2.3 负载\压力测试（StressTest）

　　在这里的负载\压力和功能测试中的不同，他是系统测试的内容，是基本功能已经通过后进行的。可以在集成测试阶段，亦可以在系统测试阶段进行。

　　使用负载测试工具进行，虚拟一定数量的用户看一看系统的表现，是否满足定义中的指标。

　　负载测试一般使用工具完成，loadrunner，webload，was，ewl，e-test等，主要的内容都是编写出测试脚本，脚本中一般包括用户一般常用的功能，然后运行，得出报告。所以负载测试包括的主要内容就不介绍了。

　　负载测试技术在各种极限情况下对产品进行测试 （如很多人同时使用该软件，或者反复运行该软件），以检查产品的长期稳定性。例如，使用压力测试工具对web服务器进行压力测试。 本项测试可以帮助找到一些大型的问题，如死机、崩损、内存泄漏等，因为有些存在内存泄漏问题的程序，在运行一两次时可能不会出现问题，但是如果运行了成千上万次，内存泄漏得越来越多，就会导致系统崩滑。用J2EE实现的系统很少但是并不是没有内存问题。

　　无论什么工具基本的技术都是利用线程技术模仿和虚拟用户，在这里主要的难点在与测试脚本的编写，每种工具使用的脚本都不一样，但是大多数工具都提供录制功能就算是不会编码的测试人员同样可以测试。

　　对负载工具的延伸使用可以进行系统稳定性测试，系统极限测试，如使用100的Load Size连续使用24小时，微软定义的通过准则是通过72小时测试的程序一般不会出现稳定性的问题。

　　2.4 回归测试 （Regression Test）

　　过一段时间以后，再回过头来对以前修复过的Bug重新进行测试，看该Bug 是否会重新出现。

　　回归测试技术可以在测试的各个阶段出现，无论是单元测试还是集成测试还是系统测试。是对以前问题进行验证的过程。

　　回归测试的目的就是保证以前已经修复的Bug不会再出现。实际上，许多Bug都是在回归测试时发现的，在此阶段，我们首先要检查以前找到的Bug 是否已经更正了。值得注意的是，已经更正的Bug 也可能又回来了，有的Bug 经过修改之后可能又产生了新的Bug。所以，回归测试可保证已更正的Bug不再重现，不产生新的Bug。

　　2.5 Alpha 和Beta 测试 （Alpha and Beta Test）：

　　在正式发布产品之前往往要先发布一些测试版，让用户能够反馈出相关信息，或者找到存在的Bug，以便在正式版中得到解决。

　　特别是在有客户参加的情况下，对系统进行测试可能会出现一些我们没有考虑的情况，还可以解决一些客户实际关心的问题。

　　不同的测试技术区分

　　3.1 覆盖测试技术

　　说明：测试覆盖率可以看出测试的完成度，在测试分析报告中可以作为量化指标的依据，测试覆盖率越高效果越好。

　　覆盖测试可以是程序代码的执行路径覆盖，亦可以是功能实现的步骤覆盖（可以理解成流程图的路径覆盖）。

　　该技术可以用在任何测试阶段，包括单元测坏死、集成测试、系统测试。

　　使用该技术时可以使用以上的任何测试方法和测试技术。

　　3.2 白盒测试和黑盒测试技术

　　白盒测试技术 （White Box Testing）该技术主要的特征是测试对象进入了代码内部，根据开发人员对代码和对程序的熟悉程度，对有需要的部分进行在软件编码阶段，开发人员根据自己对代码的理解和接触所进行的软件测试叫做白盒测试。这一阶段测试以软件开发人员为主，使用Xunit系列工具进行测试，可以包括很多方面如功能性能等。

　　黑盒测试 （Black Box Testing）测试的主体部分黑盒测试的内容主要有以下几个方面，但是主要还是功能部分。主要是覆盖全部的功能，可以结合兼容，性能测试等方面进行，包括的不同测试类型请参考以上内容。

　　3.3 手工测试和自动化测试

　　手工测试（Manual Testing）：即依靠人力来查找Bug。方法可以参考上边的测试，也可以根据对实现技术及经验等进行不同的测试。

　　自动测试（Automation Testing）使用有针对工具实行。可以作出自动化测试的计划，对可以进行自动化测试的部分编写或者录制相应的脚本，可以加入功能，容错，表单提交等，可以参考MI，Rational或者其他类测试工具说明。

　　根据权威的软件测试经验，手工测试还是主要的测试方法，自动测试不够灵活，在这里不再详述。微软的测试过程80％还是手工完成。

　　自动测试永远也代替不了手工测试，但是手工测试的工作量很大是不争的事实。