测试用例是项目质量好坏的关键，测试用例不但要求覆盖率高，而且又不要出现冗余现象。
测试计划是项目开展的指南针，是保证项目按期完成的重要因素。
上面两句话虽然好像有些废话的架势，但是确实也是
软件测试用例和测试计划的核心所在。
接下来先说说测试用例，测试用例是在拿到项目spec后，根据spec中的scope，然后编写测试要点的验证步骤。
它的基本要素很简单，因公司、因人而异。但是只要能关键表达中心思想就行。但是也有一个规范要素：
用例编号：测试用例的编号有一定的规则，比如
系统测试用例的编号这样定义规则
： PROJECT1-ST-001 ，命名规则是项目名称＋测试阶段类型（系统测试阶段）＋编号。
定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。
测试标题： 对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如
“ 测试用户登录时输入错误密码时，软件的响应情况 ” 。
重要级别： 定义测试用例的优先级别，可以笼统的分为 “ 高 ” 和 “ 低 ” 两
个级别。一般来说，如果软件需求的优先级为 “ 高 ” ，那么针对该需求的测试用例
优先级也为 “ 高 ” ；反之亦然，
测试输入： 提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用
例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没
有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。
操作步骤： 提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要
分为几个步骤完成，这部分内容在操作步骤中详细列出。
预期结果： 提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。
如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之
则测试通过。
软件测试用例的设计主要从上述 6 个域考虑，结合相应的软件需求文档，在掌握一
定测试用例设计方法的基础上，可以设计出比较全面、合理的测试用例。具体的测试用
例设计方法可以参见相关的测试书籍，
白盒测试方法和
黑盒测试方法在绝大多数的软件
测试书籍中都有详细的介绍，这里不作赘述。
我主要想说的是每个阶段的把握，所以在测试用例编写完成后，一定需要发出去给相关人员review，目的是：
1. 保证你的测试用例全面覆盖了需求
2. 你的测试用例的有效性
3. 可以摆脱你将来的责任（如果软件将来出现问题，只要不是在你测试的scope范围，责任将由开发，测试人员各担50%。如果没有review，责任将由测试人员100%承担。因为开发始终会觉得，有bug就是测试没做好）
测试用例的review一定需要正式邮件的形式，并且设定一个期限，如果没有得到回复测试人员将默认开发确认完毕测试用例质量。当然，口头或再一次发邮件友好提醒是应该做的。
关于测试人员自己怎么提高编写高质量的测试用例方法，需要自己多看一些理论书籍，白盒黑盒测试用例编写技巧啊什么的。这个需要在实践中不断练习，总结。总之，多总结很重要。
测试计划：
测试计划的重要性就不用说了。还有，我今天想说的不是它的具体每一个细节，因为它也是一个因公司而异，当然也有它的主要因素。但是我今天想强调的是，测试计划里一定要设置好测试目标，比如测试用例的执行率，测试用例成功率，blocker，critical，major，minor，trivial，performance
test,security testing等等。还有就是测试的启动条件和结束条件。只有明确这些项，才能保证项目不会没完没了。才能不被开发牵制着。否则他们什么都想给你测一通，不管质量有多差。实际上，测试是需要开发出来的质量满足一定条件才能开始的。而不是只要他们做完就是我我们的责任。
还有，测试类型的定义，这也是划分责权的关键，出了问题谁来担当。
将scope包括这测试计划里面，同时做好风险控制策略。
最后，又到review的阶段，这个真的很重要。原则上，我们的测试时间不是由开发来定，是测试人员根据测试需要来定义。很多开发团队会这样做，他们开发花了很长时间，结果临近release了，告诉你一个测试需求，让测试人员在几号前完成测试。这样的问题，根本不要理回他（如果你们的测试团队领导够牛逼的话），你依然按到他们给的scope里定schedule，忽略release时间，因为不是你的罪过。定出了的时间如果跟release时间出入很大。在review的时候把它作为一个问题提醒领导们。当然你可以给他们提供几套方案。
比如，你加班，加资源（注意，一定不要说这么简单，一定要出具体方案和计划，如果加资源+加班来保证项目按时完成的计划是什么？要具体化方案）。另一个就是砍掉部分scope，这个选择需要开发自己定。你不用担心。然后，在完成review后，形成最终的计划（过程要书面化，以保留证据）。解决完问题，就是你认真履行职责的时候了。
下一篇预告：规范的软件测试流程
