我所理解的"测试"工作

写在前沿

         入行第5年了，最近发现自己心态上起了一些微妙的变化，如果在头三年，别人问我，软件测试到底是干啥的，我肯定会回答，就是测软件上bug的，当然，你的bug测得越多越好，甚至，你在测试时候如果没有发现Bug，你会莫名的感觉焦灼甚至有点心慌，妈呀，我是不是漏测了？那时候以为，发现bug的数量和质量或许体现了测试工程师存在于这个行业的最大价值和意义。

       直到，我经历过一个项目，心路慢慢的有了些转变，因为项目上线质量和快速迭代的压力，我发现从刚开始尽管一遍又一遍的测出了很多的bug，但是项目质量仍然堪忧，项目上线仍然没有安全感，特别是上线以后，开发一句：这个怎么没测出来让我有点风中凌乱（宝宝心里苦，宝宝不说），按照我以前的理解，我自认为已经是一个合格的测试了，但是我所面临的让我思考，我是不是该从项目下游的环节往上捋捋是不是团队出了什么问题？

 

回归项目

首先说下项目特点，该项目迭代速度很快，平均一个月发布三次，后端相对于比较稳定，前端代码Bug率较大，其中我所碰到过以下主要几个问题：

回归范围的不确定性

经常出现的问题可能就是，当前端修改过一个问题后，可能会产生其他的前端问题。

另外一个问题可能是刚开始项目交接的时候，本身该项目没有需求文档，以及产品经理，测试需求点的介入需要强依赖开发的口头沟通；

案例：有一次，前端修改一个ini接口，开发评估自测，但是线上出现某个活动页面登录不上。

思考：如何从测试的角度去预知前端代码的变更所造成的影响范围，从而评估出测试范围？

目前的解决方案：

a． 在测试阶段，让前端开发去评估的测试范围，针对项目需求在建立jira任务的时候去尽可能的给出测试版本，测试内容以及相对应的交互稿。

                

             &n