前言
上个月整理的测试体系，可以从整个测试层面梳理认知。那么具体对应到项目中的时候，怎么快速了解到本项目的测试方案， 对于一个新来者，或者一个其他业务组的测试来说，也是非常重要的。 当你疲于为了不同的交付产品，打乱原有项目的迭代节奏，临时组件很多临时数据、报告等的时候；当你一遍遍给不同的人， 讲述你们组的测试流程，测试方案的时候，是非常有必要整理一个标准化的测试方案的，也可以供其他组参考。
一、引言
1. 介绍
行业配置平台提供了一整套管理配置系统，主要面向数据维护人员，编辑维护知识库的有效性，其中系统配套提供数据挖掘和运营工具， 通过机器学习的方式挖掘在线数据，提高运营人员训练机器人和维护支持库的效率。
2. 背景
行业平台作为多个产品项的配置入口，难免会需要支持多个交付项目，为了更好让其他小组的成员快速了解行业配置平台的测试方案， 同时也让本小组的成员在测试时候有一个宏观指引，特此拟定此方案，欢迎补充。
二、流程
测试的整体流程：测试准备>测试计划－>测试需求－>测试用例－>测试执行－>测试缺陷管理－>测试报告总结->测试度量->回顾总结， 目前都是通过TAPD进行管理，时刻需要关注：
- TAPD Story的【待提测】【测试通过】【测试不通过】状态
- TAPD Bug的各个状态，以及相关字段
- TAPD 提测单的各个状态，以及关联关系
- TAPD 测试报告
具体事项，按照软件开发的生命周期，进行分段描述：
1. 需求阶段
- 测试人员需要参与需求评审，给出合理的建议
- 初步估算需求所需的测试人力
- 根据开发的排期，及时给出测试人力排期计划（用于后续在对应的时间点，Check进入测试时间是否延期）
2. 开发阶段
- 提前编写测试用例，便于产品进行核对确认和补充，便于开发人员进行自测
- 根据测试人力排期计划表，Check开发任务是否仍在开发中
3. 测试阶段
3.1 功能测试
- 严格根据提测任务进行测试，检查提测任务是否符合规范（需求状态、必要信息）
- 测试期间发现Bug，根据提单规范及时提TAPD单，填写必要信息，填写优先级和影响程度，并分配给开发同学，针对需求拉小群
- TAPD发送测试报告，注意需求、提测任务、Bug的TAPD状态
3.2 回归
- 针对功能测试发现的Bug，在开发解决完Bug后，进行回归
- 跟进Bug进度，及时处理拒绝的Bug，分配对应处理人
- 开发解决完Bug，需要核对Bug产生原因；挂起的Bug，需要产品、开发、测试三方达成一致
- 遇到阻塞性问题，重点提出，尤其是跨小组跨区域的，及时找人
3.3 集成
- 原则上，功能测试通过了，才能进行迭代集成测试；有例外情况，需要开发、产品达成一致
- 根据Bug数量情况，按需组织Bug Review会议，决定是否解决、什么时候解决
- TAPD发送测试报告，关系到是否允许上线
4. 灰度阶段
4.1 验证
- 验证只能在灰度上验证的Bug
4.2 Showcase
- 录屏留存，便于业务分享
- 记录会议中发现的问题，线下转为TAPD单进行跟踪
5. 线上阶段
- 产品/用户线上发现问题，后续改正之后，测试人员需要进行验证
- 针对本次迭代，进行Bug情况分析，收集意见，进行改进
三、测试能力
1. 单元测试
单元测试，由开发人员编写，纳入流水线度量统计。
具体编写，可参考:
2. 接口测试
接口测试，源代码层面由开发人员编写，纳入流水线度量统计。 星海层面目前暂时由开发和测试共建，后续测试人力补足之后，逐步承担起星海层面的测试用例编写。
在星海上，如果采用TAF的方式调用，是直接访问的具体服务；如果采用HTTP接口，需要传入action_type，经由CGI网关进行访问服务。 如果想通过HTTP接口，直接访问具体服务，会被登陆部分进行拦截。
3. 功能测试
功能测试，是针对于每个需求的功能点进行的测试。
根据开发创建的提测单，结合事先编写的测试用例，进行功能测试。需要从UI、功能、易用性、安全、网络、稳定、兼容等方面进行测试。
4. 集成测试
各个需求的功能测试结束之后，当代码进行合入主干时候，为了确保各个需求之间、新代码和旧代码之间的兼容性，需要对系统所有的 测试用例再进行一次集成的验证。考虑到所有的用例比较多，对于旧有模块的用例，可以挑选P0级别和基本主路径的用例，进行验证。
5. 性能测试
行业平台分为用户端和管理端，两个层面的要求不同，规范化的压测还在进行中，详情可参考【性能测试】子页面。
四、测试工具平台
- 接口/压力测试平台：星海，内网链接，隐藏处理
- 免费邮箱：https://9em.org/
- 接口工具：postman
- 测试管理工具：内网链接，隐藏处理
- 白盒测试工具：单元测试框架
- 代码扫描：codedog，内网链接，隐藏处理
- 持续集成工具：codingci，内网链接，隐藏处理
五、测试用例
测试用例分为手工测试的用例和自动化测试的代码用例。
1. 手工测试
手工测试的用例，需要按照合理的方式设计之后，存档到行业平台的用例集里，目前是Excel维护。 后续根据测试阶段发现问题的频繁程度，合理调整测试用例集里P0级别的功能点。
2. 自动化测试
目前行业平台测自动测试，只有接口测试和压力测试，都存放在星海平台上进行管理。
六、测试数据
测试环境的数据，每周有脚本自动从生产环境同步过来：
- 实现测试环境DB和正式环境DB(沙箱)一致。
- 避免语义灰度沙箱数据库被污染。
目前实行举手机制，设置白名单。如果需要账户下的数据不被覆盖，需要开发同学进行提前举手。
七、测试报告
1. 功能测试报告
- 结论：测试是否通过
- 概述：描述测试包含的覆盖情况（场景、分支等）
- 性能：目前压力测试还在建设中，后续需要按照需求，把压测情况包含在功能测试报告中
- 需求：关联此次测试的需求
- 问题：关联此次测试发现的所有BUG
2. 集成测试报告
- 集成测试报告，关系到本迭代是否能够上线
- 集成测试
3. 性能测试报告
如果需要单独进行一轮性能测试，需要单独的发送性能测试报告，目前是根据实际情况发送邮件说明小结，规范正在建设中
4. 归因分析报告
目前暂无定期的ODC分析报告，后续建立以迭代为单位的，ODC分析报告，主要包括：
- 分析结论
- 开发质量评估
- 测试质量评估
ODC分析方法，可参考：
- BUG根因分析
- [【ODC分析报告】腾讯地图iOS客户端]（内部文章无权访问，后续单独写一篇）
八、验收标准
验收主要从整体通过率、高优先级Bug通过率、性能等多个维度考察。
验收规则：
- 必现严重/致命问题必须解决
- 遗留的一般问题挂起率<5%
- 总遗留问题<10%
- 问题最终的状态只能是挂起/关闭（含转需求关闭），或转至后续迭代优化
如果特殊情况，需要产品、测试、开发三方达成一致，并添加对应的评论等。
九、度量
度量主要分为两个部分，一部分在Grafana进行统计分析，另外一部分结合TAPD自身的报表功能，以及迭代里面的趋势图，进行观测。
1. Grafana
主要指标说明：
| 序号 | 指标 | 说明 |
|---|---|---|
| 1 | 需求全周期LeadTime | 测试通过时间 - 进入开发中时间or创建时间 |
| 2 | 开发阶段LeadTime | 待提测时间 - 进入开发中时间or创建时间 |
| 3 | 测试阶段LeadTime | 测试通过时间 - 待提测时间 |
| 4 | Velocity | 本迭代进入开发之后的预估故事点 |
故事点说明：
| 故事点 | 1 | 2 | 3 | 4 | 5 |
|---|---|---|---|---|---|
| 人天 | T<=1 | T<=3 | T<=5 | T<=8 | T<=14 |
2. TAPD
主要指标说明:
| 序号 | 指标 | 说明 | 查看路径 |
|---|---|---|---|
| 1 | 缺陷解决率 | 已解决的缺陷/缺陷总数 | 迭代仪表盘 |
| 2 | 缺陷平均解决时间 | 缺陷从提交到修复的平均时间 | 迭代仪表盘 |
| 3 | 严重缺陷百分比 | 严重缺陷/总缺陷 | 迭代仪表盘 |
| 4 | 缺陷有效率 | 无效的缺陷/缺陷总数 | 报表-缺陷有效率 |
| 4 | 缺陷状态分布 | 各个阶段的状态占比 | 报表-缺陷状态分布 |
| 5 | 缺陷产生原因 | 各个原因的占比 | 报表-缺陷产生原因 |