浅谈测试需要立足于业务场景
本帖最后由 璐璐 于 2019-9-25 14:23 编辑从我从事测试行业以来，不断的有人对我说起测试要基于业务，设计测试用例要基于业务场景。也有人对我说，测试是需要软件技术与业务知识并行成长的。无论哪种观点，都把业务放在了一个重要的位置。今天我就谈谈我这些年的体会。
一、好的测试用例必定基于业务场景
好些测试人员，拿到一个需求，阅读几遍，再找开发聊一聊开发的设计方案，就觉得已经掌握了软件的基本功能和特性，然后就开始书写自己的测试用例。运用边界值、等价类、组合等等耳熟能详的测试方法开始测试用例的编写。这个过程其实本身就存在着最大的弊端。就是没有基于业务场景。正确的书写方式应该是先了解业务场景。具体包括哪些方面呢？
1、这个软件的最终使用者是谁？他们期望软件的功能是怎样的？
2、这个软件的设计是基于什么样的业务场景下提出的？
这里我说个具体的例子：我是从事保险行业测试工作的。针对一种保险，我们暂且叫他保险品种A，这款产品前年就已经上线了，保险大家都知道有保费的计算。原来保险品种A的保费计算公式为：保费=保额*费率，最近提出了一个需求说是保险费率要调整，调整为保险费率*短期系数。我拿到这个需求后，做了测试分析后，得出的基本的测试功能点如下：
（1）验证保费计算无误
（2）验证新推出的保费与原来的保费计算一致。（这是基于对历史数据的考虑），我沾沾自喜，觉得按照这两个基本的思路测试下去，肯定没问题。但是到了生产的第一天就出现了问题。
问题出在哪里呢？出在原来保费计算公式中的费率它指的是年费率，现在之所以进行调整是因为为了更好的协调统一各个系统的费率表达方式：用原费率/12得出所谓的短期系数，可是这个短期系数是除不尽的，具体值为0.83333333333无限循环下去，这个时候，在乘以保额，保额的值不是定值啊，导致不同的保额*费率*短期系数的值部分与原来的值相等，但是有些个别情况不再相等。当初设计测试用例的时候我就没有考虑到这一点？我应该向需求求证下：
业务为什么这样改？这样改了之后对业务有什么影响？如果我早早的问出这个问题，肯定不会出现这个问题。写出来叫我时时为戒，也希望大家不要重蹈覆辙。
二、业务场景的熟练，决定你的价值
只有对业务场景特别熟练，测试人员才能发现更加深刻的问题。比如说你在测试一个接口，你已经遍历了必录项、枚举值、非必录项、时间格式、有效数字保留这些问题后，如果你对业务场景没有概念。那么你的测试工作实在是没有什么技术含量。因为这些内容接口文档里有明确的规定，谁来测试都一样。但是换个角度想一想，我知道在某个特定场景下，这个本来是必录项的值就会变成非必录的。在或者，某个字段被定义为int类型，可是实际业务场景中我切身看到的了解到的是String类型。再比如我们的接口中有身份证号这个概念，验证位数为18位，可是实际业务中却有港澳台的居民的身份证号的介入。等等，这些基于实际业务场景的问题如果被测试人员挖掘出来，那么开发也好、需求也好、领导也好都会对你另眼相待！
三、测试场景的建立要满足两不要原则
1、不要主观臆想测试场景
测试场景基于需求说明书、基于开发的设计文档，基于测试分析，不是臆想出的场景。具体点，有些情况已经违背了需求描述，已经不再代码可控的范围内，有的场景已经和软件的实际功能产生了矛盾和冲突，那么这种场景不应该建立。
2、不要放过细小的测试场景
反过来讲，测试场景要涉及的足够细致，粒度越细越好。这个场景建立的前提条件是什么？这个场景实现的过程是什么？这个场景的实现目标是什么？这个场景的异常流程有哪些？这些都要覆盖在我们平时的测试中，体现在我们的测试思维里，表达在我们的测试用例中。
总之测试工作和业务场景是有这千丝万缕的联系的，测试要基于场景，场景映射在软件功能上，只有这样，才是真正基于场景的测试，才是有前途的测试！文章来源：海哥说测试 作者：博为峰网校金牌讲师 haibao1371
页:
[1]
