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

       郑州软件公司认为面向对象软件的测试用例设计方法还正处于成型期，然而，已经有一些对面向对象测试用例设计的方法建议。

       （1）每个测试用例应该被唯一标识，并且和将被测试的类显式地相关联。

       （2）应该陈述测试的目的。

       （3）对每个测试应该开发一组测试步骤，应该包含以下几个方面。

       ①将被测试的对象的一组特定状态。
 

       ②将作为测试的结果使用的一组消息和操作。
 

       ③当测试对象时可能产生的一组例外。
 

       ④一组外部条件（即为了适当地进行测试而必须存在的软件的外部环境的变化）。
 

       ⑤辅助理解或实现测试的补充信息。

       1．面向对象概念的测试用例设计的含义

       如我们已经看到的，面向对象类是测试用例设计的目标。因为属性和操作是被封装的，对类之外操作的测试通常是徒劳的。虽然封装是面向对象的本质设计概念，但是它可能会成为测试的小障碍。测试需要对对象的具体和抽象状态的报告，然而，封装却使得这些信息在某种程度上难于获得。除非提供了内置操作来报告类属性的值，否则，对对象的状态快照是难以获得的。

       郑州苹果软件开发认为继承也造成了对测试用例设计者的挑战。我们已知道，即使是彻底复用的，对每个新的使用语境也需要重测试。此外，多重继承增加了需要测试的语境数量从而使测试进一步复杂化。如果从超类导出的子类被用于相同的问题域，有可能对超类导出的测试用例集可以用于子类的测试，然而，如果子类被用于完全不同的语境，则超类的测试用例将没有多大用处，必须设计新的测试用例集。

       2．传统测试用例设计方法的可用性

       在前面章节描述的白盒测试方法可用于对为类定义的操作的测试，基本路径、循环测试或数据流技术可以帮助保证已经测试了操作中的每一条语句，然而，很多类操作的简洁结构导致某些人认为：将用于白盒测试的工作量用于类级别的测试可能会更好。

       黑盒测试方法就像对传统软件工程方法开发的系统和对面向对象系统同样适用的，如在本章前面看到的，用例可以为黑盒及基于状态的测试的设计提供有用的输人。

       和传统测试用例设计不同，传统测试是由软件的输人一加工一输出视图或个体模块的算法细节驱动的，面向对象测试关注于设计合适的操作序列以测试类的状态。

       测试用例目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

       郑州android开发认为不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。笔者主要从事企业管理软件的测试。因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。

       要使最终用户对软件感到满意，最有力的举措就是对最终用户的期望加以明确阐述，以便对这些期望进行核实并确认其有效性。测试用例反映了要核实的需求。然而，核实这些需求可能通过不同的方式并由不同的测试人员来实施。例如，执行软件以便验证它的功能和性能，这项操作可能由某个测试人员采用自动测试技术来实现；而市场占有率和销售数据（以及产品需求），只能通过评测产品和竞争销售数据来完成。

       确定测试用例之所以很重要，原因有以下几方面。

       （1）测试用例构成了设计和制订测试过程的基础。

       （2）测试的“深度”与测试用例的数量成比例。由于每个测试用例反映不同的场景、条件或经由产品的事件流，因而，随着测试用例数量的增加，您对产品质量和测试流程也就越有信心。

       （3）判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这又是以确定、实施和／或执行的测试用例的数量为依据的。类似“95％的关键测试用例已得以执行和验证”的说明，远比“我们已完成95％的测试”更有意义。

       （4）测试工作量与测试用例的数量成比例。根据全面且细化的测试用例，可以更准确地估计测试周期各连续阶段的时间安排。

       （5）测试设计和开发的类型以及所需的资源主要都受控于测试用例。

       （6）测试用例通常根据它们所关联关系的测试类型或测试需求来分类，而且将随类型和需求进行相应的改变。最佳方案是为每个测试需求至少编制两个测试用例：一个测试用例用于证明该需求已经满足，通常称为正面测试用例；另一个测试用例反映某个无法接受、反常或意外的条件或数据，用于论证只有在所需条件下才能够满足该需求，这个测试用例称为负面测试用例。

       3．基于故障的测试

       郑州安卓软件开发认为在面向对象系统中基于故障的测试的目标是设计最有可能发现似乎可能的故障的测试。因为产品或系统必须符合客户需求，因此，完成基于故障的测试所需的初步计划是从分析模型开始的。

       测试人员查找似乎可能的故障（即系统实现中有可能产生错误的方面），为了确定是否存在这些故障，设计测试用例以测试设计或代码。

       考虑一个简单的例子。软件工程师经常在问题的边界处犯错误，例如，当测试SQRT操作（该操作对负数返回错误）时，尝试边界一个靠近零的负数和零本身，“零本身”用于检查是否程序员犯了如下错误：
 

       if（x＞0）calculate the square root（）；

       而不是正确的：

       if（x＞＝0）calculatethe square root（）；

       作为另一个例子，考虑布尔表达式：

       if（a＆＆bll）
 

       多条件测试和相关的用于探查在该表达式中可能存在的故障的技术，如：“＆＆”应该是“&’，“！”在需要处被省去，应该有括号包围“！bll”。

       对每个可能的故障，设计迫使不正确的表达式失败的测试用例。在上面的表达式中，（a—0，b—0，c—0）将使得表达式得到预估的“假”值，如果“＆＆”已改为“11”，则该代码做了错误的事情，有可能分叉到错误的路径。

       当然，这些技术的有效性依赖于测试人员如何感觉“似乎可能的故障”，如果面向对象系统中的真实故障被感觉为“难以置信的”，则本方法实质上不比任何随机测试技术好。然而，如果分析和设计模型可以提供对什么可能出错的深入洞察，则基于故障的测试可以以相当低的工作量花费来发现大量的错误。

       集成测试在消息连接中查找似乎可能的故障，在此语境下，会遇到3种类型的故障：未期望的结果、错误的操作／消息使用、不正确的调用。为了在函数（操作）调用时确定似乎可能的故障，必须检查操作的行为。

       集成测试，对象的“行为”通过其属性被赋予的值而定义，测试应该检查属性以确定

是否对对象行为的不同类型产生合适的值。

       应该注意，集成测试试图在客户对象而不是服务器对象中发现错误，用传统的术语来说，集成测试的关注点是确定调用代码中是否存在错误，而不是被调用代码中。用调用操作作为线索，这是发现实施调用代码的测试需求的一种方式。

       4．面向对象编程对测试的影响

       面向对象编程可能对测试有几种方式的影响，依赖于O（）P的方法。

       （1）某些类型的故障变得几乎不可能（不值得去测试）。

       （2）某些类型的故障变得更加可能（值得进行测试）。

       （3）出现某些新的故障类型。

       郑州ios开发认为当调用一个操作时，可能很难确切知道执行什么代码，即操作可能属于很多类之一。同样，也很难确定准确的参数类型／类，当代码访问参数时，可能得到一个未期望的值。

       可以通过考虑如下的传统的函数调用来理解这种差异。

       x＝func（y）；

       对传统软件，测试人员需要考虑所有属于func的行为，其他则不需考虑。在面向对象语境中，测试人员必须考虑 base：：func（）、of derived：：func（）等行为。每次 func被调用，测试人员必须考虑所有不同行为的集合，如果遵循了好的面向对象设计习惯并且限制了在超类和子类（用C++的术语，称为基类和派生类）间的差异，则这是较为容易的。对基类和派生类的测试方法实质上是相同的。

       测试面向对象的类操作类似于测试一段代码，它设置函数参数，然后调用该函数。继承是一种方便的生成多态操作的方式，在调用点，关心的不是继承，而是多态。继承确实使得对测试需求的搜索更为直接。

       由于面向对象系统的体系结构和构造，是否某些类型的故障更加可能，而其他类型的故障则几乎不可能？对面向对象系统而言，回答是“是”。例如，因为面向对象操作通常是较小的，往往存在更多的集成工作和更多的集成故障的机会，集成故障变得更加可能。

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