报表测试用例设计方法总结
测试用例总结报告精选5篇
测试用例总结报告精选5篇（经典版）编制人：__________________审核人：__________________审批人：__________________编制单位：__________________编制时间：____年____月____日序言下载提示：该文档是本店铺精心编制而成的，希望大家下载后，能够帮助大家解决实际问题。
文档下载后可定制修改，请根据实际需要进行调整和使用，谢谢!并且，本店铺为大家提供各种类型的经典范文，如述职报告、工作总结、心得体会、工作方案、条据文书、讲话致辞、合同协议、教学资料、作文大全、其他范文等等，想了解不同范文格式和写法，敬请关注!Download tips: This document is carefully compiled by this editor. I hope that after you download it, it can help you solve practical problems. The document can be customized and modified after downloading, please adjust and use it according to actual needs, thank you!Moreover, our store provides various types of classic sample essays for everyone, such as job reports, work summaries, insights, work plans, policy documents, speeches, contract agreements, teaching materials, essay summaries, and other sample essays. If you want to learn about different sample formats and writing methods, please pay attention!测试用例总结报告精选5篇实用的总结报告是能够帮助我们不断进步的，通过总结报告的写作是可以让自己的思索能力得到提升的，下面是本店铺为您分享的测试用例总结报告精选5篇，感谢您的参阅。
测试总结分析报告
测试总结分析报告
XXX软件技术有限公司
2003年06月27日
产品名称
Xxxx
文档编号
版本号
页数
19
文档名称:测试总结分析报告
作者：
Xxx
日期：
2003-06-27
审核：
日期：
批准：
日期：
客户意见：
客户确认：
日 期：
公司地址
第一章
一.1
全国计算机信息高新技术考试系统（CITT）是ATA公司为劳动部开发的一套考试系统，是目前ATA实施的考试系统中比较有代表性的一套考试系统。目前，CITT已经开始使用，在使用之中，发现了系统存在的一些问题，为了更加系统和有效地发现系统中的其它问题，ATA公司和上海文思创意软件技术有限公司合作，启动本项目来对系统进行测试。
建议适当的采用测试管理工具。
在不违犯法律法规、不侵犯商家权益的前提下，我们建议ATA公司在今后的项目中适当地采用测试全程管理工具，加强测试全过程管理，增强测试用例的实现方式，提升测试用例的复用和维护能力，有效地安排和控制各种规模的测试执行工作。
二.2
CITT第一轮测试结束后，各子系统中已发现的缺陷和建议的汇总数据如下：
本文档的的读者为：
文思创意本项目的项目经理
文思创意相关领导
ATA公司本项目的项目经理
ATA公司相关领导
参与本项目的测试人员
一.3
《CITT项目进度安排》
《CITT测试计划》
《CITT工作任务安排》
《CITT测试需求》
《CITT测试用例说明书》
《CITT -测试执行记录》
《CITT -性能测试.》
《CITT -系统培训阶段总结》
《测试用例设计方法》课件
什么是白盒测试？
在白盒测试中，测试人员根据对 源代码的深入了解和测试来识别 问题。
如何进行白盒测试用例设 计？
评审代码结构并创建代表各部分 的测试用例。
为何需要白盒测试用例设 计？
因为白盒测试用例可以帮助确保 软件系统是代码的正确归纳，并 验证预期的输入和输出。
用户界面测试用例设计方法
什么是用户界面？
网络拓扑测试用例设计方法
1 什么是网络拓扑？
网络拓扑是一种描述组成网络的设备和链接的方法和属性。
2 如何进行网络拓扑测试用例设计？
了解网络拓扑和组成部分，确定需要测试的网络拓扑部分，然后创建测试用例以确保系 统的高效性和完整性。
3 为什么需要网络拓扑测试用例设计？
这是一种测试设计方法，可评估整个网络的安全性、性能、稳定性等属性，以提高系统 效率。
2 业务过程
从用户的角度考虑，了解所有可供商业业务 活动使用的业务过程。
4 约束条件
确定并为每个场景创建适当的约束条件。
边界值分析测试用例设计方法
什么是边界值？
边界值是指一个变量或一个参 数的合法最小值和最大值范围 的一个或多个端点。
为什么需要进行边界 值分析？
由于一些计算错误、软件漏洞 或编程缺陷，很容易出现在接 近端点值时导致的失败。
测试用例设计方法
欢迎来到本课程，本课程将介绍测试用例设计方法。测试用例是保证软件质 量的重要组成部分，而测试用例的设计则决定测试的覆盖面和效果。通过本 课程，您将了解各种测试用例设计方法，以便更好地开展软件测试工作。
什么是测试用例设计？
测试用例定义
测试用例是测试计划的基本元素，它是指在特定条 件下，执行步骤和验证结果的描述性文档。
用户界面是用户与系统交互的主要方式。
设计报表测试(统计方面)用例方法总结
设计报表测试（统计方面）用例方法总结一、数据统计方面1、报表统计数据的正确性1）数据的正确a)数据的来源：来源于哪张表，哪个字段，数据库中的数值与界面上的一致b)数据的范围：是否只显示了报表设置的对应范围，如：时间选择2012.11.01-2012.11.19，那么是否应该包含1和19这天c)数据的对应关系：数据库中的字段是否与报表中的一致d)数据的格式：小数位、千位符，四舍五入等是否正确；单位或税率转换是否正确；组合显示的数据是否合理f)数据排序是否正确g)流水号：如果报表使用流水号，流水号的生成和格式是否正确h)明细与合计的一致性：各部分明细或小节是否与最后总和一致2）格式正确a)报表的整体风格b)报表标题：报表的标题是否是正确的报表名c)公司的一些标志：如logo，名称，地址之类的是否正确d)报表的页首与页尾：是否采用了一致的规则e)分页：当输出的内容多时，分页是否正确，翻页功能是否正确f)友好性：数据或图表是否清晰，一目了然，数据的展示是否符合用户的习惯；需要提醒的是数据（如合计，异常数据）是否突出显示；复杂算法处、用户不明白或容易混淆处是否有注释；一些默认的格式是否让人感觉舒服，如对齐、边界、间隔等3）权限的控制a) 报表内容：报表中的内容不能显示用户根本没有权限的数据b)报表的条件定义：在条件选择区域，有些下拉框中不能显示权限以外的数据2、报表统计数据的完整性3、报表统计数据的合法性；比如：统计金额字段需求要求有‘$’等二、报表格式1、表头字段表示的正确性2、表头字段表示的完整性3、表头字段表示的字体、字号，美观程度4、各统计字段的显示是否满足需求；比如：数据过长时要折行还是缩小5、页眉和页角的表示三、报表输出界面1、报表排列方式可调2、报表标题明确，不能含糊误导用户四、报表打印、预览、导出。
如何编写测试用例
如何编写测试⽤例⼀、测试⽤例是软件测试的核⼼软件测试的重要性是⽏庸置疑的。
但如何以最少的⼈⼒、资源投⼊，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的⽬标。
每个软件产品或软件开发项⽬都需要有⼀套优秀的测试⽅案和测试⽅法。
影响软件测试的因素很多，例如软件本⾝的复杂程度、开发⼈员（包括分析、设计、编程和测试的⼈员）的素质、测试⽅法和技术的运⽤等等。
因为有些因素是客观存在的，⽆法避免。
有些因素则是波动的、不稳定的，例如开发队伍是流动的，有经验的⾛了，新⼈不断补充进来；⼀个具体的⼈⼯作也受情绪等影响，等等。
如何保障软件测试质量的稳定？有了测试⽤例，⽆论是谁来测试，参照测试⽤例实施，都能保障测试的质量。
可以把⼈为因素的影响减少到最⼩。
即便最初的测试⽤例考虑不周全，随着测试的进⾏和软件版本更新，也将⽇趋完善。
因此测试⽤例的设计和编制是软件测试活动中最重要的。
测试⽤例是测试⼯作的指导，是软件测试的必须遵守的准则。
更是软件测试质量稳定的根本保障。
⼆、什么叫测试⽤例测试⽤例（Test Case）⽬前没有经典的定义。
⽐较通常的说法是：指对⼀项特定的软件产品进⾏测试任务的描述，体现测试⽅案、⽅法、技术和策略。
内容包括测试⽬标、测试环境、输⼊数据、测试步骤、预期结果、测试脚本等，并形成⽂档。
不同类别的软件，测试⽤例是不同的。
不同于诸如系统、⼯具、控制、游戏软件，管理软件的⽤户需求更加不统⼀，变化更⼤、更快。
笔者主要从事企业管理软件的测试。
因此我们的做法是把测试数据和测试脚本从测试⽤例中划分出来。
测试⽤例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试⽅案。
对软件的每个特定功能或运⾏操作路径的测试构成了⼀个个测试⽤例。
三、编制测试⽤例着重介绍⼀些编制测试⽤例的具体做法。
1、测试⽤例⽂档编写测试⽤例⽂档应有⽂档模板，须符合内部的规范要求。
测试⽤例⽂档将受制于测试⽤例管理软件的约束。
标准测试用例范文测试用例包括些要素
标准测试用例范文测试用例包括些要素测试用例包括如下要素：(1) 用例ID。
可以定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。
(2) 用例名称。
是测试用例的的名称代号，测试用例文档将受制于测试用例管理软件的约束。
(3) 测试目的。
也就是指测试用例的目标和行使其过程所要达到的最终要求。
(4) 测试级别。
也就是指测试用例的等级划分。
引进了路径分析法，按路径设置用例。
演变为按功能、路径混合模式设置用例。
(5) 参考信息。
测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。
(6) 测试环境。
测试用例是“一组输入、执行条件、预期结果”、毫无疑问地应该包括清晰的输入数据和预期输出，没有测试数据的用例最多只具有指导性的意义，不具有可执行性。
(7) 前提条件用于功能性测试的测试用例测试目标的用例。
应该为每个用例场景编制测试用例。
(8) 测试步骤。
也就是指测试用例所需要的详细操作过程。
(9) 预期结果。
“预期输出”仅描述为程序的可见行为，其实，“预期结果”的含义并不只是程序的可见行为。
(10) 设计人员。
甚至是测试工程师本身，全然不顾实际的资源情况，一定要写出“没有接触过系统的人员也能进行测试”的用例。
测试用例的作用如下：1、指导测试的实施。
测试用例主要适用于集成测试、系统测试和回归测试。
在实施测试时测试用例作为测试的标准，测试人员一定要按照测试用例严格按用例项目和测试步骤逐一实施测试。
2、规划测试数据的准备。
在我们的实践中测试数据是与测试用例分离的。
按照测试用例配套准备一组或若干组测试原始数据，以及标准测试结果。
尤其象测试报表之类数据集的正确性。
参考资料：这个要根据测试用例的难度，不能一概而论。
不过，普通的测试用例（执行步骤不超过10步）的话，高质量的测试用例一天编写一般在30个左右，执行在50个左右。
在工作过程中难免会有一些因素影响进度的。
根据系统需求规范写系统测试用例感觉有点困难。
是因为这个时候功能描述还比较泛，感觉会感觉编写用例有点困难，这个时候编写的用例粒度可以比较粗，不用写的很细节（估计也写不出来很细）。
财务公司如何进行可用性测试与压力测试
财务公司如何进行可用性测试与压力测试在当今数字化时代，财务公司对于信息系统的可用性和高性能的要求越来越高。
为确保系统能够稳定运行并满足用户的需求，可用性测试和压力测试是至关重要的环节。
本文将介绍财务公司如何进行可用性测试和压力测试的方法和步骤。
一、可用性测试可用性测试旨在评估系统是否易于使用、学习和操作，以及系统的易用性和用户满意度。
在财务公司中，可用性测试的重点通常是检查交易系统、报表系统和用户界面等关键功能。
以下是进行可用性测试的步骤：1. 确定测试目标：明确测试的目的和范围，根据系统的重要功能和用户需求确定测试重点。
2. 制定测试计划：制定详细的测试计划，包括测试方法、测试环境和测试工具等。
3. 设计测试场景和用例：根据测试目标设计测试场景和用例，以模拟用户在实际使用中的操作。
4. 执行测试用例：按照测试计划执行测试用例，记录测试过程中的问题和异常情况。
5. 分析测试结果：对测试结果进行分析和总结，评估系统的可用性问题，并提出改进建议。
6. 优化系统设计：根据测试结果和反馈意见，对系统进行优化和改进，提高系统的可用性。
二、压力测试压力测试旨在评估系统在正常或超负荷情况下的性能稳定性和承载能力。
对于财务公司而言，压力测试是为了确保系统能够在高并发和大数据量环境下正常运行。
以下是进行压力测试的步骤：1. 确定测试目标：明确压力测试的目的和范围，根据系统的预期负载和性能指标确定测试重点。
2. 配置测试环境：搭建符合实际情况的测试环境，包括硬件设备、网络带宽和数据库等。
3. 制定负载模型：根据预期的负载情况，设计负载模型，模拟用户的请求和响应。
4. 进行负载测试：根据负载模型进行压力测试，记录系统的响应时间、吞吐量和错误率等指标。
5. 分析测试结果：对测试结果进行分析和总结，评估系统的性能瓶颈，并提出改进建议。
6. 优化系统性能：根据测试结果和反馈意见，对系统进行性能优化和调整，提升系统的响应速度和并发处理能力。
怎么写测试用例
怎么写测试用例测试用例是一种重要的软件开发手段，用于验证新系统、新功能或修复问题的功能，本文将探讨如何实践编写测试用例。
测试用例是清晰明确完成一个任务所必须要满足的条件或者要完成的步骤，是用来检验一个软件系统是否有效可靠的重要手段。
正确的编写测试用例能够更好的验证软件的功能，因此需要有一套可行的用例写法来编写测试用例。
一、目的1. 熟悉测试用例的书写规范，明确测试目标。
2. 让参与者更精确了解需求，确定最终的验收结论。
二、测试用例书写基本步骤1. 写明测试用例的名称：测试用例的名称必须清晰明确，能够反映其相应的功能。
2. 编号：可以让其他项目成员更容易找出指定的测试用例。
3. 预置条件：这一项有助于测试者确保所有的必要条件都能够得到满足。
4. 操作步骤：每一项也要尽量包含相应的操作步骤，使其明确容易操作，不要让其他成员困惑。
5. 期望结果：这一项要清晰明确，如果期望结果无法被准确描述，可以使用例子来表示。
6. 测试结果：将实际执行结果与期望结果做比较，以验证是否通过测试。
7. 其他：这一项可以用来描述未被测试的其他情况。
三、测试用例的编写要点1. 从客观角度编写：将主观想象变为客观可测。
2. 写明被测功能：每一个测试用例必须清晰明确的描述测试的功能。
3. 满足覆盖率：保证测试覆盖率能够满足用例设计要求，尽量符合业务需求。
4. 简单而又详细：编写的用例要详细到位，但是又不能过分复杂。
5. 要准确：用例细节一定要准确，避免出现歧义和模糊不清。
6. 将关联引入：多个用例可以间接的关联起来，完成复杂的业务测试。
四、测试用例的维护1. 不断完善：随着需求的不断完善，用例也要及时随之进行相应的更新。
2. API校验：将用例，内部、外部数据和API之间建立关联，有效帮助测试人员校验业务数据的正确性。
3. 使用测试管理工具：将其他项目成员都放入工具中，实现及时之间的信息沟通，同时掌控软件开发进度。
4. 追踪审计：将测试痕迹形成报表，清晰追踪审计，以确保版本更新的有效性。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
报表测试用例设计方法总结
报表的测试主要分为以下几个方面:界面,安全性,准确性,展示速度(性能)
数据统计方面
1、报表统计数据的正确性；
2、报表统计数据的完整性；
3、报表统计数据的合法性；比如，统计金额字段需求要求有“$”等；
报表格式
1、表头字段表示的正确性；
2、表头字段表示的完整性；
3、表头字段表示的字体，字号，美观程度；
4、各统计字段的显示是否满足需求；比如：数据过长时要求折行还是缩小；
5、页眉和页角的表示；
报表的预览和印刷
1、预览中的显示完整性；
2、多页情况下，第2页的表头显示；
3、能否实现需求要求的特定印刷情况；（比如，印刷使用指定的模板）
4、预览后印刷；
5、不预览，直接印刷
6、需求规定各类打印机的测试；
数据准确性测试，带有报表测试的系统分为两类，一类是业务系统中，带有统计分析功能模块，该模块中包含分析报表，这个系统的主体是业务系统，报表是为**业务的而提供帮助的。
比如说，应年检统计报表，某月应交罚款车辆统计报表，这样的报表数据准确与否，可通过增加、删减、修改相关业务或相关业务的参数，查看统计报表数据变化，检查数据准确性。
另一类是系统只有统计功能，就是我说的数据仓库展现这类，它与业务系统分离，并且经过多层处理，比如数据仓库的数据，经过抽取，清洗，展现前会经过数据挖掘，数据再处理，有些字段在原始数据表中根本就没有。
这样的数据准确性测试比较复杂，当然检查出数据错误，修改定位也是很不容易的。
从整个项目节约成本看，逐层测试效果是最好的。
完全修改率也是最高的。
首先建立测试数据模型，模拟所有应用表，建立简单易跟踪的数据用例，底层的数据表测试，方法很原始，嘿嘿，通过SQL语句和手工计算，对数据进行比对。
对系统中的报表数据准确性测试方法较为灵活，
①系统中报表重叠的进行比对
②对子报表汇总与父报表比对，就是对月报表汇总与年报表比对，日报表汇总与月报表比对，这只是一个方面，可以从维度关系考虑，地域，行政级别、时间，个人等方面下手，进行汇总比对
③这个方法如果延伸点呢，可以将报表间的业务逻辑关系作为比对依据。
呵呵，这要看测试人员的需求了解深度个人能力了。
插几句不想干的话，做测试工作总让我保持快乐状态，前两天我的一个同事说，公司里一直没有人喜欢做测试工作，这个工作太枯燥。
嘿嘿，我当时就说我做了这么多年的测试工作从来没有感觉到枯燥。
重复性工作不代表枯燥，编程其实不也是重复嘛，人每天谁不重复昨天的事啊，吃饭，吃这个动作重复一生，有谁觉得麻烦枯燥啦？
④使用SQL和手工计算进行比对。
以上是差错方式，接下来讲一下查什么错？哪些地方容易出错
● 原始表使用错误：因为表比较多，又加上没有统一的数据关系对应表，很容易表使用错误，当然这应该是单元测试检查出来的错误。
● 数据处理逻辑错误：这一点容易因为测试人员和开发人员对需求理解有偏差造成争执，所以在需求评审时，对数据处理规则用表达式或伪代码表示清楚。
还有就是程序员失误，逻辑编写有偏差，边界值、特殊情况处理不当。
● 数据权限：不同用户对数据有着不同的查看权限。
这关系到数据的安全性。
● 数据误差：数据的保留位数，数据是否是处理计算是否是最后一次计算使用了位数保留和四舍五入。
● 由于字典表，数据错误，而造成的数据错误，如，根据性别统计，购买量，表中的男女颠倒，或者没有考虑性别缺失项，用了if else,这样就是把表中缺失该项内容的算成了
else条件里。
或者逻辑中应该考虑用户状态，数据状态类似的字段，容易被忽略，测试应该考虑到。
● 最后一项，当数据量相当大的时候，统计应该考虑，切割速度，也就是数据的完整性，由于数据切割的滞后，带来的数据不完整，而造成统计结果不完整。
如统计昨天的销售情况，而昨天的数据并没有完全从业务系统数据到数据池，再者月底数据，由于最后一天的数据切割不完整而造成的正月统计数量不准确。
报表的界面和输入输出测试
界面分为输入界面和输出界面；统一的界面要求：美观、统一、易操作。
输入界面要求是：
①输入项字段长度不允许超过字段长度；
②输入不符合字段要求的，不允许查询。
如money类型，在输入汉字，字母、特殊字符等不允许查询，并有友好的操作提示。
③用户权限范围外的输入，不允许查询。
如用户输入不是其权限范围内的客户号，不允许查询，并有友好的操作提示。
对于选项，应不出现可选择的用户权限以外的选项。
对于汉字模糊查询，考虑不常见字，如“�”即汉字因译码问题，造成的汉字存储出现乱码问题。
输出界面要求：
①因为是报表所以应该有打印、打印预览、报表导出等功能。
不能因为报表导出丢失数据，不能因为打印缺少了报表表格框
②报表排列方式可调，用户可按任意列升序或降序排列，或者，按某一关键列的一定规则排序
③报表标题明确，不能含糊误导用户
④报表内可关联查询的项，应能特殊显示，如鼠标有箭头变为手掌，子报表格式与父报表格式统一，数据统一。
报表测试根据项目的定义有大有小,有时只是作为软件的一个部分进行测试,有时整个项目都是测试各种报表.但不论如何,报表的作用始终都是将系统中已经存在的数据根据用户的设置计算加工/整理汇总/最终以清晰的格式展示给用户,以便用户进一步做数据分析或统计.
软件中的报表实现一般分为定义报表的所需数据(一般可以通过选择或手工输入条件来缩小数据范围)和定义报表格式两个部分.报表格式除了如国家各行业标准中规定的报表使用固定格式外,大多是根据企业或用户的需要定制报表.
所以,做报表测试时要注意以下方面:
1.数据的正确
用户使用报表就是期望通过一个简单方便的平台能快速的查找到他所需要的数据.所以在测试报表时首先就要检查报表中的数据是不是用户需要的数据,如果没有加工的数据,是否保持了原貌; 加工过的数据查看加工的结构是否和手工加工的结果一致.简言之,需要测试以下内容.
数据的来源：来源于哪张表,哪个字段,数据库中的数值与界面数据的对应.如数据库中性别的数据可能是0或1,但界面显示为男或女,这个对应关系是否正确.
数据的范围：是否只显示了报表设置的对应范围；特别要注意边界数据,要清楚报表的需求,是否需要过滤掉被选择的数据.如时间选择为2006-9-27~2007-9-27,那么是否应该包含9-27这天.
数据的对应关系：数据库中的字段是否与报表中的信息对应
数据的格式：小数位,千位符,四舍五入等是否与报表设置一致；单位或税率转换是否正确；组合显示的数据是否合理
数据的排序：排序方式是否与报表设置一致(如果没有设置,是否有一个清晰的默认排序方式,如按字母或数字排序)
流水号：如报表有使用流水号,流水号的生成和格式是否正确.取消操作是否会生成流水号.
明细与合计的一致性：各部分明细或小节是否与最后总和一致
其他
测试这一部分内容需要对业务逻辑相当熟悉,对数据库的设计也要非常了解.必要时可以通过自己写查询语句查看数据.
有些报表的条件有多有少,但测试方法都是一样.根据条件通过等价类划分和排列组合设置各种条件组合.千万不要盲目的测试,否则会导致该测的没测,多余的测试做了一堆..一般来说有类别划分的(一般界面表现为下拉框),每个类别都要测试到,如性别中的男,女都要测试.输入的可以用等价类来划分要测试的数据.
2. 格式的正确
数据验证正确后,就需要看看报表的输出格式是否符合要求.可以从以下几方面来检查.
报表的整体风格：报表是否符合规定的或用户设置的格式
报表标题：报表的标题是否是正确的报表名称；如报表中有嵌入的数据(会跟随用户的选择而变化的).需要检查数据是否正确,如XX企业9月份财务报表,这个9月就是用户选择的; 或者XX公司2006-9-27~2007-9-27的网站访问量,这个时间段也是用户选择的.
公司的一些标志：如logo,名称,地址之类的是否正确
报表的页首与页尾：是否采用了一致的规则.
分页：当输出的内容多时,分页是否正确.翻页功能是否正确
友好性：数据或图表是否清晰,一目了然,数据的展示符合用户的习惯；需要特别提醒的数据(如合计,异常数据)是否突出显示；复杂算法处,用户不明白或容易混淆处是否有注释；一些默认的格式是否让人感觉舒服,如对齐,边界,间隔等
3. 权限的控制
对于有权限控制的系统，报表当然也应该和用户所具有的权限相一致。
需要从两方面校验权限的控制。
报表的条件定义:在条件选择区域，有些下拉框中应该不能显示用户权限范围外的数据。
如普通文员在使用报表时，报表名称下拉框中是不可以显示管理者才能查看的报表的。
有些以输入的文本框有级别的划分时，都应该要测试输入超越权限的数据的相应。
注意这里一定要测试每个条目。
报表内容：报表中的内容不能显示用户本没有权限查看的数据。
4.报表的输出
报表在电脑上生成后，并不是报表的结束。
报表一般都需要打印出来他用，如开会或者提交审批之类。
所以报表的打印功能也是非常重要的。
测试主要分成三部分：
● 打印设置
● 打印预览
● 实际打印效果
除了打印之外，用户有可能需要导出报表做进一步的分析或用于和其他报表的比较。
所以也应该提供导出报表的功能。
一般可以导出为CSV,Excel,pdf,html,xml格式。