本文是我在当前项目上设计的质量保障方案，在进行项目信息脱敏后，总结如下。
质量 = 正常工作的软件 + 满足项目干系人的需求
主动性质量管理 –> 预防 + 评审
流程
- 开发流程
- 每一个环节明确的进入退出条件
- 多轮质量反馈机制 ** 开发团队日常的反馈 ** 站会 ** IPM ** 开卡&结卡 ** 客户/用户的反馈 + showcase
- 持续集成/持续部署流程 2.1 加入代码扫描，自动化测试等 2.2 失败处理
- 与上下游方的沟通联调流程
需求
- 需求分析和澄清
- 需求符合INVEST原则，无二义性和歧义性
- PO积极性，能够及时响应和回答
- AC的定义，完工的定义，测试结束的定义
开发实践
- Code Review 代码审查
- Peer Review (via PR) 同行评审
- TDD
- Pairing 结对编程
代码质量
- 静态测试 1.1 统一的编码规范：比如命名规则，注释，代码格式，函数复杂度等 1.1.1 可以结合业界标准。比如Sun Code Convent和Google Style等 1.1.2 使用工具扫描代码。比如JS的ESlint 1.2.3 可以在IDE装相关插件，做到编码时检测 1.2 静态代码扫描 1.2.1 集成到CI流水线中。SonarQube 1.2.2 IDE插件，做到编码时检测
- 动态测试 2.1 前端单元测试 2.2 后端单元测试
风险管理
- 可视化风险
- 及时暴露和管理风险
项目实践
- 定期Retro
- 知识管理
- API文档管理
- 新人培训
- 追求技术卓越
- 面对面沟通
- 集中办公
被动型质量管理 –> 测试 + 检验
质量属性
- 功能性
- 完成度
- 精准度
- 互用性
- 效率
- 并发
- 性能
- 资源利用率
- 吞吐量
- 持久力
- 安全
- 认证
- 授权
- 隐私
- 兼容性
- 应用兼容
- OS兼容
- 硬件兼容
- 向后兼容
- 可用性
- 易学性
- 易操作性
- 可达性
- 可靠性
- 稳定性
- 健壮性
- 可恢复性
- 错误处理
- 数据完整性
- 可维护性
- 可扩展性
- 修复
- 构建
- 可移植性
- 重用
- 可安装性
- 配置
- 升级卸载
测试活动
| 质量属性 | 测试类型 |
|---|---|
| 功能性 | 功能测试、集成测试、探索式测试、用户验收测试、流测试、回归测试 |
| 性能 | 压力测试、负载测试 |
| 安全 | 渗透测试、威胁建模 |
| 兼容性 | 兼容性测试 |
| 可用性 | 用户测试、Alpha测试、Beta测试 |
| 可靠性 | 风险测试、场景测试、域测试(domain testing)、流测试、压力测试 |
| 可维护性 | 单元测试 |
| 可移植性 | 专项测试 |
| 可安装性 | 专项测试 |
测试策略
| SDLC | 测试类型 | 方法 | 框架/工具 | 策略 |
|---|---|---|---|---|
| Code | 单元测试 | 自动化 | Junit, pytest, mocha, jasmine | 采用TDD，覆盖率检查，QA review UT，每次构建在CI执行 |
| Test | 冒烟测试 | 手工/自动化 | webdriver | 针对每次build在CI执行地自动化冒烟测试，在shoulder check环节的冒烟测试，与Build Verification Testing类似，每次build都要通过的测试 |
| Test | 功能测试 (系统测试) | 手工/自动化 | webdriver | 故事卡测试 - 探索式测试，故事卡测试 - 场景验收测试，自动化UI测试，自动化API测试，自动化测试在CI流水线执行，自动化测试也可以单独在CI执行 |
| Test | 集成测试 | 自动化 | Rest assured，pact | 覆盖依赖服务的测试，可以使用mock |
| Test | 性能测试 | 自动化 | locust，gatling | 压力测试，负载测试 |
| Test | 兼容性测试 | 手工/自动化 | Browserstack | 确定产品支持的主流平台和浏览器 |
| Test | 安全测试 | 自动化 | HP Fortify | 渗透测试 |
| Test | 回归测试 | 手工/自动化 | 故事卡缺陷的回归测试，AC的回归测试，相关代码配置改动引起的回归测试，缺陷卡回归测试，上线前的回归测试 - Candidate testing， PVT | |
| UAT | 用户验收测试 | 手工 | 每个故事卡QA测试结束后，需要客户进行在UAT环境进行测试。只有当UAT通过了，才表明这个故事卡done，QA需要在此环节和business进行协调 |
质量度量
- 缺陷统计度量
- 解决率
- 解决时间
- 分布
- 触发原因
- 严重性
- 优先级
- 数量变化趋势
- 覆盖率
- 需求覆盖率
- 故事卡AC覆盖率
- 代码覆盖率
- 函数覆盖数量
- 运行使用到的功能覆盖数量
- 条件覆盖数量
- path覆盖数量
- 自动化测试覆盖率
- 运行通过的测试比率
- 功能稳定程度
- 不同开发阶段的比率
- 运行通过的测试比率
- 兼容
- 支持哪些浏览器
- 移动端支持多分辨率机型
- 代码质量
- 静态代码扫描问题数
- 技术负载率
- 剩余技术负债点数
- 用户/客户反馈
- 线上问题反馈
- 满意度反馈
事后检查处理的代价其实是最高的。质量是规划、设计、建造出来的，不是检查出来的。预防高于检查，预防错误的成本通常比在检查中发现并纠正错误的成本低得多。
如何更好地规划质量管理活动
- 质量规划，明确标准
规划质量，是识别项目及产品的质量要求和标准，并确定用哪些保障方法、改进措施来达到这些标准的过程。
在业务生命周期的不同阶段，质量标准应该是动态变化的
只能结合具体项目和具体阶段的质量诉求，对质量的标准进行合理定义。
其中，你需要特别关注研发过程中的质量保障手段，制定适当的编码规范、提交规范和分支规范，同时设计代码准入标准，确保代码 Review、单元测试、接口验证和 UI 验证等手段与你的项目质量要求相匹配。
- 质量分析，追根溯源
质量分析，是指识别项目运行期间，整体质量上遇到的问题和制约因素，分析根本原因，并制定相应的预防措施和解决方案。
- 每月坚持开线上 Bug 分析会
- 持续进行内部 Bug 分类
- 建立质量大盘，拉通不同业务线或模块的每月 Bug 趋势
- 质量控制，层层卡点
质量控制，就是将一些明确下来的质量规范和做法，真正落地到各个环节。质量控制及卡点行为，是要结合项目的质量要求和团队的质量成熟度，一层一层地加强质量把关和收口
质量管理过程中的工作，你可以从三个方面入手，分别是质量规划，明确项目的质量标准；质量分析，追根溯源，找到质量差距的根本症结；质量控制，在需求到发布的过程中，设置层层卡点来控制质量
