6年前,我在一家中型跨国公司工作的时候,我建议与其浪费时间在准备充分的测试用例，还不如编写描述测试场景的文档。所有的人都对我的建议。投以烦恼的目光。他们的脸上清晰地传递出,我这个建议犯了个大错误。虽然没人否认了这一想法,但更没有人愿意接受。每个人都认同传统做法,即编写测试用例,会更稳妥。我无力反驳。

　　4年之后,该公司接到一个测试项目,唯一的约束就是时间,唯一的期望是完整的测试证明材料。再次见面,我们讨论了怎么赶上最后期限的想法。应用程序主要是关于“通过搜索和生成不同菜单项的报表”。编写和记录测试用例应该要花大部分时间,我们不确定,有多少文档会用到客户交付时。所以，我建议记录测试场景,虽然有些犹豫,但最后大家都还是同意了。相对说我们可以节省宝贵的文档时间,更可以利用它进行测试。

　　测试用例很快就会被测试场景代替吗？

　　随着时间的推移,一切都在变化,软件行业和过程也发生了深刻的变化。

　　传统的瀑布式和v-模型已经被敏捷和迭代模型所取代。文档是必要的,但是为了赶上最后期限,使过程简单而透明的,文档的方式也是可以改变的。

　　这些时候测试用例的文档是很重要的:

　　1.客户要求的文档（是项目的一部分）

　　2.没有时间的约束(我不认为这是可能的)

　　3.测试员是新人的或不熟悉产品

　　4.公司政策(我坚信它可以改变)

　　让我分享一下我的一个经历

　　我和我的团队参与测试一个项目是世界500强公司,有着灵活的时间表。我们用最好的模板来记录测试用例并且得到客户的评审通过。一旦开始组建QA团队,每天的大部分时间里,我们的责任就是,机械地遵循100个测试用例,更新文档中通过/失败结果，和在一天结束的时候把结果发给客户。很多团队的成员开始抱怨工作的单调乏味,尽管这仍然可以为公司创收。

　　然后就可以休息一天，没有新的测试。我们坐在一起,并讨论我们接下来要做什么。当我提议去想更多的方法来改进测试用例文档,所有的团队成员都否认我们投入的努力。按照他们的想法,他们没有更多地去思考我们已经覆盖的所有场景。说服他们跳出思维框架，产生更多的想法真的很艰难。

　　大多数时候,当我们测试用例(带执行结果)文档时,一旦得到客户的评审通过,就认为我们所做的工作已经完成,我们的大脑会自动停止思考任何其他方法来测试产品。

　　相信我,当测试用例文档准备好了,我们就只想机械地跟随它。请告诉我，在你的职业生涯中，你和团队成员在得到类似评审通过后，还提供了额外的测试用例的情况，你经历了过多少次?

　　另一个经历

　　在每周的团队挑战活动中,我们会要求团队成员完成对被测应用程序指定的“测试场景”。所有的团队成员,包括那些后期有反馈或无反馈的想法（有的没的的想法）。为什么呢?没有正式的用例文档了,他们就不得不“诸如：补填预期结果，每个步骤的每个用例的功能和前提条件等等”。我们在一天中居然收集了40个测试场景,这是一个成功的经历。

　　为了更好地证明我的经验,我想展示一个例子。

　　拿一个应用程序做示例：用一个用户名、密码,登录和取消按钮的登录页面来说。如果以同样的要求写测试用例,我们将通过结合不同的选项和细节，的排列组合最终可以写得50多个测试用例。