安排岗位和管理

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

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

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

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

　　数据驱动方法

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

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

　　输入程序的参数

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

　　驱动程序的测试用例序列

　　驱动程序的状态机序列

　　程序读取和操作的文档

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

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

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

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

　　框架驱动方法

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

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

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

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

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

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

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

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

　　24. 被载入框架的函数库的脚本一般应该包括错误检查功能。(一致同意)

　　这是任何类型编程都能得到的好经验，但是对于测试代码尤其显得重要。因为，我们希望我们测试的程序出现问题，并且，为了使报告和排除故障变得容易，我们希望看到失败的最初征兆。

　　25. 当创建共享库命令时，就会出现处理不同编码和文档风格的问题。因为如果人们对某人的代码不满意，他们就不会使用它。(一致同意)

　　26. 在通过包绕函数库创建脚本时，要注意节省时间。与此类似，要注意不要创建单独的一个库。(一致同意)

　　函数库是一个有组织的共享函数储藏区。如果有个函数太全面，需要用户向它传递大量的参数，那么一些程序员(正在做自动化的测试者)就可能会使用他们自己特定目的的较小版本。而有的程序员由于匆忙，不在意检查库中的代码。还有的程序员则不信任库中的代码，因为他们觉得(或许是正确的)库里的大部分东西没有被测试过，存在着bug。

　　27. 应该把测试参数包括在数据文件中，例如.ini文件，设置文件以及配置文件，而不是把嵌入在自动化脚本或含有脚本的文件中的常量包括在内。(一致同意)

　　28. 包裹是一个好东西。要尽可能多的合理使用它们。

　　本地化

　　我们花了很多时间来谈论本地化，并且我们获得了一个让我吃惊的结论。我们很可能在以后的LAWST会议中继续讨论它，但是，如果你被告知，现在对基于GUI的自动化投资能使你在本地化时得到很大回报，那么会议上那些有自动化本地化测试经验的人所表达出的挫折感应该可以给你提个醒。

　　29. 自动化本地化测试的目的是表明先前工作的基线函数仍然可以工作。(一致同意)