我的测试生活感悟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. 上周五去听了一个关于软件架构师的课程，总结一下大约有如下几点收获：
   • 架构师首先要明白真正需要解决的问题是什么。例子：老太太买梨
   • 一个优秀的架构师，必须有一套自己明确的方法论。
   • 政治->经济->技术，架构师容易只看到技术上的问题，其实有时技术问题并不是最大的问题。
   • 架构师是参谋长，也是辅导员。有了自己的架构设计，还要将自己的架构设计描述清楚，并推动设计方案的实施。
   •  (概念部分)架构师的定义，分类，架构设计的过程等等。
     

如果您觉得有用，请您告诉我，谢谢！