测试用例设计.ppt

测试用例设计,软件测试的目的,基于不同的立场，存在着两种完全不同的测试目的。 从用户的角度出发，普遍希望通过软件测试暴露软件中隐藏的错误和缺陷，以考虑是否可接受该产品。 从软件开发者的角度出发，则希望测试成为表明软件产品中不存在错误的过程，验证该软件已正确地实现了用户的要求，确立人们对软件质量的信心。,软件测试的目的,测试是程序的执行过程，目的在于发现错误； 一个好的测试用例在于能发现至今未发现的错误； 一个成功的测试在于发现了至今未发现的错误。,软件测试的目的,换言之，测试的目的是 想以最少的时间和人力，系统地找出软件中潜在的各种错误和缺陷。如果我们成功地实施了测试，我们就能够发现软件中的错误。 测试的附带收获是，它能够证明软件的功能和性能与需求说明相符合。 实施测试收集到的测试结果数据为可靠性分析提供了依据。 测试不能表明软件中不存在错误，它只能说明软件中存在错误。,软件测试的原则,应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。 测试用例应由测试输入数据和对应的预期输出结果这两部分组成。 程序员应避免检查自己的程序。 在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。,软件测试的原则,充分注意测试中的群集现象。经验表明，测试后程序中残存的错误数目与该程序中已发现的错误数目成正比。 严格执行测试计划，排除测试的随意性。 应当对每一个测试结果做全面检查。 妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。,软件测试的对象,软件测试并不等于程序测试。软件测试应贯穿于软件定义与开发的整个期间。 需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应成为软件测试的对象。,测试方法,两种常用的测试方法 黑盒测试 白盒测试,黑盒测试,这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。 黑盒测试又叫做功能测试或数据驱动测试。,黑盒测试,黑盒测试方法是在程序接口上进行测试，主要是为了发现以下错误: 是否有不正确或遗漏了的功能? 在接口上，输入能否正确地接受? 能否输出正确的结果? 是否有数据结构错误或外部信息(例如数据文件)访问错误? 性能上是否能够满足要求? 是否有初始化或终止性错误?,黑盒测试,用黑盒测试发现程序中的错误，必须在所有可能的输入条件和输出条件中确定测试数据，来检查程序是否都能产生正确的输出。 但这是不可能的。,黑盒测试,假设一个程序P有输入量X和Y及输出量Z。在字长为32位的计算机上运行。若X、Y取整数，按黑盒方法进行穷举测试： 可能采用的 测试数据组： 232×232264 如果测试一组数据需要1毫秒，一年工作365×24小时，完成所有测试需5亿年。,白盒测试,此方法把测试对象看做一个透明的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。 通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。,白盒测试,软件人员使用白盒测试方法，主要想对程序模块进行如下的检查： 对程序模块的所有独立的执行路径至少测试一次； 对所有的逻辑判定，取“真”与取“假”的两种情况都至少测试一次； 在循环的边界和运行界限内执行循环体； 测试内部数据结构的有效性。 对一个具有多重选择和循环嵌套的程序，不同的路径数目可能是天文数字。,测试用例是软件测试的核心,如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。 测试用例是测试工作的指导，是软件测试的必须遵守的准则。更是软件测试质量稳定的根本保障。,什么是测试用例,所谓的测试用例就是将软件测试的行为活动，做一个科学化的组织归纳。 软件测试是有组织性、步骤性和计划性的，而设计软件测试用例的目的，就是为了能将软件测试的行为转换为可管理的模式。 软件测试是软件质量管理中最实际的行动，同时也是耗时最多的一项。 基于时间因素的考虑，软件测试行为必须能够加以量化，才能进一步让管理阶层掌握所需要的测试过程，而测试用例就是将测试行为具体量化的方法之一。,什么是测试用例,因为我们不可能进行穷举测试，为了节省时间和资源、提高测试效率，必须要从数量极大的可用测试数据中精心挑选出具有代表性或特殊性的测试数据来进行测试。 目前研究室测试过程中，所有的测试用例都放在测试大纲中，使用测试大纲的好处： 保证测试功能不被遗漏； 使得功能不被重复测试，合理安排测试人员； 使得软件测试不依赖于个人；,测试用例内容,实施一次测试而向被测系统提供的输入数据、操作或各种环境设置。 对交互式系统，软件交互执行过程的控制也是一种测试用例。 测试用例的设计与生成是依据测试大纲对其中每个测试项目的进一步实例化。比如： 对于一个输入项的测试，应当设计一组测试数据，包括合法的、边界的和非法的数据等。,测试用例设计生成的基本准则,测试用例的代表性：能够代表并覆盖各种合理的和不合理、合法的和非法的、边界的和越界的、以及极限的输入数据、操作和环境设置等; 测试结果的可判定性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果； 测试结果的可再现性：即对同样的测试用例，系统的执行结果应当是相同的。,测试用例的特征,最有可能抓住错误的； 不是重复的、多余的； 一组相似测试用例中最有效的； 不要太简单，也不要太复杂。,测试用例的组织和跟踪,在执行测试过程中，会遇到如下问题： 计划执行哪些测试用例？执行需要多少时间？一轮测试需要多少测试人员？ 能否挑出测试套装（相关测试用例子集）来测试某些特性或软件部分？ 在执行测试用例时，能否记录哪些通过？哪些失败； 当前测试是否按计划进行？ 上次执行测试用例时通过的百分比是多少？ 测试用例跟踪管理方式：测试用例追踪表,测试用例的意义,使用测试用例的好处主要体现在以下几个方面： 在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。 测试用例的使用令软件测试的实施重点突出、目的明确。 在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期。 功能模块的通用化和复用化使软件易于开发，而相对于功能模块的测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精化其效率也不断攀升。,测试用例的意义,组织性有利于测试的组织； 功能覆盖确保功能不被遗漏； 重复性有利于测试的重复； 跟踪有利于测试的跟踪； 测试确认在少数高风险的测试中，必须证明确实执行了计划执行的测试；,黑盒测试用例的设计方法,具体的黑盒测试用例设计方法包括等价类划分法、边界值分析法、场景法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法等。 这些方法是比较实用的，但采用什么方法，在使用时自然要针对开发项目的特点对方法加以适当的选择。,等价类划分法,等价类划分是一种典型的黑盒测试方法，用这一方法设计测试用例完全不考虑程序的内部结构，只根据对程序的需求和说明，即需求规格说明书。 由于穷举测试工作量太大，以致于无法实际完成，促使我们在大量的可能数据中选取其中的一部分作为测试用例。,等价类划分法,等价类划分法是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据当作测试用例。 每一类的代表性数据在测试中的作用等价于这一类中的其他值，也就是说，如果某一类中的一个例子发现了错误，这一等价类中的其他例子也能发现同样的错误；反之，如果某一类中的一个例子没有发现错误，则这一类中的其他例子也不会查出错误。 使用这一方法设计测试用例，首先必须在分析需求规格说明的基础上划分等价类，列出等价类表。,划分等价类和列出等价类表,可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据取得较好的测试结果。 等价类划分有两种不同的情况： 有效等价类：是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。 无效等价类：与有效等价类的定义恰巧相反。 设计测试用例时，要同时考虑这两种等价类。因为软件不仅要能接收合理的数据，也要能经受意外的考验。这样的测试才能确保软件具有更高的可靠性。,确定等价类的原则,在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。 在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可以确立一个有效等价类和一个无效等价类。 在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。 在规定了输入数据的一组值(假定n个)，并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。 在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)。 在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小的等价类。,建立等价类表,在确立了等价类之后，建立等价类表，列出所有划分出的等价类：,确定测试用例,根据已列出的等价类表，按以下步骤确定测试用例： 为每个等价类规定一个唯一的编号； 设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步，最后使得所有有效等价类均被测试用例所覆盖； 设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步使所有无效等价类均被覆盖。,举例,根据下面给出的规格说明，利用等价类划分的方法，给出足够的测试用例。 “一个程序读入3个整数，把这三个数值看作一个三角形的3条边的长度值。这个程序要打印出信息，说明这个三角形是不等边的、是等腰的、还是等边的。”,举例,我们可以设三角形的3条边分别为A，B，C。如果它们能够构成三角形的3条边，必须满足： A0，B0，C0，且A+BC，B+CA，A+CB。 如果是等腰的，还要判断A=B，或B=C，或A=C。 如果是等边的，则需判断是否A=B，且B=C，且A=C。,举例,举例,边界值分析法,由测试工作的经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。 边界值分析是一种补充等价划分的测试用例设计技术，它不是选择等价类的任意元素，而是选择等价类边界的测试用例。实践证明为检验边界附近的处理专门设计测试用例，常常取得良好的测试效果。,边界值设计原则,对边界值设计测试用例，应遵循以下几条原则： 如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。 如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少一、比最大个数多一的数作为测试数据。 根据规格说明的每个输出条件，使用前面的原则1。 根据规格说明的每个输出条件，应用前面的原则2。 如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。 如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例。 分析规格说明，找出其他可能的边界条件。,其他一些边界条件,另一种看起来很明显的软件缺陷来源是当软件要求输入时(比如在文本框中),不是没有输入正确的信息，而是根本没有输入任何内容，单单按了Enter键。这种情况在产品说明书中常常忽视，程序员也可能经常遗忘，但是在实际使用中却时有发生。程序员总会习惯性的认为用户要么输入信息，不管是看起来合法的或非法的信息，要不就会选择Cancel键放弃输入，如果没有对空值进行好的处理的话，恐怕程序员自己都不知道程序会引向何方。 正确的软件通常应该将输入内容默认为合法边界内的最小值或者合法区间内某个合理值，否则返回错误提示信息。 因为这些值通常在软件中进行特殊处理，所以不要把它们与合法情况和非法情况混在一起，而要建立单独的等价区间。,场景法,现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。 提出这种测试思想的是Rational 公司，并在RUP2000 中文版当中有其详尽的解释和应用。 用例场景用来描述流经用例的路径，从用例开始到结束遍历这条路径上所有基本流和备选流。,基本流和备选流,右图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。备选流用不同的彩色表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流 1 和 3）；也可能起源于另一个备选流（如备选流 2），或者终止用例而不再重新加入到某个流（如备选流 2 和 4）。,基本流和备选流,按照上图中每个经过用例的路径，可以确定以下不同的用例场景： 场景 1 基本流 场景 2 基本流 备选流 1 场景 3 基本流 备选流 1 备选流 2 场景 4 基本流 备选流 3 场景 5 基本流 备选流 3 备选流 1 场景 6 基本流 备选流 3 备选流 1 备选流 2 场景 7 基本流 备选流 4 场景 8 基本流 备选流 3 备选流 4 注：为方便起见，场景 5、6 和 8 只考虑了备选流 3循环执行一次的情况。,测试方法选择的综合策略,测试用例的设计方法不是单独存在的，具体到每个测试项目里都会用到多种方法，每种类型的软件有各自的特点，每种测试用例设计的方法也有各自的特点，针对不同软件如何利用这些黑盒方法是非常重要的，在实际测试中，往往是综合使用各种方法才能有效提高测试效率和测试覆盖度，这就需要认真掌握这些方法的原理，积累更多的测试经验，以有效提高测试水平。,测试方法选择的综合策略,以下是各种测试方法选择的综合策略，可在实际应用过程中参考。 首先进行等价类划分，包括输入条件和输出条件的等价划分，将无限测试变成有限测试，这是减少工作量和提高测试效率的最有效方法。 在任何情况下都必须使用边界值分析方法。经验表明用这种方法设计出测试用例发现程序错误的能力最强。 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，应当再补充足够的测试用例。 对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程，在案例中综合使用各种测试方法。,测试用例的编写,测试用例的编写可以参考研究室规范和模板文档 软件测试大纲编写指南 软件测试大纲模板,谢 谢！,