Documentation: Software Test Plan Documentation
This document is written by the rubyirubiangong project team. Any copying or use of all or part of the content of this article must first seek the consent of the team, thank you.
- introduction
1.1 Purpose of writing
The purpose of writing this test plan is to:
(1) Provide guidance for the management and technical work of the entire testing phase, determine the content and scope of the test, and provide a basis for the evaluation system;
(2) In addition, help arrange testing activities, and explain the need for resources;
(3) Describe the evaluation indicators of the test results.
The main contents of this document include:
(1) Introduction to the test system
(2) Test method
(3) Test standard
(4) Test plan
The intended readers of this document are:
(1) Developer
(2) Project managers
(3) Testers
1.2 Project Background
Project name: rub it.
Project proponent: An unnamed Nuan Lai Chuang group from Huazhong Agricultural University.
Development unit: School of Information, Huazhong Agricultural University.
User: All school students.
Project implementation unit: An unnamed Nuan Lai Nuan group of Huazhong Agricultural University.
Relationship with other systems: This system operates independently.
1.3 Definition of terms
The projects, products, software, etc. mentioned in this test plan document all refer to the course design work of this group - the APP.
1.4 References
Dou Wanfeng et al. Software Engineering Methods and Practice [M]. Beijing: Machinery Industry Press, 2016.
2. Mission overview
2.1 Goals
Coverage of this test:
(1) Random Course Search Module
(2) Bulletin board module
(3) Community module
(4) My module
Through the test, the following goals are achieved:
(1) Test whether the realized project meets the design requirements. Specifically, it includes: whether each function has been implemented, and whether the process of each function is correct.
(2) The specified operation and operation of the product are stable.
(3) The number of bugs and defect rate are controlled within an acceptable range.
Acceptance criteria for this system:
After executing all system functional tests and performance test use cases, there are no major problems that cause the system to fail to run. System testing is terminated if there are serious quality issues that prevent it from continuing and cannot be repaired within an acceptable time frame.
2.2 Test environment
Hardware Environment: Appropriate hardware environment.
Software Environment: A suitable software environment, compatible with the developed project.
2.3 Overview of Requirements
2.3.1 Data Requirements
Internal data:
The internal data structures and types of this system have been defined by the data dictionary, which are listed in the following table:
| data item name |
code |
type of data |
Data length |
Ranges |
| User code |
Uid |
Varchar (11) |
11 |
Legal phone number |
| message |
MicroBlog |
Varchar(256) |
256 |
|
| User's Nickname |
Uname |
VarChar(10) |
10 |
|
| User department |
Uposition |
VarChar(10) |
10 |
|
| local year |
Year |
int (4) |
4 |
2018~2028 |
| local month |
Month |
int (2) |
2 |
1~12 |
| local day |
Day |
int (2) |
2 |
1~31 |
| local hour |
Hours |
int (2) |
2 |
00~23 |
| local minute |
Minutes |
int (2) |
2 |
00~59 |
| local seconds |
Seconds |
int(2) |
2 |
00~59 |
| Course Title |
Cname |
VarChar(24) |
24 |
|
| Course No |
Cnumber |
VarChar(10) |
10 |
|
| Course type |
Ctype |
VarChar(14) |
14 |
|
| Start academy |
College |
VarChar(16) |
16 |
|
| Instructor |
Cteacher |
VarChar(8) |
8 |
|
| class time |
Ctime |
VarChar(40) |
40 |
|
| class locations |
Cplace |
VarChar(20) |
20 |
|
| credit |
Credit |
Float(2) |
2 |
0.5-6 |
| semester |
Semester |
VarChar(11) |
11 |
|
| User verification code |
Password |
VarChar (6) |
6 |
000000---999999 |
| Preferred Course Semester |
BECAUSE |
VarChar(11) |
11 |
|
| Preferred course name |
KCname |
VarChar (24) |
24 |
|
| Preferred course number |
KCdm |
VarChar (10) |
10 |
3000000000--3999999999 |
| Preferred Course Credits |
XF |
Float(2) |
2 |
0.5---6 |
| Preferred course type |
KCLB |
VarChar(14) |
14 |
|
| Preferred college |
KSXY |
VarChar (16) |
16 |
|
| Preferred course teacher name |
Tname |
VarChar (8) |
8 |
|
| Preferred course location |
SKDD |
VarChar(20) |
20 |
|
| Preferred course time |
SKSJ |
VarChar(40) |
40 |
|
| Textbook name |
Bookname |
VarChar (20) |
20 |
|
The internal data of this project should be organized according to the above data dictionary. The storage format and access format of external data are determined with reference to internal data.
2.3.2 Transaction Requirements
The test process and processing requirements are carried out according to the following table
| step |
action |
| 1 |
Package and compile the test case. |
| 2 |
Review the test cases and finally submit the test. |
| 3 |
Receive the test. |
| 4 |
start testing. |
Work to be prepared:
(1) A consensus is reached within the group on the testing work.
(2) Set up the corresponding test tools and debug the test tools into a working state.
（3） 准备好相关文档以供参考和查阅。
2.4条件与限制
条件：
（1） 硬件设备：合适的硬件设备和当前市面上主流的Android机型设备，如华为、vivo、oppo、荣耀、中兴等。
（2） 软件系统保证：将需要使用到的调试软件等准备好。
（3） 人员齐备：小组全体成员在场。
（4） 配合：定制好各类预案应对突发情况。
（5） 内部协调：分工明确并相互配合。
限制：
（1） 资金限制：小组资金有限，主要通过学院机房提供的资源开展测试工作。
（2） 时间限制：课程设计时间有限，需要尽快完成测试工作。
（3） 环境限制：测试主要在学院机房开展。
3.计划
3.1测试方案
测试策略：黑盒测试。
测试过程：确认测试，针对可以实现的功能设计相关用例进行测试。
测试内容：app的所有功能。
测试技术：包括等价类划分，边界值分析，错误推测和因果图等方法。
技术标准：完成所有功能的测试
3.2测试项目
功能测试：
课程搜索：
(1)根据课程名称搜索得到课程
(2)根据上课老师名字搜索得到课程
(3)根据上课时间搜索得到课程
(4)根据用户的需要
公告板：
(1)用户根据自己的需要进入相关的网址页面
社区：
(1)用户发表自己的想法
(2)用户浏览其他人的发言
我的：
(1)查看自己的账号信息
(2)查看自己喜欢的课程的上课时间，上课地点，任课老师等信息。
回归测试：
如果在功能测试过程中发现了系统的缺陷，则进行及时修正，每次修正后，再对发现的缺陷进行验证，确保其得以改正。在系统交付前做一次完整的系统回归测试。
界面测试：
对界面的完整性，正确性，操作性和友好性进行测试。
负载测试：
测试app的并发访问性能，即同时多个用户安装使用此app；还有就是大规模数据访问效率，即多用户使用时的速度问题。
文档测试：
对需求分析文档进行测试，测试重点在文档内容的正确性，准确性。主要采用走查的方式进行。
3.3测试准备
在测试前，与各模块的主要负责人进行共同协商讨论；阅读软件需求分析说明书，并以此作为总的提纲；选择合适的输入输出数据；编写测试用例。
3.4测试机构及人员
小组全体成员。
4 测试项目说明
本部分是测试项目的情况说明，包括测试项目定义、测试用例编写和操作步骤、测试进度安排及参考资料等
4.1 测试项目名称及测试内容
对每个测试项目定义合适的名称和测试内容
4.2 测试用例
编写测试用例，包括用例编号、输入数据、预期的输出结果等。
| 测试用例编号 |
Test_001 |
| 测试项目 |
用户登录 |
| 测试标题 |
输入不合法手机号 |
| 重要级别 |
高 |
| 预置条件 |
系统安装好本app，并在联网的情况下成功打开 |
| 输入 |
00000000000 |
| 操作步骤 |
①输入不合法手机号 ②选择发送验证码 |
| 预期输出 |
系统提示该手机号不存在（不合法） |
| 测试用例编号 |
Test_002 |
| 测试项目 |
用户登录 |
| 测试标题 |
输入合法手机号并成功登陆 |
| 重要级别 |
高 |
| 预置条件 |
系统安装好本app，并在联网的情况下成功打开 |
| 输入 |
15071264651 |
| 操作步骤 |
①输入合法手机号 ②选择发送验证码 |
| 预期输出 |
系统进入搜索主页面，用户可自由操作 |
| 测试用例编号 |
Test_003 |
| 测试项目 |
通过课程名称搜索 |
| 测试标题 |
在搜索页面，输入合法课程名称，并选择按课程搜索 |
| 重要级别 |
高 |
| 预置条件 |
系统安装好本app，并在联网的情况下成功打开，合法用户 |
| 输入 |
软件工程A |
| 操作步骤 |
①用户在搜索页面输入该课程名 ②选择按课程搜索 |
| 预期输出 |
显示软件工程A的相关信息 |
| 测试用例编号 |
Test_004 |
| 测试项目 |
通过任课老师名字搜索 |
| 测试标题 |
在搜索页面，输入合法老师名字，并选择按任课老师名字搜索 |
| 重要级别 |
高 |
| 预置条件 |
系统安装好本app，并在联网的情况下成功打开，合法用户 |
| 输入 |
XX |
| 操作步骤 |
①用户在搜索页面输入该老师名 ②选择按任课老师搜索 |
| 预期输出 |
显示老师XX的所带课程的相关信息 |
| 测试用例编号 |
Test_005 |
| 测试项目 |
通过上课时间名字搜索 |
| 测试标题 |
在搜索页面，输入合法上课时间，并选择按上课时间搜索 |
| 重要级别 |
高 |
| 预置条件 |
系统安装好本app，并在联网的情况下成功打开，合法用户 |
| 输入 |
星期一上午一二节 |
| 操作步骤 |
①用户在搜索页面输入该上课时间 ②选择按上课时间搜索 |
| 预期输出 |
显示该时间的所有课程的相关信息 |
| 测试用例编号 |
Test_005 |
| 测试项目 |
通过上课时间名字搜索 |
| 测试标题 |
在搜索页面，输入合法上课时间，并选择按上课时间搜索 |
| 重要级别 |
高 |
| 预置条件 |
系统安装好本app，并在联网的情况下成功打开，合法用户 |
| 输入 |
星期一上午一二节 |
| 操作步骤 |
①用户在搜索页面输入该上课时间 ②选择按上课时间搜索 |
| 预期输出 |
显示该时间的所有课程的相关信息 |
| 测试用例编号 |
Test_006 |
| 测试项目 |
通过上课时间名字搜索 |
| 测试标题 |
在搜索页面，输入任课老师，并选择按上课时间搜索 |
| 重要级别 |
高 |
| 预置条件 |
系统安装好本app，并在联网的情况下成功打开，合法用户 |
| 输入 |
XX |
| 操作步骤 |
① 用户在搜索页面输入任课老师相关信息 ②选择按上课时间搜索 |
| 预期输出 |
显示输入不正确 |
| 测试用例编号 |
Test_007 |
| 测试项目 |
通过按课程搜索 |
| 测试标题 |
在搜索页面，输入不存在的课程，并选择按课程搜索 |
| 重要级别 |
高 |
| 预置条件 |
系统安装好本app，并在联网的情况下成功打开，合法用户 |
| 输入 |
XXXXX |
| 操作步骤 |
①用户在搜索页面输入不存在的课程 ②选择按课程搜索 |
| 预期输出 |
显示输入不正确 |
| 测试用例编号 |
Test_008 |
| 测试项目 |
通过公告板页面跳转教务处网站 |
| 测试标题 |
在公告板页面，点击教务处按钮 |
| 重要级别 |
高 |
| 预置条件 |
系统安装好本app，并在联网的情况下成功打开，合法用户 |
| 输入 |
无 |
| 操作步骤 |
①用户选择公告板页面 ②选择教务处按钮 |
| 预期输出 |
成功跳转教务处按钮 |
| 测试用例编号 |
Test_009 |
| 测试项目 |
通过公告板页面跳转教务处网站 |
| 测试标题 |
在公告板页面，点击教务处按钮 |
| 重要级别 |
高 |
| 预置条件 |
系统安装好本app，并在不联网的情况下成功打开，合法用户 |
| 输入 |
无 |
| 操作步骤 |
① 用户选择公告板页面 ②选择教务处按钮 |
| 预期输出 |
系统提示未连接互联网 |
| 测试用例编号 |
Test_010 |
| 测试项目 |
通过社区页面发言 |
| 测试标题 |
在社区页面，输入一定文字，选择发表 |
| 重要级别 |
高 |
| 预置条件 |
系统安装好本app，并在联网的情况下成功打开，合法用户 |
| 输入 |
无 |
| 操作步骤 |
① 用户选择社区页面 ②在发言框输入一定文字③选择发表 |
| 预期输出 |
成功提交该发言 |
| 测试用例编号 |
Test_011 |
| 测试项目 |
通过社区页面发言 |
| 测试标题 |
在社区页面，输入一定文字，选择发表 |
| 重要级别 |
高 |
| 预置条件 |
系统安装好本app，并在未联网的情况下成功打开，合法用户 |
| 输入 |
无 |
| 操作步骤 |
①用户选择社区页面 ②在发言框输入一定文字③选择发表 |
| 预期输出 |
系统提示未连接互联网 |
| 测试用例编号 |
Test_012 |
| 测试项目 |
通过社区页面查看发言 |
| 测试标题 |
在社区页面，查看已有发言 |
| 重要级别 |
高 |
| 预置条件 |
系统安装好本app，并在联网的情况下成功打开，合法用户 |
| 输入 |
无 |
| 操作步骤 |
① 用户选择社区页面 ②浏览社区页面其他发言 |
| 预期输出 |
当前已存在的发言 |
| 测试用例编号 |
Test_013 |
| 测试项目 |
通过我的页面修改自己个人信息 |
| 测试标题 |
在我的页面，修改或查看自己个人信息 |
| 重要级别 |
高 |
| 预置条件 |
系统安装好本app，并在联网的情况下成功打开，合法用户 |
| 输入 |
无 |
| 操作步骤 |
① 用户选择我的页面 ②浏览个人信息 ③编辑个人信息 ④保存个人信息 |
| 预期输出 |
个人信息修改成功 |
| 测试用例编号 |
Test_014 |
| 测试项目 |
通过我的页面查看个人偏好课程 |
| 测试标题 |
在我的页面，查看自己个人偏好课程信息 |
| 重要级别 |
高 |
| 预置条件 |
系统安装好本app，并在联网的情况下成功打开，合法用户 |
| 输入 |
无 |
| 操作步骤 |
① 用户选择我的页面 ②浏览个人偏好 |
| 预期输出 |
显示当前搜索（标记过的）相关课程信息 |
4.2.1 输入
每个测试用例的输入数据格式、顺序及输入方式
4.2.2 输出
每个用例预期的输出结果
4.2.3 步骤及操作
每个测试项的操作步骤，以及每个用例的操作过程和要求等
4.2.3 允许偏差
允许的结果偏差范围
4.3 进度
制定每个测试项目的进度安排和人员安排：测试人员为小组全部成员，进度按具体编码而定。
4.4 条件
针对每个测试项目，确定需要的硬件条件只需要安装了该app的安卓手机，或者通过电脑虚拟完成。
4.5 测试资料
测试需要参考的相关资料、文档及规范，见第一部分参考资料。
5.评价
5.1准则
质量准则：错误率尽可能低，效率尽可能高，具有可靠性。
覆盖准则：用例的覆盖度要高。
5.2结束标准
以错误率为结束标准，错误率要达到某一要求。
本文档由蹭一蹭软工项目小组撰写，任何复制、使用本文的全部或部分内容的行为必须先征求小组同意，谢谢。