一份思考—版本间共性问题提炼与控制

题记:很久没在写有关测试的方面的文章了,估计已经被各位达人遗忘了。小辛,即退出游戏行业后,被华为招为奴工已经勤勤肯肯的劳作了大半年时间。总结这大半年的时光,大多是在加班与出差中渡过的,听说华为最近又死人了哦,一阵寒意!盼了好久终于等来了可爱的端午节,有三天的时间休整,接着是广东联通开局。没有余震的日子,是让人欣慰的,这日子也就这点盼头了。震后的生活,真是苦不堪言,天天觉得在摇哦,办公室楼梯到昨天都没给维修的,一道道裂痕触目惊心啊!总觉得随时都的塌了的,近日,小辛的一位同事(美女)离职了。还是觉得很惋惜吧,嘿嘿,怎么说也是个美女嘛,小辛在这里说一声“谢谢”,相聚总是缘分,何况还是同事呢。

说了,这么多废话,该进入今天的论题了。这是小辛负责该产品以来,遇到的一个新问题,描述如下:
A产品在经过N个版本测试洗礼后,终于如期发布。A产品发布时共产生的B、C两个分支版本。 B、C版本均为A基线版本子版本,但流程上有一定区别,同属一个产品线,但有一些地域性需求特性。 B版本随着时间的推移又推出了D、E两个补丁版本,即Bsp1及Bsp2。由于产品结构的调整,产品结构链需要向F版本过渡,F版本将是现有产品新的基线版本,但全国局点更新速度远小于产品演进速度。则出现以下问题,由于同时需要在全国局点维护多个不同基线的发布版本。则在代码修改时需要同时对几个版本进行更改,并合并到一个主分支上,遂产生以下一些问题:
问题1:F版本的问题单,应该如何标示为共性问题,问题单是否需要重复拷贝到前一个基线版本中。
问题2:共性问题,应该由项目周期中的哪个角色来做判断
问题3:定位共性的问题的标准是什么
问题4:如何来规避这类问题,以免在遗留在某个待维护的版本中
问题5:如何通过缺陷管理与QA控制来实现对共性问题的跟踪与回访
问题6:从版本打包机制与版本号管理入手,加强基线版本的作用
待着这6个问题,我对现有的版本控制进行了一些的思考与分析,当然一些思考是不成熟的仅代表着自己的看法,此贴本着学习与探讨的态度,希望各位达人能够帮忙指证。
流程控制节点上的缺失
. 缺陷管理过程:缺陷提交版本控制混乱,即在一轮规划的测试过程中,存在多个临时版本。产品测试打包申请中缺少对测试版本号的控制,测试负责人在规划一个产品发布测试时,仅对测试周期进行初步估算规划出X轮测试的时间。在提交缺陷时,简单的按照版本名+测试轮数的方式进行缺陷控制,导致在发布周期出现B、C两个分支版本时,无法对B版本中遗留问题进行跟踪。必须通过全盘回访才能做出定位,这样造成测试工作组大量时间压力。
2.共性问题定义:缺陷提交中缺少共性问题字段标示,有关共性问题的定位这块需要QA、测试组负责人及项目共通商议。其中,共性问题判断的归属问题,应由项目组负责人共同决定。如果TD库是基于域建立(域:代表产品,目:子版本),F基线版本中的问题单,又应该已怎样的方式进行共享。
3.测试报告缺失:版本间问题单,目前已经开展了必要的曲线分析,意在查看项目周期是否稳定。如果出现大的跳跃,项目负责人将对现有情况做出评估报告。而由此问题造成缺失在于,测试报告中未对版本间的遗留问题进行分析与总结,为后期版本埋下重大隐患。
阅读更多
想对作者说点什么?

博主推荐

换一批

没有更多推荐了,返回首页