网站建设测试度量是一种经过检测软件测试过程的质量和有效性来评价软件开发的量化办法。开发团队运用测试指标来跟踪开发过程各个阶段的软件质量。测试指标关于管理层也很有用，它能够让公司股东评价软件开发团队的效率。
测试指标应该一直是有意义和可执行的。问题是有些测试指标无法到达这一目的。许多指标都是误导，有些只是无价值的指标，而有些则... 网站建设测试度量是一种经过检测软件测试过程的质量和有效性来评价软件开发的量化办法。开发团队运用测试指标来跟踪开发过程各个阶段的软件质量。测试指标关于管理层也很有用，它能够让公司股东评价软件开发团队的效率。
测试指标应该一直是有意义和可执行的。问题是有些测试指标无法到达这一目的。许多指标都是误导，有些只是无价值的指标，而有些则毫无意义。
下面这些无用的测试指标的例子能够协助你更好天文解测试指标能否提供了所需的洞察力。
1、执行的测试用例的数量
这是一个糟糕的度量规范，缘由很简单，它没有通知你测试用例测试的是什么。
这个度量规范的最初想法是，我们开发的测试用例越多，我们的测试就越全面。实践上，许多测试用例基本没有对测试掩盖率做出奉献。许多测试套包含已弃用的测试，这些测试不再与软件的新版本相关。测试用例的设计效率不高，因而它们会堆叠，并且实质上是测试相同的功用。 在这些和许多其他的状况下，具有更多的测试用例并不是一件好事，这可能只是代表一个臃肿且过于复杂的测试套。
2、每一个测试人员发现的Bug数
这是一个糟糕度量规范的缘由之一在于,度量每一个测试人员的任何东西都不是一个好的理论——它鼓舞过度的竞争，并且毁坏协作的的团队工作，而团队协作在矫捷组织中得到了激烈的鼓舞。 有些公司以至会依据每个软件测试人员发现的缺陷来决议员工报酬，这对团队的目的特别不利，由于它常常会抑止信息的共享，并促进“每个人都只为本人”的态度。
此外，一个员工可能在测试一个稳定的软件特性，而另一个测试一个有缺陷的、不稳定的特性。在这个度量规范下，后者会被以为性能更好，由于他发现了更多的bug，这是很愚笨的的。
3、百分比经过率
运用百分比通率作为度量指标是一个坏主见，由于在你的软件开发团队中不鼓舞的行为很容易支配这种指标。 例如，测试团队可能会专注于执行更容易经过的测试，从而进步经过率。或者，团队能够将一个长时间的测试合成成许多小的测试，人为地进步百分比的经过率。换句话说，这个指标变化无常，易于支配。
4、单元测试代码掩盖率
代码掩盖是另一个常用的度量指标，常常被错误地运用。代码掩盖率是由单元测试掩盖的代码行百分比。代码掩盖能够给你一个完整错误的实践测试掩盖图，缘由有两个：
首先，单元测试并不是对你软件的全面测试。它们只是测试代码中特定的微组件能否可以正常工作。即便你的车里的一切部件都经过了测试和圆满的工作，也不能保证汽车会启动。
其次，这个指标对单元测试质量没有任何意义。一个单元测试能够包含文雅设计的代码，测试一个办法或函数的一切相关输入和输出。或者，它可能是一团乱麻，只测试其中的一些功用，或者其他无关的或已弃用的功用。用越来越多的草率的单元测试来掩盖代码对任何人都没有益处。 5、自动化的百分比
在许多状况下，自动执行的测试用例百分比是一个无价值的度量规范。假如自动化测试不像旧的手工测试那样测试功用，那么越来越多的自动化测试是没有意义的。或者假如软件变化太快，自动化测试很快就会解体，需求完整重构。 被这个指标掩盖的另一个方面是测试持续时间。添加越来越多的Selenium测试，停止自动化UI测试是一个好主见。但是运转这些测试能够使构建时间从几分钟增加到几小时。在当前频繁发布版本的理想中，停止这样的测试需求十分慎重，关于需求匆忙停止托付的团队就只能跳过了。
6、每一个缺陷的本钱
这可能是软件质量的最古老的度量规范，它早在上世纪60年代就在IBM内部运用过。改度量指标为一个bug贴上一个价钱标签——辨认一个bug、修复它、并考证它的本钱。这个共识就是：在开发周期的早期修复bug要廉价得多，而在测试后期，或者在消费过程中，修复它们是十分昂贵的。
在开发周期的不同阶段度量每个缺陷的本钱是一个很好的想法。但是，一些团队度量每个缺陷的本钱，以使软件维护更有效。 主要问题是：关于软件的质量和用户的经历，缺陷有不同的含义。有些缺陷是“化装品”，关于软件的用户简直没什么影响。而其他的一些缺陷，如平安问题，假如不处理的话可能会带来灾难性结果。
一个软件团队可能会把留意了放在那些影响不大的缺陷上，大幅降低每个缺陷的本钱，但是最终会损坏软件的质量。
7、缺陷密度
缺陷密度是指软件中检测到的得到确认的缺陷数量。通常以为较低的缺陷密度同等于较低的软件质量，但这并不是真的。缺陷密度的一个问题是，缺陷的数量取决于测试是如何结构和报告的，以及软件测试人员的技艺。某个软件问题能够被当成一个bug、或者是该问题不同方面的15个bug，或者基本没有bug报告，由于测试人员没有发现它。因而，关于相同的软件，缺陷密度可能会有很大的变化。
