qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

重构——构筑测试体系

 构筑测试体系

  如果你想进行重构,首要前提就是要拥有一个可靠的测试环境。

  “编写优良的测试程序,可以极大的提高我的编程速度,即使不进行重构也是如此。”

  1、自我测试代码(Self-testing Code )的价值

  “Class 应该包含他们自己的测试代码。”

  “每个Class 都有一个测试函数,并用它测试自己这个 Class 。”

  确保所有的测试都完全自动化,让它们检查自己的测试结果。

  只要写好一点功能,就立即添加测试。

  一整组(a suite of )测试就是一个强大的“臭虫”侦测器,能够大大缩减查找“臭虫”所需要的时间。

  “实际上,编写测试代码的最有用时机是在开始编程之前。当你需要添加特性的时候,先写相应的测试代码。听起来离经叛道,其实不然。填写测试代码其实就是问自己:添加这个功能需要做什么。编写测试代码还能使你把注意力集中于接口而非实现上头(永远是件好事)。预先写好的测试代码也为你的工作按上一个明确的结束标志:一旦测试代码运行正常,工作就可以结束了。”

  构建自我测试的代码。

  2、JUnit测试框架( Testing Framew )

  频繁的运行测试,每次编译请把测试也考虑进去,每天至少执行每个测试一次。

  单元测试功能测试

  “每当你接获臭虫提报,请先撰写一个单元测试来揭发这只臭虫。”——如何揭发?这里需要根据报告准确定位。单元测试会对此有帮助吗?

  3、添加更多的测试

  “观察Class 该做的所有事情,然后针对任何一项功能的任何一种可能失败的情况,进行测试。”

  “测试应该是一种风险驱动(risk driven )行为,测试的目的是希望找出现在或未来的可能出现的错误。”

  “测试的诀窍是:测试你最担心的部分。”

  这点和我目前的想法不大相同。我目前的想法是,测试要对程序做100% 的保证,所以,要测试程序可能行为的每一种情况,保证其正确性。按照我的想法,值域的设置和访问函数也是要测试的。作者的意思是,测试代码要用最低的成本,获取最大的收益。这一点,要我在实际的环境中进行抉择。

  “编写不是十分完美的测试并实际运行,好过对完美测试的无尽等待。”——我持怀疑态度。

  运用测试用例前后执行的函数:tearDown 和 setUp,保证测试用例之间相互隔离,而非相互影响。

  做一个懒惰的程序员。

  考虑可能出错的边界条件,把测试火力集中在那儿。

  “测试(优先)可以调高编程速度”,这一点我要在实践中验证一下,如果真是这样,那我就要尝试在我们部门推行这种方法。

  “当测试达到一定的程度后,测试效益会呈现递减态势。”所以,你不要期望通过测试找出所有的bug ,而是要通过测试,找出绝大多数的 bug 。

  这个地方其实也符合“二八定律”:即20% 的测试可以找出 80% 的 bug,其余的 80% 的测试可以找出剩下的 20% 的 bug 。我们要做的,就是写这 20% 的测试,而非 100% 的测试。

posted on 2011-12-05 14:24 顺其自然EVO 阅读(124) 评论(0)  编辑  收藏


只有注册用户登录后才能发表评论。


网站导航:
 
<2011年12月>
27282930123
45678910
11121314151617
18192021222324
25262728293031
1234567

导航

统计

常用链接

留言簿(54)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜