最近很喜欢一句话，”一具体，就深刻“。做事情的时候，你能够具体到什么程度，也意味着你能够专业到什么程度。项目经理需要把控质量，这件事情所有的项目经理都清楚，但是要具体到怎么做？可能大多数人还真不一定说得清楚。
用一个实际的案例给大家分享下关于质量的具体案例，让你对质量不只是停留在测试报告这个词的层面，而是深入到细节中，当谈到质量问题的时候，我们不能做一个甩手掌柜，把他们都交给测试，至少我们要能够看得懂，问题在哪里，至少我们要能够明白如何去做监管。
迭代的发布日，好不容易所有的bug修复完毕，提交了发布申请单，等待审批通过后按时发布上线
结果等来的是驳回，审批节点上有一个负责人打开了测试报告，立刻就把我们的发布申请驳回了。被驳回当然会引起团队的反感和抱怨，可是我们深入进去看，会发现我们的测试报告确实存在一些低级错误。
我们通过查看这些低级错误，来看看我们的测试报告需要注意什么吧？
image.png
1.起止时间选择错误。明显这次测试的时间不止2天
2.用例覆盖率75%。这个用例覆盖率是如何统计的，为什么这个项目的用例覆盖率只有75%
3.发现31个Bug，遗留21个Bug。测试报告看到这里，大概有点常识的人都知道这个报告有问题，如果确实如此，那么这个系统根本不能进行发布，如果并非如此，那么这个低级错误是谁犯的。
以上三个错误几乎是致命的，我们对于质量的关注真的是非常的粗略。为什么我们会对最基本的测试报告如此忽视，源于我们最初重视的是自动化测试，一切以自动化测试为主，所以从一开始就忽略功能测试的内容，为了快速往前跑，对于报告相关的内容都不够重视，但是从最近的经验来看，我们不但离不开功能测试，而且还不能放松对其过程的管理。
测试报告包括这一页的基本信息就够了么，答案当然是否定的，如果了解禅道的人会发现，这是禅道的测试报告模板，这个“基本信息”页可以通过编辑填写“总结”内容，基本信息由于禅道或者工具的限制，不能进行灵活定义，也无法对测试过程问题进行整体的分析，这时候总结就起到了作用，总结包括哪些内容呢？
image.png
- 测试结论：回答是否测试通过？是否测试完成？是否存在遗留问题？
- 风险与建议：是否存在风险及建议
- 分析：从整体上进行分析本次测试过程中发现的Bug产生的主要原因，以便于在接下来的开发和测试工作中做出有针对性的改进。
大家有如此细致的了解过团队的测试报告么，如果想要团队的质量得到提升，不妨关注从关注测试报告开始关注深度关注一下团队的质量情况。
网友评论