如果对您对性能测试感兴趣，请加我的飞信群。群号：8542195  群名称：软件医院

    编写通信类性能测试脚本，最主要的需要先了解TCP/IP，SOCKET传输机制，SOAP,XML等传输协议。.NET已经为大家准备好了完备的类库，直接拿来用就可以了。
    具体实践中大家可以详细研究一下.NET为大家提供的用例代码，通俗易懂。

如果对您对性能测试感兴趣，请加我的飞信群。群号：8542195  群名称：软件医院

    想学习如何用VS2005.NET编写性能测试脚本，首先要了解.NET提供的类库。具体可以参考其帮助文档。
刚开始编写LoadRunner脚本，大家需主要先了解如下几个类：

1. TcpClient

2. NetworkStream

3. HttpWebRequest

4. HttpWebResponse

5. XmlDocument

6. String

其次，大家需要了解Loadrunner所提供的以下方法：

LoadRunner.LrApiClass

方法：

error_message

message

eval_string等

get_attrib_string等

start_transaction

end_transaction

set_transaction

如果对您对性能测试感兴趣，请加我的飞信群。群号：8542195  群名称：软件医院
　　通常大家发现软件缺陷时会对软件缺陷进行分类，可分类的方式只有一种，就是严重极别,难道没有其它的分法吗。比如我们碰到下面这种情况，测试人员发现有一种功能是必需加入进去的，这时他与程序员说，程序员说没有时间或是不必要，这时这种情况则会形成两者的扯皮，最终的结果也就不了了知了，这样会戳伤了测试人员的积极性，下次他们再也不会尽心的考虑产品的问题，只要可以运行就可以了。其实这种情况是可以解决的,下面我会提到一个新的软件缺陷分类概念，从而有效的解决这个问题。在软件缺陷中不仅仅只是严重极别，更多的则是功能没有做到。说到这里也许大家都理解了，就是需求没有考虑到，可需求不会一次就很完美的，需要大家的共同努力，来不断的完善。那么怎样才能让测试人员提出的好的建议得到有效的执行？这就是我下面想说的。
　　在软件缺陷中还有一种分法，跟据缺陷内容来分，主要分为需求Bug与程序Bug，对于这种分法的好处就是明确了Bug处理的责任人。对于程序Bug我们都知道是由相关开发人员进行处理。下面主要讨论一下需求 Bug,需求Bug从名称上来就知道是要交由需求人员进行处理，可怎么处理，怎样在处理的过程中有效的让这些创意得到体现。现在我们都有Bug管理系统，这时我们的测试人员将需求Bug不是提交给程序员，而是提交给需求分析人员，由他们进行处理，不过这里我想强调的是对需求Bug的定位，如果这个Bug在软件需求说明书中明确提到了，这时就不可能定位它为需求Bug，它是必需让程序员实现的，称为软件功能缺陷，提交由程序员进行处理。但如果需求说明书没有明确提到的，我们则可以定位为需求
　　这样处理有以下好处，首先需求Bug再不象以前，没有人进行确认，需求的处理人员本来就是需求人员，由他们确认与跟踪是最好不过的，因为他们对需求有绝对的权威。同时测试人员其实就是最早的用户，他们的需求就是用户的需求，这种方法加强了需求人员与测试人员的沟通，使需求得到有效的补充，从而让产品更加完善。还有测试人员从本质上来说与程序员还是对立的，这里如果为了这样一个不是软件本身问题的问题形成与开发人员的对立，则会出现赢得战役而丢失整个战争的情况，测试人员协调好与开发人员的关系，让他们更有效的对软件本身的缺陷形成有效的关注是最好的。还有最为关键的一点，测试人员的激情是最重要的，如果他们的想法没有得到体现，这时会渐渐的失去对测试的兴趣，从而软件的质量则会无法得到保证，通过这种方法可以让他们看到自己的建议可以通过对需求人员的反映得到实现，让他们时时觉得自己的想法是可以通过这种方法来有效的推行，这样工作的积极性才会有保障。
　　不过从实施的角度来说，还是有一定的困难的，首先要让大家改变以前那种凡是Bug就是由开发人员负责的观念，其次需求人员的工作量是要加大的，不过广泛的了解需求是他们的本份工作，想来不会很困难，还有必需要有有效的Bug管理工具，比如BugManage等等，不要出现那种对需求人员说了，可过两天就忘的情况出现，这时需求Bug的生命周期会出现跨越两个软件开发周期，因为有些需求会在下一版实现，这时测试人员需要延长对这些需求Bug的管理，不过我想这些需求是他们提出的，会有兴趣对这些Bug进行管理的。

如果对您对性能测试感兴趣，请加我的飞信群。群号：8542195  群名称：软件医院

　　因为软件测试的工作量很大（40% 到60% 的总开发时间），而又有很大部分适于自动化，因此，测试的改进会对整个开发工作的质量、成本和周期带来非常显著的效果。
　　首先，谈谈在测试自动化的情况下，带有图形界面的产品的测试用例的设计问题。因为图形界面的输出显示不是很容易做到测试结果自动化比较，所以一般的做法是把图形界面输出的部分单独建立测试用例，以手工运行。而所有非图形输出则可进行自动测试。
　　下面举出一些测试自动化的例子：
　　1.测试个案（test case ，或称为测试用例）的生成
　　用编程语言或更方便的剧本语言（scrīpt language 例如Perl等）写出短小的程序来产生大量的测试输入（包括输入数据与操作指令）。或同时也按一定的逻辑规律产生标准输出。输入与输出的文件名字按规定进行配对，以便控制自动化测试及结果核对的程序易于操作。
　　这里提到测试个案的命名问题，如果在项目的文档设计中作统一规划的话，软件产品的需求与功能的命名就应该成为后继开发过程的中间产品的命名分类依据。这样，就会为文档管理和配置管理带来很大的方便，使整个产品的开发过程变得更有条理，更符合逻辑。任何新手半途加入到开发工作中也会更容易进入状态。
　　2.测试的执行写控制
　　单元测试或集成测试可能多用单机运行。但对于系统测试或回归测试，就极有可能需要多台机在网络上同时运行。记住一个这样的原则，在开发过程中的任何时候，如果你需要等候测试的运行结果的话，那就是一个缩短开发时间的机会。
　　对于单个的测试运行，挖潜的机会在测试的设置及开始运行和结果的对比及显示。有时候，需要反复修改程序，重新汇编和重新测试。这样，每一个循环的各种手工键入的设置与指令所花费的时间，加起来就非常可观。如果能利用make或类似的软件工具来帮助，就能节省大量的时间。
　　对于系统测试或回归测试这类涉及大量测试个案运行的情况，挖潜的的机会除了利用软件工具来实现自动化之外，就是怎样充分利用一切硬件资源。往往，就算是在白天的工作时间内，每台计算机的负荷都没有被充分利用。能够把大量测试个案分配到各台机器上去同时运行，就能节省大量的时间。另外，把大量的系统测试及回归测试安排到夜间及周末运行，更能提高效率。
　　如果不购买商品化的工具的话，应当遵从正规的软件开发要求来开发出好的软件测试自动化工具。在实践中，许多企业自行开发的自动化工具都是利用一些现成的软件工具再加上自己写的程序而组成的。这些自己开发的工具完全是为本企业量身定做的，因此可用性非常强。同时，也能根据需要随时进行改进，而不必受制于人。当然，这就要求有一定的人力的投入。
　　在设计软件自动测试工具的时候，路径（path）控制是一个非常重要的功能。理想的使用情况是：这个工具可以在任何一个路径位置上运行，可以到任何路径位置去取得测试用例，同时也可以把测试的结果输出放到任何的路径位置上去。这样的设计，可以使不同的测试运行能够使用同一组测试用例而不至于互相干扰，也可以灵活使用硬盘的空间，并且使备份保存工作易于控制。
　　同时，软件自动测试工具必须能够有办法方便地选择测试用例库中的全部或部分来运行，也必须能够自由地选择被测试的产品或中间产品采作为测试对象。
　　3.测试结果与标准输出的对比
　　在设计测试用例的时候，必须考虑到怎样才能够易于对此测试结果和标准输出。输出数据量的多少及数据格式对比较的速度有直接影响。而另一方面，也必须考虑到输出数据与测试用例的测试目标的逻辑对应性及易读性，这将会大大有利于分析测试所发现的不吻合，也有利于测试用例的维护。
　　许多时候，要写一些特殊的软件来执行测试结果与标准输出的对比工作，因为可能有部分的输出内容是不能直接对比的（比如，对运行的日期时间的记录，对运行的路径的记录，以及测试对象的版本数据等），就要用程序进行处理。
　　4.不吻合的测试结果的分析、分类、记录和通报
　　上一点所谈到的，用于对测试结果与标准输出进行对比的特殊软件，往往也同时担任对不吻合的测试结果进行分析、分类、记录和通报的任务。
　　“分析”是找出不吻合的地方并指出错误的可能起因。“分类”包括各种统计上的分项，例如，对应的源程序的位置，错误的严重级别（提示、警告、非失效性错误、失效性错误；或别的分类方法），新发现的还是已有记录的错误，等等。“记录”，是按分类存档。“通报”，是主动地对测试的运行者及测试用例的“负责人”通报出错的信息。
　　这里提到测试用例的“负责人”的概念。是用以指定一个测试用例运行时发现的缺陷，由哪一个开发人员负责分析（有时是另外的开发人员引进的缺陷而导致的错误）及修复。在设立测试用例库时，各用例均应有指定的负责人。
　　最直接的通报方法是由自动测试软件发出电子邮件给测试运行者及测试用例负责人。邮件内容的详细程度可根据需要灵活决定。
　　5.总测试状况的统计，报表的产生
　　这些都是自动测试工具所应有的功能。目的是提高过程管理的质量，同时节省用于产生统计数据的时间。
　　产生出来的统计报表，最好是存放到一个约定的路径位置，以便任何有关人员都知道怎样查阅。同时，可按需要用电子邮件向适当的对象（如项目经理，测试经理和质量保证经理）寄出统计报表。
　　6.自动测试与开发中产品每日构建（build ）的配合
　　自动测试应该是整个开发过程中的一个有机部分。自动测试要依靠配置管理来提供良好的运行的环境，同时它必须要与开发中的软件的构建紧密配合。
　　在开发中的产品达到一定程度的时候，就应该开始进行每日构建和测试。这种做法能使软件的开发状态得到频繁的更新，以及及早发现设计和集成的缺陷。
　　为了充分利用时间与设备资源，下班之后进行自动的软件构建，紧接着进行自动测试（这里多数指的是系统测试或回归测试），是一个非常行之有效的方法。如果安排得好，到第二天上班时，测试结果就已经在各人的电子邮箱里面面了，等待着新的一天的开发工作。

　　我们一般把发现的错误bug(我们也称为缺陷defect)按严重性分为4类：
　　死机(系统崩溃或挂起)
　　致命(使系统不稳定、或破坏数据、或产生错误结果，而且是常规操作中经常发生或非常规操作中不可避免的)
　　严重(系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果，如：显示不正确但输出正确)
　　一般(界面拼写错误或用户使用不方便)。
　　我们也把发现的错误按优先级分为三种：高、中、低：一般是越影响用户接受或使用该产品的错误优先级越高。
　　但下面，将不对所有的问题进行列举和分析，而只是列出一些显而易见的、容易被项目组忽略的错误，这些错误可能是容易修改的、或是容易避免的，但是对于测试组或用户来说可能却是非常头痛和不方便的。
　　形象类问题：---不专业、用户不信任
　　1、不符合用户操作习惯。如，快捷键定义不科学、不实用(键位分布不合理、按键太多，甚至没有快捷键)。
　　2、不够专业，缺乏基本知识，而又没有高手检查。
　　3、界面中英文混杂，经常弹出莫名其妙的信息，而且还拼错单词
　　4、SETUP界面：CopyRight 1994-1996；缺省认为用户使用某种分辨率；
　　5、说明书或帮助的排版格式不专业：中英文搭配不对、标点符号全角半角部分、没有排版准则…
　　6、程序名/路径名是程序员的名字、或没有安装程序、或安装程序不完善(丢掉一些必要的模块或文件)
　　7、界面元素参差不齐，文字不能完全显示，TAB时鼠标乱走。
　　可用性问题：---用户无法使用或不方便使用
　　"用户比开发或测试人员在接触界面上要花费更多时间。表面上不重要的方面的影响会变得越来越大，最终甚至会掩盖了产品得有用得方面。"
　　下面是一些用户界面错误的例子：
　　1、输入无合法性检查和值域检查，允许用户输入错误的数据类型，并导致不可逆料的后果
　　2、界面中的信息不能及时更新，不能正确反映数据状态，甚至对用户产生错误的误导。如：数据库中剩余记录个数；参数设置对话框中的预设值
　　下面是一些低效的用户界面的例子：
　　1、表达不清或过于模糊的信息提示
　　2、要求用户输入多余的、本来系统可以自己得到的数据。如：服务是否启动，安装后用户要手动修改某些配置文件。
　　3、为了达到某个设置或对话框，用户必须做许多冗余操作。如，对话框嵌套层次太多。
　　4、不能记忆用户的设置或操作习惯，用户每次进入都需要重新操作一次初始环境。
　　5、使用不完善的功能且不给用户以恰当的提示。
　　6、不经用户确认就对系统或数据进行重大修改
　　稳定性问题：---影响用户正常工作
　　1、不可重现的死机，或不断申请但不完全释放资源，系统性能越来越低
　　2、主系统和子系统使用同样的临界资源而互相不知道。如：使用同样的类名或临时文件名、使用同样的数据库字段名或登录帐号。
　　3、不能重现的错误，许多与代码中的未初始化变量(在Debug时一般是缺省初始化的)有关，有些与系统不检查异常情况(如内存申请不成功、网络突然中断或长时间没有响应)有关。
　　其他问题
　　1、文档匮乏：无标准；无新功能使用方法；无版本改动说明。我们不仅要认为没有说明文档的产品不是是一个完整的产品，也要认为没有说明或没有正确说明的功能是一个没有完全实现的功能，因为用户无法用得起来。
　　2、运行时不检查内存、数据库或硬盘空间等
　　3、无根据地假设用户环境：硬件/网络环境；有些动态库；安装程序换台机器不正确；假设网络随时都是连通的
　　4、提供的版本带病毒，或根本无法安装，或没有加密
　　5、提供Debug版本给测试组或测试用户，或项目组与测试组使用不同版本
　　6、用户现场开发和修改，又没有记录和保留
　　7、错误反复出现，改动得不彻底、或版本管理出现混乱
　　8、错误越改越多，改动得不彻底、或改动得不小心
　　9、版本中部分内容和接口倒退
　　10、有些选项永远是灰的；有些选项、菜单项在该灰时还不灰，并且还能状态显示
　　11、资源没有和代码分离，不同语言版本间不能平滑转换
　　12、缺少第三方产品的评估：广告管理系统2000年问题
　　13、产品配合不利，准备当作一套产品或方案推出，互相之间却各不负责，(没有整个项目负责人，是面向组织的而不是面向产品或方案的)。
　　期望项目组关注的一些问题
　　1、修改Bug的人考虑得不够周全，也可能是没有能力考虑周全---不懂全部程序
　　2、问题留给测试组去发现的心态----不仔细测试、不小心修改、甚至不全面改(不彻底)
　　3、自己不会用，不了解产品的用法。
　　4、更多地从用户使用的角度考虑设计、编码与测试 

　　Analysis会话的目的是查找系统的性能故障，然后确定这些故障的根源。
　　1:是否满足了测试的预期目标？在负载下，用户终端的事务响应时间是多少？这些事务的平均事务响应时间是多少？
　　2:系统的哪些部分导致性能下降？该网络和服务器的响应时间是多少？
　　3:通过将事务时间和后端监控器矩阵关联起来，您是否能找到可能的原因？
　　在以下部分中，您将学习如何打开LoadRunner Analysis以及生成和查看图及报告，这将有助于您找出性能问题并确定该问题的根源。

　　负载测试指在典型的工作条件下测试应用程序，例如，多个旅行代理同时在相同的航班预订系统中预订航班。
　　测试用于模拟真实情况。为此，需要能够在应用程序上生成较重负载并计划应用负载的时间（因为用户不会正好在同一时间登录或注销）。还需要模拟各种不同的用户活动和行为。例如，某些用户可能使用Netscape（而不是Internet Explorer）来查看应用程序的性能，并且可能使用了不同的网络连接（例如，调制解调器、DSL或电缆）。您可以在场景中创建并保存这些设置。
　　Controller可以提供所有您需要的有助于创建并运行测试的工具，以准确地模拟您的工作环境。
　　场景目标
　　在本课中，目标是创建一个场景，用来模拟十个旅行代理同时登录系统、搜索航班、购买机票、查看路线和注销系统的行为。
　　启动 Controller
　　要开始创建场景，请打开Controller并创建一个新的场景。
　　1           打开Mercury LoadRunner。
　　选择“开始”>“程序”>“Mercury LoadRunner”>“LoadRunner”。将打开“Mercury LoadRunner Launcher”窗口。
　　2           打开Controller。
　　在“Load Testing”选项卡中，单击“Run Load Tests”。将打开LoadRunner Controller。
　　默认情况下，Controller打开时将显示“新建场景”对话框。
　　3           选择场景类型。
　　选择“手动场景”。
　　通过手动场景，可以控制正在运行的Vuser数量及其运行的时间，还可以测试应用程序可以同时运行的Vuser数。您可以使用百分比模式根据业务分析员指定的百分比在脚本间分配全部的Vuser。
　　面向目标的场景用于确定系统是否可以达到特定的目标。由您确定基于的目标，例如，指定的事务响应时间或每秒点击次数/事务数，并且LoadRunner将根据这些目标自动为您创建场景。您将在第9课“面向目标的高级场景”中创建面向目标的场景。

在测试环境中，LoadRunner会在物理计算机上用虚拟用户（即Vuser）代替实际用户。Vuser通过以可重复、可预测的方式模拟典型用户的操作，在系统上创建负载。

LoadRunner虚拟用户生成器(VuGen)采用录制并播放机制。当您在应用程序中按照业务流程操作时，VuGen将这些操作录制到自动脚本中，以便作为负载测试的基础。

注意：如果已经完成了Mercury LoadRunner快速入门，您将注意录制的脚本步骤与将在以下部分录制的脚本步骤相同。但是，整个录制过程将在此处进行更详细介绍。

　　Client/Server 测试
　　Roger S. Pressman
　　通常，客户 / 服务器软件的测试发生在三个不同的层次：
　　（ 1 ）个体的客户端应用以 “ 分离的 ” 模式被测试 —— 不考虑服务器和底层网络的运行；
　　（ 2 ）客户端软件和关联的服务器端应用被一起测试，但网络运行不被明显的考虑；
　　（ 3 ）完整的 C/S 体系结构，包括网络运行和性能，被测试。
　　下面的测试方法是 C/S 应用中经常用到的：
　　应用功能测试 —— 客户端应用被独立地执行，以揭示在其运行中的错误。
　　服务器测试 —— 测试服务器的协调和数据管理功能，也考虑服务器性能（整体反映时间和数据吞吐量）。
　　数据库测试 —— 测试服务器存储的数据的精确性和完整性，检查客户端应用提交的事务，以保证数据被正确地存储、更新和检索。
　　事务测试 —— 创建一系列的测试以保证每类事务被按照需求处理。测试着重于处理的正确性，也关注性能问题。
　　网络通信测试 —— 这些测试验证网络节点间的通信正常地发生，并且消息传递、事务和相关的网络交通无错的发生。
　　回归测试
　　Roger S. Pressman
　　每当一个新的模块被当作集成测试的一部分加进来的时候，软件就发生了改变。新的数据流路径建立起来，新的 I/O 操作可能也会出现，还有可能激活了新的控制逻辑。这些改变可能会使原本工作得很正常的功能产生错误。在集成测试策略的环境中，回归测试是对某些已经进行过的测试的某些子集再重新进行一遍，以保证上述改变不会传播无法预料的副作用。
　　在更广的环境里，（任何种类的）成功测试结果都是发现错误，而错误是要被修改的，每当软件被修改的时候，软件配置的某些方面（程序、文档、或者数据）也被修改了，回归测试就是用来保证（由于测试或者其他原因的）改动不会带来不可预料的行为或者另外的错误。
　　回归测试可以通过重新执行所有的测试用例的一个子集人工地进行，也可以使用自动化的捕获回放工具来进行。捕获回放工具使得软件工程师能够捕获到测试用例，然后就可以进行回放和比较。
　　回归测试集（要进行的测试的子集）包括三种不同类型的测试用例：
　　· 能够测试软件的所有功能的代表性测试用例。
　　· 专门针对可能会被修改影响的软件功能的附加测试。
　　· 针对修改过的软件成分的测试。
　　在集成测试进行的过程中，回归测试可能会变得非常庞大。因此，回归测试应当设计为只对出现错误的模块的主要功能进行测试，每当进行一个修改时，就对每一个程序功能都重新执行所有的测试是不实际的而且效率很低的。
　　α 测试
　　α 测试是由一个用户在开发环境下进行的测试，也可以是开发机构枘部的用户在模拟实际操作环境下进行的测试。软件在一个自然设置状态下使用。开发者坐在用户旁边，随时记下错误情况和使用中的问题。这是在受控制的环境下进行的测试，
　　α 测试的目的是评价软件产品的 FLURPS( 即功能、局域化、可使用性、可靠性、性能和支持 ) 。尤其注重产品的界面和特色。 α 测试人员是除开产品开发人员之外首先见到产品的人，他们提出的功能和修改意见是特别有价值的。
　　α 测试可以从软件产品编码结束之时开始，或在模块（子系统）测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程序之后再开始。有关的手册（草稿）等应事先准备好。
　　β 测试
　　β 测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。这些用户是与公司签定了支持产品预发行合同的外部客户，他们要求使用该产品，并愿意返回有关错位错误信息给开发者。与 α 测试不同的是，开发者通常不在测试现场。因而， β 测试是在开发者无法控制的环境下进行的软件现场应用。在 β 测试中，由用户记下遇到的所有问题，包括真实的以及主观认定的，定期向开发者报告，开发者在综合用户的报告之后，做出修改，最将软件产品交付给全体用户使用。
　　β 测试主要衡量产品的 FLURPS 。着重于产品的支持性，包括文档、客户培训和支持产品生产能力。只有当 α 测试达到一定的可靠程度时，才能开始 β 测试。由于它处在整个测试的最后阶段，不能指望这时发现主要问题。同时，产品的所有手册文本也应该在此阶段完全定稿。 由于 β 测试的主要目标是测试可支持性，所以 β 测试应尽可能由主持产品发行的人员来管理。

　　单元测试：单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。一个软件单元的正确性是相对于该单元的规约而言的。因此，单元测试以被测试单位的规约为基准。单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。
　　集成测试：集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。它根据集成测试计划，一边将模块或其他软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。
　　集成测试的策略主要有自顶向下和自底向上两种。
　　系统测试：系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的 “ 先知者问题 ” 。因此，系统测试应该按照测试计划进行，
　　其输入、输出和其他动态运行行为应该与软件规约进行对比。软件系统测试方法很多，主要有功能测试、性能测试、随机测试等等。
　　验收测试：验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。所不同的是，验收测试常常有软件系统的购买者代表在现场，甚至是在软件安装使用的现场。这是软件在投入使用之前的最后测试。
　　回归测试：回归测试是在软件维护阶段，对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。这里，修改的正确性有两重含义：
　　一是所作的修改达到了预定目的，如错误得到改正，能够适应新的运行环境等等；二是不影响软件的其他功能的正确性。
　　黑盒测试
　　黑盒测试注重于测试软件的功能性需求，也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品，而是用于辅助白盒测试发现其他类型的错误。
　　黑盒测试试图发现以下类型的错误：
　　1 ）功能错误或遗漏；
　　2 ）界面错误；
　　3 ）数据结构或外部数据库访问错误；
　　4 ）性能错误；
　　5 ）初始化和终止错误。
　　白盒测试在测试的早期采用，而黑盒测试主要用于测试的后期。黑盒测试故意不考虑控制结构，而是注意信息域。黑盒测试用于回答以下问题：
　　1 ）如何测试功能的有效性？
　　2 ）何种类型的输入会产生好的测试用例？
　　3 ）系统是否对特定的输入值尤其敏感？
　　4 ）如何分隔数据类的边界？
　　5 ）系统能够承受何种数据率和数据量？
　　6 ）特定类型的数据组合会对系统产生何种影响？
　　运用黑盒测试方法，可以导出满足以下标准的测试用例集：
　　1 ）所设计的测试用例能够减少达到合理测试所需的附加测试用例数；
　　2 ）所设计的测试用例能够告知某些类型错误的存在或不存在，而不是仅仅与特定测试相关的错误。
　　白盒测试
　　Rex Black
　　白盒测试，也称为结构化测试、基于代码的测试，是一种测试用例设计方法，它从程序的控制结构导出测试用例。用白盒测试产生的测试用例能够：
　　1 ）保证一个模块中的所有独立路径至少被使用一次；
　　2 ）对所有逻辑值均需测试 true 和 false ；
　　3 ）在上下边界及可操作范围内运行所有循环；
　　4 ）检查内部数据结构以确保其有效性。
　　“ 我们应该更注重于保证程序需求的实现，为什么要花费时间和精力来担心（和测试）逻辑细节？” 答案在于软件自身的缺陷：
　　1 、逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。当我们设计和实现主流之外的功能、
　　条件或控制时，错误往往开始出现在我们工作中。日常处理往往被很好地了解，而 “ 特殊情况 ”
　　的处理则难于发现。
　　2 、我们经常相信某逻辑路径不可能被执行，而事实上，它可能在正常的基础上被执行。程序的逻辑流
　　有时是违反直觉的，这意味着我们关于控制流和数据流的一些无意识的假设可能导致设计错误，
　　只有路径测试才能发现这些错误。
　　3 、笔误是随机的。当一个程序被翻译为程序设计语言源代码时，有可能产生某些笔误，很多将被语法检查机制发现，但是，其他的会在测试开始时才会被发现。笔误出现在主流上和不明显的逻辑路径上的机率是一样的。 正如 Beizer 所说的： “ 错误潜伏在角落里，聚集在边界上 ” ，而白盒测试更可能发现它。
　　GUI 测试
　　Roger S. Pressman
　　图形用户界面（ GUI ）对软件测试提出了有趣的挑战，因为 GUI 开发环境有可复用的构件，开发用户界面更加省时而且更加精确。同时， GUI 的复杂性也增加了，从而加大了设计和执行测试用例的难度。因为现在 GUI 设计和实现有了越来越多的类似，所以也就产生了一系列的测试标准。
　　下列问题可以作为常见 GUI 测试的指南：
　　窗口：
　　· 窗口是否基于相关的输入和菜单命令适当地打开？
　　· 窗口能否改变大小、移动和滚动？
　　· 窗口中的数据内容能否用鼠标、功能键、方向键和键盘访问？
　　· 当被覆盖并重新调用后，窗口能否正确地再生？
　　· 需要时能否使用所有窗口相关的功能？
　　· 所有窗口相关的功能是可操作的吗？
　　· 是否有相关的下拉式菜单、工具条、滚动条、对话框、按钮、图标和其他控制可为窗口使用，
　　并适当地显示？
　　· 显示多个窗口时，窗口的名称是否被适当地表示？
　　· 活动窗口是否被适当地加亮？
　　· 如果使用多任务，是否所有的窗口被实时更新？
　　· 多次或不正确按鼠标是否会导致无法预料的副作用？
　　· 窗口的声音和颜色提示和窗口的操作顺序是否符合需求？
　　· 窗口是否正确地被关闭？
　　下拉式菜单和鼠标操作：
　　· 菜单条是否显示在合适的语境中？
　　· 应用程序的菜单条是否显示系统相关的特性（如时钟显示）？
　　· 下拉式操作能正确工作吗？
　　· 菜单、调色板和工具条是否工作正确？
　　· 是否适当地列出了所有的菜单功能和下拉式子功能？
　　· 是否可以通过鼠标访问所有的菜单功能？
　　· 文本字体、大小和格式是否正确？
　　· 是否能够用其他的文本命令激活每个菜单功能？
　　· 菜单功能是否随当前的窗口操作加亮或变灰？
　　· 菜单功能是否正确执行？
　　· 菜单功能的名字是否具有自解释性？
　　· 菜单项是否有帮助，是否语境相关？
　　· 在整个交互式语境中，是否可以识别鼠标操作？
　　· 如果要求多次点击鼠标，是否能够在语境中正确识别？
　　· 光标、处理指示器和识别指针是否随操作恰当地改变？
　　数据项：
　　· 字母数字数据项是否能够正确回显，并输入到系统中？
　　· 图形模式的数据项（如滚动条）是否正常工作？
　　· 是否能够识别非法数据？
　　· 数据输入消息是否可理解？ 

　　========winrunner
　　1　启动时选择要加载的插件
　　2　进行一些设置（如录制模式等）
　　3　识别应用程序的GUI，即创建map(就是学习被测试软件的界面）
　　4　建立测试脚本（录制及编写）
　　5　对脚本除错及调试（保证能够运行完）
　　6　插入各种检查点（图片，文字，控件等）
　　7　在新版应用程序中执行测试脚本
　　8　分析结果，回报缺陷　
　　=========quicktestpro========
　　1　准备录制
　　打开你要对其进行测试的应用程序，并检查QuickTest中的各项设置是否适合当前的要求。
　　2　进行录制
　　打开QuickTest的录制功能，按测试用例中的描述，操作被测试应用程序。
　　3　编辑测试脚本
　　通过加入检测点、参数化测试，以及添加分支、循环等控制语句，来增强测试脚本的功能，使将来的回归测试真正能够自动化。
　　4　调试脚本
　　调试脚本，检查脚本是否存在错误。
　　5　在回归测试中运行测试
　　在对应用程序的回归测试中，通过QuickTest回放对应用程序的操作，检验软件正确性，实现测试的自动化进行。
　　6　分析结果，报告问题
　　查看QuickTest记录的运行结果，记录问题，报告测试结果。
　　＝＝＝＝TestDirect============
　　安装好后，先进入站点管理
　　1　创建域及工程
　　2　添加用户
　　3　编辑licenses及本服务器
　　4　编辑数据库
　　－－TD
　　1　选择新建的工程进行定制(列表，用户，组，版本等)
　　2　在require中增加需求
　　3　把需求转化为plan
　　4 在testlab中由计划新建测试具体用例与执行
　　5　发现bug，在defect中提交bug
　　（每一部分都可以相对独立地使用）
　　======loadrunner
　　1　制定负载测试计划
　　(分析应用程序， 确定测试目标，计划怎样执行LoadRunner）
　　2　开发测试脚本
　　（录制基本的用户脚本，完善测试脚本）
　　3　创建运行场景
　　（选择场景类型为Manual Scenario，选择场景类型，理解各种类型，场景的类型转化）
　　4　运行测试
　　5　监视场景
　　（MEMORY 相关，PROCESSOR相关，网络吞量以及带宽，磁盘相关，WEB应用程序 ，IIS5.0，SQL SERVER，NETWORK DELAY等)
　　6　分析测试结果
　　(分析实时监视图表,分析事务的响应时间,分解页面,确定WEBSERVER的问题,其他有用的功能)

　　测试用例编写规范
　　一、测试用例编写准备
　　从配置管理员处申请软件配置：《需求规格说明书》和《设计说明书》；根据需求规格说明书和设计说明书，详细理解用户的真正需求，并且对软件所实现的功能已经准确理解，然后着手制订测试用例。
　　二、测试用例制定的原则
　　测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。测试数据应该选用少量、高效的测试数据进行尽可能完备的测试；基本目标是：设计一组发现某个错误或某类错误的测试数据，测试用例应覆盖方面：
　　1、    正确性测试：输入用户实际数据以验证系统是满足需求规格说明书的要求；测试用 例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。
　　2、    容错性（健壮性）测试：程序能够接收正确数据输入并且产生正确（预期）的输出， 输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示 并进行相应处理。把自己想象成一名对产品操作一点也不懂的客户，在进行任意操作。
　　3、    完整（安全）性测试：对未经授权的人使用软件系统或数据的企图，系统能够控制的程度，程序的数据处理能够保持外部信息（数据库或文件）的完整。
　　4、    接口间测试：测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。
　　5、    数据库测试：依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行测试。
　　6、 边界值分析法：确定边界情况（刚好等于、稍小于和稍大于和刚刚大于等价类边界值），针对我们的系统在测试过程中主要输入一些合法数据/非法数据，主要在边界值附近选取。
　　7、 压力测试：输入10条记录运行各个功能，输入30条记录运行，输入50条记录运行。。。进行测试。
　　8、等价划分：将所有可能的输入数据（有效的和无效的）划分成若干个等价类。
　　9、错误推测：主要是根据测试经验和直觉，参照以往的软件系统出现错误之处。
　　10、效率：完成预定的功能，系统的运行时间（主要是针对数据库而言）。
　　11、可理解（操作）性：理解和使用该系统的难易程度（界面友好性）。
　　12、可移植性：在不同操作系统及硬件配置情况下的运行性。
　　13、回归测试：按照测试用例将所有的测试点测试完毕，测试中发现的问题开发人员 已经解决，进行下一轮的测试。
　　14、比较测试：将已经发版的类似产品或原有的老产品与测试的产品同时运行比较，或与已往的测试结果比较 。
　　说明：针对不同的测试类型和测试阶段，测试用例编写的侧重点有所不同。
　　1、  其中第1、2、6、8、9、13项为模块（组件、控件）测试、组合（集成）测试、系统测试都涉及并重点测试的方面。
　　2、  单元（模块）测试（组件、控件）测试：重点测试第5项。
　　3、  组合（集成）测试：重点进行接口间数据输入及逻辑的测试，即第4项。
　　4、  系统测试：重点测试第3、7、10、11、12、14项。
　　5、  其中压力测试和可移植性测试如果是公司的系列产品，可以选用其中有代表性的产品进行一次代表性测试即可。
　　6、  GMPS基础测试用例设计完成后，其他的测试项目只编写设计与之不同部分的测试用例。
　　7、  对于每个测试项目测试的测试用例不是一成不变的，随着测试经验的积累或在测试其他项目发现有测试不充分的测试点时，可以不断的补充完善测试项目的测试用例。
　　三、测试用例的填写
　　一个软件系统或项目共用一套完整的测试用例，整个系统测试过程测试完毕，将实际测试结果填写到测试用例中，操作步骤应尽可能的详细，测试结论是指最终的测试结果（结论为：通过或不通过）。

　　四、测试用例在软件测试中的作用
　　1、指导测试的实施
　　测试用例主要适用于集成测试、系统测试和回归测试。在实施测试时测试用例作为测试的标准，测试人员一定要按照测试用例严格按用例项目和测试步骤逐一实施测试。并对测试情况记录在测试用例管理软件中，以便自动生成测试结果文档。
　　根据测试用例的测试等级，集成测试应测试那些用例，系统测试和回归测试又该测试那些用例，在设计测试用例时都已作明确规定，实施测试时测试人员不能随意作变动。
　　2、规划测试数据的准备
　　在我们的实践中测试数据是与测试用例分离的。按照测试用例配套准备一组或若干组测试原始数据，以及标准测试结果。尤其象测试报表之类数据集的正确性，按照测试用例规划准备测试数据是十分必须的。
　　除正常数据之外，还必须根据测试用例设计大量边缘数据和错误数据。
　　3、编写测试脚本的"设计规格说明书"
　　为提高测试效率，软件测试已大力发展自动测试。自动测试的中心任务是编写测试脚本。如果说软件工程中软件编程必须有设计规格说明书，那么测试脚本的设计规格说明书就是测试用例。
　　4、评估测试结果的度量基准
　　完成测试实施后需要对测试结果进行评估，并且编制测试报告。判断软件测试是否完成、衡量测试质量需要一些量化的结果。例：测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少，等等。以前统计基准是软件模块或功能点，显得过于粗糙。采用测试用例作度量基准更加准确、有效。
　　5、分析缺陷的标准
　　通过收集缺陷，对比测试用例和缺陷数据库，分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步完善软件质量。而已有相应测试用例，则反映实施测试或变更处理存在问题。
　　五、相关问题
　　1、测试用例的评审
　　测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。测试用例在设计编制过程中要组织同级互查。完成编制后应组织专家评审，需获得通过才可以使用。评审委员会可由项目负责人、测试、编程、分析设计等有关人员组成，也可邀请客户代表参加。
　　2、测试用例的修改更新
　　测试用例在形成文档后也还需要不断完善。主要来自三方面的缘故：第一、在测试过程中发现设计测试用例时考虑不周，需要完善；第二、在软件交付使用后反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成；第三、软件自身的新增功能以及软件版本的更新，测试用例也必须配套修改更新。
　　一般小的修改完善可在原测试用例文档上修改，但文档要有更改记录。软件的版本升级更新，测试用例一般也应随之编制升级更新版本。
　　3、测试用例的管理软件
　　运用测试用例还需配备测试用例管理软件。它的主要功能有三个：第一、能将测试用例文档的关键内容，如编号、名称等等自动导入管理数据库，形成与测试用例文档完全对应的记录；第二、可供测试实施时及时输入测试情况；第三、最终实现自动生成测试结果文档，包含各测试度量值，测试覆盖表和测试通过或不通过的测试用例清单列表。
　　有了管理软件，测试人员无论是编写每日的测试工作日志、还是出软件测试报告，都会变得轻而易举。

　　测试工作也从简单测试演变为包括：编制测试计划、编写测试用例、准备测试数据、编写测试脚本、实施测试、测试评估等多项内容的正规测试。测试方式则由单纯手工测试发展为手工、自动兼之，并有向第三方专业测试公司发展的趋势。
　　一、测试用例是软件测试的核心
　　软件测试的重要性是毋庸置疑的。但如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。每个软件产品或软件开发项目都需要有一套优秀的测试方案和测试方法。
　　影响软件测试的因素很多，例如软件本身的复杂程度、开发人员（包括分析、设计、编程和测试的人员）的素质、测试方法和技术的运用等等。因为有些因素是客观存在的，无法避免。有些因素则是波动的、不稳定的，例如开发队伍是流动的，有经验的走了，新人不断补充进来；一个具体的人工作也受情绪等影响，等等。如何保障软件测试质量的稳定？有了测试用例，无论是谁来测试，参照测试用例实施，都能保障测试的质量。可以把人为因素的影响减少到最小。即便最初的测试用例考虑不周全，随着测试的进行和软件版本更新，也将日趋完善。
　　因此测试用例的设计和编制是软件测试活动中最重要的。测试用例是测试工作的指导，是软件测试的必须遵守的准则。更是软件测试质量稳定的根本保障。
　　二、什么叫测试用例
　　测试用例（Test Case）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。
　　不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。笔者主要从事企业管理软件的测试。因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。
　　三、编制测试用例
　　着重介绍一些编制测试用例的具体做法。
　　1、测试用例文档
　　编写测试用例文档应有文档模板，须符合内部的规范要求。测试用例文档将受制于测试用例管理软件的约束。
　　软件产品或软件开发项目的测试用例一般以该产品的软件模块或子系统为单位，形成一个测试用例文档，但并不是绝对的。
　　测试用例文档由简介和测试用例两部分组成。简介部分编制了测试目的、测试范围、定义术语、参考文档、概述等。测试用例部分逐一列示各测试用例。每个具体测试用例都将包括下列详细信息：用例编号、用例名称、测试等级、入口准则、验证步骤、期望结果（含判断标准）、出口准则、注释等。以上内容涵盖了测试用例的基本元素：测试索引，测试环境，测试输入，测试操作，预期结果，评价标准。
　　2、测试用例的设置
　　我们早期的测试用例是按功能设置用例。后来引进了路径分析法，按路径设置用例。目前演变为按功能、路径混合模式设置用例。
　　按功能测试是最简捷的，按用例规约遍历测试每一功能。
　　对于复杂操作的程序模块，其各功能的实施是相互影响、紧密相关、环环相扣的，可以演变出数量繁多的变化。没有严密的逻辑分析，产生遗漏是在所难免。路径分析是一个很好的方法，其最大的优点是在于可以避免漏测试。
　　但路径分析法也有局限性。在一个非常简单字典维护模块就存在十余条路径。一个复杂的模块会有几十到上百条路径是不足为奇的。笔者以为这是路径分析比较合适的使用规模。若一个子系统有十余个或更多的模块，这些模块相互有关联。再采用路径分析法，其路径数量成几何级增长，达5位数或更多，就无法使用了。那么子系统模块间的测试路径或测试用例还是要靠传统方法来解决。这是按功能、路径混合模式设置用例的由来。
　　3、设计测试用例
　　测试用例可以分为基本事件、备选事件和异常事件。设计基本事件的用例，应该参照用例规约（或设计规格说明书），根据关联的功能、操作按路径分析法设计测试用例。而对孤立的功能则直接按功能设计测试用例。基本事件的测试用例应包含所有需要实现的需求功能，覆盖率达100%。
　　设计备选事件和异常事件的用例，则要复杂和困难得多。例如，字典的代码是唯一的，不允许重复。测试需要验证：字典新增程序中已存在有关字典代码的约束，若出现代码重复必须报错，并且报错文字正确。往往在设计编码阶段形成的文档对备选事件和异常事件分析描述不够详尽。而测试本身则要求验证全部非基本事件，并同时尽量发现其中的软件缺陷。
　　可以采用软件测试常用的基本方法：等价类划分法、边界值分析法、错误推测法、因果图法、逻辑覆盖法等设计测试用例。视软件的不同性质采用不同的方法。如何灵活运用各种基本方法来设计完整的测试用例，并最终实现暴露隐藏的缺陷，全凭测试设计人员的丰富经验和精心设计。 

3．测试的人员组织
　　为了保证软件的开发质量，软件测试应贯穿于软件定义与开发的整个过程。因此，对分析、设计和实现等各阶段所得到的结果，包括需求规格说明、设计规格说明及源程序都应进行软件测试。基于此，测试人员的组织也应是分阶段的。
(1)软件的设计和实现都是基于需求分析规格说明进行的。
　　需求分析规格说明是否完整、正确、清晰是软件开发成败的关键。为了保证需求定义的质量，应对其进行严格的审查。审查小组由下列人员组成：
　　组长：1人
　　成员：包括系统分析员，软件开发管理者，软件设计、开发和测试人员和用户
(2)设计评审：
　　软件设计是将软件需求转换成软件表示的过程。主要描绘出系统结构、详细的处理过程和数据库模式。按照需求的规格说明对系统结构的合理性、处理过程的正确性进行评价，同时利用关系数据库的规范化理论对数据库模式进行审查。评审小组由下列人员组成：　　组长：1人
　　成员：包括系统分析员、软件设计人员、测试负责人员各一人。
(3)程序的测试：
　　软件测试。是整个软件开发过程中交付用户使用前的最后阶段，是软件质量保证的关键。软件测试在软件生存周期中横跨两个阶段：通常在编写出每一个模块之后，就对它进行必要的测试（称为单元测试）。编码与单元测试属于软件生存周期中的同一阶段。该阶段的测试工作，由编程组内部人员进行交叉测试（避免编程人员测试自己的程序）。这一阶段结束后，进入软件生存周期的测试阶段，对软件系统进行各种综合测试。测试工作由专门的测试组完成，测试组设组长一名，负责整个测试的计划、组织工作。测试组的其他成员由具有一定的分析、设计和编程经验的专业人员组成，人数根据具体情况可多可少，一般3～5人为宜。
4．软件测试文件
　　软件测试文件描述要执行的软件测试及测试的结果。由于软件测试是一个很复杂的过程，同时也是设计软件开发其它一些阶段的工作，对于保证软件的质量和它的运行有着重要意义，必须把对它们的要求、过程及测试结果以正式的文件形式写出。测试文件的编写是测试工作规范化的一个组成部分。
　　测试文件不只在测试阶段才考虑，它在软件开发的需求分析阶段就开始着手，因为测试文件与用户有着密切的关系。在设计阶段的一些设计方案也应在测试文件中得到反映，以利于设计的检验。测试文件对于测试阶段工作的指导与评价作用更是非常明显的。需要特别指出的是，在已开发的软件投入运行的维护阶段，常常还要进行再测试或回归测试，这时仍须用到测试文件。
(1)测试文件的类型
　　根据测试文件所起的作用不同，通常把测试文件分成两类，即测试计划和测试分析报告。测试计划详细规定测试的要求，包括测试的目的和内容、方法和步骤，以及测试的准则等。由于要测试的内容可能涉及到软件的需求和软件的设计，因此必须及早开始测试计划的编写工作。不应在着手测试时，才开始考虑测试计划。通常，测试计划的编写从需求分析阶段开始，到软件设计阶段结束时完成。测试报告用来对测试结果的分析说明，经过测试后，证实了软件具有的能力，以及它的缺陷和限制，并给出评价的结论性意见，这些意见即是对软件质量的评价，又是决定该软件能否交付用户使用的依据。由于要反映测试工作的情况，自然要在测试阶段内编写。
(2)测试文件的使用
　　测试文件的重要性表现在以下几个方面：
　　a、验证需求的正确性：测试文件中规定了用以验证软件需求的测试条件，研究这些测试条件对弄清用户需求的意图是十分有益的，
　　b、检验测试资源：测试计划不仅要用文件的形式把测试过程规定下来，还应说明测试工作必不可少的资源，进而检验这些资源是否可以得到，即它的可用性如何。如果某个测试计划已经编写出来，但所需资源仍未落实，那就必须及早解决。
　　c、明确任务的风险：有了测试计划，就可以弄清楚测试可以做什么，不能做什么。了解测试任务的风险有助于对潜伏的可能出现的问题事先作好思想上和物质上的准备。
　　d、生成测试用例：测试用例的好坏决定着测试工作的效率，选择合适的测试用例是作好测试工作的关键。在测试文件编制过程中，按规定的要求精心设计测试用例有重要的意义。
　　e、评价测试结果：测试文件包括测试用例，即若干测试数据及对应的预期测试结果。完成测试后，将测试结果与预期的结果进行比较，便可对已进行的测试提出评价意见。
　　f、再测试：测试文件规定的和说明的内容对维护阶段由于各种原因的需求进行再测试时，是非常有用的。
　　g、决定测试的有效性：完成测试后，把测试结果写入文件，这对分析测试的有效性，甚至整个软件的可用性提供了依据。同时还可以证实有关方面的结论。
(3)测试文件的编制
　　在软件的需求分析阶段，就开始测试文件的编制工作，各种测试文件的编写应按一定的格式进行。

　　 作为软件开发的重要环节，软件测试越来越受到人们的重视。随着软件开发规模的增大、复杂程度的增加，以寻找软件中的错误为目的的测试工作就显得更加困难。然而，为了尽可能多地找出程序中的错误，生产出高质量的软件产品，加强对测试工作的组织和管理就显得尤为重要。
　　从软件的生存周期看，测试往往指对程序的测试，这样做的优点是被测对象明确，测试的可操作性相对较强。但是，由于测试的依据是规格说明书、设计文档和使用说明书，如果设计有错误，测试的质量就难以保证。即使测试后发现是设计的错误，这时，修改的代价是相当昂贵的。因此，较理想的做法应该是对软件的开发过程，按软件工程各阶段形成的结果，分别进行严格的审查。软件的生命周期可用图1的流程表示。
　　为了确保软件的质量，对图1的过程应进行严格的管理。虽然测试是在实现且经验证后进行的，实际上，测试的准备工作在分析和设计阶段就开始了。
1．测试的过程及组织
　　当设计工作完成以后，就应该着手测试的准备工作了，一般来讲，由一位对整个系统设计熟悉的设计人员编写测试大纲，明确测试的内容和测试通过的准则，设计完整合理的测试用例，以便系统实现后进行全面测试。
　　在实现组将所开发的程序经验证后，提交测试组，由测试负责人组织测试，测试一般可按下列方式组织：
　　(1)首先，测试人员要仔细阅读有关资料，包括规格说明、设计文档、使用说明书及在设计过程中形成的测试大纲、测试内容及测试的通过准则，全面熟悉系统，编写测试计划，设计测试用例，作好测试前的准备工作。
　　(2)为了保证测试的质量，将测试过程分成几个阶段，即：代码审查、单元测试、集成测试和验收测试。
　　(3)代码会审：
　　代码会审是由一组人通过阅读、讨论和争议对程序进行静态分析的过程。会审小组由组长，2～3名程序设计和测试人员及程序员组成。会审小组在充分阅读待审程序文本、控制流程图及有关要求、规范等文件基础上，召开代码会审会，程序员逐句讲解程序的逻辑，并展开热烈的讨论甚至争议，以揭示错误的关键所在。实践表明，程序员在讲解过程中能发现许多自己原来没有发现的错误，而讨论和争议则进一步促使了问题的暴露。例如，对某个局部性小问题修改方法的讨论，可能发现与之有牵连的甚至能涉及到模块的功说明、模块间接口和系统总结构的大问题，导致对需求定义的重定义、重设计验证，大大改善了软件的质量。
　　(4)单元测试：
　　单元测试集中在检查软件设计的最小单位—模块上，通过测试发现实现该模块的实际功能与定义该模块的功能说明不符合的情况，以及编码的错误。由于模块规模小、功能单一、逻辑简单，测试人员有可能通过模块说明书和源程序，清楚地了解该模块的I/O条件和模块的逻辑结构，采用结构测试（白盒法）的用例，尽可能达到彻底测试，然后辅之以功能测试（黑盒法）的用例，使之对任何合理和不合理的输入都能鉴别和响应。高可靠性的模块是组成可靠系统的坚实基础。
　　(5)集成测试：
　　集成测试是将模块按照设计要求组装起来同时进行测试，主要目标是发现与接口有关的问题。如数据穿过接口时可能丢失；一个模块与另一个模块可能有由于疏忽的问题而造成有害影响；把子功能组合起来可能不产生预期的主功能；个别看起来是可以接受的误差可能积累到不能接受的程度；全程数据结构可能有错误等。
　　(6)验收测试：
　　验收测试的目的是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。
　　经过上述的测试过程对软件进行测试后，软件基本满足开发的要求，测试宣告结束，经验收后，将软件提交用户。
2．测试方法的应用
　　集成测试及其后的测试阶段，一般采用黑盒方法。其策略包括?
　　(1)用边值分析法和（或）等价分类法提出基本的测试用例；
　　(2)用猜测法补充新的测试用例；
　　(3)如果在程序的功能说明中含有输入条件的组合，宜在一开始就用因果图法，然后再按以上（1）、（2）两步进行。
　　单元测试的设计策略稍有不同。因为在为模块设计程序用例时，可以直接参考模块的源程序。所以单元测试的策略，总是把白盒法和黑盒法结合运用。具体做法有两种：
　　a、先仿照上述步骤用黑盒法提出一组基本的测试用例，然后用白盒法作验证。如果发现用黑盒法产生的测试用例未能满足所需的覆盖标准，就用白盒法增补新的测试用例来满足它们。覆盖的标准应该根据模块的具体情况确定。对可靠性要求较高的模块，通常要满足条件组合覆盖或路径覆盖标准。

　　b、先用白盒法分析模块的逻辑结构，提出一批测试用例，然后根据模块的功能用黑盒法进行补充。

（1）、性能优化工具EcoScope
EcoScope是一套定位于应用（即服务提供者本身）及其所依赖的所有网络计算资源的解决方案。EcoScope可以提供应用视图，并标出应用是如何与基础架构相关联的。这种视图是其他网络管理工具所不能提供的。EcoScope能解决在大型企业复杂环境下分析与测量应用性能的难题。通过提供应用的性能级别及其支撑架构的信息，EcoScope能帮助IT部门就如何提高应用性能提出多方面的决策方案。
EcoScope的应用主要表现在以下几个方面：
确保成功部署新应用
维护性能的服务水平
加速问题检测与纠正的高级功能
定制视图有助于高效地分析数据
（2）、数据库测试数据自动生成工具——TestBytes
在数据库开发的过程中，为了测试应用程序对数据库的访问，应当在数据库中生成测试用例数据，我们可能会发现当数据库中只有少量数据时，程序可能没有问题，但是当真正投入到运用中产生了大量数据时就出现问题了，这往往是因为程序的编写没有达到，所以一定及早地通过在数据库中生成大量数据来帮助开发人员完善这部分功能和性能。
TestBytes是一个用于自动生成测试数据的强大易用的工具，通过简单的点击式操作，就可以确定需要生成的数据类型（包括特殊字符的定制），并通过与数据库的连接来自动生成数百万行正确的测试数据，可以极大地提高数据库开发人员、QA测试人员、数据仓库开发人员、应用开发人员的工作效率。
（3）、PC—LINT
PC—LINT 主要进行更严格的语法检查功能，还完成相当程度的语义检查功能。可以这样认为：PC—LINT是一个更加智能、更加严格的编译器。PC—LINT在实现语法和某些语义规则检查时，是通过参数配置完成的，它的选项就有数百个之多，因此，在使用PC—LINT过程中，了解选项的含义也很重要。
（4）、TCL
TCL是Tool Command Language的缩写，它是一种很流行的脚本解释器，尤其在测试领域，它的最大特点是可移植性好，接口简单，方便，可以很容易地嵌入到软件中，作为自己的解释器使用。
TCL提供两种接口：编程接口和用户接口。编程接口是通过LIB或DLL形式提供的，提供了一些函数（命令）供调用，包括：分配一个解释器指针（对象）；初始化解释器（指针）；注册扩展函数等。用户接口很简单，即编写的脚本，脚本里面包含对扩展命令的调用。
（5）VB测试工具：VB Watch
（6）Java 程序的测试工具
1）Bean—Test
2）EJBQuickTest
3）JStyle
4）JTest
5）HttpUnit
6）JUnit
（7）、覆盖测试
C—Cover
C—Cover是一个测试工具软件，用来找出没有被测到的代码，并报告测试的覆盖率。C—Cover
只支持C/C++的代码覆盖率分析，其它语言不支持。但不受OS的限制。

单元测试方面：（对开发人员比较有用） J-Unit工具。
功能测试方面：E-test是个不错的选择，功能很强大，由于不是采用Post URL的方式回放脚本，所以可以支持多内码的测试数据（当然要程序支持）。基本上可以应付大部分的Web Site。
如果只是利用脚本回放代替手工劳动，或者做对页面响应数的性能测试，Microsoft Web Application Stress Tool是个不错的选择。
另外，在性能测试方面，PureLoad也是一个不错的工具，完全用Java写成，可以测试各种C/S程序， 如SMTP Server等。 这两个工具都是使用Post URL的方法测试Web Application的。对大量使用Javascrīpt的页面不太适合。 当然，如果程序在Unix，linux下面运行的话，可以直接编写Shell脚本程序，更加方便。
另外，还有很多专门的工具，比如说Linkbot是专门作页面链接测试的。
另外，测试流程管理工具也有不少，个人用过也一直在用的是Test Plan Control，短小精悍，不错。 至于WinRunner和LoadRunner之类，因为没有License，所以都没怎么用过，惭愧。不过我看过一篇英国人评价英国测试市场上最流行的五个软件的文章。WinRunner得分最高。
测试工具从测试的方法上可以分为两种：白盒测试和黑盒测试 白盒测试工具主要有：
内存资源泄漏检查：Numega中的bouncechecker,Rational的Purify等
代码覆盖率检查：Numega中的truecoverage,Rational的Purecoverage，Telelogic公司的logiscope, Macabe公司的Macabe等 代码性能检查：Numega中的truetime,Rational的Quantify等
代码静态度量分析质量检查工具：logiscope和Macabe等
黑盒测试工具主要有： 客户端功能测试：MI公司的winrunner,compuware的qarun,Rational的SQA robot等等
服务器端压力性能测试： MI公司的winload,compuware的qaload,Rational的SQA load等等
Web测试工具：MI公司的Astra系列，rsw公司的e-test suite等等
测试管理工具：rational的test manager,compuware的qadirector等等，此外还有缺陷跟踪工具 trackrecord等。
数据库测试工具:TestBytes
黑盒测试工具：QACenter、SQATeamTest，Rational Viaual Test。
回归测试工具：Rational TeamTest，WinRunner（MI公司）
WEB系统测试工具：TEST，Workberch，Web Appication Stress Tool（WAS）
白盒测试工具：Numega 、PuRe、软件纠错工具（Rational Purity）。
嵌入式测试工具：Logiscope（静态测试工具）、CodeTest。
系统负荷测试工具：RationalPerformance
涵盖测试工具范围评估工具
软件性能测试工具：LoadRunner（MI产品）、Rational Visual Qantify
测试管理工具：TestDirector（MI产品支持整个生命周期中测试流程管理）
　　　　　　　 IBM-testmanage ；　compureware-trackrecord
　　　　　　　 微创的TCM
嵌入软件测试工具：codetest 

1、 从测试功能上分
（1） 单元测试 : 针对不同语言，如JUNIT
（2） 功级测试
E—Test：功能强大，由于不是采用POST URL的方式回放脚本，所以可以支持多内码的测试数据（当然要程序支持），基本上可以应付大部分的WEB SITE。
MI公司的WINRUNNER
COMPUWARE的QARUN
RATIONAL的SQA ROBOT
（3） 压力测试
MI公司的WINLOAD
COMPUWARE的QALOAD
RATIONAL的SQA LOAD
（4） 负载测试
LOADRUNNER
RATIONAL VISUAL QUANTIFY
（5） WEB测试工具
MI公司的ASTRA系列
RSW公司的E—TEST SUITE等
（6） WEB系统测试工具
WORKBENCH
WEB APPLICATION STRESS TOOL（WAS）
（7） 数据库测试工具
TESTBYTES
（8） 回归测试工具
RATIONAL TEAM TEST
WINRUNNER
（9） 嵌入式测试工具
ATTOLTESTWARE。是ATTOLTESTWARE公司的自动生成测试代码的软件测试工具，特别适用于嵌入式实时应用软件单元和通信系统测试。
CODETEST是AppliedMicrosystemsCorp.公司的产品,是广泛应用的嵌入式软件在线测试工具。
GammaRay。GammaRay系列产品主要包括软件逻辑分析仪GammaProfiler、可靠性评测工具GammaRET等。
LogiScope是TeleLogic公司的工具套件，用于代码分析、软件测试、覆盖测试。
LynxInsure++是LynxREAL-TIMESYSTEMS公司的产品，基于LynxOS的应用代码检测与分析测试工具。
MessageMaster是ElviorLtd.公司的产品，测试嵌入式软件系统工具，向环境提供基于消息的接口。
VectorCast是VectorSoftware.Inc公司的产品。由6个集成的部件组成，自动生成测试代码，为主机和嵌入式环境构造可执行的测试架构。
（10） 系统性能测试工具
Rational Performance
（11） 页面链接测试
Link Sleuth
（12） 测试流程管理工具
Test Plan Control
（13） 测试管理工具
TestDirector 　　　　　　　　微创tcm
Rational公司的Test Manager
Compuware公司的QADirector
TestExpert：是Silicon Valley Networks公司产品的测试管理工具，能管理整个测试过程，从测试计划、测试例程、测试执行到测试报告。
（14） 缺陷跟踪工具
TrackRecord等
（15） 其他测试工具包
TestVectorGenerationSystem是T—VECTechnologies公司的产品。提供自动模型分析、测试生成、测试覆盖分析和测试执行的完整工具包，具有方便的用户接口和完备的文档支持。
TestQuestPro是TestQuest公司的非插入码式的自动操纵测试工具，提供一种高效的自动检测目标系统，获取其输出性能的测试方法。
TestWorks是SoftwareResearch.Inc公司的一整套软件测试工具，既可单独使用，也可捆绑销售使用。
2、 从测试的方法上分：
（1） 白盒测试工具
白盒测试工主要有：Numega、PuRe、软件纠错工具（Rational Purify）。
内存资源泄漏检查：
Numega中的BounceChecher
Rational的 Purify等
代码覆盖率检查：
Numega的TrueCoverage
Rational的PureCoverage
TeleLogic公司的LogiScope
Macabe公司的Macabe
代码性能检查：
Numega的TrueTime
Rational的Quantify等
代码静态度量分析度量检查工具：LogiScope和Macabe等
黑盒测试工具主要有：QACenter、SQATeamTest、Rational Visual Visual Test。
QACenter：QACenter帮助所有测试人员创建一个快速、可重用的测试过程。这些测试工具自动帮助管理测试过程、快速分析和调试程序，包括针对回归、强度、单元、并发、集成、移植，容量和负载建立测试用例，自动执行测试和产生文档结果。QACenter主要包括以下几个模块：
QARun：应用的功能测试工具。
QALoad：强负载下应用的性能测试工具。
QADirector：测试的组织设计和创建以及管理工具。
TrackRecord：集成的缺陷跟踪管理工具。
EcoTools：高层次的性能监测工具。

　　Web资源分析是从服务器入手对Web服务器的性能分析。
　　1、Hits per Second（每秒点击次数）
　　“每秒点击次数”，即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。
　　通过它可以评估虚拟用户产生的负载量，如将其和“平均事务响应时间”图比较，可以查看点击次数对事务性能产生的影响。通过对查看“每秒点击次数”，可以判断系统是否稳定。系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。
　　2、Throughput（吞吐率）
　　“吞吐率”显示的是场景运行过程中服务器的每秒的吞吐量。其度量单位是字节，表示虚拟用在任何给定的每一秒从服务器获得的数据量。
　　可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。
　　“吞吐率”图和“点击率”图的区别：
　　“吞吐率”图，是每秒服务器处理的HTTP申请数。
　　“点击率”图，是客户端每秒从服务器获得的总数据量。
　　3、HTTP Status Code Summary（HTTP状态代码概要）
　　“HTTP状态代码概要”显示场景或会话步骤过程中从Web服务器返回的HTTP状态代码数，该图按照代码分组。HTTP状态代码表示HTTP请求的状态。
　　4、HTTP Responses per Second（每秒HTTP响应数）
　　“每秒HTTP响应数”是显示运行场景过程中每秒从Web服务器返回的不同HTTP状态代码的数量，还能返回其它各类状态码的信息，通过分析状态码，可以判断服务器在压力下的运行情况，也可以通过对图中显示的结果进行分组，进而定位生成错误的代码脚本。
　　5、Pages Downloader per Second（每秒下载页面数）
　　“每秒下载页面数”显示场景或会话步骤运行的每一秒内从服务器下载的网页数。使用此图可依据下载的页数来计算Vuser生成的负载量。
　　和吞吐量图一样，每秒下载页面数图标是Vuser在给定的任一秒内从服务器接收到的数据量。但是吞吐量考虑的各个资源极其大小（例，每个GIF文件的大小、每个网页的大小）。而每秒下载页面数只考虑页面数。
　　注：要查看每秒下载页数图，必须在R-T-S那里设置“每秒页面数(仅HTML模式)”。
　　6、Retries per Second（每秒重试次数）
　　“每秒重试次数”显示场景或会话步骤运行的每一秒内服务器尝试的连接次数。
　　在下列情况将重试服务器连接：
　　A、初始连接未经授权
　　B、要求代理服务器身份验证
　　C、服务器关闭了初始连接
　　D、初始连接无法连接到服务器
　　E、服务器最初无法解析负载生成器的IP地址
　　7、Retries Summary（重试次数概要）
　　“重试次数概要”显示场景或会话步骤运行过程中服务器尝试的连接次数，它按照重试原因分组。将此图与每秒重试次数图一起使用可以确定场景或会话步骤运行过程中服务器在哪个时间点进行了重试。
　　8、Connections（连接数）
　　“连接数”显示场景或会话步骤运行过程中每个时间点打开的TCP/IP连接数。
　　借助此图，可以知道何时需要添加其他连接。
　　例：当连接数到达稳定状态而事务响应时间迅速增大时，添加连接可以使性能得到极大提高（事务响应时间将降低）。
　　9、Connections Per Second（每秒连接数）
　　“每秒连接数”显示方案在运行过程中每秒建立的TCP/IP连接数。
　　理想情况下，很多HTTP请求都应该使用同一连接，而不是每个请求都新打开一个连接。通过每秒连接数图可以看出服务器的处理情况，就表明服务器的性能在逐渐下降。
　　10、SSLs Per Second（每秒SSL连接数）
　　“每秒SSL连接数”显示场景或会话步骤运行的每一秒内打开的新的以及重新使用的SSL连接数。当对安全服务器打开TCP/IP连接后，浏览器将打开SSL连接。
　　Web Page Breakdown（网页元素细分）
　　“网页元素细分”主要用来评估页面内容是否影响事务的响应时间，通过它可以深入地分析网站上那些下载很慢的图形或中断的连接等有问题的
　　元素。
　　1、Web Page Breakdown（页面分解总图）
　　“页面分解”显示某一具体事务在测试过程的响应情况，进而分析相关的事务运行是否正常。
　　“页面分解”图可以按下面四种方式进行进一步细分：
　　1)、Download Time Breaddown（下载时间细分）
　　“下载时间细分”图显示网页中不同元素的下载时间，同时还可按照下载过程把时间进行分解，用不同的颜色来显示DNS解析时间、建立连接时间、第一次缓冲时间等各自所占比例。
　　2)、Component Breakdown(Over Time)（组件细分(随时间变化)）
　　“组件细分”图显示选定网页的页面组件随时间变化的细分图。通过该图可以很容易的看出哪些元素在测试过程中下载时间不稳定。该图特别适用于需要在客户端下载控件较多的页面，通过分析控件的响应时间，很容易就能发现那些控件不稳定或者比较耗时。

　　
　　Transactions（用户事务分析）
　　用户事务分析是站在用户角度进行的基础性能分析。
　　1、Transation Sunmmary（事务综述）
　　对事务进行综合分析是性能分析的第一步，通过分析测试时间内用户事务的成功与失败情况，可以直接判断出系统是否运行正常。
　　2、Average Transaciton Response Time（事务平均响应时间）
　　“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。
　　例：随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。
　　3、Transactions per Second（每秒通过事务数/TPS）
　　“每秒通过事务数/TPS”显示在场景运行的每一秒钟，每个事务通过、失败以及停止的数量，使考查系统性能的一个重要参数。通过它可以确定系统在任何给定时刻的时间事务负载。分析TPS主要是看曲线的性能走向。
　　将它与平均事务响应时间进行对比，可以分析事务数目对执行时间的影响。
　　例：当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈。
　　4、Total Transactions per Second（每秒通过事务总数）
　　“每秒通过事务总数”显示在场景运行时，在每一秒内通过的事务总数、失败的事务总署以及停止的事务总数。
　　5、Transaction Performance Sunmmary（事务性能摘要）
　　“事务性能摘要”显示方案中所有事务的最小、最大和平均执行时间，可以直接判断响应时间是否符合用户的要求。
　　重点关注事务的平均和最大执行时间，如果其范围不在用户可以接受的时间范围内，需要进行原因分析。
　　6、Transaction Response Time Under Load（事务响应时间与负载）
　　“事务响应时间与负载”是“正在运行的虚拟用户”图和“平均响应事务时间”图的组合，通过它可以看出在任一时间点事务响应时间与用户数目的关系，从而掌握系统在　　用户并发方面的性能数据，为扩展用户系统提供参考。此图可以查看虚拟用户负载对执行时间的总体影响，对分析具有渐变负载的测试场景比较有用。
　　7、Transaction Response Time(Percentile)（事务响应时间(百分比)）
　　“事务响应时间(百分比)”是根据测试结果进行分析而得到的综合分析图，也就是工具通过一些统计分析方法间接得到的图表。通过它可以分析在给定事务响应时间范围内能执行的事务百分比。
　　8、Transaction Response Time(Distribution)（事务响应时间(分布)）
　　“事务响应时间(分布)”显示在场景运行过程中，事务执行所用时间的分布，通过它可以了解测试过程中不同响应时间的事务数量。如果系统预先定义了相关事务可以接受的最小和最大事务响应时间，则可以使用此图确定服务器性能是否在可以接受的范围内。