Presentation is loading. Please wait.

Presentation is loading. Please wait.

微软的秘诀 -- 软件开发中的测试管理 李丹软件测试工程师视窗数字媒体事业部 Microsoft Corporation.

Similar presentations


Presentation on theme: "微软的秘诀 -- 软件开发中的测试管理 李丹软件测试工程师视窗数字媒体事业部 Microsoft Corporation."— Presentation transcript:

1

2 微软的秘诀 -- 软件开发中的测试管理 李丹软件测试工程师视窗数字媒体事业部 Microsoft Corporation

3 Windows XP 有多少行编码? YearOperating SystemSLOC (Million) 1990Windows 3.13 1995Windows NT4 1997Windows 9515 1998Windows NT 4.016 1999Windows 9818 2000Windows NT 5.020 2001Windows 200035 2002Windows XP40

4 问题 “ 连 Daily build 都没有,怎么做测试? ” “ 连 Daily build 都没有,怎么做测试? ” “ 应该用 Rational? 还是 Load runner?” “ 应该用 Rational? 还是 Load runner?” “ 什么时候开始测试? ” “ 什么时候开始测试? ” “ 测试计划应包括哪些内容? ” “ 测试计划应包括哪些内容? ” “ 一个好的测试人员须具备什么条件? “ 一个好的测试人员须具备什么条件? “ 怎么做测试的预算? “ 怎么做测试的预算? ??? ???

5 这个课程将 … 简介 “ 产品开发周期 ”- PCM 简介 “ 产品开发周期 ”- PCM 简介产品开发的指南针 – 5 P’s 简介产品开发的指南针 – 5 P’s 窥视微软的十个秘诀 窥视微软的十个秘诀

6 秘诀之一 -- 测试举足轻重

7 三国鼎立 Dev PM Test 立法 监控 执法

8 组织结构 产品 项目经理开发测试

9 组织结构 大团队 项目经理开发测试 产品 1 产品 2

10 开发人员 vs 测试人员 比例 比例 薪水 薪水 发展 发展 代表用户 代表用户

11 小结一下 … 测试工作改善产品的质量 测试工作改善产品的质量 测试工作改善项目的质量 测试工作改善项目的质量 从生意的角度认识 从生意的角度认识 从组织结构来认识 从组织结构来认识 从人员配备来认识 从人员配备来认识

12 秘诀之二 --- 测试贯彻始终

13 规划设计 贯彻 稳定 发布 产品开发周期 – PCM Model

14 第一阶段 --- 规划 目标 : 产品定位, 用户定位, 时间 定位 目标 : 产品定位, 用户定位, 时间 定位 定义小组组建计划 定义小组组建计划 其他 其他  简略功能定义 (Functional Specification)  概念性设计 (Conceptual design)  简略测试计划 (Preliminary test plans)  运作预测 (Operations forcasting)  简略用户协助计划简略地区化计 划 进行测试部门的预算 ( Budget/Estimate) 进行测试部门的预算 ( Budget/Estimate) 调查将可使用于测试的的 流程, 技术, 和工具 调查将可使用于测试的的 流程, 技术, 和工具 建立测试团队 建立测试团队

15 第二阶段 --- 设计 完成总体的测试计划 完成总体的测试计划 由下至上的成本和日程 预算 由下至上的成本和日程 预算 团队已经组成 团队已经组成 n 予功能说明书的审查 n 予功能说明书的审查 撰写测试计划 撰写测试计划 建立管理流程 建立管理流程  工具, Bug 管理,报告 系统等等 目标 : 怎样开发 目标 : 怎样开发 完成功能规范设计 (Functional Specs) 完成功能规范设计 (Functional Specs) 详细开发体系结构 (Architecture Specs) 详细开发体系结构 (Architecture Specs) 定义工具和技术的应用 定义工具和技术的应用 完成由下至上的日程表 完成由下至上的日程表 总体测试计划( Master Test Plan) 总体测试计划( Master Test Plan) 用户协助, 地区化, 用户界面 用户协助, 地区化, 用户界面

16 第三阶段 --- 贯彻 主要里程碑 (Mn); 多个小产品周期

17 第三阶段 - 完成标准 完成市场定位和咨询策略 完成市场定位和咨询策略 完成代码 ( Code Complete) 完成代码 ( Code Complete) 测试完成设计测试工具和规范 测试完成设计测试工具和规范 完成用户界面的详细设计规范文件 完成用户界面的详细设计规范文件 完成用户协助功能规范文件 完成用户协助功能规范文件 完成产品上市发布计划 完成产品上市发布计划 开始 Bug triage/tradeoffs 开始 Bug triage/tradeoffs 开始产品地区化工作 开始产品地区化工作

18 第三阶段 – 测试部门责任 初步接收测试 Acceptance/BVT testing 初步接收测试 Acceptance/BVT testing 国际化测试 Globalizability 国际化测试 Globalizability 基本功能测试 Feature Functionality Testing 基本功能测试 Feature Functionality Testing 参予编码的审查 Participate in Code review 参予编码的审查 Participate in Code review 进行测试优化 Test prioritization 进行测试优化 Test prioritization 撰写测试案例 Write test cases 撰写测试案例 Write test cases 测试自动化编码 Write test automation script 测试自动化编码 Write test automation script 编写测试工具 Writing test tools 编写测试工具 Writing test tools

19 第四阶段 --- 稳定 目标 : 满足用户对稳定, 可靠和安全的产品需 要和期望.

20 第四阶段 - 完成标准 发布市场测试 (Beta) 版 发布市场测试 (Beta) 版 发布技术测试 (Beta) 版 发布技术测试 (Beta) 版 其他 其他  产品发布的推广计划  继续 Bug Triage  达到零个 bug (Zero Bug Bounce)  完成对用户协助文件的检验  测试板被内部 Servers 采用

21 第四阶段 – 测试 部门责任 总体测试 总体测试  表现,压力,用户界面,地区化,耐力,装机, 实况摹拟,等等 Performance, stess, UI, loc, longhaul, setup, scenarios, help, etc 编码覆盖研究和优化测试顺序 Code coverage and test prioritization 编码覆盖研究和优化测试顺序 Code coverage and test prioritization Bug 的报告与跟踪 Bug 的报告与跟踪  Bug bash, test pass, scenarios, cross area testing, etc 内部应用 内部应用  dog food

22 第五阶段 --- 发布 目标 : 满足企业对发布新产品的需求. 满足用 户对使用新产品的需求.

23 第五阶段 - 完成标准 发布零售制造版 (RTM) 发布零售制造版 (RTM) 发布网络版 (RTW) 发布网络版 (RTW) 最后的文件 (Help, Release Note) 最后的文件 (Help, Release Note) 地区化准备同步发布 地区化准备同步发布 产品支持部 (PSS) 和快速修补工程 (QFE) 开 始运作 产品支持部 (PSS) 和快速修补工程 (QFE) 开 始运作 市场运用的研究开始 市场运用的研究开始

24 第五阶段 – 测试部门责任 确定测试 sign-off 的程序 确定测试 sign-off 的程序 Regression 重测 Regression 重测 QFE/SE 测试交接 QFE/SE 测试交接 移向新的项目 移向新的项目

25 规划设计 贯彻 稳定 发布 产品开发周期 – PCM Model

26 秘诀之三 --- 坚持原则

27 管理的指南针 ( 5Ps) 管理的指南针 ( 5Ps)  Purpose 目的  Principle 原则  Priority 优序  Plan 规划  People 人选

28 秘诀之四 --- 建立高效的团队

29 组织结构 Test Manager Test Lead STE Test Lead SDET Test Lead

30 下面哪一个是好的测试人员 ? 发现最多的 bug? 发现最多的 bug? 发现最多被除掉的 bugs ? 发现最多被除掉的 bugs ? 发现,推动除掉最多对用户有影响的 Bugs ? 发现,推动除掉最多对用户有影响的 Bugs ?

31 测试人员的素质 适应性 适应性 逻辑思维 逻辑思维 细心 细心 有勇气 有勇气 有效的追求结果 有效的追求结果

32 好的测试人员 优秀的测试基本功 优秀的测试基本功 准确地报告 Bugs, 包括准确的步骤和 debugging 信息 准确地报告 Bugs, 包括准确的步骤和 debugging 信息 能写好的,经已测试的自动化编码,加以 清晰的文件 能写好的,经已测试的自动化编码,加以 清晰的文件 对自己的领域负责任 对自己的领域负责任  总是自我检察有无漏洞  总是敢於对自己的工作负责

33 优秀的测试人员 有能力超越自己的领域 有能力超越自己的领域 视野开阔,可看得更远 视野开阔,可看得更远 可对质量和进度可做权衡 可对质量和进度可做权衡 司机的性格 司机的性格

34 测试人员角色的转变 企业意识 企业意识 技术要求 技术要求  Black box, White box, Gray-box 沟通技术 沟通技术 代表顾客 代表顾客

35 秘诀之五 --- 完整的臭虫 (Bugs) 管理体系

36 什么是 Bug? 什么是 Bug? Bug 的生命周期 Bug 的生命周期 Bug 的处理流程 Bug 的处理流程 Bug 的分类 Bug 的分类 Bug 的数据库各个阶段的含义 Bug 的数据库各个阶段的含义 除害三国会议 (Bug Triage) 除害三国会议 (Bug Triage)

37 什么是 Bug? 编码或逻辑中的错误 编码或逻辑中的错误  Any error in code or logic 与 spec 或说明书有出入 与 spec 或说明书有出入  Disparity from a spec, or applicable guidelines 预料不到或不正确的结果 预料不到或不正确的结果  Incorrect or unexpected results 与合理的顾客期望有出入 与合理的顾客期望有出入  Deviation from a reasonable customer’s expectations - Myers

38 Reopened Bug Open Bugs Closed Bugs Resolved Bugs Investigate & Resolve Resolved Verify Resolutions Rejected FixedVerified Regression Testing Fixed Bugs Regression Bug Bug 的生命周期

39

40 Bug 报告中的一些问题 不完整的步骤 不完整的步骤 缺乏调查的细节 缺乏调查的细节 少了数据支持文件 少了数据支持文件 少了环境 / 调试的信息 Environment / configuration information 少了环境 / 调试的信息 Environment / configuration information 少了期待的结果 少了期待的结果 重复 重复 少了 Debug 信息 少了 Debug 信息 多个 Bugs 放在一起 多个 Bugs 放在一起

41 最佳实践 记录最基本的数据 记录最基本的数据  状态,类别,解决办法,客户影响,等等 Create custom fields 记录有意义的信息 记录有意义的信息 用 template 来输入信息 用 template 来输入信息 记录所有的 bug 记录所有的 bug Policy – 只有测试人员才能 Close Bugs Policy – 只有测试人员才能 Close Bugs

42 基本数据

43 防止无意义的纪录 Meaningless data is completely worthless Meaningless data is completely worthless No way to determine test method effectiveness No way to determine test method effectiveness

44 防止无用的纪录 Microsoft only produces products in about 39 languages Microsoft only produces products in about 39 languages No “localization” difference between Arabic (Algeria) and Arabic (Qatar) No “localization” difference between Arabic (Algeria) and Arabic (Qatar)

45 Bug 报告 Template 题目 : 简略描述 : 步骤 : 实际结果 : 预期结果 : 其他 note:

46 分类 Severity 严重性 Severity 严重性  Crash  功能上的错误  Uncommon or minor feature failure  Suggestion Priority 优先性 Priority 优先性  Blocking test  Must fix before ship  Would like to fix before ship  Minor issue

47 三国大战 怎样开好三国会审? 怎样开好三国会审?  关上门  每个决定是会议的决定 - 支持  最好各方派一个代表  有一个最后下决定的人  用 “ 无一反对 ” , 而不用 “ 全部赞成 ”

48 秘诀之六 --- 投资测试自动化

49 推动测试自动化 自动化需一定成本 自动化需一定成本 为什么要自动化? 为什么要自动化? 挑战 挑战

50 PCM – 自动化投资的阶段 早投资 早投资 在设计时考虑 在设计时考虑 Planning (M0) Major Milestone Phase M1,2… Release Phase Time Testing Investment Testing Phase

51 PCM – 自动化回收的阶段 Planning (M0) Major Milestone Phase M1,2… Release Phase Time Automation Payback Testing Phase 早期无回收 早期无回收 稳定,发布以及发布后的支持阶段受益 稳定,发布以及发布后的支持阶段受益

52 自动化的优势 Why Automate ? 机器代替人 机器代替人  可以更频繁的测试  每一次做同样的测试 做更多的测试 做更多的测试  减少了烦闷的,重复性的工作。可用时间来检 查结果  更多的时间用来做手工测试和寻找 bugs.

53 优势 ( 继续 ) 自动化可进行一些高难度的测试 自动化可进行一些高难度的测试  Perf, Stress, Scalability, Config, OM/API, Matrix 一至性 一至性  Performance, Regression 可重复使用 可重复使用  How many File Open drivers are there?  Logging, etc. 稳定性 稳定性 容易交接 容易交接 Easy to hand off (external teams & sustaining engineering) Easy to hand off (external teams & sustaining engineering)

54 风险和问题 过分依赖自动化结果 过分依赖自动化结果 维持计划 维持计划 同样的测试 同样的测试 错误的 “ 失败 ” 或 “ 成功 ” 错误的 “ 失败 ” 或 “ 成功 ” 需要有技术才能找出问题 需要有技术才能找出问题

55 使你的自动化更有效  分析成本  重复使用  写扎实的编码  写详细文件  自动化英根据测试案例  如不行应立既放弃  利用框架

56 测试分配系统 – 组件 用户界面 用户界面 数据库 数据库 机器管理和控制 机器管理和控制 用户端 agent 用户端 agent 测试的 harness 测试的 harness 机器成像 机器成像 Other common tasks Other common tasks Results Viewer Results Viewer Email Email

57 秘诀之七 --- 测试文件的管理

58

59 有趣的事实 70% of all defects are introduced at the specification phase 70% of all defects are introduced at the specification phase Where bugs live Where bugs live  General: 80% of bugs live in 20% of the code (Parado lives!)  IBM published 50% of bugs live in 7% of code base

60 微软的测试文件系统 Master Test Plan “Business” focus Test spec “Technical” focus Test spec “Technical” focus Test spec “Technical” focus Test cases

61 定义:总体测试计划 一个测试计划是 … 大方向,总体进度表,目标,资源 大方向,总体进度表,目标,资源 Contract 合同 Contract 合同 Road map 指南针 Road map 指南针

62 定义:测试设计说明书 确认测试方法 确认测试方法 确认欲测试的功能 确认欲测试的功能 确认测试的案例 确认测试的案例

63 定义:测试案例 一个测试案例 : 目的 目的 步骤 步骤 预期结果 预期结果

64

65 定义:报告和报表 个别案例结果记录 个别案例结果记录 整体测试报表 整体测试报表 整体项目报表 整体项目报表

66 好的测试文件 清晰的目的 清晰的目的 容易维持 容易维持 容易明白 容易明白 保持更新 保持更新 完整 完整 ?

67 秘诀之八 --- 重视流程的管理

68 秘诀之九 – 工欲善其事, 必先利其 器

69 秘诀之十 – 不断研究更新

70 问题?

71 下一步 更多培训机会 – MAT 更多培训机会 – MAT http://www.microsoft.com/china/advancedtraining/ 请加入微软高级培训论坛 请加入微软高级培训论坛微软高级培训论坛 http://www.devmanclub.com/ E-mail: dianeli@microsoft.com E-mail: dianeli@microsoft.com

72 © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.


Download ppt "微软的秘诀 -- 软件开发中的测试管理 李丹软件测试工程师视窗数字媒体事业部 Microsoft Corporation."

Similar presentations


Ads by Google