【系统分析师】-软件测试

1、测试的类型

1.1、动态测试

1.1.1、黑盒法

1.1.2、白盒法

1.1.3、灰盒法

1.2、静态测试

2、测试阶段

2.1、单元测试

2.2、集成测试

2.3、确认测试

2.4、系统测试

3、性能测试

3.1、性能测试的目的

3.2、性能测试的类型

3.3、性能测试的步骤

5、测试设计

6、测试管理

7、考点

软件测试用于验证软件是否满足软件需求规格说明和软件设计所规定的功能、性能及软件质量特性的要求，为软件质量的评价提供依据。

软件测试过程包括测试计划、测试设计、测试执行和测试评估等阶段

1、测试的类型

1.1、动态测试

通过运行程序发现错误

1.1.1、黑盒法

又称功能测试或数据驱动测试。

测试人员完全不考虑程序的内部结构和处理过程，只在软件的接口处进行测试，是否满足需求规格说明书。

对输入数据的各种可能值的排列组合进行测试。

1、等价类划分

把程序的输入域划分成若干部分，从每部分选择少数数据作为测试用例。

2、边界值分析

一种补充等价类划分的测试用例，不选择等价类的任意元素，而是选择等价类边界的测试用例。

3、错误推测

基于经验和直觉推测程序中的所有可能错误，有针对性的设计测试用例。

4、因果图

从自然语言书写的程序规则说明的描述中找出因（输入条件）和果（输出或程序状态的改变），通过因果图转化为判定表

1.1.2、白盒法

又称结构测试

测试人员必须了解程序的内部结构和处理过程，以检查处理过程的细节为基础，对程序中的逻辑路径进行测试，检查内部控制结构和数据结构是否有误，实际的运行状态与预期状态是否一致。

1、基本路径测试

在程序控制流程图的基础上，通过分析控制结构的环路复杂性导出基本路径集合，然后设计测试用例，保证路径至少通过一次。

2、循环覆盖测试

指覆盖程序中所有的循环，包含单循环和嵌套循环

3、逻辑覆盖测试

以程序内部逻辑为基础，包括

语句覆盖、判定覆盖、条件覆盖、条件判定覆盖、修正的条件判断覆盖、条件组合覆盖、点覆盖、边覆盖和路径覆盖等。

1.1.3、灰盒法

一种介于白盒测试与黑盒测试之间的测试，它关注输出对于输入的正确性，同时也关注内部表现，但这种关注不像白盒测试那样详细且完整，而只是通过一些表征性的现象、事件及标志来判断程序内部的运行状态。

灰盒测试结合了白盒测试和黑盒测试的要素，考虑了用户端、特定的系统知识和探作环境，在系统组件的协同性环境中评价应用软件的设计。

1.2、静态测试

指被测试程序不在机器上运行，而采用人工检测和计算机辅助静态分析的手段对程序进行检测。

1）桌前检查

由程序员自己检查自己编写的程序。

2）代码审查

由若干程序员和测试员组成一个会审小组，通过阅读、讨论和争议，对程序进行静态分析的过程。

第一步，小组负责人提前把设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给小组成员，作为评审的依据。

第二步，召开程序审查会。在会上，首先由程序员逐句讲解程序的逻辑。在此过程中，程序员或其他小组成员可以提出问题，展开讨论，审查错误是否存在。

3）代码走查

代码走查与代码审查基本相同

第一步，把材料先发给走查小组每个成员，让他们认真研究程序，然后再开会。

第二步，让与会者“充当”计算机，准备一批有代表性的测试用例，提交给走查小组。

静态测试属于白盒测试的范畴

2、测试阶段

2.1、单元测试

又称为模块测试，是针对软件设计的最小单位(程序模块)进行正确性检验的测试工作。

其目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求，以及发现各模块内部可能存在的各种错误。

单元测试需要从程序的内部结构出发设计测试用例，多个模块可以平行独立地进行单元测试。

单元测试计划在软件详细设计阶段完成

2.2、集成测试

也称为组装测试、联合测试(对于子系统而言，则称为部件测试)。它将已通过单元测试的模块集成在一起，主要测试模块之间的协作性。

一次性组装和增量式组装(包括自顶向下、自底向上及混合式)

黑盒测试

1）驱动模块：相当于被测模块的主程序。它接收测试数据，把这些数据传送给被测模块，最后输出实测结果。

2）桩模块：用于代替被测模块调用的子模块。模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不允许什么事情也不做。

在自底向上增量式集成时，因为模块是自底向上进行组装，对于一个给定层次的模块，它的子模块(包括子模块的所有下属模块)已经组装并测试完成，所以不再需要模块。

在模块的测试过程中需要从子模块得到的信息可以直接运行子模块得到。

集成测试计划在软件概要设计阶段完成

2.3、确认测试

也称有效性测试，主要包括验证软件的功能、性能及其他特性是否与用户要求(需求)一致。

包含以下类型

(1)内部确认测试：主要由软件开发组织内部按软件需求说明书进行测试。

(2)Alpha 测试：由用户在开发环境下进行测试。

(3)Beta 测试：由用户在实际使用环境下进行测试。

(4)验收测试：针对软件需求说明书，在交付前以用户为主进行测试。

确认测试计划在需求分析阶段完成

2.4、系统测试

如果项目不只包含软件，还有硬件和网络等，则要将软件与外部支持的硬件、外设、支持软件、数据等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列集成与确认测试。

主要内容包括功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、安装与反安装测试

系统测试计划在系统分析阶段(需求分析阶段)完成

3、性能测试

通过自动化的测试工具模拟多种正常、峰值及异常负载条件来对系统的各项性能指标进行测试。

1）通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。

2）压力测试是通过确定一个系统的瓶颈或不能接收的性能点，获得系统能提供的最大服务级别的测试

3.1、性能测试的目的

评估系统的能力
识别体系中的弱点
系统调优
检测软件中的问题
验证稳定性和可靠性

3.2、性能测试的类型

负载测试：指数据在超负荷环境中运行，程序是否能够承担。
强度测试：强度测试是在系统资源特别低的情况下考查软件系统运行情况。
容量测试：确定系统可处理的同时在线的最大用户数。

3.3、性能测试的步骤

(1)制定目标和分析系统。

(2)选择测试度量的方法。

(3)学习相关技术和工具。

(4)制定评估标准。

(5)设计测试用例。

(6)运行测试用例。

(7)分析测试结果

在网络应用系统中，负载压力测试应重点关注客户端、网络及服务器(包括应用服务器和数据库服务器)的性能。应获取的关键测试指标如下。

(1)客户端:并发用户数、响应时间、交易通过率及吞吐量等

(2)网络:带宽利用率、网络负载、延迟，以及网络传输和应用错误等

(3)服务器:操作系统的 CPU占用率、内存使用和硬盘 O等;数据库服务器的会话执行情况、SQL执行情况、资源争用及死锁等;应用服务器的并发连接数、请求响应时间等。

5、测试设计

1）用户层测试是面向产品最终的使用操作者的测试，重点突出的是从操作者角度上，测试系统对用户支持的情况，用户界面的规范性、友好性、可操作性，以及数据的安全性等。主要包括用户支持测试、用户界面测试、可维护性测试和安全性测试。

2）应用层测试是针对产品工程应用或行业应用的测试，重点放在系统应用的角度，模拟实际应用环境，对系统的兼容性、可靠性、性能等进行测试。主要包括系统性能测试系统可靠性、系统稳定性测试、系统兼容性测试、系统组网测试和系统安装升级测试。

3）功能层测试是针对产品具体功能实现的测试，主要包括功能覆盖测试、功能分解测试、功能组合测试和功能冲突测试。

4）子系统层测试是针对产品内部结构性能的测试，重点关注子系统内部的性能、模块间接口的瓶颈。主要包括单个子系统性能测试、子系统间的接口瓶颈测试和子系统间的相互影响测试。

5）协议层测试是针对系统支持的协议的测试，主要包括协议一致性测试和协议互通性测试。

6、测试管理

(1)测试团队管理

首先，一个好的测试团队要有一个具有极为丰富的开发经验、具有亲和力和人格魅力的带头人。其次，测试团队还应有具备一技之长(如对某些自动化测试工具运用娴熟或能轻而易举地编写自动化测试脚本)的成员。另外，测试团队还应有兼职的同行专家。

(2)测试计划管理

测试计划也称软件验证与确认计划，它详细地规定测试的要求，包括测试的目的、内容、方法、步骤以及测试的准则等，以用来验证软件需求规格说明书中的需求是否已由软件设计说明书描述的设计实现。软件设计说明书表达的设计是否已由编码实现，编码的执行是否与软件需求规格说明书中所规定的需求相一致。由于要测试的内容可能涉及到软件的需求和软件的设计，因此必须及早开始测试计划的编写工作。不应在着手测试时，才开始考虑测试计划。通常，测试计划的编写从需求分析阶段开始，到软件设计阶段结束时完成。

(3)缺陷跟踪管理

当测试团队发现文档或代码中存在缺陷以后，并不是交一份测试报告就草草了事，而是在递交报告以后继续督促开发团队及时改正已有错误。当开发团队改正了测试报告中的错误以后，测试团队还需进行回归测试以验证开发团队在改错过程中没有引入新的错误。

(4)测试件管理

测试件指测试工作形成的产品，包括测试团队在长期实践过程中逐步积累起来的经验教训、测试技巧、测试工具、规格文档以及一些经过少量修改能推广通用的测试脚本程序。测试件管理工作做得越好，测试团队在实际测试过程中就能越少走弯路，测试团队内部的知识交流和传递就越充分，测试脚本或规格文档的重复开发工作也就能被有效地避免。