软件工程课件部分软件测试

第14章软件测试工程测试是一个工程任务，需要回答：花多少时间、多少成本？何时可以停止测试？目录14.1测试工程化14.2各测试阶段的工作14.3测试用例设计方法14.4OO程序的测试14.5不可测试软件的测试14.6何时停止测试？14.7可信赖性测试和评价14.8总结14.1测试工程化14.1.1测试的生命周期14.1.2测试方式与方法14.1.3测试工程的原则14.1.4测试过程14.1.1测试的生命周期14.1.2测试方式与方法静态测试是人工对文档和代码的质量评审。本书的第12.7节讨论了代码审查的方法。文档审查和评审可以解决许多测试中不能解决深层问题，例如，需求不明确，设计中的缺陷等。本书的第16章进一步把文档作为软件开发中的中间产品进行审查的方法和原则。第21.5节给出了国防系统软件中间产品的质量评价。动态测试的目的是尽可能回答被测系统的功能和质量是否达到期望的要求，从而增强用户使用软件系统的信心或可信任程度，包括被测系统的功能和非功能两个方面可信任程度。将非功能的要求主要分为：质量要求(ISO-9126意义上的，见第4章)特征，例如，系统的响应时间、数据吞吐量、系统的并发用户数、平均服务时间等，可信赖性要求(见第5章)。以及系统防止被攻击的能力(密安性)，安全可靠程度(如，测试主系统失败后切换到备份系统的过渡时间和数据丢失情况等)。测试阶段和测试方法交叉对应针对质量和可信赖性的测试14.1.3测试工程的原则原则1：测试用例必须定义出期望的输出或结果。原则2：程序员避免测试自己的程序。原则3：编程队伍不测试自己的程序。原则4：全面审查每个测试结果。原则5：测试用例必须写出非法的和不期望的输入条件，以及合法的期望的条件。原则6：测试是一场战斗，一半任务是验证系统有没有实现的其所假定的要求，另一半是验证系统是否实现了其没有假定的要求。14.1.3测试工程的原则原则7：不要扔掉测试用例，除非被测程序也被扔掉了。原则8：不能以“错误未被发现”为依据计划测试工作量。原则9：程序中某一部分存在错误的概率与该部分已发现的错误个数成正比。原则10：测试是一个极其具有创作和挑战性的工程工作。14.1.4测试过程测试过程一般分为：1）测试环境的准备，2）测试用例设计，3）测试的执行和记录，以及4）对测试结果的分析和评判。测试用例(TestCase)是指对被测系统的输入数据、预期的中间和最终输出结果、测试的执行步骤、执行测试的前置条件、评价该测试用例是否测试成功的判断条件。在测试过程中，需要记录测试的中间执行情况，无论自动测试还是手动测试。中间结果能够帮助代码开发者分析和定位软件错误的大致范围。测试的复现：如果测试中间和最终结果都能够用同一组(个)测试用例复现出来，说明系统的执行路径上具有必然的错误；往往是代码的错误如果不能复现，说明系统中隐藏者深层次的设计错误，例如，分配了内存，忘记回收内存，变量未初始化等这样的随机性故障。软件的随机性故障最难对付，因为很难复现出来！必须对测试结果进行认真的分析，并评判测试工作是否达到目标要求。再次强调“成功的测试是让系统出现错误”而不能用类似于“系统通过测试，没有发现错误”等结论评判测试工作是否完成。14.2各测试阶段的工作14.2.1单元测试14.2.2集成测试14.2.3系统测试14.2.4验收测试14.2.5试运行14.2.6产品发布前的测试14.2.1单元测试单元测试是测试的基础工作。一方面要验证单元是否符合设计要求，程序员和测试人员不会忘记这项测试工作。另一方面，单元测试的要验证程序路径的覆盖程度和代码中的错误，增强后续集成测试对代码的信任程度。这是质量要求，往往因时间而压缩或忽略此工作。由于软件单元的规模小，对软件单元的全路径覆盖是可能的。需要花大量的人工，最好能做自动测试。即使不能做到完全的路径覆盖，也近似做到，即，采用其它的覆盖率定义方法，例如，代码行覆盖率、分支覆盖率、独立分支覆盖率等替代全路径覆盖，以满足工程中能够明显区分(度量)出测试程度的需要。14.2.2集成测试集成测试与集成活动相互交替的过程。即，伴随着软件系统的集成，对软件集成的当前状态进行测试，便于发现和定位错误到某个具体的部件上。否则，对于一个庞大的软件系统，其中的故障很难被定位的。即使将代码开发和测试分为两个独立的队伍，依然需要双方的不断交流和迭代，才能很好的将软件系统集成在一起，达到系统的质量、工期和成本要求。伴随着集成的测试和代码修改，能够高效地地降低系统集成过程中的错误。一个假设的软件系统自顶向下的测试与集成示例自底向上的测试与集成示例三明治(sandwich)在实际工程中，可以将两个办法结合起来使用，称为“三明治(sandwich)”方法。即，依据编写驱动或桩的难易程度，以及集成的方便程度，从顶向下和从底向上一起实施集成和测试。14.2.3系统测试系统测试也是在模拟环境下，对集成起来的系统的功能、非功能(一般意义上的质量和可信赖性等)的全面验证和确认。包括：验证体系结构设计是否满足系统的功能、质量和可信赖性要求；也包括：确认系统是否满足需求分析所给出的要求简单的回答“通过所有测试用例的测试”的评价是十分有害的。测试人员必须建立模型，判断“真实”和“模拟”环境的区别，以便能够推测出“通过所有测试用例的测试”后，系统上线试运行阶段和实际运行中可能出现的偏差，这种偏差包括功能、质量、可信赖性等方面。14.2.4验收测试验收测试的目标至少包括：(1)全面评价各个测试阶段情况是否真实，是否得到了期望的测试目标和要求？(2)如果测试过程有返工，是否进行了回归测试？回归测试是否达到了该重复测试所要求的目标？(3)测试中所反映出的缺陷和修复情况的的趋势是否有明显的下降？(4)能否从历次测试中发现的缺陷数趋势推测出系统中遗留缺陷数量？(5)对系统进行试运行中可能发生的重大错误，是否有处理预案？14.2.5试运行试运行目的是进一步告诉开发者和系统的运维者(包括系统的管理和使用人员)：(1)该系统中还有哪些不足或缺陷？使用中如何避免这些缺陷的发生。(2)在不同的使用场景下，例如，火车售票系统的高峰期和一般时段，为更好地满足系统运行的能力，能否和如何对系统的参数进行调整？(3)维护人员在日常维护中的工作，例如，每周或每天是否需要做数据备份？如何提高系统的性能？(4)在如何保证系统运行和维护期间的密安性、安全可靠、防攻击能力等方面是否有预案？以及，(5)为系统的交割和正常运行所需要的工作是否都得到了验证和确认。14.2.6产品发布前的测试如果开发的是一个软件产品，开发者会在产品正式发布前进行α和β测试。目的是让潜在的用户验证系统的实际可用性，评价系统上市后的风险。也通过大用户量的试用，发现问题。一般α测试在系统接近完成后进行，由最终用户或委托给专职的测试公司进行，仍允许对设计进行微小的变动。而β测试则是在开发和测试接近完成时进行的，目的是发布前进一步发现软虫和缺陷。β测试也可以由最终用户或委托给专职的测试公司进行。14.3测试用例设计方法14.3.1随机方法14.3.2判定表方法14.3.3等价类划分14.3.4边界值方法14.3.5因果图方法14.3.1随机方法随机(Random或“ad-hoc”)测试是最简单的测试方法。依据系统输入的类型，测试人员（或测试工具）随机选择和组合测试数据形成测试用例。缺点：这种测试不能保证测试用例是否覆盖了关键的功能。显得有点不负责任，因为无法判断测试的效果。优势：可以避免测试者主观地选择测试用例的偏见。简单的道理是，一个“猴子”随机敲击键盘把PC机“玩死”的可能性要比一个具有专业知识的人把计算机“用死”的可能性大的多。14.3.2判定表方法客户要求：如果客户是一个新客户，那么可以给20%的折扣；如果客户是一个老客户，那么可以免发货费；货物价值等级：如果货物价值等级高，那么，

如果客户是一个新客户，那么检查其信用记录；

如果客户是一个老客户，那么，

如果以前的订单总数>5000元，可以发货；

否则，检查其信用记录。依据需求=>创立判定表=>得到测试用例14.3.3等价类划分一个等价类(equivalencepartition)是输入集合的子集。用该子集中的每个输入元素对被测系统S进行测试时，所引起S发生同样的运行错误，或都不能引起S发生错误。回顾图13-8把等价类划分为：有效等价类和无效等价类。(1)有效等价类：是有效的输入集合。即，正确的输入，系统S应当给出正确的输出。(2)无效等价类：是不合理的，无意义的输入元素构成的集合划分等价类指导原则主要因素是输入条件（1）如果输入条件是一个范围，可以直接区分出合法等价区域和不合法等价区域。例如，输入是一个实数，其值域范围确定了合法和不合法的区域；（2）如果输入条件是一个指定的值，可以划分为一个合法区域和两个不合法区域；例如，小于、等于和大于指定的值；（3）如果输入条件是多个集合，可以分为一个合法类和一个非法类；（4）如果输入条件是一个布尔量，可以定义为一个合法和一个非法类。例子1：依据整型或浮点变量值划分。在一个应用程序中，用整数age表示人的年龄。假设其范围是[1..120]，那么age的输入自然被划分为三类：(a)自然数的集合[0,∞]，(b)计算机表达的整数，例如，[0..32767]，(c)实际的范围[1..120]。在测试中，再考虑到：(d)工作年龄段为[1..60]和退休年令段[61..120]。由此，一个测试年龄的等价类为，<1，[1..60]，[61..120]，[120,32767]，>32767。测试者可以分别从这5个等价类中取得一个值作为代表。例子2：依据字符串变量划分。例如定义：firstname:string，则其等价类为：{空字符串}，{张三}，{最长长度的字符串}，以及{超过最长长度的字符串}。例子3：数组变量。int[]aName：newint[3];则其等价类为：{[]},{[-10,20]}，{[-9,0,12,15]}例子4：枚举量划分。例如定义：Autocolor:{red,blue,green};则其等价类为：{{red}，{blue},{green}}例子5：布尔量划分。Up:Boolean;则其等价类为:{{true}，{false}}例子6：组合的例子。约束条件为：3≤x≤7且5≤y≤9，那么,组合的情况为：图14-6,p.26514.3.4边界值方法如果简单地从图14-6中的等价类中取一组值是有风险的。因为软件的许多错误往往就出现在边界值上。边界值分析(BVA—BoundaryValueAnalysis)就是针对边界产生测试用例的方法，弥补等价类方法的不足。BVA的选择原则1）如果输入条件是有值a,b指定的区间，先搞清楚区间的开闭情况，例如，[a,b]或（a,b）或[a,b），然后，分别用a，b，a<，>b等测试。2）如果输入条件是许多值，测试用例要分别用最小、最大值测试，以及大于最大值和小于最小值进行测试。3）把上述1）和2）用于输出条件，例如，“温度”和“压力”是两个输出。测试用例要创立输出表，分别产生“温度”和“压力”的最大和最小值。4）如果内部程序数据结构有预定义的边界(例如，100项的数组)，一定要测试其边界的值。例子7：假设code的范围是99..999，quantity的范围时1..100。第一步：划分出等价类如下：Code的等价类：E1:<99；E2:[99..999]；E3:>999。quantity的等价类：E4:<1；E5:[1..100]；E6:>100。第二步，标出各个变量的边界第三步，构造出测试用例测试用例输入参量值codequantityt1980t2991t31002t499899t5999100t6100010114.3.5因果图方法因果图(CEG-Cause-EffectGraphing)来源于硬件测试，被Elmendorf引入到软件测试中。首先用自然语言标识原因、结果和约束条件，然后，构造CEG图。CEG图是一个组合的逻辑网络图，其中，结点(表示原因和结果)，弧线(表示布尔操作符：与、或、非)将原因和结果连接起来的约束条件。最后，跟踪这张图，按顺序建立判定表，转换为使用用例，以及测试用例。例子—文字叙述在网络中，sendfile命令用来发送一个文件到不同的文件服务器。

Sendfile有三个变量：变量1是发送者根目录的文件名，变量2是接收方文件服务器的名称，变量3是接收方的用户号(userid)。

如果所有的变量是正确的，那么文件成功发送，否则给发送者返回一个错误信息。第一步阅读上述的描述，梳理出因果原因结果1．变量1是发送者根目录的文件名，2.变量2是接收方文件服务器的名称，3.变量3是接收方的用户号(userid)。100.文件成功发送，101.发送者得到一个错误信息。第2步，依据因果关系表，用“等于”、“与”、“或”、“非”等符号画出因果图。常用的因果符号第3步，将因果图转换为判定表。将每个原因分别取“真/假”值进行组合，并给出相应的结果值。第4步，消除判定表中的无用或重复项。判定表会出现一些“有输入原因，但却没有任何输出结果的情况”，或者，有些输入和输出都是相同的情况。消除的目的是：降低测试的工作量14.4OO程序的测试14.4.1OO程序测试面临的问题14.4.2传统测试方法对OO测试适用性14.4.3OO程序测试方法14.4.4类内的MtSS的方法14.4.5对象类之间的MtSS的方法14.4.6对象之间的MgSS方法14.4.7从交互图获得MtSS和MgSS14.4.8OO测试的充分性14.4.1OO程序测试面临的问题OO编程的单元测试必然是针对类和对象的测试，而不仅仅是传统结构化语言的对函数的测试。测试一个对象类：首先，要测试对象内的方法，可以采用传统的方法测试其路径、语句、分支等的覆盖情况，验证其功能和错误情况。其次，要测试对象组完成所要求的任务需要利用消息空间发送消息序列关系，被验证对象之间的调用关系。第三，必须考虑类的继承问题。面向对象集成过程与传统程序的集成不一样。为面向对象的系统编写测试驱动程序或打桩，也没有传统程序的调用关系显得那么简洁明了。对象的创立、运行和消亡：每个对象就好像是一个独立运行的进程和代理，这种代理可能会动态地创立、运行和消亡。对象间的消息传递是动态的：对象之间的调用和参数传递次序是动态的，因此，仅仅考虑形参和实参数位置是不够的，还需要追加参数传递和调用的时间顺序。14.4.2传统测试方法对OO测试适用性黑箱的测试用例设计方法都可以用于OO测试。随机测试、判定表、等价类、边界值、因果图等都可以用来设计OO的测试用例，因为黑箱测试不考虑代码的结构和组织关系。显然，各种白箱测试方法可以用于类内每个方法的测试。测试基本路径、分支、语句、判断，以及数据流测试技术都是有助于对每个方法的验证。白箱测试方法也可以用于类层面的测试，特别是对类进行时。例如，类Base含有两个操作inherited()和redefined()。如果类Derived继承Base，并重新定义redefined()，就必须对Derived::redefined()进行测试，因为redefined()必然已经具有了新代码。之外，如果inherited()也调用redefined()，也必须对inherited()进行测试。14.4.3OO程序测试方法需要进一步讨论OO的测试.如何根据需求和设计规格说明派生出OO测试用例UML等图形化的建模和设计语言为OO的编程和开发带来了高效率，同样可以帮助实施OO测试。这里讨论Kirani等提出用方法和消息序列规格说明(MethodandMessageSequenceSpecification)说明类集合中的实例方法之间的因果关系的方法。首先，定义14.1Methods(C)：对于一个类C，定义Methods(C)为类C中所有可公开被使用的实例方法集合。例如，一个堆栈(stack)C的方法集合是：Methods(Stack)={push,pop,isempty?,isfull?,top}接下来，讨论一个类内部的MtSS、对象间的MtSS和MgSS，以及如何从前面第9章给出的各种UML建模图形直接派生出MtSS和MgSS。14.4.4类内的MtSS的方法定义14.2方法序列(MethodSequence)：一个方法序列S是一个类C中的方法集合M的有限序列(m0,m1,:::mn)，这里mi

∈M。一个方法序列并不一定包含所有所有的方法。序列中的项对应于方法被调用的次序。例如，一个堆栈类C的可能的方法序列是(push,top,pop,isempty?)。定义14.3SeqSpec(C):SeqSpec(C)是类C的一个说明，它定义了C中所有方法之间的顺序关系。用REc表达正则定义图14-11图14-11(b)中有限状态自动机按正则表式表达的SeqSpec(Account)如下：定义14.4SafeSeq(C)：一个SafeSeq(C)是从类C的SeqSpec(C)派生出了的所有序列Si。这样，SafeSeq(C)就是类C的实例可以接受的合法的序列。SafeSeq(C)是SeqSpec(C)定义出的正则子集。接着上面图14-11的Account的例子，识别出对象能接收的所有可能的合法消息队列，即，SafeSeq(Account)。下面的序列是安全的：{(Create,Open,Deposit,Withdraw,Close,Delete),(Create,Open,Deposit,Deposit,Withdraw,Close,Delete),…}14.4.5对象类之间的MtSS的方法图简化的ATM的Account类的对象图。编号给出了Bank和Account之间的操作顺序。14.4.6对象之间的MgSS方法MtSS只是解决了Account类中的方法被调用的顺序，包括Account类内部的调用，或被外部对象的调用次序。MgSS可以说明向外输出消息的每个方法。MgSS和MtSS一起可以表达和分别定义的两个方法之间的因果次序。例如，图中含有四个对象O1、O2、O3、O4。O1的方法m1发送消息给O2、O3、O4。依据m1按向外面的方法m2、m3、m4发送消息的次序不同，可以得到方法m1的不同的MgSS。如果按m2、m3、m4的次序向外发消息，那么m1的MgSS是：如果按先向m2或m3发送，后向m4发送消息次序，那么，m1的MgSS是：

可以根据与其它对象交互的方式定义出MgSS交互场景的不同，所引导出的MgSS也不同。1）如果一个方法接着上一个方法向外发消息，那么所有的消息的次序将被表达出来。例如，如果m2和m3按顺序发送，相应的MgSS是m1.m2.m3。2）如果发送一个可选消息和其它消息，可选消息用“？”表达。例如，如果m1是可选的，然后发送m2、m3，那么MgSS为：m1?.m2.m3。当依据条件判断决定发送消息时，消息算作是可选的。3）如果一个方法发送的消息是可替换的，如，“真”用一个消息，“假”用另一个消息，MgSS将把这两个消息作为可替换的消息。例如，如果m1或m2被发送，那么MgSS为m1|m2。4)如果一个方法向外循环地发消息，那么用操作符“*”或“+”。“*”表达循环零或多次，“+”表达1或多次。例如，如果m1重复向外发送一次或多次，接着发送m2，那么MgSS是(m1+).m2。14.4.7从交互图获得MtSS和MgSS为得到ATMHardware的MtSS，只需考虑发生readAmt和dispCase两个可能发生的事件。其次序是由事件产生的次序所决定的，事件的发生可能是条件的、循环的等情况，由取款者(系统边界—虚线的左面)决定。MtSS:MgSS:14.4.8OO测试的充分性Andrews等认为需要在UML合作图的基础上进行测试，并同时考虑如下的测试准则：(1)条件覆盖准则，(2)判断覆盖准则，(3)与每个消息相关联的准则，(4)所有消息的路径准则，以及(5)聚集(collection)覆盖准则。Binder对面向对象的测试原理、方法和技术做了全面的论述。这里简要给出OO相关的覆盖准则：1）继承原则：对于所有面向对象语言必须验证：一个类所用到的所有继承类的方法是正确的；如果是指定参数类型的子类、所有的参数都是正确的；具有同名字的所有方法执行相同的逻辑操作，并要求精确且充分的文档可以使用一个独立的使用者使用所有的构件。2)回归原则：超类的改变将会使测试结果彻底改变，因为超类可能会影响所有子类。由于OO编程的主要目的复用，必须重新测试或做回归测试，一旦超类被改变。3)增量式的类测试原则：增量式地测试超类的历史可以反映出派生类和超类的差异情况。只有新的属性或继承时，受影响的属性及其相互之间的作用才需要被测试。这样可以节约测试时间，分析和决定测试哪些类，以及测试这些类的所花费的时间。4)类的接口与数据流覆盖对比原则：Zweben建立了类接口模型，用结点表示类的方法的“定义”和“使用”。传统的数据流测试覆盖(见13.3节)OO的类接口测试覆盖全语句全操作全分支全可行的边全路径(all-defs)全路径全用法(all-uses)全用法全定义(all-defs)全定义全执行路径(All-du-path)全执行消息序列5)多态绑定准则。OO的多态绑定是一个难以测试的问题。Thuy证明“对一个动态服务的单一绑定执行是不够的”，因为只有当所有调用方法的所有重定义都被执行过后，覆盖才完全。McCabe提出了构件制导策略覆盖多态服务的测试用例问题。系统中的每个类都由一个驱动程序对其测试。类的测试包括：1)基本路径测试，2）测试类的方法所有的实验情况，3）测试多态服务器的每个重载至少一次。当这三项均被测试后，该类是“安全”的。慎用OO！达到这些准则的要求并不意味着被测的OO程序是可信任的。OO测试的难度远比传统语言的程序测试难度大。毫无疑问，OO程序的集成、多态性、动态绑定等优点可以极大地提高程序的开发效率，同时也增加了代码测试验证的难度，更难用测试的完整曾度判断软件的可信任程度。在一些“安全关键”领域禁止用OO的继承、多态等属性，甚至禁止用OO编程，主要的问题是很难测试和评价代码的可信任程度(见14.6节)。14.5不可测试软件的测试14.5.1数值求解问题14.5.2“四舍五入”问题14.5.3规划类问题14.5.1数值求解问题如何判断微分和偏微分方程（组）是否收敛？该软件系统中的输入函数是不确定的？例如，测试一个导弹的控制系统时，人们往往用：直线，正弦函数、线性函数等作为输入，测试系统是否能控制的住(预计输出是否合理)实际上，一个被追踪目标的飞行曲线并不是这样简单，那么，能否保证导弹控制系统求解微分方程时能够收敛哪？这一类系统的测试往往是不充分的，无法测试出所有的情况。14.5.2“四舍五入”问题标准公式：总成绩=平时*10%+期中*30%+期末*50%+实验*10%公式A：总成绩=INT(平时*0.1+期中*0.3+期末*0.5+实验*0.1+0.5)公式B：总成绩=INT(平时*0.1+0.5)+INT(期中*0.3+0.5)+INT(期末*0.5+0.5)+INT(实验*0.5+0.5)如果上述计算的是银行、股市交易、财务系统的总账，或者是将总账拆分，甚至具有更复杂的算法(不仅仅是加减乘除)等。例如，全国的个人所得税收的总账计算中，每个人依据收入(平时工资收入、股票收入、偶然性收入等)严格按“四舍五入”交税，可以用类似于公式B累计出全国个税总数。税务局也可以用公式A向国家报告总税收。两者的结果会出现一定的误差。如果软件测试者不知道系统的误差到底是多大，测试时就很难判定系统的正确性。14.5.3规划类问题理论上，规划类问题是图灵机不可计算的。在实际工程中，可以增加一些应用的约束条件，让规划问题变成实际上可行的软件系统。例如，学生的选课软件系统。测试这样的规划类软件，应当考虑：1）给定一组输入数据，测试者是否能给出准确的或最优的答案是什么？如果不能，如何判断出该软件的功能是否正确；2）测试给出的输入数据总是有限的，能否预测随着各种参数(如，学生人数、课的门类、课时段等)的增加，所期望的计算结果？3）测试者能否给出输入/输出的等价类，以及输入和输出的因果关系？等等。14.6何时停止测试？测试工程最难回答的问题是：何时可以停止测试？广泛的原则是：(1)测试工期达到了进度要求；(2)设计的所有测试用例不再能测试出错误，即，测试不再成功时。这对吗？如何办？测试总是要停止的！必须寻找能说服客户、开发者等的“可以停止测试”方法。14.6何时停止测试？14.6.1错误种子法14.6.2错误种子测试的信任度14.6.3覆盖率与测试信任度

14.6.4能力基线与测试信任度14.6.1错误种子法IBM的Mills于1972年就提出通过“错误播种(faultseeding)”的方法估计程序中的错误数量。Pfleeger根据Mills的提议，进一步假设播种的错误数为S，N是代码中固有错误总数，S和N具有一样的严重程度，并以相等的概率被测出。再假定s是测试工作中发现的撒入的错误数，n是测试中发现代码原有的错误数，那么概率上就有：从而估算出代码中固有的错误数为：

接下来的问题是如何向被测程序中种入错误种子：(1)变异测试方法(见面13.4节的讨论)，即，变更正确程序的操作符，引发错误。这种办法需要付出大量的时间成本，因为要对其进行测试。另外，是对语法做简单改变，并不一定能引发出代码中原先隐藏着的严重（结构和语义等）错误。(2)随机错误播种。事先定义错误的分布模型，采用工具对代码按随机方式播种错误。这种方法的好处在于，播种效率和分析效率都会比较高，也避免认为播种的偏见。但是，这种方法法可能会导致“盲点”，即，对期望测试出的错误的估计不足。这项技术对于判断语言处理器方面的软件错误是非常有用的。(3)专家播种。以专家对编程语言和领域知识的理解为基础，撒播错误种子。这样可以有针对性地，将错误撒播到希望测试的部分。并且可以根据开发团队经常犯错误的错误分类，有意地撒播一些具有代表性的种子。但是这种放工作方法可能极其耗时，很难用于大规模的程序，明显带有专家个人意识的偏见。(4)程序依赖图(PDG--ProgramDependenceGraph)。用PDG表达程序数据依赖和控制依赖关系，即，节点表达语句和判断，边表达数据依赖和控制依赖。。14.6.2错误种子测试的信任度测试并不不意味着可以把代码中的错误全部测试出来。这样就以一个对软件的使用的信心问题。可以把可信任程度(confidence)表达为一个百分比，即，软件是“无错”的概率。即，如果confidence=95%，就意味着，软件中没有错误的概率为95%。假设一个软件理论上固有N个错误，向软件播种S个错误。当测试出所有的播种的S个错误时，设n是测试期间发现的代码的真实错误个数，那么，采用错误种子法所获得软件测试工作的信任度是：Richard在1974年改进了评价方法，建议用当前发现的种子错误数，不管是否都被发现，来计算Con。14.6.3覆盖率与测试信任度除非完全路径覆盖达到100%，之外，语句、分支等覆盖率达到100%也不能说明软件是完全可信度。工业界的普遍做法是：划分软件的安全等级，并依据安全等级对开发过程、测试过程、验证过程的目标等做出规定。从而提高软件的可信任程度，而不仅仅是在后期(如，测试阶段)来评价软件的可信任程度。参见书的第三部分关于安全关键领域的测试要求，特别是民用航空要求14.6.4能力基线与测试信任度如果我们能够从历史数据中获得开发队伍在软件开发过程中各个活动引入错误的密度，那么就能当能估计出需要测试出的错误个数。实际上，随着企业或组织的开发队伍能力的稳定和提高，按照当今普遍认可的CMM/CMMI模型对开发团队的能力稳定和改进。特别是CMMI第四级要求计算和使用团队的能力基线。这种基线自然包括各个阶段生产力和产生缺陷的密度数据和分布情况。参见第20章。可以使用这种有历史数据确定的错误密度，估计出每个阶段产生的缺陷数和应当测试出缺陷个数，从而估计出遗留在系统中的缺陷个数。14.7可信赖性测试和评价14.7.1可恢复性测试

14.7.2密安性测试14.7.3压力测试14.7.4性能测试14.7.5可信赖性评价14.7.1可恢复性测试可恢复测试就是要创立让系统整个或部分发生故障，验证系统恢复能力的系统级的测试。因此，这些测试用例不是简单是输入数据，可能包括强制停电、通信线路中断等物理手段。如果系统具有自动恢复能力，则要对系统重新初始化，检查关键程序和数据恢复节点，以及启动和进入正常服务的关键流程进行跟踪和评估。如果需要人工干预，计算包括人工处理在内的恢复时间。将自动恢复和人工恢复