本文探讨互联网时代测试用例相关问题。对比传统企业与互联网企业，指出二者因业务、用户、运维等差异，对测试用例的认识和定位不同。分析测试用例是否为资产，以及不同情况下的编写方式，还基于JVM存储模式给出用例编写的逻辑。
1.互联网测试人员不专业吗?
前段时间和一个朋友聊到测试用例的问题，他说在刚工作那会，编写用例都需要写的很详细，前置条件、操作步骤、预期结果缺一不可，每一条用例都需要有详细的操作步骤和输入数据，每一个用例都有唯一的预期结果；而互联网企业中所谓的“用例”，其实就是测试大纲,从这一点上来说，互联网测试人员的专业性还是差了一些，你说为什么会这样呢？
我回答到，这个问题其实不是人员的专业性的问题，而是互联网和传统行业的差异造成的，比如业务、用户、运营等不同造成的。
业务不同：传统企业主要解决企业信息化的问题，互联网主要解决需求与供给的匹配问题，面向端的业务较为简单。
使用对象不同：传统软件使用者大多是有一定专业能力的人员，业务具有专业性，相对复杂；而互联网企业用户多样化，对端的业务要求简单。
运维能力差异：传统企业更多是客户运营，有问题需要提交给技术服务商，流程复杂，对功能质量要求高；而互联网企业更多的是提供服务企业自运营，有问题可以随时上线修复。
当时对这个回复还是挺满意的，直到上周阅读到《数据中台：让数据用起来》一书中提到：“数据是一种资产”。突然想到一个问题，测试用例是资产吗？如果是资产应该如何编写用例，如果不是资产又应该如何编写用例呢？
2.测试用例是资产吗？
在2008年参与了某四大行的测试资产管理系统开发工作，系统包含测试用例管理、测试数据管理、测试环境管理三部分内容。当时没有太关注系统的名字，现在想来大有深意，至少在传统企业中，很多公司把测试用例当成一种测试资产。
如果测试用例是一种资产的话那该如何编写用例呢？从资产的特性上来说，资产是有价值的，可复用，可传承（转让）。如果让测试用例这个资产有价值、可复用、可传承呢？那就需要有更多的信息描述，如前置条件，测试步骤（详尽的测试数据，每一步都是可以预期的结果），测试结果（用例都有唯一的预期结果）；以及测试用例详细信息（关联需求、优先级、重要程度、需求描述、编写人、维护人、时间等属性）。
但在互联网快速发展的时代，因为业务性质、用户、运营以及软件技术和开发流程都发生了很大的变化，需求可能是临时的，实验性质的。这个时候，面向用户端的测试用例本身来说不一定是资产，“用例”可能只是一种对需求的理解，或者一种测试思路，其目的是为了和产品经理对齐思路，或者提供一种测试思路。基于这个思路，用例编写不再有求详尽，而是能够表达清楚对产品的理解和测试思考即可。
从这个角度来说不是互联网时代测试不专业，而是因为传统企业和互联网企业对用例的认识和定位不同，在互联网时代，测试用例不一定是资产，测试用例到底是不是一种资产，直接影响着用例的编写方式。
3.互联网时代的测试用例该如何编写？
前面讨论了测试用例到底是不是资产，是基于大背景下的一个思考，但互联网时代，测试用例该如何编写，该基于什么样的逻辑编写呢？JVM存储模式给予一种思考的方式。比如把用例分成几个等级。如基础能力、核心业务、其他业务等。
基础能力：登录、路由、通用或者技术组件等。
核心业务：小金库、白条、交易等。
其他业务：营销、新业务等。
基础能力是业务最核心的能力，直接影响用户使用或者经营决策，这些业务相对稳定，按照资产的逻辑编写详尽的测试用例，一则可以确保测试时无遗漏，二则确保知识交接转移无缝衔接。
核心业务可以业务情况选择使用资产的方式，编写详尽的用例，也可以选择按照大纲的方式编写用例。
其他业务则只要做到对齐需求，做到不遗不漏就可以，没必要编写详尽的测试用例，从资产的角度来说，有用，但不能复用。
以上笔者从测试用例是否是资产的角度思考测试用例，从测试以外的角度理解测试。希望给读者一个不一样的视角思考测试用例。
文章来源：土司阿哈，致力于提供最具价值的测试及测试管理领域原创文章。包括测试技术、测试方法、测试思想、测试管理等。
· 推 荐 阅 读 ·
RECOMMENDATION
你点的每个“在看”，我都认真当成了喜欢
你点的每个“在看”，我都认真当成了喜欢
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
