标签归档: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的竖表示能力深度。前面提到的方方面面都属于广度,包括不同技术和不同业务领域的扩展,而深度就是对于其中一个领域进行深入的学习研究,发展对应的测试技能。

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

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

再谈敏捷QA

曾经在《敏捷中的QA》一文里介绍了敏捷开发模式下,QA如何参与从需求到测试的每个阶段,在每个实践中如何跟不同角色的合作,以及敏捷QA跟传统开发模式下的测试人员的区别等。

这些内容在今天依然适用,但在真实项目中往往情况比较复杂,总会听到一些困惑或者是质疑的声音。

在敏捷项目团队摸爬滚打多年以后,我想跟大家一起再来聊聊这个话题,下面逐个来分析我所见(听)到的质疑或困惑。

敏捷QA流程必须严格遵守

“如果QA没有参加Kick-off,我们拒绝做Desk Check;如果没有QA参与Desk Check,我们拒绝测试。”

从需求分析到生产环境,推荐QA参与每一个环节,跟多个角色进行充分的沟通和合作。

有人把这个当做圣旨,觉得不管怎样都不能漏掉某个环节,但难免有特殊情况。比如,由于QA请假或者开会等,错过了某一次Desk Check,一定要求等有时间了(甚至第二天或第三天)再补上,没准那个时候代码都已经上到测试环境,完全可以直接测试没必要在折腾大家来做一次全面的Desk Check了。

QA参与每个环节的目的是尽可能早期发现需求或者设计中的不足,做到Bug的预防。如果已经错过了这个“早”,那就没有必要再纠结非要严格进行每个环节了,不然不仅没有意义,还带来浪费。

QA不用了解太多的业务上下文,一样做的很好

“需求来的晚,QA手头忙着测试当前迭代的Story,根本没有时间去参与需求分析,不过这样也不影响,测好当前的卡就可以很好的保障质量了。”

这个想法是狭隘的。敏捷测试的原则之一是优化业务价值。如果连业务上下文都不清楚,如何做到优化业务价值?了解业务上下文的重要性不言而喻。

业务上下文

那么,真的忙的没有时间如何来破解呢?这其实是进入了一个恶性循环,需要找到突破点,打破这个不良环路,让其变成一个良性循环就好了。

不破不立,对于这个循环,就是需要减少测试Story的时间。可行的方案是:加强Desk Check,确保单元测试的覆盖,保证开发验收完成到最终交付的代码在自动化测试的保护下不被后续环节破坏;同时QA参与技术方案的设计讨论,这样测试的时候就可以有针对性的测,必要时候辅助以Bug Bash,由此节省出时间。经过两三个迭代的调整,情况定会有所改善。

技术方案讨论跟QA没什么关系

“技术方案,那是Dev们的事情,QA的重要任务是如何做好测试,参与技术讨论浪费时间。”

知己知彼,百战不殆。如果完全不了解技术实现,很难做到有的放矢。正如前面提到的,QA参与技术方案的讨论,了解更多技术细节,知道技术方案可能的风险,就能更好的指导测试,使测试更有针对性、更高效。

比如,对于微服务架构,了解了服务的熔断和降级机制,测试就能有效覆盖到相关方面。

单元测试Review没有价值

“单元测试还挺复杂,Dev新人写起来都不容易,QA更看不懂。QA Review单元测试,提不出有价值的反馈,感觉是在浪费时间。”

敏捷QA有个实践就是在做Desk Check的时候Review开发人员写的单元测试,其目的是两个方面:

  • 帮助发现漏掉的或者需要修改的测试,QA更好的了解测试覆盖情况
  • 帮助开发人员增加测试Sense,同时也能帮助QA提高代码阅读和理解能力

我理解对于单元测试Review的质疑是由于DEV和QA的相关技能还有所欠缺的情况下可能会发生的情况,但并不能因此否认这个实践的价值。

这时正确的做法是DEV跟QA解释每个测试所测到的内容,而QA从业务的角度考虑有哪些Case是遗漏掉了的。经过一段时间的磨合,我相信Dev的测试Sense和QA阅读代码、理解测试的能力都会得到提高。

必须严格Review每一个单元测试

“我对Dev写的单元测试总是不放心,不严格的Review根本不行。”

另一个极端情况就是,不管花多少时间,认为必须严格Review每个测试,认真的去检查测试的每个实现细节。

对于复杂一点的Story,严格Review每个单元测试,我见过最长的是花了两个小时,到最后大家都已经筋疲力尽…这显然是一种浪费!

QA Review单元测试更多的是关注测试的覆盖情况,而不是关注每个测试的实现细节,后者更多的是属于Code Review范畴。更重要的是,任何实践都不能只关注形式,要看其价值,具体问题具体分析。对于新的团队新的人,可能刚开始需要多花时间去了解所写的测试。而对于成熟的团队,或者是非常有经验的Dev,这个Review过程可以简化,只看测试的标题,或者只是听Dev说一下测试覆盖到了哪些内容就可以了。

我一般要求整个Desk Check控制在15分钟以内,对于特别复杂的Story,最多也不要超过30分钟。

没有发现Bug的测试不是好测试

“这些自动化测试从来没有发现过Bug,ROI太低,没有存在的必要!”

图片来自:https://www.netsolutions.com/insights/wp-content/uploads/2016/08/Why-You-Need-Automation-Testing-For-Mobile-Apps-Th.jpg

由于有些测试执行起来太耗时、测试实现成本和维护成本都很高,大家在讨论要不要去掉这些测试的时候,总能听到上面那样的声音。

其实,自动化的回归测试并不是用来发现Bug的,有数字表明自动化回归测试发现Bug的比例仅有15%。自动化测试只是形成一道保护的屏障,增加对系统质量的信心。

敏捷团队的QA对质量应该有全面的认识,在制定测试策略的时候需要综合考虑多方面因素,要真正理解每个实践、每个活动背后的真实价值。

敏捷QA该怎么做?

关于QA的定义,有下面三个层次:

  1. QA = Quality Assurance质量保障
    第一个层次QA的要求是做好质量保障工作,确保我们交付给客户的软件产品是正常工作的。
  2. QA = Quality Analyst质量分析
    第二个层次的QA通过测试、数据收集的方式,分析系统的质量,识别风险,并反馈给团队,和团队所有成员一起确保交付的质量是合格的。
  3. QA = Quality Advocate质量倡导者
    第三个层次的QA不再局限于只关注质量,通过培养对产品和流程持续改进的思维模式、了解产品的整体质量视图和持续关注产品质量的意识,引导整个团队构建正确的产品,并且正确地构建产品。

敏捷QA需要做到第三个层次,通过分析软件风险并制定相应实践,确保软件在其整个生命周期中持续工作并创造价值,为业务和团队提供信心,从而为客户提供价值。

敏捷QA的所有实践和活动都需要以价值为核心来驱动,根据不同团队的具体情况可以适当调整,且在不同项目阶段应该也是演进式的。敏捷QA跟各个角色的沟通和协作,也是随着团队成员的了解程度、配合默契度不同而有变化,并不是要求一成不变的。

大规模团队的QA如何高效合作

“你们团队QA和DEV的人员比例是多少?”
“我们团队一般有1个QA和3~4对DEV pair.”

经常会被问到这样的问题,一般的小团队都是这样的人员比例,QA也不会觉得压力有多大。当多个特性团队工作在同一个代码库、分别在开发同一个系统的不同功能的时候,虽然每个特性团队也保持前面所述的比例,对于QA的挑战却要大得多,那是因为:

  • QA不仅要了解自己特性团队的需求,还需要了解其他团队的需求,因为这些功能都在同一个系统上,联系必然是很紧密的;
  • 某个团队发现的软件缺陷的根源、错误日志信息,在其他团队也可能发生,这些信息需要共享;
  • 某个特性团队有任何基础设施、测试环境配置文件的变化都得让所有团队知晓,而QA是其中沟通这个内容最恰当的角色;
  • ……
图片来自网络
(图片来自网络)

由此可见,大规模团队的QA不像小团队那么简单,沟通的成本要高很多。如果没有及时沟通,将会造成信息不对称,要补救所花费的额外精力是比较大的。当然,大规模团队不仅QA的沟通成本增加,其他角色也一样,只是因为我是QA嘛,就跟大家聊聊我们QA是如何应对这种大规模团队的挑战的。

集体参加story的kickoff和desk check

不管哪个组有kickoff和desk check,各组的QA都一起参加,这样基本能搞清楚各个团队都在开发什么功能。只有两三个特性团队的时候,这个方法还勉强行得通。但随着团队越来越多,在高峰期的时候,QA可能一天都在这两个活动中切换,通过这种方式了解各组的需求似乎不是一种高效的方式……

集体参加各组的feature kickoff

一个release做一个feature的话,QA参加feature kickoff每个release只需要参加一次,貌似还可以的样子。但由于各组的发布周期是一样的,各组做feature kickoff的时候,QA正是忙着上一个发布周期验收测试的收尾阶段,同时也是忙着review自己所在特性团队story的时候,一般都比较忙,尤其特性团队越来越多,如果还要集中参加其他组的feature kickoff,一定会忙不开……

前面这两项我们团队都有实践过,但显然都没能很好的坚持,因为手头的确有些忙不过来,这些自然优先级就变低了。大家始终坚信信息共享的重要性,于是团队在不断摸索中找到以下两种方式。

定期catch up

定一个每周一次的例会,要求QA们合理安排手头工作,务必参加该例会。例会上每个人
给大家介绍自己组内的feature,更新状态,把遇到的困难、blocker、风险等拿出来跟大家一起讨论,讨论对策,并且对一些接下来要做的事情清晰列出来,找到专人own,下次例会的时候检查执行情况。

QA内部showcase

在每个发布周期,在QA们做一次showcase,共享组内新开发功能特性。这样不仅锻炼了QA做好showcase的能力,同时也给其他团队QA共享了业务功能信息。

这两项实践以来,大家感觉到的收益还是蛮大的,除了知识、信息共享之外,也增进了QA间的相互了解,对于大家一起合作带来很大的帮助。

当然,除了这种具体的实践,更重要的是大家都有一颗愿意分享的心。随着例会和内部showcase的开展,QA们共享信息的意识得到了加强,日常工作中遇到某种情况觉得其他团队需要知道的就会主动分享出来。

大团队带来的挑战不是那么轻松容易解决,关于如何能高效协作,我们也还在继续摸索中。

不知道您所在团队是否也面临如此挑战?是否愿意和我们大家一起分享分享呢?

神圣的QA——写给应届毕业生

你有没有过下面的经历:

  • 在谷歌浏览器输入一个网址,出来一个错误提示:“不支持当前浏览器,请用IE访问”…
  • 换成IE,重新打开该网站,输入用户信息注册一个新用户,随后收到一封注册成功邮件,里边直接包含刚刚注册的密码…
  • 用注册的用户名密码登录进去,又不知道所需要的功能入口在哪里…
  • 翻遍了一层又一层的菜单,终于找到了入口,进去打开的是一个列表,足足等了2分钟才加载完成…
  • 从列表中找到自己需要的那个信息,点击“查看详情”,却显示一堆乱码…
这么多问题 :(

一次性碰到上面的各种当然属于极端现象,但我敢说,你一定碰到过其中的问题不止一次,而且碰到了一定很郁闷。这些都是软件缺陷,分别是兼容性、安全性、易用性、性能和功能方面的缺陷,一旦出现将会给企业和用户带来不同严重程度的影响。

这种糟糕的体验有没有使你产生想去优化的冲动?你是否想知道如何帮助软件开发团队开发出缺陷更少的软件产品?如果你的回答是肯定的,那么请跟我一起来做QA吧:)

QA是什么?

狭义的理解就是软件测试,软件测试工程师常被称为QA;广义上,QA就是在软件开发过程中做好软件质量分析和保证的人员。

QA的职责有哪些?

QA的职责

下面结合一个简单的例子说明QA的职责:生产杯子。

1. 理解和澄清业务需求

需求是软件开发的源头,需求的正确性、合理性对软件开发的质量有着至关重要的作用。QA的一个很重要的职责就是澄清需求、验证需求合理性,并且帮助团队一致理解需求。

需求包括功能需求,也包括各种非功能需求:性能、安全、易用性、兼容性等。所谓理解和澄清业务需求,就是需要把业务相关的功能和非功能需求都搞清楚了。

对于生产杯子的例子,QA需要搞清楚杯子的功能有哪些:普通的盛水、加热、保温、带吸管等等。杯子的功能可能还远不止这些,这就需要发散性思维,去挖掘可能得用途并进行确认、测试。除了功能需求以外,还有要考虑的非功能需求可能有:材质耐热性、耐摔性、跟各种液体的兼容性、安全性(是否有毒?是否可以砸伤人?)……

注意

需求的澄清是个过程,并不是在开始开发和测试之前要搞清楚所有的需求(这也是不可能的),同时可以在开发和测试过程中不断去澄清需求、优化业务流程。

2. 制定策略并设计测试

澄清了需求,还得知道怎么去验证软件产品是否满足了需求,这就需要制定测试策略,并根据策略设计测试。大概说来,需要确定测试范围、测试阶段,覆盖要求的测试范围都需要什么类型的测试(功能与非功能等),在每个阶段采用什么测试方法,手动测试和自动化测试的分配比例,如何设计手动和自动化测试的测试用例,用什么工具实现功能、性能和安全测试的自动化等。

对于杯子来说,确定需求之后,针对每一项需求指标需要确认可能采取的不同测试方法,需要考虑如何测试盛水和加热功能、如何测试耐摔性(直接摔吗?)、以及如何测试安全性等等。

可以参考测试四象限测试金字塔等模型来制定测试策略,并根据产品发布周期制定具体的测试计划、设计测试内容。

注意

设计测试,不仅是指设计测试用例。
四象限和金字塔只是个参考,不可以生搬硬套,而且有些内容稍有争议,但参考价值还是很大的。

3. 执行和实现测试

根据制定的测试策略和测试计划、设计好的测试用例,执行手动的验收测试和探索式测试等,实现和执行功能和非功能的自动化测试,统计和生成测试结果报告。

对于生产的杯子,根据设计的测试方案对产品(半成品)进行测试,可能的方式有:往里加水,直接摔到地板上,加热至100摄氏度,往里注入硫酸等。测试之后,统计和生成杯子的测试结果报告,内容包括但不限于测试样品集、测试方法、测试结果、成功率等。

4. 缺陷管理

测试之后,必然会发现很多的缺陷,对这些缺陷进行有效的管理是QA们一个非常重要的职责之一。缺陷管理包括以下内容:

  • 记录缺陷
    发现缺陷以后,QA需要尽自己所能去调查缺陷,收集所有跟缺陷相关的信息,包括不限于出现的环境(操作系统、浏览器和不同的测试环境等)、重现步骤、屏幕截图、日志等,并将这些信息简单清晰的记录下来。
  • 确定严重性和优先级
    严重性是指缺陷发生对用户所产生影响的严重程度,优先级是指需要修复的紧急程度,通常需要结合严重性和发布计划等来确定。新QA往往比较容易混淆这两个概念,注意它们是有区别的,优先级高的严重性不一定高,而严重性高的往往优先级比较高。具体需要根据产品和项目实际情况来确定。
  • 分析和跟踪缺陷
    开发人员修复缺陷之后,QA需要测试和验证缺陷,很多时候缺陷被验证之后就没人管了,但缺陷的生命周期并没有结束,后面还有非常重要的分析和跟踪阶段。在这个阶段,QA要分析缺陷产生的原因,影响的功能模块,过去一段时间以来的发展趋势等,根据这些分析结果制定下一阶段避免和减少同样缺陷产生所需要采取的行动措施,并且跟踪行动执行的详细情况。
注意

缺陷分析是非常重要的一个环节,但却很容易被忽略。关于缺陷管理的更多详细内容请参考我的另一篇文章《软件缺陷的有效管理》

再来看看杯子的例子,执行一番测试之后,可能发现如下缺陷:

  1. 容积为100毫升的量杯只能盛水80毫升
  2. 杯子表面不够光滑但不影响使用
  3. 清水倒进去水变成酸的了

第一个是严重的功能缺陷,第二个属于UI问题,第三个可能是一个非常严重的安全性问题。QA需要将这些缺陷报告,并根据严重性和产品流程等来安排优先级,督促开发人员及时修复高优先级的缺陷。缺陷修复并重新测试没问题之后,要分析统计,找出产生缺陷的环节,并采取措施防止下一批杯子出现同样的问题。

5. 质量反馈和风险意识

软件产品的质量不是QA这一个角色能保证的,而是需要整个开发团队所有人员齐心协力,共同为质量负责。QA作为质量分析保证的主力军,对产品质量需要有更清晰的认识,及时识别质量风险,并反馈给整个团队。

将质量相关因素可视化出来,是反馈给团队的较为有效的方式。质量可视化包括但不限于cycle time、自动化测试覆盖率、缺陷分析报告、错误日志分析、网站分析工具统计报告、性能监控数据、安全扫描结果、用户反馈、产品环境下的缺陷统计等,可以根据项目和产品具体情况具体定义。

定期或者不定期的把这些可视化结果反馈给团队,有助于形成团队对质量的统一认识,发挥团队每个成员对于质量保证的主观能动性,从而一起制定和调整下一阶段的质量保证策略。

测试了一批杯子之后,将杯子的质量相关情况反馈给团队,内容可能是:

  • 最近这批杯子出现的缺陷明显比上一批少,可以鼓励团队再接再厉;
  • 这批杯子出现了很多严重缺陷,那么就需要组织团队一起讨论问题根源,考虑采取措施防止问题重复出现;
  • 某一批杯子等待很久才可测,需要分析原因,采取改进行动;
  • 这一批杯子生产效率明显比以前有提高,同样可以确认效率提高的原因,后续可以以此为参考持续改进和提高。

QA的必备技能要求

硬技能之扎实的计算机基础

软件测试的概念虽然已经出现多年,但QA或者软件测试工程师还是被很多人误认为就是简单的点击应用程序进行测试,是一项没有技术含量的工作。其实,从前面对QA职责的描述,大家可以看到,QA的技能要求还是蛮高的,其中非常关键的一项就是具备扎实的计算机基础,具备基本的编码能力和数据库操作能力。

只有了解系统的工作原理,才能更好的去验证系统的完备性,发现问题才能更快更有效的初步定位。因此,下次有人问你为啥选择软件测试行业,千万别说是因为自己技术不行,那样会被鄙视的。

各项软技能

从QA的职责要求可以看出,做好QA还需要多方面的软技能:

  • 快速理解业务的能力:通常丰富的领域知识和快速学习新事物的能力可以帮助快速理解业务。
  • 分析能力和定位问题的能力:执行测试和定位缺陷的过程中,这种能力非常重要。
  • 良好的沟通表达能力,包括口头和书面沟通:QA需要跟客户、需求人员、开发人员等不同角色沟通以更好的完成工作,良好的沟通将会事半功倍。
  • 踏实、认真、细心:每一个测试、每一个缺陷都需要认真的对待,容不得半点浮躁,这些技能无需细说。

当然,除此之外,能在QA职业道路上有良好的发展,极其重要的一点是对软件质量相关工作有浓厚的兴趣。

写在最后

QA在一个软件开发团队,能与需求人员一起分析需求,能与开发人员一起编写测试,能给团队和客户详细展示系统功能,还能更新整个产品/项目的质量状态,是比PM更为了解产品/项目的人,听起来就很厉害,对不对?

是的,QA就是这么神圣的工作!你心动了吗?

软件缺陷的有效管理

“这次发布之前怎么这么多的缺陷,是不是需要分析一下啊?” 答案是肯定的,可是这个时候才想起要分析已经有点晚了,有可能这些缺陷很难分析了。这是发生过的一个真实场景,所记录的缺陷包含信息很有限,很难有效的做好分析!本文就来聊聊如何有效的管理和分析缺陷。

缺陷记录

曾经有个项目是在QC(Quality Center)里记录缺陷,需要填写很多必填属性字段,加上QC服务器在国外,访问速度非常的慢,每次记录缺陷成为了大家极其痛苦的一件事情。于是,很多时候,发现了缺陷也不愿意往QC里填,而是直接写个纸条简单记录下,验证完了它的生命周期就结束了,这样后面就没办法去很好的跟踪和分析了。(题外话:当时采用脚本稍微减轻了点痛苦。)

也有的项目对缺陷的格式和属性没有严格要求,记录的时候很简单也很自由,这样记录的缺陷由于很多必要信息的缺失,对后续的跟踪和分析也是极为不利。

还有一种情况就是记录缺陷时同样有一些属性要求填写,但是这些属性值可能不是那么有意义,导致存储的信息不仅没用,反而添加混乱,也是不利于跟踪和分析的。比如,其中的“根源(root cause)”属性的值如下图1所示,这些值根本就不是根源,这是一个没有意义的捣乱属性。

图1.某项目缺陷根源属性值

缺陷记录应该做到尽量简单,且包含必要的信息。

1. 标题:言简意赅,总结性的语句描述是什么缺陷

2. 详情:包括重现步骤、实际行为、期望结果等,根据具体情况确定其详细程度,必要时可以添加截图、日志信息等附加说明。

3. 重要属性:优先级、严重性、所属功能模块、平台(OS、浏览器、移动设备的不同型号等)、环境、根源等,这些属性对应的值需要根据不同项目的情况自己定义,其中“根源”是相当关键的一个属性,后面有示例可以参考该属性对应的值有哪些。

4. 其他:每个项目对应的还会有其他信息需要记录的,自行定义就好。

在敏捷开发环境中,测试人员可能随时在测试、随时都会发现缺陷,包括还在开发手里没有完成的功能。什么时候发现的缺陷需要记录呢?通常情况下,开发还没完成的用户故事(story),测试人员发现缺陷只需要告诉开发修了,在该故事验收的时候一起检查就好了,无需单独记录;在开发已经完成,交到测试人员手里正式测试的故事,再发现缺陷就需要记录来跟踪了;后续的所有阶段发现的缺陷都需要记录。

缺陷分析

比较推荐的一种缺陷分析方法是鱼骨图分析法,可以将跟缺陷相关的各个因素填写到鱼骨图里,对缺陷进行分析,如下图2示:

图2. 鱼骨图缺陷分析法

缺陷相关的各属性拿到了,就可以用表格、曲线图、饼图等统计各个属性对应的缺陷数量,分析缺陷的趋势和原因。下面是我在项目上做过的分析报告图:

图3. 功能/环境对应缺陷数量统计表和缺陷根源比例图

图4. 缺陷根源统计表和比例图

图5. 缺陷迭代趋势分析图

分析完得到统计的结果就要采取对应的措施,从而防范更多的缺陷产生。比如:修缺陷(上面示例中的“bug fixing”)引入的新缺陷比较多,可以在修复缺陷后添加对应的自动化测试;浏览器兼容性问题相关的缺陷较多的话,可以在开发完成验收的时候在多种浏览器上验收,等等。

什么时候该进行缺陷的分析呢?通常,推荐每个迭代周期分析一次,并且跟以往各个迭代进行对比,进行趋势对比。当然,有时候可能一个迭代发现的缺陷非常少,分析的周期可以根据具体情况做出调整。

总结

缺陷记录是为更好的跟踪和分析缺陷做准备的,而缺陷分析是软件质量保证的重要环节,对于软件过程的改进,软件产品的发布来说具有十分重要的参考价值,建议各项目定期都要做做缺陷分析。

(此文发表于TW洞见