从功能测试到自动化测试你都知道他们的有缺点吗？

一、手工测试优点

1. 测试人员的经验可以继承，对错误有猜测能力
2. 测试人员有审美能力和心理体验
3. 测试人员有逻辑推断能力

二、自动化的优点

1. 自动化测试执行可以替代大量的手工机械重复性操作，测试工程师可以把更多的时间花在更全面的用例设计和新功能的测试上。
2. 自动化测试可以大幅提升回归测试的效率，非常适合敏捷开发过程（事实上自动化测试主要是用于发现回归缺陷）。
3. 自动化测试可以更好的利用无人值守时间去更频繁的执行测试，特别适合在非工作时间执行测试，工作时间分析失败用例的工作模式。
4. 自动化测试可以高效实现，某些手工测试无法完成或者代价巨大的测试类型，比如关键业务 7×24 小时持续运行的系统稳定性测试和高并发场景的压力测试。
5. 自动化测试还可以保持每次测试执行的操作以及验证的一致性和可重复性。避免人为的遗漏或疏忽。

综述：提高测试效率，提高测试覆盖率，提高测试的一致性和更快的反馈测试结果。

三、自动化测试的缺点

• 永远不可能代替手工测试：自动化脚本无法做到手工测试的覆盖率，不是每个测试用例都适合转换成自动化测试用例。复杂性极强的操作也只能通过手工测试来完成，如果写成代码的话会是件大麻烦事，得不偿失。比如验证当前页面的布局是否正确。
• 无法完全保证测试的正确性：自动化测试是由脚本组成的，它的核心任然是代码。简单来说，自动化测试就是程序测试程序，是程序就会有缺陷，所以不能保证测试工程师开发的脚本就一定没有缺陷，如果代码有 一个小小的逻辑错误，哪怕是一个条件判断的误写也会导致测试结果完全出错，当然对于自动化测试工程师来说，大多数的错误还是会在脚本调试中避免的。
• 手工测试发现的缺陷远比自动化测试的多：自动化测试几乎是无法发现新缺陷，大多是用来发现曾经发现过的缺陷在每个新版本下有没有重新出现。自动化测试更适合缺陷预防，而不是发现更多缺陷，自动化测试最大的用途就是回归。
• 对测试质量的依赖性极大：自动化测试的运行，首先是建立在手工测试质量稳定的大条件下，如果当前版本测试的质量不够稳定，运行自动化测试会非常不顺利，几乎是一种无用功白白浪费时间的行为。
• 测试自动化可能会制约软件发展：由于自动化测试比手工测试更脆弱，以及脚本维护受到限制，从而制约软件的开发。
• 自动化工具死板问题：自动化测试无法做到像人类一样随心所欲的创造，自动化测试好坏完全取决于测试负责人和测试开发工程师的思想与技术，和自动化测试工具没有任何关系，所有程序都是依靠输入代码的方式来告诉工具该怎么做。
• 成本投入高，风险大：自动化测试需要很大的成本投入，并且没有良好的成本分析与控制手段以及自动化测试计划，与执行过程控制，那么往往会导致自动化测试项目失败。白白浪费人力物力，还得不到任何回报。
• 自动化测试要求相对较高：自动化测试工程师要有一定的开发背景，开发技术越高，脚本质量也就越高，越具有想象力

四、什么样的项目适合自动化？

第一，需求稳定，不会频繁变更。

 

自动化测试最怕的就是需求不稳定，过高的需求变更频率会导致自动化测试用例的维护成本直线上升。刚刚开发完成并调试通过的用例可能因为界面变化，或者是业务流程变化，不得不重新开发调试。所以自动化测试更适用于需求相对稳定的软件项目。

第二，研发和维护周期长，需要频繁执行回归测试。

1.在我看来，软件产品比软件项目更适合做自动化测试。

首先，软件产品的生命周期一般都比较长，通常会有多个版本陆续发布，每次版本发布都会有大量的回归测试需求。

同时，软件产品预留给自动化测试开发的时间也比较充裕，可以和产品一起迭代。

其次，自动化测试用例的执行比高于 1:5，即开发完成的用例至少可以被有效执行 5 次以上时，自动化测试的优势才可以被更好地体现。

2.对于软件项目的自动化测试，就要看项目的具体情况了。

如果短期的一次性项目，就算从技术上讲自动化测试的可行性很高，但从投入产出比（ROI）的角度看并不建议实施自动化，因为千辛万苦开发完成的自动化用例可能执行一两次，项目就结束了。我还遇到过更夸张的情况，自动化测试用例还没开发完，项目都已经要上线了。

所以，对于这种短期的一次性项目，我觉得你应该选择手工探索式测试，以发现缺陷为第一要务。
而对于一些中长期项目，我的建议是：对比较稳定的软件功能进行自动化测试，对变动较大或者需求暂时不明确的功能进行手工测试，最终目标是用 20% 的精力去覆盖 80% 的回归测试。

第三，需要在多种平台上重复运行相同测试的场景。

这样的场景其实有很多，比如：

• 对于 GUI 测试，同样的测试用例需要在多种不同的浏览器上执行；
• 对于移动端应用测试，同样的测试用例需要在多个不同的 Android 或者 iOS 版本上执行，或者是同样的测试需要在大量不同的移动终端上执行；
• 对于一些企业级软件，如果对于不同的客户有不同的定制版本，各个定制版本的主体功能绝大多数是一致的，可能只有个别功能有轻微差别，测试也是需要覆盖每个定制版本的所有测试；
• 这些都是自动化测试的最佳应用场景，因为单个测试用例都需要被反复执行多次，能够使自动化测试的投资回报率最大化。
   

第四，某些测试项目通过手工测试无法实现，或者手工成本太高。

对于所有的性能和压力测试，很难通过手工方式实现。

比如，某一个项目要求进行一万并发用户的基准性能测试（Benchmark test），难道你真的要找一万个用户按照你的口令来操作被测软件吗？又比如，对于 7×24 小时的稳定性测试，难道你也要找一批用户没日没夜地操作被测软件吗？

这个时候，你就必须借助自动化测试技术了，用机器来模拟大量用户反复操作被测软件的场景。当然对于此类测试是不可能通过 GUI 操作来模拟大量用户行为的。

第五，被测软件的开发较为规范，能够保证系统的可测试性。

从技术上讲，如果要实现稳定的自动化测试，被测软件的开发过程就必须规范。比如，GUI 上的控件命名如果没有任何规则可寻，就会造成 GUI 自动化的控件识别与定位不稳定，从而影响自动化测试的效率。

另外，某些用例的自动化必须要求开发人员在产品中预留可测试性接口，否则后续的自动化会很难开展。

比如，有些用户登录操作，需要图片验证码，如果开发人员没有提供绕开图片验证码的路径，那么自动化测试就必须借助光学字符识别（OCR）技术来对图片验证码进行模式识别，而它的设计初衷是为了防止机器人操作，可想而知 OCR 的识别率会很低，就会直接影响用例的稳定性。

第六，测试人员已经具备一定的编程能力。

如果测试团队的成员没有任何开发编程的基础，那你想要推行自动化测试就会有比较大的阻力。这个阻力会来自于两个方面：

• 前期的学习成本通常会比较大，很难在短期内对实际项目产生实质性的帮助，此时如果管理层对自动化测试没有正确的预期，很可能会叫停自动化测试；
• 测试工程师通常会非常热衷于学习使用自动化测试技术，以至于他们的工作重点会发生错误的偏移，把大量的精力放在自动化测试技术的学习与实践上，而忽略了测试用例的设计，这将直接降低软件整体的质量。

自动化测试是，把人工对软件的测试转化为由机器执行测试行为的一种实践，可以把测试工程师从机械重复的测试工作中解脱出来，将更多的精力放在新功能的测试和更全面的测试用例设计上。

然而自动化测试试一把“双刃剑”，虽然它可以从一定程度上解放测试工程师的劳动力，完成一些人工无法实现的测试，但并不适用于所有的测试场景，如果维护自动化测试的代价高过了节省的测试成本，那么在这样的项目中推进自动化测试就会得不偿失

五、什么样的项目不适合自动化测试

1. 定制型项目，相关测试经验少
2. 周期很短的项目
3. 业务规则复杂的对象
4. 人体感官与易用性测试
5. 不稳定的软件
6. 涉及物理设备的交互

六、你们的自动化测试的实践策略是怎么样的？

        先进行可行性分析，被测系统具备足够的易测试性，比如是否提供了必要的接口，需求稳定，不会频繁变更，研发周期长，需要频繁执行回归测试，软件系统用户界面稳定，变动少。

自动化测试一般都为分层测试，按价值比重从大到下（单元测试，集成和接口自动化测试，用户界面）

七、自动化技术的种类

1. 自动化流程环节来分：自动化测试设计 和 自动化测试执行
2. 自动化测试执行：执行测试用力或脚本自动操作被设备箱及测试环境中周边设备来完成测试步骤和结果的检查。自动判断出测试用例的执行结果的相关技术。
3. 自动化测试设计： 通过某些信息（如系统的模型设计，模型源代码）由生成算法自动的生成测试用例和测试脚本的相关技术。
4. 自动化目的来分：功能自动化和非功能自动化（性能和安全）
    

 八、你们的自动化（用例执行自动化）流程是怎么样的？

1.  制定测试计划（明确测试范围-自动化可行性、分层测试，测试目的-功能、非功能，测试内容-需求，方法，资源人力要求）
2. 评审
3. 分析测试需求（需求转化为测试需求），明确测试点，优先设计项目中相对稳定且相对重要的模块。
4. 设计测试用例
5. 搭建自动化测试框架
6. 编写测试脚本，把具体的测试用例脚本化（包含准备，执行，断言，清理四部分）
7. 执行测试
8. 获得测试结果
9. 跟踪缺陷
10. 持续集成（一个完整的持续集成系统包含：一个自动构建过程，包括自动编译、分发、部署和测试）
     

九、自动化测试的设计原则 

1. 一个脚本是一个完整的场景
2. 一个脚本只验证一个功能点
3. 重点测试功能中的正向逻辑，避免自动化中涉及大量异常逻辑。因为自动化测试脚本对异常逻辑可能引起的系统错误响应的容错性有限。
4. 用例对应的测试脚本应尽可能的互相独立。测试脚本是自动化系统的一部分，其开发同样应贯彻软件工程的高内聚，低耦合的理念。
5. 在整个脚本中只对验证点进行验证，不是每一个步骤都需要验证点。不对整个脚本的每一步都做验证。

十、你在自动化测试中遇到什么问题？

        测试脚本重复代码过多，难以维护。引入 PO 模型，参数化。

        被测平台不稳定，经常导致元素定位失败

 十一、自动化测试的常见使用场景

• 回归测试：通过自动化测试快速验证是否引入新的缺陷，以及旧的缺陷是否修复成功
• 冒烟测试：在手工测试之前先跑一轮自动化测试，保证项目主流程没有问题
• 在需要生成大数据量的时候也可以用自动化测试
• 线上巡检：构建自动化测试每日巡检，用于每日实时监测线上产品主流程的稳定性和可用性
• 固化资产：通过自动化测试可固化测试资产（流程、工具、代码、文档）
• 建立测试与代码的覆盖联系：通过自动化工具能够确定测试用例的覆盖路径，确定测试用例集对程序逻辑流程和控制流程的覆盖

十二、如果让你来从零主导，如何开展自动化测试？

前期准备

1. 评估被测项目是否适合做自动化测试（什么样的项目、团队适合开展自动化测试？）
2. 评估被测项目适合在哪些功能模块做自动化测试（什么样的功能模块适合开展自动化测试？）
3. 确定使用何种测试工具、测试框架
4. 评估开展自动化测试需要哪些资源，包括：人员、机器、时间；
5. 当前可用或是可以申请到的资源
6. 如何在不影响日常测试工作的前提下，开展自动化测试工作

启动自动化测试工作 

1. 确定自动化测试框架的开发原则
2. 搭建自动化测试框架
3. 确定自动化测试用例的编写原则
4. 根据功能测试用例，筛选可转换为自动化测试用例的用例集，评审
5. 编写自动化测试用例
6. 评审自动化测试用例
7. 编写自动化测试脚本
8. 调试自动化测试脚本
9. 运行自动化测试脚本
10. 输出测试结果，将报告发送至同事邮箱

后期工作

1. 完善自动化测试用例
2. 定期根据实际情况，调优自动化测试脚本、框架
3. 集成 CI，定时执行自动化测试脚本，自动发送测试结果到同事邮箱

 

十三、如何挑选自动化测试框架/工具？

根据测试类型进行初步区分

• 接口自动化测试
• UI 自动化测试
• 性能测试

接口自动化测试

• 工具：postman（入门）、jmeter（高级）

• 若需要结合代码更加推荐用 jmeter

• 代码：Python + Requests + 单元测试框架（Unittest、Pytest）、Cypress、HttpRunner、RobotFramework

UI 自动化测试

• app 端：Appium、Airtest、RobotFramework
• 小程序：MiniProgram
• Web 端：Selenium、Cypress、RobotFramework
• Window 端：Cypress（electron 框架的应用）、Airtest

性能测试

• Jmeter（开源，可二次开发）
• Loadrunner（付费）

十四、自动化测试用例覆盖度到什么程度？

一般都会将主流程和优先级最高（使用频率最高）的功能模块的功能测试用例转换为自动化测试用例

感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

  这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取