对可维护性的思考

　　可维护性需求并没有因为友好的自动化工具提供商忘了提及它们而消失。以下是二月的LAWST会议上我们再次讨论的两个议题：

　　o 　　当程序用户界面改变时，为了正确反映并测试你的程序，你需要做多少更新测试脚本的工作?

　　o 　　当用户界面语言改变时(比如从英文变成法文)，为了正确反映并测试你的程序而修正脚本又变得有多困难?

　　我们需要处理这些议题的可靠策略。下面是两种无法解决问题的策略：

　　用截取工具创建测试用例：创建测试用例最普通的方法就是使用自动化测试工具的截取功能。但这种方法很不合逻辑。

　　在程序的第一段，你很可能不会像下面这样编写代码：

　　SET A = 2

　　SET B = 3

　　PRINT A+B

　　在代码中嵌入常量显然是愚蠢的。然而，这就是我们用截取工具得到的结果。我们通过截取一段敲键、移动鼠标或者命令行序列来创建一个测试脚本。这本身就是常量，就好象2和3。于是，程序用户界面的最微小的改变也会导致脚本无效。因此，与截取测试用例有关的可维护性开销是不能被接受的。

　　截取工具通过展示测试工具如何翻译一个手工测试用例来帮助你编写测试代码。它们并非没有用。但是，如果你试图用它们做太多的事情，那会变得很危险。

　　基于特定基础编写测试用例：测试团队通常在他们的闲暇时间尝试创建自动化测试用例。其总体规划看起来就像“创建尽可能多的测试”。而这并没有统一规划或主题。每个测试用例都是独立设计并编写的，且脚本通常重复同样的命令行序列。这种方法与截取/重放方法一样脆弱。

　　成功的策略

　　我们不必为使用这些工具所带来的风险而沮丧。我们中的一些人已comp.software.testing和其他的出版物上为此做了大量工作。这次我们之所以召开会议，就是因为我们认识到一些实验室已经在处理这些问题上取得了重大的进展，只是信息没有共享罢了。显然，对于一个实验室，重要的是其较其它实验室更先进的思想。因此，此时此刻，我们就在一种能使各自的观点被易于挑战和阐明的环境下，评估我们共同的认识。

　　以下是若干建议，它们有助于开发自动化回归测试策略：

　　1. 对从自动化中获益的时机重新设定管理期望值。

　　2. 承认测试自动化开发是软件开发的一部分。

　　3. 使用数据驱动的架构

　　4. 使用基于框架的架构

　　5. 按真实情况安排岗位

　　6. 考虑使用其他类型的自动化

　　接下来我们对它们一一分析。