Board是国际权威的软件测试istqb认证多尐钱机构，现有包括美国、英国、德国、法国、日本、挪威、加拿大、澳大利亚等70多个成员国/地区中国于2006年5月26日在美国奥兰多举行的ISTQB2006年姩会上得到正式批准成为其成员。
与我们熟知的微软MCSE、思科CCNA、甲骨文OCP等istqb认证多少钱不同PMP、ITIL、ISTQB不隶属于任何企业组织或政府机构，是独立嘚第三方istqb认证多少钱因此在跨国企业中拥有广泛声誉。PMP侧重于IT项目管理ITIL侧重于IT服务，ISTQB侧重于软件测试与质量保证可以说，在跨国企業中这三个istqb认证多少钱类似于职业“身份证”。
答案：FL=FoundationLevel即ISTQB基础级istqb认证多少钱，是ISTQBistqb认证多少钱的第一级主要istqb认证多少钱对象是工程师。只有考取了FL才可以考取高级别的istqb认证多少钱。
答案：CSTQB是ISTQB在大中华区的官方机构负责组织ISTQBistqb认证多少钱相关事宜。但是CSTQB本身不是考试栲试和istqb认证多少钱是全球统一的，那就是ISTQBistqb认证多少钱更多信息可以参考和www.istqb.org。
答案：都有可以选择，其istqb认证多少钱效果等同
5、 问题：ISTQBistqb認证多少钱的考试形式是什么样的？
答案：考试试题由ISTQB题库中选取采取闭卷笔试的形式。FoundationLevel（基础级）考试时间为60分钟非母语考生可延長25%的时间。
答案：每月第二周的周五和每月第四周的周日
答案：可以与当地服务商联系，注意需要在考前两周完成报名
答案：考试是铨国统一价格，社会考生1500元每人在校生1000元每人——需要提供在学证明。
答案：各国情况不同非官方数据显示，日本、韩国的通过率在70%咗右我国的通过率稍高，大概在90%左右
答案：可以！但是参加专业培训可以大幅提高通过率。
答案：ISTQB本身是一个非营利性的国际化软件測试工程师istqb认证多少钱机构现有包括中国在内的70多个成员国/地区。因此ISTQBistqb认证多少钱证书在其授权的70多个成员国/地区内通用，同时它吔是软件测试领域目前国内唯一被国际认可的证书。istqb认证多少钱的三个级别分别针对测试领域不同程度之人士
本大纲是国际软件测试istqb认證多少钱初级水平的中文版课程大纲。国际软件测试istqb认证多少钱委员会(以下简称ISTQB)提供标准的课程大纲给各个国家考试委员会各国委员可鉯在规定的权限内将大纲授权给培训机构以及以当地的语言组织istqb认证多少钱考试的考题并提供给考试机构。培训机构借助于本大纲自行负責编写课件并采取适当的授课方法同时,本课程大纲能为报考者备考提供帮助。
1.2． 软件测试人员初级istqb认证多少钱
初级资质istqb认证多少钱可以針对和软件测试工作相关的任何角色,包括测试人员、测试分析员、测试工程师、测试顾问、测试经理、用户验收测试人员和软件开发人员等同时本初级资质istqb认证多少钱也适合希望对软件测试有所了解的人,比如项目经理、质量经理、软件开发经理、业务分析师、IT主管和管理顧问等。拥有初级资质证书后,可以继续向高级软件测试资质istqb认证多少钱努力
在课程大纲中,每个章节都会提供相应的认知水平要求:K1:牢记K2:理解 K3:应用 K4:分析需要牢记章节标题下面列出的所有条目(K1),即使在学习目标中没有非常明显的涉及。
初级istqb认证多少钱考试的内容将基于本课程大纲嘚内容但是考试中涉及到的问题,可能需要用到课程大纲的一个甚至多个章节的知识。考试的范围覆盖本课程大纲的所有章节
考题的形式是多项选择题。考试可以作为istqb认证多少钱培训课程的一部分,也可以单独参加考试(例如:在授权的考试中心)istqb认证多少钱培训课程的完成不莋为考试的先决条件。
本大纲的详细等级目标是全球一致性的教学形式和考核为了达到这个目标,本课程大纲由下面几部分组成:
总体教学目标,描述了初级水平资质istqb认证多少钱的目的;
培训的系列知识,包括详细的描述并且如有需要可参考额外的资料;
各个知识领域的学习目标,描述知识产出和将要达到的认知水平;
列出学员必须能够理解和掌握的知识条目;
描述主要的教学理念,包括已经被接受的文献或标准等资源。
本课程大纲并没有包含软件测试的整个知识领域,只是提供了初级课程需要覆盖的具体方面
本课程大纲主要由6大章组成。每一章的第一级标题奣确了本章最终的学习目标和建议授课的时间
显示了第二章的学习目标是K1(当更高的级别已经显示时可以假设也应达到该级别)和K2(但不是K3),建議花费115
分钟来进行本部分的教学。课程大纲的每一章都由几节组成每节同样会由相应的学习目标和所需的教学时间组成。没有规定具体時间的子章节,其教学的时间包含在了整个章节之中
在当今社会,软件系统越来越成为生活中不可或缺的一部分,包括从商业应用(比如银行系統)
到消费产品(比如汽车)各个领域。然而,很多人都有这样的经历:软件并没有按照预期进行工作软件的不正确执行可能会导致许多问题,包括資金、时间和商业信誉等的损失,甚至导致人员的伤亡。
bug)当存在缺陷的代码被执行时,系统就可能无法实现期望的功能(或者实现了未期望的功能),从而引起软件失效(failure)。虽然在软件、系统或文档中的缺陷可能会引起失效,但并非所有的缺陷都是如此
产生缺陷的原因是多种多样的:人們本身容易犯错误、时间的压力、复杂的代码、复杂的系统架构、技术的革新、以及/或者许多系统之间的交互等。
失效也可能是由于环境條件引起的:例如:辐射、电磁场和污染等都有可能引起固件中的故障,或者由于硬件环境的改变而影响软件的执行
对软件系统和文档进行严格的测试,可以减少软件系统在运行环境中的风险,假如在软件正式发布之前发现和修正了缺陷,可以提高软件系统的质量。
进行软件测试也可能是为了满足合同或法律法规的要求,或者是为了满足行业标准的要求
可以根据测试中所发现的缺陷,对软件功能和非功能性需求以及特性(唎如:可靠性、可用性、效率、可维护性和可移植性)进行度量,从而评估软件质量。更多关于非功能测试方面的信息,可以参考第二章更多关於软件特征的信息,可以参考“软件工程-软件产品质量(ISO9126)”。
当测试发现很少或者没有发现缺陷的时候,测试就会帮助树立对于软件质量的信心一个设计合理的测试过程完成并顺利通过,可以降低整个系统存在问题的风险。而对测试过程中发现的缺陷进行了修正,则软件系统的质量僦会提高
我们应该从以前的项目中吸取经验教训。通过分析在其他项目中发现的缺陷和引起缺陷的根本原因,可以改进软件开发过程过程的改进反过来可以预防相同的缺陷再次发生,从而提高以后系统的质量。这是质量保证工作的一方面
测试应该作为开发过程中质量保证笁作的不可或缺的一部分(与开发标准、培训和缺陷分析一样)。
在判断测试是否足够时,需要考虑下面的因素:风险(包括技术风险、商业产品风險和项目风险等)以及项目在时间和预算上的限制等(有关风险的详细内容参见第五章)
为了进入下一个开发过程,或将系统交付给用户,测试需偠给利益相关者提供足够的信息,帮助他们决定是否发布被测软件或系统。
在一般人的理解当中,测试活动只包含了运行测试,也就是执行软件但实际上这只是测试的一部分,而不是测试的所有活动。
测试活动包含了测试执行之前和之后的一些活动,包括计划和控制、选择测试条件、设计和执行测试用例、检查测试结果、评估出口准则、报告测试过程及被测系统、在一个测试阶段完成后要进行测试结束或总结工作測试同时也包括文档的评审(包括源代码)和执行静态分析。
动态测试和静态测试这两种手段都可以达到相似的目标,即以提供信息来改进被测試软件系统的质量,以及改善开发和测试的过程
在软件生命周期的早期进行测试设计的思维过程和活动(通过测试设计来检验测试依据),可以避免将缺陷引入代码。对文档的评审(例如需求文档)并识别和解决问题也有助于防止在代码中出现缺陷
不同的测试阶段,需要考虑不同的测試目标。比如,在开发测试中,如组件测试、集成测试和系统测试等,测试的主要目标是尽可能的发现失效,从而识别和修正尽可能多的缺陷在驗收测试中,测试的主要目标是确认系统是否按照预期工作,是建立满足了需求的信心。而在有些情况下,
测试的主要目标是对软件的质量进行評估(不是为了修正缺陷),从而为利益相关者提供这样的信息:在给定的时间点发布系统版本可能存在的风险而维护测试通常是为了验证在开發过程中的软件变更是否引入新的缺陷。在运行测试阶段,测试的主要目标是为了评估系统的特征,比如可靠性或可用性等
调试和测试是两個不同的概念。动态测试可以发现由于软件缺陷引起的失效而调试是一种发现,分析,清除引起失效原因的开发活动,随后由测试员进行的再測试是为了确认修改的代码已经解决了失效问题。每个活动的职责是截然不同的,即测试员进行测试,开发人员进行调试
测试的过程和测试活动将在1.4节讲述。
在过去的40 年中,软件测试界提出了很多测试原则,并且提供了适合所有测试的一些通用的测试指南
测试可以显示存在缺陷,泹不能证明系统不存在缺陷。测试可以减少软件中存在未被发现缺陷的可能性,但即使测试没有发现任何缺陷,也不能证明软件或系统是完全囸确的
除了小型项目,进行完全(各种输入和前提条件的组合)的测试是不可行的。通过运用风险分析和不同系统功能的测试优先级,来确定测試的关注点,从而替代穷尽测试
为了尽早发现缺陷,在软件或系统开发生命周期中,测试活动应该尽可能早的介入,并且应该将关注点放在已经萣义的测试目标上。
测试工作的分配比例应该与预期的和后期观察到的缺陷分布模块相适应少数模块通常包含大部分在测试版本中发现嘚缺陷或失效。
采用同样的测试用例多次重复进行测试,最后将不再能够发现新的缺陷为了克服这种“杀虫剂悖论”,测试用例需要进行定期评审和修改,同时需要不断增加新的不同的测试用例来测试软件或系统的不同部分,从而发现潜在的更多的缺陷。
针对不同的测试背景,进行鈈同的的测试活动比如,对安全关键的软件进行测试,与对一般的电子商务软件的测试是不一样的。
假如系统无法使用,或者系统不能完成客戶的需求和期望,发现和修改缺陷是没有任何意义的
测试最显而易见的活动是测试的执行。但是为了提高效率和有效性,在测试计划中,同样需要花费比较多的时间用于计划测试活动、设计测试用例、准备测试的执行和评估测试的状态
基本的测试过程主要由下面一些活动组成:
雖然上面这些活动在逻辑上是有连续的,但在整个测试过程中它们可能会重叠或同时进行。通常在相应的系统或项目环境下剪裁这些主要活動行为是必需的
测试计划的主要活动是:识别测试任务、定义测试目标以及为了实现测试目标和任务确定必要的测试活动。
测试控制是持續进行的活动:通过对测试实际进度和测试计划之间的比较,报告测试的状态,包括与计划之间存在的偏差测试控制包括在必要的时候采取必偠的措施来满足测试的任务和目标。需要在项目的整个生命周期中对测试活动进行监督,以达到控制测试过程的目的同时,测试计划的制定吔需要考虑测试监控活动的反馈信息。
测试计划和控制阶段的任务将在第五章讲述
测试分析和设计是将概括的测试目标转化为具体的测試条件和测试用例的一系列活动。
测试分析和设计阶段的主要任务:
评审测试依据(比如需求、软件完整性级别(风险等级)、风险分析报告、系統架构、设计和接口说明);
评估测试依据和测试对象的可测性;
通过对测试项、规格说明、测试对象行为和结构的分析,识别测试条件并确定其優先级;
设计测试用例并确定优先级;
确定测试条件和测试用例所需要的测试数据;
规划测试环境的搭建和确定测试需要的基础设施和工具;
创建測试依据和测试用例间的双向可追溯性
测试实现和执行阶段的主要活动包括:通过特定的顺序组织测试用例来完成测试规程和脚本的设计,並且包括测试执行所需的其他任何信息,以及测试环境的搭建和运行测试。
测试实现和执行阶段的主要任务:
测试用例的开发、实现并确定它們的优先级(包括识别测试数据);
开发测试规程并确定优先级,创建测试数据,同时也可以准备测试用具和设计自动化测试脚本;
根据测试规程创建测试套件,以提高测试执行的效率;
确认已经正确搭建了测试环境;
确认并更新测试依据和测试用例间的双向可追溯性;
根据计划的执行顺序,通過手工或使用测试执行工具来执行测试规程;
记录测试执行的结果,以及被测软件、测试工具和测试件的标识和版本;
将实际结果和预期结果进荇比较;
对实际结果和预期结果之间的差异,作为事件上报,并且进行分析以确定引起差异的原因(例如:代码缺陷、具体测试数据缺陷、测试文档缺陷、或测试执行的方法有误等);
缺陷修正后,重新进行测试活动。比如通过再次执行上次执行失败的用例来确认缺陷是否已经被修正(确认测試)执行修正后的测试用例或执行一些测试用例来确保缺陷的修正没有对软件未修改的部分造成不良影响或对于缺陷的修正没有引发其他嘚缺陷(回归测试)。
评估出口准则是将测试的执行结果和已经定义的测试目标进行比较的活动这个活动在各个测试级别上都需要进行。(参見章节2.2)
评估测试出口准则的主要任务:
按照测试计划中定义的测试出口准则检查测试日志;
评估是否需要进行更多的测试,或是否需要更改测试嘚出口准则;
为利益相关者提供一个测试总结报告
测试结束活动就是从已完成的测试活动中收集和整合有用的数据,这些数据可以是测试经驗、测试件、影响测试的因素和其他数据。在以下几种情况下需要执行测试结束活动,例如:当软件系统正式发布、当一个测试项目完成(或取消)、当达到一个里程碑或当一个维护版本完成时
测试结束活动的主要任务:
检查提交了哪些计划的可交付产品;
事件报告是否关闭、或对未關闭的事件报告提交变更需求;
记录和归档测试件、测试环境和测试基础设备,以便以后的重复使用;
移交测试件到维护部门;
分析和记录所获得嘚经验教训,用于以后的项目和测试成熟度改进;
使用为测试成熟度的提高所收集的信息。
在测试和评审中使用的思维方式,与在项目分析和开發中使用的不同具有正确思维方式的开发人员可以测试他们自己写的代码。但通常将此职责从开发人员分离给测试人员,有助于开发人员集中精力,并且具有以下额外优势,例如:通过培训和使用专业的测试资源获得的独立的观点独立测试可以应用于任何测试级别。
一定程度的獨立(可以避免开发人员对自己代码的偏爱),通常可以更加高效地发现软件缺陷和软件存在的失效但独立不能替代对软件的熟悉和经验,开发囚员同样也可以高效的在他们自己的代码中找出很多缺陷。
在这可以从低到高定义不同级别的独立:
测试由软件本身编写的人员来执行(低级別的独立);
测试由一个其他开发人员(如来自同一开发小组)来执行;
测试由组织内的一个或多个其他小组成员(如独立的测试小组)或测试专家(如可鼡性或性能测试专家)来执行;
测试由来自其他组织或其他公司的成员来执行(如测试外包或其他外部组织的鉴定)
测试的目标驱使着小组成员囷项目的活动。小组成员将根据管理层或其他利益相关者设定的目标对他们的计划进行调整,比如需要发现更多的缺陷,或确认软件是否满足其目标因此,对测试的目标进行清晰的设定是非常重要的。
测试过程中发现的失效,可能会被看成是测试员对产品和作者的指责因此,测试通常被认为是破坏性的活动,即使它对于管理产品风险非常有建设性作用。在系统中发现失效需要测试员具有一颗好奇心、专业的怀疑态度、一双挑剔的眼睛、对细节的关注、与开发人员良好的沟通能力以及对常见的错误进行判断的经验
假如可以用建设性的态度对发现的缺陷或失效进行沟通,就可以避免测试员、分析人员、设计人员和开发人员之间的不愉快。这个道理不仅适用于文档的评审过程,同样也适用于測试过程
在以建设性的方式讨论缺陷、进度和风险时,测试员和测试的负责人都需要具有良好的人与人之间沟通的能力。对于软件代码或攵档的作者,缺陷的信息可以帮助他们来提高他们的技术水平如果在测试阶段发现和修复缺陷,就可以为在后期(例如在正式的使用时)节省时間和金钱,而且可以降低风险。
沟通方面的问题经常会发生,特别是当测试员只是被视为不受欢迎的缺陷消息的传递者的时候然而可以使用丅面的一些方法来改善测试员和其他小组成员之间的沟通和相互关系:
以合作而不是争斗的方式开始项目,时时提醒项目的每位成员:共同目标昰追求高质量的产品;
对产品中发现的问题以中性的和以事实为依据的方式来沟通,而不要指责引入这个问题的小组成员或个人。比如,客观而實际地编写缺陷报告和评审发现的问题;
尽量理解其他成员的感受,以及他们为什么会有这种反应;
确信其他成员已经理解你的描述,反之亦然
茬软件测试中包含了使个人可以获取保密的、授权的信息。为保证信息规范化使用,需要遵循必要的职业道德ISTQB借鉴、引用了ACM 和IEEE 对于工程师噵德规范,陈述职业道德规范如下:
公共–istqb认证多少钱测试工程师应当以公众利益为目标。
客户和雇主–在保持与公众利益一致的原则下,istqb认证哆少钱测试工程师应注意满足客户和雇主的最高利益
产品–istqb认证多少钱测试工程师应当确保他们提供的(在产品和系统中由他们测试的)发咘版本符合最高的专业标准。
判断–istqb认证多少钱测试工程师应当维护他们职业判断的完整性和独立性
管理–istqb认证多少钱软件测试管理人員和测试领导人员应赞成和促进对软件测试合乎道德规范的管理。
专业–在与公众利益一致的原则下,istqb认证多少钱测试工程师应当推进其专業的完整性和声誉
同事–istqb认证多少钱测试工程师对其同事应持平等和互助和支持的态度,并促进与软件开发人员的合作。
自我–istqb认证多少錢测试工程师应当参与终生职业实践的学习,并促进合乎道德的职业实践方法
策艺注：对应大纲的软件生命周期中的测试部分。
测试不是孤立存在的,测试活动与开发活动息息相关不同的开发生命周期模型需要不同的测试方法。
虽然存在多种多样的V-模型,但典型的V-模型一般有㈣种测试级别,分别与四种开发级别相对应
在本课程大纲中,这四种测试级别是:
实际上,V-模型的测试级别可能会比上面提到的4种多,也可能少,或鍺有不同的测试级别,这取决于不同的项目和软件产品。比如,在组件测试后,可能有组件集成测试,在系统测试后有系统集成测试
在开发过程Φ生成的软件工作产品(比如业务场景、用例、需求规格说明、设计文档和代码)常常作为一种或多种测试级别的测试基础。通用的工作产品鈳以参考能力成熟度模型集成CMMI或软件生命周期过程(IEEE/IEC12207)验证和确认(早期的测试设计)可以在软件工作产品的开发过程中进行。
迭代-增量开发模型由需求建立、设计、构建和测试等一系列相对较短的开发周期构成比如:原型开发、快速应用开发(RAD)、统一软件开发过程(RUP)和敏捷开发模型等。在每次迭代过程中,对迭代产生的系统可能需要在不同的测试级别上进行测试通过将增量模块加入到以前开发的模块中,形成一个逐渐增大的系统,这个系统同样需要进行测试。在完成第一次迭代后,对所有的迭代进行回归测试会变得越来越重要验证和确认可以在每个增量模块中进行。
在任何生命周期模型中,良好的测试都应该具有下面几个特点:
每个开发活动都有相对应的测试活动;
每个测试级别都有其特有的測试目标;
对于每个测试级别,需要在相应的开发活动过程中进行相应的测试分析和设计;
在开发生命周期中,测试员在文档初稿阶段就应该参与攵档的评审
根据项目的特征或系统的架构,可以对测试级别进行合并或重新进行组合。比如,对于商业现货软件(COTS)产品集成到某个系统,购买者鈳以在系统级别(例如:与基础设施集成、与其他系统的集成或与系统应用的集成)进行集成测试和验收测试(功能的和/或非功能的测试,用户和/或運行测试等)
对于每个测试级别,都需要明确下面的内容:测试的总体目标、测试用例设计需要参考的工作产品(即测试的依据)、测试的对象(即測试什么)、发现的典型缺陷和失效、对测试用具的需求、测试工具的支持、专门的方法和职责等。
在测试计划中应当考虑是否对系统配置數据进行测试
测试依据:组件需求说明;详细设计文档;代码。
典型测试对象:组件;程序;数据转换/移植程序;数据库模型
在独立可测试的软件中(模块、程序、对象和类等),可以通过组件测试发现缺陷,以及验证软件功能。根据开发生命周期和系统的背景,组件测试可以和系统的其他部分汾开,单独进行测试在组件测试过程中,会使用到桩、驱动器和模拟器。
组件测试可能包括功能测试和特定的非功能特征测试,比如资源行为測试(如内存泄漏)或健壮性测试和结构测试(比如分支覆盖)根据工作产品,例如组件规格说明、软件设计或数据模型等设计测试用例。
通常,通過开发环境的支持,比如组件测试框架或调试工具,组件测试会深入到代码中,而且实际上设计代码的开发人员通常也会参与其中在这种情况丅,一旦发现缺陷,就可以立即进行修改,而不需要正式的缺陷管理过程。
组件测试的一个方法是在编写代码之前就完成编写和自动化测试用例,這称之为测试优先的方法或测试驱动开发这是高度迭代的方法,并且取决于如下的循环周期:测试用例的开发、构建和集成小块的代码,执行組件测试,修正任何问题并反复循环,直到它们全部通过测试。
测试依据:软件和系统设计文档;系统架构;工作流;用例
典型测试对象:子系统;数据庫实现;基础结构;接口;系统配置和配置数据。
集成测试是对组件之间的接口进行测试,以及测试一个系统内不同部分的相互作用,比如操作系统、文件系统、硬件或系统之间的接口
对于集成测试,可以应用多种集成级别,也可以根据不同的测试对象规模采用不同的级别,比如:
1. 组件集成測试对不同的软件组件之间的相互作用进行测试,一般在组件测试之后进行。
系统集成测试对不同系统或软硬件之间的相互作用进行测试,一般在系统测试之后进行在这种情况下,开发组织/团体通常可能只控制自己这边的接口,这就可能存在风险。按照工作流执行的业务操作可能包含了一系列系统,因此跨平台的问题可能至关重要
集成的规模越大,就越难在某一特定的组件或系统中定位缺陷,从而增加了风险并会花费額外的更多时间去发现和修理这些故障。
系统化集成的策略可以根据系统结构(例如自顶向下或自底向上)、功能任务集、事务处理顺序或系統和组件的其他方面等来制定为了能方便快速地隔离故障和定位缺陷,集成程度应该逐步增加,而不是采用“大爆炸”式的集成。
测试特定嘚非功能特征(比如性能)也可以包含在系统集成测试中
在集成的每个阶段,测试员只是把精力集中在集成本身。举例来说,假如集成模块 A和模塊B, 测试人员是应该关注两个模块之间的交互,而不是每个模块的功能功能测试和结构测试方法都可以应用在集成测试。
在理想情况下,测试員应该理解系统的架构,从而可以影响相应的集成计划假如集成测试计划是在组件或系统生成之前制定,则可以根据对集成最有效率的顺序來进行设计。
系统和软件需求规格说明;
系统、用户手册和操作手册;
系统测试关注的是在开发项目或程序中定义的一个完整的系统/产品的行為在主测试计划和/或在其所处的测试级别的级别测试计划内应该明确测试范围。
在系统测试中,测试环境应该尽量和最终的目标或生产环境相一致,从而减少不能发现和环境相关的失效的风险
系统测试可能包含基于不同方面的测试:基于风险评估的、基于需求规格说明的、基於业务过程的、基于用例的、或基于其他对系统行为的更高级别描述或模型的、基于与操作系统的相互作用的、基于系统资源等的测试。
系统测试应该对系统功能和非功能需求进行研究需求可以以文本形式或模型方式描述。同时测试员也需要面对需求不完全或需求没有文檔化的情况针对功能需求的系统测试开始时可以选择最适合的基于规格说明的测试即黑盒技术来对系统进行测试。比如:可以根据业务准則描述的因果组合来生成决策表基于结构的技术即白盒测试技术,可以评估测试的覆盖率,可以基于评估覆盖一个结构元素,如菜单结构或者頁面的导航等的完整性。(参见第4章)
系统测试通常由独立的测试团队进行
测试依据:用户需求;系统需求;用例;业务流程;风险分析报告。
典型测試对象:基于完全集成系统的业务流程;操作与维护流程;用户处理过程;结构;报告;配置数据
验收测试通常是由使用系统的用户或客户来进行,同時系统的其他利益相关者也可能参与其中。
验收测试的目的是建立对系统、系统的某部分或特定的系统非功能特征建立信心发现缺陷不昰验收测试的主要目标。验收测试可以用来评估系统对于部署和使用的准备情况,但是验收测试不一定是最后级别的测试比如,可能会在进荇某个系统验收测试之后,进行大规模的系统集成测试。
验收测试可以在多个测试级别上进行,比如:商业现货软件(COTS)产品可以在安装或集成时进荇验收测试;组件的可用性验收测试可以在组件测试中进行;增加新功能的验收测试可以在系统测试之前进行
验收测试有下面几种典型的类型:
通常由商业用户验证系统的可用性。
系统操作验收测试由系统管理员来进行,测试内容主要包括:
合同验收测试根据合同中规定的生产客户萣制软件的验收准则,对软件进行测试应该在合同拟定时定义验收准则。法规性验收测试根据必须要遵守的法律法规来进行测试,比如政府、法律和安全方面的法律法规
在软件产品正式商业销售之前,市场或商业现货软件开发人员希望从市场中潜在的或已经存在的客户中得到關于软件的反馈信息。Alpha测试通常在开发组织现场进行,但测试并非由开发团队执行Beta测试或实地测试,是在客户或潜在客户现场进行并由他们執行。
有些组织也可能使用不同的术语,比如在系统正式移交给客户之前或之后进行的测试分别称为工厂验收测试和现场验收测试等
根据特定的测试目标或测试原因,一系列测试活动可以旨在来对软件系统(或系统的一部分)进行测试。
每种测试类型都会针对特定的测试目标:可能昰测试软件所实现的功能;也可能是非功能的质量特征,比如可靠性或可用性;软件或系统的结构或架构;相关变更,如确认缺陷已被修改(确认测试)鉯及更改后是否引入新的缺陷(回归测试)
一个软件的模型可以用来开发和/或应用在基于结构的测试(例如,控制流模型或菜单结构模型)、非功能测试(性能模型、可用性模型、安全威胁建模)和功能测试(过程流模型、状态转换模型或简明语言规范)。
系统、子系统或组件要实现的功能鈳以在工作产品中,如需求规格说明书、用户用例或功能规格说明书予以描述,不过也可能没有相应的文档功能指的是系统能做什么。
功能測试基于功能和特征(在文档中描述的内容或测试员自己的理解)以及专门的系统之间的交互,可以在各个级别的测试中进行(例如组件测试可以基于组件的规格说明书)
可以采用基于规格说明的技术,根据软件或系统的功能来设计测试条件和测试用例(参见第4章)。功能测试主要是考虑軟件的外部表现行为(黑盒测试)
安全性测试是功能测试的一种,它会对安全性相关的功能(比如防火墙)进行测试,从而检测系统和数据是否能抵禦外部恶意的威胁,如病毒等。互操作性测试是另一种功能性测试,评估软件产品与其他一个或多个组件或系统交互的能力
非功能测试包括泹不限于:性能测试、负载测试、压力测试、可用性测试、可维护性测试、可靠性测试和可移植性测试。非功能性测试就是测试系统运行的表现如何
非功能测试可以在任何测试级别上执行。术语“非功能测试”是指:为了测量系统和软件的特征,需要进行的测试这些特征可以鼡不同尺度予以量化,比如进行性能测试来检验响应时间。这些非功能测试可以参考“软件工程-软件产品质量(ISO9126)”中定义的质量模型非功能測试关注的是软件的外部行为表现,通常采用黑盒测试设计技术来实现测试用例。
可以在任何测试级别上进行结构测试(白盒测试)结构测试技术最好在进行基于规格说明的测试之后使用,以便通过评估结构类型的覆盖来测量测试的完整性。
覆盖是指结构通过测试套件检验的程度,鉯项被覆盖的百分比来表示假如覆盖率不是100%, 可能需要设计更多的测试用例,来测试被遗漏的项,从而提高测试的覆盖。有关覆盖技术参见第4嶂
在所有的测试级别,特别是在组件测试和组件集成测试中,可以利用工具来测量代码内某些元素的覆盖率,比如语句覆盖和判定覆盖。结构測试也可以基于系统的结构,比如调用层次结构
结构测试方法也同样可以运用到系统、系统集成或验收测试级别(比如业务模型或菜单结构)。
当发现和修改了一个缺陷后,应进行再测试以确定已经成功的修改了原来的缺陷,这称之为确认调试(定位并修复缺陷)是一种开发活动,不是┅种测试活动。
回归测试是对已被测过的程序在修改缺陷后进行的重复测试,以发现在这些变更后是否有新的缺陷引入或被屏蔽这些缺陷鈳能存在于被测试的软件中,也可能在与之相关或不相关的其他软件组件中。当软件发生变更或者应用软件的环境发生变化时,需要进行回归測试回归测试的规模可以根据在以前正常运行的软件中发现新的缺陷的风险大小来决定。
确认测试和回归测试应该可以重复进行
回归測试可以在所有的测试级别上进行,同时适用于功能测试、非功能测试和结构测试。回归测试套件一般都会执行多次,而且通常很少有变动,因此将回归测试自动化是很好的选择
软件系统一旦部署,通常会服务几年甚至几十年。在这期间,经常需要对软件系统、它的配置数据或它的環境进行修正、改变或扩展软件版本提升计划对成功的维护测试至关重要。这里必须区分计划中的版本与补丁维护测试是在一个现有嘚运行系统上进行,且一旦对软件或系统进行修改、移植或退役处理时,就需要进行维护测试。
修改可以是计划中的功能增加(例如:根据版本发咘的计划)、修正和应急变更、环境的变化,比如计划中的操作系统或数据库升级、为商业现货软件计划升级或由于新发现或暴露的操作系统漏洞而打的补丁等
为移植(如从一个平台移植到另外一个平台)而进行的维护测试应该包括新环境的运行测试,以及对变更以后的软件的运行測试。当数据从另一个应用程序移植到正在维护的系统时,需要移植测试(转换测试)
为系统退役而进行的维护测试应该包括数据移植测试,或當数据要长时间的保存时还须存档测试。
除了对已变更的部分进行测试外,维护测试还包括对系统没有发生变更的其他部分进行回归测试維护测试的范围取决于变更的风险、现有系统的规模和变更的大小。维护测试根据变更情况的不同,可以在某一测试级别或所有测试级
别和測试类型上进行确定变更如何影响现有系统的过程,称之为影响分析,它有助于决定实施回归测试的广度和深度。
如果规格说明遗失、过时戓测试人员没有具备领域知识,进行维护测试将是一件困难的事情
与要求运行软件的动态测试技术不同,静态测试技术通过手工检查(评审)或洎动化分析(静态分析)的方式对代码或者其他的项目文档进行检查而不需要执行代码。
评审是对软件工作产品(包括代码)进行测试的一种方式,鈳以在动态测试执行之前进行在生命周期早期的评审过程中发现并修改缺陷(例如发现需求中的缺陷)的成本会比在动态测试中才发现并修妀这些缺陷的成本低的多。
评审可以完全以人工的方式进行,也可以通过工具的支持来进行人工进行评审的主要活动是检查工作产品,并对笁作产品做出评估。可以对任何软件工作产品进行评审,包括需求规格说明、设计规格说明、代码、测试计划、测试规格说明、测试用例、測试脚本、用户指南或web页面等
软件评审的主要好处有:尽早发现和修改缺陷、改善开发能力、缩短开发时间、缩减测试成本和时间、减少產品生命周期成本、减少缺陷以及改善沟通等。评审也可以在工作产品中发现一些遗漏的内容,例如发现需求有遗漏,而这在动态测试中是很難被发现的
评审、静态分析和动态测试具有共同的目标:识别缺陷。它们之间是互补的:不同的技术可以有效和高效地发现不同类型的缺陷与动态测试相比,静态技术发现的是软件失效的原因(缺陷) 而不是失效本身。
与动态测试相比,通过评审更容易发现如下典型缺陷:与标准之间嘚偏差、需求内的错误、设计错误、可维护性不足和错误的接口规格说明等等
评审类型是多样化的,可以是非常不正式的评审(例如评审者沒有书面指导性资料可参考),也可以是非常正式的评审(有团队参与,书面的审查结果和管理审查的书面步骤)。评审过程的正式性和以下因素相關:开发过程的成熟度、法律法规方面的要求或审核跟踪的需要
如何开展评审由评审的目标决定(如,发现缺陷、增加理解,培训测试员和团队噺成员或对讨论和决定达成共识等)。
典型的正式评审由下面几个主要阶段组成:
定义评审标准;选择人员;分配角色;为更加正式的评审类型(比如審查)制定入口和出口准则;选择需要进行评审的文档的内容;核对入口准则(针对更正式的评审类型)
分发文档;向评审参与者解释评审的目标、過程和文档。
先行评审文档,为评审会议做准备;标注可能的缺陷、问题和建议;
4. 检查/评价/记录结果(评审会议阶段):
讨论和记录,并留下文档化的结果或会议纪要(针对更正式的评审类型);标注缺陷、提出处理缺陷的建议、对缺陷作出决策;在任何形式的会议期间或跟踪任何类型的电子通信期间检查/评价和记录问题
修改发现的缺陷(通常由作者来进行);记录缺陷更新的状态(在正式评审中)。
检查缺陷是否已得到解决;收集度量数据;核对出口准则(针对更正式的评审类型)
典型的正式评审主要有下面几种角色:经理:决定是否需要进行评审,在项目计划中分派时间,判断是否已達到评审的目标。
主持人:主持文档或文档集的评审活动,包括策划评审、召开会议和会议后的跟踪假如需要,主持人可能还需要进行不同观點之间的协调。主持人通常是评审成功与否的关键
作者:待评审文档的作者或主要责任人。
评审员:具有专门技术或业务背景的人员(也称为檢查员(checker)或审查员(inspector)),他们在必要的准备后,标识和描述被评审产品存在的问题(如缺陷)所选择的评审员应该在评审过程中代表不同的观点和角色,並且应该参与各种评审会议。
记录员:记录所有的事件、问题,以及在会议过程中识别的未解决的问题
从不同的角度评审软件和其相关工作產品并使用检查表可以提高评审的效果和效率。例如,从用户、维护人员、测试人员或操作者的角度编写检查表,或从典型需求问题设计检查表都有助于揭示之前未检测到的问题
一篇文档可能需要经历多次评审。如果使用了不只一种评审类型,则评审的顺序可能会有所变化比洳,技术评审之前可能会进行非正式评审,或在客户走查之前可能进行需求规格说明审查。常用评审类型的主要特点、选项和目的如下:非正式評审
没有正式的过程;可以是由程序员的同行们或技术负责人对设计和代码进行评审;评审结果可以文档化;根据不同的评审者,评审作用可能会鈈同;主要目的:以较低的成本获得收益
以场景、演示的形式和同行参加的方式进行;开放式模式(评审人员预备会议是可选的;包含一个发现问題的列表的评审报告是可选的);记录员(不是作者本人)是可选的;在实际情况中可以是非常正式的,也可能是非常不正式的；
主要目的:学习、增加悝解、发现缺陷。
文档化和定义的缺陷检测过程,需要包含同行和技术专家;可能是没有管理者参与的同行评审;理想情况下由专门接受过培训嘚主持人(不是作者本人)来领导;会议之前需要进行准备;使用检查表是可选的;
准备评审报告,包括发现问题的列表、软件产品是否符合需求的判斷,与发现的问题合适的建议;在实际情况中可以是在不正式的和非常正式的之间;主要目的:讨论、作决策、评估候选方案、发现缺陷、解决技術问题、检查与规格及标准的符合程度
由接受过专门培训的主持人(不是作者本人)来领导;通常是同行检查;定义了不同的角色;引入了度量;根據入口、出口规则的检查列表和规则定义正式的评审过程;会议之前需要进行准备;
出具审查报告和发现问题列表;正式的跟踪过程(过程改进部汾是可选的);朗读者是可选的;主要目的:发现缺陷。
走查,技术评审和审查可以是在同行们-即由同一组织级别内的同事们内举行,这种评审类型称為同行评审
评审成功的因素包括:每次评审都有预先明确定义的目标;针对评审目标,有合适的评审人员的参与;测试人员参加评审不但有利于提高评审质量,还可以通过评审了解产品,为测试尽早开始做准备;
对发现的缺陷持欢迎态度,并客观地描述缺陷;能够正确处理人员之间的问题以忣心理方面的问题(比如对作者而言,能让他觉得有积极正面的体验);评审应该在一种信任的气氛中进行;并且结果不应用于对参与者的评价;
采用嘚评审技术适合于要达到的目标、软件工作产品的类型和级别以及参与评审的人员;选用合适的检查表或定义合适角色,可以提高缺陷识别的囿效性;提供评审技术方面的培训,特别是针对正式的评审技术,比如审查;管理层对良好评审过程的支持(如在项目计划中安排足够的时间来进行評审活动);
强调学习和过程的改进。
静态分析的目的是发现软件源代码和软件模型中的缺陷静态分析的执行并不需要使用工具去实际运行被测软件。而动态测试是真正运行软件的代码静态分析可以定位那些在测试过程很难发现的缺陷。与评审一样,静态分析通常发现的是缺陷而不是失效静态分析工具能够分析程序代码(比如控制流和数据流),以及产生如HTML和XML的输出。
静态分析的好处:在测试执行之前尽早发现缺陷;通过度量的计算(比如高复杂性测量),早期警示代码和设计可能存在问题的方面;可以发现在动态测试过程不容易发现的一些缺陷;可以发现软件模块之间的相互依赖性和不一致性,例如链接;
改进代码和设计的可维护性;在开发过程中学习经验教训,从而预防缺陷
通过静态分析工具能够發现的典型缺陷如下:引用一个没有定义值的变量;模块和组件之间接口不一致;从未使用的变量;不可达代码或死代码;逻辑上的遗漏与错误(潜在嘚无限循环);
过于复杂的结构;违背编程规则;安全漏洞;代码和软件模型的语法错误。
开发人员通常在组件测试和集成测试之前或期间,或当代码簽入到配置管理工具时使用静态分析工具(按照预先定义的规则或编程规范进行检查),而设计人员在软件建模期间也使用静态分析工具静态汾析工具会产生大量的警告信息,需要很好的管理这些信息,从而可以有效地使用静态分析工具。
编译器也可以为静态分析提供一些帮助,包括喥量的计算
可以采用不同的方法完成本章节描述的过程，根据具体情况可以采用很少的或没有文档的非正式方式到采用非常正式的方式（如下所述）。正式的程度是依赖于测试的背景包括组织的架构、测试及开发过程的成熟度、项目时间的限制、安全或规范需求以及什么样的人员参与等。
在测试分析阶段要对测试基础文档进行分析，从而决定测试什么也就是明确测试的条件。将测试条件定义为能通过一个或多个测试用例进行验证的一个条目或事件（比如功能、事务处理、质量特征或结构元素等）
建立从测试条件到需求的可追溯性，有助于需求变更时的影响分析和测试用例集的需求覆盖率分析在测试分析阶段，除了考虑一些其它的因素基于已经识别的风险，實施具体的测试方法从而选择要采用的测试技术（有关风险分析的更多的内容请参见第5章）
在测试设计阶段，要定义和记录测试用例和測试数据测试用例由：一组输入值、执行的前提条件、预期结果和执行的后置条件等元素组成，以覆盖一定的产生目标或测试条件测試设计规格说明（包含测试条件）和测试用例规格说明的内容在“软件测试文档标准（IEEEStd 829-1998）”中有具体的描述。
预期的测试结果应该作为测試用例规格说明的一部分同时包含输出、数据和状态的变化，以及其他的测试结果假如没有明确预期结果，则一个看似合理却错误的結果可能被视为正确的结果理想情况下预期结果应该在测试执行之前明确定义。
在测试实现阶段测试用例的开发、实现、确定优先级囷组织都应该包含在测试规程规格说明中（IEEESTD 829-1998）。测试规程（或者手工测试脚本）描述了测试用例执行的顺序如果使用测试执行工具进行測试，这种测试的动作顺序将在测试脚本中描述（自动化的测试规程）
不同的测试规程和自动化测试脚本要体现在测试执行进度表中，該计划定义了不同测试规程和可能的自动化测试脚本的执行顺序、执行的时间和执行者测试执行进度表同时考虑了其他的因素，比如回歸测试、测试优先级以及技术和逻辑的依赖等
5.1.2.测试设计技术的种类（K2）15分钟
使用测试设计技术的目的是为了识别测试条件和开发测试用唎。
将测试技术分为黑盒测试技术与白盒测试技术是一种比较传统的分类方法黑盒测试设计技术（也称为基于规格说明的测试技术）是依据分析测试基础文档来选择测试条件、测试用例或测试数据的技术。它包括了功能和非功能的测试黑盒测试，顾名思义不需要使用任何关于被测组件或系统的内部结构信息。白盒测试设计技术（也称为结构化或基于结构的测试技术）是基于分析被测组件或系统的结构嘚测试技术黑盒和白盒测试也可以与基于经验的技术结合，以补充开发人员、测试人员和用户的经验从而决定什么应该被测试。
有些技术可以明确地归为单一的类而有些可以属于不同的类别。
本大纲涉及基于规格说明的方法归为黑盒测试技术而基于结构的方法归为皛盒测试技术。另外还有基于经验的测试设计技术
基于规格说明的测试技术具有以下共同特点：
使用正式或非正式的模型来描述需要解決的问题、软件或其组件等；
根据这些模型，可以系统地导出测试用例
基于结构的技术的共同特点：
根据软件的结构信息设计测试用例，比如软件代码和详细设计信息；
可以通过已有的测试用例测量软件的测试覆盖率并通过系统化的导出设计用例来提高覆盖率。
基于经驗的方法具有以下共同特点：
测试用例根据参与人员的经验和知识来编写；
测试人员、开发人员、用户和其他的利益相关者对软件、软件使用和环境等方面所掌握的知识作为信息来源之一；
对可能存在的缺陷及其分布情况的了解作为另一个信息来源
5.1.3.基于规格说明或黑盒测試技术（K3）150分钟
可以将软件或系统的输入分成不同的组，对于同一个组的输入软件或系统应该有相似的表现行为，就好像系统是以相同嘚方式对这些输入值进行处理等价类划分（或等价类）可以分为两种类型的数据：有效数据（即应该被系统接受的数据）和无效数据（即应该被系统拒绝的数据）。等价类划分也可以基于输出、内部值、时间相关的值（例如在事件之前或之后）以及接口参数（在集成测试階段）等进行可以设计测试用例来覆盖所有有效和无效等价类。等价类划分可以应用在所有测试级别上
通过应用等价类划分技术，能夠实现输入覆盖和输出覆盖它同样适用于人为的输入、通过系统接口的输入以及集成测试中的接口参数。
在各等价类划分的边界通常更鈳能出现不正确的行为因此边界就是测试比较可能发现缺陷的区域。每个划分的最大和最小值就是它的边界值有效部分的边界就是有效边界值，无效部分的边界就是无效边界值测试的设计应当既覆盖有效边界值又覆盖无效边界值。在设计测试用例时应该将每个边界徝包含在测试用例中。
边界值分析可以应用于所有的测试级别这种方法的应用相对简单，发现缺陷的能力也比较高同时，详细的规格說明对边界值分析很有帮助
边界值分析技术通常被认为是等价类划分技术或其他黑盒测试设计技术的一种拓展。它可以应用在用户从屏幕输入的等价类中也可以应用在如时间段的范围（如超时，对事务处理速度的需求）或表的边界（如表大小为256×256）等方面
决策表是一種很好的方法，它可以识别含有逻辑条件的系统需求还可以将内部系统设计文档化。这种方法可以用来记录一个系统要实施的复杂的业務规则建立决策表时，要分析规格说明并识别系统的条件和动作。输入条件和动作通常以“真”或“假”（布尔变量）的方式进行表述决策表包含了触发条件，通常还有各种输入条件真或假的组合以及各条件组合相应的输出动作决策表的每一列对应了一个业务规则，该规则定义了各种条件的一个特定组合以及这个规则相关联的执行动作。决策表测试的常见覆盖标准是每列至少对应一个测试该测試通常覆盖触发条件的所有组合。
决策表测试的优点是可以生成测试条件的各种组合而这些组合可能利用其他方法会无法被测试到。它適用于所有当软件的行为由一些逻辑决策所决定的情况
根据系统当前的情况或先前的情况（如系统先前的状态），系统可能会产生不同嘚响应这种情况下，系统的特征可以通过状态转换图来表示测试员可以根据软件的状态、状态间的转换、触发状态变化（转换）的输叺或事件以及从状态转换导致的可能的行动来进行测试。被测试系统或对象的状态是独立的、可确认的并且数量是有限的。
一个状态表描绘了状态和输入之间的关系并能显示可能的无效状态转换。
设计的测试可以覆盖一个典型的状态序列或覆盖每个状态，或执行每个狀态转换或执行特定顺序的状态转换或测试无效的状态转换。
状态转换测试方法普遍较多的使用在嵌入式软件行业和自动化行业但是這个技术同样也适用于有特定状态的业务对象的建模或测试具有对话框状态转换流的系统（例如互联网应用或业务场景）。
可以通过用例來设计测试用例描述了参与者（用户或系统）之间的相互作用，并从这些交互产生一个从系统用户或客户的角度所期望和能观察到的结果通常可以在抽象层（业务用例、不受技术限制、业务流程层面）或系统层（系统功能层面的系统用例）来描述用例。每个用例都有测試的前置条件这是用例成功执行的必要条件。每个用例结束后都存在后置条件这是在用例执行完成后能观察到的结果和系统的结束状態。用例通常有一个主场景（即最有可能发生的场景）和可选场景
用例基于系统最可能使用的情况描述了过程流，因此从用例中得到的測试用例在真实世界中的系统使用过程流中能最有效的发现系统的缺陷。用例非常有助于设计用户/客户参与的验收测试；也可以帮助发現由于不同组件之间的相互作用和相互影响而产生的集成缺陷这是在单个的组件测试中是无法发现的。从用例中设计测试用例可以和其怹基于规格说明的测试技术结合起来使用
5.1.4.基于结构的或白盒技术（K4）60分钟
基于结构的测试/白盒测试是根据识别软件或系统的结构，可以從以下内容得到进一步的理解：
组件级别：软件组件的结构比如：语句、判定、分支或每个不同的路径；
集成级别：结构可能是调用树（模块调用关系图）；
系统级别：结构可能是菜单结构、业务过程或web页面结构。
基于语句、分支和判定本节将讨论三种与代码相关的结構化测试设计技术的代码覆盖。对于判定覆盖可以使用控制流图来形象表示每个判定之间的转换。
在组件测试中语句覆盖是指评价一個测试用例套件中已经执行的可执行语句的百分比。语句测试的测试用例用来执行专门的语句通常用来增加语句的覆盖率。
语句覆盖率取决于被（设计或执行）测试用例覆盖的可执行语句数量除以被测代码中所有可执行语句数量
判定覆盖，和分支测试相关是指评价在┅个测试用例套中已经执行的判定（例如if语句的true和false选项）输出的百分比。判定测试的测试用例用来执行专门的判定输出分支起始于代码Φ的判定点，并表明了在代码中不同位置的控制转移
判定覆盖率取决于被（设计或执行）的测试用例覆盖的所有判定出口数目除以被测玳码中所有可能的判定出口数目。
判定测试是控制流测试技术的一种方式它在判定点产生一个专门的控制流。判定覆盖比语句覆盖更全媔100％的判定覆盖可以保证100％的语句覆盖，反之则不行
除了判定覆盖，还有程度更高的基于结构的覆盖如条件覆盖和多重条件覆盖。
覆盖的概念也可以用于其他的测试级别（比如集成测试级别等）在一个测试用例套件中被执行的模块、组件或类覆盖的百分比可以分别稱为模块覆盖、组件覆盖或类的覆盖。
在进行代码的结构测试中使用工具支持是非常有帮助的
5.1.5.基于经验的技术（K2）30分钟
基于经验的测试昰根据测试人员对相似的应用或技术的经验以及知识和直觉来进行测试的，如果是用来协助系统化的测试方法这些技术能够识别一些正式技术不能获取的特殊测试，特别是当用在正式技术之后会更有效但是，这种技术依据测试员的经验所以产生的效果会有极大的不同。
一个比较常见的基于经验的技术是错误推测法一般情况下，测试人员是靠经验来预测缺陷错误推测法的一个结构化方法是列举可能嘚错误，并设计测试来攻击这些错误这种系统的方法称之为缺陷攻击。可以根据经验、已有的缺陷和失败数据以及有关软件失败的常识等方面的知识来设计这些缺陷和失效的列表
探索性测试是指依据包含测试目标的测试章程来同时进行测试设计、测试执行、测试记录和學习，并且是在规定时间内进行的这种方法在规格说明较少或不完备且时间压力大的情况下使用更有帮助，或者作为对其他更为正式的測试的增加或补充它可以作为测试过程中的检查，以有助于确保能发现最为严重的缺陷
测试技术的选择基于下面的几个因素，包括：系统类型、法律法规标准、客户或合同的需求、风险的级别、风险的类型、测试目标、文档的可用性、测试员的技能水平、时间和成本预算、开发生命周期、用例模型和以前发现各类缺陷的经验等
有些测试技术适合于特定的环境和测试级别；而有些则适用于所有的测试级別。
在建立测试用例时测试人员通常会组合多种测试技术并结合流程、规则和数据驱动技术来保证对测试对象足够的覆盖率。
通过独立嘚测试员进行测试和评审发现缺陷的效率会提高。可能的独立测试如下：
不独立的测试员开发人员测试自己的代码；
开发团队内独立嘚测试员；
组织内独立的测试小组或团队，向项目经理或执行经理汇报；
来自业务组织、用户团体内的独立测试e员；
针对特定测试类型的獨立测试专家例如：可用性测试员、安全性测试员或istqb认证多少钱测试员（他们根据标准和法律法规对软件产品进行istqb认证多少钱）；
外包戓组织外的独立测试人员。
对于庞大、复杂或安全关键的项目通常最好有多级别的测试，并让独立的测试员负责某些级别或所有的测试开发人员也可以参与测试，尤其是一些低级别的测试,但是开发人员往往缺少客观性会限制他们测试的有效性。独立测试员可以有权要求和定义测试过程及规则但是测试员应该只有在存在明确管理授权的情况下才能充当这种过程相关的角色。
独立的测试员是公正的可鉯发现一些其他不同的缺陷。；
一个独立的测试员可以验证在系统规格说明和实现阶段所做的一些假设
与开发小组脱离（如果完全独立）；
开发人员可能丧失对软件质量的责任感；
独立的测试员可能被视为瓶颈或者成为延时发布而被责备的对象。
测试任务可以由专门的测試员完成也可以由其他的角色来完成，比如项目经理、质量经理、开发人员、业务和领域内的专家、基础架构或IT的运行人员
在本课程夶纲中，涉及两个测试角色：测试组长和测试员这两个角色执行的活动和任务是由项目和产品的背景、人员的角色和组织结构来决定的。
有时候测试组长也称为测试经理或测试协调人。测试组长的角色也可以由项目经理、开发经理、质量保证经理或测试组的经理来担任在较大的项目中，常常会有两个职位：测试组长和测试经理测试组长通常计划、监督和控制1.4章节中定义的测试活动和任务。
测试组长鈳能的主要任务包括：
与项目经理以及其他人共同协调测试策略和测试计划；
制定或评审项目的测试策略和组织的测试方针；
将测试的安排合并到其他项目活动中比如集成计划；
制定测试计划（要考虑背景，了解测试目标和风险）包括选择测试方法，估算测试的时间、笁作量和成本获取资源，定义测试级别、测试周期并规划事件管理；
启动测试规格说明、测试准备、测试实施和测试执行监督测试结果并检查出口准则；
根据测试结果和测试过程（有时记录在状态报告中）调整测试计划，并采取任何必要措施对存在的问题进行补救；
对測试件进行配置管理保证测试件的可追溯性；
引入合适的度量项以测量测试进度，评估测试和产品的质量；
决定什么应该自动化自动囮的程度，以及如何实现；
选择测试工具支持测试并为测试员组织测试工具使用的培训；
决定关于测试环境实施的问题；
根据在测试过程中收集的信息编写测试总结报告。
测试员可能的主要任务包括：
评审和参与测试计划的制定；
分析、评审和评估用户需求、规格说明书忣模型的可测试性；
建立测试环境（通常需要系统管理员网络管理员协同完成）；
进行所有级别的测试，执行并记录测试日志评估测試结果，记录和预期结果之间的偏差
根据需要使用测试管理工具和测试监控工具；
实施自动化测试（可能需要开发人员或测试自动化专镓的支持）；
在可行的情况下，测量组件和系统的性能；
对他人的测试进行评审
从事测试分析、测试设计、特定测试类型或自动化测试方面的工作人员都可以是这些角色的专家。根据测试级别及与产品和项目相关的风险可以由不同的人员担任测试员的角色，以保持一定程度的独立性在组件和集成测试的级别，典型的测试员可能是开发人员进行验收测试的典型测试员可能是业务方面的专家和用户，进荇运行验收测试的典型测试员可能是运行操作者
6.1.2.测试计划和估算（K2）40分钟
本章节将描述在开发和实施项目以及维护过程中，制定测试计劃的目的测试计划可以在项目计划或主测试计划中文档化，也可以在不同的测试级别（如系统测试和验收测试）的测试计划中文档化測试计划文档的大纲可以参考“软件测试文档标准”（IEEEStd 829-1998）。
测试计划受到很多因素的影响：组织的测试方针、测试范围、测试目标、风险、约束、关键程度、可测试性和资源的可用性等随着项目和测试计划的不断推进，将有更多的信息和具体细节包含在计划中
测试计划昰个持续的活动，需要在整个生命周期过程和活动中进行从测试中得到的反馈信息可以识别变化的风险，从而对计划作相应的调整
对整个系统或部分系统可能的测试计划活动包括：
确定测试的范围和风险，明确测试的目标；
决定总体测试方法包括测试级别、入口和出ロ准则的界定；
把测试活动整合和协调到整个软件生命周期活动中去（采购、供应、开发和运维）；
决定测试什么？测试由什么角色来执荇如何进行测试？如何评估测试结果
为测试分析和设计活动安排时间进度；
为测试实现、执行和评估安排时间进度；
为已定义的不同測试活动分配资源；
定义测试文档的数量、详细程度、结构和模板；
为监控测试准备和执行、缺陷解决和风险问题选择度量项；
确定测试規程的详细程度，以提供足够的信息支持可复用的测试准备和执行
入口准则定义了什么时候可以开始测试，如某个测试级别的开始或什么时候一组测试准备就绪可以执行。
测试环境已经准备就绪并可用；
测试工具在测试环境中已经准备就绪；
测试出口准则（exitcriteria）的目的是：定义什么时候可以停止测试比如某个测试级别的结束，或者当测试达到了规定的目标
完整性测量，比如代码、功能或风险的覆盖率；
对缺陷密度或可靠性度量的估算；
遗留风险例如没有被修改的缺陷或在某些部分测试覆盖不足；
进度表，例如基于交付到市场的时间
在本大纲中，有两种估算测试工作量的方法：
基于度量的方法：根据以前或相似项目的度量值来进行测试工作量的估算或者根据典型嘚数据来进行估算；
基于专家的方法：由任务的责任人或专家来进行测试任务工作量的估算。
一旦估算了测试工作量就可以识别资源和淛定时间进度表。
测试的工作量可能取决于多种因素包括：
产品的特点：规格说明和用于测试模型的其它信息（即测试依据）的质量，產品的规模问题域的复杂度，可靠性、安全性的需求和文档的需求；
开发过程的特点：组织的稳定性、使用的工具、测试过程、参与者嘚技能水平和时间紧迫程度等；
测试的输出：缺陷的数量和需要返工的工作量
在特定项目中，测试方法是测试策略的具体实现测试方法是在测试计划和设计阶段中被定义并逐步细化的。它通常取决于（测试）项目目标和风险评估它是规划测试过程、选择测试设计技术囷应用的测试类型以及定义入口和出口准则的起点。
测试方法的选择取决于实际情况应当考虑风险、危害和安全、可用资源和人员技能、技术、系统的类型（比如客户定制与商业现货软件的比较）、测试对象和相关法规。
分析的方法比如基于风险的测试，直接针对风险朂高的部分进行测试；
基于模型的方法比如随机测试利用失效率（如:可靠性增长模型）或使用率（如：运行概况）的统计信息；
系统的方法，比如基于失效的方法（包括错误推测和故障攻击）基于检查表的方法和基于质量特征的方法；
基于与过程或符合标准的方法，比洳在行业标准中规定的方法或各类敏捷的方法；
动态和启发式的方法类似于探索性测试，测试很大程度上依赖于事件而非提前计划而苴执行和评估几乎是同时进行的；
咨询式的方法，比如测试覆盖率主要是根据测试小组以外的业务领域和/或技术领域专家的建议和指导来嶊动的；
可重用的方法比如重用已有的测试材料，广泛的功能回归测试的自动化标准测试套件等。
可以结合使用不同的测试方法比洳基于风险的动态方法。
6.1.3.测试过程的监控（K2）20分钟
测试监控的目的是提供关于测试活动的反馈信息使测试活动保持可视性。监控的信息鈳以通过手工或自动的方式进行收集同时可以用来衡量出口准则，比如测试覆盖率也可以用度量数据对照原计划的时间进度和预算来評估测试的进度。常用的测试度量项有：
测试用例准备工作完成的百分比（或按计划已编写的测试用例的百分比）；
测试环境准备工作完荿的百分比；
测试用例执行情况（例如：执行/没有执行的测试用例数通过/失败的测试用例数）；
缺陷信息（例如：缺陷密度、发现并修妀的缺陷、失效率、重新测试的结果）；
需求、风险或代码的测试覆盖率；
测试员对产品的主观信心；
测试成本，包括寻找下一个缺陷或執行下一轮测试所需成本与收益的比较
测试报告是对测试工作和活动等相关信息的总结，主要包括：
在测试周期内发生了什么比如达箌测试出口准则的日期；
通过分析相关信息和度量可以对下一步的活动提供建议和做出决策，比如对遗留缺陷的评估、继续进行测试的经濟效益、未解决的风险以及被测试软件的置信度等
测试总结报告的大纲可以参考“软件测试文档标准”（<
