软件测试实用教程-方法与实践（第2版）课件 第10、11章 测试过程管理、测试应用案例实践

第10章测试过程管理高等学校计算机类系列教材软件测试实用教程——方法与实践01软件测试过程模型V模型PaulRook在20世纪80年代后期提出V模型，该模型是最具有代表意义的测试模型。V模型是软件开发瀑布模型的变种，反映测试活动与系统分析和设计的关系，体现了动态测试的过程。V模型的基本思想如图10.1所示，图中箭头表示时间方向。从该图可以看出，左半部分的开发过程自顶向下，严格分为不同的开发阶段，右半部分的测试过程则自底向上，也严格区分不同阶段，且测试活动的展开次序正好与开发的次序相反。V模型

V模型的策略：动态测试行为应与开发行为对应，每个测试阶段的基础是对应开发阶段的提交物，并通过低层测试确保源代码正确，通过高层测试保证整个系统满足用户需求。V模型的局限性主要在于：(1)测试滞后。测试是编码完成后的阶段，无法快速发现开发早期引入的缺陷，大大增加缺陷修复成本，且当前期开发进度拖延时将导致测试大大缩水。(2)测试与开发文档难以—一对应。测试与开发文档之间很少有完美的一对一关系。例如，需求分析文档往往需利用设计文档中的部分内容来为系统测试提供足够的信息。(3)缺少静态测试。缺少需求评审、代码审查等静态测试，容易降低测试效率。W模型为解决V模型的不足，PaulHerzlich提出了W模型，其基本思想是在V模型基础上增加与开发阶段同步进行的测试部分，即开发和伴随的测试过程分别是两个完整的“V”，如图10.2所示。其中，开发的V字左侧对应需求定义和设计，伴随的测试行为是对开发文档的静态测试，以及对应测试阶段的测试计划、设计和实施的过程；开发的V字右侧对应软件实现，伴随的测试行为是对这些实现的动态测试，即测试执行和评估的过程。W模型W模型的测试策略：静态测试和动态测试行为伴随整个开发阶段，并与开发行为对应，有助于早期发现缺陷、了解项目难度、评估测试风险，并加快项目进度，降低项目成本。W模型的局限性主要在于：(1)将软件开发看成需求分析、设计和编码等一系列串行的活动。(2)开发、测试之间保持着线性的前后关系，无法支持迭代的开发模型，无法支持变更调整。(3)未体现测试流程的完整性。H模型V模型和W模型都把软件开发看做需求→设计→编码的串行活动，具有严格的阶段划分，无法支持迭代和增量开发，且未体现每个测试阶段的完整流程。为此，人们提出了H模型，其基本思想是将测试活动独立出来，形成两个阶段的独立的测试流程：(1)测试准备阶段：包括测试计划、测试设计和测试实施。(2)测试执行阶段：包括测试执行和测试评估。H模型的原理如图10.3所示，该图说明了软件开发某个阶段对应的测试活动，图中实线表示的为测试流程所包含的活动，虚线则表示其他流程所包含的活动，如设计、编码活动，甚至是软件质量保证这类非开发流程。H模型由该图看出，在测试就绪点之前要做两方面准备工作：一方面是开发准备，即提供被测对象和测试依据，属于主要开发流程所提供的工件；另一方面是测试准备，即提供测试工件(包括测试计划、测试需求、测试用例、测试脚本、测试环境等)，对应测试计划、设计和实施的过程。V模型基于一套必须按照一定次序严格排列的开发步骤，而实际的实践过程往往并非如此，例如，实际的项目往往缺乏足够的需求，而V模型必须从需求处理开始。为此，Marick提出了X模型，其基本思想是：针对每个单独的程序片段，进行编码和测试工作，不同程序片段之间的编码和测试相互独立，最终的可执行程序通过各程序片段的交接和集成来获取。X模型图10.4给出了X模型示意图。图中左半部分是针对每个单独的程序片段进行的单独的编码和测试过程，强调测试先行，即对编写完成的程序代码片段先进行测试设计和工具配置，再开始测试执行，这与敏捷开发的思想十分类似。对某个程序片段测试执行完成后，认为该程序的编码完成(注意，图中的“编码完成”不等于“代码编写完成”，而是指经过了一定单元测试后质量具有一定保障的程序片段)。多个这样的程序片段需进行多次交接和集成，并需对集成的程序再次进行更高级别的测试设计和执行(见图的右半部分)，最终通过测试的成品作为更大规模内集成的一部分，或直接封版提交给用户。X模型综合策略综合上述测试过程模型，建议采用的综合策略：宏观上以W模型为基本框架，将软件开发和测试作为两个并行的过程，测试伴随整个开发过程；而微观上对每个测试阶段则以H模型为指导，进行独立测试，即只要满足测试执行条件就可以进行独立的测试，并反复迭代测试，直至达到预定目标；当项目小组的开发过程中存在诸多不确定因素时(如需求的变更、对缺陷的修复等)，则可利用X模型，针对每个相对独立的系统组成部分，进行相互分离的编码和测试，经多次交接后集成为最终的版本。当然，对于软件企业而言，则应以软件测试成熟度模型(TMM)为指导，努力建立规范的软件测试过程，有关TMM的内容，本书不再详细描述。02测试用例的管理测试用例的核心属性包括ID、输入和预期输出，为了便于其管理，测试用例报告中还应包含更多内容。测试用例报告实际就是要详细回答如下问题：谁、在何时、针对哪个软件项目、针对哪个程序版本、针对哪个功能模块、针对哪个测试需求、依据什么参考文档、设计了哪些测试用例、这些测试用例规定软件在怎样的测试环境下、以何种方式执行之后应得到怎样的预期结果、这些用例的优先级如何、测试用例之间的约束关系是怎样的。测试用例报告的撰写受成本限制，公司或项目组将根据实际情况对上面的测试用例报告进行瘦身，例如将若干测试用例之间相同的部分集中予以表达，将用例间不同的内容(主要涉及测试用例的ID、输入、操作步骤和输出等)以列表或大纲形式给出。表10.1给出了某项目的设备管理模块中辖区移交子功能(功能编号：Q3.13)的部分功能测试用例，对应测试需求(编号：Q3.13.2，优先级：中):正二级用户登录，移交的设备树辖区节点中有设备，指定要移交的二级单位无辖区设备，但有正二级用户，辖区节点可成功移交。表中各测试用例的操作步骤为：选中辖区节点1处，选择“辖区移交”菜单项，然后在辖区属性对话框中选择2处，单击“确定”按钮。在表中不再——给出。测试用例报告的撰写测试用例报告的撰写测试用例的组织和跟踪测试用例的组织和跟踪可分7个步骤来完成。(1)整理模块需求产品的需求往往不是一次就搞定的，一开始经常会存在很多遗漏、错误理解、不一致、无法测试等各种缺陷，而交到测试小组手中的很可能就是这样的文档。(2)撰写测试计划撰写测试计划是后续测试设计、执行和评估的基础，所有工作都应在良好的计划指导下完成。(3)设计测试思路通过分析测试计划中的测试特性，应设计测试的思路，即对测试需求进一步做细化工作。(4)编写测试用例根据测试设计，分别设计具体的测试用例，应灵活使用本书第二部分所介绍的测试方法，并遵循第三部分的测试阶段策略。(5)评审测试用例测试用例在设计编写过程中应组织同级互查，编写完成后则应组织专家进行评审，获得通过才可以使用。测试用例的组织和跟踪若时间紧迫可提前启动测试，等评审完成后再修改测试用例。外部评审通常是在测试用例编写完成之后进行。典型的测试用例评审检查单见表10.2。(6)修改更新测试用例测试用例经评审之后需根据评审意见进行修改。(7)执行测试用例测试用例经修改之后，可从版本控制库中取出测试用例，并在测试用例中记录测试的结果，使用后送入版本控制库，进行版本管理。典型的测试用例生命周期见图10.5。测试用例的组织和跟踪(8)分析评估测试用例质量测试用例全部执行后，需对测试用例的质量进行分析和评估。一方面，从测试用例对代码及对缺陷的覆盖率来衡量测试用例的设计质量。测试用例的组织和跟踪每百行代码的测试用例数目越多，测试用例密度越高，对代码的覆盖程度越高，但太高的覆盖率反而有可能带来成本的激增，效果却不一定很好。所有缺陷中，被测试用例所发现的缺陷率越高，证明测试用例的漏洞越小，当测试用例对缺陷的覆盖率低到一定程度的时候，说明亟需提高测试人员的技术水平了。另一方面，从每轮测试中测试用例的执行率、通过率、平均每天执行测试用例的数目、平均每天执行测试用例的通过率、不同模块的测试用例通过率等指标来衡量测试用例的执行情况。03软件缺陷的管理1.严重性严重性(Severity)是指缺陷对被测系统造成的破坏程度的大小，它可能是即时的破坏，也可能是一段时间之后对系统带来的毁坏。严重性是对缺陷的客观评价，反映了缺陷自身对软件系统和对用户使用造成的绝对影响。严重性由测试人员设定，但一经设定，不可随意改动。缺陷的属性(1)严重的(Critical):重要功能丧失，致命错误造成系统崩溃、死机、系统悬挂、甚至危及人身安全，用户数据丢失或破坏而容易引起用户财产损失或法律纠纷，业务流程错误、数值计算错误等，其中法律法规、具高频使用率的功能的缺陷是最严重的。(2)一般的(Major):不影响系统的基本使用，能满足商业要求，但用户不常用的功能实现未达到预期效果，可能导致用户使用不方便，可能对公司品牌形象有直接影响等。(3)次要的(Minor):对功能几乎没有影响，产品及属性仍可使用。典型缺陷包括：个别错别字，文字排列不整齐，非常小的标点符号错误，不可行路径等。2.优先级优先级(Priority)是指缺陷必须被修复的紧急程度。优先级是对缺陷的主观评价，反映了项目小组对缺陷风险的评估结论，若认为缺陷带来的风险不大，则设定该缺陷的优先级别较低，反之，则定级较高。优先级由项目经理负责设置，一经确定，也不能随意改动。缺陷的属性一般地，可将优先级划分为如下三个等级：(1)高(High):缺陷完全阻碍或部分阻碍进一步开发或测试工作，需立刻修复(一般为48小时内)或在下一个里程碑之前必须修复。(2)中(Middle):缺陷需正常排队等待修复，但在产品发布之前必须修复。(3)低(Low):缺陷对系统影响不大，当时间允许时可考虑修复，有时甚至不修复也能发布产品。缺陷的属性可重现性(Reappearance)指缺陷应在同样的条件下可反复出现，且每次出现的形式完全一样。无法重现的缺陷对开发人员是无意义的，因为无法对缺陷进行定位，意味着无法修复该缺陷，测试人员在测试中应确保缺陷可多次重现，并在缺陷报告中准确地描述出来。为确保缺陷可重现，应采用如下的措施：(1)在测试过程中随时记录操作步骤和被测系统的响应，一旦出现缺陷，可以快速写出执行步骤及出错现象，降低操作导致的不可靠因素，必要时采用屏幕录制工具(如Wink)协助完成这一过程；(2)重复测试至少三次，确保每次执行同样的步骤可得到相同表现的缺陷，同时在缺陷报告中注明重复测试的次数，以提高缺陷报告的可信度；(3)对于随机性出现的缺陷(即出现率并非百分之百)，则应尝试使用不同的测试数据、改变测试环境等，试图找到影响缺陷出现的根本原因。缺陷报告的撰写1.概述缺陷报告就是记录缺陷各方面信息的文档，一份缺陷报告实际就是要回答如下问题：(1)谁，何时，在何处，发现了什么缺陷?(2)谁，何时，提出怎样的处理意见?(3)谁，何时，如何修复该缺陷?(如果需要修复缺陷的话)(4)谁，何时，如何验证该缺陷?测试结果如何?缺陷报告的撰写2.完整的缺陷报告表10.3是一个典型的缺陷报告模板。3.第二日问题的缺陷报告以第二日问题为例，若管理员(充当测试人员角色，来自微软“人人均可测试”的理念)发现了isLeapYear函数中的一个缺陷，登录BugFree(一款开源缺陷管理工具)后填写的缺陷报告见图10.6。缺陷报告的撰写缺陷报告的撰写接着，程序员登录后看到有一个缺陷报告发给自己待解决，项目经理和管理员对该缺陷进行了详细的说明，如图10.7所示，程序员对缺陷修复后回复的内容如图10.8所示。缺陷报告的撰写管理员回复后的缺陷报告如图10.9所示，单击“关闭它”按钮即可关闭该缺陷。缺陷报告的撰写4.缺陷报告的裁剪为了节省时间，公司或项目组往往会根据实际情况对完整的缺陷报告进行裁剪，仅保留缺陷报告的主要信息，如表10.4所示，缺陷067对应的界面如图10.10～图10.12所示。从中可以看出，该缺陷报告仅保留了核心内容，从而可保证缺陷可跟踪，并避免了大量的文档编写工作。缺陷报告的撰写缺陷报告的撰写5.缺陷报告撰写的技巧缺陷报告采用什么模板并不重要，最重要的是缺陷描述应准确、完整、无歧义。缺陷010的描述较清楚，但与其对应的缺陷界面图却难以看懂，不清楚缺陷到底在哪里。而表10.4中的缺陷067不仅描述简明清晰，对应的三个界面图也一目了然，可惜其修改过程却让人看不懂：“没有问题”是什么意思?相比之下，缺陷103的描述则非常清楚。关于缺陷报告的技巧可用一句话来概括，任何人看到该缺陷描述和相关附件，都能准确无误地了解系统究竟怎样与预期不一致，经过怎样的修复后可关闭该缺陷，这就是一个合格的缺陷报告。缺陷的跟踪和管理1.缺陷处理的流程缺陷需要密切跟踪，测试人员发现并提交缺陷报告后，缺陷报告就在测试员、项目经理、开发人员等不同角色之间流转，进入不同的状态。典型的缺陷处理流程如图10.14所示。缺陷的跟踪和管理2.缺陷跟踪流程中的角色与权限缺陷的跟踪并非仅为测试人员的任务，在整个软件开发过程中涉及的不同人员均将接触到缺陷，如何划分不同人员的职责，应回答以下问题：(1)谁负责上报缺陷?谁控制缺陷的分类、严重性和优先级?谁决定缺陷的处理方式?(2)谁负责分配缺陷?谁负责修复缺陷?(3)当处理意见不一致时，谁负责进行仲裁?是否允许申诉?(4)谁有权查询缺陷数据?谁有权统计缺陷数据?缺陷的跟踪和管理有关各种角色的权限如图10.15所示。缺陷的跟踪和管理从该图中可以清楚地看到：(1)测试员负责上报缺陷，并对缺陷进行分类，确定缺陷的严重等级；(2)项目经理负责对缺陷的优先级进行划定，将缺陷分配给程序员；(3)程序员对缺陷报告审核之后决定针对缺陷应采取的处理方式，负责修复缺陷；(4)当程序员与测试员对缺陷的处理意见不一致时，仲裁委员会负责进行仲裁，避免程序员与测试员的“踢皮球”现象；(5)项目经理需了解整个项目的进度和质量，因此，需要通过对缺陷数据的查询分析来了解当前被测软件的质量，进而决策是否可以停止测试，准备产品交付。04测试团队的管理测试团队的责任测试团队的主要责任包括：(1)尽早并尽可能多地发现软件产品中的严重缺陷；(2)督促开发人员尽快修复程序中已发现的软件缺陷；(3)帮助项目管理人员制订合理的开发计划；(4)分析、总结和跟踪发现的缺陷，便于让项目管理者和项目负责人能清楚地了解软件系统当前的质量情况：(5)帮助改善开发流程，提高产品的开发效率；(6)督促开发人员遵循良好的编码习惯，提高代码的规范性、可读性和可维护性。其中，前两项是测试人员的基本职责，其余工作则主要是从过程度量和管理、质量保证及缺陷预防等角度所做的工作。测试团队组织架构一个测试团队不仅包含测试实施人员，还包括其他相关人员，典型的测试团队包括如下人员：(1)技术支持组：包括系统架构师和业务分析师；(2)质量保障组：包括质量保障人员和配置管理人员；(3)测试实施组：包括功能测试工程师和性能测试工程师；(4)测试开发组：包括软件架构师和研发工程师。测试团队各角色职责在一个测试团队中，不同角色的岗位职责如下。(1)项目经理项目经理对整个项目负责，其职责包括：①对项目进行管理，对最终的产品质量负责；②与用户或客户相关部门的沟通，以及与研发团队的沟通，保证项目顺利进行；③协调测试资源，对各种资源进行计划、分工和管理；④制订项目测试计划和测试方案；⑤组织项目各阶段的评审和验收；⑥对团队成员进行管理，保证团队高效地协同工作。测试团队各角色职责(2)测试组长测试组长对整个测试项目的管理负责，偏重技术，因此，测试组长的综合能力和技术应为小组内最强的，其职责包括：①对所负责小组的工作负责，包括制订成员工作计划、检查工作完成情况；②辅助编写测试计划、测试结果分析和报告，帮助测试工程师完成工作；③服从项目经理的管理，保质、保量地完成本小组负责的测试任务；④与小组其他成员一起，分析测试需求，设计测试用例，并保证对需求的覆盖；⑤提交软件缺陷报告，并跟踪缺陷处理流程，对本小组提出的缺陷报告负责；⑥协助项目经理进行项目管理工作；⑦与研发团队有效沟通，并协同研发、质量控制及配置管理小组的工作，提供必要的技术支持。测试团队各角色职责(3)测试工程师测试工程师主要负责开发文档的审查、测试的设计、实施和执行，其职责包括：①服从项目经理和组长的日常管理，保质、保量、按时完成测试任务；②根据软件需求来分析测试需求，设计测试用例，并保证足够的覆盖率；③执行测试用例，提交缺陷报告，并跟踪缺陷的处理；④有义务对项目工作提出建设性建议；⑤与研发等相关部门进行有效沟通。测试团队各角色职责(4)实验室管理员实验室管理员主要负责配置和维护实验室测试环境，以保证稳定的测试环境，具体职责包括：①对测试环境所需的网络进行规划和建设，维护网络正常运行；②建立和维护测试环境所需的服务器或软件平台；③对测试实验室的软件和硬件资源进行登记、分配和管理；④对测试实验室资源的使用权限进行分配，确保安全、合理地使用；⑤对测试环境进行优化，提高网络、服务器和其他设备的运行性能；⑥协助有关部门，对申请的新资源进行采购和验收。测试团队各角色职责(5)内审员内审员与质量保障人员和配置管理人员的工作有些相似，但侧重点不同，其职责包括：①对流程进行审查，并提出流程改进的建议；②建立测试文档所需的各种模板；③根据已建立的标准和规范，对测试过程中产生的文档进行质量检查。(6)配置管理人员配置管理人员的职责包括：①对被测系统进行配置管理和版本控制；②有效管理业务和研发提供的需求和设计文档；③对测试过程中产生的文档进行管理和版本控制；④与客户和研发团队配置管理员进行有效沟通；⑤辅助质量保障人员进行质量控制。测试团队各角色职责(7)质量保障人员质量保障人员的职责包括：①制订质量标准，制订质量保障计划；②对项目质量进行监督和控制；③制订里程碑的工件验收标准，并对完成情况进行审计；④分析项目风险，为项目经理决策提供支持。(8)系统架构师系统架构师并不隶属于测试部门，他主要的任务是进行软件架构设计，其与测试相关的职责包括：①搭建和维护测试环境；②数据库备份和恢复；③协助各小组完成测试任务。测试团队各角色职责(9)业务分析师业务分析师也不属于测试团队的主要成员，主要任务是收集用户需求，进行需求分析，为了提高测试人员对被测业务的理解程度，其与测试相关的主要职责包括：①对被测业务进行分析，协助项目经理设计测试方案；②对测试团队成员进行业务培训和支持；③协助设计深层次的测试用例，执行部分测试工作。对于一个较为完整的测试部门来说，以上角色的职责会发生些许变化。例如，部门需要一个测试经理的职位，他一般不对具体的项目负责，而是负责整个部门的管理，对产品质量负全面责任，有责任向公司最高管理层反映软件开发或产品中的管理问题，职责包括测试人员的招聘、培训、考核，测试团队结构建立和优化，负责测试部门年度计划、实施和评估，负责测试资源的调配和测试方法的改进等。05本章小结本章小结无论在哪个测试阶段，都需要对测试过程进行管理，最重要的管理对象就是测试用例、软件缺陷和测试团队。本章先简要说明了典型的测试过程模型，便于对测试过程进行宏观指导，结合测试用例、缺陷和团队管理展开讨论。测试用例是测试团队内部各测试工程师之间进行沟通的有效途径，测试用例报告既要清楚明白，又不能过于冗长，执行测试的人根据用例报告既能准确把握每批用例关注的测试重点，又能根据自己的理解加以适当的变化。缺陷报告是测试团队与开发人员，以及与用户之间有效沟通的主要媒介，缺陷报告也应尽量简洁、清楚，便于程序员在最短时间内重现缺陷、定位缺陷和修复缺陷。测试团队的管理则主要是对人的管理，要点在于不同角色各司其责，注意相互沟通和协调。谢谢观看第11章测试应用案例实践高等学校计算机类系列教材软件测试实用教程——方法与实践01保险金案例实践自动化测试设计1.脚本设计原则对于某个函数的测试实施来说，主要需考虑的问题是：(1)该函数是否存在上下级调用关系，若被上层函数所调用，或调用其他下层函数，则需为存在直接调用关系的那些函数另外开发驱动函数或桩函数，以实现对本函数的测试；(2)是否需以自动化方式来测试该函数，若需要，则应进一步考虑自动化测试覆盖的范围、支持自动化测试脚本的开发工具、测试脚本的存储等问题。同为函数的自动化测试，保险金问题的测试需求与1.5节捉虫实践4中提到的测试需求完全一致，不再赘述。所不同的是，本节使用Java语言开发，且基于Eclipse和Ant工具来完成保险金问题的自动化测试。自动化测试设计2.测试代码说明测试代码主要包括两个文件，其中InsuranceCalculatorTestjava用于定义测试驱动类，而XMLToXLSjava用于定义XML文件向Excel文件输出报告的过程。该测试脚本的基本思想是从一个名为“测试报告模板.xls”的Excel文件中读取全部测试用例数据，测试执行后将结果保存在report目录下形如“测试报告-20120604-211255.xls”的Excel文件中。受篇幅所限，详细代码见教学资源包。测试报告结果文件包括4个工作薄，其中，第一个工作薄为“概要”，说明测试的统计信息(如图11.1所示)，测试人、测试时间等这些具体的测试统计信息在测试执行之前为空。自动化测试设计第二个工作薄为“边界值”，用于提供基于边界的测试用例的测试结果，部分内容如图11.2所示，分别将通过和失败的部分测试用例显示在图11.2(a)、(b)中，图中测试结果、出错信息和测试用时在测试执行后才由系统自动填入对应数据。自动化测试设计

第3个工作薄为“决策表”，提供基于决策表的测试用例的测试结果，内容见图11.3。自动化测试设计

第4个工作薄为“无效等价类”，存储针对无效等价类的用例测试结果，部分内容见图11.4。JUnit概述1.JUnit自动化测试框架JUnit采用Composite设计模式构建自动化测试框架，如图11.5所示。该模式下，TestSuite(测试包类)可以容纳任何派生自Test(测试类)的对象，当调用TestSuite对象的run()方法时，将遍历自己所容纳的所有对象，分别调用它们的run方法，并分析返回的结果。JUnit概述2.JUnit主要的包和类的说明JUnit共有7个包，核心包是JUnit.framework和JUnitrunner，分别负责整个测试对象的构建和测试驱动。JUnit框架的骨干可表示为：TestCase+TestSuite+BaseTestRunner=TestResult。JUnit包含7个核心类，简要说明如下：(1)Test(测试)类是一个接口类，用来测试和收集测试结果，通过Test接口建立TestCase与TestSuite之间的关联。(2)TestCase(测试用例)类是Test接口的抽象实现，通过对该类继承来开发自己的测试驱动。一般地，一个TestCase的派生类实现对一个类的测试，可包含若干测试用例。也可以根据本项目和团队需要来开发自己的TestCase测试驱动基类，以便于代码重用。JUnit概述(3)TestSuite(测试包)类用于聚合多个测试用例。(4)TestRunner(测试运行)类是用于启动测试的用户界面，从而执行测试。(5)TestResult(测试结果)类用于收集TestCase的执行结果，将结果分为Failure和Errors两种异常，并转发给TestListener处理，其中由Assert触发的Failures是由测试用例抛出的可预测异常，当用例执行结果不同于期望值时抛出，表示用例失败；Errors是因测试驱动程序本身存在语法等缺陷而抛出的不可预测异常，与测试用例无关。我们可开发自己的TestResult类。(6)Assert(断言)类用于比较实际值与预期值，判断二者是否一致，进而确定用例是否通过。Assert类可对普通数据类型、字符串等多种情况实现自动检验。(7)TestListener(测试监听)类用于处理测试结果和提取测试驱动过程的工作特征，当测试中产生事件(开始、结束、错误、失败)时，会通知TestListener。JUnit概述3.JUnit3与JUnit4的区别目前JUnit已经发展到JUnit4.9版本，JUnit4是配合JDK1.5版本的，因此，JUnit4以上版本较JUni3.x改动较大。JUnit3强制继承TestCase类，以函数命名规则(规定函数名应形如“testXX”)来判断是否是测试方法；而JUnit4使用元数据。JUnit3和JUnit4的简单对比如下：(1)定位测试JUnit3使用命名约定和反射来定位测试。JUnit4中的测试是由@Test注释来识别的。(2)SetUp和TearDown方法JUnit3在运行(testrunner)每个测试之前自动调用setUp()方法，完成初始化字段、打开日志记录、重置环境变量等任务：JUnit4中不需强制使用setUp()方法，只需用@Before注释指示即可，甚至可用其注释多个方法，使之均在每个测试之前运行。类似地，tearDown方法替换为用@After注释指示即可。JUnit4不需要在超类中显式调用初始化和清除方法，只要它们不被覆盖即可，测试运行程序根据需要自动调用这些方法，其中，超类中的@Before方法在子类中的@Before方法之前被调用，而@After方法则以反方向执行。JUnit概述4.基于JUnit4的测试程序编写采用JUnit4编写测试程序的基本步骤如下：(1)添加测试初始化和环境清理方法，完成初始化和清理资源工作在每个测试之前/之后执行的方法：@Before和@After;在整套测试之前/之后执行的方法：@BeforeClass和@AfterClass;测试时跳过该方法：@Ignore.(2)编写测试类通过添加@Test注释，将类的方法标记为一个单元测试方法，方法名可自定义。(3)使用assertEquals()方法进行比较判断。(4)使用测试集来构建测试包，并将测试用例加入测试包。(5)使用参数化测试通过@Parameters注释的方法返回包含一组参数的集合，JUnit4自动将每组参数传入测试方法进行测试。基于Eclipse的JUnit4测试开发作为Java单元测试的事实标准，JUnit得到了各种开发工具广泛的支持，如Eclipse中集成了JUni3和JUnit4，NetBeans中可使用JUnit。下面简要说明如何在Eclipse中使用JUnit4。(1)新建Java项目时，添加testsrc源文件夹，以存放测试类的源文件，如图11.6所示。基于Eclipse的JUnit4测试开发(2)添加JUnit库并选择JUnit4版本，在Java设置中选择“库”页签并单击“添加库”按钮，在弹出的对话框中选择“JUnit”，如图11.7所示。基于Eclipse的JUnit4测试开发(3)将其他可能用到的库放入项目的lib文件夹，在此分别添加poi库用来读写Excel文件，dom4j库用来读取XML文件，jaxen库用于在dom4j中使用Xpath查询语句，如图11.8所示。基于Eclipse的JUnit4测试开发(4)在src目录下写好被测试的类后，在testsrc下创建一个同名的包，并新建JUnit测试用例，如图11.9所示。基于Eclipse的JUnit4测试开发在弹出的新建JUnit测试用例对话框(见图11.10)中应注意，填写的包名应与被测试的类保持一致。当勾选方法存根中的方法后，系统将自动生成对应的由@BeforeClass、@AfterClass、@Before、@After注释的方法。(5)写好测试驱动类后，运行结果如图11.11所示，图中的进度条表示存在测试失败的情况，且目前选择了“只显示失败”的显示模式。1.Ant的安装配置Ant安装配置的步骤如下：(1)下载安装包并解压。从下载安装包apache-ant-1.8.4-binzip，解压到计算机上的某个适当的目录，如C:Nava，解压缩时会自动在该目录下创建所下载的Ant分发包的子目录结构，如C:Nava\apache-ant-1.8.4。(2)配置环境变量。在桌面用鼠标右击“我的电脑”，选择“属性”，在打开的系统属性对话框中选择“高级”页签，并单击“环境变量”按钮，可设置JAVAHOME、ANTHOME和PATH，如图11.12所示。Ant概述2.Ant的构建文件编写要定义某个项目中Ant要执行的目标，需编写基于XML的配置文件，通常为build.xml，用于描述想应用在项目中的每个任务(Task)，通过调用目标树就可执行各种任务。配置文件可包含若干目标，或称进入点(Entrypoint)，目标的depends属性定义目标间的依赖关系，即某目标完成后才执行此目标。每个目标下包含若干任务，每个任务由实现了特定接口的对象来运行。Ant概述Ant内置了很多任务，包括与JUnit相关的两个任务junit和junitreport，分别用于执行JUnit单元测试和生成测试结果报告。Ant还支持一些可选任务，但一般需要额外的库才能工作，且可选任务与内置任务是分开单独打包的。基于Eclipse的Ant使用在Eclipse平台下要使用Ant，可遵循如下的步骤：(1)在项目根目录下新建XML文件，并以Ant编辑器的方式打开，如图11.13所示。(2)编写好build.xml文件后，选择“窗口”→“显示视图”→“Ant”菜单项，添加构建文件buildxml，查看各个目标，并选择执行某个目标，如图11.14所示。基于Eclipse的Ant使用(3)为执行Ant的JUnittask，需将junitjar和orghamcrestcore.jar也添加到lib文件夹下，以方便在Ant的执行中去引用。完整的目录结构如图11.15所示，其中class、testclass和report文件夹是由于build.xml中有相关任务，运行一次后会自动生成。(4)选择buildxml运行默认目标，或在Ant视图中选择运行特定目标，在控制台显示运行结果，如图11.16所示。测试小结保险金问题是一个函数级别的测试问题，即使如此，设计的测试用例也可能非常多。当在Eclipse平台下基于Java进行开发时，应基于JUnit提供的测试框架，编写测试脚本，自动完成测试用例的执行，以提高效率。当然，如果对JUnit不熟悉，则可能需要花费巨大的精力来编写测试脚本，且得到的测试脚本可能质量也不高，这是需要在制订测试计划时就注意到的。02信息采集系统案例实践信息采集系统的主要功能是对给定的信息文件和照片文件进行格式及内容的校验，并在信息文件和照片文件正确的情况下对多个文件进行统一汇总导出，其测试重点在于如何考虑到尽可能多的格式及内容无效的情况。自动化测试设计对应地，其测试用例的设计就是设计典型缺陷表的过程，通过构建一批典型数据文件，将多种缺陷植入这些数据文件(含信息文件和照片文件)，判断系统能否发现这些数据文件中植入已知的缺陷。因此，不需要额外开发自动化测试脚本，而仅需构建测试数据，测试用例执行的过程实际上就是导入包含典型缺陷的数据文件并运行系统来对这些数据文件进行校验的过程。表11.1给出了一个典型的包含多种缺陷的信息文件数据表。其中，身份证号省略了。备注列是为了说明设计该数据的原因，在实际的信息文件中不包含备注列。自动化测试设计部分缺陷分析尽量信息采集系统功能不多，但要考虑的无效情况太多，所以经测试后还是发现了一些缺陷，部分缺陷如表11.2所示。信息采集系统是一个系统级别的案例，但由于该系统的主要功能是对文件进行查错，因此，其测试脚本的开发主要在于测试数据文件的设计，而测试数据文件对于该系统而言，其实就是被校验的数据对象，所以该系统的测试不需要额外开发自动化测试脚本。测试小结03网络教学平台案例实践网络教学平台案例来源于课程教学建设的需要，服务于某课程教学。该网络教学平台是一个课程网站，主要功能：通过网络教学平台主要为教师和学生用户提供服务，教师通过教学平台提供课程相关资源、作业的布置及相关自测题。案例说明学生通过该平台可随时访问课堂内外与课程相关的教案、课件、案例、实验、软件、阅读材料等资源，可方便地提交课程作业，随时就课程内容进行自测自评，并可在课后与教师就课程相关专题和疑问等展开交流。该网络教学平台的最终目标是使之成为师生之间资源共享、提供实践和增进交流的平台。该网络教学平台以VisualStudio2005为开发平台，采用ASPNET和C#语言为开发语言，后台数据库采用SQLServer2005开发实现。1.系统用户及用例系统用户主要分为如下4类：(1)管理员：负责管理用户和设置用户使用期限。对应系统后台功能。(2)匿名用户：所有访问网站的未登录的用户都是匿名用户。对应系统前台功能。(3)教师用户：本课程的任课教师。对应系统前台功能。(4)学生用户：当前学期学习该门课程的学生。对应系统前台功能。案例说明案例说明受篇幅所限，在此仅分析管理员用户的用例，如图11.17所示。案例说明2.软件需求跟踪矩阵根据管理员用户的用例，可以得到其对应软件需求跟踪矩阵如表11.3所示。该表仅列出需求标题和功能简述，其他有关需求状态、变更等内容不再给出。案例说明3.系统需求规格说明受篇幅所限，仅列出添加用户和删除用户的功能需求说明，分别如表11.4和表11.5所示。案例说明测试需求分析对应上述功能需求，得到测试项如表11.6所示：添加用户的测试需求如表11.7所示：测试需求分析删除用户的测试需求如表11.8所示：1.添加用户的部分测试用例对添加用户功能，仅针对测试需求A1.1.1、A1.1.2给出部分测试用例，见表11.9、表11.10。测试用例设计2.删除用户的部分测试用例对删除用户功能，仅针对测试需求A1.2.1、A1.2.4给出测试用例，见表11.11、表11.12。测试用例设计自动化测试设计使用QTP进行功能测试时，应时刻注意，使用工具的最终目的不是为了给领导展示实施自动化测试的过程，而是为了切实提高测试效率，因此，关键仍然在于测试的设计。1.测试设计原则该教学平台已进行过较为详细的手动测试，为了提高后续版本的回归测试效率，将部分功能的测试改为自动化方式执行。基本原则如下：(1)针对大量的重复性手动测试，尽量改为自动化方式，即只要能够通过系统自动读入的方式执行的测试，均改为自动化方式进行，且注意每个测试脚本包含的流程不要太复杂。(2)对于某些无法用自动化方式实现的测试，仍采用手动测试。(3)对于交叉功能的测试，仍采用手动方式执行，例如涉及多类用户频繁登录和退出系统的流程，自动化测试脚本的开发和维护将十分繁琐和困难。自动化测试设计2.测试重点对于管理员用户的功能测试，最重要的功能模块是添加用户，即测试的重点。对各用户之间的交叉功能测试，重点应放在用户超过使用期限后无法登录、用户被删除后无法登录等内容。3.测试难点基于QTP进行自动化功能测试的难点在于：(1)预置条件的设置。例如，测试添加教师用户时，如何设置预置条件以保证每次添加用户时，系统环境一致。(2)参数的设置。例如，设计3组输入数据，如何将这3组数据写入测试脚本。(3)检查点的插入。例如，添加用户后，如何添加检查点来验证添加的用户是否成功，以及如何验证添加的用户是否按顺序添加。QTP概述QTP(QuickTestProfessional)采用关键词驱动测试的理念执行测试，用于执行重复的手动测试，简化测试创建和维护工作，主要用在回归测试中，或测试同一软件的新版本。(1)QTP测试的3个阶段使用QTP测试包括3个阶段：创建测试或组件、运行测试或组件以及分析结果。(2)QTP测试的注意事项①使用QTP进行测试时，应了解QTP的加载项。②了解QTP对浏览器的要求。③QTP的3种录制模式。QTP有3种录制模式：正常录制模式，模拟录制模式和低级录制模式。QTP概述④QTP的对象库。脚本中用到的对象都必须存在对象库中，若在脚本中使用了某个对象而对象库中并不存在，运行脚本时就会出现找不到相应对象的错误。⑤设置Action的执行次数。若执行数据列表中的多组测试数据，应设置Action的执行次数，在QTP的“当前Action”→“ActionCallProperties”中勾选“Runonallrows”，或勾选“Runfromrow()torow()”，仅选择其中指定的几行参数来执行。⑥预置条件的设置。QTP脚本在运行前均有预置条件。QTP概述(3)QTP的合理应用QTP测试的重点不是实现测试的自动化，而是提高测试效率。在实际的测试过程中，如何合理地应用QTP是使用QTP的难点所在。软件系统开发的初期是不适合用QTP进行测试的，此时，待测系统还不稳定，如果这时就采用QTP进行测试，将需要投入大量的成本，且一旦被测系统发生重大改变，将影响很多的自动化测试和组件。总的来说，QTP主要是用于回归测试，它最大的好处是可以重用，在被测系统改动不大的情况下，由QTP将之前的用例全部执行一次，使用回归的次数越多，使用率越高，就越能体现使用QTP的优势。基于QTP的功能测试1.测试环境该网络教学平台的测试环境如表11.13所示。基于QTP的功能测试2.测试脚本开发(1)测试脚本编写的一般步骤测试脚本，也就是测试用例的实现过程，一般步骤为：①录制，将用例中需要测试的具体步骤用QTP录制下来；②脚本增强，修改脚本以满足测试的需要，如添加检查点等；③测试数据添加，如果脚本中进行了参数化，将需要测试的数据添加到数据列表中；④对象库管理，如果修改脚本时用到了新的对象，则将该对象添加到对象库中便于识别。基于QTP的功能测试(2)测试脚本开发(以成功添加教师用户为例)以添加教师用户的测试为例，针对有效用户的测试见表11.9中测试需求A1.1.1对应的测试用例。(3)测试脚本开发(以添加教师用户的有效性校验为例)仍以添加教师用户为例，当输入数据无效时对应的部分测试用例见表11.10，完整的用例应为8个，此时，所有执行步骤完全相同，可直接通过参数化输入测试数据。基于QTP的功能测试3.测试执行脚本编写完成后，即可执行测试脚本。表11.10中测试用例脚本的执行过程部分截图如图11.21-图11.23所示。可以看到，当用户名末4位与身份证号不相同时，系统告警。基于QTP的功能测试在实际执行过程中可能会碰到这样的情况，运行测试脚本时，一些随机生成的验证码无法用脚本来输入，这时需要在脚本运行的过程中手动添加这些内容，且手动添加内容时，时间不能过长，否则脚本执行将中断，如图11.24所示。基于QTP的功能测试4.测试结果分析测试脚本执行完成后，QTP自动生成测试报告，列表如图11.25所示。图中打勾的表示测试通过，未发现缺陷。测试结果中身份证验证的结果如图11.26所示。基于QTP的功能测试验证输入无效数据时系统是否告警的结果如图11.27所示。当测试脚本执行后测试不通过，则将在测试报告相应项的前面显示叉号，图11.28给出了测试脚本A1.1.4的执行结果。基于QTP的功能测试从图11.28可以看出，用户名重复时存在Bug，详细内容见图11.29，测试报告中指出错误原因为“用户名重复系统没有告警，出现功能错误”，对应的缺陷写入缺陷报告，不再给出示例。实际上，在详细的手动测试之后，基于QTP对该网络教学平台进行自动化测试后又发现了20个缺陷。测试小结网络教学平台是一个典型的Web应用系统，包含多类用户、多个子系统、提供较多功能，在功能测试的层面上，当流程、界面稳定时，可采用QTP工具进行自动化功能测试。良好的测试效果关键取决于测试用例的设计，以及如何根据测试用例的要求来构建测试脚本，通过原始的录制、回放方式得到的脚本肯定是不满足要求的，而设计得过于复杂，包含太多流程、操作和校验点的脚本也是不适用的。04分布式搜索系统案例实践案例说明分布式搜索系统是一个基于B/S模式的图书馆馆藏文献查找系统，系统核心功能是提供智能搜索服务，即授权用户登录系统后，通过输入一些描述信息，如文献题目、作者、书评、目录、内容简介等内容，这些内容可能是完整的，或者仅给出部分词汇，也可能只是与文献相关描述有一定关联而已，系统需通过自动对用户输入进行理解，并在资料库中进行搜索匹配，然后将与用户输入最匹配的馆藏文献以一定的排序方式呈现给用户，用户通过浏览文献来查阅各馆藏文献的具体描述信息，并判断该文献是否是自己所需要借阅的文献。案例说明该系统的核心特点是：(1)海量数据的分布式存储。由于文献数量众多，每个馆藏文献不仅包含标题、作者、出版社等基本信息，还可能包含多种格式的附件，且文献数量将随着时间的推移呈逐步上升趋势。面对TB级的文献存储量，必须采用分布式存储方式对其进行存储。(2)分布式搜索方式。系统用户数量众多，且分散在多个地点，用户数也呈稳步上升趋势，为保证为用户提供快速的搜索响应，必须采用分布式搜索方式。(3)高稳定、可靠的系统部署。对于一个庞大的系统而言，必须保证整个系统部署的稳定、可靠，一旦系统停止服务，即使极短时间，也很可能导致投诉电话被打爆。(4)智能化的搜索。用户在搜索文献时并不知道系统中有哪些文献，其输入可能很不专业，系统需自动对用户输入进行词法、语法甚至语义分析，然后基于专业特性计算文献匹配度，同时为用户推荐更多相关文献。自动化测试设计分布式搜索系统的本质是基于分布式存储和分布式搜索提供一个稳定、可靠的T级海量数据智能搜索服务，其中，智能搜索的效果主要通过查全率、查准率、用户反馈等指标加以衡量，不再详述。在此主要考虑的是作为一个应用系统而应满足的核心功能的性能要求，即面对T级海量数据，面对大量用户的并发搜索请求，系统性能如何。然而，在系统上线之前，用户不可能提供实际的数据，且一旦上线，不能允许系统频繁出错，这样的性能测试难点在于：(1)如何通过性能测试证明当前方案的可行性；(2)如何通过性能测试预测实际上线后的性能；(3)如何通过性能测试来寻找系统进一步优化的方向。LoadRunner概述LoadRunner是惠普公司开发的一款性能测试工具，主要用于C/S和B/S结构的软件系统测试。该产品通过模拟虚拟的并发用户数来对系统进行测试。与WinRunner不同，LoadRunner(简称LR)可以跨平台使用，适用于Windows、Linux等多种操作系统下。LoadRunner是最好的企业级软件性能测试工具之一。LR的运行机制是通过用一台或几台计算机产生成千上万虚拟用户，模拟实际用户行为，虚拟用户(Vuser)通过执行典型业务流程模拟设计用户的操作，对于Vuser执行的每个操作，LR向服务器或类似的企业系统提交输入信息，增加Vuser的数量可以增大系统上的负载。若要模拟较多用户负载的情况，可通过Controller设定虚拟用户数执行一系列任务的Vuser，如观察1000个Vuser同时登录系统并进行搜索时服务器的行为。通过使用LR将客户端/服务器的性能测试需求划分为多个场景，通过场景定义每个测试会话中发生的事件。LoadRunner概述LR提供多种Vuser类型，适于各种特定负载测试环境。Vuser使用Vuser脚本进行描述，脚本中包含在方案中独立并录制服务器性能的函数。LR由如下3部分构成：(1)VuGen:脚本生成器，是LR用于开发Vuser脚本的主要工具，可用于录制和运行脚本。(2)Controller:控制器，通过手动和基于目标的两种方法来设计场景，并通过设置场景模拟用户行为，在场景运行期间自动收集应用服务器软、硬件相关数据，存放到小型数据库文件中，从而独立监控和分析系统性能和功能。(3)Analysis:分析器，当运行完成，数据收集工作完成后，通过该分析器对测试结果数据进行分析，包括各种图表，并可根据需要进行合并，还可以比较两次运行结果之间的差异，利于系统的性能调优，最终的输出结果也可通过该分析器以Word或HTML格式输出。基于LoadRunner的性能测试1.测试环境(1)硬件环境2台主服务器，配置分别为：①AMDAthlon(tm)ⅡX4635Processor2.90GHz，内存4.00GB②Intel(R)Core(TM)2DuoCPUT83002.40GHz，内存2.00GB2台从服务器，配置均为：AMDAthlon(tm)ⅡX2240Processor2.81GHz，内存2.00GB1台测试客户端，配置为：CPU:Intel(R)Core(TM)i5-2410MCPU2.30GHz，内存2.00GB(2)软件环境操作系统：Ubuntu10.04，WindowsXP软件配置：Jdk1.6.029，Tomcat6.0.35，Apache2.22，Solr3.5.0基于LoadRunner的性能测试(3)系统部署系统部署如图11.30所示。基于LoadRunner的性能测试(4)网络环境网络环境如图11.31所示。基于LoadRunner的性能测试2.测试数据测试所用原始数据见表11.14(在此仅截取2012年3月23日到3月26日之间的数据):基于LoadRunner的性能测试生成的索引数据见表11.15。搜索主要是针对索引数据展开，而非针对原始数据进行搜索，因此，需要重点关注的不是原始数据的规模，而是生成的索引数据的规模，以及原始数据与索引数据在规模上的关系。从数据对比看出，索引数据相比原始数据的规模级别相差较大，其存储要求不高，且数据核心在数据库数据而非附件文档，为此，构造原始数据时重点并非附件文档，主要利用数据库数据增大索引数据规模，这样也可节省硬盘空间，便于展开有限条件下的性能测试。基于LoadRunner的性能测试3.测试需求测试主要针对搜索模块。性能要求：分别在250、500、1000、1500、2000的并发用户数条件下，要求系统的平均响应时间不大于3秒。4.测试风险本性能测试并非在实际用户使用环境中进行测试(即模拟的测试环境和客户实际使用环境配置差别较大)，因此，测试结果与实际使用环境中的结果可能存在一定的出入。另外，测试环境中的数据量相比实际使用环境中数据量少得多，且系统上线后