◆选择重复，消除重复和选择出序列

有例表：emp

emp_no name age   
  001 Tom 17   
  002 Sun 14   
  003 Tom   15   
  004 Tom 16

要求：

列出所有名字重复的人的记录

(1)最直观的思路：要知道所有名字有重复人资料，首先必须知道哪个名字重复了：

select   name   from   emp     
  group   by   name   
  having   count(*)   >1

所有名字重复人的记录是:

select   *   from   emp     
  where     
  name   in   (   
  select   name   from   emp     
  group   by   name   
  having   count(*)   >1   
      )

(2)稍微再聪明一点，就会想到，如果对每个名字都和原表进行比较，大于2个人名字与这条记录相同的就是合格的 ，就有

select   *   from   emp   
where   
(select   count(*)   from   emp   
e   where   e.name=emp.name)   
>1

--注意一下这个>1，想下如果是 =1，如果是 =2 如果是>2 如果 e 是另外一张表 而且是=0那结果 就更好玩了:)

这个过程是 在判断工号为001的 人 的时候先取得 001的 名字（emp.name） 然后和原表的名字进行比较 e.name

注意e是emp的一个别名。

再稍微想得多一点，就会想到，如果有另外一个名字相同的人工号不与她他相同那么这条记录符合要求：

select   *   from   emp   
  where   exists   
  (select   *   from   emp   e   where   
e.name=emp.name   and   e.emp_no<>emp.emp_no)

此思路的join写法：

select   emp.*     
  from   emp,emp   e   
  where     
  emp.name=e.name   and   emp.emp_no<>e.emp_no   
  /*   
  这个   语句较规范   的   join   写法是   
  select   emp.*     
  from   emp   inner   join     emp   e   
  on   
  emp.name=e.name   and   emp.emp_no<>e.emp_no   
  但个人比较倾向于前一种写法，关键是更清晰   
  */   
  b、有例表：emp   
  name age   
  Tom 16   
  Sun 14   
  Tom   16   
  Tom 16

提取测试需求是测试活动中的基础工作，是测试活动展开的前提条件。

在项目实施前在做整个系统的测试方案中工作量评估时，如果是基于系统功能点的方法，则已经对系统中的功能点、性能点等进行分析统计，可以直接在该分析结果的基础上进行细化和完善。

在项目测试活动中确定用户需求范围是最重要也最困难的工作之一。往往在项目实施前无法准确界定测试范围，原因很多，主要有以下几个方面：

1、系统用户需求不详细，从而无法确定测试范围；

2、用户需求中简单的描述，可能包括很多研发工作，也需要测试，容易别忽略；

3、行业经验不足，对其中的业务不熟悉，造成对业务功能不能确定；

在测试过程中，带来测试范围变化的原因，主要包括：

1、在开发过程中客户较大的改变原来的需求，扩展原来的需求；

2、开发改变客户的需求，带来测试范围的变化；

综合以上的原因，主要来自于三个方面：

1、客户的需求前期描述不清，后期的增加、修改变化；

2、开发对需求的变更；

3、测试团队对行业或系统业务、项目经验的不足；

对于第1点，可以约定测试用户需求的基线版本，对于研发过程中需求变更超过一定范围，重新评估增加的工作量。

对于第2点，可以同第1点一样，同客户在前期约定好。

对于第3点，则是需要一个过程，业务和项目经验积累需要一个过程。

要确定测试需求，相当于确定了测试范围，则能比较准确的确定工作量。如何分析测试需求呢？

首先、分析用户提供的所有文档，在业务分析师的帮助下，根据业务分解系统功能，由粗到细，逐渐细化需求，这其中需要客户、研发团队的协助，把不清晰、不明确、不具有可测试性的需求转化明确的、具有可测性的需求。根据测试需求对应的集成测试、系统功能测试和性能测试活动不同，其测试需求也不同，例如，对于产品集成测试，则测试需求细化到测试集成的每个模块接口、子系统接口即可。对于功能测试则时一个具体的功能实现，该功能可能时一个典型业务中的一个操作，也可能是整个典型业务。如果是一个典型业务的一个操作功能，则最好把整个典型业务的测试需求串接在一起，形成一个典型业务的测试需求链（具有相关的测试需求形成的一个序列）。

其次、把测试需求尽量使用测试管理工具进行管理，便于测试需求的统计、变更，以及与测试用例形成关联。

测试需求在客户评审通过后，要形成基线，以后用户需求变更后，要进行测试需求的变更，且保持测试需求与用户需求的版本一致。

任务：

1、在Weblogic发布WEB应用程序

1.1配置工作区   用户名：weblogic     密码：weblogic

1.2进入weblogic服务器的管理控制中心进行配置要启动服务器：7001 通过 http：//localhost：7001/console

1.3发布应用诚寻--web程序  完成符合J2EE标准的web目录  -WEB-INF

                                                -web.xml文件（jso2.0、servlet2.4版本）

诚寻的访问http：//localhost：7001/testbea 项目部署上去后服务器必须选择启动项目。

2.在Weblogic 使用数据源连接池 依然使用oracle数据库在Weblogic之中包含了主流数据库的驱动程序

1.软件需求是软件开发最重要的一个输入 ，好的开始是成功的一半！ 所以，需求的质量很大程度上决定了项目质量或产品质量。
2.需求风险常常是软件开发过程中最大的一个风险 ，要降低需求阶段带来的风险，就要把需求评审做好。
3.需求评审做不好的后果：
需求变更
需求不明确
需求不可测
需求不可实现
导致后续工作难于开展或经常出现变更。
4、产品经理：不识庐山真面目，只缘身在此山中，需求是自己写的，容易受到固定思维的限制，所以，需要一双没有看过这个需求的眼睛来检查一下，有什么问题。

先大概说一下需求的不同类型：
需求的不同层次：
目标性需求：定义了整个系统需要达到的目标；
  -高层关注
功能性需求：定义了整个系统必须完成的任务；
  -中层关注
操作性需求：定义了完成每个任务的具体的人机交互；
  -执行人员关注

在做需求评审的时候，应该根据不同的需求层次，进行不同的评审。

因为经常参加需求评审会议，所以对需求评审中常见的问题有所了解，现在举一些例子：
1、某产品经理在主持需求评审会，评审开始时间不长，就被一位主管打断，明确指出此方案与企业业务发展方向不符，不能实施。紧接着其他与会人员纷纷发言表示同意，结果评审会无法继续进行，需求最终被否决。
问题所在：
缺乏初步沟通，目标性需求尚未明确，功能性需求和操作性需求无从谈起。

2、某次需求评审会，主要是公司内部相关领域的专家参加，在评审会开始后不久，某专家就对需求中的某个具体问题提出了自己的不同意见，于是，与会人员纷纷就该问题发表自己的意见，大家争执不下，结果，致使会议出现了混乱状况，主持人无法控制局面，会议大大超出了计划评审时间。
问题所在：
前期沟通和准备不够，缺乏应对不同意见的准备，难以化解争执。
主持者不能有效把握会议目标，会议讨论过于关注细节，导致评审失控。
3、某产品经理主持需求评审会，在讲解需求说明书时，与会人员似懂非懂，没有提出任何有价值的问题，致使会议没有得到预期效果，不得不改日重新进行。
问题所在：
前期准备和沟通不够，评审变成了培训。
没有选择合适的评审人员，无法获得有价值的信息。

4、某需求评审会，与会人员各抒己见，气氛热烈，产品经理忙于收集意见，结果散会时发现对需求有价值的并不多，并且遗漏了许多要评审的问题，评审效果不佳。与会人员在离开会议室后，私下也认为评审没有多少实际效果，完全是在走过场。
问题所在：
评审缺乏有效依据和规范，不能保证评审的覆盖率和有效性。
产品经理没有把握好会议主题，评审变成了头脑风暴。

需求评审常见问题汇总
目标性需求没有沟通好，后面的需求变成空中楼阁。
缺乏评审的可操作依据，遗漏评审内容。
没有作好前期准备工作，导致评审时间长，效率低。
没有选择合适的评审人员，无法获得有价值的反馈。
参加人员过多，容易陷入细枝末节的讨论，会议演变成一场人人自由的混战。

针对以上问题，提出一些建议：
建议一、做好评审前的沟通和准备
需求编写人员应将评审所需的资料准备齐全，数据、图表、其他相关资料等，并仔细检查以保证文档质量。
需求文档在评审会议前应提前下发给参与评审会议的人员，并留出时间让参与评审的人员阅读需求文档。
参加评审的人，应该是带着问题而来，而不是来参加培训的。

建议二、先沟通好目标，再进行细节的落实。
应该在需求形成的过程中进行分阶段的评审，而不是在需求最终形成后再进行评审。
分阶段评审保证了需求在形成的过程中不偏离方向，不出现大的错误，降低了需求返工的风险，提高了最终评审的质量

建议三、正式评审与非正式评审相结合
正式评审
是指通过开评审会的形式，组织多个专家，将需求涉及到的人员集合在一起，并定义好参与评审人员的角色和职责，对需求进行正规的会议评审。
非正式的评审
通过电子邮件、文件汇签甚至是网络聊天等多种形式对需求进行评审。 两种形式各有利弊，因此在评审时，根据项目复杂程度，紧急程度不同，应该灵活地利用这两种方式。

建议四、精心挑选评审员
为了保证评审的质量和效率，需要精心挑选评审员。
首先要保证使不同类型的人员的都要参与进来，否则很可能会漏掉了很重要的需求。(测试经常被遗忘哦！)
在不同类型的人员中要选择那些真正和系统相关的，对系统有足够了解的人员参与进来，选择有经验的，而不是有时间的人。（teamleader选择参加，主要执行人员必须参加！针对评审目标选择参与者，避免高、中、低层一起评审。）

建议五、充分利用需求检查单
使评审有可操作依据，提高评审有效性，避免遗漏。
便于收集评审数据，记录评审结果

建议六、做好评审后的跟踪工作
切忌评审完毕后，没有对问题进行跟踪，而无法保证评审结果的落实，使前期的评审努力付之东流
发送项目状态通知，让相关人员周知需求评审已完成。
说明需求经评审后改动的部分，如实现优先级、加入和裁减了哪些。
针对评审结果对需求进行完善，并保证相关人员获得最新版的需求文档


另外，关于开会说几点：

为什么会议时间过长？
前期沟通不够，把应该花在前期沟通上的时间，用在了会议上。
自己准备不足，比如资料不全，不准，数据准备不充分等，不能说服与会人员，陷入争执。
不能把握会议主题，偏离目标。

说了这么多，希望能对遇到过相似问题的朋友有所帮助。

1.项目数据库建立(一般名称为项目简称)

2.相关用户组建立 (根据项目已知信息确定用户组及相关权限，在TD中设定并实现)

3.BUG管理规范在TD中的实现(分析缺陷规范或流程，得到用户组信息。确定缺陷状态。确定每类用户在缺陷处理过程和整个测试过程中的权限。在TD中实施设置。实施检查。)

4.TD过程功能使用(建立测试需求树(将已经识别的测试对象管理起来requirement)，计划测试(Test Plan测试用例管理)，创建测试集(Test lab测试执行策略管理)，执行测试，缺陷管理(defect))

5.报表生成(生成缺陷分析报告(包含缺陷状态分布图、趋势图、龄期图)。生成测试需求覆盖报告(包含报告和执行结果覆盖饼图))

简历要真实，千万不能造假。还要突出特色，把最重要的排在前面。HR经理筛选简历一般只用10秒钟，在10秒钟内让他看到最重要的内容非常关键。所以简历要简短，不要超过两页。内容不在多而在于精，要突出自己的优势。招聘者一般对数字很敏感，如果能摆出有说服力的数字，凸显自己的成绩和工作能力，这样比空洞的论述更能吸引人。

面试的时候不要太过于表现自己，更不要紧张，就当是和朋友聊天就好，不要有小动作。当遇到不懂的问题时，可以诚实地说自己不会，不要不懂装懂。一些知名的外企都有英语口语面试，所以自己的经历最好能在求职前好好回忆一下，整理一下思绪，面试时才能说得流利而有条理。

两天进行了ISO的培训，记了一些笔记，将其中的精要部分整理到论坛上供大家参考。

审核目标：传统的理解为发现问题，随着人们理解的升华，现在意义不仅仅是发现问题，更重要的是发现能够或者可以改进的机会。----审核主要是为了保证工作方向，路线的正确性。
审核目的：符合性（何为符合性，即符合iso9000的质量体系认证，符合公司实际），适用性（实际的工作是否按公司制定的文件，制度进行），适用性（看公司执行了这套体系，制度之后能不能达到预期的目标）
审核目的分解：1体系本身的适用性(符合)
            2发现问题
            3改进地方（2，3是适用）
            4以前问题的跟踪（持续改进）
            5工作目标达成情况（有效）
            6满足认证公司复审要求

与审核的相关的东西：
1  复审之前需要做的两件事（内审，管理评审）
2 何为第一方审核，第二方审核，第三方审核（第一方审核指内审，第二方审核指客户的审核，第三方审核指相关的中介或者认证机构的审核）
3何为体系（为实施管理的组织结构，职责，程序过程和资源）
4何为审核（为获得审核证据并对其进行客观评价，以确定满足审核准则的程度进行的系统的，独立的并形成文件的过程）
4审核组（由多名内审员组成）
5审核员需要具备的能力（理解标准；理解内审工作的要求；个人具备的素质，公正，公平与良好的沟通能力；对公司的制度有相当程度的了解）

内审的三个阶段：
第一阶段：审核准备
         1内审启动
         2成立审核组（需要有书面授权书）
         3编制内审计划
         4编制核查表
         5下发内审计划
         6准备审核文件
    下面重点讲审核计划中需要涉及到的内容
         1）目的
         2）范围（审核那些部门，那些业务产品）
         3）依据（依据下面分好多条）
                  a）标准
                  b）体系文件
                  c）相关的法律法规或者制度
                  d）审核组的安排
                  e）日程计划及分工
                  f）计划的分发范围（被审核部门）
                  g）计划本身的编制，审核，批准

第二阶段：审核实施
          1首次会议（要简短，主要通知相关部门给以配合）
          2现场审核（需要以书面的形式汇报给审核组长）
          3审核小组会议
          4末次会议（部门领导和审核组长）

第三阶段:审核总结
         1内审报告
         2不符合项纠正措施
         3跟踪验证
         4内审记录保存

薪水无故被蒸发，跳槽！没有发展空间，跳槽！Office人际关系太复杂，跳槽！有人说离开一间已经让我们没有激情的单位，就像结束一段已经枯萎的爱情。所以既不能太过绝情，所以也不能拖泥带水，拿出你的风度，留下你的微笑。

1.辞职报告不可缺
纵然你有千百个辞职的理由，写一份正式而诚恳的辞职报告却是十分必要的。事实上，你的离职本就是老板应该反思的问题，所以他最想看到的就是你辞职的理由。然而，你真的要告诉你的老板：在这里已经没有我的个人发展空间了；这间单位的前途值得怀疑；老板你常常拖欠我的薪水？真话往往具有极强的杀伤力，这不但让你的老板不开心，有时还会给你自己造成不必要的伤害——当你的新加盟公司对你进行外调的时候，你的旧老板会有很不好的评价传递给你的新单位。为此，你完全可以更多的写一些个性化的理由：“我要去进修”、“单位离家太远，上下班不方便”、“最近家里有事，时间上有点冲突”等等。另外，无论这间公司多么的不堪，一定不要忘记感激他对你的培养以及同事给予的帮助，因为毕竟是单位给你提供了经验积累的机会。

2.站好最后一班岗
记住：在辞职报告尚未批准的这段时间内，你依然是这间单位的职工，你需要站好这最后一班岗。有许多人因为自己要走了，就开始放松对自己的要求，迟到早退，不认真做事。这样，都会给原单位留下不好的印象。因为这段敏感期你稍有不慎，可能会引起人议论你一贯懒散，不称职。与此同时，控制好自己的情绪，不要抱怨更不要炫耀。即使你内心很想一吐为快，出一出长期以来积压的怨气，但明智的做法是管住舌头，必须明白：人一走茶即凉。不论你如何能干，人缘多好，人们也不可能完全站在你的角度理解你。相反，这些话如传到当事人的耳朵里，反会引起对方的怨恨。另外，你需要尽量清楚地交接自己手中正在使用的公物，不要拿走公司的任何资料。甚至连名片夹也不要带走，你只应拿走属于你的私人用品和你本人的名片。

3.做一回好老师
当一个月后你与单位脱掉干系的时候，接替你的新人也已经上岗了。对于他，你完全可以大方一些，做一回好老师，带带新人。你在职期间，积累了一定的工作资源，例如客户资源，你那这些工作资源带走后，可能会造成新人无法开展工作，同时也会让原单位的主管心理不踏实。这时，如果你主动把工作资源留在这里——即使只是一小部分，你的慷慨也可以为你在这里留下好名声。必要的时候，你可以把自己的工作职位说明以及工作经验以文件的形式留给新人，使他能在短时间内熟悉业务，尽量少走弯路，这也会让他对你感激不尽。不管以何种方式，你都能在原单位留下良好的印象，当他们感慨无缘与你共事的同时，也祝你一路顺风。

4.与他们保持联系
尽管你已经不是他们的员工了，可大家还是朋友，所以经常打个电话或写封电子邮件回原单位与老同事、老领导们叙叙旧，应该是一件非常愉快的事情。再说，这本是个小世界，说不定哪天大家就会在另外的一些场合继续合作，彼此都会有照应。即使在新单位遇到什么疑问，也可以想原来的老朋友们请教，多听听旁观者的见解，或多或少会对你的新工作有所帮助。要是原单位有什么需要你的时候，尽力去做，那么你的风度就尽在不言中了。

错误的产生原因：上述ORACLE错误为回滚段表空间不足引起的，这也是ORACLE数据管理员最常见的ORACLE错误信息。当用户在做一个非常庞大的数据操作导致现有回滚段的不足，使可分配用的回滚段表空间已满，无法再进行分配，就会出现上述的错误。

解决方法：使用“ALTER TABLESPACE tablespace_name ADD DATAFILE filename SIZE size_of_file”命令向指定的数据增加表空间，根据具体的情况可以增加一个或多个表空间。当然这与还与你主机上的裸盘设备有关，如果你主机的裸盘设备已经没有多余的使用空间，建议你不要轻意的增加回滚段表空间的大小，可使用下列的语句先查询一下剩余的tablespace空间有多少：

Select user_name,sql_text from V$open_cursor 
where user_name=’<user_name>’;

如果多余的空间比较多，就可以适当追加一个大的回滚段给表空间使用，从而避免上述的错误。你也可以用以下语句来检测一下rollback segment的竞争状况：

Select class,count from V$waitstat where calss in(‘system undo header’,’
system undo block’,’undo header’,’undo block’);

　　和

Select sum(value) from V$sysstat where name in 
(‘db_block_gets’,’consistents gets’);

如果任何一个class in count/sum(value)大于1%，就应该考虑增加rollback segment。

ORA-01652:unable to extend temp segment by num in tablespace name

错误产生的具体原因：ORACLE临时段表空间不足，因为ORACLE总是尽量分配连续空间，一但没有足够的可分配空间或者分配不连续就会出现上述的现象。

解决方法：我们知道由于ORACLE将表空间作为逻辑结构-单元，而表空间的物理结构是数据文件，数据文件在磁盘上物理地创建，表空间的所有对象也存在于磁盘上，为了给表空间增加空间，就必须增加数据文件。先查看一下指定表空间的可用空间，使用视图SYS.DBA_FREE_SPACE，视图中每条记录代表可用空间的碎片大小：

SQL>Select file_id,block_id,
blocks,bytes from sys.dba_free_space 
where tablespace_name=’<users>’;

返回的信息可初步确定可用空间的最大块，看一下它是否小于错误信息中提到的尺寸，再查看一下缺省的表空间参数：

SQL>SELECT INITIAL_EXTENT,NEXT_EXTENT,MIN_EXTENTS,
PCT_INCREASE FROM SYS.DBA_TABLESPACES WHERE 
TABLESPACE_NAME=name;

通过下面的SQL命令修改临时段表空间的缺省存储值：

SQL>ALTER TABLESPACE name DEFAULT STORAGE (INITIAL XXX NEXT YYY);

适当增大缺省值的大小有可能解决出现的错误问题，也可以通过修改用户的临时表空间大小来解决这个问题：

SQL>ALTER USER username TEMPORARY TABLESPACE new_tablespace_name;

我们都知道，「测试」是产品的真正试炼场；即使对一项软件开发工程投注了庞大的心血，如果测试不合格还是枉然，因为客户要的是「合格产品」，而不是你的「努力过程」。所以测试的重要性应该不必赘述。只不过，「知道」跟「做得到」是两回事，就如同我们都知道应该多吃青菜水果，然而还是有许多人每餐都是大鱼大肉。

许多人谈到测试，总是有满腹牢骚，因为它似乎是一件「知易行难」的麻烦工作。为何测试总是做不好？大致可归类成下述三大原因。

测试排最后

目前一般的软件开发工作，大多采用传统的「瀑布式（ Waterfall ）」流程法，也就是把开发过程分为「需求」、「分析」、「设计与撰写」、「整合」、「测试」等阶段，一个接一个依序进行。

这种方法很单纯，但导致「测试总是排在最后才进行」的状况。这种设计会产生两个状况：一是测试人员直到案子接近尾声才上工，所以往往在尚未了解整个系统架构的情况下，就一头栽进工作。二是这个时间点距离完工期实在太近，如果有什么突发状况，往往导致整个开发项目大乱或失败。

时间不够

测试做不好的第二个原因是「时间不够」，这是开发团队最常面临的问题。它其实也是上述「瀑布式」流程法把测试排在最后所导致的另一个致命伤。由于许多开发团队把大部分时间分配给前面阶段（特别是程序设计与撰写部分），只留少数时间给测试工作。然而突发状况永远无法预期，如果前面阶段因故导致工作拖延，在出货时间不能延后的情况下，后面阶段的时间就会不断地被牺牲。

所以我们常常看到，在一个预定进行八个月的软件项目里，因为前面阶段的状况百出（计算机当机、同仁生病请假、客户需求更改、开发不顺等），结果前面阶段不断占用后面阶段的时间，最后导致原本排定一个月的测试时间只剩下一周，甚至二、三天而已，根本无法测试。所以常常出现有些产品根本是在未经完整测试的情形下就贸然出货上市，把测试工作留给客户或消费者的情况。

另外还有一个与「时间不够」刚好相反的现象，就是「时间太长」。有时产品经初步测试之后发现问题丛生，实在无法交差（或是被客户退件），所以开发团队只好回头继续进行大量又重复的「测试 → 修改 → 验证」工作。如此折腾了好一阵子，最后产品终于可以验收。把这段额外时间加总起来，重新计算整体开发时间，这时才突然惊觉：「天啊，测试竟然占了将近一半的时间！」

风险太高

第三个问题是「风险太高」，也是流程设计不当所致。如文章开头所言：「测试才是产品的真正试炼场」，也就是一个项目的各种隐藏性风险，往往是透过「测试」才被完整发掘出来。但是「单向瀑布式」流程法却把测试集中在最后进行，所以它的风险容易随着开发流程的推进而越来越高；是一种相当危险的风险控管方式。

事实上，这也是许多项目在后期才突然出现成本失控或失败的重要原因。因为等到风险爆发之时，往往已经无力回天，或必须付出相当大的代价以为因应。