上接 软件测试浅悟妄语
6. 返回起点后状态正确性的检查。
如果软件的每一步都能严格地通过这些“宇”测试，那么无疑会健壮很多。
当然我们也不要将“宙”视若等闲，有这样几个问题需要问自己：
1. 起点中的对象的属性都受哪些环境因素的影响？
2. 一个操作会影响到哪些环境因素？
3. 哪些环境因素会影响到当前要进行的操作？
4. 终点能不能在环境中生存？
5. 终点会对环境产生哪些影响？
如果软件能通过这些测试，那么它会更加健壮。然而，找到这些“宙”因素是要依靠你大脑里的知识、强大的分析问题的能力、冥想、灵感……忘记什么Test Plan吧！打破框框的禁锢，用思考去测试软件！这时候，你基础知识的威力就显现出来了——汇编、操作系统、编译原理、软件工程等课程知识就成了你分析问题、设计Test Case的利器！然而……我们的知识总是有限的，我们分析问题的能力也是有限的，于是，有了我开篇的妄语。
思想之剑
我强烈建议软件测试公司在招聘新员工的时候要查看一下员工的语文成绩。为什么？请往下看。
当有了“静测动试”和测试的“宇宙观”后，我们应该如何下手写Test Plan和Test Case呢？答案是：从分析用例的句子成分开始。
大多数测试员接触到的都是Test Case，也就是“测试用例”。实际上，在软件工程的最一开始，“用例”就已经出现了——它就是Use Cases。市面上关于如何写用例的书也有不少，其中《编写有效用例》堪称经典，建议大家都去读一读。理想状态下，软件都是有用例的——它是需求分析的产物。如果你发现一个软件没有用例支持，那么说明它根本没有良好的需求分析，几乎可以肯定它存在很多缺陷。相信我，一个没有良好设计的软件，再怎么测试也不会成为一个优秀的软件。
偏偏我们的测试员都很走运——几乎都没有用例在手。原因很简单，那是一个软件生产的源策动力，那才是这个软件的精华——不是代码，一般做外包测试，雇主是不会把用例给测试员看的。还有的时候，项目和开发人员由于种种原因（包括时间紧、公司风格或懒惰等），根本没有用例，测试人员也要硬着头皮上。
没有用例怎么办？有一种文档可以部分替代用例，那就是Functional Specification。不同公司及公司中不同的项目组对FS的定义不一样，有的就相当于用例，有的很粗糙。如果遇到粗糙的，没办法，我们只能多花时间在软件的使用上，然后把它细化。
总之到最后，你应该拿到一批用例——这样才能展开对软件的分析和测试。顺便说一句：有用例的一大好处是——它跟我们的基线测试基本上是一致的J
有了Use Case，我们就可以通过分析句子写出Test Case了。
我们来分析这句话：“漫漫黑夜终于过去了。一轮火红的太阳从东方冉冉升起！”它是一个精美绝伦的3D游戏场景，需要你测试一下——这个游戏是使用完全面向对象的方法开发的，一切物体都是对现实世界的模拟。
句子的分析如下：
1. 这个用例在宇向上分为两步。句子的主干为“夜过去”和“太阳升”。
2. 对“夜”的基线测试
i. 夜能正确结束。
3. 对“夜”的静态属性分析（Check List）——定语分析
i. 夜的颜色是黑的吗？ 定语：黑
ii. 夜的长度够吗？ 定语：漫漫
4. 对“夜”行为的动态分析——状语、补语分析
i. 夜能过去吗？ 补语：了，表示结束
ii. 夜过去能回来吗？ 不允许
5. 对“太阳”的基线测试
i. 太阳正常升起
6. 对“太阳”的宇分析
i. 太阳是在黑夜正常结束后开始升起的吗？
7. 对“太阳”的静态分析
i. 是只有一个太阳吗？ 定语：一轮
ii. 太阳的颜色正确吗？ 定语：火红
8. 对“太阳”的动态分析
i. 是从东方吗？ 状语：东方
ii. 升起的速度正常吗？ 状语：冉冉（不是蜗速升起，呵呵）
iii. 升的方向正确吗？ 补语：起
iv. 还会降下去吗？ 不允许，太阳“降落”的方法只能在黄昏时调用
做完这些测试，程序基本上过关。但我们还有深入挖掘的余地：昼夜更迭的本质原因是什么？是地球的自转。也就是说，这个Test Case的一个“宙”是没有在Use Case中出现的“地球”对象。
1. 对“地球”的静态测试
i. 地球的自转方向正确吗？地球自西向东转，保证了太阳从东方升起，黑夜会结束。
ii. 地球的自转速度正确吗？只有速度正确的情况下，黑夜才会“漫漫”、太阳升起才会“冉冉”。
2. 对“地球”的动态测试
i. 地球会一直稳定转下去吗？（性能测试）
ii. 会有彗星撞地球吗（环境冲击测试）？这是“宙”测试（只要你肯想，会有很多环境因素）
同一个游戏中，还有这样一个Use Case：海上生明月，天涯共此时。我们继续分析——
相信你会立刻意识到，这也与地球自转有关，而日升月沉共用一个地球，所以这个Case的地球就不用测试了。这时候，你应该意识到：地球自转是“黑夜过去”、“太阳升”、“明月生”等的源动因，所以这组隐藏Case的优先级反而高。而且，由于地球在Case中始终没有UI，所以它更有可能被归为功能测试和性能测试里去。
1. 基线测试
i. 月亮升起，测验天涯范围内的时间是否一致
2. “月”静态分析
i. 亮度够吗？ 定语：明
ii. 位置正确吗？ 定语：海上
3. “月”的动态分析
i. 升（生）的方向对吗？
ii. 升（生）的速度正确吗？（此Case可以省略，与太阳升属等价类Case）。
4. “天涯”静态分析
i. 天涯的范围是一个时区吗？
ii. 在天涯的范围内时间一致吗？（边界测试）
其实，如果你肯仔细想，还能想出很多两个Use Case的“宇”和“宙”来。只要我们的测试团队能够超出用户可探知的“宇宙范围”，那么我们就胜利了。可喜的是，在我目前的测试项目中，我正在验证这种思路，特别是在“宙”测试上——试图挖掘对象与菜单操作的（菜单操作是最全面的）所有正交反应，果然找到很多意想不到的Bug。
宇宙终归是无限的，所以，我们除了要将上面的Test Case向Test Plan中归类外，就是更深入地研究“宇”和“宙”——究竟有多少Case和Bug隐藏其中？我不知道……也许跟点点繁星一样多吧……
结语：
面对苍茫的宇宙，我敞开胸怀……
软件是不可测试的，因为我们的眼界不是无限的、手段不是无限的；
软件是可以测试的，因为软件的用户是有限的，用户的操是有限的。
祝福：
祝辛勤工作在博彦科技测试一线的兄弟姐妹们工作顺利，和我们的公司一起走向成功！
祝艰苦奋斗在测试大拿（CSDN）的兄弟姐妹们天天开心。
法律声明：本文章受到知识产权法保护，任何单位或个人若需要转载此文，必需保证文章的完整性（未经作者许可的任何删节或改动将视为侵权行为）。若您需要转载，请务必注明文章出处为CSDN以保障网站的权益；请务必注明文章作者为刘铁猛（http://blog.csdn.net/FantasiaX），并向liutm@beyondsoft.com发送邮件，标明文章位置及用途。转载时请将此法律声明一并转载，谢谢！
Trackback:http://tb.blog.csdn.net/TrackBack.aspx?PostId=1487219
