关于自动化测试，你有想过怎么用手工不借助任何工具
发表时间：2023-09-09 10:06:55
文章来源：炫佑科技
浏览次数：242
菏泽炫佑科技
关于自动化测试，你有想过怎么用手工不借助任何工具
*近，我要为我的新公司准备一个自动化测试培训。 得知要做自动化测试培训后，我画了一张图，很神奇：
这些是我能想到的关于自动化测试的一些要点，然后根据我三年前写的一篇关于自动化测试的文章进行更新。 当然，遗憾的是，到目前为止，我接触过的成功的敏捷开发项目还是很少的。 尽管敏捷近年来非常流行，但很少。 敏捷自动化测试只有一次不太成功的经验，因此我在本文中避免了这方面：
1.什么是自动化测试？
用程序测试程序，用代码代替思考，用运行脚本代替手动测试。 自动化测试涵盖：功能（黑盒）自动化测试、功能（白盒）自动化测试、性能测试、压力测试、GUI（用户）测试、安全测试等。
关于什么是自动化，我查了一些资料，但没有权威、规范的解释。 以下内容摘自维基百科：
在 中，测试是使用（从存在）到测试和测试的使用。测试可以将某些任务放在适当的位置，或者添加到。
首先，测试和测试是有区别的。 测试自动化涵盖了更广泛的领域。 本文介绍自动化测试，这里我们暂时混淆这两个概念。
这段话翻译成英文并不难。 你可以自己翻译一下。 我眼中的几个要点：
我说一下我自己的理解：
自动化测试是测试思维的延伸，为测试工程师提供了“触手”。 它的行为可以看作是一种工具，但本质上，自动化测试仍然是一种思想。
顺便说一句，狭义的自动化测试是指基于GUI的自动化测试，以及单元测试和API测试。 您是否想过如何在不使用任何工具的情况下手动完成？ 所以它们很自然地属于测试自动化的范畴。
2、自动化测试的优点
回归测试更加方便可靠； 可以快速高效地运行越来越繁琐的测试； 它可以执行一些手动很难或无法执行的测试，例如大量并发用户； 能够更好地利用资源自动化软件开发，并具有一致性和可重复性的特点，自动化测试脚本完全可重用； 它提高了软件的可信度； 可以在多种环境下进行测试等。
自动化*真正的优势是很容易找到工作：一位测试工程师（不是我自己）发现了一个有趣的现象。 她申请过的几乎所有测试职位在招聘时都要求有自动化测试经验。 但当她开始工作后，她发现这些公司都在尝试自动化测试，但大部分效果都不好。 不过，虽然她只参加了杯子项目，但她总能把这些杯子包装成洗涤用具，以备下次采访。
那么，既然自动化测试有如此多的优势，为什么还有那么多项目失败呢？
我个人有一个结论：自动化测试的优点是自动化测试成功完成后得到的结论，而自动化测试的缺点则是建立自动化项目的基础。
另一个优点：自动化测试可以将产品知识固化到脚本中，减少测试人员流动对项目的影响。 但这个优势的前提是这些脚本易于维护，这就需要一些必要的文档，这是另一个话题了。
3. 自动化测试不能做什么以及它的缺点
它永远无法完全取代手动测试。 自动化测试无法达到手动测试的覆盖率。 并不是每个测试用例都适合自动化，比如提示页面布局是否正确、安装测试、文档测试、兼容性测试、恢复性测试等。
手动测试发现的缺陷比自动化测试多得多。 自动化测试几乎不可能发现新的缺陷。 它*大的用途是回归，以确保以前的错误不会在新版本中再次出现。
自动化测试工具已经死了，它没有任何想象空间。 自动化测试的质量完全取决于测试工程师。
成本高，风险也高。 对测试人员的技术要求很高，对测试工具的要求也很高。
关于成本，包括资金预算、人力资源、人员培训、硬件资源等。下图是自动化测试的投资成本与时间的关系。 显然，大多数时候，成本是非常高的。
基于以上缺点，虽然我作为一名自动化测试工程师被“看重”，但我大部分时间都在说服我的老板，“亲爱的，你能不做自动化吗？” 这是一个多么悲伤的故事。
4.适合引入自动化
项目周期长，系统版本恒定，需求变化不频繁。 这个时候就适合引入自动化测试。
系统的测试对象基本上都能正常识别，对于无法识别的控件能否提供解决方案。
系统中不存在大量无法识别的第三方控件。
需要反复进行测试，比如可靠性测试、回归测试等，需要进行上千次的系统测试。
5、不适合自动化
项目周期短，需求变化频繁。 即使是周期长的项目，如果需求变化频繁，也不适合自动化。
当软件版本尚未稳定，有可能主要功能或大量功能发生改变时，不适合自动化。
没有明确的项目测试自动化计划、措施和管理。
大多数对象无法识别，脚本维护频繁且困难。 无论哪种方式，自动化都注定会失败。
6. 自动化测试流程
自动化的合理切入点：通常，一个项目只有经过完整的系统测试后，才具备引入测试自动化的基本条件。
个人观点：无论哪种检测，越早干预关于自动化测试，你有想过怎么用手工不借助任何工具，越有利于降低成本、降低风险。 随着新的开发模式的兴起，自动化测试也具备了早期介入的条件。 例如，在敏捷开发中，当某个核心模块的核心功能完成后，就可以对该模块的该功能开始自动化测试。
测试自动化分析：
（一）可行性分析
(2)抽样演示分析。 Demo一般会选择冒烟测试用例来检查脚本是否能够成功运行，以及是否所有设计的测试点都被执行。
(3)测试需求分析，分析哪些功能点准备自动化
(1)可行性分析是自动化测试*重要的部分之一。 可行性分析是自动化测试*重要的部分之一。 可行性分析是自动化测试*重要的部分之一。 重要的话要说三遍。
关于可行性分析，请参见第2、3、4、5点； 你的一个错误决定（启动自动化测试项目）可能会给几个人带来全职工作机会。 从这个角度来说，也能促进鸡的发育。 放屁==
（2） Demo主要是用来验证你的工具是否可以使用。
(3)自动化测试不是100%测试，不可能达到手动测试的覆盖率。 自动化测试必须筛选功能点。
测试计划定制：自动化测试计划越全面，后期实施就越有纪律，自动化测试的成功率就越高。
计划跟不上变化，有时过于全面也未必是好事。
自动化测试设计阶段：主要分为自动化测试框架和自动化测试用例。
（1）自动化测试框架的设计、开发和搭建：应能保证测试的分布式执行、脚本模块化、数据驱动、日志分析、错误截图、报告回收、共享对象库、公共函数库、环境配置、和统一设计 用于模式、异常处理和场景恢复的无人值守、每个项目的测试框架
关于为什么需要自动化测试框架，我有另一篇文章详细解释过，这里不再重复。
那我就顺便说一下找对象的事吧。 自动化测试框架正在寻找对象，而不是我:)
通常每个框架都应该支持两种查找对象的方法：动态和静态。 静态搜索涉及到对象库，包括对象库的读、写、合并、维护等一系列问题。 这些可以留给框架；
关于动态搜索，我举一个RFT的例子方便大家理解：
中的两种类型的 find API：
寻找（）。
寻找（ ， ）。
可以是()或()或()。
：一个或多个必须是 的子级。
：一个或多个可以是
：要匹配的列表。 适用于 、 和 。
: 限制了 . 如果设置为 true，则 for 将适用于那些为 的测试，非测试也为 。
首先，测试工具将提供动态搜索的接口或方法。 RFT提供了find方法。 通过调用这些接口或方法可以实现动态搜索。
动态搜索的优点是可以使用“相对路径”来定位对象，而相对的，对象库使用“绝对路径”。 如果对象的某些属性发生变化，静态搜索方法可能无法找到该对象。 当然，如今的自动化测试越来越智能化，已经可以选择匹配度*高的对象并返回。 动态搜索的另一个优点是它找到的对象是“代码”。 您可以在框架中进一步处理这些对象，对象库中的每个对象都是一个独立的对象。 您可以使用它们，但很难更改它们。
通常，当前的自动化测试框架采用动态和静态相结合的方法，即两种查找对象的方法都考虑在内，因为一般来说，静态查找方法更快、更高效。 但静态搜索带来的问题也很大，主要集中在对象的维护、管理和合并，如何共享对象，避免重复添加对象。 此时，规范对象命名就很重要了。 在我过去做过的自动化测试项目中，这些都是陷阱。
（2）自动化测试用例设计的三步：从头开始创建手动测试用例，然后根据手动测试用例编写自动化测试用例。 首先，过滤手动测试用例。 然后转换手动测试用例，*后添加和补充自动化测试用例。
为什么自动化测试用例不能完全被手动测试用例替代？
自动化测试用例的范围往往是核心业务流程或者重复执行率较高的流程，自动化测试的覆盖范围无法达到手动测试的覆盖范围。 自动化测试的用例选择一般是基于正向的，同时也有很多反向的情况。 不过，自动化测试并不是会涵盖所有的逆向情况，而是只会选择选定的部分。 并非所有手动测试用例都可以用于自动化，例如页面布局检查。 手动测试不需要回源，但自动化测试往往是必要的。 自动化测试用例与手动测试用例的不同之处在于，不需要为每个步骤编写预期结果。
通常在做自动化测试的时候，我会写一个测试用例，叫做shake-down test。 该测试用例将遍历系统中所有已填写的表单，仅执行一次操作来确保某个页面是否可用。
在每次回归测试之前，可以先运行一次安定测试，可以快速确定是哪些功能，相当于对整个系统做了一次冒烟测试。
测试脚本设计和开发：
测试脚本大致可以分为：
(1)线性脚本：通过录制直接生成的线性可执行脚本
(2)结构化脚本：具有序列、循环、分支等结构的脚本。
（3）可共享脚本：可以被多个测试用例使用并被其他脚本调用的脚本（即模块化脚本）
（4）数据驱动脚本：将测试数据与业务流程控制分离的脚本，以及通过读取数据文件来驱动流程的脚本
(5)关键字驱动脚本：脚本、数据、业务分离。 数据和关键字在不同的数据表中，关键字用于驱动测试业务逻辑。 关键字驱动的特点是它更像是描述一个测试用例做了什么而不是如何做。
(6) 混合文字：以上任意两种或两种以上
（7）敏捷自动化测试脚本/框架：等我有成功经验后再补充这个=。 =
自动执行测试：
(1)无人值守测试：环境搭建、部署和配置； 自动化测试用例和测试脚本相互绑定； 自动化测试用例执行顺序的安排与组合
(2)异常处理和场景恢复
提交自动化测试产品：一般需要提交执行状态、测试结果、分析报告、测试报告、质量状态等。
测试脚本维护：严格来说，测试脚本维护是在每个阶段进行的。 一个不值得维护的自动化测试项目就不值得建立。
如果你
①从事功能测试并想进阶自动化测试
②在测试行业工作了一两年，我还是不会编码。
③采访各大厂商却屡屡碰壁
我推荐一个群！加油~~测试员，（Q群里有技术高手交流分享，学习资源的价值取决于你的行动，不要当“收藏家”）以获得更多技术和面试材料来自大制造商。
