软件测试.docx
《软件测试.docx》由会员分享，可在线阅读，更多相关《软件测试.docx（15页珍藏版）》请在冰点文库上搜索。
软件测试
第七章软件测试
7.1软件测试基础
教学内容：
测试观点、原则、组织和工具。
教学重点：
测试观点和原则。
教学难点：
测试观点和原则的理解。
教学方法：
课堂讲授+讨论。
教学要求：
理解软件测试的观点和原则，掌握软件测试工具，了解测试与调试的关系，了解动态测试步骤。
思考题：
1）为何软件测试尽早进行？
2）如何应用Pareto原则进行软件测试？
3）测试是否是证明程序没有错误？
7.1.1测试观点
软件测试应能够系统地揭示不同类型的错误，并耗费最少时间与最小工作量，而且没有发现错误的测试实际是无效的测试。
测试附带的收获是能够证实软件的功能和性能是否与需求说明相符；同时，实施测试后收集到的测试结果数据提供了软件可靠性以及软件整体质量的有关信息。
7.1.2测试原则
在进行测试时，为了能更好地体现上述测试观点，软件测试人员必须贯彻以下有关的测试原则：
（1）测试应“尽早地和不断地进行”。
软件测试不应仅仅是一个独立的软件开发阶段，而应贯穿到软件开发的各个阶段中。
通过各阶段的评审，把错误克服在早期，以减少错误放大效应影响，不仅可以提高软件质量，而且也是降低软件成本的一个重要措施。
（2）较早确定测试计划，严格执行测试计划。
测试计划可以在需求分析完成后就开始进行，详细的测试用例定义可以在各种设计结果确定后开始进行。
测试计划应包括：
测试目的、所测软件的功能、输入和输出、测试内容、各项测试的进度安排、资源要求、测试资料、测试工具、测试用例的选择、测试的控制方式和过程、系统组装方式、跟踪规程、调试规程以及评价标准等。
（3）注意错误的群集现象和应用Pareto原则。
经验表明，测试后程序中残存的错误数目与该程序中已发现的错误数目或检错率成正比。
从而，应当对错误群集的程序段进行更多的测试，以提高测试的效率。
Pareto原则表明80%的错误来源于20%的程序模块。
这进一步表明了错误的群集现象。
（4）测试规模应从小到大。
（5）测试应由独立的第三方进行。
（6）应保证测试用例的完整性和有效性。
完整的测试用例应由输入数据和相应的预期结果组成。
测试是为了发现错误，从而没有发现错误的测试应视为无效的测试。
经验表明，用不合理的输入数据测试程序比用合理的输入数据测试程序能发现更多的错误。
（7）应保存所有测试用例和出错统计等，直至软件不用为止。
7.1.3测试工具
软件测试工具是一种测试软件，开发人员借助它可以提高软件测试工作的效率。
测试工作在软件开发的整个过程中占有极其重要的地位，其工作量通常占软件开发总工作量的40%~60%。
因此，采用软件测试工具是降低测试成本，提高测试质量和效率的重要途径。
软件测试工具按工作方式可分为：
静态分析工具和动态测试工具。
1、静态分析测试软件
2、动态分析测试软件
3、测试数据自动生成程序
4、文件比较程序
7.1.4测试组织
从心理上来讲，软件工程师所进行的软件分析、设计和编码是一个构造软件的过程，是建设性的工作。
和其他任何建设者一样，软件工程师对自己的辛勤劳动是非常骄傲和不容质疑的。
而软件测试却恰恰是对软件进行质疑，是一种专门挑“刺”的活动。
但是，无论是软件工程师还是软件测试人员，其目标均是为了获取高质量的软件。
一般来讲，独立测试之前，软件开发者应负责对程序单个模块测试，以保证每个模块能完成详细设计的功能等。
在很多情况下，软件开发者也进行集成测试，以保证每个模块能按总体设计的要求形成整个软件系统。
在系统形成之后，独立测试小组才开始介入，同时为了保证测试顺利进行，在测试过程中，开发人员必须协助。
独立测试应确保系统满足需求分析的要求和用户意图。
7.1.5测试与调试
测试是查找错误症状的过程，调试则是查找错误症状原因并改正错误的过程。
调试的结果可能是错误原因查明并改正，也可能是未能发现错误原因，还有可能引入新的错误。
实际上，调试之后还应进一步进行测试和评价，以确保错误真正消除且没有引入新的错误。
7.1.6动态测试步骤
大型软件系统通常由若干子系统组成，每个子系统又由许多模块组成。
按照软件工程的观点，动态测试应按4个步骤进行，即单元测试、集成测试、确认测试和系统测试等。
其中单元测试一般在编码阶段完成；集成测试和确认测试均放在测试阶段完成；系统测试是指整个计算机系统（包括软件与硬件）的测试，可与系统的安装和验收结合进行。
7.2代码复审
教学内容：
代码复审内容、代码会审、走查和办公桌检查。
教学重点：
代码会审、走查和办公桌检查。
教学难点：
代码复审内容。
教学方法：
课堂讲授+讨论。
教学要求：
了解代码复审内容，理解代码会审、走查和办公桌检查。
思考题：
1）代码复审除了检查程序错误外，还可以有哪些作用？
2）为何代码复审的效率有时比动态测试的效率高？
3）代码会审、走查和办公桌检查有何不同？
7.2.1代码复审内容
对源程序代码进行的复审主要着重于检查编码实现是否完备、正确等。
在复审过程中，查找程序在结构、功能、编码标准和风格等方面的错误或提出质疑。
内容
条例举例
完备性
代码是否完全、准确地实现了详细设计中规定的内容？
正确性
代码是否符合标准？
一致性
是否自始至终使用了相同的格式、调用约定、结构等？
易理解性
注释是否简洁明了地对每一子程序均作了充分描述？
易修改性
代码是否对常数通过常量标识符进行引用？
可预测性
是否避免了依赖于程序设计语言缺省值的代码？
健壮性
代码是否防止了运行时可发现的错误？
如下标越界等。
结构化
程序的每一功能是否都可作为一块代码能识别出？
易追溯性
是否有修改历史记录？
可验证性
是否避免了使用测试难度大的技术和方法？
7.2.2代码会审
代码会审以小组会的形式进行。
会审小组一般由4人左右组成，包括组长1人，程序作者1人，其他程序员（或测试员）1~2人。
会审小组通过对评审材料阅读、讨论和争议，对程序代码进行检查。
为了确保会审的质量，在会审时应强调以下几个方面：
（1）会审针对的是文档，而不是文档的作者；
（2）会审只是发现错误，改正错误应在会后进行；
（3）会审一般以1～2小时为宜，每小时大约150行代码；
（4）如果系统较大，代码较多，则应分别进行多次会审；
（5）争论的范围应只限于文档内容，应避免对方案问题、风格问题等进行过多争论。
7.2.3走查
又称为“预排”，与代码会审基本相同，也是以小组会的方式进行。
会前，发放有关材料给与会者进行熟悉，并至少指定一人设计测试用例。
会上，与会者扮演计算机角色，人工“执行”被测程序。
通过将测试用例“输入”被测程序，对程序的逻辑和功能提出各种疑问，并进行有关的讨论和争议，以发现程序中存在的问题。
会后的处理同代码会审相同，这里不再多讨论。
由于人工“执行”程序比较缓慢，因而测试用例不要过于复杂。
7.2.4办公桌检查
这是一种传统的检查方法。
程序作者在程序通过编译之后，进行单元测试之前，对源代码进行分析、检验，并补充有关文档，以发现程序中的错误。
其方式可以按照错误检验表来分析被查程序，也可以仿照走查对程序进行人工“执行”。
办公桌检查可以看成是由一个人进行的代码复审。
由于程序作者熟悉自己的程序，可以节省检查时间，但也应避免主观片面性。
综上所述，代码复审是一种非常有效的人工测试，一方面它一次可以发现许多错误；另一方面除逻辑错误外还可以发现编码标准与风格等方面的问题。
但人工测试缓慢，有些类型的错误，如中断，进行动态测试更有效。
因此，人工测试和动态测试是相互补充，相辅相成的。
7.3白盒测试
教学内容：
逻辑覆盖法、基本路径覆盖法、循环覆盖法。
教学重点：
逻辑覆盖法、基本路径覆盖法。
教学难点：
基本路径覆盖法。
教学方法：
课堂讲授+案例。
教学要求：
熟悉逻辑覆盖法和基本路径覆盖法设计测试用例，理解循环覆盖法。
思考题：
1）满足条件组合覆盖是否满足基本路径覆盖？
2）如何描述程序的控制流？
控制流和数据流有何不同？
7.3.1逻辑覆盖法
由于覆盖测试的目标和程度不同，逻辑覆盖又分为：
语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖和条件组合覆盖。
——语句覆盖：
测试用例能使被测程序的每条执行语句至少执行一次。
——判定覆盖：
测试用例能使被测程序中的每个判定至少取得一次“真”和一次“假”。
又称分支覆盖。
——条件覆盖：
测试用例能使被测程序中每个判定的每个条件至少取得一次“真”和一次“假”。
如果判定中只有一个条件，则条件覆盖便满足判定覆盖，否则，不一定。
——判定/条件覆盖：
测试用例既满足判定覆盖，又满足条件覆盖。
——条件组合覆盖：
测试用例使每个判定中所有可能的条件取值组合至少执行一次。
7.3.2基本路径覆盖法
基本路径测试法适用于模块的详细设计结果及源程序代码，其主要步骤如下：
（1）以详细设计结果或源程序代码为基础，导出程序图；
注意应将复合条件判定转化为单一条件判定。
（2）计算程序图的环形复杂度；
可以采用图形矩阵方法计算，也可采用其它方法来计算。
（3）确定基本路径集；
基本路径集的路径数就是环形复杂度大小。
（4）生成测试用例，使基本路径集中的每条路径至少经过一次。
7.3.3循环覆盖法
对于结构化程序而言，循环主要有三种：
简单循环、串接循环和嵌套循环。
对于简单循环，假设n是循环的最大次数，则可以采用如下策略设计测试用例：
1.整个跳过循环，即循环0次；
2.只有一次通过循环，即循环1次；
3.循环2次；
4.循环m次，其中m＜n；
5.分别循环n-1，n和n+1次。
对于嵌套循环，可以采用如下策略来导出测试用例：
1.从最内层循环开始，其他循环设置为最小次数循环；
2.对最大内层循环使用简单循环策略，并为范围外或排除的值增加其他测试；
3.由内向外构造下一个循环的测试，使其外层循环为最小次数，其内部嵌套循环为“典型”次数；
4.继续3，直到所有循环测试完。
对于串接循环，如果串接循环的循环都彼此独立，则可以采用简单循环的测试策略；如果循环不独立，如第二个循环变量的初始值是外层第一个循环变量的当前值，则应使用嵌套循环的测试策略。
7.4黑盒测试
教学内容：
等价分类法、边界值分析法、猜错法、因果图法。
教学重点：
等价分类法、因果图法。
教学难点：
等价分类法。
教学方法：
课堂讲授+案例。
教学要求：
掌握等价分类法和因果图法，理解边界值分析法和猜错法。
思考题：
1）划分等价类时，为何还需要输入数据？
2）考虑输入数据不同条件组合的有哪些设计测试用例的方法？
3）在因果图法中，哪些是原因？
哪些是结果？
7.4.1等价分类法
等价分类法将所有可能的输入数据（有效的或无效的）划分成若干个等价类，然后从每个等价类中选出一个作为“代表”形成测试用例。
其中有一个假定：
等价类中的所有数据对于暴露程序中的错误是等效的。
有时，在确定输入数据的等价类时常要分析输出数据的等价类，以便根据输出数据的等价类导出对应的输入数据等价类。
等价分类法设计测试用例的步骤如下：
①划分等价类，形成等价类表；
②为每个等价类规定一个唯一的编号；
③设计一个新的测试用例，使其尽量多地覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止。
④设计一个新的测试用例。
使其覆盖一个而且只覆盖一个无效等价类，重复这一步，直到所有无效等价类均被覆盖为止。
在第③步中，有效等价类尽量共用相同的测试用例，这样做可以减少测试次数。
在第④步中，对无效等价类要求一类一个测试用例，这是因为某些程序中对某一输入错误往往会屏蔽对其他输入错误的检查。
7.4.2边界值分析法
边界值分析法主要用来选择等价类边界值作为测试用例检查程序边界运行情况，是一种补充等价分类法的测试用例设计技术。
通常，输入等价类和输出等价类的边界情况是测试的重点，应当选择正好等于，刚刚小于和刚刚大于边界的值作为测试数据。
边界值分析法的指南如下：
·如果输入条件代表以a和b为边界的范围，则测试用例应当包含a、b、略小于下界a，略大于上界b的值。
·如果输入条件规定了值的个数，则用最大个数、最小个数、比最大个数多1，比最小个数少1的数作为测试数据。
·上述两条指南对输出条件也适用。
·如果程序的规格说明中给出的输入和输出域是有序集合（如有序表），则应选取集合的第一个元素和最后一个元素作为测试数据。
·如果程序数据结构有预定义的边界（如数组有100项，下标下界是0，上界是99），则应选择测试数据测试其边界的数据项
7.4.3猜错法
猜错法的基本想法是：
列出程序中所有可能有的错误和容易发生错误的特殊情况，然后依据它们选择测试用例。
通常，这种方法仅用作辅助手段，即先用其它方法设计测试用例，再用猜错法补充一些例子。
例如，测试一个排序程序，可先用边界值分析法设计以下的测试用例：
①排序序列为空；②排序序列仅有一个数据；③排序序列为满序列数据。
然后，再用猜错法补充以下测试用例：
④排序序列已经按要求排好序；⑤排序序列的顺序与要求的顺序恰好相反；⑥排序序列中的所有数据全部相等；等等。
7.4.4因果图法
因果图是一种简化了的逻辑图，能直观地表明程序输入条件（原因）和输出动作（结果）之间的相互关系。
在因果图中有两类关系，即：
因果关系和约束关系。
利用因果图导出测试用例的步骤如下：
（1）分析程序规格说明中哪些是原因，哪些是结果。
原因常常是输入条件或输入条件的等价类，结果则是输出条件。
（2）分析程序规格说明中描述内容的语义和限制，找出两类关系，画出因果图。
（3）把因果图转换成判定表。
（4）对判定表的每一列写成一个测试用例。
7.5单元测试
教学内容：
测试策略、测试内容、测试过程、测试软件。
教学重点：
测试内容、测试软件。
教学难点：
测试软件的理解。
教学方法：
课堂讲授+讨论。
教学要求：
理解单元测试策略，掌握单元测试内容，了解单元测试过程，理解测试软件的作用。
思考题：
1）为何要进行单元测试？
单元测试一般由谁完成？
2）桩模块和驱动模块哪个容易编写？
7.5.1测试策略
单元测试一般总是把白盒法和黑盒法结合运用。
先用黑盒法设计出一组基本的测试用例，然后用白盒法，根据覆盖标准要求补充新的测试用例满足覆盖标准。
在一般情况下，单元测试应以白盒法为主。
采用从单元开始而不是对整个程序进行测试，一方面可以减少测试工作的复杂性，另一方面容易进行错误定位和纠错。
同时，对多个模块的测试可以并行地进行，从而缩短测试的周期。
7.5.2测试内容
单元测试在于考察模块的接口和内部结构，检查是否符合程序规格说明（即详细设计说明书）的要求。
测试的重点在以下几个方面：
1、模块的接口
2、局部数据结构
3、重要的执行通路
4、出错处理路径
5、影响以上各项的边界条件
7.5.3测试的阶段及活动
根据GB/T15532-1995国家标准，单元测试由下列阶段及活动组成：
1、完善测试计划阶段
⑴制定方法、资源及进度的计划。
⑵确定需测试的与需求有关的特性。
⑶细化计划。
2、获得测试用例集阶段
⑴设计测试用例集。
⑵执行测试计划及实现设计。
3、评价测试单元阶段
⑴执行测试规程。
⑵核对终止情况。
⑶评价测试效果和被测单元.
7.5.4测试软件
测试软件都应完成：
①提供数据；②提供程序通路；③报告有关结果；等等工作。
驱动模块和桩模块的编写会给测试带来额外的开销，必须开发但一般不把它交给用户。
如果驱动模块和桩模块很简单，则额外开销相对来说是很低的。
但是，许多模块使用“简单”的额外软件是不能进行充分的单元测试的。
因此，完整的测试可能要推迟到集成测试时完成。
当模块的内聚度很高时，单元测试是简单的。
如果每一个模块只完成一个功能，测试用例的数量会降低，而且错误也更容易预测和被发现。
7.6集成测试
教学内容：
测试内容和策略、非渐增式测试、渐增式测试、回归测试。
教学重点：
非渐增式测试、渐增式测试。
教学难点：
非渐增式测试、渐增式测试。
教学方法：
课程讲授+讨论。
教学要求：
理解集成测试的内容和策略，掌握非渐增式测试和渐增式测试，了解回归测试。
思考题：
1）集成测试为何应由独立的测试小组进行？
2）与非渐增式测试相比，渐增式测试有何优势？
3）为何要保存已经测试过的测试用例？
7.6.1测试内容
集成测试的内容主要在以下几方面：
·接口完整性。
在每一个模块集成到整个结构中去的时候，要对其内部和外部接口进行测试。
·功能有效性。
进行以发现功能性错误为目的的测试。
·数据一致性。
进行以发现和局部或全局数据结构相关的错误为目的的测试。
·性能。
测试在边界和在人为条件下软件的性能。
7.6.2测试策略
集成测试一般应由独立的测试小组进行，由测试小组提出测试用例，记录测试结果，并编制测试报告。
测试用例的设计通常采用黑盒法，其实施策略又分为非渐增式和渐增式两种。
前者一次将所有模块集成在一起，对整个程序进行测试。
后者则从一个模块或功能簇开始，一次添加一个新模块或功能簇，每添加一次就测试一次，直到所有模块组装完毕。
在实际测试中，可以混合使用这两种策略。
当模块可以用简单的测试软件充分测试时，则可以先测试好这些模块，组装时只着重测试接口，从而可采用非渐增方式；若没能充分测试时，则应采用渐增方式，利用已测模块进行充分测试。
7.6.3非渐增式测试
采用非渐增式测试，一般应先经过单元测试，然后再把所有模块一次性组装在一起进行测试，最终得到要求的软件系统。
实际上，在单元测试期间，由于程序中不可避免地存在涉及模块间接口和全局数据结构等方面的问题，测试实际上是不充分的。
因此，将模块一次性组装在一起运行成功的可能性并不大。
其结果往往是发现有错误，但由于程序中模块一次性引入过多，难于进行错误定位。
同时，一旦修正错误之后，新的错误很可能马上会出现。
这样将会导致恶性循环。
因此，除了规模很小的程序，一般很少采用此种测试策略。
7.6.4渐增式测试
渐增式测试采用逐步加入模块或功能簇的方式进行，在加入过程中边连接边测试，比较容易定位和修正错误，且接口也可以更容易进行彻底地测试。
按照添加模块的方式，又可分为自顶向下的渐增测试和自底向上的渐增测试。
1．自顶向下的渐增式测试
自顶向下的渐增式测试，首先集成主控模块，然后按照软件结构的控制层次自上而下进行集成，把主控模块的直接（或间接）调用模块按深度优先或广度优先的方式集成到整个软件结构中。
2．自底向上的渐增式测试
自底向上的渐增式测试是从软件结构的最底层的模块开始组装和测试，其步骤如下：
（1）把低层模块组合成实现某个特定的子功能的模块簇，并用编写的驱动模块控制它进行测试；可以对若干功能簇并行进行测试；
（2）用实际模块换掉驱动模块，沿软件结构自下而上移动，把子功能簇组合起来形成更大的子功能簇，并进行测试；
（3）重复
（2）直到所有模块组装完毕。
3．混合的渐增式测试
自顶向下的渐增式测试和自底向上的渐增式测试各有自己的特点，并且是互补的。
7.6.5回归测试
回归测试就是用来保证软件的变动不会带来新的错误的活动。
为此，回归测试便采用软件改动前测试时执行过的测试用例对改动后的软件再进行测试。
回归测试的测试用例有三种不同类型：
（1）能够测试软件的所有功能的代表性测试用例；
（2）针对可能会被修改所影响的软件功能而进行附加测试的测试用例；
（3）针对修改过的软件成分进行测试的测试用例。
在进行回归测试时，也应该集中测试关键模块。
7.7确认测试
教学内容：
确认测试内容、α测试和β测试。
教学重点：
α测试和β测试。
教学难点：
α测试和β测试。
教学方法：
课程讲授+讨论。
教学要求：
了解确认测试内容，理解α测试和β测试。
思考题：
1）为何要在α测试比较稳定后才能进行β测试？
2）确认测试能否确定软件符合用户要求？
?
?
7.7.1确认测试内容
一般地说，确认测试应包括以下几方面的内容：
1、功能测试
2、性能测试
3、强度测试
4、配置复审
确认测试是由软件开发单位组织进行的最后一次测试，也是把软件交给用户，进行正式的安装和验收之前所作的一次重要的准备。
为了确保测试质量，一方面应组织独立的测试小组进行测试，另一方面吸收任务委托单位及用户代表参加测试，以提高测试的可信度。
同时，应将测试中发现的错误填入问题清单，交开发者处理。
7.7.2α测试和β测试
α测试是由一个用户在开发环境下进行的测试；也可以是开发机构内部的用户在模拟实际操作环境下进行的测试，软件在一个自然设置状态下使用。
软件在开发者对用户的“指导”下进行测试，开发者负责记录错误和使用中出现的问题。
显然，α测试是在一个受控的环境中进行。
α测试的目的是评价软件产品的功能（F）、局域化（L）、可使用性（U）、可靠性（R）、性能（P）和支持（S）等方面的特性，尤其注重产品的界面和特色。
β测试是由软件的最终用户（多个）在一个或多个用户场所来进行。
这些用户是与软件厂商签定了支持产品预发行合同的外部客户，要求用户使用该产品，并愿意返回有关问题给开发者。
一般地，β测试时开发者通常不在测试现场，软件是在开发者不能控制的现场中应用。
只有当α测试达到一定的可靠程度时，才能开始β测试。
β测试的主要目标是测试可支持性，包括文档、客户培训等。
一般β测试应尽可能由主持产品发行的人员来管理。
确认测试结束后，开发单位就可以把软件交付委托单位或用户，进行系统测试。
7.8系统测试
教学内容：
恢复测试、安全测试、可用性测试、安装测试、互联测试。
教学重点：
可用性测试、安装测试。
教学难点：
安全测试。
教学方法：
课堂讲授+讨论。
教学要求：
了解恢复测试、安全测试和互联测试，理解可用性测试和安装测试。
思考题：
1）系统测试中，哪一类测试对产品软件最重要？
2）系统测试应该采用哪种方法设计测试用例？
7.8.1恢复测试
许多基于计算机的系统必须要在一定的时间里从错误中恢复过来，然后继续运行。
在有些情况下，运行过程中的错误必须不能使得整个系统的功能都停止，等等。
恢复测试就是要通过各种手段，让软件强制性地发生故障，然后验证恢复是否能正常进行的一种系统测试方法。
7.8.2安全性测试
任何管理敏感信息或者能够对个人造成不正当伤害的计算机系统都是非法侵入的目标。
安全测试用来验证集成在系统内的保护机制是否能够在实际中保护系统不受到非法侵入。
为此，要采用破坏系统安全性的方法和工具，设计测试用例对系统进行测试。
7.8.3可用性测试
可用性测试主要从使用的方便性、易理解性和易学性等方面对系统进行检查，以发现人为因素或使用习惯等的问题。
例如，用户界面便于使用；出错信息能帮助用户解决问题；销往国外的产品有译本；输入可容错；输出信息有意义并且前后一致等等。
衡量可用性有一定的主观因素。
可用性是软件质量的一个很重要的方面，随着软件应用的深化，系统可用性将越来越起重要的作用。
7.8.4安装测试
安装测试是要找出系统安装过程中出现的问
升级会员 