测试经验总结（优秀范文五篇）.docx

测试经验总结（优秀范文五篇）

第一篇：测试经验总结测试经验总结每次总结或者回顾的时候总会免不了一声感叹：时间过得真快啊！本想着这次一定不要再有这样俗气的话语，可是没办法，时间真的过得很快，转眼自己毕业三年，也真真实实地从事测试工作三年了。想想这三年，自己测试的任务也不少，有时也一直问自己，这三年的时间自己到底成长了多少？测试技能到底学到了多少？可笑的是，每次问自己的时候，没有什么明确的答案，而这一系列的问题也就以测试任务繁重为借口，不了了之。或许，这次的年中是一个好机会，让自己不再回避这些问题，让自己好好回顾一下这三年自己的测试生涯。下面是一些自己平时测试工作总结及一些自己比较认可的观点，当然，也有很多经验是借鉴于其他测试前辈的。我喜欢把测试工作看着是一个环形的生产链，就像一条环形的生物链一样，我们需要找到这个生产链的头部，也就是在一项测试任务开始的时候，我们需要明确，首先我们应该做什么。每一本测试书籍，对测试流程都有不同的阐述，每一个作者都有他们不同的侧重点，这里我也就对自己觉得与测试工作切切实实相关的几个工作做一下自我见解的阐述，并不是说其他的就与我们无关，只是个人觉得这几点比较重要吧：一、明确客户需求：相信产品需求的重要性，大家都不言而喻，产品的需求阐述了客户想要的产品是什么，想要的产品原型是怎样。很多时候我们的需求人员在与客户沟通后做出的产品需求规格书并不是客户想要的，虽然中间可能针对某个需求点沟通交流过很多次，但是因为大家都误以为彼此已经充分明白了自己想表达的意思，从而导致了客户的需求是A，而我们给出的是B。这样情况下，测试人员对需求评审的重要性就体现出来了，测试人员需要以第三方的身份去看需求，对需求不明的地方要有打破沙锅问到底的精神，真正了解需求设计上面实现的方案是什么，然后再以客户的身份探究，这是否就是我想要的。另外，在对需求评审的时候，需要把需求与实际业务进行结合起来，需要探究一份看似不错的需求是否符合实际的业务需求。很多时候，我们的需求提出者，对当前的业务系统并不是很了解，有时提出来的需求，看似很符合情理，但是在实际业务中根本无法实现。所以，这也要求我们的测试工作人员需要有强大的业务背景。二、设计测试用例：测试用例的设计是决定一个产品能否成功发布的关键因素。每一个需求乃至一个缺陷我们都要有明确的测试方案，或许时间上不允许我们作过多的详细设计，但是一定要把每个功能的关键点罗列出来。曾经遇到过这样情况，开发同事在一个需求任务下面，优化了一个投保单带出的默认起保时间，当时口头沟通确认后，这个改动点影响不大，而且只是一个默认值的带出，当时就没有多在意，只是找了一些数据看看功能是否正常，但是功能上线后第二天，运维电话就一直响，客户一直在抱怨即时生效的保单不能出，后来才恍然大悟，修改了起保时间势必会影响到即时生效保单起保时间的带出，因为即时生效的保险期限规则与非即时生效保险期限规则不一致，如果当时自己不这么大意，认真地对待每一改造点，或许就不会有这个问题，只要自己仔细分析一下这个改造点涉及到哪些功能，这个问题是完全可以避免的。跟大家分享这个案例并不是说想给大家说自己有多悔恨，只是以此来提醒大家，每一个功能都需要有严谨、清晰的分析，要有自己的判断。针对测试用例设计上面，应该考虑以下几点：1、针对需求文档涉及到的每一个功能点设计单独的测试用例；2、针对每一个功能点不同场景设计；3、周边功能测试用例；4、功能点涉及到的易用性测试用例；5、考虑功能点可能会有的性能问题；三、用例执行：在测试用例执行的时候，大体都是按照之前设计好的测试用例执行的，但在测试过程中，脑海里或许会时不时地想到一些新的idea,当执行过程中有这样的想法闪过的时候，千万不要错过，或许潜在的缺陷就存在于你脑海里的这个新想法，其实这也不是一闪而过的想法，这是大脑在执行用例时，产生的一种探索性想法，也就是我们叫的探索性测试。所以在执行测试用例的时候，千万不要放过这些想法。四、测试回归：回归测试在整个测试生命周期是必不可少的。无论是修复一个缺陷还是测试完成一个需求，整个系统的回归测试是必要的，或许某一个很小功能点的改动会影响到整个产品的发布。永远不要质疑bug的存在性，bug真的无处不在。或许你会说我把整个测试用例全都执行了一遍，也没有发现缺陷，回归测试还有必要么？但是，你只是保证了在你设计的用例或场景里面没有缺陷而已，你不能保证其他场景或用例就发现不了缺陷，正如测试工作本身一样，我们能做的是尽量减少缺陷，而不是杜绝缺陷，缺陷是我们没有办法杜绝的。五、经验教训总结：每次我们在完成一个任务后，或多或少都有一些感触。比如，在测试某个任务时，因为某个测试用例，成功地发现了一个缺陷，而这个缺陷又只是在某个特地的场景下才能浮现，或者这个缺陷一直都有，只是从来没有被人发现过，