提高自动化测试套件的可维护性 - 6

原创 2004年05月24日 09:56:00

 

用于自动化测试的值是不确定(比如随机)的尽管我们需要确定测试用例的方法。(一致通过)<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

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

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

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

 

 

人力和管理

 

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

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

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

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

 

数据驱动方法

  

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

 

数据驱动策略的主题包含(举例):

输入程序的参数

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

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

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

文档记录程序读取和操作

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

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

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

 

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

框架驱动方法

   

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

 

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

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

 

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

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

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

 

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

   

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

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

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

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

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

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

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

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

 

本地化

   

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

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

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

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

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

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

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

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

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

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

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

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

   

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

 

提高自动化测试套件的可维护性 - 2

思考可维护性脚本维护的需求不是不需要,而是卖自动化工具的人没有提到这点而已。在二月LAWST会议上我们不停的讨论两件事。当软件用户界面发生变化的时候,你们要做多少修改测试脚本的工作能让脚本正确适应软件...
  • piaocl
  • piaocl
  • 2004年05月21日 13:17
  • 2275

提高自动化测试套件的可维护性 - 1

                                                作者:Cem Kaner                                        ...
  • piaocl
  • piaocl
  • 2004年05月19日 13:23
  • 1594

提高自动化测试套件的可维护性 - 3

3.利用数据驱动体系 在讨论成功的工程中,我们得出两种分类,分别是数据驱动设计和基于框架的设计。他们可以孤立也可以集成在一起。一个数据驱动的例子:假设测试一个用户创建和打印表格的程序。你要处理这样几件...
  • piaocl
  • piaocl
  • 2004年05月21日 14:29
  • 2249

提高自动化测试套件的可维护性 - 5

 6.考虑用其他自动化测试类型 LAWST会议上主要集中在GUI层次上衰退测试工具,所以这篇文章主要写的是关于这方面的。在开会前我们参加会议的人主要描述了我们在测试自动化中的经验。一些人作了生动的成功...
  • piaocl
  • piaocl
  • 2004年05月23日 17:31
  • 2151

提高自动化测试套件的可维护性 - 4

 在你创建的库中很多函数可以在几个应用程序中用(或者你把他们设计得很灵活)。不要期望百分之百的灵活。比如openfile函数的一个版本中可能对每个用到标准文件对话框的程序都有用,但是你有些时候你要用到...
  • piaocl
  • piaocl
  • 2004年05月21日 18:08
  • 2132

如何提高代码可读性、可维护性

高质量代码的三大要素: 可读性、可维护性和可变更性 做好代码规范、提高代码质量,能显著增强代码的可读性、可维护性和可变更性。努力提高代码的读写可维护性,是做好代码规范的必要非充分条件。代码规范和架...
  • zm1_1zm
  • zm1_1zm
  • 2016年07月21日 16:05
  • 3057

保持应用系统可维护性的八个实际措施

应用系统的可维护性: 整体组织;逻辑分割;细粒度措施;技术决策; 一致处理;有效隔离;消除重复; 对维护敏感...
  • shuqin1984
  • shuqin1984
  • 2013年09月03日 18:00
  • 3762

提高程序的可读性以及可维护性

对于简单的一个for循环,如: for(int i =1; i { //proceeding } 从语法上来讲,上述语句完全没有问题。但是可读性及可扩展性差,为什么呢? 因为使用了100这...
  • GeniusSnail
  • GeniusSnail
  • 2012年04月14日 12:54
  • 1377

《java与模式》笔记(一) 软件的可维护性和可复用性

ξ 3.1 软件系统的可维护性☆ 导致一个软件设计的可维护性较低,也就是说会随着性能要求的变化二“腐烂”的真正原因有四个: ① 过于僵硬 加入一个新性能,不仅仅意味着建造一个独立的模块,而且因为这个新...
  • plusir
  • plusir
  • 2006年08月05日 12:27
  • 1237

谈谈软件的可维护性问题

前言       很多包括自己在内的开发人员都会经常去借用(我们不用剽窃这个词了!呵呵)开源代码进行二次开发;或者在前辈的遗留代码下,继续修修补补。这种经历往往并不像看起来那么简单——有时看懂,进而修...
  • kanghua
  • kanghua
  • 2008年12月30日 17:08
  • 15859
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:提高自动化测试套件的可维护性 - 6
举报原因:
原因补充:

(最多只允许输入30个字)