软件测试概念方法实例解读

1、软件测试看法、方法以及实例解读软件测试看法、方法以及实例解读71/71软件测试看法、方法以及实例解读一、数据引用错误1、能否有引用的变量未赋值或未初始化？这可能是最常有的编程错误，在各样环境中都可能发生。在引用每个数据项（如变量、数据元素、结构中的域）时，应试图非正式地“证明”该数据项在目前地点拥有确定的值。2、对于所有的数组引用，能否每一个下标的值都在相应规定的界线以内？3、对于所有的数组引用，能否每一个下标的值都是整数？固然在某些语言中这不是错误，但这样做是危险的。4、对于所有的经过指针或引用变量的引用，目前引用的内存单元能否分配？这就是所谓的“虚调用（danglingreference）

2、”错误。当指针的生命期大于所引用内存单元的生命期时，错误就会发生。当指针引用了过程中的一个局部变量，而指针的值又被赋给一个输出参数或一个全局变量，过程返回（开释了引用的内存单元）结束，此后程序试图使用指针的值时，这种错误就会发生。与前面检查错误的方法近似，应试图非正式地“证明”，对于每一个使用指针值的引用，引用的内存单元都存在。5、假如一个内存地区拥有不一样属性的别名，当经过别名进行引用时，内存地区中的数据值能否拥有正确属性？6、变量值的种类或属性能否与编译器所预期的一致？7、当使用的计算机上，当内存分派的单元小于内存可寻址的单元大小时，能否存在直接或间接的寻址错误？比方，在某些条件下，定长的

3、位串不用以字节界限为起点，可是地点又老是指向字节界限的。假如程序计算一个位串的地点，稍后又经过该地点引用这个位串，可能会指向错误的内存地点。将一个位串参数传给一个子程序时，也可能发生这种状况。8、当使指针或引用变量时，被引用的内存的属性能否与编译器所预期的一致？9、若是一个数据结构在多个过程或子程序中被引用，那么每个过程或子程序对该结构的定义能否都相同？10、假如字符串有索引，当对数组进行索引操作或下标引用，字符串的界限取值能否有“仅差一个”（off-by-one）的错误？11、对于面向对象的语言，能否所有的继承需求都在实现类中获取了满足？二、数据申明错误1.能否所有的变量都进行了明确的申明？

4、没有明确申明固然不必定是错误，但平常倒是麻烦的源泉。2.假如变量所有的属性在申明中没有明确说明，那么默认的属性可否被正确理解？3.假如变量在证明语句中被初始化，那么它的初始化能否正确？在很多语言中，数组和字符串的初始化比较复杂，所以也成为简单犯错的地方。4.能否每个变量都被给予了正确的长度和数据种类？5.变量的初始化能否与其储存空间的种类一致？6.能否存在着相像名称的变量（如volt和volts）？这种状况不必定是错误，但应被视为警示，这些名称可能会在程序中发生混杂。三、运算错误1、能否存在不一致的数据种类（如非算术种类）的变量间的运算？2、能否有混杂模式的运算？3、能否有相同数据种类，不一样

5、字长变量间的运算？4、赋值语句的目标变量的数据种类能否小于右侧表达式的数据种类或结果？5、在表达式的运算中能否存在表达式向上或向下溢出的状况？也就是说，最后的结果看起来是个有效值，但中间结果对于编程语言的数据种类可能过大或过小。6、除法运算中的除数能否可能为0？7、假如计算机表达变量的基本方式是鉴于二进制的，那么运算结果能否不精准？也就是说，在一个二进制计算机上，10*0.1极少会等于1.0。8、在特定场合，变量的值能否高出了存心义的范围？9、对于包含一个以上操作符的表达式，赋值次序和操作符的优先次序能否正确？10、整数的运算能否有使用不妥的状况，特别是除法？四、比较错误1、能否有不一样数据种

6、类的变量之间的比较运算，比方，将字符串与地点、日期或数字对比较？2、能否有混杂模式的比较运算，或不一样长度的变量间的比较运算？假若有，应保证程序能正确变换规则。3、比较运算符能否正确？程序员常常混杂“至多”、“最少”、“大于”、“不小于”、“小于”和“等于”等比较关系。4、每个布尔表达式所表达的内容能否正确？在编写波及“与”、“或”或“非”的表达式时，程序员常常犯错。5、布尔运算符的操作数是不是布尔种类的？比较运算符和布尔运算符能否错误地混在了一同？这是一类常常会犯的错误，这里我们描绘几个典型错误的例子。假如想判断i能否在210之间，表达式2i10是不正确的；相反，正确的应当是（2i）&（ix

7、|y也是不正确的，正确的应当是（ix）|（iy）。假如要比较三个数字能否相等，表达式if(a=b=c)的实质意义却天地之别。假如需要考证数学关系xyz，正确的表达式应当是（xy）&（yx）。6、在二进制的计算机上，能否实用二进制表示的小数或浮点数的比较运算？因为四舍五入，以及用二进制表示十进制数的近似度，这常常是错误的本源。7、对于那些包含一个以上布尔运算符的表达式，赋值次序以及运算符的优先次序能否正确？也就是说，假如碰到如(if(a=2)&(b=2)|(c=3)的表达式，程序可否正确理解是“与”运算在先还是“或”运算在先？8、编译器计算布尔表达式的方式能否会对程序产生影响？五、控制流程错误1

8、、假如程序包含多条分支路径；2、能否所有的循环最后都停止了？应设计一个非正式的凭证或论据来证明每一个循环都会停止。3、程序、模块或子程序能否最后都停止了？4、因为实质状况没有满足循环的进口条件，循环体能否有可能从未履行过？假如的确发生这种状况，这里是不是一处疏忽？5、假如循环同时由迭代变量和一个布尔条件控制（如一个找寻循环），如果循环越界（fall-through）了，结果会如何？6、能否存在“仅差一个”的错误，如迭代数目恰很多一次或少一次？这在从0开始的循环中是常有的错误。我们会常常忘掉将“0”作为一次计数。7、假如编程语言中有语句组或代码块的看法（比方do-while或），能否每一组语句都

9、有一个明确的while语句，并且do语句也与其相应的语句组对应？或许，能否每一个左括号都对应一个右括号？目前的大部分编译器都能鉴识出这些不般配的状况。8、能否存在不可以穷尽的判断？举例来说，假如一个输入参数的预期值是1,2,或3，当参数值不1或2时，在逻辑上能否假定了参数必然为3？假如是这样的话，这种假定能否有效？六、接口错误1、被调用模块接收到的形参（parameter）数目能否等于调用模块发送的实参（argument）数目？其余，次序能否正确？2、实参的属性（如数据种类和大小）能否与相应形参的属性相般配？3、实参的量纲能否与对应形参的量纲相般配？举例来说，能否形参以度为单位而实参以弧度为单

10、位？4、此模块传达给彼模块的实参数目，能否等于彼模块希望的形参数目？5、此模块传达给彼模块的实参属性，能否与彼模块相应形参的属性相匹配？6、此模块传达给彼模块的实参的量纲，能否与彼模块相应形参的量纲相匹配？7、假如调用了内置函数，实参的数目、属性、次序能否正确？8、假如某个模块或类有多个进口点，能否引用了与目前进口点没关的形参？9、能否存子程序改变了某个本来仅为输入值的形参？10、假如存在全局变量，在所有引用它们的模块中，它们的定义和属性能否相同？11、常数能否以实参形式传达过？在一些用FORTRAN语言编写的程序中，诸如CALLSUBX(J,3)的语句是很危险的，因为假如子程序SUBX对其第

11、二个形参进行赋值，常数3的值将会被改变。七、输入/输犯错误1、假如对文件明确申明过，其属性能否正确？2、翻开文件的语句中各项属性的设置能否正确？3、格式规范能否与I/O语句中的信息相吻合？举例来说，在FORTRAN语言中，能否每个FORMAT语句都与相应的READ或WRITE语句相一致（就各项的数量和属性而言）？4、能否有足够的可用内存空间，来保存程序将读取的文件？5、能否所有的文件在使用从前都翻开了？6、能否所有的文件在使用以后都封闭了？7、能否判断文件结束的条件，并正确办理？8、对I/O犯错状况能否正确？9、任何打印或显示的文本信息中能否存在拼写或语法错误？八、其余检查1、假如编译器建立了

12、一个表记符交织引用列表，那么对该列表进行检查，查察能否有变量从未引用过，或仅被引用过一次。2、假如编译器建立了一个属性列表，那么对每个变量的属性进行检查，确保没有给予过不希望的默认属性值。3、假如程序编译经过了，但计算机供应了一个或多个“警示”或“提示”信息，对付此逐个进行认真检查。“警示”信息指出编译器对程序某些操作的正确性有所思疑；所有这些疑问都应进行检查。“提示”信息可能会排列出没有声明的变冷了，或许是不利于代码优化的用法。4、程序或模块能否拥有足够的鲁棒性？也就是说，它能否对其输入的合法性进行了检查？5、程序能否遗漏了某个功能？总结：大部分的软件项目都应使用到以下的人工测试方法：（1）

13、利用错误列表进行代码检查；（2）小组代码走查；（3）桌面检查；（4）同行评审。一、白盒测试1、逻辑覆盖测试白盒测试关注的是测试用例履行的程度或覆盖程序逻辑结构（源代码）的程度。完好的白盒测试是将程序中每条路径都履行到，可是对一个有循环的程序来说，完好的路径测试其实不吻合实质。若完好从路径测试中跳出来看，那么有价值的目标仿佛就是将程序中的每条语句最少履行一次。遗憾的是，这正是合理的白盒测试中较弱的准则。判断覆盖或分支覆盖是较强一些的逻辑覆盖准则。该准则要求一定编写足够的测试用例，使得每一个判断都最罕有一个为真和为假的输出结果。换句话说，也就是每条分支路径都一定最少遍历一遍。分支或判断语句的例子包

14、含switch、do-while和if-else语句。在一些程序语言如Fortran中，多重选择goto语句也是合法的。判断覆盖平常能够满足语句覆盖。因为每条语句都是在要么从分支语句开始，要么从程序进口开始的某便条路径上，假如每条分支路径都被履行到了，那么每条语句也应当被履行到了。但仍有以下三种例外状况：（1）程序中不存在判断；（2）程序或子程序/方法有着多重进口点。只有从程序的特定进口点进入时，某条特定的语句才能履行到。（3）在on单元（ON-unit）里的语句。遍历每条分支路径其实不必定能保证所有的ON单元都能履行到。2、等价区分等价区分方法设计测试用例主要有两个步骤：（1）确定等价类；（

15、2）生成测试用例。（1）确定等价类：确定等价类是采用每一个输入条件（平常是规格说明中的一个句子或短语）并将其区分为两个或更多的组。注意，我们确定了两类等价类：有效等价类代表对程序有效输入，而无效等价大表的则是其余任何可能的输入条件（即不正确的输入值）。外面条件有效等价类无效等价类等价类列举表比方：假如输入条件规定了一个取值范围（如“数目能够是1到999”），那么就应确定出一个有效等价类（1数目999），以及两个无效等价类（数目999）。（2）生成测试用例，过程以下：为每个等价类设置一个不一样的编号；编写新的测试用例，尽可能多地覆盖那些还没有被涵盖的有效等价类，直到所有的有效等价类都被测试用例所

16、覆盖（包含进去）。编写新的用例，覆盖一个且仅一个还没有被涵盖的无效等价类，直到所有的无效等价类都被测试用例所覆盖。3、一个典范4、界限值分析经考证明，考虑了界限条件的测试用例与其余没有考虑界限条件的测试用例对比，拥有更高的测试回报率。所谓界限条件，是指输入和输出等价类中那些恰利处于界限或超出界限、或在界限以下的状态。界限值分析方法与等价区分方法存在双方面的不一样：与从等价类中优选出任意一个元素作为代表不一样，界限分析需要选择一个或多个元素，以便等价类的每个界限都经过一次测试。与不过关注输入条件（输入空间）不一样，还需要考虑从结果空间（输出等价类）设计测试用例。5、因果图界限值分析和等价区分的一

17、个短处是未对输入条件的组合进行分析。因果图有助于用一个系统的方法选择出高效的测试用例集。它还有一个额外的利处，就是能够指出规格说明的不完好性和不明确之处。因果图是一种形式语言，用自然语言描绘的规格说明能够变换为因果图。因果图其实是一种数字逻辑电路（一个组合的逻辑网络），但没有使用标准的电子学吻合，而是使用了略微简单点的符号。生成测试用例时采用的过程以下：（1）将规格说明分解为可履行的片段。这是一定的步骤，因为因果图不善于办理较大的规格说明。举例来说，当测试一个电子商务系统时，“可履行的片段”可能是指对优选和确认购物车中的单件商品的规格说明。在测试一个Web页面设计时，我们可能会测试一个独自的菜

18、单树，甚至是一个不太复杂的导航序列。（2）确定规格说明中的因果关系。所谓“因”，是指一个明确的输入条件或输入条件的等价类。所谓“果”，是指一个输出条件或系统变换（输入对程序或系统状态的连续影响）。举例来说，假如某个事务惹起文件或数据库记录被修改，那么这种改变就是一个系统变换，而系统反应的确认信息就是一个输出条件。经过逐字逐句地阅读规格说明，同时表记出描绘“因”和“果”的文字或句子，就能够将“因”和“果”确定出来。因果关系一旦确定下来，每个“因”和“果”都被给予一个独一的编号。（3）分析规格说明的语义内容，并将其变换为连结因果关系的布尔图。这就是所谓的因果图。（4）给图加上说明符号，说明因为语法

19、或环境的限制而不可以联系起来的“因”和“果”。（5）经过认真地追踪图中的状态或环境的限制而不可以联系起来的“因”和“果”。（6）将判断表中的列变换成测试用例。二、错误猜想错误猜想是他们利用直觉和经验猜想犯错的可能种类，而后编写测试用例来裸露这些错误。因为错误猜想主若是一项依靠于直觉的非正规的过程，所以很难描绘出这种方法的规程。其基本思想是列举出可能犯的错误或错误易发状况的清单，而后依照清单来编写测试用例。比方，程序的输入中出现0这个值就是一种错误易发状况。所以，能够编写测试用例，检查特定输入值中有0，或特定的输出值被强迫为0的状况。相同，在出现输入或输出的数目不定的地方（如某个被找寻列表的条目

20、数目），数目为“没有”和“一个”（比方空列表，仅包含一个条目的列表）也是错误易发状况。另一个思想是，在阅读规格说明时联系程序员可能做的假定来确定测试用例（即规格说明中的一些内容会被忽视，要么是因为有时要素，要么是程序员以为其不言而喻）。因为没法给出一个规程来，次优的选择是谈论错误的实质，最好的做法是举出实例。假定在测试一个排序程序，要商讨的状况以下：(1)输入列表为空；(2)输入列表包含一个条目；(3)输入列表所有条目的值都相同；(4)输入列表已经排过序。换言之，上面列举出的这些特别状况可能在程序设计时被忽视。假如要测试的是一个二进制找寻程序，需要检查的状况包含：（1）被找寻的表中只有一个条目

21、；（2）表的大小是2的幂（如16）；（3）表的大小是2的幂差1和2的幂多1。三、测试策略每一种方法都能够供应一组详尽的实用的测试用例，可是都不可以独自供应平一个完好的测试用例集。一组合理的策略以下：（1）假如规格说明中包含输入条件组合的状况，应第一使用因果图分析方法。（2）在任何状况下都应使用界限值分析方法。应记着，这是对输入和输出界限进行的分析。界限值分析能够产生一系列增补的测试条件，可是，也正如“因果图分析”一节所述，多半甚至所有条件都能够被整合到因果图分析中。（3）应为输入和输出确定有效和无效等价类，在必需状况下对上面确认的测试用例进行增补。（4）使用错误猜想技术增加更多的测试用例；（5

22、）针对上述测试用例集检查程序的逻辑结构。应使用判断覆盖、条件覆盖、判断/条件覆盖或多重条件覆盖准则（最后的一个最为完好）。假如覆盖准则未能被前四个步骤中确定的测试用例所满足，并且满足准则也非不行能（因为程序的性质限制，某些条件的组合或许是不行能实现的），那么增加足够数目的测试用例，以使覆盖准则获取悉足。模块（单元）测试模块测试(或单元测试)是对程序中的单个子程序、子程序或过程进行测试的过程，也就是说，一开始其实不是对整个程序进行测试，而是第一将注意力集中在对构成程序的较小模块的测试上面。这样做的动机有三个。第一，因为模块测试的注意力一开始集中在程序的较小单元上，所以它是一种管理组合的测试元素的

23、手段。其次，模块测试减少了调试（正确定位并纠正某个已知错误的过程）的难度，这是因为一旦某个错误被发现出现，我们就知道它在哪个详尽的模块中。第三，模块测试经过为我们供应同时测试多个模块的可能，将并行工程程引入软件测试中。模块测试的目的是将模块的功能与定义模块的功能规格说明或接口规格说明进行比较。为了再次重申所有测试过程的目的，这里的测试目标不是为了说明模块吻合规格说明，而是为了揭示出模块与其规格说明存在着矛盾。以下是从三个方面来商讨模块测试：（1）测试用例的设计方式；（2）模块测试及集成的次序；（3）对履行模块测试的建议。一、测试用例设计在为模块测试设计的测试用例时，需要使用两各样类的信息：模块

24、的规格说明和模块的源代码。规格说了然一般都规定了模块的输入和输出参数以及模块的功能。模块测试整体上是面向白盒测试的。此中一个原由是假如对大一点的软件进行测试，比方一个完好的程序（其实是后续的测试过程所针对的对象），白盒测试不简单睁开。第二个原由是，后续的测试过程着眼于发现其余种类的错误（举例来说，这些错误不必定与程序的逻辑结构有关，比方程序未能满足其用户需求）。所以，模块测试的测试用例的设计过程以下：使用一种或多种百合测试方法分析模块的逻辑结构，而后使用黑盒测试方法比较模块的规格说明以增补测试用例。二、增量测试在履行模块测试过程中，我们主要有两点考虑：第一，如何设计一个有效的测试用例集；第二，

25、将模块组装成工作程序的方式。第二点考虑很重要，因为它波及模块测试用例编写的形式、可能用到的测试工具种类、模块编码和测试的次序、生成测试用例的成本以及调试（定位并修复检查出的错误）的成本等。简而言之，它拥有实质重要性。在这一节中，我们将谈论两类方法，增量测试和非增量测试。这里需要考虑的问题是：软件测试能否应先独立地测试每个模块，而后再将这些模块组装成完好的程序？还是先将下一步要测试的模块组装到测试达成的模块会合中，而后再进行测试？第一种方法称为非增量测试或“崩溃（big-bang）”测试，而第二种方法称为增量测试或集成。测试独自的模块需要一个特别的驱动模块（drivermodule）和一个或多个

26、桩模块（stubmodule）。驱动模块是人们编写的一个小模块，用来测试用例驱动或传输到被测模块中（也能够用测试工具代替）。另一种可选择的方法是增量测试。不一样于独立地测试每个模块，增量测试第一将下一个要测试的模块组装到前面已经测试过的模块会合中去。结论以下：（1）非增量测试所需的工作量要多一些。增量测试所需的工作量要少一些，因为使用了前面测试过的模块来代替非增量测试中所需要的驱动模块（假如从顶部开始测试）或桩模块（假如从底部开始测试）。（2）假如使用了增量测试，能够较早地发现模块中与不般配接口、不正确假定有关的编程错误。这是因为尽早地对模块组合进行了集成测试。可是，假如采用非增量测试，只有到

27、了测试过程的最后阶段，模块之间才能“相互看到”。（3）所以，假如使用了增量测试，调试会进行得简单一些。我们假定存在着与模块间接口或假定有关的编程错误（依据经验而来的合理假定），那么，如果使用非增量测试，直到整个程序组装以后，这些错误才会浮现出来。到了这个时候，我们就难以定位错误，因为它可能存在与程序内部的任何地点。相反，如果使用增量测试，这各样类的错误就很简单发现，因为该错误很可能与近来增加的模块有关。（4）增量测试会将测试进行得更完全。换言之，增量测试使用先前测试过的模块，代替了非增量测试中使用的桩模块或驱动模块。所以，到最后一个模块测试达成时，实质的模块经遇到了更多的检验。（5）非增量测试

28、所占有的机器时间显得少一些。所以，达成一次增量测试所需履行的机器指令，明显剩余采用非增量测试方法所需的指令。但此消彼长的是，非增量测试要比增量测试需要更多的驱动模块和桩模块，开发这些驱动模块和桩模块是要占有机器时间的。（6）模块测试阶段时，假如使用的是非增量测试，就会有更多的机遇进行并行操作（也就是说，所有的模块能够同时测试）。对于大型的软件项目（模块和人员都很多），这可能十分重要，因为在模块测试开始之时，项目的人员数目常常处于最顶峰。三、自顶向下测试与自底向下测试1、自顶向下的测试自顶向下的测试是从程序的顶部或初始模块开始。测试开始以后，优选哪一个后连续模块进行增量测试没有独一正确的方法；独

29、一的原则是：要成为吻合条件的下一个模块，最少一个该模块的隶属模块（调用它的模块）早先经过了测试。长处：（1）假如主要的缺点发生在程序的顶层将特别有益；（2）一旦引入I/O功能，提交测试用例会更简单；（3）初期的程序框架能够进行演示，并可激发踊跃性。弊端：（1）一定开发桩模块；（2）桩模块要比最先表现的更复杂；（3）在引入I/O功能从前，向桩模块中引入测试用例比较困难；（4）创立测试环境可能很难，甚至没法实现；（5）观察测试输出很困难；（6）令人误会设计和测能够交迭进行；（7）会以致特定模块测试的达成延后。2、自底向上的测试在大部分状况下，自底向上的策略与自顶向下的策略是相对峙的；自顶向下测试的

30、长处成为自底向上的弊端，而自顶向下测试的弊端又成为自底向上测试的长处。自底向上的策略开始于程序中的终端模块（此类模块不再调用其余任何模块）。测试完这些模块以后，相同没有最正确的方法来优选要进行增量测试的下一个模块；独一正确的原则是，要成为吻合条件的下一个模块，该模块所有的隶属模块（它调用的模块）都已经早先经过了测试。长处：（1）假如主要的缺点发生在程序的底部层将特别有益；（2）测试环境比较简单建立；（3）观察测试输出比较简单。弊端：（1）一定开发驱动模块；（2）知道最后一个模块增加进去，程序才形成一个整体。3、履行测试当测试用例造成模块输出的实质结果与预期结果不般配的状况时，存在两个可能的解说

31、：要么该模块存在错误，要么预期的结果不正确（测试用例不正确）。为了将这种纷乱降低到最小程度，应在测试履行从前对测试用例集进行审察或检查（也就是说，对付测试用例进行测试）。使用自动化测试工具能够使测试过程中的无聊劳动减至最小。举例来说，此刻已有测试工具能够降低我们对驱动模块的需求。流程分析工具能够举例出程序中的路径、找出从未被履行的语句（不行达）代码，以及找出变量在赋值前被使用的实例。当程序没法实现其最后用户要求的合理功能时，就发生了一个软件错误。软件产品开发周期的模型，过程流程以下七个步骤：（1）将软件最后用户的要求变换为一系列书面的需求。这些需求就是该软件产品要实现的目标。（2）经过评估可行

32、性与成本、除去相抗争的用户需求、建立优先级和均衡关系，将用户需求变换为详尽的目标。（3）将上述目标变换为一个正确的产品规格说明，将产品视为一个黑盒，仅考虑其接口以及与最后用户的交互。该规格说明被称为“外面规格说明”。（4）假如该产品是一个系统，如操作系统、翱翔控制系统、数据库管理系统或雇员人事系统，而不但是一个程序（编译器、薪水程序、字办理程序等），那么下一步骤就是系统设计。该步骤将系统切割为独自的程序、零件或子系统，并定义它们的接口。（5）经过定义每个模块的功能、模块的层次结构以及模块间的接口，来设计程序或程序会合的结构。（6）设计一份正确的规格说明，定义每个模块的接口与功能。（7）经过一个

33、或更过的子步骤，将模块接口规格说明变换为每个模块的源代码算法。模块测试的目的是发现程序模块与其接口规格说明之间的不一致。功能测试的目的是为了证明程序未能吻合其外面规格说明。系统测试的目的是为了证明软件产品与其初始目标不一致。功能测试功能测试是一个视图发现程序与其外面规格说明之间存在不一致的过程。外部规格说明是一份从最后用户的角度对程序行为的精准描绘。除了在小程序中的使用状况以外，功能测试平常是一项黑盒操作。也就是说，要以来初期的模块测试的过程来实现理想的白盒逻辑覆盖准则。系统测试系统测试最简单被错误理解，也是最困难的测试过程。系统测试并不是是测试整个系统或程序功能的过程，因为有了功能测试，这样

34、会显得剩余。系统测试有着特定的目的：将其系统或程序与其初始目标进行比较。给定这个目标以后，隐含双方面的含义：1、系统测试其实不限制于系统。假如产品是一个程序，那么系统测试就是一个试图说明程序作为一个整体是如何不满足其目标的过程。2、依据定义，假如产品没有一组书面的、可胸怀的目标，系统测试也就无法进行。在找寻程序与其目标之间的不一致的过程中，应要点注意那些在设计外面规格说明的过程中所犯的变换错误。系统测试因此成为一种要点的测试种类，因为就软件产品自己、所犯错误的数目及严重性而言，开发周期的这个阶段是最易出错的。这也示意与功能测试的状况不一样，外面规格说明不可以作为获取系统测试用例的基础，不然就损

35、坏了系统测试的目标。可是另一方面，也不可以利用目标文档自己来表示测试用例，因为依据定义，这些文档其实不包含对程序外面接口的正确描绘。战胜这一两难场面的方法是利用程序的用户文档或书面资料。经过分析目标文档来设计系统测试，分析用户文档来说明测试用例。该方法能够产生双方面的作用，一是将程序与其目标和用户文档对比较；二是同时也将用户文档与程序目标想比较，以以下图所示：如上图说明为何系统测试是最困难的测试过程。图中最左侧的箭头表示将程序与其目标进行比较，是系统测试的核心目的，可是没有说明使用什么样的测试用例设计方法。因为目标文档论述了程序应当成什么、做到什么程度，却没实用说明程序功能如何表现。1、能力测

36、试最明显的系统测试种类是判断目标文档说起的每一项能力（或功能，为了避免与功能测试发生混杂而不使用“功能”一词）能否都的确已经实现。能力测试的过程是逐条语句地检查目标文档，当某条语句定义了一个“要做什么”（比方，“语法应当一致”、“用户应当能够指定一个空间范围”等），就判断程序能否满足。此各样类的测试常常能够在不使用计算机的状况下进行；有时人工对目标和用户文档进行比较就足够了。尽管这样，利用问题检查单将有助于在下一次进行测试时，保证人工检查的目标时相同的。2、容量测试第二类系统测试是使程序经受大容量数据的检验。举例来说，编译器可能要编译规模特别宏大的源程序，连结编写器可能需要办理一个包含上千模块

37、的程序、电子电路模拟器可能要输入一个包含上千零件的电路，而操作系统的作业行列可能已经达到饱和的容量。假如程序需要办理超越不一样卷的文件，则应产生足够的数据使应用程序从一个卷变换到另一此中。换言之，容量测试的目的是为了证明程序不可以办理目标文档中规定的数据容量。因为容量测试明显需要大批的资源，鉴于对机器和工时的考虑，不行进行过多的容量测试。自然，每个程序应当最少进行几次容量测试。3、强度测试强度测试使程序承受高负载或强度的检验。这不该和容量测试发生混杂；所谓高强度是指在很短的时间间隔内达到的数据或操作的数目峰值。近似的状况是测试一名打字员。容量测试是判断打字员可否办理大篇幅的稿子，而强度测试则是

38、判断打字员可否达到没每分钟50个单词的速度。因为强度测试波及时间要素，所以，它不合用于很多程序，如编译器或批量办理薪水程序。可是，强度测试合用于在可变负载下运转的程序，以及交互程序、及时程序和过程控制程序。若是某个空中交通控制系统要求在其地区内最多可跟踪200架飞机，则能够经过模拟200架飞机存在的状况来对其进行强度测试。因为再客观上没法防范第201架飞机进入该地区，所以需要进一步的强度测试，以观察系统对这个不请自来的反应。附带的强度测试则会模拟大批飞机同时进入该地区的状况。假如操作系统要求支持最多15个多道程序的作业，则可试试同时运转15个作业对其进行强度测试。能够让学员强行打左舵、后拉节流

39、阀、放下襟翼、抬起机头、放下起落架、翻开着陆灯并向左转弯等所有这些操作同时进行，观察系统如何反应，从而对翱翔员训练模拟器进行强度测试（这个测试用例可能需要一个长着四只手的翱翔员，或许现实一点，需要翱翔座舱里有两个测试专家）。可以经过让所有被督查的过程同时产生信号，来对过程控制系统进行强度测试。当对电话互换系统进行强度测试时，能够让大批电话同时打入该系统。鉴于Web的应用程序是最常接受强度测试的软件之一。在这里，我们需要确信的是应用程序及硬件能够办理必定容量的并发用户。读者可能会争论论，或许有数百万人在同一时刻接见站点最大人群的状况。固然有很多强度测试表现的是程序再运转过程中可能会碰到的状况，可

40、是也有另一些强度测试的确表现了“不行能发生”的状况，但这其实不意味这些测试是无用的。假如在这些不行能发生的状况中检查出了错误，那么这项测试就是有价值的，因为相同的错误也可能发生在现实的、强度稍低的环境中。4、易用性测试系统测试的另一个重要种类是视图发现人为要素或易用性的问题。以下的清单中，我们列举了需要测试的一些问题：（1）每个用户界面能否都依据最后用户的智力、教育背景和环境要求而进行了调整？（2）程序的输出能否存心义、不模糊且没有计算机的纷杂信息？（3）错误诊疗（如错误信息）能否直接，用户能否需要有计算机学科的博士学位才能理解它们？举例来说，程序能否产生了诸如“IEK022AOPENERRO

41、RONFILESYSINABENCODE=102?”此类的信息？象这样的信息在二十世纪七、八十年月的软件系统中其实不鲜见。今日的面向大众销售的系统在这方面有了改良，但我们仍旧会碰到诸如“出现一个未知错误”或“程序碰到了一个错误，一定从头启动”这样无用的信息。自己编写的程序是由自己控制的，不该加入这些无用的信息。即使我们其实不开发软件，假如在测试小组中工作，那么能够推感人机界面这个领域的改良。（4）整体的用户界面能否在语法、常例、语义、格式、风格和缩写方面展现出了相当程度的看法完好性、基本的一致性和一致性？（5）在正确性极为重要的环境里，如网上银行系统，输入中能否有足够的冗余信息？举例来说，该系

42、统可能会要求输入账号、用户名和PIN（个人鉴识号）来考证接见账户信息的是合法用户。（6）系统能否包含过多或不太可能用到的选项？现代软件的一个趋向是，仅向用户供应那些鉴于软件测试和设计考虑而确定出的最有可能使用的菜单项选择项。一个设计优秀的软件能够向用户学习，并开始向不一样的用户显现其常常接见的菜单项。即使已经有了这样智能化的菜单系统，仍需要设计成功的软件，使得对不一样选项的接见吻合逻辑、吻合直觉。（7）对于所有的输入，系统能否返回了某些种类的即时确认信息？举例来说，在点击鼠标进行输入的环境里，被选项能够变换颜色，或许某个按钮对象可以显示凹进或突出的状态。假如要让用户从列表中选择，那么当用户作出

43、选择后被选序号应显示在屏幕上。还有，假如被选的操作需要一些运转时间（假如软件正在接见一个远程的系统，状况常会这样），那么应显示一条信息通知用户目前正在做什么。（8）程序能否易于使用？举例来说，假如输入是区分大小字符的，这一点对用户来说能否清楚？其余，假如程序要求阅读一系列的菜单或操作，那么返回到主菜单的方法能否清楚？用户能否能够很简单阅读到上一层或下一层？5、安全性测试因为社会对个人隐私的日趋关注，很多软件都有特其余安全性目标。安全性测试是设计测试用例打破程序安全检查的过程。举例来说，我们能够设计测试用例来闪避操作系统的内存保护系统，损坏数据库管理系统的数据安全系统。设计此种测试用例的方法之一

44、是研究近似系统中已知的安全问题，而后生成测试用例，尽量裸露被测系统存在相像问题。比方，在杂志、聊天室和新闻组中公布的资料，常常包含有操作系统或其余软件系统的已知错误。经过在与被测软件供应相像服务的现有系统中找寻安全漏洞，能够设计测试用例来判断软件能否遇到近似问题的困扰。鉴于web的应用程序常常比绝大部分程序所需的安全测试级别更高。对于电子商务网站特别这样。尽管已经有了足够多的技术（比方密码学）同意客户在因特网上安全地达成交易，但不可以纯真依靠技术的应用来保证安全。除此以外，我们一定向客户群证明软件是安全的，不然就会有失掉客户的风险。6、性能测试很多软件都有特定的性能或效率目标，这些特征描绘为特

45、征描绘为特定负载和配置环境下程序的相应时间和吞吐率。再一次重申，因为系统测试的目的是为了证明程序不可以实现其目标，所以应设计测试用例来说明程序不可以满足其性能目标。7、储存测试近似地，软件有时会有储存目标，举例来说，可能描绘了程序使用的内存和辅存的容量，以及暂时文件或溢出文件的大小，应设计测试用例来证明这些储存目标的到满足。8、配置测试诸如操作系统、数据库管理系统和信息互换系统等软件都支持多种硬件配置，包含不一样种类和数目的I/O设备和通讯线路、或不一样的储存容量。平常可能的配置数目特别之大，以致于测试没法左右逢源，可是最少应当使用每一各样类的设备，以最大和最小的配置来测试程序。假如软件自己的

46、配置可忽视掉某些程序组件，或可运转在不一样的计算机上，那么该软件所有可能的配置都应测试到。此刻的很多软件都设计成运转在多种操作系统下，所以假如测试此类程序，应当在该程序面向的所有操作系统环境中对其进行测试。对设计在Web阅读器里运转的的程序，需要特其余注意，因为Web阅读器的种类众多，其实不是所有阅读器都按相同方式运转。除此以外，即即是同一种Web阅读器，在不一样的操作系统之下，运转方式也会不一样。9、兼容性/配置/变换测试大部分开发的软件都其实不是崭新的，常常时为了代替某些不完美的系统。这样的软件常常有着特定的目标，波及与现有系统的兼容以及从现有系统的变换过程。再次重申，在针对这些目标测试程

47、序时，测试用例的目的是证明兼容性目标未被满足，变换过程并未奏效。在将数据从一个系统转移到另一个系统时，应全力发现错误。升级数据库管理系统就是一个例子。需要确定现有的数据部署到了新的系统中。有很多不一样的方法测试这个过程；但这些方法都高度依靠于所使用的数据库系统。、安装测试有些种类的软件系统安装过程特别复杂。测试安装过程是系统测试中的一个重要部分。对于包含在软件包中的自动安装系统而言，这特别重要。安装程序假如出现故障，会影响用户对软件的成功体验。用户的第一次体验来自于安装软件的过程。假如这个过程进行得很糟糕，用户或顾客就那么找寻其余得产品，要么对软件的有效性不抱太大信心。、靠谱性测试自然，所有种

48、类的测试都是为了提高软件的靠谱性，可是假如软件的目标中包含了对靠谱性的特别描绘，就一定设计专业的靠谱性测试。测试靠谱性目标可能很困难。举例来说，诸如公司广域网（WAN）或因特网服务供应商（ISP）等现代在线系统在整个运转时期，正常运转时间应占99.97%。我们此刻还不太可能花上数月甚至数年的时间来测试这个目标。今日的要点软件系统的靠谱性标准甚至更高，而当今的硬件能够令人钦佩地保障这个目标的实现。但假如软件或系统有更为适中的均匀故障间隔时间（MTBF）目标或合理的（以测试而言）功能错误目标，就有可能对其进行测试。比方，MTBF值不超出20个小时，或许系统目标是程序在投入使用以后裸露的不一样错误的

49、数目不得超出12个，那么就能够进行测试，特别是使用了统计的、程序考证的或鉴于模型的测试方法以后。这些方法都超出了本书的范围，但有些技术文件（网上或其余方面的）对这个领域供应了充分指导。举例来说，假如读者对软件测试的这个领域感兴趣，能够研究概括断言的看法。这种方法的目的是设计出有关被测试软件的一系列定理，作为判断软件中不存在的错误的依照。这种方法第一要对程序的输入条件及其正确的结果编写断言。断言用形式逻辑的符号表示，平常是一阶谓词演算。而后需要确定程序中的每一个循环，对于每一个循环都写一个断言，描绘出在循环中任意点都不变的（总为真）条件。程序此刻已经被区分为固定数目的固定长度的路径（在成对的断言

50、中所有所有路径）。对于每一条路径，取中间程序语句的语义来更正断言，最后抵达路径的终点。此时在路径的终点处存在着两条断言：原来的断言以及从路径的另一个终点处断言引申出的断言。而后写出一条定理，说明原来的断言隐含着引申出的断言，并试图证明这个定理。假如能够证明该定理，就能够以为程序不存在错误只需程序最后能够结束。需要独自的证明来说明程序总会结束。固然此各样类的软件证明或展望听起来特别复杂，但靠谱性测试及软件靠谱性工程（SRE）的看法已经为我们所认识，并且对于那些一定保持特别高的正常运转时间的系统，其重要性日趋增加。为了说明这一点，请查察表6-1中某个系统为支持不一样的正常运转时间的需要而每年一定达

51、到的运转小时数。这些数字能够说明对SRE的需求。、可恢复性测试诸如操作系统、数据库管理系统和远程办理系统等软件平常都有可能恢复性目标，说明系统如何从程序错误、硬件无效和数据错误中恢复过来。系统测试的一个目标是是证明这些恢复过来。系统测试的一个目标是证明这些恢复系统不可以够正确发挥作用。我们能够成心将程序错误置入某个系统中，判断系统能否能够从中恢复。诸如内存校验错误或I/O设备错误等硬件业能够进行模拟，而如通讯中的噪音或数据库中的无效指针等数据错误能够成心生成或模拟出来，以分析系统的反应。这些系统的设计目标之一是使均匀恢复时间（MTTR）最小。系统宕机常常会减少公司的收入。我们的一个测试目标是证

52、明系统不可以满足MTTR的服务合同。MTTR常常有上界和下界，所以测试用例反应出这些界线。、合用性测试软件还可能有合用性或可保护性的目标。所有的此类目标都一定测试到。这些目标可能定义了系统供应的服务协助功能，包含储存转存程序或诊疗程序、调试明显问题的均匀时间、保护过程以及内部业务文档的质量等。、文档测试忧如在图6-4中所描绘的那样，系统测试也需要检查用户文档的正确性。完成此任务的主要方法是依据文档来确定系统测试用例的形式。也就是说，一旦设计达成某个详尽的测试状况，应当使用文档来作为编写实质测试用例的指南。同时，用户文档应看作为审察的对象（近似代码审察的看法），检查其正确性和清晰性。在文档中描绘

53、的任何典范应编成测试用例，并提交给程序。、过程测试最后，很多软件都是较大系统的构成部分，这些系统其实不完好部是自动化的，包含了很多人员操作过程。在系统测试中，一定对所有已规定的人工过程，如系统操作员、数据库管理员或最后用户的操作过程进行测试。举例来说，数据库管理员一定记录备份和恢复数据库系统的操作过程。在可能的状况下，应因为数据库管理不有关的人员测试这些过程。可是，公司一定为充分测试这些过程而供应所需的资源，这些资源平常包含硬件和额外的软件同意证。、系统测试的履行系统测试履行中一个最要点的考虑是决定由谁来进行测试。我们从反面来回答这个问题：（1）不可以由程序员来进行系统测试；（2）在所有的测试

54、阶段之中，这是独一一个明确地不可以由负责该程序开发的机构来履行的测试。第一点鉴于的事实是，履行系统测试的人思虑问题的方式一定与最后用户相同，这意味着一定充分认识最后用户的态度和应用环境，以及程序的使用方式。那么明显的是，假如可行的话，一位或多位最后用户是很好的履行测试的候选人。可是，因为一般的最后用户都不具备履行很多前面所描绘的测试种类的能力或专业技术，所以，理想的系统测试小组应由几位专业的系统测试专家（以履行系统测试作为职业）、一位或两位最后用户的代表、一位人类工程学工程师以及该程序主要的分析人或设计者所构成。将原来的设计者包含进来其实不违反先前的测试原则，即不倡议测试由自己编写的程序，因为

55、程序自构想以来已经历经人手，所以原来的设计者不会再遇到心理约束的影响，对程序的测试不会再涉及该原则。第二点鉴于的事实是，系统测试是一项“为所欲为，百无禁忌”的活动，而软件开发机构会遇到心理约束，有悖于此项活动。并且大部分的开发机构最为关怀的是让系统测试进行得尽可能顺利准时达成，而不会全力证明程序不可以满足其目标。系统测试最少应由极少（假若有的话）受开发机构左右的独立人群来履行。或许最经济的履行系统测试的方式（所谓经济，是指花必定的成本发现最多的错误，或利用更少的花费发现相同数目的错误）是将测试分包给一个独立的公司来达成。查收测试从开发过程的完好模型上来看，能够看到查收测试是将程序与其最先的需求

56、及最后用户目前的需要进行比较的过程。这是一种不平常的测试种类，因为该测试平常由程序的客户或最后用户来进行，一般不以为是软件开发机构的职责。对于软件按合同开发的状况，由订购（用户）来进行查收测试，将程序的实质操作与原始合同进行比较。忧如其余种类的测试相同，查收测试最好的方法是设计测试用例，全力证明程序没有满足合同要求；若是这些测试用例都是不行功的，那么就能够接受该程序。对于软件产品的状况，如计算系统造商的操作系统或编译器，或是软件公司的数据库管理系统，理智的用户第一会进行一次查收测试以判断产品能否满足其要求。安装测试图6-3描绘的测试过程的节余部分是安装测试。安装测试在图6-3中的地点有些不平常

57、它与所有其余测试过程不一样，与设计过程中的任何阶段都没有联系。它的不平常是因为其目的不是为了发现软件中的错误，而是为了发此刻安装中出现的错误。在安装软件系统时期会发生很多事件。作为实例的简洁列表包含了以下事件：1、用户一定选择大批的选项；2、一定分派并加载文件和库；3、一定进行有效的硬件配置；4、软件可能要求网络联通，以便与其余软件连结。安装测试应由生产软件系统的机构来设计，作为软件的一部分来公布，在系统安装达成以后进行。除此以外，测试用例需要检查以确认已选的选项会合互不矛盾，系统的所有零件所有存在，所有的文件已经创立并包含必需内容，硬件配置稳当等。测试的计划与控制假如以为测试一个大型软件系统

58、可能需要编写、履行和考证数万个测试用例、办理数千个模块、更正数千个错误、聘任数百人花销一年甚至更长的时间工作，那么很明显我们在计划、督查和控制测试过程方面遇到了巨大的项目管理挑战。在计划测试过程中最常出现的主要错误是默以为不会发现软件缺点。这个错误带来的明显结果是对计划投入的资源（人力、时间表及计算机时间）明显估计不足，这在计算机行业是个名誉狼藉的问题。造成这个问题的原由是测试阶段处于开发周期的最后阶段，以致调整资源特别困难。其余，可能是更重要的问题，即对软件测试的定义有误，因为很难看到对测试正确定义（测试的目的是发现错误）的人在假定找不就任何错误的状况下去计划一个测试。与大部分项目的状况相同

59、，计划是管理测试过程中至关重要的一环。一个优秀的测试计划应包含：1、目标。一定定义每个阶段的目标。2、结束准则。一定制定准则以规定每个测试阶段何时能够结束。3、进度。每个阶段都须有时间表。应指出何时设计、编写和履行测试用例。某些软件技术，如极限编程要求在程序编码开始从前就设计测试用例和单元测试。4、责任。对于每一个阶段，应当确定谁来设计、编写和考证测试用例，谁来更正发现的软件错误。因为在大型项目中谈论特定的测试结果能否代表错误时，有可能出现争端，所以还需要确定一名仲裁者。5、测试用例库及标准。在大型项目中，用于确定、编写以及储存测试用例的系统方法是一定的。6、工具。一定确定需要使用的测试工具，

60、包含计划由谁来开发或采买、如何使用工具以及何时需要时使用工具。7、计算机时间。计划每个测试阶段所需的计算机时间，包含用来编译应用程序的服务器（假如需要的话），用来进行安装测试所需的桌面计算机，用来运行鉴于Web应用程序的Web服务器、联网的设备（假如需要的话）等等。8、硬件配置。假如需要特其余硬件配置或设备，则需要一份计划来描绘该需求，该如何满足需求以及何时需要满足。9、集成。测试计划的一部分是定义程序如何组装在一同的方法（比方自定向下的增量测试）。一个系统假如包含大的子系统或程序，可按增量的方式组装在一同，比方能够使用自顶向下或自底向上的方法，可是这些结构块是程序或子系统，而不是模块。假如是