适用场景:测试技术应用总结、测试框架建设总结、测试工具使用总结
演讲要点:自动化测试框架搭建、测试用例覆盖率提升、测试效率优化措施
行文逻辑:学习自动化技术→搭建测试框架→开发测试工具→执行测试任务→分析测试结果
一、工作内容
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、自动生成的表格,奇丑无比
三、负责m项目测试
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、懂就是懂,不懂就别乱说。记得最早“老”员工问我一个我自己不是很懂的问题,我通常是按自己的理解方式,跟他胡吹一通。结果他再一细问,我就傻了。知道就知道,不知道就别乱说,这点很重要,尤其是在参加面试的时候,如果自己不是很动,别人一问你就会露馅。
适用场景:企业实习总结报告、岗位适应性分析、职业发展评估
演讲要点:核心做法为参与软件测试工作、问题反思为发现产品兼容性不足、行动规划为提升业务能力与网络推广
行文逻辑:参与测试→发现缺陷→提出建议→分析市场→提升自我→制定计划
20xx年xx月xx日,我怀着对提高并实现自我价值的心态,跨进西安XX科技有限责任公司的大门,开始了自己大学里兼职实习工作。转眼间,断断续续的三个星期的实习时间就过去了。回想起这段时间的工作过程,我深深的认识到在XX实习的选择是绝对正确的,XX公司和同事们对我个人产生的积极影响也是超越我的料想之中的。现将这段时间的工作进行如下总结。
一、软件测试部见证XX的强硬实力
这段实习时间完全是在软件测试部度过,亲自体验感受离了XX科技的主要软件产品。包括数据快速恢复平台v3、0,系统快速恢复平台v1、o,闪电恢复,三合一数据宝,一键恢复,联想onekey等等。并且协助同事完成对comguard,hd-shield以及联想网络控制工具等软件的测试工作。
1、XX的产品名不虚传。
通过对软件的实际测试,彻底从思想上改变了自己对数据备份保护的概念。XX的硬盘动态备份技术,能够在不占用固定硬盘空间(非用户使用空间),实现数据的快速备份与恢复,堪称典范,不愧是行业的创新者和领导者。
2、友善同事关系给人温暖和关怀。
在实习期间,自己的对计算机硬件系统比较陌生,特别是对频繁的更换操作系统等,多亏蓝朝霏等多位同事的热情帮助和指导,让我顺利完成软件测试。在软件测试过程中,同事们一丝不苟的精神对我影响很是深刻。这种良好的工作环境给我振奋,给我力量,给我信心!
3、软件的瑕疵在所难免。
在软件测试过程中,也发现了部分让人不是很满意的地方。主要表现在下列方面:
a、软件对中英文操作系统不能完全兼容。
建议:在软件安装入口处对中英文操作系统进行路径选择。
b、软件对不同主板的识别bios差异大。
具体是在hd-shield软件测试中,不同主板性能差异大。
c、软件密码在重新登录后有残存现象。
已经通过金党锋学长反馈到研发部。
d、软件的不稳定性。
本人联想昭阳e660因为测试三合一数据宝中的闪电恢复软件在重启中黑屏,在维修过程中彻底报废。
在软件测试中部分软件在不同机器环境中测试性能有差异。
还有其他问题在测试过程中已经汇报相关人员并得到满意解决。
总而言之,我们XX科技的产品还是值得信赖的。作为销售人员,我们需要对产品树立强大的信心!即使我们产品存在瑕疵,我坚信,我们勤奋团结的同事,一定会创造出更优秀的产品。
二、产品市场简单调查分析
1、同行业产品简单调查
通过在baidu,google搜素引擎检索“数据快速恢复”,“系统快速回复”,“快速还原”等关键词,发现南京生产的“雨过天晴”软件,和本公司产品具有很强的相似性。(测试报告详见附件内容)
通过在西安赛格,百脑汇电脑城的电脑diy市场及软件销售市场简单走访,暂时未发现“雨过天晴”系列软件的经销商。
2、网络调查简单分析
作为数据快速恢复领域的创新者和领导者,本公司的核心关键词语“数据快速恢复”,“系统快速回复”,“电脑系统快速还原”等在baidu,google等知名搜索引擎没有很好的被索引。
或许是公司产品发展定位因素,在网络推广方面有再提高的`空间。
对于此,本人有信心有能力,在非工作实践,提高XX产品关键词语在上述搜索引擎的排行。
3、电脑城市场调查简单分析
前期,和赛格电脑城的三叶网络(网络及电脑外设集成批发全国连锁经营),高鸿it(品牌笔记本零售商),陕西天惠(电脑diy集成)等公司的店长简单交流对此类软件的看法。整体反映效果较好。
在11月份,在进一步熟悉公司产品和销售流程同时,将安排时间继续跟进,推荐试用XX产品。
三、个人整体认知
准确的说,XX是一面镜子,照出了自己的不足和缺点,为自己的成长和提高创造了机会。
1、计算机硬件知识欠缺。
自认为是it专业本科生,熟悉专业去做销售更好些。其实不然,自己还是一粒沙子。在软件测试部,学会了计算机硬件的线路连接,知道了用u盘可以ghost快速做系统等等。或许可笑,但是对我而言,很严肃的现实证实:自己还不会是一个合格的大学生。需要虚心的向同事们请教!
2、英语知识的欠缺。
自认为立志做好国内销售,带领团队创作“农村信息化”创业计划书,立志为西部农村的it发展贡献一份力量。看到了vista,win7的英文操作系统,就基本灰心。但是我坚信,我会在短期内,在专业英语方面有所突破,因为自己还是对专业英语有浓厚兴趣的。
3、对销售的错误认识。
两年多的校园代理销售经历,误打误撞,取得了一定的成绩。尽管在实习期间,没有亲自体验到去向大客户推销产品的经历,但是通过李经理推荐的《大客户销售十八招》一书,发现自己还有很多的东西要认真的学,认真的领会,并在实际推销中灵活应用。庆幸的是,对于销售的做起码准则还是在坚守:诚实信用,对客户负责!用好的人品去赢得客户关注!面对拒绝,保持良好的心态!
4、自己还有在XX存在的价值。
XX和自己理想中的还有很大的差距,但是这种差距,或许就是我存在的价值!
主动向同事请教问题,积极虚心的向同事学习,这是我实习过程中一直在践行的!
下阶段,将积极贯彻李总经理的指示“加强个人管理,提高业务的能力”,从严要求自己,做好各项工作,提高个人存在贡献值。
“与XX共创业”,是我在XX实习的基本心态:认同公司发展愿景,服从公司安排,任劳任怨,积极负责,务实创新,把XX的事业看成自己的事业去拼搏!
四、下阶段工作计划
在11月份,认真贯彻落实“加强个人管理,提高业务能力!”的XX员工作风,具体落实到:
1、服从公司的工作安排,保质保量完成任务;
2、进一步熟悉公司产品(硬件产品),熟悉公司环境(认识研发部同事)
3、熟悉学习公司的销售制度和流程;
4、提高公司关键字网络检索排行,并提交一份营销计划书;
5、继续学习销售知识及应用技术,提高处理实际问题的能力;
6、申请参加公司的综合业务能力考核。
十月份,自己的收获是丰硕的:最起码从意识上,发现自己的不足,并寻求到合适的解决途径。非常感谢测试部的同事,感谢所有XX的同事,因为你们的帮助,我顺利的走过在XX科技的适应期。我坚信:在你们的帮助下,我会持续努力,不断反省,总结提高,快速度过在XX的成长期,早日跨进发展期,创造期。
适用场景:项目测试管理,技术能力评估,职业发展规划
演讲要点:功能测试执行与缺陷提交,测试文档编写与优化,自动化测试方案设计
行文逻辑:思想学习→测试执行→文档编写→技能提升→自动化推进
20xx年即将过去,时光飞逝,日月如梭,我来公司两年的时间转瞬即逝,身为一名年轻的员工,我紧密配合公司的安排,卯足精神,踏踏实实地为公司做事,同时也努力成为一名能主动做事,勇挑重担的员工,为公司的发展贡献出了自己的一份力量,回顾这段时间的工作,既有收获也有不足,现对自己这段时间的工作进行总结。本人在公司领导的正确领导下,在各位同事的热情帮助和大力支持下,立足本职工作,努力学习,勤奋工作,诚恳待人,团结协作,遵守各项规章制度和工作纪律,不断提高服务质量和工作效率,较好的完成了全年的各项工作任务。以下是两年的时间个人的工作总结。
政治思想方面:
在工作中我积极参加公司里组织的学习,努力做到在思想上,认识上同公司价值观保持一致,始终保持与时俱进的精神状态。同时,自己还树立终身学习的观念,利用业余时间进一步学习自己的业务知识。平时能够团结同志,具有一种良好的敬业精神和责任感。
工作情况:
这段时间我的主要工作有:大衍企业版项目的相关测试。
关于大衍企业版,在工作前期主要是对企业版各个子模块下功能点的测试,查找bug并提交到禅道,同时与产品、开发人员对需求的一些讨论,后期在需求部分变动下通过产品原型与产品需求进行测试计划,测试方案,测试用例等文档的编写。
存在的问题和打算:
尽管经过一些努力,我的业务水平还需进一步提高。在以后的工作中,我将加强自主管理的意识,加强理论和业务学习,不断提高业务技术水平,使自己的工作达到一个更高的层次,有问题积极与领导进行交流,出现工作上与思想上的问题及时汇报,也希望领导能够及时对我工作的不足进行批评指正,使我的工作能够更加完善。
今后我会加强其他专业知识的学习,社会的进步与企业的发展对员工的综合素质提出了越来越高的要求,要求员工一专多能,只有这样才能进一步提高企业的效率,增强企业的竞争力,才能增强员工在这个社会中的竞争力;具体在接下来的工作中,我准备进行接口文档,数据库文档,性能测试报告的组织编写,同时在具体的测试过程中与开发人员对产品性能上的一些优化进行商讨;下一阶段是当产品需求不再变更已完善后,回归测试过程中对可执行自动化测试的部分进行自动化脚本的设计与录制以节省人力物力。在工作过程中对测试工具jemter与python自动化测试框架selenium灵活运用不断改进公司产品的用户体验。
平凡普通的岗位上,自己只是沧海一粟,但是,人同此心,心同此理,只要我们都有爱岗敬业的行动,必将成为公司发展壮大的坚实基础。我会把自己的理想、信念、青春、才智毫无保留的奉献给这个庄严的选择,因为企业的发展与成功,不仅是一个公司的成功,更是我们每一个员工的成功,只有企业更好地发展,才有员工发挥的舞台,才能尽情发挥个人的才华,实现个人与企业的共发展!
适用场景:软件测试培训材料、测试人员工作参考、测试方法研究
演讲要点:利用网络搜索技巧、动手实践定位问题、学习相关系统知识
行文逻辑:学习网络→动手实验→思考总结→利用论坛→学习产品知识
软件质量越来越受到人们的关注,软件测试作为新兴行业有很多不完善的地方。很多从事软件测试工作的同行处于迷茫之中,如何提高,如何解决测试工作中的实际问题,困惑着每一个人。本文总结了一下个人经验,希望对大家有帮助。
我最初参加测试工作的时候,不知道什么是软件测试,集成测试和系统测试的概念经常混淆, cmm 是什么就更加不知道了。那时候最简单的开关机也是通过直接拔插电源完成,安装系统对我来说简直是有史以来人类的最高技能,对于那些拿着螺丝刀安装机器的人就认为是宇内超级高手,身具杀人于无形之绝世秘技。拿破仑说不想当将军的士兵不是好士兵,我最初的梦想就是想成为软件测试的高手,傲视天下。所以不断偷师,总结经验,自认为掌握了成为高手的几个秘技,这几年混迹 “ 江湖 “ 还算无往而不利。不敢独享,望与吾辈测试人员切磋,早日总结成功密技之大成,助新进人员早日入门,也算不愧对东北活雷锋的称号。
第一招 学会利用网络
刚参加工作面对浩瀚的网络世界,当时如刘姥姥进大观园,什么都新奇,什么都想要,从网上下载很多源程序的代码,软件技术文档之类,恨不得把所有的好东西收集到手中,其实有些在他人看起来就是垃圾一堆。当时觉得有了这些 “ 武林秘籍 “ ,成为高手指日可待。最初参加工作由于自己工作努力有幸转为开发,加入项目组后我的习惯还是没有改,反而变本加厉,手中的资源更加多,上网的时间更加频繁。
一次项目经理分配任务,觉得依靠手中的秘籍加上自己的 “ 聪明才智 “ 很快会完成,不料短短的时间,所有的一切变成了马奇诺防线。解决问题很慢,思路不清晰,项目经理在对我施压的过程中教会了我终身难忘的一招,学会利用网络寻找要解决问题的答案,从此 google 成了我的最爱,关键成了我变化的招数。在软件测试工作中,他帮我解决了很多疑难问题,解答了很多令我迷惑的地方。也是我帮助测试同行解决问题手段之一,很多软件测试新手,甚至老手都没有意识到自己手上就握有 “ 无敌秘籍 “ ,所以只要你耐心找,答案就在身边。
这里总结一下利用网络搜索引擎的技巧:
组合搜索
每次搜索某个文件,如果只给出一个单词进行搜索,经常会出现成千上百万计的匹配网页。然而如果再加上一个单词,那么搜索结果会更加切题。
选择表述内容的词组
一般我在网页搜索引擎的时候,选择一些可以表达我要查找内容的关键词组,用来缩小搜索范围,从而找到搜索结果是最好的办法。运用词组搜索涉可以先先简单地输入一个问题作为词组搜索,如果仍然找不到合适的,那就用多个可以表达要查询内容的关键进行查询。
定位信息来源
有的时候用词组搜索不到或者无法准确表达所需信息。可以用另一种方法直接到信息源,就是直接到到提供某种信息的站点去。可以用公式 “www. 公司名 ” 去猜测某一组织的特点。从而得到所要搜索的信息的主要词组
其实网络上还有很多关于搜索技巧的文章,大家可以自行学习。千万要记住搜索引擎是帮助你成功的有力武器。
第二招 学会动手
参加软件测试工作后,随着工作经验的增长自我感觉越来越好。在公司里也逐渐受到同事领导的重视,一次针对公司的新的软件功能进行测试的时候,像往常一样 “ 随手 “ 测试出了几个 bug ,然后 “ 仔细 “ 的填写了 bug 单(这个 bug 的现象已经出现了很多次了)。这时候测试经理走过来,重新复查了一下填写的 bug 。他在重现我的 bug 的过程中,简化了我的输入变化, bug 神奇的又出现了,同样的现象,他关闭软件重新变化输入,扩展出 10 几个变化后,软件不动了,内存不断上升。终于他找到了产生软件的 bug 的原因,然后对我说 “ 寻找 bug 要准确定位,我们开发团队是一个整体,时间是等量的,时间不在你身上浪费,就是在他身上浪费。如果测试人员每次发现的 bug 描述不清楚,并且多个问题潜在的错误原因是一个,虽然操作可能稍微有些变化。这样开发人员在重现 bug 的时候他要调试跟踪判断,很花费时间,而且效率低。如果测试人员发现 bug 的时候多动手可以更加准确的定位 bug 步骤和原因,给开发人员最精确的步骤和准确的描述,这样整个团队才能高效,所以需要大家协作!。 “ 。
在以后的日子里,每次解决问题的时候我都记得多试验几次,多尝试。网上很多朋友还有同事问我问题的时候,其实他们只是万里长征就差一步,只要再多动手实验一次就可以达到目的了。所以多动手,多尝试。
第三招 思考自己所作的
刚开始入行的时候,总是思考如何做好软件测试。认为公司的测试流程混乱总是很郁闷,认为自己学不到东西,如何才能测试好产品,常说心动不如行动,以前看到古龙小说中经常出现的场景无名小子不断挑战高手,总结积累。我总结了有些经验是实战中得到的,所以不断尝试引入新的测试流程然后评估,这个过程虽然很痛苦,但是从中积累了不少经验。这段时间让我学习到了很多东西,接触了 iso,cmm ,测试管理工具,自动化工具(因为公司不正规给了我很多学习的机会,后来到了比较大的软件公司后,以前的经历给了我更多的发展机会,因为大公司非常正规了,公司内部人员分工明确,所以能力的锻炼反倒少了)。由于工作中经常写报告反倒养成了总结教训的习惯,因为纸面上的东西是永远也忘不掉的。在写的过程中可以不断补充扩展,整个过程是思想升华的过程,当年达摩面壁九年就是融会贯通的典型例子,如果他不是有个思考的过程,他也不能成为一代大家。如果后来不时有人把他的绝技记录下来,也就不能有后来的少林寺七十二绝技。
所以善于思考,总结经验,也是成为高手之路的不二法决。
第四招 学会利用论坛资源
其实测试新兵和测试高手之间的区别,往往是不会利用现有资源。在论坛中我们会看到很多新手不断的提问,但是有很多问题其实都是已经别人提过了,或者已经有解决方案的。所以经常会看到 “测试高手“的身影,并且不提问题,而且还能“锄强扶弱“,是测试新丁的救命稻草。好像是高手们无所不能,其实摘掉这层耀眼的光环,他们并没想像得那么厉害,只不过通过自己的搜索找到的答案,然后帮助其他人。当然也有很多人都是通过自学,然后在论坛中交流得到了很多经验,高手其实也是因为善于思考问题,亲自动手解决问题。所以动手和利用论坛资源的过程中他们也在不断提高。
很多时候看到论坛中有人提问,问题描述不清,很多人看了很困惑。发贴题目动不动请高手帮忙,救命之类的,好像天下大乱,世界末日。虽然这个题目很招人,但是无法让那些想帮助你的人帮你,因为题目不清晰,而且高手样吓阻了很多人。其实问问题也是个思路整理的过程,描述清晰,让人理解清楚,才能望文知意知道你的当前发生问题的环境,才能让那些想帮你的人解决问题,否则给人无从下手的感觉,解决问题效率不高。
第五招 学习和你所测试的软件产品相关的知识
要想成为好的测试人员,还要了解你要测试的软件的相关知识。要了解软件产品的架构是什么样的。要了解软件的市场需求,在接触软件之初要可以多看看用户的反馈信息,这些才是用户最关心的,也是你在测试中需要注意的问题,满足客户是最大的需要。但是了解软件需求之后要学会要多读些软件系统的技术文档,软件设计文档,这些文档可以帮助你了解产品如何工作。还有多看看公司 bug 库中的问题,这些存在的问题可以帮助你了解软件产品那些地方存在缺陷,软件系统那些地方会出现错误。软件是运行在一个大环境中,如果对系统不熟悉,那么有些问题你不能从一个更广阔的层面考虑,学习操作系统的知识,有助于你发现缺陷,定位问题更加准确。比如软件运行在 windows 或者 linux ,如果你不懂操作系统,你就无法建立测试环境,有些时候时候软件的组件发生问题,就是你系统配置造成的,对系统不熟悉,你会把外在原因归结为软件本身。所以要学习关于和软件系统相关的知识,比如编程,网络,数据库等。不一定你要学习到多好的程度,只是通过这些扩展的知识面,你可以在发现问题,解决问题上不会局限在狭小的圈子里。
和一切相关的人员交流,不同的交流渠道,获取消息是不同的,角度也不同。和客户交流,你会在测试中从客户的角度发现问题;和开发人员交流,你会了解开发人员怎么实现软件功能的;和项目管理人员交流,你会知道开发进度以及遇到的困难。
适用场景:教学实践总结,项目管理总结,团队协作总结
演讲要点:项目开发计划编写,测试计划制定,团队协作经验
行文逻辑:规划项目需求→分解工作任务→协调团队沟通→制定测试方案→总结实践经验
本次课程设计我主要负责的是项目开发计划和测试计划两个文档的编写工作。历时两个星期终于顺利完成。辛苦虽然是不可避免,但收获还是令人尤其欣慰。
其中项目开发计划主要对项目的整体实施提前做一个详细的规划。项目开发计划主要在于协调和沟通,在规定的时间内尽可能全面收集项目信息。项目信息收集要讲究充分的、有效率的沟通,并要和小组成员达成共识。
编制项目计划主要经历了如下的过程。包括、确定项目的应交付成果。这里的项目的应交付成果不仅是指项目的最终产品,也包括项目的中间产品;任务分解:从项目目标开始,从上到下,层层分解,确定实现项目目标必须要做的各项工作,并画出完整的工作分解结构图。在资源独立的假设前提下确定各个任务之间的相互依赖关系,以确定各个任务开始和结束时间的先后顺序;获得项目各工作任务之间动态的工作流程。确定每个任务所需的时间,即根据经验或应用相关方法给任务需要耗费的时间;确定每个任务所需的人力资源要求,如需要什么技术、技能、知识、经验、熟练程度等等。确定项目团队成员可以支配的时间,即每个项目成员具体花在项目中的确切时间;确定每个项目团队成员的角色构成、职责、相互关系、沟通方式。确定管理工作,管理工作是贯穿项目生命周期的,如项目管理、项目会议等、编写阶段报告。项目团队成员之间的沟通时间、项目团队成员和其他项目干系人之间的沟通时间也比较容易被忽视,而沟通时间也是比较不容易固定地量化和日程化。但这些工作在计划中都应当充分地被考虑进去,再回师项目计划更加合理,更有效地减少因为计划的不合理而导致的项目进度延期。考虑项目的费用预算、可能的风险分析及其对策。
另一个就是测试计划了。软件测试就是利用测试工具按照测试方案和流程对产品进行功能和性能测试,甚至根据需要编写不同的测试工具,设计和维护测试系统,对测试方案可能出现的问题进行分析和评估。执行测试用例后,需要跟踪故障,以确保开发的产品适合需求。编写测试计划是为了项目经理能够根据测试计划做宏观调控,进行相应的资源配置等。同时测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作,便于其他人员了解测试人员的工作内容,进行有关配合工作。本次我编写的测试计划分别包含了黑盒白盒测试、单元测试、集成测试、确认测试、系统测试和验收测试。应详细介绍了每个测试的方法和过程。
通过这次测试计划的编写过程和上网查资料了解到,每当测试一个程序时,人们总希望为程序增加一些价值。利用测试来增加程序的价值,是指通过测试,找出并修改尽可能多的程序缺陷,从而提高程序的可靠性或质量。
因此,不要只是为了证明程序能够正确运行而去测试程序。相反,应该一开始就假设程序中隐藏着错误,然后测试程序,发现尽可能多的错误。
事实上,如果把测试目标定位于要证明程序中没有缺陷,那么就会在潜意识中倾向于实现这个目标。也就是说,测试人员会倾向于挑选那些使程序失效的可能性较小的测试数据。另一方面,如果把测试目标定位于要证明程序中存在缺陷,那么就会选择一些容易发现程序缺陷的测试数据。而后一种态度会比前者给程序增加更多的价值。
因此,大多数测试专业人员都赞同myers对测试的定义:“测试是为发现错误而执行程序的过程。”这个定义意味着程序测试的过程是具有破坏性的,甚至是一个“施虐”过程。开发人员可能不愿意这么做,因为人们总是倾向于建设而不是破坏。这个定义还暗示了对于一个特定的程序,应该如何设计测试用例(测试数据)、哪些人应该而哪些人又不应该执行测试。
事实上,如果在测试某个程序段时发现了可以纠正的缺陷,或者测试最终确定在没有其他缺陷,则应将这次合理设计并得到有效执行的测试称作是“成功的”。而所谓“不成功的”测试,仅指未能适当地对程序进行检查,未能找出程序中潜藏缺陷的测试。因为软件中不可能没有缺陷,没有找出它们,当然测试是“不成功的”。
“软件测试就是证明软件不存在错误的过程”。对几乎所有的程序而言,甚至是非常小的程序,这个目标实际上是无法达到的。因为即使程序完全实现预期要求,仍可能包含有缺陷。也就是说,如果程序不按要求工作,它显然有缺陷,但如果程序做了不要它做的事,它也有缺陷。
心理学研究告诉我们,当人们在干一件已经知道是不合适的或不可能做到的事时,往往他们的表现就相当糟糕。把程序测试定义为在程序中找出错误的过程,就使测试成了可以做到的任务,从而克服了心理上存在的问题。虽然这看起来像是个微妙的文字游戏,但对成功地进行软件测试有很大的影响。
总之,软件测试更适宜被视为试图发现程序中错误(假设其存在)的破坏性的过程。一个成功的测试,通过诱发程序发生错误,可以在这个方向上促进软件质量的改进。当然最终人们还是要通过软件测试来建立某种程度的信心:软件做了其应该做的,而没有做其不应该做的。
通过以前课程的了解,意识到测试的重要性。在发布新产品之前做好测试,提高软件产品质量,减少漏洞,是预防木马攻击的根本途径。别人的经验证明,软件的质量不仅体现在程序的正确性上,它和开始编码以前所做的系统需求分析,软件设计密切相关。许多软件使用中出现的错误,未必是编程人员在编码阶段造成的,反而在程序设计,甚至在需求分析时就埋下了祸因。这时,对软件的错误纠正,就必须追溯到软件开发的最初阶段。由此看出了软件测试阶段的重要性。为了保证软件的质量,专案管理就应该着眼于整个软件生存期,特别是在开发阶段的系统分析。所以软件测试的概念和实施范围必需包括在整个开发各阶段的复查、评估和检测。
整个编写计划的过程紧张而又快乐,我像一个真正的项目开发人员一样,找到了自己的位置,找到了感觉。把全部的心血浇筑到键盘上,眼看着文档想豆芽一样生长,我心满意足。做项目的过程中曝露很问题,不过这是好事,有挫折才会成长。
可以说做项目的过程是一个艰辛的过程,很多同学,特别是组长为了这个项目经常加班。回到宿舍之后还要拖着疲惫的身体继续工作在电脑前,为了项目的如期完成而努力......在完成了项目之后,有一种如释重负的感觉。但我相信每一位做了项目的同学,一定能够对软件开发的过程有个更深的了解。软件开发过程最重要的是团队精神,这是小组全体成员的心声,在整个项目文档制作过程中,没有谁能够真正一个人走下去,做项目如此,我们每个人的生活又何尝不是如此,谁能真正独立于社会生活呢?项目团队只是我们社会生活的一个缩影,认识到这一点,就不难理解为什么项目开发需要优秀的团队,需要良好的团队精神。
课程设计对我们而言是我们对所学课程内容掌握情况的一次自我验证,有着及其重要的意义。通过课程设计能提高我们对所学知识的综合应用能力,能全面检查并掌握所学内容。根据课堂讲授内容,学生在实践中做相应的自主练习,消化课堂所讲解的内容。回顾气此次课程设计,至今感慨颇多,从理论到实践,巩固了以前学的知识,同时学到了课堂上不能学到的内容,正所谓实践出真知。
突然发现,做项目的过程就是捡金子的过程,是把以前学过的知识一块一块的捡起来,做为项目组的一员对项目的开发我有了深刻的认识。过程中,每个同学都离不开其他同学,在一个问题的交流看法中,可以体会到文档编写的多样性和灵活性,有很多的捷径都是同学们互相交流和辩解中得到的最佳答案,以至于每个同学都会在项目中得到更多的理解和项目经验。
这13天中,我们小组分工明确,齐心协力,互帮互助,积极讨论,共同见证了从调研到最后一份报告的完成。
最后更离不开老师的指导,并且感谢老师在这段时间对我们寄予的信心和期待!
适用场景:软件项目测试总结、 软件开发流程总结、 软件质量评估总结
演讲要点:测试用例编写与评审成效、 用户体验测试经验反思、 系统稳定性测试规划
行文逻辑:编写测试用例→测试系统功能→优化用户体验→提升测试能力→规划未来测试方向
一、测试工作及经验
作为软件部测试组的一员,首先要做好的就是自己的本职工作,我在xxxx年中所做的工作主要有:
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;自身专业技术能力还不足,不能从系统稳定性这一点上对系统进行测试。在以后的工作中,我会努力改善。
在xxxx年的工作中,我计划:
1、本着实事求是的态度,更加认真、负责的完成工作;
2、要尽可能深刻的理解需求,坚持编写覆盖率强的测试用例;
3、按照系统稳定性测试方案,要逐渐对系统的稳定性、安全性进行测试;
4、继续研究性能测试,并要将LR工具运用在实际工作中;
5、多多的学习,参加一些有益的培训,在实际工作中活学活用。
四、个人建议
这一年来我们部门有着的显著进步,越发规范的工作流程,越来越明确的责任制度、管理体系等,都让我们更加有凝聚力。在此,个人提出以下几个小建议:
1、希望可以加强对项目的把控,尽量能将延期风险降到最低;
2、从各个组对需求理解的不一致,以及信息更新不及时等问题上看,沟通
问题还是有待完善;
3、希望能够在需求这一关卡上能更详细、准确的确定产品的功能要求;
4、虽然工作任务繁重,还是希望部门能够多组织活动,完善奖励制度,可
以让大家更加激情的为部门、为公司奉献自己的全部力量。
以上是我个人的一些浅见,相信在大家共同的努力下,向着同一个目标进发,软件部甚至整个公司必定会大展全新的宏图伟业。
适用场景:项目测试报告、测试方法分析、测试流程规范
演讲要点:单元测试实施、测试用例设计、性能测试优化
行文逻辑:执行单元测试→设计测试用例→优化性能测试
这学期的期末大作业是对ELearning Java Web应用系统进行测试,通过这次系统测试,我学到了很多知识,软件测试个人总结。对于具体的测试部分,我主要做的是单元测试和性能测试,其中单元测试使用的是Junit工具,性能测试使用的是JMeter。就这次大作业而言,我认为它与我们平时做的实验很不相同,我们平时的实验只是涉及到测试的某个小部分,而这次测试却是对一个相对完整的项目按照规范的标准进行测试。
对于好的测试来说,应该注意一下几点:
1.测试的独立性:一次只测试一个对象,方便定位出错的位置。这有2层意思:一个TestCase,只测试一个对象;一个TestMethod,只测试这个对象中的一个方法。
2.给测试方法一个合适的名字。
3.在assert函数中给出失败的原因,如:assertTrue(…should be true,…),方便查错。在这个例子中,如果无法通过assertTrue,那么给出的消息将被显示。在junit中每个assert函数都有第一个参数是出错时显示消息的函数原型。
4.测试所有可能引起失败的地方,如:一个类中频繁改动的函数。对于那些仅仅只含有getter/setter的类,如果是由IDE(如Eclipse)产生的,则可不测;如果是人工写,那么最好测试一下。
5.在setUp和tearDown中的代码不应该是与测试方法相关的,而应该是全局相关的。如针对与测试方法A和B,在setUp和tearDown中的代码应该是A和B都需要的代码。
6.测试代码的组织:相同的包,不同的目录。这样,测试代码可以访问被测试类的protected变量/方法,方便测试代码的编写。放在不同的目录,则方便了测试代码的管理以及代码的打包和发布。
对于测试用例的命名,我们最好要使其与测试类的名称相一致,比如说,类的名称为Testing,此类的测试用例的名称为TestingTest。当我们把测试代码和被测的代码放在同一目录下时,我们就可以在编译被测代码的同时编译测试代码,从而确保两者是同步更新的,工作总结《软件测试个人总结》。事实上当前的普遍做法,就是把单元测试视为build的一个环节。保持测试之间的独立性是一个很好的习惯,使得它们在任何次序下执行的结果都是相同的`。如果真得需要某些测试按照特定的次序执行,我们可以借助addtest来实现。当我们需要增加一个测试时,我们要书写一个自己的测试用例,但是如果喜欢在测试用例的构造函数中做有关的初始化工作,这就不是个好习惯。数据文件应该尽可能和源代码一起都放在配置管理系统上,但这样一来如果我们采用上面的resource机制,我们就需要做一件工作,就是把数据文件从原来的位置-就是源代码的某个相对路径,拷贝到编译后的位置,也就是class文件的相应的相对路径。
通过这次软件测试的系统测试,我对软件测试有了更加深刻的认识,其实软件测试并不像想象的那么简单,它需要测试人员具备多方面的能力和素质。软件测试人员应该拥有广阔的视野、一定的编程能力、细心和耐心等等。这些对于能否测出优秀的系统来说都是必不可少的。
经过这次对java Web应用系统的测试,我的测试能力得到了锻炼,对软件测试有了比较全面的认识,收获了很多珍贵的东西,而且我也从软件测试的角度,对编写健壮的程序也有了新的认识。
适用场景:系统测试总结、文档编写总结、bug修复总结
演讲要点:系统测试工作、问题反思改进、数据库迁移规划
行文逻辑:测试系统→编写文档→修复bug→优化体验→学习数据库
伴随着充实紧凑的工作生活,两个月的时间已经过去了。这一段时间里有工作上的收获,知识的丰富,经验的增长,同时也暴露出很多问题和不足。总结经验,吸取教训,本文将主要从几个方面来对工作进行总结:工作的主要内容;其中的失败和教训以及成功和经验;展望下一阶段的工作,确定自己的目标。以此作为惩前毖后的记录。
1、工作的主要内容:
在这两个月的工作中,我的总体任务是协助苏薇做好武警黄金部队矿业权管理系统的后期测试,编码,修改,文档编写的工作,分解开来之后,我主要做了三件事:
1)、编写矿业权系统的各类文档。
2)、矿业权系统的编码及bug勘误工作。
3)、矿业权系统的测试工作。
下面依照时间来对我的工作进行介绍。
初踏入职场,进入专业的软件制造公司,对我,一个没有接触过标准软件制作过程的新人来说,起步就是一个很大的难题。若直接做开发,则业务不熟练,代码不规范,弊大于利;若仅做学习,则不能跟上项目的步伐,不能以快的速度融入工作中去。
在我还在忐忑自己到底要做什么工作的时候,任务已经下达了,首先进行矿业权系统的测试工作。这样的好处在于能够在测试的过程中,了解项目的整体布局,了解项目中的业务逻辑,了解项目中尚未完成的工作并以此作为下个阶段的工作目标。至此,入职工作顺利起步。
在对矿业权系统进行测试之后,暴露了系统的诸多问题,测试过程中发现矿权系统没有进行输入限定,为了解决这个问题需要对整个系统的数据进行整理,我的下一个任务就是编写矿业权系统的数据需求文档。在编写该文档的过程中,对矿权系统进行了更深入的了解,为之后的bug勘误工作奠定了一定的基础。
完成了矿业权系统的数据需求文档的编写之后,新的任务是对整个矿权的输入数据进行输入限定,在任务开始之处是极为困难的,幸而得到了同事们的帮助才得以顺利完成任务。任务虽然完成,但是对输入限定实现方法的一知半解以及任务完成过程中的不仔细,为之后发生的问题也埋下了苦果。
在对矿业权系统添加输入限定完成之后,进入了解决程序小问题的阶段,对矿权系统进行细微的缝补工作。这段时间是学习多于工作的,不同的问题督促我要每天和百度亲密接触数百次,又要劳烦诸位在百忙中的同事抽出时间来给我帮忙。虽然辛苦一点,但收获却是满满。
完成了系统的修补之后,我们的程序送到了四惠进行第一轮测试,在测试的一周里,我主要是补充网络编程的基础知识。
第一轮测试结果出来之后,我们项目组开始了紧张的第一轮矿业权系统bug勘误工作。拿到bug列表之后,发现有一小半错误皆是因我而起,输入限定问题很多,我也主动承担了输入限定部分的bug勘误工作。
第一轮bug勘误工作完成后,进行了第一轮了回归测试,测试结果已然不尽人意,仍然存在大量的问题需要修改,而且很多问题还是因我而起,输入限定仍然存在大量问题,再进行修改之后,我们的程序送到了十五所进行所检。
在进行所检之余,我又接到了新的任务,完成矿权系统的概要设计以及详细设计文档的编写。这两份文档已于9月2号编写完毕。
现阶段我的任务是根据所检的bug列表,对矿权系统进行回归测试。
2、工作中失败的教训以及成功的经验
对于失败的教训要吸取,成功的经验要进行总结。我对成功的定义是:在保证质量的前提下完成既定的计划或目标就是成功。其他的所有结果都是失败。成功的经验:
1)敢于接受任务并想尽一切办法完成
入职两个月大的收获就是敢于接受任务并想尽办法完成,每一个任务对于初入职场的我都是一个挑战,如何保质保量完成任务是基本的要求。这两月大的成功在于没有任务是拖沓的,每次都尽大努力完成了任务。
2)勇于承担错误,正视自身的问题
在这两个月的工作中可谓是错误不断,从文档的错别字这种小问题到矿权系统bug修改不正确导致崩溃这种大错误,暴露出来了很多的问题,我秉承着有错即改,下不为例的思想,正视自己的错误并积极改正,因此这也算是一个成功。
失败的教训:
1)重视每一个细节,不要忽视小问题
在初进行矿业权系统数据需求文档的编写的过程中,对某些页面的数据在数据库中没有存储的情况没有加以重视,在后期进行数据限定的时候,还要重新修改数据需求文档,造成了不必要的时间浪费。从这个事情上得到教训就是不要放过任何一个小问题,这个小问题可能导致之后的大问题。
2)进行重复工作也不能大意
在对矿权系统进行输入限定的方法熟悉之后,都是重复性的工作,给每个页面,每个字段进行输入控制语句的添加,在进行了数个页面之后,出现了有的页面没有添加完整,或者提示语句不正确的.情况,在后续的bug勘误中出现了大量此类问题,浪费了大量的时间和精力修改。从这个事情上得到的教训就是工作不能大意,重复性的工作更要完成好。一般重复性的工作第做不好,后续检查修改是非常浪费时间的。
3)考虑问题要严谨
在对矿权系统bug勘误的过程中,对输入限定条件的判断出了问题,我想当然的按照我的主观思路对数据进行了限定,而在回归测试的时候出了问题,这些都是考虑不严谨的后果。这个事情的教训就是考虑不严谨直接导致问题推倒重来,影响了工作效率,而且很容易埋下隐患。
4)注重用户体验
在矿权系统bug勘误的过程中,修改多的在于坐标系统的提示语句,因为坐标系统不仅要求数据必须填入,而且每一个数据都有严格的格式限定,因此每一个错误提示的弹出都要本着如何让用户知道哪里错了为原则进行设置。在初的限定里面,语句粗糙,弹出语句不明确,造成了用户使用的不方便,还得重新进行改造。这个问题的教训是一定要从用户的角度出发考虑问题,注重用户体验从简单的提示语句做起。
3、展望下一阶段的工作
下一阶段短期内我们的工作主要针对矿权系统的使用的数据库变更来对我们的系统进行修改。我的工作任务主要是学习oracle数据库和sql数据库的使用上的区别,做好从sql数据库向oracel数据库的迁移工作。