点赞，有全局思考后的指导性

好处：

１、 查漏补缺用例：通过分支覆盖率信息，获取测试的盲区，即一直以来没有测试用例覆盖到的地方。理论上这种情况应不多，如果发现大片业务代码未覆盖到，需反思测试过程哪里出了问题。据我们的实践案例，大部分情况下，是比较难摸拟的边界情况或比较偏的路径覆盖不到，此时，依需补充用例。
２、 找到适合组织的测试充分性评价：覆盖率客观数据。通过全遍历用例，得到代码覆盖率数据，如 75%，80%，90%，结合上市实际质量，找到团队做到多少的覆盖率是比合适的，即找到团队的参照值（标准值），为新项目的测试充分性判断找到一个合适的客观数据；
３、 识别可能的废代码。通过分析覆盖率数据，我们可以识别存在的废代码，如一些函数，已没有人调用（明显的代码孤岛）。曾推动开发人员优化掉，但开发人员一般情况不会去删除，原因怕删除后出问题，即使很明显的一些函数，也是觉得放着无误，这也导致越是时间长的项目越无人敢动，经过长时间的累积，代码行越来越多（冗肿），越难读。

不足：

１、 覆盖率高，并不代表质量好，但质量好定是覆盖率高；
２、 覆盖率的计算是单点的（某分支语句是否穿过的统计值），并没有上下文逻辑的串起来的场景数据，这是导致覆盖率高并不代表质量好的主要原因；
３、 分析覆盖率数据需分析代码，需耗测试人员大量时间，投入与产出比并不高；

建议：

找到团队的测试覆盖率标准值（测试充分性客观判断数据）后，有针对性地使用。

白盒测试是要看代码的，如果楼主的被测对像是 java 写的，是必须项，最起码要能看懂。如果之前做黑盒测试转为白盒测试，建议自行先练手，如：开发个 java 小程序，真正去调试，特别是逐行调试，这样程序的运行过程就比较清楚了。
另外，黑盒，白盒都有难度，不存在转白盒就是晋升（个人观点）

哈哈哈，看来一个小习惯，顺手贴了 URL，是找问题的线索起点，必须的啊

理解软件的设计实现，不一定要看代码，建议自已先想想，例如：假设你来实现此功能，在现在的产品平台上，你会如何设计，然后把图画出来，主动找开发人员讲讲你的思路，请教他哪里想得不对，此时，他应会告诉你他实际的设计是怎么样的。当然，如果有设计方案，拿来先看看更好。

#6 楼@CKL 回复很细了，建议补充几点
1、线上出了问题，首先咱们想到的应是客户，判断对客户使用的风险，及如何快速解决客户的问题，如是发补丁版本，还是如何。有些问题还会影响公司的经济效益或声誉，都需考虑。
2、必要时组织团队的复盘会，需求、开发、测试所有相关人员一起思考、复盘（建议可用多嵌套的根因分析法，直到找到根因）
3、找到根因后，讨论解决方案，并严格落地执行，防患未然。无论是开发还是测试的原因，或是都有，一起优化流程或改进方法。
至于一定是测试或是开发的问题，复盘后大家都很清楚的，领导更清楚。重点还是解决问题。

@ 陈恒捷 @ 恒温 用微信访问的问题，昨晚上使用时正常了哦，谢谢！

谢谢，应是没注意。

是网站出了大 bug 么，#8 内容 是我（@ 简一）复的，怎么显示成
@ 何健雄 了呢

分别在浏览器
1、chrome（版本 102.0.5005.63（正式版本）（64 位））
2、edge（版本 104.0.1293.47 (正式版本) (64 位)，Microsoft Edge 是最新版本）
上同样遇到 楼主提到的问题

操作步骤：
1、进入 testerhome 主页，点击"登录"按钮
2、点击 “微信”
结果：
提示 “redirect_uri 参数错误”（不合预期），出错时进入的 URL：https://open.weixin.qq.com/connect/qrconnect?appid=wxb202aa632230d47a&redirect_uri=http%3A%2F%2Fwww.testerhome.com%2Faccount%2Fauth%2Fwechat%2Fcallback&response_type=code&scope=snsapi_login&state=e9776e45704f5b07a3e6df21d0078b93eace06b46f5583b8#wechat_redirect

尝试定位：清除 chrome 中 cookie，重启 chrome，重复操作，但现象同样。

确实没看太明白，
1、楼主提到的测试架构（pytest,unittest）是给谁用的，如果给策划团队使用，是否还需封装成接口，或者提供 UI，然后还有要使用说明。
2、测试架构与配置文件是如何交互的，如何解决现有效率、质量问题的呢

有理论，如果有案例分享会更好理解，例如：“质量把控能力—从用例设计转变为测试策略”，具体指哪些方面的用例设计转变为测试策略，因为正常流程上是拿到需求，与开发、需求同事一起讨论需求，一起理解设计实现，然后设计测试方案（过程中需解决测试策略）问题，即现在条件、环境下，如何测试（如何打仗），什么时修测试哪些用例，哪些暂可以不测，等。

1、分析用户场景，可采用 5W1H 模型展开（理解需求对用户的价值，把握核心操作场景）
2、业务需求细节分析，可用 viso 画图（流程图，IPO 图都可），如业务操作流程（业务流）
3、梳理数据流，需理解软件的设计实现，例如：楼主提到打开 开关，用户是一个点击操作，此时对应软件可能是一个消息，此消息触发后面的代码，此时是否有数据的变化，如把背后的配置文件给改变了；弹窗提示有哪些信息，这些信息内容从哪里读取，如是否增加了字符串，这些字符串来自哪里，如果有多语言，其他语言的显示是否正确？弹窗存在与用户的交互吗，交互的数据，如用户输入后的数据回显，是保存在什么地方呢。
抓住业务操作流、数据流，再以各节点为分支展开分析，可得出可能对系统其他模块的影响（其输入、输出与其他功能的关系）。

这个没有定论，不同公司不同团队需求不同。个人理解测试经理的能力
1、技术上：精通业务（很重要），测试技术上有某方面强项，如测试策略，测试分析与设计，测试开发等都可，有自已擅长的一面
2、结果上：过往业绩优秀，能扛事（做事靠谱）
3、管理上：善沟通，能凝聚团队力量
4、影响力：能服众（有技术精通的一面，其他方面也有懂一些，正能量，抗压等）

这个主要要看当下团队为什么要制定一些开发规范，是想解决哪些问题，测试人员与开发人员整天在一起战斗，需要总结一下，例如：
1、开发发的版本质量不高，过去曾遇到哪些问题，是否要增加开发人员的 smoking test，最好能集成到版本构建中自动执行，等。
2、是否存在开发人员悄悄改代码，导致测试人员漏测情况，如有需要纳入规范
3、增加单元测试，用什么工具，还是自研框架，是否要纳入代码审计中，等都可纳入规范中

楼主坚持不来的原因是什么呢，需要解决一下，如是目标有问题么？（内因），外因太多？其他情况不太清楚楼主的实际情况，不好建议

复测高手的亮点：
1、利用生产端用户真实环境生成的数据造数，
2、录制生产端用户行为回放
3、理念不错

对原来自动化测试（脚本化功能测试用例）是一个改进，但也存在以下问题：
1、真实环境下的数据收集需要时间，及用户量，回归测试此时才开展是否有些晚（因为版本已上线）
2、不太可能代替原来经验设计的用例，因为生产端的用户场景也只能是一部分（重要的一部分）
3、复测高手假定的被测对像需要比较稳定或长久性产品

建议：
1、复测高手除了收集生产数据、用户行为，是否可进行用户大数据分析，导推需求测试，及需求挖掘。
2、是否有成功应用的业务领域，分享一下

“最后还有一点，测试人员的价值体现在什么地方呢？有一篇文档中说的很好，原话我记不太清了，大概意思是：测试人员的价值体现在发现设计和编码人员思维狭隘的地方，帮助他们修正这个期间产生的错误，提出自己的建议，还有提前识别可能的风险和问题，预防缺陷的产生。”
--原话：“软件测试的真正价值并不体现在代码中找出了多少缺陷，而是发现设计和编程人员解决问题方法上的局限、思路中的狭隘和技能方面的不足”，出自 快速算法作者（也是图灵奖获得者）托尼.霍尔

这句话我也想过很久，咱们测试人员要做到，不是那么容易，但确实是有价值，可以作为大家努力的方向。要在这方面有效果，建议：
1、精通业务，这是咱们测试的强项，当开发人员更改的方案未考虑全时，可以给出建议，补充局限；
2、熟悉设计框架，开发的更改一旦不全面（影响分析不足等），例如：开发人员更改了 CBB（平台组件）代码，但未考虑影响哪些产品，可以给出解决方法的影响；
3、常去分析、积累经典 bug 原因，如内存 leak，数组越界，数据精度，数据库读写冲突等，后面工作中遇到同类问题可以快速识别开发人员代码中埋下的坑

比较赞同
@Jerry li 的一些观点，楼主提供的解决方案 估计并没有从根源上解决问题。多语言字符串的管理，是否可以独立出来，如同下图：

此字串需通过转换工具转换成多语言目标文件，前端网页可通过配置或接口调用这些文件中的内容，这样每增加新功能的字串可以直接修改此表，软件的前后端实现逻辑不用改变。降低测试与运维人员成本。具体实现细节@Jerry li 也有提到。

看了楼上大家的回答，据我们曾经的失败与稍有成功的经历，建议如下：
1、与现在的领导（主管）达成一致，有目标及具体计划，并得到支持，如：个别对技术有兴趣的同事，争取一点资源跟你一起做架构的开发（需要你的指导），后面维护的事，他可以帮你，也为这道框架持续下去打下基础
2、根据团队的情况，采用低代码开发测试用例的框架，并把用例转化的工作纳入同事们的 KPI（需领导支持）。前提：你这边作指导，如：带头写一个小模块的用例脚本，并运转起来，让同事们看到效果（好处）
3、主动积极推广：建议主动领某项目的小业务进行功能测试，需与业务同事打成一片，更深入了解他们，为自己的推广及自动化优化工作作好铺垫。（这一点对你来说很重要，也只有这样你才不会偏离方向，技术永远为业务服务才有价值，也为自己争取更多的可能）

让同事们看到效果（好处）,例如通过自动化发现一些业务测试难于发现的问题，并让大家有成长，没有人愿意拒绝成长的，:)

1、首先，不知理解是否正确，应属于 APP 与 SDK 之间交互如何解藕的问题，其实站在任何一方而言，都想在主干上一直往前跑，然后随时可 release 版本。但对于宿主 APP 方，是否清楚 SDK 频繁变更的所有信息，及对自己的影响。如果不清楚，那么肯定被动。此时，看是否自动化一些用到 SDK 调用的场景用例，采用 2-8 原则，把风险业务优先保证，从而提升测试的效率。
2、其次，SDK 的质量，建议组织相关人员一起讨论，总会有一些办法的

1、宿主 APP 与 SDK 之间属于不同代表方（前端应用与中台），相互之间的边界（如 APP 与 SDK 之间的接口）是否清楚，例如，作为中台的 SDK，应提供接口给其他调用者使用，理论上 SDK 方需出具接口测试报告，以示提供的中台软件是有质量保障的
2、当 APP 与 SDK 集成后再验证，是偏业务场景的验证，放在 APP 端会更合适；
3、SDK 频繁升级，升级的内容 APP 是否需要？如果否，与 APP 一起集成的中台 SDK 可以指定版本进行构建，让 SDK 稳定下来

楼主的工作流程很正常，目前的建议
1、如还没有总结的习惯，需马上行动起来，总结主要是养成思考的习惯，去发现问题，包括个人的，项目的，团队的。发现问题，提出问题，进而主动地解决问题。
2、想办法，第 2 次或第 n 次领同类任务时做得更好（更快，质量更好等），可以采取不同的方法或策略，做得更好。
3、向旁边优秀的同事学习，找工作输出的差距，思考为什么？（一个较好的学习方法，优秀同事的测试方案或用例，提交的 bug ，回归 bug 的思路，拿来学习）

我们需要自动化测试，但要有针对性，才能事倍功半，需要考虑的因素，包括但不限于
1、自动化测试的范围，原理上越往下越易，如：单元测试自动化，可老虑与开发结对，开发做好框架，测试设计用例，把正常、异常用例都考虑，相互补充；
2、自动化测试的时机，如果是业务功能自动化测试，需选择业务成熟时，当成回归测试来用
3、自动化测试技术管理，技术框架本身的设计，需要长远看，例如：定义一套接口规则，封装一些公共函数，代码维护原则，相关培训推广，发现的问题管理等一系列问题

1、可以理解楼主的心情
2、展开背调，了解到的有如下场景：1）面试通过，准备录用，但个人情况，如婚姻、学历、其他重要事件，面试官们达不成一致，为进一步求证，公司会进行背调 2）重要岗位，但面试官掌握的信息不太够或存疑，为稳妥，展开背调
3、背调一般会找原公司的领导或同事回答问题