自动化测试策略与方法

自动化测试策略与方法

自动化测试

简述

• 自动化测试主要用于软件功能的批量回归验证，是一种机械式且重复性的验证工作，而这正是机器所擅长的
• 自动化测试是为了消除手工重复劳动而投入对测试用例的自动化活动

测试领域的4类基本活动

• “问题认知”是指对业务问题本身的理解和认识。其主要信息来源于持续交付中的探索环
• “分析”是指测试分析和设计，通过对业务问题的认知，分析并设计能够验证是否成功解决业务问题的方式和方法，在确保验证质量的前提下，使测试成本最低
• “执行”是指执行由测试分析环境产生的测试用例，得到测试结果或数据
• “决策”是指根据测试结果做出下一步行动判断

自动化测试的优势

• 减少失误率，提交准确性
• 节省时间和执行成本
• 提升测试覆盖度
• 做手工无法完成的测试
• 为开发人员提高质量反馈速度
• 提高团队士气

自动化测试所需的成本

• 工具投入成本
• 用例维护成本
• 专业技能人员的成本
• 设备资源的投入

自动化测试的不足

• “无法观察执行过程”

自动化测试4个基本衡量维度

• “快速”。是指自动化测试用例的执行速度要快。“最好在10分钟之内，不要超过15分钟”
• “便捷”。是指团队中的每名工程师都能在需要的时候方便的执行自动化测试用例，而且不需要他人帮助，也不会影响到他人
• “及时”。是指一旦功能发生改变，就能够通过自动化测试用例的运行，告知本次代码变更对软件质量的影响，包括对原有功能的影响，以及新增功能的质量情况
• “可信”。是指自动化测试用例运行后的结果可信赖，不存在随机失败的现象

自动化测试常用架构

微核架构的测试金字塔

• 端到端自动化测试。是指通过模拟界面操作来驱动的自动化测试
• API自动化测试。是指在UI层之下，通过API接口来驱动下层业务逻辑的自动化测试
• 组件或插件间服务的接口自动化测试。主要是验证两个或多个组件间的功能正确性
• 组件测试。是对单个组件或框架本身进行质量验证
• 自动化测试。是最细粒度的自动化测试

微服务应用的测试金字塔

• 业务组件或服务测试。是指对单个组件或服务的测试，以验证该组件的行为是否符合设计预期
• 契约测试（也称为消费者驱动测试）。是指软件系统中各个服务间交互的数据标准格式，更多的指消费者与服务提供方之间交互的数据接口的格式
• 业务工作流测试。是指启动运行两个或以上微服务，进行业务流程上的测试，以验证多个被测服务之间是否可以正常工作，完成某一业务请求
• 端到端测试。指整个软件服务的流程进行测试，以验证其工作流自始至终的执行是否符合设计预期

自动化测试的实施策略

增加自动化测试用例的着手点

• 针对代码热区补充自动化测试用例
• 跟随新功能开发的进度
• 从测试金字塔的中间层向上下两端扩展
• 自动化测试用例的质量比数量重要

提高自动化测试的执行次数

• 共享自动化测试用例
• 开发人员是自动化测试的第一用户

良好自动化测试的特征

• 用例之间必须互相独立
• 测试用例的运行结果必须稳定
• 测试用例的运行速度必须块
• 测试环境应该统一

共享自动化测试的维护职责

代码测试覆盖率

• 代码测试覆盖率建议性标准是达到85%

用户验收自动化测试要点

自动化测试用例的代码框架结构的3层结构

• 测试用例的描述层

  它用于人与人的沟通交流。每个人都可以轻松的知道这个测试的测试目的与内容
  

• 测试用例的实现层

  它用于将上面的描述层与程序脚本对应在一起，并可以实现测试意图
  

• 测试用例的接口层

  它对通用测试工具提供的API进行一定的封装，把哪些与测试领域不相关的代码实现细节隔离，
  并为上层的实现层提供一些可复用的基本接口集合
  

测试用例数应保持低位

为自动化测试用例预留API

为调试做好准备

测试数据的准备

常见方法

• 通过一些规则，编写程序自动生成数据。其不足之处在于，当规则复杂时，数据生成的程序比较难于编写和维护
• 通过录制手工测试时产生的数据
• 将生产环境的非敏感数据克隆一份，或者截取数据片段
• 进行生产环境数据的自动化录制、保存并备份

质量检查方法

差异批准测试方法

简述

• 是一种半自动化测试方法
• 当将预定义的数据集输入系统后，收集运行后的输出结果，对其中需要验证的数据进行提取，并将提取的结果放入文本文件中。通过前后两次测试结果的对比，用人工批注的方式进行半自动化测试
• 在使用差异批准测试方法时，需要注意动态信息的处理。例如日期时间数据
• 在做这类测试时，需要通过某种方式过滤噪声

步骤

• 首次运行后，人工对这些文本文件的内容标注其正确性，并保存起来
• 当再次批量运行这些测试时，将运行结果与上次保存的结果进行自动对比
• 如果没有差异，即可认为本次输出结果是正确的
• 如果存在差异，则由人工进行再次审核。加入后面这次的执行结果是正确的，将它批注为新的正确的结果，以便作为下次的判断基准

代码规范检查与代码动静态检测

• 代码风格规范检查。是指通过一些工具，依据团队定义的一些代码编写规范，针对源代码进行检查。对风格规范检查来说，其目的更多是增强代码的可读性和易维护性
• 代码动静态检测。是指使用一些工具，对产品源代码进行扫描，发现代码中存在的问题或潜在风险，是一种投入产出比较高的质量检查手段，可以分为静态扫描和动态分析
• 静态扫描。通常是指写好源代码后，无须经过编译器编译，而直接使用一些扫描工具对其进行扫描，找出代码当中存在的一些语义缺陷、安全漏洞的解决方案。实现方式包括两种：一是基于语法解析方法进行模式匹配来做静态分析；二是采用模拟程序全路径执行的方式进行分析
• 动态分析。是通过在真实或虚拟处理器上执行目标程序进行分析

AI在测试领域的应用

传统自动化测试

传统自动化测试用例的创建流程

1. 测试分析者设计测试用例，并文档化
2. 测试执行者执行测试用例，并报告bug
3. 开发人员修复bug
4. 测试执行者再次执行测试，直至验证通过
5. 测试自动化专家从测试用例文档中选出一些重要且变动可能性较小的测试用例
6. 对挑选出来的重要测试用例编写自动化脚本，并归入自动化回归测试用例库

传统自动化测试的特点

• 测试用例执行成本高

  多为黑盒自动化测试用例，而且通常是以模拟界面操作来驱动的系统集成测试。
  这种测试用例需要模拟真实用户的界面操作，同时要在界面捕获系统返回的结果
  

• 自动化测试执行频率低

  自动化测试用例通常只在软件开发完成之后，作为进入测试阶段的准入标准，以及回归测试时使用
  

• 质量反馈滞后

  大部分测试用例是对软件应用主要操作流程的回归测试，无法覆盖当前版本正在开发的新功能
  

• 测试环境准备成本高

  通常是端到端的自动化测试用例，需要准备完善的测试数据集和整套的运行环境
  
  测试环境搭建过程中手工操作较多，甚至需要多人参与，成本较高
  

• 测试结果可信度低

  受机器硬件排至、网络状况、用例的处理流程长度等多种因素影响，
  端到端的自动化测试用例结果的不稳定性，令测试结果的可信度大大降低
  

• 人员依赖性较强

  编写自动化测试用例很大程度上依赖于少数测试开发专职人员
  

敏捷测试的四象限分类法

领域

• “面向业务专家”。是指能够与业务专家无障碍沟通
• “面向技术人员”。是指容易与技术人员达成共识
• “支持编程”。是指它的第一目标是为了帮助产品研发团队自己检查功能需求是否开发完成
• “评判项目”。是指用于找出产品是否有缺陷

象限

• 第一象限

  通常都只能通过手工方式运行。例如软件演示、用户体验测试和探索性测试
  

• 第二象限

  通常是以自动化方式运行。例如用户功能验收测试。该类测试是从用户的角度来验收软件功能的
  

• 第三象限

  常是以自动化方式运行。例如系统集成测试、单元测试、组件测试。
  该类测试是软件研发团队对于自我软件技术实现的验证
  

• 第四象限

  通过自动化/手工方式运行。例如安全测试、性能测试等非功能验收测试
  

手工测试

• 手工测试的核心价值在于回答“我们是否正在开发一个正确的、满足用户期望的软件系统？”
• 手工测试过程中，我们可以主动观察、学习和分析，进行更具有创造性的工作。例如探索测试、用户友好性验证或者用户体验的改善