EIAC测试经典问题总结

前言：在EIAC项目组参与测试接近三年，成功测试了很多业务功能和流程，但同时也出现过多次失误和雷区，其中有些失误确实是难以避免的，但是有些可以通过仔细测试，或者通过有效沟通或其他用例评审等都是完全可以避免，本总结统计和分析在EIAC测试过程中，出现的几次严重失误，作为后续测试的经验教训，为自己后续参与其他项目提供参考，也为后续其他测试人员参与EIAC提供简单的指导，以便重复同样或类似的错误。

问题一：

问题描述：（由于时间长，以前没有记录，记不太准了，大体是这样的！）在业务流程中，有两个功能块，每个功能块分别对应着一个开发人员和一个测试人员，两个功能块在测试环境都没有问题，上了生产环境，只是做表面的checklist，也没有发现明显问题，但是第二天用户报障，让整个项目组挨批；

问题原因分析

问题之所以没有在测试环境被发现和挖掘出来，主要是因为涉及两个开发人员，同时测试阶段也是两个不同的测试人员，不是在同一时间测试，代码有覆盖，未及时发现，上线到生产时，由于第二个补丁部署上去以后已经比较晚，第一个补丁已经检查完，待第二个补丁部署完成后，没有重新检查第一个补丁，同时，在测试环境测试通过后，开发之间没有互查代码

解决和避免措施

针对以上问题。项目组讨论，从根本上杜绝问题存在，即：

1、针对测试环境，每周一做一次同步，所有开发人员开发新补丁或功能时，获取最新代码；

2、在测试环境补丁测试通过后，由平台级开发人员进行代码复查codereview，

3、测试人员在保证测试环境没有问题的情况下，在测试环境进行checklist时，要等同批次所有补丁部署上去再做全面检查。

问题二

问题描述：

问题的原因出的有点可笑，但这确实影响面还是挺大的，具体是：测试环境在深圳公文发现word控件有乱码现象，于是就告诉了开发人员，过了一段时间，开发人员就说，再试试，此时测试人员再试，问题已经不能重现，于是，测试人员就认为问题已经解决，在生产环境验证时，验证公文问题也只是验证了省本部的广州市的

原因分析：

    当测试人员汇报了问题，开发人员并没有及时去解决问题，而是从生产同步过来后，直接让测试人员试试，测试人员试过以后发现没有问题了，就以为是问题解决了，而实际上，只是同步了代码，并没有真正解决此问题，所以问题还是带到了生产上，但是在生产上检查时又漏掉了检测深圳市分公司的。所以造成这么严重的失误。