本文档主要描述非功能性测试的主要内容、测试范围、测试方法和策略，以及常见的问题，为进行该类测试的人员提供测试指导和帮助.
大型的产品级软件系统都需要在上线前进行非功能性测试。我们通常所说的性能测试就是非功能性测试中最重要的组成部分。严格的非功能性测试能确保系统的性能瓶颈、安全漏洞、兼容性问题、系统稳定性等问题得到暴露和解决，增强对产品质量的信心，是系统上线商用前的重要步骤。
压力测试也称为负载测试。
1、测试工具
LR等工具
2、测试方法
以系统实际运行并发数量的极限情况作为测试并发数量，进行并发测试
3、关注结果
系统运行的正常性（是否中途运行失败）、系统CPU和MEM性能下降程度、系统事物响应速度（如TPS等参数）、系统特定功能模块的运行时间、系统运行日志是否记录有错误；
4、适用系统
面向大量用户使用的WEB站点（B/S），大型MIS系统（B/S C/S）
5、常见错误
（1）TPS太小或者响应时间太大，没有达到产品需求的要求；
（2）存在系统CPU、MEM性能参数消耗过大的情况；
（3）并发用户中，存在若干用户失败的情况；
（4）其他[其他文档摘要]：
使用压力测试，您有希望找到很多种用其他测试方法更难发现的错误。有两种错误类型是：
内存泄漏（Memory leak）：一种极难检测的现象。内存泄漏经常发生在已发行的产品中，原因很简单，很难设计测试用例来检测它们。使用简单的功能测试，几乎发现不了内存泄漏问题，因为在产品完成之前测试没对产品进行足够多的使用。内存泄漏通常要求操作要重复非常多的次数以使内存消耗达到能引起注意的程度。尽管与其它编程语言（如C/C++）相比，Java程序更难引入内存泄漏错误，但只要程序仍保持着对对象的引用，该对象仍有可能被实例化并且它占用的内存永远不会被释放。
并发与同步（Concurrency and Synchronization）：压力测试在查找并发性问题上非常出众，这是因为在任何一个测试生命周期中，它都应用了许多不同的代码路径和定时条件。一般的规则是，压力测试运行的时间越长，涉及并应用的代码路径组合和定时条件就越多。当然，这也的确使得这些问题很难再现（错误可以在5分钟或5天后发生）。死锁、线程泄漏以及任何一般的同步问题通常只能在压力测试阶段被检测出来。这些类型的问题很难通过执行单元测试来发现。开发人员不会一直考虑他或她的代码将与其他地方的代码（在执行单元测试时这些代码可能还没写出来）进行交互。
1、 测试工具
根据容量测试的具体要求来选择工具，构造大容量的测试数据。例子如下：
日志分析：使用编程工具来快速生成大量的日志文件；
数据库逻辑操作：使用SQL脚本来生成符合逻辑要求的大量数据库记录；
话单等文件解析操作：类似日志分析的构造方法；
综合性的容量测试：运用以上所有方法来产生测试场景所需要的大数据量背景。
2、 测试方法
容量测试关键是构造有效的测试数据。有效是指数据量的大小符合现网要求，而且数据的构成比例也尽量符合现网要求（在数据组合比较复杂的情况下，可以按最典型的数据组合来简化）。
3、 关注结果
系统运行的正常性（是否中途运行失败），系统CPU和MEM性能，系统相应速度、系统特定功能模块的运行时间、系统运行日志是否记录有错误；
4、 适用系统
需要对大量数据库数据/文件进行解析、逻辑处理的后台系统。如电信级别的运营系统、日志分析系统等。
5、 常见错误
（1）过期数据或者临时数据没有删除，导致数据库或者应用服务器的机器空间急剧减少；
（2）数据库SESSION连接过多，程序没有及时释放等原因，导致执行失败，如：
java.sql.BatchUpdateException: ORA-00604: error occurred at recursive SQL level 1ORA-01000: maximum open cursors exceeded
oracle.jdbc.dbaccess.DBError.throwBatchUpdateException(DBError.java:460)
（3）内存泄露、内存没有释放、内存消耗过多，出现类似java.lang.outmemory的错误，如：java.lang.Exception: java.lang.OutOfMemoryError
（4）系统性能消耗过大：如CPU过低，甚至出现IDLE<10%的情况；内存消耗过大，free的内存只剩下20M左右；
（5）系统运行时间过长：由于处理方案设计的并发进程数不够等原因，导致系统处理大数据量时使用时间过长，无法满足产品需求。出现该问题时，往往系统的CPU、MEM的消耗都比较小。系统在消耗系统资源和增加运行时间之间没有达到最优的平衡。
注：目前个人理解为：性能测试包括压力测试和容量测试。
1、对于此类系统：面向大量用户使用的WEB站点（B/S），大型MIS系统（B/S C/S）
可以使用LR工具，设置循环次数/时间来实现稳定性测试。
2、对于此类系统：需要对大量数据库数据/文件进行解析、逻辑处理的后台系统
稳定性测试的方案比较多，举例如下：
（1）若输入的数据源为表数据：
方法一：使用JOB调用存储过程来实现。这个存储过程的作用一般为：新增新的记录或者修改原来老记录的特定字段（如时间/数量）
方法二：使用JOB定时修改上次执行的断点记录值（如将ID或者时间往前修改），使程序下次执行时仍然能处理一定数量的数据。
（2）若输入的数据源为文件：
方法一：使用crontab定时从另外一个目录CP文件，补充到系统的采集目录；
方法二：使用LR录制FTP脚本（RTE协议/FTP协议），并设置循环和思考时间，定时向采集目录FTP需要的文件；
方法三：使用UNIX C脚本直接完成文件生成和转移的操作；
1、应用系统和操作系统的兼容性（LUNIX UNIX）
2、相关应用系统之间的兼容性（如MISC各网元）
3、同一系统，不同PATCH之间的兼容性（如在多点部署并互连的系统，PATCH1和升级后的PATCH2是否仍然可以交互正常工作）
4、系统对数据源格式/协议的兼容性（如日志分析系统，是否兼容老规范和新规范，是否兼容缩写和非缩写等）
重点关注以下方面（参考塞班斯法案要求）：
1、密码取回；
2、密码修改：是否要求强密码原则（6-16位,至少含有数字、小写字母、大写字母、特殊字符中任意3项）；修改密码时是否需要输入老密码；
3、密码保存：数据库中或者配置文件中，密码字段是否加密
4、系统登陆：密码错误次数限制等；
5、权限管理：权限管理可以设置不同角色和权限；
6、操作日志：是否记录有操作日志；
1、不同功能的容错性要求是不同的。需要根据需求说明书中异常处理部分的说明设计特定的测试方法和步骤。
2、系统对各种错误情况，需要在页面显示人性化的错误提示信息，不能直接打印编程语言抛出的异常信息、中间件抛出的异常信息。
3、错误信息定位准确
1、打印运行日志
系统正常运行日志记录简洁清晰、可读性强；
系统运行出现异常时，日志信息丰富，定位准确，可指导开发和测试人员发现和解决问题；
2、写操作历史表
有些系统对重要的业务操作必须记录操作历史表。这样系统出现异常时方便维护人员定位问题。
3、“安装部署文档”需要对各配置项进行详细说明，维护文档完整。
安装部署测试：依照产品安装部署文档的步骤，测试系统是否可正常安装。
配置项测试：系统一般有配置参数表，需要在测试中按等价类划分的方法，设置不同的值来验证系统确实读取了该配置项（存在问题的系统往往在代码中直接使用默认值，即被写死）。
易用性测试：站在用户的角度，对产品使用的方便性、美观性、易用性等方面提出改进建议，使产品更加完善、易用和专业。
文档测试：对于产品同时提交给用户的文档，如安装部署文档、维护文档、功能介绍文档等，进行文档校验，确保文档完备、准确，整洁美观。
附属工具测试：一般大的软件产品都有一些提供给后期维护人员的维护工具或者脚本，这些作为内部使用的附属工具，如果时间允许，也可以作为测试范围。（如MISC离线工具、SS割接脚本等）
