能文能武测试人，面对开发时的常胜秘籍！

lsekfe

又到了招聘季，不少测试人员开始物色合适的机会，那么在面试时都有什么套路呢？
　　大部分的面试都是先“文”后“武”。
　　“文”呢，主要是问你一些测试的理论技巧、逻辑思维以及团队之间问题的处理方式等等。
　　“武”呢，大体来说就是问你一些测试技能，包括一些测试工具、环境配置等等的使用。
　　今日我们主要来说说测试的“文”，主要分为两大部分：
　　1. 面对“开发说”，测试人员的完胜秘籍是什么？
　　2. 作为一个专业测试，日常的测试标配工作流程具体是什么？

　　第一篇：开发说
　　面试官问该类问题：一方面是考察面试人员的是否实际参与工作，一方面是考察面试人员的处理事务能力。
　　那么，在日常测试工作中，如何高效、高情商地面对所谓的“开发说”呢？

　　1. 开发说：需求文档没提到？
　　测试秘籍：人为判断需求文档未提及的问题，jira提交【改进】给需求人员，让产品确认并备注解决方案后转移给对应的开发人员，并同步更新需求文档。

　　2. 开发说：上一版本留下的坑？
　　测试判断：影响业务非基础流程，影响用户体验。
　　测试秘籍：缺陷影响业务非基础流程/影响用户体验，jira提交【低级-缺陷】给当前负责该模块的开发人员，要求开发备注缺陷原因以及解决方案。

　　3. 开发说：这个bug级别太高？
　　测试秘籍：从阻塞耗时间，来判断缺陷等级。
　　1）导致测试工作无法开展，且解决耗时较长（严重影响测试进度）的，定义为高级；
　　2）导致测试工作无法开展，可在短时间（不影响测试进度）内解决的，可适当降低缺陷等级；
　　3）导致部分工作无法开展，不影响其他流程，可适当降低缺陷等级；
　　4）原则上不予降级，但是开发出现异议，可协商等需求上线后的复盘会议上进行二次讨论。

　　4. 开发说：我自测了？
　　开发自测的质量，严重影响测试的工作量，提测的质量不过关，无形中增加了测试的工作负担。
　　那么如何保证开发自测和提测的质量呢？
　　测试秘籍：
　　1）实行开发自测用例，将1级用例指派给开发进行执行；
　　2）在提测前检测开发是否执行自测用例；
　　3）提测后在日报汇报当日测试效果。

　　5. 开发说：不是我的问题？
　　在测试过程中，特别是测试前端时，开发经常习惯性的不排查问题，直接给测试人员说：这是api的问题。
　　所以测试在日常工作中，经常出现找前端开发，前端开发说是api的问题，找api开发说是前端问题。那么作为一个专业的测试，如何减少这种不断找bug主人的工作？
　　测试秘籍：
　　1）对比现象，同时对比安卓和ios：
　　a) 若是两端均为错误，则大概率是api的问题，可以优先找api人员；
　　b) 若是仅有一端出现错误，则大概率是前端的问题，可以优先找前端开发。
　　2）学会看日志：使用抓包工具或者公司内部的日志平台，直接定位是接口返回的数据异常，还是前端展示异常；
　　3） 提供定位日志：给对应的开发人员。

　　6. 开发说：部署/安装一下？
　　在测试过程中经常出现，开发解决一个bug，就会要求你部署一次代码或者重新安装包，导致测试过程中不断地部署、不断地安装，不仅影响个人测试，同时也会影响他人测试的准确性。
　　测试秘籍：
　　1）判断缺陷严重程度：导致无法继续测试的缺陷，可立即部署/更换安装包；
　　2）非严重缺陷，则按以下方式处理：
　　a) 开发在缺陷jira上备注：修复的版本+修复内容+可能影响范围；
　　b) 及时提交代码；
　　c) 完成a）+b）之后，开发人员及时再将缺陷【状态变更：已解决+指派给对应的测试人员】。
　　测试人员可以阶段性的对已解决的缺陷进行环境部署或安装包替换后，再进行统一回归验收。

　　第二篇：测试姐们的日常标配
　　电脑手机都有低配置、标配、高配置的区分，那么测试的日常规范也可以做个等级划分。
　　测试流程及其不规范的测试日常是低配：直接开展测试
　　测试流程稍微规范点的测试日常勉强算是标配：需求-测试要点-上线
　　……
　　每一家公司的工作流程规范都不统一，以下是个人根据自我经历整理出来的测试日常工作流程。

　　1. 参加需求评审会议
　　在需求会议前，测试人员需事先了解会议内容，并对疑问点进行标注。
　　在需求会议中，及时提问，在需求会议结束后，跟进确认会议上问题的解决方案。

　　2. 制定测试计划
　　1）评估测试工作量；
　　2）确定测试环境：在哪一套环境上开展测试工作；
　　3）确定测试策略：新功能测试、兼容性功能测试、历史功能回归测试、升级测试等；
　　4）准备测试物料：提前预备测试数据，测试硬件环境（浏览器、手机等）；
　　5）……

　　3. 设计测试用例
　　常见的设计测试用例，除了大家常说的参考需求文档和需求原型外，实际上，我们还需要参考以下内容。
　　1）UI设计效果：注意UI设计效果；
　　2）需求原型；
　　3）流程图：衔接各个子系统之间的业务流转，设计对应的场景型测试用例；
　　4）需求文档。

　　4. 评审测试用例
　　1）信息同步：需求会议后变更的内容，在评审时再次同步给开发；
　　2）核心评审：需求文档未提及细节内容，着重提醒开发。

　　5. 执行测试
　　6. 测试日报：当日测试进度，阻塞问题等
　　7. 上线风险评估：评估是否满足上线标准、遗留问题处置