应用程序和其运行环境进行交互和接收到的所有输入导致软件状态发生变化。软件接收到输入，并在内部存储这些输入值之后，软件状态就会发生变化。测试人员就是要测试这些状态变化的情况。测试软件是否正确更新了它自身的当前状态？测试应用程序的当前状态是否会导致接收某些输入时发生故障？测试软件是不是进入了一些它不应该进入的状态？下面让我们来看看测试输入和状态变化时要考虑的一些主要因素。

软件可以接受的输入是无限的。我们已经提过输入变量、输入值的组合和输入值的顺序，它们都让测试变得愈加困难。然而，这里出现的一个新的维度--软件状态，让测试人员的日子更加难过。软件状态的复杂性在于它自身可以牢记已经处理过的输入，还牢记从前发生过的状态叠加效果。从某种意义上来说，软件状态保持了一个输入的历史记录，因为软件可以记住前一次用户使用软件时做了哪些事情。

因为软件状态改变源于连续不断的输入，所以测试它就需要使用多个测试用例，并需要持续不断地运行软件，中止运行，再运行软件。如果测试人员花时间去观察输入是如何影响系统运行的，就可以注意到软件状态的这些变化。如果输入某些值后，发现这些值被显示出来，就说明这些值在软件内部被存储起来，并已经成为应用程序当前状态的一部分了。如果软件接收输入后进行了计算操作，而且该计算过程可以被多次重复，这也说明该输入值在软件内部被存储起来了。

软件状态可以看成是用于描述软件记住过去发生的所有输入和输出的一种方式。状态可以是临时的(temporary)，就是说它在当前运行中会被程序记住，但当程序终止时，该状态就被忘却了。它也可以长期保存(persistent)，它可以被存储在一个数据库里或一个文件内，程序将来再运行时可以存取这个值。这两种情况一般被称为数据辖域(scope of data)，检验软件是否正确地实现了数据辖域也是一个很重要的测试 。

很多临时或被长期保持的数据并不能被直接观测到，必须通过它们对软件行为的影响来推测它们的值。如果同一个输入会导致软件作出两种完全不同的反应，这说明这两种情况下软件的状态完全不同。这里我拿控制电话交换机的软件来举例说明，如果当前输入是“接电话”的动作(就是提起电话线一端的话筒，或者是按下手机上的接听键)，那么根据软件当前状况的不同会导致几个完全不同的结果。

如果电话连接的电话网没有开通，电话就不会有什么反应，或者会发出一个表示出错的回应。

如果当前电话没有在振铃，电话就会发出一个拨号音(如果使用的是电话线)或者是显示一个最近拨打的电话号码列表以供重拨(如果使用的是手机)。

如果当前电话正在振铃，电话就被接通，用户可以和拨打该号码的人进行通话。

这里的状态就是电话网的状况(是否开通)和电话机的状况(是否正在振铃)。这些值和我们使用的输入值(接电话的动作)结合起来，决定了会产生什么样的回应或者产生什么样的输出。测试人员要根据自己拥有的时间和预算，并结合考虑最终用户可以承担怎么样的风险，来确定在这些限制条件下如何来测试尽量多的组合。

输入和状态之间的关系相当关键，但无论是从局部或全局来看，它都是测试中的一个难点。因为本章讲述的是局部探索式测试法，所以我在这里提供以下建议。

使用状态信息来帮助寻找相关的输入

测试输入的各种组合可以说是测试的一个基本常识。如果两个或更多个输入在某种程度上是相关联的，那么它们应该放在一起测。例如，我们需要测试一个网站，它允许用户输入折扣券来获得一些优惠，但是要求折扣券不能用于打折商品。这里，我们要在购物车里放上打折商品，然后输入折扣券来进行测试。如果我们只测试折扣券用于非打折商品的情况，就会忽略掉上述那种重要的情况，商户就可能会遭受金钱上的损失。在测试中，我们必须观察状态(购买的物品和价格)对结果有什么影响，只有注意到这种情况，才可以知道开发人员有没有编程错误。一旦我们得到了一堆相关的输入值和状态信息后(本例中，就是打折商品、折扣券和所有购买的物品)，我们就可以通过某种方式来确定需要测试哪些输入组合，以保证所有重要的情况和变化都被测试到了。

使用状态信息来辨识重要的输入序列

当一个输入导致状态信息被更新时，紧接着再多次使用同样的输入会导致一连串的状态变化。如果状态变化在某种方式上被累加起来，就必须考虑是否会发生溢出(overflow)。是不是已经存放了太多的数值？是不是一个数会变得过大？比如购物车会不会被装满？用于存放数据的列表是不是会变得太大？通过观察被测应用程序中状态的累积程度，然后重复使用相同或不同的输入来检验这种累积是否会带来某些副作用。