软件测试实习总结3篇范文.doc

《软件测试实习总结3篇范文.doc》由会员分享，可在线阅读，更多相关《软件测试实习总结3篇范文.doc（6页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、 软件测试实习总结3篇范文 大三的时候，一次计算机等级考试，由于考c，数据库，都没过，就报了个四级软件测试工程师。抱着试试看的态度学了一个月做了几套题，就拿下了一个四级证书。当时想的是，这都行，水分有点大吧 原来想找一份网站开发的工作，技术不够硬，始终在北京飘着飘着啊。通过一个学姐，得到了一个软件测试面试的时机。于是半只脚踏入了软件测试的大门，由于我现在刚开头写测试用例，还没有真正的融入到团队中去。 实习生，直接领导给我安排了一个实习规划，严格根据实习规划执行。首先就是看公司软件的手册，要了解产品，知道软件的根本操作流程，不会了就问带我的师傅。就这样学了一个礼拜，不同于用一款软件，在用的过程中

2、要去思索，这个功能为什么有，这个功能要实现什么。忘了说了，现在产品做的是功能测试，比拟简洁，所以分到了这个组里。一周之后带我的师傅检查了一下我的学习成果，详细操作、实现软件的一些功能，然后就几个主要的功能点以及一些需要特殊留意的关键词，给我做了具体的讲解。 然后给我了两个功能界面，让我写一些测试用例，开头感觉没什么可写的，这两个功能实现起来很简单的。第一天试着写了几个，然后拿给师傅看，由于不知道从哪方面入手，虽然看了一些以前的测试用例，但是亲自写还是第一次，所以有些拿不准。 就这样，写了几天的测试用例，一个功能点一个功能点的细分。写的差不多了，就开头看一些技术类的博客，尤其是软件测试中功能测试

3、用例的写法。看着博客中提到的一些东西，比照自己写的测试用例，看看是不是满意要求。就这样自己一点一点的修改。 其实压力还是蛮大的，由于要测试的系统需要测试多个不同的数据库，以及不同的操作系统是软件的执行，而我只懂一点的msql，对linux一窍不通。所以有了各种学习目标，但是还是没有清楚的目标。努力吧，既然踏入了这个行业，就要努力的去吸取学问，不断学习，不断进步! #690272软件测试实习总结2 接触计算机程序设计已经快7年了，从事特地的软件测试也快四年了，强子也是在阴差阳错中踏入软件测试领域，一开头只想做一个特牛的程序设计师，可是毕业后找工作却找了个软件测试的工作，在一些彷徨与迟疑中承受了这

4、个职业并且到现在也做得挺快乐，也是由于那时我们这个业务刚成立不久，由于表现还不错所以一个阴差阳错的时机被升为team leader，到现在也还在同一家公司做着测试的工作。 先讲讲做manager的一些体会，其实详细做什么事真的不是那么重要，关键是做事的方法，做人的章法，特殊是对一个manager来说，方法比技术更重要，真的是这样，固然我也很喜爱讨论技术，技术能让我找到更多的自信和成就感，但是面对着手下一帮兄弟姐妹，一个人的技术就显得有些力不从心了，这个时候得把你的学问share给大家，固然形式多种多样，比方写一份文档，做一个正式的training，给大家营造一种不耻下问的环境或者大家一起争论一

5、些难题等等。固然还有很重要的一点，肯定不能说“我不知道”，作为一个头，假如你真的不知道，那你得想方法通过一些手段与员工一起把这个问题解决了，坚决不能说“我不知道，你自己看着做吧“等，原来员工是很敬重你的，这些话将直接导致其鄙视你。 另外就是做头的，特殊像咱这种中低层的头，不像中高层的领导，咱们考虑事情的角度不一样，当这种小头儿的最重要的两件事：把事情做对做好，与员工打成一片。首先得确保把事情做对咯，然后带着大家朝着这一个对的方向前进进而把事情做好，在99%的时间里，你是和你的兄弟姐妹们呆在一起而不是和老板，所以这个过程中的与员工的关系肯定要融洽且单纯，不能让员工对你有隔膜感，常常一起吃饭，摆摆

6、龙门阵，唠唠家常，开开玩笑，不要摆架子，在一个公司里最不能摆架子的就是这种小头儿(或称之为leader或者manager一类)，这就像个村官一样，小样的，还真把自己当回事儿呢? 做开发还是做测试?许多人争论甚至争吵，强子认为之所以会有这样的问题是由于中国还没有把软件行业普及好，大家还停留在江民时代，求伯君时代，认为做开发的才是牛人，才有前途。而事实上，现在的软件是一个系统工程，缺开发，缺测试，缺文档都不行，都可能直接导致失败，谁最牛?强子认为写文档的人最牛，那咱们都去写文档?不过从强子面试的许多人当中来看，还是有更多的人情愿做开发，这不能不说是一大圆满，强子无能，也只能聊以文字来表达自己对测试

7、的喜爱。测试如同开发一样，也是一门深不见底的大学问，咱以后渐渐争论。 关于工程治理，这又是一门大学问，强子在这几年当中也经受过很多次的版本更新，版本公布或者一些内部的工程，对工程治理略知一二，有空时强子自会附上一些体会。我想工程治理最本质的一点：爱护工程团队，爱护工程经理，去除杂音。工程经理这活，不好干，要职位没职位，要资金没资金，做好了皆大高兴，做不好就卷铺盖走人，挺难，不过咱有咱的方式方法，怕啥? #690274软件测试实习总结3 在支付宝测试分析的角色和系统分析的角色是对应的，只不过一个是测试类的另外一个是开发类的。系分下面会有相应开发，测分下面会有相应的测试用例编写和执行人员。也就是说

8、测试分析文档是对测试执行人员的一个指导(在我原来的理解方式上，觉得测试分析人员应当是用例编写人员;而在这里测试分析人员是从业务上去分析的，用例是用例执行人员来写并且执行的)。 而通过这次的这次分析觉得自己的测分还存在以下的问题： 1、太关注开发的内部实现规律。建议：将开发内部实现规律看成一个黑盒子，测试分析要从这个黑盒子的输入和输出上去看开发内部实现规律是不是有问题，而不应当先去了解开发的实现规律然后根据他们的思路去分析。 2、分析文档写的过于具体，甚至将用例的步骤都写了出来。建议：测试分析要从全局上去看问题，细节的东西即便是知道的，也要留给之后的用例编写人员去了解(就像系分之后的开发需要去写

9、具体设计的道理一样)，这样后面的人才会自己主动去想问题。 3、分析文档要考虑维护性问题，不要消失类似比方还款中状态为“R”这种详细的数据内容。由于我的分析是对后续用例编写人员的一个指导性的文档，所以假如侧分这么写很有可能导致用例也照着这么写，其实不管侧分和用例都不应当详细写到R这么细节，否则的话开发稍作变动我们就要相应变动我们的用例 4、没有明确测试目的。review用例的时候，没有提出每个用例需要明确一个测试目的，让别人来看这个用例的时候能明白究竟是怎么回事。 总结： 1、以后写测试分析文档，依据仅仅是prd文档，必需抛开开发实现规律局部(即不去看系分文档)，待测分出来之后，再去看系分文档，相互看看彼此考虑的是否存在遗漏的地方。等到在写用例的时候再让写用例的人和相应的开发去相互明确更细节的东西。 2、写用例我们目前都是仅仅做到对流程上的每个节点去单独分析，细到看输出的时候会关注到数据库表的一个变化。但是除了以上局部，其实还少了对整体流程的关注，需要增加业务流程的各条路径的一个掩盖，在针对路径的用例中不需要关注到数据库表级那么细。 3、在做流程路径掩盖之前应当画一个路径图，这个图的画法考虑各个入口的不同分开画流程图，分别进展路径掩盖。 测试总结汇报