与您一起分享在测试过程中的快乐与辛酸...

微软的软件测试策略

上一篇 / 下一篇  2009-02-04 15:11:06 / 个人分类:测试经验

看了51testin论坛上 软件质量管理 精华板块中《微软软件测试方法》一文,深有感触!原文链接地址:http://bbs.51testing.com/thread-39630-1-1.html

以下是自己整理的测试策略,微软作为全球软件行业的大哥,在管理上自有一套,很多都值得我们学习

策略1:
总体上说分为三个步骤进行三大步骤:审核需求和设计—>设计测试—>实施运行测试
1.验证需求和设计:(1)由项目经理根据用户要求(信息来源于市场部门、用户支持部门等等)而编写的需求文
本;(2)由项目经理根据需求文本而编写的功能设计文本;(3)由开发人员根据功能文本而编写的实施设计文本。测试人员要参与所有这些文本的审核。作为测试人员,审核重点是检查文本对用户需求定义的完整性、严密性和功能设计的可测性。同时这种审核对于测试人员也是一种热身活动,使他们尽早地进入技术和业务状态。
2.测试人员要根据已审核通过的需求和设计编制测试计划,设计测试用例。。“测试计划” 主要阐述测试的范
畴、领域、方法、工具、资源和计划时间表等等。“测试用例设计”要列出测试用例、每个用例的设置、执行步骤和预期结果。测试的这两个文档也要被项目经理和开发人员审核。这样经过各种相互的审核,大家对项目形成了基本的共识。
3.实施运行测试是整个开发过程中最长最复杂的一个阶段。从测试的过程来看,总是先运行或执行简单用例,然
后再复杂用例;先验证单一的基本功能,再综合的端到端的功能;先发现解决表面的,影响面大的Bug,再深层的,不容易重现的Bug。因此随着项目开发和测试的进程,产品的功能不断完善,质量不断提高。这一阶段测试人员还有一项繁琐但却很重要的工作,就是对已有的测试用例的维护。比如通常以下两种情况下要新增一些测试用例,一是对于当初测试设计不周全的领域,二是对于外部的Bug(比如从Beta客户报告来的),没有被现有测试用例所覆盖。当产品的功能设计出现更改时(在微软这是常事),所涉及的测试用例当然也要相应地修改。

策略2:
微软的测试是阶段性的,常常根据需要而带有随机性和突击性。对于这类测试,在微软有一个专门的名称
:“BugBash(Bug大扫除)”。BugBash通常发生在项目开发各阶段(微软叫里程碑)的末期,比如Beta版发布前,划出一个专门的时间段(通常1-3天),在这期间所有参与项目的人员,集中全部精力,运用各方面的知识,尽全部智慧来搜寻项目的Bug。这是一个非常有意思的活动,但要组织好这样的活动并非易事。一般有以下要点:(1)尽管这是一个测试活动,但参与者并不仅限于测试人员。项目经理,开发人员甚至于高层管理人员都应参加,如同全民动员。目的是要集思广益;(2)要鼓励各部门,领域交叉搜索,因为新的思路和视角通常有助于发现更多的Bug;(3)为调动积极性,增强趣味性,可以适当引入竞争机制,比如当活动结束时,评出发现Bug最多,发现最严重Bug的个人,给以物质和精神奖励。(4)可以分专题展开,比如安全性、用户界面可用性、国际化和本地化等等。
    微软的第二类测试除了Bug Bash外,经常还有一些专业性的测试,最典型的是针对安全性攻击测试。一般会
邀请公司内部,或业界的专家来搜寻产品的安全漏洞。


TAG: 测试经验

 

评分:0

我来说两句

显示全部

:loveliness: :handshake :victory: :funk: :time: :kiss: :call: :hug: :lol :'( :Q :L ;P :$ :P :o :@ :D :( :)

Open Toolbar