SnapPay Developer Documents
QA质量建议书
- Sean Zhang (Deactivated)
一、概述
QA质量建议书编写的目的是为了规范 “交付验证环节”、“生产验证环节”、“灰度验证环节”及“投产验证环节”进行相应流程执行，尽可能高的保障软件质量。
二、交付验证环节
交付验证环节主要描述在交付环节中甲乙双方的合作和交互流程。
三、生产验证环节
生产验证的测试范围主要限定为“生产环境的测试账号”，将从“环境数据准备”及“业务功能测试”两方面进行。此过程以微智金服开发团队为主，Snappay开发团队为辅，进行相关环节的推动及实施。
只有在“生产验证环节”达到设定的“测试验收标准”后，才可进行后续的“灰度验证环节”；若“生产验证环节”未达到设定的“测试验收标准”，则持续循环此环节，直到到达“生产验证测试验收标准”为止。
建议生产上线时间必须为商户交易量低峰期进行上线，在凌晨进行操作，如果验证不通过必须回滚本次上线内容。
3.1 测试范围
生产验证的测试范围主要限定为“生产环境的测试账号”。
3.2 生产验证流程
3.3 测试资源配置
测试资源配置按照对应项目的急迫程度进行相关测试活动，一定要至少2人进行交叉测试。根据具体的项目进行具体的资源和人力划分。
序号 | 测试时间工时（天） | 人员配置 | 资源（文档） |
1 | XX | 至少2人 （交叉测试） | 资源：（提供）生产环境相应的操作权限及kafaka日志等 |
下面我们以“QR Invoice项目”为例，具体阐述“微智团队”及“Snappay开发团队”的测试资源配置：
团队名称 | 测试时间工时（天） | 人员配置 | 资源（文档） |
微智团队 | 7 | 2人 （交叉测试） | 资源：（提供）生产环境相应的操作权限及kafka日志等 |
Snappay开发团队 | 10 | 2人 （交叉测试） |
3.4 测试结论
最终，微智团队与Snappay开发、运营团队协商评价本次生产验证是否达到预期验收标准及是否进入“灰度验证环节。”
四、灰度验证
灰度验证实施的前提是必须完成“测试及生产环境”及达到相应的验收标准。此过程主要以Snappay运营、开发团队为主，微智团队为辅进行相关环节的推动及实施。
4.1 测试范围
灰度验证的测试范围主要限定为“生产环境的友好商户”。
4.2 灰度验证流程
4.3 测试资源配置
团队名称 | 测试时间工时（天） | 友好商户数量 | 资源（文档） |
友好商户 | （例如）7 | （例如）20+ |
4.4 测试结论
最终，微智团队与Snappay开发、运营团队协商评价本次生产验证是否达到预期验收标准及是否进入“投产验证环节。”
五、投产验证
投产验证实施的前提是必须完成“灰度验证”及达到相应的验收标准。此过程主要以Snappay运营、开发团队为主，微智团队为辅进行相关环节的推动及实施。
5.1 测试范围
投产验证的测试范围主要限定为“生产环境的全部商户”。
5.2 投产验证流程
5.3 运营问题讨论
Snappay运营、开发团队为主，微智团队3方共同协商对“运营问进行讨论”，后续步骤流程参照《4.2 投产验证》所示，并根据附件【📎运营问题记录.xlsx】填写相关记录。
5.4 结论
最终，微智团队与Snappay开发、运营团队协商评价本次生产验证是否达到预期验收标准及是否完成运营问题修复。
Copyright reserved for SnapPay Inc 2019.