前言：写这篇文章的起因朋友圈总看到同样的一个问题。
“在公司内换了一个项目组，发现在新的项目组内测试工作面临很多困难，经常加班但是产品交付的质量却不高？”
我不由地在想这到底是为什么？跟着又想起了自己经历过的项目组，有些测试工作做起来很轻松效果又好，有些做起事情来又累效果又差，为什么效率相差这么大？这些现象背后有哪些深层次的，共性的原因？
我试图在这篇文章中找到答案，能把自己一些零散的想法做一个完整清晰的描述。
关于文章的标题，我觉得从“效率”这个角度来描述这件事情比较合适。百度百科里效率的解释是：“单位时间完成的工作量”，我们一般的理解也是这样的，高效率指单位时间内完成的工作多，或者同一件工作需要的时间更少，低效率则反之。这样之前描述的测试工作的状态就可以表达为：如果软件测试的效率高，那么测试工作做起来就比较轻松效果又好。而如果测试工作做起来又累效果又差，那么可以认为是低效率的软件测试。所以就有了这个标题：“如何打造高效率的软件测试？”。
什么是低效率的软件测试？
我们首先来看低效率的软件测试，我刚才说的“测试工作做起来又累效果又差”，这个描述很不准确，只是主观的感受，需要一些事实来将它具体化。不同公司不同项目组的差异很大，但根据我经历过的项目经验，低效率的软件测试主要有以下共同的表现：
什么是高效率的软件测试？
那么什么才是高效率的软件测试，或者说高效率的软件测试应该有哪些表现？我尝试着从流程管理，环境和平台，工具，自动化，人员能力五个方面阐述：
以上的各个方面之间又存在着千丝万缕的联系，例如环境和平台部分中就隐含着工具和自动化的内容，要想构建起完善的测试环境，就需要CI，Docker等工具，也需要自动化的构建脚本。而工具部分中很多也是为了能够使机器自动化地完成重复工作，减少手工的工作量。而这一切又都需要团队有合适的流程管理方法作为前提，需要团队成员具备相应的技术能力。
如何做到高效率的软件测试？
好了，讲了这么多闲话之后，我们来看点干货。如何才能把测试人员从重复枯燥的工作中解脱出来，高效率地做软件测试呢？从上述的分析中可以看出，这是一个系统化的工程，就像给团队做敏捷转型一样，不是简单地引入某项技术或者做几次培训就能达到的。但是一个优秀的测试人员应该具有这方面的能力，下边我依然尝试着从流程管理，环境和平台，工具，自动化，人员能力五个方面来阐述：
1、流程管理
很不幸，传统的瀑布式模型对于测试人员是很不友好的，几乎必然会导致之前描述的问题。就我自己的实践经验来看，看板方法在这方面的效果不错，我曾经所在的一个严格遵循看板流程的团队，开发测试比长期在6:1至7:1，项目运作的很顺利。
但是另一个常见的问题是：在一些传统开发团队中，测试人员的地位比较低，没有权利和职位去完成在团队内改变已有开发流程，推行新的开发流程的工作。可能的建议是：先通过某些方法，例如和权利干系人沟通，帮助团队解决某个复杂的问题等，获取领导层和团队内部的信任与支持，然后再根据项目的实际情况，调整具体的实践活动，逐步改善流程中存在的问题，引导团队接受和适应新的流程。
2、环境和平台
要做软件测试，首要问题是在什么样的环境上做测试，以及如何能够快速高效地构建起需要的环境。两个关键的因素是：测试环境需要尽可能地模拟软件产品环境存在较大差异，这样测试工作才能准确反映软件在使用中的真实状态；环境部署能够快速自动化完成，以避免测试人员在搭建测试环境这种重复且低价值的工作上耗费时间和精力。
Devops的兴起无疑是测试人员的福音，infrastructure as code，pipeline as code，容器化等技术可以极大地提高环境构建的自动化程度，减轻测试人员准备测试环境的工作量。而持续集成，持续交付等理念可以使测试人员更有效地控制代码合入质量，构建起更贴近产品环境的测试环境，可供参考的资料有：《持续交付:发布可靠软件的系统方法》。
这部分的内容属于团队的基础技术设施，直接影响着测试人员的工作效率和产品交付质量。但是在传统观念中，很多人认为这不是测试人员的职责所在，而很多测试人员由于职位或者自身技术能力的限制，也缺乏这方面的影响力。这就要求测试人员提升自己的技术能力，扩大自己的工作范围，从各个角度考虑影响产品质量的因素，并引导团队提升质量内建能力。（顺便说一句，虚拟化平台例如VMwar，AWS，容器化技术例如Virtual Box, Docker，都是测试人员的得力助手，值得深入了解和学习）
3、工具
“工欲善其事，必先利其器”，面对现代高度复杂的软件结构，没有合适的工具，全凭手工开发是不可想象的。但遗憾的是，大家往往把注意力放在了琳琅满目的开发工具上，而忽视了测试工具的重要性，这对测试人员是很不公平的。试想一下，如果一个项目中没有git，svn等版本管理工具，没有eclipse，intelllliJ等IDE工具，没有maven，gradle等构建工具，没有jenkins等CI工具，开发人员要用vi写代码，手工管理代码提交，手工编译打包，手工部署，那会是怎样一幅场景？完全不可想象的事。
但是事实上很多测试人员和测试团队就是工作在类似这样的原始条件下，能用的工具就是鼠标和键盘，能做的事情就是点击和输入，需要的测试资源无法轻易获取，出现问题后无法快速定位原因，只能一遍又一遍的找开发人员，带来了很多沟通成本，甚至影响与开发人员的合作关系。
James Whittaker在其著作《探索式软件测试》中举过一个很形象的例子，在游戏“魔兽世界”中，玩家的控制面板中有各种各样的信息，例如自己控制人物的血量，魔法量，技能冷却状态，施法距离，物品状态等等，而玩家借助这些信息可以做出更加正确的决策。同样的，应用到软件测试中，他提出未来的软件测试，也应该像魔兽世界一样，当做了某个操作后，有工具能够提示这个操作背后的数据流向，触发的逻辑，覆盖的代码路径等等信息，有了这些信息作为依据，测试人员可以做出更加高效和准确的决策。类似的，在很多游戏类的软件测试中，也有这样的后门工具，可以帮助测试人员成为这个游戏中的上帝，做任何想做的事情。例如让控制的人物金钱变成无限，等级升到最高，拥有各种各样的装备，穿越障碍物等等，以便充分测试软件的各种功能。
由此可见测试工具对于测试人员的重要性，缺少合适的工具，很多测试工作根本无法开展，也就是我们经常听到的“这个功能没法测”。根据自己的经验，测试人员需要的工具基本可以分为两大类：
有一些通用的工具可以帮助到测试人员，例如性能测试常用的jmeter，接口测试用到的postman，搭建mock server的moco，web程序常用的chrome开发者工具等等。但总的来说，不如开发工具丰富，而且由于测试工作不同于开发工作，没有那么高的通用性，很多时候还是需要根据项目情况自己开发。这就涉及到另一个问题：测试人员一般代码能力都比较弱，对产品的底层细节理解也不够深刻，自己开发测试工具存在困难。而求助于开发人员也比较困难，因为这些事情不像功能开发那样能直接产生价值，很容易被团队忽视。
所以我的建议是：一方面在团队内普及测试相关的知识，所遇到的困难，提高团队的质量意识；另一方面依然需要测试人员提高自己的技术能力和代码能力，加深对产品底层的理解，最好自己具备开发测试工具的能力。毕竟是自己用的，需要什么样的工具自己最清楚。语言方面我建议Python或者Ruby这样的脚本语言，非常灵活轻巧，运行环境搭建简单，可以快速的完成所需功能，而且有很多通用的库可以使用。
现在的软件越来越复杂，就像是现代化的战争一样，战场条件复杂多变，各种测试工具就像是武器装备，只有把自己武装到牙齿，才能打赢现代化的战争。
自动化
好吧，终于轮到了自动化。但这里我说的并不限于自动化测试，而是所有可以减少手工重复工作量的事情，即automated everything。在测试工作中有很多需要经常做，反复做的事情，自动化测试只是其中一方面，但是自动化测试需要的准备条件较多，而很多事情可能只需要几行shell脚本或者java代码，就可以节省很多工作。
试计算一下，每次节省一分钟，一天做五次就能节省五分钟，一周能节省二十五分钟，如果这个项目做几个月，那么能节省多少时间？可以用这些时间去思考别的事，去做更有价值的事，而不是做这些重复的，产生不了价值的事情。
当然，自动化测试依然是重要的一部分，高效率的软件测试不能缺少自动化测试。关于自动化测试的话题和文章非常多，我想说的一点是，控制好投入产出比是最重要的。自动化测试是为测试人员服务的，不能为了自动化，为了指标而盲目的增加自动化测试。
人员能力
思想，技术，工具，这些都是外部因素，都需要人来应用到实践中。从上边的描述中能够看出，对于测试人员能力的要求是多方面的。我的感受是，要想做到理想状态下高效率的软件测试，QA或者测试人员至少应该具备四个方面的能力：
结尾
写到这里，这篇文章基本上也该结尾了。可以看到，其中讨论的很多东西超出了传统软件测试的范畴，这也是我想表达的另一个观点：软件测试在软件开发过程中不是一个隔离的存在，它和各个方面息息相关。运作流程，产品结构，运行环境，部署实践，人员能力等等都会影响测试效率和交付质量。而作为软件测试的从业者，不能仅仅把自己的工作定位为“做软件测试”，所有和测试效率，交付质量相关的事情都值得我们去思考，分析，改进，优化。只有这样，才能高效率地完成软件测试，成为高效率的测试专家。
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！