报表测试-zt
|
测试项目
|
测试要点
|
| 数据的来源 |
来源于哪张表,哪个字段,
数据库中的数值与界面数据的对应.如数据库中性别的数据可能是0或1,但界面显示为男或女,这个对应关系是否正确.
|
| 数据的范围 |
是否只显示了报表设置的对应范围
特别要注意边界数据,要清楚报表的需求,是否需要过滤掉被选择的数据.如时间选择为2006-9-27~2007-9-27,那么是否应该包含9-27这天.
|
| 数据的对应关系 | 数据库中的字段是否与报表中的信息对应 |
| 数据的格式 |
小数位,千位符,四舍五入等是否与报表设置一致
单位或税率转换是否正确
组合显示的数据是否合理
|
| 数据的排序 | 排序方式是否与报表设置一致(如果没有设置,是否有一个清晰的默认排序方式,如按字母或数字排序) |
| 流水号 |
如报表有使用流水号,流水号的生成和格式是否正确.
取消操作是否会生成流水号.
|
| 明细与合计的一致性 | 各部分明细或小节是否与最后总和一致 |
| 其他 |
|
测试项目
|
测试要点
|
| 报表的整体风格 | 报表是否符合规定的或用户设置的格式 |
| 报表标题 |
报表的标题是否是正确的报表名称
如报表中有嵌入的数据(会跟随用户的选择而变化的).需要检查数据是否正确,如XX企业9月份财务报表,这个9月就是用户选择的;或者XX公司2006-9-27~2007-9-27的网站访问量,这个时间段也是用户选择的.
|
| 公司的一些标志 | 如logo,名称,地址之类的是否正确 |
| 报表的页首与页尾 | 是否采用了一致的规则. |
| 分页 |
当输出的内容多时,分页是否正确.
翻页功能是否正确
|
| 友好性 |
数据或图表是否清晰,一目了然,
数据的展示符合用户的习惯
需要特别提醒的数据(如合计,异常数据)是否突出显示
复杂算法处,用户不明白或容易混淆处是否有注释
一些默认的格式是否让人感觉舒服,如对齐,边界,间隔等
|
关于进销存系统的报表测试
近日，看了陈雷的文章《进销存系统的报表测试http://www.51testing.com/html/6/1871.html ，自己也在这方面接触了两年的时间，颇有同感，他的经验总结得非常到位，在此，希望能作点补充，或者是以另一种角度来讨论！
报表的重要性，大家都知道它有举足轻重的地位，特别是成本/利润类报表、月报、年报等，这里就废话少说了！所以，它对测试条件的要求、测试覆盖率的要求、测试深度的要求都非常高，而且不是一般的测试员和新手随便就能测试的，一定是对业务和相关的法规非常熟悉，最好能有实践经验的、较强分析能力、综合能力高的测试员来做！
总结了报表在测试时需要关注的十大特性：
一、 正确性
报表的最低要求和基本特征就是它的正确性！
1.报表格式的正确
不同的报表有不同的格式，有些是行业内默认的，有些是明文规定的，还有自定义的，按照不同条件还可以分各种各样的，如：按照货品的仓库进出情况，分入库类报表、出库类报表和仓库类报表等；按照报表的类型，分图表，固定行列报表，分栏报表、交叉报表等等！因此，报表的格式不是随便增减的，一般包括表头、表体、表尾、以及附注等，测试时需要具体问题具体分析，根据需求提供的标准格式模板！
2.报表内容的正确
这是测试的重中之重，包括数据的算法、数据的来源、数据的对应关系、小数位问题、四舍五入问题、单位换算问题、税率换算问题、明细与合计是否一致、单据的类型/状态改变后对报表的影响等！
二、 时段性
这个很容易了解，没有那张报表在时空上的统计是漫无边际的，就算是“所有”或者“全部”，都是有它的时效！特别是财务类报表，有月报、季报、年报、甚至还有现金日记帐等，都表现出时段在报表中的必要。
三、 条件性
每个报表都是针对特定的条件而作出的输出，要想达到目的，是需要一定条件的。如：统计XX供应商XX业务员在XX时期采购XX商品的情况，在查询时就至少需要四个条件了！
在测试查询条件时，通常采用正交的方法来增加它的测试覆盖率，但是要注意的是，测试数据的选取非常重要，我们都尽量模拟真实的、有代表性的、经过精心设计的数据！
四、 可比性
这在报表的分析和成效的判定上，显得尤其重要，通常报表的测试，不仅只是对单张报表的测试，还需要多张同时进行比较，多张可以是指同一时期不同类型的报表、不同时期同一类型的报表、不同类型与不同类型的报表（但它们之间必然存在某种关系的）；还有什么同比的、类比的等！
目的是找出它们之间的联系和区别，然后获得更深层次的某种规律或者业务流程的脉络。简单来说，就是从实践上升到理论！
举个简单的例子：我们都知道财务报表的会计原则是“有借必有贷，借贷必相等”，因此，每个财务类报表都有借、贷两方；然而从销售收入报表、销售支出报表和销售利润表，显然得出：销售收入-销售支出=销售利润，这一条无人不晓的规律！
五、 穿透性
这个也很容易理解，大多数的报表都不是孤立的，例如：从汇总表可以穿透到明细表，从明细表又可以穿透到单据，从单据甚至可以穿透到具体的产品；虽然它们的层次深度可能不一样，但它们与某某之间有着奇妙的联系！
在测试中，一定要理清它们之间的层次、顺序，这就需要对业务的理解和知识的积累！
六、 隐蔽性
这里不是指报表的数据或者结果隐蔽，而是指所统计的数据来源的隐蔽。例如：入库类的，除了正规的采购入库，还会有估价入库、退货入库、盘盈入库、报溢入库、拆卸入库（将组装产品或者已经打包的产品，拆卸后将元素产品重新入库）等；出库类的，除了常见的销售出库，还会有采购退货、盘亏出库、报损出库、生产领用、组装领用等。请注意的是，有些进销存系统还分有帐面库存数和实际库存数两种的！
另一个陷阱：有些进销存系统的应收帐款是由正常的应收帐款加上预付转应收的部分组成的；同理，应付帐款是由正常的应付帐款加上预收转应付的部分组成！
七、 时序性
上面说了时段性，现在到说说时序性，顾名思义，就是指业务发生的时间顺序。在明细报表中，每项明细都应该有记录业务发生的时间，它的先后顺序很重要。
举个简单的例子：某仓库库存量为100，三月份销售出库50，四月份采购入库也是50，如果将四月份的采购入库计入三月份的，虽然年仓库库存量还是100，没有变，但是对于月度库存量和季度库存量就影响大了！
八、 安全性
1.这个主要体现在报表的权限控制上。因为报表是针对不同的用户设计的，特别是敏感的数据，如个人资料、产品成本、商业信息等，这就需要加强访问权限的控制，有的是只读的，不能过滤条件或者修改其他的查询条件；有的根据用户等级来分配权限等！
2. 通过用户角色和密码来控制：业务员只能看到自己的业绩报表
3.通过用户角色的等级来控制：非财务主管不能打开销售收入利润表等
九、 直观性
报表的数据、结果清晰明了，页面简洁、排版合理，不能给用户产生模糊或者引起奇异的感觉；一般合计的部分或者关键字段都需要突出显示；有的报表需要图文并茂，选择最佳的报表类型。
十、 打印
仅仅测试通过查询得到的报表，是不足够的；通过屏幕看到报表的效果，也是不能全信的，需要持有怀疑的态度，把报表打印出来，重新检查是否适合所需的效果！
包括：打印模板的设计、套打样式、自定义模板、打印调试、打印时间等方面。
本文适合有过MIS系统报表测试经验，或者有关进销存系统测试经验的朋友参考。
报表功能的基本要求，就是通过查询/统计/分析，提供用户所需的准确的数据。如果无法实现这个基本功能，则报表完全失去意义。
对于用户来说，报表可以直接影响到他们的决策，例如可能因为报表对销售和库存情况反映的不准确，导致错误的大量进货；或者因为报表对应收应付金额计算的不准确，而导致企业对资金占用情况做出错误的估计，
从而导致错误的决策，最终造成用户在经营上的损失。诸如此类，相信只要大家留心，还可以找出很多这样的例子。
进销存系统中的报表多如牛毛，而且各种不同行业的进销存系统中的业务有区别，报表也有些区别，因此不太可能对各种报表逐个讲解，而主要是把一些报表测试的经验总结成了十几条可以在各种行业的报表测试中应用的“最佳实践”，来跟大家一起分享。希望下面的这十几条像一招招简单实用的“擒拿手”，可以供正在进行报表测试或者准备开始作报表测试的朋友随手拈来，见招拆招，轻松应对这项工作。
（1） 提高对业务的熟悉程度
其实对任何一个软件进行测试，都必须要熟悉它的业务，包括业务流程和业务规则。但是报表同一般的业务功能还是有些区别的。例如对于单据的增、删、改，通过对界面的浏览和探索性的操作，大概都可以弄明白它的业务流程和业务规则，因为这些内容比较直观，而且在不同的行业中也差不了太多。但是在报表中，是很难直观的看到我们所需要了解的内容的。例如报表中的某个数据项，它的算法或者说数据来源，恐怕是比较难看出来的——即使是很类似的一个数据项，在不同行业的实际业务中，它的算法和数据来源也可以能完全不同的。
所以对于报表业务的熟悉，主要是两个方面：数据项的算法和数据来源，也就是说要明白一个数据项同具体的业务有什么关系，单据的增、删、改或者状态的变化，对报表中各个数据项的计算会产生什么不同的影响。如果不知道到这些，那么就无法验证报表中的数据是否准确，也无法通过报表去检查业务系统的正确与否。
（2） 覆盖所有可能的查询统计方式，而不是以自己的使用习惯为准
对于报表的使用者来说——一般是企业的中层或高层领导，他们对于报表的要求可能会是多方面的，例如在进销存系统中，可能需要按不同商品进行分类统计，也可能是按供应商分类统计，这些都是由用户在实际工作中的需要来决定的，所以假如一个报表提供了多种查询统计的方法，那么在测试时，只要时间充分，就应该覆盖这些所有可能被用到的查询统计方法，而不是以自己的使用习惯为测试的依据。
（3） 使用或构造受控的数据环境
数据对于报表测试来说是一个非常非常重要的问题。因为上面说到，报表的基本功能就是通过各种查询统计分析的方法，为用户提供准确的数据，帮助用户做出决策。那么那些用来进行测试的数据从哪里来呢？
首先，应该保证准备足够多的有效的数据。前面一条也提到了，在实际测试报表时，应当尽可能的覆盖到报表所提供的各种查询统计方法，因此至少应该保证每一种查询统计方法都应该有对应的数据，得到的结果都不会是0，否则等于没有覆盖到这个被测的查询统计算法。当然数据也不是越多越好，能保证全部覆盖，并且刚好够用就可以了，因为数据的准备和生成也是很花时间的。
其次，要保证数据的可控。数据并不是随意生成的，如果使用通过自动化工具或者通过业务测试时随意的输入的数据来进行报表测试，一般来说是不太可能的。因为如果无法控制数据来源，那么即使知道报表中每个数据项的算法，也无法最终验证报表的查询统计结果是否正确。例如，系统的会有不同类型的单据，每种单据又会有不同的状态，某个报表的统计中，可能会涉及到多种类型和状态的单据，那么在准备数据时，就要充分考虑到这一点，准备各种不同的单据来满足测试的要求。又比如，如果整个系统中只有一个供应商，一个商品，那么测试按供应商分类统计或者按商品分类统计的报表时，意义也就不大了。
所以如果希望高有效、更高质量的完成报表的测试，那么就要重视并增加对于数据准备工作的关注：用于验证报表功能的数据，一定是专门为报表准备的，并且是经过精心设计，要分析影响数据项算法的各种因素，以及每个因素可能出现的不同变化，这样才有可能覆盖各种查询统计方法；同时，才能保证无论使用哪个数据项的算法进行计算，其结果都是可以预知的——因为数据来源已经被我们控制了。
特别是对于算法比较复杂，又提供了多种查询统计方式的报表，如果想完整的测试，就需要准备大量的数据。而如果想高效、高质量的完成这项功能，就一定要理解数据准备工作的重要性。
经过精心设计的数据还有一个好处，就是当在进行业务功能的测试时，不再需要使用一些随意的数据，而是可以通过业务测试的过程，把报表测试所需要的数据输入到系统中。并根据报表对单据类型和状态的需要，进行相应的操作。
如果留心，你也会发现报表测试同其他业务功能测试的有个区别。业务功能（例如单据的新增、审核等）的测试用例设计，通常需要考虑的是对各种正常的、异常的业务流程和业务规则的组合的遍历或覆盖；而对于报表功能，虽然没有太复杂的业务流程和规则，但是算法更加复杂，同时报表功能本身就是一种对数据的加工处理，因此会更偏重于对于各种数据来源和算法的遍历或覆盖，也就是要准备各种正常的、异常的数据，来验证报表是否取到的该取的数据、没有取不该取的数据，并且最后计算出了正确的结果。
（4） 特征性数据的准备
这又是一个同数据准备有关的问题，也是一个解决实际问题的经验。如果由多人同时对一个系统进行测试，虽然大家各自使用的数据都是经过精心设计的，但是在实际进行报表测试时，还是很难保证其他人的数据不会对自己的测试结果产生影响，最明显的一个问题就是原来自己对结果是可以预知的——因为数据是经过精心设计的，是可控的，但是现在掺杂了别人的数据，就需要花时间去区分这种“假”的错误和真的错误。
有一个经验是可以借鉴的，就是在初期，团队内对数据的准备达成一直，使数据中的某一项具有特征性，例如分别使用不同的供应商，或者使用不同的商品。最后测试报表时，通过限定选取的数据来源，来保证相互之间尽可能的没有影响。
（5） 做好数据环境的备份和维护
虽然数据是经过精心准备的，但是难免在操作过程中因为误操作导致环境的变化，例如不小心把一张单据变成了另外一种状态，或者某个类型的单据多做了一张。对于这种情况，一个简单的方法就是去维护你的数据文档——一般我们都可以用EXCEL表来保存我们事先准备的数据，可以一个文件保存一个类型的单据，例如采购单、入库单、出库单等等，文件中的每张表用来保存不同状态的单据，例如已经审核过的入库单，没有审核过的入库单，全部入库的入库单和部分入库的入库单，等等。假如你一不小心，把一张本来准备入一半的入库单全入了，那也不要惊慌，去重新调整一下你的数据文档，在相应的类型相应的状态的单据列表中新增一张就行了。
而如果想减少回归测试的工作量，那么应该考虑在一些关键的“点”上备份测试数据。例如所有的基础单据已经输入完成，但是还都没有开始审核或者出入库，那么可以备份一下，下次再测的时候可以直接在数据库中恢复这部分原始数据。
（6） 在业务功能测试通过之后才开始
这一点相信应该不难理解，如果业务功能本身存在缺陷，导致的数据不准，那么最后进行报表测试也就没有什么意义了。所以，应该在保证各项同报表有关的业务的功能测试通过之后，才开始考虑对报表进行测试。
（7） 寻求开发人员的协助
在报表测试中很常见的一个问题，是需求文档中可能没有定义报表的各个数据项的算法，这时候你需要找开发人员帮忙，向他们了解准确的算法和相应的公式。
（8） 多个报表相互对照
这是一项“高级”的报表测试技能，需要对整个系统中的各种业务的熟悉程度达到一种炉火纯青的地步。除了可以准确的说出各个业务的处理过程对每张报表的影响之外，还能够进行横向的联系，知道不同报表之间存在的关系。例如，一个简单的例子，库存报表中，你可以看到商品的出入库情况，而在销售报表中，你可以看到商品的销售金额和销售成本金额，在应收应付报表中，你又可以看到不同供应商或客商之间的应收应付金额。那么这几张报表之间，是否存在一些关联呢？是否会存在一些可以相互验证的地方呢？这个问题，留给大家来思考 ^_^
（9） 着重对那些算法复杂、与业务功能关联较多的报表的测试
如果只是简单的把某个日期范围内的所有入库情况统计出来，可能不会出错；但是如果还要考虑按照供应商或商品汇总，同时要选取特定的类型或状态的单据，再进行一些响应的计算，恐怕就很难保证开发人员永远不会出错了。这就像业务功能的测试一样，越是复杂的业务，越有可能出错。
（10） 留意四舍五入对报表数据的影响
从这一条开始，后面的内容可以说也是一些在实际测试时要注意的事项。
这也是一个常见的问题。在一般的进销存系统中，都会存在这种情况，无论小数点后保留几位，总是难以避免明细和汇总之间的差别。原因可能是因为采购和销售的包装不一致，因为拆零引起的，例如10/30*30≠10；或者由于毛利率、税率等因素导致的不一致。我们曾经试过在保留4位小数的情况下还是无法避免这种情况。
（11） 留意进/存/销时使用不同单位对报表数据的影响
例如采购时是5箱，每箱有100盒，而销售单位是盒，入库之后，可能会要求按照销售单位来统计，这时要注意开发人员是否会选择了错误的单位，把500盒弄成5盒。
（12） 留意业务单据中存在多个日期字段时对报表数据的影响
一般来说，一张单据上都会有多个日期字段，比如采购单就有采购日期、单据日期、审核日期，而入库单也会有单据日期、入库日期，诸如此类。那么在测试时，一定要留意，开发人员是否按照要求选择了正确的日期，包括日期选取的一致性——是否存在这边取采购日期，那边取审核日期的情况。
（13） 留意是否存在遗漏的单据类型
例如像出入库的报表，入库方向的，除了最主要的采购入库外，可能还会包括退货入库、盘盈入库、报溢入库；出库方向的，除了最常见的销售出库，还会包括盘亏出库、报损出库。那么在具体测试时，一定要准备充分这些相应类型的单据，并且要留意开发人员是否遗漏了相应的单据类型。
（14） 留意不同状态的单据对报表数据的影响
例如采购单，当采购单发出后，供应商会开始送货，可能第一批之送来了一半的商品，那么这时采购单的收货状态是“未完成” ；当供应商把商品送齐了以后，采购数量＝收货数量，则采购单的收货状态变为“已完成”。那这时留意，开发人员在采购报表中，是包含所需要的状态的单据，还是只包含了一部分？
（15） 留意那些被当做默认规则的因素
有些规则——例如单据类型或者单据状态——是作为默认规则写死在SQL语句或者数据库的存储过程里面，这些规则不会体现在界面，也不会由用户选择决定。但是这些规则恰恰是最容易被忽略的部分。所以，一定要同开发人员反复确认，保证自己已经了解了同报表各数据项计算有关的各个因素。
（16） 保证测试人员可以通过UI 找到自己所需的所有原始数据
在进行系统测试时，无论是报表，还是一般的业务功能测试，都不要去直接通过SQL语句查询数据库中的内容，而是通过UI来输入，再通过UI体现处理的结果进行验证——因为这是系统测试，不是集成测试，将来用户是决不会去直接查数据库的。因此，如果需要对报表的结果进行验证，应该通过其他的功能模块，去查询业务单据，或者其他报表，根据UI体现的结果，来进行确认。
（17） 检查大数据量对报表的影响
报表测试也会涉及到性能测试，主要是在大数据量查询统计的测试。大数据量一是说原始数据多，二是被操作、计算的数据多，三是某个数据项被是经过多次计算得出的。特别是对于一些算法比较复杂的报表，10万条数据和100万条数据时的响应时间将表现出巨大的差别。
（18） 不要遗漏权限控制和访问安全性的测试
这里说的权限控制不是谁可以访问某个模块，谁不可以访问某个模块，而且数据的计算也没有直接的关系，而是侧重于报表设计的测试。我们都知道不同的报表是设计给不同的人看的，例如出入库报表是给仓库管理人员看的，里面不会包含商品的价格，而只会包含数量；而财务报表中，只会包含采购、销售的金额，而不会包含数量，这样才能保证可以相互对照，不会出现营私舞弊的行为。那么在测试时，应当考虑报表是否泄漏了不该泄漏的信息。当然，这里对业务的熟悉程度就是更高的要求了。
又如，不同的业务员只能看到同自己有关的业务，但是领导可以看到所有业务员的业务——例如不同的业务员分管不同的客户或者地域，他们之间的销售情况是互相保密的。
还有一种情况，系统的用户可能会为他的供应商提供一个专门的程序或者Web页面，供其对其供应的商品的销售、库存情况进行查看。那么对于这种情况，一方面是要保证某个供应商只能看到他所供应的商品的销售、库存情况，如果某个商品由多个供应商同时提供，那么其中一个供应商应该只能看到他提供的那部分，而看不到其他供应商提供的同一商品的情况。当然，这种功能一般都是通过外网（internet）来访问的，所以也还要考虑相应的访问安全性测试，以免泄漏重要的商业信息。
本文根据本人在第5次广州软件测试交流会上的演讲整理而成，请各位同行指正。
