Lessons Learned in Software Testing
美 Cem kaner、James Bach、Bret Pettichord著
本书的三位作者具有多年的测试经验，知道成功的测试都需要什么。在这本革命性的新书中，他们汇总了293条测试经验建议，阐述了如何做好测试工作，如何管理测试，以及如何澄清有关软件测试的常见误解。读者可直接将这些经验用于自己的测试工作中。这些经验中的每一条都是与软件测试有关的一个观点，后面是运用这条经验的方法、时机和原因的解释或例子。
第5章 测试自动化
使一部分测试工作自动化可能有帮助，也可能没有帮助，自动化可以节省时间，加快开发，拓展测试员的能力，并使测试更有效；自动化也可以分散测试员的注意力，并浪费资源。
如果自动化能促进测试使命的完成，就利用自动化，评估利用自动化是否成功的标准，是看它在多大程度上
帮助测试员完成自己的使命。
在决定要自动化的内容时，首先设计自己的测试；
采用与设计手工测试不同的方法设计自动化测试；
两条重要的经验：
没有好的测试设计的自动化可能会产生大量活动，但没有什么价值。
没有很好理解自动化可能性的测试设计，可能会低估一些最有价值的自动化机会。
经验102-
加快开发过程，而不是试图在测试上省钱
目标是降低测试成本的自动化工作，很少能够得到为了获得成功所需要的关注和合作。最成功的公司通过自动化测试实现其开发灵活性，他们的自动化测试部分目标是：迅速检测出新版本中的不稳定的变更；
尽可能迅速暴露回归程序错误；
快速报告问题，因为这会使程序错误修改更容易；支持开发节奏的手段的两个例子：1、自动化冒烟测试；冒烟测试又叫版本确认测试；2、自动化单元测试；这些测试也会使测试过程流畅、避免回退，并保持开发动力。单元测试可能要程序员创建。
经验103-拓展测试
领域，不要不断重复相同的测试
以下是几个例子：负载测试；性能基准测试；配置测试；耐力测试；竞争条件；组合错误；
经验104-根据自己的背景
选择自动化测试策略
测试需求：往往只有少量功能是关键的，这些功能必须可靠，可能要求值得将其自动化的大量测试。另外，测试员也可以关注自动化测试能够如何帮助控制产品的主要风险。软件产品体系结构；测试人员技能；
经验105-不要
强求100%的自动化
经验106-测试工具并
不是策略
经验107-不要通过自动化使无序情况更
严重
经验108-不要把手工测试与自动化测试
等同起来
不要拿手工测试与自动化测试相比，而应该把自动化测试看做是对测试员能力的扩充，能够完成手工测试所不能完成的工作。
经验109-不要根据测试运行的频率来估计测试的
价值
测试本身是不可比较的；比较自动化测试的运行成本；
经验110-自动化的回归测试发现
少部分程序错误
非正式调查显示，由自动化测试发现的程序错误百分比令人惊讶地低；自动回归测试在测试开发阶段发现的程序错误比以后执行测试时多。
老功能的新测试也与老测试一样可能发现回归程序错误，并且增加了发现以前
没有发现过的程序错误的优势。
经验111-在自动化测试时考虑什么样的程序错误
没有发现
经验112-
差的自动化测试的问题是没有人注意
测试可能并不完成所想象的工作；测试可能已不再重要；覆盖率可能很差；虚警可能很常见；测试结果可能有错；
经验113-
捕获回放失败
最流行的测试工具包括各种记录器。要在构建能够持久或手工测试结合的自动化测试的技能和规划上投入，与捕获回放相比，这两种测试通常更高效，更有效。
经验114-测试工具也有程序
错误
测试工具常常程序错误更多。要计划测试工具，并花时间找出解决程序错误的方法。有时测试工具会受其他组件中的程序错误的影响。有些工具可能会对正在测试的产品产生很大的影响。
经验115-用户界面
变更
要抽象测试自动化设计的界面。当用户界面变更时，只需升级抽象层，而不是升级访问修改后界面的所有测试。产品GUI抽象的一些手段：窗口映射；数据驱动的自动化测试；任务库；关键词驱动的自动化测试；
基于API的自动化测试；
经验116-根据兼容性、熟悉程度和服务选择GUI测试
工具
经验117-自动回归测试
消亡
自动回归测试所面临的最大问题是退化和过早消亡，
经验118-测试自动化是一种软件开发
过程
经验119-测试自动化是一种重要
投资
自动化测试需要时间和成本。
经验120-测试自动化项目需要程序设计、测试和项目管理方面的
技能：自动化测试的目标、用途，怎么发现程序错误、发现什么错误、需要理解产品的用户领域吗？
编程：测试自动化就是编程，测试自动化并不容易，不遵循软件工程原则是不会成功的。项目管理：如果不重视管理，自动化项目就可能不会实际达到最初预想的目标。
经验121-通过试点验证
可行性
试点有助于展示测试小组的能力，使保证得到全面实施测试自动化的成功所需的资源和协作更容易一些。
经验122-请测试员和程序员
参与测试自动化项目
产品测试员：定义自动化需求、检验自动化可用性、可理解性和可信赖性。产品程序员：是软件开发专家，评审自动化测试的体系结构。可评审行、可维护性、完整性；
经验123-设计自动化测试以推动
评审
1、测试自动化针对自动化测试的代码；2、评审测试代码；
经验124-在自动化测试设计上
不要吝啬
经验125-
避免在测试脚本中使用
复杂逻辑
使测试线性化有助于关注测试的目的，而不是自动支持。
经验126-不要只是为了
避免重复编码而构建代码库
如果把所看到的重复代码都另行存放，最终会得到一种杂烩库。测试自动化有很多重复代码，有用的库应该遵循更强的设计原则，而不只是为了避免重复编码。
经验127-数据驱动的自动化测试更便于运行大量测试
变种
为了通过相同的测试过程测试不同的输入和输入组合，可利用数据驱动的自动化测试。将测试输入和预期输出组织为表，表中的一行对应一个测试，然后创建一个从表中逐行读入的自动化测试过程，执行每个输入步骤，并检验预期结果。
经验128-
关键词驱动的自动化测试更便于非程序员创建测试
关键词驱动的自动化测试建立在数据驱动手段上，但是表中包含指令，而不只是数据。首先，这种方法要求既支持运行测试，又支持设置库、结果分析和报告的一般框架。其次，必须创建一个任务库，封装由被测产品的支持的用户任务。最后，增加对读取电子表格数据的支持，每次读入一行。通常便于非程序员的创建和评审，测试员可以将注意力集中到测试，而不是控制语言上。
经验129-利用自动化手段生产
测试输入
创建大文件、创建大量测试输入、设置测试床、创建随机数据、覆盖所有输入组合、减少所需的测试用例，或者可以描述预期结果。覆盖等价类的所有代表对偶（如果测试所有关键等价类成员的成对组合，可发现大多数交互程序错误）；覆盖逻辑条件中的交互（如果变量不独立，就不能使用类似的全对偶组合测试手段，因果图是一种更健壮的方法）；通过状态模型创建测试场景；
经验130-将测试生成与测试执行
分开
将执行代码与测试数据分开的一种策略是数据驱动的自动化测试，这种分离有利于测试生成，有如下优点：
测试易于理解和评审；可以使用不同的工具或程序设计环境生成和执行测试；独立的测试用例生成器比较容易测试；如果预先生成数据，则更容易重复测试；报告所发现的程序错误更容易；不同的测试专业人员会各自关注自动化测试的不同方面；
经验131-使用
标准脚本语言
经验132-利用编程
接口自动化测试
编程接口更可能提供稳定性，而且还有利于错误检测和隔离。
经验133-鼓励开发单元测试
包
单元测试：程序员所创建的函数、类和方法；
经验134-
小心使用不理解测试的测试自动化设计人员
经验135-
避免使用不尊重测试的测试自动化设计人员
经验136-
可测试性往往是比测试自动化更好的投资
驻留在产品内部提供控制或可视性的测试代码；
经验137-可测试性是
可视性和控制
访问源代码；日志；诊断；错误模拟；测试点；事件触发器；读入老的数据格式；测试接口；定制控制支持；允许多实例；
经验138-
尽早启动测试自动化
经验139-为
集中式测试自动化小组明确章程
经验140-测试自动化要
立即见效
系统配置与准备；辅助诊断；会话记录；测试生成；
经验141-测试员
拥有的测试工具会比所意识到的多
第6章-测试文档
文档是形式化测试过程的一个
重要组成部分，IEEE软件测试文档标准829提供了一种很好的测试文档描述，以及测试文档相互之间和测试过程之间关系的描述。
经验142-为了有效地应用解决方案，需要清楚地理解问题
经验143-不要使用测试文档模板，除非可以脱离模板，否则模板就没有用
经验144-使用测试文档
模板：模板能够促进一致的沟通
经验145-使用IEEE标准829作为测试文档
经验146-不要使用IEEE标准829
经验147-在决定要构建的产品之前先分析需求，这一点既适用于软件也同样适用于文档决定什么内容要包含到测试文档中，什么内容不包含，应该以项目需求为基础。
经验148-为了分析测试文档需求，可采用类似以下给出的问题
清单进行调查
测试小组的使命是什么，测试这个产品的目标是什么？文档无太多用处的话，则没有价值。自己的测试文档是产品还是工具？文档是产品一部分的话，则需要付费。软件质量是受法律问题驱动还是受市场驱动？如果需要管理审查，则需要文档；设计变更有多频繁？变更太频繁，则不要编写大量测试文档。反映设计变更的规格说明变更有多频繁？如果规格说明长期不完整并且过时，不能把测试文档捆绑在这种规格说明的内容上；在测试时，是希望证明与规格说明一致，还是希望证明与客户预期不一致？要采用的测试风格更依赖于预先定义的测试，还是探索性测试？测试文档应该关注要测试什么，还是应该关注怎么测试？文档应该控制测试项目吗？如果文档控制部分测试项目，那么是在项目的初期还是后期进行控制？谁是这些测试文档的主要读者？这些读者有多重要？需要多强的可跟踪性？要反向跟踪哪些文档？谁来控制跟踪？测试文档要在多大程度上支持项目状态与测试进展的跟踪和报告？文档要在多大程度上支持向新测试员指派工作？对新测试员的技能和知识做哪些假设？要使用测试文档记录项目团队的过程，以提供一套别人做测试可依据的产品模型或描述，或给出发现程序错误的结构吗？测试包应该提供预防、检测和预测收益。对于本项目来说，哪一种收益最重要？测试文档的可维护性有多高？这些测试文档在多大程度上能够保证测试变更能够跟上代码变更？测试文档会有助于标识程序风险模式的永久转移吗？
经验149-用简短的语句归纳出核心文档需求
第7章 与程序员交互
经验150-理解程序员怎样
思考
程序员和测试员是在不同的条件下工作的，扮演者不同的角色；测试员了解如何与程序员交互的最好方法，是成为一名程序员，并在一段时间内成员与其它程序员一样的工作。大多数程序员都很专一；程序员关注自己的系统理论；程序设计师一种复杂活动；程序员常常要与各种困难做斗争；很多程序员不喜欢例行工作，常常构建工具和脚本来自动化自己所面临的重复性工作；
经验151-获得程序员的
信任
测试员越早与程序员接触情况就越好。
经验152-提供
服务
主动直接为程序员提供帮助。测试第三方组件；测试非正式个人版本和原型；为程序员建立测试环境；评审需求文档的可测试性；
经验153-测试员的正直和能力需要
尊重
如果测试员发现令人信服的问题，并准确、直接地报告，那么测试员应该得到尊重。当报告问题时，注意下列问题：要干脆的报告问题；将自己的判断建立在产品行为的实际观察基础之上；如果失效是不可重现的，要展示为了重现失效所做的各种尝试；直接报告坏消息；不要假装了解自己并不了解的东西；不要夸张错误报告；如果测试员是正直的，就可以展示自己的能力；
经验154-把关注点放在
产品上，而不是人上
测试员只做自己分内的事；
经验155-程序员喜欢谈论自己的工作，应该
问他们问题
一个很好的切入点是讨论程序员所使用的设计文档；问问题；索要系统框图；测试员的目的是更多的了解在建系统，了解系统可能失败的方式，了解人们构建系统所做的假设；作为测试员，工作就是考虑产品怎样才会失效，作为团队的一员，测试员需要理解在建产品的价值所在。
经验156-程序员
乐于通过可测试性提供帮助
对于测试员来说，可测试性是能够便于测试软件的任何功能。三点注意事项：用程序员的语言谈话；尽早提出要求；要现实；