Web安全性测试—SQL注入

Web安全性测试—SQL注入

因为要对网站安全性进行测试，所以，学习了一些sql注入的知识。

　　在网上看一些sql注入的东东，于是想到了对网站的输入框进行一些测试，本来是想在输入框中输入<script>alter("abc")<script>,但是输入框有字符限制，只好输入<script>,结果网站出大问题了，呵呵，终于又出现了个bug。

　　另一个就是在URL最后随意输入一些字符或数字，结果，新闻模块那出现了问题，暴露了网站的一些信息，又一个bug，高兴下……

　　下面把今天看到的有关SQL注入方面的知识整理如下：

　　SQL注入是一种攻击方式，在这种攻击方式中，恶意代码被插入到字符串中，然后将该字符串传递到SQL Server的实例以进行分析和执行。任何构成SQL语句的过程都应进行注入漏洞检查，因为SQL Server将执行其接收到的所有语法有效的查询。一个有经验的、坚定的攻击者甚至可以操作参数化数据。

　　SQL注入的主要形式包括直接将代码插入到与SQL命令串联在一起并使其得以执行的用户输入变量。一种间接的攻击会将恶意代码注入要在表中存储或作为元数据存储的字符串。在存储的字符串随后串连到一个动态SQL命令中时，将执行该恶意代码。

　　注入过程的工作方式是提前终止文本字符串，然后追加一个新的命令。由于插入的命令可能在执行前追加其他字符串，因此攻击者将用注释标记“--”来终止注入的字符串。执行时，此后的文本将被忽略。

　　以下脚本显示了一个简单的SQL注入。此脚本通过串联硬编码字符串和用户输入的字符串而生成一个SQL查询：

　　var Shipcity;

　　ShipCity = Request.form. ("ShipCity");

　　var sql = "select * from OrdersTable where ShipCity = '" + ShipCity + "'";

　　用户将被提示输入一个市县名称。如果用户输入Redmond，则查询将由与下面内容相似的脚本组成：

　　SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond'

　　但是，假定用户输入以下内容：

　　Redmond'; drop table OrdersTable--

　　此时，脚本将组成以下查询：

　　SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond';drop table OrdersTable--'

　　分号(;)表示一个查询的结束和另一个查询的开始。双连字符(--)指示当前行余下的部分是一个注释，应该忽略。如果修改后的代码语法正确，则服务器将执行该代码。SQL Server处理该语句时，SQL Server将首先选择OrdersTable中的所有记录（其中ShipCity为Redmond）。然后，SQL Server将删除OrdersTable。

　　只要注入的SQL代码语法正确，便无法采用编程方式来检测篡改。因此，必须验证所有用户输入，并仔细检查在您所用的服务器中执行构造SQL命令的代码。本主题中的以下各部分说明了编写代码的最佳做法。

　　验证所有输入:

　　始终通过测试类型、长度、格式和范围来验证用户输入。实现对恶意输入的预防时，请注意应用程序的体系结构和部署方案。请注意，设计为在安全环境中运行的程序可能会被复制到不安全的环境中。以下建议应被视为最佳做法：

　　如果一个用户在需要邮政编码的位置无意中或恶意地输入了一个10 MB的MPEG文件，应用程序会做出什么反应？

　　如果在文本字段中嵌入了一个DROP TABLE语句，应用程序会做出什么反应？

　　测试输入的大小和数据类型，强制执行适当的限制。这有助于防止有意造成的缓冲区溢出。

输入字符在Transact-SQL中的含义
; 查询分隔符。
' 字符数据字符串分隔符。
-- 注释分隔符。
/* ... */ 注释分隔符。服务器不对/*和*/之间的注释进行处理。
xp_ 用于目录扩展存储过程的名称的开头，如xp_cmdshell。

                                                                   

 

 

Web安全体系测试

一个完整的Web安全体系测试可以从部署与基础结构，输入验证，身份验证，授权，配置管理，敏感数据，会话管理，加密，参数操作，异常管理，审核和日志记录等几个方面入手

数据加密：某些数据需要进行信息加密和过滤后才能进行数据传输，例如用户信用卡信 息、用户登陆密码信息等。此时需要进行相应的其他操作，如存储到数据库、解密发送要用户电子邮箱或者客户浏览器。目前的加密算法越来越多，越来越复杂，但一般数据加密的过程时可逆的，也就是说能进行加密，同时需要能进行解密！

注：对登陆帐户和密码进行加密，可在后台数据库查看是否进行了加密。

登录： 一般的应用站点都会使用登录或者注册后使用的方式，因此，必须对用户名和匹配的密码进行校验，以阻止非法用户登录。在进行登陆测试的时候，需要考虑输入的密码是否对大小写敏感、是否有长度和条件限制，最多可以尝试多少次登录，哪些页面或者文件需要登录后才能访问/下载等。

超时限制：WEB应用系统需要有是否超时的限制，当用户长时间不作任何操作的时候，需要重新登录才能使用其功能。

SSL： 越来越多的站点使用SSL安全协议进行传送。SSL是Security Socket Lauer(安全套接字协议层)的缩写，是由Netscape首先发表的网络数据安全传输协议。SSL是利用公开密钥/私有密钥的加密技术。（RSA），在位于HTTP层和TCP层之间，建立用户与服务器之间的加密通信，确保所传递信息的安全性。SSL是工作在公共密钥和私人密钥基础上的，任何用户都可以获得公共密钥来加密数据，但解密数据必须要通过相应的私人密钥。进入一个SSL站点后，可以看到浏览器出现警告信息，然后地址栏的http变成https，在做SSL测试的时候，需要确认这些特点，以及是否有时间链接限制等一系列相关的安全保护。

服务器脚本语言：脚本语言是常见的安全隐患。每种语言的细节有所不同。有些 脚本允许访问根目录。其他只允许访问邮件服务器，但是经验丰富的黑客可以将服务器用户名和口令发送给他们自己。找出站点使用了哪些脚本语言，并研究该语言的缺陷。还要需要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。最好的办法是订阅一个讨论站点使用的脚本语言安全性的新闻组。

注：黑客利用脚本允许访问根目录的这个安全隐患特性攻击网站。这个网站包含了脚本代码（有允许访问根目录的特性）就可能有这个安全隐患。

日志文件：在服务器上，要验证服务器的日志是否正常工作，例如CPU的占用率是否很高，是否有例外的进程占用，所有的事务处理是否被记录等。

目录： WEB的目录安全是不容忽视的一个因素。如果WEB程序或WEB服务器的处理不适当，通过简单的URL替换和推测，会将整个WEB目录完全暴露给用户，这样会造成很大的风险和安全性隐患。我们可以使用一定的解决方式，如在每个目录访问时有index.htm,或者严格设定WEB服务器的目录访问权限，将这种隐患降低到最小程度。

注：每个目录访问时有index.htm目的：通过首页中的登陆验证功能进行访问权限控制。

 

 

 

“易用性”测试

Usability的概念在中国开始逐渐为企业所认识，但是作为这个领域的核心词汇，usability的中文翻译仍未统一。目前存在着两个主流版本：“可用性”和“易用性”。这两个译法虽然只有一字之差，但它们所传达的含义却大相径庭。对这两者的取舍已经不仅仅是哪个更好一点的锦上添花的问题，而是哪个对哪个错的是非原则问题。“易用性”的使用对于正确理解usability具有极大的片面性和误导性，非常不利于其在中国的开展。

从英文原词上分析，usability是由use（动词）变化到usable（形容词）然后再转变为usability（名词）。Use这个词从动词到名词的过程还有另一种变化，就是从use（动词）到useful（形容词）再到usefulness（名词）。后者要比前者更“单纯”，变化的过程只是词性的改变而不涉及意思的转化。这些变化都围绕着use这个核心展开，因此在意思上都离不开“用”这个概念。-ability这个词根代表“具备某种行为特性”这样一个抽象的概念，故而在中文翻译中通常译为“可…性”，例如：readability（可阅读性）。因此，“可用性”这个译法是在严格遵从语言和翻译习惯的基础上形成的。“易用性”虽然也保留了这个“用”这个核心意思，但是其中的“易”字却完全是无中生有，因为在英文单词的整个变化过程中始终没有任何一丝“易”的意义出现。

对于为什么要人为加上“易”字，一个看似合理的解释是这是意译。那么usability是不是就是“易用”呢？不妨先看看usability的解释。世界标准组织对于usability的定义是“The extent to which a product can be used by specified users to achieve specified goals with effectiveness， efficiency and satisfaction in a specified context of use.”这个定义采用了effectiveness（效果）、efficiency（效率）和satisfaction（满意）三个维度来说明usability.尽管这三个维度并不构成usability的全部，但是在测量usability时它们是被最广泛采用的指标。如果说efficiency和satisfactory这两个维度还可以和“易用”扯上关系的话，那么effectiveness这个维度显然和“易用”是互相独立的两个概念。因此，意译这个说法同样是无法成立的。

事实上，“易用”在usability领域是有一个专门用语的，那就是ease of use.在英文文献中，没有人会简单地将ease of use与usability划等号。但是当usability进入中国以后，“易用性”却堂而皇之地以代言人的身份四处出现。也许有人认为“易用性”这个词比较直观，容易被大众理解和接受。殊不知这正是“易用性”的危害。如果放任“易用性”的使用， usability这个概念在中国恐怕将被局限在ease of use这个狭窄的范围之中。作为一个术语，是不是很容易从字面上理解其含义并不是第一重要的，“递归”这个术语就是一个很好的例子。对一个术语的翻译，在艰涩与误导之间永远都不应该选择误导。更何况“可用性”的译法远没有达到艰涩的地步。

 

 

功能测试中故障模型的建立

故障模型是将测试人员的经验和直觉尽量归纳和固化，使得可以重复使用。测试人员通过理解软件在做什么，来猜测可能出错的地方，并应用故障模型有目的地使它暴露缺陷。下面介绍功能测试中故障模型的建立。

1. 概述

故障模型是软件测试的基础，也是一个判断测试方法是否成熟的重要标志。在测试的过程中，要确保每一个目标状态都被测试，那么测试必须是系统的；为了最终定位软件缺陷，所以测试必须是集中的；测试需要使用大量的测试用例和重复性测试，因此测试必须是自动的。若要满足上述三个测试条件，我们必须建立故障模型。

故障模型是将测试人员的经验和直觉尽量归纳和固化，使得可以重复使用。测试人员通过理解软件在做什么，来猜测可能出错的地方，并应用故障模型有目的地使它暴露缺陷。它具有一定的形式和足够的信息对错误进行预测，因此对测试人员来说，构造一个准确的故障模型，是选择测试策略、设计测试用例和测试执行的基础。在建立故障模型时，希望故障模型在框架上是通用的，但是建立具体的故障模型时一定要针对具体的软件类型、应用环境、甚至开发工具才有意义。一个成熟的故障模型必须具备下列条件：

1）该模型是符合实际的：大多数系统中存在的故障都可以用该模型来表示；

2）模型下的故障个数是可容忍的：模型下的故障个数一般和系统的规模是成线性关系；

3）模型下的故障是可以测试的：存在一个算法，利用该算法可以检测模型中的每一个故障。

本文将从软件的功能和技术特点出发，如软件的输入、输出、数据以及处理等，分析在软件功能测试过程中，我们通常应建立的故障模型及按照故障模型所提供的缺陷类型寻找尽量多的缺陷。

2. 输入型故障模型

主要是对用户的各种输入进行建模，因为用户的输入是无法预期的，可能的组合状态也是千变万化。软件功能除了能让正确的输入得到正确的输出之外，还必须对非法和不合逻辑的输入进行处理，防止因数据异常造成不可挽回的错误。典型的建模方法有：

1）使用非法数据：从输入数据的类型、长度、边界值等方面考虑，测试软件是否允许不正确的输入进入系统并进行处理，是否有错误处理代码，代码是否正确。

2）使用默认值输入：检测软件中所使用的变量是否初始化，是否将非法数据默认为合法边界内的某个合理值。

3）使用特殊字：检测软件是否正确处理了特殊字符和数据类型。

4）使用使缓冲区溢出的合法输入：输入超过允许的最大长度的数据，检测软件是否检查字符串/缓冲区的边界。

5）使用可能产生错误的合法输入组合：测试多个输入值的组合，确认这些值的组合是否会互相影响而引起软件失效。

6）重复输入相同的合法输入序列：检测软件是否考虑了循环处理的边界。

3. 输出型故障模型

软件的输出通常是最直观也是用户最关注的，输出型故障模型就是从软件输出角度出发，分析造成故障的可能原因。例如通过一个正确的输入在不同情况下产生不同输出的情况可以对输入和输出的关系进行进一步验证；可采用列举等方法，强制软件产生不符合业务背景知识的无效的输出，从而进行处理，规避不必要的错误；强制修改输出的属性、查看输出结果，测试初始化代码和修改代码是否同步；检查用户界面刷新情况，在不同的操作下测试界面刷新时间是否正确、界面刷新区域计算是否正确。

在大多数的软件中，功能输出的正确与否直接决定了软件实现的好坏，输出型故障模型所覆盖的故障也占有相当大的比例。因此，我们在测试过程中应建立这种故障模型，从故障结果进行分析，判断造成故障的影响因素。

4. 计算型故障模型

对于部分软件程序，常需要进行大量的计算，因此该模型应该尽可能包括关于计算方面的各种错误。包括变量的定义与使用方面的错误；数据的冗余；数组变量的越界错误；数据类型不匹配的错误；还有数据操作方面错误，包括函数调用参数传递错误、赋值语句错误等。

在建立计算型故障模型的时候，要定义数据并且对这些数据执行各种故障操作，尽可能使模型比较完善。体现在功能层面上，可以使用非法的操作数和操作符组合来验证计算要求的合法性、强制使计算结果溢出考虑数据结构存储的正确性、同时对数据进行操作检测数据共享性等方法来建立故障模型。

5. 流程型故障模型

这是一种程序控制流的故障模型，是对在程序中同样占很大比例的循环结构和分支结构建立的模型。循环故障主要包括永不循环故障和死循环故障，这主要是由循环条件错误引起的。循环条件的错误中包括变量错误和运算符错误，在未执行循环之前，循环变量的初值设置出错以致永不循环；进入循环以后，循环变量的值不作修改以致发生死循环。

而分支故障则包括判定条件故障和谓词结构故障，由于判定条件的出错或者变量初值设置错误而导致不执行分支结构；对于进入了分支结构的执行，可能因为谓词的错误而提前退出分支结构。

由此可知，流程型故障模型很可能是由一串连续的故障所组成的。因此在软件功能测试中，我们可以通过判断软件流程是否正确执行、功能分支是否覆盖全面、循环操作是否正常结束等方法来检测软件流程的正确性。

6. 资源型故障模型

资源型故障模型是在文件系统超载、系统介质忙或不可用、介质损坏等情况下，运行被测程序进行测试。此类故障模型的建立通常需要辅助测试工具进行环境的模拟。当磁盘负荷到达一定程度或可用物理资源十分有限时，系统进程十分容易进入“死锁”状态或出现不可恢复的错误。产生死锁的根本原因在于系统提供的资源个数少于并发进程所要求的该类资源数。显然，由于资源有限，不可能为所有要求资源的进程无限制地提供资源。

但是，可以采用适当的方法，以达到消除或规避“死锁”的目的。因此判断软件在何种操作下会导致“死锁”以及软件对介质损坏的纠错能力也就变得极其重要。所以我们应该建立这种故障模型，并给出相应的测试用例。

7. 结论

故障模型的建立对于故障定位、故障分析以及生成相应的测试用例是非常有用的。本文在前人研究的基础上，仅仅从软件功能层面出发，提出了五种常用的故障模型。而在实际的软件测试工程中，由于软件故障原因的多样性，还有很多故障模型有待于进一步细化和探讨。

 

 

怎样完善功能测试小结

功能测试(Functional testing )，也称为behavioral testing（行为测试），根据产品特征、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求。

今天boss问我们对于公司当前功能测试是否有完善意见，突然觉得这个话题离我们很近，却总来没深入总结过。还好要求明天上交报告，先在此做些总结，到时候拼装下给boss.

接触测试三年了，从测试工程师到测试组长兼sepg，然后跳槽继续测试工程师。一路下来都在跟需求跟业务打交道。做好测试首先要做好需求、理解业务，这个不用多说了，相信很多人都总结过。当然也听到过一些言论“换单位了，那业务不是没用了”，换单位后，业务没用这是必然的，我也是从易制毒换到当前的税务，但有一点都是跟政府行业，其实我们要做的是摸索和总结如何快速获取和掌握新业务，内容不同，但方法是可以通用的。

对于需求处理，就我接触的有以下三种情况。

A、有需求说明，无设计文档。

B、有需求分析文档，快完成时临时补充设计文档。

C、有需求分析文档和设计文档。

A这种情况一般分工不是很明确的小团队都会出现，需求来源为客户或者区域客服（特点是太简单了没经过提取，或者太自我了，很难实现），这时候在不规范的过程也会弄一次需求讨论。

这个时候测试务必要做到这点——争取参加需求讨论会议，不用发言，只要听就可以。因为这里没有写文档的习惯，很多测试标准、需求处理细点都会在口头上体现，你得眼疾手快，参加会议很好的一点就是测试过程中，碰到不一致的地方，可以有足够的重语气让开发修改，因为你有证据，而不用去问开发这点是不是要改，如何实现。

B这种情况其实是最头痛的，在时间紧和维护项目中经常出现。软件需求功能在界面上都实现了，但开发只是考虑实现需求，却没有把需求与当前业务（其他模块的逻辑），后台数据处理（例如某个字段更新）这些弄好。因为功能测试时，测试人员大都会跑流程或者数据库测试，这时候模糊无标准的问题就来了，头痛。

另外一些开发人员就会以功能实现，进入测试、或者边设计边改，测试就大工作量了。这个时候测试有这些可以扭转一些局面——版本验收流程、开发人员给测试人员培训。版本验收：像前面提出的，设计不全面等，很容易导致只完成需求，破坏了原有功能或流程功能，在拿到版本后，进行初步的重要流程验收，可以减少很多测试工作量。

开发人员讲解培训：这个很好的解决了由于没设计文档导致的测试不了解内部，被动，另外也是给开发压力，逼他们做单元和集成自测，从中测试也可以提问，不要觉得这是浪费时间，好处你试了才知道。我很坏，呵呵。

C这种情况一般实行Cmmi3之后的企业都很规范。这里我讲下自己的几个方法，更好的理解需求：模块间逻辑图、数据流向图、需求用例矩阵。模块间逻辑图：其实就usecase图、流程图，只要能让自己摸清楚模块间的业务联系即可，为自己的业务测试用例做准备。数据流向图：目的是搞清楚，该某块功能涉及哪些表、存储过程，数据表见关系如何，其实有点像数据库模型的小型版，很多问题在界面上实现了，但后台sql处理却有错误。例矩阵这个主要是对覆盖率进行校验，其实就是一个execl，针对某个需求点有哪些用例。

这些文档我稍后上转。另外在阅读需求时，多写一些为什么（例如：文档上写着某输入框有默认值，那你注明下：默认值可以修改吗？）

或许你们觉得让测试参加会议，让开发讲解这些有点难，但记住一点：做测试的一定要“主动”。

在做功能测试过程中，经常会碰到其他的问题。例如：对于web，所用控件的ie兼容性，标签值显示格式、长度，提示信息风格、内容，按钮大小，名称等这些，当前项目和开发人员都习惯最后处理。更多时候测试跟开发还不能达成一致，维护时还有“这是以前开发人员弄的，当前不予修改这些。”

一些通用的界面要求可以定个标准并维护，这个初步难的话，在项目测试计划里能注明下，并达成统一。这样避免项目后期，开发人员改动，测试人员由于对工作负责又得全部测试一遍，减少工作量。

功能测试，先抓主干，在测分支这是恒定的原则。但如何完善功能测试这个值得讨论，测试前如何分析需求，编写用例，测试通过准则。测试中确定测试版本，选择用例，测试优先级。项目后期的测试分析，用例优化等等。

 

 

软件测试中服务器稳定性测试方法

服务器稳定性是最重要的，如果在稳定性方面不能够保证业务运行的需要，在高的性能也是无用的。

正规的服务器厂商都会对产品惊醒不同温度和湿度下的运行稳定性测试。重点要考虑的是冗余功能，如：数据冗余、网卡荣誉、电源冗余、风扇冗余等。

一些测试方法主要分以下几种：

压力测试：已知系统高峰期使用人数，验证各事务在最大并发数（通过高峰期人数换算）下事务响应时间能够达到客户要求。系统各性能指标在这种压力下是否还在正常数值之内。系统是否会因这样的压力导致不良反应（如：宕机、应用异常中止等）。

Ramp Up增量设计：如并发用户为75人，系统注册用户为1500人，以5％－7％作为并发用户参考值。一般以每15s加载5人的方式进行增压设计，该数值主要参考测试加压机性能，建议Run几次。以事务通过率与错误率衡量实际加载方式。

Ramp Up增量设计目标：

寻找已增量方式加压系统性能瓶颈位置，抓住出现的性能拐点时机，一般常用参考Hits点击率与吞吐量、CPU、内存使用情况综合判断。模拟高峰期使用人数，如早晨的登录，下班后的退出，工资发送时的消息系统等。

另一种极限模拟方式，可视为在峰值压力情况下同时点击事务操作的系统极限操作指标。加压方式不变，在各脚本事务点中设置同集合点名称（如：lr_rendzvous("same");）在场景设计中，使用事务点集合策略。以同时达到集合点百分率为标准，同时释放所有正在Run的Vuser。

稳定性测试：已知系统高峰期使用人数、各事务操作频率等。设计综合测试场景，测试时将每个场景按照一定人数比率一起运行，模拟用户使用数年的情况。并监控在测试中，系统各性能指标在这种压力下是否能保持正常数值。事务响应时间是否会出现波动或随测试时间增涨而增加。系统是否会在测试期间内发生如宕机、应用中止等异常情况。

根据上述测试中，各事务条件下出现性能拐点的位置，已确定稳定性测试并发用户人数。仍然根据实际测试服务器（加压机、应用服务器、数据服务器三方性能），估算最终并发用户人数。

场景设计思想：从稳定性测试场景的设计意义，应分多种情况考虑：

针对同一个场景为例，以下以公文附件上传为例简要分析场景设计思想：

1）场景一：已压力测试环境下性能拐点的并发用户为设计测试场景，目的验证极限压力情况下测试服务器各性能指标。

2）场景二：根据压力测试环境中CPU、内存等指标选取服务器所能承受最大压力的50%来确定并发用户数。

测试方法：采用1)Ramp Up-Load all Vusers simultaneously

2)Duration-Run Indefinitely

3)在Sechedule-勾选Initalize all Vusers before Run

容错性测试：通过模拟一些非正常情况（如：服务器突然断电、网络时断时续、服务器硬盘空间不足等），验证系统在发生这些情况时是否能够有自动处理机制以保障系统的正常运行或恢复运行措施。如有HA（自动容灾系统），还可以专门针对这些自动保护系统进行另外的测试。验证其能否有效触发保护措施。

问题排除性测试：通过原有案例或经验判断，针对系统中曾经发生问题或怀疑存在隐患的模块进行验证测试。验证这些模块是否还会发生同样的性能问题。如：上传附件模块的内存泄露问题、地址本模块优化、开启Tivoli性能监控对OA系统性能的影响等等。

测评测试是用于获取系统的关键性能指标点，而进行的相关测试。主要是针对预先没有明确的预期测试结果，而是要通过测试获取在特定压力场景下的性能指标（如：事务响应时间、最大并发用户数等）。

评测事务交易时间：为获取某事务在特定压力下的响应时间而进行的测试活动。通过模拟已知客户高峰期的各压力值或预期所能承受的压力值，获取事务在这种压力下的响应时间。

评测事务最大并发用户数：为获取某事务在特定系统环境下所能承受的最大并发用户数而进行的测试活动。通过模拟真实环境或直接采用真实环境，评测在这种环境下事务所能承受的最大并发用户数。判定标准阈值需预先定义（如响应时间，CPU占用率，内存占用率，已出现点击率峰值，已出现吞吐量峰值等）。

评测系统最大并发用户数：为获取整个系统所能够承受的最大并发用户数而进行的的测试活动。通过预先分析项目各主要模块的使用比率和频率，定义各事务在综合场景中所占的比率，以比率方式分配各事务并发用户数。

模拟真实环境或直接采用真实环境，评测在这种环境下系统所能承受的最大并发用户数。判定标准阀值预先定义（如响应时间，CPU占用率，内存占用率，已出现点击率峰值，已出现吞吐量峰值等）。取值标准以木桶法则为准（并发数最小的事务为整个系统的并发数）。

评测不同数据库数据量对性能的影响：针对不同数据库数据量的测试，将测试结果进行对比，分析发现数据库中各表的数据量对事务性能的影响。得以预先判断系统长时间运行后，或某些模块客户要求数据量较大时可能存在的隐患。

问题定位测试在通过以上测试或用户实际操作已经发现系统中的性能问题或怀疑已存在性能问题。需通过响应的测试场景重现问题或定义问题。如有可能，可以直接找出引起性能问题所在的代码或模块。

该类测试主要还是通过测试出问题的脚本场景，并可以增加发现和检测的工具，如开启Tivoli性能监控、开启HeapDump输出、Linux资源监控命令等。并在场景运行过程中辅以手工测试。

 

 

XCode调试技巧之EXC_BAD_ACCESS

XCode调试技巧之EXC_BAD_ACCESS中BUG解决是本文要介绍的内容，在iphone开发的时候EXC_BAD_ACCESS这个bug时不容易找到原因的，在网上找到的3个关于这个问题的方法，希望可以帮到你，我自己试了一下第一中方法，效果还不错

首先说一下 EXC_BAD_ACCESS这个错误，可以这么说，90%的错误来源在于对一个已经释放的对象进行release操作。

1. 重写object的respondsToSelector方法，现实出现EXEC_BAD_ACCESS前访问的最后一个object

有时程序崩溃根本不知错误发生在什么地方。比如程序出现EXEC_BAD_ACCESS的时候，虽然大部分情况使用设定 NSZombieEnabled环境变量可以帮助你找到问题的所在，但少数情况下，即使设定了NSZombieEnabled环境变量，还是不知道程序崩溃在什么地方。那么就需要使用下列代码进行帮助了：

1.      #ifdef _FOR_DEBUG_

2.     -(BOOL) respondsToSelector:(SEL)aSelector {

3.         printf("SELECTOR: %s\n", [NSStringFromSelector(aSelector) UTF8String]);

4.         return [super respondsToSelector:aSelector];

5.     }

6.     #endif

你需要在每个object的.m或者.mm文件中加入上面代码，并且在 other c flags中加入-D _FOR_DEBUG_（记住请只在Debug Configuration下加入此标记）。这样当你程序崩溃时，Xcode的console上就会准确地记录了最后运行的object的方法。

2. 通过NSZombieEnabled

相信很多人都知道通过NSZombies来帮助调试出现EXC_BAD_ACCESS的情况,但有时还是找不到需要的信息,那么应该怎么办呢?

下面通过一个例子来说明.下面是hello world的代码:

1.     NSString* hello = [NSString stringWithFormat:@"Hello world"];

2.     NSLog(@"What you say is %@",hello);

3.     [hello release];

运行后出现EXC_BAD_ACCESS错误.但没有其他任何提示,这时 候通过右击executables下的应用程序名,选择get info后,在arguments下输入环境变量(NSZombieEnabled,MallocStackLogging)

再次运行后程序crash,如图：（单击放大）

这次可以看到问题是”message sent to dealloced object”了,但具体是哪个语句引起的还并不知道,于是需要在gdb上输入以下语句:

1.     shell malloc_history pid address

那么pid和address是什么呢?再看下crash的图片结合一下我以下使用的命令,你应该很快就可以判定pid和address是从哪里来的了,我的命令是:

1.     shell malloc_history 596 0×5f3ef80

再次运行,程序crash时会出现大量的stack trace信息,如下图是与本程序相关的:

根据这些信息大家就可以找到问题出现在[BadAccessViewController viewDidLoad]中与 +[NSString stringWithFormat:] 有关的地方.

最后大家记得把环境变量NSZombieEnabled,MallocStackLogging删除或设置为NO,因为它们会使得内存不会被释放.

3、设置全局断点快速定位问题代码所在行

XCode调试技巧–设置全局断点快速定位问题代码所在行[zz]

小结：XCode调试技巧之EXC_BAD_ACCESS中BUG解决的内容介绍完了，希望本文对你有所帮助！