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

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

软件测试心得体会篇2

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

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

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

1.找个好师傅

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

2.学会读书

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

3.与前辈们一起讨论，多说

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

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

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

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

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

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

软件测试心得体会篇3

一个从点点点开始，一切未知的故事。

在最初的认知里，软件测试这个行业需要掌握的只是简单的点点点，但是怎么点，从那点，为什么点一直是我内心的疑惑，所以，为了让自己能够点点点，更明白的点点点，学习软件测试并在这个行业发展成了我现阶段的目标。

需求澄清阶段：从二三百字的英文需求文档，像一个产品的使用说明书，简单明了的交代了是什么，怎么用。到后来几千字的需求澄清文档，是一次思维的转变。从习以为常的使用各种软件到思考怎样去制造出来一个软件，一个成熟的软件具备了哪些功能才能够让我们去使用，要同时从人和计算机的角度去思考问题。从人的角度出发，我们要考虑我们所需要的软件能够帮助我们干什么，在哪些方面减少我们的人工成本，怎样才是使用起来方便快捷的。从代码的角度出发，代码能够实现的功能有哪些，其中的逻辑顺序是怎样的，怎样才能用最少的代码实现最多的功能。尽最大的努力去提出尽可能多的需求。

思维导图阶段：思维导图，像字面意思一样，是思维的引导流程图。相比于繁琐的文字信息，它能够有逻辑有顺序的用最少的.文字展现一个软件应有的功能。也能够说明在人们对于软件错误的操作后，软件能够明确的告知。

测试计划阶段：计划，顾名思义，对任何一件事情都是需要有计划的，它就像是完成目标的开始，我们在对某件事情有了初步的了解之后，怎样去完成这件事情，谁去完成这件事情，在什么环境下完成这件事情，怎样就算达到目标，不管哪一方面，我们都需要一个简单的计划，这样才能更好的掌控事情的发展形势。

测试设计阶段：软件测试需要我们去测试什么，我们怎样才能测试出来我们想要的东西，根据什么去执行测试。或许这就是测试设计的意义。根据对需求的理解，我们怎样才算完成对需求的开发，是测试设计的重点，也是测试用例编写的依据。我们需要全方面的考虑问题。不仅仅是它能不能正常使用，而且也包括在异常情况下的处理；在不同条件，不同环境下功能能否正常使用；一个软件前端和后端所能显示的信息情况是否一致。这些都不再是概括性的描述，而是具体的实例。

需求澄清到用例开发，二三百字到上万字的文档，对于软件测试这个行业有了全新的认识。不止是简单的点点点，是对一个项目上线前的最后一道防线，尽可能多的去避免缺陷产生是软件测试的职责。

对于现阶段的自己，想要更深层次的了解软件测试，需要的是时间和精力的付出。只希望现在的自己，能够快速的掌握软件测试的基础知识，进入这个行业。在实践中成长，在成长中学习。

软件测试心得体会篇4

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

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

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

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

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

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

总结：

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

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

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

软件测试心得体会篇5

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

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

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

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

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

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

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

软件测试心得体会模板5篇相关文章：