软件测试培训课件（PPT精品）.ppt

《软件测试培训课件（PPT精品）.ppt》由会员分享，可在线阅读，更多相关《软件测试培训课件（PPT精品）.ppt（326页珍藏版）》请在三一文库上搜索。

1、ISTQB 基础级培训讲义,北京昱达环球科技有限公司 版权所有,,北京昱达环球科技有限公司,目录,一、国际软件测试认证委员会(ISTQB) 简介 二、软件测试基础 三、软件测试与软件生命周期 四、软件静态测试技术 五、软件测试设计技术 六、软件测试管理 七、软件测试工具,昱达公司简介,昱达环球科技有限公司(IGS)是中国首家专注于全球化、国际化和本地化新兴产业，开展全球化咨询、技术开发和人才培训，为中外企业提供信息全球化解决方案的供应商，是国际软件测试认证委员会（ISTQB）中国分会在北京唯一授权培训和认证机构。 公司地址：北京市朝阳区北苑路68号星河写字楼204室 邮政编码：100012 公

2、司网站： 培训邮箱：CSTQB 联系电话：010-84935334 移动电话：13683312675,一、ISTQB CTFL简介,,CSTQB软件测试基础级培训教程,ISTQB与CSTQB简介,ISTQB简介 国际软件测试认证委员会ISTQB (International Software Testing Qualification Board)于2002年在英国成立。 ISTQB是国际唯一权威的软件测试资质认证机构，现有包括美国、德国、英国、法国、日本等47个成员国。 中国软件测试认证委员会 (CSTQB)在2006年成为ISTQB的正式成员。 ISTQB培训与认证体系 ISTQB-Cer

3、tified Tester培训及认证体系分为三个级别： 基础级/Foundation Level 高级/Advanced Level：3年以上测试工作经验 专家级/Expert Level ：5年以上测试工作经验 培训者获得基础级证书后，可申请参加更高级别的培训和认证考试，并获得相应证书。,CSTQB FL 培训内容,ISTQB CTFL认证考试,考试形式 闭卷笔试 考试卷包含40道单选选择题（给定的答案中只有一项是正确的） 考试时间为1小时 分数达到65%以上（26题以上含26题）通过考试 考试内容与比例,二、软件测试基础,,CSTQB软件测试基础级培训教程,目录,为什么需要软件测试 软件测

4、试与软件质量 软件测试的目的与原则 软件测试过程,软件测试术语（1）,术语 错误 Error，Mistake 缺陷 Defect，Bug，Fault 失效 Failure 说明 程序员可能会犯错误，由此在程序或文档中产生缺陷。 如果执行了代码中的缺陷，软件将可能无法实现应该实现的功能或者产生了不应该实现的结果，由此产生失效。 软件、系统或者文档中的缺陷可能导致失效，但是并不是所有的缺陷都会导致失效。 缺陷的产生是因为程序员容易犯错误，可能是因为时间压力，复杂的代码，架构复杂，技术变更，或者系统交互等引起的。 失效也可能是环境条件引起的。例如，辐射，磁场，电场，污染导致硬件故障。或者由于改变了硬

5、件的条件，对软件的执行产生影响。 软件系统的失效不可能是老化或磨损引起的。,软件测试术语（2）,错误error是广义的概念。错误是人为的原因导致一个不正确的结果。它可以是程序内的内部错误，也可能是文档内的错误。 缺陷是错误的具体表现，可以是不正确的文档，程序段，指令或数据定义，它们可能会引起一个外部的失效(failure) 。 bug，defect和fault同义。因为存在的缺陷(defect)而导致软件的运行失败叫失效。 失效是缺陷在执行测试软件时的外部反映。失效是（规范说明）期望的值与实际（观察到）的值存在偏差。例如系统的不正确的反应，崩溃，死机等。 当缺陷引起了运行错误或对用户产生了消极

6、影响时，它就被称为失效。对缺陷最大的担心就是它会转变为失效，而失效将会对用户产生损害。 有一些缺陷可能永远也不会转变为失效，但有时一个缺陷又可能会引起上百万的失效。 缺陷可以通过静态测试发现,而失效只能通过动态测试发现。,软件测试的总体目标,总体目标 发现缺陷 获取对产品质量的信心 提供用于决策的信息 预防缺陷,早期测试,开发阶段的测试,运行阶段的测试,静态测试,组件测试,集成测试,系统测试,验收测试,非功能测试,维护测试,预防缺陷,发现缺陷,建立信心,提供信息,不同测试阶段的测试目的,软件需求阶段对文档的静态测试是为了预防缺陷 在开发阶段执行的测试（组件测试、集成测试和系统测试），测试的主要

7、目的可能是尽可能的使软件失效，从而发现和修改尽可能多缺陷。 在验收测试中，主要目的可能是用来确认系统是否按照预期工作的，从而在系统是否满足系统需求方面得到信心。 在有的情况，测试的主要目的可能是对软件的质量进行评估（不是为了修改缺陷），从而为利益相关人提供这样的信息：在给定时间内发布系统版本是否存在风险？ 在运行测试阶段，测试的主要目标可能是为了评估系统的特征，比如可靠性或可用性等。 维护测试通常是为了验证在变更开发过程中是否有新的错误引入。,测试和调试的区别,调试（Debug）和测试（Test）是两个不同的概念。 测试 测试可以发现由于软件缺陷引起的失效。 测试员执行测试。 调试 调试是一种

8、开发活动，用来识别引起缺陷的原因，修改代码以及验证是否正确的修改了软件的缺陷。 开发人员执行调试。 关系 开发人员调试后的软件需要测试员进行确认测试，确认修改的代码已经解决了失效问题。 开发人员除了调试，也执行某些类型的测试,测试在软件开发、维护和运行中的角色,测试是软件质量保证的关键活动和方式 对软件系统和文档进行严格的测试,可以减少软件系统在运行环境中的风险，假如在软件正式发布之前发现和修正了缺陷，就可以提高软件系统的质量。 测试对象包括软件产品（软件程序、手册和联机帮助）和开发过程产生的文档 测试也可能需要满足合同和法律法规的需求，或者是为了满足特定的行业标准 认证测试，微软认证Cert

9、ification GB18030测试 ISTQB测试认证 测试的工作产品(Work Product) 测试的工作产品指的测试依据（Testing basis） 例如，业务场景、用例、需求规格说明、设计文档和代码,测试与软件质量,借助软件测试，可以通过发现的缺陷度量软件的质量，包括功能和非功能软件需求和特性（例如，可靠性、易用性、有效性、可维护性以及可移植性）。 测试如果发现较少或者没有发现缺陷，可以增强对软件质量的信心。正确设计的测试执行通过后减少了系统的整体风险级别。测试发现的缺陷修正（Fixed）后提高了软件系统的质量。 应该从以前项目中吸取教训。理解其它项目中发现的缺陷的根本产生原因后

10、，改进流程，这样可以避免再次产生同样的缺陷，相应地改进了未来软件系统的质量。这是质量保证的体现。 测试应该集成为质量保证活动的一个组成部分（与开发标准、培训和缺陷分析并列）。,软件测试心理学,软件测试需要独立性 测试机构的独立有利于关注开发过程中工作产品中可能存在的缺陷，可以避免开发人员（作者）的偏见 独立并不等于完全代替开发人员，开发人员能有效的找到自己工作产品中存在的缺陷 软件测试独立的优点 独立的测试员可以做到没有偏见，可以发现一些其他不同的缺陷。 一个独立的测试员可以验证在系统规格说明和实现阶段所做的一些假设。 软件测试独立的缺点 与开发小组脱离（如果完全独立）。 开发人员可能失去对软

11、件质量的责任感。 独立的测试员可能是项目的瓶颈或者要为软件发布延时负责。,软件测试独立的方式,软件测试独立的方式 测试的设计由开发人员自己完成； 测试由开发队伍的其他开发人员完成； 测试独立于本项目的开发队伍； 测试独立于本开发企业，来自于独立的第三方测试机构。,软件测试与开发如何相处,合作、沟通、交流、中立、目标一致 测试人员发现软件工作产品的缺陷某种程度上是对工作产品和其作者的批评，所以软件测试常常被看成一种消极的活动，尽管软件测试对软件开发的风险具有很强的规避作用。 如果测试人员与分析、设计和代码开发人员能很好的沟通，那么他们对测试人员的不好感将避免。软件工作产品的缺陷信息有助于提高开发

12、者的技能，也为开发过程节约成本和时间，降低软件开发风险。 测试人员和测试管理者之间也应该具有好的沟通，通过规则的交流途径交流测试中的缺陷信息、进展情况和风险。 如果测试人员把自己发现缺陷作为一个新闻来传播，那么会给沟通带来麻烦。,软件质量保证,软件质量保证(SQA)的对象是过程，质量保证的重要工作通过预防、检查与改进来保证软件质量。QA采用“全面质量管理”和“过程改进”的原理开展质量保证工作。 软件测试与软件质量保证的关系 SQA侧重对流程中过程的管理与控制，是一项管理工作，侧重于流程和方法。 软件质量保证的职能是向管理层提供正确的可视化的信息，从而促进与协助流程改进。 SQA还充当测试工作的

13、指导者和监督者，帮助软件测试建立质量标准、测试过程评审方法和测试流程，同时通过跟踪、审计和评审，及时发现软件测试过程中的问题，从而帮助改进测试或整个开发的流程等 有了SQA，测试工作就可以被客观的检查与评价，同时也可以协助测试流程的改进。 . 测试是对软件产品的检验，是一项技术性的工作，软件测试的对象是产品，测试人员要“执行”软件，对过程中的产物-开发文档和源代码进行走查，运行软件，以找出问题，报告缺陷。 软件测试是寻找缺陷的策略，SQA是规避缺陷的策略。,软件质量保证与软件测试的比较,软件测试的充分性,为什么考虑测试的充分性？ 测试需要给利益相关者提供足够的信息，帮助他们决定是否发布被测软件

14、或系统。软件可以发布表示可以进入下一个开发过程，或将系统交付给用户。 测试的特征 测试是高风险的质量保证活动，测试是不能穷尽的 在有限的预算、时间、资源下，尽可能多的发现和报告缺陷 判断测试是否充分的考虑因素 风险（包括技术风险、商业产品风险和项目的风险等） 项目在时间和预算上的限制等。,软件测试的目的,Grenford JMyers 测试是程序的执行过程，目的在于发现错误 一个好的测试用例在于能发现至今未发现的错误 一个成功的测试是发现了至今未发现的错误的测试 Bill Hetzel 提出了测试目的不仅仅是为了发现软件缺陷与错误，而且也是对软件质量进行度量和评估，以提高软件的质量。 当前业内

15、普遍接受的测试目的 以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正各种错误和缺陷提高软件质量，避免软件发布后由于潜在的软件缺陷和错误造成的隐患所带来的商业风险。简而言之，软件测试的目的是降低软件风险，保证软件质量 测试是以评价一个程序或者系统属性为目标的活动，测试是对软件质量的度量与评估，以验证软件的质量满足用户的需求的程度，为用户选择与接受软件提供有力的依据。 通过分析错误产生的原因还可以帮助发现当前开发工作所采用的软件过程的缺陷，以便进行软件过程改进。同时，通过对测试结果的分析整理，还可以修正软件开发规则，并为软件可靠性分析提供依据。,软件测试的原则,所有的软件测试都应追

16、溯到用户需求 应当把“尽早地和不断地进行软件测试”作为软件测试者的座右铭 完全测试是不可能的，测试需要适可而止 测试只能证明软件存在错误而不能证明软件没有错误 充分注意测试中的缺陷群集现象 程序员应避免检查自己的程序（测试独立性） 测试的“杀虫剂”效应,所有的软件测试都应追溯到用户需求,从根本上讲，判断软件现象是否是缺陷的依据是是否满足用户需求 显性需求 隐性需求 软件的目的是使用户完成预定的任务，并满足用户的需求 软件测试所揭示的缺陷和错误使软件达不到用户的目标，满足不了用户需求,尽早地和不断地进行软件测试,在软件或系统开发生命周期中，测试活动应该尽可能早的介入，并且应该将关注点放在已经定义

17、的测试目标(test objective)上 早期发现和修改缺陷成本最小 每个软件Build都应该被测试，而不是等到最后一个Build才进行测试 经验数据示例,穷尽测试是不可能的,测试是有计划的，产品要发布，市场不允许无限期测试 被测试软件复杂，需要测试的内容很多 测试预算和资源有限，测试需要适可而止 除了小型项目，进行完全（各种输入和前提条件的组合）的测试是不现实的。 通过运用风险管理(Risk management)和不同系统功能的测试优先级，来确定测试的关注点，从而替代穷尽测试,测试显示缺陷的存在,测试只能表明软件存在缺陷，不能说明软件不存在缺陷 测试可以减少软件中存在缺陷的可能性，但即

18、使测试没有发现任何缺陷，也不能证明软件或系统是完全正确的 由于软件测试不能穷尽测试，因此，经过测试的软件仍然含有未知的缺陷,缺陷的群集现象,版本发布前进行的测试所发现的大部分缺陷和软件运行失效是由于少数软件模块引起的 如果发现某一程序模块似乎比其他程序模块有更多的错误倾向，则应当花费较多的时间和代价测试这个程序模块。,测试的独立性,人为心理因素，人们认为揭露自己程序中的问题总不是一件愉快的事，不愿否认自己的工作 由于思维定势，人们难于发现自己的错误 程序员应该避免全部测试自己的程序和文档 为达到测试目的，应由客观、公正、严格的独立的测试部门或者独立的第三方测试机构进行测试,测试的“杀虫剂”效应

19、,同样的测试用例一遍一遍重复进行测试，最后将不再能够发现新的缺陷 为了克服这种杀虫剂悖论，测试用例需要经常性的评审和修改 需要不断增加新的不同的测试用例来测试软件或系统的不同部分，从而发现潜在的更多的缺陷 重复测试、不间断测试、更新测试内容和测试用例,软件测试的基本过程,软件测试计划和控制 测试分析和设计 测试实施和执行 退出测试的标准 测试报告 测试结束活动,开始,结束,测试计划,跟踪 控制,分析与设计,实现与执行,评估与报告,完成测试,测试计划 测试进度表,测试方法 逻辑测试用例,测试规格说明 物理测试用例 测试环境.,测试日志 缺陷报告 测试总结报告,软件测试计划和控制,定义 ANSI/

20、IEEE软件测试文档标准829-1983将测试计划定义为：“一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了测试项、被测特征、测试任务、人员安排，以及任何偶发事件的风险。” 作用 借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。 内容 指明测试范围、方法、资源，以及相应测试活动的时间进度安排表。 包含测试目标、项目概述、组织形式、角色及职责、测试对象、测试通过和失败的标准（测试何时结束、度量的尺度如何、度量的评价标准等）、测试挂起的标准及恢复的必要条件、测试任务的

21、安排、应交付的测试工作产品、工作量估计等。 特点 一般开始于软件需求分析结束阶段,软件测试计划内容与实例,计划内容 测试项目概述 需要测试的功能 不需要测试的功能 测试策略 测试中断与恢复的规定 测试完成后需要提交的内容 测试环境的设置 测试人员的工作分配 测试人员的能力与培训 测试进度表 测试风险 计划实例 简单的测试计划 复杂测试计划 附录A：测试计划模板,软件测试控制,利用事先定义的度量评估和分析测试结果 监督和记录： 测试进度 测试的覆盖状况 测试的结束条件 是否偏离计划 确定是否需要采取纠正措施 确定是否需要更改原计划 对测试计划的执行进行反馈,软件测试分析和设计,不同阶段的分析和设

22、计依据不同 在组件（单元）测试阶段分析的依据是详细设计规约 在集成测试阶段分析的依据是概要设计规约 在系统测试阶段分析的依据是需求分析规约 在分析过程中规约不是惟一的依据，由于软件开发过程中的文档可能不是十分的完整，这就要求测试分析人员从其他方面进行分析作为补充。,软件测试分析和设计,对测试依据（需求、结构、设计、接口）进行评审/分析，为对所有测试点设计测试用例做好准备 以测试分析为基础并结合软件测试方法和技术进行测试设计 从产品原型分析角度出发，与当事人交流和沟通（开发者和用户等） 对需求和测试对象的可测试性进行评价 在分析测试对象、规约说明、测试对象间的关系和结构的基础上，确定测试条件（例

23、如验证需求）以及所需的测试数据 使用测试策略内规定的测试方法设计逻辑测试用例（测试用例的架构） 测试用例的设计应该从逻辑测试用例到实际测试用例的设计过程，设计用例的多少应该充分考虑测试子系统或模块在整个系统中的重要性，用例的设计同时要考虑用例执行应该具备的前提条件设计测试环境，包括必要的基本设施和工具 测试设计包括测试用例设计、测试工具设计或选择、测试脚本设计、测试缺陷管理工具设计或选择，测试管理模板设计 测试用例设计是测试设计的重要内容，黑盒、白盒、灰盒测试用例设计 从软件的流程图、功能点、状态图、use-case图等方面进行测试用例的设计 细化测试进度表,测试的实现与执行,测试的实现(Im

24、plementation) 从测试条件具体到可执行的测试用例（即从逻辑测试用例到实际的测试用例），以及必要的测试件（文档和工具） 借助于测试准则，确定测试期望结果 根据风险判定测试用例的优先级 生成测试数据 测试对象的输入值和状态值以及期望值，或在运行有关的测试用例后的期望结果 建立和检查测试环境，以确保配置的正确性 构建测试台(Test bed)和编写测试自动化脚本 组合成测试套件（Test suites）/测试序列（多个单个测试用例形成的逻辑集），并完成测试规程（Test procedure） 测试套件是用于被测组件/系统的一组测试用例。在这些测试用例中，一个测试用例的后置条件（Post

25、condition）常作为下一个测试的前置条件（Precondition）,测试的实施与执行,测试的准备 测试环境的准备（软件、硬件、网络） 测试对象是否按照规定构建并准备完毕，测试程序、测试脚本是否准备完毕 缺陷管理系统和测试文档是否准备完毕 测试辅助件的准备：测试驱动器和测试桩、测试模拟器及测试工具等。,测试的实施与执行,测试的执行 测试某个软件组合或系统并产生实际结果的过程 按照测试计划和测试规约说明执行手动测试的测试用例和自动测试的测试用例 比较实际的和期望的结构，分析期望和实际结果偏差的原因（测试对象和测试件的错误等） 提交事件（Incidents），即在测试过程中出现的，并且在此后

26、还需要检查或者关注的事件 记录 测试结果（测试日期、时间、测试人员、输入的测试数据和期望值、测试对象的ID标识/版本号，测试工具和测试方法，测试结果和后续动作包括测试缺陷报告和修改测试用例），如果可能给出错误的原因，记录特殊情况。 如有必要，补充新的测试用例 执行确认测试和回归测试，用于确认错误更改是否有效，或者执行已经更改的测试用例 测试日志 即关于测试执行的按时间顺序的详细记录,测试退出的标准,测试退出的标准 计划中的测试用例是否执行完毕 是否达到功能、语句等计划的覆盖指标 继续测试发现缺陷的数量减少低于度量标准等 满足测试计划中的测试退出标准 测试评估 对每个测试阶段都要进行评估是否达到

27、测试退出的标准 对测试记录评估，判断测试是否达到了测试计划规定的测试退出准则 达到测试退出准则后，才进入下一个测试阶段 评价是否需要继续执行进一步的测试或者需要更改已经定义好的测试退出准则。例如，准则无法执行或者资源有限（费用、时间和人员）无法达到 每个测试阶段结束后提供对被测系统和测试过程当前状况的评价 给相关决策人员提交测试报告（包括测试活动和测试结果的文档，在规定的测试退出准则下的测试运行的评估）,测试结束活动,测试结束的条件 当一个软件产品正式上线应用后 当开发（或测试）达到一个里程碑（Milestone) 一个维护版本结束时 测试结束活动的内容 检查是否所有计划的交付物都产生并交付了

28、，或者产生交付了哪些 事件报告的完成（缺陷报告，偏差报告.） 为仍然存在的错误/偏差提供变更需求 系统验收的文档 测试结果分析，测试总结，测试信息和数据备份（测试规约说明书、数据、测试日志等） 对测试发现的缺陷进行统计分类并分析原因 制定的测试计划和实际的计划执行的差距并分析原因，哪些事件或风险没预料到，总结好的经验等 分析每个测试活动的计划和实施之间的偏差，并判断原因 统计测试结果与测试开销的关系 软件、硬件、文档和邮件的备份、销毁和退还,总结,失效是缺陷在执行测试软件时的外部反映，当缺陷被执行时产生软件失效 软件测试独立有4种方式 软件测试和软件开发是合作和交流的关系 软件测试关注的是产品

29、，软件质量保证关注的是过程 实施软件测试需要理解和遵守条基本原则： 追溯到用户需求 尽早和不间断测试 不可能穷尽测试 测试不能表明软件没有缺陷 缺陷的群集现象 开发人员避免检查自己的程序 避免杀虫剂效应,总结,软件测试的内容 计划和控制 分析和设计 实施和执行 退出测试的标准 测试报告 测试结束活动,练习作业,什么是软件测试？ 软件测试的目的是什么？ 软件测试的内容有哪些？ 什么是软件缺陷？软件失效？ 软件缺陷和软件失效之间有什么关系？ 引起软件失效的因素有哪些？ 软件为什么会存在缺陷？ 软件测试在软件开发、维护和使用中扮演什么角色？ 软件测试独立有什么好处？ 软件测试独立有哪些形式？ 软件测

30、试和软件开发人员应该如何相处？ 什么是软件质量？ 什么是软件质量保证？,练习作业,软件测试和软件质量保证之间有什么相同和不同？ 确定软件测试的充分性的因素有哪些？ 软件测试的一般规则有哪些？ 软件测试的基本过程包括哪些内容？ 在软件测试的基本过程内，各个过程包括哪些内容？,三、软件测试与软件生命周期,CSTQB软件测试基础级培训教程,北京昱达环球科技有限公司 版权所有,,目录,软件开发模型 软件测试级别 软件测试类型 维护性测试,软件开发模型,软件开发模型简介,软件生命周期 软件需求、分析、设计、实现、测试、部署Deploy/Release、维护和退出的过程，称为“软件生命周期”（Softwa

31、re Life Cycle） 概述 软件开发模型是指软件开发所依据的方式和过程 从事软件测试为什么要熟悉开发模型？ 测试不是孤立存在的，测试活动与开发活动是息息相关的 每个开发活动都有相对应的测试活动 不同的开发生命周期模型需要不同的测试方法 每个测试级别都有其特有的测试目标 对于每个测试级别，需要在相应的开发活动过程中进行相应的测试分析和设计 在开发生命周期中，测试人员在文档初稿阶段就应该参与文档的评审 如何选择开发模型？ 根据项目的内容 根据产品的特征,软件开发V模型图,验证与确认(V & V),验证Verification 翻译为“验证”，也可以译为“检验”，即验证或检验软件是否已正确地

32、实现了产品规格书所定义的系统功能和特性。“验证”强调的是“规定规格要求” 验证过程提供证据表明，软件相关产品与所有生命周期活动（需求分析、设计、编程、测试等）的要求（如正确性、完整性、一致性、准确性等）相一致。 验证是否满足生命周期过程中的标准、实践和约定； 验证为判断每一个生命周期活动是否已经完成，以及是否可以启动其他生命周期活动建立一个新的基准。 可以用英文描述“Are we building the product right?”。是否正确地构造了软件？即是否正确地做事，验证开发过程是否遵守已定义好的内容。 测试结果要和相应的开发需求定义的结果比较而进行功能准确性测试 软件生命周期中的每

33、一个阶段的成果是否满足上一个阶段所设定的目标,验证与确认(V & V),确认Validation 翻译为“确认”，但更准确地翻译，应该是“有效性确认”。保证所生产的软件可追溯到用户需求的一系列活动。确认过程提供证据，表明软件是否满足客户需求（指分配给软件的系统需求），并解决了相应问题。 “确认”检验软件是否满足用户需求，保证软件的功能和性能符合用户的实际需要。 可以用英文描述“Are we building the right product?”。是否构造了正确的软件？即是否正在做用户真正所需要的事。 被测试内容的正确性及完整性与相应的用户需求进行比较，即针对测试设计内容本身的准确性进行确认

34、问题与思考 既然软件测试的目标是满足用户的要求，而测试中的“确认”方法是检验软件是否满足用户需求，那么为什么还要使用“验证”呢？,V模型分析,概述 最早由Pual Rook于80年代末提出。 其左右分支形成了V字型，因此称作V模型。 含义 V 模型指出软件测试不仅仅是软件开发的一个独立阶段，而应贯穿于整个软件生命周期中 V 模型中的右分支列出的软件测试任务和相应的左分支列出的软件开发任务在整个软件项目中有着同等的重要性 该模型描述了基本的开发过程和测试行为，非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。 V模型的缺点 仅仅把测试过程作为在

35、需求分析、系统功能设计、系统架构设计及编码之后的一个阶段 容易使人理解为测试是软件开发的最后的一个阶段，主要是针对程序进行测试寻找错误，而需求分析阶段的隐藏的问题一直到后期的系统测试和验收测试才被发现。 说明 在测试实践中，V模型中的各个开发及测试阶段可往往会根据具体情况有所增减甚至组合或重新排列,W模型图,W模型分析,概述 Evolutif公司在1999年提出 W模型由两个V字型模型组成，分别代表测试与开发过程 表示了测试与开发的并行关系 含义 W模型体现了“尽早地和不断地进行软件测试”的原则 W模型有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动

36、中，以尽早地找出缺陷所在 对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度 模型缺点 需求、设计、编码等活动被视为串行的，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作 对于软件开发复杂多变的情况，W模型并不能完全解除测试管理面临的困惑,迭代-增量模型图,原型开发模型 快速开发模型 RUP（Rational Unified Process），统一软件开发过程 Agile Development敏捷开发,迭代-增量模型分析,在每次迭代过程中,对迭代产生的系统可能需要在不同的测试级别上进行测试。 通过将

37、增量模块加入到以前开发的模块中，形成一个逐渐增大的系统，这个系统同样需要进行测试。 在完成第一次迭代后，对所有的迭代进行回归测试会变得越来越重要。 验证和确认可以在每个增量模块中进行。,H模型图,H模型分析,概述 将软件测试看着一个独立的流程贯穿于软件产品的开发周期，当某个测试条件就绪时，软件测试工作就可以开始 含义 将测试活动完全独立出来，形成了一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来 软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行 模型指出软件测试要尽早准备，尽早执行 不同的测试活动可以是按照某个次序先后进行的，但也可能是反复的，只要某个测试达到

38、准备就绪点，测试执行活动就可以开展,其它模型,X模型 提出针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的交接，通过集成最终合成为可执行的程序 前置测试模型 体现了开发与测试的结合，要求对每一个交付内容进行测试,软件测试级别,测试级别概述,软件开发的不同阶段对应不同级别(Level)的测试 组件测试（单元测试） 在软件编码结束后，对编写的每一个程序模块进行测试 集成测试（组装测试，联合测试 ） 在模块集成后，对集成在一起的模块组件，有时也可称为“部件”进行测试 系统测试 将整个程序模块集成为软件系统安装在运行环境下，对于硬件、网络、操作系统及支撑平台构成的整体系统进行测试 验收测试（

39、交付测试，确认测试） 在上述测试后，需要检测与证实软件是否满足软件需求说明书中规定的要求,良好的测试所具有的特征,特征 每个开发活动都有相对应的测试活动 每个测试级别都有其特有的测试目标 对于每个测试级别，需要在相应的开发活动过程中进行相应的测试分析和设计 在开发生命周期中，测试员在文档初稿阶段就应该参与文档的评审 注意： 根据项目的特征或系统的架构，可以对测试级别进行合并或重新进行组合。 比如，对于商业现货软件(COTS)产品集成到某个系统，购买者可以在系统级别（例如：与基础设施集成、与其他系统的集成或与系统应用的集成）进行集成测试和验收测试（功能的和/或非功能的测试，用户和/或运行测试等）

40、。,各个测试级别需要明确的内容,测试的总体目标 测试用例设计需要参考的工作产品（即测试的依据） 测试的对象（即测试什么） 发现的典型缺陷和失效 对测试用具的需求 测试工具的支持 专门的方法和职责等 注意： 如果某些数据属于系统的一部分，那么在测试计划时就应当考虑是否对系统配置数据进行测试。,组件测试概述,概述 组件测试是对软件基本组成单元进行的测试，一般在代码完成后由开发人员完成，测试人员辅助。 组件测试的目的是检查代码是否符合设计和规范。 测试依据 组件需求说明 详细设计文档 代码 测试对象 组件 程序 数据转换/移植程序,组件测试的特征和测试内容,特征 组件测试可能包括功能测试和特定的非功

41、能特征测试，比如资源行为测试（如内存泄漏）或健壮性测试和结构测试（比如分支覆盖）。 根据工作产品，例如组件规格说明、软件设计或数据模型等设计测试用例。 测试内容 模块接口测试 检查局部数据结构能否保持完整性 模块边界条件测试 模块执行路径测试 检查模块内部错误处理是否有效,组件测试的测试方法,测试框架和调试工具 通过开发环境的支持，比如组件测试框架或调试工具(debugging tool)，组件测试会深入到代码中，而且实际上设计代码的开发人员通常也会参与其中。 在这种情况下，一旦发现缺陷，就可以立即进行修改，而不需要正式的缺陷管理过程。 测试优先的方法或测试驱动开发 在编写代码之前就完成编写和

42、自动化测试用例 这是高度迭代的方法，并且取决于如下的循环周期： 测试用例的开发 构建和集成小块的代码 执行组件测试 修正任何问题并反复循环，直到它们全部通过测试。,理解驱动程序与桩,# include void main(void) int a=1,b=2,c; c=fun1(a,b); int fun1(int x, int y) return x+y; ,问题： 假设这两个函数是两个人分别开发的，二者开发进度不同，则如何测试？,驱动模块和桩 驱动模块（driver）:对底层或子层模块进行测试所编写的调用这些模块的程序。 桩模块（stub）：对顶层或上层模块进行测试时所编写的替代下层模块的程

43、序。,集成测试概述,概述 通过单元测试的多个模块组合成更大的模块或子系统或产品，然后进行测试 集成测试是对组件之间的接口进行测试，以及测试一个系统内不同部分的相互作用，比如操作系统、文件系统、硬件或系统之间的接口。 测试依据 软件和系统设计文档 系统架构 工作流 用例 测试对象 子系统数据库实现 基础设施 接口,集成测试的级别和内容,集成级别 集成测试，可以应用多种集成级别，也可以根据不同的测试对象规模采用不同的级别。 组件集成测试 对不同的软件组件之间的相互作用进行测试，一般在组件测试之后进行。 系统集成测试 对不同系统或软硬件之间的相互作用进行测试，一般在系统测试之后进行。 内容 各单元的

44、接口是否吻合 代码是否符合规定的标准 界面标准是否统一等,集成的策略和方式,策略 根据系统结构（例如自顶向下或自底向上）、功能任务集、事务处理顺序或系统和组件的其他方面等制定集成测试策略。 为了能方便快速地隔离故障和定位缺陷，集成程度应该逐步增加，而不是采用“大爆炸”式的集成。 方式 非渐增式测试模式：先分别测试每个模块，再把所有模块按设计要求一次全部组装起来所要的系统，然后进行整体测试。非渐增式集成测试是不科学的集成测试方式。 渐增式测试模式：把下一个要测试的模块同已经测试好的模块结合起来进行测试，测试完以后再把下一个模块结合进行测试 自顶向下集成（Top-Bottom）：自顶向下集成时，前

45、期完成的模块将是后期模块的驱动程序（Driver） 自底向上集成：前期完成的模块将是后期模块的桩程序（Stub）,系统测试概述,概述 将经过确认测试的软件，与计算机硬件、外设、支持软件等一起，在实际运行环境下测试。 系统测试关注的是在开发项目或程序中定义的一个完整的系统/产品的行为。 目的 充分运行系统，验证系统各部件是否能正常工作，符合软件需求规格说明。 测试依据 系统和软件需求规格说明 用例 功能规格说明 风险分析报告 典型测试对象 系统、用户手册和操作手册 系统配置,系统测试类型与方法,类型 功能测试 非功能测试：压力测试/性能测试/容量测试 用户界面测试 兼容性测试 国际化测试 /本地

46、化测试 测试方法 基于需求的测试 从需求导出测试目标和测试条件，设计测试用例，测试检查功能或者非功能特性（可靠性和可用性）。 基于业务流程的测试 从业务流程的说明和对业务流程的理解导出和选择测试用例的测试方法。 基于用例（Use Cases）的测试 黑盒测试设计方法，根据实际的场景设计测试用例，进行测试。 基于风险评估的测试 说明： 在系统测试中，测试环境应该尽量和最终的目标或生产环境相一致，从而减少不能发现和环境相关的失效的风险。 系统测试通常由独立的测试团队执行,验收测试概述,概述 技术测试的最后一个阶段，在软件产品完成了系统测试之后、产品发布之前所进行的软件测试活动 验收测试通常是由使用

47、系统的用户或客户来进行，同时系统的其他利益相关者也可能参与其中。 目的 验收测试的目的是建立对系统、系统的某部分或特定的系统非功能特征建立信心。 验证系统是否达到了用户需求规格说明书（可能包括项目或产品验收准则）中的要求，保证系统或软件产品最终被用户接受 发现缺陷不是验收测试的主要目标。 测试依据 用户需求 系统需求 用例 业务流程 风险分析报告,验收测试的对象和内容,对象 基于完全集成系统的业务流程 操作与维护流程 用户处理过程 结构 报告 内容 安装测试 功能测试 可靠性测试 安全性测试 性能测试 易用性测试 可移植性测试 可维护性测试 文档测试,验收测试的特点,验收测试不一定是最后级别的

48、测试。 可能会在进行某个系统验收测试之后，进行大规模的系统集成测试。 验收测试可以在多个测试级别上进行 商业现货软件(COTS)产品可以在安装或集成时进行验收测试； 组件的可用性验收测试可以在组件测试中进行； 增加新功能的验收测试可以在系统测试之前进行。,验收测试的形式,形式（5种类型） 用户验收测试 操作验收测试 系统操作验收测试由系统管理员来进行，测试内容主要包括： 系统备份/恢复测试； 灾难恢复测试； 用户管理测试； 维护任务测试； 数据加载和移植活动； 安全漏洞阶段性检查。 合同和法规性验收测试 合同验收测试根据合同中规定的生产客户定制软件的验收准则，对软件进行测试。应该在合同拟定时定

49、义验收准则。 法规性验收测试根据必须要遵守的法律法规来进行测试，比如政府、法律和安全方面的法律法规。,验收测试的形式,Alpha testing （ 测试） 在软件产品正式商业销售之前，市场或商业现货软件开发人员希望从市场中潜在的或已经存在的客户中得到关于软件的反馈信息。 Alpha测试通常在开发组织现场进行，但测试并非由开发团队执行。 Beta testing（ 测试） Beta测试或实地测试，是在客户或潜在客户现场进行并由他们执行。 概念辨析 Alpha testing （ 测试）：用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。 Beta testing（ 测试）：软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。,软件测试类型,测试类型概述,软件类型众多，不同的分类标准对应不同的测试类型 分类： 功能性测试 软件产品特性测试（非功能