测试质量从几个维度进行分析：
- 从线上问题说明测试质量
- 测试用例执行情况
- Bug问题一般性描述(将问题进行归类总结)，整理出一套常见问题的列表。
- 自动化测试的介入，能满足业务测试中的多少场景，自动化用例覆盖度。
接下来我从这几个维度说明简单拆解测试质量。
1.从线上问题说明测试质量
项目上线之后产生了问题不可怕，可怕的是这个bug影响面非常广。举个我之前公司犯得一个低级错误。
项目上线之后，有个会员系统，如果是充值了我们的会员，才可以下载会员对应的付费资料，由于开发同学没有考虑，导致上线之后，可以通过接口直接抓取付费资料，导致付费资料可以不用通过付费就可以下载。
所以，我说，线上问题说明测试质量。这个问题如果一直没有发现，那可能导致的将是”任何一个用户都可以下载付费资料”。
所以，测试没有发现问题，开发没有关注这类问题，可能就会给公司带来实际的经济损失。
此外，线上问题从另一方面说明我们需要在一些不同的维度去保证质量，而这些并非产品提出的产品需求，我们也需要进行其他维度的测试。
2.测试用例执行情况
其实严格的来说应该是测试用例的覆盖度，测试用例不在于多，而在于对功能点的描述，测试场景的因果图描述，测试条件的判断等情况下功能是否正常，产品是否有规范说明。测试用例如果能覆盖到大部分的场景和业务，那么测试质量可能会明显的提升，只不过因为问题提前暴露出来，所以对测试质量的把控并不是很明显，但是，确实这块是比较关键的。
3.Bug问题一般性描述(将问题进行归类总结)，整理出一套常见问题的列表。
常见问题的分类汇总是非常重要的，还有一些功能测试点的整理也是。
工作几年后还是同样的业务，没有总结归纳，是不是？
所以将这些问题进行归纳整理，将某一类功能测试点也进行相应的归类，比如：像第三方分享，可以设计一套通用的测试用例进行模板化的测试，然后可以着重对这一种类型的进行测试维度的扩展。
4. 自动化测试的介入，能满足业务测试中的多少场景，自动化用例覆盖度。
自动化测试已经是当前测试行业中一项必备的技能了，所以，从技术角度看测试用例可以满足多少场景，总的自动化用例是多少，UI自动化、接口自动化相辅相成，实现的功能业务覆盖可以达到哪些标准，这从一方面说明我们测试的点有多少，可以保证哪些测试场景的正常或没有问题。
测试质量从几个维度考虑最终提现出来就是：测试用例的覆盖度或者能满足业务功能的多少场景。