逻辑层：即业务统计逻辑层，是整个数据仓库系统的灵魂。数据仓库存在的意义是通过一系列的逻辑分析，将各海量数据转换成一种更直观更简便的方式展示给中层或高层领导，为他们提供商业分析和决策支持。其中这一系列统计逻辑决定了此报表的质量高低。在实际的测试过程中，此层的逻辑应该是由前期调研人员提供的需求规格说明书明确且保障的。对于研发环节中的测试人员，在需求文档已评审通过且封版定稿的前提下，应从测试覆盖度的角度做到与需求文档的业务描述高度符合。
测试覆盖度是评估阶段性软件测试执行状态的重要手段之一，简单讲，就是确定测试是否已经达到了预先设定的测试任务完成的标准。严格讲，测试覆盖策略有基于需求的测试覆盖与基于代码的测试覆盖，鉴于目前笔者所从事内容多为系统验收测试，故着重从基于需求的角度描述测试覆盖度的保证措施。
……………………
4、评审设计阶段：在开发发布概要设计文档和详细设计文档之后，应对设计文档进行静态测试，主要从以下三方面进行评审：
1. 设计功能点是否已完全覆盖需求所描述的业务点
2. 设计的实现方式是否有利于系统的扩展性，并评估是否有局限性
3. 评审设计文档的实现方式是否有可优化的实现方式
通过以上的静态评审，一方面可保证编码实现方式完全覆盖显性需求，另一方面可对整体的系统架构或系统延展性有所保障。
5、测试用例设计与评审：
测试用例的设计依赖于测试需求，测试用例至少等价覆盖测试需求是测试用例设计的原则，测试用例的设计方法有很多，边界值
等价类划分、流程图、因果图、判定表等一系列常用的设计方法，此处不再赘述。测试用例的评审由业务、需求调研、测试共同参与，并对测试用例设计过程中所触及到的风险及应对措施予以公布。
测试用例尽可能覆盖测试需求，通过同行评审及外部评审提高测试用例的覆盖度。
......
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
