zoukankan      html  css  js  c++  java
  • 测试经验--测试流程总结

    一直想写一篇测试流程总结文章,在北京做测试工作3年之久,大大小小也接触了10几个项目了,简单总结下测试工作中的流程,大多为测试环节的优化部分,作为经验总结。

    一、测试过程之需求分析

      测试介入阶段大多从需求分析开始,需求分析阶段是整个软件生命周期最关键的一环,产品、研发、测试三方对产品需求理解应做到一致,所以需求评审会尤其重要,至少2轮以上。

      需求分析优化点:

    •  需求文档是否为完整版,本次测试范围先确定出来,优先分析
    •  阅读需求文档将不明确、不理解需求做批注标记
    •    利用思维导图Xmind工具,将需求文档功能模块大概画出来,需求评审可做参考
    •    阅读需求文档第一遍,应仔细通读一遍,提前准备需求评审问题单,做到有准备的评审
    •    对于新增需求,应尽可能关注对已实现功能的影响范围、关联性等
    •    需求文档存在很多不确定需求,测试应注意风险,及时与产品沟通,确定最新需求文档,避免测试阶段增加沟通成本

      以上几点仅供参考,需求文档还包含(需求文档规格书、产品原型图、详细设计说明书等),建议测试人员做到专业,在每个环节都严格把控,保证项目整体的质量

    二、测试过程之测试计划、测试方案

      测试计划大多为测试组长编写,主要包含测试目标、测试资源、测试策略、测试需求(功能、性能、接口)、测试进度计划,根据项目总体排期表,制定出测试排期与人员安排计划。

      测试方案为具体实施的方案,主要包含测试需求细化、测试组网图设计、自动化测试设计、测试数据和测试脚本、测试用例设计等,项目测试负责人编写即可。

    三、测试过程之测试用例编写

      测试需求评审通过、测试计划、方案制定好后,便可进行测试用例编写工作了,可根据详细需求文档、Xmind思维导图、产品原型图、研发详细设计文档进行用例编写,通常按照系统功能模块划分编写范围。

      测试用例优化点:

    •    测试用例结构设计,请参考另外一篇文档 https://www.cnblogs.com/xjx767361314/p/9516654.html 清晰的结构方便后期用例的维护
    •    测试用例编写规范,每个公司的大概都有自己的规范,包含用例基础信息的描述、用例执行信息的编写、用例的生命周期等,建议按照规范编写,便于其他人执行与维护
    •    测试用例评审流程,测试用例评审切不要走马观花,尽量让研发与产品给出专业建议,可分为线上与线下评审,建议进行线下评审,与研发、产品可直接交流沟通,做到功能无遗漏、无疑问的一份测试用例
    •    测试用例维护,评审后的用例、需求文档更新、研发实现方式改变等因素,我们需要定期维护测试用例,建议增加测试用例维护日志记录

    四、测试过程之缺陷管理

      缺陷的管理每个公司都有自己的管理平台,合理的管理缺陷、分析缺陷不仅可以提高产品质量还可以提高工作效率。

      缺陷管理优化:

    •  BUG创建最好能与研发人员意见达成一致,在提交缺陷系统,如遇歧义与项目经理或产品人员进行确认,保证意见一致
    •    BUG规范,如命名、描述信息、版本信息、严重程度、缺陷类型、附件(图片、文件)、留言,尽量做到简单直接描述一个缺陷
    •    BUG跟踪,一个缺陷的生命周期分为几个状态,还可能变更修复人、验证人等信息,及时跟踪并做好缺陷留言,以免遗漏
    •    BUG定位能力提升,测试人员尽可能的发现问题,并试着去定位问题,总结问题,不仅可以提升自身技能还可以让研发高看一眼
    •    BUG分析,一个项目结束,缺陷分析是必不可少的,包含BUG严重等级分布图、版本与BUG数量趋势图、模块BUG占比图、缺陷类型图等,可以从多个角度分析缺陷的产生原因并如何去减少缺陷的产生数量
    •    版本控制,建议测试人员自己做版本控制,提测版本、提测脚本、提测范围等走邮件流程,保证缺陷与版本的对应关系,以免混乱

      以上几点仅供参考,根据统计分析缺陷大多出现在研发自测不过关、需求文档不明确、设计不合理等方面,所以我们制定出研发自测用例集、增加单元测试、主动召开需求评审会等,在提测之前规避缺陷的发生。

    五、测试过程之风险控制

      测试作为项目质量的最后一道关,可谓责任重大,所以超前的风险意识是必不可少的,避免成为千年背锅侠。

      风险注意点:

    •  测试需求确认后,尽可能拿到项目排期,明确提测时间点、提测范围、上线时间点等,如遇变更及时调整
    •    需求、设计中途变更,为了工期压缩研发时间与测试时间,此时风险很高,研发代码质量差频发,测试耗时耗力
    •    提测时间点推迟,应提前和项目经理沟通,增加测试人力或延长测试时间,保证测试的质量
    •    研发不进行冒烟测试,提测阶段发现问题,重新发布版本,浪费时间,应与项目经理沟通,保证冒烟测试的通过才可以提测,测试可提供冒烟测试用例
    •    研发人员技术参差不齐,应先测试新人研发的模块或研发质量差的模块,争取更多的修复缺陷时间
    •    测试环境变更,有些项目需要特定的环境,测试环境与生产环境存在差异,导致上线后问题频发
    •    测试人员技术水平不同,特别外包新进人员,对于质量的把控与产品理解不到位,造成测试标准的误差

    六、测试过程之测试总结

      一个项目测试结束,笔者比较主张进行测试总结,涉及测试环境信息、测试数据备份、测试项目总结、测试范围列表、BUG整体的分析与统计、测试报告等。

    •  提高项目的完整性,无论维护人员还是测试人员,都可以一目了然了解项目情况
    •  为测试类似项目积累经验,包括测试方法、测试数据、测试工具的复用,减少测试风险提高测试效率

    备注:项目文档管理工具SVN、测试管理工具禅道

  • 相关阅读:
    pat 1123 Is It a Complete AVL Tree
    pat 1098 Insertion or Heap Sort
    pat 1147 Heaps
    Python中的Dict底层 | 字典类型删除数据为什么不直接删除?
    MySQL | 重置root密码
    MySQL | 安装后初次使用
    安装MySQL | 报缺失文件的错误
    IDEA | 不使用骨架创建Maven项目
    python | list.sort()和sorted(list)的区别
    python | 字符串不可修改
  • 原文地址:https://www.cnblogs.com/xjx767361314/p/9541204.html
Copyright © 2011-2022 走看看