1 测验用例界说

• 测验用例（TestCase）为测验对象编制一种测验输入、履行条件和预期成果；
• 用例能够表现测验方案、方法、技能和战略；
• 用例的内容一般包含：

# 测验对象名称
# 测验项
# 测验目标
# 测验环境
# 测验输入
# 测验步骤
# 预期成果
# 测验脚本等

• 往常咱们最简化的测验用例至少应该包含测验输入和预期成果。

2 测验用例规划准则

• 测验用例应覆盖三类事情：

# 1、根本事情：依据需求需求完成一切功用的测验用例，覆盖率到达100%；
# 2、备选事情：程序履行中的备选情况；
# 3、异常事情：程序履行出错处理的路径。

• 运用等价类划分法完成根本测验用例，将无限测验变成有限测验；
• 运用鸿沟值发现程序或许呈现过错的鸿沟问题或临界条件；
• 运用过错推断法追加一些测验用例，这个和一些经验有关；
• 对照程序逻辑，检查已规划测验用例的逻辑覆盖程度；
• 关于有输入条件的测验用例，在开始时应选择决策表驱动法和因果图法；
• 关于参数配置类软件，应采用正交实验法规划用例；
• 关于业务流程清晰的体系，可采用场景法规划用例。

3 测验用例的评定

评定的关键，能够分以下内容：

• 是否覆盖了测验需求的一切功用点？
• 是否覆盖了一切非功用性测验需求？
• 测验用例编号是否和测验需求对应？
• 测验规划是否包含了正面和反面的测验用例？
• 是否清晰了测验特性、步骤、履行条件、预期成果等内容？
• 是否包含了测验数据、测验数据的生成办法？
• 是否具有可操作性？
• 优先级组织是否合理？
• 是否删除了冗余的测验用例？
• 用例规划的是否简练？是否复用性强？

4 测验怎么保护？

一般情况下咱们需求对测验用例进行保护更新，更新的点有：

• 废弃的用例怎么处理？
• 因需求的变更，用例的标识和需求的标识是否对应？
• 经过屡次迭代测验，用例的优先级履行是否需求更改？
• 用例的规划场景是否需求完善？
• 用例的履行人员是否设置合理？
• 用例的版本更新等。

另外，为什么需求更新保护呢？原因有下：

• 测验过程中发现用例规划不全，需求进行弥补完善；
• 软件交给后反响了软件问题，而这些问题恰巧在测验时并没有发现，需求对这些缺点弥补相关的用例；
• 软件的更新，导致需求有所变动，需求更新用例等。

5 用例的作用

• 发现和盯梢软件缺点；
• 更精确的反响软件的某一个特性；
• 反响软件的功用和质量；
• 清晰毛病责任等。

6 用例办理东西

• 用例办理的东西有许多，比方

1、PingCode；2、TestRail；
3、TestLink；4、Jira；
5、PractiTest；6、PractiTest；
7、Zephyr Enterprise；8、MeterSphere；
9、Bugzilla、10、ZenTao

• 咱们这里来举个例子，比方禅道（以下为举例，仅供参考，详细的东西运用仍是需求依据团队和项目的规模和工作模式来选择）：

  

  用例的创立根本包含了许多常用的字段：

  

• 用例履行，一般要阐明这个用例履行的情况，比方失利仍是经过等等：

  

• 大部分渠道也能够对用例进行相关bug、相关需求、相关项目等等，有的是针对项目规划用例，有的是直接用例库中进行规划，需求的时分能够进行相关操作等。

7 缺点关注的要点

• 以下是列出了缺点需求关注的一些部分要点字段，当然不止这些：

8 缺点剖析

咱们需求对缺点进行统计剖析，比方以下：

• 缺点的主要分布模块；
• 缺点发生的原因；
• 依据已知的缺点，剖析或许发生的缺点模块；
• 依据缺点的发生，剖析软件的质量情况；
• 依据提交缺点，剖析测验人员的技能提升点；
• 依据缺点修正的程度，剖析对应处理人的缺点处理质量情况等。

9 缺点办理东西

• 之前说到的用例办理东西相同适用缺点办理：

1、PingCode；2、TestRail；
3、TestLink；4、Jira；
5、PractiTest；6、PractiTest；
7、Zephyr Enterprise；8、MeterSphere；
9、Bugzilla、10、ZenTao

• 咱们看个东西吧，比方TAPD：

  

• 缺点的创立：

  

• 一个简单的缺点流程：