最近负责的 L 项目从 3 月初开始开发到 6 月底正式上线，这是我在工作快 1 年时间里第一次独立负责一个从 0 到 1 项目的全部测试工作。这边团队中项目的质量要求都比较高，测试流程很规范，对测试人员自身的要求也比较高。从项目开始时制定整体测试方案，到模块测试、集成测试、兼容性测试、异常测试，最后到上线，一整个流程跟下来，我对项目整体的测试工作的开展也有了更宏观的认识。项目上线前比较忙忙，趁现在项目上线后还没那么忙的时候，反思一下项目测试过程中那些做得不太好的地方，在以后的工作中能有针对性地做一些改进，做得更好。

1、项目排期时的时间预估能力欠佳

记得刚开始进行项目排期的时候，其中一个模块我是这样排期的：接口测试方案及用例设计 2d，接口测试执行 1d，UI 口测试方案及用例设计 1d，UI 测试执行 1d。罗仔看了后说，你这个不太合理啊，预估的时间太短，不可能完成的。但哪项工作到底需要安排几天我当时确实有点懵，然后罗仔指导我重新排了个期。排完之后，这个模块重新排期后是这样的：接口测试方案及用例设计 2d，接口测试执行 3d，UI 口测试方案及用例设计 2d，UI 测试执行 3d。当时我内心的想法是这样的：这时间排得有点多啊，到时候万一时间用不完正好多了一些学习的时间~~~然而实践证明，我想错了。在真正开始项目测试才发现，时间看起来排得宽裕却常常不够用，工作过程中总是会遇到各种各样的问题需要花时间去解决。

有一次项目时间赶，周末过来加班，遇到了我们测试小团队的负责人策策，然后我们发生了下面的对话：
他问我，怎么周末还来加班？
我说，有些技术刚上手还不太熟悉，所以进度比较慢。
他问我，当初排期的时候怎么没有把学习新技术的时间也考虑一点进来呢？
我说，这怎么好意思啊？
他反问我，开发使用新技术时，在项目排期时都会加上新技术的调研时间，测试使用新技术不也应该留点学习的时间余地吗？

我竟无言以对，为啥会不好意思呢？可能是因为工作才 1 年，感觉到自己的思维还是很学生的，好像排期越短越能体现自己工作很努力一样，排期排得长一点总会有一种偷懒的错觉，还不能以一种客观的态度来对待工作。在预估时间时总是想得太顺利，忽略了可能遇到的各种各样的问题。
我感觉，对项目合理排期及把控时间也是一种个人能力的体现，从拆解任务点到合理预估每个子任务点需要花费的时长，这其中还包括了对可能出现的问题的预估。而这项能力的培养依赖于以前的一些项目经验以及及对踩过的一些坑的总结反思。

在以后的项目中，要结合实际的项目经验，在时间预估过多和过少的时候多进行一些思考，提升自己这方面的能力。

2、QA 写单元测试

项目中有一个计算价格的基础服务模块，其中有一个计算字符串中包含的所有规则（例如重复、连号、ABAB、特殊含义等）的方法。当时选用了写单元测试的方法来进行这部分逻辑的测试，花了不少时间去了解开发代码的处理逻辑，选择了很多包含特殊规则的字符串作为输入，然后断言是否包含指定的规则。写完之后，把代码发给开发，让开发加进项目工程代码中，但内心总有种说不出的异样感觉，毕竟项目代码都是开发写的，加入自己的测试代码总有种自己是外人的感觉。

不可否认这个过程中对这块代码的熟悉程度增加了很多，但总觉得哪里姿势不对。单元测试是必要的，能从根本上减少 bug 及定位 bug 的成本，也能够提高代码重构的成功率。但总有疑问，单元测试不是应该让开发做吗？遂百度之，看到下面的这段话，正解我惑：单元测试应该由最熟悉代码的人来写，这是好的单元测试的标准之一。测试人员进行单元测试，工作量大、周期长，结果事倍功半，所以单元测试应该由开发人员自己来写。

以后，遇到同样的问题，我想我会这样做：推动开发来写重要底层模块的单元测试，我通过统计这些模块单元测试覆盖率的方式，来检查单元测试的覆盖情况。

3、集成测试方案不够精简

拿集成测试来说，这里所说的集成测试是指模块开发结束之后，对项目整体做的系统级的测试。在之前的模块开发阶段，功能不端叠加，在集成测试阶段，系统已经相对稳定。集成测试的重点应该是模块间的交互及系统整体的业务流程。但在制定集成测试方案的时候却没有一直围绕这个重点，做了一些投入产出比比较低的工作。
下面是之前出的集成测试方案，在设计方案的时候还专门花了一些时间进行了 P0 级别回归用例的挑选（去除了部分 UI 用例）。方案评审会的时候也是主要讨论了组合场景分析及用例设计，还有围绕重点 bug 进行的一些思路发散。但测试执行阶段发现 P0 级别用例回归及 bug 回归基本是不需要做的，因为 P0 级别用例大都是前后端的基础功能，而这些在组合场景的用例设计中已经全都覆盖了。而 bug 的回归在集成测试开始前已经全部回归过，再做一次也基本没有必要。所以最后真正执行的就是组合场景用例及重点 bug 的发散测试。

其实不光是集成测试方案，在设计其他测试方案的时候（如异常测试方案），都有点不成熟的想法，就是觉得既然是测试方案，就应该要 “多一点，全一点”，在方案和用例的精简及有效性上思考得不够多。可能很多新人都会走过这一步吧。
以后在各个测试阶段开始前，都要多花一些时间进行全盘的思考，尽量设计出精简而有效的方案及用例，提升工作的效率。

4、排了优先级也很难取舍

有时候跟罗仔反馈说项目时间比较赶，他总提醒我，要先排个优先级，挑重要的先做。其实我思考过各项任务的优先级，但可能是缺乏一些判断的经验吧，总感觉手上的工作好像都很重要，很难取舍，特别是在要放弃一些不重要的东西。就拿浏览器兼容性测试来说，虽然对浏览器按优先级划分了 P1、P2 优先级，但后来时间比较赶的时候讨论决定放弃 P2 级别的浏览器不做兼容性测试的时候心里总还是不太放心。可能是项目经验不太多，总想做到大而全，但互联网企业中项目迭代一般都很快，根本不会有那么充足的时间，而且往往也不需要那么全。

以后的工作应该花更多的时间和精力去思考投入产出比，抓住主要矛盾，在解决主要矛盾的基础上再去做其他的工作，在时间进度赶的时候可以舍弃一些不重要的事，这样才能把控好项目的整体进度不至于乱了阵脚。

5、搭完 redis 集群却不了解 redis 运行机制

开发环境的 redis 集群是运维搭的，1 主 1 从，3 个哨兵结构，分布在 2 台机器上，1 台机器上 1 主 1 哨兵，另 1 台机器是 1 从 2 哨兵。虽然之前看过一些 redis 的教程，但了解得还是比较浅的，之前也想过请运维来搭这个 redis 集群，但之前一直想自己亲手搭一回 redis 集群，这个难得的机会还是应该把握一下自己动手实践一下。然后就开始对照网上的各种教程，按照开发环境的配置搭了一套 1 主 1 从，3 个哨兵的 redis 集群，只不过我是搭在同一个 docker 容器里的。花了很长时间了解了 redis 各配置项的意思，准备好了 5 份配置文件，踩了很多坑最后终于把 redis 集群搭出来，但 master 进程总是会莫名其妙地挂掉，网上查阅各种资料也没能解决这个问题。后来我就去请教了组里的吴大神，跟他描述了下我搭的 redis 集群及遇到的问题。

他问我，测试环境的 redis 为什么要搭集群啊？
我说，我是按照开发环境一样的结构来搭的。
他说，使用主从结构是为了保证高可用，测试环境只需要一个 master 就够了，而且没有主从结构，也不需要哨兵。
然后他指导我排查了下问题，最后发现是配置中 docker 中的 ip 和宿主机 ip 没用对导致的。

之前查看开发代码，redis 的配置文件中是指定了哨兵 ip 和 mastername，但因为之前没有用过 java 代码去连 redis，更不清楚 java 代码连接 redis 的方式有几种，还是不知道能不能只用一个 master 就够了。我去咨询了下开发，他说不行的，因为代码中是通过哨兵 +mastername 来连的，现在的代码不支持直接连单个 master。后面又自学和实践了 redis 的哨兵机制、主从切换，对 redis 有了一些更深的了解，后面会专门写一篇关于 redis 的文章。

以后有新项目需要搭 redis 的话，我想我会这样做：搭 1 主 1 哨兵结构，或者跟开发商量下代码中能否支持只有一个 master 的情况，这样测试环境直只需要搭一个 master 就可以了，这样可以节省很多时间。

总结

写到这里，之前计划的一些点都基本写完了，但跟写总结之前在一些想法上也发生了一些变化。写总结之前是想分析分析做过了哪些无效的工作，走了哪些弯路，但真正挖下去，发现其实并没有绝对无效的工作。每个人都会走弯路，特别是在工作年限比较短的时候，走得弯路更多。但是如果在感觉不对劲的时候能够及时总结反思，那么走这些弯路吸取的经验和教训，都能够成为自己的宝贵经验，让以后的路能走得更顺利。而且自己经常是抱着学习的心态去尝试一些工作，这本身就是一个学习的过程，而学习本没有捷径，都是一个循序渐进的过程，通过一次次遇到问题、分析问题，解决问题的过程，不断挖掘，才会对所做的事情有更深的理解。

记得上次我去找小团队的测试负责人策策聊下关于在项目中的实践、学习以及自己的输出的时候，他提醒了我一点，对我很有帮助。他说，学东西要有个目标，自己定一些标准，要能量化地评估学习的成果，怎么样算是学得很好，怎么样算是一般。自己之前也有思考过要评估学习的效果，但一般都只是把学习及遇到的问题记录成文档，但感觉这样在深度上还远远不够。就拿 redis 来说，搭 redis 的集群的过程我都记录成了文档，但对于 redis 内部主从切换及哨兵的机制还不太熟悉。从我自身经验来看，在新学一项技术的时候可能还不具备自我评估的能力，我觉得可以去请教一下擅长这项技术的同事，让他们问自己几个核心的问题，带着这些问题，可以学习得更深入一些。

写这篇总结花的时间比我之前预估的要长很多，思考的深度也更深了一些。但写总结确实是一个很好的自我梳理和提升的过程。自我感觉在日常工作中思考得不够多，特别是一忙的时候，就光顾着干活而懒得跳出来多思考思考。以后的工作中，要通过定期写总结的方式来反思和总结近段时间的得失，做到清晰地思考和高效地行动。