测试流程和测试方案的区别

第一篇：测试流程和测试方案的区别

测试方案和测试计划的区别

一、测试计划：

对测试全过程的组织、资源、原则等进行规定和约束，并制订测试全过程各个阶段的任务以及时间进度安排，提出对各项任务的评估、风险分析和需求管理。

二、测试方案：

描述需要测试的特性、测试的方法、测试环境的规划、测试工具的设计和选择、测试用例的设计方法、测试代码的设计方案。

三、测试计划是组织管理层面的文件，从组织管理的角度对一次测试活动进行规划。

四、测试方案是技术层面的文档，从技术的角度度一次测试活动进行规划。

五、测试计划要明确的内容：

1、明确测试组织的组织形式

○1测试组织和其他部门关系，责任划分。

○2测试组织内的机构和责任安排。

2、明确测试的测试对象（明确测试项，用于后面划分任务,估计工作量等）

3、完成测试的需求跟踪

4、明确测试中需要遵守的原则

○1测试通过/失败标准

○2测试挂起和回复的必要条件

5、明确测试工作任务分配是测试计划的核心

○

1、进行测试任务划分

○

2、进行测试工作量估计

○

3、人员资源和物资源分配

○

4、明确任务的时间和进度安排

○

5、风险的估计和规避措施

○

6、明确测试结束后应交付的测试工作产品

六、测试方案的具体内容：

○

1、明确策略

○

2、细化测试特性（形成测试子项）

○

3、测试用例的规划

○

4、测试环境的规划

○

5、自动化测试框架的设计

○

6、测试工具的设计和选择

七、测试方案需要在测试计划的指导下进行，测试计划提出“做啥”，而测试方案明确“咋做”。

八、详见测试计划模板和测试方案模板

第二篇：测试方案和测试计划的区别

一、测试计划：

对测试全过程的组织、资源、原则等进行规定和约束，并制订测试全过程各个阶段的任务以及时间进度安排，提出对各项任务的评估、风险分析和需求管理。

二、测试方案：

描述需要测试的特性、测试的方法、测试环境的规划、测试工具的设计和选择、测试用例的设计方法、测试代码的设计方案。

三、测试计划是组织管理层面的文件，从组织管理的角度对一次测试活动进行规划。

四、测试方案是技术层面的文档，从技术的角度度一次测试活动进行规划。

五、测试计划要明确的内容：

1、明确测试组织的组织形式

1>测试组织和其他部门关系，责任划分。

2>测试组织内的机构和责任安排。

2、明确测试的测试对象（明确测试项，用于后面划分任务,估计工作量等）

3、完成测试的需求跟踪

4、明确测试中需要遵守的原则

1> 测试通过/失败标准

2> 测试挂起和回复的必要条件

5、明确测试工作任务分配是测试计划的核心

1>进行测试任务划分

2>进行测试工作量估计

3>人员资源和物资源分配

4>明确任务的时间和进度安排

5>风险的估计和规避措施

6>明确测试结束后应交付的测试工作产品

六、测试方案的具体内容：

1、明确策略

2、细化测试特性（形成测试子项）

3、测试用例的规划

4、测试环境的规划

5、自动化测试框架的设计

6、测试工具的设计和选择

七、测试方案需要在测试计划的指导下进行，测试计划提出“做啥”，而测试方案明确“咋做”。

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

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

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

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

简陋的测试流程

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

需求分析与架构设计：

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

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

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

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

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

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

流程分析：

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

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

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

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

规范的测试流程

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

需求分析：

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

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

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

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

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

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

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

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

具体测试流程：

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

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

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

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

流程分析：

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

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

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

敏捷测试流程

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

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

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

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

第一阶段：

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

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

流程分析：

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

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

2、对测试问题的处理

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

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

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

第四篇：测试流程及费用

测试流程及费用

一、测试流程

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

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

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

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

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

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

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

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

二、费用

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

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

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

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

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

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

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

（三）《安装配置手册》

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

（四）《测试用例》

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

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

第五篇：软件测试流程

每个软件测试阶段都要经历以下步骤：测试需求分析、测试过程设计、测试实现、测试实施、测试评价、测试维护。

1.测试需求分析：整个测试过程的基础；确定测试对象以及测试工作的范围和作用。

2.测试过程设计：包括测试计划,测试策略制定，测试时间安排用，测试用例编写等

3.测试实现：环境配置好了，新的版本也收到了，人员也都培训好了等等

4.测试实施：已经按照测试计划进行展开了，比如手工测试，自动化测试等

5.测试评价：对版本测试覆盖率，测试质量，人员测试工作以及前期的一些工作制定情况进行评价

6.测试维护：对测试用例库，测试脚本，bug库等进行维护，保证延续性等

软件测试过程

软件测试过程按各测试阶段的先后顺序可分为单元测试、集成测试、确认（有效性）测试、系统测试和验收（用户）测试5个阶段，如图3所示。

(1)单元测试：测试执行的开始阶段。测试对象是每个单元。测试目的是保证每个模块或组件能正常工作。单元测试主要采用白盒测试方法，检测程序的内部结构。

(2)集成测试：也称组装测试。在单元测试基础上，对已测试过的模块进行组装，进行集成测试。测试目的是检验与接口有关的模块之间的问题。集成测试主要采用黑盒测试方法。

(3)确认测试：也称有效性测试。在完成集成测试后，验证软件的功能和性能及其他特性是否符合用户要求。测试目的是保证系统能够按照用户预定的要求工作。确认测试通常采用黑盒测试方法。

(4)系统测试：在完成确认测试后，为了检验它能否与实际环境（如软硬件平台、数据和人员等）协调工作，还需要进行系统测试。可以说，系统测试之后，软件产品基本满足开发要求。

(5)验收测试：测试过程的最后一个阶段。验收测试主要突出用户的作用，同时软件开发人员也应该参与进去。