话说公元250 年2 月30 日，孔明设计并制造出一台集各种武器于一身的超
级杀人武器霸王——“拿你命300”，它能识别出放入其内的数百种弹药并用相
应的投弹器发射出去，使用起来非常方便，非常傻瓜。比如放入石头它会用投石
机投掷，放入箭簇则以弓弩射出。现在需要测试它的功能是否达到这种要求。但
问题是：
1、测试过程耗时很长(关系到成本);
2、测试过程很单调，就是放入弹药(输入)，看它会用哪种发射器去发射
(输出)，如此重复相当多次，并且不用查看中间的工作过程，(即黑盒测试，
根据输入检查输出是否符合要求);
3、此机批量生产后每台都要做完全相同的测试。
而孔明日理万机，故无暇顾及此机，如果花点时间培训一个专人来负责，那
以后就省力又省心，一个人顶过去十个(可重复测试)……然则何人来测?发愁
之际，吏部调一人前来。此人名叫齐铁炮，英文名是QTP，他不懂汉语，只会
VBscript，最擅模仿，动作神速，能工作数月而不知疲倦。那不就是传说中的变
形金刚?不，因为他的缺点是智商为零，非常死板，不知变通。
根据这些特点，孔明这样安排他工作：
1、录脚本
孔明先以石头为例做一遍测试过程，然后QTP 把孔明的动作都逐一记在本
子上(即脚本)，再依照脚本来做就完全重现了孔明的测试过程。
2、插入检查点
然后孔明又告诉他如何将预设的期望值与测得的实际值对比来判断功能是
否正确。比如：(对于放入的石头，按发射按钮后，)如果输出端可见一投石器
升起并投掷此石，则表示该功能通过。QTP 也把它记下来并也成功照做。
3、参数化
“好，灰常好，QTP，现在你改用箭去测试。”
“可是丞相，我记下的脚本中只有‘……打开弹药舱，放入石头……’，并
没有关于如何使用‘箭’的内容，你要做一遍给我看或者明确告诉When，Where
and How 去用它，不然我无从下手。”
孔明一听吐血，这QTP 还真不愧是笨蛋，要是每种输入的弹药都要做一遍
那还不如自己测试，于是他决定在QTP 原有的脚本上修改，用参数表记下所有
需要测试的弹药，在‘放入石头’的‘石头’处改用此参数表，告诉QTP 每次
到这一步时就取表中的下一种弹药来测，在检查点中也改用对应的期望值参数表
来判断结果。这下QTP 才能按孔明的意愿顺利测试下去。
其间还涉及一些问题：
对象库
孔明发现，QTP 在记录脚本时要用掉很多本子，仔细一看，这些本子叫“对
象库”，他把有关对象的属性都记录到里面去了。比如某个按钮的属性为：
类型：按钮，
名称：发射，
颜色：红色，
密度：3000g/m3，
材料：聚乙烯，
重量：100g，
位置：左边顶部
……
为的是在测试时根据这些属性来确定对象，以便操作。可是要确定对象一般
只需特定的两三个属性就够了(像刚才那个按钮只要用“类型：按钮，名称：发
射”就足以标识它)，其它属性变得多余且占空间。
“QTP 啊，我不是给你指定了几个属性来标识对象吗?你把全部都记下来
干嘛?洛阳纸贵啊”
“丞相，我这样做是有好处的，如果根据指定的属性无法确定对象，我还有
个特技，我可以用其它属性来进行智能识别。”
“就你那智商还智能识别……”
描述性编程
为了节省资源，孔明令QTP 不要记录对象属性到对象库，改为直接在脚本
中描述对象，比如对刚才那个按钮，只需描述类型和名称就可以找到它了。
自动化测试(增强)
有一次孔明出征去了，不在测试现场，QTP 在一炷香后还确定不了要按哪
个按钮，就写了一张便条放在孔明办公桌上，其内容是：
“无法找到“锁定目标”按钮所在的控制面板，应如何处理?你有几个选择：
A、别测了，先吃饭去B、我不管，反正你不能停C、你来调戏试D、去掉两
个不推荐的选项E、向现场将士求助。”
然后暂停测试，干等孔明的指示，直到数月后孔明回来。鉴于此事，孔明令
QTP 以后一旦遇到无法解决的问题或者完成测试后立刻向他报告，方式可以是
用发短信、语音通话、发邮件、即时通讯工具、飞鸽传书等。
需求变更
后来孔明又对此机增加了一个功能：如果放入玉米、地瓜之类的食物，输出
来的就是烤熟的了，这样将士们作战时就可以打到哪吃到哪。如果一并测试这个
功能应该怎么改脚本?很容易想到：在“放入石头”的参数表中增加食物，在后
面检查点中增加相应期望结果即可。改好脚本后QTP 照做，可这一次测试结果
却是投石器把玉米抛了过去，给敌人送去了粮食，bug，终于出现了……
