以下是小编帮大家整理的软件测试实习生实习日记（共含7篇），供大家参考借鉴，希望可以帮助到您。同时，但愿您也能像本文投稿人“林深时见鹿鸣”一样，积极向本站投稿分享好文章。
七，八月流火,暑期的背影已经渐渐远去,当我转身回眸时,才发现在那个刚刚逝去的夏日里仍然留有自己的身影.想起在南京XX系统仪表公司软件部实习的日子,挤公交车，埋头钻研技术，暑假的辛勤工作场面历历在目，很是难忘。
7月10号，回家四天后的一个明媚的清晨，我踏上了暑假实习的大路，不知前方的酸甜苦辣，喜怒哀乐，踌躇满志的迈着步伐走向了理想中的自由。那时我什么都没想，只是发现自己一瞬间长大了，不再拿着父母给的生活费浪费了。终于要独立了，终于要自由了。内心的喜悦大家应该都能理解。
7月11号-7月15号，失望，已经不单写到了脸上，行为上已经也有所怠慢了。也许是我的无精打采和刚进公司的表现形成了鲜明的对比，项目经理(自称周大侠，人称周哥)也觉得我们在这仅仅是自学是不够的，应该来点激情的东西。于是就开始给我们来了个欢迎会议，啥都不懂，一群人都坐在周边的沙发上，只有我们三个实习生，一本正经的坐在会议桌周围，聚精会神的听着小裴哥(另一项目经理)在那介绍公司的经营方向，公司历史。说实话，公司历史不多，3年左右，发展方向很普通，但是“后台”很硬。用公司“华仔”的话来说，叫做“咱们和江苏省XX局是穿一条裤子的”。的确，咱们公司是个不经传的小公司，上海XX是咱们名义上的father，咱们只是人家的一个son。但是我们也正在走向成熟，走向自立。通过跟江苏省安监局合作，我们公司在一步一步的壮大，也必然壮大。想到那次会议，现在还真有点激动，想到我还不是一无所知，一无是处，我对我的未来的期望，对公司的好感，都达到了前所未有的高度。
7月16号-7月31号，自从上次的欢迎会，我又进入了正常的步入了正轨，又拥有了激-情。也认识了我办公桌后面的“华仔”(原名杨华)和“老韩”(原名韩翔)，尽管公司任何一个人都能当我们的大哥，大姐，但是之间的情谊就不局限于大哥大姐了。那是两个字“哥们”。在这15天里面，我一边自学着公司要求具备的技术，一边做着周哥吩咐的常熟安监局电子管理系统的测试工作，我井然的成为了三个实习生名义上的小头头。分配工作，收发测试文档，整合测试文档。向周哥和华仔，老韩报告需要改正的地方，这15天过的也很充实。尽管测试并不是想象的那么简单，但是我们这些实习生，还是积极的完成了分配的任务，也完成了测试，也加入到了改进管理系统的讨论,感觉真是颇好,深感团队的合作有时候还需要大家的齐心合力。
8月1号-8月10号，鉴于8月8号开幕的奥运会，着实让我这个奥运迷高兴了一把，尽管测试工作还在做收尾工作，但是也无法打消我对奥运开幕式的期待，正午吃饭的时候，一边吃饭，一边浏览网上关于奥运会开幕式的小道消息，大家也在谈论着奥运点火人选。紧张而又充实的等到了8月8号，上网看了奥运会，甚是感叹，一遍看过，意犹未尽，又看了一遍重播。内心不由得赞叹“老谋子真是创意非凡啊!”
8月11号-8月20号，终于常熟安监局电子管理系统的测试告一段落，但是随之而来的任务又来了，写常熟安监局电子管理系统的使用说明书，也是，我们测试这个系统，必然对该系统的操作流程必定很熟悉。但是当时接到这个任务很是犹豫，因为要写这个说明书，花费的时间真是太多了，而且我们自学struts2.0还欠火候，打算最后半个月加紧补上上月测试耽误的时间，所以我很是为难，怎么办呢?最后想到了个还算两全其美的方法，上午我们自学，下午写说明文档，就这样电子管理系统使用说明书，一个星期左右被我们拿下，心中颇有成就感。
我在我的位置上自学测试用例设计的学习。
通过今天的学习我总结了软件测试用例就是一个文档，描述输入、动作、或时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常工作。软件测试用例的设计主要从用例编号、测试标题、重要级别、测试输入、测试步骤、预期结果6个域考虑，结合相应的软件需求文档，在掌握一定测试用例设计方法的基础上，设计出比较全面、合理的测试用例。
项目经过一段时间的测试，终于快要完成了，这个星期主要是回归测试。就是把提过BUG的单，经过开发修改过后的系统再进行测试。回归全部通过，说明系统的质量不差。测完并且编写用户手册。 回归测试并不减少对系统新功能和特征的测试需求，回归测试包应包括新功能和特征的测试。如果回归测试包不能达到所需的覆盖要求，必须补充新的测试用例使覆盖率达到规定的要求。
有成为一名优秀的软件工程师必须要有严谨的工作态度，能够胜任反复性的工作。必须要懂得与人良好的沟通。描述具体问题时，应准确，最后以图文并茂的方式展示问题。
在组织回归测试时需要注意两点，首先是各测试阶段发生的修改一定要在本测试阶段内完成回归，以免将错误遗留到下一测试阶段。其次，回归测试期间应对该软件版本冻结，将回归测试发现的问题集中修改，集中回归。
激情与耐心，就像火与冰，看似两种完全不同的东西，却能碰撞出最美丽的火花。在中心时，老师就跟我说，想做软件测试这一块，激情与耐心必不可少，在产品更新方面，这一行业就像做新闻工作，不断的在更新，这就需要你有激情去发现与创造，而你的耐心就要用到不断的学习新知识，提高自己的专业水平和业务了解水平。在一些具体的工作当中也是这样的：记得刚来公司实习的时候老板安排我学习对软件测试基础学习，我本想这应该是非常简单的事，可没想到出现了很多问题，还是在师傅一步一步的教导下，慢慢的把自己思路调整过来。对于软件测试的学习我只能保持激情和耐心，一步一个脚印。
如何设计测试用例，如何评审测试用例，最后如何管理测试用例，这都是我们测试工作中必须要去改进的问题。在之前的公司，由于团队工作任务繁忙，我们没有太多的时间去管理和优化测试用例，也因此对用例方面少了太多的思考，而且虽然有对于用例的评审，但一直以来，我认为是做得不够好的，毕竟每次评审下来，感觉效果没有预期的那么好，主要还是没有足够的时间去管理，所以无法引起重视。不过，现在我想我需要花大量的`时间来管理用例了，而且要保证有序的进行，最后输出让团队中各个成员都认为满意而且高效的测试用例。对于用例管理的根本问题，我个人认为是分类上，如何有效的维护和优化用例，就是需要前期明确的分类规划，根据分类的优先级一步一步地来完成就可以了，到最后，我们也可以有效把控的测试覆盖度。
当前，我们大致可以把测试用例分称三个方面，分别是功能、UI和业务流程，从这三个角度来进行设计。
1、从功能的角度，功能是每个项目测试的重点，通常在测试人员得到需求文档的时候，我们就开始设计测试用例，那么这个时候需求文档上列出都是功能以及部分一些业务逻辑等，所以在测试用例的第一阶段就是完成功能的用例设计。不过这里，肯定会让很多人疑惑，其实功能、业务还有UI，都是有关联的，而且很多时候无法分解的。这里后面我会举个例子说明哈，但绝非都是可以分类，只是谈谈如何分解的方法，最重要的就是不要遗漏就行。
2、从UI的角度，UI通常是指界面测试，这个应该不难理解，但要想与功能点进行分解，也不是那么容易区分的，所以我们来直观的说明哈。界面测试，注重样式，外观、整洁、摆放以及易用性，还包括用户体验等。
3、从业务的角度，这个相对来说，还比较好理解，业务通常是指一连串的动作所连接起来的流程，这个流程必须有行为和目标，或者说方向。业务通常是一个项目或者产品设计的核心，当下，越来越多的应用业务流程都是非常复杂，所以对于业务的用例设计，就是考验一个测试人员的业务水平如何。
下面通过一个证券交易平台上的买入和撤单业务，进行具体说明：
业务说明：买入业务包括股票代码、当前价格、买入价格，买入股票数量、确定买入按钮和取消按钮;
撤单业务包括选择撤单的未成交业务、撤单成功、撤单失败以及取消撤单按钮;
以上只是大致列举了一部分。
功能点：买入按钮、取消按钮、选择撤单、撤单按钮和取消撤单按钮等
UI界面测试：股票代码、当前价格、买入价格、买入股票数量，所有的文本框;买入成功/失败的提示框;撤单成功/失败的提示框;撤单成功/失败的业务状态等
业务测试：买入业务，从输入买入表单的数据，到提交表单，到最后买入的表单显示的位置，以及买入提交但未成交，可以撤单，完成撤单的业务，到撤单成功或者失败等，这一连串的工作组合就是一个业务流程。
其实这里就存在一个争议性的问题，对于买入和撤单，既可以作为功能点，也可以作为一个业务逻辑来设计，但从本质上来讲，功能点注重单独的操作，而业务流重的在是一个流程，还需要具体业务去甄别。功能点的设计更主要对这个买入和撤单的按钮本身进行用例设计;而业务则是需要从买入和撤单之前的输入到最后输出这样一个过程来设计。
以上也只是大概的一个简单的说明，具体的操作还得根据自己的实际流程来执行，毕竟测试用例的管理是一个长期的积累和沉淀的过程，好的方法都是总结出来的。对于测试来说，用例是基础，对于回归测试、自动化、性能等等都是根本，管理好测试用例，也就是提高测试的工作质量。
目标在我的生活中很重要，每天给自己制定一个小目标，这样生活就了激情这也是我保持激情的方法之一。今天我的目标是基本掌握边界值法。
使用边界值分析方法设计测试用例时一般与等价类划分结合起来。但它不是从一个等价类中任选一个例子作为代表，而是将测试边界情况作为重点目标，选取正好等于、刚刚大于或刚刚小于边界值的测试数据。
(1)如果输入条件规定了值的范围，可以选择正好等于边界值的数据作为合理的测试用例，同时还要选择刚好越过边界值的数据作为不合理的测试用例。
(2)如果输入条件指出了输入数据的个数，则按最大个数、最小个数、比最小个数少1、比最大个数多1等情况分别设计测试用例。
(3)对每个输出条件分别按照以上原则(1)或(2)确定输出值的边界情况。
(4)如果程序的规格说明给出的输入或输出域是个有序集合(如顺序文件、线形表、链表等)，则应选取集合的第一个元素和最后一个元素作为测试用例。
3月11号
之前学习了测试用例设计的常用方法，今天计划是学习另一种方法：正交分析法。
正交分析法：即正交分解法是将一个力沿着互相垂直的方向(x轴、y轴)进行分解的方法。
正交分解法:(1)明确研究对象(或系统);(2)了解运动状态(题给出、暗示或判断、假设);(3)进行受力分析(按顺序，场力、弹力、摩擦力);(4)建立坐标,对力进行正交分解(有相对运动或相对运动趋势的特别是有加速度的，必需建一轴在这方向上,)所建立的坐标原点最好是题目中大多数力的交点.(5)立方程，解之。(有时还需∑M=0，这不属正交分解法)
正交表：次数(Runs)：简单的说，就是次数是多少，就有多少个用例。因素数(Factors)：简单的说，就是有多少个变量。水平数(Levels)：比如有三个变量，其中变量取值最多的是四个值，那么水平数就是四。强度(Strength)：即变量间的相互关系，当强度为二时，只考虑变量两两之间的影响，如果强度为三，同考虑三个变量对结果的影响;当强度增加时，用例的个数会急剧增加
现在对测试工作有了全新的认识，测试能力是要不断提高的；可扩展性：具备可以进行测试工作的基本功能，在功能和性能上还需完善和补充，好在可扩展性好，还有优化的余地。测试工作在很大程度上改变了我的思维方向，几个月前的我对任何事物都几乎是在没有任何依据的情况下，盲目的乐观自信，而现在面对事物时我习惯性的以怀疑的角度切入，正因为怀疑，就会对事物追根刨底，对自己和自己所要处理的事物具备更强烈的责任心。所以作为一个测试人来说怀疑是出发点，体现在测试人身上的品质就是责任心。旁观测试组中一个个兢兢业业工作着的同事们，想到原来生病的不只我，他们病得更重，我不禁哑然失笑，一下子觉得自己病得理直气壮了，也坚定了自己将测试工作进行到底的决心。
★ 软件测试实习总结
★ 软件测试工作总结
★ 软件测试简历
★ 实习生实习日记
