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 不同的测试技术区分

　　3.1 覆盖测试技术

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

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

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

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

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

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

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

　　3.3 手工测试和自动化测试

　　手工测试(Manual Testing)：即依靠人力来查找Bug。方法可以参考上边的测试，也可以根据对实现技术及经验等进行不同的测试。
　　自动测试(Automation Testing)使用有针对工具实行。可以作出自动化测试的计划，对可以进行自动化测试的部分编写或者录制相应的脚本，可以加入功能，容错，表单提交等，可以参考MI，Rational或者其他类测试工具说明.

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

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

　　3.4 根据RUP标准按阶段区分测试

　　单元测试在上边有详细的叙述，还有针对单元测试和集成测试的论述，请参考。

　　集成测试分为功能集成测试和系统集成测试，相互有调用的功能集成，在系统环境下功能相互调用的影响等，使用方法可以任意选用上面的内容。注重功能方面。

　　系统测试在功能实现的基础上，可以加入兼容性，易用性，性能等等

　　验收测试可以包括Alpha和Beta测试，在这里不再详述。

　　4. 存在风险及解决方法

　　说明：测试不能找出所有的问题，只是尽量将问题在开发阶段解决大多数的问题而已。

　　测试风险如下：

　　软硬件的测试环境提供上也对测试结果有很大的影响。

　　测试团队的水平，经验，合作效果等

　　整个开发流程对测试的重视程度，测试的进入时间等

　　由于测试环境操作系统，网络环境，带宽等情况可能产生的测试结果可能不同这是需要经验以及对测试环境的保护等方面下一些功夫。

　　5. 软件缺陷的原则

　　软件缺陷区别于软件bug，它是在测试过程中出现的对系统有影响的，但是在设计中没有的或者对修改后的bug测试和开发人员有不同意见等

　　软件未达到产品说明书标明的功能。

　　软件出现了产品说明书指明不会出现的错误。

　　软件功能超出产品说明书指明范围。

　　软件未达到产品说明书虽未指出但应达到的目标。

　　软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者终用户认为不好。

　　6. 文档测试

　　产品说明书属性检查清单

　　完整.是否有遗漏和丢失?完全吗?单独使用是否包含全部内容?

　　准确.既定解决方案正确吗?目标明确吗?有没有错误?

　　精确，不含糊，清晰.描述是否一清二楚?还是自说自话?容易看懂和理解吗?

　　一致.产品功能能描述是否自相矛盾，与其他功能有没有冲突?

　　贴切.描述功能的陈述是否必要?有没有多余信息?功能是否原来的客户要求?

　　合理.在特定的预算和进度下，以现有人力，物力和资源能否实现?

　　代码无关.是否坚持定义产品，而不是定义其所信赖的软件设计，架构和代码?

　　可测试性.特性能否测试?测试员建立验证操作的测试程序是否提供足够的信息?

　　产品说明书用语检查清单

　　说明对问题的描述通常表现为粉饰没有仔细考虑的功能----可归结于前文所述的属性.从产品说明书上找出这样的用语，仔细审视它们在文中是怎样使用的.产品说明书可能会为其掩饰和开脱，也可能含糊其词----无论是哪一种情况都可视为软件缺陷.

　　总是，每一种，所有，没有，从不.如果看到此类或肯定的，切实认定的叙述，软件测试员可以着手设计针锋相对的案例.

　　当然，因此，明显，显然，必然.这些话意图诱使接受假定情况.不要中了圈套.

　　某些，有时，常常，通常，惯常，经常，大多，几乎.这些话太过模糊."有时"发生作用的功能无法测试.

　　等等，诸如此类，依此类推.以这样的词结束的功能清单无法测试.功能清单要或者解释明确，以免让人迷惑，不知如何推论.

　　良好，迅速，廉价，高效，小，稳定.这些是不确定的说法，不可测试.如果在产品说明书中出现，必须进一步指明含义.

　　已处理，已拒绝，已忽略，已消除.这些廉洁可能会隐藏大量需要说明的功能.

　　如果...那么...(没有否则).找出有"如果...那么..."而缺少配套的"否则"结构的陈述.想一想"如果"没有发生会怎样.