静态测试
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
♦ 非正式评审特点 1. 没有正式的评审过程 2. 对设计文档和代码以技术评审为主 3. 评审的过程和结果可能是文档化的 4. 评审的投入少，效率高 5. 评审主要目的是以较低成本即时的
发现问题
上午11时5分
3 正式评审（formal Review）
♦ 正式评审概述 ♦ 正式评审的基本过程 ♦ 正式评审的分类 1. 管理评审 2. 技术评审 3. 审查 4. 走查 5. 审计
上午11时5分
2.4.1.1 从用户的角度看问题举例
♦ 凡是做得好的软件，都需要与用户沟通
药理学实验结果曲线模拟
上午11时5分
2.4.2.2 坚持标准和规范的原因
♦ 坚持符合标准和规范编码的三个重要原因： 1. 可靠性——代码更加可靠，缺陷更少 2. 可读性/维护性——代码易于阅读、理解和维
护 3. 可移植性——代码经常在不同的硬件上运
2 评审领导 评审领பைடு நூலகம்确保完成与评审相关的行政工作，为评审计划和准备 工作负责，他将确保引导评审按照有序的方式进行并达到其目 标，并发布评审结果
assurance plans ）
上午11时5分
2
2.3 评审的软件产品(2)
5. 软件配置管理计划（configuration management plans ）
6. 软件设计描述（design descriptions ） 7. 软件项目管理计划（project
management plans ） 8. 软件用户文档（user documentation ） 9. 软件安全计划（safety plans ） 10. 软件构架描述（architectural
上午11时5分
6
3.2 正式评审的基本过程
♦ 典型的正 式评审阶 段构成：
团队构建 评审准备
指派角色 分配责任
评审输入
个人准备
评审过程
上午11时5分
评审结束 评审跟踪
评审报告
3.3.1 管理评审的成员
序号 角色
1 决策者
职责
决策者是管理评审的管理者，决策者确定是否达到评审目标， 决策者是公司领导，对评审结果进行认定
方面的问题
上午11时5分
2.4.6 评审成功的因素（cont.）
5. 采用的评审技术适合于软件工作产品和 评审参与者
6. 为提高缺陷标识的效率，可以采用检查 列表的方式或定义不同的脚色
7. 提供评审技术方面的培训 8. 管理层对评审过程的支持（安排时间与
资金支持） 9. 强调学习和过程的改进
上午11时5分
上午11时5分
2.4.2 研究现有的标准和规范
♦ 标准比规范更加严格 ♦ 几乎所有产品都需要有参照规范和标
准，比如： 1. 公司惯用语和约定规范 2. 行业要求 3. 国家标准 4. 图形用户界面的标准 5. 硬件和网络标准等
上午11时5分
2.4.2.3 标准和规范的举例
国家标准、行业标准和企业标准
user complaints） 26. 硬件性能计划（Hardware performance
plans） 27. 备份和恢复计划（Backup and recovery
plans） 28. 应变计划（Contingency plans）
上午11时5分
2.3 评审的软件产品(6)
29. 管理评审报告（Management review reports） 30. 技术评审报告（Technical review reports） 31. 审查报告（Inspection reports） 32. 走查报告（Walk-through reports） 33. 审计报告（Audit reports） 34. 进度报告（Progress reports） 35. 异常报告（Anomaly reports）
♦ 以下人员会根据需要出现在不同的正式 评审中
1. 决策者（Decision maker） 2. 管理经理（Management staff） 3. 作者（Author） 4. 顾客或使用者代表（Customer or user
representative） 5. 其他利益相关者（Other stakeholder）
♦ 这种方法简单适用，可以发生在软件开发的任 何时间和地点，也不拘泥于正式的形式，比如 走廊聊天（hallway chat），伙伴测试（buddy test）或者结对编程（pair programming）等。
♦ 优点：方便、廉价、有效，很多程序员都在自 觉不自觉地采用这种评审方式
上午11时5分
2.7 非正式评审的特点
♦ 规格说明（specification）——说明组件/系统 的需求、设计、行为或其他特征的文档，常 常还包括判断是否满足这些条款的方法。
上午11时5分
2.2.1 评审的相关术语（cont.）
♦ 标准（Standard）——（1986年ISO发布的第2 号指南中）得到一致（绝大多数）同意，并经 公认的标准化团体批准，作为工作或工作成果 的衡量准则、规则或特性要求，供（有关各方） 共同重复使用的文件，目的是在给定范围内达 到最佳有序化程度。（与规范相比，标准比较 严格，有些标准带有强制性）
manuals） 22. 发布记录（Release note） 23. 标准、规则、指南和过程（Standards,
regulations, guidelines and procedures）
上午11时5分
2.3 评审的软件产品(5)
24. 合同（Contracts） 25. 客户和用户代表投诉（Customer or
上午11时5分
3.1正式评审概述
♦ 正式评审（formal review）是对评审过 程及需求文档化的一种特定评审
♦ 正式评审的最小可接受条件： 1. 团队参与（Team participation） 2. 文档化评审结果（Documented results
of the review） 3. 文档化实施评审的过程（Documented
上午11时5分
4
2.4.3 审查和测试同类软件
♦ 了解软件最终结果的最佳方法是研究同 类软件，例如竞争对手的同类产品
♦ 审查竞争对手的产品需要注意的问题：
– 软件规模 – 软件的复杂性 – 软件的可测试性
上午11时5分
2.4.3.1 审查和测试同类软件举例1
澳大利亚AD公司的信号采集系统
上午11时5分
validation ） 16. 采购合同方法（Procurement and contracting
methods） 17. 安装计划（Installation plans） 18. 安装过程（Installation procedures）
上午11时5分
2.3 评审的软件产品(4)
19. 维护手册（Maintenance manuals） 20. 维护计划（Maintenance plans） 21. 操作及用户手册（Operations and user
2.4.3.2 审查和测试同类软件举例2
上午11时5分
中国的BL系列信号采集系统
2.4.6 评审成功的因素
♦ 要确保评审成功，如下因素很重要： 1. 每次评审都有非常明确的目标 2. 针对评审目标，有合适的评审人员参与 3. 对发现的缺陷持欢迎态度，并客观的描
述缺陷 4. 能够正确处理人员之间的问题以及心理
行，或者使用不同的编译器，如果代码遵循 设备标准，将更容易使软件具有移植性 ♦ 软件审查小组在开始审查前需要了解相应的 标准和规范
上午11时5分
2.4.2.4 符合标准和规范的要求
♦ 软件测试员要检查新设计的软件是否符合正 确的标准，有无遗漏，是否和某些标准有抵 触。
♦ 比如，软件界面是否符合Windows程序的通 用要求；采用的网络协议是否为通用网络协 议；针对民航（要求采用Unix操作系统）、 军队或政府部门的项目（要求极高的保密性） 是否符合这些行业的要求等
♦ 规范（Specification）——某一范畴内以明文 规定或约定俗成的形式规定的规则
上午11时5分
2.3 评审的软件产品(1)
♦ 软件产品（Software product）是指与 软件相关的全部文档、源代码及标准等
♦ 评审的软件产品包括 ：
1. 需求建议（Request for proposal） 2. 软件需求说明（requirements specifications ） 3. 风险管理计划（Risk management plans） 4. 软件质量保证计划（Software quality
procedures for conducting the review）
上午11时5分
3.1.1正式评审的脚色
♦ 参与正式评审的人员会因评审的内容不 同而有差异，包括：
1. 评审领导（Review leader） 2. 评审员（Reviewer） 3. 记录员（Recorder）
上午11时5分
3.1.1正式评审的脚色
软件产品或软件过程被呈现给工程人员、 管理者、使用者、用户、使用者代表、 审计人员或其他感兴趣的人员进行检查、 评价或建议
上午11时5分
2.2 评审的相关术语
♦ 异常（anomaly）——任何与需求规格说明 书、设计文档、用户文档、标准或者人们的 感觉和经验所希望的相偏离的状态。异常可 能在评审、测试、分析、编辑或者软件的使 用中被发现
上午11时5分
2.4 评审的依据
♦ 评审的依据包括： 1. 从用户的角度看问题 2. 研究现有的标准和规范 3. 审查和测试同类软件
上午11时5分
3
2.4.1 从用户的角度看问题
♦ 软件产品的目的是满足用户要求 ♦ 测试员在审查软件产品时把自己当作
用户来考虑问题，通过与销售人员和 客户的交流来了解产品 ♦ 另外，测试员具有软件应用的领域知 识，比如财务知识，医学知识，航空 知识等，对于软件需求的审查将大有 裨益
2.5评审的分类
非
正
♦ 根据IEEE Std
式 评
1028-2008 软件
审
评审与审计标 评 准，按照评审过 审
程的正式程度、
严格程度可以将
正 式
评审分为非正式
评 审
评审和正式评审
上午11时5分
桌面审查 走廊聊天 伙伴测试 结队编程
管理评审 技术评审
审查 走查 审计
5
2.6 非正式评审
♦ 非正式评审（informal review）是一种不基于 正式（文档化）过程的评审
上午11时5分
1.2.1 提示
♦ 静态测试不仅具有更长的生命周期，而 且由于其大多数情况下是对软件系统高 层次的测试评审，能够在软件开发的早 期找出软件缺陷，更能体现测试的经济 学原则
上午11时5分
1
1.3 静态测试的重要性
♦ 发现设计的方向性问题 ♦ 更早的发现问题 ♦ 避免杀虫剂现象 ♦ 引起程序设计人员的重视 ♦ 静态测试可以训练程序员
上午11时5分
2. 评审概述
♦ 评审概述 ♦ 评审的相关术语 ♦ 评审的软件产品 ♦ 评审的依据 ♦ 评审成功的因素 ♦ 评审的分类
上午11时5分
2.1 评审的概念
♦ 评审（review）是指对产品或产品状态 进行评估，以确定与计划的结果所存在 的误差，并提供改进建议
♦ 评审是主要的静态测试技术 ♦ 评审是一个过程或会议，在此期间一个
静态测试
软件需求
软件设计
编码
软件测试
静态测试具有更长的测试周期 动态测试
上午11时5分
上午11时5分
1.1静态测试和动态测试的概念
♦ 软件测试可以分为静态测试和动态测试 1. 静态测试（static testing）——对组件/
系统进行规格或实现级别的测试，而不 是执行这个软件。比如代码评审 2. 动态测试（dynamic testing）——通过 运行软件的组件或系统来测试软件
descriptions ）
上午11时5分
2.3 评审的软件产品(3)
11. 源代码（Source code） 12. 系统构建过程（System build procedures） 13. 供应商文档（Vendor documents） 14. 软件测试文档（test documentation ） 15. 软件验证和确认计划（verification and
静态测试
Static Testing
提纲
♦ 静态测试概述 ♦ 评审
上午11时5分
1. 静态测试概述
♦ 静态测试和动态测试的概念 ♦ 为什么需要静态测试 ♦ 静态测试的重要性
上午11时5分
1.2 为什么需要静态测试
♦ 狭隘的软件测试思想只对可运行的软件 进行测试，广义的软件测试思想是将测 试遍布于软件开发生命周期的各个阶 段，包括软件需求、软件设计、软件编 码、软件测试及软件维护等阶段
发现问题
上午11时5分
3 正式评审（formal Review）
♦ 正式评审概述 ♦ 正式评审的基本过程 ♦ 正式评审的分类 1. 管理评审 2. 技术评审 3. 审查 4. 走查 5. 审计
上午11时5分
2.4.1.1 从用户的角度看问题举例
♦ 凡是做得好的软件，都需要与用户沟通
药理学实验结果曲线模拟
上午11时5分
2.4.2.2 坚持标准和规范的原因
♦ 坚持符合标准和规范编码的三个重要原因： 1. 可靠性——代码更加可靠，缺陷更少 2. 可读性/维护性——代码易于阅读、理解和维
护 3. 可移植性——代码经常在不同的硬件上运
2 评审领导 评审领பைடு நூலகம்确保完成与评审相关的行政工作，为评审计划和准备 工作负责，他将确保引导评审按照有序的方式进行并达到其目 标，并发布评审结果
assurance plans ）
上午11时5分
2
2.3 评审的软件产品(2)
5. 软件配置管理计划（configuration management plans ）
6. 软件设计描述（design descriptions ） 7. 软件项目管理计划（project
management plans ） 8. 软件用户文档（user documentation ） 9. 软件安全计划（safety plans ） 10. 软件构架描述（architectural
上午11时5分
6
3.2 正式评审的基本过程
♦ 典型的正 式评审阶 段构成：
团队构建 评审准备
指派角色 分配责任
评审输入
个人准备
评审过程
上午11时5分
评审结束 评审跟踪
评审报告
3.3.1 管理评审的成员
序号 角色
1 决策者
职责
决策者是管理评审的管理者，决策者确定是否达到评审目标， 决策者是公司领导，对评审结果进行认定
方面的问题
上午11时5分
2.4.6 评审成功的因素（cont.）
5. 采用的评审技术适合于软件工作产品和 评审参与者
6. 为提高缺陷标识的效率，可以采用检查 列表的方式或定义不同的脚色
7. 提供评审技术方面的培训 8. 管理层对评审过程的支持（安排时间与
资金支持） 9. 强调学习和过程的改进
上午11时5分
上午11时5分
2.4.2 研究现有的标准和规范
♦ 标准比规范更加严格 ♦ 几乎所有产品都需要有参照规范和标
准，比如： 1. 公司惯用语和约定规范 2. 行业要求 3. 国家标准 4. 图形用户界面的标准 5. 硬件和网络标准等
上午11时5分
2.4.2.3 标准和规范的举例
国家标准、行业标准和企业标准
user complaints） 26. 硬件性能计划（Hardware performance
plans） 27. 备份和恢复计划（Backup and recovery
plans） 28. 应变计划（Contingency plans）
上午11时5分
2.3 评审的软件产品(6)
29. 管理评审报告（Management review reports） 30. 技术评审报告（Technical review reports） 31. 审查报告（Inspection reports） 32. 走查报告（Walk-through reports） 33. 审计报告（Audit reports） 34. 进度报告（Progress reports） 35. 异常报告（Anomaly reports）
♦ 以下人员会根据需要出现在不同的正式 评审中
1. 决策者（Decision maker） 2. 管理经理（Management staff） 3. 作者（Author） 4. 顾客或使用者代表（Customer or user
representative） 5. 其他利益相关者（Other stakeholder）
♦ 这种方法简单适用，可以发生在软件开发的任 何时间和地点，也不拘泥于正式的形式，比如 走廊聊天（hallway chat），伙伴测试（buddy test）或者结对编程（pair programming）等。
♦ 优点：方便、廉价、有效，很多程序员都在自 觉不自觉地采用这种评审方式
上午11时5分
2.7 非正式评审的特点
♦ 规格说明（specification）——说明组件/系统 的需求、设计、行为或其他特征的文档，常 常还包括判断是否满足这些条款的方法。
上午11时5分
2.2.1 评审的相关术语（cont.）
♦ 标准（Standard）——（1986年ISO发布的第2 号指南中）得到一致（绝大多数）同意，并经 公认的标准化团体批准，作为工作或工作成果 的衡量准则、规则或特性要求，供（有关各方） 共同重复使用的文件，目的是在给定范围内达 到最佳有序化程度。（与规范相比，标准比较 严格，有些标准带有强制性）
manuals） 22. 发布记录（Release note） 23. 标准、规则、指南和过程（Standards,
regulations, guidelines and procedures）
上午11时5分
2.3 评审的软件产品(5)
24. 合同（Contracts） 25. 客户和用户代表投诉（Customer or
上午11时5分
3.1正式评审概述
♦ 正式评审（formal review）是对评审过 程及需求文档化的一种特定评审
♦ 正式评审的最小可接受条件： 1. 团队参与（Team participation） 2. 文档化评审结果（Documented results
of the review） 3. 文档化实施评审的过程（Documented
上午11时5分
4
2.4.3 审查和测试同类软件
♦ 了解软件最终结果的最佳方法是研究同 类软件，例如竞争对手的同类产品
♦ 审查竞争对手的产品需要注意的问题：
– 软件规模 – 软件的复杂性 – 软件的可测试性
上午11时5分
2.4.3.1 审查和测试同类软件举例1
澳大利亚AD公司的信号采集系统
上午11时5分
validation ） 16. 采购合同方法（Procurement and contracting
methods） 17. 安装计划（Installation plans） 18. 安装过程（Installation procedures）
上午11时5分
2.3 评审的软件产品(4)
19. 维护手册（Maintenance manuals） 20. 维护计划（Maintenance plans） 21. 操作及用户手册（Operations and user
2.4.3.2 审查和测试同类软件举例2
上午11时5分
中国的BL系列信号采集系统
2.4.6 评审成功的因素
♦ 要确保评审成功，如下因素很重要： 1. 每次评审都有非常明确的目标 2. 针对评审目标，有合适的评审人员参与 3. 对发现的缺陷持欢迎态度，并客观的描
述缺陷 4. 能够正确处理人员之间的问题以及心理
行，或者使用不同的编译器，如果代码遵循 设备标准，将更容易使软件具有移植性 ♦ 软件审查小组在开始审查前需要了解相应的 标准和规范
上午11时5分
2.4.2.4 符合标准和规范的要求
♦ 软件测试员要检查新设计的软件是否符合正 确的标准，有无遗漏，是否和某些标准有抵 触。
♦ 比如，软件界面是否符合Windows程序的通 用要求；采用的网络协议是否为通用网络协 议；针对民航（要求采用Unix操作系统）、 军队或政府部门的项目（要求极高的保密性） 是否符合这些行业的要求等
♦ 规范（Specification）——某一范畴内以明文 规定或约定俗成的形式规定的规则
上午11时5分
2.3 评审的软件产品(1)
♦ 软件产品（Software product）是指与 软件相关的全部文档、源代码及标准等
♦ 评审的软件产品包括 ：
1. 需求建议（Request for proposal） 2. 软件需求说明（requirements specifications ） 3. 风险管理计划（Risk management plans） 4. 软件质量保证计划（Software quality
procedures for conducting the review）
上午11时5分
3.1.1正式评审的脚色
♦ 参与正式评审的人员会因评审的内容不 同而有差异，包括：
1. 评审领导（Review leader） 2. 评审员（Reviewer） 3. 记录员（Recorder）
上午11时5分
3.1.1正式评审的脚色
软件产品或软件过程被呈现给工程人员、 管理者、使用者、用户、使用者代表、 审计人员或其他感兴趣的人员进行检查、 评价或建议
上午11时5分
2.2 评审的相关术语
♦ 异常（anomaly）——任何与需求规格说明 书、设计文档、用户文档、标准或者人们的 感觉和经验所希望的相偏离的状态。异常可 能在评审、测试、分析、编辑或者软件的使 用中被发现
上午11时5分
2.4 评审的依据
♦ 评审的依据包括： 1. 从用户的角度看问题 2. 研究现有的标准和规范 3. 审查和测试同类软件
上午11时5分
3
2.4.1 从用户的角度看问题
♦ 软件产品的目的是满足用户要求 ♦ 测试员在审查软件产品时把自己当作
用户来考虑问题，通过与销售人员和 客户的交流来了解产品 ♦ 另外，测试员具有软件应用的领域知 识，比如财务知识，医学知识，航空 知识等，对于软件需求的审查将大有 裨益
2.5评审的分类
非
正
♦ 根据IEEE Std
式 评
1028-2008 软件
审
评审与审计标 评 准，按照评审过 审
程的正式程度、
严格程度可以将
正 式
评审分为非正式
评 审
评审和正式评审
上午11时5分
桌面审查 走廊聊天 伙伴测试 结队编程
管理评审 技术评审
审查 走查 审计
5
2.6 非正式评审
♦ 非正式评审（informal review）是一种不基于 正式（文档化）过程的评审
上午11时5分
1.2.1 提示
♦ 静态测试不仅具有更长的生命周期，而 且由于其大多数情况下是对软件系统高 层次的测试评审，能够在软件开发的早 期找出软件缺陷，更能体现测试的经济 学原则
上午11时5分
1
1.3 静态测试的重要性
♦ 发现设计的方向性问题 ♦ 更早的发现问题 ♦ 避免杀虫剂现象 ♦ 引起程序设计人员的重视 ♦ 静态测试可以训练程序员
上午11时5分
2. 评审概述
♦ 评审概述 ♦ 评审的相关术语 ♦ 评审的软件产品 ♦ 评审的依据 ♦ 评审成功的因素 ♦ 评审的分类
上午11时5分
2.1 评审的概念
♦ 评审（review）是指对产品或产品状态 进行评估，以确定与计划的结果所存在 的误差，并提供改进建议
♦ 评审是主要的静态测试技术 ♦ 评审是一个过程或会议，在此期间一个
静态测试
软件需求
软件设计
编码
软件测试
静态测试具有更长的测试周期 动态测试
上午11时5分
上午11时5分
1.1静态测试和动态测试的概念
♦ 软件测试可以分为静态测试和动态测试 1. 静态测试（static testing）——对组件/
系统进行规格或实现级别的测试，而不 是执行这个软件。比如代码评审 2. 动态测试（dynamic testing）——通过 运行软件的组件或系统来测试软件
descriptions ）
上午11时5分
2.3 评审的软件产品(3)
11. 源代码（Source code） 12. 系统构建过程（System build procedures） 13. 供应商文档（Vendor documents） 14. 软件测试文档（test documentation ） 15. 软件验证和确认计划（verification and
静态测试
Static Testing
提纲
♦ 静态测试概述 ♦ 评审
上午11时5分
1. 静态测试概述
♦ 静态测试和动态测试的概念 ♦ 为什么需要静态测试 ♦ 静态测试的重要性
上午11时5分
1.2 为什么需要静态测试
♦ 狭隘的软件测试思想只对可运行的软件 进行测试，广义的软件测试思想是将测 试遍布于软件开发生命周期的各个阶 段，包括软件需求、软件设计、软件编 码、软件测试及软件维护等阶段