“测试用例”的定义
为一个测试项创建一个文档，这个文档包含 了一系列的执行条件和环境，并定义描述输 入数据和期望的输出和结果
为一个测试项的输入和期望输出做定量测试 必须包括有效的和期望的输入条件以及无效
的和不期望的输入条件
一个定义明确 的缺陷报告
也是一个测试用例。
TCM界面
TCM应用场景
– PM: 根据反馈调整功能
– Dev: 具体怎么做？
– Dev: 开发，解决缺陷
– Test: 细化的衡量标准
– Test: 多种手段稳定产品
协作的保障
协作三板斧
◦ 每日构造（daily build） ◦ 版本控制 ◦ 缺陷管理
案例分析：开发流程精髓
每日构造
整个Office团队使用统一的每日构造
确的缺陷指派回给项目经理或登记 该缺陷的测试人员 ◦ 找到所有由自己解决的缺陷，并写 代码Check-in Report
开发主管
◦ 指派缺陷 ◦ 比较谁解决的缺陷最多，而且个人
是否完成指标 ◦ 调研指派给自己的那些较难解决的
缺陷 ◦ 通过比较check-in前后的文件版本，
为开发人员解决的缺陷做Code Review ◦ 评估修复某个缺陷的复杂度
◦ 工作无法量化，奖惩机制无效 利用工具辅助绩效考核及工作评估
软件开发中的常见问题
开发周期难以控制
◦ 项目风险无法评估和预测 ◦ 对频繁出现的变更和缺陷无法跟踪 ◦ 缺乏数据采集平台和分析引擎以辅助决策 ◦ 工具灵活性差，不能进行企业级的量身定制 ◦ 计划、设计、编码和测试脱节，无法做到无缝连接
瀑布模型 螺旋模型
MSF模型
全程协作
协作贯穿于产品开发周期始终
• 远景阶段
• 开发阶段（多里程碑）
– PM: 做什么，为什么？ – PM: 掌舵，进度控制
– Dev: 技术可行否？
– Dev: 开发
– Test: 风险在哪？
– Test: 无微不至的关怀
• 计划阶段
• Beta与发布阶段
– PM: 具体做什么？
流程分解
逻辑-物理设计 构
开发管理造
代码集成
/
规范和审核
基 线
项目范围定义 风
需求管理 需求跟踪管理 险 管 概念-逻辑设计 理
项
文
目
档
管
管
理
理
版
缺
本
陷
控
管
制
理
测试用例设计 测
测试管理 测试用例运行 试 计 测试结果报告 划
流程分解
逻辑-物理设计 构
开发管理造
代码规范
/
代码集成
基 线
项目范围定义 风
◦ 软件设计、编程、制作中出现的错误
BMS中对缺陷的定义：
任何有助于改善产品质量的提议、任何需要引起注意、值得跟 踪的问题、任何可能潜在的错误，由BMS来记录、跟踪、管理 缺陷的后继变化和处理方案。其中包括： ◦ 代码错误 ◦ 工作项 ◦ 变更 ◦ 文档问题 ◦ 测试问题 ◦ 建议及其他
BMS界面 缺陷的生命周期
开发团队协同问题
◦ 缺乏沟通平台，信息交流滞后 ◦ 开发模式落后，团队协作不力 ◦ 责任机制不明，事务无法跟踪 ◦ 工作无法量化，奖惩机制无效
解决方案
开发团队协同问题
◦ 缺乏沟通平台，信息交流滞后 建立实时的信息沟通和管理平台
◦ 开发模式落后，团队协作不力 建立科学的流程和高效的管理机制
◦ 责任机制不明，事务无法跟踪 构建科学的团队模型和明确角色分工
测试管理 测试用例运行 试 计 测试结果报告 划
上图对CMM部分KPA的映射
1-初始级 2-可重复级 3-定义级 4-管理级
需求管理
集成式软件管理 定量过程管理
5-优化级
缺陷管理
软件项目计划
组织过程定义
软件质量管理
技术改革管理
.. .. .. .. .. ..
软件配置管理
.. .. .. .. .. ..
更重要的是测试计划，软件质量标准和测试流程
个性化的企业应用级平台
后 共
同 学 习
会 相
互 提 高
有 期
自动监控
非细化无以监控
◦ 细化的开发进度表
检查点多多益善
◦ Spec freeze ◦ CC ◦ 50 bug goal ◦ ZBB ◦ Beta ◦ RC ◦ RTM
赋予测试团队神圣的权利
◦ 测试计划紧密尾随开发计划 ◦ 测试员和开发员捉对厮杀 ◦ 群众的眼睛是雪亮的
每日构造和自动测试让问题自动曝光
障制度
◦ 单元测试 ◦ 代码审阅 (code review) ◦ 通知机制
每个程序员都有完整的Build环境，在集成的基础上进 行单元测试
缺陷管理
协同工作的主要手段
◦ 缺陷 ◦ 变更请求 ◦ 建议 ◦ 各色问题
量化管理
◦ 量化质量 ◦ 跟踪进度 ◦ 预测发布时间
工具在管理流程中的应用
开发流程概览
需求管理 需求跟踪管理 险 管 概念-逻辑设计 理
项目项计划 项目目跟踪 变更管控制 范围理管理
风险管理
基线版管理 Che本ck-in Chec控k-out D风ai险ly制管Bu理ild
范围文/需求 计划档/设计 开发管文档 测试理文档
用户文档
缺陷缺跟踪 任务陷跟踪 质质变量量更管理评管管估理理
测试用例设计 测
◦痛
Office Common的Bug马上会影响Excel的开发 Build一次需要几个钟头 开发人员的疏忽造成Blocking Bug，成为万恶不赦的公敌
◦பைடு நூலகம்并快乐着
各产品组自始至终在集成环境下工作，保证总体质量 开发人员绝对重视单元测试 让无微不至的关怀变得可能
版本控制
版本控制是否形同虚设？ 版本控制是每日构造的基础 版本控制是建立在版本工具之上的一系列严格的质量保
缺B陷M的生S命周应期 用场景
测试人员
◦ 登记一个缺陷，描述缺陷的 详细信息
◦ 按优先级验证缺陷，检查其 是否可以重现
◦ 若缺陷被解决，关闭缺陷 ◦ 回归测试
测试主管
◦ 指派缺陷 ◦ 比较谁登记的缺陷最多，而
且个人是否完成指标 ◦ 组织“软件大扫除”
缺B陷M的生S命周应期 用场景
开发人员
◦ 找到所有由自己负责的缺陷 ◦ 按优先级解决这些缺陷 ◦ 把那些设计、重现环境或步骤不明
测试人员
◦ 新建测试用例 ◦ 在一个可执行版本上检验测试用例并记录
结果 ◦ 碰到非期望的结果时，登记一个缺陷 ◦ 选择一组测试用例来做不同场景的测试
（如BVT）
测试主管/项目经理
◦ 分配测试用例 ◦ 检验有多少用例已经走过，有多少用例还
未被运行，测试人员是否完成指标 ◦ 审核测试用例是否和设计文档一致
BMS
缺陷管理
缺乏缺陷管理会怎么样？
◦ 以前解决过的缺陷发布时又出现了，拉长开发周期 ◦ 测试发现的问题被忽略或是不了了之 ◦ 很难衡量测试员和开发员的工作
缺陷管理的意义
◦ 提高项目质量，缩短周期 ◦ 为项目管理提供依据 ◦ 预测项目进度与里程碑 ◦ 加强沟通与协作
“缺陷”的定义
通常大家认为缺陷是：
微软开发管理流程综述
MSF团队模型
团队组织结构一例
产品部门经理 项目经理组长 项目经理 开发人员组长 开发人员 测试人员组长 测试人员 产品经理 可用性 用户培训 其他
MSF过程模型
1. 多里程碑式管理-平衡范围、时间和资源的最佳实践
MSF过程模型
2. MSF模型-集瀑布模型和螺旋模型的优点于一身
.. .. ..
同行评审
过程变更管理
工具在领域中的应用
开发管理
需求管理
项
文
目
档
管
管
理
理
版
缺
本
陷
控
管
制
理
测试管理
微创软件开发管理平台 产品介绍及应用场景
设计思想
TCM
测试人员
用户
RMS
项目经理
BMS
其他人员
Project
项目管理
开发人员
Exchange
构造员
VSS
代码管理 Daily Build
开发人员
◦ 单元测试时运行一批用例并验证是否成功
测试方法大全
单元测试
◦ 让每日构造和测试员来监督
覆盖性测试
◦ 依赖清晰的功能规范，着眼于用户情景
Monkey Testing
◦ 找出边缘问题
回归测试
◦ 以前出现过的缺陷是财富
自动测试
◦ 成熟软件的必备
白盒测试
◦ 对后台和技术性强的模块有效
TCM
测试管理
测试目的
◦ 验证软件对规格说明的实现 ◦ 发现程序中的缺陷 ◦ 确定系统可以正常工作 ◦ 了解性能的限制 ◦ 了解系统不能做什么 ◦ 评估系统的能力和质量 ◦ 验证文档
测试关键
◦ 测试应尽早开始 ◦ 应该在测试工作真正开始前较长时间内就进行测试计划 ◦ 建立良好的测试用例管理机制 ◦ 严格执行测试计划，避免测试的随意性 ◦ 对每个测试结果做全面调查 ◦ 妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便 ◦ 建立良好的Daily Build机制
缺B陷M的生S命周应期 用场景
项目经理
◦ 指派待定的缺陷，并指定优先级和负 责人
◦ 及时了解缺陷分布以更好地协调团队 之间的工作，消除瓶颈
◦ 组织专家会诊 ◦ 通过缺陷趋势预测关键检查点及发布
日期 ◦ 给开发人员布置工作任务（可以从
Microsoft Project 2019导入），并 给出详细设计 ◦ 变更跟踪