当根据客户的需求整理出项目需求分析文档时，我们就可以根据需求文档来编写测试用例了。但是，有些情况客户提供的项目需求文档非常“简陋”，很难根据需求文档设计测试用例。
我们只有等到项目开发人员把项目开发出来，给我们系统文档、部署环境、数据库结构（如果系统牵涉到数据库的话），我们根据这些文档来设计测试用例。
我们设计的测试用例设计完成之后，是否完整？是否符合系统？是否符合客户要求？对用例做一个评审是必不可少。关于评审的方式，不同的公司有不同的流程。
我们编写的测试用例也不是经过评审之后就不变了，随着需求的变更、功能的改进，测试用例当然也需要更新和变动。
文件时间
如果一个功能我很快就测试完了，而且只需要测试一遍，但我们设计测试用例时却比较麻烦，花时间也长。这个时候就没必要编写测试用例了。
需求变动大且频繁
需求的功能变动非常频繁，而且变动很大，之前编写的测试用例根本没法使用，必须要重新编写，这个时候也没必要去设计测试用例了。
项目时间不允许
这一项是不太厚道的做法，如果不是急需交付客户的话，尽量不要这样做；当然了，如果只是给客户展示或试用，可以在之后进行补充和完善测试用例。
语句覆盖最低不能小于80%，测试需求覆盖率达到100%，测试用例覆盖率达到100%，一、二级缺陷修复率达到100%，三、四级修复率达到80%。
bug等级：
一级：非常严重的bug
二级：严重的bug
三级：一般性的bug
四级：建议性问题
1. 我们让软件做的它必须会做。
2. 我们不让软件做的它必须不会做。
可能你会发现有附加功能的时候，就是客户没有要求，我们加了这样的功能，可能加了这点功能系统看上去会更好。这时怎么办？算问题么？作为开发人员，中规中矩的做东西最好，如果真的有非常好的功能要加的话，需要和客户沟通，然后写到需求里。作为测试人员，凡是不符合需求文档的都需要当问题点提出。责任分明，以免后续麻烦。
信息来源：51testing
