『测试基础』| 如何理解测试用例管理和缺陷管理？

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：
  
• 缺陷的创建：
  
• 一个简单的缺陷流程：
  

代码007普通

打赏 收藏 海报 链接