软件测试的时代 - 软件测试思想、软件测试技术新体验
 
 案例分析

 
 
 


案例分析第四期(2005-06)

你在日常的工作中没有遇到问题吗?如果有,你也可以提交案例。【我要提交案例
案例分析
   
本期案例
题目:如何让开发控制提交的测试版本的质量?
所属主题:配置管理
作者:lovetest
案例内容:
  开发提交给测试的版本有的时候是因为没有更新最新的代码,打包错误等等原因导致好容易发布的版本不可测,浪费大家的时间。或者是开发人员没有完全改好问题,改好你提的问题却又引发了别的问题。
解决方法:
  曾经考虑过拒绝测试,但是最终提交的时间是定下来的,打回去拒绝测耽误了测试的时间,测试更被动。
求助问题点:
  怎样采取一个有效的措施来控制提交版本的质量呢?单纯的靠开发人员的责任心?这感觉也有点太虚了,不知道大家有什么好的建议?
相关分析
   
分析一:
  作者:味书生
  分析内容:
1.首先我们要定义出开发的出口标准,要求非常细致的纪录。
  测试人员可以早介入,将交互点处理成一个交互式间段,这样就可以有效地促进开发向可测试标准运行,同时作为测试人员可以准确地了解到项目的状况,不至于在测试开始过于被动,还可以根据开发的情况及时调整计划,同时向上层提出报警。一定要做接受测试报告,及时地反应项目的情况。
2.测试组开发组共同建立一个好的合作模型。
  现实中我们必须处理开发质量低下的问题,而且必须考虑与开发并行的问题,也就是说没有绝对的不介入集成测试,甚至单元测试。所以在前期项目计划时,就要与项目经理达成一致的标准(最高标准,最低标准),最低标准也就是你最差可以接受的情况,增加各个环节的审核,通过多个项目的磨合和总结,得出一些可行的明细标准。
分析二:
  作者:小蚂蚁
  分析内容:
  这个问题我曾经也问过别人,我说的只是和黑盒测试相关的内容,我个人的建议是:
1、在项目前期,测试人员就应该介入,同时针对这个项目的开发流程制定一个测试流程。
2、测试流程里包含了程序测试的入口和出口标准,当然这个标准要得到开发人员以及项目负责人,项目经理的认可。
3、在入口标准里,针对这个项目的黑盒测试制定一套测试点,通过测试点的进入测试人员手里测试,没有经过的打回给开发人员,当然,这个测试点是要对项目比较熟悉或者很有经验的测试人员来做了。入口标准做好了,对后面的测试工作是否有效是有很大影响的。
4、公司领导要重视测试部门的工作,如果工作上不给予理解和支持.建议你跳巢吧!
分析三:
  作者:baitest
  分析内容:
1.在项目前期测试人员应当及早介入了解项目的进度安排,并制定一套的流程。
2.项目组应当配一个协调员,随时和开发沟通,同时负责测试程序版本的控制。
分析四:
  作者:小颖
  分析内容:
  开发项目组在建立时,本身就应该包括测试人员,测试人员应作为项目组的成员参加一切关于开发工作的会议,交流及讨论,有利于了解开发的方法及开发的各项信息。
  对于版本管理,理想状态应存在一名配置管理员,作为测试人员与开发人员的交接点对程序版本进行管理,测试完成版本返回配置管理员,开发修改完成版本也给配置管理员,由配置管理员再交给测试人员;但一般公司不会设立这个岗位,而有即便是设了,也不能充分的发挥作用(我们公司就这样)
我认为的解决方法:
1、测试人员接收程序后,在存放时以程序名称和时间作为标识,并且每一次提交的程序一直到项目结束后再删除
2、开发人员提取修改后程序时,不要直接测试,先查看一下上一次程序错误的位置是否修改(与机器中保留的上一次提交版本核对)。
3、检查后,再开始动手测试,如果真的有没有修改的地方,那就再算一次错误,不能总是替他们想的。
分析五:
  作者:flygold
  分析内容:
  规定deadline,如每日12:00以后,不允许版本更新。
分析六:
  作者:cissy
  分析内容:
  小颖所说的方法与我们公司现在进行的方法比较一致。但个人感觉确实没有很好地得到贯彻实施~~
  我们公司现在在项目的立项阶段后就由测试部派谴了质保员进行跟踪,但由于级别的不一致,引不起项目组的重视,有时只能是很浅地介入项目组的开发进程,应有的作用没有得到发挥。幸好本部门的部长比较重视,一直在维护质保员的重要性、权威性,希望以后这种情况能得到改善。
  确实现在这种状态很普遍,也没有什么很好地解决办法。要想真正地有效地体现测试的价值,只有从上头做工作,让高层真正地支持你,给开发人员一定的压力,才能让测试工作真正有效地进行。
分析七:
  作者:akchenyanjun
  分析内容:执行CVS
分析八:
  作者:rosemei
  分析内容:
  个人认为 :开发人员提交测试需代单时,把需要测试的目的描述清楚,其中包括其代码更新部分需要接受验证的内容描述,测试人员根据测试需求单,首先验证其版本更新后的内容,是否通过,以更新内容为接入点,决定是否能够尽快尽早的打回给开发人员。
  至于其修改后又引发其他地方的错误,这是个无法控制的,只能看开发人员修改BUG的严谨性了,通过奖惩激励的办法,提高开发人员的开发技能是关键。
分析九:
  作者:spring_post
  分析内容:
  项目开始的时候,测试部门是要参与的(原因不用多说了),但是一旦项目处于实现过程时,理想的做法是测试部门定期对成果进行测试(通常是一周一次,由RE将现有成果建立一个BUILD交给测试部门)此时开发和测试是并行的,可用CVS管理各个版本(很好用的噢~)至于BUG的提交、确认、修改也都是同时进行的~当然开发人员有责任对所开发的模块做相应的组件测试~RE在此过程中的作用是相当大的~
分析十:
  作者:ppent
  分析内容:
  个人认为本案例的焦点是如何控制开发人员提交代码、打包版本的质量,而与测试人员何时介入项目是没有很大的联系的,还有楼上说的通过入口标准、检查后再测试,那是事后的补救办法,但还是可以减少测试人员不必要的资源投入。
我的看法:
1.记录每个提交代码、编译打包版本的质量情况,每月/季度进行发布。让大家清楚的看到本阶段的各个版本中谁犯了了“没有更新最新的代码、打包错误、bug没有改好、bug改这个错那个”的错误。有了这样的统计结果,相信以后不管是开发人员还是打包人员都会更加小心的。
2.如果有必要,可以根据上面的结果建立奖惩制度。
3.采用配置管理工具,进行良好的版本管理,防止代码更新遗漏、错误的情况。
4.如果是接近发布的版本,慎重起见为了防止改bug而带来的新的bug,需要评估每个bug修改的难度、优先级、风险等,是否有良好的解决办法,或者在下个发布版本中修改。
分析十一:
  作者:小胖子
  分析内容:
  前面几位的方法在实际的工作中都是使用过的,但是制度是理想的,实施起来就不是很理想。我遇到一个开发人员写的程序,基本上是无法使用没有一点是根据需求规格说明书写的。但是我还是耽误了两周的时间,最后我在例会上向项目经理提出了正式的交涉,才引起公司的注意。最终那个开发人员因为工作能力问题离开了公司。
分析十二:
  作者:自得其乐
  分析内容:
  我们公司现在的做法是在提交测试之前由开发人员先做VT,测试人员拿到新版本后也是先做快速测试,没有大的功能性问题才接受该版本,如果随便点一个功能就报底层的错误,就说明开发VT没有做好,可以打回该版本,由测试员提交delay报告,说明这个版本延迟提交的原因。由管理中心进入来跟踪查找原因,所以长期这样开发人员一般对于提交的版本还是比较谨慎的。
分析十三:
  作者:chimi
  分析内容:
  在我单位,具体操作是这样的:
1.BUG 的跟踪要抓紧,必须有一个BUG的跟踪系统来管理BUG。
2.版本的发布和测试版本的管理,要以BUG 管理系统为依据。
3.新加功能的跟踪也可以用BUG 管理系统那里实现。
4.每次开发人员修改了BUG 或者是 完成了新添加的功能,都必须在BUG 管理系统那里作说明。
5.每天安排一个指定时间来获取最新版本的程序来做测试,当然之前要确认他们都更新了代码,编译服务器也要准时、成功的编译好测试的版本,确认他们对自己的工作都作了记录(记录到BUG 的管理系统)。
6.开始测试新版本的程序。只要其中一环还没有完成,那部分的内容不作为测试考虑。
分析十四:
  作者:nio
  分析内容:
  其实作为测试来讲,没有必要关注这个问题。
  测试的主要目的是发现问题,至于版本问题,以及BUG有没有修好,那不是我们测试人员要关注的。我们要做得是如实的反应问题。
  这个问题的出现根源在于测试人员有太多的意见(牢骚),出现这样的问题,我们要做的是告诉开发人员,在这个版本中有些BUG并没有修好,至于为何会出现这样那样的问题,则和测试一点关系也没有。
  楼上几位的观点,使我认为测试的责职太多……测试其实和版本控制、进度控制等扯不上什么关系吧?一般来说这两个工作是有专人负责的,不是么?
测试时代工作室分析
   

  问题一:该案中Team的沟通平台建设有问题,没有建立组间协调的基本准则,和监督手段,这样会出现没有完成的工作可以提交甚至是移交给下一个环节。
  问题二:该案中没有说是否采用了配置管理工具,但很显然配置管理规范是没有做的。
  问题三:该案中的Team Leader 没有起到疏通流程,接收反馈,改进过程的作用。
  问题四:该案中尚没有建立很权威的软件质量标准。
  高质量的工作=过程+管理+技术
  首先,过程。应该说现在很多软件公司的工作流程都很不完善,需要过程改进。而且更多的时候需求管理和配置管理是过程改进的关键和瓶颈所在。需求管理和配置管理不善就会直接的给开发和测试工作带来负面影响,尤其给测试和开发人员的沟通增加了障碍。导致效率不高,就如本案中提到的问题点。那么配置管理的过程是什么呢?如下图
  
  当项目组有越多的成员的时候,制定一个规范的流程就显得越发的重要。
  第二,管理。所谓“无规矩,无以成方圆”,在做好管理之前制定一套合理的管理规范是必须的,流程有了,但是管理不善也是会功亏一篑的。配置管理,可以说是时间、人、工作内容的全面管理。
1.时间,时间管理主要是及时的向配置管理库中提交更新的内容,从而避免在Build的新版本的时候有遗漏,而导致本案中提到的,测试人员在回归的时候发现提交的缺陷根本没有改的状况,重新再Build一个版本,那自然是人、时、力的极大的浪费。
2.人,作为所有数据的处理和操作主体,是管理的关键,一个误操作就可能使很多人的工作成果付之流水,所以付给不同角色的人不同的权限是很关键的,曾经有一个项目经理给所有的人员只能提交,不能删除的权限,还谓之约“糖公鸡”策略。(意思是不但不拔毛,还粘毛)这不是不信任谁,而是在极大程度上保护大家的劳动成果。
3.工作内容,工作内容可以说是工作质量和工作的主体了,同时也是大家交流的主要对象。对于工作内容的管理主要注意下面几个方面。
* 注释,很多程序员再写代码的时候,不做注释,一个程序员一种风格,这就给读代码,尤其是交叉检查代码带来了困难,人的记忆能力总是有限的,老人家常说“好记性,不如烂笔头”相信时间久了,代码的易读程度就会受到影响。所以代码要求注释。
* 更新说明,在做更新的时候要写说明,我们都知道,变动的代码是极有可能跟很多其他开发人员写的代码有关联的,那么代码的变更势必需要相关联的代码也跟着变更,如果没有,那当然就会出现,提交的缺陷修改完成了,又引入了新的问题的状况。关联复杂的情况下定位问题是很不容易的。由此可见更新的说明对于沟通是多么的重要,当然它也是有帮助记忆的作用的。
* 代码状态,这个是内容管理很重要的一部分,这个状态既能标示一个开发人员的工作里程碑,也能给Build新版本提供一个依据。从而保证Build的每一个新版本是开发人员确认过了的有效的一个版本。
  第三,技术。开发工程师和测试工程师的技术水平也是决定版本质量的关键,甚至决定性的因素,开发人员不比说了,资深开发人员和刚毕业的开发人员会出现的Bug都很大区别。但经验都是积累出来的。测试人员的水平是很需要提高的,一个同行把测试分为验证和确认两种,(CMMI中也有这样两个过程域)。验证,主要来做数据结构,系统架构,逻辑结构的严谨的验证,从而保证算法、逻辑的严密和准确。确认,主要来看这个系统是否满足了客户的业务需求。我想着不无道理。这样能更深层次,或者更有依据的来保证软件的质量,我们直接就做确认了,确认正确的结果可能是一个假象,就像2+2=4,但公式如果写成2*2=4两个的结果是一样的,但是实现确实完全不一样的。不论是开发人员还是测试人员,在软件质量保证上的目标是一致的,技术要求也是一致的。
  技术指标的制定,这个笔者也不能给出什么建议,只知道没有最好,只有更好,我们需要不断的提高技术水平。技术提高,不耻下问很重要,一个技术难题很可能其他同事已经解决了,而你不知道,就还需要钻研很久。一个相同的功能,很可能多少个开发人员就有多少种实现,何不大家沟通一下,选个最好的呢?配置管理也是,如果你有更好的解决办法,也别忘了跟我们共享一下。
  说的可能有点远,但在任何时候做正确的事情,都比坚持错的效果要好。配置管理,从现在开始吧!

关注案例  
焦点4:白盒测试的困惑,究竟多少人在做?适用范围?
焦点5:在软件项目规划和开发阶段,如何考虑与测试配合?
焦点6:覆盖率如何计算?
焦点7:如何进行滚动测试?
焦点8:嵌入式软件的测试设计应该如何做?
案例分析
你在日常的工作中没有遇到问题吗?如果有,你也可以提交案例。【我要提交案例

 

测试时代首页 | 测试时代论坛 | 测试交流会 | Blog社区 | 测试时代工作室 | 测试时代刊物 | 软件测试资料