ISTQB基础

ISTQB=International Software Testing Qualifications Board，是国际权威的软件测试认证机构，现有包括美国、英国、德国、法国、日本、挪威、加拿大、澳大利亚等70多个成员国/地区。中国于2006年5月26日在美国奥兰多举行的ISTQB2006年年会上得到正式批准成为其成员。

ISTQB-CertifiedTester培训及认证体系分为三个级别：基础级/FoundationLevel、高级/AdvancedLevel和专家级/ExpertLevel。培训者获得基础级/FoundationLevel证书后，可申请参加更高级别的培训和认证考试，并获得相应证书。截止2012年12月，全球已有超过280,000IT专业人士持有ISTQB-CertifiedTester的认证证书。ISTQB认证是仅次于PMP认证、ITIL认证的全球第三大IT认证（非厂商认证领域）。

与我们熟知的微软MCSE、思科CCNA、甲骨文OCP等认证不同，PMP、ITIL、ISTQB不隶属于任何企业组织或政府机构，是独立的第三方认证，因此在跨国企业中拥有广泛声誉。PMP侧重于IT项目管理，ITIL侧重于IT服务，ISTQB侧重于软件测试与质量保证。可以说，在跨国企业中，这三个认证类似于职业“身份证”。

常见问题：

1、  问题：ISTQB是什么？

答案：ISTQB=InternationalSoftware Testing Qualifications Board，是国际权威的软件测试认证机构，是全球最大的软件测试工程师认证。

2、  问题：ISTQBFL是什么?

答案：FL=FoundationLevel，即ISTQB基础级认证，是ISTQB认证的第一级，主要认证对象是工程师。只有考取了FL，才可以考取高级别的认证。

3、  问题：CSTQB是什么？ISTQB和CSTQB的关系是什么？CSTQB也是一种考试吗？

答案：CSTQB是ISTQB在大中华区的官方机构，负责组织ISTQB认证相关事宜。但是CSTQB本身不是考试，考试和认证是全球统一的，那就是ISTQB认证。更多信息可以参考www.cstqb.cn和www.istqb.org。

4、  问题：ISTQB考试是中文还是英文？

答案：都有，可以选择，其认证效果等同。

5、  问题：ISTQB认证的考试形式是什么样的？

答案：考试试题由ISTQB题库中选取，采取闭卷笔试的形式。FoundationLevel（基础级）考试时间为60分钟，非母语考生可延长25%的时间。

6、  问题：ISTQB考试时间是什么？

答案：每月第二周的周五和每月第四周的周日。

7、  问题：如何报名参加ISTQB认证考试？

答案：可以与当地服务商联系，注意需要在考前两周完成报名。

8、  问题：ISTQBFL考试费用是多少？

答案：考试是全国统一价格，社会考生1500元每人，在校生1000元每人——需要提供在学证明。

9、  问题：ISTQBFL考试通过率如何？

答案：各国情况不同，非官方数据显示，日本、韩国的通过率在70%左右，我国的通过率稍高，大概在90%左右。

10、         问题：能自学ISTQB吗？

答案：可以！但是参加专业培训可以大幅提高通过率。

11、         问题：ISTQB认证与国内同类认证的区别是什么？

答案：ISTQB本身是一个非营利性的国际化软件测试工程师认证机构，现有包括中国在内的70多个成员国/地区。因此，ISTQB认证证书在其授权的70多个成员国/地区内通用，同时，它也是软件测试领域目前国内唯一被国际认可的证书。认证的三个级别分别针对测试领域不同程度之人士。

 

ISTQB大纲

1． 大纲简介

1.1．  本文档的目的

本大纲是国际软件测试认证初级水平的中文版课程大纲。国际软件测试认证委员会(以下简称ISTQB)提供标准的课程大纲给各个国家考试委员会。各国委员可以在规定的权限内将大纲授权给培训机构以及以当地的语言组织认证考试的考题并提供给考试机构。培训机构借助于本大纲自行负责编写课件并采取适当的授课方法。同时,本课程大纲能为报考者备考提供帮助。

1.2．  软件测试人员初级认证

初级资质认证可以针对和软件测试工作相关的任何角色,包括测试人员、测试分析员、测试工程师、测试顾问、测试经理、用户验收测试人员和软件开发人员等。同时本初级资质认证也适合希望对软件测试有所了解的人,比如项目经理、质量经理、软件开发经理、业务分析师、IT主管和管理顾问等。拥有初级资质证书后,可以继续向高级软件测试资质认证努力。

1.3．  学习目标和认知水平

在课程大纲中,每个章节都会提供相应的认知水平要求:K1:牢记K2:理解  K3:应用 K4:分析需要牢记章节标题下面列出的所有条目(K1),即使在学习目标中没有非常明显的涉及。

1.4．  关于考试

初级认证考试的内容将基于本课程大纲的内容。但是考试中涉及到的问题,可能需要用到课程大纲的一个甚至多个章节的知识。考试的范围覆盖本课程大纲的所有章节。

考题的形式是多项选择题。考试可以作为认证培训课程的一部分,也可以单独参加考试(例如:在授权的考试中心)。认证培训课程的完成不作为考试的先决条件。

1.5．  细节

本大纲的详细等级目标是全球一致性的教学形式和考核。为了达到这个目标,本课程大纲由下面几部分组成:

总体教学目标,描述了初级水平资质认证的目的;

培训的系列知识,包括详细的描述并且如有需要可参考额外的资料;

各个知识领域的学习目标,描述知识产出和将要达到的认知水平;

列出学员必须能够理解和掌握的知识条目;

描述主要的教学理念,包括已经被接受的文献或标准等资源。

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

1.6．  课程大纲的结构

本课程大纲主要由6大章组成。每一章的第一级标题明确了本章最终的学习目标和建议授课的时间。

例子:

2. 软件生命周期中的测试(K2)(115分钟)

显示了第二章的学习目标是K1(当更高的级别已经显示时可以假设也应达到该级别)和K2(但不是K3),建议花费115 分钟来进行本部分的教学。课程大纲的每一章都由几节组成。每节同样会由相应的学习目标和所需的教学时间组成。没有规定具体时间的子章节,其教学的时间包含在了整个章节之中。

2． 软件测试基础

2.1．  软件测试基础(K2)(155分钟)

2.1.1. 为什么需要测试(K2)(20 分钟)

2.1.1.1.             术语

缺陷(bug)、缺陷(defect)、错误(error)、失效(failure)、故障(fault)、错误(mistake)、质量(quality)、风险(risk)。

2.1.1.2.             软件系统的重要性(K1)

在当今社会,软件系统越来越成为生活中不可或缺的一部分,包括从商业应用(比如银行系统) 到消费产品(比如汽车)各个领域。然而,很多人都有这样的经历:软件并没有按照预期进行工作。软件的不正确执行可能会导致许多问题,包括资金、时间和商业信誉等的损失,甚至导致人员的伤亡。

2.1.1.3.             引起软件缺陷的原因(K2)

所有的人都会犯错误(error,mistake),因此在由人设计的程序代码或文档中也会引入缺陷(defect, fault, bug)。当存在缺陷的代码被执行时,系统就可能无法实现期望的功能(或者实现了未期望的功能),从而引起软件失效(failure)。虽然在软件、系统或文档中的缺陷可能会引起失效,但并非所有的缺陷都是如此。

产生缺陷的原因是多种多样的:人们本身容易犯错误、时间的压力、复杂的代码、复杂的系统架构、技术的革新、以及/或者许多系统之间的交互等。

失效也可能是由于环境条件引起的:例如:辐射、电磁场和污染等都有可能引起固件中的故障,或者由于硬件环境的改变而影响软件的执行。

2.1.1.4.             测试在软件开发,维护和运行中所担当的角色(K2)

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

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

2.1.1.5.             测试和质量(K2)

可以根据测试中所发现的缺陷,对软件功能和非功能性需求以及特性(例如:可靠性、可用性、效率、可维护性和可移植性)进行度量,从而评估软件质量。更多关于非功能测试方面的信息,可以参考第二章。更多关于软件特征的信息,可以参考“软件工程-软件产品质量(ISO9126)”。

当测试发现很少或者没有发现缺陷的时候,测试就会帮助树立对于软件质量的信心。一个设计合理的测试过程完成并顺利通过,可以降低整个系统存在问题的风险。而对测试过程中发现的缺陷进行了修正,则软件系统的质量就会提高。

我们应该从以前的项目中吸取经验教训。通过分析在其他项目中发现的缺陷和引起缺陷的根本原因,可以改进软件开发过程。过程的改进反过来可以预防相同的缺陷再次发生,从而提高以后系统的质量。这是质量保证工作的一方面。

测试应该作为开发过程中质量保证工作的不可或缺的一部分(与开发标准、培训和缺陷分析一样)。

2.1.1.6.             测试是否充分(K2)

在判断测试是否足够时,需要考虑下面的因素:风险(包括技术风险、商业产品风险和项目风险等)以及项目在时间和预算上的限制等(有关风险的详细内容参见第五章)。

为了进入下一个开发过程,或将系统交付给用户,测试需要给利益相关者提供足够的信息,帮助他们决定是否发布被测软件或系统。

2.1.2. 什么是测试(K2)(30 分钟)

2.1.2.1. 术语

调试(debugging)、需求(requirement)、评审(review)、测试用例(testcase)、测试(testing)、测试目标(testobjective)。

2.1.2.2. 背景

在一般人的理解当中,测试活动只包含了运行测试,也就是执行软件。但实际上这只是测试的一部分,而不是测试的所有活动。

测试活动包含了测试执行之前和之后的一些活动,包括计划和控制、选择测试条件、设计和执行测试用例、检查测试结果、评估出口准则、报告测试过程及被测系统、在一个测试阶段完成后要进行测试结束或总结工作。测试同时也包括文档的评审(包括源代码)和执行静态分析。

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

测试可以有如下目标:

发现缺陷;

增加对质量的信心;

为决策提供信息;

预防缺陷。

在软件生命周期的早期进行测试设计的思维过程和活动(通过测试设计来检验测试依据),可以避免将缺陷引入代码。对文档的评审(例如需求文档)并识别和解决问题也有助于防止在代码中出现缺陷。

不同的测试阶段,需要考虑不同的测试目标。比如,在开发测试中,如组件测试、集成测试和系统测试等,测试的主要目标是尽可能的发现失效,从而识别和修正尽可能多的缺陷。在验收测试中,测试的主要目标是确认系统是否按照预期工作,是建立满足了需求的信心。而在有些情况下, 测试的主要目标是对软件的质量进行评估(不是为了修正缺陷),从而为利益相关者提供这样的信息:在给定的时间点发布系统版本可能存在的风险。而维护测试通常是为了验证在开发过程中的软件变更是否引入新的缺陷。在运行测试阶段,测试的主要目标是为了评估系统的特征,比如可靠性或可用性等。

调试和测试是两个不同的概念。动态测试可以发现由于软件缺陷引起的失效。而调试是一种发现,分析,清除引起失效原因的开发活动,随后由测试员进行的再测试是为了确认修改的代码已经解决了失效问题。每个活动的职责是截然不同的,即测试员进行测试,开发人员进行调试。

测试的过程和测试活动将在1.4节讲述。

2.1.3. 测试的基本原则(K2)(35 分钟)

2.1.3.1. 术语

穷尽测试(exhaustivetesting)。

2.1.3.2. 基本原则

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

2.1.3.3. 原则 1 –  测试发现缺陷但不能确保正确

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

2.1.3.4. 原则 2 –穷尽测试是不可行的

除了小型项目,进行完全(各种输入和前提条件的组合)的测试是不可行的。通过运用风险分析和不同系统功能的测试优先级,来确定测试的关注点,从而替代穷尽测试。

2.1.3.5. 原则 3 –测试尽早介入

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

2.1.3.6. 原则4 –缺陷集群性

测试工作的分配比例应该与预期的和后期观察到的缺陷分布模块相适应。少数模块通常包含大部分在测试版本中发现的缺陷或失效。

2.1.3.7. 原则5 –杀虫剂悖论

采用同样的测试用例多次重复进行测试,最后将不再能够发现新的缺陷。为了克服这种“杀虫剂悖论”,测试用例需要进行定期评审和修改,同时需要不断增加新的不同的测试用例来测试软件或系统的不同部分,从而发现潜在的更多的缺陷。

2.1.3.8. 原则 6 –测试活动依赖于测试背景

针对不同的测试背景,进行不同的的测试活动。比如,对安全关键的软件进行测试,与对一般的电子商务软件的测试是不一样的。

2.1.3.9. 原则 7 –不存在缺陷(就是有用系统)的谬论

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

2.1.4. 基本的测试过程(K1)(35 分钟)

2.1.4.1. 术语

确认测试(confirmationtesting)、再测试(retesting)、出口准则(exitcriteria)、事件(incident)、回归测试(regressiontesting)、测试依据(testbasis)、测试条件(testcondition)、测试覆盖(testcoverage)、测试数据(testdata)、测试执行(testexecution)、测试日志(testlog)、测试计划(testplan)、测试规程(testprocedure)、测试方针(testpolicy)、测试套件(test suite)、测试总结报告(testsummary report)、测试件(testware)。

2.1.4.2. 背景

测试最显而易见的活动是测试的执行。但是为了提高效率和有效性,在测试计划中,同样需要花费比较多的时间用于计划测试活动、设计测试用例、准备测试的执行和评估测试的状态。

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

测试计划和控制;

测试分析和设计;

测试实现和执行;

评估出口准则和报告;

测试结束活动。

虽然上面这些活动在逻辑上是有连续的,但在整个测试过程中它们可能会重叠或同时进行。通常在相应的系统或项目环境下剪裁这些主要活动行为是必需的。

2.1.4.3. 测试计划和控制阶段(K1)    

测试计划的主要活动是:识别测试任务、定义测试目标以及为了实现测试目标和任务确定必要的测试活动。

测试控制是持续进行的活动:通过对测试实际进度和测试计划之间的比较,报告测试的状态,包括与计划之间存在的偏差。测试控制包括在必要的时候采取必要的措施来满足测试的任务和目标。需要在项目的整个生命周期中对测试活动进行监督,以达到控制测试过程的目的。同时,测试计划的制定也需要考虑测试监控活动的反馈信息。

测试计划和控制阶段的任务将在第五章讲述。

2.1.4.4. 测试分析和设计阶段(K1)

测试分析和设计是将概括的测试目标转化为具体的测试条件和测试用例的一系列活动。

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

评审测试依据(比如需求、软件完整性级别(风险等级)、风险分析报告、系统架构、设计和接口说明);

评估测试依据和测试对象的可测性;

通过对测试项、规格说明、测试对象行为和结构的分析,识别测试条件并确定其优先级;

设计测试用例并确定优先级;

确定测试条件和测试用例所需要的测试数据;

规划测试环境的搭建和确定测试需要的基础设施和工具;

创建测试依据和测试用例间的双向可追溯性。

2.1.4.5. 测试实现和执行阶段(K1)

测试实现和执行阶段的主要活动包括:通过特定的顺序组织测试用例来完成测试规程和脚本的设计,并且包括测试执行所需的其他任何信息,以及测试环境的搭建和运行测试。

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

测试用例的开发、实现并确定它们的优先级。(包括识别测试数据);

开发测试规程并确定优先级,创建测试数据,同时也可以准备测试用具和设计自动化测试脚本;

根据测试规程创建测试套件,以提高测试执行的效率;

确认已经正确搭建了测试环境;

确认并更新测试依据和测试用例间的双向可追溯性;

根据计划的执行顺序,通过手工或使用测试执行工具来执行测试规程;

记录测试执行的结果,以及被测软件、测试工具和测试件的标识和版本;

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

对实际结果和预期结果之间的差异,作为事件上报,并且进行分析以确定引起差异的原因(例如:代码缺陷、具体测试数据缺陷、测试文档缺陷、或测试执行的方法有误等);

缺陷修正后,重新进行测试活动。比如通过再次执行上次执行失败的用例来确认缺陷是否已经被修正(确认测试)。执行修正后的测试用例或执行一些测试用例来确保缺陷的修正没有对软件未修改的部分造成不良影响或对于缺陷的修正没有引发其他的缺陷(回归测试)。

2.1.4.6. 评估出口准则和报告(K1)

评估出口准则是将测试的执行结果和已经定义的测试目标进行比较的活动。这个活动在各个测试级别上都需要进行。(参见章节2.2)

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

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

评估是否需要进行更多的测试,或是否需要更改测试的出口准则;

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

2.1.4.7. 测试结束活动(K1)

测试结束活动就是从已完成的测试活动中收集和整合有用的数据,这些数据可以是测试经验、测试件、影响测试的因素和其他数据。在以下几种情况下需要执行测试结束活动,例如:当软件系统正式发布、当一个测试项目完成(或取消)、当达到一个里程碑或当一个维护版本完成时。

测试结束活动的主要任务:

检查提交了哪些计划的可交付产品;

事件报告是否关闭、或对未关闭的事件报告提交变更需求;

记录系统的验收;

记录和归档测试件、测试环境和测试基础设备,以便以后的重复使用;

移交测试件到维护部门;

分析和记录所获得的经验教训,用于以后的项目和测试成熟度改进;

使用为测试成熟度的提高所收集的信息。

2.1.5. 测试的心理学(K2)(25 分钟)

2.1.5.1. 术语

错误推测(errorguessing)、独立(independence)。

2.1.5.2. 背景

在测试和评审中使用的思维方式,与在项目分析和开发中使用的不同。具有正确思维方式的开发人员可以测试他们自己写的代码。但通常将此职责从开发人员分离给测试人员,有助于开发人员集中精力,并且具有以下额外优势,例如:通过培训和使用专业的测试资源获得的独立的观点。独立测试可以应用于任何测试级别。

一定程度的独立(可以避免开发人员对自己代码的偏爱),通常可以更加高效地发现软件缺陷和软件存在的失效。但独立不能替代对软件的熟悉和经验,开发人员同样也可以高效的在他们自己的代码中找出很多缺陷。

在这可以从低到高定义不同级别的独立:

测试由软件本身编写的人员来执行(低级别的独立);

测试由一个其他开发人员(如来自同一开发小组)来执行;

测试由组织内的一个或多个其他小组成员(如独立的测试小组)或测试专家(如可用性或性能测试专家)来执行;

测试由来自其他组织或其他公司的成员来执行(如测试外包或其他外部组织的鉴定)。

测试的目标驱使着小组成员和项目的活动。小组成员将根据管理层或其他利益相关者设定的目标对他们的计划进行调整,比如需要发现更多的缺陷,或确认软件是否满足其目标。因此,对测试的目标进行清晰的设定是非常重要的。

测试过程中发现的失效,可能会被看成是测试员对产品和作者的指责。因此,测试通常被认为是破坏性的活动,即使它对于管理产品风险非常有建设性作用。在系统中发现失效需要测试员具有一颗好奇心、专业的怀疑态度、一双挑剔的眼睛、对细节的关注、与开发人员良好的沟通能力以及对常见的错误进行判断的经验。

假如可以用建设性的态度对发现的缺陷或失效进行沟通,就可以避免测试员、分析人员、设计人员和开发人员之间的不愉快。这个道理不仅适用于文档的评审过程,同样也适用于测试过程。

在以建设性的方式讨论缺陷、进度和风险时,测试员和测试的负责人都需要具有良好的人与人之间沟通的能力。对于软件代码或文档的作者,缺陷的信息可以帮助他们来提高他们的技术水平。如果在测试阶段发现和修复缺陷,就可以为在后期(例如在正式的使用时)节省时间和金钱,而且可以降低风险。

沟通方面的问题经常会发生,特别是当测试员只是被视为不受欢迎的缺陷消息的传递者的时候。然而可以使用下面的一些方法来改善测试员和其他小组成员之间的沟通和相互关系:

以合作而不是争斗的方式开始项目,时时提醒项目的每位成员:共同目标是追求高质量的产品;

对产品中发现的问题以中性的和以事实为依据的方式来沟通,而不要指责引入这个问题的小组成员或个人。比如,客观而实际地编写缺陷报告和评审发现的问题;

尽量理解其他成员的感受,以及他们为什么会有这种反应;

确信其他成员已经理解你的描述,反之亦然。

2.1.6. 职业道德(10 分钟)

在软件测试中包含了使个人可以获取保密的、授权的信息。为保证信息规范化使用,需要遵循必要的职业道德。ISTQB借鉴、引用了ACM 和IEEE 对于工程师道德规范,陈述职业道德规范如下:

公共–认证测试工程师应当以公众利益为目标。

客户和雇主–在保持与公众利益一致的原则下,认证测试工程师应注意满足客户和雇主的最高利益。

产品–认证测试工程师应当确保他们提供的(在产品和系统中由他们测试的)发布版本符合最高的专业标准。

判断–认证测试工程师应当维护他们职业判断的完整性和独立性。

管理–认证软件测试管理人员和测试领导人员应赞成和促进对软件测试合乎道德规范的管理。

专业–在与公众利益一致的原则下,认证测试工程师应当推进其专业的完整性和声誉。

同事–认证测试工程师对其同事应持平等和互助和支持的态度,并促进与软件开发人员的合作。

自我–认证测试工程师应当参与终生职业实践的学习,并促进合乎道德的职业实践方法。

参考文献:

1.1.5Black, 2001, Kaner,2002 1.2 Beizer, 1990, Black, 2001, Myers, 1979 1.3 Beizer,1990, Hetzel, 1998, Myers, 1979 1.4 Hetzel, 1998 1.4.5 Black, 2001, Craig, 20021.5 Black, 2001, Hetzel, 1988

3． 测试模式

策艺注：对应大纲的软件生命周期中的测试部分。

3.1.  软件生命周期中的测试(K2)(115分钟)

3.1.1.软件开发模型(K2)(20分钟)

3.1.1.1.             术语

商业现货软件(commercialoff the shelf(COTS)、迭代-增量开发模型(iterative-incremental development model)、确认(validation)、验证(verification)、V- 模型(V-model)。

3.1.1.2.             背景

测试不是孤立存在的,测试活动与开发活动息息相关。不同的开发生命周期模型需要不同的测试方法。

3.1.1.3.             V模型(顺序开发模型)(K2)

虽然存在多种多样的V-模型,但典型的V-模型一般有四种测试级别,分别与四种开发级别相对应。

在本课程大纲中,这四种测试级别是:

组件/单元测试;

集成测试;

系统测试;

验收测试。

实际上,V-模型的测试级别可能会比上面提到的4种多,也可能少,或者有不同的测试级别,这取决于不同的项目和软件产品。比如,在组件测试后,可能有组件集成测试,在系统测试后有系统集成测试。

在开发过程中生成的软件工作产品(比如业务场景、用例、需求规格说明、设计文档和代码)常常作为一种或多种测试级别的测试基础。通用的工作产品可以参考能力成熟度模型集成CMMI或软件生命周期过程(IEEE/IEC12207)。验证和确认(早期的测试设计)可以在软件工作产品的开发过程中进行。

3.1.1.4.             迭代-增量开发模型(K2)

迭代-增量开发模型由需求建立、设计、构建和测试等一系列相对较短的开发周期构成。比如:原型开发、快速应用开发(RAD)、统一软件开发过程(RUP)和敏捷开发模型等。在每次迭代过程中,对迭代产生的系统可能需要在不同的测试级别上进行测试。通过将增量模块加入到以前开发的模块中,形成一个逐渐增大的系统,这个系统同样需要进行测试。在完成第一次迭代后,对所有的迭代进行回归测试会变得越来越重要。验证和确认可以在每个增量模块中进行。

3.1.1.5.             生命周期模型中的测试(K2)

在任何生命周期模型中,良好的测试都应该具有下面几个特点:

每个开发活动都有相对应的测试活动;

每个测试级别都有其特有的测试目标;

对于每个测试级别,需要在相应的开发活动过程中进行相应的测试分析和设计;

在开发生命周期中,测试员在文档初稿阶段就应该参与文档的评审。

根据项目的特征或系统的架构,可以对测试级别进行合并或重新进行组合。比如,对于商业现货软件(COTS)产品集成到某个系统,购买者可以在系统级别(例如:与基础设施集成、与其他系统的集成或与系统应用的集成)进行集成测试和验收测试(功能的和/或非功能的测试,用户和/或运行测试等)。

3.1.2.测试级别(K2)(60分钟)

3.1.2.1.             术语

Alpha 测试(alphatesting)、Beta测试(betatesting)、组件测试(componenttesting) (也称为单元测试、模块测试或程序测试)、驱动器(driver)、现场测试(fieldtesting)、功能需求(functionalrequirement)、集成(integration)、集成测试(integrationtesting)、非功能需求(non-functionalrequirement)、健壮性测试(robustnesstesting)、桩(stub)、系统测试(systemtesting)、测试环境(testenvironment)、测试级别(testlevel)、测试驱动开发(test-driven development)、用户验收测试(useracceptance testing)。

3.1.2.2.             背景

对于每个测试级别,都需要明确下面的内容:测试的总体目标、测试用例设计需要参考的工作产品(即测试的依据)、测试的对象(即测试什么)、发现的典型缺陷和失效、对测试用具的需求、测试工具的支持、专门的方法和职责等。

在测试计划中应当考虑是否对系统配置数据进行测试。

3.1.2.3.             组件测试/单元测试(K2)

测试依据:组件需求说明;详细设计文档;代码。

典型测试对象:组件;程序;数据转换/移植程序;数据库模型。

在独立可测试的软件中(模块、程序、对象和类等),可以通过组件测试发现缺陷,以及验证软件功能。根据开发生命周期和系统的背景,组件测试可以和系统的其他部分分开,单独进行测试。在组件测试过程中,会使用到桩、驱动器和模拟器。

组件测试可能包括功能测试和特定的非功能特征测试,比如资源行为测试(如内存泄漏)或健壮性测试和结构测试(比如分支覆盖)。根据工作产品,例如组件规格说明、软件设计或数据模型等设计测试用例。

通常,通过开发环境的支持,比如组件测试框架或调试工具,组件测试会深入到代码中,而且实际上设计代码的开发人员通常也会参与其中。在这种情况下,一旦发现缺陷,就可以立即进行修改,而不需要正式的缺陷管理过程。

组件测试的一个方法是在编写代码之前就完成编写和自动化测试用例,这称之为测试优先的方法或测试驱动开发。这是高度迭代的方法,并且取决于如下的循环周期:测试用例的开发、构建和集成小块的代码,执行组件测试,修正任何问题并反复循环,直到它们全部通过测试。

3.1.2.4.             集成测试(K2)

测试依据:软件和系统设计文档;系统架构;工作流;用例。

典型测试对象:子系统;数据库实现;基础结构;接口;系统配置和配置数据。

集成测试是对组件之间的接口进行测试,以及测试一个系统内不同部分的相互作用,比如操作系统、文件系统、硬件或系统之间的接口。

对于集成测试,可以应用多种集成级别,也可以根据不同的测试对象规模采用不同的级别,比如:

1. 组件集成测试对不同的软件组件之间的相互作用进行测试,一般在组件测试之后进行。

2. 系统集成测试对不同系统或软硬件之间的相互作用进行测试,一般在系统测试之后进行。在这种情况下,开发组织/团体通常可能只控制自己这边的接口,这就可能存在风险。按照工作流执行的业务操作可能包含了一系列系统,因此跨平台的问题可能至关重要。

集成的规模越大,就越难在某一特定的组件或系统中定位缺陷,从而增加了风险并会花费额外的更多时间去发现和修理这些故障。

系统化集成的策略可以根据系统结构(例如自顶向下或自底向上)、功能任务集、事务处理顺序或系统和组件的其他方面等来制定。为了能方便快速地隔离故障和定位缺陷,集成程度应该逐步增加,而不是采用“大爆炸”式的集成。

测试特定的非功能特征(比如性能)也可以包含在系统集成测试中。

在集成的每个阶段,测试员只是把精力集中在集成本身。举例来说,假如集成模块 A和模块B, 测试人员是应该关注两个模块之间的交互,而不是每个模块的功能。功能测试和结构测试方法都可以应用在集成测试。

在理想情况下,测试员应该理解系统的架构,从而可以影响相应的集成计划。假如集成测试计划是在组件或系统生成之前制定,则可以根据对集成最有效率的顺序来进行设计。

3.1.2.5.             系统测试(K2)

测试依据:

系统和软件需求规格说明;

用例;

功能规格说明;

风险分析报告。

典型测试对象:

系统、用户手册和操作手册;

系统配置和配置数据。

系统测试关注的是在开发项目或程序中定义的一个完整的系统/产品的行为。在主测试计划和/或在其所处的测试级别的级别测试计划内应该明确测试范围。

在系统测试中,测试环境应该尽量和最终的目标或生产环境相一致,从而减少不能发现和环境相关的失效的风险。

系统测试可能包含基于不同方面的测试:基于风险评估的、基于需求规格说明的、基于业务过程的、基于用例的、或基于其他对系统行为的更高级别描述或模型的、基于与操作系统的相互作用的、基于系统资源等的测试。

系统测试应该对系统功能和非功能需求进行研究。需求可以以文本形式或模型方式描述。同时测试员也需要面对需求不完全或需求没有文档化的情况。针对功能需求的系统测试开始时可以选择最适合的基于规格说明的测试即黑盒技术来对系统进行测试。比如:可以根据业务准则描述的因果组合来生成决策表。基于结构的技术即白盒测试技术,可以评估测试的覆盖率,可以基于评估覆盖一个结构元素,如菜单结构或者页面的导航等的完整性。(参见第4章)

系统测试通常由独立的测试团队进行。

3.1.2.6.             验收测试(K2)

测试依据:用户需求;系统需求;用例;业务流程;风险分析报告。

典型测试对象:基于完全集成系统的业务流程;操作与维护流程;用户处理过程;结构;报告;配置数据。

验收测试通常是由使用系统的用户或客户来进行,同时系统的其他利益相关者也可能参与其中。

验收测试的目的是建立对系统、系统的某部分或特定的系统非功能特征建立信心。发现缺陷不是验收测试的主要目标。验收测试可以用来评估系统对于部署和使用的准备情况,但是验收测试不一定是最后级别的测试。比如,可能会在进行某个系统验收测试之后,进行大规模的系统集成测试。

验收测试可以在多个测试级别上进行,比如:商业现货软件(COTS)产品可以在安装或集成时进行验收测试;组件的可用性验收测试可以在组件测试中进行;增加新功能的验收测试可以在系统测试之前进行。

验收测试有下面几种典型的类型:

3.1.2.6.1.        用户验收测试

通常由商业用户验证系统的可用性。

3.1.2.6.2.        操作(验收)测试

系统操作验收测试由系统管理员来进行,测试内容主要包括:

系统备份/恢复测试;

灾难恢复测试;

用户管理测试;

维护任务测试;

数据加载和移植活动;

安全漏洞阶段性检查。

3.1.2.6.3.        合同和法规性验收测试

合同验收测试根据合同中规定的生产客户定制软件的验收准则,对软件进行测试。应该在合同拟定时定义验收准则。法规性验收测试根据必须要遵守的法律法规来进行测试,比如政府、法律和安全方面的法律法规。

3.1.2.6.4.        Alpha和Beta(或现场)测试

在软件产品正式商业销售之前,市场或商业现货软件开发人员希望从市场中潜在的或已经存在的客户中得到关于软件的反馈信息。Alpha测试通常在开发组织现场进行,但测试并非由开发团队执行。Beta测试或实地测试,是在客户或潜在客户现场进行并由他们执行。

有些组织也可能使用不同的术语,比如在系统正式移交给客户之前或之后进行的测试分别称为工厂验收测试和现场验收测试等。

3.1.3.测试类型(K2)40分钟

3.1.3.1.             术语

黑盒测试(black-boxtesting)、代码覆盖(codecoverage)、功能测试(functionaltesting)、互操作性测试(interoperabilitytesting)、负载测试(loadtesting)、可维护性测试(maintainability testing)、性能测试(performancetesting)、可移植性测试(portabilitytesting)、可靠性测试(reliabilitytesting)、安全性测试(securitytesting)、压力测试(stresstesting)、结构测试(structuraltesting)、可用性测试(usabilitytesting)、白盒测试(white-boxtesting)。

3.1.3.2.             背景

根据特定的测试目标或测试原因,一系列测试活动可以旨在来对软件系统(或系统的一部分)进行测试。

每种测试类型都会针对特定的测试目标:可能是测试软件所实现的功能;也可能是非功能的质量特征,比如可靠性或可用性;软件或系统的结构或架构;相关变更,如确认缺陷已被修改(确认测试)以及更改后是否引入新的缺陷(回归测试)。

一个软件的模型可以用来开发和/或应用在基于结构的测试(例如,控制流模型或菜单结构模型)、非功能测试(性能模型、可用性模型、安全威胁建模)和功能测试(过程流模型、状态转换模型或简明语言规范)。

3.1.3.3.             功能测试(K2)

系统、子系统或组件要实现的功能可以在工作产品中,如需求规格说明书、用户用例或功能规格说明书予以描述,不过也可能没有相应的文档。功能指的是系统能做什么。

功能测试基于功能和特征(在文档中描述的内容或测试员自己的理解)以及专门的系统之间的交互,可以在各个级别的测试中进行(例如组件测试可以基于组件的规格说明书)。

可以采用基于规格说明的技术,根据软件或系统的功能来设计测试条件和测试用例(参见第4章)。功能测试主要是考虑软件的外部表现行为(黑盒测试)。

安全性测试是功能测试的一种,它会对安全性相关的功能(比如防火墙)进行测试,从而检测系统和数据是否能抵御外部恶意的威胁,如病毒等。互操作性测试是另一种功能性测试,评估软件产品与其他一个或多个组件或系统交互的能力。

3.1.3.4.             软件非功能特征测试(非功能测试)(K2)

非功能测试包括但不限于:性能测试、负载测试、压力测试、可用性测试、可维护性测试、可靠性测试和可移植性测试。非功能性测试就是测试系统运行的表现如何。

非功能测试可以在任何测试级别上执行。术语“非功能测试”是指:为了测量系统和软件的特征,需要进行的测试。这些特征可以用不同尺度予以量化,比如进行性能测试来检验响应时间。这些非功能测试可以参考“软件工程-软件产品质量(ISO9126)”中定义的质量模型。非功能测试关注的是软件的外部行为表现,通常采用黑盒测试设计技术来实现测试用例。

3.1.3.5.             软件结构/架构测试(结构测试)(K2)

可以在任何测试级别上进行结构测试(白盒测试)。结构测试技术最好在进行基于规格说明的测试之后使用,以便通过评估结构类型的覆盖来测量测试的完整性。

覆盖是指结构通过测试套件检验的程度,以项被覆盖的百分比来表示。假如覆盖率不是100%, 可能需要设计更多的测试用例,来测试被遗漏的项,从而提高测试的覆盖。有关覆盖技术参见第4章。

在所有的测试级别,特别是在组件测试和组件集成测试中,可以利用工具来测量代码内某些元素的覆盖率,比如语句覆盖和判定覆盖。结构测试也可以基于系统的结构,比如调用层次结构。

结构测试方法也同样可以运用到系统、系统集成或验收测试级别(比如业务模型或菜单结构)。

3.1.3.6.             与变更相关的测试(再测试和回归测试)(K2)

当发现和修改了一个缺陷后,应进行再测试以确定已经成功的修改了原来的缺陷,这称之为确认。调试(定位并修复缺陷)是一种开发活动,不是一种测试活动。

回归测试是对已被测过的程序在修改缺陷后进行的重复测试,以发现在这些变更后是否有新的缺陷引入或被屏蔽。这些缺陷可能存在于被测试的软件中,也可能在与之相关或不相关的其他软件组件中。当软件发生变更或者应用软件的环境发生变化时,需要进行回归测试。回归测试的规模可以根据在以前正常运行的软件中发现新的缺陷的风险大小来决定。

确认测试和回归测试应该可以重复进行。

回归测试可以在所有的测试级别上进行,同时适用于功能测试、非功能测试和结构测试。回归测试套件一般都会执行多次,而且通常很少有变动,因此将回归测试自动化是很好的选择。

3.1.4.维护测试(K2)(15分钟)

3.1.4.1.             术语

影响分析(impactanalysis)、维护测试(maintenancetesting)。

3.1.4.2.             背景

软件系统一旦部署,通常会服务几年甚至几十年。在这期间,经常需要对软件系统、它的配置数据或它的环境进行修正、改变或扩展。软件版本提升计划对成功的维护测试至关重要。这里必须区分计划中的版本与补丁。维护测试是在一个现有的运行系统上进行,且一旦对软件或系统进行修改、移植或退役处理时,就需要进行维护测试。

修改可以是计划中的功能增加(例如:根据版本发布的计划)、修正和应急变更、环境的变化,比如计划中的操作系统或数据库升级、为商业现货软件计划升级或由于新发现或暴露的操作系统漏洞而打的补丁等。

为移植(如从一个平台移植到另外一个平台)而进行的维护测试应该包括新环境的运行测试,以及对变更以后的软件的运行测试。当数据从另一个应用程序移植到正在维护的系统时,需要移植测试(转换测试)。

为系统退役而进行的维护测试应该包括数据移植测试,或当数据要长时间的保存时还须存档测试。

除了对已变更的部分进行测试外,维护测试还包括对系统没有发生变更的其他部分进行回归测试。维护测试的范围取决于变更的风险、现有系统的规模和变更的大小。维护测试根据变更情况的不同,可以在某一测试级别或所有测试级

别和测试类型上进行。确定变更如何影响现有系统的过程,称之为影响分析,它有助于决定实施回归测试的广度和深度。

如果规格说明遗失、过时或测试人员没有具备领域知识,进行维护测试将是一件困难的事情。

参考文献:

2.1.3CMMI, Craig, 2002, Hetzel, 1998, IEEE 12207 2.2 Hetzel, 1998 2.2.4 Copeland,2004, Myers, 1979 2.3.1 Beizer, 1990, Black, 2001, Copeland, 2004 2.3.2 Black,2001, ISO 9126

2.3.3Beizer, 1990, Copeland, 2004, Hetzel, 1988 2.3.4 Hetzel, 1988, IEEE 829 2.4Black, 2001, Craig, 2002, Hetzel, 1988, IEEE 829

4．静态测试

4.1.  静态技术（K2）60分钟

4.1.1.静态技术和测试过程(K2)15 分钟

4.1.1.1.             术语

动态测试(dynamictesting)、静态测试(statictesting)

4.1.1.2.             背景

与要求运行软件的动态测试技术不同,静态测试技术通过手工检查(评审)或自动化分析(静态分析)的方式对代码或者其他的项目文档进行检查而不需要执行代码。

评审是对软件工作产品(包括代码)进行测试的一种方式,可以在动态测试执行之前进行。在生命周期早期的评审过程中发现并修改缺陷(例如发现需求中的缺陷)的成本会比在动态测试中才发现并修改这些缺陷的成本低的多。

评审可以完全以人工的方式进行,也可以通过工具的支持来进行。人工进行评审的主要活动是检查工作产品,并对工作产品做出评估。可以对任何软件工作产品进行评审,包括需求规格说明、设计规格说明、代码、测试计划、测试规格说明、测试用例、测试脚本、用户指南或web页面等。

软件评审的主要好处有:尽早发现和修改缺陷、改善开发能力、缩短开发时间、缩减测试成本和时间、减少产品生命周期成本、减少缺陷以及改善沟通等。评审也可以在工作产品中发现一些遗漏的内容,例如发现需求有遗漏,而这在动态测试中是很难被发现的。

评审、静态分析和动态测试具有共同的目标:识别缺陷。它们之间是互补的:不同的技术可以有效和高效地发现不同类型的缺陷。与动态测试相比,静态技术发现的是软件失效的原因(缺陷) 而不是失效本身。

与动态测试相比,通过评审更容易发现如下典型缺陷:与标准之间的偏差、需求内的错误、设计错误、可维护性不足和错误的接口规格说明等等。

4.1.2.评审过程(K2)25分钟

4.1.2.1.             术语

入口准则(entrycriteria)、正式评审(formalreview)、非正式评审(informalreview)、审查(inspection)、度量(metric)、主持人/审查负责人(moderator/inspectionleader)、同行评审(peerreview)、评审员(reviewer)、记录员(scribe)、技术评审(technicalreview)、走查(walkthrough)。

4.1.2.2.             背景

评审类型是多样化的,可以是非常不正式的评审(例如评审者没有书面指导性资料可参考),也可以是非常正式的评审(有团队参与,书面的审查结果和管理审查的书面步骤)。评审过程的正式性和以下因素相关:开发过程的成熟度、法律法规方面的要求或审核跟踪的需要。

如何开展评审由评审的目标决定(如,发现缺陷、增加理解,培训测试员和团队新成员或对讨论和决定达成共识等)。

4.1.2.3.             正式评审的阶段(K1)

典型的正式评审由下面几个主要阶段组成:

1. 计划阶段:

定义评审标准;
选择人员;
分配角色;
为更加正式的评审类型(比如审查)制定入口和出口准则;
选择需要进行评审的文档的内容;
核对入口准则(针对更正式的评审类型)。

2. 预备会阶段:

分发文档;
向评审参与者解释评审的目标、过程和文档。

3. 个人准备阶段:

先行评审文档,为评审会议做准备;
标注可能的缺陷、问题和建议;

4. 检查/评价/记录结果(评审会议阶段):

讨论和记录,并留下文档化的结果或会议纪要(针对更正式的评审类型);
标注缺陷、提出处理缺陷的建议、对缺陷作出决策;
在任何形式的会议期间或跟踪任何类型的电子通信期间检查/评价和记录问题。

5. 返工阶段:

修改发现的缺陷(通常由作者来进行);
记录缺陷更新的状态(在正式评审中)。

6. 跟踪结果阶段:

检查缺陷是否已得到解决;
收集度量数据;
核对出口准则(针对更正式的评审类型)。

4.1.2.4.             角色和职责(K1)

典型的正式评审主要有下面几种角色:
经理:决定是否需要进行评审,在项目计划中分派时间,判断是否已达到评审的目标。
主持人:主持文档或文档集的评审活动,包括策划评审、召开会议和会议后的跟踪。假如需要,主持人可能还需要进行不同观点之间的协调。主持人通常是评审成功与否的关键。
作者:待评审文档的作者或主要责任人。
评审员:具有专门技术或业务背景的人员(也称为检查员(checker)或审查员(inspector)),他们在必要的准备后,标识和描述被评审产品存在的问题(如缺陷)。所选择的评审员应该在评审过程中代表不同的观点和角色,并且应该参与各种评审会议。
记录员:记录所有的事件、问题,以及在会议过程中识别的未解决的问题。

从不同的角度评审软件和其相关工作产品并使用检查表可以提高评审的效果和效率。例如,从用户、维护人员、测试人员或操作者的角度编写检查表,或从典型需求问题设计检查表都有助于揭示之前未检测到的问题。

4.1.2.5.             评审类型(K2)

一篇文档可能需要经历多次评审。如果使用了不只一种评审类型,则评审的顺序可能会有所变化。比如,技术评审之前可能会进行非正式评审,或在客户走查之前可能进行需求规格说明审查。常用评审类型的主要特点、选项和目的如下:
非正式评审
没有正式的过程;
可以是由程序员的同行们或技术负责人对设计和代码进行评审;
评审结果可以文档化;
根据不同的评审者,评审作用可能会不同;
主要目的:以较低的成本获得收益。

走查
由作者主持开会；
以场景、演示的形式和同行参加的方式进行;
开放式模式(评审人员预备会议是可选的;包含一个发现问题的列表的评审报告是可选的);
记录员(不是作者本人)是可选的;
在实际情况中可以是非常正式的,也可能是非常不正式的；
主要目的:学习、增加理解、发现缺陷。

技术评审
文档化和定义的缺陷检测过程,需要包含同行和技术专家;
可能是没有管理者参与的同行评审;
理想情况下由专门接受过培训的主持人(不是作者本人)来领导;
会议之前需要进行准备;
使用检查表是可选的;
准备评审报告,包括发现问题的列表、软件产品是否符合需求的判断,与发现的问题合适的建议;
在实际情况中可以是在不正式的和非常正式的之间;
主要目的:讨论、作决策、评估候选方案、发现缺陷、解决技术问题、检查与规格及标准的符合程度。

审查
由接受过专门培训的主持人(不是作者本人)来领导;
通常是同行检查;
定义了不同的角色;
引入了度量;
根据入口、出口规则的检查列表和规则定义正式的评审过程;
会议之前需要进行准备;
出具审查报告和发现问题列表;
正式的跟踪过程(过程改进部分是可选的);
朗读者是可选的;
主要目的:发现缺陷。

走查,技术评审和审查可以是在同行们-即由同一组织级别内的同事们内举行,这种评审类型称为同行评审。

4.1.2.6.             评审成功的因素(K2)

评审成功的因素包括:
每次评审都有预先明确定义的目标;
针对评审目标,有合适的评审人员的参与;
测试人员参加评审不但有利于提高评审质量,还可以通过评审了解产品,为测试尽早开始做准备;
对发现的缺陷持欢迎态度,并客观地描述缺陷;
能够正确处理人员之间的问题以及心理方面的问题(比如对作者而言,能让他觉得有积极正面的体验);
评审应该在一种信任的气氛中进行;并且结果不应用于对参与者的评价;
采用的评审技术适合于要达到的目标、软件工作产品的类型和级别以及参与评审的人员;
选用合适的检查表或定义合适角色,可以提高缺陷识别的有效性;
提供评审技术方面的培训,特别是针对正式的评审技术,比如审查;
管理层对良好评审过程的支持(如在项目计划中安排足够的时间来进行评审活动);
强调学习和过程的改进。

4.1.3.静态分析的工具支持(K2)20 分钟

4.1.3.1.             术语

编译器(complier)、复杂性(complexity)、控制流(controlflow)、数据流(dataflow)、静态分析(staticanalysis)。

4.1.3.2.             背景

静态分析的目的是发现软件源代码和软件模型中的缺陷。静态分析的执行并不需要使用工具去实际运行被测软件。而动态测试是真正运行软件的代码。静态分析可以定位那些在测试过程很难发现的缺陷。与评审一样,静态分析通常发现的是缺陷而不是失效。静态分析工具能够分析程序代码(比如控制流和数据流),以及产生如HTML和XML的输出。

静态分析的好处:
在测试执行之前尽早发现缺陷;
通过度量的计算(比如高复杂性测量),早期警示代码和设计可能存在问题的方面;
可以发现在动态测试过程不容易发现的一些缺陷;
可以发现软件模块之间的相互依赖性和不一致性,例如链接;
改进代码和设计的可维护性;
在开发过程中学习经验教训,从而预防缺陷。

通过静态分析工具能够发现的典型缺陷如下:
引用一个没有定义值的变量;
模块和组件之间接口不一致;
从未使用的变量;
不可达代码或死代码;
逻辑上的遗漏与错误(潜在的无限循环);
过于复杂的结构;
违背编程规则;
安全漏洞;
代码和软件模型的语法错误。

开发人员通常在组件测试和集成测试之前或期间,或当代码签入到配置管理工具时使用静态分析工具(按照预先定义的规则或编程规范进行检查),而设计人员在软件建模期间也使用静态分析工具。静态分析工具会产生大量的警告信息,需要很好的管理这些信息,从而可以有效地使用静态分析工具。

编译器也可以为静态分析提供一些帮助,包括度量的计算。

参考文献：

3.2.2Gilb, 1993, van Veenendaal, 2004 3.2.4 Gilb, 1993, IEEE 1028 3.3 VanVeenendaal, 2004

5． 测试设计

5.1.  测试设计技术（K3）285分钟

5.1.1.测试开发过程（K2）15分钟

5.1.1.1.             术语

测试用例规格说明（testcase specification）、测试设计（testdesign）、测试执行进度表（testexecution schedule）、测试规程规格说明（testprocedure specification）、测试脚本（testscript）、可追溯性（traceability）。

5.1.1.2.             背景

可以采用不同的方法完成本章节描述的过程，根据具体情况，可以采用很少的或没有文档的非正式方式到采用非常正式的方式（如下所述）。正式的程度是依赖于测试的背景，包括组织的架构、测试及开发过程的成熟度、项目时间的限制、安全或规范需求以及什么样的人员参与等。

在测试分析阶段，要对测试基础文档进行分析，从而决定测试什么，也就是明确测试的条件。将测试条件定义为能通过一个或多个测试用例进行验证的一个条目或事件（比如功能、事务处理、质量特征或结构元素等）。

建立从测试条件到需求的可追溯性，有助于需求变更时的影响分析和测试用例集的需求覆盖率分析。在测试分析阶段，除了考虑一些其它的因素，基于已经识别的风险，实施具体的测试方法从而选择要采用的测试技术（有关风险分析的更多的内容请参见第5章）。

在测试设计阶段，要定义和记录测试用例和测试数据。测试用例由：一组输入值、执行的前提条件、预期结果和执行的后置条件等元素组成，以覆盖一定的产生目标或测试条件。测试设计规格说明（包含测试条件）和测试用例规格说明的内容在“软件测试文档标准（IEEEStd 829-1998）”中有具体的描述。

预期的测试结果应该作为测试用例规格说明的一部分，同时包含输出、数据和状态的变化，以及其他的测试结果。假如没有明确预期结果，则一个看似合理却错误的结果可能被视为正确的结果。理想情况下预期结果应该在测试执行之前明确定义。

在测试实现阶段，测试用例的开发、实现、确定优先级和组织都应该包含在测试规程规格说明中（IEEESTD 829-1998）。测试规程（或者手工测试脚本）描述了测试用例执行的顺序。如果使用测试执行工具进行测试，这种测试的动作顺序将在测试脚本中描述（自动化的测试规程）。

不同的测试规程和自动化测试脚本要体现在测试执行进度表中，该计划定义了不同测试规程和可能的自动化测试脚本的执行顺序、执行的时间和执行者。测试执行进度表同时考虑了其他的因素，比如回归测试、测试优先级以及技术和逻辑的依赖等。

5.1.2.测试设计技术的种类（K2）15分钟

5.1.2.1.             术语

黒盒测试设计技术（black-boxtest design technique）、基于经验的测试设计技术（experience-basedtest design technique）、测试设计技术（testdesign technique）、白盒测试设计技术（white-boxtest design technique）。

5.1.2.2.             背景

使用测试设计技术的目的是为了识别测试条件和开发测试用例。

将测试技术分为黑盒测试技术与白盒测试技术是一种比较传统的分类方法。黑盒测试设计技术（也称为基于规格说明的测试技术）是依据分析测试基础文档来选择测试条件、测试用例或测试数据的技术。它包括了功能和非功能的测试。黑盒测试，顾名思义，不需要使用任何关于被测组件或系统的内部结构信息。白盒测试设计技术（也称为结构化或基于结构的测试技术）是基于分析被测组件或系统的结构的测试技术。黑盒和白盒测试也可以与基于经验的技术结合，以补充开发人员、测试人员和用户的经验，从而决定什么应该被测试。

有些技术可以明确地归为单一的类，而有些可以属于不同的类别。

本大纲涉及基于规格说明的方法归为黑盒测试技术，而基于结构的方法归为白盒测试技术。另外还有基于经验的测试设计技术。

基于规格说明的测试技术具有以下共同特点：
使用正式或非正式的模型来描述需要解决的问题、软件或其组件等；
根据这些模型，可以系统地导出测试用例。

基于结构的技术的共同特点：
根据软件的结构信息设计测试用例，比如软件代码和详细设计信息；
可以通过已有的测试用例测量软件的测试覆盖率，并通过系统化的导出设计用例来提高覆盖率。

基于经验的方法具有以下共同特点：
测试用例根据参与人员的经验和知识来编写；
测试人员、开发人员、用户和其他的利益相关者对软件、软件使用和环境等方面所掌握的知识作为信息来源之一；
对可能存在的缺陷及其分布情况的了解作为另一个信息来源。

5.1.3.基于规格说明或黑盒测试技术（K3）150分钟

5.1.3.1.             术语

边界值分析（boundaryvalue analysis）、决策表测试（decisiontable testing）、等价类划分（equivalencepartitioning）、状态转换测试（statetransition testing）、用例测试（usecase testing）。

5.1.3.2.             等价类划分（K3）

可以将软件或系统的输入分成不同的组，对于同一个组的输入，软件或系统应该有相似的表现行为，就好像系统是以相同的方式对这些输入值进行处理。等价类划分（或等价类）可以分为两种类型的数据：有效数据（即应该被系统接受的数据）和无效数据（即应该被系统拒绝的数据）。等价类划分也可以基于输出、内部值、时间相关的值（例如在事件之前或之后）以及接口参数（在集成测试阶段）等进行。可以设计测试用例来覆盖所有有效和无效等价类。等价类划分可以应用在所有测试级别上。

通过应用等价类划分技术，能够实现输入覆盖和输出覆盖。它同样适用于人为的输入、通过系统接口的输入以及集成测试中的接口参数。

5.1.3.3.             边界值分析（K3）

在各等价类划分的边界通常更可能出现不正确的行为，因此边界就是测试比较可能发现缺陷的区域。每个划分的最大和最小值就是它的边界值。有效部分的边界就是有效边界值，无效部分的边界就是无效边界值。测试的设计应当既覆盖有效边界值又覆盖无效边界值。在设计测试用例时，应该将每个边界值包含在测试用例中。

边界值分析可以应用于所有的测试级别。这种方法的应用相对简单，发现缺陷的能力也比较高，同时，详细的规格说明对边界值分析很有帮助。

边界值分析技术通常被认为是等价类划分技术或其他黑盒测试设计技术的一种拓展。它可以应用在用户从屏幕输入的等价类中，也可以应用在如时间段的范围（如超时，对事务处理速度的需求）或表的边界（如表大小为256×256）等方面。

5.1.3.4.             决策表测试（K3）

决策表是一种很好的方法，它可以识别含有逻辑条件的系统需求，还可以将内部系统设计文档化。这种方法可以用来记录一个系统要实施的复杂的业务规则。建立决策表时，要分析规格说明，并识别系统的条件和动作。输入条件和动作通常以“真”或“假”（布尔变量）的方式进行表述。决策表包含了触发条件，通常还有各种输入条件真或假的组合以及各条件组合相应的输出动作。决策表的每一列对应了一个业务规则，该规则定义了各种条件的一个特定组合，以及这个规则相关联的执行动作。决策表测试的常见覆盖标准是每列至少对应一个测试，该测试通常覆盖触发条件的所有组合。

决策表测试的优点是可以生成测试条件的各种组合，而这些组合可能利用其他方法会无法被测试到。它适用于所有当软件的行为由一些逻辑决策所决定的情况。

5.1.3.5.             状态转换测试（K3）

根据系统当前的情况或先前的情况（如系统先前的状态），系统可能会产生不同的响应。这种情况下，系统的特征可以通过状态转换图来表示。测试员可以根据软件的状态、状态间的转换、触发状态变化（转换）的输入或事件以及从状态转换导致的可能的行动来进行测试。被测试系统或对象的状态是独立的、可确认的，并且数量是有限的。

一个状态表描绘了状态和输入之间的关系，并能显示可能的无效状态转换。

设计的测试可以覆盖一个典型的状态序列，或覆盖每个状态，或执行每个状态转换，或执行特定顺序的状态转换或测试无效的状态转换。

状态转换测试方法普遍较多的使用在嵌入式软件行业和自动化行业。但是这个技术同样也适用于有特定状态的业务对象的建模或测试具有对话框状态转换流的系统（例如互联网应用或业务场景）。

5.1.3.6.             用例测试（K2）

可以通过用例来设计测试。用例描述了参与者（用户或系统）之间的相互作用，并从这些交互产生一个从系统用户或客户的角度所期望和能观察到的结果。通常可以在抽象层（业务用例、不受技术限制、业务流程层面）或系统层（系统功能层面的系统用例）来描述用例。每个用例都有测试的前置条件，这是用例成功执行的必要条件。每个用例结束后都存在后置条件，这是在用例执行完成后能观察到的结果和系统的结束状态。用例通常有一个主场景（即最有可能发生的场景）和可选场景。

用例基于系统最可能使用的情况描述了过程流，因此从用例中得到的测试用例，在真实世界中的系统使用过程流中能最有效的发现系统的缺陷。用例非常有助于设计用户/客户参与的验收测试；也可以帮助发现由于不同组件之间的相互作用和相互影响而产生的集成缺陷，这是在单个的组件测试中是无法发现的。从用例中设计测试用例可以和其他基于规格说明的测试技术结合起来使用。

5.1.4.基于结构的或白盒技术（K4）60分钟

5.1.4.1.             术语

代码覆盖（codecoverage）、判定覆盖（decisioncoverage）、语句覆盖（statementcoverage）、基于结构的测试（structure-basedtesting）。

5.1.4.2.             背景

 

基于结构的测试/白盒测试是根据识别软件或系统的结构，可以从以下内容得到进一步的理解：

组件级别：软件组件的结构，比如：语句、判定、分支或每个不同的路径；

集成级别：结构可能是调用树（模块调用关系图）；

系统级别：结构可能是菜单结构、业务过程或web页面结构。

基于语句、分支和判定，本节将讨论三种与代码相关的结构化测试设计技术的代码覆盖。对于判定覆盖，可以使用控制流图来形象表示每个判定之间的转换。

5.1.4.3.             语句覆盖和覆盖率（K4）

在组件测试中，语句覆盖是指评价一个测试用例套件中已经执行的可执行语句的百分比。语句测试的测试用例用来执行专门的语句，通常用来增加语句的覆盖率。

语句覆盖率取决于被（设计或执行）测试用例覆盖的可执行语句数量除以被测代码中所有可执行语句数量。

5.1.4.4.             判定覆盖和覆盖率（K4）

判定覆盖，和分支测试相关，是指评价在一个测试用例套中已经执行的判定（例如if语句的true和false选项）输出的百分比。判定测试的测试用例用来执行专门的判定输出。分支起始于代码中的判定点，并表明了在代码中不同位置的控制转移。

判定覆盖率取决于被（设计或执行）的测试用例覆盖的所有判定出口数目除以被测代码中所有可能的判定出口数目。

判定测试是控制流测试技术的一种方式，它在判定点产生一个专门的控制流。判定覆盖比语句覆盖更全面，100％的判定覆盖可以保证100％的语句覆盖，反之则不行。

5.1.4.5.             其他的基于结构的技术（K1）

除了判定覆盖，还有程度更高的基于结构的覆盖，如条件覆盖和多重条件覆盖。

覆盖的概念也可以用于其他的测试级别（比如集成测试级别等），在一个测试用例套件中被执行的模块、组件或类覆盖的百分比可以分别称为模块覆盖、组件覆盖或类的覆盖。

在进行代码的结构测试中使用工具支持是非常有帮助的。

5.1.5.基于经验的技术（K2）30分钟

5.1.5.1.             术语

探索性测试（exploratorytesting）、缺陷攻击（faultattack）。

5.1.5.2.             背景

基于经验的测试是根据测试人员对相似的应用或技术的经验以及知识和直觉来进行测试的，如果是用来协助系统化的测试方法，这些技术能够识别一些正式技术不能获取的特殊测试，特别是当用在正式技术之后会更有效。但是，这种技术依据测试员的经验，所以产生的效果会有极大的不同。

一个比较常见的基于经验的技术是错误推测法。一般情况下，测试人员是靠经验来预测缺陷。错误推测法的一个结构化方法是列举可能的错误，并设计测试来攻击这些错误，这种系统的方法称之为缺陷攻击。可以根据经验、已有的缺陷和失败数据以及有关软件失败的常识等方面的知识来设计这些缺陷和失效的列表。

探索性测试是指依据包含测试目标的测试章程来同时进行测试设计、测试执行、测试记录和学习，并且是在规定时间内进行的。这种方法在规格说明较少或不完备且时间压力大的情况下使用更有帮助，或者作为对其他更为正式的测试的增加或补充。它可以作为测试过程中的检查，以有助于确保能发现最为严重的缺陷。

5.1.6.选择测试技术（K2）15分钟

5.1.6.1.             术语

无

5.1.6.2.             背景

测试技术的选择基于下面的几个因素，包括：系统类型、法律法规标准、客户或合同的需求、风险的级别、风险的类型、测试目标、文档的可用性、测试员的技能水平、时间和成本预算、开发生命周期、用例模型和以前发现各类缺陷的经验等。

有些测试技术适合于特定的环境和测试级别；而有些则适用于所有的测试级别。

在建立测试用例时，测试人员通常会组合多种测试技术并结合流程、规则和数据驱动技术来保证对测试对象足够的覆盖率。

参考文献：
4.1 Craig, 2002, Hetzel, 1988, IEEE 829，4.2 Beizer, 1990, Copeland, 2004，4.3.1Copeland, 2004, Myers, 1979，4.3.2Copeland, 2004, Myers, 1979，4.3.3Beizer, 1990, Copeland, 2004，
4.3.4 Beizer, 1990,Copeland, 2004，4.3.5 Copeland, 2004，4.4.3 Beizer, 1990, Copeland,2004，4.5Kaner, 2002，4.6Beizer, 1990, Copeland, 2004

6． 测试管理

6.1.  测试管理（K3）170分钟

6.1.1.测试组织（K2）30分钟

6.1.1.1.       术语

测试员（tester）、测试组长（testleader）、测试经理（testmanager）

6.1.1.2.             测试组织和测试独立性（K2）

通过独立的测试员进行测试和评审，发现缺陷的效率会提高。可能的独立测试如下：
不独立的测试员，开发人员测试自己的代码；
开发团队内独立的测试员；
组织内独立的测试小组或团队，向项目经理或执行经理汇报；
来自业务组织、用户团体内的独立测试e员；
针对特定测试类型的独立测试专家，例如：可用性测试员、安全性测试员或认证测试员（他们根据标准和法律法规对软件产品进行认证）；
外包或组织外的独立测试人员。

对于庞大、复杂或安全关键的项目，通常最好有多级别的测试，并让独立的测试员负责某些级别或所有的测试。开发人员也可以参与测试，尤其是一些低级别的测试,但是开发人员往往缺少客观性，会限制他们测试的有效性。独立测试员可以有权要求和定义测试过程及规则，但是测试员应该只有在存在明确管理授权的情况下才能充当这种过程相关的角色。

独立测试的优点：
独立的测试员是公正的，可以发现一些其他不同的缺陷。；
一个独立的测试员可以验证在系统规格说明和实现阶段所做的一些假设。

独立测试的缺点：
与开发小组脱离（如果完全独立）；
开发人员可能丧失对软件质量的责任感；
独立的测试员可能被视为瓶颈或者成为延时发布而被责备的对象。

测试任务可以由专门的测试员完成，也可以由其他的角色来完成，比如项目经理、质量经理、开发人员、业务和领域内的专家、基础架构或IT的运行人员。

6.1.1.3.             测试组长和测试员的任务（K1）

在本课程大纲中，涉及两个测试角色：测试组长和测试员。这两个角色执行的活动和任务是由项目和产品的背景、人员的角色和组织结构来决定的。

有时候，测试组长也称为测试经理或测试协调人。测试组长的角色也可以由项目经理、开发经理、质量保证经理或测试组的经理来担任。在较大的项目中，常常会有两个职位：测试组长和测试经理。测试组长通常计划、监督和控制1.4章节中定义的测试活动和任务。

测试组长可能的主要任务包括：

与项目经理以及其他人共同协调测试策略和测试计划；
制定或评审项目的测试策略和组织的测试方针；
将测试的安排合并到其他项目活动中，比如集成计划；
制定测试计划（要考虑背景，了解测试目标和风险），包括选择测试方法，估算测试的时间、工作量和成本，获取资源，定义测试级别、测试周期并规划事件管理；
启动测试规格说明、测试准备、测试实施和测试执行，监督测试结果并检查出口准则；
根据测试结果和测试过程（有时记录在状态报告中）调整测试计划，并采取任何必要措施对存在的问题进行补救；
对测试件进行配置管理，保证测试件的可追溯性；
引入合适的度量项以测量测试进度，评估测试和产品的质量；
决定什么应该自动化，自动化的程度，以及如何实现；
选择测试工具支持测试，并为测试员组织测试工具使用的培训；
决定关于测试环境实施的问题；
根据在测试过程中收集的信息编写测试总结报告。

测试员可能的主要任务包括：

评审和参与测试计划的制定；
分析、评审和评估用户需求、规格说明书及模型的可测试性；
创建测试规格说明；
建立测试环境（通常需要系统管理员，网络管理员协同完成）；
准备和获取测试数据；
进行所有级别的测试，执行并记录测试日志，评估测试结果，记录和预期结果之间的偏差。
根据需要使用测试管理工具和测试监控工具；
实施自动化测试（可能需要开发人员或测试自动化专家的支持）；
在可行的情况下，测量组件和系统的性能；
对他人的测试进行评审。

从事测试分析、测试设计、特定测试类型或自动化测试方面的工作人员都可以是这些角色的专家。根据测试级别及与产品和项目相关的风险，可以由不同的人员担任测试员的角色，以保持一定程度的独立性。在组件和集成测试的级别，典型的测试员可能是开发人员，进行验收测试的典型测试员可能是业务方面的专家和用户，进行运行验收测试的典型测试员可能是运行操作者。

6.1.2.测试计划和估算（K2）40分钟

6.1.2.1.             术语

测试方法（testapproach），测试策略（teststrategy）

6.1.2.2.             测试计划（K2）

本章节将描述在开发和实施项目以及维护过程中，制定测试计划的目的。测试计划可以在项目计划或主测试计划中文档化，也可以在不同的测试级别（如系统测试和验收测试）的测试计划中文档化。测试计划文档的大纲可以参考“软件测试文档标准”（IEEEStd 829-1998）。

测试计划受到很多因素的影响：组织的测试方针、测试范围、测试目标、风险、约束、关键程度、可测试性和资源的可用性等。随着项目和测试计划的不断推进，将有更多的信息和具体细节包含在计划中。

测试计划是个持续的活动，需要在整个生命周期过程和活动中进行。从测试中得到的反馈信息可以识别变化的风险，从而对计划作相应的调整。

6.1.2.3.             测试计划活动（K3）

对整个系统或部分系统可能的测试计划活动包括：
确定测试的范围和风险，明确测试的目标；
决定总体测试方法，包括测试级别、入口和出口准则的界定；
把测试活动整合和协调到整个软件生命周期活动中去（采购、供应、开发和运维）；
决定测试什么？测试由什么角色来执行？如何进行测试？如何评估测试结果？
为测试分析和设计活动安排时间进度；
为测试实现、执行和评估安排时间进度；
为已定义的不同测试活动分配资源；
定义测试文档的数量、详细程度、结构和模板；
为监控测试准备和执行、缺陷解决和风险问题选择度量项；
确定测试规程的详细程度，以提供足够的信息支持可复用的测试准备和执行。

6.1.2.4.             入口准则（K2）

入口准则定义了什么时候可以开始测试，如某个测试级别的开始，或什么时候一组测试准备就绪可以执行。

入口准则主要包含：
测试环境已经准备就绪并可用；
测试工具在测试环境中已经准备就绪；
可测的代码可用；
测试数据可用。

6.1.2.5.             出口准则（K2）

测试出口准则（exitcriteria）的目的是：定义什么时候可以停止测试，比如某个测试级别的结束，或者当测试达到了规定的目标。

出口准则主要包含：
完整性测量，比如代码、功能或风险的覆盖率；
对缺陷密度或可靠性度量的估算；
成本；
遗留风险，例如没有被修改的缺陷或在某些部分测试覆盖不足；
进度表，例如基于交付到市场的时间。

6.1.2.6.             测试估算（K2）

在本大纲中，有两种估算测试工作量的方法：
基于度量的方法：根据以前或相似项目的度量值来进行测试工作量的估算，或者根据典型的数据来进行估算；
基于专家的方法：由任务的责任人或专家来进行测试任务工作量的估算。

一旦估算了测试工作量，就可以识别资源和制定时间进度表。

测试的工作量可能取决于多种因素，包括：
产品的特点：规格说明和用于测试模型的其它信息（即测试依据）的质量，产品的规模，问题域的复杂度，可靠性、安全性的需求和文档的需求；
开发过程的特点：组织的稳定性、使用的工具、测试过程、参与者的技能水平和时间紧迫程度等；
测试的输出：缺陷的数量和需要返工的工作量。

6.1.2.7.             测试策略，测试方法（K2）

在特定项目中，测试方法是测试策略的具体实现。测试方法是在测试计划和设计阶段中被定义并逐步细化的。它通常取决于（测试）项目目标和风险评估。它是规划测试过程、选择测试设计技术和应用的测试类型以及定义入口和出口准则的起点。

测试方法的选择取决于实际情况，应当考虑风险、危害和安全、可用资源和人员技能、技术、系统的类型（比如客户定制与商业现货软件的比较）、测试对象和相关法规。

典型的测试方法包括：
分析的方法，比如基于风险的测试，直接针对风险最高的部分进行测试；
基于模型的方法，比如随机测试利用失效率（如:可靠性增长模型）或使用率（如：运行概况）的统计信息；
系统的方法，比如基于失效的方法（包括错误推测和故障攻击），基于检查表的方法和基于质量特征的方法；
基于与过程或符合标准的方法，比如在行业标准中规定的方法或各类敏捷的方法；
动态和启发式的方法，类似于探索性测试，测试很大程度上依赖于事件而非提前计划，而且执行和评估几乎是同时进行的；
咨询式的方法，比如测试覆盖率主要是根据测试小组以外的业务领域和/或技术领域专家的建议和指导来推动的；
可重用的方法，比如重用已有的测试材料，广泛的功能回归测试的自动化，标准测试套件等。

可以结合使用不同的测试方法，比如基于风险的动态方法。

6.1.3.测试过程的监控（K2）20分钟

6.1.3.1.             术语

缺陷密度（defectdensity）、失效率（failurerate）、测试控制（testcontrol）、测试监控（testmonitoring）、测试总结报告（testsummary report）。

6.1.3.2.             测试过程监控（K1）

测试监控的目的是提供关于测试活动的反馈信息，使测试活动保持可视性。监控的信息可以通过手工或自动的方式进行收集，同时可以用来衡量出口准则，比如测试覆盖率。也可以用度量数据对照原计划的时间进度和预算来评估测试的进度。常用的测试度量项有：
测试用例准备工作完成的百分比（或按计划已编写的测试用例的百分比）；
测试环境准备工作完成的百分比；
测试用例执行情况（例如：执行/没有执行的测试用例数，通过/失败的测试用例数）；
缺陷信息（例如：缺陷密度、发现并修改的缺陷、失效率、重新测试的结果）；
需求、风险或代码的测试覆盖率；
测试员对产品的主观信心；
测试里程碑的日期；
测试成本，包括寻找下一个缺陷或执行下一轮测试所需成本与收益的比较。

6.1.3.3.             测试报告（K2）

测试报告是对测试工作和活动等相关信息的总结，主要包括：
在测试周期内发生了什么？比如达到测试出口准则的日期；
通过分析相关信息和度量可以对下一步的活动提供建议和做出决策，比如对遗留缺陷的评估、继续进行测试的经济效益、未解决的风险以及被测试软件的置信度等。

测试总结报告的大纲可以参考“软件测试文档标准”（IEEEStd 829-1998）。

需要在测试级别的过程中和完成时收集度量信息，来评估：
该测试级别的测试目标实现的充分性；
采用的测试方法的适当性；
针对测试目标的测试的有效性。

6.1.3.4.             测试控制（K2）

测试控制描述了根据收集和报告的测试信息和度量而采取的指导或纠正措施。措施可能包括任何测试活动，也可能影响其它软件生命周期中的活动或任务。

测试控制措施的例子：
基于测试监控信息来做决策；
如果一个已识别的风险发生（如软件交付延期），重新确定测试优先级；
根据测试环境可用性，改变测试的时间进度表；
设定入口准则：规定修改后的缺陷必须经过开发人员再测试（确认测试）后才能将它们集成到版本中去。

6.1.4.   配置管理（K2）10分钟

6.1.4.1.             术语

配置管理（configurationmanagement）、版本控制（versioncontrol）。

6.1.4.2.             背景

配置管理的目的是在整个项目和产品的生命周期内，建立和维护软件或系统产品（组件、数据和文档）的完整性。

对测试而言，采用配置管理可以确保：
测试件的所有相关项都已经被识别，版本受控，相互之间有关联以及和开发项（测试对象）之间有关联的变更可跟踪，从而保证可追溯性；
在测试文档中，所有被标识的文档和软件项能被清晰明确的引用。

对于测试员来说，配置管理可以帮助他们唯一地标识（并且复制）测试项、测试文档、测试用例和测试用具。

在测试计划阶段，应该选择配置管理的规程和基础设施（工具），将其文档化并予以实施。

6.1.5.风险和测试（K2）30分钟

6.1.5.1.             术语

产品风险（productrisk）、项目风险（projectrisk）、风险（risk）、基于风险的测试（risk-basedtesting）。

6.1.5.2.             背景

风险可以定义为事件、危险、威胁或情况等发生的可能性以及由此产生不可预料的后果，即一个潜在的问题。风险级别取决于发生不确定事件的可能性和产生的影响（事件引发的不良后果）。

6.1.5.3.             项目风险（K2）

项目风险是围绕项目按目标交付的能力的一系列风险，比如：
组织因素：
技能、培训和人员的不足；
个人问题；
政策因素，比如：与测试员进行需求和测试结果沟通方面存在的问题；测试和评审中发现的信息未能得到进一步跟踪（如未改进开发和测试实践）；
对测试的态度或预期不合理（如：没有意识到在测试中发现缺陷的价值）。
技术因素：
不能定义正确的需求；
给定现有限制的情况下，没能满足需求的程度；
测试环境没有及时准备好；
数据转换、迁移计划，开发和测试数据转换/迁移工具造成的延迟；
低质量的设计、编码、配置数据、测试数据和测试。
供应商因素：
第三方存在的问题；
合同方面的问题。

在分析、管理和缓解这些风险的时候，测试经理需要遵循完善的项目管理原则。“软件测试文档标准”（IEEEStd 829-1998）中指出，测试计划需要陈述风险和应急措施。

6.1.5.4.             产品风险（K2）

在软件或系统中的潜在失效部分（即将来可能发生不利事件或危险）称之为产品风险，因为它们对产品质量而言是一个风险，包括：
故障频发的软件交付使用；
软件/硬件对个人或公司造成潜在损害的可能性；
劣质的软件特性（比如功能性、可靠性、易用性和性能等）；
低劣的数据完整性和质量（例如：数据迁移问题、数据转换问题、数据传输问题、违反数据标准问题）；
软件没有实现既定的功能。

风险通常可以用来决定从什么地方开始测试，什么地方需要更多的测试。测试可以用来降低风险或可以减少负面事件的影响。

产品风险对于项目的成功来讲是一种特殊类型的风险。作为一种风险控制活动，测试通过评估修正严重缺陷的能力和应急计划的有效性来提供关于遗留风险的反馈信息。

在项目初期阶段，使用基于风险的方法进行测试，有利于降低产品风险的级别。它包括对产品风险的识别，并且将这些风险应用到指导测试计划和控制、规格说明、测试准备和执行中。在基于风险的测试方法中，识别出的风险可以用于：
决定采用的测试技术；
决定要进行测试的范围；
确定测试的优先级，尝试尽早的发现严重缺陷；
决定是否可以通过一些非测试的活动来降低风险（比如对缺乏经验的设计者进行相应的培训）。

基于风险的测试需要借助于项目利益相关者的集体知识和智慧，从而识别风险以及为了应对这些风险需要采用的测试级别。

为了确保产品失效机会最小化，风险管理活动提供了一些系统化的方法：
评估（并定期重新评估）可能出现的错误（风险）；
决定哪些风险是重要的需要处理的；
处理风险的具体措施。

另外，测试可以帮助识别新的风险，可以有助于确定应该降低哪些风险，以及降低风险的不确定性。

6.1.6.事件管理（K3）40分钟

6.1.6.1.             术语

事件日志（incidentlogging）、事件管理（incidentmanagement）、事件报告（incidentreport）。

6.1.6.2.             背景

测试的目的之一是发现缺陷，所以实际结果和预期结果之间的差异需要作为一个事件被记录。事件必须进行调查，并且有可能最终被证明是一个缺陷。应当定义合理的措施以便对事件和缺陷进行有效处理。事件和缺陷应该从发现和分类就开始跟踪，直到改正并被确认已经解决。为了完成所有事件的管理，应该在组织内建立一套完整的事件管理过程和分类规则。

在软件产品的开发、评审和测试、以及软件使用的过程中都会产生事件。它们可能是在代码内或在使用的系统内或以任意方式在文档内产生（包括需求文档、开发文档、测试文档和用户文档，如“帮助”或安装手册等）。

事件报告的主要目标如下：
为开发人员和其他人员提供问题反馈，在需要的时候可以进行识别、隔离和纠正；
为测试组长提供一种有效跟踪被测系统质量和测试进度的方法；
为测试过程改进提供资料。

事件报告的具体内容主要包括：
提交事件的时间，提交的组织和作者；
预期和实际的结果；
识别测试项（配置项）和环境；
发现事件时软件或系统所处的生命周期阶段；
为了能确保重现和解决事件需要描述事件（包括日志、数据库备份或截屏）；
对利益相关者的影响范围和程度；
对系统影响的严重程度；
修复的紧迫性/优先级；
事件状态（例如：打开的、延期的、重复的、待修复的、修复后待重测的或关闭的等）；
结论、建议和批准；
全局的影响，比如事件引起的变更可能会对系统的其他部分产生影响；
变更历史记录，比如针对事件的隔离、修改和已修改的确认，项目组成员所采取的行动顺序；
参考，包括发现问题所用的测试用例规格说明的标识号。

事件报告的大纲也可以参考“软件测试文档标准”（IEEEStd 829-1998）。

参考文献：
5.1.1 Black, 2001, Hetzel, 1988，5.1.2 Black, 2001, Hetzel, 1988，5.2.5Black, 2001, Craig, 2002, IEEE Std 829-1998, Kaner 2002，5.3.3 Black, 2001, Craig,2002, Hetzel, 1988, IEEE Std 829-1998
5.4 Craig, 2002，5.5.2Black, 2001, IEEE Std 829-1998，5.6 Black, 2001, IEEE Std 829-1998

7． 软件测试工具

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

7.1.1.测试工具的类型（K2）45分钟

7.1.1.1.             术语

配置管理工具（configurationmanagement tool）、覆盖率工具（coveragetool）、调试工具（debuggingtool）、动态分析工具（dynamicanalysis tool）、事件管理工具（incidentmanagement tool）、负载测试工具（loadtesting tool）、建模工具（modelingtool）、监控工具（monitoringtool）、性能测试工具（performancetesting tool）、探测影响（probeeffect）、需求管理工具（requirementmanagement tool）、评审工具（reviewtool）、安全性工具（securitytool）、静态分析工具（staticanalysis tool）、压力测试工具（stresstesting tool）、测试比较器（testcomparator）、测试数据准备工具（testdata preparation tool）、测试设计工具（testdesign tool）、测试用具（testharness）、测试执行工具（testexecution tool）、测试管理工具（testmanagement tool）、单元测试框架工具（unittest framework tool）。

7.1.1.2.             理解使用测试工具支持测试的意义和目的（K2）

测试工具可以用于支持一种或多种测试活动。包括：

1. 直接用于测试的工具，如测试执行工具、测试数据生成工具和结果对比工具；

2. 测试过程管理工具，如用于管理测试、测试结果、数据、需求、事件、缺陷等等，并且可以报告和监控测试执行；

3. 用于观测的工具，或简单地说就是探索（例如：监控应用程序文件活动的工具）；

4. 任何对测试有帮助的工具（从这个意义来说，电子表格也是测试工具）。

根据实际情况，工具支持测试可以有如下一个或多个目的：

可以通过自动重复任务改进测试活动的效率，或支持手动测试活动，如测试计划、测试设计、测试报告与监控；

当手动进行需要大量资源时，可使用自动执行（例如，静态测试）；

无法手动完成的测试可以将其自动化（例如：CS应用程序的大规模性能测试）；

增加测试的可靠性（例如：进行大量数据的自动比较或是行为模拟）。

术语“测试框架”也被大量的应用于工业界，它至少有三个含义：

可重用、可扩展的测试库，可用于搭建测试工具（也称为测试用具）；

设计测试自动化的设计类型（例如：数据驱动、关键字驱动）；

测试执行的全过程。

基于本大纲的目的，术语“测试框架”的前两种含义，在章节6.1.6有所描述。

7.1.1.3.             测试工具分类（K2）

有很多工具可以支持不同类型的测试活动。工具可以按照多种规则进行分类，例如：目的、商业/免费/开源/共享、使用的技术等。在本大纲中，是按照测试工具能支持的测试活动来进行分类。

有些工具明确支持一种活动；有些工具可以支持多种活动，但将它们分类到联系最紧密的那一类活动中。同一家供应商的测试工具，尤其是那些为了协同工作而设计的测试工具，可能会被捆绑到一个软件包中。

某些类型的测试工具本身是植入式的，这意味着测试的实际结果可能会受到影响。比如，由于工具执行了额外的指令，可能导致实际时间的不同，或者你可能得到了不同的代码覆盖率。一个工具的植入式特征也称之为探测影响。

某些测试工具提供的支持可能更适合开发人员（比如在进行组件和组件集成测试时使用的工具）。在以下的分类中将这些工具用“D”来标记。

7.1.1.4.             测试管理的工具支持（K1）

管理工具适用于整个软件生命周期中的所有测试活动。

测试管理工具

这些工具除了提供测试执行、缺陷跟踪和需求管理的接口外，还提供定量分析和测试对象的报告。它还支持追溯测试对象到需求规格说明并可提供独立的版本控制能力或提供一个外部接口。

需求管理工具

需求管理工具储存了需求描述、需求的一些属性（包括优先级），并提供唯一的标识符以及从需求到相应测试的可追溯性。这些工具也可以帮助识别自相矛盾或遗漏的需求。

事件管理工具（缺陷跟踪工具）

这类工具存储并管理事件报告，即缺陷、失效、变更请求或察觉到的问题和异常，并协助管理事件的整个生命周期，为静态分析提供了可能。

配置管理工具

严格的来说，配置管理工具并不能算是测试工具，但对测试件和相关软件的存储和版本管理时却是必要的，尤其是当配置一个以上硬件/软件环境的时候，比如：操作系统版本、编译器、浏览器等等。

7.1.1.5.             静态测试的工具支持（K1）

静态测试工具提供了一种在开发过程的早期发现尽可能多的缺陷的高性价比的方法。

评审工具

这类工具可支持评审过程、检查表、评审指导方针，并且能用于存储和交流评审意见、以及缺陷和工作量报告。还能进一步为庞大的或分布于不同地区的团队提供在线评审。

静态分析工具（D）

这类工具通过提供对标准编码规范（包括安全编码）、结构和其相关性分析的支持，从而帮助开发和测试员在动态测试之前就找到缺陷。也可以对代码进行度量（例如：复杂性），在计划或风险分析方面有所帮助。

建模工具（D）

建模工具可以用来确认软件模型（例如：关系型数据库的物理数据模型），可以列举其不一致性并发现缺陷。他们通常也用于生成一些基于模型的测试用例。

7.1.1.6.             测试规格说明的工具支持（K1）

测试设计工具

测试设计工具能够根据需求、图形用户界面（GUI）、设计模型（状态、数据或对象）或代码生成测试输入或可执行的测试和/或测试准则。

测试数据准备工具

测试数据准备工具用来处理数据库、文件或数据传输，并且生成可以在测试执行过程中使用的测试数据，并通过数据匿名来确保安全性。

7.1.1.7.             测试执行和记录工具（K1）

测试执行工具

测试执行工具存储了输入和预期结果并通过脚本语言使测试能够自动或半自动进行并记录每一轮测试。它也可用于录制测试，并支持基于脚本语言或图形用户界面数据的参数化配置和其他自定义设置。

测试用具/单元测试框架工具（D）

单元测试用具或测试框架，通过使用像桩或者驱动这类能够模拟测试对象的装置来模拟将要运行的环境，使组件或子系统的测试变得更容易。

测试比较器

测试比较器能够确定文件、数据库或测试结果之间的差异。测试执行工具通常包括动态比较器，但执行后的比较也许会由一个分离的独立比较工具完成。一个测试比较器可能会使用测试准则，尤其是自动化进行的时候。

覆盖率测量工具（D）

这类工具可以使用植入式或非植入式的方法，通过一组测试来测量已运行的代码中特定代码结构类型（比如语句、分支或判定、以及模块或函数调用）的百分比。

安全性测试工具

这类工具用于评估软件的安全特性，包括评估软件保护数据机密性、完整性、身份验证、权限、可用性和不可否认性的能力。安全性工具通常关注在某一特定的技术、平台和目的。

7.1.1.8.             性能和监控工具（K1）

动态分析工具（D）

动态分析工具能发现那些只有在软件执行过程中才显现的缺陷，比如与时间依赖有关的问题，或内存泄漏等。它们通常应用在组件和组件集成测试以及中间件的测试。

性能测试/负载测试/压力测试工具

性能测试工具监控和报告系统在模拟大量并发用户使用系统时的性能表现、持续增加的模型、处理各业务的频率和相应的处理百分比。系统的负载只是创造了虚拟用户，用来执行一个所选的业务，这些虚拟用户分布在不同的测试机上，通常理解为负载生成器。

监控工具

监控工具持续地分析、验证和报告特定系统资源的使用情况，对可能存在的服务问题提出警告。

7.1.1.9.             特定应用领域的测试工具（K1）

数据质量评估

数据是有些项目的核心内容，例如：数据转换/数据迁移项目和应用，像数据仓库，它们会在不同临界和容量时表现出不同的特性。在这种情况下，需要使用工具评估数据质量，来评审和验证数据转换和迁移规则，以确保处理的数据是正确的、完整的并遵循一个预定义的、符合特定背景的标准。

还存在一些针对可用性测试的工具。

7.1.2.       有效使用工具：潜在的收益与风险（K2）20分钟

7.1.2.1.             术语

数据驱动测试（data-driventesting）、关键字驱动测试（keyword-driventesting）、脚本语言（scriptinglanguage）。

7.1.2.2.             测试工具的潜在收益和风险（针对所有工具）（K2）

仅仅购买或租用工具并不能保证成功使用工具。任何类型的工具都需要额外努力才能获得真正且持续的成效。工具的支持能给测试带来巨大的潜在（可能）收益和新的机会，但是必须考虑到，工具的使用同样存在风险。

使用工具的潜在收益包括：

减少重复性的工作（比如，执行回归测试，重新输入相同测试数据，代码规则检查）；

更好的一致性和可重复性（比如，用工具按照相同的顺序和频率执行测试，从需求生成测试）；

客观的评估（比如，静态测量、覆盖率）；

容易得到测试和测试的相关信息（比如，关于测试进展的统计和图表，事件发生率和性能）。

使用工具存在的风险：

对工具抱有不切实际的期望（包括功能性和易用性）；

低估首次引入工具所需的时间、成本和工作量（包括培训和额外的专业知识）；

低估从工具中获得较大和持续性收益需要付出的时间和工作量（包括使用工具的方式需要更改测试过程，并不断改进）；

低估了对工具生成的结果进行维护所需的工作量；

对工具过分依赖（替代测试设计或者对一些更适合手工测试的方面却使用自动测试工具）；

忽视了在工具中对测试对象的版本控制；

忽视了多个重要工具之间的关联和互操作性，例如：需求管理工具、版本控制工具、事件管理工具、缺陷跟踪工具和其他从不同供应商获得的工具；

工具供应商破产、停止维护工具或将工具卖给其他供应商的风险；

供应商对工具的支持、升级和缺陷修复反应不力；

开源/免费工具项目中止的风险；

其他不可预知的风险，例如不能支持新平台。

7.1.2.3.             一些工具类型的特殊考虑（K1）

测试执行工具

测试执行工具使用自动化的测试脚本执行测试对象。为了获得可观收益，经常需要为这类工具投入很多工作量。

通过记录测试员手动操作的捕捉过程往往开始看起来似乎很吸引人，但是这种方法不适合大量的自动化测试。捕获的脚本只是用特定数据和动作来线性表示每个脚本的一部分。当发生意外事件时，这类脚本是不稳定的。

数据驱动的方法是将测试输入（数据）与测试用例分离，并将测试输入存放在一个电子表格中，这样可以使用不同的数据进行相同的测试。不熟悉脚本语言的测试员可以从一个表格内输入测试数据并执行事先定义好的测试脚本。

在数据驱动技术中可以使用一些其它的技术，用一个表格内的元素组合来替代硬编码数据，使用基于可配置参数的算法在运行时生成并提供应用数据。例如，工具可以通过算法生成一个随机的用户ID，并按可重复的模式，用随机数种子可以控制随机模型。

在关键字驱动的测试方法中，电子表格含有描述系统要采取的行为的关键字（也称为行为字）和测试数据。测试员（即使不熟悉脚本语言）也能针对被测应用，使用这些关键字来定义测试。

所有的测试方法都需要脚本语言方面的技术专家（或测试员或测试自动化专家）。

无论使用什么脚本技术，都需要储存每次测试的预期结果，便于后续比较。

静态分析工具

静态分析工具检查源代码是否遵循编码标准，但是如果应用于已经存在的代码会产生大量警告信息。警告信息不阻碍代码转换成可执行程序，但理想情况是应予以处理，以便将来更容易进行代码的维护。在开始就有计划的逐步使用分析工具来过滤一些警告信息是一种有效的方法。

测试管理工具

测试管理工具需要有与其他工具和表格有接口，以便产生符合组织所需格式的有用信息。

7.1.2.4.             组织内引入工具（K1）15分钟

术语

无

背景

为组织选择工具所需要考虑的关键点有：

评估组织的成熟度、分析引入工具的优点和缺点和认识引入工具能改善测试过程的可能性；

根据清晰的需求和客观的准则进行评估；

概念验证，在评估阶段要确认在现有的情况下使用工具对被测软件是否有足够效果，或为了有效使用工具，目前的基础设施需要如何改变；

评估供应商（包括培训、提供的支持及其他商业方面考量），如果是非商业性工具要评估提供服务的供应商；

为了在工具使用方面得到更好的指导和培训，需要先收集内部需求；

评估培训需求时需要考虑现有测试团队的自动化测试技能；

根据实际的情况估算成本-收益比。

将选择的工具引入组织要从一个试点项目开始，试点项目有以下目的：

对工具有更多的认识；

评估工具与现有的过程以及实践的配合程度，确定哪些方面需要作修改；

定义一套标准的方法来使用、管理、储存和维护工具及测试资产（比如，定义文件和测试的命名规则、创建库和定义模块化测试套件）；

评估在付出合理的成本后能否得到预期的收益。

在组织内成功部署工具的因素包括：

逐步在组织的其余部分将工具推广到测试中；

调整并改进过程来配合工具的使用；

为新使用者提供培训和指导；

定义使用指南；

实施一种在实际运用中收集工具使用情况的方法；

监控工具的使用和收益情况；

为测试团队使用工具提供支持；

在所有团队内收集经验和教训。

参考文献：6.2.2Buwalda, 2001, Fewster, 1999，6.3Fewster, 1999