郑州软件开发之面向对象软件的测试用例设计(二

       5．测试用例和类层次

       如本章前面所述，继承并没有排除对所有派生类进行全面测试的需要，事实上，它确实使测试过程变得复杂。

       郑州软件公司认为考虑下面情形，类 base包含了操作 inherited和 redefined，类 derived使 re一efined定义以用于局部语境中，毫无疑问，必须测试 derived：：redefined（）操作，因为它表示了新的设计和新的代码。但是，必须重测试  derived：：inherited（）操作吗？

       如果 derived：：inherited（）调用 redefined，而 redefined的行为已经改变，derived：：bented（）可能错误地处理这新行为，因此，即使其设计和代码没有改变，它需要被重新测试。然而，重要的是要注意，仅仅必须执行 derived：：inherited（）的所有测试的一个子集。如果 inherited的设计和代码部分不依赖于 redefined（即不调用它或任意间接调用它的代码），则不需要在derived类中重测试该代码。

       base：：redefined（）和  derived：：red：fi：d（）是具有不同规约和实现的两个不同的操作，它们各自具有一组从规约和实现导出的测试需求，这些测试需求探查似乎可能的故障：集成故障、条件故障、边界故障等。但是，操作可能是相似的，它们的测试需求的集合将交迭，面向对象设计得越好，交造就越大，仅仅需要对那些不能被base：：redefined（）测试满足的  derived：：redefined（）的需求来导出新测试。

       小结一下，base：：redefined（）测试被应用于类derived的对象，测试输人可能同时

适合于base和derived类，但是，期望的结果可能在derived类中有所不同。

       6．基于场景的测试设计

       郑州apple软件开发认为基于故障的测试忽略了两种主要的错误类型：①不正确的规约。②子系统间的交互。当和不正确的规约关联的错误发生时，产品不做客户希望的事情，它可能做错误的事情，或它可能省略了重要的功能。在任一情形下，质量（对要求的符合度）均受到影响。当一个子系统建立环境（如事件、数据流）的行为使得另一个子系统失败时，发生和子系统交互相关联的错误。

       基于场景的测试关心用户做什么而不是产品做什么。它意味着捕获用户必须完成的任务（通过用例），然后应用它们或它们的变体作为测试。

       场景揭示交互错误，为了达到此目标，测试用例必须比基于故障的测试更复杂和更现实。基于场景的测试往往在单个测试中处理多个子系统（用户并不限制他们自己一次只用一个子系统）。

       例如，考虑对文本编辑器的基于场景的测试的设计，下面是用例。

       用例：确定最终草稿。

       背景：打印“最终”草稿、阅读它并发现某些从屏幕上看时不明显的恼人错误是常见的。该用例描述当此事发生时产生事件的序列。

       （1）打印完整的文档。

       （2）在文档中移动，修改某些页面。

       （3）当每页被修改后，打印它。

       （4）有时打印一系列页面。

       郑州ios开发认为该场景描述了两件事：测试和特定的用户需要。用户需要是明显的：①打印单页的方法。②打印一组页面的方法。当测试进行时，有需要在打印后测试编辑（以及相反）。测试人员希望发现打印功能导致了编辑功能的错误，即此两个软件功能不是合适的相互独立的。

       用例：打印新复制件。

       背景：某人向用户要求文档的一份新复制件，它必须被打印。

       （1）打开文档。

       （2）打印文档。

       （3）关闭文档。

       测试方法也是相当明显的，除非该文档未在任何地方出现过，它是在早期的任务中创建的，该任务对现在的任务有影响吗？

       在很多现代的编辑器中，文档记住它们上一次被如何打印，默认情况下，它们下一次用相同的方式打印。在“确定最终草稿”场景之后，仅仅在菜单中选择“打印”命令并在对话框中单击“打印”按钮，将使得上次修正的页面再打印一次，这样，按照编辑器，正确的场景应该如下。

       用例：打印新复制件。

       （1）打开文档。

       （2）选择菜单中的“打印”命令。

       （3）检查是否将打印一系列页面，如果是，点击以打印完整的文档。

       （4）单击“打印”按钮。

       （5）关闭文档。

       但是，这个场景指明了一个潜在的规约错误，编辑器没有做用户希望它做的事。客户经常忽略在第（3）步中的检查，当他们走到打印机前发现只有一页，而他们需要100页时，他们将是烦恼的。烦恼的客户会指出这一规约错误。

       测试用例的设计者可能在测试设计中忽略这种依赖，但是，有可能在测试中问题会出现，测试员则将必须克服可能的反应，“这就是它工作的方式”。

       7．测试表层结构和深层结构

       郑州苹果软件开发认为表层结构指面向对象程序的外部可观察的结构，即对终端用户立即可见的结构。不是处理函数，而是很多面向对象系统的用户可能被给定一些以某种方式操纵的对象。但是不管接口是什么，测试仍然基于用户任务进行。捕获这些任务涉及理解、观察以及和代表性用户（以及很多值得考虑的非代表性用户）的交谈。

       在细节上一定存在某些差异。例如，在传统的具有面向命令的界面的系统中，用户可能使用所有命令的列表作为检查表。如果不存在执行某命令的测试场景，测试可能忽略某些用户任务（或具有无用命令的界面）。在基于对象的界面中，测试人员可能使用所有的对象列表作为检查表。

       当设计者以一种新的或非传统的方式来看待系统时，则可以得到最好的测试。例如，如果系统或产品具有基于命令的界面，则当测试用例设计者假设操作是独立于对象的，将可以得到更彻底的测试。提出这样的问题：“当使用打印机工作时，用户有可能希望使用该操作（它仅应用于扫描仪对象）吗？”不管界面风格是什么，针对表层结构的测试用例设计应该同时使用对象和操作作为导向被忽视任务的线索。

       深层结构指面向对象程序的内部技术细节，即通过检查设计和／或代码而理解的结构。深层结构测试被设计用以测试作为面向对象系统的子系统和对象设计的一部分而建立的依赖、行为和通信机制。

       分析和设计模型被用作深层结构测试的基础。例如，对象一关系图或子系统协作图描述了在对象和子系统间的可能对外不可见的协作。那么测试用例设计者会问：一我们已经捕获了某些测试任务，它测试在对象一关系图或子系统协作图中记录的协作？如果没有，为什么？”

       类层次的设计表示提供了对继承结构的误人洞察，继承结构被用在基于故障的测试中。考虑如下情形：一个命名为。aller的操作只有一个参数，并且该参数是到某基类的引用。当。aller被传递给派生类时将发生什么事情？可能影响。aller的行为有什么差异？对这些问题的回答可能导向特殊测试的设计。

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