不熟悉 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、通过组内的用例评审，集思广益，补充一些可能存在但编写时遗漏的用例。

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

这个就看实际情况了，如果大家能力够，且觉得写代码效率还可以，那就写代码呗。否则可能引入 itest 会好一些，能避免写代码规范不一造成的额外理解成本。

至于造数据要用 UI 自动化这个，可以考虑把准备数据和接口测试解耦一下。准备数据搞个凌晨的定时任务自动造好（具体每个场景造多少个，可以根据实际情况自行评估下）并记录相关信息（如账号 id）到某个数据库表里，接口自动化直接从里面拿，并标记是否已使用。

极客时间 52 讲里，也有提过这种方式，详细的可以参照下这部分内容。

木有这样的设备，无法解答。。。

建议先把 appium 日志发上来？只有个 loading 截图，我们知道的信息并不比你多，所以也没办法提出什么建议。

不加精对不起这么详尽的一个问题排查记录

有点没太明白，为何会需要选择和排除其中一些方案呢？

如果是设计框架，想要通用性尽量强，那 4 个都得支持。
如果是业务项目的测试方案制定，那正常需求里就明确了需要支持的用户场景是什么，对应选择测试就行。

这 4 个场景，个人理解核心的差异：

1、web 打开和手机打开：内核的少许差异带来的渲染或特殊 api 调用差异 + 屏幕大小差异带来的布局改变 + 触屏和鼠标/键盘交互的差异（比如按钮要大一些之类的）。布局差异一般是大头，不过随着响应式布局的流行，不大复杂的网页一般都可以自动适配。

2、手机浏览器打开和 app webview 打开（你可以理解为 3 里面的套壳）：内核的少许差异带来的渲染或特殊 api 调用差异（webview 用的内核一般是系统自带/app 自带，和手机浏览器自带的内核一般会有一些差异，但因为总体 h5 标准还是比较清晰的，所以差异一般不至于很大）+ app 额外提供的 api 差异（比如有的网页为何要求必须微信打开，就是因为要调用微信的特定 api ，比如获取用户信息 api 等）。api 差异一般是大头，这个只能用指定 app 打开解决，自己随便弄的套壳 app 也不会有这类 api 的。

没太看懂这个问题，你是想验证啥？

是要收集确认线上环境是否存在音画不同步，还是验证开发说音画不同步问题已修复，是不是真的修复完没问题？

建议补充清楚问题的背景，以及具体想解决问题吧。直接把问题的一句话描述抛出来，容易导致理解偏差，而且这个一句话描述的问题可能在大家看来范围会太大，要回答清晰需要花不少时间，所以放弃回答。

举个例子，“如何减少线上 bug”，这个是很大的问题，可以说是每个测试人的终极目标之一，基本测试所有做得事情都是在解决这个问题，很难回答，所以也很难收集到答案。但如果是 “我所在的公司 .... ，所以导致由于 ... 出现的问题会比较频繁，大家有没有什么好的建议” ，那大家理解了上下文后，范围会缩小，回答起来也更容易，所以更容易收获答案。