标签：架构设计 业务 评估 必须 自动化测试 接口 用户 splay 机制
不管产品规模是大还是小，结构简单还是复杂，质量评估都不是一件容易的事情。
尽管很难，但质量评估仍然是必需的，因为关系到版本是否能够发布、测试工作是否有效、测试投入是否有价值等。
产品发布之前可以对如下指标进行评估
● Bug
Bug数量、Bug趋势图、Bug分布图等，有利于我们对问题的归纳总结。
● 测试通过率
包括计划的测试用例执行进度、通过的测试用例数目、失败的测试用例数目、被阻塞的测试用例数目等。一般要求达到95%以上。
我们还利用一次通过率去衡量开发的质量，这里不做详细的阐述。还可以延伸到模块通过率，来衡量系统某一具体功能模块的稳定性。
● 测试覆盖率
包括业务覆盖率（核心业务场景）、测试类别（性能、安全测试等）。业务覆盖率必须全部覆盖，根据产品的性质，考虑性能指标、安全指标是否需要100%达标。
● 信心
测试负责人对所测版本及需求的主观感受。作为需求及版本的第一手用户，测试员对其有比较敏感的判断。
延伸到我们经常提的：测试总结或者版本发布公告，应该包含但不限于上述提到的几项指标。
软件产品发布之后一般面向的是项目（面向测试发布的制品进行一轮验证），亦或者是客户（直接部署到正式环境，面向客户使用）。
针对发布后的评估，根据项目或者客户现场发现的问题数量/(测试发布时发现的问题数量+客户现场发现的问题数量)*100%
一般统计周期是三个月，一般控制在10%以内算正常，当然也要看问题的严重等级。
常见的有千行代码错误率，CMMI级别也定义了每一级的错误率：
有的公司也逐渐从CMM1升级到了CMM3，量化的指标比较能够直观的反应一些问题，不至于问起来质量好坏都是，我觉得应该可以。
但也有不少诟病：代码冗余；为了CMMI定级而去冲指标。
所以，我们也不能完全依赖千行代码错误率去评判和衡量产品质量的好坏，测试度量的目标还是提高产品质量。
从研发阶段和效率价值金字塔看，自底向上，越早参与测试发现问题，后期的投入就越少，产品质量就越稳定。
自底向上，我们可以做哪些工作来保障产品质量呢：
1. 需求的评审：测试参与
2. 架构设计方案评审
3. 代码模块设计，包的依赖的规划，接口的设计的review
4. 代码的review的机制
5. 测试用例评审
6. 使用代码检测工具，自动发现问题
7. 使用自动化测试，自动检测历史功能及模块完整性
8. 完善测试流程，增加性能、安全等未涉及领域测试
9. 漏洞Review分析，测试总结
当然上述每项，单独做起来都是需要耗时耗力的，前期还要有专人负责牵头保障效果与执行监督。
产品质量不是测试出来的，需要上游产品设计、开发编码、架构设计等环节以及下游运维、实施、维护等环节共同保障。
单纯依赖测试去保障研发出来的产品，只是冰山一角，更多的问题需要大家共同去关注，协同保障产品质量。
个人认为
完全依赖一些量化的指标去评判产品质量的好坏、测试质量的好坏是不够的，重点是数据背后的问题，管理者要重视起来，找到问题的根源并有意识的去提升。
这样产品质量才能持续稳步的提升。
标签：架构设计 业务 评估 必须 自动化测试 接口 用户 splay 机制
原文地址：https://www.cnblogs.com/starlight-yang/p/10237936.html
