关于测试:分享实录测之以恒代码精进而不觉-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 是一款功能强大的调试 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 是趋势，它能做什么，有什么长处呢？上面两种图给出了答案。