给测试归类

　　“终于，在我的脑海中形成了这样的图像：

　　开发人员测试：

　　单元测试：隔离良好的、原子性质的、相互独立的：使用xUnit框架开发

　　集成测试：

　　互相隔离的可能改变系统状态的测试，比如，把数据保存到数据库，写文件……集成测试并不像听上去那样代表着功能需求。可以使用xUnit编写。

　　集成测试会检查代码与第三方工具、或者其他层次代码的集成情况，比如说，业务逻辑层依赖于数据访问层。

　　功能测试：（也被叫做系统测试）

　　把系统的某部分当成整体来检验的测试，通常代表了一些功能需求。这些测试可能会改变系统的状态。

　　产品所有者测试：

　　验收测试：也是功能测试，不过输入和输出可以被非技术人员——产品所有者验证。”

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

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

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

　　测试类型：单元测试、集成测试、功能测试、系统测试、验收测试、渗入（soak）测试、冒烟测试等等。

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

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

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

　　所以我对区分测试到底属于什么“类型”并不是十分感兴趣，我更关注特定测试在特定时刻该从何种角度来区分，而且这对我也非常重要。我经常思索如下的问题：

　　* 什么“单元”是由这个测试界定，并对之进行测试的？（什么系统、子系统、对象、协作......）——这个测试界定并测试了什么特性？

　　* 这个测试的主要关注对象是谁？谁最关心这个测试的运行结果？

　　* 基于该测试的运行结果，会做出何种决定？”

　　Charlie Poole详细分析了Calos的分类，进而建议到：

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

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