录入界面	1.1	输入字段要完整，且要与列表字段相符合（参照数据库进行检查）
	1.2	必填项一律在后面用*表示（必填项为空在处理之前要有相关的提示信息）
	1.3	字段需要做校验，如果校验不对需要在处理之前要有相关的提示信息 （1）       长度校验 （2）       数字、字母、日期等等的校验 （3）       范围的校验
	1.4	录入字段的排序按照流程或使用习惯，字段特别多的时候需要进行分组显示
	1.5	下拉框不选值的时候应该提供默认值
	1.6	相同字段的录入方式应该统一（手动输入 、点选 、下拉选择、参照）
	1.7	录入后自动计算的字段要随着别的字段修改更新（如单价变后，金额也变）
	1.8	日期参照应该既能输入，又能从文本框选择

界 面 格式	2.1	字体颜色、大小、对齐方式（根据字段的性质确定）、加粗的一致性
	2.2	文本框、按钮、滚动条、列表等控件的大小、对齐、位置的一致性
	2.3	所有新增、修改、查看页面加上页面说明（如：XXX新增、XXX编辑、XXX查看等说明字样），（弹出的）界面要有标题，标题与内容要一致
	2.4	不同界面显示相同字段的一致性（如列表界面和编辑界面）
	2.5	界面按钮显示要求（查询、新增、删除顺序）
	2.6	列表的顺序排列应该统一（按照某些特定条件排序）
	2.7	下拉框中的排列顺序需要符合使用习惯或者是按照特定的规则排定
	2.8	所有弹出窗口居中显示或者最大化显示
	2.9	信息列表中如果某个字段显示过长用“…”或者分行显示
	2.10	人员、时间的缺省值一般取当前登录人员和时间
	2.11	对于带有单位的字段，需要字段的标签后面添加如下内容：“（单位）”

功 能 问 题	3.1	按钮功能的实现（如返回按钮能否返回）
	3.2	信息保存提交后系统给出“保存/提交成功”提示信息，并自动更新显示
	3.3	所有有提交按钮的页面都要有保存按钮（每个界面风格一致）
	3.4	凡是点选或者下拉选择的界面，如果一旦选择完了无法回到不选择的情况，需要加上“清除选择”功能按钮
	3.5	没有选择记录点击删除/修改按钮要提示“请先选择记录”
	3.6	选择记录后点击删除按钮要提示“确实要删除吗？”
	3.7	需要考虑删除的关联性，即删除某一个内容需要同时删除其关联的某些内容
	3.8	界面只读的时候（查询、统计、导入）等，应该不能编辑

查询问题	4.1	查询条件缺少一些可以查询的字段
	4.2	有些查询条件需要支持模糊查询
	4.3	需要考虑有些查询条件本身的关联性（即某个查询条件的取值范围是依赖于其它查询条件的取值）
	4.4	查询条件名称与信息列表及信息编辑页面相应的字段名称完全统一
	4.5	不同模块相同字段的查询方式应该统一（手动输入 、点选 、下拉选择）
	4.6	出报表的时候，查询条件需要显示在报表标题的下面，这样看报表的时候知道数据的依据是什么
	4.7	对于范围的查询采用全闭的形式（如 [2006-1-1,2006-12-30]

2．开始录制

　　假设需要测试的是Web应用，选择“Web（HTTP/HTML）”协议，单击“OK”按钮确定后，进入主窗体，如图2-5所示。

　　

　　图2-5 录制结果的主窗体

　　单击工具栏中“Start Record”按钮，根据录制的对话框，输入要测试程序的地址，开始进行录制。通过“Vuser”菜单来启动录制脚本的命令，如图2-6所示。

　　

　　图2-6 选择录制按钮

　　也可以在工具栏中直接单击“Start Recording”按钮，但录制之前还要进行相应的设置，如图2-7所示。

　　

　　图2-7 录制配置界面

　　（1）环境设置

　　首先，勾选“Record the application startup”，单击“OK”后，就会自动启动要测试的程序，还可以选择要把录制的脚本放到哪一个部分，默认情况下是“Action1”。

　　然后，单击左下角的“Options”按钮，进入录制环境设置界面，如图2-8所示。

　　● “Recording”标签页：默认情况下选择“HTML-based scrīpt”，说明脚本中采用HTML页面的形式，这种方式的scrīpt脚本容易维护和理解，推荐用这种方式录制。“URL-based scrīpt”说明脚本中的表示采用基于URL的方式，WAS和ACT中的录制方式就是这种，这种方式看上去比较乱。

　　其他标签页功能说明如下，如有需要可作相应的设置。

　　● “Browser”标签页：浏览器的选择。

　　● “Recording Proxy”标签页：浏览器上的代理设置。

　　

　　图2-8 环境设置界面

　　● “Advanced”标签页：可以设置录制时的思考时间（Think Time）、支持的字符集标准等。

　　● “Correlation”标签页：手工设置关联，通过关联可在测试执行过程中保存动态值。使用这些设置可以配置VuGen在录制过程中执行的自动关联的程度。

（2）脚本内容

　　在录制过程中，可以单击“Pause”（暂停录制）按钮，在脚本中插入事务、注释和集合，防止在录制完成后再插入这些事务找不到具体位置。当业务流程完成后，单击“Stop”（停止录制）按钮，会自动生成脚本，退出录制过程，如图2-6所示。

　　单击“Save”（保存）按钮，起个与实际业务有关系的名字，保存到相应的位置。

　　使用VuGen录制之后生成的每个Vuser脚本都至少包含vuser_init、一个或多个Actions及vuser_end等三部分。

　　在通常情况下，将登录到服务器的活动记录在vuser_init部分中，将客户端活动录制到Actions部分中，并将注销过程录制到vuser_end部分中。因为运行多次迭代的Vuser脚本时，只有脚本的Actions部分重复，而vuser_init和vuser_end部分将不重复。

　　脚本图例如图2-9所示。

　　

　　图2-9 脚本图例

　　在录制脚本期间，发出的消息可以通过日志来查看，选择“View”>“Output Window”，然后选择“Recording Log”选项卡。可以在“Run time Setting”的“Log”选项卡中设置该日志的详细级别，如图2-10所示。

　　

　　图2-10 录制日志

　　录制时，VuGen会创建一系列配置、数据和源代码文件。这些文件包含Vuser运行时和设置信息。VuGen会将这些文件连同脚本一起进行保存。

　　至此，一个完整的Vuser脚本录制完成。

　　多协议脚本的录制与单协议脚本的录制过程基本相同，只是比单协议脚本的录制多一个选项界面，如图2-11所示。

　　在此界面中单击协议，可以进行添加和删除协议的操作。在协议前的复选框中打对号，即为选中，否则删除。

　　

　　图2-11 添加协议

第2章  LoadRunner入门

　　LoadRunner是一个强有力的压力测试工具。它的脚本可以录制生成，自动关联；测试场景可以面向指标，多方监控；测试结果可以用图表显示，并且可以拆分组合。

　　作为专业的性能测试工具，通过模拟成千上万的用户对被测系统进行操作和请求，能够在实验室环境中重现生产环境中可能出现的业务压力，再通过测试过程中获取的信息和数据来确认和查找软件的性能问题，分析性能瓶颈。

　　2.1  LoadRunner创建测试脚本

　　开发LoadRunner脚本需要经过图2-1所示的几个步骤。

　　

　　在录制脚本时要遵循以下录制原则：

　　1．提高脚本执行效率

　　所录制的脚本内容要精练，而且是用户的真实操作，不可增加多余或重复性的操作，这样的脚本执行起来更能准确地模拟用户的真实行为，减少了执行时间，执行结果更准确。

　　2．录制具有代表性的功能

　　在一个软件中有很多不同的功能，但要录制所有的功能几乎是不可能的，所以要选择常用的、使用频率较高的业务功能来进行测试。

　　3．选择具有影响的事务

　　测试人员要对被测功能具有一定的认识和了解，选择一些对于整个测试过程中有影响的事务来测试，否则测试结果是无意义的。

　　当启动Visual User Generator后会出现选择脚本类型的对话框，在此对话框中，请选择我们常用的脚本类型，也就是Web（HTTP/HTML）协议，这是最为常见的。以下脚本介绍以此类型为例。

　　2.1.1  录制普通脚本

　　启动Visual User Generator，在弹出的对话框中选择需要新建的协议脚本，通过VuGen可以采用单协议或多协议模式，进行脚本的录制。选择单协议还是多协议，根据测试程序的实际需要而定。

1．选择协议

　　采用单协议模式时，VuGen将只录制指定的协议；采用多协议模式时，VuGen将录制多个协议中的操作。下列协议支持多协议脚本：COM、FTP、IMAP、Oracle NCA、POP3、RealPlayer、Window Sockets（原始）、SMTP和Web。“双协议Web/Web Services”的引擎使用一种不同的机制，应视为单协议，不能与其他多协议类型结合使用。

　　各种Vuser类型之间的另一个区别是多操作支持功能。大多数协议都可支持多个操作部分，如Oracle NCA、Web、RTE、General（C Vusers）、WAP、i-Mode 和VoiceXML等协议。

　　对于大多数Vuser类型，在每次录制时都会新建一个Vuser脚本，而不能在现有脚本中进行录制。但是，在录制Java、CORBA-Java、RMI-Java、Web、WAP、i-mode、Voice XML、Oracle NCA或RTE Vuser脚本时，可以在现有脚本中进行录制。

　　创建脚本时，单击“New”（新建）打开“New Virtual User”（新建Vuser）对话框，该对话框可提供选择录制脚本协议的快捷方式。

　　（1）单协议脚本：创建单协议Vuser脚本，这是“Startup”（启动）对话框打开时的默认选项。从Vuser生成器的“类别”中进行选择，并选择录制脚本的协议，如图2-2所示。

　　

　　图2-2  选择单协议脚本

　　（2）多协议脚本：创建多协议Vuser脚本，VuGen将显示所有可用的协议。选择一个协议后，单击右箭头，将其移入“Selected Protocols”（选定的协议）部分中，如图2-3所示。

　　

　　图2-3  选择多协议脚本

　　（3）使用最近使用过的协议新建脚本：从最近创建脚本的协议中选择已经使用过的协议，并且这些协议已经体现了录制脚本类型，如图2-4所示。

　　

　　图2-4  选择最近使用的协议

WEB性能测试种类

　　压力测试：确定一个系统的瓶颈或者不能接收用户请求的性能点，来获得系统能提供的最大服务级别的测试。

　　负载测试：在被测系统上不断增加压力　，直到性能指标达到极限，响应时间超过预定指标或者某种资源已经达到饱和状态。这种测试可以找到系统的处理极限，为系统调优提供依据。

　　大数据量测试：针对某些系统存储、传输、统计查询等业务进行大数据量的测试。

　　配置测试：通过测试找到系统各资源的最优分配原则。

　　可靠性测试：可以施加cpu资源保持70%-90%使用率的压力，连续对系统加压运行8小时，然后根据结果分析系统是否稳定。即加载一定压力的情况下，使系统运行一段时间。

　　并发测试：多以发现一些算法设计上的问题。

　　性能测试以用户并发测试为主的测试。

　　性能测试主要是为了发现软件问题和硬件瓶颈。

　　对于性能方面给系统留有30%左右的扩展空间即可。

　　Web全面性能测试模型

　　预期指标的性能测试

　　主要指需求分析和设计阶段提出的一些性能指标。

　　针对每个指标都要编写一个或者多个测试用例来验证系统是否达到要求。

　　预期指标的性能测试用例通常以单用户为主，如果涉及并发用户内容，则归并到并发用户测试用例中进行设计。

　　并发性能测试

　　选择具有代表性、关键的业务来设计用例，并且用户的设计应该面向“模块”

　　用户并发性能测试分为：独立核心模块并发性能测试，组合模块并发性能测试

　　独立核心模块并发：完全一样功能的并发测试；完全一样操作的并发测试；相同/不同的子功能并发。

　　针对独立核心模块用户并发性能的测试用例设计，可发现一些核心算法或者功能方面的问题，如一些多线程、同步并发算法在单用户模式下测试是很难发现问题的，通过模拟多用户的并发操作，更容易验证其是否正确和稳定。

　　核心模块测试一般属于基本的性能测试，它较多地关注模拟的“功能”，一般不会对服务器进行测试。

　　组合模块并发：具有耦合关系的核心模块进行组合并发测试；彼此独立的、内部具有耦合关系的核心模块组的并发测试；基于用户场景的并发测试。

　　组合模块测试一般发现接口方面的功能问题，并尽早发现综合性能问题。

　　在实际中，各种类型的用户都会对应一组模块，相当于不同的业务组在并发访问系统，要充分考虑实际场景，如话费管理系统中的每月10日左右的收费高峰等场景。

　　在编写组合模块用户并发性能测试用例时，不但要考虑用户使用场景，还要注意并发点的运用，并发点是指一定数量的用户开始执行同一功能或者操作的时间点，一组测试场景通常包含多个并发点，从而实现了核心模块同一功能或者操作的真正并发。

　　独立业务性能测试

　　独立业务实际是指一些核心业务模块对应的业务。这些模块通常具有功能比较复杂，使用比较频繁，属于核心业务等特点。主要测试这类模块和性能相关的一些算法、还要测试这类模块对并发用户的响应情况。

　　用户并发测试是核心业务模块的重点测试内容。

　　组合业务性能测试

　　是最接近用户实际使用情况的测试，也是性能测试的核心内容。

　　组合并发的突出特点是根据用户使用系统的情况分成不同的用户组进行并发，每组的用户比例要根据实际情况来进行匹配。

　　用户并发测试是组合业务性能测试的核心内容。“组合”并发的突出特点是根据用户使用系统的情况分成不同的用户组进行并发，每组的用户比例要根据实际情况来进行匹配。

　　网络性能测试

　　为准确展未带宽、延迟、负载和端口的变化是如何影响用户的响应时间的。主要是测试应用系统的用户数目与网络带宽的关系。

　　调整性能最好的办法就是软硬相结合。

　　大数据量测试

　　主要是针对对数据库有特殊要求的系统进行的测试，主要分为三种：

　　1．实时大数据量：模拟用户工作时的实时大数据量，主要目的是测试用户较多或者某些业务产生较大数据量时，系统能否稳定地运行。

　　2．极限状态下的测试：主要是测试系统使用一段时间即系统累积一定量的数据时，能否正常地运行业务

　　3．前面两种的结合：测试系统已经累积较大数据量时，一些实时产生较大数据量的模块能否稳定地工作。

　　大数据量测试用例的设计:1,历史数据引起的大数据量测试和2运行时大数据量测试

　　首先确定系统数据的最长迁移周期和选择一些前面的核心模块或者组合模块的并发用户测试用例作为其主要内容即可.

　　服务器性能测试

　　性能测试的主要目的是在软件功能良好的前提下，发现系统瓶颈并解决，而软件和服务器是产生瓶颈的两大来源，因此在进行用户并发性能测试，疲劳强度与大数据量性能测试时，完成对服务器性能的监控，并对服务器性能进行评估。

　　服务器性能测试用例设计就是确定要采集的性能计数器，并将其与前面的测试关联起来。

　　设计性能测试用例注意的原则：

　　可以满足预期性能指标测试用例要求的，就没有必要设计更多的内容，因为用例越多，执行的成本也越高。

　　一定要服从整体性能测试策略，千万不能仅从技术角度来考虑设计“全面”的测试用例，“全面”应该以是否满足自己的测试要求作为标准。

　　适当裁剪原则

　　只有根据实际项目的特点制定合理的性能测试策略、编写适当的性能测试用例，并在测试实施中灵活地变通才可以做好性能测试工作。

　　测试计划：主要包含测试范围、测试环境、测试方案简介、风险分析等，测试计划要进行评审后方可生效。

　　测试报告：主要包含测试过程记录、测试分析结果、系统调整建议等。

　　测试经验总结：不断总结工作经验是建立学习型团队的基础，实践－总结－再实践

总结以往进行的性能测试，虽然测试人员自始至终对测试工作都做到了认真负责，但测试报告出炉后，大家总觉得美中不足，对测试结果都心存疑虑，尤其在那些时间跨度较长、针对不同的测试对象的性能对比测试中，或多或少都存在以下几个方面的问题：

　　1. 测试准备不充分，测试目标不明确，测试计划不详细；

　　2. 缺乏测试以及针对测试对象的技术储备；

　　3. 测试环境的稳定性及前后一致性不足；

　　4. 测试数据精确性和代表性不足；

　　5. 测试描述不精练；

　　下面，我们就剖析以上问题的同时，探讨一下如何解决这些问题。

　　性能测试准备

　　这是一个经常被测试人员忽略的环节，在接到测压任务后，基于种种其它因素的考虑，测试人员往往急于进度，立即投入到具体的测试工作去了，测试、记录、分析，忙的不亦乐乎，工作进行了一半才发现，或是硬件配置不符合要求，或是网络环境不理想，甚至软件版本不对，一时弄得骑虎难下，这都是没有做好测试准备惹的祸。那么我们应该如何做好性能测试的准备工作呢？

　　做软件项目有需求调查、需要分析，我们做测试也一样。在拿到测试任务后，我们首要的任务就是分析测试任务，在开始测试前，我们至少要弄清以下几个问题：

　　a) 要测试什么或测试的对象是谁？

　　b) 要测试什么问题或我们想要弄清楚或是论证的问题？

　　c) 哪些因素会影响测试结果？

　　d) 需要怎样的测试环境？

　　e) 应该怎样测试？

　　只有在认真调查测试需求和仔细分析测试任务后，才有可能弄清以上一系例的问题，只有对测试任务非常清楚，测试目标极其明确的前提下，我们才可能制定出切实可行的测试计划。

　　明确测试目标,详尽测试计划

　　在对测试需求充分了解的基础上，制定尽可能详细的测试计划，对测试的实施是大有裨益的。测试计划的制定，大多专业的测试书籍多有详述，故本文不再鏊述。

　　测试技术准备

　　在目前的大环境下，要求测试人员在短时间撑握所有的软、硬件知识是不太现实的，但平时测试人员应抓紧对测试工具和测试理论的研究，在测试计划中，应给研究测试对象和测试工具分配充足的学习时间，只有在充分撑握测试工具，完全了解测试对象的前提下，我们才能够实施测试。建力在错误的认识上的测试，既使你再努力，结果也是背道而驰，也很难证明问题，更不用说用这样的测试报告去说服用户。

　　配置测试环境

　　只有在充分认识测试测试对象的基础上，我们才知道每一种测试对象，需要什么样的配置，才有可能配置一种相对公平、合理的测试环境（这在性能对比测压中尤其重要）。

　　考虑到其它因素，如网络锁、网速、显示分辩率，数据库权限、容量等对测试结果的影响。如条件允许，我们最好能配置几组不同的测试环境。

　　测试数据的获取和处理

　　在所有的测试中，测试数据的收集工作都是较为困难的，Gis软件更是如此，每一种软件都有它的文件格式，有的软件还有几种格式。在这种情况下，我们只能把第三方格式的数据转换成每一种被测试软件自已的格式。同时，还应对数据作一定的处理，如处理数据冗余，处理显示风格等。如在测试时会更新数据，操作前一定要备份数据。 其外，还应评估数据格式和数据量对测试的影响，如有必要，应准备多组数据。

　　最后，一定要检查测试数据的有效性，避免损坏数据对测试结果的影响。

　　如何开展性能测试

　　测试前期的准备工作纷繁复杂，做好测试准备工作，已是完成了测试工作的一大半，但要产生一份具有说服力的测试报告，还应正确把握测试的强度，保持测试的一致性，提高测试的精度。

　　判断软件的好坏，要看软件解决实际应用的能力，只有在一定的测试强度下，才能测试出各种软件资源的消耗率，软件运行的速度，软件的稳定性。通过对比在不同的测试强度下，不同软件每一个功能模块解决实际问题的能力和软件运行的效率，我们才可能判断出不同软件的每一个模块的强弱，甚至于整个软件的优劣。

　　性能测试开始后，所有参数的输入都应遵循统一的标准，无论是哪一个环节，哪怕是一点点偏差，都应立即纠正，觉不能心存侥幸。要特别注意外部环境对测试结果的影响，如果在整个测试过程中，外部境不一致，如网速、机器内存使用率不一样，就有可能导制测试结果与实际情况有出入。

　　如何总结性能测试

　　对测试的终结，实际就是对测试数据的分析和处理。我们测试工作做的再好，如最终到用户手中的是一堆杂乱无章的数据，那也是美中不足。

　　首先，我们最好从所有的测试数据中，筛选出具有代表意义的数据，做出统计图，然后和开发人员一起，认真分析数据，找出软件存在的问题，得出测试结论。大多数用户，真正需要的就是科学、客观的测试结论。

　　结论

　　各种软件性能测试，范围大小不同，强度高底有别，但只要本着认真、客观，科学的工作态度，遵循本文论述的方法，做好测试工作是不难的。

通用指标（指Web应用服务器、数据库服务器必需测试项)

指标	说明
ProcessorTime	服务器CPU占用率，一般平均达到70%时，服务就接近饱和
Memory Available Mbyte	可用内存数，如果测试时发现内存有变化情况也要注意，如果是内存泄露则比较严重
Physicsdisk Time	物理磁盘读写时间情况

Web服务器指标

指标	说明
Requests Per Second（Avg Rps）	平均每秒钟响应次数＝总请求时间 / 秒数
Avg time to last byte per terstion （mstes）	平均每秒业务脚本的迭代次数 ,有人会把上面那个混淆
Successful Rounds	成功的请求
Failed Requests	失败的请求
Successful Hits	成功的点击次数
Failed Hits	失败的点击次数
Hits Per Second	每秒点击次数
Successful Hits Per Second	每秒成功的点击次数
Failed Hits Per Second	每秒失败的点击次数
Attempted Connections	尝试链接数

数据库服务器性能指标

指标	说明
User 0 Connections	用户连接数，也就是数据库的连接数量
Number of deadlocks	数据库死锁
Butter Cache hit	数据库Cache的命中情况

系统的瓶颈定义

性能项	命令	指标
CPU限制	vmstat	当%user+%sys超过80%时
磁盘I/O限制	Vmstat	当%iowait超过40%(AIX4.3.3或更高版本)时
应用磁盘限制	Iostat	当%tm_act超过70%时
虚存空间少	Lsps，-a	当分页空间的活动率超过70%时
换页限制	Iostat, stat	虚存逻辑卷%tm_act超过I/O(iostat)的30%，激活的虚存率超过CPU数量(vmstat)的10倍时
系统失效	Vmstat, sar	页交换增大、CPU等待并运行队列

　稳定系统的资源状态

性能项	资源	评价
CPU占用率	70%	好
	85%	坏
	90%+	很差
磁盘I/0	<30%	好
	<40%	坏
	<50%+	很差
网络	<30%带宽	好
运行队列	<2*CPU数量	好
内存	没有页交换	好
	每个CPU每秒10个页交换	坏
	更多的页交换	很差

　　通俗理解：

　　日访问量

　　常用页面最大并发数

　　同时在线人数

　　访问相应时间

　　案例：

　　最近公司一个项目，是个门户网站，需要做性能测试，根据项目特点定出了主要测试项和测试方案：

　　一种是测试几个常用页面能接受的最大并发数(用户名参数化，设置集合点策略)

　　一种是测试服务器长时间压力下，用户能否正常操作(用户名参数化，迭代运行脚本)

　　一种则需要测试服务器能否接受10万用户同时在线操作，如果是用IIS做应用服务器的话，单台可承受的最大并发数不可能达到10万级，那就必须要使用集群，通过多台机器做负载均衡来实现；如果是用websphere之类的应用服务器的话，单台可承受的最大并发数可以达到10万级，但为性能考虑还是必须要使用集群，通过多台机器做负载均衡来实现；通常有1个简单的计算方式，1个连接产生1个session，每个session在服务器上有个内存空间大小的设置，在NT上是3M，那么10万并发就需要300G内存，当然实际使用中考虑其他程序也占用内存，所以准备的内存数量要求比这个还要多一些。还有10万个用户同时在线，跟10万个并发数是完全不同的2个概念。这个楼上已经说了。但如何做这个转换将10万个同时在线用户转换成多少个并发数呢？这就必须要有大量的历史日志信息来支撑了。系统日志需要有同时在线用户数量的日志信息，还需要有用户操作次数的日志信息，这2个数据的比例就是你同时在线用户转换到并发数的比例。另外根据经验统计，对于1个JAVA开发的WEB系统（别的我没统计过，给不出数据），一般1台双CPU、2G内存的服务器上可支持的最大并发数不超过500个（这个状态下大部分操作都是超时报错而且服务器很容易宕机，其实没什么实际意义），可正常使用（单步非大数据量操作等待时间不超过20秒）的最大并发数不超过300个。假设你的10万同时在线用户转换的并发数是9000个，那么你最少需要这样的机器18台，建议不少于30台。当然，你要是买个大型服务器，里面装有200个CPU、256G的内存，千兆光纤带宽，就算是10万个并发用户，那速度，也绝对是嗖嗖的。

　　另外暴寒1下，光设置全部进入运行状态就需要接近6个小时。具体的可以拿1个系统来压一下看看，可能会出现以下情况：

　　1、服务器宕机；

　　2、客户端宕机；

　　3、从某个时间开始服务器拒绝请求，客户端上显示的全是错误；

　　4、勉强测试完成，但网络堵塞或测试结果显示时间非常长。假设客户端和服务器之间百兆带宽，百兆/10000=10K，那每个用户只能得到10K，这个速度接近1个64K的MODEM上网的速度；另外以上分析全都没考虑系统的后台，比如数据库、中间件等。

　　1、服务器方面：上面说的那样的PC SERVER需要50台；

　　2、网络方面：按每个用户50K，那至少5根百兆带宽独享，估计仅仅网络延迟就大概是秒一级的；

　　3、如果有数据库，至少是ORACLE，最好是SYSBASE，SQL SERVER是肯定顶不住的。数据库服务器至少需要10台4CPU、16G内存的机器；

　　4、如果有CORBA，那至少再准备10台4CPU、16G内存的机器；再加上负载均衡、防火墙、路由器和各种软件等，总之没个1000万的资金投入，肯定搞不定。

　　这样的门户系统，由于有用户权限，所以并不象jackie所说大多是静态页面。但只要是多服务器的集群，那么我们就可以通过1台机器的测试结果来计算多台机器集群后的负载能力的，最多额外考虑一下负载均衡和路由上的压力，比如带宽、速度、延迟等。但如果都是在1台机器上变化，那我们只能做一些指标上的计算，可以从这些指标上简单判断一下是否不可行，比如10万并发用户却只有1根百兆带宽，那我们可以计算出每个用户只有1K带宽，这显然是不可行的。但实际的结果还是需要测试了才知道，毕竟系统压力和用户数量不是线性变化的。

　　这一类系统的普遍的成熟的使用，以及很多软件在方案设计后就能够大致估算出系统的性能特点，都导致了系统在软件性能方面调优的比例并不大（当然不完全排除后期针对某些代码和配置进行优化后性能的进一步提高），更多的都是从硬件方面来考虑，比如增加内存、硬盘做RAID、增加带宽、甚至增加机器等。

　　网络技术中的10M 带宽指的是以位计算， 就是 10M bit /秒 ，而下载时的速度看到的是以字节（Byte）计算的，所以10M带宽换算成字节理论上最快下载速度为： 1.25 M Byte/秒!

　　对于一个开发比较成熟的业务系统而言，功能相对已经完善，但在大业务量的情况下往往会出现各种异常。对此，需通过对系统进行配置修改或者产品框架调整来优化系统。在优化系统过程中，最有效的手段就是对系统做性能测试，通过测试结果的收集分析，不断进行系统优化，最终达到系统在大业务量情况下稳定运行的目的。

　　一、测试方法

　　测试方法主要通过测试过程中的测试步骤体现出来。测试步骤需根据每次的测试结果不断调整，一个完善的测试方法需要不断地进行性能测试和性能调整。在开始性能调整循环之前，必须确定以下两点：一是建立业务模型，通过统计或数学模型的方法建立起科学的业务模型，如业务流程分布比例、平均负荷、峰值负载等；二是设置性能指标，作为判断设计指标和实际性能处理指标的基准值，总体的系统吞吐量、系统的吞吐效率、响应时延等都是用于测量性能的常用度量标准。

　　确定以上两点后，开始调整循环，这是一系列重复的受控性能试验。重复四个调整循环阶段，直至获得在开始调整过程前建立的系统性能目标。

　　二、测试阶段

　　测试阶段是调整循环操作的起点，此阶段是根据测试的要求进行相关操作，为下一步结果统计提供相应的测试数据。此阶段需要注意测试环境配置、测试用例的操作两个要点。

　　1、 测试环境配置

　　不同的测试环境会产生不同的测试结果，因此测试前需要对环境配置进行详细的检查。

　　(1)  检查网络连通性。网络畅通是测试能够正常进行的基本前提。

　　(2)  检查流量模型是否超出系统负荷。如果将要加的压力大大超出系统的负荷，会对系统产生伤害，并可能在测试过程中出现宕机、告警等异常情况。

　　(3)  检查被测系统的系统配置。此系统配置包括软件版本和硬件配置两个方面，不同的系统配置会产生不同的测试结果，故测试之前应对被测系统的配置进行严格核对，检查是否是测试所需的系统配置。

　　(4)  检查测试工具的参数配置。在性能测试中，必须利用测试工具来模拟大业务量。对于一个功能相对完善的测试工具，不但能模拟大业务量，而且还能够配置压力递增方式、压力大小、压力持续时间等参数。在测试之前需要根据测试的需求检查相应参数配置是否满足测试要求。

　　2、测试用例操作

　　测试过程中，性能测试主要按照测试用例规定的内容去逐步操作。一般来讲性能测试用例内容大体分成测试环境配置、预置条件、测试步骤、预期结果、判定原则、测试结果六个方面。

　　环境配置是指按照测试的需求配置测试环境，包括网络的组网、系统的参数配置等；测试预置条件是指为了真实模拟一些场景，需要在测试之前在系统中预置一些条件，例如在邮箱系统的性能测试过程中，为了模拟业务开展的实际情况测试，需要在邮件系统中预先存储一些积压的邮件；测试步骤是指在环境配置完成及预置条件完成后，如何对系统加压的过程，一般而言，首先确定压力的生成形式(如阶梯型递增、二次曲线形式递增等)，然后确定压力递增的时间，最后要求压力保持的时间；预期结果是指通过理论及经验分析，对实际测试结果的一个预期指标，此内容是检验测试结果的一个依据；判定原则是制定出一个标准来判断测试是否满足要求，此原则的制定很大程度上依据测试的预期结果；测试结果是根据实际测试情况及参考预期结果和判定原则对测试的一个总体结论，其结论包括此项测试是否通过及测试的相应指标记录两个方面。

　　3、结果统计

　　此过程是调整循环内容中一个承上启下的环节。此环节统计的数据来源于上一次的测试结果，并为下一步的数据分析提供相关数据。

　　结果的统计可以来源于被测系统和测试工具本身两个方面，在统计过程中不但要考虑到从被测系统中统计数据还要兼顾到测试工具本身的数据统计。一般来讲，从被测系统可以直接通过系统的日志统计出系统资源消耗(如CPU、内存的占用率等)；从测试工具本身可以统计出压力的大小、业务处理时延、业务处理成功率等指标。结果统计阶段需要将以上两个方面的数据一并统计出来，为下一步数据分析提供重要依据。

　　4、结果分析

　　通过数据统计收集到系统所需的性能数据后，对这些数据进行分析以确定系统瓶颈。在这里，需要明确的是统计到的体现性能数据仅具有指示性，它并不一定就可以确定实际的瓶颈在哪里，因为一个性能问题可能由多个原因所致。因此，在结果分析阶段需要从系统的角度去分析并查找原因，千万不能走入“头痛医头，脚痛医脚”的误区。在结果分析阶段应该注意到以下几个方面。

　　(1)  数据发现的敏感性，能够主动发现一些貌似“合理”的数据问题。

　　(2)  数据分析的系统性，能够通过测试数据的表象，从系统的角度对数据进行分析，发现系统瓶颈。

　　(3)  数据合理的疑问性，测试工作的目的就是要发现问题，优化系统，所以应该抱着对所有数据怀疑的态度去分析测试数据，这样才能做到不遗漏任何的“可疑”数据。

　　(4)  结果分析的分步性，通过测试经验，对于测试结果分析可以分成六步进行，包括观察、初步假设、预测、测试、控制和结论，结论由该过程积累的最佳证据集合所支持的假设组成。

　　三、总结

　　在循环调整的过程中，测试、结果统计、结果分析环节的最终目的是要对系统进行优化。因此，系统优化的依据直接来源于对测试结果的分析。通常来讲，对于一个比较成熟的系统，系统的绝大多数优化工作往往是对系统配置的优化，只有少部分的优化工作是对系统设计的修改。

　　通过对结果的分析，可以大体定位出系统问题出现在哪里，随后对系统配置进行更改及优化。此优化过程大部分的工作是尝试性和不间断性的，需要不断尝试配置参数的改变，然后验证此配置的修改是否达到预期目的。如果没有达到预期目的，需要进一步对配置进行修改和验证。根据以往的测试经验，实现参数配置更改的最重要规则是一次仅实现一个配置更改。这主要是由于系统某一个模块/单元出现问题可能是由多个模块/单元的瓶颈导致的。因此，分别处理每个问题很重要。如果同时进行多个更改，将不可能准确地评定每次更改的影响。

　　实现了配置更改后，必须对修改后的系统进行测试，确定更改对系统所产生的影响。如果幸运，性能提高到预期的水平，这时便可以退出。如果不是这样，则必须重新逐步进行调整循环。

　　综合考虑以上的内容，一个调整循环的流程才算基本完成，根据调整的结果来考虑是否进入下一部调整循环的阶段。

与并发用户数相关的概念还包括“并发用户数”、“系统用户数”和“同时在线用户数”，下面用一个实际的例子来说明它们之间的差别。

        假设有一个OA系统，该系统有2000个使用用户——这就是说，可能使用该OA系统的用户总数是2000名，这个概念就是“系统用户数”，该系统有一个“在线统计”功能（系统用一个全局变量记数所有已登录的用户），从在线统计功能中可以得到，最高峰时有500人在线（这个500就是一般所说的“同时在线人数”），那么，系统的并发用户数是多少呢？

        根据我们对业务并发用户数的定义，这500就是整个系统使用时最大的业务并发用户数。当然，500这个数值只是表明在最高峰时刻有500个用户登录了系统，并不表示实际服务器承受的压力。因为服务器承受的压力还与具体的用户访问模式相关。例如，在这500个“同时使用系统”的用户中，考察某一个时间点，在这个时间上，假设其中40%的用户在较有兴致地看系统公告（注意：“看”这个动作是不会对服务端产生任何负担的），20%的用户在填写复杂的表格（对用户填写的表格来说，只有在“提交”的时刻才会向服务端发送请求，填写过程是不对服务端构成压力的），20%部分用户在发呆（也就是什么也没有做），剩下的20%用户在不停地从一个页面跳转到另一个页面——在这种场景下，可以说，只有20%的用户真正对服务器构成了压力。因此，从上面的例子中可以看出，服务器实际承受的压力不只取决于业务并发用户数，还取决于用户的业务场景。

       在实际的性能测试工作中，测试人员一般比较关心的是业务并发用户数，也就是从业务角度关注究竟应该设置多少个并发数比较合理，因此，在后面的讨论中，也是主要针对业务并发用户数进行讨论，而且，为了方便，直接将业务并发用户数称为并发用户数。

        （1） 计算平均的并发用户数： C = nL/T     

        （2） 并发用户数峰值： C’ ≈ C+3根号C

         公式（1）中，C是平均的并发用户数；n是login session的数量；L是login session的平均长度；T指考察的时间段长度。

        公式（2）则给出了并发用户数峰值的计算方式中，其中，C’指并发用户数的峰值，C就是公式（1）中得到的平均的并发用户数。该公式的得出是假设用户的login session产生符合泊松分布而估算得到的。

实例：

        假设有一个OA系统，该系统有3000个用户，平均每天大约有400个用户要访问该系统，对一个典型用户来说，一天之内用户从登录到退出该系统的平均时间为4小时，在一天的时间内，用户只在8小时内使用该系统。

则根据公式（1）和公式（2），可以得到：

               C = 400*4/8 = 200

               C’≈200+3*根号200 = 242

 F=VU * R / T
| v K6^mSa:H197087  其中F为吞吐量，VU表示虚拟用户个数，R表示每个虚拟用户发出的请求数，T表示性能测试所用的时间
S|9BBia"y197087  R = T / TS
]3?&Q z_
TF
A197087  TS为用户思考时间
w8Op~hG'W197087  计算思考时间的一般步骤：51Testing软件测试网.F} |e3I
  A、 首先计算出系统的并发用户数
2wu'S+s$la197087  C=nL / T      F=R×C
'Xd'xu0YVX8ft9zm197087  B、 统计出系统平均的吞吐量51Testing软件测试网*j-~2R4Y t@
  F=VU * R / T  R×C = VU * R / T51Testing软件测试网9N#B6].kAr1f
  C、 统计出平均每个用户发出的请求数量51Testing软件测试网B'G)t9`#m1n d
  R=u*C*T/VU51Testing软件测试网 @ M8Ey4cB4Ob
  D、根据公式计算出思考时间51Testing软件测试网%n~)e&m.N"Z]e0R
  TS=T/R51Testing软件测试网?I/He&fD
51Testing软件测试网.Dd#?4@#X:N-J,r
51Testing软件测试网p+U
J&xQ.~ e%e)HL%C
  缺陷检测有效性百分比DDE=TDFT/(TDFC+TDFT)×100%51Testing软件测试网 d6Q M9y7p'`*x jPV+e
  其中:TDFT=测试过程中发现的全部缺陷(即由测试组发现的),TDFC=客户发现的全部缺陷(在版本交付后一个标准点开始测量,如,半年以后)
7t,K`1m
G8T/}1E197087
E*\\7[rC1nkY197087  缺陷排除有效性百分比DRE=(TDCT/TDFT)×100%51Testing软件测试网q{,o dT7L} a%Mt
  其中:TDCT=测试中改正的全部缺陷,TDFT=测试过程中发现的全部缺陷51Testing软件测试网fv|e7@"A(r V0x
51Testing软件测试网x3v Rib*E
  测试用例设计效率百分比TDE=(TDFT/NTC)×100%
1X^#B[1z$q!G(rZ'W"X4{F T197087  其中:TDFT=测试过程中发现的全部缺陷,NTC=运行的测试用例数51Testing软件测试网 q)k/L \3X'Nh1|@

ETb`e]6vu197087以下公式较适用于白盒测试51Testing软件测试网-O2]VNux
  功能覆盖率= 至少被执行一次的测试功能点数/ 测试功能点总数 （功能点）
-foO `
u'i197087  需求覆盖率= 被验证到的需求数量 /总的需求数量 （需求）
5M? {3x*SCB197087  覆盖率= 至少被执行一次的测试用例数/ 应执行的测试用例总数 （测试用例）51Testing软件测试网p2`![q0[h2Q!Au8n/o1Z%g
  语句覆盖率= 至少被执行一次的语句数量/ 有效的程序代码行数
/U4s'j X(r197087  判定覆盖率= 判定结果被评价的次数 / 判定结果总数
Q Uu(~wZ's N197087  条件覆盖率=  条件操作数值至少被评价一次的数量 / 条件操作数值的总数51Testing软件测试网o
Bfe9C!CMk5O
  判定条件覆盖率= 条件操作数值或判定结果至少被评价一次的数量/(条件操作数值总数+判定结果总数)
\~~6@u w197087  上下文判定覆盖率= 上下文内已执行的判定分支数和/(上下文数*上下文内的判定分支总数)51Testing软件测试网
x} Q \5x }{
  基于状态的上下文入口覆盖率= 累加每个状态内执行到的方法数/(状态数*类内方法总数)51Testing软件测试网nq2Bz(w5}:[
  分支条件组合覆盖率= 被评测到的分支条件组合数/分支条件组合数51Testing软件测试网p,?1|su@%C
  路径覆盖率=  至少被执行一次的路径数/程序总路径数

　　性能测试（并发负载压力）测试分析－简要篇

　　在论坛混了多日，发现越来越多的性能测试工程师基本上都能够掌握利用测试工具来作负载压力测试，但多数人对怎样去分析工具收集到的测试结果感到无从下手，下面我就把个人工作中的体会和收集到的有关资料整理出来，希望能对大家分析测试结果有所帮助。

　　分析原则：

　　?? 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）

　　?? 查找瓶颈时按以下顺序，由易到难。

　　服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）

　　注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。

　　?? 分段排除法 很有效

　　分析的信息来源：

　　??1 根据场景运行过程中的错误提示信息

　　??2 根据测试结果收集到的监控指标数据

　　一．错误提示分析

　　分析实例：

　　1 ??Error: Failed to connect to server “10.10.10.30:8080″: [10060] Connection

　　??Error: timed out Error: Server “10.10.10.30″ has shut down the connection prematurely

　　分析：

　　??A、应用服务死掉。

　　（小用户时：程序上的问题。程序上处理数据库的问题）

　　??B、应用服务没有死

　　（应用服务参数设置问题）

　　例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的 AcceptBacklog属性值设得过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25％

　　??C、数据库的连接

　　(1、在应用服务的性能参数可能太小了 2、数据库启动的最大连接数（跟硬件的内存有关）)

　　2 Error: Page download timeout (120 seconds) has expired

　　分析：可能是以下原因造成

　　??A、应用服务参数设置太大导致服务器的瓶颈

　　??B、页面中图片太多

　　??C、在程序处理表的时候检查字段太大多

　　二．监控指标数据分析

　　1．最大并发用户数：

　　应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。

　　在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。

　　如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。

　　2．业务操作响应时间：

　　?? 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。

　　?? 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？

　　?? 如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题

　　3．服务器资源监控指标：

　　内存：

　　1 UNIX资源监控中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。

　　2 Windows资源监控中，如果Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高，同时Memory\Available bytes计数器的值持续降低，则很可能存在内存泄漏。

　　内存资源成为系统性能的瓶颈的征兆:

　　很高的换页率(high pageout rate);

　　进程进入不活动状态;

　　交换区所有磁盘的活动次数可高;

　　可高的全局系统CPU利用率;

　　内存不够出错(out of memory errors)

　　处理器：

　　1 UNIX资源监控（Windows操作系统同理）中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server,可接受的最大上限是80-85%

　　合理使用的范围在60%至70%。

　　2 Windows资源监控中，如果System\Processor Queue Length大于2，而处理器利用率（Processor Time）一直很低，则存在着处理器阻塞。

　　CPU资源成为系统性能的瓶颈的征兆:

　　很慢的响应时间(slow response time)

　　CPU空闲时间为零(zero percent idle CPU)

　　过高的用户占用CPU时间(high percent user CPU)

　　过高的系统占用CPU时间(high percent system CPU)

　　长时间的有很长的运行进程队列(large run queue size sustained over time)

　　磁盘I/O：

　　1 UNIX资源监控（Windows操作系统同理）中指标磁盘交换率（Disk rate），如果该参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。

　　2 Windows资源监控中，如果 Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。

　　I/O资源成为系统性能的瓶颈的征兆 :

　　过高的磁盘利用率(high disk utilization)

　　太长的磁盘等待队列(large disk queue length)

　　等待磁盘I/O的时间所占的百分率太高(large percentage of time waiting for disk I/O)

　　太高的物理I/O速率:large physical I/O rate(not sufficient in itself)

　　过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself))

　　太长的运行进程队列，但CPU却空闲(large run queue with idle CPU)

　　4．数据库服务器：

　　SQL Server数据库：

　　1 SQLServer资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80%，应考虑增加内存。

　　2 如果Full Scans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。

　　3 Number of Deadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该计数器的值必须为0。

　　4 Lock Requests/sec(锁请求/秒)，通过优化查询来减少读取次数，可以减少该计数器的值。

　　Oracle数据库：

　　1 如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90，那么需要增加SHARED_POOL_SIZE的大小。

　　快存（共享SQL区）和数据字典快存的命中率：

　　select(sum(pins-reloads))/sum(pins) from v$librarycache;

　　select(sum(gets-getmisses))/sum(gets) from v$rowcache;

　　自由内存： select * from v$sgastat where name=’free memory’;

　　2 如果数据的缓存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS参数的值（单位：块）。

　　缓冲区高速缓存命中率：

　　select name,value from v$sysstat where name in (’db block gets’,

　　‘consistent gets’,'physical reads’) ;

　　Hit Ratio = 1-(physical reads / ( db block gets consistent gets))

　　3 如果日志缓冲区申请的值较大，则应加大LOG_BUFFER参数的值。

　　日志缓冲区的申请情况 ：

　　select name,value from v$sysstat where name = ‘redo log space requests’ ;

　　4 如果内存排序命中率小于0.95，则应加大SORT_AREA_SIZE以避免磁盘排序 。

　　内存排序命中率 ：

　　select round((100*b.value)/decode((a.value b.value), 0, 1, (a.value b.value)), 2)from v$sysstat a, v$sysstat b where a.name=’sorts (disk)’ and b.name=’sorts (memory)’

　　注：上述SQL Server和Oracle数据库分析，只是一些简单、基本的分析，特别是Oracle数据库的分析和优化，是一门专门的技术，进一步的分析可查相关资料。

 负面测试（Negative testing）是相对于正面测试（Positive testing）而言的。它们也是测试设计时的两个非常重要的划分。简单点说，正面测试就是测试系统是否完成了它应该完成的工作；而负面测试就是测试系统是否不执行它不应该完成的操作。形象一点，正面测试就象一个毕恭毕敬的小学生，老师叫我做什么，我就做什么；而负面测试就象一个调皮捣蛋的孩子，你叫我这样做，我偏不这样做，而且和你对着干。开发人员也是最讨厌修改此类bug的。
        正面测试主要根据需求，功能说明书，设计文档等相关参考文档来执行测试，而负面测试则主要根据错误猜测，逆向思维来测试系统，一定程序上的的依赖测试人员的经验积累。
        执行负面测试时，不单单要测试系统是否处理了用户的异常操作，还要检查系统对于这些异常操作是否给予了正确的错误提示。它是系统对用户进行继续正确操作的指引。
        简言之负面测试的三部曲就是：
1． 检查程序中的屏幕或页面是否给出了清晰且充分的提示或约束；
2． 测试系统是否处理了用户的异常操作；
3． 检查系统的错误提示是否清晰且充分。
 
        以下是Steve Miller的《Top 10 Negative Test Cases》，概括性的提到了一些做负面测试时经常需要注意的测试。
 
        负面测试用例被设计于用软件未意欲被使用的方式测试软件，它也应该是测试工作的一部分。以下就是在设计测试工作量时你应该考虑的10大负面测试用例。
        1.植入的单引号。大多数基于SQL的数据库系统在用户存储包含一个单引号的信息时会出现问题，例如John's car。每一个可以接受文字数字型数据条目的屏幕都要试试输入包含一个或多个单引号的文本。
        【Kiki补充】其实不只是单引号，基本上测试人员应该测试所有的特殊字符和空/空格（单纯的空格和文本前后的空格）。单引号，逗号，/，<，>（对于web的应用程序）都是很容易引发错误的。在开发早期测试组就可以建议开发组写一个通用的函数来处理这些特殊字符，然后在处理用户的输入时套用这个函数就可以避免此类错误了。
 
        2.必需输入的数据条目。功能说明书上应该清楚的指出屏幕上必须输入数据条目的字段。测试屏幕上每一个被说明为必须输入的字段以保证它强制要求你在字段中输入数据。
        【Kiki补充】对于强制输入的字段，在屏幕上最好有些标识以说明其为必须输入的字段。一般在字段前或后用红色的*号表示。测试时必须要检查有标识的字段是否和功能说明书或其他参考文档一致，错误信息提示是否正确，强制输入的字段是否真的必须输入。
 
        3.字段类型测试。功能说明书上应该清楚的指出要求特定数据输入要求（日期字段，数字字段，电话号码，邮编等等）的字段。测试屏幕上每一个被指出有特定类型的字段以保证你输入了基于字段类型的符合正确格式的数据（数字型字段应该不允许字符或特殊字符，日期型的字段应该允许输入一个正确的日期等等）
        【Kiki补充】其实这里还有一个字段格式和字段内容的测试。有些字段对输入的格式有要求，这些字段的格式一般在屏幕上也有相应的提示。所以在测试时需要测试提示的格式是否合理（和功能说明书或其他参考文档相一致）以及系统是否正确识别输入的格式。有些字段对字段的内容有限制，如常见的用户名，不能包含特殊字符，首字不能未数字等要求。所以在测试时需要测试提示的格式是否合理（和功能说明书或其他参考文档相一致）还有不符合内容要求的数据输入时系统是否正确的处理。
 
        4.字段长度测试。功能说明书上应该清楚的指出可以在字段中输入的字符数（例如，first name必须是50个或更少的字符）。写测试用例以保证你只可以输入特定的字符数。防止用户输入比允许范围更多的字符比因用户已输入过多的字符而给出的错误信息更加的文雅些。
        【Kiki补充】一般对于限制长度的字段，现在开发大多采用限制输入的方法（设置字段的长度）来处理。所以测试时需要测试限制的长度是否合理（和功能说明书或其他参考文档相一致），对于没有限制长度的字段，要测试无穷输入时是否出错，有问题报bug时建议开发人员根据需要限制长度。
 
        5.数字型的边界测试。对于数字型的字段，测试上下边界是非常重要的。例如，如果你正在计算某个账户的利息时，你永远不会输入一个负的利息数给应该赢取利息的账户。因此，你应该尝试用负数测试。同样，如果功能说明书上要求字段在某一个特定的范围（如从10～50），你就应该尝试输入9或51，它应该给出一个得体的信息表示失败。
 
        6.数字的约束测试。大多数数据库系统和编程语言允许数字条目被识别为整数或长整数。通常，整数的范围是从-32,767~32,767，长整数的范围从-2,147,483,648~2,147,483,647。对于那些没有特定边界限制的数字数据条目，用这些限制测试以确保不会出现数字的溢出错误。
        【Kiki补充】小数型的数字字段同样也需要格外的测试。一般对于未指出数字类型的字段，尝试输入负整数，负小数，0，正整数，正小数进行测试。
        不管是哪种数据库系统，对于数字一般都有多种数字类型。所以测试人员一定要测试的全面。
 
        7.日期边界测试。对于日期型的字段，测试上下边界是很重要的。例如，如果你正在检查一个出生日期的字段，很大可能出生日期不能早于150年前。同样，出生日期应该不是将来的某一天。
        【Kiki补充】一般来说，每种数据库系统的日期都有个范围，如SQL Server最小日期是1753年1月1日，所以如果是输入型的日期字段同样也应该测试早于1753的日期。
 
        8。日期的有效性。对于日期字段，确保不允许无效的日期是很重要的（04/31/2007是一个无效的日期）。测试用例也应该检查闰年（每个第4年和第400年是一个闰年）。
 
        9。web会话测试。很多的web应用程序依赖浏览器的会话来追踪已登录的用户，应用程序的设置等等。应用程序的大多数屏幕不被设计为没有首次登录就可以被运行。应用程序应该确保在打开应用程序的某一页面之前会话里有一个有效的登录。
 
        10.性能的改变。当发布产品的最新版本时，应该有一套运行于识别屏幕（列出信息的屏幕，add/update/delete数据的屏幕等等）速度的性能测试。测试包里应该包括比较先前版本和现有版本性能统计值的测试用例。这个可以帮助识别那些可以证明是随着对现有版本的代码变更而引起的潜在的性能问题。
 
        【Kiki补充】从第一条到第八条是我们在测试字段时常常需要做的测试，一般的测试人员都不陌生。第九条在测试web应用程序中会作为检查应用程序的安全性而做的一项测试。而第十条估计很多公司都不会将它考虑到测试的范畴中，一般最多也就是在测试用例中添加校验某一个操作是否在系统允许的响应时间里，很少去做这样的比较，除了一些有针对性的性能测试。

一、功能测试
1、对话框测试输入进行测试。包括中文字符、英文字符、数字字符、特殊字符、及几种字符的组合。
2、对界面可操作按钮进行测试。包括【新增(N)】【保存(S)】【修改(M)】【查询(A)】【打印(P)】【退出(X)】。
同时需要对鼠标右键的菜单进行测试。
3、数据保存测试。将1 和2 进行组合。
4、必要条件控制测试。在做了3 时将必要条件(如：a、编号、姓名不可为空b、编号、姓名不可重复)控制测试
联合起来。
GUI测试
1.窗体是否能够基于相关的输入或菜单命令适当的打开
2.窗体是否能够改变大小、移动和滚动
3.窗体的数据是否能够利用鼠标、功能键、方向箭头和键盘操作
4.当窗体被覆盖并重新调用后，窗体是否能够正确再生
5.窗体相关的功能是否可以操作
6.是否显示相关的下拉菜单、工具条、滚动条、对话框、按钮、图标和其他控制，既能正确显示又能调用
7.显示多窗体时，窗体名称是否能够正确表示
8.活动窗体是否能够被反显加亮
9.多用户联机时所有窗体是否能够实时更新
10.鼠标无规则点击时是否会产生无法预料的结果
11.窗体声音及提示是否符合既定编程规则
12.窗体是否能够被关闭
13.窗体控件的大小、对齐方向、颜色、背景等属性的设置值是否和程序设计规约相一致
14.窗体控件布局是否合理、美观
15.窗体控件 TAB 顺序是否从左到右，从上到下
16.窗体焦点是否按照编程规范落在既定的控件上
17.窗体画面文字（全、半角、格式、拼写）是否正确
18.鼠标有多个形状时是否能够被窗体识别（如漏斗状时窗体不接受输入）

功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。
常用的测试方法如下：
1.页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。
2.相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。
3.检查按钮的功能是否正确：如update, cancel, delete, save 等功能是否正确。
4.字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错.
5.字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其
他字符类型),看系统是否检查字符类型,会否报错.
6.标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确.
7.中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错.
8.检查带出信息的完整性: 在查看信息和update 信息时,查看所填写的信息是不是全部带出.,带出信息和添加的
是否一致
9.信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名
包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.
10.检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按”delete”,看系统如何处理,会否
出错;然后选择一个和多个信息,进行删除,看是否正确处理.
11.检查添加和修改是否一致: 检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;
添加规定为整型的项,修改也必须为整型.
12.检查修改重名:修改时把不能重名的项改为已存在的内容,看会否处理,报错.同时,也要注意,会不会报和
自己重名的错.
13.重复提交表单：一条已经成功提交的纪录，back 后再提交，看看系统是否做了处理。
14.检查多次使用back 键的情况: 在有back 的地方,back,回到原来页面,再back,重复多次,看会否出错.
15.search 检查: 在有search 功能的地方输入系统存在和不存在的内容,看search 结果是否正确.
如果可以输入多个search 条件,可以同时添加合理和不合理的条件,看系统处理是否正确.
16.输入信息位置: 注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方.
17.上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，
系统是否有解释信息，并检查系统是否能够做到。
18.必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加*
19.快捷键检查：是否支持常用快捷键，如Ctrl+C Ctrl+V Backspace 等，对一些不允许输入信息的字段，
如选人，选日期对快捷方式是否也做了限制。
20.回车键检查: 在输入结束后直接按回车键,看系统处理如何,会否报错
21.完成相同或相近功能的菜单用横线隔开放在同一位置
22.菜单深度一般要求最多控制在三层以内。
通用测试用例补充
B1 焦点转移问题         使用Tab 键测试焦点转移
B2                     当保存时如果提示“有未输入的必填”项回到页面后，
                       焦点应转移到未输入的必填项中最靠前的一项上
B3
B4
B5 数字格式             如果对数字格式有限制则看是否符合限制
B6                     格式没有限制时，所有输入数据的小数点位数应该一致
B7

B8 输入文本框类型控件的测试    空值测试
B9                      空格测试;前面输入空格，中间输入空格,末尾输入空格和全部输入空格，
                       程序是否进行处理，保存成功后，数据库中的数据是否与页面显示的一致
B10                    长度测试(最大字符)
B11                    类型测试(如果有类型要求)
B12                    特殊字符的测试
B13
B14 关于文本框录入为数字
    时的测试             对数字长度有没有限制，输入1 位数，2 位数，等等有没有提示信息
B15
B16 关于文本框录入数字型
    小数点的测试          录入整数加小数点、小数点加整数和单独的小数点，保存时系统是否有提示，
                        是否成功
B17
B18 关于文本框填写不符合   比如在文本框中录入不符合条件的数据（类型不符合或者超多等），
    条件的信息保存确认后   保存确定后只要清空错误的数据即可
    清空与否的测试       

B19
B20 文本框内容的合理性     如果是输入正数的文本框。（如：职工人数）还要判断是否为负数。
B21
B22 大小写问题            要求数据唯一性时是否区分大小写
B23
B24 下拉列表的检测         检查列表中的内容是否漏选，重选；如果列表中的数据要求从其他页面或者
                         数据库中获得的，就要检查是否与该页面中有数据一致。
B25
B26 时间                  注意要修改系统时间到2004-01-02/2004-11-12
B27                       起始时间不可大于终止时间
B28                       检查日期为空时程序的反应。
B29                       数据库中的日期是否能够正确显示在页面上
B30                       输入错误日期时程序的反应。
B31                       如果有输入日期不得大于当前日期的限制，则是否通过
B32                       如果有输入日期不得小于当前日期的限制，则是否通过
B33
B34 边界值                 输入条件规定了值的范围
B35                       应取刚达到这个范围的边界的值作为测试输入数据
B36                       以及刚刚超越这个范围边界的值作为测试输入数据
B37                       输入条件规定了值的个数
B38                       最大个数
B39                       最小个数
B40                       比最小个数少一
B41                       比最大个数多一
B42
B43 保存操作的测试          保存成功/失败后检查数据库
B44                       检查必录项

B45                       保存成功/失败是否有相应的提示信息
B46
B47 删除操作的测试          删除提示成功/失败后看查看数据库
B48                       删除时是否有确认对话框
B49                       删除成功/失败是否有提示信息
B50                       确定是逻辑删除还是物理删除;物理删除是否已经把数据库中的数据删除掉，
                          逻辑删除是否改变了标志位。                        
B51
B52
B53 修改操作的测试          修改提示成功后看数据库中的记录是否已经修改
B54
B55 查询操作的测试          查询到的记录是否与数据库中的记录相符
B56                       检查组合查询时,查询结果是否正确
B57                       查询列表下如果可以查询纪录的详细信息，检测查询条件是否改变
B58                       查询条件中有日期这一项的查看是否有默认值及其值是否符合要求
B59
B60 分页显示的测试          检查是否能够正常分页显示
B61                       检查是否能够正常前进或后退
B62                       检查是否能够正确选择一页的显示记录数
B63                       检查是否能够正确选择显示第x 页
B64
B65 必录项的测试            检查必录项是否提示必须输入
B66
B67 工作流程的测试          每个模块的工作流程是否可以正常运行
B68                       每个模块的工作流程过程是否与详细设计要求的一致
B69                       不按正常的工作流程操作是否可以正常运行
B70
B71 系统自动生成项的测试     应该自动生成数据的地方是否自动生成了数据
B72                       系统自动生成的数据是否符合详细设计的要求
B73                       自动生成数据的该条信息是否可以正常使用
B74                       自动生成数据后系统是否可以正常运行
B75
B76重复某项操作的测试(包     某项操作重复进行时是否正确运行
   括按钮、某个流程)
B77                       某项操作重复进行后再进行其他操作是否正确
B78                       某项操作重复进行后再进行其他操作系统是否正常运行
B79
B80 权限的问题             检查具有不同权限的用户登录时，是否具有跟其权限相符合的操作;

                          检查不权限的用户是否具有相应的权限
B81
B82 链接测试               将鼠标按到链接上然后移动一下再放开鼠标页面是否会出错。
B83                       当链接打开一个新页面时检查页面初始化状态是否有异常情况。
B84
B85 关于统一性的测试         页面对于同样的成功或者失败的提示信息是否统一（包括标点符号的统一）

B86
B87 关于计算方面的测试        查看计算结果是否正确，进行增删改操作后其值是否进行相应正确改变
B88
B89 唯一性测试               要求数据唯一并且是逻辑删除时，是否允许与已删除的记录重复
B90                        要求唯一性的数据，在两人（或两人以上）同时操作时是否能正确地执行
B91
B92窗口最大化、最小化、
   关闭、确定按钮、取消
   按钮的测试
B93
B94 打印测试                 打印按钮是否可用
B95                         在打印窗口中设置打印参数
B96                         打印设置是否方便用户使用
B97                         打印出来的是否与设置的打印参数一致
B98                         打印的内容是否正确
B99                         打印结束后是否能正常运行
B100
B101 提示信息的测试           检验应该有提示信息的是否有提示信息
B102                        相应提示信息的内容表达是否正确
B103                        提示信息的内容用户是否接受
B104                        确认后是否可以正常运行
B105
B106 用户登陆测试             用户权限测试
B107                         录入不存在的用户名和密码有提示信息
B108                         录入用户名不录入密码有提示信息
B109                         录入密码不录入用户名有提示信息
B110                         录入正确的用户名和密码进入相应的系统页面
B111                         重置按钮的测试