本文作者:qiaoqingyi

软件开发公司代码管理(开发软件的代码)

qiaoqingyi 04-03 110

  1 软件研发的风险本质

  软件研发过程是个集体性的活动,团队工作在一起的目标就是在规定的时间内完成原计划的特性并交付上线,而其过程中不免有多种风险因素的存在。作为一名QA,我时常在思考,软件研发过程中的风险究竟是怎样引入的,其本质因素又是什么。 我们先暂时放下这个问题,来看一下QA的角色价值。

  交付上线后的软件版本作为整个迭代完成后最重要的输出物,其实也是我们在迭代内所有工作围绕的核心所在。我们大体上都会有这样的一种共识,迭代结束后,经过QA充分测试后的上线版本是一个质量可控的交付版本。那么我们在接下去的一个迭代内还需不需要引入QA呢?答案当然是肯定的,原因在于新的迭代有新的需求,QA需要在迭代内通过QA活动,控制软件的质量风险,这其实也是QA角色最重要的核心价值之一。

  说到这里,上面提到的风险引入的本质因素貌似有了答案:是新的需求引入了风险,这貌似是教科书上的经典答案。我们可以再深入思考一下:需求会是团队迭代结束后的最终交付物吗?显然不是。所有需求最终都会转化为软件实际的功能、性能等方面的实现。而软件功能、性能的实现本质上是由一行行代码组成的,因此我们觉得软件研发过程中风险的本质因素是代码发生了变化。

  2 QA判断测试范围与重点的常见痛点

  开发作为软件代码的实际生产者,在提测的时候,往往会被QA要求告知本次提测功能变更的实际区域,因为QA需要通过开发传递的这些信息输出来判断接下来的测试范围和测试重点。开发传递这些信息的方式大体有邮件描述、口头沟通等,但这些方式往往会存在如下两个痛点:

开发告知的变更是基于其自身的主观判断,有时可能会存在遗漏和遗忘。

语言和文字在信息传递的过程中,往往会存在不同人对其理解有一定差异性的情况。

  由于上述两点痛点问题,QA在判断测试范围和测试重点时可能会存在一定程度上的非客观性,而这并不利于QA把控软件的质量风险。 如何降低这个过程中的风险,这就要求在提测的时候,能有渠道获得更加客观的实际代码变更信息来辅助QA来进行相应的风险和测试分析。

  3 代码变更风险分析平台与服务化

  在代码变更风险分析的平台化实践上,为了综合判断代码的质量风险,我们整合了多维度的分析数据和信息,其中包括实际的代码diff,新增/删除代码行数,子类数,类的扇入(有多少其它类会调用)、扇出(会调用多少其它类),极高/高/中圈复杂度(复杂度越高的方法和类越容易产生bug)等。 下面采用问题驱动的方式,分三个维度来讲讲平台的具体思考与实现。

  3.1 谁会使用该平台服务

  平台最开始的用户群定位在QA群体,希望通过有效的分析和展示手段来帮助QA同学客观的分析代码变更风险。同时也希望一定程度上能帮助到开发同学了解自己实现的代码所对应的变更风险。

  3.2 他们会怎样使用该平台服务

软件开发公司代码管理(开发软件的代码)

  在时间比较紧张的情况,使用者可能想利用非常短的时间,快速地了解整体的风险信息。对此平台采用了可视化的手段将风险信息聚合在了一张图上,从而帮助使用者快速的掌握整体风险信息。

  上面的这张图是某项目的整个工程的拓扑图。每个圆圈代表的是一个类文件;类与类之间的连线代表了他们之间关联关系(子类、扇入、扇出),越是中间区域的类表示被依赖的越多,也越是底层;圆圈的直径大小代表了文件代码行的变动量,越大表示变动越大;颜色色系的深浅代表了复杂度的大小,越深复杂度越高。

  如果一次代码变动导致某些中间区域的、深色的圆圈直径变得很大,这代表着这次的代码变更风险会比较大,这应该引起QA的高度重视,应考虑增加相应的测试力度。 在时间比较宽裕,同时对整个项目代码结构有大致了解的前提下,使用者可能想更详细的了解一下具体的变更信息。对此平台采用了表格矩阵的方式展示每个类文件的多维度信息,从而帮助使用者更细粒度的掌握风险信息。如下图:

  在时间比较宽裕,同时对整个项目代码又非常了解的前提下,使用者可能想在平台上直接能看到具体的代码diff。对此平台采用了类似gitlab等代码仓库管理平台,用页面的方式,展示具体代码diff,从而帮助使用者最细力度的掌握风险信息。如下图:

  3.3 他们会在哪些场景下触发使用该平台服务

在代码的开发过程中,使用者可能期望在开发分支上通过对比不同revision,来及时了解和掌握代码变更的综合信息。

在提测的时候,使用者可能期望将提测分支与线上分支进行对比,来了解和掌握这个版本所有代码变更的综合信息。

在回归测试中,开发修复bug后会要求QA重新基于修复版本进行测试,使用者可能期望在提测分支上通过对比修复bug前后的不同revision,来了解和掌握针对这些bug修复所做出的代码变更的综合信息。

上线后,对于hotfix,使用者可能期望在hotfix分支上通过对比hotfix前后不同revision,来了解和掌握代码变更的综合信息。

  上述四种使用场景基本覆盖了QA活动过程中最常见的一些类型,对此平台通过实现不同分支之间的对比、分支内不同revision之间的对比两种方式实现了上述四种使用场景的全覆盖。

  网易企业服务-企业信息化服务提供商

  湖南领先网络科技有限公司 www.hnling.com

阅读
分享