❶ 在javascript中如何做控件测试
不太清楚你说的控件测试是指的什么，一般前端测试js的话，如果测试数据提交响应使用抓包工具fillder或者其它的进行抓包以及伪造测试数据，浏览器的话IE的httpwatch，火狐的firebug，谷歌的chrom都是不错的测试工具，我们可以看到页面的情况，js信息传输包，以及语法错误报错控制台，甚至可以写一些js语法，在开发工具中直接进行验证，另外js语法中常用来测试的语句是alert，console，希望对你有帮助~
❷ 问大家一个问题，我刚做前端一个月（实习）
今年5月开始前端之旅，学习近4个月之后，于9月底，参与了一个商城厂家后台的前端页面的开发，所做的内容并不多，但是在这段时间的收获却不少。接下来将详细谈谈这些收获。
1）参与项目之前应该做什么
在实习刚开始的时候，主要是从git上clone代码，然后自己在前辈的指导下查看代码结构，理解整个流程。当时花的时间不长，基本也把代码看的差不多了。这个是很重要的，你需要对整个前端的架构有一个大致的了解。
2）写第一行代码前应该做什么
仔细看产品原型，查看接口文档。这是非常重要的，特别是原型，需要仔细的查看原型，看看那些地方存在不合理的，需要及时找产品或相关负责人沟通，最终要确保你对整个产品原型有很详细的了解。这样子不至于在写页面，写交互的时候出现大问题。还有接口文档也是很重要的，前端和后端都需要一份共同的接口文档，大家根据这个文档进行数据交互。有了共同的接口文档，在开发过程中不用关注变量名这些无关紧要的细节。而且能确保前后端数据交互时不会有不一致的地方。
3）写代码时应该做什么
多思考，就能少写几行不必要的代码。这是很重要的一个问题，一般来说，在最开始的时候，需要将所需要的技术掌握，然后将页面分成几个小块，从整体到部分，要清楚代码的大致结构，脉络。先将大的东西做好，再慢慢细调。这样子不必时刻纠结于细节，浪费不少时间。写代码时要遵循代码规范，比如说Tab键还是空格缩进的问题，比如说是LF还是CTLF换行的问题，尽量采取和大家一致的开发环境，这样在别人看你的代码和你看别人的代码时会减少不必要的麻烦。
4）写完代码时应该做什么
单元测试，不用多说。如果是用RAP来进行单元测试的话，要注意测试用例设计的合理性。
5）前后端联调
前后端联调应该采取怎样的方式才是最好的？以前是一个前端搭配一个后端，他们用同一个分支。联调时，后端从git上pull代码，然后在本地跑一遍gulp，然后运行联调。这样有一个问题就是，当前端有问题时，如果是一个很小的问题，那么他也需要从他自己的机子上改，然后commit，push代码，然后后端在他的机子上重新pull，gulp，运行联调。这样子比较繁琐，效率不怎么高。现在的做法是前端将请求用nginx代理请求到后端的机子上，然后在前端进行测试。这样前端发现有问题，他自己修改就好。后端不用pull代码。后端发现有问题也是如此，这样前后端就分开了。
6）提交给测试人员
当联调完成之后就可以将代码提交给测试人员。测试人员通过模拟真实数据来进行功能测试。之所以在测试阶段会有这么多问题，是因为：前后端联调的时候，对联调数据没太在意，以为数据跑得通就OK。导致一上到真实环境出现一堆问题。另外一个原因是，测试人员往往不能够详细描述问题出现的情形，比如说：在什么情况下，做了什么操作之后，出现了什么样的结果。出现的频率。和预期的差别。实际得到的结果往往是：出现了某个问题，然后把错误一截图发给开发人员就没了。其实对于前端来说，需要知道做了哪些操作导致的bug往往是特别重要的。
❸ 测量的小伙伴，请问如何做假的CPK报告数据
在公差范围写够30个的测量数据再计算。
❹ 如何进行前端自动化测试
没人邀请，路过回答。
前端测试是前端工程方面的重要分支，有过一些探索，这里简单分享一下。
首先，还是要强调一点：
前端是一种特殊的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的展现问题已经是不小的进步了。
❺ 如何开展数据中心假负载验证测试
众所周知，购车前我们都会有试驾环节，通过试驾我们可以验证和评估车辆的品质。同样的，在新建数据中心基础设施交付前，也需要通过假负载模拟服务器运行对数据中心基础设施进行全方位测试，亦即试运行。假负载验证测试通常会产生大量的测试费用，并延长项目交付工期；经测算，2万台服务器规模数据中心的假负载验证测试将耗时近1个月，测试费用更是高达几十~上百万元。
在海外，数据中心假负载验证测试已经得到广泛应用；而国内在这方面起步较晚，但随着国内数据中心产业快速发展，越来越多的企业开始重视数据中心假负载验证测试。
一定要进行假负载验证测试么
答案是肯定的。假负载验证测试耗时长、费用高是不争的事实。然而近年来行业内新建数据中心却广泛引入假负载验证测试环节，这是为什么呢？我们先看两个案例。
案例
故障情况
故障原因
1某数据中心市电中断柴油发电机启动后，输出开关未自动合闸，导致末端负载无法加载。
柴发配电输出控制转换开关虚接，自动合闸失效。
2某数据中心冷水机组出现故障后，开启备用冷水机组运行几分钟后自动停机。
冷冻水系统管道上旁路阀门未正确关闭，导致机组启动不久后自动保护停机。
诸如上述故障，在新建数据中心投产前通过假负载验证测试是可以及时发现和规避的。同时，假负载验证测试的成本是可以预见的，而如果带风险投入运营后故障产生的损失将难以用金钱衡量，投产后的整改难度和成本也将显着增加。
假负载验证测试的内容
据统计，数据中心常见故障主要有四类原因：
设备质量
施工工艺
自控系统
人为操作
❻ Web前端站点有哪些功能测试的方法
有些测试方法的界限比较模糊，比如功能测试的同时会穿插一些兼容性和安全性的测试，以下列出简单的一些点，可以参考下：
1、该页所提供的功能逻辑方面有无问题；
2、各输入项的合法性测试、输入顺序；(是否只做了前端的js验证)
3、该页权限，既无访问权限的用户能否直接访问该页；
4、不同浏览器下该页的显示；
5、该页链接的参数是否可以修改，对功能的影响；
7、多个页面打开该页，进行操作，是否有不合法的影响；
8、网络环境异常情况下系统的处理；
9、页面链接是否正确；
10、cookies测试；
❼ vue.js前端自己写死的数据在自己电脑上怎么测
安装一个wamp, 相当于一个虚拟的服务器。软件小，操作简单。方便易用。实在不行 安装HBulid， 这个玩意是个前端开发工具，也自带服务器。
❽ weex前端怎么模拟数据进行接口测试
你的“两头USB接口的数据线”分三种： 如果是U口延长线的话 可以找个能用的U口鼠标接入 使用正常说明该延长线没断 还有U口双公线、U口双母线 便捷检验方法同上 找相应U口成品进行测试 如没有条件 只能用万用表了
❾ 我是怎么搭建前端mock-server的
作者：张云龙
链接：https://www.hu.com/question/35436669/answer/62753889
来源：知乎
着作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
为了更好的分工合作，让前端能在不依赖后端环境的情况下进行开发，其中一种手段就是为前端开发者提供一个web容器，这个本地环境就是 mock server。
要完整运行前端代码，通常并不需要完整的后端环境，我们只要在mock server中实现以下几点就行了：
能渲染模板
实现请求路由映射
数据接口代理到生产或者测试环境
能渲染模板很简单，在mock server中集成模板引擎就行了，然后提供模拟的页面数据用于完整渲染页面，不过有时候生产环境中的模板引擎可能有一些环境依赖的扩展，这个要单独实现。
请求路由映射，实现原理就是要让本地的mock server有一个router，能接收所有HTTP请求，然后在router中根据线上的路由约定，实现一套一样的规则，这个也不难，不赘述了。
最后数据接口代理。与前端相关的HTTP请求一共就3种响应情况：
渲染页面的请求；
静态资源的请求；
获取数据的请求。
由于实现了router，我们把渲染页面的请求在mock server中处理掉，直接输出本地模板的渲染结果；静态资源的请求直接返回文件内容；而把数据请求代理到测试或者生产环境，本地就不用mock了（当然，如果出现新的接口测试环境没有的，可以追加router，在mock server想响应假数据）
画个图总结一下：
补充一些Tips：
由于Mock Server需要具备渲染模板的能力，因此可能需要一种轻量的服务端跨平台server实现方案，如果是java的后端，可以考虑使用jetty，一个1.8M的jar即可；如果是php的后端，可以考虑使用php 5.4以后内置的server，启动命令是 php -S 127.0.0.1:3000 router.php；如果是Nodejs，那就很简单了，估计都不需要Mock Server，本地也可以跑的