BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

给测试归类

| 作者 Amr Elssamadisy 关注 0 他的粉丝 ,译者 金明 关注 0 他的粉丝 发布于 2009年8月24日. 估计阅读时间: 3 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

Yahoo!的测试驱动开发讨论组里面,Carlos Ble与众人分享了他在经过研究之后对测试类别的理解:

终于,在我的脑海中形成了这样的图像:
开发人员测试:
单元测试:隔离良好的、原子性质的、相互独立的:使用xUnit框架开发
集成测试:
互相隔离的可能改变系统状态的测试,比如,把数据保存到数据库,写文件……集成测试并不像听上去那样代表着功能需求。可以使用xUnit编写。
集成测试会检查代码与第三方工具、或者其他层次代码的集成情况,比如说,业务逻辑层依赖于数据访问层。
功能测试:(也被叫做系统测试)
把系统的某部分当成整体来检验的测试,通常代表了一些功能需求。这些测试可能会改变系统的状态。
产品所有者测试:
验收测试:也是功能测试,不过输入和输出可以被非技术人员——产品所有者验证。

John Donaldson分享了关注于测试角色和测试类型的多维模型:

我喜欢你给出的测试视图。但是我认为这是更大模型的一个实例,在那个模型里面,你(至少)拥有执行者-角色和测试类型。

执行者-角色:开发人员、测试人员、QA、用户、出资方等等。

测试类型:单元测试、集成测试、功能测试、系统测试、验收测试、渗入(soak)测试、冒烟测试等等。

在具体的情景下,某种角色会执行某些测试。但是,换个项目这种关系就可能不一样。

Dale Emery提议:对于不清楚所写测试的类型这种情况,应该将其定义为一种代码坏味道,它说明缺乏清晰度。与此同时,一个测试可能会被归类于多种类型,重要的是你当前视角的重点:

我所认为的挑战在于:根据关注角度的不同,任何测试都有很多种理由充分的分类方法。人们可以从很多角度出发来给测试归类。我在这篇文章中指出了一些:

所以我对区分测试到底属于什么“类型”并不是十分感兴趣,我更关注特定测试在特定时刻该从何种角度来区分,而且这对我也非常重要。我经常思索如下的问题:
  • 什么“单元”是由这个测试界定,并对之进行测试的?(什么系统、子系统、对象、协作......)——这个测试界定并测试了什么特性?
  • 这个测试的主要关注对象是谁?谁最关心这个测试的运行结果?
  • 基于该测试的运行结果,会做出何种决定?

Charlie Poole详细分析了Calos的分类,进而建议到:

在我看来,最重要的区别在于开发人员关注的测试和客户关注的测试。

讨论凸现了这样一个事实:测试的分类可能令人非常迷惑,特别是对初学者而言。大多数观点认为需要从特定角度出发来给测试归类,分类类型是否恰当则依赖于当时的关注点和场景。

查看英文原文:Categorizing Tests

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT