软件工程概论（九）测试系统

I. Principles of system testing!!

Sources of software faults

故障可能存在于代码中，但是如果这段代码从未被执行过，或者如果这段代码由于执行时间不够长或这段代码恰好处于有问题的配置中，我们可能根本看不到软件失效。
在开发或维护过程中的任何阶段，例如需求、设计、代码构件或文档中，都可能存在故障。
在开发的早期或后期，都可能将故障引入系统。

System testing process

过程目标

测试系统包括以下几个步骤
1、功能测试
2、性能测试
3、验收测试
4、安装测试

每一步的侧重点不同，并且一个步骤的成功依赖于它的目标或目的。因此，对系统测试的每一步骤的目的进行评审是非常有用的。

首先测试的是系统执行的功能。针对一组构件，开始先单独测试其中的每一个构件，然后把它们集成在一起进行测试。功能测试检查集成的系统是否按照需求中指定的那样执行它的功能。

一旦测试小组确信功能按指定的要求实现后，性能测试将集成的构件与非功能系统需求进行比较。这些需求包括安全性、精确性、速度和可靠性，它们约束了系统功能的执行方式。
此时，系统按照设计人员的意图运作，我们将其称为验证过的系统，它是设计人员对需求规格说明的解释。
接着，通过评审需求定义文档，我们将系统与客户的期望进行比较。如果我们相信构建的系统满足了需求，那么系统就称为确认过的系统。

迄今为止，所有的测试都是由开发人员根据他们对系统及其目标的理解进行的。客户也要测试系统，以确保它符合他们对需求的理解而客户对需求的理解可能与开发人员有所不同。这种测试称为验收测试，它向客户保证，构建的系统就是客户想要的系统。

验收测试有时在实际环境中进行，但通常在不同于目标地点的测试设备下进行。由于这样的原因，还可能需要最后的安装测试，使得用户能够执行系统功能并记录在实际环境中可能引起的其他问题。

构建或集成计划

大型系统不适合作为一种巨型构建被整体测试，一般思路是将系统作为一种嵌套的层次或子系统的集合，测试就针对每个子系统进行。子系统是根据功能划分的，可分为最关键功能、期望功能和不重要功能。更大的子系统包含前面的所有子系统，最终通过迭代实现对整个系统的测试。
递增测试需要仔细计划。定义要测试的子系统，并描述如何、何处、何时由谁进行测试。计划还要解决如集成顺序、是否需要桩或驱动程序等。构建计划的一个层次或子系统被称为一次旋转。旋转有编号，最低的层次称为旋转0。

Configuration management!

系统配置是向特定客户交付的一组系统构件。
开发和测试这些不同的配置需要配置管理。配置管理控制不同系统配置之间的差别，将风险和错误减少到最低程度。配置管理需要确保将各种变化反映在文档以及影响到的其它构件中的。配置管理是协调测试人员和开发人员的。

Versions and release

某个特定系统的一个配置有时称为一个版本，每个版本针对将使用的一种平台或环境。
当修改故障或进行功能增强后，会发布一个新的版本，会带一个编号。
在向用户发布使用之前，配置管理小组负则确保每一个版本或发布都是正确稳定的，并且所进行的变化是准确及时的。
产品系统是已经经过测试满足客户需求的一部分的一个版本，而下个系统即开发系统还在研发。一个开发系统通常有两个目的，一个是增加下一阶段的功能，另一个是改正前面版本中发现的问题。

Regression testing

回归测试用于识别在改正当前故障的同时可能引入的新故障。回顾测试是用于新的版本或发布的一种测试，以验证与旧的版本或发布相比，它是否依然以同样的方式执行相同的功能。

假设版本m的功能测试是成功的，进而对版本m+1进行测试，其中m+1具有版本m的所有功能及一些新的功能。要求改变m+1中的几行代码，以修改较早测试中发现的故障。现在必须改变代码以使m+1的测试能够继续进行。如果测试小组遵循严格的回归测试策略，则测试应该包括下面这些步骤：
插入你的新代码。
测试被新代码影响的功能。
测试m的基本功能，以验证它们仍能适当工作 继续m+1的功能测试。

通常，回归测试包含从前面层次的测试中复用最重要的测试用例。

Deltas, separate files, and conditional compilation

控制版本和发布的方式主要有三种，其中每一种都涉及管理测试过程中的配置。

单独文件：每个版本都有自己的文件。难度在于修改时必须同时改多个版本。

Delta：确定主版本，其它版本只存在它们和主版本的差异，这种差别文件就是delta，描述如何将主版本转换到不同版本。那么修改就只考虑主版本，并且存储空间需求小。但如果主版本没了，那么就比较麻烦，并且转换也不好做。

条件编译：单个代码构件代表所有的版本。条件语句让编译器决定哪些语句适用于哪些版本，共享代码只出现一次，所以对所有版本只进行一次改正。但是，如果版本之间的差异非常复杂，源代码可能难以阅读和理解，再者，对大量的版本来讲，条件编译可能难以管理。

Change control

对系统任何一部分改变，都需要经过配置管理小组批注，修改后录入文档，配置小组通知所有受到影响的人员。
当多名开发人员改变同一个构件的时候，变更控制会更加复杂，变更可能被覆盖。配置管理小组必须进行变更控制，配置管理小组监视代码和文档库，当开发人员进行修改时，要求他们必须检出副本，例如提交和覆盖的控制。另一种方式就是保持单独的、明确的副本在线，需要加锁，进行版本“检出”，避免交叉修改。

Test team

测试小组一般由开发人员和客户组成，但建议有独立的人员。

专业测试人员组织并运行测试。从测试开始阶段，随着项目的进展，到设计测试计划和测试用例，他们都参与其中。专业测试人员与配置管理小组合作，提供文档和其它一些将测试与需求、设计构件和代码紧密结合起来的机制。

分析员参与最初需求定义和规格说明。他们既深刻了解客户定义的问题，也与设计人员一起构造解决方案，他们也了解系统是如何运作的。

系统设计人员使测试小组的工作更具有目的性。当要设计测试用例和确保测试覆盖的时候，系统设计人员了解系统整体情况，可以帮助他们列出所有的可能性。

配置管理代表保证修改记录。当出现失效或变化请求的时候，配置管理专家安排该变动，使其反映在文档、需求、设计、代码或其它开发制品中。

用户，评价提出的关于系统使用的问题。

II. Function testing

系统测试是从功能测试开始的。前面讨论的测试集中于构件和构件之间的交互，功能测试则不考虑系统结构，而集中于功能，属于黑盒测试，不必知道哪个构件做了什么，必须知道系统应该做了什么。

Purpose and roles

与一个功能相关联的动作集合称为线程，因此，功能测试有时候称为线程测试。
一般来说范围越小越容易测试，所以要选择功能测试的范围，因为功能是由某个构件或系统实现的，本身范围就不同。可以用嵌套方式定义功能，就像在层次中定义旋转一样。

有效的功能测试的指导原则，与单元测试类似，包括：
具有很高的故障检测率。
使用独立于设计人员和程序员的测试小组。
了解期望的动作和输出。
既要测试合法输入，也要测试非法输入。
永远不要为了使测试更加容易而去修改系统。
制定停止测试标准。

功能测试是在谨慎、受控的条件下进行的，并且可以在系统构建之前测试部分功能。
功能测试需要与需求进行比较，因此测试用例要对照需求文档进行开发，并进行分级在每一类处理方式中，对不同的功能进行测试。

Cause-and-effect graphs

IBM提出将自然语言的需求定义转化为形式化规格说明，再生成测试用例，且这种过程中用例不会重复，且能够发现需求的不完整或含义模糊问题。

因果图

III. Performance testing

在我们确定系统能执行需求所要的功能之后，就要考虑这些功能的执行方式。因此，功能测试针对的是功能需求，而性能测试针对的是非功能需求。

Purposes and roles

系统性能是根据客户规定的性能目标来测量的。这些性能目标表示为非功能性需求。性能测试则根据对用户命令的响应速度、结果的精确度、数据的可访问性等客户的性能规定，检查计算的效果。
性能测试由测试小组进行设计和执行，并将结果提供给客户。性能测试常常涉及硬件和软件，硬件工程师可能会参与测试小组。

Types of performance testing

性能测试是根据需求进行的，因此，测试的类型由非功能性需求的种类决定。

压力测试是当系统在短时间内达到其压力极限时，对系统进行的测试。有的系统通常是在低于其最大能力的情况下运作的，但是，在某个峰值时间，系统会受到严重的压力，对于这样的系统，压力测试尤为重要。

容量测试强调的是处理系统中的大量数据。例如检查所定义的数据结构能否处理所有可能的情况。另外，对字段、记录和文件进行检查，看他们的大小能否容纳所有的期望数据。还要确保当数据集达到最大限度时，系统能适当的作出反应。

配置测试分析需求中指定的各种软件和硬件的配置。可以定义一个最小的系统，其它另外一些用户使用的配置则可在这个最小的系统的基础上进行构建。配置测试评估所有可能的配置，确保每一种配置都能满足需求。

兼容性测试，检查接口功能，看与其他系统的交互情况 回归测试，保障新系统至少要表现得和老系统一样好。常在分阶段开发的过程中使用。

安全性测试确保安全性需求得到满足。它测试数据和服务的可用性、完整性和机密性相关的系统特性。

计时测试评估响应时间或执行时间，通常和压力测试一起进行，检查系统处于极度活跃的时候，是否还能满足计时需求

环境测试考察系统在安装场所的执行能力，对温度、湿度、可携带性、断电等情况的容忍度

质量测试评估系统的可靠性、可维护性和可用性。包括计算平均无故障时间和平均修复时间以及发现和修复一个故障的平均时间。质量测试有时难以进行，如一个需求指定一个很长的平均失效时间。

恢复测试强调的是系统对出现故障或丢失数据、电源、设备或服务时的反应。使系统丧失一些数据，看它能否适当的恢复。

维护测试跟踪故障根源，提供诊断程序、内存映射、事物追踪、电路图和其它辅助工具，及工具是否能够适当运行。

文档测试确保已经编写了必需的文档，并且信息一致、准确和易于阅读，且格式无误。

人为因素测试检查涉及系统用户界面的需求，还要对操作人员和用户过程进行检查，以了解他们是否遵循易用性需求，这些测试有时候称为可使用性测试。

IV. Reliability, availability, and maintainability！！

可靠性、可用性、可维护性非常重要，因为不能在交付前全部测量，所以保证就非常困难，只能通过间接的方式进行度量。

Definition

可靠性是指一个系统在给定的时间间隔内、在给定条件下无失效运作的概率。我们用0到1之间的数值表示可靠性。如果一个系统是高度可靠的，则其可靠性测量接近1；而一个不可靠的系统，其可靠性测量接近于0.为了更准确反映系统的使用情况，可靠性是根据一段执行时间进行测量的，而不是实际时间。

可用性是指在给定的时间点上，该系统能够完全运行的概率。一个完全可运行的系统可用性为1，一个不能使用的系统可用性为0。可用性是在时钟时间的某一时刻进行测量的，而不是在执行时间上进行测量。

可维护性是在给定的使用条件下，在规定时间间隔内，使用规定的过程和资源完成维护活动的概率。它的取值范围在0到1之间。软件维护与硬件维护不同，硬件维护通常要求在维护期间系统处于不可用状态，但是软件维护有时可以在系统运行期间进行。

三者采用失效定义，一旦系统开始运作，就要测量是否失效。通常将已知和未知失效区分开，即确定可靠性时，只对新的失效进行计数，而不考虑已知的却还没有修复的失效。
通常我们对每个失效指派一个严重性级别，以获取它对系统的影响。

Measurement

MTTF(Main time to failure)平均无故障时间，发现第一个到第i个失效的间隔时间的平均值
MTTR(Mean time to repair)平均修复时间，修复每个失效所需时间的平均值
MTBR(Mean time between failures)平均失效间隔时间，系统可用情况

MTBF=MTTF+MTTR

系统越可靠，MTTF就应该增加，所以MTTF就越小越接近于0，从而提出三类指标
Reliability R = MTTF/(1+MTTF)
Availability A = MTBF/(1+MTBF)
Maintainability M=1/(1+MTTR)

如果不能这样测，就采用比如故障密度（千行代码故障数或每个功能点内故障数）进行表示。重要的不是找到故障或失效的总数，而是隐藏的。

V. Acceptance testing

当功能测试和性能测试之后，我们确信，系统满足在软件开发的初始阶段过程中指定的所有需求，下一步要询问用户和客户，看他们是否持有同样的观点。

Purpose and roles

向客户确认是否完成了对应的工作，客户领导测试并定义测试用例，参与需求定义的客户会主导这个过程。

Types of acceptance tests

在基准测试中，客户准备一组在实际安装后系统运作的典型情况的测试用例，针对每一个测试用例，客户评估系统的执行情况。由实际用户或执行系统功能的专门小组来负则进行基准测试。无论在哪种情况下，测试人员都要对需求很熟悉，并且能够评估实际系统执行情况。
通常在客户有特殊需求时进行，客户会要求两个或多个开发团队根据规格说明生产系统。基于基准测试的成功情况来选择购买其中一个系统。

试验性测试在试验的环境中安装系统，测试日常工作。客户通常准备一个建议的功能列表，每位用户都设法在日常的工作过程中包含这些功能。与基准测试相比没有那么正式和结构化。

有时，在向客户发布一个系统之前，先让自己公司的用户来测试这个系统，在客户进行实际的试验性测试之前先“试验”这个系统，这样的内部测试称为α测试（内测），而客户的试验称为β测试（公测）。当要向大范围的客户发布系统时，经常使用这种方法。

如果一个新系统要替代现有系统，或者该系统是分阶段开发的一部分，可以使用并行测试。在并行测试中，新系统与先前版本并行运转，用户逐渐地适应新系统，但是继续使用与新系统功能相同的老系统。这种逐步过渡的方法使得用户能够将新系统与老系统进行比较和对照。从某种意义上讲，并行测试还包含用户执行的兼容性测试和功能测试。

VI. Installation testing

最后一轮测试，在用户场所安装系统，如果验收已经在了，那么不一定需要安装测试，但是如果一条件变化，就一定需要。要开始进行安装测试，就要在用户环境中配置系统，将正确数量和种类的设备连接到主处理器上，并建立与其他系统的通信。为文件分配空间，指派到适当功能和数据的访问。
安装测试要求我们与客户一起工作，确定现场，保证现场与测试前是一样的。测试用例要让客户确信系统是完备的，且所有必需文件和设备已备齐。测试集中于测两件事，安装系统的完备性，验证任何可能受场所条件影响的功能和非功能特性。
客户满意后，就正式交付系统。

VII. Test documentation

Test plan - test specification and evaluation - test description —test analysis report

测试计划描述系统本身以及测试所有功能及特性的计划。
测试规格说明和评估详细描述每一个测试，以及为测试针对的每一个特征定义评估标准。
测试描述为每一个单独的测试提供测试数据和过程。
测试分析报告描述每一个测试的结果。