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

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

说了，这么多废话，该进入今天的论题了。这是小辛负责该产品以来，遇到的一个新问题，描述如下：

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.测试报告缺失：版本间问题单，目前已经开展了必要的曲线分析，意在查看项目周期是否稳定。如果出现大的跳跃，项目负责人将对现有情况做出评估报告。而由此问题造成缺失在于，测试报告中未对版本间的遗留问题进行分析与总结，为后期版本埋下重大隐患。