使一部分测试
工作自动化可能有帮助，也可能没有帮助，自动化可以节省时间，加快开发，拓展测试员的能力，并使测试更有效；自动化也可以分散测试员的注意力，并浪费资源。
如果自动化能促进测试使命的完成，就利用自动化，评估利用自动化是否成功的标准，是看它在多大程度上帮助测试员完成自己的使命。在决定要自动化的内容时，首先设计自己的测试；
两条重要的经验：
没有好的测试设计的自动化可能会产生大量活动，但没有什么价值。
没有很好理解自动化可能性的测试设计，可能会低估一些最有价值的自动化机会。
经验102-加快开发过程，而不是试图在测试上省钱
目标是降低测试成本的自动化工作，很少能够得到为了获得成功所需要的关注和合作。
最成功的公司通过自动化测试实现其开发灵活性，他们的自动化测试部分目标是：
迅速检测出新版本中的不稳定的变更；
尽可能迅速暴露回归程序错误；
快速报告问题，因为这会使程序错误修改更容易；
支持开发节奏的手段的两个例子：
1、自动化冒烟测试；冒烟测试又叫版本确认测试；
2、自动化
单元测试；这些测试也会使测试过程流畅、避免回退，并保持开发动力。
单元测试可能要程序员创建。
经验103-拓展测试领域，不要不断重复相同的测试
以下是几个例子：负载测试；性能基准测试；配置测试；耐力测试；竞争条件；组合错误；
经验104-根据自己的背景选择自动化测试策略
测试需求：往往只有少量功能是关键的，这些功能必须可靠，可能要求值得将其自动化的
大量测试。另外，测试员也可以关注自动化测试能够如何帮助控制产品的主要风险。
软件产品体系结构；测试人员技能；
经验105-不要强求100%的自动化
经验106-测试工具并不是策略
经验107-不要通过自动化使无序情况更严重
经验108-不要把手工测试与自动化测试等同起来
不要拿手工测试与自动化测试相比，而应该把自动化测试看做是对测试员能力的扩充，能够完成手工测试所不能完成的工作。
经验109-不要根据测试运行的频率来估计测试的价值
测试本身是不可比较的；比较自动化测试的运行成本；
经验110-自动化的回归测试发现少部分程序错误
非正式调查显示，由自动化测试发现的程序错误百分比令人惊讶地低；自动回归测试在测试开发阶段发现的程序错误比以后执行测试时多。老功能的新测试也与老测试一样可能发现回归程序错误，并且增加了发现以前没有发现过的程序错误的优势。
经验111-在自动化测试时考虑什么样的程序错误没有发现
经验112-差的自动化测试的问题是没有人注意
测试可能并不完成所想象的工作；
测试可能已不再重要；
覆盖率可能很差；
虚警可能很常见；
测试结果可能有错；
经验113-捕获回放失败
最流行的测试工具包括各种
记录器。要在构建能够持久或手工测试结合的自动化测试的技能和规划上投入，与捕获回放相比，这两种测试通常更高效，更有效。
经验114-测试工具也有程序错误
测试工具常常程序错误更多。要计划测试工具，并花时间找出解决程序错误的方法。有时测试工具会受其他组件中的程序错误的影响。有些工具可能会对正在测试的产品产生很大的影响。
经验115-用户界面变更
要抽象测试自动化设计的界面。当用户界面变更时，只需升级抽象层，而不是升级访问修改后
界面的所有测试。产品GUI抽象的一些手段：窗口映射；数据驱动的自动化测试；任务库；关键词驱动的自动化测试；
基于API的自动化测试；
经验116-根据兼容性、熟悉程度和服务选择GUI测试工具
经验117-自动回归测试消亡
自动回归测试所面临的最大问题是退化和过早消亡，
经验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-测试员拥有的测试工具会比所意识到的多
