年终总结,新年展望

2009年,毕业后的第二年,上半年在MySpace,下半年在FreeWheel。测试技术上,有1年多的白盒测试经验,不过由于工作调动,现在已经没有做了,不过还好,还没有离开代码。在新的单位里面主要跟以下东西打交道,数据仓库,ETL工具,报表脚本,自动化回归测试框架,在线广告的业务逻辑。

在FreeWheel已经4个月了,工作开始上手,新的公司同事的素质都非常高,就我们Core来说吧,清华北大的占了一大半,第一次跟那么多非常聪明的人一起工作,有点兴奋,压力。公司发展的势头不错,我从进公司到现在,短短四个月,ad servering的流量应该翻了5倍吧。明年应该会增长的更加快,cool!

明年工作上主要还是集中在数据库相关技术,自动化回归测试框架,Python应该是主要的编程语言。

keep learning…

自动化测试中的sleep

最近在修改公司现有的一个自动化测试框架,里面用了很多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自己的用例。这样做的好处有:

  1. 强迫自己有一个较为系统的测试用例设计,因为这个是需要给同事看,并且让别人看懂的
  2. 同事之间的knowledge share在不知不觉中就达到
  3. 两个人的review总是比一大群人坐到会议室里面要有效,帮助提高测试覆盖率,尽可能避免测试盲点
  4. 互相监督

Python多行注释技巧

Python语言本身是没有注释多行的支持的,如果需要注册多行,可以用一个取巧的方法,就是把需要注释的代码块用三个引号括起来,赋值为一个永远都不会使用的字符串变量,例如:

__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)
'''

用PDB库调试Python程序

如果使用过微软技术的朋友应该体会过微软的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()
498 base_data = {}
499 new_data = {}
500 try:
501 execfile(base_file_name,{},base_data)
502 -> execfile(new_file_name,{},new_data)
503 except:
504 logger.writeLog(“error! load result log error!”)
505 print “load cmp logs error!”
506 raise Exception, “load cmp logs error!”
507

  • b(reak), 设置断点,例如 “b 77″,就是在当前脚本的77行打上断点,还能输入函数名作为参数,断点就打到具体的函数入口,如果只敲b,会显示现有的全部断点

(Pdb) b 504
Breakpoint 4 at /home/jchen/regression/regressionLogCMP.py:504

  • condition bpnumber [condition],设置条件断点,下面语句就是对第4个断点加上条件“a==3”

(Pdb) condition 4 a==3
(Pdb) b
Num Type Disp Enb Where
4 breakpoint keep yes at /home/jchen/regression/regressionLogCMP.py:504
stop only if a==3

  • cl(ear),如果后面带有参数,就是清除指定的断点(我在Python2.4上从来没成功过!!!);如果不带参数就是清除所有的断点

(Pdb) cl
Clear all breaks? y

  • disable/enable,禁用/激活断点

(Pdb) disable 3
(Pdb) b
Num Type Disp Enb Where
3 breakpoint keep no at /home/jchen/regression/regressionLogCMP.py:505

  • n(ext),让程序运行下一行,如果当前语句有一个函数调用,用n是不会进入被调用的函数体中的

Continue reading “用PDB库调试Python程序”