测试的心得8篇

测试的心得8篇测试的心得篇1

虽然一如继往地写读书笔记，笔墨也浪费了不少。但真正坐下来利用大段的时间将自己的思路理清还没有过。因为最近有了肯定的时间,更因为狠狠地泡了一段时间测试论坛,下载学习了该网站的电子测试杂志之后，自己的思路最终开始清楚起来，朦朦胧胧地开始看清了远方的路,麻着胆子去分析一下自己,也学着展望一下将来了,毕竟摸黑走路的感觉很不好。

我觉得学习软件测试的通用技术与针对某类软件的测试技术外,还有一个重要的与技术无关的方面:业务学问.没有具体的业务学问很难发觉软件中潜在的规律错误甚至是需求上的错误,当然需求要根据特定的软件,但软件测试人员对需求理解的深入程度不应低于软件开发的人员.因为软件测试全部的根据来自于需求,而全部的需求来自于客户,甚至是我们的全部都来自于客户.识别需求后还必需转化为测试上的需求,毕竟测试人员看需求的角度和开发人员还是有区分的。

关于学习，我知道我并非计算机专业的学生,初涉软件测试行业，没有接受系统的培训，对软件测试一无所知，既不知道该测试什么，也不知道如何开始测试。但是,总该知道如何去学习，然而我认为，学习总该有必要的方法。

1.找个好师傅

这是最重要的一条了,也是公司提供的最好的一个条件.刚进来的时候,td,测试案例都有一个pm细心的和你讲,案例有什么方法来设计要留意哪些错误软件测试技术相关书籍名目、软件测试流程相关文档名目、产品业务相关的文档名目，一大堆的东西马上够你头晕的了.呵呵,还好,悟性不错,都囫囵吞枣地吞下去了。

2.学会读书

无论是神马专业，我始终确信，万变不离其宗，我知道，我不是这个专业的，但这个并不代表这我就不了解这个，再怎么不济，我也是从书本中走出来的，我信任，只要我努力地吧书本啃熟，我能够敏捷地融入到这个职业中去，从书本中找寻解决问题的方法。标记出自己所错误的。

3.与前辈们一起商量，多说

总有一天，我们会成为一位前辈，不过不是如今，至少如今我们应当好好的向别人学习，所以，我觉得，前辈是我们前进道路上不行或缺的一部分，他会成为引领我们前进的发动机，给我们指教，跟我们道工作的阅历。然而，我们也应当多说，我知道，前辈们给我们讲解，已经是很辛苦的事情，毕竟，这不是他们的义务。我们也应当多多说说我们的观点，这样既能够让人家了解我们的水平，也方便老师前辈们对我们进行指导。

这些天的学习，我也有了一点自己的心得体会

体会一：软件测试在整个软件周期中的重要性。

它存在于整个项目周期，在项目开始之初需求调研的时候就开始了，在形成需求规格说明书的时候就需要针对文档进行测试。这个环节在后续整个项目中占了很大的比重，能主导整个项目的走向，成败与否全在于开始阶段的决策。

体会二：软件测试的真正意义在于发觉错误，而不在于验证软件是正确的。

再严密的测试也不能完全发觉软件当中全部的错误，但是测试还是能发觉大部分的错误，能确保软件基本是可用的，所以在后续使用的过程中还需要加强快速响应的环节。结合软件测试的理论，故障暴露在最终客户端之前准时主动的去发觉并解决。这一点就需要加强研发队伍的建设。

测试的心得篇2

这个学期我学习了软件测试这门专业课程，在学期即将结束的时候，我也对这门课程建立基本的了解和理解。软件测试这门课程作为软件工程专业中一门很重要的课程，已经在软件领域占据了不行替代的角色，当一个软件从雏形到真正的在一台计算机上运行的时候，谁也不能保证计算机软件能一步到位的满足人们的需求。所以就有了软件测试，其目的是：第一是确认软件的质量，其一方面是确认软件做了你所期望的事情，另一方面是确认软件以正确的方式来做了这个事件。下面我简洁的写一下这个学期对课程的总结和收获。

我认为，在整个浩大的软件工程中，不管是需求分析、架构设计甚至是最终的debug，都会产生引入不管的机会，这就要求作为一个软件测试师要把握丰富的软件工程原理和学问。测试的工作将会存在于整个项目周期，即在项目开始时需要各种分析调研时就开始了。尤其是在形成需求规格说明书时就有对文档的测试需求，甚至主导整个项目的走向。

软件测试对规律思维、学习能力、反应要求很高，是否有严密的思维和逆向思维也特别重要。做测试还要考虑到全部出错的可能性，有时候还要用一些特别规的的测试方法。软件测试还很注重软件性能问题，也就是要保证软件运行得很好；不同的使用环境下，考虑软件的兼容性同样重要。对于测试员来讲，会比开发人员更加重视软件产品的质量问题。在测试过程中，测试者可能会为客户的需求角度考虑

到更多，由此我们可以认为测试人员有权利决定产品是否可以发布。然而，通过一个学期的学期，我们又不得不懂得，软件测试人员不是万能的，测试人员在面对一个设计烂编码烂的软件时，也是无法不低头的，再怎么测试它也变不成优秀的软件。

通过课上的理论因为课下的实践和后半学期又因为身体力行于群论坛里使我对测试方法和设计分析有了大致的接触和深入了解。收印象深刻的有一下几点。

1、最基本的测试的分类：从是否需要执行被测软件的角度，可分为静态测试和动态测试；从测试是否针对系统的内部结构和具体实现算法的角度来看，可分为白盒测试和黑盒测试。

2、然后就是，白盒测试中的规律驱动测试的覆盖率测试。

3、还有就是对于划分等价类和边界值法这一块，让我从模糊到明朗。

4、在初次写测试用例的时候，感觉真是纠结，用例写的很死板，看似简洁的一个填表工作，要写好真是不简洁。一开始写的比较不自然，有些生搬硬套，而且还很慢。在后来负责了对论坛新奇事版块的测试之后，明白了测试用例其实就是指导怎么去执行测试，而且书写设计测试用例也要以熟识软件的业务为前提，才能更好的去测试。

另外就是一个学期的学习让我纠正了几点误区：

1、有位大师曾说过：“软件测试的目的在于发觉错误，一个好的测试用例在于发觉从来未发觉的错误，一个胜利的测试是发觉了从未发觉的错误的测试。〞由此我自认为测试就是为了找到bug，然而一个学期的测试学习阅历告知我这是错误的，假如只是为了找到bug，那么bug会成天缠着你。

2、在大家协力测试论坛的时期内，我曾认为这种大量的重复性的工作真的很乏味，可是在这乏味中真心发生挺多有意思的bug，意想不到的bug，所以我认为只要把握了方法，在重复中寻到到创新的小惊喜，任何东西都有它的特点。

作为测试新手，通过一学期的学习，我认为能独立写测试计划，设计测试用例，精通一种测试工具，理解一种bug管理软件是新手晋级老手的必备素养。任重而道远？

在最终，我不得不提的就是细心和耐烦了。这是我认为这个学期测试课上收获最大的了，课程要求测试时必需细心和耐烦，我在想，假如以后真的工作在测试一系列的岗位上，要学会坐得住，用大量的时间和精力和bug斗争，分别、识别还有归类bug，是不是也能真的转变我马虎大意和三分钟热度的毛病。

最终感谢刘老师这学期的课程讲授，和实践中的指导和帮助。测试路程，路漫漫其修远兮，吾将上下而求索。

测试的心得篇3

曾经一度认为软件测试就是使用工具测试bug，如今看来不是这么一回事情，因为还是有手工测试〔执行测试〕，工具只是一个辅助，用工具你先要去了解测试的一些基本的东西〔如：测试用例，预期结果等〕，不是那按两下按钮就行了，就算是录制脚本，也需要看懂脚本的代码，工具不是万能的。

一开始接触软件测试觉得很枯燥乏味，全都是一些理论的东西，还不如回到小学学习语文呢，都是一些名词的解释，比方:黑盒测试，百合测试，系统测试。测试基础等等这些，老师都会去告知你这些名词什么意思，很无聊，到后来渐渐由语文变成了数学，开始练习测试用列的编写，这个还有点意思，因为这个更多时候能够表达个人的规律思维能力，再然后数学就转变成了英语，因为要使用到一些测试的工具，比方：winrunner工具，录制脚本它会产生一些代码，不过代码比较好理解，虽然是英文的但是还是很好看懂的。

学习软件测试一学期，其实我觉得最重要的是兴趣，有了兴趣还是不行的，还需要具备一些语言的基础，例如：c，java，c#等一些语言，这些语言你不需要去深入的学习，只需要了解，最重要的是了解数据库〔例如：sql，mysql，oracle〕的学问，想要成为一个好的测试工程师，应当要全面的进展，读懂需求分析文档〔注：客户的要求〕，还有要学会写文档，语言的组织能力决定你这份文档的价值，这也是一种沟通能力的表达，比方写缺陷报告时：有一项是描述缺陷，这就能看出你的表达能力，给程序员能不能看懂就能表达沟通，最终就是整理文档和撰写测试总结报告，越是到最终越是要细心，因为软件永久都是有缺陷的，我们的细心可以让软件削减一些bug，不求最好，只求更好。

测试的心得篇4

下面简洁谈谈我的几点体会：

体会一：软件测试在整个软件周期中的重要性。

它存在于整个项目周期，在项目开始之初需求调研的时候就开始了，在形成需求规格说明书的时候就需要针对文档进行测试。这个环节在后续整个项目中占了很大的比重，能主导整个项目的走向，成败与否全在于开始阶段的决策。

体会二：软件测试的真正意义在于发觉错误，而不在于验证软件是正确的。

再严密的测试也不能完全发觉软件当中全部的错误，但是测试还是能发觉大部分的错误，能确保软件基本是可用的，所以在后续使用的过程中还需要加强快速响应的环节。结合软件测试的理论，故障暴露在最终客户端之前准时主动的去发觉并解决。这一点就需要加强研发队伍的建设。

体会三：在系统性能测试方面需要重视。

经过这次培训中多个案例的讲解，让我了解到系统在上线之后会有许多不能预知的性能问题，需要在上线之前实现进行模拟，以规避风险，包括大数据量访问，高并发数等等。

当然也有许多应对手段，没有哪种手段可称为最完善，只有最合适的，需要敏捷把握，综合运用以到达最优程度，这是个很值得讨论的领域。

下面是本人的几点想法：

想法一：加强系统上线前的性能测试。

目前我们在项目建设过程中对性能压力测试的重视程度还不太高，厂家也很少有雇佣第三方的测试机构。而是在现网进行试用，遇到问题再解决，可能会产生滞后问题，影响客户使用。期望以后能在性能测试方面提高重视程度，加大人力投入，以保证系统上线后能够稳定运行。

想法二：适当介入相关项目研发

对于快速响应这块，我们不能一味依靠厂家，而期望自己就能快速响应，准时将问题解决。这也是一个比较长远的问题，需要加强研发力量的投入。

我个人是做开发出身，有此类阅历，当时是在客户现场，因为了解系统内部结构，能够在第一时间排查解决客户所反馈问题。

如今系统完全由厂家开发，很难了解内部结构，或许会造成后期维护困难。所以，是否应当针对某些项目介入厂家研发工作，比方请厂家提供源代码等相关要素，以增进维护人员对系统的了解。

最终再次感谢公司提供的平台，感谢领导的信任，让我有机会得到更深层次的学习以及展示自己能力的机会，我也会尽我所能来完善工作的系统，提高整体工作效率，为南方电网的进展建设提供更坚实，优秀的支撑服务平台。

测试的心得篇5

在支付宝测试分析的角色和系统分析的角色是对应的，只不过一个是测试类的另外一个是开发类的。系分下面会有相应开发，测分下面会有相应的测试用例编写和执行人员。也就是说测试分析文档是对测试执行人员的一个指导(在我原来的理解方式上，觉得测试分析人员应当是用例编写人员;而在这里测试分析人员是从业务上去分析的，用例是用例执行人员来写并且执行的)。

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

1、太关注开发的内部实现规律。建议：将开发内部实现规律看成一个黑盒子，测试分析要从这个黑盒子的输入和输出上去看开发内部实现规律是不是有问题，而不应当先去了解开发的实现规律然后根据他们的思路去分析。

2、分析文档写的过于细致，甚至将用例的步骤都写了出来。建议：测试分析要从全局上去看问题，详情的东西即便是知道的，也要留给之后的用例编写人员去了解(就像系分之后的开发需要去写细致设计的道理一样)，这样后面的人才会自己主动去想问题。

3、分析文档要考虑维护性问题，不要出现类似比方还款中状态为r这种具体的数据内容。因为我的分析是对后续用例编写人员的一个指导性的文档，所以假如侧分这么写很有可能导致用例也照着这么写，其实不管侧分和用例都不应当具体写到r这么详情，否则的话开发稍作变动我们就要相应变动我们的用例

4、没有明确测试目的。review用例的时候，没有提出每个用例需要明确一个测试目的，让别人来看这个用例的时候能明白到底是怎么回事。

总结：

1、以后写测试分析文档，根据仅仅是prd文档，必需抛开开发实现规律部分(即不去看系分文档)，待测分出来之后，再去看系分文档，相互看看彼此考虑的是否存在遗漏的地方。等到在写用例的时候再让写用例的人和相应的开发去相互明确更详情的东西。

2、写用例我们目前都是仅仅做到对流程上的每个节点去单独分析，细到看输出的时候会关注到数据库表的一个改变。但是除了以上部分，其实还少了对整体流程的关注，需要增加业务流程的各条路径的一个覆盖，在针对路径的用例中不需要关注到数据库表级那么细。

3、在做流程路径覆盖之前应当画一个路径图，这个图的画法考虑各个入口的不同分开画流程图，分别进行路径覆盖。

测试的心得篇6

写在前面：找工作真不简单，来北京呆了一个多月，都没找到一个合适的工作

大三的时候，一次计算机等级考试，由于考c，数据库，都没过，就报了个四级软件测试工程师。抱着试试看的看法学了一个月做了几套题，就拿下了一个四级证书。当时想的是，这都行，水分有点大吧。

原来想找一份网站开发的工作，技术不够硬，始终在北京飘着飘着啊。通过一个学姐，得到了一个软件测试面试的机会。于是半只脚踏入了软件测试的大门，因为我如今刚开始写测试用例，还没有真正的融入到团队中去。

实习生，直接领导给我支配了一个实习计划，严格根据实习计划执行。首先就是看公司软件的手册，要了解产品，知道软件的基本操作流程，不会了就问带我的师傅。就这样学了一个礼拜，不同于用一款软件，在用的过程中要去思索，这个功能为什么有，这个功能要实现什么。忘了说了，如今产品做的是功能测试，比较简洁，所以分到了这个组里。一周之后带我的师傅检查了一下我的学习成果，具体操作、实现软件的一些功能，然后就几个主要的功能点以及一些需要特殊留意的关键词，给我做了细致的讲解。

然后给我了两个功能界面，让我写一些测试用例，开始感觉没什么可写的，这两个功能实现起来很简单的。第一天试着写了几个，然后拿给师傅看，因为不知道从哪方面入手，虽然看了一些以前的测试用例，但是亲自写还是第一次，所以有些拿不准。

就这样，写了几天的测试用例，一个功能点一个功能点的细分。写的差不多了，就开始看一些技术类的博客，尤其是软件测试中功能测试用例的写法。看着博客中提到的一些东西，对比自己写的测试用例，看看是不是满足要求。就这样自己一点一点的修改。

其实压力还是蛮大的，由于要测试的系统需要测试多个不同的数据库，以及不同的操作系统是软件的执行，所以有了各种学习目标，但是还是没有清楚的目标。努力吧，既然踏入了这个行业，就要努力的去汲取学问，不断学习，不断进步！

测试的心得篇7

?软件测试方法和技术》这门课程，还是由张建东老师教我们的。在张老师的讲解下，我深刻的体会到软件测试是很有必要的。一个软件，从最开始的可行性分析、需求分析、概要设计、细致设计、编写代码。这一系列的开发之下。千辛万苦的，花费了大量的人力物力、金钱时间，最终把软件给做出来了。你试着想一下，要是送到客户的手上，客户突然发觉，软件用不了，或者是软件存在很大的缺陷。导致软件不好用、甚至比原先没有这个软件，还麻烦了。客户是很生气的。客户一生气，就导致客户不会付钱。这最终，项目失败，造成资源的大量浪费，所以说软件测试还是很有必要的。再者就是，软件测试可以发觉软件的缺陷，从而通知编程人员不断改良软件。在这样不断测试，不断改良的状况下。将软件性能不断提高，软件变得越来越好用。

软件测试，旨在发觉软件的缺陷。可以这样说，软件测试就是以发觉软件缺陷，为最终目的的测试活动。它通过软件测试方法，白盒的、黑盒的、静态的或是动态的。借助软件测试工具，来找到缺陷。然后在缺陷评审和确认之后将缺陷记录下来，并用缺陷管理工具管理，细致描述，关注软件缺陷的发生周期。对它的严重性、和优先级下一个定义。书写软件缺陷报告，具名缺陷的重现步骤、测试的期望结果与实际结果、还有相关图片、文字资料。提交给软件编程人员，来完成软件缺陷的修复。

软件测试的方法，包括：白盒测试和黑盒测试。其中，白盒测试之中，有含有：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖、等方法。黑盒测试方法中，有：等价类划分法、边界值分析法、判定表法、因果图法等。软件测试方法，根据是否运行代码来看，可以分为：静态测试和动态测试。其中静态测试有，对代码的走查和评审。动态测试，则是要通过运行代码来执行。白盒测试多用于软件的单元测试上，黑盒测试多用于功能性测试上。代码的静态测试和动态测试，则是每一个软件项目都必需的。

单元测试，多构造桩函数或是驱动程序来测试。一般借助与各种软件测试工具。软件测试，或者说程序测试。一般先是进行单元测试。单元测试，修改完单元之中的缺陷、错误之后，就是集成测试。集成测试多针对程序功能进行测试，看程序的各项功能是否到达要求，是否齐全。集成测试之后就是系统测试。系统测试是针对整个软件系统的。看软件系统是否到达性能的要求。从而改良代码，以求到达系统的严格要求。最终就是验收测试，这个测试，一般都分成两半来做。一半是，程序员模拟客户环境，进行测试。而，另一半则是，真正的客户参加的测试。最大程度的表达客户的真实环境。客户在试运行的状况下，看是否会发觉，平常发觉并且以前的环境发觉不了的问题。

验收测试，包含对界面的测试和软件可用性的测试，运用尼尔森十大原则，来测试软件是否好用。软件是否到达用户的对软件界面的需求。

无论是软件编写，还是软件测试，都需要相应的文档管理。还有针对软件测试制定的测试计划，软件测试执行等。

通过本学期的学习，我感受到软件测试是一门特别需要学习的课程。即使作为考察课程，它也是软件行业人士所必需了解的学问。它对软件工程项目的作用是至关重要的。如今，作为学生的我所做的项目虽然都是一些小的项目，但是在小组共同开发的时候还是需要用到

项目的测试。如今这门课程我学的还不是很好，但我信任在今后的实训及工作当中，能够更好的体验和感受到项目测试的精髓，对软件项目测试有更深入的了解。我也期望，学校的老师能够在今后的教学当中重视软件项目测试课程，多让学生了解实例，去感受、体会软件项目测试所遇到的问题和解决方案，理解软件项目测试的精髓。

测试的心得篇8

20__年x月x日。我怀着对提高并实现自我价值的心态，走进深圳走秀网络科技有限公司的大门，开始了自己大学里兼职实习工作。转瞬间。6个月的实习时间就要过去了。回想起这段时间的工作过程，我深深的认识到在走秀网实习的选择是肯定正确的，走秀网和公司的同事们对我个人产生的主动影响也是超越我料想之中的。现将这段时间的工作进行如下总结。

首先，要具有良好的学习能力。刚进走秀，带我的老大是哈尔滨人，我跟她很投缘。开始的一个星期，我只是熟识公司的一些业务和我们前端的测试范围，在熟识业务的过程中，我发觉这些页面上的东西看上去挺简洁的，但是要深入了解还是需要很长的一段时间。期间老大叫一个老员工带着我去测试一些之前xiu2.0所遗留的简洁的bug。走秀网的测试部还比较大，所以对