A. 在pc端写的web前端页面，要转到微信上，怎么样在电脑上测试有没有什么好用的软件呢
Opera Mobile Emulator 模拟手机浏览器，微信页面也是调用微信的内置浏览器
B. 前端写好的代码要在公司内部局域网服务器测试之后才提交后台吗
公司给你svn帐号和密码--->在自己电脑上下载网站代码--->本地开发测试--->通过svn提交--->线上查看
C. 前端使用mqtt之后 如何测试
使用JMeter测试MQTT协议
服务端基于spring-cloud微服务框架,主要提供服务发现,用户管理,权限管理,设备管理,MQTT节点管理等管理功能
D. vue.js前端自己写死的数据在自己电脑上怎么测
安装一个wamp, 相当于一个虚拟的服务器。软件小，操作简单。方便易用。实在不行 安装HBulid， 这个玩意是个前端开发工具，也自带服务器。
E. 请问我是女生现从事Web前端工作，我想转测试类的工作，比如前端测试好转么
你做过前端开发，确实懂技术的测试比较吃香，因为他们无论在自动测试还是性能测试都有很大优势。如果只做功能测试会埋没你的能力
1.写测试用例，这个需要理清产品流程，你做过开发会简单些，然后设计自己测试的方法，以文字形式将所有操作表现出来，要覆盖所有功能点，正常异常等各种操作都要考虑到
2.自动测试相对手工测试来说比较高端，他也属于功能测试。通过脚本或自动测试工具来执行被测程序从而检查功能是否正确实现。自动测试只能检查已经发现的BUG是否重现，或能否正确执行被测程序。通常用以回归测试和重复测试。他不能发现新的BUG。
3.性能测试。这个需要网络知识，代码能力，计算机知识等，如果只是录制脚本运行脚本，那么每个人都能做，主要的是分析瓶颈，相信大多数开发也没这个能力，所以在我的认知里性能是最难的。
4.安全测试，一听肯定需要网络安全方面的知识
5.本地化测试。合格必须需要的是语言能力，然后是功能测试的能力。
其实无论那种测试，都是以功能测试为基础。
其他测试就不一一列举了。如果只做功能测试，除了设计测试用例，其他就是执行测试用例，只要测试用例写的好，谁都能做，这个“谁都能做”是用例写的好的前提。
测试主要是一个覆盖率的问题。虽说不能百分百覆盖所有组合的操作。但是好的测试人员能够更全面的考虑测试方法。
F. APP开发之后该怎么测试
1. UI 测试
app主要核ui与实际设计的效果图是否一致；交互方面的问题建议，可以先与产品经理确认，确认通过后，才开始让开发实施更改或优化
2. 功能测试
根据软件说明或用户需求验证App的各个功能实现，实际测试过程一般都是根据功能测试用例来执行。测试覆盖率基本上都是有测试用例主导，也就是说在功能测试部分，是检验测试用例是否有效以及完整的，也就导致另外一个问题，测试用例怎么写的问题，将另外一篇文章来单独阐述测试用例的编写方法。
3. 中断测试
模拟用户真实使用app是会遇到的中断情况进行测试.如： 网络的断网， 切换网络， 断电，来电话/短信，听音乐，切换到其他app， 打开其他app 的通知等
4. 兼容以及适配测试
新旧版本的在功能，逻辑层面的兼容测试， 同一个app 在不同系统版本运行，以及不同机型之间的适配测试
兼容测试：接口的兼容性测试能够保证大部分的功能完善；app在不同系统版本上保证运行
适配性： 屏幕，系统版本等（系统位数一定要考虑）
该部分通过第三方的云平台进行
5. 性能测试
可测试的方面
- 安装和启动时间
- CPU的占用
- 内存的占用
- 流量的耗用
- 电量的耗用
- 后端,测试App中的各类操作是否满足用户响应时间要求，主要是测试点在网速方面，2g，3g，wifi， 4g一定要覆盖到
- 后端 有网络并发
6. 稳定性测试，压力测试
1.在各种边界压力情况下（如电池、存储、网速等），验证App是否能正确响应
2.反复/长期操作下，系统资源是否占用异常；Android 可是使用adb命令
3.压力测试主要集中在后端，前端的压力测试目前测的较少
7.安全测试
App安全测试大概划分为以下几类：
1)从数据的本地存储到数据的传输、处理以及远程访问等各个环节，基于相应的安全标准/行业标准评估App的安全特性；
2)借鉴在Web App和网络安全测试的一些成功经验在智能终端App测试中进行裁减或适配；
3)检测App的用户授权级别，数据泄漏，非法授权访问等；
4)对App的输入有效性校验、认证、授权、敏感数据存储、数据加密等方面进行检测,以期发现潜在的安全问题；
5)基于各种通信协议或相应的行业安全标准检视App是否满足相应的要求。
8.用户体验测试
这个简单的说就是站在用户的角度上进行使用app，学习成本低，易上手等，可以进行用户盲测，根据用户反馈的意见进行修改。测试人员可以通过与其他竞争品进行对比， 或者根据较大厂商app的交互习惯进行比较。
9. 回归测试--一般这部分建议使用自动化测试， 如果没有自动化测试，可以根据以几方面进行测试
1.根据产品说明书或者功能文档进行功能确认
2.重新将主要优先级较高的测试用例执行一遍
3.重新验证bug
10. 线上测试
线上测试是产品上线之后一定要完成的，这部分可以根据场景化进行回归测试，其中网络环境要全部覆盖一遍
G. 一个前端开发的工作流程是什么样的
我们以前基本的流程是，领导或甲方提出需求，然后产品分析需求，并且根据需求画出原型图，然后根据原型图出设计稿。
出完设计稿团队评审，过后交与前端制作静态页面，然后静态页面，交与设计审核，过后交给开发人员，进行动态数据的添加。
添加完之后，发布测试环境，产品测试领导审核，成功后，直接发布产品环境。或进行版本迭代。
这是整个的一个设计，开发，部署的流程。
根据前面的，在补充一下，前面的所有流程中的灵魂是原始需求提出者，但人随着客观条件的变化，思维认识会有所不一致，
所以产生了文档，文档是贯穿整个流程的一个灵魂。
而产品是整个流程中文档的编写者，因为产品最能接触最原始的需求，对需求的理解更深刻或专业，所以他会有一个文档出来。
这个文档是需要交付给设计，让设计在设计过程中进行参考。
前端看的另外一个文档。交互设计师出交互文档，一般的公司没有交互设计师那就是由产品来出的交互文档。
有的交互不过于复杂，就没有文档，只是邮件。
有时候说，不要这个邮件行不行，那怕是最简单的原始东西，没有文件或邮件是不能做一个后期测试回溯的依据。
产品文档表示页面的流转或数据的走向，交互文档描述页面复杂的交互或各个用户表单与用户发生的各种互动。
另外2个是，要架构师或项目经理出的需求文档，需求文档是对整个项目的历史背景，系统开发软硬件要求，或版本信息，等等。
另外一个是由服务端工程师提供的接口文档，这里边包括一些请求类型，传参的数目与键名，还有服务端返回的参数名约定等等的，这些文档是开发中的灵魂，也是以后测试回溯的标准或依据。
H. 如何进行前端自动化测试
没人邀请，路过回答。
前端测试是前端工程方面的重要分支，有过一些探索，这里简单分享一下。
首先，还是要强调一点：
前端是一种特殊的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的展现问题已经是不小的进步了。
I. 刚进一家公司，这个公司有人专门写前端，我是java写后台，我想问测试的时候怎么搞
自己写个简单的页面，去测试，或者如果是struts可以写action的测试用例的
~~~~~~~~~~
J. 前端中怎样将写好的网页在真机上进行测试
使用grunt+bower+webstorm作为前端开发工具，在开发移动端的时候，怎么才能直接在真机上进行页面调试？
举个例子就是在IDE里写html，手机上也会同步展示。
-------分隔线------
在各位大神的推荐下使用了browser-sync，发现真是神器啊，现在使用grunt-watch + browser-sync 可以实现了实时编译。这里有个前端大牛裙前面是五五二中间是就一二后面是思五五连起来可以了，不是来学习请不要加了
在使用的过程中发现了一个问题，就是使用ip在本机是可以访问的
http://192.168.2.224:3000/src/html/index.html
但是发到手机上就访问不了了
确定是在同一个网段，路由器配置也检查过了。。。实在找不到原因了