7. 汇总以往出现过的严重或典型缺陷，在该项目验证

　　每一次较大型的发布，都让测试人员颇为担心，害怕出现遗漏bug，但是总会有未考虑周全之处，每次大型发布之后，或是被公司内部的人发现或是被我们的用户发现，我们需要对以往的经验进行总结，汇总出以往项目从眼皮底下溜走的bug，他们发生的原因及如何避免，这些都是教训及经验谈。在这个项目中，一样是把之前遗漏过的bug告诉大家，一定多加注意。

　　8. 进行每日项目会议，掌握项目进展情况

　　每天抽出半小时，把大家召集到一起，了解每个人的进度，遇到的问题，让大家积极发言，进行头脑风暴，这个时候的碰撞往往能事半功倍，我也会把我自己的想法告诉给大家，哪些功能间需要加强协调测试，比如在UI上有交互的，在某一个标签处显示2个内容而恰好属于不同人测试，在数据上都有读取或修改的，让功能间有依赖的人多沟通，测试时多考虑相互间的影响等等，会上统一集中的帮助大家解决问题或提供解决问题的思路。我觉得每日会议可以让大家更像一个团队作战，而不是单打独斗，各干各的，最后乱成一团糟。

　　9. 注意风险控制，了解缺陷影响范围

　　项目越往后，bug数量越收敛，而给我们最大的障碍可能就是我们不够了解缺陷影响范围，不懂得回归bug时还需要测试些什么，这却正是测试新人最大的挑战。仅仅是测试bug里说的这情况吗？大多数时候肯定不够，老生长谈如何判断功能间的依赖：

　　1. 有关输入：这些功能会不会处理同样的输入？

　　2. 有关输出：这些功能会不会在界面上显示在同一个区域？会产生同一个输出吗？

　　3. 有关数据：是否会操作同样的数据？是读取还是修改？

　　如果上面三点中有一个答案是会，那么他们之间肯定就有依赖！

　　同样，你也可以通过咨询开发人员，这个bug改动会影响到哪些地方，对于熟悉公司业务及代码的人来说，也可以通过diff两个版本间代码差异获得答案。

　　10. 合版后明确回归范围

　　这里的回归跟上面的回归其实是有差异的，因为上面的只针对bug而言，这里的回归就涉及到该产品其他正在进行的项目内容。因为公司进行多个项目多个分支并行开发，在进行该项目时，有别的项目已完成并发布上线，那么该版本发布前需要合并这些项目的代码。有些情况下会出现未正常合并或合并过程中未正确处理好冲突，或在业务需求层面上就有相互影响的情况，这就需要有针对性的进行回归。

　　对于未合并的，让对应项目参与者运行下冒烟的case就知晓结果了；对于有冲突的，让合并代码的开发人员告知冲突的代码功能是什么，在业务流程回归之外重点关注下对应的功能；对于业务层面，就需要对每个项目内容充分熟悉了解影响到的地方，明确需求具体内容，触发条件，处理过程及结果，有侧重点的进行验证。

版权声明：本文出自 zzzmmmkkk 的51Testing软件测试博客： http://www.51testing.com/?258885

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。