Selenium自行整理【五十】_selenium 标识-优快云博客

本文链接：https://blog.youkuaiyun.com/qq_31942921/article/details/98875867

第 10 章自动化测试项目实战

如果是根据本文的章节安排，学完前面九个章节的内容，相信此时已经具备了开发自动化测试项目的能力。如果到此为止你依然对如何开展自动化测试无从下手，那么可能会有两个原因：一方面原因可能是前面的内容学习的不够扎实，没有达到理解运行程度。另一方面可能是对被测项目的理解不够，不能挖掘出相关的自动化需求。不管出于哪一方面原因，本书都有责任帮助你强化前面所学的内容。

尽量通过一个具体的项目来告诉你如何进行自动化测试的开发，当然，作者经验有限，这个项目的设计并非完美，更多的是希望向读者传达一些项目中的开发技巧和设计思想。

10.1、自动化测试用例设计

对于测试人员来说，不管是进行功能测试、自动化测试还是性能测试都需要编写测试用例，测试用例的好坏往往能准确的体现了测试人员的经验、能力以及对项目需求的理解深度。所以，在正式开展自动化测试工作之前，我们很有必要聊聊自动化测试用例的一些特点，以及如何有编写自动化测试用例。

10.1.1、手工测试用例与自动化测试用例

手工测试用例是针对功能测试人员的，而自动化测试用例则是针对自动化测试框架或工具的；前者是功能测试用例人员通过手工方式进行用例解析，后者是应用脚本技术进行用例解析。两者各自最大的特点在于，前者具有较好的异常处理能力，能够基于测试用例，制造各种不同的逻辑判断，而且人工测试步步跟踪，能够细致地定位问题；而后者是完全按照测试用例的步骤进行测试，只能在已知的步骤与场景中发现问题，而且往往因为网络问题或功能的微小变化导致用例执行异常，自动化的执行也很难发现新的 bug。

手工测试用例

● 较好的异常处理能力，能通过人为的逻辑判断校验当前步骤的功能是否正确实现

● 人工执行用例具有一定的步骤跳跃性

● 人工测试步步跟踪，能够细致地定位问题

● 主要用来发现功能缺陷

自动化测试用例

● 执行对象是脚本，任何一个判断都需要编码定义

● 用例步骤之间关联性强

● 主要用来保证产品主体功能正确和完整，让测试人员从烦琐重复的工作中解脱出来

● 目前自动化测试阶段定位在冒烟测试和回归测试

通过对比我们可以看到，手工测试用例与自动化测试用例之间存在较大的差异，所以，不能直接把手工测试用例 “翻译”成自动化测试脚本。

通过它们之间的特点对比也可清晰地认识到，自动化测试不能完全的替代手工测试，自动化测试的目的仅仅在于让测试人员从烦琐重复的测试过程中解脱出来，把更多的时间和精力放到更有价值的测试中，例如探性测试。而自动化测试更多的是用来进行冒烟测试和回归测试。

自动化测试用例选型注意事项：

● 不是所有的手工用例都要转为自动化测试用例。

● 考虑到脚本开发的成本，不要选择流程太复杂的用例。如果有必要，可以考虑把流程拆分成多个用例来实现脚本。

● 选择的用例最好可以构建成场景。例如，一个功能模块，分多个用例，多个用例使用同一个场景。这样的好处在于方便构建关键字测试模型。

● 选择的用例可以带有目的性。例如，这部分是用例做冒烟测试，那部分用例是做回归测试等，当然，会存在重叠的关系。如果当前用例不能满足需求，那么唯有修改用例来适应脚本和需求。

● 选取的用例可以是你认为是重复执行，很烦琐的部分。例如，字段验证、提示信息验证这类，这部分适用于回归测试。

● 选取的用例可以是主体流程，这部分适用于冒烟测试。

● 自动化测试也可以用来做配置检查、数据库检查。这些可能超越了手工用例，但也算用例拓展的一部分，项目负责人可以有选择地增加。

● 平时在手工测试时，如果需要构造一些复杂的数据或重复一些简单的机械式动作，则告诉自动化脚本，让它来帮你，或许你的效率会因此而得到提高。

10.1.2、测试类型

1、测试静态内容

静态内容测试是最简单的测试，用于验证静态的、不变化的 UI 元素的存在性。例如：

● 每个页面都有其预期的页面标题码？这可以用来验证链接指向一个预期的页面。

● 应用程序的主页包含一个应该在页面顶部的图片吗？

● 网站的每一个页面是否都包含一个页脚区域来显示公司的联系方式、隐私政策以及商标信息?

● 每一页的标题文本都使用的<h1>标签吗？每个页面都有正确的头部文本吗？

你可能需要也可能不需要对页面内容进行自动化测试。如果你的网页内容是不易受到影响，则手工对内容进行测试就足够了。假设您的应用文件的位置被移动了，则内容测试就非常有价值。

2、测试链接

Web 站点的一个常见错误为失效的链接或链接指向无效页。链接测试涉及各个链接和验证预期的页面是否存在。如果静态链接不经常更改，则手动测试就足够了。但是，如果你的网页设计师经常改变链接，或者文件不时被重定向，则链接测试应该实现自动化。

3、功能测试

在你的应用程序中，需要测试应用的特定功能，需要一些类型的用户输入，并返回某种类型的结果。通常一个功能测试将涉及多个页面，一个基于表单的输入页面，其中包含若干输入字段、提交和取消操作，以及一个或多个响应页面。用户输入可以通过文本输入域、复选框、下拉列表，或任何其他浏览器所支持的输入。

功能测试通常是需要自动化测试的最复杂的测试类型，但通常也是最重要的。典型的测试是登录、注册网站账户、用户账户操作、账户设置变化、复杂的数据检索操作，等等。功能测试通常对应着你的应用程序的描述应用特性或设计的使用场景。

4、测试动态元素

通常一个网页元素都有一个唯一的标识符，用于唯一地定位该网页中的元素。通常情况下，唯一标识符用HTML 标记的“id”属性或“name”属性来实现。

这些标识符可以是一个静态的（即不变的）字符串常量。也可以是动态生成值，在每个页面实例上都是变化的。

例如，有些 Web 服务器可能在一个页面实例上命名所显示的文件为 doc3861，而在其他页面实例上显示为 doc6148，这取决于用户在检索的“文档”。验证文件是否存在的测试脚本可能无法找到不变的识别码来定位该文件。通常情况下，具有变化的标识符的动态元素存在于基于用户操作的结果页面上，然而，显然这取决于 Web 应用程序。

5、Ajax 的测试

Ajax 是一种支持以及动态改变用户界面元素的技术。页面元素可以动态更改，但不需要浏览器重新载入页面，如动画、RSS 源、其他实时数据更新等等。Ajax 有不计其数的更新网页上元素的方法。但是了解 Ajax 的最简单的方式，可以这样想，在 Ajax 驱动的应用程序中，数据可以从应用服务器检索，然后显示在页面上，而不需要重新加载整个页面。只有一小部分的页面，或者只有元素本身被重新加载。

10.1.3、自动化测试用例编写原则

在编写自动化测试用例过程中应该遵守以下几点原则：

1、一个用例为一个完整的场景，从用户登录系统到最终退出并关闭浏览器。

2、一个用例只验证一个功能点，不要试图在用户登录系统后把所有的功能都验证一遍。

3、尽量少的编写逆向逻辑用例。

3.1、一方面因为逆向逻辑的用例很多（例如，手机号输错有几十种情况）； 3.2、另一方面自动化脚本本身比较脆弱，对于复杂的逆向逻辑用例实现麻烦且容易出错。

4、用例与用例之间尽量避免产生依赖。

5、一条用例完成测试之后需要对测试场景进行还原，以免影响其它用例的执行。

10.2、126 邮箱项目实战

以126邮箱为例，综合运用前面所讲到的知识点，来完成一个自动化测试项目。

10.2.1、编写自动化测试用例

关于功能用例的管理大概分两类，一类是通过 word、excel 等文档工具进行管理，另一类由缺陷管理具工维护，如 QC、禅道项目管理等都自带的有用例管理功能。因为自动化测试用例对执行的步骤有着更高的要求，所以通过 excel 描述是个不错的选择。

用例001：

用例id	LoginTest.java	用户登录、退出
步骤	动作	数据	验证点
1	打开登录页	http://www.126.com
2	用户登录	Username 123456	匹配用户昵称“xxx”
3	用户退出