软件测试管理工具 TestLink 应用

软件测试管理工具 TestLink 应用
软件测试管理工具 TestLink 应用

2.3.4 TestLink 应用举例

下面将从TestLink 初始配置、确定测试需求、测试用例管理、制定测试计划、测试报告与度量以及与缺陷管理系统的集成等方面对TestLink 的具体应用进行介绍

1、用户设置

打开浏览器,在地址栏输入http://localhost/testlink。

系统为TestLink 创建了一个默认的管理员账号,用户名/密码为admin/admin。可以使用这个账号访问TestLink,如果是第一次访问,访问后TestLink 会要求您创建一个新的测试项目,如图2-12所示。

图2-12 创建新的测试项目

只有在创建了测试项目之后,页面上才会出现功能栏,如图2-13所示。

图2-13 TestLink的功能栏

在TestLink 系统中,每个用户都可以维护自己的私有信息。admin 可以创建用户,但无法看到其他用户的密码。在用户信息中,需要提供E-mail 地址,如图2-14 所示。这样当用户忘记密码时,便可以通过E-mail 来获得。

TestLink 有6 种不同的默认权限级别,对于管理员来说,通过用户管理链接可以很容易地改变权限。这些权限如下所示:

● Guest:只能查看测试用例和项目度量。

● Tester:只能执行分配给他们的测试用例。

● Test Designer:可以开展测试用例和测试需求的所有工作。

●Senior Tester:可以查看、创建、编辑和删除测试用例,并且可以执行测试用例,但

是不能管理测试计划、管理产品、创建里程碑或分配权限。(针对初级测试员和高级测试员)

●Leader:拥有一个Tester 所有的权限,并且可以管理测试计划、分配权限、创建里

程碑和管理关键字。

●Admin(Administrator):拥有一个Leader 所有的权限,并且可以维护整个产品。

图2-14 用户信息

详细情况请参见表2-1 和图2-15。

表2-1 用户角色及相应职能

角色权限列表能力查看测试规范(组件、分类和测试用例的数据),查看关键

Guest 字,查看度量只能浏览数据

Tester

执行测试用例,查看度量只能执行测试

Senior tester 执行测试用例,查看度量,创建构建,查看、修改测试规

范(组编辑测试规范和执行件、分类和测试用例的数据),查看关键字,查看测试需

求测试

查看度量,查看、修改测试规范(组件、分类和测试用例

编辑测试规范和测试

Test Designer 的数据),查看关键字,创建、编辑、结合和删除测试需

需求求,查看测试需求

执行测试用例、创建构建、查看度量,创建、编辑、删除

Leader 试计划,设置风险/所有权,编辑/删除里程碑,编辑用例

集,设置查看项目的权限,查看/修改测试规范(组件、

分类和

拥有所有测试计划权

限,编辑测试规范和

执行测试

试用例的数据),查看/修改关键字,查看/修改测试需求

执行测试用例、创建构建、查看度量,创建、编辑、删除

Admin 测试计划,设置风险/所有权,编辑/删除里程碑,编辑用

进行一切可行

性操

(Administrator) 例集,设置查看项目的权限,查看/修改测试规范(组件、作,只有此用户可以分类和测试用例的数据),查看/修改关键字,查看/修改

测维护产品和用户

试需求,创建、编辑和删除产品,创建、删除和维护用户

同时,TestLink 初始配置支持不同地域用户对不同语言的需求,为用户提供不同的语言支持。

2、 1)创建需求规格

单击主页,在主页上找到产品需求,新建一个需求规格。对于需求规格的描述比较简单,内容包含文档ID,标题、范围。如图2-16

图2-16 创建产品需求规格点击左侧的“在线考试系统”节点。在右侧的界面中点击“新建产品需求规格”按钮。输入文档ID:1,标题:前台功能测试。然后创建另一个规格文档ID:2,标题:后台功能测试。完成以后如图2-17所示。

图2-17 产品需求规格

2) 创建需求

选择你要编辑的需求规格,点击该页面上的“创建新产品需求”按钮,开始新建测试需求。点击需求规格“1:前台功能测试”,添加它的需求:1.1登录验证,需要的测试用例数1个,如图2-18所示。

图2-18 创建需求

添加其他需求,如表2-2所示。

表2-2 所有需求

完成后的需求如图2-19所示。

测试需求内容包含:文档标识、名称、范围、需求的状态,以及覆盖需求的案例。

3. 测试用例管理

TestLink 支持的测试用例管理包含2层:测试用例集或测试套件(Test Suites)、测试用例(Test Cases)。可以把测试用例集对应到项目的功能模块。测试用例与每个模块的功能相对应。可

以使用测试用例搜索功能从不同的项目以及成百上千的测试用例中查到我们需要的测试用例,甚至可以直接将别的项目里的测试用例复制过来,这样就解决了测试用例的管理和复

用问题。但是,还有一个问题没有解决,那就是与测试需求的对应问题。在测试管理中,

测试用例对测试需求的覆盖率是我们非常关心的,从需求规格说明书中提取出测试需求之

后,TestLink 会提供管理测试需求与测试用例间对应关系的功能。

1) 创建用例集

点击主页上的“测试用例”菜单下的“编辑测试用例”,出现如下界面,参见图2-20。

图2-20 创建用例集主页面

.点击左侧的“在线考试系统”,在右侧窗口点击“新建测试用例集”按钮,添加两个测试集合“前台功能测试(学生端)”和“后台功能测试(教师端)”。如图2-21所示。

图2-21 创建用例集

填写好相关的内容后,可以点击“创建测试用例集”按钮,创建该用例集。完成以后如图2-22所示。

2) 添加测试用例图2-22 测试用例集创建完成

选择创建好的测试用例集“前台功能测试(学生端)”,点击该页面右侧的“创建测试用例”按钮,新建一个名为“登录验证”的测试用例。如图2-23所示。

图2-23 创建测试用例测试用例创建成功后,点击“创建步骤”按钮,输入数据,点击“保存”如图2-24所示。

图2-24 创建测试步骤

按照此方法添加表2-3 所示数据。

表2-3 所有测试数据

摘要,要求短小、概括全面;步骤,描述测试说明(输入行为)以及可以包括的前提条件及

清除信息;期望的结果,描述检验点和一个测试产品或系统的预期行为。

建议:在编写测试用例时,要细分每一个数据类型。有些测试用例的编写步骤是相同

的,变化的可能只是数据类型,可以采用复制的方法来实现。如果有多个分类下面的测试

用例操作相同,而只是部分数据类型或字段名称不同,则可以通过移动测试用例的方法来

减少测试用例工作量。同时,也可以在创建测试用例的摘要中,将不同的测试数据罗列,

然后在测试步骤中,根据不同的测试数据,执行相同的操作。

完成上述操作后,创建好的测试用例树如图2-25所示。

图2-25 测试用例树

3) 删除测试用例

经过主管许可后,通过“删除”按钮可以将测试用例集和测试用例从一个测试计划中删除。当第一次创建一个测试计划时,由于其中还没有包含任何结论,删除数据也许是有益的。但是在大部分情况下,删除测试用例会导致与它们相关联的所有结果都丢失。因此,使用这项功能时一定要十分谨慎。

4) 需求关联

测试用例和软件/系统需求之间是n 对n 的关系。对于一个产品来说,这个功能是一定

要用到的。用户可以通过主页面中的指派产品需求,把需求指派给测试用例。点击主页“产品需求”模块下的“指派产品需求”菜单,进入指派需求页面,选中左侧

用例树中的测试用例,再选择右侧对应的测试需求,进行指派即可。本特性允许在需求和测试用例之间建立关系,设计人员可以定义0..n到0..n的关系。例如,一个需求可以被指派给零个、一个或多个测试用例上,反之亦然。

在线考试系统中测试用例与需求的关联如表2-4所示。

表2-4 测试用例与需求的关系

完成上述的操作,可以查看已经指派的测试用例。点击顶部的“产品需求”栏,在所示页面中点击左下的需求“1.4:在线考试”,可以看到需求的覆盖率。如图2-26所示。

图2-26 需求覆盖率

4. 制定测试计划(只能由admin 用户进行)

1) 创建测试计划

测试计划是执行测试用例的基础,测试计划由测试用例组成,而这些测试用例是在特定的时间段里输入到产品中的。测试计划只能主管创建,但也可以从其他测试计划中产生,同时还允许用户在紧急情况下及时从测试用例中创建测试计划。当为一个小模块创建一个测试计划时,上

述都是可以使用的方法。为了使用户可以查看测试计划,此用户必须有足够的权限,而查看测试计划的权限要在定义用户/产品权限页面由主管分配,当用户被告知他们不能查看工作中的项目时,权限是需要记住的重要事情。

在TestLink 系统中,一个完整的测试计划要包括各测试阶段的名称(如集成测试阶段、

系统测试阶段)。

点击主页“测试计划管理”模块下的“测试计划管理”菜单。在出现的页面点击“创建”

按钮,进入测试计划创建页面。如图2-27 所示。

图2-27 创建测试计划

测试计划的内容包括:计划名称,计划描述,以及是否从已有的测试计划创建,如果选择从已有的测试计划中创建,则新创建的测试计划包含选择的已有测试计划的所有相关联的信息,比如已有测试假话分配的测试用例。

创建一个名为“在线考试系统——测试计划”的测试计划。

2)创建测试里程碑(明确每个测试阶段的开始和截止时间,以及完成A、B、C 三种优

先级的比例)

单击主页面“测试计划管理”模块下的“编辑/删除里程碑”菜单,创建一个新的测试

里程碑。测试里程碑的内容包括:名称、日期、优先级。如图2-28 所示。

图2-28 创建测试计划里程碑

3)版本管理(Builds/Releases)

测试计划做好后,就应该制定版本,比如ver1.0。测试过程中发现了bug,修改之后产生了ver2.0。这时应该追加版本,相应的接下来未完的测试以及降级测试都应该在新的版本上完成。所有测试完成后可以统计在各个版本上测试了哪些用例,每个版本上是否都进行了降级测试等等。

点击主页“测试计划管理”模块下的“版本管理”菜单,创建一个新的测试版本。如图2-29

所示。

图2-29 定义测试的版本测试版本的内容包括:版本的标识,版本的说明,以及选择该版本是否为活动和打开的版

本。如果是活动的版本,说明该版本可以用,否则该版本不可用。如果是打开的版本,则该版本的测试结果可修改,否则不可修改。在TestLink 中,“执行”由版本和测试用例组成。如果在一个项目中没有创建版本,执行页面将不允许执行,度量页面则完全是空白的,版本通常不能被编辑或删除。

4)安排测试人员(定义用户/测试计划角色权限)

单击主页面“测试计划管理”模块下的“指派用户角色”菜单,为测试计划指派用户。测试用户如表2-5所示。

表2-5 测试用户

在为测试计划指派用户页面,可以选择测试计划,选择好需要指派权限的测试角色后,点击更改按钮,则可以更改测试计划。选择好测试计划后,可以将该测试计划以不同的角色分配给不同的用户,通过角色列表,可以选择用户对该测试计划的操作角色,选择结束后,点击更新按钮,可以保存结果。如图2-30所示。

图2-30 指派测试计划用户角色

5)添加测试用例到测试计划

在主页通过测试计划下拉列表,先选择一个测试计划,点击“测试用例集”下的“添加/删除测试用例到测试计划”按钮,进入测试计划中添加测试用例。

可以将已经创建好的测试用例指派给该测试计划。点击一个测试用例集,可以看到该测试用例集下所有的测试用例,可以选择该测试计划中要执行的测试用例,点击“增加选择的测试用

例”来添加或删除测试用例,可以将选择好的测试用例分配给该测试计划。如图2-31所示。

图2-31 添加测试用例到测试计划

6)移除测试用例

在图2-31所示的页面中,可以在复选框勾选不需要在该测试计划中执行的测试用例,然后点

击“添加/删除选择的”按钮,将测试用例移除。如图2-32所示。

图2-32 移除测试用例

7)设置测试用例的所用者(给测试人员分派测试任务)

单击主页面“测试用例集”模块下的“指派执行测试用例”菜单,进入指派测试

用例页面,可以为当前测试计划中所包含的每个测试用例指定一个具体的执行人员。

在指派测试用例页面,从左侧用例树中选择某个测试用例集或测试用例,右侧页面将会出现下拉列表供您选择用户。选择好合适的用户后,选中测试用例前面的复选框,单击

“保存”按钮即可完成测试用例的指派工作,如图2-32 所示。

图2-32 设置测试用例的所有者当然,这里也可以进行批量指定——右侧页面的最上方有一个下拉列表可以选择用户,在

下方的测试用例列表中选择要指派给该用户的用例,然后点击一下后面的“执行”按钮即可完成将多个用例指派给一个人的操作。

8) 执行测试

在TestLink顶部的菜单栏中有“执行”选项,点击进入“测试用例执行”页面。如图2-33所示。

图2-33 测试用例执行

这里需要说明一点,虽然“执行”表面上针对的是测试计划,但实际上对应的是测试计划中测试用例的执行情况。

在左侧用例树中,可以根据具体的条件来选择测试用例。选择某一个测试用例集后,页面右侧上方会出现测试计划、build 描述、测试集说明等信息,页面下方则是每个测试用例的详细情况,同时每一个测试用例的最后部分,有“说明/描述”输入框,可以在这里输入执行的一些说明性情况,还有“测试结果”,这两个输入框都是需要我们执行完测试用例后自己来填写的。

测试结果分以下4 种情况:

●通过:该测试用例执行通过。

●失败:该测试用例没有执行成功,这个时候可能就要向Mantis 提交Bug 了。

●锁定:由于其他用例执行失败,导致此用例无法执行,被阻塞。

●尚未执行:如果某个测试用例没有执行,则在最后的度量中将其标记为“尚未执行”。

执行测试页面如图2-34所示。

6.测试结果分析

TestLink根据测试过程中记录的数据,提供了较为丰富的度量统计功能,可以直观的得到测试管理过程中需要进行分析和总结的数据。点击首页导航菜单栏中的“结果”菜单,即可进入测试结果报告页面,主要包括的功能如图2-40所示。

图2-40 测试结果报告主要功能

1) 总体测试计划进度

查看总体的测试情况,可以根据测试组件,测试用例拥有者,关键字进行查看。如图2-41所示。

图2-41 总体测试计划进度

2) 失败的测试用例

统计所有当前测试结果为失败的测试用例

3) 锁定的测试用例

统计所有当前测试结果为锁定的测试用例。

4) 尚未执行的测试用例

统计所有当前尚未执行测试的测试用例。如图2-42所示。

图2-42 尚未执行的测试用例

5) 图表

点击图表,可以看到TestLink以图表的形式生成的报告,非常直观。这里主要是通过图表的形式来表示测试用例的执行情况,红色表示测试失败,蓝色表示锁定用例,绿色表示通过测试,黑色表示尚未执行。如图2-43,2-44所示。

注意:TestLink图表中文显示乱码的解决办法如下

●从Windows字体库中找到SIMYOU.TTF(幼圆),将其拷贝到TestLink中的pchat字体目录。路径

为:E:\xampp\htdocs\testlink\third_party\pchart\Fonts(以本书安装路径为例)。

●修改config.inc.php文件,将:

$tlCfg->charts_font_path = TL_ABS_PATH . "third_party/pchart/Fonts/tahoma.ttf";

中的字体tahoma.ttf修改为SIMYOU.TTF

图2-43 总体测试结果饼图

图2-44 顶层测试用例集结果

总的来说,TestLink 已经为我们创造了很好的测试管理条件,其配置也相对简单,我们可以根据自己的需要进行相关的配置。另外,TestLink 是开源的测试工具,这也提高了其灵活性。不过在TestLink 的使用过程中,我们也感觉到了一些不便之处,比如很多情况下,需要回到主页面才能单击一些链接,并且TestLink 和缺陷管理工具的整合需要手工来

完成。另外,一些描述信息需要用文字描述,如果能提供填表的方式,效果会更好。

软件测试流程管理体系

测试体系建设与软件测试流程 (初稿)

目录 1.目的3 2.范围3 3.测试过程描述4 3.1 测试流程图4 3.2 活动说明5 3.2.1 需求评审5 3.2.2 编写测试计划6 3.2.3测试用例设计8 3.2.4 测试用例执行9 3.2.5发布版本回归测试12 3.2.6版本迭代回归测试13 3.2.7 文档测试16 3.2.8 测试报告18 4.软件缺陷管理系统—禅道19 4.1 概述19 4.1.1 编写目的19

4.1.2 适用范围19 4.1.3 角色和职责19 4.1.4 禅道简介19 4.2 缺陷状态关系示意图20 4.3 缺陷流转的过程及处理20 4.3.1 基于禅道的项目/测试/Bug管理21 4.4 禅道项目管理流程图21 5.配置管理21 1.目的 本文是对项目软件测试的指导性文件,对软件测试过程中所涉及到的测试理论、测试类型、测试方法、测试标准、测试流程及测试过程中涉及到的角色职责进行总体规范,以有效保证软件质量。 2.范围 本文适用于所有软件测试人员。

3.测试过程描述 3.1 测试流程图 需求规格说明书 测试用例 测试计划 开发计划 评审Checklist 需求评审会议 评审通过 评审 测试版本发布 执行测试用例部署测试环境提交缺陷报告 修复缺陷 确认缺陷是否 验证缺陷 不通过 测试完成通过 测试报告发布上线

3.2 活动说明 3.2.1需求评审 3.2.1.1目的 从源头把握软件质量,并确保开发结果与实际需求相一致,分析需求实现的可能性,功能细节描述无二义,补充需求细节,确定项目周期和时间。 3.2.1.2角色与职责 测试负责人:《需求规格说明书》的编写,以及软件开发过程中《需求规格说明书》的修正; 评审人员:项目经理、开发人员、测试人员等项目干系人; 评审《需求规格说明书》,从全面性、完整性、正确性、一致性、可靠性方面检查《需求规格说明书》,将需求缺陷Checklist提交给产品需求人员,在评审会议上讨论,确定为缺陷后,跟踪需求缺陷直至需求缺陷验证关闭。 3.2.1.3启动标准 《软件需求规格说明书SRS》编写完成

其他测试、软件测试过程和管理(二)

其他测试、软件测试过程和管理(二) (总分:100.00,做题时间:90分钟) 一、{{B}}选择题{{/B}}(总题数:42,分数:100.00) 1.下面有关软件测试的叙述中,不属于H模型核心思想的是______。 ? A.软件测试不仅指测试的执行,还包括很多其他的活动 ? B.软件测试是一个独立的流程,贯穿产品整个开发周期,与其他流程并发地进行 ? C.软件测试要尽早准备,尽早执行 ? D.软件测试不同层次的测试活动严格按照某种线性次序执行 (分数:2.50) A. B. C. D. √ 解析:[解析] 软件测试的不同的测试活动可以是按照某个次序先后进行的,但也可能是反复的,只要某个测试达到准备就绪点,测试活动就可以开展。 2.以下有关测试用例设计与开发的说法中,错误的是______。 ? A.白盒测试的测试用例设计不必考虑软件功能 ? B.软件测试用例设计要关注测试用例设计的测试需求覆盖率 ? C.自动化测试的测试脚本开发属于测试用例设计工作的一部分 ? D.测试用例设计的主要依据是测试计划中的测试需求定义 (分数:2.50) A. B. C. D. √ 解析:[解析] 白盒测试义称为逻辑驱动的测试,这种测试策略对程序的逻辑结构进行检查,从中获取测试数据,故A对。自动化测试的测试脚本开发属于自动化测试用例设计工作的一部分,故C对。根据产品需求分析、系统设计等规格说明书,在测试的技术方案基础上设计具体的测试用例,故D错。测试用例是否完整、边界是否考虑,其覆盖率能达到多高,是软件测试设计要点的一部分,故B对。 3.下列有关测试过程管理的基本原则,哪个是错误的______。 ? A.测试过程管理应该首先建立测试计划 ? B.测试需求在测试过程中可以是模糊的、非完整的 ? C.在测试任务较多的情况下,应该建立测试任务的优先级来优化处理 ? D.整个测试过程应该具有良好的可测性和可跟踪性,强调以数据说话 (分数:2.50) A. B. √

软件测试的基本流程

一:软件测试的基本流程 1.熟悉需求 2.需求评审(测试人员,开发,需求参与) 剔除需求中不合理的部分和一些无法实现的部分,有异议的地方,描述不清楚的地方。 3.编写测试计划 4.测试计划评审 5.测试分析 6.测试分析评审(交叉评审) 7.设计测试用例 8.编写测试用例 9.测试用例评审 10.冒烟测试 11.运行测试用例 12.提交BUG 13.回归测试 14.编写测试报告 二:什么是冒烟测试 冒烟测试,英文是Smoke testing。 冒烟测试的名称可以理解为该种测试耗时短,仅用一袋烟功夫足够了。也有人认为是形象地类比新电路板功基本功能检查。任何新电路板焊好后,先通电检查,如果存在设计缺陷,电路板可能会短路,板子冒烟了。 冒烟测试的对象是每一个新编译的需要正式测试的软件版本,目的是确认软件基本功能正常,可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。 三:什么是回归测试 回归测试是指修改了旧代码后,重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。 回归测试包括两部分:函数本身的测试、其他代码的测试。在对被修改的函数重新测试。如果函数的设计功能没有变化,直接运行函数测试就可以了。如果修改了设计功能,则要根据增减的功能点,增加或删除测试用例。另外,还要完成白盒覆盖。 函数代码的修改可能导致调用该函数的代码产生错误,所以需要测试其他代码。如果函数是私有函数并且未涉及到全局变量,应运行类测试,否则应运行工程测试。在函数列表中选择类测试或工程测试,编译运行测试工程,即可执行对其他代码的回归测试。 四:测试报告包含的内容

流程管理软件测试的流程

(流程管理)软件测试的流 程

软件测试的流程,包含各阶段会产生什么文档 无论是采用瀑布式仍是其他的产品生命周期模型,软件测试分为如下几个阶段:1、测试需求分析阶段。 测试需求分析阶段主要工作是获得测试项目的测试需求(测试规格)。 输出产物:《可测试性需求说明书》和《测试规格》 2、测试计划阶段。 以测试需求为基础,分析产品的总体测试策略。 输出产物:《产品总体测试策略》 3、测试方案设计阶段。 本阶段主要是以测试规格为基础获得特性测试方案,对于有自动化测试的项目,进行自动化测试的分析,获得测试策略。 输出产物:《产品或者版本总体测试方案》 4、测试用例实现阶段。 本阶段主要是完成各个特性的测试用例的编写和自动化脚本的编写。 输出产物:《产品自动化测试用例》和《手工执行测试用例》 5、测试执行阶段。 本阶段是根据测试策略开展测试执行和回归测试。 输出产品:《产品或版本测试方案》和《缺陷分析方案》 6、评估和关闭阶段。 只对前面的各个阶段的执行情况,完成对测试项目的关闭,同时提供完整的度量数据和项目总结方案。 输出产物:《遗留问题风险分析方案》、《度量分析方案》和《测试关闭方案》软件生命周期的各个阶段如何应用哪些软件测试方法。

画壹个V模型你就明白了:左边为开发过程,对应右边的测试过程,开发自上而下,测试是自下而上 开发过程测试过程 可行性研究验收测试 需求分析系统测试 概要设计集成测试 详细设计单元测试 软件编码阶段 1、需求分析阶段对应生成需求规格说明书,对应测试生成系统测试方案,即为系统测试准备的,该阶段已经完成了单元测试和集成测试,主要是对软件产品的功能和非功能进行测试,几乎不测试代码,所以测试方法以黑盒为主; 2、概要设计阶段对应生成概要设计说明书,对应测试生成集成测试方案,该阶段已完成单元测试,是将各个功能模块组装起来进行的测试,所以也叫组装测试。主要见模块调用是否正常,接口是否可用,数据传输是否正确等,所以用到的测试方法几乎是白盒的方法,如路径覆盖,条件组合覆盖等; 3、详细设计阶段对应生成详细设计说明书,对应测试生成单元测试方案,该阶段是开发人员编码后的第壹个测试阶段,是对开发出来的单独模块进行测试,以确保每壹个功能模块的功能正常,能够构建桩模块和驱动模块来回调用,方法也是以白盒为主。 4、白盒测试的准则是尽可能覆盖程序内部的逻辑结构,黑盒则是尽可能覆盖所有的输入输出接口,包括文档等壹些静态的测试。除常用的测试方法外,仍需补充大范围的随机测试,尽可能达到覆盖率100%。

软件测试流程及规范V1.1

软件测试流程及规范V1.1

二、各阶段具体流程 1.需求分析阶段 立项 需求调研 编写/修改SRS 提交SRS SRS 审核 审核是否通过 达到要求 提交最终版SRS 审核是否通过 审核通过 依据SRS ,项目整体计划,设计、编写《测试计划》 和《测试设计》《测试计划》根据SRS 定义相应的测试需求报告,即制订测试的标准,以后所有的测试工作都将围绕着测试需求来进行,符合测试需求的应用程序即是合格的,反之即是不合格的;同时,还要适当选择测试内容,合理安排测试人员、测试 时间及测试资源等。 《测试设计》 将测试计划阶段制订的测试需求 分解、细化为若干个可执行的测 试过程,并为每个测试过程选择 适当的测试用例。 进入概要设计阶段评审测试计划 和测试设计优化测试计划、 测试设计1.1步骤说明 1、需求定义基本完成,SRS 编写完成。 2、开评审会,由需求调研人员、开发组、设计组、测试组等人员对需求中不清楚、不完整、存在疑义的地方提出问题,相关人员解答并确认。 3、当评审未通过,直接打回,重新修改SRS ,问题解决后,重新提交评审。

4、当评审通过后,依据SRS,项目整体计划,设计、编写《测试计划》和《测试设计》,具体模板见附件。 5、开评审会,由开发组、设计组、测试组等人员对计划和设计中不清楚、不完整、存在疑义的地方提出问题。 6、当审批未通过,直接打回,优化测试计划、测试设计,问题解决后,重新提交评审。 7、审核通过后,进入下一阶段。 1.2测试通过打回标准 1.3、阶段的输出 输入:最新SRS、项目计划 输出:测试计划、测试设计 2、单元及集成测试流程

使用软件测试工具的目的

软件测试的目的:第一是确认软件的质量,其一方面是确认软件做了你所期望做的事情,另一方面是确认软件以正确的方式来做了这个事情。 第二是提供信息,比如提供给开发人员或程序经理的回馈信息,为风险评估所准备的信息。 第三软件测试不仅是在测试软件软件产品本身,而且还包括软件开发的过程。如果一个软件产品开发完成之后发现了很多问题,这说明此软件开发过程很可能是有缺陷的。因此,软件测试的第三个目的是保证整个软件开发过程是高质量的。 测试工具一般可分为白盒测试工具、黑盒测试工具、性能测试工具,另外还有用于测试管理(测试流程管理、缺陷跟踪管理、测试用例管理)的工具,这些产品主要是MercuryInteractive(MI)、Segue、IBM Rational、Compuware和Empirix等公司的产品,而MI公司的产品占了主流。白盒测试工具白盒测试工具一般是针对代码进行测试,测试中发现的缺陷可以定位到代码级,根据测试工具原理的不同,又可以分为静态测试工具和动态测试工具。静态测试工具:直接对代码进行分析,不需要运行代码,也不需要对代码编译链接,生成可执行文件。静态测试工具一般是对代码进行语法扫描,找出不符合编码规范的地方,根据某种质量模型评价代码的质量,生成系统的调用关系图等。静态测试工具的代表有:Telelogic公司的Logiscope 软件;PR公司的PRQA软件。动态测试工具:动态测试工具与静态

测试工具不同,动态测试工具的一般采用"插桩"的方式,向代码生成的可执行文件中插入一些监测代码,用来统计程序运行时的数据。其与静态测试工具最大的不同就是动态测试工具要求被测系统实际运行。动态测试工具的代表有:Compuware公司的DevPartner软件;Rational公司的Purify系列等。黑盒测试工具黑盒测试工具适用于黑盒测试的场合,黑盒测试工具包括功能测试工具和性能测试工具。黑盒测试工具的一般原理是利用脚本的录制(Record)/回放(Playback),模拟用户的操作,然后将被测系统的输出记录下来同预先给定的标准结果比较。黑盒测试工具可以大大减轻黑盒测试的工作量,在迭代开发的过程中,能够很好地进行回归测试。黑盒测试工具的代表有:Rational公司的TeamTest、Robot;Compuware公司的QACenter。性能测试工具专用于性能测试的工具包括有:Radview公司的WebLoad;Microsoft公司的WebStress等工具;针对数据库测试的TestBytes;对应用性能进行优化的EcoScope等工具。MercuryInteractive的LoadRunner是一种适用于各种体系架构的自动负载测试工具,它能预测系统行为并优化系统性能。LoadRunner的测试对象是整个企业的系统,它通过模拟实际用户的操作行为和实行实时性能监测,来帮助您更快的查找和发现问题。测试管理工具测试管理工具用于对测试进行管理。一般而言,测试管理工具对测试计划、测试用例、测试实施进行管理,并且,测试管理工具还包括对缺陷的跟踪管理。

软件测试基础要点总结

软件测试基础要点总结 软件测试基础要点总结 从宏观的角度讲,软件测试过程一般可划分为单元测试、集成测试、验收测试和系统测试等几个主要测试阶段。 1.测试计划注意事项 1.测试计划不一定要尽善尽美,但一定要切合实际,要根据项目特点、公司实际情况来编制,不能脱离实际情况; 2.测试计划一旦制定下来,并不就是一成不变的,随着软件需求、软件开发、人员流动等发生变化,测试计划也要根据实际情况的变化而不断进行调整,以满足实际测试要求.3.测试计划要能从宏观上反映项目的测试任务、测试阶段、资源需求等,不一定要太过详细.测试原则 ①应尽早和不断地进行软件“测试”。 ②测试用例中,不仅要选择合理的输入数据,还要选择不合理的输入数据。③在开发各阶段应事先分别制定出相应的测试计划,在测试开始后应严格执行,防止随意性。④对发现错误较多的程序模块,应进行重点测试。⑤避免程序员测试自己的程序。 ⑥用穷举测试是不现实的,一般通过设计测试用例,充分覆盖所有条件或所有语句即可。⑦长期妥善保存测试计划、测试用例、出错统计和有关的分析报告。 2.测试用例文档 测试用例文档通常是由简介和测试用例两部分组成:

简介部分编制了测试目的、测试范围、定义术语、参考文档等,这个与测试计划是一致的。 测试用例部分逐一列出各个测试用例。 测试用例(TestCase)是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求。 测试用例部分 测试用例通常包含的信息:用例标识和用例名称内容描述前提条件执行步骤预期结果评价准则 用例设计人员和设计时间用例执行人员和执行时间其它内容3.软件缺陷 缺陷的表现形式不仅体现在功能的失效方面,还体现在其他方面。主要类型有:①软件没有实现产品规格说明所要求的功能模块软件中;②出现了产品规格说明指明不应该出现的错误; ③软件实现了产品规格说明没有提到的功能模块; ④软件没有实现虽然产品规格说明没有明确提及但应该实现的目标; ⑤软件难以理解,不容易使用,运行缓慢,或从测试员的角度看,最终用户会认为不好。测试用例:以计算器为例 ①计算器的产品规格说明定应能准确无误地进行加、减、乘、除运算。如果按下加法键,没什么反应,就是第一种类型的缺陷;若计算结果出错,也是第一种类型的缺陷。②产品规格说明书还可能规定计算器不会死机,或者停止反应。如果随意敲键盘导致计算器停止接受输入,这就是第二种类型的缺陷。 ③如果使用计算器进行测试,发现除了加、减、乘、除之外还可以求平方根,但是产品规格说明没有提及这一功能模块。这是第三种类型的缺陷④在测试计算

软件测试工作流程()

软件开发与测试配合 工作流程 XXX软件股份有限公司质量部 目录 1.简介 本流程文件旨在规定一个简单的可使开发人员和测试人员在软件开发的编码阶段相互配合工作的工作流程,其中包括测试与开发的配合、送测单和BUG单的填写、测试循环的结束等部分。开发阶段与测试循环的关系、测试模块的组合与测试原则、BUG的分类评级原则等也在本流程文件中有相关的描述。 鉴于公司的技术要求,目前质量部的测试人员不仅要完成黑盒测试工作,而且还要进行白盒测试中的“代码走查”工作。其它的白盒测试工作,目前还不在测试人员的工作职责之内。 由于公司已经为质量管理部开发完成“辅助测试系统1.0”,因此本测试流程的制定就建立在辅助测试系统之上,如果辅助测试系统有了新的版本,质量部将根据其变化适当调整测试流程。 2.适用范围 本流程文件适用于公司开发软件并需要测试服务的任何软件开发项目组、软件开发人员,以及任何测试人员。

当项目组在辅助测试系统中注册以后,公司领导可以使用本系统查询了解所有在本系统中注册的项目的测试信息,项目的质量管理员可以使用本系统查询了解项目的当前测试进展情况。程序员和测试员都可以使用本系统查询到自己产生的送测单和BUG单。 3.术语、名词定义 3.1 送测软件 送测软件包括一切软件执行必须的文件、数据、数据库配置等。开发人员必须提供所有的详细的资料以保证测试人员可以像客户一样的运行被测软件。 3.2 开发文档 开发人员提供给测试人员的开发文档至少包括以下几种:用户需求,概要设计,详细设计,用户手册等。开发人员应当在开发每阶段完成后三天内就向测试人员传送本阶段完成的开发文档,以利于测试人员的工作。 3.3 测试文档 测试文档包括测试计划、测试用例说明、BUG报告及分析、测试总结,以及测试工作全部完成后的测试报告等。测试文档由测试人员编写并维护,也属于开发文档的一部分。

软件测试过程管理实践

软件测试过程管理实践 关键词 测试过程模型测试管理理念可持续改进 1 测试过程概述 1.1 软件测试过程概述 软件测试过程是一种抽象的模型,用于定义软件测试的流程和方法。众所周知,开发过程的质量决定了软件的质量,同样的,测试过程的质量将直接影响测试结果的准确性和有效性。软件测试过程和软件开发过程一样,都遵循软件工程原理,遵循管理学原理。 随着测试过程管理的发展,软件测试专家通过实践总结出了很多很好的测试过程模型。这些模型将测试活动进行了抽象,并与开发活动有机的进行了结合,是测试过程管理的重要参考依据。 1.2 软件测试过程模型介绍 V模型 V模型最早是由Paul Rook在20世纪80年代后期提出的,旨在改进软件开发的效率和效果。V模型反映出了测试活动与分析设计活动的关系。在图1-1中,从左到右描述了基本的开发过程和测试行为,非常明确的标注了测试过程中存在的不同类型的测试,并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系。 图1-1 软件测试V模型 V模型指出,单元和集成测试应检测程序的执行是否满足软件设计的要求;系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标;验收测试确定软件的实现是否满足用户需要或合同的要求。 但V模型存在一定的局限性,它仅仅把测试作为在编码之后的一个阶段,是针对程序进行的寻找错误的活动,而忽视了测试活动对需求分析、系统设计等活动的验证和确认的功能。 W模型 W模型由Evolutif公司公司提出,相对于V模型,W模型增加了软件各开发阶段中应同步进行的验证和确认活动。如图1-2所示,W模型由两个V字型模型组成,分别代表测试与开发过程,图中明确表示出了测试与开发的并行关系。 W模型强调:测试伴随着整个软件开发周期,而且测试的对象不仅仅是程序,需求、设计等同样要测试,也就是说,测试与开发是同步进行的。W模型有利于尽早地全面的发现问题。例如,需求分析完成后,测试人员就应该参与到对需求的验证和确认活动中,以尽早地找出缺陷所在。同时,对需求的测试也有利于及时了解项目难度和测试风险,及早

5类软件测试工具

目前主流的测试工具主要有以下5类: 1.负载压力测试工具 这类测试工具的主要目的是度量应用系统的可扩展性和性能,是一种预测系统行为和性能的自动化测试工具。在实施并发负载过程中,通过实时性能监测来确认和查找问题,并针对所发现问题对系统性能进行优化,确保应用的成功部署。负载压力测试工具能够对整个企业架构进行测试,通过这些测试,企业能最大限度地缩短测试时间,优化性能和加速应用系统的发布周期。 2.功能测试工具 通过自动录制、检测和回放用户的应用操作,将被测系统的输出记录同预先给定的标准结果比较,功能测试工具能够有效地帮助测试人员对复杂的企业级应用的不同发布版本的功能进行测试,提高测试人员的工作效率和质量。其主要目的是检测应用程序是否能够到预期的功能并正常运行。 3.白盒测试工具 白盒测试工具一般是针对代码进行测试,测试中发现的缺陷可以定位到代码级。根据测试工具原理的不同,又可以分为静态测试工具和动态测试工具。静态测试工具直接对代码进行分析,不需要运行代码,也不需要对代码编译链接和生成可执行文件。静态测试工具一般是对代码进行语法扫描,找出不符合编码规范的地方,根据某种质量模型评价代码的质量,生成系统的调用关系图等。动态测试工具一般采用“插桩”的方式,在代码生成的可执行文件中插入一些监测代码,用来统计程序运行时的数据。它与静态测试工具最大的不同是,动态测试工具要求被测系统实际运行。 4.测试管理工具 一般而言,测试管理工具对测试需求、测试计划、测试用例、测试实施进行管理,并且测试管理工具还包括对缺陷的跟踪管理。测试管理工具能让测试人员、开发人员或其他的IT 人员通过一个中央数据仓库,在不同地方就能交互信息。 5.测试辅助工具 这些工具本身并不执行测试,例如它们可以生成测试数据,为测试提供数据准备。 参加完“2005年IT测试技术研讨会”以后,谢常君对软件测试和网络测试的主流厂商和产品有了更全面的了解。不过最让他高兴的是结识了一批企业的代表和专家。 一个阳光明媚的下午,谢常君约上某位专家在一个咖啡馆会面。“非常谢谢你能前来,我这次约你出来是希望你可以给我一些专业的建议。”谢常君说,“我们公司近期可能需要采购一些测试工具,但是我们对此了解不多,希望你可以帮我们。”接下来,这位专家就首先从测试工具的分类开始讲起…… IT测试工具集锦 Radview TestView系列 Radview公司的TestView系列Web性能测试工具和WebLoad Analyzer性能分析工具,旨在测试Web应用和Web服务的功能、性能、程序漏洞、兼容性、稳定性和抗攻击性,并且能够在测试的同时分析问题原因和定位故障点。 整套Web性能测试和分析工具包含两个相对独立的子系统:Web性能测试子系统Web 性能分析子系统。其中Web性能测试子系统包含3个模块:TestView Manager、WebFT以及WebLoad。Web性能分析子系统只有WebLoad Analyzer。 左图表达了在一个完整的测试系统中,TestView Manager用来定制、管理各种测试活动;WebLoad模拟多个用户行为进行测试,所测试的是系统性能,容量,稳定性和抗攻击性;

软件测试基本流程与要求要求规范

软件测试基本流程与规范 1目标 制定完整且具体的测试路线和流程,为快速、高效和高质量的软件测试提供基础流程框架。 最终目标是实现软件测试规范化,标准化。 2测试流程说明

3测试需求分析 测试需求是整个测试过程的基础;确定测试对象以及测试工作的范围和作用。用来确定整个测试工作(如安排时间表、测试设计等)并作为测试覆盖的基础。而且被确定的测试需求项必须是可核实的。即,它们必须有一个可观察、可评测的结果。无法核实的需求不是测试需求。所以我现在的理解是测试需求是一个比较大的概念,它是在整个测试计划文档中体现出来的,不是类似的一个用例或者其他. ·测试需求是制订测试计划的基本依据,确定了测试需求能够为测试计划提供客观依据; ·测试需求是设计测试用例的指导,确定了要测什么、测哪些方面后才能有针对性的设计测试用例; ·测试需求是计算测试覆盖的分母,没有测试需求就无法有效地进行测试覆盖; 3.1测试方法与规范 3.1.1测试方法 随着软件技术发展,项目类型越来越多样化。根据项目类型应选用针对性强的测试方法,合适的测试方法可以让我们事半功倍。以下是针对目前项目工程可以参考的测试方法: ?β测试(beta测试)--非程序员、测试人员 β测试,英文是Beta testing。又称Beta测试,用户验收测试(UAT)。 β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场,Beta测试不能由程序员或测试员完成。 当开发和测试根本完成时所做的测试,而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员完成,不能由程序员或测试员完成。?α测试(Alpha测试)--非程序员、测试人员 α测试,英文是Alpha testing。又称Alpha测试. Alpha测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的受控测试,Alpha测试不能由该系统的程序员或测试员完成。 在系统开发接近完成时对应用系统的测试;测试后,仍然会有少量的设计变更。这种测试一般由最终用户或其他人员来完成,不能由程序员或测试员完成。?兼容性测试 --测试人员 兼容性测试是指测试软件是否可以成功移植到指定的硬件或者软件环境中,例如在B/S项目中各个不同浏览器之间的测试。 ?用户界面测试-UI测试--测试人员 用户界面测试,英文是User interface testing。又称UI测试。 用户界面,英文是User interface。是指软件中的可见外观及其底层与用户交互的部分(菜单、对话框、窗口和其它控件)。

软件测试工作流程(个人版)

软件测试流程 测试基本阶段划分 ?测试计划阶段 ?测试设计阶段 ?测试执行阶段 ?测试评估阶段 ?测试验收阶段 文档编写人:龙文 编写时间:2010-8-3

目录 1、测试计划阶段 (3) 1.1、测试计划考虑的问题 (3) 1.2、测试策略 (4) 1.3功能列表 (4) 1.3.1、其他非功能测试 (6) 1.3.2、策略附件要求 (6) 2、测试设计阶段 (8) 3、测试执行阶段 (8) 3.1、执行阶段操作 (9) 4、测试评估阶段 (9) 5、测试验收阶段 (10)

1、测试计划阶段 ?做测试需要做好准备工作,把做一件事需要做的准备工作做好,明确做这件事的目的,最终达成目的并验证结果是我们要做的事情。这要求我们有一个完善的“测试计划书”。 ?测试计划的内容: 1、测试范围:描述本次测试中做的测试范围,如:测试软件功能范围、测试种类等 2、简单的描述如何搭建测试平台以及测试的潜在的风险。 3、项目信息:说明要测试的项目的相关资料,如:输入输出文档,产品描述,软件主要功能 4、人力资源的分配 注: 计划和设计分开编写,最好安排充分的时间去明确测试需求 测试需求:笼统说,就是测试中的所有设计和需求文档。作为本次测试的依据 1.1、测试计划考虑的问题 ?1、要充分考虑测试计划的实用性,即测试计划与实际之间的接近程度和可操作性(必须对需求有透彻的理解)。编写测试计划的目的在于充分考虑执行测试时的各种资源,包括测试内容、测试标准、时间资源、人力资源等等,准确地说是要分析执行时所能够调用的一切资源以及受各种条件限制,可能受到的各种影响。说的再明确一点就是要“计划”“如何”去做“测试工作”,而不是“如何编写测试计划”。 (1)测试内容:对一个软件来说测试计划中会明确本次测试做哪些测试? 如:系统测试:在整个系统测试中会有(界面测试、功能测试、性能测试、兼 容性测试、安装卸载测试、可靠性测试等测试) (2)测试目的:一般多为保证产品质量是否达到预期的指标。这个指标也就是在 测试中定义的结束标准。 (3)测试标准:需要考虑本次测试需要输入那些文档,该项目结束标准定义、测试结束标准的定义?bug级别定义、优先级定义、bug管理流程定义。这个都需要在执行测试事明确。计划中应该包含这些内容。 (4)资源分配:这里分为人力资源、软硬件资源等划分。一般会把人力资源的利用写入一个测试人员任务分配表里,按照不同的阶段,每个阶段提交相应的成果(难度很大)。软硬件资源中主要是在做计划时考虑到需要多少电脑或别的工具,列出清单。 (5)测试风险:大多考虑到的就是项目开发延期、测试人员不足用例无法全面覆盖测试点、时间不足用例无法全部执行、bug无法及时修改导致无法验证、测试人员技能不足导致测试进度拉长。 (6)软件测试策略一般都是分开来做相关测试方案。 ?2、要坚持“5W1H”的原则,明确测试内容与过程。 ◇明确测试的范围和内容(WHA T); ◇明确测试的目的(WHY); ◇明确测试的开始和结束日期(WHEN);

软件测试过程管理-考题

软件测试过程管理-考题-标准化文件发布号:(9456-EUATWK-MWUB-WUNN-INNUL-DDQTY-KII

一、软件测试过程管理 1. 关于软件测试模型,描述正确的是(C) A. V模型测试的对象就是程序本身,测试与开发可以同一阶段进行 B. W模型测试的对象是程序,需求、设计等,可以支持迭代的开发模型 C. H模型软件测试过程活动完全独立,贯穿产品整个生命周期,与其他流程并发地进行。 D. X模型是事先计划再进行测试。 2. 制定测试计划的步骤:(D) A. 确定项目管理机制预计测试工作量测试计划评审 B. 确定测试范围确定测试策略确定测试标准、预计测试工作量 C. 确定测试构架确定项目管理机制预计测试工作量测试计划评审 D. 确定测试范围确定测试策略确定测试标准确定测试构架确定项目管理机制预计测试工作量测试计划评审 3、编写测试计划的目的是:(ABC)(多选) A、使测试工作顺利进行 B、使项目参与人员沟通更舒畅 C、使测试工作更加系统化 D、软件工程以及软件过程的需要 E、软件过程规范化的要求 F、控制软件质量 4、某公司采用的软件开发过程通过了CMM2认证,表明该公司(C)。 A. 开发项目成效不稳定,管理混乱 B. 对软件过程和产品质量建立了定量的质量目标 C. 建立了基本的项目级管理制度和规程,可对项目的成本、进度进行跟踪和控制 D. 可集中精力采用新技术新方法,优化软件过程 5. (B )可以作为软件测试结束的标志。 A.使用了特定的测试用例B.错误强度曲线下降到预定的水平C.查出了预定数目的错误D.按照测试计划中所规定的时间进行了测试 6.软件测试计划的内容应包括(D)。 A. 测试目的、背景 B. 被测软件的功能、输入和输出 C. 测试内容和评价标准 D. 以上全部 7.下面不属于软件测试过程中的输入类的是(B)。 A. 软件配置 B. 测试用例 C. 测试配置 D. 测试工具 8. 下列不属于测试需求分析阶段的输入的是(A)。 A. 软件测试的方法与规范 B. 软件需求规格说明 C. 软件测试计划 D.软件设计说明

软件测试环境管理规范

测试环境管理规范

修改履历 修改编号版本修改条款及内容修改日期 1 V1.0 初稿

目录 1.概述 (5) 1.1目的 (5) 1.2适用范围 (5) 2.环境使用要求和原则 (5) 2.1环境使用要求 (5) 2.2环境使用原则 (5) 3.硬件环境 (6) 3.1全流程测试环境申请 (6) 3.1.1申请流程图 (6) 3.1.2申请流程说明: (6) 3.2待测系统环境申请 (7) 3.2.1申请流程图 (7) 3.2.2申请流程说明: (7) 3.3测试用机申请 (8) 3.3.1申请流程图 (8) 3.3.2申请流程说明: (8) 3.4硬件环境变更 (9) 3.4.1全流程测试环境变更流程图 (9) 3.4.2全流程测试环境变更流程说明: (9) 3.5硬件环境释放 (10) 3.5.1释放流程图 (10) 3.5.2释放流程说明 (10) 4.环境权限 (11) 4.1权限说明 (11) 4.1.1查询帐户 (11) 4.1.2监控帐户 (11) 4.1.3应用帐户 (11) 4.1.4备用帐户 (11) 4.1.5特殊帐户 (11) 4.2权限申请流程 (11) 4.2.1查询帐户申请流程 (11) 4.2.2监控帐户申请流程 (11)

4.2.3应用帐户申请流程 (12) 4.2.4备用帐户申请流程 (12) 4.2.5特殊帐户申请流程 (12) 4.3应用系统 (12) 4.3.1应用版本变更 (12) 应用版本部署 (12) 应用版本变更 (12) 4.3.2测试数据 (12) 测试数据预埋 (13) 测试数据变更 (13) 5.系统参数变更 (13) 5.1工作时段参数变更 (14) 5.1.1变更流程图: (14) 5.1.2变更流程说明: (14) 5.2非工作时段参数变更 (15) 5.2.1变更流程图: (15) 5.2.2变更流程说明 (15) 6.系统备份 (16) 6.1不定期备份 (16) 6.1.1备份说明 (16) 6.1.2备份流程 (16) 6.2特需备份 (16) 6.2.1备份说明 (16) 6.2.2备份流程 (16)

软件测试过程和管理(二)

[模拟] 软件测试过程和管理(二) 选择题 第1题: 下列哪个不是测试环境的组成要素______。 A.软、硬件 B.技术文档 C.测试工具 D.网络环境 参考答案:B 第2题: 以下活动中,不属于测试计划的内容是______。 A.为测试各项活动制定一个实现可行的综合的计划 B.确定测试过程中每个测试阶段的测试完成标准 C.识别测试活动中各种风险,并给出风险应对措施 D.分析测试需求,并制定测试方案 参考答案:D 第3题: 下列有关测试过程抽象模型的描述中正确的是______。 A.V模型指出,软件测试要尽早准备,尽早执行,只要某个测试达到了准备就绪点,测试执行活动就可开展 B.W模型强调,测试伴随着整个软件开发周期同步进行,而且测试的对象不仅仅是程序,需求、设计也同样需要测试 C.H模型指出,单元测试和集成测试应检测程序的执行是否满足软件设计的要求 D.X模型提出针对完整的程序进行集成的编码和测试 参考答案:B 第4题: 下列哪个选项不属于测试计划要达到的目标______。 A.为测试各项活动制定一个现实可行的、综合的计划,包括每项测试活动的

对象、范围、方法、进度和预期结果 B.为项目实施建立一个组织模型,并定义测试项目中每个角色的责任和工作内容 C.为测试执行活动设计测试方案,编制测试用例 D.确定测试需要的时间和资源,以保证其可获得性和有效性 参考答案:C 第5题: 下列有关软件测试设计的说法中,正确的是______。 A.测试方案应考虑是否可行、是否有效和是否能够达到预期的测试目标 B.基于判定表的测试用例设计方法是白盒测试用例设计方法 C.测试方案设计中可以忽略软件系统的实际使用环境 D.测试开发不是测试用例设计的工作内容 参考答案:A 第6题: 下列有关测试项目结束与定稿测试报告的说法中,正确的是______。 A.测试执行完成,测试人员向测试负责人提交测试报告后,测试项目就可以结束了 B.对当前软件产品存在的缺陷进行逐个分析,认定剩余缺陷对产品质量无重大影响后,即可定稿测试报告 C.审查测试全过程,检查测试计划和内容无遗漏后,即可定稿测试报告 D.当所有测试计划内容完成,测试覆盖率达到要求及产品质量达到定义的标准,即可定稿测试报告 参考答案:D 第7题: 下列哪项工作与软件缺陷管理和追踪无关______。 A.对缺陷应该包含的信息条目、状态分类等进行完善设计 B.通过软件系统自动发送通知给相关开发和测试人员,使缺陷得到及时处理 C.对测试用例的执行结果进行记录和追踪 D.通过一些历史曲线和统计曲线来分析和预测未来的缺陷发展情况 参考答案:C

测试管理工具大全

测试管理工具大全 测试管理工具大全软件测试类工具现列举如下,并非百分百全面,仅供测试同行参考: 测试管理工具 厂商工具名称 * HP Quality Center (TestDirector) 备注:Mercury公司原主打产品TestDirector于2003年开始迁移到J2EE 平台,重构了整个软件的开发,因融入了Mercury BTO理念,继而重新命名为Quality Center,它是Mercury BAC平台的重要组成部分。2006年后是HP Quality Center。时至今日,仍然为业内最强大、使用最广泛的测试管理工具之一,可与QTP、Winrunner、Loadrunner等集成,也与MS Office、IBM Rational等产品集成。 * IBM Rational TestManager 备注:原Rational产品中专业对软件测试资源进行管理的强大工具。包括测试用例管理、测试执行管理、测试脚本和报告管理等。另外可与Robot结合做性能测试,更可以和RFT、RFP、CC、CQ等集成使用。 * IBM Rational Quality Manager 备注:IBM2008年推出的新产品,是完全可以与HP Quality Center媲美的软件测试管理工具。包括测试计划、工作流、任务跟踪和统计分析等功能。 * Micro Focus QADirector 备注:原Compuware公司产品,是业内强大的软件测试资源和过程管理工具,虽然市场不大,但是可以和IBM Rational TestManager比较,与原Compuware 产品集成紧密。 * Micro Focus SilkCentral Test Manager 备注:原Segue产品,被Borland收购后又被Micro Focus收购。是业内强大的软件测试资源和过程管理工具,可以和IBM Rational TestManager比较,与原Segue产品集成紧密。 * Parasoft ConcerTo

推荐几款好用的软件测试工具

推荐几款好用的软件测试工具 和其他的行业一样,学习软件测试首先要了解行业知识和软件测试的基础知识,练好扎实的基本功。其次要熟悉各种技术技能和工具使用,在工作上不断积累自己的经验和技术优势。 目前热门的软件测试技术方向主要分为:自动化测试、性能测试、黑盒测试、白盒测试、安全测试等。一名优秀的软件测试工程师也需要掌握至少一门编程语言,主要方向是Python,Java,C语言等,还有一些前端的脚本语等。数据库,热门的有Mysql、Oracle等,一般至少要掌握基础的增删该查SQL语句。操作系统windows、linux以及相关系统命令。网络协议,如TCP/IP等。 软件测试工具推荐 很多初学者对软件测试工具不是很了解,测试人员通过工具能够使软件的一些简单问题直观的显示在读者的面前,这样能使测试人员更好的找出软件错误的所在。软件测试工具分为自动化软件测试工具和测试管理工具。提高测试效率主要是靠软件测试工具来完成的,用

软件来代替一些人工输入。一个好的软件测试工具和测试管理工具结合起来使用将会使软件测试效率大大的提高。 如今国际上主流软件测试工具: Segue测试工具,Mercury测试工具,Rational测试工具,qtp自动化测试工具和AutoRunner工具,占有市场90%以上。 国内免费软件测试工具有:AutoRunner和TestCenter。 开源测试管理工具:TestLink、Bugfree、Bugzilla、mantis zentaopms 开源功能自动化测试工具:Watir、MaxQ、Selenium、WebInject LoadRunner:预测系统行为和性能的负载测试工具。 QuickTest Professional:用于创建功能和回归测试。 禅道测试管理工具:功能比较全面的测试管理工具,功能涵盖软件研发的全部生命周期,为软件测试和产品研发提供一体化的解决方案。是一款优秀的国产开源测试管理工具。

软件测试基础习题及答案范文

1、软件测试的定义? 软件测试是一个过程或者一系列过程,用来确认计算和代码完成了其应该完成的功能,并且不执行其不应该有的操作。 2、软件测试的目标是什么? 是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷,通过修正各种错误和缺陷提高软件质量,降低软件发布后由于潜在的软件错误和缺陷造成的隐患所带来的商业风险。 3、简单描述一下软件测试的原则? 所有的软件测试都应追溯到用户需求 应当把“尽早地和不断地进行软件测试”作为测试者的座右铭 Good Enough原则 质量第一 充分注意测试中的群集现象 程序员应避免检查自己的程序 有据可依 尽量避免软件测试的随意性,要有预期结果 重视回归测试 妥善保存一切测试过程文档 4、软件测试中验证和确认的区别? Verfication 验证: 是保证软件正确实现特定功能的一系列活动和过程。 目的是保证软件生命周期中的每一个阶段的成果满足上一个阶段设定的目标。 Validation 确认: 是保证软件满足用户需求的一系列的活动和过程。 目的是在软件开发后保证与用户需求符合 5、软件测试按照测试的基本策略可分为哪两种并加以详细说明? 白盒测试: 白盒测试也称结构测试或逻辑驱动测试,是指基于一个应用代码的内部逻辑知识,即基于覆盖全部代码、分支、路径、条件的测试,它是知道产品内部工作过程,可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行,按照程序内部的结构测试程序,检验程序中的每条通路是否都有能按预定要求正确工作,而不顾它的功能,白盒测试的主要方法有逻辑驱动、基路测试等,主要用于软件验证。

黑盒测试: 黑盒测试是指不基于内部设计和代码的任何知识,而基于需求和功能性的测试,黑盒测试也称功能测试或数据驱动测试,它是在已知产品所应具有的功能,通过测试来检测每个功能是否都能正常使用,在测试时,把程序看作一个不能打开的黑盆子,在完全不考虑程序内部结构和内部特性的情况下,测试者在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数锯而产生正确的输出信息,并且保持外部信息(如数据库或文件)的完整性。黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等,主要用于软件确认测试。 6、整个软件生命周期中,需要进行哪几项测试? 单元测试、集成测试、系统测试、验收测试 单元测试 单元测试是对软件中的基本组成单位进行的测试,如一个模块、一个过程等等。它是软件动态测试的最基本的部分,也是最重要的部分之一,其目的是检验软件基本组成单位的正确性。因为单元测试需要知道内部程序设计和编码的细节知识,一般应由程序员而非测试员来完成,往往需要开发测试驱动模块和桩模块来辅助完成单元测试。因此应用系统有一个设计很好的体系结构就显得尤为重要。 一个软件单元的正确性是相对于该单元的规约而言的。因此,单元测试以被测试单位的规约为基准。单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。 集成测试 集成测试是在软件系统集成过程中所进行的测试,其主要目的是检查软件单位之间的接口是否正确。它根据集成测试计划,一边将模块或其他软件单位组合成越来越大的系统,一边运行该系统,以分析所组成的系统是否正确,各组成部分是否合拍。集成测试的策略主要有自顶向下和自底向上两种。 系统测试 系统测试是对已经集成好的软件系统进行彻底的测试,以验证软件系统的正确性和性能等满足其规约所指定的要求,检查软件的行为和输出是否正确并非一项简单的任务,它被称为测试的“先知者问题”。因此,系统测试应该按照测试计划进行,其输入、输出和其他动态运行行为应该与软件规约进行对比。软件系统测试方法很多,主要有功能测试、性能测试、随机测试等等。 验收测试 验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。所不同的是,验收测试常常有软件系统的购买者代表在现场,甚至是在软件安装使用的现场。这是软件在投入使用之前的最后测试。

相关文档
最新文档