3.也可能我的数据要来自外部的其他系统或系统内部的其他模块，比方说某个web服务接口，如果这个接口实际不存在而需要自动化测试人员写一个代替品，那么这个代替品我们叫他桩（Stub）。
4.还有可能我的数据来自自动化测试人员写的某一程序，比如我写过一个插件用于生成符合数据类型定义的随机数据。像用户注册规定用户名是多少位的字符串，哪些符号不能出现，然后密码要符合什么规则，出生年月要符合什么规则，我的插件就在规定的范围内随机生成合理的数据。
准备数据在很多项目中都是难点，有时获取到的数据还需要进行转换，此时又要写程序，比如我们编写一个插件把某web服务接口返回的二进制编码转换成另一个web服务接口需要的输入数据的类型。
另外，除了selenium，还有很多其他层次的自动化测试，这一个步骤也会遇到其他很多难题，但至少这些原理定义是需要有个大概概念的。
题外话，请记得把自己写的小程序/脚本都称为"插件"（plugin），这样听上去专业而且高大上（笑）。
最后第三步，结果对比。
就是简单对比第一步和第二步的结果。但是问题是要用何种方式组织第一步和第二步的结果，如何管理这些结果数据，并反映到测试报告中去。
以Java语言下的网页自动化测试为例，和测试执行器结合起来做断言是最常见的情况。
仍有很多种做法：
1.简单对比，比方说 assert（1+1 == 2），等于号左边是实际结果，右边是预期结果。
2.编写静态断言类，如assert（xxxPage.userIsSignedIn（））这样在XXXpage里自己写一个userIsSignedIn（）方法来判断用户有没有登录成功
3.封装DSL做断言，如mobilePhoneNumber.isNumbers().hasCorrectLength().notExistedInDataBase()这样一个方法链来判断某个文本框里输入的电话号码全由数字组成、长度正确、数据库里无重复记录。
等等
在自动化测试这个话题的最后谈一下我理解的自动化测试成功的前提：产品适合自动化、技术基础到位、成本估计充分
1.产品适合自动化：比如别人举过的一个例子：某项目要做8年，主要内容是做某产品的40国语言本地化测试。这样的项目很适合自动化
适合不适合自动化要综合考虑，一般来说，要看
UI是否稳定、业务需求是否稳定、现存功能BUG多不多、待测程序是否具有可测性、项目周期够不够长、对质量要求高不高、可用资源够不够等等
2.技术基础到位：有没有招到自动化测试的专家，技术难题有没有解决。自动化测试项目要当作一个开发项目来做，可想而知在没有专家的情况下开发一个高难度的自动化测试项目想成功太难了。
3.成本估计是否充分：自动化测试项目通常要长期投入才可见效，小项目切勿轻举妄动。
而且有一点就是，自动化测试和手工测试能发现的BUG是不同的。自动化测试做得好，不一定能减少手工测试的工作量，也不一定能够在脚本执行时发现多少BUG。从技术负责人到上层管理需要对自动化测试有一个相对正确的认识，判断好产品究竟是否做自动化，是否有钱搞自动化，是否招到了合适的人才来搞自动化。
实际上我面试过一些小单位，技术负责人说很重视自动化测试，希望搞100%的自动化测试，但他在技术面试时没问我任何技术问题就爽快地给了offer，我不禁心里问，既然重视自动化测试技术，为什么不问技术问题。还有一些单位嘴上说以自动化测试为主，很少做手工测试，说测试经理很重视开发能力，但同样在面试中没有问我任何技术题。有时我们要鉴别一个单位是否真的适合做自动化测试，就从这些小细节上看出来。当然反过来，还有公司问一大堆用不到的技术的问题，最后进去了发现还是做手工测试为主，这也是很有可能的。
通常，自动化测试是否成功和具体的公司类型，如互联网公司、传统软件公司、金融机构、通信公司这些关系不一定很大。但也不能说无关，通常我要考虑这些：
一个是软件开发的节奏和项目周期的长短，比如互联网公司的节奏比传统软件公司快得多。
一个是新技术的应用，比如很多银行只使用商业工具，拒绝开源工具。
一个是对软件质量的要求，比如造航天飞机的，对软件质量要求会高于做游戏的。
一个是产品手工测试的难度，比如大量数据的测试，手工实在太累。
一个是资金的投入，比如巨头级公司和小创业公司相比，前者的投入更大，后者往往没有测试或刚招了一个初级测试。