软件测试用例对于测试进度的可控性建议——理论篇(转载)

上一篇 / 下一篇 2013-03-26 16:36:54 / 个人分类：转载

一个项目在测试的过程中，不论是PM或者测分都希望随时可以了解测试的进度，以便随时掌控项目的时间走向。而测试的过程中测试人员所进行就是测试用例的执行，那么用例执行的程度显然可以直观的反应出项目在测试阶段的进度情况。

　　我们首先来分析一下现在的情况。

　　必须明确的是，一个项目中所涉及的产品线很可能不只一条，而各个产品线的用例设计的方法，粒度，以及格式均有差别。在这些差别中，最能够对进度起决定性作用的就是用例的粒度。由于目前的情况下，每个人设计的用例粒度都千差万别，有些同学可能设计的比较详细，而有些同学可能设计的相对粗略，在不影响执行用例以及其他人的易懂性的情况下，我们说这些都是可以的。但是随之带来对议题最直接的问题就是，QC给出的进度不客观。这个是很明显的，举个最极端的例子，A写了9个很细致的用例，B只写了1个很粗略的用例，但是执行度和A相当。当A的用例全部执行完以后，QC给出的进度应该是90%，但是很显然，实际进度才进行到50%。

　　我们需要改善这种情况。

　　第一种方法，所有的用例都设计到最细致，粒度为1的情况。

　　我们知道，如果从理论上说，每个用例都是不可分割的，也就是说我们设计出来的用例的粒度应该都是相等的。如果能够做到这一点，测试进度的可控性会好很多。然而，这个很难做到。如果每个人的用例都精确到最细致的程度，比如说使用未精简过的因果图法设计用例，那么我们用例数量将会十分庞大，这样同样不利于我们控制，而且在执行的过程中，由于用例太细致，但是操作却不少，效率上也是个问题。而且，这从目前的情况来，我们要走这条路也是不可能的。每个人对用例的理解和对功能的理解都是不一样的，不可能把粒度做到都相等。

　　此外，这种方法还存在问题。用例的粒度都为1，并不能说明每个用例的重要程度都一样。当你提交一个bug的时候，会对bug做重要性的评估，正是基于这一点，我们认为，用例的重要性也是不一样的，由于引申开去，即使用例粒度都为1，实际执行中的进度也还是不客观的，存在误差的。而我们需要的是更精确的数据，更能反应对进度的情况。

　　所以我们提出了第二种方法。

　　在介绍第二种方法的时候，我们引进了一个概念——权重。相信所有人对这个概念不会陌生，所以就不多介绍了。其次，我们对用例的设计有个要求——在用例执行的过程中不能出现预期结果或者关注点，只有在执行的最后一步，才能出现预期结果或者关注点，如果用例中间出现，则必须分成多个用例——最大在这种粒度下，我们认为可以接受。

　　基于以上两个条件，我们对用例进行权重分析，以达到进度可控。

　　第一个因素是项目类型。通过分析，我们大致确定有这三种类型的项目：升级包，新增项目，改造类型（可能以后会更加细致的划分）。可以这么说，在这三种类型的项目下，我们设计用例的思路以及粒度是不相同的，当然更多的加入了个人的因素。这是一个最大方向，而这个方向，会直接影响我们对用例权重的分析，也就是算法问题——当然在各种项目下的权重算法应该怎么计算，我们需要通过实践来给出更加科学的依据，目前只给出思路。

　　第二个因素则是用例的设计方法。用例的设计方法本身对进度没什么影响，但是由于设计方法会直接影响到用例的覆盖程度，会间接影响到进度。那么在这里我们认为这个因素可以作为一个系数加入权重的计算方法。通常情况下经过用例评审或者review应该不存在覆盖度不全的情况，但是在需求变更的情况下，可能会导致用例覆盖度下降。在用例重新改善前，我们认为进度是存在变化的。

　　第三，用例的参数设定。这是最重要的部分，用例参数的设定直接影响了该用例的重要程度。关于这一点，我们的初衷是，为用例制定一系列参数，然后由测试人员对这些参数进行值的设定，我们会为每个值设定一个权重，通过这些参数来制定出一个用例在项目中实际占用的比重，这样可以更加科学地反应测试的进度。这样不面有人会提出提问，那么这些参数的值如何去设定，有什么标准，如果设定不当，那么依然不能反应出测试的进度。但是我们要说，这是一次尝试，没有一个流程在制定的时候就能考虑到各种问题，这个建议也不例外。并且在尝试的过程中我们会给出参考的用例，本着自己对自己用例负责的原则，我们有理由相信我们会给自己设计的用例给出一个正确的、科学的参数，以计算出最正确的权重，相信没人会反对这一点。

　　那么如何来制定这些参数？我们初步定制了这些：用例关注点，用例代表的功能点的重要程度，用例执行的难度以及用例估计执行的时间，通过这些参数来设定参数的值。

　　接下来，我会用最近做的公共事业缴费做一个模型，在这个模型中，我们尝试使用这种方法对用例进行权重分析。

　　（我们对用例的分析，仅限于目前未经验证过的方法，具体的实行需要通过大家一起推敲以及更加科学的算法给出才能正是实行。这里仅仅给出一种思路，供大家参考，并未真正给出规范。）

　　首先，这个项目是一个新增项目，也就是说，他有这独立的功能，即使是收银台也是重新开发（功能雷同），所以我认为，这个项目在功能上几乎是全新的，所以我们不需要考虑到其他项目或者升级包，我认为权重的计算方法可以用最简单的，直接相加后作为总的权重，即进度μ= ，其中d是已经执行的用例权重和，D是所有用例的权重和。

　　给出一下权重规则：（权重W）

　　1、用例关注点，一个关注点W++；

　　2、用例代表的功能点，与bug相对应，分成三个等级：影响流程的功能W+=3，项目主要的功能W+=2，项目次要的功能W+=1。（如何定义功能的重要程度，需要考虑。）

3、用例执行的难度，这点主要针对在执行过程中是否需要大量的计算什么的，比如在公共事业缴费项目中需要计算校验码，是比较难的。预期定义为：难，W+=3；一般，W+=2；容易，W+=1。（本条需要郑重考虑，尤其是对难度的定义。）

　　4、用例执行的估计时间，由设计者预估，可以在执行中根据实际情况修改。我大体分成几个等级：10分钟级：W+=1.0；10分钟~1小时，W+=1.5；1小时~半日级：2.0；跨日：W+=3。（本条需要对时间进行更科学的调整。）

　　以上各条均可以影响到测试进度，如果还有重要的参数也可以加入。

　　接下来对公共事业缴费项目按以上规则进行分析，用例请参考QC。

　　在QC中可以看到，用例被分成6个文件夹（最后一个是回归使用，不在讨论范围）。由于用例通过了用例评审，我们可以认为，功能覆盖的情况是完善的，即覆盖系数可以认为是100%，并且中间没有经过需求变更，所以只需要对用例本身进行分析就可以了。（这里列举几个比较典型的）

　　前台页面缴费：

　　录入缴费单类

　　验证输入项关联关系：关注点6个，W=6。功能为影响流程，W=9。执行难度为容易，W=10。时间为10分钟级别，W=11。

　　条形码解析类