标签：多个 很多 数据 style 登陆 能力 处理 case 影响
1.一个脚本是一个完整的场景，从用户登陆操作到用户退出系统关闭浏览器。
2.一个脚本脚本只验证一个功能点，不要试图用户登陆系统后把所有的功能都进行验证再退出系统
3.尽量只做功能中正向逻辑的验证，不要考虑太多逆向逻辑的验证，逆向逻辑的情况很多（例如手机号输错有很多种情况）
，验证一方面比较复杂，需要编写大量的脚本，另一方面自动化脚本本身比较脆弱，很多非正常的逻辑的验证能力不强。 （我们尽量遵循用户正常使用原则编写脚本即可）
4.脚本之间不要产生关联性，也就是说编写的每一个脚本都是独立的，不能依赖或影响其他脚本。
5、整个脚本中只对验证点进行验证，不要对整个脚本每一步都做验证。
6. 如果对数据进行了修改，需要对数据进行还原。
7. 测试用例的上下文必须有一定的顺序性，要能够互相连接起来；并且前置条件要清楚。
8. 每个测试用例粒度必须尽可能小，短小简单的测试用例易于调试。如果测试用例不得不长而复杂，则把它分成两个或更多的私有方法，并单独调用这些方法。
9. 尽量把重复任务放入一个方法中，这样它可以被多个测试用例调用。
10. 测试用例需要记录操作步骤
11. 测试用例执行出错要截图，从日志查看错误能一目了然
12. 测试用例要有合适的验证点，符合测试用例的期待结果。验证用是否存在的方法，如文件存在。
13. 测试用例只要不匹配预设的验证点，即使该测试用例还有未执行完的代码也要中断下面的执行，抛出合适的异常并提供详细的失败信息，然后设置该测试用例运行结果为失败
14. 测试用例要尽量处理所有的异常以健壮
15. 用例中尽量少的出现sleep，建议用"wait until ..."来代替；
16. 可以采用并发执行用例的方法来提升效，这需要case的独立性来做保证。
标签：多个 很多 数据 style 登陆 能力 处理 case 影响
原文地址：https://www.cnblogs.com/Aaron-007/p/9732639.html
