海盗派测试分析3 建模

测试时要基于上下文的。

《Essential Software Test Design》《A Practitioner's Guide to Software Test Design》

1.~确定测试对象；确定单功能的边界；单功能拆分；。

判定表中做的是测试分析，得到的是测试场景，而不是具体的可以直接运行的测试实例，过早的把问题具体化有可能会丢失一些关键的场景 。

测试条件代表了要对单功能进行测试的一些基本测试场景。

不要一味的追求测试的高覆盖率。

2.测试场景描述   Given-When-Then来自Gerard Meszaros<xUnit Test Patterns:Refactoring Test Code>

Given-----给定被测对象所处的预制状态（预置条件）

每个测 试场景都是在一个预置的状态下发生的，这可能包括被测系统当前的状态，与被测系统相关的另外一个系统的状态等。从某种程度上来说，这些预置的状态也是测试时隐含的输入。

When-----当执行某个操作时（动作）

用户/模块/系统执行了某个操作，或者向某个函数传入一个指定的参数，这些就是某个测试场景的主要的，显式的输入，表明被测对象在某个特定条件下，收到了一个外在的“鼓励”。

Then----发生了什么（后置条件）

被测对象在这个“鼓励”下的反应，比如返回一个值，执行一个动作，抛出一个异常等。同时不要忘记此时被测系统的状态是否有变化，这些都是测试中要仔细观察的内容。

识别测试条件的目的就是为了覆盖测试用例模型，Model不同，识别测试条件的方法也不同。

覆盖等价类的方式：一是设计足够多的的用例，确保每一个有效等价类和无效等价类都被覆盖就可以了。另一种是根据引起缺陷的故障因子个数以及是否覆盖无效等价类进行区分。

考虑的因素	可能的取值	表示符号	等价类覆盖方式
			Weak Normal	Strong Normal	Weak Robust	Strong Robust
引起缺陷的故障因子个数	单因子故障假设（Single Fault Assumption）	Weak	★		★
	多因子故障假设（Multiple Fault Assumption）	Strong