Selenium自动化测试完全指南:基于Python
上QQ阅读APP看书,第一时间看更新

第1章 Selenium自动化测试概览

1.1 自动化测试简介

即使是经验非常丰富的程序员,在开发编码时也很容易犯错,这些错误也许是由于需求不明确,也许是由于设计问题,也许是编码中出现了失误等。但无论是怎样的错误,若不及时处理,都会降低软件的可靠性,严重时甚至会导致整个软件的失败。

为了排除这些错误,人们引入了软件测试的概念。通俗地说,软件测试就是为了发现程序中的错误而分析或执行程序的过程。

测试和修正的活动可以在软件生命周期的任何阶段进行。然而,随着开发的不断进行,找出并修正错误的成本也会急剧增加。在需求阶段就能发现问题并进行修改,成本就会很低。如果代码已经编写完毕,再进行更改,则成本将会高许多。

随着行业的蓬勃发展,开发周期不断缩短,人们对软件研发效率和质量的要求越来越高,于是自动化测试开始登上历史舞台,代替人来高效地执行大量重复的手工劳动。自动化测试的定义很简单:软件测试一般是由测试人员执行的,如果由机器来代替人执行软件测试,那么这种测试就叫自动化测试。例如,由计算机代替人来单击被测试软件的界面,执行一系列操作并进行验证。

然而,并不是所有测试类型都适合自动化。哪些测试更适合自动化?哪些更适合手工测试?根据Brain Marick提出的测试四象限,我们可以对测试进行归类,将其划分到4个象限中,以解答这些问题,如图1-1所示。

接下来对各个象限进行简单的介绍。

图片 1

图1-1 自动化测试四象限

  • 第一象限:面向技术和指导开发,该象限中的测试主要为集成测试、组件测试、单元测试等,让开发团队能够获得代码级别的高效反馈,从技术上而言可以实现完全自动化。
  • 第二象限:面向业务和指导开发,该象限中的测试主要为功能性的验证测试,判断开发团队的产出是否符合需求,从技术上而言大部分可以实现自动化。但越面向业务,实现成本越高,是否自动化一般取决于成本因素。
  • 第三象限:面向业务和评估产品,该象限中的测试(例如探索式测试、可用性测试,等等)需要靠测试人员主动探索系统潜在的故障,而其他类型的测试偏重客户(而非测试人员)在使用过程中的使用体验,所以以手工测试为主。
  • 第四象限:面向技术和评估产品,该象限中的测试主要为非功能性测试,例如性能测试、安全性测试、可靠性测试等。这些测试的场景复用度不高,而且一般依赖于特定的测试工具,能否自动化取决于场景是否有复用价值及工具本身是否能有效支持自动化。

第一象限中的测试类型全都可以自动化,包括单元测试、组件测试等。第二象限中的测试类型大部分可以自动化,例如功能验收测试。第四象限中的测试类型受工具的限制,且测试场景具有一定局限性,所以只有小部分可以做成可复用的自动化测试,而第三象限的测试通常只能以手工方式进行。

显然,自动化测试不可能完全取代手工测试。事实上,两者的定位并不相同,分别从不同的层面去保证软件的质量。第一象限、第二象限中的测试是自动化测试的重点,通常我们所说的自动化测试都是在第一象限、第二象限中的自动化测试。

然而,第一象限、第二象限中的测试也并不是全部需要实现自动化的。关于自动化测试的比例,需要有一个健康的模式,才能得到最佳成本收益比。这里引入Mike Cohn提出的自动化测试金字塔的概念,合理的自动化测试用例的分布应如图1-2所示。

图片 2

图1-2 合理的自动化测试用例的分布

合理的自动化测试的分布中,顶部以少而精的用户界面(UI)测试为主,中间由适量的API测试组成,而底部由大量的单元测试组成。在测试金字塔中,越往上就越接近真实的业务,其自动化成本越大,运行速度比较缓慢,反馈周期变长,而越往下则越偏向技术层面,虽然离具体业务较远,但运行速度快,实施成本低,反馈周期短。自动化测试的整体搭配越接近 图1-2所示的金字塔形,自动化程度越高,收益越高。

在测试金字塔的顶端,强调少而精的测试,作为整个测试体系的点睛之笔,它们必须拥有强力的策略及工具才能支撑。本书将着重介绍策略部分。对于工具,到底要用什么样的工具才能完成这项艰巨的任务呢?

接下来,本书的主角Selenium闪亮登场。唯有它能真正胜任这项艰巨的任务。