【软件测试】web自动化测试如何开展合适？自动化测试用例如何设计？资深测试的总结......

前言

首先，还是把web UI自动化的开展思路和大家聊一下吧：
1、通过代码方式实现框架，要么自研，要么直接使用开源；
2、使用开源软件进行工具级别投入使用，少量自己开发，基本无代码；

代码方式
好处：灵活、定制化高、可锻炼人员能力。
问题：需要大家掌握代码，起码达到用例编写级别。

工具方式
好处：对人员能力要求低，基于成熟工具可达到量产的地步。
问题：工具本身可能存在限制，过于依赖工具本身，也可能无法解决某些特殊的问题。
其实，所有工具都是为了一个目标，即：降低人员要求，提高团队效率。

开展UI自动化测试？
1、应该开展UI层面的自动化，但不一定是功能的；
2、如果要做功能级别的UI自动化，前提是API层做的比较好了；
3、我们要结合公司当前现状，发版节奏、需求变化、产品生命周期等等综合因素一起确定。

让自动化测试产生价值：
1、优先挑选稳定少变的模块覆盖；
2、选择重点场景进行覆盖；
3、不要仅按照功能测试用例的步骤实现，而是要按照功能测试用例的一个suite为单位进行实现（设想如果一个用例有10步，你实现了其中6步，你认为覆盖率是60%，其实是0%。。。因为你少了4步，这个用例还是得需要人工执行）；
4、框架设计一定要好，这里面包括几点：用例分层、数据分离、模块公用、元素分离、数据驱动。

最后应该达成的最次效果，应该是这样的：
每天晚上服务器部署后，按照模块+场景执行API测试 → 按照模块+场景执行UI测试 → 进行各项专项测试（当然，2和3的顺序不一定一样），然后大家第二天上班，就可以看报告分析结果了。

接下来说说自动化测试设计用例

用户角度设计自动化
在功能测试的时候我们一般会遵循这个原因，但是自动化测试往往可以实现更强大的功能，所以，我们在设计脚本的时候很容易违背这个原则。

例如，你要获得的数据是用户不可见的，你要判断用例是否成功的信息也是用户不可见的，或者你要模拟的是用户永远不可能做的操作等。

设计简单傻瓜的用例
自动化脚本本来是很傻瓜的。记得有小伙伴问我，百度输入有个自动联想功能，就是在用户输入的过程中自动配置热门搜索的关键词，例如，用户输入“自”，会自动联想“自我评价”，“自行车”等。用继续输入“自动”，会自动联想“自动化”，“自动关机”，“自动档”等。他想定位自动联想下拉列表的某个关键词，这个关键词是百度根据用户搜索热度的变化而变化的。

再如有小伙伴问我，下拉列表功能，我想脚本执行时随机选择某一个选项，那么如何如何去判断随机的结果呢？换句话说，你都不知道你做了什么，怎么去判断做的结果对不对？

所以，我们在设计用例时尽量考虑简单傻瓜的用例，操作步骤简单，预期结果容易判断等。

循序渐进，从简单开始
对于新需要自动化的项目来说，自动化测试的实施是循序渐进的，不要一上来就设计几百条用例，而是逐步的将功能用例转成自动化用例，在转的过程中需要不断的调整测试结构。

然后，再增加稳定的测试用例。然后，再调整测试结构。随着功能的增加你的自动化测试框架也在逐渐稳定，基础测试用例也在增加。一上来就几百条用例，需求的稍微变化，用例就可能大调整，那么你很可能每天疲惫于用例的维护。

所以，在开始自动化的时候，你可以只对登录功能写个十来条的自动化用例。从而，渐渐的考虑将更多功能自动化起来。

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

目标的坚定是性格中最必要的力量源泉之一，也是成功的利器之一。没有它，天才也会在矛盾无定的迷径中，徒劳无功。

只要完成目标就会成功。期望能够快速的建立起早会的制度，让每个人都会定目标、定计划、行动，这样每个人都会有成功感。

小点，简单点，现实点。这样就不会走得太远了。在你还没有忘了的时候，它已经是过去世了。新的目标已上路了。