[Tommas] 测试场景 VS 测试用例 哪个更好？（转）

分享一篇网上别人的感悟：

     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年的软件测试项目管理经验。她喜欢测试存在的一切,欣赏好的创意和创新,但讨厌单调的工作。

　　像往常一样,我欢迎听到您的想法。