1、先对策划案进行分析，也可以组织进行评审，主要以下几个方面进行，输出是新的策划案：

　　　　a）需求描述是否具备完整性；（没有遗漏内容；或描述片面）

　　　　b）需求描述是否有二义性；（没有让不同的人有不同的理解结论）

　　　　c）需求描述是否是正确的；（需求之间没有冲突等）

　　　　d）是否包含有非功能属性的需求；（性能，安全性，可靠性，易用性等）

　　　　e）是否需求是可以验证的；（需求描述具备可测试性）

　　　　f）需求是否可实现；

　　　　g）判断需求的必要性

　　2、编写用例之前，先跟负责该系统的程序沟通一下，让他说下对于整个系统，他的大概思路，主要逻辑是什么，需要增加什么配置，数据存储方式等，有利于对系统了解更深刻，用例也能全面一些，而且程序通过叙述，也能梳理思路，并发现一些问题

　　3、根据之前的了解，分析整个系统，细分功能点，得出测试分析文档，主要列出功能点细分、重点难点、风险点，以及一下测试需求，包括人力需求、时间需求、log需求、gm指令需求、配置需求等，以便于输出用例和进行测试准备。也不一定得有文档，但脑子里应该清楚这些

　　4、用例初稿写好后，邮件发给大家，让大家帮忙看看有没有什么遗漏，让策划看看预期结果是否跟需求一致等，根据大家的反馈，完善用例，必要时可以对用例进行开小会评审

　　5、如果有条件，在用例完成后，丢给程序一份，让他们读读，能减少很多问题的出现

　　6、模块提交到测试这边时，可以先和程序沟通一下，进行风险分析，从风险发生的概率，风险产生的影响两个角度对风险进行打分评级，对于风险系数高的部分作为后期的测试重点，并配置针对性的测试资源和测试方法

　　7、用例的设计和执行，需要关注模块间交叉的异常检查

　　8、用例的执行，在执行过程中，发现一些在用例上未体现的检查点，需要实时补充

　　9、执行完用例后，可以测试组成员间交叉进行用例执行

　　10、执行结果出来后，检查发现的bug是否能在用例上一一对应，发现有未对应上的bug，就说明用例遗漏了检查点，需补充

　　11、整个系统测试完毕后，把一些比较重大的bug，添加到对应检查项后面，警示下次跑用例时这些需要着重关注，也可以当作一次总结；

　　12、对bug的产生原因、修改方式应该很清楚，对bug的类型（性能、功能、设计问题）必要时也需要进行分类，然后可以结合其他系统的问题，进行汇总分析，可以得出其他一些结论，如设计考虑不全面、程序思路不够清晰等等