同一个游戏中，还有这样一个UseCase：海上生明月，天涯共此时。我们继续分析——

　　相信你会立刻意识到，这也与地球自转有关，而日升月沉共用一个地球，所以这个Case的地球不用测试了。这时候，你应该意识到：地球自转是“黑夜过去”、“太阳升”、“明月生”等的源动因，所以这组隐藏Case的优先级反而高。而且，由于地球在Case中始终没有UI，所以它更有可能被归为功能测试和性能测试里去。

　　1.基线测试

　　i.月亮升起，测验天涯范围内的时间是否一致

　　2.“月”静态分析

　　i.亮度够吗？定语：明

　　ii.位置正确吗？定语：海上

　　3.“月”的动态分析

　　i.升（生）的方向对吗？

　　ii.升（生）的速度正确吗？（此Case可以省略，与太阳升属等价类Case）。

　　4.“天涯”静态分析

　　i.天涯的范围是一个时区吗？

　　ii.在天涯的范围内时间一致吗？（边界测试）

　　其实，如果你肯仔细想，还能想出很多两个UseCase的“宇”和“宙”来。只要我们的测试团队能够超出用户可探知的“宇宙范围”，那么我们胜利了。可喜的是，在我目前的测试项目中，我正在验证这种思路，特别是在“宙”测试上——试图挖掘对象与菜单操作的（菜单操作是全面的）所有正交反应，果然找到很多意想不到的Bug。

宇宙终归是无限的，所以，我们除了要将上面的TestCase向TestPlan中归类外，是更深入地研究“宇”和“宙”——究竟有多少Case和Bug隐藏其中？我不知道……也许跟点点繁星一样多吧……

　　结语：

　　面对苍茫的宇宙，我敞开胸怀……

　　软件是不可测试的，因为我们的眼界不是无限的、手段不是无限的；

　　软件是可以测试的，因为软件的用户是有限的，用户的操是有限的。