1、测试前的准备
在开始测试之前，要做好哪些准备工作，以下是之前在实践中积累的经验
- 问题：预发以及线上测试时，未区分优先级，将精力花费在功能的细枝末节
- 办法：预发以及线上测试时，要评估功能点的重要程度，以及出问题时的影响程度，判断要重点测试哪些功能
- 问题：需求文档中给出的邮箱不对，在线上环境测试的时候发现这个问题
- 办法：新需求中有涉及到的对外展示的电话、邮箱、微信号（包括企微）等联系方式的，请在提测时向QA同学特别备注说明。
- 问题：写测试用例时，未能完善的考虑用户的实际场景
- 办法：要从用户实际场景考虑，考虑用户要使用的重点功能，对于用户来说，哪里的功能是最重要的，是用户最常遇到的，最看重的。考虑用户的操作路径，再验证这些路径是否存在问题
- 问题：涉及不熟悉的需求时，容易对隐藏的功能点进行漏测
- 办法：要有敬畏心，测试和历史需求相关的需求，一定要找相关的测试人员询问要注意的点，查询历史的需求文档
- 问题：需求中，未判断功能的数据是否需要做数据隔离
- 办法：需求中，有要展示活动推荐列表的，展示嘉宾推荐列表的，要确保做了数据隔离，所有的页面功能，不只是活动，都不能给普通用户推荐测试的内容
- 问题：测试时，未明确讨论测试范围，导致有的改动没有测到
- 办法：测试需求，要和开发详细的确定测试范围，核实哪些功能需要测，哪些不需要测，防止甩锅行为
2、兼容性相关（重要重要重要）
关于新老版本兼容性，要注意哪些测试点
新老版本/平台兼容
兼容性常会有风险问题，测试工程时考虑兼容可以考虑以下几个方面
1、服务端和h5上线后，但没发包时，有的功能不能用，需要隐藏这些入口
2、在"我的"，"消息"页面由服务端返回的，只有新版本有，老版本没有，要服务端做版本控制
3、发push，跳到app的新页面，老版本也发push的话，跳转的页面就会有异常，需要服务端处理，不让老版本发push
- 问题：后端在"我的"页面新增入口，未做版本控制，未考虑到小程序的兼容性
- 办法：在原有基础上改东西的，服务端或h5改动的，一定要看老版本和小程序的兼容性
- 问题：当站内信、push只供app使用时，未考虑老版本、小程序点击站内信的场景
- 办法：站内信、push相关，要考虑老版本、小程序的兼容性
- 问题：后端前端上线时，而app小程序未发版时，可能会有用户能看到但使用不了的功能
- 办法：在写用例时，要提前仔细考虑是否有这种情况，并提醒开发及时作出版本控制，隐藏相关入口
- 问题：在旧版本的h5页提示"请升级至新版本"，但新版本未过审时，无法升级，并且加入OPPO过了，VIVO没过时，OPPO用户会分享给VIVO用户，VIVO用户也会提示升级
- 办法：这种需要等新版本全都过审了，才能放开旧版本的入口
机型兼容
关于机型兼容性，要注意哪些测试点
4、手机适配兼容，测试页面UI改动时，弹窗的展示时，测试初期机型未看全，导致问题后至
- 问题：女性嘉宾卡片优化，实际效果与预期不符，屏幕适配性差，同样的资料，在小屏手机上已经放不下，但在大屏手机上留有很大空白
- 办法：在测试早期，就测试多种屏幕，包括iOS和安卓大屏幕，安卓要看有无导航建的情况，尽早让产品确认效果，确认是否需要调整
- 问题：iOS一直在覆盖安装，未测试全新安装，导致未发现全新安装会出现的问题
- 办法：IOS要测全新安装，并且注意全新安装时的测试表现
- 问题：iOS系统兼容，常常会有高版本和低版本的兼容问题
- 办法：iOS测功能要测低版本和高版本，保证版本兼容正常，高系统例如18，低系统例如14、15
3、测试中注意事项
在测试过程中，为了防止漏测，要注意哪些点
- 问题：测试时，对用户实际的使用场景的判断有错误，见面计划同时出发首次欢迎和聊天动效有两种途径，对用户的常用途径产生了误判
- 办法：有时测试容易触发的场景，却不是用户按实际流程容易触发的场景，要考虑正常用户的正常思维
- 问题：测试时，想到了用例之外的场景，在QA改了之后，预发忘记回归了，导致问题带到了
- 办法：测试中，遇到用例之外的问题，要及时把场景补充到用例中，防止预发忘记回归
- 因不熟悉历史逻辑，导致测试用例不全面，设计场景时漏掉了重要场景，出现线上问题
- 有些不了解的历史逻辑，一定要先问，但不要只询问测试、开发，要自己找之前的历史文档，查清楚，再和多方进行确认
- 原有：着急测试时偶遇其他问题，未进行彻底的关注
改进：提高敏感度，遇到问题来不及跟进时要及时记录下来，防止着急时漏了bug
- 原有：测试功能时，有涉及到双方的交互时，只看了单方的效果
- 改进：测试功能时，有涉及到双方的交互时，要查看双方的展示与点击效果是否正常
- 原有：测试时，着急测自己要测的功能，导致没注意存在的问题
- 改进：每到一个新页面，不要直接进行测试，停留两秒钟，观察页面是否有其他问题
4、沟通相关
和其他协作方合作时，为了提高工作效率，要注意哪些点
- 问题：描述bug时，描述的信息不够完整，会影响开发解决问题的效率
- 办法：描述bug时，需要后端解决时，要带上用户ID，涉及到活动时，加上报名的活动ID，后端根据出问题的用户，能快速定位到问题。需要前端解决时，要描述清楚出问题的机型，带上用户的手机号，前端往往登陆手机号，检查修复后的效果
- 问题：有一个问题，未确定是由那一端来解决，我只是单独的与各方交流，未拉群讨论，导致沟通效率很低
- 办法：一个待讨论的细节涉及到多人时，最好拉群讨论，保证每个改动，都同步到所有相关成员
- 问题：我发现的bug，属于同事B负责的模块，我直接将bug告诉了开发，导致这个问题由我来跟进，后续我交接给了同事B，同事B不了解其中的细节，导致沟通出现问题，引起上线的p4级问题
- 办法：发现的bug，属于其他同事负责的模块时，先告知该测试，让该测试直接与相关开发沟通，避免跟进他人的测试模块
- 问题：端上的UI处理的有问题，但是没告诉UI，打算让设计走查的时候自己觉得，但是设计走查的时候没发现，导致UI问题暴露到线上
- 办法：对UI有歧义的地方，一定要追踪彻底，不要觉得影响不大就忽视，最终导致严重后果
- 问题：需要开发配置白名单时，未说明环境
- 办法：需要开发配置白名单时，要说明ID和对应的环境
- 问题：有些历史遗留问题，找不到是哪个需求引入的
- 办法：猜测是哪个需求改动引出的，下载这个版本的包，并对比这个版本之前的包，就能定位到哪个需求引入的问题
- 问题：在部署预发的时候，未提前提醒开发执行sql，导致第二天的测试进度收到影响
- 办法：在部署预发的时候，要提前一天提醒开发执行sql，最好统一在群里发个消息，提醒各个协作方及时部署预发环境
- 问题：后端上线前，未在群里同步算法，导致算法上线进度推后
- 办法：在上预发时，就告知算法上线时间。上线前要把消息发群里，别忘记通知敏感词策略和算法推荐等上线，确定好要通知的对象
5、测试流程相关
关于测试中各个关键的节点，有哪些需要注意的
- 问题：在线上环境的测试流程不了解
- 办法：线上环境，首先要简单验新版本的新功能，再回归新版本的老功能
- 问题：让产品验收的时间点过于靠后，导致发现的问题被后置，延缓上线进度
- 办法：办法无论版本需求还是非版本需求，上线前要找一个合适的节点，大概是QA到了尾声的时候，告知产品需求已测试完毕，让产品验收，验收通过后再上线
- 问题：未区分出小程序的页面是原生页还是h5，导致未提醒小程序未提审，有些功能不能及时回归
- 办法：一定在测试时，要确认哪些是原生的，哪些是h5，小程序顶部条的有颜色的新页面，几乎都是原生页
- 问题：上线时，开发未上线全部功能，有遗漏分支，未验证出来，需要等第二天再次上线
- 办法：上线后，要验证需求的主要功能使用正常，保证无上限遗漏
- 问题：上线后，遇到了问题，只有安卓端有问题，以为是端上的，没确认就下班了，导致后续其他同事帮忙跟进
- 办法：上线后，遇到问题，一定要和各方确认后，才能下班，不能留下不靠谱的印象，下班不要走太早，以防有意外发生，没人验收
- 问题：QA环境未测试全部用例，QA测不到的，预发也要完整过一遍，否则问题暴露过晚
- 办法：QA、预发至少要把所有用例都跑一遍，最大限度的暴露问题，要是有QA测不到的场景，也要让开发配合构造，验证场景是否符合预期
- 问题：服务上线，小程序未发布新版本时，会有兼容风险
- 办法：小程序四点要求提审，涉及到小程序原生页的改动，要考虑小程序新老版本的兼容
7、用户体验相关
关于用户体验方面，有哪些需要特别注意的
- 问题：测试时只是站在用户角度觉得没问题，未站在设计者的角度思考
- 办法：测试体验性问题时，设计者和使用者这两个角度都要思考，思考是否满足设计者的需求，是否满足使用者的需求