我所经历的以及我所理解的敏捷-六-Scrum

换了新东家以来，由于研发模式的差异，对在上一个东家涉及的一些知识暂时无实践机会，其中觉得最遗憾的应该是敏捷相关的知识体系和实践经历。得益于上个东家的信任，有幸参与过公司敏捷团队的教练工作，同时也在公司的安排下参与了ACP培训，这个培训至今仍然是我觉得最有价值的一次培训，虽然涉及技术内容不多，但是却通过敏捷这一条线将自己所涉及的一些技术串联起来。在这一系列学习和实践中，也结合敏捷的思想有一些自己的感悟。在这记录下来，以便后面回过头来参考。其中会大量参考ACP培训的内容，也算是一个学习总结。

敏捷出现的背景

从软件作坊到软件危机，再到软件工程，传统的软件工程理论使得软件系统的开发流程变得越来越复杂，导致：

过长的开发周期 more >>

展开全文 >>

一些感想

2019-01-17

工作

对应开发人员能力不够理想的情况下，自动化测试更凸显其价值。
端到端的自动化测试是下下策，不管是服务拆分还是前后端分离，目标都是把测试目标缩小。
前后端分离之后的前端自动化，可以考虑以图像对比技术为主。
应该开发或者寻找一种技术方案能够快速通过录制回放方式生成一整套后端mock接口，用于前端自动化测试。
数据多了之后才体会到”数字化研发”的含义，数据的意义不仅仅是用于考核，还包括方向引导，决策参考等等。
入职新公司之后先后引入了基于python，基于TypeScript,基于Node，基于JavaScript的各种开源项目，并在上面做了少量二次开发，优秀的开源项目确实让二次开发变得简单，语言完全不是障碍。
对任何技术都心存敬畏之心很多人都做不到，但得时刻提醒自己尽量做到。

生活

重要的人越来越重要。
为人父母之后内心柔软很多，同时也发现情绪管理能力太差。
坚持阅读，尽量让眼界不一样。
期待晚年的“二人世界”，哈哈。

展开全文 >>

Superset提示`fetch data error`

2018-12-24

使用场景

为了应付各种汇报和考核需要，引入轻量级BI工具生成各个维护的视图，在工具选型阶段简单调研了Metabase,Superset以及Knowage(也就是Spago BI)，最后选择Superset是因为自带图表比Metabase酷炫且比Knowage轻量，足以满足当前需求。

问题

由于对数据库不够熟悉，可能是设计不足，数据量大了之后查询结果返回时间过长，导致在视图生成时提示fetch data error,查看后台提示发现是因为查询时间超出了60s的默认超时控制。

解决办法

尝试过通过superset_config.py启动时注入环境变量无效，因此查看镜像的Dockerfile，发现环境变量在其中定义，因此修改重新制作镜像解决，Dockerfile内容如下：
more >>

展开全文 >>

低侵入配置Gradle项目获取单元测试结果

2018-12-17

写在前面

目前公司CI采用的是基于Drone CI的方案，Pipeline的各个Job主要依靠各种Docker镜像支撑。例如拉取代码使用的是官方的插件镜像，编译代码采用在官方镜像基础上的定制镜像等等。随着集团对于代码质量的要求越来越高，对于早该纳入持续集成体系的单元测试工作终于提上了议程。

工作目标

第一步的工作目标是在尽量少侵入各产品线当前正常研发工作的前提下将单元测试的Job集成进当前的持续集成体系中，并能成功收集当前所有后端系统的单元测试现状，后续再根据现状制定相关指标提升计划。

工作难点

公司后端系统大都采用的Java，构建工具统一使用Gradle。市场上对于配置Gradle获取单元测试相关结果的方案已经很成熟了，因此配置并不是这项工作的难点。难点在于工作前提-尽量少侵入各产品线当前正常研发工作的前提下。现有方案大都需要修改项目的build.gradle文件以添加各种插件依赖和task，虽然知道其中原理的我们清楚这并不会对项目自身产生任何影响，但是无奈要求来自于高层，作为严格遵循BDD(Boss Driven Development)的我们来说，必须考虑实现。

工作思路

more >>

展开全文 >>

前端自动化测试中如何平衡稳定性和效率

2018-12-13

不同场景下的前端自动化测试要点以及策略选择

前端自动化测试的应用场景众多，常见的包括自动化冒烟，自动化回归，版本自动化测试以及环境的自动巡检。对于自动化冒烟来说，效率可能需要排在第一位，因为往往自动化冒烟都是集成在pipeline中，pipeline中的节点众多，自动化冒烟很容易成为整条pipeline的运行瓶颈（运行时间过长）。对于自动化回归，版本测试以及环境的自动巡检来说，效率可能并不是第一位，因为往往这部分自动化测试要求的时效性并不高，以自动化回归为例，通常我们会找一台独立的服务器运行，不会影响到测试人员手中的正常工作，主要消耗的是机器资源。

对于策略选择，自动化冒烟以效率为先，因此在自动化冒烟测试的用例选择中需要非常谨慎，对于一些测试预期结果不可控的用例尽量不要加在自动化冒烟测试用例库中，而对于自动化回归，版本测试等使用场景，用例的选择则可以稍微粗放一些，只要选择的自动化测试框架能够帮助我们快速的排错，那么在时间允许的情况下，应该尽可能运行所有的自动化测试用例。环境巡检属于比较特殊的使用场景，稳定性肯定第一位，因为谁都接受不了一堆的误报。而如果效率过低，对于快速发现问题不利，特别对于生产环境的巡检来说，效率的要求也极高，因此对于这种场景，我们应该采取特殊策略对待，尽量在高稳定性的同时保障高效率。

常见的可能影响稳定性和效率的因素

稳定性和效率往往是相悖的，为了解决稳定性的问题，往往就会牺牲效率。最常见的，不确定元素多久才会出现，则在脚本中加入足够长的绝对等待，这对于效率的影响是非常大。还有在前端自动化测试的元素定位上，在自动化测试设计时往往图方便，会直接用浏览器的插件完成元素的定位信息的提取，通常是xpath，这样对于当前的自动化测试实施确实节约了时间，但是xpath的维护性非常差，一个层级的变动可能影响整个定位信息失效，这对于维护的工作量是致命的。还有一些常见的在前端自动化测试中可能影响到脚本运行的原因，例如服务器上的其他服务影响到浏览器的运行，导致运行失败等。

提升前端自动化测试稳定性和效率的常用技巧

减少服务器上其他服务对浏览器的影响

针对这点有三种方案，第一种也是最简单的就是准备一台专门用于你这一个项目的前端自动化测试运行的服务器，不允许运行其他项目；第二种是用docker容器来代替运行服务器，例如常见的selenium grid+docker的方案，容器是一个独立的进程，服务器上的各个进程间都是隔离的，不存在互相影响的情况；第三种是使用无头浏览器。
第一种方案无需介绍，重点介绍第二种和第三种方案：

RF应用selenium grid+docker启动浏览器的关键脚本如下：

即在open browser关键字的第四个参数输入grid_hub服务地址即可，目前部门已经提供了两个hub可供使用：

RF应用无头浏览器的关键脚本如下：

核心脚本为第二行在chrome的启动参数中加上–headless

对于不确定弹框的捕获

所谓不确定弹框，不是指由于环境异常导致的各种弹框（例如网络连接中断，服务器异常等），而是指在不同合理的外部条件下出现的弹框，例如在网速慢的时候，可能会出现的缓冲图标。针对弹框内容的捕获，由于网络条件的不确定性，往往很难捕捉。这个时候就可以借助抓包利器-fiddler。fiddler的rule中设置请求断点，一条一条的发送请求。