第3讲 测试用例-等价类划分法和边界值法

一、软件项目的测试流程（重点）

1、熟悉分析需求

2、制定测试计划

通常由测试主管（组长/经理）制定测试计划，测试人员要阅读计划，并按计划要求执行

3、设计测试

分析需求-->提炼测试点-->编写测试用例-->评审用例

4、执行测试，记录测试结果

测试结果：通过--pass

失败--failed

5、记录bug，并且对bug进行跟踪管理

《缺陷报告》

6、测试的总结

对项目测试中的数据进行统计总结，形成《测试总结报告》、《测试报告》

补充说明：

(1) 在项目测试过程中，主要的测试相关文档有：《测试计划》、《测试用例》、《缺陷报告》、《测试总结报告》

(2) 测试计划主要有哪些部分组成？

1）测试产品简介

产品介绍、测试目的、测试范围

2）测试参考文档和提交的测试文档

3）测试进度安排（排期）

4）测试资源

人力、测试环境、测试工具

5）bug的严重程度和优先级的具体说明（可以独立形成文档）

6）测试风险和风险预案

7）项目的测试策略

（3）你能制定测试计划吗？

可以

（4）软件项目测试结束的标准有哪些？

常见的结束标准有：

测试用例100%测试执行

缺陷的解决/修复率达到95%以上

对于发现的所有bug有相应的处理结果，未解决的bug有明确的后期处理说明

完成测试提交物的提交（计划、总结、用例等）

应覆盖测试需求规格说明书中所有的需求

二、测试用例/案例（test case ）

1、什么是测试用例？

在测试执行之前，由测试人员编写的，用来指导测试过程的重要文档

测试用例的常见组成有：用例编号、用例标题、测试目的、预置条件、测试步骤、预期结果、参考需求、撰写人、是否评审、功能模块、用例类型等

2、黑盒/功能测试时，常用的设计测试用例的方法有哪些？

场景法、等价类划分法、边界值法、判定表法

补充：经验型测试方法--错误推测法

3、 设计测试用例可以参考什么？

（1）需求和需求相关文档

（2）核心的技术文档（例如：设计文档）

说明：测试方可能会拿不到核心技术文档（例如外包的测试团队）

（3）已经开发出来的被测系统

说明：在实际工作中，只参考需求，大概只能设计50%-70%左右的测试用例，结合着被测系统，测试人员可以补充部分用例，这样，可以使用例的设计更为完善

注意：测试用例是可维护的，在项目测试的过程中可以不断完善，逐步优化的

（4）最后可以与开发人员、产品经理、用户等沟通讨论。

 注意：实际工作中这些参考资料可能残缺不齐全，但是测试人员应利用一切能利用的现有资源，尽力去测。也可以辅助的查看一些网上资料或参考市面上的类似软件产品设计测试。

4、测试思想

（1）穷举测试思想：就是将所有可能的数据或情况全部都测试，穷举测试是最全面的测试，测试质量高；但是穷举测试效率太低，要耗费太多时间，在实际工作中无法应用

（2）理想测试思想：就是挑选最少的测试数据，达到最好的测试质量（抽样测试），抽样测试的测试效率高，但是毕竟没有穷举测试，有可能有遗漏bug的风险，如果测试时间允许的情况下，测试人员应进行补充测试，以降低遗漏bug的风险

三、等价类划分法

1、应用场合 （这个方法适合测试什么情况）

在程序中有数据输入的地方，适合使用等价类划分法测试

2、等价类划分法的测试思想

将大量数据划分成若干个范围（等价类），再从每个范围中挑选少量代表数据进行测试--抽样测试

3、有效等价类和无效等价类？

有效等价类--对程序来说，正确的、合理的输入数据集合--验证功能的正确性--正向测试

无效等价类--对程序来说，错误的、不合理的输入数据集合--验证软件的异常处理能力（健壮性）--反向测试

4、测试步骤

1、总结多种测试方法的基本使用步骤：

（1）分析需求，提炼测试点

（2）记录测试点

（3）覆盖测试点编写测试用例

2、等价类划分法的测试步骤：

案例：即时贴中的设置标题功能模块

  设置标题：设置便签的标题，要求

 （1）字符个数最少为1个字符，最多为40个字符

 （2）不能包含 / ： * ？这些特殊字符

步骤1:分析需求，列出等价类（先初步化分，再细化价类）

分析需求：字符个数应为1-40个，不能为空，不能包含/ ： * ？这些特殊字符

分析点1：不能为空

无效：为空

有效：不为空

分析点2：不能包含/ ： * ？

无效：包含/ ： * ？

有效：不包含/ ： * ？

分析点3：长度：1-40个字符

无效：<1个字符=为空,>40个

有效：1-40个字符

有效等价类：1--40个字符+不包含/ : * ?不为空

无效等价类：为空

 包含/ ： * ？（说明：应分别测）

 >40个字符

步骤2：在等价类表中记录测试点

步骤3：覆盖等价类（测试点），编写测试用例

要求：每个等价类至少要挑选一个代表数据进行测试，保证覆盖所有测试点，有特殊数据或情况可以挑选多个代表数据代表数据--normal

注意：（1）编写用例前应明确项目组对测试用例的模板和格式要求

关于该案例的总结和补充

1、问题：无效数据的组合测试

在每个无效数据都单独测试过的前提下，没有必要各种无效数据再都组合测试了，如果时间允许，可以利用错误推测的方法，对少量组合进行补充测试

2、补充测试方法：错误推测法（经验）

也叫错误推轮法，常用于补充测试用例，在测试程序时，测试人员可以根据经验或者直觉推测程序中可能存在的各种错误，从而有针对性的编写测试用例的方法

基本思想：列举程序中可能出现的错误和容易发生错误的情况，设计编写用例.

例：程序之前曾经出现过的错误、程序员容易出现的错误、用户经常会出现的错误操作行为，这些需要经验总结

实例：

1）数据为0的情况

2）空格

3）表格中的数据是只有1行或者0行时

4）网络处于弱网状态时

四、边界值法

一、边界值法说明：

在程序中程序员很容易在数据边界处理的代码中出现错误，所以针对容易出错的边界数据就出现了一种测试方法叫边界值法，边界值法是对等价类划分法的有力补充

二、应用场合

在程序中，有数据输入的地方也常常会使用边界值法，边界值法常常与等价类划分法配合使用：等价类划分负责划分范围测试，而边界值负责针对容易出错的边界数据测试，两种方法配合起来形成一套最为完善的测试方案

三、如何划分边界

1、边界值点（最小值min，最大值max）

边界值点就是有效等价类和无效等价类的分界点

2、次边界点左右两边相邻的点

无效最小次边界：min-

有效最小次边界：min+

有效大次边界：max+

无效最大次边界：max+

四、边界值的常见面试题：

Q1：如果测试时间紧张，应优先测试哪些边界值点？

如果测试时间紧张，应优先测试边界值点：最大值和最小值

引出问题：如果要重点测试健壮性，应测试哪些边界值点？

测健壮性就是要测无效的边界值，在所有的边界值中无效的是：min-：无效最小次边界max+:无效最大次边界

Q2：在需求中是不是所有的数据边界值在开始就已经确定了？

不是所有数据的边界值在开始就能确定，有的数据边界值开始就可以很明确，而有的数据开始时不能明确，需要在设计、研发过程中逐步明确。

五、等价类划分法+边界值法的综合应用

案例：信息注册

步骤1：分析需求->选择合适的测试方法->提炼测试点

姓名：等价类+边界值

有效：1-20个字符不能包含数字，不能为空

Max:20 min:1 min+:2 max-:19

无效：<1（为空） >20字符 为空 包含数字

max+ min-

步骤2：将测试点填入《数据分析表》中

步骤3：明确测试方案（思路），然后覆盖测试点编写测试用例

测试有效测试点：

先正向测试：就是功能的正确性，测试有效测试点（有效测试点=有效等价类+有效边界）

姓名5个（一个有效等价类+4个有效边界） 年龄5个（一个有效等价类+4个有效边界）

思路：将两个（多个）控件的有效测试点组合测试

编写用例1，2，3总共5个

再反向测试：测程序健壮性，测试错误数据（无效测试点=无效等价类+无效边界）

姓名：4个（3个无效等价类+1个无效边界） 年龄7个（5个无效等价类+2个无效边界）

思路：无效测试点测试应保证单独测试--由于屏蔽现象（一个弹框覆盖了另外一个弹框）会影响测试结果的判断，所以要单独测试每个无效测试点，如果每个输入框后面对每个的输入框有判断（成功或失败提示），可以组合测试

课堂练习：编写用例4,5,6,7总共11个

最后，利用错误推测法可以进行补充测试。 例如：数据0，空格等

六、总结测试用例

1.测试用例作用（了解）

2、编写测试用例的注意事项：

（1）编写用例之前应明确用例的模板，格式要求；如果带有附件，应明确附件的命名规范；

（2）要明确用例的提交位置

（3）用例需要评审

1）评审方式

交换评审、开评审会（内部评审会、外部评审会）

2）评审的细节参考；关于用例的评审

---

 用例的评审.Docx（了解）

关于测试中的评审在软件开发过程中的适当阶段对软件阶段产品进行评审，是确保软件产品最终质量的重要方法。阶段评审可以对某个开发阶段的阶段产品进行评审，也可以对某几个开发阶段的阶段产品进行综合评审。在每次阶段评审中，必须履行正式手续，填写必要的评审表格，以利于项目管理工作，利于产品验收时的质量检查工作。流程：

1. 主持人确定评审日期，参与评审人员
2. 评审前2天，测试用例发给所有评审人员
3. 评审人员记录测试用例问题
4. 评审会议，作者讲解用例，回答别人问题
5. 会议结束，修改用例，准备再次评审
6. 再次评审通过，用例基线化注意：如果是需求评审、设计评审等等会议，把以上步骤中测试用例改为相应的需求、设计文档即可

用例评审标注：

1. 用例设计策略
2. 用例覆盖率
3. 用例书写格式
4. 用例可读性
5. 用例可执行性

测试用例评审要点（一定要看）1.测试用例是否覆盖了所有需求.2.测试用例内容是否正确,是否与需求目标一致.3.测试用例内容是否完整,是否清楚包含输入和预期输出结果.4.测试用例是否具有指导性,是否能灵活指导测试人员通过用例发现更多缺陷,而不是限制他们的思维.5.找出哪些需求不可测：无法准备环境、可测试性达不到等等原因；6.对具体需求的实现结果的确认（设计人员、开发人员、测试人员的认识是否一致，如果不一致，谁说了算）；7. 测试用例本身的描述是否清晰，是否存在二义性8.是否考虑到测试用例的执行效率.往往测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗余性，都造成了效率的低下

参与该评审的人员包括：开发人员、系统分析人员、项目经理和相关测试人员