[技术原创] 软件测试过程中细节场景的构造与测试用例设计
（本文为技术原创，如需转载请留言注明。谢谢支持。）
2007年4月17日 “测试是一门将构造与破坏结合的艺术”——土土松
通俗的总结一些发生在过去11个月中的项目经验。
一、百变不离其中，“软件需求”——成败的决定因素。
在IT圈子内，无论你是刚毕业的理论新手，还是从事多年的元老，“软件需求”这个概念，相信你都能明白其地位有多么重要。就好比你不知如何表达你的喜好那样，错误的需求就是项目的灾难。
我们先来操作一下：
打开EXCEL，新建4个新的表单。然后执行“窗口”-“重新排列”-“平铺”。
很清楚，这里EXCEL四个表单的窗口都是平铺的。这个功能对于数据比较非常实用。然而我们可以假设这样一个场景：
在实际的软件构造过程中，第一个需求规定了单个表单最小的长度和宽度。也就是说，为了不被遮住其中的内容，表单不允许被缩放到一定的大小。比如最小为450*450。第二个需求规定，该软件的最上级父窗体的大小为固定，比如800*600。第三个需求规定，软件需要有平铺功能，为了比较显示多表单情形。这样的话，表面上，我们都能按照需求去覆盖功能。然而实际上呢？如果没有仔细的预见性，在测试的时候，你便会发现，平铺2个表单时已经出现了缺陷。450*2=900，大于了父窗体的宽度800。这时候怎么办？——返工，沟通，疲惫不堪……为什么我们不能一开始就把这些逻辑整理仔细呢？更为复杂的逻辑矛盾在实际项目中比比皆是。
二、破坏的本能——故意制造或仔细研究合理的错误逻辑，试图让程序出错。
由于实际上，普通人类的思维不可能把大量复杂的逻辑整理得美无瑕疵。这就好比侦探小说里的“密室杀人案”一样，看上去是多么的不可思议，然而却是完全符合逻辑的。因此，作为测试设计人员，我们必须有良好的预见性，去摸索，并组合一些“必然”的错误。甚至在必要时，想方设法把程序弄坏。
但是对于测试人员的问题，往往出于“如何去捣乱”上面。因为无论从业务上，还是操作流程上，要去刻意制造逻辑紊乱，或者发现一些具有重大意义的程序缺陷，战略部署的眼光和思路很难培养。这个只能自我累积经验，领悟出规律和感觉。
从一些经常接触的技术上而言，你对WINDOWS环境下的控件规则了解多少？不同平台开发出来的程序你能否一眼望穿？C++、.NET、JAVA、Delphi、VB等环境中造就出来的相同业务功能的控件，在技术上存在哪些区别和必然的缺陷？其默认属性可能带来多少设置上的简便或者漏洞？如果你能本能的反应出这些，那么要去制造一些高难度的场景就可以有思路下手了。
举一个实际的例子：
如果你项目中的软件，需要有打印预览功能，制作时采取第三方控件。而这个控件默认有两个功能，一个是“打开”本地的预览缩略图文件，一个是“导出”当前的打印状态为PDF或者其他图片格式。而实际上，项目只需要能导出PDF就足够了。很可能需求上会不明确规定要屏蔽这个第三方控件的某些默认属性。然而你在测试“打开”功能时，要么这个功能毫无作用，要么用户便能通过它，打开一些令程序不接受的格式，从而出现莫名其妙的错误。
三、数据库——要说爱你不容易。。。
这个涉及技术太广泛，只能总结一些实用的规则：
1． 设计PL/SQL的测试脚本时，尽量采用“输入”“输出”剥离的方式，比如多用一些变量常量，多用一些有意义的别名。免得在使用语句打包业务逻辑时，被迫采取多嵌套，既显得难以调试，又不好维护，性能也差，出错率极高。
2． 一定要写异常块。如果你的SELECT结果不能保证完整，怎么办？如果你的返回行为0，而这个0恰好需要在业务上作为被除数，怎么办？……等等等等。
3． 字符串转换。——黑盒测试中测试功能完整性的必测项。前后台字符串定义不一致，字符串转换时的计算误差（比如四舍五入），前台接纳字符串的限制和后台定义的约束是否一致？……要在这些地方找一些错误，是很皮毛，也是很容易的。当然，我也遇到过强悍的开发，这一块怎么做都不错。估计他是修炼成仙了……
四、多平台的兼容性错误
实际项目中，我发现过这么一个错误。在XP环境下，某个子窗体抛出的信息提示框不存在任何错误。而放到VISTA里，每次调用或者关闭这个子窗体，它都要跑出来亮亮相。后来和开发一起搞明白了，VISTA里对于某些全局变量的解释机制和XP不同。诸如此类的，从简单的前台错误无法直接辨别原因的错误，值得我们探讨研究，并且把经验总结分享。
五、今天就总结这些了？
难道还不够多么，呵呵。先暂停了。个人感觉，要搞明白这些，也需要相当的领悟力。
六、来玩玩WINDOWS的BUG
1.无论中文版本的XP还是英文版本的XP。首先去控制面板看看，时区和语言是不是都是“中国”和“中文”。如果是，打开硬盘中任意一个CHM文件试试。OK，没问题。然后把时区调整为“美国”，语言为“英语”。然后再打开刚才那个CHM文件？报错了吧？再也无法正常打开CHM了。恢复之后又好了。
2.还是“扫雷”。我们知道WIN98下面，扫雷有一个BUG，能让计时器停止，那么XP下面已经修复这个BUG的扫雷，能否让它停止计时而继续游戏呢？——当然能。先开局，随便点一个格子（当然，炸死了你好运！），应该是翻开一些空格了吧，然后立刻按组合键“WIN”（就是左CTRL和左ALT之间的那个窗口图标的键）+“D”——组合键“WIN+D”是微软操作系统中最小化所有窗口的快速切换方法。然后你再恢复扫雷的窗口看看，计时器已经宣告死亡。——这个组合测试挺奇怪的吧，居然还是有BUG啊。
……
