第二章测试计划.ppt

1,软 件 测 试 技 术,2,第二章 测试计划,2.1 测试计划要点和制订过程2.2 测试软件需求2.3 测试策略 2.4 测试环境 2.5 测试管理 2.6 测试计划编写,3,通过本章的学习，可以：了解软件测试计划的重要性。了解软件测试计划的编写过程和主要内容。了解软件需求应该具有的特征。了解如何对软件需求进行静态测试。学会确定测试策略。学会定义测试环境。对软件测试管理工作有所了解,4,在一个工程活动中，了解需求和制定计划是所有工作的起点。在软件测试工作中，也首先需要分析需求和制定测试计划。,5,软件测试阶段组成,测试计划,测试开发,测试执行,6,2.1.1 为什么要写测试计划 软件测试计划是指导测试过程的纲领性文件。借助软件测试计划，1）领导能够根据测试计划做宏观调控，进行相应资源配置等；2）测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等；3）便于其他人员了解测试人员的工作内容，进行有关配合工作,2.1 测试计划要点和制订过程,7,2.1.2 测试计划内容和要点,一个软件项目的测试计划是一份描述软件测试工作的目标、范围、策略、方法和重点的文档。,8,测试计划编写包括6要素（5W 1H）1）why为什么要进行这些测试；2)what测试哪些方面，不同阶段的工作内容；3)when测试不同阶段的起止时间；4)where相应文档，缺陷的存放位置，测试环境等；5)who项目有关人员组成，安排哪些测试人员进行测试 6)how如何去做，使用哪些测试工具以及测试方法进行测试。,9,测试活动进度综述，可供相关人员参考 测试方法；测试工具，包括如何和何时获取工具；实施测试和报告结果的过程；系统测试进入和结束准则；设计、开发和执行测试所需的人员；,测试计划要点,10,设备资源：需要什么样的机器和测试基准；恰当的测试覆盖率目标；测试所需的特殊软件和硬件配置；测试哪些特性，不测试哪些特性；风险和意外情况计划。,测试计划要点,11,2.1.3 测试计划制订过程,分析和测试软件需求,定义测试策略,定义测试环境,定义测试管理,编写和审核测试计划,12,在编写测试计划时，经过五个步骤：(1)分析和测试软件需求 在需求分析阶段，软件测试人员就需要进入。在这个阶段，测试人员需要对需求有完整的理解，还需要对需求文档进行测试。(2)定义测试策略 测试策略，指的是确定总的测试范围、测试的方法、测试活动的进入/退出标准、自动化测试工具的选择、测试软件的编写等。,13,(3)定义测试环境 测试环境包括软件运行的硬件平台、软件平台，还包括一些特殊的外围设备。在制定测试计划时，需要定义测试工作将在什么样的测试环境中进行。(4)定义测试管理 测试过程中所涉及到的人、活动和工具都是很多的(特别是在大型软件的测试中)，在制定测试计划时，要对这些因素加以管理。,14,(5)编写计划文档 在上述几项工作完成后，需要编写测试计划文档，并需要被相关人员审核。测试计划阶段的原始依据是软件需求文档。测试计划阶段的输出是测试计划文档,15,2.2 分析和测试软件需求,为了编写测试计划和进行测试设计，测试人员需要软件需求说明书，软件需求是设计、编码和测试人员共同的工作起点。,16,需求分析就是完整、准确地定义系统的目标，确定系统必须做什么。在失败的项目中与需求分析相关的原因：不完善的需求分析(13.1)。缺乏用户的参与(12.4)。不切实际的期望值(9.9)。不断变更的需求和说明(8.7)。系统不再被需要(7.5)。51.6%,2.2.1 需求分析过程,17,经统计，一般的，如果在需求分析阶段发现并解决问题花费$1，则在设计阶段解决同样的问题要花费$5，在编码阶段要花费$10，在交付使用后要解决同样的问题需花费$200。测试团队需要清晰、明确、可测试的需求说明书以便开始测试计划和测试设计工作。另一方面，测试团队通过对需求的分析实现对需求的静态测试，尽量在早期发现问题，减小后期修改的代价。因此，测试人员需要在需求分析阶段开始介入测试工作。,18,需求分析需经历五个主要步骤：(1)收集用户需求 通过客户访谈等途径收集客户需求。(2)编写需求定义文档 将客户需求整理并写成需求定义，需求定义文档用自然语言记录所有系统需求，这样用户和系统开发人员比较容易理解沟通。(3)编写软件功能说明 软件功能说明用精确性和技术性语言描述所有系统需求，该文档主要被开发组织使用。,19,(4)编写软件需求跟踪矩阵 其目的是跟踪每一个需求以确保其被实现和测试。(5)审核软件需求文档 在需求文档编写完成后，要进行相应的审核工作。,20,各步骤工作重点：(1)收集用户需求 客户与开发人员的沟通对项目的成功是非常重要的，在沟通过程中客户与开发人员对相互背景知识的欠缺将会限制沟通效果，客户缺乏对软件开发过程的了解，不能用系统开发人员易理解的方式陈述他们的需求。正如设计一个客户的房子，客户没有足够的建筑方面的知识去精确地告诉建筑师自己的需要，因此客户与建筑师之间的沟通可能包括看样板房、图片、演示存在的软件是非常有用的。测试人员通过客户与开发人员沟通后的结果来了解客户准备如何使用软件，并进行验收测试设计。,21,(2)编写需求定义 从测试人员看，需求定义应有如下特点：每个需求应被惟一地标识。当测试人员计划测试覆盖、设计测试用例、报告测试结果时能够清楚地识别需求：需求定义要从用户的角度描述。定义必须包括功能需求和非功能需求。功能需求描述系统要完成的功能，非功能需求描述系统操作中的约束，如系统能够支持的用户数。,22,(3)编写功能说明 功能说明描述的内容与需求定义文档相同，但文档是从系统设计者的角度来书写，由开发团队使用。,23,(4)编写需求跟踪矩阵 必须确定哪些测试用例对应目标功能。需求跟踪矩阵提供下列信息：哪些测试用例检查一个特定的功能。哪些需求没有对应的测试用例。哪些功能仍然需要测试。,24,2.2.2 需求分析中测试人员工作,测试人员必须在需求阶段就进入原因：(1)测试人员需要在了解需求的情况下编写测试计划、测试用例、准备测试环境。(2)需求文档本身也需要被测试人员进行测试。(3)估算工作量，估算项目成本，编写开发计划。如果在此阶段不考虑测试本身的工作量和成本、测试工作需要持续的时间，那么对于整个项目的工作量、成本和时间的估算就会产生很大的偏差。,25,需求分析中测试人员工作理解需求，参与审核需求文档理解项目的目标、限制，了解用户应用背景编写测试计划准备资源包括了人员、资金、设备、工具软件。如果测试人员对所测试的软件应用领域不熟悉，要进行相应的培训。在很多时候，需要购买设备来建立测试环境；,26,2.2.3 软件需求文档 需求文档是进行设计、编码、测试的基础文件，软件需求文档中，需要描述下列内容：说明一般描述各种限制条件、假定和依赖功能需求非功能需求参考 P244,27,1、需求跟踪矩阵 在整个开发过程中，对于需求文档中的每项需求，要确保以下问题：是否完成了相应的设计？是否编写完成了相应的代码？在哪里可以找到这些代码？是否编写完成了相应的单元测试用例？是否进行了单元测试？是否完成了相应的集成测试用例？是否进行了集成测试？需求跟踪矩阵即描述上述问题。,28,对于需求规格RS2.2.4.1，其单元测试、集成测试、系统测试用例分别对应到D2.2.4.1、CC2.2.4.1、UT2.2.4.1、IT2.2.4.1.x、ST2.2.4。在编写测试用例时，就需要根据需求跟踪矩阵里面的编号规则进行标号。,N/A所代表的含义是：对应于此需求，没有对应的单元测试用例(也许是不需要,也许是不打算针对此需求进行单元测试)。,29,2、良好需求文档的特征具有清晰的格式和文档结构需求的内容正确 每个需求必须精确描述要交付的功能 需求的内容完整 不应该遗漏要求和必需的信息，认为有些内容理所当然而未明确写出来。需求具有可行性 如果需求文档中所描述的软件需求在已知的能力、有限的系统及其环境中是不可能实现的，那么相关的需求就没有意义,30,必要性 需求中的每项内容都应该是必要的 对不同的需求的优先等级进行定义 当时间、人力、经费不足时，应该优先完成哪些功能，可以暂时放弃哪些功能?描述明确，无歧义、二义，上下文一致 避免使用一些对于作者很清楚但对于读者不清楚的主观词汇，例如：容易、简单、快速、有效、几个、艺术级、改善的、最大、最小等等。要注意在文档中表达同一个意思时所用的词是同一个。,31,可证实和可测试性 每个需求是否正确的实现 可修改性 通过良好的组织可以使需求易于修改 可追踪 软件需求应该能够与其原始材料相对应。另外，软件需求与设计元素、源代码、用于构造实现和验证需求的测试也应该对应起来。需求文档被及时更新 如果程序员很高兴地宣布某个功能终于完成了，但接下去发现这个功能其实已经被取消了。,32,需求测试是软件测试的一个重要部分。软件本身是由代码、各种文档、数据来组成的，因此，软件测试的对象也不应该仅仅局限在代码和可执行程序，需求文档就是一个重要的被测试对象。在评审软件需求说明书时，软件测试主管和部分测试工程师一般会加入到评审小组中，他们会在会议前阅读软件需求，并在评审会议上发表自己的意见。,2.2.4 需求测试,33,1.需求测试内容 软件需求文档从以下几个方面来评价需求文档：需求文档是否符合公司的格式要求？需求是否正确？要保证需求文档中所描述的内容是真实可靠的这是“真正的”需求吗？描述的产品是否就是要开发的产品？需求是否完备？第一个发布版本是否需要更多的功能?需求是否兼容？需求有可能是矛盾的。需求是否可实现？需求是否合理？在开发进度、开发费用、产品性能、可靠性之间存在着平衡关系。需求是否可测？,34,如果测试人员面对的是不可测试的需求，那么后续的所有工作将无法进行。假如在需求文档中出现了这样一段话“要求打印文档的速度足够快”，那么这段话就是不可测试的需求。在这种情况下，需要测试人员提出质疑。如果把它改为“要求打印文档的速度为不低于5张/min”，那么这段话就是可以被测试的。,35,2、需求测试的方法 需求测试是一种静态的测试。在这个阶段，没有一个可以在计算机上运行的软件供测试人员进行测试。三种常用的静态测试方法：复查 复查一般是让工作中合作者检查产品并提出意见。发现文档缺陷同级互查的能力是三种方法中最弱的。走查 系统分析员做好需求分析，然后给相关人员讲解他的需求说明书,在开发人员讲解的过程中,其他人员如果有问题,可以提问。,36,审查 关键组件的审查通过会议进行，会前每个与会者需要进行准备，会议必须按规定的程序进行，缺陷被记录并形成会议报告。审查是非常有效的发现缺陷的方法。,37,2.3 测试策略,制订测试策略考虑的问题：（1）测试范围 由于软件是无法被完全测试的，对于被测试软件，要判断哪些功能、特性需要被测试。（2）测试方法 对于不同的系统，需要采用不同的测试方法（3）测试标准 只有完成了一个阶段的测试(如集成测试)，才能开始下一个阶段的测试(系统测试)。所以就需要为每个阶段测试在什么情况下可以开始、什么情况下可以结束定义标准。,38,（4）自动化测试工具的选择 需要判断是否使用自动化测试工具、使用什么自动化测试工具（5）测试软件的编写（6）与项目相关的一些特殊考虑 在测试策略中，需要考虑、回答上面问题，然后编写相应文档。,39,测试策略中需要完成的主要步骤：确定测试范围 确定测试方法 定义测试标准 选择测试工具,40,对于一个将被实际使用的软件来说，完全测试是不可能实现的。例如：一个计算器软件。如果要完全测试其中的两个整数相加的功能，将把所有可能的组合都进行一次测试，而这个组合有2*1032*2*1032个，可以很容易地判断出进行这个完全测试是不可能的。而两个整数相加还只是计算器中的一个小小的功能。那么简单的计算器软件尚且如此，在实际被使用的一些软件系统，要想对其进行完全测试，是根本不可能实现的。,2.3.1 确定测试范围,41,有一些比较典型的情况可以事先要确定一个必须的测试范围而不是测试所有内容：(1)某些阶段的测试或者某些内容的测试可以简化 如果是在旧的软件版本的基础上进行新版本的开发。在旧版本中，有些软件模块已经被进行过多次单元测试，证明这个模块是足够坚固的，在这种时候，一般就不对这个模块进行单元测试。但也不是可以完全地省略某个阶段的测试。,42,(2)当对原有系统进行修改升级时，某些测试不需要 例如，为某个软件添加打印功能，这个时候文件打开和保存功能就不需要进行很多测试。但是要慎重选择。有时候，程序员很自信地认为某个原有的功能绝对没有修改，绝对不会受到新加功能的影响，但事实上，可能会存在他们完全没有意料到的因素而导致原有的功能被破坏。,43,(3)某些测试根本不可能进行 例如，银行发行了新的取款机软件，根本不可能让所有信用卡的持有者在某个时间段去试用一下，而只能采取一些模拟的手段来进行测试。测试过度，则在测试覆盖中存在大量冗余；测试范围过小，则存在遗漏错误的风险。定义测试范围是一个在测试时间、费用和质量风险之间寻找平衡的过程。期望花费更少的时间和费用，就必须承担更大的质量风险。,44,定义测试范围需要考虑下列一些因素：首先测试最高优先级的需求。(在时间和资源的限制下）测试新的功能和代码或者改进的旧功能。（如果代码改动过，就需要回归测试）使用等价类划分来减小测试范围 重点测试经常出问题的地方,45,确定测试范围方法 可采用提问单的方式来确定测试范围哪些功能是软件的特色？哪些功能是用户最常用的？如果系统可以分块卖的话，哪些功能块在销售时最昂贵？哪些功能出错将导致用户不满或索赔？哪些程序是最复杂、最容易出错的？哪些程序是相对独立，应当提前测试的？哪些程序最容易扩散错误？哪些程序是全系统的性能瓶颈所在？哪些程序是开发者最没有信心的？,需求分析人员、设计人员、程序员，市场、销售人员，公司工程管理人员、客户都有可能加入到这个过程中。,46,2.3.2 选择测试方法,在不同的开发阶段，需要选择不同的测试方法。在软件开发的不同的阶段可以选择的不同的测试方法。,（1）需求分析阶段 静态测试（2）概要设计与详细设计阶段 静态测试(3)编码和单元测试阶段：静态测试和动态测试、白盒测试(4)集成测试阶段：动态测试、白盒测试、黑盒测试(5)系统测试阶段：动态测试、黑盒测试(6)验收测试阶段：动态测试、黑盒测试,47,2.3.3 定义测试标准,定义测试标准的目的是设置测试中遵循的规则。需要制订以下几种标准：测试入口标准测试暂停与继续标准测试出口标准,48,(1)测试的入口标准 在什么情况下可以开始某个阶段的测试?测试的入口标准，指的是在开始某个阶段测试之前，需要完成的工作。不同的公司、不同的项目、不同的测试阶段所需要的入口标准是有所差异的，需要测试人员根据实际情况，会同项目组其他成员制定入口标准。,49,如在开始系统测试之前，需要完成的工作：完整的软件包(指软件安装光盘和相应的手册)；系统测试计划；测试数据；所需要的测试环境；软件已经通过了集成测试。,50,(2)测试暂停与继续标准 测试暂停标准就是定义在什么情况下，测试工作需要暂时停止。例如，当测试人员在第一个测试工作日发现的缺陷数量大于50个时，集成测试工作暂停。另外还有其他原因会导致测试工作暂停，例如，测试环境未能准备好；测试工具未能准备好或者未完成人员培训。测试继续标准说明的是，当问题被解决，而且能够有方法确认被解决了之后，测试可以继续进行。,51,(3)测试出口标准 定义在什么情况下可以结束某个阶段的测试。以系统测试阶段为例，在测试出口标准中，就会要求所有的测试案例都已经被执行，并且未能通过的测试案例小于某个数值。注意：一个阶段的出口标准和下个阶段的入口标准是不一样的。要想进行下个阶段的测试，首先要达到上个阶段的测试出口标准，还要为下个阶段的测试准备额外的内容。例如，在进行系统测试时，并不是说完成了集成测试就可以做系统测试了，至少还要准备、审查系统测试的测试计划、测试案例，然后才可以启动系统测试。,52,制订测试标准常用规则,（1）基于测试用例的规则 当测试用例的不通过率达到某一百分比时，则拒绝继续测试。当功能性测试用例通过率达到100，非功能性测试用例通过率达到90时，允许正常结束测试。（2）基于“测试期缺陷密度”的规则“测试期缺陷密度”：测试一个CPU小时发现的缺陷数。如果在相邻n个CPU小时内“测试期缺陷密度”全部低于某个值m时，则允许正常结束测试。,53,（3）基于“运行期缺陷密度”的规则“运行期缺陷密度”：软件运行一个CPU小时发现的缺陷数。如果在相邻n个CPU小时内“运行期缺陷密度”全部低于某个值m时，则允许正常结束测试。,54,一般来说，软件产品的质量标准，往往不是“无错误”，例如：严重Bug不允许存在；次要Bug数量小于5个。在开发合约中，也往往对递交时的缺陷数量进行约束。例如，开发合约描述向用户最终递交软件时的质量标准：灾难级Bug=0；严重级Bug=0；重要级Bug=O；一般级Bug6；次要级Bug15。,55,2.3.4 自动化测试工具的选择,在制定测试计划时，需要确定：在本项目的测试过程中，是否使用自动化测试工具；如果使用，在什么阶段，使用哪种测试工具。使用测试工具可以带来下面一些主要的好处：能够很好地进行性能测试和压力测试能够缩短测试周期能够提高测试工作的可重复性测试人员在进行人工测试时，无法保证每次都是用同样的方式同样的步骤来操作。但自动化测试工具能够保证在每次测试的时候都是完全按照同样的方式来进行的。,56,选择自动化测试工具需要注意以下几方面：并不是所有的测试工作都可以由测试工具来完成并不是一个自动化工具就可以完成所有的测试使用自动化工具本身也是需要时间的，这个时间有可能超过手工测试的时间如果测试人员不熟悉测试工具的使用，有可能不能更多发现软件错误，从而影响测试工作质量自动化测试工具并不能对一个软件进行完全的测试购买自动化测试工具，有可能使本项目的测试费用超出预算,57,2.3.5 测试软件的编写在有些情况下，完全的人工测试并不可行，也没有合适的自动化测试工具，就需要编写相应的测试软件。如果涉及到软件中某个部分需要自行编写测试软件来完成测试，就需要在测试计划阶段，对此进行规划。,58,2.3.6 合理减少测试工作量 航空航天、武器、金融等领域的软件系统，要严格测试。而对于一般性软件，开发商对测试的投入是有限度的。降低软件测试代价有两种方法：(1)减少冗余和无价值测试 白盒测试与黑盒测试的方式虽然不同，但在很多地方，会产生一模一样的效果，这样的测试是冗余的。一般白盒测试比黑盒测试麻烦。所以在执行白盒测试时，应当将精力集中在黑盒测试无能为力的方面，如内存泄漏、误差累积、数据溢出等等。在集成测试、系统测试阶段，可能要执行多次“回归测试”。每一次“回归测试”都会存在不少的冗余，应当设法剔除不必要的重复测试工作。,59,(2)减少测试阶段 如不作单元测试和集成测试，只做系统测试。这种方法将危害软件的质量，导致维护的代价增加。上述第(1)种方法是我们追求的，第(2)种方法只能在万般无奈的情况下采用,60,2.4 测试环境,从软件的编码、测试到用户实际使用，存在着三种环境：开发环境、测试环境、用户环境。开发环境是供程序员进行代码开发时使用的环境；测试环境是测试人员为进行软件测试而搭建的环境；一般情况下，将包括多种典型的用户环境；用户环境是用户实际使用软件的环境；不同的用户可能在不同的环境下使用这个软件。在很多情况下，这三个环境并不相同，但一个规划良好的测试环境，总是很接近于用户环境。,61,“环境”指的是被测试软件所运行的软件环境和硬件环境。包括产品运行的操作系统(Windows XP、Linux)，其他支持软件(如Java虚拟机、数据库软件)，计算机平台(例如PC、小型机)，外围设备(如打印机)，专用的硬件设备(如一系列输入、输出设备)。在开始进行测试前，要建立测试环境。建立测试环境，需要花费人力、时间和经费才能建立起满足测试要求的环境。因此，在测试计划阶段，就需要对建立什么样的测试环境进行规划。,62,2.4.1 测试环境的环境项,测试一个商业软件。该软件是一个运行在Windows下的应用软件，可以完成数据文件备份与恢复功能。该软件支持Windows 98及以上的各个Windows版本，可以将文件备份到CD刻录机、DVD刻录机、USB移动硬盘。测试小组需准备测试环境：,63,2.4.1 测试环境的环境项,九个版本的Windows系统Windows 98Windows 98 SEWindows MEWindows 2000 Professional(中/英）Windows 2000 ServerWindows XP Home Edition（中/英）Windows XP Professional。,在每个版本的Windows上，都进行了完整的测试。另外，在Windows XP Home Edition下面，还进行了256MB内存、512MB内存两种配置的测试,64,2.4.1 测试环境的环境项,多种CD、DVD刻录机。包括七种CD刻录机(三种IDE接口内置式，一种SCSI接口内置式，一种USB接口外置式，两种带有CD刻录功能的DVD-Combo)，两种DVD刻录机。五种USB移动硬盘 一个规模很小的软件，测试人员也必须要准备多种操作系统环境和外围设备环境。建立测试环境，需要对软件的需求(包括功能需求和非功能需求)、用户的使用环境有很深入的了解。,65,在建立测试环境时需要考虑的因素有以下环境项：（1）计算机平台 在PC上运行的软件需要考虑：CPU速度、内存容量、硬盘、显示卡和显示器的显示能力及多媒体能力。在搭建测试环境时，一般要考虑三种情况：最低配置，常见配置，理想配置。常见配置是测试的重点，最低配置是必须测试的。,66,例如，要求CPU为1GHz或以上，要求至少256MB内存。软件的最低配置需求情况需要被测试，如果软件在最低配置情况下能够正常工作，一般可以肯定在高配置的情况下能够更好地工作。实际上更多的用户不是在最低配置环境下工作，因此，更多的测试也应该是在最通常的配置情况下进行。例如，某软件要求最低配置1GHz以上CPU，256MB内存，那么在测试的时候，需要验证在1GHz CPU，256MB内存情况下是否可以正常工作，但由于使用1GHz CPU的用户并不是多数，所以更多的测试可以在P4 2.0 GHz下进行。,67,（2）操作系统 需要声明支持的操作系统，例如 要求Windows 98或以上，则要测试Windows的多个版本。每个版本还包括了不同的语言，如果是在国内发行的软件，就要考虑英文版本和中文版本，如果是在其他国家发行的，就要有当地语言版本。,68,（3）浏览器 如果是基于Web的应用系统，就需要对各种流行的浏览器环境进行测试。有两种浏览器环境必须要被测试：Microsoft Internet Explorer和FireFox。在某段时间哪些浏览器拥有最多的用户，是测试人员必须要了解的信息。,69,（4）软件支持平台 在一个软件系统发布的时候，往往需要第三方软件的支持，Java应用程序就需要Java虚拟机的支持,很多企业应用软件需要数据库软件的支持。要考虑版本和兼容性等。在软件支持平台方面，还有一个要注意的问题是：用户环境中存在某个软件，与待测试 软件不兼容。待测试软件与市场占有率很高的软件不兼容，这种情况就比较糟糕。,70,（5）外部设备 不同的软件系统会需要不同的外围设备支持，键盘、鼠标、显示器是基本的外围设备。另外还有打印机、扫描仪、磁带机、刻录机、数码相机、数字摄像机等有一些常用的外围设备。当软件系统支持某个外围设备时，就需要测试人员在尽可能多的设备型号上进行测试。例如在某家开发图像处理软件的公司，该公司的多数产品均具有图像打印功能，在该公司的测试实验室，准备了数十台各种各样的喷墨、激光、针式打印机，当某个新的软件发布前，该软件将在所有这些打印机上被测试。,71,在多种外围设备上进行测试，所消耗的时间和费用是很大的。一般来说，在组建测试环境的时候，选择该设备的几款主流型号进行测试，就可以覆盖大多数用户的使用环境。,72,（6）网络环境 在网络环境方面，需要考虑的有：网络访问方式(如通过局域网连接、通过代理服务器连接)、网络速度、防火墙等。另外，还要考虑不稳定的网络连接情况，如网络时常中断。（7）其它专用设备,73,在配置测试环境方面，同样面临着在测试范围中的平衡问题。测试的配置环境越多，所花费的时间和费用越高，面临的未来的质量风险也越小。但过于复杂的测试环境，也会导致测试周期过长、测试成本过高，在项目开发中也难以接受。,2.4.2 如何配置测试环境,74,假设某个软件需要测试两种浏览器(IE和FireFox)四种操作系统(Windows 98、Windows ME、Windows 2000、Windows XP)三种CPU(Intel PIII 1GHz、Intel P4 2.8GHz、AMD A1thon XP 2600+)两种内存配置(256MB、512MB)两种网络连接方式(拨号网络、ADSL宽带接入)。在测试这个软件的时候，即使只考虑五种环境项，那么可能的组合数目是2*4*3*2*2=96。需要搭建96种测试环境进行测试，做不到也没必要。,75,在搭建测试环境的时候，要排列配置的优先级，决定哪些配置需要全面测试，哪些配置需要部分测试。哪些配置需要优先被测试，主要考虑因素：使用的频度或者范围 某些配置使用的概率远远大于其他配置，可以增加这种配置环境的测试量。反过来，某些配置使用的概率远远小于其他配置，那么就可以减少这种配置的测试量 失效的可能性 如果某种配置下很容易发现软件错误，那么就应该加强在这种配置下的测试 能最大限度模拟真实环境 面向大众的商品化软件，在测试时常需要考察在真实环境中的表现。,76,2.5 测试管理,测试过程中所涉及到的人、活动和工具都是很多的(特别是在大型软件的测试中)，在制定测试计划时，要对这些因素加以管理。在测试管理方面，需要考虑的主要问题包括：选择缺陷管理工具和测试管理工具定义工作进度 建立风险管理计划,77,测试过程中，需要不断地发现缺陷、报告缺陷、跟踪缺陷直到其被解决，用什么工具来报告和管理缺陷?缺陷管理的过程，需要编码、测试人员的紧密配合，需要不停地交换、更新当前的工作状态，为了高效率地完成这些工作，一般需要有软件工具来进行辅助。目前，已经有很多的缺陷管理工具可供使用，可以用Bugzilla缺陷管理工具进行缺陷管理。,2.5.1 缺陷管理工具和测试管理工具,78,软件测试过程包括了一系列的工作步骤，这些步骤需要被进行良好地管理和组织。可以依靠测试管理人员和一系列的文档来进行管理，也可以使用测试管理工具TestDirector来进行辅助管理。在执行测试的过程中，缺陷管理工具和测试管理工具并不是必须的。但多数公司都会使用缺陷管理工具。,79,定义工作进度的过程,2.5.2 定义工作进度,80,1.确认工作任务 工作任务可以分为两类，一类是可以直接和需求文档对应起来的，比如在需求文档中列出的某个软件功能，在测试过程中。另一类和需求文档没有直接的关联，如不同小组之间的交流。在需求文档中，描述了软件的功能性需求和非功能性需求，对需求中的每一个条目，都应该有相应的测试工作与之对应起来。确认好测试任务后，还应该排列这些任务的优先级。,81,考虑与需求文档没有直接关联的任务：执行测试时设置和配置系统开发和安装专用测试工具学习使用测试工具定制测试工具将测试用例编写为脚本或数据文件重新运行以前没通过的测试用例产生测试报告和测试总结文档编写测试计划编写质量报告、缺陷报告人员培训与程序员之间的交流与客户之间的交流,82,上面列举的任务，在确认工作任务和估算工作量的过程中，很容易被遗漏掉，而在实际的测试过程中，又必须执行上述任务。如果遗漏掉了上述任务，就很容易发现这样的情况：在实际进行测试时，发现实际所需要的工作量远远超过了“以为”的工作量。在工作任务完成后，要进行审查和确认。可以根据所列出的测试任务，“静态地”把测试的全部过程走一遍，以判断有无遗漏。,83,2.估算工作量 工作量可以使用“人*日”、“人*月”、“人*年”单位。一般认为：1人*年=12人*月；1人*月=21人*日；1人*日=8工作小时 测试工作量的估算可以采用以下方法：(1)建立详细的工作分解结构 如装修、写书 软件测试也需要建立详细的工作分解结构，将任务细分为众多的子任务，直到可以比较有把握地确定每个子任务的工作量为止。,84,例如：测试员与程序员交流的工作量：与编码小组的每周例行质量会议，预计每周2小时。向程序员现场演示发现软件错误的过程，预计每天0.5小时。在收到新的版本后，听程序员描述新版本改动的内容和期望进行重点测试的地方，预计每周1.5小时。每个测试人员每周需要与程序员进行6小时的交流。如果测试工作预计持续1个月，有3名测试人员参与工作，那么每个测试人员需要在此任务中投入24小时的工作量，以人*日来度量，那么该测试小组与程序员的交流的总工作量就是24*3/8=9人*日。,85,(2)分析以往项目，寻找历史数据 如果即将进行测试的软件和以往某个已经完成的软件类似，那么就可以使用以往的数据来估计工作量。如开发软件其功能、难度、复杂度、编码和设计的工作量与以往某个软件类似。在估算该功能测试所需要时间时，可以参考以往的数据。人员结构类似，可以参考以往关于交流时间的数据。(3)使用评估模型 现在有一些评估模型，可以预测工作量。这些评估模型通常是基于估计的代码行数、功能点数来进行的。,86,在估算工作量时，还要注意一些“返工”的问题。在估算工作量时，要记住的是：某些工作任务有可能被重复做上多遍。,87,3.编写进度计划进度计划可以用甘特图的形式来表示，更直观。,88,在进度计划中，要确保：所有任务都已经被列出 计划中包含了任务编号、任务名称、开始时间、完成时间、持续时间等信息计划是可行的，资源要求能够被满足按照此计划开展实际工作如果有变化，该计划将被及时更新,89,2.5.3 建立风险管理计划,在测试中也要不断地预计风险、跟踪风险和规避风险。在测试中面临的问题：由于设计、编码出现了大的质量问题，导致测试工作量、测试时间增加；在开始测试时，所需要的硬件、软件没有准备好 未能完成对测试人员的技术培训 例如，在测试工作中选用了某个新的测试工具，但未能及时对测试人员进行工具使用的培训；测试时的人力资源安排不足,90,在测试过程中，发生了大量的需求变更在测试过程中，项目的开发计划被进行大幅度调整 不能及时准备好所需要的测试环境 某公司遇到过这样的例子：某个软件系统的集 成测试需要在数台小型机上进行，由于该公司不可能为此购买小型机进行测试，所以集成测试和系统测试需要在用户购买了小型机后再进行。但用户的实际购买日期比原计划推迟了。不能及时准备好测试数据,91,风险管理的过程：识别风险 列举在工作中可能遇到的风险 评估风险针对所列举出来的风险，对其发生的可能性、产生的后果进行评估 制订对策 对于每个风险，制定对策使其发生概率减小。跟踪风险 跟踪风险状态和对策执行情况，更新风险管理计划,92,2.6 编写和审核测试计划,由于测试的种类多、内容广并且时间分散，并且不同的测试工作由不同的人员来执行，因此一般把单元测试、集成测试、系统测试、验收测试各阶段的“测试计划”分开写。“测试计划”的撰写宜早不宜迟，只要信息足够就可以提前起草，不要拖到快要测试时才开始写。,93,94,2.6.1 编写系统测试计划文档 测试计划是描述软件测试努力的目标、范围、方法和焦点的文档。完整的文档将有助于测试组之外的人理解为什么要进行软件检测，并且如何进行检测。下面是一份测试计划模版,95,标题。确定软件的版本号。修订文档历史，包括作者、日期和批示。目录表。文档的目的和适合的读者群。测试的目的。软件产品概述。相关文档列表，例如：需求、设计文档、其他测试计划等。相关的标准或合法需求。相关的命名规范和标识符规范。整个软件项目组织和人员，联系信息责任。测试组织和人员联系信息，责任。假设和依赖关系。,测试计划模版,96,项目风险信息。测试优先级和焦点。测试范围和限制。测试提纲对测试过程的一个分解，通过测试类型、特点、功能性、过程、系统、模块等。测试环境设置和配置问题。数据库设置需求。概述系统日志错误日志其他性能，有助于描述问题的屏幕捕获工具等。有助于测试者跟踪问题根源的具体软硬件工具的论述。测试自动化的可能性和概述。使用的测试工具，包括版本、补丁等。使用的项目测试度量。,测试计划模版,97,报告需求和测试可传递性。软件人口和出口准则。初始的理性测试阶段和标准。测试终止和重新开始的标准。人员安排。测试地点。用到的测试外的组织，他们的目的、责任、可传递性、联系人和协作问题。相关的财产、分类、安全性和许可证问题。附录词汇表、缩略语等。（例P254）,测试计划模版,98,2.6.2 单元测试计划表格,99,100,2.6.3 审核测试计划文档“测试计划”撰写完毕后应当请有关人员对其审批.,101,一般来说，“单元测试计划”需要设计主管和程序主管审批，“集成测试计划”需要项目主管和设计主管审批，“系统测试计划”需要项目经理、质量保障部门主管、测试主管审批。,102,小 结 本章介绍了如何制定测试计划。在制定测试计划前，需要对软件需求进行了解和分析。另外，还需要对软件需求进行静态的测试。在制定测试计划时，首先要确定测试策略。这包括了：确定测试范围、选择测试方法、制定测试标准、选择自动化测试工具和编写测试软件。自动化测试工具、编写测试软件并不是在每个软件的测试中都是必需的。在确定测试范围的时候，要做到在保证测试质量的前提下，尽量减小测试范围。,103,接下去要定义测试环境。对于绝大多数软件来说，需要在各种环境中运行。如果把各种 可能的环境因素全部组合起来，将可能得到一个天文数字。这个时候，软件测试人员就需要对测试环境进行分析，从而选择出有限的测试环境组合。测试过程中，还会涉及到一些管理工作。对于缺陷的管理和对于测试工作流程的管理就是其中典型的管理工作，在制定测试计划时，需要确定使用什么样的工具来进行相应的管理。,104,在测试计划阶段所进行的工作，都需要有相应的文档来记录和描述，需要编写测试计划文档。单元测试、集成测试和系统测试的测试计划文档需要被不同的人员编写，一般是独立的文档，其需要完成时间也不一样。测试计划文档需要被审核，只有被审核通过后，才能作为后续工作的计划文件。要特别注意的是：所有完成的文档都必须保持及时的更新。否则，文档中描述的内容就会和实际工作的偏差越来越大。,