《测试之道》

显示全部楼层 · 2014-2-19 11:55:14

《测试之道》第一篇——道可道
1、道可道
老子《道德经》：道可道，非常道；名可名，非常名。
其实你一切都会，只是看你有没有悟到你的确会。
说到测试，无论是专业的测试专家还是对策是一无所知的门外汉，首先要提到的肯定是“测试有什么
用？”花那么多的人力物力和金钱做的测试到底是为了什么？”很多所谓的专业书籍对此讲了很多让人眼
花缭乱的理论。
然而其实很简单，测试就是为了让产品在交付给最终用户以后，在产品生存周期（或提供有效服务的
期限以内），不让最终用户发现其所不能接受的现象。只要能不让用户发现其不能接受的一切现象，至于
产品是否存在bug，用户不会关心；因此IT企业也就没有必要关心。
最后再补充一点：世界上最浩瀚的是大海，比大海更浩瀚的是天空，比天空更浩瀚的是人的心灵。
人的心灵里其实什么都知道，什么都会做。
随心所欲，不滞于物；行云流水，任意所至。独孤九剑的总则便是如此。

千问 · 2014-2-19 11:55:14

《测试之道》第二篇——大道如一，过犹不及
2、大道如一，过犹不及
为了让bug不被用户发现，测试是不是用该做的越深入越好？不止门外汉会这样认为，即便测试业界
的很多一些人也会这样认为。
《论语》有言：子贡问，“师与商也孰贤？”子曰，“师也过，商也不及。”曰，“然则师愈与？”
子曰，“过犹不及。”
译为现代汉语就是：
　　子贡问曰，“子张和子夏哪个能干？”孔子说，“子张过头了些，子夏不够了些。”子贡说，“那么
是子张强一些了？”孔子说，“过分和不及，同样都不好。”
所谓大道如一，测试亦然。投入的不够，则会不能在交付给用户之前发现bug；投入的过多，则会影
响收益。过犹不及，二者都不不够好的。
然而把握这个度还是极难的，没有一个可量化的标准。通常可以做到的就是两害相权取其轻了，对于
容忍力较强的客户，使用“不及”就可以了，用户发现了bug，召回产品打个补丁再重新发布就行了。
“XX产品存在重大隐患，被XX厂商召回”这样的新闻怕是在国内并不少见吧，其他行业如此，IT业能例外
乎？对于重要的客户，就不得不采用“过”的方式了。尤其一些需要“算政治账，不要算经济账”的项目
上更是如此了。

千问 · 2014-2-19 11:55:14

《测试之道》第三篇——吴钩霜雪明
3、吴钩霜雪明
李白《侠客行》：赵客缦胡缨，吴钩霜雪明。银鞍照白马，飒沓如流星。十步杀一人，千里不留行。
事了拂衣去，深藏身与名。闲过信陵饮，脱剑膝前横。将炙啖朱亥，持觞劝侯嬴。三杯吐然诺，五岳倒为
轻。眼花耳热后，意气素霓生。救赵挥金槌，邯郸先震惊。千秋二壮士，煊赫大梁城。纵死侠骨香，不惭
世上英。谁能书閤下，白首太玄经。
各个待测试的目标系统就是世间各个芸芸众生，测试工程师(TE)就是IT业的侠客。TE离不开测试用例
(TC)就如同侠客离不开剑。无剑不成侠；无合格的测试用例没法做好测试。
测试十大原则第二条：测试用例必须有明确的预置条件、操作步骤以及与之对应的预期结果。
IT业界的人员流动，那是相当快的。A先生设计了测试方案，到写TC的时候可能A先生已经另谋高就，
换成B先生在做了，再等到测试执行的时候可能B先生也远走高飞，必须让没有任何测试经验的C同学来做
了。
这时候如果TC写的不是妇孺皆能看懂，C同学十之八九无法顺利执行。后面最有可能的结果是什么？
不言而喻。
不良的TC导致糟糕的测试执行（C同学职业道德如果不是很好，甚至可能故意漏测一些TC，反正这些
TC具体的执行没有人懂，C同学不必承担责任），糟糕的测试执行导致三个结果：其一，不能按计划的方
案验证重要功能导致bug没有在用户面前“躲”起来，进一步企业不论经济还是声誉都受到损害；其二，C
同学为了保证发现足够的bug，于是乎一定会专心致志于寻找一些诸如单词拼写错误，界面错误之类的细
枝末节问题，给coding的工程师们带来一种印象：他们做测试的什么也不会……；其三，在版本不断更新
的过程中，TC肯定需要不断维护，不断进行相应更新，不良的TC导致C同学没有真正去运行这些TC，也就
无从发现这些TC的问题了，从而不良的TC一直被保留到产品发布，然后这些不良的TC又被下一个产品所继
承……继续这些恶性的循环。
TC如剑。十年磨一剑。花时间细致地写好TC并不是浪费时间和精力。

千问 · 2014-2-19 11:55:14

《测试之道》第四篇——胡马大宛名
4、胡马大宛名
上回书说到TE如侠。侠客离不开剑，也离不开马。就好比郭靖有了汗血宝马，想去哪就去哪，从来不
必担心路程问题；而胡斐追捕南霸天雷老虎，没有宝马良驹，从广东一直追到北京才算完。侠客离不开马
，尤其需要骐骥骅骝，千里良驹。
杜甫《房兵曹胡马》：胡马大宛名，锋棱瘦骨成。竹批双耳峻，风入四蹄轻。所向无空阔，真堪托死
生。骁腾有如此，万里可横行。
然则对于TE而言，能够“风入四蹄轻”的千里马何在呢？
人的精力总是有限的，即便再伟大的TE，对于无穷无尽的测试任务，也总会有感到疲惫不堪，难以为
继的时候。这不是因为TE本身功力不够，也不是因为TE掌中剑（TC）不好，而是缺少了一匹良骥。人力有
时而尽，只有非人力的才可持久；因此这良骥便是且只能是自动化测试（Automation testing）。
虽然《荀子·劝学》有云：骐骥一跃，不能十步；驽马十驾，功在不舍。然而完全由机器所执行的自
动化测试，不论骐骥还是驽马，全都能够做到功在不舍。因此这时候TE如果只是埋头编写自动化代码便有
失明智了。
TE可以针对每一条TC编写一段测试代码，然后通过执行这段代码完成对测试目标内容的覆盖；此为驽
马的方法，虽然劳而有功，然而工程浩大，且成本不菲，后续项目的继承性也难以保证。
TE还可以先创建框架，从测试需求分析开始，与coding的CMM的流程同步，采用迭代的方法渐增完成
测试代码；“随风潜入夜，润物细无声。”当测试执行开始的时候，测试代码的架构已经完成，只需对细
节进行后续维护即可。
然而还有更可取的方式：TE不要针对每个测试例编码，而是每个STEP编写更小的一段代码。不同的测
试例有可能使用相同的STEP。这种等价于STEP的每一段小的代码（记为cell）可以用STEP的简述进行封装
。例如BS结构的web页面，第一步通常是登录，登录之后跳转到首页。可以采用如下封装：
login {
/*input username & password*/

input_username "xxxxxx";

input_password "xxxxxx";
/*check*/

if (get_new page "//main.htm&quot

output "step xxx is pass"

else

output "step xxx is fail"
}
若干个此种简易封装的函数(例如完成了login,download_source,edit_source,upload_source等)完成之
后，TE对于某个测试例（step1：登录xx网站；step2：下载xx文件；step3：编辑刚才下载的xx文件；
step4：把编辑过的xx文件再上传回xx网站。）可以如下编写：
login;
download_source;
edit_source;
upload_source;
对于使用函数编写测试代码的TE而言，完全不是在编码，只是写一篇简单至极的短文。如果测试例的管理
工具足够强大，甚至可以自动组装函数。至于今后的类似项目，同样可以直接使用这些函数；如果测试例
的管理工具足够强大，甚至可以第一次编写函数之后，一切的测试代码都自动生成。
只不过到那时，说不好TE是完全被解放了，还是完全被淘汰了。就好似汽车的出现代替了千里马，而
火器的出现淘汰了剑，剑与马都失去了价值的那一天，侠客也就消失了。

千问 · 2014-2-19 11:55:14

把测试提升到道的高度，不容易啊……