【测试需求分析】

测试需求分析阶段✝️

软件需求 = 功能性需求 + 非功能性需求（性能、易用性、可靠性…）。

1、软件需求的分类

• 业务需求：从业务场景、业务流程方面定义的内容，一般是由产品经理提供的，以user stroy的形式给出。
• 系统需求：用户所需要的所有的功能和非功能性需求的集合，一般是由开发团队提供，在业务需求的基础上进行的细化
  • 功能性：开发要实现的用户所需要的功能，注册功能、登录功能、查询功能、加购功能、下单功能、支付功能等。
    • 注册功能：用户名、密码、邮箱等
      • 用户名：用户名是由数字、字母、下划线组成，长度在4~26位之间.
      • 邮箱：符合邮箱的格式xx@域名.com；邮箱名必须20位以内等
      • 密码：只能是数字，要求必须是6位。
  • 非功能性：8大质量特性中除了功能性的，都是非功能的
    • 性能需求：
      • xx功能的响应时间不能高于500ms
      • 系统运行过程中，cpu使用率不能高于80%
      • TPS必须达到2000
    • 兼容性需求：
      • 支持window和macos和linux系统平台
      • 支持edge（windows的最新版，ie已经被淘汰了，兼容了chrome）、firefox、chrome、safari、opera等

2、测试需求（测试需求规格说明书、测试需求跟踪矩阵）

测试需求是在软件测试的需求分析阶段，通过各种手段、渠道获取软件的业务需求、系统需求，进行软件的可测性分析形成的文档，是后续软件测试过程的参考依据之一。

简言之：将可以获取到支持文档，汇总成测试需求规格说明书（测试需求跟踪矩阵：每一条需求来自哪一个上层文档），目的是要做到有据可依、有源可查。

3、测试需求分析

• 分析测试范围：不是所有的需求都需要在当前版本中进行测试，要根据模块的核心程度确定要测试的范围。
• 可测性分析：某个需求在当前版本中是否具备可测性
• 明确测试的类型、阶段：
  • 阶段：基本就是确认、系统和验收测试，在互联网企业中，测试人员直接参与单元测试和集成测试的较少
  • 类型：功能性测试、非功能性测试
• 优先级划分：识别那个需求要优先测试、哪些需求可以滞后测试、哪些可以正常排队

4、测试需求评审

测试需求规格说明书是作为后续测试工作的指导性文档，就需要进行配置管理，形成基线文档（标准）。

通过专家评审的文档（先评审、修改、提交批准），形成基线，加入三库管理（产品库、受控库、开发库）。

评审的类型：

• 相互评审、交叉评审：最不正规的，测试团队内随时可以搞定的
• 轮查、走查
• 小组评审：小组之间进行评审；
• 审查：最正规的一种，一般要邀请外部的专家参加