最近在弄 appium,而后顺便发现了 Selenium 框架和这本书,刚好这本书也介绍了一些软件测试&自动化测试的理论知识,遂拿过来学习学习。因此本文几乎没有实践内容,大多都是概念和工具的 mark,后续如有实践,我会来补充的。html
需求分析前端
设计node
编码python
单元测试git
集成测试github
系统测试web
验收测试编程
白盒测试的意义:有时候输出是正确的,但内部其实已经错误了,这种状况很是多。设计模式
灰盒测试的意义:若是每次都经过白盒测试来操做,效率会很低,黑盒又太过笼统,所以折中的灰盒测试比较适合。api
功能测试
主要检査实际功能是否符合用户的需求。
功能测试又能够细分为不少种:逻辑功能測试、界面测试、易用性测试、安装测试、兼容性测试等。
性能测试
主要有时间性能和空间性能两种。
时间性能:主要是指软件的一个具体的响应时间。
空间性能:主要指软件运行时所消耗的系统资源。
自动化测试不能彻底地替代手工测试,自动化测试的目的仅仅在于让测试人员从烦琐重复的测试过程当中解脱出来,把更多的时间和精力放到更有价值的测试中,例如探索性测试。而自动化测试更多的是用来进行冒烟测试和回归测试。
自动化测试是本文要探讨的重点。
冒烟测试
:引入到软件测试中,就是指测试小组在正式测试一个新版本以前,先投入较少的人力和时间验证一个软件的主要功能,若是主要功能都没有运行经过,则打回开发组从新开发。这样作的好处是能够节省时间和人力投入到不可测的项目中。
回归测试
:回归测试是指修改了旧代码后,从新进行测试以确认修改后没有引入新的错误或致使其余代码产生错误。
随机测试
探索性测试
安全测试
正向测试用例 (Positive Test Case) 和反向测试用例 (Negtive test Case) 是对测试用例的一种分类。
例如:一个输入只能接受输入数字0-9,那么正向用例能够为:0,1,2,3,4,5,6,7,8,9,反向用例能够为:其它值。
反向测试用例一般指,系统不支持的输入或则状态,这类用例能够检查系统的容错能力、健壮性和可靠性。
自动化测试
的概念有广义与狭义之分:广义上来说,全部借助工具来辅助进行软件测试的方式均可以称为自动化测试:狭义上来说,主要指基于 UI 层的功能自动化测试。
注意:若是没有特别说明,则本文所说的“自动化测试”均指“基于 UI 的功能自动化测试”。
不一样测试阶段所投入的自动化测试的比例:Unit > Service > UI。
单元测试:单元就是人为规定的最小的被测功能模块。规范的进行单元测试须要借助单元测试框架,如 Java 语言的 Junit、TESTNG, C# 语言的 Nunit,以及 Python 语言的 unittest、pytest 等,目前几乎全部的主流语言都有其相应的单元测试框架。
Code Review:与 Code Review 相关的插件和工具备不少,例如 Java 语言中基于 Eclipse 的 Review Clipse 和 Jupiter、主要针对 Python 语言的 Review Board 等。
如今由于 github/gitlab 的流行, 之前的工具用的不多了。不排除大厂用一些更专业的工具。
目的:
一、改善代码质量
一些很基础的,好比缩进空格什么的,就交给 eslint 什么的去解决吧。
二、保证团队代码规范
三、提升代码性能
四、预防 bug
五、加深技术团队成员沟通,营造技术氛围
六、老带新互助成长
实践建议:
一、全部代码都必须通过 Review 才能 merge。
二、批评的时候最好同时给解决方案
三、每次 review 至少给一条正面评价,提升对方信心
四、不要在 review 中讨论需求
五、不要在 review 中讨论太多的架构或者设计模式,这个应该是在前期设计时解决的事
普及状况:
Code Review 作得好的广泛是一些比较偏技术的团队,而偏业务的技术团队比较少。
咱们公司也不多作其实。
接口测试:也有相应的类库或工具,例如测试 HTTP 的有 Httpunit、Postman 等。
UI 自动化测试:目前主流的测试工具备 UFT、Watir、Robot Framework、Selenium 等。
JS 自动化测试:Qunit 就是针对 Javascript 的一个强大的单元测试框架,由jQuery团队的成员所开发,而且用在jQuery,jQuery UI,jQuery Mobile等项目。
其实这个也是单元测试,可是由于是前端,因此归到了 UI 这边。
(1)软件需求变更不频繁
或者一种折中的作法是先对系统中相对稳定的模块与功能进行自动化测试,而变更较大的部分用手工进行测试。
(2)项目周期较长
(3)自动化测试脚本可重复使用
(4)等等
最原始的方法,测试用例之间可能会存在重复的操做,会致使开发成本和维护成本都很高。
很好地解决了脚本的重复问题。
由于输入数据的不一样从而引发输出结果的不一样。实现了数据与脚本的分离。
理解了数据驱动后,无非是把“数据”换成“关键字”,经过关键字的改变引发测试结果的改变。
好处:
目前市面上典型关键字驱动工具以 QTP(目前已改名为 UFT- Unified Functional Testing)、Robot Framework (RIDE)工具为主。这类工具封装了底层的代码,提供给用户独立的图形界面,以“填表格”的形式免除测试人员对写代码的恐惧,从而下降脚本的编写难度,咱们只需使用工具所提供的关键字以“过程式”的方式来编写用例便可。
坏处:
关键字驱动也能够像写代码同样写用例,在编程的世界中,没有什么不能作:不过这样的用例一样须要较高的学习成本,与学习一门编程语言几乎至关。这样的框架越到后期越难维护,可靠性也会变差,关键字的用途与经验被局限在本身的框架内,你所学到的知识也很难重用到其余地方。因此,从测试人员的经验与技术积累价值来说,笔者更倾向于直接经过编程的方式开发自动化脚本。
本章实操部分省略,后续如有实践,会适当补充。
有人说咱们公司的软件是用某语言开发的,因此自动化测试也要选某语言:其实软件开发语言和软件自动化测试语言没有必然联系。也就是说,基于 Python (+ Selenium)编写的自动化测试脚本既能够测试基于 Java 开发的 Web 项目,也能够测试基于 PHP 开发的 Web 项目。因此,在选择 Selenium 自动化测试语言时不须要考虑与开发语言的一致性。
selenium 2
是 web 浏览器自动化测试框架。
下文的 selenium 默认都指 selenium 2。
虽然 selenium 支持 Android 自动化测试,但更推荐 Appium
, Appium 是 selenium 的延伸,基本上能够视为 “Selenium for Apps”,由于它也是基于 Selenium 的 Webdriver 技术开发的。
selenium (selenium 1) 和 webdriver 原来是两个不一样的开源项目,但在 selenium 2 的时候,将selenium 与 webdriver 合并了,即:
selenium 2 = webdriver + selenium 1
因此 selenium 2 能够等价为 webdriver ,对于 Selenium 2 的学习,实际上是对 WebDriver API 的学习。
selenium 支持 HtmlUnit
和 PhantomJS
两个模式。
Phantom JS 是一个拥有 Javascript API 的无界面 Webkit 内核,与 Htmlunit 相似,但比它更高级一些。
经过 HtmlUnit 或 Phantom JS 进行的自动化测试运行不会真正打开一个浏览器,在咱们看来,可见的东西才会以为是真实的,须要的时候,能够调用截图的 api。
pip3 install selenium
控制浏览器:如调整窗口大小
找元素(定位)
操做元素
鼠标事件
键盘事件
设置元素等待
多 frame、iframe 切换 / 多窗口切换
调用switch_to.frame()
和 switch_to.window()
处理警告框
如接受警告框:driver.switch_to_alert().accept()
上传/下载文件
更复杂的上传/下载须要编写 Autoit 脚本
操做 Cookie
调用 JS
调用 execute_script()
经过浏览器插件的形式提供。
功能点备注:
一、断言和验证的区别:与断言
相比,当执行验证
命令失败后不会终止测试。
二、pause 和 waitfor 的区别: pause 来设置固定时间的体眠,而 waitfor 则用于在必定时间内等待某一元素显示。
三、支持将录制内容导出为代码,支持类型以下:
Ruby/Rspec/Webdriver
Ruby/Rspec/Remote Control
Ruby/Test: Unit/ Webdriver
Ruby/Test: Unit/Remote Control
Python/unittest/Webdriver
Python/unittest/Remote Control
Java/Junit4/Webdriver
Java/Junit4/Webdriver Backed
Java/Junit4/Remote Control
Java/Junit3/Remote Control
Java/TESTNG/Remote Control
C#/Nunit/Webdriver
C#/Nunit/Remote Control
利用 Selenium Grid 2 能够在不一样的主机上创建主节点(hub)和分支节点(node),可使主节点上的测试用例在不一样的分支节点上运行。对不一样的节点来讲,能够搭建不一样的测试环境(操做系统、浏览器),从而使一份测试用例获得不一样环境下的执行结果。
Selenium Grid 2 的时候,再也不提供单独的包,其功能已经集成到 Selenium Server 中,因此,须要下载和运行 Selenium Server オ可使用 Grid 2 的功能。
下文中 Selenium Grid 2 都简称为 Selenium Grid。
Selenium Grid 只是提供多系统、多浏览器的执行环境,Selenium Grid 自己并不提供并行的执行测试用例。因此建议使用多线程技术结合 Selenium Grid 实现分布式并行地执行测试用例。
在 Python 语言下有诸多单元測试框架,如 doctest、unittest、pytest、nose 等,unittest
框架(原名 Pyunit 框架)为 Python 语言自带的单元测试框架,Python2.1 及其之后的版本已将 unittest 做为一个标准模块放入 Python 开发包中。
单元测试
自己就是经过一段代码去验证另外一段代码。
一个 Testcase 的实例就是一个测试用例
。
一个用例为一个完整的场景,从用户登陆系统到最终退出并关闭浏览器。
一个用例只验证一个功能点,不要试图在用户登陆系统后把全部的功能都验证一遍。
用例与用例之间尽可能避免产生依赖。
一条用例完成测试以后须要对测试场景进行还原,以避免影响其余用例的执行。
一个功能的验证每每须要多个测试用例,能够把多个测试用例集合在一块儿来执行,这就产生了测试套件
Testsuite 的概念。
包含执行策略和执行结果。
对一个测试用例环境的搭建和销毁,就是一个 fixture。
待写
HTMLTestRunner
是 unittest 的一个扩展,它生成易于使用的 HTML 测试报告。
待写
跟上面说的 Selenium Gird 同样,unittest 单元测试框架自己并不支持多线程技术,它不能像 Java 的 TESTNG 框架同样经过简单的配置就可使用多线程技术执行测试用例。
SMTP (Simple Mail Transfer Protocol)是简单邮件传输协议。
Python 的 smtplib
模块提供了一种很方便的途径用来发送电子邮件。
可用于如测试时结果的告知。
Page 对象(Page Object)
的一个基本经验法则是:凡是人能作的事,page 对象经过软件客户端都可以作到。所以,它也应当提供一个易于编程的接口并隐藏窗口中底层的部件。因此访问一个文本框应该经过一个访问方法(accessor method)来实现字符串的获取与返回,复选框应当使用布尔值,按钮应当被表示为行为导向的方法名。page 对象应当将在 GUI 控件上全部查询和操做数据的行为封装为方法。一个好的经验法则是,即便改变具体的控件,paee 对象的接口也不该当发生变化。
也能够创建一个 base 的 Page 对象,让别的 page 继承它。
很像面向对象编程思想里的接口与实现。
待写