平时都是测后台多， 最近接手做 app 测试。 如何高效测同一个需求（多端，包括 H5，安卓，苹果，小程序）。
目前是 H5 先测，看接口有无问题，然后再物理机安卓，苹果，小程序，一起测同一个界面。
有时候多端不一致，都挺纠结的。。。（虽然有 UI，但是有时候觉得不是致命性的问题，感觉提 bug，开发会觉得小题大造，不提，到时验收又说是 bug）
bug 还是要提的，只要你觉得不符合设计图的，都可以提；开发不改那就不是你的问题了；实在不行可以拉上产品讨论
ui 的 bug 类型选 UI 就行了
-
优化测试工作量视角：
- 梳理出哪些地方可能会多端不一致，依赖研发配合做，明确多端肯定一致的地方就不需要重复测试
- 不同的人拿不同端同时测试，依赖大家对 bug 的标准要足够一致
- ui 自动化 + 图像识别，但是没足够空余时间不建议上这种玩意儿，很不稳定
-
业务权重视角：
- 按业务优先级，先在多端上测重要的场景，时间不够就砍掉低优场景
针对最后多端不一致的问题，先提了 bug 再说，代表问题已经发现了，是否修复研发来判断，责任也转移了绝大部分。
该怎么测就怎么测，三端都要测全了，如果有不一致的就提 bug，要不功能多了，不一样地方多了，后面会很麻烦，谁对谁错都不好说，前期一定要保证，UI 问题该提就提，类型选 UI，优先级如果是 UI，可以适当降级一下，开发也不会太较真，说明事情原因就行
建议和研发确认下，这个多端背后的技术方案是啥，看确实是每个端代码都完全独立，还是用类似 Electron 的技术，一套逻辑代码，打包成多平台应用。
如果是完全独立，只能老老实实去测试，因为代码之间相互独立。
如果是有相互复用的，可以看哪些部分复用，复用部分只需要过一下 P0 功能确认没问题就行，不用过太细。重点关注兼容性方面有没有问题（如唤起相机这类调用平台 api 实现的，以及不同屏幕大小下的适配）
如果是同一个产品，相同的设计，在不同端唯一的差别就是操作系统的风格不一样. 比如日历控件在 iOS 和 Android 就不一样，这种都是可以总结的.
我们的做法是除非这种和操作系统相关的差异，其他都要求和设计一致；如果有差别就让产品决定如何统一.
感谢大家的回答。
就好像最近有个需求，商品详情页有 “咨询” 的按钮，需求：某类域名的商品，按钮是显示 “客服”。但是安卓显示 “客服”（对了），ios 显示 “咨询”（错了）。对我来说，感觉都一样，就是一个按钮字眼显示。但是没想到，安卓不是真的做对了，最后需要拉上 H5（这些页面都是 APP 调用 H5 的）、产品来分析（讨论起码有 15 分钟）
。。
解决方案：两个 APP 端，拦截 H5 要跳商品详情，就请求接口，根据域名再跳对应页面。
可能习惯测后台，比较简单的界面，一下子突然测这么多端，有点懵。。
同刚刚转手接 app 之前一直负责中后台相关
Emma999
回复
这说明凭 “感觉” 去测试是有问题的
其实多端测试和兼容性测试很类似，绝大部分功能在不同的浏览器，设备上期待结果都是一样的，多端测试也是一样。我们应该以需求和用例作为标准去执行测试和判断结果是否符合预期，而 “感觉” 这个东西应该帮你去怀疑这个结果是不是缺陷，然后通过需求，讨论等流程去验证你的怀疑，而不是通过 “感觉” 来把一个不符合预期的结果变成一个合理的需求。
不要害怕提出来得问题被拒绝
不要害怕提出来得问题被拒绝
不要害怕提出来得问题被拒绝