软件测试心得体会.docVIP

软件测试心得体会

我们心里有一些收获后，应该马上记录下来，写一篇心得体会，这样可以不断更新自己的想法。应该怎么写才合适呢？以下是小编精心整理的软件测试心得体会，供大家参考借鉴，希望可以帮助到有需要的朋友。

软件测试心得体会1

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

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

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

1.找个好师傅

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

2.学会读书

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

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

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

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

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

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

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

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

软件测试心得体会2

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

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

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

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

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

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