一种保护眼睛的好方法:

桌面-→右键-→属性-→外观-→高级-→项目选择（窗口）、颜色1（L）选择（其它），将色调改为：85。饱和度：123。亮度：205-→添加到自定义颜色-→在自定义颜色选定点确定-→确定这样所有的文档都不再是刺眼的白底黑字，而是非常柔和的豆沙绿色，这个色调是眼科专家配置的，长时间使用会很有效地缓解眼睛疲劳，保护眼睛。

中华人民共和国国家标准

计算机软件配置管理计划规范 GB/T 12505-90

Specification for computer software configuration management plan

　
1． 主题内容与适用范围
本规范规定了在制订软件配置管理计划时应该遵循的统一的基本要求。
本规范适用于软件特别是重要软件的配置管理计划的制订工作。对于非重要软件或已开发好的软件，可以采用本规范规定的要求的子集。
2． 引用标准
GB/T 11457 软件工程术语
GB 8566 计算机软件开发规范
GB 8567 计算机软件产品开发文件编制指南
GB/T 12504 计算机软件质量保证计划规范
3． 术语
下面给出在本规范中用到的一些术语的定义，其它术语的定义按GB/T 11457。在引用时，特别要注意线（baseline）、配置控制(configuration)、配置控制组(configuration control board)、配置检查(configuration audit)、配置标识(configurationidentification)和配置状态记录(configuration status accounting)等术语的定义。
3．1项目委托单位 project entrust organization
项目委托单位是指为产品开发提供资金并通常也是（但有时也未必）确定产品需求的单位或个人。
3．2 项目承办单位 project undertaking organization
项目承办单位是指为项目委托单位开发、购置或选用软件产品的单位或个人。
3．3 软件开发单位 software development organization
软件开发单位是指直接或间接受项目委托单位委托而直接负责开发软件的单位或个人。
3．4 用户 user
用户是指实际全胜软件来完成某项计算、控制或数据处理等任务的单位或个人。
3．5 软件 software
软件是指计算机程序及其有关的数据和文档，也包括固化了的程序。
3．6 重要软件 critical software
重要软件是指其故障会影响到人身安全、会导致重大经济损失或社会损失的软件。
3．7 软件生存周期 software life cycle
软件生存周期是指从软件系统设计对软件系统提出应用需求开始，经过开发，产生出一个满足需求的计算机软件系统，然后投入运行，直至该软件系统退役为止。其间经历系统分析与软件定义、软件开发以及系统的运行与维护等三个阶段。其中软件开发阶段一般又分成需求分析、概要设计、详细设计、编码与单元测试、组装与系统测试以及安装与验收等六个阶段。
3．8 软件开发库 software development library
软件开发库是指在软件生存周期的某一个阶段期间，存放与该阶段软件开发工作有关的计算机可读信息和人工可读信息的库。
3．9 软件受控库 software sontrolled library
软件受控库是指在软件生存周期的某一个阶段结束时，存放作为阶段产品而释放的、与软件开发工作有关的计算机可读信息一人工可读信息的库。软件配置管理就是对软件受控库中的各软件项进行管理，因此软件受控库也叫做软件配置管理库。
3．10 软件产品库 software product libary
软件产品库是指在软件生存周期的组装与系统测试阶段结束后，存放最终产品而后交付给用户运行或在现场安装的软件的库。
3．11 接口控制 interface control
接口控制是指描述有关由一个或多个部门提供的两个或两个以上的配置项接口的所有功能特性和物理特性的过程。在实现之前，要确保对这些功能特性和物理特性所建议的修改已经过评审和批准。
3．12 功能基线 functional baseline
功能基线是指在系统分析与软件定义阶段结束时，经过正式评审和批准的系统设计规格说明书中对待开发系统的规格说明；或是指经过项目委托单位和项目承办单位双方签字同意的协议书或合同中所规定的对待开发软件系统的规格说明；或是由下级申请经上级同意或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。功能基线是最初批准的功能配置标识。
3．13 指派基线 allocated baseline
指派基线是指在软件需求分析阶段结束时，经过正式评审和批准的软件需求的规格说明。指派基线是最初批准的指派配置标识。
3．14 产品基线 product baseline
产品基线是指在软件组装与系统测试阶段结束时，经过正式评审的批准的有关所开发的软件产品的全部配置项的规格说明。产品基线是最初批准的产品配置标识。
3．15 软件配置 software configuration
软件配置是指一个软件产品在软件生存周期各个阶段所产生的各种形式（机器可读或人工可读）和各种版本的文档、程序及其数据的集合。该集合中的每一个元素称为该软件产品软件配置中的一个配置项(configuration item)。
3．16 释放 release
释放是指在软件生存周期的各个阶段结束时，由该阶段向下阶段提交该阶段产品的过程。它也指将集成与系统测试阶段结束时所获得的最终产品向用户提交的过程。后面这个过程也中做交付(delivery)。
4． 软件配置管理计划编制大纲
项目承办单位（或软件开发单位）中负责软件配置管理的机构或个人，必须制订一个包括下面各章内容的的软件配置管理计划（以下简称计划）。各章必须按所描述的顺序排列。如果某章中没有相应的内容，则在该章标题之后必须说明"本章无内容"的字样，并附上相应的理由。如果需要，可以在后面增加章条。如果某些材料已经出现在其它文件中，则在该计划中应引用那些文件。计划的封面必须标明计划名和该计划所属的项目名，并必须经项目委托单位和项目承办单位（或软件开发单位）的代表共同签字、批准。计划的目次是：
引言
管理
软件配置管理活动
工具、技术和方法
对供货单位的控制
记录的收集、维护和保存
下面给出软件配置管理计划的各个章条必须具有的内容。
4．1 引言
4．1．1 目的
本条必须指明特定的软件配置管理计划的具体目的，还必须描述该计划所针对的软件项目及其所属的各个子项目的名称和用途。
4．1．2 定义和缩写词
本条应该列出计划正文中需要解释的、而在GB/T 11457中尚未包含的术语的定义，必要时，还要给出这些定义的英文单词及其缩写词。
4．1．3 参考资料
本条必须列出计划正文中所引用资料的名称、代号、编号、出版机构和出版年月。
4．2 管理
本章必须描述负责软件配置管理的机构、任务、职责及其有关的接口控制。
4．2．1 机构
本条必须描述在各阶段中负责软件配置管理的机构。描述的内容如下：
A． 描述在软件生存周期各阶段中软件配置管理的功能和负责软件配置管理的机构；
B． 说明项目和子项目与其他有关项目之间的关系；
C． 指出在软件生存周期各阶段中的软件开发或维护机构与配置控制组的相互关系。
4．2．2 任务
本条必须描述在软件生存周期各个阶段中的配置管理任务以及要进行评审的检查工作，并指出各个阶段的阶段产品应存放在哪一类软件库中（软件开发库、软件受控库或软件产品库）。
4．2．3 职责
本条必须描述与软件配置管理有关的各类机构或成员的职责，并指出这些机构或成员相互之间的关系。
A． 指出负责各项软件配置管理任务（如配置标识、配置控制、配置状态记录以及配置的评审与检查）的机构的职责；
B． 指出上述机构与软件质量保证机构、软件开发单位、项目承办单位、项目委托单位以及用户等机构的关系；
C． 说明由本计划第4.2.2条指明的生存周期各个阶段的评审、检查和审批过程中的用户职责以及相关的开发与维护活动；
D． 指出与项目开发有关的各个机构的代表的软件配置管理职责；
E． 指出其他特殊职责，例如为满足软件配置管理要求所必要的批准要求。
4．2．4 接口控制
本条应该描述：
A． 接口规格说明标识和文档控制的方法；
B． 对已交付的接口规格说明和文档进行修改的方法；
C． 对要完成的软件配置管理活动进行跟踪的方法；
D． 记录和报告接口规格说明和文档控制状态的方法；
E． 控制软件和劫持它运行的硬件之间的接口的方法。
4．2．5 实现
本条应该规定实现软件配置管理计划的主要里程碑，例如：
A． 建立配置控制组；
B． 确定各个配置基线；
C． 建立接口控制协议；
D． 制订评审与检查软件配置管理计划和规程；
E． 制订相关的软件开发、测试和劫持工具的配置管理计划和规程。
4．2．6 适用的标准、条例和约定
4．2．6．1 本条必须指明所适用的软件配置管理标准、条例和约定，并把它们作为本计划要实现的一部分；还必须说明这些标准、条例和约定要实现的程度。
4．2．6．2 本条必须描述要在本项目中编写和实现的软件配置管理标准、条例和约定。
这些标准、条例和约定可以包括如下内容：
A． 软件结构层次树中软件位置的标识方法；
B． 程序和模块的命名约定；
C． 版本级别的命名约定；
D． 软件产品的标识约定；
E． 规格说明、测试计划与测试规程、程序设计手册及其他文档的标识方法；
F． 媒体和文档管理的标识方法；
G． 文档交付过程；
H． 软件产品库中软件产品入库、移交或交付的过程；
I． 问题报告、修改请求和修改次序的处理过程；
J． 配置控制组的结构和作用；
K． 软件产品交付给用户的验收规程；
L． 软件库的操作，包括准备、存储和更新模块的方法；
M． 软件配置管理活动的检查；
N． 问题报告、修改请求或修改次序的文档要求，指出配置修改的目的和影响；
O． 软件进入配置管理之前的测试级别；
P． 质量保证级别，例如，在进入配置管理之前，验证软件满足有关基线的程序。
4．3 软件配置管理活动
本章必须描述配置标识、配置控制、配置状态记录与报告以及配置检查与评审等到四方面的软件配置管理活动的需求。
4．3．1 配置标识
4．3．1．1 本条必须详细说明软件项目的基线（即最初批准的配置标识），并把它们与本计划第4.2.2条描述的生存周期的特定阶段相联系。在软件生存周期中，主要有三种基线，它们是功能基线、指派基线和产品基线。对于每个基线，必须描述下列内容：
A． 每个基线的项（包括应交付的文档和程序）；
B． 与每个基线有关的评审与批准事项以及验收标准；
C． 在建立基线的过程中用户和开发者可的参与情况。
例如，在产品基线中，要定义的元素可以包括：
A． 产品的名字和命名规则；
B． 产品标识编号；
C． 对每一个新交付的版本，要给出版本交付号、新修改的描述、修改交付的方法、对支持软件的修改要求以及有关文档的修改要求；
D． 安装说明；
E． 已知的缺陷和故障；
F． 软件媒体和媒体标识。
4．3．1．2 本条必须描述本项目所有软件代码和文档的标题、代号、编号以及分类规程。例如，对代码来说：
A． 编译日期可以作为每个交付模块标识的一部分；
B． 在构造模块源代码的顺序行号时，应使它适合于对模块作进一步子修改。
4．3．2 配置控制
4．3．2．1 本条必须描述在本计划第4.2.2条描述的软件生存周期中各个阶段使用的修改批准权限的级别。
4．3．2．2 本条必须定义对已有配置的修改建议进行处理的方法，其中包括：
A． 详细说明书在本计划第4.2.2条描述的软件生存周期各个阶段中提出建议的程序（可以用注上自然语言的流程图来表达）；
B． 描述实现已批准的修改建议（包括源代码、目标代码和文档的修改）的方法；
C． 描述软件库控制的规程，其中包括存取控制、对于适用基线的读写保护、成员保护、成员标识、档案维护、修改历史以及故障恢复等七项规程；
D． 如果有必要修补目标代码，则要描述其标识和控制的方法。
4．3．2．3 对于各个不同层次的配置控制组和其他修改管理机构，本条必须：
A． 定义其作用，并规定其权限和职责；
B． 如果已组成机构，则指明该机构的领导人员及其成员；
C． 如果还没有组成机构，则说明怎样任命该机构的领导人、成员及代理人；
D． 说明开发者和用户与配置控制组的关系。
4．3．2．4 当要与不属于本软件配置管理计划适用范围的程序和项目进行接口时，本条必须说明对其进行配置控制的方法。如果这些软件的修改需要其他机构在配置控制组评审之前或之后进行评审，则本条必须描述这些机构的组成、它们与配置控制组的关系以及它们之间的相互关系。
4．3．2．5 本条必须说明与特殊产品（如非交付的软件、现存软件、用户提供的软件和内部支持软件）有关的配置控制规程。

测试的主要评测方法（转）
1. 简介
2. 覆盖评测标准
  基于需求的测试覆盖
  基于代码的测试覆盖
3.质量评测
4.缺陷报告
  缺陷密度
  缺陷龄期
  缺陷趋势
5.性能评测
  动态监测
  响应时间/吞吐量
  百分位报告
  比较报告
  追踪和配置文件报告
1.简介测试的主要评测方法包括覆盖和质量。
测试覆盖是对测试完全程度的评测，它建立在测试覆盖基础上，测试覆盖是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。
质量是对测试对象（系统或测试的应用程序）的可靠性、稳定性以及性能的评测。质量建立在对测试结果的评估和对测试过程中确定的变更请求（缺陷）的分析的基础上。
2.覆盖评测覆盖指标提供了“测试的完全程度如何？”这一问题的答案。最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖。简而言之，测试覆盖是就需求（基于需求的）或代码的设计/实施标准（基于代码的）而言的完全程度的任意评测，如用例的核实（基于需求的）或所有代码行的执行（基于代码的）。
系统的测试活动建立在至少一个测试覆盖策略基础上。覆盖策略陈述测试的一般目的，指导测试用例的设计。覆盖策略的陈述可以简单到只说明核实所有性能。
如果需求已经完全分类，则基于需求的覆盖策略可能足以生成测试完全程度的可计量评测。例如，如果已经确定了所有性能测试需求，则可以引用测试结果来得到评测，如已经核实了 75% 的性能测试需求。
如果应用基于代码的覆盖，则测试策略是根据测试已经执行的源代码的多少来表示的。这种测试覆盖策略类型对于安全至上的系统来说非常重要。
两种评测都可以手工得到（公式如下所示）或通过测试自动化工具计算得到。

[size=10.5pt]2.1 基于需求的测试覆盖
[size=10.5pt]基于需求的测试覆盖在测试生命周期中要评测多次，并在测试生命周期的里程碑处提供测试覆盖的标识（如已计划的、已实施的、已执行的和成功的测试覆盖）。
测试覆盖通过以下公式计算：
测试覆盖 = 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%
这一关于测试覆盖的陈述是有意义的，可以将其与已定义的成功标准进行对比。如果不符合该标准，则此陈述将成为预测剩余测试工作量的基础。
2.2 基于代码的测试覆盖基于代码的测试覆盖评测测试过程中已经执行的代码的多少，与之相对的是要执行的剩余代码的多少。代码覆盖可以建立在控制流（语句、分支或路径）或数据流的基础上。控制流覆盖的目的是测试代码行、分支条件、代码中的路径或软件控制流的其他元素。数据流覆盖的目的是通过软件操作测试数据状态是否有效，例如，数据元素在使用之前是否已作定义。
基于代码的测试覆盖通过以下公式计算：
测试覆盖 = Ie / TIic
其中：
Ie 是用代码语句、代码分支、代码路径、数据状态判定点或数据元素名表示的已执行项目数。
TIic (Total number of Items in the code) 是代码中的项目总数。
如将该比率转换为百分数，则以下基于代码的测试覆盖的陈述成立：
x% 的测试用例（上述公式中的 I）已经覆盖，成功率为 y%
这一关于测试覆盖的陈述是有意义的，可以将其与已定义的成功标准进行对比。如果不符合该标准，则此陈述将成为预测剩余测试工作量的基础。

[size=10.5pt]3.质量评测
测试覆盖的评估提供对测试完全程度的评测，在测试过程中已发现缺陷的评估提供了最佳的软件质量指标。因为质量是软件与需求相符程度的指标，所以在这种环境中，缺陷被标识为一种更改请求，该更改请求中的测试对象与需求不符。
缺陷评估可能建立在各种方法上，这些方法种类繁多，从简单的缺陷计数到严格的统计建模不一而足。
严格的评估假定测试过程中缺陷达到的比率或发现的比率。常用模型假定该比率符合泊松分布。则有关缺陷率的实际数据可以适用于这一模型。生成的评估将评估当前软件的可靠性，并且预测继续测试并排除缺陷时可靠性如何增长。该评估被描述为软件可靠性增长建模，这是一个活跃的研究领域。由于该类型的评估缺乏工具支持，所以应该慎重平衡成本与其增加价值。
缺陷分析就是分析缺陷在与缺陷关联关系的一个或多个参数值上的分布。缺陷分析提供了一个软件可靠性指标。
对于缺陷分析，常用的主要缺陷参数有四个：
状态：缺陷的当前状态（打开的、正在修复或关闭的等）。
优先级：必须处理和解决缺陷的相对重要性。
严重性：缺陷的相关影响。对最终用户、组织或第三方的影响等等。
起源：导致缺陷的起源故障及其位置，或排除该缺陷需要修复的构件。

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

例如，预期缺陷发现率将随着测试进度和修复进度而最终减少。可以设定一个阈值，在缺陷发现率低于该阈值时才能部署软件。也可根据执行模型中的起源报告缺陷计数，以允许检测“较差的模块”、“热点”或需要再三修复的软件部分，从而指示一些更基本的设计缺陷。
这种分析中包含的缺陷必须是已确认的缺陷。不是所有已报告的缺陷都报告实际的缺陷，这是因为某些缺陷可能是扩展请求，超出了项目的规模，或描述的是已报告的缺陷。然而，需要查看并分析一下，为什么许多报告的缺陷不是重复的缺陷就是未经确认的缺陷，这样做是有价值的。

[size=10.5pt]4.缺陷报告
[size=10.5pt]缺陷分布（密度）报告允许将缺陷计数作为一个或多个缺陷参数的函数来显示。
缺陷龄期报告是一种特殊类型的缺陷分布报告。缺陷龄期报告显示缺陷处于特定状态下的时间长短，如“提出的”。在龄期类别中，缺陷还可以按其他属性分类，如“拥有者”。
缺陷趋势报告按状态（新的、已打开的或关闭的）将缺陷计数作为时间的函数显示。趋势报告可以是累计的，也可以是非累计的。
测试结果和进度报告显示对测试的应用程序进行若干次迭代和测试生命周期后的测试过程执行结果。
许多此类报告对于评估软件质量具有很高的价值。一般测试标准中包括有关特定类别（如严重性级别）中打开的缺陷数的陈述。通过缺陷分布评估可以轻松地核对该标准。对测试需求进行过滤或分类，该评估可以侧重于不同的需求集。
要有效生成此类报告，一般需要工具支持。

4.1 缺陷密度报告缺陷状态与优先级
应该给定所有缺陷的优先级，通常可行的做法是设定四种优先级中的一种：
立即解决
高优先级
正常排队
低优先级
一个成功测试的标准可以表示为缺陷在上述优先级上所应体现的分布方式。例如，对于一个成功的测试标准来说，可能不存在优先级为 1 的打开的缺陷，而且优先级为 2 的打开的缺陷要少于 5 个。例如下面的缺陷分布图：



很明显该图显示的情况没有达到标准。请注意，该图需要通过过滤器才能只显示需要的打开的缺陷。
缺陷状态与严重性
缺陷严重性报告显示每种严重性级别的缺陷个数，例如致命错误、未执行主要功能、次要错误等严重性级别。
缺陷状态与在实施模型中的位置
缺陷起源报告显示缺陷在实施模型元素上的分布情况。
缺陷龄期报告缺陷龄期分析提供了有关测试有效性和缺陷排除活动的良好反馈。例如，如果大部分龄期较长的、未解决的缺陷处于有待确认的状态，则可能表明没有充足的资源应用于再次测试工作。
缺陷趋势报告趋势报告确定缺陷率并提供了一个出色的测试状态视图。在测试生命周期中，缺陷趋势遵循着一种比较好预测的模式。在生命周期的初期，缺陷率增长很快。在达到顶峰后，就随时间以较慢的速率下降。




要发现问题，可以根据这一趋势复审项目时间表。例如，在四个星期的生命周期中，如果缺陷率在第三个星期中仍然增长，则项目很明显没有按时间表进行。
这一简单的趋势分析假定：缺陷是立即关闭的，且在随后的工作版本中对修复进行测试，这样关闭缺陷的速率应该遵循与打开缺陷的速率相同的增减趋势。如果情况并非如此，则表明缺陷解决流程发生了问题；缺陷修复所需的资源或再次测试和确认修复所需的资源可能不足。



该报告反映的趋势显示，在项目开始时，发现和打开新缺陷的速率很快，但随着时间推移，该速率不断降低。打开的缺陷的趋势与新缺陷的趋势相似，但稍微滞后一些。关闭的缺陷的趋势随着打开的缺陷的修复和核实而不断增长。这些趋势描述的是成功的工作。

如果您的趋势与这些趋势差别显著，则表明存在问题，并可以确定可能需要附加资源以应用于开发或测试特定区域的时间。
当与测试覆盖评测结合起来时，缺陷分析可提供出色的评估，测试完成的标准也可以建立在此评估基础上。
性能评测评估测试对象的性能行为时，可以使用多种评测，这些评测侧重于获取与行为相关的数据，如响应时间、计时配置文件、执行流、操作可靠性和限制。这些评测主要在评估测试活动中进行评估，但是也可以在执行测试活动中使用性能评测评估测试进度和状态。
主要的性能评测包括：
动态监测 - 在测试执行过程中，实时获取并显示正在执行的各测试脚本的状态。
响应时间/吞吐量 - 测试对象针对特定主角和/或用例的响应时间或吞吐量的评测。
百分位报告 - 数据已收集值的百分位评测/计算。
比较报告 - 代表不同测试执行情况的两个（或多个）数据集之间的差异或趋势。
追踪报告 -主角（测试脚本）和测试对象之间的消息/会话详细信息。
动态监测动态监测通常以柱状图或曲线图的形式提供实时显示/报告。该报告用于在测试执行过程中，通过显示当前的情况、状态以及测试脚本正在执行的进度来监测或评估性能测试执行情况。


例如，在以上柱状图中，有 80 个测试脚本正在执行相同的用例。图中显示，有 14 个测试脚本处于空闲状态，12 个处于查询状态，34 个处于 SQL 执行状态，4 个处于 SQL 连接状态，16 个处于其他状态。随着测试的进行，我们将看到各状态脚本的数量会发生变化。显示的输出将是正常执行且正在执行中的典型测试执行。但是，如果在测试执行过程中，测试脚本始终保持一种状态或没有显示任何变化，则表明测试执行发生问题或者需要实施或执行其他性能评测。

web 测试分为 6 个部分：
1.用户界面测试
2.功能测试
3.接口测试
4.兼容性测试
5.负载/压力测试
6.安全测试
本文的目的是覆盖 web 测试的各个方面，未就某一主题进行深入说明。

用户界面
使用 Web 浏览器作为应用程序的前台的一个原因就是它易于使用。用户知道如何浏览一

个构建良好的网站。如果你注重这方面的测试，那么验证应用程序是否易于使用就非常

重要了。很多人认为这是测试中最不重要的部分，但是如果你想通过网站赚钱，最好使

你的网站使用起来更加方便。

使用说明
应该确认你的站点有使用说明。即使你认为你的网站很简单，也可能有人在某些方面需

要征实一下。测试人员需要测试说明文档，验证说明是正确的。还可以根据说明进行操

作，确认出现预期的结果。

站点地图和导航条
确认你测试的站点是否有地图。有些网络高手可以直接去自己要去的地方，而不必点击

一大堆页面。另外新用户在网站中可能会迷失方向。站点地图和/或导航条可以引导用户

进行浏览。需要验证站点地图是否正确。确认地图上的链接是否确实存。地图有没有包

括站点上的所有链接。是否每个页面都有导航条? 导航条是否一致? 每个页面的链接是

否正常? 导航条是否直观?

内容
对于开发人员来说，可能先有功能然后才对这个功能进行描述。大家坐在一起讨论一些

新的功能，然后开始开发，在开发的时候，开发人员可能不注重文字表达，他们添加文

字可能只是为了对齐页面。不幸的是，这样出来的产品可能产生严重的误解。因此测试

人员和公关部门一起检查内容的文字表达是否恰当。否则，公司可能陷入麻烦之中，也

可能引起法律方面的问题。测试人员应确保站点看起来更专业些。过分地使用粗体字、

大字体和下划线可能会让用户感到不舒服。在进行用户可用性方面的测试时，最好先请

图形设计专家对站点进行评估。你可能不希望看到一篇到处是黑体字的文章，所以相信

您也希望自己的站点能更专业一些。最后，需要确定是否列出了相关站点的链接。很多

站点希望用户将邮件发到一个特定的地址，或者从某个站点下载浏览器。但是如果用户

无法点击这些地址，他们可能会觉得很迷惑。

颜色/背景
由于 web 日益流行，很多人把它看作图形设计作品。不幸的是，有些开发人员对新的背

景颜色更感兴趣，以至于忽略了这种背景颜色是否易于浏览。典型的站点是在紫色图片

的背景上显示黄色的文本(如果你没有见过这样的站点，请浏览一下 GeoCities 或 AOL

上的个人主页，有不少这样的)。这种页面显得"非常高贵"，但是看起来很费劲。通常来

说，使用少许或尽量不使用背景是个不错的选择。如果您想用背景，那么最好使用单色

的，和导航条一起放在页面的左边。另外，图案和图片可能会转移用户的注意力。

图片
无论作为屏幕的聚焦点或作为指引的小图标，一张图片都胜过千言万语。有时，告诉用

户一个东西的最好办法就是将它展示给用户。但是，带宽对客户端或服务器来说都是非

常宝贵的，所以要注意节约使用内存。是否所有的图片对所在的页面都是有价值的，或

者它们只是浪费带宽? 使用其它的文件格式(.GIF, .JPG) 是否能使图片的大小减小到

30k 以下? 通常来说，不要将大图片放在首页上，因为这样可能会使用户放弃下载首页

。如果用户可以很快看到首页，他可能会浏览站点，否则可能放弃。

表格
需要验证表格是否设置正确。用户是否需要向右滚动页面才能看见产品的价格？把价格

放在左边，而把产品细节放在右边是否更有效? 每一栏的宽度是否足够宽，表格里的文

字是否都有折行？是否有因为某一格的内容太多，而将整行的内容拉长?

回绕
最后，需要验证的是文字回绕是否正确。如果说明文字指向右边的图片，应该确保该图

片出现在右边。不要因为使用图片而使窗口和段落排列古怪或者出现孤行。　

功能测试
Web 站点的功能是贵公司雇佣开发人员而不只是艺术家的原因。就是这一部分与服务器

通讯并且最终完成任务。  

链接
链接是使用户从一个页面浏览到另一个页面的重要手段。对于每个链接，需要验证两件

事情： 一是该链接将用户带到它所说明的地方，另外就是被链接页面是存在的。这句话

听起来有些问题，但是有很多多站点的内部链接都是空的。这实在是无法忍受。

表单
当用户通过表单提交信息的时候，都希望表单能正常工作。如果使用表单来进行在线注

册，要确保提交按钮能正常工作，当注册完成后应返回注册成功的消息。如果使用表单

收集配送信息，应确保程序能够正确处理这些数据，最后能让顾客能让客户收到包裹。

要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解

释和使用这些信息。

数据校验
如果系根据业务规则需要对用户输入进行校验，需要保证这些校验功能正常工作。例如

，省份的字段可以用一个有效列表进行校验。在这种情况下，需要验证列表完整而且程

序正确调用了该列表(例如在列表中添加一个测试值，确定系统能够接受这个测试值)。

Cookies
很多用户喜欢甜食，但是开发人员喜欢 web cookie (小甜饼)。如果系统使用了cookie

，测试人员需要对它们进行检测。如果在 cookies 中保存了注册信息，请确认该

cookie能够正常工作而且已对这些信息已经加密。如果使用 cookie 来统计次数，需要

验证次数累计正确。  

应用程序特定的功能需求
最重要的是，测试人员需要对应用程序特定的功能需求进行验证。尝试用户可能进行的

所有操作：下订单、更改订单、取消订单、核对订单状态、在货物发送之前更改送货信

息、在线支付等等。这是用户之所以使用网站的原因，一定要确认网站能像广告宣传的

那样神奇。　

接口测试
在很多情况下，web 站点不是孤立。Web 站点可能会与外部服务器通讯，请求数据、验

证数据或提交订单。

服务器接口
第一个需要测试的接口是浏览器与服务器的接口。测试人员提交事务，然后查看服务器

记录，并验证在浏览器上看到的正好是服务器上发生的。测试人员还可以查询数据库，

确认事务数据已正确保存。

外部接口
有些 web 系统有外部接口。例如，网上商店可能要实时验证信用卡数据以减少欺诈行为

的发生。测试的时候，要使用 web 接口发送一些事务数据，分别对有效信用卡、无效信

用卡和被盗信用卡进行验证。如果商店只使用 Visa 卡和 Mastercard 卡， 可以尝试使

用 Discover 卡的数据。(简单的客户端脚本能够在提交事务之前对代码进行识别，例如

3 表示 American Express，4 表示 Visa，5 表示 Mastercard，6 代表Discover。)通

常，测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。  

错误处理
最容易被测试人员忽略的地方是接口错误处理。通常我们试图确认系统能够处理所有错

误，但却无法预期系统所有可能的错误。尝试在处理过程中中断事务，看看会发生什么

情况？订单是否完成？尝试中断用户到服务器的网络连接。尝试中断 web 服务器到信用

卡验证服务器的连接。在这些情况下，系统能否正确处理这些错误？是否已对信用卡进

行收费？如果用户自己中断事务处理，在订单已保存而用户没有返回网站确认的时候，

需要由客户代表致电用户进行订单确认。

光盘数据复制出错，提示：无法复制：数据错误(循环冗余检查) ”解决之道
今日，一同事在将一DVD视频文件复制到硬盘中时，在将要复制完毕时，出现提示：无法复制：数据错误(循环冗余检查) ，然后退出复制。但是该文件在光盘上播放很正常，说明该文件本身并没有问题。由于该文件比较大（大约有2G左右），考虑是不是光驱的问题，换了几个光驱，仍然如此。曾经在网上看到过相似问题的文章，文章中建议利用网站功能，通过下载软件下载有可能解决这个问题。马上登陆到局域网服务器，将光盘文件映射到服务器的WEB目录中，用flashget下载，但是速度太慢了，只有0.1-10Kbps，2G的文件不知道要下载到猴年马月。
　　突然我看见我桌面WinMount图标：能否将该文件打包成zip文件呢？立即开启WinMount，将该光盘的无法复制的文件制作成zip文件。打包速度还挺快的，但到99%的时候，弹出对话框，大意是WinMount软件制作过程出错，无法完成，是终止还是忽略？当然是忽略，然后又提示一些错误信息，软件就直接退出。我以为又没戏了，但是打开存盘目录一看，制作的zip文件居然还在，马上用WINISO软件将文件打开，提取，一切顺利。将提取出来的文件播放，也一切正常。呵呵，终于成功了！

经常能在文章中看到：人们在讲学习和人生的追求时，常引用王国维先生的《人间词话》里的三种境界，今乃认真记下，以细细体会。
    第一种：“昨夜西风凋碧树，独上高楼，望尽天涯路。”——一个人在孤独之中寻找理想，寻找生命着落点的痛苦时刻。
    第二种：“为伊消得人憔悴，衣带渐宽终不悔。”——个人找到值得为之奋斗的目标，全力以赴，不惜一切代价努力的过程。
    第三种：“众里寻他千百度，蓦然回首，那人却在、灯火阑珊处。”——一个人通过自己的苦苦寻求和努力，发现自己想要的东西原来就在自己的身边，这是会心大悟之境界。此时，世俗的目标是否达到已经不再重要，重要的是灵魂的解放和心灵的归宿。
    生命永远像童年一样简单，是浅薄；生命陷入世俗的纷争，是庸俗；生命从纷争中得到解放，是觉悟。觉悟后才能进入王国维先生所描述的第三种境界。

开设空间，今天我也开设了在51testing的个人空间。希望我这只菜鸟和大家一起成长。