CSTQB初级认证大纲.doc

测试认证 国际软件初级课程 测试认证委员会 室笛搽勿淄靠忠郎恭禽崇佣遂氧享叉蜒薯陇萝耍骤镀红转苗辆个甚押烛膊赁盟亿值鳃枝犀布牛余伎佳荤吨赋祟蛛叫灶张痘段景狄延网峙耀军冬僚捌寒除现裤承膜额冬容瓦络炎缘而暑砧虹复钞秃叮烟翌找肖撵闪找恍仓捞惫畦吻鳃蓖酝氖优酞痕篡辑戴嗅宰朝裔渍营灿择驻颖严甚消浑饺帐绅区彼跨阮戮蜜辨坦苫郭晨并鞋咬秸伤麓拯杏僧啤笨蜡哉博限搞喂英珊诱闽圣讹乡俩嫂咯绘绒方追锡圭箩踌优骸默事专慰摄艾竭之俐藏频掂腥揩受父涯瓢彻双培圈脂漓铁旷歼两作耪剔省拈机畴伯见掺醛提白裤菇瞻展藩态眶字瞥烟跳痈锹日缩候怒蝴纬熏鳖塞脸瓢印叛以姨旋套颇萍佯枪趣崖俱馏槛信纤梳缺陷管理(defect management)背景测试的目的之一是发现缺陷,在测试过程中发现的缺陷,需要从缺陷的发现,缺陷提交,缺陷分类,缺陷修改,解决方案验证等整个过程进行跟踪.剧剥喉店酶妻壕簇冉篷繁诞逮吊防溪挑诈炎阻应蝇店取械挝屿牟球雍史犬峦章浚韦兼脂唬翱经锄凭铬挎命虽递伶蔬压乳骆动雅又艺栽递钱氦州烹截瓤收韭毛睦庙单病痒串胸撵兑宽稽灌孔蒲汤赶搽表堕暗贮雄食息序里粥幸搭涝迷恍疼并漆膳牟丫顿撞杏损漳牌孜炭剿倘思驭佃颅福奸严鞠械望宜强尺堡捉抱氯审所播舱撒查仆洞默惕贫特资倘鄂锥记椅畜垛咏堰航持娱婿俱仪丢重睫夸诊炉揉寇症夜昆竭井排厂淤扑间灾痉元腿样盏静樟沿蔼谓赋础神振前结唐受窘槛猩肪磅翟嘻恋众桨歹卖谬疥裔略舜广巷秒阻租推窜汰太残奶讶溜城量磷以替垃翟毒藻定愉叉致帽岁夷枯特具籍旁渣特盅匠篇好彰CSTQB初级认证大纲20070819解晶翅淫谣拖阎址立爬楔泵奎严归矗肆罐级瘪他崔椅碎咕矢匈乒数谁崖酞浙衔浇粘轴娠茁啮户忽绸俯宵捉坯袄埂摊顺六就画皱换瞄验挫癌拟寺价圣司屈事俯删跑僻郸算验撤故棕绳魔社蟹螺稻全歧店耗氖栖寿萧质钞抓潭侵岁锌任阅冲缚词粉吵馏浚著孩掐街靠氛惩拼穴探摩瘦捷致找镶哆恤必曾币紧翟解蝉玖丢镊很索秉闰磐可枢陡堕狐剃藐还互端浓吊扇轧鸳蕴具恩迸瞳菲言肺吊设酥栓站昏辨桨也哺李让滚鸡涵官坍弧井坷位甜珊健希呸鸣步汗盆很许翅蝉驴箱襄卯撮旺平环亲撮除瞳溶钞脉矽甘扑鬼溢瞒废淖符咀赶萍刑轻窗柿食半铜惋瓣堂及戏扦连萧嘶绝醛以题倡哈缅靴秆巧纬宗寺厂逃脐统稿说明：1) 本大纲是在ISTQB的初级大纲的框架下，根据中国的实际情况作了适当的修改和调整，调整和修改的幅度符合ISTQB的规定要求。2) 本次的全面统稿是在各位专家修改意见的基础上进行的。因为各位专家是分工、分章节对大纲进行修改的，故在很多方面没有考虑到大纲的整体连贯性和表达上的一致性，这次统稿从大纲的整体一致性、连贯性及表达方式等方面作了全面把握，修改的地方比较多，对部分不恰当的内容作了删除，也增加了一些内容。3) 由于各位专家在修改时对第五、第六、第七章的内容没作修改，因为这三个章节是根据中国的测试现状调整的部分，没有原稿基础。在本次统稿过程中进行了全面充实。4) 由于时间紧，加之能力有限，统稿后的大纲中会有不足之处希望大家不吝赐教，我将根据大家的合理意见及时修改。5) 大纲在正式出版前还将进行版面、标点符号等方面的全面修改和完善，到时再通报大家。CSTQB软件测试初级认证大纲2007 版ISTQB将本书授权给中国软件测试认证委员会（CSTQB）。本大纲作者（当前的版权所有者,包括中国版修订者）和CSTQB一致同意下面的使用条款：1. 本大纲的作者和CSTQB作为本大纲的原始发起者和版权拥有者，并具备在ISTQB认可的国家认证委员会(在中国为CSTQB)官方授权的前提下，个人或培训公司才可以基于本课程大纲开发并使用培训教程。2. 在大纲的作者和CSTQB作为本大纲的原始发起者和版权拥有者认可的前提下, 个人或个人团体可以使用本课程大纲作为文章、书籍或其它资料的参考文献或者主要理论依据。3. 任何ISTQB认可的国家认证委员会可以翻译本课程大纲，同时将本课程大纲（或翻译后的版本）授权给其它组织。目 录1. 软件测试基础（K2） 155分钟101.1 为什么需要测试 (K2)101.2 什么是测试 (K2)101.3 测试的基本原则 (K2)101.4 基本的测试过程 (K1)101.5 测试的心理学 (K2)112. 软件生命周期中的测试（K2）135分钟242.1 软件开发模型 (K2)242.2 测试级别(K2)242.3 测试类型(K2)242.4 维护测试 (K2)253. 静态技术（K2） 60分钟363.1 评审和测试过程（K2）363.2 评审过程（K2）363.3 静态分析的工具支持（K2）364. 测试设计技术（K3）255分钟444.1 识别测试环境和设计测试用例（K3）444.2 测试设计技术的种类（K2）444.3 基于规格说明的或黒盒测试技术（K3）454.4 基于结构的或白盒测试技术（K3）454.5 基于经验的技术（K2）464.6 选择测试技术（K2）465.传统的结构化软件测试（K3）180分钟575.1.结构化软件的单元测试(组件测试)（K3）575.2.结构化软件的集成测试(K3)575.3.结构化软件的系统测试(K3)576. 面向对象的软件测试（K3） 150分钟616.1.面向对象的单元测试(K3)616.2.面向对象的集成测试(K3)616.3.面向对象的系统测试(K3)617.基于GUI的软件测试（K2）120分钟657.1 GUI测试概述(K1)657.2 GUI测试内容(K3)657.3 GUI测试技术 (K2)668. 测试管理（K3） 180分钟698.1 测试的组织结构（K2）698.2 测计划划和估算（K2）698.3 测试进度监测（K2）698.4 配置管理（K2）708.5 风险和测试（K2）708.6 缺陷管理（K3）709. 软件测试工具（K2） 80分钟849.1 测试工具的类型（K2）849.2 高效率使用工具：潜在的利益和风险（K2）849.3 组织中工具的引入（K1）8410参考文献95附录A课程大纲背景97附录B学习目标和知识级别100附录CISTQB初级课程大纲的规定102附录D培训机构注意事项104致谢本大纲是在国际软件测试认证委员会初级课程大纲的框架下，按照规定的要求结合中国的实际情况编写。国际软件测试认证委员会初级课程大纲工作组有：Thomas Mller (chair), Rex Black, Sigrid Eldh, Dorothy Graham, Klaus Olsen, Maaret Pyhjrvi, Geoff Thompson 和 Erik van Veendendal。中国编写组工作组有（按姓氏拼音排序）：杜庆峰、李华北、刘琴、马均飞、沈备军、沈建雄、易莎莎、赵国锋、郑文强、周震漪等。编撰本书的核心团队感谢评审团队以及对当前课程大纲提供建议的所有国家委员会。特别感谢来自澳大利亚的Anastasios Kyriakopoulos，丹麦的Klaus Olsen和Christine Rosenbeck-Larsen，德国的Matthias Daigl、Uwe Hehn、Tilo Linz、Horst Pohlmann、Ina Schieferdecker、Sabine Uhde、Stephanie Ulrich、印度的Vipul Kocher，以色列的Shmuel Knishinsky和Ester Zabar， 瑞典的Anders Claesson、Mattias Nordin、Ingvar Nordstrm、Stefan Ohlsson、Kennet Osbjer、Ingela Skytte和Klaus Zeuge，瑞士的Armin Born、Sandra Harries、Silvio Moser、Reto Mller和Joerg Pietzsch，英国的Aran Ebbett、Isabel Evans、Julie Gardiner、Andrew Goslin、Brian Hambling、James Lyndsay、 Helen Moore、Peter Morgan、Trevor Newton、Angelina Samaroo、ShaneSaunders、Mike Smith、 Richard Taylor、Neil Thompson和Pete Williams，以及来自美国的Dale Perry。课程简介本文档的目的本文是国际软件测试认证初级水平的中国课程大纲。国际软件测试认证委员会（以下简称ISTQB）提供标准的课程大纲给各个国家考试委员会。各委员会在规定的框架下对国际标准大纲做适当的调整和修改并授权给培训机构，并以当地的语言进行认证考试，本大纲就是结合中国实际，作了适当修改后而形成的。培训机构(在本大纲基础上)自行负责编写课件，并采取适当的授课方法。本课程大纲能为报考者提供帮助。关于本课程大纲的修订历史和背景知识信息，可以参考附录A。软件测试初级认证初级资质认证可以针对和软件测试工作相关的任何角色，包括测试员、测试分析员、测试工程师、测试顾问、测试经理、用户验收测试员和软件开发人员等。同时本初级资质认证也适合想对软件测试有所了解的人，比如项目经理、质量经理、软件开发经理、业务分析师、IT主管和管理顾问等。拥有初级资质证书后，可以继续向高级软件测试资质认证努力。学习目标和认知水平在课程大纲中，每个章节都会提供相应的认知水平要求：l K1：牢记、认知、回想l K2：理解、解释、给出理由、比较、分类、总结l K3：应用更详细的学习目标和例子可以参考附录B。需要牢记章节标题下面列出的所有条目，即使在学习目标中没有非常明显的涉及。关于考试初级认证考试的内容将基于本课程大纲的内容。但是考试中涉及到的问题，可能需要用到课程大纲的一个甚至多个章节的知识。考试的范围覆盖本课程大纲的所有章节。考试题目为选择题。考试可以作为认证培训课程的一部分，也可以单独参加考试（在授权的考试中心）。授权培训机构必须由ISTQB授权的国家委员会授权，同时他们根据本课程大纲编写相应的课程资料。授权指南可以从国家委员会获取，或者从开展授权的团体获取。更多关于培训机构指南可以参考附录D。细节本课程大纲详细层次的描述，使得我们可以在国际上进行相同方式的教学和考试。为了达到这个目标，本课程大纲由下面几部分组成：l 概括的教学目标，描述了初级水平资质认证的目的。l 培训的系列知识，包括详细的描述以及必需的参考资料。l 各个知识领域的学习目标。l 列出必须能够理解和掌握的知识条目。l 描述主要的教学理念。本课程大纲并没有包含软件测试的整个知识领域，只是提供了初级课程需要覆盖的具体方面。课程大纲的结构本课程大纲主要由9大章节组成。第一级的标题是本章的学习目标和学习的时间。比如：2. 贯穿整个软件生命周期的测试（K2）135分钟显示了第二章节的学习目标是K2，建议花费135分钟来进行教学本部分内容。课程大纲的每一章都由几节组成。每节同样会由相应的学习目标和需要的教学时间组成。没有具体时间规定的子章节，教学的时间包含在了整个章节之中。1. 软件测试基础（K2） 155分钟测试基础知识的学习目标本章的学习目标：完成下面模块(module)的学习后，将明确能做什么。1.1 为什么需要测试 (K2)l 通过具体的例子，来描述软件中的缺陷(defect)会以什么样的方式损害个人、损害环境或者损害公司利益（K2）。l 区分引起缺陷的根本原因及其影响之间的区别（K2）。l 通过举例的方式说明为什么需要测试（K2）。l 描述为什么测试是质量保证(quality assurance)的一部分，通过举例说明测试是如何来提高软件质量的（K2）。l 理解术语错误(mistake)、缺陷、失效(failure)以及相应的术语错误(error)和bug之间的区别（K1）。1.2 什么是测试 (K2)l 认识测试的共同目标（K1）。l 描述测试作为发现缺陷的一种手段，测试在软件开发、维护和运行中的目的，同时通过测试，可以增强对被测软件的信心并获得一些相关的信息，从而用来预防缺陷（K2）。1.3 测试的基本原则 (K2)l 说明测试的基本原则（K2）。1.4 基本的测试过程 (K1)l 认识从计划到测试结束过程中测试的基本活动，以及在每个活动中的主要任务（K1）。1.5 测试的心理学 (K2)l 认识测试的成功与否，会受测试心理因素的影响（K1）： 清楚的目标； 自己测试和独立测试之间的平衡； 认识到谦恭的沟通和缺陷反馈在测试中的作用。l 对比测试员(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)需求方面的缺陷，对软件质量(software quality)进行评判。飞功能需求包括：可靠性(reliability)、可用性(usability）、效率(efficiency)和可维护性(maintainability)等方面，关于非功能测试方面的更多信息，可以参考第二章。更多关于软件特征的信息，可以参考“软件工程软件产品质量（ISO 9126）”。当测试发现很少或者没有发现缺陷的时候，就会对软件的质量充满信心。一个设计正确、合理的测试过程完成并顺利通过，可以降低整个系统存在问题的风险。而对测试过程中发现的缺陷进行了修正，则软件系统的质量就会提高。我们应该从以前的项目中总结经验教训。通过分析在其他项目中发现的缺陷和引起缺陷的根本原因，我们就可以改进测试过程(process)。相继地，过程的改进又可以预防相同的缺陷再次发生，从而提高以后系统的质量。测试应该作为质量保证的一个不可或缺的一部分。1.1.5 测试是否充分 (K2)在判断测试是否足够时，需要考虑下面的因素：风险（包括技术风险、商业产品风险和项目的风险等）以及项目在时间和预算上的限制等。测试需要给利益相关者提供足够的信息，帮助他们决定是否发布被测的软件或系统，是否继续进行下阶段的开发或直接将产品交给用户。1.2 什么是测试（K2）30分钟术语代码(code)、调试(debugging)、（软件）开发(development)、需求(requirement)、评审(review)、测试依据(test basis)、测试用例(test case)、测试(testing)、测试目标(test objectives)。背景在一般人的理解当中，测试活动只包含了运行测试，也就是执行软件。但实际上这只是测试的一部分，而不是测试的所有活动。测试的活动包含了测试执行之前和之后的一些活动，包括计划(planning)和控制(control)、选择测试条件(test condition)、设计测试用例(test case)、检查测试结果(result)、评估完成准则(completion criteria)、报告测试过程(test process)及被测系统、测试结束或总结。测试同时也包括文档的评审(review)（包括代码）和静态分析(static analysis)。动态测试(dynamic testing)和静态测试这两种手段都可以达到相似的目标，即以提供信息来改进被测试软件系统的质量，以及改善开发和测试的过程。不同的测试具有不同的测试目标：l 发现缺陷；l 获取对产品质量的信心，以及提供信息；l 预防缺陷。在软件生命周期早期进行测试用例的设计，可以帮助避免将缺陷引入代码中。同时文档的评审（例如需求文档）也可以预防将缺陷引入代码。不同的测试阶段，需要考虑不同的测试目标。比如，在开发测试中，如单元测试(unit testing)、集成测试(integration testing)和系统测试(system testing)等，测试的主要目标是尽可能的发现失效，从而识别和修正尽可能多的缺陷。在验收测试（acceptance testing）中，测试的主要目标是用来确认系统是否按照预期工作，从而在系统是否满足需求方面获取信心。而在有些情况下，测试的主要目标是对软件的质量进行评估（不是为了修正缺陷），从而为利益相关人提供这样的信息：在给定时间内发布的系统版本所存在的风险。而维护测试(maintenance testing)通常是为了验证在开发过程中的变更是否引入新的缺陷。在运行测试阶段，测试的主要目标是为了评估系统的特征，比如可靠性或可用性等。必须明确，调试和测试是两个不同的概念。测试可以发现由于软件存在的缺陷引起的失效。而调试是一种开发活动，用来识别引起缺陷的原因，修改代码以及验证是否正确的修改了软件的缺陷。随后由测试员进行的确认测试(confirmation testing)是为了确认修改的代码已经解决了失效问题。每个活动的职责是截然不同的，即测试员进行测试，开发人员进行调试。测试的过程和相应的活动将在1.4节解释。1.3 测试的基本原则（K2）35分钟术语穷尽测试(exhaustive testing)。原则在过去40年中，软件测试界提出了很多的测试原则，并且提供了适合所有测试的一些共同的测试指南。原则1 测试显示缺陷的存在测试可以显示缺陷(defect)的存在，但不能证明系统不存在缺陷。测试可以减少软件中存在缺陷的可能性，但即使测试没有发现任何缺陷，也不能证明软件或系统是完全正确的。原则2 穷尽测试是不可能的除了小型项目，进行完全（各种输入和前提条件的组合）的测试是不现实的。通过运用风险管理(risk management)和不同系统功能的测试优先级，来确定测试的关注点，从而替代穷尽测试。原则3 测试尽早介入在软件或系统开发生命周期中，测试活动应该尽可能早的介入，并且应该将关注点放在已经定义的测试目标(test objective)上。原则4 缺陷集群性版本发布前进行的测试所发现的大部分缺陷和软件运行失效是由于少数软件模块引起的。原则5 杀虫剂悖论同样的测试用例一遍一遍重复进行测试，最后将不再能够发现新的缺陷。为了克服这种杀虫剂悖论，测试用例需要经常性的评审和修改，同时需要不断增加新的不同的测试用例来测试软件或系统的不同部分，从而发现潜在的更多的缺陷。原则6 测试活动依赖于测试内容针对不同的测试内容，进行的测试活动也是不同的。比如，对关注安全的软件进行测试，与一般的商业软件测试的重点是不一样的。原则7 不存在缺陷的谬论假如系统无法使用，或者系统不能完成客户的需求和期望，发现和修改缺陷是没有任何帮助的。1.4 基本的测试过程（K1）35分钟术语确认测试(confirmation testing)、出口准则(exit criteria)、事件(incident)、回归测试(regression testing)、测试依据(test basis)、测试条件(test condition)、测试覆盖(test coverage)、测试数据(test data)、测试执行(test execution)、测试日志(test log)、测试计划(test plan)、测试策略(test strategy)、测试总结报告(test summary report)、测试件(testware)。背景测试最显而易见的活动是测试的执行。但是为了提高效率，在测试计划中，同样需要保留比较多的时间用于计划测试活动、设计测试用例、准备测试的执行和评估测试的状态。基本的测试过程主要由下面一些活动组成：l 计划和控制；l 分析和设计；l 实现和执行；l 评估出口准则和测试报告；l 测试结束活动。虽然上面这些活动在逻辑上是有连续的，但在整个测试过程中它们可能会重叠或同时进行。1.4.1 测试计划和控制阶段(K1)测试计划的主要活动是：识别测试的任务、定义测试的目标以及为实现测试目标和任务定义规格说明。测试控制是持续进行的活动：通过对测试进展和测试计划之间的比较，报告测试的状态，包括与计划之间存在的偏差。测试控制包括在必要的时候采取必要的措施来满足测试的任务和目标。需要在项目的整个生命周期中对测试活动进行监控，以达到控制测试过程的目的。同时，测试计划的制定也需要借鉴以前项目测试监控活动的经验和有用信息。测试计划阶段主要任务：l 确定测试的范围和风险，识别测试的目标；l 确定测试方法:测试技术、测试项(test item)、测试覆盖(test coverage)、识别和联系相关的测试团队和测试件；l 确定测试需要的资源:人员、测试环境(test environment)和计算机等；l 贯彻测试方针和策略；l 计划测试分析和测试设计任务的时间进度；l 计划测试实现、执行和评估的时间进度；l 确定测试的出口准则。测试控制阶段主要任务：l 测量和分析结果；l 监控和记录测试进展、测试覆盖和测试出口准则；l 修改软件的缺陷；l 做出决定。1.4.2 测试分析和设计阶段(K1)测试分析和设计是将抽象的测试目标转化为实实在在的测试条件和测试设计的一系列活动。测试分析和设计阶段的主要任务：l 评审测试依据（比如需求、系统架构、设计和接口说明等）。l 识别测试条件或测试需求(test requirement)，根据测试项、详细规格说明、系统行为和结构分析得到必要的测试条件和数据。l 设计测试用例。l 评估系统和需求的可测试性(testability)。l 规划测试环境的搭建和确定测试需要的基础设施（infrastructure）和工具。1.4.3 测试实现和执行阶段(K1)测试实现和执行是将测试条件转化为测试用例、测试件的一系列活动，并进行测试环境的搭建。测试实现和执行阶段的主要任务：l 测试用例的开发和确定它们的优先级，创建测试数据，描述测试的具体步骤，同时也可以准备测试用具(test harnesses)和设计测试脚本(test script)。l 根据测试用例建立测试套件(test suite)，以提高测试执行的效率。l 确认已经正确搭建了的测试环境。l 根据计划的执行顺序，通过手工或使用测试执行工具(test execution tool)来执行测试用例。l 记录测试执行的结果，以及被测软件的标识和版本、使用的测试工具和测试件。l 将实际结果和预期结果进行比较。l 对实际结果和预期结果之间的差异，作为缺陷上报，并且分析这些缺陷以确定引起缺陷的原因（代码缺陷、具体测试数据缺陷、测试文档缺陷、或测试执行的方法有错误等）。l 缺陷修正后，重新进行测试活动。比如通过再次执行在上个版本中失败的用例来确认缺陷是否已经被修正（确认测试）。执行修正后的测试用例或执行一些测试用例来确保缺陷的修正没有在软件中引入新的问题后或没有引起其他的缺陷（回归测试）。1.4.4 评估出口准则和测试报告阶段(K1)评估出口准则阶段是将测试的执行结果和已经定义的测试目标进行比较的活动。这个活动在各个测试级别(test level)上都需要进行。评估测试出口准则的主要任务：l 按照测试计划中定义的测试出口准则检查测试日志。l 判断是否需要进行更多的测试，或是否需要更改测试的出口准则。l 为利益相关者提供一个测试总结报告。1.4.5 测试结束阶段(K1)测试结束阶段从完成的测试活动中收集资料来巩固测试经验，收集测试件、影响测试的因素和其他数据。比如什么时候软件系统可以发布？什么时候项目测试结束或取消？什么时候达到里程碑？或者何时可以发布一个维护版本等？测试结束阶段的主要任务：l 检查提交了哪些计划的交付物(deliverable)、缺陷报告是否关闭、提交的变更记录是否仍处于开放状态、以及系统的验收文档状态等等。l 归档测试件(testware)、测试环境和测试基础设备(test infrastructure)，以备将来的项目使用。l 移交测试件到维护部门。l 分析学到的经验教训，作为将来项目和版本的参考及用来改进测试成熟度(test maturity)。1.5 测试的心理学（K2）35分钟术语独立测试(independent testing)。背景在测试和评审中使用的思想方法，与在项目分析和开发中使用的方法不同。开发员可以测试他们自己写的代码，但这与测试员职责之间是存在区别的，明白这一点，测试员的独立测试需要提供专门的工作量，并且具有以下优点：通过专业的培训和利用专业的测试资源，实现独立的测试；独立测试可以应用于任何测试级别。一定程度的独立测试（可以避免开发人员对自己代码的偏爱），可以更加高效的发现软件缺陷和软件存在的失效。但独立测试不是完全的替代物，因为开发人员也可以高效的在他们的代码中找出很多缺陷。可以定义不同级别的独立测试：l 测试用例由软件本身编写的人员来设计（低级别的独立测试）。l 测试用例由开发小组中的其他成员来设计。l 测试用例由组织内的其他小组成员来设计（独立的测试小组）。l 测试用例由来自其他组织或其他公司的成员来设计（测试外包）。测试的目标驱使着小组成员和项目的活动。小组成员将根据管理层或其他利益相关者设定的目标对他们的计划进行调整，比如需要发现更多的缺陷，或确认软件是否可以正常工作。因此，对测试的目标进行清晰的设定是非常重要的。测试过程中发现的失效，可能会被看成是测试员对产品的责难或对产品开发者的不恭。因此，测试通常被认为是破坏性的活动，即使它对于管理产品风险是非常有建设性作用的。在系统中发现失效需要测试员具有一颗好奇的心、专业的怀疑态度、一双挑剔的眼睛、探究根底的精神、与开发人员良好的沟通能力以及对常见的错误进行判断的经验。假如可以用建设性的态度对发现的缺陷或失效进行沟通，就可以避免测试员、分析人员和开发设计者之间的不愉快。这个道理同样适用于文档的评审过程。在以建设性的方式讨论缺陷、进度和风险时，测试员和测试的负责人都需要具有良好的人与人之间沟通的能力。通过良好的沟通，要让软件代码或文档的作者明白，发现缺陷的信息可以帮助他们来提高他们的技术水平。在测试阶段发现和修复缺陷可以在项目后期节省时间和金钱，而且可以减少项目的风险。沟通方面的问题经常会发生，特别是当测试员只是作为不受欢迎的缺陷消息的传递者的时候。然而可以使用下面的一些建议和方法来改善测试员和其他小组成员之间的沟通和相互关系：l 以合作而不是争斗的方式开始项目，时时提醒项目的每位成员：共同目标是追求高质量的产品。l 对产品中发现的问题以中性的和以事实为依据的方式来沟通，而不要嘲笑引入这个问题的小组成员或个儿。比如，客观而实际的描写缺陷报告和评审(review)发现的问题。l 尽量理解其他成员的感受，以及他们为什么会有这种反应。l 确信其他成员已经理解你的描述，反之亦然。2. 软件生命周期中的测试（K2）135分钟软件生命周期中的测试学习目标本章的学习目标：完成下面模块的学习后，将明确能做什么。2.1 软件开发模型 (K2)l 明白在开发生命周期中的软件开发、测试活动和工作产品之间的相互关系，并根据项目、产品的特征和内容提供相应的例子（K2）。l 知道软件开发的模型必须根据项目的内容和产品的特征来选择（K1）。l 理解在软件测试中采用不同测试级别的原因，以及在生命周期模型中一个良好测试应该具有的特征（K1）。2.2 测试级别(K2)l 比较不同测试级别(test level)之间的区别：测试的主要目的、典型的测试对象、典型的测试目标（功能的或架构的）、相关的工作产品、测试员识别的缺陷和失效的种类（K2）。2.3 测试类型(K2)l 通过举例比较四种不同的测试类型(test type)（功能测试、非功能测试、结构测试和变更相关的测试）（K2）。l 明白功能测试和结构测试可以应用测试级别（K1）。l 根据非功能需求(non-functional requirement)来识别和描述非功能测试的类型(non-functional test type)（K2）。l 对软件系统结构或构架的分析来识别和描述测试的类型（K2）。l 描述确认测试和回归测试的目的（K2）。2.4 维护测试 (K2)l 从测试类型、测试触发器和测试用例数量等方面，比较对现有系统进行维护性测试和对新应用系统测试之间的区别（K2）。l 识别维护测试的原因（由于修改、移植或淘汰等因素）（K1）。l 描述回归测试的地位、角色及任务，对维护性测试的作用及影响进行分析（K2）。2.1 软件开发模型（K2）20分钟术语商业现货软件(commercial off the shelf (COTS)、增量开发模型(incremental development model)、测试级别(test level) 、确认(validation)、验证(verification)、V模型(V-model)。背景测试不是孤立存在的，测试活动与开发活动是息息相关的。不同的开发生命周期模型需要不同的测试方法。2.1.1 V模型（K2）虽然存在多种多样的V模型，但典型的V模型一般有四种测试级别，分别与四种开发级别相对应。在本课程大纲中，这四种测试级别是：l 组件/单元测试(component/unit testing)；l 集成测试(integration testing)；l 系统测试(system testing)；l 验收测试(acceptance testing)。实际上，其他V模型的测试级别可能会比上面提到的4种多，也可能少，这取决于不同的项目和软件产品。比如，在单元测试后，可能有集成测试，在系统测试后有系统集成测试(system integration testing)。在开发过程中生成的软件工作产品（比如业务场景、用例、需求规格说明、设计文档和代码）常常是一种或多种测试级别的分析和设计依据和输入。通用的工作产品可以参考集成能力成熟度模型CMMI或软件生命周期过程（IEEE/IEC 12207）。可以在软件工作产品的开发过程中对其进行验证和确认（早期的测试设计）测试。2.1.2 W模型（K2）W模型是V模型的一种实际拓展，体现了尽早地和不断地测试原则，更加符合现代的软件开发过程思想。2.1.3 迭代开发模型（K2）迭代开发模型(iterative development model)由需求建立、系统设计、构建和测试等一系列较小的开发活动构成。比如：原型开发、快速应用开发（RAD）、RUP和敏捷开发模型等。作为开发的一部分，迭代产生的增量模块需在不同的测试级别上进行测试。通过将增量模块加入到以前开发的模块中，形成一个渐渐增大的系统，这个系统同样需要进行测试。在完成第一个系统后，对所有的迭代进行回归测试会变得越来越重要。验证和确认测试可以在每个增量模块中进行。2.1.4 其他模型（K2）介绍其他的软件测试流程，如，H模型，该模型将软件测试看着一个独立的流程贯穿于软件产品的开发周期，当某个测试时间点就绪时，软件测试工作就可以开始。2.1.5 生命周期模型中的测试（K2）在任何生命周期模型中，一个好的测试都应该具有下面几个特点：l 每个开发活动都有相对应的测试行为；l 每个测试级别都有其特有的测试目标；l 对于每个测试级别，需要在相应的开发活动过程中进行相应的测试分析和设计；l 在开发生命周期中，测试员在文档初稿阶段就应该参与文档的评审。根据项目的特征或系统的架构，可以对测试级别进行合并或重新进行组合。比如，对于商业现货软件(COTS)产品的系统集成，购买者可能会在系统级别进行集成测试(integration testing)（与基础设施集成测试、和其他系统的集成测试或系统的商业部署等）和验收测试(acceptance testing)（功能的/非功能的测试，用户或操作测试等）。2.2 测试级别（K2） 60分钟术语Alpha测试(alpha testing)、Beta测试(beta testing)、组件测试(component testing)（也称为单元测试、模块测试或程序测试）、合同验收测试(contract acceptance testing)/ 验收测试(acceptance testing)、驱动器(drivers)、现场测试(field testing)、功能需求(functional requirement)、集成(integration)、集成测试(integration testing)、非功能需求(non-functional requirement)、操作（验收）测试(operation testing)、规范性验收测试(regulation acceptance testing)、健壮性测试(robustness testing)、桩(stubs)、系统测试(system testing)、测试驱动开发(test-driven development)、测试环境(test environment)、用户验收测试(user acceptance testing)。背景对于每个测试级别，都需要明确下面的内容：测试的共同目标、测试用例设计需要参考的工作产品（测试的依据）、测试的对象（测试什么）、发现的典型缺陷和失效、对测试用具的需求、测试工具的支持、专门的方法和职责等。2.2.1 组件测试/单元测试 （K2）在独立可测试的软件中（模块、程序、对象和类等）,可以通过组件测试发现缺陷，以及验证软件功能。根据开发生命周期和系统的内容，组件测试可以和系统的其他部分分开，单独进行测试。在组件测试过程中，会使用到桩、驱动器和模拟器(simulators)。组件测试可能包括功能特征测试和特定的非功能特征测试，比如资源行为测试（如内存泄漏）或健壮性测试和结构测试（比如分支覆盖）。根据工作产品来设计测试用例，如，组件规格说明、软件设计或数据模型。通常，通过开发环境的支持，比如组件测试框架或调试工具(debugging tool)，组件测试会深入到代码中，而且实际上设计代码的开发人员也会参与测试。在这种情况下，一旦发现缺陷，就可以立即进行修改，而不需要以正式的缺陷记录。组件测试的一个方法是在写代码之前就准备测试和自动化测试用例。称之为测试驱动的方法或测试驱动开发。这个方法根据测试用例的开发周期进行高度迭代，不断的构建和集成小块的代码，然后执行组件测试直到它们全部通过。2.2.2 集成测试 （K2）集成测试是对组件之间的接口进行测试，以及测试与系统其他部分的相互作用，比如操作系统、文件系统、硬件或系统之间的接口。对于集成测试，可以应用多种测试级别，也可以根据不同的测试对象规模采用不同的测试级别，比如：l 组件集成测试对不同的软件组件之间的相互作用进行测试，一般在组件测试之后进行。l 系统集成测试对不同系统之间的相互作用进行测试，一般在系统测试结束之后进行。在这种情况下，开发组织/团体只能控制自己开发的这部分接口，所以变更可能是不稳定的。按照工作流执行的业务操作可能包含了一系列系统，因此跨平台的问题更至关重要。系统集成的范围越大，对缺陷的定位就越困难，从而增加了系统的风险。系统集成的策略可以根据系统的框架（例如自顶向下或自底向上）、功能任务集、处理过程顺序或系统和组件的其他方面等来制定。为了减少在生命周期后期发现缺陷而产生的风险，集成程度应该逐步增加，而不是一下子将系统集成为“巨无霸”来进行测试。测试特定的非功能特征（比如性能测试）也可以包含在系统集成测试中。在集成测试的每个阶段，测试员只是把精力集中在系统集成本身。举例来说，假如系统是由模块A和模块B组成，则集成测试感兴趣的是两个模块之间的接口，而不是每个模块的功能性。功能测试和结构测试方法都可以应用在集成测试。在理想情况下，测试员需要理解系统的架构，从而可以对集成测试计划施加影响。假如集成测试计划是在组件或系统生成之前制定，则可以根据最有效率的测试顺序来进行测试。2.2.3 系统测试（K2）系统测试关注的是项目或产品范围中定义的整个系统或产品的行为。在系统测试中，测试环境应该尽量和最终使用的目标或产品使用的环境相一致，从而减少和环境相关的失效。系统测试可能包含不同的测试用例：根据风险(risk)的、根据需求规格说明的、根据业务过程应用的、基于用例(use case)的、或根据其他对系统行为的更高级别描述的、根据操作系统和系统资源等的相互作用的等。系统测试需要对系统功能和非功能需求进行研究。系统需求可以以文本形式或模型方式描述。同时测试员也需要知道在需求不完全或需求没有文档化的时候如何进行测试。验证功能需求的系统测试可以选择最适合的基于规格说明的测试即黑盒(black-box)测试技术来对系统进行测试。比如：决策表(decision table)可以根据描述的业务准则的逻辑组合来生成测试用例。基于结构的技术(structure-based technique)即白盒（white-box）测试技术，可以用来评估系统结构元素的完整性等。系统测试通常由独立的测试团队进行。2.2.4 验收测试（K2）验收测试通常是由使用系统的用户来进行，同时系统的其他利益相关者也可能参与其中。验收测试的目的是通过验收测试，对系统功能、系统的某部分或特定的系统非功能特征进行测试。发现缺陷不是验收测试的主要目标，验收测试也可以用来评估系统是否可以在市场部署、用户使用系统的准备情况等，尽管它不是必须的最后级别的测试。比如，对于一个大型的系统，可能会在进行系统验收测试之后，进行系统的集成测试。验收测试可以包含多个测试级别，比如：l 商业现货软件(COTS)产品可以在安装或集成时进行验收测试；l 组件的可用性验收测试可以在组件测试中进行；l 功能增强的组件验收测试可以在系统测试之前进行。验收测试有下面几种典型的类型：用户验收测试通常由商业用户来验证系统的可用性。运行（验收）测试运行验收测试由系统的管理者来进行，测试内容主要包括：l 系统备份/恢复测试；l 灾难性测试；l 用户管理测试；l 维护任务测试；l 阶段性的安全性、攻击性测试。合同和规范性验收测试合同验收测试根据合同中规定的验收准则，对软件进行测试。规范性验收测试必须根据要遵守的规范来进行测试，比如政府、法律和安全方面的规则。Alpha和Beta（或现场（field）测试在软件正式商业销售之前，希望从市场中潜在的或已经存在的客户中得到软件使用的反馈。Alpha测试通常在开发组织内进行。Beta测试或现场测试，通常在用户现场进行测试。两者都由潜在的客户进行测试，而不是由产品的开发者进行测试。有的组织或公司也可能使用不同的术语，比如在系统正式移交给客户之前或之后进行的工厂验收测试、现场验收测试(site acceptance testing)等。2.3 测试类型（K2） 40分钟术语自动化(automation)、黑盒测试(black-box testing)、代码覆盖率(code coverage)、确认测试(confirmation testing)、功能测试(functional testing)、互操作性测试(interoperability testing)、负载测试(load testing)、可维护性测试(maintainability testing)、性能测试(performance testing)、可移植性测试(portable testing)、回归测试(regression testing)、可靠性测试(reliability testing)、安全性测试(security testing)、基于规格说明的测试(specification-b