写在前面
如何让一个城市干净整洁？许多人会认为，雇用更多的环卫工人，安排至城市的每一个角落，就可以保证环境的干净整洁了。这样的做法直观且效果立竿见影，但是人力成本高，治标不治本，今日清扫完毕，隔天又是满街的垃圾。这时我们就需要思考为什么每天都有那么多垃圾，其中一个必然的原因就是有人乱扔垃圾。因此，可以对乱扔垃圾的人采取一定的惩罚，杜绝乱扔垃圾的现象。除此之外，为了引导更多人不乱扔垃圾，避免强行惩罚措施带来市民的反感，我们还需要进行更深层次的思考：为什么垃圾还不少，是否因为垃圾桶的设计不够合理……逐层加深思考，从公共设施等方面进行改进。
测试工作与城市环卫管理工作有着异曲同工之处，只不过测试工作遇到的问题更抽象更复杂，需要考虑的因素更多。结合几年的测试经验，我将测试归结为如下几个阶段。
第一阶段：find BUG & find BUG
这个阶段就是尽可能发现更多的bug，见一个灭一个，见两个灭一双，测试工作主要集中在发现bug，但是要做好这个阶段的工作，需要从如下方面努力：
首先，提高用例设计能力，更有效率地找到bug；
其次，学会清晰地描述bug、定位严重级别和优先级别，以及后期跟踪验证；
第三，提高对系统业务和系统架构的理解能力，发现深层次的缺陷；
第四、学会根据发现的bug，举一反三，尽早发现更多类似的缺陷。
如上所谈到的能力，是一个测试工程师的基本功，虽然表面看起来很简单，但是切切实实有助于提升系统质量。不过，测试工作若一直停留在此，就与单纯雇佣很多环卫工人并无区别：系统在开发，每天都有新鲜元素的输入，测完今天，明天依然会有很多bug，仅仅只是find bug，无法治本。
测试之所以一直停留在这个阶段，原因如下：
1、研发完成，不进行自测，尤其涉及多个接口，没有足够的环境自测，从而提交测试后，测试需要花更多的测试时间；
2、提交测试后，很多基本功能未完善，无法正常使用；
3、发布时间较随意，研发刚完成，就面临着发布，没有充分的测试时间；
4、没有对研发人员进行质量考核，导致研发人员缺少意识，容易产生一些常见而重复的缺陷，从而增加测试的工作量。
这些现状，导致测试人员无法跨越第一个阶段。针对项目现状进行分析，我们有必要结合研发的体系发展，努力改善并克服这些问题。
第二阶段：quality management
经过了第一个阶段，我们认识到仅仅find bug治标不治本，无法从根本上提高项目质量，因此需要思考是否有更好的方式进行测试？最直接的方法即是让bug产出更少一些。
我们可以对发现的bug进行分析，并从研发流程的角度去思考如何使bug减少：
一、质量统计分析
1、统计每个版本发现的bug数量bug分布严重程度等；
2、对比每个模块产生的bug数量；
3、对比每月产生的bug数量；
4、分析bug类型（兼容性、可用性、功能性、安全性等），列出研发过程中可以避免的bug；
5、统计bug的返工率；
6、持续集成，追踪代码变更情况；
通过对这些数据进行统计分析，推测出问题集中在哪些模块中、哪些人负责研发这些模块、产出最多哪一种类型的bug，将其罗列出来，通知相关研发人员，并根据2-8原则，着重测试问题较多的模块，尽早发现问题，尽可能规避风险，并在下个版本继续分析总结，查看这些问题是否已改善。
二、考核研发人员
研发人员可以通过控制bug产出量减少测试人员的工作负担。虽然在研发过程中，很多研发人员会自觉检查规避bug，但是没有考核机制，容易导致开发人员懈怠、没有积极性。可以从如下几个方面进行考核：
1、考核编译失败的次数；
2、测试阶段产生的 bug数量，尤其是致命及严重bug、低级bug；
3、发布事故；
4、质量统计分析反馈后，下个版本是否改善；
5、bug返工次数。
考核机制，不仅能够起到一定的约束作用，而且也能够作为心理暗示，潜移默化地提高工作人员的责任心，便于其养成良好习惯。
三、考核测试人员
研发人员要考核，测试人员也不例外，通常可以考虑如下几个指标：
1、模块是否漏测；
2、发现的严重bug是否及时沟通反馈；
3、bug描述是否清晰，是否导致研发人员在读懂bug的过程中，占用较多时间；
4、每个版本是否有测试报告，是否有项目相关人员不懂项目质量情况现象；
5、发布后，是否出现重大bug；
6、测试效率是否低于标准。
具体制定考核指标，需要从各个项目综合分析考虑。
四、鼓励开发自测
1、统计发现的bug，分析哪些bug是可以通过研发自测发现的，是不应该进入测试阶段的，进而制定相应的标准，进行横向纵向对比，将分析总结出来的这些bug，反馈给研发；
2、在征求开发负责人认可的前提下，制定一份自测清单，要求研发人员在提交代码之前完成这个清单的编写并反馈；
3、设计一套可用于自动化验收的用例，并用于持续集成测试。
第三阶段：Quality improvement
如上第二个阶段，我们发现质量又有了一定的提升，但是，或许有些问题，还是无法避免，这些问题需要拓宽思维方式，开阔眼界去看待。为此，革命尚未成功，同志仍需努力，可以从如下几个方面开拓质量提升的思路。
一、梳理开发流程
我们在分析项目质量和工作效率时，会发现很多bug不仅是纯代码问题，还可能涉及研发整个流程的方方面面，比如需求描述不清、需求管理混乱、团队与团队之间配合问题、版本管理问题、人员沟通问题、版本的发布流程问题等。因此，规范梳理研发流程，在避免如上问题中，起到非常重要的作用。
二、测试前代码走查
即所谓的code review。每一个成功的项目都是难以一蹴而就的，开发过程必然会遇到各种各样的问题和阻力，正所谓：软件开发中唯一不会变的就是，需求永远会变化。而问题越早被发现，补救花费的时间就会越少，损失就会越小，成本就越低。研发人员之间，可以进行交叉review，查看不同人员的代码，有助于发现黑盒难以发现的问题，从而将缺陷扼杀在摇篮中。
三、提升测试效率
可以根据项目的情况，拓展测试类型，比如白盒测试、兼容测试、安全测试、性能测试等；提高测试人员全面的测试技能，尽早、尽可能发现系统中存在的bug，从而有效的规避风险，减少不必要的损失。
同时，在项目相对稳定的前提下，挖掘一套适合项目的自动化测试工具，分析各种情况，搭建自动化测试环境，设计测试用例，设计测试脚本，从而减少后期频繁的流程回归测试时间，提高测试效率。
四、发布时环节把控
考虑到项目的组织架构不同，可能执行发布的人员也有所不同，或许是开发人员，或许是运维人员，或许是专职的版本管理人员等。但无论哪个角色执行发布任务，建议遵循如下原则。
1、避免随意发布，从而更准确地度量质量；
2、了解该阶段发生了什么、可能会带来哪些影响、线上需要注意什么；
3、备份和快速回滚准备。
发布是研发流程的关键点，在这个节点上进行控制，对于测试团队来说，可以发现很多问题，也有利于提升团队合作的能力。
五、发布后线上监控
发布后，监控系统的运行情况，若发现问题，及时进行分析，并推动优化。通常，可以从如下几个方面进行监控：
1、运行监控，如资源使用情况，主要组件是否正常等；
2、业务指标监控，如点击率，响应时间等；
3、功能监控，如接口、功能模块使用等层面；
4、用户监控，收集用户反馈的问题，并从中分析问题根源，从而在下个版本中优化并处理这些问题。
如上监控，可以及时发现一些问题，当然，为了实现上面的监控，需要做出大量的工作，但是，这些监控对于整个系统运营质量的度量，也是至关重要的。
写在后面
“众里寻他千百度，蓦然回首，那人却在灯火阑珊处”，经过不断的磨练，或许就有那么一个时刻，灵犀一点，领悟真谛的豁然。我们时刻在考虑一个问题，测试团队存在的价值和意义是什么，或许就是这些细枝末节，凝聚了测试一点一滴的汗水，成就了团队的价值，也证明了测试存在的意义。
