2009年，毕业后的第二年，上半年在MySpace，下半年在FreeWheel。测试技术上，有1年多的白盒测试经验，不过由于工作调动，现在已经没有做了，不过还好，还没有离开代码。在新的单位里面主要跟以下东西打交道，数据仓库，ETL工具，报表脚本，自动化回归测试框架，在线广告的业务逻辑。 在FreeWheel已经4个月了，工作开始上手，新的公司同事的素质都非常高，就我们Core来说吧，清华北大的占了一大半，第一次跟那么多非常聪明的人一起工作，有点兴奋，压力。公司发展的势头不错，我从进公司到现在，短短四个月，ad servering的流量应该翻了5倍吧。明年应该会增长的更加快，cool！ 明年工作上主要还是集中在数据库相关技术，自动化回归测试框架，Python应该是主要的编程语言。 keep learning…
最近在修改公司现有的一个自动化测试框架，里面用了很多time.sleep()方法，看着不是很爽，为什么我觉得sleep方法在自动化测试中不应该过多的使用呢，我甚至觉得应该尽可能避免sleep方法的使用，sleep可以作为增加自动化测试稳定性的手段，但是不能依赖sleep来让自动化系统稳定。 举个例子，如果一个UI的自动化测试，需要等待某个页面load完成以后才进行操作，那么需要对那个页面是否已经Load完成进行判断，而不应该sleep(x)，x是一个magic number，有时候1、2秒就足以，有时候它却不知道有多大，因为已经超时了！那如果我们在check页面状态之前做一个短时间的sleep，那么在某些场合下可以增加这个自动化测试的稳定性，但是最终整个自动化测试的脚本是不会依赖于这个sleep的语句来达到稳定的。 在做自动化测试的时候，最常见的两种判断就是1. 某程序已经成功启动，某页面已经加载完毕。 2. 某程序已经正常关闭，某服务已经顺利停止。 回到实际的工作，我要判断被测的程序是否已经正常启动，可以用系统提供的一些工具，或者调用一些接口，例如SNMP命令，或者是调用一下Lua脚本等，如果他们都返回我们期望的数据，那么可以认为程序已经成功启动了。反之，如果前面的这些命令出错了，那么我也可以认为程序已经是关闭了的。 要实现自动化测试，就必须要让测试代码每时每刻都掌握着被测系统的状态，sleep方法会让自动化测试脚本的行为变得诡异。
在一个公司或者是某个组织里面，测试人员扮演的角色通常都会被认为是软件质量的保证者，把关者，仿佛经过测试的产品都是没有任何缺陷的。但事实大家都知道，即使经过多么“完美”测试的产品，总免不了在发布以后还会发现或多或少的问题。 以前在MySpace做测试的时候，主要是写代码来测试一些接口、模块等。这样就会出现一个问题，我用一段程序A去测试层序B，那么测试代码也是程序，如何保证程序A的正确性呢？OK，我们可以写一个程序C去测试程序A，由此来保障程序A的正确性，但是程序C的正确性又由谁来保证呢？who watches the watchers？当时只有我一个人负责白盒测试，最多也就是让开发帮忙看看。其实对于一段程序，只要写的足够简单，那么就可以认为这段简单的程序的正确性是能得到保证的。所以我一直都给自己强调，单元测试的代码不要写的复杂，尽可能不用判断，让测试代码顺序执行下去。 但是对于功能测试来说，怎么样才能尽可能地保证测试的方法，测试的数据，测试的覆盖率是能达到某项标准的呢？在这次MRM 2.9 Release的测试过程中，我们引入了peer review的做法，一个功能点一般会以ticket的形式存在，每个人拿到ticket的时候首先自己设计测试用例，包括测试数据的准备，用什么样的方法等等。然后找另外一个同事来review自己的用例。这样做的好处有： 强迫自己有一个较为系统的测试用例设计，因为这个是需要给同事看，并且让别人看懂的 同事之间的knowledge share在不知不觉中就达到 两个人的review总是比一大群人坐到会议室里面要有效，帮助提高测试覆盖率，尽可能避免测试盲点 互相监督
Python语言本身是没有注释多行的支持的，如果需要注册多行，可以用一个取巧的方法，就是把需要注释的代码块用三个括号括起来，赋值为一个永远都不会使用的字符串变量，例如： 1 2 3 4 5 6 7 8 9 10 11 12 13 __devilcomment = ”’ if bCmpLog == "True": self.appendAdsLogToCmpLog("") if bCmpBinaryLog == "True": self.appendBinaryAdsLogToCmpLog(res) if bCompareResp == "True": self.appendResponseToCmpLog(response_strs) print "move new and debug logs" self.tools.move (src_db,dst_db) ”’
如果使用过微软技术的朋友应该体会过微软的Visual Studio系列IDE给debug程序带来的方便，换了个工作就没有Visual Studio了，对于我这种从未在非GUI环境下调试过程序的人来说实在有点不爽，今天花了点时间看了一下Python自带的pdb库，发现用pdb来调试程序还是很方便的，当然了，什么远程调试，多线程之类，pdb是搞不定的。 用pdb调试有多种方式可选： 1. 命令行启动目标程序，加上-m参数，这样调用myscript.py的话断点就是程序的执行第一行之前 python -m pdb myscript.py 2. 在Python交互环境中启用调试 >>> import pdb >>> import mymodule >>> pdb.run(‘mymodule.test()’) 3. 比较常用的，就是在程序中间插入一段程序，相对于在一般IDE里面打上断点然后启动debug，不过这种方式是hardcode的 if __name__ == "__main__": a = 1 import pdb pdb.set_trace() b = 2 c = a + b print (c) 然后正常运行脚本，到了pdb.set_trace()那就会定下来，就可以看到调试的提示符(Pdb)了 常用的调试命令 h(elp)，会打印当前版本Pdb可用的命令，如果要查询某个命令，可以输入 h [command]，例如：“h l” — 查看list命令 l(ist)，可以列出当前将要运行的代码块 (Pdb) l 497 pdb.set_trace() [...]
