测试经验总结
每次总结或者回顾的时候总会免不了一声感叹：时间过得真快啊！本想着这次一定不要再有这样俗气的话语，可是没办法，时间真的过得很快，转眼自己毕业三年，也真真实实地从事测试工作三年了。想想这三年，自己测试的任务也不少，有时也一直问自己，这三年的时间自己到底成长了多少？测试技能到底学到了多少？可笑的是，每次问自己的时候，没有什么明确的答案，而这一系列的问题也就以测试任务繁重为借口，不了了之。或许，这次的年中是一个好机会，让自己不再回避这些问题，让自己好好回顾一下这三年自己的测试生涯。下面是一些自己平时测试工作总结及一些自己比较认可的观点，当然，也有很多经验是借鉴于其他测试前辈的。
我喜欢把测试工作看着是一个环形的生产链，就像一条环形的生物链一样，我们需要找到这个生产链的头部，也就是在一项测试任务开始的时候，我们需要明确，首先我们应该做什么。每一本测试书籍，对测试流程都有不同的阐述，每一个作者都有他们不同的侧重点，这里我也就对自己觉得与测试工作切切实实相关的几个工作做一下自我见解的阐述，并不是说其他的就与我们无关，只是个人觉得这几点比较重要吧：
一、明确客户需求：相信产品需求的重要性，大家都不言而喻，产品的需求阐述了客户想要的产品是什么，想要的产品原型是怎样。很多时候我们的需求人员在与客户沟通后做出的产品需求规格书并不是客户想要的，虽然中间可能针对某个需求点沟通交流过很多次，但是因为大家都误以为彼此已经充分明白了自己想表达的意思，从而导致了客户的需求是A ，而我们给出的是B 。这样情况下，测试人员对需求评审的重要性就体现出来了，测试人员需要以第三方的身份去看需求，对需求不明的地方要有打破沙锅问到底的精神，真正了解需求设计上面实现的方案是什么，然后再以客户的身份探究，这是否就是我想要的。另外，在对需求评审的时候，需要把需求与实际业务进行结合起来，需要探究一份看似不错的需求是否符合实际的业务需求。很多时候，我们的需求提出者，对当前的业务系统并不是很了解，有时提出来的需求，看似很符合情理，但是在实际业务中根本无法实现。所以，这也要求我们的测试工作人员需要有强大的业务背景。
二、设计测试用例：测试用例的设计是决定一个产品能否成功发布的关键因素。每一个需求乃至一个缺陷我们都要有明确的测试方案，或许时间上不允
许我们作过多的详细设计，但是一定要把每个功能的关键点罗列出来。曾经遇到过这样情况，开发同事在一个需求任务下面，优化了一个投保单带出的默认起保时间，当时口头沟通确认后，这个改动点影响不大，而且只是一个默认值 的带出，当时就没有多在意，只是找了一些数据看看功能是否正常，但是功能上线后第二天，运维电话就一直响，客户一直在抱怨即时生效的保单不能出，后来才恍然大悟，修改了起保时间势必会影响到即时生效保单起保时间的带出，因为即时生效的保险期限规则与非即时生效保险期限规则不一致，如果当时自己不这么大意，认真地对待每一改造点，或许就不会有这个问题，只要自己仔细分析一下这个改造点涉及到哪些功能，这个问题是完全可以避免的。跟大家分享这个案例并不是说想给大家说自己有多悔恨，只是以此来提醒大家，每一个功能都需要有严谨、清晰的分析，要有自己的判断。针对测试用例设计上面，应该考虑以下几点：1、针对需求文档涉及到的每一个功能点设计单独的测试用例；2、针对每一个功能点不同场景设计；3、周边功能测试用例；4、功能点涉及到的易用性测试用例；5、考虑功能点可能会有的性能问题；
三、用例执行：在测试用例执行的时候，大体都是按照之前设计好的测试用例执行的，但在测试过程中，脑海里或许会时不时地想到一些新的idea, 当执行过程中有这样的想法闪过的时候，千万不要错过，或许潜在的缺陷就存在于你脑海里的这个新想法，其实这也不是一闪而过的想法，这是大脑在执行用例时，产生的一种探索性想法，也就是我们叫的探索性测试。所以在执行测试用例的时候，千万不要放过这些想法。
四、测试回归：回归测试在整个测试生命周期是必不可少的。无论是修复一个缺陷还是测试完成一个需求，整个系统的回归测试是必要的，或许某一个很小功能点的改动会影响到整个产品的发布。永远不要质疑bug 的存在性，bug 真的无处不在。或许你会说我把整个测试用例全都执行了一遍，也没有发现缺陷，回归测试还有必要么？但是，你只是保证了在你设计的用例或场景里面没有缺陷而已，你不能保证其他场景或用例就发现不了缺陷，正如测试工作本身一样，我们能做的是尽量减少缺陷，而不是杜绝缺陷，缺陷是我们没有办法杜绝的。
五、经验教训总结：每次我们在完成一个任务后，或多或少都有一些感触。比如，在测试某个任务时，因为某个测试用例，成功地发现了一个缺陷，而这个缺陷又只是在某个特地的场景下才能浮现，或者这个缺陷一直都有，只是从来没有被人发现过，那么这个用例的设计就非常完美了，那么我们就需要回想
当时设计这个用例出于什么样的动机？为了验证的功能点是什么？为什么当时要设计这样的测试用例？这些疑问，会影响到以后我们对用例的设计，或许以后我们的设计用例的视野就会更加开阔，想到的也就更多。同样的，如果一个产品上线后，客户使用的时候发现有bug ，那么我们也需要从这个生产缺陷本身去分析，为什么我们测试过程中没有发现这个缺陷？我们设计的用例里面究竟遗漏了什么？是业务知识掌握的不够全面还是粗心大意，把明明可以规避的风险放在了生产上面？
以上就是在测试工作中自己觉得比较重要的几点吧，不过在关注测试任务的本身外，还需要具备良好的心态。曾经在一次测试任务汇报会议上，有一位领导说了一句话，现在记忆犹新：测试人员应该具备敏感、较真、充满激情又负有责任感的心态。
敏感是指在测试过程中对待问题要有敏感的认知，能够迅速地找出程序中重要的缺陷，也就是说在发现问题时，一定要先从重要缺陷着手，不能在产品快发布的时候，却发现一个严重缺陷，这会导致昂贵的修复成本。
较真不是说偏执，较真就是我们要怀揣着一颗求真的心态去定位问题、解决问题。一个问题或许开发和测试的不同角度，问题也会有值的偏差，那么这时我们就需要回归到问题的本身，以客户的身份去看待问题，当然这也强调如果真的是程序问题，作为测试的我们也就要以专业的身份去看待问题，不能因为其他而有所妥协，问题解决的时效性可以根据问题本身的严重性决定，但是不能直接忽略而过。
个人觉得，测试工作是一项比较‘受气’的工作。在产品未发布前如果发现太多缺陷或者说提了很多测试建议的话，开发就很不乐意了，他们会在你耳边说这些问题都是可改可不改的，你报这么多缺陷会延迟整个产品的上线时间，乃至影响整个项目组产品的发布。产品上线后，如果客户发现问题的时候，开发、项目领导以及测试领导都会走到你的跟前问你，这个缺陷为什么遗漏了呢？测试当时为什么没有发现这个问题？而此刻，作为测试人员内心也一定百感交集，心里一边想着‘自己为什么会把这样的缺陷遗漏到生产呢，应该仔细点的，或许多考虑一下就不会了’另一边也想着‘上次升级的版本任务太多了，根本没有时间让自己来仔细琢磨这些，为什么自己这么辛苦地完成任务还要受到这么多质疑’，当遇到的次数多了，便开始怀疑自己的测试能力，开始怀疑自己是否真的适合这项测试工作，从而开始否定自己的能力、否定自己的工作甚至
否定自己。而此刻，一份对测试工作的挚爱、积极乐观及充满激情的心态就显得尤为重要了。选择了测试工作，那么你就要明白不能发现程序中所以的缺陷，我们能做的就是在有限的时间里发现尽可能多的缺陷。只有当你对这份工作怀揣着十分满满的激情时候，你才会有勇气去迎接一次又一次的挑战。
最后一点，也是最重要的一点，无论我们做什么工作，都要对它有一份理所应当的责任感。一个人的责任感决定了这个人工作的态度。当你真正的把一项任务看着是自己的责任而不仅仅是任务的时候，你就会爆发你所有的潜能去完成它，无论它看起来有多么的困难，多么的难以实现。就像你的家人需要你去照顾一样，这是一份责任，而不是任务，所以很多时候你想的不是怎么快地完成它，而是想的是怎样才能更好地完成它。
写了很多，其实阐述的好像也不多，不管了，这些应该也就是自己这三年工作中最想说的吧！fighting!!!
测试经验总结
每次总结或者回顾的时候总会免不了一声感叹：时间过得真快啊！本想着这次一定不要再有这样俗气的话语，可是没办法，时间真的过得很快，转眼自己毕业三年，也真真实实地从事测试工作三年了。想想这三年，自己测试的任务也不少，有时也一直问自己，这三年的时间自己到底成长了多少？测试技能到底学到了多少？可笑的是，每次问自己的时候，没有什么明确的答案，而这一系列的问题也就以测试任务繁重为借口，不了了之。或许，这次的年中是一个好机会，让自己不再回避这些问题，让自己好好回顾一下这三年自己的测试生涯。下面是一些自己平时测试工作总结及一些自己比较认可的观点，当然，也有很多经验是借鉴于其他测试前辈的。
我喜欢把测试工作看着是一个环形的生产链，就像一条环形的生物链一样，我们需要找到这个生产链的头部，也就是在一项测试任务开始的时候，我们需要明确，首先我们应该做什么。每一本测试书籍，对测试流程都有不同的阐述，每一个作者都有他们不同的侧重点，这里我也就对自己觉得与测试工作切切实实相关的几个工作做一下自我见解的阐述，并不是说其他的就与我们无关，只是个人觉得这几点比较重要吧：
一、明确客户需求：相信产品需求的重要性，大家都不言而喻，产品的需求阐述了客户想要的产品是什么，想要的产品原型是怎样。很多时候我们的需求人员在与客户沟通后做出的产品需求规格书并不是客户想要的，虽然中间可能针对某个需求点沟通交流过很多次，但是因为大家都误以为彼此已经充分明白了自己想表达的意思，从而导致了客户的需求是A ，而我们给出的是B 。这样情况下，测试人员对需求评审的重要性就体现出来了，测试人员需要以第三方的身份去看需求，对需求不明的地方要有打破沙锅问到底的精神，真正了解需求设计上面实现的方案是什么，然后再以客户的身份探究，这是否就是我想要的。另外，在对需求评审的时候，需要把需求与实际业务进行结合起来，需要探究一份看似不错的需求是否符合实际的业务需求。很多时候，我们的需求提出者，对当前的业务系统并不是很了解，有时提出来的需求，看似很符合情理，但是在实际业务中根本无法实现。所以，这也要求我们的测试工作人员需要有强大的业务背景。
二、设计测试用例：测试用例的设计是决定一个产品能否成功发布的关键因素。每一个需求乃至一个缺陷我们都要有明确的测试方案，或许时间上不允
许我们作过多的详细设计，但是一定要把每个功能的关键点罗列出来。曾经遇到过这样情况，开发同事在一个需求任务下面，优化了一个投保单带出的默认起保时间，当时口头沟通确认后，这个改动点影响不大，而且只是一个默认值 的带出，当时就没有多在意，只是找了一些数据看看功能是否正常，但是功能上线后第二天，运维电话就一直响，客户一直在抱怨即时生效的保单不能出，后来才恍然大悟，修改了起保时间势必会影响到即时生效保单起保时间的带出，因为即时生效的保险期限规则与非即时生效保险期限规则不一致，如果当时自己不这么大意，认真地对待每一改造点，或许就不会有这个问题，只要自己仔细分析一下这个改造点涉及到哪些功能，这个问题是完全可以避免的。跟大家分享这个案例并不是说想给大家说自己有多悔恨，只是以此来提醒大家，每一个功能都需要有严谨、清晰的分析，要有自己的判断。针对测试用例设计上面，应该考虑以下几点：1、针对需求文档涉及到的每一个功能点设计单独的测试用例；2、针对每一个功能点不同场景设计；3、周边功能测试用例；4、功能点涉及到的易用性测试用例；5、考虑功能点可能会有的性能问题；
三、用例执行：在测试用例执行的时候，大体都是按照之前设计好的测试用例执行的，但在测试过程中，脑海里或许会时不时地想到一些新的idea, 当执行过程中有这样的想法闪过的时候，千万不要错过，或许潜在的缺陷就存在于你脑海里的这个新想法，其实这也不是一闪而过的想法，这是大脑在执行用例时，产生的一种探索性想法，也就是我们叫的探索性测试。所以在执行测试用例的时候，千万不要放过这些想法。
四、测试回归：回归测试在整个测试生命周期是必不可少的。无论是修复一个缺陷还是测试完成一个需求，整个系统的回归测试是必要的，或许某一个很小功能点的改动会影响到整个产品的发布。永远不要质疑bug 的存在性，bug 真的无处不在。或许你会说我把整个测试用例全都执行了一遍，也没有发现缺陷，回归测试还有必要么？但是，你只是保证了在你设计的用例或场景里面没有缺陷而已，你不能保证其他场景或用例就发现不了缺陷，正如测试工作本身一样，我们能做的是尽量减少缺陷，而不是杜绝缺陷，缺陷是我们没有办法杜绝的。
五、经验教训总结：每次我们在完成一个任务后，或多或少都有一些感触。比如，在测试某个任务时，因为某个测试用例，成功地发现了一个缺陷，而这个缺陷又只是在某个特地的场景下才能浮现，或者这个缺陷一直都有，只是从来没有被人发现过，那么这个用例的设计就非常完美了，那么我们就需要回想
当时设计这个用例出于什么样的动机？为了验证的功能点是什么？为什么当时要设计这样的测试用例？这些疑问，会影响到以后我们对用例的设计，或许以后我们的设计用例的视野就会更加开阔，想到的也就更多。同样的，如果一个产品上线后，客户使用的时候发现有bug ，那么我们也需要从这个生产缺陷本身去分析，为什么我们测试过程中没有发现这个缺陷？我们设计的用例里面究竟遗漏了什么？是业务知识掌握的不够全面还是粗心大意，把明明可以规避的风险放在了生产上面？
以上就是在测试工作中自己觉得比较重要的几点吧，不过在关注测试任务的本身外，还需要具备良好的心态。曾经在一次测试任务汇报会议上，有一位领导说了一句话，现在记忆犹新：测试人员应该具备敏感、较真、充满激情又负有责任感的心态。
敏感是指在测试过程中对待问题要有敏感的认知，能够迅速地找出程序中重要的缺陷，也就是说在发现问题时，一定要先从重要缺陷着手，不能在产品快发布的时候，却发现一个严重缺陷，这会导致昂贵的修复成本。
较真不是说偏执，较真就是我们要怀揣着一颗求真的心态去定位问题、解决问题。一个问题或许开发和测试的不同角度，问题也会有值的偏差，那么这时我们就需要回归到问题的本身，以客户的身份去看待问题，当然这也强调如果真的是程序问题，作为测试的我们也就要以专业的身份去看待问题，不能因为其他而有所妥协，问题解决的时效性可以根据问题本身的严重性决定，但是不能直接忽略而过。
个人觉得，测试工作是一项比较‘受气’的工作。在产品未发布前如果发现太多缺陷或者说提了很多测试建议的话，开发就很不乐意了，他们会在你耳边说这些问题都是可改可不改的，你报这么多缺陷会延迟整个产品的上线时间，乃至影响整个项目组产品的发布。产品上线后，如果客户发现问题的时候，开发、项目领导以及测试领导都会走到你的跟前问你，这个缺陷为什么遗漏了呢？测试当时为什么没有发现这个问题？而此刻，作为测试人员内心也一定百感交集，心里一边想着‘自己为什么会把这样的缺陷遗漏到生产呢，应该仔细点的，或许多考虑一下就不会了’另一边也想着‘上次升级的版本任务太多了，根本没有时间让自己来仔细琢磨这些，为什么自己这么辛苦地完成任务还要受到这么多质疑’，当遇到的次数多了，便开始怀疑自己的测试能力，开始怀疑自己是否真的适合这项测试工作，从而开始否定自己的能力、否定自己的工作甚至
否定自己。而此刻，一份对测试工作的挚爱、积极乐观及充满激情的心态就显得尤为重要了。选择了测试工作，那么你就要明白不能发现程序中所以的缺陷，我们能做的就是在有限的时间里发现尽可能多的缺陷。只有当你对这份工作怀揣着十分满满的激情时候，你才会有勇气去迎接一次又一次的挑战。
最后一点，也是最重要的一点，无论我们做什么工作，都要对它有一份理所应当的责任感。一个人的责任感决定了这个人工作的态度。当你真正的把一项任务看着是自己的责任而不仅仅是任务的时候，你就会爆发你所有的潜能去完成它，无论它看起来有多么的困难，多么的难以实现。就像你的家人需要你去照顾一样，这是一份责任，而不是任务，所以很多时候你想的不是怎么快地完成它，而是想的是怎样才能更好地完成它。
写了很多，其实阐述的好像也不多，不管了，这些应该也就是自己这三年工作中最想说的吧！fighting!!!