当一个产品原型出来的时，在写业务测试用例的时候，总会发现用例的关注点大部分都集中在业务逻辑的覆盖上面，对具体逻辑的实现，以及底层实现原理的注偏少。用例就是覆盖需求，感觉没有错误，而需求就是我们说的业务逻辑。
但是仔细想一下W模型就会发现，集成测试和单元测试缺少了，而直接进入系统测试，但是单元测试和集成测试的测试要点又需要在系统测试阶段中考虑到。
在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。微软推荐的分层式结构一般分为三层，从上至下分别为：表示层、业务逻辑层、数据访问层。可以利用这个分层理论，让我们也可以在系统测试阶段考虑到逻辑实现和底层原理的验证。
下面我以现有的项目分别进行举例说明。
表示层
定义
系统测试阶段的需求覆盖包括显性需求覆盖和基于需求本身补充与完善的隐性需求
平台最近需要上线一个新的产品类型为股权产品，产品特征为固定期限，浮动收益，会有超额收益；而且会有以下两种摊还模式：利随本清；先本后利；已还本金部份，后续持有阶段不再计息；超额收益，会按初始份额计算。下图为持有详情页面简单的用例：
只要对需求里面的显现和隐性的需求进行覆盖，从表示层的层面来看是覆盖完整。
业务逻辑层
定义
简单点来说就是可以把集成测试和接口测试阶段的测试对象理解为业务逻辑层
以上面持有详情页面为例，经过和开发沟通发现，如果接口返回信息披露中有值的时候信息披露需要显示，无数据则隐藏。
再举一个例子，平台中我的页面还有一个预期收益的显示，在股权类型产品特性中知道该产品的收益为浮动，那么说明用户购买股权类产品之后用户的预期收益浮动的，未加股权类产品之前，用户在我的页面查看的预期收益都是显示具体数值，所以新增股权类产品之后，我的页面预期收益字段的显示业务逻辑上面有了新的变化，此处应新增一个用例。
数据访问层
定义
数据访问层的数据应该是广义的包括数据库中的数据、具体的的文件、图片变化等等都算是的。需求有涉及数据变化时，一定要对数据本身进行确认和验证
先以股权类的超额收益举例子，超额的收益会在平台中的资金记录详情中进行展示。在之前的需求有提过：超额收益，会按初始份额计算。那我们可以先根据开发的计算公式，使用Excel对超额收益进行核对；还可以根据我们自己对数据的理解，另外写一个计算公式对超额收益再核对一次。看不同的公式算出来的数据是否一致。
下图为根据开发的计算逻辑，以摊还的本金所得的收益为基准进行计算，公式：实际收益(开发)=分配本金*收益天数*基础利率/基准天数，最终的超额公式应该为：超额收益=分配收益TA之和 - 实际收益(开发)之和，最终得到的结果为18,368.72元。
我们再根据自己的计算公式进行计算，每次摊还的剩余本金计算每一个阶段可得到的收益。公式：阶段收益(测试)= 剩余本金*收益天数*基础利率/基准天数
测试的计算公式还可以校验摊还的时候，分配收益Ta和阶段收益(测试)的值是否一致。结束日期2个收益不一致为正常现象，因为分配收益Ta为系统分配的收益包括超额收益。
最终的超额公式应该为：超额收益=结束日期的分配收益Ta - 结束日期的阶段收益(测试) 。最终得到的结果为18,368.7161元。比较之和发现差1分钱，因为四舍五入的原因，这个可以忽视。
再举一个简单的例子，我们平台开通电子账户的时候需要上传身份证的正反面照片，得到照片之后，需要从服务把照片传给第三方进行信息的校验。而传给第三方的照片不能超过1M。这样我们每次扫描或者拍照之后，我们可以在服务器中看服务器保存照片的大小是否大于1M。这样就可以保证给第三方的照片不会大于1M。
各位看官是否对前面说的分层概念有更好的理解，是否借助这个让我们对用例更深入也更有针对性。
- END -
