DevOps中的测试

测试的分类

测试象限图：

四象限图其实并没有体现敏捷的价值观，它只是一个“通用的软件测试策略”的描述，也可以说，它是一个自动化测试的整体策略的描述，帮助刚入门的测试人员更好地理解：

• 哪些测试更适合自动化测试？
• 哪些测试更适合手工测试？
• 哪些测试需要手工测试和自动化测试结合起来？
• 测试工具在哪些测试中发挥主导作用？

---

业务向导且支持开发过程的测试

包括：功能测试（Functionality）、可变性测试（Modifiability）和可用性测试（Availability）等

功能测试

Functional testing（功能测试），也称为behavioral testing（行为测试）
，根据产品特性、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试，用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本，以保证目标用户的体验将足够好，就像应用程序是专门为该市场开发的一样。功能测试是为了确保程序以期望的方式运行而按功能要求对软件进行的测试，通过对一个系统的所有的特性和功能都进行测试确保符合需求和规范。
功能测试也叫黑盒
测试或数据驱动测试，只需考虑需要测试的各个功能，不需要考虑整个软件的内部结构及代码.一般从软件产品的界面、架构出发，按照需求编写出来的测试用例，输入数据在预期结果和实际结果之间进行评测，进而提出更加使产品达到用户使用的要求。

回归测试

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。

回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。

回归测试应该是上述测试的一个全集，即回归测试中应该包含上述测试的所有内容。

---

业务导向且评价项目的测试

包括：演示（Demonstration）、易用性测试（Usability）、探索性测试（Exploratory）等

这类手工测试可以验证我们实际交付给用户的应用软件是否符合其期望。这并不只是验证应用是否满足需求规格说明，还验证需求规格说明的正确性。

演示

一种非常重要的面向业务且评价项目的测试是演示。在每个迭代结束时，敏捷开发团队都向用户演示其开发完成的新功能。在开发过程中，也应该尽可能频繁地向客户演示功能，确保尽早发现对需求规范的错误理解或者有问题的需求规范。

易用性测试

易用性测试是指用户使用软件时是否感觉方便，比如是否最多点击鼠标三次就可以达到用户的目的。易用性和可用性存在一定的区别，可用性是指是否可以使用，而易用性是指是否方便使用。

探索性测试

探索性测试被James
Bach描述为一种手工测试，他说：“执行测试的同事，测试人员会积极地控制测试的设计，并利用测试时获得的信息设计新的更好的测试。”探索性测试是一个创造新的学习过程，并不只是发现缺陷，他还会导致创建新的自动化测试集合，并可以用于覆盖哪些新的需求。

---

技术向导且支持开发过程的测试

包括：单元测试（unit testing）、组件测试（Component testing）、部署测试（Deployment test）

单元测试

单元测试（unit testing
），是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

单元测试不应该有组件之间的交互，这会让单元测试运行非常快，因此可以得到更早的反馈，了解自己的修改是否破坏了现有的任何功能。

测试替身

**哑对象 （Dummy Object）**是指那些被传递但不被真正使用的而对象，通常这些呀对象只是用于填充参数列表。

**假对象 （Fake Object）**是可以真正使用的实现，但是通常会利用一些捷径，所以不适合在生产环境中使用。一个很好的例子是：内存数据库。

**桩 （Stub）**实在测试中危每个调用提供一个封装好的响应，他通常不会对测试之外的请求进行响应。只用于测试。

**模拟对象 （Mock）**是一种在编程时就设定了它预期要接收的调用。如果收到了未预期的调用，他会抛出异常，并且还会再验证时被检查是否收到了他们所预期的所有调用。

单元测试常常依赖于用测试替身(Test Double)模拟系统的其他部分。

测试用户场景时，单元与单元之间是有关联的，你测某一单元的功能时，可能需要别的单元提供数据，也有可能这单元会有返回结果，而结果会影响到别的单元，也就是测试的单元可能会有输入输出数据，这些数据是会影响被测单元的功能的。
当我们在测试这样的单元时，一般有两种方法，第一种是，将依赖单元放一起测试，但是这种方法实现比较复杂，困难，有时需要花费大量时间。第二种就是将测试单元独立出来，提供它需要的数据，用一些假的比较简单的数据，但是行为是一样的东西来代替，由此降低复杂度和测试可行性，这些假单元借鉴电影中替身的概念，称为测试替身。

测试替身主要的两项功能：为被测单元提供输入数据和记录被测单元的输出结果。

组件测试（集成测试）

组件测试一般包含更大的功能集合，因此可能会捕捉到一些对更大范围内的代码测试时才会发现的问题。所以运行速度比较慢。

部署测试

部署测试用于检查部署过程是否正常，就是应用程序能否被正确的安装、配置。是否与所需的服务正确通信，并得到相应的回应。

【百度百科】也被叫做配置测试:

在很多情况下，软件必须在多种平台及操作系统环境中运行

配置测试主要是针对硬件而言，其测试过程]是测试目标软件在具体硬件配置情况下，出不出现问题，为的是发现硬件配置可能出现的问题。

---

技术向导且评价项目的测试

非功能性测试

非功能行测试指，除了系统功能之外的系统其他方面的质量，如：容量、可用性、安全性等。

容量测试（Capacity Testing）

通过性能测试，如果找到了系统的极限或苛刻的环境中系统的性能表现，在一定的程度上，就完成了负载测试和容量测试
。容量还可以看作系统性能指标中一个特定环境下的一个特定性能指标，即设定的界限或极限值。
容量测试的目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限状态下没有出现任何软件故障或还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。软件容量的测试能让软件开发商或用户了解该软件系统的承载能力或提供服务的能力，如某个电子商务网站所能承受的、同时进行交易或结算的在线用户数。知道了系统的实际容量，如是不能满足设计要求，就应该寻求新的技术解决方案，以提高系统的容量。有了对软件负载的准确预测，不仅能对软件系统在实际使用中的性能状况充满信心，同时也可以帮助用户经济地规划应用系统，优化系统的部署。

安全性测试（Security Testing）

安全测试是在IT软件产品的生命周期中，特别是产品开发基本完成到发布阶段，对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程 。

与通常测试区别

1. 目标不同：测试以发现BUG为目标，安全测试以发现安全隐患为目标。
2. 假设条件不同：测试假设导致问题的数据是用户不小心造成的，接口一般只考虑用户界面。安全测试假设导致问题的数据是攻击者处心积虑构造的，需要考虑所有可能的攻击途径。
3. 思考域不同：测试以系统所具有的功能为思考域。安全测试的思考域不但包括系统的功能，还有系统的机制、外部环境、应用与数据自身安全风险与安全属性等。
4. 问题发现模式不同：测试以违反功能定义为判断依据。安全测试以违反权限与能力的约束为判断依据。

与渗透测试区别

1. 出发点差异：渗透测试是以成功入侵系统，证明系统存在安全问题为出发点；而安全测试则是以发现系统所有可能的安全隐患为出发点。
2. 视角差异：渗透测试是以攻击者的角度来看待和思考问题，安全测试则是站在防护者角度思考问题，尽量发现所有可能被攻击者利用的安全隐患，并指导其进行修复。
3. 覆盖性差异：渗透测试只选取几个点作为测试的目标，而安全测试是在分析系统架构并找出系统所有可能的攻击界面后进行的具有完备性的测试。
4. 成本差异：安全测试需要对系统的功能、系统所采用的技术以及系统的架构等进行分析，所以较渗透测试需要投入更多的时间和人力。
5. 解决方案差异：渗透测试无法提供有针对性的解决方案；而安全测试会站在开发者的角度分析问题的成因，提供更有效的解决方案。

可用性测试

可用性测试的概念是：

让一群具有代表性的用户对产品进行典型操作，同时观察员和开发人员在一旁观察，聆听，做记录。

该产品可能是一个网站，软件，或者其他任何产品，它可能尚未成型。测试可以是早期的纸上原型测试，也可以是后期成品的测试。

在IS0-9241-11中对于可用性做出了明确的解释：

Extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and
satisfaction in a specified context of use.

---

如何做到自动化测试

在新项目中

在新项目中需要从开始就编写自动化验收测试（UAT，User Acceptance Testing）。为了能做到这一点，你需要：

• 选择技术平台和测试工具
• 建立简单的自动化构建
• 指定遵守INVEST原则指定用户故事，并且考虑其验收条件
  • 独立的（Independent）
  • 可协商的（Negotiable）
  • 有价值的（Valuable）
  • 可估计的（Estimable）
  • 小的（Small）
  • 可测试的（Testable）

然后需要遵守以下流程：

• 客户、分析师和测试人员定义验收条件
• 测试人员和开发人员一起基于验收条件实现验收测试的自动化
• 开发人员编码来满足验收条件
• 只要有自动化测试失败，无论是单元测试、组件测试（集成测试）还是验收测试，开发人员都应该将其定位高优先级并且修复它。

在进行中的项目中

• 需要同客户沟通，清楚的识别客户真正的业务价值是什么，延后使用测试来做回归，以防止功能被破坏。
• 基于这些沟通，先将Happy Path的测试自动化，用于覆盖高价值的场景。
  • 让这些测试尽可能覆盖更多的选项是有用的，即让测试覆盖的范围少少宽裕通常用户故事级别的验收测试，步入尽可能多填充一些字段、多点击一些按钮来满足测试需要。

在遗留系统中

• 识别系统中的该价值功能。
• 创建一套广泛的自动化测试，覆盖这些高价值的核心功能。
• 微信的功能添加相应的测试。

对遗留系统来说，这些覆盖核心功能的测试就是非常重要的冒烟测试了。

测试用例的分类

Happy Path

Happy path testing is a well-defined test case that uses known input, that executes without exception and that
produces an expected output.

A test case which results you in a positive result is a Happy path, for e.g. entering proper username and password
on login page.

Happy Path就是按照用户正常使用的流程对系统进行输入，并且最终产生业务价值的系统使用过程。

打开APP->
	注册->
		登录->
			添加购物车->
				跳转到付款页面->
					付款->  // 产生价值
						查看付款信息->
							退出APP

Alternate Path

Alternate Path，用户使用一个不常见的流程对系统进行输入，其过程有可能有反复、或者循环等曲折方式，最终产生了业务价值，这个过程叫做
Alternate Path。

打开APP->
	注册->
		登录->
			添加购物车->
				跳转到付款信息->
			退回购物车->
		删除货物->
			重新选择货物,添加到购物车->
				跳转到付款页面->
					付款-> // 产生价值
						查看付款信息-> 
							退出APP

Sad Path

A test case which yields no result like entering invalid username and invalid password on a login screen is **Sad path
**.

系统没有对用户错误的输入进行正确的反映，被称作Sad Path.比如，进行操作时，系统没有响应，或者系统产生错误等。

Bad Path

“Bad path” which is like entering junk characters in username field or some 70 characters in username field and
will expect system to handle it and show some messages to the user.

当用户有意或者无意的进行错误的输入时，系统应该做出正确的相应，如：提示用户名或者密码错误，提示密码长度不正确等。