回归测试的挑战

你们做计划的时候能不能重视点测试啊？ 当你作为一个测试人员发出这种呐喊的话，其实是无奈。

紧张的sprint，严格的deadline，身为测试主管如果没有改变的权利，如何在短时间内完成release 前的回归测试？

把 automation 统统 run 一遍？ 把高优先级的 test cases 全部走一遍？时间够吗，心里有底吗？

不妨在几个方面发挥一些 innovation

• 回归开始前，让组员对自己负责的模块做规划，规划内容为：设计大的系统级测试用例，这些用例要从需求出发，务必将每个user story的正向测试用例组合起来，形成完整的用户事务和工作流。这样的好处是对整体情况比较摸底，防止回归陷到细节里面去，忽视大的对用户有价值的东西
• 对于自动化，如果你的工具也能达到这种将任意测试用例组织成工作流，那就很完美了。自动化最大的risk就是后期程序的改动造成 block 和 refine,时间不够的话，千万不要去补自动化的债。Manual就manual

最后其实最重要的是，测试人员一定要为自己争取地位与权利，残留大量bug，甚至还要添加新feature，如何做回归？ 为什么一个小的功能你能延期，为了对客户更有意义的核心功能的质量，就没有时间呢？！重视测试的领导对测试人员真如刘备之于诸葛啊。

• 增加一点，或许可以按照页面划分责任，将页面设计到的输入（怎么到这个页面），输出（完成的操作与去的页面），全部覆盖。

总之一点，划分划分再划分，回归时一点要清晰，心中有数,打扫了那些地方，那些地方还未覆盖，那些地方存在风险。 不能稀里糊涂的乱扫一通，出了屋子祈祷没有遗漏的死角。藏身于其中的臭虫会让你死的很难看。