第十章：自动化测试策略与方法

自动化测试的自身定位：
　　测试领域有4类基本活动：
　　　　问题认知：对业务问题本身的理解和认识。其主要信息来源于持续交付8字环中的探索环
　　　　分析：“测试分析和设计”，通过对业务问题的认知，分析并设计能够验证是否成功解决业务问题的方式和方法，通过不断优化，在确保验证质量的前提下，使测试成本最低
　　　　执行：执行由测试分析环节产生的测试用例，得到测试结果或数据（存在大量重复性劳动，可以由机器承担）
　　　　决策：根据测试结果做出下一步行动判断
　　敏捷测试的四象限分类法：P154

　　　　面向业务专家：能够与业务专家无障碍沟通
　　　　面向技术人员：容易与技术人员达成共识
　　　　支持编程：第一目标是为了帮助产品研发团队自己检查功能需求是否开发完成
　　　　评判项目：用于找出产品是否有缺陷
　　自动化测试的优势：
　　　　减少失误率，提高准确性：自动化测试每次执行时都会执行相同的步骤，并且每次都会记录详细的执行结果，且不受“人”的因素影响
　　　　节省时间和执行成本：自动化软件测试用例一旦被创建，就可以做到无人值守的运行，可以配置在不同的电脑上并行运行，比手动测试快，
　　　　提升测试覆盖度：可以查看应用程序内部的运行情况，如内存使用、内存中的内容及数据表、文件内容和内部程序状态；在每次测试中可以轻松执行数千个不同的复杂测试用例
　　　　做手工无法完成的测试：模拟成千上万的用户同时受控的网络应用测试
　　　　为开发人员提高质量反馈速度
　　　　提高团队士气
　　自动化测试所需的投入：
　　　　工具投入成本：自动化测试需要工具支持，因此需要相关测试工具的研发投入和对团队成员的专有测试架构、工具的使用培训
　　　　用例维护成本：软件在整个生命周期，会不断进行功能的增加、删除和修改，此时原有的自动化测试用例也要做对应的改动
　　　　专业技能人员的成本：需要编写代码
　　　　设备资源的投入：自动化测试无法完全代替手工测试，不仅需要保存手工测试的测试环境，以及为自动化测试用例执行准备的测试环境
　　　　与手工测试相比，其不足在于“无法观察执行过程”，无任何主动观察、认知和分析能力
　　　　自动化测试用例最擅长回答的问题是“软件系统是否按照我们预先设计的方式运行了？”
　　　　自动化测试主要用于软件功能的批量回归验证
　　　　手工测试的最核心价值在于回答“我们是否正在开发一个正确的、满足用户期望的软件系统？”
突破传统自动化测试的困境
　　传统自动化测试的流程：
　　　　1.测试分析者设计测试用例，并文档化
　　　　2.测试执行者执行测试用例，并报告Bug
　　　　3.开发人员修复Bug
　　　　4.测试执行者再次执行测试，直至验证通过
　　　　5.测试自动化专家从测试用例文档中选出一些重要且变动可能性较小的测试用例
　　　　6.对挑选出来的重要测试用例编写自动化脚本，并归入自动化回归测试用例库
　　传统自动化测试的特点：
　　　　1.测试用例执行成本高：多为黑盒自动化测试用例，而且通常是以模拟界面操作来驱动的系统集成测试。
　　　　2.自动化测试执行频率低：只在软件开发完成后，作为进入测试阶段的准入标准，以及系统回归测试时使用
　　　　3.质量反馈滞后：无法覆盖当前版本正在开发的新功能，一般是作为主流程的回归用例
　　　　4.测试环境准备成本高：需要准备整套环境，需要参与人较多，成本较高
　　　　5.测试结果可信度低：端到端的自动化测试用例受机器硬件配置、网络状况、用力的处理流程长度等多种因素影响，可能会造成随机失败
　　　　6.人员依赖性强：很大程度上依赖少数测试开发专职人员
　　自动化测试的分层：
　　　　容易融化的测试蛋筒冰淇淋：用户验收测试（最上面）>系统集成测试>组件测试（最下面）（用例数量多->少，运行时间多->低）
　　　　自动化测试金字塔：单元测试（最下面）>系统集成测试>用户验收测试（最上面）（用例数量多->少，运行时间低->多）
　　自动化测试建设的4个基本衡量维度：
　　　　快速：执行速度要快，最好在10分钟之内，不要超过15分钟
　　　　便捷：团队中的每名工程师都能够随时随地很方便的执行自动化测试用例，而且不需要他人帮助，也不会影响到他人
　　　　及时：功能一旦发生了改变，就能够通过自动化测试用例的执行，告知本次代码变更对软件质量的影响
　　　　可信：自动化测试用例运行后的结果可以信赖，不存在随机失败（或成功）的现象
　　不同类型的测试金字塔：
　　　　微核架构的测试金字塔：自动化单元测试（最下面）>框架或插件的自动化测试>框架组件与插件间服务/接口自动化测试>API自动化测试>端到端自动化测试（最上面）
　　　　　　端到端自动化测试：通过模拟界面操作来驱动的自动化测试
　　　　　　API自动化测试：UI层之下，通过API接口来驱动下层业务逻辑的自动化测试
　　　　　　组件或插件间服务的接口自动化测试：验证两个或两个以上组件（插件）间的功能正确性
　　　　　　组件测试：对单个组件或框架本身进行质量验证
　　　　　　自动化单元测试：最细粒度的自动化测试
　　　　微服务应用的测试金字塔：单元测试（最下面）>业务组件或组件测试>契约测试>工作流测试>端到端自动化测试（最上面）
　　　　　　单元测试：软件中最小可测业务逻辑单元进行检查和验证
　　　　　　　　特点：对外部依赖（如文件系统、网络等）比较少，测试运行时不需要系统处于运行状态，测试运行速度快
　　　　　　业务组件或服务测试：对单个组件或服务的测试，以验证该组件的行为是否符合设计预期。
　　　　　　　　组件是由多个最小业务逻辑单元组成的代码块，对外提供一组相关业务功能的集合。它既可能与本系统内的其他组件交互，也可能负责与外部集成点进行交互
　　　　　　契约测试：又称为消费者驱动的契约测试。
　　　　　　　　契约是指软件系统中各个服务间交互的数据标准格式，更多的指消费者与服务提供方之间交互的数据接口的格式
　　　　　　　　目标是测试消费者接口与服务者接口之间的正确性
　　　　　　业务工作流测试：启动运行两个或以上微服务，进行业务流程上的测试，以验证多个被测服务之间是否可以正常工作，完成某一业务请求
　　　　　　端到端测试：对整个软件服务的流程进行测试，以验证其工作流自始至终的执行是否符合设计预期
　　　　　　　　目的是识别系统依赖关系，并确保在各种系统（包括外部依赖以及多个内部系统）之间传递正确的信息

自动化测试的实施策略：
　　增加自动化测试用例的着手点：
　　　　1.针对代码热区补充自动化测试用例：
　　　　　　代码热区是指那些代码改动频率相对较高的文件或函数，以及经常出问题的功能组件
　　　　2.跟随新功能开发的进度
　　　　3.从测试金字塔的中间层向上下两端扩展
　　　　4.自动化测试用例的质量比数量重要
　　提高自动化测试的执行次数：
　　　　1.共享自动化测试用例
　　　　2.开发人员是自动化测试用例的第一用户：在编写代码的时候，随时能够方便的运行自动化测试用例
　　良好自动化测试的特征：
　　　　1.用例之间必须相互独立
　　　　2.测试用例的运行结果必须稳定
　　　　3.测试用例的运行速度必须快
　　　　4.测试环境应该统一
　　共享自动化测试的维护职责：保持测试用例代码和需求变更速度一致
　　代码测试覆盖率：谷歌公司建议单元测试覆盖率达到85%
用户验收自动化测试要点：
　　先搭建分层框架
　　　　1.测试用例的描述层：用于人与人的沟通交流
　　　　2.测试用例的实现层：用于将上面的描述层与程序脚本对应在一起，并可实现测试意图
　　　　3.测试用例的接口层：对通用测试工具提供的API进行一定的封装，把那些与测试领域不相关的代码实现细节隔离，并为上层的实现层提供一些可复用的基本接口集合
　　测试用例数应保持低位：
　　　　数量不应该过多，验证的重点：
　　　　　　用户验收自动化测试应该以用户旅程地图的方式来验证软件应用或服务的核心工作流程
　　　　　　用户验收自动化测试应该验证软件应用或服务的端到端行为，而非具体实现细节
　　为自动化测试用例预留API：
　　　　应该尽量调用位于界面下层的API来驱动业余流程的执行，而少用模拟图形界面操作的代码，这就要求在程序设计时就要考虑到端到端自动化测试的便捷性，支持相应的API驱动方式。
　　为调试做好准备：提供完整的日志文件；记录常见的测试失败模式；保留所有相关的系统状态信息，如自动截屏、出错时的现场镜像保存等
　　测试数据的准备
　　　　分类：
　　　　　　确保应用程序启动所需的基本数据，例如：一些应用初始化所需要的数据，如元数据、字典表等
　　　　　　令某一类测试组成的测试用例集达到预期状态所需要的数据
　　　　　　某个具体测试用例执行，它自己所需要准备的数据
　　　　测试数据准备工作：
　　　　　　1.通过一些规则，编写程序自动生成数据。其不足之处在于：当规则复杂时，数据生成的程序比较难于编写和维护
　　　　　　2.通过录制手工测试时产生的数据
　　　　　　3.将生产环境的非敏感数据克隆一份，或者截取数据片段
　　　　　　4.进行生产环境数据的自动化录制、保存与备份
　　　　　　实时生产环境的数据流量克隆：
　　　　　　　　原理：在流量请求的入口处增加一个请求克隆器。当生产环境的请求进入之后，该克隆器将其克隆一份请求后，原有的请求仍旧通过原来的服务进行正常处理，而克隆出来的请求引流到新版本的服务，从而进行新版本的相关测试。是暗部署的是一种实现方式。
其他质量检查方法：
　　差异批注测试方法：
　　　　概念：
　　　　　　是一种半自动化测试。当将预定义的数据集输入系统后，收集运行后的输出结果（如图片或PDF文件），对其中需要验证的数据进行提取，并将提取的结果放入文本文件中。通过前后两次测试结果的对比，用人工批注的方式进行半自动化测试。
　　　　应用场景：
　　　　　　例如软件系统需要生成很多动态数据的图片或者PDF文件（如电子发票）
　　　　步骤：
　　　　　　1.首次运行后，人工对这些文本文件的内容标注其正确性，并保存起来
　　　　　　2.当再次批量运行这些测试时，将运行结果与上次保存的结果进行自动对比
　　　　　　　　如果没有差异，即可认为本次输出结果是正确的
　　　　　　　　如果存在差异，则由人工进行再次审核。假如后面这次的执行结果是正确的，将它批注为新的正确结果，以便作为下次的判断基准
　　　　注意事项：
　　　　　　需要注意动态信息（如日期时间）的处理。在做这类测试时，需要通过某种方式过滤噪声
　　代码规范检查与代码动静态检测
　　　　代码风格规范检查是指通过一些工具，依据团队定义的一些代码编写规范，针对源代码进行检查。如发现破坏规范的代码，就加以指正。
　　　　　　常用的有Checkstyle、PMD、SonarQube等
　　　　　　目的是增强代码的可读性和易维护性
　　　　代码动静态检测是指使用一些工具，对产品源代码进行自动化扫描，发现代码中存在的问题或潜在风险。
　　　　　　静态扫描：写好源代码后，无须经过编译器编译，而直接使用一些扫描工具对其进行扫描，找出代码当中存在的一些语义缺陷、安全漏洞的解决方案
　　　　　　　　实现方式：
　　　　　　　　　　基于语法分析方法进行模式匹配来做静态分析
　　　　　　　　　　采用模拟程序全路径执行的方式进行分析
　　　　　　　　常用的有各种编程语言对应的lint工具、Coverity、Klocwork等
　　　　　　动态分析：通过在真实或者虚拟处理器上执行目标程序进行分析
　　　　　　　　例如，在可能的漏洞处插入专门编制的故障发生函数，这些函数的作用就是迫使目标软件的运行产生异常，然后通过监控程序来检查是否发生了边界溢出或其他异常现象
　　　　　　　　常用的工具有Valgrind、Purify等
　　　　　　当代码库规模较大时，扫描时间可能会较长，可以通过增量扫描的方式

前置周期：从用户下订单开始到其收到产品之间的时间周期
　　这个时间周期越短，说明交付效率越高，越能提升客户的满意度

对自动化测试的实践管理来说，有5条重要原则需要遵守
　　1.自动化测试用例运行次数越多，平均成本越低，收益就越大
　　2.自动化测试用例之间应该尽可能相互独立，互不影响
　　3.在质量有保障的前提下，自动化测试用例的数量越少越好
　　4.遗留代码的自动化测试用例编写应该从代码热区开始
　　5.自动化测试用例从测试金字塔的中间层开始补充，投入产出比最高