软件的特点：具有抽象性的逻辑实体
运行和使用没有磨损和老化问题，但在修改维护中存在失效率升高，退化 开发和运行依赖计算机系统：硬件要求，操作系统要求，可移植性方面的质量需求
手工开发，很难依靠新技术利用现成的部件组装成所需软件
复杂性：实际问题复杂，程序逻辑结构复杂，涉及相关领域的专业知识，软件技术发展落后于需求
成本昂贵，作用在不断提升
分类：
功能--系统+支持+应用
规模：小 5人 6-12月，中 5-100 12月 大 100以上 1年以上
mistake错误：人为的产生不正确结果的行为
defect缺陷：可能会导致组件或者系统无法执行其定义的功能的瑕疵
failure失效：组件或系统与期望的交付、服务或结果存在的偏差，是缺陷的外部反映
程序员犯了一个错误--在代码或软件中表现为缺陷--运行存在缺陷的代码或软件就可能引起失效
动态测试发现的是失效，静态测试可以发现缺陷
软件产品的质量特性：功能性，可靠性，易用性，效率，可维护性，可移植性
使用质量：有效性，生产率，安全性，满意度 （基于用户观点）
软件测试的主要阶段：
测试计划和控制
测试分析和设计
测试实现和执行
评估出口准则和报告
测试结束活动
实际项目测试中的出口准则：
当计划的测试时间用尽的时候
当继续测试没有发现新的缺陷的时候
当所有的测试用例执行完毕时
当测试的成本大于收益时
当达到所要求的测试覆盖率的时候
当所有发现的缺陷都已经被清除的时候
测试目的：
发现缺陷，增加对质量的信心，为决策提供信息和预防缺陷
软件测试是对软件开发过程中的所有工作产品包括程序及相关文档进行的测试，而不仅仅是通过运行程序来进行的动态测试
动态测试：通过运行被测对象来进行
静态测试：不需要运行被测对象，其测试对象是开发过程中生成的各类工作产品，包括需求
文档，设计文档，代码等
主要由评审和动态分析组成
验证verification:通过检查和提供客观证据来证实指定的需求是否满足
是否在正确构建产品 关注构建过程，针对开发过程中的单个阶段 确认validation：通过检查和提供客观证据来证实软件产品的特定目的的功能或应用是否已经实现
是否构建了正确的产品 关注的已构建的软件产品 根据原始需求检查各阶段开发结果的过程
测试test：目的是发现缺陷 人员：测试人员，开发人员 方法：由已知条件开始，有期望的结果 可以计划，工作进度可以度量
对象包括软件开发过程中的所有产品，各种文档、数据及代码
可以发现由于软件存在的缺陷而引起的失效
调试debug：目的是定位缺陷并修改 人员：开发人员 方法：由未知条件开始，结果难以预测 过程或者时间相对难以计划
用来识别引起失效的原因和采取解决方案来修正缺陷
测试基本原则：
穷尽测试是不可能的，无法发现被测对象所有的缺陷 good enough
测试只能显示缺陷的存在，不能证明软件完全正确，不存在缺陷
测试应该尽早的介入 提高质量，降低开发成本
缺陷具有集群效应，符合帕累托原则，需要重点关注缺陷较多的模块或者程序段
杀虫剂效应：重复执行相同的测试用例，其发现缺陷的能力会越来越差 因此需要经常进行用例的评审和修改
测试活动依赖于上下文 不同的软件系统需要选择不同的测试 依赖于运行环境和使用中的风险
没有失效不代表系统是可用的 满足客户真正的需要才是成功的 充分了解需求
测试的基本过程：
测试计划和控制：指导方针 出入口准则，决定，监控（识别测试对象，目的，范围）
测试分析和设计：识别具体的测试需求，并依据需求设计相应的测试用例，规划环境搭建，需要的基础设施和工具
测试实现和执行：创建测试数据，执行用例，确认测试和回归测试
评估出口准则和测试报告：数据分析，出口依据 提交报告，包括所有数据
测试结束活动：经验教训总结，过程改进建议，归档过程中的各项产品
测试模型：
瀑布模型：能否正确理解客户需求，且需求在开发过程中是否会经常变更
测试作为软件开发的一个组成部分
V模型：开发任务和测试任务是相互对等的活动且同等重要
测试分级：
单元测试：系统最小组件，保证能够正常运行，满足详细设计说明的要求 黑盒+白盒 功能+特定的非功能 测试驱动开发
集成测试：为暴露接口已经集成单元或集成系统之间交互时存在的缺陷而进行 是否能按需求协同工作，接口是否正确
组件集成、系统集成--关注集成本身（接口）
通信，数据传递--适合动态测试 包括功能测试和非功能性测试
集成策略：自底向上--驱动模块 自顶向下--桩模块 核心系统先集成 按组件完成时间集成
系统测试：检查整个系统是否满足指定的需求 功能是否实现，非功能的质量特性是否满足设计要求
两者都是顺序模型，使用前提都是软件系统是否具备完善明确的需求
增量迭代模型：需求不断变化，持续集成，早期迭代，实现重用，不断改进开发过程，充分利用项目人力资源
螺旋模型：多次风险分析 风险驱动 可以演化为原型开发或者瀑布模型
RUP：最佳实践 四阶段：初始 精化 构建 产品化
敏捷开发：极限编程xp 看板 scrum 功能驱动开发feature driven development 动态系统开发
关注个体和交互 可用软件胜过全面文档
验收测试:对系统功能、系统某部分或者特定的系统非功能特性进行测试。发现缺陷不是主要目标，评估系统是否可以发布及用户对系统使用的准备情况
确认测试：确认缺陷是否已经修改
回归测试：变更是否会引入新的缺陷--零回归，部分回归（关联部分，高优先级的用例），全部回归
各阶段测试，各类型测试通用
功能测试：对系统或组件功能说明的分析而进行的测试 系统能做什么?主要通过观察输入输出，考虑系统外部表现行为 适用黑盒测试
分类：适用性，准确性，互确认性，安全性测试 界面测试，业务逻辑测试，兼容测试，易用性测试，安装测试
非功能测试：特征，行为表现 黑盒测试
可靠性，易用性，效率，可维护性，可移植性（性能测试：负载，压力，容量，并发，配置，可靠性，冒烟，随机）
结构测试：通过分析组件或系统的内部结构而进行的测试 白盒测试
覆盖率 语句 条件 判定
维护测试：在现有的运行系统上进行，对系统进行修改，移植或者退役处理时需要进行
静态测试：通过人工检查-评审，或者自动化分析-静态分析对代码或者其他的项目文档进行
检查，而不需要运行代码
基本思想是预防缺陷，可以发现缺陷，而不是失效
更容易发现：与标准之前的偏差，需求的遗漏和错误，设计的缺陷，软件可维护性差，错误的结构说明
发现文档的问题，减少由于错误的文档造成的缺陷 避免影响动态测试本身的质量 评审：计划-预备会：向评审员介绍相关内容-评审员个人准备-会议
管理者：决策
主持人：负责文档或文档集的评审工作，收集评审数据和发布评审报告，协调评审员的不同观点
作者：使评审对象满足评审出入口准则 创建，修改
评审员：标示和描述被评审对象存在的缺陷
项目测试文档是用来记录，描述，展示测试过程中国的一系列测试细信息的处理过程，通过过过书面或者图示的形式对项目测试活动过程或者结果进行描述、定义及报告。 伴随测试的各个阶段逐渐充实完善，记录整个测试的过程和成果。
作用：有助于项目测试水平的提高
驱动着测试过程
软件测试计划：在软件测试工作正式实施之前明确测试的对象，并通过对资源、时间、风险、测试范围和预算等方面的综合分析和规划，确保软件测试的有效实施。
基本结构：计划的简介 项目说明 需要测试的项目清单
测试手段和策略 项目通过或失败的标准 暂停或重启测试的标准
测试的可交付性—产物
测试任务
需求：环境 人员及培训
时间进度安排
风险及偶然事故的预测
缺陷：不满足用户确定需求
再现与优化缺陷
有效记录：保证重现缺陷
使用最少步骤重现（节约时间，便于准确定位）
包含所有必要步骤
方便阅读，尽量简单独立，一个缺陷一个报告
客观描述，对事不对人
缺陷报告的用途：记录 分类（分配解决所需资源） 跟踪
分类方式：功能
严重程度-影响进度，死机，功能问题，界面问题，建议
修复优先级—应立即处理，发布前必须处理，时间有序才处理，发布版本可以存在
处理流程：提交——分配——处理——返测——关闭