在手续费的整个设计阶段和开发阶段,以及后期的维护阶段中,得到一点测试心得和大家分享一下。
一、准确理解需求。
我认为测试首先要准确的了解系统是干什么的，要达到一个什么样的效果。设计阶段中就已经确定了什么事情系统是能够完成的，什么事情是系统不能够做的。测试不但是各个功能单独的测试，最好能够从整体上了解整个系统的结构，流程等等。理解需求，包括两方面，一个从我们程序的角度，即我们的详细设计文档所描述的具体的什么表，什么字段等来了解。了解什么功能的实现跟那些表，那些字段有关，做了某些操作后，这些表的字段应该发生了什么样的变化。这些都是建立在对系统的深刻理解的基础上面的。另一方面，从客户哪个角度去理解需求，因为客户不会管我们实现这些功能具体是怎样实现的。但是他们对业务的理解会比较深，有些情况（情景）是要在实际操作的时候，才可能考虑得到。对需求的准确理解是验证程序的正确性的最重要的要求。如果测试的过程中不清楚系统应该实现的怎样的功能,必须通过各种途径了解清楚。
二、测试重点要分明。
测试整个系统的过程中，对一些关键的重要功能的测试，必须重视它，反复进行测试。根据可能出现的种种情况进行测试。因为这些关键的部分有问题会引起其他相关的一连串的错误。
三、测试案例的准备和保留。
对于系统整个流程的各个功能，每个功能的各种应用的情形，准备好相应的情形的数据,(做好备份),以备修改好后可以重现或检查。理想状态下应有完整的记录说明，什么样的数据是做什么测试用的.
有些经常要用到的测试，最好能够另外编写很简单的测试驱动程序。可以写些专门用于校对数据的准确性的小程序。案例的准备数据和应有正确结果对于回归测试特别有意义。
四、沟通技巧
沟通的时机主要是一个测试前，一个在测试后。测试前务必了解清楚系统的功能点。测试员必须不耻下问，程序员回答测试员问题的时候也不应该感到厌烦.第一点中已经有过这方面的说明。测试员在问程序员问题之前，最好自己首先阅读相关的设计文档和数据库结构.心中有底之后，再带着疑问去咨询，会取得比较好的效果。对需求有了准确的理解后，做好数据准备后开始测试，测试完成后,记录测试结果。发现问题的时候要重复多次，最好能够重现错误。有些错误确实不能每次都重现的话，尽量回忆清楚发生的情景是怎样的，好描述或演示给程序员看。有的时候，可能确实不是程序的错误，而是操作不当引起的。这种情况应该区分好，有的时候应该坚持自己的理解，当双方对同一个问题的理解出现分歧的时候，必须找系统分析员或项目经理确认一下谁的理解是正确的。沟通的时候，测试员要很耐心的聆听对方的意见。有的时候以邮件的方式沟通比较好，不要所有的沟通都以口头完成.当双方都比较烦躁的时候，可以暂时把问题放在一边，不要争吵。等大家平静下来的时候再继续讨论问题。
五、测试的顺序
测试有单元测试，集成测试和压力测试等，还有白盒测试，黑盒测试等分类.我觉得测试一般来说先进行功能性测试，然后再进行压力测试.可以借助一些工具来辅助测试。测试的数据不能太少，有时数据太少就不能暴露出某些问题。集成测试的时候,重点测试各个接口,这时对整个系统的全局的了解,整个流程怎么走必须心中有数。通过测试驱动开发，从而提高软件的质量。
六、测试的分工合作。
测试的时候是很需要老老实实的执行程序的，千万不能想当然。测试需要分工合作,测试计划和案例跟着需求变动，特别是后期需求发生了变化，时间又紧迫的情况下，测试的文档就很容易跟不上。到后期编码任务基本完成后交付给客户之前需要进行详尽的完整的测试。以前我们会进行交叉测试，但效果不是很理想。测试后集中修改，必须进行回归测试。特别是项目后期的集成测试的时候，最好能够大家有计划的安排好测试的内容，准备好一些数据可以从头走到尾，尽量覆盖比较多的案例情况。尽可能不让重要的Bug逃逸。
七、如何面对客户
前面第四点描述的是我们内部的沟通。当我们有机会面对客户的时候，也要注意跟客户的沟通技巧。用心聆听客户的声音。不能先入为主的认为我们的程序就是完全正确的，客户什么都不懂，或者客户是在提无理的要求。我们认真的听取客户的意见，把需求收集起来，去芜存精。然后我们再根据实际的情况决定是否修改程序。如果有的时候确实不能修改程序的时候，也要耐心跟客户解释清楚。
以上就是在做测试的过程中的一点点心得，欢迎大家能够多点交流各自的心得体会。
此文来源于51testing论坛，转载请注明出处
