“这些用例是为了保证上次发现的bug不要再出现，所以务必要重复一致的步骤，因为那些bug就是在固定的步骤下才能重现的。万一步骤不一致，而bug又没有出现，那就无法判断到底上次发现的bug有没有出现了。”
“这些用例是要让开发人员在提交代码之前保证没有大问题的，如果每个开发人员都依赖测试人员来执行的话，累都累死测试团队了，而且又不可能让每个开发人员都熟悉每个测试用例，只有让机器执行，这样就两边的人都不会麻烦了。”
“这些测试用例要么是极快地，要么是长时间地与产品交互操作，人类没有那样的速度和耐心，所以只能让机器执行。”
“哦，我有点概念了。那我不太明白一件事，看起来所有测试用例都可以是为了达到第一个目的嘛（作者注2）。”
“没错，但那并不一定是主要目的啊。”
“还主要目的次要目的咧。老大，为什么我们要想那么多呢？下次我都能很熟练的分类啦，开工写代码就好啦。”
“就是因为你这样的家伙太多了，一摸到键盘就脑袋发热，想到哪就写到哪，原先想要达到的目标被抛到爪哇国去了。”
“呃……”
“行啊，你先写代码，我给你找反面教材，找不到的话，我请大家吃饭。”
作者注：你想一件事是什么结果，它就是什么结果。为什么很多时候不是那个结果，那是因为，要么是压根没想过结果应该是什么样，要么是想得不够使劲或者不对——当然啦，有时候是因为比你更牛的人在想，我才不要那个结果。跟一些同行交流自动化测试，发现大家都很少在想，结果应该是什么样；已经吃了亏的则在想，结果为什么会是这样。
作者注1：有个陷阱是领导没有提到的：执行了大量的测试用例之后，能不能迅速分析结果并且/或者找到bug，有没有大量与产品本身质量无关的执行失败。不少自动化测试的实践者兴冲冲的造了大量自动化测试用例，然后掉到后面的这个陷阱里面。
作者注2：即，短时间内执行大量的测试用例。
相关链接：
