直接进入主题，关于https的测试工作，之前没有专门工具化尝试，最初接到这个任务的第一的思路方法，是否直接进行页面源码扫描所有链接，判断是否存在http协议的静态链接即可？答应是否定的，仅通过请求响应码以为会是200，数据内容都可以正常获取，只是在页面中无法正常加载静态资源文件。
在第一个思路被否之后，也考虑通过
浏览器中左上角的不安全提示的截图分析或者获取console里的error信息是不是可以获取。
第一种思路明显，时间成本高，还需进行图片分析，很快被否，可行性差。
第二种思路，看起来还算是个不错的方式，那么通过哪种技术方式获取，就需要调研分析，借鉴之前的UI自动化相关技术及与前端部门同学沟通，最终确认采用phantomjs工具，利用其onConsoleMessage信息即可获取所有console中的error或warning信息。最终快速确认方案可行，并进行工具化展示，方便更多同学使用。
在进行工具实现过程中，发现之前好像又犯了一个低级的错误，浏览器在请求URL时，不会将所有静态链接进行加载渲染，故对页面渲染之后的html源码仍需进行一次http协议URL进行扫描获取，以获取所有非相对协议地址链接。但由于https协议在切换过程中无法确保一次性修复所有链接，包括公司内部符合规范域名，不合规范的三级域名，以及公司外部不支持https协议的连接，所以此步骤只能给用户提示，但非完全错误信息。基于这一点，工具中扩展了对http协议URL的扫描功能。
此外，由于主站较多链接对在已经支持https协议的App端中会大量使用，所以在App端接口的返回数据不可包含相对协议地址出错，故在工具中也添加了对该类型数据的过滤处理，并直接断定为错误信息。
基于以上的分析过程，https切换校验工具的最终方案如下：
1、基于phantomjs的onConsoleMessage方法获取conosle error信息；
2、获取页面请求后的源码，进行静态http链接的过滤获取，并区分公司内合规、不合规、公司外链接，输出给用户作为提示信息；
3、针对App端接口，对其响应结果进行相对协议地址的获取，将错误URL地址输出反馈。
当然，仅靠以上方案并不能保证系统完全没有问题，我们首先需保证的还是原有http协议下所有请求页面的正常访问，本地服务类别可直接使用LTC平台（http://ltc.58corp.com）进行该类型链接的全量或抽样验证。
还有一点，更重要的，我们没有处理交互的测试工具，还是需要进行关键业务的抽测；当然也鼓励大家进行这部分功能的二次封装。
【补充总结以上2个小段】首先保证所有业务在http情况的正常访问，以及覆盖兼容交互类问题的抽样测试覆盖。
最后感谢FE李健、吴鹏丽、周瑜，QA杨雪、闫菲、RD张艳伟同学，运维杨屹同学，特别感谢吴鹏丽同学的大力支持。
附件为phantomjs的实现代码，本地安装phantomjs后就可以进行指定链接的https支持测试了，请在执行前评估执行过程对线上应用的影响。
参考源代码如下：
