如何提高自动化测试套件的可维护性？

用于自动化测试的值是不确定（比如随机）的尽管我们需要确定测试用例的方法。（一致通过）

我们不确定盲目测试。需要知道运行的是什么测试，有时候你需要输入严格的和一定顺序的输入。但是如果你决定是否程序是正在运行通过的测试，你都要不断用大量的测试用例替换那些已经运行成功的测试用例。

我们需要设计纪录测试用例运行日志的能力。（一致通过）

一些测试工具使纪录测试工程变得简单，一些变得复杂。调试跟踪测试过程，你可以很快看到测试用例运行的状态和返回值。

人力和管理

自动化工作所作的努力在版本n，在版本n+1发布的时候将得到更多的好处。在你能达到短期回放目标的情况下，对这个真实性存在异议。例子中包括冒烟测试，压力测试（一些压力测试只能用自动化实现），配置/兼容性测试。（一致通过）

如果版本n是自动化开始测试的版本，那么你基本目标是可以在版本n+1中写稳定的自动化脚本。你的第二个目标是容易实现的除了把在版本n中测试作为目标。

人们需要重视自动化而不是吧她作为次要目标。如果没有人投入到自动化中，那么自动化可能就是浪费时间。（一致通过）

很多测试人员没有什么编程经验，他们不知道如何建立和好的设计框架。（一致通过）

数据驱动方法

本篇文章主要描述了数据驱动。我认为谈论我么喜欢的数据驱动方法是保险的，但是我们中没有人在每个可以想象的情况下用数据驱动方法。附加部分，会议详细的备注。

数据驱动策略的主题包含（举例）：

输入程序的参数

执行程序的操作顺序和命令

驱动程序运行的测试用例顺序

驱动程序运行的机器状态顺序

文档记录程序读取和操作

由系统模型指定参数和事件（比如状态模型或者基于模型的图表）（一致通过）

数据驱动维护量很小而且对于非编程人员很容易使用。（一致通过）

尽管我们同意这些原则，但是我们有杂乱或者简单思考的测试矩阵例子等等。如果你缺乏设计工作能力，那么将没有人同意和维护你所作的。

提供多个接口用于输入数据到文件来进行数据驱动测试。你可能选择一个或者针对有不同经验的测试人员提供不同的接口。（一致通过）

框架驱动方法

暂时，框架讨论进入了一个扩展一种语言设计的讨论，使用程序语言的是最好的实践。我们不断尝试，在其他人遇到这类问题前，修改我们的协议列表。沿着这条线我们跳过了保留观点。下边是一些详细框架的建议：

同意依靠一定数量的混合人员来开发框架。（一致同意）

当你建立框架的时候，你建立的函数在什么层次上。例如，要思考在三个层次上操作项目：

菜单/命令层次，执行简单的命令

对象层次，特别的处理要执行的动作

任务层次，注意特别，普通，重复的任务

你可能发现他在一个层次上起作用，当你确实需要他们的时候，加入其他用例。

有很多方法定义和分离层次。用适当的方法分析任务。避免不明智的创建非常简单的测试脚本测试一些非常长而复杂的测试用例。（一致同意）

脚本中加载框架函数库的时候必须包含错误处理的检查代码。（一致同意）

一个对所有开发都适用的经验，特别对测试代码重要，因为我们期望正在测试的程序中断，并为了使报告和处理简单所以看失败的征兆。

当创建共享库的命令时，在处理个人编程和文档风格上存在风险。如果开发人员不能适应这些，那么他们不会用其他人的代码。（一致同意）

利用你的库创建脚本可以节省“时间“。如果不创建库则反之。（一致同意）

这些库是有序的存储共享命令的仓库。如果一个函数很普通，并且需要用户传递大量的参数，有些开发人员（使用测试工具的测试人员）宁愿使用自己定义的参数。一些开发人员不检查库里是什么。有些程序员不相信库里的代码，因为他们认为里面有（可能正确）很多未经测试的和错误。

在数据文件中包含测试参数是需要的，比如ini文件，设置文件胜于把常量加入到自动化脚本中或者加入到包含脚本的文件中。（一致同意）

封装是对的。和通常一样使用这种方法.(一致同意)

本地化

我们花费很多时间讨论本地化的问题，我们得出了令人惊讶的结论。我们可能在以后的LAWST会议上讨论这些问题，但是对于自动本地化测试经验的人——如果被告知当你今天付出很多来投资基于GUI的自动化，将来会有回报，这对你来说是个警告，这些是受挫的表示。

自动化本地测试目标是展示以前仍然工作的基线。（一致通过）

如果国际化做了组织计划，并且如果测试团队手工翻译了所有字符串（我们比认为这能自动化），还有如果测试团队做了有利于本地化功能变化的手工测试（我们不认为这是有效的自动化测试），那么有一小套自动化测试用例是检查本地化是否合法是需要和合理的。我们依靠本地用户真正的使用/手工测试。（7个同意，1个否定）

如果基线和增强测试是足够强大，那么测试脚本轻松的处理语言是很少做得除了一组小测试需要选择脚本。（5个同意，0个否定）

如果转化翻译在实施后作，没有早期的可翻译性的设计，那么我们需要对每一个事情重新测验。在这种情形下，基线代码可能是自动脚本有意义的值。

我们不同意下面的情况：在局域化版本中复测所有的缺陷，在基线版本中扩展，为每一个语言建立同样的基线来扩展自动化测试。（7个不同意，1个同意）

bug分类或许是引起计划好本地化期间通过基线衰退测试跟踪是不可靠的原因。（9个同意，1个反对）

我们没有在这些观点上投票，是因为我将加入Brian Marick建议自动本地化测试加入测试计划中的讨论，我们要一些容易分辨的测试分类来思考。下边是一些例子：

语言独立于自动化测试，例如（很多不是全部的案例中）打印人员配置测试，另一些配置/兼容性测试，变化纸张尺寸的兼容性测试。特别语言自动的测试，如果他们是值得的。如果你期望不断卖法国，英国，西班牙版本的新产品，那么你可能在一些建立法国，德国和西班牙的自动化测试用例中发现价值。

更多通过手工本地化测试来处理是测试语言细节的最好方法。通过自动化处理来进行国际化方面的测试。这些测试检查软件的翻译和本地化。举例，你可能提供虚拟的很长很短等字符串来翻译。不同的国家你可能提供不同连接的文本。

廉价的本地化测试。Marick的期望这一类很校然而，一些测试不关心字符串用法和屏幕显示。例如，依靠不断执行一些函数来发现内存泄漏的压力测试，但是显示的图形和文本可能没有关系。这些测试中的本地化测试，最底程度要让他们有用，将很简单。

底线是即使你有英文产品的一个强大的自动化测试套件，当你测试译文的时候也不会把速度加快很多。

本文到此翻译完毕，由于本人英语水平有限，其中难免有很多疏漏之处，请大家原谅。希望这篇文章给大家一些启示。谢谢。