写在前沿
入行第5年了，最近发现自己心态上起了一些微妙的变化，如果在头三年，别人问我，软件测试到底是干啥的，我肯定会回答，就是测软件上bug的，当然，你的bug测得越多越好，甚至，你在测试时候如果没有发现Bug，你会莫名的感觉焦灼甚至有点心慌，妈呀，我是不是漏测了？那时候以为，发现bug的数量和质量或许体现了测试工程师存在于这个行业的最大价值和意义。
直到，我经历过一个项目，心路慢慢的有了些转变，因为项目上线质量和快速迭代的压力，我发现从刚开始尽管一遍又一遍的测出了很多的bug，但是项目质量仍然堪忧，项目上线仍然没有安全感，特别是上线以后，开发一句：这个怎么没测出来让我有点风中凌乱（宝宝心里苦，宝宝不说），按照我以前的理解，我自认为已经是一个合格的测试了，但是我所面临的让我思考，我是不是该从项目下游的环节往上捋捋是不是团队出了什么问题？
回归项目
首先说下项目特点，该项目迭代速度很快，平均一个月发布三次，后端相对于比较稳定，前端代码Bug率较大，其中我所碰到过以下主要几个问题：
回归范围的不确定性
经常出现的问题可能就是，当前端修改过一个问题后，可能会产生其他的前端问题。
另外一个问题可能是刚开始项目交接的时候，本身该项目没有需求文档，以及产品经理，测试需求点的介入需要强依赖开发的口头沟通；
案例：有一次，前端修改一个ini接口，开发评估自测，但是线上出现某个活动页面登录不上。
思考：如何从测试的角度去预知前端代码的变更所造成的影响范围，从而评估出测试范围？
目前的解决方案：
a． 在测试阶段，让前端开发去评估的测试范围，针对项目需求在建立jira任务的时候去尽可能的给出测试版本，测试内容以及相对应的交互稿。
图1. 完善需求
b． 加强开发代码CodeReview流程，多个前端交互评审，给出评审报告；
当然，最好的解决方案是测试人员学会前端代码，参与代码评审，从上游和开发一起做一个代码质量保证。
无法把控的项目节奏
案例：在迭代过程中，经常会面临测试节奏被打乱的情况；可能有以下几种原因：
- 线上Hotfix紧急上线；
2. 在已经确定好开发计划后又新增需求；
以上几点原因直接导致我们在项目进度上被某些突发事件打乱，无法按照预定的项目节奏走。
图2.某个项目迭代过程
解决方案：
针对Hotfix，可能确实已经相对比较紧急了；在开发给出测试范围以后，测试根据自己的经验做一些相应的回归；
针对新增需求，各个团队人员进行相应的评估，由新增需求的人提出一个需求变更表；需要团队队员确认；
图3.需求变更风险评估表
剑拔弩张的沟通
开发与测试的矛盾点很大部分集中在，开发在产品质量意识上，对产品质量和测试人员有些误解，他们会认为线上如果有Bug那是因为测试人员的问题，他们没有给产品把好关，导致Bug流到了线上，然后巴拉巴拉的吐槽测试，在整个团队里面，我觉得集中突出了以下2个问题：
1.“这个怎么没测出来？”：
曾经经历过一次线上Bug，在和一个开发聊天的过程中，在交谈过程中他跟我抱怨“你怎么连这个都没测出来呢？我们怎么信任你的测试质量？”。说实话那句话让我心里很不爽，因为在他的意识里面把那次线上Bug的责任全部归咎到了我没有测试到位。当时直接争执了起来，“你说我测试差，我还没说你开发能力差呢？”
尽管，我们所了解的测试其实是一个服务型的行业，有时候会是一个“背锅侠”，但是真的像开发所说的那样，线上Bug只是我们测试不到位的原因嘛？如果我们细细挖掘整个产品生产过程，事实是，“测试”这个环节是所有产品生产里面最不会产生”Bug”的环节。
2.如何去看待线上问题？：
团队面临的另外一个问题，就是对线上Bug的零容忍，这样会导致一个很直接的结果，就是一旦出现线上Bug，团队氛围会因为线上压力而变得很紧张；其次，刚开始的时候，一旦出现问题大家都会把矛头直接对准测试，并且会把目光聚焦到产品生产下游—从测试的底端去想如何去避免该类问题；
解决方案：
- 如何让开发有质量保障的参与感---增加开发用例设计的参与感。
除了一般的用例评审环节，还会增加一个用例站会评审环境，测试需要把所有的测试思路以及测试重点再进行一轮展示，全体参与查漏补缺（可能一部分原因是想说，让开发去体会测试所处的位置和难处）。
图4. 用例评审模式
2.尽可能的引导团队在出现线上问题的时候从产品生产上游去解决问题。因为增加自动化回归范围这些手段来说，可能会避免这个问题，但还是无法去解决真正发生这些问题的原因，尽管这个过程中在推广这些理念的时候会和开发产生一些冲突和争执，过程比较艰辛，是一个任重而道远的过程。
图5.线上问题解决方案
产品质量的困惑
每次迭代上线，我们都会写一个测试报告，在每次报告总结里面，我们都会填写一个总结，产品质量怎么样，能不能上线等等？这些很多都是凭借我们自己的经验去判断，当有人真正问你的时候，你还真的无法说出一个一二，什么叫好，什么叫不好？
这个项目可能会给我增加一些判定的维度方面的经验：
- 产品质量：
包含了我们最终在交付产品的时候，对Bug（数量+严重度+概概述），功能点（包含了功能，性能，异常是否全部覆盖），用例（是否包含了全部功能点以及执行情况，测试过程的代码覆盖率等）的一个整体产品评估。
- 产品过程质量：
引入这个概念，是因为一些测试经验；比如，我们在做功能测试的时候，一般我们会进行相对较全的功能回归，在第一轮回归以后，可能会出现一些问题，然后修复好以后又进行相应的冒烟，此时在回归次数增加的同时，可能也会存在一些未知的风险，比如第一轮回归完成后，第二轮修的Bug可能会影响到前面的测试功能，所以存在说回归次数和产品质量的一个风险关系；
其次，比如我们在迭代过程中的需求挖掘，如果在刚开始需求挖掘的时候，没有挖掘出一些潜在的需求Bug，那可能后续会增加一些回归的风险，再比如开发的冒烟的通过率等等还有很多，也可以根据自己的项目经验去增加。
图6.日常迭代过程记录
- 上线过程质量：
主要考虑2个方面：
- 上线过程中前后端是否相互完全隔离；
- 上线是否采用静默升级，升级后会不会影响线上现有的功能点。
如何提项目质量风险？
整个测试过程中，质量保障的最后一步，我认为也是最难的一步，就是如何去预估产品所在的风险点，我曾经和开发有过一些争执的矛盾点是在于立场的不一致会对风险点的看法理解不一样，所以在写风险点的时候尽可能和开发在意见上达成一致。
其次，除了遗漏Bug等一些质量风险，项目风险的话尽可能由“大”到“小”的去思考，“大”是指方向性，比如兼容性，安全，性能，异常等等的角度入手，“小”是结合产品所在的一些细节。
比如，一个移动端的产品要上线，可能因为我的测试时间有限我兼容性只测了一部分，兼容性问题可能是我的一个风险点；
再比如，后端新增一个接口或者新增一个服务 ，性能和异常这块可能要考虑是不是一个风险点。
这些都是需要去考虑和项目经验积累的。
写在最后：
如果现在，项目要上线了我还没有发现bug，那种焦灼感反而由一些欣慰替代，我发现我心态的转变可能是源于我意识的转变，当别人问我，测试是干嘛的时候，我可能更偏重于，测试是一个把质量意识输出到整个团队的人，是一个流程推动者，是一个需求挖掘者，是一个质量把关者，一方面我们确实通过自己的经验和技术手段去挖掘更多的Bug，另外最重要的一方面，通过一些测试需求的挖掘，流程把控，质量意识以及测试方法的传播尽可能的去从产品生产上游去避免Bug。希望有一天，在我们的推动下，行业没有了测试人员，因为项目里人人都是测试专家。
共勉！