极客时间已完结课程限时免费阅读

17 | 测试左移：测试如何应对新的开发模式？

17 | 测试左移：测试如何应对新的开发模式？-极客时间

17 | 测试左移：测试如何应对新的开发模式？

2019-09-30 葛俊 来自北京
《研发效率破局之道》
课程介绍

讲述：葛俊

时长12:05大小11.07M

你好，我是葛俊。今天，我们来聊聊测试这个话题。

为什么需要测试左移，测试右移？

测试可以保证产品质量，重要性不言而喻。但，要做好测试也比较困难，需要克服很多挑战。尤其是，持续交付、敏捷开发等开发模式为传统软件测试方式带来了更大的时间压力。
我们先来看看下面这种熟悉的测试方式都有什么问题：测试人员接到项目后参与需求评审，然后根据需求文档写用例、准备脚本，等开发提测之后正式开始测试、提 Bug、回归，测试通过后就结束了，项目交给运维上线，之后投入下一个项目继续重复这样的流程。
这样的流程看似没什么错，但有两大问题：
测试人员非常被动。当需求质量、开发质量较差的时候，测试人员只能被动接受。
但同时，测试又被认为是质量的责任人。如果因为需求质量、开发提测质量差而导致上线延期，大家通常会首先怪罪测试团队。
这些问题，在新的开发模式下愈发严重。因为这些新的开发模式有一个共同点，就是要缩短产品的交付周期，对自动化的要求越来越高，能够专门留给传统竖井流程中测试环节的时间越来越短，自然更难保证质量。
在极端的情况下，比如在持续部署的模式下，所有测试都是自动化的，已经完全没有留给测试人员专门进行手工测试的时间了。与此同时，测试的能力和质量又是这些开发模式成功的关键。否则，即使可以频繁地构建产品，质量不过关价值也为零。在我看来，《持续交付：发布可靠软件的系统方法》这本关于持续交付经典图书，更像是一本介绍测试的书，也是因为这个原因吧。
所以，在快速开发模式的挑战下，测试左移、测试右移就应运而生了。这些测试模式，能让测试人员拥有更多主动权，以及更多的时间进行测试。那，到底什么是测试左移和测试右移呢？

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

测试左移和右移，就是把测试的范围从传统测试的节点中释放出来，向左和右扩展。
向左扩展，就是让测试介入代码提测之前的部分。比如，扩展到开发阶段，在架构设计时就考虑产品的可测试性，并尽量进行开发自测等。另外，测试可以更进一步扩展到需求评审阶段，让测试人员不只是了解需求，更要评估需求的质量，比如分析需求的合理性以及完整性等。
类似的，测试右移，是让测试介入代码提测之后的部分。比如，测试人员在产品上线过程中，利用线上的真实环境测试。另外产品上线之后，测试人员仍然介入，通过线上监控和预警，及时发现问题并跟进解决，将影响范围降到最低。这样一来，测试人员不但有更多的时间进行测试，还能发现在非生产环境中难以发现的问题。
从测试右移的概念中可以看出，它与我们下一篇文章“蓝绿红黑灰度发布：这些五颜六色的发布到底怎么用？”中的各种部署模式强相关，所以我会在下一篇文章中与你介绍。而在今天这篇文章中，我会与你详细介绍测试左移的原则和实践。

测试左移的原则和实践

在我看来，要做好测试左移，有 3 个基本原则：
调整团队对测试的态度；
把测试添加到开发和产品需求步骤中；
频繁测试，快速测试。
接下来，我们具体看看这 3 个原则吧。

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

调整团队对测试的态度，打破竖井的工作方式，是测试左移的前提。一个有效的办法是，按照功能的维度管理团队，让整个功能团队对产品负责。也就是说，如果产品质量出现问题，不只是测试团队“背锅”，而是会影响整个功能团队的绩效。同时，让质量问题的直接责任人承担更多的责任，来进一步增强团队成员的责任心。这种利益绑定的办法，虽然简单但非常有效，只不过出现质量问题时要记得进行根因分析，以避免再次出现类似问题。
另外，还要改变团队成员对测试工作的认知。传统的工作方式中，我们通常认为发现 Bug 最重要，但其实为了提高产品质量，更重要的是预防 Bug。所以说，在测试左移的过程中，我们应该更聚焦在预防 Bug 上。

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

测试左移的第一步，是把测试工作融入到开发步骤中。常用的办法是，让测试人员参与到开发阶段的方案设计中，了解开发的实现方式。因为很多开发人员可能只熟悉他负责的那一部分，而测试人员往往对全局更加了解，所以测试人员要评估改动范围以及是否有遗漏的模块和系统。
另外一个比较彻底，也很有效的方法是，我在第 8 篇文章中提到的全栈开发。当时，我们讨论全栈开发的场景主要是，通过运维团队提供工具和支持，让开发人员尽量参与到运维工作中去。对于测试来说，也是同样的道理。我们可以让测试团队转型，进行工具开发，并更多地去支持专项测试，比如性能测试、安全测试等，通过“使能”的办法，让开发人员完成功能测试，包括单元测试、集成测试等。
说到让开发人员完成部分测试工作，常常会听到很多质疑声。反对者认为，测试人员的心理模型跟开发人员不一样，他们更倾向于去找问题。而开发人员面对自己开发的产品，潜意识里就不愿意去找问题，比如，他们不愿意专门尝试各种边界输入进行测试，而把自己开发的功能搞崩溃。所以，开发人员和测试人员更适合分开。
这种观念，在 10 年前瀑布开发模式盛行时就深入人心。我曾经也非常认同，但在 Facebook 工作了 5 年后改变了看法。如果你能够把开发人员的责任界定得很清楚，谁开发的产品谁要保证质量，那么开发人员自然而然地就会去尝试做好测试，比如进行边界测试。而且，开发人员最了解自己写的代码，所以他能够最高效地对自己的代码进行测试。
当然，做全栈开发的同时我们仍会保留一部分功能测试人员，毕竟从竖井模式转变到全栈模式是一个循序渐进的长期过程。不过 Facebook 做到了极致，完全没有了功能测试人员，也就是我们所说的“去 QA”。
测试左移到了开发阶段之后，再往左移一步就到了产品设计阶段，在这里，测试人员除了解需求外，更重要的是评估需求的质量。
我推荐使用 BDD（Behavior Driven Development，行为驱动开发）的方法进行开发，促进团队在需求评审时更多地考虑测试。BDD 是通过特定的框架，用自然语言或类自然语言，按照编写用户故事或者用例的方式，从功能使用者的视角描述并编写测试用例，从而让业务人员、开发人员和测试人员着眼于代码要实现的业务行为，并以此为依据通过测试用例进行验证。
这里有一篇关于 BDD 的文章，推荐你阅读。

测试左移原则三：频繁测试，快速测试

测试左移的第三个重要原则是，频繁测试、快速测试。在测试左移之前，我们需要等待提测，比较被动，不能频繁测试。但测试左移到开发阶段之后，我们就有了很大的自由度去频繁运行测试，从而更好地发挥测试的作用，尽早发现更多的问题。
这里最重要的方法就是，我在讲持续开发时提到的几个关于验证的操作，具体包括：
规范化、自动化化本地检查；
建设并自动化代码入库前的检查流程；
提供快速反馈，促进增量开发。
你可以再复习下第 5 篇文章中的相关内容。
另外，为了能够顺利、频繁地运行测试，我们还要提升测试运行的速度。给测试提速的常见办法包括：
并行运行。比如把测试用例放到多台机器上运行，用资源换时间。
提高构建速度。比如使用精准构建，因为通常构建之后才能运行测试。
精准测试，也就是只运行跟改动最相关的测试。可以建立需求与代码的关系，以及需求与测试用例的关系，从而在代码改动时重点关注与之最相关的测试用例。
分层测试，即不同情况运行不同测试用例集合。
减少不必要的用例。比如，识别不稳定的用例，对其删除或者优化。
在这里，我再与推荐两个精准构建和精准测试的工具。一个是，Facebook 使用并开源的Buck系统，可以用来提高构建速度；另一个是，Google 开源的Bazel，支持精准构建和精准测试。

小结

在敏捷、持续交付等开发模式愈发流行的今天，产品的研发节奏越来越快，传统的开发提测之后进行测试，然后交给运维上线的测试模式受到很大的挑战。由此促成了测试左移和右移等新的测试方法，也就是测试向左扩展到产品设计、开发流程中，向右扩展到发布、生产流程中，从而在整个研发流程中持续关注测试，解决新模式给测试带来的挑战。
而测试左移，本质上是尽早发现问题、预防问题。基本原则包括：从人的角度出发，让产品、开发、运维人员统一认识，重视测试；从流程上，让测试融入产品设计和开发步骤中；快速测试、频繁测试。
其实，软件开发行业早就达成了共识，问题发现得越晚，修复代价越大。《代码大全》这本书，从软件工程实践的角度说明了修复⼀个 Bug 的成本在产品需求分析阶段、设计阶段、开发阶段、测试阶段有着天壤之别。比如，在集成阶段修复一个 Bug 的成本是编码阶段的 40 倍。除了成本悬殊之外，在修复难度、引入新问题的可能性、沟通成本、团队状态等方面也有很大的影响。
在我开来，Facebook 正是成功进行了持续测试，让测试融入到了整个研发流程中，从而没有 QA 团队也能保证产品的高质量。

思考题

你认为测试左移和测试右移，会不会减少测试人员的工作机会呢？如果你是测试人员，又应该怎么面对这个新的测试模式带来的挑战呢？
感谢你的收听，欢迎你在评论区给我留言分享你的观点，也欢迎你把这篇文章分享给更多的朋友一起阅读。我们下期再见！
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享

赞 1

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
16 | 高效上云：如何用云计算来提高效能？
下一篇
18 | 蓝绿红黑灰度发布：这些五颜六色的发布到底怎么用？
 写留言

精选留言(13)

  • 技术修行者
    2019-10-01
    1. 测试左移和测试右移是在市场激烈竞争情况下的必然结果，做不到的话，迟早会被淘汰。 2. 如果项目在用成熟的敏捷开发框架进行项目管理，团队中测试人员的比重会越来越少。 3. 在做项目计划的时候，尤其是让开发人员给时间评估时，必须要为单元测试和自动化测试预留时间，一个功能可以交付的标准不仅仅是实现功能，对应的测试集也是需要包括的，这部分需要管理层有一个思维转换。 4. 软件开发团队变为全栈开发全队的趋势越来越明显，全栈开发不止是对传统开发人员你的要求，也是对测试人员的要求，测试人员可以考虑扩展技能，例如自动化测试、运维、项目管理等，不要让工作中的角色限制我们未来的无限可能。
    展开

    作者回复: 再一次分析得很全面！赞！

    共 2 条评论
    13
  • Jxin
    2019-10-06
    关于这个所谓的后端全栈。刚好有过思考，分享下。 从经济学角度看，社会分工可以实现专人专事，进而解放生产力，让总收益更大，所有参与方都受益。但是分工就会有沟通协作的成本，工序多会增加出事故的概率。那么为什么以前强调分工，现在又推崇垂直整合呢（去qa和devops的理念）。我认为是软件稳定性诉求和软件工程开发模式共同决定的。以前，软件的用户体量小，事故和不可用的影响较小，并且开发模式大多是瀑布开发，时间上也比较经得起折腾。而现在，大的互联网公司，用户体量都是千万，亿级别的，系统稳定性诉求就高，往往都要4个9，5个9，且大部分推行的都是敏捷开发或伪敏捷开发，进而对系统稳定性和迭代速度的诉求就有了新的挑战 。而依旧保持分工的模式对接不上这个变化（天时），同时测试运维经过这几年的发展演变，也推陈出新有了很多新技术新框架，开发要学习测试运维技术栈的成本已经可以接受（地利），最后，新技术的轻便学习成本低，加上程序员的高薪，进几年也涌进了大量新鲜血液到互联网行业（人和）。故，这种垂直整合的模式一推出需求（去qa和devops），就有大批技术人员调整技术栈去迎合变化。而在精益开发，企业中台建设的推进中，甚至连产品思维也可能会落到开发的技能树中。
    展开

    作者回复: > ...那么为什么以前强调分工，现在又推崇垂直整合呢（去qa和devops的理念）。我认为是软件稳定性诉求和软件工程开发模式共同决定的... 这种探究深层次原因的思考非常棒！我觉得一个非常重要的原因是交互方式的改变。互联网越来与普遍后，有了快速交付的条件。这个是快速迭代的基础。 比如，2005年我在微软Windows团队的时候，大家都还是主要使用光盘发布Windows。DVD刻好交付给客户之后，再修改起来代价可就高了去了。所以当时主要用瀑布模式，非常强调在前期的计划，希望一次搞定。 在有了快速迭代的条件之后，大家逐渐意识到快速迭代对快速、准确交付用户需要的产品非常有效，所以逐渐往这个方向发展。在这种方式下，全栈也就比较自然起来。 这是我的思考 ：）欢饮继续讨论

    共 2 条评论
    5
  • 张裕
    2019-09-30
    管理团队理念的改变至关重要，将传统智能团队重组成全栈团队，不然很多实践只能流于表面

    作者回复: 是的。一般来说做事的顺序都是 人 -> 流程 -> 工具

    4
  • mgxian
    2019-09-30
    测试左移是 TDD/BDD 能充分发挥作用的地方了。右移大部分时间应该在预发布环境（共享生产环境数据）进行测试。

    作者回复: 是的，TDD的确是一个测试左移的方式，虽然我个人用的并不是很多。 对于右移，当前情况的确是很多时间在预发布环境进行测试，但是趋势是越来越多的可以在生产环境上做。我在下一篇文章会详细讨论。

    2
  • 刘丹
    2019-09-30
    测试左移和右移，减少了耗时长的功能测试（例如从3个人变成1个人），增加了自动化测试（例如从1人个变成2个人），提升了测试的效率，总体上应该是减少了测试人员岗位数量。 作为测试人员，要用全栈开发的标准来要求自己，不仅要横向发展，也要竖向发展。例如在学习多种测试技能（功能测试、自动化测试、性能测试、安全测试）、完成本岗位工作任务的基础上，根据个人和公司的情况向运维、开发、需求、项目管理等领域渗透拓展。
    展开

    作者回复: 是的。测试人员在这种趋势下，有压力的同时也是有更多的成长机会（无论是主观还是客观情况要求）。

    共 2 条评论
    2
  • 大风起兮
    2019-11-03
    测试左移能否成功，依赖左移的测试工作量是不是能被工具化和研发人员自测消化掉，不然就累死QA了（去QA，哈哈）

    作者回复: 这个玩笑过分啦，哈哈

    1
  • 高倩
    2019-10-22
    测试左移和右移，对于测试来说是好事情，可以掌握整个需求的全面性，来源以及价值。 但是目前会存在一个问题，就是没办法完全依靠左移来提高原来竖井模式的测试效率，测试既要左移，右移，又要进行测试。比如正在进行一个项目的测试，此时产品又提了几个需求，测试陷入车轮战，会很疲惫。

    作者回复: > 没办法完全依靠左移来提高原来竖井模式的测试效率，但是应该也都提高一些效率。时间花在这个上面比只花在竖井测试环节，对团队的总体效率是提升的。 另外要加强开发自测。多让他们做左移了的测试。

    1
  • 刘晓光
    2019-10-01
    测试左移可以提高开发测试比么？ it depends，它俩没有绝对的因果关系。切记。哈哈。

    作者回复: 听起来是有故事的人 😀 可以分享一下吗？

    1
  • 李双
    2019-09-30
    有学习一新思路
    共 1 条评论
    1
  • 道客
    2021-06-01
    facebook buck系统的链接这里点不开
  • 文中
    2020-04-14
    我们是这样管理分支的，请老师看看有没有优化的空间： - Master：线上版本对应的主分支（Master 分支的头指针指向当前线上版本） - Release：每个 sprint 的开发、测试主分支，可以理解为不同迭代的计划上线分支，也称为 Sprint 分支 - Feature：用于研发开发自己的特性 / bugfix 分支。 一般只对研发可见。 - Hotfix：用于对线上问题进行热修复的分支。parent 是当前 Master 分支。 具体的操作方式如下： - Master 主分支是一个受保护分支，绝大部分情况下只应通过持续集成工具进行合并。合并的时机是 Prod 上线完成， - Release 分支是目前按 Sprint Name 定义，例如 sprint-101，表示第 101 个迭代对应的 sprint。 - Feature 分支从计划发布的 Release 分支上拉出单独的 Feature 分支进行开发。Feature 开发完毕以后，提 Merge Request ，请求将对应分支合并到 Release 主分支。Merge Request 提出以后，会触发 Pre Merge check，待 merge 的版本会在 Gitlab 先进行一次 local CI（主要是单元测试），并将结果更新至 Gitlab Merge Request 页面中。若 Pre Merge Check 通过，研发负责人 review 代码，review 通过后合并代码到 Sprint 主分支。若 Pre Merge Check 不通过，Merge Request 提交人修复后重新提交。 环境维护方式如下： - 研发人员在 Sprint N 结束时将 Sprint N 分支的当前版本更新给测试人员。 - 在 Sprint N+1 开始时 - 研发人员基于 Sprint N 的版本，拉出 Sprint N+1 的主分支，开始下一个 Sprint 的 Feature 的对应开发。 - 测试人员发布 Sprint N 的版本到测试环境，开始测试。测试过程中若发现 Bug，提出 Jira，指派给对应的研发人员。研发人员按相关流程修复以后，还应 Merge 到 Sprint N+1 分支。 - 研发人员按需将 Sprint 分支的当前版本更新到 Dev 环境，用以联调。 Dev / Test 环境有常规的 CI Job 对当前 Sprint 版本的正确性进行校验（每日的 1830 / 0630 执行）。对于集成自动化测试的测试用例，也有一个和 Release 分支相对应的分支，用于编写当周实现的功能的自动化用例。 其他注意事项 需要有节点检查当前的版本是否包含 master 分支上的所有改动，目前 check point 通过以下方式设置： - gitlab server 上设置 pre-receive hook，检测每次提交是否包含 master 当前最新版本 - venus 提交发布工单时，检测当前版本是否包含 master 当前最新版本 - 未上线的 Release 分支的所有变化(bugfix，临时插入的需求等），都要被所有后续拉出的活跃 Release 分支 Merge
    展开

    作者回复: 不好意思回复晚了。这几天特别忙。 感谢详细的描述。你们这个跟git flow workflow 比较相似，还是比较成熟的！说到提高，我觉得如果能做到主干开发那就最好，因为那样才能做到及时的对每一个提交都CI。 你们觉得有什么具体的痛点吗？

  • Joe Black
    2020-02-16
    感觉很多内容适用于相对大众化的软件，而且前提是人员的软件和工程化能力都还可以。我们是做行业专业软件的，开发人员基本都是在特定专业本科硕士博士学下来的，没有受过软件工程方面的训练，开发也都是自学，参加工作的时候连版本控制都没听说过，因为学编程大多是为了发paper。 总体感觉我需要先把技术人员的软件工程水平提高到一个基本层次，然后才能上一些提升效能的实践。
    展开

    作者回复: 这个要看需求。如果写paper不需要这些高效的实践，那也不需要。高效实践归根结底是为业务服务的。 当然，一个常见问题是大家不知道高效的研发是什么样的，从而不知道高效研发实际上能给自己带来的好处。所以，推荐让大家了解一下这些高效的开发模式，让大家自己判别是否需要在研发效能方面投入资源和时间。

  • 沫沫（美丽人生）
    2019-11-16
    有个问题请教一下 ，现在我们的代码管理有开发分支，测试分支和发布分支 ，如果现在开发左移，让研发参与更多测试工作的话 ，则还需要有一个供研发自测的测试分支吗？因为如果在开发分支上测试的话，代码频繁提交会影响测试的有效性。盼复。

    作者回复: 如果能够减少一个分支当然最好。开发自测最好能首先在自己的环境上测。不行的话定时在master上部署到一个环境让开发自测。 可以参考一下第六篇文章。 不知道我解释得清不清楚 ：）