软件测试计划文档（初）
软件测试计划文档
1.引言
1.1 编写目的
满足大学生选课需求，解决选课难的问题
1.2 项目背景
如今，网上选课已成为大学生必经之路，但是普通的官方系统难以满足大学生需求，我们拟在大学内推广该软件以解决大学选课难的问题
1.3 术语定义
Ad hoc testing（随机测试），没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行用例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。
Alpha testing （α测试），是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。
Automated Testing（自动化测试），使用自动化测试工具来进行测试，这类测试一般不需要人干预，通常在GUI、性能等测试中用得较多。
Beta testing（β测试），测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。
Black box testing（黑盒测试），指测试人员不关心程序具体如何实现的一种测试方法。根据软件的规格对软件进行各种输入和观察软件的各种输出结果来发现软件的缺陷的测试，这类测试不考虑软件内部的运作原理，因此软件对用户来说就像一个黑盒子。
Bug (错误)，有时称作defect（缺陷）或error（错误），软件程序中存在的编程错误，可能会带来不必要的副作用，软件的功能和特性与设计规格说明书或用户需求不一致的方面。软件缺陷表现特征为：软件未达到产品说明书标明的功能；软件出现产品说明书指明不会出现的错误；软件功能超出产品说明书指明的范围；虽然产品说明书未指出但是软件应达到的目标；软件测试人员或用户认为软件难以理解，不易使用，运行速度缓慢等问题。
Bug report（错误报告），也称为“Bug record（错误记录）”，记录发现的软件错误信息的文档，通常包括错误描述、复现步骤、抓取的错误图像和注释等。
Build（工作版本），软件开发过程中用于内部测试的功能和性能等不完善的软件版本。工作版本既可以是系统的可操作版本，也可以是展示要在最终产品中提供的部分功能的部分系统。
Compatibility Testing（兼容性测试），也称“Configuration testing（配置测试）”，测试软件是否和系统的其它与之交互的元素之间兼容，如：浏览器、操作系统、硬件等。验证测试对象在不同的软件和硬件配置中的运行情况。
Crash（崩溃），计算机系统或组件突然并完全的丧失功能，例如软件或系统突然退出或没有任何反应（死机）。
Debug（调试），开发人员确定引起错误的根本原因和确定可能的修复措施的过程。一般发生在子系统或单元模块编码完成时，或者根据测试错误报告指出错误以后，开发人员需要执行调试过程来解决已存在的错误。
Performance testing（性能测试），评价一个产品或组件与性能需求是否符合的测试。包括负载测试、强度测试、数据库容量测试、基准测试等类型。
Regression testing（回归测试），在发生修改之后重新测试先前的测试以保证修改的正确性。理论上，对软件的任何新版本，都需要进行回归测试，验证以前发现和修复的错误是否在新软件版本上再现。
Software life cycle（软件生命周期），开始于一个软件产品的构思，结束于该产品不再被使用的这段期间。
Static testing（静态测试），不通过执行来测试一个系统。如代码检查，文档检查和评审等。
User interface testing （用户界面测试），指测试用户界面的风格是否满足客户要求，文字是否正确，页面是否美观，文字，图片组合是否完美，操作是否友好等等。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。
1.4 参考资料
<<软件工程方法与实践>>
<<软件工程实验教程>>
<<数据库系统概论>>
<<Qt 快速入门>>
2.任务概述
2.1 目标
主要目标:能够与官方选课系统对接,帮助大学生选课
覆盖范围：大学校内，用户拟定为在校大学生
验收标准：可完成选课并实现数据共享即可验收
2.2 测试环境
硬件环境：PC机
软件环境：eclipse SDK，SQL server
2.3 需求分析
2.3.1 数据需求
2.3.2 事务需求
2.4 条件与限制
硬件设备：
CPU Core i3-2100及以上
内存 2GB DDR3-160及以上
外存 120/128GB SATA3.0及以上
软件系统保证：安装eclipse SDK、JavaServlet
人员齐备：全员到齐
时间限制：一周
3.计划
3.1 测试方案
主要内容是需求，分析，设计，实现。
3.2测试项目
●功能测试
在线选课：利用鼠标和键盘实现选择需要的课程
在线退课：利用鼠标和键盘退掉已选课程
●回归测试
定义
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
意义
1.避免在回归测试中应各种操作误差所引起的测试结果异常。
2.可以保持和原始测试一直性。
3.可以提高测试效率。
4.测试经理可以更好的掌握测试存在的问题
●界面测试
1. 简介说明 说明文字是否合理，位置 ，是否正确。
2. 背景/色调 是否正确、美观、，是否符合用户需求
3. 登录界面是否正常，能否正常登录
4. 能否正常选课和退选
5. 测试登录后能否正常退出
6. 页面元素的容错性列表
7. 页面元素清单（为实现功能、是否将所需要的元素全部都列出来，如按钮，单选框，复选框，列表框，超链框，输入框等等）。
8. 页面元素的容错性是否存在。
●负载测试
通过增加并发用户数和（或）事务数量来测量组件或系统能够承受的负载。
●文档测试
1. 测试方案（主要设计怎么测试什么内容和采用什么样的方法，经过分析，在这里可以得到相应的测试用列表）
2. 测试执行策略（可以主要包括哪些可以先测试，哪些可以放在一起测试之类的），
3. 测试用例(主要根据测试用例列表，写出每一个用例的操作步骤和紧急程度，和预置结果)，
4. BUG描述报告(主要可以包括，测试环境的介绍，预置条件，测试人员，问题重现的操作步骤和当时测试的现场信息)，
5. 整个项目的测试报告(从设计和执行的角度上来对此项目测试情况的介绍，从分析中总结此次设计和执行做的好的地方和需要努力的地方和对此项目的一个质量评价)。
3.3 测试准备
3.3.1. 测试计算机，是相对比较“干净”的。 因为测试都是有风险的，有的时候会导致蓝屏，计算机重新启动，优势时候则要求更换操作系统。
3.3.2. 功能测试环境 和 性能测试环境 要分开。 性能测试是持续的，有的用例要一次运行十几天，只有单独的性能测试环境才能满足这个要求。
3.3.3 提前准备好软件和硬件。
3.3.4 测试支持平台。 测试用例管理程序，bug管理程序，测试报告生成程序。
3.3.5 把搭建测试环境时遇到的问题和相应的解决办法记录下来。
3.4 测试机构及人员
测试机构人员组成：罗骁，曾理，曾正旗，施宏飞，聂良疆
测试文档书写：施宏飞，聂良疆
软件运行人员：罗骁，曾理
软件完善人员：曾正旗
4.测试项目说明
4.1 测试项目名称及测试内容
|
测试项目名称 |
测试内容 |
|
登录功能 |
用户能否正常输入用户名、密码和正常登录 |
|
选课功能 |
用户能否正常选课 |
|
退课功能 |
用户能否对已选课程进行退课 |
|
查看功能 |
用户能否查看已选课程和自己的选课之前和之后课表 |
4.2 测试用例
|
用例编号 |
输入数据 |
预期的输出结果 |
|
SL1 |
用户未输入用户名或密码 |
界面提示“请输入完整信息！”。 |
|
SL2 |
用户输入错误用户名 |
界面提示“用户名不存在！”。 |
|
SL3 |
用户输入错误密码 |
界面提示“密码不正确！”。 |
|
SL4 |
用户在主界面点击选课按钮 |
用户进入选课界面，并能看到当前可选课程。 |
|
SL5 |
用户在选课界面中点击课程 |
界面弹出小窗口，显示该课程的信息，包括上课时间、上课地点、上课老师和已选人数。 |
|
SL6 |
用户在选课界面中点击与上课时间不冲突的课程后选课按钮 |
界面弹出“成功选课！”，并在课表中加入已选课程 |
|
SL7 |
用户在选课界面中点击与上课时间冲突的课程后选课按钮 |
界面弹出“与上课时间冲突！” |
|
SL8 |
用户点击选课界面的返回按钮 |
返回主界面。 |
|
SL9 |
用户在主界面点击退课按钮 |
用户进入退课界面，并能看到已选课程，若没有已选课程，则界面提示“没有已选课程！” |
|
SL10 |
用户在退课界面点击退课按钮 |
界面弹出小窗口：是否退课？ |
|
SL11 |
点击退课界面小窗口中确定按钮 |
退课界面删除该课程，在课表中删除该课程，在选课界面中添加该课程。 |
|
SL12 |
点击退课界面的返回按钮 |
返回主界面 |
|
SL13 |
在主界面中点击查看按钮 |
进入课表界面，显示当前该用户课表。 |
|
SL14 |
在课表界面中点击课程 |
界面弹出小窗口，显示该课程的信息，包括上课时间、上课地点和上课老师。 |
|
SL15 |
点击主界面注销按钮 |
用户退出系统，进入登录界面。 |
4.3 进度
小组成员全体参与每个测试用例。
4.4 条件
硬件条件：正常可运行电脑，键盘鼠标。
软件条件：Eclipse软件和SQLserver软件。
人员条件：全体小组成员。
4.5 测试资料
[1]计算机软件测试文档编制规范GB/T 9386-2008.
[2]窦万峰.软件工程方法与实践[M].北京：机械工业出版社，2009.
5.评价
5.1 准则
质量准则：错误率在1%左右，点击按钮系统反应时间不超过0.5秒。
覆盖准则：用例覆盖度99%。
5.2 结束标准
各个用例预期结果和实际结果一致。
集成测试文档
1.简介
1.1 目的
本文档用于描述辅助选课系统集成测试所要遵循的规范以及确定测试方法、测试环境、测试用例的编写和测试整个进度的计划安排、人力资源安排等。
测试目的：集成测试目的是测试组成辅助选课系统的各个子模块间的接口及功能实现等。
1.2 背景
面对当前大学生选课时遇到选课时间慢、选的课程不满意等问题，我们团队准备开发出一个辅助选课系统，以帮助学生更好地选课。
1.3 范围
需要集成的模块为登录模块、选课模块、退课模块和查看模块。
1.4 参考文档
[1]计算机软件测试文档编制规范GB/T 9386-2008.
[2]窦万峰.软件工程方法与实践[M].北京：机械工业出版社，2009.
2.测试约束
2.1 测试进出条件
2.1.1 进入条件
程序能够成功运行并显示系统登录界面
2.1.2 退出条件
致命和严重级别缺陷清除率达到100%，致命和严重级别缺陷修复率达到100%，一般缺陷的遗留个数小于等于2个。
2.2 测试通过和失败准则
输入测试用例后的结果与预期结果相近或者相同，测试即为成功，否则测试失败。
2.3 测试启动/结束/暂停/再启动准则
2.3.1 测试启动准则
程序运行成功，能够输入测试用例。
2.3.2 测试结束准则
当对程序的各个功能都进行覆盖测试并成功修复错误以后退出测试。
2.3.3 测试暂停/再启动准则
当测试过程中出现致命、严重以及一般级别缺陷后，测试工作需要暂停，当修复致命、严重以及一般级别缺陷后再重新启动测试工作。
3.测试需求
需求功能点：用户登录，选课，退课，显示功能
接口：硬件接口，以及人际交互接口。
4.测试风险
不可抗力因素：应及时保存程序的代码，做好文档的整理工作。
测试环境风险：弄清楚测试环境和生产环境配置，测试环境交叉影响较大，尽量增多测试环境数据量。
回归测试风险：回归测试一般时间相对来说较少，应该尽量测试多的回归功能点，防止漏测；另外还有减少回归验证缺陷时业务流走不通导致的打回修复再验证造成的时间延后问题。
5.集成策略
采用自下而上的集成顺序，先将个模块实现的功能进行测试，在集成后对整体功能进行测试，集成环境为Eclipse开发环境。
6.集成计划
小组成员前期先将个模块的功能实现比测试，中后期将各个模块之间的关系整理好，在集成环境下将各个功能模块进行整合并测试最终的功能。
7测试策略
7.1 策略描述
先对最底层的各个小功能测试，然后逐层上升，将出现集成，直到实现最终的预期功能
7.2 测试类型
●功能测试：登录功能：预期结果：当出现运行成功后输入用户名和密码，登录成功显示选课系统的菜单；用户名不存在显示“用户名不存在，请重新输入”，密码不正确显示“密码不正确，请重新输入“。
测试结果：
选课功能：预期结果：登录成功后点击“选课”按钮，显示选课界面，在选择合适的课程后点击课程后面的选课按钮，选课成功显示“选课成功”；选课人数达到上限显示“人数已到上限，请重新选择”。
测试结果：
退课功能：预期结果：选课成功后点击“退课”按钮，显示退课界面，选择想要退掉的课程后点击课程后面的退课按钮，退课成功显示“退课成功”。
测试结果：
显示功能：预期结果：登录成功后点击“我的课程”按钮，显示该用户的所以课程。
测试结果：
●接口测试：硬件接口：键盘和鼠标点击是否有效果
软件接口：
●容错测试:暂无
●回归测试:暂无
