前一讲我们提到了一些广为统计，但是实际上却可能没有指导意义的数据。那么这一讲，我们将来阐述那些需要统计并对项目产生积极影响的数据。
一般来说，软件项目最关心的就是Quality (质量)、Cost (成本)、 Delivery（交货期）。管理者希望以不同的角度，不同的形式通过数据形式将这些属性展示出来。那么我们所统计的数据也就是围绕着三方面的。而同时，我们也要关系这些数据将为未来的改进提供什么样的帮助。
1.圈复杂度
圈复杂度无疑是衡量软件质量的一个指标。圈复杂度有现成的工具来统计。C#.Net的NUnit，Java的Google Code Pro*，Matrix等都可以统计这个数据。圈复杂度的推荐指标为不超过10。超过10的代码应该被改进。而过分的求低可能从ROI（投资回报率）上来说不一定值得。
2. 平均Bug修复时间
和统计Bug收敛趋势，Bug数量，二次Bug率，Bug分布，Bug原因统计等不同，统计平均Bug修复时间有助于了解组织在市场中的竞争力。Bug平均修复时间越短说明发布的周期越短，组织也就越具有竞争力。Bug修复的时间应该从Bug登记开始计算，到Bug被彻底修复（即通过已知的全集测试没有测试出二次Bug）为止。这其中还包括等待时间，测试时间，所以想要有短的Bug修复时间，就需要有好的测试机制。关于如何建立好的回归测试机制，在以后的章节中将会详细讨论，这里只强调为了能够缩短Bug平均修复时间必须采用自动化测试。
3. 测试覆盖率
测试覆盖率说明了测试的覆盖程度，但是现在的测试工具基本上只能在C0级别上给出数据。而且，代码被执行了并不代表代码被测试了。所以，现在的测试覆盖率统计工具的数据只能作为参考。为了能够更好地掌握测试覆盖程度，测试代码的复查是不可或缺的。为了能够保障测试的质量应该尽可能的增多不同类别的测试用例。对于测试类别的涵盖程度也是比较重要的审核方面。为了能够更好地说明这个问题，举例如下：
对于一个只能够输入正整数的文本框的校验测试应该有哪些测试数据这个问题，很多人给出的答案仅限于，整数、小数、正数、负数、0等几个条件。
实际上，下面这些也是至关重要的测试用例：
a. 中文、日文、韩文、法文、英文、罗马字等各种语言的数字。例如:quatre
b. 半角、全角的数字。例如：８
c. 带括号、带圆圈的数字。例如：㈥⑦
d. 带加号的数字。例如：+6
e. 分数。例如：3/5
f. 科学计数法。例如：2e5
g.符号。例如：$
h.英文。例如:ask
i.8进制，16进制数字。例如：0x52, FF,
j.以小数点结尾的数字，例如：2.
k.最大值与最小值：例如：Integer.MAX,Integer.MIN
l.百分比。例如37%
4. 测试用例数量
测试用例的数量可以反映测试的力度。
5. 到完成任务所需要的时间
这是用来取代百分比进度报告的。前文已经讨论过百分比进度报告无法给出足够的信息。到完成任务所需要的时间是一个可调整的数字，今天估算剩余工时是10小时，经过了8小时，明天应该还剩余2小时，但是由于今天开会等原因，可以剩余4小时。这样的数字往往比较准确。注意，其值不宜超过20小时，如果超过，应该考虑将任务分解。另外，当任务发现有估算条件遗漏时，可以对数字进行扩大，即，今天估算的剩余工时为10小时，经过了8小时之后，原来应该为2小时，但是由于发现一块重大遗漏，可以变为12小时。至于什么原因导致遗漏是另外需要解决的问题，但是就工时和进度本身，通过这样的数据统计就可以更为准确的把握了。
6. 进度偏差
实际的日程和计划之间有什么样的偏差。这样可以为调整进度或者削减功能提供参考依据。
7. 所用工时
所用工时应该单独列出。尤其是对于超时工作的情况。超时工作（加班）往往带来负面效果。进行实际情况的统计，并且分析投入的工时和产出的价值之间的关系。如果加班时间超过了法定的上限就是一件更为严重的事情。
8. 投入和预算之间的偏差
项目的投入不仅仅包括工时上的投入，还包括因为项目开发需要所产生的机器设备折旧、房租、通信费、差旅费、交通费、项目活动经费、采购的软硬件设施费、外包费、咨询费等各种费用。这些实际花费的费用和当初的预算费用之间的关系究竟如何。如果忘记了某些费用，下次应该如何改进。
9. 代码行数
统计这个不是为了计算Bug密度、测试密度、生产效率的。前文已经说过。统计这个是为了了解代码规模，进而了解代码是否有些臃肿。可以通过对比类似项目的代码行数来看技术上是否得到了改进。例如：某30万行代码的项目，改写之后代码行数为3万。
扫一扫
2197
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
