1.6 补充知识点

1.6.1 什么是面向对象编程中的对象

动物园里有各种各样的动物，每一个动物都可以被称为一个“对象”。动物园在管理动物时，会按照大类将动物分别圈养，而这个“大类”就是在每个对象身上寻找共同点，有共同点的放在一起。

同理，在面向对象编程中，所有的数据类型都被称作“对象”，将有共同点的对象抽象出来就变成了“类”。

综上所述，对象是Python中最基本的单位，所有的事物都可被称为“对象”。

1.6.2 什么是面向对象编程中的类

“物以类聚，人以群分”是指，同类的东西常聚在一起，志同道合的人相聚成群。我们经常说这类人（比如精明的人）如何如何，“这类人”应该是有共同点的。如果将这个概念延伸到编程语言的类中，那“类”应该是具有共同点的一群事物，比如人类、鱼类、鸟类等。

这些共同点是什么呢？现实中说“这类人”（精明的人），一般是指这类人聪明、会算计等，这些就是这类人的共用特性。同样，将这个概念延伸到编程语言的类中，那么“类”应该有一些静态的和动态的属性。比如人类，静态的属性有一个脑袋、有手、有脚、会呼吸等；动态的属性有直立行走、会制造工具等。

综上所述，编程语言中的“类”就是有特定属性（静态、动态）的一个基本组合。

1.6.3 什么是编程语言中的实例

“实例”总是和“类”绑定在一起使用的。即实例是依附于类存在的，实例是类的代言人。可以这么举例，“类”相当于古时候的皇帝，皇帝想知道下面的官员是否按照自己的旨意去办事，但皇帝（类）又不能亲自出马，所以委派了钦差大臣（实例），让他行使皇帝赋予的权利，这时钦差大臣就代表皇帝，拥有皇帝才有的权利。

“实例”代表了“类”，但实例能被使用，正是使用了实例的方法。所以，使用实例达到了使用类的效果。

1.6.4 自动化测试是不是比手工测试覆盖率高

1．分析

有的读者可能觉得自动化很神奇，认为自动化测试能替代手工测试。然而，“理想很丰满，现实很骨感”。

许多自动化测试最终以失败告终，究其原因，不是技术不够成熟，也不是测试人员不用心，而是因为其太想自动化了，太想把所有事都用机器去实现，到最后为了自动化而自动化，疲于应对纷繁变化的业务，疲于维护代码，最终发现实际的工作量比手工测试还要多，这样自动化项目自然就无法被推进下去了。

2．看点

自动化测试是让机器去执行代码，自动化代码是编程语言的集合，编程语言是开发者思想的体现，开发者思想是业务逻辑抽象的结果，所以“自动化=业务逻辑的抽象”。这么说读者应该能理解“指望自动化测试提高测试覆盖率是不现实的”。因为它只是业务逻辑的一种体现方式，最多只是效率要高一些而已。

3．反问

既然自动化测试不能提高测试覆盖率，为什么还要用自动化测试代替手工测试呢？虽说自动化测试没有提高覆盖率的优势，但其他方面的优势它还是有的，比如无差异地执行（手工测试不能保证每轮执行都一样）。

自动化测试的执行效率比手工高。但这个优势需要有一个基础——项目比较稳定。只有稳定的项目才有自动化的价值，所以，现在很多人摒弃了UI自动化测试（或者说，复杂的UI自动化测试）的原因是：UI变化快，维护代码的成本太高，继而开始追捧接口自动化测试。因为接口是连接业务和数据的纽带，是业务逻辑的集中体现，同时接口又比较单一，其核心部件就三个——地址、入参、返回包。最重要的一点是，接口的修改基本以增量模式为主（即保持原有的逻辑不变，依据业务需要新增接口或摒弃原接口），所以其稳定性很高。所以，接口自动化测试的性价比高。

4．追加

既然自动化测试性价比如此高，那么该做到什么层次呢？可以参照表1-6-1来定义自动化的检查等级。

1.6.5 什么是自动化测试

广义上来讲，一切通过工具（程序）的方式来代替或辅助手工测试的行为，都可以被看作是自动化，甚至包括：①性能测试工具（Loadrunner、Jmeter），其本质也是自动地发送请求，只是监控的指标不同而已；②自己所写的一段代码，用于生成区间内的随机数字。

狭义上来讲，自动化测试是指：使用工具记录或编写代码的方式模拟手工测试的过程，通过回放或运行代码来执行测试用例，让机器重复处理从而代替人工对系统进行验证。

从上面两个层面不难理解，在做自动化测试时，不一定动辄就是搭建框架或平台，而要立足于实际的项目需要，从最重复的点着手，哪怕只是自动生成测试数据，也能提高测试效率。“以提高效率来驱动自动化的项目的开展和落地”比“追求华而不实、大而全的框架性东西”更接地气。

1.6.6 什么是分层自动化测试

金字塔结构最初在Mike Cohn于2009年著作Succeeding with Agile: So ftware Development using Scrum （《Scrum敏捷软件开发》）的一书中被提到。在这本书中，自动化测试被定义为一种三层的金字塔形结构（如图1-6-1所示）。他的基本观点是：应该有更多低级别的单元测试，而不仅仅是通过用户界面运行高层“端到端”的测试。

传统的自动化测试，大多关注的是产品UI（用户界面）层的自动化测试；而分层的自动化测试，倡导在产品的不同阶段都要实施自动化测试。根据测试金字塔，可设计分层自动化测试（如图1-6-2所示），其强调从UI层到最小的逻辑单元层都需要实施自动化测试，从全面自动化测试到对系统的不同层次进行不同程度的自动化测试。

相信从事测试工作的人对图1-6-2的金字塔图形并不陌生，这不就是在产品开发不同阶段所对应的测试吗！规范的单元测试需要相应的单元测试框架，单元测试框架有基于Java的Junit、testNG，基于C#的NUnit，以及基于Python的unittest、pytest等。几乎所有的主流语言，都会有其对应的单元测试框架。

1．手工测试

对于手工测试，读者应该不陌生，它是测试入门必须经历的测试。手工测试是由人一个个地输入用例，然后观察结果，属于比较原始但是必需的一个步骤。这种测试主要应用在程序集成阶段，即在产品已具有较完善的功能时再测试。

2．用户界面自动化测试

大部分测试人员的大部分工作都是对用户界面的功能进行测试。例如，不断重复地对一个表单进行提交操作，以测试其功能。这时可以通过相应的自动化测试工具来模拟这些操作，从而避免重复劳动。

UI（用户界面）层的自动化测试工具非常多，比较主流的是QTP、Robot Framework、Watir和Selenium。

为什么要画成一个金字塔形，则不是长方形或倒三角形呢？这是为了表示不同阶段所投入自动化测试的比例。

如果一个产品从没有做过单元测试与接口测试，只做UI层的自动化测试，是不科学的，这很难从根本上保证产品的质量。

不要妄图实现全面的UI层自动化测试，那是一个劳民伤财的举动：投入了大量的人力和时间，最终获得的收益可能远远低于所支付的成本。因为UI层的元素会时常发生改变，所以越往上层，其维护成本越高。

所以，应该把自动化测试更多地放在单元测试与接口测试阶段。

既然UI层的自动化测试这么劳民伤财，那只做单元测试与接口测试好了？不可以!因为不管什么样的产品，最终呈现给用户的是UI层。所以，测试人员应将更多的精力放在UI层。也正是因为测试人员在UI层需要投入大量的精力，所以，有必要通过自动化的方式解放部分重复的劳动。

在自动化测试中，最怕的是变化。因为变化会直接导致测试用例运行失败，从而需要对自动化代码进行维护。如何控制失败、降低维护成本，对自动化测试的成败至关重要。反过来讲，一份永远都运行成功的自动化测试用例是没有价值的。

测试金字塔中的3种测试的比例，应根据实际的项目需求来划分。在《Google测试之道》一书中说道：“对于Google产品，70%的投入为单元测试，20%的投入为集成和接口测试，10%的投入为UI层的自动化测试。”

3．接口自动化测试

不少测试新手都不太容易理解接口测试。接口测试关注的是函数和类（方法）所提供的接口是否可靠。例如，要定义一个add()函数用于计算两个参数的结果并返回，则需要调用add()及传参，并比较返回值是否为两个参数之和。当然，接口测试也可以URL形式进行传递。例如，通过GET方式向服务器端发送请求，则发送的内容作为URL的一部分传递到服务器端；Web Service技术对外提供公共接口，需要通过SoapUI等工具对其进行测试。

接口自动化测试是用工具和代码来模拟请求和结果校验，以解放人力和保证持续、稳定地测试。

4．模块/单元测试

在程序中最小的组合是一个个的函数或者方法，而对函数和方法的测试可归为单元测试。单元测试关注代码的实现逻辑，例如，一个if语句分支或一个for循环的实现。所以，单元测试应尽可能覆盖代码逻辑的每条路径。