今天完成的事情： 学习python和se测试工具 问题还挺多 

明天计划的事情： 学selenium录制方法 

遇到的问题： 自动化的东西都是问题.,..

收获：

elenium 是什么？

Selenium 是web自动化测试工具集，包括IDE、Grid、RC（selenium 1.0）、WebDriver（selenium 2.0）等。

Selenium IDE 是firefox浏览器的一个插件。提供简单的脚本录制、编辑与回放功能。

Selenium Grid 是用来对测试脚步做分布式处理。现在已经集成到selenium server 中了。

RC和WebDriver 更多应该把它看成一套规范，在这套规范里定义客户端脚步与浏览器交互的协议。以及元素定位与操作的接口。

如何开展自动化测试

准备测试用例

找到合适的自动化测试工具

用准确的编程形成测试脚本

在测试脚本中对目标进行“检查”，即做断言

记录测试日志，生成测试结果

和所有的其他测试一样，自动化测试的流程也是由“用例”执行和“缺陷”验证组成。差别是需要找到合适的“工具”来替代“人手”。不同目标的自动化测试有不同的测试工具，但是任何工具都无不例外的需要“编程”的过程，实现“源代码”，也可以称之为测试脚本。于是开展自动化测试的方式基本上如下

自动化测试包括三个方面：UI前端界面，Service服务契约和Unit底层单元

越是底层的测试，运行速度越快，时间开销越少，金钱开销越少

越是顶层的测试，运行速度越慢，时间开销越多，金钱开销越多

这是理想中的金字塔原理。

在实际的项目中，尤其是结合国内的项目实践，其实还隐藏了另一个问题：越是顶层的测试，效果越明显。有句话说“贵的东西，除了贵，其他都是好的！”能够很清晰的阐述这个观点。

金字塔原理在国内的适应性也有一定的问题

自动化测试的起步不是特别早

甚至软件测试很长一段时间都在进行基于业务的手工测试，测试人员的代码能力相对较弱

开发人员在代码中不太习惯写单元测试

近些年基于服务契约的API测试也在兴起

相对来说，在基于UI前端界面的自动化测试反倒是开展和实施的不是特别多。尽管基于界面的测试带来的效果还是能够立竿见影的。对于产品的质量提升，还是比较容易有保证。

自动化测试的适用范围

自动化测试可以涉及和试用的范围主要在以下方面：

基于Web UI的浏览器应用的界面测试

基于WebService或者WebAPI的服务契约测试

基于WCF、.net remoting、Spring等框架的服务的集成测试

基于APP UI的移动应用界面测试

基于Java、C#等编程文件进行的单元测试

本文集中讨论第一条：基于Web UI的浏览器应用的界面测试。界面的改动对于测试来说，具有较大的成本风险。主要考虑以下方面：

任务测试明确，不会频繁变动

每日构建后的测试验证

比较频繁的回归测试

软件系统界面稳定，变动少

需要在多平台上运行的相同测试案例、组合遍历型的测试、大量的重复任务

软件维护周期长

项目进度压力不太大

被测软件系统开发比较规范，能够保证系统的可测试性

具备大量的自动化测试平台

测试人员具备较强的编程能力

自动化测试的流程

自动化测试和普通的手工测试遵循的测试流程，与项目的具体实践相关。一般来说，也是需要从测试计划开始涉及自动化测试的。

测试计划：划定自动化测试的范围包含哪些需求，涉及到哪些测试过程

测试策略：确定自动化测试的工具、编程方案、代码管理、测试重点

测试设计：使用测试设计方法对被测试的需求进行设计，得出测试的测试点、用例思维导图等

测试实施：根据测试设计进行用例编写，并且将测试用例用编程的方式实现测试脚本

测试执行：执行测试用例，运行测试脚本，生成测试结果