工具使用

火狐浏览器新建标签总是在当前打开标签之后，而不是在最后一个标签后新建。 1.about:config 2.browser.tabs.insertAfterCurrent设为false。 新标签中打开书签 browser.tabs.loadBookmarksInTabs设置true。 新标签中打开搜索 browser.search.openintab设置true.

vscode远程开发 vscode远程开发功能在2019年5月份发布，到现在已经有一年半的时间了，但是周围的人很少提及此功能，并不是没有人使用vscode，而是对此没有强烈需求。 那么远程开发还有什么用呢？下面我来举些列子。 关于vscode远程环境搭建本文不重复说明，网上有大量教程，大家只需要安装remote development插件基本都可以使用起来。 远程开发，顾名思义就是连接远端服务器进行开发，这样的场景确实不是很常见，但是有时候却是很有用，能够解决燃眉之急。 本地主机性能差 有一些大型项目对电脑的要求也较高，编译耗时，跑起来吃内存，我们的常规解决方案是升级电脑内存，升级硬盘，总之就是换高配电脑，如果是换一台也倒罢了，如果是一个团队都要使用更高配的电脑，那这样的成本还是挺高的。 此时利用远程开发功能，所有人共用一台8核16G服务器就足够了。能够解决编译耗时，吃内存等问题。 开发环境统一 现代大多数应用服务是跑在Linux上的，而开发环境则有Windows，Mac，有些服务在开发环境下无法顺利跑起来，这种情况就可以利用远程开发，不再需要虚拟机或WSL了，在Linux上部署应用，在Windows上开发。 远程调试 远程调试我想很多人都有过这样的需求，但是却从来没有过真正的实践，原因是太难搞了。线上出问题，本地无法复现，真希望能够直接调试线上代码，但是无奈无法实现。现在好了，有了vscode远程开发，调试就变得容易了。 远程编辑文件 在Linux上编辑文件时使用的vim编辑器对大多数人来说有些头大，能在vscode中编辑文本就舒服多了。只需要使用vscode连接远程服务可以很方便打开文件并编辑。 在家临时远程开发 作为开发的我们，每天下班都要背着电脑回家，主要原因就是防止线上有问题，能够打开电脑调试代码。一般来说并不是家里没有电脑，而是没有能够正常运行的开发环境。 而远程开发正好能解决该问题，我们需要的仅仅是一台装有vscode的普通电脑即可，不需要再操心开发环境，各种SDK，C++，Python，Nodejs等等八辈子不用的软件装了一大堆，还需要经常更新才行。 节省成本 大多数开发人员是不需要经常开发大型项目和远程调试代码的，但是不是完全没有，这样就需要为了不时之需而配置笔记本电脑，而笔记本电脑一般相对台式机是又贵性能还低，公司要为了应对偶发情况而给开发人员配备笔记本电脑，会造成资源浪费，成本升高。 如果有了远程开发环境，则能应对临时性工作，大大降低成本。 用iPad写代码 如果你觉得vscode远程开发还不够酷？那在iPad中写代码呢？ vscode远程开发虽好，但还有有局限性，毕竟还是需要一台可以安装vscode的电脑，还是不能随时随地的写代码。现在我要告诉你如何在iPad中写代码！ code-server是一个可以运行在服务器上的web项目，这下我们可以在浏览器中使用vscode了，可以在浏览器中打开vscode的，自然就可以使用iPad来写代码了。 Eclipse Theia https://gitpod.io/#https://github.com/eclipse-theia/theia 额，希望苹果能给我广告费！ 再或者使用使用codespaces也可以在线编辑代码，https://mp.weixin.qq.com/s/Eutjgbx_nofmuhU2yBGhxg 最后 贴一篇带图的环境搭建教程真香！使用 VSCode 远程开发调试

MySQL常用的客户端是Navicat，SQLyog等，本文推荐另一款通用的客户端：DBeaver DBeaver不能创建表？那是因为选错了视图。可以重新编辑链接

puppeteer要模拟3G，4G网络需要利用DevTools Protocol。 Chrome DevTools Protocol page = await browser.newPage(); // 模拟3g网络 let cdp = await page.target().createCDPSession(); await cdp.send('Network.emulateNetworkConditions', { 'offline': false, 'downloadThroughput': 600 * 1024,//(bytes/sec) 3G最高600K/s 4G 最高10M/s 'uploadThroughput': 600 * 1024,//(bytes/sec) 'latency': 0 }); await page.setCacheEnabled(false); await page.goto(url);

postman是开发人员必备的接口测试工具，虽然经常使用，但是并不会使用到所有功能，除了简单的接口测试外，它还有很多实用的功能，如果充分利用起来，能使我们的工作事半功倍。 环境变量的使用 捕获请求和cookie 收藏接口与分享接口 批量测试 编写文档和示例 环境变量的使用 环境变量的作用是使用切换变量的方式代替频繁的环境修改。这样我们只需保存一次测试接口就可以在不同环境下使用。 举例： 环境变量配置 环境变量使用 环境变量切换 捕获请求和cookie 能够直接将浏览器中的请求和cookie同步到postman，省去手动复制请求接口和cookie到postman中。 同时，对于需要登录后使用的接口，postman可以直接使用浏览器的登录状态，而不必复制cookie。 举例： 收藏接口与分享接口 将自己保存的接口分享与他人，直接拿来即可使用。 如果安装了Chrome插件，则可以直接的浏览器中打开链接。使用客户端需要使用import来导入。 批量测试 保存的多个接口批量测试。 编写文档和示例 对于团队协作很有用，接口交流利器。不仅有了请求参数，添加一个example还可以看到接口返回参数。

Nodejs项目部署到服务器以后接下来做的最多的操作就是上线发布了。因为nodejs的语言特性决定了其开发效率高，发布自然就频繁，每个公司或个人都有自己的发布方式。 有的公司会有严格的流程，必须通过CI/CD工具进行发布，有可能使用现成的工具，如：jenkins。有可能是自研发布系统。 有的公司会通过FTP上传代码到服务器发布。 有的公司使用更原始的发布方式，直接登录服务拉代码发布。 不论哪种发布方式都有其优缺点，越高级的工具会有诸多限制，比如有权限控制，有严格的审批流程，自然就不能随时发布，也就越僵化。越原始的方式越简单越灵活，自然风险也越高。 至于采用哪种发布方式，依据需要选择即可。 而关于nodejs的发布方式，本人也是也是多种方式都有使用，公司项目也经历过多次变迁。公司最开始是直接登录服务器拉代码发布，后来有了运维团队，领导说开发自己发布不安全，于是就由运维搭建了Jenkins环境来发布，但是每次发布都需要走流程，后来因为发布太频繁，每1-2天要发布一次，又要灰度发布，运维也会觉得烦。于是开发就搭建了某个发布系统自己来发布，不过这个发布系统有个缺点，就是发布集群的时候是串行的，每次发布要十几分钟。 另外说明一下Jenkins。它应该是使用最多的发布系统了，Jenkins基于Java开发，它已经是成熟的系统了，成熟同时也代表着复杂，复杂代表修改困难，我想大家也不太会基于Jenkins定制开发。 然后是部署困难，相比较nodejs三条命令搞定linux安装nodejs——快捷版，go直接放二进制文件部署，Jenkins部署可能就略显复杂了。 于是下定决心自己开发一个发布系统，朱雀发布系统因此诞生。 基于以往的发布系统使用经历，我想要的是一款使用够灵活，部署够简单的发布系统。市面上现有的系统为了满足各种语言的发布，做的大而全。我自然是不想重蹈覆辙再做一个大而全的系统，我要的是小而美。正好之前了解过PM2本身集成了远程发布功能，可以在此基础上开发。PM2本身的发布过程其实已经很简单了，而且足够灵活，能够满足我的部分要求，但是公司的环境是不能在本地直接连接应用服务器的，所以需要一个中间层代理一下，放一张简单的架构图： 和其他工具架构逻辑一样，都是通过ssh来通信，不同的是朱雀没有直接使用ssh，而是利用了pm2,由pm2来实现通信，它已经为了做了一部分工作，比如拉代码，回滚，执行远程脚本。 由于nodejs的项目特性，它依赖了node_modules包，如果按照打包的方式发布会又大又费时，所以还是选择拉git代码的方式发布比较合适。 所以我只需要给它做一个图形界面，并有一定的管理和审批流程（可根据环境跳过）。 放一张图来看一下： 项目地址：nodejs发布系统 朱雀发布系统支持scp（rsync）发布

为什么需要UI自动化？ 说起自动化，听着很厉害，可是也没见识过到底多厉害，基本是属于传说，没见过实战。但不能否认其价值，作者本人作为一个开发者也是偶然的机会接触到UI自动化，感受到了自动化的魅力，才不惜花时间来学习并使用在实际工作中。下面就来说一下为什么要做自动化。 自动化有很多种，单元测试，接口测试，UI测试。所有测试过程可以形成这样一个金字塔： （图片来自网络） （图片来自网络） 从图中看出底层测试简单快速，每个单元相对独立，测试成本也较低。而最顶层的UI层聚合了底层的很多接口服务，一个测试流程相对更长更复杂，也就导致了速度慢，成本高的问题。如果由人工来完成，一个完整的测试流程往往需要几分钟，而且是不停的重复这样一个流程。所以很多开发都不愿意完整的测试自己所开发的一套业务，只能由测试人员不厌其烦的循环往复。此时如果有自动化的话就非常nice了。口说无凭，一图胜千言： 是不是还没看清？没错，平时人工测试一个报名表单需要15秒左右，而自动化后几乎一瞬间即可完成，速度提升不言而喻。如果您对UI自动化已产生兴趣，请继续往下看。 哪些场景可以UI自动化？ UI自动化的目的不是为了自动化而自动化，也并不能覆盖所有测试。还是以测试金字塔来说明： UI自动化虽然只能覆盖到约10%，但其价值却不可忽略，因为越往顶层消耗的人力成本越高，如果底层测试不够充分就只能靠顶层测试来保证。自动化虽好，但需要满足特定的场景才行，那么什么样的场景可以做UI自动化？ 流程变化少。侧重UI的修改，而不是流程的修改。 频繁的回归测试。比如一个报名表单样式修改比较频繁，需要测试其报名是否可用。 界面稳定。样式可以频繁修改，但表单顺序和个数变化较少不能频繁变更。 维护周期长。如果只是使用一次那也不必自动化了，毕竟自动化是解决重复劳动。 开发与测试可相互配合。自动化需要程序有一定规范便于测试人员写测试程序。 测试人员具备编程能力。 如果满足了上述的场景，那么UI自动化在人力消耗和效率上就有很大的提升。正确性上更有保证，手工录入会有输错重输的情况，而自动化则不会出现。 再看一个流程比较长的页面： 上面动图并没与快进，一气呵成完成了一次下单流程，基本不需要停留即可进入下一步，相比起手动操作省时省力。 为什么UI自动化普及率低？ 既然UI自动化能提高效率，但为什么却很少有人去使用？ 开发自动化程序对测试人员的编程水平有一定要求，很少有人愿意花时间去写这个程序。 对于互联网公司，大多数业务需要快速迭代，一个页面的生存周期很短，也可能只是一次性的，自动化测试没有存在的必要性。 测试人员没有切实的感受到效率提升。 其实说白了，就是大家觉得投入和产出不值得。如果是迫于领导压力要写自动化程序，就会不停的对程序修修补补，自己用的话有问题大不了不用自动化，手动测试一下通过就行，如果是给别人用就会不停收到反馈和吐槽，自然也就没有写下去的动力了。 所以个人觉得，自动化程序不应该成为一种流程和形式，而是应该由开发和测试人员自发的去将自身经常重复的工作做成自动化。因为自动化本身就不能覆盖所有场景，只有实际参与的人才能知道哪些是可以自动化的。 有哪些工具可以选择？ 目前市场上不仅提供了多种工具可以选择，还支持不同语言。 web端：selenium、webdriver、robotframework、puppeteer等。 APP端：Appium、Instrumentation、Robotium 、UIAutomator、Espresso、Calabash、Selendroid、Robolectric、RoboSpock、Cafe、Athrun等。 移动APP自动化测试框架 本文不对所有工具一一详解，可自行根据平台选择合适的工具和语言进行学习使用。只针对个别WEB端工具做简单说明。 拿selenium来说，selenium是一款很多人比较熟悉的工具，支持的语言有Python，Java，JavaScript等，推荐使用Python。而且其支持的浏览器也很全面： Google Chrome Internet Explorer 7, 8, 9, 10, 11 Firefox Safari Opera HtmlUnit phantomjs Android iOS 一些常见问题 在自动化过程中最多的就是对元素进行定位，自动化工具常见的定位符有： id name class name tag link text partial link text xpath css selector 以上这些元素定位对于以前的网页来说还足以应对，因为以前开发的网页大多数元素会有id，class这些属性，定位起来也比较方便。但是对于react，vue，angular这类数据驱动的框架就不那么友好了。 比如有这么一个元素：<div>{{element}}</div>结果为： 这个元素既没有id，也没有class，而且是使用最多的div元素，想要定位就很困难了。 而且这些元素定位支持也比较简单，不支持一些兄弟元素，父子元素的定位，我们以往使用的jquery选择器是不支持的。 所以这时候就体现出开发和测试配合的重要性了，开发测试不分家，开发需要根据测试需要的来对重要元素加明确的标识便于测试定位。 其次就是让自动化工具支持jquery，使用一些jquery的选择器来操作元素，使用方式是自动添加一个<script src="jquery"></script>标签。然后执行js脚本来实现jquery选择器。

新买的windows笔记本一般会对磁盘进行分区，虽然有说法是现代电脑没必要分区，不过目前很多人还是有这样的习惯。 然而我们往往低估了软件的吃磁盘能力，会把C盘设置50G左右的大小，觉得C盘只是装个系统而已，会自觉把软件装到其他盘下，结果就是没用几个月C盘就满了。其实，虽然我们把软件装到了其他盘，但是软件本身会下载很多内容，比如数据保存，缓存，默认下载等等都会占用C盘。所以建议C盘设置100G比较合理。 关于已经分配好大小的磁盘也可以进行调整，需要借助一些软件来操作，本文作者使用的是Diskgenius。 很简单的三个步骤： 选择需要扩容的磁盘右击“扩容分区” 选择缩容的磁盘，用于将缩容的磁盘分配给C盘。 选择需要缩容的大小。 确认开始大约需要十几分钟就可以了。

上一篇写到了如何在docker中运行nodejs，运行方式是在docker中安装了pm2来保证node服务宕机重启，这种方式更像是把docker当做虚拟机来使用。其实，既然使用了docker的话就可以不使用pm2来管理进程，因为docker自身可以充当守护进程，在node进程退出时进行重启。只要在启动docker容器时加上–restart=always参数即可。例如：docker run -d --restart=always -p 3000:3000 mynode:1 没有pm2如何开启多进程 使用pm2可以开启多node进程，并且自带负载均衡，但是有个限制，pm2可以开启的进程数是CPU最大核心数。而使用docker的话就不会受限于此了，开启几十个上百个node服务都可以，然后通过nginx实现负载均衡。不过要手动开启几十上百个docker容器那怎么行？让我手动开启3个都很烦了，这时候就需要用到docker编排工具了，比如：Docker Swarm、Kubernetes、docker compose等，可以一键开启多个容器。但是使用编排工具启动docker端口就不确定了，是由编排工具随机开启服务端口的，这又要做到服务注册发现，所以这些工具结合起来使用。 哪一种部署方式支持并发高？ 使用jmeter在本机上进行了简单的并发测试，服务端进行简单的10万次hash计算，使用pm2开启4个实例，docker开启5个实例。docker使用Nginx做负载均衡，单次访问响应时间在1.2s~1.4s之间不等，在200个并发的情况下，两种模式响应时间相差不大，docker模式响应时间略占优势，大概快了0.1s。当并发数在300以上时两者的响应时间都有增加，此时docker部署方式出现了响应失败的情况，pm2就比较稳定了，虽然响应时间增加，但是并未出现过响应失败。 所以在单机上低并发docker还是有点优势，如果在高并发情况下还是pm2更稳定一些。（以上测试是单机上进行，准确性并不高）

从火狐量子浏览器开始，pocket按钮集成到了地址栏右侧， 如果你找不到，那么有可能是在浏览器配置中关闭了，开启方式： 地址栏中输入about:config,点击“我了解风险”继续，搜索“pocket.enabled”，如果是false双击修改为true就会出现。 其他情况可参考：https://help.getpocket.com/article/942-where-is-the-pocket-button-in-firefox