《大型软件测试过程与方法》由会员分享，可在线阅读，更多相关《大型软件测试过程与方法（28页珍藏版）》请在金锄头文库上搜索。
1、测 试 过 程张乐2005年5月20日主要内容测试过程测试过程测试类型测试类型相关文档相关文档软件测试对象根据软件定义，软件包括程序、数据和文档，所以软件测试并不根据软件定义，软件包括程序、数据和文档，所以软件测试并不仅仅是程序测试。仅仅是程序测试。软件测试不仅仅是软件开发的一个独立阶段，而应贯穿于整个软软件测试不仅仅是软件开发的一个独立阶段，而应贯穿于整个软件生命周期中。件生命周期中。在整个软件生命周期中，各阶段有不同的测试对象，形成了不同在整个软件生命周期中，各阶段有不同的测试对象，形成了不同开发阶段的不同类型的测试。需求分析、概要设计、详细设计以开发阶段的不同类型的测试。需求分析、概要设
2、计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应成为软件测试计规格说明、详细设计规格说明以及源程序，都应成为软件测试的对象。的对象。 软件测试对象在软件编码结束后，对编写的每一个程序模块进行测试，称为在软件编码结束后，对编写的每一个程序模块进行测试，称为“模块测试模块测试”或或“单元测试单元测试”；在模块集成后，对集成在一起的模块组件，有时也可称为在模块集成后，对集成在一起的模块组件，有时也可称为“部件部件”进行测试，称为进行测试，称为“集成测试集成测试”；在集成测试后，需
3、要检测与证实软件是否满足软件需求说明书中在集成测试后，需要检测与证实软件是否满足软件需求说明书中规定的要求，这就称为规定的要求，这就称为“确认测试确认测试”。将整个程序模块集成为软件系统安装在运行环境下，对于硬件、将整个程序模块集成为软件系统安装在运行环境下，对于硬件、网络、操作系统及支撑平台构成的整体系统进行测试，称为网络、操作系统及支撑平台构成的整体系统进行测试，称为“系系统测试统测试”。 软件测试对象由于软件分析、设计与开发各阶段是互相衔接的，前一阶段工作中由于软件分析、设计与开发各阶段是互相衔接的，前一阶段工作中发生的问题如未及时解决，很自然要影响到下一阶段。从源程序的发生的问题如未及
4、时解决，很自然要影响到下一阶段。从源程序的测试中找到的程序错误不一定都是程序编写过程中造成的。测试中找到的程序错误不一定都是程序编写过程中造成的。 为了把握各个环节的正确性，需要进行各种验证和确认工作。为了把握各个环节的正确性，需要进行各种验证和确认工作。u验证（验证（Verification）是保证软件正确实现特定功能的一系列活）是保证软件正确实现特定功能的一系列活动和过程，目的是保证软件生命周期中的每一个阶段的成果满动和过程，目的是保证软件生命周期中的每一个阶段的成果满足上一个阶段所设定的目标。足上一个阶段所设定的目标。u确认（确认（Validation）是保证软件满足用户需求的一系列的活
5、动和）是保证软件满足用户需求的一系列的活动和过程，目的是在软件开发完成后保证软件与用户需求相符合。过程，目的是在软件开发完成后保证软件与用户需求相符合。验证与确认都属于软件测试，它包括对软件分析、设计以及程序的验证与确认都属于软件测试，它包括对软件分析、设计以及程序的验证和确认。验证和确认。软件测试分类 按照全生命周期的软件测试概念，测试对象应该包括软件设计开按照全生命周期的软件测试概念，测试对象应该包括软件设计开发的各个阶段的内容，但这里重点讲述开发阶段的测试。发的各个阶段的内容，但这里重点讲述开发阶段的测试。 按照开发阶段划分：单元测试、集成测试、系统测试、确认测试。按照开发阶段划分：单元
6、测试、集成测试、系统测试、确认测试。按照测试实施组织划分：开发方测试、用户测试（按照测试实施组织划分：开发方测试、用户测试（测试）、第测试）、第三方测试。三方测试。按照测试技术划分：白盒测试、黑盒测试、灰盒测试。按照测试技术划分：白盒测试、黑盒测试、灰盒测试。软件测试技术的分类软件测试方法和技术的分类与软件开发过程相关联，它贯穿了整软件测试方法和技术的分类与软件开发过程相关联，它贯穿了整个软件生命周期。个软件生命周期。走读、单元测试、集成测试、系统测试用于整个开发过程中的不走读、单元测试、集成测试、系统测试用于整个开发过程中的不同阶段。同阶段。u开发文档和源程序可应用走查的方法；开发文档和源程
7、序可应用走查的方法；u单元测试可应用白盒测试方法；单元测试可应用白盒测试方法；u集成测试应用近似灰盒测试方法；集成测试应用近似灰盒测试方法；u系统测试和确认测试应用黑盒测试方法。系统测试和确认测试应用黑盒测试方法。软件测试过程模型 软件测试是与软件开发紧密相关的一系列有计划的系统性的活动，软件测试是与软件开发紧密相关的一系列有计划的系统性的活动，显然软件测试也需要测试模型去指导实践显然软件测试也需要测试模型去指导实践 。主要介绍两个模型主要介绍两个模型uV模型模型 uW模型模型 V模型V模型是最具有代表意义的测试模型模型是最具有代表意义的测试模型 。V模型是软件开发瀑布模型的变种，它反映了测试
8、活动与分析和模型是软件开发瀑布模型的变种，它反映了测试活动与分析和设计的关系设计的关系 。从左到右，描述了基本的开发过程和测试行为，非常明确地标明从左到右，描述了基本的开发过程和测试行为，非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系和开发过程期间各阶段的对应关系 。箭头代表了时间方向，左边下降的是开发过程各阶段，与此相对箭头代表了时间方向，左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即各测试过程的各个阶段。应的是右边上升的部分，即各测试过程的各个阶段。 V模型W模型V模
9、型存在一定的局限性，它仅仅把测试过程作为在需求分析、模型存在一定的局限性，它仅仅把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段。容易使人理解为测概要设计、详细设计及编码之后的一个阶段。容易使人理解为测试是软件开发的最后的一个阶段，主要是针对程序进行测试寻找试是软件开发的最后的一个阶段，主要是针对程序进行测试寻找错误，而需求分析阶段的隐藏的问题一直到后期的验收测试才被错误，而需求分析阶段的隐藏的问题一直到后期的验收测试才被发现。发现。在在V模型中增加软件各开发阶段应同步进行的测试，被演化为一模型中增加软件各开发阶段应同步进行的测试，被演化为一种种W模型。模型。开发是开发是“V”
10、，测试也是与此相重叠的，测试也是与此相重叠的“V”。W模型体现了模型体现了“尽早地和不断地进行软件测试尽早地和不断地进行软件测试”的原则。的原则。W模型W模型相比于相比于V模型，模型，W模型更科学。模型更科学。W模型可以说是前者自然而然的模型可以说是前者自然而然的发展，它强调：测试伴随着整个软件开发周期，而且测试的对象发展，它强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。不仅仅是程序，需求、功能和设计同样要测试。 测试与开发是同步进行的，从而有利于尽早地发现问题。以需求测试与开发是同步进行的，从而有利于尽早地发现问题。以需求为例，需求分析一完成，我们
11、就可以对需求进行测试，而不是等为例，需求分析一完成，我们就可以对需求进行测试，而不是等到最后才进行针对需求的验收测试。到最后才进行针对需求的验收测试。 测试不仅仅是评定软件的质量，测试还可以尽可能早地找出缺陷测试不仅仅是评定软件的质量，测试还可以尽可能早地找出缺陷所在，从而帮助改进项目内部的质量。所在，从而帮助改进项目内部的质量。 研究室测试过程岗位及职责岗位及职责u部门主管：负责审计测试报告，决定软件是否能够对外发布。部门主管：负责审计测试报告，决定软件是否能够对外发布。u项目组负责人：负责需求分解、讲解和澄清，评审测试方案和测试样例。项目组负责人：负责需求分解、讲解和澄清，评审测试方案和测
12、试样例。负责单元和集成测试并保证提交的产品质量达到系统测试的要求。组织负责单元和集成测试并保证提交的产品质量达到系统测试的要求。组织研究组成员根据系统测试中提交的研究组成员根据系统测试中提交的Bug进行修改并发布新版本。进行修改并发布新版本。u测试负责人：负责组织测试团队，编写测试计划、测试大纲，按计划进测试负责人：负责组织测试团队，编写测试计划、测试大纲，按计划进行测试。行测试。u测试人员：负责编写测试样例、执行测试、发布测试报告等。测试人员：负责编写测试样例、执行测试、发布测试报告等。u质量保证人员：负责审计系统测试过程和测试报告。质量保证人员：负责审计系统测试过程和测试报告。u配置管理员
13、：负责配置审计和检入、检出控制，为缺陷管理提供支持。配置管理员：负责配置审计和检入、检出控制，为缺陷管理提供支持。研究室测试过程总体流程（参见流程图）总体流程（参见流程图）u需求阶段需求阶段u设计阶段设计阶段u编码阶段编码阶段u集成测试阶段集成测试阶段u系统测试阶段系统测试阶段u测试报告的确认测试报告的确认研究室测试过程需求阶段需求阶段在需求阶段，测试人员需要了解需求，根据需求编写测试用例。在需求阶段，测试人员需要了解需求，根据需求编写测试用例。u测试人员必须参加研究组的需求培训和参加主要的需求讨论、分测试人员必须参加研究组的需求培训和参加主要的需求讨论、分析会议。需求和原型的讨论结果也应发与
14、测试人员。析会议。需求和原型的讨论结果也应发与测试人员。u测试人员应参加需求的评审会议，对于需求的可测性进行确认，测试人员应参加需求的评审会议，对于需求的可测性进行确认，协助确定需求的验收标准。协助确定需求的验收标准。u如果有原型的讨论会议，测试人员也应参加。如果有原型的讨论会议，测试人员也应参加。u需求文档评审通过后研究组指定负责人编写系统测试方案。系统需求文档评审通过后研究组指定负责人编写系统测试方案。系统测试方案要经过评审后才可使用。测试方案要经过评审后才可使用。研究室测试过程（续）（续）u测试负责人根据需求文档和项目开发进度计划编写系统测试测试负责人根据需求文档和项目开发进度计划编写系
15、统测试进度计划。系统测试进度计划可以与项目进度计划写在一起，进度计划。系统测试进度计划可以与项目进度计划写在一起，但要给出编写系统测试样例和每轮测试的时间及资源。但要给出编写系统测试样例和每轮测试的时间及资源。u测试人员根据需求说明书和业务流程图开始设计系统测试样测试人员根据需求说明书和业务流程图开始设计系统测试样例中的测试功能点和业务测试流程（包括正常业务测试流程例中的测试功能点和业务测试流程（包括正常业务测试流程和异常的业务测试流程）。和异常的业务测试流程）。u测试人员根据测试人员根据SCCB的需求变更修改系统测试样例。的需求变更修改系统测试样例。研究室测试过程设计阶段设计阶段在设计阶段，
16、测试人员需要了解设计，细化测试用例。在设计阶段，测试人员需要了解设计，细化测试用例。u测试人员必须参与结构设计和详细设计的评审会议。测试人员必须参与结构设计和详细设计的评审会议。u测试人员根据开发组的结构设计和详细设计精化测试样例，测试人员根据开发组的结构设计和详细设计精化测试样例，明确出测试步骤、分类的测试数据（正常数据、异常数据和明确出测试步骤、分类的测试数据（正常数据、异常数据和边缘数据）和具体的期望值等。边缘数据）和具体的期望值等。u测试人员根据设计变更修改系统测试样例。测试人员根据设计变更修改系统测试样例。研究室测试过程编码阶段编码阶段在编码阶段，测试人员完成系统测试样例，并提交评审
17、。在编码阶段，测试人员完成系统测试样例，并提交评审。u开发人员根据结构设计和详细设计，确定相互间接口的参数开发人员根据结构设计和详细设计，确定相互间接口的参数和服务是否描述清晰、匹配。对于可能出现的问题要在编码和服务是否描述清晰、匹配。对于可能出现的问题要在编码前提出避免的方法。前提出避免的方法。u开发人员在代码编写完成后进行代码自查和互查和单元测试。开发人员在代码编写完成后进行代码自查和互查和单元测试。u测试人员完成系统测试样例（或者大纲）并提交评审。测试人员完成系统测试样例（或者大纲）并提交评审。研究室测试过程（续）（续）u开发人员根据详细设计编写单元测试样例程序或脚本，并执开发人员根据详
18、细设计编写单元测试样例程序或脚本，并执行。开发人员设计单元测试样例时要注意以下几点：行。开发人员设计单元测试样例时要注意以下几点：同一个包（模块）内类（组件）与类（组件）之间接口的参数同一个包（模块）内类（组件）与类（组件）之间接口的参数和服务是否匹配。和服务是否匹配。测试样例建议达到测试样例建议达到条件覆盖条件覆盖的要求。的要求。在循环的起始、终止值的边界至少走一遍。在循环的起始、终止值的边界至少走一遍。异常处理的测试。异常处理的测试。研究室测试过程集成测试阶段集成测试阶段u集成测试是为了确保各个模块接口没有问题，模块间的数据集成测试是为了确保各个模块接口没有问题，模块间的数据结构是一致的，
19、模块间的通信协议是一致的，系统大体流程结构是一致的，模块间的通信协议是一致的，系统大体流程能够运行。能够运行。u通常情况下，集成测试是指模块之间的集成。但是对于一个通常情况下，集成测试是指模块之间的集成。但是对于一个由多个开发组构成的项目组来说，集成测试还包括各开发组由多个开发组构成的项目组来说，集成测试还包括各开发组生产的软件之间的集成。生产的软件之间的集成。u集成测试由研究组开发人员来完成。集成测试由研究组开发人员来完成。研究室测试过程系统测试阶段系统测试阶段系统测试指根据需求对最终软件进行测试，以便发现软件中的缺系统测试指根据需求对最终软件进行测试，以便发现软件中的缺陷，验证软件满足预先
20、定义的需求。一般采用黑盒测试方法。陷，验证软件满足预先定义的需求。一般采用黑盒测试方法。u进入系统测试阶段的三个前提条件：进入系统测试阶段的三个前提条件：送系统测试的产品经过了开发组内的集成测试，保证在系送系统测试的产品经过了开发组内的集成测试，保证在系统测试时大体业务流程不会出现堵塞现象。统测试时大体业务流程不会出现堵塞现象。测试人员得到开发人员的邮件通知。测试人员得到开发人员的邮件通知。测试人员可以从静态配置库得到安装包或升级包，并确定测试人员可以从静态配置库得到安装包或升级包，并确定包中的内容符合要求。包中的内容符合要求。研究室测试过程（续）（续）u系统测试过程系统测试过程测试人员根据测
21、试进度计划按照测试方案中的测试类型进测试人员根据测试进度计划按照测试方案中的测试类型进行测试。行测试。 对于功能测试，测试人员要进行对于功能测试，测试人员要进行自由测试自由测试和严格按照测和严格按照测试样例测试两种方式。试样例测试两种方式。测试人员可以根据测试进度进行回归测试。测试人员不用测试人员可以根据测试进度进行回归测试。测试人员不用每轮都做每轮都做完全回归测试只做部分回归测试完全回归测试只做部分回归测试即可，但发布现即可，但发布现场的版本必须要进行完全回归测试。场的版本必须要进行完全回归测试。测试人员还必须对用户安装手册、使用手册、维护手册和测试人员还必须对用户安装手册、使用手册、维护手
22、册和升级安装手册进行测试。升级安装手册进行测试。研究室测试过程（续）（续）测试人员必须将测出的缺陷提交到测试人员必须将测出的缺陷提交到Bugzilla。如何使用。如何使用Bugzilla和如何确认缺陷的优先级和修改缺陷状态请参阅和如何确认缺陷的优先级和修改缺陷状态请参阅 Bugzilla管理指南管理指南。测试完毕后测试人员发布测试报告给部门主管、研究组测试完毕后测试人员发布测试报告给部门主管、研究组负责人、测试负责人、质量保证人员和配置管理人员等负责人、测试负责人、质量保证人员和配置管理人员等相关人员。相关人员。测试报告内容详见测试报告内容详见系统测试报告模板系统测试报告模板项目组负责人必须参
23、加最后一轮的系统测试以确定最终项目组负责人必须参加最后一轮的系统测试以确定最终产品的功能和性能达到了需求中的要求。产品的功能和性能达到了需求中的要求。 研究室测试过程测试报告的确认测试报告的确认 u部门主管、研究组负责人、测试负责人、配置人员和质量保部门主管、研究组负责人、测试负责人、配置人员和质量保证人员根据测试报告对测试结果进行审计、确认。证人员根据测试报告对测试结果进行审计、确认。u当产品最后一轮测试报告确认后，测试活动结束。当产品最后一轮测试报告确认后，测试活动结束。研究室测试过程质量记录质量记录u系统测试计划系统测试计划u系统测试大纲系统测试大纲u系统测试报告系统测试报告验证验证u评
24、审人员评审评审人员评审系统测试计划系统测试计划、系统测试大纲系统测试大纲。u部门主管、项目负责人、质量保证人员审计、确认部门主管、项目负责人、质量保证人员审计、确认系统测系统测试报告试报告。u质量保证人员对整体测试过程进行审核。质量保证人员对整体测试过程进行审核。测试类型（参见文档）功能测试功能测试 用户界面测试用户界面测试 性能测试性能测试 配置测试配置测试 安装卸载测试安装卸载测试 安全性和访问控制测试安全性和访问控制测试 数据和数据库完整性测试数据和数据库完整性测试 故障转移和恢复测试故障转移和恢复测试 文档测试文档测试 相关文档规范：规范：软件测试计划编写指南软件测试计划编写指南软件测试大纲编写指南软件测试大纲编写指南软件测试报告编写指南软件测试报告编写指南模板：模板：软件测试计划模板软件测试计划模板软件测试大纲模板软件测试大纲模板软件测试报告模板软件测试报告模板
