软件测试自动化

很多朋友对于软件测试自动化和如果只想学*软件测试的一方面，是学*性能测试还是自动化测试不太懂，今天就由小编来为大家分享，希望可以帮助到大家，下面一起来看看吧！

本文目录

1. 如果只想学*软件测试的一方面，是学*性能测试还是自动化测试
2. 软件测试目前在一线城市的大互联网公司能做到一个团队完全自动化测试吗

如果只想学*软件测试的一方面，是学*性能测试还是自动化测试

要想不失业，都得会！

在实际工作中，没有只会性能测试，也没有只会自动化测试的，对于一个测试专家的要求来说，从技术上看，性能测试和自动化测试时必须都掌握的。但是如果要从专一项的角度考虑，二者的侧重点还是有所不同：

性能测试除了基本压测工具的使用，比如jmeter，loadrunner这些，往往需要对开源工具做扩展或者二次开发。而且性能测试，不仅仅是测试，还需要对系统的性能瓶颈进行分析，这个时候，先从测试用例的设计角度上来讲，需要对系统架构有所了解；当测试结果出来之后，又能对测试报告反应的性能瓶颈进行分析，比如是IO，还是CPU，还是networking等等，这些就更加涉及到一些底层的知识了；再往上，大型分布式系统的链路压测，又涉及到动态加压、监控、扩容等，要求会更高一些。而越往上，所涉及到的开发知识并不比一般的开发少。

自动化测试的角度来看，初中级的定位在能写UI自动化测试脚本，包括不限于web、h5、app、desktop这些；能写接口自动化测试脚本；再往上，能写自动化测试框架；再深入发展，测试平台的搭建，质量保障工具的开发，此时也开始涉及到不少开发知识了。

所以，从整条路径来看，测试发展到最后，必不可少计算机专业知识和深入的开发技能。但是如果从初中级的角度考虑，需要取决于个人的学*和技术能力，如果本身对开发就兴趣不大，我的建议就是专注业务测试，加上初中级的性能测试和自动化测试要求即可，把自己培养成业务专家。如果开发技术比较好，从事自动化测试要更好一些。

软件测试目前在一线城市的大互联网公司能做到一个团队完全自动化测试吗

完全自动化是指的100%覆盖？100%覆盖所有测试点？如果是，那么可以讲这不是能不能做到的问题，而是需不需要，有没有必要的问题。

同时，这里提到了地域的问题，由于各地域IT行业发展、应用的程度不同，相应的测试开发技术确实存在一定程度的差距，但这个问题和地域之间不存在直接关系。

首先，需要明确下关于自动化基本的认知:

常见的错误认知：

使用自动化完全替代手工测试。使用自动化测试发现更多的新BUG。

应该形成怎样的认知：

自动化测试的目的不单纯是为了减少或者替代手工测试，而是为了测试人员能够做更多更有意义的测试（也包含手工测试）。自动化测试是用来验证以前能够正常工作的功能是否依旧可以正常工作。接下来我们讨论下完全自动化测试的必要性

首先并不是什么条件下都可以开展自动化

通常需要同时满足以下条件：

软件需求变动不频繁(超过10%的变动是频繁变动，当然10%不是一个定值)项目周期足够长自动化测试用例可重复使用

其次针对不同的业务特点选择合适的自动化类型和框架

比如，被测对象采用前后端分离的架构设计，但界面有时会做根据用户需求做调整，此时该选择怎么做？在这种背景下，选择UI、接口自动化似乎都可行，但这里我更倾向于选择接口自动化，然后通过手工或者其他工具简单覆盖页面展示是否OK。

再比如，被测对象包含复杂的业务逻辑，如某审批流程业务，涉及不同审批流程环节和审批用户角色。这时会怎么选择？这里我更倾向于选择基于关键字驱动测试框架的接口测试。

等等，之所以会有结合不同被测对象特点，选择合适测试类型和框架，一是考虑到自动化的投入产出比、二是考虑到自动化测试的可持续性。

投入产出比不仅体现在开发成本，更重要的是维护成本。一个难维护、维护量大、难扩展的自动化，是很难持续的开展下去的。

测试用例中包含了很多类型的测试，比如功能测试、可靠性测试、性能测试等等。仅仅是功能性、可靠性的覆盖也将是一笔巨大的投入，所以我们会看到很多公司会选择只覆盖正向用例，应用于回归测试的迭代场景里，反向用例和异常测试用例一般不覆盖（根据团队人力情况而定，但不会完全覆盖）。团队当然不想看到，通过自动化测试提高效率节省的时间，用来维护自动化用例。

文章到此结束，如果本次分享的软件测试自动化和如果只想学*软件测试的一方面，是学*性能测试还是自动化测试的问题解决了您的问题，那么我们由衷的感到高兴！