一、色彩形成 　　
    物体表面色彩的形成取决与三个方面：光源的照射、物体本身反射一定的色光、环境与空间对物体色彩的影响。

     １、光源色：由各种光源发出的光，光波的长短、强弱、比例性质的不同形成了不同的色光，称为光源色。

     ２、物体色：物体色本身不发光，它是光源色经过物体的吸收反射，反映到视觉中的光色感觉，我们把这些本身不发光的的色彩统称为物体色。  

     ３、光源色 复色光 白色光（全色光） 投射在物体上 不透明物体 反射

     ４、有色光 半透明物体

     ５、单色光 透明物体 透射

     ６、光源色 复色光 白色光（全色光） 投射在物体上 不透明物体 反射

     ７、有色光 半透明物体

     ８、单色光 透明物体 透射

     二、色彩组成

     １、基本色 　　

 　　一个色环通常包括12种明显不同的颜色。而对于艺术设计师充分理 解的色环和色论的重要方面，也许不会被我们中的网页设计者们能够充 分欣赏。缺少多这方面的了解，你将会把事情搞乱。

     ２、三原色"

  　从定义上讲，三原色是能够按照一些数量规定合成其他任何一种颜 色的基色。为了确定三原色，你必须首先确切明确哪一种颜色是你正在 使用的中间色。在上小学时，你可能就知道了三原色：红、黄、蓝，并 且你现在用于展示的，仍然是红、黄、蓝三原色。但是如果你有喷墨打 印机的话，花点时间把它的盖子打开，看看它的墨盒。你能看到红、黄、 蓝吗？不能！你可能看到的是四种墨色：蓝绿（青）色、红紫（洋红） 色、黄色和黑色。颜色的不同是由于你的电脑用的是正色，而你的打印 机用的是负色。显示器发出的是彩色光，而纸上的墨则吸收灯光发出的 颜色。更进一步的解释就超出了本文要探讨的范围。

     除了发射与吸收光的不同之外，本文涉及的概念同样适用于正色和 负色模式，出于本文的写作目的，我们仅探讨着正色模式的三原色：红、 绿、蓝。

     ３、近似色

 　　近似色可以是我们给出的颜色之外的任何一种颜色。如果从橙色开 始，并且你想要它的两种近似色，你应该选择红和黄。用近似色的颜色 主题可以实现色彩的融洽与融合，与自然界中能看到的色彩接近起来。

        ４、补充色 

　　正如我们所知道的相对色一样，补充色是色环中的直接位置相对的 颜色。当你想使色彩强烈突出的话，选择对比色比较好。假如你正在组 合一幅柠檬图片，用蓝色背景将使柠檬更加突出。 

　　５、分离补色 

　　分离补色由两到三种颜色组成。你选择一种颜色，就会发现它的补 色在色环的另一面。你可以使用补色那一边的一种或多种颜色。 

　　６、组色

 　　组色是色环上距离相等的任意三种颜色。当组色被用作一个色彩?题时，会对浏览者造成紧张的情绪。因为三种颜色形成对比。上面所讲 的基色和次色组可以被称作两组组色。 

　　７、暖色 

　　暖色由红色调组成。比如红色、橙色和黄色。它们给选择的颜色赋 予温暖、舒适和活力，它们也产生了一种色彩向浏览者显示或移动，并 从页面中突出出来的可视化效果。

 　　８、冷色 　

 　　冷色来自于蓝色色调。譬如蓝色、青色和绿色。这些颜色将对色彩 主题起到冷静的作用，它们看起来有一种从浏览者身上收回来的效果， 于是它们用作页面的背景比较好。 

    需要注明的是，你将发现在不同的书中，这些颜色组合有不同的名称。但是如果你能够理解这些基本原则，它们将对你的网页设计是十分有益的。

三、色彩对比
两种以上的色彩，以空间或时间关系相比较，能比较出明显的差别，并产生比较作用，被称为色彩对比。该想象分为两大类：同时对比和连续对比。
１、色相对比   因色相之间的差别形成的对比。当主色相确定后，必须考虑其他色彩与主色相是什么关系，要表现什么内容及效果等，这样才能增强其表现力。将相同的橙色，放在 红色或黄色上，我们将会发现，在红色上的橙色会有偏黄的感觉，因为橙色是由红色和黄色调成的，当他和红色并列时，相同的成份被调和而相异部份被增强，所以 看起来比单独时偏黄，以其他色彩比较也会有这种现象，我们称为色名对比。 除了色感偏移之外， 对比的两色， 有时会发生互相色渗的现象， 而影响相隔界线的视觉效果， 当对比的两色， 具有相同的彩度和明度时， 对比的效果越明显， 两色越接近补色， 对比效果越强烈。 

     ２、明度对比   因明度之间的差别形成的对比。（柠檬黄明度高，蓝紫色的明度低，橙色和绿色属中明度，红色与蓝色属中低明度）。

 　　明度对比 将相同的色彩，放在黑色和白色上，比较色彩的感觉，会发现黑色上的色彩感觉比较亮，放在白色上的色彩感觉比较暗，明暗的对比效果非常强烈明显，对配色结果产生的影响，明度差异很大的对比， 会让人有不安的感觉。 

    ３、纯度对比 一种颜色与另一种更鲜艳的颜色相比时，会感觉不太鲜明，但与不鲜艳的颜色相比时，则显得鲜明，这种色彩的对比便称为纯度对比。 

    ４、补色对比 将红与绿、黄与紫、蓝与橙等具有补色关系的色彩彼此并置，使色彩感觉更为鲜明，纯度增加，称为补色对比。（视觉的残像现象明显）。

 
    ５、冷暖对比 由于色彩感觉的冷暖差别而形成的色彩对比，称为冷暖对比。（红、橙、黄使人感觉温暖；蓝、蓝绿、蓝紫使人感觉寒冷；绿与紫介与其间），另外，色彩的冷暖对比还受明度与纯度的影响，白光反射高而感觉冷，黑色吸收率高而感觉暖。                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                          文章来源：中国设计秀

测试生命周期

　　测试计划 → 测试设计 → 测试开发 → 测试执行 → 测试评估

　　测试计划就是定义一个测试项目的过程，以便能够正确的度量和控制测试。

第一部分：测试计划

测试计划的问题：

　　1、测试计划经常是等到开发周期后期才开始实行，使得没有时间有效的执行计划；

　　2、测试计划的组织者可能缺乏Client/Server测试经验；

　　3、测试的量度和复杂性可能太大，没有自动化工具，很难计划和控制。

测试策略：

　　测试策略描述测试工程的总体方法和目标。描述目前在进行哪一阶段的测试（单元测试、集成测试、系统测试）以及每个阶段内在进行的测试种类（功能测试、性能测试、压力测试等）。

　　测试策略包括

　　1、要使用的测试技术和工具；

　　2、测试完成标准；

　　3、影响资源分配的特殊考虑例如测试与外部接口或者模拟物理损坏、安全性威胁。

　　测试计划最关键的一步就是将软件分解成单元，写成测试需求。

　　测试需求有很多分类方法，最普通的一种就是按照商业功能分类。把软件分解成单元元件有几个好处：

　　1、测试需求是测试设计和开发测试用例的基础，分成单元可以更好地进行设计；

　　2、详细的测试需求是用来衡量测试覆盖率的重要指标；

　　3、测试需求包括各种测试实际和开发以及所需资源。

怎样估计测试工作量：

　　1、效率假设：即测试队伍的工作效率。对于功能测试，这主要依赖于应用的复杂度，窗口的个数，每个窗口中的动作数目。对容量测试，主要依赖于建立测试所需数据的工作量大小。

　　2、测试假设：为了验证一个测试需求所需测试动作数目。

　　3、应用的维数：应用的复杂度指标。例如要加入一个记录，测试需求的维数就是这个记录中域的数目。

　　4、所处测试周期的阶段：有些阶段主要工作都在设计，有些阶段主要是测试执行。

测试资源：

　　1、人力资源

　　测试项目经理

　　为测试项目提供总体方向。开发测试计划、征集并监督测试人员、申请系统资源、监视并汇报工作进程、测试评估、测试需求的分解。

　　测试工程师 —- 设计和开发

　　设计：对被测软件的详细了解、分解测试需求的技能、选择在C/S环境下用来验证测试需求的技术。

　　开发：熟悉SQA、VB、和脚本语言。

　　测试工程师 —- 执行

　　负责测试执行和记录结果。需要能够安装系统，网络知识，初始化数据库和其他初始条件。重要的是诊断能力。

　　测试系统管理者

　　每个测试项目必须指定一个专人负责管理SQA Suite。包括在服务器上安装存储库，安装打印机连接，执行备份，以及其他维护工作。管理者必须高度熟悉SQA，网络工作经验。

　　2、系统资源

　　安装SQA Suite的硬件和软件环境

　　数据库服务器

　　该服务器必须专用于 测试工作，能够重置某些初始值，包括系统日期和时间等。

写测试计划的步骤：

　　1、确定工程

　　收集下列信息

　　定义新的工程，Adminà New Project。

　　确定软件的结构，用Assetsà Software Structure选项定义软件结构。

　　2、定义测试策略

　　3、分解软件，写测试需求

　　分析各种信息

　　反复检查并理解各种信息，和用户交流，理解他们的要求。可以按照以下步骤执行：

　　1、确定软件提供的主要商业任务

　　2、对每个商业任务，确定完成该任务所要进行的交易。

　　3、确定从数据库信息引出的计算结果。

　　4、对于对时间有要求的交易，确定所要的时间和条件。这些条件包括数据库大小、机器配置、交易量、以及网络拥挤情况。

　　5、确定会产生重大意外的压力测试，包括：内存、硬盘空间、高的交易率

　　6、确定应用需要处理的数据量。

　　7、确定需要的软件和硬件配置。通常情况下，不可能对所有可能的配置都测试到，因此要选择最有可能产生问题的情况进行测试，包括：最低性能的硬件、几个有兼容性问题的软件并存、客户端机器通过最慢的LAN/WANF连接访问服务器。

　　8、确定其他与应用软件没有直接关系的商业交易。包括：

　　　　管理功能，如启动和推出程序
　　　　配置功能，如设置打印机
　　　　操作员的爱好，如字体、颜色
　　　　应用功能，如访问email或者显示时间和日期。

　　9、确定安装过程，包括定置从哪安装、定制安装、升级安装。

　　10、确定没有隐含在功能测试中的户界面要求。大多界面都在功能测试时被测试到。还有写没有测到，如：操作与显示的一致性，如使用快捷键等；界面遵从合理标准，如按钮大小，标签等。

　　把需求组织成层次图

　　4、估计测试工作量

　　∑(每个测试的时间*每个需求的测试的数目*测试需求的的数目)
　　（测试设计、开发、….）

　　5、确定资源

　　人力资源

　　系统资源

　　6、创建工程调度表

　　7、书写测试计划

　　1、介绍

　　　　目的
　　　　背景
　　　　测试范围
　　　　项目文件列表

　　2、测试需求

　　3、测试策略

　　　　测试类型

　　　　1、功能测试
　　　　2、用户界面测试
　　　　3、性能测试
　　　　4、压力测试
　　　　5、容量测试
　　　　6、配置测试
　　　　7、安装测试

　　　　工具

　　4、资源

　　　　人力资源
　　　　系统资源

　　5、调度

　　6、文档

　　　　软件元件
　　　　测试特性（Assets）
　　　　测试日记
　　　　缺陷报告

第二部分：测试设计

测试设计的问题

　　1、不做测试设计，测试过程也是胡乱建立的。

　　2、测试设计不详细，不是基于可量度的测试策略，例如测试计划覆盖一个集合或者测试需求的一个子集。

　　3、测试过程没有采用最好的技术来检验Windows C/S结构的测试需求

测试用例的选择规则

　　1、选择与测试需求的实质部分最相关的测试用例。

　　2、选择的测试用例应该不容易应用程序的改变的影响。

　　下面是选择测试用例的几点具体规则：

　　1、商业函数

　　商业函数一般与数据库有关，要测试数据库的变化，有几种方法：
　　1、如果数据库的的改变会反映在一个列表框中，那么就要选择验证列表框内容的测试用例。
　　2、还可以检查交易完成后的确认对话框。可以检查对话框的标题。图象比较也可以检查确认对话框，但图象比较容易受其他因素影响。
　　3、修改脚本，SQA Basic提供了强大的数据库支持。

　　2、域的验证

　　各种不同的域选择相应的测试用例。

　　3、用户界面测试

　　对象状态测试用例

　　4、性能标准

　　等待状态测试用例

　　5、压力下的操作

　　6、访问控制

　　Object state test case

　　7、配置测试

　　不能选择图象测试用例（也分辨率有关）和文件测试用例（与驱动器有关）

　　8、安装选项和验证

　　对象状态用例和窗口存在用例，文件存在用例。

书写测试设计的步骤

　　　　生成测试需求报告
　　　　　　　↓
　　　　　指定测试过程
　　　　　　　↓
　　　指定测试用例（可选）
　　　　　　　↓
　　　　回顾测试覆盖率

第三部分：测试开发

输入：被测软件、基于测试需求的测试设计

输出：测试过程和测试用例

目标：

　　1、创建可以重用的测试过程和测试用例
　　2、维护测试过程、测试用例与相关测试需求的一一对应。

测试开发的问题：

　　1、测试开发很乱，与测试需求或测试策略没有对应性
　　2、测试过程不可重复或不可重用
　　3、测试过程被作为一个编程任务来执行，导致脚本太长，不能满足软件移植性的要求。

错误处理

　　当测试过程发生错误时，有几种解决办法：

　　1、跳转到别的测试过程
　　2、调用一个能够清除错误的过程
　　3、退出过程，启动另一个
　　4、退出过程和应用程序，重新启动启动Windows，在失败的地方重新开始测试

测试开发的步骤

　　1、设立开发环境

　　　　SQA Suite
　　　　连接到SQA存储库
　　　　启动SQA Baisc或VB
　　　　被测软件
　　　　等等

　　2、录制和回放原型过程

　　原型过程指出所有未知窗口控制，使得他们都能象标准窗口那样动作或者没有特别的动作，把他们都划归为Generic类型。通过这个过程，SQA Robot就知道该怎样处理应用中的特殊控制。

　　1、把recording option 中的Define Unknown Object as Type Generic选项设置为off
　　2、使用的过程标识符要可以被覆盖，或者能被删掉。因为这只是个原型，用来教SQA Robot 录制的过程

　　3、录制测试过程和测试用例

　　1、录制模块测试过程和与测试需求最低层对应的测试用例；
　　2、录制初始化过程；
　　3、录制导航过程，把前面的过程串起来；

　　4、测试和调试测试过程

　　5、修改测试过程（可选）

　　6、建立外部数据集合

　　如果测试过程是用来循环一套输入和输出数据，就需要建立数据集合。

　　7、重复测试和调试测试过程，回到4

第四部分：测试执行

测试执行的问题

　　1、自动化测试没有有效的利用，使得手工测试太多。
　　2、测试结果的捕获没有系统性，而且没有查看或调查
　　3、缺陷报告必须用手工加入缺陷跟踪系统

错误分类

　　1、测试用例失败

　　　　正常错误

　　2、脚本命令失败

　　　　当测试过程不能不能执行录制过程中的某个功能时，回产生这种错误，如鼠标单击按钮或选择菜单项等。它也能指示是缺陷还是测试过程的设计问题。

　　3、致命错误

　　　　导致测试停止，这种情况最好重起Windows。

具体步骤：

　　1、建立测试系统
　　2、准备测试过程
　　3、运行初始化过程
　　4、执行测试
　　5、从终止的测试恢复
　　6、验证预期结果
　　7、调查突发结果
　　8、记录缺陷日记

第五部分：测试评估

测试评估的目标

　　1、量化测试进程
　　2、生成缺陷和测试覆盖率的总结报告

测试评估的问题

　　1、没有把测试覆盖率作为报告测试进程的根据，使得不知测试是否结束；
　　2、没有做缺陷评估，缺陷评估是量度软件可行性的重要指标；
　　3、不使用专门的软件工具进行数据输入任务和相应的评估活动，使得这些任务变得繁重累人。

测试覆盖率

　　评估测试完成多少的标准

缺陷评估

　　评估软件质量的重要指标，通常评估模型假设缺陷的发现是呈泊松分布的；严格的缺陷评估要考察在测试过程中发现缺陷的间隔时间长短。评估要估计软件当前的可靠性并预测随着测试的继续进行，软件可靠性会怎样提高。

　　SQA Suite 提供四种形式进行缺陷评估：

　　1、缺陷分布报告可以生成缺陷数量与缺陷属性的函数。如测试需求和状态。
　　2、缺陷趋势报告可以看出缺陷增长和减少的趋势；
　　3、缺陷年龄报告展示一个缺陷处于某种状态的时间长短
　　4、测试结果进度报告展示测试过程在被测应用的几个版本中的执行结果以及测试周期。

具体步骤

　　1、回顾测试日记

　　2、评估测试需求的覆盖率

　　3、分析缺陷

　　4、决定是否达到完成测试的标准，没有满足标准时

　　　　1、再测试
　　　　2、降低标准
　　　　3、确定软件的一个满足标准的子集，看是否可以发布。

中科院Java Eclipse视频教程—-乐视清晰版全集

    本视频为中科院新科海学校和v512工作室共同出品,刘伟,张利国老师主讲.更多信息请访问:http: //www.jobedu.com.cn/,咨询QQ:373750059,903367690,电 话:010-82622282,010-82622285.

　　自动化的最终目标是什么？

　　很多人以为是像工业革命一样消灭手工劳动者，在这里等于手工测试人员。但是测试存 在一个目前来看还算正确的、其他行业不多见的悖论：任何时候，你都不能准确知道还有多少bug，就像警察不能准确知道还有多少贼一样。所以自动化的最终目 标——目前来说——是解放尽量多的人手去进行更多的测试，除非有一种手段能像《少数派报告》里面的预言少女一样预知所有的bug。因为永远有bug，有未 知的bug，所以目前不存在能覆盖所有bug的手段，这意味着总需要人的参与。现代化手段只是减少了而不是杜绝对人员的需求。所以如果认为自动化工作一做 完就没活干，那你就大错特错了。正认为这些人闲下来，他们有空发现更难发现的bug。这本来没什么大不了的，但是搁在计划阶段如果过分乐观，牛皮吹得太大 的话，到后面就不容易圆回去了。因为按上面分析，自动化测试总有些地方是力有不逮的，如果这些地方没有安排好人手时间，只要在这些地方出大问题，那你就玩 完了。

　　能否/怎样自动验证？

　　这个问题每次复审测试计划的时候我都会问，针对每一个提出要实施自动化的地方。每个人、每个工具 谈论自动化的时候都在说如何真实模拟用户使用产品的情况， 这很好，绝对需要关心。不过我得问一句：测试的最后结果是什么？如果你回答“各种使用产品的场景已经运行过“就嘎然而止的话，你就漏掉了一大块：最起码还 得加上“产品能工作/不能工作“！所以模拟用户使用产品的各种情况，只是解决上述问题的第一部分；如何得出测试通过/不通过的最终结论，才是解决问题第二 部分的基础部分，还有详细缺陷描述、上下文数据收集等没做到呢！

　　所以让机器像人一样使用产品，并没有解决全部问题，剩下的事情还有多少，这是需要视情况而定的。如果只是解决了第一个问题就认为万事大吉，那简直就是在赌运气——有些时候自动验证是小菜一碟，但很多时候不是。

　　令事情恶化的是，自动验证了产品的一些指标，并不能反映产品的真实质量。有时验证过的指标通过 了，其实其他地方暴露了问题却没有检查：比如说界面说没有查询结果，这是期望的，实际上查询请求根本没有发过去，不去检查底下做了什么的话是发现不了这种 bug的；有时验证过的指标不通过，其实只是个小问题，大问题需要通过别的指标暴露出来的：比如说返回结果跟预期的不一致，实际上该有的都有，只是没有排 好顺序而已，但是被标记成重要的测试用例没有通过，把开发人员搞个鸡飞狗跳。

　　这个话题深入下去，那就涉及到白箱测试策略、逻辑推演、嗅探和代码注入以及布景伪造（environment mockup）等领域，但我想强调的只是，如果考虑自动化测试，自动验证绝对不是可忽略的问题。

　　整合现有还是自力更生？

　　这个话题用于辩论赛是最好不过的，它符合“没有定论“这个要求 。所以我只谈一下使用每种手段时的一些不正确的假设。

　　“现有的工具多少经过测试，质量比自己做的更有保证“。先不在“是不是更有保证”这个话题上钻牛 角尖，我们先关注几个问题：整个测试方案里面哪些部分是关键，质量不好会导致致命后果的？这些部分有专人保证质量吗？出事的时候反应时间和修复效果如何？ 如果这些问题的答案是“我充分了解”或者“没问题”，那我也同意这个观点（我敢打赌，回答“不清楚”或者“很不妙”的人已经跑去重新考虑整个测试方案 了）。

　　“整合现有的工具省时间和人力”。类似的几个问题：你能在这些工具中自由地调试产品的缺陷吗？整合方案能适应产品的演变吗？几个月后呢？几个版本后呢？有需要变动的话代价多少？（哗啦啦又跑掉一大队人了）

　　“自力更生好控制”。投入产出比如何？引用的技术可靠吗？如果你是开发者（之一），别人都觉得好控制吗？谁来测试你的自力更生成果？

　　“有些事情必须得自力更生“。剪裁现有工具难度如何？时间允许吗？

　　其实，纵观所有提出的问题，我想强调的一点是，自动化测试的开发跟产品开发一样，也是需要规划和管理的，回答这些问题也是自动化测试项目管理的一部分。

　　如何解决历史遗留问题？

　　折腾上个版本的自动化测试框架是新人最头疼的事情。但了解了一些事情之后，原先的事情就没那么令 人头疼了。很多人忙于了解旧框架本身，其实世界一直在变，现在项目需要解决的问题才是关键。无论上个版本的东西多么辉煌，只有它适合现在的项目（的部分） 才是有价值的。所以关于旧的自动化测试技术，了解什么能用得上，而不是了解它是什么，才是需要做的事情。就好像汽车修理工知道怎样拆旧车零件来修新车，并 不需要他知道怎样造一辆出来或者知道怎样修好旧的那辆。

　　另一个极端是“旧的不好浪费，继续用“。“能用“这个结论是基于以前项目的情况的，现在能不能用，值不值得用得看现在的需求。人们要理发就是个很好的例子：总不能因为头发长出来要耗养分不好浪费，就一辈子都不剪吧？

　　本文介绍了基于B/S模式的软件缺陷跟踪管理系统的设计与实现。软件缺陷是在软件生命周期中不可避免的对象。缺陷跟踪管理是软件管理的重要组成。现有管理方法是将进入到系统中的问题,都认为是软件缺陷进行处理。但是实际情况却可能有虚假或重复的缺陷报告。不及时处理这些问题,它本身又可能形成新的缺陷。从软件系统考虑,应将软件缺陷跟踪管理纳入到项目管理信息系统之中,成为项目管理信息系统的一个子系统。对维护人员提交的缺陷报告认真鉴定、筛选、分类,进入不同的处理流程,以获得真正的缺陷跟踪数据。本文在分析讨论这些问题的基础上,提出新的软件缺 陷跟踪管理系统的总体结构。

　　软件缺陷跟踪管理系统在现代软件开发中已经占据了很重要的位置。每一个软件组织都知道必须妥善处理软件中的缺陷。这是关系到软件组织生存、发展的质量根本。可遗憾的是，并非所有的软件组织都知道如何有效地管理自己软件中的缺陷。CMM及CMMI都对软件缺陷跟踪给予了关注并做出了相关规定。本文的侧重点放在了讨论这个程序的需求分析、设计、实现及所用到的项目管理知识。借着实现这个简单的缺陷跟踪系统，探讨了个人软件开发过程当中遇到的各种问题，以及解决它们的方法，展示了个人软件开发的一般过程。

　　缺陷跟踪管理是测试工作的一个重要部分，测试的目的是为了尽早发现软件系统中的缺陷，因此，对缺陷进行跟踪管理，确保每个被发现的缺陷都能够及时得到处理是测试工作的一项重要内容。

　　1、 缺陷跟踪管理的目标

　　缺陷能够引起软件运行时产生的一种不希望或不可接受的外部行为结果，软件测试过程简单说就是围绕缺陷进行的，对缺陷的跟踪管理一般而言需要达到以下的目标：

　　确保每个被发现的缺陷都能够被解决；这里解决的意思不一定是被修正，也可能是其他处理方式（例如，在下一个版本中修正或是不修正），总之，对每个被发现的BUG的处理方式必须能够在开发组织中达到一致；

　　收集缺陷数据并根据缺陷趋势曲线识别测试过程的阶段；决定测试过程是否结束有很多种方式，通过缺陷趋势曲线来确定测试过程是否结束是常用并且较为有效的一种方式。

　　收集缺陷数据并在其上进行数据分析，作为组织的过程财富。

　　上述的第一条是最受到重视的一点，在谈到缺陷跟踪管理时，一般人都会马上想到这一条，然而对第二和第三条目标却很容易忽视。其实，在一个运行良好的组织中，缺陷数据的收集和分析是很重要的，从缺陷数据中可以得到很多与软件质量相关的数据。

　　2、 缺陷的描述

　　对缺陷的描述应该包含以下的内容： 可追踪信息

　　缺陷ID：唯一的缺陷ID，可以根据该ID追踪缺陷

　　缺陷基本信息

　　缺陷状态：缺陷的状态，分为“待分配”、“待修正”、“待验证”、“待评审”、“关闭”

　　缺陷标题：描述缺陷的标题

　　缺陷的严重程度：描述缺陷的严重程度，一般分为“致命”、“严重”、“一般”、“建议”四种

　　缺陷的紧急程度：描述缺陷的紧急程度，从1－4，1是优先级最高的等级，4是优先级最低的等级

　　缺陷提交人：缺陷提交人的名字（邮件地址）

　　缺陷提交时间：缺陷提交的时间

　　缺陷所属项目/模块：缺陷所属的项目和模块，最好能较精确的定位至模块

　　缺陷指定解决人：缺陷指定的解决人，在缺陷“提交”状态为空，在缺陷“分发”状态下由项目经理指定相关开发人员修改

　　缺陷指定解决时间：项目经理指定的开发人员修改此缺陷的deadline

　　缺陷处理人：最终处理缺陷的处理人

　　缺陷处理结果描述：对处理结果的描述，如果对代码进行了修改，要求在此处体现出修改

　　缺陷处理时间：缺陷处理的时间

　　缺陷验证人：对被处理缺陷验证的验证人

　　缺陷验证结果描述：对验证结果的描述（通过、不通过）

　　缺陷验证时间：对缺陷验证的时间

　　缺陷的详细描述：对缺陷的详细描述；之所以把这项单独列出来，是因为对缺陷描述的详细程度直接影响开发人员对缺陷的修改，描述应该尽可能详细

　　测试环境说明：对测试环境的描述

　　必要的附件：对于某些文字很难表达清楚的缺陷，使用图片等附件是必要的

　　除上述描述项外，从统计的角度出发，还可以添加上“缺陷引入阶段”、“缺陷修正工作量”等项目。

　　3、 缺陷管理的一般流程

　　缺陷管理的流程比较简单，图1是一个缺陷状态图。

　　流程中的角色：

　　1、 测试人员：进行测试的人员，缺陷的发起者；

　　2、 项目经理：对整个项目负责，对产品质量负责的人员；

　　3、 开发人员：执行开发任务的人员，完成实际的设计和编码工作；

　　4、 评审委员会：对缺陷进行最终确认，在项目成员对缺陷达不成一致意见时，行使仲裁权力。

　　缺陷的状态

　　1、 初始化：缺陷的初始状态；

　　2、 待分配：缺陷等待分配给相关开发人员处理；

　　3、 待修正：缺陷等待开发人员修正；

　　4、 待验证：开发人员已完成修正，等待测试人员验证；

　　5、 待评审：开发人员拒绝修改缺陷，需要评审委员会评审；

　　6、 关闭：缺陷已被处理完成。

　　4、 缺陷数据统计

　　如前所述，缺陷数据统计也是缺陷跟踪管理系统的目标。一般而言，生成的缺陷数据统计图表包括缺陷趋势图、缺陷分布图、缺陷及时处理情况统计表等。

　　5、 缺陷跟踪管理系统

　　目前已有的缺陷跟踪管理软件包括Compuware公司的TrackRecord软件（商业软 件）、Mozilla公司的Bugzilla软件（免费软件），以及国内的微创公司的BMS软件，这些软件在功能上各有特点，可以根据实际情况选用。当然， 也可以自己开发缺陷跟踪软件，例如基于Notes或是ClearQuese开发缺陷跟踪管理软件。我公司采用的是自己开发的基于Notes的缺陷跟踪系统，除了具有上述功能外，还能够通过Notes的邮件系统方便地向相关人员发送提醒信息（缺陷处理超时提醒、缺陷待处理提醒等）。

　　除此之外，作为一个缺陷跟踪管理系统，还必须注意权限分配的问题。缺陷记录作为软件开发过程中的 重要数据，不能轻易被删除；对于已经关闭的缺陷，也不能随意进行修改。因此，缺陷跟踪管理系统必须设置严格的管理权限，非相关人员不得进行相应操作，修改相应数据。在这一点上，通过Notes也很容易控制。

中科院Java WEB开发视频教程—-乐视清晰版全集

淘宝网上订购		新科海名师视频课程－Java WEB视频课程光盘 一口价 10.00

中科院Java WEB开发视频教程 本视频为中科院新科海学校和v512工作室共同出品,刘伟,张利国老师主讲.清晰版下载:http://www.verycd.com/topics /215898/.更多信息请访问网站:http://www.jobedu.com.cn/,咨询QQ:373750059,903367690,电 话:010-82622282,010-82622285.院校合作:010-82608892.

循序渐进学习QTP–初级篇

      我们使用QTP的目的是想用它来执行重复的手动测试，主要是用于回归测试和测试同一软件的新版本。因此你在测试前要考虑好如何对应用程序进行测试，例如要测试那些功能、操作步骤、输入 数据和期望的输出数据等。
      强烈建议你按照版主oldsidney 写的 Tutorial_oldsidney_cn.pdf 文件来认认真真、从头到尾地执行一遍，包括录制脚本、分 析脚本、增加check point、Split Action等。我想这会减少你在学习QTP过程中的不少困惑和疑虑。
      这篇文档对如何使用QTP写的非常详细，是QTP初学者的经典教材。我就是看了这篇文档后才对QTP的整个测试流程有了一个初步的认识。在此，我对 oldsidney表示感谢。
     注意：
      1，确保你的IE运行正常，依次点击菜单 查看 –> 工具栏，一定要上网助手等插件卸载掉，特别3721这个垃圾网站和其它拦截广告的插件（它也把测试过程中弹出的窗口当成广告，一样会拦截的！）！
    2，如果是按照Tutorial_oldsidney_cn.pdf 文件 中的订购飞机票的例子来练习 QTP的使用，那么只需选择Web 插件就可以了。如果是测试其它的应用程序或系统，就要根据需要来选择相应的插件了。

循序渐进学习QTP—中级篇
在这个阶段你就要自己针对某个系统去录制脚本、维护脚本了。在录制后的回放过程中，你可能会遇到各种问题，这个时候就需要发挥你的主观能动性来解决遇到的 问题。我想你可以按照下面的方法去解决：

       1，查看QTP的有关文档，包括Help 、QTP User’s Guide等文档。这些都是比较系统全面的学习材料。你该好好利用呀。
       2，在本论坛上查看以前别人是如何解决此类问题的（如果有的话）或者是发新贴寻求帮助，也可以搜索Google 等网站寻找问题的解决方法；
      3，与自己部门的同事交流，例如与测试人员交流他们是如何解决的，与开发人员交流某个QTP无法识别的控件具体是用什么属性 来识别的等。毕竟他们对测试的环境和测试的软件比论坛上的人熟悉呀。
      4，自己通过学习VBScript 等方式来提高自己的管理QTP Script的能力。

或许你会发现许多问题都是由提出问题的人来解决的，因为他们希望问题得到解决的迫切心比谁都强烈。

循序渐进学习QTP—高阶篇
如果你对VB Script 、QTP和需要测试的程序或系统非常熟悉，你可能就想直接写QTP Script来表现一下了。如果你能达到这个水平，那么恭喜你－－－你就是真正的高手了。这个时候你已经可以从宏观上把握QTP了，也能灵活自如地使用 QTP了。偶离这个阶段还好远呢。

中科院Java开发杂项专题视频—-乐视清晰版全集

《中科院Java开发杂项专题视频》

本视频为中科院新科海学校和v512工作室共同出品,刘伟,张利国老师主讲.清晰版下 载:http://www.verycd.com/topics/215898/。更多信息请访问网站:http: //www.jobedu.com.cn/,咨询QQ:373750059,903367690,电 话:010-82622282,010-82622285.院校合作:010-82608892.