Lessons Learned in Software Testing
美 Cem kaner、James Bach、Bret Pettichord著
本书的三位作者具有多年的测试经验，知道成功的测试都需要什么。在这本革命性的新书中，他们汇总了293条测试经验建议，阐述了如何做好测试工作，如何管理测试，以及如何澄清有关软件测试的常见误解。读者可直接将这些经验用于自己的测试工作中。这些经验中的每一条都是与软件测试有关的一个观点，后面是运用这条经验的方法、时机和原因的解释或例子。
第8章 管理测试项目
管理测试项目在某些方面与管理任何其他类型的项目一样。测试员的工作是对程序员工作的反映。
经验157-建设一种服务
文化
测试员是为整个项目团队提供服务，典型的服务是发现并报告程序错误。
经验158-
不要尝试建立一种控制文化
经验159-要发挥
耳目作用
测试员在公司中的权力建立在自己的调查技能和自如沟通的基础上，而不是建立在命令链上，因为测试员在项目团队的命令链中的位置并不很高。测试员必须评估自己公司的文化，要在不被解雇或排斥的限度内发挥作用，在这个限度内，我们建议测试员要称为能够为别人带来价值的守信用、高度正直的信息提供者，以此来施展和扩大自己的影响力。
经验160-测试经理管理的是提供测试服务的
子项目，不是开发项目
测试工作是整个项目的一个子项目，要申请资源并提供服务。项目经理在如何运作测试项目上有很大的控制权，应该仔细选择自己的管理风格，从而与项目经理的管理风格协调。
经验161-所有项目都会
演变，管理良好的项目能够很好地演变
每个项目的整个过程中，测试经理都应该准备对整个计划的大小细化或更正。项目就是一组任务，随着时间的推移，项目团队会发现有些任务比预期的要困难，或要花费更长的时间，有些任务还不能完成，有些任务与前一周相比，对市场开发经理或者客户来说很紧迫，此外，每次测试员提出一份错误报告时，都会在大堆的任务中再增加一项。
经验162-总会有很晚的
变更
所有项目管理方法都必须处理变更
需求实在我们想要和我们能够得到的功能之间进行不断斗争的结果。随着项目的展开，需求会有变化。
经验163-项目涉及功能、可靠性、时间和资金之间的
折中
项目经理的任务就是按时并在预算限度内支付一组合适的功能，达到合适水平的可靠性。这是一种具有挑战性的折中。
经验164-让项目经理
选择项目生命周期
生命周期模型是从最初考虑构建这种产品，到向公众发放并投入使用为止，产品设计和开发过程的描述。有些公司遵循标准生命周期模型，但是根据我们的经验，项目经理总是有一定的定制余地。明智的项目经理
会挑选能够流畅地控制自认为很难管理的方面的方法，而预留出自己特别有能力解决的方面。
经验165-瀑布生命周期把
可靠性与时间对立起来
瀑布模型是一种描述按阶段推进项目管理的具体生命周期方法。这些阶段包括：问题定义；需求定义；内部和外部设计；编码；测试；安装；安装后支持；失望客户的法律诉讼；问题定义（针对产品的下一个版本）；软件项目有大量的风险。总会有很晚的变更。在瀑布模型下，到测试员得到代码时，所有功能都已经设计，且大部分或所有功能都已经编码，大部分软件开发经费已经支出。关键的折衷要素是时间和可靠性。
要么修改错误而晚一些交付产品，要么较快交付产品，但是有较多错误。这是项目经理和测试员之间的经典争持：要交付错误很多的产品，还是延迟交付。
经验166-进化生命周期把
功能与时间对立起来
在软件开发进化方法中，项目团队每次增加一个功能，他们设计该功能、编码、测试，并更正其错误。如果这个功能的产品满足了项目团队的质量标准，他们就会增加下一个功能。今天的版本和下个月的版本
之间的差别是下个月的版本有更多的功能。这两个版本都能使用，不存在项目结束时的时间和可靠性之间的折中考虑。
经验167-愿意在开发初期将
资源分配给项目团队
可以评审需求文档的可理解性、可测试性和模糊性；随着项目工作制品的开发，再对他们进行测试，不要等到真个产品完成才测试；推动代码评审；代码评审是收效很大的一种质量改进工作。拟定硬件配置和准备购置或借用设备的初步清单；要求提供可测试性的功能。准备测试自动化；研究测试工具；如果可能，订购用于被测软件的外部开发的测试包；了解产品的市场和竞争情况；
经验168-合同驱动的开发
不同于寻求市场的开发
在合同驱动的项目中，测试员的主要活动是对一组规格说明测试软件；在寻求市场的项目中，测试员更可能根据不同客户的预期，来研究和测试产品；
经验169-要求
可测试性功能
越早提出可测试性功能要求，程序员和项目经理越有可能把它列入预算和进度计划。
经验170-
协商版本开发进度计划
制定版本进度计划，内容包括测试小组接受软件的频度，对提交的被测试软件的要求，以及在最近版本中发现的程序错误如何在新版本中重现。
经验171-了解程序员在
交付版本之前会做什么（以及不会做什么）
有些编程小组会做大量的单元测试，有些没有；有些会把冒烟测试作为其开发的一部分，有些没有；不要指望他们完成或不完成某种类型的测试，也不要指望对交付给测试员的版本做各种准备。
经验172-为被测版本做好
准备
当被测版本就绪时测试环境也应该就绪，这一点很重要。
经验173-有时测试员应该
拒绝测试某个版本
偶尔测试员也会回绝某个版本，拒绝测试。理由1、由于这个版本中应该加入某个关键功能，但是测试员发现没有加，或马上失效；2、以前正常的关键功能现在不能正常使用了，测试小组的冒烟测试应该发现这种失效，当冒烟测试失败后，一般都要拒绝该版本。3、如果收到一个版本，并且已经另一个版本在几个小时之后就会完成；一般来说，如果会使测试工作不能得到明显收益的情况下效率受到很大影响，或对某个版本的测试结果会被忽略，则应该拒绝该版本的测试。
经验174-使用
冒烟测试检验版本
冒烟测试或接受测试是一种测试包，目标是检查版本的基本功能。如果该版本没有通过，则可宣布该版本不太稳定，不值得测试。
经验175-有时正确的决策是
停止测试，暂停改错，并重新设计软件
如果不管进行了多少次程序错误的修改，在同一位置总发现问题，或不管对用户界面做了多少小修改，仍然存在使用户困惑的问题，也许应该停止测试并对有关代码进行调试。这部分内容可能需要重新设计或重写；
经验176-根据实际使用的开发实践
调整自己的测试过程
除非程序员向测试员提供完整的规格说明，建议测试员拒绝测试产品。这是很糟糕的建议。我们建议不要改变程序员的工作方式。
经验177-项目文档是一种有趣的
幻想：有用，但永远不足
即使对于试图充分描述产品的项目团队，开发文档也和想象有很大差别。不要对抗这个事实，这是一个基本问题。
经验178-测试员除非要用，否则不要
索要
如果要求提供规格说明就要使用它，否则以后他们不会向测试员提供任何材料；
经验179-
充分利用其它信息源
如果没有人向测试员提供规格说明，测试员还有很多其它的信息源可以帮助。以下是补充规格说明所没有提供的信息：用户手册草稿；产品市场开发文献；市场开发人员向管理层推销产品概念的演讲；程序软件变更的备忘录；内部备忘录；已出版的风格指南和用户界面标准；已出版的标准；第三方兼容的测试包；已出版的规定；错误报告；程序逆向工程；与人员面谈；头文件、源代码、数据库的表定义；第三方的规格说明和问题清单；原型以及针对原型的所有试验记录；前一个版本的客户电话记录；可使用性测试结果；B测试结果；常见错误；兼容产品；与仿制的产品进行比较；内容参考材料；
经验180-向项目经理提出
配置管理问题
程序错误修复损坏产品中的其它功能，或使得以前解决了的问题再次出现的可能性有多大？对于不同的公司和项目团队，出现副作用的可能性有很大不同。不管是那种情况，都要与项目经理讨论这个问题，并要求提出解决意见。如果这个问题还得不到解决，在状态报告中说明需要高级别的回归测试。
经验181-程序员就像
龙卷风
程序员就像龙卷风，把他们看做是一种自然力量。程序员会按照自己的方式做，而且在不同的公司中程序员的工作方式也有很大不同，测试经理应该相应地设计自己的实践。
经验182-好的测试计划
便于后期变更
如果后期变更是不可避免的，那么测试经理的责任是设计能够适应后期变更的测试过程。不要在测试之前开发大的测试包，而是在需要测试包时再开发；不要编写维护成本很高的大量测试文档；不要把手动或自动化测试捆绑到特定的用户界面；通过最大化可维护性和跨平台可移植性来设计自动化测试；构建一组能够在不同程序中重复使用的通用测试；构建一组很强的冒烟测试，以快速检测被测软件中的基本失效；慎重考虑使用极限编程法开发自动化的测试；开发一种产品用户和用户要通过产品获得效益的模型；帮助程序员开发大的单元测试包；
经验183-只要交付工作制品，就会出现测试
机会
任何时候产品的任何部分可以提交评审，测试机会都会出现，通过这种方式可以把测试融入到产品的整个开发过程中。只要工作制品已经能够完成，都要尽快测试。
经验184-要多少测试才算
够？这方面还没有通用的计算公式
不要费心寻找计算公式，还是英爱多开动脑筋。
经验185-
足够测试意味着有足够的信息可供客户做出好决策
当有理由相信产品任由有重要的未发现的问题可能性很低，就可以停止测试。判断测试是够足够好有多种因素：知道发现的重要问题的种类；知道产品的不同部件如何表现出严重问题；对产品做了与这些风险相应的检查；测试策略具有合理的多样化；使用了所有可用的资源进行测试；满足客户期望满足的所有测试过程标准；尽自己的可能，清晰地表示测试策略、测试结果和质量评估。交付之后可能会有大的问题有以下原因：测试员不想按照自己想象的那样了解风险的动态；测试员在测试中出现错误；风险评估是正确的，管理层决定冒风险；在测试中遗漏问题不算问题，粗心、不认真思索或不通过实践吸取教训才是问题。
经验186-不要只为
两轮测试做出预算
第一轮会暴露问题，第二轮检查所有错误修改，但是产品测试不得不进行的次数也许比两次多得多。
经验187-为一组任务确定进度
计划，估计每个任务所需的
时间
列出任务清单，估计所需的总时间，但是做起来难。列出任务并不是简单的事，因为很容易遗漏任务或低估任务范围；尝试其他估计问题的方法：测试员完成过类似的项目，可以类推；了解程序的长度和复杂度，了解当前公司将程序长度和复杂度与测试时间关联起来的数据为基础的模型，则使用这种模型导出估计值；了解有关的风险，针对风险测试需要什么，最终估计时间；一些其它因素会影响测试员的估计。
经验188-承担工作的人应该告诉测试经理完成该任务需要
多长时间
如果要使估计更有意义，可收集承担该任务的员工所做的估计并进行统计。
经验189-在测试员和开发人员之间没有正确的
比例
经验190-调整任务和不能胜任的
人员
不同的测试员都有不同的强项，要鼓励测试员承担风险并扩展自己的能力，测试经理要尽可能提供指导，但是要关注测试员的进步。不要让测试员承担不适合的工作。
经验191-
轮换测试员的测试对象
不要让测试员自始至终对某个项目的同一组功能进行测试。首先，大多数测试员赶到厌烦；其次，测试员太专；第三，如果专家离开，会留下很大知识漏洞；第四、最重要的，两个测试员会以不同方式分析同样的功能，他们会使用不同的查错理论，创建不同的测试，并发现不同的缺陷。
经验192-尽量
成对测试
测试员结成对子，一起工作，常常等于熟练的差错高手；测试时一种思想生产活动，而不是计划实现活动，测试是一种在开放的多维空间中启发式探索过程，成对测试有利于每个测试员解放思想，并对其做出反应。成对测试有助于两个测试员始终关注任务，更容易重现和分析程序错误。
经验193-为项目指派一位问题查找
高手
问题查找高手是经验丰富、热心探索的测试员。问题查找的一些方式：对有怀疑的部分进行初步探索式测试，形成更细致地跟踪的想法，这个可以让经验不足的测试员执行；探索被认为是风险很低的部分；定位看起来很容易引起不可重现问题的关键部分；找出关键程序错误，以说服项目经理推迟发布日期；
经验194-确定测试的
阶段计划，特别是探索式测试的阶段计划
确定60-90分钟内要做什么，我们把这叫做阶段计划；这种方法的好处是有助于测试员集中注意力。阶段目标可以包括要测试什么，要使用什么工具，使用什么测试技术，有什么风险，要寻找什么程序错误，要研究什么文档，需要什么结果等。
经验195-
分阶段测试
保护阶段的完整性，在一个阶段中，测试员要进行专题测试。
经验196-通过活动
日志来反映对测试员工作的干扰
如果认为不需要保护自己的测试免受频繁中断，可以记录一两周的活动。为了解决看起来生产率有问题的测试员，了解需要大量加班才能完成任务的测试员的实际问题，活动日志是有助于将注意力集中到任务并对任务划分优先级的有效办法。
经验197-
定期状态报告是一种强有力的工具
测试小组的真正力量来自沟通，不是监管。注意永远使用中性、客观的语气；不要针对具体的某人；采用所有项目都一致的格式；按照标准进度计划提交报告；仔细地选定状态报告的内容；要把状态报告提交给项目团队之外的人看。
经验198-再也没有比副总裁
掌握统计数据更危险的了
在报告状态时，应该知道自己在统计什么数据，谁将看到这些数据；根据定义，度量就是整个图片的一小片，将整个图片压缩为少量数据的度量是一种很大的简化。我们利用度量帮助了解项目的进展情况，以及产品各个方面的质量情况。
经验199-要小心通过程序错误数
度量项目进展
程序错误数是一种度量项目进展的很好参数。但是程序错误数是不充分的，并且常常产生误导。程序错误数不能用来说明产品已经接近发布时所要求的质量，不赞同把程序错误到达率作为项目管理依据的统计模型，因为没有理由相信这种方法核心的概率模型假设符合项目的实际情况。
经验200-使用的覆盖率度量越
独立，了解的信息越多
可以在多个元素上度量产品已经完成的测试量：程序错误、需求、代码、配置、变更历史、开发人员、测试员、数据等，单独测试任何一个元素都是不够的；
经验201-利用综合记分牌产生
考虑多个因素的状态报告
最好的状态报告反映多个因素的参数，不是单一、平凡的数字向管理层提供信息，但是信息模式的表示要足够简单，以便指导决策；
经验202-以下是周状态报告的推荐
机构
可以把状态报告看做四页长的文档；第一页列出关键问题，如所需的决策、所需的程序错误修改、预期的交付的工作制品、意外问题；第二页描述测试小组完成计划任务进展的情况；第三页提供错误报告
统计数字；最后一页列出本周被推延的程序错误，清单可以只包括程序错误数、总数、严重程度；
经验203-项目进展表是另一种
展示状态的有用方法
向项目团队所有成员和与该项目有关的任何人公开，直观地展示项目的进展情况。
经验204-如果
里程碑定义的很好，里程碑报告很有用
如果公司要在每个里程碑处评估产品，那么测试经理需要知道应对照什么进行评估。
经验205-
不要签署批准产品的发布
要让项目经理或者项目团队确定什么时候发布产品；
经验206-
不要签字承认产品经过测试达到测试经理的满意程度
产品经过了充分测试，完成了约定程度的测试，或在可用的时间内尽力做了最好的测试。
经验207-如果测试经理要
编写产品发布报告，应描述测试工作和结果，而不是自己对该产品的看法只描述自己知道的东西；
经验208-在产品最终发布报告中列出没有排除的程序错误应附上产品中未排除的程序错误的
清单。
经验209-有用的发布报告应列出批评者可能指出的10个最
糟糕的问题
第9章 测试小组的管理
本章考虑的是一个项目接一个项目、年复一年地一起工作的员工组成的小组。
经验210-
平庸是一种保守期望
不要扼杀员工的创造性；不要是员工成为不能互换的齿轮；不能标准化员工；要以创造性、可说服性、判断力、人际敏感性等评价自己的员工；不能将员工与工作结果剥离；
经验211-要把自己的员工当做
执行经理
大多数测试员都是执行经理，以此为基础进行管理；接受测试员具有不同的强项和兴趣，并有针对性管理；
经验212-
阅读自己员工完成的错误报告
阅读程序错误报告，有助于测试经理了解产品情况，自己员工的强项和品德，以及影响自己员工的沟通和人际问题；针对报告，可能有一些问题：报告写的好吗？直率地提出问题了吗？留下迫切要求后续测试的漏洞了吗？发现程的错误是例行公事还是很有见地？程序错误很难发现吗？错误出现在比较稳定的部分吗？报告的语气怎么样？程序员能够理解吗？
经验213-像
评估执行经理那样评估测试员
不要仅仅把程序错误数做为一种度量；建议可以参照以下：错误报告、编写的代码、编写的测试文档、与其一起工作的程序员和其它有关人员的意见；鼓励测试经理积极、随时地跟踪员工的工作。
经验214-如果测试经理确实想知道实际情况，可与员工一起
测试
经验215-不要指望别人能够
高效地处理多个项目
有些人会接受多项任务，但是在特定的一周内，他们只能承担这些工作中的一项；积极地承担所有被分配的任务的测试员会把时间分得很碎，要在管理方面花很多时间。
经验216-
积累自己员工的专业领域知识
可以通过多种途径积累真正的专业领域知识：阅读面向类似产品客户的杂志和书籍；参加教授客户如何使用本公司开发产品的培训班；参加与产品的下层主题有关的学习班；在客户现场工作；推销自己公司或竞争对手的软件；回答公司技术支持热线电话；
经验217-积累自己员工相关技术方面的
专门知识
经验218-积极
提高技能
对于强化测试小组在公司中的价值极有帮助；
经验219-
浏览技术支持日志
思考为了某类投诉减少自己可以做些什么；思考什么类型的测试会助于发现被测软件中类似的一些问题；
经验220-
帮助新测试员获得成功
为测试员找好地方；至少安排一天时间与有关人员见面；为新测试员指派一位指导者；
经验221-让新测试员
对照软件核对文档
全面测试手册和在线帮助是很值得的；测试员应该核对所有事实描述和程序测试；
经验222-通过
正面测试使新测试员熟悉产品
尝试简单但是实际的方式使用该产品；帮助测试员理解该产品或产品版本的优点；
经验223-让测试新手在编写新错误报告之前，先
改写老的错误报告
一种方法是让其重新测试老程序错误，并改写出更有效的错误报告。
经验224-让新测试员在测试新程序错误之前，先
重新测试老程序错误利用三类任务，可以帮助测试员了解被测产品、产品怎么样失效、怎么测试产品等。重现现在还没有关闭的程序错误；重新测试已经解决的程序错误；重新测试已经解决但还没有关闭的程序错误；
经验225-
不要派测试新手参加几乎完成的项目
经验226-员工的
士气是一种重要资产
礼貌对待员工、尊重员工；注意他们的工作；称赞好的工作、热心和诚实努力；员工加班，测试经理也要加班；为员工指派他们感兴趣的任务和项目；测试任务不顺利，则指派别人指导、帮助；提供培训机会；
公平对待员工；不要对任何一位员工产生误导；不要与员工叫喊；避免公开批评；不要与员工私下议论其它小组的员工；测试经理不要与员工约会；
经验227-测试经理不要让自己被
滥用
不要为了过度工作而搞垮自己和整个团队；不要承诺不可能做到的事；
经验228-
不要随意让员工加班
避免让测试员长期加班；制定项目进度计划时，不要指望员工每天8小时集中在工作上，这不现实；不要同意自己知道的不现实的进度计划，尽可能准确估计完成不同任务需要多长时间；
经验229-
不要让员工滥用
提供精神支持，解决各种不公正待遇；礼貌处理表现不当的测试员；
经验230-
创造培训机会
经验231-
录用决策是最重要的决策
经验232-在招募期间利用承包人
争取回旋余地
经验233-
谨慎把其它小组拒绝的人吸收到测试小组中
经验234-对测试小组需要承担的任务，以及完成这些任务所需的技能做出
规划
经验235-测试团队成员需要有不同
背景
经验236-录用
其它渠道的应聘者
经验237-根据大家意见
决定录用
经验238-录用
热爱自己工作的人
经验239-录用
正直的人
经验240-在面谈时，让应聘者展示期望有的
技能
经验241-在面谈时，请应聘者通过
非正式能力测验展示其在工作中能够运用的技能
经验242-在录用时，要求应聘者提供工作
样本
经验243-一旦拿定主意就
迅速录用
经验244-要将录用承诺形成文字，并遵守
诺言