软件测试浅悟妄语3

 　软件测试的生命之图

　　如果把软件从启动到关闭看作是一次生命的话，那么软件的生命会是一张非常美丽的生命之图--这张图的起点是软件的Start，然后每一步你都有一个或者若干选择，从而让用户可以有多个达到下一步的通路，这些通路有的是可逆的，有的是单行的，有些是可跳过的……总之，我们最后会达到软件生命的另一端--关闭。

　　虽然这是一个"图"数据结构，但是对每个通路的遍历却是一条线（我是说线性的步骤），其中包含一些可以回溯的步骤。而每条线又是由有限个线段构成的。

　　每条线段由两个端点和一条连线构成。两个端点，一个是起点（我称它为"起点场景"），一个是终点（我称它为"终点场景"），中间的连线是从起点到终点的"动作"。（目前CSDN没法上传图片，过几天我补上图）

　　那么有个问题：这条小线段有几种走法？OK，让我们来分析一下--

起点à正确操作à终点。（基线测试）

　　2.起点à错误操作à终点。

　　3.起点à正确操作à终点à正确操作à起点。

　　4.起点à错误操作à终点à正确操作à起点。

　　5.起点à正确操作à终点à错误操作à起点。

　　6.起点à错误操作à终点à错误操作à起点。

　　7.起点à部分正确操作à放弃à起点。

　　8.起点à部分错误操作à放弃à起点。

　　别忘记还有"宇"的问题，操作的上一步、下一步组合起来会如何？如果这一线段之前的"宇"都是正确的，那么这样的测试是常规的。如果此前的"宇"已经在某步出了问题（我称之为"错误传递"）那这对软件的质量就是考验了：我认为，凡是能在"宇"中传递下来的数据，都是正确的；如果有错误被在"宇"中传递，那么这就是软件的缺陷。有了这一点，情况似乎简单多了--我们只需要检查这几项就足够了起点状态的正确性。

　　2.操作输入的正确性（小到简单的鼠标点击，大到多项数据的组合输入，边界检验，默认值等）。

　　3.终点的正确性（如果有错误，软件是否通过报错而阻止错误在"宇"向下中传递）。

　　4.可返回性。

　　5.返回操作的输入。

　　6.返回起点后状态正确性的检查。

　　如果软件的每一步都能严格地通过这些"宇"测试，那么无疑会健壮很多。

　　当然我们也不要将"宙"视若等闲，有这样几个问题需要问自己起点中的对象的属性都受哪些环境因素的影响？

　　2.一个操作会影响到哪些环境因素？

　　3.哪些环境因素会影响到当前要进行的操作？

　　4.终点能不能在环境中生存？

　　5.终点会对环境产生哪些影响？

　　如果软件能通过这些测试，那么它会更加健壮。然而，找到这些"宙"因素是要依靠你大脑里的知识、强大的分析问题的能力、冥想、灵感……忘记什么Test Plan吧！打破框框的禁锢，用思考去测试软件！这时候，你基础知识的威力就显现出来了--汇编、操作系统、编译原理、软件工程等课程知识就成了你分析问题、设计Test Case的利器！然而……我们的知识总是有限的，我们分析问题的能力也是有限的，于是，有了我开篇的妄语。