测试的种类

系统测试的定义：
   系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不相符合或与之矛盾的地方。

系统测试的对象：
  系统测试的对象不仅仅包括需要测试的产品系统的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。因此，必须将系统中的软件与各种依赖的资源结合起来，在系统实际运行环境下来进行测试

系统测试的设计
   系统测试过程包含了测试计划、测试设计、测试实施、测试执行、测试评估这几个阶段，而整个测试过程中的测试依据主要是产品系统的需求规格说明书、各种规范、标准和协议等。在整个测试过程中，首先需要对需求规格进行充分的分析，分解出各种类型的需求（功能性需求、性能要求、其他需求等），在此基础之上才可以开始测试设计工作，而测试设计又是整个测试过程中非常重要的一个环节，测试设计的输出结果是测试执行活动依赖的执行标准，测试设计的充分性决定了整个系统过程的测试质量。因此，为了保证系统测试质量，必须在测试设计阶段就对系统进行严密的测试设计。这就需要我们在测试设计中，从多方面来综合考虑系统规格的实现情况。通常需要从以下几个层次来进行设计：用户层、应用层、功能层、子系统层、协议层

3.1、用户层：
     主要是面向产品最终的使用操作者的测试。这里重点突出的是在操作者角度上，测试系统对用户支持的情况，用户界面的规范性、友好性、可操作性，以及数据的安全性。主要包括：
3.1.1、用户支持测试
     用户手册、使用帮助、支持客户的其他产品技术手册是否正确、是否易于理解、是否人性化。
3.1.2、用户界面测试
     在确保用户界面能够通过测试对象控件或入口得到相应访问的情况下，测试用户界面的风格是否满足用户要求，例如：界面是否美观、界面是否直观、操作是否友好、是否人性化、易操作性是否较好。
3.1.3、可维护性测试
    可维护性是系统软、硬件实施和维护功能的方便性。目的是降低维护功能对系统正常运行带来的影响。例如：对支持远程维护系统的功能或工具的测试。
3.1.4、安全性测试
    这里的安全性主要包括了两部分：数据的安全性和操作的安全性。核实只有规格规定的数据才可以访问系统，其他不符合规格的数据不能够访问系统；核实只有规格规定的操作权限才可以访问系统，其他不符合规格的操作权限不能够访问系统；

3.2、应用层：
     针对产品工程应用或行业应用的测试。重点站在系统应用的角度，模拟实际应用环境，对系统的兼容性、可靠性、性能等进行的测试。
3.2.1、系统性能测试
     针对整个系统的测试，包含并发性能测试、负载测试、压力测试、强度测试、破坏性测试。并发性能测试是评估系统交易或业务在渐增式并发情况下处理瓶颈以及能够接收业务的性能过程；强度测试是在资源情况低的情况下，找出因资源不足或资源争用而导致的错误；破坏性测试重点关注超出系统正常负荷N倍情况下，错误出现状态和出现比率以及错误的恢复能力。
3.2.2、系统可靠性、稳定性测试
     一定负荷的长期使用环境下，系统可靠性、稳定性。
3.2.3、系统兼容性测试
     系统中软件与各种硬件设备兼容性，与操作系统兼容性、与支撑软件的兼容性。
3.2.4、系统组网测试
     组网环境下，系统软件对接入设备的支持情况。包括功能实现及群集性能。
3.2.5、系统安装升级测试
     安装测试的目的是确保该软件在正常和异常的不同情况下进行安装时都能按预期目标来处理。例如，正常情况下，第一次安装或升级、完整的或自定义的安装都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。还有一个目的是核实软件在安装后可立即正常运行。另外对安装手册、安装脚本等也需要关注。

3.3、功能层
     针对产品具体功能实现的测试。
3.3.1、业务功能的覆盖
     关注需求规格定义的功能系统是否都已实现。
3.3.2、业务功能的分解
     通过对系统进行黑盒分析，分解测试项及每个测试项关注的测试类型。
3.3.3、业务功能的组合
     主要关注相关联的功能项的组合功能的实现情况。
3.3.4、业务功能的冲突
     业务功能间存在的功能冲突情况。比如：共享资源访问等。

3.4、子系统层
     针对产品内部结构性能的测试。关注子系统内部的性能，模块间接口的瓶颈。
3.4.1、单个子系统的性能
     应用层关注的是整个系统各种软、硬件、接口配合情况下的整体性能，这里关注单个系统。3.4.2、子系统间的接口瓶颈
     例如：子系统间通讯请求包的并发瓶颈。
3.4.3、子系统间的相互影响
     子系统的工作状态变化对其他子系统的影响。

3.5、协议/指标层
     针对系统支持的协议、指标的测试。
3.5.1、协议一致性测试
3.5.2、协议互通测试

计算机软件是基于计算机系统的一个重要组成部分，软件开发完毕后应与系统中其它成分集成在一起，此时需要进行一系列系统集成和确认测试。对这些测试的详细讨论已超出软件工程的范围，这些测试也不可能仅由软件开发人员完成。在系统测试之前，软件工程师应完成下列工作：

　　（1） 为测试软件系统的输入信息设计出错处理通路；

　　（2） 设计测试用例，模拟错误数据和软件界面可能发生的错误，记录测试结果，为系统测试提供经验和帮助；

　　（3） 参与系统测试的规划和设计，保证软件测试的合理性。　　

　　系统测试应该由若干个不同测试组成，目的是充分运行系统，验证系统各部件是否都能政党工作并完成所赋予的任务。下面简单讨论几类系统测试。

　　１、恢复测试

　　恢复测试主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。恢复测试首先要采用各种办法强迫系统失败，然后验证系统是否能尽快恢复。对于自动恢复需验证重新初始化（reinitialization）、检查点(checkpointing mechanisms)、数据恢复(data recovery)和重新启动 (restart)等机制的正确性；对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。

　　２、安全测试

　　安全测试检查系统对非法侵入的防范能力。安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。例如，①想方设法截取或破译口令；②专门定做软件破坏系统的保护机制；③故意导致系统失败，企图趁恢复之机非法进入；④试图通过浏览非保密数据，推导所需信息，等等。理论上讲，只要有足够的时间和资源，没有不可进入的系统。因此系统安全设计的准则是，使非法侵入的代价超过被保护信息的价值。此时非法侵入者已无利可图。

　　３、强度测试

　　强度测试检查程序对异常情况的抵抗能力。强度测试总是迫使系统在异常的资源配置下运行。例如，①当中断的正常频率为每秒一至两个时，运行每秒产生十个中断的测试用例；②定量地增长数据输入率，检查输入子功能的反映能力；③运行需要最大存储空间（或其他资源）的测试用例；④运行可能导致虚存操作系统崩溃或磁盘数据剧烈抖动的测试用例，等等。

　　４、 性能测试

　　对于那些实时和嵌入式系统，软件部分即使满足功能要求，也未必能够满足性能要求，虽然从单元测试起，每一测试步骤都包含性能测试，但只有当系统真正集成之后，在真实环境中才能全面、可靠地测试运行性能系统性能测试是为了完成这一任务。性能测试有时与强度测试相结合，经常需要其他软硬件的配套支持。

阶段         产出

1. 计划——《系统测试计划》
2. 设计——《系统方案》（系统测试项和系统测试子项）
3. 实现——《系统测试用例》
4. 执行——《测试报告》

概念：将已经集成好的软件系统，与其他系统元素结合在一起，在实际运行环境下，进行一系列的测试活动。

目的：验证系统对需求的符合程度；

对象：软硬件集成一起的系统，并尽可能地在实际运行环境与条件；

常用类型：

1、功能测试——（针对软件质量中）“功能性”

目的：根据产品的需求规格说明书和测试列表，验证产品的功能实现是否符合需求规格；

关注点：

• 功能是否遗漏
• 功能实现是否满足用户需求和系统设计的隐性需求
• 输入能否正确接受，输出结果是否正确

测试方法：等价类、边界值、判定表、因果图、正交、状态迁移、流程分析……

2、性能测试——“效率”

目的：测试软件集成系统中运行的性能，度量系统相对于目标的差距；

为什么要进行性能测试呢？

• 因为它是产品质量的重要组成部分；
• 用户眼中的良好形象；
• 节省成本（主要是物理设备成本）的重要手段

性能指标是怎么定义的？（需求规格中的）

• 直接提出的性能指标
• 以某个版本为基准
• 与竞争对手的同类产品的比较

性能指标的特征：

• 需求性（设计出来的）
• 代表性
• 可用性
• 可测性
• 完整性：从三个方面——能力（请求量，在线用户量等）、质量（响应率，正确率，延时）、软硬件配置（物理设备）

按目的分类：

• 产品性能质量测试（有指标定义）
• 基准性测试（无指标定义）
• 性能规划测试（有指标定义）

性能测试的基本步骤：（是一个反复执行，重复优化的过程）

1. 性能测试需求分析
2. 业务功能验证
3. 测试环境准备
4. 测试脚本与数据准备
5. 测试场景分析
6. 测试场景监控
7. 测试执行
8. 结果分析

性能测试结论（明确的）

• 指标类：明确产品在不同条件下的性能指标；
• 稳定类：系统是否稳定，每个模块是否稳定；
• 对比类：通过好坏对比来知道差距；
• 验证类：通过与否；
• 优化类：优化方向，优化效果

3、压力测试（stree Testing）——“效率、可靠性”

目的：验证系统在其资源超负荷的情况下的表现（自我保护能力、可靠性），发现性能瓶颈、优化系统；

分类：

• 稳定性压力测试
• 破坏性压力测试

4、容量测试（Volume Testing）——“效率”

目的：验证系统在不同配置、不同场景下能正确处理的最大业务量；

对象：面向数据的；

5、负载测试

目的：

6、安全性测试

7、图形用户界面（GUI）测试

8、可用性测试

9、安全性测试

10、配置测试

11、兼容性测试

12、异常测试

13、备份测试

14、健壮性测试

15、文档测试

16、在线帮助测试

17、网络测试

18、稳定性测试

系统测试，是测试生命周期中最为重要的一个环节：
系统测试
1、 适用对象
由开发部门提供给测试部的最终系统。
2、 进入条件
(1) 已经完成集成测试。
(2) 该系统可以运行在真实或仿真的环境下。
3、 测试内容
测试该系统是否达到了系统需求和功能规格说明中的要求，一般需要进行以下几方面的测试：
(1)功能测试。
(2)性能测试。
(3) 外部接口测试。
(4) 人机界面测试。
(5) 强度测试。
(6) 冗余测试。
(7) 可靠性测试。
(1)安全性测试。
(9) 恢复测试。
4、 具体要求
(1) 由项目负责人决定具体进行那些方面的测试，但至少应该进行功能和性能测试。
(2) 系统测试采用功能测试的方法。
(3) 必须编写正式的系统测试计划。
(4) 系统测试可以在开发环境中进行。
(5) 系统测试组组长应由高级应用专家担任。
(6) 系统测试过程中必须对用户手册进行评价，找出用户手册与实际操作结果的差异。
(7) 系统测试由测试部负责开展，开发小组予以配合。
5、 实施步骤
(1) 在需求分析阶段开始准备【系统测试计划】，并且在设计阶段加以细化更新，在实现阶段最终确定下来。
(2) 建系统测试环境，完成测试设计和开发，准备测试数据。
(3) 执行系统测试用例，并且详细记录测试结果。
(4) 判定测试用例是否通过。
(5) 提交系统测试报告。
(6) 完成交付测试计划。
6、 分析评估
根据【概要设计说明书】、【详细设计说明书】、系统测试结果和发现的错误信息，评价系统的设计与实现。
7、 通过准则
(1) 完全执行了系统测试计划中的每个测试用例。
(2) 在系统测试中发现的错误已经得到修改并且通过了测试。
(3) 完成软件系统测试报告。
(4) 交付测试计划已经完成。

瀑布模型需要完整的需求分析,没有迭代的过程.而迭代模型可以在设计过程中不断的更新,完善需求分析.我觉得瀑布模型不过是一个元素,每个模型中必不可少的有瀑布模型.迭代模型是n个瀑布模型的叠加罢了.

瀑布式模型适合的项目要有以下两个特征：  

 1、需求明确；  

 2、需求稳定，基本上没有变化，或者没有关键性变化。  

 其他的没有限制。

原型：简单说,是当软件需求不明确的时候,先做个样品,给客户看一下,看是否是客户所要得.  

   原型可分为抛弃原型和非抛弃原型.在客户确认了需求之后,抛弃原型就作废了;而非抛弃原形是以后继续开发的基础(非抛弃模型可以理解为螺旋模型的一次周期).  

   开发非抛弃原形要比开发抛弃原形成本高,因为非抛弃原形在设计和实现时必须考虑质量特性,而抛弃原形则不必.  

   我个人认为,在需求完全不明确的情况下,以抛弃原型为宜;但项目太大时,应选用螺旋模型.

增量

螺旋型：Barry Boehm正式发表了软件系统开发的"螺旋模型"，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。

螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：

（1）制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；

（2）风险分析：分析评估所选方案，考虑如何识别和消除风险；

（3）实施工程：实施软件开发和验证；

（4）客户评估：评价开发工作，提出修正建议，制定下一步计划

一个阶段首先是确定该阶段的目标，完成这些目标的选择方案及其约束条件，然后从风险角度分析方案的开发策略，努力排除各种潜在的风险，有时需要通过建造原型来完成。如果某些风险不能排除，该方案立即终止，否则启动下一个开发步骤。最后，评价该阶段的结果，并设计下一个阶段。

兼容测试是测试软件在一个特定的硬件/软件/操作系统/网络等环境下的性能如何。向上兼容向下兼容，软件兼容硬件兼容。软件的兼容性有很多需要考虑的地方

探索测试是指通常用于没有产品说明书的测试，这需要把软件当作产品说明书来看待，分步骤逐项探索软件特性，记录软件执行情况，详细描述功能，综合利用静态和动态技术来进行测试。探索测试人员只靠智能、洞察力和经验来对bug的位置进行判断,所以探索测试又被称为自由形式测试。

可移植性测试是指测试软件是否可以被成功移植到指定的硬件或软件平台上

可移植性测试是指测试软件是否可以被成功移植到指定的硬件或软件平台上

用户界面，英文是User interface。是指软件中的可见外观及其底层与用户交互的部分（菜单、对话框、窗口和其它控件）。

用户界面测试是指测试用户界面的风格是否满足客户要求，文字是否正确，页面是否美观，文字，图片组合是否完美，操作是否友好等等。UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。

用户界面测试用户分析软件用户界面的设计是否合乎用户期望或要求。它常常包括菜单，对话框及对话框上所有按钮，文字，出错提示，帮助信息(Menu和Help content)等方面的测试。比如，测试Microsoft Excel中插入符号功能所用的对话框的大小，所有按钮是否对齐，字符串字体大小，出错信息内容和字体大小，工具栏位置/图标等等。

健全测试是指一个初始化的测试工作，以决定一个新的软件版本测试是否足以执行下一步大的测试努力。例如，如果一个新版软件每5分钟与系统冲突，使系统陷于泥潭，说明该软件不够“健全”，目前不具备进一步测试的条件。

静态测试指测试不运行的部分，例如测试产品说明书，对此进行检查和审阅.。静态方法是指不运行被测程序本身，仅通过分析或检查源程序的文法、结构、过程、接口等来检查程序的正确性。静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。静态测试结果可用于进一步的查错，并为测试用例选取提供指

集成测试是指一个应用系统的各个部件的联合测试，以决定他们能否在一起共同工作并没有冲突。部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。这种类型的测试尤其与客户服务器和分布式系统有关。一般集成测试以前，单元测试需要完成。

集成测试是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。此外，如果程序由多个进程组成，应该成对测试它们，而不是同时测试所有进程。

集成测试识别组合单元时出现的问题。通过使用要求在组合单元前测试每个单元，并确保每个单元的生存能力的测试计划，可以知道在组合单元时所发现的任何错误很可能与单元之间的接口有关。这种方法将可能发生的情况数量减少到更简单的分析级别。

可接受性测试是在把测试的版本交付测试部门大范围测试以前进行的对最基本功能的简单测试。因为在把测试的版本交付测试部门大范围测试以前应该先验证该版本对于所测试的功能基本上比较稳定。必须满足一些最低要求。比如不会很容易程序就挂起或崩溃。如果一个新版本没通过可测试性的验证，就应该阻拦测试部门花时间在该测试版本上测试。同时还要找到造成该版本不稳定的主要缺陷并督促尽快加以修正