组合测试方法覆盖率分析
测试6种覆盖率详细解释

(1)语句覆盖。
为了个提高发现错误的可能性,在测试时应该执行到程序中的每一个语句。
语句覆盖是指设计足够的测试用例,使被测试程序中每个语句至少执行一次。
(2)判定覆盖。
判定覆盖指设计足够的测试用例,使得被测程序中每个判定表达式至少获得一次“真”值和“假”值,从而使程序的每一个分支至少都通过一次,因此判定覆盖也称分支覆盖。
(3)条件覆盖。
条件覆盖是指设计足够的测试用例,使得判定表达式中每个条件的各种可能的值至少出现一次。
(4)判定/条件测试。
该覆盖标准指设计足够的测试用例,使得判定表达式的每个条件的所有可能取值至少出现一次,并使每个判定表达式所有可能的结果也至少出现一次。
(5)条件组合覆盖。
条件组合覆盖是比较强的覆盖标准,它是指设计足够的测试用例,使得每个判定表达式中条件的各种可能的值的组合都至少出现一次。
(6)路径覆盖。
路径覆盖是指设计足够的测试用例,覆盖被测程序中所有可能的路径。
在实际的逻辑覆盖测试中,一般以条件组合覆盖为主设计测试用例,然后再补充部分用例,以达到路径覆盖测试标准。
各种覆盖率方法介绍

目录1 简介01.1 代码覆盖率分析01.2 结构化测试和功能测试(STRUCTURAL TESTING&FUNCTIONAL TESTING)11.3 假定12 基本的度量12.1 语句覆盖(STATEMENT COVERAGE )12.2 判定覆盖(DECISION COVERAGE )22.3 条件覆盖(CONDITION COVERAGE )32.4 多条件覆盖(MULTIPLE CONDITION COVERAGE )32.5 分支条件组合覆盖(CONDITION/DECISION COVERAGE )42.6 修正条件/判定覆盖(MODIFIED CONDITION/DECISION COVERAGE)42.6.1 覆盖率的计算公式:52.7 路径覆盖(PATH COVERAGE )53 其它度量63.1 函数覆盖(FUNCTION COVERAGE )63.2 函数出入口覆盖(FUNCTION EXITS COVERAGE)63.3 调用覆盖(CALL COVERAGE )63.4 线性代码顺序及跳转覆盖(LINEAR CODE SEQUENCE AND JUMP (LCSAJ) COVERAGE )73.4.1 覆盖率的计算公式:73.5 数据流覆盖(DATA FLOW COVERAGE )83.6 目标代码分支覆盖(OBJECT CODE BRANCH COVERAGE )83.7 循环覆盖(LOOP COVERAGE )83.8 竞争覆盖(RACE COVERAGE)83.9 比较操作符覆盖(RELATIONAL OPERATOR COVERAGE)83.10 弱变化覆盖(WEAK MUTATION COVERAGE)93.11 表覆盖(TABLE COVERAGE)94 比较各种覆盖94.1 对RELEASE版本的覆盖目标94.2 中间版本的覆盖目标95 总结106 参考107 术语表111 简介1.1 代码覆盖率分析这篇文章给出了一个完整的代码覆盖率分析方面的概念。
TestStand的测试用例设计和覆盖率分析

TestStand的测试用例设计和覆盖率分析TestStand是一种流程驱动的自动化测试软件平台,广泛应用于各个领域的软件测试中。
测试用例设计和覆盖率分析是TestStand中的重要组成部分,对于确保软件质量和提高测试效率具有重要意义。
一、测试用例设计测试用例设计是测试工程师在开展测试活动前必须进行的工作,它用于验证被测软件在不同条件下的功能和性能表现。
下面将介绍几种常见的测试用例设计方法:1. 等价类划分法等价类划分法是一种常用的黑盒测试方法,它将输入和输出数据分为不同的等价类,以确保测试用例具有充分的覆盖性。
例如,对于一个要求输入0-100之间的数字的软件,可以将输入数据划分为负数、0-100之间的数和大于100的数等等,每个等价类至少设计一个测试用例。
2. 边界值分析法边界值分析法是等价类划分法的一种补充,它将边界值作为测试用例的重点。
以一个要求输入1-100之间的数字的软件为例,可以设计测试用例输入1、100、0和101来验证软件的边界情况。
3. 因果图法因果图法用于处理多个输入之间的逻辑关系,通过绘制因果图来生成测试用例。
它能够将复杂的逻辑关系分解为易于理解和执行的测试用例。
因果图法对于逻辑关系复杂的系统非常有效。
4. 错误推测法错误推测法是一种常用的白盒测试方法,通过在代码中注入错误来验证软件对错误处理的能力。
测试用例设计时,需要针对可能出现的各种错误情况进行测试,如输入不合法数据、溢出、空指针等。
二、覆盖率分析覆盖率分析是测试工程师在执行测试用例后对测试过程的评估和优化。
它通过分析测试用例执行结果,统计代码中被覆盖到的部分,以评估软件测试的充分性和有效性。
下面是几种常见的覆盖率分析方式:1. 语句覆盖率语句覆盖率是指测试用例执行时是否覆盖到了软件代码中的每一条语句。
它是最基本的覆盖率指标,用于评估测试用例的充分性。
在TestStand中,可以通过代码覆盖率工具分析每个测试用例执行期间代码的覆盖情况。
测试工程师的经验分享如何提升测试用例的覆盖率

测试工程师的经验分享如何提升测试用例的覆盖率测试用例的覆盖率是衡量软件测试质量的重要指标之一。
一个高效且全面的测试用例覆盖率能够帮助测试工程师发现更多的软件缺陷,并提供更准确的测试结果。
本文将分享一些提升测试用例覆盖率的经验,希望对测试工程师们有所帮助。
一、理解需求和设计在编写测试用例之前,测试工程师首先要深入理解软件的需求和设计。
对于需求的理解不仅包括表面的功能需求,还应该关注一些隐藏的需求、界面交互和系统运行逻辑等方面。
只有真正理解了这些关键要点,测试用例才能准确地覆盖到各种场景,从而提升覆盖率。
二、使用不同的测试技术为了提高测试用例的覆盖率,测试工程师可以采用多种不同的测试技术。
常见的测试技术包括黑盒测试、白盒测试、灰盒测试等。
黑盒测试主要关注软件功能的正确性,通过测试用户界面进行测试。
白盒测试则侧重于软件内部的结构和逻辑,通过测试代码进行测试。
而灰盒测试则结合了黑盒测试和白盒测试的特点。
通过灵活应用这些测试技术,可以更全面地覆盖软件的各个方面,提升测试用例的覆盖率。
三、考虑边界条件和异常情况在编写测试用例时,测试工程师需要特别关注边界条件和异常情况。
边界条件是指输入输出值的极限情况,通过测试这些边界情况可以帮助测试工程师发现可能存在的缺陷。
而异常情况则是指软件在异常输入或者异常操作下的响应情况。
测试工程师应该针对各种可能的异常情况编写测试用例,以确保软件在异常情况下的稳定性和可靠性。
四、组合测试用例为了提升测试用例的覆盖率,测试工程师可以将不同的测试用例进行组合。
通过对不同的功能场景进行组合测试,可以更全面地覆盖各种可能的组合情况,从而发现更多的潜在缺陷。
例如,对于一个复杂的软件系统,测试工程师可以将不同的功能模块进行组合测试,以验证整个系统的稳定性和一致性。
五、优化测试用例测试工程师在编写测试用例时应该尽量避免冗余和重复的测试。
如果某个测试用例已经覆盖了某个功能点,那么就没有必要再编写相同功能的测试用例。
软件开发中的代码测试与覆盖率分析

软件开发中的代码测试与覆盖率分析在软件开发领域,代码测试是一个至关重要的环节,它是确保软件质量的有效手段之一。
随着软件规模的不断扩大和功能的增加,一个完善的代码测试策略变得尤为重要。
本文将介绍软件开发中的代码测试方法以及如何进行代码覆盖率分析。
代码测试是用于验证软件是否符合预期行为的过程。
它主要分为单元测试、集成测试和系统测试三个层次。
单元测试是最基本的测试层次,它针对软件的最小单元——函数或方法进行测试。
在单元测试中,开发人员编写测试用例,对函数的各个输入情况和边界条件进行验证。
通过单元测试,可以及早发现并解决代码中的潜在问题,确保软件的各个模块功能正常。
集成测试是将各个单元测试中的模块组合起来,测试它们之间的交互是否正确。
在集成测试中,需要模拟不同的场景和条件,验证各个模块之间的数据交换和接口调用是否正常。
通过集成测试,可以保证不同模块之间的协作正确无误。
系统测试是对整个系统进行全面的测试,验证软件是否满足用户需求和设计规格。
在系统测试中,需要模拟真实的使用环境,对软件的各个功能进行全面的测试。
通过系统测试,可以发现软件中的潜在问题和性能瓶颈,并进行相应的优化和改进。
除了以上的测试方法,代码的覆盖率分析也是一个重要的指标。
代码覆盖率是度量代码中被测试覆盖到的程度。
它衡量了代码中的哪些部分已经被测试用例覆盖到,从而判断测试的完整性和有效性。
常见的代码覆盖率分析方法包括语句覆盖、分支覆盖和路径覆盖。
语句覆盖要求每个语句至少被测试用例执行一次;分支覆盖要求每个条件的每个分支至少被测试用例执行一次;路径覆盖要求每条执行路径至少被一个测试用例覆盖到。
通过代码覆盖率分析,可以了解测试用例对代码的覆盖情况,进而确定测试的完整性和有效性。
为了提高代码的覆盖率和测试的全面性,可以采取以下几种策略:1. 设计可测试的代码:在编写代码的过程中,考虑到测试的需要,尽量使代码易于测试。
例如,良好的模块化设计和接口规范可以方便进行单元测试和集成测试。
软件测试中的代码覆盖率分析方法

软件测试中的代码覆盖率分析方法代码覆盖率分析是软件测试中的重要环节,它可以帮助开发人员评估测试是否充分覆盖了待测代码的各个分支和路径。
本文将介绍几种常见的代码覆盖率分析方法,以及它们的优缺点和适用场景。
一、语句覆盖率(Statement Coverage)语句覆盖率是最简单且最常用的代码覆盖率分析方法之一。
它的原理是通过测试用例执行情况来判断是否覆盖了每一个代码语句。
具体而言,语句覆盖率要求测试用例至少执行一次每个语句,以确保代码的执行路径被完全覆盖。
优点:语句覆盖率简单易懂,容易实施。
缺点:无法细分代码内部的分支情况,可能会导致某些分支未被覆盖。
适用场景:适用于稳定的代码,对于简单的程序或快速迭代的项目,语句覆盖率已经足够。
二、分支覆盖率(Branch Coverage)分支覆盖率是对语句覆盖率的一种扩展,它要求测试用例能够覆盖代码中的每一个分支。
通过分支覆盖率分析,开发人员可以得知每个条件语句的所有可能取值,从而判断测试是否充分考虑了不同的条件情况。
优点:相较于语句覆盖率,分支覆盖率能够更全面地测试代码的不同分支情况。
缺点:测试用例的编写难度较大,需要覆盖所有可能的分支。
适用场景:适用于逻辑较复杂的代码,对于包含多个条件语句的程序,分支覆盖率更加全面。
三、条件覆盖率(Condition Coverage)条件覆盖率是对分支覆盖率的进一步扩展,它要求测试用例能够覆盖每个条件的各种可能取值。
在代码中存在多个条件表达式的情况下,条件覆盖率能够帮助开发人员发现隐藏的逻辑错误和边界情况。
优点:对代码逻辑进行更加全面的覆盖,提高测试用例的质量。
缺点:测试用例的编写量增加,需要考虑更多的条件情况。
适用场景:适用于复杂的条件判断,例如需要满足多个条件才能进入某个分支的情况。
四、路径覆盖率(Path Coverage)路径覆盖率是最为完整的代码覆盖率分析方法,它要求测试用例能够覆盖代码中所有可能的路径。
路径是指程序执行的各种可能的组合,通过路径覆盖率分析可以确保测试覆盖了所有可能的情况。
如何有效评估测试的覆盖率与效果

如何有效评估测试的覆盖率与效果测试评估是软件开发过程中至关重要的一环。
通过对软件系统或应用进行测试评估,可以确保软件系统的稳定性和可靠性,并发现和解决潜在的问题和bug。
而评估测试的覆盖率与效果是评估测试工作质量的重要指标,本文将探讨如何有效评估测试的覆盖率与效果。
一、什么是测试覆盖率测试覆盖率是衡量测试工作完成程度的指标,它反映了测试用例对被测软件的覆盖程度。
测试覆盖率通常可以通过以下几种方式进行评估:1. 语句覆盖率:衡量被测试源代码中有多少语句被至少执行一次的测试用例覆盖到。
2. 分支覆盖率:衡量被测试源代码中的所有分支(如if语句、switch语句等)被至少执行一次的测试用例覆盖到。
3. 条件覆盖率:衡量被测试源代码中的所有条件语句(如if语句中的条件)的真假分支都至少被执行一次的测试用例覆盖到。
4. 路径覆盖率:衡量被测试源代码中所有可能的执行路径都被测试用例覆盖到。
通过评估测试覆盖率,我们可以了解测试用例是否充分覆盖了被测软件的各个部分,从而帮助我们发现测试的不足之处,并优化测试策略和用例设计。
二、如何评估测试覆盖率评估测试覆盖率是一个相对复杂的过程,需要综合考虑多个因素。
下面是几个评估测试覆盖率的常用方法:1. 静态代码分析工具:通过使用静态代码分析工具,可以对被测软件的源代码进行分析,查找可能存在的潜在问题和死代码,并根据分析结果评估测试覆盖率。
2. 代码覆盖率工具:使用代码覆盖率工具可以监控测试过程中被执行的代码行数、分支数等信息,从而计算覆盖率指标。
常见的代码覆盖率工具有JaCoCo、Cobertura等。
3. 自动化测试工具:通过编写自动化测试脚本和用例,可以有效地提高测试覆盖率。
自动化测试可以模拟多个测试场景和输入组合,并全面地执行测试用例,提高测试覆盖率。
三、如何评估测试效果除了评估测试的覆盖率,还需要评估测试的效果,即测试用例是否能够发现问题和缺陷。
以下是一些评估测试效果的方法:1. 缺陷发现率:缺陷发现率是衡量测试用例发现缺陷数量的指标。
代码覆盖率分析白盒测试的关键指标

代码覆盖率分析白盒测试的关键指标代码覆盖率是白盒测试中的一个重要指标,用于评估测试用例对于被测代码的覆盖程度。
本文将介绍代码覆盖率分析的概念、作用以及常用的几种覆盖率指标。
一、代码覆盖率分析概述代码覆盖率分析是一种通过运行测试用例,评估测试用例对于被测代码执行路径覆盖程度的技术。
它可以帮助开发人员和测试人员了解测试用例是否充分覆盖了被测代码,从而判断测试的质量和可靠性。
二、代码覆盖率指标1. 语句覆盖率(Statement Coverage)语句覆盖率是最基本的覆盖率指标之一,指的是测试用例执行过程中覆盖到的代码语句的比例。
通常以百分比的形式表示。
2. 分支覆盖率(Branch Coverage)分支覆盖率衡量的是测试用例覆盖到的代码分支的比例。
分支通常指的是if语句、switch语句等控制流程中的选择路径。
分支覆盖率高意味着测试用例能够覆盖到更多的控制流程选择路径,提高代码的可靠性。
3. 函数覆盖率(Function Coverage)函数覆盖率是指测试用例是否能够覆盖到被测代码中的所有函数。
如果测试用例无法覆盖到某个函数,那么该函数就存在未被测试到的风险。
4. 条件覆盖率(Condition Coverage)条件覆盖率是衡量测试用例是否能够覆盖到所有可能的条件组合。
条件通常指if语句、while语句等中的判断条件。
通过提高条件覆盖率,可以增加对于代码逻辑错误的发现几率。
5. 路径覆盖率(Path Coverage)路径覆盖率是指测试用例能否覆盖到所有可能的路径组合。
路径通常指的是代码中所有可能的执行路径。
路径覆盖率高意味着覆盖到的执行路径更全面,提高了对于代码错误的检测能力。
三、代码覆盖率分析的作用1. 发现代码缺陷代码覆盖率分析可以帮助开发人员和测试人员发现被测代码中的潜在缺陷。
通过分析没有被覆盖到的代码,可以定位并修复代码中的错误。
2. 提高测试用例的质量代码覆盖率分析让测试人员了解到测试用例对于被测代码的覆盖情况,从而有针对性地编写更加全面有效的测试用例,提高测试用例的质量。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
Combinatorial Coverage MeasurementD. Richard KuhnRaghu N. KackerInformation Technology Laboratory National Institute of Standards and TechnologyGaithersburg, MDYu LeiUniversity of Texas ArlingtonArlington, TX /10.6028/NIST.IR.7878CombinatorialCoverage MeasurementD. Richard KuhnRaghu N. KackerInformation Technology LaboratoryNational Institute of Standards and TechnologyGaithersburg, MDYu LeiUniversity of Texas ArlingtonArlington, TX/10.6028/NIST.IR.7878September, 2012U.S. Department of CommerceRebecca Blank, Acting SecretaryNational Institute of Standards and Technology Patrick D. Gallagher, Under Secretary of Commerce for Standards and Technology and DirectorReports on Computer Systems TechnologyThe Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL’s responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of other than national security-related information in Federal information systems.AuthorityThis publication has been developed by NIST to further its statutory responsibilities under the Federal Information Security Management Act (FISMA), Public Law (P.L.) 107-347. NIST is responsible for developing information security standards and guidelines, including minimum requirements for Federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate Federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130, Section 8b(3), Securing Agency Information Systems, as analyzed in Circular A-130, Appendix IV: Analysis of Key Sections. Supplemental information is provided in Circular A-130, Appendix III, Security of Federal Automated Information Resources.Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on Federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other Federal official. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST.National Institute of Standards and Technology Interagency Report 787816 pages (September 2012)Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose.There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by Federal agencies even before the completion of such companion publications. Thus, until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, Federal agencies may wish to closely follow the development of these new publications by NIST.Organizations are encouraged to review all draft publications during public comment periods and provide feedback to NIST. All NIST publications, other than the ones noted above, are available at /publications.C OMBINATORIAL C OVERAGE M EASUREMENTAbstract. Combinatorial testing applies factor covering arrays [6, 7] to test all t-way combinations of input or configuration state space. In some testing situations, it is not practical to use covering arrays, but any set of tests with n parameters covers at least some proportion of t-way combinations up to t ≤n. This report describes measures of combinatorial coverage that can be used in evaluating the degree of t-way coverage of any test suite, regardless of whether it was initially constructed for combinatorial coverage. Keywords-combinatorial testing; factor covering array; state-space coverage; verification and validation (V&V); t-way testing; configuration model; component interaction failure1 IntroductionBecause testing all possible combinations of input values is nearly always intractable, combinatorial testing using factor covering arrays is a reasonable alternative [8, 9, 10]. But it is not always practical to re-design an organization’s testing procedures to use tests based on covering arrays. Testing procedures often develop over time, and employees have extensive experience with a particular approach. Units of the organization may be structured around established, documented test procedures. This is particularly true in organizations that must test according to contractual requirements, or relevant standards. And because much software assurance involves testing applications that have been modified to meet new specifications, an extensive library of legacy tests may exist. The organization can save time and money by re-using existing tests, which may not have been developed as factor covering arrays.Short of creating new test suites from scratch, one approach to obtaining the advantages of combinatorial testing is to measure the combinatorial coverage of existing tests, then supplement as needed. Depending on the budget and criticality of the software, 2-way through 5-way or 6-way testing may be appropriate. Building covering arrays for some specified level of t is one way to provide t-way coverage. However, many large test suites naturally cover a high percentage of t-way combinations. If an existing test suite covers almost all 3-way combinations, for example, then it may be sufficient for the level of assurance that is required. Determining the level of input or configuration state space coverage can also help in understanding the degree of risk that remains after testing. If 90% -100% of the relevant state space has been covered, then risk is likely to be smaller than would remain after testing that covers a much smaller portion of the state space. This report describes measures of combinatorial coverage that can be helpful in evaluating the degree of t-way coverage of any test suite, regardless of whether it was initially constructed for combinatorial coverage.2 Software Test CoverageTest coverage is one of the most important topics in software assurance. Users would like some quantitative measure to judge the risk associated with less than effectively exhaustive testing. A variety of measures have been developed to gauge the degree of test coverage [2]. The following are some of the better-known coverage metrics:•Statement coverage: This is the simplest of coverage criteria – the percentage of statements exercised by the test set.•Decision or branch coverage: The percentage of branches that have been evaluated to both true and false by a test set.•Condition coverage: The percentage of conditions within decision expressions that have been evaluated to both true and false. Note that 100% condition coverage does not guarantee 100% decisioncoverage. For example, “if (A || B) {do something} else {do something else}” is tested with [0 1], [1 0], then A and B will both have been evaluated to 0 and 1, but the else branch will not be taken because neither test leaves both A and B false.•Modified condition decision coverage (MCDC): This is a strong coverage criterion that is required by the US Federal Aviation Administration for Level A (catastrophic failure consequence) software; i.e., software whose failure could lead to loss of function necessary for safe operation. It requires that every condition in a decision in the program has taken on all possible outcomes at least once, and each condition has been shown to independently affect the decision outcome, and that each entry and exit point have been invoked at least once [4].3 Combinatorial CoverageNote that the coverage measures discussed above depend on access to program source code. Combinatorial testing, in contrast, is a black box technique. Inputs are specified and expected results for assessment are determined from some form of specification. The program is then treated as simply a processor that accepts inputs and produces outputs.Suppose we have a program that accepts two inputs, x and y, with 10 values each. Then the input state space consists of the 102 = 100 pairs of x and y values, which can be pictured as a checkerboard square of 10 rows by 10 columns. With three inputs, x, y, and z, we would have a cube with 103 = 1,000 points in its input state space, and so on. Exhaustive testing would require inputs of all 10n combinations, but combinatorial testing could be used to reduce the size of the test set while ensuring that all t-way combinations for some specified level of t are covered.Looking closely at the nature of combinatorial testing leads to several measures of state space that are useful. We begin by introducing what will be called a variable-value configuration.Definition. Variable-value configuration: For a set of t variables, a variable-value configuration is a set of t valid values, one for each of the variables.Example. Given four binary variables a, b, c, and d, for a selection of three variables a, c, and d the set a=0, c=1, d=0 is a variable-value configuration, and a=1, c=1, d=0 is a different variable-value configuration.3.1 Simple t-way combination coverageOf the total number of t-way combinations for a given collection of variables, what percentage will be covered by the test set? If the test set is a covering array, then coverage is 100%, by definition, but many test sets not based on covering arrays may still provide significant t-way coverage. If the test set is large, but not designed as a covering array, it is possible that it provides 2-way coverage or better. For example, random input generation may have been used to produce the tests, and good branch or condition coverage may have been achieved. In addition to the structural coverage figure, for software assurance it would be helpful to know what percentage of 2-way, 3-way, etc. coverage has been obtained.Definition. Simple t-way combination coverage: For a given test set for n variables, simple t-way combination coverage is the proportion of t-way combinations of n variables for which all variable-values configurations are fully covered.Example. Figure 1 shows an example with four binary variables, a, b, c, and d, where each row represents a test. Of the six possible 2-way variable combinations, ab, ac, ad, bc, bd, cd, only bd and cd have all four binary values covered, so simple 2-way coverage for the four tests in Figure 1 is 1/3 = 33.3%. There are four 3-way variable combinations, abc, abd, acd, bcd, each with eight possible configurations: 000, 001, 010, 011, 100, 101, 110, 111. Of the four combinations, none has all eight configurations covered, so simple 3-way coverage for this test set is 0%.a b c d0 0 0 00 1 1 01 0 0 10 1 1 1Figure 1.An example test array for a system with four binary components3.2 (t + k)-way combination coverageA test set that provides full combinatorial coverage for t-way combinations will also provide some degree of coverage for (t+1)-way combinations, (t+2)-way combinations, etc. This statistic may be useful for comparing two combinatorial test sets. For example, different algorithms may be used to generate 3-way covering arrays. They both achieve 100% 3-way coverage, but if one provides better 4-way and 5-way coverage, then it can be considered to provide more software testing assurance.Definition. (t + k)-way combination coverage: For a given test set that provides 100% t-way coverage for n variables, (t+k)-way combination coverage is the proportion of (t+k)-way combinations of n variables for which all variable-values configurations are fully covered.Example. Suppose the test set in Figure 1 is extended as shown in Figure 2 then all four combinations of pairs of variables are covered, so 2-way coverage is 100%. Out of the four 3-way combinations abc, abd, acd, bcd only the combination bcd has all 8 variable value combinations so (2+1)-way = 3-way coverage is 25%.a b c d0 0 0 00 1 1 01 0 0 10 1 1 10 1 0 11 0 1 11 0 1 00 1 0 0Figure 2.Eight tests for four binary variables.3.3 Measures of Variable-Value Configuration coverageSo far we have only considered measures of the proportion of combinations of variables for which all configurations of t variables are fully covered. But when t variables with v values each are considered, each t-tuple has v t possible variable-value configurations. For example, in pairwise (2-way) coverage of binary variables, every 2-way combination has four configurations: 00, 01, 10, 11. We define two measures with respect to such variable-value configurations:Definition. Variable-value configuration coverage: For a given combination of t variables, variable-value configuration coverage is the proportion of variable-value configurations that are covered by at least one test case in a test set.For (t+k)-way coverage where k = 1, Chen and Zhang [3] have proposed the tuple density metric. A special metric for (t+1)-way coverage is useful because (1) the coverage of higher strength tuples for t’ > t+1 is much lower (because the number of t-way combinations to be covered grows exponentially with t), (2) the coverage at t+1 provides some information for coverage at t’ > t+1 because (t+1)-way tuples are subsumed by higher strength tuples, and (3) the number of additional faults triggered by t-way combinations drops rapidly with t > 2 [10].Definition. Tuple Density: Sum of t and the fraction of the covered (t+1)-tuples out of all possible (t+1)-tuples [3].Example. As shown in the previous example, the test set in Figure 2 provides 100% coverage of 2-way combinations and 25% coverage of 3-way combinations, so the tuple density of this test set is 2.25.Definition. (p, t)-completeness: For a given set of n variables, (p, t)-completeness is the proportion of the C(n, t) combinations that have configuration coverage of at least p [11].Example. For Figure 1 above, there are C(4, 2) = 6 possible variable combinations and C(4, 2) × 22 = 24 possible variable-value configurations. Of these, 19 variable-value configurations are covered and the only ones missing are ab=11, ac=11, ad=10, bc=01, bc=10. But only two, bd and cd, are covered with all 4 value pairs. So for the basic definition of simple t-way coverage, we have only 33% (2/6) coverage, but 79% (19/24) for the variable-value configuration coverage metric. For a better understanding of this test set, we can compute the configuration coverage for each of the six variable combinations, as shown in Figure 3. So for this test set, one of the combinations (bc) is covered at the 50% level, three (ab, ac, ad) are covered at the 75% level, and two (bd, cd) are covered at the 100% level. And, as noted above, for the whole set of tests, 79% of variable-value configurations are covered. All 2-way combinations have at least 50% configuration coverage, so (.50, 2)-completeness for this set of tests is 100%. Although the example in Figure 1 uses variables with the same number of values, this is not essential for the measurement, and the same approach can be used to compute coverage for test sets in which parameters have differing numbers of values.Vars Configurationsd Configa b 00, 01, 10 .75a c 00, 01, 10 .75a d 00, 01, 11 .75b c 00, 11 .50b d 00, 01, 10, 11 1.0c d 00, 01, 10, 11 1.0total 2-way cove rage = 19/24 = .79167(.50, 2)-completeness = 6/6 = 1.0(.75, 2)-completeness = 5/6 = 0.83333(1.0, 2)-completeness = 2/6 = 0.33333Figure 3.The test array covers all possible 2way combinations of a, b,c,and d to different levels.The graph in Figure 4 shows a graphical display of the coverage data for the tests in Figure 3. Coverage is given as the Y axis (ordinate), with the percentage of combinations reaching a particular coverage level as the X axis (abscissa). Note from Fig. 1 that 100% of the combinations are covered to at least the .50 level, 83% are covered to the .75 level or higher, and a third covered 100%. Thus the rightmost horizontal line on the graph corresponds to the smallest coverage value from the test set, in this case 50%. Thus (.50, 2)-completeness = 100%.Figure 4.Graph of coverage from Figure 3 test data.Note that the total 2-way coverage is shown as 0.792. This figure corresponds approximately to the area under the curve in Figure 4. (The area is not exactly equal to the true figure of 0.792 because the curve is plotted in increments of 0.05.) Additional tests can be added to provide greater coverage. Suppose an additional test [1,1,0,1] is appended to figure 1 Coverage then increases as shown in Figure 5. Now we can see immediately that all combinations are covered to at least the 75% level, as shown by the rightmost horizontal line (in this case there is only one horizontal line). The leftmost vertical line reaches the 1.0 level of coverage, showing that 50% of combinations are covered to the 100% level.Figure 5.Coverage after test [1,1,0,1] is appended.Note that the upper right corner includes roughly 25 squares, so the area under the curve is 175/200, or 87.5%, matching the Total 2-way coverage figure. Appending one more test, [1,0,1,1] results in the coverage shown in Figure 6.Figure 6.Coverage after test [1,0,1,1] is appended.If a test [1,0,1,0] is then appended, 100% coverage for all combinations is reached, as shown in Figure 7. The graph can thus be thought of as a “coverage strength meter”, where the red indicator line moves to the right as higher coverage levels are reached. A covering array, which by definition covers 100% of variable-value configurations will always produce a figure as below, with full coverage for all combinations.Figure 7.Appending test [1,0,1,0] provides 100% coverage, i.e., a covering array. Consider the graph in Figure 8 corresponding to test set in figure 1. The symbol Φindicates the proportion of combinations with 100% variable-value coverage, and Μindicates the minimum proportion of coverage for all t-way variable combinations. In this case 33% (Φ) of the combinations have full variable-value coverage, and all variable combinations are covered to at least the 50% level (Μ). So (1.0, 2)-completeness = Φand (Μ, 2)-completeness = 100%, but it is helpful to have more intuitive terms for the points Φand Μ. Note that Φis the level of simple t-way coverage. Since all combinations are covered to at least the level of Μ, we will refer to Μas the “t-way minimum coverage”, keeping in mind that “coverage” refers to a proportion of variable-value configuration values. Where the value of t is not clear from the context, these measures are designated Φt and Μt. Using these terms we can analyze the relationship between total variable-value configuration coverage, t-way minimum coverage and simple t-way coverage.Figure 8.Example coverage graph for t = 2.Let S t = total variable-value coverage, the proportion of variable-value configurations that are covered by at least one test. If the area of the entire graph is 1(i.e., 100% of combinations), thenS t ≥1 -(1-Φt)(1-Μt)S t ≥Φt + Μt – Φt Μt (1)If a test suite has only one test, then it covers C(n, t) combinations. The total number of combinations that must be covered is C(n,t) × v t, so the coverage of one test is 1/v t . Thus,t-way minimum coverage : Μt ≥1t> 0. (2) vtThus, for any non-empty test suite, t-way minimum coverage ≥1/v. This can be seen in Figure 9, which shows coverage for a single test with ten binary variables, where 2-way minimum coverage is 25%. With only one test, 2-way full coverage is of course 0, and S = total variable-value coverage (denoted “Total t-way” on the graph legend) is 25%.Figure 9.Coverage for one test, 10 binary variables.3.4 Example ApplicationThe methods described in this report were originally developed to analyze the state space coverage of spacecraft software [11]. A very thorough set of over 7,000 tests had been developed for each of three systems. At that time combinatorial coverage was not the goal. With such a large test suite, it seemed likely that a huge number of combinations had been covered, but how many? Did these tests provide 2way, 3-way, or even higher degree coverage? If an existing test suite is relatively thorough, it may be practical to supplement it with a few additional tests to bring coverage up to the desired level.(2) (1)Figure 10.Configuration coverage for 132754262inputs.The original test suites had been developed to verify correct system behavior in normal operation as well as a variety of fault scenarios, and performance tests were also included. Careful analysis and engineering judgment were used to prepare the original tests, but the test suite was not designed according to criteria such as statement or branch coverage. The system was relatively large, with the 82 variable configuration 132754262 (three 1-value, 72 binary, two 4-value, and two 6-value). Figure 10 shows combinatorial coverage for this system (red = 2-way, blue = 3-way, green = 4-way). This particular test set was not a covering array, but pairwise coverage is still relatively good, with about 99% of the 2-way combinations having at least 75% of possible variable-value configurations covered (1), and 82% have 100% of possible variable-value configurations covered (2).3.5 Analysis of Test StrategiesThese coverage metrics can be used to analyze various testing strategies by measuring the combinatorial coverage they provide. To illustrate this type of analysis, some examples are discussed in this section.All-values: Consider the t-way coverage from one of the most basic test criteria, all-values, also called “each-choice” [2]. This strategy requires that every parameter value be covered at least once. If all parameters have the same number of values, v, then only v tests are needed to cover all. Test 1 has all parameters set to v1, Test 2 to v2, and so on. If parameters have different numbers of values, where p1 .. p n have v i values each, the number of tests required is at least Max i=1,n v i.Example: If there are three values, 0, 1, and 2, for five parameters, then 0,0,0,0,0; 1,1,1,1,1; and 2,2,2,2,2 will test all values once. As shown above, each test covers 1/v t of the variable-value configurations, and no combination appears in more than one test, so with v values per parameter and thus v tests, we have1 1Μt (all-values ) ≥ v = t t −1v v (3) Therefore, for the all-values criterion, where all values are covered at least once, minimum coverage Μ ≥ 1/v t-1.We can also reach this result by noting that each test covers C(n , t ) combinations, so with v values the proportion of combinations covered is v C(n ,t )/C(n ,t )v t = 1/v t -1. This relationship can be seen in Figure 11, which shows coverage for two tests with ten binary variables; 2-way minimum coverage = .5, and 3way coverage = .25.Figure 11. tway coverage for two tests with binary values. Base choice : Base-choice testing [1] requires that every parameter value be covered at least once and in a test in which all the other values are held constant. Each parameter has one or more values designated as base choices. The base choices can be arbitrary, but can also be selected as “special interest” values, e.g., default values, or values that are used most often in operation. If parameters have different numbers of values, where p 1 .. p n have v i values each, the number of tests required is at least 1 + Σ i =1,n (v i -1), or where all n parameters have the same number of values v , the number of tests is 1+n (v -1). An example is shown below in 0, with four binary parameters. a b c d base: 0 0 0 0 test 2 1 0 0 0 test 3 0 1 0 0 test 4 0 0 1 0 test 51Figure 12.Base choice test suite for a 24 configuration The base choice strategy can be highly effective, despite its simplicity. In one study of five programs seeded with 128 faults [8], it was found that “although the Base Choice strategy requires fewer test cases than Orthogonal Arrays and AETG, it found as many faults [8].” In that study, AETG [5] was used to generate2-way (pairwise) test arrays. We can use combinatorial coverage measurement to help understand this finding. For this example of analyzing base choice, we will consider n parameters with 2 values each.First, note that the base test in which each parameter takes its base choice covers C(n , t ) combinations, so for pairwise testing this is C(n , 2) = n (n -1)/2. Changing a single value of the base test to something else will covern -1 new pairs (in our example, ab , ac , and ad have new values in test 2, whilebc and bd are unchanged). This must be done for each parameter, so we will have the original base test combinations plus n (n -1) additional combinations. The total number of 2-way combinations is C(n , 2) × 22, so for n binary parameters:n (n −1) / 2 + n (n −1)Μt (2-way binary base-choice ) = C (n ,2)22C (n ,2) + 2C (n ,2)= C (n ,2)22= 3/4. Figure 13. Graph of 2way coverage for test set in 0. This can be seen in the graph in Figure 13 of coverage for 0. Note that the 75% coverage level is independent of n . For v > 2, the analysis is a little more complicated. The base choice test covers C(n , 2) combinations, and each new test covers n -1 new combinations, but we need v -1 additional tests beyond the base choice for v values. So the proportion of 2-way combinations covered by the base choice strategy in general is: C (n ,2) + (v −1)2C (n ,2)Μt (base-choice ) = C (n ,2)v21+ 2(v −1)= 2vFor example, with v = 3 values per parameter, we still cover 55.6% of combinations, and with v = 4, coverage is 43.75%. This analysis helps explain why the base choice strategy can be effective even if it does not achieve full 2-way coverage. This equation can be generalized to higher interaction strengths. The base test covers C(n ,t ) combinations, and each new test covers C(n -1,t -1) new combinations, since the parameter value being varied can be combined with t -1 other parameters for each t -way combination. Base choice testing requires n (v -1) additional tests beyond the initial one, so for any n , t with n ≥ t C (n ,t ) + n (v −1)C (n −1,t −1)Μt (base-choice ) = C (n ,t )v tC (n ,t ) + t (v −1)C (n ,t )= C (n ,t )v t1+t(v −1)=v t (4)3.6 Analysis of (t+1)-way CoverageA t-way covering array by definition provides 100% coverage at strength t, but it also covers some (t+1)way combinations (assuming n ≥t+1). Using the concepts introduced previously we can investigate minimal coverage levels for (t+1)-way combinations in covering arrays. Given a t-way covering array, for any set of t+1 parameters, we know that any combination of t parameters is fully covered in some set of tests. Joining any other parameter with any combination of t parameters in the tests will give a (t+1)way combination, which has v t+1 possible settings. For any set of tests covering all t-way combinations, the proportion of (t+1)-way combinations covered is thus v t/v t+1, so if we designate (t+1)-way variable-value configuration coverage as S t+1, thenS t+1 ≥1 for any t-way covering array with n ≥t+1. (5)vNote that variable-value configuration coverage is not the same as simple t-way coverage, which gives the proportion of t-way configurations that are 100% covered. Clearly no set of (t+1)-way combinations will be fully covered with a t-way covering array if N < v t+1, where N = number of tests. For most levels of t and v encountered in practical testing, this condition will hold. For example, if v=3, then a 2-way covering array with less than 33=27 tests can be computed (using IPOG-F) for any test problem with less than 60 parameters. So the proportion of combinations with full variable-value coverage, designated Φ, will be zero for 3-way coverage for this example. And in general, designating (t+1)-way full variable-value configuration coverage as Φt+1, if N < v t+1, then Φt+1 = 0, for any t-way covering array with n ≥t+1.As an additional illustration, we show that expression (5) can also be reached by noting that with a t-way covering array, unique (t+1)-way combinations can be identified as follows: traversing the covering array, for the first appearance of each t-way combination, append each of the n-t parameters not contained in the t-way combination to create a (t+1)-way combination. This procedure counts each (t+1)-way combination C(t+1, t) = t+1 times. The covering array contains C(n,t)v t t-way combinations, so the proportion of (t+1)-way combinations, S t+1 , in the t-way array is at leastC(n,t)v t (n −t) /( t+1) 1=t+1C(n,t +1)v vIn most practical cases, the (t+1)-way coverage of a t-way array will be higher than 1/v .3.7 Summary1. Many coverage measures have been devised for code coverage, including statement, branch ordecision, condition, and modified condition decision coverage. These measures are based on aspects of source code and are not suitable for combinatorial coverage measurement.2. Combinatorial coverage measurements may be useful in understanding test set thoroughness and foranalyzing test strategies. Measures include simple t-way coverage, tuple density, variable-value configuration coverage, t-way minimum coverage, and (p,t)-completeness. Test strategies differ in the level of coverage they provide as measured by these concepts.。