项目小结
从10月底进入项目，开始承担一个测试经理的角色，从测试策略到根据文档的每日功能测试、兼容性测试及回归测试，再到整个项目进行迭代后对测试文档的重新架构及整体回归测试，直至最后的统一交付测试，我个人提交总BUG数为103个。对整个项目的逻辑及架构逐步清晰，对项目之间所需的复杂交互的认识也越发深入，对项目功能逻辑上的测试如何进行也更加明晰以及如何在测试过程中把握测试进度和开发进行有效沟通尤为关键。 一、对项目的总结如下1.测试人员进入项目初期，开发人员有必要与测试人员沟通，帮助其理清整个项目的顺序逻辑。
2.建议测试文档撰写人员与测试人员最好不要是同一个人，并且要有评审的过程，这样有助于发现测试文档构建的漏洞。
3.撰写测试文档时，必须要经过方案设计评审，与客户充分沟通后实施，避免思路过于混乱，想到哪里写到哪里，导致最后文档难于维护和修改。
4.迭代开发过程中，测试基本上是项目改到哪就测到哪，这里面最大的问题不是发现修改模块的BUG，而是发现修改该模块后牵涉到的其它模块出现的BUG。在迭代验收过程中，测试人员不能放过验收标准的每一个点，并且项目做的是数据统计类系统，必须对数据有一个敏锐的直观，对于超出常识的数据要敢于进行质疑，并且验证。
5.迭代开发后期，开始对整个系统从头回归一遍，这时候又发现了许多以前从未出现的BUG。测试人员在测试后期尤其需要提高警惕，不能漏过任何一个功能点，更不能忽略任何一次貌似无用的查询、翻页、按键。
6.最后，是大家一起进行的交付测试，人员包括了所有的编程人员及测试人员。这期间，除了对基本功能的回归测试外，还包括了并发测试及性能测试（这主要是编程人员在做），除此之外，在开发过程中由于数据没有参考和对比，导致在给客户演示的时候出现数据和客户的不一致，使得演示中断，在交付比较紧张的情况下，对项目的压力就比较明显。所以这个验证数据正确性问题，需要在以后多加留意。 二、经验和教训
经验主要如下：
1、学会如何根据项目Demo及需求文档撰写测试文档；
2、学会如何用英文撰写文档，提交，验证问题；
3、学会如何理清项目逻辑，如何更深入地撰写文档并进行测试；
4、学会如何与编程人员沟通交流，获得解答，以便正确提交BUG；
教训如下：
1、撰写测试文档前没有理清业务逻辑，导致前期测试深度不够；
2、撰写测试文档时结构不清晰，导致后期难以维护和修改；
3、测试过程中心态有些浮躁，有些急于求成；
4、还没有形成测试思维，测试过程思维显得有些混乱； 谢谢分享~
页:
[1]
