测试工作计划【通用5篇】

【前言导读】此篇优秀范文“测试工作计划【通用5篇】”由阿拉题库网友为您精心整理分享，供您学习参考之用，希望这篇资料对您有所帮助，喜欢就复制下载吧！

测试工作计划【第一篇】

简述本计划的目的，旨在说明各种测试阶段任务、人员分配和时间安排、工作规范等。

测试计划在策略和方法的高度说明如何计划、组织和管理测试项目。测试计划包含足够的信息使测试人员明白项目需要做什么是如何运作的。另外，清晰的文档结构能使任何一个读者在浏览计划的前面几页后，就能对项目有一个大概的认识。测试计划只是测试的一个框架，很多细节需要跟开发人员或其他人员沟通，因此计划不包括测试用例的细节和系统功能的详细信息。在计划目的中需要指明读者对象。

名词解释

列出本计划中使用的专用术语及其定义

列出本计划中使用的全部缩略语全称及其定义

参考资料

列出本计划各处参考的经过核准的全部文档和主要文献。

测试摘要

这一节主要说明测试计划中重要的和可能有争议的问题。本节的主要目的是将这些信息传递给那些可能不会通读整个测试计划文档的人员(比如经理或开发项目的负责人)。

重点事项

列出测试的重点事项。可以将问题按重要程度和优先级罗列出来，然后在后面的章节中再对这些问题进行详细说明，这样就能让对这些问题有重要影响的人员知道问题的所在

争议事项

简要说明争议事项。

风险评估

通过对技术文档的阅读，对被测系统可能存在的问题：系统设计，数据库设计，响应时间，计费策略，因测试环境不足可能存在的测试缺陷事先评估出来，以指导测试方案，进行有重点的测试。

时间进度

测试工作计划【第二篇】

参加认证计划的A380飞机共有五架。目前，有三架A380验证机正在进行飞行测试。截至2005年11月，这三架验证机已成功完成总计237架次、523小时的测试飞行。第一架A380验证机于2005年4月27日完成首次飞行。第二和第三架A380验证机也分别于2005年10月18日和2005年11月3日成功进行了首飞。

目前，这三架验证机以及按计划将于2006年早些时候参与飞行测试的第四架验证机均配备了罗罗“遄达900”发动机。第五架A380验证机将配备由联合发动机公司制造的“GP7200”型发动机。按计划， 第五架A380验证机将在2006年年中进行首次飞行，主要用于对配备新型发动机的飞机性能及发动机本身进行测试。

最初的两架A380验证机是系列飞行测试的主要环节，在这两架飞机上均配备了重型飞行测试仪器及水压载。飞机测试的对象包括：飞行速度包线、飞行振动、航空电子设备及操纵性能。首架验证机还参与了负载测量飞行与系统发展工作，测试对象包括自动驾驶仪、电气系统、液压系统及导航系统等。

迄今为止完成的大量测试表明，A380飞机的飞行速度包线、最佳空气动力配置已得到确定，此外还成功地试验了飞机的最小（失速）速度和最大（VD/MD）速度以及万英尺的升限。

振动测试已经在2005年底完成，测试结果良好。

第二架验证机目前正在进行编订飞行手册所必需的全部测试。这些测试包括飞机在一台发动机不工作时的爬升性能，所有发动机正常工作时的起飞性能，以及一台发动机不工作时的起飞性能和飞机的制动性能。

按计划，高空测试也是飞行手册编订工作的一部分。寒冷气象条件下的测试可能会在加拿大北部地区进行，届时飞机将被暴露在零下40度的低温中进行测试。炎热气象条件下的系列测试也计划于2006年早些时候进行，非洲有可能成为测试地区。抗电磁干扰试验将于2006年上半年按计划进行。

与此同时，在第三与第四架A380验证机上将配备全部客舱设备与轻型飞行测试仪器。它们将用于对客舱性能及客舱系统进行测试，测试对象包括机上娱乐系统、乘客舒适度、客舱噪音水平以及舱内通风。另外，这两架飞机还将进行部分认证演练，例如，检验机上灭火设备与烟雾探测系统的有效运转情况。

提供两架飞机专门用于全部客舱特性的验证与确认，这足以表明空中客车公司对客舱设计和乘客舒适度的重视。

目前，第三架验证机还在汉堡安装全部客舱设备。该机计划在2006年早些时候携机上安装的全部客舱设备进行飞行。

一旦第四架飞机在2006年早些时候进行首次飞行并成功完成飞行试验，也将为其安装全部客舱设备，用以对由不同供应商提供的设备及系统进行测试。

在2006年年中，第三架飞机还将被用于进行早期远程飞行。此次专项试验将持续两个月，目的是确保飞机可安全运送乘客。在这一系列试验中，飞机将从图卢兹起飞，分别按照4小时、8小时和15小时时间段飞行，并最终返回图卢兹。届时机上将搭载通过抽奖胜出的空中客车公司的乘客。这些飞行将对机舱在乘客满员条件下的性能进行测试。这两架装有客舱设备的飞机都将被用于进行航线验证测试以及机场兼容性测试。

第四架飞机在汉堡完成客舱设备安装后，将通过一系列展示来表明A380能够满足最严格、最新的客舱安全规定。飞机上将进行一项一级测试，以展示在高密度的座位布局下，飞机拥有在要求的90秒内撤出最大数量乘客（800个座位以上）的能力。

2005年10月，A380首次飞离法国，前往德国的法兰克福。此后又高调进行了A380飞机亚太之旅，在新加坡、吉隆坡、布里斯班、悉尼和墨尔本等地停留。最后，A380飞机出现在迪拜航空展上，它的亮相在观众中引起了轰动。

这些旅程中也包含机场兼容性测试、推广活动和数据收集等内容。尽管A380飞机非常需要进行推广，但是飞行测试机组仍抓紧时间收集重要的技术信息并进行机场兼容性测试。测试机组在长时间的运输飞行过程中，利用典型的航线环境，对导航系统、飞行管理系统、未来空中导航系统、高频无线电、燃油系统及增压系统进行了测试，并且从中获益良多。

在法兰克福进行的机场全面兼容性测试，以及在吉隆坡、布里斯班、悉尼和墨尔本等地进行的测试证明了A380能够在机场环境中实现无缝整合。这些测试科目包括：环绕机场滑行、停靠登机口以及乘客登机廊桥定位等。用于食品补给、货物装卸、供水和燃油加注的各类车辆也被停放在飞机周围，以展示它们能够方便地围绕飞机移动，从而证明所列举的飞机周转时间是切实可行的。

在2006年，A380将在欧洲以外的地区巡回旅行，其中包括参加新加坡航展，以及其他一些机场兼容性测试。

事实上，空中客车公司自2004年10月起就已经开始在图卢兹对最早的一架A380机体进行了静力试验。该机体从一开始就没打算用行。这些试验目前仍在进行当中。

迄今为止，飞机的机翼与机身已经成功地达到了极限――即飞机在飞行中所能承受的限定载荷。它们进行的一项时间长达一年的认证试验项目已接近尾声。该试验项目的目的是要确认在各类飞行与地面条件下，飞机所能承受的最大载荷或极限负载。

需要接受认证的极限负载试验内容是：对飞机结构施加达到限定载荷标准倍的负载，使机翼与机身承受最大设计载荷，从而确认飞机结构的强度。在完成极限负载试验后，飞机机身与机翼将继续承受更大负载，直至破损的临界点。

疲劳测试于2005年9月在位于德国德累斯顿的测试实验室启动，该测试比原定计划提前了两个月。测试在一架专门供试验用的机身上进行，该机身不用行。预计整个测试工作将持续26个月，总共需要进行万次模拟飞行测试，在测试一般性的飞行与地面负载对机身结构的影响的同时，也将对客舱增压与减压的效果进行测试。测试目标是完成近5000次模拟飞行测试，以取得型号许可证。

空中客车A380飞机的首席适航检验工程师让・米切尔・高瓦耶解释说，认证计划将在授予型号许可证前数周结束，这其中也包含了许多其他类型的测试――如在实验室、设备销售商处、地面上以及飞行模拟器内进行的各类测试，以及各种详细说明、分析、安全和安全计算与检查――所有测试将总共生成约2000份文件。

测试工作计划【第三篇】

关键词软件测试 测试报告 测试流程

1 引言

软件测试是软件开发过程的重要组成部分，是用来确认一个产品的品质或性能是否符合开发之前所提出的要求。对软件需求分析、设计规格说明和编码的最终复审，某种程度上测试工作的好坏直接影响了软件产品的交付和用户的满意度。因此，如何做好测试工作，使测试在软件工程中顺利进行，辅助软件开发工作是我们每个软件人员应该考虑的问题。

2 软件测试的目的

（1）确认软件的质量，确认软件做了你所期望的事情，确认软件以正确的方式来做了这个事件。

（2）提供信息，比如提供给开发人员或程序经理的反馈信息，为风险评估所准备的信息。

（3）软件测试不仅是在测试软件产品的本身，而且还包括软件开发的过程。软件测试的第三个目的是保证整个软件开发过程是高质量的。

3 软件测试的对象

软件测试并不等于程序测试。软件测试应该贯穿整个软件定义与开发整个期间。因此需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应该是软件测试的对象。

4 软件测试流程

软件测试工作并不是在软件代码开发完毕后才开始的，这一点是很多软件人员的误区，需要明确一下，它其实是在项目进入软件实现阶段就开始了，项目进入软件实现阶段的时候，就应该启动软件测试工作了。

下面根据笔者的测试经验，详细阐述一下软件测试的流程、每个阶段需要做的工作及整个测试过程产生的文档。

计划与设计阶段

召开测试启动会议

当项目进入软件实现阶段（编码），测试经理召集项目经理、开发经理开会确定测试交接时间，开发团队与测试团队交接测试内容，对测试目标达成一致，商讨测试计划的可行性，统一项目组的目标和测试的工作重点。进行规模预估并成立测试团队，完成《测试计划》和《测试方案》。

设计测试用例

明确了测试需求和测试计划，在需求分析文档确立基线以后，测试组需要针对测试需求编写全部测试用例，在实际的测试中，测试用例将是唯一实施标准。

实施测试阶段

实施测试用例

实施测试用例将花费测试组绝大部分时间，这些工作都是建立在前期很多计划工作的基础上。当测试用例全部编写完成后，测试工程师根据测试计划中分配给自己的测试任务，实施相应的测试用例，并记录测试结果。

填写测试记录

测试人员在进行具体的测试工作时，需要将测试内容填写在测试记录表中，直到所有的测试执行工作结束。

提交BUG清单

在具体的测试过程中，测试人员发现BUG后，需要将BUG记录在清单里，并及时提交给测试经理。

提交测试报告

在约定的测试周期完成之后，测试工程师需要总结此测试的结果，编写测试报告。测试工程师根据此轮测试的结果，编写测试报告，主要应包含以下内容：

（1）测试报告的版本。

（2）测试的人员和时间。

（3）测试所覆盖的缺陷――测试组在这轮测试中所有处理的缺陷， 不仅要写出覆盖缺陷的总数，还要写明这些缺陷的去向。

（4）上一版本活动缺陷的数量。

（5）经过此轮测试，所有活动缺陷的数量及其状态分类。

（6）测试评估――写明在这一版本中，哪些功能被实现了，哪些还没有实现，这里只需写明和上一版本不同之处即可。

（7）急待解决的问题――写明当前项目组中面临的最优先的问题，可以重复提出。

在每轮测试结束之后应尽快将符合标准的测试报告发给测试经理。

总结阶段

测试工作结束或即将结束时，测试组就要开始着手准备进行总结的工作。

编写测试总结报告

在测试结束之后，测试经理编写测试报告，对测试进行总结，并且提交给项目经理，为产品的后续工作提供重要的信息支持。

测试经理根据测试的结果及测试工程师提交的测试报告编写测试总结报告，测试总结报告必须包含以下重要内容：

（1）测试资源概述―多少人、多长时间。

（2）测试结果摘要―分别描述各个测试需求的测试结果，产品实 现了哪些功能点，哪些还没有实现。

（3）缺陷分析―按照缺陷的属性分类进行分析。

（4）测试需求覆盖率―原先列举的测试需求的测试覆盖率，可能 一部分测试需求因为资源和优先级的因素没有进行测试，那么 在这里要进行说明。

（5）测试评估―从总体对项目质量进行评估。

（6）测试组建议―从测试组的角度为项目组提出工作建议。

测试验收

测试验收工作是在以上工作全部结束后，测试经理对测试的过程、效果进行验收，签发测试验收报告，宣布测试结束。由测试经理进行测试验收，验收内容包括：

（1）测试效果验收―测试是否达到预期目的。

（2）测试文档验收―测试过程文档是否齐全，符合标准。

（3）测试评估―从总体对测试的质量进行评估。

（4）测试建议―对本次测试工作指出不足，需要在以后工作中改 进的地方。

（5）宣布测试结束―测试组成员签字宣布本次测试结束。

测试归档

测试归档是在测试验收结束宣布测试有效，结束测试后，对测试过程中涉及到各种标准文档进行归档，主要包括测试计划、测试用例、测试报告、验收报告等。这些文档的编写保障了测试的顺利进行，同时作为整个测试项目的痕迹，被保留下来，供查阅。

参考文献

[1]佟伟光。软件测试[M].北京：人民邮电出版，2008.

[2]Rex Black.测试流程管理[M].北京：北京大学出版社，2001.

[3]Robert 著，华庆一等译。面向对象系统的测试[M].北京：人民邮电出版社，2001.

[4]Mark Fewster， Dorothy Graham著，舒智勇等译。软件测试自动化技术与实例详解[M].北京：电子工业出版社，2000.

[5]Karl 著，陆丽娜，王忠民，王志敏译。软件需求[M].北京：机械工业出版社，2000.

测试计划【第四篇】

关键词：自动化测试；自动化测试管理平台

中图分类号：TN98 文献标识码：A文章编号：1009-3044(2011)28-7003-05

1 概述

2 电信行业自动化测试需求

作为运营商的核心生产系统之一，BSS系统的稳定性运行非常关键，其每次发生的重大故障都会给运营商带来严重的经济损失。而BSS系统的稳定运行，与应用开发/集成商提供的应用软件本身的稳定性密切相关。

BSS系统稳可以分为3个方面：系统功能稳定，不要动辄操作失败；系统运行效率好，实时性高；系统运行平稳，不要动辄重启服务器解决严重性能故障问题。而要做到这三方面，不对应用软件进行充分的测试，是无法保证的。

在BSS的实际建设和维护过程中，关于应用软件导致的系统不稳定（主机、存储等设备，数据库、中间件等系统软件导致的不稳定，本文不作讨论），可以大致归结为以下几种：

1）运营商的业务需求繁杂多变，开发周期短，难以进行充分的测试即被迫匆匆上线。每次系统升级前除了进行需求确认测试外，还应进行全量回归测试，以保障变更不会影响到其他功能，这在管理上是很难实现的！

2）新上线系统的BUG过多，功能不稳定。某个新系统上线后，才发现应用软件的BUG很多，营业员时不时的操作失败，而又不是每次都操作失败，让人难以琢磨该系统的“性格”。

3）新上线业务功能导致原有正常业务功能出错。这可以说是BSS系统维护中最常发生的不稳定问题，实际上就是新功能开发时，只对新功能进行了测试，而没有对原有功能的影响进行大量的测试，导致上线前没有发现问题，而仓促上线所致。

4）系统BUG修复后，因回归测试不全面，在上线时会产生新的BUG，得不偿失。

5）新上线业务越来越多，系统越来越慢，直至系统后台死机不处理。这属于典型的性能、压力的测试和分析不够，并进而对系统支撑业务能力估算不足所致

这5个问题，从另一个角度来看，可以理解为解决当前BSS应用软件测试问题的三个步骤。

首先必须加强上线前开发/集成商的软件测试，建立完整的测试流程和测试环境。

在此基础上，对每个新上线的业务功能，除了执行新功能本身的测试外，还通过建立丰富的测试用例库来确保执行严格的功能回归测试，才能确保新上线业务没有对原有正常业务功能产生不良影响；

同时，引入适当的测试工具软件。一方面，即使针对正在研发中的软件，由于在开发过程中不断引入的变更（发现错误进行的变更，业务需求变化引起的变更等），对于已经测试通过的功能，也需要在每次修改代码后进行回归测试，只有这样才能保证即使在代码不断修改的情况下，软件时相应的功能测试仍然是通过的。而这种回归测试的工作量非常之巨，以至于如果完全人工来做，是不可能实际做到的，自动化测试可以解决回归测试、重复测试的问题。这样才能解决以上问题中1、2、3和4；

最后，有了这些测试流程、测试环境、测试用例库，才可以进行严格的性能测试和分析，为新业务上线对系统荷载造成的影响进行科学客观的分析，从而准确地把握系统实际运行荷载的变化趋势，并进而尽早发现系统支撑能力的“临界点”。

因此，电信行业的业务运营支撑系统有必要启用自动化测试。

3 自动化测试的好处

自动化测试长久以来，一直是软件测试领域的热点，而今从事或者具有自动化测试技能的工程师更是就业市场非常需要的人才。这是因为自动化测试可以带来很多好处。

将精力投入更有意义的测试。自动化测试的引入会减轻重复的工作，使得测试人员有更多的时间去分析测试需求、设计详细的测试计划、测试用例、构建更复杂的测试。可以说这是自动化测试带给我们的最大好处之一。

回归测试，降低测试成本。这可能是自动化测试最主要的任务，特别是在程序修改比较频繁时，效果是非常明显的。由于回归测试的动作和用例是完全设计好的，测试期望的结果也是完全可以预料的，将回归测试自动运行，可以极大提高测试效率，缩短回归测试时间。

充分利用资源。可以在无人时定时执行自动化测试脚本，到时候直接看执行结果即可。人工测试和自动化测试相结合使用，可以在白天上班时间进行新功能的手工测试，原有功能的自动化测试可以在晚上或者周末执行，第二天就可以看到执行的结果。即避免了开发和测试之间的等待，又充分利用时间资源，提高测试效率。

测试具有一致性和可重复性。由于测试是自动执行的，每次测试的结果和执行的内容的一致性是可以得到保障的，从而达到测试的可重复的效果。

测试的复用性。由于自动测试通常采用脚本技术，这样就有可能只需要做少量的甚至不做修改，实现在不同的测试过程中使用相同的用例。

加大软件信任度。由于测试是自动执行的，所以不存在执行过程中的疏忽和错误，完全取决于测试的设计质量。一旦软件通过了强有力的自动测试后，软件的信任度也会增加。

公司实力的象征。自动化测试也从一定程度上体现出一个公司对测试质量的重视和实力，增强用户对软件的信任度。

自动化测试是对手工测试的一种补充，自动化测试不可能完全替代手工测试，因为很多数据的正确性、界面是否美观、业务逻辑的满足程度等都离不开测试人员的人工判断。而仅仅依赖手工测试，则会让测试过于低效，尤其是回归测试的重复工作量对测试人员造成了巨大的压力。自动化测试的意义不是为了取代人在手工测试中的位置，而是将人从重复繁琐的工作中解放出来，做更有价值的测试工作。

4 自动化测试框架

前面章节介绍了电信行业业务支撑系统对于自动化测试的需求，下面来介绍自动化测试在某省BSS系统支撑过程中的实际应用。

自动化测试框架整体介绍

建立自动化测试框架就是为了把测试数据与测试用例的分离、测试数据与业务流程的分离、测试用例与业务流程的分离，让自动化测试更容易维护、用例的重复利用率更高，最后再和需求管理、开发进度管理统一起来，整个质量控制体系就更加完善。

自动化测试框架包括：自动化测试管理和自动化测试工具。自动化测试管理包配置管理、组件管理、测试用例管理、测试计划管理、数据管理，自动化测试报告管理。在本自动化测试框架中使用的是SilkTest测试工具和自主配套研发的自动化测试管理工具平台。运用在实际的电信行业中的框架如图1所示。

5 自动化测试工具选用

自动化测试的工具很多，当前主流的自动化测试工具有Mercury Interactive Corporation、IBM Rational、Compuware Corporation、Segue Software等公司的系列产品。产品简介如下，这里选用的是Borland Software SilkTest（原SegueSoftware产品）

SilkTest 是面向 Web 应用、 Java 应用和传统的 C/S 应用，进行自动化的功能测试和回归测试的工具。它提供了用于测试的创建、定制的工作流设置、测试计划和管理、直接的数据库访问及校验等功能，使用户能够高效率地进行软件自动化测试。为提高测试效率， SilkTest 提供多种手段来提高测试的自动化程度，包括：从测试脚本的生成、测试数据的组织、测试过程的自动化、测试结果的分析等方面来进行规范。

SilkTest的脚本语言采用面向对象的编程语言 4Test 来编写灵活的测试脚本，并且SilkTest 有较好的跨平台性。

6 自动化测试管理平台

为了能够让自动化测试入门更简单，维护更加简单容易。我们自主研发了自动化测试管理平台，是基于自动测试工具的自动测试统一工作平台。自动化测试管理平台为B/S结构的系统包括组件管理、测试用例管理、测试计划管理，测试报告管理等。自动化测试工具和自动测试统平台的交互，能够很好的维护自动测试脚本及工程文件，并能以更加直观方式对自动测试结果进行展示。统一的自动化测试平台有如下特点：

通过自动测试平台对象管理功能，可以显示对象的增量修改功能；

SilkTest工具编写的脚本，可以导入到自动测试平台，并通过可视化界面对脚本进行维护；

自动测试平台可以对脚本进行有效的管理，保证脚本的唯一性；

自动测试平台可以对SilkTest整个工程进行管理，方便整个工程的读取；

自动测试平台可以将测试结果文件以pdf文件的形式导出，便于对测试结果的阅读和分析。

组件管理

组件管理包括：对象导入、对象维护、对象导出。

对象获取。要管理对象，就要先获取取对象。对象获取和整理是编写用例的前提。整理好对象会对在平台上编写用例有很大帮助。也会对接手维护的人员有很大帮助。对象是通过SilkTest工具来获取的，获取对象有两种途径：Window Declarations（获得整个页面的对象）和Window Identifiers（获取单个对象的属性）。Window Declarations获取的对象，结果如图2所示。

对象导入。通过自动化测试平台的导入对象功能，将SilkTest获取的对象存储到数据库中，以便后期维护和部署。页面如图3所示。

对象导出。通过自动化测试平台导出对象文件以便部署到服务器上。页面如图4所示。

对象维护。对导入的对象进行修改或者添加新的元素，页面如图5所示。

自动化测试用例管理

自动化测试用例的管理包括：测试用例添加，测试用例维护，测试用例导出。

用例添加。需要填写用例名称、用例说明、期望结果和用例类型。操作页面如图6所示。

用例维护。添加用例完成后，在用例维护中将SilkTest中的脚本写成操作步骤。此时页面右边的树就是我们导入的对象，点击对象就可以添加操作步骤。补换卡业务的测试步骤截图如图7所示。

用例导出。将用导出为SilkTest可执行的脚本文件，以后需要调试该用例时，直接通过自动测试管理平台导出用例执行，直接部署到自动化测试机上。操作页面如图8所示。

数据管理

在编写测试用例的过程中，一定会涉及到数据的交互，例如测试用例的输入数据从哪里获得，如何对输出结果进行验证等。

通常有两种方法：数据写到脚本里面；将数据与脚本分离，存放到excel或数据库中。我们现在选择的是将脚本和数据分离的方式，这样做有如下好处：

1）便于脚本的维护；

2）便于一个脚本支持多个用例，当编写一个新用例时，只需去配置与该用例相关的数据即可；

3）利于扩展和组织测试计划。

测试计划管理

测试计划管理包括：计划新增、计划维护和计划生成。

计划新增。自动化测试管理平台上有测试计划管理功能，查询出用例并放到新计划中。同时系统还提供了对测试计划维护的功能。如图9。

计划维护。自动化测试管理平台上有测试计划维护功能，即修改已经存在的计划里面包含的用例，可增加或者删除，操作页面如图10所示。

计划生成。由测试计划生成功能，生成脚本、生成计划。即可部署到自动化测试主机上执行。如图11。

自动化定时执行

编写一个bat文件，定时执行即可，如图12。

自动化测试报告管理

结果数据的抽取、汇总与展示。在测试执行过程中，通过特定的数据采集组件以及事件触发，获得我们关心的中间结果数据，并且将数据全部入库，根据客户需求，展现一份客户能够看得懂的报告。避免了工具原有报告难理解的问题。同时，记录下来的中间数据可以很好的体现出每个步骤地详细信息和过程时间，这样可以提供一段时间内的横向和纵向的对比，为系统特别是生产系统上的性能渐变提供有力的监控和依据。

自动化测试平台从数据库中捞出测试结果进行处理，根据需要生成用户容易看懂的PDF格式的自动化测试报告，如图13，图14所示。

7 自动化测试流程

有了上面自动化测试管理平台的支撑，自动测试流程中编写测试脚本、执行自动化测试的开展就会更加顺利。

表1为自动化测试流程角色表。自动化测试流程如图15所示。

1）制定测试计划。测试经理要制定测试计划，明确测试对象、测试目的、测试的项目内容、测试的方法、测试的进度要求，并确保测试所需的人力、硬件、数据等资源都准备充分。制定好测试计划后，分派给QA；

2）分析测试需求。QA根据测试计划和需求说明书，分析测试需求，设计测试需求树，以便用例设计时，能够覆盖所有的需求点；

3）设计测试用例。QA通过分析测试需求，设计足够多能够覆盖所有需求点的测试用例，形成专门的测试用例文档。并不是所有的测试用例都能用自动化来执行，所以需要将能够执行自动化测试的用例汇总成自动化测试用例；

4）搭建测试环境。自动化测试人员在用例设计工作开展的同时即可着手搭建测试环境。包括被测系统的部署、测试硬件的调用、测试工具的安装和设置、网络环境的布置等等；

5）编写测试脚本。自动化测试人员在自动化测试管理平台的支持下，编写自动化测试用例步骤，通过自动化测试工具编辑脚本插入检查点和异常判定反馈语句，调试脚本；

6）执行自动测试。自动化测试人员测试测试计划，验证软件功能，执行回归测试、流程测试等，以替代重复性的手工测试工作；

7）分析测试结果。自动化测试人员根据执行结果，分析测试通过与没通过的情况，通过自动化测试平台生产用户容易读懂的自动化测试报告；

8）记录测试问题。QA在测试脚本执行完毕之后，即可查看测试工具的测试报告，然后将没有通过的地方提取出来，描述成BUG，反馈给开发人员；

9）跟踪测试BUG。QA将测试中发现的BUG记录到BUG管理工具中去，以便定期跟踪处理。开发人员修改后，需要对此问题执行回归测试，即重复执行一次该问题对应的脚本，通过则关闭，否则继续修改。如果问题（BUG）的修改方案与客户达成了一致，但与原来的需求有所偏离，那么回归测试前，还需对脚本进行必要的修改和调试。

8 系统软硬件环境

系统的软硬件基本要求如表2所示。

9 结束语

电信行业业务支撑系统随着电信业务的发展和计算机技术的日新月异，系统功能不断扩充和更新。每次需求变更，系统缺陷，都会给系统带来大大小小的频繁更新。在需求管理、测试流程管理、测试环境这些都具备的条件下，要满足运营商给开发商预留的项目工期越来越紧，对软件的质量要求越来越高，对开发商软件正式上线前尽量减少程序BUG这些要求，这就必须要提高软件测试的质量和效率，在手工测试的基础上引入自动化测试，建立完善的自动化测试管理平台，统一管理测试用例库，让自动化测试完成大量的回归测试和重复性测试，让测试人员将精力投入更有意义的测试，制定更加合理的测试计划、设计更完善的测试用例，使得测试覆盖率更高，发现更多的问题，最终保障BSS系统的质量、降低业务支撑系统给运营商带来的风险，也将对电信运营商的业务支持起到非常积极的作用。

参考文献：

[1] 科兹纳。项目管理：计划、进度和控制的系统方法[M].10版。杨爱华，译。北京：电子工业出版社，2010:19-102.

[2] 柳胜。软件自动化测试框架设计与实践[M].北京：人民邮电出版社，2009.

[3] 陈能技。软件自动化测试成功之道[M].北京：人民邮电出版社，2010.

[4] Paul 软件测试[M].韩柯，杜旭涛，译。北京：机械工业出版社，2003.

[5] 胡贝蒂。软件质量和软件测试[M].马博，赵云龙，译注。北京：清华大学出版社，2003.

[6] 布莱克。软件测试实践[M].郭耀，译。北京：清华大学出版社，2008.

[7] 朱少民。轻轻松松自动化测试[M].北京：电子工业出版社，2009.

[8] 蔡为东。赢在测试[M].北京：电子工业出版社，2010.

[9] 温伯格。完美软件[M].宋锐，译。北京：电子工业出版社，2009.

[10] 惠特克。探索式软件测试[M].方敏，张胜，钟颂东，等，译注。北京：清华大学出版社，2010.

[11] 曹向志。软件测试项目实战[M].北京：电子工业出版社，2010.

[12] Dennis 精粹[M].3版。北京：清华大学出版社，2009.

测试工作计划【第五篇】

测试范围

说明本计划涵盖的测试范围，比如功能测试、集成测试、系统测试、验收测试等。通常说明什么是要测试的，什么是不要测试的是非常重要的。明确规定这些问题后，测试人员对该做什么有一个清晰的认识。

(1)简要地列出测试对象中将接受测试或将不接受测试的那些性能和功能。

(2)如果在编写此文档的过程中作出的某些假设可能会影响测试设计、开发或实施，则列出所有这些假设。

(3)列出可能会影响测试设计、开发或实施的所有风险或意外事件。

(4)列出可能会影响测试设计、开发或实施的所有约束。

提示和技巧：

需要测试和特别注意测试那些部分？

测试是否专么针对与某些问题的解决？

哪些部分不需要测试，为什么？

哪些部分需要推迟测试，为什么？

是否要验证每个模块的稳定性？

测试的优先级和先后顺序

测试目标

系统目标对测试人员了解自己需要做什么是非常重要的。测试项目负责人应积极与系统设计人员或开发人员沟通，以取得相关资料。测试人员必须知道系统是做什么并且帮助项目实现这种目标。在计划中包括系统视图和目标后，要确保所有的测试人员都知道项目和系统的目标。

通常情况下项目计划都是模糊的。模糊的目标必须通过成员的努力转换成可衡量和实现的东西。没有固定的视图和目标，你将无法完成部分任务。而且，你会发现很难将对产品的认识向别人转述。

联系方式

列出项目参与人员的职务、姓名、E-mail 和电话。

风险及约束

列出测试过程中可能存在的一些风险和制约因素，并给出规避方案。如：