① 如何进行前端自动化测试
没人邀请，路过回答。
前端测试是前端工程方面的重要分支，有过一些探索，这里简单分享一下。
首先，还是要强调一点：
前端是一种特殊的GUI软件
看过我最近一年内做前端工程方面相关分享的人可能有印象，我总是在强调这一点。前端测试也跟这个理论基础有所关联。
在这里，我还想吐槽一下：
API测试方法论在测试GUI时并不能解决所有问题。
与很多前端工程师讨论过前端测试，大家更多的还是盯着API测试方法论。诚然，前端有那么一小部分代码是可以用API测试保证质量的，但前端项目中的绝大多数代码是GUI界面，前端测试应该向传统GUI测试方法论需求解决方案：GUI软件测试_网络 ，这个网络词条介绍的很不错，大家可以感受一下GUI测试相关概念和方法。它的测试用例、覆盖率统计、测试方法等等都与API测试有着很大的不同。
统一了这个认知之后，我们来讨论一下前端GUI测试的特殊性。根据网络词条上的那些介绍，相信大家都能感觉到GUI测试的成本非常高，而前端这种特殊的GUI软件，具有天生的快速迭代特征，这使得case维护成本也变得非常高，经常跟不上迭代速度。
一
个标准的互联网应用产品的前端部分，我粗略估计大概有20%的业务基础代码比较稳定，比如通用组件、通用算法和数据模块等，可以针对这些建立复杂一些的
API和GUI测试用例来保证质量。剩下80%的部分不是很稳定，每天都在迭代，针对他们维护case的成本非常高。目前业界中号称做了自动化测试的项
目，也大多是在做那稳定的20%。
关于稳定部分的单元测试方法我这里就不赘述了， @貘吃馍香 的答案给出了很多关键字，有兴趣的去搜索就好了。我想讨论的是针对剩下80%不稳定部分的工程化测试方案。据我了解，前端测试面对这些问题还是很无力的，业内大部分团队还是靠堆人解决。
面对这种现状，我其实也没想到过什么好的方法，基本原则就是：以最低的成本建立和维护自动化测试用例。到目前为止，就想到过两个方案（都不是测试方案，只是回归测试辅助）：
1. 不太靠谱的“超级工位”大法。
这个方案可以说根本不是什么技术方案，而是一个办公设施，就是我们准备一个工位，摆上所有我们需要测试的主流设备，然后设备通过某种方式与一台电脑相连接，测试人员坐在工位上，在电脑中输入某个url，就能同步到所有设备中，然后开始逐个的人肉测试。
超级工位大法示意图（应该很多设备的，这里就是随便展示一下而已。。。）超级工位大法示意图（应该很多设备的，这里就是随便展示一下而已。。。）
相比现在的前端GUI测试，超级工位已经算是从0到1的飞跃了，虽然没解决什么技术问题，但为测试前的准备工作做好了铺垫。如果把前端测试比作吃屎，超级工位就是为这餐准备了一个好一点的餐桌。。。
2. 靠谱一些的“页面差异监控”
12
年的时候还在网络，当时有同事去美国参加velocity，twitter分享了一下他们的开发流程，其中有一个环节就是页面对比监控，利用了一个叫
pdiff的工具，每次提交代码，会自动对比页面之间的差异然后提醒测试人员注意回归。这也是一个典型的GUI测试零成本维护用例的案例。不过pdiff
这个工具是基于像素对比的，误报率比较高，所以去年我做了一个这个项目：fouber/page-monitor · GitHub 基于DOM树的diff，这样就能很大程度上自主控制要监控的元素，可以设置监控样式、文本的变化，比起像素diff智能了一些。
其
工作原理就是利用phantom或其他headless浏览器访问页面，然后截图，然后执行一段js，遍历整个dom树，获取元素计算样式和元素内文本内
容，构造出一个JSON结构，然后每次diff这个json来判断页面差异，并标记在截图上展示。dom树的diff过程有点类似react的虚拟dom
树diff。
（react的dom树diff算法示意图）（react的dom树diff算法示意图）
（react的dom树diff算法示意图）（react的dom树diff算法示意图）
DOM树diff我们可以分辨出元素样式修改/内容修改/新增元素/删除元素四种不同的页面差异，我们可以配置选择器来忽略元素。四种页面差异的效果图：
新增元素（绿色区域标记部分，“i am new here”）新增元素（绿色区域标记部分，“i am new here”）
删除元素（灰色区域标记部分，“你好”）删除元素（灰色区域标记部分，“你好”）
内容修改（黄色区域标记部分，“百-度”，“新-浪”）内容修改（黄色区域标记部分，“百-度”，“新-浪”）
样式修改（红色区域标记的部分）样式修改（红色区域标记的部分）
基于这样的页面差异对比监控，我们可以建立一个任务系统，把应用的所有页面url监控起来，这样每次版本迭代提交代码后，系统就能自动告诉我们，哪些页面的元素展现发生了改变，用于确定回归范围。
用监控的方式确定测试回归范围，是一种“少吃屎”的手段，符合工程化要求，能比较大范围的应用，虽然不能完美解决GUI中的交互问题，但能保证GUI的展现问题已经是不小的进步了。
② 两年前端开发，感觉太累了，不知道该不该换行
同开发，只不过我是两年后端开发，外行人只看到我们行业挣得多，却不知道我们多少个日日夜夜加班到凌晨，为了上线稳定通宵也是有的。这个行业累是肯定的，但我想我们的收获也是多的，正所谓收获与付出成正比。楼主如果是喜欢这个行业，那可以趁着年轻再多奋斗几年，如果身体 健康 差了或者是厌倦了这个行业，那就尽早转行吧，转测试转产品等等都是可以的。
累因为积累的东西不足以支撑自己走下去
累因为东西学不动了没有竞争能力了
累因为觉得这行业给你了对未来的恐惧感
累总是因为你有不敢面对的原因，走出来就好了
最近几年前端的变化确实很大，不过你刚从业两年，如果换行业，我觉得一个是看自己兴趣方向，另一个就是考虑收入情况！
首先，两年的前端开发经验，在前端开发这个领域的收入是你转到任何一个行业都比不了的！其实还有好多人由于自己工资太低还想去培训做开发多赚些钱呢[可爱]
其次，就是关于工作累的问题，我觉得任何行业可能都不轻松，而且也不一定可以拿高工资。
最后，我想说的是，目前前端趋势还算明朗，多花些时间把常用的框架，语言学习扎实 ，然后多积累多总结，后续工作可能效率就会提高，也就没那么累了
纯属个人的一些想法与建议，最后还是要自己做打算，只能帮你到这儿啦 [呲牙]
看你是不是还继续喜欢着前端工作，如果喜欢请继续。因为现在的前端开发行业很火，现在的用户在基本操作的前提下越来越注重页面的美观和体验，而这都是靠前端技术人员来完成的，不管后端代码写得有多好，算法用的多么精通这些用户通通不管，他们看到的就是眼前的页面，所以说前端还是很好的。不过前端技术更新太快所以要及时掌握新技术才能不被淘汰。
为啥你们程序员都说换行，我觉得转行没那么容易呀？
前端转行有什么路子没？
转行，做什么呢？感觉除了写代码，其它都不会啊？？？？
③ 如何进行前端自动化测试
一般前端自动化测试大致包括
类库单元测试自动化
UI组件测试自动化
类库单元测试自动化
较好实现
基本思路是让不同的浏览器可以自动根据指令跑一些JS函数
结果与预期比对后返回是否通过case测试标志
其中一般有两种实现方式：
其一：
1.打开目标浏览器，运行测试框架站点
2.测试框架站点通过ajax 轮询、websocket 等方式，将待测 js 的 case 在浏览器内运行（通过eval 、createElement("script") 等方式）
3.比对测试结果，将结果 post 到远端
4.远端接受测试结果
5.远端等待所有浏览器返回结果完成
6.marge 所有浏览器数据显示最终通过与否结果。
这种方式弊端：
人工开启一次所有浏览器
需要排队测试，浏览器只能一次运行完一组测试后才能再运行下一组
如果中间某testcase导致浏览器异常，返回结果将缺失，需要人工去服务器上检查下浏览器状态
好处：
可以覆盖所有想覆盖到的浏览器
另一种方式：
1.将常用浏览器内核放进一个或多个相互有关联的进程内
2.用例通过系统消息发送到各个包装的内核中
3.每次开启一个新内核进程运行JS用例
4.用例结果发送给包装进程
5.包装进程汇集所有用例结果后post到远端保存
6.包装进程连带内核进程一起退出
优点：
无序人工开启一次浏览器
独立进程运行，无需排队
不怕内核异常，异常后包装进程可以直接恢复内核或者通知测试失败
缺点：
前端实现太困难，需要C++开发
无法覆盖到所有浏览器
常用内核覆盖更新劳心劳力
④ 怎么加强自动化测试脚本的稳定性
IBM® Rational® Functional Tester 是用于功能性和回归线测试的高级测试自动化工具，它可以在一个基于图形化用户界面（GUI）的程序上录制测试场景，并回放测试场景以实现测试自动化。在录制期间，您可以插入确认点，这些确认点可以从您正在测试的程序中获取特定的数据或者属性。然后在回放期间，这些确认点用来将录制的信息，与现场信息进行比较以确保稳定性。工具会搜索映射的对象，并在测试期间对其执行一系列的操作。 但是，由于对象不存在或者不适当的状态，Playback 特性通常会遇到一些失败情况，在回放期间，如果 GUI 响应时间或者 GUI 到达预期状态所花费的时间，要远远高于录制时间，那么工具所执行的操作就不能在适当的位置找到适当的对象或者它们的状态或属性了，这样脚本回放就会失败。通过按照本文中所介绍的步骤进行操作，您将会学到怎样利用 Rational Functional Tester 程序编程界面（API），来改进脚本以实现基于 Eclipse 程序地可靠测试自动化。 前提条件 如果您拥有下述的知识，那么您就能从本文中学到更多的信息： 熟悉 Eclipse 环境以及为测试下程序配置 Rational Functional Tester 熟悉录制和回放测试脚本，并理解测试脚本的内容 场景 注意： 对于这些范例，IBM® Rational® Software Architect（一种基于 Eclipse 的程序）用作测试下的程序。 本文将会涉及到测试自动化中以下的失败场景，并解释在 Eclipse 工作区中遇到它们时的方案。 场景 1：不匹配的 GUI 响应时间 在回放期间，如果 GUI 响应时间要比录制期间的时间长，那么自动化工具将不会找到需要执行操作的对象，而测试脚本也将会失败。 场景 2：未预期的活动窗口 如果在自动化测试的回放期间，出现了一个未预期的活动窗口，那么在录制期间该窗口将不会出现，自动化脚本将会失败。自动化会因为未处理的窗口而停止。 场景 3：不适当的对象状态 当您在创建确认点时，如果对象没有处于它所预期的状态，那么它会获取所有需要的具体内容。同样，在回放期间，如果并不能确保相同的对象状态，那么确认点将会失败。 图 1 中的图表描述了处理这些场景的基本方法。 图 1. 方案的基本方法 方案方法基本上可以改进使用 Rational Functional Tester API 的脚本。作出的选择能够处理描述的场景，该场景可能发生在测试自动化场景之中。 创建 Eclipse：准备 Rational Functional Tester 以测试基于 Eclipse 的程序 为了对基于 Eclipse 的程序使用 Rational Functional Tester 自动化测试特性，您必须首先按照下面的方法来创建测试的环境： 点击 Configure > Enable environment for testing 以打开 Enable Environments 窗口（参见图 2）。 选择 Eclipse 实例，并点击 Enable。如果 Eclipse 环境尚没有列出，那您您可以点击 Search。 点击 Finish 以保存您所做的修改。 图 2. 激活环境窗口 修改代码：根据用例来更改自动生成的代码 在这一步中，会获得对自动生成代码所做的更改，以处理前面所描述的一个或者多个失败。每一个失败场景的解决方案，都与下述描述的子部分不同。 场景 1：不匹配的 GUI 响应时间 对于该场景有两个可能的解决方案： 方案 1a. 检查进度条的状态 当您在基于 Eclipse 的程序中创建一个项目时，项目构建和确认会在项目向导完成之后才启动，其中基于 Eclipse 的程序例如 Rational Software Architect 或者 IBM® Rational® Application Developer。有时所花费的时间要比预期的长，脚本回放会失败，因为项目构建没有完成，但是脚本会试着进一步地操作。为了避免这种失败情况的发生，您可以在 Eclipse 工作区右下角查看进度条的状态 修改代码：根据用例来更改自动生成的代码 在这一步中，会获得对自动生成代码所做的更改，以处理前面所描述的一个或者多个失败。每一个失败场景的解决方案，都与下述描述的子部分不同。 场景 1：不匹配的 GUI 响应时间 对于该场景有两个可能的解决方案： 方案 1a. 检查进度条的状态 当您在基于 Eclipse 的程序中创建一个项目时，项目构建和确认会在项目向导完成之后才启动，其中基于 Eclipse 的程序例如 Rational Software Architect 或者 IBM® Rational® Application Developer。有时所花费的时间要比预期的长，脚本回放会失败，因为项目构建没有完成，但是脚本会试着进一步地操作。为了避免这种失败情况的发生，您可以在 Eclipse 工作区右下角查看进度条的状态
⑤ Web端自动化测试失败的原因
最初的测试自动化失败是从不切实际的期望中获得的。在我的职业生涯中，我已经多次观察到它，一旦您获得了自动化的质量保证或工作人员，管理层就期望他们对所有内容进行自动化测试。尽管听起来很令人愉悦，但这是不可能的。您不能进行100％的自动化测试，因为在少数几个领域必须进行人工检查。这些领域之一可能与您的Web应用程序的可访问性有关。
例如，如果您正在执行自动跨浏览器测试，则用于Selenium测试的自动化脚本将在不同的浏览器或操作系统上呈现网页的显示。但是，要确定网站是否按照设计进行渲染，版式是否合适，文字是否合适，最好手动评估
许多组织确实意识到期望进行100％自动化测试的问题陈述，但通常会遇到以下问题。我们可以实现什么自动化，如果不是100％，那么我们可以为Web产品实际实现多少自动化？
没有适用于每个企业的自动化测试覆盖率的完美百分比或近似值。这完全取决于您所提供的Web应用程序，并且由于不同的企业正在满足不同的需求。自然而然地，人们会对围绕自动化测试实际能实现的自动化测试百分比抱有独特的期望？自动化测试的范围将从电子商务Web应用程序到静态，动态或动画Web应用程序有所不同。因此，如果您想知道为什么自动化测试对您的组织失败？然后，我建议您根据所提供的Web应用程序的类型来评估所需的自动化测试量。
在我作为自动化测试员开始IT生涯时，我就一直是管理不当的受害者。我当时在一家基于Service的公司工作，他们为我分配了我的第一个项目。这个项目已经运行了两年，当我加入后，我被交给了一系列测试自动化脚本。项目的高层将要离开组织，管理层对即将到来的冲刺太忙了，无法考虑将要离开的高级自动化测试人员进行的全面知识转移课程。他们离开后发生的景象不佳？我的经理在听证会的结尾说，我们因停电而大吃一惊，而我刚起步，对各种出站和入站流程如何受到众多自动化脚本的影响的了解最少。然而， 我见过一些由少数成员负责实现自动化的团队，而其他成员则对正在发生的事情一无所知。
您是否认为当一半的团队缺乏可见性时，从自动化测试中获得魔术效果是不现实的吗？由于自动化必须是一个协作的工作，因此对每个团队成员进行相关工具和流程的教育非常重要，尤其是对新手而言。您可以通过举行团队会议和会议来讨论与自动化有关的工具，趋势和实践，从而实现这一目标。
这可能会让您有些惊讶，测试自动化失败的另一个原因可能是缺少手动测试技能或 探索 性测试技能。自动化测试脚本并不意味着团队成员可以减少一些懈怠。到目前为止，我们已经知道，自动化方法不能涵盖所有内容，而这正是挑战所在。因为现在您必须更深入地研究Web应用程序，并找到队友尚未发现的关键测试方案。
自动化是节省测试工作的一种方式。软件公司应该使用它来最大程度地减少重复，并尽量使那些不易更改的元素自动化。一旦完成，公司应该分配他们的资源来执行广泛的手动测试或 探索 性测试，以找到独特的测试用例。
自动化似乎是减少工作量的一个目标。但是在开发测试自动化脚本之前，必须考虑周全。此外，这可能会花费大量的自动化测试执行时间。框架和测试自动化工具的灵活性在开发脚本场景所需的时间中起着至关重要的作用。
由于每种情况都不同，因此必须编写脚本。即使您仔细考虑，如果不编写脚本脚本，这都是浪费。确保测试工程师的编码技能与测试的复杂性保持一致。复杂的测试需要大量时间才能实现自动化。因此，随着全新功能的发展，他们通常没有机会发现回归的错误。在写下测试方案之前，请确保牢记这些注意事项。
“ 为什么测试自动化对您的公司失败？”背后的最常见的原因？”是人们不知道什么时候应该自动化，什么时候不知道。例如，可以自动化不同的网页功能。但是通过测试自动化评估填充，图像等渲染问题不是一个好主意。如果使用坐标来确定元素位置，则在以不同的屏幕分辨率和大小运行时，可能会导致差异。
在测试易于进行大量更改的项目时，使用自动化是不可行的。如果您要测试稳定的实体，那么自动化是必经之路。基本上，需要重复执行某些操作的普通任务最适合自动化测试。因此，测试自动化可以简化您的回归测试过程。
我看到IT行业普遍存在错误观念。人们认为任何开发人员或测试人员都可以执行测试自动化。测试自动化的设计，配置和实施需要特定的技能。执行自动化的测试人员应该知道如何在经理，开发人员和客户之间阐明想法。他/她还应该对开发趋势有清晰的了解，并且应该知道开发团队要去的方向。
自动化测试工程师是最困难但最重要的一些人。为了启动各种自动化项目，聘请具有广泛技术知识的测试人员至关重要。整个团队应该知道发生了什么，而不是由一个或几个人进行自动化测试。即使在雇用技术精湛的员工方面投入很高，但回报还是值得的。
由于自动化测试是一个相对较新的现象，因此失败的可能性很高。测试团队进行的新实验太多，因此准确分析结果变得很重要。进行测试后，测试人员必须做出详尽的测试报告。但是，这就是测试自动化对您而言失败的原因！您的团队没有对测试报告的分析给予足够的重视。如果执行不当，分析可能会导致无人看管的故障，并浪费时间，资源和精力。
在自动测试中，有些测试成功，有些失败。因此，必须检查测试报告是否有故障并分析某些测试失败的原因。最好手动进行分析，以发现真正的故障。揭露隐藏的问题并确保它们不会被其他问题掩盖而被忽略是至关重要的。
设置太高而不能成为自动化的真正目标，在纸面上似乎很完美。但是，在执行步骤时，团队成员之间严重缺乏清晰度。最大的问题是目标不明确。他们缺乏从自动化中获得真正价值的准确性和准确性。大多数公司所做的是，他们开始将非常复杂的事情自动化，并最终重构整个框架。结果，团队最终会浪费大量时间，金钱和精力。
您可以通过从小处着手并逐步提高复杂性来消除不确定性。选择稳定的功能，并从其自动化开始。之后，收集反馈以确定出了什么问题。一旦您的测试达到一致性，就可以继续使用其他功能。对于不同的项目环境，需求可能会有所不同，因此请使用自定义方法进行测试自动化。
在拥有大量自动化工具的情况下，有时候选择最佳工具变得充满挑战。最终目标是改善整体测试程序并满足实际要求。但是大多数团队都无法从头再来，也没有挑选出最适合其测试需求的工具。毫无疑问，自动化测试是高度依赖于您决定继续使用的工具。每个工具都有特定的功能。但是，团队缺乏充分利用这些功能所需的专业知识水平。
此外，公司陷入了对特定工具的炒作。但是在选择它之后，他们意识到它并没有提供他们希望获得的一切。另外，每个团队都有预算，有时该工具的成本超出了预算。在继续选择操作工具之前，请仔细列出要求。之后，确定您对该工具的期望值。在设定目标时要非常具体，并检查与产品用户接受标准的对应关系。您也可以咨询有使用这些工具经验的专家。
几乎每个组织都经常观察到这一点。一旦自动化测试套件准备就绪并且工作正常，管理就开始放松。他们开始放宽对测试执行的深入分析，因为他们认为只有通过/失败检查才足够。但是，这就是测试自动化导致他们失败的原因！
有时，系统从根本上可以正常运行。但是，自动化脚本不能反映出相同的情况。他们以其他方式陈述并导致假阳性方案。因此，这造成了混乱的局面，浪费了时间，精力和资源。我已经看到测试团队试图找到不存在的东西是多么令人沮丧！
每个Web元素都必须有一个ID才能执行有效的测试。但是有时，开发人员无法将ID分配给所有Web元素，这就是测试自动化失败的原因。在这种情况下，自动脚本必须查找这些Web元素，这会花费大量时间。此外，如果脚本无法在规定的时间内找到这些元素，则测试将失败。因此，为了确保脚本的正确同步，团队必须为所有Web元素分配唯一的ID。
因此，最终使所有想要自动化的东西都自动化了。您最终获得了庞大的测试套件，直到现在，您才开始碰壁。这些复杂的测试套件执行时间比您预期的要长。这开始与您各自的IDE测试自动化框架中的测试队列质量相抵触。结果，由于队列超时问题，测试用例突然停止，这都是因为您要按顺序执行它们。测试用例的顺序执行是Web应用程序测试自动化失败的另一个原因。
与顺序运行测试不同，并行执行使您可以在不同的环境中同时执行多个测试。但是自动化测试可能会导致意外的代码交互。调试失败的原因非常困难，因此您需要透彻的报告机制，提供有关测试执行的详细见解。
无论您在线经营什么业务，ROI都将成为每次董事会会议的议程。股东要求更高的回报。而且，无论您准备测试自动化套件花费了多少时间和精力，如果它们产生的ROI均达不到预期，那么它们的重要性将比您预期的要轻得多。
在计算测试自动化的投资回报率时，可能需要考虑许多指标，例如测试维护，购买必要的测试自动化工具所涉及的成本，板载资源等等。计划不切实际的ROI对于许多组织而言可能是成问题的，并且可能是测试自动化失败的原因。
许多组织给人以自动化测试容易的印象。您所需要做的只是编写几行代码以自动化您的Web应用程序的测试工作流程。就是这样！您完全不必担心测试自动化脚本的计划和输入。但这不是！
您需要评估波纹效应。您的Web应用程序将包含许多旨在测试不同模块和流程的测试自动化脚本。如果一个测试脚本无法正确执行，则其他脚本也可能触发测试自动化失败。不仅如此，在计划资源时还应该计算出连锁反应。
假设您有一个高级资源，他曾经写过脚本，现在已经离开了公司。您可能没有想到辞职可能会在自动化项目的未来时间表中产生连锁反应。这就是为什么需要记录有关系统中每个自动化测试脚本的每个细节的原因。该文档应作为萌芽的自动化测试人员以及经验丰富的自动化测试人员的标准。
测试自动化对您的组织失败的另一个原因可能是不合适的测试套件。许多自动化测试人员会创建静态测试套件，这些套件在您扩展业务时并不那么灵活。每当平台发展时，它们最终都会重新编写整个自动化测试脚本。这是一个坏习惯，因为您在浪费时间，资源和金钱。另外，这也是一个错误的过程。确保您编写随平台扩展而发展和适应的测试套件。
避免测试自动化失败的另一种方法是即兴测试套件。现在，这听起来似乎很明显，但是在许多组织中却没有实践。原因是，一旦他们设计了测试套件，并发现它可以正常工作，便开始着手自动化新领域。我没有批评沉迷或 探索 新领域以实现自动化的努力。但是，管理一个时间窗口并让您和您的团队回顾现有的代码段，以找出进一步优化它的方法并没有什么坏处。始终尝试使用您的测试套件，以使事情变得更好。
随着敏捷软件，看板软件等现代SDLC（软件开发生命周期）方法在全球范围内的采用，协作已成为将Web应用程序更快部署到市场中的关键组成部分。
这是一个多维软件开发过程，所有团队都在同时开发Web应用程序。您有一组开发人员设计前端，另一个负责后端，还有一个负责中间件活动的团队。作为测试人员，您需要了解哪个团队负责哪个模块。您必须及时了解不同团队所做的产品增强功能，并对自动化脚本进行相关更改，以确保测试自动化不会失败。
自动化测试的主要目的是最大程度地减少重复手动测试所涉及的压力，以节省时间。从抽象的角度看，这听起来不错，但对于那些执行测试自动化的人来说，要意识到为执行内部测试自动化而配置正确的基础结构的艰辛。我经常观察到测试人员在执行新脚本之前会刷新整个测试自动化套件，以避免与脚本产生任何歧义。但这不能使自动化测试的整个过程都失败，不是吗？
例如，如果您正在使用内部Selenium Grid执行自动跨浏览器测试，以测试适用于Google Chrome和Safari浏览器的macOS和Windows操作系统的网站。现在，您可能每次都要运行Selenium脚本之前就不得不面对设置新操作系统的麻烦。
这是组织自动化测试失败得非常普遍的原因。特别是在临近最后期限时。您的测试部门将继续在同一测试环境上运行大量测试套件，而不会清除先前执行的测试自动化脚本的缓存。这可能会导致错误的测试评估，当您遇到更多的假阴性和假阳性时，您的测试报告可能会受到影响。
例如，假设您需要针对不同的地理位置测试您的Web应用程序。在静态测试环境中执行地理位置定位时。您的脚本可能会遭到Google的测试，要求您证明自己不是机器人。这将导致测试自动化脚本失败。
这就是需要使用清除的缓存的新虚拟机的原因，因此您可以获得自动化跨浏览器测试脚本的准确结果。
为了使自动化能够在不同的测试环境中工作，需要进行大量的计划。您需要在暂存环境上进行测试，以确保将代码移入生产管道时，它们可以完美地工作。但是，经常会发生这样的情况：在舞台环境中进行测试时，用于代码更改的测试自动化脚本可以无缝运行，但是当移至生产环境时，它就会崩溃。此类问题背后可能有许多原因，例如缺乏持续的监控，登台环境无法使生产环境成对增长，缺少实时流量等等。
但并非最不重要的。如果到目前为止我们已经讲完所有要点，并且您的测试自动化仍然失败，那么您唯一需要反思的地方就是您自己的测试自动化脚本。确保您没有为整个项目中涉及的任何测试脚本提交任何编译时以及运行时错误。
如果您的组织需要提高生产力，那么自动化测试就是必经之路。这是提高产品质量所需的最有效的过程之一。测试自动化还提高了软件的健壮性。但是要谨慎执行和拖延。您不能在没有障碍的情况下匆匆忙忙，因为没有一家公司可以承受损失巨额资金的麻烦。另一方面，过多的恐惧会阻止您获得自动化测试所提供的显着优势。
感谢每一个认真阅读我文章的人！！！
如果下面这些资料用得到的话可以直接拿走：
1、自学开发或者测试必备的完整项目源码与环境
2、测试工作中所有模板（测试计划、测试用例、测试报告等）
3、软件测试经典面试题
4、Python/Java自动化测试实战.pdf
5、Jmeter/postman接口测试全套视频获取
我个人整理了我这几年软件测试生涯整理的一些技术资料，包含：电子书，简历模块，各种工作模板，面试宝典，自学项目等。需要的可以私我谢谢
⑥ 前端自动化测试框架Jest 基础入门-
一、引言
前端这几年发展的非常迅速，我们的系统的功能正在变的越来越复杂，这对我们的前端工程化能力提出了更高的要求，听到工程化，大家的第一反应肯定是高质量的代码设计和高质量的代码实现。
但实际上，前端 自动化测试 也是前端工程化里面非常重要的一个环节。
二、 Jest 基础入门
一个普通前端听到自动化测试，第一反应可能是：我工作这么多年也没写过测试，这个东西有用吗？
答：非常有用
如果你打开GitHub，去看一下流行的开源库或者框架的源码，你会发现，在这些源码里面，全部都包含了大量的自动化测试的代码。比如antd、lodash、再比如vue、react、echarts、rex等等……
开源的工具需要稳定性，而引入前端自动化测试为开源项目提供稳定性，是再好不过的选择了。
三、学习前提
阅读这篇 文章 需要以下知识储备：
·js、es6 基础语法
·node、npm 相关知识
·git 的相关操作
·react或者vue，至少了解一个
·状态管理工具，至少了解一个
四、背景及原理
首先在任意目录下创建一个math.js文件，假设这个文件是一个数学库，里面定义两个函数，分别是加法和减法：
// math.js
function add(a, b) {
return a + b;
}
function minus(a, b) {
return a - b;
}
这时候我们可以在业务代码里去使用这个数学库。
但是，假如，上面的minus函数我们不小心写错了，把减法写成了乘法，如果直接在业务代码中使用这个方法，就会带来无法预期的bug。
所以这时候，我们就需要对math.js这个公共库进行自动化测试，确保没问题之后，再让业务组件去调用，这样就会保证不会出特别多的bug了。
我们可以这样做：
在该目录下创建一个math.test.js文件，然后写一点测试代码：
const result = add(3, 7);
const expect = 10;
if (result !== expect) {
throw new Error(`3 + 7 应该等于${expect}，结果却是${result}`);
}
const result = minus(3, 3);
const expect = 0;
if (result !== expect) {
throw new Error(`3 - 3 应该等于${expect}，结果却是${result}`);
}
这时候我们运行这段代码，会发现没有抛出任何异常，说明这两个 测试用例 都通过了。
这就是自动化测试最原始的雏形。
然后我们思考一个问题，如何将这堆代码进行简化，做成一个公用的函数，比如这样：
// 测试 3 + 3 是否等于 6
expect(add(3, 3)).toBe(6);
// 测试 3 - 3 是否等于 0
expect(minus(3, 3)).toBe(0);
expect 方法实现：
function expect(result) {
return {
toBe(actual) {
if (result !== actual) {
throw new Error("预期值和实际值不相等");
}
},
};
}
这时候我们运行这段代码，会发现没有抛出任何异常，说明这两个测试用例都通过了。
虽然实现了 expect 函数，但是报错的内容始终是一样的，我们不知道是具体哪个方法出现了问题，这时候我们就会想到，我们需要将这个 expect 方法进一步做改良，我们如果能在 expect 方法外部再包装一层，就可以多传递一些额外的内容，比如创造这样的写法：
test("测试加法 3 + 3", () => {
expect(add(3, 3)).toBe(6);
});
test("测试减法 3 - 3", () => {
expect(minus(3, 3)).toBe(0);
});
这样封装之后，我们既能进行测试，又能得到测试的描述。
test 方法实现：
function test(desc, fn) {
try {
fn();
console.log(`${desc} 通过测试`);
} catch {
console.log(`${desc} 没有通过测试`);
}
}
所以前端自动化测试到底是什么？
答：实际上就是写了一段其它的用来测试的js代码，通过测试代码去运行业务代码，判断实际结果是否满足预期结果，如果满足，就是没有问题，如果不满足，就是有问题。
上面实现的 expect 方法 和 test 方法 实际上和主流的前端自动化测试框架 jest 里面的语法是完全一致的。所以上面的示例代码可以理解为 jest 的底层实现原理。
⑦ 如何有效的开展自动化测试
自动化测试不宜大力投入
不管是自动化测试还是接口测试，都不宜在前期大量投入。当前业务是否适用自动化，哪些框架或者工具更适合，适合做接口自动化还是 UI 的自动化？如何让自动化达到收益和效果？
这些问题都需要根据团队和业务具体的情况去尝试，找到合适的才行。如果前期投入太大，团队对其期望太高，非常容易在遇到一点挫折的时候对自动化丧失信心。
另外，投入太大，毕竟加大人力或者减少手工测试的投入，会造成测试资源的紧张。在项目时间和成本的压力下，测试管理者需要顶着巨大的压力，这本身就很难成功。
可以安排一些技术强或者技术兴趣浓厚的成员，在项目允许的情况下减少其手工测试工作量，让其可以利用部分工作时间和部分业余时间尝试做自动化，先局部功能尝试，能够有效果，在扩大范围。逐步达到一定的自动化规模。
以接口为主UI为辅
UI 自动化因其运行环境的问题，会导致运行速度慢，对环境依赖过高。同时因程序界面的多变性，导致自动化脚本维护成本大大增加。
接口测试有很多优于 UI 自动化的地方。但是接口测试也自有其短板，对流程性质的测试并不适合用接口自动化来覆盖。接口自动化更适合覆盖单一接口功能的检查。
所以我们可以采用核心业务流程使用 UI 自动化，单一功能使用接口自动化，两种层面的自动化结合的方式来进行。
不轻谈自动化测试平台
目前测试界开始流行起自己开发测试平台（以接口为主）。简单来说就是模仿常见的接口测试工具，用 Python 或者 Java 写成了一个 web 版本的。
当然也有其理由，“定制性更强！”但是毕竟是软件都需要进行测试，花大量精力开发的平台并不稳定，而本身功能和理念上并没有太多更新。而这样的一些功能，市面上的绝大部分测试工具都能胜任。
如果是为了提高个人能力，项目时间有空余，怎么玩都可以。若是要在实际工作中应用，那么就有点得不偿失了。
自动化测试中，工具的重要性始终是最低的。理念、思维和环境治理才是最重要的。
通过不断小范围试错，找到适合自己团队的自动化策略才是最重要的。任何技术脱离实际应用都是耍流氓。
⑧ 谁知道做软件测试好还是做开发好
从工资上讲是软件开发：
软件开发是要看资历的。一般初级工程师，也就刚入门，基本能力过关，没经验的人工资大概4k到8k，随时间的累积工资也会上涨。工具工作年限5年以上，有丰富的团队开发经验，有一定的大型系统框架设计经验，工资大概会在30k到50k左右。
软件测试刚入行的软件测试人员，起步月薪大多才5000-7000元左右。高于同龄人1000-2000元的薪资水平，工作2-3年后月薪在9000-12000元左右，3年以后基本就在10k到20k左右。
从技术上讲是软件测试：
开发又要前端和都端，现在还有一个终端，这些开发基本要熟悉Java，H5，数据库等语言，作为一个公司的开发要想拿高工资技术肯定要到位。如今大量的人投入IT行业可为什么还是大量缺人，那是很少的人技术达到高端水平，可想技术的难度有多大。
测试是进入IT的一个低门槛职业，需要你掌握的内容不要求精,但是要求广。文案编写是最基本的还需要熟悉一下编程语言比如脚本。然后了解你自己所需要的工具，关于计算机的配置信息。相比于开发肯定是简单了不少。
职业规划上讲,肯定是软件测试：
开发是非常伤脑的职业，相信如果仔细的人会发现IT行业秃头的人多、年轻人多。第一点就是做开发费脑头发容易掉，很伤身体，所以一般40岁左右就是开发的结束年龄。第二点一个IT公司需要新鲜血液，没有新的idea，公司就会面临淘汰，所以年轻人较多。
软件测试门槛低、技术要点少，基本就是固定的结构和方法，所以对于资历越老对公司的效益越高。
⑨ 前后端自动化测试方案
这段时间我探索了点自动化测试方面的技术，探索结果如下
【后端】：任意后端工程 + python 自动化测试脚本（实现接口测试），服务器要求：指令服务器即可（即终端操作系统）
【前端】：任意前端工程 + python 自动化测试脚本（实现UI交互测试），服务器要求：必须是可视化服务器（即有交互界面的系统） （虽然说 phantomjs 可以实现无界面的情况下进行浏览器测试，但是还是不太推荐，毕竟对于前端而言，可视化才最好）
经过探索下来，发现 python 在实现自动化方案确实非常合适，且前后端都可以通过python实现自动化测试，如此一来自动化测试也就可以独立出一个工程，而无需受前后端工程语种、框架等各种不同的影响。只是前端自动化测试比较特殊，需要模拟用户交互，最好是有界面的系统（通过浏览器驱动器调用浏览器实现自动化交互测试），也就是说前后端的自动化测试服务器要么都用一台带交互界面的系统，要么就用2台服务器，一台终端服务器测后台接口，一台交互服务器测前端交互