一、什么是测试用例

1、测试用例的定义

设计一个情况，软件程序在这种情况下必须能够正常运行，且达到程序所设计的预期结果。

如果程序不能正常运行，且这种问题会重复发生，那表示测试人员已经测试出有缺陷，这时必须将问题标示出来并通知开发人员。

2、测试用例的模板和包含的内容

测试用例应该包含以下内容：

• 标识符（用例编号）：一般编号规则：TestCase-项目名称-模块名称-功能名称-0001
• 测试项：测试用例的测试目的。一般情况下，用一句话表明目的。（表明测试模块，测试对象，测试方式、事件）
• 依赖用例：一般功能流程上，下游功能测试用例依赖于上游功能测试的用例。
• 测试步骤：用最朴实的语言，写出来软件的操作步骤，要尽量详细。
• 测试数据：单独整合测试数据，必须和测试步骤中的数据保持一致。
• 预期结果：准确（对象、内容），原则上每一个操作步骤都要有一个结果。**在重要的步骤之后设定预期结果。一般和测试目的密切相关。测试目的决定测试步骤和测试结果。**例如：在XX操作后跳转到XX页面。
• 测试结果：要求在测试执行完成后添加，没有执行保持为空。测试结果只有两个：通过（Pass）和失败（Failed）。
• 测试人：测试的执行人可以和测试用例的设计者相同也可以不同。
• 备注：为了测试用例正常执行而做的特殊准备。

3、设计测试用例的作用

有效性：测试用例是测试人员测试过程中重要的参考依据。

可复用性：良好的测试用例具有重复使用的功能，使得测试过程事半功倍，提高测试效率。

易组织性：即使是小的项目，也可能会有几千甚至更多的测试用例，测试用例可能在数月甚至几年的测试过程中被创建和使用。

可评估性：从测试的项目管理角度来说，测试用例的通过率是检验代码质量的保证。

可管理性：测试用例也可以作为检验测试人员的进度、工作量以及跟踪/管理测试人员的工作效率的标准。

4、用例按照测试分类

• 功能（Function）
• 界面（UI）
• 性能（Performance）
• 安全（Security）
• 接口（Interface）

二、测试用例编写注意事项

• 不要设计“穷举测试用例”。
• 在详细测试用例与有效测试时间中找到平衡点。
• 好的测试用例应该多关注“反向测试问题”。
• 测试用例库应该不断更新和维护。
• 测试用例可以复用，但要注意数据有效性和环境变化。
• 测试用例是设计出来的，不是写出来的。
• 多去学习经验丰富的测试工程师所设计的测试用例。
• 针对不同的需求类型和测试对象，灵活采用不同的测试用例设计方法。
• 测试项必须是确定的，不能模棱两可。测试项一般只写一个测试目的。
• 一个无效等价类的测试数据，只能违反一个需求。
• 不能把软件的缺陷设计为测试用例。

三、黑盒测试用例设计方法

1、测试数据选择

a.等价类划分法

原理

• 把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例
• 每一类的代表性数据在测试中的作用等价于这一类中的其他值，如果某一类中的一个例子发现了错误，这一等价类中的其他例子也能发现同样的错误。
• 反之，如果某一类中的一个例子没有发现错误，则这一类中的其他例子也不会查出错误。

确定等价类的原则：

• 在输入条件规定的取值范围或值的个数情况下，可以确立一个有效等价类和两个无效等价类。
• 在输入条件规定“必须”情况下，可以划分一个有效类，一个无效类。
• 在规定了输入数据须遵守的规则后，可以划分一个有效类，和若干个无效类。

划分等价类和列出等价类表：

• 表格包括有效等价类及其测试数据，无效等价类及其测试数据。

确定测试用例：

• 为每个等价类规定一个唯一的编号
• 设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步，最后使得所有有效等价类均被测试用例覆盖。
• 设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步使得所有的无效等价类都被覆盖。

注意事项：

• 不要重复，也不要缺失。

b.边界值分析法

核心：“常在河边走，哪有不湿鞋”

• 如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。
• 如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少1、比最大个数多1的数作为测试数据。
• 分析规格说明，找出其他可能的边界条件。
• 如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。
• 如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构边界上的值作为测试用例。

2、测试步骤设计

a.因果图法 *

• 适合于描述对于多种输入条件组合的测试方法
• 根据输入条件的组合、约束关系和输出条件的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法。
• 它适合于检查程序输入条件涉及的各种组合情况。

原因和结果的关系：

原因之间的约束：

要求：原因a成立，要求b一定先成立。

结果之间的约束：

屏蔽：结果之间会出现a出现，b一定不出现。例如：收到注册成功，就一定不会收到注册失败的提示。

案例

因果关系：

约束：

因果图使用中的局限性： 当原因和结果很多时，关系连线很多，导致因果图可读性不强，因此因果图可用于局部的小功能。

**因果图优势 ** ： 能够发现设计中存在的不足。

b.判定表法

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

应用场合：主要适用于多条件的内容与结果分析。

由以下几个内容组成：

• 条件桩：列出了问题的所有条件。通常认为列出的条件的次序无关紧要。
• 动作桩：列出了问题规定可能采取的动作。这些操作的排列顺序没有约束。
• 条件项：列出针对它左列条件的取值。在所有可能情况下的真假值。
• 动作项：列出在条件项的各种取值情况下应该采取的动作。

使用的条件：所有的条件桩在表中的位置和顺序互相不影响，所有的动作桩的顺序不会因为条件顺序的变化而产生不同。

建立判定表的步骤：

第一步：识别出操作条件（原因）和对应的动作（结果）

第二步：分析条件的组合数量

第三步：简化和优化结果。排除一些不可能存在的情况

适合使用判定表设计测试用例的条件：

• 规格说明以判定表的形式给出，或很容易转换成判定表
• 条件的排列顺序不影响执行哪些操作
• 规则的排列顺序不影响执行哪些操作
• 当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则
• 如果某一规则要执行多个操作，这些操作的执行顺序无关紧要

案例：

c.场景法

原理： 测试时，生动地描绘出事件触发时的情景，有利于设计测试用例，同时使测试用例更容易理解和执行。

基本流： 软件功能按照正确的事件流实现的一条正确流程。通常一个业务仅存在一个基本流，且基本流仅有一个起点和一个终点。

备选流： 除了基本流之外的各支流，包含多种不同的情况。

注意：

• 场景中必须有基本流

测试用例的步骤：

• 根据说明，描述出程序的基本流及各项备选流
• 根据基本流和各项备选流生成不同的场景
• 对每一个场景生成相应的测试用例
• 对生成的所有测试用例重新复审，去掉多余的测试用例
• 测试用例确定后，对每一个测试用例确定测试数据值
  

案例：

d.正交试验法

概念 ：使用正交表，从大量实验中，挑选一部分具有代表性的点，进行试验，分析数据。

核心思想：

• 影响实验结果的称为实验因素
• 每一个因素的不同取值（状况）称为水平
• 正交表：每列中，同一个数字（水平），出现的次数相等，任意两列组成的数字对（水平对）出现的次数也是相同的。

实施步骤：

• 分析所有对结果有影响的因素。从多个角度和方式进行分析（不要放过文本框、按钮等需求中提及或者没有提及的内容）
• 分析每个因素的水平数量。充分利用等价类、边界值（需求中说明和未说明的都要分析）
• 选择正交表。只有特定的因素数和水平数的组合才有对应的正交表。在现实中用到的时候，找最贴近的正交表（正交表的因素数和水平数一般要大于实际的因素数和水平数）

正交表的数字关系。n代表实验次数，m代表水平数，k代表因素的数量，这三个数字之间没有任何数学关系。

案例：

使用正交设计助手选择最贴近的正交表生成。

e.功能图法

功能图法又叫做状态迁徙图

来源：在遇到有事务流或由于某种条件成立导致状态改变的软件时，如何进行测试用例的设计就比较麻烦。

状态迁徙图法的目标

• 设计足够多的测试用例达到对系统状态的覆盖、状态-条件组合的覆盖以及状态迁移路径的覆盖

步骤：

• 列出所有可能的输入事件，以IP（input） N的方式
• 定义空闲状态（初始状态）。一般以软件刚启动时打开的界面状态为空闲状态。
• 为空闲状态加操作（只加一次）
• 为上一步产生的新状态加操作（只加一次，并且已经加过的操作不进行重复添加）
• 循环给所有的新增状态加操作，直到没有新状态产生为止。
• 组合任意的状态，以列表的形式展现，设计和编写测试用例。

案例：QQ登录界面为例

f.其他用例设计方法

1、测试大纲法

一般用于快速的测试和过程记录。

2、探索性测试

基于经验和直觉，是计划内测试用例设计的补充。

探索性测试执行前也需要设计测试用例。

3、猴子测试

一种没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。

缺点：

• 测试往往不太真实
• 不能达到一定的覆盖率
• 许多测试都是冗余的
• 需要使用同样的随机数才能重建测试

3、用例设计方法综合选择

• 首先进行等价类划分
• 在任何情况下都必须使用边界值分析方法
• 如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法和判定表驱动法
• 对于参数配置类软件，要用正交试验法选择较少的组合方式达到最佳效果
• 状态迁徙图法也是很好的测试用例设计方法，我们可以通过不同时期条件的有效性设计不同的测试数据
• 对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程
• 可以用错误推测法追加一些测试用例
• 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例

案例：以某APP为例

启动页需求：读取版本信息，读取用户信息。

登录界面需求：手机号只支持大陆手机号，验证码为6位数字

4、注意事项：

测试用例的设计方法：没有哪一种是单独使用的。

• 所有的软件，都是因为某种操作结果才会导致一定的结果。---------考虑使用因果图
• 所有的软件都有文本框。---------考虑必须一定使用等价类、边界值。

四、缺陷和缺陷报告

一定不要在测试工程师的工作生涯中被开发标注缺陷状态为不是缺陷。

1、缺陷的属性

• 缺陷类型： 根据缺陷的自然属性划分（功能、用户界面、文档、软件包、性能、系统/模块接口）

  注意： 需求分析、设计阶段文档类型缺陷多，集成测试阶段接口类缺陷多，系统测试阶段功能、界面缺陷多，验收测试阶段更关注性能缺陷，实施过程软件包缺陷多。

• 缺陷严重程度 ：致命（某主要功能完全丧失）、严重（某主要功能部分丧失）、一般（次要功能没有完全实现，但不影响使用）、较小（操作不便，不影响功能的使用）

• 缺陷优先级： 必须被修复的紧急程度（立即解决P1、高优先级P2、正常排队P3、低优先级P4）

  注意： 优先级的衡量，一般可以根据测试的软件系统的全业务流程划分，软件的基本功能的缺陷优先级高。软件的备选流、基本功能的反向测试优先级较低，甚至可改可不改。

• 缺陷状态： 缺陷通过一个跟踪修复过程的进展情况。（激活或打开，已修正或修复，关闭或非激活，重新打开，推迟，保留，不能重视，需要更多信息，重复，不是缺陷，需要修改软件规格说明书）

• 缺陷起源

• 缺陷来源（需求说明书，设计文档，系统集成接口，数据流，程序代码）

• 缺陷根源（测试策略，过程、工具和方法，团队/人，缺乏组织和通讯，硬件，软件，工作环境）

面试提问：缺陷的严重程度和优先级有什么关系？

答：没有任何关系，严重程度是指缺陷对软件的影响，优先级是说对测试工作的影响，不要认为严重的缺陷修复的优先级就高。如果碰到了优先级和严重程度都高的缺陷，也只是偶然。例如：企业logo错误，不影响任何功能，但是必须优先修复。

2、缺陷的生命周期

• 发现缺陷-----测试人员
• 提交缺陷-----测试人员
• 确认缺陷-----测试主管、质量保证人员、产品经理
• 分配缺陷-----谁确认谁分配，分配的对象可能是开发、UI、产品经理等
• 修复缺陷-----分配给谁谁修复
• 验证缺陷-----测试人员
• 关闭缺陷-----只能是测试人员进行。否则，出现问题与测试人员无关。

面试提问：针对你工作中的一个bug，说说这个bug的处理过程。（缺陷生命周期中，每一个环节由谁做什么？）

3、缺陷的识别

• 通过测试用例中的预期结果进行识别
• 通过需求规格说明书中进行识别
• 通过用户手册及其他文档进行识别
• 通过同行业相类似成熟的商业软件来识别
• 通过和开发人员的沟通进行识别（下下策）
• 通过和有经验的测试人员沟通进行识别
• 参照同行业隐式需求进行识别

4、缺陷报告

• 缺陷编号：Bug_项目名称-模块名称-功能名称-0001
• 所属模块：一级模块/二级模块/三级模块
• 优先级：修复紧急程度 P1>P2>P3>P4
• 严重程度：S1>S2>S3>S4
• 缺陷概述：一句话描述（时间、地点、人物、事件）
• 缺陷描述：复现步骤、实际结果、预期结果
• 提交人
• 备注：一般写产生该缺陷的特殊情况。bug截图信息作为备注信息
  

缺陷报告编写目的：

• 易于搜索软件测试报告的缺陷
• 报告的软件缺陷进行了必要的隔离，报告的缺陷信息更具体、准确
• 软件开发人员希望获得缺陷的本质特征和复现步骤
• 市场和技术支持等部门希望获得缺陷类型分布以及对市场和用户的影响程度。
• 展现缺陷的详细信息，展现缺陷的影响程度和方式

预期读者：

• 开发人员、质量管理人员、市场人员、运维人员…

缺陷报告编写准则：

• 准确、清晰、简洁、完整、一致

缺陷描述的准则：

单一准确、可以再现、完整统一、短小简练、特定条件、补充完善、不做评价（客观）

5、缺陷跟踪系统

Bugzilla、Bugfree、禅道、QC、JIRA、企业自己开发

五、测试需求、测试用例、缺陷报告的关系

测试基本流程：获取测试需求 --编写测试计划–制定测试方案-- 设计和编写测试用例 – 执行测试 – 提交缺陷 --测试分析和评审–测试总结–准备下一版本的测试

获取测试需求是测试工作的重点 ，也是第一步。通过需求的分析，了解和掌握测试的方向和内容。例如：分析出系统的模块和组织结构，分析出软件的基本功能和运行流程（业务分析）。

需求的覆盖程度=被测试用例覆盖的需求数/需求点总数

如果需求覆盖度<100%，那一定说明了测试的覆盖度不够。

测试中，最能体现测试人员工作量的指标就是缺陷的数量和用例的数量。（设计的测试用例总量、执行的测试用例数量、执行通过的测试用例总量、执行失败的测试用例总量、提交的缺陷的总量）

提交的bug数量多于执行未通过的用例数。一条用例的预期结果数量是固定的（甚至是唯一的）。说明测试过程中发现的缺陷，除了一部分是用例执行失败带来的，还有一部分应该是测试人员自身的经验和直觉带来的。

通过测试用例总量/执行的用例总量 可以表现出系统的质量是否合格。

执行的测试用例总量/设计的测试用例总量 可以表现出系统的需求是否得到满足。