适用场景:银行系统测试总结、金融软件测试总结、项目实施总结
演讲要点:完成多个银行系统测试任务、分析测试流程优化方法、提出测试管理改进建议
行文逻辑:跟进项目测试→制定测试计划→协调测试资源→总结测试经验→优化测试流程
回顾这一年里的工作收获颇多。年初一直在参与中行对公系统的测试工作,中国银行对公代客资金管理系统已2月份对公系统顺利投产。紧接着春节后又开始了xx银行的X-FUND2.0项目的全程介入测试。跟随项目组一同到北京现场开发测试,以及后期配合用户的压力测试,项目投产内部演练和支持等工作。目前中信X-FUNDS2.0系统也已经投产完毕。
8月份后回到公司,主要从事公司内部集成测试和系统测试工作,主要测试系统包括福建分行日积月累系统、SGE与K+接口管理系统、xx银行利率衍生品交易系统、浦发银行离岸交易系统、中国银行新一代做市商系统等。目前正忙于新一代做市商系统测试工作,该项目计划年底投产。
补丁测试方面主要有部分辖内对公系统补丁测试、部分中行对公代客管理系统补丁测试、澳门资金管理系统补丁测试、中信X-FUNDS2.0系统补丁测试等。
压力测试方面主要有中信X-FUNDS2.0系统、中信外汇电子交易系统压力测试、统一登录系统压力、浦发离岸系统压力、新一代做市商系统压力测试等。
从年初的中行对公项目到xx银行X-FUNDS2.0项目再到中行新一代做市商项目。一个个项目完成测试任务并顺利投产或进行中。
从本年度内主要项目的测试及跟进客户测试方面经验教训进行总结,以便更好的提高项目介入测试的质量和完善自己的能力与不足之处。
一、测试组内部要有计划。介入项目测试以后,理论上讲是应该配合项目组的测试工作。但个人认为这样测试组方面工作会比较被动,跟随项目组指定的测试并不能比较全面的覆盖到系统全部功能或者绝大多数功能。如更新一块,就让你测一块,这样无形中就会疏漏其他模块。测试组内部可以根据项目整体工作的安排情况也应该有自己的测试计划,即完整测试轮次的计划,这样能更好的把握系统整体功能情况。这部分工作在进驻客户现场测试时应与项目组长沟通,明确每日工作流程,如版本更新时间约定、内部更新测试安排以及配合指导用户测试等工作。
二、项目的测试进度控制。主要是按照项目计划进行的,按照项目组计划要求完成测试任务、提交测试类相关文档,包括制定内部测试计划、测试案例的"完善、执行测试、缺陷跟踪以及BUG回归测试等。协调项目的内部测试工作,配合项目工作,共同保证项目质量。项目测试的问题跟踪及处理采用每日进行修改问题回归测试工作,每日同步更新问题跟踪单的模式,按照规划时间完成系统更新测试等。
三、要加强学习和沟通。在进驻客户现场测试后,测试人员的工作要配合项目组,也要指导和协调客户测试。项目组内部共同探讨解决问题的方法,向各模块负责人学习模块功能处理方式,向业务人员了解系统中涉及的业务知识点,两者结合起来进行模块功能测试。与客户接触吸收新的业务知识,积累测试方面必须的业务知识点,这些都做公司系统测试应有的测试基础,或者说银行金融行业项目测试工作的素养。也可以进步一提高与客户、与项目组内的沟通能力和协调能力。多参考客户测试的测试案例及测试过程中提出的问题,也能为自己的测试工作打下一个好的基础。
四、善于总结和吸收项目经验教训。总结回顾以往的项目测试经验可以更好的指导以后的测试工作,也会提高系统缺陷和业务处理流程方面不合理情况的发现率。测试出来的问题与项目组沟通也会比较容易.。鉴于以前的项目经验,也可以向项目组提出了一些完善性意见和功能实现的处理方式。
五、个人得失及不足。作为几次项目测试的负责人,对于日常的测试流程、测试任务分配、测试执行、缺陷跟踪、协调内部测试及协调客户测试方面能力均得到了进一步提高,理清了项目整个过程中测试小组的工作过程以及后期的项目移交工作。同时也对系统相应的业务知识有了更进一步认知。相关业务知识方面还需要进一步加强,测试技能及测试管理方面还需要进一步完善学习。更好的吸收项目经验,做好以后的补丁测试工作及其他项目的测试工作。
项目测试中,维护部门配合介入的测试工作比较难分配及管理。维护人员并不是很积极从事项目的测试工作,且分配的任务也不情愿去完成。在中信X-FUNDS2.0项目和新一代做市商项目组中都能明显体现出来。他们多是认为项目组的测试过程中的工作不属于自己的职责范围,认为自己只是一个简单的配合过程,要求加班时间要么不来,要么就做其他无关工作的事情。项目组也认为维护人员只是做自己的维护工作,抱怨时只会对测试人员。项目测试工作量也比较繁重,频繁的超负荷工作,给测试人员也造成比较大的压力。
公司是否可以通过下放部分考核比例,由测试负责人给组内测试人员和维护人员的工作进行考核打分,来约束和督促内部测试工作的合理进行。
公司是否应该考虑制定比较合理项目开发和测试周期计划及人员分配比例,切实减少超负荷工作带来的压力。
公司的业务逐年扩展,测试部门人员缺口较大,主要测试工作基本都落在了部门几个人身上,望明年公司能合理补充人员,并能在薪资待遇方面能有比较合理的增长。
适用场景:项目管理总结、技术实施总结、团队优化总结
演讲要点:需求分析改进、设计流程优化、编码规范提升
行文逻辑:明确需求→优化设计→规范编码→完善测试→协调实施
转眼20xx已经结束,下面我就把我自己到公司这一年的一些感触、体会及工作情况给领导及各位同事汇报一下:
我刚开始第一次负责做定制开发的一个项目,功能的实现相对来说比较简单,但是功能多,繁琐,而且当时没有项目开发的整体经验,缺乏项目全局观,直接开始编码实现功能,在项目编码过程中,由于客户不断的增加需求,改动,经历了近3个月时间,才完工;对我来说很失败;不过这个项目对于我刚负责项目开发的整体经验来说,算是一次教训、也算是一次收获,通过这个项目及开发人员提出的意见,进行改进,并且在后面的项目开发过程中初见成效,开发周期逐渐缩短、需求改动逐渐减少、开发出的产品起码达到90%的要求;到目前为止,团队的技术水平、沟通能力及团队协作能力都有所提高、有所改善,但是整个项目的开发从开始到结束存在的问题依然不少:
1、项目需求
需求是一个项目的来源,后续所有工作都是围绕需求展开,需求中哪怕有一点的不明确,都会影响项目的总体进度及项目质量。
2、分析设计
软件最后的操作便捷性、功能扩展性、界面友好性都取决于设计人员对需求的理解、模块框架的设计、业务流程的设计、数据库表的设计,每个环节都是建立在前一个环节的基础上,每个环节上的失误都会影响到之后所有环节,项目组无专业软件设计人员,软件的架构、逻辑设计、界面设计,都是凭对客户需求的理解设计的,导致软件开发出来后逻辑处理经常改动,软件操作不是很便捷;而数据表的建立及表之间的关系建立主要取决于各项目组人员对需求的理解程度,每个人对需求理解程度不一,直接导致数据表建立时的不规则,不专业,从而产生软件功能上的问题
3、编码
第一,开发人员编码的统一性较以前有了很大的改善,但是还是存在个别人员不按统一规则编码的现象;
第二,开发人员普遍存在一些简单的问题就是,比如该判断的不判断、点保存没有任何提示等小问题,这些问题可以说不是技术问题,而是作为一个程序员最起码的工作态度,认不认真,细不细心;
第三,人员技术水平差距较大,这种现象会直接影响编码阶段的进度;
第四,项目编码过程中的积极性,对于开发人员来说也就是工作积极性;
4、测试
软件测试决定了软件是否是一个已开发完成的软件,还是一个半成品;无专业测试人员,只能用软件测试方法中最简单的排除法,大家可想而知,这种排除法只能排除当时输入的数据,所以发现bug问题有限,这样一个半成品软件客户在使用的时候问题可想而知。
5、软件实施
由于技术部人员有限,所以经常出现各部门对技术人员的工作协调问题,导致软件不能按时实施、项目开发不能按进度完工、需求不能按计划完成等一系列问题。
以上问题都是个人角度去衡量的,考虑不合理之处还望领导及各位同事批评指正。
适用场景:教学评估总结、项目管理总结、团队协作总结
演讲要点:项目开发计划编制、测试计划制定实施、团队协作问题反思
行文逻辑:规划项目目标→制定开发计划→执行测试方案→优化团队协作
课程设计
题 目:课程设计个人总结 学生姓名:
学 院:信息工程学院
系 别:计算机系
专 业:软件工程
班 级:
指导教师:
20XX年7月21日
关于本次课设的个人总结
本次课程设计我主要负责的是项目开发计划和测试计划两个文档的编写工作。历时两个星期终于顺利完成。辛苦虽然是不可避免,但收获还是令人尤其欣慰。
其中项目开发计划主要对项目的整体实施提前做一个详细的规划。项目开发计划主要在于协调和沟通,在规定的时间内尽可能全面收集项目信息。项目信息收集要讲究充分的、有效率的沟通,并要和小组成员达成共识。
编制项目计划主要经历了如下的过程。包括、确定项目的应交付成果。这里的项目的应交付成果不仅是指项目的最终产品,也包括项目的中间产品;任务分解:从项目目标开始,从上到下,层层分解,确定实现项目目标必须要做的各项工作,并画出完整的工作分解结构图。在资源独立的假设前提下确定各个任务之间的相互依赖关系,以确定各个任务开始和结束时间的先后顺序;获得项目各工作任务之间动态的工作流程。确定每个任务所需的时间,即根据经验或应用相关方法给任务需要耗费的时间;确定每个任务所需的人力资源要求,如需要什么技术、技能、知识、经验、熟练程度等等。确定项目团队成员可以支配的时间,即每个项目成员具体花在项目中的确切时间;确定每个项目团队成员的角色构成、职责、相互关系、沟通方式。确定管理工作,管理工作是贯穿项目生命周期的,如项目管理、项目会议等、编写阶段报告。项目团队成员之间的沟通时间、项目团队成员和其他项目干系人之间的沟通时间也比较容易被忽视,而沟通时间也是比较不容易固定地量化和日程化。但这些工作在计划中都应当充分地被考虑进去,再回师项目计划更加合理,更有效地减少因为计划的不合理而导致的项目进度延期。考虑项目的费用预算、可能的风险分析及其对策。
另一个就是测试计划了。软件测试就是利用测试工具按照测试方案和流程对产品进行功能和性能测试,甚至根据需要编写不同的测试工具,设计和维护测试系统,对测试方案可能出现的问题进行分析和评估。执行测试用例后,需要跟踪故障,以确保开发的`产品适合需求。编写测试计划是为了项目经理能够根据测试计划做宏观调控,进行相应的资源配置等。同时测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作,便于其他人员了解测试人员的工作内容,进行有关配合工作。本次我编写的测试计划分别包含了黑盒白盒测试、单元测试、集成测试、确认测试、系统测试和验收测试。应详细介绍了每个测试的方法和过程。
通过这次测试计划的编写过程和上网查资料了解到,每当测试一个程序时,人们总希望为程序增加一些价值。利用测试来增加程序的价值,是指通过测试,找出并修改尽可能多的程序缺陷,从而提高程序的可靠性或质量。
因此,不要只是为了证明程序能够正确运行而去测试程序。相反,应该一开始就假设程序中隐藏着错误,然后测试程序,发现尽可能多的错误。
事实上,如果把测试目标定位于要证明程序中没有缺陷,那么就会在潜意识中倾向于实现这个目标。也就是说,测试人员会倾向于挑选那些使程序失效的可能性较小的测试数据。另一方面,如果把测试目标定位于要证明程序中存在缺陷,那么就会选择一些容易发现程序缺陷的测试数据。而后一种态度会比前者给程序增加更多的价值。
因此,大多数测试专业人员都赞同Myers对测试的定义:“测试是为发现错误而执行程序的过程。”这个定义意味着程序测试的过程是具有破坏性的,甚至是一个“施虐”过程。开发人员可能不愿意这么做,因为人们总是倾向于建设而不是破坏。这个定义还暗示了对于一个特定的程序,应该如何设计测试用例(测试数据)、哪些人应该而哪些人又不应该执行测试。
事实上,如果在测试某个程序段时发现了可以纠正的缺陷,或者测试最终确定在没有其他缺陷,则应将这次合理设计并得到有效执行的测试称作是“成功的”。而所谓“不成功的”测试,仅指未能适当地对程序进行检查,未能找出程序中潜藏缺陷的测试。因为软件中不可能没有缺陷,没有找出它们,当然测试是“不成功的”。
“软件测试就是证明软件不存在错误的过程”。对几乎所有的程序而言,甚至是非常小的程序,这个目标实际上是无法达到的。因为即使程序完全实现预期要求,仍可能包含有缺陷。也就是说,如果程序不按要求工作,它显然有缺陷,但如果程序做了不要它做的事,它也有缺陷。
心理学研究告诉我们,当人们在干一件已经知道是不合适的或不可能做到的事时,往往他们的表现就相当糟糕。把程序测试定义为在程序中找出错误的过程,就使测试成了可以做到的任务,从而克服了心理上存在的问题。虽然这看起来像是个微妙的文字游戏,但对成功地进行软件测试有很大的影响。
总之,软件测试更适宜被视为试图发现程序中错误(假设其存在)的破
坏性的过程。一个成功的测试,通过诱发程序发生错误,可以在这个方向上促进软件质量的改进。当然最终人们还是要通过软件测试来建立某种程度的信心:软件做了其应该做的,而没有做其不应该做的。
通过以前课程的了解,意识到测试的重要性。在发布新产品之前做好测试,提高软件产品质量,减少漏洞,是预防木马攻击的根本途径。别人的经验证明,软件的质量不仅体现在程序的正确性上,它和开始编码以前所做的系统需求分析,软件设计密切相关。许多软件使用中出现的错误,未必是编程人员在编码阶段造成的,反而在程序设计,甚至在需求分析时就埋下了祸因。这时,对软件的错误纠正,就必须追溯到软件开发的最初阶段。由此看出了软件测试阶段的重要性。为了保证软件的质量,专案管理就应该着眼于整个软件生存期,特别是在开发阶段的系统分析。所以软件测试的概念和实施范围必需包括在整个开发各阶段的复查、评估和检测。
整个编写计划的过程紧张而又快乐,我像一个真正的项目开发人员一样,找到了自己的位置,找到了感觉。把全部的心血浇筑到键盘上,眼看着文档想豆芽一样生长,我心满意足。做项目的过程中曝露很问题,不过这是好事,有挫折才会成长。
可以说做项目的过程是一个艰辛的过程,很多同学,特别是组长为了这个项目经常加班。回到宿舍之后还要拖着疲惫的身体继续工作在电脑前,为了项目的如期完成而努力......在完成了项目之后,有一种如释重负的感觉。但我相信每一位做了项目的同学,一定能够对软件开发的过程有个更深的了解。软件开发过程最重要的是团队精神,这是小组全体成员的心声,在整个项目文档制作过程中,没有谁能够真正一个人走下去,做项目如此,我们每个人的生活又何尝不是如此,谁能真正独立于社会生活呢?项目团队只是我们社会生活的一个缩影,认识到这一点,就不难理解为什么项目开发需要优秀的团队,需要良好的团队精神。
适用场景:项目经验总结报告、职业发展评估材料、技术能力分析报告
演讲要点:方案设计优化改进、需求分析能力提升、技术方向学习规划
行文逻辑:梳理需求→优化方案→提升能力→学习新技术
一、职业成长回顾
还没有来得及揣摩自己在这一年中的所有得失,20xx年已经领近尾声,细细回首这一年走过的路,虽然没有轰轰烈烈的成绩和战果,但是也经历了一些不平凡的考验和磨砺。我想,20xx年是我工作旅程中的转折一年,在这一年中,我在自己的岗位上迎来了更多的历练和思考。我想,这是喜悦和汗水并存的一年,也是充满了机遇和挑战的一年。
来到已经一年光景,作为一名项目工程售前的技术工程师,承蒙公司领导与部门同事的批评指导,在履行自己职责的同时,也逐渐看到了自己距离优秀员工所具备的全面素质要求还有一段需要努力弥补和完善的差距。空闲的时候我也时常扪心自问,是否拥有足够的资格去享受”售前工程师”这样责任重大的称谓?
自从担任公司项目工程售前技术工程师以来,我的主要工作是为行业部门以及其他业务部门的同事编写项目设计方案、项目施工组织方案,以及就公司现有资源产品整合起来编写解决方案。记得过去一年最开始独立接受项目派单时,我几乎不太能够理解项目售前的含义,更不了解应该如何去把项目售前的工作开展实施,而是过多的依赖于抄袭现场的方案,在一些项目关键点部分处理得不够理想,过于理论化,导致与实际脱节。通过几次不太成功的案例锻炼之后,慢慢的我也开始形成一套适用于自己成长的思维模式,并摸索出一些相似领域、固定产品的处理办法。但是回过头来看,那段时期的方案编写也存在许多的不足,体现在对于项目建设的需求经常只顾眼前的形势直奔主题,阐述完功能产品的适用性,能够如何满足客户需求即可,但是却忽略了未来客户发展所带来的变化与扩展,对项目的把握不够全面,毕竟系统集成涉及的领域众多,涵盖的技术面较广,这种着眼现在直奔主题的处理方式也折射出了自己知识面狭小的事实。
好在公司的领导及同事通过单独技术指导以及对整个部门进行的项目经验分享指导,也让我逐渐明白在进行系统集成项目时宏观了解,全局设计的重要,对用户的需求必须要深入的分析,了解客户的企业规模、事务处理流程以及发展规划之后,从全局的角度来进行方案设计,再突出眼前的局部建设构想,这样才能真正把系统集成方案写好,才能真正让客户满意,而我也必须在具备这样全局把控的思维能力,再加上知识的不断积累,才能成长为一名合格的售前工程师。
二、工作开展回顾
在过去的一年,我对涉足不同行业的系统集成需求也进行了一些回顾总结,其中视频监控项目与网络项目占到了所处理案件的70%,在这些项目中,我所要承担的任务主要包括:项目需求了解、项目设计方案编写、项目跟踪等。而相对来说,项目方案设计又占到了很高的精力付出比例,但是如何提供解决方案完成工作,亦经历了两个时期的成长。
第一阶段:
从产品到方案。将公司的产品资料(如海康威视、华为等常用设备)修改成针对用户的解决方案,这一类售前支持不在少数,处于对公司内部代理的产品比较熟悉,再加上有一定的技术功底,所以这个时期在编写方案的时候从完成速度上来说比较快速,但不能站在客户价值角度来理解产品。
第二阶段:
从需求到方案。通过总结问题以及对项目的不断理解,有了自己的知识体系和工作方法,能站在管理咨询的角度采用各种方法去了解客户业务、分析用户需求,并提供解决方案。
三、个人职业展望
通过这一年时间的摸索与观察,对于现在各大行业客户,越来越不满足于单一产品的建设需要,他们往往希望单位或企业内部的各个应用子系统能够兼容整合,并且所有的管理能够在统一的平台下进行。也就是说,对于未来客户系统集成需求我们可以理解或者影响客户往应用系统集成方向发展,而不是单一的提供产品集成,在激烈的行业竞争中,我们需要提供客户耳目一新的亮点方案。
在学习交流中我发现,数据集中与云计算将是未来发展的技术方向,所谓数据集中,就是把企业所有日常办公产生的数据集中在机房管理端,确保数据的安全有效管理,杜绝一些潜在或已知的泄密危险;而云计算通俗来说既是虚拟化服务,包括应用虚拟化、桌面虚拟化和服务器虚拟化,这样的技术发展将越来越降低对客户终端的硬件要求,转而提升系统应用的灵活性和高可用性。
除了对技术方面的发展追求,在职业规划中我也有一些为自己客观定位的要求。在过去的工作开展中,接受客户案件的时候,我想自己可能过多的是处在一种被动的状态下,按照客户提出的需求进行分析,了解客户一时期内的发展状况,然后提出可行的办法。但是我想这样远不能够树立自己在客户心目中理想方案解决者的形象地位,我更倾向于为客户树立一种可靠可信的咨询师的身份角色。不单单对客户的需求进行分析,还要对客户所在行业进行一些必要的了解,清楚行业发展趋势以及新兴技术的应用案例,从硬件和软件结合的角度出发来进行整体解决方案设计,提供给客户综合应用解决方案。
明确了个人的发展方向与职业角色定位,这就要求自己仍然需要不断的知识积累,尤其在数据集中所涉及的存储、备份、数据恢复以及云服务涉及的虚拟化技术上投入一些精力,结合项目实施者成功经验的分享,总结出适合自己在新的一年工作中处理项目的办法。
适用场景:软件开发项目总结、测试流程分析报告、测试经验分享材料
演讲要点:测试项目实施过程、测试工具应用效果、缺陷管理优化措施
行文逻辑:分析测试需求→设计测试方案→执行测试用例→发现缺陷问题→优化测试流程
我在几个月的软甲测试课程中深刻体会到软件测试的重要性和趣味性。这门课教会我们以软件系统工程的更大视角审视软件测试这项工作。
在做作业的过程中我感觉我做的测试项目越多,阅读的测试书籍越多,我越感到我对软件测试理解的越肤浅。因为我越来越感受到软件测试的广度和深度的无限性,它像大海宽广,像宇宙那样深邃。
为什么要进行软件测试软件测试的前途如何软件测试的工具和思想谁更重要软件测试的最高境界是什么
软件测试是保证软件质量的重要活动,是软件项目实施的不可缺少的环节。软件测试的直接目的是发现软件中存在的缺陷。此为测试的有效性。
在软件项目没有结束之前的全部软件缺陷主要由软件开发人员负责,因为软件缺陷来自程序员的编程。软件项目结束后的软件缺陷主要由软件测试人员负责,因为软件测试人员没有在软件发布之前的测试中没有发现隐藏的错误。
软件测试不是万能的,因为不可能发现全部的软件缺陷,而且软件的功能和性能不是由测试决定的。此为测试的有限性。
软件测试目前主要以手工测试为主,自动测试工具虽然很多,但实际应用的广度和深度还有很大潜力,自动将有很大的发展空间!。软件测试的缺陷管理流程非常重要,报告的软件缺陷的质量,应该由他人验证,做到责任明确,方法简便可行。
软件测试技术不断进步,但总体来看,国内的测试重视程度还不够,但已经发展很快。差不多两年之前,国内计算机书店中关于软件测试的书籍非常稀少,如今却琳琅满目,异彩纷呈。
软件测试是个可以很快入门的职业,门槛不高,但是,不要认为什么人都可以做好软件测试。因为会做和做好是两个概念。软件测试人员最好具有软件开发经验,理解软件工程的知识。这是提高软件测试能力的基础。对于刚刚毕业的学生,如果希望今后从事软件开发,那么,先从事一段时间的.测试可能更有利于今后的编程。而对于具有多年编程经验的程序员,如果改行做测试,更容易提高技术。
软件测试不是孤立的活动或过程,需要开发和市场人员的参与和交流,需要软件质量保证人员SQA的积极配合和沟通。
软件测试的技术不断进步,与具体测试技术相比,掌握测试的核心思想比具体技术更重要!测试的最高境界在于运用最简单有效的测试技术,最大限度的发现软件缺陷!