本书以两个典型项目为背景,按实际项目进行的先后次序,循序渐进地阐述了软件测试的全过程。从软件项目启动、需求评审、测试计划开始,然后深入到测**例设计、测试工具选择、脚本开发、功能测试和系统测试等不同阶段,生动地演绎了必需而实用的测试方法、技术和实施技巧。本书还系统地介绍了测试管理的各个层次及其细节,包括测试策略制定、风险控制、缺陷跟踪和分析、测试管理系统的应用等。*后,本书呈现了软件测试成熟度模型和对软件测试的总结和思考,帮助读者了解软件测试所面对的现实问题和应恪守的原则、领会测试方法的应用之道和品味测试的*佳实践。
本书是作者长期从事软件测试工作的经验与智慧的结晶,是软件测试工程师的良师益友。本书也可作为软件开发人员、项目经理等的参考书,更适合用作软件测试的培训教材或��学用书。

在本书的开头,有必要介绍软件测试在软件开发中的位置、地位和作用,也就是帮助读者建立起有关软件测试的基本轮廓(big picture),这样对阅读和理解以后各章的内容会有很大帮助。要建立起软件测试的基本轮廓,也就需要回答下列几个问题:
软件测试的作用是什么?
软件测试在软件开发生命周期(SDLC)中的位置在哪里?
软件测试过程是怎样的?
软件测试团队的地位如何?
软件测试和软件质量保证(SQA)有何区别?
下面我们先简单回答这些问题。即使您不能完全理解也不要急,后面会逐步帮助您解开软件测试之谜。但有一点是明确的,在看完这段“引子”后,您对软件测试会有一个整体的认识,从而不至于陷入“盲人摸象”的困境。
1. 软件测试的作用
在购买商品时,会发现商品上贴有一个“QC”标签,这就是产品经过质量检验(Quality Control)的标志。软件测试就好比制造工厂的质量检验工作,是对软件产品和阶段性工作成果进行质量检验,力求发现其中的各种缺陷,并督促修正缺陷,从而控制和保证软件产品的质量。所以,软件测试是软件公司致力于提高软件产品质量的重要手段之一。
2. 软件测试在SDLC中的位置
在**的软件瀑布模型中,软件测试处在“编程”的下游,在“软件维护”的上游,先有编程后有测试,测试的位置很清楚,但瀑布模型没有反映SDLC的本质,没能准确无误地反映测试的位置。
实际上,测试贯穿整个SDLC,从需求评审、设计评审开始,就介入到软件产品的开发活动或软件项目实施中了。测试人员借助于需求定义的阅读、讨论和审查,不仅能发现需求定义的问题,而且可以了解产品的设计特性、用户的真正需求,进而确定测试目标,准备用例(Use Case)并策划测试活动。同理,在软件设计阶段,测试人员可以了解系统是如何实现的,以及构建在什么样的平台之上等各类问题,这样可以提前准备系统的测试环境,包括硬件和第三方软件的采购,并着手研究如何测试系统,完成系统测**例设计、测试工具的选型或启动测试工具的开发,进一步完善测试计划等。所有这些准备工作,都要花去很多时间,应尽早开展起来。
当设计人员在做详细设计时,测试人员就应直接参与具体的设计、参与设计的评审,找出设计的缺陷。同时,完成功能特性测试的用例,并基于这些测**例开发测试脚本。
在编程阶段就进行单元测试,是一种很有效的办法,可以尽快找出程序中的错误。充分的单元测试可以大幅度提高程序质量,减少开发成本。
软件测试在SDLC中的位置,可以通过图0-1充分地体现出来。软件测试和软件开发构成一个全过程的交互、协作的关系,两者自始至终一起工作,共同致力于同一个目标——按时、高质量地完成项目。

图0-1 软件测试和SDLC的关系

3. 软件测试过程
软件测试的全过程,要经历如图0-2所示的很多个里程碑,其中主要的里程碑有:
产品需求文档(PRD)或市场需求文档(MRD)的评审和签发;
产品规格说明书(Spec)的评审和签发;
测试计划、测试计划书的评审和签发;
测**例的设计、评审和签发;
功能测试;
系统测试;
验收测试。

图0-2 测试全过程的跟踪示意图
4. 软件测试团队的地位
在软件开发中,虽然有很多角色,有各种各样的人员参与,包括项目经理、产品经理、UI(用户界面)设计人员、文档人员等,但*大的两个团队就是测试团队和开发团队(由设计人员/程序员组成),也就是说,在一个软件公司,测试人员和程序员,占有*大比重。当然,有些软件公司,销售人员或客户支持人员也比较多。由此可见,软件测试团队的地位应该是举足轻重的。
5. 软件测试和SQA的区别
如前面所说,软件测试属于软件控制,它和SQA(质量保证)的区别概括起来有4点,见表0-1。

表0-1
项目 软件测试 SQA
工作性质 技术性工作 管理性工作
对象 软件产品(包括阶段性产品) 软件过程
焦点 事后检验 强调预防
范围 在研发(R&D)部门或技术部门 在公司层次,跨所有部门,包括市场、销售、客户服务、行政、后勤、人事等部门 前言2000年刚建立测试团队时,测试人员和开发人员是一种对立的关系,开发人员觉得软件测试是挑他们的毛病,和他们过不去,有一个简单的故事可以说明这一点。当时,条件有限,测试人员和开发人员共享一台小型机服务器,测试人员发现了一个缺陷,告诉了某个开发人员,而他趁测试人员不注意,回到自己的座位上偷偷地修改了代码,处理了那个缺陷,然后跑到测试人员身边说:“你把那个Bug再现给我看看?”结果,可想而知,这个测试人员无论如何也不能复现那个Bug(缺陷)了。 几年以后,这种情况不再出现了,不是因为条件好了,可以买很多服务器,可以将测试环境和开发环境分离开来,而是观念改变了。虽然的确是购买了几百台服务器(不用小型机,越来越多的服务器采用Linux系统),将测试环境和开发环境分离开了,在客观上可以避免那类“悲剧”的发生,但是观念远比机器重要。拥有正确的观念,就比较容易创建良好的质量文化,开发人员的态度也随之发生变化,他们已经深深认识到: 软件测试是帮助自己,测试人员是在找产品定义、设计和实现的缺陷,不是找自己的缺陷,是对事,不是对人; 测试人员越快地发现缺陷,项目越能尽早结束; 测试人员尽可能多地发现Bug,**在产品中的Bug就会越少,产品的质量就会越高; 测试人员和自己(开发人员)的工作都是为了相同的目标——按时、高质量地发布产品; 开发人员的水平越高,所写的程序中的Bug越少,而不在于使用了别人不知道的技巧。 现在,有的开发人员向我抱怨,是不是换了一个新人测试他写的模块?因为这次发现的缺陷比前次发现的少多了。开发人员希望更多的缺陷被测试人员发现出来,绝不希望缺陷被留给客户去发现。 今天,我们高兴地看到开发人员和测试人员心往一处想。从项目启动的**天起到需求和设计的评审阶段,从后期的缺陷修正到产品维护——在整个软件生命周期中,开发人员和测试人员愉快地合作、共同努力,将软件产品的开发效率和质量推到一个新的高度。一方面,开发人员主动介绍自己对产品特性是如何理解的,又是如何实现这些特性的,他们主动邀请测试人员参与代码的走查并对新发现的Bug快速响应。另一方面,测试人员提前将设计好的一些测**例交给开发人员,让开发人员先根据这些测**例验证正在开发的功能特性,测试人员还愉快地帮助开发人员再现某个缺陷。 所有这些,都可以看出软件测试在国内越来越受重视,软件测试领域正迎来朝气蓬勃的新气象。当更多的人投入到测试行业时,需要一本实践性强、富有启发性的专业书,指导大家如何进行测试,出色地完成测试任务。这本《全程软件测试》就承载了这样一个任务,它会从项目启动开始,一步一步地教会大家如何做好测试工作,包括建立测试组、计划测试、设计测**例、选择测试工具、开发测试脚本、执行测试和编写测试报告等。这也是我与大家分享多年来积累的软件测试经验与技术实践,以及不断思考所升华的体会。 为了写这本书,我事先也做了一些尝试,尽量收集大家对软件测试需求的反馈,并在CSDN的个人博客http://blog.csdn.net/KerryZhu上演义了30回的软件测试,受到了大家的好评。也许就因为这个,在CSDN建立博客不到8个月,我的博客就成为当年(2006年)十大*具价值的博客之一。 此前,我曾写过一本《软件测试方法和技术》的教材,这本教材在比较短的时间内印刷了好几次,也颇受欢迎。但那本书在很大程度上是从理论、概念上讲解软件测试的方法和技术的,适合在校学生使用。而这本书重实践、重应用,适合软件公司的测试经理、工程师和想进入软件测试行业的人员学习。 全书共12章,以两个案例为背景,以项目向前发展的实际过程为路线图,全面展开软件测试的思想、流程、方法、技术和*佳实践。全书力求做到方法有效、技术实用,集中讲解实际测试工作,没有单纯地介绍概念,而是将概念准确地穿插在测试进程活动之中。 第1章 介绍测试项目启动后要做好哪些准备,如何掌控项目背景和要素,为制定测试计划打下坚实的基础,包括了解软件的质量需求,深刻理解软件测试和测试过程,以及开发过程之间的关系,并说明如何确定软件测试组长和制定测试规范。 第2章 测试计划是焦点,主要讨论了测试人员在需求评审中的作用,确定软件功能和非功能性的系统测试需求、各个阶段的测试任务,并进行测试范围分析和工作量估计、测试资源需求和团队组建、测试里程碑和进度安排,以及基于测试风险分析制定有效的测试策略。 第3章 从系统架构的审查开始,深入到系统组件设计、设计规格说明书、界面设计和系统部署设计等一系列的审查。在系统部署设计中,详细讨论了系统部署逻辑设计、物理设计、可用性设计、可伸缩性设计和**性设计的验证。 第4章 围绕测试设计展开讨论,先从测**例框架的设计入手,然后逐步涉及测**例的构成、设计方法、评审、功能测**例和系统测**例的设计,其中对各种功能设计方法、故障转移和系统**性的测**例设计作了更详细的介绍。 第5章 测试工具的选择和脚本的开发是本章的主题。在这一章,对测试工具的优势、实现原理等进行了分析,介绍了测试工具选择的标准、评估报告和误区,给出了开源或商业的测试工具的完整解决方案,包括详细介绍了Selenium和Jmeter的使用,*后说明如何进行测试脚本录制、回放、开发和重构。 第6章 展示测试和编程的交互过程,主要经历程序代码的审查、程序的动态测试两个环节。对于白盒测试方法及其应用、单元测试工具等,在这一章作了详细介绍。 第7章 开始进入功能测试的执行阶段,并着重介绍了自动化功能测试的执行,如何优化测试环境的组合,如何有效地创建测试套件和软件缺陷的报告,包括测试执行之前的准备、测试环境的建立和设置、UI测试、回归测试等。 第8章 介绍如何进行国际化测试和本地化测试,包括本地化的功能测试、数据格式验证、UI验证、配置和兼容性验证,以及翻译验证。 第9章 内容是围绕系统测试执行来展开的,进一步让读者了解系统测试,详细分析了负载测试的加载方式、负载参数、执行布局和结果报告,从而更好地理解如何做好性能测试,并相继介绍了Web**性测试、容错性测试、兼容性测试、安装测试等。 第10章 内容相对简单,包括4个方面:验收测试、文档测试、α测试和β测试、产品后继版本的测试。 第11章 内容丰富,涉及测试管理的思想和系统、测**例的管理、测试自动化的管理、缺陷跟踪和分析、测试进度和风险的控制、测试覆盖度和结果分析等。例如单就缺陷分析,就包括缺陷生命周期、缺陷状态的跟踪、缺陷的分析、累计缺陷趋势分析等。 第12章 *后一章是总结和思考,可以让读者认清现实、制定原则,然后用辨证统一的方法去看各种测试方法,如白盒测试方法和黑盒测试方法、静态测试和动态测试、手工测试和自动化测试、有计划测试和随机测试等,从而真正悟出软件测试方法的应用之道。这章还分享了笔者在测试中所积累的大量*佳实践,并以实用的测试成熟度模型作为结尾。 本书*后附有软件测试全景图、完整的项目检查表、软件测试计划通用模板、完整的测试工具列表和代码审查的示范性列表等资料。 由于水平和时间的限制,书中难免会出现错误,欢迎读者及各界同仁不吝指正。 **序翻阅少民的这部新作时,不禁让我想起一位好朋友前几天提到的《叙事谣曲》中“只弯一次腰”的故事:有一次,耶稣带着他的门徒彼得出门远行,在路上发现了一块破烂的马蹄铁,耶稣就让彼得拣起来,不料彼得懒得弯腰,假装没有听见。耶稣没说什么,自己弯腰拣起马蹄铁,用它在铁匠那里换了几文钱,并用这些钱买了十几颗樱桃。出了城,两人继续向前走,沿途都是茫茫的荒野,看不到人烟,也找不到水源。耶稣猜到彼得渴得厉害,就让藏在袖子里的樱桃悄悄掉出一颗。彼得一见,赶紧捡起来吃掉。耶稣边走边掉,彼得也就狼狈地弯了十七八次腰。于是耶稣对他说:“要是你刚才弯一次腰,就不会在后来没完没了地弯腰了。小事不干,就将在更多的小事上操劳。” 这个故事,不同的人有不同的感悟。作为一个软件行业的多年从业者,我很自然就联想到了软件开发过程。软件测试(具体到每一个测**例的实施)正是在庞大复杂的软件产品开发过程中确保软件产品质量的“小事”。软件测试工作繁杂、琐碎又耗时,甚至有时吃力不讨好,这使得许多软件从业者对其不够重视;好多技术人员热衷于编码而不愿从事测试工作这样的“小事”;有些公司认为开发能出成果而测试可有可无,因而非常重视开发但不重视测试;许多国内软件企业存在着漠视测试过程、测试时间不充分、测试计划不细致、测试软硬件资源不足等问题,从而在软件质量控制上存在相当大的问题,以致项目延迟甚至失败。 在软件产业发展的几十年中,软件测试已逐步渗透到各个领域,成为越来越不可或缺的技术成分。例如,以前被认为距离软件技术比较远的汽车工业,现在已把**车制造费用的20%~25%投入到电子设备与软件系统上。由此看来,软件的品质已成为人们日益关注的重中之重。如何找到一种全面的分析方法,来检测软件开发过程中不同阶段的结果,以便尽可能早地系统地保证或提高软件产品的质量和可靠性,从而减少后期“弯腰”的必要性与次数,已成为影响软件企业生产力与生产效率的关键问题。 可喜的是,越来越多的软件公司和管理技术人员在工作中将更多的时间和资源投向了测试方面。很多**企业中开发与测试的人员比例达到了3:1或2:1,许多**的技术人员在从事质量控制和软件测试工作。而国内这几年软件测试人员的短缺和招聘难度的提高从反面证明了软件测试正越来越得到重视。 近年来,软件产业发展正从产品模式向服务模式(Software as a Service,SaaS)转变。 在过去的多年中,WebEx公司一直处于这一浪潮的领导地位。WebEx提供的网络会议服务(Web Conference)被称为改变人们工作方式的技术革命。朱少民先生与他带领的团队非常自豪而荣幸地参与了WebEx产品开发的整个过程,在这个过程中他们夯实了软件测试的理论基础,并积累了丰富的实战经验。 少民从事高校教育及软件开发测试工作多年,并且在美国硅谷工作两年,其经历是很好的理论与实践相结合的典范。与少民共事多年,了解他在软件测���领域的积累,从开始时采用简单、初级的测试方法,一步步发展到今天系统、科学的软件质量管理体系;从手工测试向自动化测试过渡;从几个人的测试小组到几百名测试工程师的大规模团队。现在,是到了将过去的经验教训作一番总结,以其亲身经历为业界同仁指点软件测试的规律与介绍成功实践经验的时候了。 这部《全程软件测试》是少民与其工作团队多年来的经验积累,其中一些观点与见解已经成为WebEx公司的基本工作准则,对软件研发领域有着重要的实质性贡献。本书通过实例全面描述了软件测试的整个过程,覆盖了测试管理的各个重要方面。对测试管理的各个层次和环节做了系统的介绍,包括测试策略制定、风险控制、缺陷跟踪和分析、测试管理系统的应用等,并且更进一步对如何执行本地化测试和国际化测试进行了阐述。作者**聚焦在实践性上,从软件测试项目启动、测试计划开始,深入到测**例设计、测试工具选择、脚本开发,以及功能测试和系统测试等各个步骤,并对它们都作了详细阐述。 让人印象深刻的是本书对软件测试工作中几个看似简单、实际上非常关键的问题作了详细的说明。例如就开发团队模式,作者介绍了以开发为核心,以项目经理为核心,以及“三国鼎立”(以项目经理、开发组长、测试组长为核心)的模式。而“三国鼎立”的测试团队具有独立、权威性地位的概念也是工作经验的总结。相信读者会从实战中体会到作者的深刻用意。 在探索**软件测试与软件开发的过程中,本书覆盖了全面的理论分析和详细的实战阐述,对任何从事软件测试的人员和软件开发人员,以及软件工程相关专业的高校师生,都具有重要的参考价值。希望书中的一些真知灼见对广大读者有所裨益。 李钦敏(Jim Li) WebEx总部工程技术及中国研发**总监 2007年6月于美国硅谷 **语这是一本为软件测试团队创作的融实践性、专业性、思想性和实用性为一体的软件测试书籍。全书以完整测试项目的规划和执行过程为主线,以典型测试项目案例为分析和应用实例,把作者丰富的测试实践经验与具体测试方法和技术总结出来与读者分享。本书适合于指导软件公司测试经理和测试工程师阅读和实践,对准备从事软件测试的从业人员也是****的学习和培训教材。 ——崔启亮 昱达软件科技有限公司 技术与培训总裁 非常欣喜地得知又一本国内原创的软件测试专著问世了,目前国内的软件测试书籍理论偏多,介绍*佳实践的偏少,希望本书能成为软件测试工程师的案头手册,为国内软件测试行业的蓬勃发展添砖加瓦。 ——贺炘 慧灵科技 **测试专家、北京软件行业协会测试工作委员会副秘书长 如果你想通过一本切合实际而不仅仅是纸上谈兵的书来学习软件测试,《全程软件测试》会是一个很好的选择! ——周泽睿 百度**测试工程师 兴趣:模块级测试、性能压力测试、网络编程、算法等 很难得,久未看到如此让人畅快的文章。能将软件工程实践系统地贯穿在一起,并不失理论佐证,这本身就是个胜利。 ——高磊 百度**测试工程师 致力于软件测试前沿理论的探索及其与工程实践的结合 **的测试思想,体现着对人生反思的哲学。从某种意义上说,生活和软件开发一样,要在试错的磨炼中成长。 ——李晓杰 百度测试与项目管理工程师 本书*吸引我的地方在于其真实的项目背景,这对于缺乏丰富实践经验的从业人员来说无疑是*宝贵的材料。 ——周可杉 对外经济贸易大学信息学院在读硕士研究生 研究方向:管理信息系统与电子商务 作者对于测试项目从启动、计划、验证、设计、工具和脚本开发等多个角度由浅入深的介绍,非常有利于初学者对于测试流程的理解。 ——曹辉 某公司软件测试工程师 计算机信息管理专业

前 言
引 子
第1章 测试项目启动
1.1 了解软件的质量需求 2
1.1.1 软件产品的质量需求 2
1.1.2 软件质量的对立面——软件缺陷 5
1.1.3 软件缺陷产生的原因 7
1.1.4 究竟什么是软件测试 8
1.1.5 软件测试的目标 11
1.2 选定测试组长 13
1.2.1 测试过程和开发过程的关系 13
1.2.2 测试组长的人选 15
1.2.3 测试在项目团队中的位置 17
1.3 掌控项目背景 18
1.3.1 软件测试的项目要素 18
1.3.2 两个典型项目的介绍 20
1.3.3客户端软件Google Talk功能简介 21
1.3.4 Web应用——雅虎日历功能介绍 22
1.4 制定测试规范 23
1.5 小结 28

第2章 测试计划
2.1 产品需求文档审查和评审 30
2.1.1需求评审的重要性 30
2.1.2 测试人员在需求评审中的角色 32
2.1.3 需求评审的标准 34
2.2 项目的测试需求和任务 36
2.2.1 确定软件功能测试需求 36
2.2.2 非功能性的系统测试需求 38
2.2.3 软件即服务的测试需求 39
2.2.4 各个阶段的测试任务 41
2.3 测试范围分析和工作量估计 43
2.3.1 功能测试范围的分析 43
2.3.2系统测试范围的分析 46
2.3.3 工作量的估计 48
2.3.4 工作分解结构表方法 49
2.3.5 工作量估计的实例 51
2.4 测试资源需求和团队组建 53
2.4.1 测试资源需求 53
2.4.2 团队组建 54
2.4.3 培训 55
2.5 测试里程碑和进度安排 56
2.6 测试风险分析 57
2.7 制定有效的测试策略 61
2.8 完整生成测试计划书 65
2.9 小结 66

第3章 设计验证
3.1 系统架构的审查 68
3.1.1 系统架构选型的确认 68
3.1.2软件设计评审标准 69
3.1.3 系统组件设计的审查 72
3.2 产品设计规格说明书的复审 74
3.2.1 重视设计规格说明书的审查 74
3.2.2 设计规格说明书的多层次审查 75
3.2.3 界面设计的评审 76
3.2.4 验证过程与确认过程 77
3.3 系统部署设计的审查 78
3.3.1 系统部署逻辑设计的审查 79
3.3.2 软件部署物理设计的审查 80
3.3.3 系统部署可用性设计的审查 82
3.3.4 系统部署可伸缩性设计的验证 85
3.3.5 系统部署**性设计的验证 86
小结 87

第4章 测试设计
4.1 测**例框架的设计 89
4.1.1为什么需要测**例 89
4.1.2 测**例设计考虑因素 90
4.1.3 测**例框架的构成 91
4.1.4 测**例的元素 93
4.2 功能测**例的设计 94
4.2.1 功能测**例的内容 95
4.2.2 功能测**例的设计方法 96
4.2.3 等价类划分法 97
4.2.4 边界值分析法 100
4.2.5 因果图法 104
4.2.6 功能图法 105
4.2.7 错误推测法 106
4.2.8 正交实验设计方法 107
4.3 系统测**例的设计 108
4.3.1 故障转移的测**例设计 109
4.3.2 系统**性的测**例设计 110
4.4 测**例的审查 112
4.4.1 测**例书写标准 112
4.4.2 测**例评审要点 113
4.6 测试套件的创建 115

第5章 测试工具选择和脚本开发
5.1 测试工具的需求分析 119
5.1.1 测试工具的优势 119
5.1.2 测试工具的实现原理 120
5.2 测试工具的选择 124
5.2.1 测试工具选择的标准 124
5.2.2 测试工具评估报告实例 126
5.2.3 测试工具选择的误区 127
5.3 测试工具完整方案之商业版 128
5.3.1 GUI功能测试工具的比较 129
5.3.2 负载和性能测试工具 131
5.3.3 基于Web应用的测试工具 133
5.4 测试工具完整方案之开源版 135
5.4.1 开源测试工具总览 135
5.4.2 Web功能测试工具—Selenium 137
5.4.3 强大的性能测试工具—JMeter 142
5.4 测试脚本录制和回放 145
5.4.1 创建自动化脚本项目 145
5.4.2 录制Selenium脚本 147
5.4.3 用Robot录制客户端测试的脚本 150
5.5 测试脚本的开发 152
5.5.1 适应测试脚本开发的测**例 152
5.5.2 测试脚本的重构和优化 153

第6章 测试和编程的交互
6.1 程序代码的审查 154
6.1.1 代码审查的方法和范围 154
6.1.2 代码风格的审查 156
6.1.3 编程规则的审查 158
6.2 单元测试 160
6.2.1 什么是单元测试 161
6.2.2单元测试的现状和作用 162
6.2.3单元测试的方法 163
6.3 单元测**例的设计 164
6.3.1 语句覆盖法 165
6.3.2 判定和条件覆盖法 166
6.3.4 基本路径测试法 169
6.3.5 多种白盒测试方法的比较和总结 169
6.3.6 循环结构的测**例 170
6.3.7 单元测试的典型实例 172
6.4 单元测试工具 174
6.4.1 静态代码分析 175
6.4.2 测试覆盖率工具EMMA 176

第7章 功能测试的执行

7.1 测试执行概述 180
7.2 测试执行的准备 181
7.2.1 培训和知识传递 182
7.2.2 测试任务安排 183
7.2.3 测试环境的建立 184
7.2.4 测试环境的设置 185
7.2.5 测试自动化运行平台 187
7.3 如何有效地创建测试套件 188
7.3.1 功能测试套件的创建 188
7.3.2 测试环境的爆炸性组合 190
7.3.3 环境组合优化 191
7.4 功能测试自动化的执行 194
7.5 用户界面和适用性测试 197
7.6 回归测试 200
7.6 软件缺陷的报告 202
7.6.1 缺陷的属性 202
7.6.2 缺陷描述的详细描述 205
7.6.3 如何报告缺陷 206
小结 207

第8章 国际化和本地化测试的执行
8.1 国际化测试 208
8.1.1 软件国际化的基本要求 209
8.1.2 国际化测试 212
8.1.3 I18N测试实例 214
8.2 本地化测试 215
8.2.1 软件本地化的质量需求 215
8.2.2 本地化测试的基本内容 217
8.2.3 L10N的功能测试 219
8.2.4 L10N的数据格式验证 221
8.2.5 L10N的UI验证 224
8.2.6 L10N的配置和兼容性验证 225
8.2.7 L10N的翻译验证 226
8.3 I18N和L10N测试工具 228
小结 230

第9章 系统测试的执行
9.1 如何进行系统测试 232
9.1.1 进一步了解系统测试 232
9.1.2 系统测试的实施策略 234
9.2 Web应用服务器的负载测试 236
9.2.1 负载测试的加载方式 237
9.2.2 负载测试的准备工作 238
9.2.3 负载测试的执行 239
9.2.4 负载测试的结果分析 241
9.3 Web应用服务器的性能测试 242
9.4 Web**性测试 244
9.5 容错性测试 246
9.6 数据库的性能测试 247
9.7 兼容性测试 250
9.8 安装测试 253
9.8.1 客户端软件安装测试 253
9.8.2 软件服务模式下的安装测试 255
小结 256

第10章 后续测试
10.1 验收测试 256
10.2 文档测试 259
10.3 α测试和β测试 260
10.4 产品后继版本的测试 261
小结 263

第11章 测试的跟踪和管理
11.1 测试管理 265
11.1.1 测试管理的全局性 265
11.1.2 测试策略的执行 266
11.1.3 测试管理系统的应用 267
11.1.4 测试管理工具 269
11.2 测**例的管理 271
11.2.1 测**例创建的管理 271
11.2.2 测**例执行的管理 273
11.2.3 测**例的维护 273
11.3 测试自动化的管理 275
11.3.1 测试自动化的框架 275
11.3.2 测试自动化的流程 277
11.4 缺陷跟踪和分析 278
11.4.1 缺陷生命周期 278
11.4.2 缺陷状态的跟踪 280
11.4.3 缺陷的分析 281
11.4.4 累计缺陷趋势分析 284
11.5 测试进度和风险的控制 286
11.5.1 测试进度管理 286
11.5.2 测试风险的控制 289
11.6 测试覆盖度和结果分析 291
11.6.1 测试覆盖评估 291
11.6.2 基于软件缺陷的质量评估 293
11.6.3 软件缺陷清除率 294
11.6.4 测试报告的模板、实例 296
小结 298

第12章 总结和思考
12.1软件测试的现实和原则 300
12.1.1 测试的现实 300
12.2 软件测试的多维空间 304
12.3 软件测试方法的应用之道 306
12.3.1 白盒测试方法和黑盒测试方法 307
12.3.2静态测试和动态测试 307
12.3.3 手工测试和自动化测试 308
12.3.4 有计划测试和随机测试 309
12.3.5 新功能测试和回归测试 310
12.3.6 测试方法综合应用的总结 311
12.3.7 测试方法的有效性和风险性 312
12.4 软件测试的*佳实践 312
12.4.1 测试计划的*佳实践 313
12.4.2 测**例设计中的*佳实践 314
12.4.3 测试自动化中的*佳实践 315
12.4.4 测试执行中的*佳实践 319
12.4.5 测试团队建设中的*佳实践 321
12.5 软件测试成熟度模型 323
12.5.1 从CMM/CMMI得到的启发 323
12.5.2 目前TMM存在的问题 325
12.5.3 实用测试成熟度模型的建立 326

附录A 软件测试全景图
附录B 完整的项目检查表
附录C 软件测试计划通用模板(GB8567-88)
附录D 完整的测试工具列表
附录E 代码审查的示范性列表
附录F 软件测试术语中英文对照
附录G LoadRunner和OpenSTA比较分析
参考文献