【文档说明】软件工程及实践窦万峰软件测试课件.pptx，共(62)页，716.479 KB，由小橙橙上传

转载请保留链接：https://www.ichengzhen.cn/view-45021.html

以下为本文档部分文字说明：

软件工程及实践窦万峰软件测试课件验证（Verification）是指已经实现的软件产品是按照其需求做的，是符合需求说明书的。验证测试是指测试人员在模拟用户环境的测试环境下对软件进行测试，验证已经实现的软件产品或产品组件是否实现了需求中所描述的

所有需求项。确认（Validation）是指已经实现的软件产品或产品组件在用户环境下实现了用户的需要。确认测试是指测试人员在真实的用户环境下，软件产品或产品组件不仅实现了需求中所描述的所有需求项，而且也满足用户的最终需

要。在软件测试中应注意以下几个原则。1．Parito法则2．木桶理论3．测试不能证明软件无错4．完全测试软件是不可能的5．软件测试是有风险的行为6．测试无法显示潜伏的软件缺陷7．程序中存在错误的概率与该

程序中已发现的错误数成比例8．软件缺陷的免疫力9．并非所有软件缺陷都能修复图7-1软件项目的最合适的测试工作量7.2.1单元测试模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下，其他测试才有意义。测试接口正确与否应该考虑下列因素。（1）输入的实际参数与形式参数的个数是

否相同。（2）输入的实际参数与形式参数的属性是否匹配。（3）输入的实际参数与形式参数的量纲是否一致。（4）调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同。（5）调用其他模块时所给实际参数

的属性是否与被调模块的形参属性匹配。（6）调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致。（7）调用预定义函数时所用参数的个数、属性和次序是否正确。（8）是否存在与当前入口点无关的参数引用。（9）是否

修改了只读型参数。（10）对全程变量的定义各模块是否一致。（11）是否把某些约束作为参数传递。如果模块内包括外部输入输出，还应该考虑下列因素。（1）文件属性是否正确。（2）OPEN/CLOSE语句是否正确。（3）格式说明与输入/输出语句是否匹配。

（4）缓冲区大小与记录长度是否匹配。（5）文件使用前是否已经打开。（6）是否处理了文件尾。（7）是否处理了输入/输出错误。（8）输出信息中是否有文字性错误。检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完

整和正确。局部数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误。（1）不合适或不相容的类型说明。（2）变量无初值。（3）变量初始化或默认值有错。（4）不正确的变量名（拼错或不正确地截断）。（5）出现上溢、下溢和地址异常。比较判断与控制流常常紧密相关，测试用例还应致力于

发现下列几类错误。（1）在不同数据类型的对象之间进行比较。（2）错误地使用逻辑运算符或优先级。（3）因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等。（4）比较运算或变量出错。（5）循环终止条件不可能出现。（6）迭代发散时不能退出。（7）错误地修

改了循环变量。一个好的设计应能预见各种出错条件并预设各种出错处理通路，出错处理通路同样需要认真测试，测试应着重检查下列几个问题。（1）输出的出错信息难以理解。（2）记录的错误与实际遇到的错误不相符。（3）在程序自定义的出错处理段运行之前，系统已介入。（4）

异常处理不当。（5）错误陈述中未能提供足够的定位出错信息。通常模块通过了单元测试，组装成完整的程序系统还会出现问题，还要测试，原因如下。（1）程序的各模块之间可能有比较复杂的接口，单个模块的接口测试很容易产生疏漏，而且不易被发现。

（2）单元测试中往往使用了测试软件，即“驱动”模块或“桩”模块。（3）单个模块中可能允许有误差，但是模块组装后的积累误差可能达到了不能容忍的地步。模块集成方式一般都采用渐增式，有自顶向下、自底向上和混合式3种，因此集成测

试策略也有相应的自顶向下测试、自底向上测试和混合式测试3种。这3种测试策略主要的优缺点如下。（1）自顶向下测试的优点是能较早展示整个程序的概貌，取得用户的理解和支持；主要缺点是测试上层模块时要使用桩模块，很难模拟出真实模块的全部功能。（2）自底向上测试从下层模

块开始，设计测试用例比较容易，但是在测试的早期不能显示出整个程序的概貌。（3）混合式测试的优点综合了以上两种测试策略的长处，一般的策略是对关键模块采取自底向上测试，这样可能把输入/输出模块提前组装进程序，使设计测试用例变得较为容易。经过集成测试，软件已经

按照设计把所有模块组装成一个完整系统，接口错误也基本排除。然后应该验证软件的有效性，这就是软件确认测试的任务。确认测试在集成测试之后进行，其目的是确认已组装的程序是否满足软件需求规格说明书的要求。典型的确认测试包括有效性

测试（主要采用黑盒测试方法）和配置复审（主要采用人工评审方法）等。1．功能测试功能测试也称为“需求测试”，主要测试系统的功能性需求。找出功能性需求和系统之间的差异，即检查软件系统是否完成了需求规格中所指定的功能。功能测试主要使

用黑盒测试技术。2．性能测试性能测试主要测试系统的非功能性需求，找出非功能性需求和系统之间的差异。即检查软件系统是否完成了需求规格中所指定的非功能性要求，如安全性、计算精度、运行速度，以及安全性等。性能测试期间要进行如下测试活动。（1）强

度测试。（2）安全性测试。（3）恢复测试。（4）软件配置审查。（5）兼容性测试。通过功能测试和性能测试后有下述两种可能的结果。（1）功能和性能与用户要求一致，软件可以接受。（2）功能和性能与用户要求有差距。测试用例计划的目

的如下。（1）尽可能地找出软件错误，测试的目的就是为了查找错误，寻找测试用例的设计灵感，应沿着“程序可能会怎样失效”这条思路回溯。（2）杜绝冗余，“如果两个测试都是查找同一个错误，为什么两个都要执行呢？”而用例计划的编写可以很好地避免这一问题的出现。（3）在对某一个模块测试的时候

，总会有某个方法的测试效率高于其他的方法。（4）使得程序失效显而易见，“如何知道程序究竟有没有通过测试？”这是测试人员要考虑的大问题。可根据以下几个原则编写测试用例。（1）分离界面和实现，要真正精通MV

C，还要多读多练多思考。（2）契约式设计是一种非常好的思想，在C/C++中直接实现契约式设计有些困难，不过这些思想为自动测试大开方便之门。（3）注意模块的粒度。有的人确实把界面和内部逻辑分开了，但是内部逻辑过于复杂。（4）减少模块之间的耦合。（5）

控制随机因素。（6）支持测试提供额外的函数。7.4.1等价类划分在考虑等价类时，应该注意区别以下两种不同的情况。（1）有效等价类，指的是对程序的规范是有意义且合理的输入数据所构成的集合。（2）无效等价类，指对程序的规范是不合理或无意义的输入数据所构成的集合，对于具体的问题，无效等价类至少应有

一个，也可能有多个。确定等价类有以下几条原则。（1）如果输入条件规定了取值范围或值的个数，则可确定一个有效等价类和两个无效等价类。（2）输入条件规定了输入值的集合或是“必须如何”的条件，则可确定一个有效等价类和一个无效等价类。（3）如果确知已划分的等价类中各元素在程序中

的处理方式是不同的，则应将此等价类进一步划分成更小等价类。根据已列出的等价类表，按以下步骤确定测试用例。（1）为每个等价类规定一个唯一的编号。（2）设计一个测试用例使其尽可能多地覆盖尚未覆盖的有效等价类，重复这一步，最后使得所有有效等价类均被测试用例所覆盖。（3）设计一个新的测试用例，使其只覆盖一

个无效等价类。重复这一步，使所有无效等价类均被覆盖。【案例7.1】ATM系统等价类划分测试ATM接受用户界面数据的应用软件，ATM软件功能可简述为用户可以在ATM上拨号到银行，提供6位数（字母或数字）

的密码，并遵循一系列键盘命令（查询、存款和取款等）操作顺序，触发相应的银行业务功能。用户拨号的数据格式为区号（空或3位数字）+前缀（非0和1开始的3位数字）+后缀（4位数字）。用户界面应用程序对用户各种数据元素相关的输入条件做如下

一些定义。（1）区号：输入条件，布尔——是否存在区号。输入条件，范围——数值在200～999（少数例外）。（2）前缀：输入条件，范围——大于200且不含0的数值。（3）后缀：输入条件，值——4位数字。（4）密码：输入条件，布尔——是否存在密码。输

入条件，值——6位字母或数字的字符串。（5）命令：输入条件，集合——包含查询、存款和取款等命令。用边值分析法设计测试用例时有以下几条原则。（1）如果输入条件规定了取值范围或值的个数，则应以该范围的边界内

及刚刚超出范围的边界外的值，或分别将最大、最小及稍小于最小，以及稍大于最大个数作为测试用例。（2）如果程序规范中提到的输入或输出域是个有序的集合（如顺序文件和表格等），就应注意选取有序集的第1个和最后一个元素作为测试用例。（3）分析规范，尽可能找出可能的

边界条件。【案例7.2】三角形无效类测试用例设计某程序读入a、b、c为代表三角形3条边的整数值，根据a、b、c值判断组成三角形的情况。请列出a、b、c变量所有输入不合理的等价类，使用边界值分析方案设计测试用例。三角形包括如下几个无效类。（1）非三角形：不能构成三角形，如两边长度之和小于第3边

长度。（2）退化情况：退化成一条直线（3）零数据：一条、两条或三条边长度为零。（4）负数据：3条边长度中出现负值。（5）遗漏数据：出现数据丢实的情况。（6）无效数据：非法数据。相应的测试用例数据如下所示。不合理的等价类测试数据（a，b，c）非

三角形（10，10，21）（10，21，10）（21，10，10）退化情况（10，5，5）（5，10，5）（5，5，10）零数据（0，0，0）（0，11，0）（0，10，12）负数据（-5，6，7）（-5，-5，10）（-10，-10，-10）遗漏数据（—，—

，—）（10，—，—）（10，10，—）无效数据（A，B，C）（+，=，*）（10.6，A，7e3）使用等价分类和边界值分析测试技术可以帮助测试人员设计具有一定代表性并容易发现错误的测试方案，但是不同类型和不同特点的软件通常又有各自特殊的容易出错的情况；此外，等价分

类和边界值分析都只孤立地考虑各个输入条件的测试功效，没有考虑多个输入条件的组合效应，这可能会遗漏了容易出错的组合情况。而对于输入条件有很多种组合的情况，往往由于组合数目巨大，测试更是难以进行。因此依靠测试者的直觉和经验

推测可能存在的错误类型，从各种可能的测试方案中选择最可能发现错误的测试方案，这就是错误推测法。因果图法就是从程序规格说明书的描述中找出因（输入条件）和果（输出或程序状态的改变），通过因果图转换为判定表最后为判定表

中的每一列设计一个测试用例。图7-2所示为因果图的基本符号。图7-3所示为因果图的约束符号。使用因果图法的步骤如下。（1）根据程序规格说明书描述的语义内容，分析并确定“因”和“果”，将其表示成为连接各个原因与各个结果的“因果图”。（2）将得到的因果图转换成为判定表。（3）为判定表中每一列所表示的情

况设计一个测试用例。【案例7.3】自动售货机因果图法（1）分析这一段说明列出原因和结果。原因：①售货机有零钱找。②投入1元硬币。③投入5角硬币。④按下“橙汁”按钮。⑤按下“啤酒”按钮。建立中间节点，表示处理中间状态。投入1元硬币且按下饮料按钮。按下“橙汁”或“啤酒”按钮。应当

找5角零钱并且售货机有零钱找。钱已付清。结果：售货机“零钱找完”灯亮。退还1元硬币。退还5角硬币。送出橙汁饮料。送出啤酒饮料。（2）画出因果图，所有原因节点列在左边，所有结果节点列在右边，如图7-4所示。（

3）由于②与③，以及④与⑤不能同时发生，所以分别加上约束条件E。（4）转换成判定表，如图7-5所示。7.5.1逻辑覆盖1．语句覆盖【案例7.4】逻辑覆盖测试用例设计ProcedureExample(Va

rA,B,C:real)beginif(A>1)and(B=0)thenx:=x/A；if(A=2)or(x>1)thenx:=x+lend;其程序流程图如图7-6所示。2．判定覆盖对上例，如果设计两个测试用例，就可以达到“判定覆盖

”的标准。为此，可以选择输入数据如下。（1）A=3，B=0，x=l（沿路径acd执行）。（2）A=2，B=1，x=3（沿路径abe执行）。3．条件覆盖条件覆盖的含义是：执行足够的测试用例，使得判定中每个条件获得各种可能的结果。对于案例，只需设计以下两个测试用例即可满足这标准。（1）A=2，B=

0，x=4（沿路径ace执行）。（2）A=1，B=l，x=l（沿路径abd执行）。4．判定/条件覆盖对于上例，选取如下测试用例。（1）A=2，B=0，x=4（沿路径ace执行）。（2）A=1，B=l，x=l（沿路径a

bd执行）。5．条件组合覆盖再看案例7.4，必须使测试用例覆盖8种组合结果如下。（1）A>1，B=0。（5）A=2，x>1。（2）A>1，B<>0。（6）A=2，x<1。（3）A<l，B=0。（7）A<>2，x>1。（4）A<1，B<>0。（8）A<>2，x<1。

要测试8个组合结果并不意味着需要8种测试用例，事实上能够用如下4种测试用例覆盖它们。（1）A=2，B=0，x=4。（2）A=2，B=1，x=l。（3）A=l，B=0，x=2。（4）A=1，B=1，x=l。1．程序控制流图描述任何过程设计描述方法（如PDL、流程图、N-S图和PAD图等）

都可以映射到一个相应的程序控制流图描述，其映射要点如下。（1）一个或多个顺序语句可映射为程序图的一个节点，用带标志的圆表示。（2）一个处理框序列和一个判别框可映射为程序图的一个节点。（3）程序控制流向可映射为程序控制流图的边（或称为“连接”），用方向箭头表示（类似于流程图中的方向箭

头）。一条边必须终止于一个节点，即使该节点不代表任何语句。（4）有边和节点限定的范围称为“区域”（区域应包括图外部的范围）。如图7-7所示，在将程序流程图简化成为控制流图时应注意在选择结构或多分支结构中，分支的汇聚处应有一个汇聚节点。边和节点圈定的区域即

区域，当对区域计数时，图形外的区域也应记为一个区域。2．确定程序图的环形复杂性例如，图7-8（a）给出了一个抽象的流程图示例，其对应的程序图描述如图7-8（b）所示。此例的节点以数字标志区分，边是用类似于流程图的方向箭头标志（最

好能加以字母区分），区域用R1，R2，R3，R4标志。【案例7.5】学生成绩计算路径测试用例设计如图7-9所示的程序流程图描述了最多输入50个值（以-1作为输入结束标志），计算其中有效的学生分数的个数、总分数和平均值。导出程序的控制流图，如图7-10所示。确定基本路径集

合（即独立路径集合）可确定如下6条独立的路径。（1）路径1：1—2—9—10—12。（2）路径2：1—2—9—11—12。（3）路径3：1—2—3—9—10—12。（4）路径4：1—2—3—4—5—8—

2…。（5）路径5：1—2—3—4—5—6—8—2…。（6）路径6：1—2—3—4—5—6—7—8—2…。为每一条独立路径各设计一组测试用例，以便强迫程序沿着该路径至少执行一次。（1）路径1(1—2—9—10—12

)的测试用例如下。score[k]=有效分数值，当k<i；score[i]=–1,2≤i≤50。期望结果为根据输入的有效分数算出正确的分数个数n1、总分sum和平均分average。（2）路径2(1—2—9—11—12)的测试用例如下。sc

ore[1]=-1。期望的结果为average=-1，其他量保持初值。（3）路径3(1—2—3—9—10—12)的测试用例如下。输入多于50个有效分数，即试图处理51个分数，要求前51个为有效分数。期望结果为n1=50，且算出正

确的总分和平均分。（4）路径4(1—2—3—4—5—8—2…)的测试用例如下。score[i]=有效分数，当i<50；score[k]<0，k<i。期望结果为根据输入的有效分数算出正确的分数个数n1、总分sum和平均分average。（5）路径5(1—2—3—4

—5—6—8—2…)的测试用例如下：score[i]=有效分数，当i<50。score[k]>100，k<i；期望结果为根据输入的有效分数算出正确的分数个数n1、总分sum和平均分average。（6）路径6(1—2—3—4

—5—6—7—8—2…)的测试用例如下：score[i]=有效分数，当i<50。期望结果为根据输入的有效分数算出正确的分数个数n1、总分sum和平均分average。1．简单循环测试对于简单循环，测试应包括以下几种，其中的n表示循环允许的最大次数。（1）零次循环

：从循环入口直接跳到循环出口。（2）一次循环：查找循环初始值方面的错误。（3）二次循环：检查在多次循环时才能暴露的错误。（4）m次循环：此时的m<n，也是检查在多次循环时才能暴露的错误。（5）n（最大）次数循环，n+1（比最大次数多

一）次的循环，n-1（比最大次数少一）次的循环。2．嵌套循环测试（1）从最内层循环开始，设置所有其他层的循环为最小值。（2）对最内层循环做简单循环的全部测试，测试时保持所有外层循环的循环变量为最小值；另外，对越界值和非法值做类似的测试。（3）逐步外推，对其外面一层循环进行测

试。测试时保持所有外层循环的循环变量取最小值，所有其他嵌套内层循环的循环变量取“典型”值。（4）反复进行，直到所有各层循环测试完毕。（5）对全部各层循环同时取最小循环次数，或者同时取最大循环次数。对于后一种

测试，由于测试量太大，所以需人为指定最大循环次数。7.6.1集成策略1．自顶向下集成测试策略以图7-11为例，若选择了最左一条路径，首先将模块M1、M2、M5和M8集成在一起。然后将M6集成起来，考虑中

间和右边的路径。广度优先策略则不然，它沿控制层次结构水平地向下移动。2．自底向上集成测试策略（1）对被测模块进行分层，在同一层次上的测试可以并行进行。然后排出测试活动的先后关系，制订测试进度计划。（2）按

时间线序关系将软件单元集成为模块，并测试在集成过程中出现的问题，这里可能需要测试人员开发一些驱动模块用于驱动集成活动中形成的被测模块。（3）将各软件模块集成为子系统，检测各自子系统是否能正常工作，同样可能需要测试人员开发少量的驱动模块用于驱动被测子系统。（4）将各子系统集成为最终用户

系统，测试是否存在各分系统，以及各分系统能否在最终用户系统中正常工作。3．核心系统先行集成测试（1）对核心系统中的每个模块进行单独且充分的测试，必要时使用驱动模块和桩模块。（2）对于核心系统中的所有模块一次性集合到被测系统中，解决集成中出现的各类问题。（3）按照各外围软件部件的重要程度及

模块间的相互制约关系，拟订外围软件部件集成到核心系统中的顺序方案。（4）在外围软件部件添加到核心系统以前，外围软件部件应先完成内部的模块级集成测试。（5）按顺序不断加入外围软件部件，排除外围软件部件集成中出现的问题，形成最终的用户系统。1

．应用在客户端性能的测试【案例7.6】多媒体数据库性能测试多媒体数据库性能测试的目的是模拟多用户并发访问某新闻单位多媒体数据库，执行关键检索业务而分析系统性能。性能测试的重点是针对系统并发压力负载较大的主要检

索业务，进行并发测试和疲劳测试，系统采用B/S运行模式。并发测试设计特定时间段内分别在中文库、英文库、图片库中进行单检索词、多检索词，以及变检索式和混合检索业务等并发测试案例；疲劳测试案例是在中文库中并发用户数为200

时，进行测试周期约8小时的单检索词检索。在进行并发和疲劳测试的同时，监测的测试指标包括交易处理性能及UNIX（Linux）、Oracle和Apache资源等。2．应用在网络上性能的测试应用在网络上性能的测试重点是利用成熟先进的自动化技术进行网络应用性能监控、网络应用

性能分析和网络预测。网络应用性能分析的目的是准确展示网络带宽、延迟、负载和TCP端口的变化是如何影响用户的响应时间的。利用网络应用性能分析工具，如ApplicationExpert能够发现应用的瓶颈，从而可知应用程序在网络上运行时在每个阶段发生的应用行为，

即在应用线程级分析应用的问题。3．应用在服务器上性能的测试（1）评估系统的能力：测试中得到的负荷和响应时间的数据可以被用于验证所计划的模型的能力，并帮助做出决策。（2）识别体系中的弱点：受控的负荷可以被增加到一个极端的水平，并突破它，从而修复体系的瓶颈或薄弱

的地方。（3）系统调优：重复运行测试，验证调整系统的活动得到了预期的结果，从而改进性能。（4）检测软件中的问题：长时间的测试执行可导致程序发生由于内存泄露引起的失败，揭示程序中隐含的问题或冲突。（5）验证稳定性和可靠性：在

一个生产负荷下执行一定时间的测试，是评估系统稳定性和可靠性是否满足要求的唯一方法。4．基本事件流【案例7.7】ATM测试（1）事件流。事件流1：用户向ATM中插入银行卡，执行验证银行卡用例如图7-12所示。如果银

行卡是合法的，ATM界面提示用户输入取款密码，（如表7-1所示）。参数1银行密码参数类型字符串参数范围字符串为0～9之间的阿拉伯数字组合，密码长度为6位备注事件流2：用户输入该银行卡的密码，ATM提款机与MainFrame传递密码，检验密码的正确性。执行验证用户密码用例场景如图7-13所示。事

件流3：系统进入系统业务选择界面，等待用户选择业务功能。假如用户选择“取款”业务，则系统进入取款功能。注意图7-14中的“”标志互斥关系，代表用户每次只能进入一个业务功能。表7-2所示为业务功能选择测试。参数1单击参数类型参数范围用户可以选择“取款”、“

存款”、“转账”、“查询余额”、“修改密码”和“退卡”项备注事件流4：系统执行取款用例场景如图7-15所示。系统提示用户输入取钱金额，提示信息为“请输入您的提款额度”。用户输入取钱金额，系统校验金额正确，提示用户确认，提示信息为：“您输入的金额是

×××，请确认，谢谢！”。用户按下确认键，确认需要提取的金额，如表7-3所示。参数1取款金额参数类型整数参数范围50～1500元，单笔取款额最高为1500元，每24小时之内取款的最高限额是4500元备注事件流5：系统同步银行主机，点钞票，输出给用户并且减去数据库中该

用户账户中的存款金额。事件流6：用户提款，用户取走现金，ATM恢复到业务选择界面。事件流7：用户选择“退卡”，银行卡自动退出。系统执行退卡用例如图7-16所示。用户取走银行卡。（2）分析。（3）测试用例设计。下面分析测试数据，采用等

价类划分和边界值法。等价类划分如表7-4所示。输入条件有效等价类无效等价类银行卡银行卡非银行卡密码字符串为0～9之间的阿拉伯数字组合，密码长度为6位长度不是6位的0～9之间的组合金额以50为单位，50～1500元。单笔取款额最高为1500元；每24小时之内取款的最高限

额是4500元非50的倍数，或大于1500或24小时内取款超过4500确认TRUE取现金TRUE、FALSE取银行卡TRUE、FALSE边界值分析如表7-5所示。输入内点上点离点密码000001、999998000000、99999900000、10000

00金额100、135050、15000、1550测试用例如表7-6～表7-15所示。补充测试用例用于覆盖左右的路径，如表7-16～表7-18所示。7.7.1调试过程调试过程细分为两个步骤完成，首先根据测试结果表明错误

存在的迹象（称为“错误”）进行分析以验证或确定引起错误的准确位置——定位错误。然后仔细研究以便确定出错的原因（称为“故障”），并设法改正错误——修复错误。1．试探法2．回溯法3．对分查找法4．归纳法（1）收集有关数据。（2）组织数据。（3）导出假设。（4）验证假设。5．演绎法（1）列举可能的

原因。（2）排除不正确的原因。（3）细化假设。（4）验证假设。