四、自动化与场景法结合
在第二步时，我们已经根据场景法设置了测试用例，如果我们设置了4条基础流，并且每条基础流有10条备选流，也就是40组测试用例，纯手工测试的话你可能需要做40次添加甚至更多的录入数据的操作，这个时候结合我们的工具，每条基本流录制一个测试脚本，也就是4个脚本，在执行备选流的时候只要在脚本中设置断点，或者直接运行脚本中你希望运行的部分让它单独执行循环，这里还是以第一步举的案例来分析。
基本流就是添加--修改--审核--发布---删除审核---彻底删除，以这条基本流录制一个脚本。
备选流
1、添加--删除
2、添加--发布
3、添加--发布--删除
4、添加--修改--删除
在脚本执行完添加时，因为删除不需要数据的录入，我们可以直接手动删除，（一般只需要点击就可以操作的，我们都可以自己操作，对新人来说最繁琐的还是重复数据的录入，尤其是系统对数据验证比较严格的时候，是很头大的）
这里为了说明，我们多加一条备选流，添加--发布--修改。
执行完了添加的脚本，我们可以将脚本直接跳到修改让他直接执行修改的脚本，这样一来我们的工作量就大大减少了，百分之70的工作量，随随便便就减少啦。
要实现这些操作，还需要一些细节上注意下，比如说断点的设置，脚本部分循环的完整性，也就是开头到结尾，要保证结尾后就是开头还要注意Action的设置和循环设置。
五、回归测试（验收测试）
一个项目的完成期间会有很多个版本，基本上修复一次BUG就会更新一个新版本，这个时候有可能这个BUG改了因为代码覆盖或其他原因其他BUG又出现了，如果每个版本，每次开发修改你都要重新测，是不是会很烦，你做到这里的时候是不是会觉得测试真没前途，实际上，依照上述的描述，你完全可以直接对可能有影响的功能模块选择性德去执行脚本，自动化测试最大的好处就是在于回归测试（验收测试）。
六、个人的小小感悟
就犹如前言所说，我们是测试员不是测试机器，不是上司让你做什么，你就做什么，人与机器最大的不同，就是人会偷懒，机器不会。
我一直认为自己是个懒惰的人，能用1小时解决的事情，为什么要用20小时解决呢，测试员不仅在设计测试用例的时候要用脑袋，在测试计划，测试执行一样要用脑袋，说实话，在项目开发过程中，我们测试的所能运用的时间是最少的，大部分情况我们无事可做，要测试需要等待版本的更新，而一个版本有可能需要一个星期才会更新，给我们的时间有时候只有一天，试想下一天的时间你要将开发人员做了一个星期的程序测试完，这个工作量，这也就是为什么测试员闲的时候很闲，忙的时候很忙了，所以我们一定要学会高效率的测试，工作是死得，人是活得，不要认为公司没有给你用自动化的待遇，也没有给你用工具的工作你就不去做了，仔细想想收益最大的人依旧是你，不管是从技术角度还是从工作量来讲。
最后补充一句，不用脑袋的测试员，与测试机器无异。
