先来说下一般自动化测试的流程，今天一个朋友也问过我这个问题，就顺便说说。
一般在开始自动化测试，如拿到一个程序包或apk或网站文件后，我们首先要做的就是要分析这个程序适不适合进行自动化测试；之后再对程序的执行路径进行分析，找出一些关键路径和有针对性的进行测试设计；然后就是测试用例编写和脚本编写执行了；最后就是结果分析和优化了。
在这些过程中，其实关键的地方的地方在于测试设计，包括测试用例、测试脚本架构及测试组织等。
下面就主要说说自动化测试用例的写法。
首先，我们要确定一点，就是自动化的目的和作用。
自动化测试是为了代替人执行需要大量重复的规律性或“无规律”的工作，它的主要目的在于验证问题，而不是发现问题；所以我们对于自动化的设计，就主要集中在功能的正确性方面。至于很多人想象中的自动化测试可以为你发现多少个bug，这个即使能实现，投入和产出也是不成比例的。
根据自动化的目的和作用，我们可以大致确定以下几点：
1. 自动化的测试用例都必须是正向的。这里的正向指的是代码可实现的非主观操作，如按钮点击、页面切换、资源下载等。至于说页面颜色显示对不对、样式好不好看等需求还是用人来实现吧，那些太费事不说，而且成本太高、效果太差。
2. 自动化的测试用例需要更多的关注功能逻辑的实现，而不必纠结于某些字段的限制。字段限制等需要在测试分析阶段来手动确定的。
3. 自动化的测试用例上下文必须有一定的顺序性，要能够互相连接起来；并且前置条件清楚，有一些是显式的前置条件，一些是隐式的前置条件。
4. 自动化的测试用例必须是可回归的，不能太马行空般飘来飘去。否则迭代和自动执行就是空谈。
说了这些，还是有些空泛，那现在就以一个例子来说明下，这个编辑器不太好用，懒得自己写html脚本了，凑合看吧。
TestCase1[前置条件：有道词典程序未启动]：
1. 启动有道词典。预期结果：任务通知栏中有有道词典的程序/如果是windows7系统，则可以验证进程是否启动
TestCase2[前置条件：有道词典程序已启动]：
1. 显示有道字典主窗体。预期结果：有道词典窗口显示在桌面
2. 输入要查询的单词：silence，点击【查询】预期结果：查询后左侧属性列表显示查询结果索引，右侧区域显示查询内容
3. 关闭有道词典主窗体。预期结果：有道词典主窗体关闭
TestCase3[前置条件：有道词典已打开]：
1. 退出有道词典程序。预期结果：有道词典从任务通知栏消失/如果为windows系统，则任务管理器中没有改进程
上面这三条TestCase可以构成一个完整的循环，并且TestCase2也可以作为一个完整的查询功能的循环。这个与我们平时写的手工测试用例对比起来更加注重连贯性与功能的交互，而这些也正是自动化赖以生存的根本。
当测试用例不断完善之后，就可以抽取部分测试用例来进行初始化，如TestCase1；或者进行场景恢复，如TestCase3。当然，那些都是后话了。