从测试小白到测试组长，谈谈我的测试过程及管理经验总结

这几年来，跳的坑实在不少，有些也是自己挖。今天就来谈谈我的一些经验总结。

​

​一、 测试过程的经验总结：

1、测试过程中遇到严重的问题，除了登记在bug管理系统，也要反馈给领导。

为什么要反馈给领导？因为很多事情就算是让你背锅，你也背不起的，反馈给领导，领导会帮忙监督开发并给出意见。特别是紧急项目，不要在测试完的时候才给领导反馈，在测试过程就可以反馈了。

2、保管好自己的测试机子，不要轻易让软件开发人员或者其他测试人员动用了你的

测试机。

有时候测试资源比较紧缺的时候，开发都是乱拿机子的，看到谁桌上有就顺走了，测试完放回来，没通知你，压根不知道版本有变换了，还在胡乱测试了那么久。所以一定要保管好测试机。不然版本会乱的。

3、发现越多问题的模块，越来更加注意

因为有可能开发在这个模块的代码逻辑有问题，所以更加花更多的时间测试，怕一些隐秘性比较高的bug逃逸了。

4、测试的重点依附与测试背景

电信运营对性能和并发要求高，金融行业对安全性要求高所以要搞清楚测试的重点在哪。

5、用80%的时间花在20%的重点模块。

比如我们公司是做车载pos机（也有前置系统+web及APP），车载POS最重要的就是远程升级程序和刷卡交易模块了。远程升级如果没办法保障，是要技术支持要客户现场一台一台机子升级的，可想而知那个人力物力财力得花多少，而且给客户留下不好的印象。之前我们公司出现一个案例就是版本很紧急，测试人员在最后回归测试的时候，认为开发修改的不会影响到远程升级模块，所以没有测试。只测试了修改点。结果就出现升级不了的现象。整个研发部被批斗。

6、遇到问题，不能说软件开发在调查，就没有测试的事情了，测试也要跟踪原因，做好记录。

领导问你情况，一问三不知的话，会显得你很不专业的，而且知道了原因所在，你也知道开发大概要修改那一块的代码，是否会影响到其他模块，对于回归测试是很有帮助的。

7、一个版本一个版本的测试，不要接受开发在测试过程提交新版本。

这样不仅耗时，很有可能也会造成你的测试思路被打断容易造成漏测。而且你的bug回归，测试文档的编写都会很麻烦。不过这个要看公司的制度了。

二、 测试管理总结

公司的测试团队如何，要看测试流程及领导班子们的重不重视。

1、一定要完善测试流程规范包括提测试申请规范。

刚接手管理测试组的时候，整体制度是很乱的，流程也是很乱。请教了很多测试的前辈们，也上网学习了很多。然后就和我们研发总监提出要重新制定一个测试流程规范。

规范如下：

​

​有了测试流程规范，研发总监也在公司进行宣讲，并要求强制执行了，整体流程就规范多了。

2、测试用例需要组内不定期评审和修改。

只有不断改善才能发现更到的bug。类似杀虫剂悖论，一直使用那个牌子的杀虫剂，你家的蚊子估计都已经是有免疫了。

3、一定要和领导们强调开发自测的重要性。

开发没有自测，到测试这边一堆问题，问题一多，测试就容易乱了，很容易遗漏问题。另外就是开发没有自测过的，容易造成反复测试及版本多等现象，那测试人员就会被占用了。那组内测测试计划就很不好安排。我是刚好被我抓到2次，一次开发都没有和后台调通某个功能的报文，一次是机子在刷卡交易过程直接程序就崩溃了，有开发小辫子了，和研发总监反馈的时候有理有据，现在我们总监也一直在强调开发自测的重要性。

4、发布版本的时候，一定要再三检验版本是否正确。

一道屏障是：组内强调测试人员一定要确定放置到内部服务器的程序的正确性。

二是发布到生产服务器或客户前，一定要再三确认版本是正确的，和对应测试人员核对。

发错了将直接导致整批量的产品版本都不对，发到客户那边的话问题就大了。

5、重视测试报告的评审和发布决议。

以前我们公司领导对于要发布的程序的情况一定都不了解，程序到客户那边，收到客户投诉的时候就开始追究责任了。所以有些情况在发布前一定要让领导知道，目前要发布的版本还存在哪些问题，开发要留到下个版本修改的，或者不改，或者时间问题，没有测试的，一定要和领导交代清楚。领导知道了一个大概的情况，在和客户交付的时候也好说明，不至于到客户那边上线发现问题后反馈给领导，领导一脸懵逼。

6、一定要制定测试计划或测试工作表。

制定测试计划和工作表，对一个整体组内工作的情况有个明确的概念，另外根据测试人员执行测试的情况，填入测试计划中可以直观的反馈测试人员的一些情况，是否延迟，新增测试用例数，逃逸bug数等。了解组内测试人员情况，可针对性培训等。

​

​7、做好文档的管理和分类

测试文档多，且项目一多，文档更是多得不行，测试服务器上的文档管理分类也至关重要。做好测试文档的管理和分类，能让平常的工作便捷很多，领导查看时也不会觉得一团糟。测试的工作虽然处处是坑，希望大家都能及时发现坑，不往里跳。