学习软件测试过程中想到的问题.docx
- 文档编号:586597
- 上传时间:2022-10-11
- 格式:DOCX
- 页数:27
- 大小:255.30KB
学习软件测试过程中想到的问题.docx
《学习软件测试过程中想到的问题.docx》由会员分享,可在线阅读,更多相关《学习软件测试过程中想到的问题.docx(27页珍藏版)》请在冰豆网上搜索。
学习软件测试过程中想到的问题
软件测试随笔
测试技术学习阶段:
时间:
2010-6-3
1.突然觉得将学习的所想和所感记录下来是件令人心情愉悦的事情,所以,从今天开始,打算将自己的随想记录下来。
2.学习软件测试的过程中,有种感觉,就是拿软件测试的学习内容对新人进行训练,有时应该会有不错的效果。
3.软件测试真的有必要形成一个体系,就是说怎样将软件测试的方法有顺序有步骤的全面地实施,我觉得是很重要的。
4.在形成软件测试的哪怕是一个简单的体系之前,应该首先将各个测试方法和技术彻底地搞懂。
5.目前我觉得存在问题的测试方法应该是静态黑盒测试和动态白盒测试。
静态黑盒测试一般用于测试产品说明书,动态白盒测试的方法还没有吃透。
6.目前,因为只是一个初学者,所以,学习的方法应该还比较浅显,我想以浅显的为开端,再过渡到第二本《软件测试》进行学习更详细的测试方法和技术。
7.详细计划上我写的是先进行方法和技术的学习,之后再进行实战演练,但是,似乎,在进行实战练习前,对软件测试工具有必要进行一定的了解,所以,我想可能在学习顺序上会有一定的变动,例如,在完成测试文档之前,先进行测试工具的学习。
这个我会随时报告。
8.通过一周来的学习,体会最深的应该是,软件测试绝不是软件测试员一个人闭门研究怎么造测试案例,找出软件的缺陷,它是需要和管理人员以及程序员进行密切沟通的。
9.软件测试也绝不是死规矩的测试,它同样需要灵活地对待,这也将是我学习软件测试的一个有益的挑战。
10.要想成为一个优秀的软件测试人员,不只是要掌握我们通常所谓的黑盒测试技术,白盒测试同样有其不可替代的作用;那么,好的软件测试员同样也是好的程序员。
时间:
2010-6-4
1.软件测试关键技术的学习是一个过程,应该不可能将所有技术都掌握到位,有选择的进行学习是策略。
2.
运用测试技术阶段:
时间:
2010-08-01
在实际进行测试(主要是DAP测试)过程中,认为以下的测试技术可以应用到:
1.代码走查(静态白盒测试
对于有一定编码经验的测试人员来说,代码走查有时是一个比较有效的测试问题的方法,DAP开发中,杨姐审查我写的代码就是一个例子。
2.正确性测试
正确性测试有时也叫功能测试,是测试首先要考虑的方面。
在了解算法逻辑基础上造数据进行测试,所造数据最好包括了所有情况的数据,注意不要一种情况对应一组数据,将所有情况的数据都一同造出后进行测试,这样才可能发现更多的问题。
3.边界条件测试(动态黑盒测试)
无外乎利用边界值进行测试
4.次边界条件测试(动态黑盒测试)
DAP测试:
在选择立案日上考虑次边界条件,如,立案日:
2010-4-1,考虑2010-3-30或2010-4-2等的立案日设置的预测结果差异。
5.空值和无效数据(动态黑盒测试)
通常我们所说的异常数据情况(空值、无效数据等是否做了处理)
6.跟踪测试(动态白盒测试)
在整个软件中跟踪一批数据,并查看中间结果值,这样不仅可以根据观察结果决定更改某些测试案例,还可以查看中间结果值的输入输出是否正确。
7.单元测试(动态白盒测试)
略
对于上面的各种测试技术的应用,通常会找到大部分的软件缺陷,但是有时,创造性的方法可能会找到隐藏的错误。
1.像笨拙的用户那样做,把自己假想成什么都不懂,跳出你目前所了解的逻辑,站在用户的层面上执行系统,也许你会发现不合理的操作步骤,不恰当的消息输出等等。
2.在以前找到软件缺陷的地方再试试(这点记得晓明之前也提出过)
3.凭借经验、直觉和预感(这是更高的层次了)
设计测试用例阶段:
1.当然,设计测试用例要按照所用的测试技术和方法进行设计,造数据。
2.本次DAP测试,测试发现的问题都得利于所用的测试数据,所以,我最大的感触就是怎么造出能够进行有效测试的测试数据,这点,我目前还没有成熟的想法。
一般而言,对于正确性测试,只要造出几组有代表性的数据即可,然后利用有限的数据进行各种情况(包括空值、零值、无效数据等)的试验;对于异常测试,一方面,需要造出特殊的数据来试验,通俗一点说就是钻空子,看能否使软件发生异常甚至崩溃,另一方面,需要试验很多组随机数据测试,通过DAP测试的实践,利用大量的实际数据进行测试是非常有效的排除异常情况的方法。
3.对于集成测试和系统测试所用的测试用例的设计思想还需要进一步的学习和在今后的实践中不断地摸索。
测试实施阶段:
1.当你在为寻找逻辑上的不足或异常来进行测试时,这种有目的的测试对于大家来说还都可以接受,但是到了测试的后期,我们基本上确定了算法的逻辑,搞定了所有发现的异常后,可能就认为没有必要再进行测试了,这种想法是错误的,因为所有的软件缺陷一般是不可能都被查出来的,而且我们大多时候还无法在开发期内获得客户数据,这时,就需要有一定的耐性来把软件测试做到最后。
2.测试实施过程中,需要试验大量的数据,重复工作也比较多,此时,考虑利用自动化测试工具是否是更有效而快捷的测试方法,需要进一步学习和试验。
补充:
测试策略回顾阶段:
测试技术策略:
1.在任何情况下都使用边界值分析方法。
2.必要时用等价类划分方法补充一些测试用例。
3.错误推测法:
真正的推测是不可能一开始就推测的,是在对整个系统熟悉的情况下,对各种情况了解的时候做出的假设,觉得某地方可能会出现这样的问题,或者你发现一个问题,在别的模块可能也会有这种情况,还有就是由你发现的问题引申出来的情况的“变种”,因为开发人员解决问题时常不是治本的,所以要把可能的变种列举出来。
基本思想:
列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据它们选择测试用例。
例如,在介绍单元测试时曾列出许多在模块中常见的错误,这些是单元测试经验的总结。
此外,对于在程序中容易出错的情况,也有一些经验总结出来。
如输入数据为0,或输出数据为0是容易发生错误的情形,因此可选择输入数据为O,或使输出数据为O的例子作为测试用例。
又如,输入表格为空或输入表格只有一行,也是容易发生错误的情况。
可选择表示这种情况的例子作为测试用例。
再如,若两个模块间有共享变量,则要设计测试用例检查当让一个模块去修改这个共享变量的内容后,另一个模块的出错情况等等。
4.对照程序逻辑,检查已经设计出的测试用例的逻辑覆盖程度。
根据覆盖程度可再继续补充测试用例。
5.如果程序的功能说明中含有输入条件的组合情况,开始就利用因果图法进行测试(见附1)。
因果图法测试因果图法测试
6.正交实验法,利用因果图来设计测试用例时,作为输入条件的原因与输出结果之间的因果关系,有时很难从软件需求规格说明中得到。
往往因果关系非常庞大,以至于据此因果图而得到的测试用例数目多的惊人,给软件测试带来沉重的负担,为了有效地,合理地减少测试的工时与费用,可利用正交实验设计方法进行测试用例的设计(见附2)。
测试方案策略:
1.根据程序的重要性和一旦发生故障将造成的损失来确定它的测试等级和测试重点。
2.要认真研究,使用尽可能少的测试用例发现尽可能多的程序错误。
测试计划阶段:
略
测试结果报告阶段:
1.测试数据备份
我把测试数据的备份放在了这个分类里,是出于结果的呈现也需要提供相应的测试数据这点考虑。
一个是测试数据的备份,这是一定要做的,便于问题再现和回归测试。
我觉得养成一个随时保存测试数据的好习惯是挺必要的,因为有价值的数据我们日后也可能会继续用到。
比如京都酒厂数据,由于其数据的多样性,用这个数据测出了很多问题。
关于测试数据的备份,这里涉及到一个数据库备份和测试数据文档的备份问题。
为什么将这个问题拿出来,因为我比较有感触,就是当时DAP测试时,用了很多个数据库,当时命名也没有考虑太多,胡乱命的名,后来想找之前用过的数据库都找不到了,
如果要找的数据还比较难造的话,就更麻烦了。
文档的命名有时也需要花一点心思,数据太多的话,之前利用项目命名远远满足不了多个数据库的备份,此时命名时加上日期通常是我们采取的办法,但是可能同一个日期的数据库又有多个,光加日期还不够用,如此等等。
此时可能你已经备份了很多个数据库文件,如果你想日后再查找相应的数据,也许还是并不太容易。
所以,我想此时,数据库文件和数据文档同时来做数据备份也许会更好。
具体办法如下:
2.Bug管理
这是需要时时更新的文档形式。
清晰记录测试发现问题,方便相关开发人员查看。
至于具体的形式可以灵活表现,最常见的是帐害管理表的管理。
(DAPテスト障害管理表_20101108)
3.结果报告书
测试完成后的成果物,需要表现测试的整个过程。
测试工具使用阶段:
不要盲目追求自动化,根据产品目标按时完成测试任务,保证质量才是关键(测试小组成员,可以一部份做自动化,一部份做手工测试,把自动化测试后期效率与手工测试当时效率结合起来,互补完成任务)。
1)完善手工测试流程(自动化测试与手工测试,思想上是一致的,自动化基本是代替手工,进行操作,手工完善了,自动化只是工具如何使用的问题)
2)完善测试用例(在完善的过程中,你会产生使用自动测试工具的想法,这时去运用最有效;如测试用例非常齐全,有大量数据输入,你就会想要有什么工具代替我输入就好了;)
3)将所有工作中的特定部分作为应用自动化的候选对象(比如软件各组件自动安装过程)
4)从高度冗余的任务或场景开始考虑(比如:
大量的数据输入,验证翻页)
5)将乏味且人工容易出错的工作进行自动化(比如:
结果比较或计算值,核算数据等)
6)首先关注开发成熟、理解透彻的用例或场景(比如:
测试用例足够测试一个功能)
7)优先选择应用中相对稳定的部分,而非易变的部分(比如:
回归测试时,不仅要验证bug,测试新的功能,还要测试已经稳定的功能,这时对这稳定的功能就可以进行一定程度的自动化)
8)想到一个问题是测试数据的备份和维护,这时是否考虑用测试工具更好呢?
附1
因果图法(黑盒测试)
一. 方法简介
1.定义:
是一种利用图解法分析输入的各种组合情况,从而设计测试用例的方法,它适合于检查程序输入条件的各种组合情况。
2.因果图法产生的背景:
等价类划分法和边界值分析方法都是着重考虑输入条件,但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。
这样虽然各种输入条件可能出错的情况已经测试到了,但多个输入条件组合起来可能出错的情况却被忽视了。
如果在测试时必须考虑输入条件的各种组合,则可能的组合数目将是天文数字,因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计,这就需要利用因果图(逻辑模型)。
3.因果图介绍
1) 4种符号分别表示了规格说明中向4种因果关系。
2) 因果图中使用了简单的逻辑符号,以直线联接左右结点。
左结点表示输入状态(或称原因),右结点表示输出状态(或称结果)。
3) Ci表示原因,通常置于图的左部;ei表示结果,通常在图的右部。
Ci和ei均可取值0或1,0表示某状态不出现,1表示某状态出现。
4.因果图概念
1) 关系
①恒等:
若ci是1,则ei也是1;否则ei为0。
②非:
若ci是1,则ei是0;否则ei是1。
③或:
若c1或c2或c3是1,则ei是1;否则ei为0。
“或”可有任意个输入。
④与:
若c1和c2都是1,则ei为1;否则ei为0。
“与”也可有任意个输入。
2) 约束
输入状态相互之间还可能存在某些依赖关系,称为约束。
例如,某些输入条件本身不可能同时出现。
输出状态之间也往往存在约束。
在因果图中,用特定的符号标明这些约束。
A.输入条件的约束有以下4类:
①E约束(异):
a和b中至多有一个可能为1,即a和b不能同时为1。
②I约束(或):
a、b和c中至少有一个必须是1,即a、b和c不能同时为0。
③O约束(唯一);a和b必须有一个,且仅有1个为1。
④R约束
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 学习 软件 测试 过程 想到 问题