㈠ 怎样正确做 Web 应用的压力测试
你好，一个完整的压力测试需要关注三个方面：如何正确产生压力、如何定位瓶颈、如何预估系统的承载能力
(1)
首先说一下如何产生压力，产生压力的方法有很多，通常可以写脚本产生压力机器人对服务器进行发包和收包操作，也可以使用现有的工具(像jmeter、LoadRunner这些），所以说产生压力其实并不难，难点在于产生的压力是不是真实地反映了实际用户的操作场景。举个例子来说，对游戏来说单纯的并发登陆场景在整个线上环境中的占比可能并不大(新开服等特殊情况除外)，相反“登陆-开始战斗-结束战斗”、不同用户执行不同动作这种“混合模式”占了更大的比重。所以如何从实际环境中提炼出具体的场景比重，并且把这种比重转化成实际压力是一个重要的关注点。
(2)
产生压力之后，通常我们可以拿到TPS、响应时延等性能数据，那么如何定位性能问题呢？TPS、响应时延只能告诉你服务器是否存在问题，但不能帮助你定位问题。这些表面背后是整个后台处理逻辑综合作用的结果，这时候可以先关注系统的CPU、内存、IO、网络，对比在tps、时延达到瓶颈时这些系统数据的情况，确定性能问题是系统哪一部分造成的，然后再回到代码的逻辑中逐个优化这些点。
(3)
当服务器的整体性能就可以相对稳定下来，这时候就需要对自己服务器的承载能力有一个预估，通过产生真实压力、对比系统数据，大致可以对单套系统的处理能力有个真实的评价，然后结合业务规模配置服务器数量。
㈡ 关于Web系统的压力测试
压力测试没有一个固定的数值，一般凭经验或客户要求。
压力测试不达标一般是2种情况。
1.程序出现异常，大量数据的读写可能会出现代码或数据库的异常。根据异常的不同修改就是了。
2.效率低下。就是程序不会有问题就是执行时间太长了，这个需要改善就麻烦了，一般从SQL语句上节省数据库访问次数，再就是从逻辑上避免多重循环等方法解决。
-------------------------------------------
大公司的话一般设有专门的测试人员，现在这个领域还没有专门的书籍或标准，基本都时凭借经验。
㈢ web压力测试 要测试哪些方面
web压力测试通过产生真实压力来发现问题需要关注以下方面：
1、对要测试的系统进行分析，明确需要对哪一块做压力测试。比如：淘宝网站双十一期间，秒杀跟支付，此模式用户操作中占比比较大
再比如：游戏，登录--开始战斗--结束战斗这种混合模式在用户操作中占比较大
那么就可以针对这种占比比较大的模式进行压力测试
2、明确了要测试的点后，如何对这些测试点进行施压呢？
第一种方式可以通过写脚本产生压力机器人对服务器进行发包收包操作；
第二种方式就是借助一些压力测试工具如:JMeter或LoadRunner
3、如何对这些测试点进行正确的施压呢？
那么就需要用压力测试工具或者其它方法来录制脚本，模拟用户的操作
4、对测试点该施加多大的压力比较合适？该施加多少的数据才能找出系统的瓶颈？
那么就需要明确压力测试所限制的数量，即用户并发量，这里分3种情况来明确：
1）根据上级的明确规定数量，来设定最确大值，然后根据情况往上或往下增减
2）上级未规定，由自己判断，从1开始慢慢递增。如：1，5，10，20等等
3）若做过压力测试，则可以根据上次的压力测试结果为基数进行测试
5、测试完之后，如何通过这些数据来定位性能问题呢？
虽然通过这些测试结果我们可以得到TPS(吞吐量)，平均响应时间等这些数据，可判断出服务器是否存在问题，但却不能定位问题。
㈣ 压力测试是什么原理
压力测试的原理是：
给软件不断加压，强制其在极限的情况下运行，观察它可以运行到何种程度，从而发现性能缺陷，是通过搭建与实际环境相似的测试环境，通过测试程序在同一时间内或某一段时间内，向系统发送预期数量的交易请求、测试系统在不同压力情况下的效率状况，以及系统可以承受的压力情况。
然后做针对性的测试与分析，找到影响系统性能的瓶颈，评估系统在实际使用环境下的效率情况，评价系统性能以及判断是否需要对应用系统进行优化处理或结构调整。并对系统资源进行优化。
(4)web压力测试原理扩展阅读：
软件压力测试是一种基本的质量保证行为，它是每个重要软件测试工作的一部分。软件压力测试的基本思路很简单：不是在常规条件下运行手动或自动测试，而是在计算机数量较少或系统资源匮乏的条件下运行测试。通常要进行软件压力测试的资源包括内部内存、CPU 可用性、磁盘空间和网络带宽。
负载测试是通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足性能指标的情况下，系统所能承受的最大负载量的测试。其中还有一种特定类型的负载测试，它是通过逐步增加软件系统的负载，测试系统性能的变化，并最终确定在什么负载条件下系统性能处于失效状态，以此来获得系统提供的最大服务级别。
并发性能测试通过逐渐增加并发用户数负载，直到系统的瓶颈或者不能接收的状态，综合分析交易执行指标、资源监控指标等来确定系统并发性能的过程。并发性能测试是负载压力测试的重要内容。
㈤ 如何正确的做WEB端的压力测试
1、对要测试的系统进行分析，明确需要对哪一块做压力测试。比如：淘宝网站双十一期间，秒杀跟支付，此模式用户操作中占比比较大
再比如：游戏，登录--开始战斗--结束战斗这种混合模式在用户操作中占比较大
那么就可以针对这种占比比较大的模式进行压力测试
2、明确了要测试的点后，如何对这些测试点进行施压呢？
第一种方式可以通过写脚本产生压力机器人对服务器进行发包收包操作；
第二种方式就是借助一些压力测试工具如:J
㈥ 怎样正确做 Web 应用的压力测试
可以看下腾讯wetest的这个压测工具http://wetest.qq.com/gaps/
通过产生真实压力来发现问题、结合系统性能来解决问题
㈦ 压力测试的软件的基本工作原理是什么
比较有代表性的一个工具，Loadrunner。
LoadRunner是 Mercury Interactive的一款 性能测试 工具，也是目前应用最为广泛的性能测试工具之一。该工具通过模拟上千万用户实施并发负载，实时性能监控的系统行为和性能方式来确认和查找问题。
一、 LoadRunner 工具组成
1、虚拟用户脚本生成器：捕获最终用户业务流程和创建自动性能测试脚本，即我们在以后说的产生测试脚本；
2、压力产生器：通过运行虚拟用户产生实际的负载；
3、用户代理：协调不同负载机上虚拟用户，产生步调一致的虚拟用户；
4、压力调度：根据用户对场景的设置，设置不同脚本的虚拟用户数量；
5、监视系统：监控主要的性能计数器；
6、压力结果分析工具：本身不能代替分析人员，但是可以辅助测试结果的分析。
二、LoadRunner工具原理
代理（Proxy）是客户端和服务器端之间的中介人，LoadRunner就是通过代理方式截获客户端和服务器之间交互的数据流。
1）虚拟用户脚本生成器通过代理方式接收客户端发送的数据包，记录并将其转发给服务器端；接收到从服务器端返回的数据流，记录并返回给客户端。
这样服务器端和客户端都以为在一个真实运行环境中，虚拟脚本生成器能通过这种方式截获数据流；虚拟用户脚本生成器在截获数据流后对其进行了协议层上的处理，最终用脚本函数将数据流交互过程体现为我们容易看懂的脚本语句。
2）压力生成器则是根据脚本内容，产生实际的负载，扮演产生负载的角色。
3）用户代理是运行在负载机上的进程，该进程与产生负载压力的进程或是线程协作，接受调度系统的命令，调度产生负载压力的进程或线程。
4）压力调度是根据用户的场景要求，设置各种不同脚本的虚拟用户数量，设置同步点等。
5）监控系统则可以对 数据库 、应用服务器、服务器的主要性能计数器进行监控。
6）压力结果分析工具是辅助测试结果分析。
QQ：695210708
㈧ 网站压力测试原理
压力测试就是这样啊，直到测试到系统崩溃就是多少人同时登录的上限
㈨ 怎样正确做 Web 应用的压力测试
一个完整的压力测试需要关注三个方面：如何正确产生压力、如何定位瓶颈、如何预估系统的承载能力
(1) 首先说一下如何产生压力，产生压力的方法有很多，通常可以写脚本产生压力机器人对服务器进行发包和收包操作，也可以使用现有的工具(像jmeter、LoadRunner这些），所以说产生压力其实并不难，难点在于产生的压力是不是真实地反映了实际用户的操作场景。举个例子来说，对游戏来说单纯的并发登陆场景在整个线上环境中的占比可能并不大(新开服等特殊情况除外)，相反“登陆-开始战斗-结束战斗”、不同用户执行不同动作这种“混合模式”占了更大的比重。所以如何从实际环境中提炼出具体的场景比重，并且把这种比重转化成实际压力是一个重要的关注点。
(2) 产生压力之后，通常我们可以拿到TPS、响应时延等性能数据，那么如何定位性能问题呢？TPS、响应时延只能告诉你服务器是否存在问题，但不能帮助你定位问题。这些表面背后是整个后台处理逻辑综合作用的结果，这时候可以先关注系统的CPU、内存、IO、网络，对比在tps、时延达到瓶颈时这些系统数据的情况，确定性能问题是系统哪一部分造成的，然后再回到代码的逻辑中逐个优化这些点。
(3) 当服务器的整体性能就可以相对稳定下来，这时候就需要对自己服务器的承载能力有一个预估，通过产生真实压力、对比系统数据，大致可以对单套系统的处理能力有个真实的评价，然后结合业务规模配置服务器数量。
㈩ 白帽子讲Web安全的前言
在2010年年中的时候，博文视点的张春雨先生找到我，希望我可以写一本关于云计算安全的书。当时云计算的概念正如日中天，但市面上关于云计算安全应该怎么做却缺乏足够的资料。我由于工作的关系接触这方面比较多，但考虑到云计算的未来尚未清晰，以及其他的种种原因，婉拒了张春雨先生的要求，转而决定写一本关于Web安全的书。 我对安全的兴趣起源于中学时期。当时在盗版市场买到了一本没有书号的黑客手册，其中coolfire 的黑客教程令我印象深刻。此后在有限的能接触到互联网的机会里，我总会想方设法地寻找一些黑客教程，并以实践其中记载的方法为乐。
在2000年的时候，我进入了西安交通大学学习。在大学期间，最大的收获，是学校的计算机实验室平时会对学生开放。当时上网的资费仍然较贵，父母给我的生活费里，除了留下必要的生活所需费用之外，几乎全部投入在这里。也是在学校的计算机实验室里，让我迅速在这个领域中成长起来。
大学期间，在父母的资助下，我拥有了自己的第一台个人电脑，这加快了我成长的步伐。与此同时，我和一些互联网上志同道合的朋友，一起建立了一个技术型的安全组织，名字来源于我当时最喜爱的一部动漫：“幻影旅团”。历经十余载，“幻影”由于种种原因未能得以延续，但它却曾以论坛的形式培养出了当今安全行业中非常多的顶尖人才。这也是我在这短短二十余载人生中的最大成就与自豪。
得益于互联网的开放性，以及我亲手缔造的良好技术交流氛围，我几乎见证了全部互联网安全技术的发展过程。在前5年，我投入了大量精力研究渗透测试技术、缓冲区溢出技术、网络攻击技术等；而在后5年，出于工作需要，我把主要精力放在了对Web安全的研究上。 发生这种专业方向的转变，是因为在2005年，我在一位挚友的推荐下，加入了阿里巴巴。加入的过程颇具传奇色彩，在面试的过程中主管要求我展示自己的能力，于是我远程关闭了阿里巴巴内网上游运营商的一台路由设备，导致阿里巴巴内部网络中断。事后主管立即要求与运营商重新签订可用性协议。
大学时期的兴趣爱好，居然可以变成一份正经的职业（当时很多大学都尚未开设网络安全的课程与专业），这使得我的父母很震惊，同时也更坚定了我自己以此作为事业的想法。
在阿里巴巴我很快就崭露头角，曾经在内网中通过网络嗅探捕获到了开发总监的邮箱密码；也曾经在压力测试中一瞬间瘫痪了公司的网络；还有好几次，成功获取到了域控服务器的权限，从而可以以管理员的身份进入任何一位员工的电脑。
但这些工作成果，都远远比不上那厚厚的一摞网站安全评估报告让我更有成就感，因为我知道，网站上的每一个漏洞，都在影响着成千上万的用户。能够为百万、千万的互联网用户服务，让我倍感自豪。当时，Web正在逐渐成为互联网的核心，Web安全技术也正在兴起，于是我义无返顾地投入到对Web安全的研究中。
我于2007年以23岁之龄成为了阿里巴巴集团最年轻的技术专家。虽未有官方统计，但可能也是全集团里最年轻的高级技术专家，我于2010年获此殊荣。在阿里巴巴，我有幸见证了安全部门从无到有的建设过程。同时由于淘宝、支付宝草创，尚未建立自己的安全团队，因此我有幸参与了淘宝、支付宝的安全建设，为他们奠定了安全开发框架、安全开发流程的基础。 当时，我隐隐地感觉到了互联网公司安全，与传统的网络安全、信息安全技术的区别。就如同开发者会遇到的挑战一样，有很多问题，不放到一个海量用户的环境下，是难以暴露出来的。由于量变引起质变，所以管理10台服务器，和管理1万台服务器的方法肯定会有所区别；同样的，评估10名工程师的代码安全，和评估1000名工程师的代码安全，方法肯定也要有所不同。
互联网公司安全还有一些鲜明的特色，比如注重用户体验、注重性能、注重产品发布时间，因此传统的安全方案在这样的环境下可能完全行不通。这对安全工作提出了更高的要求和更大的挑战。
这些问题，使我感觉到，互联网公司安全可能会成为一门新的学科，或者说应该把安全技术变得更加工业化。可是我在书店中，却发现安全类目的书，要么是极为学术化的（一般人看不懂）教科书，要么就是极为娱乐化的（比如一些“黑客工具说明书”类型的书）说明书。极少数能够深入剖析安全技术原理的书，以我的经验看来，在工业化的环境中也会存在各种各样的问题。
这些问题，也就促使我萌发了一种写一本自己的书，分享多年来工作心得的想法。它将是一本阐述安全技术在企业级应用中实践的书，是一本大型互联网公司的工程师能够真正用得上的安全参考书。因此张春雨先生一提到邀请我写书的想法时，我没有做过多的思考，就答应了。
Web是互联网的核心，是未来云计算和移动互联网的最佳载体，因此Web安全也是互联网公司安全业务中最重要的组成部分。我近年来的研究重心也在于此，因此将选题范围定在了Web安全。但其实本书的很多思路并不局限于Web安全，而是可以放宽到整个互联网安全的方方面面之中。
掌握了以正确的思路去看待安全问题，在解决它们时，都将无往而不利。我在2007年的时候，意识到了掌握这种正确思维方式的重要性，因此我告知好友：安全工程师的核心竞争力不在于他能拥有多少个0day，掌握多少种安全技术，而是在于他对安全理解的深度，以及由此引申的看待安全问题的角度和高度。我是如此想的，也是如此做的。
因此在本书中，我认为最可贵的不是那一个个工业化的解决方案，而是在解决这些问题时，背后的思考过程。我们不是要做一个能够解决问题的方案，而是要做一个能够“漂亮地”解决问题的方案。这是每一名优秀的安全工程师所应有的追求。 然而在当今的互联网行业中，对安全的重视程度普遍不高。有统计显示，互联网公司对安全的投入不足收入的百分之一。
在2011年岁末之际，中国互联网突然卷入了一场有史以来最大的安全危机。12月21日，国内最大的开发者社区CSDN被黑客在互联网上公布了600万注册用户的数据。更糟糕的是，CSDN在数据库中明文保存了用户的密码。接下来如同一场盛大的交响乐，黑客随后陆续公布了网易、人人、天涯、猫扑、多玩等多家大型网站的数据库，一时间风声鹤唳，草木皆兵。
这些数据其实在黑客的地下世界中已经辗转流传了多年，牵扯到了一条巨大的黑色产业链。这次的偶然事件使之浮出水面，公之于众，也让用户清醒地认识到中国互联网的安全现状有多么糟糕。
以往类似的事件我都会在博客上说点什么，但这次我保持了沉默。因为一来知道此种状况已经多年，网站只是在为以前的不作为而买单；二来要解决“拖库”的问题，其实是要解决整个互联网公司的安全问题，远非保证一个数据库的安全这么简单。这不是通过一段文字、一篇文章就能够讲清楚的。但我想最好的答案，可以在本书中找到。
经历这场危机之后，希望整个中国互联网，在安全问题的认识上，能够有一个新的高度。那这场危机也就物有所值，或许还能借此契机成就中国互联网的一场安全启蒙运动。
这是我的第一本书，也是我坚持自己一个人写完的书，因此可以在书中尽情地阐述自己的安全世界观，且对书中的任何错漏之处以及不成熟的观点都没有可以推卸责任的借口。
由于工作繁忙，写此书只能利用业余时间，交稿时间多次推迟，深感写书的不易。但最终能成书，则有赖于各位亲朋的支持，以及编辑的鼓励，在此深表感谢。本书中很多地方未能写得更为深入细致，实乃精力有限所致，尚请多多包涵。 在安全圈子里，素有“白帽”、“黑帽”一说。
黑帽子是指那些造成破坏的黑客，而白帽子则是研究安全，但不造成破坏的黑客。白帽子均以建设更安全的互联网为己任。
我于2008年开始在国内互联网行业中倡导白帽子的理念，并联合了一些主要互联网公司的安全工程师，建立了白帽子社区，旨在交流工作中遇到的各种问题，以及经验心得。
本书名为《白帽子讲Web安全》，即是站在白帽子的视角，讲述Web安全的方方面面。虽然也剖析攻击原理，但更重要的是如何防范这些问题。同时也希望“白帽子”这一理念，能够更加的广为人知，为中国互联网所接受。 全书分为4大篇共18章，读者可以通过浏览目录以进一步了解各篇章的内容。在有的章节末尾，还附上了笔者曾经写过的一些博客文章，可以作为延伸阅读以及本书正文的补充。
第一篇 我的安全世界观是全书的纲领。在此篇中先回顾了安全的历史，然后阐述了笔者对安全的看法与态度，并提出了一些思考问题的方式以及做事的方法。理解了本篇，就能明白全书中所涉及的解决方案在抉择时的取舍。
第二篇 客户端脚本安全就当前比较流行的客户端脚本攻击进行了深入阐述。当网站的安全做到一定程度后，黑客可能难以再找到类似注入攻击、脚本执行等高风险的漏洞，从而可能将注意力转移到客户端脚本攻击上。
客户端脚本安全与浏览器的特性息息相关，因此对浏览器的深入理解将有助于做好客户端脚本安全的解决方案。
如果读者所要解决的问题比较严峻，比如网站的安全是从零开始，则建议跳过此篇，先阅读下一篇“服务器端应用安全”，解决优先级更高的安全问题。
第三篇 服务器端应用安全就常见的服务器端应用安全问题进行了阐述。这些问题往往能引起非常严重的后果，在网站的安全建设之初需要优先解决这些问题，避免留下任何隐患。
第四篇 互联网公司安全运营提出了一个大安全运营的思想。安全是一个持续的过程，最终仍然要由安全工程师来保证结果。
在本篇中，首先就互联网业务安全问题进行了一些讨论，这些问题对于互联网公司来说有时候会比漏洞更为重要。
在接下来的两章中，首先阐述了安全开发流程的实施过程，以及笔者积累的一些经验。然后谈到了公司安全团队的职责，以及如何建立一个健康完善的安全体系。
本书也可以当做一本安全参考书，读者在遇到问题时，可以挑选任何所需要的章节进行阅读。 感谢我的妻子，她的支持是对我最大的鼓励。本书最后的成书时日，是陪伴在她的病床边完成的，我将铭记一生。
感谢我的父母，是他们养育了我，并一直在背后默默地支持我的事业，使我最终能有机会在这里写下这些话。
感谢我的公司阿里巴巴集团，它营造了良好的技术与实践氛围，使我能够有今天的积累。同时也感谢在工作中一直给予我帮助和鼓励的同事、上司，他们包括但不限于：魏兴国、汤城、刘志生、侯欣杰、林松英、聂万全、谢雄钦、徐敏、刘坤、李泽洋、肖力、叶怡恺。
感谢季昕华先生为本书作序，他一直是所有安全工作者的楷模与学习的对象。
也感谢博文视点的张春雨先生以及他的团队，是他们的努力使本书最终能与广大读者见面。他们的专业意见给了我很多的帮助。
最后特别感谢我的同事周拓，他对本书提出了很多有建设性的意见。
吴翰清
2012年1月于杭州