第一篇:软件测试工作的心得体会
很久没有写点东西了,今天给大家聊些我在软件测试领域的心得体会。接触计算机程序设计已经快7年了,从事专门的软件测试也快四年了,强子也是在阴差阳错中踏入软件测试领域,一开始只想做一个特牛的程序设计师,可是毕业后找工作却找了个软件测试的工作,在一些彷徨与犹豫中接受了这个职业并且到现在也做得挺开心,也是由于那时我们这个业务刚成立不久,由于表现还不错所以一个阴差阳错的机会被升为team leader,到现在也还在同一家公司做着测试的工作。
先讲讲做manager的一些体会,其实具体做什么事真的不是那么重要,关键是做事的方法,做人的章法,特别是对一个manager来说,方法比技术更重要,真的是这样,当然我也很喜欢研究技术,技术能让我找到更多的自信和成就感,但是面对着手下一帮兄弟姐妹,一个人的技术就显得有些力不从心了,这个时候得把你的知识share给大家,当然形式多种多样,比如写一份文档,做一个正式的training,给大家营造一种不耻下问的环境或者大家一起讨论一些难题等等。当然还有很重要的一点,一定不能说“我不知道”,作为一个头,如果你真的不知道,那你得想办法通过一些手段与员工一起把这个问题解决了,坚决不能说“我不知道,你自己看着做吧“等,本来员工是很尊重你的,这些话将直接导致其鄙视你。
另外就是做头的,特别像咱这种中低层的头,不像中高层的领导,咱们考虑事情的角度不一样,当这种小头儿的最重要的两件事:把事情做对做好,与员工打成一片。首先得确保把事情做对咯,然后带领大家朝着这一个对的方向前进进而把事情做好,在99%的时间里,你是和你的兄弟姐妹们呆在一起而不是和老板,所以这个过程中的与员工的关系一定要融洽且单纯,不能让员工对你有隔阂感,经常一起吃饭,摆摆龙门阵,唠唠家常,开开玩笑,不要摆架子,在一个公司里最不能摆架子的就是这种小头儿(或称之为leader或者manager一类),这就像个村官一样,小样的,还真把自己当回事儿呢?
做开发还是做测试?很多人讨论甚至争吵,强子认为之所以会有这样的问题是因为中国还没有把软件行业普及好,大家还停留在江民时代,求伯君时代,认为做开发的才是牛人,才有前途。而事实上,现在的软件是一个系统工程,缺开发,缺测试,缺文档都不行,都可能直接导致失败,谁最牛?强子认为写文档的人最牛,那咱们都去写文档?不过从强子面试的很多人当中来看,还是有更多的人愿意做开发,这不能不说是一大遗憾,强子无能,也只能聊以文字来表达自己对测试的热爱。测试犹如开发一样,也是一门深不见底的大学问,咱以后慢慢讨论。
关于项目管理,这又是一门大学问,强子在这几年当中也经历过无数次的版本更新,版本发布或者一些内部的项目,对项目管理略知一二,有空时强子自会附上一些体会。我想项目管理最本质的一点:保护项目团队,保护项目经理,去除杂音。项目经理这活,不好干,要职位没职位,要资金没资金,做好了皆大欢喜,做不好就卷铺盖走人,挺难,不过咱有咱的方式方法,怕啥?
今天先写这些,以后咱慢慢叙......
第二篇:软件测试心得体会
下面简单谈谈我的几点体会:
体会一:软件测试在整个软件周期中的重要性。
它存在于整个项目周期,在项目开始之初需求调研的时候就开始了,在形成需求规格说明书的时候就需要针对文档进行测试。这个环节在后续整个项目中占了很大的比重,能主导整个项目的走向,成败与否全在于开始阶段的决策。
体会二:软件测试的真正意义在于发现错误,而不在于验证软件是正确的。
再严密的测试也不能完全发现软件当中所有的错误,但是测试还是能发现大部分的错误,能确保软件基本是可用的,所以在后续使用的过程中还需要加强快速响应的环节。结合软件测试的理论,故障暴露在最终客户端之前及时主动的去发现并解决。这一点就需要加强研发队伍的建设。
体会三:在系统性能测试方面需要重视。
经过这次培训中多个案例的讲解,让我了解到系统在上线之后会有很多不能预知的性能问题,需要在上线之前实现进行模拟,以规避风险,包括大数据量访问,高并发数等等。
当然也有很多应对手段,没有哪种手段可称为最完美,只有最合适的,需要灵活掌握,综合运用以达到最优程度,这是个很值得研究的领域。
下面是本人的几点想法:
想法一:加强系统上线前的性能测试。
目前我们在项目建设过程中对性能压力测试的重视程度还不太高,厂家也很少有雇佣第三方的测试机构。而是在现网进行试用,遇到问题再解决,可能会产生滞后问题,影响客户使用。希望以后能在性能测试方面提高重视程度,加大人力投入,以保证系统上线后能够稳定运行。
想法二:适当介入相关项目研发
对于快速响应这块,我们不能一味依赖厂家,而希望自己就能快速响应,及时将问题解决。这也是一个比较长远的问题,需要加强研发力量的投入。
我个人是做开发出身,有此类经验,当时是在客户现场,因为了解系统内部结构,能够在第一时间排查解决客户所反馈问题。
现在系统完全由厂家开发,很难了解内部结构,或许会造成后期维护困难。所以,是否应该针对某些项目介入厂家研发工作,比如请厂家提供源代码等相关要素,以增进维护人员对系统的了解。
最后再次感谢公司提供的平台,感谢领导的信任,让我有机会得到更深层次的学习以及展示自己能力的机会,我也会尽我所能来完善工作的系统,提高整体工作效率,为南方电网的发展建设提供更坚实,优秀的支撑服务平台。
第三篇:软件测试心得体会
心得体会
六天的培训结束了,感觉过得好快啊。虽然是因为参加“模拟招聘”获得这次机会的,不像其他同学一样是交钱的,但是我也是抱着要学东西的心态参加的。
第一天老师(来自好范 文网:wWw.)就给了个下马威——教材全是全是英文版的。对于虽然大三的我来说,英语四级刚过,六级成绩还没出来的情况下,想看懂全文是不太现实的。在老师讲解过程中利用在线翻译才勉强能看懂句子。不过培训过程中最难忘的不是来自教材,而是来自老师的那双犀利的眼神。无论何时,只要你打开了与课堂无关的网页,她总会第一时间或叫号码,或叫名字,或站到你旁边。说实话,大学上课已经很久没有这种高中被管的感觉了。虽然不爽,但是却有种回到高中的快感(说的是实话)。
头几天还蛮不错的,食堂开门的,超市没关。可后几天,当校门口已无人烟,就剩我们这几个的时候就真觉得寝室楼好静啊,还不如在机房呆着。对于老师我想说的是,前几天笑容总是挂在脸上,可两天后明显笑的少了,不知道是不是因为和大家熟了,没有刚见面的客气了(我喜欢看人笑,本身也喜欢笑,老师的这种变化,我很敏锐的察觉了)。
这次培训虽然感觉学到的没有很多,但是我了解了一个企业,起码是软件测试这一行业大致的运作模式,让我对我将来要不要从事这个行业有了认识。貌似软件测试女生为主,男生比较适合从开发做起,这是我这几天得到的最大体会。还有对于课堂结束的演讲,是个锻炼
自己的好机会,我并不否认这点,不过貌似每个人都只有一次机会,我是个表现欲很强的人,让我讲了一次有点不过瘾。
开始我是因为不想浪费免费来上课的就会,来到后我觉得确实很多时候是需要多接触下这些社会上的公司、企业等,毕竟还有一年就毕业了,到底何去何从自己是真的要好好做个打算了。期待下一期的网新的培训??
第四篇:软件测试心得体会
软件测试心得体会
—王礼永
曾经一度认为软件测试就是使用工具测试bug,现在看来不是这么一回事情,因为还是有手工测试(执行测试),工具只是一个辅助,用工具你先要去了解测试的一些基本的东西(如:测试用例,预期结果等),不是那按两下按钮就行了,就算是录制脚本,也需要看懂脚本的代码,工具不是万能的。
一开始接触软件测试觉得很枯燥乏味,全都是一些理论的东西,还不如回到小学学习语文呢,都是一些名词的解释,比如:黑盒测试,百合测试,系统测试。测试基础等等这些,老师都会去告诉你这些名词什么意思,很无聊,到后来慢慢由语文变成了数学,开始练习测试用列的编写,这个还有点意思,因为这个更多时候能够体现个人的逻辑思维能力,再然后数学就转变成了英语,因为要使用到一些测试的工具,比如:winrunner工具,录制脚本它会产生一些代码,不过代码比较好理解,虽然是英文的但是还是很好看懂的。
学习软件测试一学期,其实我觉得最重要的是兴趣,有了兴趣还是不行的,还需要具备一些语言的基础,例如:c,java,c#等一些语言,这些语言你不需要去深入的学习,只需要了解,最重要的是了解数据库(例如:sql,mysql,oracle)的知识,想要成为一个好的测试工程师,应该要全面的发展,读懂需求分析文档(注:客户的要求),还有要学会写文档,语言的组织能力决定你这份文档的价值,这也是一种沟通能力的体现,比如写缺陷报告时:有一项是描述缺陷,这就能看出你的表达能力,给程序员能不能看懂就能体现沟通,最后就是整理文档和撰写测试总结报告,越是到最后越是要细心,因为软件永远都是有缺陷的,我们的细心可以让软件减少一些bug,不求最好,只求更好。
第五篇:软件测试工作规划
往往一个产品里,不是简简单单做开发和测试这么单一,通常,同时会有几个任务,例如,已经上线的版本的维护性测试,新开发功能的测试,差异化版本的测试等等。
这时,就要求测试经理规划好整个产品的测试工作。做测试规划注意这些点:
1. 总体规划
a)项目测试工作规划主要考虑的因素:任务,人员,环境,时间
b)先做分析:确定有哪些任务,在哪些时间点完成,任务的优先级
c)确定需要的资源:人,环境
d)合理安排人员负责任务,配置对应的资源
2. 对每一个任务,确定具体工作策略方法
a)测试目标,范围,方法,测试类型等等。
3. 测试规划在实际中需要调整;
a)问题是:我怎么来知道现在要不要加人减人,要不要延期,要不要加钱,如果不需要,
那什么时候应该做这些事情。
b)随时关注项目的进展和变化。
c)分析项目的变化对测试的影响。
d)提前考虑到这些变化对测试工作的影响,分析这些风险并想办法规避
4. 规划时和项目经理充分沟通;
5. 规划时,和有经验的测试管理者交流;
6. 规划完成后,进行评审;
文档为doc格式