常用软件测试方法及类型解析

《常用软件测试方法及类型解析》由会员分享，可在线阅读，更多相关《常用软件测试方法及类型解析（8页珍藏版）》请在金锄头文库上搜索。

1、常用软件测试方法及类型解析一、软件测试概述软件测试是软件开发过程的重要组成部分，是用来确认一个程序的品质或性能是否符 合开发之前所提出的一些要求。软件测试的目的，第一是确认软件的质量，其一方面是确 认软件做了你所期望的事情（Do the right thing） ，另一方面是确认软件以正确的方式来做 了这个事件（Do it right） 。第二是提供信息，比如提供给开发人员或程序经理的反馈信息， 为风险评估所准备的信息。第三软件测试不仅是在测试软件产品的本身，而且还包括软件 开发的过程。如果一个软件产品开发完成之后发现了很多问题，这说明此软件开发过程很 可能是有缺陷的。因此软件测试的第三个目的

2、是保证整个软件开发过程是高质量的。软件质量是由几个方面来衡量的：一、在正确的时间用正确的的方法把一个工作做正 确（Doing the right things right at the right time.） 。二、符合一些应用标准的要求，比如不同 国家的用户不同的操作习惯和要求，项目工程中的可维护性、可测试性等要求。三、质量 本身就是软件达到了最开始所设定的要求，而代码的优美或精巧的技巧并不代表软件的高 质量（Quality is defined as conformance to requirements, not as “goodness” or “elegance”.） 。四、 质量

3、也代表着它符合客户的需要（Quality also means “meet customer needs”.） 。作为软件测 试这个行业，最重要的一件事就是从客户的需求出发，从客户的角度去看产品，客户会怎 么去使用这个产品，使用过程中会遇到什么样的问题。只有这些问题都解决了，软件产品 的质量才可以说是上去了。测试人员在软件开发过程中的任务：1、寻找 Bug；2、避免软件开发过程中的缺陷；3、衡量软件的品质；4、关注用户的需求。总的目标是：确保软件的质量。二、常用的软件测试方法1. 黑盒测试黑盒测试顾名思义就是将被测系统看成一个黑盒，从外界取得输入，然后再输出。整 个测试基于需求文档，看是否能满

4、足需求文档中的所有要求。黑盒测试要求测试者在测试 时不能使用与被测系统内部结构相关的知识或经验，它适用于对系统的功能进行测试。黑盒测试的优点有：1）比较简单，不需要了解程序内部的代码及实现；2）与软件的内部实现无关；3）从用户角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题；4）基于软件开发文档，所以也能知道软件实现了文档中的哪些功能；5）在做软件自动化测试时较为方便。黑盒测试的缺点有：1）不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的 30%；2）自动化测试的复用性较低。2. 白盒测试白盒测试是指在测试时能够了解被测对象的结构，可以查阅被测代码内容的测试工作。 它需要知道

5、程序内部的设计结构及具体的代码实现，并以此为基础来设计测试用例。如下 例程序代码：HRESULT Play( char* pszFileName )if ( NULL = pszFileName )return;if ( STATE_OPENED = currentState )PlayTheFile();return;读了代码之后可以知道，先要检查一个字符串是否为空，然后再根据播放器当前的状 态来执行相应的动作。可以这样设计一些测试用例：比如字符串（文件）为空的话会出现 什么情况；如果此时播放器的状态是文件刚打开，会是什么情况；如果文件已经在播放， 再调用这个函数会是什么情况。也就是说，根据

6、播放器内部状态的不同，可以设计很多不 同的测试用例。这些是在纯粹做黑盒测试时不一定能做到的事情。白盒测试的直接好处就是知道所设计的测试用例在代码级上哪些地方被忽略掉，它的 优点是帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中隐藏的问题。 白盒测试的缺点有： 1）程序运行会有很多不同的路径，不可能测试所有的运行路径； 2）测试基于代码，只能测试开发人员做的对不对，而不能知道设计的正确与否，可能 会漏掉一些功能需求； 3）系统庞大时，测试开销会非常大。 3. 基于风险的测试 基于风险的测试是指评估测试的优先级，先做高优先级的测试，如果时间或精力不够， 低优先级的测试可以暂时先不做。有

7、如下一个图，横轴代表影响，竖轴代表概率，根据一 个软件的特点来确定：如果一个功能出了问题，它对整个产品的影响有多大，这个功能出 问题的概率有多大？如果出问题的概率很大，出了问题对整个产品的影响也很大，那么在 测试时就一定要覆盖到。对于一个用户很少用到的功能，出问题的概率很小，就算出了问 题的影响也不是很大，那么如果时间比较紧的话，就可以考虑不测试。 基于风险测试的两个决定因素就是：该功能出问题对用户的影响有多大，出问题的概 率有多大。其它一些影响因素还有复杂性、可用性、依赖性、可修改性等。测试人员主要 根据事情的轻重缓急来决定测试工作的重点。 4. 基于模型的测试 模型实际上就是用语言把一个系

8、统的行为描述出来，定义出它可能的各种状态，以及 它们之间的转换关系，即状态转换图。模型是系统的抽象。基于模型的测试是利用模型来 生成相应的测试用例，然后根据实际结果和原先预想的结果的差异来测试系统，过程如下 图所示。 NextPage三、软件测试的类型 常见的软件测试类型有： BVT (Build Verification Test) BVT 是在所有开发工程师都已经检入自己的代码，项目组编译生成当天的版本之后进 行，主要目的是验证最新生成的软件版本在功能上是否完整，主要的软件特性是否正确。 如无大的问题，就可以进行相应的功能测试。BVT 优点是时间短，验证了软件的基本功能。 缺点是该种测试的

9、覆盖率很低。因为运行时间短，不可能把所有的情况都测试到。 Scenario Tests（基于用户实际应用场景的测试） 在做 BVT、功能测试的时候，可能测试主要集中在某个模块，或比较分离的功能上。 当用户来使用这个应用程序的时候，各个模块是作为一个整体来使用的，那么在做测试的 时候，就需要模仿用户这样一个真实的使用环境，即用户会有哪些用法，会用这个应用程 序做哪些事情，操作会是一个怎样的流程。加了这些测试用例后，再与 BVT、功能测试配 合，就能使软件整体都能符合用户使用的要求。Scenario Tests 优点是关注了用户的需求， 缺点是有时候难以真正模仿用户真实的使用情况。 Smoke T

10、est 在测试中发现问题，找到了一个 Bug，然后开发人员会来修复这个 Bug。这时想知道 这次修复是否真的解决了程序的 Bug，或者是否会对其它模块造成影响，就需要针对此问 题进行专门测试，这个过程就被称为 Smoke Test。在很多情况下，做 Smoke Test 是开发人员在试图解决一个问题的时候，造成了其它功能模块一系列的连锁反应，原因可能是只集 中考虑了一开始的那个问题，而忽略其它的问题，这就可能引起了新的 Bug。Smoke Test 优点是节省测试时间，防止 build 失败。缺点是覆盖率还是比较低。 此外，Application Compatibility Test（兼容性测

11、试） ，主要目的是为了兼容第三方软件， 确保第三方软件能正常运行，用户不受影响。Accessibility Test（软件适用性测试） ，是确 保软件对于某些有残疾的人士也能正常的使用，但优先级比较低。其它的测试还有 Functional Test（功能测试） 、Security Test（安全性测试） 、Stress Test（压力测试） 、 Performance Test（性能测试） 、Regression Test（回归测试） 、Setup/Upgrade Test（安装升级 测试）等。 四、微软的软件测试工作 1. 基本情况 测试在微软公司是一项非常重要的工作，微软公司在此方面的投入

12、是非常巨大的。微 软对测试的重视表现在工程开发队伍的人员构成上，微软的项目经理、软件开发人员和测 试人员的比例基本是 1：3：3 或 1：4：4，可以看出开发人员与测试人员的比例是 1：1。 对于测试的重视还表现在最后产品要发布的时候，此产品的所有相关部门都必须签字，而 测试人员则具有绝对的否决权。 测试人员中分成两种职位，Software Development Engineer in Test（测试组的软件开发 工程师）实际上还是属于开发人员，他们具备编写代码的能力和开发工具软件的经验，侧 重于开发自动化测试工具和测试脚本，实现测试的自动化。Software Test Engineer（软

13、件测 试工程师）具体负责测试软件产品，主要完成一些手工测试以及安装配置测试。 2. 测试计划 测试计划是测试人员管理测试项目，在软件中寻找 Bug 的一种有效的工具。测试计划 主要有两个作用，一是评判团队的测试覆盖率以及效率，让测试工作很有条理的逐步展开。 二是有利于与项目经理、开发人员进行沟通。有了测试计划之后，他们就能够知道你是如 何开展测试工作的，他们也会从中提出很多有益的意见，确保测试工作顺利进行。总之， 有了测试计划可以更好的完成测试工作，确保用户的满意度。 测试人员在编写测试计划之前，应获得以下文档： 1）程序经理编写的产品功能说明书或产品开发计划； 2）程序经理或开发人员提供的开

14、发进度表。 根据产品的特性及开发进度安排，测试人员制定具体的测试计划。测试计划通常包括 以下内容： 1）测试目标和发布条件： a. 给出清晰的测试目标描述； b. 定义产品的发布条件，即在达到何种测试目标的前提下才可以发布产品的某个特定 版本。 2）待测产品范围： a. 软件主要特性/功能说明，即待测软件主要特性的列表； b. 特性/功能测试一览，应涵盖所有特性、对话框、菜单和错误信息等待测内容，并列 举每个测试范围内要重点考虑的关键功能。 3）测试方法描述： a. 定义测试软件产品时使用的测试方法； b. 描述每一种特定的测试方法可以覆盖哪些测试范围。 4）测试进度表： a. 定义测试里程碑

15、； b. 定义当前里程碑的详细测试进度。 5）测试资源和相关的程序经理/开发工程师： a. 定义参与测试的人员； b. 描述每位测试人员的职责范围； c. 给出与测试有关的程序经理/开发工程师的相关信息。 6）配置范围和测试工具： a. 给出测试时使用的所有计算机平台列表； b. 描述测试覆盖了哪些硬件设备； c. 测试时使用的主要测试工具。此外，还应列出测试中可能会面临的风险及测试的依赖性，即测试是否依赖于某个产 品或某个团队。比如此项测试依赖性 WindowsCE 这个操作系统，而这个系统要明年 2 月 份才能做好，那么此项测试就可能只有在明年 5 月份才能完成，这样就存在着依赖关系。 如

16、果那个团队的开发计划往后推，则此项测试也会被推迟。 3. 测试用例开发 一个好的测试用例就是有一个合理的概率来找到 Bug，不要冗余，要有针对性，一个 测试只针对一件事情。特别是功能测试的时候，如果一个测试是测了两项功能，那么如果 测试结果失败的话，就不知道到底是哪项功能出了问题。 测试用例开发中主要使用的技术有等价类划分，边界值的分析，Error Guessing Testing。 等价类划分是根据输入输出条件，以及自身的一些特性分成两个或更多个子集，来减 少所需要测试的用例个数，并且能用很少的测试用例来覆盖很多的情况，减少测试用例的 冗余度。在等价类划分中，最基本的划分是一个为合法的类，一个为不合法的类。 边界值的分析是利用了一个规律，即程序最容易发生错误的地方就是在边界值的附近， 它取决于变量的类型，以及变量的取值范围。一般对于有 n 个变量时，会有 6n+1 个测试 用例，取值分别是 min-1, min, min+1, normal, max-1, max,max+1 的组合。边界值的分析的 缺点，是对逻辑变量和布尔型变量不起作用，还有可能会忽略掉某些输入的