前面的文章中我们为大家介绍了我们软件测试团队在创建之初面临的一些困难和困惑，以及针对这些困难，我们探讨出来的质量体系覆盖图。

前面已经为大家介绍来质量体系覆盖图的“过程部分”，本文我们继续为大家介绍“线上部分”。

讲完过程，我们再一起来看一下线上，线上目前关注比较多的有“产品实际可用性”，它代表的是用户端的感受。首先是总认责时长S1S2 。
比如这个产品可能依赖项比较多，有可能是受中间件影响，有可能是受第三方的授权登录影响，这个我们会在产品的实际可用性中去体现，但是在总认责时长中是不体现的，因为这些故障并不是依靠我们的产品就可以去做改善的，不是我们的产品造成的，这种我们就可以做一些降级。

故障的平均修复时长方面，目前我们定义的标准是S1、S2的故障在30分钟和45分钟内修复完成S3的故障在120分钟内修复完成。

后面是安全部分，因为我们是在物流行业，在物流行业对安全的要求比较高，因为会涉及到很多个人的隐私，在上线之前我们就会要求做一些安全测试，上线之后出现的高危安全漏洞我们要求在1天内必须修复完成。

改进项指的是这些故障产生之后，改善的任务，是不是在固定的周期内改善完成。以上就是我们2022年的质量体系覆盖图。

目前，每个月我们的各个业务部门会收到这样一份质量报告。

里面会展示我们前面提到的很多质量指标，需求、研发、发布、测试这些环节的指标都会有。业务部门收到这份质量报告后，每个月我们整个项目组的产品、研发、测试、项目经理会坐到一起进行复盘，针对一些异常数据去做一些改进。

后面的文章会继续为大家介绍我们软件测试质量团队管理的其他部分，欢迎大家继续关注。