软件测试的科学和艺术
软件开发的科学和艺术之软件测试
软件测试－《软件开发的科学和艺术》节选撰文/陈宏刚《软件开发的科学与艺术》是电子工业出版社联袂微软公司华人专家于近期推出的一本优秀之作。
书中凝聚了微软公司多位专家多年研究与工作的宝贵经验，并通过对许多成功或失败案例的中肯剖析，为读者展现了软件开发的思想与流程，值得软件人员好好阅读和领悟!一、微软的测试人员微软的软件测试人员分为两类:测试工具软件开发工程师（Software Development Engineer in Test,简称SDE/T)和软件测试工程师(Software Test Engineer，简称STE)。
测试工具软件开发工程师:负责写测试工具代码，并利用测试工具对软件进行测试；或者开发测试工具为软件测试工程师服务。
产品开发后的性能测试(Performance Test)、提交测试(Check-in Test)等过程，都有可能要用到SDE/T开发的测试工具。
由于SDE/T 和SDE的工作都是写代码，具有相通的地方，所以两者之间互相转换的情况比较多。
但需注意的是，两者写出来的代码用途是不一样的，SDE写的是产品的代码，而SDE/T写的代码只用于测试产品。
软件测试工程师:负责理解产品的功能要求，然后对其进行测试，检查软件有没有错误(Bug)，决定软件是否具有稳定性(Robustness)，并写出相应的测试规范和测试用例。
除此之外，在一个软件产品的研发和销售过程中，还会需要负责给产品打补丁(Service Pack)的快速修正工程师（Quick Fix Engineer)，通常曲SDE来担任，通过电话方式向用户提供售后技术支持的支持工程师(Support Engineer)，销售和市场(Sales and Marketing)人员，研究员和研究工程师(Researchers & Research SDE)。
在进行产品开发的时候，主要是由前面三类人员(项目经理、开发人员及测试人员)组成产品开发团队来进行的。
软件测试的艺术
（6）误区之六：软件测试是没有前途的工作，只有程序员才是软件高手
由于我国软件整体开发能力比较低，软件过程很不规范，很多软件项 目的开发都还停留在“作坊式”和“垒鸡窝”阶段。项目的成功往往靠个 别全能程序员决定，他们负责总体设计和程序详细设计，认为软件开发就 是编写代码，给人的印象往往是程序员是真正的牛人，具有很高的地位和 待遇。因此，在这种环境下，软件测试很不受重视，软件测试人员的地位 和待遇自然就很低了，甚至软件测试变得可有可无。随着市场对软件质量 的不断提高，软件测试将变得越来越重要，相应的软件测试人员的地位和 待遇将会逐渐提高。在微软等软件过程比较规范的大公司，软件测试人员 的数量和待遇与程序员没有多大差别，优秀测试人员的待遇甚至比程序员 还要高。软件测试将会成为一个具有很大发展前景的行业，软件测试大有 前途，市场需要更多具有丰富测试技术和管理经验的测试人员，他们同样 是软件专家。这两年来国内软件测试人员的需求不断增大,越来越多的IT企 业认识到了软件测试的重要性,这种可喜的现状与发展趋势让笔者对我国软 件业的发展重新抱有较大的希望。
Summary
尽管这是一门崭新的学科,目前在国内的发展仍处于"婴儿"阶
段,但看到越来越多的软件公司为软件测试招兵买马,看到越来越
多的技术人员投入到软件测试中,我就情不自禁地感叹:机会来了! 这机会不仅仅是某一个人的,而是所有人的,它对每个人都是公平
的,学的领域需要新的理论新的工具新的方法,由于国内的软件测
件项目实施过程中的重要性日益突出。但是，现实情况是，与软件 编程比较，软件测试的地位和作用，还没有真正受到重视，对于很
多人（甚至是软件项目组的技术人员）还存在对软件测试的认识误
区，这进一步影响了软件测试活动开展和真正提高软件测试质量。
软件测试基本原理和技巧
软件测试基本原理和技巧第一章：软件测试的基本原理软件测试是软件开发生命周期中至关重要的一环，其基本原理包括以下几个方面：1. 软件测试的目的：软件测试的目的是为了发现潜在的缺陷和错误，并评估软件的质量。
通过测试，可以提高软件的稳定性和可靠性，确保其在不同环境下正常运行。
2. 测试的阶段：软件测试通常分为单元测试、集成测试、系统测试和验收测试四个阶段。
单元测试主要测试单个软件组件的功能，集成测试测试多个组件之间的交互，系统测试测试整个系统的完整性和稳定性，验收测试由最终用户参与，确认系统是否满足需求。
3. 测试策略：测试策略是测试活动的整体规划，包括测试目标、测试方法和资源分配等。
根据软件的特点和需求，选择适合的测试策略可以提高测试的效率和质量。
4. 测试用例设计：测试用例是测试的核心，它是一组输入、预期输出和执行条件的描述。
测试用例应尽可能覆盖软件的各种功能和场景，以便发现更多的潜在问题。
第二章：常用的软件测试技巧为了提高软件测试的效果和效率，常用的软件测试技巧如下所述：1. 黑盒测试：黑盒测试是一种独立于内部结构和实现细节的测试方法。
测试人员只关注软件的输入和输出，通过构造各种情况进行测试，以验证软件功能的正确性。
2. 白盒测试：白盒测试是一种测试方法，关注软件内部结构和逻辑。
测试人员通过检查代码、执行路径和数据流来评估软件的质量，发现潜在的错误。
3. 灰盒测试：灰盒测试结合了黑盒测试和白盒测试的特点，既关注输入输出，也关注内部结构和实现。
测试人员可以利用已有的代码和文档进行测试，以更全面地评估软件的功能和质量。
4. 功能测试：功能测试是验证软件功能的正确性。
测试人员根据需求和规格说明书，通过输入不同的数据和操作软件，检查是否符合预期的结果。
5. 性能测试：性能测试旨在评估软件在不同负载和压力下的性能表现。
测试人员通过模拟大量用户和复杂场景来测试软件的性能和响应时间。
6. 安全测试：安全测试是测试软件系统对各种攻击和恶意行为的防御能力。
软件测试的艺术
错误猜测
错误推测法就是根据经验和直觉推测程序中 所有可能存在的各种错误，从而有针对性地 设计测试用例的方法。 基本思路：列举出程序中所有可能有的错误 和容易发生错误的特殊情况，根据他们选择 测试用例。例如：输入数据和输出数据为0 的情况。
Confidential
34
测试策略
Part Three
开发过程与测试过程的关系 测试阶段介绍
Confidential
36
开发过程与测试过程的关系
Confidential
37
测试阶段
单元测试、集成测试、系统测试、验收测试。 是“从小到大”、“由内至外”、“循序渐进” 的测试过程，体现了“分而治之”的思想。 单元测试的粒度最小，一般由开发小组采用白 盒方式来测试，主要测试单元是否符合“设 计”。 集成测试界于单元测试和系统测试之间，起到 “桥梁作用”，一般由开发小组采用白盒加黑 盒的方式来测试，既要验证“设计”又要验证 “需求”。
白盒测试中（有时候称为开盒测试），软件测 试员可以访问程序员的代码，并通过检查代码 来协助测试－可以看到盒子里面。一般在模块 测试中采用白盒测试，用于测试模块中所有可 能的路径、执行所有循环并测试所有逻辑表达 式。 黑盒测试则侧重于软件的整体功能。 它不基于 程序的内部结构而基于系统功能。犹如一个人 站在黑盒子外面，只知道系统输入一定数据， 得到一定的输出，而不必清楚这个黑盒子中进 Confidential 12 行了哪些操作和运算。
如果规格说明中包含输入条件组合的情况， 应首先使用因果图分析方法。 在任何情况下都应使用边界值分析方法。 应为输入和输出确定有效和无效等价类。 使用错误猜测技术增加更多的测试用例。 针对上述测试用例集检查程序的逻辑结构， 应使用判定覆盖、条件覆盖、判定/条件覆 盖或多重条件覆盖准则。
软件测试的基本原理与方法
软件测试的基本原理与方法概述：软件测试是保证软件质量的重要环节，它通过验证软件系统是否满足用户需求、检测潜在错误和缺陷，并为开发人员提供改进和优化的方向。
本文将介绍软件测试的基本原理和方法，旨在帮助读者更好地理解和应用软件测试。
一、软件测试的基本原理1. 确定目标和需求：在开始测试之前，明确测试的目标和需求是至关重要的。
测试目标可以是发现缺陷、验证正确性或评估性能等，而需求确定了测试的范围和对象。
2. 找到合适的测试方法：不同的软件系统需要采用不同的测试方法。
常见的测试方法包括黑盒测试、白盒测试、灰盒测试等。
黑盒测试关注系统功能，不考虑内部结构；白盒测试则通过检查代码的内部结构来进行测试；而灰盒测试兼顾了功能和内部结构。
3. 设计合理的测试用例：测试用例用于验证软件系统的正确性和稳定性。
一个好的测试用例应当具备全面的覆盖性，涵盖系统的各个功能和边界条件，以最大程度地发现潜在的问题和缺陷。
4. 提前进行测试：软件测试应当尽早进行，尽量在软件开发的早期阶段就开始进行测试工作。
这样可以及早发现问题，减少后期修复的成本和风险。
二、常见的软件测试方法1. 黑盒测试：黑盒测试是不考虑系统内部结构的测试方法，测试者只关注系统的输入和输出，通过输入一组特定的数据，对输出结果进行验证。
黑盒测试通常包括等价类划分、边界值分析、因果图等技术。
2. 白盒测试：白盒测试是基于系统内部结构进行的测试方法，测试者了解软件的内部逻辑和代码细节，设计测试用例并执行测试。
常用的白盒测试方法有语句覆盖、判定覆盖、条件覆盖等。
3. 集成测试：集成测试是将已经测试过的模块组装成整个系统，并通过相互之间的接口交互进行测试。
这种测试方法主要用于检测模块之间的集成问题和接口错误。
4. 性能测试：性能测试是测试软件系统的性能指标，如响应时间、吞吐量、并发用户数等。
通过模拟实际工作负载，观察系统在不同负载下的表现，发现系统性能瓶颈并提供优化建议。
软件测试理论和方法
软件测试理论和方法
软件测试理论和方法是指在软件开发过程中，对软件产品进行验证和验证的过程和方法。
以下是一些常见的软件测试理论和方法：
1. 黑盒测试：在测试过程中，测试人员只关注软件的输入和输出，而不关心内部的实现细节。
测试人员根据软件的需求规范和功能描述，设计测试用例并执行测试。
2. 白盒测试：在测试过程中，测试人员对软件的内部结构和实现细节有深入的了解。
测试人员根据软件的设计和代码，设计测试用例并执行测试。
3. 单元测试：针对软件中的最小功能单元进行测试。
通常由开发人员在编写代码的同时进行。
4. 集成测试：在软件开发过程中，测试人员将各个独立的单元进行组合和测试，以验证它们之间的集成是否正确。
5. 系统测试：对整个软件系统进行全面测试，以验证系统的功能、性能、可靠性和安全性等方面是否满足需求。
6. 冒烟测试：在软件开发过程中，进行一系列的基本功能测试，以验证软件是否能够基本运行。
7. 性能测试：对软件的性能进行测试，包括响应时间、吞吐量、并发性等方面的测试。
8. 安全测试：对软件的安全性进行测试，以验证软件是否容易受到攻击或数据泄露等安全问题。
9. 自动化测试：使用自动化工具和脚本进行测试，以提高测试效率和准确性。
以上只是一些常见的软件测试理论和方法，根据软件的具体情况和开发过程，还可以采用其他不同的测试理论和方法。
软件测试方法和技术
软件测试方法和技术首先，我们来谈谈软件测试的基本方法。
软件测试的基本方法主要包括黑盒测试和白盒测试。
黑盒测试是一种基于软件规格说明的测试方法，测试人员只需关注软件的功能和接口，而不需要了解软件的内部结构和实现细节。
白盒测试则是一种基于软件内部结构的测试方法，测试人员需要了解软件的内部逻辑和代码结构，以便设计测试用例和进行测试。
在实际的软件测试过程中，通常会结合使用黑盒测试和白盒测试，以确保软件的功能和质量得到全面的验证和检查。
其次，我们需要了解一些常用的软件测试技术。
常见的软件测试技术包括单元测试、集成测试、系统测试、性能测试、安全测试等。
单元测试是针对软件中的最小单元进行测试，通常由开发人员编写和执行，旨在验证单元的正确性和健壮性。
集成测试是将各个单元组合起来进行测试，验证它们之间的交互和集成是否正常。
系统测试是对整个软件系统进行测试，以验证其满足用户需求和设计规范。
性能测试是测试软件在各种条件下的性能表现，包括响应速度、并发性能、负载能力等。
安全测试是验证软件系统对各种安全威胁和攻击的抵抗能力。
这些软件测试技术能够帮助测试人员全面地评估软件的质量和性能，发现并解决潜在的问题和风险。
此外，还有一些新兴的软件测试方法和技术，如自动化测试、敏捷测试、云端测试等。
自动化测试是利用各种自动化工具和脚本来执行测试，能够提高测试效率和覆盖率，减少人工测试的工作量。
敏捷测试是在敏捷开发环境下进行的测试，注重快速反馈和持续集成，能够更好地适应需求变化和快速迭代。
云端测试是将测试环境和资源部署在云端，能够提供更灵活和可扩展的测试环境，适应不同规模和需求的软件测试。
综上所述，软件测试方法和技术是软件测试工作中的重要组成部分，它们能够帮助测试人员更加高效地进行软件测试，发现并修复软件中的缺陷和问题。
通过合理选择和应用软件测试方法和技术，可以提高软件质量，降低软件开发和维护的成本，增强软件的可靠性和稳定性。
希望本文介绍的软件测试方法和技术能够对软件测试工作者有所启发和帮助，使他们能够在软件测试工作中取得更好的成果。
软件测试的艺术
成功的测试和不成功的测试 —成功的测试用例
能发现错误 就证明它是值得设计的。一个“不成功 的”测试用例．会使程序输出正确的结果， 但不能 发现任何错误。
返回
软件测试的策略 —黑盒测试
黑盒测试是一种重要的测试策略，又称为数据驱动 的测试或输入/输出驱动的测 试。使用这种测试方法 时，将程序视为一个黑盒子。测试目标与程序的内 部机制和 结构完全无关，而是将重点集中放在发现 程序不按其规范正确运行的环境条件（判定的标准 就是“穷举 输入测试”，将所有可能的输入条件都 作为测试用例。）
返回
软件测试的策略 —黑盒测试
穷举输入测试是无法实现的，这有两方面的含义， 一是我们无 法测试一个程序以确保它是无错的，二 是软件测试中需要考虑的一个基本问题是软 件测试 的经济学。也就是说，由于穷举测试是不可能的， 测试投入的目标在于通过 有限的测试用例，最大限 度地提高发现的问题的数量，以取得最好的测试效 果。
返回
测试用例的设计 —重要性
为什么要设计测试用例？ 原因在于完全的测试是不可能的，对任何程序的 测试必定是不完全的。
测试用例的设计 —用例设计
Bug记录的规范 —规范记录
Bug记录的规范 —数据统计
通过Bug的规范记录，利用Excel函数对Bug列表数据 进行自动实时统计，统计出总问题数，未处理问题 数、各级问题所在比例，以及测试通过率。
返回
“软件测试”错误的定义
“软件测试就是证明软件不存在错误的过程。” “软件测试的目的在于证明软件能够正确完成其预 定的功能。” “软件测试就是建立一个‘软件做了其应该做的’ 信心的过程。”
返回
“软件测试”正确的定义
“测试是为发现错误而执行程序的过程”
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件测试的科学和艺术[收藏此页] [打印]作者：（来自ITPUB）2007-08-23内容导航：微软的测试人员第1页：微软的测试人员第2页：测试时应考虑的几个问题第3页：关于Bug 第4页：软件测试方法和辅助工具一、微软的测试人员微软的软件测试人员分为两类:测试工具软件开发工程师（Software Development Engineer in Test, 简称SDE/T) 和软件测试工程师(Software Test Engineer，简称STE)。
测试工具软件开发工程师:负责写测试工具代码，并利用测试工具对软件进行测试；或者开发测试工具为软件测试工程师服务。
产品开发后的性能测试(Performance Test) 、提交测试(Check-in Test) 等过程，都有可能要用到SDE/T 开发的测试工具。
由于SDE/T和SDE 的工作都是写代码，具有相通的地方，所以两者之间互相转换的情况比较多。
但需注意的是，两者写出来的代码用途是不一样的，SDE 写的是产品的代码，而SDE/T 写的代码只用于测试产品。
软件测试工程师:负责理解产品的功能要求，然后对其进行测试，检查软件有没有错误(Bug)，决定软件是否具有稳定性(Robustness) ，并写出相应的测试规范和测试用例。
除此之外，在一个软件产品的研发和销售过程中，还会需要负责给产品打补丁(Service Pack)的快速修正工程师（Quick Fix Engineer) ，通常曲SDE 来担任，通过电话方式向用户提供售后技术支持的支持工程师(Support Engineer)，销售和市场(Sales and Marketing)人员，研究员和研究工程师(Researchers & Research SDE) 。
在进行产品开发的时候，主要是由前面三类人员(项目经理、开发人员及测试人员)组成产品开发团队来进行的。
在微软内部，软件测试人员与软件开发人员的比率一般为1.5-2.5 左右，这可能远远超出了大家对测试人员的理解，但微软软件开发的实践过程已经证明了这种人员结构的合理性。
下图中显示了上述两个产品的微软软件开发人员的一般配置图。
下面以微软Exchange2O0O 和Windows2000 为例介绍一下微软产品团队的人员结构(这里只分析三类主要的人员，即项日经理、开发人员及测试人员)，如下表所示。
二、测试时应考虑的几个问题（1）测试最重要的一件事就是要考虑到所有的出错可能性。
同时，还要做一些不是按常规做的、非常奇怪的事。
说起来可能不太好听，测试的过程就像黑客(Hacker) 的攻击过程那样。
可以这么说，像黑客这样的人是最好的软件安全测试员。
他们专门找软件的漏洞，从而破坏这个软件，这样就可以修复这些漏洞来保证软件的性能。
如果找不到这种漏洞，那就说明该软件质量己经很好了。
(2) 除了漏洞之外，测试还应该考虑性能(Performance) 问题，也就是一定要保证软件运行得很好，非常快，没有内存泄漏，不会出现那种越来越慢的情况。
我们可以在不关机的情况下，与其他软件一起持续运行一个多月，看看是否会出现越来越慢的情况(当然必须保证其他软件是没有问题的)。
我们在做IE 的时候，就是让它72 小时连续不停地打开不同的网页，处理几万个不同的网页，而且速度不能减慢。
有许多软件，当只有一两个人用的时候，可能感觉不到什么问题，而当几百个用户一起用的时候，有的网站就出现各种各样的异常，这就是测试工作还比较欠缺的缘故。
(3) 另外，测试还要考虑软件的兼容性(Compatibility) 。
一般来说，一个软件是由许多小软件构成的，如果其中一个小软件与它的前一版本不兼容，那么这个软件就会出现错误。
这种错误需要通过测试来发现和解决。
许多人认为写代码的人一定能找出错误来。
其实开发人员在写代码的时候，如果有错误，他可以意识到了，可是写出来的错误，他不一定能想得到。
我自己也编过程序，在编程序的时候很自信，觉得不会有错，可事实上，即使是我编的小程序也有错误，但要自己找出来，却要费很大劲。
因为我一直认为自己不应该出错，但常常错误就出现在我认为最有把握的地方。
我是学数学的，是一个很细心的人，可是--样还是会出错，但要找出自己的错误却要花费很长的时间。
后来我写的代码让我的师弟帮我看，结果他很快就找到许多问题，可是我自己花一个月时间可能都找不到。
所以，开发人员和测试人员完全不一样，开发人员确实可以找到一些Bug，但是有更多的Bug 是他意识不到的。
在一般的开发团队中，并不需要测试人员定位Bug 的具体位置，所以，对测试人员的要求并不高。
只要你愿意学，测试工作是非常容易做的。
但是，我当年所在的IE 团队(IE 4.0)就不同，因为当时正在与另一个公司的产品竞争，所以微软就要求尽量找到一流的开发人员和一流的测试人员，尽快开发出新产品，打败对手。
所以，当时对我们测试人员的要求非常严格，不仅要找出Bug，而且要定位引起此Bug 的代码行。
然后将这些信息交给开发人员，后者就可以很快更正，省去了他们找错误出处的时间。
因此，当时IE 的开发速度非常快，一年之内就发布了一个新版本，而且几乎役有任何大Bug，大大超越了竞争对手。
三、关于BugBug 的定义很广泛，在软件使用过程中所出现的任何一个可疑问题，或者导致软件不能符合设计要求或满足消费者需要的问题都是Bug，即使这个Bug 在实践中是可行的。
有时候，Bug 并不是程序错误。
例如，软件没有按照一般用户的使用习惯来运行，此时也可以把这个问题看成是该软件的一个Bug。
通常，对Bug 的跟踪过程如图所示。
首先，测试人员根据测试结果来报告他发现的所有Bug 。
通常，这项工作还需要用户的参与。
微软在正式发布一个软件之前，经常要依次发布Alpha 测试版、Beta 测试版让用户试用，以便用户能够反馈出相关Bug 的信息。
但是，现在随着微软测试队伍的扩大及测试水平的提高，越来越多的 Bug 都是我们内部的测试人员自己发现的，很少出现外部用户所反馈的Bug 没有被测试人员发现的情况。
然后，开发经理根据这些Bug 的危害性对它们进行排序，确定Bug 的优先级，并安排给相关的开发工程师。
接着，开发人员根据Bug 的轻重缓急依次修复各个Bug 。
最后，测试人员再对开发人员已经修复的Bug 进行验证，确认Bug 是否已经被彻底更正。
微软开发一个产品经常会遇到几十万条Bug 。
随着测试人员越来越多，测试工作也越来越完善。
但是，如何快速有效地追踪并修复Bug，仍然是摆在软件测试人员面前的一个主要困难。
测试产品和追踪Bug 时最重要的是问题的定义，要清楚需要解决什么样的问题，确定Bug 的主次关系，挑选出最主要的问题，并先解决它们。
例如，有些Bug 可能会导致死机或程序崩溃，这时就要先修复它们，而另一些Bug 可能对软件的运行影响不大，或者出现的机会很少，就可以考虑以后再修复。
可以说，没有任何一个产品没有Bug，也永远不可能找出并修复所有的Bug。
在修复了旧的Bug 的同时，往往又会生新的Bug。
根据微软的经验，每修复三到四个Bug 一般就会产生一个新的Bug。
这个过程就类似于数学中的“极限”的定义，尽管我们知道某个极限值为0，但是它永远也不可能达到0。
这也就产品的Bug 永远也修复不完的原因。
因此，我们在修复 Bug 时要注意，一定要记住用户最需要的是什么，然后优先尽力修复那些影响用户使用的Bug; 而对于大部分对用户影很少、甚至根本不影响的Bug，则可以推迟修复，甚至不修复。
在查找并修复Bug 的过程中，测试人员和开发人员经常会发生争执。
例如，当开发人员宣布某一个Bug 已经被Fixed 时，测试人员往往还不放心，又重新对该Bug 进行检查;当开发人员宣布某一个Bug 是Duplicated 时，细心的测试人员也要验证该Bug 是否和另外一个Bug 相重复，如果另外一个 Bug 己经被修复了，但这个Bug 还存在，就会让开发人员重新修复该Bug;对于是否需要Postponed 一个Bug，测试人员和开发人员也常常争论不休，测试人员认为这个Bug 需要修复，而开发人员则认为修复这个Bug 不值得，这时候就需要项目经理来决定，因为测试人员要从用户的角度来看待Bug ，开发人员则要考虑到开发期限和付出的代价，而项目经理要同时考虑到这两种情况。
只有项目经理经过权衡之后才能确定是否要推迟修复该 Bug；在By design 情况下，通常是争论最多的时候。
这时候也需要三方都坐下来谈，其结果一般有三种:坚持原来的设计、修改原来的设计并增加特性、或者取消该设计。
对Not repro 和Won't fix 情况也是这样，需要测试人员、开发人员和项目经理进行协商，直到三方达成共识四、软件测试方法和辅助工具有了Bug 类型的定义以后，如何去找出这些Bug 呢？这就需要采用好的测试方法。
以下介绍几种常用的钦件测试方法。
有多种方式对软件测试方法进行分类。
例如，从代码和用户使用的角度可以将软件测试方法分为如下几种。
（1）覆盖性测试(Coverage Testing) 覆盖性测试是从代码的特性角度(即内部)出发的测试方法，包括以下方式。
①单元测试(Unit Test): 按照代码的单元组成逐个进行测试。
②功能测试(Function Test) 或特性测试(Feature Test): 按照软件的功能或特性逐个进行测试。
例如，在Exchange 中，发送邮件和接收邮件就是两个不同的功能或特性，在测试时就分别对它们进行检查，看是否工作正常。
③提交测试(Check-in Test): 在开发人员对代码做了任何修改，或者修复了某个Bug 时，需要重新Check-in 代码(即将修改后的代码放大到整个大的系统中)。
这时，开发人员往往也要进行测试，看代码是否工作正常。
为了保险起见，开发人员往往要找测试人员帮着一起进行测试(我们把这种情况称做Buddy Test) 。
测试人员和开发人员之间搞好关系是非常重要的，稍后我会专门讲述这一点。
④基本验证测试(Build Verification Test ，简称BVT): 对完成的代码进行编译和连接，产生一个构造，以检查程序的主要功能是否会像预期一样进行工作。
这是最简单而又最省时的一种测试方法。
每产生一个新的构造时都要进行测试。
如果连BVT 都通不过，表明问题很严重，开发人员需要尽快修复出现的问题，测试人员也就不用浪费时间做其他测试了。
⑤回归测试(Regression Test): 过一段时间以后，再回过头来对以前修复过的Bug 重新进行测试，看该Bug 是否会重新出现。
(2) 使用测试(Usage Testing) 使用测试是从用户的角度(即外部)出发的测试方法。