源作者:迅速fast
好的测试是用少量的测试用例运行程序 测试工作的最核心的模块，在执行任何测试之前，首先必须完成测试用例的编写。测试用例是指导你执行测试，帮助证明软件功能或发现软件缺陷的一种说明。
进行用例设计，需要对项目的需求有清晰的了解，对要测试什么，按照什么顺序测试，覆盖哪些需求做到心中有数，作为测试用例的编写者不仅了解要有常见的测试用例编写方法，同时需要了解被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构。
测试需求分析：从项目部拿到软件的需求规格说明书后，开始对项目的需求进行分析，通过自己的分析、理解，整理成为测试需求， 清楚分析出被测试对象具有哪些功能。 明确测试用例中的测试集用例与需求的关系，即一个或多个测试用例集对应一个测试需求。
业务流程分析：分析完需求后，明确每一个功能的业务处理流程，不同的功能点作业务的组合，以及项目的隐式需求。如遇复杂的测试用例设计前，先画出软件的业务流程。从业务流程上，应得到以下信息：
A、 主流程是什么?
B、 条件备选流程是什么?
C、 数据流向是什么?
D、 关键的判断条件是什么?
测试用例设计
完成以上两步则可进行测试用例设计，功能测试用例，应尽量考虑边界、异常、性能的情况，以便发现更多的隐藏问题。
设计测试用例的常见方法：1)等价类 2)边界值 3)因果图 4) 判定表 5)数据迁移 6) 正交实验 7) 场景法 8) 错误推断(注意：编写测试用例时，我们尽可能取的不应该是有效等价类而应该是无效等价类)
怎样的测试用例才算是一个良好的测试用例 编写完成后自我检查以及部门内部评审：
测试用例本身的描述是否清晰，语言准确;是否存在二义性;
测试用例内容是否完整，是否清晰的包含输入和预期输出的结果;测试步骤是否清晰;
测试用例中使用的测试数据是否恰当，准确;
测试用例是否具有指导性，是否能灵活的指导软件测试工程师通过测试用例发现更多的缺陷，而不是限制他们的思维;
是否考虑到测试用例执行的效率。对于不断重复执行的步骤，是否保证了验证点相同;或者测试用例的设计是否存在冗余性等。这些都可能导致测试用例执行效率低下;
画出软件需求跟踪矩阵，验证测试用例是否完全覆盖了需求，验证测试用例的覆盖性;
测试用例是否完全遵守了软件需求的规定。这一点其实有一些难做到。考虑到时间/成本的关系，应该视具体情况而定。
测试用例更新完善
测试用例编写完成之后需要不断完善，如遇需求更改或功能新增时，测试用例必须配套修改更新，同时在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善;在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善。
