打造企业级移动测试云平台

背景

移动技术发展到现阶段,原生、混合式技术发展的足够成熟,可以无缝融合。而随着移动技术的发展和革新,移动领域的测试技术和实践也有了一定发展:工具不再像早期一样几家独大,选择性越来越多;从浅尝辄止的实验阶段到真实项目中的自动化测试落地。这些实践在一定程度上提升了测试反馈效率,在迭代交付的过程中出色的完成了质量保证的工作,但在相对漫长的实践过程中,我们依然可以总结一些痛点:

1、移动自动化测试的执行效率远不及Web应用

有过Web自动化测试经验的同学对于Selenium肯定不会陌生,Web端的并发测试使得测试在有限资源的情况下按照我们的期望并发执行。而且由于keychain等问题,很难在测试用例之间做到互不影响、对于测试环境的清理和准备也有很大难度。

2、很难全面覆盖繁杂的测试设备

Web自动化测试关注的测试环境相对单纯,针对不同项目、产品和市场,无非是对不同的浏览器和操作系统有不同程度的支持。而对于不同浏览器也有不同的driver来支持。而在移动测试中,很难做到对众多厂商和不同操作系统设备进行模拟。

3、移动自动化框架很难支持到回归测试颗粒度

在移动端(以iOS为例),受限于Apple的机制,大部分框架很难覆盖到与iOS系统/第三方App交互的场景,例如系统通知跳转、实时通讯应用信息发送等场景。而若无法覆盖核心功能,那么自动化测试的落地实则是在给自己和团队挖坑,得不偿失。

这些问题在随着WebDriverAgent的成熟以及XCode 9的新特性 —— Multiple concurrent simulators的出现,得到了极大程度的解决,我们可以像对Web应用一样,对移动端应用在不同的simulator上并发执行测试用例,极大提升了测试反馈效率。而且,测试人员不再受限从而可以编写覆盖率更高的测试用例。

除了普适性问题之外企业对移动测试方案潜在需求?

在项目的具体实施过程中,除了我们经常被这些普遍存在的细节问题困扰之外,企业或组织级客户已经对移动端自动化测试提出了更高的要求。在一次机会给客户讲解移动端自动化测试趋势时发现,新的框架的确会使客户眼前一亮,但是,在实践上的优势无非是你比其他人先研究了什么,这样的领先微乎其微,在交流过程中观察到客户更大的痛点是:

如何同时覆盖到更多物理设备?如何更好的构建和重用基础设施?如何跨地域高效使用测试资源?

带着这几个问题,我们对比了一些现有的可用方案,例如AWS device farm。Device farm是针对移动App提供的测试服务,用户可以对在AWS托管的基于iOS和Android物理设备测试原生和混合应用。用户既可以使用各种测试框架来做自动化测试,也可以远程访问设备进行应用程序的测试和调试。

但是该解决方案也是有一定局限性的,当测试运行期间同时执行测试的设备最大只有五个,而运行测试的时间也被限制到60分钟。当然上述的限制可以根据需要适当的放松,但是企业和用户不得不承担价值不菲成本。

与AWS device farm类似,SauceLabs和Xamarin也提供类似的平台,那SauceLabs的服务举例,如果想使用无限运行时间,支持24个并发运行设备,模拟器用户需要每月承担3576刀,而如果想使用真实设备进行测试,大概需要每月花费7200刀。这种昂贵的成本对于企业很难承受,而且重要的是这种资源是无法复制,企业不得不持续为云服务支付高昂的费用。

安全性也是企业需要考虑的问题,用户不得不在云测试平台上传自己的IPA或APK。我们当然可以信赖AWS的安全机制。一些对安全性要求较高的企业来说,更想规避这样的风险。

打造私有移动真机测试平台

通过分析,对于客户的需求大概涵盖几点:真实设备、并发、成本、安全、可重用。鉴于这些需求,我们把目标进行拆分:

1.设备管理——服务发现与注册

在该实例中我们使用WebDriverAgent作为测试框架,需要运行在每一个物理设备上,我们可以把这些物理设备当作Agent集群。这些集群设备就是我们运行WebDriverAgent的服务终端,我们可以通过很简单的程序让WebDriverAgent自动在设备上运行。通过服务发现与注册机制,把WebDriverAgent服务注册在通过Ansible管理的Proxy上。而服务发现与注册不单单解决了复杂的设备管理,而且可以解决分布式团队合作时设备跨地域有效利用的问题。

2.平台数据可视化

对于一个测试平台来说,如何把所有可用的服务(机器)、服务状态、自动重启和crash报告等数据可视化给企业终端用户,是极为重要的。那老牌Apache zookeeper来说,提供了友好的服务可视化管理功能并且可以根据用户需求进行二次开发。重要的是,这些底层基础设施服务可以在之后的任何一个移动测试项目中被重用。

3.自动化测试运行和报告生成

自动化测试平台虽然提供了强大的服务(设备)管理、服务可视化等功能。而自动化测试的核心需求依然是如何保障测试的独立性、稳定性、易维护性、重用性和覆盖率。通过WebDriverAgent跨语言测试框架,我们可以像架构Web自动化测试一样来开发针对移动端的测试工程。但需要注意的是移动测试不同的是真实物理设备,而不是计算机的某个进程。另外,如何接触测试场景的相互依赖、保证测试间的独立性,以及如何清理测试环境,需要大家在进行移动端架构的时候事先考虑。

这样一来,我们如果可以解决这三个问题,就可以不受昂贵的成本限制,为企业量身定做适合自己的业务规模的移动测试私有云了,不但为企业和组织机构构建了大型测试服务平台,同时也解决了之前提到的普适性问题。

总结

随着DevOps的发展,软件工程的开发、部署、上线、应急预案等都被自动化监控和处理。如果我们依然停留在“成熟”的解决方案而缺少思考,那么留给QA/测试人员的发展空间越来越少。

我们需要通过对测试技术细节的不断归纳、对比和练习,抓住领域发展趋势和真正的客户诉求,结合其他非测试技术,帮助自己在测试技能上有所突破,同时帮助自己提升构思和落地解决方案的能力。


更多精彩洞见,请关注微信公众号:思特沃克

Share

性能测试问题与思考

性能测试对于大部分测试人员都是一个神秘地带,因为在很多公司,性能测试都是由一个性能测试团队来做,所以普通测试人员没有机会接触到真实的性能测试,因而很难学习到很多新的测试实践知识。

市面上现在有非常多关于性能测试的书籍,其中不少书籍都能够系统地介绍性能测试。今天我想通过另一种方式来介绍性能测试,那就是通过提出一些关于性能测试的问题,然后针对问题进行思考。希望通过不一样的方式让读者以另外一种视角来思考和学习性能测试实践。

1、如何在敏捷开发中做性能测试?

敏捷开发,由于其持续集成、快速反馈等特点,需要性能测试工具支持轻量化、集成CI服务器、全代码化等特性,所以传统的性能测试工具比如JMeter和LoadRunner等已经很难适用于敏捷开发。在敏捷开发中,性能测试应该需要具有以下特点:

  • 性能测试是持续集成和持续发布的一部分,尽可能早的发现性能问题,从而降低修复成本。这样可以使得很多性能问题在开发过程中被持续的尽快发现。建议将性能测试写成故事放到每个迭代里面去,见下图:
  • 性能测试脚本易读,易维护。比如代码化的脚本GatlingLocust等。下面是Gatling的DSL示例代码:
  • 可视化,报表易读,每个人都能及时了解状况 。下图为Jenkins集成了一个Gatling插件后所展现的Gatling持续测试报表。

通过在敏捷开发中做持续的性能测试,使得性能测试也可以:小步快跑->快速反馈->持续改进->持续交付。

2、如何通过数据分析更有效的做性能测试?

大部分情况下大型项目的性能测试需要的时间和人力都非常高,因为:

  • 用户并发要求高,测试硬件成本高
  • 测试功能点多,测试量大
  • 耐久性测试,测试时间长

其次是测试的有效性差,因为测试人员在测试环境中很难模拟真实用户的操作,比如访问的顺序分布,访问的强度分布以及用户端的各种访问参数。

为了解决这两个问题,应该通过用户数据分析来获得真实的用户行为数据,并用其来构造性能测试用例,其中可以用下面这个漏斗模型来进行思考:

通过这个漏斗模型可以知道,为了快速得到真实有效的性能测试数据模型,需要通过筛选并整合真实的用户数据,而并不是靠测试人员在实验室中想象出来的数据。

那如何进行用户行为分析呢?下面尝试用三个例子来进行说明。

第一个例子是一个用户注册流程,通过用户行为的数据分析可以得到每个功能点上用户的访问量。见下图:

图中展示了用户注册流程的6个步骤,分别是:

  1. Getting Started
  2. Account Information
  3. Personal Information
  4. Financial Information
  5. Review Information
  6. Thank You Page

其中第一个步骤有18606次访问,然后有71%的访问用户选择继续,但是只有13131(70.6%)到达了第二个步骤。最终只有925(5%)的用户完成了注册。由此可以知道不同步骤的真实访问比例,从而得到性能测试的数据模型和策略。

第二个例子是用户使用的浏览器的数据统计,如果性能测试需要模拟不同的浏览器,那么这些数据分析结果也可以用以确定浏览器在性能测试中的权重。

通过这个统计表可以知道使用IE浏览器的用户最多,所以在生成性能测试数据的时候应该多生成一些基于IE浏览器的数据,比如User-Agent等。

第三个例子是统计的用户访问地区,对于有些大型的互联网应用是需要进行多地区模拟来测试不同地区互相访问时的性能。这个数据统计结果可以帮助其设计更有效的这类性能测试用例。

通过这个统计表可以知道英国的用户访问量最多,而美国的访问量第二。如果应用服务器部署在美国,那么就应该尽可能的在英国架设测试服务器,通过在英国的测试服务器来测试美国的应用服务器,从而测试跨国网络的性能,并且还需要在产品环境检测英国到美国的网络性能,从而及时发现性能问题。

通过对这些真实用户数据的分析,可以设计更有效的性能测试模板,下面是一个性能测试模板的样例,其中每个功能点上圆圈中的数字代表这个功能点在真实环境中的用户访问权重。权重越大的功能点在整个性能测试模板中应该测试量更大,所花费的成本更高。

常见的Web系统用户数据跟踪与分析工具有:

  • Adobe SiteCatalyst:功能强大,使用繁琐,收费(贵)
  • Google Analytics: 功能较强,使用方便,免费和收费
  • 百度统计/腾讯分析:功能一般,免费

使用数据分析来生成数据模型的流程如下:收集数据->分析数据->生成测试数据模板->使用数据模板。

3、对大规模集群系统做性能测试应该注意什么?

通常中小型公司的IT系统都不使用大规模的集群,而只有大型公司才会大规模使用集群,导致很多测试人员没有机会实践和了解基于集群的性能测试。如果想学习基于集群的性能测试,除了常规的测试集群系统性能以外,还可以从以下几个方面进行思考,从而学习基于集群系统的性能测试:

  • 测试环境的真实性,由于大规模集群包含很多节点和服务,所以搭建和产品环境一样的测试环境的成本很高,导致测试环境的规模一般都比产品环境小很多。那测试这样的测试环境还有什么意义?
  • 一般集群都会使用负载均衡,但是由于存在多种负载均衡算法和配置,那么怎么才能保证负载均衡功能是按照设计和配置的进行工作?
  • 除了对集群系统进行整体的性能测试外,还需要单独对不同的服务和节点进行性能测试吗?

所以针对集群系统做性能测试不仅仅能测试系统的性能,还可以解决以上三个问题:性能规划,配置测试,隔离测试。

性能规划

对于一个大型的服务器应用系统,一般情况下都是由规模化的集群组建而成的。所以测试这类基于集群的服务器系统的时候,也需要将测试环境配置成和产品环境类似的集群系统。不过因为成本的原因,测试环境中的集群规模大都要小很多。可以通过测试小规模的集群,然后使用其测试结果,并通过数学建模推算产品环境的性能或者对产品环境进行性能规划。由于每个集群系统拥有各自不同的架构,配置和服务,所以其数学模型也是不同的。

配置测试

通过更改集群系统的各种配置,并在不同的配置下对集群系统进行性能测试,从而获得最优配置。比如辅助开发人员完成集群功能的开发与验证,比如负载均衡算法,热备等;以及辅助运维团队配置和调试产品环境的集群配置等。

隔离测试

对于集群系统的服务或者节点,开发这些服务的团队应该在隔离(stub)第三方依赖的环境下,各自对自己团队开发的服务进行独立的性能测试。从而尽早发现性能问题,尽早修复,避免在集群环境下发现同样的问题,增加调试和时间成本。

大规模集群系统基本都是复杂架构,环境也都是较为复杂的组织结构,而只有深入理解整个业务流程,系统架构以及环境结构才能有效地设计测试方案。

4、性能测试中的测试数据有几种类型?

测试数据一直是软件测试中的一个头疼的问题,特别是在性能测试中测试数据尤为重要,因为越真实的数据越能获得更好的结果。对于测试数据的类型可以分为以下四种:单一型,随机型,模板型,真实型。

单一型

它是通过录制或者观察,使用一个或者一类单一的测试数据来进行性能测试。这种数据的构建简单,但是数据过于单一,无法模拟真实用户。由于其数据构建简单,所以可以用于敏捷开发中的早期性能测试。

随机型

它是通过一些简单的数据规则,并结合随机算法生成的测试数据。这种数据和单一型比较,虽然增加了随机性,但是仍然缺乏真实性,并且其构建成本和性能问题的分析成本也相对较高。它可以用于上线前的大规模的多样化的综合性能测试。

模板型

它主要是通过数据分析并生成模板来构建测试数据。虽然它较随机型在一定程度上增加了用户真实性,但是准备数据的成本很高。在项目成本和资源允许范围内,可以结合模板型和随机型的方法,从而更为有效的进行性能测试。

真实型

它是通过直接导出或者重定向产品数据来做性能测试数据。它完全是真实的用户数据,构建成本较低,但是存在数据安全性的问题,比如数据泄露。在数据安全性可以得到有效保护的情况下是可以使用真实型数据来进行性能测试。

测试数据生成和管理对于一个大型项目的性能测试是十分重要的,所以如何高效的生成有效的测试数据成为了首要的任务。通过这四种测试数据类型,可以快速的判断在项目当前阶段适合使用那种类型的数据,从而避免一些弯路。

5. 其他问题

除了以上问题和思考,我还准备了一些其他的基本问题给读者自己去思考,从而通过思考问题来学习性能测试。

  • 性能测试主要包含哪些类型以及分别的作用是什么?
  • 前台页面的性能测试应该注意哪些问题?
  • 对于并发用户很少但是稳定性要求很高的系统需不需要做性能测试?为什么?
  • 对于后台有大量异步批处理需求的系统应该怎样进行性能测试?
  • Profiling是不是性能测试?什么时候应该做它?
  • 常见的性能测试工具有哪些?怎么选择性能测试工具?
  • 如果测试环境和产品环境的硬件配置不同,如何通过测试环境的测试结果评估产品环境的性能?
  • 在设计性能测试用例时需不需要考虑Think Time?
  • 中小型项目的性能测试都需要注意些什么?
  • 性能需求的来源有哪些?
  • 如何使用云服务进行超大规模性能测试?

更多精彩洞见,请关注微信公众号:思特沃克

Share

聊一聊契约测试

什么是契约

如果从契约产生的阶段来说,现有资料表明最早要追溯到西周时期的《周恭王三年裘卫典田契》,将契约文字刻写在器皿上,就是为了使契文中规定的内容得到多方承认、信守,“万年永宝用”。所以订立契约的本身,就是为了要信守,就是对诚信关系的一种确立。诚信,是我国所固有的一种优良传统,也是延续了几千年的一种民族美德,在中国儒家的思想体系里,是伦理道德内容中的一部分。

《现藏于台北故宫博物院》

现实真的是那么美好吗?小时候的价值观教育未能改变社会的现状,缺少契约精神的案例却比比皆是。

那么,契约真的要消失了吗?不尽然,在软件测试领域,我们又重新拾起了契约这把利器。

发展历程

接下来让我们把时间回溯到2011年初,回到老马的文章《集成契约测试》中来,回顾一下契约测试的起源和发展历程:

假设我们有这样一个场景:A团队负责开发API服务,B团队进行API调用消费服务。

为了保证API的正确性,我们会对外部系统的API进行测试(除非你100%相信外部系统永远正确和保持不变),这很可能就会导致一个问题,当外部系统并不那么稳定或者请求时间过长时,就会导致我们的测试效率很低,并且稳定性下降。比如当外部API挂掉导致测试失败时,你并不能完全确信是API功能被更而改导致的失败还是运行环境不稳定导致的请求失败。

最初,解决这个问题的方案是构建测试替身(Test Double),通过模拟外部API的响应行为来增强测试的稳定性和反应速度。实现手段是在测试环境中搭建一个模拟服务环境,通过设定一些请求参数来返回不同的响应内容,然后再被内部系统调用,来保证调用端的正确性。构建模拟环境时我们可以使用几种不同的测试手段,如Dummy,Fake,Stubs,Spies,Mocks等。可是,问题又来了,如果使用测试替身那如何能保证外部系统API变化时得到及时的响应,换句话说,当内部系统测试都通过的通过时,如何能保证真正的外部API没有变化?

一个比较简单的方式是部分测试使用测试替身,另外一部分测试定期调用真实的外部API,这样既保证了测试的运行效率、调用端的准确性,又能确保当真实外部系统API改变时能得到反馈。

是不是到这里就皆大欢喜了呢?

如果剧情到这里就结束的话,未免太过俗套。这个方案最大的缺陷在于API的反应速度,真实外部API的反馈周期过长,如果减少真实API测试间隔时间就又会回到文章最开始的两难境地。

那么如何解决这个问题呢?先来让我们剖析一下前面几种解决方案的共通点。

在上面的场景中,我们都是已知外部API功能来编写相应的功能测试,并且使用直接调用外部API的方式来达到验证测试的目的,这样就不可避免的带来两个问题:

第一,服务消费方对服务提供方API的更改是通过对API的测试来感知的。

第二,直接依赖于真实API的测试效果受限于API的稳定性和反映速度。

解决方式首先是依赖关系的解耦,去掉直接对外部API的依赖,而是内部和外部系统都依赖于一个双方共同认可的约定—“契约”,并且约定内容的变化会被及时感知;其次,将系统之间的集成测试,转换为由契约生成的单元测试,例如通过契约描述的内容,构建测试替身。这样,依赖契约的测试效率优于集成测试,同时契约替代外部API成为信息变更的载体。

对于契约来讲,行业内比较成熟的解决方案是基于YAML标记语言的Swagger Specification(OpenAPI Specification),或者是基于JSON格式的Pact Specification

通常的做法是API的提供者使用“契约”的形式,将功能发布在公共平台,给调用方进行说明和参考,这里我们可以暂时称之为Provider-Driven-Contract。这种做法的潜在问题是,功能提供方的API返回内容是否都满足所有API调用者的需求不得而知。所以,针对这个问题,依赖关系再一次反转,契约测试就摇身一变成为了Consumer-Driven-Contract test(CDCT), 通过给API提供方提供契约的形式,来完成功能的实现。

难道CDCT成为了问题终结者吗?请听后面分解。

注: 契约测试其中一个的典型应用场景是内外部系统之间的测试,另一个典型的例子是前后端分离后的API测试,这里不做过多展开。

契约测试的维度

1.测试覆盖范围对比(纵向)

单元测试:对软件中的基本组成单位的测试,大多数是方法函数的测试,运行速度快。

契约测试:对服务之间的功能进行的测试,运行速度基本与单元测试相同。

E2E 测试:对系统前后端或者不同系统之间的集成测试,大多通过模拟UI操作的方式实现,运行速度三者之中最慢。

2.测试效率对比(横向)

环境依赖:

  • 单元测试:程序集
  • 契约测试:程序集、依赖契约文件、虚拟路由服务
  • 端到端测试:程序集、真实路由服务、前端UI
  • 运行速度: 单元测试 > 契约测试 > 端到端测试

Pact官方给出的几个场景:

适用场景:

  • 团队能把控开发过程中的Consumer和Provider端
  • 适合Consumer驱动开发的场景
  • 对于每个独立的Consumer端,Provider端都能管理好需求。

不适用的场景:

  • 公共API或者是OAuth授权服务
  • Provider端和Consumer端没有良好的沟通渠道
  • 针对性能的测试
  • Provider端的功能性测试(Pact只测试内容和请求格式)
  • 对于不同输入有相同的输出,并未达到验证的目的
  • 当前测试输入需要依赖之前测试返回的结果

以上对比说明契约测试所要解决的问题是替代系统之间的集成测试,通过契约和单元测试的方式加速系统运行。同时也说明契约测试存在一些不适用的场景,要依据使用场景区别对待。契约测试没有取代单元测试以及E2E测试。

契约测试与CD的整合

最开始,我们的pipeline是这样的,单元测试是独立的测试,当通过单元测试后运行集成测试。此时集成测试成为了系统瓶颈,而且一旦集成测试失败,就必须被迅速修复,其他pipeline只能等待其修复,否则任何新的变更都会测试失败。

一个解决办法是将集成测试分散在每个pipeline上,每次集成测试运行的版本是当前的最新代码和其他系统的上一次通过版本之间的测试。这样解决了测试的独立性以及不会阻碍其他pipeline测试的效果,然后将通过测试的不同系统的package按照版本保存。但是这样一来,集成测试的缺点就更为明显提现出来,第一是系统部署时间长,每次集成测试需要运行同样的测试在不同pipeline上,增加了测试成本和反馈周期。

​​ ​​ 接下来,我们使用契约测试替代集成测试。这样有几点好处不仅解决了独立测试的目的,同时解决了集成测试慢和部署时间长等问题。

为了保证契约测试的正确性,契约文件由Consumer端生成,然后Provider端来实现API,我们使用CDCT来改造我们的pipeline。

我们先假设B系统希望A系统提供新功能,如果按照图中黄色步骤来提交的话,则会测试失败,原因在于此时,契约文件是最新的B-A.consumer.1.1.pact与之对应A-B.provider.1.0.jar不是最新的,所以测试失败。

按照图中步骤2运行,当提交A的pipeline时,当前版本的A已经升级到1.1,而契约文件还是1.0版本,没有break测试的情况下,最终将A-B.provider.1.1.jar提交到服务器上。​

然后按照图中步骤3运行,A-B.provider.1.1.jar和B-A.consumer.1.1.pact完美契合,最终又将B-A.consumer.1.1.pact提交到服务器。所以,改成CDCT之后,虽然产生了一定的提交顺序依赖,但是带来的更多的好处是确保契约文件的产生是调用端提出,并且保证当前最新,确保系统的正确性。

喜欢思考的同学不难发现,CDCT存在自身的缺陷,一个简单的例子是当B存在一个已有的契约约束A的一个功能,当B需要A更新其API时,是先提交B的契约测试,还是更改A的功能到最新版本?其实二者都不可行。

解决办法万变不离其宗,就是大家熟悉的不能再熟悉的重构心法,由王建总结的十六字箴言:​

我们分五步来完成API的更新:

  1. Provider端提交一个新的API来保证新功能,同时旧的API功能不变,提交并通过测试。
  2. 将Consumer端API的调用指向Provider端的新API,并更新契约文件以约束新功能。
  3. 将Provider端旧API同步更新为新API,提交并通过测试。
  4. 将Consumer端指回旧有API,其他保持不变。
  5. 将Provider端临时过渡的新API删除。

至此,我们解决了API更新时如何保证契约测试的提交顺序,如果是删除API,则直接删除Consumer端的契约测试即可。

需要思考的问题:

1.如果并行测试的话,谁先提交成功的版本,另外一个测试是否要重新运行?

设想,当两个并行pipeline A和B,同时运行时,A中跑的是A1.1和B1.0,B中跑的是B1.1和A1.0的测试,假如双方均能通过各自的测试,但是新版本不兼容(A1.1和B1.1测试失败),双方都将各自的新版本保留,这样就造成了存在相互不兼容的两个版本。目前解决方案是,人为制造一个“瓶颈”,保证同时只有一个契约测试在运行,保存的只有一个版本。

2.契约测试可维护性如何?

构建契约测试类似于单元测试,并且在Pact的框架下十分方便维护。但是,测试框架本身还有一些问题,诸如,大小写敏感,空值验证,只有一份契约文件,契约测试分组等。

(以上是基于pact 1.0的实践,pact2.0使用了正则表达式以及TypeMatching等机制解决了验证“具体”值的问题,更多详细内容请关注pact官方文档

结语

契约测试不是银弹,它不是替代E2E测试的终结者,更不是单元测试的升级换代,它更偏向于服务和服务之间的API测试,通过解耦服务依赖关系和单元测试来加快测试的运行效率。


更多精彩洞见,请关注微信公众号思特沃克

Share

聚焦测试,驱动卓越

在经历了“七年之痒”后,蓝鲸项目进入第八个年头,项目的一切趋于稳定。团队倡导持续改进,这时大家的感觉是已经尽力做到最好,似乎没有什么可以改进的了。为了突破这个局面,项目重新聚焦测试,从质量和测试的角度对现状进行了一次评估。

评估采用的是基于软件测试原则的模型,本文就是跟大家分享一下这个模型。

测试原则

在2012年澳大利亚敏捷大会(Agile Australia)上,ThoughtWorks非常资深的测试实践带头人Kristan Vingrys分享了如上测试原则,这些原则是ThoughtWorkers在多年软件测试实践基础上总结出来的。

1. 质量内建(Build quality in)

You cannot inspect quality into the product; it is already there. — W.Edwards Deming

著名的质量管理专家戴明指出:产品质量不是检测出来的,从产品生产出来后质量就已经在那了。这同样适用于软件产品。

缺陷发现的越晚,修复的成本就越高。质量内建要求我们做好软件开发每个环节,尽早预防,以降低缺陷出现后的修复成本,要减少对创可贴式的补丁(hotfix)的依赖。

推荐实践: TDD、ATDD等。

2. 快速反馈(Fast feedback)

每个环节的任何变化都能最快的反馈给需要的人,从而能够基于当下最新信息做出明智的决定,降低风险。这要求我们对系统进行频繁的测试,缩短回归测试的周期。

推荐实践:

  • 符合测试金字塔结构的自动化测试,让每一层的测试都能发挥尽可能大的价值,给出最快速的反馈;
  • 持续集成,尽早排查集成引起的问题,降低集成所带来的风险。

3. 全员参与(Involve everyone)

这次上线好多bug,QA是怎么测的?!

那个xxx组在上线前发现了很多的bug,他们的QA真给力!

成也QA,败也QA…如果还是这样的认识,那是极为片面的。测试不仅仅是QA的事情,团队成员要一起为质量负责,软件开发生命周期的测试相关活动需要全员的参与。

全员参与的好处是利用不同角色的不同领域知识和不同的思维模式,不仅可以使得测试的质量更高,同时还能最优化利用测试资源,做到价值最大化。

推荐实践:

  • 自动化测试:QA和BA结对用DSL编写测试用例,QA和Dev结对编码实现测试,生成业务人员可读的测试报告;
  • Bug bash(bug大扫除):团队不同角色一起参与的一个找bug的测试活动。

4. 测试作为资产(Tests as asset)

自动化测试帮助我们验证系统功能的正确性,好的自动化测试还有文档的功能,是宝贵的资产。如果每个项目都构建自己独立的自动化测试,没有跨项目共享,其浪费显而易见。

这个原则要求把自动化测试的代码跟产品开发的代码一起,当做资产管理起来,在不同项目间做到尽可能的复用。这笔宝贵的资产能帮助我们更好的统计跨项目的测试覆盖率,更好的优化测试。

推荐实践:利用版本控制管理工具把测试代码和产品构建代码一起管理,都作为产品的一部分。

5. 更快的交付(Faster delivery into production)

任何一个idea越快做成软件产品交付给用户,给企业带来的价值越大。

该原则要求我们把测试活动融入软件开发生命周期的每个环节,不要在后期进行长时间的集中测试;同时测试人员的关注点不再是发现更多的bug以阻止不符合质量要求的产品上线,而是把目标放在如何能够帮助团队尽快的让产品上线,让企业投资回报更早,也就是更快的赚钱。

推荐实践:自动化构建流水线、关注平均恢复时间、发布与部署解耦等。

6. 清晰一致的测试视图(Clear and consistent view of testing)

用可视化的报告给客户和内部团队展示测试的状态和产品内外部的质量,对项目的质量和风险把控是非常有帮助的。不同项目各自采用五花八门的图表样式,将不利于项目间的信息共享和比较,无端增加复杂性,带来浪费。

因此,我们需要把状态报告做的尽可能简单、清晰,并且保持跨项目的指标一致性;同时,我们不应该为了让某个指标变得好看而改变我们的行为,整个报告要诚实开放,这样才能真实反映出项目的状况。

7. 优化业务价值(Optimize business value)

开发软件无疑是要给客户的业务带来价值,软件测试也需要为这个目标服务,测试要跟业务价值保持一致,帮助客户优化业务价值。要求做到:

  • 测试不仅是保险,不仅是保证软件质量的;
  • 要有目的的关注变化的特性,不要盲目的散弹枪式的对任何特性进行测试,要有优先级;
  • 要能帮助企业驱动新的特性和功能;
  • 帮助客户创造安全的尝试新点子的环境,提供快速的反馈。

推荐实践:

  • 基于风险的测试,根据业务优先级需要调整测试策略,在测试过程中尽可能规避给业务带来的风险;
  • 生产环境下的QA,通过收集生产环境的真实用户行为和应用使用数据,对业务的优化做出贡献。

评估模型以及在项目中的应用

评估模型就是将上述七条原则的每一条细化,列出该原则对应的实践和行为,并给每个实践或行为设定0-5分的不同评分标准,最后统计各个原则的总分,形成类似下图的结果报告:

在项目中的应用

以Cristan分享的模型为基础,由Tech Lead和几个DEV、QA成立一个评估小组。

第一步:分别根据各自的理解给项目打分,结果是很有意思的,请看下图:

根据这些结果,可以看出大家的认识是不太一致的。

第二步:评估小组对模型中的每条细节进行review,做适当修改以更符合项目情况,并且在评估小组内达成共识。其中,所做的修改包括修改原有的实践评分指标、增加新的更适合项目和当前技术趋势的实践、删除过时的或者不符合项目特点的实践。

第三步:根据更新过后的模型指标对项目上的一个team做评估试点,详细分析该team对应到测试原则各个维度的well和less well部分,由评估小组成员一起打分,得到该team的评估结果图。

第四步:根据评估结果并结合项目目标排定需要改进的优先级,制定出改进action,并更新给试点team执行。

后续:试点一个周期后再次评估,并重新review评估模型,再推行到整个项目。同时,周期性的进行新的评估和制定新的action,以做到持续的改进和优化。

总结

应用程序的质量、测试的快速性、以及上线后轻松自信的更新服务的能力,是帮助企业实现业务价值最大化的关键因素之一,一直是我们所追求的。

基于测试原则的评估模型,可以帮助我们在追求这个目标的道路上少走弯路,帮助我们持续的改进,以驱动出更加卓越的软件。


更多精彩洞见,请关注微信公众号:思特沃克

Share

组件测试:改建遗留系统的起点

在遗留系统中工作,无论是开发新功能,还是对旧功能进行修改,抑或是通过重构以期重拾其往日的雄风,都会面临大量的挑战。这些挑战主要来自于流失的业务知识、失传的技术和腐坏的代码等。一般来说,改建遗留系统通常会先对其添加必要的测试,再开展重构和重新设计等一系列工序,从而提升其内建质量。

Martin Fowler 在微服务的测试策略的分享中,详细讨论了各种测试方法及其适用场景。在该讨论中,他介绍了组件测试

组件是在大型系统中封装良好的、可独立替换的中间子系统。对这样的组件进行单独的测试有很多好处,通过将测试范围限制在组件之内,就能在对组件所封装的行为进行验收测试的同时,维持相较于高层测试更好的执行效率。在微服务架构中,组件也就是服务本身。

Martin Fowler 还按照测试时调用组件的方式,以及在对组件所依赖的存储或服务构建测试替身时,测试替身位于进程内部还是进程外部来把组件测试分为进程内和进程外两种形态。

实践中,为遗留系统添加单元测试和端到端的界面测试都会遇到其对应的困难,而我们发现组件测试却能由于其关注行为的特点在单元测试和端到端测试之间取得平衡,对于改建遗留系统来说,它提供了一个不错的起点。

避开单元测试实践的被动

遗留系统从最初发布到现在,早已过去多年,当初的开发人员早已离开,徒留一段代码给后来者。在遗留系统上的工作通常要求不能破坏现有其他功能,只能按要求“恰好”地修改。作为敏捷开发人员,第一步的计划就是使用单元测试来保障已有功能不被破坏。但团队很快就会发现遗留系统使用的技术失传已久,新的团队中基本没人了解,要基于这样的技术来构建单元测试寸步难行。对于一个没有任何自动化测试的老旧系统来说,往往也意味着其内部设计耦合度之高,想理解清楚就已经很吃力了,更遑论可测试性。

在下面的示例代码里,我们无法方便地对其中的 StockService 中所依赖的 WebClient 实例进行模拟,从而无法对 GetUpdatedStock 的功能进行测试:

  public class StockService {
    public IEnumerable<Stock> GetUpdatedStock(){
        var stockContent = new WebClient().DownloadString("https://stocks.com/stocks.json");
        var stocks = JsonConvert.DeserializeObject<List<StockResponse>>(stockContent);
        return stocks.Select(ToStock);
    }

    private static Stock ToStock(StockResponse resp)
    {
        //  对象转换逻辑略
    }
  }

另一方面,在老旧系统上的开发工作,往往也意味着接下来需要对其进行较大规模的重构,以利于更好的可维护性,更轻松地添加新功能。在这种背景之下,即使为系统添加了单元测试,接下来的重构又会使得细粒度的单元测试成为一种浪费——重构势必要修改代码设计,导致单元测试也需要跟着一起修改。

相比于单元测试的矛盾,组件测试关注 Web 应用本身的功能和行为,而不是其中某个单独的层次。实际上,很多遗留系统甚至连清晰的层次化设计都没有。组件测试对 Web 应用公开的 API 或 Web 页面源码测试,在避免陷入代码细节设计不良带来的被动局面的同时,能够保障 Web 应用的行为的正确性,而这也正是我们为遗留系统添加单元测试想保障的。组件测试关注的是业务行为,而不是代码实现细节。因此不会随着代码实现细节的变化而受到影响。所以组件测试不会限制重构手法的施展,也不会在调整设计时带来额外的修改测试的负担,相反它却可以给重构提供有力的保障,帮助确保重构的安全性。

绕过端到端界面测试的窘境

在改建遗留系统开展的实践中,不少团队为了摆脱单元测试的被动局面,尝试过为其添加端到端界面自动化测试的策略。这样几乎可以完全忽略代码细节,而直接关注业务场景。相对来说,只需要能做到自动地部署 Web 应用和必要的依赖(比如数据库),就可以对应用开展测试了。但实际执行过程中,团队发现要为老旧系统构建这样的一种环境,并不容易。端到端集成测试需要在真实的 Web 应用程序实例上运行测试,并且要求各项基础设施也尽可能地真实,包括数据库、缓存设施等。因此,要想让端到端的集成测试在持续集成环境自动地运行,就要求应用程序及其所依赖的基础设施有自动化部署的能力。老旧系统往往自动化程度很低,无法自动完成部署以开展端到端集成测试。即使 Web 应用本身的部署并不复杂,它依赖的其他服务也很难自动地部署,比如 SMTP 服务器等。

测试金字塔中,端到端测试界面测试位于较高的层次。这意味着即使成功地构建了自动化的环境,还是会由于测试所依赖的资源较多,造成测试成本相对较高的状况。由于端到端测试集成了系统的多个层次,测试用例的运行也就比低层次的测试用例更脆弱,而运行速度也会更慢。

这些挑战和特点决定了我们很难在短时间里为遗留系统添加足够的端到端界面测试案例以保障接下来的改建工作。在开展组件测试时,则完全不需要担心端到端测试的这些问题。组件测试通过一定的方法模拟并隔离 Web 应用的外部依赖,避免了复杂的部署和配置外部依赖的过程。更小型、专用的模拟层的启动和运行速度都可以根据测试的需求来定制;如果采用进程内的组件测试,更是可以进一步提高测试案例的运行效率与稳定性。

组件测试最佳实践

把 Web 应用本身看作单元测试中的被测试的单元,将 Web 应用的外部依赖都用测试替身进行模拟和隔离,并按业务场景测试组件中提供的 API 或 Web 页面的行为,即为组件测试。在进程内组件测试的实践方法中,我们直接在测试代码中自动地构建 Web 应用所需的依赖项,启动被测试的服务,然后调用要测试的 API 并执行断言。下面的代码演示了这样的测试的大体流程:动态地创建一个关系型数据库,启动 Web 应用,利用 Web 应用中 repository 的准备测试所需的数据,然后调用被测试的接口并对结果进行断言。

[Fact]
public async void should_handle_search_request_with_mocked_database()
{
   var sqliteConnection = DatabaseUtils.CreateInMemorryDatabase(out var databaseOptions);
   var appServices = SetupApplication(sqliteConnection, out var client);

   var jim = new Employee {Id = 12, Name = "Jim"};
   appServices.GetService<IRepository<Employee>>().Save(jim);

   var response = await client.GetAsync("/employees/search/im");
   var employeeString = await response.Content.ReadAsStringAsync();

   Assert.Equal("Jim(id=12)", employeeString);
}

在进程内运行的组件测试,可以选择以合适的方式对 Web 应用的依赖进行模拟。以数据访问层为例,我们可以直接对 DAO 类进行模拟,也可以在需要测试事务支持的时候为测试构建真实数据库实例,并在测试运行结束时清理这些临时创建的资源。既能享受上文所述的行为测试的稳定性,又可以获得代码级模拟的灵活性。

具体地,由于要在测试代码中按需启动应用程序,这对 Web 应用程序的基础设施提出一些要求。如果我们基于 ASP.NET WEB API 或者 Spring Boot 等框架开发应用,那么框架就已经提供了这种能力。对数据层进行模拟时,在简单的情形中可以采用内存重新实现的 RepositoryStub,必要时也可以采用内存中运行的嵌入式数据库,例如 SqlLiteH2 数据库,并且使用数据框架动态地在数据库创建必要的表结构(Schema),Entify Framework Code First 以及 Hibernate 等流行的 ORM 框架均具有这样的能力。对于外部的 HTTP 依赖,同样可以采用临时实现的 Stub 对象,也可以采用社区中流行的 mockhttpClient-driver 这样的工具库。这里,本文也准备了一份简单的示例程序供读者参考,提供了 C# 版本Java 版本 可用。

组件测试在形式上看,是一种单元测试,而从测试范围上看,它又是一种集成测试,在一些场合,我们形象地把它理解为“集成的单元测试”。但它与单元测试的关注点是有所区分的。在编写组件测试的用例时,不要过于关注代码逻辑细节,而应该从业务场景出发关注 Web 应用的行为。比如在一个用户注册的 API 进行测试时,可针对注册 API 成功的场景测试给出的响应是正确的,并给用户发送了一封确认邮件,而不是向 API 提供多个用户名用例并测试哪些用户名是合法的(那些应该由测试用户名验证程序的单元测试覆盖)。

与进程内组件测试相比,进程外的组件测试则直接对部署后的服务进行测试,更具有集成性,但由于进程外的组件测试在运行之前需要对 Web 服务进行部署和启动,因而其成本更大;测试运行时由于需要通过网络调用,所以效率也会相对较低。所以在进程外运行组件测试并没有什么优势。它只是在进程内组件测试无法高效开展时的一种妥协。除非要改建的遗留系统的外部依赖无法高效地基于代码进行设置、不能通过代码在进程内启动,否则应该优先采用进程内的组件测试。

总结

没有人愿意每天与遗留系统为伍,但总有些约束让我们不得不妥协。基于遗留系统开展工作,总是会遇到很多挑战。在实践中,我们发现在遗留系统的改建过程中,组件测试总是能够在我们遭遇困境时,给出令人满意的答案。

在实践组件测试时,如果一开始不能做到在进程内进行组件测试,可以先从进程外开展,而后逐步实现更稳定高效的进程内组件测试。需要注意的是,组件测试在改建遗留系统的过程中,能成为在现时约束下的一种可贵折衷。但它并不能代替其他类型的测试,我们依然需要借助其他类型的测试来对应用进行更完整的保障。组件测试只测试了应用(组件)内部的行为,因而在必要时可能要采用契约测试等方式来关注系统间的交互行为的正确性。在开发新功能时,我们还是要优先考虑成本最小、最利于保障系统设计的单元测试;而在保障业务场景时,必要的端到端界面测试依然是必不可少的。


更多精彩洞见,请关注微信公众号:思特沃克

Share