本文目录

• 自动化测试基本流程是什么
• 什么是自动化测试
• jmete怎么写自动化测试脚本
• 自动化测试的分类有哪些
• 软件开发各个阶段可以实施的自动化测试技术有哪些
• 关于软件测试行业，未来发展方向是否是自动化测试，非自动化测试是否会逐渐消失
• 自动化测试写的用例怎样让其在执行失败的时候自动重跑1次或多次呢

自动化测试基本流程是什么

自动化测试基本流程

1、制定测试计划

在展开自动化测试之前，最好做个测试计划，明确测试对象、测试目的、测试的项目内容、测试的方法、测试的进度要求，并确保测试所需的人力、硬件、数据等资源都准备充分。制定好测试计划后，下发给用例设计者。

2、分析测试需求

用例设计者根据测试计划和需求说明书，分析测试需求，设计测试需求树，以便用例设计时能够覆盖所有的需求点。一般来讲，基于Web功能测试需要覆盖一下几个方面：

1）页面链接测试，确保各个链接正常；

2）页面控件测试，确保各个控件可靠；

3）页面功能测试，确保各项操作正常；

4）数据处理测试，确保数据显示准确、处理精确可靠；

5）模块业务逻辑测试，确保各个业务流程畅通。

3、设计测试用例

通过分析测试需求，设计出能够覆盖所有需求点的测试用例，形成专门的测试用例文档。由于不是所有的测试用例都能用自动化来执行，所以需要将能够执行自动化测试的用例汇总成自动化测试用例。必要时，要将登陆系统的用户、密码、产品、客户等参数信息独立出来形成测试数据，便于脚本开发。

4、搭建测试环境

自动化测试人员在用例设计工作开展的同时即可着手搭建测试环境。因为自动化测试的脚本编写需要录制页面控件，添加对象。测试环境的搭建，包括被测系统的部署、测试硬件的调用、测试工具的安装和设置、网络环境的布置等。

5、编写测试脚本

根据自动化测试用例和问题的难易程度，采取适当的脚本开发方法编写测试较薄。一般先通过录制的方式获取测试所需要的页面控件，然后再用结构化语句控制脚本的执行，插入检查点和异常判定反馈语句，将公共普遍的功能独立成共享脚本，必要时对数据惊醒参数化。当然还可以用其他高级功能脚本。脚本编写好了之后，需要反复执行，不断调试，知道运行正常为止。脚本的编写和命名要符合管理规范，以便统一管理和维护。

6、分析测试结果、记录测试问题

应该及时分析自动化测试结果，建议测试人员每天抽出一定时间，对自动化测试结果进行分析，以便尽早地发现缺陷。如果采用开源自动化测试工具，建议对其进行二次开发，以便与测试部门选定的缺陷管理工具紧密结合。理想情况下，自动化测试案例运行失败后，自动化测试平台就会自动上报一个缺陷。测试人员只需每天抽出一地你该时间，确认这些自动上报的缺陷，是否是真实的系统缺陷。如果是系统缺陷就提交开发人员修复，如果不是系统缺陷，就检查自动化测试脚本或者测试环境。

7、跟踪测试BUG

测试记录的BUG要记录到缺陷管理工具中去，以便定期跟踪处理。开发人员修复后，需要对此问题执行回归测试，就是重复执行一次该问题对应的较薄，执行通过则关闭，否则继续修改。如果问题的修改方案与客户达成一致，但与原来的需求有所偏离，那么在回归测试前，还需要对脚本进行必要的修改和调试。

8、自动化脚本的维护

如果系统发生变更时，对自动化测试脚本和相关文档包括《自动化测试用例》、《自动化脚本设计说明书》进行维护，以适应变更后的系统。

什么是自动化测试

原文

首先我们从招聘岗位需求说起。看近期的职业机会，提到“软件测试工程师”，基本上都有关于自动化测试的要求。例如：

• 了解 selenium、appium或者其他自动化测试框架；

• 至少熟悉一门面向对象开发语言，有一定的代码功底优先；

• 熟悉Java或者python，有一定的测试自动化经验和代码阅读能力；

• 了解接口集成测试，会使用JMeter、Postman、SoapUI等接口测试工具；

等等，上述内容不再一一列举。突然自动化测试遍地开花，好像测试工程师的自动化测试能力成为了标配一般。本文就从自动化测试的要求入手，简单的进行自动化测试扫盲，争取让各位在一分钟之内了解自动化测试。

那么我们就从“自动化测试”五个字来剖析。

一、测试

测试：这个我们熟悉。最经典的一个解释“ 程序测试是为了发现错误而执行的过程。”这个来自于G.J.Myers的经典著作《软件测试的艺术》的定义，给我们展示了测试的本质： 过程。

测试是为了发现软件的错误，而执行的过程，这个过程可以是以下内容：

• 运行被测试的软件，执行软件的功能；

• 运行其他工具，去检查软件的内部和外部。

总而言之，是一个过程，执行的过程。接下来就一张最常见的测试示意图：

请点击输入图片描述

确认过眼神的手工测试

比如：测试主管让测试工程师去把软件的所有功能遍历一遍，该测试工程师通过鼠标、键盘、麦克风、手机屏幕触控等，把软件所有的功能，全部遍历了，这个叫做什么？熟悉测试的童鞋明白，这就是传说的“手工目测”呀，这是“人肉测试”。

我们好好的画这张图，实际上是这样的。

好吧，手工测试

二、自动化

到这里，结合上面的说法，自动化测试就是让被测试的软件自己运行起来，执行软件的功能；或者就是让其他的工具自己运行起来，去检查软件的内部和外部。

既然测试是一个过程，那么自动化测试，就是自动的执行的过程。

接下来我们探讨的一个核心的问题：自动。什么叫做自动呢？让机器自己动，就是自动。让机器按照人类的要求，把软件的所有功能遍历一遍，这是自动化。。这样说会不会清晰一点？

重点来了，机器。让机器去动，这可不是“吃鸡”哦，这是人类命令机器去操作。不知道童鞋们有没有思考过，机器怎么知道人类的要求？上面的例子，测试主管只要告诉测试工程师，命令传达就完成了。可是人类直接的沟通，远比人机沟通容易啊。

• 首先，机器听不懂“人话”，无论中文，英文……

• 其次，机器默认会的“汇编语言”，应该是绝大部分的童鞋不会，并且短期掌握不来吧。

• 好吧，用“编程语言”。是时候拿出我们的另一张图了：

这个厉害了吧，自动化测试

机器学习一个编程语言，轻松和简单到令人发指的地步：安装上去，机器就学会了。好在人类学习编程语言也不是特别难的的事情。看来这个可行。

有了编程语言，就有了人机交流的桥梁，剩下的事情，是帮机器挑选工具。做对应的测试，就需要找到对应的工具，这样自动化就自动起来了。能到这里，我希望各位童鞋了解了基本的“自动”原理。

同样，好好的画这张自动化测试的示意图：

这个呢？自动化测试示意图

jmete怎么写自动化测试脚本

　　把Jmeter配置成一个Web代理，用Jmter自己来录制脚本　　第一步： 创建一个Thread Group (邮件点击： Test Plan -》 Add -》 Thread Group)　　第二步： 创建　　应该设置下忽略这些没用的请求

自动化测试的分类有哪些

在敏捷开发流程中，自动化测试涉及到下面重要四种类型的测试。单元测试（UnitTest，UT）关注某一个函数，模块的正确性，一般需要开发人员编写相关的测试代码来进行自动化测试。可以使用对应的测试驱动开发（TDD）框架，如：Java的JUnit和TestNG等，相应的python语言中有unittest和nose等测试工具。集成测试（IntegrationTest，IT）集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。这个阶段，可以尝试接口的自动化测试，同样可以利用单元测试的框架编写针对API调用的测试代码。另外也可以利用selenium和appium等测试工具来进行UI相关的测试。用户验收测试（UserAcceptanceTest，UAT）用户验收测试，也叫用户可接受测试，一般在项目流程的最后阶段，这时相关的产品经理、业务人员、用户或测试人员根据测试计划和结果对系统进行测试和验收，来决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。本阶段主要是UI相关的测试，编写自动化测试脚本的难度比较大。同样是利用selenium和appium等测试工具来编写测试脚本回归测试（RegressionTest）回归测试是软件测试的一种，旨在检验软件原有功能在修改后是否保持完整。回归测试主要是以检查退化为目的的测试。退化主要指由于系统的版本更新，在之前的版本中正常运行的功能变得无法正常运行，或者紧急修正了某个问题，但引发了其他的问题的现象。从开发人员视角出发的单元测试是需要进行回归的，还有从用户视角出发的集成测试和用户验收测试的测试用例集也是回归测试的相关内容。

软件开发各个阶段可以实施的自动化测试技术有哪些

1. 单元测试自动化, 包含: 用例代码自动化生成, 测试数据生成, 被测代码的静态分析, 测试覆盖率统计等2. 接口自动化测试, 包含: 测试数据的生成, 调用参数并发起请求, 验证请求返回的结果等3. 基于页面的GUI自动化测试, 包含: 根据不同平台和业务场景, 选择合适的自动化框架和测试执行框架等更多实战小技巧可以到网络上找下黑马程序员相关视频。很高兴我的回答能对您有所帮助，谢谢您的采纳

关于软件测试行业，未来发展方向是否是自动化测试，非自动化测试是否会逐渐消失

产生这种疑问的原因，可能也是感受到传统手工测试在自动化等测试技术面前所面临的竞争压力。

非自动化测试手段不会消失，但其比重和测试内容会有较为明显的降低和改变。

首先随着市场、产品迭代对测试效率、测试成本、测试深度和广度等要求的提高，以及测试技术发展、应用，将会不断的驱动通过测试技术取代重复、单一的手工测试操作。

其次非自动化测试的内容改变，也会由传统的纯手动改变为更精细化的测试，结合测试深度及广度更全面的进行测试分析和设计，更关注影响产品质量背后的其他因素——用户体验、支撑数据。

同时也能够看的出来，这对测试人员的要求由原来的 软件测试 逐渐过度到 测试开发。

自动化测试写的用例怎样让其在执行失败的时候自动重跑1次或多次呢

自动化测试用例失败重跑有助于提高自动化用例的稳定性，那我们来看一下，python和java生态里都有哪些具体做法？下面是我的一些实践过的还有了解到的一些内容，

怎么做

• 如果我们是在python生态里，用pytest做测试驱动，那么可以通过pytest的插件pytest-rerunfailures来实现失败用例重跑，具体的使用方式有两种，一种是通过命令行指定pytest --reruns 2 --reruns-delay 1，reruns表示重复运行次数，reruns-delay 表示重复运行是的延迟时间。另一种方式是通过@pytest.mark.flaky(reruns=2, reruns_delay=1)，这种方式一般运用，不想全局所有的测试用例都重跑，只是特定的测试用例需要跑，那就在特定的测试方法上使用这个标记。

• 如果我们是在java生态里，用junit做测试驱动，junit5提供了注解@RepeatTest(2)，可以试下测试类或者测试方法的重复运行，也可以自定义，通过实现个TestRule接口，来控制测试用例的运行。还有就是如果使用到了maven可以添加一个rerunFailingTestsCount参数，不过这个是控制所有的用例了。

为什么要让失败用例重跑呢

因为自动化一般都会在测试环境或者其他非线上的环境，由于环境的不稳定可能会导致测试用例莫名其妙的失败，是用例的稳定性大打折扣。这个时候加入失败重跑机制，能够在一定范围内提高测试用例的稳定性，做出更多的产出。

什么样的自动化用例要进行失败重跑

接口自动化测试用例我建议加入这种失败重跑，而对于UI接口接口自动化，失败重跑的话，我觉得意义不大，因为往往当用例的失败的时候，要么是由于界面元素没加载出来，要么是用例的逻辑有问题，要么是意外的弹窗影响，这个时候应该让错误尽早的抛出来，好尽快的修复，而不是在哪儿一个劲的重试，没啥用。UI自动化应该做好显式和隐式等待，这个是提升稳定的关键。

什么样的失败用例应该重跑

在测试框架中，最好能区分出什么样的异常时服务异常，什么是测试框架本身的异常，对于服务异常可以适当重试，对于框架异常不进行重跑，直接抛出。断言失败当然更不需要重跑。所以在控制测试用例执行的时候，不要一股脑儿的全都重跑，有选择性的，既要保证稳定性，还要保证效率，让自动化发挥价值。

总结

我们在做测试的时候，要做到有的放矢，在合适的时候做合适的事情，自动化测试的价值就是因为它能快速的实现回归测试，能够快速的反应系统是否正常，如果因为重试导致运行的时间成倍增加，是没有任何意义的，还不如抛出错了，尽快去解决。而且自动化测试用例的运行顺序也要控制，处于业务前方的接口尽量先跑，处于业务后方的接口尽量后跑。比如登陆接口和下单接口，登陆接口属于业务靠前的，下单是靠后的，一般在测试下单接口的时候都要初始化登陆状态，这个时候会调用登陆接口，在测试用例批量执行的时候，可以先让登陆接口测试用例先跑，如果这个接口有问题，那么其他需要登陆接口配合的用例全都会失败，那这样后面的用例就不用跑了，这样会节省很多的时间。