目 次
1 范围 ............................................................ 1
1.1 标识 .......................................................... 1
1.2 系统概述 ...................................................... 1
1.3 文档概述 ...................................................... 1
1.4 与其它计划的关系 .............................................. 1
2 引用文档 ........................................................ 1
3 软件测试环境 .................................................... 1
3.1 软件项 ........................................................ 1
3.2 硬件和固件项 .................................................. 2
3.3 权限 .......................................................... 2
3.4 安装、测试与控制 .............................................. 2
4 定义 ............................................................ 2
5 被测软件的等级 .................................................. 2
6 正式合格性测试 .................................................. 2
6.1 进入条件 ...................................................... 2
6.2 测试项目及要求 ................................................ 3
6.3 测试方法 ...................................................... 5
7 数据记录、整理和分析 ............................................ 7
I
软件测试计划
共9页 第 1 页
1 范围
1.1 标识
a. 已批准的标识号：
b. 标题： XX信息上传箱软件测试计划
c. 缩略语：
CSCI：计算机软件配置项
d. 本文档适用于XX信息上传箱软件测试。
1.2 系统概述
本文档适用于XX信息上传箱软件测试。
1.3 文档概述
本文档适用于XX信息上传箱软件在研制过程中由承制方进行的配置项测试。
本文档规定了XX信息上传箱软件配置项测试的进入条件、测试项目、测试要求、测试方法、通过准则等内容。
1.4 与其它计划的关系
无
2 引用文档
《XX系统软件需求规格说明》
3 软件测试环境
3.1 软件项
Windows 2000操作系统：XXX信息上传箱软件的运行平台；
Visual C++ 6.0：OPC信息上传箱软件的开发及源代码分析平台；
ComMonitor串口调试软件：接收XXX信息上传箱软件传送给VDR的串口数据。
软件测试计划
共9页 第 2 页
3.2 硬件和固件项
电脑一台；
VGA接口的液晶显示屏一块。
USB转422转换器一个。
3.3 权限
软件测试环境相关的权限属于XXX公司。
3.4 安装、测试与控制
将主机传令钟、应急传令钟、舵传令钟与XXX信息上传箱连好。通过USB转422转换器与电脑相连，电脑上装有ComMonitor。运行系统，用ComMonitor分析XXX信息上传箱发送给VDR的串口数据的正确性。
4 定义
配置项测试：配置项测试是检验软件是否达到设备技术协议规定的软件功能、性能、接口、约束及限制等软件本身质量特性要求的测试。由第三方测试机构针对配置项进行的测试是确认测试，当由承制方完成该阶段的测试工作时，称其为配置项测试。
5 被测软件的等级
XX信息上传箱软件等级为D级。
6 正式合格性测试
6.1 进入条件
a. 本阶段必须具备的文档：
《XX系统软件软件设计说明书》；
《XX系统软件软件需求规格说明》；
《XX信息上传箱软件设计技术协议》；
《XX系统软件软件使用说明书》；
b. 本阶段应该输出的文档：
确认测试/配置项报告
软件测试计划
共9页 第 3 页
c.源程序、可执行代码；
d. 配置项已纳入配置管理中，提交的版本为通过出厂状态确认的版本； 完成软件配置项测试计划编制并通过评审；
6.2 测试项目及要求
6. 2.1 测试项目
配置项测试阶段应进行的测试项目见表6-1
表6 -1 配置项测试阶段测试项目表
6.2.2 总体测试要求
6.2.2.1 文档审查
a. 文档的完整性；
b. 文档的一致性；
c. 文档的准确性。
6.2.2.2 代码审查
软件测试计划
共9页 第 4 页
代码审查的技术要求见表6-2
表6-2 代码审查的技术要求
6.2.2.3 功能测试
a. 对软件需求规格说明中所规定的软件合格性项进行逐项测试，以验证其功能是否满足需求规格说明的要求；
b. 对软件配置项的控制流程的正确性、合理性等进行验证。
6.2.2.4 性能测试
软件测试计划
共9页 第 5 页
a. 软件配置项在获得定量结果时计算的精确性；
b. 有时间要求的软件配置项，应测试其时间特性及其实际运行时间； c. 软件配置项完成其功能所能处理的数据量；
d. 软件配置项各部分的协调性；
e. 软件需求规格说明中所要求的其它性能指标。
6.2.2.5 接口测试
a. 内部接口的正确性和协调性；
b. 外部接口的正确性和协调性。
6.2.2.6 边界测试
软件配置项在输入域(或输出域)、数据结构、状态转换、过程参数、功能界限等边界或端点情况下的运行状态。
6.2.2.7 人机界面测试
a. 操作和显示界面与软件需求规格说明的要求的一致性和符合性；
b. 人机界面在非常规操作、误操作、快速操作下的可靠性；
c. 对错误命令或非法数据输入的检测能力与提示情况；
d. 对错误操作流程的检测与提示；
e. 人机界面对所要求界面风格的一致性、友好性。
6.3 测试方法
6.3.1 文档审查
a. 文档完整性审查
——用人工审查的方法，按6.1（a） 确认测试要求，验证所提交软件文档是否齐套；
——文档中是否包含对软件接收输入数据类型和边界值的描述或说明，包括最大、最小值，键长，文件记录的最大长度，搜索准则最大值，最小样本尺寸；
——对不可能提供固定的边界值(例如，某些边界值依赖于应用类型或输入数据)的情况，是否说明极值；
——是否包含与保密信息有关的信息，应包括防止非法授权访问的措施说明。
软件测试计划
共9页 第 6 页
b. 文档的一致性审查
——用人工审查的方法，审查文档内容和术语的含义前后是否一致，有没有自相矛盾的地方；
——检查文档与程序的一致性；
——检查书面文档与联机帮助文档的一致性。
c. 文档的正确性审查
——用人工审查的方法，审查文档内容是否正确和准确；
——是否有错别字；
——是否有二义性的定义、术语或内容。
6.3.2 代码审查
软件测试人员根据表6-2 所示的审查项目和技术要求以及被测试软件特性，编制
代码审查单，对照代码审查单进行人工审查。
6.3.3 功能测试
a. 采用等价类划分和边界值分析的方法对软件需求规格说明中所规定的软件合格性项，设计并执行测试用例，以验证其功能是否满足需求规格说明的要求；
b. 基于上面的测试用例对软件配置项进行覆盖分析，以验证其控制流程的正确性、合理性。
6.3.4 性能测试
a. 设计可获得软件配置项定量结果的测试用例，执行这些测试用例来验证其计算的精确性；
b. 对于具有实时性要求的软件配置项，使用嵌入式开发环境中的实时调试工具或使用仿真器，来测试其实时任务或线程的时间特性及其实际运行时间；
c. 对于需要同时处理多个进程的软件配置项，应分析其并发处理能力； d. 通过对软件配置项进行大量输入/输出的数据结构(包括硬件I/O 端口、网络端口等)的性能监控，在饱和状态下统计出软件配置项完成其功能所能处理的数据量。输入数据的产生方式可以使用实际设备或信号仿真器，其信号源控制器应可以记录信号的发生时刻、结束时刻和信号值，将输入信号连接入软件配置项或数据处理设备，并启动数据处理功能(如滤波、平滑)，根据软件或信号分析仪
软件测试计划
共9页 第 7 页
比较输出信号，计算处理时间、时延、误差率等；
e. 应通过仿真器仿真动行找到软件配置项中的某些功能的不协调,找出影响软件配置项运行速度的主要原因。查看软件配置项各个部件的执行次序并计算其所占用的系统时间。通过过滤可以选择查看用户关心的模块执行情况而忽略其它模块。
6.3.5 接口测试
a. 采用仿真测试环境，设计软件配置项内部接口(未被测试的软部件间的接口)的测试用例，以验证其接口特性以及其接口的正确性和协调性；
b. 采用仿真测试环境，设计软件配置项外部接口(软件配置项、硬件配置项和其它系统的接口)的测试用例，以验证其接口特性及其接口的正确性和协调性；
c. 使用软部件间调用关系覆盖测试来确保内部接口测试的充分性。
6. 3.6 边界测试
设计和执行测试用例集，它应覆盖下列种类的边界或端点情况：
——输入域(或输出域)；
——数据结构；
——状态转换；
——过程参数；
——功能界限。
6.3.7 人机界面测试
人机界面测试应对照用户手册或操作手册逐条进行操作和观察来完成。 7 数据记录、整理和分析
每个测试项目测试完成后，都要填写测试记录表、测试用例表，并填写问题报告单，经过分析整理最终形成测试报告。
软件测试计划
共9页 第 8 页
附表-1 软件测试用例表 编号：
软件测试计划
共9页 第 9 页
第二篇：软件测试工程师工作总结
软件测试工程师的工作总结 我最初的时候，不知道什么是软件测试，集成测试和系统测试的概念经常混淆， CMM 是什么就更加不知道了。那时候最简单的开关机也是通过直接拔插电源完成，安装系统对我来说简直是有史以来人类的最高技能，对于那些拿着螺丝刀安装机器的人就认为是宇内超级高手，身具杀人于无形之绝世秘技。拿破仑说不想当将军的士兵不是好士兵，我最初的梦想就是想成为软件测试的高手，傲视天下。所以不断偷师，总结经验，自认为掌握了成为高手的几个秘技，这几年混迹 “ 江湖 “ 还算无往而不利。不敢独享，望与吾辈测试人员切磋，早日总结成功密技之大成，助新进人员早日入门，也算不愧对东北活雷锋的称号。 第一招 学会利用网络
刚参加工作面对浩瀚的网络世界，当时如刘姥姥进大观园，什么都新奇，什么都想要，从网上下载很多源程序的代码，软件技术文档之类，恨不得把所有的好东西收集到手中，其实有些在他人看起来就是垃圾一堆。当时觉得有了这些 “ 武林秘籍 “ ，成为高手指日可待。最初参加工作由于自己工作努力有幸转为开发，加入项目组后我的习惯还是没有改，反而变本加厉，手中的资源更加多，上网的时间更加频繁。
一次项目经理分配任务，觉得依靠手中的秘籍加上自己的 “ 聪明才智 “ 很快会完成，不料短短的时间，所有的一切变成了马奇诺防线。解决问题很慢，思路不清晰，项目经理在对我施压的过程中教会了我终身难忘的一招，学会利用网络寻找要解决问题的答案，从此 Google 成了我的最爱，关键字成了我变化的招数。在软件测试工作中，他帮我解决了很多疑难问题，解答了很多令我迷惑的地方。也是我帮助测试同行解决问题手段之一，很多软件测试新手，甚至老手都没有意识到自己手上就握有 “ 无敌秘籍 “ ，所以只要你耐心找，答案就在身边。
这里总结一下利用网络搜索引擎的技巧：
组合搜索
每次搜索某个文件，如果只给出一个单词进行搜索，经常会出现成千上百万计的匹配网页。然而如果再加上一个单词，那么搜索结果会更加切题。
选择表述内容的词组
一般我在网页搜索引擎的时候，选择一些可以表达我要查找内容的关键词组，用来缩小搜索范围，从而找到搜索结果是最好的办法。运用词组搜索涉可以先先简单地输入一个问题作为词组搜索，如果仍然找不到合适的，那就用多个可以表达要查询内容的关键字进行查询。
定位信息
有的时候用词组搜索不到或者无法准确表达所需信息。可以用另一种方法直接到信息源，就是直接到到提供某种信息的站点去。可以用公式 “www. 公司名 .com” 去猜测某一组织的特点。从而得到所要搜索的信息的主要词组
其实网络上还有很多关于搜索技巧的文章，大家可以自行学习。千万要记住搜索引擎是帮助你成功的有力武器。
第二招 学会动手
参加软件测试工作后，随着工作经验的增长自我感觉越来越好。在公司里也逐渐受到同事领导的重视，一次针对公司的新的软件功能进行测试的时候，像往常一样 “ 随手 “ 测试出了几个 Bug ，然后 “ 仔细 “ 的填写了 Bug 单（这个 Bug 的现象已经出现了很多次了）。这时候测试经理走过来，重新复查了一下填写的 Bug 。他在重现我的 bug 的过程中，简化了我的输入变化， bug 神奇的又出现了，同样的现象，他关闭软件重新变化输入，扩展出 10 几个变化后，软件不动了，内存不断上升。终于他找到了产生软件的 Bug 的原因，然后对我说 “ 寻找 Bug 要准确定位，我们开发团队是一个整体，时间是等量的，时间不在你身上浪费，就是在他身上浪费。如果测试人员每次发现的 bug 描述不清楚，并且
多个问题潜在的错误原因是一个，虽然操作可能稍微有些变化。这样开发人员在重现 bug 的时候他要调试跟踪判断，很花费时间，而且效率低。如果测试人员发现 bug 的时候多动手可以更加准确的定位 bug 步骤和原因，给开发人员最精确的步骤和准确的描述，这样整个团队才能高效，所以需要大家协作！。 “ 。
在以后的日子里，每次解决问题的时候我都记得多试验几次，多尝试。网上很多朋友还有同事问我问题的时候，其实他们只是万里长征就差一步，只要再多动手实验一次就可以达到目的了。所以多动手，多尝试。
第三招 思考自己所作的
刚开始入行的时候，总是思考如何做好软件测试。认为公司的测试流程混乱总是很郁闷，认为自己学不到东西，如何才能测试好产品，常说心动不如行动，以前看到古龙小说中经常出现的场景无名小子不断挑战高手，总结积累。我总结了有些经验是实战中得到的，所以不断尝试引入新的测试流程然后评估，这个过程虽然很痛苦，但是从中积累了不少经验。这段时间让我学习到了很多东西，接触了 ISO,CMM ，测试管理工具，自动化工具（因为公司不正规给了我很多学习的机会，后来到了比较大的软件公司后，以前的经历给了我更多的发展机会，因为大公司非常正规了，公司内部人员分工明确，所以能力的锻炼反倒少了）。由于工作中经常写报告反倒养成了总结教训的习惯，因为纸面上的东西是永远也忘不掉的。在写的过程中可以不断补充扩展，整个过程是思想升华的过程，当年达摩面壁九年就是融会贯通的典型例子，如果他不是有个思考的过程，他也不能成为一代大家。如果后来不时有人把他的绝技记录下来，也就不能有后来的少林寺七十二绝技。
所以善于思考，总结经验，也是成为高手之路的不二法决。
第四招 学会利用资源
其实测试新兵和测试高手之间的区别，往往是不会利用现有资源。在中我们会看到很多新手不断的提问，但是有很多问题其实都是已经别人提过了，或者已经有解决方案的。所以经常会看到 “测试高手“的身影，并且不提问题，而且还能“锄强扶弱“，是测试新丁的救命稻草。好像是高手们无所不能，其实摘掉这层耀眼的光环，他们并没想像得那么厉害，只不过通过自己的搜索找到的答案，然后帮助其他人。当然也有很多人都是通过自学，然后在中交流得到了很多经验，高手其实也是因为善于思考问题，亲自动手解决问题。所以动手和利用资源的过程中他们也在不断提高。
很多时候看到中有人提问，问题描述不清，很多人看了很困惑。发贴题目动不动请高手帮忙，救命之类的，好像天下大乱，世界末日。虽然这个题目很招人，但是无法让那些想帮助你的人帮你，因为题目不清晰，而且高手字样吓阻了很多人。其实问问题也是个思路整理的过程，描述清晰，让人理解清楚，才能望文知意知道你的当前发生问题的环境，才能让那些想帮你的人解决问题，否则给人无从下手的感觉，解决问题效率不高。
第五招 学习和你所测试的软件产品相关的知识
要想成为好的测试人员，还要了解你要测试的软件的相关知识。要了解软件产品的架构是什么样的。要了解软件的市场需求，在接触软件之初要可以多看看用户的反馈信息，这些才是用户最关心的，也是你在测试中需要注意的问题，满足客户是最大的需要。但是了解软件需求之后要学会要多读些软件系统的技术文档，软件设计文档，这些文档可以帮助你了解产品如何工作。还有多看看公司 Bug 库中的问题，这些存在的问题可以帮助你了解软件产品那些地方存在缺陷，软件系统那些地方会出现错误。软件是运行在一个大环境中，如果对系统不熟悉，那么有些问题你不能从一个更广阔的层面考虑，学习操作系统的知识，有助于你发现缺陷，定位问题更加准确。比如软件运行在 Windows 或者 Linux ，如果你不懂操作系统，你就无法建立测试环境，有些时候时候软件的组件发生问题，就是你系统配置造成的，对系统不熟悉，你会把外在原因归结为软件本身。所以要学习关于和软件系统相关的知
识，比如编程，网络，数据库等。不一定你要学习到多好的程度，只是通过这些扩展的知识面，你可以在发现问题，解决问题上不会局限在狭小的圈子里。
和一切相关的人员交流，不同的交流渠道，获取消息是不同的，角度也不同。和客户交流，你会在测试中从客户的角度发现问题；和开发人员交流，你会了解开发人员怎么实现软件功能的；和项目管理人员交流，你会知道开发进度以及遇到的困难。