METRICS 指标
指标是最基本的管理工具
管理者都希望看到指标和报告，因为他们没有时间亲自跟踪项目的进展情况，而是根据一
些重要的指标来掌握当前的情况。
指标可以评估验证的效果
很多指标都可以用来评估功能验证的状态、进度和效率，code coverage就是其中之一。
code coverage并非适合所有情况
代码覆盖测试的是源代码被验证的程度，一般它会随着时间的流逝和设计的进展不断增
加，最终趋向 100%。
并不是所有的项目都适合用代码覆盖率来评估。代码覆盖率对于独立的小的设计单元是有效的
（例如，FPGA、ASIC 或可重复利用的元件），但却不适于由单独验证过的模块构成的大型设计项目。验证这些大型设计的目的是为了检查各个模块的接口是否正常工作，而不是验证每个模块的功能，因此没必要运行所有的语句。
测试用例的代码行数可以反映测试效率
执行验证过程所需的代码行数可以有效地反映执行该过程的代价，所以可以用它来比较新
的验证语言或方法的效率。如果新方法能减少需要编写的代码行数，那么它也可以降低验证过
程的花费。
代码行的比率可以反映设计的复杂性
被验证的设计的代码行数与测试用例的代码行数的比率可以反映设计的复杂程度，这个比
率还可用于预测某个新设计的复杂度和验证花费。
从版本控制系统可以了解到随时间变化的源代码修改程度。在项目的初期，随着新功能的
不断加入和版本的变化，代码会以很快的速度变化。在验证的初期阶段，修复错误也会导致代
码的变化。而随着验证过程的进行，错误越来越少，代码的变化也不断减少。
与品质相关的指标
品质是主观判断的，但可以通过测试指标来间接反映
与品质相关的指标与功能验证的关系比其他指标与其的关系更加密切。虽然品质是主观
值，但它可以由与设计质量相关的指标来反映，这就好比零售服务的质量可以由顾客投诉次数
和重复投诉的数量来反映。
功能覆盖(function coverage)可以反映测试用例的完整性
功能覆盖测试的是设计中观测到的输入、输出和内部信号的组合。对这些数据赋予不同的
权重，可以得到一个功能覆盖指标，反映设计的功能被执行的程度。如果增加重要指标的权重，它还可以作为功能验证进展情况的一种度量。在项目的初始阶段，覆盖率以很快的速度朝着100% 的目标增长，随着项目的进行，由于存在一些难以达到的功能点，它的增长速度明显放慢。
最简单的指标就是已知问题的数目
最容易收集的数据就是未解决的问题的数量，在统计时可以把问题的重要程度作为权重。
在使用计算机化的问题追踪系统时，可以很容易地得到这个指标以及它的趋势和变化速率，由
此可以判断问题是在不断增加还是在减少并趋向于零？
解释指标
用什么来评估已经完成的工作管理者在很大程度上依靠指标来判断设计者的工作业绩（作为奖惩的依据），这导致所有
设计人员都十分关注指标，也是为什么要慎重选择那些可以客观反映当前情况和所付出的努力
的指标的原因。如果评估的是已发现和修改的错误数，你很快会看到这个数目在增加，但你会
看到代码的质量在提高吗？错误以前没有被报告吗？如果只要有效地发现并修改错误就能得到
管理者的肯定，这会不会导致设计者编写代码时过于马虎和草率呢？
沒有留言:
張貼留言