加载中

在你开发的时候不要忘记性能测试

我的一个测试朋友最近来跟我抱怨,我认为在测试人员里这种抱怨很常见.。他说: “每一次有一个新版本软件发布让我们测试, 我们不得不重新编写测试脚本。”我的整个职业生涯没少听这种抱怨,不仅仅是性能测试即使用自动化工具进行功能测试也是一样.

这种情况有三个主要的原因:

  1. 改变是不可避免的。 每件事都在改变, 没有任何其他领域比软件开发领域显得更明显。测试人员让开发人员停止改变代码是不现实的, 但确实应该鼓励更合适的改变。
  2. 开发人员和测试人员的交流问题。 开发人员和测试人员之间隔的墙依然如GFW一样让人望而生畏。当开发者搁在墙扔出去一个新版本的时候,他们经常只能给测试人员一点关于如何测试的想法。
  3. 测试工具的不一致性。有一些工具对于改变的处理比其他的更胜一筹。如果你的测试工具可以很好的处理变化, 那么你们的团队就可以更轻松的拥抱变化而不是害怕变化。
j
jerrytao
翻译于 2013/01/22 23:15
1

像一个测试人员一样思考

大多数开发组织采取行动来加强开发人员和测试人员的交流,但是这并不总是能解决问题。除了鼓励开发人员和测试人员多说话, 我让他们在多做一些:像测试人员一样思考.。

我发现让开发者参加一些测试工程师进行的培训是个好主意。 以我的经验来看, 参加过培训的开发者会更加小心并且避免无意义的改变。例如,他们不再随便改变一个变量的名字,仅仅因为他们认为其他人起得名字不符合他们的看法。 当一个开发者认识到哪些改变会让测试变的更难,哪些改变会让测试更简单,从软件组织的观点来看,整个工作流程会更有生产力。

j
jerrytao
翻译于 2013/01/22 23:26
1

来自早期功能测试的类比

一些最早的测试GUI的自动化功能测试工具会简单的记录在测试的过程中鼠标在屏幕上的位置, 然后回放这些鼠标点击来执行测试脚本。 如果一个开发人员移动了屏幕上的一个按钮的位置,测试脚本将被破坏。 一些其他的工具将记录上按钮上的标签,所以移动按钮的位置不会破坏测试的脚本,但是改变标签的内容,比如从“Submit”改成“OK”将会破坏测试脚本。更高级的应用在脚本内用标识符来确认按钮, 这样开发者即使改变按钮的位置或者按钮的标签都不会让测试工作更困难。

这里的关键是对于那些在测试下开发的软件来说,测试工具的选择对测试团队的生产力有很大影响。

j
jerrytao
翻译于 2013/01/22 23:43
2

另一个关键教训是,开发人员的需要很长时间才能意识到开发工具可开发规程对平滑测试的促进作用。这是我在我多年前举办的一个训练课程中所亲眼看见的。当我讲述按钮标签的改变时如何影响到测试的时候,一个开发者坐直了身子,他终于明白了为什么当他做出修改时,他的进行测试的同事会有受挫感。 他一直不明白为什么他们极力反对他的一些修改,例如将按钮标签从“清空”改为“复位”。尽管在未来,这些知识并不会使得开发人员停止进行必要的更改。但它会让开发者停下来,考虑一下他所要做的改变,是否是有必要的。

K6F
K6F
翻译于 2013/01/24 09:37
1

使得变动更容易处理的性能测试工具

在性能测试中,我们不考虑按钮的位置,但是难免还是能看到细小的变动。

比如说,当提交一个页面表单到服务器的时候,那么表单域就是一系列的键值对,改变一个表单域的名称,或者增加删除一个表单域都会给性能测试带来问题。如果 没有一个更好的测试工具,这些问题将很难被识别和诊断,尤其是开发人员和测试人员之间的沟通很少。

文件差异查看器,能够让测试人员比较相互之间众多的记录,对找出被改变的表单域特别有帮助。当需要修改脚本的时候,一个有效的工具能够让你不用编程就能添加、删除、更新表单域。只需右击然后选择添加或者简单的拖放就甭更新你载入的测试脚本。

我只有这一个名字
我只有这一个名字
翻译于 2013/01/24 14:29
1

负载测试人员来说,表单域是相对比较容易处理。特定会话的参数更难处理(这些参数从一个会话改变到另一个会话,但是每一个用户会话的时间保持不变)。默认情况下,在每个脚本的负载测试工具中捕获硬编码会话的值,另外测试工程师需要可用于负载测试的参数值。在硬编码值上双击获取变量比在脚本代码中寻找更容易。在这里,自动化过程工具可以将测试时间从数小时缩减到几分钟。

当一个新的脚本的需求是基于现有脚本的,这些工具可以使任务加快几个数量级。

FGQ
FGQ
翻译于 2013/01/28 22:55
1

克服害怕变动

我听说开发团队逐渐变得越来越来害怕更改他们的软件,因为这些改动会给测试以及其他带来很多困扰。很显然,这很不利于他们完成新的功能和修复。说到底,问题的根源之一就是他们使用的测试工具,使得这些更改变得很吃力并且容易出错。一旦他们改变去使用更先进一点的工具,那么改动将会变得更容易。那么性能测试所花费的时间也将从星期为单位缩小为以天计,而开发也将可以长期根据需求做自由变动了。敏捷开发尤其需要这种能力快速实现测试脚本的更改,使得测试能够在几分钟或者几小时后就能继续下去而不是几天或者几星期。

所以,如果你们团队开始害怕变更,鼓励你们的开发人员像测试人员一样去思考,并且鼓励测试人员去使用能够使不可避免的更改更容易处理的测试工具。

我只有这一个名字
我只有这一个名字
翻译于 2013/01/24 13:10
1
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
加载中

评论(9)

crossmix
crossmix
test
Undeadway
Undeadway
开发人员和测试人员之间隔的墙依然如GFW一样让人望而生畏

看到这句,我喷了……
IT_小翼
IT_小翼

引用来自“Mallon”的评论

测试者都是男人?开发者都是女人?
哈哈

男人来自火星女人来自金星
红薯
红薯

引用来自“jerrytao”的评论

@铂金小熊 不好意思 linux输入法 许多词不太习惯。。
@红薯 我找了半天没找到编辑在哪。。。

我改好了,翻译必须在24小时内编辑,超过24小时就不允许了
j
jerrytao
@铂金小熊 不好意思 linux输入法 许多词不太习惯。。
@红薯 我找了半天没找到编辑在哪。。。
赵开锦
赵开锦
这种流程太正规了把,能适应国内的情况吗?比如我们公司,有5个开发写代码,但有8个产品经理+1个CTO+1个CEO共10个人都可以改需求,经常早上产品经理A觉得某个地方不好,要求开发修改,下午产品经理B可能会在A的需求上做进一步的补充,然后晚上CTO或其他某个人又会反驳掉B的需求改成别的,如此种种,曾有过个页面一个礼拜做过12次需求变动的,像文章中的描述,这得消耗多少时间啊,这种开发早就被产品经理或领导开除了
苗哥
苗哥
第七行“搁在墙”应该是“隔着墙”,写错字了。@jerrytao @红薯 @王振威
夲仒無道
夲仒無道
性能,唉,码农考虑什么性能...能用就行。
mallon
mallon
测试者都是男人?开发者都是女人?
哈哈
返回顶部
顶部