统稿说明讲解Word下载.docx

统稿说明讲解Word下载.docx

《统稿说明讲解Word下载.docx》由会员分享，可在线阅读，更多相关《统稿说明讲解Word下载.docx（64页珍藏版）》请在冰豆网上搜索。

3.1评审和测试过程（K2）36

3.2评审过程（K2）36

3.3静态分析的工具支持（K2）36

4.测试设计技术（K3）255分钟44

4.1识别测试环境和设计测试用例（K3）44

4.2测试设计技术的种类（K2）44

4.3基于规格说明的或黒盒测试技术（K3）45

4.4基于结构的或白盒测试技术（K3）45

4.5基于经验的技术（K2）46

4.6选择测试技术（K2）46

5.传统的结构化软件测试（K3）180分钟57

5.1.结构化软件的单元测试（组件测试）（K3）57

5.2.结构化软件的集成测试（K3）57

5.3.结构化软件的系统测试（K3）57

6.面向对象的软件测试（K3）150分钟61

6.1.面向对象的单元测试（K3）61

6.2.面向对象的集成测试（K3）61

6.3.面向对象的系统测试（K3）61

7.基于GUI的软件测试（K2）120分钟65

7.1GUI测试概述（K1）65

7.2GUI测试内容（K3）65

7.3GUI测试技术（K2）66

8.测试管理（K3）180分钟69

8.1测试的组织结构（K2）69

8.2测计划划和估算（K2）69

8.3测试进度监测（K2）69

8.4配置管理（K2）70

8.5风险和测试（K2）70

8.6缺陷管理（K3）70

9.软件测试工具（K2）80分钟84

9.1测试工具的类型（K2）84

9.2高效率使用工具：

潜在的利益和风险（K2）84

9.3组织中工具的引入（K1）84

10．参考文献95

附录A――课程大纲背景97

附录B――学习目标和知识级别100

附录C――ISTQB初级课程大纲的规定102

附录D――培训机构注意事项104

致谢

本大纲是在国际软件测试认证委员会初级课程大纲的框架下，按照规定的要求结合中国的实际情况编写。

国际软件测试认证委员会初级课程大纲工作组有：

ThomasMü

ller（chair）,RexBlack,SigridEldh,DorothyGraham,KlausOlsen,MaaretPyhä

jä

rvi,GeoffThompson和ErikvanVeendendal。

中国编写组工作组有（按姓氏拼音排序）：

杜庆峰、李华北、刘琴、马均飞、沈备军、沈建雄、易莎莎、赵国锋、郑文强、周震漪等。

编撰本书的核心团队感谢评审团队以及对当前课程大纲提供建议的所有国家委员会。

特别感谢来自澳大利亚的AnastasiosKyriakopoulos，丹麦的KlausOlsen和ChristineRosenbeck-Larsen，德国的MatthiasDaigl、UweHehn、TiloLinz、HorstPohlmann、InaSchieferdecker、SabineUhde、StephanieUlrich、印度的VipulKocher，以色列的ShmuelKnishinsky和EsterZabar，瑞典的AndersClaesson、MattiasNordin、IngvarNordströ

m、StefanOhlsson、KennetOsbjer、IngelaSkytte和KlausZeuge，瑞士的ArminBorn、SandraHarries、SilvioMoser、RetoMü

ller和JoergPietzsch，英国的AranEbbett、IsabelEvans、JulieGardiner、AndrewGoslin、BrianHambling、JamesLyndsay、HelenMoore、PeterMorgan、TrevorNewton、AngelinaSamaroo、Shane

Saunders、MikeSmith、RichardTaylor、NeilThompson和PeteWilliams，以及来自美国的DalePerry。

课程简介

本文档的目的

本文是国际软件测试认证初级水平的中国课程大纲。

国际软件测试认证委员会（以下简称ISTQB）提供标准的课程大纲给各个国家考试委员会。

各委员会在规定的框架下对国际标准大纲做适当的调整和修改并授权给培训机构，并以当地的语言进行认证考试，本大纲就是结合中国实际，作了适当修改后而形成的。

培训机构（在本大纲基础上）自行负责编写课件，并采取适当的授课方法。

本课程大纲能为报考者提供帮助。

关于本课程大纲的修订历史和背景知识信息，可以参考附录A。

软件测试初级认证

初级资质认证可以针对和软件测试工作相关的任何角色，包括测试员、测试分析员、测试工程师、测试顾问、测试经理、用户验收测试员和软件开发人员等。

同时本初级资质认证也适合想对软件测试有所了解的人，比如项目经理、质量经理、软件开发经理、业务分析师、IT主管和管理顾问等。

拥有初级资质证书后，可以继续向高级软件测试资质认证努力。

学习目标和认知水平

在课程大纲中，每个章节都会提供相应的认知水平要求：

●K1：

牢记、认知、回想

●K2：

理解、解释、给出理由、比较、分类、总结

●K3：

应用

更详细的学习目标和例子可以参考附录B。

需要牢记章节标题下面列出的所有条目，即使在学习目标中没有非常明显的涉及。

关于考试

初级认证考试的内容将基于本课程大纲的内容。

但是考试中涉及到的问题，可能需要用到课程大纲的一个甚至多个章节的知识。

考试的范围覆盖本课程大纲的所有章节。

考试题目为选择题。

考试可以作为认证培训课程的一部分，也可以单独参加考试（在授权的考试中心）。

授权

培训机构必须由ISTQB授权的国家委员会授权，同时他们根据本课程大纲编写相应的课程资料。

授权指南可以从国家委员会获取，或者从开展授权的团体获取。

更多关于培训机构指南可以参考附录D。

细节

本课程大纲详细层次的描述，使得我们可以在国际上进行相同方式的教学和考试。

为了达到这个目标，本课程大纲由下面几部分组成：

●概括的教学目标，描述了初级水平资质认证的目的。

●培训的系列知识，包括详细的描述以及必需的参考资料。

●各个知识领域的学习目标。

●列出必须能够理解和掌握的知识条目。

●描述主要的教学理念。

本课程大纲并没有包含软件测试的整个知识领域，只是提供了初级课程需要覆盖的具体方面。

课程大纲的结构

本课程大纲主要由9大章节组成。

第一级的标题是本章的学习目标和学习的时间。

比如：

2.贯穿整个软件生命周期的测试（K2）

135分钟

显示了第二章节的学习目标是K2，建议花费135分钟来进行教学本部分内容。

课程大纲的每一章都由几节组成。

每节同样会由相应的学习目标和需要的教学时间组成。

没有具体时间规定的子章节，教学的时间包含在了整个章节之中。

1.软件测试基础（K2）155分钟

测试基础知识的学习目标

本章的学习目标：

完成下面模块（module）的学习后，将明确能做什么。

1.1为什么需要测试（K2）

●通过具体的例子，来描述软件中的缺陷（defect）会以什么样的方式损害个人、损害环境或者损害公司利益（K2）。

●区分引起缺陷的根本原因及其影响之间的区别（K2）。

●通过举例的方式说明为什么需要测试（K2）。

●描述为什么测试是质量保证（qualityassurance）的一部分，通过举例说明测试是如何来提高软件质量的（K2）。

●理解术语错误（mistake）、缺陷、失效（failure）以及相应的术语错误（error）和bug之间的区别（K1）。

1.2什么是测试（K2）

●认识测试的共同目标（K1）。

●描述测试作为发现缺陷的一种手段，测试在软件开发、维护和运行中的目的，同时通过测试，可以增强对被测软件的信心并获得一些相关的信息，从而用来预防缺陷（K2）。

1.3测试的基本原则（K2）

●说明测试的基本原则（K2）。

1.4基本的测试过程（K1）

●认识从计划到测试结束过程中测试的基本活动，以及在每个活动中的主要任务（K1）。

1.5测试的心理学（K2）

●认识测试的成功与否，会受测试心理因素的影响（K1）：

✧清楚的目标；

✧自己测试和独立测试之间的平衡；

✧认识到谦恭的沟通和缺陷反馈在测试中的作用。

●对比测试员（tester）和开发员（developer）的心理差异（K2）。

1.1为什么需要测试（K2）20分钟

术语

缺陷（bug）、缺陷（defect）、错误（error）、失效（failure）、故障（fault）、错误（mistake）、质量（quality）、风险（risk）、软件（software）、测试（testing）。

1.1.1软件系统的内容（K1）

在当今社会，软件系统（system）越来越成为生活中不可或缺的一部分，包括从商业应用（比如银行系统）到消费产品（比如汽车）各个领域。

然而，很多人都有这样的经历：

软件并没有按照预期进行工作。

软件的不正确执行可能会导致许多问题，包括资金、时间和商业信誉等的丢失，甚至导致人身伤害和死亡。

1.1.2引起软件缺陷的原因（K2）

所有的人都会犯错误，因此由人设计的代码、系统和文档中很可能会引入缺陷。

当存在缺陷的代码被执行时，系统就可能无法执行期望的指令（或者做了不应该执行的指令），从而引起软件失效。

虽然软件、系统和文档中的缺陷可能会引起失效，但并不是所有的缺陷都会这样。

产生缺陷的原因是多种多样的：

人们本身容易犯错误、时间的压力、复杂的代码、复杂的系统架构、技术的革新、或者系统之间的配合工作等。

失效也可能是由于环境条件引起的：

放射、电磁辐射和污染等都有可能引起硬件的故障，或者由于硬件条件的改变而影响软件的执行。

1.1.3在软件开发、维护和运行中测试的角色（K2）

对软件系统和文档进行严格的测试,可以减少软件系统在运行环境中的风险，假如在软件正式发布之前发现和修正了缺陷，就可以提高软件系统的质量。

进行软件测试也可能是为了满足合同和法律法规的需求，或者是为了满足行业标准。

1.1.4测试和质量（K2）

通过测试，就可能发现软件系统在功能（functional）和非功能（non-functional）需求方面的缺陷，对软件质量（softwarequality）进行评判。

飞功能需求包括：

可靠性（reliability）、可用性（usability）、效率（efficiency）和可维护性（maintainability）等方面，关于非功能测试方面的更多信息，可以参考第二章。

更多关于软件特征的信息，可以参考“软件工程－软件产品质量（ISO9126）”。

当测试发现很少或者没有发现缺陷的时候，就会对软件的质量充满信心。

一个设计正确、合理的测试过程完成并顺利通过，可以降低整个系统存在问题的风险。

而对测试过程中发现的缺陷进行了修正，则软件系统的质量就会提高。

我们应该从以前的项目中总结经验教训。

通过分析在其他项目中发现的缺陷和引起缺陷的根本原因，我们就可以改进测试过程（process）。

相继地，过程的改进又可以预防相同的缺陷再次发生，从而提高以后系统的质量。

测试应该作为质量保证的一个不可或缺的一部分。

1.1.5测试是否充分（K2）

在判断测试是否足够时，需要考虑下面的因素：

风险（包括技术风险、商业产品风险和项目的风险等）以及项目在时间和预算上的限制等。

测试需要给利益相关者提供足够的信息，帮助他们决定是否发布被测的软件或系统，是否继续进行下阶段的开发或直接将产品交给用户。

1.2什么是测试（K2）30分钟

代码（code）、调试（debugging）、（软件）开发（development）、需求（requirement）、评审（review）、测试依据（testbasis）、测试用例（testcase）、测试（testing）、测试目标（testobjectives）。

背景

在一般人的理解当中，测试活动只包含了运行测试，也就是执行软件。

但实际上这只是测试的一部分，而不是测试的所有活动。

测试的活动包含了测试执行之前和之后的一些活动，包括计划（planning）和控制（control）、选择测试条件（testcondition）、设计测试用例（testcase）、检查测试结果（result）、评估完成准则（completioncriteria）、报告测试过程（testprocess）及被测系统、测试结束或总结。

测试同时也包括文档的评审（review）（包括代码）和静态分析（staticanalysis）。

动态测试（dynamictesting）和静态测试这两种手段都可以达到相似的目标，即以提供信息来改进被测试软件系统的质量，以及改善开发和测试的过程。

不同的测试具有不同的测试目标：

●发现缺陷；

●获取对产品质量的信心，以及提供信息；

●预防缺陷。

在软件生命周期早期进行测试用例的设计，可以帮助避免将缺陷引入代码中。

同时文档的评审（例如需求文档）也可以预防将缺陷引入代码。

不同的测试阶段，需要考虑不同的测试目标。

比如，在开发测试中，如单元测试（unittesting）、集成测试（integrationtesting）和系统测试（systemtesting）等，测试的主要目标是尽可能的发现失效，从而识别和修正尽可能多的缺陷。

在验收测试（acceptancetesting）中，测试的主要目标是用来确认系统是否按照预期工作，从而在系统是否满足需求方面获取信心。

而在有些情况下，测试的主要目标是对软件的质量进行评估（不是为了修正缺陷），从而为利益相关人提供这样的信息：

在给定时间内发布的系统版本所存在的风险。

而维护测试（maintenancetesting）通常是为了验证在开发过程中的变更是否引入新的缺陷。

在运行测试阶段，测试的主要目标是为了评估系统的特征，比如可靠性或可用性等。

必须明确，调试和测试是两个不同的概念。

测试可以发现由于软件存在的缺陷引起的失效。

而调试是一种开发活动，用来识别引起缺陷的原因，修改代码以及验证是否正确的修改了软件的缺陷。

随后由测试员进行的确认测试（confirmationtesting）是为了确认修改的代码已经解决了失效问题。

每个活动的职责是截然不同的，即测试员进行测试，开发人员进行调试。

测试的过程和相应的活动将在1.4节解释。

1.3测试的基本原则（K2）35分钟

穷尽测试（exhaustivetesting）。

原则

在过去40年中，软件测试界提出了很多的测试原则，并且提供了适合所有测试的一些共同的测试指南。

原则1－测试显示缺陷的存在

测试可以显示缺陷（defect）的存在，但不能证明系统不存在缺陷。

测试可以减少软件中存在缺陷的可能性，但即使测试没有发现任何缺陷，也不能证明软件或系统是完全正确的。

原则2－穷尽测试是不可能的

除了小型项目，进行完全（各种输入和前提条件的组合）的测试是不现实的。

通过运用风险管理（riskmanagement）和不同系统功能的测试优先级，来确定测试的关注点，从而替代穷尽测试。

原则3－测试尽早介入

在软件或系统开发生命周期中，测试活动应该尽可能早的介入，并且应该将关注点放在已经定义的测试目标（testobjective）上。

原则4－缺陷集群性

版本发布前进行的测试所发现的大部分缺陷和软件运行失效是由于少数软件模块引起的。

原则5－杀虫剂悖论

同样的测试用例一遍一遍重复进行测试，最后将不再能够发现新的缺陷。

为了克服这种杀虫剂悖论，测试用例需要经常性的评审和修改，同时需要不断增加新的不同的测试用例来测试软件或系统的不同部分，从而发现潜在的更多的缺陷。

原则6－测试活动依赖于测试内容

针对不同的测试内容，进行的测试活动也是不同的。

比如，对关注安全的软件进行测试，与一般的商业软件测试的重点是不一样的。

原则7－不存在缺陷的谬论

假如系统无法使用，或者系统不能完成客户的需求和期望，发现和修改缺陷是没有任何帮助的。

1.4基本的测试过程（K1）35分钟

确认测试（confirmationtesting）、出口准则（exitcriteria）、事件（incident）、回归测试（regressiontesting）、测试依据（testbasis）、测试条件（testcondition）、测试覆盖（testcoverage）、测试数据（testdata）、测试执行（testexecution）、测试日志（testlog）、测试计划（testplan）、测试策略（teststrategy）、测试总结报告（testsummaryreport）、测试件（testware）。

测试最显而易见的活动是测试的执行。

但是为了提高效率，在测试计划中，同样需要保留比较多的时间用于计划测试活动、设计测试用例、准备测试的执行和评估测试的状态。

基本的测试过程主要由下面一些活动组成：

●计划和控制；

●分析和设计；

●实现和执行；

●评估出口准则和测试报告；

●测试结束活动。

虽然上面这些活动在逻辑上是有连续的，但在整个测试过程中它们可能会重叠或同时进行。

1.4.1测试计划和控制阶段（K1）

测试计划的主要活动是：

识别测试的任务、定义测试的目标以及为实现测试目标和任务定义规格说明。

测试控制是持续进行的活动：

通过对测试进展和测试计划之间的比较，报告测试的状态，包括与计划之间存在的偏差。

测试控制包括在必要的时候采取必要的措施来满足测试的任务和目标。

需要在项目的整个生命周期中对测试活动进行监控，以达到控制测试过程的目的。

同时，测试计划的制定也需要借鉴以前项目测试监控活动的经验和有用信息。

测试计划阶段主要任务：

●确定测试的范围和风险，识别测试的目标；

●确定测试方法:

测试技术、测试项（testitem）、测试覆盖（testcoverage）、识别和联系相关的测试团队和测试件；

●确定测试需要的资源:

人员、测试环境（testenvironment）和计算机等；

●贯彻测试方针和策略；

●计划测试分析和测试设计任务的时间进度；

●计划测试实现、执行和评估的时间进度；

●确定测试的出口准则。

测试控制阶段主要任务：

●测量和分析结果；

●监控和记录测试进展、测试覆盖和测试出口准则；

●修改软件的缺陷；

●做出决定。

1.4.2测试分析和设计阶段（K1）

测试分析和设计是将抽象的测试目标转化为实实在在的测试条件和测试设计的一系列活动。

测试分析和设计阶段的主要任务：

●评审测试依据（比如需求、系统架构、设计和接口说明等）。

●识别测试条件或测试需求（testrequirement），根据测试项、详细规格说明、系统行为和结构分析得到必要的测试条件和数据。

●设计测试用例。

●评估系统和需求的可测试性（testability）。

●规划测试环境的搭建和确定测试需要的基础设施（infrastructure）和工具。

1.4.3测试实现和执行阶段（K1）

测试实现和执行是将测试条件转化为测试用例、测试件的一系列活动，并进行测试环境的搭建。

测试实现和执行阶段的主要任务：

●测试用例的开发和确定它们的优先级，创建测试数据，描述测试的具体步骤，同时也可以准备测试用具（testharnesses）和设计测试脚本（testscript）。

●根据测试用例建立测试套件（testsuite），以提高测试执行的效率。

●确认已经正确搭建了的测试环境。

●根据计划的执行顺序，通过手工或使用测试执行工具（testexecutiontool）来执行测试用例。

●记录测试执行的结果，以及被测软件的标识和版本、使用的测试工具和测试件。

●将实际结果和预期结果进行比较。

●对实际结果和预期结果之间的差异，作为缺陷上报，并且分析这些缺陷以确定引起缺陷的原因（代码缺陷、具体测试数据缺陷、测试文档缺陷、或测试执行的方法有错误等）。

●缺陷修正后，重新进行测试活动。

比如通过再次执行在上个版本中失败的用例来确认缺陷是否已经被修正（确认测试）。

执行修正后的测试用例或执行一些测试用例来确保缺陷的修正没有在软件中引入新的问题后或没有引起其他的缺陷（回归测试）。

1.4.4评估出口准则和测试报告阶段（K1）

评估出口准则阶段是将测试的执行结果和已经定义的测试目标进行比较的活动。

这个活动在各个测试级别（testlevel）上都需要进行。

评估测试出口准则的主要任务：

●按照测试计划中定义的测试出口准则检查测试日志。

●判断是否需要进行更多的测试，或是否需要更改测试的出口准则。

●为利益相关者提供一个测试总结报告。

1.4.5测试结束阶段（K1）

测试结束阶段从完成的测试活动中收集资料来巩固测试经验，收集测试件、影响测试的因素和其他数据。

比如什么时候软件系统可以发布？

什么时候项目测试结束或取