做测试如何应对新的开发模式?

Posted 乐却思蜀

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了做测试如何应对新的开发模式?相关的知识,希望对你有一定的参考价值。

为什么需要测试左移,测试右移?

测试可以保证产品质量,重要性不言而喻。但,要做好测试也比较困难,需要克服很多挑战。尤其是,持续交付、敏捷开发等开发模式为传统 软件测试方式带来了更大的时间压力。

我们先来看看下面这种熟悉的测试方式都有什么问题:测试人员接到项目后参与需求评审,然后根据需求文档写用例、准备脚本,等开发提测之后正式开始测试、提 Bug、回归,测试通过后就结束了,项目交给运维上线,之后投入下一个项目继续重复这样的流程。

这样的流程看似没什么错,但有两大问题:

测试人员非常被动。当需求质量、开发质量较差的时候,测试人员只能被动接受。
但同时,测试又被认为是质量的责任人。如果因为需求质量、开发提测质量差而导致上线延期,大家通常会首先怪罪测试团队。

这些问题,在新的开发模式下愈发严重。因为这些新的开发模式有一个共同点,就是要缩短产品的交付周期,对自动化的要求越来越高,能够专门留给传统竖井流程中测试环节的时间越来越短,自然更难保证质量。在极端的情况下,比如在持续部署的模式下,所有测试都是自动化的,已经完全没有留给测试人员专门进行手工测试的时间了。与此同时,测试的能力和质量又是这些开发模式成功的关键。否则,即使可以频繁地构建产品,质量不过关价值也为零。所以,在快速开发模式的挑战下,测试左移、测试右移就应运而生了。这些测试模式,能让测试人员拥有更多主动权,以及更多的时间进行测试。

那,到底什么是测试左移和测试右移呢?

什么是测试左移和测试右移?

测试左移和右移,就是把测试的范围从传统测试的节点中释放出来,向左和右扩展。

向左扩展,就是让测试介入代码提测之前的部分。比如,扩展到开发阶段,在架构设计时就考虑产品的可测试性,并尽量进行开发自测等。另外,测试可以更进一步扩展到需求评审阶段,让测试人员不只是了解需求,更要评估需求的质量,比如分析需求的合理性以及完整性等。

类似的,测试右移,是让测试介入代码提测之后的部分。比如,测试人员在产品上线过程中,利用线上的真实环境测试。另外产品上线之后,测试人员仍然介入,通过线上监控和预警,及时发现问题并跟进解决,将影响范围降到最低。这样一来,测试人员不但有更多的时间进行测试,还能发现在非生产环境中难以发现的问题。

测试左移的原则和实践

1、调整团队对测试的态度;
2、把测试添加到开发和产品需求步骤中;
3、频繁测试,快速测试。

测试左移原则一:调整团队对测试的态度

调整团队对测试的态度,打破竖井的工作方式,是测试左移的前提。一个有效的办法是,按照功能的维度管理团队,让整个功能团队对产品负责。也就是说,如果产品质量出现问题,不只是测试团队“背锅”,而是会影响整个功能团队的绩效。同时,让质量问题的直接责任人承担更多的责任,来进一步增强团队成员的责任心。这种利益绑定的办法,虽然简单但非常有效,只不过出现质量问题时要记得进行根因分析,以避免再次出现类似问题。

另外,还要改变团队成员对测试工作的认知。传统的工作方式中,我们通常认为发现 Bug 最重要,但其实为了提高产品质量,更重要的是预防 Bug。所以说,在测试左移的过程中,我们应该更聚焦在预防 Bug 上。

测试左移原则二:把测试添加到开发和产品需求步骤中

测试左移的第一步,是把测试工作融入到开发步骤中。常用的办法是,让测试人员参与到开发阶段的方案设计中,了解开发的实现方式。因为很多开发人员可能只熟悉他负责的那一部分,而测试人员往往对全局更加了解,所以测试人员要评估改动范围以及是否有遗漏的模块和系统。

另外一个比较彻底,也很有效的方法是全栈开发,通过运维团队提供工具和支持,让开发人员尽量参与到运维工作中去。对于测试来说,也是同样的道理。我们可以让测试团队转型,进行工具开发,并更多地去支持专项测试,比如性能测试、安全测试等,通过“使能”的办法,让开发人员完成功能测试,包括单元测试、集成测试等。

说到让开发人员完成部分测试工作,常常会听到很多质疑声。反对者认为,测试人员的心理模型跟开发人员不一样,他们更倾向于去找问题。而开发人员面对自己开发的产品,潜意识里就不愿意去找问题,比如,他们不愿意专门尝试各种边界输入进行测试,而把自己开发的功能搞崩溃。所以,开发人员和测试人员更适合分开。

这种观念,在 10 年前瀑布开发模式盛行时就深入人心。我曾经也非常认同,但在 Facebook 工作了 5 年后改变了看法。如果你能够把开发人员的责任界定得很清楚,谁开发的产品谁要保证质量,那么开发人员自然而然地就会去尝试做好测试,比如进行边界测试。而且,开发人员最了解自己写的代码,所以他能够最高效地对自己的代码进行测试。

当然,做全栈开发的同时我们仍会保留一部分功能测试人员,毕竟从竖井模式转变到全栈模式是一个循序渐进的长期过程。不过 Facebook 做到了极致,完全没有了功能测试人员,也就是我们所说的“去 QA”。

测试左移到了开发阶段之后,再往左移一步就到了产品设计阶段,在这里,测试人员除了解需求外,更重要的是评估需求的质量。

我推荐使用 BDD(Behavior Driven Development,行为驱动开发)的方法进行开发,促进团队在需求评审时更多地考虑测试。BDD 是通过特定的框架,用自然语言或类自然语言,按照编写用户故事或者用例的方式,从功能使用者的视角描述并编写测试用例,从而让业务人员、开发人员和测试人员着眼于代码要实现的业务行为,并以此为依据通过测试用例进行验证。

测试左移原则三:频繁测试,快速测试

测试左移的第三个重要原则是,频繁测试、快速测试。在测试左移之前,我们需要等待提测,比较被动,不能频繁测试。但测试左移到开发阶段之后,我们就有了很大的自由度去频繁运行测试,从而更好地发挥测试的作用,尽早发现更多的问题。

这里最重要的方法就是,我在讲持续开发时提到的几个关于验证的操作,具体包括:

规范化、自动化化本地检查;

建设并自动化代码入库前的检查流程;

提供快速反馈,促进增量开发。

另外,为了能够顺利、频繁地运行测试,我们还要提升测试运行的速度。给测试提速的常见办法包括:

  • 并行运行。比如把测试用例放到多台机器上运行,用资源换时间。
  • 提高构建速度。比如使用精准构建,因为通常构建之后才能运行测试。
  • 精准测试,也就是只运行跟改动最相关的测试。可以建立需求与代码的关系,以及需求与测试用例的关系,从而在代码改动时重点关注与之最相关的测试用例。
  • 分层测试,即不同情况运行不同测试用例集合。
  • 减少不必要的用例。比如,识别不稳定的用例,对其删除或者优化。

以上是关于做测试如何应对新的开发模式?的主要内容,如果未能解决你的问题,请参考以下文章

微信公众号教程用微信开发模式做欢迎词

测试人员在敏捷团队中扮演的角色

敏捷开发模式

开发模式

如何在新的 Facebook 开发者中禁用应用程序的沙盒模式?

从一个实例详解敏捷测试的最佳实践