如何制定完美的测试计划
“工欲善其事，必先利其器”。专业的测试必须以一个好的测试计划作为基础。尽管测试的每一个步骤都是独立的，但是必定要有一个起到框架结构作用的测试计划。测试的计划应该作为测试的起始步骤和重要环节。一个测试计划应包括：产品基本情况调研、测试需求 说明、测试策略和记录、测试资源配置、计划表、问题跟踪报告、测试计划的评审、结果等等。

　　 产品基本情况调研：

　　这部分应包括产品的一些基本情况介绍，例如：产品的运行平台和应用的领域，产品的特点和主要的功能模块，产品的特点等。对于大的测试项目，还要包括测试的目的和侧重点。

　　 具体的要点有：

　　 目的：重点描述如何使测试建立在客观的基础上，定义测试的策略，测试的配置，粗略的估计测试大致需要的周期和最终测试报告递交的时间。

　　 变更：说明有可能会导致测试计划变更的事件。包括 测试工具 改进了，测试的环境改变了，或者是添加了新的功能。

　　技术结构：可以借助画图，将要测试的软件划分成几个组成部分，规划成一个适用于测试的完整的系统，包括数据是如何存储的，如何传递的（数据流图），每一个部分的测试是要达到什么样的目的。每一个部分是怎么实现数据更新的。还有就是常规性的技术要求，比如运行平台、需要什么样的 数据库 等等。

　　 产品规格：就是制造商和产品版本号的说明。

　　 测试范围：简单的描述如何搭建测试平台以及测试的潜在的风险。

　　 项目信息：说明要测试的项目的相关资料，如：用户文档，产品描述，主要功能的举例说明。

　　 测试需求说明：

　　这一部分要列出所有要测试的功能项。凡是没有出现在这个清单里的功能项都排除在测试的范围之外。万一有一天你在一个没有测试的部分里发现了一个问题，你应该很高兴你有这个记录在案的文档，可以证明你测了什么没测什么。具体要点有：

　　功能的测试：理论上是测试是要覆盖所有的功能项，例如：在数据库中添加、编辑、删除记录等等，这会是一个浩大的工程，但是有利于测试的完整性。

　　 设计的测试：对于一些用户界面、菜单的结构还有窗体的设计是否合理等的测试。

　　 整体考虑：这部分测试需求要考虑到数据流从软件中的一个模块流到另一个模块的过程中的正确性。

　　 测试的策略和记录：

　　 这是整个测试计划的重点所在，要描述如何公正客观地开展测试，要考虑：模块、功能、整体、系统、版本、压力、 性能、配置和安装等各个因素的影响。要尽可能的考虑到细节，越详细越好，并制作测试记录文档的模板，为即将开始的测试做准备，测试记录重要包括的部分具体说明如下：

　　公正性声明：要对测试的公正性、遵照的标准做一个说明，证明测试是客观的，整体上，软件功能要满足需求，实现正确，和用户文档的描述保持一致。

　　 测试案例：描述测试案例是什么样的，采用了什么工具，工具的来源是什么，如何执行的，用了什么样的数据。测试的记录中要为将来的 回归测试 留有余地，当然，也要考虑同时安装的别的软件对正在测试的软件会造成的影响。

　　 特殊考虑：有的时候，针对一些外界环境的影响，要对软件进行一些特殊方面的测试。

　　 经验判断：对以往的测试中，经常出现的问题加以考虑。

　　 设想：采取一些发散性的思维，往往能帮助你找的测试的新途径。

　　 测试资源配置：

　　项目资源计划：制定一个项目资源计划，包含的是每一个阶段的任务、所需要的资源，当发生类似到了使用期限或者资源共享的事情的时候，要更新这个计划。

　　 计划表：

　　 测试的计划表可以做成一个多个项目通用的形式，根据大致的时间估计来制作，操作流程要以 软件测试 的常规周期作为参考，也可以是根据什么时候应该测试哪一个模块来制定。

　　 问题跟踪报告：

　　在测试的计划阶段，我们应该明确如何准备去做一个问题报告以及如何去界定一个问题的性质，问题报告要包括问题的发现者和修改者、问题发生的频率、用了什么样的测试案例测出该问题的，以及明确问题产生时的测试环境 。

　　 问题描述尽可能是定量的，分门别类的列举，问题有几种：

　　 1、严重问题：严重问题意味着功能不可用，或者是权限限制方面的失误等等，也可能是某个地方的改变造成了别的地方的问题。

　　 2、一般问题：功能没有按设计要求实现或者是一些界面交互的实现不正确。

　　 3、建议问题：功能运行得不象要求的那么快，或者不符合某些约定俗成的习惯，但不影响系统的性能，界面先是错误，格式不对，含义模糊混淆的提示信息等等。

　　 测试计划的评审：

　　又叫测试规范的评审，在测试真正实施开展之前必须要认真负责的检查一遍，获得整个测试部门人员的认同，包括部门的负责人的同意和签字。

　　 结果：

　　计划并不是到这里就结束了，在最后测试结果的评审中，必须要严格验证计划和实际的执行是不是有偏差，体现在最终报告的内容是否和测试的计划保持一致，然后，就可以开始着手制作下一个测试计划了。

软件测试用例的设计
一、测试用例是软件测试的核心

　　软件测试的重要性是毋庸置疑的。但如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。每个软件产品或软件开发项目都需要有一套优秀的测试方案和测试方法。

　　影响软件测试的因素很多，例如软件本身的复杂程度、开发人员（包括分析、设计、编程和测试的人员）的素质、测试方法和技术的运用等等。因为有些因素是客观存在的，无法避免。有些因素则是波动的、不稳定的，例如开发队伍是流动的，有经验的走了，新人不断补充进来；一个具体的人工作也受情绪等影响，等等。如何保障软件测试质量的稳定？有了测试用例，无论是谁来测试，参照测试用例实施，都能保障测试的质量。可以把人为因素的影响减少到最小。即便最初的测试用例考虑不周全，随着测试的进行和软件版本更新，也将日趋完善。

　　因此测试用例的设计和编制是软件测试活动中最重要的。测试用例是测试工作的指导，是软件测试的必须遵守的准则，更是软件测试质量稳定的根本保障。

　　二、什么叫测试用例

　　测试用例（Test Case）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略，内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

　　不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。笔者主要从事企业管理软件的测试。因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。

　　三、编写测试用例

　　着重介绍一些编写测试用例的具体做法。

　　1、测试用例文档

　　编写测试用例文档应有文档模板，须符合内部的规范要求。测试用例文档将受制于测试用例管理软件的约束。

　　软件产品或软件开发项目的测试用例一般以该产品的软件模块或子系统为单位，形成一个测试用例文档，但并不是绝对的。

　　测试用例文档由简介和测试用例两部分组成。简介部分编制了测试目的、测试范围、定义术语、参考文档、概述等。测试用例部分逐一列示各测试用例。每个具体测试用例都将包括下列详细信息：用例编号、用例名称、测试等级、入口准则、验证步骤、期望结果（含判断标准）、出口准则、注释等。以上内容涵盖了测试用例的基本元素：测试索引，测试环境，测试输入，测试操作，预期结果，评价标准。

　　2、测试用例的设置

　　我们早期的测试用例是按功能设置用例。后来引进了路径分析法，按路径设置用例。目前演变为按功能、路径混合模式设置用例。

　　按功能测试是最简捷的，按用例规约遍历测试每一功能。

　　对于复杂操作的程序模块，其各功能的实施是相互影响、紧密相关、环环相扣的，可以演变出数量繁多的变化。没有严密的逻辑分析，产生遗漏是在所难免。路径分析是一个很好的方法，其最大的优点是在于可以避免漏测试。

　　但路径分析法也有局限性。在一个非常简单字典维护模块就存在十余条路径。一个复杂的模块会有几十到上百条路径是不足为奇的。笔者以为这是路径分析比较合适的使用规模。若一个子系统有十余个或更多的模块，这些模块相互有关联。再采用路径分析法，其路径数量成几何级增长，达5位数或更多，就无法使用了。那么子系统模块间的测试路径或测试用例还是要靠传统方法来解决。这是按功能、路径混合模式设置用例的由来。

　　3、设计测试用例

　　测试用例可以分为基本事件、备选事件和异常事件。设计基本事件的用例，应该参照用例规约（或设计规格说明书），根据关联的功能、操作按路径分析法设计测试用例。而对孤立的功能则直接按功能设计测试用例。基本事件的测试用例应包含所有需要实现的需求功能，覆盖率达100%。

　　设计备选事件和异常事件的用例，则要复杂和困难得多。例如，字典的代码是唯一的，不允许重复。测试需要验证：字典新增程序中已存在有关字典代码的约束，若出现代码重复必须报错，并且报错文字正确。往往在设计编码阶段形成的文档对备选事件和异常事件分析描述不够详尽。而测试本身则要求验证全部非基本事件，并同时尽量发现其中的软件缺陷。

　　可以采用软件测试常用的基本方法：等价类划分法、边界值分析法、错误推测法、因果图法、逻辑覆盖法等设计测试用例。视软件的不同性质采用不同的方法。如何灵活运用各种基本方法来设计完整的测试用例，并最终实现暴露隐藏的缺陷，全凭测试设计人员的丰富经验和精心设计。

1、搭建独立的软件测试环境有利于重现开发环境无法重现的BUG。这样说也许会显得抽象，我们不妨举个简单的例子来说明：某个软件系统由模块A、B、C组成（对应开发人员A、B、 C）。起初开发人员比较偷懒，不想重新搭建独立的测试环境（特别是搭建过程比较复杂的情况下），而是让测试人员连到他们各自的开发机器上分别测试他们各自负责的模块。各自的模块功能很正常，但一旦整合作为一个系统向用户提供功能时，就不一定正常了，有可能在模块A录入的数据在模块B查询不到，或是模块间的接口有问题等。除此以外，还可能有其他因素妨碍开发环境重现BUG。总之，搭建一个与典型用户环境配置一致的测试环境是有效测试的重要前提。

2、搭建独立的测试环境便于开发人员并行地修复BUG。如果对开发环境进行测试，开发人员要修复BUG必须先重现BUG，然后修改相关代码，并进行程序调试。而在测试人员还未测试完系统前，开发人员是不能对程序进行修改、更新。只有等测试人员测试完后才能进行BUG修复（现实中也有这样的情况：测试员还未测试完开发人员就更新修复部份BUG的程序。这种做法比较危险，开发人员若修复得不好可能会导致程序无法运行，势必影响测试进度）。串行的工作方式也很耗费时间，甚至影响进度。正确的做法应该搭建独立的测试环境，测试人员提出BUG后开发人员在开发机上重现并修复，并验证修复后的效果，两种环境互不干扰。

3、搭建独立的测试环境可以验证安装软件的全过程。即进行安装测试，用以检查安装文件是否有错漏，软件在指定的操作系统下能否正常安装，各种配置项是否有错漏等。

4、搭建独立的测试环境可以避免环境被破坏导致测试无法进行的意外。如果选择开发环境来进行测试，开发人员进行某项误操作后发生系统崩溃或者系统不能正常运行的意外，此时测试工作也不得不停止。

UI测试常见BUG汇总——适用于新手

录入界面

1.1 输入字段要完整，且要与列表字段相符合（参照数据库进行检查）

1.2 必填项一律在后面用*表示（必填项为空在处理之前要有相关的提示信息）

1.3 字段需要做校验，如果校验不对需要在处理之前要有相关的提示信息

（1） 长度校验

（2） 数字、字母、日期等等的校验

（3） 范围的校验

1.4 录入字段的排序按照流程或使用习惯，字段特别多的时候需要进行分组显示

1.5 下拉框不选值的时候应该提供默认值

1.6 相同字段的录入方式应该统一（手动输入 、点选 、下拉选择、参照）

1.7 录入后自动计算的字段要随着别的字段修改更新（如单价变后，金额也变）

1.8 日期参照应该既能输入，又能从文本框选择

界面格式

2.1 字体颜色、大小、对齐方式（根据字段的性质确定）、加粗的一致性

2.2 文本框、按钮、滚动条、列表等控件的大小、对齐、位置的一致性

2.3 所有新增、修改、查看页面加上页面说明（如：XXX新增、XXX编辑、XXX查看等说明字样），（弹出的）界面要有标题，标题与内容要一致

2.4 不同界面显示相同字段的一致性（如列表界面和编辑界面）

2.5 界面按钮显示要求（查询、新增、删除顺序）

2.6 列表的顺序排列应该统一（按照某些特定条件排序）

2.7 下拉框中的排列顺序需要符合使用习惯或者是按照特定的规则排定

2.8 所有弹出窗口居中显示或者最大化显示

2.9 信息列表中如果某个字段显示过长用“…”或者分行显示

2.10 人员、时间的缺省值一般取当前登录人员和时间

2.11 对于带有单位的字段，需要字段的标签后面添加如下内容：“（单位）”

功能问题

3.1 按钮功能的实现（如返回按钮能否返回）

3.2 信息保存提交后系统给出“保存/提交成功”提示信息，并自动更新显示

3.3 所有有提交按钮的页面都要有保存按钮（每个界面风格一致）

3.4 凡是点选或者下拉选择的界面，如果一旦选择完了无法回到不选择的情况，需要加上“清除选择”功能按钮

3.5 没有选择记录点击删除/修改按钮要提示“请先选择记录”

3.6 选择记录后点击删除按钮要提示“确实要删除吗？”

3.7 需要考虑删除的关联性，即删除某一个内容需要同时删除其关联的某些内容

3.8 界面只读的时候（查询、统计、导入）等，应该不能编辑

查询问题

4.1 查询条件缺少一些可以查询的字段

4.2 有些查询条件需要支持模糊查询

4.3 需要考虑有些查询条件本身的关联性（即某个查询条件的取值范围是依赖于其它查询条件的取值）

4.4 查询条件名称与信息列表及信息编辑页面相应的字段名称完全统一

4.5 不同模块相同字段的查询方式应该统一（手动输入 、点选 、下拉选择）

4.6 出报表的时候，查询条件需要显示在报表标题的下面，这样看报表的时候知道数据的依据是什么

4.7 对于范围的查询采用全闭的形式（如 [2006-1-1,2006-12-30]）

  想雇到搞软件开发的聪明人可不容易。万一一不小心，就会搞到一堆低能大狒狒。我去年就碰到这种事了。你肯定不想这样吧。听我的，没错。在树上开站立会议门都没有。

问点有难度的问题能帮你把聪明人跟狒狒们分开。我决定把我自己整理出来的软件开发者面试百问发出来，希望能帮到你们的忙。

这个列表涵盖了软件工程知识体系中定义的大多数知识域。当然，如果你只想找出类拔萃的程序员，便只需涉及结构、算法、数据结构、测试这几个话题。如果想雇架构师，也可以只考虑需求、功能设计、技术设计这些地方。

不过不管你怎么做，都要牢记一点：

这里大多数问题的答案都没有对错之分！

你可以把我的这些问题作为引子，展开讨论。例如下面有个问题是使用静态方法或是单例的缘由。如果那个面试的就此展开长篇大论，那他很有可能是个聪明能干的家伙！如果他一脸茫然的看着你，发出这种声音，很明显这就是只狒狒了。同样，想知道一个数是不是2的乘方也有很多方法，不过要是面试的人想用mod运算符，嗯……你知道我的意思吧。（你不知道也没关系，来根香蕉？）

需求

你能给出一些非功能性（或者质量）需求的例子么？
如果客户需要高性能、使用极其方便而又高度安全，你会给他什么建议？
你能给出一些用来描述需求的不同技术么？它们各自适用于什么场景？
需求跟踪是什么意思？什么是向前追溯，什么是向后追溯？
你喜欢用什么工具跟踪需求？
你怎么看待需求变化？它是好是坏？给出你的理由。
你怎样研究需求，发现需求？有哪些资源可以用到？
你怎么给需求制定优先级？有哪些技术？
在需求过程中，用户、客户、开发人员各自的职责是什么？
你怎么对待不完整或是令人费解的需求？
功能设计

在功能设计中有哪些隐喻？给出几个成功的例子。
如果有些功能的执行时间很长，怎么能让用户感觉不到太长的等待？
如果用户必须要在一个很小的区域内，从一个常常的列表中选择多个条目，你会用什么控件？
有哪些方法可以保证数据项的完整？
建立系统原型有哪些技术？
应用程序怎样建立对用户行为的预期？给出一些例子。
如何入手设计一组数量庞大而又复杂的特性，你能举出一些设计思路吗？
有一个列表，其中有10个元素，每个元素都有20个字段可以编辑，你怎样设计这种情况？如果是1000个元素，每个元素有3个字段呢？
用不同的颜色对一段文本中的文字标记高亮，这种做法有什么问题？
Web环境和Windows环境各有些什么限制？
技术设计

什么是低耦合和高聚合？封装原则又是什么意思？
在Web应用中，你怎样避免几个人编辑同一段数据所造成的冲突？
你知道设计模式吗？你用过哪些设计模式？在什么场合下用的？
是否了解什么是无状态的业务层？长事务如何与之相适应？
在搭建一个架构，或是技术设计时，你用过几种图？
在N层架构中都有哪些层？它们各自的职责是什么？
有哪些方法可以确保架构中数据的正确和健壮？
面向对象设计和面向组件设计有哪些不同之处？
怎样在数据库中对用户授权、用户配置、权限管理这几项功能建模？
怎样按照等级制度给动物王国（包括各种物种和各自的行为）建模？
程序设计

你怎样保证你的代码可以处理各种错误事件？
解释一下什么是测试驱动开发，举出极限编程中的一些原则。
看别人代码的时候，你最关心什么地方？
什么时候使用抽象类，什么时候使用接口？
除了IDE以外，你还喜欢哪些必不可少的工具？
你怎么保证代码执行速度快，而又不出问题？
什么时候用多态，什么时候用委派？
什么时候使用带有静态成员的类，什么时候使用单例？
你在代码里面怎么提前处理需求的变化？给一些例子。
描述一下实现一段代码的过程，从需求到最终交付。
算法

怎样知道一个数字是不是2的乘方？怎样判断一个数是不是奇数？
怎样找出链表中间的元素？
怎样改变10,000个静态HTML页面中所有电话号码的格式？
举出一个你所用过的递归的例子。
在散列表和排序后的列表中找一个元素，哪个查找速度最快？
不管是书、杂志还是网络，你从中所学到的最后一点算法知识是什么？
怎样把字符串反转？你能不用临时的字符串么？
你愿意用什么类型的语言来编写复杂的算法？
有一个数组，里面是从1到1,000,000的整数，其中有一个数字出现了两次，你怎么找出那个重复的数字？
你知道“旅行商问题（Traveling Salesman Problem）”么？
数据结构

怎样在内存中实现伦敦地铁的结构？
怎样以最有效的方式在数据库中存储颜色值？
队列和堆栈区别是什么？
用堆或者栈存储数据的区别是什么？
怎样在数据库中存储N维向量？
你倾向于用哪种类型的语言编写复杂的数据结构？
21的二进制值是什么？十六制值呢？
不管是书、杂志还是网络，你从中所学到的最后一点数据结构的知识是什么？
怎样在XML文档中存储足球比赛结果（包括队伍和比分）？
有哪些文本格式可以保存Unicode字符？
测试

什么是回归测试？怎样知道新引入的变化没有给现有的功能造成破坏？
如果业务层和数据层之间有依赖关系，你该怎么写单元测试？
你用哪些工具测试代码质量？
在产品部署之后，你最常碰到的是什么类型的问题？
什么是代码覆盖率？有多少种代码覆盖率？
功能测试和探索性测试的区别是什么？你怎么对网站进行测试？
测试套件、测试用例、测试计划，这三者之间的区别是什么？你怎么组织测试？
要对电子商务网站做冒烟测试，你会做哪些类型的测试？
客户在验收测试中会发现不满意的东西，怎样减少这种情况的发生？
你去年在测试和质量保证方面学到了哪些东西？
维护

你用哪些工具在维护阶段对产品进行监控？
要想对一个正在产品环境中被使用的产品进行升级，该注意哪些重要事项？
如果在一个庞大的文件中有错误，而代码又无法逐步跟踪，你怎么找出错误？
你怎样保证代码中的变化不会影响产品的其他部分？
你怎样为产品编写技术文档？
你用过哪些方式保证软件产品容易维护？
怎样在产品运行的环境中进行系统调试？
什么是负载均衡？负载均衡的方式有哪些种？
为什么在应用程序的生命周期中，软件维护费用所占的份额最高？
再造工程（re-engineering）和逆向工程（reverse engineering）的区别是什么？
配置管理

你知道配置管理中基线的含义么？怎样把项目中某个重要的时刻冻结？
你一般会把哪些东西纳入版本控制？
怎样可以保证团队中每个人都知道谁改变了哪些东西？
Tag和Branch的区别是什么？在什么情况下该使用tag，什么时候用branch？
怎样管理技术文档——如产品架构文档——的变化？
你用什么侗剧管理项目中所有数字信息的状态？你最喜欢哪种工具？
如果客户想要对一款已经发布的产品做出变动，你怎么处理？
版本管理和发布管理有什么差异？
对文本文件的变化和二进制文件的变化进行管理，这二者有什么不同？
同时处理多个变更请求，或是同时进行增量开发和维护，这种事情你怎么看待？
项目管理

范围、时间、成本，这三项中哪些是可以由客户控制的？
谁该对项目中所要付出的一切做出估算？谁有权设置最后期限？
减少交付的次数，或是减少每个每个交付中的工作量，你喜欢哪种做法？
你喜欢用哪种图来跟踪项目进度？
迭代和增量的区别在哪里？
试着解释一下风险管理中用到的实践。风险该如何管理？
你喜欢任务分解还是滚动式计划？
你需要哪些东西帮助你判断项目是否符合时间要求，在预算范围内运作？
DSDM、Prince2、Scrum，这三者之间有哪些区别？
如果客户想要的东西太多，你在范围和时间上怎样跟他达成一致呢？

Web-OA工作流使用详解
一、概念篇
 随着企业管理信息化进程的不断深入，使用IT技术来规范工作流程的理念已开始为广大用户所接受。

Web-OA的工作流正是为这一需求而设计，可实现业务或公文的申请、审批管理。并实现数据的规范化录入、查询和存档。

简单来说，工作流就是把一项工作化解为多个步骤，由多人协同来完成一项工作。而在工作流中，业务数据或公文都可以通过“表单”来体现，“表单”是数据的载体，另外，表单还可以附带附件文件[磁盘附件和在线Office文档]。

Web-OA工作流的一些概念：
1、工作流：就是几个人协同完成一项工作，简单而言，就是几个人填写同一张“表单”，只是填写表单的人根据流程定义有先后之分，后面的人可以查看前面用户填写的内容。
2、表单：Web-OA用来接受用户输入的界面。由用户自行设计（一般由有权限的用户设计好），Web-OA的表单格式可以用word、Excel、网页工具等设计，设计好后复制、粘贴到“表单智能设计器”中，再添加定义各表单域就可以了。
3、流程：规定如何填写某表单的相应步骤。一个流程一般对应一个表单，也可以多个流程用同一个表单。流程分为固定流程和自由流程两种，固定流程由固定步骤组成，用户事先需定义好，包括某一步骤的可写表单域和可操作人员；自由流程无需定义流程步骤。固定流程第一个步骤的可操作人员有权新建该工作流程（道理可想而知）。
4、工作：即流程的实际运用。新建工作时，必须确定使用的流程，而流程又对应某一个表单，所以，工作就是按流程规定的步骤由多人来实现对某一表单的数据的填写过程。
5、工作监控：执行中的工作和已完成的工作，都可以对其监控。包括删除、跳过某步骤、回转到上一步骤、设置工作代办和终止工作等。有权限的监控人员可随时处理办理中的工作。
6、工作查询：在待办工作、应办工作和完成工作页面，用户可以根据工作名称关键字查询工作，在工作查询页面中，用户可以根据工作实际内容[即工作使用的表单数据]查询。

某网站提供会员模板下载、上传、购买、支付等功能，目前进入性能测试阶段，通过性能需求可以了解到主要有以下几个性能指标需要进行测试：
产品页面刷新性能
产品上传性能
产品下载性能
目前给出的指标为：
延迟：
测试项          响应时间      抖动 备注
产品页面刷新     <5秒         <2秒
产品下载相应时间  <4秒        <2秒

吞吐量：
编号      项                              吞吐量  
Perf.T.1 所有登录用户在线状态更改频率  每10分钟1次  
Perf.T.2 每日页面平均访问量            60000次
Perf.T.3 每日下载量                    50000  
Perf.T.4 平均每日新增会员数量          500  
Perf.T.5 高峰同一模板下载量            100用户并发下载
Perf.T.6 高峰不同模板下载量            150用户并发下载

容量：
编号      项             容量
Perf.C.1 用户数          <=100万
Perf.C.2 活动用户数       10000  
Perf.C.3 模板中心总用户数  <=25万

根据如上性能需求及数据我们该如何设计性能测试用例及场景呢？（可以说给出的性能需求很垃圾，没有丝毫价值，但没办法还是点做啊）
首先，我不去在乎它要求的性能是什么，我只需要去做在一定的测试环境下对系统进行压力测试，找到各个性能指标的临界点就好了，至于是否达到性能指标，在和性能需求对照编写测试报告即可。

所以，针对这几个需要进行性能测试的页面，我们做一下分析，如何设计场景才能尽可能准确地体现出系统的性能：

先说一下搜索页面
搜索页面根据对项目的了解，搜索后，将所有符合条件的结果遍历出来，显示在前台，每页的显示数量是一定的，超出的部分分页显示。根据上面的描述我们可以看出搜索结果是在将符合条件的所有结果集均发送到前台页面，对于页面显示对性能的消耗我们可以忽略不计，主要的压力来自数据的传输、sql的执行及应用服务器的处理过程，所以我可以从两个方面设计场景：

a、虚拟用户一定，不同数据库数量级的情况下，搜索的性能
如何确定虚拟用户的数量成为一个关键，我们可以让客户提供一个常规情况下每天访问用户数（如果没有实际数据可参考，可以根据产品方案中期望的用户数来代替），我们就用这个用户数来进行测试；再来分析一下不同的数据库数量级，如果系统运营1年的产品数据量是5万条，那么我们就根据这个值分别取1W条、3W条、5W条、10W条、20W条数据量来进行测试（具体的分法可以根据实际情况而定），所以对于这个测试目标，我们可以设计5个场景进行：
虚拟用户数 数据库数量级 录制页面 并发用户数执行时间思考时间  
100      10000       搜索页面 随机产生   30分钟   加入思考时间
100      30000       搜索页面 随机产生   30分钟   加入思考时间  
100      50000       搜索页面 随机产生   30分钟   加入思考时间
100      100000      搜索页面 随机产生   30分钟   加入思考时间
100      200000      搜索页面 随机产生   30分钟   加入思考时间
b、一定数据库数量级，不同量虚拟用户的情况下，搜索的性能
我们定下来一个常规的数据库数据量，在数据量不变的情况下逐步增加虚拟用户数，测试一下不同虚拟用户压力下系统的性能
虚拟用户数 数据库数量级 录制页面 并发用户数执行时间思考时间  
50        50000      搜索页面 随机产生   30分钟   加入思考时间
80        50000      搜索页面 随机产生   30分钟   加入思考时间
100       50000      搜索页面 随机产生   30分钟   加入思考时间
120       50000      搜索页面 随机产生   30分钟   加入思考时间  
150       50000      搜索页面 随机产生   30分钟   加入思考时间

产品上传
影响上传性能的主要因素有上传文件的大小和上传的请求数，所以我们就从这两个方面设计用例。
a、虚拟用户数一定，上传不同大小的文件
虚拟用户数 上传文件大小 录制页面 并发用户数 执行时间 思考时间
50        100k       上传页面 随机产生   30分钟   取消思考时间  
50        300k       上传页面 随机产生   30分钟   取消思考时间
50        500k       上传页面 随机产生   30分钟   取消思考时间
50        800k       上传页面 随机产生   30分钟   取消思考时间  
50        1M         上传页面 随机产生   30分钟   取消思考时间

b、上传文件大小一定，不同量的虚拟用户
虚拟用户数 上传文件大小 录制页面 并发用户数执行时间思考时间  
20       300k        上传页面 随机产生 30分钟     取消思考时间  
50       300k        上传页面 随机产生 30分钟     取消思考时间
80       300k        上传页面 随机产生 30分钟     取消思考时间
100      300k        上传页面 随机产生 30分钟     取消思考时间

产品下载
影响下载性能的主要因素有下载文件的大小和下载的请求数，所以我们就从这两个方面设计用例
a、虚拟用户数一定，下载不同大小的文件
虚拟用户数 下载文件大小 录制页面 并发用户数执行时间思考时间  
50        100k       下载页面 随机产生 30分钟取消思考时间  
50        300k       下载页面 随机产生 30分钟取消思考时间  
50        500k       下载页面 随机产生 30分钟取消思考时间  
50        800k       下载页面 随机产生 30分钟取消思考时间  
50        1M         下载页面 随机产生 30分钟 取消思考时间

b、下载文件大小一定，不同量的虚拟用户
虚拟用户数 下载文件大小 录制页面 并发用户数 执行时间 思考时间
20         300k      下载页面 随机产生  30分钟    取消思考时间
50         300k      下载页面 随机产生  30分钟    取消思考时间  
80         300k      下载页面 随机产生  30分钟    取消思考时间
100        300k      下载页面 随机产生  30分钟    取消思考时间

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。
一、概述

      性能测试在软件的质量保证中起着重要的作用，它包括的测试内容丰富多样。中国软件评测中心将性能测试概括为三个方面：应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。通常情况下，三方面有效、合理的结合，可以达到对系统性能全面的分析和瓶颈的预测。

    ·应用在客户端性能的测试

　　应用在客户端性能测试的目的是考察客户端应用的性能，测试的入口是客户端。它主要包括并发性能测试、疲劳强度测试、大数据量测试和速度测试等，其中并发性能测试是重点。

      并发性能测试是重点

　　并发性能测试的过程是一个负载测试和压力测试的过程，即逐渐增加负载，直到系统的瓶颈或者不能接收的性能点，通过综合分析交易执行指标和资源监控指标来确定系统并发性能的过程。负载测试（Load Testing）是确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统组成部分的相应输出项，例如通过量、响应时间、CPU负载、内存使用等来决定系统的性能。负载测试是一个分析软件应用程序和支撑架构、模拟真实环境的使用，从而来确定能够接收的性能过程。压力测试（Stress Testing）是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。

　　并发性能测试的目的主要体现在三个方面：以真实的业务为依据，选择有代表性的、关键的业务操作设计测试案例，以评价系统的当前性能；当扩展应用程序的功能或者新的应用程序将要被部署时，负载测试会帮助确定系统是否还能够处理期望的用户负载，以预测系统的未来性能；通过模拟成百上千个用户，重复执行和运行测试，可以确认性能瓶颈并优化和调整应用，目的在于寻找到瓶颈问题。

　　当一家企业自己组织力量或委托软件公司代为开发一套应用系统的时候,尤其是以后在生产环境中实际使用起来,用户往往会产生疑问,这套系统能不能承受大量的并发用户同时访问? 这类问题最常见于采用联机事务处理(OLTP)方式数据库应用、Web浏览和视频点播等系统。这种问题的解决要借助于科学的软件测试手段和先进的测试工具。

      举例说明：电信计费软件

　　众所周知,每月20日左右是市话交费的高峰期，全市几千个收费网点同时启动。收费过程一般分为两步,首先要根据用户提出的电话号码来查询出其当月产生费用,然后收取现金并将此用户修改为已交费状态。一个用户看起来简单的两个步骤,但当成百上千的终端，同时执行这样的操作时，情况就大不一样了,如此众多的交易同时发生,对应用程序本身、操作系统、中心数据库服务器、中间件服务器、网络设备的承受力都是一个严峻的考验。决策者不可能在发生问题后才考虑系统的承受力, 预见软件的并发承受力, 这是在软件测试阶段就应该解决的问题。

　　目前，大多数公司企业需要支持成百上千名用户，各类应用环境以及由不同供应商提供的元件组装起来的复杂产品，难以预知的用户负载和愈来愈复杂的应用程序，使公司担忧会发生投放性能差、用户遭受反应慢、系统失灵等问题。其结果就是导致公司收益的损失。

　　如何模拟实际情况呢? 找若干台电脑和同样数目的操作人员在同一时刻进行操作,然后拿秒表记录下反应时间？这样的手工作坊式的测试方法不切实际，且无法捕捉程序内部变化情况,这样就需要压力测试工具的辅助。

　　测试的基本策略是自动负载测试，通过在一台或几台PC机上模拟成百或上千的虚拟用户同时执行业务的情景，对应用程序进行测试，同时记录下每一事务处理的时间、中间件服务器峰值数据、数据库状态等。通过可重复的、真实的测试能够彻底地度量应用的可扩展性和性能，确定问题所在以及优化系统性能。预先知道了系统的承受力,就为最终用户规划整个运行环境的配置提供了有力的依据。

      并发性能测试前的准备工作

　　测试环境：配置测试环境是测试实施的一个重要阶段，测试环境的适合与否会严重影响测试结果的真实性和正确性。测试环境包括硬件环境和软件环境，硬件环境指测试必需的服务器、客户端、网络连接设备以及打印机/扫描仪等辅助硬件设备所构成的环境；软件环境指被测软件运行时的操作系统、数据库及其他应用软件构成的环境。

　　一个充分准备好的测试环境有三个优点：一个稳定、可重复的测试环境，能够保证测试结果的正确；保证达到测试执行的技术需求；保证得到正确的、可重复的以及易理解的测试结果。

　　测试工具：并发性能测试是在客户端执行的黑盒测试，一般不采用手工方式，而是利用工具采用自动化方式进行。目前，成熟的并发性能测试工具有很多，选择的依据主要是测试需求和性能价格比。著名的并发性能测试工具有QALoad、LoadRunner、Benchmark Factory和Webstress等。这些测试工具都是自动化负载测试工具，通过可重复的、真实的测试，能够彻底地度量应用的可扩展性和性能，可以在整个开发生命周期、跨越多种平台、自动执行测试任务，可以模拟成百上千的用户并发执行关键业务而完成对应用程序的测试。

　　测试数据：在初始的测试环境中需要输入一些适当的测试数据，目的是识别数据状态并且验证用于测试的测试案例，在正式的测试开始以前对测试案例进行调试，将正式测试开始时的错误降到最低。在测试进行到关键过程环节时，非常有必要进行数据状态的备份。制造初始数据意味着将合适的数据存储下来，需要的时候恢复它，初始数据提供了一个基线用来评估测试执行的结果。

　　在测试正式执行时，还需要准备业务测试数据，比如测试并发查询业务，那么要求对应的数据库和表中有相当的数据量以及数据的种类应能覆盖全部业务。

　　模拟真实环境测试，有些软件，特别是面向大众的商品化软件，在测试时常常需要考察在真实环境中的表现。如测试杀毒软件的扫描速度时，硬盘上布置的不同类型文件的比例要尽量接近真实环境，这样测试出来的数据才有实际意义。

      并发性能测试的种类与指标

　　并发性能测试的种类取决于并发性能测试工具监控的对象，以QALoad自动化负载测试工具为例。软件针对各种测试目标提供了DB2、DCOM、ODBC、ORACLE、NETLoad、Corba、QARun、SAP、SQLServer、Sybase、Telnet、TUXEDO、UNIFACE、WinSock、WWW、Java scrīpt等不同的监控对象，支持Windows和UNIX测试环境。

　　最关键的仍然是测试过程中对监控对象的灵活应用，例如目前三层结构的运行模式广泛使用，对中间件的并发性能测试作为问题被提到议事日程上来，许多系统都采用了国产中间件，选择Java scrīpt监控对象，手工编写脚本，可以达到测试目的。

　　采用自动化负载测试工具执行的并发性能测试，基本遵循的测试过程有：测试需求与测试内容，测试案例制定，测试环境准备，测试脚本录制、编写与调试，脚本分配、回放配置与加载策略，测试执行跟踪，结果分析与定位问题所在，测试报告与测试评估。

　　并发性能测试监控的对象不同，测试的主要指标也不相同，主要的测试指标包括交易处理性能指标和 UNIX资源监控。其中，交易处理性能指标包括交易结果、每分钟交易数、交易响应时间（Min：最小服务器响应时间；Mean：平均服务器响应时间；Max：最大服务器响应时间；StdDev：事务处理服务器响应的偏差，值越大，偏差越大；Median：中值响应时间；90％：90％事务处理的服务器响应时间）、虚拟并发用户数。

      应用实例：“新华社多媒体数据库 V1.0”性能测试

　　中国软件评测中心（CSTC）根据新华社技术局提出的《多媒体数据库（一期）性能测试需求》和GB/T 17544《软件包质量要求和测试》的国家标准，使用工业标准级负载测试工具对新华社使用的“新华社多媒体数据库 V1.0”进行了性能测试。

　　性能测试的目的是模拟多用户并发访问新华社多媒体数据库，执行关键检索业务，分析系统性能。

　　性能测试的重点是针对系统并发压力负载较大的主要检索业务，进行并发测试和疲劳测试，系统采用B/S运行模式。并发测试设计了特定时间段内分别在中文库、英文库、图片库中进行单检索词、多检索词以及变检索式、混合检索业务等并发测试案例。疲劳测试案例为在中文库中并发用户数200，进行测试周期约8小时的单检索词检索。在进行并发和疲劳测试的同时，监测的测试指标包括交易处理性能以及 UNIX（Linux）、Oracle、Apache资源等。

　　测试结论：在新华社机房测试环境和内网测试环境中，100M带宽情况下，针对规定的各并发测试案例，系统能够承受并发用户数为200的负载压力，最大交易数/分钟达到78.73，运行基本稳定，但随着负载压力增大，系统性能有所衰减。

　　系统能够承受200并发用户数持续周期约8小时的疲劳压力，基本能够稳定运行。

　　通过对系统UNIX（Linux）、Oracle和Apache资源的监控，系统资源能够满足上述并发和疲劳性能需求，且系统硬件资源尚有较大利用余地。

　　当并发用户数超过200时，监控到HTTP 500、connect和超时错误，且Web服务器报内存溢出错误，系统应进一步提高性能，以支持更大并发用户数。

　　建议进一步优化软件系统，充分利用硬件资源，缩短交易响应时间。

      疲劳强度与大数据量测试

　　疲劳测试是采用系统稳定运行情况下能够支持的最大并发用户数，持续执行一段时间业务，通过综合分析交易执行指标和资源监控指标来确定系统处理最大工作量强度性能的过程。

　　疲劳强度测试可以采用工具自动化的方式进行测试，也可以手工编写程序测试，其中后者占的比例较大。

　　一般情况下以服务器能够正常稳定响应请求的最大并发用户数进行一定时间的疲劳测试，获取交易执行指标数据和系统资源监控数据。如出现错误导致测试不能成功执行，则及时调整测试指标，例如降低用户数、缩短测试周期等。还有一种情况的疲劳测试是对当前系统性能的评估，用系统正常业务情况下并发用户数为基础，进行一定时间的疲劳测试。

　　大数据量测试可以分为两种类型：针对某些系统存储、传输、统计、查询等业务进行大数据量的独立数据量测试；与压力性能测试、负载性能测试、疲劳性能测试相结合的综合数据量测试方案。大数据量测试的关键是测试数据的准备，可以依靠工具准备测试数据。

　　速度测试目前主要是针对关键有速度要求的业务进行手工测速度，可以在多次测试的基础上求平均值，可以和工具测得的响应时间等指标做对比分析。

      ·应用在网络上性能的测试

　　应用在网络上性能的测试重点是利用成熟先进的自动化技术进行网络应用性能监控、网络应用性能分析和网络预测。

      网络应用性能分析

　　网络应用性能分析的目的是准确展示网络带宽、延迟、负载和TCP端口的变化是如何影响用户的响应时间的。利用网络应用性能分析工具，例如Application Expert，能够发现应用的瓶颈，我们可知应用在网络上运行时在每个阶段发生的应用行为，在应用线程级分析应用的问题。可以解决多种问题：客户端是否对数据库服务器运行了不必要的请求？当服务器从客户端接受了一个查询，应用服务器是否花费了不可接受的时间联系数据库服务器？在投产前预测应用的响应时间；利用Application Expert调整应用在广域网上的性能；Application Expert能够让你快速、容易地仿真应用性能，根据最终用户在不同网络配置环境下的响应时间，用户可以根据自己的条件决定应用投产的网络环境。

      网络应用性能监控

　　在系统试运行之后，需要及时准确地了解网络上正在发生什么事情；什么应用在运行，如何运行；多少 PC正在访问LAN或WAN；哪些应用程序导致系统瓶颈或资源竞争，这时网络应用性能监控以及网络资源管理对系统的正常稳定运行是非常关键的。利用网络应用性能监控工具，可以达到事半功倍的效果，在这方面我们可以提供的工具是Network Vantage。通俗地讲，它主要用来分析关键应用程序的性能，定位问题的根源是在客户端、服务器、应用程序还是网络。在大多数情况下用户较关心的问题还有哪些应用程序占用大量带宽，哪些用户产生了最大的网络流量，这个工具同样能满足要求。

      网络预测

　　考虑到系统未来发展的扩展性，预测网络流量的变化、网络结构的变化对用户系统的影响非常重要。根据规划数据进行预测并及时提供网络性能预测数据。我们利用网络预测分析容量规划工具PREDICTOR可以作到：设置服务水平、完成日网络容量规划、离线测试网络、网络失效和容量极限分析、完成日常故障诊断、预测网络设备迁移和网络设备升级对整个网络的影响。

　　从网络管理软件获取网络拓扑结构、从现有的流量监控软件获取流量信息（若没有这类软件可人工生成流量数据），这样可以得到现有网络的基本结构。在基本结构的基础上，可根据网络结构的变化、网络流量的变化生成报告和图表，说明这些变化是如何影响网络性能的。 PREDICTOR提供如下信息：根据预测的结果帮助用户及时升级网络，避免因关键设备超过利用阀值导致系统性能下降；哪个网络设备需要升级，这样可减少网络延迟、避免网络瓶颈；根据预测的结果避免不必要的网络升级。

      ·应用在服务器上性能的测试

　　对于应用在服务器上性能的测试，可以采用工具监控，也可以使用系统本身的监控命令，例如Tuxedo中可以使用Top命令监控资源使用情况。实施测试的目的是实现服务器设备、服务器操作系统、数据库系统、应用在服务器上性能的全面监控，测试原理如下图。

UNIX资源监控指标和描述

　　监控指标 描述
　　平均负载 系统正常状态下，最后60秒同步进程的平均个数
　　冲突率 在以太网上监测到的每秒冲突数
　　进程/线程交换率 进程和线程之间每秒交换次数
　　CPU利用率 CPU占用率（％）
　　磁盘交换率 磁盘交换速率
　　接收包错误率 接收以太网数据包时每秒错误数
　　包输入率 每秒输入的以太网数据包数目
　　中断速率 CPU每秒处理的中断数
　　输出包错误率 发送以太网数据包时每秒错误数
　　包输入率 每秒输出的以太网数据包数目
　　读入内存页速率 物理内存中每秒读入内存页的数目
　　写出内存页速率 每秒从物理内存中写到页文件中的内存页数
　　 目或者从物理内存中删掉的内存页数目
　　内存页交换速率 每秒写入内存页和从物理内存中读出页的个数
　　进程入交换率 交换区输入的进程数目
　　进程出交换率 交换区输出的进程数目
　　系统CPU利用率 系统的CPU占用率（％）
　　用户CPU利用率 用户模式下的CPU占用率（％）
　　磁盘阻塞 磁盘每秒阻塞的字节数

二、为什么进行性能测试？

      目的是验证软件系统是否能够达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈，优化软件，最后起到优化系统的目的。

      包括以下几个方面

1．评估系统的能力，测试中得到的负荷和响应时间数据可以被用于验证所计划的模型的能力，并帮助作出决策。
2．识别体系中的弱点：受控的负荷可以被增加到一个极端的水平，并突破它，从而修复体系的瓶颈或薄弱的地方。
3．系统调优：重复运行测试，验证调整系统的活动得到了预期的结果，从而改进性能。
检测软件中的问题：长时间的测试执行可导致程序发生由于内存泄露引起的失败，揭示程序中的隐含的问题或冲突。
4．验证稳定性（resilience）可靠性（reliability）：在一个生产负荷下执行测试一定的时间是评估系统稳定性和可靠性是否满足要求的唯一方法。

      性能测试类型包括负载测试，强度测试，容量测试等

      负载测试：负载测试是一种性能测试指数据在超负荷环境中运行，程序是否能够承担。

      强度测试： 强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况。

      容量测试：确定系统可处理同时在线的最大用户数 

      观察指标：

      性能测试主要是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。

      在实际中作中我们经常会对两种类型软件进行测试：bs和cs，这两方面的性能指标一般需要哪些内容呢？

Bs结构程序一般会关注的通用指标如下（简）：

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 ：尝试链接数；

CS结构程序，由于一般软件后台通常为数据库，所以我们更注重数据库的测试指标：

* User 0 Connections ：用户连接数，也就是数据库的连接数量；

* Number of deadlocks：数据库死锁；

* Butter Cache hit ：数据库Cache的命中情况

      当然，在实际中我们还会察看多用户测试情况下的内存，CPU，系统资源调用情况。这些指标其实是引申出来性能测试中的一种：竞争测试。什么是竞争测试，软件竞争使用各种资源（数据纪录，内存等），看他与其他相关系统对资源的争夺能力。

      我们知道软件架构在实际测试中制约着测试策略和工具的选择。如何选择性能测试策略是我们在实际工作中需要了解的。一般软件可以按照系统架构分成几种类型：

c/s

client/Server 客户端/服务器架构

基于客户端/服务器的三层架构

基于客户端/服务器的分布式架构

b/s

基于浏览器/Web服务器的三层架构

基于中间件应用服务器的三层架构l

基于Web服务器和中间件的多层架构l

缺陷测试中容易忽略掉的几个问题 
 摘要：
        在系统测试和确认测试中，有些缺陷由于某些原因往往被忽略了，这就给软件留下了隐患或者危机。本文通过描述这些容易忽略的缺陷，提供一个完善测试用例和测试执行的参考。

正文：
        通常软件测试会暴露软件中的缺陷，经过修正后可以保证软件系统的功能满足需求并正确运行。但是，在系统测试和确认测试中，测试人员容易遗漏一些隐藏的缺陷。众所周知，软件测试不可能发现所有的缺陷，而软件开发周期各个阶段仍然存在注入缺陷的可能，但是，有一些缺陷是测试中容易忽略的，也就是说，通过测试方法和用例可以充分暴露这些缺陷，遗憾的是，它们往往被忽略或者某种原因忘记测试了，这就给软件留下了隐患或者危机。这些容易被忽略的缺陷包括：

1、安装缺陷
        通常项目组完成代码后，发布时候安装打包是最后一个环节，而软件测试人员通常在测试的时候，没有仔细的测试这一部分，而把用例集中在其他功能上。安装时候的缺陷通常通过拷贝而不是运行安装程序方式给测试人员安装软件，结果正式安装时候出现问题，引起例如控件没有注册，注册表没有导入等。删除时候没有注意安装文件夹是否存在用户文件，造成数据丢失；使用绝对路径；安装顺序没有说明书。

2、配置文件
        有些文件在 ini 等配置文件中写出了管理员口令密码等信息，而且是明文的！这是一个安全隐患。另外，有些安装文件的 XML 文件，为了方便在数据库和中间层连接文件中写入了Admin 口令和密码。作为一个合格的软件测试人员，必须检查这些可以用记事本打开的文件。因为，一个稍有常识而且喜欢探索的用户，可能从中获取信息而成为不自觉的黑客。所以，配置文件可能成为软件安全方面的一个缺陷。

3、网页安全缺陷
        现在网站开发已经注意到：登陆网站进入其内部网页后，直接拷贝网址，然后粘贴到另一IE 窗口输入，可以绕过登陆直接访问。也许商业网站很关注这个问题，但是很多行业软件却很容易忽略。
        网页安全缺陷还可能存在于 IE 弹出的子窗口。有些设计不严格的软件，在主页面关闭的时候子页面还可以运行，这是一个明显的漏洞，而且还大大增加了错误发生的几率。

4、判断顺序/逻辑缺陷
        对界面进行多个输入判断的时候，非常容易出现这种问题。例如判断年月顺序，判断长度，判断非空等。假如操作员仅仅满足单个条件，保存不能成功；而按界面从上之下顺序一一满足条件之后，保存是没有问题的。但是，改变一下输入的次序，校验失效。例如，一一满足条件之后，不保存，倒过来将上面的输入改成非法输入，然后保存，结果居然也能成功，这是因为原先的判断由于发生过，或者根据语句顺序只检查最后一个判断，所以没有报错。这种错误尤其在 Java scrīpt 脚本的页面中要注意。能够保存不能保证数据正确，有可能引起系统崩溃或者后续数据错误。所以，在测试的时候，不要按照正常的顺序输入，而是要打乱步骤，看看代码是否强健，是否在判断逻辑上没有错误。良好的代码应该经得起折腾，至少保存时会再此全部进行判断，而不只是简简单单走到判断的最后一行。

5、调试语句和冗余信息
        维护项目和升级改造的推广系统最容易潜伏这类缺陷。典型表现在没有删除或者屏蔽调试语句。弹出一个界面不友好的提示信息，会使不明真相的用户产生误以为系统发生了严重故障，从而引起对软件的不信任感。页面中某个角落存在当前客户不需要的冗余按钮和功能也是一种缺陷。多余的功能会使用户以为是额外附加部分而去使用，其结果可想而知；而多余的按钮会误导好奇心强的用户操作，产生不必要的错误。
        同样值得关注的还有参数设置，由于没有实际数据，开发人员在调试或者单元测试的时候，习惯性的进行自我设定而忘了删除，软件测试人员可能会忽略掉了这部分测试，也可能导致在客户现场发生错误而影响系统发布和验收。

6、不可重现的故障
        新参加软件测试的人员或者新来的开发人员总是要问，不可重现的缺陷是否需要记录，有必要吗？回答是肯定的。测试必须如实的记录发生的问题，也许不能重现，或者使非软件系统本身问题，但是，可能这些偶然性背后是有规律的，不记录这些，就不可能发现这些规律。

7、多节点的逆向流转缺陷
        当前软件不少喜欢使用工作流来驱动。工作流的问题，就是可能出现多个流向分支。测试容易忽略的部分，就是工作流多节点的逆向流转。例如，通过不通过涉及两个分支，但是流程逆转的时候，有可能不是回到上一节点而是平级的另一个节点去了。软件测试要格外注意这类用例的设计。另外，有些时候默认分支在向前的时候是有默认值的，例如默认通过，那么保存的时候要提示用户是否通过，否则可能由于操作疲劳而走错了节点，引起回退。

8、输入框缺陷
        试过往输入框粘贴数据而不是直接输入吗？可能这里会出现问题。按 Ctrl＋V 的时候，输入框会根据长度大小自动截断输入长度。但是用鼠标，截断可能会失效。有一次测试人员就是用这种方法把一篇 Word 文档输入进去了，保存的时候，数据库崩溃。有些网站登陆的口令****可以拷贝下来的，只要放在剪贴板里面马上明文显示。
        输入框可以说是问题最多的部分，能够引起的麻烦也很多。日期、数字、文本等等，都需要耐心的测试一下。

9、界面布局缺陷
        曾经有一次，项目经理回来向测试部反映一个问题，客户对界面不满意。原因很简单，因为界面上删除按钮和保存按钮挨得很近。结果有些操作不熟练的业务人员，很容易误按。这个问题是测试人员没有意料到的，因此注意关闭、删除、退出按钮与保存、下一步等按钮的距离。类似的按钮应按此规则排列分布。
        界面布局还可能发生在窗口最大化和最小化上，有可能窗口缩小的时候没有下拉框或不匹配分辨率，对用户来讲，这个错误实在很低级。有些用户由于操作习惯，非常不喜欢腾出手使用鼠标，尤其是大量输入的界面，因此，要注意设置键盘的快捷方式。还有，按 Tab定位到下一焦点时要注意顺序，避免跳转太灵活而让操作人员感到无从适应，在界面进行维护或者修改的时候，不要忘了软件测试开发人员是否无意改变了这些快捷方式和跳转顺序。

10、版本和补丁包的环境问题
        理论上讲，这属于兼容性测试应该覆盖的问题。有些客户很喜欢更新最新的软件版本或者微软时不时打些补丁包，问题就出现了。有时候升级不一定是好事。这些问题最好在测试的时候增加几个用例，多用不同软件版本的机器跑一跑。软件测试有个定律是：你没跑过的地方，就一定会出事。经常听到开发人员抱怨，怎么我的机器没问题，你的机器就有事了呢？这不能完全靠配置管理员解决问题，环境配置项是大家最容易忽略的。

11、用户管理缺陷
        用户管理的角色和授权需要好好研究一下，作过测试的人员都知道，有时候为了测试的方便，测试用户都是具有超级权限的用户。而且，比较容易忽略用户管理这一部分的测试。往往发往客户的时候，很多测试用户都没有删除。
        另外，有些接口的用户和口令，到软件使用寿命结束都没有更改过。在一次测试中，软件测试人员发现，给一个用户授超级用户权限，之后更改这个用户为受限权限。使用中发现，用户居然没有真正回收权限，用户管理界面上没有任何不对。及早准备用户管理用例，不要等到测试快结束时候才想起。

12、常识缺陷
        从逻辑或者统计学上讲，计算机是允许如此处理的，但是从常识上来讲，这些情况不可能发生。例如电话号码不可能出现小数点，终止时间不能大于开始时间等等。除此之外，常识还要结合业务特点来进行判断，因此，开发和测试人员要格外注意对自己知识的培养以及增加对需求细节的了解。不能因为一味追求进度而采用最简单的代码来实现，对用户来说，这些错误可能是很荒谬的。
        尽管我们不可能完美的测试一个软件，但是我们仍然可以改进我们的软件测试。每次测试结束，及时总结测试中的不足，进一步完善用例。思考一下那些容易忽略的软件缺陷，能提高对软件测试的认识，提高所在组织软件的质量。

很多时候,我们需要时间去证明,
某些时候,我们需要冷静;
有些时候,我们已错失机会,
更多时候,我们需要机会,
而彼此之间更多的是信任..

简单爱
刹那间的遇见,
瞬间的平静,
明白太多,
懂的不一定会很多,
有时简单也有简单的好处,
生活本来系自己选择生活,
而不是生活选择自己,
适合你的,
适合我的,
也许爱情真的是如此!
什么是希望?
是两人之间要去面对的,
而不是把自己的希望寄托在别人身上,
也许你会得到,
但未必你是幸福的,
因为别人都不快乐,
自己也不会快乐..

Benond MYSELF

Few things are impossible in themselves;
and it is often for want of will,
rather than of means,
that man fails to succeed.
很想知道答案,
我却沉默了,
是责任,
我要做得更好,
还是找到自己中意做的事?
一切都感觉越离越远,
我告诉自己:
一定要不能倒下,
但时间却离我越来越远...
选择真的那么重要?
但不选择,
永远也停留在此刻,
错觉?还是错过?
只想:好好地活着,
为幸福而努力!
但未来却系未知数?
一切都需要所有的努力,
我要为自己加油了,
不要轻言说放弃!

～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

一. 引言
性能测试与分析是软件开发过程中介于架构和调整的一个广泛并比较不容易理解的领域，更是一项较为复杂的活动。就像下棋游戏一样，有效的性能测试和分析只能在一个良好的计划策略和具备了对不可预料事件的处理能力的条件下顺利地完成。一个下棋高手赢得比赛靠的不仅仅是对游戏规则的认识，更是靠他的自己的能力和不断地专注于分析自己对手的实力来更加有效地利用和发挥规则的作用。同样一个优秀的性能测试和分析人员将要面对的是来自一个全新的应用程序和环境下带来的整个项目的挑战。本文中作者结合自己的使用经验和参考文档，对Tomcat性能方面的调整做一简要的介绍，并给出Tomcat性能的测试、分析和调整优化的一些方法。

二. 测量Web服务器的性能
测量web服务器的性能是一项让人感到畏缩的任务，但是我们在这里将给出一些需要注意的地方并且指点你了解其中更多的细节性的内容。它不像一些简单的任务，如测量CPU的速率或者是测量程序占用CPU的比例，web服务器的性能优化中包括许调整许多变量来达到目标。许多的测量策略中都包含了一个看似简单的浏览实际上是在向服务器发送大量的请求，我们称之为客户端的程序，来测量响应时间。客户端和服务器端是在同一台机器上吗？服务器在测试的时候还运行着其它的什么程序吗？客户端和服务器端的通讯是通过局域网，100baseT，10baseT还是使用调制解调器？客户端是否一直重复请求相同的页面，还是随机地访问不同的页面？（这些影响到了服务缓存的性能）客户端发送请求的有规律的还是突发的？你是在最终的配置环境下运行服务的还是在调试的配置环境下运行服务的？客户端请求中包含图片还是只有HTML页面？是否有请求是通过servlets和JSP的，CGI程序，服务端包含（Server-Side Includes ，SSI是一个可以让你使用动态HTML文件的技术）？所有这些都将是我们要关心的，并且几乎我们不可能精确地把所有的问题都清楚地列出来。

1.压力测试工具

“工欲善其事，必先利其器”，压力测试只有借助于一些工具才可得以实施。

大多数web压力测试工具的实现原理都是通过重复的大量的页面请求来模拟多用户对被测系统的并发访问，以此达到产生压力的目的。产生压力的手段都是通过录制或者是编写压力脚本，这些脚本以多个进程或者线程的形式在客户端运行，这样通过人为制造各种类型的压力，我们可以观察被测系统在各种压力状况下的表现，从而定位系统瓶颈，作为系统调优的基础。目前已经存在的性能测试工具林林总总，数量不下一百种，从单一的开放源码的免费小工具如 Aapache 自带的 web 性能测试工具 Apache Benchmark、开源的Jmeter 到大而全的商业性能测试软件如 Mercury 的 LoadRunner 等等。任何性能测试工具都有其优缺点，我们可以根据实际情况挑选用最合适的工具。您可以在这里找到一些web压力测试工具
http://www.softwareqatest.com/qatweb1.html#LOAD

这里我们所使用的工具要支持web应用服务认证才可以，要支持接收发送cookies，不仅如此Tomcat支持多种认证方式，比如基本认证、基于表单的认证、相互认证和客户端认证，而一些工具仅仅支持HTTP基本认证。真实地模拟用户认证是性能测试工具的一个重要的部分，因为认证机制将对一个web站点的性能特征产生重要的影响。基于你在产品中使用的不同的认证方式，你需要从上面的工具列表中选择使用这种特性的测试工具。

Apache Benchmark和http_load是命令行形式的工具，非常易于使用。Apache Benchmark可以模仿单独的URL请求并且重复地执行，可以使用不同的命令行参数来控制执行迭代的次数，并发用户数等等。它的一个特点是可以周期性地打印出处理过程的信息，而其它工具只能给出一个全局的报告。
2.压力测试工具介绍

三. 外部环境的调整

　　在Tomcat和应用程序进行了压力测试后，如果您对应用程序的性能结果不太满意，就可以采取一些性能调整措施了，当然了前提是应用程序没有问题，我们这里只讲Tomcat的调整。由于Tomcat的运行依赖于JVM，所以在这里我们把Tomcat的调整可以分为两类来详细描述：

　　外部环境调整
　　调整非Tomcat组件，例如Tomcat运行的操作系统和运行Tomcat的java虚拟机。
　　自身调整
　　修改Tomcat自身的参数，调整Tomcat配置文件中的参数。
　　下面我们将详细讲解外部环境调整的有关内容，Tomcat自身调整的内容将在第2部分中阐述。

　　1.JAVA虚拟机性能优化

　　Tomcat本身不能直接在计算机上运行，需要依赖于硬件基础之上的操作系统和一个java虚拟机。您可以选择自己的需要选择不同的操作系统和对应的JDK的版本（只要是符合Sun发布的Java规范的），但我们推荐您使用Sun公司发布的JDK。确保您所使用的版本是最新的，因为Sun公司和其它一些公司一直在为提高性能而对java虚拟机做一些升级改进。一些报告显示JDK1.4在性能上比JDK1.3提高了将近10%到20%。

　　可以给Java虚拟机设置使用的内存，但是如果你的选择不对的话，虚拟机不会补偿。可通过命令行的方式改变虚拟机使用内存的大小。如下表所示有两个参数用来设置虚拟机使用内存的大小。

参数 描述

-Xms<size> JVM初始化堆的大小
-Xmx<size> JVM堆的最大值

　　这两个值的大小一般根据需要进行设置。初始化堆的大小执行了虚拟机在启动时向系统申请的内存的大小。一般而言，这个参数不重要。但是有的应用程序在大负载的情况下会急剧地占用更多的内存，此时这个参数就是显得非常重要，如果虚拟机启动时设置使用的内存比较小而在这种情况下有许多对象进行初始化，虚拟机就必须重复地增加内存来满足使用。由于这种原因，我们一般把-Xms和-Xmx设为一样大，而堆的最大值受限于系统使用的物理内存。一般使用数据量较大的应用程序会使用持久对象，内存使用有可能迅速地增长。当应用程序需要的内存超出堆的最大值时虚拟机就会提示内存溢出，并且导致应用服务崩溃。因此一般建议堆的最大值设置为可用内存的最大值的80%。

　　Tomcat默认可以使用的内存为128MB，在较大型的应用项目中，这点内存是不够的，需要调大。

　　Windows下，在文件{ tomcat_home }/bin/catalina.bat，Unix下，在文件{ tomcat_home }/bin/catalina.sh的前面，增加如下设置：

　　JAVA_OPTS='-Xms【初始化内存大小】 -Xmx【可以使用的最大内存】'

　　需要把这个两个参数值调大。例如：

　　JAVA_OPTS='-Xms256m -Xmx512m'

　　表示初始化内存为256MB，可以使用的最大内存为512MB。

　　另外需要考虑的是Java提供的垃圾回收机制。虚拟机的堆大小决定了虚拟机花费在收集垃圾上的时间和频度。收集垃圾可以接受的速度与应用有关，应该通过分析实际的垃圾收集的时间和频率来调整。如果堆的大小很大，那么完全垃圾收集就会很慢，但是频度会降低。如果你把堆的大小和内存的需要一致，完全收集就很快，但是会更加频繁。调整堆大小的的目的是最小化垃圾收集的时间，以在特定的时间内最大化处理客户的请求。在基准测试的时候，为保证最好的性能，要把堆的大小设大，保证垃圾收集不在整个基准测试的过程中出现。

　　如果系统花费很多的时间收集垃圾，请减小堆大小。一次完全的垃圾收集应该不超过 3-5 秒。如果垃圾收集成为瓶颈，那么需要指定代的大小，检查垃圾收集的详细输出，研究 垃圾收集参数对性能的影响。一般说来，你应该使用物理内存的 80% 作为堆大小。当增加处理器时，记得增加内存，因为分配可以并行进行，而垃圾收集不是并行的。

2.操作系统性能优化

　　这里说的操作系统是指运行web服务器的系统软件，当然，不同的操作系统是为不同的目的而设计的。比如OpenBSD是面向安全的，因此在它的内核中有许多的限制来防止不同形式的服务攻击（OpenBSD的一句座右铭是“默认是最安全的”）。这些限制或许更多地用来运行活跃的web服务器。

　　而我们常用的Linux操作系统的目标是易用使用，因此它有着更高的限制。使用BSD内核的系统都带有一个名为“Generic”的内核，表明所有的驱动器都静态地与之相连。这样就使系统易于使用，但是如果你要创建一个自定义的内核来加强其中某些限制，那就需要排除不需要的设备。Linux内核中的许多驱动都是动态地加载的。但是换而言之，内存现在变得越来越便宜，所以因为加载额外的设备驱动就显得不是很重要的。重要的是要有更多的内存，并且在服务器上腾出更多的可用内存。

　　小提示：虽然现在内存已经相当的便宜，但还是尽量不要购买便宜的内存。那些有牌子的内存虽然是贵一点，但是从可靠性上来说，性价比会更高一些。

　　如果是在Windows操作系统上使用Tomcat，那么最好选择服务器版本。因为在非服务器版本上，最终用户授权数或者操作系统本身所能承受的用户数、可用的网络连接数或其它方面的一些方面都是有限制的。并且基于安全性的考虑，必须经常给操作系统打上最新的补丁。

　　3.Tomcat与其它web服务器整合使用

　　虽然tomcat也可以作web服务器,但其处理静态html的速度比不上apache,且其作为web服务器的功能远不如apache,因此我们想把apache和tomcat集成起来，将html与jsp的功能部分进行明确分工，让tomcat只处理jsp部分，其它的由apache,IIS等这些web服务器处理，由此大大节省了tomcat有限的工作“线程”。

　　4.负载均衡

　　在负载均衡的思路下，多台服务器为对称方式，每台服务器都具有同等的地位，可以单独对外提供服务而无须其他服务器的辅助。通过负载分担技术，将外部发送来的请求按一定规则分配到对称结构中的某一台服务器上，而接收到请求的服务器都独立回应客户机的请求。

　　提供服务的一组服务器组成了一个应用服务器集群(cluster)，并对外提供一个统一的地址。当一个服务请求被发至该集群时，根据一定规则选择一台服务器，并将服务转定向给该服务器承担，即将负载进行均衡分摊。

　　通过应用负载均衡技术，使应用服务超过了一台服务器只能为有限用户提供服务的限制，可以利用多台服务器同时为大量用户提供服务。当某台服务器出现故障时，负载均衡服务器会自动进行检测并停止将服务请求分发至该服务器，而由其他工作正常的服务器继续提供服务，从而保证了服务的可靠性。

　　负载均衡实现的方式大概有四种：第一是通过DNS，但只能实现简单的轮流分配，不能处理故障，第二如果是基于MS IIS，Windows 2003 server本身就带了负载均衡服务，第三是硬件方式，通过交换机的功能或专门的负载均衡设备可以实现，第四种是软件方式，通过一台负载均衡服务器进行，上面安装软件。使用Apache Httpd Server做负载平衡器，Tomcat集群节点使用Tomcat就可以做到以上第四种方式。这种方式比较灵活，成本相对也较低。另外一个很大的优点就是可以根据应用的情况和服务器的情况采取一些策略。

四. 自身调整

　　本节将向您详细介绍一些加速可使Tomcat实例加速运行的技巧和方法，无论是在什么操作系统或者何种Java虚拟机上。在有些情况下，您可能没有控制部署环境上的操作系统或者Java虚拟机。在这种情况下，您就需要逐行了解以下的的一些建议，然而你应该在修改后使之生效。我认为以下方法是Tomcat性能自身调整的最佳方式。

　　1.禁用DNS查询

　　当web应用程序向要记录客户端的信息时，它也会记录客户端的IP地址或者通过域名服务器查找机器名转换为IP地址。DNS查询需要占用网络，并且包括可能从很多很远的服务器或者不起作用的服务器上去获取对应的IP的过程，这样会消耗一定的时间。为了消除DNS查询对性能的影响我们可以关闭DNS查询，方式是修改server.xml文件中的enableLookups参数值：

Tomcat4

<Connector className="org.apache.coyote.tomcat4.CoyoteConnector" port="80" minProcessors="5" maxProcessors="75" enableLookups="false" redirectPort="8443" acceptCount="100" debug="0" connectionTimeout="20000" useURIValidationHack="false" disableUploadTimeout="true" />

Tomcat5

<Connector port="80" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" redirectPort="8443" acceptCount="100" debug="0" connectionTimeout="20000" disableUploadTimeout="true"/>

　　除非你需要连接到站点的每个HTTP客户端的机器名，否则我们建议在生产环境上关闭DNS查询功能。可以通过Tomcat以外的方式来获取机器名。这样不仅节省了网络带宽、查询时间和内存，而且更小的流量会使日志数据也会变得更少，显而易见也节省了硬盘空间。对流量较小的站点来说禁用DNS查询可能没有大流量站点的效果明显，但是此举仍不失为一良策。谁又见到一个低流量的网站一夜之间就流量大增呢？

　　2.调整线程数

　　另外一个可通过应用程序的连接器（Connector）进行性能控制的的参数是创建的处理请求的线程数。Tomcat使用线程池加速响应速度来处理请求。在Java中线程是程序运行时的路径，是在一个程序中与其它控制线程无关的、能够独立运行的代码段。它们共享相同的地址空间。多线程帮助程序员写出CPU最大利用率的高效程序，使空闲时间保持最低，从而接受更多的请求。

　　Tomcat4中可以通过修改minProcessors和maxProcessors的值来控制线程数。这些值在安装后就已经设定为默认值并且是足够使用的，但是随着站点的扩容而改大这些值。minProcessors服务器启动时创建的处理请求的线程数应该足够处理一个小量的负载。也就是说，如果一天内每秒仅发生5次单击事件，并且每个请求任务处理需要1秒钟，那么预先设置线程数为5就足够了。但在你的站点访问量较大时就需要设置更大的线程数，指定为参数maxProcessors的值。maxProcessors的值也是有上限的，应防止流量不可控制（或者恶意的服务攻击），从而导致超出了虚拟机使用内存的大小。如果要加大并发连接数，应同时加大这两个参数。web server允许的最大连接数还受制于操作系统的内核参数设置，通常Windows是2000个左右，Linux是1000个左右。

　　在Tomcat5对这些参数进行了调整，请看下表：

属性名 描述

maxThreads Tomcat使用线程来处理接收的每个请求。这个值表示Tomcat可创建的最大的线程数。

acceptCount 指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，超过这个数的请求将不予处理。

connnectionTimeout 网络连接超时，单位：毫秒。设置为0表示永不超时，这样设置有隐患的。通常可设置为30000毫秒。

minSpareThreads Tomcat初始化时创建的线程数。

maxSpareThreads 一旦创建的线程超过这个值，Tomcat就会关闭不再需要的socket线程。

　　最好的方式是多设置几次并且进行测试，观察响应时间和内存使用情况。在不同的机器、操作系统或虚拟机组合的情况下可能会不同，而且并不是所有人的web站点的流量都是一样的，因此没有一刀切的方案来确定线程数的值。

3.加速JSP编译速度

　　当第一次访问一个JSP文件时，它会被转换为Java serverlet源码，接着被编译成Java字节码。你可以控制使用哪个编译器，默认情况下，Tomcat使用使用命令行javac进行使用的编译器。也可以使用更快的编译器，但是这里我们将介绍如何优化它们。

　　另外一种方法是不要把所有的实现都使用JSP页面，而是使用一些不同的java模板引擎变量。显然这是一个跨越很大的决定，但是事实证明至少这种方法是只得研究的。如果你想了解更多有关在Tomcat可使用的模板语言，你可以参考Jason Hunter和William Crawford合著的《Java Servlet Programming 》一书（O'Reilly公司出版）。

　　在Tomcat 4.0中可以使用流行而且免费的Jikes编译器。Jikes编译器的速度要由于Sun的Java编译器。首先要安装Jikes（可访问http://oss.software.ibm.com/pub/jikes 获得更多的信息），接着需要在环境变量中设置JIKESPATH包含系统运行时所需的JAR文件。装好Jikes以后还需要设置让JSP编译servlet使用Jikes，需要修改web.xml文件中jspCompilerPlugin的值：

<servlet>
<servlet-name>jsp</servlet-name>
<servlet-class>
org.apache.jasper.servlet.JspServlet
</servlet-class>
<init-param>
<param-name>logVerbosityLevel</param-name>
<param-value>WARNING</param-value>
</init-param>
<init-param>
<param-name>jspCompilerPlugin</param-name>
<param-value>
org.apache.jasper.compiler.JikesJavaCompiler
</param-value>
</init-param>
<init-param>
<!-- <param-name>
org.apache.catalina.jsp_classpath
</param-name> -->
<param-name>classpath</param-name>
<param-value>
/usr/local/jdk1.3.1-linux/jre/lib/rt.jar:
/usr/local/lib/java/servletapi/servlet.ja
r</param-value>
</init-param>
<load-on-startup>3</load-on-startup>
</servlet>

　　在Tomcat 4.1（或更高版本），JSP的编译由包含在Tomcat里面的Ant程序控制器直接执行。这听起来有一点点奇怪，但这正是Ant有意为之的一部分，有一个API文档指导开发者在没有启动一个新的JVM的情况下，使用Ant。这是使用Ant进行Java开发的一大优势。另外，这也意味着你现在能够在Ant中使用任何javac支持的编译方式，这里有一个关于Apache Ant使用手册的javac page列表。使用起来是容易的，因为你只需要在元素中定义一个名字叫“compiler”，并且在value中有一个支持编译的编译器名字，示例如下：

<servlet>
<servlet-name>jsp</servlet-name>
<servlet-class>
org.apache.jasper.servlet.JspServlet
</servlet-class>
<init-param>
<param-name>logVerbosityLevel</param-name>
<param-value>WARNING</param-value>
</init-param>
<init-param>
<param-name>compiler</param-name>
<param-value>jikes</param-value>
</init-param>
<load-on-startup>3</load-on-startup>
</servlet>

Ant可用的编译器

名称 别名 调用的编译器

classic
javac1.1, javac1.2
Standard JDK 1.1/1.2 compiler

modern
javac1.3, javac1.4
Standard JDK 1.3/1.4 compiler

jikes 　　 The Jikes compiler

JVC Microsoft Microsoft command-line compiler from the Microsoft SDK for Java/Visual J++

KJC 　　 The kopi compiler

GCJ 　　 The gcj compiler (included as part of gcc)

SJ Symantec Symantec's Java compiler

extJavac 　　 Runs either the modern or classic compiler in a JVM of its own

　　由于JSP页面在第一次使用时已经被编译，那么你可能希望在更新新的jsp页面后马上对它进行编译。实际上，这个过程完全可以自动化，因为可以确认的是新的JSP页面在生产服务器和在测试服务器上的运行效果是一样的。

在Tomcat4的bin目录下有一个名为jspc的脚本。它仅仅是运行翻译阶段，而不是编译阶段，使用它可以在当前目录生成Java源文件。它是调试JSP页面的一种有力的手段。

　　可以通过浏览器访问再确认一下编译的结果。这样就确保了文件被转换成serverlet，被编译了可直接执行。这样也准确地模仿了真实用户访问JSP页面，可以看到给用户提供的功能。也抓紧这最后一刻修改出现的bug并且修改它J

　　Tomcat提供了一种通过请求来编译JSP页面的功能。例如，你可以在浏览器地址栏中输入http://localhost:8080/exa......ate.jsp?jsp_precompile=true，这样Tomcat就会编译data.jsp而不是执行它。此举唾手可得，不失为一种检验页面正确性的捷径。

　　4. 其它

　　前面我们提到过操作系统通过一些限制手段来防止恶意的服务攻击，同样Tomcat也提供了防止恶意攻击或禁止某些机器访问的设置。

　　Tomcat提供了两个参数供你配置：RemoteHostValve 和RemoteAddrValve。

　　通过配置这两个参数，可以让你过滤来自请求的主机或IP地址，并允许或拒绝哪些主机/IP。与之类似的，在Apache的httpd文件里有对每个目录的允许/拒绝指定。

　　例如你可以把Admin Web application设置成只允许本地访问，设置如下：

<Context path="/path/to/secret_files" ...>
<Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127.0.0.1" deny=""/>
</Context>

　　如果没有给出允许主机的指定，那么与拒绝主机匹配的主机就会被拒绝，除此之外的都是允许的。与之类似，如果没有给出拒绝主机的指定，那么与允许主机匹配的主机就会被允许，除此之外的都是拒绝的。

五. 容量计划

　　容量计划是在生产环境中使用Tomcat不得不提的提高性能的另一个重要的话题。如果你没有对预期的网络流量下的硬件和带宽做考虑的话那么无论你如何做配置修改和测试都无济于事。

　　这里先对提及的容量计划作一个简要的定义：容量计划是指评估硬件、操作系统和网络带宽，确定应用服务的服务范围，寻求适合需求和软件特性的软硬件的一项活动。因此这里所说的软件不仅包括Tomcat，也包括与Tomcat结合使用的任何第三方web服务器软件。

　　如果在购买软硬件或部署系统前你对容量计划一无所知，不知道现有的软硬件环境能够支撑多少的访问量，甚至更糟直到你已经交付并且在生产环境上部署产品后才意识到配置有问题时再进行变更可能为时已晚。此时只能增加硬件投入，增加硬盘容量甚至购买更好的服务器。如果事先做了容量计划那么就不会搞的如此焦头烂额了。

　　我们这里只介绍与Tomcat相关的内容。

　　首先为了确定Tomcat使用机器的容量计划，你应该从一下列表项目种着手研究和计划：

　　1. 硬件

　　采用什么样的硬件体系？需要多少台计算机？使用一个大型的，还是使用多台小型机？每个计算机上使用几个CPU？使用多少内存？使用什么样的存储设备，I/O的处理速度有什么要求？怎样维护这些计算机？不同的JVM在这些硬件上运行的效果如何（比如IBM AIX系统只能在其设计的硬件系统上运行）？

　　2. 网络带宽

　　带宽的使用极限是多少？web应用程序如何处理过多的请求？

　　3. 服务端操作系统

　　采用哪种操作系统作为站点服务器最好？在确定的操作系统上使用哪个JVM最好？例如，JVM在这种系统上是否支持本地多线程，对称多处理？哪种系统可使web服务器更快、更稳定，并且更便宜。是否支持多CPU？

4. Tomcat容量计划

　　以下介绍针对Tomcat做容量计划的步骤：

　　1） 量化负载。如果站点已经建立并运行，可以使用前面介绍的工具模仿用户访问，确定资源的需求量。

　　2）针对测试结果或测试过程中进行分析。需要知道那些请求造成了负载过重或者使用过多的资源，并与其它请求做比较，这样就确定了系统的瓶颈所在。例如：如果servlet在查询数据库的步骤上耗用较长的时间，那么就需要考虑使用缓冲池来降低响应时间。

　　3）确定性能最低标准。例如，你不想让用户花20秒来等待结果页面的返回，也就是说甚至在达到访问量的极限时，用户等待的时间也不能超过20秒种（从点击链接到看到返第一条返回数据）。这个时间中包含了数据库查询时间和文件访问时间。同类产品性能在不同的公司可能有不同的标准，一般最好采取同行中的最低标准或对这个标准做出评估。

　　4）确定如何合理使用底层资源，并逐一进行测试。底层资源包括CPU、内存、存储器、带宽、操作系统、JVM等等。在各种生产环境上都按顺序进行部署和测试，观察是否符合需求。在测试Tomcat时尽量多采用几种JVM，并且调整JVM使用内存和Tomcat线程池的大小进行测试。同时为了达到资源充分合理稳定地使用的效果，还需针对测试过程中出现的硬件系统瓶颈进行处理确定合理的资源配置。这个过程最为复杂，而且一般由于没有可参考的值所以只能靠理论推断和经验总结。

1.网站失效,内存溢出
2.不断增加会话,导致内存不够分配(oracle9i)
3.页面加载的信息过大
4.查询信息量过大
5.多人同时操作速度逐渐为慢
直到成功获得请求为止
6.无效的请求,要请求多次才能成功获得返回的页面
7.负载测试
8.图片和文字没有分别建立在不同的服务器中
9.反复点击速度慢的链接
10.利用测试工具进行测试测试
11.监测数据库的session
12.功能测试(文字摆放,错误的布局,放在网页上不能用的内容)
13.非常规及反复操作(新增,取消,下一页,返回上一页,后退,刷新)
14.熟悉不同IE的设置
15.熟悉不同的操作系统
16.环境配置是否一致
17.IE是否代理上网
18.是否远程连接进行上网操作
19.速度优化
20.系统有默认设置和个性化设置
21.用户登录后,是否有检测机制?何时退出,何时踢出该用户?
22.cookies机制和session机制
23.单据或内容是否有重复或冗余数据
24.不同测试人员或开发人员可能不同的观点或角度
25.网上测试网站或论坛不同的测试方法
26.了解开发环境或配置
27.用户常用操作及其可操作性
28.测试工具的运用(不要太依赖工具而测试,要有自己的思路)
29.页面字段丢失或缺少,导致页面访问出错
30.字段是否唯一,是否建立索引,是否可删除数据
31.共用基础资料:是否可删除或添加,可分配哪些用户使用,是否可扩展
32.测试的不同情形(参考,列表,单据,树+列表,过滤信息,查询,动态查询,
处理过程,交叉报表,图形报表)尽可能文字写下来,对照比较
33.系统升级问题:是否在原有基础上升级还是拿最新的数据库过来后更改数据表后,再反复测试;
(尽可能满足不同人员的要求和测试点也尽可能多)
34.数据是否及时更新
35.权限分配是否合理(不同工作组,不同用户设置)

磁盘已满　

导致系统无法正常运行的最可能的原因是磁盘已满。一个好的网络管理员会密切关注磁盘的使用情况，隔一定的时间，就需要将磁盘上的一些负载转存到备份存储介质中（例如磁带）。

日志文件会很快用光所有的磁盘空间。Web服务器的日志文件、SQL*Net的日志文件、JDBC日志文件，以及应用程序服务器日志文件均与内存泄漏有同等的危害。可以采取措施将日志文件保存在与操作系统不同的文件系统中。日志文件系统空间已满时Web服务器也会被挂起，但机器自身被挂起的几率已大大减低。

C指针错误

用C或C++编写的程序，如Web服务器API模块，有可能导致系统的崩溃，因为只要间接引用指针（即，访问指向的内存）中出现一个错误，就会导致操作系统终止所有程序。另外，使用了糟糕的C指针的Java模拟量（analog）将访问一个空的对象引用。Java中的空引用通常不会导致立刻退出JVM，但是前提是程序员能够使用异常处理方法恰当地处理错误。在这方面，Java无需过多的关注，但使用Java对可靠性进行额外的度量则会对性能产生一些负面影响。

内存泄漏

C/C++程序还可能产生另一个指针问题：丢失对已分配内存的引用。当内存是在子程序中被分配时，通常会出现这种问题，其结果是程序从子程序中返回时不会释放内存。如此一来，对已分配的内存的引用就会丢失，只要操作系统还在运行中，则进程就会一直使用该内存。这样的结果是，曾占用更多的内存的程序会降低系统性能，直到机器完全停止工作，才会完全清空内存。

解决方案之一是使用代码分析工具（如Purify）对代码进行仔细分析，以找出可能出现的泄漏问题。但这种方法无法找到由其他原因引起的库中的泄漏，因为库的源代码是不可用的。另一种方法是每隔一段时间，就清除并重启进程。Apache的Web服务器就会因这个原因创建和清除子进程。

虽然Java本身并无指针，但总的说来，与C程序相比， Java程序使用内存的情况更加糟糕。在Java中，对象被频繁创建，而直到所有到对象的引用都消失时，垃圾回收程序才会释放内存。即使运行了垃圾回收程序，也只会将内存还给虚拟机VM，而不是还给操作系统。结果是：Java程序会用光给它们的所有堆，从不释放。由于要保存实时（Just In Time，JIT）编译器产生的代码，Java程序的大小有时可能会膨胀为最大堆的数倍之巨。

还有一个问题，情况与此类似。从连接池分配一个数据库连接，而无法将已分配的连接还回给连接池。一些连接池有活动计时器，在维持一段时间的静止状态之后，计时器会释放掉数据库连接，但这不足以缓解糟糕的代码快速泄漏数据库连接所造成的资源浪费。

进程缺乏文件描述符

如果已为一台Web服务器或其他关键进程分配了文件描述符，但它却需要更多的文件描述符，则服务器或进程会被挂起或报错，直至得到了所需的文件描述符为止。文件描述符用来保持对开放文件和开放套接字的跟踪记录，开放文件和开放套接字是Web服务器很关键的组成部分，其任务是将文件复制到网络连接。默认时，大多数shell有64个文件描述符，这意味着每个从shell启动的进程可以同时打开64个文件和网络连接。大多数shell都有一个内嵌的 ulimit命令可以增加文件描述符的数目。

线程死锁

由多线程带来的性能改善是以可靠性为代价的，主要是因为这样有可能产生线程死锁。线程死锁时，第一个线程等待第二个线程释放资源，而同时第二个线程又在等待第一个线程释放资源。我们来想像这样一种情形：在人行道上两个人迎面相遇，为了给对方让道，两人同时向一侧迈出一步，双方无法通过，又同时向另一侧迈出一步，这样还是无法通过。双方都以同样的迈步方式堵住了对方的去路。假设这种情况一直持续下去，这样就不难理解为何会发生死锁现象了。

解决死锁没有简单的方法，这是因为使线程产生这种问题是很具体的情况，而且往往有很高的负载。大多数软件测试产生不了足够多的负载，所以不可能暴露所有的线程错误。在每一种使用线程的语言中都存在线程死锁问题。由于使用Java进行线程编程比使用C容易，所以Java程序员中使用线程的人数更多，线程死锁也就越来越普遍了。可以在Java代码中增加同步关键字的使用，这样可以减少死锁，但这样做也会影响性能。如果负载过重，数据库内部也有可能发生死锁。

如果程序使用了永久锁，比如锁文件，而且程序结束时没有解除锁状态，则其他进程可能无法使用这种类型的锁，既不能上锁，也不能解除锁。这会进一步导致系统不能正常工作。这时必须手动地解锁。

服务器超载

Netscape Web服务器的每个连接都使用一个线程。Netscape Enterprise Web服务器会在线程用完后挂起，而不为已存在的连接提供任何服务。如果有一种负载分布机制可以检测到服务器没有响应，则该服务器上的负载就可以分布到其它的Web服务器上，这可能会致使这些服务器一个接一个地用光所有的线程。这样一来，整个服务器组都会被挂起。操作系统级别可能还在不断地接收新的连接，而应用程序（Web服务器）却无法为这些连接提供服务。用户可以在浏览器状态行上看到connected（已连接）的提示消息，但这以后什么也不会发生。

解决问题的一种方法是将obj.conf参数RqThrottle的值设置为线程数目之下的某个数值，这样如果越过 RqThrottle的值，就不会接收新的连接。那些不能连接的服务器将会停止工作，而连接上的服务器的响应速度则会变慢，但至少已连接的服务器不会被挂起。这时，文件描述符至少应当被设置为与线程的数目相同的数值，否则，文件描述符将成为一个瓶颈。

数据库中的临时表不够用

许多数据库的临时表（cursor）数目都是固定的，临时表即保留查询结果的内存区域。在临时表中的数据都被读取后，临时表便会被释放，但大量同时进行的查询可能耗尽数目固定的所有临时表。这时，其他的查询就需要列队等候，直到有临时表被释放时才能再继续运行。

这是一个不容易被程序员发觉的问题，但会在负载测试时显露出来。但可能对于数据库管理员（DataBase Administrator，DBA）来说，这个问题十分明显。

此外，还存在一些其他问题：设置的表空间不够用、序号限制太低，这些都会导致表溢出错误。这些问题表明了一个好的DBA对用于生产的数据库设置和性能进行定期检查的重要性。而且，大多数数据库厂商也提供了监控和建模工具以帮助解决这些问题。

另外，还有许多因素也极有可能导致Web站点无法工作。如：相关性、子网流量超载、糟糕的设备驱动程序、硬件故障、包括错误文件的通配符、无意间锁住了关键的表。

5种方法快速定位对方IP
与好友在网络上相互传输资料时，有时先要知道对方计算机的IP地址，才能与对方建立信息传输通道。
　
　　那么对方的IP地址该如何搜查得到呢？这样的问题你也许会嗤之以鼻，的确，查询对方计算机的IP地址，实在简单得不值得一提；可是，要让你列举出多种IP地址搜查方法时，你可能就感到勉为其难了。下面，本文就对如何快速、准确地搜查出对方好友的计算机IP地址，提出如下几种方法，相信能对大家 有所帮助！
　
　　1、邮件查询法
　
　　使用这种方法查询对方计算机的IP地址时，首先要求对方先给你发一封电子邮件，然后你可以通过查看该邮件属性的方法，来获得邮件发送者所在计算机的IP地址；下面就是该方法的具体实施步骤：
　
　　首先运行OutLook express程序，并单击工具栏中的“接受全部邮件”按钮，将朋友发送的邮件接受下来，再打开收件箱页面，找到朋友发送过来的邮件，并用鼠标右键单击之，从弹出的右键菜单中，执行“属性”命令；
　
　　在其后打开的属性设置窗口中，单击“详细资料”标签，并在打开的标签页面中，你将看到“Received： from xiecaiwen （unknown [11.111.45.25]）”这样的信息，其中的“11.111.45.25”就是对方好友的IP地址；当然，要是对方好友通过Internet中的 WEB信箱给你发送电子邮件的话，那么你在这里看到的IP地址其实并不是他所在工作站的真实IP地址，而是WEB信箱所在网站的IP地址。
　
　　当然，如果你使用的是其他邮件客户端程序的话，查看发件人IP地址的方法可能与上面不一样；例如要是你使用foxmail来接受好友邮件的话，那么你可以在收件箱中，选中目标邮件，再单击菜单栏中的“邮件”选项，从弹出的下拉菜单中选中“原始信息”命令，就能在其后的界面中看到对方好友的IP地址了。
　
　　2、日志查询法
　
　　这种方法是通过防火墙来对QQ聊天记录进行实时监控，然后打开防火墙的日志记录，找到对方好友的IP地址。为方便叙述，本文就以KV2004防火墙为例，来向大家介绍一下如何搜查对方好友的IP地址：
　
　　考虑到与好友进行QQ聊天是通过UDP协议进行的，因此你首先要设置好KV防火墙，让其自动监控UDP端口，一旦发现有数据从UDP端口进入的话，就将它自动记录下来。在设置KV2004防火墙时，先单击防火墙界面中的“规则设置”按钮，然后单击“新建规则”按钮，弹出设置窗口；
　
　　在该窗口的“名称”文本框中输入“搜查IP地址”，在“说明”文本框中也输入“搜查IP地址”；再在“网络条件”设置项处，选中“接受数据包”复选框，同时将“对方IP地址”设置为“任何地址”，而在“本地IP地址”设置项处不需要进行任何设置；
　
　　下面再单击“UDP”标签，并在该标签页面下的“本地端口”设置项处，选中“端口范围”选项，然后在起始框中输入“0”，在结束框中输入“65535”；同样地，在“对方端口”设置项处，也选中“端口范围”选项，然后在起始框中输入“0”，在结束框中输入“65535”。
　
　　接着在“当所有条件满足时”设置项处，选中“通行”选项，同时将“其他处理”处的“记录”选项选中，而“规则对象”设置项不需要进行任何设置；完成了上面的所有设置后，单击“确定”按钮，返回到防火墙的主界面；再在主界面中选中刚刚创建好的“搜查IP地址”规则，同时单击“保存”按钮，将前面的设置保存下来。
　
　　完成好上面的设置后，KV防火墙将自动对QQ聊天记录进行全程监控，一旦对方好友给你发来QQ信息时，那么对方好友的IP地址信息就会自动出现在防火墙的日志 。

　　3、工具查询法。
　
　　这种方法是通过专业的IP地址查询工具，来快速搜查到对方计算机的IP地址。例如，借助一款名为whereIsIP的搜查工具，你可以轻松根据对方好友的 Web网站地址，搜查得到对方好友的IP地址，甚至还能搜查到对方好友所在的物理位置。在用whereIsIP程序搜查对方IP地址时，首先启动该程序打开搜查界面，然后单击该界面的“Web site”按钮，在其后的窗口中输入对方好友的Web地址，再单击“next”按钮，这样该程序就能自动与Internet中的Domain Name Whois数据库联系，然后从该数据库中搜查到与该Web网站地址对应的IP地址了。当然，除了可以知道IP地址外，你还能知道对方好友所在的具体物理位置。
　
　　倘若要想查看局域网中某个工作站的IP地址时，可以使用“网络刺客II”之类的工具来帮忙；只要你运行该工具进入到它的主界面，然后执行工具栏中的“IP地址<->主机名”命令，在其后打开的对话框中，输入对方好友的计算机名称，再单击“转换成IP”按钮，就能获得对方好友所在计算机的IP地址了。
　
　　如果你使用Oicqsniffer工具的话，那么查询QQ好友的IP地址就更简单了。只要你单击该程序界面中的“追踪”按钮，然后向对方好友发送一条QQ消息，那么Oicqsniffer工具就会自动将对方好友的IP地址以及端口号显示出来了。除此之外，还有许多可以查找IP地址的专业工具可以选择，例如IPsniper软件。
　
　　4、命令查询法
　
　　这种方法是通过Windows系统内置的网络命令“netstat”，来查出对方好友的IP地址，不过该方法需要你先想办法将对方好友邀请到QQ的“二人世界”中说上几句话才可以。下面就是该方法的具体实现步骤：。
　
　　首先单击“开始”/“运行”命令，在弹出的系统运行对话框中，输入“cmd”命令，单击“确定”按钮后，将屏幕切换到MS-DOS工作状态；然后在DOS命令行中执行“netstat -n”命令，在弹出的界面中，你就能看到当前究竟有哪些地址已经和你的计算机建立了连接（如果对应某个连接的状态为“Established”，就表明你的计算机和对方计算机之间的连接是成功的）；。
　
　　其次打开QQ程序，邀请对方好友加入“二人世界”，并在其中与朋友聊上几句，这样你的计算机就会与对方好友的计算机之间建立好了TCP连接；此时，再在DOS命令行中执行“netstat -n”命令，看看现在又增加了哪个tcp连接，那个新增加的连接其实就是对方好友与你之间的UDP连接，查看对应连接中的“Foreign Address”就能知道对方好友的IP地址了。
　
　　5、ping检查法
　
　　这种方法就是利用“ping”命令，来检查当前计算机是否能与对方好友的网站连通，在检查的过程中该地址能自动获得对方网站的IP地址。比方说，要是你想搜查天极网站的IP地址时，可以先打开系统的运行对话框，然后在其中输入“pingwww.pconline.com.cn”字符串命令，再单击“确定”按钮，在弹出的窗口中，就能知道网站的IP地址了。同样地，你也可以搜查其他网站的IP地址。

Web系统有多少安全漏洞

Internet的开放性使得Web系统面临入侵攻击的威胁，而建立一个安全的Web系统一直是人们的目标。一个实用的方法是，建立比较容易实现的相对安全的系统，同时按照一定的安全策略建立相应的安全辅助系统，漏洞扫描器就是这样一类安全辅助系统。

　　漏洞扫描就是对计算机系统或者其他网络设备进行安全相关的检测，以找出安全隐患和可被黑客利用的漏洞。作为一种保证Web信息系统和网络安全必不可少的手段，我们有必要仔细研究利用。值得注意的是，漏洞扫描软件是把双刃剑，黑客利用它入侵系统，而系统管理员掌握它以后又可以有效的防范黑客入侵。

　　四种漏洞扫描技术

　　漏洞扫描通常采用两种策略，第一种是被动式策略，第二种是主动式策略。所谓被动式策略就是基于主机之上，对系统中不合适的设置、脆弱的口令以及其他与安全规则抵触的对象进行检查;而主动式策略是基于网络的，它通过执行一些脚本文件模拟对系统进行攻击的行为并记录系统的反应，从而发现其中的漏洞。利用被动式策略的扫描称为系统安全扫描，利用主动式的策略扫描称为网络安全扫描。

　　漏洞扫描有以下四种检测技术：

　　1.基于应用的检测技术。它采用被动的、非破坏性的办法检查应用软件包的设置，发现安全漏洞。

　　2.基于主机的检测技术。它采用被动的、非破坏性的办法对系统进行检测。通常，它涉及到系统的内核、文件的属性、操作系统的补丁等。这种技术还包括口令解密、把一些简单的口令剔除。因此，这种技术可以非常准确地定位系统的问题，发现系统的漏洞。它的缺点是与平台相关，升级复杂。

　　3.基于目标的漏洞检测技术。它采用被动的、非破坏性的办法检查系统属性和文件属性，如数据库、注册号等。通过消息文摘算法，对文件的加密数进行检验。这种技术的实现是运行在一个闭环上，不断地处理文件、系统目标、系统目标属性，然后产生检验数，把这些检验数同原来的检验数相比较。一旦发现改变就通知管理员。

　　4.基于网络的检测技术。它采用积极的、非破坏性的办法来检验系统是否有可能被攻击崩溃。它利用了一系列的脚本模拟对系统进行攻击的行为，然后对结果进行分析。它还针对已知的网络漏洞进行检验。网络检测技术常被用来进行穿透实验和安全审记。这种技术可以发现一系列平台的漏洞，也容易安装。但是，它可能会影响网络的性能。

　　网络漏洞扫描

　　在上述四种方式当中，网络漏洞扫描最为适合我们的Web信息系统的风险评估工作，其扫描原理和工作原理为：通过远程检测目标主机TCP/IP不同端口的服务，记录目标的回答。通过这种方法，可以搜集到很多目标主机的各种信息(例如：是否能用匿名登录，是否有可写的FTP目录，是否能用Telnet，httpd是否是用root在运行)。

　　在获得目标主机TCP/IP端口和其对应的网络访问服务的相关信息后，与网络漏洞扫描系统提供的漏洞库进行匹配，如果满足匹配条件，则视为漏洞存在。此外，通过模拟黑客的进攻手法，对目标主机系统进行攻击性的安全漏洞扫描，如测试弱势口令等，也是扫描模块的实现方法之一。如果模拟攻击成功，则视为漏洞存在。

　　在匹配原理上，网络漏洞扫描器采用的是基于规则的匹配技术，即根据安全专家对网络系统安全漏洞、黑客攻击案例的分析和系统管理员关于网络系统安全配置的实际经验，形成一套标准的系统漏洞库，然后再在此基础之上构成相应的匹配规则，由程序自动进行系统漏洞扫描的分析工作。

　　所谓基于规则是基于一套由专家经验事先定义的规则的匹配系统。例如，在对TCP80端口的扫描中，如果发现/cgi-bin/phf/cgi-bin/Count.cgi，根据专家经验以及CGI程序的共享性和标准化，可以推知该WWW服务存在两个CGI漏洞。同时应当说明的是，基于规则的匹配系统有其局限性，因为作为这类系统的基础的推理规则一般都是根据已知的安全漏洞进行安排和策划的，而对网络系统的很多危险的威胁是来自未知的安全漏洞，这一点和PC杀毒很相似。

　　这种漏洞扫描器是基于浏览器/服务器(B/S)结构。它的工作原理是：当用户通过控制平台发出了扫描命令之后，控制平台即向扫描模块发出相应的扫描请求，扫描模块在接到请求之后立即启动相应的子功能模块，对被扫描主机进行扫描。通过分析被扫描主机返回的信息进行判断，扫描模块将扫描结果返回给控制平台，再由控制平台最终呈现给用户。

　　另一种结构的扫描器是采用插件程序结构。可以针对某一具体漏洞，编写对应的外部测试脚本。通过调用服务检测插件，检测目标主机TCP/IP不同端口的服务，并将结果保存在信息库中，然后调用相应的插件程序，向远程主机发送构造好的数据，检测结果同样保存于信息库，以给其他的脚本运行提供所需的信息，这样可提高检测效率。如，在针对某FTP服务的攻击中，可以首先查看服务检测插件的返回结果，只有在确认目标主机服务器开启FTP服务时，对应的针对某FTP服务的攻击脚本才能被执行。采用这种插件结构的扫描器，可以让任何人构造自己的攻击测试脚本，而不用去了解太多扫描器的原理。这种扫描器也可以用做模拟黑客攻击的平台。采用这种结构的扫描器具有很强的生命力，如著名的Nessus就是采用这种结构。这种网络漏洞扫描器的结构如图2所示，它是基于客户端/服务器(C/S)结构，其中客户端主要设置服务器端的扫描参数及收集扫描信息。具体扫描工作由服务器来完成。漏洞扫描器的发展趋势

　　值得我们注意的是漏洞扫描软件从最初的专门为UNIX系统编写的一些只具有简单功能的小程序，发展到现在，已经出现了多个运行在各种操作系统平台上的、具有复杂功能的商业程序。今后的发展趋势主要有以下几点，我们可以根据实际Web信息系统风险评估的需求进行选用：

　　1.使用插件或者叫做功能模块技术。每个插件都封装一个或者多个漏洞的测试手段，主扫描程序通过调用插件的方法来执行扫描。仅仅是添加新的插件就可以使软件增加新功能，扫描更多漏洞。在插件编写规范公布的情况下，用户或者第三方公司甚至可以自己编写插件来扩充软件的功能。同时这种技术使软件的升级维护都变得相对简单，并具有非常强的扩展性。

　　2.使用专用脚本语言。这其实就是一种更高级的插件技术，用户可以使用专用脚本语言来扩充软件功能。这些脚本语言语法通常比较简单易学，往往用十几行代码就可以定制一个简单的测试，为软件添加新的测试项。脚本语言的使用，简化了编写新插件的编程工作，使扩充软件功能的工作变得更加容易，也更加有趣。

　　3.由漏洞扫描程序到安全评估专家系统。最早的漏洞扫描程序只是简单地把各个扫描测试项的执行结果罗列出来，直接提供给测试者而不对信息进行任何分析处理。而当前较成熟的扫描系统都能够将对单个主机的扫描结果整理，形成报表，能够并对具体漏洞提出一些解决方法。不足之处是对网络的状况缺乏一个整体的评估，对网络安全没有系统的解决方案。未来的安全扫描系统，应该不但能够扫描安全漏洞，还能够智能化地协助网络信息系统管理人员评估本网络的安全状况，给出安全建议，成为一个安全评估专家系统。

　　Web系统的风险等级评估

　　在实现了对Web信息系统的安全扫描后，便可根据扫描结果，对Web信息系统的安全性能进行评估，从而给出Web信息系统的风险状况。这里，风险评估的依据是根据扫描结果，根据Web信息系统所具有的漏洞数目及漏洞的危害程度，将Web信息系统的安全状态进行分级。

　　划分的风险评估级别如下：

　　l.A级：扫描结果显示没有漏洞，但这并不表明系统没有漏洞，因为有许多漏洞是尚未发现的，我们只能针对已知的漏洞进行测试。

　　2.B级：具有一些泄漏服务器版本信息之类的不是很重要内容的漏洞，或者提供容易造成被攻击的服务，如允许匿名登录，这种服务可能会造成许多其它漏洞。

　　3.C级：具有危害级别较小的一些漏洞，如可以验证某账号的存在，可以造成列出一些页面目录、文件目录等，不会造成严重后果的漏洞。

　　4.D级：具有一般的危害程度的漏洞。如拒绝服务漏洞,造成Web信息系统不能正常工作;可以让黑客获得重要文件的访问权的漏洞等。

　　5.E级：具有严重危害程度的漏洞。如存在缓冲区溢出漏洞，存在木马后门，存在可以让黑客获得根用户权限或根用户的shell漏洞,根目录被设置一般用户可写等一些后果非常严重的漏洞。

　　另外，我们需要强调的是：漏洞的产生主要源于Web信息系统的不正当配置以及其提供的服务自身的弱点。前面我们详细介绍了如何使用漏洞扫描来进行风险评估。其实还有一个非常重要的问题我们不能忽略，那就是需要检测Web信息系统到底提供了哪些服务，因为它直接关系到系统的漏洞的产生以及危害。一方面，Web信息系统为用户提供了多种优质的网络服务，包括Http、Ftp、Smtp、Pop3等;另一方面，服务的增多意味着更多的风险。每种服务本身都必然存在着某些缺陷，而这些缺陷很有可能被高明的黑客利用来对系统进行攻击。所以，提供特定服务的服务器应该尽可能开放提供服务必不可少的端口，而将与服务器服务无关的服务关闭，比如：一台作为www和ftp服务器的机器，应该只开放80和25端口，而将其他无关的服务如关掉，以减少系统漏洞。

　　因此，我们需要针对Web系统的实际用途使用相关的工具来对系统开放的网络服务及其端口等进行有效地检测和适时的处理，以及时关闭那些不必需要的服务和端口，以免为黑客和不法用户利用，从而侵入信息系统。显然，这是一项非常艰巨和长期的工作，管理者们需要在技术和管理两个层面上投入相当的物力和财力，从而保证Web信息系统的安全性

一.遇到的奇怪问题:
1.在开发人员环境中模拟不到该问题;
2.将升级包拿到另一个测试环境中可以模拟该问题;
3.将相同的升级包放到自己的测试环境中也不能模拟该问题;
结论:该升级包没有问题,只是环境配置没有和开发人员的环境一样,重新安装tomcat和JDK,问题得以解决;

二.菜单没有显示出来,
将升级包放到任何一个环境中都看不到该菜单节点,经过自己想到升级之前,是不是哪个文件没有和开发人员更换,
原来只是配置文件NewArches有个菜单上是否显示出来的区别;(要留心开发人员的升级包是否一致)

三.数据过滤问题:
1.条件不满足;
2.数据过滤出来的信息太多;
3.数据过滤出来的信息太少;
4.数据过滤有重复的数据;
5.参考没有参考数据;
6.数据唯一性问题;
7.数据丢失;
8.数据锁定;(期间结账,财务结账)
9.删除数据能否再恢复数据;

三.界面展示问题:
1.是否用户需要这样的界面;
2.客户习惯性操作;
3.逆向思维;(不同的操作,可能引起不同的错误);穷举是不切实际的,只能想好的用例,按照用例来测试;
4.多层页面操作比较难控制,建议尽量少用;
5.网络延时;(网络速度慢,页面响应不过来,页面出现错误没有提示,内存或代码溢出;)
6.缺少字段导致页面出现错误;
7.页面多一些字段和少一些字段都会信息不完整性;
8.节点越多分支,测试越困难,出现的错误也越大;
9.页面显示的信息不对;(刷新问题,程序出错,页面没有跳转)

四.速度问题:
1.存储过程引起的速度慢问题;
2.SQL语句没有优化引起的速度问题;
3.界面加载的数据量太大,导致速度慢;
4.另外用户操作出现错误,程序没有处理,导致另外一个用户速度慢;
5.网络速度慢,数据库优化,电脑配置问题;

五.错误:
1.经常出现代码错误,但不影响操作;
2.错误不可重现,多数原因:环境没有满足得到;
3.经常出现错误,暂不能解决,会导致用户对软件没有信心;
4.错误跟踪:最好知道产生该错误的原因,可以在下次操作时想到更好的用例;
5.给出的错误提示信息不对;
6.令用户不能再进行操作,只能退出系统重新进入
7.在同一个测试点,运用不同的测试方法,会发现更多的错误;
8.要传递的值没有传送到页面上;
9.输入框没有阻止非法的操作信息;
10.业务逻辑思维不能满足用户操作;(入库日期大于出库日期,出库数量多于入库数量,
仓库有数量,但不能录入系统中来,可设置调整单;
11.内存溢出错误;
12.自动退出系统;
13重新进入系统,加载的信息是否正确;
14.数据库错误,不能连接数据库;
15.树节点错误,列表错误,

六.操作:
1.删除记录,参考是否可以再带出来;
2.作废单据,系统是怎样操作;
3.确定,取消操作;
4.退格键;
5.价格版本是否执行正确的价格来更新产品价格;
6.功能是否满足以后扩展;
7.是否用户方便查询数据,关联报表,关联列表,关联单据明细,生产单号的关联问题;
8.单据序号的唯一性和连续性;
9.单据编号的唯一性;客户的单据编号要通用性和可索引性,最好有一定规律;
10.用户更改或删除基础资料,能否导致业务数据丢失,数据更改,没有逻辑性?
11.不同用户或工作组,可根据自己的权限,看到自己的数据信息,并且没有冲突和错乱;
12.报表打印样式是否正确;
13.IE的常用工具栏和快捷方式,不同IE的测试;
14.环境配置和测试;
15.多用户操作,并发操作,性能测试;
16.每个用户账号对应一个网卡地址;

软件工程师不可不知的10个概念
   出色的软件工程师善用设计模式，勤于代码重构，编写单元测试，并对简单有宗教般的追求。除了这些，优秀的软件工程师还要通晓10个概念，这10个概念超越了编程语言与设计模式，软件工程师应当从更广的范围内明白这些道理。

1. 关系数据库 (Relational Databases)
关系数据库因为在大规模 Web 服务上缺乏可扩充性而颇受微词，然而，关系数据库仍然是近20年来计算机技术中最伟大的成就。关系数据库对处理订单，公司数据方面有着出色的表现。

关系数据库的核心是以记录表示数据，记录存放在数据库表，数据库使用查询语言（SQL）对数据进行搜索与查询，同时，数据库对各个数据表进行关联。

数据库的标准化技术（normalization）讲的是使用正确的方式对数据进行分存以降低冗余，并加快存取速度。
 
2. 安全 （Security）
随着黑客的崛起与数据敏感性的上升，安全变得非常重要。安全是个广义的概念，涉及验证，授权与信息传输。

验证是对用户的身份进行检查，如要求用户输入密码。验证通常需要结合 SSL （secure socket layer）进行；授权在公司业务系统中非常重要，尤其是一些工作流系统。最近开发的 OAuth 协议可以帮助 Web 服务将相应信息向相应用户开放。Flickr 便使用这种方式管理私人照片和数据的访问权限。

另外一个安全领域是网络设防，这关系到操作系统，配置与监控。不仅网络危险重重，任何软件都是。Firefox 被称为最安全的浏览器，仍然需要频频发布安全补丁。要为你的系统编写安全代码就需要明白各种潜在的问题。
 
3. 云计算 （Cloud Computing）
RWW 最近的关于云计算的文章 Reaching For The Sky Through Compute Clouds 讲到了云计算如何改变大规模 Web 应用的发布。大规模的并行，低成本，与快速投入市场。

并行算法发明以来，首先迎来的是网格计算，网格计算是借助空闲的桌面计算机资源进行并行计算。最著名的例子是 Berkley 大学的 SETI@home 计划，该计划使用空闲的 CPU 资源分析太空数据。金融机构也大规模实施网格计算进行风险分析。空闲的资源，加上 J2EE 平台的崛起，迎来了云计算的概念：应用服务虚拟化。就是应用按需运行，并可以随着时间和用户规模而实时改变。

云计算最生动的例子是 Amazon 的 Web 服务，一组可以通过 API 进行调用的应用，如云服务（EC2），一个用来存储大型媒体文件的数据库（S3），索引服务（SimpleDB），序列服务（SQS）。

4. 并发 （Concurrency）
并发是软件工程师最容易犯错的地方，这可以理解，因为我们一直遵从线形思维，然而并发在现代系统中非常重要。

并发是程序中的并行处理，多数现代编程语言包含内置的并发能力，在 Java，指的是线程。关于并发，最经典的例子是“生产/消费”模式，生产方生产数据和任务，并放入工作线程消费或执行。并发的复杂性在于，线程需要经常访问共同数据，每个线程都有自己的执行顺序，但需要访问共同数据。Doug Lea 曾写过一个最复杂的并发类，现在是 core Java 的一部分。

5. 缓存（Caching）
缓存对现代 Web 程序不可或缺，缓存是从数据库取回，并存放在内存中的数据。因为数据库直接存取的代价非常高，将数据从数据库取回并放在缓存中访问就变得十分必要。比如，你有一个网站，要显示上周的畅销书，你可以从数据将畅销书榜一次性取回放在缓存中，而不必在每次访问时都去数据库读数据。

缓存需要代价，只有最常用的内容才可以放入缓存。很多现代程序，包括 Facebook，依靠一种叫做 Memcached 的分布式缓存系统，该系统是 Brad Firzpatrick 在工作于 LiveJournal 项目时开发的，Memcached 使用网络中空闲的内存资源建立缓存机制，Memcached 类库在很多流行编程语言，包括 Java 和 PHP 中都有。

6. 散列法（Hashing）
Hashing 的目的是加速访问速度。如果数据是序列存储的，从中查询一个项的时间取决于数据列的大小。而散列法对每一个项计算一个数字作为索引，在一个好的 Hashing 算法下，数据查找的速度是一样的。

除了存储数据，散列法对分布式系统也很重要。统一散列法（uniform hash ）用来在云数据库环境下，在不同计算机之间分存数据。Google 的索引服务就是这种方法的体现，每一个 URL 都被散列分布到特定计算机。

散列函数非常复杂，但现代类库中都有现成的类，重要的是，如何对散列法进行细调以获得最好的性能。

7. 算法的复杂性 （Algorithmic Complexity）
关于算法的复杂性，软件工程师需要理解这样几件事。第一，大O标记法（big O notation）；第二，你永远都不应该使用嵌套式循环（循环里面套循环），你应该使用 Hash 表，数组或单一循环；第三，如今优秀类库比比皆是，我们不必过分纠缠于这些库的效能的差别，我们以后还有机会进行细调；最后，不要忽视算法的优雅及性能，编写紧凑的，可读的代码可以让你的算法更简单，更干净。

8. 分层 （Layering）
用分层来讨论软件架构是最容易的。John Lakos 曾出版过一本关于大型 C++ 系统的书。Lakos 认为软件包含了层，书中介绍了层的概念，方法是，对每个软件组件，数一下它所依赖的组件数目就可以知道它的复杂程度。

Lakos 认为，一个好的软件拥有金字塔结构，就是说，软件组件拥有层层积累的复杂度，但每个组件本身必须简单，一个优秀的软件包含很多小的，可重复使用的模块，每个模块有自己的职责。一个好的系统中，组件之间的依赖性不可交叉，整个系统是各种各样的组件堆积起来，形成一个金字塔。

Lakos 在软件工程的很多方面都是先驱，最著名的是 Refactoring （代码重构）。代码重构指的是，在编程过程中需要不断地对代码进行改造以保证其结构的健壮与灵活。

9. 惯例与模板 （Conventions and Templates）
命名惯例和基础模板在编程模式中常被忽视，然而它可能是最强大的方法。命名惯例使软件自动化成为可能，如，Java Beans 框架在 getter 和 setter 方法中，使用简单的命名惯例。del.icio.us 网站的 URL 命名也使用统一的格式，如 http://del.icio.us/tag/software 会将用户带到所有标签为 software 的页。

很多社会网络均使用简单命名，如，你的名字是 johnsmith ，那你的头像可能命名为 johnsmith.jpg，而你的 rss 聚合文件的命名很可能是 johnsmith.xml 。

命名惯例还用于单元测试，如，JUnit 单元测试工具会辨认所有以 test 开头的类。

我们这里说的模板（templates ）指的并不是  C++ 或 Java 语言中的 constructs，我们说的是一些包含变量的模板文件，用户可以替换变量并输出最终结果。

Cold Fusion 是最先使用模板的程序之一，后来，Java 使用 JSP 实现模板功能。Apache 近来为 Java 开发了非常好用的通用模板, Velocity。PHP 本身就是基于模板的，因为它支持 eval 函数。

10. 界面（Interfaces）
软件工程中最重要的概念是界面。任何软件都是一个真实系统的模型。如何使用简单的用户界面进行模型化至关重要。很多软件系统走这样的极端，缺乏抽象的冗长代码，或者过分设计而导致无谓的复杂。

在众多软件工程书籍中，Robert Martin 写的《敏捷编程》值得一读。

关于模型化，以下方法对你会有帮助。首先，去掉那些只有在将来才可能用得着的方法，代码越精练越好。第二，不要总认为以前的东西是对的，要善于改变。第三，要有耐心并享受过程。

测试记录:
1、对相同的客户报价，以哪一个为准；（报价单）
测试步骤：在两台电脑上同时报价；
2、已解决单据按顺序连号问题；

讨论:B/S系统测试：
1、总公司(子母公司权限测试)基础资料是否共用,
2在网页操作B/S应用程序时，怎样防止数据是否同步；
（进销存系统，仓库的进出，财务金额的收入和支出等等）
3打印报表，什么方式比较可取，是将报表格式下载到客户端，还是在服务端生成后，在客户端下载该报表格式；（多个客户都下载时，速度大受影响的；
4怎样控制单据，列表，工具栏按钮的权限，各个部门的权限等等；
5出错信息的异常处理和返回到的页面；
6有没有人做过多页面在BS上操作？数据都能保存正确？

网站测试实例－－登录及权限测试
验证用户输入有效性
不能输入非法字符
如：‘ %&nbsp; < -- 等脚本语言中常用的特殊字符
不能直接访问有安全限制的页面
如：浏览器历史记录中记录的页面

用户名/密码验证SQL语句
Select * from userinfo whereusername= 'i_username' and pwd = 'i_password'
恶意登录 admin/ 'or '1'='1
Select * from userinfo whereusername = 'admin' and pwd = '' or '1'= '1'
用户名可以输入任意字符，只要密码中输入了 or true条件

不能直接访问有安全限制的页面
例子：
用户A有登录网站的权限
用户B直接访问历史记录中A访问过的页面

数据过滤:参考,单据关联,单据列表,基础资料,找不到页面问题;

BS系统主要的反映问题:1、过滤问题,出错信息(编辑信息),
2、页面的出错信息是否与当前的页面或界面相适应,出现的提示信息是否明白,
3、权限问题(不该有的信息是否能显示出来,要显示出来的东西是否显示正确;),
4、数据不存在问题(可输入字段的前半部分在编辑界面上,特殊符号的输入%,空格键,令过滤信息检测不正确;)
5参考:只有树;既有树,又有列表;参考界面,
6基础信息是否共用，还是私用；
7单据编号是否唯一，且连号；
8两个用户或者三个用户同时操作同一单据，同一列表，同一单据明细，同一编辑界面，同一按钮，同时保存，同时改单，同时修改，同时删除，
9多页面操作的复杂性，暂不考虑；（数据是否同步）
10仓库库存量是否及时，准确反映出数据；
11原则上不允许报表出现负的数量和金额，并且在月结转或年结转时，数据的处理方式的合理性；
11系统流程设计的合理性，程序员设计系统时应该引导用户进行正确的操作，并且设计的流程是通用，简单，可操作性的；
12客户需求只不过客户想达到怎样的结果，至于表达形式，程序员应该是对系统比较熟悉的，用最简单的方法满足客户需求，
13考虑设计的合理性问题，不能说只能按这样操作，按这样的操作会出错，系统给出的东西，按正确操作，出错的机率比较少，多数出错都是由于用户不按常规操作造成的；
14在操作单据过程中:会调出登录系统界面;
15不同用户在IE上不同切换问题;
16批增,选择记录后,要点击另外一条记录,才可反向选择;
17最近操作的合理性;
18对账单保存,系统错误;
19权限(关联查找,单据上下查,编辑按钮);目前没有权限就不能访问该信息;
20多几层的编辑界面;

升级文件:要模拟的问题:
1、登录系统，输入错误的用户或密码时，没有返回到登录页面；（已测到；）
2、下面问题：要待测；
素材入库单据明细:新增时,编辑界面只看见确定,没有出现该有的界面;
素材入库选择:客户时,出现错误,应该找不到所属的页面;（进入编辑按钮时的返回页面；）
3素材入库：客户参考，编辑，删除记录后，退出，再退出才返回到客户参考界面上；
4素材入库：客户参考：编辑，点击记录，进入编辑界面，退出后，新增按钮不可用；
5素材入库：客户参考：点击编辑按钮，进入后，退出界面，选择客户参考的一条记录，
再点击新增按钮，没有编辑界面出来；
6网页正在载入中：素材入库新增产品，编辑，再编辑（连接到产品分类）
7.出现产品编号字段不唯一后，返回再修改，还会出现系统错误的信息；

测试难点:
1、需求不确定，客户和开发人员观点存在差异，没有达成共识；
2、测试环境和用户环境有出入，没有配置正确的环境，导致有些BUG没有重现出来；
3、系统所有单据状态没有统一规则，使系统流向不明确；
4、用户需求和理论分析有区别，比如仓库要符合进出原则，产品进多少，产品就应该出多少，但客户没有明确规定，出的数量可以大于入的数量都允许；
5、单据被引用后，再修改单据数据，导致单据数据没有确定关系；
6、测试员不能和用户进行有效的沟通，了解客户所需要系统的功能，会使测试效率得不到有效提高，测试员应该尽可能地到用户的工作环境来了解；
7、每个开发人员都可能有自己的观点时，如果开发人员没有主见，任由客户说了算，
虽然解决了问题，但使系统过于复杂化，系统不能实时跟踪到问题；
8、开发人员对自己系统不负责，只完成自己的职责，而不是更好完善自己的产品；
因为开发人员对自己的产品比测试人员了解得更清楚；
9、每修改一次系统，都进行回归测试，会使测试人员的时间分配不合理；
10、做系统时，没有按行业进行规范和设计，使系统面向不同客户时，都要重新设计，
系统面向一个客户时，都要做成通用的系统，并增加客户的特殊需要就可以了；
11、并发操作；