软件测试实习日记十篇
项目经过一段时间的测试，终于快要完成了，这个星期主要是回归测试。就是把提过BUG的单，经过开发修改过后的系统再进行测试。回归全部通过，说明系统的质量不差。测完并且编写用户手册。 回归测试并不减少对系统新功能和特征的测试需求，回归测试包应包括新功能和特征的测试。如果回归测试包不能达到所需的覆盖要求，必须补充新的测试用例使覆盖率达到规定的要求。
有成为一名优秀的软件工程师必须要有严谨的工作态度，能够胜任反复性的工作。必须要懂得与人良好的沟通。描述具体问题时，应准确，最后以图文并茂的方式展示问题。
在组织回归测试时需要注意两点，首先是各测试阶段发生的修改一定要在本测试阶段内完成回归，以免将错误遗留到下一测试阶段。其次，回归测试期间应对该软件版本冻结，将回归测试发现的问题集中修改，集中回归。
怀揣着最初的梦想、保持着那份激情和耐心、我继续着我软件学习的路程。今天我开始了测试用例设计方法的学习。
测试用例是软件测试的`核心
软件测试的重要性是毋庸置疑的。但如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。每个软件产品或软件开发项目都需要有一套优秀的测试方案和测试方法。测试用例的设置
我们早期的测试用例是按功能设置用例。后来引进了路径分析法，按路径设置用例。目前演变为按功能、路径混合模式设置用例。
按功能测试是最简捷的，按用例规约遍历测试每一功能。
对于复杂操作的程序模块，其各功能的实施是相互影响、紧密相关、环环相扣的，可以演变出数量繁多的变化。没有严密的逻辑分析，产生遗漏是在所难免。路径分析是一个很好的方法，其最大的优点是在于可以避免漏测试。
目标在我的生活中很重要，每天给自己制定一个小目标，这样生活就了激情这也是我保持激情的方法之一。今天我的目标是基本掌握边界值法。
使用边界值分析方法设计测试用例时一般与等价类划分结合起来。但它不是从一个等价类中任选一个例子作为代表，而是将测试边界情况作为重点目标，选取正好等于、刚刚大于或刚刚小于边界值的测试数据。
(1)如果输入条件规定了值的范围，可以选择正好等于边界值的数据作为合理的测试用例，同时还要选择刚好越过边界值的数据作为不合理的测试用例。
(2)如果输入条件指出了输入数据的个数，则按最大个数、最小个数、比最小个数少1、比最大个数多1等情况分别设计测试用例。
(3)对每个输出条件分别按照以上原则(1)或(2)确定输出值的边界情况。
(4)如果程序的规格说明给出的输入或输出域是个有序集合(如顺序文件、线形表、链表等)，则应选取集合的第一个元素和最后一个元素作为测试用例。
3月11号
之前学习了测试用例设计的常用方法，今天计划是学习另一种方法：正交分析法。
正交分析法：即正交分解法是将一个力沿着互相垂直的方向(x轴、y轴)进行分解的方法。
正交分解法:(1)明确研究对象(或系统);(2)了解运动状态(题给出、暗示或判断、假设);(3)进行受力分析(按顺序，场力、弹力、摩擦力);(4)建立坐标,对力进行正交分解(有相对运动或相对运动趋势的特别是有加速度的，必需建一轴在这方向上,)所建立的坐标原点最好是题目中大多数力的交点.(5)立方程，解之。(有时还需∑M=0，这不属正交分解法)
正交表：次数(Runs)：简单的说，就是次数是多少，就有多少个用例。因素数(Factors)：简单的说，就是有多少个变量。水平数(Levels)：比如有三个变量，其中变量取值最多的是四个值，那么水平数就是四。强度(Strength)：即变量间的相互关系，当强度为二时，只考虑变量两两之间的影响，如果强度为三，同考虑三个变量对结果的影响;当强度增加时，用例的个数会急剧增加
在web服务测试当中，点击率和模拟的用户数是能够反映出服务压力的大小。当压力变大时，事务的响应时间变长，则导致点击率会受到响应时间的影响，不会因为用户增多，而增加。点击率在服务器出现瓶颈时，压力的增加不会增加点击率。
积累期应该是测试比较辉煌的阶段，在公司也有一定资历和地位，是幕后运筹帷幄的元帅，是能够运筹于帷幄之中，决胜于千里之外的人。这个时候应该根据实际经验，根据公司实际情况制定章程，工作标准流程，建立自己的核心团队，团队要合理配备要有学习期的也要有成长期的人。其实积累期的人也会彷徨，特别当前面所做的事都基本完成后，发现没有动力再次推动。我有一测试朋友他是这么处理，创建一个团队后就离职然后到新单位再重新来一遍周而复始。我觉得这个时期应该需要创新，包括测试本身的创新，如引入自动化测试，量化考核上，测试框架的建立等。也可以职业进行新的规划，如搞质量管理，有得做研发管理，做测试咨询等。
做测试已不知不觉有两个月了。现在我仅自我总结以下如何做好测试计划工作。
1.明确测试的目标，增强测试计划的实用性
编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确
2.坚持“5W”规则，明确内容与过程
“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。
3.采用评审和更新机制，保证测试计划满足实际需求
测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。
4.分别创建测试计划与测试详细规格、测试用例
应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。
今天主要是进行系统测试和评估测试。同时整个开发过程中我们小组也协同项目经理对各个方面进行了质量评审。从各个方面对不同的工件进行了评审，其中大部分通过了，不可避免地其中也有一些问题，但是我们采取了相应的纠正措施，保证了各个工件的质量。
学任何东西都应该认真研究，否则一知半解还不如不学；另外要注重把平时所学和实际相联系。熟练的专业技能是一个公司生存和发展的资本。现在主要的任务还是多学习，多积累。
了解了各种测试用例的方法，之后又在实际项目中设计了一些测试用例，总体感觉就是：公司里分配写作测试用例的时间并不长，而且提供的文档也不全面，所以写测试用例要符合测试部门的当前现状和项目的测试特点，综合考虑，所以看起来有点像测试计划的某些内容，但是对问题的细化程度不一样。
测试用例的设计是一项复杂的测试工作，测试用例的设计方法需要考虑测试的目标，被测试软件的特性，测试者人力资源的技术和能力，测试组织形式，测试进度、测试成本等多个方面。
确定测试用例的输入数据确实对于测试用例非常重要，它决定着测试用例的执行效果和效率，但是确定输入测试数据只是设计测试用例的一个步骤，而不是全部。因此，不能把测试用例的设计方法等同于测试用例数据的方法。
前面测试计划的学习告一段落了。从今天起我将专心软件测试用例设计的学习。
软件测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。
测试输入
提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。
操作步骤
提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。
预期结果
提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。
今天需要对文化网项目进行第一轮的测试，主要是了解该项目的流程。由于这个文化网比较简单，没有相关的需求文档。但有一个用户手册，我根据用户手册，在TestLink软件上进行测试用例的设计和记录。这一整天我浑身充满了力量，完全沉浸在测试用设计的报告中。测试中我发现以下问题;如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图。新功能测试，如果不写完整的测试用例，可能也能发现80%的问题，但一些测试点被遗漏掉的可能性很大。
我觉得测试用例还是要认真地写的，但是回归测试确实可以优化，不需要每个用例都测。
实习的第一周
按照公司安排，分配到基站那边熟悉设备和操作器件任务是认识基站设备RBS2206(室内宏蜂窝)的组成，请点各基站设备资产，登记载波的开启情况，进行备用电池的放电测试，门禁系统的开启关闭操作，空调温度的调整(一般为26度)等
由于我们队员较多，队长安排我们向另外两名早来的实习生学习我们的工作地点是海珠区的中国移动的各个基站点(主要分布在楼宇天台和地下停车场)，时间是每天早上9点钟到下午6点，中午休息一会儿工作任务较为简单，操作起来单调机械，需要乘坐面包车到处去各个点奔波抱着学习和吃苦的态度，还是认真的完成任务起先进入基站都感觉好奇，认真地向队长和队员们请教问题有的问题都觉得太简单，但书本上从未涉及过，还是坦诚地向别人请教
这一周的工作下来，学会了基站的各个部件的位置组成和实物外观，结合所学书本上的知识，加深了各器件的了解和提高了实际动手操作能力学会了与来自不同教育背景和生活地方的同事的交流与合作，深感工作上要不耻下问和同事间要合作紧密才能很好地完成工作任务
实习的第二周
依然是在基站学习工作任务与上一周的大概相同，熟悉基站设备，备用电池的放电测试，不过开始进行故障处理和部分时间进行巡检
工作地点仍然是海珠区的广东移动的基站机房与室外基站，不过检查的基站点与上一周略为不同，都第一次进入检查时间上也一样，虽然我们组要值夜班，考虑到我们实习生的身份，暂时不作安排
这一周的工作与之前的工作内容大致相同，其中故障处理较多，故障处理一般就是更换基站设备，如CDU，TRU(载波)，DXU等，更换设备有一套标准的流程，实践动手不能马虎了事还有部分巡检，需要用OMT软件连接设备，主要用来定位基站设备故障工作上依然单调枯燥，但不能放松，以免出现安全事故或工作不到位，给下一步流程的工作的同事带来重复的麻烦
实习的第三周
基站工作结束，开始做网优相关工作，网优主要包括路测，验收，楼宇普查，扫频等任务，是比基站的工作复杂一点，是处理解决信号问题的主要人员
工作地点是广州移动的业务数据中心，我所在的组是西区，位于体育中心和珠江新城一带，工作时间与之前一样第一天由负责人说明工作流程和注意事项，没有接触到实际的网优工作，都是一些送文件和设备给同事使用的跑腿工作
这一周的工作不多，负责人的一番指导和教悔也让我认识网优这一职位属于干活多薪资少的工作，需要耐心努力地学习理论和操作知识，吃苦耐劳踏实工作才能完成工作
实习的第四周
这一周才是接触到网优的实际工作，路测，路测就是道路测试信号，由于道路上都可能占用多个小区，甚至是越区覆盖，是网优中分析处理问题的一个很好的学习过程
工作地点是广州大道位于中山大道及体育东路之间的一段道路，实际上就是天河路一带，时间是凌晨2点开始，因为刚刚进行过割接小区，所以测试一下割接后小区占用情况数据显示信号强度正常，只存在局部地点出现质差，割接成功
这一周的工作是和一位路测队长学习，在测试过程中繁繁出现问题，手机电池没电，数据线连不通，电脑鼠标不动，没有带上3G卡，最后测试时间缩短减少电池使用时间，回公司更换数据线，暂时没有测试3G与2G切换情况信号测试前的设备检查是否完好，测试软件的熟悉准备都是测试前必须注意的问题