软件测试实习的开展能使实习生们对软件测试工作有一定的认识与理解。软件测试实习报告是小编为大家带来的,希望对大家有所帮助。
第一篇:软件测试实习报告
这学期学习了软件工程实践这门课,我觉得这是对上学期的软件工程课程学习的检验,上学期学习软件工程只是我们浅显的认识,相比之下,这学期就更加全面的说明了开发一个项目所需要的步骤以及开发项目过程中所需要注意的诸多细节。如果说上学期的课程注重理论基础的话,那么这学期的软工实践,顾名思义,就是侧重我们动手操作的能力。
原来我认为开发一个项目最重要的就是写代码,似乎整个软件都是编代码,因为自己动手能力不强所以就很排斥做项目。可是经过我们学习软工课程到团队做项目再到学习软件工程实践课程之后,我才真正意识到实施一个软件工程项目并不是说简单的会编码就能够解决问题的,因为一个软件的生命周期分为三个时期:软件定义时期、开发时期、维护时期,而这三个时期整体又分为七个阶段,他们分别是:问题定义、可行性研究、需求分析、总体设计、详细设计、编码和单元测试、综合测试,由此可看出,当我们开发一个项目时,更多的精力不是放在编码上,编码只是一个很小的模块,而是项目的整体结构上。
在写软工实践体会之前,我想在这里总结一下上学期三人团队做 项目的相关事宜。上学期我们三人团队根据软件开发的步骤开发一个名为“西大老乡‘荟’”的社交系统,主要是为西大学子提供一个找老乡的平台。虽然只进行到详细设计阶段,没有进一步实现,但是我还是从中学到很多东西的。首先要先确定项目主题,也就是这个项目用来做什么,可以解决什么问题。接着就是这个项目是否有研究的必要以及是否有解决的办法,针对我们的项目,我们对西大的一些学生做了问卷调查,并从调查中继续完善系统本身的做用户。第三步根据我们确定的项目主题进行需求分析,这一步骤当时做的不是很好,比如所画E-R图、数据流图等都有考虑不周的问题,导致接下来的概要设计、详细设计进行的很困难,有些步骤甚至还需要返工。
从我们在需求分析中出现的问题,使我们明白了软件定义阶段对于一个项目的开发是至关重要的,当软件定义阶段完成时必须要用正式的文档准确的地记录目标系统的需求。只有前期的准备工作做得好,后面的工作才能顺利进行。虽然项目最后没有完全实现,但是起码我们已经初步体会到软件项目开发的步骤,以及每一步所需要完成的文档等内容。
这学期的软件工程实践虽然不是亲自动手开发一个系统,但是张元平老师以“物联网物流仓储管理系统”为主给我们讲解了一个真实系统的开发过程,从计划到项目系统的发布实施,以及每一步必须生成的文档。我主要从以下五个方面谈一下我的心得体会。
第一、行业背景说明方面
对于一个软件系统的开发,第一步就是问题定义,了解所开发系统的行业背景,制定计划。当我们计划确定以后就要对项目系统本身进行可行性研究,主要从技术可行性、经济可行性和操作可行性三个方面着手。就比如《物联网物流仓库管理系统》的行业背景说明文档中非常详细地分析了当下物联网物流行业的整体业务说明、应用背景、未来发展趋势以及相关应用案例等四个方面,项目团队中系统分析员就可以根据这份文档以及相关的调查资料对将要开发系统的进行定义等工作。
原来我们写这类文档的时候就是草草了事,不会做得这么详细,而这次看到大型项目的行业背景说明也是这么详细,也让自己认识到不管是软件开发的那个阶段都要认真对待,这些琐碎的文档都是后期开发项目的支撑,只要它们做的透彻,后面的开发工作才能更顺利的进行。
第二、项目需求说明方面
这部分项目需求说明就是软件定义时期中需求分析阶段,而该阶段的主要目的就是了解用户的需要,根据用户的需要确定系统必须完成那些工作,并对目标系统提出完整、准确、清晰、具体的要求。在需求分析结束之前系统分析人员要写出一份需求规格说明,即为《物联网物流仓储管理系统》项目需求说明文档。我们可以看出该文档也是非常详细,相比之下我们之前做项目时写的需求规格说明书就非常不合格,不仅格式不正确内容也是少之又少。
在这方面,这篇文档给我启发很大。首先就是文档的格式,要美观整齐,让人看着舒服方便。其次就是文档的内容,原来它不是很重要,写文档的时候也不知道怎么写就借鉴下网上的内容,结果根本就没有把自己项目的需求写明白,以至于自己最后都有些糊涂,所以根据以前的经验教训我会对这部分更加重视。
第三、系统概要设计方面
这部分内容分说的是软件设计时期的概要设计阶段,该阶段的主要目的就是实现系统的功能、设计软件的结构、模块组成以及模块之间的关系。在概要设计阶段,我们可以站在全局的高度上,花较少的成本,从抽象的层次上分析对比多种可能的系统实现方案和软件结构,从中选出最佳方案和最合理的结构。在这个阶段还会具体画出E-R图、数据流图等方面的设计。
比如《物联网物流仓库管理系统》的系统概要设计从项目概述、设计约束、功能单元与功能模块设计、数据E-R图设计、总体设计、界面设计等六个方面介绍,通过读这个文档,我觉得最重要的还是总体设计,分别从逻辑架构设计、物理架构设计、技术架构设计设计系统。在这个阶段中模块要做到高内聚低耦合,这样开发出来的系统才会具有更高的独立性。
在原来做项目时没有编写过这类文档,在该阶段只是画了结构图、层次图以及相关的模块划分,对该类文档尚未重视。通过张老师的讲解和自己的学习,我相信在以后做项目的时候一定会注意到这类文档的编写。
第四、详细设计与分析方面
详细设计阶段就是把概要设计阶段的每个模块进一步设计,确定每个模块所需要的算法和数据结构。在这个阶段还是需要我们设计出程序的详细规格说明,而不是编写程序。在详细设计阶段,系统设计人员可以通过使用程序流程图、盒图、PAD图等过程设计的工具和Jackson图等面向数据结构的设计工具进一步设计系统相关接口,主要包括界面设计接口、业务单设计接口、单元模块设计接口等,这些对于以后的编码工作都是极其重要的。
第五、编码和测试方案方面
关于编码,我认为编码要想做的完美必备条件就是前面的软件定义和软件设计时期要按部就班的做,文档一定要按要求书写,不能偷懒也不能草草书写。对于编码也要有相应的文档书写规范,要使源程序代码的逻辑简明清晰、易读易懂。这样尽管我们不是设计系统的人员,当看到源程序代码的时候也能容易读懂代码的意思。
其次就是测试的内容,从测试的文档中我们可以得出,其实测试在软件开发中同样占据了重要的地位,它主要就是尽可能多的找到问题并排除其中的潜藏的错误,最终把一个高质量的软件系统交给用户使用。它要求测试人员也要有很高的技术水平。
第二篇:软件测试实习报告
这次软件工程实训是从20xx.12.26号开始的,截至20xx.12.31号。实训内容是用java相关知识(主要是jsp)做一个物流配送系统。下面谈谈对这次实训的看法。
因为自己平时对java知识储备不足,特别是jsp这一块基本不了解怎么回事,所以一拿到这个项目,我心里都是没有底的,再加上我被分到的那个组,我知道就意味着是我一个人在战斗了。呵呵,26号,实训开始了,我们的老师是来自中软国际公司的程序员,一个是周褀,一个是朱映,都是一身朴素的着装,让我感觉做软件的也没什么两样。老师介绍了自己之后,就直接切入正题了,分析了下我们各个组的系统,即将用到的知识,然后就总体把觉得需要补充的知识(jsp和数据库连接等这几块)给我们实际操作了下,因为当时看到用jsp,还讲的那么认真,当时我就后悔了,平时要是多听点,现在老师这么认真的给我们讲,这是一个多么难得的机会啊。后悔也没用啊,开始还勉强能理解一点,后来就直接晕了。然后再给大家介绍了一些即将用到的工具,比如rationalRose,SVN,MyEclipse等等。接下来的几天就不再细讲了。下面谈谈通过这次实训的心得体会吧。
通过这次实训,让我了解到工程开发的过程,可行性分析——>需求分析——>概要设计——>详细设计——>代码编写——>测试——>验收。从技术方面上,我开始jsp基础基本上就是零的,在老师和syz2(另外一个物流小组,我一个人基本上是跟她们做的,或者说是看着她们做的)的帮助下,对jsp有了一个大概的认识。其实实训开始前,我还以为做个系统没什么大不了,可是当真正拿到一个项目,我却真的无从下手了,而且就是在知道需求分析和详细设计,在代码编写时,一样寸步难行。通过这个实训,也让我了解到,团队协作是多么的重要。一个人的精力是多么的有限。进一步理解到,企业为什么如此重视团队协作。同时借用老师的话就是团队协作固然重要,但是是建立在个人素质的基础上,假设你个人素质不行,将会影响到整个团队,就别提对团队作更多贡献了。**老师说这几句话的时候,朝向了我,估计是有特殊意义的吧,所以,我将谨记老师的教导。
还有一个收获是从一个同学(小胖)那里得到的,他的那组成员跟我的这组大体一样,我倒是觉得没什么了,不过他倒是很重视这个问题吧。然后他说出来,我也觉得这个问题确实其实是个大的问题。就是不管你会不会这门技术,会不会做这个东西,态度要正确才好,就算你不会做,你也应该认真的对待,将来 出身到社会,就不是说像你现在,不会做就不做,跑去玩游戏了。小胖说出了这段话,也在我身上有了一个印证,虽然我jsp技术知识为0,但我也还是在认真的跟着他们一起做,不会做,就多问,毕竟现在我们是学生,可以毫不顾忌的询问各种问题,老师也会尽力为你回答。将来出身社会就不一样了。虽然,我就算个打酱油的水平,但是这个酱油也要打得有涵量啊。不管怎么样,我能对自己有个交待,虽然我不会,但是这次实训我确实是认真对待了,六天的实训,除了晚上加班外,还花了2个通宵来完成不同阶段的任务,完成与否也不重要了,我至少我做了,这点,是这次我应该对自己的一个肯定。
这次实训的心得基本上就是这些了,最后特别感谢中软国际带我们的那两个老师(周褀,朱映),这两个老师对待我们很平易近人,对我们提出的问题,总是不光解决了,还进行了扩展,晚上也跟我们一起加班加到很晚,印象尤其深刻就是朱映老师为了给小胖解决一个问题,脸都变红了,还在继续努力,这点我并不会觉得老师知识储备不够,我想应该是这个问题的突发吧,一时没想到怎么处理。相反让我感觉更多的就是老师很认真,很负责。还要感谢就是syz2小组的倾力支持,辅导。
第三篇:软件测试实习报告
20XX年11月28日,我怀着提高并实现自我价值的心态,跨进E软件技术有限公司的大门,开始了自己第一份实习工作。这是一家国内知名的专业软件外包企 业,在深圳华南地区位居行业前列。易软自开始从事软件外包业务以来,服务合作模式从人力资源外包发展到项目外包、离岸开发和OEM产品合作等模式。业务领 域包括电信业,金融业,制造业等。特别在电信行业有多年积累,在电信业务领域涉及固网,智能网、移动通信、光网络,电信增值服务等业务领域.易软公司总部 设在深圳, 在上海、南京、北京,广州,重庆,苏州,武汉,大连等地建立了分公司或办事处,就近为客户提供外包服务。
转眼间,三个月实习 时间就过去了。回想起这段时间的工作过程,我从一名普通的大学生到一个为社会服务的软件测试人员,思想觉悟有了很大的提高,作为一个刚刚步入企业的年轻人 来说,什么都不懂,没有任何实践经验,不过在各位同事的帮助下,我很快的融入到了这个新环境,还学到了很多在学校学不到的东西,也认识到了自己很多的不 足,感觉受益匪浅。以下是我在这几个月实习期间对工作的总结以及一些自己的心得体会。
要想成为好的测试人员,首先得了解自己要测试的软件 的相关知识。要了解软件产品的架构是什么样的。要了解软件的市场需求,在接触软件之初要可以多看看用户的反馈信息,这些才是用户最关心的,也是在测试中需 要注意的问题,满足客户是最大的需要。但是了解软件需求之后要学会要多读些软件系统的技术文档,软件设计文档,这些文档可以帮助了解产品如何工作。还有多 看看公司 Bug 库中的问题,这些存在的问题可以帮助自己了解软件产品那些地方存在缺陷,软件系统那些地方会出现错误。软件是运行在一个大环境中,如果对系统不熟悉,那么 有些问题你不能从一个更广阔的层面考虑,学习操作系统的知识,有助于你发现缺陷,定位问题更加准确。比如软件运行在 Windows 或者 Linux ,如果不懂操作系统,你就无法建立测试环境,有些时候时候软件的组件发生问题,就是自己系统配置造成的,对系统不熟悉,会把外在原因归结为软件本身。所以 要学习关于和软件系统相关的知识,比如编程,网络,数据库等。不一定要学习到多好的程度,只是通过这些扩展的知识面,可以在发现问题,解决问题上不会局限 在狭小的圈子里。
和一切相关的人员交流,不同的交流渠道,获取消息是不同的,角度也不同。和客户交流,会在测试中从客户的角度发现问题;和开发人员交流,会了解开发人员怎么实现软件功能的;和项目管理人员交流,会知道开发进度以及遇到的困难。
在这实习期间,我就参与了一个项目,这对我在软件测试方面有了一定的认识和需要注意的地方。
在滕邦国际的项目中,我主要负责的是wap网站、Symbian客户端和后台管理系统,对有关用户界面的测试和测试执行流程有了一定的了解,学会了对bug管理工具Bugzilla的使用。
一.有关用户界面的测试
1.图形测试
图形包括图片、动画、边框、颜色、字体、背景、按钮等。
(1) 要确保图形有明确的用途,应用系统的图片尺寸要合理,并且要能清楚的说明某件事情,一般都链接到某个具体的页面。如在滕邦项目中,wap网站跟客户端的标志图形就不一样,酒店模块、机票模块和旅游模块的图片也是不同的。
(2)验证所有页面字体的风格是否一致。
(3)背景颜色与字体颜色和背景色相搭配。如本项目以该企业颜色为主。
2.内容测试
内容测试用来检验应用系统提供信息的正确性、准确性和相关性。信息的正确性是指信息是可靠的还是误传的。信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口,也就是一般Web站点中的所谓"相关文章列表"。
如在滕邦项目中,在查询机票的时候出现一个不应存在奥林匹克航空,查询机票深圳-北京时,出现美国联合航空 UA,属于国际票务,也是不应该查询到的。
3.整体界面测试
整体界面是指整个 应用系统的页面结构设计,是给用户的一个整体感。例如:当用户浏览应用系统时是否感到舒适,是否凭直觉就知道要找的信息在什么地方?
整个应用系统的设计风格是否一致?
在滕邦国际项目中,除了wap网站外,还有Symbian、Android、WinMobile三个客户端,所以在事先没有标准的情况下,各个平台的导航不统一,各关键字段也不一致。
二.bug管理
1. 在进行测试前,首先必须理解业务和需求。需求和业务理解了,才知道客户想要系统实现什么。然后按照需求来进行测试,不满足需求要求的都可以认为是BUG。
2. 和开发人员沟通。这里说的沟通并不仅仅指通过沟通试图让开发人员修改每个BUG,这个当然需要沟通,但是并不是指所有的BUG都需要修改,这中间涉及到成 本、技术,还有别的问题。除此之外,通过和开发人员搞好关系,对于BUG我们可以问他发生该BUG的原因,修改的大致方法,甚至不修改的原因等等,这有助 于以后测试中多注意、多发现这样的问题,甚至提出修改建议。
如在Symbian客户端测试中,会出现“内存不足,请关闭一些应用程序后再试”的警告,是属于正常现象。
3. 决定BUG严重性的时候,可以根据该被测对象在整个系统中充当的角色,实现的功能来判定如果该对象出现错误会对整个系统产生什么样的影响,对产生的影响打 分,从而定义BUG的严重程度;决定BUG优先级的时候,可以先假设不修复该BUG,出现的这些问题会产生哪些影响,然后判定这些影响的严重性来判定 BUG的优先性。
如在项目中,旅游模块页面中,点击查询时自动退出系统,本是属于High单,而我提的是Medium单。
4. 容易产生BUG的情况:虽然在开发过程中,软件需求通常都会发生改动,所以如果某一部分的软件需求频繁发生变动,那么就会导致和这部分相关的编码和设计会相应的频繁变动,那么在测试中,这部分编码设计实现的部分出现BUG的可能性就很大。
如果在开发的过程中,大量使用了第三方的组件,或者从别的软件中移植了大量的代码,那么和这些第三方的组件和代码相关部分出现BUG的可能性就很大。