测试的主要评测方法
简介
测试的主要评测方法包括覆盖和质量。
测试覆盖是对测试完全程度的评测，它建立在测试覆盖基础上，测试覆盖是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。
质量是对测试对象（系统或测试的应用程序）的可靠性、稳定性以及性能的评测。质量建立在对测试结果的评估和对测试过程中确定的变更请求（缺陷）的分析的基础上。
覆盖评测
覆盖指标提供了"测试的完全程度如何？"这一问题的答案。最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖。简而言之，测试覆盖是就需求（基于需求的）或代码的设计/实施标准（基于代码的）而言的完全程度的任意评测，如用例的核实（基于需求的）或所有代码行的执行（基于代码的）。
系统的测试活动建立在至少一个测试覆盖策略基础上。覆盖策略陈述测试的一般目的，指导测试用例的设计。覆盖策略的陈述可以简单到只说明核实所有性能。
如果需求已经完全分类，则基于需求的覆盖策略可能足以生成测试完全程度的可计量评测。例如，如果已经确定了所有性能测试需求，则可以引用测试结果来得到评测，如已经核实了75%的性能测试需求。
如果应用基于代码的覆盖，则测试策略是根据测试已经执行的源代码的多少来表示的。这种测试覆盖策略类型对于安全至上的系统来说非常重要。
两种评测都可以手工得到（公式如下所示）或通过测试自动化工具计算得到。
基于需求的测试覆盖
基于需求的测试覆盖在测试生命周期中要评测多次，并在测试生命周期的里程碑处提供测试覆盖的标识（如已计划的、已实施的、已执行的和成功的测试覆盖）。
在执行测试活动中，使用两个测试覆盖评测，一个确定通过执行测试获得的测试覆盖，另一个确定成功的测试覆盖（即执行时未出现失败的测试，如没有出现缺陷或意外结果的测试）。
这些覆盖评测通过以下公式计算：
这一关于测试覆盖的陈述是有意义的，可以将其与已定义的成功标准进行对比。如果不符合该标准，则此陈述将成为预测剩余测试工作量的基础。
基于代码的测试覆盖
基于代码的测试覆盖评测测试过程中已经执行的代码的多少，与之相对的是要执行的剩余代码的多少。代码覆盖可以建立在控制流（语句、分支或路径）或数据流的基础上。控制流覆盖的目的是测试代码行、分支条件、代码中的路径或软件控制流的其他元素。数据流覆盖的目的是通过软件操作测试数据状态是否有效，例如，数据元素在使用之前是否已作定义。
基于代码的测试覆盖通过以下公式计算：
质量评测
测试覆盖的评估提供对测试完全程度的评测，在测试过程中已发现缺陷的评估提供了最佳的软件质量指标。因为质量是软件与需求相符程度的指标，所以在这种环境中，缺陷被标识为一种更改请求，该更改请求中的测试对象与需求不符。
缺陷评估可能建立在各种方法上，这些方法种类繁多，从简单的缺陷计数到严格的统计建模不一而足。
严格的评估假定测试过程中缺陷达到的比率或发现的比率。常用模型假定该比率符合泊松分布。则有关缺陷率的实际数据可以适用于这一模型。生成的评估将评估当前软件的可靠性，并且预测继续测试并排除缺陷时可靠性如何增长。该评估被描述为软件可靠性增长建模，这是一个活跃的研究领域。由于该类型的评估缺乏工具支持，所以应该慎重平衡成本与其增加价值。
缺陷分析就是分析缺陷在与缺陷关联关系的一个或多个参数值上的分布。缺陷分析提供了一个软件可靠性指标。
对于缺陷分析，常用的主要缺陷参数有四个：
·状态：缺陷的当前状态（打开的、正在修复或关闭的等）。
·优先级：必须处理和解决缺陷的相对重要性。
·严重性：缺陷的相关影响。对最终用户、组织或第三方的影响等等。
·起源：导致缺陷的起源故障及其位置，或排除该缺陷需要修复的构件。
可以将缺陷计数作为时间的函数来报告，即创建缺陷趋势图或报告；也可以将缺陷计数作为一个或多个缺陷参数的函数来报告，如作为缺陷密度报告中采用的严重性或状态参数的函数。这些分析类型分别为揭示软件可靠性的缺陷趋势或缺陷分布提供了判断依据。
例如，预期缺陷发现率将随着测试进度和修复进度而最终减少。可以设定一个阈值，在缺陷发现率低于该阈值时才能部署软件。也可根据执行模型中的起源报告缺陷计数，以允许检测"较差的模块"、"热点"或需要再三修复的软件部分，从而指示一些更基本的设计缺陷。
这种分析中包含的缺陷必须是已确认的缺陷。不是所有已报告的缺陷都报告实际的缺陷，这是因为某些缺陷可能是扩展请求，超出了项目的规模，或描述的是已报告的缺陷。然而，需要查看并分析一下，为什么许多报告的缺陷不是重复的缺陷就是未经确认的缺陷，这样做是有价值的。
缺陷报告
Rational Unified Process以三类形式的报告提供缺陷评估：
·缺陷分布（密度）报告允许将缺陷计数作为一个或多个缺陷参数的函数来显示。
·缺陷龄期报告是一种特殊类型的缺陷分布报告。缺陷龄期报告显示缺陷处于特定状态下的时间长短，如"提出的"。在龄期类别中，缺陷还可以按其他属性分类，如"拥有者"。
·缺陷趋势报告按状态（新的、已打开的或关闭的）将缺陷计数作为时间的函数显示。趋势报告可以是累计的，也可以是非累计的。
·测试结果和进度报告显示对测试的应用程序进行若干次迭代和测试生命周期后的测试过程执行结果。
许多此类报告对于评估软件质量具有很高的价值。一般测试标准中包括有关特定类别（如严重性级别）中打开的缺陷数的陈述。通过缺陷分布评估可以轻松地核对该标准。对测试需求进行过滤或分类，该评估可以侧重于不同的需求集。
要有效生成此类报告，一般需要工具支持。
缺陷密度报告
缺陷状态与优先级
应该给定所有缺陷的优先级，通常可行的做法是设定四种优先级中的一种：
1.立即解决
2.高优先级
3.正常排队
4.低优先级
一个成功测试的标准可以表示为缺陷在上述优先级上所应体现的分布方式。例如，对于一个成功的测试标准来说，可能不存在优先级为1的打开的缺陷，而且优先级为2的打开的缺陷要少于5个。例如下面的缺陷分布图：
很明显该图显示的情况没有达到标准。请注意，该图需要通过过滤器才能只显示需要的打开的缺陷。
缺陷状态与严重性
缺陷严重性报告显示每种严重性级别的缺陷个数，例如致命错误、未执行主要功能、次要错误等严重性级别。
缺陷状态与在实施模型中的位置
缺陷起源报告显示缺陷在实施模型元素上的分布情况。
缺陷龄期报告
缺陷龄期分析提供了有关测试有效性和缺陷排除活动的良好反馈。例如，如果大部分龄期较长的、未解决的缺陷处于有待确认的状态，则可能表明没有充足的资源应用于再次测试工作。
缺陷趋势报告
趋势报告确定缺陷率并提供了一个出色的测试状态视图。在测试生命周期中，缺陷趋势遵循着一种比较好预测的模式。在生命周期的初期，缺陷率增长很快。在达到顶峰后，就随时间以较慢的速率下降。
要发现问题，可以根据这一趋势复审项目时间表。例如，在四个星期的生命周期中，如果缺陷率在第三个星期中仍然增长，则项目很明显没有按时间表进行。
这一简单的趋势分析假定：缺陷是立即关闭的，且在随后的工作版本中对修复进行测试，这样关闭缺陷的速率应该遵循与打开缺陷的速率相同的增减趋势。如果情况并非如此，则表明缺陷解决流程发生了问题；缺陷修复所需的资源或再次测试和确认修复所需的资源可能不足。
该报告反映的趋势显示，在项目开始时，发现和打开新缺陷的速率很快，但随着时间推移，该速率不断降低。打开的缺陷的趋势与新缺陷的趋势相似，但稍微滞后一些。关闭的缺陷的趋势随着打开的缺陷的修复和核实而不断增长。这些趋势描述的是成功的工作。
如果您的趋势与这些趋势差别显著，则表明存在问题，并可以确定可能需要附加资源以应用于开发或测试特定区域的时间。
当与测试覆盖评测结合起来时，缺陷分析可提供出色的评估，测试完成的标准也可以建立在此评估基础上。
性能评测
评估测试对象的性能行为时，可以使用多种评测，这些评测侧重于获取与行为相关的数据，如响应时间、计时配置文件、执行流、操作可靠性和限制。这些评测主要在评估测试活动中进行评估，但是也可以在执行测试活动中使用性能评测评估测试进度和状态。
主要的性能评测包括：
·动态监测-在测试执行过程中，实时获取并显示正在执行的各测试脚本的状态。
·响应时间/吞吐量-测试对象针对特定主角和/或用例的响应时间或吞吐量的评测。
·百分位报告-数据已收集值的百分位评测/计算。
·比较报告-代表不同测试执行情况的两个（或多个）数据集之间的差异或趋势。
·追踪报告-主角（测试脚本）和测试对象之间的消息/会话详细信息。
软件作为一种纯数字化商品，在没有权威的第三方进行监督认证的情况下，软件供应商和用户在软件产品是否达到目标需求的问题上，往往各执一词。
关于软件质量标准和认证，国内虽然制定了有限的几个软件技术标准，但无法从根本上对软件这种特殊商品实施有效的质量监督和认证。在国际上通行的做法是，软件的质量标准和认证工作，由独立的软件测试机构来完成。这些测试机构的行为是市场化的，但因为测试能力和权威性将直接关系到它们的市场影响力，所以他们的测试行为极其严格，力求将垃圾软件扼杀在摇篮中。
樱花西街一座不太显眼的大厦里，迈捷实验室技术总监武友文从软件测试说起，以第三方的视角分析了制约国内软件发展的瓶颈，发表了不同意见，提出了自己的建议。
为什么需要软件测试
“我是清华大学77级的学生，在国内做了3年软件开发，随后就去了加拿大读研，专业是网络协议测试。毕业后我在北电、惠普等公司做软件质量的控制和测试项目。”武友文轻声细语地说着自己的经历，“1998年我回到国内，在对金融和电信行业进行考察时，发现他们买的硬件设备都是顶级的，可惜软件应用这一块跟不上，导致了硬件功能得不到充分的发挥。硬件设备低下的运行效率，造成了资源与资金的隐性浪费。不客气地说，实际上，是国内软件在拖硬件的后腿。”
在武友文回国期间，国内一些软件开发商通过朋友的引见，邀请武友文与公司研发人员交流时，武友文发现当时国内的软件开发普遍存在“重开发，轻测试”的现象，常常是在项目开发完成之后，才发现软件有严重缺陷问题，不得不全部推倒从头再来。推倒重来则意味着前期人、财、物的投入全部浪费了，即大大增加了软件的开发成本，又会因为超出了客户的委托时间，付出的代价就更高了。
武友文以自己在国际公司的实践经验，一再强调，软件测试是软件开发过程中的一个重要步骤，或者说测试应该贯穿在软件开发过程的每一个阶段。软件测试所起到的作用就是：能够确保在软件开发的过程中，随时发现问题，方便开发人员及时修改。
在国内对于消费类软件来说，经常出现一些已经推向市场的产品由于被发现有严重缺陷而导致大量退货的局面。而对于定制的行业软件来说，则是一再的返工、绵绵无绝期的修改和维护，既拖死了软件提供商，也耽误了客户的正常业务。
这一系列现状使用户对国内软件提供商失去信心，因此我们经常听到有人抱怨：国内软件没法用，对于正在成长的国内软件市场来说，这一结论无疑是灭顶之灾。
武友文告诉记者：“因为国外软件的成熟度高，开发商对软件质量的控制力度很强，所以国外软件测试外包的不是太多；不过在国外有些软件需要比较专业的质量认证，例如软件的本地化测试，就必须借助第三方机构来完成了。拿微软来说吧，微软的产品要翻译成欧洲的6种文字，如果是自己来做这些本地化测试工作，成本就会很大，所以外包给别的公司来做就很合适；另外还有一种情况也会外包的，例如对一些大型软件的测试，不一定每家开发商都有专业的测试队伍和测试的工具。从成本上来说，某些软件测试工作外包是经济的。相反，国内软件的成熟度比较低，软件开发商基本没有能力来做测试，我指的是专业的、职业的测试，所以从目前来说，国内软件测试的市场空间很大。”
凭着对软件测试行业的深刻理解，武友文意识到要解决国内软件应用滞后于硬件的问题，就必须提高国内软件的质量，而要提高软件质量，就必须加强软件开发过程中的测试力量，而独立的第三方测试机构正是一个市场空白点，于是专业从事软件测试的迈捷实验室就应运而生。
软件测试如何做
“迈捷成立之初，主营业务只是受客户委托，测试已经开发完毕的软件，更多的是事后验收工作，后来我们慢慢的从事后测试，向质量控制上转型，例如开始介入软件开发前的需求评审，以及开发时的文档评审、代码走查等等。我们最终的发展方向就是做软件监理，但是不能不承认，目前我们与国际上通行的软件监理还有一定的距离。”说到迈捷的发展方向，武友文沉稳中略显激昂。
武友文接着说：“美国实际是在软件规模的扩大和结构的不断复杂的情况下，开始建立软件测试制度和规矩的。我想美国在软件开发的起步阶段，也不会自己主动去做，是在现实的压力下，才去实施这些流程规范的。国内一定要有这种意识，意识到软件开发过程中一定要引进这些规章制度。另外，意识到了还不行，一定要实践。
软件测试现状
武友文向记者提供的一个市场调查报告说明，目前国内做软件测试的机构，还没有发现与迈捷公司商业形态相同的企业，只是有某些政府部门下属的机构做一些软件产品验收工作，但完全商业化操作的机构没有；另外就是开发商临时承接的一些软件测试项目。当记者问到迈捷实施软件测试时遇到的最大障碍是什么时，武友文很爽快的回答到：“一是客户的意识，二是我们派出的项目实施人员的素质问题。”
实施软件评测项目时，客户要有接受管理软件开发流程的意识。
客户交给开发商一个项目，通过测试等质量掌控流程，可以将产品的质量保证在一个相对较高的水准，减少后续工作的成本。但是现在很多开发商和客户很短视，觉得只要现在没有出问题，就可以了，不愿意在软件开发过程中，让测试介入的程度不深，这导致测试不完全，埋下了隐患。
无论是对软件开发商还是对客户来说，忽视软件测试，必将导致上的软件开发项目越多，将来会被这些有问题的项目给拖死的概率越高。
武友文说：“有独立的软件测试第三方的出现，好处就是严格地掌控软件质量，减少维护成本，这不光对客户有好处，对开发商也有好处。所以一个项目，在我们实施很长一段时间，大约是半年至两年后，客户才意识到这样做是有用的。这很正常，因为软件开发一定会有大大小小的问题，包括我们评测也有一些问题查不出来。”
迈捷对派出的项目实施人员的标准很高，要求既有综合素质，又要有专业素质，目前国内这种复合型的人才太少了，于是迈捷只能自己培养。
而人才培训，则令武友文最为头痛。人才培养是迈捷在资金和力量上投入最大的一块。其中专业素质的培训最难，因为需要实践。这如同医生一样，从医学校毕业了，虽然有很多理论上的积累，但是缺乏临床经验，你还不是一个合格的医生，更别谈做一个好医生了。项目实施管理者也一样，既要有理论基础，更要有经验积累，而一个优秀的项目实施管理者重要的素质是，能在按流程做的基础上，发挥个人的主观能动性，这个要求就太高了，但这又是项目实施成否的关键。
国内软件业和国外相比，最大的差异就在：质量和质量控制应该是最重要的一项内容。但是，无论在消费类软件还是大型软件的测试领域，与国外相比，国内软件产品的质量掌控体系和标准都是模糊的。国内软件提供商的质量承诺，既没有相应机构的监督，质量水平也没有第三方来认证，承诺显得极其苍白而无力。
可喜的是，软件测试机构在我国正逐渐成长起来，并且，它们在软件市场上的影响力正逐步得到提升。因缺乏游戏规则导致整个软件行业的市场行为不规范，并且严重制约软件行业健康成长的局面，一定会有所改善。
采访后记：
软件评测只是用技术手段来监控软件产品的质量，并不能从根本上提高我国软件产品的水平。目前，国内最缺的是软件项目实施的高级管理人才和软件结构分析的专业人才。这种高级人才的培育制度才是最重要的，缺乏高级人才培养的后果，会影响国内软件的进程。与培养软件蓝领相比，虽然高级人才培育的时间周期长，资金投入大，但是我们一定不能急功近利，要有这种忧患意识，去做这项有长远影响的工作。这种工作不是非得要谁去做，但是我们一定要有这种意识去投入去做。
在采访中，武友文认为大量的蓝领、很少的白领，这样的软件产业肯定有问题。不少人对将软件分为对白领蓝领很有意见，软件开发流程应该有一定的延续性。因为写程序不难，谁都能写，难的是写出合格的、优秀的程序。单一的写程序对软件开发很不合适，如果你不懂别的，譬如软件架构和质量目标，那么程序也写不好。单从编程的角度进行培训，对蓝领见效快，对白领则不太公平。
日本在软件开发中分得很细，国内接日本软件外包的业务很多，但大部分只是负责一个模块。软件是个创造性的工作，变成流水线工业化生产也许有问题。在我们的软件开发中，往往技术是不成问题的，但是管理是个大问题。我们的软件企业中，各个员工意识不一样，在不同的阶段理解不一样，管理人员的素质也不一样。软件管理和测试是一个需要反复实践的过程，要通过反复的实践才能解决问题。这些问题根本不是培训大量的软件蓝领就能解决的。
现在关于软件工程的培训很多，如果只是讲课意义不大，这些课在学校都已经讲过了，现在要的是实践。但是，目前国内还很欠缺这种实践的机会。
的主要评测方法
简介
测试的主要评测方法包括覆盖和质量。
测试覆盖是对测试完全程度的评测，它建立在测试覆盖基础上，测试覆盖是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。
质量是对测试对象（系统或测试的应用程序）的可靠性、稳定性以及性能的评测。质量建立在对测试结果的评估和对测试过程中确定的变更请求（缺陷）的分析的基础上。
覆盖评测
覆盖指标提供了"测试的完全程度如何？"这一问题的答案。最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖。简而言之，测试覆盖是就需求（基于需求的）或代码的设计/实施标准（基于代码的）而言的完全程度的任意评测，如用例的核实（基于需求的）或所有代码行的执行（基于代码的）。
系统的测试活动建立在至少一个测试覆盖策略基础上。覆盖策略陈述测试的一般目的，指导测试用例的设计。覆盖策略的陈述可以简单到只说明核实所有性能。
如果需求已经完全分类，则基于需求的覆盖策略可能足以生成测试完全程度的可计量评测。例如，如果已经确定了所有性能测试需求，则可以引用测试结果来得到评测，如已经核实了75%的性能测试需求。
如果应用基于代码的覆盖，则测试策略是根据测试已经执行的源代码的多少来表示的。这种测试覆盖策略类型对于安全至上的系统来说非常重要。
两种评测都可以手工得到（公式如下所示）或通过测试自动化工具计算得到。
基于需求的测试覆盖
基于需求的测试覆盖在测试生命周期中要评测多次，并在测试生命周期的里程碑处提供测试覆盖的标识（如已计划的、已实施的、已执行的和成功的测试覆盖）。
在执行测试活动中，使用两个测试覆盖评测，一个确定通过执行测试获得的测试覆盖，另一个确定成功的测试覆盖（即执行时未出现失败的测试，如没有出现缺陷或意外结果的测试）。
这些覆盖评测通过以下公式计算：
这一关于测试覆盖的陈述是有意义的，可以将其与已定义的成功标准进行对比。如果不符合该标准，则此陈述将成为预测剩余测试工作量的基础。
基于代码的测试覆盖
基于代码的测试覆盖评测测试过程中已经执行的代码的多少，与之相对的是要执行的剩余代码的多少。代码覆盖可以建立在控制流（语句、分支或路径）或数据流的基础上。控制流覆盖的目的是测试代码行、分支条件、代码中的路径或软件控制流的其他元素。数据流覆盖的目的是通过软件操作测试数据状态是否有效，例如，数据元素在使用之前是否已作定义。
基于代码的测试覆盖通过以下公式计算：
质量评测
测试覆盖的评估提供对测试完全程度的评测，在测试过程中已发现缺陷的评估提供了最佳的软件质量指标。因为质量是软件与需求相符程度的指标，所以在这种环境中，缺陷被标识为一种更改请求，该更改请求中的测试对象与需求不符。
缺陷评估可能建立在各种方法上，这些方法种类繁多，从简单的缺陷计数到严格的统计建模不一而足。
严格的评估假定测试过程中缺陷达到的比率或发现的比率。常用模型假定该比率符合泊松分布。则有关缺陷率的实际数据可以适用于这一模型。生成的评估将评估当前软件的可靠性，并且预测继续测试并排除缺陷时可靠性如何增长。该评估被描述为软件可靠性增长建模，这是一个活跃的研究领域。由于该类型的评估缺乏工具支持，所以应该慎重平衡成本与其增加价值。
缺陷分析就是分析缺陷在与缺陷关联关系的一个或多个参数值上的分布。缺陷分析提供了一个软件可靠性指标。
对于缺陷分析，常用的主要缺陷参数有四个：
TAG:
