微软的软件测试方法
软件测试复习大纲
软件测试方法和技术一、名词解释☐软件测试（IEEE）定义：在特定的条件下运行系统或构件，观察或记录结果，对系统的某个方面做出评价，分析某个软件项以发现现存的和要求的条件之差别（即错误）并评价此软件项的特性。
更完整的定义：软件测试是由“验证（Verification）”和“有效性确认（Validation）”活动构成的整体☐测试驱动开发（TDD Test Driven Development），即测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码，然后只编写使测试通过的功能代码，从而以测试来驱动整个开发过程的进行。
这有助于编写简洁可用和高质量的代码，有很高的灵活性和健壮性，能快速响应变化，并加速开发过程。
☐软件质量：软件产品具有满足规定的或隐含要求能力要求有关的特征与特征总和(ISO 8492)或者书P15：质量是产品或服务所满足明示或暗示需求能力的固有特性和特征的集合☐软件缺陷：P18（软件缺陷的现象也在该页）☐人工检测：人工检测偏重于编码风格、质量的检验，对设计、代码进行分析，有效地发现逻辑设计和编码错误。
☐计算机辅助静态分析：利用静态分析工具对被测程序进行特性分析，从程序中提取一些信息，以便检查程序逻辑的各种缺陷和可疑的程序构造。
☐主动测试方法：测试人员主动向被测试对象发送请求、或借助数据、事件驱动被测试对象的行为，从而验证被测试对象的反应或输出结果☐被动测试方法：测试人员不干预产品的运行，而是被动地监控产品在实际环境中运行，通过一定的被动机制来获得系统运行的数据，包括输入、输出数据.☐系统非功能性测试是将软件放在整个计算机环境下，包括软硬件平台、某些支持软件、数据和人员等，在实际运行环境下进行一系列的测试P29☐错误推测法：是测试者根据经验、知识和直觉来发现软件错误，来推测程序中可能存在的各种错误，从而有针对性的进行测试P38☐独立路径：至少引入一系列新的处理语句或条件的任何路径☐基本集：由独立路径构成的集合☐基于模型的测试 (MBT, Model-based testing）：通过构建能够正确描述被测软件系统功能特性的模型，然后基于这个模型产生测试用例并执行这些测试用例的过程P57☐状态迁移图（state transition diagram，STD）：描述系统状态变化的动态信息——动态说明，由状态和迁移来描述，状态指出数据输入的位置（或时间），而迁移则指明状态的改变。
vs2019 单元测试用例
vs2019 单元测试用例
Visual Studio 2019是微软公司推出的一款强大的集成开发环境，它支持多种编程语言和框架，包括C#、等。
在Visual Studio 2019中，我们可以使用单元测试来验证我们的代码是否正确。
单元测试是一种软件测试方法，它可以帮助我们快速发现代码中的错误和漏洞。
在Visual Studio 2019中，我们可以使用NUnit、xUnit等单元测试框架来进行单元测试。
这些框架提供了丰富的测试工具和功能，可以帮助我们编写高质量的单元测试用例。
要编写单元测试用例，首先需要创建一个测试项目。
在Visual Studio 2019中，我们可以使用“新建项目”向导来创建一个新的测试项目。
然后，我们需要添加一个或多个测试类到项目中。
每个测试类都应该包含一个或多个测试方法，用于测试不同的功能或场景。
在编写单元测试用例时，需要注意以下几点：
1. 确保测试用例具有独立性和可重复性。
每个测试用例都应该独立于其他测试用例运行，并且可以在不同的环境中重复运行。
2. 确保测试用例覆盖了所有可能的输入和输出情况。
我们应该尽可能地覆盖各种边界条件和异常情况，以确保代码的稳定性和可靠性。
3. 确保测试用例易于维护和扩展。
我们应该使用简洁明了的语言来编写测试用例，并尽可能地减少冗余代码和重复操作。
WHQL测试指南
WHQL测试指导书版本日期浏览修订者审核V0.1 2010-11-30V0.22010-12-27目录WHQL测试指导书 (1)目录 (2)WHQL认证简介 (3)注意事项 (4)第一章总体设计 (7)2.1 工作组方式 (7)2.2 域环境方式 (7)第二章软件安装步骤 (9)3.1 Controller端的操作 (9)1、安装虚拟光驱 (9)2、安装Driver Test Manager (10)3、安装Driver Logo printing (11)4、更新errata filter (12)5、安装Windows DTM Studio (14)3.2 Client端的操作 (15)安装需要被测试的驱动软件 (15)安装Windows DTM Studio (15)第三章软件测试步骤 (17)第四章结果分析 (23)测试项执行状态 (23)测试结果分析工具 (25)第五章信息提取 (26)信息提取 (26)提交认证 (27)第六章附录 (28)系统要求 (28)局域网网络共享设置 (30)工作组和域模式区别 (35)Framework安装步骤 (38)USB测试 (41)过滤工具errata filter更新步骤 (47)WHQL常遇疑问与解答 (52)常用WHQL认证链接 (60)WHQL认证简介WHQL认证简介：WHQL是Windows Hardware Quality Labs的简称，意思为“Windows操作系统硬件品质实验室”，该实验室的主要工作在于测试电脑周边硬件产品、驱动程式与操作系统的相容性及稳定性。
微软WHQL（Windows操作系统硬件品质实验室商标）是微软(Microsoft)为了确保计算机硬件与Windows窗口操作系统能够兼容所制定，凡是通过WHQL 的认定，便可以在其产品上标注“WHQL”验证规格，有了“微软”背书，消费使用者只要购买了具有WHQL规格的产品，都可得到很大程度的保障。
使用VBA编写自动化测试脚本的步骤与技巧
使用VBA编写自动化测试脚本的步骤与技巧自动化测试是软件开发过程中重要的一环，它通过编写测试脚本和工具来模拟用户操作，自动执行各种测试任务，从而提高测试效率和准确性。
VBA（Visual Basic for Applications）是一种用于编写微软 Office 应用程序的宏语言，它可以用于自动化测试脚本的编写。
本文将介绍使用 VBA 编写自动化测试脚本的步骤和技巧。
第一步，了解被测试的应用程序和测试需求。
在编写自动化测试脚本之前，需要对被测试的应用程序进行全面的了解，并明确测试的需求。
这包括应用程序的功能、用户操作流程、输入和输出数据等。
只有充分了解应用程序和测试需求，才能更好地编写符合需求的测试脚本。
第二步，选择合适的开发工具。
VBA 通常是和 Microsoft Office 应用程序一起使用的，所以选择合适的 Office 软件，如 Excel、Word 或 PowerPoint 作为开发和执行自动化测试脚本的平台。
同时，也可以结合使用 VBA 编辑器和宏录制工具来编写测试脚本。
第三步，学习 VBA 语法和基本概念。
要编写有效的 VBA 脚本，需要掌握 VBA 的语法和基本概念。
可以通过官方文档、教程和在线资源等途径学习 VBA 的基础知识，特别是变量、数据类型、条件语句、循环语句等重要概念。
此外，了解应用程序提供的 VBA 对象模型，可以帮助更好地理解和使用 VBA。
第四步，设计测试用例和流程。
在编写自动化测试脚本之前，需要先设计好测试用例和流程。
测试用例应该覆盖被测试应用程序的各个功能模块和场景，并定义好输入数据、预期输出和测试判定标准。
测试流程应包括测试脚本的执行顺序、测试数据准备、测试环境配置等重要步骤。
这样可以确保测试脚本的完整性和有效性。
第五步，编写测试脚本。
在 VBA 编辑器中，通过编写 VBA 代码来实现测试脚本的自动化执行。
在编写脚本时，可以使用 VBA 提供的函数、方法和属性来操作应用程序对象，模拟用户的各种操作。
软件测试需要学什么语言
软件测试需要学习什么语言引言在当今的软件开发行业中，测试是确保软件质量的重要环节。
软件测试涉及到多种技术和工具，其中语言的选择对于测试人员来说是至关重要的。
本文将探讨在软件测试中学习哪些语言对测试人员来说是有益的。
1. JavaJava是一种广泛使用的编程语言，特别适合于构建和测试大型软件系统。
学习Java语言对于软件测试人员来说是非常重要的，因为许多测试工具和框架都是用Java编写的。
以下是一些与Java相关的测试工具和框架：•JUnit：这是Java中最常用的单元测试框架之一，用于编写和运行单元测试。
•TestNG：可替代JUnit的测试框架，提供更多的测试功能和灵活性。
•Selenium：这是一个用于自动化Web应用程序测试的工具，支持Java语言编写测试脚本。
•Appium：一种用于测试移动应用程序的自动化框架，也支持Java语言编写脚本。
2. PythonPython是一种简单易学的编程语言，广泛应用于软件测试领域。
它以其简洁的语法和丰富的测试库而闻名，成为软件测试人员的首选语言之一。
以下是一些与Python相关的测试工具和框架：•pytest：这是Python中最受欢迎的测试框架之一，用于编写各种类型的自动化测试。
•behave：一个用于行为驱动开发(BDD)的测试框架，使用自然语言编写测试场景。
•Robot Framework：一种通用的自动化测试框架，支持关键字驱动和数据驱动的测试方法。
•Appium-Python-Client：Appium的Python客户端库，用于编写移动应用程序测试脚本。
3. CC#是一种由微软开发的专为.NET平台设计的编程语言，用于构建Windows桌面和Web应用程序。
在软件测试领域，C#在一些特定的测试工具和框架中被广泛使用。
以下是一些与C#相关的测试工具和框架：•NUnit：与JUnit类似的C#测试框架，用于编写和运行单元测试。
•SpecFlow：一个用于BDD的测试框架，使用Gherkin语言编写测试场景。
国外软件测试经典案例
国外软件测试经典案例做开发之前，做过一年半测试，那还是long long ago了。
第一份工作就是测试。
微软外包。
别人在测试完了以后不知道在干嘛，我抓紧时间看vs的源代码，抓紧时间看pheonix的源代码，抓紧时间看微软那个Perl和bat写的自动化测试系统的源代码然后因为加班太多，老子不干了。
第二份工作还是测试。
本来想去做开发的，但是必须直面惨淡的人生，淋漓的鲜血。
一下子找不到信任测试做开发的下家。
没关系，我先做测试再说。
别人测试完了以后不知道在干嘛，我在学lua写游戏引擎的脚本系统，我在用lua和之前学到的微软那个东西做自动化测试系统，再然后，我用微软学来的东西和lua山寨了一个自动化测试系统。
从那以后，我就不像个上班的样子了，因为完全自动化。
别人上班我看看片上上网写写代码装装样子，做了一年，本来可以转开发了，结果金融危机人事冻结，我留了点工作成绩，被裁员了。
再然后，我就开始做开发了，因为我有了工作成绩的证明。
现在，我每天花时间写代码的时间都块比不上刷知乎的时间了，因为曾经的积累，现在工作起来越来越顺手容易了，偶尔有时候贪玩了没做完，回家复制粘贴修修补补一下也就完成任务了……你看明白我这个故事想说什么了吗？是的，我想说，他妈的没接触到技术性的东西你不会自己去接触啊，都二十好几的人了，还在等人把东西嚼碎了喂你嘴里当年我呆的外包公司别说随便上网了，连u盘都不让带，就接触不到技术性的东西了？我不也一样发挥主观能动性找到了岗位的资源优势？实在不行，现在移动上网包个月能有多少钱？该花的钱省什么省？自己不动脑筋去研究一个职位的核心竞争力和可以发展的硬实力，怪这个职位无聊咯？还功能性测试无聊，功能性测试怎么会无聊？你有设计过网络爆卡的时候丢包率高的环境下，网购页面内容吗？你有试过系统重启浏览器缓存cookie历史统统清楚以后的购物车吗？你有试过互相冲突的选择数据有没有问题吗？更极端一点，你有计算过点击两个按钮的鼠标操作移动距离是不是顺手啊？有开过f12看请求是不是加密，加密是不是严谨啊？那些说测试工作无聊的人，你们有办法让每天测试最新版本程序对于30万个不同case 的处理结果然后自动整理通过个数通过率以及出问题的case和出问题的回滚历史版本号吗？这个其实还相对简单，你们能每天管理一个实验室里上百台不一样的虚拟机重装系统重装测试环境然后重新测试保证测试过程不被干扰吗？最后，30万个case都做不到没有遗漏，你们那些靠人工的，能有多少覆盖率……还不动脑筋想想的话，就更惨不忍睹了。
软件测试流程
二 软件测试的流程
图三 测试各阶段示意图
软件测试流程
三 单元测试
一．单元测试的定义 单元测试[Unit Testing]是对软件基本组成单元进行的测试,单元测试的对象是软件设 计的最小单位——模块,很多人将单元的概念误解为一个具体函数或一个类的方法,这种 理解并不准确,作为一个最小的单元应该有明确的功能定义、性能定义和接口定义,而且 可以清晰地与其他单元区分开来,一个菜单、一个显示界面或者能够独立完成的具体功 能都可以是一个单元,从某种意义上单元的概念已经扩展为组件[component],
软件测试流程
四 集成测试
二．集成测试的层次 软件的开发过程是一个从需求分析到概要设计、详细设计以及编 码实现的逐步细化的过程,那么单元测试到集成测试再到系统测试 就是一个逆向求证的过程,集成测试内部对于传统软件和面向对象 的应用系统有两种层次的划分, 对于传统软件来讲,可以把集成测试划分为三个层次： 模块内集成测试; 子系统内集成测试; 子系统间集成测试, 对于面向对象的应用系统来说,可以把集成测试分为两个阶段： 类内集成测试; 类间集成测试,
软件测试流程
一.一 软件测试的复杂性
图一 最优测试量示意图
软件测试流程ຫໍສະໝຸດ 一.二 软件测试的经济性软件测试的经济性有两方面体现： 一是体现在测试工作在整个项目开发过程中的重要地位; 二是体现在应该按照什么样的原则进行测试,以实现测试成本与测 试效果的统一, 软件工程的总目标是充分利用有限的人力和物力资源,高效率、高 质量地完成测试,
块,再把所有模块按设计要求放在一起结合成所需要实现的程序,如图 七是所示按照一次性集成测试方式的实例
软件测试流程
四 集成测试
图七 一次性集成测试方式
软件测试概述
软件测试工程师主要负责理解软件的功能要求,然 后对其进行测试,检查软件有没有错误,决定软件是 否具有稳定性,并写出相应的测试方案和测试用例
在微软内部,软件测试人员与软件开发人员的比率 一般为一.五~二.五左右,微软软件开发的实践过程 已经证明这种人员结构的合理性
课程内容
软件测试基本概念 软件测试技术 软件测试方法 软件测试流程 微软软件测试简介
微软公司软件测试简介
基本思想 测试人员 测试文档
基本思想
测试人员的任务就是站在使用者的角度上, 通过不断地使用和攻击刚开发出来的软件, 尽量多地找出软件中存在的问题
基本思想
在测试时主要考虑以下几个问题：
测试成功率：
有多少测试已经通过了,并且有多少是运行正常 的!需记录以下值：
已通过的测试用例的数目 可利用的测试用例的数目
软件测试的分类
典型的软件测试类型
功能测试 可靠性测试 容错性测试 恢复测试 易用性测试
– 性能测试 – 可维护性测试 – 可移植性测试 – 安全性测试 – 用户文档测试
语句覆盖方法 分支覆盖方法 逻辑覆盖方法
动态测试和静态测试
动态测试
动态测试需要在开发/测试环境或实际运行环境 中运行软件,并使用测试用例去查找软件缺陷
动态测试包括功能确认与接口测试、覆盖率分 析、性能分析、内存分析等
动态测试和静态测试
静态测试
静态测试不实际运行软件,主要是对软件的编程 格式、结构等方面进行评估
手工测试和自动测试
手工测试 自动测试 适合自动化的测试操作 手工测试和自动测试的比较
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
国内近年来关于软件测试的问题和讨论越来越活跃。
但从总体上说交流软件测试技术的多，而探讨软件测试方法的少。
这里的“技术”指的是具体的战术问题，比如说如何使用某种工具来解决某一特定测试问题，或者某一类型软件有哪些测试手段等等。
而这里的“方法”指的是宏观的战略问题，或者叫方法论，这包括从软件测试的概念或理念，到企业软件质量控制体系；从软件测试的过程，到测试团队的设置及其职责的界定等等。
作为测试人员，热衷于“技术”讨论和交流是一件可喜可贺的事。
从中可以感觉到软件测试在中国迅速发展的开端和潜力。
但是作为企业的管理决策者，是否也应该以同样的热情来思考“方法”问题呢？特别是当一个软件企业的软件测试从无到有，或者当企业已有一定的软件测试的投入，但发现其实效并不显著，甚至由于测试的引入而带来了新的管理上的混乱。
这个时候方法论的思考，更有利于发现问题的根源。
即便是一个基层的测试人员，当积累了一定的技术经验后，也应该不时从日常的具体工作中走出来，在一个较高层次上进行回顾总结和借鉴，并试着提出一些优化和改进的措施，这无论对专业上还是对事业上的成长都是非常有意义的。
微软在软件测试方面有很多值得一提的经验，在此我想以我个人的体会和思考，同大家一同进行一些探讨。
这里有一点须要特别说明，尽管微软的方法已被微软的实践多次证明是成功的，非常有效的，但这并不意味着这些方法在中国的软件企业中有广泛的可行性。
一种方法是否可行还受到很多其他因素的影响，比如企业类型（微软是生产平台软件和通用软件产品的企业），企业管理体制，企业文化等等。
所以我的目的只是给大家一些思路和借鉴。
两类经典的软件测试方法在具体介绍微软的软件测试方法之前，我想首先从概念，或理念的层面上来理解究竟甚么是软件测试，目的是从中导出微软测试方法的理论根源。
传统上认为软件测试的方法从总体上分为两类。
第一类测试方法是试图验证软件是“工作的”，所谓“工作的”就是指软件的功能是按照预先的设计执行的；而第二类测试方法则是设法证明软件是“不工作的”。
提出第一类方法的代表人物是软件测试领域的先驱Dr. Bill Hetzel（代表论著《The Complete Guide to Software Testing》），他曾于1972年6月在美国的北卡罗来纳大学组织了历史上第一次正式的关于软件测试的论坛。
他首先在1973年给软件测试一个这样的定义：“就是建立一种信心，认为程序能够按预期的设想运行。
Establish confidence that a program does what it is supposed to do.”后来在1983年他又将定义修订为：“评价一个程序和系统的特性或能力，并确定它是否达到预期的结果。
软件测试就是以此为目的的任何行为。
Any activities aimed at evaluating an attribute or capabilityof a program or system. ”在他的定义中的“设想”和“预期的结果”其实就是我们现在所说的用户需求或功能设计。
他还把软件的质量定义为“符合要求”。
第一类测试可以简单抽象地描述为这样的过程：在设计规定的环境下运行软件的功能，将其结果与用户需求或设计结果相比较，如果相符则测试通过，如果不相符则视为Bug。
这一过程的终极目标是将软件的所有功能在所有设计规定的环境全部运行，并通过。
在软件行业中一般把第一类方法奉为主流和行业标准。
1990年的IEEE/ANSI 标准将软件测试进行了这样的定义：“就是在既定的状况条件下，运行一个系统或组建，观察记录结果，并对其某些方面进行评价的过程。
The process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component (IEEE/ANSI, 1990 [Std610.12-1990]”这里所谓“既定的状况”也可理解为需求或设计。
尽管如此，这一方法还是受到很多业界权威的质疑和挑战。
代表人物是Glenford J. Myers（代表论著《The Art of Software Testing》）。
他认为测试不应该着眼于验证软件是工作的，相反应该首先认定软件是有错误的，然后去发现尽可能多的错误。
他还从人的心理学的角度论证，将“验证软件是工作的”作为测试的目的，非常不利于测试人员发现软件的错误。
于是他于1979年提出了他对软件测试的定义：“就是以发现错误为目的而运行程序的过程。
The process of executing a program or system with the intent of finding errors.”这就是软件测试的第二类方法，简单地说就是验证软件是“不工作的”，或者说是有错误的。
他甚至极端地认为，一个成功的测试必须是发现Bug的测试，不然就没有价值。
这就如同一个病人（假定此人确有病），到医院做一项医疗检查，结果各项指标都正常，那说明该项医疗检查对于诊断该病人的病情是没有价值的，是失败的。
我并不完全同意这一看法。
第二类软件测试方法在业界也很流行，受到很多学术界专家的支持。
大家熟悉的Ron Patton在《软件测试》（中文版由机械工业出版社出版，具说此书是目前国内测试新手入门的经典教材）一书的第10页，有一个明确而简洁的定义：“软件测试员的目标是找到软件缺陷，尽可能早一些，并确保其得以修复。
”有些软件企业以Bug数量来作为考核测试人员业绩的一项指标，其实就是接受了这样的方法。
两类方法的优劣对比虽然软件测试总的目的是为了软件产品的质量，但很明显这两类测试方法在具体目标、或指导思想上截然相反。
由此也决定了它们在思路、过程和测重点上有很大的差别，并各有利弊的。
第一类测试方法以需求和设计为本，因此有利于界定测试工作的范畴，更便于部署测试的侧重点，加强针对性。
这一点对于大型软件的测试，尤其是在有限的时间和人力资源情况下显得格外重要。
而第二类测试方法与需求和设计没有必然的关联，如果计划管理不当，测试活动很容易丢失重点，走入歧途。
第一类测试方法可以与软件的架构和软件开发的计划相配合，使软件测试活动逐层次的展开，从而使软件的功能和质量有计划地逐步完善和提高（关于测试的层次问题，我会在今后的讨论中专门介绍）。
第二类测试方法不具备这种过程的渐进性。
第一类测试方法的缺点是缺乏灵活性，不利于测试人员主观能动性的发挥，正像Myers先生所说，不容易找到软件的错误（Bug）。
而这方面正是第二类测试方法的长处。
微软的策略正是因为认识到两类测试方法各有利弊，微软在软件测试活动中将两类方法结合起来，以第一类测试方法为基础和主要线索，阶段性地运用第二类测试方法。
微软的第一类测试微软的第一类测试总体上说分为三个步骤进行：审核需求和设计—〉设计测试—〉实施运行测试。
前文已述，第一类测试是以需求和设计为本来验证软件的正确性。
大家很自然的想到，需求和设计本身也有正确性的问题。
依据不正确的需求和设计不可能开发出正确的软件产品，测试也将是徒劳的。
因此验证需求和设计是微软进行第一类测试的第一步。
有必要指出的是，这里所说的需求和设计具体说来它一般包括：（1）由项目经理根据用户要求（信息来源于市场部门，用户支持部门等等）而编写的需求文本（Requirement Specification）；（2）由项目经理根据需求文本而编写的功能设计文本（Functional Design Specification）；（3）由开发人员根据功能文本而编写的实施设计文本（Implementation Design Specification）。
微软的测试人员要参与所有这些文本的审核。
作为测试人员，审核重点是检查文本对用户需求定义的完整性、严密性和功能设计的可测性。
同时这种审核对于测试人员也是一种热身活动，使他们尽早地进入技术和业务状态。
第二步，测试人员要根据已审核通过的需求和设计编制测试计划，设计测试用例。
在前面提到的三种文本中，功能设计文本是主要依据。
原因很简单，这类测试关心的是软件是否能正确地实现功能，而不是这些功能如何被具体实施的。
从这里大家可以看出这是典型的“黑盒测试”。
确实微软的测试主要是从用户角度进行的黑盒测试。
这一步的完成就意味着“测试计划”和“测试用例设计”两个文本的完成。
“测试计划”文本主要阐述测试的范畴、领域、方法、工具、资源和计划时间表等等。
“测试用例设计”文本要列出测试用例、每个用例的设置、执行步骤和预期结果。
测试的这两个文本也要被项目经理和开发人员审核。
这样经过各种相互的审核，大家对项目形成了基本的共识。
第三步的实施运行测试是整个开发过程中最长最复杂的一个阶段。
从总体上说就是将上一步设计的测试用例按计划付诸实施的过程。
这包括编写自动化测试程序、反复运行自动化测试程序，也包括阶段性执行手动测试用例。
这一阶段的测试必须在周密的计划下进行，在前面我已提到，这正是第一类测试的特点和长处。
这种计划性首先体现在开发和测试的相互协调配合，根据产品的架构和功能模块的依赖关系，按照项目的总体计划共同推进。
从测试的过程来看，总是先运行或执行简单用例，然后再复杂用例；先验证单一的基本功能，再综合的端到端的功能；先发现解决表面的，影响面大的Bug，再深层的，不容易重现的Bug。
因此随着项目开发和测试的进程，产品的功能不断完善，质量不断提高。
这里有一点要特别指出，有很多测试用例是要反复运行的，特别是基本的自动化测试每一天，每一个Build上都要运行。
尽管这些测试大多数情况下都是通过的，很少再发现新的Bug，但其价值是显而易见的，就是为了防止质量回归。
可见Myers 的理论在这里是不适用的。
这一阶段测试人员还有一项繁琐但却很重要的工作，就是对已有的测试用例的维护。
比如通常以下两种情况下要新增一些测试用例，一是对于当初测试设计不周全的领域，二是对于外部的Bug（比如从Beta客户报告来的），没有被现有测试用例所覆盖。
当产品的功能设计出现更改时（在微软这是常事），所涉及的测试用例当然也要相应地修改。
微软的第二类测试微软的第二类测试是阶段性的，常常根据需要而带有随机性和突击性。
对于这类测试，在微软有一个专门的名称：“Bug Bash（Bug大扫除）”。
Bug Bash通常发生在项目开发各阶段（微软叫里程碑）的末期，比如Beta版发布前，划出一个专门的时间段（通常1-3天），在这期间所有参与项目的人员，集中全部精力，运用各方面的知识，尽全部智慧来搜寻项目的Bug。