【分享实录】测之以恒——代码精进而不觉 | IDCF DevOps案例研究

内容来源：DevOps案例深度研究第6期——持续测试实践研究战队（本文只展示部分PPT及研究成果，全程视频请移步文末）转载请注明出处。
本案例内容贡献者：唐正美、冯建伟、程琳琳、欧建斌、熊小龙、李静、李国有、薛建

第一篇：发展历程

1.1 软件测试的发展历程

原来软件测试也能追本溯源（不是程序员拍脑袋想出来的），也有其存在的必然性与合理性。

迄今为止，软件测试的发展一共经历了5个重要时期：

• 1957年之前－调试为主(Debugging Oriented)
• 1957–1978－证明为主(Demonstration Oriented)
• 1979–1982－破坏为主(Destruction Oriented)
• 1983–1987－评估为主(Evaluation Oriented)
• 1988–至今－预防为主(Prevention Oriented)

1）调试为主

20世纪50年代，计算机刚诞生不久，只有科学家级别的人才会去编程，需求和程序本身也远远没有现在这么复杂多变，相当于开发人员一人承担需求分析、设计、开发、测试等所有工作，当然也不会有人去区分调试和测试。然而严谨的科学家们已经在开始思考 “怎么知道程序满足了需求？”这类问题了。

2）证明为主

1957年，Charles Baker在他的一本书中对调试和测试进行了区分：

• 调试(Debug)：确保程序做了程序员想它做的事情。
• 测试(Testing)：确保程序解决了它该解决的问题。

这是软件测试史上一个重要的里程碑，它标志测试终于自立门户师出有名了。

当时计算机应用的数量、成本和复杂性都大幅度提升，随之而来的经济风险也大大增加，测试就显得很有必要了，这个时期测试的主要目的就是确认软件是满足需求的，也就是我们常说的“做了该做的事情”。

3）破坏为主

1979年，《软件测试的艺术》 (The Art of Software Testing)第一版问世，这本书是测试界的经典之作。书中给出了软件测试的经典定义：

The process of executing a program with the intent of finding errors.
测试是为发现错误而执行程序的过程。

这个观点较之前证明为主的思路，是一个很大的进步。我们不仅要证明软件做了该做的事情，也要保证它没做不该做的事情，这会使测试更加全面，更容易发现问题。

4）评估为主

1983年，美国国家标准局(National Bureau of Standards)发布“Guideline for Lifecycle Validation, Verification and Testing of Computer Software”，也就是我们常说的VV&T。VV&T提出了测试界很有名的两个名词：验证(Verification)和确认(Validation)。

• Verification: Are we building the product right?
• Validation: Are we building the right product?

人们提出了在软件生命周期中使用分析、评审、测试来评估产品的理论。软件测试工程在这个时期得到了快速的发展：

• 出现测试经理(test manager)，测试分析师(test analyst)等职称。
• 开展正式的国际性测试会议和活动。
• 发表大量测试刊物。
• 发布相关国际标准。

以上种种都预示着软件测试正作为一门独立的、专业的、具有影响力的工程学发展起来了。

5）预防为主

预防为主是当下软件测试的主流思想之一。STEP(Systematic Test and Evaluation Process)是最早的一个以预防为主的生命周期模型，STEP认为测试与开发是并行的，整个测试的生命周期也是由计划、分析、设计、开发、执行和维护组成。也就是说，测试不是在编码完成后才开始介入，而是贯穿于整个软件生命周期。

我们都知道，没有100%完美的软件，零缺陷是不可能的，所以我们要做的是：尽量早地介入，尽量早地发现这些明显的或隐藏的bug，发现得越早，修复起来的成本越低，产生的风险也越小。

虽然每一个发展阶段对软件测试的认识都有其局限性，但是前辈们一直在思考和总结前人的经验，创造性地提出新的理论和方向，这种精神非常值得尊敬和学习。所谓以铜为镜，可正衣冠；以史为镜，可明得失。知道了从哪里来，方能更好地明白该到哪里去。

过去几年间，企业的数字化转型成为IT领域中共同关注的热点。在中国市场，由于互联网应用领域的深度发展以及极其激烈的市场竞争，企业的数字化转型现在不仅是很多企业谋发展的关键支点，同时也正在成为企业生存的根基。在这种情况下，无论是企业在营销端的高效获客、产品端的研发制造，还是运营端的业务支撑，都在迅速地向数字化演变。数字业务的爆发，必然会导致企业对软件研发的强烈需求。

但是，回顾软件发展的历程，毫不夸张地说，软件研发对于很多企业来说是一场高风险的投入，面临着非常多的不确定因素和较高的失败率。所以，过去的几十年，整个软件行业都在寻找降低软件生产风险和提升软件生产效率的有效方法，这种现实的需求驱动了DevOps的广泛采纳。

DevOps在整个软件生产流程中的每个环节都引入“持续”的理念，包括如“持续开发”、“持续集成”、“持续测试”、“持续部署”，以及“持续监控”等一系列具体实践。

所谓“持续”理念，就是把软件生产流程中的每个环节都实现“反复、高效地做”，从而让每个环节的反馈效率得以提升，让完整的迭代流程尽快走完。为了达到“持续”的效果，DevOps要求软件生产的每个阶段尽可能地提升自动化能力，并且鼓励实现不同环节之间的高效衔接与沟通。

1.2 什么是持续测试

广义的概念：就是从产品发布计划开始，直到交付、运维，测试融于其中、并与开发形影不离，随时暴露出产品的质量风险，随时了解产品质量状态。

狭义概念：一次软件迭代开发中的主要测试活动。设计评审、单元测试、用户故事实现的验证、集成测试等，也包含持续的新功能测试和持续的回归测试，以及性能测试、安全性测试、兼容性测试等针对软件质量属性的专项测试。

第二篇：测试理念

本章主要通过5W1H分析方法论，简单了解测试/持续测试在日常测试工作中的方方面面。

其中 what-什么是持续测试 在第一篇中有介绍。

Why-为什么测试

测试的重要性不言而喻，这里列出了为什么需要测试：

• 为产品提供信心。
• 找到薄弱环节。
• 形成质量等级。
• 确定满足产品需求的程度。
• 加深对整个系统的理解。
• 证明可用性、可操作性。
• 对app能否deploy 提供足够的信息。

测试也在不停地发展，在DevOps中我们提倡的是持续测试，那为什么要持续测试呢？

• 提高测试效率，加快release 速度。
• 及时获得反馈。
• DevOps的最终目的是持续交付，只有实现持续测试，才能实现持续交付。

同时持续测试和持续集成、持续部署、持续运维一样，是面向敏捷和DevOps转型的关键因素。

Where-哪里需要测试

测试包括文档、数据、程序，是贯穿软件开发生命周期的，从开始的需求 到编码到验收测试结束，包括但不限于对需求、概要设计、详细设计、源码、可运行程序、运行环境的测试。

Where-不同的测试类型在敏捷测试四象限的位置。

When-什么时候测试

我们先看一下这个曲线图：

• 蓝色的线表示bug在什么时候引入，85%的bug在最初的coding阶段就存在了。
• 黄色的线表示 bug在什么时候发现，大部分的bug是在功能测试和场景测试过程中才发现。
• 红色的线表示修复bug的代价，非常明显可以看出修改bug的时间越晚cost越高。

我们可以得出一个结论：越早测试越好。

测试越早越好，就是我们常说的测试左移/测试先行的概念，有了测试左移的概念，也就有对应的测试右移，它是指在产品发布后，还是要通过测试/监控/不断反馈，继续优化产品，提高产品质量。

最后我们可以看出，在DevOps的各个环节中都有测试，测试无时无刻，无处不在。

Who-谁对质量负责

上图是从SAFe官方网站 质量内建章节copy过来，这个章节强调了所有人员为质量负责。

在实际日常工作中，每个角色都有自己的主要工作，做好自己的本职工作 就是对质量的负责。比如产品架构师在技术设计上根据产品特点选择好的技术方案，能够持续不断改进产品的架构，支持高性能、高并发。

当然我们还需要一些流程来保证质量。一般情况下，团队会建立一系列经过工程师成员评审过的规范。举个例子 story 的Definition of Ready和 Definition of Done的规范，每个成员就要遵守，在story完成的时候看是否已经达到定义的要求。

还有通过CI/CD pipeline、自动化测试加快反馈速度，提高产品质量。

How-怎么做测试

可以参考的测试理论模型。

传统测试模型以及对应的优缺点：

敏捷测试模型1--金字塔测试模型

金字塔模型 侧重于自动化测试 ，自下而上的大小表示测试的比重，把测试的重心左移，加强单元测试/组件测试，问题早发现早解决，长期来看是节约成本的。探索性测试，强调测试人员的创造力，以便在测试过程中发现质量问题。

敏捷测试模型2--四象限模型

这个四象限模型最初是Brian Marick提出的，Brain Marick是敏捷宣言的签署者和极限编程的倡导者，敏捷界的大神。后来另一个敏捷领域的测试大神Lisa Crispin在他的基础上做了优化，并在自己的《敏捷软件测试》书中 对每个象限都有详细的介绍。

第三篇：测试生命周期与工具

3.1 软件测试生命周期

• 需求阶段（Requirements phase）
• 计划阶段（Planning Phase）
• 分析阶段（Analysis phase）
• 设计阶段（Design Phase）
• 实施阶段（Implementation Phase）
• 执行阶段（Execution Phase）
• 总结阶段（Conclusion Phase）
• 结束阶段（Closure Phase）

3.2 单元测试

单元测试（Unit Testing）又称为模块测试，是针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。

• 过程化编程：一个单元就是单个程序、函数、过程等。
• 面向对象编程：最小单元就是方法，包括基类（超类）、抽象类、或者派生类（子类）中的方法。

优势：

• 可以及早发现问题。
• 更改不影响其他模块。
• 模块间集成更容易。
• 使设计和文档变得简单。
• 表达设计。

挑战：

• 测试名称的麻烦。
• 编写错误的测试类型。
• 缺乏适当的初始条件。

单元测试工具

• 开发语言：JUnit、TestNG、NUnit、 SimpleTest... ...
• 辅助：JUnit-addons——对Junit功能补充，如设置、获取被测试对象的私有属性的值，调用对象私有方法等；EvoSuite——用于自动生成单元测试用例。
• 配合：DJUnit——通过代码自动生成Mock对象，省去编写Mock类；EasyMock——通过编程自动Mock掉与测试对象无关的类和方法。

3.3 接口测试

接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。重点是检查数据的交换、传递和控制管理过程，以及系统间的相互逻辑依赖关系等 。接口测试内容包括功能测试、性能测试和安全测试。

接口测试重要性：

• 保证系统的正确和稳定，为系统接口进行全面高效持续的检测。
• 可以获得较高的投资回报；
• 有利于测试前移。
• 通过持续测试和监控能够及时发现项目中存在的问题接口。

接口测试工具

比较常用的工具如下：

工具	入门难度	持续集成
PostMan	低	newman+jenkins
SoapUI	中	ant/maven+jenkins
Jmeter	中	ant/maven+jenkins
Katalon	高	jenkins

其中POSTMAN是一款功能强大的调试HTTP接口的工具，易用性高，设计得很人性化，适合简单的API功能测试或者测试新手。原理图如下：

POSTMAN持续集成流程：

3.4 契约测试

原则：

• 快速反馈。
• 消费者与提供者解耦。
• 消费者驱动设计优于提供者驱动设计。

契约测试工具

第四篇：测试展望

软件测试的技术趋势其实有很多，在这里说其中两点：DevSecOps和AI Test接口。

4.1 DevSecOps

随着网络诈骗、网络犯罪、网络威胁和漏洞快速增长，导致网络风险时时刻刻都存在，随之而来的就是客户对安全性的感知也越来越重要。

安全是整个IT团队（包括开发、运维及测试团队）中每个人的责任，需要贯穿整个业务生命周期每一个环节，通过加强内部安全测试，主动搜寻安全漏洞，及时修复漏洞、控制风险，实现与业务流程的良好整合。

Security安全在DevOps的各个环节都有体现，不同的阶段有不同类型的安全层面的考虑。

4.2 AI Test

上图 给出了 近年来测试的演变过程，从最开始的瀑布式测试方法，到自动化测试，再到DevOps的持续测试。

再接着就是所谓的AI Test, 图中叫autonomous Testing--自治化测试，而自治化测试是通过AI和Machine Learning实现。

注意这里的名字是自治化测试，它和自动化测试的区别：自动化只是自动化执行特定的测试用例，自治化测试更加smart更加智能，并不是简单地去执行测试用例，而是能够生成最优的测试脚本和测试用例， 能够根据不同的需求选择不同的测试用例，同时能够预知客户的行为。

既然AI Test是趋势，它能做什么，有什么优点呢？下面两种图给出了答案。