第一次来这个论坛，发一个去年在公司给新人培训时讲的东西，欢迎指教

  测试经验总结（2005-2）
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.小结
 用户用软件，测试测软件
 培训时多想多问
 好记性不如烂笔头
 带着问题去测试，在测试中解决问题
 先做事，后学习，争取双赢
 软件不是一次能测透的

  在软件行业中，敬业精神尤为关键。默默无闻的测试员工作是比较枯燥和辛苦的，是否具有忍耐力、快速学习能力、沟通能力以及团体合作精神，是敬业素质的重点。