软件测试笔记

第一章 测试基础和缺陷管理
1、软件测试的定义和目的
定义：使用人工和自动化手段来运行或测试某个系统的过程
目的：检验它是否满足规定的需求或弄清预期结果与实际结果之间的区别
认识过程：证明（60年代）——检测（70年代中期）——预防（90年代）
2、软件测试观念的转变
类型 传统测试 现在测试
介入阶段 开发后期 整个生命周期
范围 基于代码 静态范畴
目的 发现错误 错误预防

3、测试的主要工作
1. 评审SRS
2. 制定计划和方案
3. 编写及评审用例
4. 搭建测试环境，准备数据
5. 执行测试，发现缺陷，提交缺陷报告，回测记录的缺陷
6. 分析测试结果，编写测试报告，度量软件质量
7. ……
4、测试用例
指对一项特定的软件产品测试任务的描述，体现测试方案、方法、技术和策略。
5、软件发展历史
程序设计阶段（50~60年代中期）、程序系统阶段（60年代中期~70年代中期）、软件工程阶段（70年代中期之后）
6、软件危机
主要表现：
1. 缺乏大型软件开发经验和软件开发数据积累，开发工作计划很难制定
2. 开发早期需求分析不明确，后期矛盾集中暴露
3. 不遵循开发规范，开发文档不完整，软件难以维护
4. 缺乏软件质量检查手段
根源：
1. 硬件发展越快，软件系统的期望越高
2. 软件系统的复杂性提高，需多人合作
3. 软件开发无法用已有的产业工程方法来管理
解决方法：A.软件工程 B.研究新的软件设计技术
7、软件生命周期
计划、需求分析、设计、编码、测试、运行和维护
8、软件研发三要素
人员、过程、工具
9、软件项目组人员
分析人员、设计人员、开发人员、测试人员、配置管理人员（CMO）、软件质量保证（SQA）
QA:检验产品的质量，保证产品符合客户的需求；是产品质量检查者
QC:审计过程的质量，保证过程被正确执行；是过程质量审计者
10、基本软件研发流程
瀑布模型 螺旋模型 RUP流程 IPD流程
概述 应用最广泛、缺陷也显而易见 综合了基本的瀑布式模型和演化/渐增原型方法 所有工作流在各个阶段都有体现 从整个产品角度出发，不仅仅针对研发

优点
简单高效
充分考虑风险，抗风险能力强 1.针对大型复杂的系统，进行逐步完善，降低了实施复杂度
2.用户可在早期提出变更并进行修复，从而有效控制变更风险及代价
3.可在早期增强用户的信心 1.将软硬件研发及生产、销售等各个部门有效整合，集中在一个平台下统一管理，提高了决策的准确性及时效性
2．有利于各部门关键数据的共享
缺点 测试介入晚，人员闲置严重，后续工作跟不上 成本高，需专业的风险分析专家参与 1.要有专业的架构师
2.已确定的功能不能变更 1.管理成本高
2.部门之间的协调关系较复杂
适用 不适合需求频繁变更的项目、大项目，适合小规模传统项目 与生命财产相关的系统 大型复杂的项目，耦合度较低的系统，当功能与功能之间联系太紧密就不适用 大型软硬件集成厂商
RUP流程：
IPD流程：集成产品开发流程
11、主要软件研发过程
需求管理、配置管理、缺陷管理、同行评审
12、软件缺陷
定义：是对软件产品预期属性的偏离现象
BUG： 缺陷的一种表现形式
其他相关术语：
错误：编写错误的代码，导致软件包含故障的人的行为，包含逻辑错误和语法错误
缺陷：静态存在于软件工作产品（代码、文档）中的错误
故障：软件运行中出现的状态，可引起意外情况
失效：软件运行时产生的外部异常行为结果，表现与用户需求不一致，功能能力终止，用户无法完成所需要的应用。
13、引入缺陷的原因
1. 开发过程缺乏有效沟通，或没有进行沟通
2. 软件复杂度越来越高
3. 编程中产生错误
4. 需求不断变更
5. 不重视开发文档
6. 软件开发工具本身隐藏的问题
……
14、缺陷
缺陷的分布：需求：56% 设计 27% 代码 7% 其它 10%
导致软件缺陷的最大原因：软件产品说明书
软件缺陷产生的第二大来源：设计方案
缺陷类型：遗漏、错误、额外实现
缺陷管理的目的：
a) 保证信息的一致性
b) 保证缺陷得到有效的跟踪，解决
c) 获取正确的Bug信息，用作缺陷分析和产品度量
缺陷管理支撑工具：QC、
缺陷的相关属性：发现人、发现时间、状态、严重程度、所属版本、修改日期
缺陷的严重程度：致命、严重、一般、提示
缺陷跟踪单的写作准则（5C）：准确、清晰、简洁、完整、一致

第二章 软件质量
1、质量
质量定义：实体基于这些特性满足需求的程度
影响质量的因素：流程，技术，组织
软件质量的三个层次： A.符合需求规格
B.符合用户显示需求
C.符合用户实际需求
2、软件质量管理体系（质量常见模式）
ISO9000：适用于各行各业
CMMI：只适用软件
6SIGMA：软件和非软件制造业
6sigma和ISO9000关系：
6sigma提供了一个ISO9000之后企业进一步改善的方向、步骤和系统的方法，它既能够促进企业改革又能保证在企业各个层面上的持续改善。
3、八项质量管理原则
1．以客户为中心
2．领导作用
3．全员参与
4．过程方法
5．管理的系统方法
6．持续改进
7．基于事实的决策方法
8．互利的供方关系
4、八项质量管理原则的意义
1. 是质量管理的理论基础
2. 用于高度概括易于理解的语言所表述的质量管理
3. 为组织建立质量管理体系提供了理论依据
4. 是组织的领导者有效的实施质量管理工作必须遵守的原则
5、CMMI两种表示法
阶段式、连续式
6、CMMI5个等级
KPA:企业需要集中力量改进的软件过程
级别 特点 KPA
初始级(0) 过程能力不可预测、缺乏控制、过程是无序的，管理是反应式、消防式。
可重复级/已管理级(6) 目的：使软件项目的有效管理过程制度化
过程能力有纪律的 需求管理、软件质量保证、软件配置管理
已定义级(7) 软件工程过程、软件管理过程被集成为一个整体，称为组织的标准软件过程，项目建立项目定义软件过程
过程能力标准的和一致的 同行评审
定量管理级(2) 过程能力可预测的 定量的过程管理
优化级(3) 为了预防缺陷出现
过程能力不断改进 缺陷预防
7、CMMI和ISO9000
同 针对性不同（行业） 覆盖范围不同（环境） 关注点不同（客户）
CMMI 管理体系
部分要求相近
关注过程 软件
ISO9000 各行各业
8、6sigma
6sigma概念：6sigma管理法是以质量作为主线，以客户需求为中心，利用对事实和数据的分析，改进提升一个组织的业务流程能力，从而增强企业的竞争力，是一套灵活的，综合性的管理方法体系
6sigma本质：6sigma模式的本质是一个全面管理概念，而不仅仅是质量提高手段
6sigma管理原则：
1. 注重客户
2. 注重流程
3. 全员参与
4. 预防为主
5. 事实依据的决定
6. 持续和突破性改进
6sigma改进区域：
1. 周期时间
2. 输出物的差变
3. 营运效率
6sigma实施方式（DMAIC循环）：
定义Define:确定要解决的问题
测量Measure:测量结果
分析Analyze:何时，何地，为何产生缺陷
改进Improve:如何改进过程
控制Control:如何保持过程的改善
强有力的组织结构是成功实现6sigma的最重要的保证。
6sigma误区：1. 自下而上推行6sigma
2. 把引入6sigma理念与方法作为一场运动
3. 6sigma培训就是统计工具的培训
……
9、QA和测试的关系
SQA从流程方面保证软件的质量
测试从技术方面保证软件的质量
只进行SQA活动或者只进行测试活动不一定能够产生好的软件质量
10、QA的主要工作范围
1. 指导并监督项目按照过程实施
2. 对项目进行度量、分析，增加项目的可视性
3. 审核工作产品，评价工作产品和过程质量目标的符合度
4. 进行缺陷分析，缺陷预防活动，发现过程缺陷，提供决策参考，促进过程改进
11、量管理PDCA循环
Plan（计划设计）
Do （实施执行）
Check（检查检测）
Act（纠正措施）
12、软件度量
度量：对事物属性的量化表示
软件度量：是指计算机软件中范围广泛的测度，包括对软件系统、构件或生命周期过程具有的某个给定属性的度的一个定量测量
软件度量的目的：
1. 提高软件生产率，缩短产品研发周期，降低研发成本，维护成本，提高软件产品质量
2. 提高软件产品质量，提高用户满意度
3. 为组织持续改进提供量化的指标和反馈
度量的作用 ：
理解，预测（最重要），评估，改进
软件度量的过程：
识别目标、定义过程、收集数据、分析数据、改进过程
软件度量的分类：
四个基本度量项：规模、工作量、进度、质量—缺陷
规模度量：SRS、HLD、LLD文档页数，KLOC（代码量）， UT、IT、ST用例数
缺陷度量：SRS、HLD、LLD评审，编码，UT、IT、ST发现缺陷数
其他：缺陷密度、生产率、测试执行效率、用例密度等
13、如何将度量知识应用于实际工作中
建立测试工作的度量数据，目的是作为预测试和改进测试的基础
1. 熟悉需求：进度、工作量、规模
2. 设计用例：工作效率、覆盖率
3. 执行用例：工作效率、缺陷密度
14、质量模型
一组特性及特性之间的关系，它提供规定质量需求和评价质量的基础
外部和内部质量
功能性 可靠性 易用性 效率 维护性 可移植性
适合性
准确性
互操作性
保密安全性

功能性的依从性 成熟性
容错性
易恢复性

可靠性的依从性 易理解性
易学性
易操作性
吸引性

易用性的依从性 时间特性
资源利用性

效率依从性 易分析性
易改变性
稳定性
易测试性

维护性的依从性 适应性
易安装性
共存性
易替换性

可移植性的依从性

第三章 系统测试
1、系统测试
定义：将已经集成好的软件系统，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行的环境下，对计算机系统进行一系列的组装测试和确认测试。
对象：软硬件集合在一起的系统，集成后的产品
目的：通过与系统的需求定义做比较，发现软件与系统定义不符合或与之矛盾的地方，以验证软件的功能和性能等满足其规约所指定的要求。
2、常见系统分类
纯软件：QQ……………..
软件和硬件：手机，PSP，空调，电梯
软件硬件和维护人员：大型系统
3、系统测试环境
真实环境：直接将整个系统和其交联的物理设备真实的建立链接，进行测试
优点：可以发现某些只能在真实环境下出现的问题
缺点：构建这样一个环境需要高昂的费用
它的测试运行也需要高昂的费用
仿真环境：它能够逼真的模拟被测试软件运行所需的真实物理环境的输入与输出，并且能够组织被测软件的输入，来驱动被测软件运行，同时接收被测软件的输出结果。
优点：仿真环境和真实环境的软件依赖是一样的，并且它能够保证测试的：
可重复性、完整性、可扩展性
4、测试工具
选用测试工具应考虑的因素：
1. 测试工具与被测软件系统的匹配程度
2. 测试工具提供的主要功能和辅助机制
3. 测试工具的服务和技术支持
4. 测试工具的价格
5、测试数据
特点：
1. 数据可以以消息、事物、记录、文件等形式存在
2. 数据来源很多
3. 真实数据最好，但在很多情况下不易或者不能得到
来源：
1. 产品数据
2. 手工构造数据
3. 生成数据（一般由工具设备构造）
4. 捕获数据（少用，与捕获数据源有关，允许手工修改）
5. 随机数据（系统测试少用，它易于获得，不够真实，性能测试常用）
5．1产品数据
1. 最具真实性
2. 不能覆盖所需所有场景
3. 数据敏感，很难保证正确性
4. 随时间变化
5. 可能数据量太大（从而降低测试执行速度）
5．2手工构造数据
1. 费时间、枯燥
2. 如果对系统的功能缺乏了解，数据不真实
3. 有时是获得特定测试用例所需独特数据的唯一手段
5．3生成数据
1. 一般由工具或设备构造
2. 数据取决于工具的完善程度和测试人员的关于如何构造数据的规格说明
5．4捕获数据
1. 与捕获数据源无关
2. 允许手工修改
5．5随机数据
1. 易于获得，不够真实
2. 对强度或负载测试是非常有用的
6、十六种系统测试类型
 功能测试（配置测试、恢复性测试、备份测试）
 性能测试（压力测试、稳定性测试、容量测试）
 GUI测试（可用性测试）
 兼容性测试
 安全性测试（网络测试）
 安装性测试
 文档测试

6．1功能测试
概念：根据SRS和 需求列表，验证产品的功能实现是否符合产品的需求规格
目标: 1.是否有不正确或者遗漏了的功能（做错或少做）
2.功能实现是否满足用户需求和系统设计的隐藏需求
3.能否正确的接受输入，能否正确的输出结果
功能测试步骤：
1.对每个明确的功能需求进行标号
2.对每个隐含的功能需求进行标号
3.对可能出现的功能异常进行分类分析并且标号
4.把功能划分为关键功能和非关键功能
5.对每个功能进行测试分析，分析其是否可测，如何测试，可能的输入、输出
6.脚本化和自动化
6．2性能测试
概念：用来测试软件在集成系统中的运行性能
目标: 度量系统各项指标，确认系统有无各种性能瓶颈
特点：混合白盒测试和黑盒测试的方法
性能测试考虑的两个方面:
1.验证系统实现的性能是否与性能需求完全一致
2.检测系统实现的具体性能到底怎样
常用方法：探针，测试驱动
常用工具：Loadrunner,WebLoad,SilkPerformer
6．3GUI测试
概念：针对软件系统界面进行的测试
目标：1.测试界面实现与界面设计的吻合情况
2.确认界面处理的正确性
关注点：界面层与功能接口层上（GUI系统分为三个层次：界面层、界面与功能的接口层、功能层）
常用工具：QTP，QARun
6．4兼容性测试
概念：考虑被测试软件在其他软件（例如OS）或硬件设备下的运行情况
目标：与辅助软件的结合情况
与硬件设计的结合情况
6．5安全性测试
概念：验证集成在系统内的保护机制是否能够在实际中保护系统不受非法的侵入，用来保护数据本身的完整性和保密性
范围：主要从几个方面考虑：系统登录，用户管理，防火墙，系统数据，WEB安全，数据库安全，内部通讯，系统防毒测试
保护测试是安全测试中的一种常见的测试，主要用于测试系统的信息保护机制
6．6安装性测试
概念：验证成功安装系统的能力
目标：找出软件安装的错误，安装手册的错误
常用自动化安装测试软件：
Total Uninstall:它能够监视软件安装的所有过程，记录下它对系统所做的任何改变
FileRiver:可以自动监视和准确记录下多个文件夹中的文件以及子文件的细微变化
6．7文档测试
概念：主要针对SRS，安装手册，配置指南等文档，测试内容主要是编写规范，内容正确性，无歧义性，完整性
目标：验证用户文档是正确的并且保证操作手册的过程能够正确工作
7、系统测试
阶段：
系统测试计划阶段：完成系统测试计划（规划和步骤）
系统测试设计阶段：完成系统测试方案
系统测试实现阶段：完成系统测试用例，系统测试规程，系统测试预测试（冒烟测试）项
系统测试执行阶段：执行系统测试预测试，系统测试用例，开展回归测试，校验已修复的问题，提交系统预测试报告，系统测试报告，缺陷报告
过程：软件需求分析、设计（概要）、系统测试（执行）

阶段 入口准则 输入 出口准则 输出
计划 1.SRS完成
2.成立了需求规格基准 软件开发计划
软件测试计划、SRS 系统测试计划评审并通过 系统测试计划
设计 系统测试计划评审并通过 系统测试计划、SRS 系统测试方案评审并通过 系统测试方案
实现 系统测试方案评审并通过 系统测试计划
系统测试方案、SRS 系统测试用例
系统测试规程
系统测试预测试项评审并通过 系统测试用例
系统测试规程
系统测试预测试项
执行 系统测试用例、系统测试规程、系统测试预测试项评审并通过，集成测试执行结束 系统测试计划
系统测试方案
系统测试用例
系统测试规程
系统测试预测试项 系统测试报告评审并通过 系统预测试报告
系统测试报告
缺陷报告

8、系统测试中的角色及职责
开发代表：解决资源需求，对系统测试结果进行监督
QA：系统测试过程质量保证，参与相关评审，对过程进行审计
配置管理组：对系统测试文档，及测试代码等相关配置进行配置管理
软件开发组：1.系统测试计划阶段，提供软件开发计划SDP，参与系统测试计划的评审
2.系统测试设计和实现阶段，提供SRS，需求分析，测试建议，响应系统测试需求，参与软件系统测试方案的评审
3.系统测试执行阶段，跟踪解决软件测试项目组的缺陷问题报告单，参与系统测试报告的评审
软件测试组：1.系统测试计划阶段，制定系统测试计划并组织评审
2.系统测试设计和实现阶段，制定软件测试方案并组织评审，按照软件系统测试方案，实现测试用例，测试代码和测试工具等设计，编写测试规程
3. .系统测试执行阶段，执行系统测试，反馈并跟踪缺陷问题报告单，完成系统测试报告并组织评审，输出测试案例、总结等经验文档
系统分析组： 1.提出系统测试需求
2.进行测试需求跟踪
3.进行软件系统可测性分析，确定系统测试的对象、范围和方法
9、系统测试计划的要点
1. 明确系统测试的被测对象
2. 完成系统测试的需求跟踪
3. 明确系统的通过或失败标准
4. 系统测试的挂起标准及恢复的必要条件
5. 明确系统测试工作任务分配
6. 系统测试结束后应交付的工作产品
10、区别
系统测试计划：对系统测试全过程的组织，指明范围，方法，资源，以及相应测试活动的时间进度安排表的文档。（做什么）
系统测试方案：设计测试方法的细节文档（描述系统需要测试的特性，测试的方法，测试环境的规划，测试工具的设计和选择，测试用例的设计方法，测试代码的设计方案，怎么做）
系统测试方案需要在系统测试计划的指导下进行，系统测试计划提出做什么，而系统测试方案明确提出“如何做”
11、系统测试步骤
需求分析—计划、方案—用例设计—环境搭建—执行—测试报告
需求分类： 1. 项目需求（用户自己提需求）
2．产品需求（产品人员进行调查撰写）
基线：第一种说法：软件版本相对稳定
第二种说法：文档经过多次评审修改之后封存起来，任何人需求修改都要提出申请。

第四章 测试过程和方法
第一节 测试过程
1、测试阶段划分
 需求测试?
 单元测试
 集成测试
 系统测试
 验收测试
2、需求测试
定义：通过评审来测试需求（通过不同级别不同类型的评审来避免人员意见）
3、单元测试
定义：针对软件基本组成单元（软件的最小组成单元：函数，语句块等）
目的：检测软件模块对LLD的符合程度
4、集成测试
定义：将所有模块按照ＨＬＤ的要求组装成子系统或者系统，验证组装后的功能以及模块间接口是否正确的功能
目的：检测软件模块对ＨＬＤ的符合程度
5、系统测试
定义：将已经集成好的软件系统，作为整个基于计算机系统的一个元素，与计算机硬件，外设，某些支持软件，数据和人员（用户）等其他元素结合在一起，在实际运行环境下，对计算机进行一系列的测试工作
目的：检测软件模块对ＳＲＳ的符合程度
6、验收测试
定义：通过了内部系统测试及软件配置审查之后，进行验收测试，以用户为主的测试
α测试
定义：用户在开发环境进行的测试，也可以是开发机构内部的用户在模拟实际操作环境下进行的测试。是可控制环境，开发测试人员可以修改控制的环境
目的：评价软件产品的ＦＬＵＲＰＳ（功能，局域化，可用性，可靠性，性能和技术支持）
β测试
定义：由多个用户在一个或多个用户的实际环境下进行的测试。不可控制环境，开发者不在现场
7、回归测试
（发生在软件测试的任何阶段，只要有缺陷的修复就进行回归测试）
策略：
完全重复测试：重新执行所有在前期测试阶段建立的测试用例，来确认问题修改的正确性和修改的局部影响性
选择性重复测试：（新发现的缺陷用例，和覆盖主要功能的用例）有选择性重新执行部分在前期测试阶段建立的测试用例，来测试被修改的程序
方法：
1. 覆盖修改法
2. 周边影响法
3. 指标达成方法
流程：
1. 在测试策略制度阶段，制定回归测试策略
2. 确定需要回归测试的版本
3. 回归测试版本发布，按照回归测试策略执行回归测试
4. 回归测试通过，关闭缺陷跟踪单
5. 回归测试不通过，缺陷跟踪单返回开发人员，经再次修改，再提交测试人员回归测试
8、单元测试，集成测试，系统测试的比较
测试方法不同
 单元测试属于白盒测试
 集成测试属于灰盒测试
 系统测试属于黑盒测试
考察范围不同
 单元测试主要测试单元内部的数据结构，逻辑控制，异常处理 等
 集成测试主要测试模块之间的接口和接口数据传递关系，以及模块组合后的整体功能
 系统测试主要测试整个系统相对于需求的符合度
评估基准不同
 单元测试的评估基准主要是逻辑覆盖率
 集成测试的评估基准是接口覆盖率
 系统测试的评估基准主要是测试用例对需求规格的覆盖率
9、主要的测试文档
 测试计划
 测试方案
 测试用例
 测试规程：指明执行测试时测试活动序列的文档
 测试报告
 测试日报：每天测试执行情况的记录和总结
10、常见测试过程模型
瀑布模型
H模型：
测试分两类活动：一类是测试准备活动，一类是测试执行活动
V&V模型：
1.实现了测试设计和测试执行相分离
2.揭示了软件测试活动分层和分阶段的本质特性，测试执行的顺序与开发活动相反
验证与确认：
验证：保证软件正确地实现特定功能的一系列活动
Producting Right?
确认：保证所生产的软件可追溯到用户需求的一系列活动
Right Producting?
11、测试与开发的并行性
12、CMM关于过程的要素
角色、入口准则、输入、活动、输出、出口准则、评审和审计等
13、集成测试过程
概要设计——详细设计——执行集成测试
概要设计：
输入：SRS、系统测试计划
输出：集成测试计划、系统测试方案、系统测试用例、预测试项、规程、阶段报告
详细设计：
输入： SRS、系统测试计划、系统测试方案、集成测试计划
输出：单元测试计划、集成测试方案、集成测试用例、集成测试规程、阶段报告
执行集成测试：
输入： 单元测试报告、集成测试计划、集成测试方案、集成测试用例、集成测试 规程
输出：集成测试报告、阶段报告
14、集成测试过程与开发阶段
概要设计（集成测试计划）——详细设计（集成测试设计、实现）——集成测试执行
15、集成测试各阶段的输入、输出
集成测试计划阶段：
输入：软件测试计划、概要设计说明书（HLD）
输出：集成测试计划
集成测试设计阶段：
输入：概要设计说明书（HLD）、集成测试计划
输出：集成测试方案
集成测试实现阶段：
输入：软件测试计划、详细设计说明书
输出：单元测试计划
集成测试执行阶段：
输入：详细设计说明书、单元测试计划
输出：单元测试方案
16、单元测试过程
详细设计——编码——执行单元测试
17、单元测试各阶段的输入、输出
单元测试计划阶段：
输入：软件测试计划、详细设计说明书（LLD）
输出：单元测试计划
单元测试设计阶段：
输入：详细设计说明书（LLD）、单元测试计划
输出：单元测试方案
单元测试实现阶段：
输入：单元测试计划、详细设计说明书、单元测试方案
输出：单元测试用例、单元测试规程
单元测试执行阶段：
输入：单元测试方案、单元测试计划、单元测试用例、单元测试规程
输出：单元测试报告、缺陷报告
18、需求分析阶段的主要任务
 需求分析，完成SRS
 SRS的评审
 进行需求跟踪
 系统测试计划
 系统测试计划的评审
19、需求阶段的角色和职责
软件测试工程师：
1. 参与SRS评审工作
2. 协助软件测试项目经理完成软件系统测试计划写作
3. 参加系统测试计划的评审
4. 完成本阶段测试需求跟踪
20、概要设计阶段的主要任务
 完成HLD
 概要设计的评审
 系统测试方案、用例的设计
 系统测试方案、用例的评审
 需求跟踪更新
 集成测试计划
 集成测试计划评审
21、概要设计阶段的角色和职责
软件测试工程师：
1. 参与HLD评审
2. 参与集成测试计划的评审
3. 进行系统测试方案、用例的设计
4. 参与系统测试方案、用例的评审
5. 完成本阶段测试需求跟踪
22、详细设计阶段的主要任务
 进行软件详细设计，完成LLD
 详细设计的评审
 集成测试的方案、用例的设计
 集成测试的方案、用例的评审
 需求跟踪更新
 单元测试计划
 单元测试计划评审
23、详细设计阶段的角色和职责
软件测试工程师：
1. 进行软件详细设计，完成LLD文档
2. 详细设计的评审
3. 集成测试方案、用例的设计
4. 集成测试方案、用例的评审
5. 需求跟踪更新
6. 单元测试计划
7. 单元测试计划评审
24、软件编码阶段的主要任务
 软件编码
 代码静态质量检查
 代码评审
 单元测试方案、用例设计
 单元测试方案、用例评审
25、软件编码阶段的角色和职责
软件测试工程师：
1. 参与代码评审
2. 进行单元测试方案、用例设计
3. 单元测试方案、用例评审
4. 完成本阶段测试需求跟踪
26、集成测试执行阶段的主要任务
 集成测试用例执行
 集成测试缺陷记录、修复
 集成测试日报写作
 集成测试缺陷的回归测试
27、UT/IT/ST执行阶段的角色和职责
软件测试工程师：
1. 搭建测试环境
2. 执行测试用例
3. 发现缺陷后提交缺陷报告
4. 回归测试
5. 每天提交测试日报
6. 测试报告及系统测试预测试报告写作
7. 参与测试报告的评审
8. 参与转系统测试评审
第二节 测试方法
1、什么是白盒测试
依据被测软件分析程序内部构造，并根据内部构造设计用例，来对内部控制流程进行测试，可完全不顾程序的整体功能的实现情况。
白盒测试是基于程序结构的逻辑驱动测试。
2、为什么要进行白盒测试
A. 它一般在测试前期进行，通过达到一定的逻辑覆盖率使软件内部逻辑控制结构上的问题能够基本得到消除
B. 保证内部逻辑结构达到一定的覆盖程度，能够给予软件代码质量更大的保证
C. 白盒测试发现问题后解决问题成本较低
3、白盒测试的常用技术
A. 静态分析技术：控制流分析技术，数据流分析技术，信息流分析技术（不执行代码）
B. 动态分析技术：逻辑覆盖率测试（分支测试，路经测试），程序插装
4、控制流相关概念
程序元素：通常是一个条件，一个简单的语句或一块语句（多个连续语句）
控制流关系：叙述了程序元素和它们执行的次序之间的联系
控制流图：对应于控制流关系的图
控制流矩阵：由控制流图得到，反映相邻程序元素之间的先后顺序关系
5、控制流分析的步骤
 确定所有程序元素
 根据程序元素之间的相互关系得到控制流图
 将控制流图转换成控制流矩阵
 通过数据结构的形式把控制流矩阵表示出来
6、控制流分析能发现的问题
 转向并不存在的标号
 没有用的语句标号
 从程序入口进入后无法达到的语句
 不能达到停机语句的语句
7、数据流相关概念（主要用于代码优化）
数据定义：如果程序中某一语句执行时能改变某程序变量V的值，则称V是被该语句定义的
数据的引用：如果一语句的执行引用了内存中变量V的值，则说该语句引用变量V
8、数据流分析步骤
 根据代码得到数据流表
 分析数据流表找到以下两种错误：
1. 变量未定义但被引用
2. 变量定义但未被引用
9、信息流分析
可以导出程序的信息流的关系，为软件开发的确认提供了工具。
通过以下三个关系表给出：
 输入变量