打造高效率的软件测试
写这篇文章的起因是在公司内换了一个项目组，发现在新的项目组内测试工作面临很多困难，经常加班但是产品交付的质量却不高。我不由的在想这到底是为什么？跟着又想起了自己经历过的项目组，有些测试工作做起来很轻松效果又好，有些做起事情来又累效果又差，为什么效率相差这么大？这些现象背后有哪些深层次的，共性的原因？我试图在这篇文章中找到答案，能把自己一些零散的想法做一个完整清晰的描述。
关于文章的标题，我觉得从“效率”这个角度来描述这件事情比较合适。百度百科里效率的解释是：“单位时间完成的工作量”，我们一般的理解也是这样的，高效率指单位时间内完成的工作多，或者同一件工作需要的时间更少，低效率则反之。这样之前描述的测试工作的状态就可以表达为：如果软件测试的效率高，那么测试工作做起来就比较轻松效果又好。而如果测试工作做起来又累效果又差，那么可以认为是低效率的软件测试。所以就有了这个标题：“打造高效率的做软件测试”。
低效率的软件测试
我们首先来看低效率的软件测试，我刚才说的“测试工作做起来又累效果又差”，这个描述很不准确，只是主观的感受，需要一些事实来将它具体化。不同公司不同项目组的差异很大，但根据我经历过的项目经验，低效率的软件测试主要有以下共同的表现：
需求分析，开发与测试工作相互分离，测试工作在整个开发阶段的末尾，承担着所有和质量相关的压力；
对于需求变动，设计变更，功能修改，代码重构等信息，测试人员往往是最后知道的，且能够了解到的信息有限；
测试人员远离真实用户，接触不到产品环境的信息，缺少对在线数据和用户行为监控分析的手段和能力；
团队无法做到有效的持续集成和持续发布，大量和运行环境，依赖系统有关的问题，每次发布的版本质量不可控；
缺少有效的，健康的自动化测试体系，测试依靠手工执行，重复繁琐的回归测试成为严重的工作负担；
缺少合适的测试工具，难以方便快速的完成构建测试数据，获取需要的信息，执行测试等工作。大量重复的无价值的工作需要手工完成，例如准备测试环境，安装被测产品等；
开发人员只关注功能实现，不写或很少写测试代码。测试人员只会手工黑盒测试，缺少对被测系统的深入理解，缺乏进行灰盒或者白盒测试的技术能力。
什么是高效率的软件测试
那么什么才是高效率的软件测试，或者说高效率的软件测试应该有哪些表现？我尝试着从流程管理，环境和平台，工具，自动化，人员能力五个方面阐述：
流程管理：具有规范的scrum或者看板等敏捷开发流程，测试活动贯穿软件开发的全阶段，提前预知风险。测试人员与开发团队，业务团队紧密合作，能够及时获取需求及开发信息，构建起完善的业务领域模型；
环境和平台：具有独立的，高度模拟化产品环境的测试环境，可以自动化的构建需要的测试环境及相关配置，能够广泛运用虚拟化和容器化技术构建复杂的测试环境；
工具：在团队中有完善的工具帮助测试人员完成日常工作，例如在线日志收集工具，服务状态和性能监控工具，用户行为分析工具，快速生成测试资源的工具，测试信息获取的工具等等；
自动化：有自动化的脚本或者工具减少重复工作量，有设计良好的自动化测试体系，并能够持续构建运行，每次代码改动的回归测试可以基本自动化完成，测试结果对整个团队可见。
人员能力：团队成员有统一的质量意识，理解各项实践活动和技术对于产品质量的重要性。开发人员重视代码质量，有完善的代码分析工具和测试覆盖率检查工具。测试人员具有黑盒，白盒和灰盒的测试设计与执行能力，具有优秀的技术能力，能够熟练掌握和运用上述提到的各种技术。对于测试活动与软件质量有深刻的认识，能够帮助团队从各方面提升测试成熟度。
以上的各个方面之间又存在着千丝万缕的联系，例如环境和平台部分中就隐含着工具和自动化的内容，要想构建起完善的测试环境，就需要CI，Docker等工具，也需要自动化的构建脚本。而工具部分中很多也是为了能够使机器自动化的完成重复工作，减少手工的工作量。而这一切又都需要团队有合适的流程管理方法作为前提，需要团队成员具备相应的技术能力。
如何做到
好了，讲了这么多闲话之后，我们来看点干货。如何才能把测试人员从重复枯燥的工作中解脱出来，高效率的做软件测试呢？从上述的分析中可以看出，这是一个系统化的工程，就像给团队做敏捷转型一样，不是简单的引入某项技术或者做几次培训就能达到的。但是一个优秀的测试人员应该具有这方面的的能力，下边我依然尝试着从流程管理，环境和平台，工具，自动化，人员能力五个方面来阐述：
1.流程管理：这是一切后续工作的前提条件，没有合适的流程管理方法，再先进的技术也无法充分发挥作用。目前业界中的项目开发流程基本可以分为传统的瀑布式流程和敏捷开发流程。每个团队根据自己的情况又会有很多变种，例如迭代式瀑布，Scrum，看板等等。各种流程管理方法不是本文讨论的重点，单单从提高测试效率的角度，团队中的流程管理方法应该具备以下几个要素：
能够促进团队各个成员的协作，解决常见的需求，开发，测试三方工作互相分离，协调沟通困难，信息不透明，响应不及时的问题；
能够可视化工作流程和进度，使团队重视测试工作的价值。避免将测试工作积压到项目开发的末尾，测试人员成了团队的清道夫，承担所有和质量相关的压力；
很不幸，传统的瀑布式模型对于测试人员是很不友好的，几乎必然会导致之前描述的问题。就我自己的实践经验来看，看板方法在这方面的效果不错，我曾经所在的一个严格遵循看板流程的团队，开发测试比长期在6:1至7:1，项目运作的很顺利。关于如何有效的引入和运用看板方法，可以参考看板之父大卫·J.安德森的著作：《看板方法:科技企业渐进变革成功之道》。
但是另一个常见的问题是：在一些传统开发团队中，测试人员的地位比较低，没有权利和职位去完成在团队内改变已有开发流程，推行新的开发流程的工作。可能的建议是：先通过某些方法，例如和权利干系人沟通，帮助团队解决某个复杂的问题等，获取领导层和团队内部的信任与支持，然后再根据项目的实际情况，调整具体的实践活动，逐步改善流程中存在的问题，引导团队接受和适应新的流程。
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在其著作《探索式软件测试》中举过一个很形象的例子，在游戏“魔兽世界”中，玩家的控制面板中有各种各样的信息，例如自己控制人物的血量，魔法量，技能冷却状态，施法距离，物品状态等等，而玩家借助这些信息可以做出更加正确的决策。同样的，应用到软件测试中，他提出未来的软件测试，也应该像魔兽世界一样，当做了某个操作后，有工具能够提示这个操作背后的数据流向，触发的逻辑，覆盖的代码路径等等信息，有了这些信息作为依据，测试人员可以做出更加高效和准确的决策。类似的，在很多游戏类的软件测试中，也有这样的后门工具，可以帮助测试人员成为这个游戏中的上帝，做任何想做的事情。例如让控制的人物金钱变成无限，等级升到最高，拥有各种各样的装备，穿越障碍物等等，以便充分测试软件的各种功能。
由此可见测试工具对于测试人员的重要性，缺少合适的工具，很多测试工作根本无法开展，也就是我们经常听到的“这个功能没法测”。根据自己的经验，测试人员需要的工具基本可以分为两大类：
第一是构造测试资源的工具。为了测试某项功能，需要具备某些条件或者拥有某些资源，而这些条件或者资源按照正常的业务逻辑，在测试环境中很难达到。例如需要大量金钱，需要很高的人物等级，需要大规模的数据量，需要某项指标达到特定的数字等等。没有合适的工具，测试人员要手工完成这些测试工作是极其低效甚至不可能的。
第二是获取测试信息的工具。在完成某项操作，或者出现问题需要分析原因时，能够快速方便的获取到所需的信息。例如点击按钮后的网络请求消息，API返回的结果消息，相关资源的变化情况等等。就像魔兽世界的例子一样，这样的信息越多越准确，越有利于测试人员做出正确的，高效率的决策。（在这里我想顺便澄清一个概念：黑盒测试不是基于无知的测试。我理解的黑盒测试并不是说这个黑盒我不知道，而是我不想知道或者我不必知道。一旦需要时，测试人员应该有能力很容易的把它变成白盒，获取到需要的信息。）
有一些通用的工具可以帮助到测试人员，例如性能测试常用的jmeter，接口测试用到的postman，搭建mock server的moco，web程序常用的chrome开发者工具等等。但总的来说，不如开发工具丰富，而且由于测试工作不同于开发工作，没有那么高的通用性，很多时候还是需要根据项目情况自己开发。这就涉及到另一个问题：测试人员一般代码能力都比较弱，对产品的底层细节理解也不够深刻，自己开发测试工具存在困难。而求助于开发人员也比较困难，因为这些事情不像功能开发能直接产生价值，很容易被团队忽视。所以我的建议是：一方面在团队内普及测试相关的知识，所遇到的困难，提高团队的质量意识；另一方面依然需要测试人员提高自己的技术能力和代码能力，加深对产品底层的理解，最好自己具备开发测试工具的能力。毕竟是自己用的，需要什么样的工具自己最清楚。语言方面我建议Ruby，非常灵活轻巧，运行环境搭建简单，可以快速的完成所需功能，而且有很多通用的gem包可以使用。
现在的软件越来越复杂，就像是现代化的战争一样，战场条件复杂多变，各种测试工具就像是武器装备，只有把自己武装到牙齿，才能打赢现代化的战争。
4.自动化：好吧，终于轮到了自动化。但这里我说的并不限于自动化测试，而是所有可以减少手工重复工作量的事情，即automated everything。在测试工作中有很多需要经常做，反复做的事情，自动化测试只是其中一方面，但是自动化测试需要的准备条件较多，而很多事情可能只需要几行shell脚本或者java代码，就可以节省很多工作。例如常见的web程序测试时，每次都要输入用户名和密码，然后登陆，那么完全可以写两行js的代码，每次在chrome的控制台里执行一下，省去手工输入一长串的用户名和密码。再比如我曾经碰到的一个产品，每次想要在本地启动服务，需要git checkout修改，git pull代码，export环境变量，yarn install安装依赖，yarn start加一串的参数启动服务。手工做完这一系列操作大约需要一到两分钟时间，每天大约需要做四五次。我把这些命令写成一个shell脚本文件，每次只需要./start.sh，然后我就可以去干别的事，服务启动好后再回来继续就行了。试计算一下，每次节省一分钟，一天做五次就能节省五分钟，一周能节省二十五分钟，如果这个项目做几个月，那么能节省多少时间？可以用这些时间去思考别的事，去做更有价值的事，而不是做这些重复的，产生不了价值的事情。
当然，自动化测试依然是重要的一部分，高效率的软件测试不能缺少自动化测试。关于自动化测试的话题和文章非常多，我想说的一点是，控制好投入产出比是最重要的。自动化测试是为测试人员服务的，不能为了自动化，为了指标而盲目的增加自动化测试。
5.人员能力：思想，技术，工具，这些都是外部因素，都需要人来应用到实践中。从上边的描述中能够看出，对于测试人员能力的要求是多方面的。 我的感受是，要想做到理想状态下高效率的软件测试，QA或者测试人员至少应该具备四个方面的能力：
团队管理的知识背景和能力：
传统软件测试领域的专业能力；
Devops能力；
代码能力；
结尾
写到这里，这篇文章基本上也该结尾了。可以看到，其中讨论的很多东西超出了传统软件测试的范畴，这也是我想表达的另一个观点：软件测试在软件开发过程中不是一个隔离的存在，它和各个方面息息相关。运作流程，产品结构，运行环境，部署实践，人员能力等等都会影响测试效率和交付质量。而作为软件测试的从业者，不能仅仅把自己的工作定位为“做软件测试”，所有和测试效率，交付质量相关的事情都值得我们去思考，分析，改进，优化。只有这样，才能高效率的完成软件测试，成为高效率的测试专家。
