从测试用例角度来看传统测试人员更专业?|从资产角度思考测试用例的编写

2021-09-22   出处:吐司阿哈  作/译者:吐司阿哈  

1.互联网测试人员不专业吗?

        前段时间和一个朋友聊到测试用例的问题,他说在刚工作那会,编写用例都需要写的很详细,前置条件、操作步骤、预期结果缺一不可,每一条用例都需要有详细的操作步骤和输入数据,每一个用例都有唯一的预期结果;而互联网企业中所谓的“用例”,其实就是测试大纲,从这一点上来说,互联网测试人员的专业性还是差了一些,你说为什么会这样呢?

        我回答到,这个问题其实不是人员的专业性的问题,而是互联网和传统行业的差异造成的,比如业务、用户、运营等不同造成的。

        业务不同:传统企业主要解决企业信息化的问题,互联网主要解决需求与供给的匹配问题,面向端的业务较为简单。

        使用对象不同:传统软件使用者大多是有一定专业能力的人员,业务具有专业性,相对复杂;而互联网企业用户多样化,对端的业务要求简单。

        运维能力差异:传统企业更多是客户运营,有问题需要提交给技术服务商,流程复杂,对功能质量要求高;而互联网企业更多的是提供服务企业自运营,有问题可以随时上线修复。当时对这个回复还是挺满意的,直到上周阅读到《数据中台:让数据用起来》一书中提到:“数据是一种资产”。突然想到一个问题,测试用例是资产吗?如果是资产应该如何编写用例,如果不是资产又应该如何编写用例呢?

2.测试用例是资产吗?

        在2008年参与了某四大行的测试资产管理系统开发工作,系统包含测试用例管理、测试数据管理、测试环境管理三部分内容。当时没有太关注系统的名字,现在想来大有深意,至少在传统企业中,很多公司把测试用例当成一种测试资产。

        如果测试用例是一种资产的话那该如何编写用例呢?从资产的特性上来说,资产是有价值的,可复用,可传承(转让)。如果让测试用例这个资产有价值、可复用、可传承呢?那就需要有更多的信息描述,如前置条件,测试步骤(详尽的测试数据,每一步都是可以预期的结果),测试结果(用例都有唯一的预期结果);以及测试用例详细信息(关联需求、优先级、重要程度、需求描述、编写人、维护人、时间等属性)。

        但在互联网快速发展的时代,因为业务性质、用户、运营以及软件技术和开发流程都发生了很大的变化,需求可能是临时的,实验性质的。这个时候,面向用户端的测试用例本身来说不一定是资产,“用例”可能只是一种对需求的理解,或者一种测试思路,其目的是为了和产品经理对齐思路,或者提供一种测试思路。基于这个思路,用例编写不再有求详尽,而是能够表达清楚对产品的理解和测试思考即可。从这个角度来说不是互联网时代测试不专业,而是因为传统企业和互联网企业对用例的认识和定位不同,在互联网时代,测试用例不一定是资产,测试用例到底是不是一种资产,直接影响着用例的编写方式。

3.互联网时代的测试用例该如何编写?

        前面讨论了测试用例到底是不是资产,是基于大背景下的一个思考,但互联网时代,测试用例该如何编写,该基于什么样的逻辑编写呢?JVM存储模式给予一种思考的方式。比如把用例分成几个等级。如基础能力、核心业务、其他业务等。

        基础能力:登录、路由、通用或者技术组件等。

        核心业务:小金库、白条、交易等。

        其他业务:营销、新业务等。

        基础能力是业务最核心的能力,直接影响用户使用或者经营决策,这些业务相对稳定,按照资产的逻辑编写详尽的测试用例,一则可以确保测试时无遗漏,二则确保知识交接转移无缝衔接。

        核心业务可以业务情况选择使用资产的方式,编写详尽的用例,也可以选择按照大纲的方式编写用例。

        其他业务则只要做到对齐需求,做到不遗不漏就可以,没必要编写详尽的测试用例,从资产的角度来说,有用,但不能复用。

        以上笔者从测试用例是否是资产的角度思考测试用例,从测试以外的角度理解测试。希望给读者一个不一样的视角思考测试用例。

       


声明:本文为本站编辑转载,文章版权归原作者所有。文章内容为作者个人观点,本站只提供转载参考(依行业惯例严格标明出处和作译者),目的在于传递更多专业信息,普惠测试相关从业者,开源分享,推动行业交流和进步。 如涉及作品内容、版权和其它问题,请原作者及时与本站联系(QQ:1017718740),我们将第一时间进行处理。本站拥有对此声明的最终解释权!欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,与我们的编辑和其他窝友交流。
147°|1479 人阅读|0 条评论

登录 后发表评论