软件测试实习日记

时间:2022-09-26 11:30:07 日记 我要投稿

软件测试实习日记

  忙碌而又充实的一天又过去了,想必大家都学习了不少新知识,不妨坐下来好好写写日记吧。快来参考日记是怎么写的吧,下面是小编精心整理的软件测试实习日记,仅供参考,大家一起来看看吧。

软件测试实习日记

软件测试实习日记1

  昨天把所有的记错本学生掌握的正确的知识点还有错误的知识点都统计出来,虽然功能已经实现了,但是我们我觉得这个模块是真的没有做完的,因为虽然功能可以正常的显示了,但是我们没有测试所有的学生的显示的结果是根据我们需求来的,今天的主要任务就是做测试,我在打印所有的学生的记错本的时候发现我在每一个学生的记错本中打印所有学生的错误知识点了,这就是一个集合没有在循环内生成的原因。

  所以我们以后工作都需要自己测试过所有的功能才去提交。这样是一个好的习惯,只要这样我们在工作提交的时候我不需要每个时候都知道我们的工作是否已经完成了,如果不去测试而且把我们做的东西提交上去我们,我们的客户发现我们的产品都不好,让我们的用户觉得这个东西不成熟,这样我们就会失去很多的用户。

软件测试实习日记2

  实习的第一周

  按照公司安排,分配到基站那边熟悉设备和操作器件任务是认识基站设备RBS2206(室内宏蜂窝)的组成,请点各基站设备资产,登记载波的开启情况,进行备用电池的放电测试,门禁系统的开启关闭操作,空调温度的调整(一般为26度)等

  由于我们队员较多,队长安排我们向另外两名早来的实习生学习我们的工作地点是海珠区的中国移动的各个基站点(主要分布在楼宇天台和地下停车场),时间是每天早上9点钟到下午6点,中午休息一会儿工作任务较为简单,操作起来单调机械,需要乘坐面包车到处去各个点奔波抱着学习和吃苦的态度,还是认真的完成任务起先进入基站都感觉好奇,认真地向队长和队员们请教问题有的问题都觉得太简单,但书本上从未涉及过,还是坦诚地向别人请教

  这一周的工作下来,学会了基站的各个部件的位置组成和实物外观,结合所学书本上的知识,加深了各器件的了解和提高了实际动手操作能力学会了与来自不同教育背景和生活地方的同事的交流与合作,深感工作上要不耻下问和同事间要合作紧密才能很好地完成工作任务

  实习的第二周

  依然是在基站学习工作任务与上一周的大概相同,熟悉基站设备,备用电池的放电测试,不过开始进行故障处理和部分时间进行巡检

  工作地点仍然是海珠区的广东移动的基站机房与室外基站,不过检查的基站点与上一周略为不同,都第一次进入检查时间上也一样,虽然我们组要值夜班,考虑到我们实习生的身份,暂时不作安排

  这一周的工作与之前的工作内容大致相同,其中故障处理较多,故障处理一般就是更换基站设备,如CDU,TRU(载波),DXU等,更换设备有一套标准的流程,实践动手不能马虎了事还有部分巡检,需要用OMT软件连接设备,主要用来定位基站设备故障工作上依然单调枯燥,但不能放松,以免出现安全事故或工作不到位,给下一步流程的工作的同事带来重复的麻烦

  实习的第三周

  基站工作结束,开始做网优相关工作,网优主要包括路测,验收,楼宇普查,扫频等任务,是比基站的工作复杂一点,是处理解决信号问题的主要人员

  工作地点是广州移动的业务数据中心,我所在的组是西区,位于体育中心和珠江新城一带,工作时间与之前一样第一天由负责人说明工作流程和注意事项,没有接触到实际的网优工作,都是一些送文件和设备给同事使用的跑腿工作

  这一周的工作不多,负责人的一番指导和教悔也让我认识网优这一职位属于干活多薪资少的工作,需要耐心努力地学习理论和操作知识,吃苦耐劳踏实工作才能完成工作

  实习的第四周

  这一周才是接触到网优的实际工作,路测,路测就是道路测试信号,由于道路上都可能占用多个小区,甚至是越区覆盖,是网优中分析处理问题的一个很好的学习过程

  工作地点是广州大道位于中山大道及体育东路之间的一段道路,实际上就是天河路一带,时间是凌晨2点开始,因为刚刚进行过割接小区,所以测试一下割接后小区占用情况数据显示信号强度正常,只存在局部地点出现质差,割接成功

  这一周的工作是和一位路测队长学习,在测试过程中繁繁出现问题,手机电池没电,数据线连不通,电脑鼠标不动,没有带上3G卡,最后测试时间缩短减少电池使用时间,回公司更换数据线,暂时没有测试3G与2G切换情况信号测试前的设备检查是否完好,测试软件的熟悉准备都是测试前必须注意的问题

软件测试实习日记3

  第二天上班,我有点不习惯早起,公司每天8:30起床。可能是因为这是我的第一份正式的实习工作,以前都不曾这么正式的上过班,对于上班没有过什么想法。所以第二天一大早我不慌不忙的出发了。又由于没平时没在上班时间出去过,对于挤公交也没什么概念。挤公交挤到想死。真想说,做个上班族,挤公交是一门必修课。折腾了一早上,我终于踩点到公司报到了。

  一大早赶到办公室,觉得桌子很脏,就在清洁阿姨那借来了抹布和水桶,把自己的卫生搞好了,开始了一天的工作。

  今天我又开始看软件测试的书籍,了解到黑盒测试又称功能测试:是对已知产品的功能设计规格,可以进行测试证明每个实现了的功能是否符合要求。白盒测试则是对已知产品的内部工作的过程,可以通过测试证明每种内部操作是否符合设计规格是否符合设计规格要求,所有内部成分是否以经过检查。

软件测试实习日记4

  早上从寝室出发就暗示自己要踏踏实实的学习忌浮躁。早上我早早的到公司,开始我的学习,今天我学习的主要内容是测试用例设计方法之划分等价类法。

  ①如果某个输入条件规定了取值范围或值的个数。则可确定一个合理的等价类(输入值或数在此范围内)和两个不合理等价类(输入值或个数小于这个范围的最小值或大于这个范围的最大值)。

  ②如果规定了输入数据的一组值,而且程序对不同的输入值做不同的处理,则每个允许输入值是一个合理等价类,此处还有一个不合理等价类(任何一个不允许的输入值)。

  ③如果规定了输入数据必须遵循的规则,可确定一个合理等价类(符合规则)和若干个不合理等价类(从各种不同角度违反规则)。

  ④如果已划分的等价类中各元素在程序中的处理方式不同,则应将此等价类进一步划分为更小的等价类。

软件测试实习日记5

  如何设计测试用例,如何评审测试用例,最后如何管理测试用例,这都是我们测试工作中必须要去改进的问题。在之前的公司,由于团队工作任务繁忙,我们没有太多的时间去管理和优化测试用例,也因此对用例方面少了太多的思考,而且虽然有对于用例的评审,但一直以来,我认为是做得不够好的,毕竟每次评审下来,感觉效果没有预期的那么好,主要还是没有足够的时间去管理,所以无法引起重视。不过,现在我想我需要花大量的时间来管理用例了,而且要保证有序的进行,最后输出让团队中各个成员都认为满意而且高效的测试用例。对于用例管理的根本问题,我个人认为是分类上,如何有效的维护和优化用例,就是需要前期明确的分类规划,根据分类的优先级一步一步地来完成就可以了,到最后,我们也可以有效把控的测试覆盖度。

  当前,我们大致可以把测试用例分称三个方面,分别是功能、UI和业务流程,从这三个角度来进行设计。

  1、从功能的角度,功能是每个项目测试的重点,通常在测试人员得到需求文档的时候,我们就开始设计测试用例,那么这个时候需求文档上列出都是功能以及部分一些业务逻辑等,所以在测试用例的第一阶段就是完成功能的用例设计。不过这里,肯定会让很多人疑惑,其实功能、业务还有UI,都是有关联的,而且很多时候无法分解的。这里后面我会举个例子说明哈,但绝非都是可以分类,只是谈谈如何分解的方法,最重要的就是不要遗漏就行。

  2、从UI的角度,UI通常是指界面测试,这个应该不难理解,但要想与功能点进行分解,也不是那么容易区分的,所以我们来直观的说明哈。界面测试,注重样式,外观、整洁、摆放以及易用性,还包括用户体验等。

  3、从业务的角度,这个相对来说,还比较好理解,业务通常是指一连串的动作所连接起来的流程,这个流程必须有行为和目标,或者说方向。业务通常是一个项目或者产品设计的核心,当下,越来越多的应用业务流程都是非常复杂,所以对于业务的用例设计,就是考验一个测试人员的业务水平如何。

  下面通过一个证券交易平台上的买入和撤单业务,进行具体说明:

  业务说明:买入业务包括股票代码、当前价格、买入价格,买入股票数量、确定买入按钮和取消按钮;

  撤单业务包括选择撤单的未成交业务、撤单成功、撤单失败以及取消撤单按钮;

  以上只是大致列举了一部分。

  功能点:买入按钮、取消按钮、选择撤单、撤单按钮和取消撤单按钮等

  UI界面测试:股票代码、当前价格、买入价格、买入股票数量,所有的文本框;买入成功/失败的提示框;撤单成功/失败的提示框;撤单成功/失败的业务状态等

  业务测试:买入业务,从输入买入表单的数据,到提交表单,到最后买入的表单显示的位置,以及买入提交但未成交,可以撤单,完成撤单的业务,到撤单成功或者失败等,这一连串的工作组合就是一个业务流程。

  其实这里就存在一个争议性的问题,对于买入和撤单,既可以作为功能点,也可以作为一个业务逻辑来设计,但从本质上来讲,功能点注重单独的操作,而业务流重的在是一个流程,还需要具体业务去甄别。功能点的设计更主要对这个买入和撤单的按钮本身进行用例设计;而业务则是需要从买入和撤单之前的输入到最后输出这样一个过程来设计。

  以上也只是大概的一个简单的说明,具体的操作还得根据自己的实际流程来执行,毕竟测试用例的管理是一个长期的积累和沉淀的过程,好的方法都是总结出来的。对于测试来说,用例是基础,对于回归测试、自动化、性能等等都是根本,管理好测试用例,也就是提高测试的工作质量。

软件测试实习日记6

  今天主要是进行系统测试和评估测试。同时整个开发过程中我们小组也协同项目经理对各个方面进行了质量评审。从各个方面对不同的工件进行了评审,其中大部分通过了,不可避免地其中也有一些问题,但是我们采取了相应的纠正措施,保证了各个工件的质量。

  学任何东西都应该认真研究,否则一知半解还不如不学;另外要注重把平时所学和实际相联系。熟练的专业技能是一个公司生存和发展的资本。现在主要的任务还是多学习,多积累。

软件测试实习日记7

  前面测试计划的学习告一段落了。从今天起我将专心软件测试用例设计的学习。

  软件测试用例就是一个文档,描述输入、动作、或者时间和一个期望的结果,其目的是确定应用程序的某个特性是否正常的工作。

  测试输入

  提供测试执行中的各种输入条件。根据需求中的输入条件,确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的'依赖性,如果软件需求中没有很好的定义需求的输入,那么测试用例设计中会遇到很大的障碍。

  操作步骤

  提供测试执行过程的步骤。对于复杂的测试用例,测试用例的输入需要分为几个步骤完成,这部分内容在操作步骤中详细列出。

  预期结果

  提供测试执行的预期结果,预期结果应该根据软件需求中的输出得出。如果在实际测试过程中,得到的实际测试结果与预期结果不符,那么测试不通过;反之则测试通过。

软件测试实习日记8

  项目经过一段时间的测试,终于快要完成了,这个星期主要是回归测试。就是把提过BUG的单,经过开发修改过后的系统再进行测试。回归全部通过,说明系统的质量不差。测完并且编写用户手册。 回归测试并不减少对系统新功能和特征的测试需求,回归测试包应包括新功能和特征的测试。如果回归测试包不能达到所需的覆盖要求,必须补充新的测试用例使覆盖率达到规定的要求。

  有成为一名优秀的软件工程师必须要有严谨的工作态度,能够胜任反复性的工作。必须要懂得与人良好的沟通。描述具体问题时,应准确,最后以图文并茂的方式展示问题。

  在组织回归测试时需要注意两点,首先是各测试阶段发生的修改一定要在本测试阶段内完成回归,以免将错误遗留到下一测试阶段。其次,回归测试期间应对该软件版本冻结,将回归测试发现的问题集中修改,集中回归。

软件测试实习日记9

  做测试已不知不觉有两个月了。现在我仅自我总结以下如何做好测试计划工作。

  1.明确测试的目标,增强测试计划的实用性

  编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷,因此软件测试计划的价值取决于它对帮助管理测试项目,并且找出软件潜在的缺陷。因此,软件测试计划中的测试范围必须高度覆盖功能需求,测试方法必须切实可行,测试工具并且具有较高的实用性,便于使用,生成的测试结果直观、准确

  2.坚持“5W”规则,明确内容与过程

  “5W”规则指的是“What(做什么)”、“Why(为什么做)”、“When(何时做)”、“Where(在哪里)”、“How(如何做)”。利用“5W”规则创建软件测试计划,可以帮助测试团队理解测试的目的(Why),明确测试的范围和内容(What),确定测试的开始和结束日期(When),指出测试的方法和工具(How),给出测试文档和软件的存放位置(Where)。

  3.采用评审和更新机制,保证测试计划满足实际需求

  测试计划写作完成后,如果没有经过评审,直接发送给测试团队,测试计划内容的可能不准确或遗漏测试内容,或者软件需求变更引起测试范围的增减,而测试计划的内容没有及时更新,误导测试执行人员。

  4.分别创建测试计划与测试详细规格、测试用例

  应把详细的测试技术指标包含到独立创建的测试详细规格文档,把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方法和资源配置,而测试详细规格、测试用例是完成测试任务的具体战术。

软件测试实习日记10

  了解了各种测试用例的方法,之后又在实际项目中设计了一些测试用例,总体感觉就是:公司里分配写作测试用例的时间并不长,而且提供的文档也不全面,所以写测试用例要符合测试部门的当前现状和项目的测试特点,综合考虑,所以看起来有点像测试计划的某些内容,但是对问题的细化程度不一样。

  测试用例的设计是一项复杂的测试工作,测试用例的设计方法需要考虑测试的目标,被测试软件的特性,测试者人力资源的技术和能力,测试组织形式,测试进度、测试成本等多个方面。

  确定测试用例的输入数据确实对于测试用例非常重要,它决定着测试用例的执行效果和效率,但是确定输入测试数据只是设计测试用例的一个步骤,而不是全部。因此,不能把测试用例的设计方法等同于测试用例数据的方法。

软件测试实习日记11

  今天进步点点,明天前进一大步。知识需要积累。我们切不可心浮气粗。通过这几天对测试用例设计方法的学习。我进行了测试用例管理的深思。

  1、从功能的角度,功能是每个项目测试的重点,通常在测试人员得到需求文档的时候,我们就开始设计测试用例,那么这个时候需求文档上列出都是功能以及部分一些业务逻辑等,所以在测试用例的第一阶段就是完成功能的用例设计。不过这里,肯定会让很多人疑惑,其实功能、业务还有UI,都是有关联的,而且很多时候无法分解的。这里后面我会举个例子说明哈,但绝非都是可以分类,只是谈谈如何分解的方法,最重要的就是不要遗漏就行。

  2、从UI的角度,UI通常是指界面测试,这个应该不难理解,但要想与功能点进行分解,也不是那么容易区分的,所以我们来直观的说明哈。界面测试,注重样式,外观、整洁、摆放以及易用性,还包括用户体验等。

  3、从业务的角度,这个相对来说,还比较好理解,业务通常是指一连串的动作所连接起来的流程,这个流程必须有行为和目标,或者说方向。业务通常是一个项目或者产品设计的核心,当下,越来越多的应用业务流程都是非常复杂,所以对于业务的用例设计,就是考验一个测试人员的业务水平如何。

软件测试实习日记12

  现在对测试工作有了全新的认识,测试能力是要不断提高的;可扩展性:具备可以进行测试工作的基本功能,在功能和性能上还需完善和补充,好在可扩展性好,还有优化的余地。测试工作在很大程度上改变了我的思维方向,几个月前的我对任何事物都几乎是在没有任何依据的情况下,盲目的乐观自信,而现在面对事物时我习惯性的以怀疑的角度切入,正因为怀疑,就会对事物追根刨底,对自己和自己所要处理的事物具备更强烈的责任心。所以作为一个测试人来说怀疑是出发点,体现在测试人身上的品质就是责任心。旁观测试组中一个个兢兢业业工作着的同事们,想到原来生病的不只我,他们病得更重,我不禁哑然失笑,一下子觉得自己病得理直气壮了,也坚定了自己将测试工作进行到底的决心。

软件测试实习日记13

  激情与耐心,就像火与冰,看似两种完全不同的东西,却能碰撞出最美丽的火花。在中心时,老师就跟我说,想做软件测试这一块,激情与耐心必不可少,在产品更新方面,这一行业就像做新闻工作,不断的在更新,这就需要你有激情去发现与创造,而你的耐心就要用到不断的学习新知识,提高自己的专业水平和业务了解水平。在一些具体的工作当中也是这样的:记得刚来公司实习的时候老板安排我学习对软件测试基础学习,我本想这应该是非常简单的事,可没想到出现了很多问题,还是在师傅一步一步的教导下,慢慢的把自己思路调整过来。对于软件测试的学习我只能保持激情和耐心,一步一个脚印。

软件测试实习日记14

  今天我终于要来时实践测试我们公司的网站了。带我的刘姐今早把握喊到他的跟前,我了我一些关于测试的的基本知识。值得高兴的是:我都能应答如流。第一次和真正的测试人员有了比较深入的了解。从刘姐对测试的理解中,我也感受到做测试人员并非易事。作为一个测试人员必须具备有耐性、有较强的沟通能力、一定的合作意识等基本素质。对于这些基本素质要求,下班之后我进行了自我反省。我觉得自己好事一个比较有亲和力、有耐心的人。可能稍微欠佳的就是沟通能力不是很强。觉得自己以后应该在沟通方面取得更大的进步。为了做好一个合格的软件测试人员,我必须努力做到这些。

软件测试实习日记15

  怀揣着最初的梦想、保持着那份激情和耐心、我继续着我软件学习的路程。今天我开始了测试用例设计方法的学习。

  测试用例是软件测试的核心

  软件测试的重要性是毋庸置疑的。但如何以最少的人力、资源投入,在最短的时间内完成测试,发现软件系统的缺陷,保证软件的优良品质,则是软件公司探索和追求的目标。每个软件产品或软件开发项目都需要有一套优秀的测试方案和测试方法。测试用例的设置

  我们早期的测试用例是按功能设置用例。后来引进了路径分析法,按路径设置用例。目前演变为按功能、路径混合模式设置用例。

  按功能测试是最简捷的,按用例规约遍历测试每一功能。

  对于复杂操作的程序模块,其各功能的实施是相互影响、紧密相关、环环相扣的,可以演变出数量繁多的变化。没有严密的逻辑分析,产生遗漏是在所难免。路径分析是一个很好的方法,其最大的优点是在于可以避免漏测试。

【软件测试实习日记】相关文章:

银行实习日记 -日记01-01

建筑实习日记 -日记01-01

物流实习日记 -日记01-01

暑假实习日记 -日记01-01

实习日记的格式 -日记01-01

会计实习日记范文 -日记01-01

认识实习日记12-13

顶岗实习日记08-24

律师实习日记08-23