安排岗位和管理

　　15. 从发行版N（比如发行版3.0）的自动化工作中得到的大部分收益往往在发行版N+1中才能实现。但也有例外，即你在某些情况下，可以获得自动化工作的近期回报。例如烟雾测试、一些强力测试（有些强力测试只有你使用自动化后才能实现）、以及配置/兼容性测试。（一致同意）

　　16. 如果发行版N是你使程序自动化后的第一个发行版，那么你的发行版N的首要目标就是要为发行版N+1中的自动化编写提供支持。而你的次要目标就是轻量而有目的的测试发行版N。（一致同意）

　　17. 人们需要重视自动化，而不是把它视为无关紧要的任务。如果没有人专门从事这项任务，那么自动化工作将是浪费时间。（一致同意）

　　18. 很多测试人员是初级程序员，他们并不知道怎样构架和创建设计良好的框架。（一致同意）

　　数据驱动方法

　　数据驱动方法在主体部分已经论述过了。我相信我们都喜欢数据驱动方法，但是我们中没有一个人能在每一种可能的情况下都使用数据驱动方法。下面是会议中提出的一些具体的额外事宜。

　　19. 数据驱动自动化策略的主旨（数据）可以包括以下几个方面：

　　输入程序的参数

　　程序执行的操作或命令序列

　　驱动程序的测试用例序列

　　驱动程序的状态机序列

　　程序读取和操作的文档

　　系统模型（例如状态模型或因果图模型）指定的参数或事件。（一致同意）

　　20. 数据驱动方法具有高度可维护性，并且易于非编程人员使用。（一致同意）

　　然我们原则上都同意以上观点，但是我们还是能举出组织不好或思考不周的测试矩阵。如果你的设计工作做的不好，那么没有人会理解并维护你做的东西。

　　21. 有多个接口可以把数据输入到数据文件中，以驱动数据驱动测试。你可以选择一个，或者为不同需要和技术的测试者提供不同的接口。（一致同意）

　　框架驱动方法

　　在一段时间里，对框架的讨论变成了讨论设计过程语言以及良好实现过程语言的延伸。我们对此变得厌倦了，觉得已经有人在以前解决了这类问题，并且我们已经从我们的协议列表中删去了这个议题。我省略了沿着这条思路下去的多数要点。以下是一些针对框架的建议：

　　22. 是否开发框架取决于你的员工的数量和熟练程度。（一致同意）

　　23. 创建一个框架时，要注意你在哪个级别上创建函数。例如，你可以考虑下面三种级别之一：

　　菜单/命令级，执行简单命令

　　对象级，对具体事物实行操作

　　任务级，负责具体的经常反复执行的任务

　　你会发现主要在一个级别上工作是高效的。所以，只有当你明确了需要在其它级别上添加测试用例后，才可以这么做。

　　还有很多定义和区分级别的其他方法。而无论用什么方法，分析任务总是合适的。这里要注意的是，需要避免随意地从创建十分简单的测试变成创建特别冗长复杂的测试。（一致同意）