简述：用文字描述出系统测试时的操作步骤
好处：
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）急于交付，弊端就是不能保证测试的覆盖率。
