经常听到会有人抱怨道，怎么这段代码没有注释啊，这是为什么这样写的啊，如此云云。仿佛没有注释，这个世界就不转了。类似的事情也经常发生在QA们的身边，只不过注释换成了文档。

刚毕业的时候做白盒测试，现在回想起来，那时候的我测试的代码大部分都是不包含注释的，不过我测试起来并没有太大的困难，总结一下，应该有以下几点原因：

1. 有意义的函数名、变量名。函数的命名让人一看就大概知道在做什么，例如PostBlog就是发布一篇博客，如果遇到一个叫SaveProfile的方法但做的却是加好友，那我想再多的注释我也会头晕
2. 代码不会说谎。根据经验，如果一段代码理解起来很费劲，那么通常里面都会隐藏着问题。代码就是最好的注释，一些过时的注释，设置会对阅读代码的人产生误导
3. 充分的沟通。虽然游走于几个项目组，跟不同的开发人员打交道，但是每当遇到问题的时候总会主动跟相关的人沟通，一个活生生的人坐在那里不问，却迷信什么文档，这真是本末倒置

注释，能不写就别写，实在要写，写WHY而不是WHAT。

联系一下最近在Team内写的一个新的回归测试工具，里面基本没有注释，希望过几个月以后，自己还能够看看代码就知道当时那段代码为什么这样写。

No related posts.

用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是不会进入被调用的函数体中的

• s(tep)，跟n相似，但是如果当前有一个函数调用，那么s会进入被调用的函数体中

• c(ont(inue))，让程序正常运行，直到遇到断点

• j(ump)，让程序跳转到指定的行数

(Pdb) j 497
> /home/jchen/regression/regressionLogCMP.py(497)compareLog()
-> pdb.set_trace()

• a(rgs)，打印当前函数的参数

(Pdb) a
_logger =
_base = ./base/MRM-8137.log
_new = ./new/MRM-8137.log
_caseid = 5550001
_toStepNum = 10
_cmpMap = {‘_bcmpbinarylog’: ‘True’, ‘_bcmpLog’: ‘True’, ‘_bcmpresp’: ‘True’}

• p，最有用的命令之一，打印某个变量

(Pdb) p _new
u’./new/MRM-8137.log’

• ！，感叹号后面跟着语句，可以直接改变某个变量

• q(uit)，退出调试

发现在命令行下调试程序也是一件挺有意思的事情，记录下来分享一下

Related posts:

1. Python多行注释技巧

首先定义一个叫StringBuffer的table，使得这个StringBuffer被调用的时候看起来像是面向对象的样子 ：）
然后分别定义两个方法append和tostr，实现的原理就是：append用table来保存所有字符串，tostr把保存了字符串的table用concat转成真正的字符串。

StringBuffer = {}
StringBuffer.append =  function(t, str)
if t and str then
    table.insert(t, str)
end
end
StringBuffer.tostr =  function(t)
if t then
    return table.concat(t)
end
end
StringBuffer.new = function() return {} end

调用的时候大概如下，摘录了一段代码。。。

all_assets = StringBuffer.new()
for asset in ctx:allassets() do
    StringBuffer.append(all_assets, asset:id())
    StringBuffer.append(all_assets, ', ')
end
result = StringBuffer.tostr(all_assets)
print (result)

在Lua中实现这样的一个StringBuffer，既可以避免潜在的性能问题，又可以使得代码看起来更加易懂~好了，重构以前的代码去了。。。

No related posts.

No related posts.

测试的过程中在数据库里面找到一张表，还知道一个GET这张表的数据的存储过程，想找一下有没有其他操作这张表的存储过程要怎么办呢？运行上面的存储过程就可以了。例如说某张数据表的名字是“UserRankStatus”，那么就用“UserRankStatus”替换了上面的“特定字符”就好了。这个存储过程是偶然在网上找到，出处是“怡红公子”，也就是我们公司的DBA。世界真小，囧……

No related posts.

• 用户是谁
• 当前用户是否真的是他所代表的角色

通常来说，一个登陆系统，就是一个认证的系统。

那么授权（Authorization）又是什么呢？授权通常是用来回答以下问题：

• 用户A是否被授权访问资源R
• 用户A是否被授权执行P操作

常见的例如密码相册那些应用，就是应用到了授权系统。

No related posts.

这个定义可能有点拗口，一个最简单的例子就是有资源A和资源B，都是不可剥夺资源，现在进程C已经申请了资源A，进程D也申请了资源B，进程C接下来的操作需要用到资源B，而进程D恰好也在申请资源A，那么就引发了死锁。这个肯定每个人都看过了。然后套用回去定义：如果一个进程集合里面（进程C和进程D）的每个进程（进程C和进程D）都在等待只能由这个集合中的其他一个进程（对于进程C，他在等进程D；对于进程D，他在等进程C）才能引发的事件（释放相应资源）。

这里的资源包括了软的资源（代码块）和硬的资源（例如扫描仪）。资源一般可以分两种：可剥夺资源（Preemptable）和不可剥夺资源（Nonpreemptable）。一般来说对于由可剥夺资源引起的死锁可以由系统的重新分配资源来解决，所以一般来说大家说的死锁都是由于不可剥夺资源所引起的。

死锁的四个必要条件

1. 互斥条件（Mutual exclusion）：资源不能被共享，只能由一个进程使用。
2. 请求与保持条件（Hold and wait）：已经得到资源的进程可以再次申请新的资源。
3. 非剥夺条件（No pre-emption）：已经分配的资源不能从相应的进程中被强制地剥夺。
4. 循环等待条件（Circular wait）：系统中若干进程组成环路，改环路中每个进程都在等待相邻进程正占用的资源。

处理死锁的策略

1. 忽略该问题。例如鸵鸟算法，该算法可以应用在极少发生死锁的的情况下。为什么叫鸵鸟算法呢，因为传说中鸵鸟看到危险就把头埋在地底下，可能鸵鸟觉得看不到危险也就没危险了吧。跟掩耳盗铃有点像。
2. 检测死锁并且恢复。
3. 仔细地对资源进行动态分配，以避免死锁。
4. 通过破除死锁四个必要条件之一，来防止死锁产生。

No related posts.