测试流程: 新手入行对测试流程的实战理解

对于测试入手

刚开始测，面临问题有三个。测试范围，优先级，业务操作不熟。

对于业务熟练，只能自己勤快，多操作产品。熟悉是很快的，但是面对陌生枯燥的东西，最难的不是脑子够不够用的问题，而是要先克服瞌睡，提高自己的兴趣和专注度。一周后你感觉已经很熟悉这个产品了，然而随后的几周里，仍会陆续发现一些你遗漏的地方……

测试优先级是容易忽略的问题。假如给你2天时间包括学习需求，编写用例，测试执行，bug报告，bug追踪，类似这样时间不够的情况很常见。那么你就需要考虑到验收时再去修复严重bug的风险，以及开发在等待bug去修复的闲暇。他们不让你闲着，你也尽量不要让他们闲着，自然就要优先测复杂的核心的改动，尽量测试与修复更高效地协作，提高团队效率，缩短周期。时间就是金钱，就是你的工资价值。

为什么我要倒着来说这三个问题，把范围放在最后呢。因为随着测试任务一个一个完成，你对测试的范围理解会越来越真实。个人觉得它是比较考验测试水平的，如果没做好它，最终测试和开发整个团队都会倒在产品验收前，如果产品验收再漏过，最后直接后果就是公司的用户损失。而测试范围，又需要上面两个的支撑，熟悉了业务，知道了轻重缓急，这时候你对需求文档转化为测试用例，才能越来越有把握。测试范围粗看就是需求的模块和功能参数逻辑要求，细看了还要分需求提到的，需求没提到但隐含的要求，以及需求矛盾，需要二次沟通，才能确定下来的预期结果。

别漏了设计稿的测试范围，这种完全脱离需求文档的玩意，有时抠得很细，有时还有临时决定的变更。到你测试时，千万不要马虎大意，以为对比是很简单的事，它涉及的页面模板，列表样式，按钮，字体，颜色，图文排版，逻辑判断对应的样式变化……测试工作量可大可小。

……

当然，大多数测试新手不需要这么谨慎周全，因为你还有测试主管帮你把关。实际工作时，对于测试团队只有一个人的情况是很少见的。

不巧，我正是。

对于测试流程

确定测试范围，确定了优先级，也知道了产品的大致功能和业务，如果你这时开始点点点，那是砍瓜切菜，势如破竹，立马提交测试报告，开发总监看完你的报告，他此刻的内心是惆怅的，因为bug太少了，不正常。

这就要涉及到测试流程了。流程的存在是为了弥补大脑的缺陷，比如靠记忆，靠一时灵感，靠反应，那都是不靠谱的，今天赢了，明天输了，在竞争如此激烈的今天，有几家公司输得起。甚至今天还风光，下个月就一落千丈，第二年销声匿迹也不稀奇。基于这种认知，才需要更科学的流程去做产品设计，产品开发，产品运营，产品客服，为了多对少错。

很多抽象的概念，就像测试流程这几个字一样，在你真正操作起来时，就会更深刻地理解它。乖乖地去写测试范围，写测试策略，写测试用例，编写bug报告，bug回归跟踪，每个步骤都是重要的，只要有一个短板，所有努力白费。

如果准备工作都到位了，bug为什么还是这么少，就需要考虑自己的测试用例设计是不是对异常考虑的不够充分，测试技术是否过浅，没能爆出bug来。

测试设计与测试技术，其中的细节这次就没法展开了，因为我还需要更多的成长，才能写出全面的看法。再说说bug。

bug报告有很多种提法，一句话，一张图，多句话，多张图，步骤描述，客户端参数，版本描述，从简单到详尽不一而足。如果项目给的时间非常充裕，你可以像绣花一样，去提交每一个报告。大家也可以有心情去欣赏精美的文档。但实际情况是，时间都是缺的。

那么你如何改进你的bug提交呢？有一个很有效的自我改进的方法，就是在开发看到这个bug后，通过他需要跟你再次交流的次数和精力，来判断你提交bug的水平。开发性格和思维不尽相同，有的人爱看逻辑步骤描述，有的人不爱看字，有的必须看到截图和涂鸦，众口难调，需要你去适配改进。

当然也有的开发压根不看bug描述，接到bug直接喊你来演示。即使你的bug内容和备注都写得很清楚，即使你现在已经在测别的东西。这里又要分情况，如果是在公司多年的开发，很可能他意识你的bug定位错了，才会喊你去说明白，如果是新来的开发，要么怕理解错，要么他之前的工作交流方式的旧习惯所致。需要你去体味，融入团队，收敛性子和脾气，寻求一种更务实的方法，大家一起去解决这个bug。

至于，团队中，谁先让步，这根本不重要，别纠结这个问题。

有时候，一个任务，你测了几天，发现bug的原因是需求改了，也没人通知你，测到时一沟通你才知道，这也是很正常的事。你也只好表示知道，默默去调整测试。