1、不是所有的手工用例都要转为自动化测试用例。
2、考虑到脚本开发的成本，不要选择流程太复杂的用例。如果有必要，可以考虑把流程拆分成多个用例来实现脚本。
3、选择的用例最好可以构建成场景。例如，一个功能模块，分多个用例，多个用例使用同一个场景。?
4、选择的用例可以带有目的性。例如，这部分是用例做冒烟测试，那部分用例是做回归测试等，
当然，会存在重叠的关系。如果当前用例不能满足需求，那么唯有修改用例来适应脚本和需求。
5、选取的用例可以是你认为是重复执行，很烦琐的部分。例如，字段验证、提示信息验证这类，这部分适用于回归测试。
6、选取的用例可以是主体流程，这部分适用于冒烟测试。
7、自动化测试也可以用来做配置检查、数据库检查。这些可能超越了手工用例，但也算用例拓展的一部分，项目负责人可以有选择地增加。
8、平时在手工测试时，如果需要构造一些复杂的数据或重复一些简单的机械式动作，则告诉自动化脚本，让它来帮你，或许你的效率会因此而得到提高
在编写自动化测试用例过程中应该遵守以下几点原则：
1、一个用例为一个完整的场景，从用户登录系统到最终退出并关闭浏览器。
2、一个用例只验证一个功能点，不要试图在用户登录系统后把所有的功能都验证一遍。
3、尽量少的编写逆向逻辑用例。一方面因为逆向逻辑的用例很多（例如，手号输错有几十种情况）；
另一方面自动化脚本本身比较脆弱，对于复杂的逆向逻辑用例实现麻烦且容易出错。
4、用例与用例之间尽量避免产生依赖。
5、一条用例完成测试之后需要对测试场景进行还原，以免影响其它用例的执行。--- 数据清理