一、自动化测试原理：
我的个人理解：
首先，自动化测试只有三个核心步骤：1.获取预期结果；2.获取实际结果；3.比较1和2的结果以判断测试是否通过。下面我先举一个最简单的三步走例子：
第一步，获取预期结果的方法：直接知道。
比如说，我测试一个网站的用户登录模块，当我要测成功登录的情况时，我的预期结果就是登录成功。
第二步，获取实际结果的方法：编写和执行测试，再获取执行结果。
知道预期结果之后，我就去编写自动化测试脚本，操作 浏览器，然后做登录，最后根据页面上显示的文字或 数据库里的信息，得知用户是否登录成功。
第三步，比较第一步和第二步的结果。
第一步里，我预期登录成功，第二步里我知道了登录实际上成功了，那么第三步对比结果是相同，测试通过。假如第二步里实际上登录失败了，则第三步对比结果是不同，测试失败。
接下来，实际上，我们会发现，这三个步骤可以扩展和细分，也都有相应的困难和解决的方案。
比如说，第一步，获取预期结果的方法，有可能我们不知道。
举个例子，我们知道 Java语言有sdk，sdk里有提供基本数学运算。那么假如要测试java sdk里两个整数Int做乘法的结果是否正确。怎么确定预期结果？手工测试时，我可以每做一个乘法调用，然后拿出纸和笔，使用数学方法列竖式来做乘法。但自动化测试里，我们做不到这一点。然后通常有以下解决方法：
1.只测少量已知样本：也就是我预先算好一些输入值和输出值，做一个表格，或者说测试数据和预期结果表。但这样做，我的测试覆盖率是比较低的。
2.用另一种算法重新实现程序：用这个算法的计算结果作为第一个待测算法的结果的预期结果。但这样的局限性是，成本太高（我的测试程序等于是另一个独立程序），可靠性存疑（测试程序可能自己出错）
3.从已知的可靠程序里获得结果：比方说我把这个待测程序跟某个正规通用的商业计算器连接起来，用这个计算器的结果来做为我的待测程序预期结果。局限性自然是受限于这个商业计算器本身
4.编写一些已知的规则来做不完全的校验：比方说我两个正整数相乘结果应该是一个正整数而是不会是负数。那么我把这个定义为一条规则，然后跑很多组测试，每组测试的结果里都去判断是否符合这个规则。假如正数相乘乘出一个负数结果来，那就是BUG了。
其中最常用的是1和3，然后4也可以跟1、3一起用。在某些测试领域获取预期结果是难题，特别是方法4是用来解决难题的，另一些领域则经常是直接知道预期结果。
再比如说，第二步，获取实际结果的方法，这一步也就是我们在网上看到过无数的工具使用的讲解，都是为了获得实际结果。你看到的大多数资料都是讲这一步骤。
举个例子，你要用selenium操作浏览器做网页测试。那么获取实际结果这个步骤再次划分为两个小步骤：1.定位页面元素；2.操作页面元素；
1.定位页面元素，就是selenium里的WebElement.findByxxxx,通过dom对象里的一些属性或xpath等定位方法来定位元素，找到我要操作的页面元素，比如某个按钮或者某个文本框。
2.操作页面元素，则是使用selenium的api提供的方法对按钮作出点击，对文本框输入文字等。
在做第一步定位页面元素的时候，有时你定位不到，这时就要想办法去定位或者绕过这个难点。
在做第二步操作页面元素的时候，我们根据实际情况，可能要先做数据准备再来操作，比方说我填表单要填哪些数据进去，要先确定，也就是做数据准备。
数据准备又可以细分下去有很多方法来准备。
1.最简单的就是预先定义好有限的样本，顺便还可以把预期结果也定义好
2.也可能要从数据库里实时去查询我要用的数据
3.也可能我的数据要来自外部的其他系统或系统内部的其他模块，比方说某个 web服务接口，如果这个接口实际不存在而需要自动化测试人员写一个代替品，那么这个代替品我们叫他桩（Stub）。
4.还有可能我的数据来自自动化测试人员写的某一程序，比如我写过一个插件用于生成符合数据类型定义的随机数据。像用户注册规定用户名是多少位的字符串，哪些符号不能出现，然后密码要符合什么规则，出生年月要符合什么规则，我的插件就在规定的范围内随机生成合理的数据。
准备数据在很多项目中都是难点，有时获取到的数据还需要进行转换，此时又要写程序，比如我们编写一个插件把某web服务接口返回的二进制编码转换成另一个web服务接口需要的输入数据的类型。
另外，除了selenium，还有很多其他层次的自动化测试，这一个步骤也会遇到其他很多难题，但至少这些原理定义是需要有个大概概念的。
题外话，请记得把自己写的小程序/脚本都称为"插件"（plugin），这样听上去专业而且高大上（笑）。
最后第三步，结果对比。
就是简单对比第一步和第二步的结果。但是问题是要用何种方式组织第一步和第二步的结果，如何管理这些结果数据，并反映到测试报告中去。