我的测试生活感悟1

有些天没有更新博客了,有的时候想到一些东西,打算把它写下来时发现时间不够,有时写着写着发现自己开始长篇大论,原本一两句话可以说清楚的事情,非要用几个段落来描述。当我看完一本几百页的书时,真正记住的原文内容不会很多,通过自己总结,大约可以用10句话来描述。因此,我打算用一种简洁的、无废话的方式记录一些测试生活中的一些感悟。这篇是开篇,酝酿了好久,万事开头难。


1. 真的是万事开头难,但我觉得更难的是,每天都坚持做同一件事情。在不被强迫的情况下(如:上班、吃饭、睡觉...),在可自由支配的时间里,现在我每天坚持做的貌似只有GoogleReader。希望我的测试感悟系列也能坚持下来。 2. 在做模块的接口测试过程中,发现开发所犯的错误大多是一些低级的,深刻领悟到:复制粘贴是代码最大的隐患! 3. 最近发现一个BUG,是开发解析xml错了,导致有的节点内容未读上来。就这样一个BUG描述,根本看不出它对产品有多大的影响,也许最了解的人,就是开发自己了。 4. 写的模块接口测试案例多了,渐渐发现了一些自己的代码风格,也许以后可以开专题来讲解一下。测试代码和产品代码是有很大区别的,测试代码其实是有通用的一些 模式的,不然就不会出现XUnit之类的东西。可以说XUnit也是一种风格约束。我总结出来的自己的测试代码都会分成以下几个部分:
* **Caller**
对开发接口函数调用的包装,使得案例有一个统一的入口调用开发的函数。开发接口函数变动,只需要变动我们的Caller。(封装变化)
* **Checker**
对接口函数调用的验证方式的封装。对被测函数的返回值检查是最基本的,更多的时候,返回值并不能告诉你一切,返回值告诉你它做了什么,但它没有证明给你看它确实做到了
* **DataDefine**
测试数据是必不可缺的,我将测试数据单独抽离出来,方便管理和组织。
* **TestFixtureBases**
TestFixture的基类,这是我喜欢使用的方式,定义某一类案例的基类,它们做同样的SetUp和TearDown,共享同样的函数调用。
* **TestCases**
最终到了测试案例这一分类,如果我们把上面的四个分类都做好了,就会发现,测试案例都可以使用一种非常简洁的方式来表达。在我看来,一个测试案例代码,五行左右代码是最优美的。
* (附加)**CommonSpec**
有时候,为了让测试案例更加容易理解,我还喜欢使用BDD的方式表述测试案例。因此,我个人可能还会有一个分类叫CommonSpec,定义的一些自然语言相关的函数。可能这个并不一定适合每个人。 5. 上周五去听了一个关于软件架构师的课程,总结一下大约有如下几点收获:
* 架构师首先要明白真正需要解决的问题是什么。例子:老太太买梨 * 一个优秀的架构师,必须有一套自己明确的方法论。 * 政治->经济->技术,架构师容易只看到技术上的问题,其实有时技术问题并不是最大的问题。 * 架构师是参谋长,也是辅导员。有了自己的架构设计,还要将自己的架构设计描述清楚,并推动设计方案的实施。 *  (概念部分)架构师的定义,分类,架构设计的过程等等。
如果您觉得有用,请您告诉我,谢谢!

[温馨提示]:该文章由原博客园导入而来,如排版效果不佳,请移步:http://www.cnblogs.com/coderzh/archive/2009/09/06/MyTestingThink1.html

微信扫一扫交流

作者:CoderZh
微信关注:hacker-thinking (一个程序员的思考)
本文出处:https://blog.coderzh.com/2009/09/06/MyTestingThink1/
文章版权归本人所有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。