软件测试计划书

文档标识：2010091601 学生信息管理系统 软件测试计划书 编 写 者 macrobutton nomacro macrobutton nomacro macrobutton nomacro 李宝刚 校 对 李宝刚 小组成员 李宝刚 孔维一 李宇杰 二O一O年七月 目录 11. 引言 11.1.目的 11.2.背景 11.3.范围 11.4.定义 11.5.参考资料 12. 测试内容 23. 测试规则 23.1.进入准则 23.2.暂停/退出准则 23.3.测试方法 33.4.测试手段 33.5.测试要点 43.6.测试工具 44. 测试环境 44.1.硬件环境 44.2.软件环境 44.3.安全性环境要求 45. 项目任务 45.1.测试规划 45.2.测试设计 55.3.测试执行准备 65.4.测试执行 75.5. 测试总结 86. 实施计划 86.1.工作量估计 86.2.人员需求及安排 86.3.进度安排 96.4.其他资源需求及安排 96.5.可交付工件 97. 风险管理 1. 引言 1.1.目的 随着学校规模不断扩大,学生数量急剧增加，有关学生的信息量也成倍增长，面对庞大的信息量需要有学生管理系统来提高学生管理工作的效率。本系统主要用于学校学生信息管理，总体任务是实现学生信息关系的系统化、 规范 编程规范下载gsp规范下载钢格栅规范下载警徽规范下载建设厅规范下载 化、自动化，其主要任务是用计算机对学生各种信息进行日常管理，如查询、修改、增加、删除，另外还考虑到学生选课，针对了这些要求设计了学生信息管理系统。 1.2.背景 在高校，计算机应用的非常普遍，在这种实用的学生信息管理系统可以使局面得到改观。学生信息管理系统主要提供了方便高校的管理功能以及网上信息的查阅平台，学生可以通过该系统查询相关信息，管理员可以管理信息，本系统主要功能有： 1． 学生管理功能：为了方便学生信息的增加、删除、修改、查询。 2． 课程管理功能：管理员可以通过填写表格的形式修改课程等相关信息。 3． 成绩管理功能：管理员可以通过数据库中的学生成绩信息进行增加、修改。 4． 班级管理功能：管理员可以通过此功能对班级信息进行增加、删除、修改、查询。 5． 用户管理功能：可以增加、删除、修改、查看该程序的用户登录，超级管理员可以设置用户的权限。 1.3.范围 本学生信息管理系统主要应用在各个学校为了方便管理学生信息而成。 主要设计人员由在校学生以及老师组成。 测试风险有可能软件应用过程中出现一些错误或者故障。 时间进度：2010-7 ---- 1.4.定义 学生管理系统 信息管理 数据库 软件测试 1.5.参考资料 列出编写本计划及测试整个过程中所要参考的文件、资料。 编号 资料名称 作者 日期 出版单位 1 《软件测试自动化》 邓波 黄丽娟 曹青春 1987 机械工业出版社 2 《有效软件测试》 Elfriede Dustin 1990 清华大学出版社 3 《软件测试》 周予滨 姚静 1996 机械工业出版社 列出编写本计划时需查阅的Intenet上杂志、专业著作、技术标准。 查阅内容 网点地址 简介 软件测试 http://www.china-pub.com/16822&ref=ps 软件测试入门 软件测试教程 http://www.bookschina.com/1117943.htm 教你如何学会软件测试 2. 测试内容 下表列出了学生信息管理系统项目的测试需求，并对其进行了优先级定义： 子系统名称 模块名称 测试点 优先级 说明 学生信息管理系统 学生信息管理模块 数据输入是否正常 H 实现增、删、改、查 数据输入是否正常 H 实现增、删、改、查 数据输入是否正常 H 实现增、删、改、查 查询系统模块 数据连接是否正常 H 连接正常 数据库管理系统 数据连接是否正常 H 连接正常 用户管理系统 登入是否正常 H 连接正常 连接是否正常 H 连接正常 3. 测试规则 3.1.进入准则 一个软件要想进去准备阶段首先要达到一下三个阶段： A．需求工件已经被基线化 B．详细设计工件已经被基线化 C．构架工件已经被基线化 3.2.暂停/退出准则 3.2.1 集成测试退出标准 1) 集成测试用例设计已经通过评审 2) 所有源代码和可执行代码已经建立受控基线，纳入[url=javascript:;]配置管理[/url] 受控库，不经过审批不能随意更改 3) 按照集成构件计划及增量集成策略完成了整个系统的集成测试 4) 达到了测试计划中关于集成测试所规定的覆盖率的要求 5) 集成工作版本满足设计定义的各项功能、性能要求 6) 在集成测试中发现的错误已经得到修改，各级缺陷修复率达到标准 7) A、B类BUG不能存在 8) C、D类BUG允许存在,但不能超过单元测试总BUG的50％ 9) E类BUG允许存在 3.2.2 系统测试退出标准 1) 系统测试用例设计已经通过评审 2) 按照系统测试计划完成了系统测试 3) 系统测试的功能覆盖率达100％ 4) 系统的功能和性能满足产品需求规格说明书的要求 5) 在系统测试中发现的错误已经得到修改并且各级缺陷修复率达到标准 6) 系统测试后不存在A、B、C类缺陷 7) D类缺陷允许存在，不超过总缺陷的5％ 8) E类缺陷允许存在，不超过总缺陷的10％ 3.3.测试方法 单元测试：纯代码的测试（白盒测试）。主要测试代码语句的正确性，如所有的代码是否都可以跑到，是否有冗余的代码等等。 集成测试：接口测试（灰盒测试，结合白盒和黑盒测试）。主要测试代码块之间的接口。看看数据的传输是否有问题。 系统测试：黑盒测试。不接触代码，只对整个系统做功能的测试和性能的测试。 确认测试：是客户做的测试。也可以叫做验收测试。客户对他提出的需求，对应要交付的软件看看是否达到其要求。 3.4.测试手段 3.4.1手工测试 就是由人去一个一个的输入用例，然后观察结果，和机器测试相对应，属于比较原始但是必须的一个步骤。 在测试过程中，手工测试的比重一般在30%左右。手工测试一般能够发现一些自动化测试所不能发现的问题，这也是为什么自动化测试取代不了手工测试的原因！ 3.4.2自动测试 对程序的回归测试更方便。这可能是自动化测试最主要的任务，特别是在程序修改比较频繁时，效果是非常明显的。由于回归测试的动作和用例是完全设计好的，测试期望的结果也是完全可以预料的，将回归测试自动运行，可以极大提高测试效率，缩短回归测试时间。 3.5.测试要点 3.5.1[测试思想] 质量意识（责任）：站在客户的立场 好奇心（动力）：探索所有的功能，深入理解系统内核 进攻（激情）：多角度发现所有可能的问题，测试和开发之间是进攻和防守的关系 帮助（沟通）：以帮助而不是找茬的心态与开发团队一起分析问题，协同工作 3.5.2[测试 工程 路基工程安全技术交底工程项目施工成本控制工程量增项单年度零星工程技术标正投影法基本原理 ] 测试目的：尽可能多地发现缺陷 测试阶段：测试计划、测试需求、测试设计、测试执行、测试报告 测试用例设计：测试环境，测试数据，执行步骤，期望结果 缺陷跟踪：提交、分派、修复、验证、审计；回归测试； 测试结束准则：严重缺陷数在一定范围内、测试用例执行完毕、或规定时间到（取决于项目/组织质量要求） 测试人员考核：没有可靠的定量指标（比如不能拿缺陷数来做） 3.5.3[测试技术] 单元测试，模块测试，产品测试，集成测试，系统测试，用户验收测试 功能测试，性能测试，压力测试，冒烟测试，猴子测试 内部测试，外部测试（客户试用） 白盒测试，黑盒测试 3.6.测试工具 软件测试方面的工具很多，主要有MercuryInteractive（MI）、Segue、Rational、 Compuware和Empirix等等 4. 测试环境 4.1.硬件环境 就是指由传播活动所需要的那些物质条件、有形条件之和构筑而成的环境。 4.2.软件环境 就是指运行于计算机硬件之上的驱动计算机及其外围设备实现某种目的的软件系统。如测试软件等 4.3.安全性环境要求 必须在无病毒，无入侵的环境下进行测试。 5. 项目任务 5.1.测试规划 学生信息管理系统是一个典型的数据库应用程序,由班级管理、学生档案管理、学生交费管理、课程管理、成绩管理等模块组成,特规划如下: 5.1.1系统管理模块 该模块的主要任务是维护系统的正常运行和安全性设置,包括添加用户、修改密码、重新登录等等。 5.1.2班级管理模块 该模块的功能是实现对全校班级的管理工作，包括：班级游览、班级添加、班级查询等，这三个功能模块各自独立，完成学校的全部班级的管理。 5.1.3学生档案管理模块 该模块的主要功能是实现对学生的个人信息的管理工作，包括档案添加、档案浏览、档案查询等功能，从而方便学校管理部门对学校的基本情况的快速查询和了解。 5.1.4课程管理模块 该模块对各个班级的课程进行设置，并可在其中设置各门课程的教材选用情况，方便了学校教材管理部门和教务处的教学管理人员的工作。该模块包括基本课程设计和班级课程设置两个模块。 5.1.5成绩管理模块 学校的成绩管理工作是检验学生学习情况的一个主要手段，本模块包括考试类型设置，共有期中考试和期未考试两种类型，还设置了成绩添加、成绩游览、成绩查询等功能模块。 5.2.测试设计 5.2.1.  测试 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 设计 　　测试方案的设计要除了要明确定义各个测试活动的对象、执行人员、测试进度、放行标准等一系列属性外，还要充分考虑到成本与技术可行性。一个好的测试方案总是遵循着以下设计原则：(1) 测试成本与测试工作产生的效益处于最佳比值；（2）各具体测试活动描述清晰，目标明确，内容完备；（3）测试手段是可行的；（4）测试产生的结果是可以用于指导产品质量改进的。笔者注意到一些企业对于第（3）点存在认识上的误区，盲目购置的一批自动化测试工具，却无人懂操作，或者根本就不适合自己的开发环境。这些问题在测试方案设计过程中应该努力避免的。 　　在进行测试方案的具体设计时，常常也暴露出来一些难题和障碍。最常见的就是角色安排多，测试人员少。解决这一问题的根本途径是招募测试人才，建设高效测试团队。然而，远水解不了近渴。如果你的测试团队遭遇到此类尴尬，那么，你就需要考虑一下变通之策：前面提到的外包和外协都是不错的处理办法。另外，建议你适当考虑自动测试工具，某些工具的确能减少你的工作压力（如自动集成工具能实现每日建构、压力测试工具能缓解你编写模拟并发程序的压力）。除了人手的问题，了解你所在的测试团队各成员的专业技能也是很重要的。有些项目测试方案设计得很好，但由于缺乏相应素质的测试团队成员担当测试方案中的相应角色，测试方案只能无限期搁浅，结果不了了之。除此之外，测试方案设计人员还应多多参考软件开发管理类文档，在测试的时间进度安排上与开发保持同步，如果开发进度有变动，应及时调整相应的测试进度安排。 5.2.2.  测试用例设计 测试用例设计是对测试方案实现技术部分更为细致描述，相关设计技术已经相对成熟[注：目前测试用例设计的某些分支仍是研究热点。市面上，关于测试用例的理论著作也是琳琅满目。下表列出了各类测试用例设计技术，在本文中笔者不打算一一介绍，而是根据测试实践和个人取向，选出了几个有代表性的方法，供读者参考。有兴趣的读者，可以进一步查阅论述更细致一些的书籍。 5.3.测试执行准备 按照开发阶段划分，软件测试可分为单元测试、集成测试，系统测试和验收测试。 单元测试：针对每个单元的测试， 以确保每个模块能正常工作为目标。 集成测试：对已测试过的模块进行组装，进行集成测试。目的在于检验与软件设计相关的程序结构问题。 确认（有效性）测试：是检验所开发的软件能否满足所有功能和性能需求的最后手段。有的划分方法中，也将确认测试合并入系统测试中。 系统测试：检验软件产品能否与系统的其他部分（比如，硬件、数据库及操作人员）协调工作。 验收（用户）测试：检验软件产品质量的最后一道工序。主要突出用户的作用，同时软件开发人员也应有一定程度的参与。 验收测试可以分成Alpha测试和Beta测试。 Alpha测试是由用户在开发环境下完成的测试，Beta测试是由用户在用户环境下完成的测试。 如果一个软件的做成了，那么首先应该进行单元测试，查看每个单元是否出现错误或者发生故障，如果出现了错误或者故障，那样该及时处理和改正，之后再进行测试，就这样每个部分进行一次小测试，如果都正常的话，就可以进行，系统测试和验收测试。 5.4.测试执行 软件测试就是利用测试工具按照测试方案和流程对产品进行功能和性能测试，甚至根据需要编写不同的测试工具，设计和维护测试系统，对测试方案可能出现的问题进行分析和评估。执行测试用例后，需要跟踪故障，以确保开发的产品适合需求。 1.在单元测试中，测试者需要依据详细设计说明书和源程序清单，了解该模块的I/O条件和模块的逻辑结构，主要采用白盒测试的测试用例，辅之以黑盒测试的测试用例，使之对任何合理的输入和不合理的输入，都能鉴别和响应。 　(1) 模块接口测试　　 * 在单元测试的开始，应对通过被测模块的数据流进行测试。测试项目包括： 　　– 调用本模块的输入参数是否正确； 　　– 本模块调用子模块时输入给子模块的参数是否正确； 　　– 全局量的定义在各模块中是否一致； 　　* 在做内外存交换时要考虑： 　　– 文件属性是否正确； 　　– OPEN与CLOSE语句是否正确； 　　– 缓冲区容量与 记录 混凝土 养护记录下载土方回填监理旁站记录免费下载集备记录下载集备记录下载集备记录下载 长度是否匹配； 　　– 在进行读写操作之前是否打开了文件； 　　– 在结束文件处理时是否关闭了文件； 　　– 正文书写／输入错误， 　　– I／O错误是否检查并做了处理。 　(2) 局部数据结构测试 　　* 不正确或不一致的数据类型说明 　　* 使用尚未赋值或尚未初始化的变量 　　* 错误的初始值或错误的缺省值 　　* 变量名拼写错或书写错 　　* 不一致的数据类型 　　* 全局数据对模块的影响 　(3) 路径测试 　　* 选择适当的测试用例，对模块中重要的执行路径进行测试。 　　* 应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。 　　* 对基本执行路径和循环进行测试可以发现大量的路径错误。 　(4) 错误处理测试 　　* 出错的描述是否难以理解 　　* 出错的描述是否能够对错误定位 　　* 显示的错误与实际的错误是否相符 　　* 对错误条件的处理正确与否 　　* 在对错误进行处理之前，错误条件是否已经引起系统的干预等 　(5) 边界测试 　　* 注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例，认真加以测试。 　　* 如果对模块运行时间有要求的话，还要专门进行关键路径测试，以确定最坏情况下和平均意义下影响模块运行时间的因素。 2.还要进行有效的测试如黑盒测试： * 有效性测试是在模拟的环境 (可能就是开发的环境) 下，运用黑盒测试的方法，验证被测软件是否满足需求规格说明书列出的需求。 　　* 首先制定测试计划，规定要做测试的种类。还需要制定一组测试步骤，描述具体的测试用例。 　　* 通过实施预定的测试计划和测试步骤，确定 　　– 软件的特性是否与需求相符； 　　– 所有的文档都是正确且便于使用； 　　– 同时，对其它软件需求，例如可移植性、兼容性、出错自动恢复、可维护性等，也都要进行测试 　　* 在全部软件测试的测试用例运行完后，所有的测试结果可以分为两类： 　　– 测试结果与预期的结果相符。这说明软件的这部分功能或性能特征与需求规格说明书相符合，从而这部分程序被接受。 　　– 测试结果与预期的结果不符。这说明软件的这部分功能或性能特征与需求规格说明不一致，因此要为它提交一份问题报告。 3. 软件配置复查 软件配置复查的目的是保证 　　软件配置的所有成分都齐全； 　　各方面的质量都符合要求； 　　具有维护阶段所必需的细节； 　　而且已经编排好分类的目录。 　　应当严格遵守用户手册和操作手册中规定的使用步骤，以便检查这些文档资料的完整性和正确性。 验收测试（Acceptance Testing） 　　* 在通过了系统的有效性测试及软件配置审查之后，就应开始系统的验收测试。 　　* 验收测试是以用户为主的测试。软件开发人员和QA（质量保证）人员也应参加。 　　* 由用户参加设计测试用例，使用生产中的实际数据进行测试。 　　* 在测试过程中，除了考虑软件的功能和性能外，还应对软件的可移植性、兼容性、可维护性、错误的恢复功能等进行确认。 5.5.测试总结 随着软件产业的发展，软件产品的质量控制与质量管理正逐渐成为软件企业生存与发展的核心。几乎每个大中型IT企业的软件产品在发布前都需要大量的质量控制、测试和文档工作，而这些工作必须依靠拥有娴熟技术的专业软件人才来完成。软件测试工程师就是这样的一个企业重头角色。业内人士分析，该类职位的需求主要集中在沿海发达城市，其中北京和上海的需求量分别占去33%和29%。民企需求量最大，占19%，外商独资欧美类企业需求排列第二，占15%。然而，目前的现状是：一方面企业对高质量的测试工程师需求量越来越大越大，另一方面国内原来对测试工程师的职业重视程度不够，使许多人不了解测试工程师具体是从事什么工作。这使得许多IT公司只能通过在实际工作中进行淘汰的方式对测试工程师进行筛选，因此国内在短期将出现测试工程师严重短缺的现象。根据对近期网络招聘IT人才情况的了解，许多正在招聘软件测试工程师的企业很少能够在招聘会上顺利招到合适的人才。在具体工作过程中，测试工程师的工作是利用测试工具按照测试方案和流程对产品进行功能和性能测试，甚至根据需要编写不同的测试用例，设计和维护测试系统，对测试方案可能出现的问题进行分析和评估。对软件测试工程师而言，必须具有高度的工作责任心和自信心。任何严格的测试必须是一种实事求是的测试，因为它关系到一个产品的质量问题，而测试工程师则是产品出货前的把关人，所以，没有专业的技术水准是无法胜任这项工作的。同时，由于测试工作一般由多个测试工程师共同完成，并且测试部门一般要与其他部门的人员进行较多的沟通，所以要求测试工程师不但要有较强的技术能力而且要有较强的沟通能力。 所以这次软件测试不仅仅锻炼我们的技术能力，还要培养我们的沟通能力，只有这样我们才能有机会被一些知名企业所用。 6. 实施计划 6.1.工作量估计 根据工作内容和项目任务对包括测试设计的工作量、测试执行和测试总结的工作量，以人月或人日计， 并详细注释测试设计、测试执行和测试总结工作所占的比重。软件测试工作量应为开发工作量的30%-40%为宜。 工作阶段 所需工作日 占项目的比例 测试规划阶段 5天 20% 测试设计阶段 7天 30% 测试实施阶段 7天 30% 测试执行阶段 3天 15% 测试总结阶段 2天 5% 6.2.人员需求及安排 下表列出了在此测试活动的人员安排： 角色 人员 具体职责/备注 测试经理 杨建国 负责监督其他人员工作及处理事项 测试设计 杨建国 负责软件开发的测试程序 测试人员 杨建国 负责测试软件的可实用性 6.3.进度安排 下表列出了测试的时间安排： 项目里程碑 开始时间 结束时间 输出要求/备注 测试规划 2010.07.10 2010.07.15 完成测试准备阶段 测试设计 2010.07.16 2010.07.23 需要完成测试的设计阶段 测试设计实施 2010.07.24 2010.07.31 按照测试的设计进行实施 测试执行 2010.08.01 2010.08.03 开始进行测试的执行阶段 测试总结 2010.08.04 2010.08.06 测试总结阶段 6.4.其他资源需求及安排 软件测试安排如下： 1.软件开发人员即程序员应当避免测试自己的程序，不管是程序员还是开发小组都应当避免测试自己的程序或者本组开发的功能模版。若条件允许，应当由独立于开发组和客户的第三方测试组或测试机构来进行软件测试。但这并不是说程序员不能测试自己的程序，而且更加鼓励程序员进行调试，因为测试由别人来进行可能会会更加有效、客观，并且容易成功，而允许程序员自己调试也会更加有效和针对性。 2.应尽早地和不断地进行软件测试，应当把软件测试贯穿到整个软件开发的过程中，而不应该把软件测试看作是其过程中的一个独立阶段。因为在软件开发的每一环节都有可能产生意想不到的问题，其影响因素有很多，比如软件本身的抽象性和复杂性、软件所涉及问题的复杂性、软件开发各个阶段工作的多样性，以及各层次工作人员的配合关系等。所以要坚持软件开发各阶段的技术评审，把错误克服在早期，从而减少成本，提高软件质量。 3.对测试用例要有正确的态度：第一，测试用例应当由测试输入数据和预期输出结果这两部分组成；第二，在设计测试用例时，不仅要考虑合理的输入条件，更要注意不合理的输入条件。因为软件投入实际运行中，往往不遵守正常的使用方法，却进行了一些甚至大量的意外输入导致软件一时半时不能做出适当的反应，就很容易产生一系列的问题，轻则输出错误的结果，重则瘫痪失效！因此常用一些不合理的输入条件来发现更多的鲜为人知的软件缺陷。 4.人以群分，物以类聚，软件测试也不例外，一定要充分注意软件测试中的群集现象，也可以认为是“80-20原则”。不要以为发现几个错误并且解决这些问题之后，就不需要测试了。反而这里是错误群集的地方，对这段程序要重点测试，以提高测试投资的效益。 5.严格执行测试计划，排除测试的随意性，以避免发生疏漏或者重复无效的工作。 　　6.应当对每一个测试结果进行全面检查。一定要全面地、仔细地检查测试结果，但常常被人们忽略，导致许多错误被遗漏。 　　7.妥善保存测试用例、测试计划、测试报告和最终分析报告，以备回归测试及维护之用。 在遵守以上原则的基础上进行软件测试，可以以最少的时间和人力找出软件中的各种缺陷，从而达到保证软件质量的目的。 6.5.可交付工件 确认测试应交付的文档有： 　　– 确认测试分析报告 　　– 最终的用户手册和操作手册 – 项目开发总结报告。 7.风险管理 本章详细描述本次测试所面临的风险（如人力资源风险、测试技术风险、测试资源风险、质量保证风险等）及相应的建议解决办法。 下表是一些具有共性的软件项目风险的清单， 以供参考： 风险 种类 描述 没 没有详细设计说明书 设计方面 分析业务逻辑，在不清楚的地方及时与开发人员沟通 统一的界面设计不规范 设计方面 与项目负责人确认测试标准 需求变更开发 开发方面 建议将需求变更形成文档，对没有文档的需求变更 人力资源 测试本身 保证稳定的人员安排 硬件资源 测试本身 事先分析测试所需硬件资源，及时申请，保证测试工作顺利进行 版本控制 测试本身 严格控制版本，BUG以版本为单位进行提交 测试时间不足 测试本身 动员测试人员完成测试任务，必要时，应给予相应物质奖励 下表列出了一些风险的分析表。分析表必须按影响的程度来排序。实践中，必须参照项目过程的、开发组的、以及公司的详细具体的情况来制定。并且，随着时间的推移和环境的变化，必须随时更新风险的分析。 风险 发生的可能性 负面影响 没有详细设计说明书 与开发人员沟通不清楚 设计说明书说明不清晰 统一的界面设计不规范 没有确认测试标准 导致测试失败 人力资源 人员不稳定 软件测试完成不及时 测试时间不足 人员太少 没有完成软件测试 版本控制 控制版本不正确 软件测试失败 硬件资源 没有事先分析需求什么硬件 不能及时完成软件测试 1