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

测试流程篇

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

需求阶段

需求文档规范

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

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

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

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

• 具体功能模块详解

需求评审前

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

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

需求评审中

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

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

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

• 涉及到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状态，开发打包发线上环境（通常公司除了测试环境还有会有预发环境模拟）

07

实际项目篇

• 主要涉及到你简历所写的项目，举几个例子自动化，大家怎么作的，你负责的是哪块业务

• 主要考察你自动化技术水平，同时涉及到的一些技术点会顺带着一块儿问出来，好比分层自动化，接口自动化。

• 有没有使用编程作一些工具或者工具二次开发等

• 团队协做如何处理问题的，你项目中你遇到困难如何解决的，还有有没有作的很差的地方如何改进。

• 项目架构相关的，如今架构都是web／app－站点层－服务层－数据层（待续）