第一篇:软件测试中报表测试用例设计方法总结
软件测试中报表测试用例设计方法总结
报表的测试主要分为以下几个方面:界面,安全性,准确性,展示速度(性能)
数据统计方面
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格式。
第二篇:常见的软件测试用例设计方法
常见的软件测试用例设计方法有以下几种:
一、等价类划分
1)确定等价类
有效等价类代表对程序的有效输入;无效等价类代表的是其他不正确的任何输入。如果需要,我们还可以将一个等价类划分为更小的一些等价类。
比如,规格说明规定了“请输入书籍的数量(1~99)以及书籍的类型(硬皮、软皮或活页)”。它们对应的等价类分别如下:
书籍数量
书籍类型
2)生成测试用例
1.为每个等价类设置编号。
2.编写测试用例,尽可能多的覆盖尚未被覆盖的有效等价类。直到所有的有效等价类都被测试用例覆盖。测试用例及其覆盖的有效等价类如下:
3.编写测试用例,覆盖一个且仅一个尚未被覆盖的无效等价类。直到所有的无效等价类都被测试用例所覆盖。测试用例及其覆盖的无效等价类如下:
用单个的测试用例覆盖无效等价类,是因为有些输入的错误检查可能会屏蔽或取代其他输入的错误检查。比如②⑦,也许程序提示“非法的书籍数量”后,就不会执行对书籍类型的检查了。
二、边界值分析
经验证明,考虑了边界条件的测试用例比其他没有考虑边界条件的测试用例,具有更高的测试回报率。所谓边界条件,是指输入和输出等价类中恰好处在边界、或超过边界、或在边界以下的状态。
上例中的书籍数量范围是1~99,那么应该针对0,1和99,100的情况分别设计测试用例。
从定义可以看出,等价划分只关注输入空间(输入等价类)的不同,边界值分析还需要从输出空间(输出等价类)设计测试用例。
举例来说:
某个程序按月计算个人所得税的速算扣除数,且最小金额是0,最大金额是13,505。使用边界值分析法,应该设计测试用例测试速算扣除数结果为0和13505的情况。此外,还应观察是否可能设计出导致速算扣除数为负数,或者超过13505的测试用例。
边界值分析法和等价划分重要的区别是,等价划分是从等价类中挑选任意一个元素作为测试数据;边界值分析法考察正处于等价划分边界或在边界附近的状态。
三、因果图
边界值分析和等价划分的缺点是,未对输入条件的组合情况、输入条件之间的相互制约关系进行分析。
1)因果图的基本关系
恒等(Identify):若a为1,则b为1;否则b为0。
非(NOT):若a为1,则b为0;否则b为1。
或(OR):若a或b或c为1,则d为1;否则d为0。
与(AND):若a和b和c都为1,则d为1;否则d为0。
2)因果图的约束条件
1、对于输入条件的约束有E、I、O、R四种:
异(E):E必须总为真,而a、b最多只有一个为1。
或(I):I为真时,a、b和c中至少有一个必须为1。
唯一(O):a、b中,有且仅有一个必须为1。
要求(R):如果a为1,b也必须为1。
2、对于输出结果的约束只有M一种:
屏蔽(M):如果结果a为0,则b强制为0。
一、假设有一规格说明:
“第一列中的字符必须是‘A’或‘B’,第二列中的字符必须是一个数字。在这种情况下,对文件进行更新。如果第一个字符不正确,产生提示信息X12。如果第二个字符不是数字,产生提示信息X13。”
(1)将规格说明分解为可执行的片段,确定“因”和“果”,为每个“因”和“果”都赋予唯一的编号。“因”是条件,是指一个明确的输入条件等价类。“果”是动作,是指一个输出或系统转换(输入对程序或系统状态的延续影响)。
(2)分析规格说明的语义,转换为因果图。原因①和原因②不可能同时成立,为因果图添加对应的约束条件,得到右图。
因果图和添加了约束条件后的因果图
(3)将因果图转换为判定表,每一列代表一个测试用例。
判定表
(4)将判定表中的列转换为测试用例。
二、将因果图转换为判定表的思路(以上述的例子来说明)
1.选择一个“果”作为当前状态。例:71。
2.对因果图回溯,找出导致该“果”为1的所有因的组合(需要考虑到约束条件)。例:001,000。
3.在判定表中为每个“因”的组合生成一列。例:(列3)和(列4)。
4.对于每种“因”的组合,判断所有其他“果”的状态,并放置在对应的每一列中。例:已得在001,000两种组合下结点71的结果为1。判断在“因”为001的组合下,得到70和72的结果为0。判断在“因”为000的组合下,得到70的结果为0,72的结果为1。将“果”的状态填入其对应的列。
对因果图进行回溯时,需要做到以下考虑:
1.当回溯经过一个结果为1的OR结点时,不要将OR结点的1个以上的输入同时设为1。
2.当回溯经过一个结果为0的AND结点时,应列举出导致该结果为0的所有输入情况的组合。然而,当该AND结点的一个输入条件为0时,其他输入有一个或更多的1,则不必考虑其他输入为1的所有情况。
3.当回溯经过一个结果为0的AND结点时,所有输入皆为0的这一种情况应当列举出来。
找出因果图中,所有导致输出状态为0的输入条件
(1)根据上述第c)条思路,我们只需列出使得结点⑤和结点⑥皆为0的情况。结点①②③④的取值状态为:
0,0,0,0(5=0,6=0)
(2)根据第b)条思路,对于结点⑤为1而结点⑥为0的情况,应该列出导致⑥为0的所有输入情况组合。同时,只需列出一种使得⑤为1的情况即可,不需要列出⑤为1时的所有输入情况组合。又根据第a)条思路,当结点⑤为1时,我们不应将结点①和②同时设为1。于是,得到结点①②③④的取值状态:
1,0,0,0(5=1,6=0)
1,0,0,1(5=1,6=0)
1,0,1,0(5=1,6=0)
同样的,对于⑤为0而⑥为1的情况,也只需要列出⑥为1的一种情况即可(尽管在本例中也只有这一种)。
0,0,1,1(5=0,6=1)
因果图有助于用一个系统的方法选择出高效的测试用例集。它还有一个额外的好处,就是可以指出规格说明的不完整性和二义性。但通常它不能生成全部应该被确定的有效测试用例。
注意:因果图方法没有充分考虑边界条件。建议,最好是单独考虑边界值分析。这不意味着我们要为此增加相应多的测试用例,而是在由因果图生成测试用例时,可以将边界条件分析一并考虑进去。最好的结果是既满足了两方面的目标,又不需要增加新的测试用例。
四、错误推测
错误猜测是一项依赖于直觉的非正规的过程,其基本思想是人们利用直觉和经验猜测可能犯得错误或错误易发情况的清单,然后编写测试用例来暴露这些错误。
例如,程序输入中出现0这个值,就是一种错误易发情况。因此可以编写测试用例检查特定的输入值中有0,或特定的输出值被强制为0的情况。同样,在出现输入或输出数目不定的地方,如,对某个列表进行搜索,结果为“空列表”或“只包含一个”条目的列表,也是错误容易发生的情况。
第三篇:编写测试用例和测试计划
第六章 编写测试用例和测试计划
主要内容:软件测试计划;软件测试方案;软件风险分析
1.软件测试计划
1.1 软件测试计划的简介
1测试计划概念:测试计划在测试中处于中心位置,它阐述了测试准备工作和执行测试的必要条件,同时也形成了测试过程质量保证的基础。
2测试计划的作用:组织和管理测试;使测试工作和整个开发工作整合起来;资源和变更事先最为一个可控制的风险。
1.2 如何编写软件测试计划
1认识测试项目不仅仅只有单一测试计划
2避免不分析直接进行测试阶段日程安排
3避免测试任务的安排超前于开发任务
4避免有些系统测试类型无法按期进入测试
5不正确的变更测试计划
6测试计划里明确更新周期和暂停测试原则
7测试计划不是一成不变的1.3 测试计划包括:简介,目的,范围,测试策略,进度,缺陷的严重程度的定义,风
险分析。
2.软件测试方案
2.1 软件测试方案的概念
软件测试方案描述测试的特征,测试的方法,测试环境的规划,测试工具的设计和选择,测试用例的设计方法,测试代码的设计方案。即包括以下几点:
明确测试策略(黑盒,白盒,灰盒等)
细化测试特征
测试用例的规划
测试环境的规划
自动化测试框架的设计
测试工具的设计和选择
2.2 软件测试计划于软件测试方案的区别
测试计划是组织管理层面的文档。测试方案是技术层面的文档。
测试方案需要在测试计划的指导下进行,测试计划提出“做什么”,测试方案明确“怎么做”
回报的对象不同,测试计划向领导汇报,测试方案是组员共享该文档
3.软件测试的风险
软件需求风险
人员的风险
测试环境的风险
测试工程师对产品的业务不熟悉
补充:
回归测试:把以前检查过的已经修复好的缺陷,拿来另测看有无带来新的缺陷 反侧:把开发人员已经处理的缺陷拿来测,看是否修复
第四篇:报表测试方法总结
报表测试方法总结
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> 报表的权限
对于有权限控制的系统,报表当然也应该和用户所具有的权限相一致.需要从两方面校验权限的控制.报表的条件定义:在条件选择区域,有些下拉框中应该不能显示用户权限范围外的数据.备注:目前这部分内容测试比较少,之前客户没有提出权限这方面的需求,但是最近在使用过程中,客户提出过,要求分公司人员只能查出自己分公司的清单,允许总公司查出所有的符合要求的清单,估计在后续还会提出类似这样的要求,所以这部分后续要需要加强测试。
第五篇:软件测试方法总结
软件测试方法总结
(一)发布时间: 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、严格按照测试用例执行测试,确认计算结果是否正确无误,注意结果的精度。