无效等价类，往往是根据测试数据来设定的，也是说由测试数据决定了是否是无效等价类。例如，当我们测试ATM取款交易的时候，无效等价类会有：1）错误的卡；2）黑名单卡；3）不插卡；4）没有磁条/错误磁条的卡；5）非法的金额；6）超限的金额；7）金额为0；8）余额不足的卡；9）不支持卡的种类……等非常多。
      对无效等价类测试，大的问题在于：1）无效等价类的情况繁多，难以穷举；2）需要测试系统在错误数据下的反应，特别是对错误提示信息的获取；3）对于自动测试，每个无效等价类对应的测试用例都需要一个专门的测试脚本，成本过高。

      我们的第一个问题是，如何设计比较全面的无效等价类测试用例，覆盖到各种情况？第二个问题是，如何通过自动化测试的方法来解决无效等价类自动测试的问题？

      先看第一个问题。很多测试，大概可以划分成为三个层次：
      第一层，产品/对象。面向产品的测试，根据产品的属性来划分功能和流程，也决定了哪些产品具备哪些流程。
      第二层，场景。根据产品的活动来设计测试场景。
      第三层，测试用例。根据产品的场景来设计测试用例。

      针对无效等价类设计，也遵守三个层次来考虑：
      第一层，产品/对象。面向产品的测试，设定一些无效等价类数据；
      第二层，场景。根据产品的活动来设计场景，不考虑是否无效等价类测试，对于测试数据，我们把每个测试的输入数据项，划分成为无效等价类的测试数据和有效等价类的测试数据。
      第三层，测试用例，根据场景来生成。在生成测试用例的过程中，如果我们发现它包含一个无效等价类的测试数据，那么包含这个无效等价类测试数据之后的组件（测试脚本），都不需要再继续执行。因为我们认为，当执行一个无效等价类，它会出现错误，主要是同步错误。当出现错误之后，之后的组件/脚本不需要再执行。
      对于无效等价类测试用例，我们给他们一个分类：无效等价类测试类型。当这个测试用例被执行：1）对于手工执行，出现错误，需要测试工程师来判断，它是成功还是失败；2）对于自动测试执行，出现错误，会纪录到测试日志，并且给出一个状态“warning/警告”，需要测试分析人员查看日志来确定它是否成功。如果是自动测试未发现错误，一般情况下会认为测试用例执行失败。

      根据以上的方法，我们解决了：1）无效等价类测试用例设计的问题。从产品出发，对数据进行划分；从场景出发，能够覆盖到各种情况；2）自动测试无效等价类的问题。在设计测试用例的时候，如果这个测试用例包括了无效等价类的数据，那么在生成测试用例的时候，包括了无效等价类之后的组件，都不需要再生成，会简化测试用例；同时，在生成无效等价类测试用例的时候，对同一个无效等价类测试数据，只需要生成一个测试用例，无需生成多个无效等价类测试数据。

      通过 “测试用例设计方法（测试用例自动生成） + 测试用例自动执行 + 人工确认测试结果”的方法，我们很好的解决了无效等价类自动测试的问题和无效等价类测试设计的问题。

      版权声明：泽众软件原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任(http://www.spasvo.com/news/html/20101021101235.html)。