在测试阶段，尤其是集成测试阶段，我们通常会通过：用例执行数，bug数量等数据来反应阶段的一些情况.在实际过程中，我发现这还不够，于是在项目中尝试使用bug解决时间与bug测试时间来进行度量.
定义
解决时间：bug解决到bug提出之间的时间差；
测试时间：bug解决到bug回归通过之间的时间差；
意义
通过这两个时间，我们可能能得到以下信息：
1、开发，测试对bug的响应速度：这是最直接的；
2、从时间长短上，分析可能存在的问题，
2.1 如果解决时间很长，则说明bug严重及复杂程度很高；则软件的整体设计或架构等可能存在一定问题，至少一点的是：开发阶段的bug解决时间都长的话，意味着项目进入维护期后，可能需要更多的时间及成本；
2.2 如果解决时间长，bug的严重及复杂程度又不高，那么能说明：要么开发人员不足，因为他们在忙于其他的事情，要么是开发人员在消极怠工或效率不高；
2.3 如果测试时间很长，同理也能分析出上述问题，并针对性的找到问题的纠正及预防措施；
3、反应开发，测试之间协调工作能力，如果其他方面问题不明显的话，那么应改进开发与测试之间的协调工作方式；
实施
在bug提交时，记录下bug的提交时间，如：2010-11-03 12：34：34-----time_created
在bug解决时，记录下bug的resolve的时间；-----time_resolved
在bug测试通过时，记录下bug的测试通过时间；----time_tested
则：解决时间=time_resolved-time_created（理论上）
测试时间=time_tested-time_resolved（理论上）
通常以上数据可以使用bug跟踪系统得到。
真实时间差
我在实际工作中，是使用excel去计算解决时间及测试时间的，以下是我在excel中的VBA程序；
| Public getTime(a, b) On orror GoTo 1 Dim weeka As Integer Dim weekb As Integer '定义两个常量，用来定义工作时间，如果周六周日休息，则daywork=24*2，如果每天工作8小时，则hourwork=24-8 Const dayWork As Integer = 24, hourWork As Integer = 16 weeka = Application.Worksheet.WeekNum(a) weekb = Application.Worksheet.WeekNum(b) getTime = (b - a) * 24 - (weekb - weeka) * dayWork - Int(b - a) * hourWork Exit 1: getTime = 0 End |
这样计算出来的时间差是工作时间的时间差。
以上，和大家分享，欢迎讨论！
