优秀的工作总结是对工作中的时间管理和资源利用的总结和反思，工作总结是对自己工作中的学习和专业知识的总结和巩固，为个人成长提供支持，小编今天就为您带来了软件员工作总结最新6篇，相信一定会对你有所帮助。
这个学期我学习了软件测试这门专业课程，在学期即将结束的时候，我也对这门课程建立基本的了解和理解。软件测试这门课程作为软件工程专业中一门很重要的课程，已经在软件领域占据了不可替代的角色，当一个软件从雏形到真正的在一台计算机上运行的时候，谁也不能保证计算机软件能一步到位的满足人们的需求。所以就有了软件测试，其目的是：第一是确认软件的质量，其一方面是确认软件做了你所期望的事情，另一方面是确认软件以正确的方式来做了这个事件。下面我简单的写一下这个学期对课程的总结和收获。
我认为，在整个庞大的软件工程中，不管是需求分析、架构设计甚至是最后的debug，都会产生引入不管的机会，这就要求作为一个软件测试师要掌握丰富的软件工程原理和知识。测试的工作将会存在于整个项目周期，即在项目开始时需要各种分析调研时就开始了。尤其是在形成需求规格说明书时就有对文档的测试需求，甚至主导整个项目的走向。
软件测试对逻辑思维、学习能力、反应要求很高，是否有严密的思维和逆向思维也非常重要。做测试还要考虑到所有出错的可能性，有时候还要用一些非常规的的测试方法。软件测试还很注重软件性能问题，也就是要保证软件运行得很好；不同的使用环境下，考虑软件的兼容性同样重要。对于测试员来讲，会比开发人员更加重视软件产品的质量问题。在测试过程中，测试者可能会为客户的需求角度考虑到更多，由此我们可以认为测试人员有权利决定产品是否可以发布。然而，通过一个学期的学期，我们又不得不懂得，软件测试人员不是万能的，测试人员在面对一个设计烂编码烂的软件时，也是无法不低头的，再怎么测试它也变不成优秀的软件。
通过课上的理论因为课下的实践和后半学期又因为身体力行于
1、最基本的测试的分类：从是否需要执行被测软件的`角度，可分为静态测试和动态测试；从测试是否针对系统的内部结构和具体实现算法的角度来看，可分为白盒测试和黑盒测试。
2、然后就是，白盒测试中的逻辑驱动测试的覆盖率测试。
3、还有就是对于划分等价类和边界值法这一块，让我从模糊到明朗。
4、在初次写测试用例的时候，感觉真是纠结，用例写的很死板，看似简单的一个填表工作，要写好真是不简单。一开始写的比较不自然，有些生搬硬套，而且还很慢。在后来负责了对论坛新鲜事版块的测试之后，明白了测试用例其实就是指导怎么去执行测试，而且书写设计测试用例也要以熟悉软件的业务为前提，才能更好的去测试。
另外就是一个学期的学习让我纠正了几点误区：
1、有位大师曾说过：“软件测试的目的在于发现错误，一个好的测试用例在于发现从来未发现的错误，一个成功的测试是发现了从未发现的错误的测试。”由此我自认为测试就是为了找到bug，然而一个学期的测试学习经验告诉我这是错误的，如果只是为了找到bug，那么bug会成天缠着你。
2、在大家协力测试论坛的时期内，我曾认为这种大量的重复性的工作真的很乏味，可是在这乏味中真心发生挺多有意思的bug，意想不到的bug，所以我认为只要掌握了方法，在重复中寻到到创新的小惊喜，任何东西都有它的特点。
作为测试新手，通过一学期的学习，我认为能独立写测试计划，设计测试用例，精通一种测试工具，理解一种bug管理软件是新手晋级老手的必备素质。任重而道远？！
在最后，我不得不提的就是细心和耐心了。这是我认为这个学期测试课上收获的了，课程要求测试时必须细心和耐心，我在想，如果以后真的工作在测试一系列的岗位上，要学会坐得住，用大量的时间和精力和bug斗争，分离、识别还有归类bug，是不是也能真的改变我粗心大意和三分钟热度的毛病。
最后感谢刘老师这学期的课程讲授，和实践中的指导和帮助。测试路程，路漫漫其修远兮，吾将上下而求索。
时光荏苒，如今17年的帷幕已经谢下，18年的钟声已经敲响，在公司高层的正确领导下，我们佰腾科技又走过了一年。而我也在自己的努力以及同事的帮助下完成了20xx年我所负责的工作，以下就是我对过去这一年的工作总结：
作为软件部测试组的一员，首先要做好的就是自己的本职工作，我在20xx年中所做的工作主要有：
1.xxxxxxxx测试用例的编写，对系统的测试、跟踪；
2.xxxxxxxx需求、高保图、界面和功能的测试；
3.xxxxxxxx功能测试用例的编写，高保图、系统的测试；
4.xxxxxxxx的静态页面测试和功能测试；
5．xxxxxxxx的功能测试；
6．xxxxxxxx第一、二、三迭代高保图测试，测试用例编写，静态页面和功能测试，并主持参与测试用例评审；
7．xxxxxxxx平台高保图的测试和系统静态页面、功能的测试；
8．xxxxxxxx的高保图测试和测试用例的编写；
9．xxxxxxxx的静态页面和功能测试，参与测试用例的评审；
10．xxxxxxxx的高保图测试、静态页面和功能测试；
11．xxxxxxxx用户使用手册的编写；
一年的工作，让我获得很多方面的经验：
1．编写逻辑覆盖率全的测试用例甚为重要。在理解需求的前提下编写测试用例，使得我掌握了多种测试用例编写方法，更让我对产品的需求有更加深入的理解，须知对需求是否理解透彻决定了能否有效、全面地对产品进行测试；
2. 要站在用户角度对系统进行测试。从一些项目中出现的未能及时发现的bug中，我认识到用户体验的重要性，现在能够越来越多的从这方面来执行测试；
3．对拿到手的项目有较清晰的思路，能够更加快速、准确地发现问题；
4.越来越规范的工作流程的让我们的工作有条不紊的进行，让我深刻认识到工作的规范性是多么的重要，并且从中学习如何从文档和流程上规范工作。
5.同事间的沟通很重要。现在不管遇到什么不确定或疑惑，都与开发人员、
产品经理等及时沟通，大大提高了工作的效率。
只有不断的提高自己各种的能力，才能胜任越来越艰巨的任务，因此在工作相对不饱和的时候，我自己进行了一些学习。
为提高对“用户体验”的理解，我学习了《下一站用户体验》，书中一些经验确实让我获益匪浅。不能总拿别人的用户体验去改进自己的产品，但是有一些却是通用的，比如：太多弹出框、按钮会给用户带来愤怒感，要适当的给页面减肥等等。
深知单纯的界面测试和功能测试已经渐渐不能满足今后平台的开发，所以我学习了性能测试的一些相关知识，并在师父的指导下运用lr工具进行简单性能测试，以后必须坚持学习。
一年的工作让我有所进步，但是很多地方还是存在不足，比如：有时候看问题比较主观，不是很细致，没能深入地去测试，会有遗漏的bug；自身专业技术能力还不足，不能从系统稳定性这一点上对系统进行测试。在以后的工作中，我会努力改善。
在20xx年的工作中，我计划：
1、本着实事求是的态度，更加认真、负责的完成工作；
2、要尽可能深刻的理解需求，坚持编写覆盖率强的测试用例；
3、按照系统稳定性测试方案，要逐渐对系统的稳定性、安全性进行测试；
4、继续研究性能测试，并要将lr工具运用在实际工作中；
5、多多的学习，参加一些有益的培训，在实际工作中活学活用。
这一年来我们部门有着的显著进步，越发规范的工作流程，越来越明确的责任制度、管理体系等，都让我们更加有凝聚力。在此，个人提出以下几个小建议：
1、希望可以加强对项目的把控，尽量能将延期风险降到最低；
2、从各个组对需求理解的不一致，以及信息更新不及时等问题上看，沟通
问题还是有待完善；
3、希望能够在需求这一关卡上能更详细、准确的确定产品的功能要求；
4、虽然工作任务繁重，还是希望部门能够多组织活动，完善奖励制度，可
以让大家更加激情的为部门、为公司奉献自己的全部力量。
以上是我个人的一些浅见，相信在大家共同的努力下，向着同一个目标进发，软件部甚至整个公司必定会大展全新的宏图伟业。
时间一晃而过，转眼间xx年已接近尾声。回首繁忙而又充实的xx，心中不禁感慨万千，过去的一年中通过自身的不断努力，使得技术水平、沟通技巧等方面都取得了一定的进步，当然亦有需要改进的地方，这是我人生中弥足珍贵的经历，也给我留下了精彩而美好的回忆。 非常幸运能够成为zx的一员，回顾奋斗历程，收获颇丰。记得初来乍到之时，不懂公司的管理制度，业务流程，工作方向。通过在江门的学习，我才融入了这个新的大家庭。这归功于公司制度合理，培养新人有方。之后的工作更让我认识到，zx是一个团结的大家庭、和谐的大家庭、有归宿感的大家庭。心在这里，家就在这里。这里的每个人，都是有着理想、有着目标、有着人生方向，倾情抛洒血汗灌溉自己梦想的人。在工作上，我们是好同事，我们一起讨论技术难题、业务流程；在生活中，我们是好朋友，我们一起畅谈人生理想、生活杂碎，社会百态。
进公司以来，我设计开发了webgis项目，克服了webgis项目存在的各种技术难题，界面美观设计，数据库通讯，socket通讯。去绵阳出差部署自己开发的软件是让我最有成就感的一件事。在部署
webgis项目时，我发现现场环境复杂多变。先是wcf连不上数据库，测绘局地图调用不出来。那时，我经常熬夜解决这些难题，皇天不负苦心人，在我的努力下，webgis终于能够顺利运行了。出差的过程也让我收获颇多，既提升了和客户沟通交流能力，也提高自身技术能力。完成webgis项目后，我又迅速投入到宜昌短信回访项目中。维护短信网关，开发短信发送接口，短信接口。此项目让我感到，写好一个能够良好运行的软件其实不容易，客户需求是变化多端的。希望有一天软件真正能够达到智能化。
在过去的工作当中，在领导和同事们的悉心关怀和指导下，通过自身的不懈努力，各方面均取得了一定的`进步，但这些远远不够。俗话说：“人无远虑，必有近忧。”我明白，要学习的东西还有很多，要提升的空间还有很大。今后，必定会不断督促自己，努力提高自身素质，克服不足，朝着以下几个方向努力：
1、学无止镜，时代的发展瞬息万变，各种学科知识日新月异。我将坚持不懈地加强学习，向理论学习，向专业知识学习，向身边的同事学习，逐步提高自己的理论水平和业务能力，并用于指导实践。
2、“业精于勤而荒于嬉”，在以后的工作中不断学习业务知识，通过多看、多学、多练来不断地提高自己的各项服务技能，克服年轻气躁，做到脚踏实地，提高工作主动性，不怕多做事，不怕做小事，在点滴实践中完善提高自己。
3、不断锻炼自己的胆识和毅力，提高自己解决实际问题的能力，并在工作过程中慢慢克服急躁情绪。积极、热情、细致地的对待每一项工作，继续提高自身文化的修养，努力使自己成为一名优秀的工作人员。
4、在工作上积极配合刘卫兵工作，快速，有效完成上级交代任务。
5、认真做好天津pgis项目。
作为软件工程师至关重要的一点那就是：学习!不断学习!掌握一门学问远远没有想象的那么高难、深奥，只是多花些时间。多方吸取、广泛涉猎，极力夯实能力。想成为出色的软件工程师不仅仅是软件知识，还有财务、经济、税务、管理等等知识，韬光养晦、未雨绸缪。今年算是丰收了，争取来年进行大丰收。
伴随着充实紧凑的工作生活，两个月的时间已经过去了。这一段时间里有工作上的收获，知识的丰富，经验的增长，同时也暴露出很多问题和不足。总结经验，吸取教训，本文将主要从几个方面来对工作进行总结：工作的主要内容；其中的失败和教训以及成功和经验；展望下一阶段的工作，确定自己的目标。以此作为惩前毖后的记录。
1、工作的主要内容
在这两个月的工作中，我的总体任务是协助xx做好武警xx部队xx管理系统的后期测试，编码，修改，文档编写的工作，分解开来之后，我主要做了三件事：编写xx系统的各类文档；系统的编码及bug勘误工作；系统的测试工作。下面依照时间来对我的工作进行介绍。
初踏入职场，进入专业的软件制造公司，对我，一个没有接触过标准软件制作过程的新人来说，起步就是一个很大的难题。若直接做开发，则业务不熟练，代码不规范，弊大于利；若仅做学习，则不能跟上项目的步伐，不能以最快的速度融入工作中去。
在我还在忐忑自己到底要做什么工作的时候，任务已经下达了，首先进行xx系统的测试工作。这样的好处在于能够在测试的过程中，了解项目的整体布局，了解项目中的业务逻辑，了解项目中尚未完成的工作并以此作为下个阶段的工作目标。至此，入职工作顺利起步。
在对xx系统进行测试之后，暴露了系统的诸多问题，测试过程中发现xx系统没有进行输入限定，为了解决这个问题需要对整个系统的数据进行整理，我的下一个任务就是编写xx系统的数据需求文档。在编写该文档的过程中，对xx系统进行了更深入的了解，为之后的bug勘误工作奠定了一定的基础。
完成了xx系统的数据需求文档的编写之后，新的任务是对整个xx的输入数据进行输入限定，在任务开始之处是极为困难的，幸而得到了同事们的帮助才得以顺利完成任务。任务虽然完成，但是对输入限定实现方法的一知半解以及任务完成过程中的不仔细，为之后发生的问题也埋下了苦果。
在对xx系统添加输入限定完成之后，进入了解决程序小问题的阶段，对xx系统进行细微的缝补工作。这段时间是学习多于工作的，不同的问题督促我要每天和百度亲密接触数百次，又要劳烦诸位在百忙中的同事抽出时间来给我帮忙。虽然辛苦一点，但收获却是满满。
完成了系统的修补之后，我们的程序送到了xx进行第一轮测试，在测试的一周里，我主要是补充网络编程的基础知识。
第一轮测试结果出来之后，我们项目组开始了紧张的第一轮xx系统bug勘误工作。拿到bug列表之后，发现有一小半错误皆是因我而起，输入限定问题很多，我也主动承担了输入限定部分的bug勘误工作。
第一轮bug勘误工作完成后，进行了第一轮了回归测试，测试结果已然不尽人意，仍然存在大量的问题需要修改，而且很多问题还是因我而起，输入限定仍然存在大量问题，再一次进行修改之后，我们的程序送到了十五所进行所检。
在进行所检之余，我又接到了新的任务，完成xx系统的概要设计以及详细设计文档的编写。这两份文档已于9月2号编写完毕。
现阶段我的任务是根据所检的bug列表，对矿权系统进行回归测试。
2、工作中失败的教训以及成功的经验
对于失败的教训要吸取，成功的经验要进行总结。我对成功的定义是：在保证质量的前提下完成既定的计划或目标就是成功。其他的所有结果都是失败。
成功的经验：
（1）敢于接受任务并想尽一切办法完成
入职两个月最大的收获就是敢于接受任务并想尽办法完成，每一个任务对于初入职场的我都是一个挑战，如何保质保量完成任务是最基本的要求。这两月最大的成功在于没有一次任务是拖沓的，每次都尽最大努力完成了任务。
（2）勇于承担错误，正视自身的问题
在这两个月的工作中可谓是错误不断，从文档的错别字这种小问题到xx系统bug修改不正确导致崩溃这种大错误，暴露出来了很多的问题，我秉承着有错即改，下不为例的思想，正视自己的错误并积极改正，因此这也算是一个成功。
失败的教训：
（1）重视每一个细节，不要忽视小问题
在最初进行xx系统数据需求文档的编写的过程中，对某些页面的数据在数据库中没有存储的情况没有加以重视，在后期进行数据限定的时候，还要重新修改数据需求文档，造成了不必要的时间浪费。从这个事情上得到教训就是不要放过任何一个小问题，这个小问题可能导致之后的大问题。
（2）进行重复工作也不能大意
在对xx系统进行输入限定的方法熟悉之后，都是重复性的.工作，给每个页面，每个字段进行输入控制语句的添加，在进行了数个页面之后，出现了有的页面没有添加完整，或者提示语句不正确的情况，在后续的bug勘误中出现了大量此类问题，浪费了大量的时间和精力修改。从这个事情上得到的教训就是工作不能大意，重复性的工作更要完成好。一般重复性的工作第一次做不好，后续检查修改是非常浪费时间的。
（3）考虑问题要严谨
在对xx系统bug勘误的过程中，对输入限定条件的判断出了问题，我想当然的按照我的主观思路对数据进行了限定，而在回归测试的时候出了问题，这些都是考虑不严谨的后果。这个事情的教训就是考虑不严谨直接导致问题推倒重来，影响了工作效率，而且很容易埋下隐患。
（4）注重用户体验
在xx系统bug勘误的过程中，修改最多的在于坐标系统的提示语句，因为坐标系统不仅要求数据必须填入，而且每一个数据都有严格的格式限定，因此每一个错误提示的弹出都要本着如何让用户知道哪里错了为原则进行设置。在最初的限定里面，语句粗糙，弹出语句不明确，造成了用户使用的不方便，还得重新进行改造。这个问题的教训是一定要从用户的角度出发考虑问题，注重用户体验从简单的提示语句做起。
3、展望下一阶段的工作
下一阶段短期内我们的工作主要针对矿权系统的使用的数据库变更来对我们的系统进行修改。我的工作任务主要是学习oracle数据库和sql数据库的使用上的区别，做好从sql数据库向oracel数据库的迁移工作。
这两个月的工作生活是充实且富有乐趣的，结识了很多同事和朋友，公司的氛围是非常轻松愉快的。感谢两个月来xx经理的关心，感谢部门同事的悉心指导，感谢公司各位同事的热心帮助，希望能在接下来的工作中能惩前毖后，总结经验，吸取教训，做到个人与公司共荣辱同进退，共同实现中地的辉煌。
20xx年过完年后，我被主管派到一个大组去学习自动化测试技术。这个测试组是个比较大的测试组，总共有几十号人，其中有很多牛人。他们的自动化测试框架就是由几个牛人耗时1年多开发出来的。到现在，他们的自动化用例覆盖率约50%，应用率好像有70%，总之这个自动化测试框架还是满厉害的，不过就是整个框架实现太复杂了，涉及的编程脚本就用了三种。
下面简单介绍一下该gui自动化测试框架。
测试工具：ibm rational robot
自动化测试技术：第三代自动化测试框架
测试脚本：robot中使用的是sqabasic脚本(基于basic的一种脚本)，另外还使用了tcl、com组建等，并自行开发了一个抓包工具用于自动化测试。还有我们测试的产品界面是使用java开发的，如果要让robot能够正常识别界面，还需涉及到java编程。
学习自动化的头一个星期，我只是学习该测试组的产品知识，学习如何使用自动化测试。后面的几个星期就开始承担自动化测试的建设任务了。想想当初自己还是满辛苦的，白天上班学习产品知识，晚上回家就对着电脑看basic脚本的语法，周末还去公司无偿加班看代码。
在技术文档的选择上，我基本只看英文的，单词不懂就拿金山词霸查，实在看不懂了才会去找些中文的资料看。为什么要选择英文的呢?因为很多中国写书的人很浮躁，只想着快点把书出版了好赚钱，所以很多中文的资料质量很差。首先要贬低的就是那本谭教授的《c语言程序设计》。记得读大学时，照着谭教授的书敲程序，没多少程序能编译通过的，真是误人子弟。
当时带我学习自动化的导师姓l，他是个大忙人，有时一整天都在开会。l的师傅姓w，w是该自动化创始人之一。
当时对我比较有用的文档就只有两篇：一篇是汇集型的chm文档，是篇比较全面的介绍，其中包括自动化框架的介绍，原理的介绍，各模块介绍，自动化执行的流程等;另外一篇则是由w写的自动化建设指导书，写的还是满不错的，在我有一定基础后，照着指导书就能完成简单的自动化建设。
在我整个学习过程中，是按照以下的过程开展的：1、吴江装修网初步了解整个自动化和产品知识，尝试使用自动化进行测试;
2、熟悉sqabasic语法;
3、对着文档读代码，尝试调试脚本，跟踪到代码的最底层。
其实最好的学习方式就是实践，去做自动化建设。当有一定基础后，去完成导师交给的自动化建设任务，就是最好的学习方式。后来，我教别人的时候，也是安排实际任务给他做，然后再进行相应的引导。
在我的学习期间，有件事情让我满讨厌的。就是我必须给原部门的主管和测试组人员讲课，然后那些家伙会不停的提问，以检验我的学习效果。虽然这招很bt，但是对个人的成长还是满有利的。假设你学会了一项技能，此时你可能只在第一个层次上，如果你能够把这项技能教会别人，那么你的层次上升了一个档次。
记得当时是20xx年2月初去参加学习的，4月初就应急被调回原测试组了。总共不到两个月的时间，我总共完成了3个模块的自动化建设，第1个模块搞了3个多星期，第2个模块不到2个星期，第3个模块一个星期就搞完了(第3个模块算是友情支援呢，哈哈)。
4月初被调回原测试组后，就一直做救火的工作。差不多5月份的时候才正是开始做我们t项目的自动化。其实也就是把我学习的自动化框架移植过来，做t项目自动化测试。
另我比较遗憾的是，t项目的测试一直都很紧，而自动化测试并没有被推广和充分利用。直到我离职前，测试组为应付测试部自动化考核指标，才得到重视。
这里我谈一下自己对自动化测试的理解。
1、自动化测试用于提高测试效率;
2、自动化测试可以完成一些无法手工完成的测试，例如长时间不间断的测试;
3、自动化虽然能够发现问题，但主要是对继承的功能进行测试，保证以前的老功能。(这个跟项目有关，gui自动化测试比较复杂，如果是嵌入式设备或芯片的自动化测试，对自动化测试的理解可能会不一样)
我在自动化学习期间，表现出来的专业技能和良好的学习能力，得到了同事和主管的认可。鉴于此，在4月中旬的时候，测试组的leader给我安排一个任务，使用excel表格开发一个工具，用于收集和统计记录的数据。要求该工具能够代替手工计算，提升测试效率。任务完成的截至日期是五一。给我安排的时间大概为一周。
该工具的实现方式并不难，就是设计一个excel表格，然后在里面嵌入vba脚本，以宏的'方式代替手工计算。对我来说最大的挑战就是：
1、短时间内学会vba编程;
2、提取需求，设计excel表格的格式，使该工具具有较好的易用性。
当我接到任务后，下班回家就开始到网上搜集关于vba资料。当时我找了一个星期，都没有让我满意的文档。最终只找到一篇国人写的pdf文档，但是那篇pdf文档只是让我初步了解了vba是个什么东东，并不能满足我的实际需求。最终，在写vba脚本期间，我还是参考微软自带的帮助文档搞定的。
本来计划是在四月底的一个星期开展该项任务，但实际上直到4月的最后两天我才有时间。记得当时，我花了一天半的时间与我的客户——也就是我的同事，共同讨论需求，并设计excel表格的格式，让其评审。最终写脚本花费了4月的最后一个下午，以及五一期间的三个下午的时间，总计4个下午的时间，完成该工具的开发。而且我五一期间的工作并没有申报加班，是无偿劳动啊。
其实工具开发完成后，还是有些问题，如：
1、程序崩溃
2、有1/3的功能基本没有被使用
3、自动生成的表格，奇丑无比
20xx年10月份，我开始独立负责m项目的测试工作。m项目是个小项目，大体情况如下：
代码量：大约10k行
开发语言：c#
软件环境：windows ppc 20xx
硬件环境：hp的pda
人力投入：开发3人，测试就我1人
m项目的测试需求分析、测试设计、测试用例编写、测试执行到测试报告，全部由我一个人搞定
20xx年10月～12月中旬这段时间，主要是完成前期的测试分析与设计。12月中旬，就进入了实际的测试阶段，20xx年1月底，软件发布。回顾这4个月的工作，有做的好的，也有做的差的。下面对这些进行总结。
做的比较好的：
1、测试进度把握比较好，在规定时间内，甚至提前完成了测试任务;
2、与开发人员的沟通较好，使问题能够较顺利的解决，基本没有内耗，双方合作愉快;
3、测试的重点把握较好，把很多严重问题，在测试前期就给暴露出来了;
做的不好的，待改进的：
1、前期的测试分析能力较弱，测试规格分析不全，测试用例编写质量不是高。到后期测试时，才发现很多规格没有覆盖到，需要补充测试用例。而且之前写的测试用例与实际测试情况，有些偏差，用例的可用性差，又花了很多时间去修改用例。
2、前期的测试计划制定比较差，实际工作较之计划偏差过大。吴江装饰网反正10月、11月那段时间，m项目的工作是乱七八糟的，还好关键时间点的把握还算到位。
3、测试对象选择上疏忽，导致漏测。m程序是个工具软件，主要用于查询和设置设备的某些参数或配置。我当时只考虑到对所有支持的设备进行遍历，却未考虑到设备上所有单板的遍历。结果技术支持工程师到香港试用该工具时，发现某块叫pm1d的单板无法识别。后续，我们对大部分单板进行了遍历，还发现了很多隐藏的问题。这是一项较大的疏忽。
4、在做内部模拟试验局测试时，对测试环境的选择有较大疏忽，导致漏测。在做内部试验局的时候，我为了偷懒只选择了3个不同设备的组网测试，而没有考虑到大规模组网情况下的测试。后来，技术支持工程师拿m软件到广州试用时，程序的某项功能就不正常了，原因就是大规模组网时，通信数据的传输是多包的，而m程序的底层函数没有对多包的情况进行处理，导致该项功能不正常。当时，在其他实验室是有类似环境的，而我却为了偷懒: (
虽然m项目的测试有很多不足，但是总体情况良好，我对产品的质量有信心: )
四、救火
大概是20xx年7月份时，我们组组长跟我说，要派我到b组去学习3个星期。等我去了b组才发现自己是被派来救火的。来b组支援测试，主要是完成一项测试任务，说具体点，就是把一件事情干600多次，没任何技术含量。我当时真是郁闷坏了: (
虽然心底是比较郁闷，但毕竟也就3个星期，想着忍忍就过去了。
具体的任务很简单：大概有80种板子，每种板子大概有8套软件，用t工具对80多块板子把8套软件都加一次，观察软件加载过程中，业务是否正常，板子加完软件后，运行是否正常。
还有一个也是其他组借调过来的新员工，跟我一起干这件事情。我600多次，他也差不多600次。还好这个家伙，心态很好，做事情也很勤奋。
最初b组给的方案是这样的：先用第1套软件把80多个板子加载一遍，再用第2套，第3套，直到第8套。
开始工作几天，我们就按这种方案执行，但按这种方案执行的效率很差。主要因为实验室常用的板子差不多只有30块，其他的板子都藏在箱子里，而且有些板子b组根本没有，需要到其他项目组去借，这样针对软件版本，对80多块板子进行轮循加载，效率就很低，因为每加一套软件，就要去寻找80多块板子。
当时，我和那个新员工都很愁，按照这种做法，这项任务3个星期根本就无法完成。b组负责带我们的两个员工，也表示比较无奈。
郁闷过的第2天一早，我就直接找b组的老大谈话，“按照你们提供的这种方案，我们在三个星期内根本无法完成任务，而且还有诸多其他困难：1、部分板子是坏的;2、某些板子实验室里根本就没有;3、对设备不熟悉。”
就这样，b组老大把组内相关骨干人员都叫过来开会，重新商讨了一套方案，并要求他们全力支持我们的工作。
开了会后，b组的人就比较支持我们的工作了，启用新的方案后，还提前了1天时间把工作完成: )
这里我体会比较深的是：在做一份工作前，一定要弄清楚这项任务到底要做些什么、要怎么做、要做到什么程度，工作中还要定期汇报工作(基本上以日报、周报的形式，用邮件发送)，如果出现了解决不了的困难，一定要向老大汇报，如果老大也解决不了，那他也不能责怪你无能: )
在辞职前的几个月，有个师弟也是老乡x君，得知我做过自动化项目后，便来向我了解自动化测试相关的情况。
从与x的聊天过程中了解到，他也正在做自动化，他们组测试的产品规模比较大，不过做自动化的只有两个新人，而且是使用一种新的gui测试工具。他在给我讲他们具体工作时，了解到他们的自动化测试非常原始，就是针对一个用例录制一套脚本，几百个测试用例，大概录制几百个脚本，根本没有对公共进行提取，更别提有什么自动化测试框架了。x君与另外一个人，在自动化方面都是新手，没有相关经验，他们不知道这样做会给后期的维护带来多大的麻烦。而且他们主管也不太懂gui测试的自动化，只是每天要他们汇报工作进度，期望在两个月内完成那几百个脚本。
经过我细致询问后，我猜测他们做这项自动化工作，基本上是为了应付部门自动化考核而做的，而并非为了提高测试效率，保证产品质量。
我也可以体谅x君主管的难处：测试组人力本来就紧张，而部门又要考核自动化指标，他只有弄两个人来应付一下部门的考核了。
这样说来，x君和他另外一位同事就是受害者了，被安排做一件这么没意义的事情。对他们我只能表示同情了。
对于这类bt主管吩咐的没啥意义的事情，我的体会就是能推掉不做就不做，如果实在推不掉，就完全按照他的意思做，他要怎么做就怎么做，要做成什么样就做成什么样。实在搞郁闷了就老板炒鱿鱼吧。
六、其他
记得刚进公司那一阵，对我们新员工有这样那样的培训，估计转正前至少被培训了20门课吧。具体讲的都是产品知识、测试技能、编程方面的东东。那些讲课的老师水平也参差不齐，ppt写的水准也有好有坏。总体感觉就是那些培训是在浪费时间，如果自己看这些资料效果都要好很多。
在转正前，作为新员工要给部门的“老”员工讲课，讲自己所学习过的知识，然后下面的“老”员工会发狂了似的问你问题。现在我感觉这种方式真的是一种非常好的检验方法，不但检验了你的学习情况还锻炼了你讲解ppt的能力。
通过这种方式，我觉得自己在很多方面有提高：
1、写ppt的水平。后续工作中，写ppt汇报工作，做的是又快，又漂亮。
2、沟通能力。最初别人问我一个问题，我还没完全理解他的意图，就以自己的理解，淅沥哗啦的说了一堆别人不想知道的东东，搞得别人一头雾水。此后，别人每问我一个问题，我都会先把他的意图或意思搞搞清楚了，确认后，再以最精练的语言来回答他的问题。
3、懂就是懂，不懂就别乱说。记得最早“老”员工问我一个我自己不是很懂的问题，我通常是按自己的理解方式，跟他胡吹一通。结果他再一细问，我就傻了。知道就知道，不知道就别乱说，这点很重要，尤其是在参加面试的时候，如果自己不是很动，别人一问你就会露馅。
从八月份入职至今,已一年过去了，回顾自己这段时间在xx公司所走过的路，所经历的事情，没有太多的感慨，没有太多的惊喜，却多了一份镇定，多了一份从容。
回想入职初，在xx月份，从开始第一周熟悉工作环境，第二周便参与煤矿安全生产管理系统的相关文档设计工作，期间在项目组各位同事的指导、安排下，进行了系统的软件开发委托合同书及系统功能模块设计说明文档的编写，也借此过程学习煤矿生产业务。
在xx月份，便正式参与了管理软件功能模块的设计工作，在张工的指导、讲解下初次尝试完成了管理软件的维护子系统的功能模块设计；在九月中旬跟随公司施工人员在xx一号矿进行业务调研，从而在我们自己的管理系统中，取其长、补其短，也借此机会了解实际的煤矿生产情况，加深对煤矿产业业务流程的理解；在九月底便根据张工的指导开始工程技术文档子系统的功能模块设计。
xx月份，在张工张工的指导下，进行了物资管理子系统的功能模块设计，并就设计的正确性、合理性分别同张工张工及何工进行讨论；到十月中旬管理软件的各子系统功能模块基本全部设计完成；十月底，根据各子系统模块设计搜集系统数据，建立初步的数据字典及概念模型，为后期数据库设计做准备。
xx月份的工作以整理系统业务关系与业务流为主，但由于业务关系图的表现形式不够合理，不足以清晰、明了得表现出各层次关系，导致工作多走了几个环节，好在张工张工及时发现问题，并多次向我指导、讲解，最终决定以列表结合流程图形式搜集、汇总系统所有子模块的业务动作、涉及人员及联系模块，为后面工作的展开提供依据。
xx围绕两个工作展开，
一是系统业务描述文档的设计编写，因为该文档是日后编程人员了解煤矿生产业务、系统功能及数据库设计的主要依据，张工张工也多次强调，文档的设计务必从读者角度考虑问题，因此最终设计由简单到复杂，由整体到具体，各层次尽量做到衔接紧密，易于理解；
另一项工作是针对已完成的关系列表、系统功能模块设计的业务合理性、正确性和张工张工逐条讨论，并将设计中出现的问题逐条记录在问题跟踪文档中。月底的工作便是根据问题跟踪文档对模块设计进行修改、完善。
在公司领导的带领下，通过项目组所有成员的不懈努力，在xx月份系统所有功能模块设计完成，在xx月份系统所有业务流程整理完成，在xx月份，对各功能模块设计及业务流的初次审查、整改工作已经完成，现在已开始进行项目组内对各功能模块设计及业务流的审查工作。
在入职初期，因为之前很少接触生产类软件，一时不知从何入手，好在项目组成员多次向我讲解，加上自己也通过网络查找相关文档，认真阅读相关材料、思考业务处理过程，最终在一个月内便对煤矿整个生产管理业务有了较为系统的认识。之后在张工张工的指导下，完成了管理软件初始化子系统、工程技术文档管理子系统、物资管理子系统的详细功能模块设计和业务处理设计，以及整个系统的业务整理工作。因为张工张工多次强调前期的业务及功能模块的设计直接关系到整个项目最终的成败，一定要做到设计正确、准确、完整，因此在每个子模块的设计中，先把握总体方向，确保设计正确，再搜集大量业务材料、对比其它类似软件处理方式、结合煤矿实际生产情况、思考业务处理流程确保设计准确，最后再将设计放到整个业务系统中，反复检验、审查，确保设计完整。回顾这一段时间的工作,我基本完成了本职工作，这与领导的支持和各位同事的配合、帮助是分不开的，但同时我也清楚得认识到自己还有很多不足，也从中获得不少经验、教训，总结为以下几点，
1、做事前准备、计划是很有必要的。
这一点在入职第一周业务学习及近期搭建各模块业务关系工作中就体会特别深，正是磨刀不误砍柴工，做好准备、计划对之后的工作能起到事半功倍的效果。
2、工作要脚踏实地、一步一步，切不可太过心急。
整个软件的设计从最开始的业务调查、模块框架设计、业务流程设计到具体软件开发设计，每个环节都是建立在前一个环节的基础上，每个环节上的失误都会影响到之后所有环节。
3、学会从整体看问题。
这一点在入职初期的业务流程学习中就感受很深，从整体看问题，从主业务流程入手，理解更容易，学习得也更快，在整个工作过程中大的方向也不会错。
4、要学会适当的思维转变。
之前的软件开发工作主要是编码工作，所考虑的问题也只局限于技术方面，但在系统业务及功能模块设计工作中，一定要考虑到整个煤矿产业的业务流程和客户群的操作习惯。
5、与同事的交流要及时要充分，尤其是项目组内成员。
及时充分的交流能快速解决疑惑、能使整个工作衔接更紧密、能使问题考虑更周全。充分的交流能保证工作的质量，及时的交流能提高工作的效率。
6、在系统设计过程中要学会从客户角度考虑问题。
软件良好的客户体验是衡量软件质量的重要标准，因此在软件设计过程中一定要考虑使用软件的客户范围、客户的操作习惯和软件的易操作性。
7、处理问题一定要以公司利益为重，坚持立场、把握好原则。
公司项目部成员对xx1号矿项目的成功实施便证明这一点；另外在集控平台开发过程中，何工也是基于这一点，多次对系统功能设计提出更高要求，以使系统功能更加完善、可操作性更强。
8、要学会思考问题、分析问题、处理问题，学会分解问题，把一个大的问题分解成若干个小问题，再将各小问题放到整体考虑其合理性。
在整理系统业务流程和搭建模块间业务关系工作中，就因为表现形式不够清晰、合理，做了不少重复工作。最终还是在张工的指导下，以“总—分—总”的形式解释业务关系，完成了业务详细说明书。
9、不要局限于固定模式，要学会创新。
在系统功能设计及系统业务整理工作中，张工多次强调这一点，因为只有这样，产品质量才能提高、自己的能力也会有较大提升。通过近半年来参与对管理软件的设计工作及与工程施工、项目发展工作的接触，自己成长不少，当然更多的成长集中在技术方面—软件前期的业务设计，总结为以下几点，
1、已掌握整个煤矿管理的业务处理及流程。
2、掌握了软件开发前期的整个软件设计流程。
3、学会如何进行软件业务及功能模块的详细设计。
4、学会如何发现问题、思考问题、解决问题。
在管理方面，接触不多，主要集中在项目组对集控平台开发的监管过程，总结为以下几点，
1、时刻掌握项目进度情况，进度一旦出现状况要及时作出反应
2、处理问题一定要以公司利益为重，坚持立场、把握好原则。
3、与外包人员要多交流多沟通，包括业务理解和完成情况。最后，通过在公司近半年来的工作生活，提一些个人的想法，
1、公司员工交流不够多，尤其是不同部门间的工作交流，而这种交流能使各部门的工作衔接更紧密，工作效率更高。
2、技术人员接触其他相关技术的机会不多，不过这一点公司正在改善，plc讲座也即将进行。
3、在准备项目经理考试期间，如果公司能统一每周提供几个小时供大家学习、讨论、交流，效果可能会更好些。
4、午饭时间太紧，员工中午休息时间太紧，一定程度上影响下午的工作效率。
以上都是个人角度的一些看法，考虑不合理之处还望领导及各位同事批评指正。
xx年已经过去，崭新的xx年来临了，在新的一年里，工作上，生活上，我们都站在了新的一个工作起点，要开始新的一轮工作，我也在此感谢领导和各位同事的支持和帮助，我将在新的一年里继续努力，不断提高自己的业务及专业水平，虚心向大家学习，为xx公司为长风的发展尽自己的力量。
先自我简介一下，本人从事asp。net开发进一年，09届毕业生，xx年11月开始上班，之前做asp，xx年2月后开始做asp。net，由于公司转型，现在带十几个人在一起搞asp。net开发，主要是关于准金融行业的行业管理软件。年度总结在会议上也写了，但仅限于对于工作总结及xx年工作计划，自我总结较少，因此今天专门做下自我的年度总结，主要从技术、管理、人生上面谈谈这一年的收获，前辈路过欢迎多多指正。
技术
我在学校里学的是电气自动化，程序基础仅限于c基础课程的一些知识，后来由vb、html转向asp，在asp上花费了不少时间，对asp比较熟悉，后来由于公司业务需要，将开发平台转向asp。net，开始对asp。net不是很感冒，以为就是asp的一点扩展（那时还不知道三层架构，数据数据访问全在页面里——！），后来招来几个北大青鸟的过来终于意识到asp。net的强大之处，经过个人的努力已经逐步掌握了asp。net，现在层次上只能讲个人觉得是入门而已，原因是多方面的，待会儿会讲到。
相信从面向过程转向面向对象的同学都有一种感觉：面向对象开始真的有点别扭，涉及到属性，尤其是类之间的.各种关系，那时老想用面向过程传递参数多方面啊。于是老在想对象这种东西，从概念中跳中来，以自己的方式去理解才逐渐体会到页面对象的精华来，分层次展现、分级别访问、封装对象之间各种关系逐渐真正理解了，尤其是对象之间的关系，如对象a与对象b两者之间的关系，有些需要完全公开，有些需要隐藏，有些需要通过第三方传递，有些需要给自己的下级可见，有些需要让下级去完成具体操作——这不是现实的实际模型吗？应该这么理解，面向对象来源于现实，它不是一种凭空空想出来的理论，这些对象之间的关系可以将其还原为父子、夫妻、领导下属、同事、朋友之间的关系。相比之下，页面过程往往像是一股脑全部推给用户使用，其中的数据与数据访问方法层次不清晰，在模拟现实上它与面向对象相比更易于入门理解，实质上难于准确直接地表述。
面向对象上另一方面是它的设计模式，在之前的面向过程中对这个设计模式并没有清晰地提出来，面向过程优秀的代码要求高内聚低耦合，从个人的理解上，这仅是对软件开发方法“技”上理论总结；设计模式是达到了“道”的层次，因为它从更大的方向、更抽象的层次来去表述具体的代码模块之间的关系，可以认为设计模式是完全从实际的应用来不断总结得来的经验，之间并没有这种术语，但相信前人肯定也使用到这种思想，它从实际应用于来，当然要应用于实际工作中，认真思考不断总结每个人都会有自己的“设计模式”，可以借鉴前人的思想来去提升自己，不可去为“设计模式”而设计模式。
具体到asp。net的实现模型中，真正理解它的机制与方法也就不难理解，记住b/s中离不开post或get，所有的autopostback、selectedindexchanged……都是去调用form传值，加上runat=server的服务器控件打开它生成的源文件也是普通的html标签，微软的让软件开发更容易的思路是很好的，时代在前进，很多年前你使用c写出mis证明你很牛，很多年之后你不在使用c去写“学生管理系统”、“图书馆管理系统”那只能说明你的脑子少一根筋，开发语言都有长处与不足的地方，因为它们适用的场合不同，类似不能拿匕首去跟炮弹比，也不能拿c与php比，程序员都有一种偏执的心理，但一点要记住，你面对的用户才有最终发言权，程序能不能满足需要，易用性、稳定性、成本才是应当首先放到重要位置来去谈的。
管理
最开始担任管理一职时开发团队加我在内只有四个人，那时只是抱着接受挑战的心理去做管理，加上我本人比较重感情，团队之间关系相处都不错，但严重的问题逐渐显露出来：工作的随意性、团队精神薄弱、工作方式蛮干，印象深刻的是有几个开始承诺项目不能完工，于是最后天天加班，一直做到早上6点，睡一会7点半接着上班，几个同事都是年龄差不多的小伙子，干劲十足。后来随着时间的推进，问题越来越摆在眼前：项目迟迟不能完工，又由于公司待遇方面让新员工感觉不值得，于是形成了老板抱怨员工也抱怨的状况，我在中间两点都要去“消火”，这期间是我们部门相对最累的时间但也是相对感觉最充实的时候，后来，之前的员工跟我说“再也找不到那种感觉了”，这是我能想像的。这期间主要是老总对我十分信任，工作上主要是管理方法上对我指点了不少。后来我逐步体会到，管理应该是“大家定规则去遵守”，而不应该是“人管人”。
人管人很容易陷入一个误区：
领导去时时刻刻关注每个员工，这样最后往往后造成员工对领导的敷衍了事，管理松了员工会责任下下降，管理紧了造成员工与领导关系紧张，另一方面领导时间精力有限必然耗费大量的精力在日常的监督中而不能投入到全局的管理中。
于是“定制度—定分工—定进度”，明确日常所有的规章制度，这期间除了公司主要的工作规章制度外其他的日常工作纪律、日常管理等规章制度都是我本人制订，然后征求大家意见最后去贯彻执行。中间也遇到了不少问题，比如开始我们内部是允许使用qq的，后来员工用qq闲聊的时间增多，大大影响了工作效率，最后决心禁止，开始阻力较大（貌似程序员都喜欢挂上几个qq去到群里搞个群主，虽然群里大多都是菜鸟），最后多次开会，逐个谈话，阐明道理，形势逐渐好转。
项目分工上针对技术水平明确分工，制订项目开发计划，由于开始技术都不是很成熟，不少时间我这边强势要求，使用野蛮方法，完不成加班——我陪着加班，这段时间能感觉到员工对我稍有怨言但总体还是认可的。
这期间公司新招人员，人员的增多更使我意识到团队管理的重要性，这期间版本控制、编码规范、文档管理、bug管理等诸多问题都得到一一解决，技术水平上主要是我个人利用空余时间学习新知识充电，然后展开各种培训，主要是photoshop、css、js、sql等方面，培训一方面提升了员工的技术水平，一方面我本人在学习培训的过程中得到的最多，因为这个时候个人要求去思考的会，加上我本人对技术兴趣比较深厚，所以后期工作慢慢踏入良性循环。
待遇低、条件艰苦、工作时间长、工作压力大是团队中最大的难题，这方面公司在某些方面决策层有着严重的错误思想，造成技术人员对公司埋怨增多，在这方面我本人只能以劝架婆的身价去安慰身边的兄弟，因为我明白现在公司的问题与当前中国软件行业的通病一样，盲目追求利益最大化，不求质量，但求速度，整个社会风气造成软件行业良莠不齐发展，整个中国三四个人的开发团队组成的公司数不胜数，整个程序员阶层生存状况可想而知，疯狂加班、代码质量低下、维护成本大、稳定性差、用户体验差……。当然我们本身不能去逃避这个现状，对于个人来讲任何假大空的口号都是没有意义的，程序员作为技术人员最重要的是心态，以良好的心态去面对各种问题，发现问题、解决问题，发现问题抱怨是解决不了问题的（“it民工”是我个人认为it人最没有正确的自我定位的一个称谓，试想一个人连自己都看不起自己的职业，他能做好自己的工作吗？），最主要是解决问题。
我在面试员工时反复提到的三点是；工作态度、发展潜力、工作能力，由前向后排序，心态最重要，大公司大家都想削尖脑袋往里挤，但名额有限，所以广大的程序员同志绝大多数都集中在二流三流四流的软件公司，这个时候更应该做好个人职业定位。以我个人的经验，新员工选择一家公司往往最看重工资待遇跟发展潜力，程序员是一种不可以混日子的职业，工作能力很重要，但不是最主要的，工作态度是最重要的，工作态度往往跟个人的思想认识还有职业所在的环境有关，我个人的体会是绝不能太过于情绪化，情绪化无论是对工作还是对个人的发展都是不利的，就是说哪怕是明天你要辞职，你今天都要把今天要做的事情认真用心做好。
对于工作责任心不够的员工是尤其值得关注的，他们往往自我意识过于强烈，追求以自我为中心，很多时候伴随着工作得不到认可、工作感觉不充实不开心，我会主动找他谈话，我认识：你管理的是一个实实在在的人，他不是一台任你摆布的机器，人会有情绪往往是有心结，找到原因，多加开导，用心去关心每个成员。对于实在不适合在本团队发展的员工要做好最坏打算。程序员这个职业与现在的大学生具有一致的特征，一个是从天之骄子沦为多余人，一个是从高智商人士成为今天中国通行的”it民工“。另一方面是程序员往往年龄集中在20—25之间的男性中，情绪化、失落感、心理不成熟等一系列问题都会出现。但这个阶段的人往往也最易沟通，可塑性也较强，适当的引导、合理的方式会比野蛮的管理效果强上百倍。
工作时间：8:00-18:00
电子邮件
675289112@qq.com
