软件测试案例教程课件作者周元哲第二章节软件测试基本.pptVIP

确认测试 集成测试完成以后，分散开发的模块被联接起来，构成一个完整的程序。其中各模块之间接口存在的种种问题都已消除。于是进入了确认测试阶段。 所谓确认测试，是对照软件需求规格说明书，对软件产品进行评估以确定其是否满足需求规格的过程。 经过确认测试，应该为已开发的软件做出结论性的评价。这无非是两种情况之中： （1）经过检验，软件功能、性能及其它要求都已满足需求规格说明书的规定，是一个合格的软件。 （2）经过检验，发现与需求说明书有相当的偏离，我们得到一个缺陷清单，这就需要开发部门和顾客进行协商，找出解决的办法。 确认任务 确认是指决定最后的软件产品是否正确无误。比如，开发的软件是否符合软件需求规格说明和用户要求，输出的信息是否是用户想要的信息，在将来的实际使用环境中能否正确稳定地运行，是否存在隐患等，这自然包含了对它在功能、性能、接口以及限制条件等方面满足需求程度的评价。 测试覆盖 测试覆盖用来衡量软件产品的被测程度 测试覆盖分为：需求覆盖、功能覆盖和逻辑覆盖。 逻辑覆盖很重要，因为： 1）逻辑覆盖可以间接地提高功能覆盖； 2）对逻辑路径的测试是必要的，而逻辑路径一般无法从外部功能看出来。 逻辑覆盖包括：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖和路径覆盖，最常用、最简单的形式是语句覆盖，即覆盖被测程序中语句的百分比。 基于需求的测试：采用黑盒测试策略，在不知道详细设计规格说明或代码的情况下对用户需求进行测试。基于需求的测试根据功能设计规格说明设计测试用例。 基于功能的测试：采用黑盒策略，根据功能设计规格说明，采用等价类划分、边界值分析和故障猜测等方法设计测试用例。 基于内部的测试：只能采用白盒测试策略，但可采用功能设计规格说明制订测试计划。一但采用白盒测试，便可通过一系列的技术确保系统的内部各部分获得充分的测试并且达到足够的逻辑覆盖。 确认测试策略 ● 测试是为了发现故障， 而不是为了显示故障不存在。 ● 测试最困难的问题之一是不知道何时终止测试。 ● 避免使用未经计划、不能重复使用且用后即扔的测试用例。 ● 测试用例的一个重要组成部分是预期输出或结果，仔细比较每一次测试执行的实际结果和预期结果。 ● 测试用例必须考虑有效、无效、预期和非预期的输入条件。 ● 经验较少的测试人员倾向于只从输入角度设计测试用例。经验丰富的测试人员能够生成预期输出所要求的输入。 实施确认测试时应考虑的基本原则： 确认测试活动可以分为：低层测试和高层测试 1.低层测试 低层测试涉及对程序的各个单元或模块进行测试，包括单元测试和集成测试。 单元测试 集成测试 综合测试策略 高层测试涉及对整个产品的测试。为保证测试的客观性，测试最好在开发组织之外由独立的测试机构进行。高层测试的形式包括： 可用性测试 功能测试试 系统测试 验收测试 高层测试 回归测试 回归测试则是对程序进行测试以确定是否因故障修复而引入了新的故障。 回归测试不是一种新的测试活动，它是为检查是否因修复故障引入了新的故障而重新执行某些或所有测试用例的过程。 软件测试模型 软件测试模型是软件测试工作的框架，描述了软件测试过程所包含的主要活动，这些活动之间的相互关系等。目前的软件测试模型主要有 V模型 W模型 H模型 X模型 前置模型 V模型 　　　V模型反映了测试活动与分析和设计的关系，明确标明了测试过程中存在的不同级别，并清楚描述测试的各个阶段和开发过程的各个阶段之间的对应关系。V模型左侧是开发阶段，右侧是测试阶段。开发阶段先从定义软件需求开始，然后把需求转换为概要设计和详细设计，最后形成程序代码。测试阶段是在代码编写完成以后，先作单元测试开始，然后是集成测试、系统测试和验收测试。 优点：自底向上测试方法不需要桩模块，测试用例的设计亦相对比较简单,也不存在还没把前面的模块完全测试却又开始测试另一模块的问题。如果关键的模块是在结构图的底部，自底向上测试具有一定的优越性。 缺点：在测试初期不能呈现出被测软件系统的轮廓。实际上，直到最后一个模块(模块M1)加入时才具有整体形象，才能形程完整的程序。 集成方法 优点 缺点 自顶向下测试 如果主要故障发生在程序的顶端时，有利于查出故障。 一旦加入I/O功能，测试用例易于形成。 初期的程序轮廓可以让人们看到程序的功能，增强信心 需要桩模块。 在I/O功能加入以前，很难描述测试用例。 很难观察测试输出。 使人想推迟完成某些模块的测试。 自底向上测试 如果主要故障发生在程序的底端时，有利于查出故障。 测试用例生成容易。 观察测试结果容易。 需要驱动程