标签归档:软件测试

软件测试人员该何去何从?

“好多QA转PM,因为QA(的地位)始终是要低一些”

“我现在做的事情跟几年前没有区别”

“资深QA在项目上做的事情新来的毕业生也能做”

上面的话你是不是也有同感?我相信大部分人会这么认为,因为这些表面上看起来的确是这样的!

那么,软件测试人员或者说QA真的有这么惨淡吗?

对于开篇引用的几句话,我们一一来分析一下。

测试工作的价值不容置疑

“好多QA转PM,因为QA(的地位)始终是要低一些”

说这话是没有看到QA所做工作带来的价值。相反的,我认为QA之所以可以转PM是QA工作过程中获得的锻炼挺多的,不仅可以转PM,可以转PO,技术型的QA还可以转Dev。

其实,QA和PM并没有地位高低之分,只是分工和职责不一样,QA转其他角色并不是地位的改变,可能只是更加适合自己。积极主动的做好本职工作,都能为团队带来很大价值;做的不好的话,都同样的不能带来价值。况且,做的不好的PM可能影响到整个团队,所带来的价值远不如一个优秀的测试人员带来的价值大。

团队协作才能成功

我们应该以合作的心态看待这个问题,一直强调的团队为质量负责,需要每个人都有团队的意识,有分工只是因为兴趣特点和擅长领域不同而已,并没有高低贵贱之分。

质量越来越受到各行各业的关注,质量问题不容忽视。软件质量的保障工作,软件产品的测试当然也是非常重要有价值的,这一点根本不用怀疑。

只是,质量的好坏带来的价值不是那么直接可见的。反而需求人员多分析了几个需求,开发人员多开发了几个功能点,又或者多写了几个自动化测试,这些都是显而易见的,似乎带来的价值更大,更容易被人认可和重视。而另一方面,需求的验证、测试的设计、质量状态的关注、风险的把控、快速的发现和定位问题,这些是不容易被量化的,也就不容易被重视或尊重。

能力提升是关键

无限风光在险峰

“我现在做的事情跟几年前没有区别”

这是只看到所做的事情似乎没有差异,比如说都是一起分析需求、设计测试、测试story、写自动化测试等,可能的确几年前就做这些事情,现在还是做这些事情。但是,我相信只要你在做每件事情都能认真对待,有自己的思考和总结,就不会一样。比如:

  • 同样的分析需求,几年前可能只看到BA写出来的需求,看看有没有边角case漏掉了;而现在的你可以从行业业务角度去看待这个需求整体考虑的合理性,是不是能给用户带来价值、能给企业带来竞争力。这两者还是有很大的区别的。
  • 同样的测试story,几年前可能只是根据验收标准和自己想到的一些边角case去测试,一个story需要一天才能测试完;而现在的你,利用自己对于领域知识的掌握、技术的了解、系统功能的熟悉,结合自身这么多年阅历和增加的常识,半天估计能测试包含几个story的一个feature,或者一个junior测试人员测试过的story,你拿过来一下就能发现一些问题。这就是成长,这就是价值!

“资深QA在项目上做的事情毕业生也能做”

如果只是看所做的事情,可能还是停留在表面,跟上一条讲的几年前的自己和今天的自己一样。

当然,有很重要的一点,资深QA不能仅仅是工作年限长,得是有真正的能力,不然的话可能还不如优秀的毕业生。

QA能够随着年龄和工龄的增长,让自己的能力也能不断的提高,才能让测试工作有更多价值的体现。因此,能力提升至关重要!

那么,能力该如何提升呢?

能力提升路径

能力提升路径

看似相同的事情,不同能力的人做出来的效果不一样。为什么他解决问题的能力那么强?我们来了解一下学习提升的过程。

第一阶段,知识积累

通过阅读、听课、观看视频等方式可以获取到知识点,将这些知识点总结归纳之后,变成自己理解的知识。

这是第一阶段知识积累的过程。

第二阶段,经验积累

将所学知识进行试验,进一步用于实际项目,获取实践经验,不断反复的实践可以获得经验的积累。

这一阶段还不够,还没变成真正解决问题的能力。

第三阶段,能力提升

在实践中坚持回顾和总结,对实践过程进行批判和改进,并且举一反三的运用所学知识,将会实现能力的积累。

到此,就实现了知识到能力的转变过程。

积累和分享很重要

前面每个阶段都可以获取新的知识,然后经历同样的知识-经验-能力的转变,不断的积累,将会实现能力的提升;每个阶段都可以把知识或经验分享给他人,在帮助他人获得相应知识的同时,更是自身能力提升的一个非常好的方式。

多次反复的知识-经验-能力的转变,达到一定积累之后就会带来惊人的效果,这不是一个线性的增长。

在整个过程中不断发掘自己的兴趣点,将学习、兴趣有机结合起来,会达到事半功倍的效果。

终身成长

了解了能力提升路径,很重要的一点还有可能是我们需要转变固有的思维模式。这里给大家推荐我非常喜欢的一本书《终身成长》,书中讲到两种思维模式:固定型思维模式和成长型思维模式,具备成长型思维模式的人将更容易获得成功。我们需要更多的关注自身的成长,而不是关注外界、跟外界进行比较。

《终身成长》

前面所讲并不只是跟软件测试人员相关,可以适用于任何角色、任何职业的朋友,只是同样作为质量工作者,听到不少人的担忧,才撰写此文。

相信积累多了,就会发生质变!

最后,让我们一起多阅读、多学习、多实践、多思考、多总结、多分享,做到终身成长!

软件测试人员的挑战与机遇

“我们公司的测试好多都转业务或开发了,还有的转管理了,测试做不长久…”

“现在好多公司已经不招测试人员了,感觉测试没有什么前途…”

“ThoughtWorks技术雷达上都是开发相关的内容,测试相关的内容越来越少…”

软件测试总是被看做没有技术含量、没有前途的工作,很多做软件测试的朋友也比较迷茫,表示发展受限。在这个技术飞速发展的时代,各行各业都在实行数字化转型,各种高新技术似乎离测试人员越来越遥远…

那么,测试人员真的是前途渺茫吗?本文将根据ThoughtWorks最新发布的第20期技术雷达来分析当前流行的技术给软件测试人员带来的影响是什么,有哪些机遇与挑战。

技术雷达上的内容涵盖有技术、平台、工具和语言&框架四个维度,我观察到其中跟测试人员关系比较紧密的主要有以下几个方面:

1. 支持快速、持续交付的基础设施与DevOps实践

质量和速度是最关键需求,为了适应各行各业对速度的要求,配套的支持快速、持续交付的基础设施与DevOps实践是成功之必备。技术雷达上与之相关的条目有很多,比如:Terraform生态系统和四个关键指标等。

  • Terraform生态系统

Terraform是一种安全有效地构建、更改和版本化基础架构的工具,可以管理现有和流行的服务提供商以及定制的内部解决方案,正在迅速成为通过声明式定义来创建和管理云基础设施的首选工具。本期雷达Terraform相关的内容重点包括Terratest(用于测试基础设施代码),以及GoCD的新提供商(可以使用Terraform配置GoCD)。

基础设施不仅是Ops或者开发人员需要关注的领域,作为测试人员,同样需要加强这项知识的掌握:

  1. 了解了基础设施知识,结合已有的测试sense,测试人员可以和开发或Ops一起测试基础设施;
  2. 了解基础设施特点,可以指导测试的设计,在测试的时候更有针对性的关注比较脆弱的节点、环节,规避风险,增强系统的反脆弱性;
  3. 利用基础设施知识,可以指导测试环境的搭建和维护、自动化测试数据的准备和管理等。
  • 四个关键指标

埃森哲发布的DevOps报告指出组织绩效跟软件交付性能关系紧密,而衡量组织绩效的四个关键指标分别是前置时间、部署频率、平均修复时间(MTTR)和变化失败率。本期技术雷达采纳了这项技术。

作为测试人员,我们需要了解每个指标的真正含义,并且思考我们测试策略是否需要做某些调整来提供对应的指标值。比如说为了提高部署频率,可能不需要那么高的E2E自动化测试覆盖率,而是达到覆盖效果和执行效率最佳平衡的一个状态即可。

2. 支持业务灵活扩展的微服务架构

引入微服务令我们受益匪浅,使用微服务,团队可以扩展那些独立部署和维护的服务的交付,从而方便业务的灵活扩展。微服务架构正在逐渐被越来越多的企业采用。我们看到技术雷达上应对微服务的相关条目有服务网格混沌工程、API测试框架Karate等。

  • 服务网格(Service Mesh)

服务网格是一种安全、快速、可靠的运行微服务生态系统的方式。这种方式为轻松地大规模采纳微服务奠定了基础。它提供了检测、保障、跟踪、监控和故障处理功能。它提供的这些跨功能能力无需共享API网关等资产或将很多依赖库纳入到每个服务中。

  • 混沌工程(Chaos Engineering)

混沌工程是对系统进行试验的一门学科,旨在建立对系统抵抗生产环境中不确定条件的能力的信心。在去年,我们看到混沌工程从一个备受关注的 、想法,转变成公认的主流方法,来改善并保证分布式系统的弹性。主要用于以下几类故障时增强系统的弹性:基础设施故障、网络故障和应用程序失败,对应的工具有Gremlin和Chaos Toolkit等。

  • Karate

Karate是一款API测试框架,其特色在于,直接使用Gherkin来编写测试,无需依赖常用编程语言来实现测试行为。Karate是一个领域特定语言,用来描述基于HTTP的API测试。虽然该方法很有趣,可以为简单的测试创建非常易读的规范,但用于匹配和验证负载的专用语言可能会变得语法晦涩、难以理解。从长远来看,使用此风格编写的复杂测试是否将可读且可维护,仍有待观察。

微服务带来灵活性的同时,也带来很多的复杂性和不确定因素,尤其是对质量保障带来了挑战,因此微服务系统的测试也备受关注。作为测试人员,只有了解了微服务架构与服务网格的特点及其对测试的影响、混沌工程对质量保障的帮助、API测试的框架选择与测试优化等,才能更好的做好微服务系统的测试。

3. 多样化数据形态的支持

随着数据源的增加、数据规模的扩大、数据种类越来越多,相应的数据形态也呈现出多样性,包括NoSQL、时间序列、像CockRoachDB和Spanner这样提供全局一致性的SQL存储,以及提供聚合日志文件查询功能的事件流。不再是关系型数据库解决一切存储的时代了,要考虑真实需求,采用合适的策略和工具。

数据形态的变化,必然对测试也提出不同的要求。作为测试人员,需要了解不同的数据规模、不同的存储形态、不同的数据类型分别该如何验证、测试该如何设计、测试数据该如何准备,还有数据安全、数据匿名化、数据分析等数据相关技术对测试的支持等。比如,对于大量数据处理的项目,测试人员需要了解数据处理的技术与处理逻辑,分别从功能层面验证处理逻辑的正确性,以及从非功能方面考虑大量数据处理的性能、数据处理的安全规约等。

(图片来自网络)

4. 网络安全始终是重中之重

网络给我们生活带来便利性的同时,其安全性也是备受关注。2018年欧盟颁布了GDPR法令,使得众多企业不得不紧急调整系统功能做好个人身份信息的保护工作。网络安全始终是质量保障的重中之重,绝对不容忽视。本期技术雷达推荐的安全相关条目有密码即服务容器安全扫描密钥销毁技术等。

  • 密码即服务(Secrets as a service)

在构建和运维软件的价值流中,密码凭据在多个场合都需要使用:构建流水线需要使用密码来与容器注册中心等安全基础设施进行交互,应用程序需要使用API密钥作为密码凭据来获得业务功能访问权限,而服务间通信则需要以证书和密钥作为密码凭据来保护其安全,这些密码凭据不建议通过源代码的方式管理,而是采用密码即服务的技术来存储和访问。利用这种技术,可以使用Vault或AWS Key Management Service(KMS)等工具来读写HTTPS端点上的密码凭据,同时实现精细的访问控制。

  • 密钥销毁技术(Crypto shredding)

密钥销毁是指主动覆盖或删除用于保护敏感数据的加密密钥,以保护敏感数据不被读取。对于审计应用程序或区块链这样不应该或不能删除历史记录的系统来说,密钥销毁技术对于隐私保护和GDPR合规非常有用。

  • 容器安全扫描(Container security scanning)

围绕Docker的容器革命显著减少了应用在跨环境迁移时的阻力,并推动持续交付和持续部署的采纳。但尤其是后者,对于传统的投产控制带来了相当大的漏洞。容器安全扫描技术是对该威胁载体的必要响应。构建流水线中的工具,会自动检查流水线中的容器是否存在已知漏洞。

作为测试人员,对于上面的安全相关技术可能不需要掌握的很深,但是需要了解有这样的一些技术,以及对应的使用场景。这样,才能对于系统整体的安全质量有更好的把握。此外,测试人员需要了解相应的安全测试技术,需要关注业务方面的安全需求,了解不同领域的安全规范和要求,从需求阶段做好威胁建模开始,跟团队一起在软件开发生命周期做到安全内建(Build Security in)

5. 自动化测试与线上质量的关注

要快速交付,必然离不开自动化测试,而要做好自动化测试,更是离不开相应工具的支持。本期技术雷达上列出的CypressTestCafePuppeteer被誉为后Selenium时代的Web UI测试的三驾马车,值得关注。这三个工具不同于WebDriver时代的自动化测试工具,具有更加轻量级、更加稳定、速度更快的优点。

随着技术架构的演进和业务领域的发展,软件系统生态越来越复杂。过于重视预生产环境的测试,不仅不能很好的保证生产环境的质量,而且影响交付速度。因此,我们要把质量关注点拓宽到生产环境,做到测试右移。本期技术雷达列出的相关工具有:日志管理工具HumioHoneycomb,以及前面提到的混沌工程相关条目等。

  • Humio

在日志管理领域,Humio是一款相对较新的工具。该工具完全从零开始构建,通过基于定制设计的时序数据库的内置查询语言,在日志提取和查询方面性能非常快。从提取、可视化和报警提醒的角度来看,该工具能够与几乎所有工具相集成。

  • Honeycomb

Honeycomb是一个可观测性工具,它从生产环境中提取出丰富的数据,并通过动态采样使其可管理。开发人员可以记录大量丰富的事件,并在之后决定如何划分和关联它们,这对于大型分布式系统的问题诊断很有帮助。

作为测试人员,自动化测试成为了必备技能,需要关注自动化测试工具的发展,了解新工具的特点与适应场景,更好的让自动化测试工作发挥最大的价值。另外,测试右移的思想也越来越被大家接受,需要测试人员更多的了解基础设施相关技术、线上监控技术等,跟Ops紧密的合作,做好QA in production。同时,利用生产环境的数据,为预生产环境的测试设计和数据准备等提供帮助,构建反脆弱的软件系统。

6. 新兴领域不容忽视

(图片来自网络)

最火热的新兴领域当属AI,这也是未来的发展方向。本期技术雷达上列出的有机器学习和神经网络训练等内容,比如:机器学习持续交付模型NLP的迁移学习fastai等。

另一个热门新技术是区块链,技术雷达上区块链相关技术条目有智能合约超越以太坊的EVM和企业版以太坊Quorum等。

技术雷达上还提到一个新的内容,那就是随着社会对科技的依赖程度日益增长,建议软件开发团队在制定决策时必须考虑道德问题,思考自己所构建的软件会在未来产生什么影响。相应的工具有技术塔罗牌道德风险手册

作为测试人员,这些都是大家可以关注并深入了解的方向。新兴领域必然会对测试有不同的要求,比如:关于AI的测试需要考虑两个方面,一个是对于AI产品的测试,另一个是把AI技术运用于测试中,比如自动化测试的智能化、生产环境数据的智能分析等。另外,对于区块链,需要考虑它对测试带来什么挑战、有什么样不同的测试方法来支持;对于道德风险的把控,我们软件测试人员又该注意些什么?能够提供哪些支持呢?

写在最后

前面列的这几项,除了自动化测试工具以外,其他的内容通常被认为跟测试人员没多大关系。其实,软件测试已经不再是那个简单的通过模拟用户行为点击去验证功能是否满足的时代了,测试人员的眼光要放更开阔一些,考虑更多的质量相关因素。对于前面总结的这些项目,我认为不是跟测试人员没有关系,而是给测试人员带来了新的挑战,提出了新的要求。同时,机遇跟挑战并存,这些挑战同样也给测试人员带来了很多新的发展机会。

那么,在众多机会面前,测试人员该如何把握呢?推荐大家可以根据T型能力模型去提升自己的能力。

(图片来自网络)

T的横表示能力广度,T的竖表示能力深度。前面提到的方方面面都属于广度,包括不同技术和不同业务领域的扩展,而深度就是对于其中一个领域进行深入的学习研究,发展对应的测试技能。

广大的测试朋友们可以结合自己的兴趣特点,找到最适合自己的那个领域,深入发展。了解足够的相关知识,通过实践将知识转换为经验,然后总结归纳、不断锻炼,以获得利用经验解决问题的能力,拥有一技之长。

同时,要拓宽视野,了解更多领域的知识,做到广度和深度协调发展。

关于软件质量,大家都在关注什么?

去年,我们在《数字化时代的软件测试》中看到了2017年软件质量方面的趋势和给测试人员的建议。又一年过去了,大家对软件质量保障和测试的关注有哪些变化呢?我们一起来看看这份质量报告《World Quality Report 2018-19》有些什么新的内容。

关键趋势

质量保障和测试的职责已从单纯的缺陷发现转变为客户满意度和业务成果的推动者了,这是个根本性的转变,它所带来的影响可以从今年这份质量报告的多个部分体现出来,而最能体现这个转变的是质量保障和测试的目标,受访者认为目前质量保障和测试策略的最高目标是“确保终端用户的满意度”。不断增长的以客户为中心推动的IT趋势也正在改变质量保障的目标和期望,比如业务数字化和敏捷、DevOps、云服务的采用。

以客户为中心要求我们的IT系统能够在速度、安全和便利性方面增加用户满意度,对应的关键IT趋势有以下几个方面。

1. AI在质量保障和测试中的作用

AI的发展对于质量保障和测试主要有两个方面的影响:一方面,AI会促使企业将测试转变成完全自生成、自执行和自适应的活动,也就是用AI技术来优化测试;另一方面,AI产品的开发需要一种新的特殊方法来验证和校验,就是对AI产品的测试。这两个方面正好是互补的,相互促进的过程。

AI在测试中的运用还处于初始阶段,有组织开始应用智能分析来制定关键决策以优化测试活动和早期的质量预测:

  • 57%的受访者表示有项目引入了IT到质量保障中
  • 45%的受访者在测试中采用AI做智能自动化
  • 36%的受访者正在使用AI做测试的预测分析

对于AI产品的测试还没有具体的、广泛被采用的方法、指南或方案,57%的受访者表示正在试验AI和ML(机器学习)的测试方法。

将AI技术用于IT也存在不小的挑战,55%的受访者表示他们在定位哪些业务可以用到AI技术的时候遇到困难;将AI技术用于测试则可能需要一些新的角色,比如AI质量保障战略家、数据科学家、AI测试专家等。

尽管挑战重重,AI还是有望成为接下来两到三年内最大的趋势,组织需要从以下几个方面考虑AI策略:

  • 要达到一定级别的自动化测试成熟度
  • 要实施分析(Analytics)技术
  • 实现能够自我学习、自我认知的系统并应用于测试中
2. 敏捷和DevOps

速度上的质量”宣言推动着敏捷和DevOps逐渐被采用,有多达99%的受访者称他们至少有一些项目在采用DevOps。但是,有些组织以质量为代价去追求速度,这样是不妥的。也有的组织认为敏捷与瀑布共存的模式比较适合他们的组织、文化和业务的需求。

敏捷和DevOps的转型打乱了原来的质量保障和测试部门,所有人都分散到不同的敏捷团队中,这样使得技术、最佳实践和测试场景的跨项目共享很难,从而有不同团队重复造轮子的事情发生。以角色组成的社区(Community),比如QA社区,很好的解决了这个问题,可以在社区内做到知识共享、能力共建。

3. 自动化

质量保障和测试活动的自动化已经有十多年的历史,测试自动化也从测试执行的自动化发展到了采用基于模型的工具来自动化生成测试用例。自动化的目标也从缩短运行时间转变成了采用更有效的测试用例实现更好的测试覆盖

但是,测试活动的自动化还是处于较低的水平,而且成为了企业成熟测试的头号瓶颈。自动化水平低下的原因有:

  • 61%的受访者表示由于应用程序每次发布都在变化,很难构建出健壮的、适应性强的自动化测试方案
  • 48%的受访者对于准备可预测的、可重复利用的测试数据和测试环境有挑战
  • 46%的企业表示由于技能和经验的缺失导致自动化实现很难

自动化测试应该是朝着智能、认知的方向发展,构建能够自执行、自适应的自动化平台。

4. 环境和数据

近几年,质量保障和测试部门都在朝着敏捷和DevOps转型,测试环境和数据的管理却跟不上,大部分企业在数据管理和创建方面没有成熟的方案:

  • 测试环境方面,31%的受访者主要还依赖物理机器环境
  • 58%的受访者表示他们仍然依赖手工方式创建测试数据
  • 66%的受访者用Excel等电子制表软件来手动生成测试数据
  • 62%的受访者用生产环境数据的副本来执行测试

目前,测试数据和环境成为企业成熟测试的二号瓶颈。当然,我们也看到了这方面正在得以改进的新技术趋势:

  • 不断增加的容器化测试环境的采用
  • API经济的增长
  • 零接触(Zero-touch)测试机器人的使用
  • 开放数据项目(Open data projects)的发展
  • 更好的数据采样智能方案的发展
5. 成本

在测试活动的成本和效能方面,我们看到两个有分歧的趋势:

  • 大量的自动化测试和测试外包的方式,使得基于瀑布式的核心IT和遗留系统的成本下降;
  • 数字化转型、迁移到云、敏捷和DevOps的采纳、质量保障和测试中自动化和分析技术的运用,使得在新的基础设施、工具、组织改组、工作流程重组方面的花销达到高峰

质量保障和测试的花费在2015和2016年分别占整个IT成本的35%和31%,在2017和2018年下降到了26%,并趋于稳定。但是,随着测试环境的虚拟化、测试数据的管理、测试自动化和测试生命周期分析技术使用方面的投资,在将来的两到三年内成本可能会升高到30%,并达到一个新的增长稳定的阶段。

推荐的应对策略

1. 以智能的、分阶段的方式提升基础测试自动化和智能测试自动化水平

自动化测试是质量保障和测试变革的瓶颈,因为:

  • 自动化的核心角色是敏捷和DevOps转型的推动者,随着敏捷和DevOps被越来越多的采用,自动化对交付“速度上的质量”的重要性也在上升;
  • 它也是AI、ML、分析等新技术的结果,这些技术在自动化可以带来的好处方面都具有很大的潜力;
  • 调查结果显示基础自动化水平还很低,还有很大的发展空间。

因此,自动化(尤其是智能自动化)将会在接下来两到三年给质量保障和测试带来重大的变化,组织需要有自己的策略和路线图去应对,报告推荐了一个三步走的方案:

  1. 优化测试
  2. 实施基础的自动化测试
  3. 采用智能的、自适应的测试自动化方案让自动化变得更加“智能”
2. 以非孤立的方式实施测试数据和测试环境的管理

53%的受访者表示在敏捷测试的数据和环境准备方面面临挑战。数据和环境的延迟使得云服务、敏捷和DevOps的采用所带来的效率不明显,这是一个需要特别引起重视的领域,建议采用集中的方式来管理。企业要开始生命周期的自动化,把测试自动化和数据、环境的准备工作一起开展,不要分离开来。另外,要采用更加智能的方式来管理测试环境和数据。

一定程度的集中化能够更有效的利用、共享各种知识、实践和经验,更好的风险管理,加速发布频率,缩减基础设施的开支,提高团队的生产力。

3. 构建超出测试开发(SDET)之外的质量工程技能

敏捷、DevOps、云、IoT、区块链和AI这些新趋势的发展,以及更加自动的、集成的质量保障方法的需求,企业需要关注新的质量技能。

推荐以下方式做好质量保障能力建设:

  1. 第一优先级是吸引敏捷测试专家,需要具备功能自动化技能和领域测试技能,自动化测试将是每个质量保障人员的必备技能;
  2. 第二优先级是吸引SDET,他们的必备技能要求有高级自动化测试、白盒测试、开发和平台构建能力,同时最好还有AI应用的基础算法应用能力和自然语言处理技能;
  3. 第三优先级是吸引拥有一些特定QA技能集的人员,比如安全等非功能测试、测试环境和数据的管理技能等;
  4. 第四优先级是吸引高级QA专家,需要有AI架构技能,以构建能够执行重复、智能任务的“智能资产”,这些技能由深度机器学习概念和算法组成,比如决策树、分类器、神经网络、高级统计学和数据优化技能。

当然,目前市场上还相对比较缺乏上面所列举的资源,建议组织要重点关注通过实习、专长培训、强制性的学习和发展计划来构建这些技能集。

4. 加强跟踪以优化各项花费

敏捷和DevOps模式下测试活动被多个不同角色承担,很难精确跟踪、掌握和优化质量保障相关花费。另外,对于云、虚拟化和容器化环境的投资回报也需要跟踪掌握。

因此,建议企业采用严格的、细粒度的跟踪机制来看各项预算分配到了哪里、各项开支都花在了什么地方。

5. 给AI解决方案开发一套测试方法

很多的企业开始开发AI产品,但是相应的质量保障方案并不成熟,有必要抓紧开发AI产品的质量保障策略和测试方案。组织应该意识到不正确的或者有缺陷的AI解决方案带来的业务和社会影响可能是巨大的。AI产品开发过程中校验和验证,以及自动化的持续监控都应该是AI质量保障策略的内容。

总结

通过前面的分析和总结,我们看到这次质量报告体现出的关键点主要有:

  1. 终端用户的满意度第一次成为质量保障和测试策略的最高目标,要求在关注速度的同时绝对不能忽视质量,要以客户为中心,在安全、便利性和速度方面关注用户的满意度。
  2. 低水平的自动化测试,以及测试环境和数据准备的挑战,影响了质量保障和测试效率的提升。要求组织加强自动化能力的提升、测试环境和数据的管理,让自动化朝着更加智能的方向发展。
  3. 质量保障和测试人员的必备技能发生了改变,需要有超出SDET的更加全面的QA技能集。

:以上大部分内容和图片均摘自这份《World Quality Report 2018-19》,更多详细内容请参考原报告。

时区那些事儿

摘要:本文总结几类项目中跟时区相关的问题,给大家分享一些基本的时区知识,以及如何在软件开发和测试中注意考虑时区因素,以避免因时区而导致系统功能的问题。

场景一

“小D,我发现调整不同的timezone(时区),咱们的KPI计算结果可能会有一天的误差…”

“啊!我看看什么原因。”

“嗯啦,KPI务必是准确的,可不能有误差…”

“小Q,我知道啦!咱们的工单任务完成时间记录的是UTC时间,是考虑了timezone转换的,但是缺失信息的记录并没有考虑… ”

“为什么缺失信息不记录UTC时间呢?”

“因为缺失信息只记录日期,并没有时间。”

蓝鲸项目的小Q和小D说的是啥呢?下面先来借助维基百科的解释来介绍时区和UTC的概念:

  1. 时区(timezone)
    时区是地球上的区域使用同一个时间的定义。以前,人们通过观察太阳的位置决定时间,这就使得不同的地方的时间有所不同(地方时)。1863年,首次使用时区的概念,通过设立一个区域的标准时间部分地解决了这个问题。
  2. UTC
    协调世界时(英语:Coordinated Universal Time,法语:Temps Universel Coordonné,简称UTC)是世界上调节时钟和时间的主要时间标准,它与0度经线的平太阳时相差不超过1秒。协调世界时是最接近格林威治标准时间(GMT)的几个替代时间系统之一。对于大多数用途来说,UTC时间被认为能与GMT时间互换,但GMT时间已不再被科学界所确定。
世界时区分布(图片来自维基百科)

原来小Q和小D所在的蓝鲸项目正在开发一个全球性的系统,用户处于世界各地的不同时区。

系统的工单处理流程中每个任务的完成因为有先后依赖关系,当时记录的是完成时刻的UTC时间,以防不同时区的用户完成依赖任务的时候产生冲突。

比如:处于UTC+08:00时区的用户S在当地时间“2019-02-28 09:30”处理了任务1,系统记录的时间是“UTC 2019-02-28 01:30”,接下来处于UTC-0800的用户G在当地时间“2019-02-27 18:20”来处理任务2(必须晚于任务1完成),系统记录的是“UTC 2019-02-28 02:20”,这个时间就不会有问题。

工单任务处理

在处理某个任务的时候如果发现有信息缺失,需要记录发现和收集到缺失信息的时间(可以是过去时间,由用户输入),而这个发现和收集完成的时间一般都是同一个用户来记录,本身不会有时区问题,另外这个时间跟工单处理流程中的任务完成时间并没有特别直接的关系,就对缺失信息部分只记录由用户输入的日期,而且是直接记录用户当地时间的日期,并没有记录时分秒,也没法根据UTC进行转换。

这样,同一个日期,比如,在东部时区的“2019-04-28”可能就是西部时区的“2019-04-27”,在西部时区的“2019-04-28”可能就是东部时区的“2019-04-29”,前后有相差一天的可能性。

但是,在做到KPI功能的时候,计算KPI需要结合工单任务处理时间和缺失信息记录时间,由于没有考虑时区问题,不同时区可能会造成KPI有一天的误差。

场景二

“我们这里有个线上用户报过来一个bug,合同签订日期签完以后打开编辑,在页面上变成了一个后一天的日期,没法保存”,R说。

“我们的合同签订日期最晚是签订当天的日期,的确不能用将来日期,这个业务上是这么要求的”,小B说。

“我们前端也有校验不允许存储将来日期。可是为什么会变成后一天的日期呢”,小D一脸迷惑。

“会不会还是timezone的问题?!” 小Q由于前一阵做KPI的时候测试时区相关问题花了不少精力去搞明白各种case,对时区也有了不少的研究,对此比较敏感。

“那个报bug的用户设置是什么timezone的?” 小B问。

“是东14区(UTC+14:00)!” R回答。

“竟然还有东14区,我一直以为都在正负12时区之间。”小Q很惊讶。

“那就对了!的确是timezone引发的问题!”小D沉思了一会,激动的跳起来。

这又是为什么呢?大家都在焦急地等待小D的解释。

原来,对于这种没有时分秒要求的时间,我们系统统一用当天中午UTC的12:00存入DB,这样做的原因是保证-12~+12时区内都不会有问题,换算以后都是当天,但是没有考虑到正负13、14区的情况。

下面我们来举例说明为什么东14区的会有问题。

假设用户A和用户B分别处于东12区和东14区,A和B分别在当地时间的2019年04月28日的上午9:00签订了合同,那么系统记录的时间都是“UTC 2019-04-28 12:00”,在用户A的页面上显示的日期是“2019-04-28”(“UTC 2019-04-28 12:00”转换东12区的时间是“2019-04-28 24:00”>,这个时间的日期还是4月28日),而在用户B的页面上显示的日期应该是“2019-04-29”(“UTC 2019-04-28 12:00”转换东14区的时间是“2019-04-28 26:00”,也就是“2019-04-29 02:00”,这个时间的日期变成了4月29日)。

如下表,用户A、B、C、D的合同签订时间都是当地时间2019年04月28日的上午9:00:

同理,用户C和D处于西部时区,从上表我们可以看到处于-12的C的时间是跟实际日期一样,而处于-13的用户D的时间则比实际时间早了一天,也是有问题的。

至此,我们明白了为什么东14区会引起系统功能有问题。但是,一直以来以为时区都在正负12之间,为什么会有大于+12的时区呢?原来小D是早就知道的,他给我们解释了是下面两个原因:

  1. 有些跨国际日期变更线的地区,为了保证该地区所有地方的时间都在同一天,就把时区设置成了大于+12的,比如基里巴斯。
  2. 有些处于+12区的地区有夏令时,夏令时的时候时区会变成+13,比如新西兰。

其实,时区还有很多有意思的,有偏移量是半个小时的(如印度),还有45分钟的(如尼泊尔),不一定都是整点。更多详情可以参考维基百科的时区列表

场景三

客户P发过来一封邮件:
“自2017年初以来,土耳其和白俄罗斯政府不再遵守夏令时(DST),因此这将改变这些国家的时区为GMT+3,而不是GMT+2。 目前,在我们系统伊斯坦布尔和明斯克都显示为GMT+2。”

这个问题听起来很简单,直接在DB里把对应的时区改一下就ok了。可是,正当小D准备去改数据的时候,发现了一个崩溃的事情:伊斯坦布尔和明斯克还跟另外两个地区的时区是绑定在一起的,见下图。当前系统中已经设置好的一些会议,没法判断真正需要的是哪个地区对应的时区… 已有数据无法修复!

伊斯坦布尔和明斯克

在此先不解释如何修复的数据问题。

当时,我们正好要把时区引入到另外一个新系统,考虑到避免再出现类似的情况,采用了一个新的库,那就是每个地区对应一个时区。比如:GMT+08:00分别有上海、乌鲁木齐、重庆、香港、新加坡等时区。

场景四

“这个新的timezone里怎么有一些乱七八糟的时区?”

“乱七八糟的时区?”

“Etc什么的,好像还正负矛盾的。比如:‘(GMT+08:00)Etc/GMT-8’” 对时区敏感的小Q觉得这些时区不太顺眼。

“这个是咱们新的时区库引入的,不过的确挺奇怪的,不知道这个Etc时区是啥。” 小B也不是很明白。

原来,这个时区表示法里时区名字都是用“区域/位置”来表示,比如“Asia/Shanghai”,而前面的“(GMT+08:00)”是表示相对于GMT的一个偏移量。前面对话中提到的“Etc/GMT-8”只是时区名字而已。那为什么叫这么奇怪的名字呢?

Etc时区

下面引用维基百科的解释来说明:

区域分为大陆,海洋或“Etc”三类。 目前使用的大陆和海洋是非洲,美洲,南极洲,北极,亚洲,大西洋,澳大利亚,欧洲,印度和太平洋。

包括海洋的原因是一些岛屿很难连接到某个大陆,有些地理位置与一个大陆相连,在政治上却与另一个大陆相连。

“Etc”属于特殊区域,用于某些管理区域,特别是用于表示协调世界时的“Etc/UTC”。 为了符合POSIX样式,以“Etc/GMT”开头的区域名称的标志与标准ISO 8601惯例相反。 在“Etc”区域,格林威治标准时间以西的区域有一个正号,而以东区域的名称有一个负号(例如“Etc/GMT-14”比GMT早14个小时。)

总结

对于国际化的软件系统来说,时区还是需要特别关注的。根据所经历项目出现的时区相关问题,尝试总结以下几点供大家参考。

实现方面

  1. 对于具体操作执行时间,这种都是包含时分秒的具体时刻,存储全部采用UTC时间,在显示的时候根据时区偏移量转换为对应的当地时间。不同模块之间传递的时间参数要以UTC格式。
  2. 对于没有精确时间点的、由用户输入的日期,这种一般对时间要求没有那么精确,可以加上操作时候的时间戳存储到数据库。当然还需要结合业务对时间的具体需求来定不同方案。
  3. 时区数据库单独一个位置作为一个时区的方式可以更方便修改对应位置的时区,比如:“(GMT+08:00)Asia/Chongqing”,而不是“(GMT+08:00) Beijing,Chongqing,Hong Kong,Urumqi”
  4. 关于UTC时间的获取:可以用第三方工具获取客观的UTC时间,但是出于安全考虑,一般不用;而是直接从服务器获取UTC时间,所以需要保证服务器的客观时间点是正确的,如果服务器的客观时间点有错,将会导致计算出的时间有出入。
  5. 有时候需要自定义一些时间段供用户使用,这种需要特别注意夏令时的影响。

测试方面

  1. 对于过去时间、未来时间的测试,一定要测不同时区跨度看是否满足条件能够正确使用。
  2. 显示时间:本地,不同时区切换能正确显示相应时间;输入时间:不同时区对应的日期边界值要重点考虑。如果只能输入未来时间,要考虑一些负时区的情况,比如 UTC-12, UTC-13等;如果只能是过去时间,要考虑UTC+12, UTC+14等。
  3. 定时任务:如果设置成固定时间段(如:每隔一小时)执行,与时区无关;每天定点执行,要考虑不存在的或者多出的时间段。
  4. 日志文件:时间戳命名的文件,不会由于夏令时导致文件名重复;文件内容涉及时间部分,不同时区显示正确。
  5. 夏令时跳变时刻系统功能测试,对于多出来的一小时或者减少的一小时系统行为是否正常。

大家如果还有遇到过其他时区方面的bug,欢迎留言,谢谢!

微服务测试的思考与实践

最近几年,微服务架构越来越火爆,逐渐被企业所采用。随着软件架构的变化,对应的软件测试策略需要作何调整呢?本文将介绍微服务架构下的测试策略,并结合分享在业务和架构演变过程中,一个历经九年的项目测试策略的演进。

关于微服务

微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,每个服务运行在其独立的进程中,服务间采用轻量级通信机制互相沟通(通常是基于HTTP协议的RESTful API)。每个服务都围绕着具体的业务进行构建,并且能够被独立部署到生产环境、预生产环境。

从微服务的概念可以看出它有如下好处:

  • 每个服务可以独立开发
  • 处理的单元粒度更细
  • 单个服务支持独立部署和发布
  • 更有利于业务的扩展

同时,独立开发导致技术上的分离,HTTP通信加上Queue的机制增加了问题诊断的复杂度,对系统的功能、性能和安全方面的质量保障带来了很大的挑战。另外,服务间的复杂依赖关系带来了很多的不确定性,要实现独立部署,对运维也提出了更高的要求。微服务架构的系统要特别关注这几个方面:

  • 服务间的依赖、连通性
  • 服务的容错、可用性
  • 数据的最终一致性
  • 独立部署
  • 不确定性

测试策略的选择

谈到微服务的测试策略,很容易就想到了老马网站上Toby Clemson的文章《Microservices Testing》,该文推荐的微服务框架下的测试策略是这样的:

经典测试策略

这个策略模型强调测试分层以及每一层的恰当覆盖,整体符合金字塔结构。它是最优的吗?

有人对此提出了质疑…认为策略模型应该是蜂巢形状的(请参考文章):


这个模型重点关注服务间的集成测试,两端的单元测试和UI层E2E测试较少。

也有同事提出微服务下的测试结构应该是钻石形状的,服务间的集成依然是重点,单元测试较少,而顶层增加了安全和性能等非功能测试。

好像都有道理,到底选择什么样的策略模型好呢?不禁陷入了困境……怎么办?不妨先来听听我们项目的故事吧!

项目的故事

测试策略的演进

还是那个蓝鲸项目,不知不觉进入了第九个年头。在这九年里,随着业务的不断发展,系统架构也进行了多次演进和调整。相应的,测试策略也发生了有意思的演进变化。

测试策略的演进

最初单一用户系统、单体架构的时候,严格按照测试金字塔来组织各层的自动化测试。随着功能的扩展,大量mock的单元测试给重构带来了很大的不便。

企业系统开始开发的时候,我们调整了策略,减少单元测试的编写,增加UI层E2E测试的覆盖,测试结构由原来的金字塔演变成上面梯形下面倒三角的形式。

后来,架构调整,开始服务化。此时,大量的E2E测试渐渐暴露出问题:

  • CI上的测试执行时间越来越长,而且定位问题的能力很弱,测试一旦失败需要很长时间修复,测试人员好几天也拿不到可以测试的版本,反馈周期过长;
  • 由于服务化带来的不稳定因素增加,E2E测试没法很好的覆盖到需要的场景,测试人员就算拿到可测的版本也总有各种缺陷发生。

因此,项目引入契约测试,停止编写新的E2E测试,将测试下移,分别用API测试和契约测试取代。

随着功能的不断增加,虽然E2E测试的量并不增加,但是其不稳定性、维护难、定位难的问题有增无减,此时已经很难由自动化测试来保证产品的质量。为了平衡成本和收益,项目考虑去掉大部分E2E测试,只保留少量的Smoke测试,将更多的测试下移。

同时,技术雷达上新的技术“生产环境下的QA”出现,项目也开始关心生产环境,并且在QA测试阶段结合微服务的特点进行对应的探索式测试。

应对微服务的挑战

前文提到过微服务带来的挑战,下面来看项目是如何应对这些挑战的。

  • 服务间的依赖、连通性

微服务架构下,独立开发的服务要整合起来最具挑战,如何保证服务间的依赖关系和连通性非常关键。前面已经讲过E2E集成测试有很大的挑战,并不适合,而消费端驱动的契约测试是个不错的选择。项目正是利用契约测试去保证服务间的连通性,取代一部分E2E集成测试。

  • 服务的容错、可用性

在系统负荷达到一定程度或者某个服务出现故障的时候,微服务架构有两种技术来确保系统的可用性:服务的熔断和降级。服务的熔断是指当某个服务出现故障时,为了保证系统整体的可用性,会关闭掉出现故障的服务;服务的降级则是当系统整体负荷过载的时候,考虑关闭某些外围服务来保证系统的整体可用性。

对应的测试包括:

  1. 熔断:从性能角度,当系统负载达到某个熔断状态的时候,服务是否能正确熔断;同时,从功能角度验证熔断后系统的行为是否跟预期相符;
  2. 降级:从业务的角度,要能区分出核心业务和外围业务,在需要降级的时候不能影响核心业务;当某个服务降级后,从功能角度验证系统行为是否跟预期相符。
  • 数据的最终一致性

数据一致性是微服务特别需要关注的。举个例子,电商平台某个订单支付成功以后,需要更新积分和订单状态,当订单服务或者积分服务其中有一个出现故障的时候,就会导致最终的数据不一致性。

测试这种情况,从业务的角度分析哪些服务会导致数据不一致性,制造对应的异常情况去测试数据的最终一致性。

  • 独立部署

微服务的独立部署需要有CI、CD的支持,跟DevOps实践分不开。同时,更为关键的是需要契约测试来验证独立部署后服务行为的正确性。项目在这方面的工作,请参考王健的文章:你的微服务敢独立交付吗?

  • 不确定性

微服务架构使得系统复杂度增加不少,很多的事情发生都是不可预测的,只能在其发生以后找到产生的原因。因此,也就没法在预生产环境通过测试去发现在真实生产环境才会发生的issue,我们需要把目光转移到生产环境,利用生产环境的不确定性、微服务的不可预测性来构建反脆弱的系统。

项目在这方面主要采用的技术是生产环境下的QA,请参考文章:生产环境下的QA

项目测试策略

从前面介绍的演进过程可以看到,项目测试策略在不同阶段结合参考了不同的策略模型:金字塔->近似钻石(除非功能测试外,类似于钻石模型)->蜂巢。后期全面服务化的时候,我们认为蜂巢模型是比较适合的。

当然,光有符合这个策略模型的自动化测试是远远不够的,我们项目还采用了针对微服务特点的探索式测试,保持持续交付节奏,践行DevOps实践,结合生产环境下的QA等技术把关注点右移到生产环境。

现在,项目整体测试策略演变成下图的形式:

  1. 项目采用的是敏捷迭代开发和持续交付的模式,每四周一个发布周期。
  2. 在开发过程中实现的自动化测试是分层实现的:底层少量的单元测试,中间量最多的是API测试(类似于老马推荐的策略模型里的组件测试),上面有一部分契约测试和少量的Smoke测试来保证服务间的契约和集成。除此之外,QA有手动的探索式测试,其中包括针对微服务特点进行的一些测试。整个测试结构是类似于蜂巢模型的。
  3. 采用生产环境下的QA技术,利用生产环境,进行error监控、用户行为分析、用户反馈收集,从而来影响和指导预生产环境的开发和测试工作。
  4. 利用DevOps实践,做到高效的部署和监控,跟生产环境下的QA结合,形成良性的环路,保证项目的正常交付。

测试策略再思考

项目上多次测试策略的调整,看似很简单,其实每次调整并不是一个轻松的过程,都是平衡利弊、综合考虑多个因素才做出的决定。

分析整个调整过程,最后突然发现:当我们面对多个策略模型不知道如何选择的时候,其实我们陷入了一个太过于关注测试结构的误区,忘记了最初的目标是什么。

影响测试策略的因素

跳出误区,回到原点,重新思考测试策略的目标。影响策略的最关键因素是业务价值、质量要求、痛点。

  • 业务价值

带来更大的业务价值、帮企业赢得更多的利润,是软件系统的目标;软件测试是软件系统成功的保障之一,业务价值也是测试策略的终极目标。所有测试活动都要围绕这个目标开展,考虑业务优先级,有效规避业务风险。

  • 质量要求

不同的系统、同一系统的不同利益干系人(参与的不同角色)对于质量的定义和要求都可能是不同的,这毫无疑问是影响测试策略的一个关键因素。

对于仅有内部用户的系统,关注的重心可能是系统的功能;而对外发布的产品,则要求更高,一个按钮位置的不恰当都可能带来大量用户的流失。

  • 痛点

真正的痛点往往也是优先级最高,迫切需要解决的。那些可以通过测试策略的调整来解决的痛点,自然成为了关键的影响因素之一。比如,CI Pipeline出包太慢,为了提高出包的效率,一方面在Pipeline本身想办法,另一方面调整自动化测试的比例、执行频率等也是解决方案之一。

演进式测试策略

处在不同阶段的项目,在业务价值这个大目标下,其他影响因素也是会不一样的,跟技术架构的演进一样,测试策略也应该是演进式的。

从目标出发,综合所处阶段各个方面的影响因素,制定出适合当时的测试策略。随着时间的推移,对策略进行评估和度量,并进一步改进、提高,以更好的满足需求。这就是目标驱动的演进式测试策略。

总结

微服务架构下多个服务的整合是最具有挑战的,对此最重要的是契约测试。契约测试有效保证服务间的契约关系不被破坏,确保服务的连通性,有助于实现真正的独立部署和独立交付。

微服务架构引入的不确定性并不是坏事,可以利用这些不确定性,采用生产环境下的QA等技术,增强系统的反脆弱性,从中获益。

测试策略的影响因素不是唯一的,技术架构并不是最关键的因素。微服务架构下的测试策略跟其他架构下的并不会有本质的区别。

业务价值始终是我们的终极目标。在这个终极目标的驱动下,测试策略不是制定完了就可以束之高阁的,需要在整个软件系统构建过程中不断的度量和改进,是演进式的。

物联网测试地图(译)

物联网的出现,给测试带来了很多有意思的挑战,使得众多QA开始重新思考传统的测试过程。

例如,我最近测试了一个产品,在这个产品中的移动APP会跟连接的机器产生会话。这两个设备各种各样的状态给测试场景的设计带来了特别大的挑战。下面给大家介绍一个很有用的物联网产品测试框架——物联网测试地图,它可以帮助我们管理物联网设备多种排列的复杂状态。

物联网测试因素

当我们测试简单的web应用时,通常要考虑的状态有:

  • 服务器宕机
  • HTTP请求超时
  • 网速慢
  • 授权和认证错误

测试任何互联网应用的时候,需要警惕这四种状态。对于移动应用,操作的是移动环境,需要关注额外的几种情况:

  • 离线模式
  • 在线模式
  • 杀掉Activity
  • 后台行为
  • 语言
  • 地理位置

我们再看“连接的机器”所带来的状态多样性,通常还有:

  • 机器WiFi断开
  • 机器WiFi连接
  • 机器繁忙
  • 机器休眠

这意味着即使只有上述给定的状态集,整个系统在任何时间点上可能会有96(4x6x4)种状态。

由于系统中状态转换会引入附加的约束,这些状态都不能当做独立的实体。例如,状态从“离线”变成“在线”很可能触发一系列的事件。

上述因素还仅仅是冰山一角。随着对规范的深入了解,把不同的状态跟逻辑场景结合起来将会更加的复杂。

对于静态系统的可变数据集,已有的web测试技术可以很好的用来抽取测试场景,比如all pairs(开源的配对测试工具)、等价类划分、边界值分析法等。这些技术通过淘汰的逻辑来优化测试数据集。

例如,all pairs技术会淘汰重复的数据配对组合。但是,对系统的可变状态设计测试场景时,这些技术是不可靠的,废弃的系统状态会使得系统通讯不畅。当然,这些技术对于物联网系统中的单个单元还是很适用的。

因此,非常有必要搞一个物联网测试地图。

可视化地图

大家肯定都在地理课上看过地图。但我这里所说的地图是针对测试场景的,它列出所有潜在的系统因素,在测试某个特性时可以从中抽取必要的测试场景。

产品的每个系统的n种状态在同一个可转动的圆环中列出,逻辑上相邻的状态在环中相互挨着。非功能需求(NFR)在测试复杂集成的时候很容易被忽略掉,于是把它们在一个环中单独列出。

下图就是我所说的物联网测试地图:

物联网测试地图

下面以一个例子介绍地图的使用场景,该例子仅涉及移动设备和机器交互部分,需要关注的环是设备、机器和网络。

把移动设备和机器固定在WiFi连接的状态,转动网络环,可以得到下面这些场景:
  • 未授权用户尝试访问机器会在App上触发“访问被拒绝”的错误消息
  • 服务器宕机和服务器错误会触发相应的业务错误消息——“程序出错,请稍后重试”
  • 响应超时可能有两种情形:重发同一个请求并显示“正在加载”图示,或者显示上面那样相似的错误消息
  • 非法请求会触发消息“请更新你的App”
继续保持移动设备的WiFi为连接状态,转动机器环:
  • 当机器是离线模式的时候,App应该显示“请检查机器的网络连接”
  • 当机器繁忙的时候,弹出警告“机器繁忙,无法完成请求”
  • 当机器休眠或者在另一个网络上的时候,应该显示“没找到机器”等类似的消息
  • 然后,机器调到正确的网络,应该恢复移动设备和机器的连接
切换机器环为WiFi连接,转动移动设备环:
  • 当移动设备离线时,应该弹出对应的消息或者禁掉操作按钮
  • 当移动设备恢复在线模式时,App应该发送相应的请求去连接机器
  • 当移动设备的网络从WiFi切换到3G,应该有什么样的行为?
  • 当用户正在试图连接物联网设备的时候突然接到电话,将App置于后台运行,这时候还能收到完整的请求还是需要从头开始发送请求?
  • 安卓设备杀掉一个在后台运行了一段时间的App,用户的最后屏幕状态还会保存吗?
  • 有本地化需求的App要在每个场景层面进行验证

就这样,多次旋转地图可以扩展产生多个场景。尽管有些场景可能不适合当前的特性,有些甚至跟业务需求无关,这个测试地图还是非常详尽的。

在实践层面,对于有多个QA在测试同一个物联网产品的团队,地图可以作为大家共同参考的手册。这个地图把工具、设备、场景和协议的排列以易于理解的方式呈现出来,覆盖了测试场景设计这个独特的需求,是一种非常高效的合作方式。


  1. 此文发表于:TW洞见
  2. 英文原文请参考:IoT Testing Atlas

软件测试新趋势

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规范文件模板,开发者只需4步,即可对应用进行快速测试。

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

– 综合考虑项目技术栈和人员能力,采用合适的框架来实现自动化;

– 结合测试金字塔和项目具体情况,考虑合适的测试分层,如果能够在底层测试覆盖的功能点一定不要放到上层的端到端测试来覆盖;

– 自动化测试用例设计需要考虑业务价值,尽量从用户真实使用的业务流程/业务场景来设计测试用例,让自动化优先覆盖到最关键的用户场景;

– 同等看待测试代码和开发代码,让其作为产品不可分割的一部分。

自动化测试

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

测试环境的准备在过去是一个比较麻烦和昂贵的事情,很多组织由于没有条件准备多个测试环境,导致测试只能在有限的环境进行,从而可能遗漏一些非常重要的缺陷,测试的成本和代价很高。随着云技术的发展,多个测试环境不再需要大量昂贵的硬件设备来支持,加上以Docker为典范的容器技术生态系统也在逐步成长和成熟,创建和复制测试环境变得简单多了,成本大大的降低。技术雷达推荐的凤凰环境(Phoenix Environment),它能够以自动化的方式支持测试、开发、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可能会导致有些组织走的太远而忽视产品上线前的质量保证,它只对那些已经执行并有一定程度持续交付实践的组织有价值。

总结

软件测试是一项技术工作,但软件测试领域的问题不仅仅是技术问题。随着自动化程度越来越高,不断有人怀疑QA存在的必要性,从前面的分析可以看到,新趋势给QA提出了更高的要求,带来了更多的机遇和挑战,相信好的QA是不可能简单的被取代的。

(此文发表于TW洞见InfoQ