1、软件测试方法,第二讲,测试用例描述软件测试方法概述静态测试和动态测试黑盒测试和白盒测试,本章内容,测试用例的定义和特征,测试用例的定义：（1）测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。（2）测试用例是执行的最小实体。 测试用例的特征：（1）最有可能抓住错误的；（2）不是重复的、多余的；（3）一组相似测试用例中最有效的；（4）既不是太简单，也不是太复杂。,设计测试用例的基本准则,测试用例的代表性： 能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作和环境设置等。测试结果的可判定性： 即测试执行结果的正确性是可判定的，每一个测试用例都
2、应有相应的期望结果。测试结果的可再现性： 即对同样的测试用例，系统的执行结果应当是相同的。,设计测试用例的着眼点,根据产品规格，测试基本功能；考虑设计一般用户（非专业人员）的使用方案；考虑设计稀有或特殊的使用方案；与系统其他组成部分的配合（如FAX和上网可能要用到MODEM，测试中考虑对设备的共享）；考虑特殊情况（如内存和硬件的冲突等）；设计极端情况（如内存泄漏、破坏性测试等）；好的测试用例集能花费最小的代价（人力、物力、财力、时间）做最好的测试。,什么是软件缺陷,软件未达到产品说明书标明的功能。软件出现了产品说明书指明不会出现的错误软件功能超出产品说明书指明范围。软件未达到产品说明书虽未指出
3、但应达到的目标。软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。,为什么会出现软件缺陷,导致软件缺陷最大的原因是产品说明书。软件缺陷的第二大来源是设计方案。编写代码其他,软件缺陷的修复费用,从开始到计划、编制、测试、一直到公开使用的过程中，都有可能发现软件缺陷。随着时间推移，修复软件缺陷的费用呈几何数级地增长。,软件缺陷在不同阶段发现时修改的费用示意图,为什么做测试用例,完全测试是不可能的：输入量太大；输出结果太多；软件实现途径太多；软件说明书没有客观标准。从不同角度看，软件缺陷的标准不同。,什么是测试用例,为达到最佳的测试效果或高效的揭露隐藏的错误而精心设计的少量测
4、试数据，称之为测试用例。我们不可能进行穷举测试，为了节省时间和资源、提高测试效率，必须要从数量极大的可用测试数据中精心挑选出具有代表性或特殊性的测试数据来进行测试。一个好的测试用例是在于它能发现至今未发现的错误。,使用测试用例的好处,在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。测试用例的使用令软件测试的实施重点突出、目的明确。在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期。功能模块的通用化和复用化使软件易于开发，而相对于功能模块的测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精化其效率也不断攀升。,测试用例的设计
5、过程,测试设计员（分析设计员）依据不同阶段的测试计划、设计模型和实施模型来设计该阶段测试用例。测试设计员是具有丰富测试经验或具有软件分析设计能力的高级测试工程师。如果没有测试设计员，则可用分析设计员代替。,测试点的确定,ISO 质量体系：在概要设计或详细设计中应明确指出每个单元模块的测试要点、指标和方法。CMM 质量体系：在系统的用例模型描述中应明确指出每个用例模型的优先级及用例工作流程，每一个用例模型为一个测试点，用例模型中每一个测试需求至少应有两个测试用例。,理解上的误区,测试用例应由测试设计员或分析设计员来制定，而不是普通的测试员。测试点应由分析设计员确立，与测试人员无关。测试工作展开于
6、项目立项后，而不是代码开发完成之后。测试对象不仅仅是源代码，还包括需求分析、需求规格说明书、概要设计、概要设计说明书、详细设计、详细设计说明书、使用手册等各阶段的文档。,软件测试的方法多种多样，可以从不同角度加以分类：从是否需要执行被测软件的角度，分为静态测试和动态测试；从是针对系统的外部功能还是针对系统的内部结构的角度，分为黑盒测试和白盒测试；从软件测试的策略和过程的角度，分为单元测试、集成测试、确认测试、系统测试和验收测试等。,软件测试方法概述,静态测试就是通过对被测程序的静态审查，发现代码中潜在的错误。它一般用人工方式脱机完成，故亦称人工测试或代码评审（Code Review）;也可借助
7、于静态分析器在机器上以自动方式进行检查，但不要求程序本身在机器上运行。按照评审的不同组织形式，代码评审又可分为代码会审，走查以及办公桌检查，同行评分4种。对某个具体的程序，通常只使用一种评审方式。,静态测试,动态测试是通过源程序运行时所体现出来的特征，来进行执行跟踪、时间分析以及测试覆盖等方面的测试。动态测试是真正运行被测程序，在执行过程中，通过输入有效的测试用例，对其输入与输出的对应关系进行分析，以达到检测的目的。,动态测试,黑盒测试黑盒测试不考虑软件的具体实现过程，当在软件实现的过程发生变化时，测试用例仍然可以使用；黑盒测试用例的设计可以和软件实现同时进行，这样能够压缩总的开发时间。白盒测
8、试它是知道产品的内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行。也称为结构测试或逻辑驱动测试,动态测试,逻辑覆盖 、循环覆盖 、基本路径覆盖测试原则保证每个模块中所有独立路径至少被使用一次完成所有逻辑值分别为真和假的条件下的测试在上下边界及可操作范围内运行所有的循环，完成覆盖测试检查内部数据结构以确保其有效性，完成边界条件的测试,白盒测试,语句覆盖程序运行时每个可执行语句至少被执行一次。在保证完成要求的情况下，测试用例的数目越少越好。判断覆盖程序中每个判断条件的真值分支和假值分支至少被执行一遍。在保证完成要求的情况下，测试用例的数目越少越好。条件覆盖程序中每个判断条
9、件中的每个判断式的真值和假值至少被执行一遍。,逻辑覆盖,判断/条件覆盖程序中每个判断条件的真假值分支至少被执行一遍，并且每个判断条件的内部判断式的真假值分支也要被执行一遍。条件组合覆盖程序中每个判断条件的的内部判断式的各种真假组合可能都至少被执行一遍。,逻辑覆盖,1If (x100&y500) then2 score=score+13If (x=1000| z5000) then4 score=score+5,逻辑覆盖,逻辑覆盖,语句覆盖（Statement Coverage）是指设计若干个测试用例，程序运行时每个可执行语句至少被执行一次。在保证完成要求的情况下，测试用例的数目越少越好。增对上
10、面的流程图，覆盖所有语句的线路线路：ace,语句覆盖,语句覆盖,语句覆盖的问题：不能发现其中的逻辑错误比如：将语句1种的 x100&y500 写错成 x100|y500,语句覆盖,判断覆盖（Branch Coverage）是指设计若干个测试用例，执行被测试程序时，程序中每个判断条件的真值分支和假值分支至少被执行一遍。在保证完成要求的情况下，测试用例的数目越少越好。判断覆盖又称为分支覆盖。设计两条测试路径：路径1：ace路径2：abd,判定覆盖,判定覆盖,也可设计线路： acd 和abe,判定覆盖,以上两组判断覆盖要求，也同时满足了语句覆盖要求。某种程度上可以说判断覆盖测试要强于语句覆盖测试。判
11、定覆盖的问题：会忽略条件中”|”的情况，比如语句中的z5000写错成其他值,判定覆盖,条件覆盖（Condition Coverage）是指设计若干个测试用例，执行被测试程序时，程序中每个判断条件中的每个判断式的真值和假值至少被执行一遍。语句中有4组判定: x100,y500, x=1000, z5000。共8种真假值,条件覆盖,逻辑覆盖-条件覆盖,问题：不能保证所有判定覆盖测试被执行,条件覆盖,判断/条件覆盖是指设计若干个测试用例，执行被测试程序时，程序中每个判断条件的真假值分支至少被执行一遍，并且每个判断条件的内部判断式的真假值分支也要被执行一遍。设计测试用例：Test Case 1：x=2
12、000, y=600, z=2000Test Case 8：x=50, y=200, z=2000,判断/条件覆盖,判断/条件覆盖,问题：虽然满足了判断覆盖和条件覆盖，但是没有对每个判断条件的内部判断式的所有真假值组合进行测试,判断/条件覆盖,条件组合覆盖是指设计若干个测试用例，执行被测试程序时，程序中每个判断条件的的内部判断式的各种真假组合可能都至少被执行一遍。可见，满足条件组合覆盖的测试用例组一定满足判断覆盖、条件覆盖和判断/条件覆盖。测试用例：Test Case 1：x=2000, y=600, z=2000Test Case 6：x=2000, y=200, z=6000Test Ca
13、se 7：x=2000, y=600, z=2000Test Case 8：x=50, y=200, z=2000,条件组合覆盖,条件组合覆盖,问题：虽然满足了判断覆盖、条件覆盖以及判断/条件覆盖，但是并没有覆盖程序控制流图中全部的4条路径（ace，abe，abe，abd），,条件组合覆盖,路径覆盖（Path Coverage）要求设计若干测试用例，执行被测试程序时，能够覆盖程序中所有的可能路径。测试用例组：Test Case 1：x=2000,y=600,z=6000 Test Case 3：x=50,y=600,z=2000Test Case 4：x=2000,y=600,z=2000Te
14、st Case 7：x=2000,y=200,z=1000,路径覆盖,路径覆盖,应该注意的是，上面6种覆盖测试方法所引用的公共程序只有短短4行，是一段非常简单的示例代码。然而在实际测试程序中，一个简短的程序，其路径数目是一个庞大的数字。要对其实现路径覆盖测试是很难的。所以，路径覆盖测试是相对的，要尽可能把路径数压缩到一个可承受范围。当然，即便对某个简短的程序段做到了路径覆盖测试，也不能保证源代码不存在其他软件问题了。其他的软件测试手段也必要的，它们之间是相辅相成的。没有一个测试方法能够找尽所有软件缺陷，只能说是尽可能多地查找软件缺陷。,逻辑覆盖小结,在流程控制图的基础上，通过分析控制结构的环路
15、复杂性，导出基本可执行路径集合，从而设计测试用例。,路径分析测试法,控制流图有以下几个特点：具有唯一入口节点，即源节点，表示程序段的开始语句；具有唯一出口节点，即汇节点，表示程序段的结束语句；节点由带有标号的圆圈表示，表示一个或多个无分支的源程序语句；控制边由带箭头的直线或弧表示，代表控制流的方向。,第一步:控制流图,控制流图,程序的环路复杂性是一种描述程序逻辑复杂度的标准，该标准运用基本路径方法，给出了程序基本路径集中的独立路径条数，这是确保程序中每个可执行语句至少执行一次所必需的测试用例数目的上界。 给定一个控制流图G，设其环形复杂度为V(G)，在这里介绍三种常见的计算方法来求解V(G)。
16、(1) V(G)=E-N+2，其中E是控制流图G中边的数量，N是控制流图中节点的数目。(2) V(G)=P+1，其中P是控制流图G中判断节点的数目。(3) V(G)=A，其中A是控制流图G中区域的数目。由边和结点围成的区域叫做区域，当在控制流图中计算区域的数目时，控制流图外的区域也应记为一个区域。,第二步:计算程序环形复杂度,为便于在机器上表示和处理控制流图，开发辅助基本路径测试的软件工具，可把流图转化为矩阵形式，即图矩阵。图矩阵是一个正方形矩阵，其大小等于流图的节点数。,图矩阵,a,c,b,d,f,e,等价类划分边界值分析因果图判定决策表错误猜测法,黑盒测试,等价类划分的办法是把程序的输入域
17、划分成若干部分，然后从每个部分中选取少数代表性数据当作测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值，也就是说，如果某一类中的一个例子发现了错误，这一等价类中的其他例子也能发现同样的错误；反之，如果某一类中的一个例子没有发现错误，则这一类中的其他例子也不会查出错误。,等价类划分,如果输入条件规定了取值的范围或值的个数，则可确定一个有效等价类和两个无效等价类；如果一个输入条件说明了一个“必须成立”的情况，则可划分一个有效等价类和一个无效等价类；如果输入条件规定了输入数据的一组可能的值，而且程序是用不同的方式处理每一种值，则可为每一种值划分一个有效等价类，并划分一个无效等价类；如
18、果我们确知，已划分的某等价类中的各元素（例子）在程序中的处理方式是不同的，则应据此将此等价类进一步划分成更小的等价类。在确立了等价类之后，建立等价类表，列出所有划分出的等价类：,怎样划分等价类,为每个等价类规定一个惟一的编号；设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步，最后使得所有有效等价类均被测试用例所覆盖；设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步使所有无效等价类均被覆盖。,等价类测试用例的步骤,测试需求：测试两个参数的值相加后的结果是否正确。其中：输入的数值在-99到99之间大于99或小于-99的输入应被拒绝，并显示错误信息,案例,第一步：在
19、本案例中我们根据测试需求可以把两位数加法分为如图的三个等价类：一个有效数据的等价类，两个无效数据等价类（有效数据等价类就是：由那些对程序的规格说明有意义的、合理的输入数据所构成的集合；无效数据等价类就是：那些对程序的规格说明不合理的或无意义的输入数据所构成的集合）。,等价类划分,第二步：在实际工作中，我们通常在确立了等价类以后，把程序中所有的等价类建立等价类表，以便在编写测试用例的时候有所依据。,等价类划分,第三步：根据上面的等价类表，我们就可以确定测试用例了，步骤为：为等价类表中的每一个等价类分配一个唯一的编号。设计一个新的测试用例，使它能够尽量覆盖尚未覆盖的有效等价类。重复这一步骤，从而使
20、所有有效等价类均被测试用例所覆盖。与上一步类似，设计一个新的测试用例，使它只覆盖一个无效等价类。重复这一步骤，从而使所有无效等价类均被测试用例所覆盖。,等价类划分,第四步：细化等价类划分在测试“-99=数值=99”的这个等价类区间的时候，我们会发现如1040，-20+30和-30+(-30)这类的正数相加，正数负数相加，负数相加也是不同的等价区间。因此我们可以使用更多的等价类划分：,等价类划分,根据以上等价类划分的结果，得出下表的等价类表,第五步：根据上面划分的4个等价类，我们至少需要有5个测试用例,等价类划分,测试需求假定一台ATM机允许提取增量为50人民币，总额为从50人民币到5000人民
21、币（含5000人民币）不等的现金。测试能否提取想提请的钱数（不考虑由于硬件的原因造成的提取错误）。,等价类划分,第一步： 划分等价类,等价类划分,第二步：建立等价类表,等价类划分,第三步： 确定测试用例,等价类划分,第四步：细化等价类划分。只要运用等价类划分，我们就只需要一个有效的测试用例和两个无效的测试用例就能进行充分的覆盖。还可以尝试将等价类进一步细化，考虑提取钱的数目为负的钱数，零钱数或特别大可能引起ATM机崩溃等等;,等价类划分,第五部：细化测试用例,等价类划分,测试相同的内容如果等价类中的一个测试能够捕获一个缺陷，那么选择该等价类中的其他测试也能捕获该缺陷如果等价类中的一个测试不能捕
22、获缺陷，那么选择该等价类中的其他测试也不会捕获缺陷如果正确的划分等价类，可以大大降低测试用例的数量，测试会准确有效。如果错误的将两个不同的等价类当作一个等价类，那就会遗漏一种测试情况。相反的，把同一个等价类看作了两个不同的等价类，那么测试就会是冗余的,等价类的特点,即考虑有效等价类，同时也要考虑无效等价类：利用有效等价类生成的测试用例，可以检验程序是否实现了需求规格说明书中预先规定的功能和性能。利用无效等价类生成的测试用例，可以检查程序中功能和性能的实现是否不符合规格说明要求。设计测试用例的时候要同时考虑这两种等价类。因为软件不仅要能接收合理的数据，也要能经受意外的考验，这样的测试才能确保软件
23、具有更高的可靠性。仔细划分，审核划分等价类的目标就是把有可能的测试用例组合缩减到仍然足以测试软件的范围。如果为了减少测试用例的数量过度进行等价分配，漏掉软件缺陷的风险就会增加。我们必须要仔细选择分类，特别对于测试新手，在测试前一定要请有经验的测试人员帮助审核确定划分的等价类别,划分等价类要注意的问题,边界值分析法是一种补充等价划分的测试用例设计技术，它不是选择等价类的任意元素，而是选择等价类边界的测试用例。实践证明，在设计测试用例时，对边界附近的处理必给予足够的重视，为检验边界附近的处理专门设计测试用例，常常取得良好的测试效果。边界值分析法不仅重视输入条件边界，而且也从输出域导出测试用例。,边
24、界值分析,如果输入条件规定了取值范围，应以该范围的边界内及刚刚超范围的边界外的值作为测试用例。如以a和b为边界，测试用例应当包含a和b及略大于a和略小于b的值；若规定了值的个数，分别以最大、最小个数及稍小于最小、稍大于最大个数作为测试用例；针对每个输出条件使用前面的第1）和2）条原则；如果程序规格说明中提到的输入或输出域是个有序的集合（如顺序文件、表格等），就应注意选取有序集的第一个和最后一个元素作为测试用例；分析规格说明，找出其他的可能边界条件。,边界值设计遵守的几条原则,我们根据边界值分析的方法来看看如何对边界值进行测试。,边界值分析,由于允许输入的数值在-99到99之间，所以我们可以把-
25、99和99看作两个边界值。我们测试的时候可以取紧邻边界值的数值和边界值本身作为输入。,边界值分析,使用边界值分析方法设计测试用例，首先，应当选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据，即重点测试最后一个肯定合法的数据，和刚刚超过边界的非法数据。其次，边界值分析方法通常和等价类划分一起使用产生一套完整的测试用例。等价类划分是从等价区间中选择有代表性的值，而边界值重点是等价区间的边界值，恰好是等价区间中最具代表性的值。,边界值分析,数值、速度、字符、地址、位置、尺寸、数量等等；,常见的边界问题,因果图法产生的背景： 等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各
26、种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。因果图法能够帮助测试人员按照一定的步骤，高效率的开发测试用例，以检测程序输入条件的各种组合情况，它是将自然语言转化为形式语言规格说明的一种严格方法，可以指出规格说明存在的不完整性和二义性。,因果图法,因果图法是基于这样的一种思想：一些程序的功能可以用判定表（或称决策表）的形式来表示，并根据输入条件的组合情况规定相应的操作。即：因果图法不过是决策表法的前期阶段。我们也可以直接应用决策表。因果图法的定义：是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，
27、它适合于检查程序输入条件的各种组合情况。采用因果图法设计测试用例的步骤：（1）根据程序规格说明书描述，分析并确定因（输入条件）和果（输出结果或程序状态的改变），画出因果图。（2）将得到的因果图转换为判定表。（3）为判定表中每一列所表示的情况设计一个测试用例。,因果图法,在一些数据处理问题中，某些操作依赖多个逻辑条件的取值。处理这类问题的一个非常有力的分析和表达工具是判定表一些软件的功能需求可用判定表表达得非常清楚，在检验程序的功能时判定表也就成为一个非常有力的工具,判定表介绍,决策表通常由以下4部分组成：条件桩列出问题的所有条件条件项针对条件桩给出的条件列出所有可能的取值动作桩列出问题规定的可
28、能采取的操作动作项指出在条件项的各组取值情况下应采取的动作,判定表介绍,将任何一个条件组合的特定取值及相应要执行的动作称为一条规则。在决策表中贯穿条件项和动作项的一列就是一条规则。,判定表图示,1:表示为是或者取该值；0：表示为否或者不取该值；：表示该值取什么都可以。,判定表举例,条件桩,动作桩,条件项,动作项,因果图法步骤,分析软件规格说明描述中的因果关系（输入与输出的因果关系） 找出原因与结果、原因与原因之间的对应关系，画出因果图在因果图上标记约束或限制条件把因果图转化为判定表将判定表中的每一列拿出来设计测试用例,因果图介绍,因果图中使用4种因果关系符号来表达因果关系：,因果图介绍,因果图
29、中的4种基本关系 在因果图的基本符号中，图中的左结点ci表示输入状态（或称原因），右结点ei表示输出状态（或称结果）。ci 与 ei 取值0或1，0表示某状态不出现，1则表示某状态出现。恒等：若 c1 是1，则 e1 也为1，否则 e1 为0。非：若 c1 是1，则 e1 为0，否则e1为1。或：若 c1 或 c2 或 c3 是1，则 e1 为1，否则 e1 为0。与：若 c1 和 c2 都是1，则 e1 为1，否则 e1 为0。,因果图介绍,因果图中的约束 在实际问题中输入状态相互之间、输出状态相互之间可能存在某些依赖关系，称为“约束”。对于输入条件之间的约束有E（Exclusive or）
30、、I（In）、O（Only）、R（Request）四种约束，对于输出条件的约束只有M（Mandate）约束。（1）原因与原因之间的约束E约束(异)：输入a和b中最多有一个可能为1，即a和b不能同时 为1。I 约束(或)：输入a、b、c中至少有一个必须为1，即 a、b、c不能同时为0。O约束(唯一)：输入a和b必须有一个且仅有一个为1。R约束(要求)：输入a是1时，输入b必须是1，即a为1时，b不能为0。（2）结果与结果之间的约束M约束(强制)：若结果a为1，则结果b强制为0。,因果图介绍,因果图中用来表示约束关系的约束符号：,因果图法主题思想,因果图法最终生成的是决策表。利用因果图生成测试用例
31、的基本步骤如下：（1）分析软件规格说明中哪些是原因（即输入条件或输入条件的等价类），哪些是结果（即输出条件），并给每个原因和结果赋予一个标识符。（即：找出原因和结果）（2）分析软件规格说明中的语义，找出原因与结果之间、原因与原因之间对应的关系， 根据这些关系画出因果图。 （即：标定因果关系）（3）由于语法或环境的限制，有些原因与原因之间、原因与结果之间的组合情况不可能出现。为表明这些特殊情况，在因果图上用一些记号表明约束或限制条件。（4）把因果图转换为决策表。（5）根据决策表中的每一列设计测试用例。,因果图法案例,第一列字符必须是#或*，第二列字符必须是一个数字，在此情况下进行文件的修改。但如
32、果第一列字符不正确，则给出信息L；如果第二列字符不是数字，则给出信息M。解题步骤（1）分析程序的规格说明，列出原因和结果。（2）找出原因与结果之间的因果关系、原因与原因之间的约束关系，画出因果图。（3）将因果图转换成决策表。（4）根据（3）中的决策表，设计测试用例的输入数据和预期输出。,因果分析,原因：c1第一列字符是#c2第一列字符是*c3第二列字符是一数字10 第一列字符是#或是*结果：e1给出信息Le2修改文件e3给出信息M,因果分析,（1）分析程序规格说明中的原因和结果：（2）画出因果图（编号为10的中间结点是导出结果的进一步原因）：,不可能同时存在,由因果图建立的判定表,（3）将因果
33、图转换成如下所示的决策表：,规则,选项,从决策表中得到测试用例,（4）根据决策表中的每一列设计测试用例：,随机测试,使用随机数生成器选取测试用例值避免测试偏见（只选取边界值）存在问题：测试用例是否充分,错误推测法,错误推测法是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例,错误推测法基本思想,列举出程序中所有可能有的错误和容易发生错误的特殊情况来设计测试用例例如: 以前测试时曾出现过错误的地方，包括单元测试、集成测试、系统测试、前几次回归测试输入数据的问题，如是否可为空，是否可以有特殊字符，是否可以小于0、等于0等等一些问题的范围或边界,测试方法的选择,通常在确定测
34、试策略时，有以下5条参考原则：（1）在任何情况下都必须采用边界值分析法。这种方法设计出的测试用例发现程序错误的能力最强。（2）必要时采用等价类划分法补充测试用例。（3）采用错误推断法再追加测试用例。（4）对照程序逻辑，检查已设计出的测试用例的逻辑覆盖 程度。如果没有达到要求的覆盖标准，则应当再补充更多的测试用例。（5）如果程序的功能说明中含有输入条件的组合情况，则应一开始就选用因果图法。,测试方法的选择,通常在确定测试策略时，有以下5条参考原则：（1）在任何情况下都必须采用边界值分析法。这种方法设计出的测试用例发现程序错误的能力最强。（2）必要时采用等价类划分法补充测试用例。（3）采用错误推断法再追加测试用例。（4）对照程序逻辑，检查已设计出的测试用例的逻辑覆盖 程度。如果没有达到要求的覆盖标准，则应当再补充更多的测试用例。（5）如果程序的功能说明中含有输入条件的组合情况，则应一开始就选用因果图法。,软件测试的必要性为什么要进行软件测试什么是软件测试软件测试和软件开发的关系测试驱动开发的思想,回顾,
