在Lua中实现简单的StringBuffer

在Lua中,字符串是一个常量,如果用字符串连接符“..”把2个字符串连接起来,例如first_str = first_str .. second_str,那么原来的first_str和second_str就会作为垃圾等待回收,first_str引用的是一个新的字符串,如果在程序里面有大量的字符串连接操作的话,性能会十分低下。Lua是一个很简洁的语言,他没有StringBuffer的实现,但是其实我们可以动手写一个简单的StringBuffer实现,来避免性能的问题。

首先定义一个叫StringBuffer的table,使得这个StringBuffer被调用的时候看起来像是面向对象的样子 :)
然后分别定义两个方法append和tostr,实现的原理就是:append用table来保存所有字符串,tostr把保存了字符串的table用concat转成真正的字符串。

StringBuffer = {}
StringBuffer.append =  function(t, str)
if t and str then
    table.insert(t, str)
end
end
StringBuffer.tostr =  function(t)
if t then
    return table.concat(t)
end
end
StringBuffer.new = function() return {} end

调用的时候大概如下,摘录了一段代码。。。

all_assets = StringBuffer.new()
for asset in ctx:allassets() do
    StringBuffer.append(all_assets, asset:id())
    StringBuffer.append(all_assets, ', ')
end
result = StringBuffer.tostr(all_assets)
print (result)

在Lua中实现这样的一个StringBuffer,既可以避免潜在的性能问题,又可以使得代码看起来更加易懂~好了,重构以前的代码去了。。。

敏捷测试只是手段不是目的

首先我要声明:本人不懂敏捷测试。
敏捷开发在这两年一直很火,很多时候作为一个测试人员,经常会“被敏捷”。一些常见的现象有,当你所要文档的时候,相关人员可能会告诉你“我们是敏捷开发,没有文档”;当你索要进度表的时候,答案也是相似的。既然软件开发已经迈入了敏捷时代,那么软件测试还能原地踏步麽?那什么是敏捷测试?我不知道,不过我想说说我在“敏捷”组织里面进行软件测试的经历。
由于我不懂敏捷测试,所以我不知道它的定义,我只能通过“敏捷测试不是传统测试”这样的思路来开展工作。
首先,那种拿着各种需求文档设计文档来设计Test Case的日子是一去不复返了,因为敏捷开发强调的是能工作的软件比漂亮的文档要有用,人和人之间的沟通胜于文档。所以作为我,一个测试员,我对被测软件的知识的了解来源有2个方面,第一是代码,第二是开发人员。
其次,如果在测试过程中发现一个问题,第一件事情并不是把这个问题记录在Tracking system里面,而是找相关的开发和产品进行确认,究竟这是不是一个真的Defect。
然后,需要知道一个现在很流行的新玩意儿:探索性测试(Exploratory Testing)。每个人对Exploratory Testing的定义都不一样,最近两个大牛(James Bach, James Whittaker)也在掐架。我觉得如果简化这个定义的话,就是我们一边熟悉被测软件,一边进行测试,在测试进行的过程中,随着对软件的熟悉,继而设计出新的Test case来对被测软件进行测试,我个人觉得就像是一个小的迭代一样。
最后,忘记敏捷测试这个词。我觉得现在业界能说清楚这个概念的人很少,所以没有必要在这些定义上纠结。人们为什么要实施敏捷开发,是因为想交付更好的软件;我们为什么要实施敏捷测试,是想提高测试的质量以及生产力,从而帮助公司交付更加高质量的产品,至于是不是真正的敏捷,又有什么重要的呢