测开常见八股文整理

一、测试开发职业相关

1. 测试开发本质

测试开发的本质是助力业务成功。

2. 软件测试存在的意义

提前发现和定位错误。

提前发现和定位错误之后呢？

可以促进开发人员修正错误，从而保证交付的软件质量满足客户需求。

提前发现和定位错误的重要性？

越早发现软件中存在的问题，开发费用就越低，软件质量越高，维护费用越低。

提前测试可以使得在需求分析时期就可发现的错误，不必等到开发完成后才被发现。

3. (高频) 测试开发与测试的区别？

软件测试是什么

在规定的条件下对一个产品或者程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。

软件测试工程师的任务

软件测试工程师主要工作是检查软件是否有bug、是否具有稳定性，写出相应的测试计划、测试规范、测试用例、测试数据、测试报告，在项目中担任类似”质量管理的角色”，及时纠错及时更正，确保产品的正常运转。

测试开发工程师的任务

测试开发的核心职能依然是测试。只是工程师在具备测试经验、熟练使用测试工具并有一定开发能力的前提下，可以自主开发平台，或对现有的开源工具进行二次开发。最终目的是提升产品的测试效率。

测试开发与开发的联系

测试开发是测试岗位衍生的一个分支，利用开发能力解决测试工作中的问题，小到生成数据、并发模拟等工具的开发，大到整个自动化测试平台的设计与实现，旨在提高效率，降低成本。

4. (高频) 为什么选择测试开发？

【岗位角度来说】

从用户角度来说，现在的软件产品种类多样，已经可以满足用户大部分的基本需求了，对于同类产品，用户会更加关注产品的质量和服务，所以测试的发展前景是非常好的。

在产品研发中，提前发现和定位问题，对整个产品和质量和公司的成本都是非常重要的，测试人员的责任非常大。是非常重要的一个岗位。

【自己角度来说】 (你的经历都是开发为什么会想到做测试？)

测开还有一部分开发工作，无论是自动化脚本还是测试工具或框架，都提高了测试的效率，为质量效率保证工作提供了有力的保障。

所以测开的所需技术广度也是很高，会激发我持续学习的态度。

并且来说，我目前具备了一些测开所必备的理论知识和技能并且还在不断地学习中，我认为我可以较快的胜任这个岗位。

5. (中频) 测试开发需要哪些知识和能力？

需要的知识：

• 软件测试基础理论知识，如黑盒测试、白盒测试等
• 编程语言基础，如C/C++、Java、Python等
• 自动化测试工具，如Selenium、Appium、Robotium等
• 计算机基础知识，如数据库、Linux、计算机网络等
• 测试框架，如JUnit等

需要具备的能力：

类别	能力要求
测试能力	业务分析能力（架构、模块、流程、数据、资源、目标）、缺陷洞察能力（一般缺陷、隐形问题、连带问题、隐患、尽早发现、根源）、宏观把控能力（计划、风险、时间、成本、方向）
个人能力	专业技术能力（测试知识、计算机知识、测试工具）、逻辑思考能力（判断逻辑、可行性分析、客观思考）、问题解决能力（技术问题、工作问题、沟通问题）
团队能力	沟通表达能力（与技术人员、产品人员、上下级）、团队协作能力（分工、协助、配合、督促、承担）

6. 软件测试的核心竞争力？

测试人员的核心竞争力在于提早发现问题，并能够发现别人无法发现的问题。

1. 早发现问题：问题发现的越早，解决的成本越低。如果一个需求在还未实现的时候就能发现需求的漏洞，那么这种问题的价值是最高的
2. 发现别人发现不了的问题：所有人都能发现的问题，你发现了，那就证明你是可以被替代的。别人发现不了，而你可以发现，那么你就是无法被替代的

7. 测试和开发如何结合才能使软件质量得到更好保障？

测试和开发应该按照W模型的方式进行结合，测试和开发同步进行，能够尽早发现软件缺陷，降低软件开发的成本。

什么是W模型

测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。

W模型的优点

W模型有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。

W模型的缺点

但W模型也存在局限性。在W模型中，需求、设计、编码等活动被视为串行的，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临的困惑。

8. 怎么看待软件测试的潜力和挑战？

软件测试是正在快速发展、充满挑战的领域。

尽管现在许多自动化测试软件的出现使得传统手工测试的方式被代替，但自动化测试工具的开发、安全测试、测试建模、精准测试、性能测试、可靠性测试等专项测试中仍然需要大量具有专业技能与专业素养的测试人员。

并且随着云计算、物联网、大数据的发展，传统的测试技术可能不再适用，测试人员也因此面临着挑战，需要深入了解新场景并针对不同场景尝试新的测试方法，同时敏捷测试、DevOps的出现也显示了软件测试的潜力。

9. (高频) 一个完整的测试流程，要干什么？

测试工作需要贯穿整个软件的生命周期。

阶段	工作内容
需求分析阶段	测试人员会进行需求评审，对产品的功能进行整体把握，根据需求写用例
写测试计划	根据开发计划制定具体的测试时间计划
撰写测试用例	根据详细的需求文档，进行用例的编写；使用思维导图列举测试大纲；可使用边界值法、等价类划分法、错误推测法、因果图法等设计案例
用例评审	测试作为主导，联合开发、项目经理、PM进行测试用例评审
执行测试用例	根据测试用例执行测试；发现问题保留现场，记录测试方法，通知开发解决问题；覆盖测试用例之外若有时间可进行探索性测试
缺陷报告编写及提交	将发现的缺陷编写成正式的缺陷报告，提交给开发人员进行缺陷的确认和修复
跟踪BUG修改情况	持续跟踪bug修复进度
执行自动化测试	编写脚本，执行，分析，报告
进行性能测试	压力测试等其他测试，执行，分析，调优，报告

10. 一条缺陷都记录哪些内容

缺陷内容包括：缺陷的标题、缺陷类型、详细步骤、期望结果、缺陷等级、优先级、截图、日志信息等。

怎样提交一个高质量的缺陷：

1. 缺陷的标题尽量简单、明确、完整
2. 尽量使用惯用的表达术语和表达方法，保证表达准确专业
3. 一个缺陷报告只包括一个缺陷，复现步骤描述清楚
4. 是UI问题的话，尽量配上截图标注好有问题的地方；功能问题，尽量配上视频；闪退一类的Bug配上Log日志等
5. 一些特殊数据出现的bug，需要备注好数据信息
6. 一些非必现的问题，多测试几遍，然后备注清楚bug的复现率
7. 兼容性问题需要备注好设备型号、操作系统及浏览器版本信息
8. 缺陷尽量保证不重复提交

---

二、测试基本流程和方法

测试伴随着软件开发模型的演进

开发模型，从软件发展来看，比较典型的有瀑布模型，V模型和W模型以及敏捷开发模型。

瀑布模型

瀑布模型的主要特征在于项目完全按照阶段划分，只有前一阶段完成，才能开始下一阶段。

具体到测试活动，则只能在全部编码完成后、发布之前执行，在这种开发模型中，测试活动被完全后置了，测试仅仅是编码后的一个活动阶段，测试的重要性没有被凸显出来。

V模型

V模型不仅相对清晰地划分了测试活动的不同级别，还将其不同级别的测试活动与软件开发各阶段清晰地对应起来，强调了测试在整个开发过程中的重要性。

但在V模型中，测试依旧是编码之后才开始的，测试介入时间还是太晚。比如，需求分析阶段出现的问题，要等到系统测试阶段才能发现。

W模型

为了弥补V模型的缺点，出现了W模型，把V模型左边的每一个活动都加了一个测试设计活动，尽早和不断地进行测试。

W模型认为测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试。

优点	缺点
测试的活动与软件开发同步进行，而且测试的对象不仅仅是程序，还包括需求和设计。这样可以尽早发现软件缺陷可降低软件开发的成本	开发和测试依然是线性的关系，需求的变更和调整，依然不方便，而且如果没有文档，根本无法执行W模型，使用W模型对于项目组成员的技术也很高

H模型

相对于V模型和W模型，H模型将测试活动完全独立出来，形成了一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。

H模型中包含了如下概念：

• 测试准备：所有测试活动的准备判断是否到测试就绪点
• 测试就绪点：测试准入准则，即是否可以开始执行测试的条件
• 测试执行：具体的执行测试的程序
• 其他流程：设计流程或编码流程

优点	缺点
让测试活动完全独立贯穿整个生命周期与其他流程并发进行。在H模型中，软件测试活动可以尽早准备尽早执行，具有很强的灵活性。而且软件测试可以根据被测对象的不同而分层次、分阶段、分次序的执行，同时也是可以被迭代的	对于管理要求很高，需要定义清晰的规则和管理制度，否则测试过程将很难管理和控制，而且对于技能要求也很高。因为H模型要求能够很好的定义每个迭代的规模，不能太大也不能太小。在H模型中，测试就绪点的分析也比较困难

敏捷模型

按一个短的迭代周期工作，强调”快”，每次迭代交付一些成果（或者说先做出一个不完美但能实现一定的功能的版本）；让客户参与进来，有新需求就快速响应变化，迭代产生新版本，缩短软件版本的周期。

强调软件开发软件而不是文档。

特点：

• 让客户参与进来，客户需求的变动和软件有些不符合需求的地方可以第一时间进行了解和改动
• 缩短版本周期
• 每隔一段时间，团队可以在工作方面进行反省和改进，调整自己的行为

敏捷测试：

• 以用户需求为中心，在每一个迭代周期都需要进行测试
• 基于自动化测试 → 速度快、敏捷
• 更强调测试的速度和适应性，侧重计划的不断调整以使用需求的变化
• 强调面对面的沟通、协作，强调团队的责任，不太关注对缺陷的记录与跟踪。缺陷修复的成本也比较低

1. 测试的相关流程

需求测试 → 概要设计测试 → 详细设计测试 → 单元测试 → 集成测试 → 系统测试 → 验收测试

1) 单元测试（模块测试）

什么是单元测试

完成最小的软件设计单元（模块）的验证工作，目标是确保模块被正确的编码，对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试，及早的发现和解决不易显现的错误。

单元测试方法

通常情况下是白盒的。

单元测试的依据

代码、注释、详细设计文档LLD。

单元测试的测试重点

• 模块接口：数据能否正确进出，检查参数的数目、次序、属性，全局变量的定义和用法在各个模块中是否一致
• 局部数据结构：局部数据说明、初始化、默认值等方面的错误
• 重要执行通路：选择具有代表性、最可能发现错误的执行通路进行测试
• 出错处理通路：应该能预见出错的条件，并且设置适当的处理错误的通路
• 边界条件：对于刚好小于、等于、大于最大值或小于最小值的数据结构、控制量和数据值进行测试

2) 集成测试

什么是集成测试

通过测试发现与模块接口有关的问题。目标是把通过了单元测试的模块拿来，构造一个在设计中所描述的程序结构。

集成测试方法

黑盒和白盒结合。

集成测试的依据

单元测试模块、概要设计文档HLD。

集成测试的两种方法

方法	说明
非渐增式测试方法	先分别测试每个模块，再把所有模块设计要求放在一起组合成所要的程序
渐增式测试	把下一个测试的模块同已经测试好的模块结合起来进行测试

应当避免一次性的集成（除非软件规模很小），而采用增量集成。非渐增式测试一下子把所有模块放在一起，情况复杂，会遇到很多错误，改正错误更是极端困难。

使用渐增式方法有自顶向下和自底向上两种集成策略：

渐增式方法	概述	流程	优点	缺点
自顶向下集成	首先集成主模块，然后按照控制层次结构向下进行集成，隶属于主模块的模块按照深度优先或广度优先的方式集成到整个结构中去	1. 对主控制模块进行测试，测试时用存根程序代替所有直接附属于主控制模块的模块；2. 根据选定的结合策略（DFS/BFS）每次用一个实际模块代换一个存根程序；3. 在结合进一个模块的同时进行测试；4. 为了保证加入模块没有引进新的错误，可能需要进行回归测试；5. 直到构造起完整的软件结构	能够在测试早期对主要的控制或关键的抉择进行检验，在一个分解的好的软件结构中，关键抉择位于层次系统的较上层，因此首先碰到，早期认识主要控制里的问题是有好处的	实际使用会遇到逻辑上的问题。为了充分地测试软件系统的较高层次，需要在较低层次上的处理。然而存根程序代替了低层次的模块，没有重要的数据自下往上流
自底向上集成	从原子模块开始来进行构造和测试	1. 把底层模块组合成实现某个特定的软件子功能的族；2. 写一个驱动程序，协调测试数据的输入输出；3. 对由模块组成的子功能族进行测试；4. 去掉驱动程序，沿软件结构自下向上移动，把子功能族组合起来形成更大的子功能族

3) 系统测试

什么是系统测试

系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等是否满足其规约所指定的要求。

系统测试方法

黑盒测试。

系统测试依据

需求测试文档SRS。

系统测试的种类

• 功能测试：对产品的各功能进行验证，以检查是否满足需求的要求
• 性能测试：通过自动化测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试
• 安全测试：检查系统对非法入侵的防范能力
• 兼容测试：测试系统在不同的软硬件环境下是否能够正常的运行

4) 回归测试

回归测试是指在发生修改之后重新测试先前的测试用例以保证修改的正确性。理论上，软件产生新版本，都需要进行回归测试，验证以前发现和修复的错误是否在新软件版本上再次出现。

5) 验收测试

验收测试是部署软件之前的最后一个测试操作。目的是确保软件准备就绪，展示该系统满足用户的需求。

测试方法：黑盒。

验收测试包括Alpha测试和Beta测试：

测试类型	说明
Alpha测试	由用户在开发者的场所来进行的，开发者对用户的指导下进行测试，开发者负责记录发现的错误和使用中的问题，内测版本
Beta测试	由软件的最终用户在一个或多个用户场所来进行的，开发者通常不在现场，用户记录测试中遇到的问题并报告给开发者，公测版本

哪一步最重要？

这些测试步骤分别在软件开发的不同阶段对软件进行测试，我认为对软件完整功能进行测试的系统测试很重要，因为此时单元测试和集成测试已经完成，能够对软件所有功能进行功能测试，能够覆盖系统所有联合的部件，是针对整个产品系统进行的测试，能够验证系统是否满足了需求规格的定义。

你觉得单元测试可行吗？

可行，单元测试可以有效地测试某个程序模块的行为，是未来重构代码的信心保证。

事前可以保证质量，事后可以快速复现问题，并在修改代码后做回归自测。

可行性考虑的是要用一些可行的方法做到关键的代码可测试，如通过边界条件、等价类划分、错误、因果，设计测试用例要覆盖常用的输入组合、边界条件和异常。

集成测试和系统测试的区别和应用场景

区别	集成测试	系统测试
时间	完成单元测试后，各模块联调测试	集成测试之后，针对整个产品的全面测试
测试目标	各模块的接口是否一致，各模块间的数据流和控制流是否按照设计实现功能、以及结果的正确性验证	《需求规格说明书》中提到的功能是否有遗漏，是否正确的实现
测试重点	主要是针对程序内部结构进行测试，特别是对程序之间的接口进行测试	既包含各模块的验证性测试和功能性测试，又包括对整个产品的健壮性、安全性、可维护性及各种性能参数的测试
测试方法	一般选用黑盒测试和白盒测试相结合	一般都使用黑盒测试法

2. (高频) 黑盒测试和白盒测试

什么是黑盒测试

主要是检查软件的每一个功能是否能够正常使用，检查程序功能是否按照设计需求以及说明书的规定能够正常使用。在测试过程中，不考虑程序内部结构和特性的基础上通过程序接口进行测试。

黑盒测试常用方法：

等价类划分法

什么是等价类划分

等价类划分是将系统的输入域划分为若干部分，则可以合理做出下述假定：每类中的一个典型值在测试中的作用与这一类中其他值的作用相同。然后从每个部分选取少量代表性数据进行测试。一个理想的测试用例能独自发现一类错误。

研究程序的功能说明，从而确定输入数据的有效等价类和无效等价类，在确定输入数据的等价类时常常还需要分析输出数据的等价类，以便根据输出数据的等价类导出对应的输入数据等价类。

下述几条启发式规则可能有助于等价类的划分

1. 如果规定了输入值的范围，则可划分出一个有效的等价类和两个无效的等价类
2. 如果规定了输入数据的个数，则类似地也可以划分出一个有效等价类和两个无效等价类
3. 如果规定了输入数据的一组值，并且程序对不同输入值做不同处理，则每个允许的输入值是一个有效等价类，还有一个无效等价类（任意一个不允许的输入值）
4. 如果规定了输入数据必须遵循的规则，则可以划分出一个有效的等价类和若干个无效的等价类
5. 如果规定了输入数据为整形，则可以划分出正整数、零和负整数3个有效类
6. 如果程序的处理对象是表格，则应该使用空表，以及含一项或多项的表

划分出等价类以后，设计测试方案

1. 设计一个新的测试方案以尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步骤直到所有有效等价类都被覆盖为止
2. 设计一个新的测试方案，使他覆盖一个而且只覆盖一个尚未被覆盖的无效等价类，重复这一步骤直到所有无效等价类都被覆盖为止

边界值分析法

什么是边界值分析法

边界值分析法是对等价类划分的一种补充，因为大多数错误都在输入输出的边界上。如果边界附近取值不会导致程序出错，那么其他取值出错的可能性也就很小。

边界值分析法是通过优先选择不同等价类间的边界值覆盖有效等价类和无效等价类来更有效的进行测试，因此该方法要和等价类划分法结合使用。选取的测试数据应该刚好等于、刚刚小于和刚刚大于边界值。

判定表法

判定表驱动法是分析和表达多逻辑条件下执行不同操作的情况的工具。

• 条件桩：列出了问题的所有条件
• 动作桩：列出了问题规定可能采取的操作
• 条件项：列出针对它所列条件的取值，在所有可能情况下的真假值
• 动作项：列出在条件项的各种取值情况下应该采取的动作

错误分析法

错误推测法是基于以往的经验和直觉，参照以往的软件系统出现的错误，推测当前被测程序中可能存在的缺陷和错误，有针对性地设计测试用例。

什么是白盒测试

它根据程序的控制结构设计测试用例，白盒测试法检查程序内部逻辑结构，对所有的逻辑路径进行测试，是一种穷举路径的测试方法。

白盒测试常用方法（强度由低到高）：

覆盖类型	说明
语句覆盖	所有的”语句”都要覆盖一遍。就是设计若干个测试用例，运行被测程序，使得每一个执行语句至少执行一次
判定覆盖	包含语句覆盖，每个判断T、F各一次。使设计的测试用例保证程序中每个判断的每个取值分支至少经历一次
条件覆盖	包含语句覆盖，每个条件T、F各一次。是指选择足够的测试用例，使得运行这些测试用例时，判定中每个条件的所有可能结果至少出现一次，但未必能覆盖全部分支
判定条件覆盖	包含判定覆盖、条件覆盖。设计的测试用例可以使得判断中每个条件所有的可能取值至少执行一次，同时每个判断本身所有的结果也要至少执行一次
条件组合覆盖	每个条件的每种组合。选择足够的测试用例，使所有判定中各条件判断结果的所有组合至少出现一次
路径覆盖	所有路径至少执行一次

黑盒和白盒测试的区别和关系

对比项	黑盒测试	白盒测试
方法	不查看内部代码结构	了解程序内部的代码结构
设计依据	根据软件需求和规范设计	按照程序内部逻辑设计
涉及阶段	涉及到单元、集成、系统和验收测试	涉及到单元、集成测试
经验要求	测试人员不需要程序经验	需要有一定的程序经验
执行方式	可以手动或自动化测试	可以手动或自动化测试
缺点	覆盖率低	穷举路径不太可能，只能测试开发人员做的对不对，不知道需求是否正确满足

3. 自动化测试

自动化测试把以人为驱动的测试行为转化为机器执行的一种过程。在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件。

自动化测试的前提条件：

1. 需求变动不频繁
2. 项目周期足够长：自动化测试需求的确定、框架的设计、测试脚本的编写与调试均需要相当长的时间来完成
3. 自动化测试脚本可重复使用

你觉得自动化测试有什么意义，都需要做什么？

1. 可以对程序的新版本自动执行回归测试
2. 可以执行手工测试困难或者不可能实现的测试，如压力测试，并发测试
3. 能够更好的利用资源，节省时间和人力

执行自动化测试之前首先判断这个项目适不适合推广自动化测试，然后对项目做需求分析，指定测试计划，搭建自动化测试框架，设计测试用例，执行测试，评估。

手动测试与自动化测试的优缺点：

类型	优点	缺点
手动测试	1. 测试人员具有经验和对错误的猜测能力；2. 测试人员具有审美能力和心理体验；3. 测试人员具有是非判断和逻辑推理能力	1. 重复的手工回归测试，代价昂贵、容易出错；2. 依赖于软件测试人员的能力
自动化测试	1. 对程序的回归测试更方便；2. 可以运行更多更繁琐的测试；3. 可以执行一些手工测试困难或不可能进行的测试；4. 更好地利用资源；5. 测试具有一致性和可重复性；6. 测试的复用性；7. 增加软件信任度	1. 不能取代手工测试；2. 手工测试比自动测试发现的缺陷更多；3. 对测试质量的依赖性极大；4. 测试自动化不能提高有效性；5. 测试自动化可能会制约软件开发；6. 工具本身并无想象力

4. Bug

Bug的周期？以及不同类别的Bug？

状态	说明
New（新的）	当某个bug被第一次发现的时候，测试人员需要与项目负责人沟通以确认发现的的确是一个bug，如果被确认是一个bug，就将其记录下来，并将bug的状态设为new
Assigned（已指派的）	当一个Bug被指认为New之后，将其反馈给开发人员，开发人员将确认这是否是一个Bug，如果是，开发组的负责人就将这个bug指定给某位开发人员处理，并将bug的状态设定为assigned
Open（打开的）	一旦开发人员开始处理bug的时候，他就将这个bug的状态设置为Open，表示开发人员正在处理这个Bug
Fixed（已修复的）	当开发人员进行处理（并认为已经解决）之后，他就可以将这个bug的状态设置为fixed并将其提交给开发组的负责人，然后开发组的负责人将这个Bug返还给测试组
Pending Reset（待再测试）	当bug被返还给测试组后，状态设为这个
Reset（再测试）	测试组的负责人将Bug指定给某位测试人员进行再测试，并将Bug的状态设置为Reset
Closed（已关闭的）	如果测试人员经过再次测试之后确认bug已经被解决之后，就将状态设置为closed
Reopen（再次打开的）	如果经过再次测试发现bug仍然存在的话（指bug本身而不是包括因修复而引发的新bug），测试人员将bug再次传递给开发组，并将bug的状态设置为Reopen
Pending Reject（拒绝中）	如果测试人员传递到开发组的bug被开发人员认为是正常行为而不是Bug时，这种情况下开发人员可以拒绝，并将Bug的状态设置为pending reject
Rejected（被拒绝的）	测试组的负责人接到上述bug的时候，如果他发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能算作Bug的时候，开发组负责人就将这个Bug的状态设置为rejected
Postponed（延期）	对于一些特殊的Bug的测试需要搁置一段时间，比如无效的测试数据，一些特殊的无效的功能等等，在这种情况下，Bug的状态就被设置为postponed

Bug类型

• 代码错误
• 界面优化
• 设计缺陷
• 配置相关
• 安装部署
• 安全相关
• 性能问题
• 标准规范
• 测试脚本
• 其他

如何进行Bug测评

Bug的 priority（优先级） 和 severity（严重程度） 是两个重要属性，通常人员在提交bug的时候，只定义severity，将priority交给leader定义。通常bug管理中，severity分为四个等级，而priority分为五个等级。

Severity（严重程度）：

等级	说明
Blocker	即系统无法执行，崩溃，或严重资源不足，应用模块无法启动或异常退出，无法测试，造成系统不稳定。常见的有严重花屏、内存泄漏、用户数据丢失或破坏、系统崩溃/死机/冻结、模块无法启动或异常退出、严重的数值计算错误、功能设计与需求严重不符、其他导致无法测试的错误，如服务器500错误
Critical	即影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。常见的有：功能未实现、功能错误、系统刷新错误、数据通讯错误、轻微的数值计算错误、影响功能及界面的错误字或拼写错误
Major	即界面、性能缺陷、兼容性，常见的有：操作界面错误，边界条件错误，提示信息错误，长时间操作无进度提示，系统未优化，兼容性问题
Minor/Trivial	即易用性及建议性问题

Priority（优先级）：

等级	说明
Immediate	即马上解决
Urgent	急需解决
High	高度重视，有时间要马上解决
Normal	正常处理
Low	在系统发布前解决，或确认可以不用解决

5. APP性能

软件质量的六个特征

按照软件质量国家标准GB-T8566—2001G，软件质量可以用下列特征来评价：

特征	说明
功能特征	与一组功能及其指定性质有关的一组属性，这里的功能是满足明确或隐含的需求的那些功能
可靠特征	在规定的一段时间和条件下，与软件维持其性能水平的能力有关的一组属性
易用特征	由一组规定或潜在的用户为使用软件所需作的努力和所作的评价有关的一组属性
效率特征	与在规定条件下软件的性能水平与所使用资源量之间关系有关的一组属性
可维护特征	与进行指定的修改所需的努力有关的一组属性
可移植特征	与软件从一个环境转移到另一个环境的能力有关的一组属性

测试的类型

测试分为功能测试和非功能测试，非功能测试又可分为：性能测试、压力测试、容量测试、健壮性测试、安全性测试、可靠性测试、恢复性测试、备份测试、协议测试、兼容性测试、可用性测试、配置测试、GUI测试。

APP性能测试的指标

1) 内存

内存消耗测试节点的设计目标是为了让应用不占用过多的系统资源，且及时释放内存，保障整个系统的稳定性。需要引入几个概念：

• 空闲状态：打开应用后，点击home键让应用后台运行，此时应用处于的状态
• 中等规格和满规格：指的是对应用的操作时间的间隔长短不一，中等规格时间较长，满规格时间较短

内存测试中存在很多测试子项：

• 空闲状态下的应用内存消耗
• 中等规格状态下的应用内存消耗
• 满规格状态下的应用内存消耗
• 应用内存峰值
• 应用内存泄漏
• 应用是否常驻内存
• 压力测试后的内存使用

2) CPU

使用Android提供的命令来获取：

adb shell dumpsys cpuinfo | grep packagename > /address/cpu.txt
adb shell top | grep packagename > /address/cpu.txt

3) 流量

网络流量测试是针对大部分应用而言的，可能还有部分应用会关注网速、弱网之类的测试。

流量测试包括以下测试项：

• 应用首次启动流量消耗
• 应用后台连续运行2小时的流量值
• 应用高负荷运行的流量峰值

4) 电量

• 测试手机安装目标APK前后待机功耗无明显差异
• 常见使用场景中能够正常进入待机，待机电流在正常范围内
• 长时间连续使用应用无异常耗电现象

5) 启动速度

• 第一次：首次启动—应用首次启动所花费的时间
• 第二次：非首次启动—应用非首次启动所花费的时间
• 第三类：应用界面切换—应用界面内切换所花费的时间

6) 滑动速度、界面切换速度

7) 与服务器交互的网络速度

APP测试工具

功能测试自动化：

• 轻量接口自动化测试：JMeter
• APP UI层面的自动化：
  • Android：UI Automator Viewer, Android JUnit, Instrumentation, UIAutomator
  • iOS：基于Instrument的iOS UI自动化

性能测试：

• Web前端性能测试：网络抓包工具：Wireshark；网页文件大小：webpagetest, pagespeed insight, chrome adb
• APP端性能测试：Android内存占用分析：MAT；iOS内存问题分析：ARC模式
• 后台服务性能测试：负载、压力、耐久性、可扩展性、基准；工具：Apache AB, JMeter, LoadRunner

专项测试：

类型	工具/方法
兼容性测试	手工测试：操作系统、分辨率、rom、网络类型；云平台：testin
流量测试	Android自带的流量管理；iOS自带的Network；tcpdump抓包；WiFi代理抓包：Fiddler
电量测试	基于测试设备的方法，购买电量表进行测试；GSam Battery Monitor Pro；iOS基于Instrument Energy工具
弱网络测试	手机自带的网络状况模拟工具；基于代理的弱网络的模拟；Windows: Network Delay Simulator；Mac: Network Link Conditioner

流量节省方法：

• 压缩数据，json优于xml
• WebP优于传统的JPG，PNG
• 控制访问的频次
• 只获取必要的数据
• 缓存

6. 性能、压力测试

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。

负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。

性能测试关注什么

性能测试概括为三个方面：

方面	说明
客户端性能测试	考察客户端应用的性能，测试的入口是客户端。主要包括并发性能测试、疲劳强度测试、大数据量测试和速度测试等，其中并发性能测试是重点
网络性能测试	重点是利用成熟先进的自动化技术进行网络应用性能监控、网络应用性能分析和网络预测
服务器性能测试	可以采用工具监控，也可以使用系统本身的监控命令，实施测试的目的是实现服务器设备、服务器操作系统、数据库系统、应用在服务器上性能的全面监控

关注指标：

响应时间RT、每秒能完成的响应数TPS、CPU利用率、内存占用、网络（带宽使用率）、手机APP要考虑耗电量，负载大时，各项指标如何变化，联网的话要考虑不同网络环境（正常网、超快网、网速慢、断网）时指标的变化。

并发用户数和在线用户数的区别

• 在线用户数：用户同时在一定时间段的在线数量
• 并发用户数：某一时刻同时向服务器发送请求的用户数

QPS（每秒查询率）

每秒查询率是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，用来衡量服务器的机器性能。

QPS和TPS的区别

• TPS：Transactions Per Second（每秒传输的事务处理个数），即服务器每秒处理的事务数
• TPS包括一条消息入和一条消息出，加上一次用户数据库访问，是软件测试结果的测量单位

---

三、故障排除类题目

1. PC网络故障，以及如何排除障碍

1. 排除接触故障：确保你的网线是可以正常使用的。然后禁用网卡后再启用，排除偶然故障。打开网络和共享中心，单击窗口左上侧”更改适配器设置”，右击其中的”本地连接”或”无线网络连接”，单击快捷菜单中的”禁用”命令，即可禁用所选网络。接下来重启网络，只需右击后单击启用即可。

2. 使用ipconfig查看计算机的上网参数：单击”开始-所有程序-附件-命令提示符”，打开命令提示符窗口，输入ipconfig，按Enter确认，可以看到机器的配置信息，输入ipconfig/all可以看到IP地址和网卡物理地址等相关网络详细信息。

3. 使用Ping命令测试网络的连通性，定位故障范围：在命令提示符窗口中输入ping 127.0.0.1，数据显示本机分别发送和接受了4个数据包，丢包率为零，可以判断本机网络协议工作正常，如显示”请求超时”则表明本机网卡的安装或TCP/IP协议有问题，接下来就应该检查网卡和TCP/IP协议，卸载后重装即可。

4. ping本机IP：在确认127.0.0.1地址能被Ping通的情况下，继续使用Ping命令测试本机IP地址能否被Ping通，如不能，说明本机的网卡驱动程序不正确，或者网卡与网线之间连接有故障，也有可能是本地的路由表受到了破坏，此时应检查本机网卡的状态是否为已连接，网络参数是否设置正确，如果正确可是不能Ping通，就应该重新安装网卡驱动程序。丢失率为0，可以判断网卡安装配置没有问题，工作正常。

5. ping网关：网关地址能被Ping通的话，表明本机网络连接以及正常，如果命令不成功，可能是网关设备自身存在问题，也可能是本机上网参数设置有误，检查网络参数。

2. 请问你怎么测试网络协议

协议测试包括四种类型的测试：

测试类型	说明
一致性测试	检测协议实现本身与协议规范的符合程度
互操作性测试	基于某一协议检测不同协议实现间互操作互通信的能力
性能测试	检测协议实现的性能指标，比如数据传输速度，连接时间，执行速度，吞吐量，并发度
健壮性测试	检测协议在各种恶劣环境下运行的能力，比如注入干扰报文、通信故障、信道被切断

---

四、设计测试用例

测试用例的组成元素

内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等。

简单地认为，测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，用于核实是否满足某个特定软件需求。

测试用例主要包含四个内容：

• 用例标题：主要描述测试某项功能
• 前置条件：用例标题需要满足该条件
• 测试步骤：描述用例的操作步骤
• 预期结果：符合预期需求（开发规格书、需求文档、用户需求等）

如何写测试用例

1. 测试人员尽早介入，彻底理解清楚需求，这个是写好测试用例的基础
2. 如果以前有类似的需求，可以参考类似需求的测试用例，然后还需要看类似需求的bug情况
3. 清楚输入、输出的各种可能性，以及各种输入的之间的关联关系，理解清楚需求的执行逻辑，通过等价类、边界值、判定表等方法找出大部分用例
4. 找到需求相关的一些特性，补充测试用例
5. 根据自己的经验分析遗漏的测试场景
6. 多总结类似功能点的测试点，才能够写出质量越来越高的测试用例
7. 书写格式一定要清晰（测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果）

测试用例的重要级别是怎么分的

级别	划分原则	参考比例
特高用例	核心功能的主流程，基本业务流，保证功能的完整性，特高用例失败会导致其他多处功能无法正常使用。用例设计常用思想&方法：场景法	10%左右
高等级	核心功能的正向业务流，覆盖平台功能的所有重要业务流	15%左右
中等级	重要功能的正向业务流、核心&重要功能的异常业务流。常见输入框、字符等正向用例，常见异常场景的业务流，常见的失败类场景	30%左右
低等级	其他异常用例、UI/UE相关用例等。用例设计常用思想&方法：边界值、无效等价类等	45%左右

特高及高等级用例要覆盖所有功能的正向业务流，能够保证软件功能稳定使用。包含功能交互、使用场景、使用频率较高的正常功能用例。

1. 微信红包设计

单个红包的功能上：

发送方：

• 输入红包金额：红包金额为0、0.01、200.00、200.01、199.99、20
• 输入留言：留言输入数字、字母、汉字、特殊字符；留言长度；留言复制粘贴
• 选择表情：表情-选择收藏的表情、其他表情；删除表情、选择新的表情
• 选择红包封面：封面选择
• 选择支付方法：（零钱、零钱通、银行卡、添加新卡支付）判断里面钱数与红包钱数的关系；使用指纹、面部识别、密码支付（正确输入、错误输入的情况）
• 钱财金额：红包发送成功后，钱包金额减少对应数值

接收方：

• 接收方收到红包：接受者对红包封面、留言、表情、金额均能正确了解
• 接收方的金额：被领取后显示已领取，领取者钱包增加相应金额，再次点开红包只能显示红包信息
• 只有接收方可以点开：发送方点开不能领取，只显示相关信息
• 未领取：24小时后未领取显示退回，钱包金额增加，对方不能再领取

群发红包功能：

• 红包个数：红包个数为空、0、1、100、99、101
• 红包金额：红包拆开每个金额一样，均为发红包时设置的单个金额对应的钱数
• 红包被拆提示：红包被拆时，有相应提示
• 退回：红包24小时内未被拆完，剩余钱被退回，相应支付方式中钱数增加

群发红包-拼手气红包功能：

每个人拆开数额不同，总金额等于红包总额；24小时内领完显示最佳手气，否则不显示。

兼容性测试：

• 测试安卓、iOS不同型号手机
• UI测试：显示无错误，风格样式统一
• 中断测试：不同应用间切换、没电、没网、来电话、短信
• 网络测试：2G、3G、4G、5G、WiFi、移动联通电信、弱网、没网

2. 用户登录过程需要做哪些分析？

功能测试：

输入用户名和密码：

• 用户名和密码，太短或太长的处理（边界值法）
• 用户名和密码，有特殊字符(比如空格)及其他非英文的情况
• 记住用户名，记住密码
• 登录失败后，不记录密码
• 用户名和密码前后有空格的处理
• 密码是否是密文显示，使用*号或圆点等符号代替
• 验证码的辨认难度，考虑颜色（色盲使用者），刷新或换一个按钮是否好用
• 输入密码时，大写键盘开启时是否有提示信息
• 什么都不输入，点击提交按钮，检查提示信息

登录流程：

• 正常流程（正确账号密码，点击提交，验证能否正确登录）
• 异常流程（错误的账号密码，点击提交，验证登录失败，并提示相应错误信息）
• 登录成功后能否正确跳转
• 登录token测试

界面测试：

• 布局是否合理，按钮和表单是否整齐
• 按钮和表单高度和长度是否符合要求
• 界面风格是否符合UI设计稿
• 文字有无错别字

性能测试：

• 打开登录界面，需要的时间是否在需求要求的时间内
• 输入正确的账号密码，点击登录，是否在需求时间内跳转成功
• 模拟大量用户同时登录，检查一定压力下能否正常跳转

安全性测试：

• 用户名或密码是否通过加密方式，发送给后端服务器
• 用户名和密码应该在前端和后端做双重验证
• 用户名和密码的输入框，应该屏蔽SQL注入攻击
• 用户名和密码的输入框，应该禁止输入脚本（防止XSS攻击）
• 防止暴力破解，检测是否有错误登录的次数限制
• 是否支持多用户在同一机器上登录
• 同一用户能否在多台机器上登录

可用性测试：

• 是否可以用全键盘操作，是否有快捷键
• 输入用户名，密码后按回车，是否可以登录
• 输入框是否可以Tab切换

兼容性测试：

• 不同浏览器下能否显示正常，且功能正常
• 同种浏览器下不同版本能否显示正常且功能正常
• 不同的操作系统是否能正常工作
• 移动设备上是否正常工作

3. 如何对短视频APP（抖音）进行测试

功能测试：

刷抖音：

• 视频清晰度
• 视频暂停、播放功能
• 视频信息（标题、描述、音乐、标签）
• 点赞数、双击点赞功能
• 评论功能（评论数、查看评论、发表评论）
• 分享转发
• 同款音乐
• 用户个人主页
• 搜索测试（热搜、话题功能）

拍抖音：

• 调起摄像头
• 视频拍摄、本地视频
• 视频剪辑功能测试
• 选择音乐功能测试
• 道具、表情、滤镜
• 发布短视频测试

商业化：

• 广告植入（跳过广告）
• 抖音商城

性能测试：

• 视频质量（码流、帧率、不卡帧）
• 网络测试（WiFi/5G/4G/3G/弱网、断网）
• 服务器负载测试
• 服务器压力测试
• 长时间运行
• 耗电量
• 内存是否泄漏
• CPU状况

安全测试：

• 视频链接加密
• 视频防止去水印
• 视频反爬

异常测试：

• 弱网、断网等异常测试
• 码率切换测试
• 破坏性点击（疯狂点赞、取消点赞）
• 切换前后台

兼容性测试：

• 移动端系统兼容性
• 应用权限测试

安装、卸载测试

4. 如何对聊天系统（偏客服系统）进行测试

功能测试：

用户端：

• 登陆状态下正常发送消息
• 未登录状态下发送消息，会提示去登陆
• 输入框发消息测试（过长、过短、表情、图片、视频、语音、英文、数字、url、卡片、红包、位置等）
• 接收消息测试
• 消息顺序（不乱序、不重复、不错误、不丢失）
• 历史消息
• 未读消息提醒（小红点显示隐藏、未读消息数）
• 用户头像点击
• 自动回复选项点击
• 长按消息（复制/转发/删除/撤回/引用）
• 一键跳转到最新消息

客服端：

• 正常回复消息
• 输入框发消息测试（过长、过短、表情、图片、视频、语音、英文、数字、url、卡片、红包、位置等）
• 接收消息测试
• 消息顺序（不乱序、不重复、不错误、不丢失）
• 历史消息
• 未读消息提醒
• 自动回复设置
• 用户头像点击，用户信息采集
• 长按消息（复制/转发/删除/撤回/引用）
• 一键跳转到最新消息
• 消息群发（有可能也没有此功能）

接口测试：

• 发送消息接口（msg_type/msg_content/埋点测试/extra_content）
• RPC接口调用
• 消息队列（排序、队列长度、数据格式）

性能测试：

• 模拟多用户同时向单用户发送消息
• 模拟单用户同时向多用户发送消息
• 1s内发送多条消息
• 同一聊天室内，1s内接收多条消息，端上应有消息延迟展示策略

兼容性测试：

• 跨平台跨系统登陆接收消息并展示
• 多端登陆同一个账号，接收别人发来的消息（若支持多端登录）
• 多端登录同一个账号，一端发送消息，自己的消息在别的端的展示情况（若支持多端登录）

异常测试：

• 断网/弱网情况下发送消息
• 输入框输入sql、脚本等

5. 如何对长视频APP（优酷）进行测试

1) 功能测试：

• 视频能够正常播放
• 会员特权（购买、有效期、行使特权）
• 播放组件（点播播放器、直播播放器、缓存视频播放器）
• 视频清晰度转换（手动、自动）
• 全屏/缩放；横屏/竖屏；锁屏
• 播放/暂停/下一集
• 进度条（快进、快退、锚点播放）
• 亮度
• 声音
• 弹幕
• 缓存
• 投屏
• 选集
• 倍速
• 断点续播
• 视频水印
• 返回键
• 分享/收藏
• 睡眠模式
• 商业化（广告）
• 片前广告/片中广告/片尾广告
• 暂停广告弹窗
• VIP跳过广告
• 广告倒计时自动关闭

2) 性能测试：

• 清晰度测试（4K、蓝光、超清、高清、标清、流畅），测试固定码率播放以及切换码率播放
• 负载测试（最大同时拉流数）
• 网络测试（WiFi/5G/4G/3G/弱网、断网）
• 首屏加载时间
• 长时间运行
• 耗电量
• 内存泄漏
• CPU状况
• 是否有丢帧

3) 安全测试：

• 视频流地址加密
• 会员接口不对外暴露
• 防止去广告脚本攻击
• 缓存视频加密

4) 异常测试：

• 弱网、断网等异常测试
• 码率切换测试
• 频繁切换前后台

5) 兼容性测试：

• 移动端兼容性
• PC端兼容性
• 浏览器兼容性
• TV端

6. 如何对列表页（贝壳找房）进行测试

1) 功能测试：

• 列表排序
• 列表翻页
• 列表筛选
• 列表少结果、无结果、多结果的页面展示
• 检索系统、推荐系统、商业化（广告）测试
• 回到顶端浮标
• 列表卡片跳转
• 列表卡片UI展示（价格、标题、描述、标签等）
• 上滑加载更多
• 下拉刷新列表
• 其他（浮标按钮等）

2) 性能测试：

• 压力测试
• 负载测试
• 大数据量返回的表现（一般后端会做翻页）
• 页面响应时间测试

3) 兼容性：

• 浏览器兼容性
• PC端操作系统兼容性
• 移动端操作系统兼容性
• 弱网/无网显示

4) 埋点测试：

• 曝光埋点
• 点击埋点
• PV/UV统计

7. 如何对搜索框（贝壳找房）进行测试

1) 功能测试：

• 输入关键字，查看返回结果是否准确
• 查询有结果的显示
• 查询无结果的显示
• 查询少结果的显示
• 输入框测试：输入特殊内容，过长/过短的关键词，关键词输入
  • 正常：楼盘、地区、街道、公司、城市、地铁沿线、商圈等关键词
  • 异常：空格及其他特殊字符、代码等
• 热门关键词搜索测试（需要结合CMS后台测试）
• sug动态搜索测试
• 商业化（广告）相关测试
• 搜索出来的楼盘结果列表：排序、翻页、是否列表去重
• 搜索历史功能测试
• 检索系统和推荐系统的测试
• 结果跳转（跳转到详情页、跳转到列表页）

2) 性能测试：

• sug耗时
• 点击搜索结果，渲染结果列表耗时
• 压力测试，不同用户数压力下的表现
• 负载测试，看极限能承受多大的用户量同时正常使用
• 大数据量返回的表现

3) 易用性：

• 功能是否易用，输入法调起是否正常，按钮可点击区域是否满足易用性
• 针对不同，是否有友好的提醒
• 搜索结果的楼盘卡片是否显示合理（价格、标题、描述等）
• 搜索结果是否准确，排序是否合理
• 控件设计是否符合APP整体设计风格

4) 兼容性：

• 浏览器兼容性
• PC端操作系统兼容性
• 移动端操作系统兼容性
• 杀毒软件、防火墙、不同输入法等工具共同使用，是否适配

5) 安全性：

• 表单不允许被SQL注入（录入一些数据库查询的保留字符，如单引号，%等）
• 是否有反爬策略
• 是否有黄反策略或对涉及国家安全、法律禁止的内容是否进行过滤和控制

8. 测试一瓶矿泉水

测试类型	测试内容
功能测试	水瓶漏不漏、瓶中的水能不能被喝到
界面测试	外观是否美观
安全性	瓶子的材质有没有毒或者细菌
可靠性	从不同高度落下的损坏程度
可移植性	在不同的地方、温度等环境下是否都可以正常使用
兼容性	是否能够容纳果汁、白水、酒精、汽油等
易用性	是否烫手、是否有防滑措施，是否方便饮用
用户文档	使用手册是否对用法、限制、使用条件等有详细描述
疲劳测试	将盛上水放24小时检查泄漏时间和情况；盛上汽油放24小时检查泄漏时间和情况等
压力测试	用针在瓶身上施加压力，看多大压强时会穿透
跌落测试	测试在何种高度跌落会破坏水瓶

9. 测试朋友圈点赞功能

功能测试：

1. 是否可以正常点赞和取消
2. 点赞的人是否在可见分组里
3. 点赞状态是否能即时更新显示
4. 点赞状态，共同好友是否可见
5. 点赞显示的是否正确，一行几个
6. 点赞是否按时间进行排序，头像对应的是否正确
7. 是否能在消息列表中显示点赞人的昵称

接口测试： 点赞朋友圈，验证朋友能否收到提示消息

性能测试： 点赞朋友圈，是否在规定时间显示结果，是否在规定时间在朋友手机上进行提示

兼容性测试： 在不同的终端上点赞，验证是否成功

---

答题角度总结

日常物品

测试类型	测试角度
功能测试	等价类划分+边界值分析
外观测试	外观完整、美观；尺寸大小/材质；外部说明清晰；舒适度
性能测试	使用寿命、响应时间、长时间使用情况、负载情况、压力情况
安全测试	材质毒性
兼容测试	不同材质、不同容量、不同形状的兼容性
易用测试	使用方便、携带方便、操作简单、防护措施
异常测试	耐破坏性、异常情况的响应、应急情况
可维护性	配件更换、维修、拆除

文本框/登录/聊天/查找类

测试类型	测试角度
功能测试	太短/太长（边界值分析）/特殊字符/输入为空、正常流程、异常流程、选中、复制粘贴、光标位置
性能测试	响应时间、压力测试、负载测试、单人聊天、多人聊天
易用/界面	输入法调起、按钮点击区域、提醒到位、搜索结果、展示结果是否合理、设计风格、快捷键
兼容性	浏览器、PC端、移动端、杀毒软件、防火墙、不同输入法、不同版本
安全性	异常测试（弱网、断网）、反爬策略、内容审核、不允许SQL注入、加密传输、防止暴力破解、多端登录

支付交易类

测试类型	测试角度
功能测试	支付方式、余额充足或不足、密码输入正确或错误、验证码、金额校验（空值、负值、最小金额、最大金额、消费上限）、取消支付
性能测试	页面跳转时间、耗电量和流量、更换支付方式响应时间、并发情况下、多端登录
外观测试	页面美观、布局合理、信息提示正确、字体清晰
安全测试	密码暗纹、支付金额过大、对面账户异常、新设备授权
易用测试	操作简单快捷、提示信息到位
兼容性测试	不同系统、不同版本、不同网络、不同浏览器
异常测试	断网、弱网、关机、刷新页面、退出程序

人工智能类

测试类型	测试角度
功能测试	不说话/声音小/错别字/文字长度限制/语音时间限制/不同语言/不同物种语音/多语音/敏感词处理/断句功能/识别数字
性能测试	响应时间、耗电量、资源占用
外观测试	界面设计、布局合理、信息提示正确
易用测试	操作简单快捷、提示信息到位
兼容性测试	不同系统、不同版本、不同网络、不同浏览器
异常测试	断网、弱网发送顺序、关机

视频类

测试类型	测试角度
功能测试	清晰度、暂停播放、视频信息、互动功能、分享转发、个人主页、广告植入、会员特权、播放组件（弹幕、进度条、声音、投屏、小屏幕）、断点续播
性能测试	负载测试、压力测试、资源消耗、视频质量（帧率、码流）
安全测试	视频链接加密、反爬、防止去水印、脚本攻击
异常测试	弱网、断网、码率切换测试、破坏性点击、切换前后台
兼容性测试	不同设备、不同网络、不同操作系统