11.2  功能性测试的主要内容及测试策略

11.2.1  功能性测试的主要内容

结合缺陷的正式定义，通常认为，功能测试的主要内容包括以下几个方面。

Ø 检验是否所有功能都能够实现，是否存在遗漏的功能。

Ø 检验是否所有功能都能正确实现，是否存在不正确的功能。

Ø 检验是否存在额外的功能，如快捷键等。

Ø 检验功能是否满足系统设计的隐含需求，如系统对意外情况的反应能力等。

Ø 检验系统能否正确接受输入，对异常输入是否能够予以提示，是否具有一定的容错能力。

Ø 检验系统能否正确输出结果，输出格式和数据是否正确，是否可以正确保存和读取。

Ø 检验系统状态是否能够随业务流程变化而变化，并保持稳定。

11.2.2  功能性测试的测试策略

不同的应用系统，功能测试的内容差异很大，我们可将被测系统分为以数据为中心的系统和以活动序列为中心的系统，前者包括各种管理信息系统，后者包括大部分基于Web的应用系统。下面我们分别讨论这两类系统的基本特点和功能测试的侧重。

1. 以数据为中心的系统

以数据为中心的系统核心就是数据的处理。我们可以从两个方面考虑展开功能测试。

（1）从实体关系模型来考虑

从高层来考虑功能测试，需建立系统的实体关系模型。实体关系模型中明确地描述了系统的所有实体，各实体之问的对应关系和逻辑关系。针对不同的实体关系和逻辑关系，应采用不同策略来设计测试用例。

Ø 1对l：此时仅需一类测试用例，创建l对1的对象实例即可。

Ø 1对多：结合边界值和等价类测试，应分别创建l对1、1对2、1对多这三类对象实例。

Ø 多对l：与1对多相似，应分别创建1对1、2对1，多对l这三类对象实例。

Ø 多对多：这种情况相对复杂，可按照1对多、多对l 、多对多这三种情况分别创建对象实例。

设计测试用例的过程中，还应兼顾满足实体之间的逻辑限定条件。

（2）从对数据的操作来考虑

我们也可以从系统主要涉及的四类针对数据的操作来设计测试用例。这四类操作为：增加、删除、查找和修改。同样地，针对不同操作，也应采用不同的设计思想。

1）增加

应测试增加操作是否能够正常实现，并应测试其他一些特殊的方面，举例如下。

Ø 针对需要唯一命名却输入重复的名字或 ID 的情况，检查系统是否会报错，特别注意添加名字和ID时系统是否区分大小写，或者系统能否正确处理输入内容的前后空格。

Ø 系统是否针对所有必填项进行处理，例如用星号对必填项予以提示。

Ø 增加成功后能否方便地看到增加的结果。

Ø 增加一项或一组数据是否会对其他数据产生影响，若产生影响，是否为正确的影响。

2）删除

应测试针对一项或一组对象的删除操作能否正常实现．并应针对特殊情况进行测试，举例如下。

Ø 对于不存在的对象，或不选中任何对象，系统能否正确处理。

Ø 系统删除之前是否有相应提示。

Ø 删除一项或一组数据是否会对其他数据产生影响，若产生影响，是否为正确的影响。

3）查找

应测试系统能否支持各种查找操作，包括简单查询和高级查询，具体策略如

Ø 输入系统存在和不存在的内容，检查系统查找的结果是否正确。

Ø 对于可以输入多个查找条件的地方，同时添加合理和不合理的条件，检查系统能否正确处理。

Ø 能否将查找结果与修改、删除等操作方便地结合起来。

4）修改

修改主要关注一些特殊的点，包括如下。

Ø 能否修改不存在的对象。

Ø 通过查看来确定修改后带出的信息与修改的信息保持一致，即确保对象得到成功修改。

Ø 应检查添加和修改信息的要求是否一致，例如添加要求必填的项，修改也应该必填；添加规定为整型的项，修改也必须为整型。

Ø 修改时将不允许重名的项改为已存在的内容，检查系统能否及时报错，并注意系统不应报和自己重名的错。

2. 以活动序列为中心的系统

以活动序列为中心的系统核心就是活动序列，包括系统输入、系统输出、系统状态以及系统事件（触发状态变迁的事件）。我们可以结合这些元素来设计测试用例。

（1）基于系统输入的测试用例设计

系统测试与集成测试的一个显著区别在于系统测试是涉及硬件设备（或称端口）的，而集成测试主要关注软件本身，其接口不涉及硬件。基于系统输入设计测试用例应考虑对所有输入的覆盖，可以考虑以下问题．

Ø 是否覆盖所有可以接受输入的硬件设备。

Ø 是否覆盖所有输入条件。

Ø 是否覆盖输入条件的边界取值（采用边界值测试的思想）。

Ø 是否覆盖输入条件的典型取值（采用等价类划分的思想）。

Ø 是否覆盖所有不合理的输入。即碰到任意一种无效或不合理输入的时候，系统能否给予合理的反馈（当然，这个条件一般是不可能完全覆盖的）。

（2）基于系统输出的测试用例设计类似于输入情况，针对系统输出设计测试用例时，也可从以上方面来考虑，只是测试输出时，应该不涉及不合理的输出。

（3）基于系统状态的测试用例设计

系统可能处于多种状态，对于面向对象的系统更是如此，基于系统状态设计功能测试用例时，往往需要借助高层的设计模型，例如，有限状态机直接描述系统的状态，根据系统上业务的分析结果将得到业务流程图，图中每个节点都可以看做是状态。状态的变迁就像程序的执行，会形成不同的路径。在系统测试的层面上，我们可以借鉴白盒测试中的覆盖指标来展开功能测试。对于一个系统状态图而言，可选的覆盖指标如下。

Ø 语句覆盖（即状态覆盖）。状态图中的每个状态对应一条“语句”，设计的测试用例至少应覆盖到每个状态。

Ø 判定覆盖（即状态变换的覆盖）。状态图中随着触发事件的发生，引发状态的变迁，对应“语句”的执行，功能测试用例应覆盖到每次状态的变迁。事实上，只有触发事件才能导致状态变迁，对状态变换的覆盖将访问到每个触发事件，因此，该指标也等同于触发事件的覆盖。

Ø 路径覆盖。从同一个初始状态开始，在不同的事件触发组合条件下，状态的变迁将形成各种路径，最终到达终止状态，在系统层面上，最高也是最严格的覆盖指标就是要达到所有可行路径的覆盖。正如白盒测试中所分析的那样，这个指标往往是很难达到的。

（4）基于系统事件的测试用例设计

基于系统事件设计测试用例是与系统状态紧密联系的，我们建议结合系统状态的覆盖展开对事件的覆盖测试。注意，在功能测试时，状态图与程序分析中的控制流图（或程序图）不同，后者的每个节点是一条语句，它不可分解，而系统状态图中的每个节点对应一个状态，它是可以分解的。状态的分解导致状态图产生层次结构，也进一步导致路径数量的爆炸。解决的方法是采用自底向上的测试策略，从最底层的状态图开始，逐层向上层推进。