测试心得体会6篇.pdf

篇

6篇

测试心得体会

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

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

测分下面会有相应的测试用例编写和执行人员。也就是说测试分

析文档是对测试执行人员的一个指导(在我原来的理解方式上，

觉得测试分析人员应该是用例编写人员;而在这里测试分析人员

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

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

1、太关注开发的内部实现逻辑。建议：将开发内部实现逻

辑看成一个黑盒子，测试分析要从这个黑盒子的输入和输出上去

看开发内部实现逻辑是不是有问题，而不应该先去了解开发的实

现逻辑然后按照他们的思路去分析。

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

建议：测试分析要从全局上去看问题，细节的东西即便是知道的，

也要留给之后的用例编写人员去了解(就像系分之后的开发需要

去写详细设计的道理一样)，这样后面的人才会自己主动去想问

题。

3、分析文档要考虑维护性问题，不要出现类似比如还款中

这种具体的数据内容。因为我的分析是对后续用例编写

人员的一个指导性的文档，所以如果侧分这么写很有可能导致用

例也照着这么写，其实不管侧分和用例都不应该具体写到r这么

细节，否则的话开发稍作变动我们就要相应变动我们的用例

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

用例需要明确一个测试目的，让别人来看这个用例的时候能明白

到底是怎么回事。

总结：

1、以后写测试分析文档，依据仅仅是prd文档，必须抛开

开发实现逻辑部分(即不去看系分文档)，待测分出来之后，再去

看系分文档，互相看看彼此考虑的是否存在遗漏的地方。等到在

写用例的时候再让写用例的人和相应的开发去互相明确更细节

的东西。

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

独分析，细到看输出的时候会关注到数据库表的一个变化。但是

除了以上部分，其实还少了对整体流程的关注，需要增加业务流

程的各条路径的一个覆盖，在针对路径的用例中不需要关注到数

据库表级那么细。

3、在做流程路径覆盖之前应该画一个路径图，这个图的画

法考虑各个入口的不同分开画流程图，分别进行路径覆盖。

测试心得体会

bug，现在看来不

是这么一回事情，因为还是有手工测试（执行测试），工具只是

一个辅助，用工具你先要去了解测试的一些基本的东西（如：测

试用例，预期结果等），不是那按两下按钮就行了，就算是录制

脚本，也需要看懂脚本的代码，工具不是万能的。

一开始接触软件测试觉得很枯燥乏味，全都是一些理论的东

西，还不如回到小学学习语文呢，都是一些名词的解释，比如:黑

盒测试，百合测试，系统测试。测试基础等等这些，老师都会去

告诉你这些名词什么意思，很无聊，到后来慢慢由语文变成了数

学，开始练习测试用列的编写，这个还有点意思，因为这个更多

时候能够体现个人的逻辑思维能力，再然后数学就转变成了英语，

因为要使用到一些测试的工具，比如：winrunner工具，录制脚

本它会产生一些代码，不过代码比较好理解，虽然是英文的但是

还是很好看懂的。

学习软件测试一学期，其实我觉得最重要的是兴趣，有了兴

趣还是不行的，还需要具备一些语言的基础，例如：c，java，c#

等一些语言，这些语言你不需要去深入的学习，只需要了解，最

重要的是了解数据库（例如：sql，mysql，oracle）的知识，想要

成为一个好的测试工程师，应该要全面的发展，读懂需求分析文

档（注：客户的要求），还有要学会写文档，语言的组织能力决定

你这份文档的价值，这也是一种沟通能力的体现，比如写缺陷报

告时：有一项是描述缺陷，这就能看出你的表达能力，给程序员

最后就是整理文档和撰写测试总结报

告，越是到最后越是要细心，因为软件永远都是有