微软 软件测试

谓自动化，就是由测试工程师写出测试程序来运行测试案例，而并非人们所想象的人工点、点、点的那种测试方式。)

每个产品的测试都包含了基本的测试，如功能测

试、压力测试、代码覆盖率校验、插入测试、与其他产品交互的测试，还有全球化和本地化测试。在测试用例上，几乎永远是越多越全面越好。

2

测试Windows XP操作系统某项目时，仅对几个

DLL文件的测试就写了两千多个测试用例。

微软的测试工具基本上都是自己开发的，虽然商

业性比较差，但对产品的针对性很强。除了常用的十种左右的测试工具外，往往需要测试人员针对项目开发很多测试工具。

3

一、微软的测试人员微软的软件测试人员分为两类:

1.测试工具软件开发工程师(SDE/T)Software DevelopmentEngineer in Test:负责写测试工具代码，并利用

测试工具对软件进行测试；或者开发测试工具为软件测试工程师服务。产品开发后的性能测试(Performance Test)、提交测试(Check-in Test)等过程，都有可能要用到SDE/T 开发的测试工具。

由于SDE/T和SDE 的工作都是写代码，具有相通的地方，所以两者之间互相转换的情况比较多。但需注意的是，两者写出来的代码用途是不一样的，SDE 写的是产品的代码，而SDE/T 写的代码只用于测试产品。

2.软件测试工程师(STE)Software Test Engineer:负责理解产品的功能要求，然后对其进行测试，检查软件有没有错误(Bug)，决定软件是否具有稳定性，并写出相应的测试规范和测试用例。

4

除此之外，在一个软件产品的研发和销售过程中，还会需要负责给产品打补丁(Service Pack)的快速修正工程师(Quick Fix Engineer)，通常曲SDE 来担任，通过电话方式向用户提供售后技术支持的支持工程师(Support Engineer)，销售和市场(Sales and Marketing)人员，研究员和研究工程师(Researchers & Research SDE)。

5

在进行产品开发的时候，主要是由三类人员(项目经理、

开发人员及测试人员)组成产品开发团队来进行的。在微软内部，软件测试人员与软件开发人员的比率一般为1.5-2.5 左右，这可能远远超出了大家对测试人员的理解，但微软软件开发的实践过程已经证明了这种人员结构的合理性。

微软软件开发人员一般配制表

6

Exchange 2000Windows 2000

项目经理开发人员人

25 人140

约250 人约1700 人

测试人员

测试人员/开发人员

350 人2.5

约3200 人1.9

7

二、测试时应考虑的几个问题(1) 测试最重要的一件事就是要考虑到所有的出错可能性。同时，还要做一些不是按常规做的、非常奇怪的事。

测试的过程就像黑客(Hacker)的攻击过程那样。可以这么说，像黑客这样的人是最好的软件安全测试员。他们专门找软件的漏洞，从而破坏这个软件，这样就可以修复这些漏洞来保证软件的性能。如果找不到这种漏洞，那就说明该软件质量己经很好了。

8

(2) 除了漏洞之外，测试还应该考虑性能(Performance)问题，也就是一定要保证软件运行得很好，非常快，没有内存泄漏，不会出现那种越来越慢的情况。

例如在不关机的情况下，与其他软件一起持续运行一个多月，看看是否会出现越来越慢的情况(当然必须保证其他软件是没有问题的)。

微软在做IE 的时候，就是让它72小时连续不停地打开不同的网页，处理几万个不同的网页，而且速度不能减慢。有许多软件，当只有一两个人用的时候，可能感觉不到什么问题，而当几百个用户一起用的时候，有的网站就出现各种各样的异常，这就是测试工作还比较欠缺的缘故。

9

(3) 测试还要考虑软件的兼容性(Compatibility)

一般来说，一个软件是由许多小软件构成的，如

果其中一个小软件与它的前一版本不兼容，那么这个软件就会出现错误。这种错误需要通过测试来发现和解决。

10

在一般的开发团队中，并不需要测试人员定位Bug 的具体位置，所以，对测试人员的要求并不高。只要你愿意学，测试工作是非常容易做的。

但是，微软当年的IE 团队(IE4.0)因为正在与另一个公司的产品竞争，所以就要求尽量找到一流的开发人员和一流的测试人员，尽快开发出新产品，打败对手。当时对测试人员的要求非常严格，不仅要找出Bug，而且要定位引起此Bug 的代码行。然后将这些信息交给开发人员，后者就可以很快更正，省去了他们找错误出处的时间。因此，当时IE 的开发速度非常快，一年之内就发布了一个新版本，而且几乎役有任何大Bug，大大超越了竞争对手。

11

三、BugBug 的定义很广泛，在软件使用过程中所出现的

任何一个可疑问题，或者导致软件不能符合设计要求或满足消费者需要的问题都是Bug，即使这个Bug 在实践中是可行的。

有时候，Bug 并不是程序错误。

例如，软件没有按照一般用户的使用习惯来运行，此时也可以把这个问题看成是该软件的一个Bug。

12

微软开发一个产品经常会遇到几十万条Bug。随着测试人

员越来越多，测试工作也越来越完善。但是，如何快速有效地追踪并修复Bug，仍然是摆在软件测试人员面前的一个主要困难。

测试产品和追踪Bug 时最重要的是问题的定义，要清楚需要解决什么样的问题，确定Bug 的主次关系，挑选出最主要的问题，并先解决它们。



例如，有些Bug 可能会导致死机或程序崩溃，这时就要先修复它们，而另一些Bug 可能对软件的运行影响不大，或者出现的机会很少，就可以考虑以后再修复。

13

没有任何一个产品没有Bug，也永远不可能找出

并修复所有的Bug。在修复了旧的Bug 的同时，往往又会生新的Bug。

根据微软的经验，

每修复三到四个Bug一般就会产生一个新的Bug。

14

四、软件测试方法和辅助工具有了Bug 类型的定义以后，如何去找出这些Bug 

呢？这就需要采用好的测试方法。

有多种方式对软件测试方法进行分类。

15

从代码的特性角度(即内部)将软件测试方法分为

如下几种。

①单元测试(Unit Test): 按照代码的单元组成逐个进行测试。②功能测试(Function Test)或特性测试(Feature Test): 按照软件的功能或特性逐个进行测试。例如，在Exchange

中，发送邮件和接收邮件就是两个不同的功能或特性，在测试时就分别对它们进行检查，看是否工作正常。

16

③提交测试(Check-in Test):

在开发人员对代码做了任何修改，或者修复了某个Bug 时，需要重新Check-in 代码(即将修改后的代码放大到整个大的系统中)。这时，开发人员往往也要进行测试，看代码是否工作正常。为了保险起见，开发人员往往要找测试人员帮着一起进行测试。测试人员和开发人员之间搞好关系是非常重要的。

17

④基本验证测试(Build Verification Test，简称BVT): 对完成的代码进行编译和连接，产生一个构造，以检查程序的主要功能是否会像预期一样进行工作。这是最

简单而又最省时的一种测试方法。每产生一个新的构造时都要进行测试。如果连BVT 都通不过，表明问题很严重，开发人员需要尽快修复出现的问题，测试人员也就不用浪费时间做其他测试了。

18

⑤回归测试(Regression Test): 过一段时间以后，再回

过头来对以前修复过的Bug重新进行测试，看该Bug 是否会重新出现。

实际上，许多Bug都是在回归测试时发现的，在此阶段，首先要检查以前找到的Bug 是否已经更正了。值得注意的是，已经更正的Bug 也可能又回来了，有的Bug 经过修改之后可能又产生了新的Bug。所以，回归测试可保证已更正的Bug不再重现，不产生新的Bug。

19

从用户的角度(即外部)出发将软件测试方法分为

如下几种。

①配置测试(Configuration Test): 从用户的使用出发进行多方面的测试。

例如，保证软件不仅能够在Windows 9X 下运行，也能够在Windows ME 下运行，还能够在Windows NT/200O/XP 下运行;或者软件不仅能够在配置高的计算机上运行，也能够在配置很低的计算机上正确地运行。总之，要考虑到用户的多种情况，用

多种配置对软件进行测试。

20

②兼容性侧试(Compatibility Test): 主要考虑兼容性问

题。

例如同一个产品的不同版本(如Office 2O00 和Office XP)之间的兼容问题，不同厂家的同一个产品(如IE 和Netscape)之间的兼容

问题，不同类型软件(如IE 和Office)之间的兼容问题等。最难测

试的往往就是软件的兼容性问题，往往要投人巨大的人力和物力。一些厂商开发出来的产品在兼容性上做得很

不好，就是因为没有足够的人力和物力进行测试。

21

微软在做SQL Server 的XML 测试的时候，

为了解决XML 的兼容性问题，用了6 个测试人员和100 台计算机进行测试。因此，微软产品的兼容性都非常好。而不像市场上的一些产品，安装以后就导致计算机上的许多其他软件无法使用，或者出现各种各样的问题，这样不仅伤害了其他

软件，也伤害了用户。

22

③压力测试(StressTest): 在各种极限情况下对产品进行测试(如很多人同时使用该软件，或者反复运行该软件)，以检查产品的长期稳定性。

例如，微软在开发IE 4.0 的时候，由于当时有一个非常强的竞争对手，因此必须保证IE4.0 要做得非常好。当时，为了测试IE4.0 的长期稳定性，微软专门设计了一套自动测试程序，它一分钟可以下载上千个页面。使用这个测试程序对IE4.0 进行了连续72 小时的测试，也没有出现任何问题，如内存泄漏、程序崩溃等。

本项测试可以帮助找到一些大型的问题，如死机、崩溃、内存泄漏等，因为有些存在内存泄漏问题的程序，在运行一两次时可能不会出现问题，但是如果运行了成千上万次，内存泄漏得越来越多，就会导致系统崩溃。

23

压力测试时间要求:

根据微软的实践经验，如果一个软件产品能通过72 小时的压力测试，则该产品超过72小时后出现问题的可能性微乎其微。所以，72 小时就成为微软产品压力测试时间的标志。24

④性能测试(Performance Test): 本项测试是保证程序

具有良好的性能。

如果别人的产品只需5 秒钟就能得出结果，而你的产品需要10 秒钟才能得出结果，就说明你的产品性能不好。如果在测试过程中发现性能问题，修复起来是非常艰难的，因为这常常意味着程序的算法不好，结构不好，或者设计有问题。因此在产品开发的开始阶段，就要考虑到软件的性能问题。

25

⑤文档和帮助文件测试(Documentation and help file Test): 用户通常是通过文档和帮助文件来学习使用产品的，如果文档和帮助文件存在错误，就可能会导致用户无法正常使用产品。

这项工作通常在产品即将准备包装发布时进行，以避免在修复Bug 的过程中需要反复修改文档，或者忘记修改文档，导致文档与产品的特性不相符。

26

⑥Alpha 和Beta 测试(Alpha and Beta Test): 在正式发布产品之前往往要先发布一些测试版，让用户能够反馈出相关信息，或者找到存在的Bug，以便在正式版中得到解决。

27

自动测试（Automation Testing）即编写一些测试工具，让他们自动运行来查找Bug。

自动测试的优点是能够很快、很广泛地查找Bug，缺点是

它们只能检查一些最主要的问题，如崩溃、死机，但是却无法发现一些一般的日常错误，这些错误通过人眼很

容易找到，但机器却往往找不到。

另外，在自动测试中编写测试工作量也很大，因此在实

际测试中通常是手工测试和自动测试相结合

28

自动测试案例一Exchange Server 项目中常常要做一种Stress Test，需要几万个甚至几十万个用户同时把E-mail 发送到服务器(Server)，以保证Server 不会出现死机或崩溃的现象。可是，需要几万人同时发送E-mail，这在现实生活中很难人为实现。但是，利用测试工具就可以非常容易地做到。测试工具可以自动产生几万个账号，并且让它们在同一时间从不同机器上(一个机器上可以有多个不同的账号)同时发送Email信息。

29

自动测试案例二浏览Web 页面：

要求50000 个用户同时浏览一个

Web 页面，以保证网站的服务器(Server)不会死机。

一般来说，找到50000 个用户同时打开一个网页是不现实的，就算能够找到50000 个测试者，成本也非常高。但是通过测试工具则很容易做到，并且工具还可以自动判断浏览结果是否正确。

30

如果不懂得有效地进行测试，你不仅得不到功劳，也没人欣赏你的苦劳，你拥有最多的将只是疲劳。

职业软件工程师应当掌握需求开发、系统设计、编程、测试、维护所有技能。

31

企业招聘---测试人员Testers

主要包含以下角色：

n测试经理Test Managern测试分析员Test Analystn测试设计员Test Designern测试员Tester

角色1: 测试经理Test Manager定义负责项目测试任务，以确保测试活动成功的角色软件测试职责l协商测试工作的目标与提交的成果，管理测试活动的范围，并据此制定测试计划l为测试活动分配人力资源和获取测试设施l监督项目测试活动的进度和效果l解决阻碍测试开展的矛盾和问题l通过发现重要的缺陷来推进项目产品的质量水平l关注软件开发过程并推动改善工件（需求、代码等）的可测试性lllll具备软件开发过程各个方面的基本知识拥有测试方法、技术和工具等广泛的经验掌握计划和管理的技能熟悉被测试系统领域的相关知识拥有编程经验确定测试任务、识别测试动因、获取测试承诺、评估和推进产品质量、评估和改进测试活动专业技能活动工作测试计划、变更请求、事项列表、测试评估总结33角色2: 测试分析员Test Analyst软件测试定义负责识别和定义所需测试，监督具体测试进展和成果的角色

llllllllllll

识别将通过测试来验证的测试对象条目定义合适的测试要求和相关的测试数据收集和管理测试数据分析各测试周期的结果

具备软件开发过程各个方面的基本知识拥有良好的分析技能关注细节并且坚忍不拔

对软件常见的失效与错误有充分理解拥有测试方法、技术和工具等广泛的经验熟悉被测试系统领域的相关知识拥有测试经验

可以由需求阐释员兼任，方便按照用例编制测试用例

34

职责

专业技能

软件测试识别测试对象、确定测试思路、定义测试细节、确定评估和跟踪活动

要求、判断测试结果、验证各构造版本中的变更

测试计划、测试评估总结、变更请求、测试指南、测试思路列表、工作

测试用例、测试数据、测试结果记录、工作负载分析模型

35

角色3: 测试设计员Test Designer定义

软件测试负责针对测试目标设计测试途径以确保测试被成功实施的角色

职责

lllllllllllllll

确定并描述相应的测试技术确定相应的测试支持工具定义并维护测试自动化架构详述和验证需要的测试环境配置验证与评估测试途径

具备软件开发过程各个方面的基本知识拥有验证测试成果的经验

具备诊断和解决调试问题的技能

拥有硬件与软件安装、配置等的广博知识拥有使用自动化测试工具的成功经验对软件常见的失效与错误有充分理解深入掌握被测试系统领域的相关知识拥有编程经验

具备开发团队领导和软件设计的技能可以由软件架构师充当本角色

36

专业技能

软件测试活动

定义测试途径、确定测试机制、定义测试环境配置、组织测试实施元素、定义测试元素测试计划、测试脚本、测试自动化构架、测试界面规格、测试环境配置、测试套件

工作

37

角色4: 测试员Tester定义

负责遵照设计的测试途径负责实施测试角色.

软件测试职责

lllll为给定的测试确定最合适的实施途径实施各个测试设置并执行测试

记录测试结果并验证测试的执行分析执行遇到的错误并从中恢复具备软件开发过程各个方面的基本知识接受过使用相应自动化测试工具的培训拥有使用自动化测试工具的经验具备诊断和调试的技能拥有编程经验

可以由测试分析员充当本角色

38

lll

专业技能

lll

软件测试活动实施测试、实施测试套件、执行测试套件、分析测试失败

工作测试套件、测试脚本、测试记录、变更请求

39

对于一个一次性水杯，该如何设计测试用例？

考虑方面:

功能、性能、易用性、可操作性、稳定性方面进行测试;

功能方面的测试，主要是考虑这个水杯是否能盛水，能盛多少水，能否盛热水，盛热水又能盛多少;

性能方面，盛冷水和热水时分别盛多少水杯能够承受;易用性方面，水杯易用手拿或端着;

可操作性，也可以说和易用性相似，当盛冰水时感觉不到很冷。

40

测试驱动开发水杯类：父类（杯子）

属性，如材料、形状、容量等方法，如盛水等

水杯可以装泥土当花盆用，要提供花盆的接口

水杯的子类：如一次性杯子等等

重写或添加属性、方法

容错：所装物体判断（物体的类别、物体的属性）

执行方法的前提判断（某些属性已经赋值，有托盘则执行端的方法，有把手则执行拿的方法……）

操作时注意，某个静态字段是否超出数值范围。

41

测试项目：杯子需求测试:查看杯子使用说明书界面测试:查看杯子外观

功能度：用水杯装水看漏不漏；水能不能被喝到安全性：杯子有没有毒或细菌

可靠性：杯子从不同高度落下的损坏程度

可移植性：杯子在不同的地方、温度等环境下是否都可以正常使用

兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等

42

易用性：杯子是否烫手、是否有防滑措施、是否方便饮用

用户文档：使用手册是否对杯子的用法、、使用条件等有详细描述

疲劳测试：将杯子盛上水（案例一）放24小时检查泄漏时间和情况；盛上汽油（案例二）放24小时检查泄漏时间和情况等

压力测试：用根针并在针上面不断加重量，看压强多大时会穿透

跌落测试: 杯子加包装(有填充物),在多高的情况摔下不破损

43

震动测试: 杯子加包装(有填充物),六面震动,检查产品是否能应对恶劣的铁路\\公路\\航空运输……

测试数据：具体编写的测试数据…… 。应用到：等价类划分法、因果图法、错误推测法、边界值法等方法

期望输出：该期望输出需查阅国标、行标以及使用用户的需求

44

简介软件测试是软件工程过程中的关键组件。

软件测试是软件质量保证的要素，可以将其描述为一个运行程序以检测错误（如果有）的过程。

45

测试的常识与道理编程大师说：没有错误的程序世间难求。（《编程之道》）

你在学校里学过测试吗？（读到博士可能也不懂测试）

你所在的企业重视测试吗？（小公司程序员的技能更加全面）

临时抱佛脚行吗？你以为有文档模板就会测试了吗？

46

测试的目的是什么•测试的目的是为了发现尽可能多的缺陷，不是为了说明软件中没有缺陷。

•推论：成功的测试在于发现了迄今尚未发现的缺陷。所以测试人员的职责是设计这样的测试用例，它能有效地揭示潜伏在软件里的缺陷。

―千万不要将“测试”与“演示”混为一谈。例如科研鉴定会。

―如果产品通过了严格的测试，大家不要不吭气，应当好好地宣传一把。

47

完全测试程序是不可能的

－输入量太大

－输出结果太多

－软件实现途径太多

－软件说明书没有客观标准。从不同角度看，软件缺陷的标准不同。

48

软件测试是有风险的行为

测试无法显示潜伏的软件缺陷

找到的软件缺陷越多，就说明软件缺陷越多并非所有软件缺陷都能修复

软件测试一项讲究条理的技术专业

49

静态和动态测试进行结构和功能测试测试阶段可行性评审需求评审设计评审单元测试集成测试系统测试验收测试执行人开发人员，用户开发人员，用户开发人员开发人员开发人员，用户开发人员在用户的协助下完成用户静态校验√√动态校验√√√√√50

测试技术软件测试技术静态测试动态测试代码走查技术评审代码审查黑盒测试功能测试性能测试攻击测试回归测试语句覆盖白盒测试分支覆盖路径覆盖51

测试产品说明书对于产品说明书的制定是个很重要的设计阶段，产品说明书的质量会直接影响到整个产品开发。测试产品说明书属于静态黑盒子测试。

52

常用测试用语－测试用例测试用例：编写用于输入输入的实际数制和预期结果。测试用例还明确指出使用具体测试用例产生的测试程序的任何。使用目的：

―测试用例应该设计为能够快速容易地发现尽可能多的错误。

―应该通过使用和产生正确和错误的输入和输出来“检验”程序。

―其目标是要使用合理范围内的条件，尽可能全面地测试所有模块乃至整个系统。

53

测试与调试－什么是缺陷缺陷：最终产品同用户的期望不一致缺陷的分类

错误遗漏

超出需求的部分

缺陷（未触发）VS.错误（应首先解决）

54

测试阶段2-1•单元测试、集成测试、系统测试、验收测试。是“从小到大”、“由内至外”、“循序渐进”的测试过程，体现了“分而治之”的思想。

•单元测试的粒度最小，一般由开发小组采用白盒方式来测试，主要测试单元是否符合“设计”。

•集成测试界于单元测试和系统测试之间，起到“桥梁作用”，一般由开发小组采用白盒加黑盒的方式来测试，既要验证“设计”又要验证“需求”。

55

测试阶段2-2•系统测试的粒度最大，一般由测试小组采用黑盒方式来测试，主要测试系统是否符合“需求规格说明书”。•验收测试与系统测试非常相似，主要区别是测试人员不同，验收测试由用户执行。

56

测试内容测试内容一般包含

接口与路径测试。

功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试…

57

测试阶段对应表测试阶段

主要依据

测试人员、测试方式

主要测试内容

单元测试

系统设计文档

系统设计文档

需求文档需求文档

由开发小组执行白盒测试

由开发小组执行白盒测试和黑盒测试

接口测试、路径测试

集成测试

接口测试、路径测试功能测试、性能测试

系统测试

由测试小组执行黑盒测试

由用户执行黑盒测试

验收测试需求文档

功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试

58

测试常见问题2-1问题1：有了“黑盒”测试为什么还要“白盒”测试？问题2：由于单元测试要写测试驱动程序，非常麻烦，能否等到整个系统全部开发完后，再集中精力进行一次性地单元测试呢？

问题3：如果每个单元都通过了测试，把它们集成一起难道会有什么不妥吗？集成测试是否多此一举？

59

测试常见问题2-2问题4：在集成测试的时候，已经对一些子系统进行了功能测试、性能测试等等，那么在系统测试时能否跳过相同内容的测试?

问题5：既然系统测试与验收测试的内容几乎是相同的，为什么还要验收测试？

问题6：能否将系统测试和验收测试“合二为一”？

60

总结2-1测试可以将测试描述为一个运行程序以发现错误的过程。

软件测试的准则:不完全测试、风险测试、无法显示潜伏错误、发现错误成线性增长、缺陷不能完全修复、测试有条理规程

测试的方法:黑盒/白盒、静态/动态

软件测试的各个阶段：单元测试、集成测试、系统测试、验收测试

61

总结2-2测试的内容包括：接口/路径测试、功能测试、性能测试、压力测试、可靠性测试、安全性测试、用户界面测试、安装/反安装测试

62