测试工程师之selenium

自动化测试方法

   测试对象：UI、接口、代码
   测试过程：系统测试、集成测试、单元测试
   执行人员：测试人员、开发人员
   自动化测试可以在整个测试过程中任何一个阶段实施，前提功能相对稳定
   测试人员一般在系统测试时进行自动化测试
   集成测试阶段多进行自动构建、部署，以及冒烟测试的自动化
   单元测试针对代码级别进行测试，可进行静态代码检查，或者执行单元测试用例，典型的框架比如junit，
jmock等，该部分多由开发人员实施

UI自动化

    用例维护量大
    页面相关性强，必须后期介入
    UI测试适合与界面变动较小的项目

接口自动化

   可在产品前期介入
   用例维护量小
   页面相关性小
   适合接口变动较小，界面变动频繁的项目
   自动化测试的优势
   降低大型系统的由于变更或者多期开发引起的大量的回归测试的人力投入，这可能是自动化测试最主要的任务，
 特别是在程序修改比较频繁时，效果是非常明显的，自动化测试前期人力投入较多，但后期进入维护期后，可节省大量人力，
而手工测试后期需要增加大量人力用于回归测试
减少重复测试的时间，实现快速回归测试
创建优良可靠的测试过程，减少人为错误
可以运行更多更繁琐的测试
可以执行一些手工测试困难或不可能进行的测试
更好的利用资源
测试具有一致性和重复性
测试脚本的重用性

自动化测试的适用对象

实施自动化测试的前提条件：需求变动不频繁、项目周期足够长、自动化测试脚本可重复使用
1、需求变动频繁的项目，自动化脚本不能重复使用，维护成本太大，性价比低
2、项目周期短，自动化脚本编制完成后使用次数不多，性价比低
3、交互型较强的项目，需要人工干预的项目，自动化无法实施

适合做自动化的项目：

     1、产品型项目。产品型的项目，新版本是在旧版本的基础上进行改进，功能变不大的项目，但项目的新老功能都必
   须重复的进行回归测试。回归测试是自动化测试的强项，它能够很好的验证你是否引入了新的缺陷，老的缺陷是否修
   改过来了。在某种程度上可以把自动化测试工具叫做回归测试工具。
     2、机械并频繁的测试。每次需要输入相同、大量的一些数据，并且在一个项目中运行的周期比较长。

如何实施自动化测试

	1.分析：总体把握系统逻辑，分析出系统的核心体系架构。
	2.设计：设计测试用例，测试用例要足够明确和清晰，覆盖面广而精
	3.实现：实现脚本，有两个要求一是断言，二是合理的运用参数化。
	4.执行：执行脚本远远没有我们想象中那么简单。脚本执行过程中的异常需要我们仔细的去分析原因。
	5.总结：测试结果的分析，和测试过程的总结是自动化测试的关键。
	6.维护：自动化测试脚本的维护是一个难以解决但又必须要解决的问题。
	7.分析：在自动化测试过程中深刻的分析自动化用例的覆盖风险和脚本维护的成本。

元素的定位

id
name
class name
link text
partial link text
tag name
xpath
css selector

操作测试对象

click 点击对象
send_keys 在对象上模拟按键输入
clear 清除对象的内容，
submit 提交表单，（类似click）
text 用于获取元素的文本信息

添加等待

		time.sleep()（固定等待）
		implicitly_wait()（智能等待）

打印信息

		current_url
		title

浏览器的操作

		maximize_window() #将浏览器最大化显示
		browser.set_window_size(480, 800) 设置浏览器宽480、高800显示
		browser.back()  浏览器的后退
		browser.forward()  浏览器的前进

键盘事件

		send_keys(Keys.TAB) # TAB
		send_keys(Keys.ENTER) # 回车

鼠标事件

		context_click() 右击
		double_click() 双击
		drag_and_drop() 拖动
		move_to_element() 移动

定位一组元素

		get_attribute：获得属性值。
		find_elements_by_tag_nam 找到这一组元素

多层框架定位

		switch_to_frame()
		switch_to_window()

alert、confirm、prompt 的处理

		text 返回alert/confirm/prompt 中的文字信息
		accept 点击确认按钮
		dismiss 点击取消按钮，如果有的话
		send_keys 输入值，这个alert\confirm 没有对话框就不能用了，不然会报错

单元测试框架 unittest

Test Fixture

初始化和清理测试环境，比如创建临时的数据库，文件和目录等，其中 setUp() 和 setDown()是最常用的方法

TestCase

单元测试用例，TestCase 是编写单元测试用例最常用的类

TestSuit

单元测试用例的集合，TestSuite 是最常用的类

TestRunner

执行单元测试

TestReport

生成测试报告

用例的执行顺序**

unittest 框架默认加载测试用例的顺序是根据ASCII 码的顺序，数字与字母的顺序为： 0~9,A~Z,a~z

断言

		1.assertEqual(arg1, arg2, msg=None) 验证arg1=arg2，不等则fail
		2.assertNotEqual(arg1, arg2, msg=None) 验证arg1 != arg2, 相等则fail
		3.assertTrue(expr, msg=None) 验证expr是true，如果为false，则fail
		4.assertFalse(expr,msg=None) 验证expr是false，如果为true，则fail
		5.assertIs(arg1, arg2, msg=None) 验证arg1、arg2是同一个对象，不是则fail
		6. assertIsNot(arg1, arg2, msg=None) 验证arg1、arg2不是同一个对象，是则fail
		7. assertIsNone(expr, msg=None) 验证expr是None，不是则fail
		8. assertIsNotNone(expr, msg=None) 验证expr不是None，是则fail
		9. assertIn(arg1, arg2, msg=None) 验证arg1是arg2的子串，不是则fail
		10.assertNotIn(arg1, arg2, msg=None) 验证arg1不是arg2的子串，是则fail
		11.assertIsInstance(obj, cls, msg=None) 验证obj是cls的实例，不是则fail
		12. assertNotIsInstance(obj, cls, msg=None) 验证obj不是cls的实例，是则fail

HTML报告的生成

异常捕捉和错误截图

数据驱动ddt