在软件系统日益复杂的今天，性能已经成为软件质量的重要衡量标准之一，这一点尤其体现在和WEB相关的系统上。接下来介绍一些WEB性能测试中的术语，这些术语都是WEB性能测试中出现频繁的比较高的词汇，只有掌握这些基础的性能知识才可以进一步开展测试工作。这些术语主要有并发用户，并发用户数量，请求响应时间，事务响应时间，吞吐量，吞吐率，TPS，点击率，资源利用率等。

并发用户：并发一般分为2种情况。一种是严格意义上的并发，即所有的用户在同一时刻做同一件事情或者操作，这种操作一般指做同一类型的业务。比如在信用卡审批业务中，一定数目的拥护在同一时刻对已经完成的审批业务进行提交；还有一种特例，即所有用户进行完全一样的操作，例如在信用卡审批业务中，所有的用户可以一起申请业务，或者修改同一条记录。

另外一种并发是广义范围的并发。这种并发与前一种并发的区别是，尽管多个用户对系统发出了请求或者进行了操作，但是这些请求或者操作可以是相同的，也可以是不同的。对整个系统而言，仍然是有很多用户同时对系统进行操作，因此也属于并发的范畴。

可以看出，后一种并发是包含前一种并发的。而且后一种并发更接近用户的实际使用情况，因此对于大多数的系统，只有数量很少的用户进行“严格意义上的并发”。对于WEB性能测试而言，这2种并发情况一般都需要进行测试，通常做法是先进行严格意义上的并发测试。严格意义上的用户并发一般发生在使用比较频繁的模块中，尽管发生的概率不是很大，但是一旦发生性能问题，后果很可能是致命的。严格意义上的并发测试往往和功能测试关联起来，因为并发功能遇到异常通常都是程序问题，这种测试也是健壮性和稳定性测试的一部分。

用户并发数量：关于用户并发的数量，有2种常见的错误观点。一种错误观点是把并发用户数量理解为使用系统的全部用户的数量，理由是这些用户可能同时使用系统；还有一种比较接近正确的观点是把在线用户数量理解为并发用户数量。实际上在线用户也不一定会和其他用户发生并发，例如正在浏览网页的用户，对服务器没有任何影响，但是，在线用户数量是计算并发用户数量的主要依据之一。

请求响应时间：指的是客户端发出请求到得到响应的整个过程的时间。在某些工具中，请求响应时间通常会被成为"TLLB"，即"Time to last byte",意思是从发起一个请求开始，到客户端接收到最后一个字节的响应时间所耗费的时间。请求响应时间过程的单位一般为"秒"或者"毫秒".

事务响应时间:事务可能由一系列请求组成,事务的响应时间主要是针对用户而言,属于宏观上的概念，是为了向用户说明业务响应时间而提出的.例如:跨行取款事务的响应时间就是由一系列的请求组成的.事务响应时间和后面的业务吞吐率都是直接衡量系统性能的参数.

吞吐量:指的是在一次性能测试过程中网络上传输的数据量的总和.吞吐量/传输时间,就是吞吐率.

TPS:每秒钟系统能够处理的交易或者事务的数量.它是衡量系统处理能力的重要指标.

点击率:每秒钟用户向WEB服务器提交的HTTP请求数.这个指标是WEB应用特有的一个指标:WEB应用是"请求-响应"模式,用户发出一次申请,服务器就要处理一次,所以点击是WEB应用能够处理的交易的最小单位.如果把每次点击定义为一个交易,点击率和TPS就是一个概念.容易看出,点击率越大,对服务器的压力越大.点击率只是一个性能参考指标,重要的是分析点击时产生的影响。需要注意的是,这里的点击并非指鼠标的一次单击操作,因为在一次单击操作中,客户端可能向服务器发出多个HTTP请求.

资源利用率:指的是对不同的系统资源的使用程度,例如服务器的CPU利用率，磁盘利用率等.资源利用率是分析系统性能指标进而改善性能的主要依据,因此是WEB性能测试工作的重点。

资源利用率主要针对WEB服务器,操作系统,数据库服务器,网络等,是测试和分析瓶颈的主要参考。在WEB性能测试中,更根据需要采集相应的参数进行分析。

一、WEB 全面性能测试模型
 Web 性能测试模型提出的主要依据是：一种类型的性能测试可以在某些条件下转化成为另外一种类型的性能测试，这些类型的性能测试的实施是有着相似之处的；

1.       预期指标的性能测试：
系统在需求分析和设计阶段都会提出一些性能指标，完成这些指标的相关的测试是性能测试的首要工作之一，这些指标主要诸于“系统可以支持并发用户200个；”系统响应时间不得超过20秒等，对这种预先承诺的性能要求，需要首先进行测试验证； 

2.       独立业务性能测试；
     独立业务实际是指一些核心业务模块对应的业务，这些模块通常具有功能比较复杂，使用比较频繁，属于核心业务等特点。

用户并发测试是核心业务模块的重点测试内容，并发的主要内容是指模拟一定数量的用户同时使用某一核心的相同或者不同的功能，并且持续一段时间。对相同的功能进行并发测试分为两种类型，一类是在同一时刻进行完全一样的操作。另外一类是在同一时刻使用完全一样的功能。

3.       组合业务性能测试；
通常不会所有的用户只使用一个或者几个核心业务模块，一个应用系统的每个功能模块都可能被使用到；所以WEB性能测试既要模拟多用户的相同操作，又要模拟多用户的不同操作；组合业务性能测试是最接近用户实际使用情况的测试，也是性能测试的核心内容。通常按照用户的实际使用人数比例来模拟各个模版的组合并发情况；组合性能测试是最能反映用户使用情况的测试往往和服务器性能测试结合起来，在通过工具模拟用户操作的同时，还通过测试工具的监控功能采集服务器的计数器信息进而全面分析系统瓶颈。

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

4.       疲劳强度性能测试；
疲劳强度测试是指在系统稳定运行的情况下，以一定的负载压力来长时间运行系统的测试，其主要目的是确定系统长时间处理较大业务量时的性能，通过疲劳强度测试基本可以判定系统运行一段时间后是否稳定；

5.       大数据量性能测试；
一种是针对某些系统存储，传输，统计查询等业务进行大数据量时的性能测试，主要针对某些特殊的核心业务或者日常比较常用的组合业务的测试；

第二种是极限状态下的数据测试，主要是指系统数据量达到一定程度时，通过性能测试来评估系统的响应情况，测试的对象也是某些核心业务或者常用的组合业务。

第三种大数据量测试结合了前面两种的测试，两种测试同时运行产生较大数据量的系统性能测试；

大数据量测试通常在投产环境下进行，并独立出来和疲劳强度测试放在一起，在整个性能测试的后期进行；大数据量的测试可以理解为特定条件下的核心业务或者组合业务测试；

6.       网络性能测试；
     主要是为了准确展示带宽，延迟，负载和端口的变化是如何影响用户的响应时间的，在实际的软件项目中

主要是测试应用系统的用户数目与网络带宽的关系。网络测试的任务通常由系统集成人员完成；

7.       服务器（操作系统，WEB服务器，数据库服务器）性能测试；
初级服务器性能测试主要是指在业务系统工作或者进行前面其他种类性能测试的时候，监控服务器的一些计数器信息，通过这些计数器对服务器进行综合性能分析，为调优或提高系统性能提供依据；

高级服务器性能测试一般由专门的系统管理员来进行如数据库服务器由专门的DBA来进行测试和调优；

8.       一些特殊的测试；
  主要是指配置测试，内存泄露测试的一些特殊的WEB性能测试；

二、WEB 性能测试策略
性能测试策略一般从需求设计阶段开始讨论如何定制，它决定着性能测试工作要投入多少资源，什么时间开始实施等后续工作的安排；其制定的主要依据是软件自身的特点和用户对性能的关注程度，其中软件自身的特点起决定性的作用；

软件按照用途的不同可以分为两大类，系统类软件和应用类软件。系统类软件通常对性能要求较高，因此性能测试应该尽早介入；应用类软件分为特殊类应用和一般类应用，特殊类应用主要有银行，电信，电力，保险，医疗，安全等领域软件，这类软件使用频繁，用户较多，也需要较早进行性能测试；一般类主要是指一些普通类应用如OA，MIS 等一般类软件根据实际情况制定性能测试策略，受用户因素影响较大；

1.       系统类软件；
 从设计阶段就开始针对系统架构，数据库设计等方面进行讨论，从根源来提高性能，系统类软件一般从单元测试阶段开始性能测试实施工作，主要是测试一些和性能相关的算法和模块；

2.       应用类软件；
特殊应用：从设计阶段就开始针对系统架构，数据库设计等方面进行讨论，从根源来提高性能，系统类软件一般从单元测试阶段开始性能测试实施工作，主要是测试一些和性能相关的算法和模块；

一般应用：与使用用户的重视程度有关，用户高度重视时 ，设计阶段开始进行一些讨论工作，主要在系统测试阶段开始进行性能测试实施；用户一般重视时，可以在系统测试阶段的功能测试结束后进行性能测试；用户不怎么重视时，可以在软件发布前进行性能测试，提交测试报告即可；

三、WEB性能测试用例设计模型
性能测试用例设计通常不会一次设计到位，是一个不断迭代完善的过程，即使在使用过程中，也不是完全按照设计好的测试用例来执行，需要根据需求的变化进行调整和修改； WEB性能测试用例设计模型是一个内容全面比较容易组织和调整的模型架构。

3.       预期性能指标测试用例；
指一些十分明确的，在系统需求设计阶段预先提出的，期望系统达到的，或者向用户保证的性能指标，针对每个指标都要编写一个或者多个测试用例来验证系统是否达到要求，预期性能指标测试用例主要参考需求和设计文档，把里面十分明确的性能要求提取出来，指标中通常以单用户为主；

如：对于普通的客户端，系统上传5MB以内的文件，速度不低于2MB/S；

输入动作：选择1-5 MB的文件并上传，用秒表计时；

期望的性能：上传的时间小于等于2.5S

实际性能: 上传的时间2.29秒;

这类用例通常以手工的方式执行;

4.       用户并发性能测试用例；
     用户并发测试主要通过逐渐增加用户数量来加重系统负担,并通过测试工具对应用系统,各种服务器资源进

监控,用户并发测试可以是正常数量用户和特殊数量用户进行并发, 用户并发测试是系统性能测试的核心部分,涉及压力测试,负载测试,强度测试等多方面的内容.独立业务性能测试实际就是核心业务模块的某一业务的并发性能测试,可以理解为单元性能测试;组合业务的性能测试是一个或者多个模块的多个业务同时进行并发性能测试,可以理解为集成性能测试,单元性能测试和集成性能测试两者紧密相连合并称为用户并发性能测试;用户并发测试要求选择有代表性的关键的业务来设计测试用例,以便更有效的评测系统性能;其测试用例设计文档的基本的编写思想是按照系统的体系结构进行编写.

1.       独立核心模块用户并发性能的测试用例设计

 完全一样功能的并发测试:主要检查系统的健壮性,从技术角度讲就是检查程序对同一时刻并发操作的处理.

 完全一样操作的并发测试:基本要求是在同一时刻进行完全一样的操作,这类测试的目的是验证核心模块在

大量用户使用同一功能时是否正常工作;

相同/不同功能的子功能并发:每个不同的子功能都模拟一定的用户数量,通过工具来控制并发情况;

如发送与接收邮件模块的一个测试用例,

功能:当在线用户达到高峰时,发送和接收普通邮件正常,保证2000个以内用户可以同时访问邮件系统,能够正常发送和接收邮件;

目的:测试系统2000个以内的用户同时在线时能否正常发送邮件;

方法:采用LOADRUNNER的录制工具录制一个邮件发送过程测试,要监视数据库服务器和WEB服务器的性能,其中发送的邮件为普通邮件,附件大小不超过1MB.

并发用户数与事务执行情况:并发用户数,事务平均响应时间,事务最大响应时间,平均每秒处理事务数,事务成功率,每秒点击率,平均流量;

并发用户数与数据库主机:并发用户数,CPU利用率,MEM利用率,磁盘I/O参数,DB参数;

并发用户数与应用服务器的关系表:并发用户数,CPU利用率,MEM利用率,磁盘I/O参数;

2.       组合模块用户并发性能测试的用例设计

组合模块的性能测试是最能反映用户实际使用情况的测试，它把前面系统中具有耦合关系的模块组合起来进行测试，可以理解为集成性能测试，组合模块并发测试可以真实反映用户使用系统的情况，可以从需求，设计文档；现场调查，系统采集数据获取用户场景；

具有耦合关系的核心模块进行组合并发测试：主要测试在多用户并发条件下，一些存在耦合关系或者数据接口的模块是否正常运行；

彼此独立的，内部具有耦合关系的核心模块组的并发测试：这类测试的对象是多个模块组，每个组相关的模块具有一定的耦合关系，组与组之间关系相互独立，主要站在用户的角度考虑问题；

基于用户场景的并发测试：选择用户的一些典型场景进行测试，测试对象不限制于核心模块或非核心模块；

组合模块用户并发性能测试的前两种类型仍然是针对核心模块的同时也关注用户场景，这样做的原因是大多数的性能问题都是由用户经常使用的核心模块一起的；可以看出，组合模块的用户并发性能测试既关注功能测试，也关注性能测试，通过发现一些接口和综合性能方面的问题，使系统更加稳定的运行。

如下某OA系统组合模块的一个测试用例：

功能：在线用户数达到高峰时，用户可以正常使用系统，目标是满足500个以内用户同时在线使用系统；

目的：测试500个以内用户同时在线时能否使用比较常见的模块：公文系统，电子公告，网上论坛；

方法：采用LOADRUNNER 的录制工具录制三项业务；业务1，在公文系统内进行打开，修改等操作；业务2，在电子公告系统内，察看发布公告； 业务3 ，在网上论坛系统内发布帖子，查看文章；每项业务分配一定数量的用户，利用LOADRUNNER来完成；

并发用户数与事务执行情况：业务1，业务2，业务3事务平均响应时间；业务1，业务2，业务3事务最大响应时间；业务1，业务2，业务3平均每秒事务数；业务1，业务2，业务3平均成功率；每秒点击率；平均流量；

并发用户数与数据库主机：CPU利用率；MEM利用率；磁盘I/O情况；DB参数；

并发用户数与应用服务器的关系：CPU利用率，MEM利用率；磁盘I/O情况；

5.       疲劳强度与大数据量测试；
疲劳强度测试：主要特点是长时间对目标测试系统加压，目的是测试系统的稳定性，持续时间一般在1小时以上；疲劳强度测试属于用户并发测试的延续，因此核心内容仍然是核心模块用户并发和组合模块用户并发，在编写测试用例时需要编写不同参数或者负载条件下的多个测试用例，可以参考用户并发性能测试用例的设计内容，通常修改相应的参数就可实现所需要的测试场景；如下疲劳强度测试用例：

极限名称：200个用户同时使用系统的3个模块；

前提条件：测试客户端要有足够的资源；

运行时间：连续运行16小时；

测试方法：采用LOADRUNNER录制3个任务，然后开始对系统加压；

输入动作：任务1，任务2，任务3 ；持续时间, 任务20小时， 任务2，21小时，任务3，16小时；用户数量；现象；

大数据量测试：主要针对对数据库有特殊要求的系统进行的测试，如电信业务系统的手机短信业务；可以分为实时大数据量，主要目的是测试用户较多或者某些业务产生较大数据量时，系统能否稳定运行；极限状态下的测试，测试系统使用一段时间即系统累计一点量的数据时能否正常的运行业务；前面两种的结合，测试系统已经累计了较大数据量时，一些实时产生较大数据量的模块能否稳定工作；如下大数量测试用例：

功能：数据库中的短信息表可以保存所有不能及时发送的短信息，用户上线后又能及时发送已经保存的信息；

目的：

方法：

并发用户数与事务执行情况：输入说明； 事务平均响应时间；事务最大响应时间；平均每秒处理事务数，事务成功率；每秒点击率；平均流量；

6.       网络性能测试；
     基于硬件的测试：主要是通过各种软件工具，仪器等测试整个系统的网络运行环境，一般由系统集成人员负责 ；

     基于应用系统的测试：主要测试用户数目与网络带宽的关系，通过测试工具准确展示带宽，延迟，负载和端口的变化是如何影响用户响应时间的；

网络性能测试的用例设计主要针对后一种类型，可以独立进行测试，也可以和用户并发性能测试，疲劳强度与大数据量测试结合起来，在原有的基础上采用工具来调整网络设置，从而达到监视网络性能的目的；如下网络性能测试用例；

目的： 测试系统运行在不同网络带宽条件下的性能情况，以及与并发用户数量的关系；

方法：在不同的广域网带宽下使用LOADRUNNNER录制邮件系统得相关事务操作脚本，然后以不同的带宽和并发用户数进行压力测试，并记录在各种用户条件下各种事务的响应情况，同时记录路由器端口的流量和其他数据；

运行时间：

并发用户数与事务响应时间：

7.       服务器性能测试；
服务器性能测试主要是对数据库，WEB服务器，操作系统的测试，目的是通过性能测试找出服务器的瓶颈，为系统扩展，优化提供相关的依据；分为：

高级服务器性能测试：在特定的硬件条件下，由数据库，WEB服务器，操作系统相应领域的专家进行的性能测试；

初级服务器性能测试：在系统运行前面的性能测试时，通过测试工具对数据库，WEB服务器，操作系统的使用情况进行监控，然后进行综合分析，找出系统瓶颈；性能测试的主要目的是在软件功能良好的前提下，发现系统瓶颈并解决，而软件和服务器是产生瓶颈的两大来源，因此服务器测试一定要和前面的测试结合起来进行；在进行用户并发性能测试，疲劳强度与大数据量性能测试时，可以完成对服务器的监控并对服务器性能进行评估；这类部分的测试用例一般不必单独编写；

四、WEB性能测试用例设计
WEB 性能测试用例设计模型是设计性能测试用例的一个框架，在实际项目中，需要对其进行适当的剪裁，从而确定性能测试用例的范围和类别，裁减的依据是性能测试策略和测试范围；在测试用例主要框架确定后，接下来就要如何设计各类性能测试用例中具体数据。

基于用户的测试多在用户现场进行，而为了测试目的而进行的测试多在开发环境即开发团队的内部进行；为了测试目的而设计的测试用例场景主要根据测试设计人员的经验来进行，但是仍要参考用户的实际场景，用户实际使用场景是设计所有测试用例的依据，性能测试用例设计首先要分析出用户现实中的典型场景，然后参照典型场景进行设计。比较常见的用户场景有如下三种：一天内不同时段的使用场景；系统运行不同时期的场景；不同业务模式下的场景；各类测试用例设计的细节：

1.       确定用户使用系统情况的方法；
确定用户对系统的使用情况是设计用例具体数据的基础，后面并发用户数据设计，疲劳强度设计以及各种场景设计都要依赖对用户使用系统情况的分析，分析用户使用情况经常采用现场调查和分析系统日志两种方法；

用户现场调查：通过和用户进行沟通，可以确定用户的人员组成情况；这类方法适用于用户群体固定且目标测试系统没有投产前的情况；

分析系统日志：当用户比较分散，现场调查比较困难时，可以采用对系统日志进行分析的方法，作为对用户现场调查的补充；

2.       并发用户数量设计；
     设计并发用户数量前，首先要了解确定系统最大并发用户数量的方法；可以根据系统的最大使用人数或者最大在线数量来评估最大并发用户数量的方法；

     极限法：取最大在线用户数作为最大并发数，这种方法适用于系统已经投产目标用户群体不确定的门户网站，可以通过分析日志来进行测试；也可以使用系统已经注册的用户数量作为系统的用户数量，按照经验公式来估算最大用户数量；

     用户趋势分析：对软件生存周期内的用户未来走势进行分析，预测系统可能达到的最大使用用户数目，从而估算系统的最大并发用户数目，这种方法多用于用户数目逐渐增多的情况；

    经验评估法：多用于系统的使用用户数目相对稳定而且比较明确的系统；

并发用户数量的设计基本是按照最大并发用户的数量的百分比来设计的，对于某一特定的用例，需要注意：

一按照各类用户同时递增的方式来设计用户数量，是为了按照由浅入深的方法来发现系统的瓶颈；二并发用户的最大值一般不会超过前面计算的最大并发用户数量的20% ，除非是为了测试系统能支持的最大并发用户数量；三设计用户数量时要考虑成本，因为每组用户数都意味着至少执行一次测试；

3.       系统不同时间段场景的设计；
不同时间段的场景更接近用户使用情况，它也是设计核心模块和组合模块并发性能测试用例的基础，不同时间段场景分析的数据主要是前面的需求分析和日志分析结果；不同时间段场景的设计基本原则有两个：一是选择典型的场景进行测试；尤其要选择场景中并发用户数目较大的场景；二是要覆盖全面，设计出的用例要覆盖到压力可能较大的时间段；用户场景的设计一般与后面的业务模式结合起来进行；

4.       业务模式的设计；
     业务模式的设计是不同时间段场景设计的特例，也是设计核心模块和组合模块并发性能测试用例的基础，设计业务模式的目的是专注于某些功能模块的组合，按时间段来设计场景通常会涉及很多模块，如果系统存在的由应用软件引起的瓶颈则很难定位，所以才抽象一些特定的业务模式来进行用例的设计；

按照业务模式和时间段的场景来设计性能测试用例时，会涉及到如何设计每个模块并发用户数目的问题，通常会取各个相关模块在24小时内最大的并发用户数目进行组合；

5.       大数据量测试用例的设计；
历史数据相关的大数据量测试设计与并发用户的测试设计很类似，首先要确定系统数据的最长迁移周期，确定了系统的最大数据量后，接下来选择一些前面的核心模块或者组合模块的并发用户测试用例作为其主要内容即可；

运行时大数据量测试主要根据模拟系统运行时可能产生的大数据量来进行测试，这类测试用例通常根据实际情况去分析设计；

6.       一些特定测试用例的设计；
疲劳强度测试，最大用户测试，容量测试等一些特殊的测试用例设计，根据用户的需求进行，这类用例的相关要求通常十分明确；

性能测试用例最重要的是注意用例间的关系，孤立的设计各类用例只能增加测试成本，浪费人力。性能测试用例设计人员应该追求设计既能覆盖性能测试需求，又能以较低的成本来执行测试用例；

五、WEB性能测试用例设计总结
1.       测试用例可用性总结
对于一个比较完善的性能测试项目，经常会有一些测试用例不能执行，，因此测试完成后应该分析哪些用例不能执行以及不能执行的原因，这样可以为下次测试打好基础。

2.       用例执行效果分析
通过对用例执行效果进行分析，可以为升级或者开发新的性能测试用例提供有利的参考，不是所有的用例都能导致系统瓶颈的出现，因此应该分析哪些用例能够发现系统问题，哪些用例执行时没有太大效果。分析那些设计好的用例不但有助于以后设计用例，还可以为再次执行提供参考：当下次测试进度压力较大时可以先执行重要的用例，跳过那些尝试性的，不容易发现问题的用例；

3.       用例执行时间分析；
分析用例的执行时间是为下次规划性能测试提供参考，由于很多用例执行时间不是特别确定，导致性能测试计划也具有一定的不确定性。通过分析用例的执行时间可以为以后的制定测试计划提供参考；

总之，性能测试用例的设计是需要通过不断分析总结才能做好，不但要分析性能测试用例的可用性，执行效果，执行时间，还应该分析用例的设计方法，设计思路等。

1.负面测试的目的

负面测试在BS7925-1中的英国标准定义是采用Beizer的定义，其定义负面测试为“旨在说明软件不能工作的测试”（原文：Testing aimed at showing software does not work）。它可以带出一系列补充性的和竞争性的目的。

发现导致重大失效、崩溃、破坏和安全漏洞的故障

观察和度量系统对外界问题的响应

揭露软件的弱点和开发的潜力

虽然有个一个公正的定义，但是它离被普遍接受还差的很远。负面测试是一个紧跟着被重新定义的术语，有时甚至是各小组的。一个常见的方法，其实践和英国标准定义不同的是它包括旨在使用专门对付失效的功能的测试。

输入验证，拒绝和重新请求的功能（人工输入和外界系统）

内部数据验证和拒绝

应付缺乏的，缓慢的或坏掉的外界资源

错误处理功能，例如消息，日志，监视功能

恢复功能，例如故障恢复，回滚和恢复

2.获取测试用例的技术

负面测试不是一种测试设计技术，说是一种方法或分类更加合适。使用许多正式的测试设计技术来获取那些能够被划分为‘负面测试’的测试是很有可能。这一节详述了各种各样的知名技术的应用。

边界值分析和等价类划分Boundary Value Analysis and Equivalence Class Partitioning

状态转换测试State Transitiontesting

逆着已知的约束测试Test against known constraints

故障模式和结果分析Failure Mode and Effects analysis

并发Concurrency

用例和误用的用例Use cases and mis-usecases

2.1.边界值分析和等价类划分

有两种基于输入和输出数据和系统行为期望的技术。

边界值分析（BVA：Boundary Value Analysis）利用关于预知系统行为转换位置的边界的需求和设计来检查那些能够带出一连贯范围数值的数据元素。

这个方法用于产生三个数值－一个就是边界本身，另外两个在前者的两边（尽可能的和数字相接近）。如果边界在有效和无效范围之间，使用无效数值的测试用例将成为一个负面测试用例。例如，使用66在只接受从18～65数值的年龄字段。

等价类划分（ECP：Equivalence Class Partitioning）着眼于边界之间的范围。给出的等价类中的每个成员应该在一个已知测试的环境里，使系统做同样的事情－这样测试员不必要测试在等价类中每一个数值。无效输入数据的范围可以被看成为负面测试－例如，一个年龄字段可能被期望用相同的方法拒绝所有的负数。

ECP一般被延伸到包括非连续数值的集合，胜于连续的数值范围。要注意一些输入可能看上去等价，但是实际上出现很多不同的行为。例如，一个简单web的表单的输入是为空或者太长时可能会被拒绝，但是控制字符的正确组合可能危害潜在web服务器的安全。

2.2.状态转换测试

假设有一个状态转换图或者一个与其等价的理解，那么就很容易获得可以明确地检查不可到达的状态是否真的不可到达的测试用例。与这种方法相同的变种称为n-switch测试，在一套已知的转换之后，那些不可到达的状态仍然是不可到达吗？图形工具，例如Compendium-TA[4]能够帮助你获得这样的测试。

2.3.逆着已知的约束测试

大多数的系统有明确的和含蓄的限制和约束。如同需求一样对待这些约束（参加Robinson+Robinson,[5])）就可以得到各种负面测试。例如：

“The site is designed to be viewed with Internet Explorer4.5 or later”–负面测试可以使用IE3.0或Netscape.

“No more than five users will use the system at the same time”–负面测试可以尝试6个，然后8。

概括来说，测试包括度量和观察系统的行为胜于直接逆着期望结果测试。这只能在系统的操作参数之外工作时被使用，并且这种观察可能导致对系统的进一步了解。

2.4.故障模式和结果分析

从对潜在的技术，实现和已知故障的分析来预见系统特有的故障是很有可能的。这种分析是观察在故障条件下系统行为的测试基础。捕获和文档化这种信息是非常重要的－特别是如果他们允许诊断数据和环境。对于那些监视他们系统并且拥有在系统被使用时（例如银行，电话公司）可以采取行动的技术专家的组织而言，这些文档通常是测试的必要输出。另一方面，对于更广泛的分布式软件包来说，这些信息也可以成为FAQ或故障诊断指南的一部分。

这些测试可能不可能在没有一个有效的测试工具或应用驱动下执行。这样的工具通常是自定制的，并且可能需要在代码的已提交版本里运行。

然而，象CannedHEAT和Holodeck(都出自the Florida Institute of Technology,[6])这样的工具允许将普通性故障引入到运行在Windows的软件中。

6.4.1.故障家族

有很多来源可以帮助你开发故障模式的家族。既有故障的根本原因分析，系统设计文档，基础设施特有问题的知识能够帮助识别故障模式，并且因此为获取测试提供来源。

以下列表虽不详尽，但或许可以帮助引发更多的关于可能的故障想法。

外部资源：反应迟钝或缓慢的，莫明其妙或不恰当的反应。

协处理器故障：独特的间断处理器，多任务和递归

并发使用：资源锁定，请求已拒绝的锁定，死锁，锁定响应延迟

牺牲处理器Sacrificialprocesses：允许失败的处理器并且用可控方式恢复

文件系统：文件不能被找到，打开，读，写，权限变更，文件系统识别介质错误，介质移除，介质装满

网络：网络中断，网络忙碌/缓慢，传输段丢失、损坏、无序，处理器之间的对话被中断

内存：不足以给请求的分配，碎片

已达到的限制：排队，licences，线程，连接，数组大小，资源分配

2.5.并发

测试对资源的并发使用可以是一个非常富有成效的找bug方法。初始分析包括鉴别也许会尝试同时使用的数据，数据库条目，文件、连接和超过一个处理器的硬件。通过允许测试者在系统之前利用资源，简单，定制的工具可能有些帮助,并且在他们选择的时候发布它。测试也应该检查第二个请求者最终得到了资源。更加复杂的测试将着眼于二个以上的请求,排队,超时和死锁。

2.6.用例和误用的用例

用例，在实践中趋向于处理系统的‘happypath’。各种错误输入的覆盖，拒绝的循环和部分转换通常是很稀少的。‘误用的用例’术语，虽然不是偏僻的标准，但是能够帮助明确地识别和区分他们。执行这些路径地用例可以通过图解期望结果正常范围外的用户的活动来帮助提高设计，并且允许一个正式的方法来测试选择和覆盖．

　　会员卖烧烤的鱼的精彩回答：

　　安全性测试（security testing）是有关验证应用程序的安全服务和识别潜在安全性缺陷的过程。

　　注意：安全性测试并不最终证明应用程序是安全的，而是用于验证所设立策略的有效性，这些对策是基于威胁分析阶段所做的假设而选择的。

　　以下是我读<<软件评测试教程>>中的Web安全性测试章节内容，并进行修改的笔记，前面看了好多朋友写的，不过不是很全，希望对大家有所帮助，建议大家还是买本<<软件评测试教程>>此书绝对物超所值^_^

WEB安全性测试
　　一个完整的WEB安全性测试可以从部署与基础结构、输入验证、身份验证、授权、配置管理、敏感数据、会话管理、加密。参数操作、异常管理、审核和日志记录等几个方面入手。
1.        安全体系测试
1)        部署与基础结构
　　网络是否提供了安全的通信
　　部署拓扑结构是否包括内部的防火墙
　　部署拓扑结构中是否包括远程应用程序服务器
　　基础结构安全性需求的限制是什么
　　目标环境支持怎样的信任级别
2)        输入验证
l        如何验证输入
A.        是否清楚入口点
B.        是否清楚信任边界
C.        是否验证Web页输入
D.        是否对传递到组件或Web服务的参数进行验证
E.        是否验证从数据库中检索的数据
F.        是否将方法集中起来
G.        是否依赖客户端的验证
H.       应用程序是否易受SQL注入攻击
I.        应用程序是否易受XSS攻击
l        如何处理输入
3)        身份验证
　　是否区分公共访问和受限访问
　　是否明确服务帐户要求
　　如何验证调用者身份
　　如何验证数据库的身份
　　是否强制试用帐户管理措施
4)        授权
　　如何向最终用户授权
　　如何在数据库中授权应用程序
　　如何将访问限定于系统级资源
5)        配置管理
　　是否支持远程管理
　　是否保证配置存储的安全
　　是否隔离管理员特权
6)        敏感数据
　　是否存储机密信息
　　如何存储敏感数据
　　是否在网络中传递敏感数据
　　是否记录敏感数据
7)        会话管理
　　如何交换会话标识符
　　是否限制会话生存期
　　如何确保会话存储状态的安全
8)        加密
　　为何使用特定的算法
　　如何确保加密密钥的安全性
9)        参数操作
　　是否验证所有的输入参数
　　是否在参数过程中传递敏感数据
　　是否为了安全问题而使用HTTP头数据
10)        异常管理
　　是否使用结构化的异常处理
　　是否向客户端公开了太多的信息
11)        审核和日志记录
　　是否明确了要审核的活动
　　是否考虑如何流动原始调用这身份
2.        应用及传输安全
　　WEB应用系统的安全性从使用角度可以分为应用级的安全与传输级的安全，安全性测试也可以从这两方面入手。
　　应用级的安全测试的主要目的是查找Web系统自身程序设计中存在的安全隐患，主要测试区域如下。
　　注册与登陆：现在的Web应用系统基本采用先注册，后登录的方式。
A.        必须测试有效和无效的用户名和密码
B.        要注意是否存在大小写敏感，
C.        可以尝试多少次的限制
D.        是否可以不登录而直接浏览某个页面等。
　　在线超时：Web应用系统是否有超时的限制，也就是说，用户登陆一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。
　　操作留痕：为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进入了日志文件，是否可追踪。
　　备份与恢复：为了防范系统的意外崩溃造成的数据丢失，备份与恢复手段是一个Web系统的必备功能。备份与恢复根据Web系统对安全性的要求可以采用多种手段，如数据库增量备份、数据库完全备份、系统完全备份等。出于更高的安全性要求，某些实时系统经常会采用双机热备或多级热备。除了对于这些备份与恢复方式进行验证测试以外，还要评估这种备份与恢复方式是否满足Web系统的安全性需求。
　　传输级的安全测试是考虑到Web系统的传输的特殊性，重点测试数据经客户端传送到服务器端可能存在的安全漏洞，以及服务器防范非法访问的能力。一般测试项目包括以下几个方面。
　　HTTPS和SSL测试：默认的情况下，安全HTTP（Soure HTTP）通过安全套接字SSL（Source Socket Layer）协议在端口443上使用普通的HTTP。HTTPS使用的公共密钥的加密长度决定的HTTPS的安全级别，但从某种意义上来说，安全性的保证是以损失性能为代价的。除了还要测试加密是否正确，检查信息的完整性和确认HTTPS的安全级别外，还要注意在此安全级别下，其性能是否达到要求。
　　服务器端的脚本漏洞检查：存在于服务器端的脚本常常构成安全漏洞，这些漏洞又往往被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。
　　防火墙测试：防火墙是一种主要用于防护非法访问的路由器，在Web系统中是很常用的一种安全系统。防火墙测试是一个很大很专业的课题。这里所涉及的只是对防火墙功能、设置进行测试，以判断本Web系统的安全需求。

另推荐安全性测试工具：
　　Watchfire AppScan：商业网页漏洞扫描器(此工具好像被IBM收购了，所以推荐在第一位)
　　AppScan按照应用程序开发生命周期进行安全测试，早在开发阶段就进行单元测试和安全保证。Appscan能够扫描多种常见漏洞，例如跨网站脚本、HTTP应答切开、参数篡改、隐藏值篡改、后门/调试选项和缓冲区溢出等等。

　　Acunetix Web Vulnerability Scanner：商业漏洞扫描器(目前用的比较多，不过这东东N占内存)
Acunetix WVS自动检查您的网页程序漏洞，例如SQL注入、跨网站脚本和验证页面弱密码破解。Acunetix WVS有着非常友好的用户界面，还可以生成个性化的网站安全评估报告。

　　另附我以前在51testing上发过“Yeepay网站安全测试漏洞之跨站脚本注入”
http://bbs.51testing.com/thread-113784-1-1.html
　　Sql注入和跨站脚本这种漏洞比较常见，另在支付宝网站注册页面也存在跨站脚本情况，希望能早点发现^_^

功能测试： 圆珠笔按下是否能正常写字，写字太重会不回缩回去，继续按会不会弹回去

性能测试：圆珠心弹出弹回的快慢

负载测试：一直按，弹簧能接受多少次的升缩

兼容性测试：换其他的笔芯能不能行

强度测试：用力过度会怎样

可恢复性测试：如果弹簧压久了，是否可恢复等等

GUI测试：笔的外观，拿笔的舒适性

安全性：考虑对笔芯的保护，是否对使用者造成危害等等

　　2、在上升轨的下沿买进股票，然后持有，到上升轨发生明显的变化，卖出。

　　3、局面复杂看不清的股票，千万不要进去，柿子捡软的捏，炒股也一样。

　　4、不要把所有的钱一次性买进同一只股票，即便你非常看好它，而且事后证明你是对的，也不要一次性买进。总有可能买得更低，或者有更好的机会买进。

　　5、如果误买了下降通道的股票，赶紧卖出，避免损失扩大。

　　6、不要买太多的股票，最好不要超过五只。你没有那么多精力看着她们。如果你想娶五个老婆，即便你身体够好，你也满足不了你的老婆们。韦小宝的故事只发生在小说里。

如果没有损失，也赶紧退出观望。

　　7、不是上升通道的股票，根本不要看。管它将来怎么样，不要陪主力去建仓。没时间陪他们耗着。

　　8、赢钱时加仓，输钱时减码，如果你不想死的快而想赚得块，这是唯一的方法。

   9、不要相信业绩，那只代表过去，不代表将来。

　　10、炒股是炒将来，不是过去。

　　11、不要幻想老是去做短线，每天进进出出。股票不是*，频繁进出，可能给你带来快感，但会让你损失很多的钱，唯一受益的是证券公司，而且你不会有那么高的水准，你也不是庄家。　

　　12、股票很便宜了，跌了很多了，不是你买入的理由，永远不是！！！他还可能更加便宜！！！！

　　13、股票很贵了，涨了很多了，也不是你拒绝买入或者卖出的理由。他还可能涨得更高！！！！！

　　最后一点，股票不是你生活的全部，你还有你的家庭，还有你的事业，还有你的爱情，他们比你的股票更加宝贵。多陪陪他们，少陪陪股票。钱是永远赚不完的，但很多东西一旦失去了，就永远不再回来！！！！

接下页