转测试思考——测试的价值体现和提升

Posted 2020-06-16

测试到底有没有价值？有什么样的价值？又体现在哪里？

我们怎么样让测试的价值发挥的更好，更充分？

我一直在思考这个问题……，下面是我的一些个人感悟，供大家阅读参考。

 

测试到底有没有价值？

最近听到了这样一个故事：

某公司有一个新项目上线，需要公司内用户进行验证。大概流程就是需要公司外部用户提交一种单据，然后由公司内用户进行审批。但是一次又一次审批都失败了，操作过的数据也无法再使用；

每一次失败，企业内的用户都得恳求外部用户帮忙，再次提交数据；而且每次提交数据都需要向银行支付一定的费用；通过不断的代码修复，最终用户提交了6次，整个流程才成功。

过程中给用户带来了很大的困扰和痛苦；出现这种情况，我想一定是没有经过测试或没有经过充分的测试才导致的。

一个好的项目，一定要通过测试，保证软件的质量符合要求之后，才能交付给用户使用；不然就是对用户的不负责任，对公司的不负责任；让第一批用户成为了小白鼠，让公司也失去了用户的信任。

所以测试是否有价值，已经在故事中有了答案。

 

测试的价值在哪里？

测试的价值，我觉得应该从两个维度去分析。

第一，是从用户的角度看。

当用户使用系统时，

发现系统主要功能存在问题！

发现系统使用起来像蜗牛一样慢！

发现系统存在安全隐患，用户数据安全得不到保障！

发现系统太不好使了，太麻烦了，看不懂！

如果是出现上面的问题，一定是功能测试、性能测试、安全性测试、用户体验测试没有做好；

如果这些问题被测试提前发现，而不是遗留给用户；用户使用起来一切OK而且感觉很爽，那我们的价值也就找到了。

总之，我认为测试的价值就是经过我们测试的东西，能够让老板放心，让用户舒心。

第二，是从项目的角度看。

从项目角度，测试的价值就是保证软件的质量；直接的数据表现就是发现的Bug；我们发现的Bug越多，开发就越放心，感觉“嗯，帮我发现了这么多问题，应该差不多了”。其实作为测试来说，我发现的问题越多，对软件的质量就越不放心；

为什么呢？因为Bug越多，证明软件存在的隐患就越多，代码质量是存在问题的。测试一直是以测试发现的bug数量论英雄，其实我觉得除了数量，发现Bug的早晚、严重程度、隐藏深度、Bug类型更能说明一个测试人员的价值。

 

如何提升测试的价值呢？

日常我们测试的项目都是时间紧急，导致需求或设计都可能存在一定的问题；或是bug或是未考虑周全，或是描述不清。开发写代码过程也会出现遗漏、错误或到了时间节点未进行联调或自测；

所有这些导致的问题都会在测试阶段集中爆发，导致测试80%时间在调试，在验证需求是否实现，验证功能是否正常。也许我们会发现几十个、几百个Bug，但是这些Bug真正发挥测试的价值了吗？我觉得，还没有！不仅没有发挥测试的价值，反而会有两大问题：

1、     导致开发有一种依赖思想；“反正后面测试”，所以在这种思想下，代码的质量就会受到影响。

2、     测试人员疲于补漏；由于表面的bug太多，根本没有时间也没有精力去发现更深层次的bug，更别提用户体验。导致系统的性能、兼容性、用户体验就会出现问题，甚至功能也可能会有问题。

所以对于如果提高测试的价值，我有以下一些经验或想法。不想一一赘述，列于下面供大家参考。

1、 从需求及设计阶段就开始测试，尽早发现需求和设计中存在的问题和漏洞。（即使没有时间或人力在需求阶段投入，也应该在后续阶段，重点对需求及设计进行深入分析，挖掘其漏洞，发现其问题。只要在交付用户之前发现，总比遗漏给用户强过百倍）

2、 深如了解用户需求，站在用户角度思考，提升用户体验。

（多与用户接触，多跟业务方聊天，你会有很多意想不到的收获。因为用户体验不是我们想出来的，而是用户真正体验、使用总结而来的）

3、 采用【白加黑】测试策略，尽量提升测试准确度。

（【白加黑】就白盒加黑盒的测试策略；尤其在回归测试中非常明显；如果纯黑盒测试，有时开发可能只改了一行代码，或者改了一个配置，我们就需要回归整个流程及其中一些重要细节；但如果我们通过阅读代码，与开发沟通，通过代码的修改评估出影响的范围，我们就能有的放矢。这样的测试我们不仅提高了工作效率，缩短测试时间，还能让我们测试的更明白，更放心。）

4、 通过冒烟测试，减少不必要的资源浪费。

（我有一个想法是，冒烟测试是否可以由开发人员来进行；冒烟的测试用例由测试和开发共同编写，评审。这样是否就可以避免我上面提到的两个问题，也保证开发提测的代码流程是通的，测试也不用在流程性的问题上耽误太多时间，而保证更多的精力去探索需求、设计及代码。是否可行，这个我还没有过经验，希望后续可以验证）

5、 自己能办到的事一般不求别人。

（在涉及多个部门或多个系统的大项目中，我认为这句话很管用。当然这句话只能用在自测的阶段，联调阶段万不可使用。在自测阶段，我们依赖的外部数据，可以通过我们自己调用自己的接口，给自己发送MQ消息，或者调用别人的接口，使用别人的系统，尽可能不依赖别人，这样我们自测的效率就会大大提高。）

6、 站在专业测试的角度，不局限于自己目前的负责范围。

（在大的公司，术业有专攻；有的人只负责功能，有的人只负责性能，有的只负责安全，等等。但是作为测试人员，我们不能仅仅局限于我们目前的工作范围，应该从整体去考虑；因为立项时，项目经理和开发人员有哪些类型测试需要做，他们可能不会特别清楚；这时，我们就应该站在专业的角度，为项目组提供更合理的建议）

7、 不存私心，一切以客户为中心。

（有些项目需要多部门合作，作为测试，我觉的不能仅仅考虑我们自己负责的范围没问题就OK；应该站在公司角度，用户角度考虑问题；少计较个人得失，多关注用户和公司的利益。看似是大道理，但是实际工作中我已深有体会；当我帮助别人发现问题，并得到解决。我的心里就会有一种莫名的自豪感和成就感。）