测试用例优先级划分_理论第一篇：说说测试用例

这里有爱，有分享，有工程师们的成长日记，点蓝字“软件测试面试汇总”进行关注,微信公众号TestMadman

---

用文字描述出系统测试时的操作步骤，或许有些帮助

 

好处

1)清晰思路、避免遗漏

当系统功能多且复杂时，根据系统每个模块，拆分功能点，花点时间思考并整理成文档，尽可能结合功能与业务，模拟不同场景，从根本上避免了直接测试系统的“手忙脚乱”。

2)明确测试进展

参考测试用例，可以清晰看到哪些用例执行了，哪些用例没有执行，从中看到测试进行到哪一步，以及结合问题管理平台，直观地从测试角度，分析项目进展。

3)系统模块缺陷率

根据测试用例发现的问题，可以看到哪个功能模块出现的bug较多。

 

方法

1)等价类划分：输入的子集中选择，假如输入要求输入数字1到10，那么输入4和7去验证；

2)边界值：输入支持的最大值，假如一个文本输入框最大值为100，输入的内容超过101；

3)因果图：判定表，通过因果关系判定；

4)错误推测法：基于测试经验推测系统在什么样的操作可能会出现错误；

 

元素

1)目录

根据拆分的系统功能点，每个功能点可以用目录的方式区分，如一个系统的系统管理-用户管理-用户添加，那么系统管理就是一级目录，用户管理就是二级目录，用户添加就是三级目录；

2)测试项

同上，根据三级目录，一般用户添加包括的元素有用户名、密码输入框、保存按钮、取消，那么每个元素都可以分成一个测试项；

3)操作步骤

每一个测试项，都对应相应的操作步骤，可以分成操作步骤1、操作步骤2，操作步骤可以细化到，点击添加用户的按钮、输入框输入某某用户名密码点击保存按钮；

4)预期结果

操作步骤，在完成一系列动作之前，都要有对应预期结果作为参考，这个参考就是最初业务部门提供的需求分析文档，根据需求分析文档来告诉我们每一个功能要有什么样的结果；

5)实际结果

操作步骤，完成之后，需要记录实际的情况，如果与预期结果不符，就可以归于bug；

考虑是否可以将实际结果改成注释，避免与预期结果一一对应关系，解耦合。

6)优先级探索性测试

在设计测试用例时，并不能完全保证每个功能每个场景都设计到位，而且单纯执行测试的时候非常枯燥，那么加入一点发散性思维，进行一些非常规性操作，以用户的心态去使用系统，或是尽情地“破坏”系统，发现系统的问题。

真正的探索性测试需要对产品的深入了解，以及软件开发技术有一定的深度和宽度。

用例评审

测试用例编写完成后，需要在测试内部进行一次评审，评审的内容包括：功能是否完整、需求是否符合，使每一个测试人员在系统测试过程中，不存在主体思维的偏差。

同时用例评审也是一个很好的学习过程，每一位测试人在介绍系统时，能够意识到各自设计用例时的不足，包括自动化、性能都可以进行技术的探讨。

不需要用例情况 1)功能过于简单

2)急于交付，弊端就是不能保证测试的覆盖率。

快，关注这个公众号，一起涨姿势～

一起成长，一起分享，希望能对您有所帮助，我们是TestMadman,期待您的关注。