01 | 软件开发流程与项目管理

软件开发步骤

• 需求分析
• 概要设计：描述系统的处理流程、组织结构、模块划分、功能分配、接口设计、运行设计、数据接口设计、异常处理设计，为详细设计提供基础
• 详细设计：描述具体模块的主要算法、数据结构、类的层次结构和调用关系、说明每个模块或子程序的设计考虑如何
• 编码：理想项目中，编码时间应占用整个研发时间的三分之一左右，不要超过二分之一
• 测试
• 软件交付：安装手册、设计指南、测试报告等
• 验收
• 维护：监控软件运行的情况

软件开发流程演变

传统瀑布模型>>敏捷开发模型>>DevOps开发模型

敏捷开发模型（Scrum）

产品BACKLOG：按照商业价值排序的需求列表，体现形式为用户故事

SPRINT计划会议：经讨论、分析、估算产出SPRINTBACKLOG，即任务列表

3个角色：产品负责人（Product Owner）、Scrum Master、开发团队

3个工件：产品Backlog、SpringBacklog、产品增量

5个事件：Sprint（迭代周期，包含后面4个事件）、Sprint计划会议、每日站会、Sprint评审会议、Sprint计划会议

5个价值：承若（愿意对目标作出承诺）、专注（把你的心思和能力用到你承诺的工作上去）、开放（项目中的一切开放给每个人看）、尊重（每个人都有他独特的背景和经验）、勇气（有勇气作出承诺，履行承诺、接受别人的尊重）

DevOps开发模型

重视开发人员（Dev）和运维（Ops）之间沟通合作。通过自动化“软件交付”和“架构变更”的流程，使得构建、测试、发布软件能够更加快捷、频繁和可靠。

持续开发：用到的工具有jira、git/svn、Ant/Maven/Gradle

持续测试：用到的工具有Selenium、Appium、Pytest、TestNG、Docker

持续集成（Continuous integration，缩写为CI）：新功能代码与现有代码集成的阶段。每次集成都通过自动化的构建（编译、发布、自动化测试），根据测试结果确定新代码和原有代码能否正确集成在一起。

持续部署（Continuous delivery，缩写为CD）：将代码部署到生产环境。让软件的构建、测试、发布更快及更频繁，减少软件开发的成本与时间。

持续监控：监控软件的性能来提高软件的质量，工具有ELK Stack。

02 | 测试流程体系

单元测试>>集成测试>>冒烟测试>>系统测试>>验收测试

单元测试（开发人员）

• 模块接口测试：验证所测模块参数的个数、属性、顺序
• 局部数据结构测试：保证临时存储在模块内的数据在程序执行中完整、正确
• 路径测试：测试模块中重要的执行路径
• 错误处理测试
• 边界测试

集成测试（开发人员）

软件系统集成过程中所进行的测试，目的是模块间的接口是否正确。

• 验证穿越各模块接口的数据是否丢失
• 验证各模块组织起来后能否达到预期的功能
• 验证一个模块的功能是否对另一个模块的功能产生不利影响
• 验证全局的数据结构是否有问题
• 验证单个模块的误差积累起来是否会放大

冒烟测试（测试人员）

对软件基本功能快速验证的策略

系统测试（测试人员）

• 功能测试
• 性能测试
• 安全测试
• 兼容测试

验收测试（用户/需求方）

• 验证功能是否正确
• 安全可靠性
• 易用性
• 兼容性
• 埃尔法测试（内部测试）
• 贝塔测试（公测）

软件测试模型

• V模型

  
  
  image.png

• W模型（测试贯穿整个研发周期，测试范围不局限于软件程序，还包括需求、UI）

  
  
  image.png

• H模型（要求比较高，很少用）

  
  
  image.png

系统测试工作流程

用例评审：需两轮，第1轮是组内评审，第2轮是产品与研发共同评审

image.png

bug管理流程

image.png

测试左移

往测试之前的开发阶段移

质量保障手段：

• 代码评审：同行评审，偏人工
• 代码审计：发现程序错误、安全漏洞、违反编码规范，偏自动化
• 单元测试
• 自动化冒烟测试：测试人员为开发人员提供自动化测试脚本
• 研发自测：测试人员为开发人员提供冒烟用例

测试右移

往发布之后移

线上监控：

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

03 | 测试技术体系

接口测试内容

• 业务逻辑功能：正常场景、异常场景
• 边界值分析测试：业务规则边界分析、输入输出参数边界分析
• 参数组合测试
• 异常情况测试：重复提交、并发测试、事物测试、分布式测试、环境测试
• 性能测试：响应时间、吞吐量、并发数、服务器资源使用率
• 安全测试：敏感信息是否加密、SQL注入

04 | 常用测试平台

建议用例和bug管理用同一个平台

中国80%的公司用Jira，其他20%的公司用redmine、禅道等，腾讯的TAPD也不错，我们公司用的就是TAPD。

05 | 黑盒测试方法

黑盒测试方法

• 等价类划分法
• 边界值分析法
• 错误推测法：基于经验和直觉推测有可能存在的错误，如输入空格、0
• 因果图法（很少用）
• 判定表驱动法：适合于检查程序输入条件的各种组合情况
• 决策树
• 探索式测试

06 |白盒测试方法

代码覆盖率常见概念

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

覆盖率统计的工具

• emma
• cobertura
• jacoco：java最流行的覆盖率统计工具

流程覆盖

...

精准化测试

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

07 | 测试经典书籍

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

08 | 实战1

质量保证工作实施的三大阶段

• 测试左移：研发阶段的质量保证
• 测试：测试阶段的测试流程
• 测试右移：发布后的质量监控

app交付策略

• 内部交付
  1.Jenkins自动打包
  2.提供内部网站下载入口
• 灰度交付
  1.使用fir.im bugly testflight 服务
• 正式发布
  1.Android：渠道包打包推送
  2.IOS：上传app store

常见后端发布机制

不同的环境对应不同的代码分支

• 代码编译和发包构建
  1.后端打包 mvn rpm docker
  2.移动端打包 gradle cocospod
• 环境构建
  1.docker等容器技术
  2.Jenkins等自动构建和部署平台
• 测试推送
  1.后端升级自动触发接口测试
  2.测试结果自动推送运维平台决策

建立测试准入机制

代码合并到测试分支，打tag时，持续集成根据打的tag自动打包并自动化测试

一般两周发布一个版本，测试时间通常只有3天，时间很紧张，故新功能我们靠人工解决，老功能靠自动化解决

• 建立测试的准入机制
  1.自动对研发、测试分支进行打包
  2.自动对研发和测试分支进行冒烟测试
  3.打回 or 接受
• 建立版本管理机制
  1.版本号的使用规范 三位+四位
  2.根据版本号和commit定位和对比代码
  3.对每个版本的变更自动采集提交记录

什么时候编写自动化测试用例呢？

若提测前能够接触到研发中版本，可以在提测前编写自动化测试用例；若接触不到，后期补上也可以，用作回归测试

09 | 实战2

测试前沟通与分析

• 业务知识梳理
  1.业务架构：业务模块之间的关系
  2.技术架构：使用的技术栈（语言、框架、数据库、通讯协议等）
  3.组织架构：协作团队的组织关系
  4.数据架构：数据的关联关系（如用户有多少属性）
• 测试架构
  1.业务架构：业务架构与流程图分析
  2.测试活动管理：测试用例管理平台、测试执行分析、bug管理平台、测试报告与测试分析图表
• 测试分析工具
  1.vscode + plantuml；https://plantuml.com/zh/；时序图（重要）、用例图、活动图（最重要）、组件图
  2.思维导图：思维导图可以很好的覆盖功能，但无法很好的覆盖流程时序

测试计划

以邮件或wiki方式通知相关人

1.项目概述

对该项目业务需求做简要描述，项目的主要功能及实现方式，项目名称、版本、背景

2.测试目标

对项目的业务需求做简要描述（如：要达到的功能/性能的概述，功能、性能、稳定性和进度上需要满足的要求）

3.测试范围和重点

以项目的角度分析测试范围和重点

4.测试策略

对于每种测试，制定测试策略时都需要考虑思路、方法、工具、技术等。
对于不能测试的功能点需列明，是否有替代的解决方案（比如开发自测、产品或服务人员协助测试）

4.1功能测试

功能测试策略。

4.2性能测试

性能测试策略。

4.3自动化测试

自动化测试策略，包含测试工具开发。

5.项目里程碑

6.测试资源

6.1人力资源

列出此项目的测试参与人员及角色

6.2环境资源

1.列出此项目所涉及到的测试环境，包括测试机名名称及用途
2.测试环境部署方案：如果项目涉及环境多且复杂，有需要特殊说明的内容。如环境统一更新时间，部署顺序，注意事项等

7.风险列表

测试用例管理

• 搭建jira，在dockerhub上搜索jira，两条命令就能搭建
• 在jira上配置用例与bug的状态及工作流并关联

10 | 实战3

• 用思维导图梳理测试需求的注意事项：
  1.部分功能可用接口mock辅助测试
  2.注意测试的范围，不要掺杂其他功能的测试，导致测试重点偏离
  3.思维导图可通过编程的方式，自动生成用例和流程图
  4.不要在case中设计大量针对于输入框的异常用例，如大量的特殊字符，只需一两种异常情况即可；偏离业务流程、正常用户不会遇到的场景用例尽量少设计
  5.不要按页面划分模块，要按功能划分模块
  6.文字描述不要太多

• jira配置
  1.问题类型、工作流、界面、字段的配置
  2.基于jira强大的自定义功能，我们可以搭建bug流程管理、用例流程管理、上线流程管理