1、测试的定义 

软件测试是软件工程过程的一个重要阶段，是在软件发布前对软件开发各阶段产品的最终检查，是为了保证软件开发产品的正确性、完全性和一致性而检测软件错误、修正软件错误的过程。

软件测试是：

① 程序测试是为了发现错误而执行程序的过程；

② 测试是为了证明程序有错，而不是证明程序无错误；

③ 一个好的测试用例是在于它能发现至今未发现的错误；

④ 一个成功的测试是发现了至今未发现的错误的测试。

软件开发的目的是开发出实现用户需求的高质量、高性能的软件产品，而软件测试是以检查软件功能和其他非功能特性为核心，是软件质量保证的关键，也是成功实现软件开发目标的重要保障。

2、测试的种类

从测试方法角度，测试分为：

1．黑盒测试：是功能测试、数据驱动测试或基于规格说明的测试。在不考虑程序内部结构和内部特性的情况下，测试者依据该程序功能上的输入输出关系，或是程序的外部特性来设计和选择测试用例，推断程序编码的正确性。

2．白盒测试：是结构测试、逻辑驱动测试或基于程序的测试。测试者熟悉程序的内部结构，依据程序模块的内部结构来设计测试用例，检测程序代码的正确性

从测试发生的时间顺序，测试分为：

1．单元测试：是对软件基本单元的测试

2．集成测试：对由个模块组装而成的系统进行测试，检查各模块间的接口和通信

3．验收测试：验证软件的功能和性能及其它特性是否与用户的要求一致。

4．系统测试：是将通过验收测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据等其它系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列确认测试。系统测试的目的在于通过与系统的需求定义作比较,  发现软件与系统的定义不符合或与之矛盾的地方。

在MSF中，测试分为2大类：

1．覆盖测试：找出程序中的缺陷，即是否该找的地方都找了；单元测试、功能测试、检入测试、构造验证测试、回归测试。

2．使用测试：找出程序中的失败，即为什么使用不成功；配置测试、兼容性测试、强度测试、性能测试、文档和帮助文件测试、α/β测试。

3、测试的执行过程 

测试主要由下面6个相互关联、相互作用的过程组成：

1．测试计划

确定各测试阶段的目标和策略。这个过程将输出测试计划，明确要完成的测试活动，评估完成活动所需要的时间和资源，设计测试组织和岗位职权，进行活动安排和资源分配，安排跟踪和控制测试过程的活动。

2．测试设计

根据测试计划设计测试方案。测试设计过程输出的是各测试阶段使用的测试用例。测试设计也与软件开发活动同步进行，其结果可以作为各阶段测试计划的附件提交评审。测试设计的另一项内容是回归测试设计，即确定回归测试的用例集。对于测试用例的修订部分，也要求进行重新评审。

3．测试实施

使用测试用例运行程序，将获得的运行结果与预期结果进行比较和分析，记录、跟踪和管理软件缺陷，最终得到测试报告4．测试配置管理

测试配置管理是软件配置管理的子集，作用于测试的各个阶段。其管理对象包括测试计划、测试方案（用例）、测试版本、测试工具及环境、测试结果等。一般会得到一个基线测试用例库。

5．资源管理

包括对人力资源和工作场所，以及相关设施和技术支持的管理。如果建立了测试实验室，还存在其他的管理问题。

6．测试管理

采用适宜的方法对上述过程及结果进行监视，并在适用时进行测量，以保证上述过程的有效性。如果没有实现预定的结果，则应进行适当的调整或纠正。

4、几种测试类型的介绍

4.1单元测试

单元测试是对最小的可测试软件元素（单元）实施的测试，它所测试的内容包括内部结构（如逻辑和数据流）以及单元的功能和可观测的行为。侧重于单元内部结构的测试设计和实施依赖于对单元实施情况的了解（白盒方法）。为核实单元的可观测行为和功能而进行的测试设计和实施并不依赖于对实施情况的了解，因而被称为黑盒方法。

单元测试是一种非常高效的测试方法，并且是软件测试周期中第一个进行的测试。加强单元测试力度有利于降低缺陷定位和修复难度，从而降低缺陷解决成本，同时加强单元测试也减轻了后续集成测试和系统测试的负担。

单元测试一般是由开发工程师执行的。

4.1.2方法 

单元测试一般要做以下三项工作

a.设计测试用例

b.编写测试代码

c.执行待测程序

其中测试用例的设计是很重要的一步，好的测试用例的原则是：

a.能够发现至今没有发现的错误

b.测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成

c.应当包含合理的输入条件和不合理的输入条件。

可以依照以下方法来设计测试用例：

1、程序中每一条可执行语句至少被执行一次。

2、程序中每一个分支判断的每一种可能结果(主要指switch-case情况)都至少被执行一次。

3、程序中每一个分支判断中的每一个条件的可能结果都至少被执行一次。

4、程序中每一个分支判断中的每一个条件的每一种可能组合结果都至少被执行一次。

5、程序中所有的可能路径都至少被执行一次。

4.1.3常用的工具 

常用的单元测试工具有 NUnit 和 NUnitAsp。

注意：NUnit和NUnitAsp具体的用法见相关的文档。 

4.2、回归测试

4.2.1定义

回归测试是指根据修复好了的缺陷再重新进行的测试。

回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。

回归测试的目的在于验证以前出现过但已经修复好的缺陷不再重新出现。一般指对某已知修正的缺陷再次围绕它原来出现时的步骤重新测试。

当软件中所含错误被发现时，如果错误跟踪与管理系统不够完善，就可能会遗漏对这些错误的修改；而开发者对错误理解的不够透彻，也可能导致所做的修改只修正了错误的外在表现，而没有修复错误本身，从而造成修改失败；修改还有可能产生副作用从而导致软件未被修改的部分产生新的问题，使本来工作正常的功能产生错误。同样，在有新代码加入软件的时候，除了新加入的代码中有可能含有错误外，新代码还有可能对原有的代码带来影响。因此，每当软件发生变化时，我们就必须重新测试现有的功能，以便确定修改是否达到了预期的目的，检查修改是否损害了原有的正常功能。

回归测试一般是由测试工程师执行的。  

4.2.2方法 

一般进行回归测试的步骤如下：

1.建立测试基线,这是回归测试的前提。具体方式是将所有的测试用例放到配置库中，打上版本标记。

2.从基线测试用例库中提取合适的测试用例组成回归测试包，必要时进行开发和重新设计整理。

3.在后续开发过程中，每次测试之前先运行回归测试包。

保存在基线测试用例库中的测试用例可能是自动测试脚本，也有可能是测试用例的手工实现过程。

4.2.3常用的工具 

在实际工作中，回归测试需要反复进行，当测试者一次又一次地完成相同的测试时，这些回归测试将变得非常令人厌烦，为了提高回归测试的效率，我们可以使用些自动化回归测试工具。常用的工具有WinRunner等，具体的用法见相关的文档。

4.3性能测试

4.3.1目的

性能测试的目的是验证软件系统是否能够达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈，优化软件，最后起到优化系统的目的。

包括以下几个方面：

一．评估系统的能力，测试中得到的负荷和响应时间数据可以被用于验证所计划的模型的能力，并帮助作出决策。

二．识别体系中的弱点：受控的负荷可以被增加到一个极端的水平，并突破它，从而修复体系的瓶颈或薄弱的环节。

三．系统调优：重复运行测试，验证调整系统的活动得到了预期的结果，从而改进性能。检测软件中的问题：长时间的测试执行可导致程序发生由于内存泄露引起的失败，揭示程序中的隐含的问题或冲突。

四．验证稳定性（resilience）可靠性（reliability）：在一个生产负荷下执行测试一定的时间是评估系统稳定性和可靠性是否满足要求的唯一方法。

4.3.2定义 

性能测试主要测试软件的性能，包括负载测试，强度测试，数据库容量测试，基准测试以及竞争测试。

负载测试：负载测试是一种性能测试,指当数据在超负荷环境中运行时程序是否能够承担。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。

强度测试：强度测试是一种性能测试，它在系统资源特别低的情况下测试软件系统运行情况。实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。

数据库容量测试：数据库容量测试指通过存储过程往数据库表中插入一定数量的数据，看看相关页面是否能够及时显示数据。数据库容量测试使测试对象处理大量的数据，以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。

基准测试：基准测试是一种与已知现有的系统进行比较，主要检验是否与类似的产品具有竞争性的一种测试。

竞争测试：软件竞争使用各种资源（数据纪录，内存等），看他与其他相关系统对资源的争夺能力。比如：一台机器上既安装您的财务系统，又安装用友财务系统。当CPU占有率下降后，看看是否能够强过用友财务系统，而是自己的系统能够正常运行？

4.3.3 方法 

做性能测试一般可以通过一些三方的工具来实现

4.3.4常用的工具 

性能测试一般都是通过工具来完成的，常用的工具有 Microsoft Application Center Test(ACT)。

5、测试计划的制定

5.1制定的阶段

测试计划是与软件开发活动同步进行的。 在MSF的构想(Envisioning)阶段,要制定测试策略和测试的验收标准。在计划(Planning)阶段),要完成和评审测试计划及所用到的资源。在开发(Developing)阶段,要完成和评审单元测试计划。对于测试计划的修订部分，需要进行重新评审。

5.2制定过程中要考虑的因素 

1.应明确的在测试计划中确立好测试管理机制的关键事件,如。

a.汇报机制。确定好用周报制度还是日报制度，日报的反馈速度越快，定位解决问题越快，但信息处理工作量大。

b.例会制度。每周举行一次例会，根据实际情况，考虑测试计划的调整或滚动。

c.实施怎样的实验室管理制度，以做到责任明确。

d.在日报中的工作汇报。不仅要包括发现的问题，还应包括在测试时新创造的测试点，这些测试点应该补充到测试计划中作为一个测试项；

e.人员情绪如何调整。在测试周期过长时，影响测试效率的一个重要因素是测试人员的情绪，一个人反复测试一个模块，总是会出现厌倦情绪的。

2.应明确的在测试计划中确立数据的管理和分析体系的办法,如：专人对提交的过程文档,周报报告中的数据予以整理和管理，以便后期在系统测试评审时作为数据来分析。

现在往往是在系统测试结束后才来收集数据，可能会造成数据的不同程度失真或滞后。收集的数据可以按不同种类来划分。这可以依赖我们系统的CHECKLIST。有一种工具叫 SRES (软件可靠性专家系统) 是很有用的，我们可以按照它的输入数据来收集。