软件测试经典面试题分析——软件测试流程

　1、需求分析

　　·跟同事之间探讨客户需求

　　· 对需求文档进行测试互相交换想法

　　2、需求评审

　　如何评审？

　　首先提前一天发邮件给格个参会人员，准备参与XXX项目需求评审。

　　参与人员：产品经理，项目经理，研发负责人，研发小组成员，测试负责人，测试小组成员。

　　然后开始会议，主要分析产品需求的合理性，开发考虑这个需求可不可以实现，测试考虑能不能给用户带来更好的使用体验。

　　3、根据需求编写测试计划

　　·确定需求分析说明书是制订测试计划的基本依据

　　· 测试计划的定义软件测试计划是指导测试过程的纲领性文件

　　测试计划包含的内容：

　　· 概述（测试目的、参考文档、缩略语)

　　· 测试范围(测试范围，要测试哪些模块)

　　· 测试组网图(系统架构图、组网图)

　　· 资源需求(硬件资源需求、软件资源需求、人员需求)

　　· 测试条件(测试版本启动、测试版本停止、测试版本挂起的准则

　　· 测试进度(测试所有活动的时间安排，是测试需求分析、测试用例、测试轮次的时间安排)

　　· 测试准则（测试用例通过、测试用例失败、回归的准则、培训计划）

　　人力风险

　　1. 人力资源不够 ?解决方式；按照项目计划，测试计划准备好测试需要的人力

　　2. 测试用例未被完全执行 ??解决方式:在测试留存中严格控制测试的执行.抽查,责任归个具体的人

　　3. 人员流动，测试人员对业务不熟悉 ?解决方式:做好人员流动的准备,加大业务培训

　　需求风险

　　1. 需求人员,测试人员,开发人员对需求的理解不一致

　　解决方式：加强需求评审和沟通。

　　2. 后期需要小的变更点,没有引起重视,未知会到测试

　　解决方式:项目流程控制,所有变更必须知会测试进行测试和分析。

　　3. 需求变动大导致测试工作量增加,可能导致的测试不充分

　　解决方式:通过加班延长测试时间,加大测试人员投入,保证测试充分。

　　开发风险

　　1. 开发提测的时间晚于原计划，导致测试时间被压缩

　　解决方式：开发把握好计划送测的时间，做好晚送测的测试准备，加班或加入人力等。

　　2. 开发修复bug考虑不周全，带入新的缺陷

　　解决方式:bug验证要考虑好相应的场景，回归相关的功能。

　　环境风险

　　测试环境与线上环境差异过大，导致环境问题。

　　解决方式：尽量使用和线上环境差异少的测试环境，条件允许可模拟一套与线上相近的测试环境，来做项目最后的回归测试或安装测试。

　　测试计划的目的

　　粗略地估计测试大致需要的周期和最终测试报告递交的时间。

　　4、编写测试要点

　　根据需求编写测试点，一个需求点包含N个测试点。

　　5、编写测试用例（部分公司有要点也有用例，大部分公司有测试要点就没有 ?????测试用例，没有测试要点就写测试用例，二取其一）

　　什么是测试用例测试用例是一份测试文档，它描述输入、操作步骤、和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作，是测试执行的依据。

　　测试用例的组成内容：

　　·所属产品

　　· 所属模块

　　· 用例编号

　　· 用例名称

　　· 前置条件

　　· 操作步骤

　　· 预期结果

　　· 实际结果

　　· 测试人员

　　6、用例评审

　　评审分类

　　1. 部门评审，测试部门全体成员参与的评审。

　　2. 公司评审，这里包括了项目经理、需求分析人员、架构设计人员、开发人员和测试人员。

　　3. 客户评审，包括了客户方的开发人员和测试人员。这种情况在外包公司比较常见。

　　评审内容

　　1. 用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。

　　2. 优先极安排是否合理。

　　3. 是否覆盖测试需求上的所有功能点。

　　4. 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法。

　　5. 是否已经删除了冗余的用例。

　　6. 是否包含充分的负面测试用例。充分的定义，如果在这里使用2?8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在“保护”20%的功能实现。

　　7. 是否从用户层面来设计用户使用场景和使用流程的测试用例。

　　7、是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。

　　·搭建测试环境

　　· 等待开发转测试（提测）提测的准则：冒烟测试通过

　　· 据用例来执行测试

　　· 测试不通过的应在缺陷报告当中记录

　　· 缺陷报告的内容

　　· 所属产品

　　· 所属模块

　　· 影响版本

　　· Bug类型

　　· Bug标题

　　· 严重程度

　　· Bug状态

　　· 优先级

　　· 重现步骤

　　· 附件

　　· 提交bug后还需对bug进行跟踪

　　8、测试完毕编写测试报告

　　· 一直反复测试2-3轮过后才确认测试结束

　　· 测试报告的内容

　　· 简介 (产品名称、版本号、参考文档)，

　　· 测试资源描述 (地点、人物，软件测试环境、硬件测试环境，测试组网图，测试仪器)

　　· 测试时间统计 (测试任务的时间，这里面的时间是详细的每个版本的细分时间统计)

　　· 测试用例分析 (测试用例执行情况分析，哪些用例通过了，哪些发现问题了),

　　· 缺陷情况分析 (分布情况、严重程度、遗留问题)，

　　· 测试版本质量分析 (测试版本的质量怎么样，描述一下)

　　· 测试活动评估 (测试活动及写测试用例，脚本方面的质量方面描述一下)

　　· 测试过程改进 (改进的建议)

感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

 

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取