其实我本身没有负责这个项目的测试，不过是不想闲着所以拿这个做做玩玩：）有这样一个弹出窗口，上面有很多CheckBox，我只选了其中的7个作为例子的测试对象，意在举例子。

下表提取出需要测试的7个对象，他们分别有两种状态，要么被选中没有没有被选中：

然后根据正交表进行映射，可以得到如下表，这个表有一部分是空的，那是因为用这8个case表示的两两组合已经是符合正交表的最低要求，就是两两组合至少出现一次，所以有这样子的空位出现

在处理这些空的数据格的时候我们可以根据一条原则进行处理，就是对那些敏感的区域或者是你觉得出现bug机会比较大的情况进行检验。例如下表，我假定Quartiles是选中的状态下有可能出现bug，所以我把这4个空全部填上了YES。对于后面那两个字段也是采用了同样的处理方法。就得出了下面这个表。

对于有7个字段，每个字段有2种可能的数值的情况，如果要做一个全面的测试，就需要2的7次方 128个Test Case来做一个全面的覆盖，但是如果加上其他字段，或者某些字段的可选值是很多的（例如一个Text Box，用等价类划分了以后可能也有4~5种）。做一个全面的测试是不可能的。现在用8个测试用例来替代原来128个的方案，虽然肯定不能保证做到发现全部的bug，不过我个人觉得是一个“性价比”比较高的方案。

当然了，我们不能完全依靠正交表，如果不是我们本身的价值哪里去了，其实观察一下上面的表，很容易地发现了上面的表是没有全部NO的Test Case的，所以我们可以根据自己的经验，认为全部都不选的情况是一个比较常见而且有肯能出错的情况，所以加上，然后还能加上一些在软件实际使用过程当中比较常用的组合还有容易出错的组合，来完成这个Test Case计划。见下表，红色的就是后来加上去的。

这样子我就完成了一个10个Case的测试计划了。

回过头来看看正交矩阵测试策略Orthogonal Array Testing Strategy (OATS)，OATS是一种对两两相互作用(pair-wise interactions)进行系统的测试的一种方法，用正交表映射出来的测试用例大致上是均匀分布的。
正交矩阵(Orthogonal arrays)是一二维的矩阵，下面是一些关键字：

• Runs：就是矩阵的行数，也就是将来要映射的Test Case数。在这里例子里面是8。
• Factors：就是矩阵的列数，一般来说是有多少个变量，就有多少个Factor。这里例子就是7。
• Levels：就是取各列因素(Factors)中的最大可能取值。这个例子里面是2。
• Strength：相互关系数，这里面是2，意思就是每两个变量之间的关系，如果是3的话就意味着需要三个变量之间的组合，如果是这样的情况用例数会极速增加。

正交表通常的表达式是：

根据上面的数据可以查找到一些已经被证明是正确的正交表。可以参考这个地址：http://www.research.att.com/~njas/oadir/index.html

然后就能把正交表的01010101映射为我们的Case了！

后记：
1.为什么强调这个正交表是均匀分布的呢？从几何学角度来看软件的bug的话，bug可以分为两类，一种是范围性的错误(region faults)另外一种是单独的错误(Single faults)。我们很难去估计在这个软件里面哪类错误存在于哪里，所以我们能做的就是取一个有限的集合去代替那个无限的集合。正因为如此，我们对这个有限的集合的要求就是尽可能地均匀分布的。

2.不要手工的实现正交表的映射。现在一般举例都是比较小规模的例子，一旦列变量很多很多，那就没有办法手工的去做映射的，需要借助工具~听说Excel可以做，我也正在研究，不过可以有其他选项~例如有个叫正交助手的软件，或者用SPSS……有点夸张。

3.滥用OATS。通常刚开始知道这个方法的时候就很有兴趣去弄他，然后就死也要实现这个方法，不过测试还是根据风险来决定测试的点。如果发现一个能应用OATS的地方，不过这个地方在整个软件里面占的比重并不是很大，或者说不是有很高优先级的，那么可以不用OATS。

4.用错了组合，其实就像是我举的这个例子，其实我没有读文档，也没有文档给我读，所以我并不知道那个界面上哪些东西是互相有影响的，所以我也只是随便挑出来罢了。做个例子可以，真正实施的时候要注意囖。

5.不要用OATS来测那些高风险的产品，例如什么医疗，银行的。

6.正交表只是取一个相对合理的集合作为全集合的一个代替，所以不要认为利用正交表就能替代原来的全集，用正交表是要承受风险的，但是正交表的确是一个“性价比”很高的方法：）有点像20/80法则，做20%的工作就得到了80%的效果：）

Related posts:

1. 《Software Testing》第十八章 – 编写和跟踪测试用例

动态黑盒测试(Dynamic Black-Box Testing)

也有叫行为测试(behavīoral Testing)，功能测试(Functional Testing)。现在可能国内很多单位就真的是一个瞎子来测试软件，不是说那个测试人员是瞎子，是老板让他们变成了瞎子，为什么呢？因为可能大多数都缺少文档，我们需要的是软件的需求文档-Requirements Document（需求文档）或者是 Product Specification（产品说明书）。

测试用例(Test Case)。

Test cases are the specific inputs that you’ll try and the procedures that you’ll follow when you test the software.我的理解，测试用例就是一组根据相应文档而设计出来的操作步骤，输入数据和输出结果，是对软件产品的进行测试的执行过程。

这章还提到了一个概念–Exploratory Testing（探索性测试）。

他的定义是：simultaneously learning the software, designing tests, and executing those tests.意思是同时进行对软件的学习，设计测试用例和执行测试用例这3种活动。我记得对于Exploratory Testing有一个很关键的步骤，就是把在测试活动过程中开发出来的测试用例记录下来，以便以后做回归测试。还有对测试用例进行维护。我觉得这个把测试用例写下来是很重要的，在这种瞎测的过程中，大家的思维肯定是很随机的，或许明天上班我们对同样的软件进行测试就有完全不同的方法，对于有用的正确的方法应该记录下来。

Test-to-Pass and Test to Fail

这个英文里面也叫Positive Testing and Negative Testing.正向测试和反向测试。前者是证明软件是能正常工作的，后者主要是为了证明软件在接受到一些预期不到的输入的时候能够有一个合理的相应。例如我们在计算器里面输入英文字母不会让系统死机。一般来说我们应该先执行Positive Testing然后再执行Negative Testing。不过这里在实际操作中会遇到有一个问题，这两种测试用例都是对同样的测试对象进行测试，如果先执行Positive Testing然后再执行Negative Testing的话就有可能增加了测试的时间。

Equivalence Partitioning

等价类划分，也叫Equivalence Classing。等价类划分可以在测试质量得到保证的同时大大减少测试用例的数量。等价类的定义是：An equivalence class or equivalence partition is a set of test cases that tests the same thing or reveals the same bug.例如可以把输入分为有效输入和无效输入，在有无效输入里面也可以有好几种细分。总之我觉得想等价类划分是一个不断细化的过程，并不是粗略地分为有效无效就万事大吉了。书中最后说到一个有趣的事情。A final point about equivalence partitioning is that it can be subjective. It’s science but it’s also art.如果说一样东西即时科学又是艺术，就证明他不是科学的，跟个人能力有很大关系啊。

Data Testing

这个我以前真的没听说过，而且网上的资料也比较少，直接翻译应该是数据测试。一种对软件的简单看法就是：软件由两部分组成：The data and the program。Data（数据）的定义。数据可以是键盘的输入，鼠标的点击，磁盘文件，打印输出等等。程序：就是可执行的流，事务，逻辑和计算。

Boundary conditions

边界条件。原文是这样说的:If software can operate on the edge of its capabilities, it will almost certainly operate well under normal conditions.如果我们在悬崖边走过而边缘上的岩石没有塌掉的话，那么我们就可以认为在远离悬崖边的地方走路是很安全的~~边界条件通常会跟等价类划分一起使用。

以下是有可能涉及到边界条件的类型：

数字，字符，位置，数量，速度，区域，大小

我们可以想一下一下的情况：

第一个/最后一个；最大/最小；开始/结束；之上/之下；空的/满的；最慢的/最快的；最大的/最小的；最短的/最长的；最先的/最后的；最高的/最低的。

这里有一个TIPS就是。当我们考虑边界条件的时候，需要考虑以下三种情况。
第一：合法数据范围里面的其中一个取值。
第二：最后一个合法数据（刚好在合法数据集合的边界上的值）取值。
第三：邻近与最后一个合法数据的非法数据数值。举例~~如果一个Text Box允许输入最大的字符数是20个，那么就可以选19，20，21，刚好符合以上条件。（这个举例只针对最大值20哦）

次边界条件(sub-boundary conditions)

或者叫内部边界条件(internal boundary conditions)。这部分内容要求测试人员要对计算机和软件怎么运行，有一个基本的了解。这些次边界通常会来自于：ASCII码所引起的问题，因为ASCII码并不是一个连续的编码，大家可以发现大写字母和小写字母在ASCII码里面并不是连续的，这里面有可能出现问题，再有就是一些单位，例如Byte，word等等。

状态测试(State Testing)

一个软件的状态的定义是：软件在某一时刻所处于的一种状态或者模式。作为一个测试员，我们必须对程序的状态和事务的转换进行测试。测试一个软件的逻辑流程应该首先画出一个状态转换图。这个状态转换图应该包括三个方面。
1.软件的每一个可能的状态。
2.触发软件的状态转换的输入和条件。
3.进入和退出某种状态的条件设置及其产生的输出。

由于状态的转换路径也是一个不可能全部测试的集合，所以需要对这个集合进行瘦身。有5种方法可以做到。
1.每个状态至少访问一次
2.测试那些看起来是很普遍或者是很常用的状态转换
3.对那些最不常用的状态切换进行测试
4.测试所有的错误状态和从错误状态切换回来的状态
5.测试随机的事务

Testing States to Fail

反向状态测试。竞争条件(Race conditions)是需要包括的。这个很多地方都讲了，我省一点字，呵呵。

• Repetition Testing（重复测试）就是不断执行同样的操作。最简单的是不停地启动、关闭程序。这个测试有可能可以发现内存泄露，不过像这样子的测试当然最好是留给自动化工具去完成啦~呵呵。
• Stress Testing（压力测试）书上的定义是把软件置于比理想状态要差的条件中运行。也有点像是边界条件，这里的边界就是软件的运行平台条件。
• Load Testing（负载测试）跟压力测试相反，我们需要做的是让软件满负荷地运作

这里关于压力测试和负载测试的定义我自己也不太确定书上说的是不是真的完全正确，因为类似的定义在网上论坛也不是一个很明确的定义，以后查资料补上吧：）

其他黑盒测试技术

其中有一条是：像一个傻瓜一样去使用软件。的确，软件到了用户的手里以后，没有人可以预计用户会如何使用这些软件~还有就是在已经发现BUG的模块上继续努力~呵呵，物以类聚嘛：）再有就是像一个黑客那样思考，这个对测试员的要求比较高哦，最后一条就是！哈哈~根据自己的经验，直觉，感觉……大家跟着感觉走囖。

Related posts:

1. 测试工程师需要懂编程么？
2. 《Software Testing》第二十一章 – 软件质量保证
3. 《Software Testing》第十八章 – 编写和跟踪测试用例

这个评审分为两个部分，第一部分是对说明书的概要评审。有三点是要做到的：
1.以用户的角度去看问题。可以先找软件的最终用户去谈谈，了解一下他们的习惯什么的，我觉得这里说的最终用户是End User而不是Customer。在这章里面我觉得比较精辟的句子就是：The definition of QUALITY means “meeting the customer’s needs”。
2.研究现有的标准和指南。不要做出来的软件是标新立异的，有时候个性是好，不过过分的个性通常不会有好的下场啊。
3.对类似的软件进行评审和测试。有句话说的很好，“你想不到的你的敌人会告诉你”。去看一下竞争对手的产品。 

第二部分讲的是对说明书的详细测试，书里面列举了两个Checklist

1.关于说明书本身的属性。

• Complete–说明书上有没有漏掉什么东西
• Accurate–正确性，对产品的定义是否是正确的呢
• Precise, Unambiguous, and Clear–描述要清晰，不要出现模棱两可的描述
• Consistent–要一致，不要前后矛盾或者跟其他相关文档矛盾
• Relevant–相关性，（其实我还不太能完全理解）
• Feasible–是否可行，如果说用手机来看HDTV，可以不，也许可以，不过不是现在。
• Code-free–不要在说明书里面出现代码算法什么的，客户不会关心我们怎么实现。
• Testable–是可测试的。

2.关于说明书的一些术语。

• Always, Every, All, None, Never–对于这些肯定的用语，一定要检查清楚看究竟所描述的相关部分是否真的100%肯定。
• Certainly, Therefore, Clearly, Obviously, Evidently–这些带有假设性的词语也是需要注意的，别跳坑了。
• Some, Sometimes, Often, Usually, Ordinarily, Customarily, Most, Mostly–这个跟上面提到的Precise,
• Unambiguous是一致的，不要出现模棱两可的定义，例如这个系统大多数情况下是不会死机的。
• Etc., And So Forth, And So On, Such As–出现这些词语都是有问题的，违背了Testable这个准则。因为这样的列表是没完没了的列表。
• Good, Fast, Cheap, Efficient, Small, Stable–出现这些词语也是违背了Testable原则。快？对于每个人来说都有不同的定义，“系统启动的很快”。有的人觉得5秒启动就是快的，有人可能觉得10分钟也是快的哦，谁知道呢。呵呵。
• Handled, Processed, Rejected, Skipped, Eliminated–通常这都会隐含了很多功能，而这些功能却没有被详细地指出来。
• If…Then…(but missing Else)。有IF就必须要有ELSE！

No related posts.