提高自动化测试套件的可维护性[转帖]

   自动化黑盒测试，GUI级别衰退测试工具在当今很流行，根据这些神话，你的编程经验即使不是很丰富，也可以建立很强大的测试套件。这些工具（按照说明）很容易上手。维护测试套件不是问题。因此，神话继续上演，用这些测试工具之一替换掉那些讨厌的软件测试工程师,开发管理者可以节省大量的金钱和负担，使软件很快正常运行。

测试软件的卖主，不懂测试的主管极力推广这样的神话，甚至那些测试经理，测试工程师也这么认为。认为使用测试工具多么好。

一些公司已经开始享受成功给他们带来的好处，但是另外一些公司由于没有有效的使用测试工具，失败了。

二月，十三个富有经验的软件测试工程师在LAWST聚会两天，讨论成功的模式和测试套件用于衰退测试阶段的黑盒测试脚本的可维护性失败的教训。我们讨论的重点集中在实际经验，以哪些已经在实际中部分有效的解决自动化问题的方案开始。我们的目标是在有限的经验下，在短时间内总结出一套有效的的过程。为了提高的效率，我们在富有经验的-- Brian Lawrence（会议的主持人） 带领下展开讨论。

其他参加者: Chris Agruss (Autodesk), Tom Arnold (ST Labs), James Bach (ST Labs), Jim Brooks (Adobe Systems, Inc.), Doug Hoffman (Software Quality Methods), Cem Kaner (kaner.com), Brian Lawrence (Coyote Valley Software Consulting), Tom Lindemuth (Adobe Systems, Inc.), Brian Marick (Testing Foundations), Noel Nyman (Microsoft), Bret Pettichord (Unison), Drew Pritsker (Pritsker Consulting), 和 Melora Svoboda (Electric Communities). 所以的与会者只有一个目的， 表达了个人的观点，不受公司的观点的束缚。

下边列出其他与会者的测试经验：
问题是什么？
自动化衰退测试中有很多缺陷。我只列出了一小部分。James Bach（与会者之一）在"Test Automation Snake Oil“中列举出其他很多问题。

通过范例举例：
这是个在衰退测试中基于GUI的自动化范例　　　　
设计测试用例，然后运行他
如果这个脚本运行失败，你将写个bug报告，赋予缺陷状态为fixed，然后从新开始。如果这个自动化脚本运行成功，并功能正确。在此运行测试脚本（或者来自于某个脚本，或者来自于某类捕获工具）。在测试后抓取屏幕文件输出，保存测试用例和这个输出文件。下次对比输出文件和这个保存的输出文件，如果一样，那么脚本运行成功，测试通过。
第一个问题：这样做不划算。创建，验证，编写自动化测试脚本和手工创建执行测试一样要花费3到10次甚至更多（直到成功为止）。很多测试人员愿意自动化，但是对于测试人员来说，只运行一次脚本，那么这种效率就很低下了。
很多测试人员建议百分之百自动化测试用例。我强烈不同意这样的要求。我创建的很多黑盒测试用例只执行一次。要把每一个测试用例自动化，我要花费很多时间和金钱。利用这些时间我可以执行很多测试测试用例。为什么要低覆盖高成本的测试呢？

第二个问题:这个方法有附加的风险存在.我们知道发现，修正缺陷的成本会随着时间的增长而增长。随着产品越来越接近出货日期人们做的工作就愈多, 作为试用版用户要编写手册和买卖原料. 越后来发现修正重大缺陷越多的人的时间将被浪费。如果你在测试时间前花费大量时间写测试脚本, 你知道最后才发现缺陷, 这是非常昂贵的。

第三个问题: 这些测试不够强大. 执行了自动化测试的这些测试已经通过。但是通过这种方法你新的缺陷能发现多少？据我听说的评估大概在百分之六道三十之间。这个数字在你创建测试用例发现缺陷的时候是呈增长的趋势,这仅仅是手工测试,和自动化测试没有关系。

第四个问题: 实践,很多测试组织仅仅是简单的运行脚本。测试前期, 简单的设计和程序不可能运行更多复杂的测试用例。稍后, 虽然, 这些测试很简单, 尤其与有经验的测试人员相比这就是无用的测试方法。

思考可维护性
脚本维护的需求不是不需要，而是卖自动化工具的人没有提到这点而已。在二月LAWST会议上我们不停的讨论两件事。当软件用户界面发生变化的时候，你们要做多少修改测试脚本的工作能让脚本正确适应软件的变化并测试软件？当软件界面语言发生变化（比如英文版到法文版），修正测试脚本让他正确适应软件的变化并测试软件有多困难？我们需要的是处理版本变化的测试策略。 下边两种策略是不推荐的：建立测试用例利用扑捉回访工具。最普通的方法是利用自动化测试工具的扑捉特性建立测试用例。这是最苯的。 编程第一课可能学习的不是写程序，例如： set a=2 set b=3 print a+b 隐藏恒量是很傻的。但那对我们是最有用的。我们建立通过录制输入一定顺序键值，鼠标动作，或者命令的测试脚本。这些恒量如2，3。软件用户界面的细微变化测试脚本都会发生错误。简单朴捉回放的脚本对于维护是不接受的。扑捉回访的脚本的好处是帮助你展示怎么样把手工测试用例用自动化工具执行。他们也不是无用的，但是如果你做的脚本越多风险越大。 在特定基础上编写测试用例：测试团队经常在他们的业余时间创建自动化测试用例。他们的计划类似，“尽可能的创建测试用例“ ---- 没有统一计划和主题。每个测试用例设计编码都是独立的，这些脚本中总会有重复的命令序列。这同扑捉回访一样是不健全的。 成功的策略： 我们不用为使用这些工具的风险而哀叹。我们其中很多人已经在comp.software.testing和另一些出版物上做了很多。我们在这里是因为我们已经意识到在处理这些问题上一些试验建立了很有意义的过程。但是信息共享的还不够。一个实验对于另一个是先进的做法是显而易见的。现在在这个既是挑战的环境也是澄清每个人想法的环境里是收集大家的想法的时候了。 一些开发自动化衰退测试测试略的建议： 重新斟酌对于能从自动化测试中得到好处的期望。承认自动化测试一种软件开发利用数据驱动体系利用基于框架的体系考虑使用其他类型的测试工具 1.重新斟酌对于能从自动化测试中得到好处的期望 我们认可GUI级别的自动化衰退测试执行n次后的结果，如果继续进行这种测试，可能会发现更多的益处。我们都知道在软件发布N次之后开发GUI级别的自动化衰退测试脚本，才能在软件发布N+1次的执行中得到更多的好处。我想大家都很惊奇有这样的结论，因为我们曾经都听说过（或者经验）投资自动化测试的回报这样的理论。 软件发布n次后意识到的好处，例如：自动化测试一系列验收测试（冒烟测试）用例有很大的好处。在开发第n版软件的时候你可能要运行这些脚本50到100次.如果开发每个测试用例是手工测试执行的10倍时间,另外花10倍时间维护.这样创建一个自动化测试用例的时间可以节省相当于手工执行测试用例30到80次.     你可以节省时间,减少人为错误,总结怎样很好的跟踪自动化测试配置和兼容性测试所能做的。在这些案例里，你要在不同的环境下和设备下运行同样的测试。如果你和30个印刷工测试程序的兼容性，一周内你就可以重新得到自动执行测试的好处。衰退自动化脚本可以作为处理操作系统和处理不同的开发版本的基准。     当自动化带有短期获利目的的时候，自动化很容易在近期中发生危机。价值证明每一个附加测试用例或者一组测试用例。    如果你正在找寻找长期目标，处理软件版本，那么你要认真思考关于版本n的目标：倘若在一些特定的阶段（比如冒烟测试和兼容性测试）中测试版本n。我们开发的脚本在软件版本n+1时将更加有效和强壮。 2．承认自动化测试一种软件开发 你不可能在还没有在下个版本还没有弄清楚和现实的计划前开发。你不可能在还没有弄清楚和现实的计划前扩展测试脚本。你不可能在没有弄清楚和现实的计划前开发出很多低维护成本的测试脚本。 软件自动化测试像其他软件开发一样需要时间，软件测试工程师需要编写自动化脚本代码。即使自动化脚本语言很难。如果决定用应用程序测试应用程序，那么每一个测试用例都有自己的特点。 从自动化软件测试的观点来看,每一个软件（正在测试的软件）的界面就是数据。我们研究如此多的软件开发工程，软件开发者（在这个例子中，测试工程师）必须 ：    了解需求：接受一种有效的的开发方式，维护和集成软件的特点和数据。接受和执行标准。（我们不必选择如iso或者cmm这样的配置管理，只要两个人可以利用命名规定，文档结构，处理错误等方式，在一个项目上合作工作就可以。任何组内成员都要遵守制定的规定和标准） 遵守规定：所有的人，测试人员必须承认遵守近似于软件开发的方法代替quick-and-dirty的设计和执行方法有多么重要。没有他，我们必须有执行多少越多测试用例失败越多的心理准备。

3．利用数据驱动体系
在讨论成功的工程中，我们得出两种分类，分别是数据驱动设计和基于框架的设计。他们可以孤立也可以集成在一起。 一个数据驱动的例子：假设测试一个用户创建和打印表格的程序。你要处理这样几件事情： 表格标题。可以设置不同的字体，大小，样式（粗体，斜体，小写，正常）。 标题位置 (在表格上下,在表格旁边) 和方向 (字母显示水平方向还是垂直方向). 标题绘图（在标题上下还是旁边），图形打下（大，中，小）。他可以是位图（pcx,bmp,tiff）或者是矢量图（CGM,WMF）。 表格边框边线稠密 表格行列数量和大小。 每个单元格字体，大小，样式。每个单元格内图形大小，位置，旋转。 表格打印输出纸张的大小，方向。 <> 标题            顶行框边         行列 特征1 表格的一些特性 因为他们在同一时间同一张纸上操作所以参数都是相关的。如果一些行特别大，就没有留给图形的地方。如果字体太多，程序有可能内存溢出。例如在组合设置这些参数测试，那么将有上万种组合。 假设编写一百个脚本测试一百个组合。如果界面的一个元素变化了，举例，如果标题字体从一个对话框移到另一个对话框，那么你不得不修改每一个脚本。 标题位置，标题字体，标题样式，标题图形(CG—Caption Graphic)，宽度 1．  顶部 Times  PCX  3pt 2．  右 Arial 斜体 2pt 3．  左  Courier 粗体 1pt 4．  底 Helevtica  粗体斜体  TIFF中间无 特征2 从一个只有几行的格式化的测试矩阵的表格开始 我们从测试矩阵开始工作。测试用例包含很多参数变量的组合。在这个矩阵里，每一行制定测试用例，每一列都指定参数设置。例如，列一可能指定标题位置，列二标题字体，列三标题样式。还有其他一些列。 创建电子表格创建你自己的矩阵，比如Excel。 执行这些测试用例，编写测试脚本从读取电子表格中一次读取一行数据（测试用例）。执行脚本设置在电子表格中指定的参数。如果我们继续工作在特征2弟子表格中的第二行。第一次运行的脚本从第一列中读取数据（标题位置），正确设置对话框并写入字段中，然后设置标题位置，这个值可以在测试矩阵中看到。一旦所有的参数正确设置，你可以做剩下的设置，你可以打印这个表格并评估输出是否正确。 测试程序将执行每一行的小脚本。 换句话说，你的结构是： 加载测试用例矩阵 For each row I (row = test case) For each column J (column = parameter)      Execute the script for this parameter:      正确操作对话框或者菜单                设置从测试矩阵中(i,j)位置读取的值                返回测试结果     如果软件设计变化，那么标题位置将移到不同的对话框，你只要改动很少行的代码，每个mini脚本中处理标题位置。你需要改动这些行一次：只要改变每个在电子表格中的测试用例。比较修改每个测试用例的脚本来说分离代码和数据是很有效的方法。 还有其它几种建立数据驱动的方法。比如，Bret Pettichord(LAWST会议参加者)在表格中填写一系列命令。每行列出了要执行的测试用例需要执行的一系列命令（一个单元格里一个命令）。如果用户界面变化了，需要稍稍修改命令序列，这时测试人员通过修改电子表格中数据要比从新写代码来修改测试用例方便的多。其他测试人员用简单的测试用例序列或者当前状态就可以了。     另一个方法驱动数据用以前的文档，假设测试文档处理器处理成千上万的文档。每个文档，脚本驱动文档处理器加载文档，然后执行一些列简单的操作（比如打印）           一个有名的设计数据驱动的方法能很容易让非功能测试计划人编写测试用例，因为他们只要简单的把测试用例写入测试矩阵中就可以。其他的测试用例都可以用这种方法生产，如果你做的很好，只要建立简明的告诉测试工具如何运行的一套表格。 4．  用基于框架的体系 这个框架提供了完全不同的方法，虽然他经常运用把多个数据驱动测试策略。Tom Arnold(LAWST成员)在他的书和课程中讨论了这个方法。       这个框架通过共享的函数库中的一系列函数把被测试应用程序和测试脚本分离。脚本开发者人员把这些函数看作测试工具本身的开发语言中的基础命令。他们因而把软件界面和测试脚本分离。          举例，一个框架编写者可能创建一个函数---OpenFile(p)。函数打开文件p。下拉文件菜单，选择打开命令，拷贝文件名字到文件字段，选择ok按钮关闭对话框，然后操作。或者函数比这要做得多，假如错误处理。函数可能检查文件p是否被打开或者把试图打开文件的操作写入日志，把结果写入日志。这个函数也可能通过快捷方式命令替换操作菜单来打开打开文件对话框。程序可以利用应用程序编程接口（API）或者Macro语言来测试，或许函数能调用简单的命令并把文件名和路径作为参数发送。这个函数的定义不断的变化。脚本开发者只要知道函数名字openfile(x)来打开文件x。

在你创建的库中很多函数可以在几个应用程序中用（或者你把他们设计得很灵活）。不要期望百分之百的灵活。比如openfile函数的一个版本中可能对每个用到标准文件对话框的程序都有用，但是你有些时候你要用到的是附加其他功能的自定义对话框。
框架中包含几种类型的函数，根据应用程序简单包装的函数或者使用处理一个集成任务的复杂脚本函数。下边是一些基本的类型： a．  定义每个应用程序的功能特征 你写一个菜单选择的函数，下拉菜单，设置变量值，或者发布一个命令。如果UI的其中一个功能发生变化，你只要改动函数功能就可以了。当重新编译连接后，任何用到这个函数的脚本自动更新。 框架的本质是当处理自定义控件时，例如自画控件。自画控件就是程序员用画图命令画对话框。自动化测试工具知道那里有个窗体，但是它不会知道内部怎么样。当他不知道那里有个按钮的时候，你如何用工具点击对话框中的按钮呢？当你不知道那里有个listbox框在那里的时候，你如何用工具选择列表框中的选项呢？你可能应用一些技巧选择列表中的第三个选项，但是你如何选择一个在任何位置变长的列表中的项目呢？跟着的问题是：当你决定重新录制的时候，你怎样处理一般不显示的按钮和列表框和其他一些界面元素呢？      在lawst会议上，我们讨论了如何把想法组合在一起。一些与会者都证实大概有一半自动化开发的时间在处理自定义控件的问题。 组合这些想法是复杂的，维护量很大，对于脚本开发者来说是分心的事情。我认为他们分心的原因是自动化工具问题带来的而不是测试脚本程序的问题。他们把测试人员的焦点转移在工具的缺点上了，而不是在发现和报告程序潜在的问题。 如有你坚持用自画控件，压缩你程序的每一个功能可能是你框架中最紧迫的任务。隐藏每一个组装的函数。用哪个特性，编程人员就调用那个特性，不用考虑组装的函数。如果UI界面变化，组装函数不用影响脚本的情况下重新编写。 b．定义命令或者测试工具语言的特征    自动化工具有自己的脚本语言。你可能发现把每个命令封装到一个间接的层里面很困难。封装函数是把其他函数封装在里面。简单例子是，仅仅调用一个封装的函数。你可以修改封装函数，添加或者修改功能解决测试工具的缺陷，或者增强脚本语言的优势。          Tom Arnold提供wMenuSelect的例子，一个Visual Test选择菜单的函数。他封装了SelMenu函数，SelMenu就是简单调用了wMenuSelect函数。这很灵活。比如你可以修改SelMenu函数，添加日志函数或者错误处理或者内存监视功能，你可以想到的任何功能。添加功能后，每个脚本不用添加任何代码就可以获得新的特性。这很适合压力测试，执行结果分析，错误分析，还可以达到报告和调试的目的。    用到这个方法的与会者说这样做可以重复使用。 c．定义小的，概念性的频繁做的统一目标     openfile函数是这种类型函数的简单例子。脚本开发者写成千上万个要求大打开文件的脚本，只要关心在这些脚本中打开的文件怎么样就可以。对于测试来说，它就像文件快速打开，完成他测试的目标。写一个库函数可以节省脚本编写时间，改进脚本维护的质量。 这是代码中重用最简单方法，不管在测试自动化开发还是其他软件开发中都一样。 d．定义大而复杂应用到一些测试用例里面的大的测试用例脚本    压缩大的序列命令是合理的。特别是你过分做这个工作，是有风险的。一个复杂的序列命令可能不是用到很多测试脚本中，所以不值得推广，事实证明，应该加入错误处理代码到你期望适合写库函数中。同样，越复杂的序列，当ui变化越需要维护。一个很少用的脚本命令可能占用你的库维护成本的很大部分。 e．定义实用函数    比如，你可以创建一个用标准方法记录测试结果到硬盘的函数。你可以在开发脚本的时候把它作为标准在每个测试用例后边调用这个函数。    每个测试工具都提前提供自己写好的实用函数。你可以添加或不添加附加函数。 一些框架的风险      你不能同时把所有的命令添加到你的库中。你没有足够的支撑。一些自动化工程失败的原因在于测试提供者想创建最终的必须有的每一个编程库。管理维护在框架完成能用前无法再提供支持。你不得不分清优先级。不得不超时运行编译库。           不要期望函数库在那里每个人就都会用它。一些人的编码风格各异。如果你没有一个变量声明，函数的参数顺序，用到的全局变量等等的标准，这些对于一个程序员是合理但是对其他人就可能不合理的。同样，一些人憎恨不是他们写的代码。一些人熟悉工程代码比较慢，不知道库里有什么东西。他们总是很匆忙没有时间任何时间考虑就开始编程。你不得不设法维护这些库正常运行。    最后，小心设置执行，尤其如果你程序中有自定义控件的时候。版本1.0中（或者早期的开始自动化测试的版本），你可能花费的大部分时间去包含创建类似于点击按钮，选择列表项，选择tab页等这样模块框架。你可以节省为版本2写脚本的时间从中获益。建立框架是昂贵的。请从新考虑你的期望。 4．  认清事实 你必须给一些稳定的版本培训你的管理。 首先，很多测试人员是初级程序员。他们没有多少设计系统的经验。设计不合理的框架对工程也是有影响的。所以需要有经验的人。如果像自动化成功，你不得不需要一个有丰富编程经验的人加入测试团队。 其次，很多黑盒测试人员几乎没有编程经验。他们可以提供类似专家经验或者其他用户体验之类，这些是编程人员无法提供的。这些是有效的强壮测试不可缺少的。因此，你需要一个不用每个人都要写测试代码的稳定开发策略。你要解决创建一个测试开发人员在非测试开发人员之上的问题。很普遍，在我的观点里利用自动化测试工具的队伍中有失去理性和反对多产的偏见。这会伤害老的非测试开发人员，它会花费更多精力测试程序，而不是用户需求本身。 非开发测试人员通过往电子表格写测试计划的方式开发测试用例---也就是数据驱动方法，会做的很好。 第三，用执行人实现自动化测试要小心。他们不但要有开发经验，而且要肩负培训或者更多的日常任务。 最后，必须让管理者知道自动化是需要时间的，不要期望在最初版本中开发的自动化程序中获得效益。如果你应用层次上达到了测试目标，那么你可以添加更多的目标。如果一个项目用十个人手工测试一年正常，你可以加两名优自动化开发经验的测试人员，这时候你就有10个测试人员两个开发人员。在下个版本中，你可以减少测试人员的时间。在这个版本中，你将节省一些同样的任务时间（比如配置测试）但是你将在培训和管理费用上失去时间。在每一个项目结尾，可以提高衰退测试软件面对推迟完成测试的能力，而在计划最后一分钟确定，这样可以帮助你稍作无用的测试，胜于给你砍掉稳定版本的机会。

6.考虑用其他自动化测试类型
LAWST会议上主要集中在GUI层次上衰退测试工具，所以这篇文章主要写的是关于这方面的。在开会前我们参加会议的人主要描述了我们在测试自动化中的经验。一些人作了生动的成功的报告。更大的成功是在于和编写测试程序的人广泛的合作。在这些故事里利用这种类型测试工具成功的案例多种多样，这反映了从不同的测试工具中获取的效益是不同的。    有很多骗局，期望和希望应用基于GUI的衰退测试。他们可以幻想在没有一个独立的工具存在的情况下测试覆盖，这引起一系列的问题，它可以把它的精力更多的放到设计和维护发现更多BUG的用例上。      这些测试工具是可用的，但是他们需要有意义的投资，详细的计划，可靠的培训，和小心的警告来配合。 附录： 关于讨论范围 在最后的三分子一的美一天，我们把一些观点写道白版上，对于不能统一意见的问题通过投票决定。这么做的目标是为了达到每一个观点符合经验丰富的测试人员的经验。在一些案例中，我们不需要投票，既不是因为缺乏特殊的投票经验，也不是因为我们认为这个框架存在问题（我们跳过了很多这样的想法和观点）。 如果你试图去培训和执行自动化化的成本和风险，那么投票是解决这种讨论最好的数据。 通用原则    这些观点不能变为事实。在自动化计划中，需要很多努力，清醒的认识需要解决什么问题，在什么环境下解决。（一致同意） GUI测试自动化是重要的软件开发，他的成功需要有体系，标准和规定为基础。通用原则适用于软件设计和执行适用于自动化设计和执行（一致同意） 对于实用和维护来说，我们首先需要开发一个包含很多变量的体系结构，来处理软件中的特性变化。我们应该开发基于GUI的自动化满足稳定的特性（一致同意） 一些人有一种应该随着公司自动化发展而变化的预感。一般决议（7 同意 1 否），在缺乏自动化经验的情况下，更多的自动化成果会发展。      扑捉回放失败。我们是否扑获到少量或者窗体部件（对象的朴捉回放）变得无关紧要。 应用个别的编程测试案例失败（个别测试用例代码没有遵守通用标准核建立共享库） 开发的共享库需要维护是必需的。这些库可能包含录制的脚本或者数据驱动测试脚本。 第二个一般决议（10个通过，1个不同意）：通用的自动化失败是原因： 建立测试用例利用扑捉回访的原则。 应用没有标准的测试永例（比如测试用例代码中不遵守通用标准，不建立共享库） 应用设计有缺陷的框架。这是普遍问题 直接回放的册实用例发现的bug率很低（一致通过） 一旦程序通过测试，不代表将来测试可以再次执行不失败。这些引出一些观点（没有人投票）：自动化测试很危险因为他给我们一个虚假模糊的程序不能失败的感觉，即使程序今天不会运行失败不是说明天就继续成功。有很多使程序失败的原因。但是你不需要找寻bug的原因除非你想那么干。      自动化测试中发现的bug 60%-80%的问题是在开发测试中发现。除非你从开始正确使用自动化工具创建和运行测试，否则更多的问题是在手工测试中发现（一致通过）。 更多的测试团队通常不是在一开始自动化工具运行册使用例。传统案例中，开始时候进行手工测试，当程序测试通过后可以把他加入自动化套件中。不管怎样，如果你决定不依靠以前扑获输出来测试，不管是程序测试成功还是测试失败，你都将更加有效的利用测试工具。例如： 运行不同的系统版本或则配置上同样的一系列测试。你可能从来没有在特殊的环境下测试程序，但是你知道怎样让他运行。 运行同等测试。在这个案例中，你运行两个程序，输入相同的序列。如果程序的结果相同那么程序测试成功。 代码经过测试，所以会产生一些系列程序运行日志目录，如异常状态，，状态转变，内存管理，堆空间，或者其他的异常，或者另外定义的程序错误。测试工具通过很多的状态转换来随机驱动程序，记录测试工具可以运行的命令。第二天，测试人员和开发人员通过寻找bug和触发他们的环境的日志来跟踪。这是简单的模拟例子。如果你正在工作在一个和开发团队合作的环境，那么你用测试工具建立的测试用例将比通过手工建立的脚本更广泛和有效（团队每周可以发现新bug）。 当你和开发人员一起开发hooks，接口和调试输出的话，自动化测试将更加成功。（一致通过） 协作的方法：不依靠基于GUI自动化测试工具，简单的使用工具—方便测试驱动程序，没有简单的GUI衰退测试范例。LAWST会议上提供的表格是迷人的，听到关于自动化成功的故事。大多数案例中，和开发队伍协作大多数都获得了戏剧性的成功，不包括传统的仅仅使用（任何使用）基于GUI的衰退测试。 我们可能在LAWST的会议后期研究测试设计和开发之间的写作关系。 大多数代码是由工具建立不可维护和没有长期值的脚本。不管怎样，用测试工具写测试用例因为它可以记录一系列近期发生的事件时，这时候扑获是有用的。通过录制工具建立的脚本可以在给你写自己代码的时候一些提示。（一致通过） 我们不能用屏幕区域来记录一切，因为那时浪费时间。（事实上，我们不在需要的时候才用屏幕区域和使用他们。我们在对比屏幕小的区域中发现问题。有时我们不得不对比屏幕区域，可能因为我们测试的区域友自画工具，但是范围太大了，我们应该对比本地结过，而不是BMP图片）。（一致同意） 不要失去测试自动化验证点。在脚本中添加扑获比寻找BUG要容易得多。（一致通过） 测试设计 自动化简单脚本不是正确策略。（一致通过） 如果你从建立很多的简单测试用例开始，那么你建立强大测试用例前就用完时间。收集大量的例子中，容易通过的测试用例比手工测试可能看上去更严谨，但是一个有经验的手工测试人员可能运行复杂的测试要比程序运行要稳定的多。 组和测试能发现新的bug（总和比部分更总要）（一致通过）

用于自动化测试的值是不确定（比如随机）的尽管我们需要确定测试用例的方法。（一致通过）
我们不确定盲目测试。需要知道运行的是什么测试，有时候你需要输入严格的和一定顺序的输入。但是如果你决定是否程序是正在运行通过的测试，你都要不断用大量的测试用例替换那些已经运行成功的测试用例。 我们需要设计纪录测试用例运行日志的能力。（一致通过） 一些测试工具使纪录测试工程变得简单，一些变得复杂。调试跟踪测试过程，你可以很快看到测试用例运行的状态和返回值。 人力和管理     自动化工作所作的努力在版本n，在版本n+1发布的时候将得到更多的好处。在你能达到短期回放目标的情况下，对这个真实性存在异议。例子中包括冒烟测试，压力测试（一些压力测试只能用自动化实现），配置/兼容性测试。（一致通过）     如果版本n是自动化开始测试的版本，那么你基本目标是可以在版本n+1中写稳定的自动化脚本。你的第二个目标是容易实现的除了把在版本n中测试作为目标。 人们需要重视自动化而不是吧她作为次要目标。如果没有人投入到自动化中，那么自动化可能就是浪费时间。（一致通过） 很多测试人员没有什么编程经验，他们不知道如何建立和好的设计框架。（一致通过） 数据驱动方法    本篇文章主要描述了数据驱动。我认为谈论我么喜欢的数据驱动方法是保险的，但是我们中没有人在每个可以想象的情况下用数据驱动方法。附加部分，会议详细的备注。 数据驱动策略的主题包含（举例）： 输入程序的参数 执行程序的操作顺序和命令 驱动程序运行的测试用例顺序 驱动程序运行的机器状态顺序 文档记录程序读取和操作 由系统模型指定参数和事件（比如状态模型或者基于模型的图表）（一致通过） 数据驱动维护量很小而且对于非编程人员很容易使用。（一致通过） 尽管我们同意这些原则，但是我们有杂乱或者简单思考的测试矩阵例子等等。如果你缺乏设计工作能力，那么将没有人同意和维护你所作的。 提供多个接口用于输入数据到文件来进行数据驱动测试。你可能选择一个或者针对有不同经验的测试人员提供不同的接口。（一致通过） 框架驱动方法      暂时，框架讨论进入了一个扩展一种语言设计的讨论，使用程序语言的是最好的实践。我们不断尝试，在其他人遇到这类问题前，修改我们的协议列表。沿着这条线我们跳过了保留观点。下边是一些详细框架的建议： 同意依靠一定数量的混合人员来开发框架。（一致同意） 当你建立框架的时候，你建立的函数在什么层次上。例如，要思考在三个层次上操作项目： 菜单/命令层次，执行简单的命令 对象层次，特别的处理要执行的动作 任务层次，注意特别，普通，重复的任务 你可能发现他在一个层次上起作用，当你确实需要他们的时候，加入其他用例。      有很多方法定义和分离层次。用适当的方法分析任务。避免不明智的创建非常简单的测试脚本测试一些非常长而复杂的测试用例。（一致同意） 脚本中加载框架函数库的时候必须包含错误处理的检查代码。（一致同意） 一个对所有开发都适用的经验，特别对测试代码重要，因为我们期望正在测试的程序中断，并为了使报告和处理简单所以看失败的征兆。 当创建共享库的命令时，在处理个人编程和文档风格上存在风险。如果开发人员不能适应这些，那么他们不会用其他人的代码。（一致同意） 利用你的库创建脚本可以节省“时间“。如果不创建库则反之。（一致同意） 这些库是有序的存储共享命令的仓库。如果一个函数很普通，并且需要用户传递大量的参数，有些开发人员（使用测试工具的测试人员）宁愿使用自己定义的参数。一些开发人员不检查库里是什么。有些程序员不相信库里的代码，因为他们认为里面有（可能正确）很多未经测试的和错误。 在数据文件中包含测试参数是需要的，比如ini文件，设置文件胜于把常量加入到自动化脚本中或者加入到包含脚本的文件中。（一致同意） 封装是对的。和通常一样使用这种方法.(一致同意) 本地化          我们花费很多时间讨论本地化的问题，我们得出了令人惊讶的结论。我们可能在以后的LAWST会议上讨论这些问题，但是对于自动本地化测试经验的人——如果被告知当你今天付出很多来投资基于GUI的自动化，将来会有回报，这对你来说是个警告，这些是受挫的表示。     自动化本地测试目标是展示以前仍然工作的基线。（一致通过）     如果国际化做了组织计划，并且如果测试团队手工翻译了所有字符串（我们比认为这能自动化），还有如果测试团队做了有利于本地化功能变化的手工测试（我们不认为这是有效的自动化测试），那么有一小套自动化测试用例是检查本地化是否合法是需要和合理的。我们依靠本地用户真正的使用/手工测试。（7个同意，1个否定）     如果基线和增强测试是足够强大，那么测试脚本轻松的处理语言是很少做得除了一组小测试需要选择脚本。（5个同意，0个否定）     如果转化翻译在实施后作，没有早期的可翻译性的设计，那么我们需要对每一个事情重新测验。在这种情形下，基线代码可能是自动脚本有意义的值。     我们不同意下面的情况：在局域化版本中复测所有的缺陷，在基线版本中扩展，为每一个语言建立同样的基线来扩展自动化测试。（7个不同意，1个同意）     bug分类或许是引起计划好本地化期间通过基线衰退测试跟踪是不可靠的原因。（9个同意，1个反对）     我们没有在这些观点上投票，是因为我将加入Brian Marick建议自动本地化测试加入测试计划中的讨论，我们要一些容易分辨的测试分类来思考。下边是一些例子：     语言独立于自动化测试，例如（很多不是全部的案例中）打印人员配置测试，另一些配置/兼容性测试，变化纸张尺寸的兼容性测试。特别语言自动的测试，如果他们是值得的。如果你期望不断卖法国，英国，西班牙版本的新产品，那么你可能在一些建立法国，德国和西班牙的自动化测试用例中发现价值。     更多通过手工本地化测试来处理是测试语言细节的最好方法。通过自动化处理来进行国际化方面的测试。这些测试检查软件的翻译和本地化。举例，你可能提供虚拟的很长很短等字符串来翻译。不同的国家你可能提供不同连接的文本。     廉价的本地化测试。Marick的期望这一类很小。然而，一些测试不关心字符串用法和屏幕显示。例如，依靠不断执行一些函数来发现内存泄漏的压力测试，但是显示的图形和文本可能没有关系。这些测试中的本地化测试，最底程度要让他们有用，将很简单。     底线是即使你有英文产品的一个强大的自动化测试套件，当你测试译文的时候也不会把速度加快很多。      本文到此翻译完毕，由于本人英语水平有限，其中难免有很多疏漏之处，请大家原谅。希望这篇文章给大家一些启示。谢谢。