Ponit2：
|
关注时间点 |
第8天 下午 项目经理向测试人员询问测试进展 |
备注说明 | ||||
|
当前BUG描述 |
BUG类型 |
需求错误 |
设计错误 |
编码错误 |
其他错误 |
其他错误（其中UI错误6，建议类1个） |
|
0 |
0 |
6 |
6 | |||
|
BUG严重程度 |
严重 |
一般 |
建议 |
|
建议的BUG为UI BUG 1个用户体验1个 | |
|
2 |
8 |
2 |
| |||
|
BUG状态 |
活动 |
已解决 |
已关闭 |
待决定 |
已关闭状态（2个严重BUG，4个一般BUG） 活动状态（2个一般BUG，2个建议BUG）。 | |
|
4 |
2 |
6 |
0 | |||
|
用例覆盖情况 |
高优先级用例执行100% ，中优先级用例执行100%，低优先级用例执行0% | |||||
|
测试人员的分析 |
A：测试工作已开展了3天，并未发现需求和设计上的错误，可以排除需求变更方面的风险。 B：从严重程度上分析，并未出现新的严重BUG，说明项目稳定程度无太大问题。 C：从BUG修复情况来看，过半BUG已被修复，且活动状态的BUG一般为建议型BUG，无影响修复进度方面的风险。 | |||||
|
测试人员的回复 |
项目进展情况正常，无特殊情况可按时完成测试任务。 | |||||
Point3：
2、小规模工程类项目缺陷分析
案例二：以“版本管控”为主线，结合三个BUG属性（BUG类型/BUG严重程度/BUG缺陷状态）分析项目缺陷。假设人力，时间等因素均正常。
……………………
查看全文请点击下载：http://www.51testing.com/html/11/n-832511.html
（三）综合分析与数据度量
当跳出单个项目，回头来看过去记录的一堆BUG，从这些BUG中还能得到诸多经验教训，并能知道测试人员的后续工作改进。
1、BUG综合分析举例
综合分析的前提是数据收集，数据越多越准确，则对工作的指导就越有效。数据分析通常涉及到建模，通过算法找出规律性的数据，总结经验，指导后续作业。
例如：取一定期限内的同类型项目，进行横向比较，排除特殊项目和无效数据，通过模型建立基线。（通常至少要取1年以上的项目量作为参考）。如图所示：
通过建立各类项目基线可以得到一些参考指标（假设）：
1）A类项目测试周期为1-5天，通常发现的BUG量5-10个，BUG遗漏率10%-12%；
2）B类项目测试周期为6-15天，通常发现的BUG量18-28个，BUG遗漏率 8%-10%；
3）C类项目测试周期为16-30天，通常发现的BUG量40-80个，BUG遗漏率9%-20%
指标分析：
√ A类项目因周期短，BUG遗漏率偏高，可近一步分析遗漏BUG的类型，严重程度，总结规律，找出解决方案。
√ B类项目周期适宜，BUG遗漏率是三类项目中最低的，今后可以考虑将部分C类项目拆分成B类项目完成，降低风险。
√ C类项目数据收集量不够，BUG遗漏率也不稳定，还需持续收集数据，比较高遗漏率项目和低遗漏率项目，分析规律，持续改进。
……
查看全文请点击下载：http://www.51testing.com/html/11/n-832511.html
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
