51Testing软件测试论坛

标题: 报表用例设计 [打印本页]

作者: goal0813 时间: 2005-8-8 16:35
标题: 报表用例设计
各位，有无报表测试用例的经验？
我要写一些报表方面的用例，基本上是检查报表目的是否达到，取数是否正确。
有一些用例设计的想法：
1，简单的报表页面整齐度检查。
2，描述数据来源
3，检查生成的报表，是否与数据来源一致

但是现在遇到一些困难，我不知道怎么着手写这方面的用例，如果哪位朋友做过类似的用例，能否分享一下经验？谢谢

作者: null2 时间: 2005-8-9 09:39
顶一下
关注ing

作者: ww0221542 时间: 2005-8-9 16:41
楼主写得不是很详细，不知道你这个报表具体的细节都有哪些呢？

作者: goal0813 时间: 2005-8-9 22:11
例如：
出差报销单：每月都有员工出差，差旅金额需要报销
公司希望能统计每月差旅金额的总和以及各个出差员工的差旅明细。
系统将差旅金额与每个出差员工挂钩，员工出差前，可以向公司申请差旅费，出差回来后，如果钱还有剩余，则归还公司，钱花多了，则公司再给员工一些补贴。
如此，需要将数据通过报表的形式反映出来。

一开始我认为写这些报表用例不难，但是真的自己写了，发现取数等一些问题，好像不太好写，一个员工一个月可以出差好多次，每次都有差旅费发生，如何在用例中描述出来，我有点无从下手，欢迎大家讨论。

作者: songfun 时间: 2005-8-10 09:53
报表的用例设计，我也关注一下

作者: goal0813 时间: 2005-8-11 08:33
自己顶一下

作者: roost 时间: 2005-8-11 11:01
标题: 关注
报表的用例设计，我也关注一下
等待这方面的高手指点,试目以待

作者: beck3000 时间: 2005-8-11 12:03
标题: 我的感想（一）
对于报表的测试，其实想保证报表数据正确性，还是要从SQL语句入手，就是作为测试人员写测试用例时，预期结果等于select count(*) from .... where ......，就是说这个SQL语句是测试人员根据他对需求的理解和数据库的熟悉而写出来的，但怎么能保证测试人员写出的SQL语句就是正确的呢？与其这样，还不如直接审查设计人员写的SQL。而且这种用例的写法，有白盒的味道了。

作者: beck3000 时间: 2005-8-11 12:22
标题: 我的感想（二）
那换成纯粹黑盒的写法，又有矛盾了。比如要统计”每月差旅金额的总和以及各个出差员工的差旅明细“，当数据少的时候我可以把一条条记录的数据直接相加，看和报表统计结果是否一致，但数据量大了呢，肯定没法手工了。
我在实际工作中测试报表，一方面要和设计人员探讨SQL写法是否正确，另一方面就是写那种验证方法，比如增加或删除或修改一个员工的差旅记录，然后看报表结果的变动。
我们都知道测试无法穷尽的道理，但是有等价类划分和边界值分析的方法可以帮助我们提高测试的覆盖率。在所有的测试中，我感觉报表（包括查询）的测试，因为涉及数据量大，是最难保证覆盖率的，象那种通过增加、修改、删除记录的方法，我做是做了，但做完后仍是对正确性一点信心都没有，因为他能验证的东西太少了。
坦白说，这种测试用例是没有办法的办法。

作者: goal0813 时间: 2005-8-11 14:02
谢谢beck3000
1，利用自己编写的SQL语句，将报表数据查询出来，再根据打印出来的报表对比，这个方法我想到过，但是由于感想（一）中提到的一些顾虑，我没有这么做。不过和设计人员探讨SQL写法，倒是一个很棒的方式。
2，目前经过2天的思考和组内交流，决定了一种比较痛苦的用例设计方式。
   方法是测试人员自己设计报表数据，然后根据报表数据画出报表的demo，以后在测试的时候，将自己的测试数据提交到系统中，生成报表，再对比demo上的数据是否一致，一致则pass，不一致则fail。
   这种方式的痛苦在于，各种数据都要自己亲手准备，并且要考虑到各种场景及情况，以及想象这种场景下这些数据录入会有怎么样的效果，然后制成demo。比起一般的功能测试，输入一些测试数据，在这种场景下，出现这种效果麻烦得不止一点。
   投入太多，收获不知道如何，可能的话，还是得用其他办法，或者索性不写了。

作者: secat 时间: 2005-8-11 15:50
goal0813：
为什么用例中必须要有详细的数据，数据肯定是要测试人员自己造的，但不一定要详细的反应在测试用例中，可以用简单的语言描述一下就可以了啊。关键是把流程反应出来，涵盖所有的异常，预期的结果和实际的结果一致就Ok了啊，而且预期的结果显示什么我想也不用写的那么清楚吧，自己心中有数就行了啊，最重要的是数据的正确性啊。

一点个人的意见而已。只要不详细描述数据，把重点放在流程上，我想不应该会显得那么难吧。

作者: goal0813 时间: 2005-8-11 16:37
To secat:
报表主要看数据显示是否正确，所以我的想法是自己先设计一些报表输入数据以及输出数据，在打印报表时候将准备的输入数据输入到系统中，看系统中出来的数据是否与准备的输出数据一致。这个和你说的预期结果和实际结果一致就OK是一样的道理。
但是报表和查询这2方面，关键是要看数据显示出来是否正确，凭主观臆断，即使测完了也会感觉到不塌实，所以得准备比较完整的测试数据，这样会比较客观。

作者: beck3000 时间: 2005-8-11 16:50
secat说的有一定道理，一般来说，测试用例就是测试用例，测试数据就是测试数据，测试用例里面只有对输入数据类型的描述，这样可以用不同数据多次重复执行同一测试用例。
但往往也不能一概而论，有些程序对数值计算要求较高，比如我们要测一个计算器，测试用例里往往就需要真正的数据，它同样可以多次执行，所以说要看被测应用的实际类型。
还有对于测试用例来说，心中有数是不够的，测试用例必须用文字描述的清楚，无歧义，预期结果必须是确定的某种行为。

作者: ww0221542 时间: 2005-8-15 17:16
beck3000讲得很明白了。对于测试用例的设计可以用图解法，结合等家划分和边界值法，最后在主观不从一些测试用例，这样就可以系统的准备测试用例了。至于测试数据，只分成有效输入和无效输入。对输出的判定就取决于相关输入的操作项了。

作者: goal0813 时间: 2005-8-15 22:07
谢谢大家的讨论。
2个善于交流协同工作的人胜于3个低头拼命干活的人。
－－大师如是说

作者: 丢了朵朵 时间: 2011-1-6 15:28
学习了~

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)