软件测试实习日记

时间：2022-08-02 08:49:07 实习日记我要投稿

软件测试实习日记推荐度：
相关推荐

软件测试实习日记

　　时间如快马般匆匆，一天又过去了，相信大家一定感触颇深吧，需要进行好好的总结并且记录在日记里了。为了让您不再为写日记头疼，下面是小编整理的软件测试实习日记，欢迎大家分享。

软件测试实习日记

软件测试实习日记1

　　近段时间，开发和我们一起做性能测试，涉及一些底层的技术，也准备开年之后写自动化的脚本，突然间发现，测试也是有意义的，不想我之前想的那么讨厌，自己在生活中做一些事情，也会按照测试的一些思想来做，有时候变得有点挑剔了，呵呵。而且测试在国内还不成熟，人才还很缺，测试也是很有前途的，自己还是喜欢测试这份工作的。而且测试需要我学的东西也很多，逻辑思维和技术含量还是很高的。唉，恍然大悟了。而且工作这么一段时间，也现实了，在做数据库和开发我的'经验是有限的，而我那有限的一点经验在测试方面也是绰绰有余了，正好为我的测试提升一步。

　　以前学计算机的时候对计算机的知识一点也不感兴趣，自从学了数据库之后就对数据库产生了强烈的兴趣，对计算机的一些知识也，慢慢的产生了兴趣。我喜欢设计数据库，我喜欢想各种方法，尽量让她达到最优的状态，喜欢写SQL语句，各种复杂的查询排序等等都写过，对事务和索引也研究了一段时间。

软件测试实习日记2

　　这周的工作任务主要是完成旅行网的第一轮测试，由于数据库的设计不合理还有待遇写的不够规范导致我们系统打印不出来，后来把代码的合理性，还有新版本的功能都做完了的上线了。

　　1、完成了后台bug的'修改。

　　2、完了管理学生的条件的查询。

　　3、完成了申请打印的条件查询。

　　4、票务管理新增加了一个功能代理商可以修改代理商信息。

　　在完成这几个任务需要的时间我们很少了，这是由于全段时间我们对我们这个系统做过很多的修改功能，还有自己对宇整个代码的流程也是越来熟悉，让我更加有成就感，因为我不会为了一个简单的文件而去浪费时间去学习，还有我们可以自己单独去很多功能了，我就会觉得我们现在的待遇不行。想到这里我们就会觉得自己的心里不平行。

软件测试实习日记3

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

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

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

软件测试实习日记4

　　今天任务是了解H模型，H模型中，软件测试过程活动完全独立，贯穿于整个产品的周期与其他流程并发的进行，某个测试点准备就绪时，就可以从测试准备阶段进行到测试执行阶段。软件测试可以尽早的进行，并且可以根据被测物的不同而分层次进行。

　　H模型揭示了一个原理:软件测试是一个独立的'流程,贯穿产品整个生命周期,与其他流程并发地进行。H模型指出软件测试要尽早准备,尽早执行。不同的测试活动可以是按照某个次序先后进行的,但也可能是反复的,只要某个测试达到准备就绪点,测试执行活动就可以开展

软件测试实习日记5

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

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

软件测试实习日记6

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

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

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

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

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

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

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

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

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

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

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

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

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

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

软件测试实习日记7

　　对于开发来说，并不是所有的bug都需要修复的；而对于测试来说，也并不是所有的bug都是开发去解决的。处理BUG的方法并不是狭隘的将BUG修复，也包括对BUG进行删除操作，和放弃选择。软件测试的确是一门技术，需要学习各种工具的使用。但真正在工作中，思考新的测试方法或引入新的工具，也是在项目空闲时候，一般大家想的最多的是关于项目本身的问题，测试方法也是平时使用的几种而已。我觉得最重要的'是态度，态度意味着责任感，责任感意味着测试人员会想尽办法把问题找出来，才能根据项目需求发现合适的测试方法和具，才能在软件测试时，全神贯注，在执行测试用例时不断发现新的用例。经验对于测试人员是宝贵的资本，所以要经常总结，往往能让自己表达出来的才是体会最深刻的。永远千万不要忽略沟通。

软件测试实习日记8

　　这周的工作主要是对我们整个系统进行检查bug，由于我们的项目做完过程中是没有需求文档，很多的需求根本就不知道要做成什么样子，导致我们在做集成测试中会遇到各种各样的问题。当我遇到问题的时候我们只能以我们现在需求来判断我们原来做过的系统的功能是否完成的`标准。

　　今天在迁移数据的时候，搞的人很烦，由于我们原来历史数据数据太多的冗余。导致我们现在的新系统的数据一直都说不是很完善。还有就是下午遇到我们我们推荐的题目没有找到在数据库里面导致我们打印记错本的报错。这一些都是数据的不完善的造成的结果。

　　进过今天的遇到的问题我想了很多，因为今天的发生的问题我们完成可以通过数据的判断可以解决这些，所以以后写代码的时候多考虑如果没有数据我们写的代码会不会报错呢？还有就是我们写的东西不错在界面中报错。

　　到现在为止我都工作了2个多月了，时间过的飞快，然而自己的想法也是越来越多。因为马上就面临到毕业的时候。一个打算就是自己赶快把自己学校的事情都搞定，还有一个想法就是自己毕业后尽量跑到沿海地方去，自己不要只要会搞技术还要学会怎么去处理业务逻辑。这样的自己才能成长的更快。

软件测试实习日记9

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

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

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

软件测试实习日记10

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

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

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

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

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

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

软件测试实习日记11

　　今天主要研究W模型

　　V模型的局限性在于没有明确地说明早期的测试,无法体现“尽早地和不断地进行软件测试的原则。在V模型中增加软件各开发阶段应同步进行的测试，演化为W模型（如下图）。在模型中不难看出，开发是“V”，测试是与此并行的“V”。基于“尽早地和不断地进行软件测试”的原则，在软件的需求和设计阶段的测试活动应遵循IEEE1012-1998《软件验证与确认（V&V）》的原则。

　　W模型由Evolutif公司提出，相对于V模型，W模型更科学。W模型是V模型的'发展，强调的是测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。测试与开发是同步进行的，从而有利于尽早地发现问题。

　　W模型也有局限性。W模型和V模型都把软件的开发视为需求、设计、编码等一系列串行的活动，无法支持迭代、自发性以及变更调整。

软件测试实习日记12

　　今天主要开始软件测试模型的学习，通过学习我主要了解到软件测试有以下几个模型：

　　1、V模型

　　在软件测试方面，V模型是最广为人知的模型，尽管很多富有实际经验的测试人员还是不太熟悉V模型，或其他的模型。V模型已存在了很长时间，和瀑布开发模型有着一些共同的特性，由此也和瀑布模型一样地受到了批评和质疑。V模型中的过程从左到右，描述了基本的开发过程和测试行为。V模型的价值在于它非常明确地标明了测试过程行政工作计划中存在的`不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。局限性：把测试作为编码之后的最后一个活动，需求分析等前期产生的错误直到后期的验收测试才能发现.

软件测试实习日记13

　　今天是实习的第一天，说实话，其实去的路上心里一直都在忐忑。有点紧张有点兴奋。不知道平常的日常所学所在实践中能否用得上，也不知道实际的`软件测试上怎样的情况。

　　刚到单位时，由于刚认识感觉有点闷闷的。需求测试部并没有太多人，设有一个部门主管，两个需求和一个运维和一个测试，带我的是负责测试工作的刘姐。刚去报到的时候，主管带我到各部门做了个简单的自我介绍，大家都对我这位90后的新同事给予了热烈的欢迎。从热烈的掌声中我感受到了该单位的工作气氛比我想象的活跃多了。值得一提的是，在隔壁的设计部做自我介绍时，居然撞见了一个老乡，聊着才知道，我们办公室还有两个老乡。为这年头遇见老乡不奇怪，但一下子遇见这么多还真是难得。当时，我就想在这里实习一定会很好，很轻松的。

　　介绍完了之后，负责人给我安排了一个座位。由于我之前没接触过软件测试，对软件测试可以说是一片空白。由于种种原因，刘姐给了我一本软件测试基础知识的书，工作第一天我就在座位上看了一整天书。

软件测试实习日记14

　　目标在我的生活中很重要，每天给自己制定一个小目标，这样生活就了激情这也是我保持激情的方法之一。今天我的目标是基本掌握边界值法。

　　使用边界值分析方法设计测试用例时一般与等价类划分结合起来。但它不是从一个等价类中任选一个例子作为代表，而是将测试边界情况作为重点目标，选取正好等于、刚刚大于或刚刚小于边界值的测试数据。

　　(1)如果输入条件规定了值的范围，可以选择正好等于边界值的数据作为合理的测试用例，同时还要选择刚好越过边界值的数据作为不合理的测试用例。

　　(2)如果输入条件指出了输入数据的个数，则按最大个数、最小个数、比最小个数少1、比最大个数多1等情况分别设计测试用例。

　　(3)对每个输出条件分别按照以上原则(1)或(2)确定输出值的边界情况。

　　(4)如果程序的'规格说明给出的输入或输出域是个有序集合(如顺序文件、线形表、链表等)，则应选取集合的第一个元素和最后一个元素作为测试用例。

　　3月11号

　　之前学习了测试用例设计的常用方法，今天计划是学习另一种方法：正交分析法。

　　正交分析法：即正交分解法是将一个力沿着互相垂直的方向(x轴、y轴)进行分解的方法。

　　正交分解法:(1)明确研究对象(或系统);(2)了解运动状态(题给出、暗示或判断、假设);(3)进行受力分析(按顺序，场力、弹力、摩擦力);(4)建立坐标,对力进行正交分解(有相对运动或相对运动趋势的特别是有加速度的，必需建一轴在这方向上,)所建立的坐标原点最好是题目中大多数力的交点.(5)立方程，解之。(有时还需∑M=0，这不属正交分解法)

　　正交表：次数(Runs)：简单的说，就是次数是多少，就有多少个用例。因素数(Factors)：简单的说，就是有多少个变量。水平数(Levels)：比如有三个变量，其中变量取值最多的是四个值，那么水平数就是四。强度(Strength)：即变量间的相互关系，当强度为二时，只考虑变量两两之间的影响，如果强度为三，同考虑三个变量对结果的影响;当强度增加时，用例的个数会急剧增加