精华内容
下载资源
问答
  • 数据仓库主题设计及元数据设计

    万次阅读 2016-04-15 15:06:29
    数据仓库主题设计及元数据设计
    明确仓库的对象:主题和元数据 

      大多数商务数据都是多维的,所以采集和表示三维以上的数据不能完全借用业务数据库设计中的方法,必须有一种新的方法来表达多维数据。现阶段流行的有2种方 法,一是面向对象方法,即把商务数据抽象为对象,再使用Rational Rose等对象建模工具来表达这些对象;另一种方法就是使用信息包图,这是一种简便且高效的方法,在项目中使用的普及率很高。 

      信息包图实际上是自上而下数据建模方法的一个很好的工具。自上而下的建模技术从用户的观点开始设计。用户的观点是通过与用户交流得到的,可以进一步明确用 户的信息需求。自上而下的方法几乎考虑了所有的信息源,以及这些信息源影响商务活动的方式,它使得设计者可以围绕着一个通常的主题或商务领域进行信息包的 开发。 

      下面就详述如何通过信息打包技术建立信息包图,从而确定数据仓库中的主题和元数据。 
    3.4.1 信息打包技术 
    1.信息打包技术的基本使用 

      信息打包法是一种自顶向下的设计方法,它从管理者的角度出发把焦点集中在企业的一个或几个主题上,着重分析主题所涉及数据的多维特性。此法具体分4个阶段: 

      (1)采用自顶向下的方法对商务数据的多维特性进行分析,用信息打包图表示维度和类别之间的传递和映射关系,建立概念模型。其中类别是按一定的标准对一个维度的分类划分,如产品可按颜色、质地、产地和销地等不同标准分类。 

      (2)对企业的大量的指标实体数据进行筛选,提取出可利用的中心指标。其中指标也称为关键性能指标和关键商务测量的值,是在维度空间衡量商务信息的一种方法。比如产品收入金额、原材料消耗、补充新雇员或设备运行时间等都可以叫做指标。 

      (3)在信息打包图的基础上构造星形图,对其中的详细类别实体进行分析,进一步扩展为雪花图,建立逻辑模型。 

      (4)在星形图和雪花图的基础上,根据所定义数据标准,通过对实体、键标、非键标、数据容量、更新频率和实体特征进行定义,完成物理数据模型的设计。 

      信息包图可以帮助用户完成以下工作: 

    l 定义某一商务中涉及的共同主题范围,例如:时间、顾客、地理位置和产品。 

    l 设计可以跟踪的、确定一个商务事件怎样被运行和完成的关键商务指标。 

    l 决定数据怎样被传递给数据仓库的用户。 

    l 确定用户怎样按层次聚合数据和移动数据。 

    l 决定在给定的用户分析或查询中实际包含了多少数据。 

    l 定义怎样访问数据,它的进入点是什么。用户想访问哪里,以及怎样引导进入信息包。 

    l 估计数据仓库大小。 

    l 确定一个数据仓库里数据的更新频率。 

    l 制定信息怎样被打包才能更好地提供给用户。 

      图3-24是一个空白的信息包图。注意信息包图上面的横线,这里要写上信息包的说明。可以有选择地填上概括说明和详细说明或者说明信息包图描述的是什么信 息。而阴影部分就是代表在一定的维度和类别下的度量指标,这部分体现的就是数据分析的主要任务,在制作信息包图时需要和用户一起完成。 

      在以后对AdventureWorksDW数据仓库的分析中,主要是对Adventure Works Cycles公司的销售情况进行分析,根据前面对需求的分析,结合信息打包法的4个阶段,可以通过如下的方法建立信息包图。

      (1)获取各个商务部门对商务数据的多维特性分析结果,确定影响销售的维度,这里可以提炼出日期、区域、产品、客户年龄和客户状况等5个维度。 

      (2)对每个维度进行分析,确定它与类别之间的传递和映射关系,如在AdventureWorks业务数据库中,日期有年、季度和月甚至更小的级别,而区域一般就分为国家、地区、城市和具体的商店。 

      (3)确定用户需要的指标体系,这里以销售情况作为事实依据确定相关的销售指标,如实际销售、计划销售、预测销售、计划偏差和预测偏差等。 

      有了以上的分析,就可以画出销售分析的信息包图,如图3-25所示,其他分析需求的信息包图可以用类似的方法表示。

      (4)这一步可以在信息打包图的基础上构造星形图,如图3-26所示。然后根据实际情况,把详细类别实体连接到星形图中就可以得到企业数据仓库的雪花模 型。如在这里的AdventureWorks业务数据库中,已经通过表“ProductCategory”、“ProductSubcategory”和 “Product”对产品进行了层次分类,把它们挂到图3-26的星形图中可以形成图3-27所示的雪花架构图。


      注意,按照设计惯例,指标实体、维度实体和详细类别实体分别用矩形、菱形和六角形表示。 

      通过以上技术,实际上建立起了数据仓库的概念模型和逻辑模型。如图3-25所示的信息包图是在最终用户和技术人员共同完成的,通过它数据的构成便由客观世 界转换到了主观世界。而图3-26则属于逻辑模型,因为它在信息包图的基础上将信息转换成了关系模型。对比最终数据仓库的架构(在3.2.2节有叙述)可 知,这时离构建完整的数据仓库数据库已经很近了。 
    2.信息动态打包 

      信息打包图中涉及的维度及其对应的类别是事先固定的。这种将维度和类别固定所带来的最直接的问题是,所设计的数据仓库不仅对一些特定的查询分析操作的适应 能力差,而且当查询或分析的要求发生变化时根本无法适应。解决该问题的方法是允许维度和类别进行自由改变,这就是信息动态打包的方法。 

      信息动态打包包括2方面的内容:与该指标分析对应的维度的动态组合及与维度关联的类别的动态组合。参考南京大学李雪梅等人的《一种基于信息动态打包的数据仓库的设计方法》一文,可以得到信息动态打包方法的7步大法。 

      (1)采用自顶向下的方法,通过与企业的领导和管理人员交谈挖掘出尽可能多的主题,然后根据这些主题找出对应的指标实体,进一步对每个指标实体采用基本信息打包法分析出其中包含的最明显的维度实体。 

      图3-28和图3-29分别是对销售分析和顾客人口统计分析得到的两个星形图,其中前者包括时间、地区和产品3个维度实体,后者包括时间、地区和顾客3个维度实体。 

      (2)综合考虑所有的主题,采用指标实体矩阵对定义的信息包和维度实体进行统一和标准化处理。利用图3-30所示的统一实体矩阵来消除实体定义中的歧异和不一致,从而保证数据仓库中实体定义的一致性。矩阵中交叉点的‘X’表示相关。 

      (3)对于单个指标实体(信息包)找出所有的与该指标实体相关的但属于其他信息包的维度实体,再根据其与该信息包的相关程度进行排序,得到该指标实体的一 个所有相关维度指标的一个有序集。需要特别指出的是,由于维度定义的相对性,当某些详细类别实体中的单个类别与指标实体的查询或分析密切相关时也可以将它 作为单独的维度实体。如顾客细节实体中包括年龄组、性别、收入组、职业、教育和婚姻状况等,而其中年龄组、性别、收入组和职业与销售分析密切相关,故可以 将它们分别作为销售的不同的维度实体。这样我们就可以得到与销售分析相关的维度实体集Dim销售={时期,地区,产品,年龄组,性别,收入组,职业}。这 里我们定义前3者的相关度为1,其他维度实体的相关度为0.5。 

      (4)对于每个维度实体,进行类别划分,找出所有可行类别。然后对这些类别的划分条件根据其粒度从大到小进行排序,得到该维度实体的类别指标的一个有序集。 

      (5)创建指标实体的动态维。可以把维度实体分为2类,一类是指对该指标实体的分析必不可少的维度实体,称之为必需维;另一类则可以根据需要自由选择,称为可选维。如DIM销售集合中,时期、地区和产品是必需维,其余的则是可选维。 

      (6)创建与维度实体对应的动态类别实体。不同于维度实体,类别实体均设为可选的,类别实体可以根据具体情况自行确定。 

      (7)建立数据仓库中各个指标的概念模型(信息打包图)和逻辑模型(星形图或雪花图)。 

      信息动态打包的数据仓库设计方法采用了维度和类别动态重组技术,提供可以修改的数据存储方式,从而使所设计的数据仓库具有真正自适应的数据结构,较好地满足企业未来查询和分析的需要。 
    3.4.2 理解数据仓库中的主题 

      通过信息包图实际上确定了数据仓库的主题和大部分元数据。这一节先讲数据包图和主题的关系。 
    1.主题的概念 

      主题(Subject)是在较高层次上将企业信息系统中的数据进行综合、归类和分析利用的一个抽象概念,每一个主题基本对应一个宏观的分析领域。在逻辑意 义上,它是对应企业中某一宏观分析领域所涉及的分析对象。例如在前面信息包图使用的例子中,“销售分析”就是一个分析领域,因此这个数据仓库应用的主题就 是“销售分析”。 

      面向主题的数据组织方式,就是在较高层次上对分析对象数据的一个完整并且一致的描述,能刻画各个分析对象所涉及的企业各项数据,以及数据之间的联系。所谓 较高层次是相对面向应用的数据组织方式而言的,是指按照主题进行数据组织的方式具有更高的数据抽象级别。与传统数据库面向应用进行数据组织的特点相对应, 数据仓库中的数据是面向主题进行组织的。例如,一个生产企业的数据仓库所组织的主题可能有产品订货分析和货物发运分析等。而按应用来组织则可能为财务子系 统、销售子系统、供应子系统、人力资源子系统和生产调度子系统。 

      主题是根据分析的要求来确定的。这与按照数据处理或应用的要求来组织数据是不同的。如在生产企业中,同样是材料供应,在操作型数据库系统中,人们所关心的 是怎样更方便和更快捷地进行材料供应的业务处理;而在进行分析处理时,人们就应该关心材料的不同采购渠道和材料供应是否及时,以及材料质量状况等。 

      数据仓库面向在数据模型中已经定义好的公司的主要主题领域。典型的主题领域包括顾客、产品、订单和财务或是其他某项事务或活动。
    2.主题域的获取 

      主题域是对某个主题进行分析后确定的主题的边界。分析主题域,确定要装载到数据仓库的主题是信息打包技术的第一步。而在进行数据仓库设计时,一般是一次先 建立一个主题或企业全部主题中的一部分,因此在大多数数据仓库的设计过程中都有一个主题域的选择过程。主题域的确定必须由最终用户和数据仓库的设计人员共 同完成。 

      比如,对于Adventure Works Cycle这种类型的公司管理层需要分析的主题一般包括供应商主题、商品主题、客户主题和仓库主题。其中商品主题的内容包括记录超市商品的采购情况、商品 的销售情况和商品的存储情况;客户主题包括的内容可能有客户购买商品的情况;仓库主题包括仓库中商品的存储情况和仓库的管理情况等,如图3-31所示。

      确定主题边界实际上需要进一步理解业务关系,因此在确定整个分析主题后,还需要对这些主题进行初步的细化才便于获取每一个主题应该具有的边界。对于图3-31的4个主题及其在企业中的业务关系可以确定边界如图3-32所示。

    3.确定主题的内容 

      主题虽然在信息包图中只占据标题的位置,但是却是信息打包方法中最重要的部分,当主题定义好之后,数据仓库中的逻辑模型也就基本成形了。此时,需要在主题 的逻辑关系模式中包含所有的属性及与系统相关的行为。数据仓库中的数据存储结构也需要在逻辑模型的设计阶段完成定义,需要向里面增加所需要的信息和能充分 代表主题的属性组。以Adventure Works Cycle这类公司数据仓库为例,如表3-7所示可以分别在“商品”、“销售”和“客户”主题上增加能够进一步说明主题的属性组。 

     表3-7 主题的详细描述

    4.主题的使用 

      由于数据仓库的设计是一个螺旋发展的过程,在刚开始,没有必要在数据仓库的数据库中体现所有的主题,选择最重要的主题作为数据仓库设计的试金石是很有必要的。因此使用主题首先是找到需要分析的主题域。 

      例如在AdventureWorksDW数据仓库的概念模型设计中,在对需求进行分析后,认识到“商品”主题既是一个销售型企业最基本的业务对象,又是进 行决策分析的最主要领域,因而把“销售分析”主题域定义为要首先建立的主题。通过“商品”主题的建立,经营者就可以对整个企业的经营状况有较全面的了解。 先实施“商品”主题可以尽快地满足企业管理人员建立数据仓库的最初要求,所以先选定“商品”主题进行实施。 

      通过将主题边界的划分应用到已经得到的关系模型上还能形成原始的概念模型。这一模型是把主题域的划分和事务处理数据库中的表结合起来的模型,例如在上面的 例子中,商品主题可能涵盖的关系表有商品表、供应关系表、购买关系表和仓储关系表;仓库主题可能涵盖的关系表有仓库关系表、仓库表、仓库管理关系表和管理 员表。把这些表的键和字段联系起来,就可以形成如  图3-33所示的原始概念模型图。

    3.4.3 理解数据仓库中的元数据 
     
      信息包图同样也包含了数据仓库中的大部分元数据。元数据最普通的定义是“关于数据的数据”。正是有了元数据,才使得数据仓库的最终用户可以随心所欲地使用 数据仓库,利用数据仓库进行各种管理决策模式的探讨。元数据是数据仓库的应用灵魂,可以说没有元数据就没有数据仓库。 
    1.元数据的类型 

      通常把元数据分为技术元数据(Technical Metadata)和业务元数据(Business Metadata)。

      技术元数据是描述关于数据仓库技术细节的数据,这些元数据应用于开发、管理和维护数据仓库,它主要包含以下信息。 

    l 数据仓库结构的描述,包括仓库模式、视图、维、层次结构和导出数据的定义,以及数据集市的位置和内容; 

    l 业务系统、数据仓库和数据集市的体系结构和模式; 

    l 汇总用的算法,包括度量和维定义算法,数据粒度、主题领域、聚合、汇总和预定义的查询与报告; 

    l 由操作环境到数据仓库环境的映射,包括源数据和它们的内容、数据分割、数据提取、清理、转换规则和数据刷新规则及安全(用户授权和存取控制)。 

      业务元数据从业务角度描述了数据仓库中的数据,它提供了介于使用者和实际系统之间的语义层,使得不懂计算机技术的业务人员也能够“读懂”数据仓库中的数 据。业务元数据主要包括以下信息:使用者的业务术语所表达的数据模型、对象名和属性名;访问数据的原则和数据的来源;系统所提供的分析方法及公式和报表的 信息。 

      在信息打包过程中,需要用包图表示维度和类别还有它们之间的传递和映射关系,实际上这个操作就是在原业务系统的基础上创建了元数据。其中的维度、类别还有 层次关系是属于典型的技术型元数据,而业务系统中与之对应的术语则属于业务元数据。比如前面的例子中提炼出的日期、区域、产品、客户年龄和客户状况等维 度,实际销售、计划销售、预测销售、计划偏差和预测偏差等指标皆属于元数据。这些数据在以后的分析中起到了极为重要的作用。下面将对这些作用进行归纳。 
    2.元数据的作用 

      从元数据的类型和作用来看,元数据实际上是要解决何人在何时、何地为了什么原因及怎样使用数据仓库的问题。再具体化一点,元数据在数据仓库管理员的眼中是 数据仓库中的包含了所有内容和过程的完整知识库和文档,而在最终用户(即数据分析人员)眼中,元数据则是数据仓库的信息地图。 

      数据分析员为了能有效地使用数据仓库环境,往往需要元数据的帮助。尤其是在数据分析员进行信息分析处理时,他们首先需要去查看元数据。元数据还涉及到数据 从操作型环境到数据仓库环境中的映射。当数据从操作型环境进入数据仓库环境时,数据要经历一系列重大的转变,包含了数据的转化、过滤、汇总和结构改变等过 程。数据仓库的元数据要能够及时跟踪这些转变,当数据分析员需要就数据的变化从数据仓库环境追溯到操作型环境中时,就要利用元数据来追踪这种转变。另外, 由于数据仓库中的数据会存在很长一段时间,其间数据仓库往往可能会改变数据的结构。随着时间的流逝来跟踪数据结构的变化,是元数据另一个常见的使用功能。 

      元数据描述了数据的结构、内容、链和索引等项内容。在传统的数据库中,元数据是对数据库中各个对象的描述,数据库中的数据字典就是一种元数据。在关系数据 库中,这种描述就是对数据库、表、列、观点和其他对象的定义;但在数据仓库中,元数据定义了数据仓库中的许多对象——表、列、查询、商业规则及数据仓库内 部的数据转移。元数据是数据仓库的重要构件,是数据仓库的指示图。元数据在数据源抽取、数据仓库开发、商务分析、数据仓库服务和数据求精与重构工程等过程 都有重要的作用,在图3-34中可以看到元数据在整个数据仓库开发和应用过程中的巨大影响。因此,设计一个描述能力强并且内容完善的元数据,对数据仓库进 行有效地开发和管理具有决定性意义。

      元数据拥有的巨大作用的发挥会在后面对数据仓库的分析中逐步体会到。这一节实际上通过信息打包技术建立起了数据仓库的概念模型,通过信息包图得到的星形结 构或雪花形结构实际上为数据仓库建立起了逻辑模型。可以说,通过对主题和元数据的分析,应该能够对从现实世界到主观世界的过程(即概念模型的构建)有深刻 的认识,而对逻辑模型还需要从事实和维度的角度进一步研究。
    展开全文
  • 测试数据设计方案

    千次阅读 2019-03-06 14:29:54
    1.测试数据设计方法一 构造测试数据时,需要看数据的开源,数据的来源一般来讲有3个,一个是根据被系统需求的分析,针对正常业务,异常情况,边界情况等来构建完整的数据,又称为造数据,这不仅仅包括最近本的基础...

    一、测试覆盖率
    测试方法及技巧的应用
    真正业务场景的满足
    测试数据的设计覆盖
    1.测试数据设计方法一
    构造测试数据时,需要看数据的开源,数据的来源一般来讲有3个,一个是根据被测系统需求的分析,针对正常业务,异常情况,边界情况等来构建完整的数据,又称为造数据,这不仅仅包括最近本的基础数据,比如,用户、权限、配置、原数据等、还包括上面提到的业务数据,
    对于比较小型的系统可行性比较高、对于大型系统来说可能较为负杂。
    2.测试数据设计方法二
    第二种方法就是利用现有系统,这是和已有类似系统,测试是针对升级或者增加功能化的系统。这种情况把已经在生产环境中运行的数据导出,在此基础上再作数据的整理、加工为测试数据。
    3.测试数据设计方法三
    还有一种方法就是将现有非电子化的业务数据导入到系统中,在验证业务的同时也完成了测试数据的积累,即边测试边积累数据、但是这种情况积累的数据往往具有一定的局限性,因为已经发生的业务数据基本上是正确的、一致的、而且可能缺少某些特定业务的数据。这样就需要根据测试需求的分析,追加新的测试数据,以便能完整覆盖业务类型。
    二、测试数据应用
    1.非空数据是否有校验。
    2.该有默认值的数据是否有默认值。
    3.引用其他功能生成的数据是否会实时刷新。
    4.页面关闭或系统重启后,数据的初始化设置等。
    5.数据的长度、类型控制是否合理,比如身份证号、实际业务中会有字母,且会出现在最后一位。
    对应方法:等价类,边界值,场景法
    优选角度:用户
    三、测试数据设计及维护
    测试数据设计及维护四、测试数据总结
    测试数据总结

    展开全文
  • 数据权限设计研究-行数据权限

    万次阅读 2019-01-17 19:22:56
    数据权限设计研究-行数据权限关于权限设计功能权限数据权限前提数据分类几种场景设计方案与思路映射表提供过滤sql的方法测试实际应用查询新增修改删除修改数据的私有,公开,部门属性私有改为部门私有改为公开部门改...

    关于权限设计

    一般来说,权限模块对于每一个系统而言都是最基础的模块,根据项目需求和功能的不同,设计方案也有许多。但从大的方面来说,可以将权限分为两大类型:功能权限数据权限

    功能权限

    主要控制不同的资源主体(用户、角色、组织等)有操作不同的资源的权限。比如常见的不同的角色能访问不同的页面(菜单权限),以及具有操作同一页面的不同功能(按钮权限)等等。对于java开发而言,功能权限的开发相对来说要简单很多,有很多现成的框架可以实现。我推荐用shiro,因为简单易用,而且能实现按钮级别的控制。

    数据权限

    主要控制不同的资源主体(用户、角色、组织等)有查看不同的数据信息的权限。数据权限又分为数据行权限和数据列权限,本篇文章主要研究一下数据行权限的控制。

    前提

    数据权限一般和业务的关系非常紧密,可能不同的业务有不同的设计方案,所以很难有一种统一而使用简单的设计方案。我的想法是:基于角色-部门的控制方式。即拥有某个角色的人,能看见当前角色所包含的部门中的数据。为了更好的设计数据权限,我总结了一下几种数据。

    数据分类

    1. 公开数据:字面意思,就是公开的数据,不需要控制数据权限。
    2. 部门数据:属于某个部门的数据,只有部门的人员可以查看。
    3. 私有数据:用户自己的数据,只能自己查看。

    几种场景

    1. 某条数据属于多个部门的情况。
    2. 某领导可以跨部门查看数据。
    3. 可以查看子部门的数据。
    4. 私有数据可以分享给别人,部门,或者公开。

    设计方案与思路

    百度上一堆关于数据权限的设计方案,基本上都是基于用户-角色-部门这个来设计,我的思路也和这个差不多,用户与数据角色挂钩,数据角色与部门挂钩,这就比直接角色与部门挂钩要相对灵活一些。虽然某个用户只能属于一个部门,但是有可能出现上面提到的第2中场景,跨部门的情况。
    在这里插入图片描述
    我的设计思路是提供一个方法,写业务的人员需要将查询的表名传给这个方法,然后我返回一段sql,这段sql只是在原来的表上进行数据权限过滤,返回的数据字段和原表一模一样,然后业务代码编写者再把这个sql作为参数传递到DAO层,拼接到FROM后面或者JOIN后面即可。这样无论是单表查询还是多表查询,都可以实现数据权限控制。
    还有一种思路是就是用mybatis拦截器去拦截sql,然后对sql进行改造拼接,但是这样我需要去拦截每一条select的sql,可能会对性能有影响。
    为了少改原有的业务表,同时统一对系统中的表进行数据权限控制,我设计了一张映射表,来映射数据表,部门,用户之间的关系。

    映射表

    映射表字段如下

    字段名类型描述备注
    ID字符串主键
    T_ID字符串数据表中的主键
    TABLE_NAME字符串数据表表名
    D_ID字符串部门ID主键
    U_ID字符串用户ID主键

    主键字段为字符串纯属个人习惯。
    有了这张映射表,我们就能根据映射表中的部门ID和用户ID是否为空来进行数据权限的识别,同时也能修改数据的所属权限(公开,部门,私有)。

    数据类型部门ID用户ID备注
    公开数据
    部门数据非空非空
    私有数据非空

    因为有私有数据分享给其他人或者部门,单条数据属于多个部门的情况,所以数据表与映射表应该是一对多的关系。

    提供过滤sql的方法

    代码如下

    /**
     * 数据权限sql拼接
     * 
     * @author chunhui.tan
     * @创建时间 2019年1月9日 下午4:30:09
     *
     */
    @Component
    public class DataSqlFilter {
    
    	@Autowired
    	private TsysUserRoleService tsysUserRoleService;
    
    	@Autowired
    	private TsysRoleDeptService tsysRoleDeptService;
    
    	@Autowired
    	private TsysDeptService tsysDeptService;
    
    	/**
    	 * 部门与数据表映射表的表名
    	 */
    	public final String MAPPING_TABLE = "DATA_MAPPING";
    
    	/**
    	 * 
    	 * @param tableName 表名
    	 * @param pkNmae    主键名
    	 * @param isPrivate 是否只获取私有
    	 * @param subDept   是否拥有子部门数据权限
    	 * @return
    	 */
    	public String getDataSql(String tableName, String pkNmae, Boolean isPrivate, Boolean subDept) {
    		// 校验参数
    		checkParam(tableName, pkNmae, isPrivate, subDept);
    		// 判断当前表是否开启数据权限
    		if (!isNeedPermissions(tableName)) {
    			return null;
    		}
    		// 获取当前用户
    		TsysUserEntity user = ShiroUtils.getUserEntity();
    		// 获取部门数据所需要的sql
    		String deptSql = getFilterSql(user, subDept);
    		StringBuilder dataSql = new StringBuilder();
    		dataSql.append("( SELECT DISTINCT S.* FROM ").append(tableName).append(" S LEFT JOIN ").append(MAPPING_TABLE)
    				.append(" T ON S.").append(pkNmae).append(" = T.T_ID AND T.TABLE_NAME= ").append("'").append(tableName)
    				.append("'");
    
    		if (isPrivate) {
    			// 只获取私有数据
    			dataSql.append(" WHERE (T.U_ID = ").append("'").append(user.getEmId()).append("'")
    					.append(" AND (T.D_ID='' OR T.D_ID IS NULL))");
    		} else {
    			// 正常数据:私有数据+部门数据+公开数据
    			dataSql.append(" WHERE T.D_ID IN ").append(deptSql).append(" OR (T.U_ID = ").append("'")
    					.append(user.getEmId()).append("'").append(" AND (T.D_ID='' OR T.D_ID IS NULL))")
    					.append(" OR ((T.D_ID='' OR T.D_ID IS NULL) AND (T.U_ID='' OR T.U_ID IS NULL))");
    		}
    		dataSql.append(")");
    		return dataSql.toString();
    
    	}
    
    	/**
    	 * 判断当前表是否开启数据权限
    	 * 
    	 * @param tableName
    	 * @return
    	 */
    	private Boolean isNeedPermissions(String tableName) {
    		// TODO 这里可以通过表名查询配置或者表来判断改表是否开启了数据权限
    		return true;
    	}
    
    	/**
    	 * 获取部门数据情况下的过滤条件SQL
    	 * 
    	 * @param user
    	 * @param subDept
    	 */
    	private String getFilterSql(TsysUserEntity user, Boolean subDept) {
    		// 部门ID列表
    		Set<String> deptIdList = new HashSet<>();
    		// 用户角色对应的部门ID列表
    		List<String> roleIdList = tsysUserRoleService.queryRoleIdList(user.getEmId());
    		if (roleIdList.size() > 0) {
    			List<String> userDeptIdList = tsysRoleDeptService
    					.queryDeptIdList(roleIdList.toArray(new String[roleIdList.size()]));
    			deptIdList.addAll(userDeptIdList);
    		}
    		// 用户子部门ID列表
    		if (subDept) {
    			List<String> subDeptIdList = tsysDeptService.getSubDeptIdList(user.getEmDeptId());
    			deptIdList.addAll(subDeptIdList);
    		}
    		List<String> result = deptIdList.stream().map(i -> {
    			return "'" + i + "'";
    		}).collect(Collectors.toList());
    		StringBuilder sqlFilter = new StringBuilder();
    		sqlFilter.append("(").append(StringUtils.join(result, ",")).append(")");
    		return sqlFilter.toString();
    	}
    
    	/**
    	 * 参数校验
    	 * 
    	 * @param tableName
    	 * @param pkNmae
    	 * @param isPrivate
    	 * @param subDept
    	 */
    	private void checkParam(String tableName, String pkNmae, Boolean isPrivate, Boolean subDept) {
    	//TODO 进行sql注入的校验
    		if (StringUtils.isBlank(tableName) || StringUtils.isBlank(pkNmae) || null == isPrivate || null == subDept) {
    			throw new XcrmsException("数据权限-缺少参数");
    		}
    	}
    }
    
    

    测试

    当前系统使用shiro做的权限,角色分成两种类型,一种是功能角色,一种是数据角色。功能角色与菜单按钮挂钩,数据角色与部门挂钩。接下来用PostMan接口测试方式来测试获取到的sql。

    只获取私有数据

    @Autowired(required = true)
    private DataSqlFilter dataSqlFilter;
    
    	/**
    	 * test
    	 * 
    	 * @param id
    	 * @return
    	 */
    	@GetMapping("/getDataSql")
    	public Result getDataSql() {
    		String dataSql = dataSqlFilter.getDataSql("PRODUCT", "P_ID", Boolean.TRUE, Boolean.FALSE);
    		System.out.println(dataSql);
    		return ResultUtil.success(dataSql);
    	}
    

    结果用Navicat处理一下:
    在这里插入图片描述
    获取普通数据
    所谓普通数据就是用户正常能看见的数据:私有数据+部门数据+公开数据。
    将参数isPrivate设置为false即可

    @Autowired(required = true)
    	private DataSqlFilter dataSqlFilter;
    
    	/**
    	 * test
    	 * 
    	 * @param id
    	 * @return
    	 */
    	@GetMapping("/getDataSql")
    	public Result getDataSql() {
    		String dataSql = dataSqlFilter.getDataSql("PRODUCT", "P_ID", Boolean.FALSE, Boolean.FALSE);
    		System.out.println(dataSql);
    		return ResultUtil.success(dataSql);
    	}
    
    

    结果用Navicat处理一下:
    在这里插入图片描述

    实际应用

    查询

    业务开发人员在查询是只需要调用这个方法获取到sql后,然后作为参数传入DAO层,在mybatis的xml文件中拼接即可(图片中的${dataSql}应为#{dataSql}),如下:
    在这里插入图片描述

    新增

    新增业务数据时,业务需要知道这个数据时那种数据类型,然后新增数据后,需要新增一条映射记录。提供过滤sql的类中可以提供统一的新增映射数据的方法。还没写,大概如下:

    	/**
    	 * 新增映射数据
    	 * 
    	 * @param pk_value  数据表数据主键值
    	 * @param tableName 数据表表名
    	 * @param type      数据类型 0 私有 1 公开 2 部门
    	 */
    	public void addMapping(String pk_value, String tableName, Integer type) {
    		// TODO 可以通过shiro获取到当前登录的用户,然后获取到用户的部门,然后根据type来新增映射关系
    
    	}
    
    

    修改

    若只是修改数据,则不关映射表的事。

    删除

    删除时需要注意,因为某条数据可能属于多个部门或者多个个人,那么当删除掉这条数据后,那么映射表中就存在多条T_ID相同和TABLE_NAME相同的数据,删除的时候应该通过T_ID和TABLE_NAME来删除映射表中的所有数据。

    修改数据的私有,公开,部门属性

    即修改映射表,按道理说,一般只会存在数据的所有人能修改,但是以防万一,业务开发人员需要判断当前数据的U_ID是否与当前用户的用户ID一致,不一致不能修改。当然,公开数据时不需要进行这一步校验的。以下修改方法都可以在DataSqlFilter类中统一提供

    私有改为部门

    即用户将私有数据分享给指定的部门
    修改方式:修改映射表中的D_ID为用户指定的部门ID

    私有改为公开

    即用户将私有数据全部公开
    修改方式:置空映射表中的U_ID和D_ID

    部门改为公开

    即将部门所拥有的数据公开
    修改方式:置空映射表中的U_ID和D_ID

    其他变更

    其他变更只要对照上面那张数据类型表即可进行修改。

    总结

    有人可能会说为什么不在原来的业务表上面加上部门ID和用户ID,从而不用映射表?
    但是这样会有一些问题,一是实际开发过程中,往往由于需求的变化,很难确定哪些表需要加部门ID和用户ID。二是这样无法满足一些特殊需求,比如:个人数据分享出去给其他人或者部门,单条数据属于多个部门。
    总结下来用以上方案来控制数据权限的优缺点如下
    优点:
    1.统一提供过滤sql,维护映射表,修改数据类型的方法,而且不用修改业务数据表,对原来的代码入侵最小化。
    2.不论是单表查询还是多表都能支持。
    3.比较灵活,针对不同需求,可以灵活调整过滤sql

    缺点:
    1.因为在对原表进行过滤时需要连接映射表,假如是多表联查,每张表都要连接映射表,可能对查询性能有影响。
    2.因为每条业务数据都会对应一条映射数据,那么意味着映射表将会有很多数据,在过滤的时候会影响性能,当然这里可以用分模块设计多个映射表的方法来解决。

    以上只是一个设计思路,还没用于实际项目,如有不足,欢迎斧正,谢谢。

    展开全文
  • 测试用例设计方法

    万次阅读 2018-03-12 17:50:01
    (一)等价类划分法定义:等价类划分法是把所有可能输入的数据,即程序的输入域划分策划国内若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例。方法是一种重要的、常用的黑盒测试用例设计...

    本篇由本人整理黑盒、白盒、接口测试一系列用例设计方法。

    黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法、场景图法等。

    (一)等价类划分法

    定义:等价类划分法是把所有可能输入的数据,即程序的输入域划分策划国内若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例。方法是一种重要的、常用的黑盒测试用例设计方法。

    等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中的错误都是等效的,并合理地假定:测试某等价类的代表值就等于对这一类其他值的测试,因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件就可以用少量代表性的测试数据取得较好的测试结果。等价类划分有两种不同的情况:有效等价类和无效等价类。

    有效等价类,是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明所规定的功能和性能。

    无效等价类 指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。对于具体的问题,无效等价类至少应有一个,也可能多个。

     

    划分标准:

    1) 完备测试、避免冗余

    2) 划分等价类重要的是:集合的划分、划分为互不相交的一组子集,而子集的并是整个集合

    3) 并是整个集合:备性

    4) 子集互不相交:保证一种形式的无冗余性

    5) 同一类中标识(选择)一个测试用例,同一等价类中,往往处理相同,相同处理映射到“相同的执行路径”。

     

    划分方法:

    1)  在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类。如:输入值是学生成绩,范围是0~100;

    测试用例设计方法---等价类划分法

    2)在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类:

    3)在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类。布尔量是一个二值枚举类型, 一个布尔量具有两种状态: true 和 false 。

    4)在规定了输入数据的一组值(假定n个),并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类。

      例:输入条件说明学历可为:专科、本科、硕士、博士四种之一,则分别取这四种的四个值作为四个有效等价类,另外把四种学历之外的任何学历作为无效等价类。

    5)在规定了输入数据必须遵守的规则情况下,可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则);

    6)在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应在将该等价类进一步的划分为更小的等价类。

     

    转化为测试用例:

    在确立了等价类后,可建立等价类表,列出所有划分出的等价类输入条件:有效等价类、无效等价类,然后从划分出的等价类中按以下三个原则设计测试用例:

    1)为每一个等价类规定一个唯一的编号;

    2)设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步,直到所有的有效等价类都被覆盖为止;

    3)设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步,直到所有的无效等价类都被覆盖为止。

     

    实例1:三角形问题

    某程序规定:“输入三个整数a、b、c分别作为三边的边长构成三角形。通过程序判定所构成的三角形的类型,当此三角形为一般三角形、等腰三角形、等边三角形时,分别做计算。。。”用等价类划分方法为该程序进行测试用例设计。

    分析题目中给出和隐含的对输入条件的要求:

    1)整数  (2)三个数(3)非零数(4)正数

    5)两边之和大于第三边(6)等腰  (7)等边

    如果a、b、c满足条件(1)~(4),则输出下列四种情况之一:

    1)如果不满足条件(5),则程序输出为“非三角形”

    2)如果三条边相等即满足条件(7),则程序输出为“等边三角形”

    3)如果只有两条边相等,及满足条件(6),则程序输出为“等腰三角形”

    4)如果三条边都不相等,则程序输出为“一般三角形”

    列出等价类表并编号

    覆盖有效等价类的测试用例:

    a b c覆盖等价类号码

    3 4 5 (1)  (7)

    4 4 5  (1)(7)  (8)

    4 5 5 (1)  (7)  (9)

    5 4 5 (1)  (7)  (10)

    4 4 4 (1)  (7)  (11)

    覆盖无效等价类的测试用例:

    覆盖有效等价类的测试用例:

    a b c覆盖等价类号码

    3 4 5 (1)  (7)

    4 4 5  (1)(7)  (8)

    4 5 5 (1)  (7)  (9)

    5 4 5 (1)  (7)  (10)

    4 4 4 (1)  (7)  (11)

    覆盖无效等价类的测试用例:

    实例2,NextDate

    NextDate函数包含三个变量:month、day、year,函数的输出为输入日期后一天的日期。

    例如,输入2006年3月7日,则函数的输出为2006年3月8日。要求输入变量month、day、year均为整数值,并且满足下列条件:

    1、1<=month<=12

    2、1<=day<=31

    3、1812<=year<=2012

    1)有效等价类为:

    M1={月份:1<=月份<=12}

    D1={日期:1<=日期<=31}

    Y1={年份:1812<=年<=2012}

    2)若条件1~3中任何一个条件失效,则NextDate函数都会产生一个输出,指明相应的变量超出取值范围,比如“month的值不在12范围中”。显然还存在这大量的year、month、day的无效组合,NextDate函数将这些组合作为统一的输出:“无效输入日期”。

    其无效等价类为:

    M2={月份:月份<1}

    M3={月份:月份>12}

    D2={日期:日期<1}

    D3={日期:日期>31}

    Y2={年份:年<1812}

    Y3={年份:年>2012}

    弱一般等价类测试用例

    月份

    日期

    预期输出

    6

    15

    1912

    1912年6月16日

     

    强一般等价类测试用例同弱一般等价类测试用例

    注:弱有单缺陷假设;健壮考虑了无效值。

    (一)弱健壮等价类测试

    用例

    ID

    月份

    日期

    预期输出

    WR1

     

    6

    15

    1912

    1912年6月16日

    WR2

     

    0

    1

    1912

    月份不在1~12中

    WR3

     

    15

    1

    1912

    月份不在1~12中

    WR4

     

    1

    0

    1912

    日期不在1~31中

    WR5

     

    1

    32

    1912

    日期不在1~31中

    WR6

     

    1

    1

    1811

    年不在1812~2012中

    WR7

     

    1

    1

    2013

    年不在1812~2012中

    (二)强健壮等价类测试

    用例

    ID

    月份

    日期

    预期输出

    SR1

     

    15

    1

    1912

    月份不在1~12中

    SR2

     

    1

    32

    1912

    日期不在1~31中

    SR3

     

    1

    1

    1811

    年份不在1812~2012中

    SR4

     

    0

    0

    1912

    两个无效一个有效

    SR5

     

    0

    1

    1811

    两个无效一个有效

    SR6

     

    1

    0

    1811

    两个无效一个有效

    SR7

     

    0

    0

    1811

    三个无效

     

    (二)边界值分析法

    定义:边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充,这种情况下,其测试用例来自等价类的边界。

    与等价类区别:

    1)边界值分析不是从某等价类中随便挑一个作为代表,而是使这个等价类的每个边界都要作为测试条件。

    2)边界值分析不仅考虑输入条件,还要考虑输出空间产生的测试情况。

    分析方法:

    大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例,可以查出更多的错误。使用边界值分析方法设计测试用例,首先应确定边界情况。通常输入和输出等价类的边界,就是应着重测试的边界情况。应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据。

    常见边界值:

     1)对16Bit的整数而言,32767和32768是边界

     2)屏幕上光标在最左上、最右下位置

     3)报表的第一行和最后一行

     4)数组元素的第一个和最后一个

     5)循环的第0次、第1次和倒数第2次、最后一次

     

    边界值分析:

    1)边界值分析使用与等价类划分法相同的划分,只是边界值分析假定错误更多地存在于划分的边界上,因此在等价类的边界上以及两侧的情况设计测试用例。

           例:测试计算平方根的函数

           输入:实数

           输出:实数

    规格说明:当输入一个0或比0大的数的时候,返回其正平方根;当输入一个小于0的数时,显示错误信息“平方根非法,输入值小于0”并返回0;库函数printLine可以用来输出错误信息。

           2)等价类划分:

              i.              可以考虑做出如下划分:

    A、输入(i)<0 和(ii)>=0

    B、输出(a)>=0和(b)Error

            ii.              测试用例有两个

    A、输入4,输出2.对应(ii)和(a)。

    B、输入10,输出0和错误提示。对应与(i)和(b)

           3)边界值分析

           划分(ii)的边界为0和最大正实数;划分(i)的边界为最小负实数和0.由此得到一下测试用例:

           A、输入{最小负实数}

           B、输入{绝对值很小的负数}

           C、输入0

           D、输入{绝对值很小的正数}

           E、输入{最大正实数}

           4)通常情况下,软件测试所包含的边界检验有几种类型:数字、字符、位置、重量、大小、速度、方位、尺寸、空间等。

           5)相应地,以上类型的边界值应该在:最大/最小、首位/末位、上/下、最快/最慢、最高/最低、最短/最长、空/满等情况下。

           6)利用边界值作为测试数据

    边界值

    测试用例的设计思路

    字符

    起始1个字符/结束+1个字符

    假设一个文本输入区域允许输入1个到255个字符,输入1个和255个字符作为有效等价类;输入0个和256个字符作为无效等价类,这几个数值都属于边界条件值

    数值

    最小值1/最大值+1

    假设某软件的数据输入域要求输入5位的数据值,可以使用10000作为最小值、9999作为最大值;然后使用刚好小于5位和大于5位的数值作为边界条件。

    空间

    小于空余空间一点/大于满空间一点

    例如在用U盘存储数据时,使用比剩余磁盘空间大一点(几KB)的文件作为边界条件

           7)内部边界值分析

           在多数情况下,边界值条件是基于应用程序的功能设计而需要考虑的因素,可以从软件的规格说明或常识中得到,也是最终用户可以很容易发现问题的。然而,在测试用例设计过程中,某些边界值条件是不需要呈现给用户的,或者说用户是很难注意到的,但同时确实属于检验范畴内的边界条件,称为内部边界值条件或子边界值条件。

           内部边界值条件主要有下面几种:

    1)数值的边界值检验:计算机是基于二进制进行工作的,因此,软件的任何数值运算都有一定的范围限制。

    范围或值

    位(Bit)

    0或者1

    字节(byte)

    0~255

    字(Word)

    0~65535(单字)或0~4294967295(双字)

    千(K)

    1024

    兆(M)

    1048576

    吉(G)

    1073741824

     

    2)字符的边界值检验:在计算机软件中,字符也是很重要的表示元素,其中ASCII和Unicode是常见的编码方式。下表中列出了一些常用字符对应的ASCII码值。

    字符

    ASCII码值

    字符

    ASCII码值

    空(Null)

    0

    A

    65

    空格(Space)

    32

    a

    97

    斜杠(/)

    47

    z

    122

    0

    48

    Z

    90

    冒号(:)

    58

    单引号(’)

    96

    @

    64

     

     

     

    3)其它边界值检验:在不同的行业应用领域,依据硬件和软件的标准不同而具有各自特定的边界值。如下列出部分手机相关的边界值:

    硬件设备

    范围或值

    手机锂电池电压

    工作电压:3.6~4.2V;

    保护电压:2.5~3V不等

    手机正常使用温度

    -25°C~+60°C

     

    转化为测试用例:

    1)    如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据。

    Ø  例如,如果程序的规格说明中规定:"重量在10公斤至50公斤范围内的邮件,其邮费计算公式为……"。作为测试用例,我们应取10及50,还应取10.01,49.99,9.99及50.01等。

    2)    如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据。

    Ø  例如,一个输入文件应包括1~255个记录,则测试用例可取1和255,还应取0及256等。

    3)    将规则1)和2)应用于输出条件,即设计测试用例使输出值达到边界值及其左右的值。

    Ø  例如,某程序的规格说明要求计算出"每月保险金扣除额为0至1165.25元",其测试用例可取0.00及1165.24、还可取一0.01及1165.26等。

    Ø  再如一程序属于情报检索系统,要求每次"最少显示1条、最多显示4条情报摘要",这时我们应考虑的测试用例包括1和4,还应包括0和5等。

    4)    如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例。

    5)    如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例。

    6)    分析规格说明,找出其它可能的边界条件。

     

    实例1,批阅试卷

    现有一个学生标准化考试批阅试卷,产生成绩报告的程序。其规格说明如下:程序的输入文件由一些有80个字符的记录组成,如右图所示,所有记录分为3组:

     

     

    1) 标题:这一组只有一个记录,其内容为输出成绩报告的名字。

    2) 试卷各题标准答案记录:每个记录均在第80个字符处标以数字"2"。该组的第一个记录的第1至第3个字符为题目编号(取值为1一999)。第10至第59个字符给出第1至第50题的答案(每个合法字符表示一个答案)。该组的第2,第3……个记录相应为第51至第100,第101至第150,…题的答案。

    3) 每个学生的答卷描述:该组中每个记录的第80个字符均为数字"3"。每个学生的答卷在若干个记录中给出。如甲的首记录第1至第9字符给出学生姓名及学号,第10至第59字符列出的是甲所做的第1至第50题的答案。若试题数超过50,则第2,第3……纪录分别给出他的第51至第100,第101至第150……题的解答。然后是学生乙的答卷记录。

    4) 学生人数不超过200,试题数不超过999。

    5) 程序的输出有4个报告:
        a)按学号排列的成绩单,列出每个学生的成绩、名次。
        b)按学生成绩排序的成绩单。
        c)平均分数及标准偏差的报告。
        d)试题分析报告。按试题号排序,列出各题学生答对的百分比。

    解答:分别考虑输入条件和输出条件,以及边界条件。给出下表所示的输入条件及相应的测试用例。

     
              输出条件及相应的测试用例表。

     

    实例2,三角形的边界问题分析测试用例

    在三角形问题描述中,除了要求边长是整数外,没有给出其它的限制条件。在此,我们将三角形每边边长的取范围值设值为[1, 100]。
     

    测试用例

    a

    b

    c

    预期输出

    Test1

    Test2

    Test3

    Test4

    Test5

    60

    60

    60

    50

    50

    60

    60

    60

    50

    50

    1

    2

    60

    99

    100

    等腰三角形

    等腰三角形

    等边三角形

    等腰三角形

    非三角形

    Test6

    Test7

    Test8

    Test9

    60

    60

    50

    50

    1

    2

    99

    100

    60

    60

    50

    50

    等腰三角形

    等腰三角形

    等腰三角形

    非三角形

    Test10

    Test11

    Test12

    Test13

    1

    2

    99

    100

    60

    60

    50

    50

    60

    60

    50

    50

    等腰三角形

    等腰三角形

    等腰三角形

    非三角形

     

    实例3,NextDate函数边界值分析测试用例

    在NextDate函数中,隐含规定了变量mouth和变量day的取值范围为1≤mouth≤12和1≤day≤31,并设定变量year的取值范围为1912≤year≤2050。

     

    (三)错误推测法

    定义:基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法。

    基本思想:列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。

    1.     例如,输入数据和输出数据为0的情况;输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。

     

    2.     例如,前面例子中成绩报告的程序,采用错误推测法还可补充设计一些测试用例:

    1)     程序是否把空格作为回答

    2)     在回答记录中混有标准答案记录

    3)     除了标题记录外,还有一些的记录最后一个字符即不是2也不是3

    4)     有两个学生的学号相同

    5)     试题数是负数

     

    3.     例如,测试一个对线性表(比如数组)进行排序的程序,可推测列出以下几项需要特别测试的情况:

    1)    输入的线性表为空表;

    2)    表中只含有一个元素;

    3)    输入表中所有元素已排好序;

    4)    输入表已按逆序排好;

    5)    输入表中部分或全部元素相同。

     

    4.     例如,测试手机终端的通话功能,可以设计各种通话失败的情况来补充测试用例:

    1)    无SIM 卡插入时进行呼出(非紧急呼叫)

    2)    插入已欠费SIM卡进行呼出

    3)    射频器件损坏或无信号区域插入有效SIM卡呼出

    4)    网络正常,插入有效SIM卡,呼出无效号码(如1、888、333333、不输入任何号码等)

    5)    网络正常,插入有效SIM卡,使用“快速拨号”功能呼出设置无效号码的数字

     

    (四)因果图法

    定义:因果图法是一种利用图解法分析输入的各种组合情况,从而设计测试用例的方法,它适合于检查程序输入条件的各种组合情况。

    应用:

    等价类划分法和边界值分析方法都是着重考虑输入条件,但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了,但多个输入条件组合起来可能出错的情况却被忽视了。

    如果在测试时必须考虑输入条件的各种组合,则可能的组合数目将是天文数字,因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计,这就需要利用因果图(逻辑模型)。

    1.     因果图介绍

    1)    4种符号分别表示了规格说明中向4种因果关系。

    2)    因果图中使用了简单的逻辑符号,以直线联接左右结点。左结点表示输入状态(或称原因),右结点表示输出状态(或称结果)。

    3)    C1表示原因,通常置于图的左部;e1表示结果,通常在图的右部。C1和e1均可取值0或1,0表示某状态不出现,1表示某状态出现。

    2.     因果图涉及的概念

    1)    关系

    Ø 恒等:若c1是1,则e1也是1;否则e1为0。

    Ø 非:若c1是1,则e1是0;否则e1是1。

    Ø 或:若c1或c2或c3是1,则e1是1;否则e1为0。“或”可有任意个输入。

    Ø 与:若c1和c2都是1,则e1为1;否则e1为0。“与”也可有任意个输入。

    2)    约束

    输入状态相互之间还可能存在某些依赖关系,称为约束。例如,某些输入条件本身不可能同时出现。输出状态之间也往往存在约束。在因果图中,用特定的符号标明这些约束。

    Ø 输入条件的约束有以下4类:

    ·        E约束(异):a和b中至多有一个可能为1,即a和b不能同时为1。

    ·        I约束(或):a、b和c中至少有一个必须是1,即 a、b 和c不能同时为0。

    ·        O约束(唯一);a和b必须有一个,且仅有1个为1。

    ·        R约束(要求):a是1时,b必须是1,即不可能a是1时b是0。

    Ø 输出条件约束类型

                   输出条件的约束只有M约束(强制):若结果a是1,则结果b强制为0。

    3.     采用因果图法设计测试用例的步骤:

    1)    分析软件规格说明描述中,那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件),并给每个原因和结果赋予一个标识符。

    2)    分析软件规格说明描述中的语义,找出原因与结果之间,原因与原因之间对应的关系,根据这些关系,画出因果图。

    3)    由于语法或环境限制,有些原因与原因之间,原因与结果之间的组合情况不可能出现,为表明这些特殊情况,在因果图上用一些记号表明约束或限制条件。

    4)    把因果图转换为判定表。

    5)    把判定表的每一列拿出来作为依据,设计测试用例。

     

    实例1,字符

    某软件规格说明书包含这样的要求:第一列字符必须是A或B,第二列字符必须是一个数字,在此情况下进行文件的修改,但如果第一列字符不正确,则给出信息L;如果第二列字符不是数字,则给出信息M。

    解答:

    1)    根据题意,原因和结果如下:

                 原因:

                 1——第一列字符是A;

                 2——第一列字符是B;

                 3——第二列字符是一数字。

                 结果:

                 21——修改文件;

                 22 ——给出信息L;

                 23——给出信息M。

    2)    其对应的因果图如下:

    11为中间节点;考虑到原因1和原因2不可能同时为1,因此在因果图上施加E约束。

    3)    根据因果图建立判定表。

     

                               表中8种情况的左面两列情况中,原因①和原因②同时为1,这是不可能出现的,故应排除这两种情况。表的最下一栏给出了6种情况的测试用例,这是我们所需要的数据。

     

    实例2,自动售货机

    有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计。其规格说明如下:若投入5角钱或1元钱的硬币,押下〖橙汁〗或〖啤酒〗的按钮,则相应的饮料就送出来。若售货机没有零钱找,则一个显示〖零钱找完〗的红灯亮,这时在投入1元硬币并押下按钮后,饮料不送出来而且1元硬币也退出来;若有零钱找,则显示〖零钱找完〗的红灯灭,在送出饮料的同时退还5角硬币。

    1)    分析这一段说明,列出原因和结果

    原因:

    1——售货机有零钱找

    2——投入1元硬币

    3——投入5角硬币

    4——押下橙汁按钮

    5——.押下啤酒按钮

    结果:

    21——售货机〖零钱找完〗灯亮   

    22——退还1元硬币

    23——退还5角硬币             

    24——送出橙汁饮料

    25——送出啤酒饮料

    2)    画出因果图,如图所示。所有原因结点列在左边,所有结果结点列在右边。建立中间结点,表示处理的中间状态。中间结点:

    11—— 投入1元硬币且押下饮料按钮

                    12——押下〖橙汁〗或〖啤酒〗的按钮

                    13——应当找5角零钱并且售货机有零钱找

                    14——钱已付清

    3)    转换成判定表:

     

    4)    在判定表中,阴影部分表示因违反约束条件的不可能出现的情况,删去。第16列与第32列因什么动作也没做,也删去。最后可根据剩下的16列作为确定测试用例的依据。

     

    (五)判定表驱动法

    定义:判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。

    优点:能够将复杂的问题按照各种可能的情况全部列举出来,简明并避免遗漏。因此,利用判定表能够设计出完整的测试用例集合。在一些数据处理问题当中,某些操作的实施依赖于多个逻辑条件的组合,即:针对不同逻辑条件的组合值,分别执行不同的操作。判定表适合于处理这类问题。

    阅读指南,判定表:

     

    1

    2

    3

    4

    5

    6

    7

    8

    问题

    觉得疲倦吗?

    Y

    Y

    Y

    Y

     

     

     

     

    感兴趣吗?

    Y

    Y

     

     

    Y

    Y

     

     

    糊涂吗?

    Y

     

    Y

     

    Y

     

    Y

     

    建议

    重读

     

     

     

     

    Y

     

     

     

    继续

     

     

     

     

     

    Y

     

     

    跳下一章

     

     

     

     

     

     

    Y

    Y

    休息

    Y

    Y

    Y

    Y

     

     

     

     

     

    判定表由四部分组成,如下图:

     1)        条件桩(Condition Stub):列出了问题的所有条件。通常认为列出的条件的次序无关紧要。

    2)        动作桩(Action Stub):列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。

    3)        条件项(Condition Entry):列出针对它左列条件的取值。在所有可能情况下的真假值。

    4)        动作项(Action Entry):列出在条件项的各种取值情况下应该采取的动作。

    规则及规则合并:

    1)  规则:任何一个条件组合的特定取值及其相应要执行的操作称为规则。在判定表中贯穿条件项和动作项的一列就是一条规则。显然判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列。

    2)  化简:就是规则合并有两条或多条规则具有相同的动作,并且其条件项之间存在着极为相似的关系。

    合并举例:

    1)        如下图左端,两规则动作项一样,条件项类似,在1、2条件项分别去Y、N时,无论条件3取何值,都执行同一操作。即要执行的动作与条件3无关。于是可合并。“-”表示与取值无关

     

    2)        与上类似,下图中,无关条件项“-”可包含其他条件项取值,具有相同动作的规则可合并。

     

    3)        

    3)        化简后的读书指南判定表

     

    1

    2

    3

    4

    问题

    觉得疲倦吗?

    -

    -

    Y

    N

    感兴趣吗?

    Y

    Y

    N

    N

    糊涂吗?

    Y

    N

    -

    -

    建议

    重读

    X

     

     

     

    继续

     

    X

     

     

    跳下一章

     

     

     

    X

    休息

     

     

    X

     

    判定表建立步骤:

    1)  确定规则的个数。假如有n个条件,每个条件有两个取值(0,1),故2n种规则。

    2)  列出所有的条件桩和动作桩

    3)  填入条件项

    4)  填入动作项,等到初始判定表

    5)  简化,合并相似规则(相同动作)

     

    实例1,机器维修

    问题要求:“。。。。。。对功率大于50马力的机器,维修记录不全或已运行10以上的机器,应给予优先的维修处理。。。。。。”,这里假定,“维修记录不全”和“优先维修处理”均已在别处有更严格的定义。请建立判定表。

    解答:

    1、确定规则的个数:这里有3个条件,每个条件有两个取值,故应有2*2*2=8种规则。

    2、列出所有的条件桩和动作桩:

    条件

    功率大于50马力吗?

    维修记录不全吗?

    运行超过10年吗?

    动作

    进行优先处理

    3、填入条件项。可从最后1行条件项开始,逐行向上填满。

    4、填入动作桩和动作项。这样便得到如下图的初始判定表

     

     

     

     

     

     

     

     

     

     

    条件

     

    1

    2

    3

    4

    5

    6

    7

    8

    功率大于50马力吗?

    Y

    Y

    Y

    Y

    N

    N

    N

    N

    维修记录不全吗?

    Y

    Y

    N

    N

    Y

    Y

    N

    N

    运行超过10年吗?

    Y

    N

    Y

    N

    Y

    N

    Y

    N

    工作

    进行优先处理

    X

    X

    X

     

    X

     

    X

     

    作其它处理

     

     

     

    X

     

    X

     

    X

    5、

    初始判定表化简。合并相似规则后得到

     

     

     

     

     

     

     

    条件

     

    1

    2

    3

    4

    5

    功率大于50马力吗?

    Y

    Y

    Y

    N

    N

    维修记录不全吗?

    Y

    N

    N

    -

    -

    运行超过10年吗?

    -

    Y

    N

    Y

    N

    工作

    进行优先处理

    X

    X

     

    X

    X

    作其它处理

     

     

    X

     

    X

     

    实例2,NextData函数的精简决策表

    M1={月份, 每月有30天}

    M2={月份, 每月有31天}

    M3={月份, 2月}                 有29=512条规则

    D1={日期,1~28}                 12月末31日和其它31

    D2={日期,29}                    日月份的31日处理不同

    D3={日期,30}                    平年2月28日处理不同

    D4={日期,31}                    于2月27日

    Y1 ={年:年是闰年}

    Y2 ={年:年不是闰年}

    改进为:

    M1={月份: 每月有30天}

    M2={月份: 每月有31天, 12月除外}

    M4={月份:12月}

    M3={月份: 2月}

    D1={日期:1<=日期<=27}

    D2={日期:28}

    D3={日期:29}

    D4={日期:30}

    D5={日期:31}

    Y1 ={年:年是闰年}

    Y2 ={年:年不是闰年}

    输入变量间存在大量逻辑关系的NextData决策表

     

     

    3.     用决策表测试法测试以下程序:该程序有三个输入变量month、day、year(month、day和year均为整数值,并且满足:1≤month≤12和1≤day≤31),分别作为输入日期的月份、日、年份,通过程序可以输出该输入日期在日历上隔一天的日期。

    例如,输入为2004年11月29日,则该程序的输出为2000年12月1日。

    1)    分析各种输入情况,列出为输入变量month、day、year划分的有效等价类。

    2)    分析程序规格说明,结合以上等价类划分的情况给出问题规定的可能采取的操作(即列出所有的动作桩)。

    3)    根据(1)和(2),画出简化后的决策表。

    案例分析如下:

    Ø  month变量的有效等价类:

    M1: {month=4,6,9,11}              M2: {month=1,3,5,7,8,10}

    M3: {month=12                       }M4: {month=2}

    Ø  day变量的有效等价类:

    D1:{1≤day≤26}                        D2: {day=27}                D3: {day=28}               D4: {day=29}                             D5: {day=30}                D6: {day=31}

    Ø  year变量的有效等价类:

    Y1: {year是闰年}                       Y2:  {year不是闰年}

    4)    考虑各种有效的输入情况,程序中可能采取的操作有以下六种:

    a1: day+2                                 a2: day=2                     a3: day=1

    a4: month+1                            a5: month=1                a6: year+1 

    4.     判定表在功能测试中的应用

    1)    一些软件的功能需求可用判定表表达得非常清楚,在检验程序的功能时判定表也就成为一个不错的工具。如果一个软件的规格说明指出:

    Ø  当条件1和条件2满足,并且条件3和条件4不满足,或者当条件1、3和条件4满足时,要执行操作1。

    Ø  在任一个条件都不满足时,要执行操作2。

    Ø  在条件1不满足,而条件4被满足时,要执行操作3。 根据规格说明得到如下判定表:

    这里,判定表只给出了16种规则中的8种。事实上,除这8条以外的一些规则是指当不能满足指定的条件,执行3种操作时,要执行1个默许的操作。在没必要时,判定表通常可略去这些规则。但如果用判定表来设计测试用例,就必须列出这些默许规则(如下表)。

    规则5

    规则6

    规则7

    规则8

    条件1

    -

    N

    Y

    Y

    条件2

    -

    Y

    Y

    N

    条件3

    Y

    N

    N

    N

    条件4

    N

    N

    Y

    -

    默许操作

    x

    x

    x

    x

    默许的规则 

    2)    判定表的优点和缺点

    Ø  优点:它能把复杂的问题按各种可能的情况一一列举出来,简明而易于理解,也可避免遗漏。

    Ø  缺点:不能表达重复执行的动作,例如循环结构。

    3)    B. Beizer 指出了适合使用判定表设计测试用例的条件:

    Ø  规格说明以判定表形式给出,或很容易转换成判定表。

    Ø  条件的排列顺序不会也不影响执行哪些操作。

    Ø  规则的排列顺序不会也不影响执行哪些操作。

    Ø  每当某一规则的条件已经满足,并确定要执行的操作后,不必检验别的规则。

    Ø  如果某一规则得到满足要执行多个操作,这些操作的执行顺序无关紧要。

    B. Beizer提出这5个必要条件的目的是为了使操作的执行完全依赖于条件的组合。其实对于某些不满足这几条的判定表,同样可以借以设计测试用例,只不过尚需增加其它的测试用例罢了。

     

     (六)正交试验法

    定义:从大量的(实验)数据(测试例)中挑选适量的,有代表性的点(例),从而合理地安排实验(测试)的一种科学实验设计方法.类似的方法有:聚类分析方法,因子方法方法等.

     

    利用正交实验设计测试用例的步骤:

    1.     提取功能说明,构造因子--状态表

    把影响实验指标的条件称为因子.而影响实验因子的条件叫因子的状态.利用正交实验设计方法来设计测试用例时,首先要根据被测试软件的规格说明书找出影响其功能实现的操作对象和外部因素,把他们当作因子,而把各个因子的取值当作状态.对软件需求规格说明中的功能要求进行划分,把整体的概要性的功能要求进行层层分解与展开,分解成具体的有相对独立性的基本的功能要求.这样就可以把被测试软件中所有的因子都确定下来,并为确定个因子的权值提供参考的依据.确定因子与状态是设计测试用例的关键.因此要求尽可能全面的正确的确定取值,以确保测试用例的设计作到完整与有效。

    2.     加权筛选,生成因素分析表

    对因子与状态的选择可按其重要程度分别加权.可根据各个因子及状态的作用大小,出现频率的大小以及测试的需要,确定权值的大小。

    3.     利用正交表构造测试数据集

    正交表的推导依据Galois理论(这里省略,需要时可查数理统计方面的教材)。

    利用正交实验设计方法设计测试用例,比使用等价类划分,边界值分析,因果图等方法有以下优点:节省测试工作工时;可控制生成的测试用例数量;测试用例具有一定的覆盖率。

     

    (七)功能图法

    定义:功能图由状态迁移图和布尔函数组成.状态迁移图用状态和迁移来描述.一个状态指出数据输入的位置(或时间),而迁移则指明状态的改变.同时要依靠判定表或因果图表示的逻辑功能.例,一个简化的自动出纳机ATM的功能图。

    应用:

    1.    功能图介绍

    一个程序的功能说明通常由动态说明和静态说明组成.动态说明描述了输入数据的次序或转移的次序.

    静态说明描述了输入条件与输出条件之间的对应关系.对于较复杂的程序,由于存在大量的组合情况,因此,仅用静态说明组成的规格说明对于测试来说往往是不够的.必须用动态说明来补充功能说明.功能图方法是用功能图FD形式化地表示程序的功能说明,并机械地生成功能图的测试用例.

    功能图模型由状态迁移图和逻辑功能模型构成.状态迁移图用于表示输入数据序列以及相应的输出数据.在状态迁移图中,由输入数据和当前状态决定输出数据和后续状态.逻辑功能模型用于表示在状态中输入条件和输出条件之间的对应关系.逻辑功能模型只适合于描述静态说明,输出数据仅由输入数据决定.测试用例则是由测试中经过的一系列状态和在每个状态中必须依靠输入/输出数据满足的一对条件组成.功能图方法其实是是一种黑盒白盒混合用例设计方法。

    (功能图方法中,要用到逻辑覆盖和路径测试的概念和方法,其属白盒测试方法中 的内容.逻辑覆盖是以程序内部的逻辑结构为基础的测试用例设计方法.该方法要求测试人员对程序的逻辑结构有清楚的了解.由于覆盖测试的目标不同,逻辑覆盖可分为:语句覆盖,判定覆盖,判定-条件覆盖,条件组合覆盖及路径覆盖.下面我们指的逻辑覆盖和路径是功能或系统水平上的,以区别与白盒测试中的程序内部的.)

    2.    测试用例生成方法

    从功能图生成测试用例,得到的测试用例数是可接受的. 问题的关键的是如何从状态迁移图中选取测试用例. 若用节点代替状态,用弧线代替迁移,则状态迁移图就可转化成一个程序的控制流程图形式.问题就转化为程序的路径测试问题(如白盒测试)问题了.

    3.    测试用例生成规则

    为了把状态迁移(测试路径)的测试用例与逻辑模型(局部测试用例)的测试用例组合起来,从功能图生成实用的测试用例,须定义下面的规则.在一个结构化的状态迁移(SST)中,定义三种形式的循环:顺序,选择和重复.但分辨一个状态迁移中的所有循环是有困难的.(其表示图形省略)。

    4.    从功能图生成测试用例的过程

    1)    生成局部测试用例:在每个状态中,从因果图生成局部测试用例.局部测试用例由原因值(输入数据)组合与对应的结果值(输出数据或状态)构成。

    2)    测试路径生成:利用上面的规则(三种)生成从初始状态到最后状态的测试路径。

    3)    测试用例合成:合成测试路径与功能图中每个状态中的局部测试用例.结果是初始状态到最后状态的一个状态序列,以及每个状态中输入数据与对应输出数据的组合。

    5.    测试用例的合成算法:采用条件构造树.

     

    (八)场景图法

    定义:现在的软件几乎都是用事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中,可以比较生动地描绘出事件触发时的情景,有利于测试设计者设计测试用例,同时使测试用例更容易理解和执行。

    应用:

    基本流和备选流:如下图所示,图中经过用例的每条路径都用基本流和备选流来表示,直黑线表示基本流,是经过用例的最简单的路径。备选流用不同的色彩表示,一个备选流可能从基本流开始,在某个特定条件下执行,然后重新加入基本流中(如备选流1和3);也可能起源于另一个备选流(如备选流2),或者终止用例而不再重新加入到某个流(如备选流2和4)。

     

    9.3.             实例

     

    1.     例子描述

    下图所示是ATM例子的流程示意图。

     

     

     

    2.    场景设计:下表所示是生成的场景。

    表3-8 场景设计

    场景1——成功提款

    基本流

    场景2——ATM内没有现金

    基本流

    备选流2

    场景3——ATM内现金不足

    基本流

    备选流3

    场景4——PIN有误(还有输入机会)

    基本流

    备选流4

    场景5——PIN有误(不再有输入机会)

    基本流

    备选流4

    场景6——账户不存在/账户类型有误

    基本流

    备选流5

    场景7——账户余额不足

    基本流

    备选流6

    注:为方便起见,备选流3和6(场景3和7)内的循环以及循环组合未纳入上表。

    3.    用例设计

    对于这7个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式,其中各行代表各个测试用例,而各列则代表测试用例的信息。本示例中,对于每个测试用例,存在一个测试用例ID、条件(或说明)、测试用例中涉及的所有数据元素(作为输入或已经存在于数据库中)以及预期结果。

    表3-9 测试用例表

       

    TCID

    场景/条件

    PIN

    账号

    输入(或选择)的金额

    账面

    金额

    ATM内的金额

    预期结果

    CW1

    场景1:成功提款

    V

    V

    V

    V

    V

    成功提款

    CW2

    场景2:ATM内没有现金

    V

    V

    V

    V

    I

    提款选项不可用,用例结束

    CW3

    场景3:ATM内现金不足

    V

    V

    V

    V

    I

    警告消息,返回基本流步骤6,输入金额

    CW4

    场景4:PIN有误(还有不止一次输入机会)

    I

    V

    n/a

    V

    V

    警告消息,返回基本流步骤 4,输入 PIN

    CW5

    场景4:PIN有误(还有一次输入机会)

    I

    V

    n/a

    V

    V

    警告消息,返回基本流步骤 4,输入 PIN

    CW6

    场景4:PIN有误(不再有输入机会)

    I

    V

    n/a

    V

    V

    警告消息,卡予保留,用例结束

     

    4.    数据设计

    一旦确定了所有的测试用例,则应对这些用例进行复审和验证以确保其准确且适度,并取消多余或等效的测试用例。

    测试用例一经认可,就可以确定实际数据值(在测试用例实施矩阵中)并且设定测试数据,如表3-10所示。

    表3-10   测试用例表

    TCID

    场景/条件

    PIN

    账号

    输入(或选择)的金额(元)

    账面
    金额(元)

    ATM内的金额(元)

    预期结果

    CW1

    场景1:成功提款

    4987

    809-498

    50.00

    500.00

    2 000

    成功提款。账户余额被更新为450.00

    CW2

    场景2:ATM内没有现金

    4987

    809-498

    100.00

    500.00

    0.00

    提款选项不可用,用例结束

    CW3

    场景3:ATM内现金不足

    4987

    809-498

    100.00

    500.00

    70.00

    警告消息,返回基本流步骤6,输入金额

    CW4

    场景4:PIN有误(还有不止一次输入机会)

    4978

    809-498

    n/a

    500.00

    2 000

    警告消息,返回基本流步骤4,输入PIN

    CW5

    场景4:PIN有误(还有一次输入机会)

    4978

    809-498

    n/a

    500.00

    2 000

    警告消息,返回基本流步骤4,输入PIN

    CW6

    场景4:PIN有误(不再有输入机会)

    4978

    809-498

    n/a

    500.00

    2 000

    警告消息,卡予保留,用例结束

     

     

    测试用例设计综合策略

    1.    Myers提出了使用各种测试方法的综合策略:

    1)    在任何情况下都必须使用边界值分析方法,经验表明用这种方法设计出测试用例发现程序错误的能力最强。

    2)    必要时用等价类划分方法补充一些测试用例。

    3)    用错误推测法再追加一些测试用例。

    4)    对照程序逻辑,检查已设计出的测试用例的逻辑覆盖程度,如果没有达到要求的覆盖标准,应当再补充足够的测试用例。

    5)    如果程序的功能说明中含有输入条件的组合情况,则一开始就可选用因果图法。

    2.    测试用例的设计步骤

    1)    构造根据设计规格得出的基本功能测试用例;

    2)    边界值测试用例;

    3)    状态转换测试用例;

    4)    错误猜测测试用例;

    5)    异常测试用例;

    6)    性能测试用例;

    7)    压力测试用例。

    3.    优化测试用例的方法

    1)    利用设计测试用例的8种方法不断的对测试用例进行分解与合并;

    2)    采用遗传算法理论进化测试用例;

    3)    在测试时利用发散思维构造测试用例;

     
    白盒测试常见的用例设计方法有:代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径覆盖测试法、域测试、符号测试。
    (一)代码检查法
            代码检查包括桌面检查、代码审查和走查等,主要检查代码和设计的一致性,代码对标准的遵循、可读性,代码逻辑表达的正确性,代码结构的合理性等方面;发现违背程序编写标准的问题,程序中不安全、不明确和模糊的部分,找出程序中不可移植部分、违背程序编程风格的内容,包括变量检查、命名和类型审查、程序逻辑审查、程序语法检查和程序结构检查等内容。

    代码检查方法:

    1、代码检查法

    (1)桌面检查:这是一种传统的检查方法,由程序员检查自己编写的程序。程序员在程序通过编译之后,对源程序代码进行分析、检验,并补充相关文档,目的是发现程序中的错误。由于程序员熟悉自己的程序及其程序设计风格,桌面检查由程序员自己进行可以节省很多的检查时间,但应避免主观片面性

    (2)代码审查

        由若干程序员和测试员组成一个审查小组,通过阅读、讨论和争议,对程序进行静态分析的过程。代码审查分两步:第一步,小组负责人提前把设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给小组成员,作为审查的依据。小组成员在充分阅读这些材料后,进入审查的第二步,召开程序审查会。在会上,首先由程序员逐句简介程序的逻辑。在此过程中,程序员或其他小组成员可以提出问题,展开讨论,审查错误是否存在。实践表明,程序员在讲解过程中能发现许多原来自己没有发现的错误,而讨论和争议则促进了问题的暴露。

       在会前,应当给审查小组每个成员准备一份常见错误的清单,把以往所有可能发生的常见错误罗列出来,供与会者对照检查,以提高审查的失效。这个常见的错误清单也成为检查表,它把程序中可能发生的各种错误进行分类,对每一类错误列出尽可能多的典型错误,然后把它们制成表格,供再审查时使用

      (3)走查

       与代码审查基本相同,分为两步,第一步也是把材料分给走查小组的每个成员,让他们认真研究程序,然后再开会。开会的程序与代码审查不同,不是简单地读程序和对照错误检查表进行检查,而是让与会者“充当”计算机,即首先由测试组成员为所测试程序准备一批有代表性的测试用例,提交给走查小组。走查小组开会,集体扮演计算机角色,让测试用例沿程序的逻辑运行一遍,随时记录程序的踪迹,供分析和讨论用。

    人们借助测试用例的媒介作用,对程序的逻辑和功能提出各种疑问,结合问题开展热烈的讨论和争议,能够发现更多的问题。

    代码检查应在编译和动态测试之前进行,在检查前,应准备好需求描述文档、程序设计文档、程序的源代码请当、代码编译标准和代码缺陷检查表等。在实际使用中,代码检查能快速找到缺陷,发现30%~70%的逻辑设计和编码缺陷,而且代码检查看到的问题本身而非征兆。但是代码检查非常耗费时间,而且代码检查需要知识和经验的积累。代码检查可以使用测试软件进行自动化测试,以利于提高测试效率,降低劳动强度,或者使用人工进行测试,以充分发挥人力的逻辑思维能力

    2、代码检查项目

         变量交叉引用表;标号的交叉引用表;检查子程序、宏、函数;等价性检查;常量检查;标准检查;风格检查;比较控制流;选择、激活路径;补充文档

        根据检查项目可以编制代码规则、规范和检查表等作为测试用例,如编码规范、代码检查规范、缺陷检查表等

    3、编码规范

        编码规范是指程序编写过程中必须遵循的规则,一般会详细制定代码的语法规则、语法格式等

    4、代码检查规范

        在代码检查中,需要依据被测软件的特点,选用适当的标准与规则规范。在使用测试软件进行自动化代码检查时,测试工具一般会内置许多的编码规则。在自动化测试基础上使用桌面检查、代码走查、代码审查等人工检查的方法仔细检查程序的结构、逻辑等方面的缺陷

    5、缺陷检查表

        在进行人工代码检查时,代码缺陷检查表是我们用到的测试用例。

        代码缺陷检查表中一般包括容易出错的地方和在以往的工作中遇到的典型错误

     

    (二)静态结构分析法

           程序的结构形式是白盒测试的主要依据。研究表明程序员38%的时间花费在理解软件系统上,因为代码以文本格式被写入多重文件中,这是很难阅读理解的,需要其它一些东西来帮助人们阅读理解,如各种图表等,而静态结构分析满足了这样的需求。

           在静态结构分析中,测试者通过使用测试工具分析程序源代码的系统结构、数据结构、内部控制逻辑等内部结构,生成函数调用关系图、模块控制流图、内部文件调用关系图、子程序表、宏和函数参数表等各类图形图标,可以清晰地标识整个软件系统的组成结构,使其便于阅读和理解,然后可以通过分析这些图标,检查软件有没有存在缺陷或错误。

         其中函数调用关系图通过应用程序中各函数之间的调用关系展示了系统的结构。通过查看函数调用关系图,可以检查函数之间的调用关系是否符合要求,是否存在递归调用,函数的调用曾是是否过深,有没有存在独立的没有被调用的函数。从而可以发现系统是否存在结构缺陷,发现哪些函数是重要的,哪些是次要的,需要使用什么级别的覆盖要求......

        模块控制流图是与程序流程图相类似的由许多节点和连接节点的边组成的一种图形,其中一个节点代表一条语句或数条语句,边代表节点间控制流向,它显示了一个函数的内部逻辑结构。模块控制流图可以直观地反映出一个函数的内部逻辑结构,通过检查这些模块控制流图,能够很快发现软件的错误与缺陷

    (三)静态质量度量法

    根据ISO/IEC 9126质量模型作为基础,我们可以构造质量度量模型,用于评估软件的各个方面。该模型从上到下分为3层:质量因素(Factors)、分类标准(Criteria)和度量规则(metrics)。其中质量因素对应ISO 9126质量模型的质量特性,分类标准对应ISO 9126质量模型的子特性,度量规则用于规范软件的各种行为属性。以下例子按照可维护性进行分析。

    1、度量规则

        度量规则使用了代码行数、注释频度等参数度量软件的各种行为属性

    2、分类标准

       软件的可维护性采用以下四个分类标准来评估:可分析性(ANALYZABILITY)、可修改性(CHANGEABILITY)、稳定性(STABILITY)、可测性(TESTABILITY)。每个分类标准由一系列度量规则组成,各个规则分配一个权重,由规则的取值与权重值计算出每个分类标准的取值。

        function_TESTABILITY_DRCT_CALLS+LEVL+PATH+PARA

    3、质量因素

        质量因素的取值与分类标准的计算方式类似:依据各分类标准取值组合权重方法计算.

        function_MAINTAINABILITY=function_ANALYZABILITY

                                                    +function_CHANGEABILITY

                                                    +function_ATABILITY

                                                   +function_TESTABILITY 

     

    (四)逻辑覆盖法

    逻辑覆盖是以程序内部的逻辑结构为基础的设计测试用例的技术。

    根据覆盖目标的不同和覆盖源程序语句的详尽程度,逻辑覆盖又可分为:

     

    1. 语句覆盖(SC)

    2. 判定覆盖(DC)

    3. 条件覆盖(CC)

    4. 条件/判定覆盖(CC)

    5. 条件组合覆盖(MCC)

    6. 修正判定条件覆盖(MCDC)

    7. 点覆盖

    8. 边覆盖

    9. 路径覆盖

     

    几种逻辑覆盖标准发现错误的能力呈由弱至强的变化。

     

    下面我们来逐一举例详解:

     

    1语句覆盖(SC):

    语句覆盖是指选择足够的测试用例,使得运行这些测试用例时,被测程序的每一个语句至少执行一次,其覆盖标准无法发现判定中逻辑运算的错误.

     

    我们看下面的被测试代码:

    int foo(int a, int b)

    {

    return a / b;

    }

    假如我们的测试人员编写如下测试案例:

    TeseCase: a = 10, b = 5

     

    测试人员的测试结果会告诉你,他的代码覆盖率达到了100%,并且所有测试案例都通过了。然而遗憾的是,我们的语句覆盖率达到了所谓的100%,但是却没有发现最简单的 Bug,比如,当我让b=0时,会抛出一个除零异常。

     

    简言之,语句覆盖,就是设计若干个测试用例,运行被测程序,使得每一可执行语句至少执行一次。这里的“若干个”,意味着使用测试用例越少越好。

     

    语句覆盖率的公式可以表示如下:

    语句覆盖率=可执行的语句总数/被评价到的语句数量 x 100%

    2判定覆盖(DC)

    判定覆盖是设计足够多的测试用例,使得程序中的每一个判断至少获得一次“真”和一次“假”,即使得程序流程图中的每一个真假分支至少被执行一次。

    但若程序中的判定是有几个条件联合构成时,它未必能发现每个条件的错误。

     

    例:

    int a,b;

    if(a || b)

    执行语句1

    else

    执行语句2

     

    要达到这段程序的判断覆盖,我们采用测试用例:

    1)a = true , b = false;

    2)a = false, b = false

    3条件覆盖(CC)

    条件覆盖是指选择足够的测试用例,使得运行这些测试用例时,判定中每个条件的所有可能结果至少出现一次,但未必能覆盖全部分支.

    例:

    int a,b;

    if(a || b)

    执行语句1

    else

    执行语句2

     

    要达到这段程序的条件覆盖,我们采用测试用例:

    1)a = true , b = false ;

    2)a = false, b = true

    4判定/条件覆盖(CDC)

    判定/条件覆盖是使判定中每个条件的所有可能结果至少出现一次,并且每个判定本身的所有可能结果也至少出现一次。

    例:

    int a,b;

    if(a || b)

    执行语句1

    else

    执行语句2

     

    要达到这段程序的判定/条件覆盖,我们采用测试用例:

    1)a = true , b = true;

    2)a = false, b = false

    5条件组合覆盖(MCC)

    选择足够的测试用例,使得每个判定中条件的各种可能组合都至少出现一次。显然,满足“条件组合覆盖”的测试用例是一定满足“判定覆盖”、“条件覆盖”和“判定/条件覆盖”的。

     

    例:

    int a,b;

    if(a || b)

    执行语句1

    else

    执行语句2

     

    要达到这段程序的判定/条件覆盖,我们采用测试用例:

    1)a = true , b = true;

    2)a = false, b = false

    3)a = true,  b = false

    4)a = false,  b = ture

    6修正判定条件覆盖(MC/DC)

    MC/DC首先要求实现条件覆盖、判定覆盖,在此基础上,对于每一个条件C,要求存在符合以下条件的两次计算:
        1)条件C所在判定内的所有条件,除条件C外,其他条件的取值完全相同;
        2)条件C的取值相反;
        3)判定的计算结果相反。

        核心意思是每个条件都要独立影响判定结果。为什么说“两次计算”,而不是“两个用例”呢?当循环中有判定时,一个用例下同一判定可能被计算多次,每次的条件值和判定值也可能不同,因此,一个用例就可能完成循环中判定的MC/DC。

        MC/DC是条件组合覆盖的子集。条件组合覆盖要求覆盖判定中所有条件取值的所有可能组合,需要大量的测试用例,实用性较差。MC/DC具有条件组合覆盖的优势,同时大幅减少用例数。满足MC/DC的用例数下界为条件数+1,上界为条件数的两倍,例如,判定中有三个条件,条件组合覆盖需要8个用例,而MC/DC需要的用例数为4至6个。如果判定中条件很多,用例数的差别将非常大,例如,判定中有10个条件,条件组合覆盖需要1024个用例,而MC/DC只需要11至20个用例。

        下面是MC/DC的示例:

        代码:
        int func(BOOL A, BOOL B, BOOL C)
        {
            if(A && (B || C))
                return 1;
            return 0;
        }

        用例:

        对于条件A,用例1和用例2,A取值相反,B和C相同,判定结果分别为1和0;
        对于条件B,用例1和用例3,B取值相反,A和C相同,判定结果分别为1和0;
        对于条件C,用例3和用例4,C取值相反,A和B相同,判定结果分别为0和1。

    9路径覆盖(PC)

    MC/DC被称为“最严格的标准”,但这种说法是将条件组合覆盖和路径覆盖排除在外为基础的。MC/DC显然不如条件组合覆盖严格,但是条件组合覆盖需要太多用例,实际应用中难以做到,所以排除,那么,路径覆盖是否也难以做到?使用先进的工具,对于一般的代码,实现路径覆盖还是可能的。另外,路径代表了从函数入口到出口的所有可能的代码组合,这些组合会不会出问题?只有路径覆盖能发现,这与MC/DC侧重于判定内的条件的组合关系是完全不同的。

        MC/DC与路径覆盖的侧重点不同,两者都有其优势和局限性,如果组合起来,优势互补,形成“MC/DC-路径覆盖”,就是真正意义上的“最严格的标准”了。

        有些程序,路径数量可能大得惊人,可用以下规则和方法减少路径数量:
        计算路径时,不考虑循环的次数,将循环结构视为循环体“至少执行一次”和“从不执行”两个分支;
        不考虑条件的计算结果只考虑判定的计算结果,条件间的组合关系由条件覆盖、C/DC和MC/DC负责;
        一个分支如果不可达,通过该分支的所有路径也不可达,可以让工具自动排除;
        当代码很复杂时,理想的处置方式是将部分代码独立为函数,如果做不到,可以让工具来模拟,即在逻辑结构图中,将部分代码临时屏蔽,被屏蔽的代码视为一个函数调用。交替屏蔽可以既减少路径数量,又保证路径覆盖的效果。

        对于一般复杂度的代码,采用以上规则和方法后,路径数量和用例数量可以维持在一个现实可覆盖的的范围内。

        路径覆盖的主要缺陷是:不相关的逻辑块会组合出大量没有意义的路径。一个函数的路径,可能达到几万条甚至几百万条。如果路径超过100条,通常路径覆盖就没有意义了。对于一般企业来说,建议用MC/DC作为统一的覆盖标准,只有特别关键的代码,才要求完成“MC/DC-路径覆盖”。

     

    路径覆盖要求设计足够多的测试用例,在白盒测试法中,覆盖程度最高的就是路径覆盖,因为其覆盖程序中所有可能的路径。

    对于比较简单的小程序来说,实现路径覆盖是可能的,但是如果程序中出现了多个判断和多个循环,可能的路径数目将会急剧增长,以致实现路径覆盖是几乎不可能的。

     

    (五)基本路径测试法

    基本路径测试法是在程序控制流图的基础上,通过分析控制构造的环路复杂性,导出基本可执行路径集合,从而设计测试用例的方法。

      设计出的测试用例要保证在测试中程序的语句覆盖100%,条件覆盖100%。

      在程序控制流图的基础上,通过分析控制构造的环路复杂性,导出基本可执行路径集合,从而设计测试用例。包括以下4个步骤和一个工具方法:

      1.程序的控制流图:描述程序控制流的一种图示方法。

      2.程序圈复杂度:McCabe复杂性度量。从程序的环路复杂性可导出程序基本路径集合中的独立路径条数,这是确定程序中每个可执行语句至少执行一次所必须的测试用例数目的上界。

      3.导出测试用例:根据圈复杂度和程序结构设计用例数据输入和预期结果。

      4.准备测试用例:确保基本路径集中的每一条路径的执行。

      工具方法:

      图形矩阵:是在基本路径测试中起辅助作用的软件工具,利用它可以实现自动地确定一个基本路径集。

      程序的控制流图:描述程序控制流的一种图示方法。

      圆圈称为控制流图的一个结点,表示一个或多个无分支的语句或源程序语句

                

    流图只有二种图形符号:

      图中的每一个圆称为流图的结点,代表一条或多条语句。

      流图中的箭头称为边或连接,代表控制流

      任何过程设计都要被翻译成控制流图。

      如何根据程序流程图画出控制流程图?

      在将程序流程图简化成控制流图时,应注意:

      1)在选择或多分支结构中,分支的汇聚处应有一个汇聚结点。

      2)边和结点圈定的范围叫做区域,当对区域计数时,图形外的区域也应记为一个区域。

    如下图所示

           

     

            3)如果判断中的条件表达式是由一个或多个逻辑运算符 (OR, AND, NAND, NOR)连接的复合条件表达式,则需要改为一系列只有单条件的嵌套的判断。

      例如:

      1 if a or b

      2 x

      3 else

      4 y

      对应的逻辑为:

            

    独立路径:至少沿一条新的边移动的路径

            

    基本路径测试法的步骤:

      第一步:画出控制流图

      流程图用来描述程序控制结构。可将流程图映射到一个相应的流图(假设流程图的菱形决定框中不包含复合条件)。在流图中,每一个圆,称为流图的结点,代表一个或多个语句。一个处理方框序列和一个菱形决测框可被映射为一个结点,流图中的箭头,称为边或连接,代表控制流,类似于流程图中的箭头。一条边必须终止于一个结点,即使该结点并不代表任何语句(例如:if-else-then结构)。由边和结点限定的范围称为区域。计算区域时应包括图外部的范围。

              

    画出其程序流程图和对应的控制流图如下

               

    第二步:计算圈复杂度

      圈复杂度是一种为程序逻辑复杂性提供定量测度的软件度量,将该度量用于计算程序的基本的独立路径数目,为确保所有语句至少执行一次的测试数量的上界。独立路径必须包含一条在定义之前不曾用到的边。

      有以下三种方法计算圈复杂度:

      流图中区域的数量对应于环型的复杂性;

      给定流图G的圈复杂度V(G),定义为V(G)=E-N+2,E是流图中边的数量,N是流图中结点的数量;

      给定流图G的圈复杂度V(G),定义为V(G)=P+1,P是流图G中判定结点的数量。

                

    第三步:导出测试用例

      根据上面的计算方法,可得出四个独立的路径。(一条独立路径是指,和其他的独立路径相比,至少引入一个新处理语句或一个新判断的程序通路。V(G)值正好等于该程序的独立路径的条数。)

      ü路径1:4-14

      ü路径2:4-6-7-14

      ü路径3:4-6-8-10-13-4-14

      ü路径4:4-6-8-11-13-4-14

      根据上面的独立路径,去设计输入数据,使程序分别执行到上面四条路径。

      o第四步:准备测试用例

      为了确保基本路径集中的每一条路径的执行,根据判断结点给出的条件,选择适当的数据以保证某一条路径可以被测试到,满足上面例子基本路径集的测试用例是:

              

     

    举例说明:

      例:下例程序流程图描述了最多输入50个值(以–1作为输入结束标志),计算其中有效的学生分数的个数、总分数和平均值。

               

    步骤1:导出过程的流图。

               

    步骤2:确定环形复杂性度量V(G):

      1)V(G)= 6 (个区域)

      2)V(G)=E–N+2=16–12+2=6

      其中E为流图中的边数,N为结点数;

      3)V(G)=P+1=5+1=6

      其中P为谓词结点的个数。在流图中,结点2、3、5、6、9是谓词结点。

      步骤3:确定基本路径集合(即独立路径集合)。于是可确定6条独立的路径:

      路径1:1-2-9-10-12

      路径2:1-2-9-11-12

      路径3:1-2-3-9-10-12

      路径4:1-2-3-4-5-8-2…

      路径5:1-2-3-4-5-6-8-2…

      路径6:1-2-3-4-5-6-7-8-2…

      步骤4:为每一条独立路径各设计一组测试用例,以便强迫程序沿着该路径至少执行一次。

      1)路径1(1-2-9-10-12)的测试用例:

      score[k]=有效分数值,当k < i ;

      score[i]=–1, 2≤i≤50;

      期望结果:根据输入的有效分数算出正确的分数个数n1、总分sum和平均分average。

      2)路径2(1-2-9-11-12)的测试用例:

      score[ 1 ]= – 1 ;

      期望的结果:average = – 1,其他量保持初值。

      3)路径3(1-2-3-9-10-12)的测试用例:

      输入多于50个有效分数,即试图处理51个分数,要求前51个为有效分数;

      期望结果:n1=50、且算出正确的总分和平均分。

      4)路径4(1-2-3-4-5-8-2…)的测试用例:

      score[i]=有效分数,当i<50;

      score[k]<0, k< i ;

     期望结果:根据输入的有效分数算出正确的分数个数n1、总分sum和平均分average。

              

      连接权为“1”表示存在一个连接,在图中如果一行有两个或更多的元素“1”,则这行所代表的结点一定是一个判定结点,通过连接矩阵中有两个以上(包括两个)元素为“1”的个数,就可以得到确定该图圈复杂度的另一种算法。

     

    (六)域测试法

    域测试是一种基于程序结构的测试方法,基于对程序输入空间(域)的分析,选择测试点进行测试。

    域测试主要测试如下错误:

    1)域错误:程序的控制流存在错误,对于某一特定的输入可能执行的是一条错误路径,这种错误称为路径错误,也叫做域错误。

    2)计算型错误:对于特定输入执行的路径正确,但赋值语句的错误导致输出结果错误,称为计算型错误。

    3)丢失路径错误:由于程序中的某处少了一个判定谓词而引起的丢失路径错误。

     

    (七)符号测试

    符号测试的基本思想是允许程序的输入不仅仅是具体的数值数据,而且包括符号值,符号值可以是基本的符号变量值,也可以是符号变量值的表达式。

     

     

    接口测试用例实际

    设计思路

    1)   优先级--针对所有接口

    1、暴露在外面的接口,因为通常该接口会给第三方调用;

    2、供系统内部调用的核心功能接口;

    3、供系统内部调用非核心功能接口;

     

    2)   优先级--针对单个接口

    1、正向用例优先测试,逆向用例次之(通常情况,非绝对);

    2、是否满足前提条件 > 是否携带默认参值参数 > 参数是否必填 > 参数之间是否存在关联 > 参数数据类型限制 >参数数据类型自身的数据范围值限制

     

     

    3)   设计分析

    通常,设计接口测试用例需要考虑以下几个方面:

    1、是否满足前提条件

    有些接口需要满足前置条件,才可成功获取数据。常见的,需要登陆Token。

    逆向用例:

    针对是否满足前置条件(假设为n个条件),设计0~n条用例

     

    2、是否携带默认值参数

    正向用例:

    带默认值的参数都不填写、不传参,必填参数都填写正确且存在的“常规”值,其它不填写,设计1条用例;

     

    3、业务规则、功能需求

    这里根据实际情况,结合接口参数说明,可能需要设计n条正向用例和逆向用例

     

    5、参数是否必填

    逆向用例:

    针对每个必填参数,都设计1条参数值为空的逆向用例

     

    4、参数之间是否存在关联

    有些参数彼此之间存在相互制约的关系

    逆向用例:

    根据实际情况,可能需要设计0~n条用例

     

    5、参数数据类型限制

    逆向用例:

    针对每个参数都设计1条参数值类型不符的逆向用例

     

    6、参数数据类型自身的数据范围值限制

    正向用例:

    针对所有参数,设计1条每个参数的参数值在数据范围内为最大值的正向用例

     

    逆向用例:

    针对每个参数(假设n个),设计n条每个参数的参数值都超出数据范围最大值的逆向用例

    针对每个参数(假设n个),设计n条每个参数的参数值都小于数据范围最小值的逆向用例

     

    以上几个方面考虑全的话,基本可以做到如下几个方面的覆盖:

    主流程测试用例:正常的主流程功能校验;

    分支流测试用例:正常的分支流功能校验。

    异常流测试用例:异常容错校验

     

    4)   编写描述

    尽量逻辑化,这样方便后续的维护

     

    5)   实践操作

    接口样例

    获取订单列表接口(多条件)

    获取店铺指定期间的所有订单列表(多种条件组合),默认根据日期倒序排序。

    接口方向

    客户端 -> 服务端

    接口协议

    接口地址:$xxx_Home/xxx/鉴权前缀/xxxxx/getAllOrderList

    接口协议:JSON

    HTTP请求方式:GET

     

    消息请求

    字段列表如下:

    字段名

    数据类型

    默认值

    必填项

    备注

    shopId

    int

     

    商铺编号

    token

    string

     

    条件

    设备令牌。Token鉴权方式必填

    dateType

    int

    1

    订单查询时间字段。

    1:下单时间(order_time)

    2:订单完成时间(order_finish_time)

    3:结算时间(shop_settle_time)

    startDate

    date

     

    查询日期

    endDate

    Date

     

    查询结束日期。

    orderStatus

    String

     

    订单状态。

    不填表示所有状态

    多个状态之间以英文逗号分割

    0:已预定

    1:已开单

    2:派送中

    3:已完成(原已结帐)

    4:退单中

    5:已退单

    8:自助下单

    9:待确认

    orderTransactionType

    Int

     

    订单交易状态。

    不填表示所有。

    1:未完成,

    2:已完成(3:已完成, 5:已退单)

    payType

    int

     

    支付方式。

    不填表示所有。

    1:现金

    2:POS

    3:线上

    cashierId

    int

     

    收银员

    billerId

    int

     

    导购员

    pNo

    int

     

    页码,从第1页开始,默认为1

    pSize

    int

     

    每页记录数,默认为10

     

    消息请求样例:

    ?shopId=1111111111&token=123411nmk515155&queryDate=2015-10-10

    消息响应

    字段元素如下:

    字段名

    数据类型

    默认值

    必填项

    备注

    orderTotalPriceTotal

    double

     

    实收金额合计(已完成的合计)

    platformTotalIncomePriceTotal

    double

     

    平台服务费合计

    cashPayTotal

    double

     

    现金支付(已完成的合计)

    posPayTotal

    double

     

    POS支付(已完成的合计)

    onLinePayTotal

    double

     

    线上支付(已完成的合计)

    lst

    object

     

    明细列表

     

    明细列表对象字段元素定义:

     

    字段名

    数据类型

    默认值

    必填项

    备注

    orderId

    string

     

    订单ID

    orderTitle

    string

     

    订单标题

    mobile

    string

     

    会员账号,如果是会员则显示手机号,为空时表示“非会员”

    settlePrice

    double

     

    交易金额

    orderTime

    datetime

     

    下单时间

    serviceAmount

    double

     

    平台服务费

    Status

    Int

     

    订单状态。

    0:已预定

    1:已开单

    2:派送中

    3:已完成(原已结帐)

    4:退单中

    5:已退单

    8:自助下单

    9:待确认

    cashPay

    double

     

    现金支付

    posPay

    double

     

    POS支付

    onLinePay

    double

     

    线上支付

     

    成功时,返回JSON数据包:

    {

        "code": 0,

        "msg": "查询订单列表成功!",

        "data": {

            "pNo": 1,

            "rCount": 5,

            "orderTotalPriceTotal": 23.3,

            "platformTotalIncomePriceTotal": 0,

            "lst": [

                {

                    "orderTitle": "kouxiangtang",

                    "settlePrice": 15.89,

                    "cashTotal": 15.89,

                    "posTotal": 0,

                    "onLineTotal": 0,

                    "orderTime": "2015-09-29 13:44:26",

                    "orderId": "12345679282015092913440268141",

                    "mobile": "13424183952"

                },

                {

                    "orderTitle": "红塔山",

                    "settlePrice": 7.5,

                    "cashTotal": 7.5,

                    "posTotal": 0,

                    "onLineTotal": 0,

                    "orderTime": "2015-09-29 11:37:58",

                    "orderId": "12345679282015092911370588273"

                }

            ]

        }

    }

     

     

     

    用例设计

     

     

    测试思想-测试设计 <wbr>接口测试用例设计实践总结

    测试思想-测试设计 <wbr>接口测试用例设计实践总结


    测试思想-测试设计 <wbr>接口测试用例设计实践总结

    测试思想-测试设计 <wbr>接口测试用例设计实践总结

     

     

    存在问题:

    如上,还没写完就有40几条用例了,要是接口参数再多点,接口数量再增加点,工作量可想而知,所以,问题来了,咋办呢?

     

    个人见解:

    1、根据接口的使用对象(外部,系统内部),有选择的去、留部分用例

    2、根据接口的是否核心接口,有选择的去、留部分用例

    3、根据参数说明,及实际情况,有选择的去、留部分用例

     

    实例:

    上例这个接口,是供app、商铺后台调用的,且为系统内部调用,所以,以下用例可酌情略去:

    test-E-按商铺id查询-商铺id非int型

    test-E-按设备token查询-token非string类型

    test-E-按订单时间类型查询-时间类型非int型

    test-E-按起始日期查询-时间类型非date型

    test-E-按结束日期查询-时间类型非date型

    test-E-按订单状态查询-订单状态非string类型

    test-E-按交易状态查询-交易状态非int型

    test-E-按支付方式查询-支付方式非int值

    test-E-按收银员查询-收银员id非int值

    test-E-按导购员查询-导购员id非int值

    test-E-按页码查询-页码非int值

     

    理由:

    这个接口是给其它开发于系统内部调用的,开发过程中,开发者肯定需要调用这些接口,如果类型错了,他们也就获取不到预期的数据,这些错误,他们肯定可以发现,所以,他们传递的参数值一般能保证类型正确。

     

    test-N-按参数类型最大值查询    所有参数

    test-E-按商铺id查询-商铺id超过类型范围值

    test-E-按订单状态查询-订单状态值超过类型最大值

    test-E-按交易状态查询-交易状态值超过int类型最大值

    略去的用例部分(参数值超过类型最大值)

     

    理由:

    1、内部调用,参数值不是外部手动输入的,输入数据长度、值大小可控,当然如果数据一直增长,那再大的类型可能都无法保证不超出,比如自动增长的商铺id

    2、部分参数的参数值是自定义的,比如 订单时间类型,就那几种,除非传错了,不然不可能超出范围

     

    最后简化后的用例数差不多28条,如果是手工测试,对于正向用例,根据等价类原理,可以制造一条数据,覆盖多条用例,当然,也可以冗余处理,即一条用例一条数据,这样的好处就是每次的验证点比较单一一点,比较有针对性。

     

     

     


    展开全文
  • 软件测试之测试用例设计(一)

    万次阅读 多人点赞 2019-07-23 19:26:19
    通俗来说就是:通过设计输入数据,执行步骤,按此步骤应产生的预期结果 它是指导测试进行的依据 目的:高效率地发现软件缺陷而精心设计的少量测试数据 2.测试用例的特性 有效性:能使用,不同人使用结果一致...
  • java数据结构与算法之(Queue)队列设计与实现

    万次阅读 多人点赞 2016-12-04 10:05:06
    队列的抽象数据类型 顺序队列的设计与实现 链式队列的设计与实现 队列的简单应用 优先队列的设置与实现
  • java数据结构与算法之栈(Stack)设计与实现

    万次阅读 多人点赞 2016-11-28 12:27:43
    【版权申明】转载请注明出处(请尊重原创,博主...关联文章:java数据结构与算法之顺序表与链表设计与实现分析 java数据结构与算法之双链表设计与实现 java数据结构与算法之改良顺序表与双链表类似ArrayList和LinkedL
  • 【版权申明】未经博主同意,不允许转载!...关联文章:java数据结构与算法之顺序表与链表设计与实现分析 java数据结构与算法之双链表设计与实现 java数据结构与算法之改良顺序表与双链表类似ArrayList和L
  • 数据挖掘之异常点检测

    千次阅读 2018-01-31 18:37:49
    iForest (Isolation Forest)孤立森林 是一个基于Ensemble的快速异常检测方法,具有线性时间复杂度和高精准度,是符合大数据处理要求的state-of-the-art算法(详见新版教材“Outlier Analysis”第5和第6章 ...
  • 表面缺陷检测数据集汇总及其相关项目推荐

    千次阅读 多人点赞 2020-06-27 00:00:00
    包含是个数据集,前六个为训练数据集,后四个为测试数据集。 每个数据集均包含以灰度8位PNG格式保存的1000个“无缺陷”图像和150个“有缺陷”图像。每个数据集由不同的纹理模型和缺陷模型生成。 “无缺陷”图像显示...
  • 阿里云首次发布云原生数据湖体系,基于对象存储OSS、数据湖构建Data Lake Formation和E-MapReduce产品的强强组合,提供存储与计算分离架构下,涵盖湖存储、湖加速、湖管理和湖计算的企业级数据湖解决方案。...
  • 2019年电子设计竞赛综合测评解析及仿真(原创)

    万次阅读 多人点赞 2020-03-09 20:54:24
    2019年电子设计竞赛综合测评解析及仿真(原创) ...设计报告应给出方案设计、详细电路图、参数计算和现场自测数据波形(一律手写),综合测评板编号及3个参赛同学签字须在密封线内,限2页,与综合测评板一同...
  • RF自动化测试系列-第三篇 测试数据

    千次阅读 2018-11-17 18:01:23
    版权声明:博主原创,转载请注明作者及出处。 Robot的测试数据可以分为三层结构:测试工程Project(或叫主目录),测试集合Test Suite,测试用例Test Case。除了这三层基本机构外, 还有用户关键字,变量文件,...
  • 云原生应用的十大设计原则

    万次阅读 2021-03-10 22:19:12
    使用最佳的数据存储完成作业 演变设计 根据业务需求构建 越来越多的企业选择上云,在云上构建自己公司的核心应用程序,通过云来大大减少公司的IT运维成本,提高应用的弹性能力,并把一些新兴的技术能力,例如:...
  • ROS机器人程序设计书第2版) 补充资料 教学大纲针对该书稍后会补充教学大纲、教案、多媒体课件以及练习题等。《ROS机器人程序设计》课程简介课程编号:XXXXXX课程名称:ROS机器人程序设计学分/学时:3/48开课...
  • 【版权申明】未经博主同意,不允许转载!...关联文章:java数据结构与算法之顺序表与链表设计与实现分析 java数据结构与算法之双链表设计与实现 java数据结构与算法之改良顺序表与双链表类似ArrayList和L
  • 数据结构”课程设计题目

    万次阅读 2016-09-09 18:38:24
    数据结构”课程设计题目 1、城市链表 [问题描述] 将若干城市的信息,存入一个带头结点的单链表。结点中的城市信息包括:城市名,城市的位置坐标。要求能够利用城市名和位置坐标进行有关查找、插入、删除、更新...
  • 我们从HOG( Histogram of OrientedGradients)描述子获得灵感,设计了一个在稠密深度数据中检测人体的方法,叫做深度方向直方图HOD(Histogram of Oriented Depths)。HOD对局部深度变化的方向进行编码,依靠在预知深度...
  • 基于数据设计(Data-oriented design)

    千次阅读 2014-10-15 08:00:18
    基于数据设计(DOD)  对于开发末期的循环,你的游戏正在缓缓开发,但是你没有看到任何热点,原因?。。。。。这件事实在是准确的描述了在这十年我遇到的几乎所有游戏中的情况,问题不在于我们用的编程语言,也...
  • 性能自动化测试之LoadRunner场景设计

    万次阅读 2020-02-03 18:19:51
    说明:该篇博客是博主一字一码编写的,...一、场景设计 Controller 是 LR 的控制中心,包括场景设计和场景执行。 1.场景设计 场景设计是依据需求制定脚本如何执行的策略,使脚本运行更接近真实用户使用。 主要包括...
  • 软件测试之测试用例设计(二)

    万次阅读 2019-07-26 21:25:45
    说明:该篇博客是博主一字一码编写的,实属不易,请尊重原创,谢谢大家! ... 目录 一丶边界值例题 ...三丶黑盒测试用例设计(正交实验) ...1.结合等价类划分法,设计测试数据! 移动公司话费赠送方案如下 2. 测试...
  • 三、测试需求分析与测试用例设计方法 1.场景法 1.1 测试点/检查点 1.2 场景法概述 1.3 场景的定义 1.4 场景法的分析步骤 1.5 场景法案例:ATM 机取款 1.6 场景法练习 2.等价类划分 2.1 案例引入 2.2 等价类划分核心...
  • 数据结构课程设计报告-职工信息管理系统

    万次阅读 多人点赞 2016-02-24 13:34:39
    数据结构”课程设计报告 职工信息管理系统 课程设计任务与要求: [问题描述] 每个员工的信息包括:编号、姓名、性别、出生年月、学历、职务、电话、住址等。系统能够完成员工信息的查询、更新、插入、删除、排序等...
  • 微服务架构设计实践 目 次1 序言2 微服务3 软件架构设计思想4 微服务架构设计实践4.1 项目概述4.2 架构准备阶段4.3 概念架构阶段4.4 细化架构阶段4.4.1 业务架构4.4.2 数据架构4.4.3 应用架构4.4.4 技术架构4.4.5 ...
  • 《黑盒测试的测试用例设计方法 》等价类划分 是把所有可能的输入数据,即程序的输入域划分成若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计...
  • 测试用例设计——如何提高测试覆盖率

    万次阅读 多人点赞 2015-01-04 14:11:35
     但事实上撇开测试数据设计不谈,仅就测试项来说,我们发现,对同一个项目,有经验的测试人员,在写用例或测试时总会有更多的测试考虑点,从而发现更多 的问题;而有些测试人员测试用例的撰写却
  • 我们可以再设计一套数据仓库的分层,同时在前面的基础上加上维表和一些临时表的考虑,来让我们的方案更优雅一些。 下图,做了一些小的改动,我们去掉了上一节的Buffer层,把数据集市层和轻度汇总层放在同一个层级上...
  • 只能为每一份数据单独设计一张表,而且当入库数据量达到1T的时候,MySQL数据库直接崩溃。最后好不容易把数据导入到MySQL数据库,然而由于缺乏更深入的MySQL数据库调优经验,一个简单的数据查询过程,耗时费力。 ...
  • 手游测试(测试内容、测试流程、测试用例)

    万次阅读 多人点赞 2019-06-12 18:04:16
    主要验证功能是否符合需求设计 主要考虑功能正确性,不考虑游戏底层结构及代码错误 通常从界面着手测试,尽量模拟用户可能出现的操作 性能测试 测试点 客户端CPU使用率 客户端内存占用率 客户端网络流量使用情况...
  • 基于华为产品的高校云数据中心建设规划设计方案

    万次阅读 多人点赞 2017-05-18 22:38:11
    基于华为产品的整体架构设计。从底层到上层的全方位指导。

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 295,245
精华内容 118,098
关键字:

数据设计原测