A. 前端UI自动化puppeteer实践
背景
在表单（web页面）测试过程中，要经常对表单基本功能进行回归，曾经考虑过使用webUI自动化工具，减少重复性的操作，但是因为之前用过appium，对UI自动化的体验不是很好，所以有些纠结，但是，再仔细想一下，有可能存在比较好用又确实能提升效率的工具，也不妨去尝试一下。
上网查询了一下，puppeteer具有可以使用录制脚本的工具puppeteer-recorder、截图等功能，找了个demo开始试了一下，发现坑较少，安装方便，使用比较流畅。
puppeteer介绍
Puppeteer 是一个Node库， 它提供高级API，通过DevTools Protocol 来控制Chrome 或 Chromium。 Puppeteer 默认运行为headless ，但是可以配置为运行为non-headless。详见文末参考链接。
效果展示
目录结构
cases：用例脚本
config：配置文件，可区分测试、线上环境
screenshot_outputs：输出的截图文件
utils：用到的通用方法
测试思路
1、在脚本中写入测试执行步骤
2、运行脚本
3、查看执行结果（截图），查看是否符合预期。
这样操作会使简单很测试很多。就拿表单人工审核为例，全部人工操作的话，需要填写并提交表单，登录表单运营后台，找到对应的目录及表单，对表单进行审核，再重新打开表单并进行查看，而自动化的话，在写好脚本（在脚本中可进行接口请求）之后，就可以直接运行脚本，查看结果。
环境搭建
1、安装puppeteer：npm install puppeteer（前提是安装了node、npm）
2、安装chrome插件puppeteer-recorder（可自行网络，比较简单）
3、npm init，初始化一个项目
脚本编写
遇到问题
1、puppeteer-recorder只能录制获取元素、点击元素操作，没有获取到填写文本的操作，需要修改或添加已录制好的脚本
2、有些地方例如截图前，接口请求结束后，需要使用等待方法。await page.waitFor(3000)
3、使用await进行接口请求，不然会出现同步异步问题，后面的语句开始执行（但是要用到的参数还没有获取到）
参考：
https://zhuanlan.hu.com/p/76237595
https://www.jianshu.com/p/679f07ba474b
B. 什么是"前端工程化"
前端工程化是指使用软件工程的技术和方法来进行前端的开发流程、技术、工具、经验等规范化、标准化。其主要目的为了提高效率和降低成本，即提高开发过程中的开发效率，减少不必要的重复工作时间。
前端工程化是前端架构中重要的一环，主要就是为了解决上述大部分问题的。而前端工程本质上是软件工程的一种，因此我们应该从软件工程的角度来研究前端工程。
前端工程化有四个特点：模块化、组件化、自动化、规范化。
1、模块化：
就是将一个大文件拆分成相互依赖的小文件，再进行统一的拼装和加载。只有这样，才有多人协助的可能。在工程化之前，一直是使用js、jquery、ajax，这没有模块概念，对于开发大型且复杂的系统会有一定的限制。
2、组件化：
组件化≠模块化。模板化只是在文件层面上，对代码和资源的拆分；组件化是在设计层面上，对于UI的拆分。目前市场上的组件化框架最多，主要的有Vue，React，Angular2。
3、自动化：
“简单重复的工作交给机器来做”，自动化也就是有很多自动化工具代替我们来完成，例如持续集成、自动化构建、自动化部署、自动化测试等等。
4、规范化：（至关重要的一环）
在项目规划初期制定的好坏对于后期的开发有一定影响。包括的规范有：
目录结构的制定、编码规范、前后端接口规范、文档规范、组件管理、Git分支管理、Commit描述规范、定期codeReview、视觉图标规范。
(2)前端ui自动化测试扩展阅读：
为什么需要前端工程化：
前端越来越复杂，设计的问题和环节也越来越多，不采用工程化管理，就无法很好的实现团队协同和降低复杂性。 原因如下：
1、前端范畴不断扩大
早期的前端只需要适配桌面浏览器，而现在的前端，需要适配不同类型和尺寸的设备，包括移动端网页，app应用等。
2、前后端分离
早期的前端只是后端 MVC 框架的一层模块， 而现在的前端普遍是从后端接口获取数据，编写处理逻辑，各种前端mvc前端框架也层出不穷。
3、模块化开发的出现
现在的前端开发不再是从零写起，重复造轮子，而是会引用大量内部和外部的组件和模块，这也导致前端必须进行模块管理。
4、转码器的盛行
为了提高效率，前端工程往往不会直接写html,css,和js代码，而是改用其他格式书写，再用工具编译为目标格式。
比如用Jade 写HTML，用less、sass、stylus 编写CSS,用ES6、Typescript编写JavaScript。
5、开发流程和团队
早期的前端团队往往只有几个人，而现在的前端团队可以扩展到几十人，甚至上百人。每个人只负责自己的一块内容。所以，如何协调多人多团队的工作，保证沟通顺畅，保证权限管理，越来越成为一大问题。
前端工程化的具体内容：
1、代码规范: 保证团队所有成员以同样的规范开发代码。
2、分支管理: 不同的开发人员开发不同的功能或组件，按照统一的流程合并到主干。
3、模块管理: 一方面，团队引用的模块应该是规范的;另一方面，必须保证这些模块可以正确的加入到最终编译好的包文件中。
4、自动化测试：为了保证和并进主干的代码达到质量标准，必须有测试，而且测试应该是自动化的，可以回归的；
5、构建：主干更新以后，自动将代码编译为最终的目标格式，并且准备好各种静态资源；
6、部署：将构建好的代码部署到生产环境。
C. 软件测试和前端开发有什么区别
在选择之前可以先分别了解一下这两个方向的主要工作职责是什么。
一、软件测试
字面意思，主要工作是测试软件。发现软件程序中的错误，对软件是否符合设计要求，以及是否能达到技术要求，进行有关验证，以及评估软件的质量。
随着IT类企业的大量增加，从而导致各类人才出现大量缺口，其中软件测试人才更是紧缺。当然，这里说的是严格意义上的软件测试开发工程师。
需要熟练标准规范的测试流程，能够做性能，功能，自动化测试；熟练使用Linux操纵系统，独立搭建测试环境；熟练MySQL、Oracle等数据库的一种或多种；至少掌握Java、Python、C++等一门编程语言。
在蜗牛学苑的教学过程中，不但要教会学员做标准的软件测试，还会教会学员自己开发自动化测试工具。我们会让学员用这些工具来完成一些项目，但是这些工具对我们来说根本不是核心和重点，我们要教会大家的是不依赖于这些工具也可以完成自动化测试，这就牵涉到其背后的底层的工作原理，这些才是我们要学习的重点。
二、Web前端
前端开发是创建Web页面或APP等前端界面呈现给用户的过程。通过HTML、CSS及JavaScript以及衍生出来的各种技术、框架、解决方案，来实现互联网产品的用户界面交互。前端技术变化比较快，需要不断的学习。在终端应用场景不断拓展的当下，前端开发的边界也在不断的拓展，岗位需求的数量也会呈不断上升的趋势。
蜗牛学苑在结合了企业需求、企业技术调研以及目前主流的技术分析和实战后将Web前端课程重磅升级，增加了更多项目实战，框架原理的分析，加强了前后端的实战。不仅要学会怎么用，还要知道是怎么来的。
总之，软件测试和Web前端都是不错的专业，都有充足的上升空间和发展前景。根据你自己的兴趣和擅长的方向来选择吧。
D. 自动化测试和前端哪个好学
前端比较好学一点，前端相对来说适合零基础的人学习，比较好掌握一些。
E. 前后端自动化测试方案
这段时间我探索了点自动化测试方面的技术，探索结果如下
【后端】：任意后端工程 + python 自动化测试脚本（实现接口测试），服务器要求：指令服务器即可（即终端操作系统）
【前端】：任意前端工程 + python 自动化测试脚本（实现UI交互测试），服务器要求：必须是可视化服务器（即有交互界面的系统） （虽然说 phantomjs 可以实现无界面的情况下进行浏览器测试，但是还是不太推荐，毕竟对于前端而言，可视化才最好）
经过探索下来，发现 python 在实现自动化方案确实非常合适，且前后端都可以通过python实现自动化测试，如此一来自动化测试也就可以独立出一个工程，而无需受前后端工程语种、框架等各种不同的影响。只是前端自动化测试比较特殊，需要模拟用户交互，最好是有界面的系统（通过浏览器驱动器调用浏览器实现自动化交互测试），也就是说前后端的自动化测试服务器要么都用一台带交互界面的系统，要么就用2台服务器，一台终端服务器测后台接口，一台交互服务器测前端交互
F. 如何成为一名高级自动化测试工程师
优秀的测试人员可以做的事情可以包括如下3点：
由单纯的测试变成项目质量保证工作
持续集成探索和推动和自动化测试技术研究
测试相关工具的开发
- 1、我们先来讲第一点，由单纯的测试变成项目质量保证工作
- 测试，从狭义的角度来讲，包括如下这些环节：
- 测试计划和测试用例编写－测试执行－质量报告书写
- 测试人员一般会在开发阶段就进行测试计划和测试用例的编写和准备工作；在测试阶段，我们一般先会做功能测试，等项目功能基本稳定，bug较少了，就开始做兼容性测试、性能测试、安全性测试。兼容性测试保证了产品在多浏览器、APP在产品在不同机型下的兼容性；性能测试保证了产品在海量用户大流量下的服务能力；安全测试能发现产品可能会被攻击的各个隐患。做完了这些测试以后，人员发布质量报告，产品上线。
- 不过，优秀的测试人员需要向上游和下游拓展测试的领域，把自己放在“质量保障”的角色上，推动整个项目组一起保证质量，上游的工作包括：
在产品刚立项、进行需求确认的时候，测试人员就会参与进去，仔细地Review需求，看需求是不是完整、有没有漏洞，这个时候中毁拿还没有进入正式开发，修改需求对于项目组来说代价是最少的。在这个环节，测试人员凭借缜密的推演、发散性的思维，往往能发现很多需求的漏洞，提高了项目的整体效率。
另外，测试人员在完成测试计划、测试用例以后，会邀请开发、策划一起来评审测试用例，在这个环节，由于测试人员把每个需求如何细化测试都体现在了用例里面，就相当于再次把需求分析了个透，往往还能发现很多需求的漏洞。这也是提早发现需求漏洞的有效环节。
我们知道，代码的质量归根结底是由开发保证的，测试做的工作，只是发现Bug让开发修复。如果一个花瓶，一开始就是很完美的；另一花瓶经过了各种修补，看起来比较完美，大家觉得哪个花瓶比较好？当然是第一个花瓶。所以，测试人员应该站在质量保障的立场，想办法跟项目组沟通、给开发提供工具，让开发自己把质量保障工作做好。比较可行的一些方式是：提供一些手工用例让开发自测；给一些自动化的接口和UI测试代码让开发自测；部署静态代码检查工具，并推动开发分析和修改发现的问题；有一些做得好的项目已经实现了持续集成，也可以尝试。
- 下游的工作包括：
在产品完成了测试以后，就是发布的环节了，测试人员在发布的环节也能发挥作用，首先，测试人员为了部署测试环境，研究自动化部署的技术，可以把上线部署的环节也自动化，以前需要2个小时的部署环节压缩到半个小时甚至更少，而且更加准确可靠。
如果有些版本修改比较多，上线的质量风险大，测试人员会跟产品一起制定灰度发布的方案并在技术上进行实现，让版本先卖搭面向一小部分用户开放，如果发现Bug了，影响的用户也比较小，Bug改掉以后，再逐渐扩大用户范围。
- 另外，优秀的测试人员还会发动项目组的其他人一起来保证项目质量，比如推动开发进行代码Review；引入冒烟自测流程，让开发先自测以后再提交给测试做冒烟测试；通过在项目组分析Bug，让开发提高自测，降低Bug数量等；引入策划、交互、视觉在测试阶段进行走查，等等各种措施。
- 2、持续集成探索和自动化测试技术研究
- 业界都在说持续集成，那持续集成究竟是个什么鬼呢？
- 持续集成原本的意思是让开发每提交一次代码就自动化测试一次，如果自动化测试发现问题了，测试用例就会失败，开发就会马上发现这个失败，并修改代码。
- 要做到持续集成可有很多工作要做。
首先就是编译环节，要把所有编译的环节都自动化起来，开发每次提交代码都能进行自动编译；
编译完成后，就是静态代码检查的环节，通过静态代码检查的工具检查代码的问题，比如，数据库连接池没有释放，参数不匹配等。
静态代码检查完成后，就是单元测试了，单元测试用例一般是开发人员或者测试人员编写，或者开发和测试合作编写，保证的是余茄开发内部函数的正确性。一个健康的自动化测试方案中，单元测试用例的占比是最高的。
然后就是接口测试，一般保证的是后端开发提供给前端开发的HTTP接口，接口一般也比较稳定，用例比较容易维护，所以，接口测试的自动化占比也可以做到很高。
在接口测试的上层就是针对用户界面的UI测试了，就像测试人员手工执行一样，UI自动化测试能操作页面的元素，完成自动化。不过，由于用户界面常常要重构，所以我们常常会控制UI自动化测试的规模，只覆盖主干的用例。
- 优秀的测试人员可以把自己的工作尽量自动化，并用持续集成框架串起来，提高工作效率和质量。
- 3、测试相关工具的开发
- 优秀的测试人员会开发其他好用、趁手的工具来提高工作效率，比如数据自动生成、报表自动生成、报bug工具等。
- 其实归根结底就是一句话：测试人员最核心的工作就是保障项目的质量，各类测试流程、技术、工具和平台的发展让我们可以更好地保证项目的质量。
G. “自动化测试”是否有必要做自动化测试
目录
一、前言
二、自动化目的
三、自动化分类
四、自动化实现
一、前言
在一些测试交流群经常会看到有小伙伴在问，"怎么做自动化测试？学习自动化测试有什么资料吗？自动化测试是不是很牛逼？" ，甚至有些言论是"不会自动化的测试人员，真的要被淘汰了吗？"
不得不说一堆流量号主抓住大众心理，点进去的必然是卖课广告，或者是关注微信公众号领取测试资料大礼包。
实话实说，我之前也有同样的疑问，甚至带着担忧。每次又不甘心得领着测试资料大礼包......
当然，随着自己的认知不断扩大，自己的一套测试体系建设不断完善，于是这些担忧逐渐的消失。每项技术引用都要看适用场景，是否适合自己的团队，因地制宜才能发挥其最大的价值。
因此，我想通过这篇文章来分享下我对于自动化测试的理解。
二、自动化目的
自动化工作可以节省很多人工操作成本，减少人工重复性操作，提高整个团队的研发效率。但是如果搭建自动化体系需要耗费很长时间，投入很多人力资源，但是用户只要2-3分钟的手动工作就能解决，而且这个操作并不频繁，又或者需要自动化操作的平台变更迭代非常快并且没有规律，自动化工具在后面类似累活的跟着。那么自动化还是有必要吗？
我之前在的团队，造测试数据特别困难，严重影响了整个研发效率，但是当时也没有一个好的解决办法，后来基础研发组做了一个造数平台，这个平台需要自己去配置各种字段，并且梳理出各个表字段的关联，从头到尾一个一个去构建场景，一不小心就配置错误，看着提示你也找不到原因的那种。这给造数过程中又添了一个拦路虎，给本不充裕的测试时间，又耗时一把。
如果能在做执行任务前评估任务的投入和收益，那么是不是就能更加合理的开展这项任务。那么自动化测试的投入和收益是怎样的呢？
投入：通过测试人员借助脚本或者工具实现自动化，维护自动化平台。
收益：提高测试效率，提升测试人员的成长。
自动化测试真的提高测试效率吗？真的可以提升测试人员的成长吗？针对后者，我认为是有的。接下来我们就来聊聊自动化测试是否提高测试效率。
三、自动化分类
自动化一般分为接口自动化和UI自动化，其中UI自动化又分为Web UI自动化和App UI自动化，按照我的理解还应加上部署自动化。
接下来我将针对这四种自动化的场景做一个介绍。因为我对于UI自动化不是很熟悉，我认为投入产出比不是很高，主要还是因为我没咋接触过，所以后面仅做简单介绍，重点讲解接口自动化和部署自动化。
四、自动化实现
4.1、接口自动化
接口
接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递过程，以及系统间的相互逻辑依赖关系等。
流程
填写接口，入参，对出参进行断言，每天定时构建，输出测试报告。
入参覆盖范围：必选，可选，有/无/null，类型，数值大小/数值范围，特殊字符；
出参：json，data；
接口关联：接口之间的依赖，数据传递；
断言：对响应做核验，可以对状态码或者msg做校验。
优点
接口测试可以做到更多的覆盖场景；
接口测试可以更快的发现服务端问题；
接口测试相对容易实现自动化持续集成；
接口测试相对于比单元测试比较贴近业务场景；
技术选型
1、MeterSphere
MeterSphere 是一站式测试平台，涵盖测试跟踪、接口测试、性能测试、 团队协作等功能，全面兼容 JMeter、Postman、Swagger 等开源、主流标准。
MeterSphere是一个功能交全的平台，并且是开源的，对于免费版就足够小团队使用了，使用门槛相对来说较低，对于技术能力要求不高，所以是一个不错的选择。MeterShpre使用的技术栈是SpringBoot+vue，以及一些中间件，也可以在此基础上进行二次开发。
2、Python
通过Python来做接口自动化的话，常用组件有：执行库Requests，断言库unittest，测试报告HTMLTestRunner，通过持续集成Jenkins做定时构建。
框架思想：封装，数据驱动。
使用Python的话则需要掌握一定的代码能力，当然这个对个人技能的提升是很有帮助的，但是如果在时间比较紧迫的并且没有足够的技术功底情况下，还是比较推荐MeterSphere的。
4.2、部署自动化
部署
部署就是将源代码编译成可运行软件包，比如jar包或者war包，并且将软件包放到目标环境，将软件包运行起来，并且能够被客户端调用。
流程
通过远程仓库拉取代码，前端编译，后端编译，下发软件包到目标机器，重启服务，启动失败则告警。
优点
相比传统手工部署，速度更快，不容易出错，提高交付效率。
技术选型
gitlab或者gitee：代码托管
git：版本管理
node：前端编译
maven：后端编译
ansible：下发文件
shell：重启服务
pipeline：流水线构建
Jenkins：CICD大总管，将以上工具整合起来，提供页面供用户操作部署流程。
4.3、Web UI自动化
UI自动化
通过页面元素定位定位到元素，模拟用户的操作行为，点击，输入，拖拽等。
流程
定位元素，模拟用户操作，发送测试报告。
优点
适用于回归主流程，并且变更不频繁的场景。可用于重复性的功能测试及验证。我之前在的团队做过一段Web UI自动化，但是因为需求频繁变更，并且精力有限，维护这个平台的成本较高，后面就没有持续维护了。
技术选型
Python，selenium。
4.4、App UI自动化
UI自动化
通过页面元素定位定位到元素，模拟用户的操作行为，点击，输入，拖拽等。
流程
定位元素，模拟用户操作，发送测试报告。
优点
适用于回归主流程，并且变更不频繁的场景。
技术选型
Appinum。
结论：我认为接口自动化和部署自动化是能够带来收益的，是真实能够提高效率的，并且也能够给测试人员的带来成长。
关注【嘎嘎软件测试】
搞测试，不迷路
呱呱大王本呱带你飞！
嘎嘎软件测试 分享个人成长、团队管理、软件测试技能知识等内容，做到有思想、有观点、有深度，欢迎订阅。
H. 自动精灵ui界面如何制作
制作自动精灵UI界面的具体方法会因使用的开发工具和目历塌标平台等因素而有所不同。以肢凯圆下是一些常见的方法供您参考：
1. 使用自动化测试工具提供的界面编辑器或可视化配置工具，例如Selenium IDE、Robot Framework等，它们通常具有可拖拽、可调整大小、可编辑属性等功能，可以很方便地制作UI界面。
2. 如果需要定制化更多的UI元素和交互效果，可以选择使用前端开发框架和工具孙派进行开发。例如，如果在Web应用中使用自动化测试，可以选择使用HTML、CSS和JavaScript等Web前端开发技术，利用主流的框架，如Vue.js、React.js等快速进行开发。
3. 另外还可以使用UI设计器和界面模板来加快UI制作过程。常见的UI设计器包括Sketch、Adobe XD、Figma等，在这些设计器的帮助下，您可以通过可视化拖拽、设计蓝图和样式表等方式快速完成静态UI设计。同时，还可以直接使用现有的UI模板，以模块化和组件化的方式构建UI，提高开发效率。
总之，无论哪种方式，都需要根据具体需求有选择地借用各种开发工具和框架，在快速实现UI设计的同时，保证交互体验和可扩展性。
I. Appium进行自动化测试的时候，始终无反应，也没有日志输出，请问什么原因
1. 启http服务器：127.0.0.1:4723 2. 根据测试代码setUp()进行初始化http服务器建立session象； 3. 始调用adb找连接设备设置设备id 猜测：我连接模拟器设备呢第二篇文章命令行启使用-U参数指定某设备我现图形界面启没指定设备 4. 等待设备准备响应命令 相关命令： c1: adb.exe -s emulator-5554 wait-for-device c2: adb.exe -s emulator-5554 shell "echo 'ready'" 5.启logcat志监控 java -jar appium\node_moles\appium\lib\devices\android\helpers\strings_from_apk.jar aimsi.apk c:\windows\temp\com.example.aimsi 条命令读取apk文件些apk基本信息json描述我例： { "app_name" : "Aimsi", "menu_settings" : "Settings", "title_activity_main" : "MainActivity", "RbtnImsi" : "汉字", "RtxtImsi" : "IMSI_IMEI" } apk属性信息文件strings.json存设备目录： c3:adb.exe -s emulator-5554 push "c:\\windows\\temp\\com.example.aimsi\\strings.json" /data/local/tmp 6.读取apk安装情况 c4:adb.exe -s emulator-5554 shell "pm list packages -3 com.example.aimsi" 读结我前已经安装apk 7.端口映射发给appium httpserver内容经httpserver直接发给设备 c5:adb.exe -s emulator-5554 forward tcp:4724 tcp:4724 8. 弄appiumjar包设备 c6:adb.exe -s emulator-5554 appium\node_moles\appium\build\android_bootstrap\appiumbootstrap.jar /data/local/tmp 网络bootstrap：Bootstrap 快速发Web应用程序前端工具包CSSHTML集合,使用新浏览器技术,给Web发提供尚版式 9.哇k安装unlock_apk-debug.apk c7:adb.exe -s emulator-5554 install appium\node_moles\appium\build\unlock_apk\unlock_apk-debug.apk apk用解锁屏幕解锁apk使其调试我猜者吧运行测试程序候看看手机没apk知道 10.kill掉所uiautomator进程 c8:adb.exe -s emulator-5554 shell "ps|grep 'uiautomator'" 我模拟器没启进程 11.执行bootstrap c9:adb.exe -s emulator-5554 uiautomator runtest appiumbootstrap.jar -c io.appium.android.bootstrap.bootstrap 帝原谅我没管写面紧跟着uiautomator输 12.bootstrap始工作 socket打4724端口appiumsocket服务器准备绪 加载json,唤醒客户端 等我想想设备apk--设备bootstrap--pcappium http server--测试程序先姑且猜着吧 13. 所设备运行窗口都输志文件判断设备已经解锁继续 c10:adb.exe -s emulator-5554 shell "mpsys window" 志文件写pc：appium\node_moles\appium\.mpsys.log 14.启测试程序 c11:adb.exe -s emulator-5554 shell "am start -S -n com.example.aimsi/.MainActivity" 15.等待测程序获焦点处超60s模拟器太慢居读两窗口才启功 16.创建session记初候根据setup提交给appium httpserver东东吧sessionid维持工作队列bootstrap队列面取命令执行像知道队列pc设备我觉像pc； 面些内容没啥看非步步调用 说啥研究些东西仔细做技术尤其测试技术原则用少搞明白底细遇问题候处理起快 吧
J. 学软件测试还是前端好一点 没什么基础，但是逻辑思维还算不错。
前端和测试就入行难度来说的话，肯定是前端比较难得。
国内的软件测试大多都是黑盒测试，通俗的讲就是手动输入，然后点点点。多一点就是配合一点自动化测试。绝大多数的创业公司都是这么一个情况。
而前端，相对于测试来，这么说都属于开发范畴了，要学习的肯定也更多，前端很杂，要学习的语言也是非常多的。我之前是测试转 Android 开发的，对前端了解并不多。
就发展前景来说，如果按照同等努力程度来说，也是前端的发展前景乐观一点。
国内的软件测试不那么受重视，很重要一个原因就是很多互联网公司对自己的系统质量要求不够高，导致很多情况都是近十个前端开发，然后就那么一个测试。甚至没有，得靠开发的自测。当然创业初期，需要削减成本，这个也是一个因素。
前端就不同了，虽然很多产品都偏向移动用户去了。但是从大趋势来看的话，不管是 Android 还是 IOS，以后都会被统一为大前端，只是时间问题。还有很多产品也是很重视PC前端的。
所以因人而异，要看自己的条件及兴趣天赋。
1、理工科好点的，逻辑思维比较强的，英语好的，有一定编程兴趣的，可以考虑前端。如果不是特别喜欢钻研的， 学前端，如果没有学好，可能很难找到工作 。
2、文科的，没啥计算基础的，希望可以风险小点的，可以选择软件测试，软件测试入门相对还是容易一些。