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