我强烈建议软件测试公司在招聘新员工的时候要查看一下员工的语文成绩。为什么?请往下看。
当有了“静测动试”和测试的“宇宙观”后,我们应该如何下手写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. 还会降下去吗? 不允许,太阳“降落”的方法只能在黄昏时调用作者: yay 时间: 2007-1-26 14:27
做完这些测试,程序基本上过关。但我们还有深入挖掘的余地:昼夜更迭的本质原因是什么?是地球的自转。也就是说,这个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. 在天涯的范围内