12确认测试白盒测试

1、本堂课讲授重点 n确认测试 n白盒测试技术 确认测试 n 确认测试的概念 n 确认测试的范围 n 软件配置复查 nAlpha和Beta测试 确认测试的概念 n确认测试的目标是验证软件的有效性 n验证：“保证软件正确地实现了某个特定要求 的一系列活动” n确认：“为了保证软件确实满足了用户需求 而进行的一系列活动” n软件的有效性软件的有效性：如果软件的功能和性能如同用 户所合理期待的那样，软件就是有效的 n需求分析阶段产生的软件需求规格说明书是进 行确认测试的基础 确认测试的范围 n必须有用户积极参与，以用户为主进行。用户 应该参与设计测试方案，使用用户界面输入测 试数据并且分析评价测试的输出

2、结果 n通常使用黑盒测试法 n保证软件: n能满足所有功能要求 n能达到每个性能要求 n文档资料准确完整 n能满足其他预定的要求（如安全性、可移植性、兼 容性、可维护性等） 软件配置复查 n保证软件配置所有成分齐全,包括: n可行性研究报告 n需求分析规格说明书 n总体设计说明书 n详细设计说明书 n源代码清单 n测试计划、测试方案、测试结果 同时，质量符合要求，文档与程序完全一致，具有完 成软件维护所必须的细节，已经编好目录。还有用 户手册的完整性合正确性。 Alpha和Beta测试 n大型通用软件，在正式发布前，通常需要执行 Alpha和Beta测试， Alpha测试是内测， Beta 测

3、试是公测。 nAlpha测试Alpha测试是由一个用户在开发环境 下进行的测试，也可以是公司内部的用户在模 拟实际操作环境下进行的受控测试，Alpha测 试不能由程序员或测试员完成。Alpha测试发 现的错误，可以在测试现场立刻反馈给开发人 员，由开发人员及时分析和处理。目的是评价 软件产品的功能、可使用性、可靠性、性能和 支持。尤其注重产品的界面和特色。 nBeta测试由软件的最终用户在一个或多个客户 场所进行，开发者通常不在Beta测试现场。 Beta测试是软件在开发者不能控制的环境中的 “真实”应用，用户记录在Beta测试过程中遇 到错误，并且定期把这些问题报告给开发者。 开发者对软件产

4、品进行必要的修改和升级，最 后将软件产品交付给全体用户使用。Beta测试 着重于产品的支持性，包括文档、客户培训和 支持产品的生产能力。只有当Alpha测试达到 一定的可靠程度后，才能开始Beta测试。 Alpha测试举例 n2004年3月，微软Bill Gates证实，微软年 内将拿出官方Alpha测试版的Longhorn操 作系统，微软Bill Gates也同时证实， Longhorn要到2006年才能正式上市销售。 微软这款下一代桌面操作系统将内建 DirectX 10，并且采用3D操作界面，采用 WinFS文件系统，采用新一代安全机制。 白盒测试技术 n问题提出 n概念 n白盒测试技术

5、主要包括： n逻辑覆盖 n控制结构测试 白盒测试概念 n白盒测试也称结构测试或逻辑驱动测试，它是 知道产品内部工作过程，可通过测试来检测产 品内部动作是否按照规格说明书的规定正常进 行，按照程序内部的结构测试程序，检验程序 中的每条通路(虽然这是不可能的)是否都有能 按预定要求正确工作，而不顾它的功能。 n测试方案：包括具体的测试目的，应该输 入的测试数据和预期的结果 n测试用例：测试数据和预期的输出结果 测试数据 n不同的测试数据发现程序错误的能力差 别很大 n不可能进行穷尽的测试 n应该选用高效的测试数据，提高测试效 率降低测试成本。设计测试数据的技术 包含白盒测试时设计测试数据的技术和

6、黑盒测试时设计测试数据的技术。 问题提出 n“我们应该更注重于保证程序需求的实现，为什么 要花费时间和精力来担心(和测试)逻辑细节？” n逻辑错误和不正确假设与一条程序路径被运行的可能 性成反比。当我们设计和实现主流之外的功能、条件 或控制时，错误往往开始出现在我们的工作中。日常 处理往往被很好地了解(和很好地细查)，而“特殊情况” 的处理则难于发现。 n我们经常相信某逻辑路径不可能被执行，而事实上， 它可能在正常的基础上被执行。程序的逻辑流有时是 违反直觉的，这意味着我们关于控制流和数据流的一 些无意识的假设可能导致设计错误，只有路径测试才 能发现这些错误。 n例如，考虑 100行C语言程序

7、，在一些基本的数据声明之后，程 序包含两个嵌套循环，根据输入的条件分别执行1到20次，在内 部循环中，需要四个if-then-else结构，该程序中大约有1014条 可能路径！ n为了正确表达这个数值，我们假设开发了一个有魔力的测试处理 器(“有魔力”是因为不存在这样的处理器)进行穷举测试。该处理 器能在一毫秒内开发一个测试用例、进行运行并评估结果，如果 每天运行24小时，每年运行365天，则需要3170年的时间来测试 这个程序。不可否认，这将导致大多数开发进度表的混乱，对大 型软件系统不可能进行穷举测试。 n然而，白盒测试不应该被抛弃，可选择有限数量的重要逻辑路径 进行测试，检测重要数据结构

8、的有效性 逻辑覆盖 (A1) and (B=0) (A=2) or (X1) X=X/A X=X+1 T1 T1 T2T2 T3 T3 T4 T4 T T T T1234 4321TTTT T T T T1234 n判定条件覆盖就是选取足够多的测试数据，使得判 定表达式中的每个条件都取到各种可能的值，而且每 个判定表达式也都取到各种可能的结果 A1B=0 X=X/A A=2 X1X=X+1 T T T T1234 T T T T1234 T T12 T T12 T T12 T T12 T T34 T T34 T T34 T T34 T T T T1234 T T T T1234 T T T T

9、1234 T T T T1234 逻辑覆盖总结： n语句覆盖对程序的逻辑覆盖很少 n判定覆盖比语句覆盖强，但是对程序逻辑的覆盖程度 仍然不高，上面的测试数据只覆盖了程序全部路径的 一半。 n条件覆盖通常比判定覆盖强，因为它使判定表达式中 每个条件都取到了两个不同的结果，判定覆盖却只关 心整个判定表达式的值。 n判定/条件覆盖也并不一定比条件覆盖更强 n条件组合覆盖是更强的逻辑覆盖标准，但是，满足条 件组合覆盖标准的测试数据并不一定能使程序中的每 条路径都执行到。 点覆盖 n 如果连通图 G 的子图G是连通的，而且 包含G的所有节点，则称G是G的点覆盖。 n 与语句覆盖标准相同。 边覆盖 n 如

10、果连通图 G 的子图G是连通的，而且 包含G的所有边，则称G是G的边覆盖。 n 通常与判定覆盖标准相同。 T T T T1234 T T T T1234 T T T T1234 T T T T3412 控制结构测试 n基本路径测试 n条件测试 n循环测试 基本路径测试 n基本路径测试是在程序控制图的基础上， 通过分析控制构造的环行复杂性，导出基 本可执行路径集合，从而设计测试用例的 方法。设计出的测试用例要保证在测试中 程序的每一个可执行语句至少执行一次 （如让循环体只执行一次）。 n例子 基本路径测试例子例子 nvoid Sort(int iRecordNum,int iType) n1 n

11、2 int x=0; n3 int y=0; n4 while (iRecordNum 0) n5 n6 if(0= =iType) n7x=y+2; n9 else n8 if(1= =iType) n10 x=y+10; n12 else n11 x=y+20; n13 n14 环形复杂度 第二步：计算环形复杂度 n环形复杂度是一种为程序逻辑复杂性提供定量测度的软件 度量，将该度量用于计算程序的基本的独立路径数目，为 确保所有语句至少执行一次的测试数量的上界。独立路径 必须包含一条在定义之前不曾用到的边。 n有以下三种方法计算圈复杂度： n 流图中区域的数量对应于环型的复杂性； n 给定流

12、图G的圈复杂度V(G)，定义为V(G)=E-N+2，E 是流图中边的数量，N是流图中结点的数量； n 给定流图G的圈复杂度V(G)，定义为V(G)=P+1，P是 流图G中判定结点的数量。 第三步：导出测试用例 n根据上面的计算方法，可得出四个独立的路径： n 路径1：4-14 n 路径2：4-6-7-14 n 路径3：4-6-8-10-13-4-14 n 路径4：4-6-8-11-13-4-14 n根据上面的独立路径，去设计输入数据，使程序 分别执行到上面四条路径。 第四步：准备测试用例 n为了确保基本路径集中的每一条路径的执行，根据判断结点给出的条件，选 择适当的数据以保证某一条路径可以被测试到，满足上面例子基本路径集的 测试用例是： n路径1：4-14 n输入数据：iRecordNum