互联网测试开发面试题集锦（二）

测试流程篇

需求阶段-开发阶段-测试阶段-上线阶段-上线后

需求阶段

需求文档规范

首先需求文档要有规范，这部分测试可以要求如果产品需求文档不够完善标准的话，一个好的需求文档应当包含如下几个方面：

• 版本信息（包含版本履历，创建人，修改人，日期等）

• 需求概述包含背景，目的，影响范围等

• 流程图（包含业务流程图，系统操作流程图）

• 具体功能模块详解

需求评审前

• 测试负责人拆分需求模块，分配对应的模块负责人

• 模块负责人进行需求了解、分析，整理需求疑问、建议等，若时间允许，提前发送邮件或口头与产品进行确认，提前发送邮件或口头与产品进行确认。

需求评审中

• 测试需要思考的地方不限于以下几点
  了解需求产生的背景，了解产品人员想要达到的效果以及要解决的核心问题是什么？

• 一个新功能添加的必要性需要评估。(产品预期状态是否能够达到，投入产出比是否合适，评估这个需求是否合理，从用户体验角度考虑)

• 功能模块是否与其他模块需求冲突，冲突时是否有相关处理方式？

• 涉及到UI方面，文字，颜色，位置，大小，样式，布局等是否有详细说明，效果是否统一

• 确认之前标注的地方得到解答

• 最后测试需要输出的：

• 测试模块拆分负责表，对应模块测试负责人，测试所需时间
  评审会议所需要输出的；需求评审会议记录

需求评审后

• 项目经理根据会议过程整理出会议记录公示所有相关参会人员包括相应领导。

• 测试对应模块负责人开始用例设计，准备测试数据，按照日期监督各模块开发负责人，准时提测

• 产品及时更新文档，确保文档内容是会议三方所述一致
  

会议记录至少包括以下内容：

1. 会议中没有解决的疑问地方，产品给出的解决方案（有些地方产品也需要会下跟业务再次确认）

2. 明确对应模块开发负责人，测试负责人，开发测试对应所需要的时间等

3. 需求影响的模块以及所涉及到的风险，上线之后应对的容灾方案，回滚计划等

需求优先级排期：

需求变更：
三方确认，如果确认一致通过同意变更，产品发出邮件，产品更新文档，开发重新修改研发时间，测试重新调整计划，是否需要延期，测试工作量，人力，时间资源等调配

跨部门，跨组需要多方配合的需求如何展开测试?
避免以下点即可，如何避免以下问题多沟通多交流，拉到一个群组交流，由项目经理牵头组织，如果没有测试负责。
通过文字邮件等方式确认每个模块开发测试按时完成，最终进行联调测试。

开发阶段

• 参与开发详细设计评审，了解功能实现过程

• 开发书写代码，完毕之后，有两种方式一种人工方式进行code review，组内leader负责检查code。

• 另一种提交到系统，由系统通知相关负责人检查或者借助第三方工具如(Checkstyle，FindBugs，PMD，Jtest），如果review通过则允许提交到svn

• 开发在开发环境自测，书写自测报告

测试阶段

从需求评审阶段就开始，一个是分析需求拆分模块，每个对应的模块负责人书写测试用例（一个根据开发详设或还有就是需求文档），进行测试用例评审，当开发提测之后进行code review环节（适当补充用例），准备测试数据测试环境调试，冒烟测试（不接受一句话提测，对于提测信息不明确或者缺少自测报告或者冒烟不通过给予打回），通过之后进行功能，性能，兼容性，异常测试等（如果有接口测试一定是在客户端没提测时候，如果涉及到前后端分离测试，那么都是先测试服务端，然后测试客户端），提交bug，验证fix的bug，回归测试，最后确定没有问题，发送验收邮件，提交上线申请。

上线阶段

上线的标准：

• 本版本所有需求都已经实现

• 本版本所有测试任务已经执行完毕

• 确认所有major级别bug都关闭，个别问题如果不修复要有明确说明，bug解决率要达到95%以上，

• app稳定性评估，包含以下三个方面

  自动化评测
  （1）随机浏览自动化评测结果无新增的未知的Crash发生；
  （2）随机浏览自动化评测中所有已知Crash能够用修复的均已修复。

  线上灰度崩溃
  （1）线上主进程Crash全部修复；
  （2）线上子进程所有已知Crash均已修复；
  （3）线上子进程没有新增的密集的崩溃。

  与上一版本数据对比
  （1）对上一版本稳定性对比，不差于上一版本。

• app性能评估

  页面加载性能
  （1）Wifi页面加载速度与上一版本相比，不能下降。
  （2）2G3G页面加载速度与上一版本相比，不能下降。

  冷启动时间评测
  （1）冷启动时间与上一版相比，不能增加。
  （2）向竞品看齐，与竞品的差距情况公示。

  主观性能感知
  （1）高端机不能有非常卡的情况，有点卡的情况也应该控制数量
  （2）高中低端机均不能有较线上版明显的卡顿内容

• 对于上线出现的问题应急措施考虑

  出现问题，有完善的应急预案，出现问题能够及时回滚或者马上修复

  如果上线失败，事后复盘总结出此次的问题，形成邮件形式发送相关人员，避免下次再次出错

上线之后

• 线上监控新功能运行情况

• 出现异常情况或者问题，需要临时发版重新打补丁包

  补丁包提测的内容一般是：

  修复线上待修复的功能逻辑Bug

  修复线上待修复的崩溃

  优化线上体验不好的产品需求

• 补丁包评估方法

  通过工具检测开发提交的代码

  三方及时沟通，为何修改，影响范围，测试需要做的

  最后确认要发送补丁包，书写邮件告知相关负责人补丁包内容原因影响范围等

产品功能复合需求，产品验收通过，进入code freeze状态，开发打包发线上环境（一般公司除了测试环境还有会有预发环境模拟）