再看了下正文，发现我说歪了。。。忽略我。。。

一楼是正解。不过我更建议你们 sonar 不要配置成每次构建都跑（代码量大了之后很可能增加的时间更长，研发意见会比较大，而且 sonar 质量阈不通过是不是要阻断部署，这个要和研发达成共识，要不很容易背上影响工作效率的锅），而是独立一个 job 另外做，联动 gitlab push event 自动扫就可以，不要影响研发的正常构建部署。

1、只对增量代码扫描，可以用楼上说的这个方式，但粒度只能到文件粒度，没法到行级别

2、你框里的这个不是指增量代码扫描得出的内容，而是指从某个特定时刻开始，新增的问题。这个是 sonar 内部的一个过滤器，过滤掉这个时刻前的所有问题，只记录这个时刻后的新问题，在 sonar 概念里称为 “新增代码” 。由于 sonar 的理念是只要保障新增代码质量，久而久之整个项目的质量就会上升（老代码只要被重构或者优化就会当做新代码），所以把这个过滤器放到了一个比较显眼的位置。

默认配置这个 “新增代码” 的范围，是以版本号作为起点的，比如版本号 1.0.0 第一次扫描为基线，第二次扫描开始直到版本号变更前的所有扫描，产生的代码变化都会被认为 “新增代码” ，这部分代码产生的问题会被认为是 “新增问题”。

每个项目都可以配置自己的这个 “新增代码” 范围，我们一般配置为从此项目确认开始要求 sonar 代码质量那一天开始，这天前的旧代码问题不追究，这天后新增的都要求符合统一的质量阈要求（比如不能新增阻塞级别的问题等），不符合的就要修。

个人理解：

1、获取这个比例数据，主要是给性能场景设计提供一个相对有效的参考，相对比拍脑袋或者直接都二八原则靠谱。

2、至于说每个小时都不一样这种，实际绝大部分情况下不可能真的每个小时的场景都测试，需要做取舍。你这里列举了 30 天就有 720 个场景，这只是最低效的穷举。一般情况下，业务表现一周是一个周期，工作日和周末会有较大差异，然后性能测试一般只选取高峰期的场景，假设每天都有 2 次高峰期，且周末和工作日高峰期情况差异较大算，那只需要 工作日 2 次高峰期 + 周末 2 次 ，一共 4 个场景就可以了。怎么想办法把穷举的多场景，聪明地通过尽可能少的样本来完成测试，这个本身应该是测试的基本技能，是要最花功夫去思考研究的地方。

3、最后说的线上已经有比例，为何不直接看线上表现作为性能测试结果，主要原因是性能测试场景大部分情况下是为了测试出系统的瓶颈点，线上虽然比例可以参照，但流量绝大部分情况下是不会达到瓶颈点的，所以要测试出系统瓶颈点，就必须要线下做压测才行。当然你做好压测数据隔离后，凌晨直接搞个压测直接压线上也可以，全链路压测由于环境太复杂，基本也都是这么弄的。

最后总结：

楼主的思维有点朝着 1:1 模拟线上情况这个极端走了，场景要穷举全，线上有的都要测试，那自然工作量大且看起来不可能。如楼上所说，多思考，先想清楚你的目标是什么，再去针对性重点解决。应该没有老板给的性能测试目标是穷举线上所有场景的，一般都是挑重点，只要压力最大且出问题损失最大的场景性能能抗住不崩溃，就没问题。

客气了

PS：不要叫我大佬，还没达到大佬水平。

我们兼容性测试做筛选时，基于的不是整体市场份额，而是线上埋点分析得来的用户机型分布。

市场份额看起来很通用，实际和业务匹配度不一定高，比如 3A 游戏和休闲游戏的用户，使用手机的倾向会有比较大的差异。线上机型分布相对靠谱。

想确认下，发版本都得清缓存才能用，"才能用" 指的是才能用新版本，还是才能正常使用？

如果是前者，前面已经提到了，webpack 会给打包出来的资源文件加个 hash 值，浏览器缓存一般是用文件名作为 key 的，文件名变了就不会用缓存而是去服务端拉取。至于 index 则通过加一个告知浏览器不进行缓存的 header 来完成。
网上用 前端 缓存 关键字，搜索到一篇对这个说得比较详细的文章，可以看看：浏览器缓存带来的前端项目更新问题及解决方法

如果是后者，这个就是向下兼容问题了，可以具体说下情况。

开发懒的把代码写的特别规范其实也能提升效率

如果现阶段整个团队是这样的共识，那引入意义不大。静态分析工具原理是词法分析，类似于 idea 常见的各种波浪线提示，过程中也许会发现一些写法不规范引起的、藏得比较深的异常路径 bug（比如最常见的检查做得不够引起空指针），但如果大家觉得只要测试是通过的，这些问题不处理也关系不大的话，那还不到引入的时机。在业务稳定且确认要长期发展，对质量要求更高了也愿意投入更多时间精力去处理一些短期够用长期是大坑的技术债，才适合引入。

另外，引入的时候要注意做下规则筛选，有些 “政治正确” 但实际不会引发问题的规则（比如创建的变量没用）可以先去掉，只保留会引起 bug（如没有有效判空、异常被捕获导致事务回滚无效）的规则。扫描结果逐步得到开发认可后，就可以配合 sonar 提供的质量阈，做到提测前要求扫描并且质量阈结果必须通过。

我看了你各种回复他人评论后，我的总体感受是 “你的这个方案不适合我” ，带有一点否定的感觉。所以我会觉得你想做的是寻求适合自己的解决方案，而不是纯粹听大家说自己的方案。一般看到想了解大家对于某个类型的问题都是怎么解决的，对大家评论的回复主要是表达感谢，然后再是探讨方案其优缺点等细节，甚至整理到正文里进行汇总沉淀，方便更多人了解。

所以基于我的这个理解，给出上面这个把你的被测软件情况说的更详细具体的建议。如果有理解不对的地方，可以回复说明下。

目前看到的首个支持远程音频传输的开源云真机平台，加个精。

或者你可以详细说下你的场景，你要测试的这个 windows 应用是什么形式的，用的什么框架画界面，各个控件可以获取到什么属性？也贴个图说下你的软件界面到底长啥样？只有一张控件树的图没啥意义。

现在看回帖情况，完全通用的方案暂时是没有的，一般都是根据自己产品的架构去选择对应的测试工具，甚至有时候需要开发配合打开相关调试入口。

虽然看帖子名字和正文像是让大家分享交流自己怎么做，但看评论大家分享自己的新的用法后，你的回复基本都是朝着自己是否能用的方向走得，所以你还是把你的情况先说清楚吧。

我看了下，这个 WinAppDriver 是微软官方出的，因为实现了 webdriver 接口，所以说写脚本的时候可以直接用 appium python 库连接调用而已。

里面的 demo 看起来也不是启动手机端的微信程序，而是电脑端的微信。和 appium 的关联也只是借用了它的 python 调用库而已。

查了下 3.10.0 release note ，里面移除了一个本身就即将废弃的 collections 的 Mapping 属性值。

相关 issue ：https://bugs.python.org/issue39674

这个要 pytest 官方适配才能彻底解决，建议你先换个稍微不那么新的 python 版本吧，比如 3.8 之类的。

docker 日志里有一项：Up About a minute (health: starting)

你确认你访问的时候 gitlab 启动完了么？

额，没必要背。我也只是想到哪写到哪。

对这些名词有个大致概念就行，一般是发现提测质量不好或者测试阶段经常返工，才需要开始关注和实施左移的。左移的核心个人理解是尽早发现甚至预防缺陷，避免都积压在测试阶段。

你接触的东西好多，好处是你的广度会很不错，缺点是因为没有持续运用，如果没沉淀好估计过个一年半载你就基本都忘掉了。建议可以多写些文章总结下你做的东西，沉淀一下，也欢迎分享到社区一起交流。

前路还很长，继续加油~

这 5 个阶段感觉有点把平台弄得太末尾了，实际上开始引入时就需要进行弄成平台还是框架形式的选型了。加上现在也有不少开源平台可用，其实平台可以直接作为第一阶段直接用。

另外，你这个只是接口测试工具的发展阶段，接口测试虽然依赖工具但不只是工具吧，还包括测试设计、测试范围等，个人觉得有点不那么严谨？

提测前做的、和质量保障相关的事情，个人理解都是左移。左移是相对于传统的测试主要在测试阶段才开始介入而提的概念。

比如需求评审时能提出更多提高需求质量的意见并推进让产品采纳；技术方案评审时能及时提出一些方案存在的风险缺陷（比如和第三方交互是否有充分可靠的补偿重试机制）并进行修正；代码提交时能通过一些自动检测工具自动发现那些低级的空指针错误；开发提测时可以通过 code review 来了解整体实现细节以及评估是否有风险（比如同时更新两个表有没有用事务避免脏数据等）等等。包括 TDD 、ATDD 这类测试驱动开发的方式个人理解也算是测试左移（比正常测试阶段提前了很多开始进行测试）

每次 build 就触发自动化测试这个是持续集成的概念，目的是及早集成和测试，确认每次提交代码后，软件达到最低限度的质量要求（能编译通过、最基本的测试可以通过）。也算是左移的一部分（正常迭代软件，在建立新分支的时候就开始做持续集成了）

左移其实挺难的，主要相关实践基本都离不开技术实践，对人员要求比较高。团队内有这样能力的人不多的话，安排做测试提效工具可能产出比弄左移要明显不少（而且一般开发水平不是太差的话，前期阶段能发现明显缺陷的概率并不高）。个人建议与其研究这些概念性的东西，还不如去审视下自己现在业务还存在什么问题，有什么合适东西可以去实践解决问题。现在已经是一个精细化的年代，很多实践并不见得都适合自己，按自己需要选择即可。

服务端性能的书比较多，讲服务端测试的好像也有一些，但只是顺带讲，比较少专门讲。

至于故障演练、安全问题、回滚机制这些，暂时没见到有讲这类的书，更建议你去找一些公司的实践案例参考，比如各个公司的技术公众号、MTSC 大会的分享材料等。

有点奇怪，你上面贴的打印日志里，get_locators_or_account 返回的值类型是 tuple 哦？你看下是不是你那时候的代码有问题导致返回的是 tuple 类型？

1、从两次的堆栈看，都不是执行 sendKeys 报的错（），而是 br.__find_element__。你一直去看 send_keys 方向不对。

2、你提供的代码里没有 __find_element__ 的完整实现，无法继续追查定位。如果需要进一步协助，麻烦把这部分源码以及涉及的其他相关函数源码也一并附上来吧。

PS：从你贴上来的代码里，username 这个传给 __find_element__ 的 locator 的值类型是 tuple 而非 string ，而从错误堆栈看这个 locator 是直接传给 self.driver.findElement(By.XPATH, locator) 的。正常 self.driver.findElement(By.XPATH, locator) 这里面的 locator 应该是 string 类型的，值内容就是 xpath 的具体定位路径，你也可以从这个角度去排查下。

好吧，我终于大概理解你这里的顺序意思了。你这个 “排序” 有点混淆，实际你需要的是获取到一对基于同一个 pb 协议的请求包和响应包，然后响应包收到后根据里面自带的序号 + 你本地缓存的发送编号，反推出使用的是哪个 pb 协议，再反序列化出对应的 key value 数据，对吧？

有几个新的疑问：
1、这个和 UDP 有什么关系？你们的网络协议是一个请求包或响应包，只需要用一个 UDP 数据包表示？数据量大的情况不会涉及拆分包？
2、是否有看过开发的网络库是怎么做的，是否可以考虑使用开发已经封装好的网络库来做？pb 我理解只是序列化和反序列化，并且由于本身 pb 的序列化方式是去掉 key 只存 value 的，因此反序列化时如果不知道序列化时用的具体协议，是无法保障正确性的（比如两个协议里都是 3 个字段，且都是 int+str+int 类型，那这同一个数据在这两个协议下进行解析都是不会出错的），一般底层网络库实现时会通过一些自定义序号或者数据位来记录这个包对应的是哪个协议，方便做自动解析，不大可能会采用你现在的这种缓存所有请求数据并按序号倒推这种方式。

几个点没看明白：
1、你需要做的是排序还是什么工作？第一段写的是需要排序，第二段变成了执行回调，没明白之间关联是？
2、你排序的目的是做什么，是为了报告展示好看点还是为了正确整合被拆分的 udp 包？

从思路上，可以考虑在收到全部返回包后再根据服务端返回内容里发送顺序字段进行排序，这样不会额外增加性能测试中的压测机负荷，也不用担心顺序会有错。但如果是有别的需求所以要实时排序，那就要根据具体情况来设计了。

我确认下我的理解，假设 DataProvider 产生 A、B、C 三个账号数据，你是想把执行顺序从：

用例1：A
用例1：B
用例1：C
用例2：A
...

改为

用例1：A
用例2：A
用例3：A
...
用例100: A
用例1：B
用例2：B
...

对吗？

如果是，那其实你要做的并不是数据驱动，而是执行顺序编排。这个可以用 testng.xml 来做。建立 10 个 testsuite，每个 suite 里面都是你那 100 条用例，然后每个 testsuite 里面设定不同的 parameter 对应不同用户，testcase 里面通过 @Parameter 来获取当前 suite 对应的用户信息即可。

如果不是，可以类似上面示例这样说清楚你想要达到的效果？

哈哈，感谢支持！当时还是写了不少单测去测试这个工具类的，因为人工测试太费劲而且也慢。印象中这个类单测的行覆盖率应该有 90% 以上。

没深入了解过这块逻辑，结合个人日常刷新 dns 缓存相关理解：

1、服务器无域名信息则向 DNS 请求获取域名对应 IP。 获取到的 IP 和域名是否保存？保存的话是在内存还是落地？内存的话是多久？
——保存是肯定有保存的，否则不会出现各种刷新本地 dns 缓存的操作。至于是内存还是磁盘里面这个真的不大了解。用 “DNS 缓存” 找到了一篇说得很详细的文章，可以参考下：https://bbs.huaweicloud.com/blogs/109378

2、服务器与被请求域名服务器建立 TCP 链接后，后 TCP 断开。在什么情况下可以让服务器再次向 DNS 请求后再与被请求域名服务器建立 TCP 链接？；
——感觉你是把域名解析和 tcp 连接混在一起了，实际流程是：找到域名关联的 ip 信息（先本地缓存，后找 dns 服务），然后和这个 ip 及端口（http 默认 80，https 默认 443）建立 tcp 连接。所以你这个问题的答案和第一个其实是一样的，只有 dns 本地缓存失效才会去问 dns 服务器

3、问题 2UDP 的情况；
——个人理解和 tcp 也是一样的

4、有没有什么方法可以让每次访问都走 DNS 解析后在发送请求；
——每次都强制清除本地 DNS 缓存即可。不过 DNS 除了本地缓存，还有路由中途各个节点的缓存、地区 DNS 缓存的等很多级缓存的，全部缓存刷新一般需要好几个小时。如果你想要快速更改，要不自己在连接的路由器手动加 DNS 映射关系（一般路由器是最近的节点，而 DNS 查询是只要有一个节点返回了映射关系，就不会继续问下一级节点了），要不直接通过本地 host 文件手动配置固定的映射关系（这个连缓存都不用清，立即生效）。