系统测试计划

  • 系统测试是针对软件产品系统进行的测试(黑盒测试)
    • 功能测试:是否符合需求规格、功能设计、用户满意度
    • 非功能测试:容错性、稳定性、异常处理能力、高强度输入处理能力、可用性、性能
  • 系统测试(系统测试计划包含系统测试的设计、实现和执行的工作):
    • 系统测试计划:完成系统测试计划。软件产品的需求规格确定后编写。
    • 系统测试设计:完成系统方案。软件概要设计文档确定后编写。
    • 系统测试实现:完成系统测试用例、脚本。
    • 系统测试执行:执行测试用例、发现问题并回归测试、提交系统测试日报、提交系统测试报告。
  • 系统测试计划(一定要做到职责明确,与实际测试活动匹配):
    • 系统测试计划是从管理的角度来规划和控制整个系统测试活动。主要内容:
      • 组织形式(每个人的任务以及如何与别人协作)一般分成:
        • 项目组内:测试团队与其他团队间的分工和协作
        • 测试团队内:测试团队内各小组间的分工和协作
        • 测试小组内:测试小组内各测试人员间的分工和协作
        • 每个组织形式都由三部分组成:
          • 组织结构图:组织中各实体间的相互关系
          • 各团队职责:明确每个实体的任务
          • 协作形式:明确不同实体间的合作以及冲突解决方式
      • 测试对象(测试需求、测试项)。确定测试对象时需考虑以下因素:
        • 被测对象
        • 时间:同一系统,测试时间不同会导致测试对象有很大的不同
        • 测试目的:常见的测试目的有检测、证明、基本功能验证。根据测试目的的不同合理选择测试对象
        • 人力
      • 工作任务分配。进一步量化每个人的工作。
      • 其他需要注意的地方:
        • 需求跟踪:通过需求跟着可以了解还有哪些需求项没有测试
        • 通过失败标准:测试什么时候可以结束
        • 挂起恢复标准:测试什么时候需要暂停
        • 应交付工作产品
  • 系统测试计划写作:
    • 目标
      • 所有测试需求已被标识
      • 测试的工作量已被估计并合理分配了人力、物力
      • 测试启动、停止的准则已被标识
      • 测试的进度安排是基于工作量估计的、适用的
      • 测试待输出的工作产品是受控的、适用的
    • 概述
      • 项目背景
        • 项目背景
        • 主要功能特征
        • 体系结构
        • 项目的历史
      • 范围
        • 被测对象的版本/修订级别。软件的承载媒介及其对测试的影响。哪些对象不在测试范围内
        • 明确将被测试/不被测试的项目特征(性能、可移植性)和功能的简要列表
        • 测试的任务划分(计划、设计、实现、执行)和与开发各个阶段的对应关系
        • 测试各阶段任务的假设、约束、存在的风险
    • 组织形式
      • 组织形式需要确定组织结构以及结构间的关系。
      • 参与系统测试的组织的职责和关系。
      • 确定沟通渠道,确保测试发现并监督问题解决的权力。
      • 测试小组组织形式中测试组长职责:
        • 制定本组测试计划
        • 分配任务并指导、监督执行
        • 跟开发保持沟通。确定版本发布日期、版本质量进度、缺陷发展趋势
        • 组织本组测试文档的设计、写作、评审
        • 组织缺陷分析等质量活动
        • 向测试主管等高层领导汇报本组工作
    • 被测对象
      • 列出所有功能测试项目和非功能测试项目
      • 哪些特性不被测试和不被测试的原因
      • 如何确定系统测试对象
        • 参照软件质量模型中的 6 个特性,27 个子特性分析《软件需求规则说明书》及软件产品相关规范、章程
        • 将各个功能性需求和非功能性需求对应到各特性下(如果是某个或某几个特性的系统测试计划,只针对这部分特性进行分析)
        • 将各特性下较大的需求细化得到最终的系统测试项
        • 确定本次系统测试的测试范围和测试类型
    • 需求跟踪
      • 确定系统测试项与《需求规格说明书》或需求库中的需求之间的对应关系。建立系统测试项--需求跟踪矩阵表
    • 测试通过失败标准
      • 指明判断/确认测试何时结束。是测试过程通过或失败的标准,而不是被测对象通过或失败的标准。
      • 若通过失败标准只考虑测试活动的度量,可以定义如下目标:
        • 用例的执行情况要达到何种目标(例如:1、2 级百分百执行,3、4 级百分之五十执行)
        • 覆盖率要达到什么目标(例如:所有的功能需求、性能需求都被覆盖)
      • 若通过失败标准必须结合被测系统的质量,可以定义如下目标:
        • 达到何种测试的质量目标(例如:致命问题多少个、一般问题多少个)
        • 使用何种缺陷分析方法判断测试是否退出(例如:通过缺陷分析中的 Competz 分析可以得出测试已经充分,可以退出)
    • 测试挂起恢复标准
      • 挂起:测试无法进行下去或失去了继续测试的意义时,将测试活动挂起
      • 恢复:挂起的条件满足时,将测试活动恢复。
    • 工作任务分配
      • 工作任务分配是系统测试过程中的测试任务分工。
      • 划分方法(可以结合使用)
        • 可以分为测试的四个基本测试任务:计划测试、设计测试、实现测试、执行测试。每个任务下还可以划分子任务,针对每个任务应从 7 个主题描述
          • 任务
          • 方法和标准
          • 输入和输出
          • 时间安排
          • 资源
          • 风险和假设
          • 角色和职责
        • 按测试特性
          • 功能测试
          • 性能测试
          • 安全性测试
        • 按测试对象
          • 业务处理
          • 配置管理
    • 应交付测试工作产品
      • 工作产品可以作为测试任务的考评,一般包括:
        • 系统测试计划
        • 系统测试方案
        • 系统测试用例
        • 系统测试规程
        • 系统测试日志
        • 系统测试报告
        • 系统测试输入和输出数据
        • 系统测试工具
        • 自动化测试脚本
    • 工作量估计
      • 具体到人天
    • 资源的分配
      • 人员及培训要求
      • 测试环境、测试工具
      • 测试仪器和材料

 


                                                  欢迎扫码关注微信公众号「一朵儿的软件测试之旅」一起学习交流

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值