范文 > 心得体会 > 软件测试心得体会 > 导航 > 软件测试心得体会(5篇)

软件测试心得体会

软件测试心得体会(5篇)。

面很很多的事情或者文学作品,我们都会油然而生一些体会。有时我们需要将自己对观看或阅读过的内容以文字的方式记录下来。在日常生活中,大家总免不了要接触或使用心得体会吧,写心得体会时需要将所思所得条清缕晰地记录下来,如何去写好一份优秀的心得体会呢?小编特地为大家精心收集和整理了“软件测试心得体会(5篇)”,欢迎你收藏本站,并关注网站更新!

篇一:软件测试课收获和体会

软件测试课学习心得

1204013031 许院生 12计本3班

这个学期我学习了软件测试这门专业课程,在学期即将结束的时候,我也对这门课程建立基本的了解和理解。软件测试这门课程作为软件工程专业中一门很重要的课程,已经在软件领域占据了不可替代的角色,当一个软件从雏形到真正的在一台计算机上运行的时候,谁也不能保证计算机软件能一步到位的满足人们的需求。所以就有了软件测试,其目的是:第一是确认软件的质量,其一方面是确认软件做了你所期望的事情,另一方面是确认软件以正确的方式来做了这个事件。下面我简单的写一下这个学期对课程的总结和收获。

我认为,在整个庞大的软件工程中,不管是需求分析、架构设计甚至是最后的debug,都会产生引入不管的机会,这就要求作为一个软件测试师要掌握丰富的软件工程原理和知识。测试的工作将会存在于整个项目周期,即在项目开始时需要各种分析调研时就开始了。尤其是在形成需求规格说明书时就有对文档的测试需求,甚至主导整个项目的走向。

软件测试对逻辑思维、学习能力、反应要求很高,是否有严密的思维和逆向思维也非常重要。做测试还要考虑到所有出错的可能性,有时候还要用一些非常规的的测试方法。软件测试还很注重软件性能问题,也就是要保证软件运行得很好;不同的使用环境下,考虑软件的兼容性同样重要。对于测试员来讲,会比开发人员更加重视软件产品的质量问题。在测试过程中,测试者可能会为客户的需求角度考虑

到更多,由此我们可以认为测试人员有权利决定产品是否可以发布。然而,通过一个学期的学期,我们又不得不懂得,软件测试人员不是万能的,测试人员在面对一个设计烂编码烂的软件时,也是无法不低头的,再怎么测试它也变不成优秀的软件。

通过课上的理论因为课下的实践和后半学期又因为身体力行于QQ群论坛里使我对测试方法和设计分析有了大致的接触和深入了解。收印象深刻的有一下几点。

1、最基本的测试的分类:从是否需要执行被测软件的角度,可分为静态测试和动态测试;从测试是否针对系统的内部结构和具体实现算法的角度来看,可分为白盒测试和黑盒测试。

2、然后就是,白盒测试中的逻辑驱动测试的覆盖率测试。

3、还有就是对于划分等价类和边界值法这一块,让我从模糊到明朗。

4、在初次写测试用例的时候,感觉真是纠结,用例写的很死板,看似简单的一个填表工作,要写好真是不简单。一开始写的比较不自然,有些生搬硬套,而且还很慢。在后来负责了对论坛新鲜事版块的测试之后,明白了测试用例其实就是指导怎么去执行测试,而且书写设计测试用例也要以熟悉软件的业务为前提,才能更好的去测试。

另外就是一个学期的学习让我纠正了几点误区:

1. 有位大师曾说过:“软件测试的目的在于发现错误,一个好的测试用例在于发现从来未发现的错误,一个成功的测试是发现了从未发现的错误的测试。” 由此我自认为测试就是为了找到bug,然而一个学期的测试学习经验告诉我这是错误的,如果只是为了找到BUG,那么BUG会成天缠着你。

2.在大家协力测试论坛的时期内,我曾认为这种大量的重复性的工作真的很乏味,可是在这乏味中真心发生挺多有意思的bug,意想不到的bug,所以我认为只要掌握了方法,在重复中寻到到创新的小惊喜,任何东西都有它的特点。

作为测试新手,通过一学期的学习,我认为能独立写测试计划,设计测试用例,精通一种测试工具,理解一种bug管理软件是新手晋级老手的必备素质。任重而道远?!

在最后,我不得不提的就是细心和耐心了。这是我认为这个学期测试课上收获最大的了,课程要求测试时必须细心和耐心,我在想,如果以后真的工作在测试一系列的岗位上,要学会坐得住,用大量的时间和精力和bug斗争,分离、识别还有归类bug,是不是也能真的改变我粗心大意和三分钟热度的毛病。

最后感谢刘老师这学期的课程讲授,和实践中的指导和帮助。测试路程,路漫漫其修远兮,吾将上下而求索。

篇二:软件测试心得

软件测试心得体会

软件测试工作是一个系统而复杂的工程,软件测试的目的就是确保软件的质量、确认软件以正确的方式做了你所期望的事情,所以工作的主要任务是发现软件的错误、有效定义和实现软件成分由底层到高层的组装过程、验证软件是否满足规格书要求和系统定义文档所规定的技术要求、为软件质量模型的建立提供依据。

而且软件的测试不仅是要确保软件的质量,还要给开发人员提供信息,以方便其为风险评估做相应的准备,以及为其提供分析依据,重要的是要贯穿在整个软件开发的过程中,保证整个软件开发的过程是高质量的。

软件测试对测试工程师来讲,要求具备较强的专业知识,严谨细心耐心的测试态度,良好的反向思维、发散思维能力、沟通能力等等。

以下是就自己的个人工作经历谈一些浅见:

1. 标准文档的制定:

1.1.任何一个公司要让自己的产品面市,都要有自己的一

套完整的品质标准,这个标准一定是在符合国标及客户

标准的基础上形成的企业标准,系统而全面地描述一款

产品的功能、性能、可靠性、健壮性、安规要求等一系

列的产品标准,并根据客户特定要求相应调整。

1.2.测试仪器的作业指导书(SOp)及保养说明等。定义仪器

的使用步骤、操作指南和保养细则等。

2. 测试资料的归档:

标准媒体文件、测试报告、BUG LIST库(电子类问题、结构

类问题、软件类问题:方案自存问题、品证测试问题、生产

测试问题、客户反馈问题、终端消费者反馈问题等)、认证测

试文档归纳总结(认证公司培训资料、认证过程中出现并改善

的问题)、测试工程师经验分享、常见问题解答FAQ等。

3. 功能测试:

3.1.这是软件测试工作中最核心和最基本的一项测试,该测

试的主要内容是检查软件是否符合需求定义,并通过构

造正常的操作来检查的动作是否正确;在这个测试里,

正确性是最最重要的软件质量要素。

3.2.功能测试按照可见性可以分为两类:显性功能和隐性功

能。

显性功能:指在菜单里可以看得到的功能。

隐性功能:指在菜单里看不到的功能。

例如,电话本的显性功能有增加、编辑、删除、拨打等,

这些功能可以在电话本的菜单里面看得到,姓名列表排

序则属于一个隐性功能,因为在电话本的菜单里没有这

样一个子菜单,但它却是一个实实在在的功能。

如以下这些隐性功能都测试中都需重点关注:

a. 电话本上下页切换,是否有遗漏联系人信息?

b. 是否支持手机内存、SIM卡电话本的同时下载?还是

支持从一种介质里下载?

c. 断电后再上电,系统设置的时间是否有记忆功能?

d. GpS信号正常时,导航地图中时间是否有更新?

e. TFT屏在power off→on, ACC off→on时,屏的角度

是否有记忆?

f. 模拟导航时,是否有双工功能?后台源声音输出是否

正常?

g. 路试语音产品外置麦克风使用效果时,考虑车速、风

声、车内讲话噪声、汽车底盘/发动机噪声等对麦克

风录音效果的影响,软件多线程开启时导致的资源占

用/系统繁忙对后台录音系统的影响。(也可从结构方

面考虑:外置麦克风型腔开孔的接触面积,是否360

度可旋转等来增加录音的路径等。)

h. 地图上的pOI信息通过后台语音搜索获取不到,解决

措施:要求方案商讯飞完善后台语音库。

3.3.在实际的测试过程中,显性功能通过菜单遍历可以很容

易地进行无遗漏的测试,但是隐性功能却很容易为我们

所忽略!一个有效的解决办法是去检查软件的功能定义

列表(Feature List),从这个列表里面找出那些隐性的

功能。

3.4.制定测试用例时,要充分考虑各功能模块软件的显性功

能和隐性功能。

4. 健壮性测试:

橘生淮南则为橘,生于淮北则为枳。是说明橘的健壮性太差。

该成语充分说明了我们对产品进行健壮性测试的必要性。

4.1.健壮性是指在异常情况下,软件还能正常运行的能力。

健壮性有两层含义:一是容错能力,二是恢复能力。

健壮性测试主要包括:电子硬件健壮性(如:遥控距离测

试、高低电压适应性测试、插拔电及开关机测试、静电

抗扰度测试、热插拔测试)和机械健壮性(如:整机结构

设计基准测试、模拟运输测试、常温包装跌落测试)。

4.2.这项测试主要是检查软件对异常操作的容错能力,异常

操作通常要考虑异常输入操作及异常条件两个方面。 例如:测试蓝光媒体播放器时,反复把HDMI连接线拔掉,造成通信异常中断,再接上复合视频(CVBS)信号输出,即由数字信号输出转为模拟信号输出。恢复测试重点考察一下几项:(1)系统能否重新运行;(2)有无重要的数据丢失;(3)是否毁坏了其它相关的软件或硬件;(4)若软件出现系统报错,是否有自恢复能力。

4.3.软件的很多功能的实现是有很多隐含的条件的,在健壮

性测试中,要检查当这些条件不满足的时候的反应。 例如:目前大多数3G智能手机,与各电信运营商形成利益捆绑,每款手机支持特定的电信运营商提供的通信服务,其它运营商提供的服务则被拒之门外。当使用移动SIM卡安装在只支持联通通信服务的3G手机上,关注该手机表现:是否在执行自动更新时重启?还是执行自动更新后提示不支持移动运营通信服务:SIM card not supported, emergency calls only?

例如:在做完常温包装跌落测试后,再测试机芯的读碟能力,读取偏芯碟、面振碟、偏重心碟、刮痕碟、指纹碟等等碟片,与未做跌落测试前读碟能力进行比较。如果读碟能力比以前更差,则考虑改进措施:软件适当增加录轨时间或机芯托盘加固等。


f132.COM更多心得体会延伸阅读

软件测试心得体会


下面简单谈谈我的几点体会:

体会一:软件测试在整个软件周期中的重要性。

它存在于整个项目周期,在项目开始之初需求调研的时候就开始了,在形成需求规格说明书的时候就需要针对文档进行测试。这个环节在后续整个项目中占了很大的比重,能主导整个项目的走向,成败与否全在于开始阶段的决策。

体会二:软件测试的真正意义在于发现错误,而不在于验证软件是正确的。

再严密的测试也不能完全发现软件当中所有的错误,但是测试还是能发现大部分的错误,能确保软件基本是可用的,所以在后续使用的过程中还需要加强快速响应的环节。结合软件测试的理论,故障暴露在最终客户端之前及时主动的去发现并解决。这一点就需要加强研发队伍的建设。

体会三:在系统性能测试方面需要重视。

经过这次培训中多个案例的讲解,让我了解到系统在上线之后会有很多不能预知的性能问题,需要在上线之前实现进行模拟,以规避风险,包括大数据量访问,高并发数等等。

当然也有很多应对手段,没有哪种手段可称为最完美,只有最合适的,需要灵活掌握,综合运用以达到最优程度,这是个很值得研究的领域。

下面是本人的几点想法:

想法一:加强系统上线前的性能测试。

目前我们在项目建设过程中对性能压力测试的重视程度还不太高,厂家也很少有雇佣第三方的测试机构。而是在现网进行试用,遇到问题再解决,可能会产生滞后问题,影响客户使用。希望以后能在性能测试方面提高重视程度,加大人力投入,以保证系统上线后能够稳定运行。

想法二:适当介入相关项目研发

对于快速响应这块,我们不能一味依赖厂家,而希望自己就能快速响应,及时将问题解决。这也是一个比较长远的问题,需要加强研发力量的投入。

我个人是做开发出身,有此类经验,当时是在客户现场,因为了解系统内部结构,能够在第一时间排查解决客户所反馈问题。

现在系统完全由厂家开发,很难了解内部结构,或许会造成后期维护困难。所以,是否应该针对某些项目介入厂家研发工作,比如请厂家提供源代码等相关要素,以增进维护人员对系统的了解。

最后再次感谢公司提供的平台,感谢领导的信任,让我有机会得到更深层次的学习以及展示自己能力的机会,我也会尽我所能来完善工作的系统,提高整体工作效率,为南方电网的发展建设提供更坚实,优秀的支撑服务平台。

软件心得体会4篇


软件工程实习心得体会一

时间过的很快,转眼间已经实习将近5个月,其中有2个月是属于完全被流放的。

最先在内部系统组参与内部管理系统开发(struts mysql spring hibernate),之后是去做网络交换机软件的脚本测试。现在又回归内部系统,虽然在脚本组期间,编码能力被别人甩在后头,但至少具有了一些测试经验。

至少自己做的东西,是真正交付到了客户手上,到也稍微有些成就感。

1、浅谈测试

一直以来,我都认为测试是脱离了软件工程范围的工作,不以为屑。但在实际情况中,测试是既重要且难以精湛的.其真正的压力,在于找不到bug,责任在你,而不在于编码人员。一般的测试人员不懂编码,他们靠的是日以累计的经验总结和想象力。而要做到高级测试工程师,则一定要懂编码,因为这是你完全掌握整个系统的方方面面具体运作的前提。但占主导地位的,还是大型系统的集成测试经验。实际项目中,编码时间一般只占30%左右,真正耗费时间的是it阶段的找 bug与对应bug,此阶段基本评定了coder的编码质量。

2、程序员的困惑

有些人,以为教学视频和代码看多,自己就懂的多,实际做起来,却不知从何下手,问题在那?如何定位?如何解决?通通跟一样能力有关,debug追踪能力,也称调试。在项目组工作不愁源码资源,但问题是蛋糕摆在面前,你如何去消化?

有位同事告诉我:代码看几遍都没用,要去抄,例如一个查询模块,在此基础上去做具体记录的历史记录查询模块,你可能会觉得很简单,但实际情况却往往报一堆异常,配置问题涉及到方方面面,以及数据库段,传值问题等等,一大堆对于新人来说很郁闷的问题。但不用怕,只要学会调试,一个个问题去追踪,一个个去解决,自然而然,那段“源码”才真正属于你。

3、如何调试追踪

如果你能在短短的时间内就看到问题点在那,放下断点去追踪,出去找工作,绝对没问题。出现问题的时候,不要光看代码,要用实际行动去追踪运行期间的具体值,那是最好途径。eclipse是个很爽的ide,这点做的很好。例如页面内容显示不是自己想要的数据,我们要先从数据库查询语句去下手,设置断点,一步一步step over,让sql段(存取最终sql语句的符串)运行到有值,inspect进去看,如果还看不出来,就点击它,copy后在sql客户端去实际运行,看看实际查询出来的表是什么,如果是对的,有可能就是页面调用的错误或者action逻辑的传值问题。

页面错误的调试,基本方法是用右键点击实际网页查看源代码,copy到editplus,就能看到具体错误发生在那几行。通常有几种常见的错误,例如:缺少对象这种很多时候是有些被你调用的段有可能为空的情况出现的,可以加if(xxx=null)语句加保护。追踪的方法基本就是用alert语句,放在有可能出错的地方。

4、一些习惯

遇到问题先自己思考,无从下手再找高手帮忙看看,注意他帮你看的思路,别在一旁闲着,看多了自己也会了,不然你一辈子都停留在那种水平,从人身上学到的东西远远比书多的多。

解决了一个问题后,要去究根问底去找到问题产生的起因,以防你下次遇到类似的问题再浪费同样的时间。

把代码写的漂亮,注释、空行、规范一样不能少,可读性是放在第一位。曾经看过一个高手写的代码,真的一看就是不同水平的人写的,几乎很完美,读起来很流畅,方便自己也方便别人。

任务完后不要呆着,去要求经理给你更有挑战性的任务,只要你肯去尝试,他们就会对你另言相看,把三天的任务一天加班搞定,效率和忠诚都有了,路也比较好走了。

软件工程实习心得体会二

在这次软件工程课程中,我学到了很多东西,第一次深刻的体会到了什么叫做用工程化的思想来编写软件,以前自己也写过一些小型软件,没有做过大型的项目,直到这次课堂我担任组长并组织组员共同完成“个人图书管理系统”这个项目,第一次和别人合作,才发现运用工程化的思想来做是如此的有必要。

从这里,我才真正的意识到实施一个软件工程并不是说简单的会编码就能够解决问题的,我们更多的精力不是放在编码上,编码只是一个很小的模块,只占到那么小的一个部分。这个事实在很大程度上颠覆了我以前的思想,在我以前的认识中,似乎整个软件就是编码,除此无它,还好有老师的指导,不然真的会出现老师所说的,撞得头破血流之后才想起来用软件工程的思想来完成这个工作。

刚真正开始工作之前,我们费了很多的时间来完成一些前端工作,如需求分析和可行性分析,这块工作在别人看来可能是相对无关紧要,甚至是多于的,其实,换做在以前,我也会这么认为。可是,我现在算是深深地明白了磨刀不误砍柴工的道理,这些工作的完成太有必要了,太重要了,要想你的软件有用有市场,能被别人接受和认可,在进行过程中不会出现崩溃性的问题,这些工作缺一不可。

还有就是接下来的一些设计模块,此模块与软件编码涉及比较紧密,主要是解决一些参数传递和接口通讯的问题,此模块对我的触动远没有上两个模块对我的影响大,因此再次也不做过多的介绍。

在整个活动的完成过程中,作为组长,我收获很多,我发现,要是组里有个人不怎么想做事情时,他对于整个组织的影响是毁灭性的,正所谓“一颗老鼠屎,能坏一仓谷”,以后我的组织里要是出现这样的人,我绝不会给他继续留下来的机会,我会在第一时间将他清除出去。还有就是,作为组长,你要做的最重要的事情,不是发挥自己的聪明才智,而是创造出一个平台,让别人去发挥,你所要做得,出了保证这个平台的完整性和公平性外,还有就是协调好各组员之间的关系。

这就是我的实习感想。

软件开发心得体会软件心得体会2篇

受某文化公司委托,开发一款用于视频和图像处理的软件,开发难度高,高到从未搞过,开发周期长,长到是我以前项目监控最长开发周期的两倍,开发成本之底,让我觉得程序员成了高级打员。首先是需求分析书、产品规格说明书、设计说明书、代码规范说明书、测试计划,光文稿就不知道熬了多久才做完。

紧接着,遇到一系列问题,首先是语言选择,vc 和c#都是可以保证开发完成的选择,但是vc 内存容易报错,界面很难修改,而客户要求的界面质量甚至比程序的功能更严格,没办法,客户就是上帝,上帝做事一定有他的道理。c#语言易于开发,而且图形界面绘制也易于修改,可以做出客户体验很好的界面,但是在资源的消耗上,让我很吃惊。做到第二个月,大概的界面已经完成时,出现界面刷新的问题,刷新时开始卡,界面不流畅。没办法,改。

开会,总结,技术骨干找问题,拿出解决方案,力争第一次做软件把它做好:

重新做软件开发进度计划和软件测试计划,并且让独立功能demo制作和测试先行;

用direct dra 软件开发平台有了更深一步的了解,对微软基础类库的认识与使用也有了大大的提高。以及如何使用sql server数据库进行连接操作方面有了本质的提高。

短短的实训结束了,为我将来的就业打下了良好的基础,也提高了我的软件开发的水平,今后我将会更加努力的学习,不断提高自身素质,开拓创新,与时俱进,做一个优秀的软件开发工程师。



软件心得体会(4篇)


受某文化公司委托,开发一款用于视频和图像处理的软件,开发难度高,高到从未搞过,开发周期长,长到是我以前项目监控最长开发周期的两倍,开发成本之底,让我觉得程序员成了高级打员。首先是需求分析书、产品规格说明书、设计说明书、代码规范说明书、测试计划,光文稿就不知道熬了多久才做完。

紧接着,遇到一系列问题,首先是语言选择,vc++和c#都是可以保证开发完成的选择,但是vc++内存容易报错,界面很难修改,而客户要求的界面质量甚至比程序的功能更严格,没办法,客户就是上帝,上帝做事一定有他的道理。c#语言易于开发,而且图形界面绘制也易于修改,可以做出客户体验很好的界面,但是在资源的消耗上,让我很吃惊。做到第二个月,大概的界面已经完成时,出现界面刷新的问题,刷新时开始卡,界面不流畅。没办法,改。

开会,总结,技术骨干找问题,拿出解决方案,力争第一次做软件把它做好:

重新做软件开发进度计划和软件测试计划,并且让独立功能demo制作和测试先行;

用direct draw、direct 3d或者opengl中的一个替代c#本身的gdi绘图,将在接下来的开发任务中加入进去。

事无巨细,当我满意的看着界面流畅,功能也已实现时,发现软件在低分辨率或者小本上根本乱到没法看,甚至是界面功能按钮错位,重叠等等。没办法,改。毕竟软件的多分辨率兼容和操作系统兼容是必须要做的。

接下来一大堆的麻烦找了上来,软件出现各种各样想都想不到的问题,总算是按时将第一个版本发布出去,并且开始接下来的升级开发任务。

最后,给刚刚接手软件开发项目的朋友一些忠告:

一、相关的文档不是给别人看的,而是给自己看的,相关文档一定要齐备,而且让所有涉及开发的人员都清楚的知道你文档里所要表达的意思;

二、一定要注意多做demo,多做实验,一个demo程序员几个钟头就可以完成,甚至更少,但是不做demo,核心程序没有做实验,其他的东西都围绕核心程序做了上去,到时候耽误的可不是几个钟头

三、程序设计要注重用户体验,当初客户对我要开发软件提出近乎苛刻的要求时我不在意,但是当我自己反复使用软件时有了很多体会,流畅美观的界面带给人心理的快感的确能替代一些尚未开发完整的功能带给用户的遗憾。

四、测试计划多次进行,分批进行,不要全部开发完成再对软件做测试。

还要坚持三个月,软件马上发布,希望大家的支持,谢谢!!!

软件开发心得体会 2018软件心得体会(2篇)

受某文化公司委托,开发一款用于视频和图像处理的软件,开发难度高,高到从未搞过,开发周期长,长到是我以前项目监控最长开发周期的两倍,开发成本之底,让我觉得程序员成了高级打员。首先是需求分析书、产品规格说明书、设计说明书、代码规范说明书、测试计划,光文稿就不知道熬了多久才做完。

紧接着,遇到一系列问题,首先是语言选择,vc++和c#都是可以保证开发完成的选择,但是vc++内存容易报错,界面很难修改,而客户要求的界面质量甚至比程序的功能更严格,没办法,客户就是上帝,上帝做事一定有他的道理。c#语言易于开发,而且图形界面绘制也易于修改,可以做出客户体验很好的界面,但是在资源的消耗上,让我很吃惊。做到第二个月,大概的界面已经完成时,出现界面刷新的问题,刷新时开始卡,界面不流畅。没办法,改。

开会,总结,技术骨干找问题,拿出解决方案,力争第一次做软件把它做好:

重新做软件开发进度计划和软件测试计划,并且让独立功能demo制作和测试先行;

用direct draw、direct 3d或者opengl中的一个替代c#本身的gdi绘图,将在接下来的开发任务中加入进去。

事无巨细,当我满意的看着界面流畅,功能也已实现时,发现软件在低分辨率或者小本上根本乱到没法看,甚至是界面功能按钮错位,重叠等等。没办法,改。毕竟软件的多分辨率兼容和操作系统兼容是必须要做的。

接下来一大堆的麻烦找了上来,软件出现各种各样想都想不到的问题,总算是按时将第一个版本发布出去,并且开始接下来的升级开发任务。

最后,给刚刚接手软件开发项目的朋友一些忠告:

一、相关的文档不是给别人看的,而是给自己看的,相关文档一定要齐备,而且让所有涉及开发的人员都清楚的知道你文档里所要表达的意思;

二、一定要注意多做demo,多做实验,一个demo程序员几个钟头就可以完成,甚至更少,但是不做demo,核心程序没有做实验,其他的东西都围绕核心程序做了上去,到时候耽误的可不是几个钟头

三、程序设计要注重用户体验,当初客户对我要开发软件提出近乎苛刻的要求时我不在意,但是当我自己反复使用软件时有了很多体会,流畅美观的界面带给人心理的快感的确能替代一些尚未开发完整的功能带给用户的遗憾。

四、测试计划多次进行,分批进行,不要全部开发完成再对软件做测试。

还要坚持三个月,软件马上发布,希望大家的支持,谢谢!!!

软件开发心得体会(2):

作为pm,有时需要招聘软件开发人员。这几年也一直在想,如何能在短短的30分钟或1小时内,快速识别出,坐在你对面的应聘人员,是否适合你的team。这几年也一直在观察和反思,经历过的team和现在team中的软件开发人员。有几点小的心得。

1. 倾向于招什么样的软件开发人员

- 经历过历练的人

吃过苦的,比如以前工作,经常被外派出差,又如曾在业内都知道以加班多而著称的公司呆过,还有些,留过学,但都是自己边打工边读书的,等等。

这些人员,入职后,通常都是能干活,能作为骨干。

- 思路清晰,思想活跃的人

让谈谈自己现在的产品,如果能清晰表述,有条理,会发散,但又能适当控制住,并收回到原话题。谈到技术问题和解决过的难题时,眼中有光芒:)

这些人员,今后工作中,学习能力强,对解决难题有帮助,能作为中坚。

- 坦诚、坚定、平和的人

面试中,坦诚,目光坚定。有时坦诚到甚至于显得有点木讷:)

我曾经遇到一个,面试下来,我最后介绍我们产品中用到的技术,他对这些技术知之不多,最后他说,我可能不是非常适合,我知道一个朋友,他可能更适合。我综合评估后,最后还是选了他,事实证明,他后来做的很不错。

坦诚坚定的人,会有恒心去学习,去解决问题。这些人员会作为team的基石。

- 有缺陷的人才

这是一个朋友(lance)的想法,我认为还是有道理的。

大公司,会看重综合素质,而如果是小公司,可以考虑选择一些有缺陷的人才。所谓有缺陷,是指,比如他英语很差,或沟通不清晰,但他能用程序员该有的思维去思考问题。这样的人员,通常进不了大公司,故会相对踏实地呆在一家公司,做好自己的工作。

2. 谨慎考虑这样的开发人员

- 太活泼,太易兴奋

太易兴奋,说到投机处,是是是是,对对对对。。。,又蹦又跳,还时不时来点,oh yeah, you are right,然后还摆个 v 手型。讨论问题,不易固守在技术问题本身,时常跑到我们产品中用到的技术(或第3方产品)很强,我挺他们,不可能有问题,又或者我们对客户要强势,我们要坚持我们的产品没问题。

软件开发工作本身,显得比较沉闷,优秀的技术人员,都略显有些内向,因为解决问题,很多时候需要耐得住寂寞,时刻保持相对冷静。

太活泼的人,会在遇到问题之初,表现出很强的冲劲,但当长时间不能解决时,会表现出没有耐心,会经常抱怨(对team、管理、产品、流程等),非常情绪化。有些女程序员还会吵,会哭,这时项目经理只能放下手中的活,下去给她买点零食来哄哄,莫哭,这里有你最爱吃的猫哆哩。一边擦着鼻涕、眼泪,一边嘴里塞满东西,鼓鼓啷啷这是酸角口味的,那个西番莲口味的才叫好吃...

这些通常不太容易在面试时表现出来,在试用期时,要观察。

软件实践课程学习心得体会 2018软件心得体会(3篇)

经过潘老师讲授软件工程实践后,感觉对软件工程这门学科有了深一层的认识。软件工程是一门重视实际操作的科学。对于软件产品,无非是产品定义、设计代码、调试维护几个步骤,看似简单,可是实际操作却复杂困难,它不比其它行业产品可预见可触及,所以学好软件工程能为以后从事软件开发行业打好基础。

在软件实践这门课中,讲到了有效利用现有资源进行软件编程的方法。提到软件开发也可以像练习书法一样,采用临贴的方式,借鉴他人的优秀代码资源。临摹优秀软件是学习软件开发的一个重要方法。正如一首诗中说的:熟读唐诗三百首,不会写来也会吟。软件开发也是一个道理。为了真正地掌握软件开发的技巧,临贴是个不错的起步方法。

以前总是觉得,既然编写一个程序,就应该完全靠自己,那样写出来才有成就感,才算是自己的程序,可是这门课程教会我原来适当地借鉴别人的东西,也不算抄,相反,还可以提高效率,节省时间。这可真是与以往的观点不一样了。具体如下:

软件编程,拿来主义的作用很大:

1、源代码交换方便。

2、可行的例程序用处大。

3、借鉴现成少走弯路。

不过借鉴别人的东西可是有说法的,可不是盲目地抄袭,下面是一些提到的途径:

1、既有系统:借鸡下蛋,买来就用;

2、书本例子:简单修改、直接使用;

3、联机或联网帮助:帮助文档、官方支持;

4、开放软件源代码:linux apache eclipse

5、互联网资源:论坛、搜索引擎、新闻组

借鉴过来后,还要多方面综合考虑,比如说代码的具体作用,完整性,还要考虑每个借鉴过来的东西的好坏。这些都要多方面考虑,可不能因为前面说软件编程可以借鉴别人的,就盲目地抄袭。到时候代码弄一堆凑在一块儿,谁也不知道它们会不会好好工作。弄不好乱了程序计划是小,公司的损失可不是哪个人都能承受得起的。

课程还提到,应该用一个小项目先从头到尾地练完,这样,有个整体性的了解,可以增加不少开发经验。看来,不学习此门课程,还不能深入地解读软件工程的奥义。这门课程为我们深入地了解软件工程这个庞大的前沿学科起到了推动性的作用。以上是我就此门课中提到的众多方法的一小段做的一些浅谈,更多的知识还在于我们自己去学习体会。

财务软件操作学习心得体会 2018软件心得体会(4篇)

下面我就这对次财务软件操作的学习做以下的学习心得体会报告:

1.学习收获: 会计电算化主要是应用电子计算机代替人工记帐、算帐、报帐,以及代替部分由人工完 成的对会计信息的处理、分析和判断的过程。 通过对用友 erp-u8 财务软件的学习, 认识和了解了财务软件系统应用基础, 系统管理、 总账管理以及 ufo 报表管理、工资管理和固定资产管理这几个方面的内容。在初次使用用 友(erp-u8)时候老师告诉我们先建立用户,再建账号,这样方便设置用户对账号的管理。 然后建立账套,将相关的企业及人员信息进行初始设置。并在企业门户里面进行基础设 置。接下来的过程就是启用总账管理系统进行日常的业务处理了,它是软件管理的核心,通 过对它的操作发我学会了运用计算机进行凭证管理、 出纳管理和账簿管理。 掌握了使用总账 进行转账和对账的功能,能够使用数据生成报表。此外,还对工资管理系统和固定资产管理 系统的相关操作进行了深入的学习。 总之, 通过对用友软件的学习基本上掌握了财务软件的 操作流程及方法。

2.学习体会 因为自己在计算机方面的学习还是很弱的, 尤其是这次学习的主要内容是关系到本专业 学习的电算化操作。 因此在整个学习的过程中, 包括理论课程和上机操作我都在很认真地听 讲和一步步地仔细操作。 但是还是难免的出现了一些问题, 比如说在注册系统时候没有将系 统的时间和账套会计期间相统一, 因此给后面的操作带来了一些不便; 在总账管理系统操作 中设置会计科目时候少设置了明细科目, 结果在输入期初余额时候才发现问题; 在输入数据 的时候抄错了数据, 试算平衡结果是不平衡的; 在制作凭证的时候凭证的制作日期发生了混 乱,系统提示说制作凭证不序时,无法进行后面凭证的操作,我修改了好久还是不行,把我 急坏了。问了 xx 老师,老师一操作就完成了,我很惊奇。老师说操作的时候不能着急,慢 慢来就好了。看来我的耐心不够好,做事不够仔细。不足的地方还很多呢。我谢过了老师并 继续实验操作。 与去年的手工做帐相比,在学习中我发现了电算化的许多优点:从编制原始凭证、记帐 凭证到登帐、结帐、编制报表(去年全程都是我是和搭档手工完成,处理一些数据的时候出 现了很多的差错,尤其是犯了如:金额写错、错行,借贷不平衡,凭证错乱、丢失等许多低 级的错误) ,而电算化则不同,数据一旦进入系统,记帐、对帐、汇总编制报表等过程都是 在一系列的设置成的体系中进行的; 对于电算化中数据的使用与保存, 只要通过账套的输出 和导入功能便可简便的实现了。

另外,电算化中对于凭证、账簿、报表的收集汇总、归类查 询都是很方便的。会计电算化,提高了会计工作质量,减轻了会计人员的负担,提高了会计 工作的效率,促进了会计工作的规范化。为更好地发挥会计职能作用,实现会计工作现代化 奠定了良好的基础。总之,电算化给我的印象就是:省时间,省人力、省材料,方便易行! 。 当然,需要说明的是:电算化不能完全取代人工操作。因为计算机也是人工操作的,计 算机不能完全取代人的大脑进行会计操作。 人工的理性化设置使得会计电算化成为了企业及 会计人员的得力的助手。

3.结束语 经过了四周的学习过程, 我们顺利的完成了学习的任务。 电算化的学习对我们即将毕业 的财管及会计的学生从事会计工作打下了良好的基础, 希望以后有机会还能更深入的学习这 方面的内容。最后,我想对一直陪伴着我们的老师们说一句:谢谢,老师您幸苦了!

  网站地图