基于Web开发资料专集
本专集包含的内容如下：
[color=#008B8B] 网页设计制作标准规范
[color=#008B8B] 网站工程的管理与规范
[color=#008B8B] 网站项目管理规范手册
[color=#008B8B] 网站软件开发规范(某门户网站的)
[color=#008B8B] 网站制作规范
[color=#008B8B] Web 测试的经验
[color=#008B8B] Web测试手段
[color=#008B8B] 对Web服务进行压力测试
[color=#008B8B] 基于Web的系统测试方法
[color=#008B8B] Web下的整体测试
[color=#008B8B] 网站测试技术简介
[color=#008B8B] WEB应用程序测试方法和测试技术详述
[color=#0000FF] 网页设计制作标准规范
// 总 论
本规范既是一个开发规范，也是一个脚本语言参考，本规范并不是一个一成不变的必须严格遵守的条文，特殊情况下要灵活运用，做一定的变通。但是，请大家千万不要随意更改规范。如果有任何问题，请及时与我联系，我会及时更改本规范的相关代码样例和文档。
/ 基 本 要 求
1. 在网站根目录中开设images、common、temp 三个子目录，根据需要再开设media 子目录，images目录中放不同栏目的页面都要用到的公共图片，例如公司的标志、banner 条、菜单、按钮等等；common 子目录中放css、js、php、include 等公共文件；temp 子目录放客户提供的各种文字图片等等原始资料；media 子目录中放flash、avi、quick time 等多媒体文件 。
2. 在根目录中原则上应该按照首页的栏目结构，给每一个栏目开设一个目录，根据需要在每一个栏目的目录中开设一个images 和media 的子目录用以放置此栏目专有的图片和多媒体文件，如果这个栏目的内容特别多，又分出很多下级栏目，可以相应的再开设其他目录。
3. temp 目录中的文件往往会比较多，建议以时间为名称开设目录，将客户陆续提供的资料归类整理。
4. 除非有特殊情况，目录、文件的名称全部用小写英文字母、数字、下划线的组合，其中不得包含汉字、空格和特殊字符；目录的命名请尽量以英文为指导，不到万不得已不要以拼音作为目录名称，经验证明，用拼音命名的目录往往连一个月后的自己都看不懂，
/ 脚 本 编 写
我们应该有一个脚本整体风格一致的概念，意思是一个月后和一个月前的你写的脚本风格保持一致，以及同一个工作组中不同的开发人员编写的脚本风格保持一致，因为我们不可能永远孤立的开发，你随时都有可能和三个月前的自己合作（你的客户要求改版），也经常要和工作室中不同的同事共同开发一个项目，还有可能被要求修改已经离职人员开发的脚本，当然你自己也有可能会扔下一个项目给后来的同事。
1. html 文件的通用模板：
<html>
<!--
Generator: Sub Design Studio
Creation Data: 2005-8-1
Original Author:
-->
<head>
<title> 文档标题 </title>
<meta http-equiv="content-type" content="text/html; charset=gb2312">
<meta name="author" content="eastline">
其他meta 标 记
<link rel="stylesheet" type="text/css" href="style/style.css">
样式表定义
客户端Javascript 函数定义及初始化操作
</head>
<body bgcolor="#ffffff">
… …
</body>
补充：
为了保证网站能够与下一代的web 语言xml 标准兼容，所有的HTML 标签的属性都要用单引号或者双引号括起，即我们应该写 <a href="url"> 而不 是 <a href=url>.
2. 允许全文检索的页面，为了使Internet 上的搜索引擎能够有效检索，在频道的首页的html的<head></head>之间应该加入Keywords 和Description 元标记，例如：
<meta name=”keywords” content=”东方新干线，汽车，买车”>
<meta name=”description” content=”东方新干劲线，全球中文汽车信息第一站”>
3. CSS 文件的格式样例代码：
<style type="text/css">
<!—
p { text-indent: 2em; }
body { font-family: "宋体"; font-size: 9pt; color: #000000; margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px}
table { font-family: "宋体"; font-size: 9pt; line-height: 20px; color: #000000}
a:link { font-size: 9pt; color: #FFFFFF; text-decoration: none}
a:visited { font-size: 9pt; color: #99FFFF; text-decoration: none}
a:hover { font-size: 9pt; color: #FF9900; text-decoration: none}
a:active { font-size: 9pt; color: #FF9900; text-decoration: none}
a.1:link { font-size: 9pt; color: #3366cc; text-decoration: none}
a.1:visited { font-size: 9pt; color: #3366cc; text-decoration: none}
a.1:hover { font-size: 9pt; color: #FF9900; text-decoration: none}
a.1:active { font-size: 9pt; color: #FF9922; text-decoration: none}
.blue { font-family: "宋体"; font-size: 10.5pt; line-height: 20px; color: #0099FF; letter-spacing: 5em}
-->
</style>
这里尤其要注意的是a:link a:visited a:hover a:actived 的排列顺序一定要严格照上面的样例代码，否则或多或少会出问题。另外我们规定重定义的最先，伪类其次，自定义最后，便于自己和他人阅读！
为了保证不同浏览器上字号保持一致，字号建议用点数pt和像素px来定义，pt一般使用中文宋体的9pt 和11pt，px一般使用中文宋体12px 和14.7px 这是经过优化的字号，黑体字或者宋体字加粗时，一般选用11pt 和14.7px 的字号比较合适。
在写 <table> 互相嵌套时，严格按照的规范，对于单独的一个<table>来说，<table><tr>对齐，<td> 缩进两个半角空格，<td> 中如果还有嵌套的表格?lt;table>也缩进两个半角空格，如果<td>中没有任何嵌套的表格，</td> 结束标记应该与 <td> 处于同一行，不要换行，
如我们注意在源代码中不应有这样的代码：
<td><img src="../images/sample.gif">
</td>
而应该是这样的：
<td><img src="../images/sample.gif"></td>
这是因为浏览器认为换行相当于一个半角空格，以上不规范的写法相当于无意中增加一个半角空格，如果确实有必要增加一个半角空格，也应该这样写：
<td><img src="../images/sample.gif"> </td>
属于同一个级别 的 <table> 一定是左首对齐的，另外不允许没有任何内容的空的单元格存在，高度大于等于12px 的单元格应该 在 <td> 和 </td> 之间写一 个 如果高度小于12px, 则应该 在 <td> 和 </td> 之间插入一个1*1 大小的透明的gif 图片，这是因为某些浏览器认为空单元格非法而不会予以解释。如果代码顺序较乱，在DW3中可以通过command->apply souce formatting进行重新整理！
5. width 和height 的写法也有统一的规范，一般情况下只有一列的表格，width 写在<table> 的标签内，只有一行的表格，height 写在 <table> 的标签内，多行多列的表格，width 和height 写在第一行或者第一列的 <td> 标签内。总之遵循一条原则：不出现多于一个的控制同一个单元格大小的height 和width, 保证任何一个width 和height 都是有效的，也就是你改动代码中任何一个width 和height 的数值，都应该在浏览器中看到变化。做到这一条不容易，需要较长时间的练习和思考。
/ 一 般 原 则
1. 在排布表格之前，请大家一定要好好思考一个最佳的方案，表格的嵌套尽量控制在三层以内，并且应该尽量避免 <colspan> <rowspan> 两个标记，经验表明，这两个标记会带来许多麻烦。
2. 一个网页要尽量避免用整个一张大表格，所有的内容都嵌套在这个大表格之内，因为浏览器在解释页面的元素时，是以表格为单位逐一显示，如果一张网页是嵌套在一个大表格之内，那么很可能造成的后果就是，当浏览者敲入网址，他要先面对一片空白很长时间，然后所有的网页内容同时出现。如果必须这样做，请使用 <tbody>标记，以便能够使这个大表格分块显示。
3. 排版中我们经常会遇到需要进行首行缩进的处理，不要使用 或者全角空格来达到效果，规范的做法是在样式表中定义 p { text-indent: 2em; } 然后给每一段加上 <p> 标记，注意，一般情况下，请不要省略 </p> 结束标记 。
4. 原则上，我们禁止用 <img width=? height=?> 来人为干预图片显示的尺寸，而且建议 <img> 标签中不要带上width 和height 两个属性，这是因为制作过程中，图片往往需要反复的修改，这样可以避免人为干预图片显示的尺寸，尽可能的发挥浏览器自身的功能；但是这样的一个副作用是当网页还未加载图片时，不会留出图片的站位大小，可能会造成网页在加载过程中抖动（如果图片是插在一个固定大小的表格里的，不会有这个现象），尤其是当图片的尺寸较大时，这种现象会很明显，所以当预料到这种会明显导致网页抖动的情况会发生时，请大家务必在最后给 <img>附上 width 和 height 属性。
5. 为了最大程度的发挥浏览器自动排版的功能，在一段完整的文字中请尽量不要使用<br> 来人工干预分段。
6. 不同语种的文字之间应该有一个半角空格，但避头的符号之前和避尾的符号之后除外汉字之间的标点要用全角标点，英文字母和数字周围的括号应该使用半角括号。
7. 所有的字号都应该用样式表来实现，禁止在页面中出现 <font size=?> 标记。
8. 请不要在网页中连续出现多于一个 的 也尽量少使用全角空格（英文字符集下，全角空格会变成乱码），空白应该尽量使用 text-indent, padding, margin, hspace, vspace 以及透明的gif 图片来实现。
9. 中英文混排时，我们尽可能的将英文和数字定义为verdana 和arial 两种字体。
10. 行距建议用百分比来定义，常用的两个行距的值是line-height:120%/150%.
11. 网站中的路径全部采用相对路径，一般链接到某一目录下的缺省文件的链接路径不必写全名，如我们不必这样：<a href="aboutus/index.htm"> 而应该这样：<a href="aboutus/">
12、嵌入图形文本的使用较大的字体，建议不要在图形中包括文本。
13、“网页大小”定义为网页的所有文件大小的总和，包括HTML文件和所有的嵌入的对象。用户喜欢快的而不是新奇的站点。对于解调器用户，网页大小保持在34K以下为合适。
/ 文 件 命 名 原 则
1. 每一个目录中应该包含一个缺省的html 文件，文件名统一用index.htm
2. 文件名称统一用小写的英文字母、数字和下划线的组合。
3. 命名原则的指导思想一是使得你自己和工作组的每一个成员能够方便的理解每一个文件的意义，二是当我们在文件夹中使用“按名称排例”的命令时，同一种大类的文件能够排列在一起，以便我们查找、修改、替换、计算负载量等等操作 。
4. 下面以“新闻”（包含“国内新闻”和“国际新闻”）这个栏目来说明html 文件的命名原则：
在根目录下开设news目录
第一条缺省新闻取名index.htm
所有属于“国内新闻”的新闻依次取名为：china_1.htm, china_2.htm, …
所有属于“国际新闻”的新闻依次取名为：internation_1.htm, internation _2.htm, …
如果文件的数量是两位数，请将前九个文件命名为：china_01.htm, china_02.htm 以保证所有的文件能够在文件夹中正确排序。
5. 图片的命名原则遵循以下几条规范：
名称分为头尾两两部分，用下划线隔开。
头部分表示此图片的大类性质，例如广告、标志、菜单、按钮等等。
一般来说:
放置在页面顶部的广告、装饰图案等长方形的图片我们取名：banner
标志性的图片我们取名为：logo
在页面上位置不固定并且带有链接的小图片我们取名为button
在页面上某一个位置连续出现，性质相同的链接栏目的图片我们取名：menu
装饰用的照片我们取名：pic
不带链接表示标题的图片我们取名：title
依照此原则类推。
尾部分用来表示图片的具体含义。
下面是几个样例，大家应该能够一眼看明白图片的意义：
banner_sohu.gif banner_sina.gif menu_aboutus.gif menu_job.gif title_news.gif logo_police.gif logo_national.gif pic_people.jpg pic_hill.jpg.
[color=#0000FF] 网站工程的管理与规范
导读
随着网络的发展，网站建设和制作已初步形成一个行业，本文尝试就这个行业的管理和规范提出网站工程的概念，并系统介绍了整个网站建设的过程以及过程中的问题的解决办法。纯属作者自己的见解和经验，供广大网站设计制作人员，网站系统分析员和项目经理借鉴。
--------------------------------------------------------------------------
随着互联网的发展，网站制作作为一个行业已经悄悄的兴起，越来越多的网站制作任务需要网页制作公司完成，越来越多的问题出现在网站制作的过程中。例如：不能按期完成制作，不能使客户满意，费用超出预算等等。仔细分析原因，发现大部分失败的原因有以下几点：
a.忽视客户的不断变化的需求；
b.没有保留历史文档作决策参考；
c.忽视监督项目进度；
d.忽视不断的测试和修改；
e.没有使用专业的项目管理软件，靠主观决策。
问题发现了，有没有一个好的解决办法可以减少失误，控制和管理网站制作呢？
网站开发制作是一个很复杂的工作，可以将它看做一个项目来管理。作者参考了国际国内有关项目管理的资料，发现软件工程的管理方法和规范与网站建设项目最接近，因此我们在仔细研究软件工程后，针对网站建设的特点和重点，整理出一套网站建设管理和控制的方法，定名为网站工程(WebSite Project简称WP )。
网站工程
什么是网站工程，简单的说就是网站项目的管理和控制方法；是一种特殊的，标准的操作程序。建立网站工程的目的在于保证网站建设的高效率，高质量，低风险。
网站工程标准的实行，不但使客户得益，更使得网站制作行业趋向规范化，它将对行业相关的每个人都有益，包括项目经理，网页设计师，程序员和编辑。
下面，就按照一个项目从洽谈到提交完成的顺序来介绍：
1.项目立项/客户的需求说明书
1.1.项目立项
我们接到客户的业务咨询，经过双方不断的接洽和了解，并通过基本的可行性讨论够，初步达成制作协议，这时就需要将项目立项。较好的做法是成立一个专门的项目小组，小组成员包括：项目经理，网页设计，程序员，测试员，编辑/文档等必须人员。项目实行项目经理制。
1.2.客户的需求说明书
第一步是需要客户提供一个完整的需求说明。很多客户对自己的需求并不是很清楚，需要您不断引导和帮助分析。曾经有一次，我问客户：“您做网站的目的是什么？”他回答：“没有目的，只是因为别人都有，我没有！”。这样的客户就需要耐心说明，仔细分析，挖掘出他潜在的，真正的需求。
配合客户写一份详细的，完整的需求说明会花很多时间，但这样做是值得的，而且一定要让客户满意，签字认可。把好这一关，可以杜绝很多因为需求不明或理解偏差造成的失误和项目失败。糟糕的需求说明不可能有高质量的网站。那么需求说明书要达到怎样的标准呢？简单说，包含下面几点：
a.正确性：每个功能必须清楚描写交付的功能；
b.可行性：确保在当前的开发能力和系统环境下可以实现每个需求；
c.必要性：功能是否必须交付，是否可以推迟实现，是否可以在削减开支情况发生时"砍"掉；
d.简明性：不要使用专业的网络术语；
e.检测性：如果开发完毕，客户可以根据需求检测。
2.网站总体设计
在拿到客户的需求说明后，并不是直接开始制作，而是需要对项目进行总体设计，详细设计，出一份网站建设方案给客户。总体设计是非常关键的一步。它主要确定：
a.网站需要实现哪些功能；
b.网站开发使用什么软件，在什么样的硬件环境；
c.需要多少人，多少时间；
d.需要遵循的规则和标准有哪些。
同时需要写一份总体规划说明书，包括：
a.网站的栏目和版块；
b.网站的功能和相应的程序；
c.网站的链接结构；
d.如果有数据库，进行数据库的概念设计；
e.网站的交互性和用户友好设计。
在总体设计出来后，一般需要给客户一个网站建设方案。很多网页制作公司在接洽业务时就被客户要求提供方案。那时的方案一般比较笼统，而且在客户需求不是十分明确的情况下提交方案，往往和实际制作后的结果会有很大差异。所以应该尽量取得客户的理解，在明确需求并总体设计后提交方案，这样对双方都有益处。网站建设方案的包括以下几个部分：
a.客户情况分析；
b.网站需要实现的目的和目标；
c.网站形象说明；
d.网站的栏目版块和结构；
e.网站内容的安排，相互链接关系；
f.使用软件，硬件和技术分析说明；
g.开发时间进度表；
h.宣传推广方案；
i.维护方案；
j.制作费用；
k.本公司简介：成功作品，技术，人才说明等。
当您的方案通过客户的认可，那么恭喜你！您可以开始动手制作网站了。但还不是真正意义上的制作，你需要进行详细设计。
附：国外网站的定价方法
如何制定网站价格？对于那些小企业，价格开得太高，他们会吓跑，开的太低，自己得不到利润。由于行业竞争的无序性，国内现在的价格千奇百怪，有1000元制作整个商务网站的，也有2000元一页的快刀斩客。国外网页制作公司是如何指定网站制作价格的呢？
首先是根据员工工资，各项费用，利润率来计算每小时工作成本，即：总价 = 工资 + 费用 + 利润
举例说明：
假设公司的月支付工资为5000元，费用为5000元，希望的利润率为20%,一月工作时间为22*8=176小时，根据调查，一般网页制作公司有20-40%时间为非工作时间。实际工作的时间为
176*(1-25%)=132
所以，每工作小时成本是：
(5000+5000)*(1+20%) / 132 =90.90元
当你了解了每小时工作成本，开价格就心里有数了。国外常见报价方法分三种：套餐法，时间法，项目评估法。
套餐法：也称页面法，指定明确的页面数，图像数，链接数，功能等。这个办法最通用，但不是一个好办法，因为按照页面计价，解释很含糊 ：（
时间法：就是按照每小时成本计算。但是这种方法经常会遭到客户的质疑和拒绝，实行起来比较困难。
项目评估法：将整个项目拆成一个一个小工作，评估工作的技能难度，计算完成时间，再根据每小时成本计价。
网站详细设计
总体设计阶段以比较抽象概括的方式提出了解决问题的办法。详细设计阶段的任务就是把解法具体化。详细设计主要是针对程序开发部分来说的。但这个阶段的不是真正编写程序，而是设计出程序的详细规格说明。这种规格说明的作用很类似于其他工程领域中工程师经常使用的工程蓝图，它们应该 包含必要的细节，例如：程序界面，表单，需要的数据等。程序员可以根据它们写出实际的程序代码。(这里不详细展开说明)
1.整体形象设计
在程序员进行详细设计的同时，网页设计师开始设计网站的整体形象和首页。
整体形象设计包括标准字，Logo，标准色彩，广告语等。 首页设计包括版面，色彩，图像，动态效果，图标等风格设计，也包括banner，菜单，标题，版权等模块设计。首页一般设计1-3个不同风格，完成后，供客户选择。
记住：在客户确定首页风格之后，请客户签字认可。以后不得再对版面风格有大的变动，否则视为第二次设计。
2.开发制作
到这里，程序员和网页设计师同时进入全力开发阶段，需要提醒的是，测试人员需要随时测试网页与程序，发现Bug立刻记录并反馈修改。不要等到完全制作完毕再测试，这样会浪费大量的时间和精力。项目经理需要经常了解项目进度，协调和沟通程序员与网页设计师的工作。
3.调试完善
在网站初步完成后，上传到服务器，对网站进行全范围的测试。包括速度，兼容性，交互性，链接正确性，程序健壮性，超流量测试等，发现问题及时解决并记录下来。
为什么要记录文档呢？其实本软件工程本身就是一个文档，是一个不断充实和完善的标准。通过不断的发现问题，解决问题，修改，补充文档，使这个标准越来越规范，越来越工业化。进而使得网站开发趋向规范，趋向合理。
4.宣传推广
宣传推广的基本方法有：
a.网页里设置适当的META标签；
b.各搜索引擎登录；
c.准备新闻稿件在各新闻公告板发表；
d.合理使用Email邮件列表；
e.广告条交换；
f.付费广告。
至此，网站项目建设完毕，将有关网址，使用操作说明文档等提交客户验收。如果需要维护，另行签定维护项目。
(附)维护
网站成功推出后，长期的维护工作才刚刚开始，我们需要做到的是:
a.及时响应客户反馈；例如可以采取Email自动回复功能，然后在1-3个工作日里解决问题，再次回复；
b.网站流量统计分析和相应对策；
c.尽量推广和使用您的网址；
d.网站内容的及时更新和维护。
1.网站目录规范
目录建立的原则：以最少的层次提供最清晰简便的访问结构。
a.根目录。
b.每个语言版本存放于独立的目录；
c.每个主要功能(主菜单)建立一个相应的独立目录；
d.当页面超过20页，每个目录下存放各自独立images目录.共用的图片放在根目录下的images目录下；
e.所有的js文件存放在根目录下统一目录script；
f.所有的CSS文件存放在各语言版本下的style目录
g.所有的CGI程序存放在根目录并列目录cgi_bin目录
2.文件命名规范
3.链接结构规范
链接结构的原则：用最少的链接，使得浏览最有效率。
首页和一级页面之间用星状链接结构，一级和二级页面之间用树状链接结构。超过三级页面，在页面顶部设置导航条。
4.尺寸规范
a.页面标准按800*600分辨率制作，实际尺寸为778*434px
b.每个标准页面为A4幅面大小，即8.5X11英寸
c.大banner为468*60px，小banner为88*31px
必须加入的标签:
a.公司版权注释
b.网页显示字符集
简体中文：< META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=gb2312">
繁体中文：< META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=BIG5">
英 语：< META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
c.网页制作者信息
d.网站简介
< META NAME="DESCRIPTION" CONTENT="xxxxxxxxxxxxxxxxxxxxxxxxxx">
e.搜索关键字
< META NAME="keywords" CONTENT="xxxx,xxxx,xxx,xxxxx,xxxx,">
f.网页的css规范
< LINK href="style/style.css" rel="stylesheet" type="text/css">
g.网页标题
< title>xxxxxxxxxxxxxxxxxx< /title>
[color=#0000FF] 网站项目管理规范手册
一. 概念
网站项目管理就是根据特定的规范、在预算范围内、按时完成的网站开发任务。
二. 需求分析
项目立项
我们接到客户的业务咨询，经过双方不断的接洽和了解，并通过基本的可行性讨论够，初步达成制作协议，这时就需要将项目立项。较好的做法是成立一个专门的项目小组，小组成员包括：项目经理，网页设计，程序员，测试员，编辑/文档等必须人员。项目实行项目经理制。
客户的需求说明书
第一步是需要客户提供一个完整的需求说明。很多客户对自己的需求并不是很清楚，需要您不断引导和帮助分析。曾经有一次，我问客户：“您做网站的目的是什么？”他回答：“没有目的，只是因为别人都有，我没有！”。这样的客户就需要耐心说明，仔细分析，挖掘出他潜在的，真正的需求。 配合客户写一份详细的，完整的需求说明会花很多时间，但这样做是值得的，而且一定要让客户满意，签字认可。把好这一关，可以杜绝很多因为需求不明或理解偏差造成的失误和项目失败。糟糕的需求说明不可能有高质量的网站。那么需求说明书要达到怎样的标准呢？简单说，包含下面几点：
1. 正确性：每个功能必须清楚描写交付的功能；
2. 可行性：确保在当前的开发能力和系统环境下可以实现每个需求；
3. 必要性：功能是否必须交付，是否可以推迟实现，是否可以在削减开支情况发生时"砍"掉；
4. 简明性：不要使用专业的网络术语；
5. 检测性：如果开发完毕，客户可以根据需求检测。
三. 系统分析
网站总体设计
在拿到客户的需求说明后，并不是直接开始制作，而是需要对项目进行总体设计，详细设计，出一份网站建设方案给客户。总体设计是非常关键的一步。它主要确定：
1. 网站需要实现哪些功能；
2. 网站开发使用什么软件，在什么样的硬件环境；
3. 需要多少人，多少时间；
4. 需要遵循的规则和标准有哪些。
同时需要写一份总体规划说明书，包括：
1. 网站的栏目和版块；
2. 网站的功能和相应的程序；
3. 网站的链接结构；
4. 如果有数据库，进行数据库的概念设计；
5. 网站的交互性和用户友好设计。
网站建设方案
在总体设计出来后，一般需要给客户一个网站建设方案。很多网页制作公司在接洽业务时就被客户要求提供方案。那时的方案一般比较笼统，而且在客户需求不是十分明确的情况下提交方案，往往和实际制作后的结果会有很大差异。所以应该尽量取得客户的理解，在明确需求并总体设计后提交方案，这样对双方都有益处。网站建设方案的包括以下几个部分：
1. 客户情况分析；
2. 网站需要实现的目的和目标；
3. 网站形象说明；
4. 网站的栏目版块和结构；
5. 网站内容的安排，相互链接关系；
6. 使用软件，硬件和技术分析说明；
7. 开发时间进度表；
8. 宣传推广方案；
9. 维护方案；
10. 制作费用；
11. 本公司简介：成功作品，技术，人才说明等。
当您的方案通过客户的认可，那么恭喜你！您可以开始动手制作网站了。但还不是真正意义上的制作，你需要进行详细设计：
网站详细设计
总体设计阶段以比较抽象概括的方式提出了解决问题的办法。详细设计阶段的任务就是把解法具体化。详细设计主要是针对程序开发部分来说的。但这个阶段的不是真正编写程序，而是设计出程序的详细规格说明。这种规格说明的作用很类似于其他工程领域中工程师经常使用的工程蓝图，它们应该 包含必要的细节，例如：程序界面，表单，需要的数据等。程序员可以根据它们写出实际的程序代码。
四. 项目实施
整体形象设计
在程序员进行详细设计的同时，网页设计师开始设计网站的整体形象和首页。整体形象设计包括标准字，Logo，标准色彩，广告语等。 首页设计包括版面，色彩，图像，动态效果，图标等风格设计，也包括banner，菜单，标题，版权等模块设计。首页一般设计1-3个不同风格，完成后，供客户选择。
记住：在客户确定首页风格之后，请客户签字认可。以后不得再对版面风格有大的变动，否则视为第二次设计。
开发制作
到这里，程序员和网页设计师同时进入全力开发阶段，需要提醒的是，测试人员需要随时测试网页与程序，发现Bug立刻记录并反馈修改。不要等到完全制作完毕再测试，这样会浪费大量的时间和精力。项目经理需要经常了解项目进度，协调和沟通程序员与网页设计师的工作。
调试完善
在网站初步完成后，上传到服务器，对网站进行全范围的测试。包括速度，兼容性，交互性，链接正确性，程序健壮性，超流量测试等，发现问题及时解决并记录下来。
为什么要记录文档呢？其实本软件工程本身就是一个文档，是一个不断充实和完善的标准。通过不断的发现问题，解决问题，修改，补充文档，使这个标准越来越规范，越来越工业化。进而使得网站开发趋向规范，趋向合理。
宣传推广
宣传推广的基本方法有：
1. 网页里设置适当的META标签；
2. 各搜索引擎登录；
3. 准备新闻稿件在各新闻公告板发表；
4. 合理使用Email邮件列表；
5. 广告条交换；
6. 付费广告。
至此，网站项目建设完毕，将有关网址，使用操作说明文档等提交客户验收。如果需要维护，另行签定维护项目。
维护
网站成功推出后，长期的维护工作才刚刚开始，我们需要做到的是：
1. 及时响应客户反馈；例如可以采取Email自动回复功能，然后在1-3个工作日里解决问题，再次回复；
2. 网站流量统计分析和相应对策；
3. 尽量推广和使用您的网址；
4. 网站内容的及时更新和维护。
五. 遵循的规范
1. 网站建设目录规范
2. 网站文件命名规范
3. 网站建设尺寸规范
4. 网站首页head区代码规范
5. 网站连接结构规范
[color=#0000FF] 网站软件开发规范(某门户网站的)
1数据库使用规范
1.1服务器上有关数据库的一切操作只能由服务器管理人员进行。
1.2程序中访问数据库时使用统一的用户、统一的连接文件访问数据库。
1.3原则上每一个频道只能建一个库，库名与各频道的英文名称相一致，库中再包含若干表。比较大的、重点的栏目可以考虑单独建库，库名与栏目的英文名称相一致。
1.4命名：
（1） 数据库、表、字段、索引、视图等一系列与数据库相关的名称必须全部使用与内容相关的英文单词命名（尽量避免使用汉语拼音），对于一个单词难以表达的，可以考虑用多个单词加下划线（_）连接（不能超过四个单词）命名。
（2） 所有的名称必须统一使用英文小写字母。
（3） 所有的名称起始和结尾不能使用下划线（_）。
（4） 所有的名称不能包含26个英文小写字母和下划线（_）以外的其他字符。
1.5不再使用的数据库、表应删除，在删除之前必须备份（包括结构和内容）。
2 文档规范
所有的项目必须有相关的文档说明（可以是电子文档）。文档应包含如下内容：
（1）项目名称。
（2）项目小组名单，项目负责人。
（3）项目开发起始时间和结束时间。
（4）项目内容描述。
（5）项目位置。（在哪个频道、哪个栏目）
（6）与项目有关的程序文件名（含路径名），文件内容及实现的功能描述。
（7）完整的程序流程图。
（8）数据库、表、视图、索引的名称，用途。字段的名称、类型、长度、用途，必须附上相关的SQL语句。
3源代码与页面嵌套规范
3.1源代码：
（1） 使用自定义变量（包括全局变量、局部变量）之前必须先声明变量，并用注释语句标明变量的类型、用途。
（2）自定义函数必须用注释语句标明函数的用途、参数的数据类型、意义，返回值的类型。
（3）程序中重要的过程或代码较长的过程应使用注释语句标明该过程的起始行和结束行，并注明该过程的功能。
（4） 所有的注释文字一律使用简体中文。
3.2 HTML页面嵌套：
（1） 网页设计部设计的HTML页面以嵌套的方式确定用于动态显示程序执行结果的位置、宽度、行数（或高度）等，并在相应位置予以文字说明。页面中与程序无关的图片、文字、联结等必须使用完整的URL。
（2） 软件开发人员和编辑人员可以根据情况协商，将页面文件及图片与程序独立存放在各自的服务器上，页面改版和修改程序独立进行。
（3） 使用include技术将分割开的HTML页面分别嵌入程序代码中，要求做到修改HTML页面时无须改写程序，而修改程序时不会影响HTML页面效果，将页面改版和修改程序两项工作分别独立。
（4） 页面和程序嵌套以后不能破坏原HTML页面的整体显示效果，字体、字号、颜色等应尽量保持原HTML页面的风格。
（5） 动态生成的页面的各项指标（如图片大小、页面宽度、高度、页面文件的字节数等）应符合本公司网页设计方面的要求。
4测试规范（软件部分）
对于较大的项目应成立相应的测试小组，小组成员由软件开发人员、网页设计人员、技术人员、编辑人员组成。测试过程应参照网页设计部为该项目提供的原HTML页面进行。测试内容包括以下几点：
（1） 页面宽度、高度（行数）。
（2） 页面文字、图片、色彩是否风格统一。
（3）页面的图片显示是否正常、有无变形。
（4）弹出页面的效果。
（5）页面的联接是否正确。
（6）动态生成的页面是否符合以上几个方面的要求，页面大小（字节数，包括页面的图片、*.js、*.css、*.class等相关文件）是否符合网页设计的要求。
（7） 软件方面的功能是否实现。如数据库的查询、修改、删除，文件的上传、下载等操作是否正常。
（8） 测试结束后，根据《软件开发需求书》在《测试报告》上如实填写测试结果，包括测试通过的、未通过的，指出出错的页面和相关的程序文件，并附上测试中出现的错误信息。
[color=#0000FF] 网站制作规范
1. 网站目录规范 ---------------------------------目录建立的原则：以最少的层次提供最清晰简便的访问结构。
l 根目录一般只存放index.asp以及其他必须的系统文件,轻易不要建目录，
l 每个主要栏目开设一个相应的独立目录;目录中开设一个images 的子目录用以放置此栏目专有的图片和flash文件，如果这个栏目的内容特别多，又分出很多下级栏目，可以相应的再开设其他目录。
l 根目录下的images用于存放各页面都要使用的公用图片
l 所有公共脚本*.js *.asp等存放在根目录下的include目录；
l 各栏目CSS文件存放在相应目录下，以该栏目名命名！
2. 网站文件命名规范 ----------------------------------文件命名的原则：以最少的字母达到最容易理解的意义。
l 每个栏目首页以该栏目命名，如：安全管理栏目下首页面 /anquan/anquan.htm
l 多个同类型文件使用英文字母加数字命名，字母和数字之间用_分隔。例如：news_01.htm。注意，数字位数与文件个数成正比，不够的用0补齐。
l HTML文件扩展文件名一律用 .htm注意不要使用.html
3. 图片的命名规范 -----------------------------------------------图片名称分为头尾两两部分，用下划线隔开。
l 头部分表示此图片的大类性质。例如： 放置在页面顶部的广告、装饰图案等长方形的图片我们取名：banner ；标志性的图片我们取名为：logo ；在页面上位置不固定并且带有链接的小图片我们取名为button ；在页面上做栏目链接的图片我们取名：menu ；不带链接表示标题的图片我们取名：title ；装饰用的照片我们取名：pic ；依照此原则类推。
l 尾部分用来表示图片的具体含义，用英文字母表示。例如：banner_lntu.gif logo_lntu.gif button_next.gif menu_aboutus.gif title_news.gif pic_people.jpg
l 有onmouse效果的图片，两张分别在原有文件名后加"_on"和"_off"命名。
4. 网站建设尺寸规范 -----------------------------------------------------------------------------------------------
l 尺寸规范请根据您的实际情况调整：页面标准按800*600分辨率制作，尺寸宽为760px；注意考虑 1024*768情况下居中，页面长度原则上不超过3屏，
l 全尺寸banner为468*60px，小banner为88*31px，另外120*90，120*60也是小图标的标准尺寸；
5. 网站首页head区代码规范 -------------------------------------------------------------------------------------
首页的代码关键在head区，head区是指首页HTML代码的和之间的内容。
这个栏目的标题
该页所采用的样式表.css" rel="stylesheet" type="text/css">
6. 其它一些规范 ------------------------------------------------------------------------------------------------------
l js的命名原则以功能的英语单词为名。例如：广告条的js文件名为：ad.js；
l 所有的CSS的尽量采用外部调用：
l 所有的javascript脚本尽量采取外部调用：
l 字号用点数pt和像素px来定义，pt使用中文宋体的9pt和11pt，px使用中文宋体12px 和14.7px黑体 字或者宋体字加粗时，一般选用11pt 和14.7px 的字号比较合适。
l 所有连接使用相对路径，切记不可使用绝对路径。如：../index.htm
l 所有文件，目录，图片全部以小写字母命名，禁止用中文命名。
[color=#0000FF] Web 测试的经验
1. 功能测试
1.1.链接测试
链接是 Web 应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证 Web 应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的 URL 地址才能访问。
链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个 Web 应用系统的所有页面开发完成之后进行链接测试。
1.2. 表单测试
当用户给 Web 应用系统管理员提交信息时，就需要使用表单操作，例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。
1.3.Cookies测试
Cookies 通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用 Cookies 访问了某一个应用系统时， Web 服务器将发送关于用户的信息，把该信息以 Cookies 的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。
如果 Web 应用系统使用了 Cookies ，就必须检查 Cookies 是否能正常工作。测试的内容可包括 Cookies 是否起作用，是否按预定的时间进行保存，刷新对 Cookies 有什么影响等。
1.4.设计语言测试
Web 设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的 HTML 等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了 HTML 的版本问题外，不同的脚本语言，例如 Java 、 JavaScript 、 ActiveX 、 VBScript 或 Perl 等也要进行验证。
1.5.数据库测试
在 Web 应用技术中，数据库起着重要的作用，数据库为 Web 应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在 Web 应用中，最常用的数据库类型是关系型数据库，可以使用 SQL 对信息进行处理。
在使用了数据库的 Web 应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。
2. 性能测试
2.1.连接速度测试
用户连接到 Web 应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果 Web 系统响应时间太长（例如超过 5 秒钟），用户就会因没有耐心等待而离开。
另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。
2.2.负载测试
负载测试是为了测量 Web 系统在某一负载级别上的性能，以保证 Web 系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问 Web 系统的用户数量，也可以是在线数据处理的数量。例如： Web 应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？ Web 应用系统能否处理大量用户对同一个页面的请求？
2.3.压力测试
负载测试应该安排在 Web 系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个 Web 系统能同时处理的请求数量将远远超出这个限度，所以，只有放在 Internet 上，接受负载测试，其结果才是正确可信的。
进行压力测试是指实际破坏一个 Web 应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试 Web 应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到 Web 应用系统崩溃，接着当系统重新启动时获得存取权。
压力测试的区域包括表单、登陆和其他信息传输页面等。
3. 可用性测试
3.1.导航测试
导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。通过考虑下列问题，可以决定一个 Web 应用系统是否易于导航：导航是否直观？ Web 系统的主要部分是否可通过主页存取？ Web 系统是否需要站点地图、搜索引擎或其他的导航帮助？
在一个页面上放太多的信息往往起到与预期相反的效果。 Web 应用系统的用户趋向于目的驱动，很快地扫描一个 Web 应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉 Web 应用系统的结构，因此， Web 应用系统导航帮助要尽可能地准确。
导航的另一个重要方面是 Web 应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道 Web 应用系统里面是否还有内容，内容在什么地方。
Web 应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。
3.2.图形测试
在 Web 应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个 Web 应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：
（1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。 Web 应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。
（2）验证所有页面字体的风格是否一致。
（3) 背景颜色应该与字体颜色和前景颜色相搭配。
（4）图片的大小和质量也是一个很重要的因素，一般采用 JPG 或 GIF 压缩。
3.3.内容测试
内容测试用来检验 Web 应用系统提供信息的正确性、准确性和相关性。
信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷；信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用 Microsoft Word 的 " 拼音与语法检查 " 功能；信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般 Web 站点中的所谓 " 相关文章列表 " 。
3.4.整体界面测试
整体界面是指整个 Web 应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览 Web 应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方？整个 Web 应用系统的设计风格是否一致？
对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般 Web 应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。
对所有的可用性测试来说，都需要有外部人员（与 Web 应用系统开发没有联系或联系很少的人员）的参与，最好是最终用户的参与。
4. 客户端兼容性测试
4.1.平台测试
市场上有很多不同的操作系统类型，最常见的有 Windows 、 Unix 、 Macintosh 、 Linux 等。 Web 应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。
因此，在 Web 系统发布之前，需要在各种操作系统下对 Web 系统进行兼容性测试。
4.2.浏览器测试
浏览器是 Web 客户端最核心的构件，来自不同厂商的浏览器对 Java ，、 JavaScript 、 ActiveX 、 plug-ins 或不同的 HTML 规格有不同的支持。例如， ActiveX 是 Microsoft 的产品，是为 Internet Explorer 而设计的， JavaScript 是 Netscape 的产品， Java 是 Sun 的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和 Java 的设置也不一样。
测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。
5. 安全性测试
Web 应用系统的安全性测试区域主要有：
（ 1 ）现在的 Web 应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。
（ 2 ） Web 应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如 15 分钟）没有点击任何页面，是否需要重新登陆才能正常使用。
（ 3 ）为了保证 Web 应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。
（ 4 ）当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。
（ 5 ）服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。
[color=#0000FF] Web测试手段
近年来，随着软硬件技术发展和人们意识的提高，Web应用得到广泛的普及，一方面在互联网浪潮的推动下，基于互联网的信息共享和电子商务不断发展，像新浪、搜狐、8848等大型网站不断涌现出来，另一方面随着Java、CGI等网络技术的成熟，基于B/S结构的大型软件逐渐显示出巨大的优势。同时，也就产生了一个焦点问题，什么样的服务器能够满足不同用户的需求，怎么能够保证Web服务器能够长期稳定地运行，为了满足这样的需求Web测试也就同样变得十分重要。
当前Web测试主要通过Web测试工具加上良好的测试案例完成的，我们认为主要有以下两种测试类型：基准测试、非基准测试
基准测试：主要指测试工具已经提供了标准的测试案例库，包括静态测试案例（HTM、JPG）、动态测试案例（CGI）和SSL测试案例等。这类测试工具分为测试案例库、控制台程序、客户端程序三个部分。它的原理是，Web服务器开启特定的Web服务程序，并且运行上述测试案例，由控制台程序控制各个客户端按照一定的脚本访问顺序遍历Web服务器的各个测试案例，每个请求完成后，各个客户端向控制台报告访问的结构，当一个测试集完成后由控制台将所有的信息综合统计，测试过程中控制台还需要采用SNMP协议对服务器进行实时监控，综合两个方面的因素可以反映出Web服务器在不同压力情况下的综合性能。
在测试过程中，主要影响测试结果的因素有网络环境、客户端性能。目前无论IA架构服务器还是SUN、HP、IBM的UNIX服务器性能都越来越优越，有可能出现在100MB网络下不能够提供足够的网络压力，有可能网络首先出现瓶颈，这样就需要扩展到1000MB网络环境或使用多个网段对服务器提供足够的压力，而稳定的客户端对于测试来说也是十分重要的，因为客户端如果出现性能下降，就会造成系统崩溃或者不能提供稳定的测试压力从而导致测试结果出现偏差；一台客户端到底能够稳定运行多少数量的连接是根据不同的硬件配置和操作系统决定的，因此对客户端的硬件资源进行监控是保证客户端可以稳定运行的必要手段。
由于这类测试工具使用的是工具开发商提供的测试案例集，虽然也具有一定的权威性，但是目前再完美的测试案例集也不能涵盖所有的Web应用情况，所以也不能够完全体现出Web服务器完整的性能，因此该类测试工具更加适合IT媒体对Web类服务器软硬件的横向对比测试，在测试对象和环境大体统一的情况下，可以比较出各个测试对象的性能差异。而对于有实际应用背景的Web服务器进行测试，使用这样的测试工具就不适合了，我们在以后的测试漫谈中会继续介绍
[color=#0000FF] 对Web服务进行压力测试
Web 服务处于分布式计算的核心位置，它们之间的交互通常很难测试。分布式开发、大型的开发者团队以及对代码日益组件化的期望都有可能使 Web 服务的开发变得越来越容易隐藏错误。这些类型的错误极难检测出来。压力测试是检测这类代码错误的一种有效方法，但是只有在压力系统设计得比较有效的情况下 才能发挥作用。本文将让您深入了解一下这种压力系统的基本要求。
测试方法
传统的测试方法包括某种形式的简单 单元测试 ，通常由开发人员执行。设计这些测试需要了解软件的内部知识，并且这些测试几乎总是针对产品的非常小的、特定的部分。这些类型的测试非常适合与其他代码组件极少交互，甚至没有交互的简单 Web 服务。
功能验证（Functional Verification） 也 是一种测试过程，在这个过程中，对产品源代码了解有限的设计者进行测试以确认产品或服务的核心功能。设计这种测试是为了证明这个核心功能符合某个规范。举 个例子，我的在线拍卖显示的是输入的正确出价吗？ 我的保险经纪人系统找到最便宜的报价了吗？如果这些测试失败，通常就意味着检测到了产品的一个基本问题（这个问题通常是可以直接修复）。这种测试也是适合 简单的 Web 服务，使您可以检查服务是否能够正确执行它的各个功能。
系统测试（System Test） 通常是在功能验 证阶段完成，验证了核心功能后进行。它倾向于把整个系统作为一个整体来查找问题 — 弄清 Web 服务作为系统的一部分怎样运作，以及 Web 服务相互之间如何交互。由于系统测试是在开发生命周期快结束时才进行，所以通常不能给它分配足够的时间来完成。又因为紧张的发行日程安排以及开发的各个重 要阶段的后移，系统测试阶段经常被忽略，并且一些通常都可以发现的、少见的错误都不能被检测到。即使发现了这种错误，这时也来不及确定错误的原因并设法修 复它们了。因此，在查找代码错误时，必需把系统测试应用设计得尽可能高效。系统测试通常由三部分组成，它们是：
性能（Performance）： 这涉及到确定相关的产品统计数据的过程。例如：每秒有多少条消息？一个服务可同时接受多少个用户？
案例（Scenario）： 这是重新创建客户所需的确切配置的过程。因此在案例中发现的任何问题都可以在客户使用该产品之前被检测出来。
压力（或称工作负载平衡）： 它 与另两个部分不同，因为它被设计为通过应用很大的工作负载来使软件超负荷运转。如果压力测试通过对产品保持高强度的使用（但不超过性能统计数字确定的限 制）能有效地执行，那么它就经常能够发现许多隐蔽的错误，而这些错误用上面提到的任何其他技术都是发现不了的（这些错误也经常是最难修复的）。
从检测代码错误这方面来说，可以证明这三个系统测试组件中效率最高的是 压力测试 部分。但由于这个过程经常跟系统的其他要素或功能测试混淆在一起，所以这个过程涉及到的方法还没有被正确着手处理或实现。
压力下的错误
使用压力测试，您有希望找到很多种用其他测试方法更难发现的错误。有两种错误类型是：
内存泄漏（Memory leak）： 一种极难检测的现象。内存泄漏经常发生在已发行的产品中，原因很简单，很难设计测试 用例来检测它们。使用简单的功能测试，几乎发现不了内存泄漏问题，因为在产品完成之前测试没对产品进行足够多的使用。内存泄漏通常要求操作要重复非常多的 次数以使内存消耗达到能引起注意的程度。尽管与其它编程语言（如 C/C++）相比，Java 程序更难引入内存泄漏错误，但只要程序仍保持着对对象的引用，该对象仍有可能被实例化并且它占用的内存永远不会被释放。
并发与同步（Concurrency and Synchronization）： 压 力测试在查找并发性问题上非常出众，这是因为在任何一个测试生命周期中，它都应用了许多不同的代码路径和定时条件。一般的规则是，压力测试运行的时间越 长，涉及并应用的代码路径组合和定时条件就越多。当然，这也的确使得这些问题很难再现（错误可以在 5 分钟或 5 天后发生）。死锁、线程泄漏以及任何一般的同步问题通常只能在压力测试阶段被检测出来。这些类型的问题很难通过执行单元测试来发现。开发人员不会一直考虑 他或她的代码将与其他地方的代码（在执行单元测试时这些代码可能还没写出来）进行交互。
现有的压力测试工具
有许多声称能够对 产品进行压力测试的可用工具目前正在开发中。被广泛应用的是针对 Web 服务的那些工具。然而，这些工具中有许多只是简单的 HTML/SOAP 生成器，它们模拟许多客户机连接，并因此对 Web 服务器生成高负载（这对于查找 Web 服务器的问题很有用，但对于查找 Web 服务的问题就没那么有用了）。这些工具对基本的压力测试比较有用，但它们经常是仅仅扩展功能验证阶段来重复地执行相同的功能任务。如果足够的时间和资源可 用，就可以通过创建定制构建的压力测试系统来实现更有效的测试。由于压力系统的设计者通常对要测试的产品和 Web 服务有更多的了解，所以他们将能够确保压力系统可以用于哪些具体的代码区域。
设计压力应用
设计试图对 Web 服务进行压力测试的压力测试系统时，要让它们以某种特定的方式运行代码。这些风格超越了功能验证，目的是要弄清楚被测试的 Web 服务是不是不仅能做我们认为它能做的事，而且在被施加了某些高强度压力的情况下仍然继续正常运行。压力测试必须对 Web 服务应用四个基本条件。许多已建立的压力系统应用了这些条件。有效的压力测试系统将应用以下这些关键条件：
重复（Repetition）： 或 许最明显的且最容易理解的压力条件就是测试的重复。换句话说，测试的重复就是一遍又一遍地执行某个操作或功能，比如重复调用一个 Web 服务。功能验证测试可以用来被弄清楚一个操作能否正常执行。而压力测试将确定一个操作能否正常执行，并且能否继续在每次执行时都正常。这对于推断一个产品 是否适用于某种生产情况至关重要。客户通常会重复使用产品，因此压力测试应该在客户之前发现代码错误。许多最简单的压力系统只实现这一个条件，但简单地扩 展功能验证测试来多次重复并不能构成一个有效的压力测试。当与下面的一些原则结合起来使用时，重复就可以发现许多隐蔽的代码错误。
并发（Concurrency）： 并 发是同时执行多个操作的行为。换句话说，就是在同一时间执行多个测试，例如在同一个服务器上同时调用许多 Web 服务。这个原则不一定适用于所有的产品（比如无状态服务），但是多数软件都具有某个并发行为或多线程行为元素，这一点只能通过执行多个代码示例才能测出 来。功能测试或单元测试几乎不会与任何并发设计结合。压力系统必须超越功能测试，要同时遍历多条代码路径。至于怎么做到这一点取决于具体的产品。例如，一 个 Web 服务压力测试需要一次模拟多个客户机。Web 服务（或者任何多线程代码）通常会访问多个线程实例间的一些共享数据。因额外方面的编程而增加的复杂性通常意味着代码会具有许多因并发引起的错误。由于引 入并发性意味着一个线程中的代码有可能被其他线程中的代码中断，所以错误只在一个指令集以特定的顺序（例如以特定的定时条件）执行时才会被发现。把这个原 则与重复原则结合在一起，您可以应用许多代码路径 和 定时条件。
量级（Magnitude）： 压 力系统应该应用于产品的另一个条件考虑到了每个操作中的负载量。压力测试可以重复执行一个操作，但是操作自身也要尽量给产品增加负担。例如，一个 Web 服务允许客户机输入一条消息，您可以通过模拟输入超长消息的客户机来使这个单独的操作进行高强度的使用。换句话说就是，您增加了这个操作的量级。这个量级 总是特定于应用的，但是可以通过查找产品的可被用户计量和修改的值来确定它 — 例如，数据的大小、延迟的长度、资金数量的转移、输入速度以及输入的变化等等。单独的高强度操作自身可能发现不了代码错误（或者仅能发现功能上的缺陷）， 但与其他压力原则结合在一起时，您将可以增加发现问题的机会。
随机变化： 最后一点，任何压力系统都多多 少少具有一些随机性。如果您随机使用前面的压力原则中介绍的无数变化形式，您就能够在每次测试运行时应用许多不同的代码路径。下面是几个关于怎样在测试生 命周期内改变测试的示例。使用重复时，在重新启动或重新连接服务之前，您可以改变重复操作间的时间间隔、重复的次数，或者也可以改变被重复的 Web 服务的顺序。使用并发，您可以改变一起执行的 Web 服务、同一时间运行的 Web 服务数目，或者也可以改变关于是运行许多不同的服务还是运行许多同样的实例的决定。量级或许是最容易更改的 — 每次重复测试时都可以更改应用程序中出现的变量（例如，发送各种大小的消息或数字输入值）。如果测试完全随机的话，因为很难一致地重现压力下的错误，所以 一些系统使用基于一个固定随机种子的随机变化。这样，用同一个种子，重现错误的机会就会更大。
一个压力测试通常会结合上述的所 有原则，并且在允许的范围内尽可能长时间地运行。测试被允许的执行时间越长，就可以遍历越多的代码路径，并且发现的错误也越多。当然，一旦找到错误就必须 诊断并修复它。由于一个代码错误可以在压力测试运行多日以后自己显示出来，所以系统必须保证当出现错误时所有可用的调试信息都被生成 — 否则可能就必须花费同样多的时间来重现这个错误。
结束语
测试是软件开发过程中至关重要 的部分，并且一个重要的、经常被曲解或忽略的部分是压力测试。遵循上面详细说明的原则，您就可以设计并实现有效的压力测试系统，用来查找一些与您的代码相 关的、比较隐蔽的问题。无论是利用预先写好的工具，还是创建一个完全专用的压力系统，压力测试都是用于查找 Web 服务（或其他任何程序）问题的本质方法，并能最终提高您的软件产品质量。
[color=#0000FF] 基于Web的系统测试方法
摘要
基于Web的系统测试与传统的软件测试既有相同之处，也有不同的地方，对软件测试提出了新的挑战。基于Web的系统测试不但需要检查和验证是否按照设计的要求运行，而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。
本文从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于Web的系统测试方法。
随着Internet和Intranet/Extranet的快速增长，Web已经对商业、工业、银行、财政、教育、政府和娱乐及我们的工作和生活产生了深远的影响。许多传统的信息和数据库系统正在被移植到互联网上，电子商务迅速增长，早已超过了国界。范围广泛的、复杂的分布式应用正在Web环境中出现。Web的流行和无所不在，是因为它能提供支持所有类型内容连接的信息发布，容易为最终用户存取。
Yogesh Deshpande和Steve Hansen在1998年就提出了Web工程的概念。Web工程作为一门新兴的学科，提倡使用一个过程和系统的方法来开发高质量的基于Web的系统。它"使用合理的、科学的工程和管理原则，用严密的和系统的方法来开发、发布和维护基于Web的系统"。目前，对于web工程的研究主要是在国外开展的，国内还刚刚起步。
在基于Web的系统开发中，如果缺乏严格的过程，我们在开发、发布、实施和维护Web的过程中，可能就会碰到一些严重的问题，失败的可能性很大。而且，随着基于Web的系统变得越来越复杂，一个项目的失败将可能导致很多问题。当这种情况发生时，我们对Web和Internet的信心可能会无法挽救地动摇，从而引起Web危机。并且，Web危机可能会比软件开发人员所面对的软件危机更加严重、更加广泛。
在Web工程过程中，基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于Web的系统测试与传统的软件测试不同，它不但需要检查和验证是否按照设计的要求运行，而且还要测试系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。然而，Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。因此，我们必须为测试和评估复杂的基于Web的系统研究新的方法和技术。
一般软件的发布周期以月或以年计算，而Web应用的发布周期以天计算甚至以小时计算。Web测试人员必须处理更短的发布周期，测试人员和测试管理人员面临着从测试传统的C/S结构和框架环境到测试快速改变的Web应用系统的转变。
一、功能测试
1、链接测试
链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。
链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的所有页面开发完成之后进行链接测试。
2、表单测试
当用户给Web应用系统管理员提交信息时，就需要使用表单操作，例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。
3、Cookies测试
Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。
如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。
4、设计语言测试
Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语言，例如Java、JavaScript、 ActiveX、VBScript或Perl等也要进行验证。
5、数据库测试
在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。
在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。
二、性能测试
1、连接速度测试
用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。
另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。
2、负载测试
负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统能否处理大量用户对同一个页面的请求？
3、压力测试
负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。
进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。
压力测试的区域包括表单、登陆和其他信息传输页面等。
三、可用性测试
1、导航测试
导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。通过考虑下列问题，可以决定一个Web应用系统是否易于导航：导航是否直观？Web系统的主要部分是否可通过主页存取？Web系统是否需要站点地图、搜索引擎或其他的导航帮助？
在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构，因此，Web应用系统导航帮助要尽可能地准确。
导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。
Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。
2、图形测试
在Web应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：
（1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。
（2）验证所有页面字体的风格是否一致。
（3）背景颜色应该与字体颜色和前景颜色相搭配。
（4）图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩。
3、内容测试
内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。
信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷；信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用Microsoft Word的"拼音与语法检查"功能；信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中的所谓"相关文章列表"。
4、整体界面测试
整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览Web应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方？整个Web应用系统的设计风格是否一致？
对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。
对所有的可用性测试来说，都需要有外部人员（与Web应用系统开发没有联系或联系很少的人员）的参与，最好是最终用户的参与。
四、客户端兼容性测试
1、平台测试
市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。
因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。
2、浏览器测试
浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java，、JavaScript、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，JavaScript是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。
测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。
五、安全性测试
Web应用系统的安全性测试区域主要有：
（1）现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。
（2）Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。
（3）为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。
（4）当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。
（5）服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。
六、总结
本文从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于Web的系统测试方法。
基于Web的系统测试与传统的软件测试既有相同之处，也有不同的地方，对软件测试提出了新的挑战。基于Web的系统测试不但需要检查和验证是否按照设计的要求运行，而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。
七、参考文献
[1] N. Zelnick. Nifty Technology and Nonconformance: The Web in Crisis. Computer， 1998(10): 115-119
[2] W. Gibbs. Software';s chronic crisis. Scientific American. 1994.9
[3] Yogesh Deshpande and Steve Hansen. Web Engineering: Creating a Discipline among Disciplines. IEEE Software，2001(2): 82-87
[4] A. Ginige. Web Engineering: Methodologies for Developing Large and Maintainable Web Based Information Systems. Proc IEEE International Conference on Networking， the India and the World CNIW';98，Ahmedabad， India， 1998，12
[5] Internet Testing: Keeping Bugs Off the Web. http://www.stlabs.com/bugs_off.htm
[6] J. Bach. Testing Internet Software.
http://www.stlabs.com/testnet/docs/inet.htm
[7] Tongren.Compatibility and Security Testing of Web-Based Applications. TTN Online，1999，3
[color=#0000FF] Web下的整体测试
随着Internet的日益普及，现在基于B/S结构的大型应用越来越多，可如何对这些应用进行测试成为日益迫切的问题。有许多测试人员来信问我B/S的测试如何做，由于工作较繁忙，对大家提出的问题也是头痛医头脚痛医脚，没有对WEB的测试过程做一个整体的概述。希望通过本篇能够让大家了解大型Web应用是如何来进行测试的。
B/S下的功能测试比较简单，关键是如何做好性能测试。目前大多数的测试人员认为只要跑一些测试工具证明我的产品是可以达到性能的就ok了，为了证明而去测试是没有任何价值的，关键是要发现产品性能上的缺陷，定位问题，解决问题，这才是测试要做的。
首先我们从两个方面分析如何进行WEB测试，从技术实现上来讲一般的B/S结构，无论是.NET还是J2EE,都是多层构架，有界面层，业务逻辑层，数据层。而从测试的流程上来说，首先是发现问题，分析问题，定位问题，再由开发人员解决问题。那么B/S的结构的测试如何来做？
如何发现问题是我首先要介绍的，在做WEB测试之前你需要一些资料，比如产品功能说明书，性能需求说明书，不一定很完善，但一定要有，明确测试目标，这是基本的常识，可是我往往看到的是已经开始动手测了，但还不知自己的系统要达到的性能指标是什么。这里我简单讲一下测试的性能指标：
l 通用指标（指Web应用服务器、数据库服务器必需测试项）:
* ProcessorTime: 指服务器CPU占用率，一般 平均达到70%时，服务就接近饱和；
* Memory Available Mbyte : 可用内存数，如果测试时发现内存有变化情况也要注意，如果是内存泄露则比较严重；
* Physicsdisk Time : 物理磁盘读写时间情况；
l Web服务器指标：
* Avg Rps: 平均每秒钟响应次数＝总请求时间 / 秒数；
* Avg time to last byte per terstion （mstes）:平均每秒业务角本的迭代次数 ,有人会把这两者混淆；
* Successful Rounds：成功的请求；
* Failed Rounds ：失败的请求；
* Successful Hits ：成功的点击次数；
* Failed Hits ：失败的点击次数；
* Hits Per Second ：每秒点击次数；
* Successful Hits Per Second ：每秒成功的点击次数；
* Failed Hits Per Second ：每秒失败的点击次数；
* Attempted Connections ：尝试链接数；
l 数据库服务器指标：
* User 0 Connections ：用户连接数，也就是数据库的连接数量；
* Number of deadlocks：数据库死锁；
* Butter Cache hit ：数据库Cache的命中情况；
上面的指标只是一些通用的指标,起到抛砖引玉的作用，对于不同的应用你还必需作相应的调整，比如程序使用的是.NET技术的，则必需加入一些针对性的测试指标。对于这些指标的详细了解，你可以参考Windows 下面的 SystemMonitor的帮助与LoadRunner、ACT的帮助。对于发现问题，指标的设置非常重要，它会帮你定性的发现一些错误。对于定性的压力测试我就不做过多的分析，工具很多，流行的主要有LoadRunner,ACT,WAS,WebLoad,各个工具有它的使用范围，其中我各个认为LoadRunner 最全面，它提供了多种协议的支持，对复杂的压力测试都可以胜任，WAS与ACT则对微软的技术支持的比较好，其中WAS支持分布式机群测试,ACT则是与.NET集成比较好，支持ViewState （.NET 下控件缓存的支持） 的测试，当时我用时，其它测试工具还不支持，现在应该支持了吧，呵呵。在这一阶段测试你要不断的跟据系数的测试目标进行变化，一开始由于系统过于庞大，所以我们要分成若干个子系统，各个子系统的性能目标必需明确，主要是并发指标定一个阀值，同时设定一些与系统相关的测试参数，应用服务器，数据库服务器都要有，对达不到阀值的与一些通用参数有问题的子系统进行深入分析。比如它的并发达不到你的要求，证明子系统性能有问题，或是数据库用户连接过高，程序没有释放用户连接等等。这个我们要对子系统进行详细测试，由于B/S 结构下,图片的请求对性能的影响较大，所以我们对子系统测试时要分两个部分进行，一、非程序部分，即图片等等;二、应用程序本身。通过事务或函数的分离，可以把这两块实现单独的测试，具体做法参考各个工具的手册，我这里就不做说明。对子系统的测试参数的设置要求则更高，它有助你后面精确的定位问题，比如对异常，死锁，网络流量等等前面没有注意到的情况的增加，同时你要注意增加测试参数的收集对系统的性能影响比较大，所以一般不要超过10个，刚刚介绍的整体的性能测试指标也不要增加很多，这样影响会小一点。最后在这一阶段要说明的是数据库的数据量会很大程度的影响性能，所以要根据前面的性能需求说明书向数据库中模拟相应的数据量，来进行测试，这样才有更高的可信度。
上面所说的是对问题的发现，下面就是分析问题原因，这一步的要求比较高，一般由测试人员与程序员配合完成，当然如果你有相当的开发经验，再做这方面的测试，就更为难得。下面我们说说如何精确定位问题，出现问题的可能性可能有很多种，大致分以下几种，一、性能达不到目标；二、性能达到目标，但有一些其它的问题，比如异常，死锁，缓存命中过低，网络流量较大；三、服务器稳定性的问题，比如内存泄漏……。要发现这些问题起马的要求要有一款使用的比较称心的性能分析与优化工具，比如微软的.NET下就有自己开发的工具，对Borland的Java开发工具中也有类似的工具，但我个人认为更好的工具是Rose下的Purify与Quantify,主要是他对.net 与java ,C++都有支持，而且分析效果特别专业，我们先了解一下Rational Purify, Rational Purify 能自动找出Visual C/C++ 和Java 代码中与内存有关的错误，确保整个应用程序的质量和可靠性。在查找典型的Visual C/C++ 程序中的传统内存访问错误，以及Java，C# 代码中与垃圾内存收集相关的错误方面；Rational Quantity 则是一款针对函数级的性能分析利器，使用它你可以从图形化的界面中得到函数调用的时间，百分比与次数，以及子函数所占时间，使你可以更快的定位性能瓶颈。
我们先说性能优化与异常的处理，性能优化有一个原则，即用时间比例最大的进行优化，效果才最明显，比如有个函数它的执行时间为30秒，如果你优化了一百倍则执行时间为0.3秒,提升了29.7秒，而如果它的执行时间为0.3秒，优化后为0.003秒，实际提升了0.297秒，提升的效果并不明显，而且写过程序的人都知道，后者性能优化的代价更大。在性能优化的过程中，一般是先数据库，后程序，因为数据库的优化不需要修改程序，修改的风险很小。但如何才能确定是数据库的问题，这就需要技巧，在使用Quantity时，你一路分析下去，大多数最终会发现，是数据库查询函数占用时间比较大，比如什么，SqlCmd.ExecuteNoQuery等等数据库执行函数,这时你就需要分析数据库，呵呵。数据库的分析原则是先索引，后存储过程，最后表结构视图的优化，索引的优化是最简单也是通常最有效的方法，如果合理的使用会带来意想不到不到的效果。在这里我要给大家简单的介绍一下我的最爱，SQLProfile,SQL查询分析器，Precise,SQLProfile是一个SQL语句跟踪器，可以跟踪程序流程使用的SQL语句与存储过程，结合查询分析器对SQL的分析，可以对索引的优化做出很好的判断，但索引也不是万能的，在增删改较多的表，索引过多会引起这些操作的性能下降，所以判断还是需要一定的经验。同时针对用户使用频度最高的SQL进行优化也是最行之有效的，这时我则需要Precise，它可以观测某一个较长时间内的SQL语句的执行情况。数据库优化的潜能挖光后，如果还是达不到性能要求或是还有问题，则要从程序来进行优化，这是程序员做的事，测试人员要做的，就是告诉他们，哪个函数执行过多引起了性能下降，比如异常过多，某个循环过多，或是DCOM调用过多等等，但说服程序员也是一件不容易的事，你要在这一阶段做的出色一定要有几年的编程经验，并且要让程序员感到听你的性能会有提升，这是一件很不容易的事情哦。
内存的分析，一般是一个长期分析的过程，要做好不容易，首先要有长期奋战的准备，其次内存泄漏的分析最好是放在单元测试之中同步进行，而不是要等到最后再去发现问题，当然出了问题也只好面对，一般这类问题都是在服务器运行了很久才暴露出来，一旦发现问题后，则需要定位问题，分析的原则采用子系统相互独立运行，找到最小问题的系统集,或是借助内存分析工具观察内存对象情况，初步定位问题，再用Purify进行运行时分析，通常C++ 内存问题比较多，Java与.NET比较少，一般由GC不合理引起。C++的内存错误就比较多了，主要常见的有:
1、 Array Bounds Read (ABR) ：数组越界读
2、 Array Bounds Write (ABW)：数组越界写
3、 Beyond stack Read (BSR)：堆栈越界读
4、 Free Memory Read(FMR)：空闲内存读
5、 Invalid pointer Read(IPR)：非法指针阅读
6、 Null Pointer Read(NPR)： 空指针阅读
7、 Uninitialized Memory Read(UMR)：未初始化内存读写
8、 Memory Leak：内存泄漏
注：如果需要更多的信息，可以参见Purify的帮助信息。
顺便提一句，为什么我要说单元测试时做这个比较好，由于单元测试针对的是单一功能，这时结合单元测试案例做内存分析会更快的定位问题，同时由于问题较早的发现，则后期的风险则会减少，当然如果结合代码覆盖工具PureCoverage 来做就更完美了，呵呵。
完成此文，已经是凌晨了，也算是回答了前一段时间提出要进行B/S结构测试又无从下手的朋友的要求，在这里要向大家表达一下歉意，由于工作比较忙，难免对大家的来信有所疏漏，请大家原谅。此文的要求的读者，对测试工具有所了解，希望进入更深测试的同仁，希望我的文章给大家带来帮助,同时也借此文表达一些曾经帮助过我的朋友与同事。
注：本篇只是对B/S应用的测试过程作一个整体的描述，对某一个阶段使用的工具只是作大概的介绍,你也可使用你比较熟悉的工具达到相同的目标。
[color=#0000FF] 网站测试技术简介
1 概述
在一个软件项目开发中，系统测试是保证整体项目质量的重要一环，本文将就网站的测试技术及相应的自动测试工具做一个简要的介绍。主要就如下几个方面进行探讨：
功能测试
性能测试
安全性测试
稳定性测试
浏览器兼容性测试
可用性/易用性测试
链接测试
代码合法性测试
2 测试内容
2.1 功能测试
在实际工作中，功能在每一个系统中的具有其不确定性，而我们不可能采用穷举的方法进行测试，因而导致了功能测试较为困难，我们依据80/20原则（即80%的错误存在于系统的20%的部分）对于测试用例的设计采用如下两种方法
2.1.1 白盒测试
白盒测试即使用程序设计的控制结构导出测试用例。基于目前的现状我们采用基本路径测试方法进行白盒测试，此种方法简单高效。基本路径测试方法的简单说明如下：
¨ 首先通过系统设计的流程图导出数据流图
¨ 根据数据流图计算其环形复杂性
V(G)=E-N+2
或 V(G)=P+1
V(G)：环形负责性
E ：流图中边的数量
N ：流图中节点的数量
P ：流图中判定节点的数量
¨ 我们设定V(G)条路径
¨ 我们设计V(G)条路径的模拟数据
¨ 根据数据进行相应的测试
2.1.2 黑盒测试
黑盒测试即派生出执行程序所有功能需求的输入条件，从而导出测试用例，进行测试的方法，黑盒测试用于辅助白盒测试。
我们采用等价划分的方法进行测试，即为将程序的输入域划分为数据类，以便导出测试用例。一般情况下输入条件为：一个特定的数值、一个数值域、一组相关值或者一个布尔条件。
2.1.3 网站功能测试
对于网站的测试而言，每一个独立的功能模块需要单独的测试用例的设计导出，主要依据为《需求分析》，对于应用程序模块需要设计者提供基本路径测试法的测试用例
具有测试用例后可以采用OpenSTA(Open System Testing Architecture)进行自动化测试
2.2 性能测试
网站的性能测试对于网站的运行而言异常重要，但是目前对于网站的性能测试做的不够，我们在进行系统设计时也没有一个很好的基准可以参考，因而建立网站的性能测试的一整套的测试方案将是至关重要的。
网站的性能测试主要从两个方面进行：负荷测试(Load)和压力测试(Stress),负荷测试指的是进行一些边界数据的测试，压力测试更像是恶意测试，压力测试倾向应该是致使整个系统崩溃。
性能测试可以采用相应的工具进行自动化测试，我们目前采用如下工具
ab -----Apache 的测试工具
OpenSTA—开发系统测试架构
2.3 安全性测试
目前网络安全问题日益重要，特别对于有交互信息的网站及进行电子商务活动的网站尤其重要。目前我们的测试没有涵盖网站的安全性的测试，我们拟定采用工具来测定，工具如下
SAINT------- Security Administrator';s Integrated Network Tool
此工具能够测出网站系统的相应的安全问题，并且能够给出安全漏洞的解决方案，不过是一些较为常见的漏洞解决方案。
2.4 稳定性测试
网站的稳定性测试是指网站的运行中整个系统是否运行正常，目前没有更好的测试方案，主要采用将测试服务器长时间运转进行测试。
2.5 浏览器兼容性测试
通过白盒测试或者黑盒测试导出的测试用例，采用相应的工具进行测试，可以采用OpenSTA进行测试，此测试工具可以采用不同的浏览器进行测试。
2.6 可用性/易用性测试
可用性/易用性方面目前我们只能采用手工测试的方法进行评判，而且缺乏一个很好的评判基准进行，此一方面需要大家共同讨论。
2.7 链接测试
超级链接对于网站用户而言意味着能不能流畅的使用整个网站提供的服务，因而链接将作为一个独立的项目进行测试。目前我们已经有了一个测试工具
Xenu------主要测试链接的正确性的工具
可惜的是对于动态生成的页面的测试会出现一些错误。
2.8 代码合法性测试
代码合法性测试主要包括2个部分：程序代码合法性检查与显示代码合法性检查
¨ 程序代码合法性检查
程序代码合法性检查主要标准为《intergrp小组编程规范》，目前采用由SCM管理员进行规范的检查，未来期望能够有相应的工具进行测试。
¨ 显示代码合法性检查
显示代码的合法性检查，主要分为Html、JavaScript、Css代码检查，目前采用
HTML代码检查------采用CSE HTML Validator进行测试
JavaScript、Css也可以在网上下载相应的测试工具。
3 测试工具
OpenSTA
主要做性能测试的负荷及压力测试，使用比较方便，可以编写测试脚本，也可以先行自动生成测试脚本，而后对于应用测试脚本进行测试。
SAINT
网站安全性测试，能够对于指定网站进行安全性测试，并可以提供安全问题的解决方案。
CSE HTML Validator
一 个有用的对于HTML代码进行合法性检查的工具
Ab(Apache Bench)
Apache自带的对于性能测试方面的工具，功能不是很多，但是非常实用。
Crash-me
Mysql自带的测试数据库性能的工具，能够测试多种数据库的性能。
上述工具除Ab及Crash-me外均可在以下目录中找得到
[url=文件://smbserver/apps/linuxapp/intergrp]/smbserver/apps/linuxapp/intergrp[/url]
ab及Crash-me请至相应的网站上察看相应的资料}
4 后记
此文只是对于网站的测试方面做了一个简单的介绍，提供的工具比较少，但是可以保证能够使用（当然都是可以从网上免费得到的），另外还有很多测试工具是需要Money的，大家有兴趣可以试用，对于上述提到的测试工具我也只是做了一个初步的调研，详细的功能说明请察看相关的说明文档。
对于网站的测试中比较重要的还有一个部分就是对于数据库的测试，由于对于数据库性能测试较好的工具需要一些Money因而我们采用Mysql的Crash-me,但是同时也存在一个问题就是对于不同的数据库的测试采用第三方的工具较好。因而大家可以对于其他数据库性能测试的工具进行研究。
5 参考资料
(1)《软件工程-实践者的研究方法》-----Roger S.Pressman
(2) http://www.softwareqatest.com
(3) http://www.soft.com/
(4) http://www.qaforums.com
(5) http://www.opensta.org
[color=#0000FF] WEB应用程序测试方法和测试技术详述
1. 概述
随着 web 应用的增多，新的模式解决方案中以 web 为核心的应用也越来越多， 很多公司各种应用的架构都以 B/S 及 web 应用为主，但是有关 WEB 测试方面的内容并没有相应的总结，所以我在这里对 web 的测试方法和采用的测试技术进行总结，便于内部交流。
测试方法尽量涵盖 web 程序的各个方面，测试技术方面在继承传统测试技术的技术上结合 web 应用的特点。
2. 测试方法
说明：测试方法的选择取决你的测试策略。
一般的 web 测试和以往的应用程序的测试的侧重点不完全相同，基本包括以下几个方面。
当然圆满的完成测试还要有好的团体和流程等的方方面面的支持，你同样应该对这些方面进行注意。有些测试方法设计到了流程，哪些应该在你的测试团队建设中建立。
2.1 界面测试
现在一般人都有使用浏览器浏览网页的经历，用户虽然不是专业人员但是对界面效果的印象是很重要的。如果你注重这方面的测试，那么验证应用程序是否易于使用就非常重要了。很多人认为这是测试中最不重要的部分，但是恰恰相反界面对不懂技术的客户来说那相当关键，慢慢体会你会明白的。
方法上可以根据设计文档，如果够专业的话可以专业美工人员，来确定整体风格页面风格，然后根据这个可以页面人员可以生成静态的 HTML ， CSS 等甚至生成几套不用的方案来讨论，或者交给客户评审，最后形成统一的风格的页面 / 框架。注意不要靠程序员的美术素养形成你的 web 风格，那样可能会很糟糕。
主要包括以下几个方面的内容：
- 站点地图和导航条 位置、是否合理、是否可以导航等内容布局 布局是否合理，滚动条等简介说明 说明文字是否合理，位置，是否正确；
- 背景 / 色调 是否正确、美观，是否符合用户需求；
- 页面在窗口中的显示是否正确、美观（在调整浏览器窗口大小时，屏幕刷新是否正确）表单样式 大小，格式，是否对提交数据进行验证（如果在页面部分进行验证的话）等；
- 连接 连接的形式，位置，是否易于理解等。
web测试的主要页面元素
- 页面元素的容错性列表（如输入框、时间列表或日历）；
- 页面元素清单（为实现功能，是否将所需要的元素全部都列出来了，如按钮、单选框、复选框、列表框、超连接、输入框等等）；
- 页面元素的容错性是否存在；
- 页面元素的容错性是否正确；
- 页面元素基本功能是否实现（如文字特效、动画特效、按钮、超连接）；
- 页面元素的外形、摆放位置（如按钮、列表框、核选框、输入框、超连接等）；
- 页面元素是否显示正确（主要针对文字、图形、签章）；
- 元素是否显示（元素是否存在）；
- 页面元素清单（为实现功能，是否将所需要的元素全部都列出来了，如按钮、单选框、复选框、列表框、超连接、输入框等等）。
测试技术
- 通过页面走查，浏览确定使用的页面是否符合需求。可以结合兼容性测试对不用分辨率下页面显示效果，如果有影响应该交给设计人员提出解决方案；
- 可以结合数据定义文档查看表单项的内容，长度等信息；
- 对于动态生成的页面最好也能进行浏览查看。如 Servelet 部分可以结合编码规范，进行代码走查。是否支持中文，如果数据用 XML 封装要做的工作会多一点等等。
2.1.l 界面测试要素 :
符合标准和规范 , 灵活性 , 正确性 , 直观性 , 舒适性 , 实用性 , 一致性
2.1.l.1 直观性 :
- 用户界面是否洁净, 不唐突, 不拥挤. 界面不应该为用户制造障碍 . 所需功能或者期待的响应应该明显 , 并在预期出现的地方；
- 界面组织和布局合理吗? 是否允许用户轻松地从一个功能转到另一个功能? 下一步做什么明显吗? 任何时刻都可以决定放弃或者退回, 退出吗? 输入得到承认了吗? 菜单或者窗口是否深藏不露?
- 有多余功能吗? 软件整体抑或局部是否做得太多? 是否有太多特性把工作复杂化了? 是否感到信息太庞杂?
- 如果其他所有努力失败 , 帮助系统真能帮忙吗?
2.1.l.2 一致性
- 快速键和菜单选项 . 在 Windows 中按 F1 键总是得到帮助信息；
- 术语和命令. 整个软件使用同样的术语吗? 特性命名一致吗? 例如, Find 是否一直叫Find, 而不是有时叫Search?
- 软件是否一直面向同一级别用户? 带有花哨用户界面的趣味贺卡程序不应该显示泄露技术机密的错误提示信息；
- 按钮位置和等价的按键 . 大家是否注意到对话框有 OK 按钮和 Cancle 按钮时, OK 按钮总是在上方或者左方, 而 Cancle 按钮总是在下方或右方? 同样原因, Cancle 按钮的等价按键通常是 Esc, 而选中按钮的等价按钮通常是 Enter. 保持一致。
2.1.l.3 灵活性
状态跳转：灵活的软件实现同一任务有多种选择方式；
状态终止和跳过：具有容错处理能力；
数据输入和输出：用户希望有多种方法输入数据和查看结果 . 例如 , 在写字板插入文字可用键盘输入 , 粘贴, 从 6 种文件格式读入 , 作为对象插入 , 或者用鼠标从其他程序拖动。
2.1.l.4 舒适性
恰当：软件外观和感觉应该与所做的工作和使用者相符；
错误处理：程序应该在用户执行严重错误的操作之前提出警告 , 并允许用户恢复由于错误操作导致丢失的数据，如大家认为 undo /redo 是当然的；
性能：快不见得是好事，要让用户看得清程序在做什么，它是有反应的。
2.2 功能测试
功能测试是测试中的重点，主要包括一下几个方面的内容：
连接：这个连接和界面测试中的连接不同。那里注重的是连接方式和位置，如是图像还是文字放置的位置等，还是其他的方式；这里的连接注重功能，如是否有连接，连接的是否是说明的位置等；
表单提交：应当模拟用户提交，验证是否完成功能，如注册信息，要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。还有数据正确性验证，异常处理等，最好结合易用性要求等。 B/S 结构实现的功能可能主要的就在这里，提交数据，处理数据等如果有固定的操作流程可以考虑自动化测试工具的录制功能，编写可重复使用的脚本代码，可以在测试、回归测试时运行以便减轻测试人员工作量；
Cookies 验证：如果系统使用了 cookie ，测试人员需要对它们进行检测。如果在 cookies 中保存了注册信息，请确认该 cookie 能够正常工作而且已对这些信息已经加密。如果使用 cookie 来统计次数，需要验证次数累计正确。关于 cookie 的使用可以参考浏览器的帮助信息。如果使用 B/S 结构 cookies 中存放的信息更多；
功能易用性测试 完成了功能测试可以对应用性进行了解，最好听听客户的反映，在可以的情况下对程序进行改进是很有必要的，和客户保持互动对系统满意度也是很有帮助的。
2. 2.1 测试技术
功能测试的测试技术可是很多的，我们可以结合实际环境选择使用。
白盒测试技术(White Box Testing)： 深入到代码一级的测试，使用这种技术发现问题最早，效果也是最好的。该技术主要的特征是测试对象进入了代码内部，根据开发人员对代码和对程序的熟悉程度，对有需要的部分进行在软件编码阶段，开发人员根据自己对代码的理解和接触所进行的软件测试叫做白盒测试。这一阶段测试以软件开发人员为主，在 JAVA 平台使用 Xunit 系列工具进行测试， Xunit 测试工具是类一级的测试工具对每一个类和该类的方法进行测试。
黑盒测试技术(Black Box Testing)：黑盒测试的内容主要有以下几个方面，但是主要还是功能部分。主要是覆盖全部的功能，可以结合兼容，性能测试等方面进行，根据软件需求，设计文档，模拟客户场景随系统进行实际的测试，这种测试技术是使用最多的测试技术涵盖了测试的方方面面，可以考虑以下方面
正确性 (Correctness) ：计算结果，命名等方面。 Ø
可用性 (Usability) ：是否可以满足软件的需求说明。 Ø
边界条件 (Boundary Condition) ：输入部分的边界值，就是使用一般书中说的等价类划分，试试最大最小和非法数据等等。 Ø
性能(Performance)： 正常使用的时间内系统完成一个任务需要的时间，多人同时使用的时候响应时间在可以接受范围内。 J2EE 技术实现的系统在性能方面更是需要照顾的，一般原则是 3 秒以下接受， 3-5 秒可以接受， 5 秒以上就影响易用性了。如果在测试过程中发现性能问题，修复起来是非常艰难的，因为这常常意味着程序的算法不好，结构不好，或者设计有问题。因此在产品开发的开始阶段，就要考虑到软件的性能问题
压力测试(Stress)： 多用户情况可以考虑使用压力测试工具，建议将压力和性能测试结合起来进行。如果有负载平衡的话还要在服务器端打开监测工具 , 查看服务器 CPU 使用率，内存占用情况，如果有必要可以模拟大量数据输入，对硬盘的影响等等信息。如果有必要的话必须进行性能优化 ( 软硬件都可以 ) 。这里的压力测试针对的是某几项功能。
错误恢复(Error Recovery)：错误处理，页面数据验证，包括突然间断电，输入脏数据等。
安全性测试(Security)：这个领域正在研究中，防火墙、补丁包、杀毒软件等的就不必说了，不过可以考虑。破坏性测试时任意看了一些资料后得知 , 这里面设计到的知识 / 内容可以写本书了 , 不是一两句可以说清的，特别是一些商务网站，或者跟钱有关，或者和公司秘密有关的 web 更是需要这方面的测试，在外国有一种专门干这一行的人叫安全顾问，可以审核代码，提出安全建议，出现紧急事件时的处理办法等，在国内没有听说哪里有专门搞安全技术测试的内容。
兼容性(Compatibility)：不同浏览器，不同应用程序版本在实现功能时的表现不同的上网方式，如果你测试的是一个公共网站的话。
兼容性测试内容详述：
- 硬件平台
- 浏览器软件和版本：浏览器插件，浏览器选项，视频分辨率和色深，文字大小，调制解调器速率 .
软件配置 (Configuration)：如 IE 浏览器的不用选项 - 安全设定最高，禁用脚本程序等等，你们的程序在各种不用的设置下表现如何。
2. 2.2 单元测试技术 (Unit Test):
2. 2.2.1 下面是对白盒测试和单元测试的区别的论述 :
单元测试和白盒测试是不同的，虽然单元测试和白盒测试都是关注功能，他们都需要代码支持，但是级别不同。白盒测试关注的是类中一个方法的功能，是更小的单位，但是完成一个单元测试可能需要 N 多类，所以说作单元测试需要写驱动和稳定桩，比如查询单元是一个查询包，包括 N 多的测试类、测试数据，运行他需要提供数据的部分，输入参数和发出命令的驱动等等，是比类大的一个整体进行的。
另一个明显的区别是白盒测试不会关注类接口，但是单元测试主要的内容就是类接口测试。
不过很多时候是很少区分的，因为这两种技术实现起来有很多相互关联的部分。不过要看你对质量的关注程度来决定。
2. 2.2.2 功能测试边界测试 / 越界测试技术详述
边界条件
边界条件是指软件计划的操作界限所在的边缘条件，如果软件测试问题包含确定的边界，那么数据类型可能是：数值、速度、字符、地址、位置、尺寸、数量。同时，考虑这些类型的下述特征：第一个 / 最后一个、最小值 / 最大值、开始 / 完成、超过 / 在内、空 / 满、最短 / 最长、最慢 / 最快、最早 / 最迟、最大 / 最小、最高 / 最低、相邻 / 最远。
越界测试
通常是简单加 1 或者很小的数 ( 对于最大值 ) 和减少 1 或者很小的数 ( 对于最小值 ) ，例如：第一个减 1/ 最后一个加 1 、开始减 1/ 完成加 1 、空了再减 / 满了再加、慢上加慢 / 快上加快、最大数加 1/ 最小数减 1 、最小值减 1/ 最大值加 1 、刚好超过 / 刚好在内、短了再短 / 长了再长、早了更早 / 晚了更晚、最高加 1/ 最低减 1 。
另一些该注意的输入：默认，空白，空值，零值和无；非法，错误，不正确和垃圾数据。
2. 2.2.3 状态测试技术
- 软件可能进入的每一种独立状态；
- 从一种状态转入另一种状态所需的输入和条件；
- 进入或退出某种状态时的设置条件及输入结果。
具体测试方法可以参考如下：
- 每种状态至少访问一次；
- 测试看起来最常见最普遍的状态转换；
- 测试状态之间最不常用的分支；
- 测试所有错误状态及其返回值；
- 测试随机状态转换。
2. 2.2.4 竞争条件测试技术
竞争条件典型情形参考如下 :
- 两个不同的程序同时保存或打开同一个文档；
- 共享同一台打印机 , 通信端口或者其他外围设备；
- 当软件处于读取或者修改状态时按键或者单击鼠标；
- 同时关闭或者启动软件的多个实例；
- 同时使用不同的程序访问一个共同数据库。
2. 2.3 负载 / 压力测试 (StressTest)
在这里的负载 / 压力和功能测试中的不同，他是系统测试的内容，是基本功能已经通过后进行的。可以在集成测试阶段，亦可以在系统测试阶段进行。
使用负载测试工具进行，虚拟一定数量的用户看一看系统的表现，是否满足定义中的指标。
负载测试一般使用工具完成， loadrunner ， webload ， was ， ewl ， e-test 等，主要的内容都是编写出测试脚本，脚本中一般包括用户常用的功能，然后运行，得出报告。所以负载测试包括的主要内容就不介绍了。
负载测试技术在各种极限情况下对产品进行测试 ( 如很多人同时使用该软件，或者反复运行该软件 ) ，以检查产品的长期稳定性。例如，使用压力测试工具对 web 服务器进行压力测试。本项测试可以帮助找到一些大型的问题，如死机、崩损、内存泄漏等，因为有些存在内存泄漏问题的程序，在运行一两次时可能不会出现问题，但是如果运行了成千上万次，内存泄漏得越来越多，就会导致系统崩滑。用 J2EE 实现的系统很少但是并不是没有内存问题。
无论什么工具基本的技术都是利用线程技术模仿和虚拟用户，在这里主要的难点在与测试脚本的编写，每种工具使用的脚本都不一样，但是大多数工具都提供录制功能就算是不会编码的测试人员同样可以测试。
对负载工具的延伸使用可以进行系统稳定性测试，系统极限测试，如使用 100 的 Load Size 连续使用 24 小时，微软定义的通过准则是通过 72 小时测试的程序一般不会出现稳定性的问题。
2. 2.4 回归测试 (Regression Test)
过一段时间以后，再回过头来对以前修复过的 Bug 重新进行测试，看该 Bug 是否会重新出现。
回归测试技术可以在测试的各个阶段出现，无论是单元测试还是集成测试还是系统测试。是对以前问题进行验证的过程。
回归测试的目的就是保证以前已经修复的 Bug 不会再出现。实际上，许多 Bug 都是在回归测试时发现的，在此阶段，我们首先要检查以前找到的 Bug 是否已经更正了。值得注意的是，已经更正的 Bug 也可能又回来了，有的 Bug 经过修改之后可能又产生了新的 Bug 。所以，回归测试可保证已更正的 Bug 不再重现，不产生新的 Bug 。
2. 2.5 Alpha 和 Beta 测试 (Alpha and Beta Test):
在正式发布产品之前往往要先发布一些测试版，让用户能够反馈出相关信息，或者找到存在的 Bug ，以便在正式版中得到解决。
特别是在有客户参加的情况下，对系统进行测试可能会出现一些我们没有考虑的情况，还可以解决一些客户实际关心的问题。
不同的测试技术区分
2.3 覆盖测试技术
说明 : 测试覆盖率可以看出测试的完成度，在测试分析报告中可以作为量化指标的依据，测试覆盖率越高效果越好。
覆盖测试可以是程序代码的执行路径覆盖，亦可以是功能实现的步骤覆盖（可以理解成流程图的路径覆盖）。
该技术可以用在任何测试阶段，包括单元测试、集成测试、系统测试。
使用该技术时可以使用以上的任何测试方法和测试技术。
2.4 白盒测试和黑盒测试技术
白盒测试技术 (White Box Testing) ：该技术主要的特征是测试对象进入了代码内部，根据开发人员对代码和对程序的熟悉程度，对有需要的部分进行测试。在软件编码阶段，开发人员根据自己对代码的理解和接触所进行的软件测试叫做白盒测试。这一阶段测试以软件开发人员为主，使用 Xunit 系列工具进行测试，可以包括很多方面如功能性能等。
黑盒测试 (Black Box Testing) ：测试的主体部分，黑盒测试的内容主要有以下几个方面，但是主要还是功能部分。主要是覆盖全部的功能，可以结合兼容，性能测试等方面进行，包括的不同测试类型请参考以上内容。
2.5 手工测试和自动化测试
手工测试 （ Manual Testing ）：即依靠人力来查找 Bug 。方法可以参考上边的测试，也可以根据对实现技术及经验等进行不同的测试。
自动测试 （ Automation Testing ）：使用有针对工具实行。可以作出自动化测试的计划，对可以进行自动化测试的部分编写或者录制相应的脚本，可以加入功能，容错，表单提交等，可以参考 MI,Rational 或者其他类测试工具说明。
根据权威的软件测试经验，手工测试还是主要的测试方法，自动测试不够灵活，在这里不再详述。微软的测试过程 80 ％还是手工完成。
自动测试永远也代替不了手工测试，但是手工测试的工作量很大是不争的事实。
2.6 根据 RUP 标准按阶段区分测试
单元测试：在上边有详细的叙述，还有针对单元测试和集成测试的论述，请参考。
集成测试：分为功能集成测试和系统集成测试，相互有调用的功能集成，在系统环境下功能相互调用的影响等，使用方法可以任意选用上面的内容。注重功能方面。
系统测试：在功能实现的基础上，可以加入兼容性，易用性，性能等等。
验收测试：可以包括 Alpha 和 Beta 测试，在这里就不再详述。
3. 存在风险及解决方法
说明：测试不能找出所有的问题，只是尽量在开发阶段解决大多数的问题而已。
测试风险如下：
软硬件的测试环境提供上也对测试结果有很大的影响；
测试团队的水平，经验，合作效果等；
整个开发流程对测试的重视程度，测试的进入时间等；
由于测试环境操作系统，网络环境，带宽等情况可能产生的测试结果可能不同这是就需要经验以及对测试环境的保护等方面下一些功夫。
4. 软件缺陷的原则
软件缺陷区别于软件 bug, 它是在测试过程中出现的对系统有影响的，但是在设计中没有的或者对修改后的 bug 测试和开发人员有不同意见等。
- 软件未达到产品说明书标明的功能；
- 软件出现了产品说明书指明不会出现的错误；
- 软件功能超出产品说明书指明范围；
- 软件未达到产品说明书虽未指出但应达到的目标；
- 软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。
5. 文档测试
产品说明书属性检查清单
完整：是否有遗漏和丢失？完全吗？单独使用是否包含全部内容？
准确：既定解决方案正确吗？目标明确吗？有没有错误？
精确：不含糊，清晰。描述是否一清二楚？还是自说自话？容易看懂和理解吗？
一致：产品功能描述是否自相矛盾？与其他功能有没有冲突 ?
贴切：描述功能的陈述是否必要 ? 有没有多余信息 ? 功能是否满足的客户要求 ?
合理：在特定的预算和进度下，以现有人力，物力和资源能否实现 ?
代码无关：是否坚持定义产品，而不是定义其所信赖的软件设计，架构和代码 ?
可测试性：特性能否测试 ? 测试员建立验证操作的测试程序是否提供足够的信息 ?
产品说明书用语检查清单
说明：对问题的描述通常表现为粉饰没有仔细考虑的功能 ---- 可归结于前文所述的属性。从产品说明书上找出这样的用语，仔细审视它们在文中是怎样使用的。产品说明书可能会为其掩饰和开脱 , 也可能含糊其词 ---- 无论是哪一种情况都可视为软件缺陷。
- 总是，每一种，所有，没有，从不。如果看到此类绝对或肯定的，切实认定的叙述，软件测试员就可以着手设计针锋相对的案例。
- 当然，因此，明显，显然，必然。这些话意图诱使接受假定情况，不要中了圈套。
- 某些，有时，常常，通常，惯常，经常，大多，几乎。这些话太过模糊， " 有时 " 发生作用的功能无法测试。
等等，诸如此类，依此类推。以这样的词结束的功能清单无法测试，功能清单要绝对或者解释明确，以免让人迷惑，不知如何推论。
- 良好，迅速，廉价，高效，小，稳定。这些是不确定的说法，不可测试。如果在产品说明书中出现，就必须进一步指明含义。
- 已处理，已拒绝，已忽略，已消除。这些廉洁可能会隐藏大量需要说明的功能。
- 如果 ... 那么 ...( 没有否则 ) 。找出有 " 如果 ... 那么 ..." 而缺少配套的 " 否则 " 结构的陈述，想一想 " 如果 " 没有发生会怎样。
[color=#008B8B] 网页设计制作标准规范
[color=#008B8B] 网站工程的管理与规范
[color=#008B8B] 网站项目管理规范手册
[color=#008B8B] 网站软件开发规范(某门户网站的)
[color=#008B8B] 网站制作规范
[color=#008B8B] Web 测试的经验
[color=#008B8B] Web测试手段
[color=#008B8B] 对Web服务进行压力测试
[color=#008B8B] 基于Web的系统测试方法
[color=#008B8B] Web下的整体测试
[color=#008B8B] 网站测试技术简介
[color=#008B8B] WEB应用程序测试方法和测试技术详述
[color=#0000FF] 网页设计制作标准规范
// 总 论
本规范既是一个开发规范，也是一个脚本语言参考，本规范并不是一个一成不变的必须严格遵守的条文，特殊情况下要灵活运用，做一定的变通。但是，请大家千万不要随意更改规范。如果有任何问题，请及时与我联系，我会及时更改本规范的相关代码样例和文档。
/ 基 本 要 求
1. 在网站根目录中开设images、common、temp 三个子目录，根据需要再开设media 子目录，images目录中放不同栏目的页面都要用到的公共图片，例如公司的标志、banner 条、菜单、按钮等等；common 子目录中放css、js、php、include 等公共文件；temp 子目录放客户提供的各种文字图片等等原始资料；media 子目录中放flash、avi、quick time 等多媒体文件 。
2. 在根目录中原则上应该按照首页的栏目结构，给每一个栏目开设一个目录，根据需要在每一个栏目的目录中开设一个images 和media 的子目录用以放置此栏目专有的图片和多媒体文件，如果这个栏目的内容特别多，又分出很多下级栏目，可以相应的再开设其他目录。
3. temp 目录中的文件往往会比较多，建议以时间为名称开设目录，将客户陆续提供的资料归类整理。
4. 除非有特殊情况，目录、文件的名称全部用小写英文字母、数字、下划线的组合，其中不得包含汉字、空格和特殊字符；目录的命名请尽量以英文为指导，不到万不得已不要以拼音作为目录名称，经验证明，用拼音命名的目录往往连一个月后的自己都看不懂，
/ 脚 本 编 写
我们应该有一个脚本整体风格一致的概念，意思是一个月后和一个月前的你写的脚本风格保持一致，以及同一个工作组中不同的开发人员编写的脚本风格保持一致，因为我们不可能永远孤立的开发，你随时都有可能和三个月前的自己合作（你的客户要求改版），也经常要和工作室中不同的同事共同开发一个项目，还有可能被要求修改已经离职人员开发的脚本，当然你自己也有可能会扔下一个项目给后来的同事。
1. html 文件的通用模板：
<html>
<!--
Generator: Sub Design Studio
Creation Data: 2005-8-1
Original Author:
-->
<head>
<title> 文档标题 </title>
<meta http-equiv="content-type" content="text/html; charset=gb2312">
<meta name="author" content="eastline">
其他meta 标 记
<link rel="stylesheet" type="text/css" href="style/style.css">
样式表定义
客户端Javascript 函数定义及初始化操作
</head>
<body bgcolor="#ffffff">
… …
</body>
补充：
为了保证网站能够与下一代的web 语言xml 标准兼容，所有的HTML 标签的属性都要用单引号或者双引号括起，即我们应该写 <a href="url"> 而不 是 <a href=url>.
2. 允许全文检索的页面，为了使Internet 上的搜索引擎能够有效检索，在频道的首页的html的<head></head>之间应该加入Keywords 和Description 元标记，例如：
<meta name=”keywords” content=”东方新干线，汽车，买车”>
<meta name=”description” content=”东方新干劲线，全球中文汽车信息第一站”>
3. CSS 文件的格式样例代码：
<style type="text/css">
<!—
p { text-indent: 2em; }
body { font-family: "宋体"; font-size: 9pt; color: #000000; margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px}
table { font-family: "宋体"; font-size: 9pt; line-height: 20px; color: #000000}
a:link { font-size: 9pt; color: #FFFFFF; text-decoration: none}
a:visited { font-size: 9pt; color: #99FFFF; text-decoration: none}
a:hover { font-size: 9pt; color: #FF9900; text-decoration: none}
a:active { font-size: 9pt; color: #FF9900; text-decoration: none}
a.1:link { font-size: 9pt; color: #3366cc; text-decoration: none}
a.1:visited { font-size: 9pt; color: #3366cc; text-decoration: none}
a.1:hover { font-size: 9pt; color: #FF9900; text-decoration: none}
a.1:active { font-size: 9pt; color: #FF9922; text-decoration: none}
.blue { font-family: "宋体"; font-size: 10.5pt; line-height: 20px; color: #0099FF; letter-spacing: 5em}
-->
</style>
这里尤其要注意的是a:link a:visited a:hover a:actived 的排列顺序一定要严格照上面的样例代码，否则或多或少会出问题。另外我们规定重定义的最先，伪类其次，自定义最后，便于自己和他人阅读！
为了保证不同浏览器上字号保持一致，字号建议用点数pt和像素px来定义，pt一般使用中文宋体的9pt 和11pt，px一般使用中文宋体12px 和14.7px 这是经过优化的字号，黑体字或者宋体字加粗时，一般选用11pt 和14.7px 的字号比较合适。
在写 <table> 互相嵌套时，严格按照的规范，对于单独的一个<table>来说，<table><tr>对齐，<td> 缩进两个半角空格，<td> 中如果还有嵌套的表格?lt;table>也缩进两个半角空格，如果<td>中没有任何嵌套的表格，</td> 结束标记应该与 <td> 处于同一行，不要换行，
如我们注意在源代码中不应有这样的代码：
<td><img src="../images/sample.gif">
</td>
而应该是这样的：
<td><img src="../images/sample.gif"></td>
这是因为浏览器认为换行相当于一个半角空格，以上不规范的写法相当于无意中增加一个半角空格，如果确实有必要增加一个半角空格，也应该这样写：
<td><img src="../images/sample.gif"> </td>
属于同一个级别 的 <table> 一定是左首对齐的，另外不允许没有任何内容的空的单元格存在，高度大于等于12px 的单元格应该 在 <td> 和 </td> 之间写一 个 如果高度小于12px, 则应该 在 <td> 和 </td> 之间插入一个1*1 大小的透明的gif 图片，这是因为某些浏览器认为空单元格非法而不会予以解释。如果代码顺序较乱，在DW3中可以通过command->apply souce formatting进行重新整理！
5. width 和height 的写法也有统一的规范，一般情况下只有一列的表格，width 写在<table> 的标签内，只有一行的表格，height 写在 <table> 的标签内，多行多列的表格，width 和height 写在第一行或者第一列的 <td> 标签内。总之遵循一条原则：不出现多于一个的控制同一个单元格大小的height 和width, 保证任何一个width 和height 都是有效的，也就是你改动代码中任何一个width 和height 的数值，都应该在浏览器中看到变化。做到这一条不容易，需要较长时间的练习和思考。
/ 一 般 原 则
1. 在排布表格之前，请大家一定要好好思考一个最佳的方案，表格的嵌套尽量控制在三层以内，并且应该尽量避免 <colspan> <rowspan> 两个标记，经验表明，这两个标记会带来许多麻烦。
2. 一个网页要尽量避免用整个一张大表格，所有的内容都嵌套在这个大表格之内，因为浏览器在解释页面的元素时，是以表格为单位逐一显示，如果一张网页是嵌套在一个大表格之内，那么很可能造成的后果就是，当浏览者敲入网址，他要先面对一片空白很长时间，然后所有的网页内容同时出现。如果必须这样做，请使用 <tbody>标记，以便能够使这个大表格分块显示。
3. 排版中我们经常会遇到需要进行首行缩进的处理，不要使用 或者全角空格来达到效果，规范的做法是在样式表中定义 p { text-indent: 2em; } 然后给每一段加上 <p> 标记，注意，一般情况下，请不要省略 </p> 结束标记 。
4. 原则上，我们禁止用 <img width=? height=?> 来人为干预图片显示的尺寸，而且建议 <img> 标签中不要带上width 和height 两个属性，这是因为制作过程中，图片往往需要反复的修改，这样可以避免人为干预图片显示的尺寸，尽可能的发挥浏览器自身的功能；但是这样的一个副作用是当网页还未加载图片时，不会留出图片的站位大小，可能会造成网页在加载过程中抖动（如果图片是插在一个固定大小的表格里的，不会有这个现象），尤其是当图片的尺寸较大时，这种现象会很明显，所以当预料到这种会明显导致网页抖动的情况会发生时，请大家务必在最后给 <img>附上 width 和 height 属性。
5. 为了最大程度的发挥浏览器自动排版的功能，在一段完整的文字中请尽量不要使用<br> 来人工干预分段。
6. 不同语种的文字之间应该有一个半角空格，但避头的符号之前和避尾的符号之后除外汉字之间的标点要用全角标点，英文字母和数字周围的括号应该使用半角括号。
7. 所有的字号都应该用样式表来实现，禁止在页面中出现 <font size=?> 标记。
8. 请不要在网页中连续出现多于一个 的 也尽量少使用全角空格（英文字符集下，全角空格会变成乱码），空白应该尽量使用 text-indent, padding, margin, hspace, vspace 以及透明的gif 图片来实现。
9. 中英文混排时，我们尽可能的将英文和数字定义为verdana 和arial 两种字体。
10. 行距建议用百分比来定义，常用的两个行距的值是line-height:120%/150%.
11. 网站中的路径全部采用相对路径，一般链接到某一目录下的缺省文件的链接路径不必写全名，如我们不必这样：<a href="aboutus/index.htm"> 而应该这样：<a href="aboutus/">
12、嵌入图形文本的使用较大的字体，建议不要在图形中包括文本。
13、“网页大小”定义为网页的所有文件大小的总和，包括HTML文件和所有的嵌入的对象。用户喜欢快的而不是新奇的站点。对于解调器用户，网页大小保持在34K以下为合适。
/ 文 件 命 名 原 则
1. 每一个目录中应该包含一个缺省的html 文件，文件名统一用index.htm
2. 文件名称统一用小写的英文字母、数字和下划线的组合。
3. 命名原则的指导思想一是使得你自己和工作组的每一个成员能够方便的理解每一个文件的意义，二是当我们在文件夹中使用“按名称排例”的命令时，同一种大类的文件能够排列在一起，以便我们查找、修改、替换、计算负载量等等操作 。
4. 下面以“新闻”（包含“国内新闻”和“国际新闻”）这个栏目来说明html 文件的命名原则：
在根目录下开设news目录
第一条缺省新闻取名index.htm
所有属于“国内新闻”的新闻依次取名为：china_1.htm, china_2.htm, …
所有属于“国际新闻”的新闻依次取名为：internation_1.htm, internation _2.htm, …
如果文件的数量是两位数，请将前九个文件命名为：china_01.htm, china_02.htm 以保证所有的文件能够在文件夹中正确排序。
5. 图片的命名原则遵循以下几条规范：
名称分为头尾两两部分，用下划线隔开。
头部分表示此图片的大类性质，例如广告、标志、菜单、按钮等等。
一般来说:
放置在页面顶部的广告、装饰图案等长方形的图片我们取名：banner
标志性的图片我们取名为：logo
在页面上位置不固定并且带有链接的小图片我们取名为button
在页面上某一个位置连续出现，性质相同的链接栏目的图片我们取名：menu
装饰用的照片我们取名：pic
不带链接表示标题的图片我们取名：title
依照此原则类推。
尾部分用来表示图片的具体含义。
下面是几个样例，大家应该能够一眼看明白图片的意义：
banner_sohu.gif banner_sina.gif menu_aboutus.gif menu_job.gif title_news.gif logo_police.gif logo_national.gif pic_people.jpg pic_hill.jpg.
[color=#0000FF] 网站工程的管理与规范
导读
随着网络的发展，网站建设和制作已初步形成一个行业，本文尝试就这个行业的管理和规范提出网站工程的概念，并系统介绍了整个网站建设的过程以及过程中的问题的解决办法。纯属作者自己的见解和经验，供广大网站设计制作人员，网站系统分析员和项目经理借鉴。
--------------------------------------------------------------------------
随着互联网的发展，网站制作作为一个行业已经悄悄的兴起，越来越多的网站制作任务需要网页制作公司完成，越来越多的问题出现在网站制作的过程中。例如：不能按期完成制作，不能使客户满意，费用超出预算等等。仔细分析原因，发现大部分失败的原因有以下几点：
a.忽视客户的不断变化的需求；
b.没有保留历史文档作决策参考；
c.忽视监督项目进度；
d.忽视不断的测试和修改；
e.没有使用专业的项目管理软件，靠主观决策。
问题发现了，有没有一个好的解决办法可以减少失误，控制和管理网站制作呢？
网站开发制作是一个很复杂的工作，可以将它看做一个项目来管理。作者参考了国际国内有关项目管理的资料，发现软件工程的管理方法和规范与网站建设项目最接近，因此我们在仔细研究软件工程后，针对网站建设的特点和重点，整理出一套网站建设管理和控制的方法，定名为网站工程(WebSite Project简称WP )。
网站工程
什么是网站工程，简单的说就是网站项目的管理和控制方法；是一种特殊的，标准的操作程序。建立网站工程的目的在于保证网站建设的高效率，高质量，低风险。
网站工程标准的实行，不但使客户得益，更使得网站制作行业趋向规范化，它将对行业相关的每个人都有益，包括项目经理，网页设计师，程序员和编辑。
下面，就按照一个项目从洽谈到提交完成的顺序来介绍：
1.项目立项/客户的需求说明书
1.1.项目立项
我们接到客户的业务咨询，经过双方不断的接洽和了解，并通过基本的可行性讨论够，初步达成制作协议，这时就需要将项目立项。较好的做法是成立一个专门的项目小组，小组成员包括：项目经理，网页设计，程序员，测试员，编辑/文档等必须人员。项目实行项目经理制。
1.2.客户的需求说明书
第一步是需要客户提供一个完整的需求说明。很多客户对自己的需求并不是很清楚，需要您不断引导和帮助分析。曾经有一次，我问客户：“您做网站的目的是什么？”他回答：“没有目的，只是因为别人都有，我没有！”。这样的客户就需要耐心说明，仔细分析，挖掘出他潜在的，真正的需求。
配合客户写一份详细的，完整的需求说明会花很多时间，但这样做是值得的，而且一定要让客户满意，签字认可。把好这一关，可以杜绝很多因为需求不明或理解偏差造成的失误和项目失败。糟糕的需求说明不可能有高质量的网站。那么需求说明书要达到怎样的标准呢？简单说，包含下面几点：
a.正确性：每个功能必须清楚描写交付的功能；
b.可行性：确保在当前的开发能力和系统环境下可以实现每个需求；
c.必要性：功能是否必须交付，是否可以推迟实现，是否可以在削减开支情况发生时"砍"掉；
d.简明性：不要使用专业的网络术语；
e.检测性：如果开发完毕，客户可以根据需求检测。
2.网站总体设计
在拿到客户的需求说明后，并不是直接开始制作，而是需要对项目进行总体设计，详细设计，出一份网站建设方案给客户。总体设计是非常关键的一步。它主要确定：
a.网站需要实现哪些功能；
b.网站开发使用什么软件，在什么样的硬件环境；
c.需要多少人，多少时间；
d.需要遵循的规则和标准有哪些。
同时需要写一份总体规划说明书，包括：
a.网站的栏目和版块；
b.网站的功能和相应的程序；
c.网站的链接结构；
d.如果有数据库，进行数据库的概念设计；
e.网站的交互性和用户友好设计。
在总体设计出来后，一般需要给客户一个网站建设方案。很多网页制作公司在接洽业务时就被客户要求提供方案。那时的方案一般比较笼统，而且在客户需求不是十分明确的情况下提交方案，往往和实际制作后的结果会有很大差异。所以应该尽量取得客户的理解，在明确需求并总体设计后提交方案，这样对双方都有益处。网站建设方案的包括以下几个部分：
a.客户情况分析；
b.网站需要实现的目的和目标；
c.网站形象说明；
d.网站的栏目版块和结构；
e.网站内容的安排，相互链接关系；
f.使用软件，硬件和技术分析说明；
g.开发时间进度表；
h.宣传推广方案；
i.维护方案；
j.制作费用；
k.本公司简介：成功作品，技术，人才说明等。
当您的方案通过客户的认可，那么恭喜你！您可以开始动手制作网站了。但还不是真正意义上的制作，你需要进行详细设计。
附：国外网站的定价方法
如何制定网站价格？对于那些小企业，价格开得太高，他们会吓跑，开的太低，自己得不到利润。由于行业竞争的无序性，国内现在的价格千奇百怪，有1000元制作整个商务网站的，也有2000元一页的快刀斩客。国外网页制作公司是如何指定网站制作价格的呢？
首先是根据员工工资，各项费用，利润率来计算每小时工作成本，即：总价 = 工资 + 费用 + 利润
举例说明：
假设公司的月支付工资为5000元，费用为5000元，希望的利润率为20%,一月工作时间为22*8=176小时，根据调查，一般网页制作公司有20-40%时间为非工作时间。实际工作的时间为
176*(1-25%)=132
所以，每工作小时成本是：
(5000+5000)*(1+20%) / 132 =90.90元
当你了解了每小时工作成本，开价格就心里有数了。国外常见报价方法分三种：套餐法，时间法，项目评估法。
套餐法：也称页面法，指定明确的页面数，图像数，链接数，功能等。这个办法最通用，但不是一个好办法，因为按照页面计价，解释很含糊 ：（
时间法：就是按照每小时成本计算。但是这种方法经常会遭到客户的质疑和拒绝，实行起来比较困难。
项目评估法：将整个项目拆成一个一个小工作，评估工作的技能难度，计算完成时间，再根据每小时成本计价。
网站详细设计
总体设计阶段以比较抽象概括的方式提出了解决问题的办法。详细设计阶段的任务就是把解法具体化。详细设计主要是针对程序开发部分来说的。但这个阶段的不是真正编写程序，而是设计出程序的详细规格说明。这种规格说明的作用很类似于其他工程领域中工程师经常使用的工程蓝图，它们应该 包含必要的细节，例如：程序界面，表单，需要的数据等。程序员可以根据它们写出实际的程序代码。(这里不详细展开说明)
1.整体形象设计
在程序员进行详细设计的同时，网页设计师开始设计网站的整体形象和首页。
整体形象设计包括标准字，Logo，标准色彩，广告语等。 首页设计包括版面，色彩，图像，动态效果，图标等风格设计，也包括banner，菜单，标题，版权等模块设计。首页一般设计1-3个不同风格，完成后，供客户选择。
记住：在客户确定首页风格之后，请客户签字认可。以后不得再对版面风格有大的变动，否则视为第二次设计。
2.开发制作
到这里，程序员和网页设计师同时进入全力开发阶段，需要提醒的是，测试人员需要随时测试网页与程序，发现Bug立刻记录并反馈修改。不要等到完全制作完毕再测试，这样会浪费大量的时间和精力。项目经理需要经常了解项目进度，协调和沟通程序员与网页设计师的工作。
3.调试完善
在网站初步完成后，上传到服务器，对网站进行全范围的测试。包括速度，兼容性，交互性，链接正确性，程序健壮性，超流量测试等，发现问题及时解决并记录下来。
为什么要记录文档呢？其实本软件工程本身就是一个文档，是一个不断充实和完善的标准。通过不断的发现问题，解决问题，修改，补充文档，使这个标准越来越规范，越来越工业化。进而使得网站开发趋向规范，趋向合理。
4.宣传推广
宣传推广的基本方法有：
a.网页里设置适当的META标签；
b.各搜索引擎登录；
c.准备新闻稿件在各新闻公告板发表；
d.合理使用Email邮件列表；
e.广告条交换；
f.付费广告。
至此，网站项目建设完毕，将有关网址，使用操作说明文档等提交客户验收。如果需要维护，另行签定维护项目。
(附)维护
网站成功推出后，长期的维护工作才刚刚开始，我们需要做到的是:
a.及时响应客户反馈；例如可以采取Email自动回复功能，然后在1-3个工作日里解决问题，再次回复；
b.网站流量统计分析和相应对策；
c.尽量推广和使用您的网址；
d.网站内容的及时更新和维护。
1.网站目录规范
目录建立的原则：以最少的层次提供最清晰简便的访问结构。
a.根目录。
b.每个语言版本存放于独立的目录；
c.每个主要功能(主菜单)建立一个相应的独立目录；
d.当页面超过20页，每个目录下存放各自独立images目录.共用的图片放在根目录下的images目录下；
e.所有的js文件存放在根目录下统一目录script；
f.所有的CSS文件存放在各语言版本下的style目录
g.所有的CGI程序存放在根目录并列目录cgi_bin目录
2.文件命名规范
3.链接结构规范
链接结构的原则：用最少的链接，使得浏览最有效率。
首页和一级页面之间用星状链接结构，一级和二级页面之间用树状链接结构。超过三级页面，在页面顶部设置导航条。
4.尺寸规范
a.页面标准按800*600分辨率制作，实际尺寸为778*434px
b.每个标准页面为A4幅面大小，即8.5X11英寸
c.大banner为468*60px，小banner为88*31px
必须加入的标签:
a.公司版权注释
b.网页显示字符集
简体中文：< META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=gb2312">
繁体中文：< META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=BIG5">
英 语：< META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
c.网页制作者信息
d.网站简介
< META NAME="DESCRIPTION" CONTENT="xxxxxxxxxxxxxxxxxxxxxxxxxx">
e.搜索关键字
< META NAME="keywords" CONTENT="xxxx,xxxx,xxx,xxxxx,xxxx,">
f.网页的css规范
< LINK href="style/style.css" rel="stylesheet" type="text/css">
g.网页标题
< title>xxxxxxxxxxxxxxxxxx< /title>
[color=#0000FF] 网站项目管理规范手册
一. 概念
网站项目管理就是根据特定的规范、在预算范围内、按时完成的网站开发任务。
二. 需求分析
项目立项
我们接到客户的业务咨询，经过双方不断的接洽和了解，并通过基本的可行性讨论够，初步达成制作协议，这时就需要将项目立项。较好的做法是成立一个专门的项目小组，小组成员包括：项目经理，网页设计，程序员，测试员，编辑/文档等必须人员。项目实行项目经理制。
客户的需求说明书
第一步是需要客户提供一个完整的需求说明。很多客户对自己的需求并不是很清楚，需要您不断引导和帮助分析。曾经有一次，我问客户：“您做网站的目的是什么？”他回答：“没有目的，只是因为别人都有，我没有！”。这样的客户就需要耐心说明，仔细分析，挖掘出他潜在的，真正的需求。 配合客户写一份详细的，完整的需求说明会花很多时间，但这样做是值得的，而且一定要让客户满意，签字认可。把好这一关，可以杜绝很多因为需求不明或理解偏差造成的失误和项目失败。糟糕的需求说明不可能有高质量的网站。那么需求说明书要达到怎样的标准呢？简单说，包含下面几点：
1. 正确性：每个功能必须清楚描写交付的功能；
2. 可行性：确保在当前的开发能力和系统环境下可以实现每个需求；
3. 必要性：功能是否必须交付，是否可以推迟实现，是否可以在削减开支情况发生时"砍"掉；
4. 简明性：不要使用专业的网络术语；
5. 检测性：如果开发完毕，客户可以根据需求检测。
三. 系统分析
网站总体设计
在拿到客户的需求说明后，并不是直接开始制作，而是需要对项目进行总体设计，详细设计，出一份网站建设方案给客户。总体设计是非常关键的一步。它主要确定：
1. 网站需要实现哪些功能；
2. 网站开发使用什么软件，在什么样的硬件环境；
3. 需要多少人，多少时间；
4. 需要遵循的规则和标准有哪些。
同时需要写一份总体规划说明书，包括：
1. 网站的栏目和版块；
2. 网站的功能和相应的程序；
3. 网站的链接结构；
4. 如果有数据库，进行数据库的概念设计；
5. 网站的交互性和用户友好设计。
网站建设方案
在总体设计出来后，一般需要给客户一个网站建设方案。很多网页制作公司在接洽业务时就被客户要求提供方案。那时的方案一般比较笼统，而且在客户需求不是十分明确的情况下提交方案，往往和实际制作后的结果会有很大差异。所以应该尽量取得客户的理解，在明确需求并总体设计后提交方案，这样对双方都有益处。网站建设方案的包括以下几个部分：
1. 客户情况分析；
2. 网站需要实现的目的和目标；
3. 网站形象说明；
4. 网站的栏目版块和结构；
5. 网站内容的安排，相互链接关系；
6. 使用软件，硬件和技术分析说明；
7. 开发时间进度表；
8. 宣传推广方案；
9. 维护方案；
10. 制作费用；
11. 本公司简介：成功作品，技术，人才说明等。
当您的方案通过客户的认可，那么恭喜你！您可以开始动手制作网站了。但还不是真正意义上的制作，你需要进行详细设计：
网站详细设计
总体设计阶段以比较抽象概括的方式提出了解决问题的办法。详细设计阶段的任务就是把解法具体化。详细设计主要是针对程序开发部分来说的。但这个阶段的不是真正编写程序，而是设计出程序的详细规格说明。这种规格说明的作用很类似于其他工程领域中工程师经常使用的工程蓝图，它们应该 包含必要的细节，例如：程序界面，表单，需要的数据等。程序员可以根据它们写出实际的程序代码。
四. 项目实施
整体形象设计
在程序员进行详细设计的同时，网页设计师开始设计网站的整体形象和首页。整体形象设计包括标准字，Logo，标准色彩，广告语等。 首页设计包括版面，色彩，图像，动态效果，图标等风格设计，也包括banner，菜单，标题，版权等模块设计。首页一般设计1-3个不同风格，完成后，供客户选择。
记住：在客户确定首页风格之后，请客户签字认可。以后不得再对版面风格有大的变动，否则视为第二次设计。
开发制作
到这里，程序员和网页设计师同时进入全力开发阶段，需要提醒的是，测试人员需要随时测试网页与程序，发现Bug立刻记录并反馈修改。不要等到完全制作完毕再测试，这样会浪费大量的时间和精力。项目经理需要经常了解项目进度，协调和沟通程序员与网页设计师的工作。
调试完善
在网站初步完成后，上传到服务器，对网站进行全范围的测试。包括速度，兼容性，交互性，链接正确性，程序健壮性，超流量测试等，发现问题及时解决并记录下来。
为什么要记录文档呢？其实本软件工程本身就是一个文档，是一个不断充实和完善的标准。通过不断的发现问题，解决问题，修改，补充文档，使这个标准越来越规范，越来越工业化。进而使得网站开发趋向规范，趋向合理。
宣传推广
宣传推广的基本方法有：
1. 网页里设置适当的META标签；
2. 各搜索引擎登录；
3. 准备新闻稿件在各新闻公告板发表；
4. 合理使用Email邮件列表；
5. 广告条交换；
6. 付费广告。
至此，网站项目建设完毕，将有关网址，使用操作说明文档等提交客户验收。如果需要维护，另行签定维护项目。
维护
网站成功推出后，长期的维护工作才刚刚开始，我们需要做到的是：
1. 及时响应客户反馈；例如可以采取Email自动回复功能，然后在1-3个工作日里解决问题，再次回复；
2. 网站流量统计分析和相应对策；
3. 尽量推广和使用您的网址；
4. 网站内容的及时更新和维护。
五. 遵循的规范
1. 网站建设目录规范
2. 网站文件命名规范
3. 网站建设尺寸规范
4. 网站首页head区代码规范
5. 网站连接结构规范
[color=#0000FF] 网站软件开发规范(某门户网站的)
1数据库使用规范
1.1服务器上有关数据库的一切操作只能由服务器管理人员进行。
1.2程序中访问数据库时使用统一的用户、统一的连接文件访问数据库。
1.3原则上每一个频道只能建一个库，库名与各频道的英文名称相一致，库中再包含若干表。比较大的、重点的栏目可以考虑单独建库，库名与栏目的英文名称相一致。
1.4命名：
（1） 数据库、表、字段、索引、视图等一系列与数据库相关的名称必须全部使用与内容相关的英文单词命名（尽量避免使用汉语拼音），对于一个单词难以表达的，可以考虑用多个单词加下划线（_）连接（不能超过四个单词）命名。
（2） 所有的名称必须统一使用英文小写字母。
（3） 所有的名称起始和结尾不能使用下划线（_）。
（4） 所有的名称不能包含26个英文小写字母和下划线（_）以外的其他字符。
1.5不再使用的数据库、表应删除，在删除之前必须备份（包括结构和内容）。
2 文档规范
所有的项目必须有相关的文档说明（可以是电子文档）。文档应包含如下内容：
（1）项目名称。
（2）项目小组名单，项目负责人。
（3）项目开发起始时间和结束时间。
（4）项目内容描述。
（5）项目位置。（在哪个频道、哪个栏目）
（6）与项目有关的程序文件名（含路径名），文件内容及实现的功能描述。
（7）完整的程序流程图。
（8）数据库、表、视图、索引的名称，用途。字段的名称、类型、长度、用途，必须附上相关的SQL语句。
3源代码与页面嵌套规范
3.1源代码：
（1） 使用自定义变量（包括全局变量、局部变量）之前必须先声明变量，并用注释语句标明变量的类型、用途。
（2）自定义函数必须用注释语句标明函数的用途、参数的数据类型、意义，返回值的类型。
（3）程序中重要的过程或代码较长的过程应使用注释语句标明该过程的起始行和结束行，并注明该过程的功能。
（4） 所有的注释文字一律使用简体中文。
3.2 HTML页面嵌套：
（1） 网页设计部设计的HTML页面以嵌套的方式确定用于动态显示程序执行结果的位置、宽度、行数（或高度）等，并在相应位置予以文字说明。页面中与程序无关的图片、文字、联结等必须使用完整的URL。
（2） 软件开发人员和编辑人员可以根据情况协商，将页面文件及图片与程序独立存放在各自的服务器上，页面改版和修改程序独立进行。
（3） 使用include技术将分割开的HTML页面分别嵌入程序代码中，要求做到修改HTML页面时无须改写程序，而修改程序时不会影响HTML页面效果，将页面改版和修改程序两项工作分别独立。
（4） 页面和程序嵌套以后不能破坏原HTML页面的整体显示效果，字体、字号、颜色等应尽量保持原HTML页面的风格。
（5） 动态生成的页面的各项指标（如图片大小、页面宽度、高度、页面文件的字节数等）应符合本公司网页设计方面的要求。
4测试规范（软件部分）
对于较大的项目应成立相应的测试小组，小组成员由软件开发人员、网页设计人员、技术人员、编辑人员组成。测试过程应参照网页设计部为该项目提供的原HTML页面进行。测试内容包括以下几点：
（1） 页面宽度、高度（行数）。
（2） 页面文字、图片、色彩是否风格统一。
（3）页面的图片显示是否正常、有无变形。
（4）弹出页面的效果。
（5）页面的联接是否正确。
（6）动态生成的页面是否符合以上几个方面的要求，页面大小（字节数，包括页面的图片、*.js、*.css、*.class等相关文件）是否符合网页设计的要求。
（7） 软件方面的功能是否实现。如数据库的查询、修改、删除，文件的上传、下载等操作是否正常。
（8） 测试结束后，根据《软件开发需求书》在《测试报告》上如实填写测试结果，包括测试通过的、未通过的，指出出错的页面和相关的程序文件，并附上测试中出现的错误信息。
[color=#0000FF] 网站制作规范
1. 网站目录规范 ---------------------------------目录建立的原则：以最少的层次提供最清晰简便的访问结构。
l 根目录一般只存放index.asp以及其他必须的系统文件,轻易不要建目录，
l 每个主要栏目开设一个相应的独立目录;目录中开设一个images 的子目录用以放置此栏目专有的图片和flash文件，如果这个栏目的内容特别多，又分出很多下级栏目，可以相应的再开设其他目录。
l 根目录下的images用于存放各页面都要使用的公用图片
l 所有公共脚本*.js *.asp等存放在根目录下的include目录；
l 各栏目CSS文件存放在相应目录下，以该栏目名命名！
2. 网站文件命名规范 ----------------------------------文件命名的原则：以最少的字母达到最容易理解的意义。
l 每个栏目首页以该栏目命名，如：安全管理栏目下首页面 /anquan/anquan.htm
l 多个同类型文件使用英文字母加数字命名，字母和数字之间用_分隔。例如：news_01.htm。注意，数字位数与文件个数成正比，不够的用0补齐。
l HTML文件扩展文件名一律用 .htm注意不要使用.html
3. 图片的命名规范 -----------------------------------------------图片名称分为头尾两两部分，用下划线隔开。
l 头部分表示此图片的大类性质。例如： 放置在页面顶部的广告、装饰图案等长方形的图片我们取名：banner ；标志性的图片我们取名为：logo ；在页面上位置不固定并且带有链接的小图片我们取名为button ；在页面上做栏目链接的图片我们取名：menu ；不带链接表示标题的图片我们取名：title ；装饰用的照片我们取名：pic ；依照此原则类推。
l 尾部分用来表示图片的具体含义，用英文字母表示。例如：banner_lntu.gif logo_lntu.gif button_next.gif menu_aboutus.gif title_news.gif pic_people.jpg
l 有onmouse效果的图片，两张分别在原有文件名后加"_on"和"_off"命名。
4. 网站建设尺寸规范 -----------------------------------------------------------------------------------------------
l 尺寸规范请根据您的实际情况调整：页面标准按800*600分辨率制作，尺寸宽为760px；注意考虑 1024*768情况下居中，页面长度原则上不超过3屏，
l 全尺寸banner为468*60px，小banner为88*31px，另外120*90，120*60也是小图标的标准尺寸；
5. 网站首页head区代码规范 -------------------------------------------------------------------------------------
首页的代码关键在head区，head区是指首页HTML代码的和之间的内容。
这个栏目的标题
该页所采用的样式表.css" rel="stylesheet" type="text/css">
6. 其它一些规范 ------------------------------------------------------------------------------------------------------
l js的命名原则以功能的英语单词为名。例如：广告条的js文件名为：ad.js；
l 所有的CSS的尽量采用外部调用：
l 所有的javascript脚本尽量采取外部调用：
l 字号用点数pt和像素px来定义，pt使用中文宋体的9pt和11pt，px使用中文宋体12px 和14.7px黑体 字或者宋体字加粗时，一般选用11pt 和14.7px 的字号比较合适。
l 所有连接使用相对路径，切记不可使用绝对路径。如：../index.htm
l 所有文件，目录，图片全部以小写字母命名，禁止用中文命名。
[color=#0000FF] Web 测试的经验
1. 功能测试
1.1.链接测试
链接是 Web 应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证 Web 应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的 URL 地址才能访问。
链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个 Web 应用系统的所有页面开发完成之后进行链接测试。
1.2. 表单测试
当用户给 Web 应用系统管理员提交信息时，就需要使用表单操作，例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。
1.3.Cookies测试
Cookies 通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用 Cookies 访问了某一个应用系统时， Web 服务器将发送关于用户的信息，把该信息以 Cookies 的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。
如果 Web 应用系统使用了 Cookies ，就必须检查 Cookies 是否能正常工作。测试的内容可包括 Cookies 是否起作用，是否按预定的时间进行保存，刷新对 Cookies 有什么影响等。
1.4.设计语言测试
Web 设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的 HTML 等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了 HTML 的版本问题外，不同的脚本语言，例如 Java 、 JavaScript 、 ActiveX 、 VBScript 或 Perl 等也要进行验证。
1.5.数据库测试
在 Web 应用技术中，数据库起着重要的作用，数据库为 Web 应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在 Web 应用中，最常用的数据库类型是关系型数据库，可以使用 SQL 对信息进行处理。
在使用了数据库的 Web 应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。
2. 性能测试
2.1.连接速度测试
用户连接到 Web 应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果 Web 系统响应时间太长（例如超过 5 秒钟），用户就会因没有耐心等待而离开。
另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。
2.2.负载测试
负载测试是为了测量 Web 系统在某一负载级别上的性能，以保证 Web 系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问 Web 系统的用户数量，也可以是在线数据处理的数量。例如： Web 应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？ Web 应用系统能否处理大量用户对同一个页面的请求？
2.3.压力测试
负载测试应该安排在 Web 系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个 Web 系统能同时处理的请求数量将远远超出这个限度，所以，只有放在 Internet 上，接受负载测试，其结果才是正确可信的。
进行压力测试是指实际破坏一个 Web 应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试 Web 应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到 Web 应用系统崩溃，接着当系统重新启动时获得存取权。
压力测试的区域包括表单、登陆和其他信息传输页面等。
3. 可用性测试
3.1.导航测试
导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。通过考虑下列问题，可以决定一个 Web 应用系统是否易于导航：导航是否直观？ Web 系统的主要部分是否可通过主页存取？ Web 系统是否需要站点地图、搜索引擎或其他的导航帮助？
在一个页面上放太多的信息往往起到与预期相反的效果。 Web 应用系统的用户趋向于目的驱动，很快地扫描一个 Web 应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉 Web 应用系统的结构，因此， Web 应用系统导航帮助要尽可能地准确。
导航的另一个重要方面是 Web 应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道 Web 应用系统里面是否还有内容，内容在什么地方。
Web 应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。
3.2.图形测试
在 Web 应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个 Web 应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：
（1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。 Web 应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。
（2）验证所有页面字体的风格是否一致。
（3) 背景颜色应该与字体颜色和前景颜色相搭配。
（4）图片的大小和质量也是一个很重要的因素，一般采用 JPG 或 GIF 压缩。
3.3.内容测试
内容测试用来检验 Web 应用系统提供信息的正确性、准确性和相关性。
信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷；信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用 Microsoft Word 的 " 拼音与语法检查 " 功能；信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般 Web 站点中的所谓 " 相关文章列表 " 。
3.4.整体界面测试
整体界面是指整个 Web 应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览 Web 应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方？整个 Web 应用系统的设计风格是否一致？
对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般 Web 应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。
对所有的可用性测试来说，都需要有外部人员（与 Web 应用系统开发没有联系或联系很少的人员）的参与，最好是最终用户的参与。
4. 客户端兼容性测试
4.1.平台测试
市场上有很多不同的操作系统类型，最常见的有 Windows 、 Unix 、 Macintosh 、 Linux 等。 Web 应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。
因此，在 Web 系统发布之前，需要在各种操作系统下对 Web 系统进行兼容性测试。
4.2.浏览器测试
浏览器是 Web 客户端最核心的构件，来自不同厂商的浏览器对 Java ，、 JavaScript 、 ActiveX 、 plug-ins 或不同的 HTML 规格有不同的支持。例如， ActiveX 是 Microsoft 的产品，是为 Internet Explorer 而设计的， JavaScript 是 Netscape 的产品， Java 是 Sun 的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和 Java 的设置也不一样。
测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。
5. 安全性测试
Web 应用系统的安全性测试区域主要有：
（ 1 ）现在的 Web 应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。
（ 2 ） Web 应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如 15 分钟）没有点击任何页面，是否需要重新登陆才能正常使用。
（ 3 ）为了保证 Web 应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。
（ 4 ）当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。
（ 5 ）服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。
[color=#0000FF] Web测试手段
近年来，随着软硬件技术发展和人们意识的提高，Web应用得到广泛的普及，一方面在互联网浪潮的推动下，基于互联网的信息共享和电子商务不断发展，像新浪、搜狐、8848等大型网站不断涌现出来，另一方面随着Java、CGI等网络技术的成熟，基于B/S结构的大型软件逐渐显示出巨大的优势。同时，也就产生了一个焦点问题，什么样的服务器能够满足不同用户的需求，怎么能够保证Web服务器能够长期稳定地运行，为了满足这样的需求Web测试也就同样变得十分重要。
当前Web测试主要通过Web测试工具加上良好的测试案例完成的，我们认为主要有以下两种测试类型：基准测试、非基准测试
基准测试：主要指测试工具已经提供了标准的测试案例库，包括静态测试案例（HTM、JPG）、动态测试案例（CGI）和SSL测试案例等。这类测试工具分为测试案例库、控制台程序、客户端程序三个部分。它的原理是，Web服务器开启特定的Web服务程序，并且运行上述测试案例，由控制台程序控制各个客户端按照一定的脚本访问顺序遍历Web服务器的各个测试案例，每个请求完成后，各个客户端向控制台报告访问的结构，当一个测试集完成后由控制台将所有的信息综合统计，测试过程中控制台还需要采用SNMP协议对服务器进行实时监控，综合两个方面的因素可以反映出Web服务器在不同压力情况下的综合性能。
在测试过程中，主要影响测试结果的因素有网络环境、客户端性能。目前无论IA架构服务器还是SUN、HP、IBM的UNIX服务器性能都越来越优越，有可能出现在100MB网络下不能够提供足够的网络压力，有可能网络首先出现瓶颈，这样就需要扩展到1000MB网络环境或使用多个网段对服务器提供足够的压力，而稳定的客户端对于测试来说也是十分重要的，因为客户端如果出现性能下降，就会造成系统崩溃或者不能提供稳定的测试压力从而导致测试结果出现偏差；一台客户端到底能够稳定运行多少数量的连接是根据不同的硬件配置和操作系统决定的，因此对客户端的硬件资源进行监控是保证客户端可以稳定运行的必要手段。
由于这类测试工具使用的是工具开发商提供的测试案例集，虽然也具有一定的权威性，但是目前再完美的测试案例集也不能涵盖所有的Web应用情况，所以也不能够完全体现出Web服务器完整的性能，因此该类测试工具更加适合IT媒体对Web类服务器软硬件的横向对比测试，在测试对象和环境大体统一的情况下，可以比较出各个测试对象的性能差异。而对于有实际应用背景的Web服务器进行测试，使用这样的测试工具就不适合了，我们在以后的测试漫谈中会继续介绍
[color=#0000FF] 对Web服务进行压力测试
Web 服务处于分布式计算的核心位置，它们之间的交互通常很难测试。分布式开发、大型的开发者团队以及对代码日益组件化的期望都有可能使 Web 服务的开发变得越来越容易隐藏错误。这些类型的错误极难检测出来。压力测试是检测这类代码错误的一种有效方法，但是只有在压力系统设计得比较有效的情况下 才能发挥作用。本文将让您深入了解一下这种压力系统的基本要求。
测试方法
传统的测试方法包括某种形式的简单 单元测试 ，通常由开发人员执行。设计这些测试需要了解软件的内部知识，并且这些测试几乎总是针对产品的非常小的、特定的部分。这些类型的测试非常适合与其他代码组件极少交互，甚至没有交互的简单 Web 服务。
功能验证（Functional Verification） 也 是一种测试过程，在这个过程中，对产品源代码了解有限的设计者进行测试以确认产品或服务的核心功能。设计这种测试是为了证明这个核心功能符合某个规范。举 个例子，我的在线拍卖显示的是输入的正确出价吗？ 我的保险经纪人系统找到最便宜的报价了吗？如果这些测试失败，通常就意味着检测到了产品的一个基本问题（这个问题通常是可以直接修复）。这种测试也是适合 简单的 Web 服务，使您可以检查服务是否能够正确执行它的各个功能。
系统测试（System Test） 通常是在功能验 证阶段完成，验证了核心功能后进行。它倾向于把整个系统作为一个整体来查找问题 — 弄清 Web 服务作为系统的一部分怎样运作，以及 Web 服务相互之间如何交互。由于系统测试是在开发生命周期快结束时才进行，所以通常不能给它分配足够的时间来完成。又因为紧张的发行日程安排以及开发的各个重 要阶段的后移，系统测试阶段经常被忽略，并且一些通常都可以发现的、少见的错误都不能被检测到。即使发现了这种错误，这时也来不及确定错误的原因并设法修 复它们了。因此，在查找代码错误时，必需把系统测试应用设计得尽可能高效。系统测试通常由三部分组成，它们是：
性能（Performance）： 这涉及到确定相关的产品统计数据的过程。例如：每秒有多少条消息？一个服务可同时接受多少个用户？
案例（Scenario）： 这是重新创建客户所需的确切配置的过程。因此在案例中发现的任何问题都可以在客户使用该产品之前被检测出来。
压力（或称工作负载平衡）： 它 与另两个部分不同，因为它被设计为通过应用很大的工作负载来使软件超负荷运转。如果压力测试通过对产品保持高强度的使用（但不超过性能统计数字确定的限 制）能有效地执行，那么它就经常能够发现许多隐蔽的错误，而这些错误用上面提到的任何其他技术都是发现不了的（这些错误也经常是最难修复的）。
从检测代码错误这方面来说，可以证明这三个系统测试组件中效率最高的是 压力测试 部分。但由于这个过程经常跟系统的其他要素或功能测试混淆在一起，所以这个过程涉及到的方法还没有被正确着手处理或实现。
压力下的错误
使用压力测试，您有希望找到很多种用其他测试方法更难发现的错误。有两种错误类型是：
内存泄漏（Memory leak）： 一种极难检测的现象。内存泄漏经常发生在已发行的产品中，原因很简单，很难设计测试 用例来检测它们。使用简单的功能测试，几乎发现不了内存泄漏问题，因为在产品完成之前测试没对产品进行足够多的使用。内存泄漏通常要求操作要重复非常多的 次数以使内存消耗达到能引起注意的程度。尽管与其它编程语言（如 C/C++）相比，Java 程序更难引入内存泄漏错误，但只要程序仍保持着对对象的引用，该对象仍有可能被实例化并且它占用的内存永远不会被释放。
并发与同步（Concurrency and Synchronization）： 压 力测试在查找并发性问题上非常出众，这是因为在任何一个测试生命周期中，它都应用了许多不同的代码路径和定时条件。一般的规则是，压力测试运行的时间越 长，涉及并应用的代码路径组合和定时条件就越多。当然，这也的确使得这些问题很难再现（错误可以在 5 分钟或 5 天后发生）。死锁、线程泄漏以及任何一般的同步问题通常只能在压力测试阶段被检测出来。这些类型的问题很难通过执行单元测试来发现。开发人员不会一直考虑 他或她的代码将与其他地方的代码（在执行单元测试时这些代码可能还没写出来）进行交互。
现有的压力测试工具
有许多声称能够对 产品进行压力测试的可用工具目前正在开发中。被广泛应用的是针对 Web 服务的那些工具。然而，这些工具中有许多只是简单的 HTML/SOAP 生成器，它们模拟许多客户机连接，并因此对 Web 服务器生成高负载（这对于查找 Web 服务器的问题很有用，但对于查找 Web 服务的问题就没那么有用了）。这些工具对基本的压力测试比较有用，但它们经常是仅仅扩展功能验证阶段来重复地执行相同的功能任务。如果足够的时间和资源可 用，就可以通过创建定制构建的压力测试系统来实现更有效的测试。由于压力系统的设计者通常对要测试的产品和 Web 服务有更多的了解，所以他们将能够确保压力系统可以用于哪些具体的代码区域。
设计压力应用
设计试图对 Web 服务进行压力测试的压力测试系统时，要让它们以某种特定的方式运行代码。这些风格超越了功能验证，目的是要弄清楚被测试的 Web 服务是不是不仅能做我们认为它能做的事，而且在被施加了某些高强度压力的情况下仍然继续正常运行。压力测试必须对 Web 服务应用四个基本条件。许多已建立的压力系统应用了这些条件。有效的压力测试系统将应用以下这些关键条件：
重复（Repetition）： 或 许最明显的且最容易理解的压力条件就是测试的重复。换句话说，测试的重复就是一遍又一遍地执行某个操作或功能，比如重复调用一个 Web 服务。功能验证测试可以用来被弄清楚一个操作能否正常执行。而压力测试将确定一个操作能否正常执行，并且能否继续在每次执行时都正常。这对于推断一个产品 是否适用于某种生产情况至关重要。客户通常会重复使用产品，因此压力测试应该在客户之前发现代码错误。许多最简单的压力系统只实现这一个条件，但简单地扩 展功能验证测试来多次重复并不能构成一个有效的压力测试。当与下面的一些原则结合起来使用时，重复就可以发现许多隐蔽的代码错误。
并发（Concurrency）： 并 发是同时执行多个操作的行为。换句话说，就是在同一时间执行多个测试，例如在同一个服务器上同时调用许多 Web 服务。这个原则不一定适用于所有的产品（比如无状态服务），但是多数软件都具有某个并发行为或多线程行为元素，这一点只能通过执行多个代码示例才能测出 来。功能测试或单元测试几乎不会与任何并发设计结合。压力系统必须超越功能测试，要同时遍历多条代码路径。至于怎么做到这一点取决于具体的产品。例如，一 个 Web 服务压力测试需要一次模拟多个客户机。Web 服务（或者任何多线程代码）通常会访问多个线程实例间的一些共享数据。因额外方面的编程而增加的复杂性通常意味着代码会具有许多因并发引起的错误。由于引 入并发性意味着一个线程中的代码有可能被其他线程中的代码中断，所以错误只在一个指令集以特定的顺序（例如以特定的定时条件）执行时才会被发现。把这个原 则与重复原则结合在一起，您可以应用许多代码路径 和 定时条件。
量级（Magnitude）： 压 力系统应该应用于产品的另一个条件考虑到了每个操作中的负载量。压力测试可以重复执行一个操作，但是操作自身也要尽量给产品增加负担。例如，一个 Web 服务允许客户机输入一条消息，您可以通过模拟输入超长消息的客户机来使这个单独的操作进行高强度的使用。换句话说就是，您增加了这个操作的量级。这个量级 总是特定于应用的，但是可以通过查找产品的可被用户计量和修改的值来确定它 — 例如，数据的大小、延迟的长度、资金数量的转移、输入速度以及输入的变化等等。单独的高强度操作自身可能发现不了代码错误（或者仅能发现功能上的缺陷）， 但与其他压力原则结合在一起时，您将可以增加发现问题的机会。
随机变化： 最后一点，任何压力系统都多多 少少具有一些随机性。如果您随机使用前面的压力原则中介绍的无数变化形式，您就能够在每次测试运行时应用许多不同的代码路径。下面是几个关于怎样在测试生 命周期内改变测试的示例。使用重复时，在重新启动或重新连接服务之前，您可以改变重复操作间的时间间隔、重复的次数，或者也可以改变被重复的 Web 服务的顺序。使用并发，您可以改变一起执行的 Web 服务、同一时间运行的 Web 服务数目，或者也可以改变关于是运行许多不同的服务还是运行许多同样的实例的决定。量级或许是最容易更改的 — 每次重复测试时都可以更改应用程序中出现的变量（例如，发送各种大小的消息或数字输入值）。如果测试完全随机的话，因为很难一致地重现压力下的错误，所以 一些系统使用基于一个固定随机种子的随机变化。这样，用同一个种子，重现错误的机会就会更大。
一个压力测试通常会结合上述的所 有原则，并且在允许的范围内尽可能长时间地运行。测试被允许的执行时间越长，就可以遍历越多的代码路径，并且发现的错误也越多。当然，一旦找到错误就必须 诊断并修复它。由于一个代码错误可以在压力测试运行多日以后自己显示出来，所以系统必须保证当出现错误时所有可用的调试信息都被生成 — 否则可能就必须花费同样多的时间来重现这个错误。
结束语
测试是软件开发过程中至关重要 的部分，并且一个重要的、经常被曲解或忽略的部分是压力测试。遵循上面详细说明的原则，您就可以设计并实现有效的压力测试系统，用来查找一些与您的代码相 关的、比较隐蔽的问题。无论是利用预先写好的工具，还是创建一个完全专用的压力系统，压力测试都是用于查找 Web 服务（或其他任何程序）问题的本质方法，并能最终提高您的软件产品质量。
[color=#0000FF] 基于Web的系统测试方法
摘要
基于Web的系统测试与传统的软件测试既有相同之处，也有不同的地方，对软件测试提出了新的挑战。基于Web的系统测试不但需要检查和验证是否按照设计的要求运行，而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。
本文从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于Web的系统测试方法。
随着Internet和Intranet/Extranet的快速增长，Web已经对商业、工业、银行、财政、教育、政府和娱乐及我们的工作和生活产生了深远的影响。许多传统的信息和数据库系统正在被移植到互联网上，电子商务迅速增长，早已超过了国界。范围广泛的、复杂的分布式应用正在Web环境中出现。Web的流行和无所不在，是因为它能提供支持所有类型内容连接的信息发布，容易为最终用户存取。
Yogesh Deshpande和Steve Hansen在1998年就提出了Web工程的概念。Web工程作为一门新兴的学科，提倡使用一个过程和系统的方法来开发高质量的基于Web的系统。它"使用合理的、科学的工程和管理原则，用严密的和系统的方法来开发、发布和维护基于Web的系统"。目前，对于web工程的研究主要是在国外开展的，国内还刚刚起步。
在基于Web的系统开发中，如果缺乏严格的过程，我们在开发、发布、实施和维护Web的过程中，可能就会碰到一些严重的问题，失败的可能性很大。而且，随着基于Web的系统变得越来越复杂，一个项目的失败将可能导致很多问题。当这种情况发生时，我们对Web和Internet的信心可能会无法挽救地动摇，从而引起Web危机。并且，Web危机可能会比软件开发人员所面对的软件危机更加严重、更加广泛。
在Web工程过程中，基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于Web的系统测试与传统的软件测试不同，它不但需要检查和验证是否按照设计的要求运行，而且还要测试系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。然而，Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。因此，我们必须为测试和评估复杂的基于Web的系统研究新的方法和技术。
一般软件的发布周期以月或以年计算，而Web应用的发布周期以天计算甚至以小时计算。Web测试人员必须处理更短的发布周期，测试人员和测试管理人员面临着从测试传统的C/S结构和框架环境到测试快速改变的Web应用系统的转变。
一、功能测试
1、链接测试
链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。
链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的所有页面开发完成之后进行链接测试。
2、表单测试
当用户给Web应用系统管理员提交信息时，就需要使用表单操作，例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。
3、Cookies测试
Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。
如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。
4、设计语言测试
Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语言，例如Java、JavaScript、 ActiveX、VBScript或Perl等也要进行验证。
5、数据库测试
在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。
在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。
二、性能测试
1、连接速度测试
用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。
另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。
2、负载测试
负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统能否处理大量用户对同一个页面的请求？
3、压力测试
负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。
进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。
压力测试的区域包括表单、登陆和其他信息传输页面等。
三、可用性测试
1、导航测试
导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。通过考虑下列问题，可以决定一个Web应用系统是否易于导航：导航是否直观？Web系统的主要部分是否可通过主页存取？Web系统是否需要站点地图、搜索引擎或其他的导航帮助？
在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构，因此，Web应用系统导航帮助要尽可能地准确。
导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。
Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。
2、图形测试
在Web应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：
（1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。
（2）验证所有页面字体的风格是否一致。
（3）背景颜色应该与字体颜色和前景颜色相搭配。
（4）图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩。
3、内容测试
内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。
信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷；信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用Microsoft Word的"拼音与语法检查"功能；信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中的所谓"相关文章列表"。
4、整体界面测试
整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览Web应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方？整个Web应用系统的设计风格是否一致？
对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。
对所有的可用性测试来说，都需要有外部人员（与Web应用系统开发没有联系或联系很少的人员）的参与，最好是最终用户的参与。
四、客户端兼容性测试
1、平台测试
市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。
因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。
2、浏览器测试
浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java，、JavaScript、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，JavaScript是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。
测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。
五、安全性测试
Web应用系统的安全性测试区域主要有：
（1）现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。
（2）Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。
（3）为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。
（4）当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。
（5）服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。
六、总结
本文从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于Web的系统测试方法。
基于Web的系统测试与传统的软件测试既有相同之处，也有不同的地方，对软件测试提出了新的挑战。基于Web的系统测试不但需要检查和验证是否按照设计的要求运行，而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。
七、参考文献
[1] N. Zelnick. Nifty Technology and Nonconformance: The Web in Crisis. Computer， 1998(10): 115-119
[2] W. Gibbs. Software';s chronic crisis. Scientific American. 1994.9
[3] Yogesh Deshpande and Steve Hansen. Web Engineering: Creating a Discipline among Disciplines. IEEE Software，2001(2): 82-87
[4] A. Ginige. Web Engineering: Methodologies for Developing Large and Maintainable Web Based Information Systems. Proc IEEE International Conference on Networking， the India and the World CNIW';98，Ahmedabad， India， 1998，12
[5] Internet Testing: Keeping Bugs Off the Web. http://www.stlabs.com/bugs_off.htm
[6] J. Bach. Testing Internet Software.
http://www.stlabs.com/testnet/docs/inet.htm
[7] Tongren.Compatibility and Security Testing of Web-Based Applications. TTN Online，1999，3
[color=#0000FF] Web下的整体测试
随着Internet的日益普及，现在基于B/S结构的大型应用越来越多，可如何对这些应用进行测试成为日益迫切的问题。有许多测试人员来信问我B/S的测试如何做，由于工作较繁忙，对大家提出的问题也是头痛医头脚痛医脚，没有对WEB的测试过程做一个整体的概述。希望通过本篇能够让大家了解大型Web应用是如何来进行测试的。
B/S下的功能测试比较简单，关键是如何做好性能测试。目前大多数的测试人员认为只要跑一些测试工具证明我的产品是可以达到性能的就ok了，为了证明而去测试是没有任何价值的，关键是要发现产品性能上的缺陷，定位问题，解决问题，这才是测试要做的。
首先我们从两个方面分析如何进行WEB测试，从技术实现上来讲一般的B/S结构，无论是.NET还是J2EE,都是多层构架，有界面层，业务逻辑层，数据层。而从测试的流程上来说，首先是发现问题，分析问题，定位问题，再由开发人员解决问题。那么B/S的结构的测试如何来做？
如何发现问题是我首先要介绍的，在做WEB测试之前你需要一些资料，比如产品功能说明书，性能需求说明书，不一定很完善，但一定要有，明确测试目标，这是基本的常识，可是我往往看到的是已经开始动手测了，但还不知自己的系统要达到的性能指标是什么。这里我简单讲一下测试的性能指标：
l 通用指标（指Web应用服务器、数据库服务器必需测试项）:
* ProcessorTime: 指服务器CPU占用率，一般 平均达到70%时，服务就接近饱和；
* Memory Available Mbyte : 可用内存数，如果测试时发现内存有变化情况也要注意，如果是内存泄露则比较严重；
* Physicsdisk Time : 物理磁盘读写时间情况；
l Web服务器指标：
* Avg Rps: 平均每秒钟响应次数＝总请求时间 / 秒数；
* Avg time to last byte per terstion （mstes）:平均每秒业务角本的迭代次数 ,有人会把这两者混淆；
* Successful Rounds：成功的请求；
* Failed Rounds ：失败的请求；
* Successful Hits ：成功的点击次数；
* Failed Hits ：失败的点击次数；
* Hits Per Second ：每秒点击次数；
* Successful Hits Per Second ：每秒成功的点击次数；
* Failed Hits Per Second ：每秒失败的点击次数；
* Attempted Connections ：尝试链接数；
l 数据库服务器指标：
* User 0 Connections ：用户连接数，也就是数据库的连接数量；
* Number of deadlocks：数据库死锁；
* Butter Cache hit ：数据库Cache的命中情况；
上面的指标只是一些通用的指标,起到抛砖引玉的作用，对于不同的应用你还必需作相应的调整，比如程序使用的是.NET技术的，则必需加入一些针对性的测试指标。对于这些指标的详细了解，你可以参考Windows 下面的 SystemMonitor的帮助与LoadRunner、ACT的帮助。对于发现问题，指标的设置非常重要，它会帮你定性的发现一些错误。对于定性的压力测试我就不做过多的分析，工具很多，流行的主要有LoadRunner,ACT,WAS,WebLoad,各个工具有它的使用范围，其中我各个认为LoadRunner 最全面，它提供了多种协议的支持，对复杂的压力测试都可以胜任，WAS与ACT则对微软的技术支持的比较好，其中WAS支持分布式机群测试,ACT则是与.NET集成比较好，支持ViewState （.NET 下控件缓存的支持） 的测试，当时我用时，其它测试工具还不支持，现在应该支持了吧，呵呵。在这一阶段测试你要不断的跟据系数的测试目标进行变化，一开始由于系统过于庞大，所以我们要分成若干个子系统，各个子系统的性能目标必需明确，主要是并发指标定一个阀值，同时设定一些与系统相关的测试参数，应用服务器，数据库服务器都要有，对达不到阀值的与一些通用参数有问题的子系统进行深入分析。比如它的并发达不到你的要求，证明子系统性能有问题，或是数据库用户连接过高，程序没有释放用户连接等等。这个我们要对子系统进行详细测试，由于B/S 结构下,图片的请求对性能的影响较大，所以我们对子系统测试时要分两个部分进行，一、非程序部分，即图片等等;二、应用程序本身。通过事务或函数的分离，可以把这两块实现单独的测试，具体做法参考各个工具的手册，我这里就不做说明。对子系统的测试参数的设置要求则更高，它有助你后面精确的定位问题，比如对异常，死锁，网络流量等等前面没有注意到的情况的增加，同时你要注意增加测试参数的收集对系统的性能影响比较大，所以一般不要超过10个，刚刚介绍的整体的性能测试指标也不要增加很多，这样影响会小一点。最后在这一阶段要说明的是数据库的数据量会很大程度的影响性能，所以要根据前面的性能需求说明书向数据库中模拟相应的数据量，来进行测试，这样才有更高的可信度。
上面所说的是对问题的发现，下面就是分析问题原因，这一步的要求比较高，一般由测试人员与程序员配合完成，当然如果你有相当的开发经验，再做这方面的测试，就更为难得。下面我们说说如何精确定位问题，出现问题的可能性可能有很多种，大致分以下几种，一、性能达不到目标；二、性能达到目标，但有一些其它的问题，比如异常，死锁，缓存命中过低，网络流量较大；三、服务器稳定性的问题，比如内存泄漏……。要发现这些问题起马的要求要有一款使用的比较称心的性能分析与优化工具，比如微软的.NET下就有自己开发的工具，对Borland的Java开发工具中也有类似的工具，但我个人认为更好的工具是Rose下的Purify与Quantify,主要是他对.net 与java ,C++都有支持，而且分析效果特别专业，我们先了解一下Rational Purify, Rational Purify 能自动找出Visual C/C++ 和Java 代码中与内存有关的错误，确保整个应用程序的质量和可靠性。在查找典型的Visual C/C++ 程序中的传统内存访问错误，以及Java，C# 代码中与垃圾内存收集相关的错误方面；Rational Quantity 则是一款针对函数级的性能分析利器，使用它你可以从图形化的界面中得到函数调用的时间，百分比与次数，以及子函数所占时间，使你可以更快的定位性能瓶颈。
我们先说性能优化与异常的处理，性能优化有一个原则，即用时间比例最大的进行优化，效果才最明显，比如有个函数它的执行时间为30秒，如果你优化了一百倍则执行时间为0.3秒,提升了29.7秒，而如果它的执行时间为0.3秒，优化后为0.003秒，实际提升了0.297秒，提升的效果并不明显，而且写过程序的人都知道，后者性能优化的代价更大。在性能优化的过程中，一般是先数据库，后程序，因为数据库的优化不需要修改程序，修改的风险很小。但如何才能确定是数据库的问题，这就需要技巧，在使用Quantity时，你一路分析下去，大多数最终会发现，是数据库查询函数占用时间比较大，比如什么，SqlCmd.ExecuteNoQuery等等数据库执行函数,这时你就需要分析数据库，呵呵。数据库的分析原则是先索引，后存储过程，最后表结构视图的优化，索引的优化是最简单也是通常最有效的方法，如果合理的使用会带来意想不到不到的效果。在这里我要给大家简单的介绍一下我的最爱，SQLProfile,SQL查询分析器，Precise,SQLProfile是一个SQL语句跟踪器，可以跟踪程序流程使用的SQL语句与存储过程，结合查询分析器对SQL的分析，可以对索引的优化做出很好的判断，但索引也不是万能的，在增删改较多的表，索引过多会引起这些操作的性能下降，所以判断还是需要一定的经验。同时针对用户使用频度最高的SQL进行优化也是最行之有效的，这时我则需要Precise，它可以观测某一个较长时间内的SQL语句的执行情况。数据库优化的潜能挖光后，如果还是达不到性能要求或是还有问题，则要从程序来进行优化，这是程序员做的事，测试人员要做的，就是告诉他们，哪个函数执行过多引起了性能下降，比如异常过多，某个循环过多，或是DCOM调用过多等等，但说服程序员也是一件不容易的事，你要在这一阶段做的出色一定要有几年的编程经验，并且要让程序员感到听你的性能会有提升，这是一件很不容易的事情哦。
内存的分析，一般是一个长期分析的过程，要做好不容易，首先要有长期奋战的准备，其次内存泄漏的分析最好是放在单元测试之中同步进行，而不是要等到最后再去发现问题，当然出了问题也只好面对，一般这类问题都是在服务器运行了很久才暴露出来，一旦发现问题后，则需要定位问题，分析的原则采用子系统相互独立运行，找到最小问题的系统集,或是借助内存分析工具观察内存对象情况，初步定位问题，再用Purify进行运行时分析，通常C++ 内存问题比较多，Java与.NET比较少，一般由GC不合理引起。C++的内存错误就比较多了，主要常见的有:
1、 Array Bounds Read (ABR) ：数组越界读
2、 Array Bounds Write (ABW)：数组越界写
3、 Beyond stack Read (BSR)：堆栈越界读
4、 Free Memory Read(FMR)：空闲内存读
5、 Invalid pointer Read(IPR)：非法指针阅读
6、 Null Pointer Read(NPR)： 空指针阅读
7、 Uninitialized Memory Read(UMR)：未初始化内存读写
8、 Memory Leak：内存泄漏
注：如果需要更多的信息，可以参见Purify的帮助信息。
顺便提一句，为什么我要说单元测试时做这个比较好，由于单元测试针对的是单一功能，这时结合单元测试案例做内存分析会更快的定位问题，同时由于问题较早的发现，则后期的风险则会减少，当然如果结合代码覆盖工具PureCoverage 来做就更完美了，呵呵。
完成此文，已经是凌晨了，也算是回答了前一段时间提出要进行B/S结构测试又无从下手的朋友的要求，在这里要向大家表达一下歉意，由于工作比较忙，难免对大家的来信有所疏漏，请大家原谅。此文的要求的读者，对测试工具有所了解，希望进入更深测试的同仁，希望我的文章给大家带来帮助,同时也借此文表达一些曾经帮助过我的朋友与同事。
注：本篇只是对B/S应用的测试过程作一个整体的描述，对某一个阶段使用的工具只是作大概的介绍,你也可使用你比较熟悉的工具达到相同的目标。
[color=#0000FF] 网站测试技术简介
1 概述
在一个软件项目开发中，系统测试是保证整体项目质量的重要一环，本文将就网站的测试技术及相应的自动测试工具做一个简要的介绍。主要就如下几个方面进行探讨：
功能测试
性能测试
安全性测试
稳定性测试
浏览器兼容性测试
可用性/易用性测试
链接测试
代码合法性测试
2 测试内容
2.1 功能测试
在实际工作中，功能在每一个系统中的具有其不确定性，而我们不可能采用穷举的方法进行测试，因而导致了功能测试较为困难，我们依据80/20原则（即80%的错误存在于系统的20%的部分）对于测试用例的设计采用如下两种方法
2.1.1 白盒测试
白盒测试即使用程序设计的控制结构导出测试用例。基于目前的现状我们采用基本路径测试方法进行白盒测试，此种方法简单高效。基本路径测试方法的简单说明如下：
¨ 首先通过系统设计的流程图导出数据流图
¨ 根据数据流图计算其环形复杂性
V(G)=E-N+2
或 V(G)=P+1
V(G)：环形负责性
E ：流图中边的数量
N ：流图中节点的数量
P ：流图中判定节点的数量
¨ 我们设定V(G)条路径
¨ 我们设计V(G)条路径的模拟数据
¨ 根据数据进行相应的测试
2.1.2 黑盒测试
黑盒测试即派生出执行程序所有功能需求的输入条件，从而导出测试用例，进行测试的方法，黑盒测试用于辅助白盒测试。
我们采用等价划分的方法进行测试，即为将程序的输入域划分为数据类，以便导出测试用例。一般情况下输入条件为：一个特定的数值、一个数值域、一组相关值或者一个布尔条件。
2.1.3 网站功能测试
对于网站的测试而言，每一个独立的功能模块需要单独的测试用例的设计导出，主要依据为《需求分析》，对于应用程序模块需要设计者提供基本路径测试法的测试用例
具有测试用例后可以采用OpenSTA(Open System Testing Architecture)进行自动化测试
2.2 性能测试
网站的性能测试对于网站的运行而言异常重要，但是目前对于网站的性能测试做的不够，我们在进行系统设计时也没有一个很好的基准可以参考，因而建立网站的性能测试的一整套的测试方案将是至关重要的。
网站的性能测试主要从两个方面进行：负荷测试(Load)和压力测试(Stress),负荷测试指的是进行一些边界数据的测试，压力测试更像是恶意测试，压力测试倾向应该是致使整个系统崩溃。
性能测试可以采用相应的工具进行自动化测试，我们目前采用如下工具
ab -----Apache 的测试工具
OpenSTA—开发系统测试架构
2.3 安全性测试
目前网络安全问题日益重要，特别对于有交互信息的网站及进行电子商务活动的网站尤其重要。目前我们的测试没有涵盖网站的安全性的测试，我们拟定采用工具来测定，工具如下
SAINT------- Security Administrator';s Integrated Network Tool
此工具能够测出网站系统的相应的安全问题，并且能够给出安全漏洞的解决方案，不过是一些较为常见的漏洞解决方案。
2.4 稳定性测试
网站的稳定性测试是指网站的运行中整个系统是否运行正常，目前没有更好的测试方案，主要采用将测试服务器长时间运转进行测试。
2.5 浏览器兼容性测试
通过白盒测试或者黑盒测试导出的测试用例，采用相应的工具进行测试，可以采用OpenSTA进行测试，此测试工具可以采用不同的浏览器进行测试。
2.6 可用性/易用性测试
可用性/易用性方面目前我们只能采用手工测试的方法进行评判，而且缺乏一个很好的评判基准进行，此一方面需要大家共同讨论。
2.7 链接测试
超级链接对于网站用户而言意味着能不能流畅的使用整个网站提供的服务，因而链接将作为一个独立的项目进行测试。目前我们已经有了一个测试工具
Xenu------主要测试链接的正确性的工具
可惜的是对于动态生成的页面的测试会出现一些错误。
2.8 代码合法性测试
代码合法性测试主要包括2个部分：程序代码合法性检查与显示代码合法性检查
¨ 程序代码合法性检查
程序代码合法性检查主要标准为《intergrp小组编程规范》，目前采用由SCM管理员进行规范的检查，未来期望能够有相应的工具进行测试。
¨ 显示代码合法性检查
显示代码的合法性检查，主要分为Html、JavaScript、Css代码检查，目前采用
HTML代码检查------采用CSE HTML Validator进行测试
JavaScript、Css也可以在网上下载相应的测试工具。
3 测试工具
OpenSTA
主要做性能测试的负荷及压力测试，使用比较方便，可以编写测试脚本，也可以先行自动生成测试脚本，而后对于应用测试脚本进行测试。
SAINT
网站安全性测试，能够对于指定网站进行安全性测试，并可以提供安全问题的解决方案。
CSE HTML Validator
一 个有用的对于HTML代码进行合法性检查的工具
Ab(Apache Bench)
Apache自带的对于性能测试方面的工具，功能不是很多，但是非常实用。
Crash-me
Mysql自带的测试数据库性能的工具，能够测试多种数据库的性能。
上述工具除Ab及Crash-me外均可在以下目录中找得到
[url=文件://smbserver/apps/linuxapp/intergrp]/smbserver/apps/linuxapp/intergrp[/url]
ab及Crash-me请至相应的网站上察看相应的资料}
4 后记
此文只是对于网站的测试方面做了一个简单的介绍，提供的工具比较少，但是可以保证能够使用（当然都是可以从网上免费得到的），另外还有很多测试工具是需要Money的，大家有兴趣可以试用，对于上述提到的测试工具我也只是做了一个初步的调研，详细的功能说明请察看相关的说明文档。
对于网站的测试中比较重要的还有一个部分就是对于数据库的测试，由于对于数据库性能测试较好的工具需要一些Money因而我们采用Mysql的Crash-me,但是同时也存在一个问题就是对于不同的数据库的测试采用第三方的工具较好。因而大家可以对于其他数据库性能测试的工具进行研究。
5 参考资料
(1)《软件工程-实践者的研究方法》-----Roger S.Pressman
(2) http://www.softwareqatest.com
(3) http://www.soft.com/
(4) http://www.qaforums.com
(5) http://www.opensta.org
[color=#0000FF] WEB应用程序测试方法和测试技术详述
1. 概述
随着 web 应用的增多，新的模式解决方案中以 web 为核心的应用也越来越多， 很多公司各种应用的架构都以 B/S 及 web 应用为主，但是有关 WEB 测试方面的内容并没有相应的总结，所以我在这里对 web 的测试方法和采用的测试技术进行总结，便于内部交流。
测试方法尽量涵盖 web 程序的各个方面，测试技术方面在继承传统测试技术的技术上结合 web 应用的特点。
2. 测试方法
说明：测试方法的选择取决你的测试策略。
一般的 web 测试和以往的应用程序的测试的侧重点不完全相同，基本包括以下几个方面。
当然圆满的完成测试还要有好的团体和流程等的方方面面的支持，你同样应该对这些方面进行注意。有些测试方法设计到了流程，哪些应该在你的测试团队建设中建立。
2.1 界面测试
现在一般人都有使用浏览器浏览网页的经历，用户虽然不是专业人员但是对界面效果的印象是很重要的。如果你注重这方面的测试，那么验证应用程序是否易于使用就非常重要了。很多人认为这是测试中最不重要的部分，但是恰恰相反界面对不懂技术的客户来说那相当关键，慢慢体会你会明白的。
方法上可以根据设计文档，如果够专业的话可以专业美工人员，来确定整体风格页面风格，然后根据这个可以页面人员可以生成静态的 HTML ， CSS 等甚至生成几套不用的方案来讨论，或者交给客户评审，最后形成统一的风格的页面 / 框架。注意不要靠程序员的美术素养形成你的 web 风格，那样可能会很糟糕。
主要包括以下几个方面的内容：
- 站点地图和导航条 位置、是否合理、是否可以导航等内容布局 布局是否合理，滚动条等简介说明 说明文字是否合理，位置，是否正确；
- 背景 / 色调 是否正确、美观，是否符合用户需求；
- 页面在窗口中的显示是否正确、美观（在调整浏览器窗口大小时，屏幕刷新是否正确）表单样式 大小，格式，是否对提交数据进行验证（如果在页面部分进行验证的话）等；
- 连接 连接的形式，位置，是否易于理解等。
web测试的主要页面元素
- 页面元素的容错性列表（如输入框、时间列表或日历）；
- 页面元素清单（为实现功能，是否将所需要的元素全部都列出来了，如按钮、单选框、复选框、列表框、超连接、输入框等等）；
- 页面元素的容错性是否存在；
- 页面元素的容错性是否正确；
- 页面元素基本功能是否实现（如文字特效、动画特效、按钮、超连接）；
- 页面元素的外形、摆放位置（如按钮、列表框、核选框、输入框、超连接等）；
- 页面元素是否显示正确（主要针对文字、图形、签章）；
- 元素是否显示（元素是否存在）；
- 页面元素清单（为实现功能，是否将所需要的元素全部都列出来了，如按钮、单选框、复选框、列表框、超连接、输入框等等）。
测试技术
- 通过页面走查，浏览确定使用的页面是否符合需求。可以结合兼容性测试对不用分辨率下页面显示效果，如果有影响应该交给设计人员提出解决方案；
- 可以结合数据定义文档查看表单项的内容，长度等信息；
- 对于动态生成的页面最好也能进行浏览查看。如 Servelet 部分可以结合编码规范，进行代码走查。是否支持中文，如果数据用 XML 封装要做的工作会多一点等等。
2.1.l 界面测试要素 :
符合标准和规范 , 灵活性 , 正确性 , 直观性 , 舒适性 , 实用性 , 一致性
2.1.l.1 直观性 :
- 用户界面是否洁净, 不唐突, 不拥挤. 界面不应该为用户制造障碍 . 所需功能或者期待的响应应该明显 , 并在预期出现的地方；
- 界面组织和布局合理吗? 是否允许用户轻松地从一个功能转到另一个功能? 下一步做什么明显吗? 任何时刻都可以决定放弃或者退回, 退出吗? 输入得到承认了吗? 菜单或者窗口是否深藏不露?
- 有多余功能吗? 软件整体抑或局部是否做得太多? 是否有太多特性把工作复杂化了? 是否感到信息太庞杂?
- 如果其他所有努力失败 , 帮助系统真能帮忙吗?
2.1.l.2 一致性
- 快速键和菜单选项 . 在 Windows 中按 F1 键总是得到帮助信息；
- 术语和命令. 整个软件使用同样的术语吗? 特性命名一致吗? 例如, Find 是否一直叫Find, 而不是有时叫Search?
- 软件是否一直面向同一级别用户? 带有花哨用户界面的趣味贺卡程序不应该显示泄露技术机密的错误提示信息；
- 按钮位置和等价的按键 . 大家是否注意到对话框有 OK 按钮和 Cancle 按钮时, OK 按钮总是在上方或者左方, 而 Cancle 按钮总是在下方或右方? 同样原因, Cancle 按钮的等价按键通常是 Esc, 而选中按钮的等价按钮通常是 Enter. 保持一致。
2.1.l.3 灵活性
状态跳转：灵活的软件实现同一任务有多种选择方式；
状态终止和跳过：具有容错处理能力；
数据输入和输出：用户希望有多种方法输入数据和查看结果 . 例如 , 在写字板插入文字可用键盘输入 , 粘贴, 从 6 种文件格式读入 , 作为对象插入 , 或者用鼠标从其他程序拖动。
2.1.l.4 舒适性
恰当：软件外观和感觉应该与所做的工作和使用者相符；
错误处理：程序应该在用户执行严重错误的操作之前提出警告 , 并允许用户恢复由于错误操作导致丢失的数据，如大家认为 undo /redo 是当然的；
性能：快不见得是好事，要让用户看得清程序在做什么，它是有反应的。
2.2 功能测试
功能测试是测试中的重点，主要包括一下几个方面的内容：
连接：这个连接和界面测试中的连接不同。那里注重的是连接方式和位置，如是图像还是文字放置的位置等，还是其他的方式；这里的连接注重功能，如是否有连接，连接的是否是说明的位置等；
表单提交：应当模拟用户提交，验证是否完成功能，如注册信息，要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。还有数据正确性验证，异常处理等，最好结合易用性要求等。 B/S 结构实现的功能可能主要的就在这里，提交数据，处理数据等如果有固定的操作流程可以考虑自动化测试工具的录制功能，编写可重复使用的脚本代码，可以在测试、回归测试时运行以便减轻测试人员工作量；
Cookies 验证：如果系统使用了 cookie ，测试人员需要对它们进行检测。如果在 cookies 中保存了注册信息，请确认该 cookie 能够正常工作而且已对这些信息已经加密。如果使用 cookie 来统计次数，需要验证次数累计正确。关于 cookie 的使用可以参考浏览器的帮助信息。如果使用 B/S 结构 cookies 中存放的信息更多；
功能易用性测试 完成了功能测试可以对应用性进行了解，最好听听客户的反映，在可以的情况下对程序进行改进是很有必要的，和客户保持互动对系统满意度也是很有帮助的。
2. 2.1 测试技术
功能测试的测试技术可是很多的，我们可以结合实际环境选择使用。
白盒测试技术(White Box Testing)： 深入到代码一级的测试，使用这种技术发现问题最早，效果也是最好的。该技术主要的特征是测试对象进入了代码内部，根据开发人员对代码和对程序的熟悉程度，对有需要的部分进行在软件编码阶段，开发人员根据自己对代码的理解和接触所进行的软件测试叫做白盒测试。这一阶段测试以软件开发人员为主，在 JAVA 平台使用 Xunit 系列工具进行测试， Xunit 测试工具是类一级的测试工具对每一个类和该类的方法进行测试。
黑盒测试技术(Black Box Testing)：黑盒测试的内容主要有以下几个方面，但是主要还是功能部分。主要是覆盖全部的功能，可以结合兼容，性能测试等方面进行，根据软件需求，设计文档，模拟客户场景随系统进行实际的测试，这种测试技术是使用最多的测试技术涵盖了测试的方方面面，可以考虑以下方面
正确性 (Correctness) ：计算结果，命名等方面。 Ø
可用性 (Usability) ：是否可以满足软件的需求说明。 Ø
边界条件 (Boundary Condition) ：输入部分的边界值，就是使用一般书中说的等价类划分，试试最大最小和非法数据等等。 Ø
性能(Performance)： 正常使用的时间内系统完成一个任务需要的时间，多人同时使用的时候响应时间在可以接受范围内。 J2EE 技术实现的系统在性能方面更是需要照顾的，一般原则是 3 秒以下接受， 3-5 秒可以接受， 5 秒以上就影响易用性了。如果在测试过程中发现性能问题，修复起来是非常艰难的，因为这常常意味着程序的算法不好，结构不好，或者设计有问题。因此在产品开发的开始阶段，就要考虑到软件的性能问题
压力测试(Stress)： 多用户情况可以考虑使用压力测试工具，建议将压力和性能测试结合起来进行。如果有负载平衡的话还要在服务器端打开监测工具 , 查看服务器 CPU 使用率，内存占用情况，如果有必要可以模拟大量数据输入，对硬盘的影响等等信息。如果有必要的话必须进行性能优化 ( 软硬件都可以 ) 。这里的压力测试针对的是某几项功能。
错误恢复(Error Recovery)：错误处理，页面数据验证，包括突然间断电，输入脏数据等。
安全性测试(Security)：这个领域正在研究中，防火墙、补丁包、杀毒软件等的就不必说了，不过可以考虑。破坏性测试时任意看了一些资料后得知 , 这里面设计到的知识 / 内容可以写本书了 , 不是一两句可以说清的，特别是一些商务网站，或者跟钱有关，或者和公司秘密有关的 web 更是需要这方面的测试，在外国有一种专门干这一行的人叫安全顾问，可以审核代码，提出安全建议，出现紧急事件时的处理办法等，在国内没有听说哪里有专门搞安全技术测试的内容。
兼容性(Compatibility)：不同浏览器，不同应用程序版本在实现功能时的表现不同的上网方式，如果你测试的是一个公共网站的话。
兼容性测试内容详述：
- 硬件平台
- 浏览器软件和版本：浏览器插件，浏览器选项，视频分辨率和色深，文字大小，调制解调器速率 .
软件配置 (Configuration)：如 IE 浏览器的不用选项 - 安全设定最高，禁用脚本程序等等，你们的程序在各种不用的设置下表现如何。
2. 2.2 单元测试技术 (Unit Test):
2. 2.2.1 下面是对白盒测试和单元测试的区别的论述 :
单元测试和白盒测试是不同的，虽然单元测试和白盒测试都是关注功能，他们都需要代码支持，但是级别不同。白盒测试关注的是类中一个方法的功能，是更小的单位，但是完成一个单元测试可能需要 N 多类，所以说作单元测试需要写驱动和稳定桩，比如查询单元是一个查询包，包括 N 多的测试类、测试数据，运行他需要提供数据的部分，输入参数和发出命令的驱动等等，是比类大的一个整体进行的。
另一个明显的区别是白盒测试不会关注类接口，但是单元测试主要的内容就是类接口测试。
不过很多时候是很少区分的，因为这两种技术实现起来有很多相互关联的部分。不过要看你对质量的关注程度来决定。
2. 2.2.2 功能测试边界测试 / 越界测试技术详述
边界条件
边界条件是指软件计划的操作界限所在的边缘条件，如果软件测试问题包含确定的边界，那么数据类型可能是：数值、速度、字符、地址、位置、尺寸、数量。同时，考虑这些类型的下述特征：第一个 / 最后一个、最小值 / 最大值、开始 / 完成、超过 / 在内、空 / 满、最短 / 最长、最慢 / 最快、最早 / 最迟、最大 / 最小、最高 / 最低、相邻 / 最远。
越界测试
通常是简单加 1 或者很小的数 ( 对于最大值 ) 和减少 1 或者很小的数 ( 对于最小值 ) ，例如：第一个减 1/ 最后一个加 1 、开始减 1/ 完成加 1 、空了再减 / 满了再加、慢上加慢 / 快上加快、最大数加 1/ 最小数减 1 、最小值减 1/ 最大值加 1 、刚好超过 / 刚好在内、短了再短 / 长了再长、早了更早 / 晚了更晚、最高加 1/ 最低减 1 。
另一些该注意的输入：默认，空白，空值，零值和无；非法，错误，不正确和垃圾数据。
2. 2.2.3 状态测试技术
- 软件可能进入的每一种独立状态；
- 从一种状态转入另一种状态所需的输入和条件；
- 进入或退出某种状态时的设置条件及输入结果。
具体测试方法可以参考如下：
- 每种状态至少访问一次；
- 测试看起来最常见最普遍的状态转换；
- 测试状态之间最不常用的分支；
- 测试所有错误状态及其返回值；
- 测试随机状态转换。
2. 2.2.4 竞争条件测试技术
竞争条件典型情形参考如下 :
- 两个不同的程序同时保存或打开同一个文档；
- 共享同一台打印机 , 通信端口或者其他外围设备；
- 当软件处于读取或者修改状态时按键或者单击鼠标；
- 同时关闭或者启动软件的多个实例；
- 同时使用不同的程序访问一个共同数据库。
2. 2.3 负载 / 压力测试 (StressTest)
在这里的负载 / 压力和功能测试中的不同，他是系统测试的内容，是基本功能已经通过后进行的。可以在集成测试阶段，亦可以在系统测试阶段进行。
使用负载测试工具进行，虚拟一定数量的用户看一看系统的表现，是否满足定义中的指标。
负载测试一般使用工具完成， loadrunner ， webload ， was ， ewl ， e-test 等，主要的内容都是编写出测试脚本，脚本中一般包括用户常用的功能，然后运行，得出报告。所以负载测试包括的主要内容就不介绍了。
负载测试技术在各种极限情况下对产品进行测试 ( 如很多人同时使用该软件，或者反复运行该软件 ) ，以检查产品的长期稳定性。例如，使用压力测试工具对 web 服务器进行压力测试。本项测试可以帮助找到一些大型的问题，如死机、崩损、内存泄漏等，因为有些存在内存泄漏问题的程序，在运行一两次时可能不会出现问题，但是如果运行了成千上万次，内存泄漏得越来越多，就会导致系统崩滑。用 J2EE 实现的系统很少但是并不是没有内存问题。
无论什么工具基本的技术都是利用线程技术模仿和虚拟用户，在这里主要的难点在与测试脚本的编写，每种工具使用的脚本都不一样，但是大多数工具都提供录制功能就算是不会编码的测试人员同样可以测试。
对负载工具的延伸使用可以进行系统稳定性测试，系统极限测试，如使用 100 的 Load Size 连续使用 24 小时，微软定义的通过准则是通过 72 小时测试的程序一般不会出现稳定性的问题。
2. 2.4 回归测试 (Regression Test)
过一段时间以后，再回过头来对以前修复过的 Bug 重新进行测试，看该 Bug 是否会重新出现。
回归测试技术可以在测试的各个阶段出现，无论是单元测试还是集成测试还是系统测试。是对以前问题进行验证的过程。
回归测试的目的就是保证以前已经修复的 Bug 不会再出现。实际上，许多 Bug 都是在回归测试时发现的，在此阶段，我们首先要检查以前找到的 Bug 是否已经更正了。值得注意的是，已经更正的 Bug 也可能又回来了，有的 Bug 经过修改之后可能又产生了新的 Bug 。所以，回归测试可保证已更正的 Bug 不再重现，不产生新的 Bug 。
2. 2.5 Alpha 和 Beta 测试 (Alpha and Beta Test):
在正式发布产品之前往往要先发布一些测试版，让用户能够反馈出相关信息，或者找到存在的 Bug ，以便在正式版中得到解决。
特别是在有客户参加的情况下，对系统进行测试可能会出现一些我们没有考虑的情况，还可以解决一些客户实际关心的问题。
不同的测试技术区分
2.3 覆盖测试技术
说明 : 测试覆盖率可以看出测试的完成度，在测试分析报告中可以作为量化指标的依据，测试覆盖率越高效果越好。
覆盖测试可以是程序代码的执行路径覆盖，亦可以是功能实现的步骤覆盖（可以理解成流程图的路径覆盖）。
该技术可以用在任何测试阶段，包括单元测试、集成测试、系统测试。
使用该技术时可以使用以上的任何测试方法和测试技术。
2.4 白盒测试和黑盒测试技术
白盒测试技术 (White Box Testing) ：该技术主要的特征是测试对象进入了代码内部，根据开发人员对代码和对程序的熟悉程度，对有需要的部分进行测试。在软件编码阶段，开发人员根据自己对代码的理解和接触所进行的软件测试叫做白盒测试。这一阶段测试以软件开发人员为主，使用 Xunit 系列工具进行测试，可以包括很多方面如功能性能等。
黑盒测试 (Black Box Testing) ：测试的主体部分，黑盒测试的内容主要有以下几个方面，但是主要还是功能部分。主要是覆盖全部的功能，可以结合兼容，性能测试等方面进行，包括的不同测试类型请参考以上内容。
2.5 手工测试和自动化测试
手工测试 （ Manual Testing ）：即依靠人力来查找 Bug 。方法可以参考上边的测试，也可以根据对实现技术及经验等进行不同的测试。
自动测试 （ Automation Testing ）：使用有针对工具实行。可以作出自动化测试的计划，对可以进行自动化测试的部分编写或者录制相应的脚本，可以加入功能，容错，表单提交等，可以参考 MI,Rational 或者其他类测试工具说明。
根据权威的软件测试经验，手工测试还是主要的测试方法，自动测试不够灵活，在这里不再详述。微软的测试过程 80 ％还是手工完成。
自动测试永远也代替不了手工测试，但是手工测试的工作量很大是不争的事实。
2.6 根据 RUP 标准按阶段区分测试
单元测试：在上边有详细的叙述，还有针对单元测试和集成测试的论述，请参考。
集成测试：分为功能集成测试和系统集成测试，相互有调用的功能集成，在系统环境下功能相互调用的影响等，使用方法可以任意选用上面的内容。注重功能方面。
系统测试：在功能实现的基础上，可以加入兼容性，易用性，性能等等。
验收测试：可以包括 Alpha 和 Beta 测试，在这里就不再详述。
3. 存在风险及解决方法
说明：测试不能找出所有的问题，只是尽量在开发阶段解决大多数的问题而已。
测试风险如下：
软硬件的测试环境提供上也对测试结果有很大的影响；
测试团队的水平，经验，合作效果等；
整个开发流程对测试的重视程度，测试的进入时间等；
由于测试环境操作系统，网络环境，带宽等情况可能产生的测试结果可能不同这是就需要经验以及对测试环境的保护等方面下一些功夫。
4. 软件缺陷的原则
软件缺陷区别于软件 bug, 它是在测试过程中出现的对系统有影响的，但是在设计中没有的或者对修改后的 bug 测试和开发人员有不同意见等。
- 软件未达到产品说明书标明的功能；
- 软件出现了产品说明书指明不会出现的错误；
- 软件功能超出产品说明书指明范围；
- 软件未达到产品说明书虽未指出但应达到的目标；
- 软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。
5. 文档测试
产品说明书属性检查清单
完整：是否有遗漏和丢失？完全吗？单独使用是否包含全部内容？
准确：既定解决方案正确吗？目标明确吗？有没有错误？
精确：不含糊，清晰。描述是否一清二楚？还是自说自话？容易看懂和理解吗？
一致：产品功能描述是否自相矛盾？与其他功能有没有冲突 ?
贴切：描述功能的陈述是否必要 ? 有没有多余信息 ? 功能是否满足的客户要求 ?
合理：在特定的预算和进度下，以现有人力，物力和资源能否实现 ?
代码无关：是否坚持定义产品，而不是定义其所信赖的软件设计，架构和代码 ?
可测试性：特性能否测试 ? 测试员建立验证操作的测试程序是否提供足够的信息 ?
产品说明书用语检查清单
说明：对问题的描述通常表现为粉饰没有仔细考虑的功能 ---- 可归结于前文所述的属性。从产品说明书上找出这样的用语，仔细审视它们在文中是怎样使用的。产品说明书可能会为其掩饰和开脱 , 也可能含糊其词 ---- 无论是哪一种情况都可视为软件缺陷。
- 总是，每一种，所有，没有，从不。如果看到此类绝对或肯定的，切实认定的叙述，软件测试员就可以着手设计针锋相对的案例。
- 当然，因此，明显，显然，必然。这些话意图诱使接受假定情况，不要中了圈套。
- 某些，有时，常常，通常，惯常，经常，大多，几乎。这些话太过模糊， " 有时 " 发生作用的功能无法测试。
等等，诸如此类，依此类推。以这样的词结束的功能清单无法测试，功能清单要绝对或者解释明确，以免让人迷惑，不知如何推论。
- 良好，迅速，廉价，高效，小，稳定。这些是不确定的说法，不可测试。如果在产品说明书中出现，就必须进一步指明含义。
- 已处理，已拒绝，已忽略，已消除。这些廉洁可能会隐藏大量需要说明的功能。
- 如果 ... 那么 ...( 没有否则 ) 。找出有 " 如果 ... 那么 ..." 而缺少配套的 " 否则 " 结构的陈述，想一想 " 如果 " 没有发生会怎样。