技术新趋势下软件测试的机遇与挑战

2015年11月，ThoughtWorks发布了新一期的技术雷达。技术雷达是以独特的形式记录ThoughtWorks技术顾问委员会对行业产生重大影响的技术趋势讨论的结果，为从CIO到开发人员在内的各方利益相关者提供价值。这期雷达的技术趋势主要体现在：受到热捧的微服务相关技术，逐步成熟的以Docker为典型的容器化生态系统，备受企业和用户关注的信息安全问题。本文就从这几个新趋势来分析一下给软件测试带来了哪些影响。

自动化测试是王道

在这个快速变化发展的时代，任何一款产品想要在市场具备竞争力，必须能够快速适应和应对变化，要求产品开发过程具备快速持续的高质量交付能力。而要做到快速持续的高质量交付，自动化测试将必不可少。同时，自动化测试也不是用代码或者工具替代手工测试那么简单，有了新的特点和趋势：针对不同的产品开发技术框架有着不同的自动化技术支持，针对不同的业务模式需要不同的自动化测试方案，从而使得自动化测试有着更好的可读性、更低的实现成本、更高的运行效率和更有效的覆盖率。来自技术雷达的下列主题分别体现了自动化测试的这些特点：

针对微服务的消费端驱动的契约测试(Consumer-driven contract testing)，有助于解决随着服务增多带来集成测试效率低和不稳定的问题。消费端驱动的契约测试是成熟的微服务测试策略中核心的组成部分。

专门用于测试和验证RESTful服务的工具REST-assured，它是一个Java DSL，使得为基于HTTP的RESTful服务编写测试变得更加简单。REST-assured支持不同类型的REST请求，并且可以验证请求从API返回的结果。它同时提供了JSON校验机制，用于验证返回的JSON数据是符合预期的。

安卓系统功能测试工具Espresso，其微小的内核API隐藏了复杂的实现细节，并帮助我们写出更简洁、快速、可靠的测试。

ThoughtWorks开源的轻量级跨平台测试自动化工具Gauge，支持用业务语言描述测试用例，支持不同的编程语言，支持所支持平台的并行执行。

用于针对UI的自动化测试构建页面描述对象的Ruby库Pageify，该工具关注于更快的执行测试以及代码的可读性，并可以很好的配合Webdriver或是Capybara使用。

专门用于iOS应用开发的开源行为驱动开发测试框架Quick，支持Swift、Objective-C，它和用来做测试验证的Nimble捆绑发布。Quick主要用于Swift和Objective-C程序行为的验证。它和 RSpec和Jasmine具有相同的语法风格，基础环境很容易建立。Quick良好的结构和类型断言使得测试异步程序更加容易。Quick拥有现成的Swift和Objective-C规范文件模板，开发者只需简单几步，即可对应用进行快速测试。

工具很重要，设计不可少!自动化测试工具云集，但做自动化也不要冲动，需要重视以下几点：

• 综合考虑项目技术栈和人员能力，采用合适的框架来实现自动化;
• 结合测试金字塔和项目具体情况，考虑合适的测试分层，如果能够在底层测试覆盖的功能点一定不要放到上层的端到端测试来覆盖;
• 自动化测试用例设计需要考虑业务价值，尽量从用户真实使用的业务流程/业务场景来设计测试用例，让自动化优先覆盖到最关键的用户场景;
• 同等看待测试代码和开发代码，让其作为产品不可分割的一部分。

云技术、容器化和开源工具使得测试成本下降

测试环境的准备在过去是一个比较麻烦和昂贵的事情，很多组织由于没有条件准备多个测试环境，导致测试只能在有限的环境进行，从而可能遗漏一些非常重要的缺陷，测试的成本和代价很高。随着云技术的发展，多个测试环境不再需要大量昂贵的硬件设备来支持，加上以Docker为典范的容器技术生态系统也在逐步成长和成熟，创建和复制测试环境变得简单多了，成本大大的降低。技术雷达推荐的凤凰环境(Phoenix Environment)，它使用凤凰服务器(Phoenix Server)的模式，能够以自动化的方式支持测试、开发、UAT和灾难恢复所需的新环境准备。这一技术由上期的评估环上升到了采用环，表明它已经得到了验证和认可，是可以放心使用的技术。

另一方面是大量开源工具的出现，这些工具往往都是轻量级的、简单易用，相对于那些重量级的昂贵的测试工具更容易被人们接受。测试工作有了这些开源工具的帮助，将更加全面、真实的覆盖到要测试的平台、环境和数据，将会加快测试速度、降低测试成本;更重要的一点，有了这些工具，让测试人员能够腾出更多的时间来做测试设计和探索性测试等更有意思的事情，使得测试工作变得更加有趣。新技术雷达提到的开源工具有：Mountebank、Postman、Browsersync、Hamms、Gor和ievms等。

在企业级应用中，对组件进行良好的测试至关重要，尤其是对于服务的分离和自动化部署这两个关系到微服务架构 是否成功的关键因素，我们更需要更合适的工具对其进行测试。Mountebank就是一个用于组件测试的轻量级测试工具，可以被用于对 HTTP、HTTPS、SMTP和TCP进行模拟(Mock)和打桩(Stub)。

Postman是一个在Chrome中使用的REST客户端插件，通过Postman，你可以创建请求并且分析服务器端返回的信息。这个工具在开发新的API或者实现对于已有API的客户端访问代码时非常有用。Postman支持OAuth1和OAuth2，并且对于返回的JSON和XML数据都会进行排版。通过使用Postman，你可以查看你通过Postman之前发起过的请求，并且可以非常友好的编辑测试数据去测试API在不同请求下的返回。同时，虽然我们不鼓励录屏式的测试方法，但是Postman提供了一系列的拓展允许我们将它作为跑测试的工具。

随着网站应用所支持设备的增多， 花在跨设备测试上的代价也在不断增大。Browsersync能够通过同步多个移动设备或桌面浏览器上的手工浏览器测试来极大的降低跨浏览器测试的代价。通过提供命令行工具以及UI界面，Browsersync对CI构建非常友好，并且能够自动化像填写表单这样的重复任务。

在软件开发领域，盲目地假设网络总是可靠，服务器总是能够快速并正确的响应导致了许多失败的案例。Hamms可以模拟一个行为损坏的HTTP服务器，触发一系列的失败，包括连接失败，或者响应缓慢，或者畸形的响应，从而帮助我们更优雅的测试软件在处理异常时的反应。

Gor可以实时捕获线上HTTP请求，并在测试环境中重放这些HTTP请求，以帮助我们使用到这些产品环境数据来持续测试我们的系统。 使用它之后可以大大提高我们在产品部署，配置修改或者基础架构变化时的信心。

尽管IE浏览器的使用量日益萎缩，但对很多产品而言IE浏览器的用户群依然不可忽视，浏览器兼容性仍然需要测试。这对于喜欢使用基于Unix的操作系统进行开发的人来说还是件麻烦事。为了帮助解决这个难题，ievms提供了实用的脚本来自动设置不同的Windows虚拟机镜像来测试从IE6到Microsoft Edge的各种版本浏览器。

安全测试贯穿整个生命周期

“安全是每一个人的问题”!互联网安全漏洞频繁爆发，安全问题已经成为每个产品迫切需要关注和解决的问题，安全测试将需要贯穿于软件开发的整个生命周期。同时，给软件测试人员带来了更多的机遇和挑战，要求具备更多的安全相关知识(其中还包括更多的计算机基础知识)，掌握已有的安全测试相关技术，从而在软件开发的各个阶段做好安全相关的分析和测试工作。尽管有些团队已经将安全跟整个开发实践结合起来，但培养每个人在每个阶段的安全意识还相当的重要，探索新的安全测试技术、方法还有很多空间。

技术雷达上列出的安全测试相关的技术和工具有：Bug bounties、威胁建模(Threat Modelling)、ZAP和Sleepy Puppy。

Bug bounties是一个安全漏洞举报奖励制度，越来越多的组织开始通过Bug bounties鼓励记录常见的安全相关的Bugs，帮助提高软件质量。

威胁建模(Thread modeling)是一组技术，主要从防御的角度出发，帮助理解和识别潜在的威胁。当把用户故事变为“邪恶用户故事”时，这样的做法可给予团队一个可控且高效的方法使他们的系统更加安全。

ZED Attack Proxy (ZAP)是一个OWASP的项目，允许你以自动化的方式探测已有站点的安全漏洞。可以用来做定期的安全测试，或者集成到CD的Pipleline中提供一个持续的常规安全漏洞检测。使用ZAP这样的工具并不能替换掉对安全的仔细思考或者其他的系统测试，但是作为一个保证我们的系统更安全的工具，还是很值得添加到你的工具集里。

Sleepy Puppy是Netflix公司近期开源的一款盲打XSS收集框架。当攻击者试图入侵第二层系统时，这个框架可用于测试目标程序的XSS漏洞。XSS是OWASP的Top10的安全威胁，Sleepy Puppy可以用来同时为几个应用完成自动安全扫描。它可以自定义盲打方式，简化了捕获、管理和跟踪XSS漏洞的过程。Sleepy Puppy还提供了API供ZAP之类的漏洞扫描工具集成，从而支持自动化安全扫描。

优化业务价值

大多数软件都是做项目的模式，在不同的档期内进行计划、实现和交付。敏捷开发极大的挑战了这种模式，通过在开发过程中各个阶段进行的分析和测试工作，持续的发现新的需求，使得需求更趋于合理化，更能体现业务价值。精益创业的技术，如观察需求的A/B测试，进一步削弱了这种心态。技术雷达推荐“产品优于项目(Product over project)”，认为大多数的软件开发工作应该遵循精益企业的引领，将自己定义为构建支持业务流程的产品。这样的产品并没有所谓的最终交付，更多的是一个探索如何更好的支持和优化业务流程的过程，只要业务依然有价值就会不断持续下去。

作为软件开发中的关键角色、负责软件测试的QA人员，通过从用户角度对软件的测试，结合自身对软件产品的了解，对优化业务价值将会起到举足轻重的作用。软件测试不仅是检验软件是否满足规定的需求或弄清预期结果与实际结果之间的差别的过程，还需要有意识的对需求进行持续的验证和优化，对业务的趋势和风险进行分析。如果能在开发过程中结合使用BDD(行为驱动开发)的思想，统一团队对需求的认识，利用团队的力量来优化业务将会达到事半功倍的效果。

传统方式下，QA角色主要专注于保证软件产品在类产品环境下的质量。随着持续交付的出现，QA角色逐渐转变到需要分析软件产品在产品环境下的质量。产品环境下的QA(QA in production)，就是要求QA角色在做好产品上线前的质量保证工作前提下，做好软件产品在产品环境下的质量分析。具体做法有：

(一)引入产品系统的监控， 制定检测条件，找出产品环境下使用的质量度量。比如，利用网站分析工具收集用户使用应用程序的数据，分析数据量需求、产品的性能趋势、用户的地域特征、用户的行为习惯和产品在同类型产品市场的占有率等。

(二)收集产品环境下最终用户的反馈，对反馈进行分类分析。这些反馈可能有：

• 缺陷：需要进行优先级划分，确定是否需要修复;并且对这些缺陷进行根源分析，在以后的开发过程中尽量避免同类型的缺陷再次出现。
• 抱怨：对于抱怨需要分析其背后的原因，可能正是能够帮助我们改进和优化业务价值的好机会。
• 建议：一般用户可能难以提出高质量的建议，需要我们在收集反馈的时候下点功夫，有针对性的去收集。一旦收集到了建议，将是对业务价值优化非常有利的。

通过对产品环境下的软件质量进行分析，将有利于协助“产品优于项目”实践，帮助优化业务价值，做好企业产品的创新工作。需要注意的是，产品环境下的QA可能会导致有些组织走的太远而忽视产品上线前的质量保证，它只对那些已经执行并有一定程度持续交付实践的组织有价值。

总结