第六个技巧：合理处理NULL字段。

　　Null字段在数据库中是一个比较特殊的字段。Null字段表示未知值或者说缺少数据，注意若某个字段的值为Null，则这个字段即不是空格，也不是0。当插入记录的时候，若这个字段没有被赋值，而且也没有默认值的话，则这个字段系统默认给他的值就是“Null”。

　　由于这个值比较特殊，在查询的时候，及时经验丰富的数据库管理员，有时候在处理起来的时候，也会发生错误。为此，笔者在这里总结一些，在数据库查询的时候，关于这个空字段查询的一些需要注意的地方。

　　一是要注意NULL字段的数字运算问题。

　 　如现在在一个薪资管理系统中，有一张薪资表，其中有基本工资与加班工资两个字段。若某个用户的基本工资为2000，而其加班工资没有。在输入这条记录的 时候，由于加班工资这个字段中，没有输入数据，而且在数据库设计的时候，也没有个这个字段设置0的默认值。所以，当这条记录保存的时候，数据库系统会给这 个字段自动赋值，这个字段的值就为NULL。

　　若我们用Select语句查询这条记录的时候，其加班工资这个字段显示的数据是空的。看起来好像是空格，而实际上其存储的不是空格。此时，我们若利用查询语句想知道，这个员工的总的工资(即加班工资加上基本工资)为多少的时候会有什么结果呢?

　 　我们可以利用Select 员工姓名,基本工资,加班工资,基本工资+加班工资 as 总工资 FROM 员工薪资表; 我们可以通过这条语句来查询这个员工总的工资是多少。但是，这条语句会查询出我们想要的结果吗?我们执行一下这条语句，结果我们会发现，得出的结果跟我们 想象的大相径庭。最后显示的总工资一栏中，为空格。

　　原来，Oracle数据库设计中，若一个NULL字段跟其他字段进行四则运算时，其显示的结果都为空。所以，若一个字段为NUU，则无论加减乘除，最后其结果都返回的施NULL值。这显然跟我们想象的不同。

　　针对这种情况，我们该如何处理呢?在数据库设计过程中，主要有两种处理方法。

　　一是在设计表的时候，对于这些需要参与运算的字段，要设置默认值。如可以把这个字段的默认值设置为0。则当添加这条记录的时候，即使前台用户没有给其设置值。在保存数据的时候，系统也会给其默认值0。如此的话，在进行四则运算的时候，才可能得到我们想要的值。

　 　二是在查询的时候，需要考虑到这个NULL值的影响。有时候，若数据库中已经有记录，则不能够改变数据库字段的默认值。遇到这种情况，若我们需要对 NULL字段与数字字段进行四则运算的时候，又该如何处理呢?此时，我们就需要在查询的时候，给NULL字段赋0的值。具体我们可以在查询语句中，如此定 义。Select 员工姓名,基本工资,加班工资,基本工资+NVL(加班工资,0) as 总工资 FROM 员工薪资表;如此的话，当加班工资的值为NULL的时候，则系统在运算的时候，会把其当作0来处理。这么处理，我们就可以得到我们所想要的结果。不过一般 情况下，这一种处理方式是不得已而为之的。最好的是，在数据库表设计的时候，就给相关的字段设置0的默认值。

　　另外，还有一个函数 NVL2跟NVL函数功能类似，只是其多了一个参数而已，其表达式为NVL2(参数1，参数2，参数3)。它的含义是，当参数1不为空值时，则返回的值为 参数2;当参数1是空值时，则范围的是参数3。若用这个函数实现NVL函数的目的时，则就需要如此改写上面这个案例的函数参数写法：NAV2 (加班工资，基本工资+加班工资，基本工资)。可见，两个函数有异曲同工之妙。具体采用哪种函数为好，则就需要根据数据库管理员的爱好来选择了。

　　二是如何查询NULL字段。

　 　如果现在有一张员工基本信息表，其中有一个身份证号码的字段。现在若用户想知道，有哪些员工还没有记录身份证号码信息，该如何做呢?由于这个 NULL字段不为空格或者0。若我们在查询条件语句中，利用’0’ 或者’’(空格)作为查询条件的话，是查不到我们所需要的结果的。此时，在数据库中，提供了一个专门用户查询NULL字段记录的函数IS NULL。若我们现在想知道哪些员工没有注明身份证信息时，就可以利用如下的语句来实现。

　　Select 员工姓名,身份证号码 from 员工基本信息表 where 身份证号码 is not null;

　　通过以上这条语句就可以实现查找身份证件为空的员工信息的目的。

　　数据查询，是数据库操作中最主要的功能之一；有时候数据库查询性能的好坏，直接关系到数据库的运行效率，关系到数据库的选型。下面笔者不谈大道理，只是对其中对一些平时大家容易忽略的查询小技巧做一些总结。或许大家可能正在为此犯愁呢?

　　第一个技巧：利用连接符连接多个字段。

　 　如在员工基本信息表中，有员工姓名、员工职位、出身日期等等。如果现在视图中这三个字段显示在同一个字段中，并且中间有分割符。如我现在想显示的结果为 “经理Victor出身于1976年5月3日”。这该如何处理呢?其实，这是比较简单的，我们可以在Select查询语句中，利用连接符把这些字段连接起 来。

　　如可以这么写查询语句：

　　SELECT员工职位 ||’ ’ ||员工姓名||’出身于’||出身日期 as 员工出身信息 FROM 员工基本信息表;

　 　通过这条语句就可以实现如上的需求。也就是说，我们在平时查询中，可以利用||连接符把一些相关的字段连接起来。这在报表视图中非常的有用。如笔者以前 在设计图书馆管理系统的时候，在书的基本信息处有图书的出版社、出版序列号等等内容。但是，有时会在打印报表的时候，需要把这些字段合并成一个字段打印。 为此，就需要利用这个连接符把这些字段连接起来。而且，利用连接符还可以在字段中间加入一些说明性的文字，以方便大家阅读。如上面我在员工职位与员工姓名 之间加入了空格;并且在员工姓名与出身日期之间加入了出身于几个注释性的文字。这些功能看起来比较小，但是却可以大大的提高内容的可读性。这也是我们在数 据库设计过程中需要关注的一个内容。

　　总之，令后采用连接符，可以提高我们报表的可读性于灵活性。

　　第二个技巧：取消重复的行。

　　如在人事管理系统中，有员工基本信息基本表。在这张表中，可能会有部门、职位、员工姓名、身份证件号码等字段。若查询这些内容，可能不会有重复的行。但是，我若想知道，在公司内部设置了哪些部门与职位的时候，并且这些部门与职位配置了相关人员。此时，又该如何查询呢?

　 　若我现在直接查询部门表，其可以知道系统中具体设置了哪些部门与职位。但是，很有可能这些部门或者职位由于人事变动的关系，现在已经没有人了。所以，这 里查询出来的是所有的部门与职位信息，而不能够保证这个部门或者职位一定有职员存在。也就是说，这不能够满足于我们上面的要求。

　　若我现在直接从员工信息表中查询，虽然可以保证所查询出来的部门与职位信息，一定有员工信息的存在。但是，此时查询出来的部门与职位信息会有重复的行。如采购部门分工合作，可能会有采购采购小组长。此时，在查询出来的部门与职位的信息中，就会有三条重复的记录。

　　所以，以上两种处理方式，都不能够百分之百的满足企业用户的需求。此时，我们其实可以利用一个DISTINCT函数，来消除其中查询出来的重复行。

　　如我们可以利用SELECT DISTINCT 部门信息，职位信息 FROM 员工基本信息表。通过这条加了DISTINCT约束的查询语句，不但可以查询出所有有员工的职位与部门信息，而且，会把重复的记录过滤掉，从而提高可阅读性。

　　所以，在数据库设计过程中，特别是在查询语句的使用中，这个函数特别有用。

　　第三个技巧：勤用WHERE语句。

　 　我们都知道，数据库查询效率高不高，是我们评价数据库设计好坏的一个重要标准。毋庸置疑，在数据库查询中勤用Where条件语句，是提高数据库查询性能 的一个很重要的手段之一。特别是在设计到比较大的表中查询符合条件的记录过程中，利用WHERE条件语句加以限制，可以大幅度的提高查询的响应速度。

　 　如在图书馆管理系统中，现在有人想查询“注册会计师”辅导用书的时候，虽然不在书的类别或者名称中输入“注册会计师”，先查询出全部的纪录，然后再一条 条的看是否有相关的书籍信息，也是可行的。但是，这么处理的话，一方面系统响应的速度会非常的慢，因为里面记录很多。另一方面，查询的结果看起来也会非常 的头疼。

　　其实，我们只需要在查询中加入一些查询的参数，利用Where条件语句加以限制，则即可以提高数据库响应的速度，也可以找出最符合用户需求的数据。

　　另外，我也接触过一些在Oracle数据库上设计的平台型管理软件，他们可以自定义相关的报表。在报表设计中，只要用户在前台设计平台中，选中“大表查询”的话，则这个平台会在生成报表的时候，自动应用Where条件语句，以提高前台系统从数据库查询数据的效率。

　　所以，笔者认为在Oracle数据库系统设计中，要勤于使用Where语句。利用Where语句来提高数据库查询的效率。

　　测试的流程中，测试计划是对整个测试活动的安排，而测试用例则是测试执行的指导，但是，现在仍然有很多的测试人员没有认识到测试计划和测试用例的重要性，在项目时间比较紧张的情况下，计划和用例往往成了形式上的东西，甚至有些测试人员脱离用例，完全凭借自己的经验在执行测试活动，对此，你有什么样的看法？

　　个人认为做好测试计划的编写工作应该从以下几个方面考虑问题：

　　1、要充分考虑测试计划的实用性，即，测试计划与实际之间的接近程度和可操作性。

　 　编写测试计划的目的在于充分考虑执行测试时的各种资源，包括测试内容、测试标准、时间资源、人力资源等等，准确地说是要分析执行时所能够调用的一切资源 以及受各种条件限制，可能受到的各种影响。说的再明确一点就是要“计划”“如何”去做“测试工作”，而不是“如何编写测试计划”。

　　2、要坚持“5W1H”的原则，明确测试内容与过程。

　　明确测试的范围和内容（WHAT）；

　　明确测试的目的（WHY）；

　　明确测试的开始和结束日期（WHEN）；

　　明确给出测试文档和软件册存放位置（WHERE）；

　　明确测试人员的任务分配（WHO）；

　　明确指出测试的方法和测试工具（HOW）。

　　3、采用评审和更新机制，确保测试计划满足实际需求。

　　因为软件项目是一个渐进的过程，中间不可避免地会发生需求变化，为满足需求变化，测试计划也需要及时地进行变更。

　　之所以采取相应的评审制度，就是要对测试计划的完整性、正确性、可行性进行评估，以保证测试的质量。

　　4、测试策略要作为测试的重点进行描述。

　　测试策略是测试计划中的重要组成部分，测试计划是从宏观上说明一个项目的测试需求、测试方法、测试人员安排等因素，而测试策略则是说明世纪的测试过程中，应该怎样具体实施。因此，测试策略一定要描述详尽并且重点突出。

　　打个不太恰当的比喻，你可以认为测试计划就是测试工作的预期输出，而测试执行是测试工作的实际输出，在预期输出！=实际输出的情况下，您会认为这样的测试合格么？

　　至于测试用例工作，我认为我们首先要明确测试用例在整个测试工作中的地位及其作用。个人认为，测试用例在整个测试工作中的地位和作用主要体现在以下几个方面：

　　1、测试用例是测试执行的实体，是测试方法、测试质量、测试覆盖率的重要依据和表现形式；

　　2、测试用例是团队内部交流以及交叉测试的依据；

　　3、在回归测试中，测试用例的存在可以大大的降低测试的工作量，从而提高测试的工作效率；

　　4、测试用例便于测试工作的跟踪管理，包括测试执行的进度跟踪，测试质量的跟踪，以及测试人员的工作量的跟踪和考核；

　　5、在测试工作开展前完成测试用例的编写，可以避免测试工作开展的盲目性；

　　6、测试用例是说服用户相信产品质量的最佳依据，同时也可以提供给客户作为项目验收的依据。

　　当我们认识到测试用例在政工测试工作中的地位及其作用之后，相信大家都已经认识到了测试用例对测试工作的重要性和必要性，那么，我们就来讨论一下如何有效的保证测试用例的质量。

　　1、做好测试人员的项目培训（主要指对需求分析、软件设计、测试计划的认知程度）工作。要想发挥团队中每一个成员的所有能力，最好的办法就是让他们每一个人都清楚这个项目中的所有细节，以及自己要在这个项目中所承担的责任。

　　2、尽可能的利用以往其他项目的测试用例；并将该项目中类似模块进行归类，按类编写测试用例，再根据每个模块的特点进行修改，要充分利用测试用例的可重用性。

　　3、在时间资源紧张的情况下，可以按照测试的关键路径编写测试用例，针对关键路径的测试用例一定要详尽，其他边缘模块的测试用例可以考虑仅通过性测试（既仅证真测试）。

　 　4、采用针对测试用例的模块化编写。个人建议将测试用例和测试数据分开，测试用例中的操作步骤应主要体现于业务流程的检验，而测试数据主要体现于针对系 统的数据处理结果的检验。考虑到软件项目的需求变更问题，建议将这两项分开，通过测试用例编号进行关联，以应对需求变化造成的测试用例的修改，从而减少测 试用例的修改量，缩短项目周期，提高工作效率。

　　以上是针对“做好测试计划和测试用例的工作的关键是什么”的问题的个人见解，如有不同意见，请大家及时指出和补充。

版权声明：51Testing 软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像。 51testing软件测试网欢迎与业内同行进行有益的合作和交流，如果有任何有关内容方面的合作事宜，请联系我们。

质量入门介绍

　　根据国际标准组织（ISO）的定义，质量是依靠特定的或暗指的能力满足特定需要的产品或服务的全部功能和特征。这个 定义说明了质量是产品的内在特征，描绘了产品的质量观点。第二个学术派的观点坚持如果要达到质量的目标必须在这个质量的概念上要加强。这个学派认为，质量 不是单独以产品为中心的，而是和客户和产品都有联系的，其中客户是出资金者或受影响的部分人，而产品包括利益和服务。进一步讲，质量的概念会随着时间响应 和环境价值的改变而改变，价值会使人们弄清什么是好的、什么是不好的。因此，软件的质量作为产品或服务需要的功能/特征，也必须定位于客户和组织间的内容 (R.T. Vidgen,A.T. Wood-Harper)。这是关于质量的有用的观点。这些回顾的细节包含在以下几段文字里，第一步是人为因素。

　　质量观点

　　对于质量的观点，开发过程中的每个人都有不同的看法和矛盾。以下几点由开发过程中的几个关键角色提供的简要描述：

　　* 开发经理：产品是可靠的、可维护性好的，能够让客户满意，如此直到项目结束或强制终止（这导致折衷的需要）。

　　* 商业分析者：客户和开发小组联合，保护用户定义的功能和需求不受外部改变干扰。

　　* QA审计师：发现从质量方案/产品中脱轨的现象——所有使过程偏离质量控制的活动将受到与项目有关的人员的反对。

　　* 最终用户：初级雇员很少给系统输入什么，但是对它的操作必须有责任。最终用户不满意，当他们不愿意为系统付支票时，就需要监察系统的可接受程度了。

　　* 生产线经理：最终用户的老板通常持有这样的态度，即他们不需要太大的时间周期。

　　* 项目投资者：付钞票的人，需要按时、按预算地交付产品。

　　最后，是开发人员的质量观点，这直接影响到选择最终产品生产的方法。这不仅起源于开发者的质量观点（产品相对于使用），也起源于如何获得需求（主管相对于客观），和他们如何创造他们工作的环境（协调相对于冲突）。R.T.Vidgen和A.T.Wood-Harper提出了四种可能的开发者对质量的认识观点：
  * 客观的/协调的：在目标没有问题并且得到很好的描述时，开发人员会客观地认为质量是一个合理的工程过程。质量是和详细阐述、实现开发过程严格控制的需要结合的。开发者趋向于接受质量是产品的属性的观点（这是目前大多数软件工程师的观点）。

　　* 客观的/矛盾的：开发者不仅明白质量是客观的，而且理解矛盾的兴趣是可以解决的，于是不可能满足所有人的质量需求，而会确定满足谁的需求（使管理者的还是工人的呢？）。

　　* 客观的/一致的：开发者认为质量关系到团体的结构，要解决许多不同团体（投资者/受益者）的不同的观点和兴趣。最终的结果反映了不同观点的一致意见。

　　* 客观的/矛盾的：开发者考虑了不同的观点和兴趣，但是，假定会有冲突和功能上的限制，解放者构造质量的新思路，这要求满足多的兴趣而忽视少部分功能。这一点更像一种协调而不是意见统一。

　　质量特征和属性

　 　所有学派都认为质量软件有两个有区别的特征：第一，即是规范的一致性（如这是一个好的方案吗？），第二，即适合它的有意的目标（是问题的正确定位 吗？）。另外，所有学派都认为有一个构成高质量的软件的属性。搜索有关不同质量相关的文献都会有许多不同的属性列表，下面是Glass建议的七个属性：

　　轻便性：允许软件能够从一台计算机很容易地传输到另一台需要运行的计算机上的能力。

　　可靠性：软件正确无误地满足需求的能力。

　　效率：软件最小是用计算机资源（如内存、外存和机器时钟周期等）的能力。

　　人性化工程：软件能够容易地被人们理解和学习的能力。

　　易测性：为了测试软件的可执行性能的测试能力。

　　可理解性：软件能够被软件维护人员阅读并理解的方便程度。

　　可修改性：软件能够被软件维护人员修改的方便程度。

　　以上例出的属性并没有一个特定的先后顺序，就像质量本身一样，对这些属性没有绝对的层次关系。不是所有这些属性在任何软件工程项目里都有用。此外，用于实现这些属性的技术可能导致确实的、消极的相互冲突。因此，质量属性的优先此序列表必须在程序开发生命期之前定义，以弥补程序目标的不足和在各属性之间保留一定距离。

　　质量法则

　　有一条规律可以决定软件开发过程是如何引入软件质量因素的，那就是质量法则。软件开发团体已经认识到这个问题，并认为这有助于对生产软件过程的风险测试。在软件质量书籍《软件开发和支持成功框架》中，Curran和Sanders指出，软件质量过程要注意四点：

　　* 从一开始就要保证不出错，至少应该努力是错误尽量不在代码是发生。为了做到这一点包括采用适当的软件工程标准和过程，建立独立的质量保证将来标准和过程；根据过去的经验和教训制订正式的方法；象软件工具和合同软件一样的高质量输入。

　　* 确保尽早发现错误并纠正，错误隐蔽得越久，修正错误花得代价就越大。因此，质量控制必须在开发生命周期重的每一个阶段都要重视，如需求分析、设计、文档和代码。这些都隶属于所有的回顾方法，如检查、预排和技术回顾。

　　* 消除引起错误的引导因素，还没有找到错误的诱因就纠正错误是不巧党的。通过排除错误的诱因你就达到了改良过程的目的（回忆连续改良过程是全面质量管理TQC原则中用于软件质量的另一个关键原则）。

　　* 运用独立的按照标准和过程来的质量审核工作方式，通常有两种方法用于检查项目活动是否按照预定的标准和过程进行的，即SEI和SPR。

　　质量因素和风险

　 　我们已经讨论了质量，接下来的问题就是软件质量，或程序的质量，在软件开发项目中要讨论的风险因素。在《软件风险的评估和控制》一书中，Jones 描述了他在软件开发中的评估经验。运用软件生产力研究(SPR，Software Productivity Research)和软件工程技术（SEI，Software Engineering Institute）方法来回顾几百个企业的项目，这些项目产生的软件可以分为六类：

　　* 管理信息系统：财务和管理系统；

　　* 象操作系统、通讯软件或其他物理设备控制软件等系统软件；

　　* 商务开发项目，如给最终用户出租/出售产品等；

　　* 军事软件项目；

　　* 合同/采购软件项目（民间），一些零散的用于职员和雇主的客户端软件；

　　* 最终用户软件项目，即一些给特定的用户开发的软件。

　　这些程序中有超过100多个的风险因素。少数项目有超过15个风险因素，但大多数是6个因素影响。分析这些项目中的风险模式，结论是它们不都是所有软件中的共同因素。这儿列出了几个在样本程序中出现最多的风险因素。

　　MIS：

　　* 缓慢的用户需求分析（80%）

　　* 过大的时间进度压力（65%）

　　* 低质量（60%）

　　* 严重超成本（55%）

　　* 不充分的配置控制（50%）

　 　低质量的软件被定义为根本不工作，或是重复出现操作失败的现象。Jones定义低质量的软件是，用户报告中每日历年、每个功能点出现超过0.5个错误。 MIS系统低质量表现在两个方面：(1)不确定的错误出现，如偶然或非专业的使用检查或运行测试时出现错误；（2）不充分的错误预防，如使用象联合应用设 计（JAD）或信息工程(IE)的标准技术失败，一些错误可以产生项目的说明。

　　系统软件风险：

　　* 长期的计划（70%）

　　* 不充分的成本估计（65%）

　　* 过多的文档工作（60%）

　　* 错误的模块（50%）

　　* 项目取消（35%）

　 　过多的文档工作并没有严格的规律，但是可以从以下几点来判断是否是“过多”：（1）超过50种分散类型的文档；（2）文档费用接近或超过了整个项目费用 的 50%；（3）每个功能点有超过2000词的描述。系统软件的文档在数量级上仅次于军事软件，太多的文档对工作来讲是多余的。(注意，过多的文档会引起额 外的问题，目前，还没有出版相关的作品说明怎样数量、卷、结构或什么样的文档风格对于软件项目来讲是合适的。)

　　商业软件风险

　　* 不充分的用户文档（70%）

　　* 低用户满意度（55%）

　　* 太多的市场营销时间（50%）

　　* 有害的竞争活动（45%）

　　* 诉讼费用（40%）

这个问题吧，问的非常好，应该是大家都比较关心的问题。当年我也一直未这个问题很困惑。

　　我想在回答这个问题之前，先搞清楚什么是协议，为什么要选择协议。这就需要我们对通信机理有一些的了解。

　　首先，什么是协议？

　　协议无非就是一个约定，关于数据包发送的格式的约定，就是说如果大家都这样发送，那么通信就能够成功，如果大家都各按各的来，那么就没办法进行通信了。

　　那么接下来就是LR录制时的工作原 理了，LR的录制和WR不一样，它不关心你的对象识别什么的，不关心你的什么窗口之类的，LR有一个Agent进程，来专门监控客户端和服务器之间的通 信，然后用自己的函数进行录制。所以说，LR录制的时候关心的是通信，是客户端和服务器之间的数据包。说到这里，大家就比较清楚了，为什么有的时候不能录 制呢？因为，协议不认识阿，导致LR截获的数据包不能解析，所以录制下来是空的。

　　到这里我们再来看，那我们怎么样选择协议呢？当然原则就是说，你数据包的通信协议能被LR识别。

　 　过去流行的一种说法是，只要B/s结构的都是选择http协议，如果不是b/s那么肯定是socket，其实这种说法是比较肤浅或者比较片面的，我觉得 要真正理解这个问题，必须搞清楚你所测系统的数据流采用的什么协议包装的。这个我个人觉得，最好是能去向开发人员多了解，多学习。（说到这里，我想顺便建议一点：测试人 员向开发人员学习是个好习惯，多学一点底层的东西，或者对程序架构，数据流向，内部结构分析多了解一点，对自己的测试很有帮助，对自己的成长也是有帮助 的），另外，个人觉得，作为一个测试人员需要多了解一些网络方面的专业知识，最好学习一些网络分析工具譬如说Sniffer等，这对测试很有帮助。

　　说了这么多，似乎跑题了？还是回到正题，如何选择协议。

　　我下面给大家推荐一些建议值，是我在某本测试专业书籍上看到了，给大家贴上来，仅供参考。我还是说，具体问题具体分析，选择协议不是一个教条的事情，而是需要研究探索并尝试。

　　协议选择参考：

　　 应用类型      协议选择

　　1. Web网站       HTTP/HTML

　　2. FTP服务器     FTP

　　3. 邮件服务器    IMAP，POP3，SMTP

　　4.  C/S （第一种）客户端以ADO，OLEDB方法连接后台数据库   MS SQL Server，Oracle，Sybase，DB2，Infrmix

　　 　 C/S  （第二种）客户端以ODBC方法连接后台数据库  ODBC

　　 　 C/S  （第三种）没有后台数据库   Socket

　　5. ERP系统    SAP Peoplesoft

　　6.分布式组件   COM/DACOM  EJB

　　7.无线应用     WAP  PALM

　　总之，只有充分了解被测系统的应用类型和技术架构，才能做出正确的选择。

识别进度计划所有者

　　识别所有者或负责开发所有或部分项目进度计划的个人，对于确保开发出好的进度计划是必要的。推荐采用WBS或者组织的分解结构作为进度开发的基础，因为WBS指定范围，组织分解结构（ＯＢＳ）指定交付的功能区。

　　决定任务和里程碑

　　对于每一个最低级别的WBS元素，识别任务和里程碑对应交付的元素。可交付物通常设置为里程碑，产生可交付物的活动被称为任务。里程碑是一个时间点，被用于管理检查点来测量成果。

　　排序工作活动

　　在确定了交付产品的任物和里程碑之后，他们应该被逻辑的排序，来反映将被执行的工作方式。排序建立了任物和里程碑之间的依赖，并被用于计算交付产品的的进度。

　　任务历时评估

　　任务的历时评估是项目计划中最具挑战的部分，他也是后续成本估计的关键。这是一个不断细化的过程，贯穿于计划过程，因为它直接受人员安排和成本估算活动影响。

　　整合任务计划

　　一旦任务和里程碑被识别，排序，并且有了计划的历时评估，对每一个交付的产品就有了进度计划。没有整合，每一部分的进度是独立的，并且因此不能描述与整个项目相关的时间问题。

　　审查批准进度计划

　　一个较大和复杂的进度计划需要从多个人那里获得输入，没有人拥有项目的每一个方面的所有影响进度计划因素的所有的知识，因此团队应该执行进度计划的审查，来发现问题，或完善该进度计划。

　　测试的主要评测方法包括覆盖和质量。

　　测试覆盖是对测试完全程度的评测，它建立在测试覆盖基础上，测试覆盖是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。

　　质量是对测试对象（系统或测试的应用程序）的可靠性、稳定性以及性能的评测。质量建立在对测试结果的评估和对测试过程中确定的变更请求（缺陷）的分析的基础上

　　一、覆盖评测

　　覆 盖指标提供了“测试的完全程度如何？”这一问题的答案。最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖。简而言之，测试覆盖是就需求（基于需 求的）或代码的设计/实施标准（基于代码的）而言的完全程度的任意评测，如用例的核实（基于需求的）或所有代码行的执行（基于代码的）。

　　系统的测试活动建立在至少一个测试覆盖策略基础上。覆盖策略陈述测试的一般目的，指导测试用例的设计。覆盖策略的陈述可以简单到只说明核实所有性能。

　　如果需求已经完全分类，则基于需求的覆盖策略可能足以生成测试完全程度的可计量评测。例如，如果已经确定了所有性能测试需求，则可以引用测试结果来得到评测，如已经核实了 75% 的性能测试需求。

　　如果应用基于代码的覆盖，则测试策略是根据测试已经执行的源代码的多少来表示的。这种测试覆盖策略类型对于安全至上的系统来说非常重要。

　　两种评测都可以手工得到（公式如下所示）或通过测试自动化工具计算得到

　　a）基于需求的测试覆盖

　　基于需求的测试覆盖在测试生命周期中要评测多次，并在测试生命周期的里程碑处提供测试覆盖的标识（如已计划的、已实施的、已执行的和成功的测试覆盖）。

　　测试覆盖通过以下公式计算：

　　测试覆盖 = T(p,i,x,s) / RfT

　　其中：

　　T 是用测试过程或测试用例表示的测试 (Test) 数（已计划的、已实施的或成功的）。

　　RfT 是测试需求 (Requirement for Test) 的总数。

　　在制定测试计划活动中，将计算测试覆盖以决定已计划的测试覆盖，其计算方法如下：

　　测试覆盖（已计划的） = Tp / RfT

　　其中：

　　Tp 是用测试过程或测试用例表示的已计划测试 (Test) 数。

　　RfT 是测试需求 (Requirement for Test) 的总数。

　　在实施测试活动中，由于测试过程正在实施中（按照测试脚本），在计算测试覆盖时使用以下公式：

　　测试覆盖（已执行的） = Ti / RfT

　　其中：

　　Tx 是用测试过程或测试用例表示的已执行的测试 (Test) 数。

　　RfT 是测试需求 (Requirement for Test) 的总数。

　　在执行测试活动中，使用两个测试覆盖评测，一个确定通过执行测试获得的测试覆盖，另一个确定成功的测试覆盖（即执行时未出现失败的测试，如没有出现缺陷或意外结果的测试）。

　　这些覆盖评测通过以下公式计算：

　　测试覆盖（已执行的） = Tx / RfT

　　其中：

　　Tx 是用测试过程或测试用例表示的已执行的测试 (Test) 数。

　　RfT 是测试需求 (Requirement for Test) 的总数。

　　成功的测试覆盖（已执行的） = Ts / RfT

　　其中：

　　Ts 是用完全成功、没有缺陷的测试过程或测试用例表示的已执行测试 (Test) 数。

　　RfT 是测试需求 (Requirement for Test) 的总数。

　　如将以上比率转换为百分数，则以下基于需求的测试覆盖的陈述成立：

　　x% 的测试用例（上述公式中的 T(p,i,x,s)）已经覆盖，成功率为 y%

　　这一关于测试覆盖的陈述是有意义的，可以将其与已定义的成功标准进行对比。如果不符合该标准，则此陈述将成为预测剩余测试工作量的基础

　　b）基于代码的测试覆盖

　　基于代码的测试覆盖评测测试过程中已经执行的代码的多少，与之相对的是要执行的剩余代码的多少。代码覆盖可以建立在控制流（语句、分支或路径）或数据流的基础上。控制流覆盖的目的是测试代码行、分支条件、代码中的路径或软件控制流的其他元素。数据流覆盖的目的是通过软件操作测试数据状态是否有效，例如，数据元素在使用之前是否已作定义。

　　基于代码的测试覆盖通过以下公式计算：

　　测试覆盖 = Ie / TIic

　　其中：

　　Ie 是用代码语句、代码分支、代码路径、数据状态判定点或数据元素名表示的已执行项目数。

　　TIic (Total number of Items in the code) 是代码中的项目总数。

　　如将该比率转换为百分数，则以下基于代码的测试覆盖的陈述成立：

　　x% 的测试用例（上述公式中的 I）已经覆盖，成功率为 y%

　　这一关于测试覆盖的陈述是有意义的，可以将其与已定义的成功标准进行对比。如果不符合该标准，则此陈述将成为预测剩余测试工作量的基础

　　二、质量评测

　　测试覆盖的评估提供对测试完全程度的评测，在测试过程中已发现缺陷的评估提供了最佳的软件质量指标。因为质量是软件与需求相符程度的指标，所以在这种环境中，缺陷被标识为一种更改请求，该更改请求中的测试对象与需求不符。

　　缺陷评估可能建立在各种方法上，这些方法种类繁多，从简单的缺陷计数到严格的统计建模不一而足。

　　严 格的评估假定测试过程中缺陷达到的比率或发现的比率。常用模型假定该比率符合泊松分布。则有关缺陷率的实际数据可以适用于这一模型。生成的评估将评估当前 软件的可靠性，并且预测继续测试并排除缺陷时可靠性如何增长。该评估被描述为软件可靠性增长建模，这是一个活跃的研究领域。由于该类型的评估缺乏工具支 持，所以应该慎重平衡成本与其增加价值。

　　缺陷分析就是分析缺陷在与缺陷关联关系的一个或多个参数值上的分布。缺陷分析提供了一个软件可靠性指标。

　　对于缺陷分析，常用的主要缺陷参数有四个：

　　状态：缺陷的当前状态（打开的、正在修复或关闭的等）。

　　优先级：必须处理和解决缺陷的相对重要性。

　　严重性：缺陷的相关影响。对最终用户、组织或第三方的影响等等。

　　起源：导致缺陷的起源故障及其位置，或排除该缺陷需要修复的构件。

　　可以将缺陷计数作为时间的函数来报告，即创建缺陷趋势图或报告；也可以将缺陷计数作为一个或多个缺陷参数的函数来报告，如作为缺陷密度报告中采用的严重性或状态参数的函数。这些分析类型分别为揭示软件可靠性的缺陷趋势或缺陷分布提供了判断依据。

　　例如，预期缺陷发现率将随着测试进度和修复进度而最终减少。可以设定一个阈值，在缺陷发现率低于该阈值时才能部署软件。也可根据执行模型中的起源报告缺陷计数，以允许检测“较差的模块”、“热点”或需要再三修复的软件部分，从而指示一些更基本的设计缺陷。

　　这种分析中包含的缺陷必须是已确认的缺陷。不是所有已报告的缺陷都报告实际的缺陷，这是因为某些缺陷可能是扩展请求，超出了项目的规模，或描述的是已报告的缺陷。然而，需要查看并分析一下，为什么许多报告的缺陷不是重复的缺陷就是未经确认的缺陷，这样做是有价值的

　　三、缺陷报告

　　Rational Unified Process 以三类形式的报告提供缺陷评估：

　　缺陷分布（密度）报告允许将缺陷计数作为一个或多个缺陷参数的函数来显示。

　　缺陷龄期报告是一种特殊类型的缺陷分布报告。 缺陷龄期报告显示缺陷处于特定状态下的时间长短，如“提出的”。在龄期类别中，缺陷还可以按其他属性分类，如“拥有者”。

　　缺陷趋势报告按状态（新的、已打开的或关闭的）将缺陷计数作为时间的函数显示。趋势报告可以是累计的，也可以是非累计的。

　　测试结果和进度报告显示对测试的应用程序进行若干次迭代和测试生命周期后的测试过程执行结果。

　　许多此类报告对于评估软件质量具有很高的价值。一般测试标准中包括有关特定类别（如严重性级别）中打开的缺陷数的陈述。通过缺陷分布评估可以轻松地核对该标准。对测试需求进行过滤或分类，该评估可以侧重于不同的需求集。

　　要有效生成此类报告，一般需要工具支持

　　a）缺陷密度报告

　　缺陷状态与优先级

　　应该给定所有缺陷的优先级，通常可行的做法是设定四种优先级中的一种：

　　立即解决

　　高优先级

　　正常排队

　　低优先级

　　一个成功测试的标准可以表示为缺陷在上述优先级上所应体现的分布方式。例如，对于一个成功的测试标准来说，可能不存在优先级为 1 的打开的缺陷，而且优先级为 2 的打开的缺陷要少于 5 个

　　缺陷状态与严重性

　　缺陷严重性报告显示每种严重性级别的缺陷个数，例如致命错误、未执行主要功能、次要错误等严重性级别。

　　缺陷状态与在实施模型中的位置

　　缺陷起源报告显示缺陷在实施模型元素上的分布情况

　　b)缺陷龄期报告

　　缺陷龄期分析提供了有关测试有效性和缺陷排除活动的良好反馈。例如，如果大部分龄期较长的、未解决的缺陷处于有待确认的状态，则可能表明没有充足的资源应用于再次测试工作

　　c)缺陷趋势报告

　　趋势报告确定缺陷率并提供了一个出色的测试状态视图。在测试生命周期中，缺陷趋势遵循着一种比较好预测的模式。在生命周期的初期，缺陷率增长很快。在达到顶峰后，就随时间以较慢的速率下降

　　四、性能评测

　　评估测试对象的性能行为时，可以使用多种评测，这些评测侧重于获取与行为相关的数据，如响应时间、计时配置文件、执行流、操作可靠性和限制。这些评测主要在评估测试活动中进行评估，但是也可以在执行测试活动中使用性能评测评估测试进度和状态。

　　主要的性能评测包括：

　　动态监测 - 在测试执行过程中，实时获取并显示正在执行的各测试脚本的状态。

　　响应时间/吞吐量 - 测试对象针对特定主角和/或用例的响应时间或吞吐量的评测。

　　百分位报告 - 数据已收集值的百分位评测/计算。

　　比较报告 - 代表不同测试执行情况的两个（或多个）数据集之间的差异或趋势。

　　追踪报告 -主角（测试脚本）和测试对象之间的消息/会话详细信息

　　a）动态监测

　　动态监测通常以柱状图或曲线图的形式提供实时显示/报告。该报告用于在测试执行过程中，通过显示当前的情况、状态以及测试脚本正在执行的进度来监测或评估性能测试执行情况

　　b）响应时间/吞吐量报告

　　响应时间/吞吐量报告评测并计算与时间和/或吞吐量（处理的事务数）相关的性能行为。这些报告通常用曲线图显示，响应时间（或事务数）在“y”轴上，而事件数在“x”轴上

　　除了显示实际的性能行为外，它在计算并显示统计信息方面也很实用，如显示数据值的平均偏差和标准偏差

　　c）百分位报告

　　百分位报告通过显示已收集数据类型的全体百分位值，提供了另一种性能统计计算方法

　　d）比较报告

　　比较不同性能测试的结果，以评估测试执行过程之间所作的变更对性能行为的影响，这种做法是非常必要的。比较报告应该用于显示两个数据集（分别代表不同的测试执行）之间的差异或多个测试执行之间的趋势

目录：

　　一、术语session

　　二、HTTP协议与状态保持

　　三、理解cookie机制

　　四、理解session机制

　　五、理解javax.servlet.http.HttpSession

　　六、HttpSession常见问题

　　七、跨应用程序的session共享

　　八、总结

　　

　　一、术语session

　　在我的经验里，session这个词被滥用的程度大概仅次于transaction，更加有趣的是transaction与session在某些语境下的含义是相同的。

　　session， 中文经常翻译为会话，其本来的含义是指有始有终的一系列动作/消息，比如打电话时从拿起电话拨号到挂断电话这中间的一系列过程可以称之为一个 session。有时候我们可以看到这样的话“在一个浏览器会话期间，...”，这里的会话一词用的就是其本义，是指从一个浏览器窗口打开到关闭这个期间 ①。最混乱的是“用户（客户端）在一次会话期间”这样一句话，它可能指用户的一系列动作（一般情况下是同某个具体目的相关的一系列动作，比如从登录到选购 商品到结账登出这样一个网上购物的过程，有时候也被称为一个transaction），然而有时候也可能仅仅是指一次连接，也有可能是指含义①，其中的差 别只能靠上下文来推断②。

　　然 而当session一词与网络协议相关联时，它又往往隐含了“面向连接”和/或“保持状态”这样两个含义， “面向连接”指的是在通信双方在通信之前要先建立一个通信的渠道，比如打电话，直到对方接了电话通信才能开始，与此相对的是写信，在你把信发出去的时候你 并不能确认对方的地址是否正确，通信渠道不一定能建立，但对发信人来说，通信已经开始了。“保持状态”则是指通信的一方能够把一系列的消息关联起来，使得 消息之间可以互相依赖，比如一个服务员能够认出再次光临的老顾客并且记得上次这个顾客还欠店里一块钱。这一类的例子有“一个TCP session”或者 “一个POP3 session”③。

　　而到了web服 务器蓬勃发展的时代，session在web开发语境下的语义又有了新的扩展，它的含义是指一类用来在客户端与服务器之间保持状态的解决方案④。有时候 session也用来指这种解决方案的存储结构，如“把xxx保存在session 里”⑤。由于各种用于web开发的语言在一定程度上都提供了对这种解决方案的支持，所以在某种特定语言的语境下，session也被用来指代该语言的解决 方案，比如经常把Java里提供的javax.servlet.http.HttpSession简称为session⑥。

　　鉴于这种混乱已不可改变，本文中session一词的运用也会根据上下文有不同的含义，请大家注意分辨。

　　在本文中，使用中文“浏览器会话期间”来表达含义①，使用“session机制”来表达含义④，使用“session”表达含义⑤，使用具体的“HttpSession”来表达含义⑥

　　二、HTTP协议与状态保持

　　HTTP 协议本身是无状态的，这与HTTP协议本来的目的是相符的，客户端只需要简单的向服务器请求下载某些文件，无论是客户端还是服务器都没有必要纪录彼此过去 的行为，每一次请求之间都是独立的，好比一个顾客和一个自动售货机或者一个普通的（非会员制）大卖场之间的关系一样。

　　然 而聪明（或者贪心？）的人们很快发现如果能够提供一些按需生成的动态信息会使web变得更加有用，就像给有线电视加上点播功能一样。这种需求一方面迫使 HTML逐步添加了表单、脚本、DOM等客户端行为，另一方面在服务器端则出现了CGI规范以响应客户端的动态请求，作为传输载体的HTTP协议也添加了 文件上载、 cookie这些特性。其中cookie的作用就是为了解决HTTP协议无状态的缺陷所作出的努力。至于后来出现的session机制则是又一种在客户端 与服务器之间保持状态的解决方案。

　　让我们用几个例子来描述一下cookie和session机制之间的区别与联系。笔者曾经常去的一家咖啡店有喝5杯咖啡免费赠一杯咖啡的优惠，然而一次性消费5杯咖啡的机会微乎其微，这时就需要某种方式来纪录某位顾客的消费数量。想象一下其实也无外乎下面的几种方案：

　　1、该店的店员很厉害，能记住每位顾客的消费数量，只要顾客一走进咖啡店，店员就知道该怎么对待了。这种做法就是协议本身支持状态。

　　2、发给顾客一张卡片，上面记录着消费的数量，一般还有个有效期限。每次消费时，如果顾客出示这张卡片，则此次消费就会与以前或以后的消费相联系起来。这种做法就是在客户端保持状态。

　　3、发给顾客一张会员卡，除了卡号之外什么信息也不纪录，每次消费时，如果顾客出示该卡片，则店员在店里的纪录本上找到这个卡号对应的纪录添加一些消费信息。这种做法就是在服务器端保持状态。

　　由 于HTTP协议是无状态的，而出于种种考虑也不希望使之成为有状态的，因此，后面两种方案就成为现实的选择。具体来说cookie机制采用的是在客户端保 持状态的方案，而session机制采用的是在服务器端保持状态的方案。同时我们也看到，由于采用服务器端保持状态的方案在客户端也需要保存一个标识，所 以session机制可能需要借助于cookie机制来达到保存标识的目的，但实际上它还有其他选择。

　　三、理解cookie机制 

　　cookie机制的基本原理就如上面的例子一样简单，但是还有几个问题需要解决：“会员卡”如何分发；“会员卡”的内容；以及客户如何使用“会员卡”。

　　正统的cookie分发是通过扩展HTTP协议来实现的，服务器通过在HTTP的响应头中加上一行特殊的指示以提示浏览器按照指示生成相应的cookie。然而纯粹的客户端脚本如Javascrīpt或者VBscrīpt也可以生成cookie。

　　而cookie 的使用是由浏览器按照一定的原则在后台自动发送给服务器的。浏览器检查所有存储的cookie，如果某个cookie所声明的作用范围大于等于将要请求的 资源所在的位置，则把该cookie附在请求资源的HTTP请求头上发送给服务器。意思是麦当劳的会员卡只能在麦当劳的店里出示，如果某家分店还发行了自 己的会员卡，那么进这家店的时候除了要出示麦当劳的会员卡，还要出示这家店的会员卡。

　　cookie的内容主要包括：名字，值，过期时间，路径和域。

　　其中域可以指定某一个域比如.google.com，相当于总店招牌，比如宝洁公司，也可以指定一个域下的具体某台机器比如www.google.com或者froogle.google.com，可以用飘柔来做比。

　　路径就是跟在域名后面的URL路径，比如/或者/foo等等，可以用某飘柔专柜做比。

　　路径与域合在一起就构成了cookie的作用范围。

　　如 果不设置过期时间，则表示这个cookie的生命期为浏览器会话期间，只要关闭浏览器窗口，cookie就消失了。这种生命期为浏览器会话期的 cookie被称为会话cookie。会话cookie一般不存储在硬盘上而是保存在内存里，当然这种行为并不是规范规定的。如果设置了过期时间，浏览器 就会把cookie保存到硬盘上，关闭后再次打开浏览器，这些cookie仍然有效直到超过设定的过期时间。

　　存 储在硬盘上的cookie 可以在不同的浏览器进程间共享，比如两个IE窗口。而对于保存在内存里的cookie，不同的浏览器有不同的处理方式。对于IE，在一个打开的窗口上按 Ctrl-N（或者从文件菜单）打开的窗口可以与原窗口共享，而使用其他方式新开的IE进程则不能共享已经打开的窗口的内存cookie；对于 Mozilla Firefox0.8，所有的进程和标签页都可以共享同样的cookie。一般来说是用javascrīpt的window.open打开的窗口会与原窗 口共享内存cookie。浏览器对于会话cookie的这种只认cookie不认人的处理方式经常给采用session机制的web应用程序开发者造成很 大的困扰。

　　下面就是一个goolge设置cookie的响应头的例子

　　HTTP/1.1 302 Found

　　Location: http://www.google.com/intl/zh-CN/

　　Set-Cookie: PREF=ID=0565f77e132de138:NW=1:TM=1098082649:LM=1098082649:S=KaeaCFPo49RiA_d8; expires=Sun,

　　17-Jan-2038 19:14:07 GMT; path=/; domain=.google.com

　　Content-Type: text/html

　　这是使用HTTPLook这个HTTP Sniffer软件来俘获的HTTP通讯纪录的一部分

　　浏览器在再次访问goolge的资源时自动向外发送cookie

　　使用Firefox可以很容易的观察现有的cookie的值

　　使用HTTPLook配合Firefox可以很容易的理解cookie的工作原理。

　　IE也可以设置在接受cookie前询问

　　这是一个询问接受cookie的对话框。

　　四、理解session机制

　　session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息。

　　当 程序需要为某个客户端的请求创建一个session的时候，服务器首先检查这个客户端的请求里是否已包含了一个session标识 - 称为 session id，如果已包含一个session id则说明以前已经为此客户端创建过session，服务器就按照session id把这个 session检索出来使用（如果检索不到，可能会新建一个），如果客户端请求不包含session id，则为此客户端创建一个session并且生成一个与此session相关联的session id，session id的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个 session id将被在本次响应中返回给客户端保存。

　　保 存这个session id的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发挥给服务器。一般这个cookie的名字都是类似于 SEEESIONID，而。比如weblogic对于web应用程序生成的cookie，JSESSIONID= ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764，它的名字就是 JSESSIONID。

　　由于cookie可以被人为的禁止，必须有其他机制以便在cookie被禁止时仍然能够把session id传递回服务器。经常被使用的一种技术叫 做URL重写，就是把session id直接附加在URL路径的后面，附加方式也有两种，一种是作为URL路径的附加信息，表现形式为http://..... /xxx;jsessionid= ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764

　　另一种是作为查询字符串附加在URL后面，表现形式为http://...../xxx?jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764

　　这两种方式对于用户来说是没有区别的，只是服务器在解析的时候处理的方式不同，采用第一种方式也有利于把session id的信息和正常程序参数区分开来。

　　为了在整个交互过程中始终保持状态，就必须在每个客户端可能请求的路径后面都包含这个session id。

　　另一种技术叫做表单隐藏字段。就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把session id传递回服务器。比如下面的表单

　　<form name="testform" action="/xxx">

　　<input type="text">

　　</form>

　　在被传递给客户端之前将被改写成

　　<form name="testform" action="/xxx">

　　<input type="hidden" name="jsessionid" value="ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764">

　　<input type="text">

　　</form>

　　这种技术现在已较少应用，笔者接触过的很古老的iPlanet6(SunONE应用服务器的前身)就使用了这种技术。

　　实际上这种技术可以简单的用对action应用URL重写来代替。

　　在 谈论session机制的时候，常常听到这样一种误解“只要关闭浏览器，session就消失了”。其实可以想象一下会员卡的例子，除非顾客主动对店家提 出销卡，否则店家绝对不会轻易删除顾客的资料。对session来说也是一样的，除非程序通知服务器删除一个session，否则服务器会一直保留，程序 一般都是在用户做log off的时候发个指令去删除session。然而浏览器从来不会主动在关闭之前通知服务器它将要关闭，因此服务器根本不会有机会知道浏览器已经关闭，之所 以会有这种错觉，是大部分session机制都使用会话cookie来保存session id，而关闭浏览器后这个 session id就消失了，再次连接服务器时也就无法找到原来的session。如果服务器设置的cookie被保存到硬盘上，或者使用某种手段改写浏览器发出的 HTTP请求头，把原来的session id发送给服务器，则再次打开浏览器仍然能够找到原来的session。

　　恰恰是由于关闭浏览器不会导致session被删除，迫使服务器为seesion设置了一个失效时间，当距离客户端上一次使用session的时间超过这个失效时间时，服务器就可以认为客户端已经停止了活动，才会把session删除以节省存储空间。

　　五、理解javax.servlet.http.HttpSession

　　HttpSession是Java平台对session机制的实现规范，因为它仅仅是个接口，具体到每个web应用服务器的提供商，除了对规范支持之外，仍然会有一些规范里没有规定的细微差异。这里我们以BEA的Weblogic Server8.1作为例子来演示。

　　首 先，Weblogic Server提供了一系列的参数来控制它的HttpSession的实现，包括使用cookie的开关选项，使用URL重写的开关选项，session持 久化的设置，session失效时间的设置，以及针对cookie的各种设置，比如设置cookie的名字、路径、域， cookie的生存时间等。

　　一 般情况下，session都是存储在内存里，当服务器进程被停止或者重启的时候，内存里的session也会被清空，如果设置了session的持久化特 性，服务器就会把session保存到硬盘上，当服务器进程重新启动或这些信息将能够被再次使用， Weblogic Server支持的持久性方式包括文件、数据库、客户端cookie保存和复制。

　　复制严格说来不算持久化保存，因为session实际上还是保存在内存里，不过同样的信息被复制到各个cluster内的服务器进程中，这样即使某个服务器进程停止工作也仍然可以从其他进程中取得session。

　　cookie生存时间的设置则会影响浏览器生成的cookie是否是一个会话cookie。默认是使用会话cookie。有兴趣的可以用它来试验我们在第四节里提到的那个误解。

　　cookie的路径对于web应用程序来说是一个非常重要的选项，Weblogic Server对这个选项的默认处理方式使得它与其他服务器有明显的区别。后面我们会专题讨论。

　　关于session的设置参考[5] http://e-docs.bea.com/wls/docs70/webapp/weblogic_xml.html#1036869

　　六、HttpSession常见问题

　　（在本小节中session的含义为⑤和⑥的混合）

　　1、session在何时被创建

　　一 个常见的误解是以为session在有客户端访问时就被创建，然而事实是直到某server端程序调用 HttpServletRequest.getSession(true)这样的语句时才被创建，注意如果JSP没有显示的使用 <% @page session="false"%> 关闭session，则JSP文件在编译成Servlet时将会自动加上这样一条语句 HttpSession session = HttpServletRequest.getSession(true);这也是JSP中隐含的 session对象的来历。

　　由于session会消耗内存资源，因此，如果不打算使用session，应该在所有的JSP中关闭它。

　　2、session何时被删除

　　综合前面的讨论，session在下列情况下被删除a.程序调用HttpSession.invalidate();或b.距离上一次收到客户端发送的session id时间间隔超过了session的超时设置;或c.服务器进程被停止（非持久session）

　　3、如何做到在浏览器关闭时删除session

　　严格的讲，做不到这一点。可以做一点努力的办法是在所有的客户端页面里使用javascrīpt代码window.oncolose来监视浏览器的关闭动作，然后向服务器发送一个请求来删除session。但是对于浏览器崩溃或者强行杀死进程这些非常规手段仍然无能为力。

　　4、有个HttpSessionListener是怎么回事

　　你 可以创建这样的listener去监控session的创建和销毁事件，使得在发生这样的事件时你可以做一些相应的工作。注意是session的创建和销 毁动作触发listener，而不是相反。类似的与HttpSession有关的listener还有 HttpSessionBindingListener，HttpSessionActivationListener和 HttpSessionAttributeListener。

　　5、存放在session中的对象必须是可序列化的吗

　　不 是必需的。要求对象可序列化只是为了session能够在集群中被复制或者能够持久保存或者在必要时server能够暂时把session交换出内存。在 Weblogic Server的session中放置一个不可序列化的对象在控制台上会收到一个警告。我所用过的某个iPlanet版本如果 session中有不可序列化的对象，在session销毁时会有一个Exception，很奇怪。

　　6、如何才能正确的应付客户端禁止cookie的可能性

　　对所有的URL使用URL重写，包括超链接，form的action，和重定向的URL，具体做法参见[6]

　　http://e-docs.bea.com/wls/docs70/webapp/sessions.html#100770

　　7、开两个浏览器窗口访问应用程序会使用同一个session还是不同的session

　　参见第三小节对cookie的讨论，对session来说是只认id不认人，因此不同的浏览器，不同的窗口打开方式以及不同的cookie存储方式都会对这个问题的答案有影响。

　　8、如何防止用户打开两个浏览器窗口操作导致的session混乱

　　这 个问题与防止表单多次提交是类似的，可以通过设置客户端的令牌来解决。就是在服务器每次生成一个不同的id返回给客户端，同时保存在session里，客 户端提交表单时必须把这个id也返回服务器，程序首先比较返回的id与保存在session里的值是否一致，如果不一致则说明本次操作已经被提交过了。可 以参看《J2EE核心模式》关于表示层模式的部分。需要注意的是对于使用javascrīpt window.open打开的窗口，一般不设置这个id，或者使用单独的id，以防主窗口无法操作，建议不要再window.open打开的窗口里做修改 操作，这样就可以不用设置。

查看(408) 评论(0) 收藏 分享 管理

有自己的网站或者博客吗？现在一个绝好的网络赚钱机会就摆在你面前。世界上最大的搜索引擎 —— Google 给你想要的一切。看到文字上面的广告了吗？这就是由Google Adsence提供的点击付费广告。

利用以网页内容定位的广告增加回头客的数量。

     您希望通过广告获得更多收入，但又不想向用户展示没有针对性的广告。 Google AdSense 解决了这一问题，它可以自动投放根据网站和网站内容逐页进行精确定位的文字广告和图片广告，这些广告非常协调，因此，读者会发现它们确实非常有用。

只需付出一点点努力，即可接触到数以千计的广告客户。

     与广告客户签约并维护与他们的合作关系需要专人进行。令人高兴的是，Google AdSense 能够为您完成这些工作。我们的广告客户规模各异，既有国际化企业，也有本地的小型公司，并且在分类上涵盖了从教育到旅游、从抵押贷款到庭院家具等等所有领 域。最有优势的一点是，启动之后基本上不需要对 AdSense 计划进行任何维护。

充分发挥贵网站的创收潜力。

    当您在网站上展示 Google 广告时，您就可以发掘您网站的最高收益潜力。 Google 将相关的CPC 和 CPM 广告放入同一竞价系统中相互竞争。该竞价立刻生效，并在结束时， AdSense 将自动展示最大收益的文字或图片广告于您的网页 -- 也给您创造最大收益。

内容发生变化时，广告也会变化。

      Google AdSense 技术并不是只停留在简单的关键字匹配或类别匹配上。无论贵网站的网页数量有多么巨大，或者内容有多么专业或宽泛，我们都会努力理解网站内容，然后自动投放 针对特定网页的相关广告。内容发生变化时， Google 广告也会跟着发生变化。并且，由于我们的广告还能够按国家 / 地区定位，所以全球性企业无需额外付出努力，即可针对不同地区展示不同的广告 。 *

捍卫您的企业规范也是我们的职责所在。

     我们致力于维护客户的企业规范。正是基于这一原因，Google AdSense 采取了以下保护措施：

         竞争性广告过滤器 。只需告知我们要拦截的网址，即可拦截竞争性广告或其他不想在自己网站展示的广告。
         广告审核 。广告需经过人工和自动化结合起来的审核过程，才会出现在您的网站上。这一审核过程要审查许多因素，包括广告质量以及是否适合所有受众。
         敏感内容过滤器 。有时，某些广告可能不适合一些网页。例如，Google 会自动过滤掉不适合在报道灾难性事件的新闻网页上展示的广告。
         选择自己的默认广告 。万一 Google 无法向您的网页投放具有针对性的广告时，我们还允许您展示您所选择的默认广告。这确保您最大限度地提高自己广告空间的使用效率。

对广告进行自定义以同自己的网站相配。

       完善网站外观花费了您大量时间，为此我们也希望 AdSense 能与贵网站相适宜。因此，我们提供了 200 多种颜色和 24 个预先设定的调色板（您可以利用简单的点击式颜色选择工具创建并保存自定义调色板）供您选择，从而通过自定义广告的外观来确保它们同贵网站完全相配。

借助于在线报告跟踪收入情况。

      加入 AdSense 计划后，您能够借助于可自定义的在线报告详细了解网页展示次数、点击次数以及点击率等信息，从而监控广告效果。您还可以快速、方便地跟踪特定广告格式、颜 色和网页的效果，并且洞察其中的发展趋势。借助于我们灵活的报告工具，您可以根据需要随意对网页进行组合，从而按照网址、域、广告类型和类别等查看结果， 了解收入情况。

当然，最有优势的一点是您可以随时检查收入情况。

启动过程既快速又简单。

    成为一名 Google AdSense 发布商非常简单。无论是内容广告还是搜索广告，都只需花费一点点时间进行在线申请。如果您获准加入，则只需登录到自己的帐户，复制一组 HTML 代码，然后将其粘贴到您现有的广告服务器或任意网页中 - 做完这些就可以了。您的网页将开始展示与相关的广告，收入也随之开始增加。

将 Google 搜索同 AdSense 相结合，由更多的网页获得收入。

     利人即利己 - 这是一条基本的商业定律。基于这一点，增加Google 搜索功能绝对是一个绝佳想法。
 
     在将 Google 搜索框加入贵网站后，您的访问者只需动动指尖，就能使用我们的搜索引擎。并且，将搜索功能与 AdSense 相结合，还可以借助于 Google 的客户群为自己增加利润。
         

搜索能够增加点击量。

       作为世界最大的搜索引擎，Google 为许多最常用的网站提供了搜索服务，包括 Amazon、AOL、AT&T Worldnet、EarthLink 以及New York Times。每天，我们都向数百万用户提供服务，这些用户明白，我们的“不收费”政策能够确保他们获得完全公平的结果。Google 搜索能够给用户带来更好的体验，因此，访问者会在贵网站中停留更多时间，访问频率也会提高。例如，AOL 利用 Google 搜索将搜索点击量提高了 33%，同时借助于搜索结果大幅度提高了客户满意度。

搜索结果页意味着更多收入。

    Google AdSense 将 Google 搜索技术与数以千计的关键字广告客户相结合，能够向搜索结果页投放有针对性的广告。人们发现这些广告非常有用，就会点击它们；只要他们点击广告，Google 就会向您付费。

这一计划简便易行，功能却非常强大。

对搜索页进行自定义。

      如果您希望尽快启动，则可以使用我们的标准 Google 搜索框和搜索结果。不过，您只需花费数分钟，即可完成对 Google 搜索框外观的自定义工作，以便使其同贵网站相配。您只需加入自己的徽标，并更改背景、标题、文本、网址以及其他内容的颜色，使搜索结果同自己网站相配即 可。有 200 多种颜色可供选择。

让您的访问者搜索 Web — 或搜索贵网站。

      利用 Google 搜索，访问者可以从贵网站搜索 Web。并且，如果我们已经抓取了贵网站（这很有可能），我们的 SiteSearch 功能还可以让访问者对您自己的网站进行搜索。而 SafeSearch 选项能够从搜索结果中排除带有成人内容的网页。

    
我们会为您托管搜索结果。

      Google 不仅提供搜索技术和广告，还对搜索结果页进行托管。您不需要付费聘请软件专家或技术专家在网站上增加搜索功能，也不需要付费请其他人进行托管。Google 的统管理员会致力于保证您的搜索功能一天 24 小时不间断地运转。

了解您的用户都在查询些什么。

       想知道您用户都在您网站上搜索些什么吗？热门搜索报告可以显示用户在 AdSense for search 搜索框中进行的 25 个最常见查询。利用该报告，您可以发掘更多应该增加到您网站的主题，或跟踪用户最想知道的信息。

过滤不希望出现的广告。

     Google 结合过滤技术、编辑人员与您的意见这三个因素，生成适合于您的一组严格的过滤条件，其中包括：

     审核 。我们使用人工和自动化相结合的程序审核整个 Google 联网内的广告，然后才会将其投放在发布商的网站上。这一审核过程要审查许多因素，包括广告质量以及是否适合所有受众。

    可自定义的过滤 。如果我们的某些合作伙伴同您存在排他性的关系，您可以过滤掉它们的竞争性广告，您还可以过滤掉其他不想展示的广告。

对结果进行在线跟踪。

    可以通过基于 Web 的帐户跟踪查询次数、点击次数、点击率以及您通过 AdSense 获得的收入，并且随时都可以方便地对帐户进行更新。

在线申请简便易行。

     在审核您的申请后，我们会通知您您是否有资格加入此计划。如果您获准加入，则只需登录到自己的帐户，将一组 HTML 代码复制并粘贴到自己的网页即可。这样，您就能开始提供搜索结果并投放有针对性的广告，并且 Google 会根据访问者对广告的点击次数向您付费。

测试人生，人生测试