admin管理员组

文章数量:1531657

2024年7月18日发(作者:)

软件测试心得

软件测试心得篇1

接触计算机程序设计已经快7年了,从事专门的软件测试也快四年了,强子

也是在阴差阳错中踏入软件测试领域,一开始只想做一个特牛的程序设计师,可

是毕业后找工作却找了个软件测试的工作,在一些彷徨与犹豫中接受了这个职业

并且到现在也做得挺开心,也是由于那时我们这个业务刚成立不久,由于表现还

不错所以一个阴差阳错的机会被升为team leader,到现在也还在同一家公司做

着测试的工作。

先讲讲做manager的一些体会,其实具体做什么事真的不是那么重要,关键

是做事的方法,做人的章法,特别是对一个manager来说,方法比技术更重要,

真的是这样,当然我也很喜欢研究技术,技术能让我找到更多的自信和成就感,

但是面对着手下一帮兄弟姐妹,一个人的技术就显得有些力不从心了,这个时候

得把你的知识share给大家,当然形式多种多样,比如写一份文档,做一个正式

的training,给大家营造一种不耻下问的环境或者大家一起讨论一些难题等等。

当然还有很重要的一点,一定不能说“我不知道”,作为一个头,如果你真的不

知道,那你得想办法通过一些手段与员工一起把这个问题解决了,坚决不能说“我

不知道,你自己看着做吧“等,本来员工是很尊重你的,这些话将直接导致其鄙

视你。

另外就是做头的,特别像咱这种中低层的头,不像中高层的领导,咱们考虑

事情的角度不一样,当这种小头儿的最重要的两件事:把事情做对做好,与员工

打成一片。首先得确保把事情做对咯,然后带领大家朝着这一个对的方向前进进

而把事情做好,在99%的时间里,你是和你的兄弟姐妹们呆在一起而不是和老板,

所以这个过程中的与员工的关系一定要融洽且单纯,不能让员工对你有隔阂感,

经常一起吃饭,摆摆龙门阵,唠唠家常,开开玩笑,不要摆架子,在一个公司里

最不能摆架子的就是这种小头儿(或称之为leader或者manager一类),这就像

个村官一样,小样的,还真把自己当回事儿呢?

做开发还是做测试?很多人讨论甚至争吵,强子认为之所以会有这样的问题

是因为中国还没有把软件行业普及好,大家还停留在江民时代,求伯君时代,认

为做开发的才是牛人,才有前途。而事实上,现在的软件是一个系统工程,缺开

发,缺测试,缺文档都不行,都可能直接导致失败,谁最牛?强子认为写文档的

人最牛,那咱们都去写文档?不过从强子面试的很多人当中来看,还是有更多的

人愿意做开发,这不能不说是一大遗憾,强子无能,也只能聊以文字来表达自己

对测试的热爱。测试犹如开发一样,也是一门深不见底的大学问,咱以后慢慢讨

论。

关于项目管理,这又是一门大学问,强子在这几年当中也经历过无数次的版

本更新,版本发布或者一些内部的项目,对项目管理略知一二,有空时强子自会

附上一些体会。我想项目管理最本质的一点:保护项目团队,保护项目经理,去

除杂音。项目经理这活,不好干,要职位没职位,要资金没资金,做好了皆大欢

喜,做不好就卷铺盖走人,挺难,不过咱有咱的方式方法,怕啥?

软件测试心得篇2

在支付宝测试分析的角色和系统分析的角色是对应的,只不过一个是测试类

的另外一个是开发类的。系分下面会有相应开发,测分下面会有相应的测试用例

编写和执行人员。也就是说测试分析文档是对测试执行人员的一个指导(在我原

来的理解方式上,觉得测试分析人员应该是用例编写人员;而在这里测试分析人

员是从业务上去分析的,用例是用例执行人员来写并且执行的)。

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

1、太关注开发的内部实现逻辑。建议:将开发内部实现逻辑看成一个黑盒

子,测试分析要从这个黑盒子的输入和输出上去看开发内部实现逻辑是不是有问

题,而不应该先去了解开发的实现逻辑然后按照他们的思路去分析。

2、分析文档写的过于详细,甚至将用例的步骤都写了出来。建议:测试分

析要从全局上去看问题,细节的东西即便是知道的,也要留给之后的用例编写人

员去了解(就像系分之后的开发需要去写详细设计的道理一样),这样后面的人才

会自己主动去想问题。

3、分析文档要考虑维护性问题,不要出现类似比如还款中状态为“R”这种

具体的数据内容。因为我的分析是对后续用例编写人员的一个指导性的文档,所

以如果侧分这么写很有可能导致用例也照着这么写,其实不管侧分和用例都不应

该具体写到R这么细节,否则的话开发稍作变动我们就要相应变动我们的用例

4、没有明确测试目的。review用例的时候,没有提出每个用例需要明确一

个测试目的,让别人来看这个用例的时候能明白到底是怎么回事。

总结:

1、以后写测试分析文档,依据仅仅是prd文档,必须抛开开发实现逻辑部

分(即不去看系分文档),待测分出来之后,再去看系分文档,互相看看彼此考虑

的是否存在遗漏的地方。等到在写用例的时候再让写用例的人和相应的开发去互

相明确更细节的东西。

2、写用例我们目前都是仅仅做到对流程上的每个节点去单独分析,细到看

输出的时候会关注到数据库表的一个变化。但是除了以上部分,其实还少了对整

体流程的关注,需要增加业务流程的各条路径的一个覆盖,在针对路径的用例中

不需要关注到数据库表级那么细。

3、在做流程路径覆盖之前应该画一个路径图,这个图的画法考虑各个入口

的不同分开画流程图,分别进行路径覆盖。

软件测试心得篇3

接触计算机程序设计已经快7年了,从事专门的软件测试也快四年了,强子

也是在阴差阳错中踏入软件测试领域,一开始只想做一个特牛的程序设计师,可

是毕业后找工作却找了个软件测试的工作,在一些彷徨与犹豫中接受了这个职业

并且到现在也做得挺开心,也是由于那时我们这个业务刚成立不久,由于表现还

不错所以一个阴差阳错的机会被升为team leader,到现在也还在同一家公司做

着测试的工作。

先讲讲做manager的一些体会,其实具体做什么事真的不是那么重要,关键

是做事的方法,做人的章法,特别是对一个manager来说,方法比技术更重要,

真的是这样,当然我也很喜欢研究技术,技术能让我找到更多的自信和成就感,

但是面对着手下一帮兄弟姐妹,一个人的技术就显得有些力不从心了,这个时候

得把你的知识share给大家,当然形式多种多样,比如写一份文档,做一个正式

的training,给大家营造一种不耻下问的环境或者大家一起讨论一些难题等等。

当然还有很重要的一点,一定不能说“我不知道”,作为一个头,如果你真的不

知道,那你得想办法通过一些手段与员工一起把这个问题解决了,坚决不能说“我

不知道,你自己看着做吧“等,本来员工是很尊重你的,这些话将直接导致其鄙

视你。

另外就是做头的,特别像咱这种中低层的头,不像中高层的领导,咱们考虑

事情的角度不一样,当这种小头儿的最重要的两件事:把事情做对做好,与员工

打成一片。首先得确保把事情做对咯,然后带领大家朝着这一个对的方向前进进

而把事情做好,在99%的时间里,你是和你的兄弟姐妹们呆在一起而不是和老板,

所以这个过程中的与员工的关系一定要融洽且单纯,不能让员工对你有隔阂感,

经常一起吃饭,摆摆龙门阵,唠唠家常,开开玩笑,不要摆架子,在一个公司里

最不能摆架子的就是这种小头儿(或称之为leader或者manager一类),这就像

个村官一样,小样的,还真把自己当回事儿呢?

做开发还是做测试?很多人讨论甚至争吵,强子认为之所以会有这样的问题

是因为中国还没有把软件行业普及好,大家还停留在江民时代,求伯君时代,认

为做开发的才是牛人,才有前途。而事实上,现在的软件是一个系统工程,缺开

发,缺测试,缺文档都不行,都可能直接导致失败,谁最牛?强子认为写文档的

人最牛,那咱们都去写文档?不过从强子面试的很多人当中来看,还是有更多的

人愿意做开发,这不能不说是一大遗憾,强子无能,也只能聊以文字来表达自己

对测试的热爱。测试犹如开发一样,也是一门深不见底的大学问,咱以后慢慢讨

论。

关于项目管理,这又是一门大学问,强子在这几年当中也经历过无数次的版

本更新,版本发布或者一些内部的项目,对项目管理略知一二,有空时强子自会

附上一些体会。我想项目管理最本质的一点:保护项目团队,保护项目经理,去

除杂音。项目经理这活,不好干,要职位没职位,要资金没资金,做好了皆大欢

喜,做不好就卷铺盖走人,挺难,不过咱有咱的方式方法,怕啥?

软件测试心得篇4

通过这次课程设计的实训,增加了我学习软件技术的兴趣,虽然还不明确软

件技术包含的具体内容,但从C++语言这门课程开始,已发现程序设计的乐趣,

在学习C++语言的过程中也学到了许多计算机应用基础知识,对计算机的机体也

有了一个大体的了解。在实际操作过程中犯的一些错误还会有意外的收获,感觉

实训很有意思。在具体操作中对这学期所学的C++语言的理论知识得到巩固,达

到实训的基本目的,也发现自己的不足之出,在以后的上机中应更加注意,同时

体会到C++语言具有的语句简洁,使用灵活,执行效率高等特点。发现上机实训

的重要作用,特别是对数组和循环有了深刻的理解。

通过实际操作,学会C++语言程序编程的基本步骤、基本方法,开发了自己

的逻辑思维能力,培养了分析问题、解决问题的能力。深刻体会到“没有做不到

的,只有想不到的”,“团结就是力量”,“实践是检验真理的标准”,“不耻

下问”的寓意。

在此希望以后应多进行这样的实训,加长设间,培养学生独立思考问题的能

力,提高实际操作水平。

通过本次项目实训我要感谢学校领导给我们提供了这次机会,让我们自己有

出去体会生活,自己做项目的深刻体会。这次实训让我明白我自己之前的学习还

是差很多,只有不断的努力,才能学好。还要感谢达内公司对我的指导,我自己

的努力固然重要,但是达内的优秀教师给我做的培训,讲的理论都让我受益匪浅,

让我对软件有了一个新的概念新的理解。

软件测试心得篇5

这个暑假惠普派人到我们学校来开展软件测试培训。老师说机会难得所以我

就参加了,说实话每天在教师从早晨坐到下午,中间只有一个半小时休息时间,

这样还是相当累人的。我们第一天开始就觉得这个简直比平常上课还累啊。

不过 看到老师讲得如此认真,看到惠普如此强大,我看在座的学员都听得

非常认真。所以向我这种上课从来不听讲的这回都听得认真得不得了,呵呵。

前两天确实还是有点累,讲的也是理论课,而且以前我们从来没有接触过测

试这个行业,所以听得也嘿吃力。但是老师给我们讲了不少他们的工作经验和惠

普这种世界五百强美国十强的企业文化,鄙人是深受教育啊。

后两天我们每个人带一个笔记本进行上机操作了。我们的第一个任务就是安

装软件,那个软件好大啊 ,整整2个G。我们考啊考啊考了好久才考完。软件

叫QTP,就是惠普的快速测试专业版。确实是一个强大的软件,呵呵 大家用了

就晓得了!

有 了电脑自然好耍了,我们休息的 时候就上网啊,我看猫和老鼠都看得差

不多了。不过那个软件毕竟是大软件,操作还是比较复杂,而且全英文版,对我

这种英语水平的人确实有点难以接受a。不过 呢,我还是在老师的敬业精神鼓

励下学到了不少知识 受益匪浅啊,单词也记到了不少!离六级又近了一步!!

四天的培训在今天就彻底的结束 了,下午老师给我们开 座谈会,问我们有

什么问题,结果呢我们一点问题都没得。老师教得好啊 呵呵!我们没得问题 老

师又只有给我们说他的光辉历史了撒 。什么当年大学毕业了差点工作都没找到

啊,什么当年英语学得最撇啊,还有找不到工作在网吧郁闷打游戏啊 呵呵。

我记得老师说得最有感情的一句话就是“社会是黑暗的啊”。我们对这句话

都是深信不疑!所以以后呢,要好好努力啊,不管社会有 好黑暗你都能找到光明,

生活就是如此,时间本就平凡。好好干好好干!

软件测试心得篇6

软件测试在整个软件周期中的重要性,它存在于整个项目周期,在项目开始

之初需求调研的时候就开始了,在形成需求规格说明书的时候就需要针对文档进

行测试。这个环节在后续整个项目中占了很大的比重,能主导整个项目的走向,

成败与否全在于开始阶段的决策。

再严密的测试也不能完全发现软件当中所有的错误,但是测试还是能发现大

部分的错误,能确保软件基本是可用的,所以在后续使用的过程中还需要加强快

速响应的环节。结合软件测试的理论,故障暴露在最终客户端之前及时主动的去

发现并解决。这一点就需要加强研发队伍的建设。

经过这次培训中多个案例的讲解,让我了解到系统在上线之后会有很多不能

预知的性能问题,需要在上线之前实现进行模拟,以规避风险,包括大数据量访

问,高并发数等等。

当然也有很多应对手段,没有哪种手段可称为最完美,只有最合适的,需要

灵活掌握,综合运用以达到最优程度,这是个很值得研究的领域。

目前我们在项目建设过程中对性能压力测试的重视程度还不太高,厂家也很

少有雇佣第三方的测试机构。而是在现网进行试用,遇到问题再解决,可能会产

生滞后问题,影响客户使用。希望以后能在性能测试方面提高重视程度,加大人

力投入,以保证系统上线后能够稳定运行。

对于快速响应这块,我们不能一味依赖厂家,而希望自己就能快速响应,及

时将问题解决。这也是一个比较长远的问题,需要加强研发力量的投入。

我个人是做开发出身,有此类经验,当时是在客户现场,因为了解系统内部

结构,能够在第一时间排查解决客户所反馈问题。

现在系统完全由厂家开发,很难了解内部结构,或许会造成后期维护困难。

所以,是否应该针对某些项目介入厂家研发工作,比如请厂家提供源代码等相关

要素,以增进维护人员对系统的了解。

最后再次感谢公司提供的平台,感谢领导的信任,让我有机会得到更深层次

的学习以及展示自己能力的机会,我也会尽我所能来完善工作的系统,提高整体

工作效率,为南方电网的发展建设提供更坚实,优秀的支撑服务平台。

本文标签: 测试问题开发用例软件测试