东北大学——软件需求分析与系统设计——第九章笔记整理(2020年5月整理)
全九章节的笔记导航目录:其他剩余章节目录
全笔记PDF版下载链接:下载链接
本章目录
一、质量管理
(一)软件的质量
1.质量管理
- 质量管理与人员管理、风险管理以及变更管理等活动属于整个软件过程管理的一部分
- 质量管理包括人员管理,风险管理,变更管理等
2.项目管理
- 可以和质量管理并行执行,如项目进度计划、预算估算、项目进度跟踪
3.软件质量的目标
- 正确性(Correctness)
- 可靠性(Reliability)
- 健壮性(Robustness)
- 性能(Performance)
- 可用性(Usability)
-
适应性
- 易懂性(Understandability)——说明文档,程序注释
- 可维护性(Maintainability)
- 可伸缩性(可扩展性)(Scalability / Evolvability)
- 可复用性(Reusability)——软件接口定义的合理性
- 可携带性(Portability)
- 协同工作的能力(Interoperability)
- 生产力(Productivity)
- 时效性(Timeliness)
- 可视性(Visibility)
(二)质量保证(Quality Assurance)
1.质量保证的定义
- 将质量构建到软件系统中的主动方法,采用主动的方式来建造有质量的软件系统
- 标准
- 在开发软件时,把质量构建在软件内,使软件尽量不出错
- 软件质量保证小组(SQA team)——小组成员不是最初的开发人员
2.使用的技术
- 检查表(Checklist)
- 在开发过程中需要仔细检查的预定义的待办事项列表
- 过程因项目而异——检查表不能永远固定
- 需要修改“基线”检查列表,以适应新的IT技术和IT开发范式中的变化
- 评审(Reviews)
- 评审是一种手工形式的测试
- 目的:评审一个工作产品或过程
- 走查(Walkthroughs)
- 可以在任何开发阶段进行的一种正式的头脑风暴评审
- 一个由开发者组成的友好会议,精心策划,目标明确,议程明确,会期明确,成员明确
- 在会议前几天,与会者将收到要审查的材料
- 在会议期间,仅需要找出问题,不试图解决
- 已确认的问题将输入到走查问题列表中
- 开发人员使用该列表对已评审的软件产品或过程进行更正
- 后续走查可能是必要的
- 审查(Inspections)
- 友好的会议,在项目管理人员的密切监督下进行
- 找出所有故障并验证,然后记录这些故障,并安排何时,由谁完成这些故障的修正。
- 识别缺陷,验证它们实际上是缺陷,记录它们,并计划何时以及由谁来修复它们
- 与走查不同,审查不太频繁,次数较少,只针对选定的关键问题,更正式、更严格(rigorous)
- 在会议期间,这些故障(defects)被识别、记录和编号
- 会议结束后,主持人立即准备在变更管理工具中记录的缺陷日志
- 开发人员通常被要求快速解决缺陷,并在变更管理工具中记录解决方案
- 主持人(moderator)在与项目经理协商后,将开发模块提交给组织中的SQA
- 审核 / 审计(Audits)
- 一种质量保证过程,以传统的会计审计为模型,在所需资源方面与之相似
- 一般在项目开始之前/之后审计
- 定位在整个软件过程管理
- 它将风险管理放在自己的观点中
- 它与IT对企业的战略重要性相关,并解决IT治理问题
- 它在企业使命和业务目标的上下文中查看被审计项目与IT投资的一致性
- 审计与其他技术的区别
- 被审核产品或过程的生产者通常是一个团队而不是个人
- 审核时生产者可以不在场
- 审核需要的检查表比会议和评审要多
- 审核可以是外部的,由组织外的审核者完成
- 审核可持续一天到一个星期或更长的时间,但始终围绕严格定义的范围和目标
- 测试驱动开发(Test driven development)
- 思想——在开发应用程序代码之前编写测试用例和脚本以及测试程序
- 应用程序代码是作为对测试代码的响应编写的,测试代码可用来测试应用程序代码
- 优点
- 允许在程序员编写应用程序代码的第一行之前澄清用户需求(和用例规范)
- 驱动实际上是软件开发,而不仅仅是软件验证
- 由测试框架(如JUnit)支持
(三)质量控制(Quality Control)
1.质量控制的定义
- 测试软件系统质量的方法,采用(大部分被动)方式来测试软件系统的质量
- 主要的软件测试活动,跨越了整个系统开发生命周期
- 发现软件中潜在的错误
2.质量控制和质量保证的对比
- 质量保证是为了建造有质量的软件产品或过程,而质量控制是为了测试软件产品或过程的质量。
- 质量保证主动,质量控制被动
- 质量保证策略级,质量控制战术级或操作级
3.测试概念与技术
- 为了进行测试,必须采用测试脚本的形式来实现测试用例
- 测试用例规定了判定一个软件产品是否满足其测试需求所需的步骤和验证点
- 可将多个测试脚本的组合成较大的测试集
- 人工测试和自动化测试
- 人工测试——由真实的测试人员进行,要完整地执行被测试地单元,然后观察测试结果
-
自动化测试——由虚拟的测试人员完成,是一个捕获/回放工具,广泛应用于回归测试
- 回归测试——在不断的代码迭代后重新执行相关的验收测试
- 回归测试的目的——保证对代码的迭代补充不会产生非故意的副作用
4.测试系统服务
- 非正式的(Informal)系统服务测试
- 基于方法的(Methodical)系统服务测试
- 静态测试(Non-execution-based)——正式的评审
- 走查
- 审查
- 动态测试
- 针对规格说明的测试
- 也称为黑盒测试,功能测试和输入/输出驱动测试
- 有利于找出其他方法一般难以发现的故障,尤其是可以找出遗漏的功能
- 针对代码的测试
- 也称为白盒测试,玻璃盒测试、逻辑驱动测试和面向路径的测试
- 针对规格说明的测试
- 集成测试
- 静态测试(Non-execution-based)——正式的评审
5.测试系统约束
- 用户界面测试
- 数据库测试
- 权限测试
- 性能测试
- 压力测试
- 容错测试
- 配置测试
- 安装测试
二、变更管理
(一)工具与管理变更需求
1.提交变更请求
- 变更请求要么是修正一个故障,要么是进行一次改进
- 管理变更需要变更请求管理工具
2.追踪变更请求
- 变更请求时为了可追溯
(二)可追踪性(Traceability)
1.可追踪性的定义
- 是测试和变更管理的基础
- 目的——捕获、链接和追踪每一个重要的开发制品,包括需求
- 最终目的——保证整个文件集中各种文档和模型的正确性和一致性
2.成本—效益分析
- 追踪、测试或变更管理会显著增加项目的成本,但不管理的话会显著增加长期成本
- 采用成本-效益分析技术来确定项目追踪的范围和深度