接口测试用例模板_【笔记3】测试计划/测试用例

软件测试的第二阶段——测试计划

定义：叙述了预定测试范围（哪些模块），测试资源（软件、硬件），测试进度安排。确认了测试项，被测任务，人员安排风险分析。

包含了产品概述，测试策略，测试方法，测试范围，时间安排，测试人力，风险分析。

为什么编写？Why

1）使软件测试工作顺利开展。一开始给出测试计划，为整个测试工作指明方向，大家知道该怎么进行，每个人具体干什么，什么时候开始。

2）促进整个项目团队的彼此沟通。测试人员了解整个项目情况和具体每个阶段的工作，使得测试和开发人员能够配合默契。

3）领导层面上软件测试工作更加易于管理。根据测试计划领导可以控制产品节奏，宏观调控，保证产品能够按照预期交付。

什么时间写？需求澄清后，大家对自己的负责内容清楚，尽早写。

谁来写？经验丰富的项目负责人或者测试负责人。一般分三个层面的编写：项目经理、测试经理、测试人员。

——测试计划的编写原则

1.尽早开始。需求完成后尽早开始，从根本上了解测试对象和内容，不能确定的点可以预估，后续进行完善。

2.简洁+易读。保持计划的简洁，易理解，让测试人员明确自己的任务和计划。

3.评审。尽量争取多渠道评审测试计划，发现计划中的缺陷和不足，更好改进。

4.计算测试计划的投入。项目的经费是一定的，制定计划要注意投入，量力而行。

——测试计划文档（测试经理层面）

3种详细程度不同的模板，掌握中间版的。

---

测试的第三阶段——测试用例设计与管理

——测试用例编写原则

1.系统性。对系统业务流程，完整说明整个系统的业务需求，子系统及之间的关系，子系统内部的功能和关系。

2.连贯性。各个子系统如何连接在一起，如果有接口，子系统的接口是否正确，若有页面链接，跳转是否正确。

3.全面性。尽可能覆盖各种途径，各个业务点，考虑大数据并发测试，若有特殊数据，列出特殊数据。

4.正确性。输出结果与测试文档记录数据一致，预期结果也应该与业务吻合。

5.符合正常业务规则。符合用户实际工作的业务流程，同时兼顾业务变化及当前行业规律，法规。

——测试用例编写标准

1.根据公司统一的模板写（Excel，Textlink），对于特定内容元素不能删除。

2.根据企业要求编写测试用例，有侧重点的编写（业务场景）。

3.严格按照需求说明书功能点，功能点覆盖全面。

4.（重点）逻辑清楚、精简，不冗余。

5.避免重复的功能点多次写。

6.业务逻辑场景的要将各个业务场景整理出用例，并进行评审，确保用例的正确性。

7.全面性，测试用例应包含正确数据，非法数据，特殊数据。

8.（重点）需求变更或者理解错误的点，及时更新用例。

高质量的用例：1.效率高。2.覆盖面广。3.结构关联强，不冗余。4.归纳总结到位（合法、不合法、特殊，按照特点来）。

用例优先级划分（1-4）：1-Critical极重要，不允许出错。2-Important重要，核心业务。3-Generic一般。4-Low低级，一般是UI层面的，不影响功能。

用例实例：用例编号-模块-场景-用例名称-前提条件-测试等级-操作步骤-预期结果-实际结果；

测试点梳理：利用Xmind工具，从外到里拆分，先梳理测试点再写用例，覆盖度高。

——testlink使用说明

1.测试项目管理：创建、查看已经建好的项目，修改

2.右上角测试产品：选择项目

3.左下编辑测试用例：过滤器功能类似查询，点击设置图标是测试用例集的操作，是一个目录，一般建议3层目录即可。

4.写用例：名称尽量精简，摘要可以详细写，关键字不用，创建步骤时可以写成一个连贯的测试用例，每个步骤结果分别写出来。

——测试用例评审

为什么要评审？由于大家在初期对需求，设计等理解程度不同，导致首次设计的用例不可避免有问题，评审很必要，开发和产品帮助测试完善用例。

目的：用例结构优化，场景覆盖全面，优先级安排合理。

评审内容：

1.设计结构清晰合理。

2.优先级合理。

3.覆盖需求所有功能点。（业务+流程+场景+功能）

4.可执行性。前提条件，执行步骤，预期是否正确。

5.全面性。合法，不合法，特殊是否均考虑了。

6.简洁美观，易于管理（维护，参考）

评审会议（测试发起）

部门评审：测试部门全体成员参与（更重要）

项目评审：项目组全体成员

内部评审：开发、产品、测试

流程：测试人员讲解，参会人员给出建议、意见，并记录，根据会议记录修改用例出最终版本。

——测试用例设计方法

1.等价类划分法：将输入划分为若干个等价类，从等价类中选择一个测试用例，若该用例通过，则该等价类通过。

适用场景：无限种输入，无法穷举。

划分为：1）有效等价类 2）无效等价类

设计用例时，一条用例尽可能覆盖多的有效等价类，一条用例只覆盖一个无效等价类。

2.边界值分析法（一般和等价类一起使用）

基本思路：从等价类的边界值去寻找，上点（刚好等于），离点（刚好大于或者小于），内点（内部的值），0是特殊值。

测试文本框应该考虑的维度：1）长度； 2）类型；3）组成规则；4）是否为空；5）是否前中后空格；6）区分大小写；

3.场景法

尽可能模拟用户的真实操作，基于1）业务需求层面；2）技术层面，结合等价类

核心概念1）基本流（正确流、有效流）：模拟正确操作，1条。2）备选流（错误流、无效流）：模拟错误流程，N条。

步骤：1）构造基本流、备选流。

2）根据基本流、备选流构造场景。

3）根据场景出用例。

4）给用例补充测试数据。

4.判定表

定义：输入、输出相互之间逻辑关系多，利用该表整理逻辑关系，条件之间不存在制约关系。

概念：条件桩-所有的输入；

条件项-针对条件桩可能输入数据的真假值；

动作桩-针对条件，被测对象可采取的动作；

动作项-动作桩响应的取值；

规则：动作项和条件项组合，形成业务逻辑规则。

步骤：1）理解需求，确定条件桩，动作桩；

2）设计、优化判定表；原因数n，则组合数=2的n次方

3）填写动作项；

4）根据判定表输出结果，合并判定表（非必须）；

合并原则：输出相同，在对应输入中，有且只有一个条件的取值对动作不产生任何影响，即可合并。

判定表快速画法举例：5个条件桩，则有2的5次方32种情况

第一行填16,1，16个0；第二行填8个1，8个0,8个1,8个0；第三行4个1,4个0,4个1,4个0；第4行2个1,；2个0；2个1,；2个0；2个1,；2个0；2个1,；2个0；2个1,；2个0；2个1,；2个0；2个1,；2个0；2个1,；2个0；2个1,；2个0；2个1,；2个0；第5行1个1,1个0……

5.因果图（Cause-effect Graph）

定义：描述输入条件的组合以及每种组合对应的输出的图形化工具。与判定表配合使用。

使用场景：输入条件之间有约束关系，逻辑关系复杂。

因果符号：恒等、非、或、与

原因符号：异，或，唯一，要求

结果符号：强制

因果图的符号

6.错误推测法

定义：根据直觉或经验，推测程序中可能存在的错误，从而设计用例。

7.正交实验法

优点：均匀分散，整齐可比

定义：研究多因素，多水平的一种试验法。

使用场景：所有的数据都是有效数据。