研发改进体制.docx
- 文档编号:30718134
- 上传时间:2023-08-19
- 格式:DOCX
- 页数:29
- 大小:36.34KB
研发改进体制.docx
《研发改进体制.docx》由会员分享,可在线阅读,更多相关《研发改进体制.docx(29页珍藏版)》请在冰豆网上搜索。
研发改进体制
研发改进体制(草案)
版本
创建
日期
备注
V0.1
王振刚
2004-4-14
创建
V0.2
王振刚
2004-4-21
修改,添加一些新的内容
V0.3
王振刚
2004-4-27
添加和修改部分内容
目录
目录2
测试介绍4
测试的分类8
单元测试8
集成测试10
系统测试11
验收测试12
测试方法12
黑盒测试12
白盒测试12
灰盒测试12
测试方面12
测试改进方案13
测试工作需要回馈13
测试工作需要总结14
需要交流平台和形式14
采用的方法15
让别人给服务说话,清楚认识自己15
自己回头看16
了解同类产品16
提高自身素质17
如何提高程序能力17
耳濡目染17
自己连内功18
实践中检验20
测试发展20
如何提高测试20
制定完备的测试计划21
提高案例设计水平21
逃避测试的误区25
如何调整团队的作战能力28
歪曲理论推理31
正确理解自动测试31
测试的几中方法33
网络方面的测试方法33
数据库测试要点33
网络游戏测试要点33
C/S结构测试要点33
WEB测试要点33
嵌入式软件的测试方法33
手机软件测试33
MP3软件测试34
通用软件的测试方法34
办公类产品测试34
杀毒类产品测试34
工具类产品测试34
ERP软件的测试方法34
验证测试34
测试管理工作34
开发方面36
开发分析36
问题分析36
目前存在的问题36
产品方面39
第一步、增强开发质量意识40
第二步、增强测试本身素质40
第三步、对产品开发过程中版本编译的控制40
第四步、进度控制40
第五步、控制进度问题40
测试介绍
测试现在被普遍认为“保证产品质量”这个笼统的说法下,而测试本身是什么呢?
今天我们就测试本身跟大家一起讨论讨论。
测试在国外已经发展比较成型了,而国内的测试现在还处于摸索阶段,至于超着那个方向去发展,我觉得大家目前还是处于比较迷茫的阶段。
主要原因是:
国内软件产业起步晚,而且质量意识不强,造成了软件工业发展缓慢,配套行业(测试发展缓慢),我觉得这个很正常,因为从人类历史发展的角度来看,这个是必须经历的阶段,从有这个概念到摸索,目前国内的测试应该处于沉思期,主要是没有一个全套的指导思想,另外一个全新的行业发展方向不明朗,造成了测试现在成了大家进入企业的跳板,要么就是觉得自己的能力还不够,目前只能从事测试,要么就没有编写程序的能力,但是同类产品比较了解,所以做测试。
我对这个问题有自己的看法,我觉得在企业发展的同时,个人要发展,那么个人怎么发展呢?
(我说的是测试人员),那就是技术不是针对产品的,因为现在的企业测试都是把测试过同类产品当成了经验,那么这个人的经验积累就这么多了,可增长和发展的空间不是很大。
如果我们把测试的方法整理成技术,那么他上一个规则或者说是一个标尺,我们只是分析这个产品的那个方面需要用什么方法来测试,那么积累就不会被约束,但是不能撇开经验,因为经验本身是设计出好的案例的基础。
我们再看看测试案例的设计,测试案例的设计在国内现在是一些刚刚入行的不会写程序或者程序功底比较差的人在写案例,那么这些人设计出来的案例只是包含了整个测试过程中功能测试的一部分案例而已,因为他们不懂得或者不理解程序,不是从原理上去分析产品,不是从逻辑上去分析产品,而是从用户使用的角度去分析产品,这样设计出来的案例的可行性和可信度多大呢?
大家可想而知了。
所以我们在整个引导大家的过程中,从技术和方法,结合具体实例和针对不同的类型的产品的测试方法进行跟踪和描述。
首先,什么叫测试?
测试干什么?
测试,是在开发过程中的一种活动,它是分白盒测试和黑盒测试。
在不同的阶段不同的人所承担着测试这个角色,我们把整个活动统称为测试。
测试的工作内容主要包含了设计测试计划,设计测试案例,执行测试,进行测试总结。
执行测试是在产品开发的整个过程中进行的,包括了单元测试,系统测试,集成测试,系统测试和验收测试,那么不同的阶段测试的重点不同。
单元测试的重点是函数级,包括需求,包括算法,包括接口预留等内容。
集成测试是指把小模块结合起来,测试的重点是输入输出数据,参数的处理,错误预处理,接口规范,参数约束等测试内容。
系统测试的重点是功能性质,它的测试重点是按照需求来对照测试,主要是功能实现的情况,包括功能使用逻辑和操作逻辑,操作系统,兼容性(软件和硬件)等内容。
验收测试,主要是合同性质而言的,在国外现在软件外包情况比较多,那么双方按照合同规定履行自己的职责,把功能按照合同约定的形式条条比对。
这是主要方面,那么在企业内部,验收测试是除了功能验收以外,还包括易用性,软件的亲和度等方面的内容。
序
我是一个充满激情的人,我把所有的激情投入到生活的每一个空间。
我是一个不停折腾的人,因为生活在不停的折腾我。
我是一个不服输的人,因为我知道这个社会不会同情弱者,只有不停的折腾,才有可能把握自己的命运。
我是一个傲慢的人,因为我把自己已经当成是行业的开拓者。
我是一个平和的人,因为我和不同的角色在对话
我是一个开放的人,我会将我知道的或者了解的用无私的信鸽传播
关于产品开发流程分析(初稿)
王振刚(2004-4-14)
测试的分类
单元测试
单元测试是在测试过程中的最小粒度,它在执行的过程中紧密的依照程序框架对产品的函数和模块进行测试,包含入库和出口的参数,输入和输出信息,错误处理信息,部分边界数值测试。
这个部分的测试工作在国内现在是开发人员进行的。
我相信未来的发展应该是测试工程师来做这个事情。
那么需要测试人员需要深刻的理解程序,理解需求,理解设计,这样才能发现问题。
还有一种在国内先在操作的方法,就是当一个模块给某个开发工程师以后,需要他给大家讲解他要完成这个模块或者函数的整体流程和思路,进行统一评审,使得问题能够暴露的更充分些,这样做的目的有以下个,第一,使得大家对设计者的思路明晰的理解,以便以后调用或者配合的时候能够真切的提出需求或者相对完美配合。
第二,在评审的过程中,如果发现问题,那么大家可能没有犯过,这样就会更加提高警惕,如果犯过,就会回想当时自己怎么解决的或者规避的,使得大家能够在错误的过程中快速提高。
第三,可以对平常犯错误进行一个积累,我觉得这是生动的教科书,可以使得新的人员在新上手的时候遇到这样的问题以后,我们就可以给他一个解决问题的方法或者方向。
回顾,我们上面给大家介绍了两种方法,第一种就是通过在开发的过程种进行测试,由开发(测试)工程师写测试代码,对所编写的函数或者模块进行测试,第二种就是通过代码互评发现问题,将问题进行积累,形成知识积累库,以便使得新人在同样的方面不至于再犯错误。
单元测试非常重要,因为他影响的范围和宽度比较大,也许由于一个函数或者参数问题,造成后面暴露出很多表象问题出现。
而且如果单元测试做不好,使得集成测试或者后面系统测试的压力很大,而且项目的费用和进度可能就会飚升。
对单元测试,现在用CPPUnit的比较多,市场上也有其他对应的产品,他们在不同的软件单位不同的阶段。
正确的理解单元测试的重要性是意识,需要在过程改进种不停的总结,慢慢的积累,将质量意识渗透到整个开放过程中的各个环节。
保证单元测试顺利进行,需要渗透软件工程的很多思想,把CMM和跟踪机制建立起来,问题的分类、跟踪,如果把整个活动都渗透了,工程师的意识都增强了,
集成测试
集成测试是在保证单元测试进行后进行的一个动作,能否集成的标志不是所有的代码编译通过了就算是可以集成了,而是所有的能够在这个虚拟环境下能够正常运转。
在集成测试种一般采用的方法是数据驱动或者桩驱动,因为集成测试不能看到产品的表象,因为他是一些数据流的中间段,我们渴望能够对中间数据进行分析,就可以知道或者就渴望知道流程或者算法中有什么不妥当的地方。
集成测试比较适合做成自动化测试,我这里就不讲详细的方法,到后面的自动化测试介绍中,我会提到这个方面的问题。
和大家一起揭开测试自动化的神秘面纱以及给大家讲一些构建,冒烟的概念。
集成测试也是不可缺少的一个部分,很多单位为了赶进度,会将这个部分省略掉,就甩手给测试小组,如果没有对应的测试小组,就会是程序员进行简单的使用后就交付市场,危险,这是个定时炸弹。
因为他时刻有可能产生市场对企业影响的额度,以及企业本身的声誉问题。
系统测试
系统测试是测试过程中的一个转折点,因为在现在国内的企业中,不同的产品面对不同的用户群体,所以有的企业经过第三方产品的验收测试,有的企业则没有通过验收,而是一些工具类或者通用类的产品,那么他的验收测试是经过广大的用户群来做的,也就是说凡是通用类产品的系统测试必须严谨测试以后,才可以投放到市场。
但是对于对企业或者其他专业性单位定制的产品我们必须进行验收测试。
系统测试工作是一个重复老动很多的工作,需要在工作种把握几个重点,系统测试是保证系统能够正常运转,包括了功能,易用性,健壮性,压力,边界数值设定等各个方面的内容。
要想在这个阶段的工作种找到乐趣,就要不停的摸索,找出能够将机器代替人的所有的东西,找工作的快感。
系统测试需要有广泛的知识面,对测试工程师的要求需要了解和掌握很多方面的知识,需要了解问题可能出现的原因,已经出现这个问题可能是由于什么原因造成的,以便我们能够及时的补充测试案例,保证或者降低产推出的风险。
验收测试
验收测试类似于客户验证产品的质量,在软件行业发展的过程中,各种承包项目类似于国外的外包项目将会不断的出现,那么外包项目的质量问题需要大家共同讨论。
外包项目的操作流程是当承包方提出具体的需求,然后有承包商来按照需求来开发项目,包括单元测试,系统测试,集成测试等各个方面的测试,经过被承包商测试后的产品提交给外包商的时候,需要进行验收测试,验收测试可以是外包商本身提供一套测试方案,然后对照具体的需求,进行产品验证测试。
也可以是双方找一个共同的第三方,进行产品的验证测试。
验收测试的测试重点主要是产品是否按照需求开发的,而不从针对功能进行的测试。
所以验收测试基本上不需要多少专业水平,也可以是承包商找到使用该产品的用户,来体验该产品是否能够满足使用要求。
这样以来使得双方可以有一个共同的平台,避免商业矛盾的产生。
验收测试的测试手段目前来说还是靠用户体验。
测试方法
黑盒测试
白盒测试
灰盒测试
测试方面
案例设计问题
分析:
因为现在从总体上看,案例设计很细,但是重复和不必要的东西太多了,个人认为原因有三个:
第一、设计案例的不了解产品设计的框架(从程序概念上讲)
第二、案例的设计没有一个反馈,涵盖情况不知
第三、开发产品质量意识淡薄,测试压力太大
第四、测试人员的素质分析没有,我们看不清问题出现在那里
进度问题
第一、测试的整体计划里面没有重复考虑风险,时间问题紧迫
第二、回归测试无法保证
测试改进方案
以上对存在的问题进行了分析,我们需要找到自己的弱项在那里,那么从现在看来,我们现在测试队伍没有建立,没有形成相应的体制。
主要表现在一下几个方面:
测试工作需要回馈
测试案例执行跟踪和统计不明确。
问题:
如果测试案例不进行跟踪,无法证明或者检测我们案例设计的好坏,无法改进工作方法或者改善我们的思路,所以需要通过这里把自身问题看清楚,这样有利于工作的开展。
在我们日常的生活中,存在这一种现象,因为这种现象导致了测试一些列的发展。
大家普遍认为,测试的含金量不高,导致了测试工作就是一些不愿意做开发或者没有能力做开发的人来做,其二,他们对测试设计的测试案例从不认真的审查,认为就那么回事情。
出现这种问题的愿意是由于开发还没有清楚的认识到测试是一个服务部门,是为他们服务的,从私利的角度来讲,我们抛开项目的关系,测试的主要工作是为了帮助开发将自己写的代码更实用一些,让市场更认可一些,让开发人员的成就感强一些。
如果大家都从这个角度考虑问题,那就可能缓解或者解决上面的第二个问题。
关于测试含金量不高的说法,我不赞成这个说法,在目前国内的大环境下,测试是这样的,但是它在朝自己预想的发展。
而开发的发展除了新的语言在发展以外,思想或者体系我们能增加或者能设想的空间已经不多了,而对于测试是一个全新的行业,他发展首先需要支持,需要理解,我相信国内测试在5~10以后,发展更加迅猛。
因为就算是现在很小的软件企业,已经开始重视测试了。
测试工作需要总结
测试的总结机制没有
i.测试案例的执行情况
ii.测试案例发现问题情况
iii.测试案例的冗余情况
iv.测试周期内的曲线项目进展情况
需要交流平台和形式
信息交流平台和积累
v.资源共享
vi.信息共享
vii.提高自己在开发中的信心,不要总是喊狼来了
viii.人和人之间需要沟通和认同,团体也一样
采用的方法
让别人给服务说话,清楚认识自己
让开发人员说话,让对应开发人员给我们的测试案例提出相应的意见,保证测试案例的覆盖面,以把握重点。
在整个开发过程中,由需求,开发,测试完整的团队,准确的说还有市场部分,我们都把它归结为需求的搜索和定义部分。
那么在整个产品研发的过程中,各个部分需要完整的配合,否则整个产品都不能按时上市。
作为为开发和需求服务的测试部分,应该摆正自己的位置,我们是一个团队中的一部分,是不可以缺少的一部分。
人贵有自知,也难有自知。
只有在认识自己的基础上才能选择好自己的生活道路。
首先要认清自己的能力。
人的能力可以有天壤之别,但只要不辜负自己这块材料,也就可以问心无愧了。
认识自己尤忌自大,这会使你为自己订立高不可攀的奋斗目标,到头来高不成、低不就。
其次要认识自己的本性。
心理学家把人分成六个类型:
经济型、理论型、社会型、审美型、宗教型和权力型。
要选择一个适合自己本性的生活目标。
看清楚了自己,就可以很好的改善,也能把自己的事情做好,同时呢,才能更好的服务。
自己回头看
让执行测试案例的人员反馈给我们数据,说明案例的冗余情况,这样会慢慢提高自己的设计水平。
因为人们习惯于谈成绩,问题在成绩中可以淡化,我不同意此观点。
其实在现实生活中,大家都经历了很多事情,都学会了总结,可是同样的错误在现实中会多次出现,为什么呢?
是因为回头了多次,没有总结,总结了没有执行,执行了没有改变方式,改变方式了但是没有认真考虑,还是错的。
把自己犯的错误列举出来,然后找出出现问题的真正原因,才是自己最大的进步。
如果淡化错误,将来可能就会将成绩磨灭掉,所以积累,回头是工作中需要重视的问题。
了解同类产品
让市场人员反馈同类产品的问题以及市场对我们产品的需求。
测试过程是反映当前产品的质量,为什么要研究竞争对手的产品呢?
首先,测试中包含易用性测试,测试什么内容呢?
就是测试怎么好用,客户是怎么用的,我们怎么设计更贴近用户,那么不研究竞争对手,我们怎么可能占领上风。
其次,了解竞争对手的产品,有利于测试工作捕捉重点,使得工作开展有利有节。
可谓知己知彼,百战不殆,所以在现在的市场竞争中,了解同类产品才可能发现对方的缺点,给以打击,发现对方的优点,快速学习,闭门造车必定失败。
提高自身素质
从程序的概念理解产品,这样测试案例可以设计的比较有针对性。
常言说得好,“识重于才”,而见识却往往是生活阅历造就的。
对于一个初出茅庐的人,智者的指点是至关重要有时甚至是决定性的。
回想我十年来的经历,很多失败其实是没有人指点而造成的。
要寻找一个精神上的导师,他可以是你的父母,也可以是其他师长。
他阅历丰富而又不拘泥于自己的老经验;他能在紧要关头给予你原则上的指导和精神上的支持。
有时候仅仅是他失败的经验就会使你受益匪浅。
如何提高程序能力
耳濡目染
让开发或者设计人员在讨论开发方案的时候参与旁听,耳濡目染。
其实这只是一种辅助的手段。
电视剧《霍元甲》播出以后,得到大家的欣赏。
原因是因为他本人身体虚弱,所以父亲从小不让练武功,而生长在那样的环境中,他天天可以看到兄弟们在练功,招式已经记忆在心理,但是苦在没有练功的机会,他利用体力劳动的过程中,改变劳动方式,趁机练功,后来发展到独创“迷综拳”。
程序设计和开发是一个硬功夫,也是一个长远的事情,它是一个积累的过程,不能一蹴而就,需要苦心练,多些理解,多些思考。
面对程序开发,不要有太多的压力,因为程序开发就跟你学说话一样,因为语言本身有很多通性,高级语言和低级语言本质上差别不大,所以扎实的从基础的东西学起,这样才能完全的积累下来。
计算机发展速度很快,各种概念,各种语言发展都很快,掌握实质,不断学习,才能把握。
所以还是需要多看,多想,多练。
自己连内功
从自身做起,了解程序架构和开发模式,努力提高理解和产品的单元测试或者组件测试能力,这样以来可以了解程序的很多算法,使得在产品的开发过程中就能把问题发现并且能够得到及时的解决。
其次能够提高大家参与到项目的荣誉感,因为在测试本身是一个服务性的行业,那么服务行业的特点是不停的改变思路,改变服务模式,提高服务质量,当服务做好了,那么在整个研发中就可以找到自己也是其中一个分子的感觉。
其三,连好内功,为自己将来提高工作效率,进行一些自动测试以及从程序架构的概念上设计测试案例提供了技术保障。
以上是自己练好内功的用途。
在过去社会中,有很多擂台赛,目的是切磋技艺,弘扬中华武术,各个门派直接交流和学习的过程,为了在擂台赛中取的很好的成绩,我们需要努力练功,其次是多学本门派和其他门派的武功,或者自创武功,在擂台上能够发挥的淋漓尽致,因为武功的最高境界就是没有招式,要达到这个境界,需要内功深厚,避免走火入魔,需要毅力,需要创新。
理论就是理论,无论在那里看到的理论都是一定的基础的,因为所有的理论基础需要一个证明此理论的平台或者条件,所有一定要看,想,用。
看别人是怎么用的,在什么情况下用的,用的目的是解决什么问题,在什么样的环境下能够做出来,需要什么样的支撑;想自己现在目前是否有这个环境,就目前的环境能够做什么,如果要搭建对方的环境需要多长时间,这个做法中存在什么不托的地方,有什么需要改进的地方;在自己工作的环节中找找看,看自己是否适合用这个东西,如果适合,怎么用,用到什么程度,如果非常认可别人的做法,需要衡量需要多少资源和时间,努力找自己的结合点。
千万不要再我们看到一个理论或者方法的时候就去推动它,或者原理实践过一个什么思想就想在新的环境下实践他,都是不可取的。
好的事情或者好的做事方式他需要一些条件支撑,一旦硬套,就可能出现问题。
实践中检验
尝试做一些灰盒测试部分(目前暂时是想法,但是还不完善)
测试发展
测试在国内还是处于摸索阶段,在过去的发展阶段,大家只是初步针对不同的软件产生了不同的测试方式,但在操作方法,操作流程等方面还需要继续摸索。
对潜入式软件来说,行业内始终认为潜入式软件是最难进行测试的,因为他需要很广的知识面,需要对各个点的设计原理进行分析和测试。
在目前国内开发眼中的测试还没有形成概念,我们需要不断的改变形象,加深他们对测试的印象,以便我们获取更多的帮助和协助。
测试未来发展需要两条腿走路,这样能够在各个环节保证产品的质量。
第一步,系统测试继续练内功,将案例设计的能力提高
第二步,需要进行灰盒测试,对产品进行代码级的测试
第三步,需要进行部分白盒测试或者由开发人员进行执行
如何提高测试
提高测试需要从几个方面着手,其实只是自己的一些感觉,不一定就需要按部就班,需要找自己适合的点。
制定完备的测试计划
清楚的认识测试计划,测试计划是一个文档,能够保证整个研发过程中顺利执行的一个指导性文档,它描述了几个方面的问题。
第一、描述了项目的目的
第二、描述了项目的开发周期
第三、描述了在测试中遇到的技术
第四、描述了测试案例的设计周期
第五、描述测试案例的执行周期
第六、描述了测试过程中用到的工具或者技术
第七、描述了测试过程中用到的资源情况
第八、描述了测试过程中可能遇到的风险以及规避方法
提高案例设计水平
明确了解现在目前流行切实用的几种案例设计的方法,因为在不同的产品不同的要求有不同的设计手段,我们需要不断的学习和总结,在为了测试领域中,许多新鲜的词语都会出现。
这种方法类似与工业领域的随即抽取统计分析法,但是工业性质牵扯到损坏或者人为原因,统计出来存在这偏差,但是应用与软件方面,虽然存在着偏差,但是不可能象硬件那么偏差很高。
等效法
明确测试的目标,一般适合用到的范围是,制定被测试的对象是在满足某个条件的区间内的所有的所有数据。
案例设计方法:
从其中区间数据段中选择任意一个或者两个数据,只要这个数据满足了,那么其他的数据就是满足的。
我现在举一些例子,来说明等效法在测试过程中如何应用的。
范例1:
在登陆某系统需要验证用户名,要求是长度是最小是6位,最长是14位,名字中可以包含数字,但是不能以数字开头,可以包含各种符号,不能包含中文。
1、随意字母组合成一个12位的姓名,测试是否可以通过验证。
2.、随意生成一个长度12位的姓名,测试是否可以通过验证
3、测试以任意一个数字打头12位的姓名,测试是否可以通过验证
4、测试姓名长度位12位且包含中文情况,测试是否可以通过验证
5、测试长度不满足条件情况下,是否通过验证
6、如果长度不满足,是以数字开头的,提示信息验证
7、如果长度不满足,姓名中包含中文的,提示信息验证
………….
(注:
)这个可能比较简单,但是说明一个问题:
为什么随意生成一个12位姓名的,其实你选择8位姓名长度或者10位姓名长度是一样的,所以这种情况下考虑采用等效方法比较合适。
范例2:
有这么一个需求,要求选择1~12之间进行调整,手机的背光就会随着数值的变化而变化。
总体的是数值越大越暗。
以上需求是大家经常可以看到的。
测试案例设计:
清晰记忆1的情况,然后随意调整一个数值,因为要求是变化了,至于变化成什么样子,变暗到什么程度才正确,没有明确的指标数值,所以只需要记住临街点1的情况,然后随意调整一个数据,然后和当前调整后的数据进行比较。
(注:
)没有明确的说明,只是含糊的结果,但是总体的结果是在变化,那么这个时候比较适合使用等效法。
范例3、如果
因果分析法
需要有一定的程序基础,了解程序的架构,就是当问题发生以后,能够有效的补充相关的案例或者筛选相关的案例。
因果分析的核心是从自己的理解去分析问题所在的真正原因。
范例1:
删除磁盘上某个文件失败,分析原因:
如果是管理员权限,那么可以随意删除,无论这个文件的属性是只读的还是存档的,那么如果不能删除磁盘文件,除非是坏道上的文件。
分析完成以后,使得测试案例设计有针对性,而不是盲目的将所有的文件格式都去尝试一次。
范例2:
假设我们用Excel作一个计算,结果和我们用计算器计算的结果不同。
分析:
Excel的计算函数单独运算没有错误,然后插入一行,结果错误了,说明插入行导致计算错误,那么插入一行怎么会引起函数计算错误呢?
原因是由于插入行后,导致传给计算函数的区域没有更新,所以造成计算结果错误,那么这个Bug就很明确了。
范例3:
假设我们平常在做讲座的时候发现在某台机器上就会死机。
这是一种现象。
分析:
为什么在这台机器上死,在其他机器上不死。
原因有两个,第一个先找系统原因,是否是我们的产品在当前这个系统下有Bug,经过验证没有,那问题出在那里?
其实演示产品需要的是硬件的支持,那就是显卡,如果显卡内存不够大,可能导致某些演示文件死。
(
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 研发 改进 体制
![提示](https://static.bdocx.com/images/bang_tan.gif)