第06章软件测试

第6章测试报告与测试评测6.1软件缺陷和软件缺陷种类6.2软件缺陷的生命周期6.3分离和再现软件缺陷6.4软件测试人员需正确面对软件缺陷6.5报告软件缺陷6.6软件缺陷的跟踪管理6.7软件测试的评测6.8测试总结报告6.1软件缺陷和软件缺陷种类6.1.1软件缺陷的定义和描述软件缺陷简单说就是存在于软件（文档、数据、程序）之中的那些不希望，或不可接受的偏差，而导致软件产生的质量问题。

按照一般的定义，只要符合下面5个规则中的一个，就叫做软件缺陷。软件未达到软件规格说明书中规定的功能；软件超出软件规格说明书中指明的范围；软件未达到软件规格说明书中指出的应达到的目标；软件运行出现错误；软件测试人员认为软件难于理解，不易使用，运行速度慢，或者最终用户认为软件使用效果不好。

软件缺陷的基本描述是报告软件缺陷的基础部分，一个好的描述需要使用简单、准确、专业的语言来抓住软件缺陷的本质，若描述的信息含糊不清，可能会误导开发人员。软件缺陷的有效描述规则：单一准确：每个报告只针对一个软件缺陷；可以再现：提供出现这个缺陷的精确步骤，使开发人员看懂，可以再现并修复缺陷；完整统一：提供完整、前后统一的软件缺陷的修复步骤和信息，如图片信息、log文件等；短小简练：通过使用关键词，使软件缺陷的标题描述短小简练，又能准确描述产生缺陷的现象；特定条件：软件缺陷描述不要忽视那些看似细节但又必要的特定条件（如特定的操作系统、浏览器），这些特定条件能提供帮助开发人员找到产生缺陷原因的线索；补充完善：从发现软件缺陷开始，测试人员的责任就是保证子元件缺陷被正确地报告，并得到应有的重视，继续监视其修复的全过程；不作评价：软件缺陷报告是针对软件产品的，因此软件缺陷描述不要带有个人观点，不要对开发人员进行评价。6.1.2软件缺陷的种类.（1）功能不正常

简单的说就是所应供应的功能，在使用上并不符合设计规格说明书中规定的要求，或是根本无法使用。这个错误常常会发生在测试过程的初期和中期，有许多在设计规格说明书中规定的功能无法运行，或是运行结果达不到预期设计。（2）软件在使用上不方便只要是不知如何使用或难以使用的软件，在设计上一定是除了问题。所谓好用的软件就是使用上尽量方便，使用户易于操作。（3）软件的结构未做良好规划

这里主要指的是软件是以自顶向下的方式开发，还是以自底向上的方式开发的。如果是以自顶向下的结构所开发的软件，在功能的规划及组织上比较完整，相反的以自底向上的组合方式开发出来软件功能较为分散。要根据具体情况，选择合适的开发方式。（4）功能不充分

这个问题与功能不正常是不一样的。这里所指的是软件所提供的功能在运作上是正常的，可是对使用者而言是不完整的。即使软件的功能运作结果符合设计规格的要求，系统测试人员在测试结果的判断上，一定要从使用者的角度进行思考。（5）与软件操作者的互动不良

一个好的软件必须与操作者之间正常互动。在操作者使用软件的过程中，软件必须很好的响应操作者。（6）使用性能不佳所测试的软件功能正常，但是使用性能不佳，如速度慢等，这样的问题通常是由于开发人员采用了错误的解决方案，或是运用了不使用的算法所导致的。（7）未做好错误处理

软件除了避免出错之外，还要做好错误处理，许多软件之所以会产生错误是因为程序本身不知道如何处理所遇到的错误。（8）边界错误

缓冲区溢出问题在这几年来已成为网络攻击的常用方式，而这个错误就属于边界错误的一种。简单地说，程序本身无法处理超越边界所导致的错误。这个问题除了编程语言所提供的函数有问题之外，有许多的情形是开发人员在声明变量或是使用边界范围时不小心引起的。（9）计算错误只要是计算机程序就免不了包括数学计算。软件之所以会出现计算错误，大部分出错原因在于采用了错误的数学运算公式或未将累加器初始化为0。（10）使用一段时间所产生的错误

这个问题就是程序刚开始运行时很正常，但在运行了一段时间后却出现问题。最典型的例子就是数据库的查找功能。有一些软件在刚开始使用时，所提供的信息查找功能运作良好，可是在使用了一段时间后却发现，进行信息查找所需的时间越来越长，原因是因为采用了顺序查找的方式。（11）控制流程的错误

控制流程的好坏，考验着开发人员对软件开发的态度及设计的程序是否严谨，软件在状态间的转变是否合理，要根据流程进行控制。（12）在大数据量压力之下所产生的错误

程序在处于大数据量状态下如果运行不正常的话，就是属于这种软件错误。大数据量压力测试对于server级的软件是必须要进行的一项测试，因为server级的软件对稳定度的要求远比其他的软件高。让程序处理超过10万笔的数据信息，然后再来观察程序运行的结果。（13）在不同硬件环境下产生的错误

如果所开发的软件与硬件设备有直接的关系，这样的问题就会相当多，如有的软件在特殊品牌的服务器上运行就会出错。（14）版本控制不良所产生的错误

出现这样的问题属于项目管理的疏忽，如一个软件被反应有安全上的漏洞，后来软件公司也很快将这个问题的修改版提供给用户，但是推出新版本的时候，却忘记将这个已解决掉的问题加入新版本内。（15）软件文档的错误

如用户手册、说明文档等内容错误，还有软件使用接口上的错误文字或错误用语等。6.1.3软件缺陷的属性.（1）缺陷标识：标记某个缺陷的唯一标识，一般由缺陷跟踪管理系统自动生成。（2）缺陷描述与缺陷注释：指对缺陷的发现过程所进行的详细描述和对缺陷的一些辅助说明信息。（3）缺陷类型：一般包括功能缺陷、用户界面缺陷、文档缺陷、软件配置缺陷、性能缺陷、系统/模块接口缺陷等。（4）缺陷严重程度：主要考虑缺陷对用户使用造成的恶劣后果的严重性。一般分为：

致命：系统主要功能完全丧失，用户数据受到破坏，系统崩溃、悬挂、死机或者危及人身安全。严重：系统的主要功能部分丧失，数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显的影响。一般：系统的次要功能没有完全实现，但不影响用户的正常使用。较小：使操作者不方便或遇到麻烦，但它不影响功能的操作和执行。（5）缺陷产生可能性：指某缺陷发生的频率，一般分为：总是、通常、有时、很少等。（6）缺陷的优先级：处理和修正软件缺陷的先后顺序，即哪些缺陷需要优先修正，哪些缺陷可以稍后修正。一般分为：最高优先级、高优先级、正常排队、低优先级等。软件缺陷的优先级在项目期间是会发生变化的。最高优先级：指的是一些关键性错误，缺陷导致系统几乎不能使用或者测试不能继续，需立即修复；高优先级：缺陷严重，影响测试，需要优先考虑修复；正常排队：缺陷需要正常排队，等待修复，在产品发布之前必须修复；低优先级：缺陷可以在开发人员有时间的时候被修正。（7）缺陷状态：描述缺陷通过一个跟踪修复过程的进展情况。一般分为：激活或打开：问题还没有解决，存在源代码中，确认“提交的缺陷”，等待处理，如新报的缺陷；已修正或修复：已被开发人员检查、修复过的缺陷，通过单元测试，认为已经解决但还没有被测试人员验证；关闭或非激活：测试人员验证后，确认缺陷不存在后的状态；重新打开：重新认定缺陷需要修复的状态；推迟：这个软件缺陷可以在下一个版本中解决；保留：由于技术原因或第三方软件的缺陷，开发人员不能修复的缺陷；不能重现：开发不能再现这个软件缺陷，需要测试人员检查缺陷再现的步骤；需要更多信息：开发能再现这个软件缺陷，但开发人员需要一些信息。（8）软件缺陷的起源：指缺陷引起的故障或事件第一次被检测到的阶段。分为：需求(54%)、设计(25%)、编码(15%)、测试、用户使用阶段等；（9）软件缺陷的来源：指引起软件缺陷产生的地方。分为：需求说明书、设计文档、系统集成接口、数据流、程序代码。（10）缺陷根源：产生软件缺陷的根本因素，一般为：测试策略，过程、工具和方法，团队/人，缺乏组织和通信，硬件，软件，工作环境。6.2软件缺陷的生命周期软件缺陷的生命周期是指的是一个软件缺陷从被发现、报告到这个缺陷被修复、验证直至最后关闭的完整过程。下面是一个最简单的软件缺陷生命周期的例子，系统地表示软件缺陷从被发现起经历的各个阶段：当软件缺陷首先被软件测试人员发现时，被测试人员登记下来，并指定程序员修复，该状态称为打开状态；一旦程序修复人员修复的代码，指定回到测试人员手中，软件缺陷就进入了解决状态；

然后测试人员执行回归测试，确认软件缺陷是否得以修复，如果验证已经修复，就把软件缺陷关掉，软件缺陷进入最后的关闭状态。

发现—打开：测试人员找到并登记软件缺陷，并将软件缺陷提交给开发人员。打开—修复：开发人员再现、修复缺陷，然后提交测试人员去验证。在许多情况下，软件缺陷生命周期的复杂程度仅为软件缺陷被打开、解决和关闭。然而，在有些情况下，生命周期变得更复杂一些，如图6-1所示。图6-1复杂的软件缺陷生命周期通常，软件缺陷生命周期有两个附加状态.（1）审查状态：指项目管理员或者委员会决定软件缺陷是否应该修复。从审查状态可以直接进入关闭状态；（2）推迟状态：审查可能认定软件缺陷应该在将来的某一时间考虑修复，但是在该版本软件中不修复。从推迟状态可以进入打开状态。6.3分离和再现软件缺陷测试人员要想有效报告软件缺陷，就要对软件缺陷以明显、通用和再现的形式进行描述。分离和再现软件缺陷是考验软件测试人员专业技能的地方，测试人员应该设法找出缩小问题范围的具体步骤。对测试人员有利的情况是，若建立起绝对相同的输入条件时，软件缺陷就会再次出现，不存在随机的软件缺陷。如果找到的软件缺陷要采取繁杂的步骤才能再现，或者根本无法再现，碰到这种情况，可采取如下的方法来分离和再现软件缺陷：（1）确保所有的步骤都被记录：测试人员应该记下测试过程中所做的每一件事：每一个步骤、每一次停顿、每一件工作，确保导致软件缺陷所需的全部细节再现；（2）注意时间和运行条件上的因素：软件缺陷是否仅在某个特定时刻出现，也许取决于输入的速度等；测试工作中看到软件缺陷时网络是否繁忙；测试的时序等，这些时间和运行条件上的因素，直接影响软件缺陷的分离和再现；（3）注意软件的边界条件、内存容量和数据溢出的问题；（4）注意事件发生次序导致的软件缺陷：状态缺陷仅在某些特定软件状态中才能显现出来，这类缺陷主要是与事件发生的次序相关，而不是事件发生的时间；（5）考虑资源依赖性和内存、网络、硬件共享的相互作用，考虑这些影响有利于分离软件缺陷；（6）不要忽视硬件：在测试过程中应注意硬件对软件的影响，测试人员必须设法在不同硬件上运行软件，看是否能够再现软件缺陷。6.4正确面对软件缺陷在软件测试过程中，软件测试人员必须确保测试过程发现的软件缺陷得以关闭。软件测试人员需要从综合的角度考虑软件的质量问题，对找出的软件缺陷保持一种平常心态。1.并不是测试人员辛苦找出的每个软件缺陷都是必须修复的

测试是为了证明程序有错，而不是证明程序没错。不管测试计划多么完善和执行测试多么努力，也不能保证所有软件缺陷发现了就能修复。有些软件缺陷可能会完全被忽略，还有一些可能推迟到软件后续版本中修复。有些软件缺陷不被修复的原因如下。（1）没有足够的时间（2）不算真正的软件缺陷（3）修复的风险太大（4）不值得修复

2.发现的缺陷的数量说明不了软件的质量

缺陷数量大，只能说明测试的方法好，不能简单的否认软件的质量，还要看缺陷的类型。

3.不要指望找出软件中所有的缺陷

当缺陷足够少的时候，就可以停止测试了。6.5报告软件缺陷6.5.1报告软件缺陷的基本原则在软件测试过程中，对于发现的大多数软件缺陷，要求测试人员简捷、清晰地把发现的问题报告给判断是否进行修复的小组，使其得到所需要的全部信息，然后才能决定怎么做。报告软件缺陷的基本原则如下。1．尽快报告软件缺陷

软件缺陷发现得越早，留下的修复时间就越多。2．有效地描述软件缺陷一个好的描述需要使用简单、准确、专业的语言来抓住软件缺陷的本质。3．在报告软件缺陷时不做任何评价

软件缺陷报告中应不带有倾向性以及个人观点。4．补充和完善软件缺陷报告

优秀的测试人员发现并随时记录许多软件缺陷，还应继续监视其修复的全过程。以上概括了报告测试错误的规范要求，测试人员应该牢记上面这些关于报告软件缺陷的原则。这些原则几乎可以运用到任何交流活动中，尽管有时难以做到，然而，如果希望有效地报告软件缺陷，并使其得以修复，这些是测试人员要遵循的基本原则。6.5.2IEEE软件缺陷报告模板ANS/IEEE829—1998标准定义了一个称为软件缺陷报告的文档，用于报告“在测试期间发生的任何异常事件”。简言之，就是用于登记软件缺陷。模板标准如图6-3所示。图6-3IEEE软件缺陷报告模板6.6软件缺陷的跟踪管理6.6.1软件缺陷跟踪管理系统软件缺陷跟踪管理系统（DefectTrackingSystem）是用于集中管理软件测试过程中所发现缺陷的数据库程序，可以通过添加、修改、排序、查寻、存储操作来管理软件缺陷。

在测试工作应用软件缺陷管理系统有以下优点：

1.保持高效率的测试过程软件测试人员可以随时向内部数据库添加新发现的缺陷，而且如果遗漏某项缺陷的内容，数据库系统将会及时给出提示，保证软件缺陷报告的完整性和一致性。

2.提高软件缺陷报告的质量为了提高报告的效率，数据库的很多字段内容可以直接选择，不必手工输入。同时，系统可以在测试工具和测试流程上，保证不同测试技术背景的测试成员书写结构一致的软件缺陷报告。

3.实施实时管理，安全控制通过方便的数据库查询和分类筛选，便于迅速定位缺陷和统计缺陷的类型。通过权限设置，保证只有适当权限的人才能修改或删除软件缺陷，保证的测试的质量。

4.利用该系统还有利于项目组成员间协同工作缺陷跟踪管理系统可以作为测试人员、开发人员、项目负责人、缺陷评审人员协同工作的平台，同时也便于及时掌握各缺陷的当前状态，进而完成对应状态的测试工作。软件缺陷跟踪管理系统可以通过添加、修改、排序、查寻、存储操作来管理软件缺陷。缺陷跟踪管理系统在实现技术层面上来看是一个数据库应用程序。它包括前台用户界面、后台缺陷数据库以及中间数据处理层。图6-4所示的是一个软件缺陷数据库跟踪系统。缺陷跟踪管理系统的实现原理图6-4软件缺陷数据库跟踪系统通过使用软件缺陷跟踪数据库，不但可以进行查询，还可以找出发现的软件缺陷类型，发现软件缺陷的速度，以及多少软件缺陷已经得到了修复，能够提取各种实用和关心的数据，可以显示测试工作的成效和项目的进展情况。测试人员或者项目管理员可以看出数据中是否有趋势显示需要增加测试的区域，或者测试工作是否符合预先所制定的测试计划的进程等。6.6.2手工报告和跟踪软件缺陷显然，在软件测试工作中，每个测试用例的结果都必须进行记录。如果使用软件缺陷数据库跟踪系统，那么测试工具将自动记录软件缺陷的相关信息。如果测试是采用手工记录和跟踪软件缺陷，那么有关软件缺陷的信息可以直接记录在相应的文档中。图6-5所示的是根据ANS/IEEE829—1998标准设计的软件缺陷报告文档。图6-5软件缺陷报告文档错误报告分析（一）冗长混乱的错误报告错误报告分析（二）含糊不清的错误报告

错误报告分析（三）优秀的错误报告

6.7软件测试的评测

软件测试评测是软件测试的一个阶段性结论，是用所生成的软件测试评测报告来确定软件测试是否达到完全成功的标准。软件测试评测的目的：一是量化测试进程，判断软件测试进行的状态，决定什么时候软件测试可以结束；二是为最后的测试和软件质量分析报告生成所需的量化数据，如缺陷清除率、测试覆盖率等。6.7软件测试的评测测试的评测主要方法包括覆盖评测和质量评测：覆盖评测：对测试完全程度的评测，它建立在测试覆盖基础上，测试覆盖是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。质量评测：对测试对象的可靠性、稳定性以及性能的评测。质量建立在对测试结果的评估和对测试过程中确定的缺陷及缺陷修复的分析基础上。6.7.1覆盖评测覆盖评测指标是用来度量软件测试的完全程度的，所以可以将覆盖用做测试有效性的一个度量。最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖，它们分别是指针对需求和代码的设计/实施标准而言的完全程度评测。1．基于需求的测试覆盖基于需求的测试覆盖在测试过程中要评测多次，并在测试过程中，每一个测试阶段结束时给出测试覆盖的度量。例如，计划的测试覆盖、已实施的测试覆盖、已执行成功的测试覆盖等。基于需求的测试覆盖率通过以下公式计算：基于需求的测试覆盖率=（T(p,i,x,s)/RfT）%其中，T是用测试过程或测试用例表示的已计划的、已实施的或成功的测试需求数，RfT是测试需求的总数。在制定测试计划活动中，将计算计划的测试覆盖，其计算方法如下：

计划的测试覆盖率=（Tp/RfT）%

其中，Tp是用测试过程或测试用例表示的计划测试需求数。RfT是测试需求的总数。在实施测试过程中，计算测试覆盖时使用以下公式：

已执行的测试覆盖率=Ti/RfT%

其中，Ti是用测试过程或测试用例表示的已执行的测试需求数。RfT是测试需求的总数。在执行测试活动中，确定成功的测试覆盖率评测通过以下公式计算：成功的测试覆盖率=Ts/RfT%

其中：Ts是用完全成功、没有出现缺陷或意外结果的测试过程或测试用例表示的已执行测试需求数。RfT是测试需求的总数。

在执行测试过程中，经常使用两个测试覆盖度量指标，一个是确定已执行的测试覆盖率，另一个是确定成功的测试覆盖率，即执行时未出现失败的测试覆盖率。

2．基于代码的测试覆盖

基于代码的测试覆盖评测是测试过程中已经执行的代码的多少，与之相对应的是将要执行测试的剩余代码的多少。许多测试专家认为，一个测试小组在测试工作中所要做的最为重要的事情之一就是度量代码的覆盖情况。基于代码的测试覆盖率通过以下公式计算：基于代码的测试覆盖率=Ie/TIic%

其中：Ie是用代码语句、代码分支、代码路径、数据状态判定点或数据元素名表示的已执行代码数。TIic是代码的总数。

很明显，在软件测试工作中，进行基于代码的测试覆盖评测这项工作极有意义，因为任何未经测试的代码都是一个潜在的不利因素。在一般情况下，代码覆盖运用于较低的测试等级时最为有效，例如单元和集成级。6.7.2质量评测

测试覆盖的评测提供了对测试完全程度的评价，而在测试过程中对已发现缺陷的评测提供了最佳的软件质量指标。

常用的测试有效性度量是围绕缺陷分析来构造的。缺陷分析就是分析缺陷在与缺陷相关联的一个或者多个参数值上的分布。缺陷分析提供了一个软件可靠性指标，这些分析为揭示软件可靠性的缺陷趋势或缺陷分布提供了判断依据。对于缺陷分析，常用的主要缺陷参数有以下4个。状态：缺陷的当前状态（打开的、正在修复的或关闭的等）。优先级：表示修复缺陷的重要程度和应该何时修复。严重性：表示软件缺陷的恶劣程度，反映其对产品和用户的影响等。起源：导致缺陷的原因及其位置，或排除该缺陷需要修复的构件。缺陷分析通常用以下4类形式的度量提供缺陷评测。缺陷发现率；缺陷潜伏期；缺陷密度；整体软件缺陷清除率。1．缺陷发现率

缺陷发现率是将发现的缺陷数量作为时间的函数来评测，即创建缺陷趋势图，如图6-6所示。

图6-6缺陷发现率xy2．缺陷潜伏期测试有效性的另外一个有用的度量是缺陷潜伏期，通常也称为阶段潜伏期。缺陷潜伏期是一种特殊类型的缺陷分布度量。在实际测试工作中，发现缺陷的时间越晚，这个缺陷所带来的损害就越大，修复这个缺陷所耗费的成本就越多。表6-1显示了一个项目的缺陷潜伏期的度量。

表6-2显示了一个项目的缺陷分布情况（按缺陷造成阶段和缺陷发现阶段）。按照缺陷产生阶段和缺陷发现阶段统计了一个项目的缺陷分布情况后，根据软件开发生命周期的各个阶段缺陷潜伏期度量的加权值，可以对缺陷的发现过程有效性和修复软件缺陷所耗费的成本等进行评测。这里采用了一个缺陷损耗的概念，缺陷损耗是使用阶段潜伏期和缺陷分布来度量缺陷消除活动的有效性的一种度量。

缺陷消耗可使用下面公式计算：表6-3显示了一个项目的各个缺陷损耗值，它们依据的是经过缺陷潜伏期加权的已发现的缺陷数。

如在验收测试期间，发现了9个缺陷，在这9个缺陷中，有6个是在项目的需求阶段造成的，因为在验收测试期间发现的这些缺陷可以在此之前的7个阶段中的任何一个阶段被发现，所以，我们将在验收测试阶段之前，一直保持隐藏状态的需求缺陷加权值为7。这样，在验收测试期间发现的需求缺陷的加权数值为42（即6×7=42）。

一般而言，缺陷损耗的数值越低，说明缺陷的发现过程越有效（最理想的数值应该为1）。作为一个绝对值，缺陷损耗几乎没有任何意义，但是当用缺陷损耗来度量测试有效性的长期趋势时，它就会显示出自己的价值。3．缺陷密度软件缺陷密度是一种以平均值估算法来计算出软件缺陷分布的密度值。程序代码通常是以千行为单位的，软件缺陷密度是用下面公式计算的。图6-7显示了一个项目的各个模块中每千行代码的缺陷密度。图6-7各个模块中每千行代码的缺陷密度缺陷密度这种度量方法存在的主要问题是：所有的缺陷并不都是均等构造的。各个软件缺陷的恶劣程度，及其对产品和用户的影响的严重程度，以及修复缺陷的重要程度有很大差别。

解决方法：对缺陷进行“分级、加权”处理，给出软件缺陷在各严重性级别或优先级上的分布作为补充度量，这样将使这种评测更加充分，更有实际应用价值。例如，图6-8所示的缺陷分布图表示软件缺陷在各优先级上所应体现的分布方式。图6-8各优先级上软件缺陷分布图.4．软件缺陷清除率的估算方法

为了估算软件缺陷清除率，首先需引入几个变量。F：描述软件规模用的功能点；D1：软件开发过程中发现的所有软件缺陷数；D2：软件分布后发现的软件缺陷数；D：发现的总软件缺陷数。由此可得到D=D1+D2的关系。对于一个软件项目，则可用如下的几个公式，从不同角度来估算软件的质量：·质量（每个功能点的缺陷数）=D2/F·软件缺陷注入率=D/F·整体软件缺陷清除率=D1/D例如，假设有100个功能点，而软件开发过程中发现20个软件缺陷，提交后又发现了3个软件缺陷。则F=100,D1=20,D2=3,D=D1+D2=23·质量（每个功能点的缺陷数）=D2/F=3%·软件缺陷注入率=D/F=23%·整体软件缺陷清除率=D1/D=86.96%软件缺陷评测用来度量测试的有效性，以及通过生成的各种度量来评估当前软件的可靠性，并且在预测继续测试并排除缺陷时可靠性如何增长方面是有效的。但是，这些度量本身是不充分的，在评测中需要用覆盖评测度量做补充，当与测试覆盖评测结合起来时，缺陷分析可提供出色的评估，测试完成的标准也可以建立在此评估基础上。6.7.3性能评测主要的性能评测包括以下几点。

动态监测：在测试执行过程中，实时获取并显示正在执行的各测试用例的状态。

响应时间和吞吐量：测试对象针对特定测试用例的响应时间或吞吐量的评测。

百分比报告：已收集数据类型的百分比计算与评测。

比较报告：代表不同测试执行情况的两个（或多个）数据集之间的差异或趋势。

追踪报告：测试