python自动化介绍

自动化测试===自动化测试分类（一）
分层的自动化测试
测试金字塔的概念由敏捷大师Mike Cohn 在他的《Succeeding with Agile》一书中首次提出，如图7.1所示。他的基本观点是：我们应该有更多的低级别的单元测试，而不仅仅是通过用户界面运行高层的端到端的测试。

Martin Fowler 大师在测试金字塔模型的基础上提出分层自动化测试的概念。在自动化测试之前加了一个“分层”的修饰，用来区别于“传统的”自动化测试。那么什么是传统的自动化测试？为何要提倡分层自动化测试的思想呢？

所谓传统的自动化测试我们可以理解为基于产品UI 层的自动化测试，它是将黑盒功能测试转化为由程序或工具执行的一种自动化测试。

在目前的大多数研发组织当中，都存在开发与测试团队割裂（部门墙）、质量职责错配（测试主要对质量负责）的问题，在这种状态下，测试团队的一个“正常”反应就是试图在测试团队能够掌控的黑盒测试环节进行尽可能全面的覆盖，甚至是尽可能全面的UI 自动化测试。

这可能会导致两个恶果：一是测试团队规模的急剧膨胀；二是所谓的全面UI 自动化测试运动。因为UI是非常易变的，所以UI 自动化测试维护成本相对高昂。

单元测试与模块测试
单元测试（Unit testing）
In computer programming, unit testing is a software testing method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine whether they are fit for use.
Intuitively, one can view a unit as the smallest testable part of an application. In procedural programming, a unit could be an entire module, but it is more commonly an individual function or procedure.In object-oriented programming, a unit is often an entire interface, such as a class, but could be an individual method. Unit tests are short code fragments created by programmers or occasionally by white box testers during the development process. It forms the basis for component testing。

总结一下就是：

1、单元测试是应用程序的最小可测试部分。
2、在面向过程编程中，单元也可以是整个模块，但常见的是单个函数或过程。
3、在面向对象编程中，单元通常是整个接口，例如类，但可以是单独的方法。
4、单元测试多数情况下是由程序员自己完成的。

模块测试（Module testing）
大多时候，我们认为单元测试与模块测试是一样的。我在国外某网站找到另段关于模块测试的定义。
A library may be composed of a single compiled object or several compiled objects. There is only a slightdifference between unit testing and module testing. Modules are fully formed chunks of coherent source code that can typically be tested by driving a few function signatures with various stimuli. On the other hand, unit testing (which is considered as part of the implementation phase for this software development process) may involve testing one small part of a function that will never formally implement any function interface.

我们读到了几个模块测试的解释：
1、首先，这段定义认为模块测试与单元测试有细微的区别。
2、模块测试是针对具有明显的功能特征的代码块进行的测试。
3、并且，它认为单元测试可能只涉及测试一小部分的功能。
4、模块测试多数情况下由其它程序员或测试人员进行。

接口测试
我根据自己的理解和认识大致把接口分为两类：程序接口和协议接口。

关于程序接口，也可以看作是程序模块接口，具体到程序中一般就是提供了输入输出的类、方法或函数。对于程序接口的测试，一般需要使用与开发程序接口相同的编程语言，通过不同的传入不同的参数，来验证程序接口的功能。

关于协议接口，一般指系统通过不同的协议来提供的接口，例如HTTP/SOAP 协议等。这种类型接口对底层代码做了封装，通过协议的方式对外提供调用。因为不涉及到程序层面，所以，不受编程语言的限制；我们可以通过其它编程语言或工具对其进行测试。

自动化测试的分类
SWTBOK
SWTBOK
本节以不同的视角重新审视测试象限。先来仔细看看象限图，如下图所示：

我们将支持团队的两个象限（象限一和象限二）标记为使用自动化。在象限四中，从技术视角来看，用于评价产品的工具通常也需要自动化。采用自动化业务测试工具来支持团队。只有象限三----评价产品的业务测试----没有标记为使用自动化。工具对于某些测试来说还是有用的，比如，自动化可以创建好测试数据和用户场景对日志进行分析。

请通过每个象限来识别每个项目（甚至是每个迭代）所需的各种自动化工具。仔细检查每个象限并给出所需工具的清单。假设我们准备重新设计UI，看看象限一，怎么能做测试先行呢？我们知道如何对表现层进行单元测试么?需要新的工具完成这项任务么？看看象限二，我们需要作出原型：仅仅写在纸上就行了么？还是需要创建一个Oz类型活动向导？需要使用什么工具创建可执行的业务测试来指导开发呢？需要更新或是替换掉现有的回归测试脚本么？我们知道象限三中有一个活动叫做可用性测试。这需要提前做好测试。我们希望通过工具追踪用户活动，这样就可以进一步分析这些活动了。看看象限四，我们发现负载测试脚本使用的还是旧的UI，因此不得不花些时间将其更新到新的UI上。

正如第三部分所强调的，象限的顺序与测试的顺序没有什么关系。在准备好每类测试所需的工具清单后，我们会考虑何时进行测试，这样就会提前准备好自动化工具。比如，某个团队重新设计了一个新的架构并打算尽快运行可伸缩性测试。这样，他们就需要在项目第一个迭代中花些时间来寻找或是实现性能测试工具。

象限有助于我们了解所需的工具，但各个层次上有这么多自动化工具，我们该何去何从呢？因此有必要了解不同类型的测试所适用的地方以及如何组织这些测试。为了快速、频繁的交付价值，自动化需要高度的ROI。测试金字塔可以帮助我们优化对测试的投入。