软件测试理论基础

《软件测试理论基础》由会员分享，可在线阅读，更多相关《软件测试理论基础（39页珍藏版）》请在金锄头文库上搜索。

1、软件测试理论基础,概述,软件测试定义 软件测试目标 软件测试对象 软件测试原则 软件测试方法 软件生命周期 软件测试流程 软件测试评测方法 建议,软件测试定义,定义一：使用人工和自动化的手段来运行或测试某个系统的过程,其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。 定义二：软件测试是贯穿整个软件开发生命周期、对软件产品（包括阶段性产品）进行验证和确认的活动过程。 验证：是为确定某一开发阶段的产品是否满足在该阶段开始时提出的要求而对系统或部件进行评估的过程。 确认：是在开发过程中或结束时，对系统或部件进行评估，以确定其是否满足需求规格的过程。 定义三：软件测试是根据软件

2、开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例，并利用这些测试用例运行软件，以发现软件错误的过程。,软件测试目标,第一：确保软件的质量 第二：提供信息 第三：保证整个软件开发过程是高质量的,软件测试对象,软件测试的对象不仅仅是程序，还包括整个软件生命周期中产生的所有过程文档。 如： 在软件定义阶段产生的可行性报告、项目实施计划、软件需求说明书或系统功能说明书， 在软件开发阶段产生的概要设计说明书、详细设计说明书，以及源程序等。,软件测试原则,一、尽早和不断地进行测试 二、遵循Pareto原则 三、软件测试是不完全的 四、并非所有的软件错误都能修复 五、由小到大的测试范围 六、避免由

3、开发人员测试自己的程序 七、追溯至用户需求 八、程序修改后要回归测试 九、妥善保存一切测试过程文档,软件测试方法,软件测试方法,软件测试方法,静态测试：不实际运行被测软件，而只是静态地检查程序代码、界面或文档中可能存在的错误的过程。 动态测试：实际运行被测软件，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。,软件测试方法,软件测试方法,功能测试：主要检查实际软件的功能是否符合用户的需求。 功能测试又可细分为： 逻辑功能测试：假设一个软件的业务流程是，如果输入1就走A流程，输入2，走B流程，输入3，退出。那对于测试人员来说，输入1到3就是不同的逻辑，你也可以输入0，4，来检验程序

4、是否有做保护处理。 界面测试：验证软件用户界面的设计是否合乎用户期望或要求。它常常包括菜单，对话框及对话框上所有按钮，文字，出错提示，帮助信息等方面的测试。 易用性测试：从软件使用的合理性和方便性等角度对软件系统进行检查，来发现软件中不方便用户使用的地方。 安装测试：是验证软件能否正常进行安装和卸载的测试。 兼容性测试：是测试软件在一个特定的硬件/软件/操作系统/网络等环境下的性能如何。包括向上兼容、向下兼容，软件兼容和硬件兼容。,软件测试方法,性能测试：主要是验证系统的性能指标是否满足需求要求。 性能测试又可细分为： 一般性测试：指的是让被测系统在正常的软硬件条件下运行，不向其施加任何压力。

5、 稳定性测试：也叫可靠性测试，是指连续运行被测系统，检查系统运行时的稳定程度。 负载测试：指让被测系统在其能忍受的压力的极限范围内连续运行，检查系统运行时的稳定性。 压力测试：通常是指持续不断地给被测系统增加压力，直到将被测系统压垮为止，用来测试系统所能承受的最大压力。,软件测试方法,回归测试：是在软件维护阶段，重复执行上一个版本测试时的测试用例，对修改后的新版本进行的测试。其目的是检验对软件所做的修改是否正确。 冒烟测试：是指在对一个新版本进行系统的大规模测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。 随机测试：是指测试中所有的输入数据都是随机生成的，其目的是模拟用户的真实操作

6、，并发现一些边缘性的错误。,软件生命周期,软件生命周期：即一个软件从功能确定、设计、开发成功、投入使用，并在使用中不断的修改、增补和完善，直至被新的需要替代而停止使用的全过程。 软件生命周期包括软件开发的生命周期和软件测试的生命周期。 软件生命周期模型是软件项目的流程模版，为制定项目流程提供参考依据。,软件生命周期,瀑布模型优点： 1、强调开发的阶段性，各阶段具有顺序性和依赖性 2、推迟编码实现的观点，主张早期调研和需求分析 3、质量保证的观点，要求每个阶段的产品都应在评审之后才能流入下一阶段，作为下一阶段的输入 4、“线性”逻辑容易掌握及应用 5、可在复杂的非线性模型中应用 瀑布模型缺点：

7、1、文档驱动，用户无法及时了解产品的情况 2、当需求变更时将会导致阶段反复，而且都要重复需求、设计、编码、测试等过程。 3、流程单一，不可逆 4、早期的错误可能要等到开发后期的测试阶段才能发现，无法全面的保证质量，控制风险 5、严格线性运行，无法在人员、工作量分配上实现最优搭配，严重影响工作效率和进度 瀑布模型适用范围：需求稳定的产品,软件生命周期,V模型优点： 1、明确地标明了测试过程中存在的不同级别 2、清楚地表示出测试阶段和开发过程各阶段的对应关系 3、强调了测试过程与开发过程的并行性 V模型缺点： 1、没有说明项目的前期测试需要做哪些工作，如编写测试计划、测试用例等 2、把系统开发过程

8、划分为具有固定边界的不同阶段，很难跨过这些边界来采集测试所需要的信息,软件生命周期,渐进模型优点： 1、设计上的灵活性,可以在项目的各个阶段进行变更 2、关键的功能更早出现，随着项目推进,客户始终掌握项目的最新信息，可以提高开发人员与客户之间的有效信息交互 3、用户在整个软件开发过程中都直接参与，因此最终的产品能够很好地满足用户的需求 4、以小的分段来构建大型系统,使成本计算和风险控制变得简单容易 渐进模型缺点： 由于过多的开发周期会增加成本，耗费时间 渐进模型适用范围： 开发初期用户需求不甚明确 相关技术和理论需要不断研究、反复实验 开发过程需要经常与用户交互的产品,软件测试流程,需求评审

9、测试计划 测试设计 测试前期准备 测试执行 缺陷管理 测试报告 测试评测,软件测试流程-需求评审,需求评审的注意事项： 一、 注意对需求规格说明的正确性进行评审 1、是否冲突或者重复 2、是否清晰、简洁、无二义性 3、是否有内容和语法错误 4、是否合理地确定了性能指标 5、是否合理地确定了安全性指标 二、 注意对需求规格说明的完整性进行评审 1、是否包含了所有已知的客户需求或系统需求 2、所有需求的详细程度是否合适，是否能为设计提供足够的基础 3、是否定义了每个需求的实现优先级 4、是否把不确定的需求标记为待确定的问题， 而不是直接遗弃 5、是否对所有预期的错误条件所产生的系统行为都进行了描述

10、 三、 注意对需求的可实施性进行评审 1、是否每个需求都有惟一标识 2、是否每个需求都易修改，可跟踪 3、是否每个需求都是实际的、量化的、逻辑清晰的 4、在现有的资源下, 是否能实现所有的需求 5、每个需求在特定的输入条件下是否给出已知的输出结果 测试人员参加“需求评审”活动需要达到的目标： 1、充分理解用户需求 2、确保需求的可测试性,软件测试流程-测试计划,为什么要编写测试计划 1）领导能够根据测试计划做宏观调控，进行相应资源配置等 2）测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等 3）便于其他人员了解测试人员的工作内容，进行有关配合工作 什么时间开始编写测试计划

11、 尽早开始。原则上应该在需求定义完成之后开始编写测试计划，对于开发过程不是十 分清晰和稳定的项目，测试计划也可以在总体设计完成后开始编写 由谁编写测试计划 具有丰富经验的测试负责人 测试计划编写策略 1. 明确测试的目标，增强测试计划的实用性 2. 坚持“5W1H”规则，明确内容与过程 1）why为什么要进行这些测试 2) what测试哪些方面，不同阶段的工作内容 3) who安排哪些测试人员进行测试 4) when测试不同阶段的起止时间 5) where给出测试文档和软件的存放位置，测试环境等 6) how指出测试的方法和工具 3. 采用评审和更新机制，保证测试计划满足实际需求 4. 分别创

12、建测试计划与测试详细规格、测试用例,软件测试流程-测试设计,过程：,软件测试流程-测试设计,测试用例是为某个特殊目标而编制的一组测试输入、执行条件、测试步骤以及预期结果。 为什么要写测试用例 1）便于团队交流 2）便于重复测试 3）便于跟踪统计 4）便于用户自测 什么时候写测试用例：通常在测试设计阶段，即需求规格说明书和测试计划完成之后 由谁来写测试用例：测试设计人员 测试用例编写依据：需求规格说明书和软件原型 测试用例包含的内容：用例编号、用例名称、测试等级、入口准则、验证步骤、期望结果（含判断标准）、出口准则、注释 最佳方案：为每个被测需求至少编制两个测试用例：正面测试用例和负面测试用例,

13、软件测试流程-测试设计,（一）白盒技术 1、逻辑覆盖：是通过对程序逻辑结构的遍历实现程序的覆盖 (1)语句覆盖：设计足够多的测试用例，使被测程序中每条语句至少执行一次 (2)判定覆盖：设计足够多的测试用例，使得程序中的每一个判定至少获得一次真值和假值 (3)条件覆盖：设计足够多的测试用例，使得每一判定语句中每个逻辑条件的可能值至少满足一次 (4)条件判定组合覆盖：设计足够多的测试用例，使得判定中的每个条件的所有可能（真/假）至少出现一次，并且每个判定本身的判定结果也至少出现一次 (5)条件组合覆盖：设计足够多的测试用例，使得每个判定中条件的各种可能组合都至少出现一次 满足条件组合覆盖一定满足判

14、定覆盖、条件覆盖、条件判定组合覆盖 (6)路径覆盖：设计足够多的测试用例，覆盖被测程序中所有可能的路径 2、循环覆盖：设计足够多的测试用例，覆盖被测程序中所有的循环体 3、基本路径测试：是在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例的方法，设计出的测试用例要保证在测试中程序的每个可执行语句至少执行一次,软件测试流程-测试设计,（二）黑盒技术 1、等价类划分：是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例。 等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中

15、的错误都是等效的，并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试，因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件就可以用少量代表性的测试数据取得较好的测试结果。 等价类划分可有两种不同的情况：有效等价类和无效等价类。 2、边界值分析：对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。 3、错误推测：基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法 4、因果图：是一种帮助人们系统的选择一组高效率测试用例的方法 5、综合策略：

16、每种方法都能设计出一组有用例子，用这组例子容易发现某种类型的错误，但可能不易发现另一类型的错误。因此在实际测试中，联合使用各种测试方法，形成综合策略，通常先用黑盒法设计基本的测试用例，再用白盒法补充一些必要的测试用例,软件测试流程-测试前期准备,明确测试任务的范围 明确测试时间 搭建测试环境 学习被测试软件 确认完全理解测试任务,软件测试流程-测试执行,全方位的观察测试用例执行结果 进行测试过程记录 及时确认发现的问题 及时更新测试用例,软件测试流程-缺陷管理,缺陷： 1）软件未实现需求规格说明书要求的功能 2）软件出现了与需求规格说明书中不一致的情况 3）软件功能超出了需求规格说明书的范围 4）软件没有达到用户期望的目标（未明确提及但应该实现的目标） 5）软件难以理解、不易使用、运行缓慢（从测试人员的角度或最终用户的角度来看）,软件测试流程-缺陷管理,一个完整的软件缺陷报告通常由以下几部分组成 缺陷编号 缺陷的标题 测试的软件和硬件环境 测试的软件版本 缺陷的类型 缺陷的严重程度 缺陷的优先级别 缺陷出现频率 缺陷状态 重现缺陷的操作步骤 缺陷的实际结果描述 期望的正确结果描述 注释及附件,