核心目标我觉得楼上已经说得比较清晰了，补充一个个人观点：

要用好代码覆盖率，前提是对代码的变更内容以及被测系统有比较高的熟悉度，最好是结合 code review 进行，便于测试人员在熟悉代码的基础上，确认自己有哪些部分的代码还没有运行到，辅助补充用例场景。覆盖率本身最强大的不是这个，而是建立起用例和代码的有效关联关系，作为后面进一步的 基于变更内容推荐所需的回归用例集 的基石。

如果团队对代码熟悉度还不高，还没有深入到技术方案评审 + 开发变更代码 review 的程度，或者周期短时间紧对质量要求没那么高，那其实都不大适合引入覆盖率。容易只解读覆盖率指标，而不去实际看代码，而且还额外增加了熟悉代码的负担。

没太理解这个需求，为啥要作为 fixture 的入参呢？一般用法应该是 fixture 提供参数给用例用，用例提供参数给 fixture 有点反过来了。

如果实在需要这么做，我能想到的方式就是把返回值放到一个自定义的全局变量，fixture 从全局变量里读取。

从 docker 部署截图看，8899 端口原来是 authority-ui 服务监听的，然后 docker 通过端口映射，改为了由 nginx 来监听这个端口，authority-ui 则改为了 80 端口。

你在 nginx 内部有配置好转发规则，让收到的 8899 端口请求，转回给 authority-ui 服务么？

另外，这个部署方式很奇怪，你想让用户通过 8899 端口访问，还是通过 80 访问呢？一般部署应该是 80（http）、443（https）给 nginx ，nginx 再按内部规则把请求转给内部前端或后端服务的。你现在把 80 给了内部的前端服务，nginx 反而监听一个 8899 的自定义端口，有点奇怪。

里面好多问题都不完整，比如 35、请说出这些测试最好由那些人员完成，测试的是什么？ 。

建议发出来之前，多校对下？

不知道。瞎猜和 jmeter 版本有关？

不熟悉 python 的覆盖率方案，帮顶一下。

这种就有点涉及办公室政治了。
1、团队的 leader，日常需要和业务方打好关系，多吃吃饭啥的，普及一下这方面一些基本知识（至少测试环境和线上环境分开下）。至少有问题先反馈给技术去处理，小问题内部解决掉，别啥问题直接怼给最大的领导。
2、如果真闹大，闹到领导那，也叫上你自己的领导过去，和产品那边把问题怼到领导那边的至少同级的，杠到底。角色不对等的话，会天然弱势
3、看清下在这个公司的业务形态下，技术到底是辅助角色还是核心角色。如果技术本身就是辅助角色的话，要获得话语权非常难，而你又比较在意这个的话，建议考虑换个公司，避免老是气到自己。

可以考虑搞个类似 wda 的程序，通过 http 和程序通讯，让程序获取？

ios 不越狱是进入不了系统控制台的，所以能获得的东西也比较有限。你说的这些，通过系统提供给应用调用的 api 反而容易获取。

这个复盘总结很棒，32 个赞！稍微修正一个信息：恒温不是产品角色，他也是开发之一，他对网站代码熟悉度比我高。

其实这个问题，解决效率没那么高的核心点，还是关键细节没有提供齐全，导致无法复现。坦白说确实很难留意到，在 chrome 浏览器 www 是会自动隐藏的，不复制网址都不知道自己用了 www 域名，我自己都没留意到这个点。然后 www 域名是前几个月做域名备案时，监管要求必须有才加的，以前确实都没有提供，也没有人想到会引发问题，还好有同学提供了 url 这个关键信息，这才破了案。

也想借此也提醒一下各位测试同学：

提供足够细节让其他同学得以重现问题，是让问题得到解决非常非常非常（重要的事情重复 3 遍）重要的一环。不管是提缺陷，还是提技术问题，都是一样的。所以，请大家后续建提问帖，或者缺陷单的时候，尽可能把你所知道的能让问题重现的信息都提供一下，便于其他同学重现问题，进而了解到更多的问题细节，给出解决的建议。

是真的测试过不支持么？

我理解浏览器的无头模式，实际还是有运行界面渲染引擎的，只是渲染出来的最终 UI 并没有展示，节省图形资源占用而已。我理解应该普通浏览器怎么写，无头浏览器也是一样的写法。

开发提测质量，应该通过提测标准限制。没达到标准的，直接认为提测不通过，没进入测试阶段，不占用预估的测试时间。
至于开发解决问题能力，这个不用管那么多吧，开发解决不完导致延期，那是开发的责任，也不会怪你测试时间预估不足的。不过阻塞测试的缺陷（比如某个功能入口压根打不开，导致里面的功能无法测试的）一定要强力 push，最迟也得 24 小时内解决，因为这玩意是真切影响测试时间的

然后因为有可能临时被抓开会、处理线上问题之类的，所以估完后多加 10%-20% 的风险时间，这样一般就比较稳了。

一句话回答：不合理。

如果是开发估的时间太长，导致整体周期过长，那应该是项目经理去找开发的 leader 去做二次评估，想办法缩短（包括加人、简化设计、减少缓冲时间等）。这活由测试做，既不专业，又没约束力，还会引起团队之间矛盾，毫无好处。

@pikaqiuabc @Jerry li 你们也试试？

现在 OK 了。

这个问题我觉得还是有需要解决的，既然提供给 www 域名，那就意味着有一定量的用户会走这个域名，那我们的功能就得保障在这个域名进来的用户可以正常使用。

查了下微信官方文档，应该确实就是 redirect_url 域名和审核时授权域名不一致导致。

https://developers.weixin.qq.com/doc/oplatform/Website_App/WeChat_Login/Wechat_Login.html

这个微信登录用的微信号，是微信开放平台上的。我没有这块的账号，你查下这块的配置，看是否支持多域名？
如果不支持，那可能需要改一下我们这块的逻辑，不管用户访问的时候是否带有 www，我们生成的 redirect_url 都要去掉 www。

我试了下，如果从 www.testerhome.com 打开的社区页面，那跳转 url 就会带 www 。如果直接通过 testerhome.com 打开，就没问题。

所以可能和微信后台配置有关。

刚再试了下，我可以正常展示二维码的 url 是：
https://open.weixin.qq.com/connect/qrconnect?appid=wxb202aa632230d47a&redirect_uri=http%3A%2F%2Ftesterhome.com%2Faccount%2Fauth%2Fwechat%2Fcallback&response_type=code&scope=snsapi_login&state=749737529adde28efbfdbca2063563927466fe478cd6e4ff#wechat_redirect

你发的 url 带有 www ，我发的没有。 @Lihuazhang 看下微信那边后台配置，是不是允许的重定向地址里，是不是可以加一下 www 的地址？

清晰不少了。

@pikaqiuabc 你那边可以稳定重现么？如果可以，浏览器版本什么的可以同步下？

我刚才试了下，没法重现。

我的步骤：
1、无痕模式打开 chrome
2、点击登录，再点击【微信登录】
3、手机微信扫描二维码，并在手机弹出的授权窗口里点击 允许

实际结果：
浏览器自动跳转到社区首页，且变为已登录状态

浏览器版本：
Chrome Version 101.0.4951.64 (Official Build) (arm64)

手机微信版本：
iOS 8.0.26

没太看懂，这个架构怎么测配置呢？

具体技能点，不同公司甚至不同团队都不一样，或者说基本上都不是因为你技能值达到所以能做的。

可以换位想一下，如果某一个团队原来的 leader 离职或者晋升上去了，你需要挑一个同学上来，你关注的会是什么？最基本的应该是向上做事比较靠谱（至少你能放心把事情给他，不会掉链子），其次是向下团队大家都比较服他（这个就不解释了吧），最后才会看测试技能（至少不是团队内倒数，不过团队内倒数基本也做不到大家服他）。

所以，核心不是技能值，而是你的办事能力。技能有短板，只要团队里有人能补上就可以。

楼上真相了。

首先，我理解不同的事情上这个地位也是不一样的，比如需求是否可以精简这个事情上，产品经理地位最高；目前质量水平是否达到可上线标准，测试地位最高。不说明场景的话，没啥可比性。

其次，认同 1 楼的观点，地位是争取来的。所以逻辑应该是 测试质量保障能力强 -> 测试团队的价值得到大家认可 -> 测试团队地位高 ，不应该反过来。正文这两个疑问点都是基于测试团队地位高为前提去问质量保障水平，逻辑上反了。

如果公开的活动排不了，那就日常私下多相互交流学习吧。

我的习惯：
1、先通过了解需求内容、技术方案，确认各个部分的优先级以及可能存在的质量风险
2、设计测试策略，包括各个部分重点需要保障什么，除了常规的功能测试是不是还需要其它类型的测试引入（如常见的性能测试、兼容性测试）
3、根据测试策略写用例。先把核心流程的用例写出来（同时也是冒烟用例），然后再按各个模块的优先级扩展异常场景。扩展异常场景过程中会通过边界值、流程分析等方法去弄（实际上也不会说每个都去按着方法逐个弄，已经形成一些思维定式了）
4、通过组内的用例评审，集思广益，补充一些可能存在但编写时遗漏的用例。

对于如何更好地去设计用例，避免遗漏，我的经验是：与其想着用各种分析法，不如多做交流和总结，逐步形成自己的思维定式。建议你们团队内可以试试搞一些活动，活动上大家对同一份需求设计用例，然后各自分享思路，促进一起成长。