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

　　当然我们也不要将“宙”视若等闲，有这样几个问题需要问自己：

　　1.起点中的对象的属性都受哪些环境因素的影响？

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

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

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

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

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

　　思想之剑

　　我强烈建议软件测试公司在招聘新员工的时候要查看一下员工的语文成绩。为什么？请往下看。

　　当有了“静测动试”和测试的“宇宙观”后，我们应该如何下手写TestPlan和TestCase呢？答案是：从分析用例的句子成分开始。

　　大多数测试员接触到的都是TestCase，也是“测试用例”。实际上，在软件工程的一开始，“用例”已经出现了——它是UseCases。市面上关于如何写用例的书也有不少，其中《编写有效用例》堪称经典，建议大家都去读一读。理想状态下，软件都是有用例的——它是需求分析的产物。如果你发现一个软件没有用例支持，那么说明它根本没有良好的需求分析，几乎可以肯定它存在很多缺陷。相信我，一个没有良好设计的软件，再怎么测试也不会成为一个的软件。

　　偏偏我们的测试员都很走运——几乎都没有用例在手。原因很简单，那是一个软件生产的源策动力，那才是这个软件的精华——不是代码，一般做外包测试，雇主是不会把用例给测试员看的。还有的时候，项目和开发人员由于种种原因（包括时间紧、公司风格或懒惰等），根本没有用例，测试人员也要硬着头皮上。

　　没有用例怎么办？有一种文档可以部分替代用例，那是FunctionalSpecification。不同公司及公司中不同的项目组对FS的定义不一样，有的相当于用例，有的很粗糙。如果遇到粗糙的，没办法，我们只能多花时间在软件的使用上，然后把它细化。

　　总之到后，你应该拿到一批用例——这样才能展开对软件的分析和测试。顺便说一句：有用例的一大好处是——它跟我们的基线测试基本上是一致的J

　　有了UseCase，我们可以通过分析句子写出TestCase了。

我们来分析这句话：“漫漫黑夜终于过去了。一轮火红的太阳从东方冉冉升起！”它是一个精美绝伦的3D游戏场景，需要你测试一下——这个游戏是使用完全面向对象的方法开发的，一切物体都是对现实世界的模拟。

　　句子的分析如下：

　　1.这个用例在宇向上分为两步。句子的主干为“夜过去”和“太阳升”。

　　2.对“夜”的基线测试

　　i.夜能正确结束。

　　3.对“夜”的静态属性分析（CheckList）——定语分析

　　i.夜的颜色是黑的吗？定语：黑

　　ii.夜的长度够吗？定语：漫漫

　　4.对“夜”行为的动态分析——状语、补语分析

　　i.夜能过去吗？补语：了，表示结束

　　ii.夜过去能回来吗？不允许

　　5.对“太阳”的基线测试

　　i.太阳正常升起

　　6.对“太阳”的宇分析

　　i.太阳是在黑夜正常结束后开始升起的吗？

　　7.对“太阳”的静态分析

　　i.是只有一个太阳吗？定语：一轮

　　ii.太阳的颜色正确吗？定语：火红

　　8.对“太阳”的动态分析

　　i.是从东方吗？状语：东方

　　ii.升起的速度正常吗？状语：冉冉（不是蜗速升起，呵呵）

　　iii.升的方向正确吗？补语：起

　　iv.还会降下去吗？不允许，太阳“降落”的方法只能在黄昏时调用

　　做完这些测试，程序基本上过关。但我们还有深入挖掘的余地：昼夜更迭的本质原因是什么？是地球的自转。也是说，这个TestCase的一个“宙”是没有在UseCase中出现的“地球”对象。

　　1.对“地球”的静态测试

　　i.地球的自转方向正确吗？地球自西向东转，保证了太阳从东方升起，黑夜会结束。

　　ii.地球的自转速度正确吗？只有速度正确的情况下，黑夜才会“漫漫”、太阳升起才会“冉冉”。

　　2.对“地球”的动态测试

　　i.地球会一直稳定转下去吗？（性能测试）

　　ii.会有彗星撞地球吗（环境冲击测试）？这是“宙”测试（只要你肯想，会有很多环境因素）