第一篇：测试经验总结
测试经验总结
每次总结或者回顾的时候总会免不了一声感叹：时间过得真快啊！本想着这次一定不要再有这样俗气的话语，可是没办法，时间真的过得很快，转眼自己毕业三年，也真真实实地从事测试工作三年了。想想这三年，自己测试的任务也不少，有时也一直问自己，这三年的时间自己到底成长了多少？测试技能到底学到了多少？可笑的是，每次问自己的时候，没有什么明确的答案，而这一系列的问题也就以测试任务繁重为借口，不了了之。或许，这次的年中是一个好机会，让自己不再回避这些问题，让自己好好回顾一下这三年自己的测试生涯。下面是一些自己平时测试工作总结及一些自己比较认可的观点，当然，也有很多经验是借鉴于其他测试前辈的。
我喜欢把测试工作看着是一个环形的生产链，就像一条环形的生物链一样，我们需要找到这个生产链的头部，也就是在一项测试任务开始的时候，我们需要明确，首先我们应该做什么。每一本测试书籍，对测试流程都有不同的阐述，每一个作者都有他们不同的侧重点，这里我也就对自己觉得与测试工作切切实实相关的几个工作做一下自我见解的阐述，并不是说其他的就与我们无关，只是个人觉得这几点比较重要吧：
一、明确客户需求：相信产品需求的重要性，大家都不言而喻，产品的需求阐述了客户想要的产品是什么，想要的产品原型是怎样。很多时候我们的需求人员在与客户沟通后做出的产品需求规格书并不是客户想要的，虽然中间可能针对某个需求点沟通交流过很多次，但是因为大家都误以为彼此已经充分明白了自己想表达的意思，从而导致了客户的需求是A，而我们给出的是B。这样情况下，测试人员对需求评审的重要性就体现出来了，测试人员需要以第三方的身份去看需求，对需求不明的地方要有打破沙锅问到底的精神，真正了解需求设计上面实现的方案是什么，然后再以客户的身份探究，这是否就是我想要的。另外，在对需求评审的时候，需要把需求与实际业务进行结合起来，需要探究一份看似不错的需求是否符合实际的业务需求。很多时候，我们的需求提出者，对当前的业务系统并不是很了解，有时提出来的需求，看似很符合情理，但是在实际业务中根本无法实现。所以，这也要求我们的测试工作人员需要有强大的业务背景。
二、设计测试用例：测试用例的设计是决定一个产品能否成功发布的关键因素。每一个需求乃至一个缺陷我们都要有明确的测试方案，或许时间上不允许我们作过多的详细设计，但是一定要把每个功能的关键点罗列出来。曾经遇到过这样情况，开发同事在一个需求任务下面，优化了一个投保单带出的默认起保时间，当时口头沟通确认后，这个改动点影响不大，而且只是一个默认值 的带出，当时就没有多在意，只是找了一些数据看看功能是否正常，但是功能上线后第二天，运维电话就一直响，客户一直在抱怨即时生效的保单不能出，后来才恍然大悟，修改了起保时间势必会影响到即时生效保单起保时间的带出，因为即时生效的保险期限规则与非即时生效保险期限规则不一致，如果当时自己不这么大意，认真地对待每一改造点，或许就不会有这个问题，只要自己仔细分析一下这个改造点涉及到哪些功能，这个问题是完全可以避免的。跟大家分享这个案例并不是说想给大家说自己有多悔恨，只是以此来提醒大家，每一个功能都需要有严谨、清晰的分析，要有自己的判断。针对测试用例设计上面，应该考虑以下几点：
1、针对需求文档涉及到的每一个功能点设计单独的测试用例；
2、针对每一个功能点不同场景设计；
3、周边功能测试用例；
4、功能点涉及到的易用性测试用例；
5、考虑功能点可能会有的性能问题；
三、用例执行：在测试用例执行的时候，大体都是按照之前设计好的测试用例执行的，但在测试过程中，脑海里或许会时不时地想到一些新的idea,当执行过程中有这样的想法闪过的时候，千万不要错过，或许潜在的缺陷就存在于你脑海里的这个新想法，其实这也不是一闪而过的想法，这是大脑在执行用例时，产生的一种探索性想法，也就是我们叫的探索性测试。所以在执行测试用例的时候，千万不要放过这些想法。
四、测试回归：回归测试在整个测试生命周期是必不可少的。无论是修复一个缺陷还是测试完成一个需求，整个系统的回归测试是必要的，或许某一个很小功能点的改动会影响到整个产品的发布。永远不要质疑bug的存在性，bug真的无处不在。或许你会说我把整个测试用例全都执行了一遍，也没有发现缺陷，回归测试还有必要么？但是，你只是保证了在你设计的用例或场景里面没有缺陷而已，你不能保证其他场景或用例就发现不了缺陷，正如测试工作本身一样，我们能做的是尽量减少缺陷，而不是杜绝缺陷，缺陷是我们没有办法杜绝的。
五、经验教训总结：每次我们在完成一个任务后，或多或少都有一些感触。比如，在测试某个任务时，因为某个测试用例，成功地发现了一个缺陷，而这个缺陷又只是在某个特地的场景下才能浮现，或者这个缺陷一直都有，只是从来没有被人发现过，那么这个用例的设计就非常完美了，那么我们就需要回想当时设计这个用例出于什么样的动机？为了验证的功能点是什么？为什么当时要设计这样的测试用例？这些疑问，会影响到以后我们对用例的设计，或许以后我们的设计用例的视野就会更加开阔，想到的也就更多。同样的，如果一个产品上线后，客户使用的时候发现有bug，那么我们也需要从这个生产缺陷本身去分析，为什么我们测试过程中没有发现这个缺陷？我们设计的用例里面究竟遗漏了什么？是业务知识掌握的不够全面还是粗心大意，把明明可以规避的风险放在了生产上面？
以上就是在测试工作中自己觉得比较重要的几点吧，不过在关注测试任务的本身外，还需要具备良好的心态。曾经在一次测试任务汇报会议上，有一位领导说了一句话，现在记忆犹新：测试人员应该具备敏感、较真、充满激情又负有责任感的心态。
敏感是指在测试过程中对待问题要有敏感的认知，能够迅速地找出程序中重要的缺陷，也就是说在发现问题时，一定要先从重要缺陷着手，不能在产品快发布的时候，却发现一个严重缺陷，这会导致昂贵的修复成本。
较真不是说偏执，较真就是我们要怀揣着一颗求真的心态去定位问题、解决问题。一个问题或许开发和测试的不同角度，问题也会有值的偏差，那么这时我们就需要回归到问题的本身，以客户的身份去看待问题，当然这也强调如果真的是程序问题，作为测试的我们也就要以专业的身份去看待问题，不能因为其他而有所妥协，问题解决的时效性可以根据问题本身的严重性决定，但是不能直接忽略而过。
个人觉得，测试工作是一项比较‘受气’的工作。在产品未发布前如果发现太多缺陷或者说提了很多测试建议的话，开发就很不乐意了，他们会在你耳边说这些问题都是可改可不改的，你报这么多缺陷会延迟整个产品的上线时间，乃至影响整个项目组产品的发布。产品上线后，如果客户发现问题的时候，开发、项目领导以及测试领导都会走到你的跟前问你，这个缺陷为什么遗漏了呢？测试当时为什么没有发现这个问题？而此刻，作为测试人员内心也一定百感交集，心里一边想着‘自己为什么会把这样的缺陷遗漏到生产呢，应该仔细点的，或许多考虑一下就不会了’另一边也想着‘上次升级的版本任务太多了，根本没有时间让自己来仔细琢磨这些，为什么自己这么辛苦地完成任务还要受到这么多质疑’，当遇到的次数多了，便开始怀疑自己的测试能力，开始怀疑自己是否真的适合这项测试工作，从而开始否定自己的能力、否定自己的工作甚至否定自己。而此刻，一份对测试工作的挚爱、积极乐观及充满激情的心态就显得尤为重要了。选择了测试工作，那么你就要明白不能发现程序中所以的缺陷，我们能做的就是在有限的时间里发现尽可能多的缺陷。只有当你对这份工作怀揣着十分满满的激情时候，你才会有勇气去迎接一次又一次的挑战。
最后一点，也是最重要的一点，无论我们做什么工作，都要对它有一份理所应当的责任感。一个人的责任感决定了这个人工作的态度。当你真正的把一项任务看着是自己的责任而不仅仅是任务的时候，你就会爆发你所有的潜能去完成它，无论它看起来有多么的困难，多么的难以实现。就像你的家人需要你去照顾一样，这是一份责任，而不是任务，所以很多时候你想的不是怎么快地完成它，而是想的是怎样才能更好地完成它。
写了很多，其实阐述的好像也不多，不管了，这些应该也就是自己这三年工作中最想说的吧！fighting！!
第二篇：测试经验总结
1.测试人员和用户的联系与区别
黑盒测试人员和用户，都是站在实际应用层进行操作，因此他们对应用层的可用性、实用性非常关注。用户不懂的是软件的使用，而相对用户来说，测试人员对软件比较了解，但不熟悉业务本身。
八个字归纳：用户是用，测试是测。
用户不懂使用就需要技术支持人员去培训，而测试人员在测试初期经过开发人员和项目负责人的简单培训后，就应该通过所学的理论知识和相关的业务知识独立去了解、深入到软件的功能点中。
应该做到：由测试人员培训技术支持人员，由技术支持人员实施时给用户培训。
2.带着问题去测试
阿猪工作守则第一条：带着问题去测试
测试中会遇到很多问题，没关系，没有脑子里面的一个个问号，是不能很好的发现问题的。往往发现一些藏的很深的bug都是在测试人员一步步解决这些问号的过程中，切忌遇到问题就问，不仅因为增加不必要的与开发人员、负责人等的交流时间可能延误项目进度，而且自己对问题的印象也不会很深刻，毕竟在相对较短的测试时间内，听不如记，记不如自己去发现规律。
3.测试期间提问题和交流的时机
什么时候应该提问题？
我们都知道，作为测试人员，并不是测试期间什么时候遇到问题就要马上问，那什么时候是提问的时间？
培训
培训时，一般在讲解内容的间歇允许打断，由培训人员解答测试人员的疑惑。培训的过程其实就是一个传输新知识并答疑的时间，这个期间的提问是欢迎的，也可以增加参与性和调动积极性。所以希望大部分的问题能在这个阶段提出来。受时间、环境等条件制约，有时培训的人讲的也不一定细致和全面，这时就需要自己多想，想想这个功能是干什么的，为什么这么做，对应的业务是什么。
阿猪工作守则第二条：培训时脑子灵活转动，多想多问
以前大家可能有过参加辩论会的经历，就算没有其实和人聊天也是一个交互的过程。参加辩论会要求快速思考，然后放慢语速说出自己的观点，因为不能说错。我们在参加培训时前者相同，后者相反。脑子嘴巴都要快，说错了也没有关系，自己的想法被纠正的过程中也是加深印象和理解的过程。
计划评审
提出对于软件不理解、安排的任务不明白的地方。
测试期间
这个时期最主要的问题应该集中在影响测试流程和进度的问题，而不是说明书或其它文档上已有的内容，或者与自己负责模块无关的内容。开发人员和其他测试人员都有自己的进度安排，因此，影响测试流程和进度的问题,马上问！
不影响流程的问题，记下来统一问！
不必要的问题（说明书或其它文档上已有的内容、讲过三遍以上的问题、今晚去哪里吃饭的问题），不问！
好处：避免不必要的时间支出，不打乱自己的测试思路，一气呵成，并且使项目成本得到控制
坏处（？）：脑子里、笔记本上留下一堆待解决的问号吧，浪费脑细胞和公司的笔和纸
张等资源
阿猪工作守则第三条：先做事，后学习
在有限的时间内先完成该做的事，有空闲的时间再去补充自己的知识。
要很好的把握上述内容，也要求提高培训期间培训人员培训内容的完善性，要求前期培训人员强调出软件的重点、难点和注意事项。这个期间适合于上面提到的“带着问题去测试”的方法。
但有一点需要注意：不要为了一个地方的卡壳在那耗上一天半天的，这就不值得了。测试中期评审测试问题
答疑解惑的时间。
测试报告评审
对一些结论有疑惑和不解的地方，提！
4.记笔记
一个老生常谈的话题。
阿猪工作守则第四条：好记性不如烂笔头
测试培训的时候对于一些重点应该记下来，即使当时听懂了；没听明白的更应该记下来，到测试软件的时候去验证自己的疑问。如果培训时特别强调的地方，测试时再去问，这就不好了。
养成一个良好的习惯，会使以后的工作更加顺利。
5.在公司和学校的学习的区别
学校是专门学习的地方，公司就是工作的地方，因此，它们的性质决定了其学习内容和方法的不同。
学校 公司 备注
内容上 主要是系统的理论知识 主要是和项目相关的业务知识 如果在测试中感到自己部分理论知识欠缺时，就应该回家多补充了
时间上 大块时间的连续学习相对邻散 在公司一般不会拿出大块时间来学习和讲解 形式上 老师授课＋自学 培训＋交流＋测试过程中自学
个人觉得，一个高效的测试流程应该如下：
a.花几个小时至多半天时间快速阅读浏览软件说明书、设计文档；
这个阶段要让脑子里面形成对软件的整体印象感，能够让自己把握全局，因此，测试负责人安排时间看文档时，决不能忽视它的重要性，否则就会出现后续阶段磕磕碰碰的情况。注重速读，把握软件说明，忽略具体的数据库设计、功能点设计、计算、规则和辅助工具（相关软件）说明文档，囫囵吞枣的方法在这里就显得很有效。
如果项目时间紧或没有文档，这个步骤所做的事可以在下面完成。
b.利用培训时间消化吸收的知识
c.软件上手
几个小时至多半天时间，熟悉软件框架和基本功能，不要求所有功能都会操作，自己负责的模块可以多侧重一些。
d.细测
主要症对计划中安排给自己做的模块，这时就要相对放慢节奏，每一步操作、每个对话框（操作界面）都要深究，别放过任何情况。这时会遇到一些错误或不理解的地方，明显的如报错就提到开发过程论坛，不明显的就先记下来，等这个功能点测完再回头去看，你会发现：
50％的问题可以自己分析出来和解决，有的问题不是问题，只是开始还没有完全理解。阿猪工作守则第五条：软件不是一次能测透的Rome is not built in one day.工期、人力、环境资料等，都制约着测试的深度和广度，因为不要期望一次能完全把握某个软件。
综合测试的优势在于，我们负责公司产品的把关，而项目由产品延伸而来；测试产品会不断出新的版本，一次没有理解，可以在下一次中弥补，温故而知新。
一口吃不成一个胖子，看我这么瘦又这么能吃就知道了^^
要结合自己的实际情况决定本次测试的深度，不要看着别人进度快了就打乱自己的节奏，只要安排合理，应该按照计划来。特别忌讳认为自己这块没问题了就马上去看看别人负责的功能，期望全能。这样一般来说除了ljl这种全能性人物外都会造成最后自己的问题留了一堆，别人的也没搞懂。
新人特别注意，踏踏实实的搞懂每个自己负责的模块，打阵地站，这种方法很有效。评价自己是否可以转入下个模块的几个因素：自我提问与别人提问、测试进度
如果大多数相关人员（主要是测试负责人、其他部分相关测试人员特别是开发组集成测试人员和技术支持人员）对于自己负责模块的问题都能解答，搞定！NEXT-->转入下个模块。
否则，还是再回头想想思路和遗漏的地方。当然，要综合考虑测试进度。请组长对自己提几个软件的问题，他会很乐意的。
e.小结
一个阶段就进行一次小结，这个小结可以是书面的，比如测试问题记录、测试用例补充、测试模块设计等，但大多是自己分析，为了方便接下来模块的测试.f.性能测试
性能测试不仅是测试性能，同时也加深自己对软件应用的理解，因为性能测试往往和实际应用或用户需求结合的很紧密，避免造成软件功能都会用，但不知用来干麻的尴尬情况。g.安装盘测试
安装盘程序测试，简单过一下软件功能有无错误。
安装盘程序文件、库文件、组件等的完整性、正确性，这个非常重要，要不返工就浪费时间了。这个阶段要积极与开发负责人和GJ沟通，确保最后的胜利。
h.测试总结
测试接近尾声，总结自己对软件的掌握情况，得出测试结论、归纳测试方法、提出修改建议，为软件以后版本的修改提供依据，也为以后再测类似软件提供捷径。
5.小结
用户用软件，测试测软件
培训时多想多问
好记性不如烂笔头
带着问题去测试，在测试中解决问题
先做事，后学习，争取双赢
软件不是一次能测透的
第三篇：测试经验总结
6年测试工作的思考
前言
在公司已经干了6年的测试了，干测试经理也5年了。正好趁此机会把自己6年来一直想写但没写的东西写出来。这篇文件纯粹是对自己工作的回顾。由于时间仓促基本上是想到什么些什么，有点儿乱，也请大家多多担待了。只要还有些人能从中找到些儿同感，或从中得到一些帮助，一些经验，我就知足了。
1.什么是测试
首先我要谈谈什么是测试。相信好多测试人员跟我一样，来公司之前也没有从事过任何测试工作。对于测试都是从零开始的。也有好多人跟我一样，从各种书上或是培训中得到过有关测试的各种定义。但不知道大家有没有净下心思考一下。什么是测试。在公司公司测试工作的定义是什么，测试的工作范围是什么。
测试的定义根据测试技术的发展，历经了3个主要的阶段。第一个阶段，认为测试就是找产品中的bug。第二个阶段，除了找bug以外，又增加测试是对软件质量的度量这一概念。第三个阶段，明确了测试是指为了度量和提高被测试软件的质量，对测试件进行工程设计，使用和维护的并发生命周期。注意其中提高的测试件，其主要是与软件这个词进行对应。明确测试也是一种开发过程。他的工作成果就是测试件，好像平时我们所谓的测试案例、测试脚本等等都可以称为测试件。然后使用测试件去度量和提高被测试软件的质量。
目前，在中国大部分软件企业，尤其是中小型的软件企业还停留在第一阶段。我个人觉得公司稍微好一点儿，处于一、二阶段之间。因为我们平时做的最多的一件事，还是找bug。至于测试案例和测试脚本等等，只占用工作量的很小一部分。而且我看不到大家在平时的测试工作中是完全依据测试案例进行测试的。目前测试案例等工作更多的成为了一种形式上的产物。从有些部分所有产品的测试案例在一个下午就能评审完就能看得出来。
说到这里顺便在谈一句测试计划。目前的测试计划是作为产品计划的一部分。先明确大概发版时间，然后是各个阶段的里程碑，其中提交集成的里程碑是死的。开发需要的时间就是那么多，剩下倒推的时间就是测试的时间。这样定出的计划是否能够起到计划的作用就不好说了。现在的计划更多的是罗列联调测试的各种内容，至于时间，不说也罢。所以从中也可以开出公司的测试也就停留在一、二阶段之间。
明确了公司测试的定义（个人理解），也就不难理解公司给测试人员的定位了。在测试人员中经常流传的一种说法就是国外测试人员的地位多么多么的高，开发就是coding。咱们公司开发比测试多拿多少多少，测试人员地位是开发序列中最低的。大家也要看看人家公司测试人员的素质，测试在开发过程中的重要性。再看看自己所从事的工作，就是找软件的bug。当然我也个人认为有经验极其丰富的测试人员对产品的贡献比开发和需求大。明确了这些，心里也就能少点儿不平衡感。
2.测试方法的思考
说完个人对测试含义的理解，再说说个人对测试方案的一些思考。
个人认为在公司6年，测试方法没有什么提高。主要还是以黑盒测试为主。中间也曾经引入过各种各种工具，但测试人员真正用起来的也就是robot。而且robot主要是进行回归测试，再加上一些人并没有真正认识到其价值，应用范围也极其有限。对整体测试效率的提升影响不大。所以目前的测试方案还主要是以需求为依据的黑盒测试。至于什么极限值了，成对测试法等等，都是建立在黑盒测试的基础上，而且从我一来公司就有相应的测试项目，只不过没有明确概念而已。
另一个说个人觉得6年来公司测试方法没有什么提高的原因是，6年前测试是以人为主，靠得是测试人员的经验，对产品的熟悉程度，对业务的理解程度。6年后测试还是以人为主，人就是测试的主体，产品质量的保证。还没有过渡到测试案例就是测试的主体，测试案例的完整性是产品质量的保证。只要测试还是以人为本，我觉得测试的效率就不会有太大提高，产品质量的信心来源也是对相关测试人员的信任。我个人觉得以黑盒测试为主要的测试方法没错，而且也比较符合目前公司的测试现状。但一定要注意各种经验的总结、积累，更重要的是共享。虽然目前测试案例在测试工作过程中的地位不重要，但其毕竟是编写者的经验积累。汇总起来也是一笔可观的财富。可现在如果有人问我850的测试方案在那里，其中还有多大比例能够用在现在的产品中，在现在的测试工作中有多少以前的案例能够复用。其他产品中的测试案例中有多少是关于接口功能，有多少我可以借鉴。我不知道，这也是自己工作不到位的地方。所以我要说的作为黑盒测试为主要的测试方法，一定要注意测试经验的总结和共享。
而且我认为一个人如果黑盒测试能做到位，做到最后培养的是一种测试的感觉。测到最后，产品你一看就能知道那里可能有问题，那里应该没什么问题。这样有重点地投入测试力量可以收到事半功倍的效果。可这是需要大量测试经验的积累的，不是我告诉你，你就知道的能力。在此前提上加强测试人员之间的横向沟通，形成经验贡献。可以较快的培养测试人员的测试感觉。
最为测试经验积累的另一个重要方法就是加强对测试案例的要求和管理。每版测试案例不仅要包括新增功能，还需要包括上一版本中继承的案例，修改或删除上版案例中变更的内容。从而形成一份完整的关于产品所有功能点、接口、升级、年结等等各方面的测试案例。真正做到测试案例是测试的主体，从而提高测试效率，提高产品质量。
3.测试工具的概念和作用
测试工具，什么叫测试工具。我认为任何能提高你测试效率的工具都可以称之为测试工具。不仅仅指robot或是loadrunner这类专门的测试工具，也不仅仅指使用各种编程工具编写的测试工具。像总账工具、eai等，即使只是帮我们导入一些常用档案，也可以节约我们的测试时间也可以称之为测试工具。
我个人现在公司测试在测试工具开发上还很不足。在公司里一提起测试工具，大家第一个想到的可能就是robot。即使是robot应用的也不够深入。大家经常认为robot主要录制gui的脚本，跟产品界面联系紧密。每次回放成功率不高，各个版本间脚本复用率也较低。而且每次总是以各种理由将脚本录制放到最后，经常就不了了之了。最后阶段的测试任务实在太紧。我想说的是robot的应用虽然有各种各样的局限性，但其毕竟提高了测试效率。比如说安装盘验证，使用robot验证，每天都可以节约一半以上的验证时间，这就是效率。认识了它的好处，才能想尽办法解决或避免在robot使用中的各种问题。以前同事有一套robot脚本规范就很好，使用后不仅提高了回放成功率，而且回放中断后，继续回放也变得很容易。所以说使用robot后，想100%回放成功不可能，想不再进行脚本的调试也不可能。认识这两个问题后，就需要加强robot使用经验的总结和共享，有针对性地加强robot使用问题的研究，每版测试开始时针对上版robot脚本的复用问题进行研究。这样才能用好它，真得使之成为一个工具，而不是一项任务。
一种工具也不是万能，有许多针对产品特性的测试工具。只能自己开发，大家应该积极提需求。凡是认为有可能提高测试效率的工具需求都可以提。能从网上找到现成的工具解决需求更好。不能，如果是普遍性的需求，可以专门进行开发。因为咱们产品的特性，每版间测试工具的复用度很大。从长远看就是节约开发成本，缩短开发周期。
在现阶段加大测试工具的适用范围和力度，用好各种测试工具，可能是提高整体测试效率最快最好的方法。但一定要加大推广的力度。否则有了好的工具，没人用或用不起来也是没用。
4.如何看待各种规则和执行
可能大家觉得平时开发过程中有好多规则、制度。这些除了一些自己公司内根据各种情况制定的外，大部分都是跟cmm体系相关的一些规则。可以说是已经被许多软件公司验证过，可以提高开发和测试效率的规则。但好多人觉得起没有什么用，就是在浪费时间。总是以一种完成任务或是应付差事的心情去做。我觉得大家之所以觉得其没用，恰恰就是由于你去做这件事的动机不对。总以应付差事的心情去做，你就不可能真正理解这么做的目的，这样做能给你带来什么好处，你从中会得到什么收益。所以我个人认为，既然有规则，不管是公司自创的或是借鉴其他标准，都是为了解决开发过程中的问题，为了提高开发的效率，保证产品质量。也许这些规则中有这样那样的不合理，但只有你认真地去做了，才能发现其中的不妥之处，才能改进，才能更有助于你的工作。
执行也是我觉得在工作中需要进一步加强的环节。许多规则就是因为执行力度不足，才容易让一些人找到空子，应付了事。但怎样加强执行力度，还是一个需要大家一起进行探讨的问题。
5.作为一名测试人员应该具有的素质
测试人员应该具有什么样的素质，相信好多人都有自己的理解，不同书上的观点也不尽相同。我就说说我在公司工作了六年，觉得一个合格的测试人员应该具有什么样的素质。业务和测试方面的能力就不说了。
测试人员应该具有的素质包括： 1.踏实细心和积极主动
我觉得作为一名测试人员首先要踏实细心。测试人员每天都要面对着枯燥的程序，从事着大量的重复工作，还要尽量发现产品中的bug。如果不踏实，你就坐不住，总想干别的，就无法净下心来想用户有可能怎么用，需求对产品是怎么要求的，现在产品中是怎么做的，哪里可能存在问题。不细心，就特别容易一些产品中微笑的错误，而恰恰就是这些错误是最影响产品形象的问题。
至于积极主动就不多说了。这是每个人都应该具有的素质。2.怀疑一切
不抱着怀疑一切的态度就不是一名合格的测试人员。经过你手测试的产品面对的是直接用户。你不认真负责，不抱着怀疑一切的态度。总想着这个功能本版没动应该没什么问题，这个功能没什么用户用不用认真测了。这样发出的产品，我是不敢让用户用。因为用户用起产品来是千奇百怪，有些用户的水平和对产品的理解比咱们还要深。所以一定要抱着怀疑一切的态度，认为产品每个功能都可能有问题，认真地测试产品的每一个测试点。
3.协作和团队感
协作和团队感也是十分重要的。要意识到测试、开发、需求是一个团队，一个整体。离了谁，产品的质量都无法保证。诚然有个别开发人员责任心不强，经常将未经任何验证的代码编译后发给测试进行验证。耽误了测试人员不少的时间。但越这样，测试人员越应该负责，否则产品发出去影响的是公司的形象。
还有个别开发人员开不起测试。此时就需要你通过各种方法去证明你自己的能力。比如测试出他根本就没考虑过的问题等等。以实际行动证明你离不开我，咱们是一个水平的。只有这样加强协作和团队建设，加强整个团队的质量意识，才能提高开发效率，保证产品质量。
4.自我提高和总结的能力
测试人员经常很迷茫，不知道自己的发展方向在哪里。测试技术还是专业知识。领导们所谓的个人发展方向考虑也经常是画一个饼在那里。这时就只能靠我们自己了。看你想今后从事哪方面的工作。一般情况下，如果升不到管理层就只有两条路可选了。一是业务精通，将来可以向需求或是售前、实施方向发展。一是技术精通，多掌握几种测试工具，又能力可以学习一些编程方面的知识。将来还继续从事测试方面的工作。随着中国软件开发的规范化，这条路也是很有发展的。
另外，我觉得作为一名合格的测试人员，一定要注意进行总结。通过总结可以对自己的工作进行一个回顾分析，看看那些做得不错，下次还继续这么做。那些工作还有改进的余地。对自己能力的提高是一个很好的帮助。
6.作为一名测试经理应该具有的能力
作为一名测试经理，我觉得除了具备一个测试人员应该具备的素质外，还应具备以下能力。
1.出色的沟通和协调能力
由于测试人员和开发人员的工作性质，必然导致测试人员和开发人员在工作中会产生冲突，对同一问题会产生不同的看法。这时，你怎么去协调，去沟通，解决这种矛盾，让自己所在的开发团队中极少的受此影响，就是考验你能力的时候。
2.条理性和计划性
作为测试经理，要负责带领团队内的其他测试人员全面的测试产品。由于测试项目很多，不仅包括产品功能，还要包括效率，性能，压力，并发互斥，环境等等方方面面。此时你如何去安排这些测试项目，哪些可以先做，哪些可以并行。与开发人员在一些项目的测试中如何协调就是考验你做事的条理性和计划性。
3.从全局考虑产品测试的能力
每一个测试人员在产品测试中，重点肯定是自己负责产品的功能，此时就容易遗漏其他的一些测试项目。有可能是接口的部分功能，又可能是升级或年结的部分功能。此时，你如何提请他们还有漏测的功能点。在有限时间内，能找出他产品测试上的薄弱点，就是考验你通盘考虑产品测试的能力。
后记
上面就是我对6年测试工作的一个回顾。这些都是我个人的一些观点，很不全面，也有不正确和遗漏的地方。大家看后，能从中得到一些自己需要的东西，我就知足了。
再次感谢在这6年中给了我许多帮助和支持的各位兄弟姐妹们。
附录A、QA工作心得
看过许多同行兄弟姐妹的工作感受，反映了一些从事QA工作过程中的困惑，心里也很有同感。之前做过几年的测试工作，到了新的公司开始做QA工作，虽说测试工作也是属于质量工作范畴，但是真正干起来才发现，还是有很大的不同的，尤其是思想方法和工作方法上。所以也是边学边干，这边和大家分享一点心得。
1、调整好自己的心态。
尊重开发人员、产品经理、项目经理等项目组内同事，不要把自己定位为监工，要把自己定位为服务员。如果你真的是从心里想帮助大家把事情做好，而不是教训别人，大家会感受到的。很多时候，调整好自己的心态才是难点。
2、有的放矢 不要盲目的发表意见，要做到有理有据，这也是避免项目组内成员产生争执和不理解的前提。在提出意见和建议前，最好做一下调查，收集一些资料和数据，或者和大家深入的聊一聊，开一些交流会，座谈会，收集到一线开发人员的真实感受，不要自己一觉得有问题就冲出来，这样肯定会被别人反感，也会降低大家对QA的认同和信任感。
3、数据说话
质量工作相对务虚不假，之前做测试好歹还有很多的bug摆在那里，刚开始做QA工作确实觉得虚了很多。自己的产出在哪里？后来发现，其实还是可以有很多的，呵呵。你可以给相关人员进行培训（质量知识、软件工程知识、产品开发知识、质量制度和规范等等），会议记录和培训资料算是你的产出的一部分。另外，对于项目过程中产生的问题，变更等，要有记录，一定周期内作出分析和报告，比如，变更发生率，项目延期的原因分布，与计划的不符合程度等等。进一步提出改进建议，有了这些数据支持，你提出建议也就更有说服力。
4、沟通再沟通
其实很多问题都是发生在沟通上，我觉得沟通好了，起码可以解决70%的问题。多为大家提供交流和沟通的机会，比如，发起一个交流会，让组内同事互相培训，形成一个良好的内部学习交流气氛。另外，什么也比不过面对面的沟通，抛弃聊天工具和email吧，走过去，和你的同事一起好好聊聊，吃饭的时候，坐车的时候，你会发现很多深入的问题的，呵呵。
5、循序渐进
规范制定好了，不要一下子就想完全推行到底。毕竟要改变别人已有的习惯，是会让别人不舒服的，呵呵。所以要循序渐进，分期分批，一点点来，习惯慢慢的就被改变了，这样大家就不会太抵触。而且，在分期分批推行规范的过程中，别忘了不断收集反馈意见，不断改进和修正规范，规范可不是qa说是什么就是什么的，一定要收集大家的意见，达成共识，这样才有被大家执行的基础。
6、展示自己
QA工作务虚，但是可以落到实处，是有很多实际工作要做的，比如文档编写，规范起草。培训、评审、跟进问题。这些工作的成果如何体现，效果如何，可以通过一些问卷调查，来收集大家的反馈，举个例子，如果推行产品开发流程规范前大家对流程的满意度是50%，推行规范两个月以后，满意度成了90%，你说这是谁的功劳呢？呵呵，这也是数据说话的一个方面，也是QA工作成绩的展现。说了这么多，其实我做QA工作也只有3个月，还有很多的不足，希望能和大家多多的交流，如果自己的一点心得，能够给大家一些帮助或启发，就深感欣慰了，呵呵。欢迎拍砖！
附录B、SQA之Q&A 软件质量保证，即 SQA，全称是 Software Quality Assurance。
问： SQA 目的是什么？
答： 对于任何的行业，讲到质量控制，归根结底都是为客户提供更高品质的产品，更好地满足客户的需求。质量有问题的话就不能满足客户的需求。在 CMMI 里边就有 “ 集成流程产品开发 IPPD(Integrated Product & Process Development)”，为什么要集成呢？就是说产品的研发不仅仅是开发团队的工作，还要把市场团队、销售团队、整个的流程、包括客户的反馈都要考虑进来、集成进来。目的是为了什么？其实就是为了更好地满足客户的需求。六西格玛里面说 DPMO(Defect Per Million Opportunities)，百万产品里有缺陷的产品只有三个。这是为什么？就是为了减少差错，从而让客户享受非常高质量的服务。
问： SQA 等于测试？
答： 测试其实只是 SQA 的一个环节，SQA 的全称是软件质量保证。在国外很多的大型的企业，比如说摩托罗拉、爱立信，他们的研发团队里面都专门有一个 QA 部门，其实他们并不是做测试工作的。QA 部门其实是管理开发流程的执行，并专门负责制定产品开发流程。比如说 RUP 里面有一个角色，叫 Process Engineer，过程工程师，他就属于 QA 部门，他的工作就是负责制定整个软件开发的流程。因为如果说要保证质量的话，不能只靠测试来保证。而必须在整个开发流程的各个环节都要做得很好，才能够真正地提升软件的质量。而测试只是整个开发流程最后的一个阶段。所以说一个好的流程就决定了一个软件的开发能不能按时交货，能否保证软件质量。这个流程就是由 QA 部门来制定的。QA 部门还有另外一个职责，就是保证整个研发团队能够严格按照这个流程来运作。在项目到达每一个里程碑的时候，QA 部门的 QA 经理就会介入，对项目做一个审核，检查前一阶段的工作是否按照公司制定的流程来运作。看看该有的工件是不是都有了，该有的步骤是不是都有了。开发团队要证明给 QA 人员看。只有过了这一关，QA 部门才会同意说开发团队可以往下走，进行下一步的工作。所以严格来讲，众广义上理解，SQA 是针对整个软件开发流程的，它关心的是怎样在软件开发生命周期中来保证好软件的质量。这是一个非常大的概念。
问： SQA 在 RUP 中是如何体现的？
答： 其实 RUP 整个流程都在讲 SQA。业界常见的模型，譬如 CMM/CMMI，六西格玛，ISO9000，RUP，它们做的基本上是同一件事情--都是在做流程改进，都在做质量控制，但是各自的侧重点不一样。像 RUP 和 SDP 专门侧重于从软件开发的整个生命周期来保证软件质量，所以对软件开发商特别适合。而其它的模型，侧重点则在其它的环节，比如说 ISO9000，用在制造业比较多一些； CMM，原来是应用在软件这个行业的，后来扩展到 CMMI，就扩展到其它行业它也适用。但适用面越广，它拉的层次就越高，可实际操作的东西就越少。RUP 是专门侧重于软件项目开发的。怎样来保证做好 QA 呢？ RUP 里定义了一个软件生命周期模型，分成四个阶段--初始阶段、细化阶段、构造阶段、交付阶段，每个阶段有不同的侧重点，通过多次的迭代，每次迭代里面都要做质量控制。
质量控制从需求开始，有很多需求分析和需求管理方面的技巧和技术方法，它们从需求方面来保证软件的质量；到了设计，就有很多成熟的设计方法，例如可视化建模，基于构件的架构设计和现在提出的模型驱动开发方法；再到实现，到测试等方面，都有很多的方法和技巧来提高软件的质量。这里面每一个环节的目的都是为了提高整个软件开发的质量。
开发过程中，什么样的问题会造成质量问题呢？其实最主要的就是沟通方面的问题，以及对系统复杂度把握程度的问题。我们逐渐发展了一些技术来帮助我们解决这些方面的问题，例如用 UML 这种标准化的语言来增强团队的沟通，用面向对象的技术来帮助加强对复杂度的控制能力。
原来这个系统很复杂，使用面向对象的方法，本身就是为了简化系统构建的复杂度。改变你看问题的角度，你对问题的把握程度就会不一样。譬如人看一个二维迷宫很容易就能找到出路，但蚂蚁在里面就走不出来，因为看问题的角度不一样。面向对象方法和可视化建模技术可以让开发人员可以更好地去把握系统，增强对系统的可控制能力，从而从这些维度上来提高和保证软件的质量。
现在有很多自动化的工具，如 IBM Rational RAD(Rational Application Developer)/ RSA(Rational Software Architect)，都是支持 MDA 的开发方法，在模型这一级进行开发，从模型直接生成代码。在开发方面我们有很多辅助工具，帮助开发人员尽量将人工做的工作、复杂的重复性的工作、不具有创造性的工作让工具来做。让人去关注他应该关注的方面，比如开发人员应该关注业务逻辑的处理，但是软件的构建方面我们是尽量让工具来降低构建细节上的难度。这样也是有助于提高质量的。
然后产品出来了，需要进行测试，有测试流程、测试规范来帮助保证质量，这是最直接的。然后还有很多的环节还会发生错误，比如配置管理、版本的管理，也需要相关的支持来保证软件的质量。所以说软件质量保证不应该只是在一个环节上，比如测试环节来保证，而应该是整个的流程，我们应该全面地去改进流程来保证质量。
问： 做 SQA 这方面的人员，在沟通方面需要的什么样技巧和能力？
答： 首先从大的方面说，整个团队的沟通，首先是大家要讲同样的语言。UML 只是这种语言的一部分，我们不要狭义地理解这种沟通语言就是 UML。它还包括采用一个什么样的流程方法，整个团队都要理解。譬如你说项目正处于 “ 精化(Elaboration)” 阶段，这个团队都要能理解这个术语。
还有就是整个组织机构内部大家采用的流程都是要一样的。举个例子来说，Rational 有很多产品，其中很多都是收购来的。不同的产品团队采用的开发方法、开发工具都是不一样的，他们到了 Rational 之后做的第一件事就是整合。这个整合一方面是说产品要整合起来（我们有 Suite 产品）；同时也是针对开发团队开发方法的整合，例如 Rational 花了一两年的时间把所有产品团队统一到 RUP 和 ClearCase/ClearQuest平台之上，这是我们的首选。实际上到了 IBM 之后也是一样，IBM 现在正在做的计划就是让所有的实验室、研发团队都要使用 IBM Rational 自己的开发工具，他们都在使用 IBM 自己的开发方法、开发平台。这就是让大家的沟通基于一个统一的基础架构 ―― 统一的软件开发平台，这也是增强沟通的一种方式。另外，讲到 SQA 的人员，在 RUP 里对应的就应该是 Process Engineer。他的主要的职能就是定义流程，保证流程的执行，并且不断地改进流程。对他的要求就是要对流程要比较了解，有实际项目的开发经验，不然没有办法理解流程，这是技能方面；另外就是与人的沟通能力要强，跟一般的开发人员和项目经理是有区别的，沟通的能力一定要强，他要负责说服项目团队来遵循标准。
问： QA 人员与目经理和开发人员之间的关系是怎样的？
答： 首先彼此之间是一个合作的关系。如果片面理解 QA 人员只是 “ 过程警察 ” 的话，就可能把他和其他的角色对立起来了。实际上在一个团队内部要避免这种认识。因为大家都是在一个组织架构内部的，大家的目标是一致的，就是要把公司的业务做好。所以 QA 人员的职责和任务就是帮助这个项目团队更好地进行软件的开发。既然已经定义的流程是比较适合企业的，项目就应该遵守这个流程来进行开发。如果有时候项目因为赶工，或是其它的原因违背一些流程上的规定的话，就会对软件的质量会造成一定影响，他就有责任来帮助开发团队来纠正这方面的一些错误。还有就是进度方面的问题。如果不按照流程来走的话，短期内看起来进度是快了一点，但从整个项目的周期来看，有可能是给以后的工作带来隐患，客观上肯定是延长整个开发的进度的。所以对于一些流程管理得比较好的企业，你会发现他们的 QA 部门和开发团队是相处得比较融洽的，配合是比较紧密的。在我们的客户里就看到过他们的开发团队非常感谢自己的质量控制人员，觉得他们对自己是给了很大的帮助。
QA 人员跟每一个角色的关系，如果你对应到 RUP 的话，RUP 里就定义好每一个角色是做什么工作的。RUP 里分了 9 个规程(discipline)，流程工程师是在环境规程里边，项目经理是在项目管理规程里边。每一个规程其实就是一类开发活动，其中的角色和他们所产生的工件集合，是一个分类。可以把项目经理相关的工作，他所涉及到的工件，比如说软件开发计划、风险管理计划、质量保证计划都放在一起，放在这个规程里面。所以 QA 人员跟项目经理的关系就是去检查项目经理在这个岗位上所做的职责是否到位，是不是跟流程相符合。其他的角色也是一样的，譬如一个测试人员，就要看你有没有根据规定把缺陷按正确的测试流程汇报，发现缺陷之后是否能够得到改正，并作一个复审，还有回归测试的时候有没有考虑测试的完备性等问题，就是看测试人员有没有做好具体的工作。QA 人员和整个项目团队在工作中的关系就是看每一个角色是不是很好地完成了自身角色所应该完成的开发任务。标准是什么？就是这个组织的流程，流程是保证质量很重要的一个依据。
问： QA 人员如何判断其工作效果和质量？
答： 最直接就是 RUP 里的工件。可以去检查这些工件，可以根据检查的结果来判断角色是否达到了要求。既然是检查这个结果的话，就有必要涉及到统一流程和工具的问题。就是说开发团队有必要采用统一的开发方法和流程。不然的话每一个开发团队各自采用不同的开发流程，流程工程师就很难去评价，没有一个可对照的标准，没有可比性。另外，和采用的工具也有关系，就是说团队要尽量采用统一的开发平台。采用统一的开发平台，工具会帮助自动收集很多的信息。比如说我们的 Project Console 可以帮助收集很多量化的指标；现在有 Portfolio Manager，项目组合管理平台，可以帮助了解项目进度还有项目进行过程中产生的各种结果；还有包括测试的报告等等，这些都最好有一个统一的标准。打个比方来说，现在的航空公司都会选择相同飞机制造厂商的机型，就是要降低维护的成本。因为机型比较统一的话，就比较好进行管理。在一个软件企业的话，在内部采用统一的软件开发平台也能有助于企业判断项目的情况，判断的方法也会相对比较简单，工作量会降低。
这是从 QA 的角度来看，其次从整个团队的角度来说，今天是做这个项目，明天做另外一个项目，作为企业的管理人员肯定不希望员工今天做这个项目用一个工具，明天做另外一个项目用另外的工具，这样学习成本就太高了。
第四篇：测试工作经验总结
测试工作经验总结
功能测试最重要的是理解业务和需求。知道系统要实现什么功能，业务流程是怎样的，然后就可以根据需求编写测试计划和测试用例了。测试书籍上介绍常用的编写测试用例的方法有：等价类、边界值、因果图、判定表等，在实际工作中，我使用较多的有等价类、边界值、场景法和错误猜测法。在这里需要提一点，将测试用例按测试目的进行分类，比如用户界面、功能点、业务场景等，会让测试用例的结构看起来更清晰，执行测试用例的效率也更高。
要做好功能测试，还需要对整个系统的数据库结构比较清楚，每个功能点涉及哪些数据表，对数据的操作方式是怎样的。这样就不单从前台页面来进行测试，通过对数据库中数据的验证，可以发现隐藏的一些bug。比如库表没有进行关联删除，从前台页面是看不出来的，但实际可能导致程序出现问题。对一些比较复杂的组合查询或数据排序，也可以自己编写sql语句对结果进行验证。
了解程序的框架结构和一些开发知识也有助于更好地测试程序和定位错误。
测试用例的编写经验步骤和数据的分离
将输入的各种数据已参数的形式表达在操作步骤中，而不需要为每一种输入数据创建一个测试用例。
例如：atm存款
好的测试用例，在执行的步骤(Step)的表达上应该是尽可能和数据相分离。举例来讲，有一个ATM机取款的功能，可能有以下几个场景：
1.密码正确的登录
2.密码错误的登录
3.密码输入三次错误，卡被锁定
4.取少于余额的款项
5.尝试取大于余额的款项
6.尝试取等于余额的款项(考虑手续费)
6.取款额度大于当次的限制
7.取款额度大于当天的限制
7.取款次数大于限制次数
等等
不管你用什么用例设计的方法论来做指导，作为这个简单的例子，有经验的人都应该能看出，此处的很多步骤是可以重用的，总结下来如下(此处只列出了操作的步骤，略去了系统的交互中的反馈结果)：
1.插入卡->A:输入密码->B:按“确定”键->重复A-B
2.A:选择取款功能->B:填写取款金额->C:点击“确定取款”的按钮->D:取现金->重复A-D
因此，我们只需要写出两套比较完整的步骤，将密码和取款金额多数字用参数来表达即可。这样是不是简单了很多呢?单独的测试基础数据准备工作
将测试基础数据提前准备好，写到你单独的测试数据准备文档中，而不是分散到 所有使用到它的case中才去描述。测试用例的前后置条件
除了第二点中谈到的数据需要准备外，在测试用例这个Level，必须有一些条件满足，您才能开始执行它。集中的把这些步骤整理成一个相对独立的操作单元，具体用例中只要引用就可以了，这样会便于对用例的理解和在多处复用。
顺便说一下，对于一些类似软件运行环境的条件，比如安装和配置测试中，需要3种操作系统和3种浏览器的组合等，我们可以把他放在Test Set这个Level上来，不用写多个用例，只是在测试计划和执行的管理系统中作为测试集的一个环境参数，恰当地表达出来就可以。
第五篇：手机测试经验总结
手机测试经验总结
VPM主要是激励团队成员测试和学习，而不是自己去执行用例。当被委派为一个项目的测试经理时，VPM应该清楚项目计划和转折点、软件发布时间表、产品定义特征列表。
1、作为VPM应具备以下几方面能力：
（1）、用不同的方式看待问题
（2）、制定计划，满足项目上市时间
（3）、依据质量、时间、成本对PR进行判断和决定
（4）、增进沟通，总结不同项目的经验
（5）、和团队的密切合作
2、测试工作点：
（1）、测试软件机制
（2）、分析问题
（3）、对产品进行认证并得到相应证书
（4）、评估对于返修率、最终用户和运营商抱怨的影响
若做欧洲市场的产品，一定要做CE认证。FCC认证在Latam市场是必须的，CTA认证在中国是必须的。
一、相关测试知识学习
1、软件测试包括测试计划、测试设计、测试执行、测试评估这几个阶段；
测试计划：
了解软件当前状态及客户对软件的需求；
了解产品规格书：按键定义及菜单树；
管控和跟催软件方案商的版本发布时间；
测试设计：根据客户需求和产品规格说明书来编写测试用例；
测试执行：测试策略包括基本功能测试、UI测试、冲突测试、压力测试、兼容性测试、验收测试
测试评估：进行三次全面测试，由方案商发出软件和报告，TMC和SZ Team
同时测试并反馈给方案商，如此反复数次，方案商改善结果并商讨最终结论。
2、场测
在硬件成熟、软件基本成熟的情况下做场地测试，主要测试这几项：寻网时间、呼通率数据、通话质量、Wap测试、FM测试、信息、紧急呼叫、基本功能测试。
3、说明书测试
验证说明书基本功能是否正确，是否清晰易懂、排版规范、无错别字等。
4、认证分类
按照销售地区分为国内认证和国外认证，国内认证是CTA认证，国外认证是CE认证和FCC认证。CTA认证需要拿到国家无委颁发的入网证书、受理中心颁发的许可证书、3C认证颁发的3C证书。
点击咨询 