测试杂谈之测试用例

撰写测试用例（TestCase）是测试工程师基本的技能，但确实最容易忽略的部分。怎么算写好了测试用例，标准是什么？带着这疑惑，我们先来看看

 

一、是什么

是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。

包含不限于：测试用例ID、目的、前提、步骤、预期输出、后果等

二、作用

测试用例在测试中占据中心地位，结合实际工作，梳理了测试用例以下作用

• 测试用例写的过程也是梳理思路的过程，有助于提高覆盖率
• 反映出测试进度，例如通过测试用例 执行数量/总数 来计算进度
• 作为测试输出存档，方便回归测试，同时可以反复利用提高效率

三、怎么写

• 怎么设计（标识）测试用例，能够覆盖更全
• 怎么写测试用例，能够清晰高效

 

测试用例设计，书（软件测试）中提到两种方法；功能性测试（黑盒）和结构性测试（白盒）

1 功能性测试

1.1 边界值测试

1.2 健壮性测试

1.3 特殊值测试

1.4 等价类测试

1.5 基于决策表的测试

2 结构性测试

2.1DD-路径

2.2 基路径测试

 

功能性测试利用定义（文档、接口）去设计测试用例，结构性测试使用源代码作为基础，根据测试对象的特点，组合使用两种方法才能更好地覆盖测试用例；实际项目中，一般是先试用文档写测试用例，再通过对具体代码实现的理解和梳理出流程图，来补充和修改测试用例，最终输出一份“合格”的测试用例

 

下面聊聊如何写测试用例，首先，我们来看看测试用例主要组成结构：

 

项	注意事项
标题（名称）	通过标题能够大概明白测试点，尽量精简 书写格式可以自由定义，统一风格即可
描述	测试点的详细描述，相当于测试用例名称的详细版
前置条件	在操作前，系统需要达到的状态
操作步骤	如果有多个步骤，每一个步骤都需要填上序号，每一行一个步骤， 不能写得过于简略，至少要让熟悉过系统的测试人员可以执行，也建议不要写得太复杂
预期结果	如果有多个检查点，需要都罗列出来，每一行一个标号， 让人一目了然有几个结果检查点，和操作步骤可以一一对应上

实际项目中，无法统一要求测试用例的标准，通常要求书写格式正确、描述清晰， 其他测试人员拿到测试用例可以在不询问写作人的情况下正常执行下去，就算一份合格的测试用例

 

 

还有一个话题“测试用例评审”，后续再总结