登陆PLSQL时系统报错: ORACLE NOT AVAILABLE; SHRED MEMORY REALM DOES NOT EXIST

用命令重新启动数据库

 

 

 系统参数表：select * from v$parameter;

  例如：参数 JOB

 

 设置完后,必须重新启动数据库才可以生效.

1、用户

查看当前用户的缺省表空间
SQL>select username,default_tablespace from user_users;

查看当前用户的角色
SQL>select * from user_role_privs;

查看当前用户的系统权限和表级权限
SQL>select * from user_sys_privs;
SQL>select * from user_tab_privs;

显示当前会话所具有的权限
SQL>select * from session_privs;

显示指定用户所具有的系统权限
SQL>select * from dba_sys_privs where grantee='GAME';

显示特权用户
select * from v$pwfile_users;

显示用户信息(所属表空间)
select default_tablespace,temporary_tablespace
from dba_users where username='GAME';

显示用户的PROFILE
select profile from dba_users where username='GAME';

2、表

查看用户下所有的表
SQL>select * from user_tables;

查看名称包含log字符的表
SQL>select object_name,object_id from user_objects
where instr(object_name,'LOG')>0;

查看某表的创建时间
SQL>select object_name,created from user_objects where object_name=upper('&table_name');

查看某表的大小
SQL>select sum(bytes)/(1024*1024) as "size(M)" from user_segments
where segment_name=upper('&table_name');

查看放在ORACLE的内存区里的表
SQL>select table_name,cache from user_tables where instr(cache,'Y')>0;

3、索引

查看索引个数和类别
SQL>select index_name,index_type,table_name from user_indexes order by table_name;

查看索引被索引的字段
SQL>select * from user_ind_columns where index_name=upper('&index_name');

查看索引的大小
SQL>select sum(bytes)/(1024*1024) as "size(M)" from user_segments
where segment_name=upper('&index_name');

4、序列号

查看序列号，last_number是当前值
SQL>select * from user_sequences;

5、视图

查看视图的名称
SQL>select view_name from user_views;

查看创建视图的select语句
SQL>set view_name,text_length from user_views;
SQL>set long 2000; 说明：可以根据视图的text_length值设定set long 的大小
SQL>select text from user_views where view_name=upper('&view_name');

6、同义词

查看同义词的名称
SQL>select * from user_synonyms;

7、约束条件

查看某表的约束条件
SQL>select constraint_name, constraint_type,search_condition, r_constraint_name
from user_constraints where table_name = upper('&table_name');

SQL>select c.constraint_name,c.constraint_type,cc.column_name
from user_constraints c,user_cons_columns cc
where c.owner = upper('&table_owner') and c.table_name = upper('&table_name')
and c.owner = cc.owner and c.constraint_name = cc.constraint_name
order by cc.position;

8、存储函数和过程

查看函数和过程的状态
SQL>select object_name,status from user_objects where object_type='FUNCTION';
SQL>select object_name,status from user_objects where object_type='PROCEDURE';

查看函数和过程的源代码
SQL>select text from all_source where ōwner=user and name=upper('&plsql_name');

1、查找锁表的情况

SELECT B.OWNER, B.OBJECT_NAME, A.SESSION_ID, A.LOCKED_MODE
  FROM V$LOCKED_OBJECT A, DBA_OBJECTS B
 WHERE B.OBJECT_ID = A.OBJECT_ID;

2、查找锁表的用户

SELECT B.USERNAME, B.SID, B.SERIAL#, LOGON_TIME
  FROM V$LOCKED_OBJECT A, V$SESSION B
 WHERE A.SESSION_ID = B.SID
 ORDER BY B.LOGON_TIME;

SELECT A.TABLE_NAME "表名",
       A.COLUMN_NAME "字段名",
       A.DATA_TYPE || DECODE(DATA_TYPE,
                             'NUMBER',
                             DECODE(NVL(DATA_SCALE, 0),
                                    0,
                                    DECODE(NVL(DATA_PRECISION, 0),
                                           0,
                                           TO_CHAR(DATA_PRECISION),
                                           '(' || TO_CHAR(DATA_PRECISION) || ')'),
                                    '(' || TO_CHAR(DATA_PRECISION) || ',' ||
                                    TO_CHAR(DATA_SCALE) || ')'),
                             'DATE',
                             NULL,
                             '(' || DATA_LENGTH || ')') "字段类型",
       B.COMMENTS "字段备注",
       A.NULLABLE "是否允许为空"
  FROM USER_TAB_COLUMNS A, USER_COL_COMMENTS B
 WHERE A.TABLE_NAME = B.TABLE_NAME
   AND A.TABLE_NAME = UPPER('表名')
   AND A.COLUMN_NAME = B.COLUMN_NAME(+)
 ORDER BY A.TABLE_NAME, A.COLUMN_ID

SELECT /*OWNER,*/
 OBJECT_TYPE, OBJECT_NAME
  FROM DBA_OBJECTS
 WHERE OWNER IN ('用户A')
   AND OBJECT_TYPE = '结构类型'
MINUS
SELECT /*OWNER,*/
 OBJECT_TYPE, OBJECT_NAME
  FROM DBA_OBJECTS
 WHERE OWNER IN ('用户B')
   AND OBJECT_TYPE = '结构类型';

例如：

SELECT /*OWNER,*/
 OBJECT_TYPE, OBJECT_NAME
  FROM DBA_OBJECTS
 WHERE OWNER IN ('A)
   AND OBJECT_TYPE = 'PROCEDURE'
MINUS
SELECT /*OWNER,*/
 OBJECT_TYPE, OBJECT_NAME
  FROM DBA_OBJECTS
 WHERE OWNER IN ('B')
   AND OBJECT_TYPE = 'PROCEDURE';

SELECT OWNER, OBJECT_TYPE, COUNT(*)
  FROM DBA_OBJECTS
 WHERE OWNER IN ('用户1', '用户2')
 GROUP BY OWNER, OBJECT_TYPE;

例如：

SELECT OWNER, OBJECT_TYPE, COUNT(*)
  FROM DBA_OBJECTS
 WHERE OWNER IN ('A', 'B')
 GROUP BY OWNER, OBJECT_TYPE;

结果：

A    LOB 10
A    TYPE 20
A    VIEW 203
A    INDEX 920
A    TABLE 916
A    PACKAGE 68
A    SYNONYM 1
A    TRIGGER 77
A    FUNCTION 105
A    SEQUENCE 77
A    PROCEDURE 173
A    TYPE BODY 1
A    PACKAGE BODY 57

B    LOB 10
B    TYPE 2
B    VIEW 203
B    INDEX 924
B    TABLE 909
B    PACKAGE 70
B    SYNONYM 1
B    TRIGGER 85
B    FUNCTION 105
B    SEQUENCE 77
B    PROCEDURE 175
B    PACKAGE BODY 58

    Mercury Interactive公司的WinRunner是一种企业级的功能测试工具，用于检测应用程序是否能够达到预期的功能及正常运行。通过自动录制、检测和回放用户的应用操作，WinRunner能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试，提高测试人员的工作效率和质量，确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行。
　　企业级应用可能包括Web应用系统，ERP系统，CRM系统等等。这些系统在发布之前，升级之后都要经过测试，确保所有功能都能正常运行，没有任何错误。如何有效地测试不断升级更新且不同环境的应用系统，是每个公司都会面临的问题。

　　如果时间或资源有限，这个问题会更加棘手。人工测试的工作量太大，还要额外的时间来培训新的测试人员等等。为了确保那些复杂的企业级应用在不同环境下都能正常可靠地运行，你需要一个能简单操作的测试工具来自动完成应用程序的功能性测试。

　　轻松创建测试：用WinRuuner创建一个测试，只需点击鼠标和键盘，完成一个标准的业务操作流程，WinRunner自动记录你的操作并生成所需的脚本代码。这样，即使计算机技术知识有限的业务用户轻松创建完整的测试。你还可以直接修改测试脚本以满足各种复杂测试的需求。WinRunner提供这两种测试创建方式，满足测试团队中业务用户和专业技术人员的不同需求。

　　插入检查点：在记录一个测试的过程中，可以插入检查点，检查在某个时刻/状态下，应用程序是否运行正常。在插入检查点后，WinRunner会收集一套数据指标，在测试运行时对其一一验证。WinRunner提供几种不同类型的检查点，包括文本的、GUI、位图和数据库。例如，用一个位图检查点，你可以检查公司的图标是否出现于指定位置。

　　检验数据：除了创建并运行测试，WinRunner还能验证数据库的数值，从而确保业务交易的准确性。例如，在创建测试时，可以设定哪些数据库表和记录需要检测;在测试运行时，测试程序就会自动核对数据库内的实际数值和预期的数值。WinRunner自动显示检测结果，在有更新/删除/插入的记录上突出显示以引起注意。

　　增强测试：为了彻底全面地测试一个应用程序，需要使用不同类型的数据来测试。WinRunner的数据驱动向导( Data Driver Wizard)可以让你简单地点击几下鼠标，就可以把一个业务流程测试转化为数据驱动测试，从而反映多个用户各自独特且真实的行为。

　　以一个订单输入的流程为例，你可能希望把订单号或客户名称作为可变栏，用多套数据进行测试。使用Data Driver Wizard，你可以选择订单号或客户名称用数据表格文件中的哪个栏目的数据替换。你可以把订单号或客户名称输入数据表格文件，或从其它表格和数据库中导入。数据驱动测试不仅节省了时间和资源，又提高了应用的测试覆盖率。

　　WinRunner还可以通过Function Generator增加测试的功能。使用Function Generator可以从目录列表中选择一个功能增加到你的测试中以提高测试能力。例如，你可以选择”calendar”，然后从日历功能的下属目录中选择，如Calendar_select_date(),然后你可以直观地输入参数，把这个功能插入到你的测试中。

　　针对相当数量的企业应用里非标准对象，WinRunner提供了Virtual Object Wizard来识别以前未知的对象。使用Virtual Object Wizard，你可以选择未知对象的类型，设定标识和命名。在录制使用该对象的测试时，WinRunner会自动对应它的名字，从而提高测试脚本的可读性和测试质量。

　　运行测试：创建好测试脚本，并插入检查点和必要的添加功能后，你就可以开始运行测试。运行测试时，WinRunner会自动操作应用程序，就象一个真实的用户根据业务流程执行着每一步的操作。测试运行过程中，如有网络消息窗口出现或其它意外事件出现，WinRunner也会根据预先的设定排除这些干扰。

　　分析结果：测试运行结束后，你需要分析测试结果。WinRunner通过交互式的报告工具来提供详尽的、易读的报告。报告中会列出测试中发现的错误内容、位置、检查点和其它重要事件，帮助你对测试结果进行分析。这些测试结果还可以通过Mercury Interactive的测试管理工具TestDirector来查阅。

　　维护测试：随着时间的推移，开发人员会对应用程序做进一步的修改，并需要增加另外的测试。使用WinRunner，你不必对程序的每一次改动都重新创建你的测试。WinRunner可以创建在整个应用程序生命周期内都可以重复使用的测试，从而大大地节省时间和资源，充分利用你的测试投资。

　　每次记录测试时，WinRunner会自动创建一个GUI Map文件以保存应用对象。这些对象分层次组织，既可以总览所有的对象，也可以查询某个对象的详细信息。一般而言，对应用程序的任何改动都会影响到成百上千个测试。通过修改一个GUI Map文件而非无数个测试，WinRunner可以方便地实现测试重用。

　　帮助你的应用程序为无线应用作准备：随着无线设备种类和数量的增加，你的应用程序测试计划需要同时满足传统的基于浏览器的用户和无线浏览设备，如移动电话、传呼机和个人数字助理(PDA)。

　　无线应用协议是一种公开的、全球性的网络协议，用来支持标准数据格式化和无线设备信号的传输。

　　使用WinRunner，测试人员可以利用微型浏览模拟器来记录业务流程操作，然后回放和检查这些业务流程功能的正确性。

1. 精通性能测试的基本概念，过程，方法论，了解性能工程；

2. 精通1个商业性能测试工具+1个开源性能测试工具，知道工具可以做什么，不可以做什么，以及工具使用中常见的问题和解决思路；

3. 扎实的计算机专业基础知识，包括计算机组成原理、操作系统、数据库原理、计算机网络原理；

4. 熟悉至少1个常用的数据库产品，例如SQL Server或者 Oracle，能进行一般的数据库管理操作，熟悉SQL脚本的使用，熟悉常用的数据调优工具和常用的counter；

5. 熟悉至少一个操作系统的原理，Windows或者Linux都可以，熟悉操作系统的体系架构、操作系统的重要基础概念，以及内存管理、存储/文件系统、驱动/硬件的管理、网络协议的实现及构成、性能的监控方法和原理，熟悉常用的counter；

6. 熟悉至少一个web server 产品，例如apache，了解一般的配置和常用的counter；

7. 熟悉至少一个应用服务器产品，例如tomcat，了解一般的配置，熟悉常用的服务器性能监控方法和原理，熟悉常用的counter；

8. 至少熟悉TCP/IP协议，熟悉HTTP协议，至少见过并了解三层、四层交换或者路由器的使用和配置。了解常用的与网络性能相关的counter；

9. 了解一般的大型企业应用的部署架构和应用架构；

10. 了解知名大型web应用、高并发量、高流量、实时响应要求高的超大规模网站的架构和优化历程；

11. 熟悉统计学的基础知识、常用分析方法以及实验设计方法，了解数学建模相关的知识；

12. 熟悉专属行业的业务知识和用户场景，例如电信行业的OSS系统所涉及的业务知识和用户场景，证券交易系统所涉及的业务知识和用户场景；

13. 大量的实际性能测试及优化经验；

14. 积极的参与到各类圈子、社团的讨论和交流、分享中。

p-unit 简介

   p-unit 是一款开放源码的性能测试框架，和 JUnit 不同，JUnit 关注的是测试案例的正确性，而 p-unit 不仅关注测试案例的正确性，还收集测试案例的性能参数，默认情况下，p-unit 收集测试案例的时间和内存消耗情况，可以产生文件，图片，和 PDF 格式的报表。此外，p-unit 还支持参数化测试，多线程测试以及不同 Java 虚拟机性能之间的比较。

　　或许我们已经习惯了使用 JUnit 来写单元测试来保证代码质量（我也一直这么做），但可能经常碰到这样的问题：程序多线程下正确性如何？ 如何测试程序的性能？ 当有多个方案可以选择时，技术上如何比较不同方案的性能？
　
　　对于问题 1，我们或许听天由命？或是凭借人工分析，或是根据用户反馈？很多软件单线程下的单元测试覆盖率相当高，从而保证了代码的健壮性。然而多线程测试时常被忽略，这并不代表多线程测试不重要，相反，修正一个用户报告的多线程 BUG 往往比单线程的要高出很多，因为测试案例经常不是 100% 可重现的。这更要求程序员在开发阶段充分的重视。目前多线程单元测试力度不够的一个重要原因是没有一个像 JUnit 那样易用的测试工具，另外重复写测试案例往往不被程序员接受。
　
　　对于问题 2，一个成熟的关心性能的产品往往有一个性能测试平台。这个测试平台应该关注的是测试业务逻辑本身，而无需关心如何运行测试案例。你是否为写这样的测试平台痛苦过？以及花费时间在产生一些直观的报表上面？
　
　　对于问题 3，我们往往写一个原型来比较不同产品之间的性能，如何比较执行速度和内存消耗？或是选择最适合你的虚拟机？
　
　　p-unit 就是这么一款开源的性能测试软件，它能帮助你很好的解决上述问题。p-unit 可以： 多线程支持：同一个测试案例可以单线程执行，也可以多线程执行，测试案例开发者只需写一套测试案例。 参数化测试案例：很多测试案例，需要测试同一功能在不同数量级上的性能表现。 不同虚拟机性能测试：只需指定虚拟机路径，即可测试同一个测试案例在不同虚拟机上的表现，报表上可以非常直观显示性能差别。 事件机制构架：punit 是基于事件机制构架的，如果用户想定制报表，只需实现事件响应器，并注册该响应器到 punit 核心即可。

  多线程执行测试案例

    在了解如何多线程执行测试案例之前，我们先了解一下如何利用 p-unit 单线程执行测试案例。不同于 JUnit， p-unit 测试用例无需继承任何测试类或是实现接口，即可执行 test 开始的方法。尽管 JUnit 4 中加入了注释（Annotation） 的特性，但测试方法前缀为 "test" 仍然是测试者们的首选。因此如果你的 JUnit 测试案例遵循的是 test 命名规则，那么 p-uni t可以兼容运行 JUnit 测试案例。

  
StressMark 简介  

   StressMark测试软件是一个使用Visual C++编写的，开放源代码的测试工具，可以完成服务程序及重要算法的功能和性能测试，其最主要的功能是模拟多线程或多客户端的自动化压力测试。
　
   我们可以利用StressMark软件完成的典型测试任务包括：

       1. 在多线程环境下测试一个软件模块、一段关键算法是否可以正确运行，即代码是否是多线程安全的。　

       2. 测试一个软件模块、一段关键算法在并发执行时的效率，如每个线程的平均执行时间等。
　
       3. 模拟一个服务程序的多个客户端，测试该服务程序对并发请求的响应是否正确。
　
       4. 模拟一个服务程序的多个客户端，测试该服务程序在并发请求的情况下，对每个客户请求的响应效率。
　
       5. 使用一台或多台高配置的测试计算机（多CPU，大内存），每台计算机上运行一套StressMark，每套StressMark模拟多个客户线程，以此测试服务程序在大压力情况下的响应能力，这一方法甚至可以测出服务程序支持的并发数上限。
　
    因为StressMark软件的源代码是完全开放的，基于这套源代码，你完全可以改造出符合你的特定需求的自动测试程序，使StressMark可以完成更多的测试任务。
基本概念

       测试包：用户根据特定测试需求制订的，包含一个或多个不同测试用例及其配置方式的描述性大纲。
　
       测试用例：指对一项特定的测试任务的描述，包括测试目标，输入数据，测试方法，实现代码等。在 StressMark 中，测试用例对应于一段具体的待测试代码，该测试代码由测试者提供，并被嵌入到 StressMark 工程中。测试时，可以对一个测试用例起多个测试客户（线程）同时运行，也就是说，一个测试用例同时可以有多个运行实例。还可以对特定的测试用例指定测试次数，即指定在该测试用例的每个实例中，重复执行多少次测试代码。根据需要，用户也可以指定每两次重复之间的时间间隔。

       测试客户：或称测试线程。指测试时某特定测试用例的一个具体的实例。该实例以线程方式运行，并与该测试用例的其他实例同时启动。用户可以在测试包中为每个测试用例配置测试客户（线程）的数目。
　
       测试次数：某特定测试用例的每一个测试客户（线程）中，待测试代码的重复执行次数。用户可以在测试包中为每个测试用例配置测试次数。
　
       间隔时间：某特定测试用例的每一个测试客户（线程）中，待测试代码两次重复执行之间的间隔时间。单位是毫秒。间隔时间可以在测试包中指定。

26.软件测试分哪两种方法？分别适合什么情况？
　
　　软件测试方法一般分为两种：白盒测试与黑盒测试。白盒测试又称为结构测试、逻辑驱动测试或基于程序本身的测试，它着重于程序的内部结构及算法，通常不关心功能与性能指标；黑盒测试又被称为功能测试、数据驱动测试或基于规格说明的测试，它实际上是站在最终用户的立场，检验输入输出信息及系统性能指标是否符合规格说明书中有关功能需求及性能需求的规定。
　
27.一套完整的测试应该由哪些阶段组成？分别阐述一下各个阶段。
　
　　计划阶段、设计阶段、白盒单元、白盒集成、黑盒单元、黑盒集成、系统测试、回归测试、验收测试一套完整的测试应该由五个阶段组成：

  1）测试计划首先，根据用户需求报告中关于功能要求和性能指标的规格说明书，定义相应的测试需求报告，即制订黑盒测试的最高标准。以后所有的测试工作都将围绕着测试需求来进行，符合测试需求的应用程序即是合格的，反之即是不合格的；同时，还要适当选择测试内容，合理安排测试人员、测试时间及测试资源等。
　
　　2）测试设计将测试计划阶段制订的测试需求分解、细化为若干个可执行的测试过程，并为每个测试过程选择适当的测试用例（测试用例选择的好坏将直接影响测试结果的有效性）。
　
　　3）测试开发建立可重复使用的自动测试过程。
　
　　4）测试执行执行测试开发阶段建立的自动测试过程，并对所发现的缺陷进行跟踪管理，测试执行一般由单元测试、组合测试、集成测试、系统联调及回归测试等步骤组成，测试人员应本着科学负责的态度，一步一个脚印地进行测试。
　
　　5）测试评估结合量化的测试覆盖域及缺陷跟踪报告，对于应用软件的质量和开发团队的工作进度及工作效率进行综合评价。
　
28.软件测试的类型有那些？分别比较这些不同的测试类型的区别与联系。
　
　　BVT （Build Verification Test），主要目的是验证最新生成的软件版本在功能上是否完整，主要的软件特性是否正确Scenario Tests（基于用户实际应用场景的测试），Scenario Tests优点是关注了用户的需求，缺点是有时候难以真正模仿用户真实的使用情况Smoke Test，修复Bug后，针对此次修复是否会对其他模块造成影响而进行的专门测试。Smoke Test优点是节省测试时间，防止build失败。缺点是覆盖率还是比较低此外，还有Application Compatibility Test（兼容性测试），主要目的是为了兼容第三方软件，确保第三方软件能正常运行，用户不受影响。Accessibility Test（软件适用性测试），是确保软件对于某些有残疾的人士也能正常的使用，但优先级比较低。其它的测试还有Functional Test（功能测试）、Security Test（安全性测试）、Stress Test（压力测试）、Performance Test（性能测试）、Regression Test（回归测试）、Setup/Upgrade Test（安装升级测试）等

29.测试用例通常包括那些内容？着重阐述编制测试用例的具体做法不同结构的用例包括的不一样。（版本、编号、项目、设计人员、设计日期、输入、预期输出……）
　 
   软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果。

  用例编号： 测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则： PROJECT1-ST-001 ，命名规则是项目名称＋测试阶段类型（系统测试阶段）＋编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。

  测试标题： 对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如 “ 测试用户登录时输入错误密码时，软件的响应情况 ” .重要级别： 定义测试用例的优先级别，可以笼统的分为 “ 高 ” 和 “ 低 ” 两个级别。一般来说，如果软件需求的优先级为 “ 高 ” ，那么针对该需求的测试用例优先级也为 “ 高 ” ；反之亦然，测试输入： 提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。

   操作步骤： 提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。

   预期结果： 提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。

30.描述使用bugzilla缺陷管理工具对软件缺陷（BUG）跟踪的管理的流程

   1) 测试人员或开发人员发现bug后，判断属于哪个模块的问题，填写bug报告后，系统会自动通过Email通知项目组长或直接通知开发者。

   2) 经验证无误后，修改状态为VERIFIED.待整个产品发布后，修改为CLOSED. 

   3) 还有问题，REOPENED，状态重新变为“New"，并发邮件通知。

   4) 项目组长根据具体情况，重新reassigned分配给bug所属的开发者。

   5) 若是，进行处理，resolved并给出解决方法。（可创建补丁附件及补充说明）

   6) 开发者收到Email信息后，判断是否为自己的修改范围。

   7) 若不是，重新reassigned分配给项目组长或应该分配的开发者。

   8) 测试人员查询开发者已修改的bug，进行重新测试。（可创建test case附件）
　
    

以下从常见测试工具功能、使用范围、目前市场情况、应用前景等方面做简要比较：

WinRunner

功能：1.插入检查点；2.检验数据；3.增强测试；4.分析结果；5.维护测试；、６.为无线应用作准备。

范围：功能测试、生成测试用例、分析测试结果、维护测试用例、回归测试。

LoadRunner

功能：1.松创建虚拟用户； 2.创建真实的负载； 3.定位性能问题；4.分析结果以精确定位问题所在； 5.重复测试保证系统发布的高性能； 6.Enterprise Java Beans的测试； 7.支持无线应用协议； 8.支持Media Stream应用； 9.完整的企业应用环境的支持。

范围：性能测试、压力测试、模拟多用户、定位性能瓶颈。

TestDirector

功能：1．需求管理;2. 计划测试;3. 安排和执行测试;4. 缺陷管理;5. 图形化和报表输出;

范围：

测试管理工具

Rational系列-------Rational Purify （测试时用，检查运行时内存错误）;

Rational Quantify（性能检测工具，查出系统瓶颈以便改进运行速度）;

Rational TestManager （测试管理）;

Robot （软件测试用，通过scrīpt自动模拟输入输出）;

LoadTest （负载测试）;

TestFactory （软件测试用）;

QACenter-----QACenter

帮助所有的测试人员创建一个快速，可重用的测试过程。这些测试工具自动帮助管理测试过程，快速分析和调试程序，包括针对回归，强度，单元，并发，集成，移植，容量和负载,建立测试用例，自动执行测试和产生文档结果。

QACenter主要包括以下几个模块：

QARun：应用的功能测试工具。

QALoad：强负载下应用的性能测试工具。

QADirector：测试的组织设计和创建以及管理工具。

TrackRecord：集成的缺陷跟踪管理工具。

EcoTools：高层次的性能监测工具。

QARun

1.强大的测试脚本建立功能。

2.可反复运行，进行回归测试。

3．支持更多的应用访问

QALoad

1.自动捕获实际执行过程，自动生成测试脚本。

2.通过控制台（安装在Windows NT）控制各个Agent（安装在Windows和Unix），进行脚本分配。

3.模拟实际操作，压力测试。

WebLoad

Web压力测试工具

panorama

功能主要是用于白盒测试。它对分析源码和跟踪错误方面有一定独到的见解，并且采用图解的方法跟踪源码。白盒方面Compuware也非常不错;

一、概述
   一般而言，软件测试从项目确立时就开始了，前后要经过以下一些主要环节：
   需求分析→测试计划→测试设计→测试环境搭建→测试执行→测试记录→缺陷管理→软件评估→RTM.

   在进行有关问题阐述前，我们先明确下分工，一般而言，需求分析、测试用例编写、测试环境搭建、测试执行等属于测试开发人员工作范畴，而测试执行以及缺陷提交等属于普通测试人员的工作范畴，测试负责人负责整个测试各个环节的跟踪、实施、管理等。

说明：

1．以上流程各环节并未包含软件测试过程的全部，如根据实际情况还可以实施一些测试计划评审、用例评审，测试培训等。在软件正式发行后，当遇到一些严重问题时，还需要进行一些后续维护测试等。

2．以上各环节并不是独立没联系的，实际工作千变万化，各环节一些交织、重叠在所难免，比如编写测试用例的同时就可以进行测试环境的搭建工作，当然也可能由于一些需求不清楚而重新进行需求分析等。这就和我们国家提出建设有中国特色的社会主义国家一样，只所以有中国特色，那是因为国情不一样。所以在实际测试过程中也要做到具体问题具体分析，具体解决。

二、测试流程

   需求分析

   需求分析（Requirment Analyzing）应该说是软件测试的一个重要环节，测试开发人员对这一环节的理解程度如何将直接影响到接下来有关测试工作的开展。可能有些人认为测试需求分析无关紧要，这种想法是很不对的。需求分析不但重要，而且至关重要！

   一般而言，需求分析包括软件功能需求分析、测试环境需求分析、测试资源需求分析等。其中最基本的是软件功能需求分析，测一款软件首先要知道软件能实现哪些功能以及是怎样实现的。比如一款Smartphone包括VoIP、Wi-Fi以及Bluetooth等功能。那我们就应该知道软件是怎样来实现这些功能的，为了实现这些功能需要哪些测试设备以及如何搭建相应测试环境等，否则测试就无从谈起！

   总得说来，做测试需求分析的依据有软件需求文档、软件规格书以及开发人员的设计文档等，相信管理一些规范的公司在软件开发过程中都有这些文档。

   测试计划

   测试计划（Test Plan）一般由测试负责人来编写。测试计划的依据主要是项目开发计划和测试需求分析结果而制定。测试计划一般包括以下一些方面：

1．  测试背景

  a. 软件项目介绍；

  b. 项目涉及人员（如软硬件项目负责人等）介绍以及相应联系方式等。

2．  测试依据

  a.  软件需求文档；

  b.  软件规格书；

  c.  软件设计文档；

  d.  其他，如参考产品等。

3．  测试资源

  a.  测试设备需求；
 
  b.  测试人员需求；

  c.  测试环境需求；

  d.  其他。

4． 测试策略

  a. 采取测试方法；

  b.  搭建哪些测试环境；

  c.  采取哪些测试工具以测试管理工具；

  d.  对测试人员进行培训等。

5． 测试日程

  a.  测试需求分析；

  b.  测试用例编写；

  c.  测试实施，根据项目计划，测试分成哪些测试阶段（如单元测试、集成测试、系统测试阶段，α、β测试阶段等），每个阶段的工作重点以及投入资源等。

6．  其他。

 
  测试计划还要包括测试计划编写的日期、作者等信息，计划越详细越好了。计划赶不上变化，一份计划做的再好，当实际实施的时候就会发现往往很难按照原有计划开展。如在软件开发过程中资源匮乏、人员流动等都会对测试造成一定的影响。所以，这些就要求测试负责人能够从宏观上来调控了。在变化面前能够做到应对自如、处乱不惊那是最好不过了。

   测试设计

   测试设计主要包括测试用例编写和测试场景设计两方面。

  一份好的测试用例对测试有很好的指导作用，能够发现很多软件问题。关于测试用例编写，请参见前面写的《也谈测试用例》一文，里面有详细阐述。

   测试场景设计主要也就是测试环境问题了.不同软件产品对测试环境有着不同的要求。如C/S及B/S架构相关的软件产品，那么对不同操作系统，如Windows系列、unix、linux甚至苹果OS等，这些测试环境都是必须的。而对于一些嵌入式软件，如手机软件，如果我们想测试一下有关功能模块的耗电情况，手机待机时间等，那么我们可能就需要搭建相应的电流测试环境了。当然测试中对于如手机网络等环境都有所要求。

  测试环境很重要，符合要求的测试环境能够帮助我们准确的测出软件问题，并且做出正确的判断。

  为了测试一款软件，我们可能根据不同的需求点要使用很多不同的测试环境。有些测试环境我们是可以搭建的，有些环境我们无法搭建或者搭建成本很高。不管如何，我们的目标是测试软件问题，保证软件质量。测试环境问题，还是根据具体产品以及开发者的实际情况而采取最经济的方式吧。

   测试执行

  测试执行过程又可以分为以下阶段：

  单元测试→集成测试→系统测试→出厂测试，其中每个阶段还有回归测试等。

  从测试的角度而言，测试执行包括一个量和度的问题。也就是测试范围和测试程度的问题。 比如一个版本需要测试哪些方面？每个方面要测试到什么程度？

  从管理的角度而言，在有限的时间内，在人员有限甚至短缺的情况下，要考虑如何分工，如何合理地利用资源来开展测试。当然还要考虑以下问题：

1．当测试人员测试的执行不到位、敷衍了事时该如何解决？

2．测试效率问题，怎样提高测试效率？

3．根据版本的不同特点是只做验证测试还是采取冒烟测试亦或是系统全面测试？

4．当测试过程中遇到一些偶然性随机问题该怎样处理？

5．当版本中出现很多新问题时该怎样对待？测试停止标准？

6．  ……

总之，测试执行过程中会遇到很多复杂的问题，还是那句话，具体问题具体解决！本文不做过多阐述。

   测试记录

 
  缺陷记录总的说来包括两方面：由谁提交和缺陷描述。

  一般而言，缺陷都是谁测试谁提交，当然有些公司可能为了保证所提交缺陷的质量，还会在提交前进行缺陷评估，以确保所提交的缺陷的准确性。

  在缺陷的描述上，至少要包括以下一些方面内容：

 序号
 标题
 预置条件
 操作步骤
 预期结果
 实际结果
 注释
 严重程度
 概率
 版本
 测试者
 测试日期
 
另外，一个版本软件测试完毕，还要根据测试情况出份测试报告，这也是所要经过的一个环节。

  缺陷管理

 缺陷管理方面，很多公司都采取缺陷管理工具来进行管理，常见缺陷管理工具有Test Director、Bugfree等。

   软件评估

  这里评估指软件经过一轮又一轮测试后，确认软件无重大问题或者问题很少的情况下，对准备发给客户的软件进行评估，以确定是否能够发行给客户或投放市场。

   软件评估小组一般由项目负责人、营销人员、部门经理等组成，也可能是由客户指定的第三方人员组成。

   测试总结

   每个版本有每个版本的测试总结，每个阶段有每个阶段的测试总结，当项目完成RTM后，一般要对整个项目做个回顾总结，看有哪些做的不足的地方，有哪些经验可以对今后的测试工作做借鉴使用，等等。测试总结无严格格式、字数限制。应该说，测试总结还是很总要的。

  测试维护

  由于测试的不完全性，当软件正式release后，客户在使用过程中，难免遇到一些问题，有的甚至是严重性的问题，这就需要修改有关问题，修改后需要再次对软件进行测试、评估、发行。

    黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试地，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。

　　黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。很明显，如果外部特性本身有问题或规格说明的规定有误，用墨盒测试方法是发现不了的。

　　黑盒测试法注重于测试软件的功能需求，主要试图发现下列几类错误。

　　功能不正确或遗漏；

　　界面错误；

　　数据库访问错误；

　　性能错误；

　　初始化和终止错误等。

　　从理论上讲，黑盒测试只有采用穷举输入测试，把所有可能的输入都作为测试情况考虑，才能查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有佥的输入，而且还要对那些不合法但可能的输入进行测试。这样看来，完全测试是不可能的，所以我们要进行有针对性的测试，通过制定测试案例指导测试的实施，保证软件测试有组织、按步骤，以及有计划地进行。黑盒测试行为必须能够加以量化，才能真正保证软件质量，而测试用例就是将测试行为具体量化的方法之一。具体的黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法等。

   等价类划分的办法是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值。

　　边界值分析是通过选择等价类边界的测试用例。边界值分析法不仅重视输入条件边界，而且也必须考虑输出域边界。

　　错误推测设计方法就是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法。

　　因果图方法是从用自然语言书写的程序规格说明的描述中找出因（输入条件）和果（输出或程序状态的改变），可以通过因果图转换为判定表。

　　正交试验设计法，就是使用已经造好了的正交表格来安排试验并进行数据分析的一种方法，目的是用最少的测试用例达到最高的测试覆盖率。

　　

    白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。

　　这一方法是把测试对象看作一个打开的盒子，测试人员依据程序内部逻辑结构相关信息，设计或选择测试用例，对程序所有逻辑路径进行测试，通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。

　　采用什么方法对软件进行测试呢？常用的软件测试方法有两大类：静态测试方法和动态测试方法。其中软件的静态测试不要求在计算机上实际执行所测程序，主要以一些人工的模拟技术对软件进行分析和测试；而软件的动态测试是通过输入一组预先按照一定的测试准则构造的实例数据来动态运行程序，而达到发现程序错误的过程。

 

 

    黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试地，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。

　　黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。很明显，如果外部特性本身有问题或规格说明的规定有误，用墨盒测试方法是发现不了的。

　　黑盒测试法注重于测试软件的功能需求，主要试图发现下列几类错误。

　　功能不正确或遗漏；

　　界面错误；

　　数据库访问错误；

　　性能错误；

　　初始化和终止错误等。

　　从理论上讲，黑盒测试只有采用穷举输入测试，把所有可能的输入都作为测试情况考虑，才能查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有佥的输入，而且还要对那些不合法但可能的输入进行测试。这样看来，完全测试是不可能的，所以我们要进行有针对性的测试，通过制定测试案例指导测试的实施，保证软件测试有组织、按步骤，以及有计划地进行。黑盒测试行为必须能够加以量化，才能真正保证软件质量，而测试用例就是将测试行为具体量化的方法之一。具体的黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法等。

    等价类划分的办法是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值。

　　边界值分析是通过选择等价类边界的测试用例。边界值分析法不仅重视输入条件边界，而且也必须考虑输出域边界。

　　错误推测设计方法就是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法。

　　因果图方法是从用自然语言书写的程序规格说明的描述中找出因（输入条件）和果（输出或程序状态的改变），可以通过因果图转换为判定表。

　　正交试验设计法，就是使用已经造好了的正交表格来安排试验并进行数据分析的一种方法，目的是用最少的测试用例达到最高的测试覆盖率。

　

 　白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。

　　这一方法是把测试对象看作一个打开的盒子，测试人员依据程序内部逻辑结构相关信息，设计或选择测试用例，对程序所有逻辑路径进行测试，通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。

　　采用什么方法对软件进行测试呢？常用的软件测试方法有两大类：静态测试方法和动态测试方法。其中软件的静态测试不要求在计算机上实际执行所测程序，主要以一些人工的模拟技术对软件进行分析和测试；而软件的动态测试是通过输入一组预先按照一定的测试准则构造的实例数据来动态运行程序，而达到发现程序错误的过程。

 

  在制定测试计划的时候，就要考虑到测试的风险，并抉择要执行哪些测试，并放弃哪些测试；测试计划的评审应该让开发人员参与；测试模型的制作应该尽可能贴近用户，或者站在用户的使用立场上来观测软件，此时应该能发现更多的问题。

  由于测试发现问题，在解决问题后还要重新测试，因此测试的时间可能会比实际更长一些.

  识别和注意少数重要的方面，而忽略多数次要的方面，有时候少数的问题足以致命，这些问题将是软件测试结果中重要性最高的错误。

  错误的定位有时是很难的，要找出必然发生的前因后果，而不至于因为描述错误而误导开发人员。有时候确实存在错误不能重建的问题。解决办法之一是在错误报告中给予说明。

  对错误的描述，应该是准确、完整而简练。因为描述的问题或者不完整的描述会引起开发人员的误解，其后果是可以想见的。

  有时有经验的测试人员凭借直觉就可以发现一些问题，这可称为“错误猜测”。

  测试人员容易犯2种错误：一是测试人员发生判断错误，将本没有错误的系统行为报告为错误，或者将错误指定了过高的严重级别，或者过高估计了问题的严重性，这样会引起开发人员的不信任，产生一种象“狼来了”一样的效果；二是测试人员将错误的严重性或优先级定得过低，从而产生“测试逃逸”，这样会造成产品质量的风险。以上两种错误应该尽量避免.
 

22 什么是“软件测试”？

  Software testing is the process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs) and to evaluate the features ofthe software item

1就是一个通过分析软件和需求之前差异，发现bug,对软件的功能进行评价的过程。

2.软件测试就是在受控制的条件下对系统或应用程序进行操作并评价操作的结果。

3.软件测试是为了发现错误而执行程序的过程。

23 什么是“测试案例”?

 测试案例是一份文档，它描述了一个输入、反应、或者是与其相应的预期的响应，以便来判断应用软件的工作是否正常。测试案例应当包括测试标识、测试案例的名称、目标、测试条件/设置、输入数据要求、步骤、以及预期的结果。

24 如果时间不够，无法进行充分的测试怎么办?

使用风险分析，确定测试的重点。由于很少有机会对一个应用软件进行所有可能的测试 (包括所有可能的事件组合、所有的相关性、或者一切可能出错的东西)，对大多数软件开发项目来说，利用风险分析是适当的。这需要判断技能、常识、感觉和经验。如果有正当理由，也可采用正式的方法。需要考虑下列因素：

1) 对于该项目的用途而言，哪种功能最重要?

2) 哪种功能对用户最明显?

3) 哪种功能对安全影响最大?

4) 哪种功能对用户最有用?

5)对客户来说，该应用软件的哪个部分最重要?

6)在开发过程中，该应用软件的哪个部分可以最先测试?

7)哪一部分代码最复杂，容易导致出现错误?

8)哪一部分的应用程序是在急迫或在惊恐的情况下开发出来的?

9)哪一部分程序与过去项目中引起问题的部分相类似/有关?

10)哪一部分程序与过去项目中需要大量维护的部分相类似/有关?

11)需求和设计的那些部分不清楚或不容易读?

12)开发人员认为在应用软件中哪些部分是高风险的?

13)哪些问题能造成最差的发行?

14)哪些问题最能引起用户抱怨?

15)哪些测试可以容易地覆盖多种功能?

16)哪些测试在覆盖高风险部分的测试时使用时间最少?

25 如果需求一直在变化怎么办?

1)如果可能，尽早与承担该项目风险的人接触，以便了解需求会怎样改变，从而可以尽早地改变测试计划和策略。

2)如果在对应用程序进行初始设计时多考虑一些适应性，那么以后在发生需求的改变时，就不需要再为改变做很多事情了。

3)好的代码注释和好的文档有助于开发人员作出相应的改变。

4)只要有可能，就应使用快速原型 (rapid prototyping)，以帮助用户确认他们的需求，从而减少变更。

5)在项目的时间表中应当留出余量，以应付可能出现的变更。

6)尽量把新的需求纳入应用软件的“下一版”，而把原始需求作为“第一版”。

7)通过谈判，把易于实现的新的变更列入项目，而把难于实现的新需求列入该应用软件的以后的版本。

8)要确保让客户和管理人员了解变更对进度表的影响、所带来的风险、以及因变更所引起的大量资金消耗。

9)在应付改变时，应在为建立自动测试而作的努力和重新进行测试所做的努力之间取得平衡。

10)在设计自动测试剧本时，试图使其有一些灵活性。

11)在对应用软件进行自动测试时，要把注意力集中在看来不大会改变的部分。

12)对变更进行适当的风险分析，以减少回归测试的要求。

13)在设计测试案例时要有一定的灵活性。做到这一点并不容易，所以要降低测试案例的详细程度，或者只建立高级的通用型的测试计划。

14)少注意详细的测试计划和测试案例，要把重点放在专门的测试 (ad hoc testing) 上。

15、集成测试通常都有那些策略？

1、在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；
2、各个子功能组合起来，能否达到预期要求的父功能；
3、一个模块的功能是否会对另一个模块的功能产生不利的影响；
4、全局数据结构是否有问题；
5、单个模块的误差积累起来，是否会放大，从而达到不可接受的程度。

16、一个缺陷测试报告的组成

测试软件项目名称,每个要测试软件项目都有唯一的名称，有的公司对项目还有特定的编号。

测试软件版本号,测试周期内，一般需要测试多个软件版本，报告错误时，一定要正确填写产生错误的软件版本号。

测试者名称,便于分清责任，便于管理。

测试日期与时间,便于分析和统计错误报告信息。

测试软件环境,包括操作系统和其他必要的软件程序。

测试硬件环境,包括测试计算机和其他测试设备的配置信息。

错误描述,简明的描述错误的特征，便于查询和快速浏览。

错误标识编号 (ID#) ,每个错误都有一个唯一的标识编号，方便查询。

错误类型,根据错误类型，分配给适当的人员处理错误。

错误级别,错误的严重程度和处理的优先级，优先处理高级别的错误。

错误状态,错误状态表明错误是否已经处理和将怎样处理，根据错误状态，采用适当的处理方法。

错误处理者名称,便于分清责任，便于管理。

重现错误的操作步骤,便于重现错误，修复错误和验证错误。

期望的结果,描述满足设计要求的结果。

实际测试结果,描述实际测试后得到的结果。

必要的附图,便于确认错误的表现形式和错误位置。

测试者的建议等注释,便于错误处理者快速和正确处理错误

17、基于WEB信息管理系统测试时应考虑的因素有哪些？

一、功能测试

    1、链接测试 

    2、表单测试

    3、Cookies测试

    4、设计语言测试 

    5、数据库测试

二、性能测试

    1、连接速度测试 

    2、负载测试  

    3、压力测试  

三、可用性测试

    1、导航测试  

    2、图形测试

    3、内容测试

    4、整体界面测试

四、客户端兼容性测试

    1、平台测试   

    2、浏览器测试  

五、安全性测试

18、软件本地化测试比功能测试都有哪些方面需要注意？

 软件本地化测试的测试策略：

1.本地化软件要在各种本地化操作系统上安装并测试。

2.源语言软件安装在另一台相同源语言操作系统上，作为对比测试。

3.重点测试因本地化引起的软件的功能和软件界面的错误。

4.测试本地化软件的翻译质量。

5.手工测试和自动测试相结合

19、软件测试项目从什么时候开始？为什么？

  软件测试应该在需求分析阶段就介入,因为测试的对象不仅仅是程序编码,应该对软件开发过程中产生的所有产品都测试,并且软件缺陷存在放大趋势.缺陷发现的越晚,修复它所花费的成本就越大.

20、需求测试注意事项有哪些？

一个良好的需求应当具有一下特点：
完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。

正确性：每一项需求都必须准确地陈述其要开发的功能。

一致性：一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。

可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。

无二义性：对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。

健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。

必要性：“必要性”可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如Use Case或别的来源。

可测试性：每项需求都能通过设计测试用例或其它的验证方法来进行测试。

可修改性：每项需求只应在S R S 中出现一次。这样更改时易于保持一致性。

另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。

可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好（f i n e - g r a i n e d ）的方式编写并单独标明，而不是大段大段的叙述。

21、简述一下缺陷的生命周期

    软件缺陷的生命周期指的是一个软件缺陷被发现、报告到这个缺陷被修复、验证直至最后关闭的完整过程。

简单的软件缺陷生命周期：
1、发现——打开：测试人员找到软件缺陷并将软件缺陷提交给开发人员；
2、打开——修复：开发人员再现、修复缺陷，然后提交测试人员去验证；
3、修复——关闭：测试人员验证修复过的软件，关闭已不存在的缺陷。

但是这是一种理想的状态，在实际的工作中是很难有这样的顺利的，需要考虑的各种情况都还是非常多的。

复杂的软件缺陷生命周期：
1、新建一个软件缺陷，这个软件缺陷是（open）状态，进行bug审查，不是代码问题，就是设计需要修改；
2、新建一个软件缺陷，这个软件缺陷是（open）状态，进行bug审查，以后修改的，就可以延期；
3、新建一个软件缺陷，这个软件缺陷是（open）状态，进行bug审查，实际没有这个bug，可以将其关闭；
4、新建一个软件缺陷，这个软件缺陷是（open）状态，看是否 清楚可重现，如果不能重现，就是缺少信息，需要返回到（open）状态；如果能够重现，就进行修正，修正后关闭，进行回归测试。
 软件缺陷生命

 Web网站的性能测试工具

   随着Web 2.0技术的迅速发展，许多公司都开发了一些基于Web的网站服务，通常在设计开发Web应用系统的时候很难模拟出大量用户同时访问系统的实际情况，因此，当Web网站遇到访问高峰时，容易发生服务器响应速度变慢甚至服务中断。为了避免这种情况，需要一种能够真实模拟大量用户访问Web应用系统的性能测试工具进行压力测试，来测试静态HTML页面的响应时间，甚至测试动态网页（包括ASP、PHP、JSP等）的响应时间，为服务器的性能优化和调整提供数据依据。

  Web 2.0开发测试人员使用Microsoft 的Web Application Stress Tool这个工具软件，这个微软提供的小工具仅9.58M，很小巧且实用。虽然功能上比不了专业的LoadRunner，但LoadRunner体积庞大，价格不菲，一般的企业也不会花那么多钱去购买LoadRunner，而微软的WAS则是完全免费，并且主要的功能都有，够用就行。

  Microsoft Web Application Stress Tool能有效测试一个网站的负载性能，这个软件可以通过脚本模拟100个强并发用户的访问，并模拟实际用户的一些点击操作，WAS还可以连接上远程Windows网站服务器的性能计数器（Performance Counter），通过对服务器性能（CPU/内存等）的性能分析来找到系统的瓶颈。CPU使用百分比反映了处理器开销，CPU使用百分比持续地超过75%是性能瓶颈在于处理器的一个明显的迹象。

每次测试运行结束后WAS会生成详细的报表，WAS报表可以从View菜单选择Reports查看。

前十大测试工具排名如下：

业级自动化测试工具WinRunner

Mercury Interactive公司的WinRunner是一种企业级的功能测试工具，用于检测应用程序是否能够达到预期的功能及正常运行。通过自动录制、检测和回放用户的应用操作，WinRunner能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试，提高测试人员的工作效率和质量，确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行。

工业标准级负载测试工具Loadrunner

LoadRunner 是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner 能够对整个企业架构进行测试。通过使用LoadRunner ，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。

全球测试管理系统testdirector

TestDirector 是业界第一个基于Web的测试管理系统，它可以在您公司内部或外部进行全球范围内测试的管理。通过在一个整体的应用系统中集成了测试管理的各个部分，包括需求管理，测试计划，测试执行以及错误跟踪等功能，TestDirector极大地加速了测试过程。

功能测试工具Rational Robot

IBM Rational Robot 是业界最顶尖的功能测试工具，它甚至可以在测试人员学习高级脚本技术之前帮助其进行成功的测试。它集成在测试人员的桌面 IBM Rational TestManager 上，在这里测试人员可以计划、组织、执行、管理和报告所有测试活动，包括手动测试报告。这种测试和管理的双重功能是自动化测试的理想开始。

单元测试工具xUnit系列

目前的最流行的单元测试工具是xUnit系列框架，常用的根据语言不同分为JUnit（java），CppUnit（C++），DUnit （Delphi ），NUnit（.net），PhpUnit（Php ）等等。该测试框架的第一个和最杰出的应用就是由Erich Gamma （《设计模式》的作者）和Kent Beck（XP（Extreme Programming）的创始人 ）提供的开放源代码的JUnit.

功能测试工具SilkTest

Borland SilkTest 2006属于软件功能测试工具，是Borland公司所提出软件质量管理解决方案的套件之一。这个工具采用精灵设定与自动化执行测试，无论是程序设计新手或资深的专家都能快速建立功能测试，并分析功能错误。

性能测试工具WAS

Microsoft Web Application Stress Tool 是由微软的网站测试人员所开发，专门用来进行实际网站压力测试的一套工具。透过这套功能强大的压力测试工具，您可以使用少量的Client端计算机仿真大量用户上线对网站服务所可能造成的影响。

白盒测试工具Jtest

Jtest是parasoft公司推出的一款针对java语言的自动化白盒测试工具，它通过自动实现java的单元测试和代码标准校验，来提高代码的可靠性。parasoft同时出品的还有C++ test，是一款C/C++白盒测试工具。

功能和性能测试的工具JMeter

JMeter是Apache组织的开放源代码项目，它是功能和性能测试的工具，100%的用java实现。

性能测试和分析工具WEBLODE

webload是RadView公司推出的一个性能测试和分析工具，它让web应用程序开发者自动执行压力测试；webload通过模拟真实用户的操作，生成压力负载来测试web的性能。

 

 

 

11.专业词语解释

α测试:

Alpha测试（α测试）是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。Alpha测试发现的错误，可以在测试现场立刻反馈给开发人员，由开发人员及时分析和处理。目的是评价软件产品的功能、可使用性、可靠性、性能和支持。尤其注重产品的界面和特色。Alpha测试可以从软件产品编码结束之后开始，或在模块（子系统）测试完成后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。有关的手册（草稿）等应该在Alpha测试前准备好。

β测试

Beta测试（β测试）是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。因而，Beta测试是 在开发者无法控制的环境下进行的软件现场应用。在Beta测试中，由用户记下遇到的所有问题，包括真实的以及主管认定的，定期向开发者报告，开发者在综合用户的报告后，做出修改，最后将软件产品交付给全体用户使用。Beta测试着重于产品的支持性，包括文档、客户培训和支持产品的生产能力。只有当Alpha测试达到一定的可靠程度后，才能开始Beta测试。由于Beta测试的主要目标是测试可支持性，所以Beta测试应该尽可能由主持产品发行的人员来管理。

驱动模块:

驱动模块在大多数场合称为"主程序"，它接收测试数据并将这些数据传递到被测试模块.单元测试一个函数单元时，被测单元本身是不能独立运行的，需要为其传送数据，为此  写驱动

驱动模块主要完成以下事情：
1、接受测试输入；
2、对输入进行判断；
3、将输入传给被测单元，驱动被测单元执行；
4、接受被测单元执行结果，并对结果进行判断；
5、将判断结果作为用例执行结果输出测试报告。

桩模块

比如对函数A做单元测试时，被测的函数单元下还包括了一个函数B，为了更好的错误，定位错误，就要为函数B写桩，来模拟函数B的功能，保证其正确。

白盒测试

白盒测试(White-box Testing，又称逻辑驱动测试,结构测试),它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。

对开发语言的支持：白盒测试工具是对源代码进行的测试，测试的主要内容包括词法分析与语法分析、静态错误分析、动态检测等。目前测试工具主要支持的开发语言包括：标准C、C＋＋、Visual C＋＋、Java、Visual J＋+等。

静态测试

动态通过评审文档、阅读代码等方式测试软件称为静态测试,通过运行程序测试软件称为测试.在动态测试中,通常使用白盒测试和黑盒测试从不同的角度设计测试用例,查找软件代码中的错误.

12、 回归测试

回归测试的目的是在程序有修改的情况下，保证原有功能正常的一种测试策略和方法。
说白了就是，我们测试人员在对程序进行测试时发现bug，然后返还程序员修改，程序员修改后发布新的软件包或新的软件补丁包给我们测试人员，我们就要重新对这个程序测试，已保证程序在修正了以前bug的情况下，正常运行，且不会带来新的错误的这样一个过程。  一般情况下是不需要全面测试的，而是根据修改的情况进行有效的测试。

13、单元测试、集成测试、系统测试的侧重点是什么？

单元测试是在软件开发过程中要进行的最低级别的测试活动，在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试，测试重点是系统的模块，包括子程序的正确性验证等。

集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求，组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。测试重点是模块间的衔接以及参数的传递等。

系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。测试重点是整个系统的运行以及与其他软件的兼容性。

14、设计用例的方法、依据有那些？  

白盒测试用例设计有如下方法:基本路径测试\等价类划分\边界值分析\覆盖测试\循环测试\数据流测试\程序插桩测试\变异测试.这时候依据就是详细设计说明书及其代码结构

黑盒测试用例设计方法:基于用户需求的测试\功能图分析方法\等价类划分方法\边界值分析方法\错误推测方法\因果图方法\判定表驱动分析方法\正交实验设计方法.依据是用户需求规格说明书,详细设计说明书。