是真的测试过不支持么？

我理解浏览器的无头模式，实际还是有运行界面渲染引擎的，只是渲染出来的最终 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”，这个是很大的问题，可以说是每个测试人的终极目标之一，基本测试所有做得事情都是在解决这个问题，很难回答，所以也很难收集到答案。但如果是 “我所在的公司 .... ，所以导致由于 ... 出现的问题会比较频繁，大家有没有什么好的建议” ，那大家理解了上下文后，范围会缩小，回答起来也更容易，所以更容易收获答案。

@imath60 这个项目看起来还挺不错的，是你开发的么？

可以在社区的 开源项目 板块发布一下，方便后面其他人快速找到？

虽然没有直接关系，但只要是会频繁造成线上 bug，不管是推动其他部门解决还是自己部门内解决，测试还是有责任想办法规避的吧。

针对原因 1，可以在上线部署环节，加一个测试审核，测试确认代码分支有没有错，有没有夹带一些测试不知道的变更上去。

针对原因 2，看是运维手工操作导致的问题，还是本身上线计划有遗漏导致。
如果是前者，可以推动运维前期做线上操作双人制（1 人操作，1 人 review，降低犯错概率），甚至建设自动发布的平台，减少人工操作，避免出错；
如果是后者，那上线计划测试多加一个审核，以及在上预发布这种类生产环境时就用这个计划演练一遍，确认下有没有遗漏。

1、针对 h5 自动化测试的时候，大家是如何进行 “驱动” 的。使用浏览器驱动直接转到 web 端自动化？还是说使用原本的 app，在此之外进入一些需要测试的 h5 应用中。（因为面向的 h5 应用不一样，有些 h5 应用在 web 端无法打开，有些 h5 应用用浏览器打开的时候会无法加载一些用户 SDK，相当于无法使用。也就是说，用浏览器驱动直接转到 web 自动化的话，会有一部分限制）

一般根据实际使用场景来驱动，比如这个 h5 设计是放在 app 里用的，那就用 app 去启动。放在浏览器里用的，那就用浏览器去启动。

2、针对兼容性测试有一个问题：我需不需要针对多浏览器内核进行测试兼容性，需不需要针对手机浏览器内核进行测试，需不需要针对一些微信/支付宝进行一些应用测试（挺迷茫的）

这个看用户使用场景和线上问题情况。相对来说，h5 标准已经比较细，各家浏览器的实现差异已经没有以前 ie 和其他浏览器那么大了，只要不调用一些相对偏门或者特别新的 js api ，一般不怎么会有兼容问题。倒是不同 app 内置的 webview ，提供的调用 app 功能 api 差异比较大（比如调起微信的支付，和调起支付宝的支付，api 是不一样的，但界面按钮大概率是同一个），这块如果有涉及，最好验证下。

3、针对性能测试：假设现在用浏览器进行驱动，那能拿到的一些自动化性能数据的偏重点，可能就是响应速度等等，这些预想之中确实有手段去拿到，但是在这之外，我还可以输出些什么。

我一直觉得，如果你功能测试的时候没太感觉性能有很大问题，暂时可以先不用特别关注性能。先把前面兼容性这些搞好吧。真要搞，包括接口响应速度、界面帧率、白屏时间等都需要测试，还挺多的，这些通过 chrome 浏览器的开发者工具，大部分都可以捕获到。

4、针对 h5“自动化”“功能测试”，由于本人对 web 端了解较少，web 端上有没有类似 Fastbot 的智能遍历工具（有最好，无则自己写一个瞎点也是可以的）

fastbot 本身也支持遍历 app 内的 webview 吧，只要控件树能拿到里面的内容就可以支持。只是 web 端出问题不如 app 出问题直接 crash 那么明显且容易捕获，更多只是 js 报错，界面无响应而已，所以反而需要下功夫的是怎么捕获错误。不过确实没怎么见到有 web 端的智能遍历工具，可能是因为更新非常容易，所以质量要求没有 app 那么高？

这也不算很底层吧，只是确定下原因，便于后续遇到类似情况后解决而已。

如果不是定位到原因后解决问题，而是随便改，改完发现生效后就当解决问题，容易导致一些副作用而不自知，也不利于系统地积累知识。