软件测试

1. 软件测试介绍

软件测试一度被认为是编程能力偏低的员工的工作，直到今天，仍然有许多公司把优秀的人才放在编码上，也有更多公司让优秀的人才进行设计，可是很少公司让优秀的人才进行测试工作。实际的软件工程实践证明，让对软件思想有深刻理解的工程师进行软件测试的，可以大幅度的提高软件质量。

2. 测试的进程

　　2.1 Alpha测试

　　　　Alpha测试通常是阶段性的开发完成后所开始进行，一直持续到进入Beta测试阶段前的阶段。Alpha测试是一种验证测试，在模拟的环境中以模拟的数据来运行。

在这个阶段中，通常是在开发单位由开发人员与测试的测试人员，以模拟或实际操作性的方式进行验证测试。

　　2.2 Beta测试

　　　　在系统测试中通常先进行Alpha测试以验证信息系统匹配用户以及设计需求所期望的功能。当Alpha阶段完成后，开发过程进入到Beta阶段，由公众参与的测试的阶段。Beta测试可称为确认测试，在一个真实的环境中以实际的数据来运行测试，以确认性能，系统运行有效率，系统撤消与备份作业正常，通过测试让信息系统日后可以更趋完善。

    　　封测与公测

　　　　封闭测试（Closed Beta，常简作封测或CB）是或等产品在开发完成后、将公开上市前的测试过程。相对于，封闭测试的主要用途是测试软件的功能和检查等等，因此通常只提供给少数人进行测试。有些公司会要求参与测试者签署，以避免测试的产品提前外流。的封测结束之后，游戏公司常会将角色数据删除，但也有少数不删的。

公开测试（Open Beta，常简作公测或OB），一般常指或等产品在正式上市前开放给不特定人试用，虽然原意是希望试用者能够提报，但并不是把试用者当做真正的验证人员。由于通常为免费性质，故常常能够吸引到大批的试用者参与，可视为另一种策略。另一方面也节省下测试人员的成本，和验证稳定度（对于多人使用的带宽及机器是否能负载，又称）的时间。

　　2.3 Gamma测试

Gamma测试是一个很少被提及的非正式测试阶段，该测试阶段对应的是对“存在缺陷”产品的测试。考虑到任何产品都可以被称为“存在缺陷”的产品（测试只能发现产品中存在的问题，不能说明产品不存在问题），因此这个概念存在一定的不确定性。 对Alpha和Beta测试常见的一个误解是“Beta测试＝黑盒测试”。实际上，Alpha和Beta测试对应在软件产品发布之前的Alpha和Beta阶段，而白盒、黑盒和灰盒测试技术是从技术和方法层面对测试的描述，不应该将这两部分概念混淆。

3. 测试的方法

软件测试一般分为白箱测试和黑箱测试。

　　3.1 黑箱测试

　　　　主条目：

　　　　黑箱测试（black-box testing），也称黑盒测试，是软件测试方法，测试应用程序的功能，而不是其内部结构或运作。测试者不需具备应用程序的代码、内部结构和编程语言的专门知识。测试者只需知道什么是系统应该做的事，即当键入一个特定的输入，可得到一定的输出。测试案例是依应用系统应该做的功能，照规范、规格或要求等设计。测试者选择有效输入和无效输入来验证是否正确的输出。

此测试方法可适合大部分的软件测试，例如集成测试（integration testing）以及系统测试（system testing）。

　　3.2 白箱测试

　　　　主条目：

　　　　白箱测试（white-box testing，又称透明盒测试glass box testing、结构测试structural testing等）是一个测试软件的方法，测试应用程序的内部结构或运作，而不是测试应用程序的功能（即黑箱测试）。在白箱测试时，以编程语言的角度来设计测试案例。测试者输入数据验证数据流在程序中的流动路径，并确定适当的输出，类似测试电路中的节点。

白箱测试可以应用于单元测试（unit testing）、集成测试（integration testing）和系统的软件测试流程，可测试在集成过程中每一单元之间的路径，或者主系统跟子系统中的测试。尽管这种测试的方法可以发现许多的错误或问题，它可能无法检测未使用部分的规范。

4. 测试的类型

功能测试	按照测试软件的各个功能划分进行有条理的测试，在功能测试部分要保证测试项覆盖所有功能和各种功能条件组合。
系统测试	对一个完整的软件以用户的角度来进行测试，系统测试和功能测试的区别是，系统测试利用的所有测试数据和测试的方法都要模拟成和用户的实际使用环境完全一样，测试的软件也是经过系统集成以后的完整软件系统，而不是在功能测试阶段利用的每个功能模块单独编译后生成的可执行程序。
极限值测试	对软件在各种特殊条件，特殊环境下能否正常运行和软件的性能进行测试。 特殊条件一般指的是软件规定的最大值，最小值，以及在超过最大、最小值条件下的测试。 特殊环境一般指的是软件运行的机器处于CPU高负荷，或是网络高负荷状态下的测试，根据软件的不同，特殊环境也有过不同。
	性能测试是对的评价。简单的说，衡量的是软件具有的响应及时度能力。因此，是采用测试手段对软件的响应及时性进行评价的一种方式。根据软件的不同类型，性能测试的侧重点也不同。

　　4.1 压力测试与性能测试

　　 常常和相混淆。它们主要不同点是，压力测试要求进行超过规定性能指标的测试。例如一个网站设计容量是100个人同时点击，压力测试就要是采用120个同时点击的条件测试。

压力测试的通常判断准则：

1. 系统能够恢复。
2. 压力过程中不要有明显性能下降。

5. 测试的阶段

　　5.1 单元测试

　　　　主条目：

　　　　单元测试是对软件组成单元进行测试，其目的是检验软件基本组成单位的正确性，测试的对象是软件设计的最小单位：函数。

　　　　在中，单元测试（英语：Unit Testing）又称为模块测试, 是针对（的最小单位）来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。在中，一个单元就是单个程序、函数、过程等；对于面向对象编程，最小单元就是方法，包括基类（超类）、抽象类、或者派生类（子类）中的方法。

通常来说，程序员每修改一次程序就会进行最少一次单元测试，在编写程序的过程中前后很可能要进行多次单元测试，以证实程序达到要求的工作目标，没有；虽然单元测试不是什么必须的，但也不坏，这牵涉到的政策决定。

每个理想的独立于其它案例；为测试时隔离模块，经常使用stubs、mock或fake等测试。单元测试通常由编写，用于确保他们所写的代码匹配软件需求和遵循。它的实施方式可以是非常手动的（通过纸笔），或者是做成的一部分。

　　5.2 集成测试

　　　　主条目：

　　　　集成测试也称综合测试、组装测试、联合测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。其主要目的是检查软件单位之间的接口是否正确，集成测试的对象是已经经过单元测试的模块。

　　　　整合测试又称组装测试，即对采用一次性或增殖方式组装起来，对系统的进行正确性检验的测试工作。整合测试一般在之后、之前进行。实践表明，有时模块虽然可以单独工作，但是并不能保证组装起来也可以同时工作。

　　5.3 系统测试[]

　　　　主条目：

　　　　系统测试主要包括功能测试、界面测试、可靠性测试、易用性测试、性能测试。 功能测试主要针对包括功能可用性、功能实现程度（功能流程&业务流程、数据处理&业务数据处理）方面测试。

　　　　系统测试是将需测试的软件，作为整个基于的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素及环境结合在一起测试。

在实际运行(使用)环境下，对计算机系统进行一系列的和确认测试。系统测试的目的在于通过与系统的作比较，发现软件与系统定义不符合或与之矛盾的地方。

　　5.4 回归测试

　　　　主条目：

　　　　回归测试指在软件维护阶段，为了检测代码修改而引入的错误所进行的测试活动。回归测试是软件维护阶段的重要工作，有研究表明，回归测试带来的耗费占软件生命周期的1/3总费用以上。

与普通的测试不同，在回归测试过程开始的时候，测试者有一个完整的测试用例集可供使用，因此，如何根据代码的修改情况对已有测试用例集进行有效的复用是回归测试研究的重要方向，此外，回归测试的研究方向还涉及自动化工具，面向对象回归测试，测试用例优先级，回归测试用例补充生成等。

　　　　回归测试是的一种，旨在检验原有功能在修改后是否保持完整。

　　回归测试过程

1. 1. 　　识别出软件中被修改的部分
   2. 　　从原测试用例库“T”中，排除所有不再适用的测试用例，确定对新版本依然有效的测试用例，创建新的基线测试用例库“TN”
   3. 　　依据一定的策略从TN中选择测试用例测试被修改的软件
   4. 　　如果必要，生成新的测试用例集“T1”，用于测试TN无法充分测试的软件部分
   5. 　　用T1执行修改后的软件

• • 　　第2和第3步测试验证修改是否破坏了现有的功能，第4和第5步测试验证修改工作本身。

　　　　观念

• • 　　回归测试是指重复执行以前的全部或部分相同的测试工作。
  • 　　新加入测试的模组，可能对其他模组产生副作用，故须进行不同程度的回归测试。
  • 　　回归测试的重心，以关键性模组为核心。

6 测试用例、测试脚本和测试场景[]

　　　　主条目：

           中的测试用例是一组条件或，测试者根据它来确定或是否正确工作。确定软件程序或系统是否通过测试的方法叫做。

7 测试过程示例[]

软件测试活动[]

• • 压力测试（英语：Stress testing），确立的一种方法，在、等领域应用比较普遍。通常在系统正常运作范围之外进行，以考察其功能极限和隐患。

8 代码覆盖率

　　　　主条目：

　　　　代码覆盖率原本是种白箱测试活动。目标软件通过特殊选项或者函数馆编译并且/或者在特殊环境（程序里每个函数都被映射回源代码里函数起点）下运行。这个过程允许开发员与品管员查看系统中在正常情况下极少或从未被读写的部分（例如：异常处理之类）并且帮助测试员确认最重要的情况（函数点）都被测过了。

测试员可查看代码覆盖率测试结果来设计测试个案、相对应的输入或者设置组以增加重要函数的代码覆盖率。两种测试员常用的代码覆盖率形式：陈述式覆盖率（或称行覆盖率）以及路径覆盖率（或称边覆盖率）。行覆盖率回报到测试完成时，运行过哪些行，或者内存大小。边覆盖率回报到测试完成时，哪些分支，或者程序决定点被运行过。正如覆盖率的“率”字所言，这两个都以百分比为单位。

通常代码覆盖率的工具与函数馆要求的性能、内存、或者其他资源开销不为正常的软件营运接受。因此它们通常只存在实验室里。又，你可能会想到软件里的许多类无法一一通过这些代码覆盖率测试，虽然代码覆盖程度可通过分析但不是直接测试。

有些瑕疵也会受这些工具的影响。个别来说某些（race condition）或者类似的对（real time）敏感度高的操作几乎不可能在代码覆盖率测试环境下侦知；相反的这类的瑕疵只会带来更多的测试码开销。

9 自动化的测试

           是使用软件工具和既定程序，对软件所进行的测试活动。

　　　　在中，测试自动化（英语：Test automation）是一种测试方法，使用特定的，去控制测试流程，并比较实际的结果与预期结果之间的差异。通过将测试自动化，可以让正式的测试过程中的必要测试，可以反复进行；通过这种方法，也可以将难以手动进行的测试，交由软件来做。这种测试方法，是流程中的必要组成。