分享一个我写测试用例的方法

mallybel

1.用例模板：
很多公司也有专门的工具管理，我们是用excel管理有两套模板，应对大小项目也有用户专门指定要用什么模板，不过主要的内容都一样。
用例模板根据项目客户的需要有可能会采用不同的模板，编写用例人员只要遵守用例模板中的填写格式进行编写即可。
1）控制页

控制页一般包含统计信息、修订历史等。

统计信息：用例编写人员在同一个excel模板中追加sheet页或者在一个sheet页中删减表格时注意对本页的统计项和汇总统计页中的公式是否有影响，确保公式的准确。

公式一般是统计用例测试项总数、测试通过个数和测试不通过个数。

修订历史：记录每次主要修改了什么功能，新增了什么功能，方便后续跟踪、防止遗漏修改项。

2）用例正文

sheet页和行数控制：

每个功能模块可以写一个sheet页或者根据功能涉及的页面多少可适当增加sheet页。一班sheet页可以是1~3个，一般一个页可以写200~500，根据个人感官。如果觉得上下滚动查看不方便可以增加sheet页，把功能合理分割成几块写也可以。

用例包含的要素：

一般包含用例编号、对应的需求编号、步骤编号、模块路径、前置条件、准备数据、用例描述（测试项）、测试步骤、预期输出、测试结果、严重等级、现象描述和子用例统计信息；

模块路径：一般用例划分为一级、二级功能模块。

一级功能模块：

每个模块构思用例时，在第一层架构上，建议先从最主要的基本功能入手，如：新增、修改、删除、查询、查看、打印、导出等依次划分，把这些常用的基本功能提到整个用例的前面。然后按页面从上到下、从左到右遍历页面上每个功能、划分出需要测试的大块，形成测试用例的骨架。

二级子模块：

在第二层细分时，需要加入优先级概念，要求每个功能分功能类（主要功能、次要功能）、业务类、表单类测试项。 主要功能是指每个功能是要实现什么的，这个作为此功能优先级最高的测试项。次要功能，是只不常用但系统也提供的功能。业务类功能指与其他模块直接间接的关联，按业务影响度划分优先级，一般优先级为中或低。表单类测试是指针对页面控件类型进行操作合法性校验，例如字符类型、长度等，每种控件都有自己的基本测试方式，请参考主要功能及通用规范.doc。网上也有很多分享的。

前置条件和准备数据：

用例中每个款项都应该能够在不参考前后用例说明情况下独立进行测试，这就要求在写用例时对前提条件进行说明，要在什么条件下才能开展此项测试。大部分情况下，只要测试项描述中说明要测试什么东西，有经验的测试人员就应该知道怎么测试，这时候就不必用例编写人员花时间在写前置条件和准备数据上。但考虑到测试人员水平的不同，稍微复杂点的情况还是需要说明一下，让90%的人都能看懂。

测试步骤和预期输出：

参考前置条件和准备数据的编写说明，如果测试项描述的够清晰，一般测试人员都知道怎么测试，再时间充裕时用力中的测试步骤和预期输出都需要填写，如果对用例要求不高或时间不充裕情况下可先不写测试步骤和预期输出，之后再补上。

写测试步骤和预期输出是提交缺陷、重现缺陷的前提。

注：

1）测试用例设计方式和思路最好全员统一，这样大家在看别人的用例的时候效率会很高。

2）会“写”用例很重要。有的人对写用例很不以为然，懒得动手写。锻炼出一手好用例，可以把你的思维塑型，在测试规划上有条理。等能力上来了，即使不写出来也会在脑海里形成清楚的测试思路。这就是为什么我会要求经验少的人多写用例。



用例评审
方式一：严格执行评审过程

需求的新增或更新测试人员都需要进行用例维护，更新测试用例后需要发起用例评审会议，邀请相关开发和测试人员共同评审。评审前后用例的状态（尚未评审、评审通过、评审不通过）和评审意见和日期也需要更新。

方式二：交叉评审。

测试人员之间互相检查。

方式三：不评审直接使用。

这一方式适用于用例编写经验丰富的员工，给予此员工足够的信任，由员工自己评估用例是否达到最高覆盖率。



怎样才能设计出覆盖率高、思路清晰的高质量用例？

以下给出几点建议：

1.测试人员不应该被“被测软件”的领域所限制，拿到一个功能应该就能利用自己的经验进行梳理参透。用例设计方法都是互通的。一般用例可以分功能类、业务类、表单类，其中功能类的要占80%左右、业务类的10%左右（知识说这块的知识，不代表用例编写篇幅的多少），需要用到专业领域知识的测试项不会超过10%。所以最主要的还是要研究测试方法、研究通用测试用例。

2.业务类和专业领域的知识涉及的少，但是不代表不用测呀。如果流出了此类bug，只能说测试经验不足知识不够，所以吃透被测软件的需求也很重要。设计测试用例的时候对场景的假设也很重要，业务知识不够，很可能有考虑不到的场景。多积累经验会拓宽测试人员的思维，提高对任何需求可能造成缺陷的敏锐度。专业领域的知识，例如医疗、土木建设、硬件、网络、移动、PC、BS\CS等，有很多专业的术语、特定的环境，如果是这类的被测系统，拥有对口的知识当然没有难度，如果没有就要临时抱佛脚，利用各种资源多问、多学。

3.还有一类测试项，其实也算是经验不足、考虑不周比较偏门（俗称冷知识）的测试遗漏。例如，我们之前在测试手机号输入规则的时候采用了等价类划分法对现有的号段进行了符合测试和不符合测试。但是漏了一种工信部新放出的新号段，用原来的验证规则，新号段的手机号就保存不了，所以以后再测试的时候追加了此测试项。

4.要快速的掌握测试用例的编写方式，还要多看别人写的。也许觉得别人写的不好，那我以后就不会犯同样的错误，也许觉得别人写的好，那我写的时候就直接copy。