黑盒测试的测试流程简单介绍

第一篇：黑盒测试的测试流程简单介绍

黑盒测试的测试流程简单介绍

话说我们一直在做黑盒自动化测试，那我们究竟处于测试中的哪个位置呢？

其实我们更多的是在执行测试提交报告和发现的软件Error，测试用例是如何设计的，为什么要这样设计又有多少人想过呢？黑盒测试中的测试用例设计的简单方法又有多少了解呢？我们常做的测试中哪些地方用到了例如等价类划分法？

下面仅仅对黑盒测试的简单的测试流程进行下说明关于黑盒测试的其他内容会在以后的帖子中说明。

首先来了解两个名词：

Statement of Work（SOW）软件使用说明书

Software Requirement Specification(SRS)软件需求规格说明书

1.需求分析阶段：对业务的学习，分析需求点。

2.测试计划阶段：测试组长就要根据SOW开始编写《测试计划》，其中包括人员，软件硬件资源，测试点，集成顺序，进度安排和风险识别等内容。

3.测试设计阶段：测试方案一般由对需求很熟的高资深的测试工程师设计，测试方案要求根据《SRS》上的每个需求点设计出包括需求点简介，测试思路和详细测试方法三部分的方案。《测试方案》编写完成后也需要进行评审。

4.测试方案阶段：主要是对测试用例和规程的设计。测试用例是根据《测试方案》来编写的，通过《测试方案》阶段，测试人员对整个系统需求有了详细的理解。这时开始编写用例才能保证用例的可执行和对需求的覆盖。测试用例需要包括测试项，用例级别，预置条件，操作步骤和预期结果。其中操作步骤和预期结果需要编写详细和明确。测试用例应该覆盖测试方案，而测试方案又覆盖了测试需求点，这样才能保证客户需求不遗漏。同样，测试用例也需要评审。

5.测试执行阶段：执行测试用例，及时提交Error和测试报告等相关文档。

第二篇：黑盒测试心得

“黑盒”测“外”不测“内”

“黑盒”测的是功能

黑盒测试也称功能测试或数据驱动测试。它在已知产品应具有的功能的条件下，通过测试来检测每个功能是否都能正常使用。在测试时，把程序看作一个不能打 开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否 能适当地接收输入数据而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。

“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使 用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。

“黑盒”的两种基本方法

黑盒测试有两种基本方法，即通过测试和失败测试。

在进行通过测试时，实际上是确认软件能做什么，而不会去考验其能力如何。软件测试员只运用最简单，最直观的测试案例。

在设计和执行测试案例时，总是先要进行通过测试。在进行破坏性试验之前，看一看软件基本功能是否能够实现。这一点很重要，否则在正常使用软件时就会奇怪地发现，为什么会有那么多的软件缺陷出现？

在确信了软件正确运行之后，就可以采取各种手段通过搞“垮”软件来找出缺陷。纯粹为了破坏软件而设计和执行的测试案例，被称为失败测试或迫使出错测试。

黑盒测试的设计方法

黑盒测试是以用户的观点，从输入数据与输出数据的对应关系出发进行测试的，它不涉及到程序的内部结构。很明显，如果外部特性本身有问题或规格说明的规 定有误，用黑盒测试方法是发现不了的。黑盒测试法注重于测试软件的功能需求，主要试图发现几类错误：功能不对或遗漏、界面错误、数据结构或外部数据库访问 错误、性能错误、初始化和终止错误。

具体的黑盒测试方法包括等价类划分、因果图、正交实验设计法、边值分析、判定表驱动法、功能测试等。在使用时，自然要针对开发项目的特点对方法加以适当的选择。

◆ 等价类划分

等价类划分是一种典型的黑盒测试方法，用这一方法设计测试用例可以不用考虑程序的内部结构，只以对程序的要求和说明，即需求规格说明书为依据，仔细分析和推敲说明书的各项需求，特别是功能需求，把说明中对输入的要求和输出的要求区别开来并加以分解。

由于穷举测试的数量太大，以致于无法实际完成，促使我们在大量的可能数据中选取其中的一部分作为测试用例。例如，在不了解等价分配技术的前提下，测试 了1+1、1+2、1+3和1+4之后，还有必要测试1+5和1+6吗?能否放心地认为它们正确吗?那么1+999…（可以

输入的最大数值）呢？这个测试 用例是否与其他用例不同？是否属于另外一种类别？另外一个等价区间？这是软件测试员必须考虑到的问题。

等价类别或者等价区间是指测试相同目标或者暴露相同软件缺陷的一组测试案例。1+999…和1+13有什么区别呢？至于1+13，就像一个普通的加法，与1+5或者1+392没有什么两样，而1+999…则属于邻界的极端情况。假 如输入最大允许数值，然后加1，就会出现问题——也许就是软件的缺陷。这个极端案例属于一个单独的区间，与常规数字的普通区间不同。

等价类划分的办法是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据当作测试用例。每一类的代表性数据在测试中的作用等价于这一类 中的其他值，也就是说，如果某一类中的一个例子发现了错误，这一等价类中的其他例子也能出现同样的错误。使用这一方法设计测试用例，首先必须在分析需求规 格说明的基础上划分等价类，列出等价类表。

在考虑等价类划分时，先从程序的功能说明中找出每个输入条件，然后为每个输入条件划分两个或更多个等价类。等价类可分两种情况：有效等价类和无效等价 类。有效等价类是指对程序的规格说明是有意义的、合理的输人数据所构成的集合；无效等价类是指对程序的规格说明是不合理的或无意义的输人数据所构成的集 合。

◆ 边界值分析

软件测试常用的一个方法是把测试工作按同样的形式划分。对数据进行软件测试，就是检查用户输入的信息、返回结果以及中间计算结果是否正确。

即使是最简单的程序，要处理的数据也可能数量极大。还记得在计算器上简单加法的全部可能性吗？再想一想字处理程序、导航系统和证券交易程序。使这些数 据得以测试的技巧（如果称得上的话）是，根据下列主要原则进行等价分配，以合理的方式减少测试案列：边界条件、次边界条件、空值和无效数据。

边界值分析（Boundary Value Analysis，BVA）是一种补充等价划分的测试用例设计技术，它不是选择等价类的任意元素，而是选择等价类边界的测试用例。实践证明，在设计测试用 例时，对边界附近的处理必须给予足够的重视，为检验边界附近的处理专门设计测试用例，常常可以取得良好的测试效果。BVA不仅重视输人条件边界，而且也从 输出域导出测试用例。

第三篇：黑盒测试技术实验报告

黑盒测试技术 — 三角形问题 实验报告 一、问题描述 输入三个整数 a、b、c，分别作为三角形的三条边，通过程序判断这三条边是否能构成三角形？如果能构成三角形，则判断三角形的类型并输出（等边三角形、等腰三角形、一般三角形），如果不构成三角形输出不能构成三角形。

要求:(1)输入三个整数 a、b、c，必须满足以下条件：1≤a≤200；1≤b≤200；1≤c≤200。

(2)容错处理：输入空值的提示；输入的值满足类型的提示；(3)不限制开发环境，不限制开发语言；(4)尽可能不对自己的程序进行测试设计。

(5)请分别采用边界值分析法、等价类分析法、决策表分析法、基于场景分析法设计测试用例；(6)正文格式（除源代码用小五号单倍行距），其他行距固定值 20，字号小四。

二、程序主要源代码 (标注：测试的源代码是哪位同学（学号姓名）编写的。)

三、程序界面（截图）

四、设计测试用例

1.用边界值测试方法设计测试用例

用边界值分析法设计测试用例，按照下列步骤进行：

（（1）

分析各变量取值 三角形三条边的取值范围都是 1-200，所以边长 A 的边界点为 1 和 200，边长 B的边界点为 1 和 200，边长 C 的边界点为 1 和 200。

（（2）

测试用例数 输入条件 边界值 测试数据 A 1,200 0,1,2,199,200,201 B 1,200 0,1,2,199,200,201 C 1,200 0,1,2,199,200,201

设计测试用例（给出所有测试用例）

三角形问题的测试用例 测试用例 编号 输入数据 预期输出 测试结果 a b c 1 0 100 100 边长 A 不合法

边长 A 不合法1 100 100 等腰三角形 等腰三角形 3 2 100 100 等腰三角形 等腰三角形 4 199 100 100 等腰三角形 等腰三角形 5 200 100 100 不是三角形 不是三角形 6 201 100 100 边长 A 不合法

边长 A 不合法100 0 100 边长 B 不合法

边长 B 不合法100 1 100 等腰三角形 等腰三角形 9 100 2 100 等腰三角形 等腰三角形 10 100 199 100 等腰三角形 等腰三角形 11 100 200 100 不是三角形 不是三角形 12 100 201 100 边长 B 不合法

边长 B 不合法100 100 0 边长 C 不合法

边长 C 不合法100 100 1 等腰三角形 等腰三角形 15 100 100 2 等腰三角形 等腰三角形 16 100 100 199 等腰三角形 等腰三角形 17 100 100 200 不是三角形 不是三角形 18 100 100 201 边长 C 不合法

边长 C 不合法

2.用等价类测试方法设计测试用例

（（1）首先分析题目中给出的条件和隐含的输入要求，输入条件如下：

条件：1<=边长 A<=200,1<=边长 B<=200,1<=边长 C<=200

隐含条件:A

输入条件 有效等价类 无效等价类 是否是三角形 1.1<=A<=200 2.1<=B<=200 3.1<=C<=200 4.A200 8.B<1 || B>200 9.C<1 || C>200 10.A>=B+C 11.B>=A+C 12.C>=A+B 等腰三角形 13.A=B&&B!=C 14.A=C&&C!=B 15.B=C&&C!=A 16.A!=B&&A!=C&&B!=C 等边三角形 17.A=B=C 18.A!=B 19.A!=C 20.B!=C

(3)设计测试用例，覆盖上表中的等价类，如表 1-3 表所示。（至少 20 条）

表 表 1-3 三角形问题的测试用例 测试用例 编号 输入数据 预期输出 覆盖等价类 测试结果 a b c 1 100 100 100 等边三角形 1,2,3,4,5,6,17 等边三角形 2 50 50 50 等边三角形 1,2,3,4,5,6,17 等边三角形 3 150 150 150 等边三角形 1,2,3,4,5,6,17 等边三角形 4 50 100 100 等腰三角形 1,2,3,4,5,6,15 等腰三角形 5 100 50 100 等腰三角形 1,2,3,4,5,6,14 等腰三角形 6 100 100 50 等腰三角形 1,2,3,4,5,6,13 等腰三角形 0 2 3 边长 A 不合法 7 边长 A 不合法 8 2 1 3 不是三角形 12 不是三角形 9 3 0 1 边长 B 不合法 8 边长 B 不合法 10 3 1 2 不是三角形 10 不是三角形 11 1 3 0 边长 C 不合法 9 边长 C 不合法 12 2 3 1 不是三角形 11 不是三角形 13 50 51 52 不是等腰三角形

1,2,3,4,5,6,16 一般三角形 14 51 52 50 不是等腰三角形

1,2,3,4,5,6,16 一般三角形 15 52 50 51 不是等腰三角形

1,2,3,4,5,6,16 一般三角形 16 100 100 101 不是等边三角形

1,2,3,4,5,6,19,20 等腰三角形 17 100 101 100 不是等边三角形

1,2,3,4,5,6,18,20 等腰三角形 18 101 100 100 不是等边三角形

1,2,3,4,5,6,18,19 等腰三角形 19 50 50 51 不是等边三角形

1,2,3,4,5,6,19,20 等腰三角形 20 50 51 50 不是等边三角形

1,2,3,4,5,6,18,20 等腰三角形 21 51 50 50 不是等边三角形

1,2,3,4,5,6,18,19 等腰三角形

3.用决策表测试方法设计测试用例

（（1）构建决策表

（（2）化简 测试用例 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 输入条件 是三角形 Y Y Y Y Y Y Y Y N N N N N N N N A=B Y Y N Y N Y N N N Y Y Y N N Y N A=C Y N Y Y Y N N N N Y Y N Y N N Y B=C Y Y Y N N N Y N N Y N Y Y Y N N 预期输出 不是三角形

等腰三角形

等边三角形

一般三角形

出错提示

测试用例 1 2,3,4 5,6,7 8 9-16 输入条件 是三角形

A=B

A=C

B=C

预期输出 不是三角形

Y 等腰三角形

Y

等边三角形

Y

一般三角形

Y

出错提示

Y

（（3）化简后的测试用例设计 测试用例 编号 输入数据 预期输出 覆盖等价类 测试结果 a b c 1 50 50 50 等边三角形 1,2,3,4,5,6,17 等边三角形 2 50 50 51 等腰三角形 1,2,3,4,5,6,13 等腰三角形 3 51 50 50 等腰三角形 1,2,3,4,5,6,15 等腰三角形 4 50 51 50 等腰三角形 1,2,3,4,5,6,14 等腰三角形 5 1 2 3 不是三角形 12 不是三角形 6 1 3 2 不是三角形 11 不是三角形 7 3 2 1 不是三角形 10 不是三角形 8 2 3 4 一般三角形 1,2,3,4,5,6 一般三角形 9 3 2 4 一般三角形 1,2,3,4,5,6 一般三角形 10 4 3 2 一般三角形 1,2,3,4,5,6 一般三角形

4.基于场景的测试

（1 1）基本流和备选流图

（2 2）场景设计

场景 1 1 ：基本流

场景 2 2 ：基本流+ + 备选流 1 1

场景 3 3 ：基本流+ + 备选流 2 2

场景 4 4 ：基本流+ + 备选流 3 3

场景 5 5 ：基本流+ + 备选流 4 4

（3 3））

测试用例设计

开始输入 输入 A,B,C 判断各边边长是否是在 1-200 A+B>C && A+C>B && B+C>A 备选流 1:边长不符合条件 备选流 2:不是三角形 是三角形 备选流 3:是等腰三角形 备选流 4:是等边三角形 一般三角形 结束

场景

A A

B B

C C

预期输出

测试结果1234

一般三角形

一般三角形2

0 0

0 0

0 0

边长错误

边长错误3247

不是三角形

不是三角形4

等腰三角形

等腰三角形5

等边三角形

等边三角形

5.测试结果分析与总结（至少 0 150 字，对测试过程中失败用例的原因进行分析，对学习了黑盒测试技术的学习总结）

在用等价类测试方法时，在测试无效等价类的结果和预期结果不一致，其原因是在设计程序时没有考虑无效等价类的这些测试用例的输出语句，黑盒测试技术是我们常使用的软件测试的方法，在测试中，我们需要将边界值测试，等价类测试，决策表测试，基于场景测试联合使用。任何一款软件都不可能做到完全测试，所以我们需要做的就是将黑盒测试中的方法尽可能结合使用，争取让软件少一些 bug。

第四篇：测试流程参考资料

工作两年了，我一直希望让自己每年对测试的理解更深入一层。工作一年的时候我写了《谈软件测试---一年工作总结》，谈轮了自己对各种测试的理解，这一年来，虽然对那些理概念的有所加强，自我感觉没有什么质的变化。前些天听我们公司的一位测试经理讲《敏捷测试》豁然开朗。他在学造飞机，而我一直在学造飞机里的一个发动机。我从来没想过，一个完整飞机的架构应该是怎样的。

如果想让测试在公司的项目中发挥出它最大的价值，并不是招两个测试技术高手，或引入几个测试技术，而是测试技术对项目流程的渗透，以及测试流程的改进与完善。虽然，当然测试行业前景乐观，许多中小企业也都在引入测试，但一百个公司就有一百种测试，每个公司对测试的看法不同，公司对测试的定位也不完全一样。本人前后经历两个公司，以自己的拙见浅谈一下对测试流程的看法。

这几天整理思路，回顾了前两份测试工作的流程与架构。

简陋的测试流程

先说笔者入职的第一个家公司，笔者是第一个入职的专职测试人员，相信一两个测试的公司还是不少的，入职后各种项目都在进行当中，上面给我的定位是并没完全融入到项目中去。而通过指派任务的方式。下面是简陋的流程图：

需求分析与架构设计：

我们做的是某一移动公司内部使用的项目，需求分析与架构全部由项目经理完成，之后由项目经理给具体某个开发人员分配任务，具体对某个功能模块的实现。这个对项目经理的经验与技术要求很高，他既然担任了需求分析师，又担任架构师的角色。程序员编码：

因为我们开发语言用的是JAVA 语言，IDE用myeclipse 中自带的CVS版本管理工具，开发人员完成代码后，提交到版本库中。测试：

笔者入职后的第一个任务是搭建缺陷管理工具，禅道项目管理，通过推广对发现的问题进行跟踪。后来正明效果并不好，因为对于一个六七人的开发团队项目，开发人员更喜欢测试人员能当面反馈，这样更能提高效率。对一个小bug 通过当面交流的方式就可以将问题修复。

对于当时的环境，并没有测试线。开发人员在本机上将项目进行部署运行。测试人员通过局域网访问开发人员的机子进行访问。或在测试人员本机上进行部署测试。这也是一个致命的缺点。因为开发人员测试人员使用的电脑存在太多不稳定性，这些都会造成问题的出现，有时候难以判定是系统问题还是环境问题。上线：

经过测试人员测试通过后，开发人员部署上线。A程序员流程

你会发现在流程图中，A程序员是先发上线之后，再进行测试。这是我们一个面向大众用户的网站，上面给于测试人员的定位是测试员兼用户体验员，测试员将发现的bug和体验问题提交到缺陷管理系统，由经理对问题进行分析，指派开发人员解决。定期对系统进行更新。

流程分析：

这个流程唯一的优点，就是能快速的发现并修复问题。

缺点就非常多了，相信许多小软件公司也有类似的流程。

这个流程中，项目经理是核心，项目经理也确实是有多年开发与项目经验的牛人，他喜欢不定期分享上些前沿的技术。我很崇拜他。

对于测试来说，需求很不明确，测试文档与用例也是可有可无的产物，没有需求文档，或非常简陋，根据需求文档根本无法编写用例。笔者只能收集一些通用的测试用例，如登录、文件上传下载、列表翻页、日期选择、输入框验证、搜索等有一些“通用型”用例，以便在测试过程中做参考。功能测试的多了，拿到一个功能，测试思路也就出来了。

规范的测试流程

放弃上份悠闲的工作，感谢那个带我入行公司，我想了解真正的测试在公作中如何进行的。所以，来到了现在这家公司。我很欣喜的是这测试有自己的团队，专业（对当时的我来说）的流程，以及与开发等同的地位。现在的测试流程：

需求分析：

需求分析由产品人员制定，他们要做的不是一份简单的文档，而是细化每一个功能的细节，每一个按钮的位置，对于稍大或复杂一点的需求都进行建模。需求评审：

这里会叫上所有参与项目人员进行，开发人员、测试人员、QA人员。测试人员提出需求，开发人员考虑功能实现的方案与可行性、当然开发负责也是要参与的。测试人员主要是对需求的理解提出疑问，以便才能根据需求写用例。QA人员是最终对软件质量进行验证的人，所以也需求了解需求 开发人员编写排期：

开发人员需求根据需求功能点进行排期。然后将开计划转交给测试人员。测试计划排期：

测试人员根据开发计划，对测试具体测试时间，也就是开发功能完成后的时间，进行几轮测试等。然后，把项目的开发与测试计划发送给各部门负责人及参与项目的所有人员。编写测试用例：

根据详细的需求分档，开始进行用例的编写。用例评审：

在用例进行评审之间，先以邮件形式将用例发送给相关人员，以便他们事先了解用例对哪些功能进行验证以及验证的细节。

然后，测试人员组进行用例评审，开发人员对用例与实际功能不符合有哪些，产品人员对会通过用例对功能的具体实现进行把握等等。提交基线：

开发人员完成所有功能后，会对自己的功能进行一个自测。自测完成后提交测试人员进行基线。

具体测试流程：

开发人员对于基到测试线的功能进行测式，发现的问题通过缺陷管理工具进行反馈，开发人员对问题进行修复，然后，准备第二轮基。

测试人员完成第一轮测试后，需要写测试结论，发到相关人员。然后对基线后的第二轮进行测试，第二轮会对第一轮中发现的问题进行重点回归。测试通过：

经过两到三轮或四轮的测试后，直到没发现新的问题，或暂时无法解决，或不紧急的问题。通过上级确认，可以通过。编写测试报告与验收方案。

验收方案是交由QA进行验证的。在现公司的流程中是将测试与QA分开的，测试人员重点关注的是功能是否可以正常运行。QA关注的是整个流程的质量以及最终用户的质量。有些公司QA与测试是不区分的，但这对测试的要求会更高，除了关心功能，还需要关心整体流程与质量。

流程分析：

对于刚接触这个流程的我来说，这个流程是规范的，测试真正融入了整个流程，而且还担任了很重的角色，从而也有效的保证了软件产品的整体质量。

那么这个流程是不是完美的呢？不，这个项目流程太强化各种文档。我们来看测试的工作内容，测试计划、测试用例、测试结论、测试报告、验收方案、问题的提交跟踪。其实，我们真用于测试的时间是非常少的，在一周的时间，也许只有一天或不到一天的时间是在进行测试的。测试人员只有在测试的时候才会体现出他的价值。而大部分工作却不能体现他的价值。

当然，我这里会省略与测试主流程无关的东西，真正的测试工作中琐事很多。

敏捷测试流程

下面来看敏捷测试，本人并没有接触过敏捷，对敏捷也没花时间学习与研究。唯一接触就是听我们测试经理对测度流程讲了两个半小时，听讲的人很多，我站着听的。受益匪浅，凭着记忆也简单谈谈。

前面讲的第一种流程，还是第二种流程都是瀑布式的，严格来说第一种简陋的都不能称为瀑布式，对于一个三个月的项目说，产品把需求分析完了给开发，然后产品就没事儿了；开发开发完成之后给测试，然后开发人员也不忙了。测试完成之后上线。那么在产品分析的阶段，开发和测试都是没事干的（这里只对单一项目）。开发阶段，产品和测试也基本没事儿。同样在测试阶段，产品与开发也是没什么事儿的。

敏捷测试的一个核心是迭代，在每个时间点上，所有项目人员都是有事可做的。

1、下面是我理解中的敏捷测试流程图：

第一阶段：

通过上面的流程图，对于一个月的需求分析，在敏捷中，可能三五天就确定下来。这个需求定得会很模糊，但整体框架确定。产品对其中某一模块功能确认，开发人员开始对确认的功能编码，开发人员编码的过程中，测试进行功能分解，因为根据模糊的需求很难写出具体的用例，所以，只能尽量对功能进行分析得细些，标注需要验证的内容。第二阶段：

开发完成后交给测试人员进行测试，开发人员继续开发新的功能。那么测试人员发现的问题怎么办呢？会从开发团队中抽出一个人员来用于解决测试发现的问题。但开发进度并没有因为测试而停止。

流程分析：

在这个流程中弱化了文档，强调了各个人员的沟通，通过这种迭代的方式，三个月的项目，可以能两个月和两个半月就会完成。

但这种流程并非完美，加入一个功能在需求分析阶段就是错误的，因为它是一个迭代渐进的过程。也只能一路错下去。

2、对测试问题的处理

上面的图更能清晰看出对问题的处理过程。

第一块面板中是开发人员未实现的功能，第二块面板中是开发完成功能，测试人员对其进行测试，发现不通过的就放回未开发的面板中，测试通过的将放到第三块面板中。

需要说明的是，敏捷测试在国外很流行，在内容，雷声大雨点小，推行的人很多，真正有公司引入的不多。我们所在公司千差万别，测试流程也可能有很大的不同。对于已经工作两年一个测试员来说，从来没关注过测试流程与结构应该是个悲剧。我希望不被思想局限，所以，努力冲破一个又一个的局限。

第五篇：测试流程及费用

测试流程及费用

一、测试流程

测试流程支撑系统供应商开始备案并通知测试单位测试机构信息化协会测试申请补充材料材料审核及环境准备准备就绪下一轮重新申请测试修改软件回归测试测试确认缺陷是否回归测试编制测试报告审核不通过提交测试报告审核审核通过向各委办局、区县推荐结束

第一步：申请单位对照《北京市电子政务IT运维服务支撑系统规范》决定本单位申请测试的软件测试项。

第二步：申请单位向北京信息化协会提交《北京市电子政务IT运维服务支撑系统测试申请表》，并在协会公布的测试机构中选择一家，同时准备测试相关材料。

第三步：信息化协会根据申请单位的申请决定是否受理，并通知测试机构。

第四步：测试机构在收到完整的申报材料后一个工作日内要与申请单位建立联系，接洽关于测试的相关事宜，开展测试的相关业务。

第五步：测试机构组织测试团队对申请单位提交的软件进行测试，软件缺陷由测试团队成员与申请单位代表共同签字确认。第六步：测试机构在测试结束后五个工作日内出具“测试报告”。

第七步：测试机构向北京信息化协会提交“测试报告”，协会根据“北京市电子政务IT运维服务支撑系统规范”对测试报告进行评估。

第八步：通过评估的支撑系统，由北京信息化协会向各委办局、区县推荐；未通过评估的支撑系统，由申请单位修改缺陷完善功能，并决定是否进行回归测试，或进入下一批申请。

二、费用

1.北京信息化协会建议测试费用不超过五万元。2.每次回归测试费用不超过原费用的60%。

三、需要向测试机构提供的相关文档

提交测试申请时申请单位应同时准备以下文档：

（一）《软件功能一致性声明》

申请单位声明待测的测试项。未声明的测试项不测试。软件功能一致性声明.xls模板如下：

（二）《软件使用说明书》

申请被测试软件的使用说明书或用户手册。

（三）《安装配置手册》

申请被测试软件的安装、配置手册。

（四）《测试用例》

建议申请单位提供内部测试使用的《测试用例》供测试机构参考。

（五）被测单位自行提供的其他特性化文档 其他有助于测试人员了解被测软件优点的资料。