《软件测试计划.doc》由会员分享，可在线阅读，更多相关《软件测试计划.doc（11页珍藏版）》请在金锄头文库上搜索。
1、叮叮小文库测试计划产品名称：OA系统仓储模块项目承担部门撰写人（签名）完成日期本文档使用部门评审负责人（签名）评审日期版本日期版本说明作者目 录 1.概述.11.1产品简介11.2范围11.3限制条件11.4参考文档12.约定22.1测试目标22.2接收标准22.3资源和工具22.3.1资源22.3.2工具22.4送测要求22.5编号规则23.测试种类及测试标准33.1测试种类33.2测试方法及标准33.2.1功能测试33.2.2业务测试33.2.3压力测试33.2.4安装测试33.2.5验收测试34.测试重点及顺序44.1预测风险44.2测试重点44.2.1功能测试44.2.2业务测试45.
2、暂停标准和再启动要求56.测试任务和进度67.测试提交物7-叮叮小文库1. 概述1.1 产品简介本模块完全适合普通物流中心仓储信息管理的软件。能实现入库、出库、盘点和库存控制等仓储的智能化管理，可以提高库存管理的效率。同时通过入库单、出库单、盘点单等各种单据使物主能够浏览自己的货物情况。1.2 范围本测试计划是针对OA系统仓储模块中规定内容的测试计划，包括：1.3 限制条件本测试计划受限于产品开发人员提交测试的内容和时间的事实。根据开发人员提交模块的实际情况，本计划会做出相应修改。1.4 参考文档 序号名称作者备注1.可行性分析(研究)报告(FAR)2.软件开发计划(SDP)3.软件(结构)设
3、计说明(SDD)4.系统(子系统)设计(结构设计)说明(SSDD)5.仓储模块逻辑模型6.查询模块详细设计说明7.仓库总系统图8.仓库管理信息系统详细设计说明9.登陆界面逻辑详细设计说明10.数据库顶层详细设计说明11.入库模块详细设计说明12.SQL语句细设计说明13.转仓详细设计说明14.盘点详细设计说明15.E-R图16.数据流图17.数据表详细设计说明15.实体及其属性设计说明2. 约定2.1 测试目标通过测试，达到以下目标： 测试已实现的产品是否达到设计的要求，包括：各个功能点是否以实现，业务流程是否正确。 产品规定的操作和运行稳定。 Bug数和缺陷率控制在可接收的范围之内。2.2
4、接收标准本节所述的接收标准是指可测试的标准，这个标准以测试组接收测试为限。单元测试接收标准的详细规定参见文档 OA系统仓储模块测试接收标准.doc。其余各阶段接收标准，以经过审核后的上一阶段测试报告为准，每一阶段停止标准的详细规定参见文档软件测试停止标准.doc。2.3 资源和工具2.3.1 资源 测试服务器稳定的测试服务器，IP地址为:192.168.43.80。 人员测试审核人1名，测试实施人员1 名。2.3.2 工具 测试中使用的Bug管理工具为经过改进的Bug管理工具。 自动化测试工具待定。2.4 送测要求OA系统仓储模块开发人员提交的测试按以下要求进行：步骤动作负责人相关文档或记录要
5、求1打包、编译开发人员无确认可测试2审核并提交测试Xx经审核的上一级测试报告测试报告xx审核并签字3接收测试测试人员经xx审核并签字的上一级测试报告4开始测试测试人员Bug单、小结测试小结个人编写个人的内容2.5 编号规则与本测试计划相关的编号规则如下： 测试用例中的编号，功能名+界面名(每个字第一个汉语拼音大写)+编号例如：查询库存第一个用例CXKC 0001 测试用例文件命命名规则，模块名+测试用例例如：查询模块查询模块测试用例3. 测试种类及测试标准3.1 测试种类计划完成以下类型测试 功能测试 业务测试 压力测试 安装测试 验收测试3.2 测试方法及标准3.2.1 功能测试3.2.1.
6、1 功能系统能按照设计要求实现模块的各个功能，数据应完整、界面美观、操作方便。具体可参照本文档测试重点及顺序部分。3.2.1.2 界面测试 详细的界面测试可以参考界面测试.doc。3.2.1.3 数据项测试 字母数字数据项是否能够正确回显，并输入到系统中？ 图形模式的数据项（如滑动条）是否正常工作？ 是否能够识别非法数据？ 数据输入消息是否可理解？3.2.1.4 帮助文档测试 文档是否精确描述了如何使用各种使用模式？ 交互顺序的描述是否精确？ 例子是否精确？ 术语、菜单描述和系统响应是否与实际程序一致？ 是否能够很方便地在文档中定位指南？ 是否能够很方便地使用文档排除错误？ 文档的内容和索引是
7、否精确完整？ 文档的设计（布局、缩进和图形）是否便于信息的理解？ 显示给用户的错误信息是否有更详细的文档解释？ 如果使用超级链接，超级链接是否精确完整？3.2.2 业务测试功能测试完成后进行业务测试，业务测试关注的要点是业务流程，及数据流从软件中的一个模块流到数据库的过程中的正确性。业务测试的方法及标准参考业务测试用例.doc。3.2.3 压力测试3.2.3.1 压力测试说明本次压力测试根据实际情况包含性能测试，重点模拟用户进行多用户测试。压力测试有一条8：2原则。及百分之八十的业务量在百分之二十的时间内输入。例如:正常每天有100条新数据，测试时在两小时内输入80条数据。我们无法知道用户的业
8、务量，所以只有利用公司现有资源进行大量的数据量的测试。3.2.3.2 压力测试工具待定3.2.3.3 压力测试方法及标准压力测试的方法及标准参考压力测试计划.doc3.2.4 安装测试3.2.4.1 安装测试说明除了嵌入式软件之外，安装是软件产品实现其功能的第一步，没有正确的安装根本就谈不上正确的执行，因此对于安装的测试就显得尤为重要。3.2.4.2 安装测试方法及标准 自动安装还是手工配置安装，测试各种不同的安装组合，并验证各种不同组 合的正确性，最终目标是所有组合都能安装成功。 安装退出之后，确认应用程序可以正确启动、运行。 卸载测试和安装测试同样重要，如果系统提供自动卸载工具，那么卸载之
9、后需检验系统是否把所有的文件全部删除，注册表中有关的注册信息是否也被删除。 至少要在一台笔记本上进行安装测试，因为有很多产品在笔记本中会出现问题，尤其是系统级的产品。(有条件的情况下) 安装完成之后，可以在简单地使用之后再执行卸载操作，有的系统在使用之后会发生变化，变得不可卸载。 安装时间是否合理； 对于客户服务器模式的应用系统，可以先安装客户端，然后安装服务器端，测试是否会出现问题。 考察安装该系统是否对其他的应用程序造成影响，特别是Windows操作系统，经常会出现此类的问题。3.2.5 验收测试3.2.5.1 验收测试说明软件产品测试部对经过内部单元测试、集成测试和系统测试后的软件所进行
10、的测试，测试用例采用业务流程测试用例。3.2.5.2 验收测试方法及标准 参考 OA系统仓储模块验收测试规范.doc和软件测试停止标准.doc4. 测试重点及顺序4.1 预测风险本次测试过程中，可能出现的风险如下： bug的修复情况 模块功能的实现情况 系统整体功能的实现情况 代码的编写质量 人员经验以及对软件的熟悉度 开发人员、测试人员关于项目约定的执行情况 人员调整导致研发周期延迟 开发时间的缩短导致某些测试计划无法执行4.2 测试重点4.2.1 功能测试这里仅为测试重点的描述，具体测试方法以及内容请参见测试用例。4.2.1.1 查询方案 是否使用查询料号实现 查找数据 查询条件为空，点击
11、查询件 查询结果与数据库对照4.2.1.2 入库/出库修改 出入库成功返回界面 增、删、改功能是否已经实现 出入库成功前后数据库对照4.2.1.3 盘点功能 捞出的数据是否正确 能否打印盘点单4.2.1.4 管理员功能 能否实现架位修改 能否查看用户操作时间和动作 能否实现和用户相同的功能4.2.1.5 个人中心待定4.2.1.6 用户注册能否成功添加新用户并添加权限4.2.2 系统测试这里只是描述了系统测试的大概情况，具体测试方法以及内容请参见系统测试用例。这里的系统测试包含模块之间的关系。4.2.2.1 数据库连接情况 正常情况，数据库文件缺少，外部系统异常4.2.2.2 对用户输入的响应
12、 正确输入，能够正常调用子模块4.2.2.3 输入错误 系统能否辨别，并做出响应(提出警告)；4.2.2.4 数据库操作 数据库连接正常、数据库连接异常。4.2.2.5 数据库连接正常 输入合理合法参数、不输入参数5. 暂停标准和再启动要求 软件系统在进行单元、集成、确认、系统、安装、验收测试时，发现一级错误（大于等于1）、二级错误（大于等于2）暂停测试返回开发。 软件项目需暂停以进行调整时，测试应随之暂停，并备份暂停点数据。 软件项目在其开发生命周期内出现重大估算，进度偏差，需暂停或终止时，测试应随之暂停或终止，并备份暂停或终止点数据。 如有新的项目需求，则在原测试计划下做相应的调整。 若开
13、发暂停，则相应测试也暂停，并备份暂停点数据。 若项目中止，则对已完成的测试工作做测试活动总结。 项目再启动时，测试进度重新安排或顺延。6. 测试任务和进度测试阶段测试任务工作量估计人员分配起止时间第一阶段单元测试添加用户。按物资编号。查询按物资名称查询。更改架位。捞出的数据。出入库10日陈斌待定打印表单1. 打印出入库单2. 打印盘点单陈斌待定单元测试BUG审核陈斌待定第二阶段集成测试1. 添加用户。按物资编号。查询按物资名称查询。更改架位。捞出的数据。出入库2. 打印表单 陈斌待定第四阶段性能测试性能测试1日陈斌待定第五阶段帮助和用户手册测试1. 帮助测试2. 用户手册测试1日陈斌待定第六阶段审核BUG审核单元测试以外的BUG1日陈斌待定
