站在软件开发的角度如何做bug分类管理？ - 知乎4被浏览200分享邀请回答0添加评论分享收藏感谢收起软件开发与项目管理专业实习报告
- 大学生实习报告 】
　　小编精心推荐阅读　　 |
| 　　怎么写，欢迎阅读小编整理提供的软件开发与项目管理专业实习报告。
　　软件开发与项目管理专业实习报告(一)
　　本次项目实施中，在第二周就落实了培训需要的电脑及网络环境的建立，但在前期培训过程中讲解及练习环节都是临场才添加的需要使用到的数据，例如为护士讲解如何记账操作时发现没有在院病人;因此培训期间的有效利用率受了较大影响。主要原因在于对培训环境的理解不全面导致准备不充分，没有提前考虑周全。
　　培训环境的建立，远远不止电脑等硬件的购置及网络环境的搭建，更重要的是软环境的建立。培训过程中的讲解及操作练习都需要实际数据才能进行，因此需要提前准备好培训要使用到的数据及参数设置。
　　应对措施：凡事预则立，不预则废。培训前考虑可能使用到的数据环境，提前在培训使用的数据库中准备好数据。
　　TIP6：启用前的重要准备及测试
　　本次项目实施在启用时，由于对产品不熟悉及对需要进行的准备工作没有足够的意识，导致在启用当天门诊收费后没有发票打印出来，启用前仅在测试库中进行了测试而没有在收费室进行打印机关联及设置等，且没有进行实际打印的测试。虽然当时医院旧系统仍然在使用，没有对医院业务运营造成重大损失，但是这个错误在我心中的印象是非常深刻的。
　　系统启用是项目实施中的关键性事务，关系到项目里程碑进展及医院业务开展，其重要性不言而喻。因此在，系统启用前需要做好充分的准备工作，例如：A.流程测试，B.票据打
　　印测试，C.登陆账号、权限分配审核，D.重要基础参数设置的检查(例如药品库存检查、票据严格管理)。
　　应对措施：启用前，必须在正式库中测试门诊与住院收费单据打印、预交款单据打印，一日打印等，检查全局参数设置、收费室药房等本地参数情况。
　　TIP7：与院方的沟通方式
　　本次项目实施中，有两次与院方的沟通效果不好。一次是用于不当，与一位院长沟通的时候说了：&这个功能，那些大医院可能用的更多&&&该院长当即表态&那如果我就是要用这个功能呢?&我明显感觉到院长的防御姿态瞬间提升，沟通进入尴尬境地;第二次是我非常直接的询问院方财务管理人员(每日收费结存人员)是谁，院长没有回答。
　　对于院方内部事务，特别是涉及内容较为敏感时，可以通过其他渠道了解;对于一些可能损伤院方自尊心的事务，尽量采用委婉或者隐晦的用词进行沟通。沟通始终要注意在合适的时间找对合适的人、使用恰当的词句及方式;否则不仅达不到沟通效果，还影响与院方的关系及项目实施工作的开展。
　　应对措施：学习卡耐基《说话的艺术》，在接下来项目中注意沟通方式及时间、频率。
　　TIP8：抓住关键性事务
　　本次项目实施中，一开始我认为初始化是项目实施中最重要的工作，因此一直在进行初始化数据的准备及对初始化人员的培训;后来在启用前一开始关注医保接口实施的具体方法步骤，然后让初始化人员又对收费项目进行医保对码，引起了初始化人员的强烈不满，认为初始化工作没有一次性结束;如果将收费项目的建立与医保对码放到一起进行，可能不会引起不满，而且条件是允许的，初始化数据的录入与医保接口实施并非逻辑先后关系。医保接口实施及医保刷卡测试的速度都相当慢，在启用前一天才完成所有测试。
　　经过这个项目，我认为该项目中除药品库存、流程至关重要，最重要的是医保刷卡功能的正常使用，因为该医院患者中绝大部分为医保病人，这是医院收入的主要支撑部分，医院安装新系统的主要目的就是为了解决原系统不能正常使用医保刷卡功能这一重大问题。
　　应对措施：时刻与同事、上级保持沟通，得到经验上的指导;项目实施方案中进行体现。
　　TIP9：项目外事务与项目的协调
　　本次项目实施中两次被综合部人员协调到另外一个医院处理&光纤交换机&事宜，两次都没有完成计划的任务，并且减少了自己在建项目的实际工作日，对公司的形象也产生了不好的影响。我方主要原因是：A.未得到关于该事务的足够信息;B.未判断清楚任务是否具备完成条件。
　　经过此事，我认为在涉及影响自己在建项目进展而被协调处理其他事务前，首先需要考虑的是是否会对在建项目的进度产生不良影响，其次是该任务是否能够正常进行并达成计划的结果;否则浪费时间不说，还不能达成结果。
　　应对措施：应答前，将被协调事务了解清楚，审核是否具备任务达成的条件。
　　问题诸多，不一一列出。
　　签完验收，一直期待的兴奋感并没有像我想象的那样从头顶瞬间灌注到脚底，而是一种难过的感觉隐隐在心中升起。系统使用存在的诸多问题，以及在这个项目过程中，学习到的东西都并非我期待的那样得到实现，对自己学习摸索的方式以及效率，对项目进度的把控能力都让自己感到失望。
　　第一个项目是做完了，但是我明白不管是从熟悉产品、学习业务、技术知识、项目管理等任何一个方面，我的HIS人生都才刚刚开始。
　　软件开发与项目管理专业实习报告(二)
　　20xx年11月28日，我怀着提高并实现自我价值的心态，跨进E软件技术有限公司的大门，开始了自己第一份实习工作。这是一家国内知名的专业软件外包企业，在深圳华南地区位居行业前列。易软自开始从事软件外包业务以来，服务合作模式从外包发展到项目外包、离岸开发和OEM 产品合作等模式。业务领域包括电信业，金融业，制造业等。特别在电信行业有多年积累,在电信业务领域涉及固网,智能网、移动通信、光网络,电信增值服务等业务领域.易软公司总部设在深圳, 在上海、南京、北京，广州，重庆，苏州，武汉，大连等地建立了分公司或办事处，就近为客户提供外包服务。
　　转眼间，三个月实习时间就过去了。回想起这段时间的工作过程，我从一名普通的大学生到一个为社会服务的软件测试人员，思想觉悟有了很大的提高，作为一个刚刚步入企业的年轻人来说，什么都不懂，没有任何实践经验，不过在各位同事的帮助下，我很快的融入到了这个新环境，还学到了很多在学校学不到的东西，也认识到了自己很多的不足，感觉受益匪浅。以下是我在这几个月实习期间对工作的以及一些自己的。
　　要想成为好的测试人员，首先得了解自己要测试的软件的相关知识。要了解软件产品的架构是什么样的。要了解软件的市场需求，在接触软件之初要可以多看看用户的反馈信息，这些才是用户最关心的，也是在测试中需要注意的问题，满足客户是最大的需要。但是了解软件需求之后要学会要多读些软件系统的技术文档，软件设计文档，这些文档可以帮助了解产品如何工作。还有多看看公司 Bug 库中的问题，这些存在的问题可以帮助自己了解软件产品那些地方存在缺陷，软件系统那些地方会出现错误。软件是运行在一个大环境中，如果对系统不熟悉，那么有些问题你不能从一个更广阔的层面考虑，学习操作系统的知识，有助于你发现缺陷，定位问题更加准确。比如软件运行在 Windows 或者 Linux ，如果不懂操作系统，你就无法建立测试环境，有些时候时候软件的组件发生问题，就是自己系统配置造成的，对系统不熟悉，会把外在原因归结为软件本身。所以要学习关于和软件系统相关的知识，比如编程，网络，数据库等。不一定要学习到多好的程度，只是通过这些扩展的知识面，可以在发现问题，解决问题上不会局限在狭小的圈子里。
　　和一切相关的人员交流，不同的交流渠道，获取消息是不同的，角度也不同。和客户交流，会在测试中从客户的角度发现问题;和开发人员交流，会了解开发人员怎么实现软件功能的;和项目管理人员交流，会知道开发进度以及遇到的困难。
　　在这实习期间，我就参与了一个项目，这对我在软件测试方面有了一定的认识和需要注意的地方。
　　在滕邦国际的项目中，我主要负责的是wap网站、Symbian客户端和后台管理系统，对有关用户界面的测试和测试执行流程有了一定的了解，学会了对bug管理工具Bugzilla的使用。
　　一.有关用户界面的测试
　　1.图形测试
　　图形包括图片、动画、边框、颜色、字体、背景、按钮等。
　　(1) 要确保图形有明确的用途，应用系统的图片尺寸要合理，并且要能清楚的说明某件事情，一般都链接到某个具体的页面。如在滕邦项目中，wap网站跟客户端的标志图形就不一样，酒店模块、机票模块和模块的图片也是不同的。
　　(2)验证所有页面字体的风格是否一致。
　　(3)背景颜色与字体颜色和背景色相搭配。如本项目以该企业颜色为主。
　　2.内容测试
　　内容测试用来检验应用系统提供信息的正确性、准确性和相关性。信息的正确性是指信息是可靠的还是误传的。信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中的所谓&相关文章列表&。
　　如在滕邦项目中，在查询机票的时候出现一个不应存在奥林匹克航空，查询机票深圳-北京时，出现联合航空 UA，属于国际票务，也是不应该查询到的。
　　3.整体界面测试
　　整体界面是指整个 应用系统的页面结构设计，是给用户的一个整体感。例如:当用户浏览应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方?整个应用系统的设计风格是否一致?
　　在滕邦国际项目中，除了wap网站外，还有Symbian、Android、WinMobile三个客户端，所以在事先没有标准的情况下，各个平台的导航不统一，各关键字段也不一致。
　　二.bug管理
　　1. 在进试前，首先必须理解业务和需求。需求和业务理解了，才知道客户想要系统实现什么。然后按照需求来进行测试，不满足需求要求的都可以认为是BUG。
　　2. 和开发人员沟通。这里说的沟通并不仅仅指通过沟通试图让开发人员修改每个BUG，这个当然需要沟通，但是并不是指所有的BUG都需要修改，这中间涉及到成本、技术，还有别的问题。除此之外，通过和开发人员搞好关系，对于BUG我们可以问他发生该BUG的原因，修改的大致方法，甚至不修改的原因等等，这有助于以后测试中多注意、多发现这样的问题，甚至提出修改建议。
　　如在Symbian客户端测试中，会出现&内存不足，请关闭一些应用程序后再试&的警告，是属于正常现象。
　　3. 决定BUG严重性的时候，可以根据该被测对象在整个系统中充当的角色，实现的功能来判定如果该对象出现错误会对整个系统产生什么样的影响，对产生的影响打分，从而定义BUG的严重程度;决定BUG优先级的时候，可以先假设不修复该BUG，出现的这些问题会产生哪些影响，然后判定这些影响的严重性来判定 BUG的优先性。
　　如在项目中，旅游模块页面中，点击查询时自动退出系统，本是属于High单，而我提的是Medium单。
　　4. 容易产生BUG的情况:虽然在开发过程中，软件需求通常都会发生改动，所以如果某一部分的软件需求频繁发生变动，那么就会导致和这部分相关的编码和设计会相应的频繁变动，那么在测试中，这部分编码设计实现的部分出现BUG的可能性就很大。
　　如果在开发的过程中，大量使用了第三方的组件，或者从别的软件中移植了大量的代码，那么和这些第三方的组件和代码相关部分出现BUG的可能性就很大。
　　例如在本项目中，机票模块和酒店模块的需求经常改动，所以这两个模块也是该测试的重点;Symbian客户端有V3版本、V5版本，这两个版间的代码大致相同的，V5版本也是大量复制了V3版本的代码，所以V3版本出现异常的时候，V5版本也就会出错。
　　5. 描述BUG主题时，应当根据实际情况，简要的描述出自己的操作和希望被重视的现象，不应该包含自己对异常表现出现的原因的推测和猜想。BUG的描述要简洁易懂。
　　6. 不能假设开发人员对他们开发的程序和业务需求都十分熟悉，在提交BUG的时候，一定要说明白是哪个模块的哪个功能，出现了哪种类型的错误，并且，如果需要，应该把这部分相应的需求都描述出来。
　　实习这段期间，自己的收获是丰硕的:最起码从意识上，发现自己的不足，并寻求到合适的解决途径。非常感谢那些曾对我帮助的同事。因为你们的帮助，我顺利的走过了我人生中第一份工作的适应期。我坚信:在你们的帮助下，我会持续努力，不断反省，总结提高。
　　软件开发与项目管理专业实习报告(三)
　　从二零XX年X月九日开始到二零XX年X月二十日止， 我们哈尔滨师范大学计算机系软件 项目管理专业全体同学去北京海辉集团晟实训中心开始我们的实习生活。 实习是每一个大学毕业生必须拥有的一段经历， 它使我们在实践中了解社会、 在实践中巩固 知识。通过此次实习，我们将学校所学的会软件知识与实际相结合起来，不仅让我对整个软 件应用方面有了详细而具体的认识， 熟悉了软件的具体工作对象， 也缩短了抽象的课本知识 与实际工作的距离。 在实习中，我在公司指导老师的热心指导下，我积极参加小组讨论，和组员们配合完成了我 们小组的项目。简短的实习生活，既紧张，又新奇，收获也很多。
　　通过实习，使我对 java 有了深层次的感性和理性的认识。 &纸上得来终觉浅，绝知此事要躬行。&在短暂的实习过程中，我深深的感觉到自己所学知识 的肤浅和在实际运用中的专业知识的匮乏， 刚开始的一段时间里， 对一些工作感到无从下手， 茫然不知所措，这让我感到非常的难过。在学校总以为自己学的不错，一旦接触到实际才发 现自己知道的是多么少，这时才真正领悟到&学无止境&的含义。通过实训中心老师的课堂讲 解与企业化标准的培训，使我加深了对自己专业的认识。从而确定自己以后的努力方向。要 想在短暂的实训时间内，尽可能多的学到东西，就需要我们跟老师或同学进行很好的沟通， 加深彼此的了解。只有我们跟老师多沟通，让老师更了解我们，才能跟真切的对我们进行培 训工作。由此，班级的文化&共享&就在生活中慢慢形成了。让我们知道了团队的力量。 老师在实习周中所讲的， 都是课本上没有而对我们又非常实用的东西， 这又给我们的实训增 加了浓墨淡采的光辉。 我懂得了实际生活中， 专业知识是怎样应用与实践的。 在这些过程中， 我不仅知道了职业生涯所需具备的专业知识， 而且让我深深体会到一个团队中各成员合作的 重要性，要善于团队合作，善于利用别人的智慧，这才是大智慧。靠单一的力量是很难完成 一个大项目的，在进行团队合作的时候，还要耐心听取每个成员的意见，使我们的组合达到 更加完美。
　　这次实训带给我太多的感触，它让我知道工作上的辛苦，事业途中的艰辛。让我知道了实际 的工作并不像在学校学习那样轻松。 软件行业的工作人员工作不是一个人的事情， 而是一个 团队的事情。软件开发中有许多的问题如。 需求分析不充分.如果需求分析不清晰、不完整、太笼统或者不具有可测试性，那么软件一 定会出现问题。这就要求我们在动手开发之前一定要有完整的、详细的、可维护的、可测试 的需求分析， 而且该需求分析一定要得到各方的认可。 不切实际的计划没有充分考虑问题的 复杂性，把一个庞大的工程限定在非常短的时间之内，出现问题是不可避免的。因此，我们 应该拿出足够多的时间作计划、设计、测试、修改错误、回归测试、整理文档，不要把长时 间熬夜作为软件公司的家常便饭。 不充分的测试在系统崩溃和用户强烈抱怨之前， 没有人知 道软件是不是存在问题。因此要尽早地开展测试，问题修改之后要尽快地进行回归测试，一 定要给测试和修改问题留出足够的时间。 不断增加新的特性在软件开发完成之后， 不断有新 的需求，这是最常见的问题。因此一定要最大限度地坚持最初的需求分析，如果万不得已， 确实需要增加新的需求， 那么一定要更改相关的计划。 如果可能在设计阶段最好使用快速原 型法， 让用户知道他们希望的系统是个什么样子的， 这样可以在初期更好地听从用户的意见。 交流不充分如果开发人员与开发人员之间、 开发人员与项目管理组之间、 项目组和用户之间 不能充分地交流的话，也会出现问题。
　　因此，使用新闻组、电子邮件以及其他的网络化的错 误跟踪工具等等方式来加强整个团队的沟通和交流是必要的。 人非生而知之，虽然我现在的知识结构还很差，但是我知道要学的知识，一靠努力学习，二 靠潜心实践。没有实践，学习就是无源之水，无本之木。为了保证项目团队按时保质地完成 项目目标，便于项目团队成员更好地了解项目情况，使项目工作开展的各个过程合理有序， 因此以文件化的形式，把对于在项目生命周期内的工作任务范围、各项工作的任务分解、项 目团队组织结构、各团队成员的工作责任、团队内外沟通协作方式、开发进度、经费预算、 项目内外环境条件、 风险对策等内容做出的安排以书面的方式， 作为项目团队成员以及项目 干系人之间的共识与约定， 项目生命周期内的所有项目活动的行动基础， 项目团队开展和检 查项目工作的依据。 这次实训让我在一瞬间长大：我们不可能永远呆在象牙塔中，过着一种无忧无虑的生活，我 们总是要走上社会的，而社会，就是要靠我们这些年轻的一代来推动。这就是我们不远千里 来实训的心得和感受，而不久后的我，面临是就业压力，还是继续深造，我想我都应该好好 经营自己的时间，充实、完善自我，不要让自己的人生留下任何空白! 实训中除了学到不少专业知识，也了解一些社会的现实性，包括人际交往，沟通方式及相关 礼节方面的内容， 对于团队开发来说， 团结一致使我深有体会。 团队的合作注重沟通和信任， 不能不屑于做小事，永远都要保持亲和诚信，把专业理论运用到具体实践中，不仅加深我对 理论的掌握和运用，还让我拥有了一次又一次难忘的开发经理，这是也是实训最大的收获。
　　现在我对&一个人最大的财富是他的人生经历和关系网络&这句话非常的有感情，因为它确 实帮了我们不少。除此课本上的知识毕竟有限。通过实训，我班同学都有这样一个感觉，课 本上的理论知识与实际工作有很大差距，只有知识是远远不够的，专业技能急需提高。 从最初的笨手笨脚， 到现在可以较熟练的按照流程开发软件， 这都与我班每个人的努力是分 不开的。十几天的实训，教会了我们很多东西，同时也锻炼了大家踏实、稳重的能力，每个 人都很珍惜这来之不易的实训机会。 在实际工作中经常会和不同的人打交道， 然而他们的态度是不可恭维的， 你会感觉到他的不 耐烦以及他的高傲，所以这就需要学会沟通的方式及，学会灵活面对。通过这十天 的实训，我班同学都收获颇丰，总体来说对这次实训还是很满意的。尽管实训很累，每天早 出晚归。 但真的很感谢学校能够提供我们这样好的实训机会， 以及北京海辉集团雅思晟实训 中心给予我们的实训平台。
　　我们深刻的了解到，只有经历过，才知道其中的滋味。对于我而 言，喜欢体验生活，可以说通过这次实训，真真切切的让我了解了什么是软件开发，什么是 软件工程，让我对于软件最初的观点也有了本质性的改变!程序员不仅仅是一份职业，更是 一份细心+一份耐心+一份责任心=人生价值的诠释。即将走向工作岗位的我们更要不断加强 自己的专业技能， 社会不会要一个一无是处的人， 所以我们要更多更快的从一个学校人向社 会人转变。为此我们将会在以后的日子里继续努力，不断激励经验，不断磨砺自己，早日走 向工作岗位。 时间过的好快啊，为十二天的实训生活即将结束了，短短的十二天让我们收获很大，专业知 识、编程水平都有很大的提高。刚开始四天的高强度的课程安排让我们受益匪浅;接下来的 上机实训又让我们可以巩固了课程。 这让我觉得实习生活充实而有意义。 辅导老师配好了环 境之后，我们开始了项目的制作，这次项目实训算是自己小组间主要完成的项目。最后，自 己的努力还是有收获的， 看着电脑上记录得满满的代码， 看着自己的项目最终能够运行成功， 就觉得好神奇，很有成就感。
　　在本次的实训中，除了让我明白工作中需要能力，素质，知识之外，更重要的是学会了如何 去完成一个任务，懂得了享受工作。当遇到问题，冷静，想办法一点一点的排除障碍，到最 后获取成功，一种自信心由然而生，这就是工作的乐趣。有时候也需要虚心请教，从别人的 身上真得能学习到不自己没有的东西，每一次的挫折只能使我更接近成功。除此以外，我还 学会了如何更好地与别人沟通， 如何更好地去自己的观点， 如何说服别人认同自己的观 点。这次所学知识与实际的应用，理论与实际的相结合，让我大开眼界。也是对以前所学知 识的一个初审吧!这次实习对于我以后学习、找工作也真是受益菲浅，在短短的十多天中让 我初步从理性回到感性的重新认识， 也让我初步的认识这个社会， 对于以后做人所应把握的 方向也有所启发!相信这些宝贵的经验会成为我今后成功的重要的基石。 在这次实训中，我们以小组为单位开发项目。我们小组的项目是 Super VCD 一款简单的音 乐软件。到目前为止，已经有很多种音乐软件，大部分都是以复杂功能为主，实现复杂音乐 的管理， 但是有些用户不需要那些功能繁琐的软件， 只是需要一款能够满足用户简单的需求 的音乐软件。
　　我们所要做的是一款简单的 SuperVCD 音乐软件， 能够满足用户简单的管理音乐需求，操作 简单。主要实现一些简单音乐的管理。 根据了解，一些用户对音乐软件只有一些简单的需求，主要有几个方面，首先是对文件的管 理，第二，是对专辑的详细查询。SuperVCD 的实体有 music.db,images 文件，服务器，客户 端，用户界面。服务器和 music.db 之间为一对一的关系，服务器可从 music.db 文件获取音 乐信息。images 文件和服务器为多对一的关系，服务器可从 images 文件获取图片。服务器 和客户端是一对多的关系，一个服务器可开启多个客户端客户端和用户界面是一对一的关 系，一个客户端开启一个用户界面(不重复) 。 我们按照老师的讲解，分配了小组。
　　在小组中我们选了组长。组长按照我们各自所擅长的分 配了我们组员的任务，设置了一个虚拟货币，按照奖惩机制进行分发货币。在进行工作时我 们相互配合，帮助。终于在我们努力和老师的指导下我们完成了老师布置的项目。老师为我 们讲解了软件架构设计要达到的目标。 软件架构设计要达到如下的目标： 可行性(Feasible) 。架构具有可行性是架构设计的基石。 可靠性(Reliable) 。软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须 非常可靠。 安全行(Secure) 。软件系统所承担的交易的商业价值极高，系统的安全性非常重要。 可定制化(Customizable) 。
　　软件开发与项目管理专业实习报告(四)
　　我所实习的南京xx软件有限公司简称xx公司，公司成立于xx年，主营软件开发和信息系统集成,专门从事工程建设项目管理信息系统开发和实施,具有自主知识产权的项目管理软件产品xx项目管理系列软件(包括xx投资控制管理软件、xx进度控制计划管理软件、xx质量控制安全管理软件、xx项目管理门户、xx城建项目管理平台等),并已经在全世界第一大桥苏通长江大桥、国内最大的开发区苏州工业园区以及南水北调工程实施和应用，目前正与南京城建集团合作，开发城建项目管理平台。
　　二、实习的内容
　　今年xx月xx日开始，我正式走进xx开始了实习工作，并被调到了江苏省建筑质量检测中心，参加正在进行的一个检测项目。由于我才大三,本身对企业的经营方式等都很陌生,公司让我们的王工带我学习,以师傅带徒弟的方式，指导我的日常实习。在王工的热心指导下，我依次对此次项目的业务流程和大概框架进行了了解,并积极参与相关工作，注意把书本上学到的理论知识对照实际工作，用理论知识加深对实际工作的认识，用实践验证大学所学确实有用。以双重身份完成了学习与工作两重任务。跟公司同事一样上下班，协助同事完成部门工作;又以学生身份虚心学习，努力汲取实践知识。我心里明白我要以良好的工作态度以及较强的工作能力和勤奋好学来适应公司的工作,完成公司的任务。
　　三、实习的提高与收获
　　实习收获，主要有四个方面:
　　一是通过直接参与企业的运作过程，学到了实践知识，同时进一步加深了对理论知识的理解，使理论与实践知识都有所提高，圆满地完成了本科教学的实践任务。
　　二是提高了实际工作能力，为就业和将来的工作取得了一些宝贵的实践经验。
　　三是一些学生在实习单位受到认可并促成就业。
　　四是为毕业后的正式工作做好了准备。
　　到公司实习并没有我想象中的难以融入，通过慢慢的学习，发现在公司用的到得知识在我们的学校学习中都会遇到。至暑期结束，从不懂到渐渐的做了几个检测项目。学到不少的东西。实习生活还没结束，开学了我还是会继续留在公司我的学习和探索。
　　推荐阅读：
下页更精彩：1
大学生实习报告栏目编辑推荐
软件专业实习报告
计算机实习报告
大学生实习报告最新资讯
大学生实习报告首页头条推荐如何修改bug（二）-bug的修改流程 - _Smileヾ - 博客园
如何修改bug（二）-bug的修改流程&&&&&&&
我发现很多程序员都在改bug，总在改bug。但是很多人没有思考过什么是修改bug的正确方法，如何高效率的修改bug，如何避免改了一个bug又被测出另外一个bug（我称为连环bug）；还有就是，为什么我们的系统越做越不稳定了，bug越改越多了。
我总结了一下经验和大家分享。（本人一直在做windows平台下C++系统的工作，文章对C++更有针对性）
作为一个程序员，少不了要修改bug，甚至每天都要修改bug。也许你在维护一个老系统，也许你的专职就是修改bug或者你自己写的代码总是被测试人员测出问题，bug总是伴随在程序员的身边。
有的人对修改bug有抵触情绪，说：这么烂的系统，还不如重写了，要是我来写代码，哪里会有这些烂bug。
有的人麻木了，说：反正bug改不完，干一天算一天。
还有的人轻蔑的说：有bug，就改呗，哪有软件没bug的，立马动手改！
修改bug是一件非常能锻炼人的工作，一般不需要一个团队去修改一个具体的bug，所以修改bug更能提现一个人的综合能力。希望这个系列的文章能对那些天天和bug做伴的朋友有一些帮助。
二.bug的定义和分类
站在能改掉bug的角度上，我对bug做了如下分类：
我把bug分为三大类：
1.逻辑错误（有出现，不能重现）
只要是有出现的bug，不管是功能错误，内存错误的crash等，基本都是逻辑错误。那些不能轻易再现的错误都属于这一类。
要想正真改掉一个bug，请你重现它。不论用什么手段，重现它。否则，你不能对比验证你在之后修改的结果。不能验证修改的结果，你敢说你一定改对了吗。
这个系列的文章一个基本前提就是：bug一定能重现。
至于如何重现一个诡异的bug，我在以后其他系列的文章专门写点东西。
2.逻辑错误（有出现，能重现）
a.明确原因：
bug拿到手，就非常清晰的理解上下文逻辑，知道需要在哪里做什么样的修改；正确估计所做的修改对他相关模块、逻辑的影响（做到这点不容易）。
或者bug非常简单，比如：笔误、字符串拼写错误，界面图片对齐等。
b.不明原因：
这种bug的修改也是我在后面文章要大书特书的。
不明确bug产生的真正原因，只知道一个判断或者调用就有bug了，或者误解了bug产生的原因。看图中误改的箭头，这种情况下做的修改是工作效率低下的主要因素，连环bug也是这么诞生的。
一个不明确产生bug正真原因的修改，会造成无法预计的风险（看箭头）。
知道导致bug的表面调用，但是不理解代码上下文，对于直接修改表面调用造成的其他隐患没有正确估计的bug，也属于不明原因的bug。
一个只对bug表面调用逻辑做修改，不思考所有相关逻辑的行为，是要付出沉重代价的。
修改bug是非常简单的，但是明确一个bug的原因有时是很难的。
c.内存错误导致的逻辑错误：
内存错误是C++老生常谈的问题了：泄露，越界等。
由于A处的内存错误导致，即使本来正确的B处逻辑，也会出现异常状态。（有些新手可能不太理解这句话，有什么问题就问吧）
特别是那些检测不出来的内存错误：B处逻辑被你改穿了，A处还是有越界，等B处逻辑被你保护死了，又发现C处逻辑又坏了，多么可怕啊。严重影响工作效率。
内存错误的难点在于，如何认识到你手头的这个逻辑错误是由一个毫不相关的内存错误导致的。
内存错误最怕的是误改。
后面的文章我会谈到怎么修改内存错误。
3.泄漏和越界,资源释放问题
a.能检测出内存错误：
有些泄露用IDE能检测出来，还可以借助boundschecker等工具。这些问题，在调试过程中就能体现。
b.不能检测出内存错误：
C++的数组越界。除非你用STL或者Boost库的数组来写代码。
C风格的数组的性格，我们改变不了。
一句话，C++是给明白人用的。
不明白的人拿起你的vc，建一个Dialog工程，定义一个成员int m_test[16];在构造函数写m_test[16] = 1；跑跑看吧。
三.修改bug的前提
再次强调，一定要重现bug，无论是谁反馈的，你要能亲眼见到bug。
有些特例：比如，前方做实施半夜1点电话你，说：重大事故啦，快改下什么什么的类型，不然人家数据要全没啦，你快改！！有经验的人，第一时间会利用vpn或者其他方式连到现场，亲眼看看。实在看不到现场的，除非你非常明确前方人员表达的意思；除非你对代码熟悉的能背诵了，早就预料到会有这一天，那你敢改就改吧。
-------------------------------------------------------（未完待续，下篇：bug的修改流程）
上篇中我对bug做了3大分类：能重现的逻辑错误，不能重现的逻辑错误和潜在的内存错误。
这篇文章是我总结关于逻辑错误的修改流程，也算是后面文章的一个总领。
流程如图：
再次强调这个是修改bug的前提。
2 明确事发点
就是明确导致一个bug产生最直接的一个调用或者一个判断。 明确了事发点后有两种情况，就是上图中的分支。 有些bug，在明确了事发点后就立刻知道原因了，这个大家都有体会；有些就不是这么简单了。 定位事发点的方法下篇文章有详细介绍。
3 整理代码
有些事发点逻辑错综复杂，一点注释也没有，也没有文档，或者代码风格很差。整理下代码，能减缩进就减点，太长的函数分割一下。。。就是为了提高阅读性。
因人而异，如果你觉得你的阅读能力超强，不整理也无所谓。 但是千万不要自作聪明的就开始做点&保护&,这个步骤不要让逻辑受一点影响。
4 分析原因
具体情况具体分析。这个步骤有时候是最难的，但是一定要明确原因。不明原因或者误解原因bug的修改后果是有极大风险的。 可参考《如何修改bug（一）-bug的分类和定义》。
5 确定方案
可行性、所做修改对其他模块和逻辑的影响需要周密思考、测试和验证。有些方案看上去很好，正真做进去了才发现时间白花了。在解决一些关于性能方面问题的时候往往会发生拿错方案的惨案。 有时候方案很多，都可行，难以抉择，那就具体情况具体分析了。
6 修改代码
这一步，是所有步骤中最简单的，就是码字。
程序员保证自己工作效率和质量的关键步骤。你不想总被别人测出问题吧，或者你也不想问题最多的模块总是你在改的吧。
bug千奇百怪，不是每个bug都需要经历所有流程的。每个步骤都有它的难点。 有些bug难在事发点的定位，比如多线程，异步逻辑中的bug； 有些bug难在原因很难分析，多数是你看不懂代码； 有些bug难在你不敢改，那是你的修改方案没有做好充分的分析。 。。。 其实会者不难，后面我会细细道来，和大家一起分享。
阅读(...) 评论()}