1 软件测试的定义和目的
软件测试定义：使用人工和自动的手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的区别。
注：软件测试的目的不仅仅是为了发现错误。
软件测试的目的：
人们对软件测试的目的的认识也经历了一个过程。
20世纪60年代： 证明，表明软件能够工作，测试是证明软件没有问题；
20世纪70年代：检测，发现错误；
20世纪90年代：预防，管理质量。
软件测试观念的转变：
传统测试：在开发后期介入，基于代码运行的测试，以发现错误为目的；
现在测试：已扩展到整个软件生命周期，已扩展到静态的范畴，已扩展到了错误预防的范畴。
2 软件的生命周期
软件发展的历史：
|
阶段名称 |
年代 |
描述 |
结果 |
|
程序设计阶段 |
50年代~60年代中期 |
硬件 |
价格贵、容量小、可靠性差 |
|
软件 |
专用、规模小 |
||
|
测试 |
没有系统意义上的软件测试，更多的是一种调试方式，错误主要集中在元器件的不稳定上 |
||
|
程序系统阶段 |
60年代~70年代中期 |
硬件 |
速度容量可靠性明显提高、价格下降 |
|
软件 |
出现软件作坊、软件产品开始出现 |
||
|
测试 |
重点逐渐转入到高级语言编写的系统中来，测试理论和方法在这一阶段发展还是比较缓慢 |
||
|
软件工程阶段 |
70年代中期以后 |
硬件 |
向超高速大容量网络化发展 |
|
软件 |
开发技术有很大进步但未完全摆脱软件危机 |
||
|
测试 |
许多测试理论和测试方法相继诞生，软件测试逐渐形成了体系 |
软件危机的出现：60年代中期，随着软件负责度的增加，爆发了众所周知的软件危机。
软件危机的主要表现：
1． 缺乏大型软件开发经验和软件开发数据积累，开发工作计划很难制定
2． 开发早期需求分析不明确，造成后期矛盾集中暴露
3． 不遵循开发规范，开发文档不完整，软件难以维护
4． 缺乏严密有效的软件质量检测手段，交付给用户的软件质量差
软件危机的根源：
1．根据摩尔定律，硬件发展很快，相应对软件系统的期望也越来越高
2、软件系统的复杂性提高，需多人合作
3、软件开发是人的智力活动，无法用已有的产业工程方法来组织管理
解决软件危机的主要方法：
1．软件工程，研究软件生命周期的各个阶段，按照工程化的原则和方法来组织软件开发工作，是摆脱软件危机的主要出路
2．研究新的软件设计技术
软件生命周期：计划、需求分析、设计、编码、测试、运行和维护
3 软件研发和流程
软件研发的要素：人员、过程、工具
只有合适的人员借助合适的工具经过合适的过程才能研发出高质量的软件。
工具为人员和过程服务，起辅助作用，起关键作用的是人员和过程。
软件项目人员的组成：
分析人员、设计人员、开发人员、测试人员、配置管理人员（CMO）、软件质量保证（SQA）
QA：检验产品的质量，保证产品符合客户的需求；是产品质量检查者
QC：审计过程的质量，保证过程被正确执行；是过程质量审计者
测试的主要工作：
评审SRS
制定计划和方案
编写及评审用例
搭建测试环境，准备数据
执行测试，发现缺陷，提交缺陷报告，回测记录的缺陷
分析测试结果，编写测试报告，度量软件质量
……
测试用例：指对一项特定的软件产品测试任务的描述，体现测试方案、方法、技术和策略。
基本软件研发流程
|
|
瀑布模型 |
螺旋模型 |
RUP流程 |
IPD流程 |
|
概述 |
应用最广泛、缺陷也显而易见 |
综合了基本的瀑布式模型和演化/渐增原型方法 |
所有工作流在各个阶段都有体现 |
从整个产品角度出发，不仅仅针对研发 |
|
优点 |
简单高效 |
充分考虑风险，抗风险能力强 |
1.针对大型复杂的系统，进行逐步完善，降低了实施复杂度 2.用户可在早期提出变更并进行修复，从而有效控制变更风险及代价 3.可在早期增强用户的信心 |
1.将软硬件研发及生产、销售等各个部门有效整合，集中在一个平台下统一管理，提高了决策的准确性及时效性 2．有利于各部门关键数据的共享 |
|
缺点 |
测试介入晚，人员闲置严重，后续工作跟不上 |
成本高，需专业的风险分析专家参与 |
1.要有专业的架构师 2.已确定的功能不能变更 |
1.管理成本高 2.部门之间的协调关系较复杂 |
|
适用 |
不适合需求频繁变更的项目、大项目，适合小规模传统项目 |
与生命财产相关的系统 |
大型复杂的项目，耦合度较低的系统，当功能与功能之间联系太紧密就不适用 |
大型软硬件集成厂商 |
4 软件中引入缺陷的原因
软件缺陷定义：是对软件产品预期属性的偏离现象
BUG：缺陷的一种表现形式
错误：编写错误的代码，导致软件包含故障的人的行为，包含逻辑错误和语法错误
缺陷：静态存在于软件工作产品（代码、文档）中的错误，产品的异常情况
故障：软件运行中出现的状态，可引起意外情况
失效：软件运行时产生的外部异常行为结果，表现与用户需求不一致，功能能力终止，用户无法完成所需要的应用
引入缺陷的原因：
开发过程缺乏有效沟通，或没有进行沟通
软件复杂度越来越高
编程中产生错误
需求不断变更
不重视开发文档
软件开发工具本身隐藏的问题
……
缺陷的分布：（需求：56% 设计 27% 代码 7% 其它 10%）
导致软件缺陷的最大原因：软件产品说明书
软件缺陷产生的第二大来源：设计方案
缺陷类型：
1．遗漏，规定的或预期的需求位体现在产品中
2．错误，未将规格说明正确实现
3．额外实现，规格说明并未规定的需求被纳入产品，得到实现
缺陷管理的目的：
1．保证信息的一致性
2．保证缺陷得到有效的跟踪，解决
3．获取正确的Bug信息，用作缺陷分析和产品度量
缺陷管理支撑工具：QC、Rational Clear Quest、Bugzilla、Mantis、Jira
缺陷的相关属性：发现人、发现时间、状态、严重程度、所属版本、修改日期
缺陷的严重程度：致命、严重、一般、提示
缺陷跟踪单的写作准则（5C）：准确、清晰、简洁、完整、一致