【转】selenium：你必须知道的七件事(1)

xchen · 发表于 2017-10-13 15:39:57

selenium：你必须知道的七件事

原文链接：https://www.lucidchart.com/techb ... you-need-to-know-2/

译者的话：

本文的作者就职于Lucid，如文中所述他们有着一套比较成熟的基于selenium的自动化测试工具。这得益于他们对于自动化测试的重视，因为只有自动化测试才能很好地保证敏捷开发的软件质量。目前国内已经渐渐开始重视自动化测试，但是由于起步较晚，大多数公司的软件测试依旧依赖于人力的叠加，这也使得软件测试工程师在大多数时候被认为是IT行业内的二等公民。事实上，想成为一名优秀的软件测试工程师，要求有着很强的功底，需要掌握很多技能。只有每个软件测试工程师都认识到这点，才能更好地担负起职责，整个行业才能发展。

selenium是一套最近比较火的开源自动化测试框架，比传统的自动化测试工具有着更高的灵活性。灵活性意味着你可以按自己的想法去使用它，但同时也意味着你需要掌握一定的技巧去驾驭它。作者在文中介绍了七个需要注意的地方，其中有些在我的工作中也使用到了，有些跟我用的方式不同，还有一些我没有用。本文仅仅是一种参考。《孙子兵法》中说，兵无常势，水无常形。我认为做技术是一样的，怎么用取决于你的需求。技术是用来提高效率、保证质量、降低成本的，不是拿来吹嘘的。否则就会成为孔乙己，“你知道茴的四种写法吗”。

哈哈~

Selenium是测试工程师工具库中的一件强大的工具。然而不幸的是，如果不能很好的驾驭它，它有可能会消耗你很大精力去编写测试用例，维护起来极其艰难，甚至会取得适得其反的效果。

起初，我厂有一个涵盖了300个测试用例的测试集，它们由40个不同的开发人员编写。每次我们run这些用例，总有六七十个会报错。为了保险起见，我们让一位同事专门负责统计在这些报错中哪些用例正确地发现了错误，哪些是误报。这工作几乎占据了他全部的时间。所以当他发现那些误报的用例阻塞了自动构建流程，并且这些用例难以修复的时候，他就会将它们从自动构建中注掉。久而久之，这些用例慢慢地就被遗忘了。

有次我们新增了一个feature，在我们的测试过程中居然没有发现它有个bug，直到这个feature上线两周后，这个bug才被发现。我们都惊呆了，居然会让这个bug通过开发环境，躲过测试环境的抓捕，顺利进入生产环境。我准备一探究竟，结果不出我所料，我一个月前为这个feature写的用例被人注掉了！！尼玛，我心中简直有千万只草泥马蹦过。但与此同时，我陷入了深深的思考，到底怎么样才能让我们的selenium测试用例变得可靠、可扩展、容易维护呢？

不仅是我，我们整个团队都致力于寻找答案的工作中。经过持之以恒的努力，工作取得了不错的效果。我们在把误报率降低到百分之一以下的同时，把测试用例的数量增加到原来的两倍。我们会定期的在开发过程中回归分析，新增测试用例去覆盖我们产品中的新feature。selenium在我们的版本发布中扮演了一个极其重要的角色，下面就就让我介绍一下我们在使用selenium过程中最需要注意的七件事。

使测试用例更容易编写

我们发现很多时候编写测试用例所使用的时间和开发修改一个bug或新增一个feature的时间一样，基于这点，我们需要使得测试用例更容易编写。我们提供的解决方案是创建测试用例的Application User和Application Driver。

1、创建Application User

所谓ApplicationUser其实就是selenium在后台操作的代理。对我们来说就是创建一个新的 Lucidchart或者 Lucidpress的用户，发起一次订阅、创建一个文档。它包含了一些对于测试场景的准备操作。同时这个类也可以包含调用后端service的通道，比如说添加团队成员，下载图片或者字体。使用这个类使得改变订阅等级变得特别容易。下面就给出一个测试开发人员使用application User的示例：

classEditorPerformanceTest extends LucidSpec {

val user = new ChartUser

override def beforeAll() {

user.login()

user.createDocument()

}

override def afterAll() {

user.finished()

}

在这种情况下，所有的设置都简化成了两个方法调用，不再需要写额外的启动操作。在测试的最后，所有的关闭操作都由结束方法执行。总而言之，使用User类，我们使得测试开发人员更容易地创建测试用例，把主要精力放在验证bug和测试新feature上。

2、创建Application Driver

selenium的api很容易让人感到绝望。因为单单获取一个元素就可以用差不多二十种不同的方法实现。去模拟浏览器各种操作的方法更是不计其数，拖拽和释放、左击和右击、使用滚轮、输入等等等等。为了简化这些操作，不必让所有的测试开发人员都十分熟悉整个webDriver api文档，我们创建了一个driver去简化大多数相似的操作。也就是Application Driver，它继承自WebDriver，并添加了部分selenium其它的操作类。以此为基础，我们又添加大多数通用的操作，比如点击元素，执行脚本，拖拽释放网页元素。这个类差不多下面这个UML图这样的结构，包含了一些非常简单的方法

def dragAndDrop(cssFrom: String, cssTo: String) { val elem1 = getElementByCss(cssFrom) val elem2 = getElementByCss(cssTo) actions.dragAndDrop(elem1, elem2)} def contextClickByCss(css: String) actions.contextClick(getElementByCss(css))}

当测试开发人员需要更多复杂操作的时候，他们依然可以采用webDriver和selenium 原生的操作类。但是对我们大多数测试而言，Lucid Driver完全够用了。采用了这个方法还有另外一个好处，就是使得在编写测试用例的时候更容易去调试了。因为所有的测试开发人员使用的是同样的方法，而不是他们使用各自在api文档里找到的不同方法去实现完全相同的功能.

使测试用例更容易更新3、使用DOM IDs

在dom结构中去定位一个元素是编写selenium测试用例中最具挑战的一个部分。给标签添加ID可以使得某个页面元素在整个应用中拥有一个独一无二的标识。在我们最初的测试用例中，我们使用xpath、classPath、css选择器去定位重要的页面元素。然而，当我们调整了页面结构，或者是简单的改变了原来css class的名字之后，发现原先的测试用例已经不能用了，需要修改在测试用例重写element locate。但是如果给每一个页面元素都赋一个ID，无论DOM结构怎么变、样式怎么变，我们都能很轻松地定位到页面元素。

下面是一个典型的例子，针对这个特殊的feature有4个测试集，总的测试用例在30个左右。另外还有20-30个测试用例是依赖这个feature的。由于我们给页面元素添加了ID，这些测试用例几乎就不需要怎么维护了。这些测试用例可以轻松找到找到任何他想要的页面元素。可以想象，如果不使用ID的话，对这个feature个小小的页面调整，都可能使得上述的测试用例都要修改一遍。