郑州软件开发讲解测试OAA和OOD模型

       郑州软件公司认为在前面学习了测试的目标，简单地说，在现实可行的时间跨度内应用可管理的工作量去发现尽可能多的错误。虽然对面向对象软件而言，这个基本目标仍保持不变，但是面向对象程序的性质改变了测试的策略和测试战术。

       有人可能争辩说，随着OOA和OOD的成熟，更多的设计模式复用将减轻面向对象系统的繁重测试量。准确地说，其反面才是真的。针对该问题有如下讨论。

       每次复用是一个新的使用语境，要谨慎地重新测试。为了获得面向对象系统的高可靠性，似乎可能将需要更多而不是更少的测试。

       为了充分地测试面向对象系统，必须做好3件事：①测试的定义必须扩大包括用于OOA和OOD模型的错误发现技术。②单元和集成测试策略必须有很大的改变。③测试用例的设计必须考虑面向对象软件的独特特征。

       扩大测试的视角

       郑州苹果软件开发认为面向对象软件的构造从分析和设计模型的创建开始。因为面向对象软件工程范型的演化性质，模型从对系统需求相对非正式的表示开始，逐步演化为详细的类模型、类连接和关系、系统设计和分配，以及对象设计（通过消息序列的对象连接模型）。在每个阶段，测试模型，以试图在错误传播到下一次递进前发现错误。

       可以争辩说面向对象分析和设计模型的复审是特别有用的，因为相同的语义结构（如类、属性、操作、消息）出现在分析、设计和代码阶段，因此，在分析阶段发现的类属性定义中的问题将遏止当问题直至设计或编码阶段（或甚至到下一次分析迭代）才被发现所带来的副作用。

       例如，考虑一个类，在第一次OOA迭代时定义了其中一系列属性，一个外来的无关属性被附于该类（由于对问题域的错误理解），然后定义两个操纵该属性的操作。在复审时，一个领域专家指出该问题。通过在本阶段删除该无关属性，可在分析过程中避免下面的问题和不必要的努力。

       （1）特殊的子类可能已经被生成以适应不必要的属性或它的例外。涉及不必要的子类的创建工作可被避免。

       （2）类定义的错误解释可能导致不正确的或无关的类关系。

       （3）系统或它的类的行为可能被不适当地刻画以适应该无关属性。

       如果问题未在分析过程中被发现并进一步向前传播，在设计中可能产生下面的问题（如尽早复审，应己避免的）。

       （1）在系统设计阶段可能将类不合适的分配到子系统和／或任务。

       （2）可能花费不必要的工作去创建针对无关属性的操作的过程设计。

       （3）消息模型将是不正确的（因为必须为无关的操作设计消息）。

       郑州android开发认为如果问题在设计阶段仍未被检测到，并传送到编码活动中，则将花费大量的工作努力和精力去生成那些实现一个不必要的属性、两个不必要的操作、驱动对象间通信的消息以及很多其他相关问题的代码。此外，类的测试将花费更多的时间。一旦问题最终被发现，必须对系统进行修改，从而引致由于修改而产生到作用的很大的潜在可能性。

       在它们的开发的后面阶段，OOA和OOD模型提供了关于系统的结构和行为的实质性信息，为此，这些模型应该在生成代码前经受严格的复审。

       所有面向对象模型应该被测试（在这个语境内，术语“测试”代表正规的技术复审），以保证在模型的语法、语义和语用的语境内的正确性、完整性和一致性。

       测试OOA和OOD模型

       分析和设计模型不能进行传统意义上的测试，因为它们不能被执行。然而，正式的技术复审可被用于检查分析和设计模型的正确性和一致性。

       1．OOA和OOD模型的正确性

       用于表示分析和设计模型的符号体系和语法将是和为项目选定的特定分析和设计方法联系的，因此，语法正确性基于符号是否合适使用，而且对每个模型复审以保证保持合适的建模约定。

       郑州安卓软件开发认为在分析和设计阶段，语义正确性必须基于模型对现实世界问题域的符合度来判断，如果模型精确地反映了现实世界（到这样一个细节程度：它对模型复审时所处的开发阶段是合适的），则它是语义正确的。为了确定是否模型确实在事实上反映了现实世界，它应该被送给问题域专家，专家将检查类定义和类层次以发现遗漏和含混。评估类关系（实例连接）以确定它们是否精确地反映了现实世界的对象连接。

       2．OOA和OOD模型的一致性

       对OOA和OOD模型的一致性判断可以通过“考虑模型中实体间的关系。一个不一致的模型在某一部分有表示，但未在模型的其他部分正确地反应”。

       为了评估一致性，应该检查每个类及其和其他类的连接。可运用类一责任一协作者（CRC）模型和对象一关系图。如在第6章提到，CRC模型由CRC索引卡片构成，每个CRC卡片列出类名、类的责任（操作），以及其协作者（其他类，类向它们发送消息并依赖于它们完成自己的责任）。协作蕴含了在面向对象系统的类之间的一系列关系（即连接），对象关系模型提供了类之间连接的图形表示。所有这些信息可以从OOA模型得到。

       为了评估类模型，推荐采用以下面步骤得到。

       （1）再次考察 CRC模型和对象一关系模型，郑州ios开发认为进行交叉检查以保证由OOA模型所蕴涵的协作适当地反应在二者中。

       （2）检查每个CRC索引卡片的描述以确定是否某被受权的责任是协作者的定义的一部分。

       （3）反转该连接以保证每个被请求服务的协作者正在接收来自合理源的请求。

       （4）使用在第（3）步检查的反转连接，确定是否可能需要其他的类或责任是否被合适地在类间分组。

       （5）确定是否被广泛请求的责任可被组合为单个的责任。

       （6）步骤（1）——（5）被迭代地应用到每个类，并贯穿OOA模型的每次演化。

       郑州plc开发认为一旦已经创建了设计模型，也应该进行对系统设计和对象设计的复审。系统设计描述了构成产品的子系统、子系统被分配到处理器的方式，以及类到子系统的分配。对象模型表示了每个类的细节和实现类间的协作所必需的消息序列活动。

       通过检查在OOA阶段开发的对象一行为模型，和映射需要的系统行为到被设计用于完成该行为的子系统来进行系统设计的复审。也在系统行为的语境内复审并发性和任务分配，评估系统的行为状态以确定哪些行为并发地存在。

       对象模型应该针对对象——关系网络来测试，以保证所有设计对象包含为实现为每张CRC索引卡片定义的协作所必须的属性和操作。此外，使用传统的检查技术来复杂操作细节的详细规约（即实现操作的算法）。

       转载请注明出处：郑州知网软件  http://www.nwisdom.com