【系统分析师之路】第八章 系统测试与维护（视频笔记）

【系统分析师之路】第八章 系统测试与维护（视频笔记）

软件测试的概念和方法（★★）
系统测试（★★★★）
软件开发环境与工具（★）
可维护性因素（★★★）
系统运行与评价（★★★）
　系统转换计划
　软件维护
　系统审计
　系统评价

• 软件测试的概念和方法（★★）

尽早不断地进行测试 程序员应避免测试自己设置的程序。
既要选择有效合理的数据，也要选择无效不合理的数据
修改后应进行回归测试 尚未发现的错误数量与已发现的错误数量成正比

动态测试：黑盒测试，白盒测试，灰盒测试
静态测试：桌前检查，代码审查，代码走查
其中黑盒测试法又分为四种：等价类划分，边界值分析，错误推测，因果图。一般先划分等价类再在此基础上进行边界值分析。
白盒测试法分为基本路径测试，循环覆盖测试，逻辑覆盖测试三种。
逻辑覆盖包含了语句覆盖，判定覆盖，条件覆盖，条件判定覆盖，条件组合覆盖，点覆盖，边覆盖，路径覆盖。
判定覆盖：每个菱形的真假条件都得要覆盖一次。 达成共识的测试划分方法：单元测试，集成测试，确认测试，系统测试四种。确认测试和系统测试的先后顺序是不一定的。
集成测试包括：一次性组装和增量式组装测试。增量式组装测试成本高，但是测试的效果与质量会更好。增量式组装测试分为自顶向下，自底向上和混合式三种方式。
监理方的测试也归属于确认测试，因为监理方可代表甲方进行测试。比如甲方专业性不高时，可委托监理方作确认测试。
而确认测试又包括了阿尔法测试，beta测试，内部确认测试和验收测试。

• 系统测试（★★★★）

系统测试：包括功能方面，性能方面，可用性方面，安全方面的测试。它是一个大杂烩。
系统测试包括了恢复测试，安全性测试，压力测试，性能测试，可靠性测试，可用性测试，可维护性测试，安装测试。
容量测试：往往是在对资源限制的条件下看同时能够容纳的并发的测试。最大并发能够达到什么样一个程度。
负载测试：各种负载情况下表现出来的性能指标。
压力测试：直到你被压垮的临界值。找出什么样的压力下是无法承受的。
强度测试：为了实现1000人并发，不断调低临界点，让系统不能够正常运行。强度测试就是去寻找这种临界点。
冒烟测试：大致初步的进行测试。
面向对象测试：

层次	层级	说明
算法层	单元测试	包括等价类划分测试，组合功能测试，基于判定表的测试，递归函数测试，多态消息测试
类层	模块测试	包括不变式边界测试，模态类测试和非模态类测试
模版层/类树层	集成测试	包括多态服务测试和展平测试。
系统层	系统测试	⁻

• 软件测试的概念和方法--自动化测试

能够做到的： 提高测试执行的速度 提高运行效率 保证测试结果的准确性 连续运行测试脚本 模拟现实环境下受约束的情况
自动化测试不能做到的： 所有测试活动都可以自动完成 减少人力成本 可以免费获得 降低测试工作量。

• 软件测试的概念和方法--软件调试的方法

蛮力法；主要思想是通过计算机找错；低效耗时； 回溯法；从出错处人工沿控制流程往回追踪，直至发现出错的根源。复杂程序由于回溯路径多，难以实施。 原因排除法；主要思想是演绎和归纳，用二分法实现。

软件调试与软件测试的区别：

No	测试	调试
1.目的	找出存在的错误	定位错误并修改程序以修正错误
2.实施时点	一般在调式之前进行测试	调试是测试之后的活动
3.开始条件	测试从一个已知的条件开始，使用预先定义的过程，有预知的结果	调试从一个未知条件开始，结束的过程不可预计
4.过程	可以事先设计，进度可以事先确定	不能描述过程或持续时间。

• 系统运行与评价--系统转换计划

遗留系统演化策略由四个策略所组成，分别分布在四个象限中。

集成策略	高技术水平，低业务价值	可能只能完成某个部门或子公司的业务管理。这种系统在各自的领域里工作良好，但对于整个企业来说，存在多个这样的系统，不同的系统基于不同的平台，不同的数据模型，形成一个个信息孤岛，对这种遗留系统的演化策略为集成。
改造策略	高技术水平，高业务价值	这种系统可能建成的时间还很短，对这种遗留系统的演化策略为改造。改造包括系统功能的增强和数据模型的改造两个方面。系统功能的增强是指在原有系统的基础上增加新的应用要求，对遗留系统本身不做改变，数据模型的改造是指将遗留系统旧的数据模型向新的数据模型的转化。
淘汰策略	低技术水平，低业务价值	遗留系统的技术含量较低，且具有较低的业务价值。对遗留系统的完全淘汰是企业资源的根本浪费，系统分析师应该善于变废为宝，通过对遗留系统功能的理解和借鉴，可以帮助新系统的设计，降低新系统开发的风险。
继承策略	低技术水平，高业务价值	技术含量低，且已经满足企业运作的功能或性能要求，但具有较高的商业价值，目前企业的业务尚紧密依赖该系统。对这种遗留系统的演化策略为继承，在开发新系统时，需要完全兼容遗留系统的功能模型和数据模型。为了保证业务的连续性，新老系统必须并行运行一段时间，再逐渐切换到新系统上运行。

新旧系统的转换策略一共有三种：直接转换策略，并行转换策略，分段转换策略。
数据转换与迁移包括了数据抽取，数据转换和数据装载等三个步骤。 1.系统切换前通过工具迁移 2.系统切换前采用手工录入 3.系统切换后通过新系统生成

• 系统运行与评价--软件维护

软件维护是生命周期的一个完整部分，可以将软件维护定义为需要提供软件支持的全部活动，这些活动包括在交付前完成的活动，以及交付后完成的活动。交付前完成的活动包括交付后运行的计划和维护计划；交付后的活动包括软件修改，培训，帮助资料。
可维护性可以细分为：易分析性，易改变性，易测试性

软件的维护并不只是修正错误，为了满足用户提出的增加新功能，修改现有功能以及一般性的改进要求和建议，需要进行完善性维护，他是软件维护的重要组成部分。 软件测试不可能揭露旧系统中所有潜在的错误，所以这些程序在使用过程中还可能发生错误，诊断和更正这些错误的过程称为改正性维护。 为了改进软件未来的可维护性或可靠性，或者给未来的改进提供更好的基础而对软件进行修改，这类活动称为预防性维护。

维护类型	占比	特点	详细定义
改正性维护	25%	修正Bug	指改正在系统开发阶段已发生而系统测试阶段尚未发现的错误。
适应性维护	20%	环境变化	指使应用软件适应信息技术变化和管理需求变化而进行的修改。企业的外部市场环境和管理需求的不断变化也使得各级管理人员不断提出新的信息需求
预防性维护	5%	针对未来	扩充功能和改善性能而进行的修改。对已有的软件系统增加一些在系统分析和设计阶段中没有规定的功能与性能特征。
完善性维护	50%	功能增加，性能增强	为了改进应用软件的可靠性和可维护性，为了适应未来的硬件环境变化，应主动增加预防性的新的功能，以使系统适应各类变化而不被淘汰。如将专用报表功能改成通用报表功能，以适应将来报表格式的变化。

被动调整是适应性维护，为了更好的适应而进行的主动调整是预防性维护，它是锦上添花的维护。增加功能，改进某某功能，改善某某算法就是完善性维护。 重构代码，改善代码通用性是使系统的适应性更强，它属于预防性维护。 适应性维护是必须要做的维护，因为它已经出错了。 可维护性往往需要在项目开发的早期就应该去考虑。 在2000年之前对应千年虫问题就属于预防性维护，而在2000年之后发生了千年虫病毒，就是改正性维护了。 

• 系统运行与评价--系统审计

在项目执行过程之中可以进行审计，事后也可以进行审计，审计一般由第三方进行。 

• 系统运行与评价--软件评审

软件评审包括了技术评审和管理评审
不应该以测试代替评审
评审人员应关注产品而不应评论开发人员
评审人员应关注于实质性的问题
评审会议不应变为问题解决方案讨论会
评审应该被安排进入项目计划
评审参与者应了解整个评审的过程
评审人员事先应对评审材料充分了解 
应重视评审的组织工作

• 系统运行与评价--验证与确认 

验证	在软件开发周期中的一个给定阶段的产品是否已经达到在上一个阶段确立的需求的过程。
确认	在软件开发过程结束时对软件进行评价以确定他是否和软件需求相一致的过程。
测试	通过执行程序来有意识的发现程序中的设计错误和编码错误的过程。测试是验证和确认的手段之一。

• 系统运行与评价--系统评价

系统性能评价，系统效益评价，系统建设评价 
确定评价对象，下达评价通知书，组织成立评价工作组，专家咨询组 
拟定评价工作方案，收集基础资料 评价工作组实施评价，征求专家意见和反馈给企业，撰写评价报告
评价工作组将评价报告报送专家咨询组复核，向委托人送达评价报告，选择公布评价结果，建立评价项目档案。 

• 系统运行与评价--软件过程改进CMMI

它由持续式软件过程能力和阶段式组织能力成熟度两部分组成。

阶段式组织能力成熟度
成熟度等级	过程域
已管理级	需求管理，项目计划，配置管理，项目监督与控制，供应商合同管理，度量和分析，过程和产品质量保证
已定义级	需求开发，技术解决方案，产品集成，验证，确认，组织级过程焦点，组织级过程定义，组织级培训，集成项目管理，风险管理，集成化团队，决策分析和解决方案，组织级集成环境
定量管理级	组织级过程性能，定量项目管理
优化级	组织级改革与实施，因果分析和解决方案

持续式软件过程能力
连续式分组	过程域
过程管理	组织级过程焦点，组织级过程定义，组织级培训，组织级过程性能，组织级改革与实施
项目管理	项目计划，项目监督与控制，供应商合同管理，集成项目管理，风险管理，集成化团队，定量项目管理
工程	需求管理，需求开发，技术解决方案，产品集成，验证，确认
支持	配置管理，度量与分析，过程和产品质量保证，决策分析和解决方案，组织级集成环境，因果分析和解决方案