用例设计的着眼点
1、测试的依据是需求规格说明书，首先应根据需求规格说明书对软件进行需求分解，然后针对每个测试需求去编写相应的测试用例；
2、测试用例的编写时，应按照需求规格说明书的内容，设计合理的测试用例，同时更重要的是考虑不合理的输入情况；
3、除了设计各子测试需求的测试用例外，还应考虑业务流程测试用例，业务流程测试用例主要由各种以验证业务流程正确性为主的测试用例组成。
测试用例的必备要素
1、项目名称和模块名称
当前用例所属的项目及被测的功能模块。
2、测试用例编号：是由字符和数字组合成的字符串，用例编号应具有唯一性、易用性。作为测试用例的唯一标识，命名方式采用“测试类别简称-项目名称-模块名称-序号”。
举例：F-RSXT-ZJJL-001
F是功能测试用例的缩写（S-安全测试 P-性能测试）
RSXT是项目“人事系统”的简称
ZJJL是模块“增加简历”的简称
001是具体的用例编号
3、用例名称
测试用例的具体名称
4、预置条件
执行当前测试用例需要的前提条件，描述要执行该用例，被测目标须达到的状态，例如，用具备正确权限的人员登录系统。
5、编制者和编制日期
当前用例的编制人员以及编制用例的日期（格式为“年-月-日”）。
6、测试步骤：执行当前测试用例需要经过的操作步骤，需要明确的给出每一个步骤的描述，测试用例执行人员可以根据该操作步骤完成测试用例执行
7、预期结果：当前测试用例的预期输出结果，包括返回值的内容、界面的响应结果、输出结果的规则符合度等等。 在我们的测试培训中，有具体的功能测试实践课程，课程中会选择一个实际的项目，让学员亲身去体验整个测试的流程，包括测试计划
1、测试计划阶段：
理解测试需求，编写测试计划，并根据需求规格说明书，完成系统的需求分解；
2、测试设计阶段：
为第一步中分解得出的具体的测试需求，设计相应的测试用例；
3、测试执行阶段：
按照自己设计的测试用例，执行测试，并记录用例执行结果，提交测试过程中发现的缺陷；
4、测试总结阶段：
对测试过程中发现的缺陷进行整理分析，完成测试报告。
在这个过程中，每个环节工作产品的评审是由老师和学员共同完成的，其中问题最多的环节就是测试设计阶段，部分学员在上课时都会跟我说，“老师，设计测试用例好烦，为什么要设计测试用例，真正做测试项目时也要向这样设计测试用例吗？”我总是笑笑，很肯定的对他们说：“要的”。
软件测试也是一个工程，也需要按照工程的角度去认识它，即在具体的测试实施之前，需要我们需要明白我们测什么，怎么测试等等，也就是说通过制定测试用例指导测试的实施。
其实设计测试用例并不是想象中的那么复杂，只要条理清晰，有耐心，并掌握基本的功能测试用例设计方法，设计出好的测试用例并不是件复杂的事情。
培训中，我也发现其实有两类学员，一类是总抱怨要设计的用例太多，什么时候才能设计完成，就一直停留在阅读需求说明书的阶段，而不愿意动手去做；而另一类呢，则是不管结果怎样，我先开始着手做起来。很显然，后一种是收益较多的一类，因为只有自己去动手做了，才会发现事情的难易程度到底怎样，才会了解事情的本质，以及自己在哪方面有所欠缺，而且，也只有当你有了中间结果时，老师才会去帮你检查，指导你测试用例设计时存在的一些不足或欠考虑的地方。
什么事情不要只是去想，想着它有多么的困难和复杂，一切事情都有解决的办法，不管事情有多复杂，它也是一点一点完成的，夸张点说，我们应本着愚公移山的精神，等到过程中，说不定也就会有神仙来帮忙呢。
下面简单介绍下设计测试用例时的几个注意点：
测试用例基本准则
1、测试用例应具有代表性：能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作、环境设置等；
2、测试结果应具有可判定性：即测试执行结果的正确性是可以判定的，每一个测试用例都应有相应得期望结果；
3、测试结果应是可再现的：即对同样的测试用例，系统的执行结果应当是相同的。
====================================分割线================================
最新内容请见作者的GitHub页：http://qaseven.github.io/
