软件测试实习报告

软件工程实习报告 报告题目：软件测试

姓名： 学号： 分院：理工分院 专业班级：软件工程0801 指导老师：***

2011年7月

摘要 本次的实习内容主要包括：对苏宁公司软件部门产品有一个初步的认识及确定其应该包括哪些模块实现什么功能；对软件测试的基础知识的理论学习；理论联系实际对测试进行具体操作；学会用测试工具进行工作，软件初步测试。 目 录

暑假专业实习报告 ............................................................................................... 1 1实习过程介绍 .................................................................................................... 1 1.1 实习第一阶段 ............................................ 1 1.2 实习第二阶段 ............................................ 1 1.3 实习第三阶段 ............................................ 1 2实习中所发现的问题 ........................................................................................ 2 3 问题的分析与讨论 ........................................................................................... 3 4 实习的收获与体会 ........................................................................................... 5 5 致 谢 ................................................................................................................. 5 实习日志 ................................................... 6 实习报告 ................................................... 7 实习鉴定表 ................................................. 8 参考文献 ............................................................................................................... 9 1

暑假专业实习报告

1实习过程介绍

1.1 实习第一阶段 7月8日到7月15日，我主要用来学会使用公司软件部门所开发的应用软件和各种产品设备，熟悉和了解一贯的操作方法和可能出现的问题，并就如何解决问题向老员工请教方法。教我的是一位年纪大一、二岁的同事，先与我说了一下要点，然就让我自已看，遇到不懂的就问。初次接触单，发现它并不像课本那样的有条有序，许信息夹杂在一起，令人眼花缭乱，而且以有不同的种类，要做到随便一看就知是什么单不下点功夫是不行的。我知眼高手低是一个通病，于是接来的几天我就踏踏实实的坐在哪里认真的看产品介绍和说明书，熟它的大致结构。 1.2 实习第二阶段

7月15日到7月25日，熟悉了相关软件和硬件的操作和基本故障诊断之后，我也成为工作之中的一员，开始尝试解决客户应用产品中出现的一些问题。在这一段时间里，主要任务有巩固之前所学的，对常见的错误要一看即知，并养成认真仔细的工作作风。在工作的过程中我也遇到了一些棘手的我无法解决的问题，比如一个对于软件数据库的操作问题，一个客户在使用产品的过程中发放补贴有误而按我们的系统和软件的操作步骤似乎又没有问题，于是就要查看客户的数据库资料，所以我就叫客户将一卡通软件的数据库备份发过来，但是刚开始对于本公司测试数据库的数据结构和数据表又不甚了解所以对于这个问题我就暂时无法解决了，最后在公司老员工的帮助下我准确的找到了相关数据表并进行了相关查询，终于查出了问题所在。经过这个故事之后我也感觉到光靠培训听讲是不那么管用的有时候也要自己试着去解决问题去亲自动手测试一些东西在实际的应用过程中去发现问题和解决问题，做任何事都是一样要实事求是，实事求真。 1.3 实习第三阶段

7月25日到8月25日，现在我通过了前一阶段的学习和了解，可以说对整个一卡通系统的工作原理和各种数据流程形成了自己的观点和见解，同时也对这个市场的需求和一些潜在的可能的变 2

化有了一个大致看法。结合以上的培训和了解我现在的任务就是熟悉各种软件的操作和数据结构然后在此基础上尽一切可能的去模拟去思考现实使用环境中的应用可能性和预测可能出现的状况然后对比一出现故障的概率等等，在这样的一个环节之后我要做的更细致的活儿就是做好各种测试计划和测试报告，然后对这些报告做一个准确和客观的评估然后将我所获得的结果反馈给软件或者硬件开发人员。我学习方式是坐在我们项目经理的身边看他做各种更改和测试，他一边做一边教，把要测试的要点给了我，让我思考模拟的方法。我遇到不懂的地方就向他请教，直至有了自己的周密方案之后形成纸质文件之后，才算是合格。有了第一次的错误之后，我就变得更加的小心，所以在其后的工作中我都有保持谦虚的心态。在种状态下我进步很快，花了比别少了将近一半的时就达到目标了。 2实习中所发现的问题

1、缺乏工作经验 因为自己缺乏经验，很多问题而不能分清主次，还有些培训或是学习不能找到重点，随着实习工作的进行，我想我会逐渐积累经验的。 2、工作态度仍不够积极 在工作中仅仅能够完成布置的工作，在没有工作任务时虽能主动要求布置工作，但若没有工作做时可能就会松懈，不能做到主动学习，这主要还是因为懒惰在作怪，在今后我要努力克服惰性，没有工作任务时主动要求布置工作，没有布置工作时作到自主学习。 3、工作时仍需追求完美 在工作中，不允许丝毫的马虎，严谨认真是时刻要牢记的。 4、学术上不够钻研 这是由工作性质决定的，也是我自己选择的，因为在我看来，只有被市场认可的技术才有价值，同时我也认为自己更适合做与人沟通的工作。但我毕竟是硕士研究生，需要作一些技术的研究工作，这就需要我个人多关注科研的最新进展，同时，这也对我的工作有促进作用。李广成总裁，也是我的导师，在百忙之中都会抽出时间作研究工作并指导我的学习，我的时间比他充裕的多，也应该可以多关注科研技术的进展。 3

3 问题的分析与讨论 1、关于概率性问题 软件测试中常见的一个问题就是概率性问题，概率性问题无论对软件测试人员还是对开发人员而言都是比较头疼的一个问题。这种概率性问题在测试中该如何处理呢？ 首先，概率性问题也是问题，这种我们千万不能一笑而过，在这种情况下测试人员要将这些问题记录下来，多做测试，看能否找出问题产生的规律。 其次，我们要对所出现的问题进行评估，看这种问题的严重性，如果是比较轻微的问题，对用户使用没什么影响，也不会影响到软件其他方面正常工作，那在这种情况下如果开发人员很随手就可修改的话，那就进行修改；如果修该起来耗时耗力的话，则可征得有关人员同意后进行keep. 再者，对于比较严重的概率性问题，如死机、系统崩溃等情况，在记录下问题的同时要及时通知相关开发人员，测试人员和开发人员商量解决如何再现并最终解决问题。对于这样的问题一定不能放过，记得以前在给佳能做传真机测试的时候，遇到一个出现系统自动重起的问题，结果为了抓这个问题，几个测试人员专门盯着这个问题反复的测试，为了这个问题整整测了一个星期，好在问题最后得一解决。 第四，有些问题用语言文字描述可能很难描述清楚，对于这样的问题，测试人员再进行描述的时候，有条件的话可以抓图和提供测试log.当然，如果有再现的话，最好通知开发人员，让开发人员确认问题的现象，毕竟百闻不如一见！ 第五，概率性问题产生的原因可能是累积性问题，是一系列复杂操作引起的，而有些可能是时间点的问题，只有在某个瞬间进行操作才能出现，过了那个时间点进行操作时就不会出现问题，这样的问题测试人员在测试时和记录时都要注意采取合适的测试策略。 第六，有些概率性可能和测试人员的操作习惯有关，一个测试人员测试出的问题有时候即使描述的很详细，让另一个测试人员来测，可能都很难发现问题，所以概率性的问题在解决之后最好由相关测试人员进行验证。 第七，对于在一些难以重现的比较严重的概率性问题，有关测试人员还可以大范围的搜集相关信息，如可以群发消息询问其他测试人员或者产品试用人员，看他们在测试过程中有没有出现有关现象，搜集的信息越多越容易分析出问题的规律、原因，这样也便于开发人员解决问题。 4

第八，对于一些让开发人员也束手无策的难以再现的问题，这种情况下可以使用带trace的版本进行测试，再现时直接分析相应的log记录。当然这些都属于开发人员解决问题方式方法范畴，相信他们都有自己独到之处，在此就不班门弄斧了。 2、不确定的问题 实际测试中会遇到这样一种情况，有些现象（在确定是问题之前最好用现象来描述）出现了，测试人员很却难确定这种现象是正常的还是一个bug，造成这种情况出现的原因测试人员对软件需求、规格要求等不是很清楚，当然很多情况下根本就没有相应的明确规格定义，尤其是一些比较复杂的大型项目时，其规格、需求往往很难做到那么完善，有很多都是在开发过程中遇到时再进行定义。 针对这种问题，测试人员可以先不要进行匆忙提交，冲动是魔鬼，冲动是会受到惩罚的！建议采用以下方式处理： 首先，查看确认软件规格说明和需求文档，当然也可以采用更快捷的方式——直接让相关开发人员确认。这种情况的好处在于快捷，而且可以避免出现需求规格有变更后，而测试人员未有及时得知从而导致判断失误的情况出现。测试人员辛辛苦苦提出的一个“bug”结果被驳回说那不是bug，需求就是那样定义的情况真的就不太好了。 实际工作中出现不是bug的bug时，有些开发人员会相当反感的，所以还是要三思而行。 其次，偶尔有确定不了的问题请相关设计人员确认还可以，如果次数多了，那就不太好了吧，而且有时候就根本不方便向有关设计人员确认，所以当遇到有些确认不了的问题的时候，如果规格也没有明确定义，则可以选择市场上比较成熟的大品牌同类产品进行对比测试，这也是在测试过程中常使用的一种方法。一般在开发一款产品的时候，公司都会购置几款同类产品做参考。 再者，如果出现测试人员确认不了的问题，也可让测试组内部其他人员进行测试确认，俗话说：三个臭皮匠，整死诸葛亮。多一个人确认其结果毕竟更为可靠些。 最后，当一个难以确定的现象被证实是一个bug时，再进行提交，不是一个bug更好，皆大欢喜！