24. 被载入框架的函数库的脚本一般应该包括错误检查功能。（一致同意）
这是任何类型编程都能得到的好经验，但是对于测试代码尤其显得重要。因为，我们希望我们测试的程序出现问题，并且，为了使报告和排除故障变得容易，我们希望看到失败的最初征兆。
25. 当创建共享库命令时，就会出现处理不同编码和文档风格的问题。因为如果人们对某人的代码不满意，他们就不会使用它。（一致同意）
26. 在通过包绕函数库创建脚本时，要注意节省时间。与此类似，要注意不要创建单独的一个库。（一致同意）
函数库是一个有组织的共享函数储藏区。如果有个函数太全面，需要用户向它传递大量的参数，那么一些程序员（正在做自动化的测试者）就可能会使用他们自己特定目的的较小版本。而有的程序员由于匆忙，不在意检查库中的代码。还有的程序员则不信任库中的代码，因为他们觉得（或许是正确的）库里的大部分东西没有被测试过，存在着bug。
27. 应该把测试参数包括在数据文件中，例如.ini文件，设置文件以及配置文件，而不是把嵌入在自动化脚本或含有脚本的文件中的常量包括在内。（一致同意）
28. 包裹是一个好东西。要尽可能多的合理使用它们。
本地化
我们花了很多时间来谈论本地化，并且我们获得了一个让我吃惊的结论。我们很可能在以后的LAWST会议中继续讨论它，但是，如果你被告知，现在对基于GUI的自动化投资能使你在本地化时得到很大回报，那么会议上那些有自动化本地化测试经验的人所表达出的挫折感应该可以给你提个醒。
29. 自动化本地化测试的目的是表明先前工作的基线函数仍然可以工作。（一致同意）
推荐阅读：
30. 如果对国际化的有组织规划已经完成，测试团队也已经人工检查了所有字符串的译文（我们不认为这也可以被自动化），并且，他们还人工检查了因本地化而变更的具体函数（我们也不认为这项工作可以被自动化），那么仅仅只需要一小套自动化测试来检查本地化的有效性。自动化仅仅提供了一个合乎逻辑的检查级测试。如果超出这个，我们只能依靠本地用户的实际使用和手动测试。（7票赞成，1票反对）
31. 如果基线测试和使能测试足够强大，那么除了一小部分被仔细挑选后的脚本外，使测试脚本跨越语言的努力的边际报酬几乎为零。（5票赞成，0票反对）
32. 如果没有为可译性做早期设计就在事后进行翻译/本地化，那么我们只有对所有的东西进行彻底的再测试。（一致同意） 这时，基线语言自动化脚本就体现出很重要的价值。
33. 我们不赞成下面的说法：按照基线版本中的样子回归本地化版本中的所有bug，以及通过扩展自动化测试为每种语言建立相同的基线版本都很重要。（7票反对，1票赞成）
34. 在规划良好的本地化过程中，可能会增加一些不容易被基线回归测试探测到的bug。（9票赞成，0票反对）
35. 我们没有对下面的观点投票，但是我还是在这里列出它们，因为它们能引起思考和讨论（还因为我认为Marick的想法在正轨上）。Brian Marick建议在规划自动化本地化测试时，应该考虑一些可区别种类的测试。下面是一些例子：
· 语言独立的自动化测试，例如（在很多但不是所有情况下），打印机配置测试，其它配置/兼容性测试，以及不同纸张大小的兼容性测试。
· 如果觉得值得的话，可以使用特定语言的自动化测试。如果你希望继续出售新产品的法文版、德文版以及西班牙文版，你会发现创建法文、德文以及西班牙文自动化测试是很有价值的。
· 特定语言的大多数测试有可能被手动本地化测试处理好。
· 特殊国际化测试能够被自动化。这些测试将检查软件的译本和本地化情况。例如，你可以用很长或很短的字符串提供虚假译文。你也可以提供不同国家中用不同连字符连接的文本。
· 简易本地化测试。Marick希望这是一类小型测试。但是，一些测试并不与字符串或屏幕显示有关。例如，强力测试能否找出内存泄露取决于一些函数的反复执行，而这与显示文本和图形没有关系。把这类测试按照使它们可用的最低程度本地化来将会很容易。
本地化的底线是，即使你为一个英文版产品创建一个自动化测试扩展套件，它也能够让你非常迅速地测试一个译本。
