软件通培训心得体会

此篇文章软件通培训心得体会（精选5篇），由智远网整理，希望能够帮助得到大家。

软件通培训心得体会 篇1

20xx年xx月xx日。我怀着对提高并实现自我价值的心态，走进深圳走秀网络科技有限公司的大门，开始了自己大学里兼职实习工作。转眼间。6个月的实习时间就要过去了。回想起这段时间的工作过程，我深深的认识到在走秀网实习的选择是绝对正确的，走秀网和公司的同事们对我个人产生的积极影响也是超越我料想之中的。现将这段时间的工作进行如下总结。

首先，要具有良好的学习能力。刚进走秀，带我的老大是哈尔滨人，我跟她很投缘。开始的一个星期，我只是熟悉公司的一些业务和我们前端的测试范围，在熟悉业务的过程中，我发现这些页面上的东西看上去挺简单的，但是要深入了解还是需要很长的一段时间。期间老大叫一个老员工带着我去测试一些之前xiu2.0所遗留的简单的bug。走秀网的测试部还比较大，所以对工作的流程和上线之前的版本控制的非常严格。我们在上线之前，会经过两套环境，功能测试环境和镜像环境，功能测试环境是对需求和功能的一个详细的验证环境，镜像环境是模拟生产环境回归之前我们在功能测试环境上锁遗留的一些小的bug。因为不知道这些转测试的bug是怎么产生的`，所以需要去跟开发人员沟通，开始的时候自己一个人不敢过去开发部，就让老员工(才哥)带着过去，一段时间过后，我开始自己去和开发沟通交流，从发现问题的重现，到催促开发修改和转测试，这一段时间让我深刻体会到沟通时多么重要。

在走秀期间，我们测试部总监还会对我们不定时的培训。教会我们测试的工作流程和每个阶段应该展开的工作范畴。作为测试，必要会使用的缺陷管理工具bugzilla和测试用例管理工具testlink，还给我们培训了，如何使用自动化工具ruby+watir来对一些测试点进行自动化脚本的编写。慢慢的，在对公司的业务了解的比较透的时候，老大就开始让我们自己对一些小需求进行测试，测试的过程中，不仅仅是对页面和表面功能进行测试，还要根据需求文档和页面的显示对数据库表进行查询操作，查看页面的显示和功能是否和数据表里面的一致，还要在后台日志中查看是否有报错。所以，测试并不是像我想象中的那么简单，不是在页面上点来点去就可以测的好的。

实习可以使每一个学生有更多的机会尝试不同的工作，扮演不同的社会角色，逐步完成职业化角色的转化，发现自己真实的潜力和兴趣，以奠定良好的事业基础，也为自我成长丰富了阅历，促进整个社会人才资源的优化配置。作为一名学生，我想学习的目的不在于通过毕业考试，而是为了获取知识，获取工作技能，换句话说，在学校学习是为了能够适应社会的需要，通过学习保证能够完成将来的工作，为社会做出贡献。然而步出象牙塔步入社会是有很大落差的，能够以进入公司实习作为缓冲，对我而言是一件幸事，通过实习工作了解到工作的实际需要，使得学习的目的性更明确，得到的效果也相应的更好。

人要想成功及获得好的业绩，必须牢记一个规则：我们永远不能将个人利益凌驾于团队利益之上，在团队工作中，会出现在自己的协助下同时也从中受益的情况，反过来看，自己本身受益其中，这是保证自己成功的最重要的因素之一。

软件通培训心得体会 篇2

广联达软件确实给我们的工作带来了很多便利，但如何用好软件还是有许多注意事项，否则一个不注意可能就会对你的算量工作带来很多不必要的麻烦。安县项目是我做的第一个完整的广联达模型，首先要感谢我可爱的同事们，在做这个项目过程中给了我很多帮助，从你们身上我学到了很多。在这个过程中我对于广联达软件也建立了一些自己的认识，下面就来疏理一下我总结的一点小经验：

1、是新建项目，都是从钢筋工程开始，一开始就要选择好计算规则，这是之后不能修改的，软件也会自动题示你。

2、在比重设置中修改6#钢筋比重为6.5#的。因为目前市场上没有直径6的钢筋，施工时都是用直径6.5的钢筋替代直径6的钢筋。

3、在2009四川定额工程量计算规则中“钢筋（钢丝束、钢绞线）按设计图示长度乘以单位理论质量计算，项目中已综合考虑钢筋、铁件的制作损耗及钢筋的施工搭接用量。”所以要在楼层设置中把搭接全部设置为0，这样就不会计算搭接区的量；还有种方法是将把定尺长度全部设置为软件允许的最大值50000mm，接头形式可以定为其他形式。这样只要图式长度在50000mm范围内就不计算搭接，超过50000mm它计算的接头也是其他形式，这样较易分辩。另外在11G101—1第54页右下角注中“梁、柱类构件搭接区箍筋直径不小于d/4（d为搭接钢筋最大直径），间距不应大于100mm及5d（d为搭接钢筋最小直径）。”而四川定额工程量计算规则中只是说综合考虑钢筋的施工搭接用量，并没有明确说明是否包含了这部分搭接区箍筋加密的.量。

4、楼层设置时有架空层和错层要尽量考虑以后工程量的划分和画图方便，我在画第一幢楼时设置楼层过细，把架空层也单独设置一层，结果最后把同层的墙、柱分成了几段，虽然对实体工程量没有影响，但画图布装饰和最后统计工程量的时候就会很麻烦。楼层设置对超高模板的量也有会影响，因为软件计算超高模板时是以层底标高开始计算的，如下图将层底标高设置为—4.5，这时三个区域的板和梁计算超高模板量都是以—4.5为底标高计算的，这要怎么在软件上处理，我还没找到办法，只能最后查看计算式，直接调整工程量。

5、在导入CAD之前要将CAD图纸转换成天正的T3格式，这样可以最大限度的保证导入图形的完整性。在识别板钢筋时，识别完成后会弹出一个如下图的提示框，一定要按照其提示一条一条的修改之后才可以关闭提示框，否则之后再调整板筋布置范围重叠就找不出这个提示框了。

6、在画变截面筏板时最好先统一画成一块整板，用分割功能进行分割，再修改其属性，这样可以保证筏板之间没有空隙，不然在设置筏板变截面时容易出错。

7、在布置剪力墙时要将暗柱覆盖，保证与砌体墙之间没有间隙，不然导入土建算量后房间没有封闭，软件不能自动识别，布置装饰将会很麻烦。

8、总说明中的梁构造腰筋及次梁加筋可以在所有梁布置完成后统一布置。如梁构造腰筋是以梁腹板高度为设置依据时，一定要在板布置完成后才布置，因为计算梁腹板高度是要扣除板厚的。

9、自动生成砌体加筋时，一定要点开“加筋形式”查看一下相应的图形类型，按实际情况调整一下选择参数化图形。这样才能准确统计出相应的预埋件和植筋数量。

10、布置墙面时，如一匹墙要分成两种墙面，那么使用打断功能将其打断，不要删除别一段，可以直接修改属性，如果将其删除，之后再画别一段墙面时，就不容易布置上去了。

软件通培训心得体会 篇3

在支付宝测试分析的角色和系统分析的角色是对应的，只不过一个是测试类的另外一个是开发类的。系分下面会有相应开发，测分下面会有相应的测试用例编写和执行人员。也就是说测试分析文档是对测试执行人员的一个指导(在我原来的理解方式上，觉得测试分析人员应该是用例编写人员;而在这里测试分析人员是从业务上去分析的，用例是用例执行人员来写并且执行的)。

而通过这次的这次分析觉得自己的测分还存在以下的问题：

1、太关注开发的内部实现逻辑。建议：将开发内部实现逻辑看成一个黑盒子，测试分析要从这个黑盒子的输入和输出上去看开发内部实现逻辑是不是有问题，而不应该先去了解开发的实现逻辑然后按照他们的思路去分析。

2、分析文档写的过于详细，甚至将用例的`步骤都写了出来。建议：测试分析要从全局上去看问题，细节的东西即便是知道的，也要留给之后的用例编写人员去了解(就像系分之后的开发需要去写详细设计的道理一样)，这样后面的人才会自己主动去想问题。

3、分析文档要考虑维护性问题，不要出现类似比如还款中状态为“R”这种具体的数据内容。因为我的分析是对后续用例编写人员的一个指导性的文档，所以如果侧分这么写很有可能导致用例也照着这么写，其实不管侧分和用例都不应该具体写到R这么细节，否则的话开发稍作变动我们就要相应变动我们的用例

4、没有明确测试目的。review用例的时候，没有提出每个用例需要明确一个测试目的，让别人来看这个用例的时候能明白到底是怎么回事。

总结：

1、以后写测试分析文档，依据仅仅是prd文档，必须抛开开发实现逻辑部分(即不去看系分文档)，待测分出来之后，再去看系分文档，互相看看彼此考虑的是否存在遗漏的地方。等到在写用例的时候再让写用例的人和相应的开发去互相明确更细节的东西。

2、写用例我们目前都是仅仅做到对流程上的每个节点去单独分析，细到看输出的时候会关注到数据库表的一个变化。但是除了以上部分，其实还少了对整体流程的关注，需要增加业务流程的各条路径的一个覆盖，在针对路径的用例中不需要关注到数据库表级那么细。

3、在做流程路径覆盖之前应该画一个路径图，这个图的画法考虑各个入口的不同分开画流程图，分别进行路径覆盖。

软件通培训心得体会 篇4

检查人员调取了A金融服务公司的电子账。该公司是分支机构，总部在上海，甲市地域内的小额金融服务由该公司负责，合作方为与之有关联的B公司，B公司在各大卖场，特别是家电卖场设立经营柜台，为购买手机、电脑等家电商品的用户提供小额贷款业务，购买者需要贷款时，在卖场的经营柜台与A、B公司签订贷款及金融服务合同，生效后，B公司将全款支付给卖场，购买者提取商品，并按合同约定分期(如12个月)向B公司支付贷款本金、利息和金融服务费，B公司收取款项后，按月拆分给A公司，A公司就收取的金融服务费申报缴纳。

检查人员在对营业税情况进行检查时，首先按年度核对营业税的计税依据是否有问题，电子账显示，6001-main business income(主营业务收入)科目当年有较大发生额，反映的似乎是主营业务收入，同时，另外有一个科目7002-clearing house accout -off bs- business-gc fee(账外科目——业务类——金融服务费)有一个较小的累计发生额，也像是主营业务收入，但似乎又不是。就此问题，检查人员询问了被查单位的财务人员，财务人员的解释是，6001记载的是每个月所有生效合同总的应收金融服务费金额，7002记载的是按合同约定每个月实际分期收到的金融服务费金额。这一数字由B公司数据服务器自动拆分，每月会有一张拆分表，被查单位根据拆分表进行账务处理。检查人员查看了部分服务合同，核对了两个被查年度7002科目记载的当年累计发生额与当年营业税申报缴纳情况，确定被查单位所缴纳营业税的计税依据就是7002科目记载的当年累计发生额，未发现疑点。但这样是不是营业税就没问题呢?

从被查单位的财务核算及数据拆分的原理来看，6001与7002科目发生额是有关联关系的，因为，7002是6001的一种“递延”，如2012年1月6001当月发生额120万元，且均为12期(即在今后12个月内分期支付金融服务费)，那么今后12个月，每个月7002都会有10万元的发生额，这就是二者之间的逻辑关系，根据这一原理，检查人员决定将6001和7002科目的趋势进行比对，看能否发现什么问题。

在用友查账软件中，检查人员点击“稽查实施” →“科目趋势分析”，设定分析科目为6001和7002的2012年1月到2013年12月贷方月发生额，点击“分析”，生成了两个科目两个年度月发生额的趋势图表，上面那条曲线(简称Q1)是6001的趋势，下面的曲线(简称Q2)是7002的趋势，仔细观察这个图，检查人员发现，Q1虽然弯折厉害，但应该是自然的，在前期与被查单位业务人员沟通时，检查人员了解到，其月金融服务合同签订的情况是不均衡的.，如每年10月是经营旺季，所以合同签订的多，6001增幅较大，而11月则进入淡季，合同额会大幅减少，但随着该公司业务的拓展，总的业务量是不断上升的，因此，可以判定Q1线是合理的。再看Q2，检查人员发现，它的最大特点是太完美了，稳步平滑增长，没有任何曲折，这是不符合实际的，因为Q1有较大的波折，根据Q1、Q2的关联关系，Q1的波折和起伏应当会在以后的期间内通过Q2反映出来，但Q2恰恰没有波折，似乎与Q1无关，存在明显的人为加工痕迹，据此，检查人员判断，根据数据拆分确定的Q2，可能没有完全反映实际情况。接下来，检查人员到被查单位实地检查，查阅了所有的合同资料，履行相关手续后，检查了被查单位相关银行账户的情况，进一步逐月核对了数据拆分情况，终于确定了被查单位人为递延、少计拆分数据，延迟并少缴税款的事实，检查人员依法进行了处理。

软件通培训心得体会 篇5

在大庆浦东软件平台有限公司经过一周的软件测试实训，从对软件测试没有什么经验的我初步掌握了软件测试的方法和技能，收获颇多。

我在大学期间的专业是信息与计算科学，原本打算从事网络方面的工作，对活动目录、数据库、操作系统等的知识比较感兴趣。经过这次理论学习，了解到要做好软件测试，要求掌握的知识并不仅仅是测试方面的，网络、数据库、操作系统等的知识对做好测试也是很有帮助的。这让我明确了以后学习的目标，在不断学习软件测试的同时，也应该继续其他相关知识的深入学习。

通过此次学习，对整个软件测试行业的了解大大的加深。以前认为软件测试只是枯燥的反复的使用被测试软件来发现异常的问题，以为软件测试并不重要，低开发一等。现在认识到了软件测试的重要性，软件测试是软件产业向软件工业化生产时代迈进不可缺少的重要组成部分，是保证软件质量达到客户需求不可缺少的环节。软件测试在国内是一个新的职业，发展得比较晚，但它的重要性正在为行业所重视。

在学习过程中，我了解了作为一个合格的`测试人员所应具备的素质与技能。其中个人素质在测试工作中起到了非常重要的作用，它包括你的信心、耐心、细心和与人交流沟通的能力，它将贯穿你工作生涯的整个过程。在测试理论上，我们系统学习了软件测试的流程，各种测试阶段和测试方法，以及测试工具的使用。通过这些课程的学习，让我们对软件工程也有了更深刻的理解，为以后的测试工作作了很好的理论储备和技能的提升。

软件测试作为软件开发过程中一个非常重要的环节，越来越成为软件开发商和用户关注的焦点。完善的测试是软件质量的保证，因此软件测试就成了一项重要而艰巨的工作，要做好这项工作当然也绝非易事，我在做软件测试工作中总结出了一些经验和技巧。

1.功能点的细化

在进行测试前，先将所要测试的功能细分，填写《测试用例表》，有针对性的运行功能测试案例，逐个对每个功能细分点进行测试。在每次运行测试案例之前，明确此次运行的目的和预期的输出结果，并要做好记录。

2.注意测试中的错误集中发生的现象

有一些错误是和程序开发人员的编程水平和习惯有很大关系的。例如程序中的拼写错误，习惯用法等。注意收集并记录这些现象，有助于更快、更多地发现类似的错误。

3.尽可能多的使用非常规的测试

充分考虑到各种合法的输入和不合法的输入以及各种边界条件。边界值往往是最容易出现异常的情况，特殊的情况下甚至要制造极端的状态和意外状态，比如网络突然中断，和电源突然断电等情况。

4.对测试错误结果一定要有一个确认的过程

一般有A测试出来的错误，一定要有一个B来确认。

5.制定严格的测试计划

测试时间安排的尽量宽松，不要希望在极短的时间内完成一个高水平的测试。

6.回归测试的关联性一定要引起充分的注意

在开发人员刚修复Bug之后的地方，再找一找，往往开发人员只修复报告出来的缺陷而不去考虑别的功能在修改时可能会重新造成错误。修改一个错误而引起更多的错误出现的现象并不少见。

7.测试文档要尽可能详细

《测试用例表》中的功能点可尽量的详细，如实、详细地记录每次运行测试案例的输入数据，输出数据，出错提示，进行测试的时间，完成测试的时间等，便于以后对测试工作的回溯。

8.重视交流和沟通

包括和程序开发人员的交流，同是测试人员之间的交流，网上技术论坛和网友的交流，和客户的交流等。多思考，多交流，多提问，通过多种沟通交流的途径，可以少走很多弯路，同时可以学到很多东西。

9.善于总结

在测试过程中发现的所有问题，异常情况，发现程序开发人员易犯，常犯的错误，各种有价值的经验教训，使用系统和操作数据库时发现或者学到的技巧，使用测试工具时的心得等等，都可以随手记录在笔记本或者电脑上。这些都将是今后工作中可以参照的珍贵资料，同时也会成为自己的宝贵经验。

10.妥善保存一切测试过程文档。

这次软件测试实训为我们以后从事软件测试工作打下了良好的专业基础，为我们的进一步学习提高打下了扎实的理论基础。对测试过程有了初步的认识，测试计划、测试设计、测试开发、测试执行、测试评估、测试报告贯穿整个软件开发过程。单元测试、集成测试、系统测试、验证测试每个阶段都应以用户需求为依据。这些基本的概念虽然比较抽象，但对以后的实践是大有益处的。

总的来说，这次培训效果不错，对自己有一定的提升，这完全不同与学校的学习，因为它更加贴近工作，针对以后工作的内容作了很多实例的练习与工具的使用，为我们更快的加入工作提供的很好的前提。接下来一段时间，我将利用假期进入相关测试部门进行实际项目的训练，我相信在我有了很好的理论基础后，会在工作中很好的加以应用，让测试工作做得更好。同时，我会更加努力的学习与工作，遇到问题会及时多渠道寻找解决方法，积极上进，希望早日成为一名优秀的测试人员。