前言
来啦老铁！
接之前的三篇文章：
- VSCode 插件开发（一）：Hello World
- VSCode 插件开发（二）：插件开发实践
- VSCode 插件开发（三）：插件打包与本地安装
我于近期应用 VSCode 插件开发的这些知识，正式开始开发一款平时工作中用得上的插件，旨在提升自动化用例编写的效率。
但由于大家用的自动化框架都不一样，脚本的样子也不尽相同，因此这是业务、项目强相关的应用，无法通用，因此仅用于分享想法、思路。
- 代码仓库：https://github.com/dylanz666/speed-up-scripting.git
(已做脱敏处理，修改敏感信息前，无法直接执行完整命令，代码可以用作学习参考用)
主要功能
- scripting.initConfiguration.
- scripting.simplyRenderCase.
- scripting.inheritFromMostSimilarCase.
- scripting.getTopSimilarCases.
- scripting.getAllAutomatedCases.
- scripting.getNotMarkedAsAutomatedCases.
- scripting.replaceKeyInfoForCase.
1. scripting.initConfiguration.
背景：
为了使插件在跨团队、跨周期中保持一定的通用性，因此使用了配置文件，在同一个人使用不同项目时，可以通过初始化这个配置文件，在不同项目中初始化后使用插件。
功能描述：
初始化（或者叫清空）插件的配置信息；
功能截图：
自我评价：
人性化考虑~
2. scripting.simplyRenderCase.
背景：
VSCode 中的代码块功能，无法动态插入内容，比较死板，因此想到解决这个死板问题。
功能描述：
调用 “用例管理平台”（我们公司有这么个平台）的接口填充至固定的用例模板，生成关键信息完整的基础用例。
功能截图：
用例模板：（图中红色箭头标注的地方就是调用 “用例管理平台” 的接口去填充的内容）
自我评价：
发现现有 VSCode 工具上功能的不足，利用代码能力解决该不足之处~
基于上述的与用例管理平台交互并完成内容填充的功能，进一步扩展，可以完成以下功能。
3. scripting.inheritFromMostSimilarCase.
背景：
作为一名测试开发，在日常工作中，编写自动化用例的时候，往往拿到一个用例的时候，不是马上进行编写（有些新功能除外），而是看与哪个用例比较像，找到后将其代码拷贝过来，对照当前的用例描述进行修改，最终完成当前用例的编写。
而看与哪个用例比较像比较费时费力，且找出来的用例不一定是最像的，效果往往不是很好，因此，我研发了这样一个功能，拿将当前要写的用例与已自动化的用例，取用例管理平台上的前置条件、步骤、预期结果等进行文字的相似性比对得到相似性值。当已自动化的用例逐一与当前要写的用例进行相似性比对后，我们最终能够得到一个与当前用例相似性最大的用例编号。
复制这个相似性最大的用例编号的用例，同时修改用例的关键信息为当前用例的关键信息，最终生成当前用例的自动化用例。
功能描述：
从已自动化的用例中寻找与当前用例最像的用例，同时集成了 scripting.simplyRenderCase 方法的部分功能，插入了用例的关键信息，生成的用例脚本更完整也更贴合当前的用例。
功能截图：
自我评价：
有了这个功能，在寻找最相似用例上排除了主观性，使得这个过程足够客观，结果可信度高！
4. scripting.getTopSimilarCases.
背景：
作为一名测试开发，在日常工作中，经常遇到写完一个用例，过一阵子写另一个用例的时候，发现相似性比较高的用例，现在想再写一个类似的用例，要重新理解整个或大部分过程，即：思路断了重来~
因此，我研发了这个功能，使编写用例的人员，在编写用例前，可以使用这个功能，从 “用例管理平台” 上获取与当前用例最接近的 5 个用例，然后在编写用例的时候，我们就可以一次性对几个用例一起规划（不一定是 5 个，因为有时候相似性很低，可能只有 1 个甚至都不适合一起写）。
功能描述：
在编写脚本前（或使用 scripting.inheritFromMostSimilarCase 方法前后），使用本功能查询与当前用例相似性最高的 5 个用例，使得批量规划、编写用例成为可能！
功能截图：
注：用例搜索条件此处未截图。
自我评价：
从测开工作人员的日常工作角度出发，解决了 “碎片的工作内容不容易保证思路连续性” 的问题~
5. scripting.getAllAutomatedCases.
背景：
作为一名测试开发人员，经常会关心（或者被关心）已自动化的用例数量、用例的优先级等、各优先级自动化的数量有多少等，虽然 “用例管理平台” 提供了查询接口和页面，但不够直接，因此研发这样的功能，能够在编写脚本的时候，一键知道结论。
功能描述：
获取本地代码中，已自动化的用例，归类、统计，方便随时得出自动化方面的数据。
功能截图：
自我评价：
能快速得到自动化方面的数据，非常有用~
6. scripting.getNotMarkedAsAutomatedCases.
背景：
作为一名测试开发人员，当我完成脚本后，需要给 QA 人员 review，review 完成后，QA 会在 “用例管理平台” 上标注该用例为已自动化，我通常会再看下是否正确标注，并且通常测试开发人员是写完几个（例如 10 个）才给 QA review，这时候我就要一个一个点开链接去验证，此时比较费劲，还容量遗漏。
因此，我就研发这样一个功能，自动找出本地代码中已经写好的脚本，但 “用例管理平台” 上还未标注为已自动化的脚本，这样不用切应用去校验标记结果，不仅效率提升了，而且还不会遗漏；
功能描述：
自动找出本地代码中已经写好但 “用例管理平台” 上还未标注为已自动化的用例。
功能截图：
自我评价：
重复性的工作交给机器，既省时省力又靠谱~
7. scripting.replaceKeyInfoForCase.
背景：
在写脚本的时候，有时候已经明确可以拷贝哪个用例了，这时候直接复制而不使用插件的功能，但复制后的用例关键信息也还是被复制的用例的，我需要去 “用例管理平台” 上一个一个复制到新用例里头，因此增加这个小功能，能自动获取用例的关键信息，并替换。
功能描述：
自动获取用例的关键信息，并替换当前选中的文本，即替换用例的关键信息。
功能截图：
例如，下图中用例 RCW-1344 为复制 RCW-2660 的用例，高亮部分为用例的关键信息，这些还是 RCW-2660 的，当我只想替换这些关键信息为 RCW-1344 的，我们只需要选中这个关键信息块，然后鼠标右键使用 scripting.replaceKeyInfoForCase 功能，如下：
上图中的 6 个地方均会被动态替换为 “用例管理平台” 上的信息~
自我评价：
功能虽小，还是具有一定的使用场景，不失为一个好的小功能~
以上就是我近期研发的几个辅助脚本编写、辅助日常工作的插件功能，这些功能可以通过鼠标右键或者快捷键触发，简单快速，对我日常工作起到了一定的帮助。
我想，未来可以以此为入口，在日常的工作积累与思考之上，将更多想法与功能集成到插件中，特别是与 “用例管理平台” 交互上十分值得做更多集成，相信这个插件能对我的工作起到越来越多的帮助。
对于这个插件，您有什么想法或建议吗？欢迎在评论区留下宝贵的意见与建议！
能力有限，欢迎指正、互相交流，感谢~
如果本文对您有帮助，麻烦点赞、关注！
感谢~