【系统分析师之路】系统分析师必知必会（系统测试与维护）

【系统分析师之路】系统分析师必知必会（系统测试与维护）

一. 软件测试

从测试阶段划分可分为三类：单元测试，集成测试和确认测试。

1. 单元测试

单元测试计划应该在详细设计阶段制定，由程序员自己来测。

2. 集成测试

对各模块组合而成的程序进行测试。集成的方式分为增量型集成（渐增式集成）和非增量集成（整体拼装）两种。
渐增式集成又可以分为自顶向下集成和自底向上集成。
集成测试计划应该在概要设计阶段制定。

3. 确认测试

检查软件的功能，性能以及其他特征是否与用户需求保持一致。
确认测试计划应该在需求分析阶段制定。

4. 阿尔法beta测试

从测试群体，场地来划分：
阿尔法测试：用户在开发者场地所进行的测试。并且在开发者的指导下进行测试。在受控的环境中进行。
beta测试：在用户现场由最终用户实施的测试。非受控。
内部确认测试以及Alpha测试与Beta测试都属于确认测试的范畴。

5. 黑盒白盒测试

1. 黑盒测试

用于集成测试，确认测试阶段。

1. 等价类划分

在设计测试用例时，等价类划分是用得最多的一种黑盒测试方法。所谓等价类就是某个输入域的集合，对于一个等价类中的输入值来说，它们揭示程序错误的作用是等效的。也就是说，如果等价类中的一个输入数据能检测出一个错误，那么等价类中的其他输入数据也能检测出同一个错误；反之，如果等价类中的一个输入数据不能检测出某个错误，那么等价类中的其他输入数据也不能检测出这一错误（除非这个等价类的某个子集还属于另个一等价类）。

2. 边界值分析

经验表明，软件在处理边界情况时最容易出错。设计一些测试用例，使软件恰好运行在边界附近，暴露出软件错误的可能性会更大一些。通常，每一个等价类的边界，都应该着重测试，选取的测试数据应该恰好等于、稍小于或稍大于边界值。例如，对于条件“10<x<30”的测试，可以选取x的值为9、10、30和31作为测试数据。
在实际测试工作中，将等价类划分法和边界值分析法结合使用，能更有效地发现软件中的错误。

3. 错误推测

使用等价类划分和边界值分析技术，有助于设计出具有代表性的、容易暴露软件错误的测试方案。但是，不同类型的软件通常有一些特殊的容易出错的地方。错误推测法主要依靠测试人员的经验和直觉，从各种可能的测试用例中选出一些最可能引起程序出错的用例。

2. 白盒测试

主要用于单元测试阶段，由程序员负责。
在纠正程序中所有的错误以后，还应选择部分或者全部原先已经测试过了的测试用例，对修改后的程序进行重新测试，也叫做回归测试。回归测试的目的是检验修改所引起的副作用。

1. 语句覆盖

选择足够多的测试用例，使得运行这些测试用例时，被测程序的每个语句至少执行一次。很显然语句覆盖是一种很弱的覆盖标准。

2. 判定覆盖

也称为分支覆盖。它是指不仅每个语句至少执行一次，而且每个判定的每个可能的结果都至少执行一次，它比语句覆盖强，但对程序逻辑的覆盖仍然不高。

3. 条件覆盖

不仅每个语句至少执行一次，判定覆盖比语句覆盖强，而且判定表达式中的每个条件都取得各种可能的结果，条件覆盖不一定包含判定覆盖，判定覆盖也不一定包含条件覆盖。

4. 条件判定覆盖

同时满足判定覆盖和条件覆盖的逻辑覆盖。
使得判定表达式中每个条件的所有可能结果至少出现一次。

5. 条件组合覆盖

所有的可能的组合至少出现一次。显然满足条件组合覆盖的测试用例，也一定满足条件判定覆盖。因此条件组合覆盖是强于以上四种的覆盖；然而，条件组合覆盖并不能保证所有的可能的路径都至少遍历一次；

6. 修正的条件判定覆盖

修正的条件/判定覆盖需要足够的测试用例来确定各个条件能够影响到包含的判定结果。首先，每个程序模块的入口和出口点都要考虑至少要被调用一次，每个程序的判定到所有可能的结果值要至少转换一次；其次，程序的判定被分解为通过逻辑操作符（and和or）连接的布尔条件，每个条件对于判定的结果值是独立的

7. 路径覆盖

选取足够的测试用例，使得程序的每条可能执行到的路径都至少执行一次，如果程序中有环路，则要求每条环路路径至少经过一次，它实际上已经考虑了程序中各种判定结果的所有可能组合，因此是一种较强的覆盖标准，但路径覆盖并未考虑判定中的条件结果的组合，并不能代替条件覆盖和条件组合覆盖。

6. 系统测试

系统测试的主要内容包括功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、安装与反安装测试等，其中，最重要的工作是进行功能测试与性能测试。
系统测试的对象是完整的、集成的计算机系统。
系统测试的技术依据是用户需求或开发合同，除应满足一般测试的准入条件外，在进行系统测试前，还应确认被测系统的所有配置项已通过测试，对需要固化运行的软件还应提供固件。

1. 功能测试

功能测试的目的很简单，测试系统是否达到用户提出的需求和隐含需求。
软件系统测试中功能测试就是平时所说的黑盒测试与白盒测试。
目的是在真实系统工作环境下，验证完整的软件配置项能否和系统正确连接，并满足系统/子系统设计文档和软件开发合同规定的要求

2. 性能测试

性能测试的目的是验证软件系统是否能够达到用户提出的性能指标
同时发现软件系统中存在的性能瓶颈，并优化软件，最后起到优化系统的目的。
主要的性能指标有：吞吐量，响应时间，并发用户数，资源利用率等。

7. Web系统测试

包括功能测试，性能测试，可用性测试和兼容性测试，安全性测试等五个大类别。

1. 功能测试

1）链接测试

链接测试可分为三个方面。
测试所有链接是否按指示链接到正确的页面；
其次，测试所链接的页面是否存在；
最后，保证Web应用系统上没有孤立页面。
链接测试可以自动进行，现在已经有许多工具可以采用。

2）表单测试

当用户给Web应用系统管理员提交信息时，就需要使用表单操作，例如用户注册，登陆，信息提交等。
在这种情况下，必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。
如果使用默认值，还要检验默认值的正确性。
如果表单只能接受指定的某些值，则也要进行测试。

3）Cookies测试

如果Web应用系统使用了 Cookies,就必须检查Cookies是否能正常工作。
测试的内容包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等等。

4）设计语言测试

Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的Html等。
当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语言例如：Java，JavaScript，ActiveX，VBScript或Perl等也要进行验证。

5）数据库测试

在Web应用中，最常用的数据库类型是关系型数据库。
在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。
数据一致性错误主要是由于用户提交的表单信息不正确造成的，而输出错误往往是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。

2. 性能测试

1）连接速度测试

由于用户连接到Web应用系统的速度差异较大，需要对Web系响应时间进行测试；
需要对页面响应速度和超时设置进行测试；
最后需要考虑由于连接速度太慢而引起的数据丢失。

2）负载测试

负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。
负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。

3）压力测试

压力测试是指实际破坏一个Web应用系统，测试系统的反映。
压力测试是测试系统的限制和故障恢复能力
也就是测试Web应用系统会不会崩溃，在什么情况下会奔溃。
压力测试的区域包括表单，登陆和其他信息传输页面等。

3）可用性测试

（1）导航测试

需要考虑导航是否直观，Web系统的主要部分是否通过主页存取，Web系统是否需要站点地图，搜索引擎或其他的导航帮助等导航可用性问题。
Web系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。

（2）图形测试

验证图形用途，减少传输时间与传输量；
验证所有页面字体的风格是否一致；
验证背景颜色是否与字体颜色和前景颜色相互搭配；
检查图片的大小和质量，等等。

（3）内容测试

主要检验Web应用系统提供信息的正确性、准确性和相关性。

（4）整体界面测试

考查整个Web系统的页面结构设计，是否给用户的一个整体感。
对所有的可用性测试来说，都需要有外部人员的参与，最好是最终用户的参与。

4）兼容性测试

（1）平台测试
需要在各种操作系统下对Web系统进行兼容性测试。
（2）浏览器测试
测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。

5）安全性测试

（1）用户名、密码测试

必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。
######（2）超时测试
测试Web系统是否有超时的限制。

（3）日志信息测试

需要测试相关信息是否写进了日志文件、是否可追踪。
######（4）安全套接字测试
当使用安全套接字时，还要测试加密是否正确，检查信息的完整性。

（5）服务器端脚本问题

服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。
所以还要就没有经过授权，就不能在服务器端放置和编辑脚本的问题进行测试。

8. 自动化测试

1. 概念定义

编程自动化是一个通过编程完成测试的过程。一旦实现了测试的自动化，大量的测试用例可以迅速的得到执行。
测试自动化通常需要构建存放程序软件包和测试软件包的文件服务器，存储测试用例和测试结果的数据库服务器；执行测试的运行环境，控制服务器，Web服务器和客户端程序。
自动化测试的主要实现方法包括了代码的静态与动态分析，测试过程的捕获与回放，测试脚本技术，虚拟用户技术和测试管理技术等。
对于产品单一，或者是开发周期长的项目，我们更加倾向于自己开发测试工具，无论是从节省成本还是从企业长远发展考虑，这都是有利的。

2. 自动化测试的优点

提高测试执行的速度
提高工作效率
保证测试结果的准确性
连续运行测试脚本
模拟现实环境中受到约束的情况

3. 自动化测试的缺陷：

自动化测试不能取代手动测试
自动化测试能够发现的缺陷不如手工测试
自动化测试对所测产品质量约束大，不能提高有效性，可能会制约软件开发，以及测试工具不具备想象力等。

4. 测试用例的生成

当前流行的自动化测试工具主要使用脚本技术来生成测试用例。
脚本是一组测试工具执行的指令的集合，其作用是通过回放的方式来模拟手工测试所执行的操作。

5. 自动化测试工具

自动化测试工具的关键特征就是具有良好的脚本开发环境。测试工具首先要具有相应的容错系统，可以自动处理一些异常的状况；其次要能够提供类似软件集成开发环境中的调试功能；
目前自动化测试工具主要有：单元测试工具，负载和性能测试工具，GUI功能测试工具，基于Web应用的测试工具。其他的测试工具还包括了缺陷跟踪工具，综合测试管理工具，嵌入式测试工具，数据库测试工具等。

9. 面向对象单元测试

面向对象系统的单元测试包括方法层次的测试、类层次的测试和类树层次的测试。

1. 方法层次的测试

类似于传统软件测试中对单个函数的测试，常用的测试技术包括等价类划分测试、组合功能测试、递归函数测试和多态消息测试等。

2. 类层次的测试

主要包括不变式边界测试、模态类测试和非模态类测试。

3. 类树层次的测试

主要包括多态服务测试和展平测试

二. 软件维护

软件经过测试交付用户后，在使用和运行的过程中，可能在软件运行维护阶段对软件进行的修改，就是所谓的维护。
软件维护占整个生命周期的60%到80%。
可维护性包括了：可分析性，易改变性，稳定性，易测试性，依从性。

1. 纠正性维护（改正性维护）

在软件投入运行后，可能会暴露一部分在测试阶段没有发现的错误
为了识别和纠正软件的错误，改正软件性能上的缺陷，进行诊断和改正错误的过程。

2. 适应性维护

当外部环境发生改变时，为使软件适应这种变化，而去修改软件的过程。

3. 预防性维护

为以后进一步改进软件打下良好的基础
是采用先进的软件工程方法对需要维护的软件或某部分软件重新进行设计，编码和测试，以提高软件的可维护性和可靠性，为以后进一步改进软件打下基础。

4. 完善性维护

在软件维护过程中，用户往往会对软件提出新的功能，性能要求，为了满足这些要求而进行的修改和新功能的开发。

5. 影响软件维护的因素

可维护性是软件开发阶段的关键目标。影响软件可维护性的因素较多。
设计，编码及测试中的疏忽和低劣的软件配置
缺少文档等都将对软件的可维护性产生不良影响。
软件的维护性可以用下面的几个质量属性来衡量：可理解性，可测试性，可修改性，可靠性，可移植性，可使用性和效率。
对于不同的维护，这七种特征的侧重点也不相同。

6. 提高软件可维护性的方法

1. 采用软件工程方法

建立明确的软件质量目标
使用先进的软件开发技术和工具
使用先进的软件开发技术能够大大提高软件质量，减少软件开发成本。
建立明确的质量保证
质量保证不仅使用在软件开发的各个阶段当中得到广泛的应用，而且在软件维护中也是一个非常重要的工具。为保证软件可维护性，以下四类检查是非常有用的：在检查点进行检查，验收检查，周期性的维护检查和对软件包的检查。
选择容易维护的编程语言
低级语言很难掌握，很难理解，因此也不便于维护。一般来说，使用高级语言更容易理解和维护。
改进软件的文档
软件文档是对软件功能，各个组成部分之间的关系，程序设计策略，程序实现过程的历史数据等的说明和补充。软件文档对提高程序的可阅读性有重要的作用，从而会提高软件的可维护性。

2. 注重可维护性开发过程

需求分析阶段
对将来需要改进或可能修改部分予以明确。
设计阶段
高内聚低耦合的原则，可能修改的地方采用易扩展的方案。考虑跨平台移植性设计，加大可复用构件的设计力度。
编码阶段
代码规范，加强注释，加大可复用构件的使用。
测试阶段
测试做好，可减少维护量，测试相关文档是回归测试的基础。
运行维护阶段
严格配置管理，同步更新系统和用户文档保证一致性，加强用户培训。

7. 遗留系统的处置策略

1. 淘汰策略

遗留系统的技术含量较低，且具有较低的业务价值。
对遗留系统的完全淘汰是企业的根本浪费，系统分析师应该要善于变废为宝
对遗留系统功能的理解和借鉴，可以帮助新系统的设计，降低新系统开发的风险。
完全淘汰是一种极端性策略，一般是企业的业务产生了根本变化，遗留系统已经基本上不再适应企业运作的需要
或者是遗留系统的维护人员、维护文档资料都丢失了。经过评价，发现将遗留系统完全淘汰，开发全新的系统比改造旧系统从成本上更合算。

2. 改造策略

高技术水平，高业务价值
这种系统可能建成的时间还比较短，对这种遗留系统的演化策略为改造。
改造包括系统功能的增强和数据模型的改造等两个方面。
系统功能的增强是指在原有系统的基础上增加新的应用要求，对遗留系统本身不做改变
数据模型的改造是指将遗留系统旧的数据模型向新的数据模型的转化。

3. 继承策略

低技术水平，高业务价值
技术含量低，且已经满足企业运作的功能或性能要求，但具有较高的商业价值
目前企业的业务尚紧密依赖该系统。
在开发新系统时，需要完全兼容遗留系统的功能模型和数据模型
为了保证业务的连续性，新老系统必须并行运行一段时间，再逐渐切换到新系统上运行

4. 集成策略

高技术水平，低业务价值
可能只能完成某个部门或者子公司的业务管理。
这种系统在各自的领域里工作良好，但对于整个企业来说，存在多个这样的系统，不同的系统基于不同的平台，不同的数据模型，形成一个个信息孤岛
对这种遗留系统的演化策略为集成比较妥当。

8. 新老系统转换策略

一共有三种转换策略：直接转换策略，并行转换策略和分布转换策略三种。

1）直接转换

直接转换就是在原有系统停止运行的某一时刻，新系统立即投入运行，中间没有过渡阶段。
该方案的风险是最大的。

2）并行转换

并行转换是新系统和现有系统并行工作一段时间，经过这段时间的试运行之后，再用新系统正式替换下现有系统。
并行策略（新旧系统并行转换一段时间再淘汰旧系统）
该策略的风险是最小的。

3）分段转换

分段转换策略也称为逐步转换策略。
这种转换方式是直接转换方式和并行转换方式的结合，采取分期分批逐步转换。

9. 数据迁移的工作内容

待迁移数据源的详细说明，包括数据的存放方式，数据量和数据的时间跨度。
建立新旧系统数据库的数据字典，对现有系统的历史数据进行质量分析，以及新旧系统数据结构的差异分析
新旧系统代码数据的差异分析
建立新旧系统数据库表的映射关系，对无法映射字段的处理方法。
开发或购买，部署ETL工具
编写数据转换测试计划和校验程序
制定数据转换的应急措施

10. 软件调试的三种方法

1. 蛮力法

是为了找到错误原因而使用的最普通但又最低效的方法。
在程序运行时使用各种手段来跟踪程序的运行轨迹，从而找出问题源。

2. 回溯法

经常用于小程序的调试。
从发现问题的地方开始回溯，跟踪源代码直至找到问题源。

3. 原因排除法

通过演绎或归纳并利用二分法来定位问题源。
先根据自己的工作经验假设一个可能的问题源，然后用数据来证明或否定该假设，直到找到问题源。

11. 模块的扇入和扇出

1）扇出

是指该模块直接调用的下级模块的个数，扇出大表示模块的复杂度高，需要控制和协调过多的下级模块。
扇出过大一般是因为缺乏中间层次，应当适当增加中间层次的控制模块。
扇出过小时可以把下级模块进一步分解成若干个子功能模块，或者合并到它的上级模块中去

2）扇入

一个模块的扇入是指直接调用该模块的上级模块的个数。扇入大表示模块的复用程度高。

3）设计方案

适用于结构化开发方法。设计良好的软件结构通常顶层扇出比较大，中间扇出比较小，底层模块则有大扇入。

12. 缺陷排除效率

在项目级和过程级都能提供有益的质量度量。
DRE是对质量保证及控制活动的过滤能力的一个测量。
DRE=E/（E+D）
E—软件交付给最终用户之前所发现的错误数；
D是交付用户之后用户发现的错误数；

13. 模块内聚与模块间耦合

1）模块内聚

内聚表示模块内部各部件之间的联系程度，以下是系统内聚度从高到低的排序。

功能内聚

完成一个单一功能，各个部分协同工作，缺一不可

顺序内聚

处理元素相关，而且必须顺序执行

通信内聚

所有处理元素集中在一个数据结构的区域上

过程内聚

处理元素相关，而且必须按特定的次序执行

瞬时内聚(时间内聚)

所包含的任务必须在同一时间间隔内执行

逻辑内聚

完成逻辑上相关的一组任务

偶然内聚(巧合内聚)

完成一组没有关系或松散关系的任务

2）模块耦合

耦合表示模块之间联系的程度。模块的耦合类型通常可分为7种。以下是系统耦合度排序。

非直接耦合

两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的

数据耦合

一组模块借助参数表传递简单数据

标记耦合

一组模块通过参数表传递记录信息(数据结构)

控制耦合

模块之间传递的信息中包含用于控制模块内部逻辑的信息

外部耦合

一组模块都访问同一全局简单变量而不是同一全局数据结构，而且不是通过参数表传递该全局变量的信息

公共耦合

多个模块都访问同一个公共数据环境，公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等

内容耦合

一个模块直接访问另一个模块的内部数据;一个模块不通过正常入口转到另一个模块的内部;两个模块有一部分程序代码重叠;一个模块有多个入口

三. 测试管理

1. 测试管理主要内容

测试管理包括过程，管理，配置管理和评审三个部分。

1）过程管理

包括测试活动管理和测试资源管理。
根据软件的规模，完整性级别和测试类别，软件测试可由不同的组织来实施。
软件测试人员应该包括有：项目负责人，测试分析员，测试设计员，测试系统管理员和配置管理员。
具体过程有：测试策划，测试设计，测试省实施，测试总结四个部分。

2）配置管理

应按照软件配置管理的要求，将测试过程中产生的各种工作产品纳入配置管理。
应建立软件测试配置库，将被测试的对象和测试工作产品纳入配置管理。

3）评审

软件测试过程中的评审包括有测试就绪评审和测试评审。

1. 测试就绪评审

可以包括评审测试计划的合理性和测试用例的正确性，完整性，测试覆盖的充分性。还有测试环境工具和设备是否齐全。

2. 测试评审

测试评审是在测试完成后，评审测试过程和测试结果的有效性，确定是否达到测试的目的，主要对测试记录和测试报告进行评审。

2. 测试管理过程

1）测试策划

就是进行测试需求分析，包括需要测试的内容或质量特征；
确定测试的充分性要求；
提出测试的基本方法；
确定测试的资源和技术需求，进行风险分析与评估，制定测试计划。

2）测试设计

依据测试的需求，分析并选用已有的测试用例，或设计新的测试用例；
获取并验证测试数据；
根据测试资源，风险等约束条件，确定测试用例执行的顺序；
获取测试资源，开发测试软件；
建立并校准测试环境；
进行测试就绪评审，主要评审测试计划的合理性，测试用例的正确性，测试覆盖的充分性，评审测试组织，环境和设备工具是否齐备并符合要求。

3）执行测试

包括执行测试用例，获取测试结果。分析并判定测试的结果，并根据不同的测试，结果采取不同的措施。
对测试过程的正常或异常终止情况进行核对，并根据核对结果，对未达到测试终止条件的测试用例，决定是停止测试还是需要修改或补充测试用例集，并进一步测试。

4）测试总结

整理和分析测试数据，评价测试的效果。
描述测试状态，评价被测试的软件测试项，完成测试报告，并通过测试评审。

四. 软件重构

1. 重构的概念

重构是对软件内部结构的一种调整
目的是不改变软件功能的前提下，提高其可理解性，降低其修改成本。

2.重构的优点

1）可维护性

重新设计软件结构，能够极大地方便今后的维护；
此外采用软件工程的方法进行重新设计、编码和测试，可以形成完整的软件文档，也便于后续的软件维护

2）可行性

重构前如果拥有该软件开发经验的人，就能够容易地确定新的需求和修改方向；
从代码开发与维护的角度看，重新编写新代码的费用可能远远低于维护现有文档不齐全的代码的费用。
且有目前可以运行的软件作为参照的话，重新开发的生产率将大大高于平均值。

3. 三个种类

代码重构，模块重构，架构重构。

1）代码重构

重新梳理代码流程，使代码容易理解和维护；

2）模块重构与架构重构

梳理模块之间的关系，使其更容易扩展和维护，降低模块之间的耦合度。

4. 重构方法

常见的重构方法有：重新组织函数，重新组织对象，重新组织数据，简化条件表达式，简化函数调用和处理概括关系

5. 重构前遇到的问题

随着时间和人员的变动，程序被多人修改，往往导致程序难以理解，注释混乱，流程复杂；
随着不断修改程序和增加新的功能，模块之间的耦合关系日益复杂，维护成本不断增加。
新来的维护人员需要直接面对大量流程、结构复杂的源程序，维护困难，往往一次改动需要设计大量的软件模块。