我的测试生活感悟1
有些天没有更新博客了,有的时候想到一些东西,打算把它写下来时发现时间不够,有时写着写着发现自己开始长篇大论,原本一两句话可以说清楚的事情,非要用几个段落来描述。当我看完一本几百页的书时,真正记住的原文内容不会很多,通过自己总结,大约可以用10句话来描述。因此,我打算用一种简洁的、无废话的方式记录一些测试生活中的一些感悟。这篇是开篇,酝酿了好久,万事开头难。
- 真的是万事开头难,但我觉得更难的是,每天都坚持做同一件事情。在不被强迫的情况下(如:上班、吃饭、睡觉...),在可自由支配的时间里,现在我每天坚持做的貌似只有GoogleReader。希望我的测试感悟系列也能坚持下来。
- 在做模块的接口测试过程中,发现开发所犯的错误大多是一些低级的,深刻领悟到:复制粘贴是代码最大的隐患!
- 最近发现一个BUG,是开发解析xml错了,导致有的节点内容未读上来。就这样一个BUG描述,根本看不出它对产品有多大的影响,也许最了解的人,就是开发自己了。
- 写的模块接口测试案例多了,渐渐发现了一些自己的代码风格,也许以后可以开专题来讲解一下。测试代码和产品代码是有很大区别的,测试代码其实是有通用的一些 模式的,不然就不会出现XUnit之类的东西。可以说XUnit也是一种风格约束。我总结出来的自己的测试代码都会分成以下几个部分:
- Caller
对开发接口函数调用的包装,使得案例有一个统一的入口调用开发的函数。开发接口函数变动,只需要变动我们的Caller。(封装变化)
- Checker
对接口函数调用的验证方式的封装。对被测函数的返回值检查是最基本的,更多的时候,返回值并不能告诉你一切,返回值告诉你它做了什么,但它没有证明给你看它确实做到了
- DataDefine
测试数据是必不可缺的,我将测试数据单独抽离出来,方便管理和组织。
- TestFixtureBases
TestFixture的基类,这是我喜欢使用的方式,定义某一类案例的基类,它们做同样的SetUp和TearDown,共享同样的函数调用。
- TestCases
最终到了测试案例这一分类,如果我们把上面的四个分类都做好了,就会发现,测试案例都可以使用一种非常简洁的方式来表达。在我看来,一个测试案例代码,五行左右代码是最优美的。
- (附加)CommonSpec
有时候,为了让测试案例更加容易理解,我还喜欢使用BDD的方式表述测试案例。因此,我个人可能还会有一个分类叫CommonSpec,定义的一些自然语言相关的函数。可能这个并不一定适合每个人。
- Caller
- 上周五去听了一个关于软件架构师的课程,总结一下大约有如下几点收获:
- 架构师首先要明白真正需要解决的问题是什么。例子:老太太买梨
- 一个优秀的架构师,必须有一套自己明确的方法论。
- 政治->经济->技术,架构师容易只看到技术上的问题,其实有时技术问题并不是最大的问题。
- 架构师是参谋长,也是辅导员。有了自己的架构设计,还要将自己的架构设计描述清楚,并推动设计方案的实施。
- (概念部分)架构师的定义,分类,架构设计的过程等等。
如果您觉得有用,请您告诉我,谢谢!
![](https://blog.coderzh.com/public/qrcode.jpg)
微信扫一扫交流
作者:CoderZh
公众号:hacker-thinking (一个程序员的思考)
独立博客:http://blog.coderzh.com
博客园博客将不再更新,请关注我的「微信公众号」或「独立博客」。
作为一个程序员,思考程序的每一行代码,思考生活的每一个细节,思考人生的每一种可能。
文章版权归本人所有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。