报表测试方法总结（合集5篇）

第一篇：报表测试方法总结

报表测试方法总结

1.提高对业务的熟悉程度

和功能测试以及其他测试一样，报表测试也需要熟悉业务，包括业务流程、业务规则以及数据存储，不同点是报表测试要理解每个指标的算法、数据来源以及要明白具体的业务动作和指标之间的关系，例如：要统计保费收入，首先要考虑正常保单，其次要考虑批增、批减以及注销、全单退以及其他特殊批改，这些业务类型都可以对此指标的统计结果产生影响。所以如果不能分析业务动作和指标之间的关系，那就无法验证报表中数据的准确性。

2.数据准备

数据对报表测试来说是非常重要的问题，因为报表的基本功能就是通过各种查询统计分析的方法为用户提供准确的数据，帮助用户进行决策以及分析，所以在报表测试前要保证准备足够多准确、有效的数据。在实际测试的时候一定要覆盖到报表所要求的每个维度,要保证所有的指标都要有对应的数据，不能出现指标为零的情况，当然也不需要过多，只要覆盖了所有的类型就可以了。一下总结了两种数据准备的方法：

1> 对测试后期比如冻结测试时产生的数据进行备份，用于报表测试，前提一定要保证数据的原始性，不允许对任何人对数据进行修改；

2> 自己手工对数据进行准备并且精心设计，要分析影响所测指标的各种因素，以及每个因素可能出现的不同变化，这样才有可能覆盖各种查询统计方法，并且要考虑需要考虑的是对各种正常的、异常的业务流程和业务规则的组合的遍历或覆盖,从而来验证报表是否取到的该取的数据、没有取不该取的数据，并且最后计算出了正确的结果。最后要将自己准备的数据用excel保存，并对数据的特点进行记录，以提高测试时的效率，并可以减少回归测试工作量；

3.数据正确性验证

对于客户来说，使用报表就是期望通过报表系统这个平台能够快速简单的查到自己所需要的数据，所以测试报表最主要的内容就是要验证数据的正确性，总结方法如下：1 > 要弄清楚数据的来源，来源于哪张表、哪个字段；> 时间条件：统计区间具体应该以业务中的什么时间在卡，并且考虑需求中是否包括统计区间的边界值；

3> 要弄清楚所测表以及所测指标的特定条件，比如要统计2009-01-01——2009-01-31 这个月份所有代理业务，那特定条件就是将保单的业务来源要限制在代理业务中； 4> Sql准备，这个过程是将上面三个过程进行总结，也是后续和开发人员进行分析数据的基础，所以提高自己编写sql的能力。另外当测试时间不充裕的情况下，对一

5>

6>

7>

8> 些简单的报表，如清单之类的报表就可以不用自己遍写sql语句，直接选出各种业务类型的单子进行单独分析； 数据核对以及分析，用sql查询出的数据要和开发人员的进行核对，由于有些数据量很大，所以最好借助对比工具（推荐：BCompare此软件），对于核对不上的数据要单独进行分析，分析的过程往往是发现问题主要环节，在这个过程中，如果自己实在分析不出来，则可以让开发人员协助； 数据的显示格式：小数位、千分符，百分号等是否与报表设置的一致，单位、汇率等是否进行转化，将有些代码是否转换成文字，比如被保险人性别，是否将系统中的0、1转化成男或女； 明细与合计的一致性:各部分明细值的和是否和总和一致等； 要覆盖所有的查询统计方式，在时间充分的条件下，要根据条件（筛选项、维度）

通过等价类划分和排列组合设置各种条件组合，每种都要测试到，千万不能按照自己的习惯为准；

4.报表格式的显示

在数据验证之后，要关注的就是输出报表的显示格式是否符合客户需求。报表的格式主要有两大类：

一、保险行业标准中规定的报表使用固定格式，如：保监会上报的一些报表，二：按照企业或者用户的需求定制的报表，所以对这两大类报表则需要从以下几个方面去测试：

1> 报表的整体显示格式是否符合客户提供的表样

2> 报表的标题或者表名是否正确

3> 报表页面的时间段是否是用户选择的时间段

4> 当输出的内容过多时，分页方式是否正确，翻页时，是否有与上页相同的样式（如

表头），第2页的输出是否正确

5> 需要特别提醒的数据（一些异常数据）是否突出显示，有些指标计算方法特别复杂

或者有几个指标容易混淆时是否在页面有加注释

5.报表之间的可比性

在纵向的测试完成后，我们要将所测试的报表进行横向联系，因为有些报表虽然名称不一样，但是有些指标是一样的，这样我们就需要将这两张报表哪起来进行比较，看在相同的时间段内是否统计出的结果都是一样的。另外不同报表的不同指标之间也是有联系的，如：业务中的应收保费清单和财务中的应收保费科目余额，当两者统计口径一致的时候，清单中的应收保费的合计则等于财务应收科目的余额，还有保费收入、实收保费、应收保费在同一统计区间总保费收入 = 实收保费 + 应收保费（未实收到的），所以在测试过程中，一定要理清它们之间的层次、顺序，这就需要加强对业务的理解和知识的积累！

6.其他

1> 报表的输出以及打印

报表在系统中生成后,并没有结束.报表一般都需要打印出来供客户使用用,例如开会或者提交审批之类.所以报表的打印功能也是非常重要的.在打印之前,用户一般都需要导出报表做进一步的分析或用于和其他报表的比较.所以也要验证报表的导出功能.一般可以导出的主要格式是Excel,pdf格式,然后要验证导出的内容是否正确,与生成的报表相一致.2> 报表的性能

尽量要求开发人员采用最优的查询语句，避免客户在使用过程中等待时间过长 3> 报表的权限

对于有权限控制的系统,报表当然也应该和用户所具有的权限相一致.需要从两方面校验权限的控制.报表的条件定义:在条件选择区域,有些下拉框中应该不能显示用户权限范围外的数据.备注：目前这部分内容测试比较少，之前客户没有提出权限这方面的需求，但是最近在使用过程中，客户提出过，要求分公司人员只能查出自己分公司的清单，允许总公司查出所有的符合要求的清单，估计在后续还会提出类似这样的要求，所以这部分后续要需要加强测试。

第二篇：软件测试中报表测试用例设计方法总结

软件测试中报表测试用例设计方法总结

报表的测试主要分为以下几个方面:界面,安全性,准确性,展示速度(性能)

数据统计方面

1、报表统计数据的正确性；

2、报表统计数据的完整性；

3、报表统计数据的合法性；比如，统计金额字段需求要求有“$”等；

报表格式

1、表头字段表示的正确性；

2、表头字段表示的完整性；

3、表头字段表示的字体，字号，美观程度；

4、各统计字段的显示是否满足需求；比如：数据过长时要求折行还是缩小；

5、页眉和页角的表示；

报表的预览和印刷

1、预览中的显示完整性；

2、多页情况下，第2页的表头显示；

3、能否实现需求要求的特定印刷情况；（比如，印刷使用指定的模板）

4、预览后印刷；

5、不预览，直接印刷

6、需求规定各类打印机的测试；

数据准确性测试，带有报表测试的系统分为两类，一类是业务系统中，带有统计分析功能模块，该模块中包含分析报表，这个系统的主体是业务系统，报表是为办理业务的而提供帮助的。

比如说，应年检统计报表，某月应交罚款车辆统计报表，这样的报表数据准确与否，可通过增加、删减、修改相关业务或相关业务的参数，查看统计报表数据变化，检查数据准确性。

另一类是系统只有统计功能，就是我说的数据仓库展现这类，它与业务系统分离，并且经过多层处理，比如数据仓库的数据，经过抽取，清洗，展现前会经过数据挖掘，数据再处理，有些字段在原始数据表中根本就没有。这样的数据准确性测试比较复杂，当然检查出数据错误，修改定位也是很不容易的。

从整个项目节约成本看，逐层测试效果是最好的。完全修改率也是最高的。

首先建立测试数据模型，模拟所有应用表，建立简单易跟踪的数据用例，底层的数据表测试，方法很原始，嘿嘿，通过SQL语句和手工计算，对数据进行比对。对系统中的报表数据准确性测试方法较为灵活，①系统中报表重叠的进行比对

②对子报表汇总与父报表比对，就是对月报表汇总与年报表比对，日报表汇总与月报表比对，这只是一个方面，可以从维度关系考虑，地域，行政级别、时间，个人等方面下手，进行汇总比对

③这个方法如果延伸点呢，可以将报表间的业务逻辑关系作为比对依据。呵呵，这要看测试人员的需求了解深度个人能力了。插几句不想干的话，做测试工作总让我保持快乐状态，前两天我的一个同事说，公司里一直没有人喜欢做测试工作，这个工作太枯燥。嘿嘿，我当时就说我做了这么多年的测试工作从来没有感觉到枯燥。重复性工作不代表枯燥，编程其实不也是重复嘛，人每天谁不重复昨天的事啊，吃饭，吃这个动作重复一生，有谁觉得麻烦枯燥啦？

④使用SQL和手工计算进行比对。以上是差错方式，接下来讲一下查什么错？哪些地方容易出错

●原始表使用错误：因为表比较多，又加上没有统一的数据关系对应表，很容易表使用错误，当然这应该是单元测试检查出来的错误。

●数据处理逻辑错误：这一点容易因为测试人员和开发人员对需求理解有偏差造成争执，所以在需求评审时，对数据处理规则用表达式或伪代码表示清楚。还有就是程序员失误，逻辑编写有偏差，边界值、特殊情况处理不当。

●数据权限：不同用户对数据有着不同的查看权限。这关系到数据的安全性。

●数据误差：数据的保留位数，数据是否是处理计算是否是最后一次计算使用了位数保留和四舍五入。

●由于字典表，数据错误，而造成的数据错误，如，根据性别统计，购买量，表中的男女颠倒，或者没有考虑性别缺失项，用了ifelse,这样就是把表中缺失该项内容的算成了else条件里。或者逻辑中应该考虑用户状态，数据状态类似的字段，容易被忽略，测试应该考虑到。

●最后一项，当数据量相当大的时候，统计应该考虑，切割速度，也就是数据的完整性，由于数据切割的滞后，带来的数据不完整，而造成统计结果不完整。如统计昨天的销售情况，而昨天的数据并没有完全从业务系统数据到数据池，再者月底数据，由于最后一天的数据切割不完整而造成的正月统计数量不准确。

报表的界面和输入输出测试

界面分为输入界面和输出界面；统一的界面要求：美观、统一、易操作。

输入界面要求是：

①输入项字段长度不允许超过字段长度；

②输入不符合字段要求的，不允许查询。如money类型，在输入汉字，字母、特殊字符等不允许查询，并有友好的操作提示。

③用户权限范围外的输入，不允许查询。如用户输入不是其权限范围内的客户号，不允许查询，并有友好的操作提示。

对于选项，应不出现可选择的用户权限以外的选项。

对于汉字模糊查询，考虑不常见字，如“?”即汉字因译码问题，造成的汉字存储出现乱码问题。

输出界面要求：

①因为是报表所以应该有打印、打印预览、报表导出等功能。不能因为报表导出丢失数据，不能因为打印缺少了报表表格框

②报表排列方式可调，用户可按任意列升序或降序排列，或者，按某一关键列的一定规则排序

③报表标题明确，不能含糊误导用户

④报表内可关联查询的项，应能特殊显示，如鼠标有箭头变为手掌，子报表格式与父报表格式统一，数据统一。

报表测试根据项目的定义有大有小,有时只是作为软件的一个部分进行测试,有时整个项目都是测试各种报表.但不论如何,报表的作用始终都是将系统中已经存在的数据根据用户的设置计算加工/整理汇总/最终以清晰的格式展示给用户,以便用户进一步做数据分析或统计.软件中的报表实现一般分为定义报表的所需数据(一般可以通过选择或手工输入条件来缩小数据范围)和定义报表格式两个部分.报表格式除了如国家各行业标准中规定的报表使用固定格式外,大多是根据企业或用户的需要定制报表.所以,做报表测试时要注意以下方面:

1.数据的正确

用户使用报表就是期望通过一个简单方便的平台能快速的查找到他所需要的数据.所以在测试报表时首先就要检查报表中的数据是不是用户需要的数据,如果没有加工的数据,是否保持了原貌;加工过的数据查看加工的结构是否和手工加工的结果一致.简言之,需要测试以下内容.数据的来源：来源于哪张表,哪个字段,数据库中的数值与界面数据的对应.如数据库中性别的数据可能是0或1,但界面显示为男或女,这个对应关系是否正确.数据的范围：是否只显示了报表设置的对应范围；特别要注意边界数据,要清楚报表的需求,是否需要过滤掉被选择的数据.如时间选择为200627~200727,那么是否应该包含9-27这天.数据的对应关系：数据库中的字段是否与报表中的信息对应

数据的格式：小数位,千位符,四舍五入等是否与报表设置一致；单位或税率转换是否正确；组合显示的数据是否合理

数据的排序：排序方式是否与报表设置一致(如果没有设置,是否有一个清晰的默认排序方式,如按字母或数字排序)

流水号：如报表有使用流水号,流水号的生成和格式是否正确.取消操作是否会生成流水号.明细与合计的一致性：各部分明细或小节是否与最后总和一致

其他

测试这一部分内容需要对业务逻辑相当熟悉,对数据库的设计也要非常了解.必要时可以通过自己写查询语句查看数据.有些报表的条件有多有少,但测试方法都是一样.根据条件通过等价类划分和排列组合设置各种条件组合.千万不要盲目的测试,否则会导致该测的没测,多余的测试做了一堆..一般来说有类别划分的(一般界面表现为下拉框),每个类别都要测试到,如性别中的男,女都要测试.输入的可以用等价类来划分要测试的数据.2.格式的正确

数据验证正确后,就需要看看报表的输出格式是否符合要求.可以从以下几方面来检查.报表的整体风格：报表是否符合规定的或用户设置的格式

报表标题：报表的标题是否是正确的报表名称；如报表中有嵌入的数据(会跟随用户的选择而变化的).需要检查数据是否正确,如XX企业9月份财务报表,这个9月就是用户选择的;或者XX公司200627~200727的网站访问量,这个时间段也是用户选择的.公司的一些标志：如logo,名称,地址之类的是否正确

报表的页首与页尾：是否采用了一致的规则.分页：当输出的内容多时,分页是否正确.翻页功能是否正确

友好性：数据或图表是否清晰,一目了然,数据的展示符合用户的习惯；需要特别提醒的数据(如合计,异常数据)是否突出显示；复杂算法处,用户不明白或容易混淆处是否有注释；一些默认的格式是否让人感觉舒服,如对齐,边界,间隔等

3.权限的控制

对于有权限控制的系统，报表当然也应该和用户所具有的权限相一致。需要从两方面校验权限的控制。

报表的条件定义:在条件选择区域，有些下拉框中应该不能显示用户权限范围外的数据。如普通文员在使用报表时，报表名称下拉框中是不可以显示管理者才能查看的报表的。有些以输入的文本框有级别的划分时，都应该要测试输入超越权限的数据的相应。

注意这里一定要测试每个条目。

报表内容：报表中的内容不能显示用户本没有权限查看的数据。

4.报表的输出

报表在电脑上生成后，并不是报表的结束。报表一般都需要打印出来他用，如开会或者提交审批之类。所以报表的打印功能也是非常重要的。测试主要分成三部分：

●打印设置

●打印预览

●实际打印效果

除了打印之外，用户有可能需要导出报表做进一步的分析或用于和其他报表的比较。所以也应该提供导出报表的功能。一般可以导出为CSV,Excel,pdf,html,xml格式。

第三篇：软件测试方法总结

软件测试方法总结

（一）发布时间: 2008-12-12 17:07作者: lxm_lxm来源: 51Testing论坛

软件测试方法的总结，是lxm_lxm根据个人所做过的项目整理的，提供给新来的的朋友们。软件测试方法总结

一、界面

● 界面测试

（1）测试界面设计是否合理、简洁、美观，操作是否方便

（2）功能键、数据项信息是否齐全

（3）确认系统中同一功能抌名称是否统一

（4）设计样式、风格（查询条件样式；输入风格（点选/手输入）；）是否与系统其它模块统一

（5）确认页面内所有字段名称显示风格是否统一（居中、左对齐、右对齐，一般采用居中显示风格）

1、新增页面及功能测试

● 字段

在开始测试时应该保证数据的正确性，然后再从系统中找出各种Bug

（1）各字段输入正确的信息值保存，确认系统是否可以正确完成新增操作。

（2）进入添加界面不输入任何信息值，单击“保存”功能按钮，系统应该给出某个不允许为空字段的提示信息（属于边界测试）

（3）建议不允许为空的字段前面加上„*‟作为标记（统一性，方便性问题）

（4）编码/编号字段不允许输入中文及特殊字符，否则系统应该给出相应的提示信息

（5）测试编码/编号字段不允许重复，否则系统应该给出相应的提示信息

（6）确认字段是否已做长度限制，如果输入值超出长度范围，那么在保存时系统应该给出提示信息

（7）非法测试，如：校验数值型字段输入非数值，保存时系统是否给出相应的提示信息（根据实际需要确定数值型字段是否能够接受负数）

（8）边界测试，如：确认数值型字段的边界值（如：有效值为„0-100‟整数，那么输入-1或101保存时系统应该给出相应的提示信息；输入值为0、100系统应该能正确保存信息值；输入0到100内的整数值系统应该正确保存信息值）

（9）精确值测试，测试小数位数是否在定义的长度内

（10）字段精确值是否正确（四舍五入否）。

（11）根据实际情况测试名称字段是否具有唯一性，（一般情况下名称是不允许重复的，具体问题具体分析），否则系统应该给出相应的提示信息

（12）确认各字段名称书写是否正确（注意：要求编辑界面、住息列表中、错误提示信息、查询条件中的字段名称完全相同）

（13）确认特殊格式的字段是否已做标准格式的限制（如：电子邮件、邮编等）

（14）测试上级信息字段（如：上级XXX名称、上级XXX编号）的信息值是否根据所选择的上级XXX名称系统自动生成（注意：编号生成值一定是维护界面的编号，而不应该是相应表的那个主键编码）

（15）测试如果某字段信息值是从另一个模块中选择输入的，那么需要确认其它相关联字段的信息值是否也相应的正确的自动带入，并且这些字段应该都是只读的（16）创建人/编辑人、发布人、创建时间、创建人字段应该设为只读的，而且此类字段值应该默认当前操作人的姓名

（17）如果某个字段可以点选输入多个信息值，那么测试该字段是否接受，并保存了点选输入的多个信息值

（18）对于多选字段，测试是否具有记忆上次选择值并已验重

（19）测试字符型字段是否可以接受空格（统一性问题，建议不要接受空格）

（20）引用其它模块的字段信息值的字段长度是否与被引用模块相应字段长度一致

软件测试方法总结

（二）发布时间: 2008-12-12 17:13作者: lxm_lxm来源: 51Testing论坛

关键字：软件测试方法

6、常用功能键的功能测试

（1）保存---所有编辑页面如果未输入任何信息值而单击“保存”，系统应该给出“XXX字段不允许为空”的提示信息

（2）保存---如果某字段输入值有错误或超出长度范围，那么单击“保存”按钮时，系统应该给出相应的提示信息

（3）保存---输入相关信息单击“保存”后，建议系统给出“保存成功”提示信息

（4）保存---测试新增/修改信息保存后，信息列表是否自动刷新

（5）下一步---单击此按钮，如果有非空字段为空，系统应该给出相应提示信息；如果有字段输入非法值，单击此按钮系统应该给出相应提示信息；正常情况下单击此功能按钮，系统进入到下一个编辑/操作界面

（6）上一步---单击此功能按钮，系统应该正确返回到上一个编辑/操作界面

（7）浏览---测试该功能键功能是否已经正确实现，单击此按钮系统应该弹出文件选择页面，并且可以选择输入相关附件

（8）上传附件---测试上传功能已经正确实现，确认上传的附件在界面相应位置是否显示

（9）下载---测试下载功能已经正确实现（可以将上传到服务器的附件下载的本地相应位置）

（10）重新上传---保存操作后上传功能按钮名称应该自动变为“重新上传”，并且可以重新上传附件

（11）发布---测试该功能键功能已经正确实现，单击些功能按钮系统完成发布操作，相应的信息状态变为“已发布”，发布人、发布时间系统自动生成或已经正确保存（注意：已经发布的信息是不允许再进行修改操作的）（根据系统需求及设计测试，有些系统只有信息修改页面才有此功能）

（12）取消发布---测试该功能键功能是否已经正确实现，单击此功能按钮系统完成取消发布功能，相应信息状态变为“未发布”（根据系统需求及设计测试，有些系统只有信息修改页面才有此功能）

（13）关闭---单击此功能按钮系统将关闭当前页面，建议当单击此功能按钮时系统弹出“确认离开此页面提示信息”

（14）查询---单击查询功能按钮，系统按钮输入查询条件进行模糊查询；查询条件输入非法值进行查询操作，系统应该查询0记录

（15）删除----未勾选待删除记录单击此按钮系统弹出相应提示信息；正常情况下系统删除所选记录

（16）选择---勾选待选记录，单击此按钮系统完成选择操作；单击选择超链接功能按钮系统完成选择操作

（17）取消选择---单击此功能按钮，系统完成取消选择操作（清除所有选择信息）

软件测试方法总结

（三）发布时间: 2008-12-12 17:14作者: lxm_lxm来源: 51Testing论坛

关键字：软件测试方法

11、对用户名、密码的有效性测试

（1）密码信息有效性测试：特殊字符、正常字符、空字符（不输入）、空格

（2）登陆名是否区分大小写

（3）登陆名是否允许重名

（4）用户名字和密码都为最大长度（边界值分析，取上点）

（5）用户名字和密码都为最小长度（边界值分析，取上点）

（6）用户名字和密码都是非最大和最小长度的数据（边界值分析，取内点）

（7）用户名长度大于要求1位（边界值分析，取离点）

（8）用户名长度小于要求1位（边界值分析，取离点）

（9）密码长度大于要求1位（边界值分析，取离点）

（10）密码长度小于要求1位（边界值分析，取离点）

（11）是否记住上次登陆名

（12）密码信息有效性测试：字母数字混排、数字、符号数字、字母符号、数字符号、空字符（不输入）、空格、ASCII字符、字符串在有空格、串在有半角空格

（13）口令锁定：即输入口令次数的限制

（14）密码显示是否以星号或者别的符号显示

（15）看是否支持tap和enter键等

（16）密码是否可以复制粘贴

密码修改测试方法

（1）不输入旧密码，直接改密码

（2）输入错误旧密码

（3）不输入确认新密码

（4）不输入新密码

（5）新密码和确认新密码不一致

（6）新密码中有空格

（7）新密码长度有效性测试方法同上

（8）新密码为非允许字符（如有的密码要求必须是英文和数字组成，那么要试汉字和符号等）

（9）测试密码是否区分大小写，新密码中英文小写，确认密码中英文大写

（10）新密码与旧密码一样能否修改成功

软件测试方法总结

（四）发布时间: 2008-12-12 17:17作者: lxm_lxm来源: 51Testing论坛

关键字：软件测试方法

四、权限测试

1、业务权限

按需求测试用户业务权限分配是否正确，业务权限主要控制功能模块、功能菜单的展示，没有相应业务权限的不展示其功能模块能功能菜单。

2、操作权限

（1）权限组：按组用户来分配操作权限。（组内所有人员都具有所分配的操作权限）

（2）测试已分配操作权限的功能按钮是可见的（3）测试已分配操作权限的功能按钮是否可用；是否可以正确完成相应功能操作

（4）通常不分配调看操作权限是无法进行修改操作

五、算法

1、测试前需要充分了解算法的整个计算过程及结果值的精度

2、算法测试之前需要准备充足，而且是准确无误的测试实例

3、根据输入值确认系统计算输出结果是否与预期结果完全一致

4、如果计算公式中含有引用其它模块的数据，需要先确认数据提取是否对应的正确

5、先用等价划分法、边界值测试方法测试输入数据是否在需求范围内

6、严格按照测试用例执行测试，确认计算结果是否正确无误，注意结果的精度。

第四篇：App测试方法总结

一、安全测试 1.软件权限

1）扣费风险：包括短信、拨打电话、连接网络等。

2）隐私泄露风险：包括访问手机信息、访问联系人信息等。

3）对App的输入有效性校验、认证、授权、数据加密等方面进行检测 4）限制/允许使用手机功能接入互联网 5）限制/允许使用手机发送接收信息功能 6）限制或使用本地连接

7）限制/允许使用手机拍照或录音 8）限制/允许使用手机读取用户数据 9）限制/允许使用手机写入用户数据

10）限制/允许应用程序来注册自动启动应用程序 2.安装与卸载安全性

1）应用程序应能正确安装到设备驱动程序上

2）能够在安装设备驱动程序上找到应用程序的相应图标 3）安装路径应能指定

4）没有用户的允许，应用程序不能预先设定自动启动 5）卸载是否安全，其安装进去的文件是否全部卸载 6）卸载用户使用过程中产生的文件是否有提示 7）其修改的配置信息是否复原 8）卸载是否影响其他软件的功能 9）卸载应该移除所有的文件 3.数据安全性

1）当将密码或其它的敏感数据输入到应用程序时，其不会被存储在设备中，同时密码也不会被解码。2）输入的密码将不以明文形式进行显示。

3）密码、信用卡明细或其他的敏感数据将不被存储在它们预输入的位置上。4）不同的应用程序的个人身份证或密码长度必须至少在4-8个数字长度之间。

5）当应用程序处理信用卡明细或其它的敏感数据时，不以明文形式将数据写到其他单独的文件或者临时文件中。以防止应用程序异常终止而又没有删除它的临时文件，文件可能遭受入侵者的袭击，然后读取这些数据信息。

6）党建敏感数据输入到应用程序时，其不会被存储在设备中。7）应用程序应考虑或者虚拟机器产生的用户提示信息或安全警告

8）应用程序不能忽略系统或者虚拟机器产生的用户提示信息或安全警告，更不能在安全警告显示前，利用显示误导信息欺骗用户，应用程序不应该模拟进行安全警告误导用户。

9）在数据删除之前，应用程序应当通知用户或者应用程序提供一个“取消”命令的操作。10）应用程序应当能够处理当不允许应用软件连接到个人信息管理的情况。

11）当进行读或写用户信息操作时，应用程序将会向用户发送一个操作错误的提示信息。12）在没有用户明确许可的前提下不损坏删除个人信息管理应用程序中的任何内容。13）如果数据库中重要的数据正要被重写，应及时告知用户。14）能合理的处理出现的错误。15）意外情况下应提示用户。4.通讯安全性

1）在运行软件过程中，如果有来电、SMS、蓝牙等通讯或充电时，是否能暂停程序，优先处理通信，并在处理完毕后能正常恢复软件，继续其原来的功能。2）当创立连接时，应用程序能够处理因为网络连接中断，进而告诉用户连接中断的情况。3）应能处理通讯延时或中断。

4）应用程序将保持工作到通讯超时，进而给用户一个错误信息指示有链接错误。5）应能处理网络异常和及时将异常情况通报用户。6）应用程序关闭网络连接不再使用时应及时关闭，断开。5.人机接口安全测试

1）返回菜单应总保持可用。2）命令有优先权顺序。

3）声音的设置不影响使用程序的功能。4）声音的设置不影响应用程序的功能

5）应用程序必须能够处理不可预知的用户操作，例如错误的操作和同时按下多个键。

二、安装、卸载测试

验证App是否能正确安装、运行、卸载、以及操作过程和操作前后对系统资源的使用情况 1.安装

1）软件安装后是否能够正常运行，安装后的文件夹以及文件是否写到了指定的目录里。2）软件安装各个选项的组合是否符合概要设计说明。3）软件安装向导的UI测试

4）安装后没有生成多余的目录结构和文件。2.卸载

1）测试系统直接卸载程序是否有提示信息。

2）测试卸载后文件是否全部删除所有的安装文件夹。3）卸载是否支持取消功能，单击取消后软件卸载的情况。4）系统直接卸载UI测试，是否有卸载状态进度条提示。

三、UI测试

1）测试用户界面（如菜单、对话框、窗口和其他控件）布局、风格是否满足要求、文字是否正确、页面是否美观、文字、图片组合是否完美、操作是否友好等。

2）UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。1.导航测试

1）按钮、对话框、列表和窗口等；或在不同的连接页面之间需要导航。2）是否易于导航，导航是否直观。3）是否需要搜索引擎。4）导航帮助是否准确直观。

5）导航与页面结构、菜单、连接页面的风格是否一致。2.图形测试

1）横向比较，各控件操作方式统一。

2）自适应界面设计，内容根据窗口大小自适应。3）页面标签风格是否统一。4）页面是否美观。

5）页面的图片应有其实际意义而要求整体有序美观。3.内容测试

1）输入框说明文字的内容与系统功能是否一致。2）文字长度是否加以限制。3）文字内容是否表意不明。4）是否有错别字。5）信息是否为中文显示。

四、功能测试

根据软件说明或用户需求验证App的各个功能实现，采用如下方法实现并评估功能测试过程： 1）采用时间、地点、对象、行为和背景五元素或业务分析等方法分析、提炼App的用户使用场景，对比说明或需求，整理出内在、外在及非功能直接相关的需求，构建测试点，并明确测试标准。2）根据被测功能点的特性列出相应类型的测试用例对其进行覆盖，如：设计输入的地方需要考虑等价、边界、负面、异常、非法、场景回滚、关联测试等测试类型对其进行覆盖。

3）在测试实现的各个阶段跟踪测试实现与需求输入的覆盖情况，及时修正业务或需求理解错误。1.运行

1）App安装完成后的试运行，可正常打开软件。2）App打开测试，是否有加载状态进度提示。3）App页面间的切换是否流畅，逻辑是否正确。4）注册

     同表单编辑页面 用户名密码长度 注册后的提示页面

前台注册页面和后台的管理页面数据是否一致 注册后，在后台管理中页面提示

5）登录

  使用合法的用户登录系统

系统是否允许多次非法的登录，是否有次数限制        使用已经登录的账号登录系统是否正确处理 用户名、口令（密码）错误或漏填时能否登陆 删除或修改后的用户，原用户名登陆

不输入用户口令和重复点“确定/取消”按钮，是否允许登录 登陆后，页面中登录信息 页面中有注销按钮 登录超时的处理

2.应用的前后台切换

1）App切换到后台，再回到App，检查是否停留在上一次操作界面。2）App切换到后台，再回到App，检查功能及应用状态是否正常。

3）App切换到后台，再回到前台时，注意程序是否崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候。

4）手机锁屏解锁后进入App注意是否会崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候。

5）当App使用过程中有电话进来中断后再切换到App，功能状态是否正常。6）当杀掉App进城后，再开启App，App能否正常启动。

7）出现必须处理的提示框后，切换到后台，再切换回来，检查提示框是否还存在，有时候会出现应用自动跳过提示框的缺陷。

8）对于有数据交换的页面，每个页面都必须要进行前后台切换、锁屏的测试，这种页面最容易出现崩溃。3.免登陆

很多应用提供免登陆功能，当应用开启时自动以上一次登录的用户身份来使用App。1）考虑无网络情况时能否正常进入免登录状态。

2）切换用户登陆后，要校验用户登录信息以及数据内容是否相应更新，确保原用户退出。

3）根据Mtop的现有规则，一个账户只允许登陆一台机器。所以，需要检查一个账户登录多台手机的情况。原手机里的用户需要被退出，给出友好提示。4）App切换到后台，在切换回前台的校验。5）切换到后台，再切换回到前台的测试。

6）密码更换后，检查有数据交换时是否进行了有效身份的校验。

7）支持自动登录的应用在进行数据校验时，检查系统是否能自动登录成功并且数据操作无误。8）检查用户主动退出登录后，下次启动App，应停留在登录界面。4.离线浏览

很多应用会支持离线浏览，即在本地客户端会缓存一部分数据供用户查看。1）在无线网络情况可以浏览本地数据。2）退出App再开启App时能正常浏览。3）切换到后台再回到前台可以正常浏览。4）锁屏后再解锁回到应用前台可以正常浏览。

5）在对服务器段的数据有更新时回给予离线的相应提示。5.App更新

1）当客户端有新版本时，有更新提示。

2）当版本为非强制升级版时，用户可以取消更新，老版本能正常使用。用户在下次启动App时，仍出现更新提示。

3）当版本为强制升级版时，但给出强制更新后用户没有做更新时，退出客户端。下次启动App时，仍出现强制升级提示。4）当客户端有新版本时，在本地不删除客户端的情况下，直接更新检查是否能正常更新。

5）当客户端有新版本时，在本地不删除客户端的情况下，检查更新后的客户端功能是否是新版本。6）当客户端有新版本时，在本地不删除客户端的情况下，检查资源同名文件如图片是否能正常更新成最新版本。如果以上无法更新成功的，也都属于缺陷。6.定位、照相机服务

1）App有用到相机，定位服务时，需要注意系统版本差异。

2）有用到照相机服务的地方，需要进行前后台的切换测试，检查应用是否正常。3）测试照相机服务时，需要采用真机进行测试。7.PUSH测试

1）检查Push消息是否按照指定的业务规则发送。

2）检查不接收推送消息时，用户不会在接收到Push消息。

3）如果用户设置了免打扰的时间段，检查在免打扰时间段内，用户接收不到Push。在非免打扰时间段内，用户能正常收到Push。

4）当Push消息是针对登录用户的时候，需要检查收到的Push与用户身份是否相符，没有错误的将其他人的消息推送过来。一般情况下，只对手机上最后一个登录用户进行消息推送。5）测试Push时，需要采用真机进行测试。

五、性能测试

1）响应能力测试：测试App中的各类操作是否满足用户响应时间要求。

  App安装、卸载的响应时间 App各类功能性操作的响应时间

2）压力测试，反复/长期操作下，系统资源是否占用异常。

 App反复进行安装卸载，检查系统资源是否正常  其他功能反复进行操作，检查系统资源是否正常

六、交叉事件测试

针对智能终端应用的服务等级划分方式及实时特性所提出的测试方法。交叉测试又叫事件或冲突测试，是指一个功能正在执行过程中，同时另外一个事件或操作对该过程进行干扰的测试。如：App在前/后台运行状态时与来电、文件下载、音乐收听等关键运用的交互情况测试等。交叉事件测试非常重要，能发现很多应用中潜在的性能问题。1）多个App同时运行是否影响正常功能。2）App运行时前/后台切换是否影响正常功能。3）App运行时拨打/接听电话。4）App运行时发送/接收信息。5）App运行时发送/收取邮件。6）App运行时浏览网络。

7）App运行时使用蓝牙传送/接收数据。

8）App运行时使用相机、计算器等手机自带设备。

七、兼容测试

主要测试内部和外部兼容性 1）与本地及主流App是否兼容

2）与各种设备是否兼容，若有跨系统支持则需要检验是否在个系统下，各种行为是否一致。

  不同手机屏幕分标率的兼容性 不同手机品牌的兼容性

八、回归测试

1）Bug修复后且在新版本发布后需要进行回归测试。2）Bug修复后的回归测试在交付前、要进行大量用例的回归测试。

九、用户体验测试

以主观的普通消费者的角度去感知产品或服务的舒适、有用、易用、友好亲切程度。通过不同个体、独立空间和非经验的统计复用方式去有效评价产品的体验特性，提出修改意见提升产品的潜在客户满意度。

1）是否有空数据界面设计，引导用户去执行操作。2）是否滥用用户引导。

3）是否有不可点击的效果，如：你的按钮此时处于不可用状态，那么一定要灰掉，或者拿掉按钮，否则会给用户误导。4）菜单层次是否太深。5）交互流程分支是否太多。6）相关的选项是否离的很远。7）一次是否载入太多的数据。8）界面中按钮可点击范围是否适中。

9）标签页是否跟内容没有从属关系，当切换标签的时候，内容跟着切换。10）操作应该有主次从属关系。

11）是否定义Back的逻辑。涉及软硬件交互时，Back键应具体定义。12）是否有横屏模式的设计，应用一般需要支持横屏模式，即自适应设计。

十、手势操作测试

1）手机开锁屏对运行中的App的影响。2）运行中的App前后台切换的影响。3）多个运行中的App的切换。4）App运行时关机。5）App运行时重启系统。6）App运行时充电

7）App运行时Kill掉进程再打开

十一、客户端数据库测试 1）一般的增、删、改、查测试。

2）当表不存在时是否能自动创建，当数据库表被删除后能否再自建，数据是否还能自动从服务器中获取回来并保存。

3）在业务需要从服务器端取回数据保存到客户端的时候，客户端能否将数据保存到本地。

4）当业务需要从客户端取数据时，检查客户端数据存在时，App数据是否能自动从客户端数据中取出，还是仍然会从服务器端获取？检查客户端数据不存在时，App数据能否自动从服务器端获取到并保存到服务器端。

5）当业务对数据进行了修改、删除后，客户端和服务器端是否会有相应的更新。

第五篇：SIT测试方法总结

SIT测试方法总结

测试人员介入时机

对于SIT测试，测试人员最佳介入时间为需求分析阶段，在需求分析阶段就介入测试可以使测试人员更高效充分的了解需求，从而提高后面测试用例编写及测试用例执行的效率。

制定测试方案

测试人员进入项目后首要任务是制定测试方案。制定测试方案的目的： 1.明确测试目的。2.制定本次测试范围。3.阐述本次测试的策略。

4.罗列测试过程中可能遇到的风险及应对措施。5.安排测试人员的任务。

6.确定测试实施过程中需要准备的数据。

7.确定测试阶段的轮次及各项测试工作的时间节点。8.制定缺陷分级的级别描述以及缺陷修复的时效。以上8点作为测试方案的重要内容。测试方案编写后，与项目组其他人员以及客户方一起参与测试方案的评审工作；对测试方案评审完成后测试方案正式定稿。

案例对需求的覆盖

测试案例对需求的覆盖率直接关系到测试质量，如果覆盖率不够则系统中隐藏的缺陷无法被发现，存在严重的质量风险。提高案例的覆盖率有效的方法：

1.提高测试人员对需求的理解，对需求进行逐字逐句的分析将显性与隐性的功能点充分挖掘出来。

2.测试人员在编写测试用例之前先编写测试大纲，罗列出功能点并与需求人员一同对测试大纲进行评审，找出遗漏的测试点。

3.测试大纲评审完成后根据测试大纲所罗列的测试点进行测试案例编写，编写完成后与开发人员、需求人员一同对案例进行评审，找出潜在的遗漏部分。

案例编写策略（易读易执行优先级等）

1.测试用例编写遵循以下大体分类：界面及字段显示，字段取值规则，模块功能，上下游模块功能关联。2.用例应包括以下内容：功能，子功能，优先级，用例类型，测试点，操作步骤，预期结果。

编写是功能子功能描述清晰，一条用例对应一个测试点和唯一的预期结果。操作步骤编写是简单易懂具有很好的可操作性，测试点、预期结果需言简意赅可读性强。

3.案例优先级的确定规则一般为：模块功能＝上下游模块功能关联＞字段取值规则＞界面及字段显示。

制定测试计划及测试资源分配（工作量轮次）

1.测试用例编写完成后对测试实施制定测试计划，计划按照单个测试人员每日预估执行案例数，测试人员数量，测试用例总量计算出需要的测试实施时间，如测算出的时间超过测试方案中计划时间时需要与项目负责人沟通延长测试时间或者增加测试资源。（每个人每天的工作量是有限的所以不可以通过总量/时间/人数来倒退每人每日需执行的数量）。

2.测试实施过程需经过三个阶段：准入测试阶段，第一轮测试阶段，第二轮测试阶段。

第二轮测试阶段在第一轮测试的案例中选取，选择策略：在一轮测试中该模块测试情况不良好，缺陷较多则在二轮中着重测试；系统的重要功能需在二轮中着重测试；一轮中缺陷优先级高的再二轮中着重测试。

3.测试用例在执行时有难易之分，为了保证测试人员可以完成计划中的工作量，在分配时要综合考虑有所区分。

实施过程中的策略

1.测试用例的难易程度存在两个维度：用例所属模块，用例优先级；当用例的所属模块功能操作较易时则可不考虑用例的优先级；当用例的所属模块功能操作以及需要准备的数据比较复杂时则需要优先执行用例优先级较高的用例。

2.测试人员被分配需执行的用例后首先要做的是纵览一遍需要执行的用例，对用例需要的数据进行整合，使用最少的数据来覆盖所需执行的用例。

3.在测试中遇到阻碍性问题导致后续功能测试进度延迟，此时需组织复杂该模块开发的骨干人员联合测试人员在该模块进入测试阶段之前进行调通，以便于测试人员按照测试计划开始该模块测试时不会发生严重的阻碍性缺陷，可以有效的提高测试效率。

缺陷的处理

1.使用测试工具提交缺陷时需填写完整功能模块，问题描述简单易懂并附上截图，标明使用的数据编号，使用的用户。

2.提交缺陷时缺陷级别严格按照测试方案中所制定的缺陷等级标准。

3.开发人员将缺陷状态指为已解决后测试人员在关闭时需复测，同时将复测通过的截图记录在测试工具中。

4.对于缺陷修复的时效需要实时关注，特别对于优先级高且影响测试进度的缺陷需要重点跟踪直到被解决。附件：

1.测试方案与计划：测试方案与计划.xlsx

2.测试案例模板：测试案例.xlsx