微软是怎么做软件测试工作的？(4)

　　要避免或至少将这种破坏减少到最低限度，开发人员首先需要知道这种破坏的影响面。在这里单靠开发人员自身的逻辑思维、技能和经验是远远不够的，自动测试再一次成为一种有效的工具。往往开发人员会制定不止一个方案，对每个方案上都运行一遍同样一套自动测试用例，然后比较结果，选出最佳方案。

　　自动测试在这方面所起的作用不仅在产品的开发过程中，它还延续到产品发布后。产品支持部门在为客户提供应急解决方案时也要依赖自动测试。

　　管理对测试的依赖

　　在微软，软件项目管理的主要线索就是Bug的管理，其中最直接具体的管理活动就是“Bug三方讨论会(Bug Triage)”。会议一般由项目管理Program Manager(简称PM)来主持，有开发人员和测试人员参加(所以叫三方会议)。会上对每个新生成的Bug进行讨论，并决定

　　是否接受这个Bug;

　　Bug的严重级别和优先级别;

　　Bug由谁来负责，是由测试提供进一步详细信息，还是交由开发人员解决，以及大致的解决方案等等。

　　会议还要对老的Bug检查解决进度。这种讨论会常常会发生争论，要求测试人员具有足够的技术基础和用户经验，来捍卫产品的质量。

　　可以说项目开发到了某一阶段后就是由这种Bug的管理所驱动的。这其中的原动力来自测试。

　　项目管理中一项非常重要但也十分困难的工作是衡量项目的进度，包括判断项目的状态，确定项目是否能预期完成。这方面，测试提供了两个非常重要的参数，一个是Bug数量的趋势，另一个是测试结果的趋势。

　　Bug趋势就是将每天新生成的Bug数和每天被解决的Bug数标成一个趋势图表。一般在项目的开始阶段新生Bug数曲线会呈上升趋势，到项目中后期被解决Bug数曲线会趋于上升，而新生Bug数曲线应下降，到项目最后，两条曲线都趋向于零。PM会持续观察这张图表，确保项目健康发展，同时通过分析预测项目Bug趋于零的时间。

　　在一定的历史经验的基础上分析使用这一图表会得到很多有价值的信息，比如说，可分析开发和测试在人力资源的配比上是否恰当，可以分析出某个严重的Bug所造成的项目质量的波动。

　　每天的自动测试结果同样可以形成类似的图表。它同样非常有助于了解当前项目的质量状况，开发测试进度。

　　由测试产生的这些数据不仅在项目开发过程中为项目管理提供有效的依据，而且也是产品通过发布的必要条件。在微软，每个产品都要经过评审才能通过发布。前面介绍的几个图表是发布评审的重要内容，如果从图表中发现临评审前还出现过较大的质量波动，评审人员一定会对此提出质疑。 因此软件项目管理依赖软件测试提供其基本的管理素材。

　　可以说，现代大型软件开发过程中开发和管理对测试的依赖性是测试与开发流程融合的一个根本因素。从另一个角度看，测试与开发流程融合决不仅仅是简单的时间上的同步，更不是双方空间上的接近，而是这种内在的依存关系的外在表现。开发对测试的这种依赖性对测试和测是人员提出了更高的要求。在理念上，软件测试已远不仅仅只是软件功能的验证和Bug的搜寻;在具体方法上，自动测试和测试工具的使用已成为基本的要求。

　　在微软，测试不仅使用一些通用的工具，每一个产品还有专门开发的专用工具库，测试的代码量常常超过项目本身的代码量。 一个软件企业要提高其软件开发的能力，特别是针对大型软件的大规模的快速开发能力，在测试方面对传统理念和方法进行突破是必要的。微软的实践就是一个很好的印证。

　　一、职位名称含义：

　　即使你给玫瑰花起不同的名字，它闻起来可能还是同样的香。但是，如果你给工程师不同的职位名称，他们对自己职责的理解就会大不相同。微软将那些通过编写代码来开发产品功能的软件工程师统称为"软件开发工程师"(Software Development Engineer，SDE)。而微软测试工程师的正式职位名称是"软件开发测试工程师"(Software Development Engineer in Test，SDET)。这两个职称听起来很像，因为微软的测试工程师也同时做开发。测试工程师的其他主要职责包括：制定测试计划、设计测试用例、分析缺陷的根本原因、参与程序代码的审查和产品设计的审查，以及开发测试自动化程序。有时测试工程师也参与产品源代码的开发，或缺陷的修正等工作。但总的来说，因为测试工程师的工作量很大，所以直接参与产品开发的情况并不是很普遍。

　　雇用对测试有激情的软件工程师做测试工作是微软行之有效的创新，它完全不同于软件行业其他公司的做法。对此外界常得出一种结论，认为我们雇用会编写程序代码的工程师来做测试工作是因为我们想让他们编写有效的自动化测试程序，从而排除手工测试。其实这只是其中的一小部分原因。那些懂得怎样编写程序和计算机基本构造的测试工程师，常常具有软件测试所必备的分析技能。他们能够尽早发现缺陷并分析其根本起因，这使得他们能很快发现类似的缺陷。拥有和开发工程师一样的计算机基础增强了测试工程师的技能，给了我们的测试工程师更灵活和动态的生产力。

　　2005年以前，微软将软件测试人员人分为：软件测试工程师(Software Test Engineer，STE)和软件开发测试工程师(SDE/T)。SDE/T 和STE的分工。

　　可以看出，STE的工作更贴近于我们一般黑盒测试人员的工作，专注于测试计划、测试用例、测试的执行以及设计方案的审查;而SDE/T 的工作内容则是开发测试工具(安全、性能、自动化方面的工具的开发)以及找bug、参与设计方案审查、代码审查等一般的测试工作。(ps:只用大牛公司才会设开发测试工具的测试人员，呵呵)

　　2005年以后，微软调整了测试职称，将所有的测试人员统称为：软件测试开发工程师(SDET)

　　微软的SDET培训路线图：

　　二、微软的测试架构师

　　微软1999年设立测试架构师职称。是专门为那些对产品有影响的高级独立贡献者而设的。测试架构师的职称反映了一个SDET对其所工作的产品的广泛影响力。而高级SDET、首席SDET、合伙人SDET的职称则主要是给那些对某个产品的功能产生影响的人。

原文转自：http://www.ltesting.net