一. 软件测试基础概念
1.1 软件测试定义
- 通过手工或者工具对 “被测对象” 进行测试；
- 验证实际结果与预期结果之间是否存在差异。
1.2 软件测试作用
- 通过测试工作可以发现并修复软件当中存在的缺陷，从而提高用户对产品的使用信心；
- 测试可以降低同类型产品开发遇到问题的风险。
1.3 软件缺陷
- 软件缺陷被测试工程师和开发工程师们称作bug；
- 软件缺陷会导致软件不能正常运行，它的存在会一定程度上导致软件不能满足用户的需求，甚至有可能破坏或者泄露用户的重要数据。
1.4 软件测试原则
- 测试显示缺陷的存在；
- 穷尽测试是不可能的；
- 测试尽早介入；
- 缺陷集群性（2/8原则）；
- 杀虫剂悖论；
- 测试活动依赖于测试内容；
- 没有错误就是好，这是谬论。
1.5 软件测试对象
- 需求分析阶段：需求文档、接口文档；
- 编码实现阶段：源代码；
- 系统功能使用：软件程序。
1.6 测试用例
- 为特定的目的而设计的一组测试输入、执行步骤和预期结果，以便测试产品是否满足某个特定需求的文档。
二. 软件开发流程
2.1 软件
- 软件是与计算机系统操作有关的计算机程序、可能有的文档和数据。
2.2 软件生命周期
2.3 软件开发流程
- 为了使软件开发的工作系统化并且可控制；需要采用合适的软件开发模型和开发过程管理所有的活动。
软件开发模型：
- 瀑布模型;
- 敏捷开发模型;
- DevOps 模型。
2.4 瀑布模型
- 软件开发的各项活动严格按照线性方式进行；
- 当前活动接受上一项活动的工作结果；
- 当前活动的工作结果需要进行验证。
优点：
- 开发的各个阶段比较清晰；
- 强调早期计划及需求调查；
- 适合需求稳定的产品开发。
缺点：
- 早期的错误可能要等到开发后期的阶段才能发现；
- 由于开发模型是线性的，增加了开发的风险。
2.5 敏捷开发模型
- 使用于需求频繁变化和需要快速开发的场景：XP、SCRUM。
XP-极限编程：
SCRUM
- 敏捷模型总结：增量迭代、小步快跑。
2.6 DevOps
- 2.6.1 DevOps示意图
- 2.6.2 DevOps生命周期
- 持续开发；
- 持续测试；
- 持续集成；
- 持续部署；
- 持续监控。
-
2.6.3 DevOps对发布的影响
- 减少变更范围；
- 加强发布协调；
- 自动化。
-
2.6.4 CI/CD
-
持续集成（Continuous Integration，CI）：
- 一种软件开发实践；
- 团队开发成员每天可能会发生多次集成；
- 每次集成都通过自动化的构建（包括编译、发布、自动化测试）来验证；
- 根据测试结果确定新代码和原有代码能否正确的集成在一起。
-
持续交付（Continuous Delivery，CD）：
- 是一种软件工程手法；
- 让软件产品的产出过程在一个短周期内完成；
- 保证软件可以稳定、持续的保持在随时可以发布的状况；
- 目标：（1）让软件的构建、测试与发布变得更快以及更频繁；（2）减少软件开发的成本与时间，减少风险。
-
-
2.6.5 CD与DevOps的关系
- DevOps的范围更广：
- DevOps是软件交付过程所设计的多个团队之间的合作；
- 并且将软件交付的过程自动化。
- 持续交付是一种自动化交付的手段：
- 关注点在于将不同的过程集中起来；
- 并且更快、更频繁地执行这些过程。
- 总结：DevOps可以是持续交付下的一个产物，持续交付的成果直接汇入DevOps模型。
- DevOps的范围更广：
三. 软件测试模型
3.1 V模型
- V 模型是瀑布模型的一种改进；
- V 模型标明了测试过程中的不同阶段。
3.1.1 V模型步骤
- 需求分析：需求文档；
- 概要设计：系统架构、模块划分、模块与模块之间的接口；
- 详细设计：模块内部实现的逻辑和方法；
- 编码：用代码实现设计的内容；
- 单元测试：测试代码中最小模块是否符合详细设计；
- 集成测试：测试各个模块组成到一起后是否可以正常使用；
- 系统测试：测试已经集成在一起的产品是否符合需求文档中的要求；
- 验收测试：测试产品是否符合用户的需求。
3.1.2 V模型的优缺点
-
优点：
- 既有底层测试又有高层测试；
- 将开发阶段清楚的表现出来，便于控制开发的过程。
-
缺点：
- 容易让人误解为测试是在开发完成之后的一个阶段；
- 由于它的顺序性，当编码完成后，正式进入测试时，这是发现的一些 bug 可能不容易找到其根源，并且代码修改起来很困难；
- 如果需求变更较大，导致要重复变更需求、设计、编码、测试，返工量大。
3.2 W模型
- W模型明确表示出了测试与开发的并行关系；
- W模型中测试伴随着整个软件开发周期，并且测试的对象不仅仅是程序，需求和设计同样要测试
3.2.1 W 模型优缺点
-
优点：
- 将测试贯穿到整个软件的生命周期中，且除了代码要测试，需求、设计等都要测试；
- 更早的介入到软件开发中，能尽早的发现缺陷并修复；
- 测试与开发独立起来，并与开发并行。
-
缺点：
- 无法支持迭代的开发模型；
- 对有些项目，开发过程中根本没有文档产生，故 W 模型无法使用；
- 对于需求和设计的测试技术要求很高，实践起来很困难。
3.3 H模型
- 软件开发中需求、设计、编码等活动被分阶段执行，但是实践中，他们并不是完全串行的，他们之间更多时候是交叉进行的，更多的是迭代执行；
- 把测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。
3.3.1 H模型优缺点
- 优点：
- 软件测试完全独立，贯穿整个生命周期，且与其他流程并发进行；
- 软件测试活动可以尽早准备、尽早执行，具有很强的灵活性。
- 缺点：
- 测试就绪点分析困难；
- 对于整个项目组的人员要求非常高。
四. 软件测试工作流程
传统测试流程
系统测试流程
Bug管理流程
五. 测试左移和测试右移
5.1 测试左移
- 左移是往测试之前的开发阶段移；
- 测试团队在软件开发周期早期就开始介入；
- 对代码进行测试；
- 从发现 bug 到预防 bug。
测试左移 - 质量保障手段
- 代码评审：code review；
- 代码审计；
- 单元测试；
- 自动化冒烟测试；
- 研发自测。
5.2 测试右移
- 右移是往发布之后移；
- 产品上线后进行线上监控。
测试右移 - 线上监控
- 闭环的线上问题反馈 - 检查 - 解决 - 更新流程；
- 更便捷的日志查看、回传服务；
- 丰富有效的 log，便于问题的快速定位；
- 丰富的监控指标（例如业务异常点指标）；
- 业务便捷（例如短信发送等）；
- 关键指标每日监控（服务器指标）；
- 生产数据监控（警报）。
六. 测试技术体系
6.1 软件测试分类
6.1.1 黑盒测试
- 黑盒测试又称数据驱动测试；
- 完全不考虑程序内部结构和内部特性；
- 注重于测试软件的功能需求；
- 只关心软件的输入数据和输出数据。
6.1.2 白盒测试
- 白盒测试研究产品内部的源代码和程序结构；
- 单元测试就是白盒测试的一种。
6.1.3 单元测试
- Java
- JUnit
- TestNG
- Python
- unittest
- pytest
6.1.4 接口测试
- 接口全称Application Programming Interface，一般称API。
- 接口测试是针对软件对外提供服务的接口的输入输出进行测试。
- 检查接口参数传递的正确性；
- 接口功能实现的正确性；
- 输出结果的正确性；
- 对各种异常情况的容错处理的完整性和合理性。
6.1.5 接口测试方法
- Charles、Fiddler
- postman
- Jmeter
- LoadRunner
- python：Requests、HTTPRunner
- Java：HttpClient、RestAssured
6.1.6 UI测试
- 手工方法：人工查看、操作。
- 自动化方法：
- Web：Selenium；
- APP：Appium。
6.2 自动化分层测试体系
- 70%单元测试；
- 20%服务测试；
- 10%用户界面测试。
七. 常用的测试平台
7.1 测试用例管理
- JIRA：推荐方案、定制性很强；
- RedMine：推荐方案，开源、活跃、定制性很强；
- TestLink：流行的测试用例管理平台，体验不太好；
- 其他：Tapd、云效、禅道、GitLab、在线协作文档；
- 无协作模式：Excel、思维导图。
7.2 Bug管理平台
- 通常与用例管理平台一致；
- 测试用例、Bug都可以使用issue表达；
- 关联关系设定；
- 测试用例与Bug的属性设定。
7.3 代码管理平台
- GitLab：可本地部署的Git代码管理平台，行业标准；
- SubVersion：SVN管理，已经过时；
- GitHub：开源项目运作；
- BitBucket：与JIRA同属一家公司Altassian。
7.4 持续集成管理平台
- Jenkins：持续集成与持续交付的主流平台；
- GitLab Runner：GitLab的持续交付方案；
- GitHub Action：GitHub的开源方案；
- 自建DevOps平台：企业定制平台，Tapd、云效等。
7.4.1 Jenkins平台
7.4.2 持续集成与持续交付
- 研发：
- 构建、单元测试+覆盖率分析；
- 自动化代码审计。
- 运维：自动化部署。
- 测试：
- 接口测试
- UI自动化测试
- 专项测试自动化
- 性能测试、安全测试
7.5 流程管理平台
7.5.1 JIRA管理平台
- 特点：
- 推荐方案；
- 定制性很强。
- 基本概念：
- Project项目
- Issue问题
- Field字段
- Workflow工作流
- Screen视图
7.5.2 JIRA平台管理测试流程
- 用例管理：
- 1.创建测试用例管理项目；
- 2.录入用例；
- 3.测试用例状态转化。
- Bug管理：
- 1.创建Bug管理项目；
- 2.从用例关联到Bug；
- 3.在项目中录入Bug；
- 4.Bug状态转化。
八. 项目管理与跨部门沟通合作
8.1 项目管理
8.1.1 需求阶段
| 项目经理 | 产品 | 研发 | 测试 |
|---|---|---|---|
| 活动 | 活动 | 参与 | 参与 |
| 1. 在项目管理工具中建立项目目录；2. 分析项目所需资源、风险等；3. 预估项目周期。 | 1. 收集整理需求 | 1. 需求分析；2. 环境分析 | 1. 需求分析；2. 环境分析 |
| 产出 | 产出 | ||
| 1. 项目计划（大致时间规划） | 1. 需求文档 |
8.1.2 设计阶段
| 项目经理 | 产品 | 研发 | 测试 |
|---|---|---|---|
| 活动 | 活动 | 活动 | 活动 |
| 1. 监控项目进度；2. 组织安排本阶段的评审；3. 任务分解，责任到人；4. 细化项目计划。 | 1. 系统功能设计； | 1. 系统功能技术设计；2. 数据库设计 | 1. 组织测试计划评审 |
| 产出 | 产出 | 产出 | 产出 |
| 1. 项目计划（具体到各个功能） | 1. 系统说明书 | 1. 概要设计文档；2. 详细设计文档 | 1. 测试计划 |
8.1.3 开发阶段
| 项目经理 | 产品 | 研发 | 测试 |
|---|---|---|---|
| 活动 | 参与 | 活动 | 活动 |
| 1.监控项目进度；2.调整人员安排；3.跟踪解决技术难点 | 1.需求细节沟通 | 1.具体功能开发；2.组织code review；3.单元测试 | 1.编写测试用例；2.组织测试盈利评审 |
| 产出 | 产出 | 产出 | 产出 |
| 1.项目计划（更新进度）；2.项目报告进度 | 1.功能代码；2.单元测试代码 | 1.测试用例 |
8.1.4 集成测试阶段
| 项目经理 | 产品 | 研发 | 测试 |
|---|---|---|---|
| 活动 | 参与 | 活动 | 活动 |
| 1.监控项目进度；2.跟踪解决技术难点 | 1.需求细节沟通；2.Bug修改方案 | 1.集成测试；2.修改Bug | 1.支持研发进行集成测试；2.准备测试数据；3.准备自动化测试用例 |
| 产出 | 产出 | 产出 | 产出 |
| 1.项目报告进度 | 1.集成测试报告；2.部署测试环境 |
8.1.5 系统测试阶段
| 项目经理 | 产品 | 研发 | 测试 |
|---|---|---|---|
| 活动 | 参与 | 活动 | 活动 |
| 1.分配Bug；2.跟踪解决技术难点 | 1.需求细节沟通；2.Bug修改方案 | 1.支持测试；2.修改Bug | 1.测试环境搭建；2.补充测试数据；3.功能测试；4.自动化测试 |
| 产出 | 产出 | 产出 | 产出 |
| 1.项目报告进度 | 1.系统测试报告（执行报告）；2.缺陷报告 |
8.2 软件项目管理的方法
- 制定项目计划；
- 执行该计划并监控跟踪管理；
- 项目风险应对与问题解决；
- 项目收尾。
8.3 跨部门沟通协作-与产品沟通
- 需求评审会；
- 在分析需求阶段；
- 在测试用例编写阶段；
- 在测试过程中。
8.4 跨部门沟通协作-与研发沟通
- 在分析需求阶段；
- 在测试用例编写阶段；
- 在测试过程中；
- 在线上监控发现Bug时。
8.5 跨部门沟通协作-上下游测试配合
- 测试计划沟通；
- 环境对接；
- 熟悉业务。
