书名：持续测试
ISBN：978-7-115-59346-7
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
编 著 陈 磊
责任编辑 谢晓芳
人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
读者服务热线：(010)81055410
反盗版热线：(010)81055315
本书旨在讲述如何通过持续测试交付一个功能完善、质量完美的系统，满足测试人员快速交付、快速迭代的需求。本书首先概述了什么是持续测试，以及持续测试和自动化测试的异同，介绍了如何提升持续测试的效率和效果，然后讨论了如何通过持续测试中的非功能性测试保障软件的可靠性、可用性、可移植性、性能效率等质量特性，如何通过建立质量门禁保障所交付系统的质量，并通过自动化提升质量效能，最后介绍了持续测试技术的发展，讨论了如何通过有效的度量促进质量的成熟，以及持续测试下测试工程师的自我修养。
本书适合测试人员阅读。
陈磊，阿里云MVP（Most Valuable Professional，最有价值专家），华为云MVP（最有价值专家），中国商业联合会互联网应用工作委员会智库专家，中关村智联软件服务业质量创新联盟软件测试标准化技术委员会委员，Asian Journal of Physical Education & Computer Science in Sports编委会委员。编写过《接口测试方法论》，参与编写过《京东质量团队转型实践：从测试到测试开发的蜕变》《决战618：探秘京东技术取胜之道》，在极客时间开设过“接口测试入门课”，在拉勾教育开设过“软件测试第一课”，担任过《测试敏捷化白皮书》和2021年的《研发效能实践指南》副主编。具有多年质量工程技术实践经验，精通研发效能提升、手工测试团队自动化测试转型实践、智能化测试等，公开发表学术论文近30篇，拥有20余项专利，并且是国内TiD质量竞争力大会、NCTS、MAD、MPD、TICA、DevOpsDays等技术峰会的演讲嘉宾或技术委员会成员。
随着业务复杂度的提升，为了使业务系统在多种操作系统、应用客户端友好适配，大量企业采用DevOps敏捷开发，通过自动化流程，使软件构建、测试与交付更加快捷和可靠。持续测试是 DevOps 开发流程的重要组成部分。在整个项目交付中，不仅执行自动化测试，还需要持续地对业务和技术风险进行评估、分析，以保障业务连续、稳定运行。通过阅读本书，我们可以掌握持续测试的实施步骤，建立持续测试体系，结合自身测试修养，形成自己团队的测试文化。本书还提供了丰富的示例，理论联系实践，有助于读者真正掌握持续测试的要点。
——白连东，PerfMa公司技术VP，IT东方会联合发起人
当前软件已经渗透到各行各业，为越来越多的工作场景带来效率的提升，软件的复杂度不断提升，对质量保障的要求越来越高，测试是质量保障和改善的重要反馈回路，通过快速、持续、有效的测试反馈，我们能以更低的成本提升软件质量。对于持续集成与持续发布，要配合持续测试才能完成软件研发活动的闭环，才能有效地保证软件价值的顺利交付。本书深入浅出地介绍了测试活动各个方面的道、法、术、器，特别提出通过测试左移与测试右移实现全环节的质量内建。本书能为关注软件质量的读者带来启发。
——冯斌，ONES公司联合创始人兼CTO
最近这几年DevOps越来越流行，相关的图书比较多，但对持续测试的关注相对较少。在现在变幻莫测的时代，只有持续、快速地交付有价值且有质量的产品或者服务，才能应对剧烈的变化和竞争。要实现这一点，持续测试是至关重要的一环。本书系统阐述了持续测试的重要性、方法和流程，是软件研发团队实践持续测试的参考指南，推荐每一位测试管理人员或者项目管理人员阅读。
——王春生，禅道项目管理软件创始人
作者在测试领域耕耘十几年，特别是在自动化测试和接口测试方面的功底在本书中得到了充分体现，而且本书涉及目前主流的测试技术，从全链路压测、流量录制技术、精准测试、智能化测试到测试平台化、混沌工程等。本书对测试工程师的工作和自我提升都有良好的参考价值。
——朱少民，QECon大会发起人，《全程软件测试》
《敏捷测试：以持续测试促进持续交付》的作者
近十年在业界流行的“极限编程”的原理是，如果某项活动对软件的最终质量有好处，那么我们就把它推行到极致，例如，既然代码审查有好处，那么我们为何不把它推行到极致，让代码审查在编码的时候就发生呢？这就是“结对编程”的由来。如果测试是保证软件质量的重要手段，那么我们为何不把测试推行到极致，做到“持续测试”？为什么不在软件生命周期的每一步都主动用测试来保证质量？在测试技术和质量保障方面，陈磊实践了十几年，非常高兴看到陈磊在这个领域的深入思考和经验总结。持续测试能帮助我们在早期就发现问题，解决问题，大幅度降低交流成本和软件修复成本，提高软件开发和维护的效率。每个产品经理和研发人员都会从本书中获得短期与长期的收益。强烈推荐本书！
——邹欣，CSDN副总裁
本书是一个很好和大胆的尝试，作者将软件测试和软件质量保障理论与自己丰富的实践经验相结合，并尝试以国际标准和国家标准、行业规范等作为质量保障的基础，精心编写了本书。作者以软件测试人员的身份讲述了很多新概念和新方法，让读者不仅能从本书中系统化地了解软件测试的理念、理论、技术和方法，还能从本书中获得宝贵的实践经验，从而更好地规避风险，更好地完成质量保障工作。本书适合作为软件测试从业者的学习资料和参考书。
——周震漪，ISTQB中国分会（CSTQB） 副理事长，TMMi基金会中国分会副理事长
信息技术的快速发展和数字化转型的不断深入大幅推动了软件产品的发展，软件研发的迭代速度越来越快，用户对软件质量的要求越来越高，传统的软件测试流程与方法已无法适应目前的研发模式。
我们需要从研发的底层逻辑的视角去发现问题，然后用问题驱动的方式将测试模式从传统低效的形态逐渐演变为符合时代要求的高效模式。高效的测试模式之间会有竞争，比如，出现高效测试模式的各种不同实践形态。然而，高效的测试模式和低效的测试模式之间不会有竞争，只会有“逐步取代”。
多行业专家认为，软件研发效能的提升需要保持5个持续，它们分别是持续开发、持续集成、持续测试、持续交付和持续运维。所以，掌握持续测试的知识体系并能够在实践中灵活应用俨然已成为现在软件测试从业者的“硬实力”。
当软件处于单体架构中时，一个理解需求并且掌握黑盒业务测试的人就很专业；在前后端分离的分布式架构时代，一个掌握接口测试的人就能比别人更快地解决问题。而在微服务架构大行其道且系统复杂性不断提升的今天，全面理解和掌握持续测试的人才有机会获得最终的成功。
国内外优秀公司的先进测试实践已经告诉我们，我们迫切需要将原本处于软件研发生命周期后期的测试活动提前，将其贯穿于整个软件研发的全生命周期，而不再是后期通过系统测试来发现问题，这是实现软件质量内建的最佳途径。
落到具体实践中，我们需要以持续测试为主线，将各个研发环节的各种测试能力和流水线相结合，并且通过设立质量门禁达到系统化运作。如果你对这部分内容感兴趣，并且希望更深入了解业界的探索和最佳实践，那么本书将会是你的案头书。
全书以持续测试为主线，不仅系统性探讨了各类自动化测试在持续测试过程中的作用，详细介绍了各类非功能性测试和混沌工程，还讲述了持续测试中的很多前沿实践，如流量录制回放、测试代码生成、精准测试和智能化测试。另外，本书还对质量运营和测试工程师的自我修养展开了讨论。本书系统展示了持续测试的知识全景图，能够让广大读者受益匪浅。强烈推荐本书。
茹炳晟
腾讯微信支付技术主管
腾讯研究院特约研究员
中国计算机学会TF 研发效能 SIG主席
一口气读完书稿，我的第一感受就是，本书出得太晚了，如果早读到本书，或许在对测试的理解上，我可以少走很多弯路。
今天的软件越来越复杂，规模越来越庞大，对测试的要求也越来越高，持续测试已经成为保证软件质量的必然选择。测试技术最近几年发展得很快，各种新的理念、新的工具层出不穷，你一定听说过测试左移、测试右移、精准测试和全链路压测等新词汇，测试开发成为测试工程师进阶的必选技术，测试从业者的职业焦虑与日俱增，他们经常对如何提升自己在测试上的认知不知所措。
本书作者拥有丰富的一线经验和广阔的视野，从一个整体的视角系统讲述测试的工作内容，深入讨论各个层面的测试工作与测试用到的各种技术。作者用平实的文字讲述新技术，并结合实战案例和代码，讲述新技术的应用。
大多数关于测试的书注重介绍具体技术，而很少讨论如何建立测试的整体认知，本书介绍了这方面的知识。
从测试左移、测试、测试右移的关系，到持续测试中自动化测试的各个层面，再到非功能测试的各项专项测试，最后延伸到测试的度量和质量门禁，本书既有对理论知识的解析，又有各种技术的介绍，还有落到组织层面的具体实践，几乎可以作为测试管理的手册。
本书应该成为每个测试总监以及立志成为测试总监的读者的案头书。我计划给云测公司每个测试人员买一本，作为他们职业进阶的助推器。
徐琨
北京云测总裁
我们正身处数字化转型的关键节点上，数字化对每一个行业产生着深刻的影响。在这个时代，每家公司的发展都离不开软件研发和信息技术，而通过什么样的方法、技术和实践，才能更快、更高质量、更可靠、可持续地交付更优的业务价值，是每家公司都要面对的课题。
如今，敏捷方法已经发展了二十多年，DevOps的应用也持续了十多年，相关的理念和方法已经深入人心，在业界越来越多的公司和行业实践者采用这些相对“新”的方法来改善研发流程，优化工程能力，提升技术能力，这在一定程度上也推动了研发效能的提升。
但是，在研发的整个过程中，质量一直是一个绕不过的话题。我们经常听到有人说“天下武功，唯快不破”，追求持续的、快速的研发以实现需求，让产品从想法到实现，直至交付给客户的速度足够快，面向市场的时间足够短，对于提升和维持企业的竞争力至关重要。但是，我们交付的产品都是有一定质量要求的，快速交付给客户质量有瑕疵的产品不但不会产生任何价值，而且会引起投诉和客户流失。所以，我们在当前的环境下，既要关注效率，也要重视质量，既要“快”，也要“好”。
在关于效率与质量的阐述中，曾经有一个演讲让我印象深刻。作为DevOps运动和社区活动在国内的主要推动者之一，我与朋友们每年都会筹办并组织几次DevOpsDays大会，有机会目睹一些行业前沿的技术分享。记得，2018年，我们邀请到了一位精通精益方法的国际嘉宾，他在大会上分享时提到：The “Speed” is the “Quality”，The biggest “Muda” is “Re-Do”。 “Muda”是一个源自精益生产的日文术语，表示“浪费”的意思。也就是说，研发过程中最大的浪费就是返工，就是在研发的上游没有把控好质量，而缺陷和瑕疵被传递到研发的下游，从而产生浪费。所以，我们要从提升质量方面提高效率，质量和效率是有机的整体，不是相互对立的，而是相互依存、彼此促进的。
那么，我们如何保持研发效率和产品质量的平衡并使二者相互促进？答案之一就是在研发中引入持续测试。本书给出了持续测试的明确定义：持续测试是在软件交付生命周期过程中，以防控业务风险为目的，将每一个业务交付阶段都辅以测试活动进行质量保障，并尽最大可能自动化，通过测试结果不断地反馈给制品交付过程的测试实践活动。所以，我们不仅要应用一系列方法、技术和实践把传统意义上的测试工作做好，还要推进测试左移和测试右移。通过测试左移，持续不断地进行测试，提前发现产品缺陷，降低缺陷发现、排查和修复成本；通过测试右移，在产品发布上线或者交付客户后仍然持续进行一些与质量相关的活动，从而保障业务连续性，提升交付后的质量。
本书的作者是测试领域的专家，曾经供职于进行大规模软件研发的企业，不仅精通测试各个领域的方法、技术、实践，还对在当前环境下如何实现持续测试有着深刻的理解。本书的内容全面详细，从测试理念和方法，讲到自动化测试、非功能测试等测试技术；从DevOps持续交付流水线及其质量门禁，讲到契约测试、流量录制、精准测试、智能测试等最新实践；还包括对质量度量、测试工程师自我提升等内容的精彩阐述。本书的出版可谓恰逢其时，很好地结合了时代发展的特点和研发人员的诉求，本书对想在测试领域持续提升技能或者对该领域感兴趣的读者有很大帮助。
张乐
腾讯技术工程事业群 DevOps与研发效能资深技术专家
我从事软件测试领域的工作已经有十多年了。2009年硕士毕业后，我就入职了一家第三方评测机构并成为一名软件测试工程师，在这家公司里所有的工程师都是测试工程师，所以我刚刚入行时，就接触了各种各样的软件测试工程师，如功能测试工程师、性能测试工程师、安全测试工程师等，这些不同的软件测试工程师做着不同方向的工作。
起初，我认为不同岗位名称的软件测试工程师的工作内容不同，但随着工作经验的积累和专业方向的不断深入，我逐渐发现不同岗位的软件测试工程师有一致的测试理论依据，它们是基于同一理论的细分。于是，我开始从更底层的视角来审视测试工作的内容。对于很多刚入行的软件测试工程师来说，构建一套完整的测试知识体系对完成基础任务的影响并不明显，但是随着职业发展，缺失测试知识体系会让你事倍功半，甚至举步维艰。
和所有人一样，在职业发展初期，我也是一名功能测试工程师。而对于初入测试行业的我来说，最初的印象是“测试工作=文档工作”。
刚参加工作时，我绝大部分时间在编写文档，如测试需求、测试计划、测试方案、测试报告等过程文档。同时，对于每一个测试过程，团队都会召开一次评审会，因此我还要为每一个过程文档都配上评审会纪要。于是，我每天都被各种格式的文档支配着。
那时我当然也有一些困惑，不太能理解我的工作内容究竟有何价值。另外，我也接触了性能测试工程师的工作，每天看着他们调试脚本、设计测试场景、执行负载测试、预测可能发生的问题，以及和研发人员一起调整参数或者代码等，而在我心中这才是高级测试工程师该做的工作。
随着测试工作的不断深入，我逐渐能为软件质量的标准和实际工作内容建立起映射关系。当时使用的标准还是GB/T 16260，标准中提出了六大质量特性，即功能性、效率、可靠性、易用性、可维护性和可移植性。随着从质量的角度来考虑问题，我重新审视了当时在公司的各种测试工程师，这才发现原来每一个细分的测试工程师岗位对应的都是一部分国标的检查项，缺一不可，因此我修正了“性能测试才是高级测试工程师的工作”这种错误的认知。
后来，GB/T 25000将质量特性升级为八大质量特性，增加了信息安全性和兼容性两个特性，这也是依据软件发展趋势及质量保障的重点而做的变更。进一步理解测试标准之后，我逐渐对测试工作有了很多新的认识，并在此基础上将很多理论在实践中落地。随着时间的流逝，我掌握的测试知识形成了体系。
而对于测试工程师，很多人存在错误认知。由于对测试知识缺乏了解，很多人认为测试就是“点工”，是一个凭借耐心就可以完全胜任的工作岗位，这就完全低估了测试工程师的工作难度，这也是为什么很多测试工程师在入行3年以后，就迅速到达了职业瓶颈，最终要么转行，要么业绩平平。
在入职京东后，作为一名测试架构师，我的主要工作就是通过技术手段提升质量效能，解决快速交付和手动测试之间的矛盾。在这段时间，我带领团队成员开发了一套自动化测试框架，这套框架可以完成测试代码生成、测试数据推荐、测试执行、测试结果收集等工作，但这些归根到底都是测试体系的机器实现，并没有逃脱测试体系的范围。
随着DevOps的出现，软件测试的滞后性和低效能大大制约了研发效能的提升。这也促使软件测试发生了改变。为了让测试能够满足持续交付的效率和质量的要求，持续测试就此诞生。持续测试通过测试左移、测试、测试右移，覆盖了整个软件开发周期，同时通过质量度量和质量运营促进质量改进，从而实现良性循环。
本书并不是一本纯理论著作，而是一本实践指导用书。本书从持续测试的本质开始讨论，尽可能以通俗易懂的语言讲述什么是持续测试，以及如何将持续测试应用到工作中。本书既包含了测试左移、测试、测试右移的方法论，也包含了质量门禁、静态测试、动态测试等实践方案。同时，本书还介绍了接口自动化、验收自动化等常规自动化测试手段在持续测试中的应用，并从质量度量、质量运营两大方面讲解了持续测试如何促进持续改进。本书还讲述一些测试技术的本质、测试平台化的发展趋势，以及智能化测试框架的使用，从而为持续测试奠定了技术基础。
如果你对软件质量和测试感兴趣，相信本书对你有所帮助。
陈磊
本书由异步社区出品，社区（https://www.epubit.com）为您提供后续服务。
作者和编辑尽最大努力来确保书中内容的准确性，但难免会存在疏漏。欢迎您将发现的问题反馈给我们，帮助我们提升图书的质量。
当您发现错误时，请登录异步社区，按书名搜索，进入本书页面，单击“提交勘误”，输入错误信息，单击“提交”按钮即可，如下图所示。本书的作者和编辑会对您提交的错误信息进行审核，确认并接受后，您将获赠异步社区的100积分。积分可用于在异步社区兑换优惠券、样书或奖品。
我们的联系邮箱是contact@epubit.com.cn。
如果您对本书有任何疑问或建议，请您发邮件给我们，并请在邮件标题中注明本书书名，以便我们更高效地做出反馈。
如果您有兴趣出版图书、录制教学视频，或者参与图书翻译、技术审校等工作，可以发邮件给我们；有意出版图书的作者也可以到异步社区投稿（直接访问www.epubit.com/contribute即可）。
如果您所在的学校、培训机构或企业想批量购买本书或异步社区出版的其他图书，也可以发邮件给我们。
如果您在网上发现有针对异步社区出品图书的各种形式的盗版行为，包括对图书全部或部分内容的非授权传播，请您将怀疑有侵权行为的链接通过邮件发送给我们。您的这一举动是对作者权益的保护，也是我们持续为您提供有价值的内容的动力之源。
“异步社区”是人民邮电出版社旗下IT专业图书社区，致力于出版精品IT图书和相关学习产品，为作译者提供优质出版服务。异步社区创办于2015年8月，提供大量精品IT图书和电子书，以及高品质技术文章和视频课程。更多详情请访问异步社区官网https://www.epubit.com。
“异步图书”是由异步社区编辑团队策划出版的精品IT专业图书的品牌，依托于人民邮电出版社的计算机图书出版积累和专业编辑团队，相关图书在封面上印有异步图书的LOGO。异步图书的出版领域包括软件开发、大数据、人工智能、测试、前端、网络技术等。
异步社区
微信服务号
软件测试伴随着软件工程实践的进步也在不断地进步，它从最原始的开发调试中分离出来后，在瀑布模式的软件工程实践中摸索了很长时间，目前软件测试已经贯穿软件交付生命周期的全流程。这种在软件交付生命周期的每个阶段都存在测试活动的实践就是持续测试。
持续测试并不是什么全新的测试技术、测试方法，而是一种测试实践方法。Tricentis公司的CMO（Chief Marketing Officer，首席营销官）Wayne Ariola在公司博客中题为“Continuous Testing: ‘Perfect’ Software Is not the Goal”的文章中给出了持续测试的定义：
持续测试侧重于业务风险并提供有关软件是否可以发布的决策基础。自动化测试对于连续测试至关重要，但它并非全部。自动化测试旨在生成一组与用户故事或应用需求相关的通过/失败数据检查点，而持续测试侧重于业务风险并提供有关软件是否可以发布的决策基础。除将测试用例自动化之外，持续测试还包括业务风险验证、应用服务虚拟化和状态化测试数据管理等以稳定持续测试；在每次迭代中使用探索性测试尽早发现阻碍性问题等实践。这不仅意味着使用更多的不同的工具，还要求包括技术在内的人和流程的深度转变。
Thomas Hamilton在“Continuous Testing in DevOps: What is, Definition, Benefit, Tools”文章中也给出了持续测试的定义：
持续测试是DevOps中的一种软件测试类型，它主要约束在软件开发生命周期中任何阶段都有对应的测试活动，从而尽早进行频繁的测试，这也就做到了在持续交付过程中每一步都有了质量评价活动从而实现了持续测试。
除这两种解释以外，还有很多其他解释，但是都没有说清楚持续测试是什么。
持续测试其实就是一种新的测试实践，指在软件交付生命周期中，以防控业务风险为目的，对每一个业务交付阶段都辅以测试活动进行质量保障，并尽最大可能自动化，通过测试结果不断反馈给制品交付过程的测试实践活动。
随着当今软件行业的发展，信息技术的快速进步，以及人们对软件系统的理解，一次性交付一个功能完善、质量完美的系统已经不再是首要任务。快速交付一个满足用户最需要的功能的系统，后续通过快速迭代逐渐完善成为当前的主流。在这种快速交付、快速迭代的要求之下，每次交付系统时，所有的领导都会问测试工程师同一个问题：“测试完了吗？”此时，如果测试工程师还抱着原来做测试的思想，就很难在短时间内回答领导的问题，而持续测试能够解决这种问题。
持续测试就是从产品发布计划开始，直到交付、运维，测试融于其中并贯穿整个开发过程，随时暴露出产品的质量风险，随时了解产品质量状态，从而满足持续交付对测试、质量管理所提出的新要求。
为了能够帮助团队构建更高质量的软件系统，测试工程师必须在整个交付过程中不断地运行测试（这里的测试既包含自动化测试，也包含手工测试），以验证开发中的系统的功能和架构。为了达到这个目标，测试人员需要从组织上和技术上共同推进。
在组织上，要允许测试工程师在整个软件交付过程与开发工程师、产品经理乃至运维工程师相互协作，从而建立制品团队共同交付高质量系统的文化。同时，在整个测试过程中，要充分发挥测试工程师的能力，广泛实现和推广探索测试。
在技术方面，最好维护一套行之有效的分层自动化测试解决方案。这里面既包含单元测试、接口自动化测试，也包含UI自动化测试，这样才能将质量保障工作和持续交付流水线集成到一起，通过流水线触发自动部署、自动测试，然后交付给测试工程师，完成人工主导的探索测试和可用性测试。
最后，如果在测试工程师工作步骤中未发现任何错误，则应用可以发布。通过流水线大大减少了从代码合并到发布整个过程的工作量，降低了生产环境中的错误率，开发者的绝大部分代码可以在很短的时间内完成验证，因此他们也可以快速完成修复，这就是持续测试的优越性。这也说明持续测试并非创新，而是另外一种实现方式，因此软件测试行业中已有的理论、方法在持续测试中仍然适用。
测试的生命周期是测试过程的总称，从有质量保障活动的投入开始，到系统交付提供测试结论为止，其间全部关于质量保障的活动都属于测试生命周期的范围。测试的生命周期如图1-1所示。
图1-1 测试的生命周期
在需求分析环节，测试工程师的工作重点是参与需求的评审，评审的具体形式由项目组内部自行决定，评审过程中测试工程师会站在质量保障的角度给予一些意见和建议。
测试计划环节的工作重点是估算各种投入，其中最重要的一个活动就是排期。排期指在综合测试工具约束、被测试业务约束的前提下测试工作量的估算，并在上述约束下给出关键里程碑节点。这个环节的重点是工作量估算。
目前应用较广泛的工作量估算方法有以下3种。
● 专家经验法：依赖测试专家的工作经验对项目工作量进行评估的一种方法。这是一种定性分析方法，容易实施、便于落地。但是其缺点很明显，最致命的缺点是不可复制，完全依赖专家，并且受专家个体约束，不同专家对相同项目的评估有可能相差很远，而且估算评估过程完全是一个黑盒，估算结果经不起推敲，缺乏科学客观性。为了规避专家经验法的问题，一般会建立一个专家组来完成工作量评估，从而将上述问题弱化，但是上述问题难以完全避免。
● 类比法：依据已完成项目中与本次迭代的需求类似的项目的实际工作量进行评估的一种方法。这里的重点是具备可借鉴的项目。如果没有类似的项目，那么就无法使用该方法进行工作量评估。
● 类推法：这种方法可以看作类比法的一种进阶方法，使用类推法的时候，将需要估算工作量的项目与类似项目或者类似的功能模块的工作量进行对比，然后再结合一些外部依赖条件对工作量进行适当的增加或者减少。
测试环境设置是约束测试工作能够正常进行的一个重要的环节，包含了支持被测系统运行的软硬件环节以及自动化测试所需的软硬件环境。在该阶段，测试工程师的主要工作就是建立测试环境，部署被测试系统，部署自动化测试环境，搭建性能测试环境等。除此之外，测试环境设置还包含被测系统及测试过程都需要的一些数据支持的设置。
测试执行指测试工程师根据测试用例在测试环境中完成测试工作的过程，该环节包含手工业务测试、自动化测试、性能测试、稳定性测试、安全测试等所有测试工作，并不断地将问题反馈给开发工程师修复并完成回归验证活动。
测试周期结束后，在项目组内复盘测试报告、缺陷报告，重点讨论发现的问题，从而确定未来处理类似问题的最佳方案。该阶段的工作重点是输出详细的测试报告。
测试用例设计方法是软件测试方法中的核心内容之一。很多人会觉得说到测试用例设计方法就是老生常谈，但是一说到测试用例具体是什么又解释不清楚。
IEEE Standard 610 (1990)给出了测试用例的定义：“测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。”
测试用例是执行的最小实体。简单地说，测试用例就是一个检验软件程序在某种场景下能够正常运行并且达到程序所设计的执行结果的场景设计。这就说明，如果测试工程师设计的测试用例能够验证全部的软件设计场景，那么测试活动就结束了。但是在实际测试过程中，无法穷尽所有验证场景，因此测试人员就需要从庞大的测试场景中选择有代表性的、数据特殊的测试用例来完成测试工作。测试用例应该满足的特性如图1-2所示。
图1-2 测试用例应该满足的特性
那么到底应该如何设计满足上述要求的测试用例呢？答案是使用科学的测试用例设计方法。测试用例设计方法如图1-3所示。
图1-3 测试用例设计方法
黑盒测试用例设计方法有很多，这里重点介绍使用频度较高的3个方法——等价类划分法、边界值分析法和场景法。其他方法如果读者有兴趣，可以自行查阅相关资料进行学习。
等价类划分法的重点是把程序的输入划分成若干类，然后从每一类中选取少数具有代表性的输入数据作为测试用例，这样某一类中的少数代表性数据就等价于该类中的其他数据。该方法基于某一类中的少数代表性输入数据，如果出了问题，那么该类中所有的数据都会出现问题；反之，亦然。
假设三角形的3条边分别为a、b、c，则必须满足
a > 0，b > 0，c > 0，且a+ b > c，b + c > a，a+ c > b
如果三角形是等腰三角形，还须满足a= b或b = c或a= c。
如果三角形是等边三角形，则须满足a= b = c。
使用等价类划分法设计测试用例的第一步就是识别有效等价类和无效等价类，然后输入等价类表中。等价类表如表1-1所示。
表1-1 等价类表
| 输入条件 |
有效等价类 |
无效等价类 |
|---|---|---|
| 是否为三角形的3条边 |
（a > 0） （1） |
（a≤0） （7） |
| 是否为等腰三角形 |
（a= b） （13） |
（a≠b）and（b≠c）and（c≠a） （16） |
| 是否为等边三角形 |
（a= c）and（b = c）and（c =a） （17） |
（a≠b） （18） |
依据等价类表设计测试用例，输入是a，b，c，如表1-2所示。
表1-2 测试用例表
| 序号 |
输入a，b，c |
覆盖等价类 |
输出 |
| 1 |
6，7，8 |
（1），（2），（3），（4），（5），（6） |
一般三角形 |
| 2 |
0，4，5 |
（7） |
不能构成三角形 |
| 3 |
4，0，5 |
（8） |
|
| 4 |
4，5，0 |
（9） |
|
| 5 |
1，4，6 |
（10） |
|
| 6 |
1，6，4 |
（11） |
|
| 7 |
6，1，4 |
（12） |
|
| 8 |
4，4，6 |
（1），（2），（3），（4），（5），（6），（13） |
等腰三角形 |
| 9 |
6，4，4 |
（1），（2），（3），（4），（5），（6），（14） |
|
| 10 |
4，6，4 |
（1），（2），（3），（4），（5），（6），（15） |
|
| 11 |
3，4，5 |
（1），（2），（3），（4），（5），（6），（16） |
非等腰三角形 |
| 12 |
3，3，3 |
（1），（2），（3），（4），（5），（6），（17） |
等边三角形 |
| 13 |
3，4，4 |
（1），（2），（3），（4），（5），（6），（14），（18） |
非等边三角形 |
| 14 |
3，4，3 |
（1），（2），（3），（4），（5），（6），（15），（19） |
|
| 15 |
3，3，4 |
（1），（2），（3），（4），（5），（6），（13），（20） |
表1-2中的输入就是测试用例，输出就是预期结果。可以看出，两位测试工程师使用等价类划分法设计的测试用例可能不一样，但覆盖的等价类是一样的。
边界值分析法的重点是找到刚好满足和刚好不满足输入条件边界的输入数据并使用它们设计测试用例。这是目前应用很广泛的测试用例设计方法。边界值分析法如图1-4所示。
图1-4 边界值分析法
边界值分析法主要包含边界条件和次要边界条件。边界条件主要从以下两个方面考虑。
● 需求约束边界。例如，如果用户名在需求中的约束条件是“字母、数字，并且以字母开头，长度为5”，那么测试用例包含criss、cris、12345、1cris、c123s、+riss、crisss。
● 功能依从性边界。如果测试的是一个计算器程序，那么该程序就应该和物理计算器一样，不可以在其中输入汉字、非数学运算符号的符号等。
上述边界条件主要的判定依据就是需求或者系统使用过程中的一些特性。虽然用户在使用过程中很难触碰到一些次要边界条件，但是仍有必要测试它们，如变量取值范围、ASCII值的范围、数组越界与“空”值的表示等。
充分发挥这种基础测试用例设计方法的作用的方式是混合使用边界值分析法和等价类划分法。
当今人们所面对的被测系统都是通过数字化事件的不同触发顺序实现场景数字化的。Rational公司基于该思想提出了场景法这种测试用例设计方法。场景法中的主要工作是设计基本流和备选流。其中，基本流是主流程，备选流是程序设计的各种分支流程。基于基本流和备选流的全覆盖建立符合业务逻辑的场景，然后设计参数并实现对应的场景，完成测试用例设计。
按照软件正确的事件流，设计的测试流程就是基本流。
在基本流之上，在程序设计的各种分支流程中，重点关注业务异常的测试流程就是备选流。
假设基本流和备选流如图1-5所示，其中黑色表示基本流，其他颜色的箭头表示备选流。备选流从基本流开始，在不同的条件下进入不同的流程，在完成备选流后可能结束基本流，也可能直接结束用例。
图1-5 基本流和备选流
每一个开始用例阶段都从基本流开始，经由不同流程形成不同的测试场景。具体场景设计如表1-3所示。这里为了讲解清楚，只简单给出了场景法的使用示例，实际项目中的场景设计会比给出的示例复杂。
表1-3 场景设计
| 场景编号 |
场景设计 |
|---|---|
| 场景1 |
基本流 |
| 场景2 |
基本流 备选流1 |
| 场景3 |
基本流 备选流1备选流2 |
| 场景4 |
基本流 备选流3 |
| 场景5 |
基本流 备选流3 备选流1 |
| 场景6 |
基本流 备选流3 备选流1 备选流2 |
| 场景7 |
基本流 备选流4 |
| 场景8 |
基本流 备选流3 备选流4 |
下面以在异步社区购买图书为例进行介绍。用户只需要访问异步社区首页，输入用户名和密码，然后在搜索框中输入要购买的图书名称，单击搜索到的图书图标，进入图书详情节，单击“立即购买”按钮，结账付款，即可购买成功。这个流程是实际购买流程，其基本流和备选流呢？
基本流是访问异步社区首页，输入用户名和密码，在搜索框中输入要购买的图书名称，单击搜索到的图书图标，进入图书详情页，单击“立即购买”按钮，结账付款。
备选流如下。
● 备选流1：账户问题。
● 备选流2：密码问题。
● 备选流3：图书库存为零。
● 备选流4：图书不存在。 - 按照场景法设计测试用例，如表1-4所示。
表1-4 购书流程测试用例场景设计
| 场景编号 |
场景设计 |
|---|---|
| 场景1 |
基本流 |
| 场景2 |
基本流 备选流1 |
| 场景3 |
基本流 备选流2 |
| 场景4 |
基本流 备选流3 |
| 场景5 |
基本流 备选流4 |
以上设计的5个场景中每一个场景都需要对应的测试用例，一般采用矩阵或决策表来确定和管理测试用例。首先确定执行用例场景所需的数据元素，然后构建矩阵，最后确定包含执行场景所需的适当条件的测试用例。在下面的矩阵中，V表示这个条件必须是有效的才可执行基本流，I表示这种条件下将激活所需备选流，n/a表示这个条件不适用于测试用例。
表1-5展示了利用场景法设计的购书流程测试用例。
表1-5 利用场景法设计的购书流程测试用例
| 测试用例编号 |
场景编号 |
账号 |
密码 |
图书 |
预期结果 |
|---|---|---|---|---|---|
| TC1 |
场景1：购买成功 |
V |
V |
V |
购买成功 |
| TC2 |
场景2：账号不存在 |
I |
n/a |
n/a |
账号不存在 |
| TC3 |
场景3：密码错误 |
V |
I |
n/a |
密码错误 |
| TC4 |
场景4：购买的图书无货 |
V |
V |
I |
图书无货 |
| TC5 |
场景5：没有搜索到要购买的图书 |
V |
V |
I |
图书不存在 |
在上面的矩阵中，5个测试用例对应5个场景。对于基本流和备选流，都有测试用例。测试用例如表1-6所示。
表1-6 测试用例
| 测试用例编号 |
测试用例 |
预期结果 |
|---|---|---|
| TC1 |
（1）访问异步社区首页 |
购买成功 |
| TC2 |
（1）访问异步社区首页 |
账号不存在 |
| TC3 |
（1）访问异步社区首页 |
密码错误 |
| TC4 |
（1）访问异步社区首页 |
图书无货 |
| TC5 |
（1）访问异步社区首页 |
图书不存在 |
在应用场景法时，要时刻记得基本流不一定就只有一条，而备选流也不一定就有多条，具体依据被测业务及被测系统而定。场景法特尤其适用于工作中的定时任务类的流程测试。
关于其他黑盒测试用例设计方法，建议读者查阅相应资料，在将不同方法应用到工作中的同时不断体会它们各自的优越性，以及适用的场景。
下面将介绍白盒测试用例设计方法。既然是白盒，那么肯定站在代码的角度设计测试用例。根据测试方法，测试分为静态检查和动态测试。目前广泛使用的一种静态检查方法就是CodeReview，所以这方面并不涉及测试用例的设计。动态测试主要站在逻辑覆盖的角度设计测试用例，以满足覆盖率的要求。动态测试主要遵循以下原则。
● 保证一个模块中的所有预期路径至少使用一次。
● 对所有逻辑判定条件都测试真和假。
● 在上下边界及可操作范围内运行所有循环。
● 检查内部数据结构以确保其有效性。
为了满足上述原则，白盒测试用例设计方法也遵循科学的方法，具体如图 1-6所示。
图1-6 白盒测试用例设计方法
白盒测试用例设计的重点是满足覆盖率。其中，语句覆盖法重点关注是否覆盖了每一条程序语句；判定覆盖法重点关注每个逻辑判断分支是否都至少取了一次真值和一次假值；条件覆盖法重点关注每个判定语句是否都至少取了一次真值和一次假值；判定/条件覆盖法要求每个判断分支及每个判断语句都至少取了一次真值和一次假值；而条件组合覆盖法则要保障各种分支组合都至少出现一次。
从上述描述中就可以知道，白盒测试用例设计方法之间的关系如图1-7所示。
图1-7 白盒测试用例设计方法之间的关系
没有任何一款软件系统是完美无缺的，任何系统都有缺陷。但是每一次迭代都会有一个期望，测试工程师需要知道本次迭代的项目干系人的预期，通过项目干系人的预期管理测试的风险。Sue Bartlett在“How to Find the Level of Quality Your Sponsor Wants”一文中描述了如何实现上述目标和降低风险。
该文章指出，在开始详细的计划、设计或者编码前就明确质量目标，这样会更好地保证交付一个满足预期质量目标的交付物。Ross Collard指出，通过10%～15%的测试用例发现被测系统中75%～90%的缺陷。
这也符合二八原则，二八原则对软件测试的影响很深。在面对成百上千的测试用例时，测试工程师要挑选出一个最小的、最重要的、优先级最高的测试用例集并不容易，且往往没有头绪。对测试用例进行优先级定义并不容易，而且优先级定义在每一次迭代中或者迭代后都有可能修改，因此测试用例的优先级是动态的。具体测试用例的优先级划分如下所示。
测试用例的优先级如下。
● 构建验证测试（Build Verification Test，BVT，也称为P0）。BVT也称为冒烟测试用例集，是每次测试开始投入前最希望运行并得以确认的测试用例集。冒烟测试用例集的规则是如果一个测试用例无法正确执行，则其他测试用例同样无法正确执行。满足该规则的测试用例都应该纳入冒烟测试用例集。
● 高优先级（P1）。高优先级测试用例集是按照执行频度和业务功树的根部分支的条件选入的。高优先级测试用例是在BVT中加入的常用测试用例，用来验证重要或者主干流程的功能是否稳定、是否正确。测试用例既包含正确的数据流，也包含错误的数据流。
● 中优先级（P2）。中优先测试用例集是按照执行频度和业务功树的主要分支的条件选入的。中优先级测试用例更加详尽地验证新迭代影响域（新功能区域）或者功能。测试用例包含大多数的功能，其中不仅包含正确数据流和错误数据流，还应包含一些配置方面的测试。
● 低优先级（P3）。低优先测试用例集是按照执行频度和业务功树的根部分支的条件选入的。低优先级测试用例是最不频繁执行的测试用例。但是低并不是说不执行，不测试，只是在迭代的过程汇总，执行频率比较低，不常执行。这部分测试用例涉及错误消息、可用性、压力测试和性能测试等。
首先，进行粗略划分，任意标注。将验证全部功能的正确性的测试用例指定为高优先级的；将全部有错误或者有边界值验证的测试用例指定为中优先级的；将其他测试用例指定为低优先级的（这里面主要是非功能测试用例）。
其次，评审每一个测试用例，升级或者降级。通过对每一个测试用例及其优先级的重新评审，划分测试的重要性及执行频度等，按照下述原则进行降级处理。将功能验证测试分为两组（重要和非重要），将“不太重要”的功能验证测试降级为中优先级；将错误和边界测试分为两组（重要和非重要），将“重要”错误和边界测试提升到高优先级。将非功能性测试分为两组（重要和非重要），将“重要”非功能性测试提升到中优先级。对每组高、中和低优先级测试用例重复划分并升级/降级，直到在优先级之间移动的测试用例数量变为0为止。
最后，确定BVT。将高优先级测试分为两组，分别为致命和严重（如果出现缺陷就是致命缺陷，则这条测试用例也是致命的）。将致命的测试用例归并到BVT优先级。
优先级分布为BVT占 10%～15%，高优先级占 20%～30%，中优先级占40%～60%，低优先级占10%～15%，但是这并不是一个绝对要遵循的比例。测试用例的分级还要以实际项目的需求为准。
自从测试从开发工程师的调试工作中分离出来，测试用例的形式逐渐开始多样化。在传统的瀑布模式交付流程中，主要以操作步骤的形式描述测试用例。图1-8所示是一种典型的测试用例模板。
图1-8 测试用例模板
测试用例编号是唯一的，并且在全部的测试用例管理体系中也是唯一的，因此多个系统间的测试用例编号也不会重复，大部分情况下，通过在测试用例编号中加入系统缩写字段确保测试用例全局的唯一性。如果存在自动化测试脚本，那么该唯一标号也可作为自动化测试脚本的标号，这样就建立了测试用例和自动化测试脚本的映射关系，即映射矩阵。
组件/模块部分主要说明测试用例属于哪个组件或者模块，这样不仅可以粗略地给测试用例和系统实现建立一种映射关系，还可以建立一种基于系统组件/模块的测试用例分类方式。
级别即测试用例的分级。这里就涉及前面描述的测试用例分级的内容，一般包含P0级（构建验证测试）、P1级（高优先级）、P2级（中优先级）、P3级（低优先级）。
测试描述主要是测试流程的简单说明，主要作用是帮助测试工程师快速理解测试用例，而不需要阅读详细的测试步骤。
先决条件指开始执行测试步骤前必须要满足条件，否则后续测试步骤无法执行，也就无法开始测试。
测试步骤就是测试用例的具体操作步骤，每一步都要简单明了地说明具体操作和内容。
期望结果指前序测试步骤中每一步对应的系统反馈，而非全部业务执行完的最终结果。
实际结果指测试过程中实际的系统交互结果。这部分有两种描述，一种是将实际的内容记录下来，另一种是输入“与预期结果一致”，但是这里一条预期结果对应一个实际结果。
状态指执行测试用例后的结论，当实际结果和预期结果一致时，测试用例的状态为通过，否则为失败。
测试执行人指执行测试用例并记录实际结果、状态的测试工程师。
这是一种原始的测试用例模板，后续的很多测试管理系统借鉴了这种测试用例模板的原型，只是留存形式不再是电子表格，而是由管理系统员在关系数据库中维护。
在瀑布交付模式的团队中，这种记录详细的电子表格类的测试用例模式是有优越性的。传统质量保障团队是完全按照瀑布模式交付的，测试流程中的各个环节具备明显的交接界限，如图1-9所示。
图1-9 瀑布交付模式的团队合作方式
这种传统质量保障团队角色分工明确，角色间交集相对较少，项目交付以“面向测试的开发”为主，团队交付的最终质量全部依靠集成测试阶段测试工程师对系统的理解和了解程度。
因此，步骤详尽的测试用例有助于将测试过程解释清楚，这样在测试用例评审过程中，开发工程师站在已经实现的系统角度评价测试用例写得完不完善，产品经理站在系统设计的角度评价测试用例写得对不对，同时评审开发工程师实现的是否是需求文档中所描述的功能。
这种测试用例模式对于测试工程师也是有帮助的，其中既详细记录了系统的操作过程，也帮助测试工程师深入了解了实现的系统。同时，在生产出现问题时，我们可以通过测试用例是否覆盖、测试过程是否执行确定测试工程师在项目测试过程中是否有遗漏。
随着敏捷实践的不断完善，按照上述测试用例模板撰写测试用例逐渐不再适用于对应的敏捷交付团队。这是因为对于交付结果已经从对线上问题的团队追责转变成对制品交付团队问题的追责，所以并不需要某一个人或者某一个角色承担对应的责任，若团队交付的产品发生问题，这是交付团队整体的问题，并非某一个人的失误造成的。
因此，测试用例也逐渐地转变成这样一种业务梳理模式，测试工程师通过测试业务逻辑建模，整理测试业务，并在团队内部分享。目前，大部分团队以思维导图的形式完成业务逻辑的梳理工作。思维导图工具既有单机版本也有Web版本，目前开源的Web版本类似于测试用例工具，以滴滴的敏捷测试用例管理平台（AgileTC）为代表，具体可以参考对应项目在GitHub上的开源代码。
在实践测试左移时，提倡在需求进入迭代计划之前就讨论每一张需求卡片，参与每一个故事的讨论，完善每一个故事卡片的验收条件（Acceptance Criteria，又称为“验收准则”，简称AC）。在研发工程师开始满足需求之前和完成需求开发之后，测试工程师都在参与故事卡片的验收条件讨论。测试工程师开始测试之前需要根据一些常规的测试用例设计方法补充异常用例。
在整个过程中，团队都以交付高质量的项目为中心，而不再使用缺陷数、测试用例数、代码行数等不科学和不客观的考核指标。
软件测试的分类有很多种，它们分别站在不同的观察角度，但是无论哪一种都是针对测试工作内容进行划分的。
众所周知，软件测试和软件开发相辅相成，因此按照开发阶段划分相对来说应该最容易了。按照开发阶段，软件测试的划分如图1-10所示。
图1-10 按照开发阶段软件测试的划分
按照图1-10的划分方式，软件测试很容易就和软件交付的V字模型对应上。其实V字模型就是较早对测试进行细分的一种模型。
单元测试的被测对象是程序模块，这是软件设计中最小的模块。
集成测试的被测对象是将程序模块组合到一起且对外暴露的接口，这里重点验证集成到一起的程序模块是否满足概要设计的要求。
确认测试就要验证被测试软件是否满足软件需求规约中的要求，重点检查功能特性的符合程度。
系统测试是指在真实或者仿真环境中对被测系统进行验证。在这个阶段，除功能性之外，还包含性能效率等其他质量特性要求。在很多实际项目中，常常把确认测试和系统测试合二为一。
验收测试是指按照最初的约定，验证被测系统、软件需求规约、用户手册三方的一致性，以及非功能特性的符合性。
除按照开发阶段进行划分外，软件测试还可以按照测试实施组织来进行划分，如划分为α测试、β测试。按照测试实施组织，软件测试的划分如图1-11所示。
图1-11 按照测试实施组织软件测试的划分
这里说的α测试指由一名用户在非生产环境下进行的验收测试，这里强调开发人员或者测试人员陪同完成验收测试，实时记录暴露的缺陷。β测试指由少部分用户在真实环境中完成的验收测试，β测试与α测试有一个明显的区别，就是没有开发人员或者测试人员的陪同。α测试、β测试都隶属于验收测试。
如果站在测试工程师的角度按照测试技术划分软件测试，那么有两种划分方式。一种是按照测试过程中是否需要了解程序结构和处理过程来划分，另一种是从是否需要检查代码运行结果的角度来划分。按照测试技术，软件测试的划分如图1-12所示。
图1-12 按照测试技术软件测试的划分
按照测试过程中是否需要了解程序结构和处理过程，软件测试可以划分为白盒测试、黑盒测试及灰盒测试。
按照是否需要检查代码运行结果，软件测试可以划分为静态测试和动态测试。白盒测试既可以是静态测试也可以是动态测试，灰盒测试、黑盒测试只能是动态测试。
测试左移的概念最早由Arthur Hicken提出。Arthur Hicken提出，为了弥补瀑布模型的不足，以及避免测试工作成为系统交付前的最后且唯一的质量保障手段，测试应左移并贯穿于项目的整个研发生命周期。
这也说明测试工程师在项目的需求分析阶段就应该参加相关活动，从而在需求分析阶段就站在测试角度补充各种验收条件。从需求分析开始到测试业务分析，再到测试用例设计、测试执行及测试结论总结，都应由同一名测试工程师完成。在此过程中，这名测试工程师可以不断地理解需求并澄清需求。
测试工程师在需求分析阶段就参与相关活动，能够更早地帮助开发人员发现系统在设计之初就存在的业务逻辑缺陷、使用缺陷及交互缺陷，从而将一些缺陷在系统开发之前就排除，避免团队投入的浪费，提高团队的投入产出比和交付效率。
此外，当研发工程师开始开发系统时，测试工程师就可以同步完成测试用例的设计。在这里，并不像传统方式下那样按照系统的操作步骤设计测试用例，而是按照业务流程的梳理结果设计测试用例。这种更深入的参与和理解能促进测试工程师获得产品的完整知识，彻底理解各种应用场景，并根据软件行为设计实时场景。以上这些都能帮助制品团队在编码完成之前识别出一些缺陷。测试左移聚焦于使测试人员在最重要的项目阶段就参与进来，将关注点从发现缺陷转移到风险预防，从而避免一些技术风险和业务风险，同时驱动项目商业目标的实现。
当测试团队不断实践测试左移时，质量文化便会在整个团队中不断建立并传播，人们不会再将质量保障等同于在测试中发现缺陷，而是参与到项目的各个环节中以降低业务风险和技术风险，促进团队所有成员积极合作，在项目的初始阶段就为满足业务需求及避免业务风险开展工作。测试工程师在项目开始阶段就应为建立有效的测试策略不断努力，并在测试策略的指导下避免业务风险和技术风险，使整个团队聚焦于产品的长期价值和可靠性。
随着测试左移思想的发展，更提倡测试工程师在需求阶段就开始有质量保障的输出，因此开卡、验卡实践越来越受到各种DevOps实践团队的推崇。
当团队中开发工程师准备实现一张故事卡片时，他会按照故事卡片上的验收条件向测试工程师、产品经理详细讲解自己对故事的理解，以及如何实现。这时，如果产品经理发现故事卡片有遗漏的验收条件，就需要及时补充，测试工程师基于自己对需求的理解、对系统全局的认识及对上下游依赖的分析，补充验收条件中缺失的内容，这种快速的集合讨论就是开卡（Kick Off，KO）动作。
开发工程师完成开发后，同样需要将产品经理、测试工程师集合到一起，按照故事卡片上的验收条件和已经实现的系统完成验收，这里产品经理站在是否实现了对应故事的角度进行分析，测试工程师站在是否完善的角度进行分析，通过验收后进入测试环节，这个动作称作验卡（Desk Check，DC）。
在这个过程中，验收条件就是这条需求的测试用例，测试工程师只需要补充一些非功能测试用例就可以了。这种验收条件和开卡、验卡的实践保证了交付的流畅度，是目前测试左移一种有效的实践方式。
测试右移是相对于测试左移而言的，指制品发布到生产环境之后进行的一些测试活动。但是这里的测试活动并非通常说的测试活动，而是指通过环境监控、业务监控、APM等手段考量服务的可用性、稳定性等，以便在发现生产环境的问题时，尽快将问题暴露给制品交付团队并快速修复，给予用户良好的使用体验。
测试右移就是将测试移动到生产环境，这就决定了该部分的测试活动与通常说的测试活动有很多区别。在传统的测试角色分工中，生产环境的负责人是运维工程师，运维的核心工作理念是“稳”，这就和当前测试工程师要求的快速验证、快速修复有冲突。
测试右移不仅包括在生产环境中进行测试活动，还包括在生产环境中进行的部分测试实践。
测试右移不是和运维冲突，而是利用运维的一些技术平台给测试工程师一些判断的输入来源，然后结合测试中原有的一些技术沉淀，完成服务质量的保障工作，以便早发现、早预防。其具体方法如下。
● 利用运维技术平台。充分利用运维工程师提供的监控平台、日志平台等数据监控服务的状态，以便更早地发现生产环节中存在的问题，并将对应问题的一些留痕数据（日志信息、监控数据等）记录到缺陷系统中，从而辅助解决对应生产缺陷（如果造成损失也可能是故障）。
● 利用自动化测试。利用自动化测试手段为生产环节提供业务正确性的巡检功能，这样既可以在运维工程师保障服务的基础之上模拟自动化测试的业务逻辑，又能保障业务的稳定性。这是监控分层的一种思想实践。
除此之外，用户使用系统的行为有可能并不是按照该系统设计的预期方法进行的，因此需要在测试右移环节中，通过前端埋点等技术记录真实用户的使用方法、喜好等，从而在测试左移时反哺业务需求。这样，我们就可以在测试左移时关注测试右移中获得的很多有价值的需求信息，从而充分保障从业务到需求环节的质量。
当然，如果要完成这种实践，我们必须要实现真正的敏捷测试，而非披着敏捷外衣的伪敏捷实践。
虽然生产环境以稳定为前提，但是仍有一些测试技术和测试环境可以在该前提下实施。
● 全链路测试。全链路测试是通过流量录制、回放技术在生产环境中完成的测试技术。当然，生产环境下的全链路测试并不是测试工程师就可以完成的事情，这需要对被测系统做全套的技术改造。
● 灰度环境。有了灰度环境，系统就可以在部分环境中先上线，然后再进行一些测试活动或者实验活动。
● A/B测试。A/B测试可能在用户增长领域比测试领域应用得更广，但它也是一种对生产环节的测试验证活动。
测试越早开始，发现问题、修复问题的成本就越低。那多早才算早呢？当然是在软件开始的初期，也就是开卡阶段，测试工程师就参与到项目中，以发挥质量保障作用。在开卡阶段，测试工程师的工作也很重要，他要评估需求的质量，并给出完善的建议。
测试工程师在开卡阶段对故事验收条件的考虑如图1-13所示。
图1-13 对故事验收条件的考虑
具体要求如下。
● 唯一性：对应的故事是全部系统中的唯一功能，不能存在两个相同的功能。既要横向对比一次迭代中的需求，也要纵向对比已有的功能。
● 完整性：每一张故事卡片的描述都是完整的，都有对应验收条件的完整描述及约束描述，没有不确定性的描述。
● 可测试性：每一个验收条件都可以验证，其中既包含了功能性也包含了非功能性。
● 一致性：验收条件之间是一致的，无冲突的，每次迭代中故事卡片的内容和已有功能也是一致的，无冲突的。
● 易理解性：验收条件的描述和设计上是容易理解的，通过故事卡片上的描述就能判定实现的功能。
依照上述特性要求完成故事卡片的评估并补充不完善的验收条件，就完成了测试左移的第一步，接下来进入代码评审、代码扫描、单元测试等针对开发工程师产出物的评价环节。代码扫描属于静态测试技术的实现手段，单元测试是动态测试技术的实现手段，这两种测试手段都属于白盒测试。
测试左移的目标是防止缺陷并降低技术风险，这意味着要持续不断地进行测试，才可以交付高质量的产品。
相对于测试左移，测试右移指产品发布上线或者交付客户后的一些与质量相关的活动，从而保障业务的连续性，提升交付后的产品质量。这里的质量活动包含生产环境监控、生产日志监控、线上巡检、业务指标监控等方面。在生产环境中发生故障时，测试工程师可以把生产故障反馈给制品交付过程中解决问题的关键角色，完成质量回溯的职责。
测试左移、测试、测试右移的关系如图1-14所示。
图1-14 测试左移、测试、测试右移的关系
一图胜千言，图1-14已把测试左移、测试、测试右移解释清楚了，这也是敏捷测试的约束范围。
那么如何衡量软件质量效果这个抽象和笼统的问题呢？为了回答这个问题，测试工程师引入了软件质量模型。
软件质量模型分为以下两类。
● 基于经验的模型：依据经验，使用典型的质量因素构建一个多层质量模型。基于经验的模型又分为层次模型和关系模型两种。其中，层次模型的典型代表有McCall模型、Boehm模型、ISO/IEC 9126模型、ISO/IEC 25010模型，关系模型的典型代表有Perry模型、Gillies模型。
● 基于构建的模型：通过一些方法构建一个模型，包含质量属性之间关系的构建和对质量属性的分析，典型代表为Dromey质量模型。
McCall模型也称为GE（General Electric）模型。它最初起源自美国空军，主要面向系统开发人员和系统开发过程。1977年，Jim A. McCall试图通过一系列软件质量属性指标弥补开发人员与最终用户之间的沟壑，提出了McCall模型。
McCall模型指出，特性是软件质量的反映，因此软件属性可用于（软件质量的）评价准则，通过对软件属性定量的度量就可以反映出软件的质量。
McCall模型是一个三层模型，自顶向下分别是质量因素、质量准则和质量度量。
其中的质量因素是面向管理观点的产品质量，软件的最终用户尽管不了解软件的内部实现细节，但是很了解自己的需求，用户从外部视角定义和描述软件，形成从外部可观察到的特性，这就是McCall模型中顶层的质量因素的来源。次顶层是质量准则，开发人员从内部视角构建软件属性，这些属性是从内部可以观察到的属性，是决定产品质量的属性；底层是定量地度量软件属性的质量度量。
如图1-15所示，McCall模型将质量因素分为产品修正、产品转移和产品运行。每一类质量因素都有自己的质量准则。产品修正包含可维护性、可测试性、灵活性，产品转移包含可移植性、可复用性、互连性，产品运行包含正确性、可靠性、效率、可用性和完整性。
图1-15 McCall模型中的质量因素
这11个质量标准是通过23个衡量指标来度量的。这23个衡量指标包含了简单性、简明性、工具性、自描述性、可扩展性、通用性、模块性、机器独立性、软件系统独立性、通信通用性、数据通用性、可追溯性、完备性、一致性、准确性、容错性、执行效率、存储效率、存取控制、存取审查、可操作性、培训性和通信性。
McCall模型中的质量因素、质量准则和质量度量如图1-16所示。
图1-16 McCall模型中的质量因素、质量准则和质量度量
McCall模型已经对质量做了特性的细化，但是整个模型中缺少了硬件属性。众所周知，没有硬件资源，软件系统就没有了运行的“土壤”，因此Barry W. Boehm在1978年提出了Boehm模型，通过一系列的属性指标量化软件质量。Boehm模型类似于McCall质量模型，采用层次结构（见图1-17），包含高层属性、中层属性和原始属性。
图1-17 Boehm模型的层次结构
Boehm模型中的高层属性包括可移植性、可用性和可维护性。
中层属性包含7个质量要素，分别是可移植性、可靠性、效率、人机界面、可测试性、可理解性和可修改性。原始属性包含设备独立性、自包含性、准确性、完备性、完整性、一致性、可说明性、设备效率、可访问性、通信性、自描述性、结构化性、简明性、易读性及可扩展性。
Boehm模型已经囊括了软件和硬件的属性，但是最终的原始属性和前面介绍的质量要素交叉映射，这为Boehm模型的广泛推广造成了一些影响。因此，ISO/IEC 9126模型综合了Boehm模型和McCall模型的优点与缺点，站在用户、开发者、管理者的角度，从外部质量、内部质量、使用中质量三个方面完成了质量模型的建设，从外部和内部对质量进行度量。
其中，外部度量在测试和使用软件产品的过程中进行，通过观察软件产品的系统行为，完成对其系统行为的测量，得到度量的结果；内部度量在软件设计和编码过程中进行，通过对中间产品的静态分析完成，其目的是确保获得所需的外部质量和使用质量。
ISO/IEC 9126质量模型（见图1-18）包含了6个质量特性和27个质量子特性，特性和子特性一一映射，不存在交叉问题，但是还不够完善。因此有了后来的GB/T 25000质量模型，其中包含系统质量、使用质量等，这在后续章节中会进行介绍。
图1-18 ISO/IEC 9126质量模型
被誉为当代“伟大的管理思想家”“零缺陷之父”“世界质量先生”的克劳士比，致力于“质量管理”哲学的发展和应用，将源于制造业的概念扩展到了所有商业领域。作为美国的商界传奇人物和创业企业家，他拥有40余年的管理经验，创造了许多专业词汇，如“零缺陷”“符合要求”“预防”“不符合要求的代价”“可信赖的组织”等。他对质量的定义是客体的一组固有特性满足要求的程度。
这些质量的理念和名词也影响着软件质量，自从1991年软件产品质量评价国际标准ISO/IEC 9126提出了外部质量、内部质量和使用质量的概念之后，评价一个软件的质量好坏就是要从软件的内部、外部、使用中的表现的角度看软件是否满足规定或潜在用户需求的能力，这也就是软件质量的度量内容。
1979年出版的The Art of Software Testing一书明确了软件测试为发现错误而执行的一个程序或者系统的过程。1983年Bill Hetzel在The Complete Guide to Software Testing一书中再一次明确了测试是以评价一个程序或者系统属性为目标的任何一种活动，测试是对软件质量的度量。
现在，随着质量保障体系的逐渐发展，质量保障已包含测试、质量分析。其中，质量分析主要通过数据、日志、监控及缺陷的表现识别系统的风险（这既可能是技术风险也可能是业务风险），并持续反馈到制品中，由交付团队进行修改，一起保障交付物的质量。再次强调一下，质量保障的重要工作是通过预防、检查与改进软件缺陷保证软件质量。
持续测试不等同于自动化测试，也包括手工测试，比如，每次迭代中新功能的测试采用手工（探索式测试）测试会更快，因为人更灵活、更智能。再比如，人工的需求评审、设计评审和代码评审也必不可少。测试左移中的这些测试活动可以帮助团队在早期预防缺陷，让随后的研发活动更加顺利，通过生产环境中的监控手段、业务巡检方式等促成测试右移，保障持续测试的覆盖度，从而建立从需求到生产的连续性持续测试实践方法。
