项目测试流程规范(面试)

本文介绍测试人员在完整项目流程中的角色、输入与输出。涵盖项目立项阶段的讨论,如产品目标、技术可行性等;需求分析文档的输出;以及测试流程,包括方案设计、评审、用例设计与执行、报告评审、线上问题处理和复盘等,可供应届生面试参考。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

背景

前后入职过大小几家公司,现针对完整的一个项目流程来简单介绍一下测试人员在其中扮演的角色,以及应该获得的输入件和应该输出的交付件。

一、项目背景

当前是项目立项阶段,需要参与的角色有:项目主管,系统工程师,研发工程师(FPGA,硬件,软件),测试工程师,项目经理,销售。这一阶段需要讨论的是

我们为什么要做这一款产品?

目前做这款产品是为了经济收益,市场份额,还是技术能力建设提升等,也就是回答"需求是从哪里来的”这一问题

该产品是从0-1还是1-n?

该产品是全新开始的项目还是某一款产品的迭代升级版?全新的项目需要讨论的事项众多,而迭代升级版在技术实现,研发经验等很多层面都可以继承,这一阶段主要讨论该项目的技术可行性:

  • 项目的难点在哪里?
  • 对于研发和测试来说是否有难度?
  • 需要哪些方面的知识/人力支持?
  • 现有人力能否满足项目需求?
  • 是否需要内部团队协作/人员招募?

该产品要做成什么样?

此时不一定要展开讨论技术细节,仅讨论本轮需要完成的最终目标后续迭代实现的功能即可

【例】我们准备做一款车载以太网和普通以太网转换的板卡,对标某某企业的XX产品,仅做一个数据流的转化即可支持Bypass和透传两种模式,后续可能通过增加设备IP的配置来远程升级但优先级不高,本次不用实现

预计的交付周期是怎样的?

该产品的交付是否紧急?一般通过交付的紧急程度来确定项目的优先级

  • 该产品是否已有订单?是否有明确的最晚交付时间点?
  • 预计多少人力投入多久在某个时间点完成?
  • 整个项目过程中可能存在的风险以及应对措施(春节假期,资源协调,人力短缺)

二、需求分析

基于以上讨论的结果,相关人员可以输出需求分析文档,也就是这一项目需要实现的基本功能,性能,技术参数等;该需求分析文档应当是系统工程师/产品经理输出给研发工程师(软件,硬件,FPGA)用来进行项目开发的,同时测试人员的测试方案和测试用例也都由此产出

需求分析可按照如下模板格式编写,其中*产品介绍**功能需求*为必填项

1、项目背景

  • 介绍需求背景和市场分析:为什么要做这款产品
  • 需求场景和目标客户:什么样的用户在什么样的场景下使用本产品
  • 项目目标:对标XX产品,做成一款XX的板卡

2、*产品介绍*

  • 产品说明:用户可以在XX场景下,使用本产品来XXX
  • 产品定位:该产品预估售价XX,对标市面上的XX产品
  • 产品结构图:绘制原理图,功能结构图

3、*功能需求*

  • 功能点清单:罗列需要实现的功能点
  • 功能点描述:需求描述及原型

4、非功能需求

  • 性能需求:响应时间低于XX,时延低于XX
  • 兼容性需求:向下兼容XX版本,兼容XX操作系统

三、流程概述

Step1:测试方案/计划

根据需求分析设计测试方案/计划,测试方案包含

  • 测试范围:软硬件测试or纯逻辑测试,全功能验证or仅验证性能
  • 人力投入:需要XX人力投入XX个工作日
  • 预计完成时间:预计在XX年XX月XX日完成,该日期应该早于上线/交货日期3-7天。
  • 潜在风险点:一些可以预见的人力/技术问题,例如:缺少温箱,需要外部协同

【输出结果】XX项目测试方案文档

Step2:测试方案评审

开发人员和测试人员一同评审测试方案,指出测试用例设计与实际规格不符合的点

  • 某些关键功能的优先级调整:例如板卡性能应该追加多项验证,协议覆盖TCP/UDP,帧长覆盖短包/中包/长包
  • 某些不起眼场景的遗漏:例如当前板卡与前一代板卡组合使用的场景,两块板卡不同模式组合使用的场景

【输出结果】XX项目测试方秦评审-会议纪要

step3:测试用例设计

按照测试方案划分的范围进行测试用例设计,遵循如下方法,用例设计保证覆盖100%的需求

  • 等价类划分
  • 边界值分析法
  • 正交实验法
  • 因果图法

【输出结果】XX项目测试用例集

Step4:测试用例评审

这个环节不一定需要拉会议,中小型项目直接转研发评审即可,主要是为了检查

  • 是否有场景漏测:多为业务场景,功能组合场景
  • 功能并不支持:多体现在继承用例上,例如上代板卡支持2.5/5/10G,当前板卡已不支持2.5G

【输出结果】XX项目测试用例评审记录

Step5:测试用例执行

研发人员完成研发和自测工作,输出《研发人员自测报告》后,提起转测流程,交付给测试人员执行测试工作,例如当前存在两套方案,由武汉和杭州分别实行

  • 【武汉】测试人员在pingcode上勾选冒烟用例,研发人员按照该用例集完成自验,一键生成报告
  • 【杭州】研发人员按照代码逻辑完成自验并输出对应报告,确保该正式版本无误后转测

测试人员按照测试方案,执行测试用例,在第一轮手动测试完成后,开始自动化脚本编写,同时执行第二轮测试和可归测试。遇到问题立刻提单,开发超时无响应直接提单,提单不过夜,详见:问题单提单规范文档

【输出结果】XX项目测试问题单,XX项目自动化测试脚本,XX项目测试执行记录,XX项目测试报告

Step6:测试报告评审

需要拉通所有项目参与人员,测试人员汇报测试进度和结果,全体参与评审当前版本质量,遗留问题需要指定责任人和后续迭代排期

【输出结果】XX项目测试报告评审-会议纪要

Step7:线上问题漏测

1、客户现场反应回来的问题必须在第一时间处理,项目经理应当立刻组织研发和测试定位/复现问题

  • 研发人员根据问题现象和复现结果走位问题
  • 测试人员根据现场返回的问题信息着手复现问题

2、定位问题并完成修改或者无法定位问题制定规避措施后

  • 研发人员编译临时版本并完成自验
  • 测试人员完成同场景复现(此时问题不应该复现),确定问题修复后手动执行或自动化执行冒烟/全量用例验证版本(确保该问题修改成功且不会对其他模块造成影响),发版给客户验证

【输出结果】XX项目临时版本

Step8:AAR复盘

研发,测试,项目管理人员一同讨论确定该问题的根因,是如何引入的

  • 研发做代码review,检查其他模块是否有同类型的问题(如:空指针,死循环)
  • 测试检查为何漏测,是用例缺失还是测试未执行,针对性进行用例增补,检查其他模块是否有同类型问题

【输出结果】XX项目测试AAR复盘-会议纪要

结论

各家企业的项目流程不尽相同,也有大领导一拍脑门决定的,本文仅供参考,起码应届生在面试的时候可以轻松应付面试官提出的类似问题了。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值