但大规模改动不现实 缺少敏捷软件开发专家和人才 技术人员需要观念的转变和方法培训 缺乏相应的质量控制方法 需要经常的和及时的质量度量、测试、决策
传统的QA方法程序怎样适应敏捷软件开发？
问题的提出
需求分析
与用户存在语义分歧 对问题域缺乏全面的认识 多变的需求导致效率低下
功能实现
周期过长 与分析设计脱节 版本之间管理混乱
制定测试计划对软件进行测试
◦ 单元测试 ◦ 集成测试 ◦ 确认测试 ◦ 系统测试
形成报告
◦ 记录软件开发活动的偏差 ◦ 记录软件产品的偏差－软件测试报告
目的
◦ 发现问题，纠正偏差，提高质量
目的
◦ 为管理者管理了解软件的质 量提供可视性
800
700
600
500
400 300
200
设计
测试
产品化
在组织内部或者项目组内部制定标准和规范，限制 和约束软件开发活动，有助于得到规范化的软件产 品，从而提高软件质量
◦ 软件开发过程规范 ◦ 需求管理 ◦ 变更管理 ◦ Java编码规范，…… ◦ 测试用例编写规范
审查每个活动是否遵循软件开发过程规范
◦ 审查每个活动的输入条件是否都得到满足 ◦ 审查活动的执行是否遵循规范 ◦ 审查每个活动的输出是否都已经产生
Quick Test Professional (QTP) ◦ Mercury Interactive Company ◦ 功能测试工具
Rational Robot ◦ IBM Rational ◦ 功能测试工具
Xrunner ◦ Mercury Interactive Company ◦ 功能测试工具
QARun ◦ Compuware Company ◦ 功能测试工具
E-Tester ◦ Empirix Company ◦ 功能测试工具
Silk Test ◦ Segue Software Inc.
100
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Total Inser ti on 2 41 50 59 64 79 93 118 159 207 263 320 378 420 485 536 579 593 630 662 679 702 706
理解客户的要求和需要
让客户参与开发，随时和客户交流，验证客户的需 求
◦ 形成文字 ◦ 软件原型 ◦ 用不同的形式表达需求
修复软件的代价 – 高成本
在产品化阶段，
失去机会的代价 – 低营业额 修复软件错误的成本 成本 失去客户的代价 – 低营业额 将高出100到1000倍！
需求
敏捷开发模式的最佳表述：
◦ 人和交互 重于 过程和工具。 ◦ 可以工作的软件 重于 求全责备的文档。 ◦ 客户协作 重于 合同谈判。 ◦ 随时应对变化 重于 循规蹈矩。
注：其中位于右边的内容虽然也有其价值，但是左 边的内容最为重要。
越来越多的企业希望采用，但没有把握 习惯于传统的瀑布式产品开发流程已不满足快速发展需要，
2007年３月，成千上万台某种型号的医疗设备被 召回，只是为了修正一个软件错误
2007年某天，深圳某银行软件出错，柜员机吐出 ２倍的金额给客户，客户排队取款。
每天线上都有问题产生 经常有用户投诉，交易出现异常 代码可维护性差 缺乏统一架构设计，对将来的扩展是一个很大挑战 缺乏业务文档，很多业务流程只有少数人知道 流程刚刚建立，存在质量控制方面的漏洞 需求、开发和测试缺乏共识，需要培训
如何提升软件产品 质量
不同角色
收集需求
收集需求
收集需求
20世纪90年代逐渐引起广泛关注的新型软件开发 方法
它们的具体名称、理念、过程、术语都不尽相同， 但是都强调
◦ 程序设计师团队与业务专家之间的紧密协作 ◦ 面对面的沟通（认为比书面的文档更有效） ◦ 频繁交付新的软件版本 ◦ 紧凑而自我组织型的团队 ◦ 能够很好地适应需求变化的代码编写和团队组织
Total Fi xed
0 0 9 20 20 20 20 20 20 25 54 109 186 265 313 379 443 499 568 605 648 685 688
Total Inser ti on
Total Fi xed
Win Runner ◦ Mercury Interactive Company ◦ 功能测试工具
开发活动
◦ 审查，产生审查报告 (Review)
பைடு நூலகம்
构架是软件的蓝图
软件项目质量保证小组(SQA小组) 独立于项目开发小组 具有比较大的权限
项目一开始测试人员应该进入 正确理解用户的要求 制定标准和规范，Team统一执行 审查软件开发活动 测试源程序代码 记录开发活动和软件产品的偏差 记录所有不符合项，报告高级管理者
产品
质量不可靠 BUG太多 重用性低
可维护性差 兼容性差 文档混乱
开发设计
无法预知和降低风险 没有清晰的架构思路 与实现难以平滑衔接
软件测试
测试成本过高 无法做到回归测试
维护成本过高
1961年，一个简单的软件错误导致美国大力神洲 际导弹助推器的毁灭．
2007年４月，某软件缺陷导致某地铁系统的火 灾．
标准和规范
需求分析 开发活动
软件设计 编码 测试
软件产品
文档
程序代码
软件产品
◦ 软件需求基线文档 ◦ 软件设计文档 ◦ 源程序代码，….
开发活动
◦ 需求分析 ◦ 软件设计 ◦ 编码
标准和规范
组织内部或者在项目开始之时要制定软件开发的标 准和规范
软件产品
◦ 文档类：审核，产生评审报告(Review) ◦ 代码类：测试，产生测试报告(Test Report)
传统的QA方法程序怎样适应敏捷软件开发？
1. QA人员 2. 测试人员 3. 开发人员 4. 项目管理人员 5. 需求人员 6. All above
用户对软件质量的评价
◦ 没有××功能(功能) ◦ 运行速度太慢(性能) ◦ 有太多的错误(故障) ◦ 软件不好改动(维护) ◦ 界面不美观(人机界面) ◦ 这个软件不好使用(易用性) ◦ ……