该空间是我专为记录工作而开，非常乐意公开和大家分享！

由于有些文章受当时情绪情感的影响包含了一些私人的东西，事后本人又觉得不便公开，可又觉得文章衔接自然，舍不得删减，惟有加密设为私有。

为点缀生活，自得其乐，文章写完后会公开一天，有缘者读到了，那就是有缘了！！！

6.     游标：cursor 

游标（cursor）提供了这种机制: 它能保证每次处理结果集(如select的查询结果集）中的一行或一部分行.

游标的使用过程：

  声明游标- DECLARE <游标名> CURSOR FOR <集/表>

  打开游标- OPEN

  读取数据- FETCH ...  FROM  <游标名>  INTO ...

  关闭游标- CLOSE    //关闭后，使用OPEN依然可以再打开它

  释放游标- DEALLOCATE     //不能再使用此游标

例.

DECLARE st_cursor CURSOR   //st_cursor为游标名

FOR

SELECT Sno,Sname,Cno FROM Student 

OPEN st_cursor

FETCH NEXT FROM st_cursor INTO @Sno, @Sname, @Cno    //将提取的值放入变量@Sno, @Sname, @Cno 中

WHILE @@FETCH_STATUS = 0   // "@@FETCH_STATUS" 是专门用来存放游标的状态的

BEGIN

  操作...

  FETCH NEXT FROM st_cursor INTO @Sno, @Sname, @Cno

END

CLOSE  st_cursor

7.     视图：view

视图 是从一个或几个基本表导出的表，它与基本表不同，是一个虚表，数据库中只存放视图的定义，而不存放视图对应的数据，这些数据存放在原来的基本表中，当基本表中的数据发生变化，从视图中查询出的数据也就随之改变。
视图 一经定义就可以像基本表一样被查询、删除、有限更新。

优点：
1. 视图能够简化用户的操作
   为复杂的查询建立一个视图，用户不必键入复杂的查询语句，只需针对此视图做简单的查询即可。
2. 视图使用户能以多种角度看待同一数据
   视图机制能使不同用户从不同视角看待同一数据，适应数据库共享的需要。
3. 视图能够对机密数据提供安全保护
   对不同用户定义不同视图，使每个用户只能看到他有权看到的数据。

格式：

CREATE  VIEW 
      <视图名>  [(<视图属性列表>)]
      AS  <子查询>
      [WITH CHECK OPTION]

例子：
CREATE VIEW STUDENT_VIEW
               AS
               SELECT *
               FROM    Student
               WHERE  class='95031'
               WITH CHECK OPTION  
// “WITH CHECK OPTION” 强制视图上执行的 “所有数据更新语句” 都必须符合 “子查询中WHERE子句” 中的条件 （在此是：class='95301', 所以所有试图将此视图某行的class改为其他值的更新操作都不被允许, 如执行以下更新语句将报错：

UPDATE STUDENT_VIEW
SET class='95033'
WHERE sno='103'

1.     创建表，同时定义完整性约束：

CREATE TABLE 

[CONSTRAINT <约束名>] <约束类型>

CREATE TABLE Student

(

 Sno CHAR(8)  CONSTRAINT  S_CONS  NOT NULL， // Sno属性不能为空

 Cno CHAR(8)  CONSTRAINT  C_FORE  FOREIGN KEY  REFERENCES Course(Cno), //属性Cno 是外部键，它是表“REFERENCES Course”的主键Cno

 Sname VARCHAR(20)  CONSTRAINT  Sn_UNIQ UNIQUE,  //Sname属性取值唯一

 Sage INT,

 Ssex CHAR(2) ,

 Sdept VARCHAR(20)，

 CONSTRAINT  Sno_PRIM  PRIMARY KEY  (Sno,Cno)    //将(Sno,Cno)属性组设为主键

);

2.     修改基本表 <针对列的操作> ：

ALTER TABLE

1. ADD方式：增加新列

例.  在Student表中增加一个班号列和住址列：

ALTER TABLE Student

ADD

Class_NO  CHAR(6),

Address  CHAR(40)

      2. ALTER COLUMN方式：修改某些列

例.  把Student表中的Sno列加宽到10位字符宽度:

ALTER TABLE Student

ALTER COLUMN

Sno CHAR(10)

      3. DROP CONSTRAINT方式: 删除某列的完整性约束

例.  删除Student表中的Ssex约束

ALTER TABLE Student

DROP CONSTRAINT Ssex

      4. DROP COLUMN方式：删除列

例.  删除Student表中的Sdept列

ALTER TABLE Student

DROP

COLUMN Sdept

 3.     删除表

       DROP TABLE <表名>

4.     数 据 更 新 <针对行的操作>  

     1  插入行：INSERT INTO <表名> VALUES(....)

例.  向Student表中插入一行，只有Sno, Cno属性有值，其他属性为空：

INSERT

    INTO Student(Sno,Cno)

VALUES ('95020','1')

     2  修改行：UPDATE <表名> SET...[WHERE <条件>]

例.  将学生95001的年龄改为22岁:

UPDATE  Student

         SET Sage=22

         WHERE  Sno='95001'

     3  删除行：DELETE FROM  <表名> [WHERE <条件>]

例.  删除学号为95019的学生记录：

DELETE FROM Student

     WHERE Sno='95019'

5.     查询: 

SELECT  FROM <表名>

[WHERE <条件>]

[ GROUP BY]

[ HAVING <条件>]

[ ORDER BY ]

HAVING子句：使用在GROUP BY子句后，用于筛选出只有满足指定条件的组

例. 查询所有年龄在18 - 25之间的女生的学号、姓名及系号； 查询结果按系分组，且只选出那些含有不止2个满足条件的女生的系；结

果按学号降序排列。

SELECT Sno,Sname,Sdept

 FROM    Student   

WHERE Sage BETWEEN 18 AND 25 AND Ssex='F'

GROUP BY Sdept

HAVING COUNT(*) >=2

ORDER BY Sno DESC

 下一篇：SQL 数据库De基本操作 < 二 >

需填项

• 指定处理人（Assigned To）
  可以指定一个处理人
  如不指定处理人，则系统指定管理员为默认处理人

• 超链接（URL）
  输入超链接地址，引导处理人找到与报告相关联的信息

• 概述（Summary）
  概述部分“Summary”的描述，应保证处理人在阅读时能够清楚提交者在进行什么操作的时候发现了什么问题。
  如果是通用组件部分的测试，则必须将这一通用组件对应的功能名称写入概述中，以便今后查询。

• 硬件平台和操作系统（Platform. and OS）
  测试应用的硬件平台（Platform），通常选择“PC”
  测试应用的操作系统平台（OS）

• 版本（Version）
  产生该Bug的软件产品版本

• Bug报告优先级（Priority）
  分五个等级即P1-P5，P1的优先级别最高之后逐级递减

• Bug严重性（Severity）
  Blocker：  阻碍开发和/或测试工作
  Critical： 死机，丢失数据，内存溢出
  Major： 较大的功能缺陷
  Normal： 普通的功能缺陷
  Minor： 较轻的功能缺陷
  Trivial： 产品外观上的问题或一些不影响使用的小毛病，如菜单或对话框中的文字拼写或字体问题等等
  Enhancement： 建议或意见

• 报告人（Reporter）
  Bug报告提交者的账号

• 邮件抄送列表（CC List）
  Bug报告抄送对象，该项可以不填
  如需要抄送多人，可将邮件地址用“，”分隔

• 从属关系（Bug “ID” depends on，Bug “ID” blocks）
  “Bug ‘ID’ depends on”： 如果该Bug必须在其他Bug修改以后才能够修改，则在此项目后填写那个Bug的编号
  “Bug “ID” blocks”： 如果该Bug的存在影响了其他Bug的修改，则在此项目后填写被影响的Bug编号

• 附加描述（Additional Comments）
  在Bug跟踪过程中测试与开发人员通过这里进行沟通
  开发人员可以在这里填写处理意见和处理记录
  测试人员可以在这里填写返测意见和对在返测过程中发现的新问题进行描述

一个bug的 6 种状态：
ｎｅｗ：　        意味着这个ｂｕｇ是新发现的，等着被扫描。
ａｓｓｉｇｎｅｄ： 意味着这个ｂｕｇ已经被分到合适的人去处理，但还没被解决掉
ｒｅｏｐｅｎｅｄ：　意味着这个ｂｕｇ曾被处理过，但处理得不正确。
ｒｅｓｏｌｖｅｄ：　意味着ｂｕｇ已处理过了，现等着被验证
ｖｅｒｉｆｉｅｄ：　意味着测试ｔｅａｍ已经对这个ｂｕｇ的处理进行了验证，并且同意这种处理方式。若不认可的话，则会将此bug的状态改为ｒｅｏｐｅｎｅｄ。

ｃｌｏｓｅｄ：　    意味着这个ｂｕｇ被正确处理掉了，且一致通过。

如图：

一个bug的 5 种处理结果：

一个bug分到相关人后， 相关人士对它的处理会产生 5 种结果， 即当一个ｂｕｇ的状态为 ｒｅｓｏｌｖｅｄ 时， 这个ｂｕｇ经处理后的结果可能有如下 5 种：
ｆｉｘｅｄ：　     意味着这个ｂｕｇ被ｆｉｘｅｄ掉了。
ｉｎｖａｌｉｄ：　  意味着这不是一个ｂｕｇ
ｗｏｎｔｆｉｘ：　  意味着这是一个ｂｕｇ，但不能被ｆｉｘｅｄ掉，或者超出了我们的工作范围。
ｄｕｐｌｉｃａｔｅ：　 意味着这是一个重复的ｂｕｇ
ｗｏｒｋｓｆｏｒｍｅ：　意味着“所有重现此ｂｕｇ的工作都是徒劳的，也并不能从代码中找到任何解决的线索。如果今后获得了更多的信息，该ｂｕｇ可被重新开放”。

工作以来的第一次面试， 砸了， 项目也砸了！

关于杀毒软件的测试项目， 电话面试， 面试者为台湾人。理由：Windows基础知识都没有！无troubleshooting经验！

面试是一个一个单独进行， 先介绍自己的测试项目经验， 以及测试特长， 接着是问答， 问及：

1 测试执行效率（case数/天）经验；

2 什么是troubleshooting，如何正确troubleshooting？

3 什么是Windows的safe模式（因为此方面与安全有关）；

4 Vista系统的自动防护机制了解吗？

5 使用过哪些杀毒软件，遇到问题时都是如何处理的？

从第2个问题起，开始犯蒙，对于如何正确定位和判断一个trouble（trouble并非指bug，指的是杀毒软件的配置/使用等方面的问题，而导致测试工作遇到阻碍）一无所知； 对于“safe mode”“vista 的防护机制”也了解得很少； 至于谈到“杀毒软件的使用”， 自己也从没有去了解过一个杀毒软件的工作流程等， 当此软件遇到问题时我又该如何在这个软件中定位问题，并试着处理！

心得：

很久没有面试过了，真的有些紧张。

一开始就有点犯虚， 因为不知道接下来要面对什么样的问题。

加上自己也很少做过工作总结， 对自己过去的工作经验很模糊， 一时没法找到亮点。

没有认真对待这场面试， 没有任何准备工作， 没有去思考这个项目对测试人员的要求（例如，问到了一些windows的基础知识，因为这些测试工作就是要在windows下执行的）。

没有正确的心态应对面试过程中的失误/意外，当回答错误或者无法回答时开始慌乱，我想跟着对方的纠正学习并证明已经懂得或者请教对方会更好。

面试者也是凡人，不是审判官，不止自己为了面试成功在“受苦”，他也在为了他的面试工作而辛苦着。

体谅！ 懂礼！ 给彼此一个轻松的环境！

前车之鉴 后事之师！  到要换工作时，希望能有所帮助！ 

555... 过去了！ 

运行安装Vmware；

输入序列号；

启动Vmware；

点击 <Create a New Virtual Machine>;

创建一个虚拟机： 定制操作系统的框架（如XP），为这个虚拟机命名，指定硬盘空间的大小等等；

创建好后，点击 <Open a existing Virtual Machine>，打开刚创建的虚拟机；

将此虚拟机对应的CD-ROM的位置改为CD-ROM的实际盘符（如 D:）；

在CD-ROM中插入Windows XP的安装盘；

点击 <Start Virtual Machine>；

进入BIOS，改为从CD-ROM启动；

开始安装XP系统，过程和在实机上一样；

安装好后，记住 进入BIOS，改为从hard 0启动。

之后，每次打开 Vmware 后，都可以点击 <Open a existing Virtual Machine>，即可打开这个XP系统。

可以复制这个已创建好的虚拟机， 以备今后需要。以后要用时，只需将它拷贝到"Vmware Machines"目录下。

为了实现本机和虚拟机之间的文件传输，可用 Ipmsg 实现。

6sigma

   6σ管理法是一种统计评估法，核心是追求零缺陷生产,防范产品责任风险，降低成本，提高生产率和市场占有率，提高顾客满意度和忠诚度。
   "σ"是希腊文的一个字母，在统计学上用来表示标准偏差值，用以描述总体中的个体离均值的偏离程度，测量出的σ表征着诸如单位缺陷、百万缺陷或错误的概率性，σ值越大，缺陷或错误就越少。

   6σ是一个目标，这个质量水平意味的是所有的过程和结果中，99.99966% 是无缺陷的，也就是说，做100万件事情，其中只有3.4件是有缺陷的，这几乎趋近到人类能够达到的最为完美的境界。6σ理论认为，大多数企业在3σ～4σ间运转，也就是说每百万次操作失误在6210～66800之间，这些缺陷要求经营者以销售额在15%～30%的资金进行事后的弥补或修正，而如果做到6σ，事后弥补的资金将降低到约为销售额的5%。

西格玛水平
　6个西格玛＝3.4失误/百万机会：意味着卓越的管理，强大的竞争力和忠诚的客户

　5个西格玛＝230失误/百万机会：优秀的管理、很强的竞争力和比较忠诚的客户

　4个西格玛＝6,210失误/百万机会：意味着较好的管理和运营能力，满意的客户

　3个西格玛＝66,800失误/百万机会：意味着平平常常的管理，缺乏竞争力

　2个西格玛＝308,000失误/百万机会：意味着企业资源每天都有三分之一的浪费

　1个西格玛＝690,000失误/百万机会：每天有三分之二的事情做错的企业无法生存

  6SIGMA管理的核心牲特征:顾客与组织的双赢以及经营风险的降低。

QA: 软件质量保证（SQA）
   是建立一套有计划，有系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。软件质量保证的目的是使软件过程对于管理人员来说是可见的。
   目前，实施CMM的企业越来越多了。CMM模型就要求建立QA角色。这里的QA类似于过程警察，主要职责是，检查开发和管理活动是否与已定的过程策略、标准和流程一致，检查工作产品是否遵循模板规定的内容和格式。在这些企业中，一般还要求QA独立于项目组，以保障评价的客观性。

QC：质量控制

QA与QC两者基本职责: 

QC：检验产品的质量，保证产品符合客户的需求；是产品质量检查者；
QA：审计过程的质量，保证过程被正确执行；是过程质量审计者；

注意区别检查和审计的不同:
检查：就是我们常说的找茬，是挑毛病的；

审计：来确认项目按照要求进行的证据；仔细看看CMM中各个KPA中SQA的检查采用的术语大量用到了“证实”，审计的内容主要是过程的；对照CMM看一下项目经理和高级管理者的审查内容，他们更加关注具体内容。

SEPG：Software Engineering Process Group软件工程过程小组

Metrics：就是体现不同的数据集之间的关系，如：时间和发现的bug数的关系。

点击可参考一些具体的图表

GQM:
为一个项目获得它的metrics的最常用的方法 —
GQM 方法（Goals, Questions, Metrics)：
步骤：
   定出目标(G)，关注客户要求的重点．
　　陈列出为达到目标(G)的相关问题(Q)．
　　获取与合适的metrics(M)以陈述问题(Q).

如：Ｇ－　产品应该是容易维护的
　　Ｑ－　给代码每行加上注释将helpful to the Goal吗？
　　　　　严格控制局域变量的数目将helpful to the Goal吗？
　　　　　严格控制每一个函数的call/return语句将helpful to the Goal吗？

　　 M－ Number of comment lines/LOC
    　　  Number of function calls/return 语句/LOC
          Number of local variables/LOC

PDMR: Project Data and Metrics Report.

MRM: Management Review Meeting （最少每6个月一次）

QIC: Quality Improvement Coucil （最少每个月一次，第六次时就可以进行Domain MRM了）

LAM：Look Ahead Meeting, 在“项目开始时”，以及“项目的每个阶段开始之前”举行。 过去的项目经验和metrics报告是它的输入。

SQC: Statistical Quality Control. 常见的SQC工具有：

1) Pareto Chart

2) Fish Bone Analysis

3) Histogram

4) Control Chart

5) Scatter Plot

对以上工具一一说明如下：

1) Pareto Chart：

构建一个Pareto Chart的步骤：
   为每一个类别／模块搜集数据
   将数据按降序排列
   计算一个个类别／模块累计下来的数据与总数据的百分比
   画图（左轴标示数据，水平底轴标示类别／模块，右轴标示百分比）
   为每个类别／模块画数据方块
   用点标记出每个类别／模块相应的累计百分比
   连接这些点成为一条曲线
   从右轴的80%处向左引出一条水平线与曲线相交，从交点向下引出一条垂直线与水平底轴相交（可知：垂直线左边的类别/模块占据了整个数据的80%，则可以优先考虑它们）

下图是一个Pareto Chart：
 

2) Fish Bone Analysis：是对原因和影响分析。每一个主要原因的类别代表一根骨头；每一个类别的子理由在每一根骨头下被描述出来；头脑风暴技术被用于得到理由。
   这种分析中一个很重要的特征就是不断地问“为什么”，直到陈列尽所有的答案，然后最后一个理由就被标记为根由。
   构建一个fish bone diagram的步骤：
   清晰地定义出defect/problem
   随意分析：头脑风暴法或者structured meetings 被用来找出理由，子里有，根由
   列出所有的根由并且将他们归组于一个类别中
   为每一个根由列出预防措施
   列出所有灵活的预防措施，并鼓励有相关能力的成员去执行这些行为
  
例如：问题是：在DEST模块里发现了太多的bugs,这就是一根骨头。这个问题的主要原因有两类：技术问题和对功能的了解程度。 这就得到了两根骨头。
  然后头脑风暴法分别对这两类原因进行讨论，直到不断地讨论出所有的理由，子理由。最后一个理由就是根由了。 

下图是一根“鱼骨头”(用红色框框标记出的就是“根由”）

3) Histogram（直方图）

Histogram是显示数据按不同类别/模块分布的图。它是一个频率分布图。可用于分析过程中数据的变化，通过检查分析这些变化，识别出需要投放更多努力的区域。

以下是一个特定的例子阐述Histogram的构建：

某个公司的报销流程经常性delay，为了找出在报销流程中需要提高的领域，一个histogram被创建出来，参数有发票delay的天数。（假设有100张发票）

Step1: 收集数据，找出最小和最大的数据块，决定数据之间的间隔数，以及间隔宽度

Step2: 找出开始点，建立一个频率表

类别(delay天数)     频率（相应区间的发票数/总发票数）

1-10                 8

11-20                9

21-30                                     12

31-40                                     16

41-50                                     19

51-60                                                     10

61-70                                                        8

71-80                                                        7

81-90                                                        6

91-100                                                     5

画直方图，间隔作为横坐标，频率作为纵坐标

4）Control Chart

一个Control Chart用来监视一个系统怎样随着时间改变的。Xbar, R, XmR, u,c,p,np,z是一些Control Chart的类型，选择什么类型的控制图取决于数据的类型和分布情况。

U Chart:

一个U Chart是用于跟踪每个opportunity所发生的缺陷。标记在U Chart上的属性数据通常用来监测不合规的数据的数量，这些违规数据在预先决定的两个控制极限值之间。

这两个控制极限值是Upper Control Limit(UCL) 和 Low Control Limit(LCL).

一条中心线center line（CL），通常是指平均读数，代表过程中的平均defects数。

UCL和LCL代表了3sigma变化。

一个U Chart的构造步骤：

step1．计算出U bar(等于总共的defects数/总共的size， size如代码的行数)，然后对每个独立点计算相应的UCL和LCL值。

step2．画坐标 size/effort - review number

step3. 辨别处在control limits（即不在LCL与UCL之间的值）以外的点

5）Scatter plot（散点图）

开展自动测试的过程：

6.    过程评估与改进

以下几种情况不适宜进行自动测试

• 测试运行频率比较低
• 软件更改比较频繁
• 测试中涉及物理交互的测试
• 测试结果很容易通过人员验证，而对于自动测试来说又比较难以实现

自动测试的典型应用

1.  自动生成测试用例

2.  GUI自动录制回放

    如工具：

       QARun

       TestPartner

3.  自动化性能测试

    通过录制回放功能，可以很容易地模拟数千个用户同时运行

    如工具：

        QALoad，

        LoadRunner

4.  通过API编程实现自动测试

    通过编程API，建立测试框架，在测试代码中调用这个框架，验证给定输入会得到预期的结果

    工具主要有：JUnit、HttpUnit、各种单元测试工具

5.  测试管理

6.  白盒测试

       源代码审查

       运行期错误检测

       内存分析

       性能分析

       代码覆盖分析

     工具如：logiscope

7.  定制的测试工具

    开发适合于自身要求的测试工具

    如模拟仿真工具：

        仿真无法真实搭建的测试

        如：航天应用、模拟硬件设备

测试工具与软件开发周期关系

测试工具厂商介绍

     * Mercury Interactive

产品：TestDirector，Winrunner，Loadrunner，QuickTest

    * Rational

产品：TestManager，Purify，Quantify，Robot，TestFactory

     * Compuware

产品：QADirector，QARun，TestPartner，QALoad，TrackRecord，Dev Partner

测试工具类型

Defect filing trend: 描述随着时间推移，每天发现新defect的数目（红线）与总defects累计的数目（蓝线）

Mile Stone wise Defects: 描述在项目的各个阶段发现的defect数。
mile stone 指项目阶段，此项目有4个阶段: BF, FM, FC, RC (均为简称）。

Last week Defect status: 描述上周提交的defects数（红色），解决了的defects数（蓝色），以及经过验证了的defects 数（绿色）。

Defect fixing trend: 描述随着时间推移，每天的尚未解决的defects数（红色，此线未完成），解决了的defects数，以及累计下来的已经解决了的和已经验证过的defects数。

Open Defects distribution: 描述不同紧急程度的defects数。

OverAll TestSuite-Milestone-Wise-Defect: 描述在项目的不同阶段(milestone)，各个test suit中所发现的defects数。

RC-Regression status: 描述在RC阶段所进行的回归测试中，两test suit：LV与HV中已经执行了的test case数，以及pass了的test case数。

FC-Regression status: 描述在FC阶段所进行的回归测试中，两test suit：LV与HV中已经执行了的test case数，以及pass了的test case数。