其中粉红色部分是通过等价法，确认需要删除的case；  黑色部分是输入条件非法而删除的case（黑色部分在输入允许的条件下，可以作为错误推断测试的输入条件）；  红色部分是确认需要采用的case。
　　做表需要注意2点：

　　　1）.将正交的表元素分为几类进行分别构建，比如这里我们将年/月/日划为一类，先进行建表，因为年月日含有的元素较多，重复无效的case也比较多。
　　　2）.往往正交表的由于输入元素过多，造成表过于庞大，所以边制表边删除多余的case不失为一个好的选择。
5.1.化简后：

　　终生成上表，一共有22*2*2*2=176个case，但是其中还有一些case需要删除（比如 1999是专门为“千年”设计的case，所以1999年12月31日AM 00:00这样的case没意义，需要删除，又比如12月31日这样的case也是为了设计PM 11：59而引入的，所以，2050年12月31日PM00：00也是没意义的），大约估算了一下，终应该在130个case左右。

6、生成终case
　　按照整理出的正交表（注意整理的时候查看是否涵盖了W1~W7，如果没有，可增加特殊日期case），逐条生成case。
比如：
Case1
Input：输入2050年1月1日00：00 AM ，等待1分钟
Output：界面显示2050年1月1日00：01 AM，星期六

PS:错误推断和性能case这里不说明了，错误推断case需要更细致的需求信息（比如哪些编辑框用户可以编辑等等）；性能case往往与平台挂钩，web时钟和终端时钟的性能case区别还是很大的。

 

小结：
1、拿到模块后，先划分测试单元并分类，分析过程除了正交表以外，判定表、因果法也是不错的选择。
2、无论哪种方法，都需要增删case来满足终的要求，平时业务知识的积累可以更好帮你完善你的设计。