2023年7月6日发(作者：)

火车票订购系统需求分析

1.1 系统任务概述

这里将该系统的应用是学生在线订购火车票系统，主要涉及对列车信息的管理、学生信息的管理和学生订票信息的管理：

对列车信息的管理：对列车信息的添加、修改、删除和查询等

对学生信息的管理：对学生信息的添加、修改、删除、查询等

对订票信息的管理：对订票信息的管理，如：何人，何时订了何票等。

此外，对于每个使用该系统的人，都要实现用户名和密码登陆，只有合法的用户才能使用该系统。

1.2 功能需求

1.2.1 学生的管理

每个通过资格审查的人都注册，并拥有自己的用户名和密码，成为注册用户，以后凭此登陆系统；不能通过审查的人员则不予办理。

每个注册用户都拥有一个账号，此账号里包含该用户的所有个人信息，每次的订票活动都凭借此账号进行，直到该账号被注销或删除为止。

因此，对学生的管理包含对学生相关信息的添加、修改、删除及检索功能。

1.2.2 列车信息管理

列车信息的管理中很大一部分就是对车次信息的管理，主要涉及以下功能：

新列车车次入库：对次新的列车车次信息，都将其详细信息加以记录，方可对外订购和查询

列车信息的检索：要想从上千条列车信息记录中找到需要的车次，必须提供列车车次的快速检索和查询功能。

信息的修改：列车的基本信息（如车次号、车次时间、单价等）是不需提供修改功能的，但其它一些信息（是否打折、席别、票价、张数等）需要有修改功能。

列车信息的删除：对过时的列车信息要能够从系统信息中删除。

1.2.3 订票信息管理

这是火车订票系统的核心功能之一，由系统管理员实现，主要涉及订票的车次的基本信息、学生的部分信息，订购日期及归订购张数等。

订票时：审查学生是否有订票权；检查列车信息信息是否可以被订购；两者都满足后才能办理订票手续。

取票时：获取学生信息和列车车次信息，判断订票时间是否超期，若超期则不予订购，只有在学生交了订金后才算成功订票。

对订票的历史记录要提供一定的查询功能，且由于不可能永远保存所有记录，还需要提供相应的删除记录的功能。

1.2.4 用户的登录

用户分系统管理员和普通注册用户两种：系统管理员拥有系统的所有功能权限，而普通注册用户只能管理自己的个人信息及检索需要的车次，对系统的其他功能不具有权限。因此，系统需要对不同的用户给予不同的权限，为此要给每一 个合法用户提供一个用户名和密码，用户凭此登录系统，提高系统的安全性。

1.2.5 系统基本信息的管理

对车次类别的设置：对不同类型的车次信息给予不同的订票期限。

对系统用户的管理：分系统管理员和普通注册用户两类，不同类型的用户有不同的使用权限。

1.3 数据字典

需求分析可通过数据字典加以描述，以保证数据定义的严格性。

对学生的管理：[添加学生|修改学生|删除学生|检索学生]

对列车的管理：[添加列车|修改列车信息|删除列车信息|检索列车]

对车票订购的管理：

对车票订购的管理：[添加订票信息|修改订票信息|删除订票信息|检索订票信息]

对个人信息的管理：[添加个人信息|修改个人信息]

对基本信息的维护：[对车次类别的信息维护|对登录用户的维护]

对车次类别信息的维护：[对车次类别信息的添加|对车次类别信息的修改|对车次类别信息的删除|对车次类别信息的检索]

对登录用户的维护：[对用户信息的添加|对用户信息的修改|对用户信息的删除|对用户信息的检索]

时间表达：年+月+日

学生信息：姓名+性别+学号

学生：学生信息

性别：[男|女]

学号：12位字符串

车次信息=车次号+车次名+时间+类型+票价+席别+起始站+终点站+里程+入库日期

车次=车次信息

车次号=8位字符串

时间=时+分

类别=[普快|特快|动车|普通|高铁]

席别=[硬座|软座|硬卧|软卧]

起点站=4个字节

终点站=4个字节

里程=4为整数

入库时间=年-月-日

订票信息=流水号+姓名+列车号+列车名+订购日期+实际得票日期+张数

订票=订票信息

订购日期=年+月+日

实际订票日期=年+月+日

系统基本信息=[学生类别信息|车次类别信息|系统用户]

学生类别信息=学生类别+能订购的数量 张数=[0|1|2|3|4|5|6|7|8|9]本

车次类别信息=车次类别+金额

车次类别=[硬座|软座|硬卧|软卧]

系统用户=用户名+密码+是否管理员

用户名=16位数字或字母

密码=8位数字或字母

是否管理员=[是管理员|不是管理员]

是管理员=1；不是管理员=0

1.3性能要求

总体来说，该系统在性能上没有太多特殊要求，只要进行图书查询的时候没有明显的延时就行了，希望查询的响应时间不超过3秒。其它一些要求如下：

系统最小寿命：系统应该能在无重大改动的条件下正常运行5年以上

设备要求：计算机稳定性良好，整套系统经济实惠

在使用上：要求系统易理解，易学习，易操作

在安全性上：要求系统安全可靠，容错，易恢复

在数据集中上：要求用统一的数据库实现数据的完整性和实时性

在可维护性上：要求系统可修改、可测试、可扩充、可移植。

火车订票系统测试

本测试所测试的功能均来自于火车订票系统的需求规格说明书，也就是说，在火车订票系统需求规格说明书中列出的系统功能和性能都需要进行完整的测试，其目标是尽可能多地发现待测系统中的错误，再尽可能改正。

2.1 概述

2.1.1火车票订购系统概述

本系统的主要功能包括：车次入库的管理、订票信息的管理、系统使用者的管理。

2.1.2 系统的测试计划

系统的测试从需求分析阶段就要开始考虑，在总体设计、详细设计中不断地对测试计划进行补充和完善。对于设计中的每个具体功能的实现，都要考虑到其测试用例的设计。当进入到编码实现阶段后，每一个模块都需要进行单元测试，通过后再进行集成测试。在系统测试完成后方可在用户参与下进行验收测试。只有通过了用户的验收测试后，才能把系统交给最终的用户。

在系统项目及其所属的各个模块的编制与开发期间，要进行各种测试活动，准确记录、及时分析并妥善保存有关这些测试的记录，是确保系统运行的重要条件。在系统测试中，应有专人负责收集、汇总与保存有关系统测试的记录，具体如下：

需求分析阶段列出的系统的每个功能都要求是“可测试”的。

设计阶段每个具体功能的实现都要考虑到其测试用例的设计。 编码实现阶段对每个模块做单元测试，然后做集成测试。

最后和用户一起做验收测试。

系统测试是为了验证各个阶段所完成的工作是否满足分析和详细设计要求，识别出期望的结果和真正结果之间的差别，以便修正系统设计和代码实现中的潜在错误，保证系统运行的正确性和功能完备性，提高系统运行的性能。

2.2测试方法和步骤

2.2.1系统的测试方法

针对本系统各个模块的功能集中于对数据库的处理，以及对用户交互界面的设计，系统内部并没有涉及复杂的算法和数据结构，因此制定的测试方法是以注重测试功能的黑盒测试为主，如果需要的话，可以对个别重要的模块辅以白盒测试，以保证系统的正确性。

2.2.2系统的测试步骤

先进行单元测试，再进行集成测试，遵循自底向上的策略。对于每一个测试用例都要考虑到合法和非法的情况。

2.3 测试过程

2.3.1系统的测试内容

根据前面的需求分析的功能描述，本系统主要有系统登录、学生信息管理、车次管理、订票管理、基本信息管理五个部分，所以系统的测试主要围绕着这些模块展开。需要说明的是，在前面的编码中，为了使系统具有更好的交互性，在上述的每个模块里设置了相应的出错处理，对于这些出错处理部分，也要给出相应的测试，这部分测试可放在各个子模块的测试里。

测试1：

系统登录测试：测试系统的登录界面是否正确、合理。对于合法的用户是否能够转入正确的界面，对于非法的用户能否进行正确的处理

测试2：

学生管理测试：根据前面的详细设计，可知该模块共有4个子模块，因此需要对这4个子模块先分别进行单元测试，及测试“添加学生”、“修改学生”、“删除学生”、“查询学生”，然后再进行集成测试。

添加学生测试：首先测试当用户填写了正确的学生信息后，能否成功提交；还要测试当用户提交含有错误的信息时能否被拒绝，并正确的指出出错的位置。

修改学生测试：首先需要测试是不是只有允许修改的字段才能修改，那些不能修改的字段是不允许修改的；对于允许修改的字段，先给正确的修改值，看能否正确提交，再给错误的修正值，看能否被拒绝，并给出正确的提示。

删除学生的测试：测试当用户确实要删除后，该记录是否真的被删除，以及当用户放弃删除时，该记录是否还在。

查询学生的测试：首选需要测试当输入一个合法的条件时，能否给出满足条件的学生；其次需要测试当输入一个非法的条件时，能否给出正确的提示。需要说明的是，在“修改学生”、“删除学生”测试中都可能要先调用“查询学生”来找到指定的学生，对于这些，在“修改”和“删除”中不予测试，而是把它放在“查询”中进行测试。在下面的其它测试中也是类似，以后不再重复说明。

测试3：

车次信息管理测试：根据前面的详细设计可知，该模块也有4个子模块，因 此需要对这4个模块先分别进行单元测试，即测试“添加车次”、“删除车次”、“修改车次”、“查询车次”，然后再进行集成测试。

添加车次测试：首先需要测试当某些该填的信息没有输入时，系统是否能够给出正确的提示；还需要测试当所有信息都填入但是新输入的车次号在后台已有时，能否给出正确的提示；最后还需要测试当输入一个正确的记录时，能否成功提交。

修改车次测试：首先测试当用户没有点击任何记录时，系统能否给出相应的提示；当用户选择了某条记录时，能否将满足条件的记录正确地显示在相应的编辑框中；在用户修改后，能否成功提交。

删除车次测试：首先测试当用户没有选中任何记录时，系统能否给出相应提示；还要测试当用户选中了一条记录进行删除时，能否给出“确定要进行删除吗”的提示，并且分别点击“确定”和“取消”能够进行正确的处理。

查询车次测试：首先测试当“车次类型”和“车次号”都不为空时，系统能否给出正确的处理；还需要测试当其中一个为空时，能否给出正确处理；最后测试当两者都不为空时，能否给出正确的处理。

火车票订购测试：根据前面的详细设计，可知该模块也有4个子模块，因此需要对这4个模块先分别进行单元测试，即测试“订票”、“取票”、“删除订票信息”、“查询订票信息”，然后再进行集成测试。

订票测试：首先测试当输入正确车次号时能否正确显示该车次的信息，当输入错误车次号时能否给出相应的提示；测试当同时给出正确的终点站和起始站时，能否进行正确的订票处理（包括可以订购和不能订购两种测试）。

取票测试：当用户订票成功后，需要到指定地点取票，点击了“取票”按钮后，测试对于各个记录是否做了正确的处理。最后还要测试当用户点击了“放弃”按钮时，交互界面是否清空。

删除订票信息测试：首先测试当要删除的订票记录中的有对应的记录时，若不能删除，并要给出正确的提示信息；

查询订票信息测试：学生登录西太后点击查询信息就可以查询到已经订购的票务信息。

基本信息管理测试：主要包含对 “车次类别信息管理”、“用户管理”2个子模块的测试，每个子模块也分别有“添加”、“删除”、“修改”、“查询”4个更细的子模块，这些测试都和上面的“借阅者管理测试”的4个子测试完全类似，这里不再赘述。

2.3.2系统的单元测试

从上面可以看出，本系统需要测试的模块较多，而很多模块的测试内容比较相似。对于单元测试，仅以系统订票管理为例，详细地说明如何设计测试用例。对于其它的模块，这里不再赘述。对于每个单元测试，可采用的方法是黑盒测试中的等价类测试，辅以边界值分析方法，力图发现系统中的每一个错误。

订票测试用例的设计

等价类的划分（这里主要包含对于有效等价类的划分以及无效等价类的划分）

有效的输入等价类有

A 有效的车次号，必须为数字与字母

有效的输出等价类有 Z成功的订票

无效的输入等价类有：

b无效的车次号

无效的输出等价类有

x提示票额数额已满

w提示车次号无效

设计覆盖等价类的测试用例

对于有效等价类，希望设计的测试用例覆盖的等价类越多越好；对于无效等价类，为每一个测试用例，如表所示。

有效性

输 入

用户名

Wang

OK

Wang

Wang

车 次

K201

#!@#

K111

CCC

输 出

覆盖的

等价类

有效 成功订票

A, Z

无效 无效车次

b

无效 票额已满

x

无效 车次号无效

w

2.3.3 系统的集成测试

通过了单元测试后，便可进行系统的集成测试，一般采用自底向上集成的方法。下面以订票管理模块为例阐述订票管理系统的集成测试。

订票管理模块的集成测试

在进行了“订票”、“取票”、“删除订票信息”、“查询订票信息”4个子模块的单元测试完成以后，就可以进行“订票管理”模块的集成测试。这里主要测试的是各个模块之间的接口，以及涉及的一些全局变量。具体的设计步骤如下：

利用“订票”模块完成某个账号的一次借书，然后调用“查询订票信息”模块来看看这次订票行为能否查询到。如果没能查询到则为软件错误，否则进入下一步。

对这次借书行为调用“取票”模块进行取票，如果不能成功取票则为软件错误，否则进入下一步。

调用“查询票务信息”模块查询上述还书行为，如果查询到进入下一步，否则错误。

调用“删除订票信息”模块删除上述还书记录，看看能否给出正确提示，能则进入下一步，否则为软件错误。

修改账号的相关字段以满足删除条件，再次调用“删除票务信息”模块对订票记录进行删除，如果可以删除则此次测试成功，否则软件错误。

2.3.4系统测试与回归测试

完成了各个模块的测试后要进行系统测试，也就是说，要把系统的所有模块集成在一起进行全面测试，还要考虑软件兼容和硬件的配置问题。

在系统测试的任何一个阶段，只要发现了错误，就要尽可能及时更正。更正后还要检验已经发现的缺陷有没有被正确地修改及修改过程中有没有发现新的缺陷，即回归测试。另外，每当一个新的模块被当作集成测试的一部分加进来的时候，软件环境都会发生改变，即建立新的数据流路径，还有可能激活了新的控制逻辑。这些改变可能会使元宝工作得很正常的功能产生错误，因此在集成测试策略的环境中要进行回归测试，就是对部分已通过测试的功能要再次进行测试，以保证系统在新的环境下能正常工作。