预期结果：是我们在需求上人为定义的，很多测试员在测试时遇到需求不明确，没有标准，其实就是不知道预期结果是什么。将预期结果转化为机器可识别的数据也是一个难点。
结果比较：验证测试结果是正确还是错误，良好的自动化测试除了需要自动化的执行，还需要包括自动化的验证，有时候自动化的验证比自动化操作更困难。
要实现自动化测试，就要将这三样东西通过程序来实现，并且高效地结合起来。何谓高效地结合起来？就是预期结果和实际结果可以大量快速获取进行比较，并且尽量少地出现人为干涉。比如我们控制一个程序能够读取到全部预期结果，并且执行操作获取全部实际结果，然后可以自动比较两者生成报告，这样就比我们人手控制一个程序单个多次地读取预期结果，再人手控制另一个程序单个多次地获取实际结果，再人手控制第三个程序去单个多次地比较前两者的结果要高效。当然，如果这些程序是统一控制，相互自动触发的话，那效果也等同于一个程序，在实际中这种情况是很常见的。
实际过程中又可以分为UI界面交互和非UI界面交互的情况。
非UI界面交互，以接口测试为例：
1.批量的发送请求并获取返回值，
2.批量得到预期结果并转为机器可识别的数据，可以用xml或者excel一类的文档来准备数据，使用工具的话可以将多个case保存为一个集合。
3.批量比较返回值和预期结果数据，将前两步的数据都获取到之后再用字符或者正则表达式来比较两者，用工具的话需要选择那些可以断言返回值的。
4.将比较结果生成测试报告。
UI界面交互，以Web UI测试为例：
1.需要实现web操作，无论你是自己写程序实现，还是用现有的工具，都是将动作、对象、数值组织起来完成一个web操作。比如登入网站，分3个步骤，（1）输入用户名，（2）输入密码，（3）点击登入按钮，
2. web操作之后，我们就可以获取到相关的实际结果，例如登入成功的提示，或者登入后的网页内容，我们就需要通过程序去获取回来，准备之后的比较。
3.通过实际结果与预期结果判断，使用断言来判别执行失败或者通过。
总结, 如果想用自动化测试去发现错误，首先就必须由人去预想可能出现错误的各种情况，然后用自动化去检查。这样其实就不是用自动化去发现错误了，而是由人去寻找错误（或者错误的可能性），然后用自动化去验证。偏偏试图通过自动化去发现错误是很多人开展自动化的最初目的，于是就导致了自动化的高代价，投入了人工（预测错误，设计用例，编写脚本），但自动化的成果只能局限在人工能够预测到的范围之内。所以我们可以看到很多案例，在使用了自动化测试之后，用手工测试依然可以发现大量的bug。所以，能否发现bug，最核心的东西是用例，而不是工具或方法，只有用例能够发现bug，工具只是实现的手段而已。因此，想要测试得更好，应该加强的是设计用例的能力。