面向对象分析设计Chapter05

§5.1分析模型测试的重要性第五章分析模型的测试§5.3测试过程§5.2测试方法第五章小结§5.4用例模型的测试§5.5类模型的测试§5.6类状态模型的测试§5.7典型场景的测试传统的观点认为测试要在编码之后才进行，假设测试的对象是程序代码。需求和设计是代码产生的基础，需要对需求和设计进行测试。需求或设计的测试通常以两种方式进行：一是在没有代码的情况下进行测试；二是在有代码的情况下进行测试。第五章分析模型的测试分析模型的测试实际上包括两部分内容：针对分析模型测试模型的完整性；根据分析模型为系统的测试(包括类级别的单元测试、集成测试等)，定义测试用例。通常模型的测试采用正式评审会方式进行。在需求阶段不会执行什么实在的测试用例，定义测试用例。在设计阶段需要设计测试用例。在不同的软件开发过程模型中，需求、设计和编码总是有一定的时序特性。需求模型、设计模型和实现代码之间还具备解释特性，即设计解释了需求，实现代码解释了设计。需求的质量影响并决定了设计的质量，进而影响并决定了代码，直至整个系统的最终质量。§5.1分析模型测试的重要性必须首先重视需求的质量，而测试是质量保证的重要手段。需求测试可以较早地发现需求中不合理的项目、以及错误地理解了用户需求的项目，避免对于成本和资源的消耗。同时也减少了返工的几率，应尽早发现并解决这些问题。用户需求是用户对待实现的系统的要求，通常以一种非正规的形式给出，具有一定的模糊性。这种模糊性带入了设计，甚至代码中，将可能引发几倍，甚至几十倍的错误，这必将极大地消耗系统的资源和成本。§5.2测试方法基于代码——代码走查静态基于非代码——评审(需求和设计规格说明)动态——测试用例驱动代码执行根据测试方式目的可分为：数据流测试方式；控制流测试方式；事务流测试方式(数据流和控制流综合测试)。测试是否应深入到代码逻辑中：黑盒测试白盒测试在UML中，对需求模型的测试：评审；事务流(场景)模型等方法测试(需结合具体的模型描述)；正式——承担责任，写出评审报告评审非正式评审的目的是对具体的工作产品集(如文档、源代码)进行评价，并对管理提供以下信息：是否符合制定的软件规格；是否按照项目的标准和方法完成；是否所有的更改都正确地得到完成。评审计划需要列出的项目(解决测什么，什么时候测，谁来测)：哪些人将参加评审会，各自的职责是什么；需要准备哪些材料；必须满足什么条件；要完成的检查单或其他的指标；评审会完成所必须满足的条件或准则；评审会结束后需要保留归档的记录和文档。参加评审人员：用户，软件项目负责人，软件工程师，软件配置管理人员，软件质量保证人员；软件独立验证与确认人员，软件开发无关的专家。测试实际上也是一个项目。测试也有需求、设计和实现，并且测试本身也会有测试(测试中的测试)。测试作为项目开发活动中的一部分，在时间上应该有明确的要求，测试计划对于测试来说也是至关重要的。UML分析模型的每个模式，从严格意义上说都应该经过测试。实际上，通常对用例模型、类对象模型以及用例中典型场景进行测试。§5.3测试过程通常测试步骤如下：测试用例模型测试某些用例中的典型场景类及对象模型某些类测试其状态模型单个用例测试采取典型应用场景的测试方法，用例模型的测试相当于系统测试，测试的主要目标是用例模型对于用户需求的可跟踪性。以系统的用户为主要的出发点设计测试用例，通过模拟某个系统用户的行为来测试整个系统，对于该用户的服务提供情况，从而检查系统功能的完整性，用户需求可跟踪性等情况。用例模型的测试从系统用户的角度测试系统的服务，并不关心每个测试用例所实现的功能如何，所以应该是黑盒测试。§5.4用例模型的测试用例模型的测试可以通过系统的可能用户对系统的功能要求来设计测试用例。下面以一个订货中心系统的用例模型为例说明测试用例的设计。识别五个主要的系统角色(用户)：管理者(Manager)、发货人员(Shipper)收款人员(Tollcollector)、商务客户(Customer)信用卡(Creditcard)从各个角色出发通过下边的问题识别用例：角色要求系统提供的功能有哪些？系统在提供这些功能的时候该角色需要做什么？角色需要创建、阅读、销毁或存储系统的哪些信息？系统中的哪些事件需要通知该角色？以管理者为例：(1)管理者要求系统为他提供什么功能？管理者需要做哪些工作？答：管理者要求系统提供a.接受顾客订货请求并创建订单；b.计算订单的价钱；c.根据订单信息选择仓库，并将订单发送给仓库；d.查询订单货物发送情况；e.查询客户订单付款情况；f.评价商务结果；g.顾客退货处理；h.把仓库返回的订单发送到收费处；i.为价格更新。管理者需要做：生成订单；查询订单时输入订单号。(2)管理者需要阅读创建、销毁、更新或者存储系统哪些信息？答：是。信息包括：订单、职员(仓库人员、收费人员等)信息、顾客信息、物品条目及价格信息、仓库信息和税务信息。(3)系统中的事件一定要告诉管理者吗？答：是。这些事件包括：仓库有关物品短缺以致无法满足某订单；订单数据出现错误；顾客超过期限未付款。可见，管理者要使用系统的十个功能，因此至少可以设计出十个测试用例。下面以第三条功能“根据订单信息选择仓库，并将订单发送给该仓库”为例，显然，不同的订单产生的结果可能是送往不同的仓库来处理。假设订货中心共有三个仓库，现有一订单要让管理者决定应该选择哪个仓库处理订单，至少可设计出三个测试用例。仓库名称仓库位置存货品名及数量订单处理客户信誉度A东城G1(200)，G5(100)，G6(1000)，G10(70)，G11(90)85B西城G1(1000)，G2(100)，G5(250)，G8(150)，G10(98)95C北城G1(220)，G4(300)，G5(350)，G7(400)，G10(700)80系统用户考虑分配订单到某仓库的因素：(1)首先仓库必须能够满足订单上的货物要求；(2)选择地理位置与发货点较近的仓库发货；(3)信誉满意度越高的客户就越应该以较高的服务质量来回报。结合考虑上面三个因素，以最少的成本取得最好的收益，三个订单信息如下：订单号送货地点货物名称及数量客户信誉订单1北城某集团公司G1(200)，G5(100)，G10(40)95订单2东城某街道G5(10)，G6(5)80订单3北城某街道G4(10)85测试用例1：输入：订单1预期结果：选择仓库B来处理订单(三个均可，大宗订单，客户信誉度高)；测试用例2：输入：订单2预期结果：选择仓库A来处理订单(个人订单，客户信誉一般)；测试用例3：输入：订单3预期结果：选择仓库C来处理订单。以上测试未触及某个具体用例，体现了用例模型测试和用例测试的区别。类模型是分析模型中的核心，它抽象出了问题域中的对象和实体，以及它们在问题域中的职责。为确保类模型的正确性和完整性，只根据问题域测试类模型。测试方法是评审会。类图实际上由类和类之间的关系组成，评审会的检查单可从以下两个方面制定。§5.5类模型的测试针对每个类提问：(1)该类在问题域中对应的实体(或对象)是什么？(2)履行什么职责？(3)在类图中被赋予了哪些职责？(4)该类在问题域中的职责和在类图中的职责能匹配吗？(5)该类的每个数据属性都是问题域所关心的吗？针对类图中的类之间的关系提问：(1)这种类关系是反映了问题域本质的关系还是为管理类模型而引入的关系？(如果类之间的关系并非反映问题域的本质，那么这个关系的存在就值得怀疑。)(2)仔细检查每个继承关系，到底是聚集关系还是继承关系？(3)针对关联关系中的关联数目，提一些问题结合实际场景来考察。类状态模型描述了一个对象在问题域中的活动历程。在分析阶段，识别的对象还只是停留在较粗的层次上，因此，对象状态模型的测试通常只能采用评审会的办法。只测试在问题域中非常重要的对象，如电梯系统中的电梯对象。§5.6类状态模型的测试从模型的角度可以关心如下问题：(1)状态模型刻画了对象的生命周期吗？(2)针对每个状态而言，状态转移触发条件是状态转移的充分条件吗？(3)对象在问题域需要响应的所有条件是否在状态模型中都有响应？(4)关心对象在某些状态中的动作，如果对象需要发送消息给其它对象，那么此时接收该消息的对象处在其声明周期的什么阶段？(5)从初始状态开始，每个状态都可以达到吗？上述五个问题可以作为评审会问题检查单的选择。对问题(1)：检查状态模型对于对象状态的划分，一旦出现识别的状态不足，或者某些状态超出问题域的关心，分析原因，分析员在评审会报告想法和理由。对问题(2)：检查状态转移条件，验证当触发条件满足时是否会出现状态转移，要求触发条件是最简化的(无冗余条件)。对问题(3)：通过一张对照表可以找出答案。对问题(4)：检查较复杂，容易发现分析错误的一个环节。通常，分析员以为进行交互的其它对象都处于“良好”状态，但这个假设常常不能成立，因为两个不同的对象可能与相应的事件会有交叉(如定时事件)。因此，当当前分析的对象发生了状态转移时，其它对象也发生了状态转移，所以在对象发送消息给其它对象时，也要注意接收该消息的对象是否处于合适的状态中。对问题(5)：如果某个状态根本就不可达到，那么可以断定分析模型有错误。类级别的单元测试中，状态模型可以辅助进行测试用例的模型。顺着不同的状态演变路径来测试对象的动作行为(操作序列)，如帐号对象的状态图。空帐号帐号设置工作帐号当空帐号无效帐号opensetupdeposit(initial)depositwithdrawbalancecountwithdraw(final)close银行帐号共有5个生命周期状态，设计下面的测试用例：(1)测试用例1：open,setup,deposit(initial),withdraw(final),close;(2)测试用例2：open,setup,deposit(initial),deposit,balancecount,withdraw(final),close;(3)测试用例3：open,setup,deposit(initial),deposit,withdraw,balancecount,withdraw(final),close.上述测试用例覆盖每个状态，并增量测试每个状态的转移。该例不涉及复杂对象之间的交互情况，有对象交互的测试用例设计将更加困难。如果通过覆盖状态模型中的每个状态和每个状态转移，那么就可以测试到对象之间的各种情况。典型场景是指系统用户经常使用系统的方式。典型场景是用例模型的一个实例。典型场景测试主要关注用例执行情况，典型场景测试可能涉及到不止一个用例，通常测试的是系统的功能。测试可以根据需求分析出发列出的一些典型场景(顺序图模型所描述)进行。如果无典型场景的顺序图模型，可以把几个不同用例的顺序图模型联合起来，并选择一条对象交互链作为一个典型场景，这个场景就是测试用例。§5.7典型场景的测试在需求测试中最重要的是把握用户需求与需求模型的对照，根据问题域来测试分析模型。测试本身也是一个项目，包括计划、实施和评估实施结果，还必须对测试用例进行组织和管理。测试用例反映了测试工作量，是测试创造性的工作成果。通常开发和测试是并行的，随着开发组中引入新的代码，测试组需要进行回归测试，如果不对用例进行管理，将给回归测试带来困难。针对需求模型而言，由于模型还要经历分析和设计阶段的扩充，测试用例也会扩充。因此，把测试用例作为分析模型的一部分在项目环境中管理起来，使测试用例在整个项目组内共享，而且可以保证测试用例对模型的可跟踪性。正式测试有测试报告，包括测试目的、测试对象、测试人员、测试情况的描述、测试用例以及各个测试用例的执行情况。第五章小结