漫谈接收测试

        所谓接收测试，一般情况下是厂商在自己系统具备出场条件时，由厂商发起，客户验证厂商系统的过程。但是根据系统各自的特点和要求（如boss系统的业务复杂度特点以及稳定性要求等），接收测试可能会进行多轮，根据既定的目的进行每轮接收测试。

       从我参与的两次接收测试和大家探讨一下关于接收测试。

       个人认为接收测试最重要的一点是---接收测试的目标性，通常接收测试都是在已提供接收测试用例的前提下进行的。所谓接收测试用例是客户和厂商根据系统的详细需求等信息而编写的一个系统功能覆盖列表，接收测试用例需要经过编写和评审两个阶段来最终定型，同时接收测试用例很多情况下是在系统还没有实现的基础上编写的，所以接收测试用例应更加关注各个功能点的输入和输出，而不是其具体的实现。作为厂商一定要先明确此轮接收测试的目标，然后根据目标制定出此轮接受测试的计划。目标不明确的话，很有可能造成接收测试过程的不可控。接收测试目标的制定，要直接参考当前的版本状况，而不是盲目的制定一堆根部就不可能达到的目标。像我参与的其中一次，本来是为了让客户验证我们当前版本的功能，以及此功能是否符合客户的需求，结果因为研发计划的延期直接导致了当前版本的不可用，最终演变成为了客户发现我们系统bug的过程，这个给客户留下极坏的印象，如果不是我们在客户层面的关系做的不错，估计我们早早的就可以回家了！所以能否制定出可操作和客户可接受的接收测试目标是接收测试能否顺利实施的关键。

       接收测试的准备工作也是非常重要的，虽然说接收测试的目标性是最重要的，但是这是在版本已经稳定，已经通过了内部的接收测试的前提下，否则接收测试最好不要发起！发起等于留给客户一个很差的第一印象。接收测试的准备工作，主要包括版本的研发、内部接收测试及测试用例的编写和评审等工作。上面我已经提到了关系接收测试用例的编写和评审相关事宜，而对于版本的研发这个不用说大家都知道，版本不研发完成怎么进行接收测试呢。而对于内部接收测试工作，这也是必须的，经过了版本测试，再进行一轮内部接收测试，可以最大限度发现我们系统的问题，以及准备各种接收测试的数据和场景，使之和客户进行接收测试时，速度能够加快、质量能够保证，争取一次完成更多接收测试场景。

       第三个我要提到的是人的因素，正常情况下，接收测试工作都是由测试人员和客户来完成的，作为接触客户的第一团体。由于接收的版本不可能完全符合客户的需求，那么测试人员就要承担说服客户在不影响功能需求的前途下，接受我们版本当前的实现方式，往往客户会提出很多异议和新的需求，对于作为在测试人员后方的研发线，一定要在最大程度上给予测试人员支持，如果出现了客户提的需求和改进意见在测试转达给开发或是设计人员后，得到的结果是不屑和愤慨，那么测试人员真的就太委屈了，一边受客户的不满，一边还要受到研发线的不满。作为接收测试的负责人一定要注意到这一点，可以这么说测试人员的接收测试态度很大程度上决定了客户对系统的满意度！

      总结一下，开展接收测试，我们要先制定出可行的接收测试目标，然后制定出详细的接收测试计划，当然接收测试的各种准备工作一个也不能少。聪明的负责人会善于协调各种工作，让自己的下属在一种积极的氛围下工作，使接收测试工作在自己的可控计划中顺利开展！