软件测试心得体会(真题9篇) .pdfVIP

软件测试心得体会(真题9篇)--第1页

软件测试心得体会(通用9篇)

软件测试心得体会篇1

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

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

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

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

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

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

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

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

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

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

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

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

会自己主动去想问题。

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

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

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

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

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

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

总结：

软件测试心得体会(真题9篇)--第1页

软件测试心得体会(真题9篇)--第2页

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

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

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

相明确更细节的东西。

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

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

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

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

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

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

软件测试心得体会篇2

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

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

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

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

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

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

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

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

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

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

软件测试心得体会(真题9篇)--第2页

软件测试心得体会(真题9篇)--第3页

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

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

问，高并发数等等。

当然也有很多应对手段，没有哪种手段可称为最完美，只有最