JSP电信通讯计费系统设计(含英文文献翻译)
3、批价出账模块
先不计较算法是否能够十分精准的算出通话费用，用几条实际的数据来测试其功能的完整性，若能够通过记录的参数，计算出产生的费用，再将费用写入数据库通话详单表中，然后分析通话详单，将同一类型的通话累加，出账到通话费用表中，则说明功能完善。
4、用户缴费模块
单个用户到前台来缴费，应该能够从数据库查询出该用户，当前已出账的帐期的欠费金额，若历史账期还存在欠费，能够计算出滞纳金，统计总共需缴纳的金额，显示在前台，若用户组缴费，应该统计该组所有用户产生的费用总和。后台随时都应该可以查询某用户或用户组的费用信息，缴费记录等，可在此基础上补打发票。
用户组缴费，可以统计改组所有成员产生的费用，即应缴金额，且只允许组实际缴费金额等于应缴金额，不允许预存。
4、数据文护模块
测试的目标是该模块的新增数据到数据库，查询出来，更改数据库已有数据，删除数据等操作都能够顺利进行，测试时，每操作完一项，就到数据库表中去查看，数据是否真的发生相应的变动，若无改变或变动错误，则相应的部分有问题，需要进一步调试。
5、测试结论
权限菜单分配模块一开始并没有完全像预期一样运行，比如当选取某些父菜单项而未选其子菜单项，相应的子菜单没有跟着一起被赋权给权限组，更改代码，当选取某父菜单项市时，其下所有的子项都一并加入其中；同理，当只选取了某个低级层次的子菜单项时候，其父层，循环向上，直到顶层的菜单都需要一并添加还能算是完整。
业务受理模块的某些业务逻辑涉及到事务，就是执行某些操作，要么成功，要么失败，而不能出现成功一半的情况，事务能够很好的解决这个问题，最典型的操作就是同时向多项表中插入数据。初次测试时该问题被发现并成功解决。
批价、出账和缴费模块的功能测试时，并没有考虑计算结果的完全精准性，而是大致能够运行并计算简单的测试用例，且可以将结果插入数据库中，即可。没有出现太大的问题，而数据文护模块的测试，出现某些查询不支持模糊查询，查询结果没有按照预期要求排版，修改不成功等问题，都成功解决。
三、需求测试
1、测试规范
对于需求的测试，可以从下面几个方面进行检查：
①正确性：需求描述是否正确，是否和用户的意图一样。
以批价来举例，某用户在2008年09月30日 23:55:45开始打11808长话，通话结束时间为 2008年10月1日 00:11:42秒，通话时长为16分钟，省委机关的需求是这样的：用户拨打11808长话会产生两项费用，既收取普通市话费，又收取IP长话费，11808长话的计时划分规则为：第一阶段：180秒；第二阶段：600秒；第三阶段：不限时长。同时数据库应该存在多种相应的计费方法。
所设计的计费算法应该只找到以下两个该通话记录需要的计费方法：a、11808市话晚间优惠计费方法：其优惠时间段为晚间22:00:00至早上08:00:00，其计费细则假设为第一阶段0.3元/180秒，第二阶段为0.2元/60秒，第三阶段为0.4元/60秒；b、11808市话国庆节优惠计费方法：其优惠时间为10月1日00:00:00至10月8日00:00:00,其计费细则假设为第一阶段0.1元/180秒，第二阶段为0.2元/60秒，第三阶段为0.3元/60秒；c、11808IP长话晚间优惠计费方法：其优惠时间段为晚间22:00:00至早上08:00:00，其计费细则假设为第一阶段0.2元/180秒，第二阶段为0.3元/60秒，第三阶段为0.4元/60秒；d、11808IP长话晚间优惠计费方法：其优惠时间为10月1日00:00:00至10月8日00:00:00,其计费细则假设为第一阶段0.1元/180秒，第二阶段为0.25元/60秒，第三阶段为0.3元/60秒。
该用户的该次通话记录，其费用应该是普通市话费和IP长话费的总和，普通市话费应该这样算：通话时长共16分钟，前300秒，划归晚间优惠段计费，晚间第一阶段180秒，180/180*0.3=0.3元，晚间第二阶段120秒，120/60*0.2=0.4元，后面的时长划归国庆节优惠段计费，第二阶段已算掉120秒，国庆第二阶段600-120=480秒，480/60*0.2=1.6元，国庆第三阶段180/60*0.3=0.9元，至此，通话时长算尽，普通市话费为0.3元+0.4+1.6+0.9=3.2元，同理，算出IP长话费为0.2+0.6+2.0元+0.9元=3.7元，该次通话产生费用为3.2+3.7=6.9元。
还有滞纳金的计算，也应该达到毫厘不差：从出账日开始起，至下个帐期出账，都不产生滞纳金，过后，就开始计算：若2009年02月01日出账，出账帐期编号为200901，即出的是01月份的话费，允许用户在02月1日至02月最后一天期间来缴费，不收取滞纳金，3月1日开始算取200901帐期的滞纳金。若该用户到5月15日前来缴费，200901帐期的欠费y产生的滞纳金计算：三月份：y3=y+y*0.003*31；四月份：y4=y3+y3*0.003*30；截止缴费日：total=y4+y4*0.003*15，同理，该用户的其他帐期同样的算法，累加起来，即得到总滞纳金，将程序得到的结果与手工算取(要保证正确)的结果比较，测试程序算法的准确性。
②完备性：需求是否包含了所有用户的要求和条件等。
正如①中所举例，测试用例应该覆盖所有可能的现实情况，①只是举了其中一个较为复杂的情况计算，那么，计费算法的测试用例大致应该包含以下几种：晚间优惠段内的通话，普通优惠段的童话，节假日段内的通话，晚间，普通，节假日优惠段之间的两两跨越，最复杂的还要考虑到三者之间的跨越。
③一致性: 需求是否和标准等一致。可参照①的准确性。
④可测试性：需求是否可以被测试用例进行测试。模拟数据，打印结果，核对结果。
⑤明确性： 需求描述不能含糊，必须是明确的。比如系统启动时间很快就是一个含糊的需求[12]。
2、测试结论
需求测试较为繁琐，因为大部分核心需求都体现在这块当中，需要编写大量有效的测试数据，一一进行测试，还需要考虑现有的所有边缘情况，这些问题都集中体现在批价，出账和缴费模块上，批价和滞纳金问题，都是经过反复地测试，修改代码，将运行结果与手工计算结果比较，直到所有的边缘情况下运行结果都与手工计算的结果一致，才能说明该算法是正确的，否则，继续修改。最后，拿现有需求条件下编写的测试数据，测试代码运行结果，完全符合预期结果，该需求测试才得以结束。
第三节、本章小结
软件测试也是软件开发周期里十分重要且必不可少的一部分，本章首先从软件测试的定义、目的和原则作了简要的概述，从而引出了该省委计费系统的测试要点，可以看出，最重要的测试部分还是需求测试和功能测试，它是保证需求的准确性和功能的完整性的基石，所有该部分的测试量是很大的。若这两块测试完成后，系统可以说基本上就达到预期要求了。
<< 上一页 [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] 下一页
JSP电信电话计费系统设计(含英文文献翻译) 第16页下载如图片无法显示或论文不完整，请联系qq752018766
