整理下测试流程

上一篇 / 下一篇  2013-04-24 22:51:14 / 个人分类:测试基础

   在外包工作工作了两年了,虽然有一份号称测试流程规范的文档在那,但是不起丝毫作用,在实际项目中大家就是意思下,给我们测试人员的工作带来了很多不便,各种重复的工作量、有风险的妥协等。期间有幸负责过一个华为的外包项目,华为的规范流程和严格要求给我带来了很大触动,做测试就是要这样!!项目立项后,项目就开始启动,整理下整个测试流程如下:

1. 测试准备阶段:
  • 需求培训:【由于未参与,借鉴下别人的经验】华为客户会提供一份《委托项目开发任务书》和一份《规格基线》,这两份是对需求的描述。华为方派人过来进行需求培训,这时该项目的测试组长也要参与到项目需求的培训和评审,也就是测试工作应该从需求开始介入。
  • 细化需求:测试负责人需要组织项目中比较有经验的测试人员分析需求,进一步细化需求的功能点,一个大的需求点包含多少功能点,特别要注意整理出之前开发甚至是客户未考虑到的,拿出来跟开发负责人、开发骨干人员以及客户讨论。整理出最终的Feature list.测试需求是后续测试工作的基础。
  • 测试计划:在项目经理完成的《项目计划》、开发提供概要设计的同时,测试leader需要开始编写《测试计划》,然后是测试计划的审核工作
  • 测试方案:整体测试方案、策略和特性测试方案,分别由测试leader和各个模块的测试人员负责,这是编写用例的基础。然后测试方案审核即可
  • 人员培训:经过设计细化需求、设计方案、设计策略,测试人员对项目已经比较了解,下面需要对测试使用到的工具、测试流程、bug管理工具、质量标准、交付文档编写规范、测试环境等进行系统的培训,让大家对整个测试工作有更规范的认识,其中,在对流程、bug的管理、质量标准等培训中,要求开发人员一同参加,以便达成一致的认识。
  • 整个测试准备期间,测试leader需要和客户项目负责人等沟通很多细节,主要原则就是如何保证项目可以正常启动测试、可以顺利完成测试、了解交付标准等,所以会有一些类似《人员名单》、《测试标准》、《项目日程》、《阶段软件要求》、《合作事务跟踪表》、《购买设备说明》、《工作量评估》等。期间尽可能所有沟通有邮件记录,口头会议有会议记录,这样方便整理项目细节。
2. 测试设计阶段
  • 测试用例:如果没有像TestLink这样的工具,就需要提供用例编写模板,组织各个模块的主要负责人来编写用例。用例的编写主要是依据审核通过的《特性测试方案》,方案中已详细列举出比较细致的功能点,达到用例的二级甚至三级标题的级别。编写者结合常用的编写用例方法:等价类、边界值、因果图等,编写出符合规范的测试用例。
  • 一般公司都会有用例的积累,所以编写时可以参考公司的用例库类似项目的用例
  • 用例评审:同级评审、组内评审、客户评审。
3. 测试实施阶段
  • 测试环境:设备到位,搭建测试环境
  • 各阶段测试:华为的终端项目采用过点的方式,每个阶段都有明确的过点要求,分享下我们项目组的过点要求,整个测试周期分为TR4 ~ TR6这4个阶段,这是华为的一种特殊称呼方式,等同于我们平时称呼的:Alpha、Beta1、Beta2、Release四个版本,各个过点之间也会发布一些中间版本进行测试,具体在确定《测试日程》时都需要明确。
  1. TR4过点要求:
    提供完整的软件Alpha版本;提供完整的测试策略和测试用例;系统测试用例;提供所有文档,包括质量过程文档;遗留问题不能阻塞某些功能测试;无致命问题
  2. TR4A过点要求:软件不阻碍硬件的完成,解决TR4A前(含TR4A点)发现问题的75%;交付Beta1软件代码
  3. TR5过点要求: 实现所要求的所有功能;交付Beta2软件代码;遗留无致命问题;严重问题数<=3;DI值小于25分
  4. TR6过点要求:交付Release版本;实现所有需求功能;无致命问题;无严重问题;DI值<=15
  • 阶段测试详介:在这里就大概介绍下每个阶段的大概流程。之前的版本你测试完毕时,会对下个版本定个质量要求,基本达到要求后,开发会计划提供版本,发布时需要根据测试提供的核心用例把最基础的功能过一遍,通过后可以提交给测试组测试。提供版本的同时,需要附带版本的release notes,注明实现了哪些功能、改进了哪些问题、可能影响的部分等注意事项。与此同时,测试负责人需要重点考虑,此次版本测试的周期、人员、设备是否到位,是否需要进行交叉测试等准备工作。测试人员拿到版本后,会进行预测试,未实现本次版本的质量要求或者有重大问题时,版本会打回,如通过,可以启动版本的系统测试。这里需要强调一点是,如果是过点版本,需要把版本测试大概情况反馈给华为客户,客户同意后才可启动系统测试。
    华为使用的bug管理工具是DTS,该工具的流程非常全面,所有问题都需要有测试和开发的所有问题处理都有测试负责人和开发负责人的审核,每个流程都有对应的返回处理流程,在这里不做具体介绍了。具体bug的处理流程就依据DTS的具体要求。
    测试过程中,测试负责人需要定期的反馈《测试日报》,反应当前的困难、风险、bug情况、测试进度等。测试结束后需要有对应的《测试报告》。
    一轮测试结束后,有个很重要的工作要做,就是本轮测试的总结,主要工作包括:各个模块的测试总结、重点问题、漏测分析、用例可行
性和覆盖率分析、阻塞问题分析等,以便组内优化工作,当然这些问题也需要跟华为客户反映,他们会协助一起推动解决, 
    需要特别说明的是,为了保证过点版本达到质量要求,既要根据组内情况对过点之前的版本进行质量预估,对处于开发阶段的过点版本要有更高的质量要求,比如过点要求解决所有有效问题的75%,那开发需要对这个过点版本要求解决问题在80%甚至85%,因为一般的公司发布版本后标注的已解决的问题,都有被reopen的情况,所以按照75%发布,测试完毕会发现,达不到要求,白忙活一场啊~~最终过点时,达到质量标准后需要华为方点头通过,即可付款了~~

4. 测试评价
  • 阶段测试评价和最终release版本测试评价:这些在平时会议和测试报告中都会及时反映出来,如果不在华为场地外包而是在自己公司,就有可能存在公司上层给测试施压,美化测试报告或者在bug上做些手脚,这时如果无力拒绝,请如实邮件发布出项目真实情况并要求项目经理回复要改动的邮件,这样也算有个证据咯~
5. 验收测试阶段
  • 正常的流程是由客户组织华为本部的人进行验收测试,通过即可。但是我们项目比较特殊,直接由华为测试经理一人来公司验收,估计也是因为项目延期较久,他们不想难为我们吧,他一人的验收自然是比较顺利的,没什么严重问题。

    实际工作中发现,规范流程是高效工作的前提,在最初极不规范的流程中,测试人员的有太多的重复工作量,和一些没质量意识的开发对话让我们更头疼,以后工作要注意咯。
     以上是项目的一些心得,欢迎大家提问和纠错!
      




TAG:

 

评分:0

我来说两句

Open Toolbar