之前，我们广泛提到了统计，但实际上可能没有指导性数据。 那么，我们将讨论将来需要统计的、对项目有积极影响的数据。
一般来说，软件项目最大的兴趣是交货期(质量、成本、交付)。 管理员希望以各种角度、各种形式以数据格式展示这些属性。 我们统计的数据也就是围绕着三个方面。 同时，还必须涉及这些数据将为未来的改善提供什么样的帮助。
1 .环路复杂性
圈的复杂度无疑是衡量软件质量的一个指标。 圈的复杂性有现成的工具。 C#.Net的NUnit、Java的Google Code Pro*、Matrix等可以统计该数据。 轮的复杂度推荐指标在10以下。 超过10的代码应该被改善。 寻求过低的值在投资回报(ROI )方面可能不一定有价值。
2 .平均错误修复时间
与统计bug收敛趋势、bug数、二次bug率、bug分布、bug原因统计等不同，统计平均bug修复时间有助于了解组织在市场上的竞争力。 错误的平均修复时间越短，发布周期越短，表明组织也越有竞争力。 错误修复的时间必须从错误注册开始计算，直到错误完全修复，也就是说，在已知的全集测试中没有测试两次错误之前。 这包括等待时间、测试时间，所以要求短的错误修复时间需要良好的测试机制。 如何构建回归测试机制将在以后的章节中详细讨论，这里只强调为了能够缩短错误的平均修复时间，必须采用自动化测试。
3 .测试覆盖率
测试覆盖率表明了测试的覆盖率，但目前的测试工具基本上只能在C0级别提供数据。 此外，运行代码并不意味着测试了代码。 因此，目前测试覆盖率统计工具的数据只能作为参考。 为了更好地掌握测试的覆盖水平，重新审视测试代码是必不可少的。 为了保障测试的质量，应该尽量增加不同类别的测试用例。 关于测试类别的覆盖水平，也是比较重要的审计方面。 为了更好地说明这个问题，以下是例子。
对于只能输入正整数的文本框的检测测试中应该有什么样的测试数据这个问题，很多人的回答仅限于整数、小数、正数、负数、0等几个条件。
实际上，以下内容也是重要的测试用例。
a .中文、日文、韩文、法文、英文、罗马字等各种语文的数字。 例如：四叉
b .半角、全角数字。 例如8
c .带括号、带圈的数字。 例
d .带加号的数字。 例如6
e .分数。 例如3/5
f .科学计数法。 例如2e5
g .符号。 例如$
h .英语。 例如：ask
I .八进制、十六进制。 例如0x52、FF、
j .以小数点结尾的数字，例如2。
k .最大值和最小值：例如Integer.MAX，Integer.MIN
百分比。 例如37%
4 .测试用例数量
测试用例的数量可以反映测试的力量。
5 .完成任务所需的时间
这将代替百分比进度报告。 上一篇文章中介绍的进度报告无法提供足够的信息。 完成任务所需的时间是一个可调的数字，今天剩下的工时10个小时，经过8个小时，明天应该还有2个小时，但是因为今天的会议等原因，剩下4个小时也可以。 这样的数字往往比较准确。 请注意，该值不能超过20小时。 如果超过了，就应该考虑分解任务。 另外，如果任务发现遗漏了估计条件，可以扩大数字。 也就是说，今天估计的剩余工时为10小时，经过8小时后，本来应该是2小时，但是因为发现了巨大的泄露，所以可以变成12小时。 究竟是什么原因导致泄漏是需要另外解决的问题，但对于工时和进度本身，通过这样的数据统计可以更准确地把握。
6 .进度偏差
实际的日程和计划之间有什么偏差？ 这样可以作为调整进度和削减功能的参考。
7 .雇用的情况
工作地点必须单独列出。 特别是超时工作时。 加班(加班)往往会带来负面效应。 进行实际情况的统计，分析投入的工时和产出的价值之间的关系。 如果加班时间超过法定上限，那就更严重了。
8 .投入与预算错位
项目投资不仅包括工时投资，还包括因项目开发需要而产生的机器设备折旧、房租、通讯费、差旅费、交通费、项目活动经费、购置的软硬件设施费、外包费、咨询费等各种费用这些实际花费的费用和当初的预算费用之间的关系到底如何呢？ 如果忘记了一部分费用，下次应该怎么改善？
9 .代码行数
统计它不是为了计算臭虫密度、测试密度和生产效率。 如上文已经叙述过的那样。 统计这一点是为了了解代码的规模，进而了解代码是否臃肿。 通过比较类似项目的代码行数，可以看到是否有技术上的改进。 例如，某30万行代码的项目，改写后的代码行数为3万。
转载于：3359 www.cn blogs.com/Stephen-Wang/archive/2012/10/24/2737937.html