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的类型（性能、功能、设计问题）必要时也需要进行分类，然后可以结合其他系统的问题，进行汇总分析，可以得出其他一些结论，如设计考虑不全面、程序思路不够清晰等等
13. 当系统有调整时，需要体现到用例上去，而不是用例执行过后就不管了，另一方面也需要敦促策划更新策划案
Ps：我有个习惯，喜欢问程序实现机制或者bug出现的原因。沟通方式一般都是跟程序聊天时，让他们给我介绍他手头上的活的思路，听他们说完，我会以测试的角度问一些问题，经常程序会一拍脑袋说，我靠，这问题还真没考虑。到了功能开发的差不多时，我会过去，坐在程序的电脑前，大概的玩玩新开发的功能。
这样有几个好处：
1. 可以进行缺陷预防，从根本上杜绝一些bug的出现。作为程序员，当他们开始开发某个系统时，如果自己都无法跟别人描述清楚自己的思路，那么他自己的思路肯定也不会很清晰，因而，跟人复述一遍自己的思路，既能让自己的思路更加清晰，也说不定能在复述的时候，能够发现一些自己考虑不足的地方；作为测试员，也能够从测试的角度提一些问题，避免一些bug的产生。
2. 对于测试来说，了解程序的实现机制，能使自己理清思路，测试有重点、有针对性，设计的测试用例，也能覆盖的更全面
3. 可以通过听他们的叙述，评估这个系统的可靠性。比如bug的修改，如果程序跟你不确定的说，大概是咋咋造成的，那么你在回归这个bug的时候，就需要注意了，因为程序自己都没底；再比如程序设计系统时，步骤多，存储过程复杂，那设计用例时就必须多考虑异常情况
4. 一些bug出现后，能在版本提交前被发现而马上解决掉，减少跑流程耗费的时间；
5. 可以更有效的掌握程序的开发进度；
6. 节省时间，提高开发效率；
7. 可以帮助程序员提交代码质量。
沟通前需要做的工作：
1.对于一些基础的开发知识，需要了解，不然有时听不懂对方在说什么；
2.对于工作经验要时常总结，才能对他们的叙述给出有用的反馈或者自己能通过这些叙述得出一些需要注意的关键点；
3.沟通时机需要选择，最好是闲聊时或者看程序不忙的时候，因为集中精力工作中，大家都不喜欢被打搅；
4.总结、分析各个程序员的编码习惯，得出该程序员常犯的错误。
到了后来，他们都会主动跟我说，他想咋咋实现，让我帮他们用另外的角度看看这样的方案有没有什么漏洞，需要注意些什么，特别是开始一个比较大的新系统时。到了开发的差不多时，会让我过去帮他看看有没有什么问题，有问题能马上处理。
