软件检验测试方案计划V0Word格式.docx
《软件检验测试方案计划V0Word格式.docx》由会员分享，可在线阅读，更多相关《软件检验测试方案计划V0Word格式.docx（16页珍藏版）》请在冰豆网上搜索。
2.2软件配置9
2.3测试数据9
3测试策略9...
3.1.1功能测试9
3.1.2用户界面（UI）测试9
3.1.3性能测试10
3.1.4安全性测试10
3.1.5兼容性测试11
3.1.6回归测试11
3.2测试实施阶段11
4测试通过标准1..2.
5测试用例模板1..2.
测试用例是根据软件需求得出的功能描述，用尽可能少的测试用例覆盖尽可能多的功
能，避免冗余。
12
6测试bug提交与管理12
测试如果有错误就需要提交bug，bug更需要通过管理维护来观察测试进度，直至bug跟踪完成。
错误!
未定义书签。
使用QC软件来提交与管理bug。
错误!
1概述
软件的错误是不可避免的，所以必须经过严格的测试。
通过对本软件的测试，尽可能的发现软件中的错误，借以减少系统内部各模块的逻辑，功能上的缺陷和错误，保证每个单元能正确地实现其预期的功能。
检测和排除子系统（或系统）结构或相应程序结构上的错误，使所有的系统单元配合合适，整体的性能和功能完整。
并且使组装好的软件的功能与用户要求一致。
1.1软件测试流程实施方案
从一个软件企业的长远发展来看，如果要提高产品的质量首先应当从流程抓起，规范软件产品的开发过程。
按照流程进行开发可以使得我们少走弯路，并有效的提高产品质量，提高用户的满意度。
1.2软件测试流程图
1.2.1测试工作总体流程图
说明：
集成测试和系统测试的反馈意见可能导致设计文档（需求或数据库）的修改
122计划、用例阶段流程图
项目经理
测试经理
测试工程师
评审委员会
时间
立项
项目总体计划
需要完成的功能
《需求说明
书》
J设计说明书
测试计划
用户业务要求
功能实现
评审
NO
测试用例
是否符合要
、一求
一评L•是否符合要
求
NC
段阶例用'
划计'
求需
进入单元/集成测
试阶段
YES
123单元/集成测试阶段流程图
开发工程师
测试工程师评审委员会
需求计
划阶段
结束
编写/修改测试
代码
测试申请
执行预测试（编码审核）
评审是否达
到可进行测
■试的标准，
T
执行单元/集成测试
（使用测试用例）
测试缺陷记录—单、Bug报告
是否达到要
段阶试测成^L元单
测试报告
进入系统测试
阶段
段阶试测统系
退回项目经理
或挂起
YES
卜是否初测
复查BUG
检查文档/编写
YES问题需要挂起
或重测
审验测试环境
编写补充测
试用例
系统测试
Not
是否复查
例覆盖率评审
125验收测试流程图
验收测试为系统上线前的最后检验，检验方向主要是安装包、安装程序、用户手册、加密设置、基本功能等内容。
完成
使用手册
O
审验测试环
境
是否达到验
收要求
加密测试
段阶试测收验
提交验收测试报告、安装包、手册
验收测试结束
2测试资源和环境
2.1硬件配置
关键项
数量
性能要求
期望到位阶段
测试PC机
1
P4,主频2.6GHZ，硬盘300G，内存2G，此配置是实际用机
需求分析阶段
数据库服务器
P4,主频2.6GHZ，硬盘300G,
内存2G,此配置是实际用机
2.2软件配置
资源名称/类型
配置
操作系统环境：
操作系统主要分为windowsXP，windows7。
其中windowsXP和windows7是重点测试对象
浏览器环境：
主流浏览器有：
IE浏览器（IE8/9）。
此测试根据开发提供依据决定测试范围
功能性测试工具
手工测试
测试管理工具
Bugfree
2.3测试数据
本方案的测试数据来源于测试需求及测试用例。
（测试数据可以是开发给出，也可以是测试工程师整理）
3测试策略
系统测试类型及各种测试类型所采用的方法、工具等介绍如下：
3.1.1功能测试
测试范围
验证数据精确度、数据类型、业务功能等相关方面的正确性
测试目标
核实所有功能均已正常实现，即是否与需求一致
技术
采用黑盒测试、边界测试、等价类划分等测试方法
工具与方法
开始标准
开发阶段对应的功能完成并且测试用例设计完成
完成标准
测试用例通过并且最高级缺陷全部解决
需考虑的特殊事项
3.1.2用户界面（UI）测试
1•导航、链接、Cookie、页面结构包括菜单、背景、颜色、字体、按钮名称、TITLE、提示信息的一致性等。
2.友好性、可操作性（易用性）
核实各个窗口风格（包括颜色、字体、提示信息、图标、TITLE
等等）都与需求保持一致，或符合可接受标准，能够保证用户界面的友好性、易操作性，而且符合用户操作习惯。
技术
WEB测试通用方法
手工测试、目测
界面开发完成
UI符合可接受标准，能够保证用户界面的友好性、易操作性，而且符合用户操作习惯
测试重点与优先级
3.1.3性能测试
多用户长时间在线操作时性能方面的测试
核实系统在大流量的数据与多用户操作时软件性能的稳定性，不造成系统崩溃或相关的异常现象
手工测试、自动化测试（loadrunner）
自动化测试脚本设计并评审通过且项目组移交系统测试
系统满足用户需求中所要求的性能要求
3.1.4安全性测试
1.用户、管理员的密码安全
2.权限
3.非法攻击
1.用户、管理员的密码管理
2•应用程序级别的安全性：
核实用户只能操作其所拥有权限能操作的功能。
3•系统级别的安全性：
核实只有具备系统访问权限的用户才能访问系统。
代码包或者非法攻击工具
功能测试完成
执行各种非法操作无安全漏洞且系统使用正常
3.1.5兼容性测试
1•使用不同版本的不同浏览器、分辨率、操作系统分别进行测试。
2•不同操作系统、浏览器、分辨率和各种运行软件等各种条件的组合测试。
核实系统在不同的软件和硬件配置中运行稳定
黑盒测试
项目组移交系统测试
在各种不冋版本不冋类项浏览器、操作系统或者其组合下均能正常实现其功能（此测试根据开发提供依据决定测试范围）
3.1.6回归测试
所有功能、用户界面、兼容性、安全性等测试类型
核实执行所有测试类型后功能、性能等均达到用户需求所要求的标准
手工测试和自动化测试（QT见附件《QTP教程（入门到高
级）》）
每当被测试的软件或其环境改变时在每个合适的测试阶段上进行回归测试
95%的测试用例执行通过并通过系统测试
测试优先级以测试需求的优先级为参照
软硬件设备问题
3.2测试实施阶段
功能测试
X
?
性能测试
安全性测试
兼容性测试
用户界面（UI）测试
回归测试
每当被测试的软件或其环境改变时在每个合适的测试阶段上进行回归测试
备注：
“？
”表示由测试组执行，“X”表示由项目组执行；
4测试通过标准
系统无业务逻辑错误和二级的BUG经确定的所有缺陷都已得到了商定的解决结果。
所设
计的测试用例已全部重新执行，已知的所有缺陷都已按照商定的方式进行了处理，而且没有发现新的缺陷。
注：
缺陷的严重等级说明：
A:
严重影响系统运行的错误；
B:
功能方面一般缺陷，影响系统运行；
C:
不影响运行但必须修改；
D:
合理化建议。
5测试用例模板
测试用例是根据软件需求得出的功能描述，用尽可能少的测试用例覆盖尽可能多的功能，避免冗余。
6测试bug提交与管理
测试如果有错误就需要提交bug，bug更需要通过管理维护来观察测试进度，直至bug跟踪完
成。
使用QC软件来提交与管理bug
提交bug也需要按照一定格式，方便开发能够清晰的知道bug出在了哪里，以便维护。
案例：
测试文档模板
见附件《测试文档模板V1.0》
升级会员 