软件测试——理论篇

测试流程体系

软件测试基本概念

1. 软件测试：通过手工或者工具对“被测对象”进行测试，验证实验结果与预期结果是否存在差异。
2. 软件测试的作用：通过测试可以发现并修复软件当中存在的缺陷，从而提高用户对产品的使用信心。测试可以降低同类型产品开发遇到问题的风险。
3. 软件缺陷：即bug，软件缺陷会导致软件不能正常运行，它的存在会一定程度上导致软件不能满足用户的需求，甚至有可能破坏或泄露用户的重要数据。
4. 软件测试原则
   • 测试显示缺陷的存在
   • 穷尽测试是不可能的
   • 测试尽早介入
   • 缺陷集群性（2/8）原则
   • 杀虫剂悖论
   • 测试活动依赖于测试内容
   • 没有错误是好是谬论
5. 软件测试对象
   • 需求分析阶段：需求文档，接口文档。
   • 编码实现阶段：源代码
   • 系统功能使用：软件程序
6. 测试用例：为特定目的而设定的一组测试输入、执行步骤和预期的结果，以便测试产品是否满足某个特定需求的文档。

软件测试模型

V模型：

• 需求分析：需求文档
• 概要分析：系统架构、模块划分、模块与模块之间的接口
• 详细设计：模块内部实现的逻辑和方法
• 编码：用代码实现设计的内容
• 单元测试：测试代码中最小模块是否符合详细设计
• 集成测试：测试各个模块组成到一起后是否可以正常使用
• 系统测试：测试已经集成在一起的产品是否符合需求文档中的要求
• 验收测试：测试产品是否符合用户的需求

1. V模型是瀑布模型的一种改进。
2. V模型标明了测试过程中的不同阶段。
3. V模型的优点：
   1. 既有底层测试又有高层开发。
   2. 将开发阶段清楚的表现出来，便于控制开发的过程。
4. V模型的缺点：
   1. 容易让人误解为测试是在开发完成之后的一个阶段。
   2. 由于它的顺序性，当编码完成之后，正式进入测试时，这时发现的一些bug可能不容易找到其根源，并且代码修改起来也很困难。
   3. 如果需求变更较大，导致要重复变更需求、设计、编码、测试。返工量大。

W模型：

1. W模型明确表示出了测试与开发的并行关系。
2. W模型中测试伴随着整个软件开发周期，并且测试的对象不仅仅是程序，需求和设计同样要测试。
3. W模型的优点：
   1. 将测试贯穿到整个软件的生命周期中，且除了代码要测试，需求、设计等都要测试。
   2. 更早的介入到软件开发中，能尽早的发现缺陷进行修复。
   3. 测试与开发独立起来，并与开发并行。
4. W模型的缺点：
   1. 无法支持迭代的开发模型。
   2. 对有些项目，开发过程中根本没有文档产生，故W模型无法使用。
   3. 对于需求和设计的测试技术要求很高，实践起来很困难。

H模型：

1. 软件开发中需求、设计、编码等活动被分阶段执行、但是实践中，他们并不是完全串行的，它们之间更多时候是交叉进行的，更多的是迭代执行。
2. 把测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰的体现出来。
3. H模型的优点：
   1. 软件测试完全独立，贯穿整个生命周期，且与其他流程并发进行。
   2. 软件测试活动可以尽早准备、尽早执行，具有很强的灵活性。
4. H模型的缺点：
   1. 测试就绪点分析困难。
   2. 对于整个项目组的人员要求非常高。

软件测试工作流程

传统测试流程

系统测试

Bug管理流程

缺陷提交：说明Bug来源、环境、结果、类型、Bug如何复现、截图、录屏、日志等相关信息。

测试左移和测试右移

测试左移

1. 左移是往测试之前的开发阶段转移
2. 测试团队在软件开发周期早期就开始介入
3. 对代码进行测试
4. 从发现bug到预防bug

测试左移——质量保障手段

• 代码评审（code review）
• 代码审计
• 单元测试
• 自动化冒烟测试
• 研发自测

测试右移

1. 右移是往发布之后移。
2. 产品上线后进行线上监控。

测试右移——线上监控

• 闭环的线上问题反馈-检查-解决-更新流程。
• 更便捷的日志查看、回传服务。
• 丰富有效的log，便于问题的快速定位。
• 丰富的监控指标（例如业务异常点指标）。
• 业务监控（例如短信发送等）。
• 关键指标每日监控（服务器指标）。
• 生产数据监控（警报）。

测试技术体系

软件测试分类

黑盒测试

• 又称数据驱动测试
• 完全不考虑程序内部结构和内部特性
• 注重于测试软件的功能需求
• 只关心软件的输入数据和输出数据

白盒测试

• 研究产品内部的源代码和程序结构
• 单元测试就是白盒测试的一种

灰盒测试

• 对白盒测试和黑盒测试的结合

自动化分层测试体系

单元测试方法

1. java
   • JUnit
   • TestNG
2. Python
   • unittest
   • pytest

接口测试

• 一般称作API。
• 是针对软件对外提供服务的接口的输入输出进行测试。
• 检查接口参数传递的正确性，接口功能实现的正确性，输出结果的正确性性，以及对各种异常情况的容错处理的完整性和合理性。

接口测试方法

• Charles、Fiddler
• postman
• Jmeter
• loadRunner
• python：Requests、HttpRunner
• Java：HttpClient、RestAssured

UI测试方法

• 手工方法：人工查看、操作
• 自动化方法
  • web：selenium
  • app：appium

常用测试平台

测试用例管理和bug管理平台

• jira：推荐方案，定制性很强
• redmine：推荐方案，开源，活跃，定制性很强
• testlink：流行的测试用例管理平台，体验不太好
• 其他：tapd，云效，禅道，gitlab，在线协作文档
• 无协作模式：excel，思维导图

代码管理平台

• gitlab：可本地部署的git代码管理平台，行业标准
• subversion：svn管理，已经过时
• github：开源项目运作
• bitbucket：与jira同属同一家公司altassian

持续集成与持续交付管理平台

• jenkins：持续集成与持续交付的主流平台
• gitlab runner：gitlab的持续交付方案
• github action：github的开源方案
• 自建devops平台：企业定制平台，tapd，云效等

使用jenkins完成 CI/CD

• 研发
  1. 构建、单元测试+覆盖率分析
  2. 自动化代码审计
• 运维：自动化部署
• 测试：
  1. 接口测试
  2. UI自动化测试
  3. 专项性能测试
  4. 性能测试、安全测试

黑盒测试方法论

常用测试方法

• 等价类划分
• 边界值分析
• 因果图
• 判定表
• 决策树
• 探索式测试

白盒测试方法论

白盒测试的度量

• 根据待测产品的内部实现细节来设计测试用例
• 白盒测试的执行手段是可以涵盖单元测试、集成测试等
• 使用代码覆盖率来作为白盒测试的主要度量指标

代码覆盖率常见概念

• 语句覆盖：每行代码都要覆盖至少一次
• 判定覆盖：判定表达式的真假至少覆盖一次
• 判定/条件覆盖：判定覆盖与条件覆盖都必须覆盖
• 条件组合覆盖：判定表达式中的所有条件组合都需要覆盖
• 分支覆盖：控制流中的每条边都要被覆盖一次
• 路径覆盖：所有的路径都要尽量覆盖
• 指令覆盖：一行代码会被编译为多条指令，尽可能地覆盖所有指令
• 方法覆盖：每个方法至少要被覆盖一次
• 类覆盖：每个类至少被覆盖一次

覆盖率统计工具

• emma
• cobertura
• jacoco

流程覆盖

• 利用代码执行流代表流程
• 流程覆盖用路径覆盖率表达
• 对流程进行裁剪获得一个适合业务的小规模的业务子集
• 流程覆盖率=测试经过的路径/业务子集路径

精准化测试

• 代码调用链与黑盒测试用例的关联
• 根据代码变更自动分析影响范围
• 黑盒测试过程中借助代码流程覆盖数据知道探索式测试
• 利用线上数据推导有效测试用例
• 代码流程分析与覆盖率统计

测试经典书籍

• 《全程软件测试》
• 《探索式测试》
• 《探索式软件测试》
• 《google测试之道》
• 《持续交付1.0》
• 《持续交付2.0》
• 《不测的秘密》