背景：
我所在的公司有两个产品线，一个是web端，一个是移动端，两端实现的业务是相同的，但web端功能一般会比移动端发布的早一些，两端分别配有各自的测试人员。我参与移动端的测试，最新一个移动端的迭代是web端已经上线的功能，功能类似于签到得积分，然后积分兑换，但由于涉及到各种状态的流转，需要修改数据库这类的操作，所以我特意和web端测试此功能的小伙伴提前确认了下里面的逻辑关系，然后兢兢业业的开始了我的case写作，考虑到最新的迭代偏功能，所以特地罗列出了容易出错的逻辑小点供开发自测
问题：
Review test-case 会议开始，当我拿出case宝典准备与大家分享时，前端大佬瞄了几眼后，说到"其实我感觉 xxx那边的业务逻辑 其实测试这边不会是主要测试流程. 主要还是在app中的整体表现 包括UI 展示内容 比如当app中打开xxx的时候 daily tasks这些是需要隐藏的. 包括登录之后 能够正确鉴权. 登出之后也可以正确要求登录之类的"
我直呼：听君一席话，如听一席话,这个也算是偏功能的需求，为啥逻辑测试会不是重点
直到我测完了这个迭代后，前端大佬在群里共享了一个Hybird框架,据说很好用，本着看热闹的心态，我去百度里搜索了下“啥是Hybird框架”，不搜不知道，一搜就得从APP的分类开始说起：
APP可以分为3类：Native APP(原生)/Web APP(网站)/Hybrid APP(混合),各自的优点见下图
大悟：
然后我恍然大悟，然后暗戳戳开始了如下自我批评：
之前前端大佬的一番话不是没有道理的。首先这个功能在web上是已经成熟的，所以相关的接口服务以及逻辑不会有太大问题。其次我当时没有原生/混合应用的这类概念，还以为是移动端再重新写一套一样的代码，其实这次的迭代就是内嵌web端的页面，所以页面具体的展现出现问题时我找的是web前端人员，而web端端页面也已经是上线了的，所以也不会有太大问题，所以最后，作为移动端的测试，肯定是需要重点关注内嵌web页面和APP的交互，比如页面标题在前进/后退/弹窗出现/退出后的展现
总结
所以感叹道作为测试也需要了解一些技术的知识，不是说了解了有多厉害，但至少能拓展我们的测试思维，或者让我们少费一些蛮力，让我们可以预见哪里是容易出问题的地方，哪里可以不用花那么多精力
