利用OATS技术来设计Test Case

http://blog.sina.com.cn/s/blog_48fc02b90100037j.html

  我本身的工作是QA（Quality Assurance），是在软件公司的研发中心工作，QA工作简单来说就是测试工作，通过各种各样的测试来对软件的质量进行保证，因此呢工作内容的很大一部分就是设计Test Case，但是看过《计算机软件测试》这本书并且对软件测试有一些经验的人都知道，不可能能让测试完全覆盖各个方方面面，就算能够都覆盖到，也没有那么多资源来实施这些测试工作。
    当然，这里不是讲这些理论，这些道理测试人员都知道，我今天要讲的是如何利用OATS（Orthogonal Array Testing Strategy）技术来设计Test Case，这种技术特别适合对于软件的某一个Function和系统的某一个Subcomponent设计Test Case，并且它可以做到半自动化，能够帮助我们QA设计很大一部分的Test Case，而且能够比较充分的从理论上保证Case执行的覆盖率。
    什么叫Orthogonal Array，就是正交表了，其实利用正交表技术来选择测试样本的方法已经得到了很大的应用了，简单说来就是这样一种情况，有N个变量，每个变量又可以取不同的值，假设都是M个，假如你要穷举了测试，就得有M*M*...M（N个M）的测试样本集，要全部执行简直不可想象，这个时候需要选出一些比较有代表性的来测试，怎么样选择呢，就是利用正交表的原理，如果N个变量每个都有M个取值，那这个正交表就是Single Level的，如果有些变量可以有不同个取值，那就是Multi Level的，我们这里不讲述具体为什么OATS技术能够帮我们比较好的选择测试样本集，我们具体讲述的是如果利用这项技术，关于该技术的详细介绍，请参考：
OATS Technique

    好了，现在进入正题，利用这个技术可大致分为如下几个步骤：

1、选择测试变量
    这里选择测试变量，就是说针对我们要测试的Function和Subcomponent，我们把它的每一个测试点都给选出来，比如你测试字符的显示，字符的大小可能是一个测试点，字符的字体也可能是另一个测试点，等等，就是这些可以变的参数，当然了，你要选出很多很多参数也有可能，怎么掌握这个粒度可以根据经验阿什么的，也可以根据该模块的测试优先级，甚至有可能跟Schedule有关，这些事情做完了之后，剩下的无非就是考虑怎么组合这些测试点了，这个时候可以利用两个原则：
1）等价类原则
2）边界值原则
    利用这两个原则可以针对每一个测试变量选择出比较有代表性的几个值，比如一个文本框按照设计可以接收0 － 99之间的数，你可以取－1， 0， 99， 100， aa等。
    这一步做完了之后，我们现在的到的是我们要测试的模块的各个可变参数以及它们的一些有代表性的取值。

2、利用OATS技术选择测试样本集
    这一步就是利用我们前面所论述的OATS技术，从总的测试样本集中选出一个比较有代表性的子集，通常子集的数目要远远少于全集，且能比较充分的保证覆盖率。

3、Test Case分类
    上一步完了之后，我们虽然得到了一个测试子集，但是有可能这个子集还是很大，也有可能我们没有主次，这个时候我们需要从里面跳出一些来，作为RAT、TOFT、FET类型的Test Case，一个简单的原则就是：
1）RAT － Release Acceptance Test，如果取值都是比较正常的值，我们不妨作为RAT Case的取值，比如上面说的文本框，取0，99比较有可能是RAT的Case。
2）TOFT － Task Oriented Function Test，虽然取值可能不太正常，但是这些用户可能比较经常的遇到，不妨作为TOFT Case的取值，依然说文本框的Case，－1，99，100等都有可能是TOFT的Case。
3）FET － Force Error Test，有些平常不大可能的取值，但是我们要保证它不出错，可以作为FET Case的取值，如文本框取值的aa等。
    这一步做完了之后，我们就从OATS技术得出来的子集里面又挑出了RAT、TOFT、FET的Case。

4、Test Case优先级划分
    最后一步就是针对RAT、FET、TOFT的case，我们可以根据一些简单的原则来划分Test Case执行的优先级，这些原则可以是测试值出现概率，经验，等。

    上述除了第1个步骤之外，后面的3个步骤我们可以借用计算机程序来帮我们自动化，这样我们在设计Test Case时的精力就可以放到怎么选择边界值这些问题上了，就不用考虑他们的组合了，以我的经验来看，我们设计Test Case时很大的精力都是放在考虑组合上面了，人工的考虑虽然可以根据经验，但是没有一个可以遵循的原则还是比较痛苦的事情。
    最后说一点，软件工程里面没有银弹，就是说没有万能药，我这篇文章里面所讲述的方法不是万能的，它可以帮助我们设计一部分的Test Case，但是绝不能设计所有的Test Case，因为有很多情况是我们事先所考虑不到的，我的目的只是希望它作为我们QA设计Test Case手段的一种补充吧，也就是说，希望QA的理论能够和实际更加结合一些，更加具有可操作性一些。

BTW：利用OATS技术设计Test Case的方法我目前已经开始使用了，我现在设计了一个程序可以自动帮我生成Test Case，效果还不错，也马上会share给公司的Test Group，

其他的参考资料：http://blog.codylab.com/testcase-categorization/