没有完善，因为有些图片是内网的，涉及敏感，后面看看找个替代的图片上来，所以目前的图片是看不到的。
如何保证重前端交互性产品质量
投稿规则：实践案例需具备一定影响力，包括但不限于工具平台、流程机制、管理模式、研发质量、系统架构、工程算法等领域，通过提升研发人力及IT资源效率，以实现业务加速发展，稿件中需附以图文数据说明成果。 结构建议：可遵循专业、案例落地实践的原则，案例需要
从案例背景、目标、解决方案、解决了什么问题、前后对比分析、案例启示、案例对组织的价值意义等多个维度进行结构化提炼， 从而达到让读者或听者受益的目的
行文流畅，文字通畅连贯，有明确章节段落划分，
主线逻辑脉络清晰，文字简介精炼，直入主题不要有太多铺垫，
多讲实践少讲理论。
图文并茂，有相应的系统截图，数据效果，架构图，代码片段等辅助案例说明，图片要求原创高清，避免网络截图（版权风险）。
无字数要求，要把实践案例表述清楚，配有提效成果图文说明。
背景
京东调研是一个重前端，轻后端的产品。对 C 端有感知的有三个 web 工程：问卷设计、问卷答题、问卷管理。特别是前面 2 个工程有问卷逻辑跳转、问卷逻辑显示，选择题引用等，在用户交互方面异常的复杂，因此需要测试点的颇多，每次上线都是心惊胆战。
#todo 贴上设计端的交互图
过程
在这个过程中，主要做了 2 个动作。一个是自动化、一个是checklist，来提升产品的质量和效率。
每一次上线，都有大部分的重复的「点点点」工作，比如创建问卷、设置问卷、答卷、提交问卷，需要在测试、预发、灰度、全量 4 个环境重复的执行一次或者多次。
因此我和大部分人一样，想到的是构建UI自动化来完善回归测试，同时也可以用来做日常的冒烟测试等。最开始采用的 selenium，使用了一段时间，发现有几个问题：不稳定、也有很多场景还是需要手动干预。所以在自动化方面需要考虑如下场景：
- 元素变化太快，定位元素不稳定，导致脚本运行失败
- 对于有太多的内容需要检查，大部分元素都需要定位检查
- 多次重复校验，测试、预发、灰度、全量都是重复的操作
除了自动化，在日常的测试过程，第一次没有考虑周全的测试点，第二次遇到对应的问题还是会遗忘。好记性不如烂笔头，做了一个Checklist，包含了一些易忘问题点，常规必检查点，每次有新需求或者上线，都对照避免忘掉。
- 问题发生了，才会记录到checklist
- Checklist只有针对测试人员，其他产品、开发没有受益
- 需求变更，运营、产品、开发、测试理解不一致
解决方案
在首次的自动化实现和改进措施中，也发现的一些问题，随后再次做了一些优化，提升效率，实现业务的加快发展。
自动化方面
元素变化太快，定位元素不稳定，导致脚本运行失败
在增加定位元素健壮性方面，可以从获取相对唯一的定位、重试机制、playwright库的自带函数方面入手。
上面提到了，自己的开始用的公司自研工具，用的是 selenium (# todo待确认)。对比一下 webDriver、puppeteer、playwright，最后选择了微软的 playwright，支持多种浏览器，支持多种开发语言。
对于 webUI 自动化，根据业务的需求，大部分实现方式是维护元素定位表，然后用元素对应的动作来完成测试工作。 playwright 是原生的Nodejs库，对更好的支持前端测试。对于元素定位提供多种 selector定位，常用的有text、css、xpath、n-th。
可以使用xpath或者css selector定位。但是对于重复的定位可以使用 lambda 函数获取一个封装好的 element 集合。
# 获取所有基础题型的的 element 集合
(lazy element 代码 )
比如在创建在创建题目的时候，就分为基础题型和题型控件，只需要获取到这 2 个里面的所有element，然后通过遍历来操作每一个元素。
(图片：获取到的lazy element 对象)
以及在定位易出错的地方加上重试机制，增加脚本的健壮性，比如登录京东账号、设置问卷页面某一个值等。
# 注释
重试机制 while ...break
在增加健壮性方面，除了重试机制外，还可以引用playwright库自带的expect_navigation，配合python自带的with函数，就非常的方便，比如在问卷下一步、下一页等涉及到网址或者view将要发生变化的地方都可以使用。
# 编辑完问卷，点击下一页设置问卷投放参数
code
对于有太多的内容需要检查，大部分元素都需要定位检查
问卷编辑端，创建大量的题型后，需要对每一种题型的设置进行比对，包括标题、题号、描述、选项等。
除了编辑端，还有一个重要答题端每个题型的排版，包括字号、边距、选项框大小等都需要校验。
注：前端工程是vue，需要把编译打包后的静态文件同到web工程，然后在编译成war包，部署到docker里面。从提交的静态文件是没法查看Diff，曾经有vue版本不同导致，编辑的问卷用不了。欢迎有相关经验的一起交流学习，谢谢。
在大量对比元素内容，引入了图片对比。思路是第一次运行的时候生成一张参考图，然后第二次之后获取问卷，然后截图，和参考图片进行，实现的方法参考的pixelmatch，然后每次保存差异图片。只需要查看差异图片就知道问题出在什么地方。
# 比对图片
code
图片效果图
(todo 放图片对比图)
多次重复校验，测试、预发、灰度、全量都是重复的操作
通过 pytest 自带的hook方法pytest_addoption，在命令行添加一个--env参数，传入不同值的，就可以在不同的环境运行。
由于不同环境，鉴权方式也不完全一致，在使用鉴权账号的地方做差异化处理。 (在不同环境有没有可能获取一个万能的鉴权账号，目前没有得到一个答案，希望大家一起交流。)
# 命令行对不同环境做差异化处理
code
# 工具env的不同，使用不同的鉴权账号
这样就可以在不同环境，用不同账号鉴权，来进行回归测试验证。同时有可能每一个用例需要运行多次，保证运行速度，把共用的功能和耗时的操作，提出来只需要执行一次或者减少运行时间。比如重复登录，可以把缓存保存到本地，只要缓存有效就不继续登录。
# 保存缓存到本地文件
code
# 加载缓存文件
code
复盘
除了从自动化方面入手外，还可以从其他方面入手，一定是保证质量的前提下，提高效率。
问题发生了，才会记录到checklist； Checklist只有针对测试人员，其他相关人员产品、开发没有受益
这样其实问题是发生了才去做的动作，希望在发生之前就被扼杀掉。做了一个线上问题汇总，对于这个汇总，主要是测试和开发需要沉淀的内容。不管遇到什么问题，问题的大小严重性，都记录下来，只有直面问题，问题才会被解决，总有一些收获和沉淀。
(todo 问题汇总截图)
比如在xx(todo)案例中，复盘的结果是测试需要做xxx，开发也需要xxx，这个就是收获，这个就是沉淀，也保证了产品质量，提升了编码质量，以及提高整体的质量意识，从瀑布开发模式转入敏捷模式，再到DevOps模式，从而提高多人、多团队的协同工作效率。
需求变更，运营、产品、开发、测试理解不一致
对于需求变更，也做一个需求变更列表，从BRD到PRD，以及最后的成品或多或少有一定的出入。
(todo 需求变更列表截图)
为了减少需求频繁的变更，影响工作效率，同时阶段性和产品、运营、业务同步进度，提供demo体验等活动，来提高效率。
效果
以提升效率，节约资源，以实现业务加速发展为根基，从自动化、checklist、问题汇总复盘出发。一段时间的执行，效率明显有改善，从上线周期、自动化回归时间、问题数量等方面一一展示。
上线频率降低 50%
每次上线有大量重复的工作需要去做，曾经做过一次上线时间统计，就是每个时间段用时统计。发现有大部分时间会花在合并代码、比对代码、编译、上线隔离(todo 补充其他)等。
(todo 耗时统计 5月一次上线统计截图)
除了紧急上线外，其他改为从每周 2 次改为每周 1 次，冗余工作就需要每周一次即可，效率间接提升接近 50%。
(todo 已完成上线截图)
自动化回归测试，效率提升 xx (todo)
在自动化回归测试中效果最明显，也最直接的就是图片对比。之前从创建问卷到完成问卷元素布局校验，手动完成大概需要时间(这里涉及到主观预估，是一个概数，浮动 10%)：
- 创建问卷：4~5 分钟(复杂问卷耗时 5 分钟+)
- 审核以及作答问卷：5~6 分钟
注：问卷类型 7 种，包括普通问卷、定向问卷、精准问卷、智能测款问卷、NPS问卷、第三方问卷、防伪溯源
这里假设取中位数，完成校验大概是 10 分钟。从测试 -> 预发 -> 灰度(部分回归) -> 全量(部分回归)环境，部分回归折算 50% 的工作量，总需要 10*(4-1) = 30分钟。
在自动化回归测试中，最耗时的就是图片对比的计算，其他创建、作答等执行时间差别不大，这里取普通问卷作为参考，完成总需要耗时 xx*4 = 分钟(todo)。
(todo 耗时截图)
从手动到自动化回归，从 30 分钟到 xx 分钟，总体执行时间降低 xx (todo)分账号，效率提升 xx(todo)
质量提升数据
(todo 有数据这部分有要，没有就移掉)
提交的代码通过sonar扫描，就不规范代码增加为 0。
(todo sonar截图)
上线回滚率，和重复申请上线率降低到 (todo 到jdos截图，从多少次到多少)。
BUG发现率： (todo 从时间周期维度来取(jira和jagile对比)，执行前后对比，bug数量下降率)
(todo 图片)
小结
在保证产品质量的前提下，记录工作中遇到的问题点，也就是结合业务痛点，展开的自动化回归、复盘等活动，来提高效率，节省资源，加快业务的快速发展。
我在这里抛砖引玉，标题是保证重前端交互性产品质量，也希望和志同道合的同事乃至同行一起交流学习，来为提高质量、提高效率出谋划策。其实不管是前端、后端、还是算法等，要找到提高效率的本质方法，用自研工具、脚本、自动化等，都可以做到降低时间，万变不离其宗。
还有一点也是至关重要，减少不切实际的动作，比如在框架、平台纠结许久，还有类似「一顿操作猛如虎，仔细一看原地杵」的动作。这里不管是自建轮子、引用工具，亦或二次改造，找到适合当前项目的方法和策略才是重点。
如果有可能后续也把这些自己这些鄙见，应用到组内或者公司的其他项目，希望激起一点涟漪，带来实质的收益。
