软件测试学习心得-5

测试管理

  • 一.测试组织
      • 独立测试方法
        • 优点
        • 缺点
      • 测试团队的人员构成
        • 测试经理
        • 测试人员
  • 二.测试计划和估算
      • IEEE测试计划内容
      • 入口准则
      • 出口准则
      • 测试估算
        • 自顶向下的估算过程
        • 自底向上的估算过程
  • 三.测试过程的监控
      • 测试过程监控
        • 目的
        • 检测的指标
      • 测试报告
      • 测试控制
  • 四.风险和测试
      • 项目风险
      • 产品风险
  • 五.事件管理
      • 相关角色
      • 缺陷状态
      • 严重程度
      • 优先级

一.测试组织

独立测试方法

测试过程中使用的测试方法,与在项目分析和开发中使用的方法是不同的。一定程度的独立测试,可以避免由于开发人员对自己代码偏爱导致的问题,也可以更加高效地发现软件缺陷

优点

  1. 公正和客观性
  2. 专业性
  3. 权威性
  4. 资源有保证

缺点

  1. 整个组织的复杂度越来越高管理成本增加,当测试团队不属于该组织的时候,无法及时监控测试团队的测试质量
  2. 沟通效率降低,原来可能只是需要口头交流的问题,现在需要通过复杂的配置管理、缺陷管理和文档管理系统来解决
  3. 测试人员和开发人员的距离越来越远,项目团队氛围可能会下降,某些极端情况下甚至可能会出现开发人员和测试人员的对立现象
  4. 测试人员重点关注测试相关技能,对开发技能掌握得比较少,不利于发现系统需求和设计方面的缺陷
  5. 独立的测试团队可能降低开发人员对软件质量的责任感,开发人员可能会觉得产品质量应该是测试团队的事情,而不是整个项目团队的责任
  6. 独立的测试团队可能同时为多个项目进行测试,独立的测试人员可能被视为瓶颈或成为延时发布而被责备的对象

测试团队的人员构成

测试经理

  1. 与项目经理以及其他相关人员共同协调测试策略和测试计划
  2. 将测试的安排合并到其他项目活动中,例如集成计划
  3. 制订测试计划(要考虑背景,了解测试目标和风险),包括选择测试方法,估算测试的时间工作量成本,获取资源,定义测试级别、测试周期并规划事件管理等
  4. 启动测试说明、测试准备、测试实施和测试执行,监督测试结果并检查出口准则
  5. 根据测试结果和测试过程(有时记录在状态报告中)调整测试计划,并采取任何必要措施解决存在的问题
  6. 对测试件进行配置管理,保证测试的可追溯性
  7. 引入合适的度量项以测量测试进度,评估测试产品的质量
  8. 决定什么应该自动化、自动化的程度,以及如何实现。
  9. 选择测试工具支持测试,并为测试人员组织测试工具使用的培训
  10. 决定关于测试环境实施的问题
  11. 根据在测试过程中收集的信息编写测试总结报告

测试人员

测试设计人员/测试分析人员

  1. 分析、评审和评估用户需求、设计和模型等内容的可测试性,以便设计测试用例
  2. 创建概要测试用例和详细测试用例
  3. 准备和获取测试数据

测试自动化人员

  1. 负责设计和搭建模块化的、可维护的自动化测试环境
  2. 自动化测试需求分析和使用适合项目特点的测试工具实现测试用例的自动化脚本

测试系统管理员

  1. 负责或协助测试环境的规划和搭建,维护环境的正常运行
  2. 安装新的测试平台、被测试的系统等
  3. 优化测试环境,提高测试环境中网络、服务器和其他设备运行的性能

测试执行人员

  1. 评审和参与测试计划的制订
  2. 进行各种级别的测试,执行并记录测试日志,评估测试结果,记录实际结果和期望结果之间的偏差
  3. 根据需要使用测试管理工具和测试监控工具
  4. 在可行的情况下,测试组件和系统的性能
  5. 对他人的测试进行评审

二.测试计划和估算

IEEE测试计划内容

  1. 测试计划标识(Test Plan Identifier)
  2. 简介(Introduction)
  3. 测试对象或测试项(Test Items)
  4. 需要测试的特性(Features to be Tested) 。
  5. 不需要测试的特性(Features not to be Tested) 。
  6. 测试方法(Approach)
  7. 测试项通过/失败准则(Item Pass/ Fail Criteria
  8. 暂停准则/恢复要求 (Suspension Criteria and Resumption Requirements) 。
  9. 测试交付物(Test Deliverables)
  10. 测试任务 (Testing Tasks)
  11. 环境要求 (Environmental Needs)
  12. 职责(Responsibilities)
  13. 人员配备和培训要求 (Staffing and Training Needs)
  14. 进度(Schedule)
  15. 风险和应急(Risks and Contingencies)
  16. 批准(Approvals)

入口准则

测试执行入口准则指的是允许软件系统或者软件产品进入测试执行阶段所必须具备的条件。也就是说,提交的软件系统或者软件产品,必领满足入口准则定义的条件,测试团队才可以进行测试执行的具体工作

出口准则

测试出口准则的目的是定义什么时候可以停上测试执行,例如某个测试级别的结束,或者当测试达到了规定的目标

测试估算

自顶向下的估算过程

自顶向下的估算过程首先通过功能点或者代码行(功能点和代码行之间是可以相互转换的)估算整个软件系统的工作量。工作量估算中需要确定团队的生产效率,例如测试人员每天开发的测试用例数,该数据可以通过类似项目数据进行估算,也可以直接来自组织的度量数据。工作量可以在开发生命周期的每个阶段,按照一定的百分比进行确定(不同阶段的工作量百分比分布,通常也是从组织的过程数据库中获得的)

自底向上的估算过程

自底向上的估算方法通常是分解测试过程,然后进行估算的一种方法。采用自底向上的估算方法,测试经理首先需要将测试过程分解成不同的测试活动。针对每个不同的测试活动或者测试任务定义三个不同的难易级别:简单中等复杂。同时针对每个测试活动得到它们各自的工作量估算,所有测试活动的工作量之和就是整个项目的总的测试工作量估算。

三.测试过程的监控

测试过程监控

目的

测试过程监控的目的是为了测试控制提供反馈信息可视性

检测的指标

  1. 测试用例准备工作完成的百分比(或按计划已编写的测试用例的百分比)
  2. 测试环境准备工作完成的百分比
  3. 测试用例执行情况(例如执行/没有执行的测试用例数,通过/失败的测试用例数)
  4. 缺陷信息(例如缺陷密度、发现并修改的缺陷、失效率、重新测试的结果)
  5. 需求风险或代码的测试覆盖率
  6. 测试人员对产品的主观信心
  7. 测试里程碑的日期
  8. 测试成本,包括寻找下一个缺陷或执行下一轮测试所需成本与收益的比较

测试报告

测试报告指的是对软件系统或组件进行测试产生的行为及结果的描述文件。测试报告以文档的形式,描述了被测对象的测试情况测试结果,并对相关的结果和数据进行分析,向管理层提供信息建议。测试报告是测试活动的一个重要输出,必须得到管理层的批准,才能够成为正式的测试文档

测试控制

测试控制是对整个测试过程(计划、分析和设计、实现和执行、评估出口准则和测试报告、测试结束)进行控制,根据测试计划以及收集和报告的测试信息采取应对措施。应对措施可以针对任何测试活动,也可以包括软件开发过程中的其他活动

四.风险和测试

项目风险

项目风险是围绕项目按目标交付的能力的一系列风险,影响项目风险的因素主要由:组织因素技术因素供应商因素

产品风险

在软件或系统中的潜在失效部分《印将来可能发生不利事件或危险的部分)称为产品风险,因为它们对产品质量而言是一个风险,包括:

  1. 故障频发的软件产品或软件系统交付使用。
  2. 软件/硬件对个人或公司造成潜在损害的可能性。
  3. 劣质的软件特性(例如功能性、可靠性、易用性和性能等)。
  4. 低劣的数据完整性质量(例如数据迁移问题、数据转换问题、数据传输问题、违反数据标准问题)。
  5. 软件没有实现既定的功能

五.事件管理

软件测试学习心得-5

相关角色

  1. 测试人员:主要是指发现和报告缺陷的测试人员。通常情况下,测试人员需要对该缺陷后续相关的状态负责,包括回答相关人员对这个缺陷信息的询问,以及在正式版本上进行确认测试(再测试)和回归测试

  2. 开发人员:主要指对缺陷进行研究修复的开发人员。开发人员将修复后的缺陷提交测试人员正式确认测试之前,需要对修改后的缺陷在开发环境上进行验证

  3. 缺陷评审委员会:主要由项日经理、测试经理、质量经理、开发经理以及资深的开发人员、测试人员等组成。他们对缺陷进行确认,并将其分配给相应的开发人员进行修复,同时对有争议的缺陷进行仲裁

  4. 版本经理:负责将己经解决的缺陷相关的配置信息合并到新的版本。

缺陷状态

  1. 新建(New)
  2. 接受(Accepted)
  3. 分配(Assign)
  4. 打开(Open)
  5. 交付(Deliver)
  6. 解决(Resolved)
  7. 已修复(Fixed)
  8. 关闭(Closed)

严重程度

  1. 严重程度1(致命的):产品在正常的运行环境下无法给用户提供服务,并且没有其他的工作方式可以补救,或者软件失效会造成人身伤害或危及人身安全
  2. 严重程度2(严重的):极大地影响系统提供给用户的服务,或者严重影响系统要求或者基本功能的实现
  3. 严重程度 3(一般的):系统功能需要增强存在缺陷,但有相应的补救方法解决这个缺陷
  4. 严重程度 4(轻微的):细小的向题,不需要补救方法或对功能进行增强;或者操作不方便,容易使用户误操作

优先级

  1. 优先级1(立即修改):由于该缺陷的存在,导致开发活动或测试活动无法继续。该问题需要立即修复,或必要的话采取临时措施(如打补丁的方式)
  2. 优先级 2(下次发布前修改):在下次常规的产品发布或下次(内部)测试对象版
  3. 优先级3(必要时修改):在受影响的系统部件进行修订时进行修正
  4. 优先级4(木决):尚无修正计划

文章知识点与官方知识档案匹配,可进一步学习相关知识Python入门技能树首页概览208141 人正在系统学习中

来源:一个老废物

声明:本站部分文章及图片转载于互联网,内容版权归原作者所有,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!

上一篇 2022年1月8日
下一篇 2022年1月8日

相关推荐