6年前,我在一家中型跨国公司
工作的时候,我建议与其浪费时间在准备充分的
测试用例，还不如编写描述测试场景的文档。所有的人都对我的建议。投以烦恼的目光。他们的脸上清晰地传递出,我这个建议犯了个大错误。虽然没人否认了这一想法,但更没有人愿意接受。每个人都认同传统做法,即编写测试用例,会更稳妥。我无力反驳。
4年之后,该公司接到一个测试项目,唯一的约束就是时间,唯一的期望是完整的测试证明材料。再次见面,我们讨论了怎么赶上最后期限的想法。应用程序主要是关于“通过搜索和生成不同菜单项的报表”。编写和记录测试用例应该要花大部分时间,我们不确定,有多少文档会用到客户交付时。所以，我建议记录测试场景,虽然有些犹豫,但最后大家都还是同意了。相对说我们可以节省宝贵的文档时间,更可以利用它进行测试。
测试用例很快就会被测试场景代替吗？
随着时间的推移,一切都在变化,软件行业和过程也发生了深刻的变化。
传统的瀑布式和v-模型已经被
敏捷和迭代模型所取代。文档是必要的,但是为了赶上最后期限,使过程简单而透明的,文档的方式也是可以改变的。
这些时候测试用例的文档是很重要的:
1.客户要求的文档（是项目的一部分）
2.没有时间的约束(我不认为这是可能的)
3.测试员是新人的或不熟悉产品
4.公司政策(我坚信它可以改变)
让我分享一下我的一个经历
我和我的团队参与测试一个项目是世界500强公司,有着灵活的时间表。我们用最好的模板来记录测试用例并且得到客户的评审通过。一旦开始组建QA团队,每天的大部分时间里,我们的责任就是,机械地遵循100个测试用例,更新文档中通过/失败结果，和在一天结束的时候把结果发给客户。很多团队的成员开始抱怨工作的单调乏味,尽管这仍然可以为公司创收。
然后就可以休息一天，没有新的测试。我们坐在一起,并讨论我们接下来要做什么。当我提议去想更多的方法来改进测试用例文档,所有的团队成员都否认我们投入的努力。按照他们的想法,他们没有更多地去思考我们已经覆盖的所有场景。说服他们跳出思维框架，产生更多的想法真的很艰难。
大多数时候,当我们测试用例(带执行结果)文档时,一旦得到客户的评审通过,就认为我们所做的工作已经完成,我们的大脑会自动停止思考任何其他方法来测试产品。
相信我,当测试用例文档准备好了,我们就只想机械地跟随它。请告诉我，在你的职业生涯中，你和团队成员在得到类似评审通过后，还提供了额外的测试用例的情况，你经历了过多少次?
另一个经历
在每周的团队挑战活动中,我们会要求团队成员完成对被测应用程序指定的“测试场景”。所有的团队成员,包括那些后期有反馈或无反馈的想法（有的没的的想法）。为什么呢?没有正式的用例文档了,他们就不得不“诸如：补填预期结果，每个步骤的每个用例的功能和前提条件等等”。我们在一天中居然收集了40个测试场景,这是一个成功的经历。
为了更好地证明我的经验,我想展示一个例子。
拿一个应用程序做示例：用一个用户名、密码,登录和取消按钮的登录页面来说。如果以同样的要求写测试用例,我们将通过结合不同的选项和细节，的排列组合最终可以写得50多个测试用例。
但如果用测试场景编写,这将是如下重要的10行:
High Level 的场景:登录功能
Low Level的场景:
1．检查应用程序的启动
2．检查登录页面上的文本内容
3．检查用户名字段
4．检查密码字段
5．检查登录按钮和取消按钮功能
参见= > 180 +示例测试场景来测试web和桌面应用程序。
由于时间关系,测试场景与其说是以前那个IODEX（一种去痛膏），还不如说是止痛药喷雾。但效果还是一样的。
最后,我总结的区别如下:
最后这篇文章应该得出的结论为:
测试用例是软件开发生命周期中最重要的一部分,没有了它,就很难跟踪、了解,遵循和推理出一些东西。但在 Agile的时代,测试用例将很快被测试场景所取代。
每个类型的测试的常见测试清单为 (数据库测试、GUI测试、功能测试等)，加上测试场景，就是软件测试人员的现代利器。讨论、培训、问题和实践绝对可以改变你的生产力（包括报bug的能力）。
关于作者:这篇优秀的文章是由 STH的作者Bhumika Mehta。她是一个有着超过7年的软件测试项目管理经验。她喜欢测试存在的一切,欣赏好的创意和创新,但讨厌单调的工作。
像往常一样,我们欢迎听到您的想法。