简述：用文字描述出系统测试时的操作步骤

　　好处：

　　 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）急于交付，弊端就是不能保证测试的覆盖率。

 本文由职坐标整理并发布，希望对同学们有所帮助。了解更多详情请关注职坐标软件测试之测试技术频道！