【软件测试】集成测试和系统测试

1.系统集成的模式与方法 

1.1   软件集成测试前的准备

◇人员安排

◇测试计划

◇测试内容

◇集成模式

◇测试方法

1.2  集成测试的模式

渐增式测试模式与非渐增式测试模式　
非渐增式测试模式：先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序，如大棒模式。
渐增式测试模式：把下一个要测试的模块同已经测试好的模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合进来测试。

1.3  自顶向下和自底向上集成方法 

驱动程序/驱动模块（driver），用以模拟被测模块的上级模块。驱动模块在集成测试中接受测试数据，把相关的数据传送给被测模块，启动被测模块，并打印出相应的结果。

桩程序/桩模块（stub），也有人称为存根程序，用以模拟被测模块工作过程中所调用的模块。桩模块由被测模块调用，它们一般只进行很少的数据处理，例如打印入口和返回，以便于检验被测模块与其下级模块的接口

1.3.1  自顶向下法(Top-down Integration) 

1.3.2   自底向上法(Bottom-up Integration) 

1.3.3  混合策略(Modified Top-down Integration) 

混合法：对软件结构中较上层，使用的是“自顶向下”法；对软件结构中较下层，使用的是“自底向上”法，两者相结合 

1.3.4  大棒集成方法(Big-bang Integration)

采用大棒集成方法,先是对每一个子模块进行测试（单元测试阶段），然后将所有模块一次性的全部集成起来进行集成测试 。

因为所有的模块一次集成的，所以很难确定出错的真正位置、所在的模块、错误的原因。这种方法并不推荐在任何系统中使用，适合在规模较小的应用系统中使用。  

1.3.5  三明治集成方法(Sandwich Integration) 

采用三明治方法的优点是：它将自顶向下和自底向上的集成方法有机地结合起来，不需要写桩程序因为在测试初自底向上集成已经验证了底层模块的正确性。采用这种方法的主要缺点是：在真正集成之前每一个独立的模块没有完全测试过。

改善的三明治集成方法

改进的三明治集成方法，不仅自两头向中间集成，而且保证每个模块得到单独的测试，使测试进行得比较彻底 。

1.4  几种集成方法性能的比较 

2.功能测试

2.1  目的和内容

•  程序安装、启动正常，有相应的提示框、错误提示等
•  每项功能符合实际要求
•  系统的界面清晰、美观
•  菜单、按钮操作正常、灵活，能处理一些异常操作
•  能接受正确的数据输入，对异常数据的输入有提示、容错处理等
•  数据的输出结果准确，格式清晰，可以保存和读取
•  功能逻辑清楚，符合使用者习惯
•  系统的各种状态按照业务流程而变化，并保持稳定
•  支持各种应用的环境
•  能配合多种硬件周边设备
•  软件升级后，能继续支持旧版本的数据
•  与外部应用系统的接口有效 

2.2  功能测试的方法 

• 等价类划分法
• 边界值分析法
• 错误推测法
• 因果图法
• 组合分析法

2.2.1  等价类划分法

划分好等价类测试：防止遗漏测试案例。

2.2.2   边界值分析法

例子：排序程序，边界条件有：

•  序列为空；
•  序列仅有一个数据；
•  序列为满，用猜错法补充一下测试用例；
•  序列已经按要求排好序；
•  序列的顺序与要求的顺序恰好相反；
•  序列中的所有数据全部相等。

   因为错误最容易发生在边界值附近，所以边界值分析法对于多变量函数的测试很有效，尤其是对于像C/C++数据类型要求不是很严格的语言有利 。

2.2.3   错误推测法

这个错误到底在哪呢？

2.2.4  因果图法

2.2.5  组合分析法

  组合分析是一种基于每对参数组合的测试技术，主要考虑参数之间的影响是主要的错误来源和大多数的错误起源于简单的参数组合。

3.系统测试

回归测试（Regression test）

压力测试 (Stress test) 
容量测试 (Capacity test) 
性能测试 (Performance test) 
安全测试 (Security test) 
容错测试 (Recovery test) 

可靠性测试（Reliability test）

3.1  回归测试

回归测试的目的 

•  所做的修改达到了预定的目的，如错误得到了改正，新功能得到了实现，能够适应新的运行环境等；
•  不影响软件原有功能的正确性。

 回归测试的方法

•   再测试全部用例 
•  基于风险选择测试 
•  基于操作剖面选择测试 
•  再测试修改的部分 

回归测试的组织和实施

3.2  压力测试，容量测试和性能测试

    压力测试、容量测试和性能测试的测试目的虽然有所不同，但其手段和方法在一定程度上比较相似，通常会使用特定的测试工具，来模拟超常的数据量、负载等，监测系统的各项性能指标，如CPU和内存的使用情况、响应时间、数据传输量等。 

3.3  性能测试

看看在各种情况下CPU使用的效率

性能测试的目的： 为了验证系统是否达到用户提出的性能指标，同时发现系统中存在的性能瓶颈，起到优化系统的目的。

性能测试指标的来源： 用户对各项指标提出的明确需求；如果用户没有提出性能指标则根据用户需求、测试设计人员的经验来设计各项测试指标。（需求+经验）

主要的性能指标： 服务器的各项指标（CPU、内存占用率等）、后台数据库的各项指标、网络流量、响应时间

性能测试要点：

• 测试环境应尽量与产品运行环境保持一致，应单独运行尽量避免与其他软件同时使用。
• 性能测试一般使用测试工具和测试人员编制测试脚本来完成。
• 性能测试的重点在于前期数据的设计与后期数据的分析。
• 性能测试的用例主要涉及到整个系统架构的问题，所以测试用例一旦生成，改动一般不大，所以做性能测试的重复使用率一般比较高。

性能测试的方法和技巧：

两种负载类型：

• “flat”测试
• ramp-up测试

对于企业级的系统，性能测试的方法主要有：

• 基准测试
• 性能规划测试
• 渗入测试
• 峰谷测试

两种负载类型：

3.3.1  “Flat”测试

 对于一次给定的测试，应该取响应时间和吞吐量的平均值。精确地获得这些值的唯一方法是一次加载所有的用户，然后在预定的时间段内持续运行。

3.3.2  Ramp-up测试:

用户是交错上升的（每几秒增加一些新用户）。ramp-up测试不能产生精确和可重现的平均值，这是因为由于用户的增加是每次一部分，系统的负载在不断地变化。其优点是，可以看出随着系统负载的改变，测量值是如何改变的据此选择要运行的flat测试的范围。

3.3.3  基准测试

将系统置于相同的高负载下，将请求之间间隔时间设为零。这样服务器会立即超载，并开始构建执行队列。如果请求（虚拟用户）数保持一致，基准测试的结果会非常精确 flat运行是获得基准测试数据的理想模式

3.3.4  性能规划测试

性能规划类型的测试其目标是找出在特定的环境下，给定应用程序的性能可以达到何种程度。例如，如果要以5秒或更少的响应时间支持8,000个当前用户，需要多少个服务器？

　要确定系统的容量，需要考虑几个因素:

• 用户中有多少是并发与服务器通信的。
• 每个用户的请求间时间间隔是多少。

如何加载用户以模拟负载状态？
最好的方法是模拟高峰时间用户与服务器通信的状况。
如果用户负载状态是在一段时间内逐步达到的,选择ramp-up测试，每隔几秒增加x个用户;
如果所有用户是在一个非常短的时间内同时与系统通信，就应该使用flat测试，将所有的用户同时加载到服务器

  什么是确定容量的最好方法？
结合两种负载类型的优点，并运行一系列的测试
  如：首先使用ramp-up测试确定系统支持的用户范围该范围内不同的并发用户负载进行一系列的flat测试，更精确地确定系统的容量。

3.3.5  渗入测试

渗入测试是一种比较简单的性能测试。渗入测试所需时间较长，它使用固定数目的并发用户测试系统的总体健壮性。这些测试将会通过内存泄漏、增加的垃圾收集(GC)或系统的其他问题，显示因长时间运行而出现的任何性能降低。
  
   建议运行两次测试——一次使用较低的用户负载（要在系统容量之下，以便不会出现执行队列），一次使用较高的负载（以便出现积极的执行队列）。

3.3.6  峰谷测试

兼有容量规划ramp-up测试和渗入测试的特征,目标是确定从高负载（例如系统高峰时间的负载）恢复、转为几乎空闲、然后再攀升到高负载、再降低的能力。

性能测试的过程:

3.4  压力测试

在一种需要反常（如长时间的峰值）数量、频率或资源的方式下，执行可重复的负载测试，以检查程序对异常情况的抵抗能力，找出性能瓶颈。从本质上来说，测试者是想要破坏程序。
步骤：

•  测试压力估算 
•  测试环境准备 
•  问题的分析 
•  累积效应 

试试这个游戏站点的承受力

3.4.1  压力测试类型

•  并发性能测试（重点）
•  疲劳强度测试
•  大数据量测试 

3.4.2  并发性能测试

考察客户端应用的性能，测试的入口是客户端
并发性能测试的过程，是一个负载测试和压力测试的过程。即逐渐增加并发虚拟用户数负载，直到系统的瓶颈或者不能接收的性能点，通过综合分析交易执行指标、资源监控指标等来确定系统并发性能的过程。并发性能测试是负载压力测试中的重要内容。

ramp-up测试
    

3.4.3  疲劳强度测试

    通常是采用系统稳定运行情况下能够支持的最大并发用户数或者日常运行用户数，持续执行一段时间业务，通过综合分析交易执行指标和资源监控指标来确定系统处理最大工作量强度性能的过程。
    疲劳强度测试案例制定的原则是保证系统长期不间断运行的业务量，并且应该尽量去满足该条件。 
 Flat测试

3.4.4  大数据量测试

独立的数据量测试
       针对某些系统存储、传输、统计、查询等业务进行大       数据量测试 

综合数据量测试 
       和压力性能测试、负载性能测试、并发性能测试、疲劳性能测试相结合的综合测试方案 

3.5  容量测试 

  容量测试目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限值状态下还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。 

3.5.1  度量系统容量举例

查看现有系统中性能与负载间的关系，并确定出现响应时间显著延长的位置 “拐点”。可以确定是否需要增加资源以支持额外的用户。

3.5.2  系统瓶颈分析举例

交易的响应时间如果很长，远远超过系统性能需求，表示耗费CPU的数据库操作，例如排序，执行aggregate functions（例如sum、min、max、count）等较多，可考虑是否有索引以及索引建立的是否合理；尽量使用简单的表联接；水平分割大表格等方法来降低该值。 

3.6  安全性测试，可靠性和容错性测试 

 安全性测试、可靠性测试和容错性测试的测试目的不同，其手段和方法也不同，但都属于系统测试的范畴，有一定的联系，如软件可靠性要求通常包括了安全性的要求。
安全性测试、可靠性测试和容错性测试的技术比较深、实施比较难，但在应用系统中越来越重要。

3.7  安全性测试

根据ISO 8402的定义，安全性是“使伤害或损害的风险限制在可接受的水平内”。 

安全性测试是检查系统对非法侵入的防范能力。安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。例如：

•   想方设法截取或破译口令；
•  专门开发软件来破坏系统的保护机制；
•  故意导致系统失败，企图趁恢复之机非法进入；
•  试图通过浏览非保密数据，推导所需信息等等。

理论上讲，只要有足够的时间和资源，没有不可进入的系统。因此系统安全设计的准则是，使非法侵入的代价超过被保护信息的价值，此时非法侵入者已无利可图。

3.8   可靠性测试 

可靠性（Reliability）是产品在规定的条件下和规定的时间内完成规定功能的能力，它的概率度量称为可靠度。软件可靠性是软件系统的固有特性之一，它表明了一个软件系统按照用户的要求和设计的目标，执行其功能的可靠程度。软件可靠性与软件缺陷有关，也与系统输入和系统使用有关。理论上说，可靠的软件系统应该是正确、完整、一致和健壮的。 

• 规定的时间 
• 规定的环境条件
• 规定的功能

3.8.1  可靠性测试结果的评估

成熟性度量可以通过错误发现率DDP（Defect Detection Percentage）来表现。在测试中查找出来的错误越多，实际应用中出错的机会就越小，软件也就越成熟。
DDP=测试发现的错误数量/已知的全部错误数量
已知的全部错误数量是测试已发现的错误数量加上可能会发现的错误数量之和。

3.9  容错性测试 

容错性测试是检查软件在异常条件下自身是否具有防护性的措施或者某种灾难性恢复的手段。如当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。容错性测试包括两个方面：

• 输入异常数据或进行异常操作，以检验系统的保护性。如果系统的容错性好的话，系统只给出提示或内部消化掉，而不会导致系统出错甚至崩溃。
• 灾难恢复性测试。通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失、系统和数据是否能尽快恢复。

4.0  从质量三个纬度看系统测试