[Tommas] 测试场景 VS 测试用例 哪个更好?(转)

时间:2023-03-08 16:53:01
[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(一种去痛膏),还不如说是止痛药喷雾。但效果还是一样的。
  最后,我总结的区别如下:
[Tommas] 测试场景 VS 测试用例 哪个更好?(转)
  最后这篇文章应该得出的结论为:
  测试用例是软件开发生命周期中最重要的一部分,没有了它,就很难跟踪、了解,遵循和推理出一些东西。但在 Agile的时代,测试用例将很快被测试场景所取代。
  每个类型的测试的常见测试清单为 (数据库测试、GUI测试、功能测试等),加上测试场景,就是软件测试人员的现代利器。讨论、培训、问题和实践绝对可以改变你的生产力(包括报bug的能力)。
  关于作者:这篇优秀的文章是由 STH的作者Bhumika Mehta。她是一个有着超过7年的软件测试项目管理经验。她喜欢测试存在的一切,欣赏好的创意和创新,但讨厌单调的工作。
  像往常一样,我欢迎听到您的想法。