下载文档原格式
白盒测试的测试方法白盒测试是一种测试软件系统内部结构和实现细节的测试方法，也被称为结构测试或透明盒测试。
白盒测试的目标是验证软件系统是否按照设计要求正确地执行，并且对系统内部的各个组件和逻辑路径进行全面的测试。
白盒测试需要测试人员具备一定的编程和代码理解能力，因为测试人员需要分析系统的源代码、程序逻辑和内部数据结构来设计测试用例，并理解代码的执行过程和运行结果。
白盒测试的方法有很多，下面将介绍几种常用的白盒测试方法：1. 代码覆盖率分析：代码覆盖率是衡量测试用例对代码的覆盖程度的指标。
常见的代码覆盖率分析方法有语句覆盖、判定覆盖、条件覆盖和路径覆盖等。
通过分析代码的覆盖率，可以确定测试用例的完备性和测试效果。
2. 边界值分析：边界值分析是一种设计测试用例的方法，通过测试系统在各个边界条件下的行为来发现潜在的错误和异常情况。
常见的边界条件包括最小值、最大值、临界值和非法输入等。
3. 错误推测：错误推测是一种通过主动插入错误来测试系统对异常情况的处理能力的方法。
测试人员可以在系统的关键位置插入错误代码或输入错误数据，观察系统的反应和处理结果，从而验证系统的健壮性和容错性。
4. 数据流分析：数据流分析是一种分析程序中数据流动路径的方法，用于评估程序的正确性和性能。
通过分析数据在程序中的产生、传递和使用过程，可以找出数据依赖性、数据冗余和数据丢失等问题。
5. 代码审查：代码审查是一种通过对软件源代码进行逐行检查和评审的方法，以发现存在的错误、潜在的问题和不良的编程实践。
代码审查可以通过静态分析工具和人工审查相结合的方式进行。
6. 单元测试：单元测试是白盒测试的一种重要方法，用于对系统中最小可测试单元进行测试。
单元测试一般通过驱动程序或测试框架来调用被测单元，并对其进行输入和输出结果的验证。
7. 逻辑覆盖测试：逻辑覆盖测试是一种通过测试不同的逻辑路径来覆盖程序的所有可能执行路径的方法。
通过设计合适的测试用例，可以验证程序的各种条件判断、循环控制和算术运算等逻辑运算的正确性。
测试⽤例设计--⿊盒测试、⽩盒测试测试⽤例设计设计数据库测试⽤例就是针对数据库的功能和性能⽽设计的测试⽅案，并编⼊测试计划中。
测试⽤例的设计既要考虑正常情况，也应考虑极限情况以及字段取最⼤值和最⼩值等边界情况。
因为测试的⽬的是暴露数据库中隐藏的错误和缺陷，所以在设计测试⽤例时要充分考虑那些易于发现错误和缺陷的测试⽤例。
好的测试⽤例应该有较⾼的发现错误和缺陷的概率。
⽩盒测试的测试⽤例设计逻辑覆盖法和基本路径测试法是计算机软件⽩盒测试⽤例设计的两个重要⽅法。
这两个⽅法也适合存储过程、触发器、嵌⼊式SQL等数据库程序的测试。
语句覆盖语句覆盖语句覆盖是设计⾜够多的测试⽤例，运⾏所测程序，使得程序中每条可执⾏语句⾄少被执⾏⼀次。
不过，每条可执⾏语句⾄少执⾏⼀次是最基本的要求，但是它不能保证发现逻辑运算和程序逻辑错误，且并不是所有的分⽀被执⾏过。
例6-1 考虑图6-2，语句覆盖的测试⽤例如表6-1所⽰。
注意，该组测试⽤例不能覆盖判断E为假的分⽀。
⽽且，如果判断C误写为X>2 or Y>3，该组测试⽤例仍能够实现语句覆盖，因此该组测试⽤例发现不了这个错误。
测试⽤例⼀般不是唯⼀的。
例如，表6-2的测试⽤例也可以实现语句覆盖。
判定覆盖判定覆盖⼜称分⽀覆盖，是设计⾜够多的测试⽤例，运⾏所测程序，使得程序中每个判断的取真分⽀和取假分⽀分别⾄少执⾏⼀次。
例6-2 考虑图6-2，其中C、E为判断。
判定覆盖的测试⽤例如表6-3所⽰。
虽然判定覆盖能够保证所有判断的取真分⽀和取假分⽀执⾏⾄少⼀次，但判定覆盖不能保证发现条件表达式错误。
例如，如果语句C误写为X>2 or Y>3，表6-3给出的测试⽤例仍能够实现判定覆盖，因此该组测试⽤例发现不了这个错误。
条件覆盖条件覆盖是设计⾜够多的测试⽤例，运⾏所测程序，使得每个判断的每个条件成分取真值和假值分别⾄少执⾏⼀次。
例6-3 考虑图6-2。
⾸先对所有判断的条件成分取值进⾏标记：v条件覆盖的测试⽤例如表6-4所⽰。
白盒测试的主要步骤白盒测试是软件开发过程中的一种测试方法，通过查看和分析软件的内部结构和代码来评估其质量。
在进行白盒测试时，测试人员需要按照一系列步骤来完成这个过程，以确保软件系统的功能和性能符合预期。
下面是白盒测试的主要步骤：1. 确定测试的目标和范围在进行白盒测试之前，首先需要明确测试的目标和范围。
测试人员需要了解要测试的软件系统的功能和特性，并确定需要覆盖的代码范围和测试重点。
2. 分析需求和设计文档测试人员需要仔细分析软件系统的需求和设计文档，以了解系统的架构和功能。
这有助于测试人员确定哪些部分需要进行测试以及如何设计测试用例。
3. 编写测试用例根据需求和设计文档，测试人员编写白盒测试用例。
测试用例应涵盖不同的代码路径和边界条件，以确保软件系统的每个功能都得到充分测试。
4. 执行测试用例测试人员执行编写的测试用例，同时记录测试结果。
在执行测试用例的过程中，需要验证软件系统的功能是否按照需求文档的规范工作，同时检查是否存在潜在的缺陷和问题。
5. 分析测试结果一旦测试完成，测试人员需要分析测试结果并检查是否存在失败的测试用例。
通过分析测试结果，可以确定软件系统的稳定性和质量，并识别需要改进的地方。
6. 跟踪和修复缺陷测试人员应该跟踪所有发现的缺陷，并确保这些缺陷得到及时修复。
跟踪缺陷的过程可以协助开发团队更好地理解和解决问题，提高软件系统的质量。
结语白盒测试是软件开发过程中必不可少的一环，通过深入了解和分析软件系统的内部结构来确保其质量和可靠性。
遵循上述步骤可以帮助测试人员高效地完成白盒测试，并为软件系统的发布提供有力的支持。
白盒测试中的测试自动化如何实现自动化的白盒测试流程白盒测试是软件测试中的一种重要方法，旨在对软件系统的内部运行逻辑和结构进行检查和验证。
随着软件开发行业和技术的不断进步，越来越多的测试工作开始采用自动化的方式来提高效率和准确性。
本文将探讨白盒测试中的测试自动化以及如何实现自动化的白盒测试流程。
一、白盒测试自动化的意义在传统的白盒测试中，测试人员需要手动编写测试用例、执行测试、记录结果等一系列操作。
这种方式不仅费时费力，还容易出现人为错误。
而通过测试自动化，可以将这些重复、规模庞大的任务交给计算机来完成，提高测试效率、减少错误和成本。
二、实现自动化的白盒测试流程1. 环境准备在进行白盒测试自动化之前，首先需要搭建好测试环境。
这包括安装测试工具、编写测试框架、配置测试环境等。
测试工具可以根据具体业务需求选择，常用的包括Selenium、JUnit、TestNG等。
测试框架则需要根据项目的特点和测试需求进行设计和搭建。
2. 制定测试计划测试计划是测试工作的重要组成部分，包括测试目标、测试策略、测试范围、测试资源等。
在进行白盒测试自动化时，需要针对自动化测试的特点进行相应的测试计划制定。
这包括确定测试的覆盖范围、编写测试用例、选择合适的自动化工具等。
3. 编写测试用例在自动化的白盒测试中，编写测试用例是至关重要的一步。
测试用例应该覆盖系统的各种业务逻辑和功能点，并针对每个功能点设计相应的测试场景。
测试用例需要准确明确地描述预期结果和输入条件，以便自动化工具可以进行匹配和验证。
4. 实施自动化测试一旦测试用例编写完成，就可以进行自动化测试的实施。
这包括使用自动化工具执行测试用例、记录测试结果、生成测试报告等。
在执行过程中，可以根据需要进行参数化、循环、分支等控制，以模拟各种测试场景。
5. 分析测试结果自动化测试完成后，就需要对测试结果进行分析和评估。
分析测试结果可以帮助找出系统的问题和缺陷，并进行相应的优化和改进。
白盒测试功能测试1. 介绍白盒测试是软件测试中的一种重要测试方法，旨在检查软件的内部结构和代码逻辑。
而在白盒测试中，功能测试则是其中的一个重要部分。
功能测试是验证软件系统的功能是否按照需求规格书中的描述正常工作的过程。
在本文中，我们将专注于讨论白盒测试中的功能测试。
2. 功能测试的定义功能测试是一种黑盒测试方法，可确保软件在用户操作下的正常工作。
在进行功能测试时，测试人员会根据需求规格书中的功能描述，校验软件是否符合预期的功能特性。
功能测试依赖于需求文档和用户场景，通过模拟用户操作来验证软件的功能。
3. 白盒测试中的功能测试流程在白盒测试中，功能测试主要包括以下几个步骤：•制定测试计划：确定测试的范围、测试的重点以及测试的时间安排。
•设计测试用例：根据功能需求书设计测试用例，覆盖主要的功能路径以及边界条件。
•执行测试用例：按照设计的测试用例逐一执行测试，记录测试结果和发现的问题。
•缺陷跟踪和修复：将测试中发现的问题记录在缺陷跟踪系统中，并协助开发人员修复问题。
•测试报告编写：整理测试过程中的执行结果和问题汇总，编写测试报告。
4. 功能测试的目标功能测试的主要目标是验证软件的功能是否正确实现，包括以下几个方面：•功能完整性：确保软件的功能完全实现，不缺失任何功能。
•功能正确性：验证软件的功能按照需求规格书中的描述正确执行。
•边界条件处理：测试软件在各种边界条件下的处理能力。
•用户友好性：验证软件的用户界面是否友好并易于操作。
•性能：对功能进行性能测试，确保软件在一定负载下稳定运行。
5. 功能测试的优势功能测试在白盒测试中具有以下几个优势：•覆盖面广：功能测试能够覆盖软件的主要功能，在用户角度上进行验证。
•易于理解：功能测试基于需求文档进行设计，易于理解和执行。
•发现问题及时：通过功能测试能够及时发现软件的功能问题，提高软件质量。
6. 总结在白盒测试中，功能测试是一个非常重要的测试环节，通过对软件功能的验证，可以确保软件的功能实现正确且完整。
1.白盒测试方法语句覆盖语句覆盖就是设计若干个测试用例, 运行所测程序,使得每一可执行语句至少执行一次. 对上面例子, 正好所有的可执行语句都在路径L1上, 所以选择路径L1来设计测试用例,就可覆盖所有的可执行语句.测试用例的设计格式如下：[输入(A,B,X), 预期的输出(A,B,X)]可设计出满足语句覆盖的测试用例是:[(2,0,4), (2,0,3)], 覆盖ace [L1]从每个执行语句都得到执行这一点来看, 语句覆盖的方法似乎能够比较全面地经验每个可执行语句. 但实际上并非如此.不足:假如该程序段中的两个逻辑运算有问题, 例如, 第一个判断中的逻辑运算符"∧"错写成了"∨", 或者第二个判断中的逻辑运算符"∨"错写成了"∧", 利用上面的测试用例, 仍然可覆盖所有4个可执行语句. 这说明虽然做到了语句覆盖测试, 但可能发现不了判断中逻辑运算中出现的错误.语句覆盖是最弱的逻辑覆盖准则.判定覆盖判定覆盖就是设计若干个测试用例, 运行所测程序, 使得程序中每个判断的取TURE分支和取FALSE分支至少经历一次. 判断覆盖又称分支覆盖.根据定义,可分别选择路径L1 和L2 或路径L3和L4设计测试用例.如果选择路径L1 和L2, 可得到满足要求的测试用例:[(2,0,4), (2,0,3)], 覆盖ace[L1][(1,1,1), (1,1,1)], 覆盖abd[L2]如果选择路径L3和L4, 可设计另一组测试用例:[(2,1,1), (2,1,2)], 覆盖abe[L3][(3,0,3), (3,1,1)], 覆盖acd[L4]可看出,测试用例的选择不唯一.不足: 假如第二个判断中的条件x>1被错写成了x<1, 利用上面两组测试用例, 仍能得到同样的结果. 这表明, 只是判断覆盖, 还不能保证一定能查出在判断的条件中存在的错误. 条件覆盖条件覆盖就是设计若干个测试用例, 运行所测程序, 使得程序中每个判断的每个条件的可能取值至少执行一次. 因此首先要对所有的条件加以标记:对第一个判断: 条件A>1 取TURE 时为T1, 取FALSE时为F1条件B=0 取TURE 时为T2, 取FALSE时为F2 对第二个判断: 条件A=2 取TURE 时为T3, 取FALSE时为F3条件x>1 取TURE 时为T4, 取FALSE时为F4根据这8个条件取值, 可分别设计如下两组测试用例:表1(第一组):表2(第二组)从表1和2可看出, 两组测试用例都满足了条件覆盖, 即覆盖了所有的条件取值.不足: 第一组测试用例不满足判定(分支)覆盖要求.判定-条件覆盖判定-条件覆盖就是设计足够的测试用例,使得判断中每个条件的所有可能取值至少执行一次,同时每个判断的所有可能判断结果至少执行一次. 也就是说要求各个判断的所有可能的条件取值组合至少执行一次.根据判定-条件覆盖的定义，只需设计下面两个测试用例便可覆盖例子的8个条件取值以及4个判断分支.不足: 表面来看, 判断-条件覆盖测试了所有条件的取值, 但实际上并非如此, 而是某些条件掩盖了另一些条件(由于多重条件判定). 例如, 对条件表达式(A>1) AND (B=0) 来说, 若(A>1)的测试结果为FALSE 时, 可以立即确定表达式的结果为FALSE, 这时往往就不再测试(B=0)的取值了, 因此, 条件(B=0)就没有被检查. 同样, 对条件表达式(A=2) OR (x>1)来说, 若(A=2)的测试结果为TURE时, 就立即确定表达式的结果为TURE, 这时, 条件(x>1)就没有被检查.因此, 采用判定-条件覆盖测试, 逻辑表达式中的错误不一定能够查得出来.条件组合覆盖条件组合覆盖就是实际足够得测试用例, 运行所测程序, 使得每个判断得所有可能得条件取值组合至少执行一次.针对上面的例子, 先对各个判断的条件取值组合加以标记:对每个判断,要求所有可能的条件取值的组合都必须取到. 每个判断各有两个条件, 所以各有4个条件取值的组合. 注: 这里没有要求第一个判断的4个组合再与第二个判断的4 个组合进行组合(16).设计4个测试用例, 就可覆盖上面8种条件组合.这些测试用例覆盖了所有条件的可能取值的组合, 覆盖了所有判断的可取分支.不足: 没有覆盖路径L4, 这样测试还不完全.路径覆盖路径测试就是设计足够的测试用例, 覆盖程序中所有可能的路径. 可设计下面的4个测试用例覆盖全部4条路径.不足: 没有全部覆盖判断的条件取值的组合. 如②③⑥测试用例的组合和优化对该例子, 采用逻辑覆盖方法中的一种,都不能满足所有需求, 如果每种方法都采用, 又有测试用例的重复. 如何用最少的测试例而实现最多的需求? 在测试设计中, 是一个值得考虑和解决的问题. 对本例子, 我们采用条件组合覆盖和路径覆盖两种方法设计测试用例, 并进行优化, 可得采用上面的6个测试用例, 可满足所有逻辑覆盖测试.注1:基本路径测试: 实际中, 一个模块中的路径可能非常多, 由于时间和资源, 不可能一一测试到. 这就需要把测试所有可能路径的目标减少到测试足够多的路径以获得对于模块的信心. 要测试的最小路径集--基本测试路径集要保证: ①每个确定语句的每一个方向要测试到;②每条语句最少执行一次.由于时间, 有关基本路径测试的方法这里省略.注2: 循环测试: 测试循环是一种特殊的路径测试. 因为循环比其他语句都复杂一些,循环测试值得一提.循环中错误的发生机会比其他代码构成部分都多.因此对于任何给定的循环的测试应该包括测试下面每一个条件的测试用例:①循环不执行;②执行一次循环;③执行两次循环;④反映执行典型的循环的执行次数;⑤如果有最大循环次数,最大循环次数减一;⑥最大循环次数;⑦大于最大循环次数. 对于增量和减量不是 1 的FOR 语句,要特别注意, 因为程序员习惯1 增量.注3: 循环嵌套: 循环嵌套使逻辑的次数呈几何级数增长. 设计测试嵌套循环的测试用例应该包括的测试条件有: ①把外循环设置为最小值并运行内循环所有可能的情况;②把内循环设置为最小值并运行外循环所有可能的情况;③把所有的循环变量都设置为最小值运行;④把所有的循环变量都设置为最大值运行;⑤把外循环设置为最大值并运行内循环所有可能的情况;⑥把内循环设置为最大值并运行外循环所有可能的情况.注4: 边界值测试: 是指专门设计用来测试当条件语句中引用的值处在边界或边界附近时系统反映的测试. 被测试语句的最好的例子就是"IF--THEN...ELSE-ENDIF"部分.这样语句的例子如:IF a<=123 THENb=1ELSEIF a>=123 THENb=2ELSEb=31ENDIF上面例子的边界值测试用例应该至少包括a的以下值: 122,123,124. 当A=123时, b=1还是2?.2.黑盒测试规范（规格）导出法规范导出的测试是根据相关的规范描述来设计测试用例。
软件测试中如何编写单元测试用例（白盒测试）测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
测试用例（Test Case）目前没有经典的定义。
比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。
内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。
不同类别的软件，测试用例是不同的。
不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。
笔者主要从事企业管理软件的测试。
因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。
测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。
对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。
随着中国软件业的日益壮大和逐步走向成熟，软件测试也在不断发展。
从最初的由软件编程人员兼职测试到软件公司组建独立专职测试部门。
测试工作也从简单测试演变为包括：编制测试计划、编写测试用例、准备测试数据、编写测试脚本、实施测试、测试评估等多项内容的正规测试。
测试方式则由单纯手工测试发展为手工、自动兼之，并有向第三方专业测试公司发展的趋势。
要使最终用户对软件感到满意,最有力的举措就是对最终用户的期望加以明确阐述，以便对这些期望进行核实并确认其有效性。
测试用例反映了要核实的需求。
然而，核实这些需求可能通过不同的方式并由不同的测试员来实施。
例如，执行软件以便验证它的功能和性能，这项操作可能由某个测试员采用自动测试技术来实现；计算机系统的关机步骤可通过手工测试和观察来完成；不过，市场占有率和销售数据（以及产品需求），只能通过评测产品和竞争销售数据来完成。
既然可能无法（或不必负责）核实所有的需求，那么是否能为测试挑选最适合或最关键的需求则关系到项目的成败。
选中要核实的需求将是对成本、风险和对该需求进行核实的必要性这三者权衡考虑的结果。
确定测试用例之所以很重要，原因有以下几方面。
测试用例构成了设计和制定测试过程的基础。
测试的“深度”与测试用例的数量成比例。
由于每个测试用例反映不同的场景、条件或经由产品的事件流，因而，随着测试用例数量的增加，您对产品质量和测试流程也就越有信心。
判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这又是以确定、实施和/或执行的测试用例的数量为依据的。
类似下面这样的说明：“95 % 的关键测试用例已得以执行和验证”，远比“我们已完成95 % 的测试”更有意义。
测试工作量与测试用例的数量成比例。
根据全面且细化的测试用例，可以更准确地估计测试周期各连续阶段的时间安排。
测试设计和开发的类型以及所需的资源主要都受控于测试用例。
测试用例通常根据它们所关联关系的测试类型或测试需求来分类，而且将随类型和需求进行相应地改变。
最佳方案是为每个测试需求至少编制两个测试用例：·一个测试用例用于证明该需求已经满足，通常称作正面测试用例；·另一个测试用例反映某个无法接受、反常或意外的条件或数据，用于论证只有在所需条件下才能够满足该需求，这个测试用例称作负面测试用例。
前段时间公司进行有关测试的培训，集成测试，性能测试，压力测试说了很多。
由于本人还处于Coder阶段，只是对单元测试有了些了解。
写下来怕以后自己忘记了。
都是些自己的看法，不一定准确，欢迎高手指教。
一、单元测试的概念单元通俗的说就是指一个实现简单功能的函数。
单元测试就是只用一组特定的输入(测试用例)测试函数是否功能正常，并且返回了正确的输出。
测试的覆盖种类1.语句覆盖：语句覆盖就是设计若干个测试用例，运行被测试程序，使得每一条可执行语句至少执行一次。
2.判定覆盖（也叫分支覆盖）：设计若干个测试用例，运行所测程序，使程序中每个判断的取真分支和取假分支至少执行一次。
3.条件覆盖：设计足够的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次。
4.判定——条件覆盖：设计足够的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次，并且每个可能的判断结果也至少执行一次。
5.条件组合测试：设计足够的测试用例，运行所测程序，使程序中每个判断的所有条件取值组合至少执行一次。
6.路径测试：设计足够的测试用例，运行所测程序，要覆盖程序中所有可能的路径。
用例的设计方案主要的有下面几种：条件测试，基本路径测试，循环测试。
通过上面的方法可以实现测试用例对程序的逻辑覆盖，和路径覆盖。
二、开始测试前的准备在开始测试时，要先声明一下，无论你设计多少测试用例，无论你的测试方案多么完美，都不可能完全100%的发现所有BUG，我们所需要做的是用最少的资源，做最多测试检查，寻找一个平衡点保证程序的正确性。
穷举测试是不可能的。
所以现在进行单元测试我选用的是现在一般用的比较多的基本路径测试法。
三、开始测试基本路径测试法：设计出的测试用例要保证每一个基本独立路径至少要执行一次。
函数说明：当i_flag=0；返回i_count+100当i_flag=1；返回i_count *10否则返回i_count *20输入参数：int i_count ，int i_flag输出参数：int i_return;代码：1 int Test(int i_count, int i_flag)2 {3 int i_temp = 0;4 while (i_count>0)5 {6 if (0 == i_flag)7 {8 i_temp = i_count + 100;9 break;10 }11 else12 {13 if (1 == i_flag)14 {15 i_temp = i_temp + 10;16 }17 else18 {19 i_temp = i_temp + 20;20 }21 }22 i_count--;23 }24 return i_temp;25 }1.画出程序控制流程图图例：事例程序流程图：圈中的数字代表的是语句的行号，也许有人问为什么选4,6,13,8......作为结点，第2行，第3行为什么不是结点，因为选择结点是有规律的。
让我们看程序中；第2行，第3行是按顺序执行下来的。
直到第4行才出现了循环操作。
而2，3行没有什么判断，选择等分支操作，所以我们把2，3，4全部合并成一个结点。
其他的也是照这个规则合并，然后就有了上面的流程图。
2.计算圈复杂度有了图以后我们要知道到底我们有写多少个测试用例，才能满足基本路径测试。
这里有有了一个新概念——圈复杂度圈复杂度是一种为程序逻辑复杂性提供定量测试的软件度量。
将该度量用于计算程序的基本独立路径数目。
为确保所有语句至少执行一次的测试数量的上界。
公式圈复杂度V（G）=E+N+2，E是流图中边的数量，N是流图中结点的数量。
公式圈复杂度V（G）=P+1 ，P是流图G中判定结点的数量。
通俗的说圈负责度就是判断单元是不是复杂，是不是好测试的标准。
一般来说如果圈复杂度如果大于20就表示这个单元的可测试性不好，太复杂（也许有人觉得无所谓，但是如果你们公司实行了CMMI5的话，对这个是有规定的）。
从图中我们可以看到，V（G）=10条边-8结点+2=4V（G）=3个判定结点+1=4上图的圈复杂图是4。
这个结果对我们来说有什么意义呢？它表示我们只要最多4个测试用例就可以达到基本路径覆盖。
3.导出程序基本路径。
现在我们知道了起码要写4个测试用例，但是怎么设计这4个测试用例？导出程序基本路径，根据程序基本路径设计测试用例子。
程序基本路径：基本独立路径就是从程序的开始结点到结束可以选择任何的路径遍历，但是每条路径至少应该包含一条已定义路径不曾用到的边。
（看起来不好理解，让我们看例子）。
让我们看上面的流程图：从结点4到24有几条路径呢？1 B（4，24）2 C，E，J（4，6，8，24）3 C，D，F，H，A，B（4，6，13，15，22，4，24）4 C，D，G，I，A，B（4，6，13，19，22，4，24）还有吗？？5 C，D，C，I，A，C，E，J（4，6，13，19，22，4，6，8，24）算吗？不算，为什么？因为上面的4条路径已经包括了所有的边。
第5条路径已经不包含没有用过的边了。
所有的路径都遍历过了。
好了，现在我们有了4条基本独立路径根据独立路径我们可以设计测试用例。
1 B（4，24）输入数据：i_flag=0，或者是i_flag<0的某一个值。
预期结果：i_temp=0.2 C，E，J（4，6，8，24）输入数据：i_count =1;i_flag=0预期结果：i_temp=101.3 C，D，F，H，A，B（4，6，13，15，22，4，24）输入数据：i_count =1;i_flag=1预期结果：i_temp=10.4 C，D，G，I，A，B（4，6，13，19，22，4，24）输入数据：i_count =1;i_flag=2预期结果：i_temp=20.这里的输入数据是有路径和程序推论出来的。
而要注意的是预期结果是从函数说明中导出，不能根据程序结构中导出。
为什么这么说？让我们看程序中的第3行。
int i_temp=0;假如开发人员一不小心写错了，变成了int i_temp=1;根据程序导出的预期结果就会是一个错误的值，但是单元测试不出来问题。
那单元测试就失去了意义。
有人也许会问这么简单的函数就有4个测试用例，如果还复杂一些的怎么办？上面的测试用例还可以简化吗？答案是可以。
我们来看路径1 B（4，24）和 4 C，D，G，I，A，B（4，6，13，19，22，4，24），路径1是路径4的真子集，所以1是可以不必要的。
上图的圈复杂度是4。
这个结果对我们来说有什么意义呢？它表示我们只要最多4个测试用例就可以达到基本路径覆盖。
所以说圈复杂度标示是最多的测试用例个数，不是一定要4个测试用例才可以。
不过有一点要申明的是测试用例越简化代表你的测试越少，这样程序的安全性就越低了。
四、完成测试接下来根据测试用例使用工具测试NUNIT，VS2005都可以。
接下来根据测试结果编写测试报告，测试人，时间，结果，用例，是否通过，格式网上一大把，每个公司的格式也不一样就不说了。
