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.项目里程碑
| 任务 | 开始时间 | 结束时间 |
|---|---|---|
| 需求了解 | ||
| UC评审 | ||
| 设计评审 | ||
| 测试用例设计 | ||
| TC评审 | ||
| 自动化开发/测试工具开发 | ||
| 冒烟测试 | ||
| 功能测试 | ||
| 性能测试 | ||
| 第一轮回归测试 | ||
| 第二轮回归测试 | ||
| 预发布验证 | ||
| 发布 |
6.测试资源
6.1人力资源
列出此项目的测试参与人员及角色
6.2环境资源
1.列出此项目所涉及到的测试环境，包括测试机名名称及用途
2.测试环境部署方案：如果项目涉及环境多且复杂，有需要特殊说明的内容。如环境统一更新时间，部署顺序，注意事项等
7.风险列表
| 序号 | 风险描述 | 影响范围 | 风险系数 | 预防方案 | 备注 |
|---|---|---|---|---|---|
| 1 | 高/中/低 |
测试用例管理
- 搭建jira，在dockerhub上搜索jira，两条命令就能搭建
- 在jira上配置用例与bug的状态及工作流并关联
10 | 实战3
-
用思维导图梳理测试需求的注意事项：
1.部分功能可用接口mock辅助测试
2.注意测试的范围，不要掺杂其他功能的测试，导致测试重点偏离
3.思维导图可通过编程的方式，自动生成用例和流程图
4.不要在case中设计大量针对于输入框的异常用例，如大量的特殊字符，只需一两种异常情况即可；偏离业务流程、正常用户不会遇到的场景用例尽量少设计
5.不要按页面划分模块，要按功能划分模块
6.文字描述不要太多 -
jira配置
1.问题类型、工作流、界面、字段的配置
2.基于jira强大的自定义功能，我们可以搭建bug流程管理、用例流程管理、上线流程管理
网友评论