软件测试的相关概念.ppt

1、1,软件测试的相关概念,2,主要内容,测试的目的 测试原则 测试的对象 测试的流程 测试步骤 测试的类型 测试用例 缺陷报告,3,测试的目的,根本目的 发现软件的缺陷。软件测试是为了发现错误而执行程序的过程; 测试是为了证明程序有错，而不是证明程序无错误;一个好的测试用例是在于它能发现至今未发现的错误;一个成功的测试是发现了至今未发现的错误的测试。 相关目标 评估软件是否满足的用户的需求 阻止没有成熟的软件发布 可以减少技术支持的费用 评估软件的质量、验证产品的正确性、保证产品的质量 最大化bug的数量 保证bug已经修改,4,测试的目的,从用户的角度出发，就是希望通过软件测试能充分暴露软件中

2、存在的问题和缺陷，从而考虑是否可以接受该产品。 从开发者的角度出发，就是希望测试能表明软件产品不存在错误，已经正确地实现了用户的需求 想以最少的时间和人力，系统地找出软件中潜在的各种错误和缺陷。注：测试完成不能表明软件中不存在错误，它只能说明软件中存在错误。,5,软件测试的原则,应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。 测试用例应由测试输入数据和对应的预期输出结果这两部分组成。 程序员应避免检查自己的程序。 在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。,6,软件测试的原则,充分注意测试中的群集现象。测试后程序中残存的错误数目与该程序中已发现的错误数目成正比。

3、 严格执行测试计划，排除测试的随意性。 应当对每一个测试结果做全面检查。 妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。,7,测试的对象,软件测试并不等于程序测试。软件测试应贯穿于软件定义与开发的整个期间。 需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应成为软件测试的对象。,8,测试的流程,前期准备 测试组与开发组协调，包括项目测试流程约定，测试组与开发组的协作活动安排等。在项目前期，规划好测试组与开发组的协调工作，可以让测试人员与项目开发人员彼此了解在测试活动中的职责。项目的客户需求、项

4、目本身要求、明确测试范围、测试指标、测试要点、测试所需软硬件环境等，为制定测试计划打好基础。 制定测试计划 主要包括测试软硬件资源，人力资源，测试指标，粗略进度，采集的度量数据，风险，约定等。,9,测试流程,编制测试用例 了解项目需求（客户需求与项目需求）、明确公共用例、明确手动测试用例与自动化测试用例范围、确定用例编写进度、正式编写、用例验证、明确测试用例执行顺序。 实施测试 确定实施进度、搭建测试环境、执行测试用例，记录用例执行结果，报告缺陷、记录度量数据、维护测试用例。 测试总结 测试停止评估（参照测试用例执行情况，缺陷收敛情况，与测试指标偏差情况等）、测试总结报告、提交汇总度量数据、保

5、存测试文档。,10,测试方法,两种常用的测试方法 黑盒测试 白盒测试 灰盒测试,11,测试的步骤,单元测试 集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。 集成测试 测试过的模块组装起来，主要对与设计相关的软件体系结构的构造进行测试。 系统测试 已经经过确认的软件纳入实际运行环境中，与其它系统成份组合在一起进行测试。 确认测试 要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确 发版测试 测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。 测试是由软件的多个用户在实际使用环

6、境下进行的测试。这些用户返回有关错误信息给开发者。,12,测试类型,功能测试 性能测试 恢复测试 配置测试 安全性测试 易用性测试 . 安装测试 容量测试 文档测试 冒烟测试 随机测试,13,测试用例是软件测试的核心,如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质。 测试用例是测试工作的指导，是软件测试的必须遵守的准则。更是软件测试质量稳定的根本保障。,14,什么是测试用例,所谓的测试用例就是将软件测试的行为活动，做一个科学化的组织归纳。 软件测试是有组织性、步骤性和计划性的，而设计软件测试用例的目的，就是为了能将软件测试的行为转换为可管理的模式。

7、基于时间因素的考虑，软件测试行为必须能够加以量化，才能进一步让管理阶层掌握所需要的测试过程，而测试用例就是将测试行为具体量化的方法之一。 因为我们不可能进行穷举测试，为了节省时间和资源、提高测试效率，必须要从数量极大的可用测试数据中精心挑选出具有代表性或特殊性的测试数据来进行测试。,15,测试用例的作用,通过一个用例来证明被测软件的某功能符合需求说明书中规定的要求 可以保证一个软件被测试的有效性，使测试人员知道那些功能以被测，那些功能还需要测试，从而避免漏测，重复测，提高测试效率 指导测试的工作，保证测试是有计划的实施，而不是随意性的测试 为公司留下财富，为后期软件维护提高帮助，为公司新人进来

8、提供指导，在测试的时候可以尽量把人为因素的影响减少到最小。保障软件测试质量的稳定。 可以做为评估测试结果的，为编写测试报告提供依据。 提高测试的质量。分析bug的标准，通过收集的bug，对比测试用例和bug数据库，分析确证是漏测还是bug复现。漏测反映了测试用例的不完善，应立即补充相应测试用例，逐步的提高测试质量。而已有相应测试用例，则反映实施测试或变更处理存在问题。,16,测试用例的内容,介绍部分：可以有这些：公司名称，保密等级，编写人员，日期，审核人，版本号，测试对象的介绍，测试的范围和目的，测试环境，定义术语，参考文档，用例执行情况，测试用例设计思路等 测试用例部分：模块名称，测试类型，

9、用例ID，用例目的，重要程度，测试过程分为（前提条件，测试步骤，期望结果，测试结果，测试结论）测试日期，备注。,17,测试用例生成的基本准则,测试用例的代表性能够代表并覆盖各种合理的和不合理、合法的和非合法的、边界的和越界的、以及极限的输入数据、操作和环境设置等； 测试结果的可判定性即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果； 测试结果的可再现性即对同样的测试用例，系统的执行结果应当是相同的。,18,测试用例的特征,最有可能抓住错误的； 不是重复的、多余的； 一组相似测试用例中最有效的； 不要太简单，也不要太复杂。,19,测试用例的意义,使用测试用例的好处主要体现在以

10、下几个方面： 在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。 测试用例的使用令软件测试的实施重点突出、目的明确。 在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期。 功能模块的通用化和复用化使软件易于开发，而相对于功能模块的测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精化其效率也不断攀升。,20,黑盒测试用例的设计方法,具体的黑盒测试用例设计方法包括等价类划分法、边界值分析法、场景法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法等。 这些方法是比较实用的，但采用什么方法，在使用时自然要针对开发项目的

11、特点对方法加以适当的选择。,21,等价类划分法,等价类划分是一种典型的黑盒测试方法，用这一方法设计测试用例完全不考虑程序的内部结构，只根据对程序的需求和说明，即需求规格说明书。 由于穷举测试工作量太大，以致于无法实际完成，促使我们在大量的可能数据中选取其中的一部分作为测试用例。,22,等价类划分法,等价类划分法是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据当作测试用例。 每一类的代表性数据在测试中的作用等价于这一类中的其他值，也就是说，如果某一类中的一个例子发现了错误，这一等价类中的其他例子也能发现同样的错误；反之，如果某一类中的一个例子没有发现错误，则这一类中的其他例子也

12、不会查出错误。 使用这一方法设计测试用例，首先必须在分析需求规格说明的基础上划分等价类，列出等价类表。,23,划分等价类和列出等价类表,可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据取得较好的测试结果。 等价类划分有两种不同的情况： 有效等价类：是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。 无效等价类：与有效等价类的定义恰巧相反。 设计测试用例时，要同时考虑这两种等价类。因为软件不仅要能接收合理的数据，也要能经受意外的考验。这样的测试才能确保软

13、件具有更高的可靠性。,24,确定等价类的原则,在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。 在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可以确立一个有效等价类和一个无效等价类。 在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。 在规定了输入数据的一组值(假定n个)，并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。 在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)。 在确知已划分的等价类中各元素在程序处理中的方式不同

14、的情况下，则应再将该等价类进一步地划分为更小的等价类。,25,建立等价类表,在确立了等价类之后，建立等价类表，列出所有划分出的等价类：,26,确定测试用例,根据已列出的等价类表，按以下步骤确定测试用例： 为每个等价类规定一个唯一的编号； 设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步，最后使得所有有效等价类均被测试用例所覆盖； 设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步使所有无效等价类均被覆盖。,27,举例,根据下面给出的规格说明，利用等价类划分的方法，给出足够的测试用例。 “一个程序读入3个整数，把这三个数值看作一个三角形的3条边的长度值。这个程序要

15、打印出信息，说明这个三角形是不等边的、是等腰的、还是等边的。”,28,举例,我们可以设三角形的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。,29,举例,30,举例,31,边界值分析法,由测试工作的经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。 边界值分析是一种补充等价划分的测试用例设计技术，它不是选择等价类的任意元素，而是选择等价类

16、边界的测试用例。实践证明为检验边界附近的处理专门设计测试用例，常常取得良好的测试效果。,32,边界值设计原则,对边界值设计测试用例，应遵循以下几条原则： 如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。 如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少一、比最大个数多一的数作为测试数据。 根据规格说明的每个输出条件，使用前面的原则1。 根据规格说明的每个输出条件，应用前面的原则2。 如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。 如果程序中使用了一个内部数据结构，则

17、应当选择这个内部数据结构的边界上的值作为测试用例。 分析规格说明，找出其他可能的边界条件。,33,其他一些边界条件,另一种看起来很明显的软件缺陷来源是当软件要求输入时(比如在文本框中),不是没有输入正确的信息，而是根本没有输入任何内容，单单按了Enter键。这种情况在产品说明书中常常忽视，程序员也可能经常遗忘，但是在实际使用中却时有发生。程序员总会习惯性的认为用户要么输入信息，不管是看起来合法的或非法的信息，要不就会选择Cancel键放弃输入，如果没有对空值进行好的处理的话，恐怕程序员自己都不知道程序会引向何方。 正确的软件通常应该将输入内容默认为合法边界内的最小值或者合法区间内某个合理值，否

18、则返回错误提示信息。 因为这些值通常在软件中进行特殊处理，所以不要把它们与合法情况和非法情况混在一起，而要建立单独的等价区间。,34,场景法,现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。 提出这种测试思想的是Rational 公司，并在RUP2000 中文版当中有其详尽的解释和应用。 用例场景用来描述流经用例的路径，从用例开始到结束遍历这条路径上所有基本流和备选流。,35,基

19、本流和备选流,右图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。备选流用不同的彩色表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流 1 和 3）；也可能起源于另一个备选流（如备选流 2），或者终止用例而不再重新加入到某个流（如备选流 2 和 4）。,36,基本流和备选流,按照上图中每个经过用例的路径，可以确定以下不同的用例场景： 场景 1 基本流 场景 2 基本流 备选流 1 场景 3 基本流 备选流 1 备选流 2 场景 4 基本流 备选流 3 场景 5 基本流 备选流 3 备选流 1 场景 6 基本流 备选流

20、 3 备选流 1 备选流 2 场景 7 基本流 备选流 4 场景 8 基本流 备选流 3 备选流 4 注：为方便起见，场景 5、6 和 8 只考虑了备选流 3循环执行一次的情况。,37,测试方法选择的综合策略,测试用例的设计方法不是单独存在的，具体到每个测试项目里都会用到多种方法，每种类型的软件有各自的特点，每种测试用例设计的方法也有各自的特点，针对不同软件如何利用这些黑盒方法是非常重要的，在实际测试中，往往是综合使用各种方法才能有效提高测试效率和测试覆盖度，这就需要认真掌握这些方法的原理，积累更多的测试经验，以有效提高测试水平。,38,Bug报告,目的 当我们发现一个缺陷时，我们需要把它告诉

21、给开发人员。Bug报告就是这种沟通的 媒介物。Bug报告的主要目的是让开发人员亲眼看到这个错误。如果你不能和他一起以在他面前制造出那个失败，那么就需要给他们足够多的指引以便他们能够自己制造 出那个失败。Bug报告就是解释在期望结果和实际结果之间的差距并且详细的说明如何重现那个场景。,39,Bug报告的内容,题目 步骤 Bug的出现环境 测试数据 测试结果（截屏） 严重程序/优先级别 其他信息,40,测试人员所应具备的能力,技术能力 自信心 沟通能力 移情能力 很强的记忆力 耐心 怀疑精神 自我督促,41,关于软件测试的误区,误区之一：软件开发完成后进行软件测试 误区之二：软件发布后如果发现质量

22、问题，那是软件测试人员的错 误区之三：软件测试要求不高，随便找个人多都行 误区之四：软件测试是测试人员的事情，与程序员无关 误区之五：项目进度吃紧时少做些测试，时间富裕时多做测试 误区之六：软件测试是没有前途的工作，只有程序员才是软件高手,42,参考资料,软件测试作者：（美）Ron Patton 译者：周予滨 姚静 出版社：机械工业出版社 软件测试作者：美Paul C.Jorgensen 译者：韩柯 杜旭涛 出版社：机械工业出版社 计算机软件测试技术作者：郑人杰 出版社：清华大学出版社 软件测试艺术 作者：Glenford J.Myers等著 译者：王峰 陈杰等/译 出版社：机械工业出版社 软件测试自动化 作者：Daniel J.Mosley, Bruce A.Posey/著 译者：邓波 黄丽娟 曹青春等/译 出版社：机械工业出版社 有效软件测试 作者：美Elfriede Dustin/著 译者：新语/译 出版社：清华大学出版社,43,参考资料, http:/ http:/ http:/