软件工程--测试.ppt

-测试,软件工程,内容提要,软件测试的目的 错误分类 基本任务、特点和原则 软件测试的信息流 软件测试的方法 测试用例的设计 软件测试的过程及其相关的角色与职责 测试层次 测试的类型 软件测试与调试 软件可靠性,软件测试是为了发现错误而执行程序的过程。 程序运行需要数据，为测试设计的数据称测试用例。 软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例，并利用这些测试用例去运行程序，以发现程序错误的过程。,软件测试在软件生存期中横跨两个阶段：通常在编写出每一个模块之后就对它做必要的测试（称为单元测试）。模块的编写者与测试者是同一个人。编码与单元测试属于软件生存期中的同一个阶段。 在这个阶段结束之后，对软件系统还要进行各种综合测试，这是软件生存期的另一个独立的阶段，即测试阶段，通常由专门的测试人员承担这项工作。,软件测试的目的,Grenford J.Myers就软件测试目的提出以下观点： 测试是程序的执行过程，目的在于发现错误； 一个好的测试用例很可能找到迄今为止尚未发现的错误； 一个成功的测试是发现了至今未发现的错误的测试。 E.W.Dijkstra 指出: 程序测试能证明错误的存在，但不能证明错误不存在。 测试的目的是发现程序中的错误，是为了证明程序有错，而不是证明程序无错。,软件测试的目的,测试的目的是想以最少的时间和人力系统地找出软件中潜在的各种错误和缺陷。如果我们成功地实施了测试，就能够发现软件中的错误。测试的附带收获是，它能够证明软件的功能和性能与需求说明相符合。此外，实施测试收集到的测试结果数据为可靠性分析提供了依据。 把证明程序无错当作测试目的不仅是不正确的, 完全做不到的，而且对做好测试没有任何益处，甚至是十分有害的。 能够发现错误的测试是成功的测试，否则是失败的测试。,测试者知道软件怎样才能发生故障而导致失败，并可记录发生失败的多种故障类型 测试案例没有冗余。每个测试案例都有不同的用途，不要重复相同意义的测试案例 使用最具有代表性的案例，它能够高效率揭示所有可能的错误 每个测试应该能独立执行，不能太复杂，也不会太简单，它们能够被组合用于一个测试案例中,好的测试应该具有的特性,软件错误的分类,由于人们对错误有不同的理解和认识，所以目前还没有一个统一的错误分类方法。错误难于分类的原因，一方面是由于一个错误有许多征兆，因而它可以被归入不同的类。另一方面是因为把一个给定的错误归于哪一类，还与错误的来源和程序员的心理状态有关。,To be continue,软件错误的分类,按错误的影响和后果分类 较小错误：只对系统输出有一些非实质性影响。如，输出的数据格式不合要求等。 中等错误：对系统的运行有局部影响。如输出的某些数据有错误或出现冗余。 较严重错误：系统的行为因错误的干扰而出现明显不合情理的现象。比如开出了0.00元的支票，系统的输出完全不可信赖。 严重错误：系统运行不可跟踪，一时不能掌握其规律，时好时坏。 非常严重的错误：系统运行中突然停机，其原因不明，无法软启动。 最严重的错误：系统运行导致环境破坏，或是造成事故，引起生命、财产的损失。,To be continue,软件错误的分类,按错误的性质和范围分类 B.Beizer从软件测试观点出发，把软件错误分为5类： 功能错误 系统错误 加工错误 数据错误 代码错误,To be continue,功能错误,规格说明错误：规格说明可能不完全，有二义性或自身矛盾。 功能错误：程序实现的功能与用户要求的不一致。这常常是由于规格说明中包含错误的功能、多余的功能或遗漏的功能所致。 测试错误：软件测试的设计与实施发生错误。软件测试自身也可能发生错误。 测试标准引起的错误：对软件测试的标准要选择适当，若测试标准太复杂，则导致测试过程出错的可能就大。,系统错误,外部接口错误：外部接口指如终端、打印机、通信线路等系统与外部环境通信的手段。所有外部接口之间，人与机器之间的通信都使用形式的或非形式的专门协议。如果协议有错，或太复杂，难以理解，致使在使用中出错。此外还包括对输入输出格式错误理解，对输入数据不合理的容错等等。 内部接口错误：内部接口指程序之间的联系。它所发生的错误与程序内实现的细节有关。例如，设计协议错、输入输出格式错、数据保护不可靠、子程序访问错等。 硬件结构错误：这类错误在于不能正确地理解硬件如何工作。例如，忽视或错误地理解分页机构、地址生成、通道容量、IO指令、中断处理、设备初始化和启动等而导致的出错。,To be continue,系统错误,操作系统错误：这类错误主要是由于不了解操作系统的工作机制而导致出错。当然，操作系统本身也有错误，但是一般用户很难发现这种错误。 软件结构错误：由于软件结构不合理或不清晰而引起的错误。这种错误通常与系统的负载有关，而且往往在系统满载时才出现。这是最难发现的一类错误。例如，错误地设置局部参数或全局参数；错误地假定寄存器与存储器单元初始化了；错误地假定不会发生中断而导致不能封锁或开中断；错误地假定程序可以绕过数据的内部锁而导致不能关闭或打开内部锁；错误地假定被调用子程序常驻内存或非常驻内存等等，都将导致软件出错。,To be continue,系统错误,控制与顺序错误：包括：忽视了时间因素而破坏了事件的顺序；猜测事件出现在指定的序列中；等待一个不可能发生的条件；漏掉先决条件；规定错误的优先级或程序状态；漏掉处理步骤；存在不正确的处理步骤或多余的处理步骤等。 资源管理错误：这类错误是由于不正确地使用资源而产生的。例如，使用未经获准的资源；使用后未释放资源；资源死锁；把资源链接在错误的队列中等等。,加工错误,算术与操作错误：指在算术运算、函数求值和一般操作过程中发生的错误。包括：数据类型转换错；除法溢出；错误地使用关系比较符；用整数与浮点数做比较等。 初始化错误：典型的错误有：忘记初始化工作区，忘记初始化寄存器和数据区；错误地对循环控制变量赋初值；用不正确的格式，数据或类型进行初始化等等。 控制和次序错误：这类错误与系统级同名错误类似，但它是局部错误。包括：遗漏路径；不可达到的代码；不符合语法的循环嵌套；循环返回和终止的条件不正确；漏掉处理步骤或处理步骤有错等。 静态逻辑错误：这类错误主要包括：不正确地使用CASE语句；在表达式中使用不正确的否定（例如用“”代替“”的否定）；对情况不适当地分解与组合；混淆“或”与“异或”等。,数据错误,动态数据错误：动态数据是在程序执行过程中暂时存在的数据。各种不同类型的动态数据在程序执行期间将共享一个共同的存储区域，若程序启动时对这个区域未初始化，就会导致数据出错。由于动态数据被破坏的位置可能与出错的位置在距离上相差很远，因此要发现这类错误比较困难。 静态数据错误：静态数据在内容和格式上都是固定的。它们直接或间接地出现在程序或数据库中，由编译程序或其它专门程序对它们做预处理，这是在程序执行前防止静态错误的好办法，但预处理也会出错。 数据内容错误：数据内容是指存储于存储单元或数据结构中的位串、字符串或数字。数据内容本身没有特定的含义，除非通过硬件或软件给予解释。数据内容错误就是由于内容被破坏或被错误地解释而造成的错误。,To be continue,数据错误,数据结构错误：数据结构是指数据元素的大小和组织形式。在同一存储区域中可以定义不同的数据结构。数据结构错误主要包括结构说明错误及把一个数据结构误当做另一类数据结构使用的错误。这是更危险的错误。 数据属性错误：数据属性是指数据内容的含义或语义。例如，整数、字符串、子程序等等。数据属性错误主要包括：对数据属性不正确地解释，比如错把整数当实数，允许不同类型数据混合运算而导致的错误等。,代码错误,主要包括：语法错误；打字错误；对语句或指令不正确理解所产生的错误。,程序错误的分类,Good enoughGerhart分类方法把软件的逻辑错误按生存期不同阶段分为4类: 问题定义错误 规格说明错误 设计错误 编码错误,问题定义错误,它们是在软件定义阶段，分析员研究用户的要求后所编写的文档中出现的错误。换句话说，这类错误是由于问题定义不满足用户的要求而导致的错误。,规格说明错误,这类错误是指规格说明与问题定义不一致所产生的错误。它们又可以细分成： 不一致性错误-规格说明中功能说明与问题定义发生矛盾。 冗余性错误-规格说明中某些功能说明与问题定义相比是多余的。 不完整性错误-规格说明中缺少某些必要的功能说明。 不可行错误-规格说明中有些功能要求是不可行的。 不可测试错误-有些功能的测试要求是不现实的。,设计错误,这是在设计阶段产生的错误，它使系统的设计与需求规格说明中的功能说明不相符。它们又可以细分为： 设计不完全错误：某些功能没有被设计，或设计得不完全。 算法错误：算法选择不合适。主要表现为算法的基本功能不满足功能要求、算法不可行或者算法的效率不符合要求。 模块接口错误：模块结构不合理；模块与外部数据库的界面不一致，模块之间的界面不一致。 控制逻辑错误：控制流程与规格说明不一致；控制结构不合理。 数据结构错误：数据设计不合理；与算法不匹配；数据结构不满足规格说明要求。,编码错误,编码过程中的错误是多种多样的，大体可归为以下几种：数据说明错、数据使用错、计算错、比较错、控制流错、界面错、输入输出错，及其它的错误。 在不同的开发阶段，错误的类型和表现形式是不同的，故应当采用不同的方法和策略来进行检测。,软件测试的基本任务,测试阶段的基本任务应该是根据软件开发各阶段的文档资料和程序的内部结构，精心设计一组“高产”的测试用例，利用这些用例执行程序，找出软件潜在的缺陷。,软件测试的特点,软件测试的开销大 按照Boehm 的统计，软件测试的开销大约占总成本的30%50%。例如：APPOLLO登月计划，80%的经费用于软件测试。 不能进行穷举测试 只有将所有可能的情况都测试到，才有可能检查出所有的错误。但这是不可能的。,例如： 程序P 有两个整型输入量X、Y，输出量为Z，在32 位机上运行。所有的测试数据组(Xi,Yi)的数目为：232×232264。假设毫秒执行次，如要进行完全测试，共需亿年。,例:Windows95有1000万行代码 Windows2000有5000万行代码， 3000多个工程师，几百个小团队。 Exchange2000和 Windows2000开发人员结构,软件测试的原则,测试是一项非常复杂的、创造性的和需要高度智慧的挑战性的工作。测试一个大型程序所要求的创造力，事实上可能要超过设计那个程序所要求的创造力。软件测试中一些直观上看是很显而易见的至关重要的原则，总是被人们忽视。 应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。 不应把软件测试仅仅看作是软件开发的一个独立阶段，而应当把它贯穿到软件开发的各个阶段中。坚持在软件开发的各个阶段的技术评审，这样才能在开发过程中尽早发现和预防错误，把出现的错误克服在早期，杜绝某些发生错误的隐患。 测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成。 测试之前应当根据测试的要求选择测试用例（Test case），用来检验程序员编制的程序，因此不但需要测试的输入数据，而且需要针对这些输入数据的预期输出结果。,To be continue,软件测试的原则,程序员应避免检查自己的程序。 程序员应尽可能避免测试自己编写的程序，程序开发小组也应尽可能避免测试本小组开发的程序。如果条件允许，最好建立独立的软件测试小组或测试机构。这点不能与程序的调试（debuging）相混淆。调试由程序员自己来做可能更有效。,To be continue,软件测试的原则,开发者在测试自己的程序时存在一些弊病： 开发者对自己的程序印象深刻，并总以为是正确的。倘若在设计时就存在理解错误，或因不良的编程习惯而留下隐患，那么他本人很难发现这类错误。 开发者对程序的功能、接口十分熟悉，他自己几乎不可能因为使用不当而引发错误，这与大众用户的情况不太相似，所以自己测试程序难以具备典型性。 程序设计犹如艺术设计，开发者总是喜欢欣赏程序的成功之处，而不愿看到失败之处。让开发者去做“蓄意破坏”的测试，就像杀自己的孩子一样难以接受。即便开发者非常诚实，但“珍爱程序”的心理让他在测试时不知不觉地带入了虚假成分。,下面我们再来看看Microsoft 公司关于测试的经验教训： IBM PC 机一起推出的BASIC 软件，用户在用“.1”（或者其他数字）除以10 时，就会出错。在FORTRAN 软件中也存在破坏数据的“Bug”。由此激起了许多采用Microsoft 操作系统的PC 厂商的极大不满，而且很多个人用户也纷纷投诉。 Microsoft 公司的经理们发现很有必要引进更好的内部测试与质量控制方法。但是遭到很多程序设计师甚至一些高级经理的坚决反对，他们固执地认为在高校学生、秘书或者外界合作人士的协助下，开发人员可以自己测试产品。在1984 年推出Mac 机Multiplan（电子表格软件）之前，Microsoft 曾特地请Authur Anderson 咨询公司进行测试。但是外界公司一般没有能力执行全面的软件测试。结果，一种相当厉害的破坏数据的“Bug”迫使Microsoft 公司为它的2 万多名用户免费提供更新版本，代价是每个版本10 美元，一共花了20 万美元，可谓损失惨重。 痛定思痛后，Microsoft 公司的经理们得出一个结论：如果再不成立独立的测试部门，软件产品就不可能达到更高的质量标准。IBM 和其他有着成功的软件开发历史的公司便是效法的榜样。但Microsoft 公司并不照搬IBM 的经验，而是有选择地采用了一些看起来比较先进的方法，如独立的测试小组，自动测试以及为关键性的构件进行代码复查等。,Microsoft 公司的一位开发部门主管戴夫·穆尔回忆说：“我们清楚不能再让开发部门自己测试了。我们需要一个单独的小组来设计测试，运行测试，并把测试信息反馈给开发部门。这是一个伟大的转折点。” 但是有了独立的测试小组后，并不等于万事大吉了。自从Microsoft 公司在1984 年与1986 年之间扩大了测试小组后，开发人员开始“变懒”了。他们把代码扔到一边等着测试，忘了唯有开发人员自己才能阻止错误的发生、防患于未来。此时，Microsoft 公司历史上第二次灾难降临了。原定于1986 年7 月发行的Mac 机的Word 3.0，千呼万唤方于1987 年2月问世。这套软件竟然有700 多出错误，有的错误可以破坏数据甚至摧毁程序。一下子就使Microsoft 名声扫地。公司不得不为用户提供升级版本，费用超过了100 万美元。 从Microsoft 公司的教训中可知，公司内部对产品的测试需要开发人员与独立的测试小组共同参与。,软件测试的原则,在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。 合理的输入条件是指能验证程序正确的输入条件；不合理的输入条件是指异常的，临界的，可能引起问题异变的输入条件。软件系统处理非法命令的能力必须在测试时受到检验。用不合理的输入条件测试程序时，往往比用合理的输入条件进行测试能发现更多的错误。,To be continue,软件测试的原则,充分注意测试中的群集现象。 在被测程序段中，若发现错误数目多，而残存错误数目也比较多，这种错误群集现象。群集现象已为许多程序的测试实践所证实。根据这个规律，应当对错误群集的程序段进行重点测试，以提高测试投资的效益。 pareto原则：测试发现的错误中80%很可能起源于20%的模块中。应孤立这些疑点模块重点测试。 严格执行测试计划，排除测试的随意性。 测试之前应仔细考虑测试的项目，对每一项测试做出周密的计划，包括被测程序的功能、输入和输出、测试内容、进度安排、资源要求、测试用例的选择、测试的控制方式和过程等，还要包括系统的组装方式、跟踪规程、调试规程，回归测试的规定，以及评价标准等。对于测试计划，要明确规定，不要随意解释。,To be continue,软件测试的原则,应当对每一个测试结果做全面检查。 有些错误的征兆在输出实测结果时已经明显地出现了，但是如果不仔细地全面地检查测试结果，就会使这些错误被遗漏掉。所以必须对预期的输出结果明确定义，对实测的结果仔细分析检查，以暴露错误。 妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。,软件测试阶段的信息流,需求规格说明书 软件设计说明书 被测源程序,测试计划 测试用例 测试驱动程序,软件测试阶段的信息流,上图中，测试过程需要三类输入： 软件配置：包括软件需求规格说明、软件设计规格说明、源代码等； 测试配置：包括测试计划、测试用例、测试驱动程序等； 测试工具：测试工具为测试的实施提供某种服务。例如，测试数据自动生成程序、静态分析程序、动态分析程序、测试结果分析程序、以及驱动测试的工作台等。,软件测试阶段的信息流,测试之后，用实测结果与预期结果进行比较。如果发现出错的数据，就要进行调试。对已经发现的错误进行错误定位和确定出错性质，并改正这些错误，同时修改相关的文档。修正后的文档一般都要经过再次测试，直到通过测试为止。 通过收集和分析测试结果数据，对软件建立可靠性模型。,如果测试发现不了错误，那么可以肯定，测试配置考虑得不够细致充分，错误仍然潜伏在软件中。这些错误最终不得不由用户在使用中发现，并在维护时由开发者去改正。但那时改正错误的费用将比在开发阶段改正错误的费用要高出40倍到60倍。,软件测试方法,静态测试方法 动态测试方法 白盒测试方法 黑盒测试方法,静态和动态测试,静态测试方法,静态测试方法的基本特征是在对软件进行分析、检查和审阅，但并不实际运行被测试的软件。 如： 对需求规格说明书、软件设计说明书、源程序做检查和审阅，包括： 是否符合标准和规范； 通过结构分析、流图分析、符号执行指出软件缺陷。,To be continue,静态测试方法,人工测试：通过人工阅读分析以及评审软件的文档、程序资料等。一些设计上的逻辑错误在机器上不易发现，需要人工复查。好的人工复查，可找出3070%的编码和逻辑设计错误。 计算机辅佐分析：设计一些分析工具对被测程序进行静态分析，从中提取信息。如检查局部变量和全局变量、参数匹配、判断与循环的嵌套匹配、潜在的死循环、不执行的代码、过程调用层次等。,动态测试方法,动态测试：通过运行软件来检验软件的动态行为和运行结果的正确性 动态测试的两个基本要素： 被测试程序 测试数据（测试用例）,To be continue,动态测试方法,动态测试方法的基本步骤： 选取定义域有效值，或定义域外无效值； 对已选取值决定预期的结果； 用选取值执行程序； 执行结果与预期的结果相比，不吻合程序有错。 如果了解软件产品的内部逻辑结果，可针对某些特定条件设计测试用例，对软件的逻辑路径进行测试，即白盒测试； 如果完全不考虑程序的内部结构和处理过程，测试仅在程序界面上进行，测试的目的是为了证实各个功能完全可执行，并在各功能中查找错误，则是黑盒测试。,To be continue,黑盒测试与白盒测试的比较,黑盒测试是从用户观点，按规格说明书要求的输入数据与输出数据的对应关系设计测试用例，是根据程序外部特征进行测试。 白盒测试是根据程序内部逻辑结构进行测试。 值得指出的是，黑盒测试法与白盒测试法不能互相替代，相反两者应互为补充，在测试的不同阶段为发现不同类型的错误而灵活选用。,黑盒测试与白盒测试比较,黑盒测试 白盒测试,优 点,缺 点,性 质,适用于各阶段测试 从产品功能角度测试 容易入手生成测试数据,可构成测试数据使特定程序部分得到测试 有一定的充分性度量手段 可或较多工具支持,某些代码得不到测试 如果规格说明有误，则无法发现 不易进行充分性测试,不易生成测试数据(通常) 无法对未实现规格说明的部分进行测试 工作量大，通常只用于单元测试，有应用局限,是一种确认技术，回答“我们在构造一个正确的系统吗？”,是一种验证技术，回答 “我们在正确地构造一个系统吗？”,测试用例的定义 测试内容的一系列情景和每个情景中必须依靠输入和输出，而对软件的正确性进行判断的测试文档，称为测试用例。 测试用例就是将软件测试的行为活动，做一个科学化的组织归纳。,测试用例的设计,如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。 测试用例是测试工作的指导，是软件测试的必须遵守的准则。更是软件测试质量稳定的根本保障。,测试用例的组成元素与范例,测试用例编号ID 测试用例标题 测试的模块,测试输入条件 期望的输出结果 其它说明,测试用例的设计方法,黑盒测试技术 等价类划分法 边界值分析法 错误推测法 白盒测试技术 逻辑覆盖法 基本路径测试法,黑盒测试技术,等价类划分法 边界值分析法 错误推测法,等价类划分法,等价类划分法是一种典型的黑盒测试方法，使用这一方法时，完全不考虑程序的内部结构，只依据程序的规格说明来设计测试用例。 等价类划分法把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据做为测试用例。 使用这一方法设计测试用例要经历划分等价类（列出等价类表）和选取测试用例两步。,划分等价类,等价类的划分有两种不同的情况： 有效等价类：是指对于程序的规格说明来说，是合理的，有意义的输入数据构成的集合。 无效等价类：是指对于程序的规格说明来说，是不合理的，无意义的输入数据构成的集合。 在设计测试用例时，要同时考虑有效等价类和无效等价类的设计。,划分等价类的原则,如果输入条件规定了取值范围，或值的个数，则可以确立一个有效等价类和两个无效等价类。,例如，在规格说明中，对输入条件有一句话： “ 项数可以从1到999 ” 则有效等价类是“1项数999”; 两个无效等价类是“项数1”或“项数999”。在数轴上表示成:,1,999,有效等价类,无效等价类,无效等价类,To be continue,划分等价类的原则,如果输入条件规定了输入值的集合，或者是规定了“必须如何”的条件，这时可确立一个有效等价类和一个无效等价类。 例如，在编程语言中对变量标识符规定为“以字母打头的串”。那么所有以字母打头的构成有效等价类，而不在此集合内（不以字母打头）的归于无效等价类。,To be continue,划分等价类的原则,如果输入条件是一个布尔量，则可以确定一个有效等价类和一个无效等价类。 如果规定了输入数据的一组值，而且程序要对每个输入值分别进行处理。这时可为 每一个输入值确立一个有效等价类，此外针对这组值确立一个无效等价类，它是所有不允许的输入值的集合。 例如，在教师上岗方案中规定对教授、副教授、讲师和助教分别计算分数，做相应的处理。因此可以确定4个有效等价类为教授、副教授、讲师和助教，一个无效等价类，它是所有不符合以上身分的人员的输入值的集合。,To be continue,划分等价类的原则,如果规定了输入数据必须遵守的规则，则可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。 例如，Pascal语言规定 “一个语句必须以分号;结束”。这时，可以确定一个有效等价类 “以;结束”，若干个无效等价类 “以:结束”、“以,结束”、“以 结束”、“以LF结束”等。,To be continue,以上列出的只是测试时可能遇到的情况的很小一部分，实际情况千变万化，根本无法一一列出。如规定了输入数据为整数，可划分出正整数、零和负整数三个有效类，如果程序处理对象是表格，则应使用空表以及含一项或多项的表。 要正确划分等价类，必须要注意经验的积累和正确分析被测试程序的功能。 不需要设计测试数据来暴露编译程序肯定能发现的错误。,划分等价类的原则,用等价类划分法设计测试用例步骤,形成等价类表，每一等价类规定一个唯一的编号； 设计一测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步骤，直到所有有效等价类均被测试用例所覆盖； 设计一新测试用例，使其覆盖一个且只覆盖一个尚未被覆盖的无效等价类，重复这一步骤直到所有无效等价类均被覆盖。,例: 某报表处理系统要求用户输入处理报表的日期，日期限制在2003年1月至2008年12月，即系统只能对该段期间内的报表进行处理，如日期不在此范围内，则显示输入错误信息。 系统日期规定由年、月的6位数字字符组成，前四位代表年，后两位代表月。 如何用等价类划分法设计测试用例,来测试程序的日期检查功能？,用等价类划分法设计测试用例步骤,第一步：等价类划分,“报表日期”输入条件的等价类表,第二步：为有效等价类设计测试用例,对表中编号为1,2,3的3个有效等价类用一个测试用例覆盖：,(1) 6位数字字符 (2) 年在20032008之间 (3) 月在112之间,第三步：为每一个无效等价类 至少设计一个测试用例,不能出现相同 的测试用例,本例的10个等价类至 少需要8个测试用例,边界值分析法,边界值分析也是一种黑盒测试方法，是对等价类划分方法的补充。 边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。 人们从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。,软件边界与悬崖很类似,边界值分析法,如果在悬崖峭壁边可以自信地安全行走，平地就不在话下。 如果软件在能力达到极限时能够运行，那么在正常情况下就不会出什么问题。,确定边界值的方式,如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。 如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少一、比最大个数多一的数作为测试数据。 如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。 如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例。 分析规格说明，找出其他可能的边界条件。,“报表日期”边界值分析法测试用例,错误推测法,基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例。 经验表明，一段程序中已经发现的错误数往往和尚未发现的错误数成正比。因此进一步测试要着重测试发现错误较多的程序段。,错误推测法测试用例设计,发现程序经常出现的错误的方法： 单元测试中发现的模块错误； 产品的以前版本曾经发现的错误； 输入数据为0或字符为空； 当软件要求输入时(比如在文本框中)，不是没有输入正确的信息，而是根本没有输入任何内容，单单按了Enter键； 这种情况在产品说明书中常常忽视，程序员也可能经常遗忘，但是在实际使用中却时有发生。程序员总会习惯性的认为用户要么输入信息，不管是看起来合法的或非法的信息，要不就会选择Cancel键放弃输入。,白盒测试技术,逻辑覆盖法法 基本路径测试法,白盒测试应该根据程序的控制结构设计测试用例,原则是: 保证模块中每一独立的路径至少执行一次; 保证所有判断的每一分枝至少执行一次； 保证每一循环都在边界条件和一般条件下至少各执行一次; 验证所有内部数据结构的有效性。,逻辑覆盖,逻辑覆盖是以程序内部的逻辑结构为基础的设计测试用例的技术。这一方法要求测试人员对程序的逻辑结构有清楚的了解，甚至要能掌握源程序的所有细节。 由于覆盖测试的目标不同，逻辑覆盖又可分为： 语句覆盖 判定覆盖 条件覆盖 判定/条件覆盖 条件组合覆盖 路径覆盖,语句覆盖,语句覆盖就是设计若干个测试用例，运行被测程序，使得每一可执行语句至少执行一次。这种覆盖又称为点覆盖，它使得程序中每个可执行语句都得到执行，但它是最弱的逻辑覆盖准，效果有限，必须与其它方法交互使用。,To be continue,(A1) and (B=0),(A=2) or (X1),X = X / A,X=X+1,T,T,F,F,b,c,e,a,1,s,d,2,3,4,5,6,7,PROCEDURE Example(A,B:real; X:real ); Begin IF (A1) AND (B=0) THEN X:= X / A; IF ( A=2 ) OR (X1) THEN X:=X+1 END;,I. A=2, B= 0, X=4 - sacbed,语句覆盖 所有的语句至少执行一次！ 是最弱的逻辑覆盖,判定覆盖,判定覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次。判定覆盖又称为分支覆盖。 判定覆盖只比语句覆盖稍强一些，但实际效果表明，只是判定覆盖，还不能保证一定能查出在判断的条件中存在的错误。因此，还需要更强的逻辑覆盖准则去检验判断内部条件。,To be continue,(A1) and (B=0),(A=2) or (X1),X = X / A,X=X+1,T,T,F,F,b,c,e,a,1,s,d,2,3,4,5,6,7,每个语句至少执行一次！ 每个判定的每种可能都至少执行一次！ 即每个判定的真假分支都至少执行一次！,I: A=3, B=0,X=3: sacbd,II: A=2, B=1,X=1: sabed,满足判定覆盖的测试用例一定满足语句覆盖：判定覆盖比语句覆盖强。但仍是弱的逻辑覆盖。,条件覆盖,条件覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判断的每个条件的可能取值至少执行一次。 条件覆盖深入到判定中的每个条件，但可能不能满足判定覆盖的要求。,To be continue,每个语句至少执行一次，而且判定表达式中的每个条件都要取得各种可能的结果。,第一判定表达式: 设条件 A1 取真 记为T1 假 T1 条件 B=0 取真 记为T2 假 T2 第二判定表达式: 设条件 A=2 取真 记为T3 假 T3 条件 X1 取真 记为T4 假 T4,条件覆盖要求这8种值都要取到,(A1) and (B=0),(A=2) or (X1),X = X / A,X=X+1,T,T,F,F,b,c,e,a,1,s,d,2,3,4,5,6,7,(A1),(A1),(B=0),(B0),(A=2),(A2),(X1),(X1),: A=1, B=1,X=1: sabd,: A=2, B=0,X=4: sacbed,满足判定覆盖,(A1) and (B=0),(A=2) or (X1),X = X / A,X=X+1,T,T,F,F,b,c,e,a,1,s,d,2,3,4,5,6,7,(A1),(A1),(B=0),(B0),(A=2),(A2),(X1),(X1),: A=1, B=1,X=2: sabed,: A=2, B=0,X=1: sacbed,不满足判定覆盖,(A1),(A1),(B=0),(B0),(A=2),(A2),(X1),(X1),: A=2, B=1,X=1: sabed,: A=1, B=0,X=3: sabed,既不满足条件覆盖 又不满足判定覆盖,条件覆盖不一定包含判定覆盖 判定覆盖也不一定包含条件覆盖,条件覆盖通常比判定覆盖强，因为它使判定表达式中每个条件都取到了两个不同的结果，判定覆盖却关心整个判定表达式的值。但也可能有相反的情况：虽然每个条件都取到了不同值，但判定表达式却始终只取一个值。,判定-条件覆盖,既然判定条件不一定包含条件覆盖，条件覆盖也不一定包含判定覆盖，就自然会提出一种能同时满足两种覆盖标准的逻辑覆盖，这就是判定/条件覆盖。 判定条件覆盖就是设计足够的测试用例，使得判断中每个条件的所有可能取值至少执行一次，同时每个判断本身的所有可能判断结果至少执行一次。换言之，即是要求各个判断的所有可能的条件取值组合至少执行一次。,To be continue,判定-条件覆盖,测试用例I,II既满足判定覆盖也满足条件覆盖的要求。严格来讲，合适的条件覆盖测试用例设计应该做到满足判定/条件覆盖的标准：判定/条件覆盖并不比条件覆盖更强。 判定条件覆盖有缺陷。表面上，它测试了所有条件的取值，但事实并非如此，往往某些条件掩盖了另一些条件，会遗漏某些条件取值错误的情况。为彻底地检查所有条件的取值，需要将判定语句中给出的复合条件表达式进行分解，形成由多个基本判定嵌套的流程图。这样就可以有效地检查所有的条件是否正确了。,判定-条件覆盖,复合判定的例子：,To be continue,判定-条件覆盖,复合判定的例子： 改为单个条件判定,条件组合覆盖,条件组合覆盖就是设计足够的测试用例，运行被测程序，使得每个判断的所有可能的条件取值组合至少执行一次。 这是一种相当强的覆盖准则，可以有效地检查各种可能的条件取值的组合是否正确。它不但可覆盖所有条件的可能取值的组合，还可覆盖所有判断的可取分支，但可能有的路径会遗漏掉。测试还不完全。,A1, B0 A1, B0 A1, B0 A1, B0 A2, X1 A2, X1 A2, X1 A2, X1,选取足够多的测试数据，使得每个判定表达式中条件的各种可能组合都至少出现一次。,(A1),(A1),(B=0),(B0),(A=2),(A2),(X1),(X1),I. A=2,B=0,X=4,II. A=2,B=1,X=1,III. A=1,B=0,X=2,IV. A=1,B=1,X=1,I: sacbed II: sabed III: sabed IV: sabd,覆盖路径,满足条件组合覆盖标准的测试数据，也一定满足判定覆盖、条件覆盖和判定/条件覆盖标准。,4组测试数据可以使8种条件组合每种至少出现一次：,显然，满足条件组合覆盖的测试用例，也一定满足判定覆盖、条件覆盖和判定/条件覆盖。 所以，条件组合覆盖是前述几种覆盖中最强的。但满足条件组合覆盖的不一定能使程序中的每条路径都执行到，如sacbd。,如果连通图 G 的子图G´是连通的，而且包含G的所有节点，则称G´是G的点覆盖。 与语句覆盖标准相同。,点覆盖,如果连通图 G 的子图G´是连通的，而且包含G的所有边，则称G´是G的边覆盖。 通常与判定覆盖标准相同。,: A=3,B=0,X=3 (1-4-5-3); : A=2,B=1,X=1 (1-2-6-7),: A=1,B=1,X=1 (1-2-3); : A=2,B=0,X=4 (1-4-5-6-7),或,边覆盖,路径覆盖,路径测试就是设计足够的测试用例，覆盖程序中所有可能的路径。这是最强的覆盖准则。但在路径数目很大时，真正做到完全覆盖是很困难的，必须把覆盖路径数目压缩到一定限度。,路径覆盖是相当强的逻辑覆盖，它保证程序中每条可能的路径都至少执行一次，因此更具代表性，暴露错误的能力也比较强。但为了做到路径覆盖，只需考虑每个判定式的取值，并没有检验表达式中条件的各种可能组合。如果将路径覆盖和条件组合覆盖结合起来，可以设计出检错能力更强的测试数据。,路径覆盖,通过分析由控制构造的环路的复杂性，导出基本路径集合，从而设计测试用例，保证这些路径至少通过一次。 为了使用图论的知识和术语，引入流图(亦即程序图)的概念，流图即把流程图中结构化构件改用一般有向图的表示形式。,基本路径测试法,流图(flow graph ),在流图中用圆表示节点，一个圆代表一条或多条语句。程序流程图中的一个处理框序列和一个菱形判定框，可以映射