软件测试-多库文档.ppt

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * SEI 与HP 公司合作,提出了实施SW2CMM 的IDEAL 模型。IDEAL 模型是一个单位用于启动、规划和实现过程改善措施蓝图的模型,概括了建立一个成功的过程改善项目的必要步骤,其中I 代表Initiating(启动) 、D 代表Diagnosing(诊断) 、E 代表Establishing(建造) 、A 代表Acting(实施) 、L 代表Learning(学习) 。 四、CMM与软件评价及测试 1、在CMM的发展进程中，曾经提议将软件评价与测试（Evaluation and Test）作为CMM的一个KPA加入到CMM中，虽然这一提议最终未获通过，但通过对这一提议的讨论，我们可以得到很多与软件测试相关的一些有益的东西。 2、软件评价与测试在整个软件生命周期中的作用：在项目生命周期中的每一个交付产品都必须被测试。对于一个给定交付产品的评价和测试可能会延续项目生命周期的多个阶段。 3、希望在CMM中加入这个独立的KPA的原因　　1)评价和测试在促进向有纪律的软件工程过程的文化转变中的作用；　　2)评价和测试在项目跟踪中所起的作用；　　3)整个开发和维护在评价和测试部分的预算；　　4)评价和测试训练对软件交付时间和成本方面的影响；　　5)评价和测试对软件残余缺陷的影响。 第三节 微软的过程管理 一、微软团队模型 1） 项目经理：编写功能规范，协调各角色关系 2）产品经理：客户联系的桥梁，进行需求分析 3）用户教育：让产品容易使用 4）发布经理：保证产品顺利发布 二、微软项目管理-- 多里程碑式流程 1、达成共识 ???1）基本完成需求调研和分析 （产品经理负责） 2）确定大方向和长中短期目标 3）所有角色都参与讨论并真正认同结论 4）产生的文档：常见用户情景：覆盖80%以上功能、Vision：言简意赅地说明大方向，并有激励团队的作用 2、完成项目计划 1）编写详细的功能规范（项目经理负责） 2）在编程前想清楚所有功能流程，并引导用户明确需求 3）所有角色都参与审阅功能规范 4）制订开发计划和进度表（开发团队） 5）制订测试计划和进度表（测试团队） 6）分配资源（人力和预算） ·形成项目综合计划和综合进度表 7）产生的文档： *功能规范，开发计划，测试计划（用例），项目综合计划 *开发进度表，测试进度表，综合进度表 3、完成功能 1）开发人员分别完成自己的功能 2）使用版本控制工具 3）使程序员及时check out和check in，避免积累大量代码 4）及时进行模块间的整合，及时发现问题（daily build） 5）对每一项可测试的功能进行测试，无需等待 6）使用测试用例工具，对功能进行完整和重复的检验 7）使用BMS进行缺陷跟踪 8）记录所有程序问题 9）实现解决Bug的自动流程 10）按照综合进度表不断检查进度 11）使用的工具： ????????·版本控制工具 VSS ????????·缺陷跟踪工具 Raid/BMS ????????·测试用例管理工具 4、稳定与发布 1）测试组全面地测试功能，包括性能和稳定性 2）开发组全力配合解决Bug 3）使用BMS进行 *监测质量情况 *预测发布日期 4）专家会诊机制： ????*决定Bug的优先度 *决定哪些Bug可以等到下个里程碑或版本中解决 *决定由谁解决某个Bug 5）使用的工具： *版本控制工具 VSS *缺陷跟踪工具 BMS *测试用例管理工具 三、微软的开发管理经验：100%以Bug为核心 1．Bug 及常见类型 ????1）功能未实现，和规格说明书不一致 ????2）不能工作：死机，没反应 ????3）不兼容 ????4）边界条件 ????5）界面、消息、提示不够准确，不友好 ????6）把尚未完成的工作也作为一个Bug ????7）文档与帮助信息中的缺陷也是Bug 2、RAID/BMS的基本功能 1） 完整的Bu