自动化测试用例如何设计，对于新手来说也是比较难理解的问题。
不少新手刚刚掌握了写脚本的能力，一上来就拿着
功能测试用例一条一条的转化成自动化用例。在写的过程中，会发现诸多问题，例如，脚本中重复代码很多，一个脚本的执行结果影响到另一个脚本的执行，有些功能用例很难转化成自动化用例等。
站在用户角度设计自动化
在功能测试的时候我们一般会遵循这个原因，但是自动化测试往往可以实现更强大的功能，所以，我们在设计脚本的时候很容易违背这个原则。例如，你要获得的数据是用户不可见的，你要判断用例是否成功的信息也是用户不可见的，或者你要模拟的是用户永远不可能做的操作等。
设计简单傻瓜的用例
自动化脚本本来是很傻瓜的。记得有同学问我，
百度输入有个自动联想功能，就是在用户输入的过程中自动配置热门搜索的关键词，例如，用户输入“自”，会自动联想“自我评价”，“自行车”等。用继续输入“自动”，会自动联想“自动化”，“自动关机”，“自动档”等。他想定位自动联想下拉列表的某个关键词，这个关键词是百度根据用户搜索热度的变化而变化的。
再比例有同学问我，下拉列表功能，我想脚本执行时随机选择某一个选项，那么如何如何去判断随机的结果呢？换句话说，你都不知道你做了什么，怎么去判断做的结果对不对？
所以，我们在设计用例时尽量考虑简单傻瓜的用例，操作步骤简单，预期结果容易判断等。
从简单开始
对于新需要自动化的项目来说，自动化测试的实施是循序渐进的，不要一上来就设计几百条用例，而是逐步的将功能用例转成自动化用例，在转的过程中需要不断的调整测试结构。然后，再增加稳定的
测试用例。然后，再调整测试结构。随着功能的增加你的自动化测试框架也在逐渐稳定，基础测试用例也在增加。一上来就几百条用例，需求的稍微变化，用例就可能大调整，那么你很可能每天疲惫于用例的维护。
所以，在开始自动化的时候，你可以只对登录功能写个十来条的自动化用例。从而，渐渐的考虑将更多功能自动化起来。
半自动化对于测试人员是个不错的开始，这样你可以将更多的精力花在
安全测试，探索性测试，甚至是用例体验上等。不要觉得全职自动化就是多么高大上的职位。