您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
   
 
 
     
   
 订阅
  捐助
软件测试团队组建构想
 
作者:blacklist 来源:51CTO 发布于 2015-8-21
   次浏览      
 

1、前言

进入公司半年有余,接触公司的开发项目至今,对公司的情况有了更深的了解。在此提出一些建议,希望可以对部门组建测试团队起到贡献微薄之力。

1.1 开发部现状

目前开发部完成或未完成的项目基本存在如下情况:

软件交付迟迟不能按照计划时间如期交付关闭;

大项目合同金额小,加之开发部人力资源有限,导致项目不赚钱或赔钱;

需求随着开发的深入不断的新增或更改;

外包人员的开发能力、对项目不够负责的态度等问题,不仅导致项目质量的低下,间接导致后续交付的种种问题;

测试团队依旧没有雏形,测试人员利用率低下或高投入低产出;

上述的几个问题体现出开发部的人力资源、管理体系和组织机构不够完善,仍需要管理阶层花些心进行规划完善。

2、测试人员在软件开发各阶段任务

表1:软件测试流程

软件测试流程如表1,包括测试计划、测试设计、测试执行及测试总结,测试人员的主要任务:

尽早的发现问题,尽可能的发现软件程序、系统和产品的问题;

针对问题进行分析、分类总结和跟踪;

督促开发人员尽快解决程序中的缺陷;

帮助项目管理人员制定合理的开发计划;

帮助改善开发流程、提高产品开发效率;

2.1 设计

设计包括需求设计、概要设计和详细设计,目前开发部的需求设计似乎涵盖了3种设计;测试人员在该阶段需要做的就是:熟悉需求,对需求的熟悉程度应该高于一般的开发人员;

2.1.1 现状

深分开发部二次开发项目周期短,项目需求不尽相同,测试人员未参加需求调研和设计,很大程度上是个人对文档的理解或同项目经理、需求人员的确认。

影响:

1、对需求理解肤浅不够深刻;

2、部分需求印象不深或毫无印象,导致需求遗漏;

3、刻意遵守文档内容或开发人员的设计,缺少个人观点;

4、编写测试用例产生该覆盖的需求没有涉及,不用验证的却编写了测试用例;

2.1.2 建议

需求评审

需求设计人员完成软件需求说明书,要发给参与项目的每位同事进行需求评审,参与评审的人员要列出需求说明书中存在的问题及疑问;

需求评审会

需求评审会的目的是讲解并解答评审人员针对需求说明书所提出的问题及疑问,更改需求中的问题,完善软件需求说明书,需求评审会也是加深需求理解的好途径;

需求变更/新增

项目需求变更/新增,必须通知测试人员,更新需求说明书要及时发布最新的版本。

注:设计阶段可能包括项目开发计划,此阶段要相应的出测试计划;

2.2 编码

编码阶段测试需要编写测试大纲、测试用例,根据项目具体情况,决定测试用例的详细程度,但需求功能点必须全部覆盖。

测试用例文档由简介和测试用例两部分组成。简介部分编制了测试目的、测试范围、定义术语、参考文档、概述等。测试用例部分逐一列示各测试用例。每个具体测试用例都将包括下列详细信息:用例编号、用例名称、测试等级、入口准则、验证步骤、期望结果(含判断标准)、出口准则、注释等。

测试用例是软件测试的核心,测试用例需要完善的情况包括:

第一、在测试过程中发现设计测试用例时考虑不周,功能点缺失;

第二、软件自身的新增功能以及软件版本的更新(需求新增及变更),测试用例也必须配套修改更新。

第三、在软件交付使用后反馈的软件缺陷,而缺陷又是因测试用例存在漏洞造成;

2.3 测试

测试的流程如表1所示,测试执行阶段是一项重复劳动,所以我们应该尽量避免无用功。那么测试计划就显得相当重要。

测试计划是在软件测试中最重要的步骤之一,它在软件开发的前期对软件测试做出清晰,完整的计划,不光对整个测试起到关键性的作用,而且对开发人员的开发工作,整个项目的规划,项目经理的审查都有辅助性作用。

测试计划的目的包括:

(1)将需求和总体设计分解成可测试,应该测试,推迟测试和无法测试的范围

(2)对每个范围制订测试的策略和方法

(3)制订release和停止测试的标准

(4)准备测试所需要的环境

(5)确定测试风险

(6)确定软件测试目标

(7)确定测试所需要的资源其他相关信息

(8)制订测试进度和任务安排

2.3.1 现状

目前开发部测试人员测试计划设计相对较少,也存在没有测试计划的情况,总体来说开发部现在的情况如下:

1)项目周期小,不需要测试人员参与;

2)一个测试人员应付一个项目;

3)测试人员对项目情况不够了解,工作没有主观能动性;

4)开发的人员缺少软件集成测试,不间断的更新版本;

5)缺少测试文档及缺陷管理体系;

2.3 建议

重视测试计划的设计;

完善测试流程,制定测试标准;

需要增加测试人员,完善测试的梯队;

2.4 交付

目前部门并没有出具相应的测试报告或出局了相对简单的测试报告,测试报告是软件测试重要的输出文档,一个完整的测试报告应该包括如表2,测试报告应该让看到报告的人对项目测试情况一目了然。

表2:测试报告内容

3、测试团队组建

3.1 测试机构

测试团队的组成一般由测试组长、资深测试工程师和初级测试工程师;

1)测试组长:负责项目的管理、测试计划、测试用例、任务安排等;

2)测试设计人员/资深测试工程师,产品设计规格说明书的审查、测试用例的设计、技术难题的解决、培训和指导、实际测试任务的执行;

3)一般(初级)测试工程师,执行测试用例和相关的测试任务。

4)需要的情况下可以设置专门的性能测试工程师;

图1:测试梯队

目前,公司希望几个分散的测试人员组成一个测试团队不太现实,且没有测试的梯队架构,这样就会导致员工激情的减少。

3.2 测试团队地位

图1 三国鼎立

测试机构在组织中地位的确定事关测试机构执行测试任务的效力。测试机构的独立是十分重要的。

目前,开发部为项目组配备一个测试小组几乎是不可能的,但是我们至少应该在整个研发部门成立独立的测试小组,统一开展测试任务的执行,同时为保证与不同的产品紧密衔接,应该实行责任测试工程师制度。

测试团队应直接向研发部门的质量总监负责,质量总监在研发部门的地位应该等于或者高于开发团队的最高负责人,只有这样才能保证测试机构的权威性。

3.3 规范执行

针对目前深分开发部的情况,首先要做的是以下三个方面:

第一,建立缺陷管理信息系统,收集整理遗留的缺陷,报告相关数据;

第二,建立严格的版本管理制度,追踪发布的每一个版本;开发提供不断修订的版本,这样导致了修复问题的代价变得越来越大,因为每一次修改都很仓促,常常是解决了这个问题,衍生出很多其他的问题。解决这个问题的关键是建立严格的版本管理,任何一个版本的发布都必须经过测试小组全面的测试,同时详细记录每一个版本的信息。这些都与配置管理息息相关,所以测试体系的建设中还必须建立有效的配置管理。

提第三,高开发人员的编码质量,建立严格的代码评审制度,对于外包开发人员,需要考核外包人员能力,最好有可以进行代码走读能力的开发人员;

   
次浏览       
相关文章

微服务测试之单元测试
一篇图文带你了解白盒测试用例设计方法
全面的质量保障体系之回归测试策略
人工智能自动化测试探索
相关文档

自动化接口测试实践之路
jenkins持续集成测试
性能测试诊断分析与优化
性能测试实例
相关课程

持续集成测试最佳实践
自动化测试体系建设与最佳实践
测试架构的构建与应用实践
DevOps时代的测试技术与最佳实践
最新活动计划
LLM大模型应用与项目构建 12-26[特惠]
QT应用开发 11-21[线上]
C++高级编程 11-27[北京]
业务建模&领域驱动设计 11-15[北京]
用户研究与用户建模 11-21[北京]
SysML和EA进行系统设计建模 11-28[北京]

LoadRunner性能测试基础
软件测试结果分析和质量报告
面向对象软件测试技术研究
设计测试用例的四条原则
功能测试中故障模型的建立
性能测试综述
更多...   

性能测试方法与技术
测试过程与团队管理
LoadRunner进行性能测试
WEB应用的软件测试
手机软件测试
白盒测试方法与技术

某博彩行业 数据库自动化测试
IT服务商 Web安全测试
IT服务商 自动化测试框架
海航股份 单元测试、重构
测试需求分析与测试用例分析
互联网web测试方法与实践
基于Selenium的Web自动化测试
更多...