先科普一下，标题的前两个字念taotie。^_^ 这四个字合在一起通常用来形容指有很多吃的东西的宴席或者有很多给人带来享受东西的宴席。联想起我们整个测试团队近来轰轰烈烈的测试用例PK大赛，我想用这四个字形容再合适不过。
作品PK环节中每个团队的分享都让我们每个参赛的同学醍醐灌顶，原来我们经常编写的测试用例，其中的奥妙玄机和博大精深，即使有10支队伍也PK不够。亦如每个团队都有闪光之处，我们的OH MY 囧 小队也有自己的思考和亮点。类似PK大赛上单刀直入的解说在这里我不想再多说，今天我想说的只与饕餮盛宴有关。因为仔细想想，我们的测试设计过程本身就和饕餮宴席有着异曲同工之秒，具体内容且听我细细说来。
我们的需求和UC其实分别就是一场盛宴的菜单和为这分菜单准备的材料、烧法说明。是要满汉全席还是要家常小菜取决于我们的需求，而我们的大厨们也就是我们的开发为这道宴席准备的材料、烧法说明的是否齐全和好坏就决定了我们所看到的UC的质量。只有当这些UC充分满足需求，品鉴师（当然这里的品鉴师是广义的品鉴师包括对材料的鉴定等）也就是我们的测试人员们才能充分验证这场盛宴是否如满足这份菜单的原始需求。
所以说我们的测试首先要有全局、需求背景的概念，到底是一场什么主题的、面向哪类人群的宴席决定了我们大的的评估标准。即便是一个情侣约会之餐，我们也需要根据情侣选择的氛围来配菜，比如追求浪漫的，我们需要做的更为温馨，比如追求简单的，我们要做的更为精致，这些是潜在的需求，菜单里也许不会写，但是做厨师的开发和做品鉴师的测试如果没有这份意识，那么菜做得再香也未免讨真实客户的欢喜。
其次我们要逐一支解每一道菜，每一个环节我们都不能放过，因为任何一道菜的不满足都能导致整个盛宴的失败，一个不新鲜的番茄就无法做出美味的番茄牛肉羹，这个道理我相信大家都明白，所以测试需要在把握大局之后深入细节，检查每一个可能影响结果的元素。
做好了前面的这两步，就是做好了我们的测试分析、UC评审。剩下的就是指导我们进行品鉴的测试设计，而用例就是告诉我们品鉴具体该怎么做。既然我们一开始将需求从整体把握，到细节摸索进行了分析，那么剩下的就需要我们还原需求，把分解后的进行合并，这才是我们完整的设计，即我们的测试设计必须最终回归到整体，否则即便每道菜都非常的OK，但如果不是我们需要的宴席种类，那一切都无意义，就好比把粤菜做成了川菜，那注定了客户无法消受，自然也不会有人为此买单。
在还原需求之后，那么就是我们实实在在的用品鉴师的标准递交了一份可以让需求的提出人信服的品鉴说明，以及告诉我们的大厨们，我们将以这样的方式和方法来考核你们的产出。所以这份说明也就是我们的测试用例一定要简单易懂、清晰明了、覆盖全面、不会产生二义性，且要保证现实可行。否则一份“天书”，相信也只能让需求提出人和大厨们无法信服。当然，一道盛宴不可能仅靠一位品鉴师来品鉴，所以品鉴师也需要互相的约定和沟通，否则一道被A认为不合格被B又认为合格的菜肴，那么到底我们该相信谁？那么这必然要有相应的规范说明，当然这规范说明必须也只会在我们的品鉴说明产出之前就已存在。
做完了上面的这些，剩下的就是执行、和作为一个与时俱进的品鉴师应该具有的不断补充完善品鉴技巧以及内容的过程了。当然，对于经过自己品鉴的东西我们肯定需要听听客户的说法，因为三人行，必有我师。
除了上述内容，像就餐环境的验证等等，我想这就类似于我们像性能测试等等内容的验证一样。所以，每一次测试，其实都像是一场饕餮盛宴，汝之见呢？
本文出自seven的测试人生公众号最新内容请见作者的GitHub页：http://qaseven.github.io/
