目录
前言
1、项目排期时的时间预估能力欠佳
2、QA写单元测试
3、集成测试方案不够精简
4、排了优先级也很难取舍
5、搭完redis集群却不了解redis运行机制
总结
结语
前言
最近负责的L项目从3月初开始开发到6月底正式上线，这是我在工作快1年时间里第一次独立负责一个从0到1项目的全部测试工作。这边团队中项目的质量要求都比较高，测试流程很规范，对测试人员自身的要求也比较高。
从项目开始时制定整体测试方案，到模块测试、集成测试、兼容性测试、异常测试，最后到上线，一整个流程跟下来，我对项目整体的测试工作的开展也有了更宏观的认识。项目上线前比较忙忙，趁现在项目上线后还没那么忙的时候，反思一下项目测试过程中那些做得不太好的地方，在以后的工作中能有针对性地做一些改进，做得更好。
1、项目排期时的时间预估能力欠佳
记得刚开始进行项目排期的时候，其中一个模块我是这样排期的：接口测试方案及用例设计2d，接口测试执行 1d，UI口测试方案及用例设计 1d，UI测试执行1d。六哥看了后说，你这个不太合理啊，预估的时间太短，不可能完成的。
但哪项工作到底需要安排几天我当时确实有点懵，然后六哥指导我重新排了个期。排完之后，这个模块重新排期后是这样的：接口测试方案及用例设计2d，接口测试执行 3d，UI口测试方案及用例设计 2d，UI测试执行3d。
当时我内心的想法是这样的：这时间排得有点多啊，到时候万一时间用不完正好多了一些学习的时间~~~然而实践证明，我想错了。在真正开始项目测试才发现，时间看起来安排得宽裕却常常不够用，工作过程中总是会遇到各种各样的问题需要花时间去解决。
有一次项目时间赶，周末过来加班，遇到了我们测试小团队的负责人策策，然后我们发生了下面的对话：
他问我，怎么周末还来加班” />
我感觉，对项目合理排期及把控时间也是一种个人能力的体现，从拆解任务点到合理预估每个子任务点需要花费的时长，这其中还包括了对可能出现的问题的预估。而这项能力的培养依赖于以前的一些项目经验以及及对踩过的一些坑的总结反思。
在以后的项目中，要结合实际的项目经验，在时间预估过多和过少的时候多进行一些思考，提升自己这方面的能力。
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为什么要搭集群啊” />
以后有新项目需要搭redis的话，我想我会这样做：搭1主1哨兵结构，或者跟开发商量下代码中能否支持只有一个master的情况，这样测试环境直只需要搭一个master就可以了，这样可以节省很多时间。
总结
写到这里，之前计划的一些点都基本写完了，但跟写总结之前在一些想法上也发生了一些变化。写总结之前是想分析分析做过了哪些无效的工作，走了哪些弯路，但真正挖下去，发现其实并没有绝对无效的工作。每个人都会走弯路，特别是在工作年限比较短的时候，走得弯路更多。但是如果在感觉不对劲的时候能够及时总结反思，那么走这些弯路吸取的经验和教训，都能够成为自己的宝贵经验，让以后的路能走得更顺利。而且自己经常是抱着学习的心态去尝试一些工作，这本身就是一个学习的过程，而学习本没有捷径，都是一个循序渐进的过程，通过一次次遇到问题、分析问题，解决问题的过程，不断挖掘，才会对所做的事情有更深的理解。
记得上次我去找小团队的测试负责人策策聊下关于在项目中的实践、学习以及自己的输出的时候，他提醒了我一点，对我很有帮助。他说，学东西要有个目标，自己定一些标准，要能量化地评估学习的成果，怎么样算是学得很好，怎么样算是一般。自己之前也有思考过要评估学习的效果，但一般都只是把学习及遇到的问题记录成文档，但感觉这样在深度上还远远不够。就拿redis来说，搭redis的集群的过程我都记录成了文档，但对于redis内部主从切换及哨兵的机制还不太熟悉。从我自身经验来看，在新学一项技术的时候可能还不具备自我评估的能力，我觉得可以去请教一下擅长这项技术的同事，让他们问自己几个核心的问题，带着这些问题，可以学习得更深入一些。
写这篇总结花的时间比我之前预估的要长很多，思考的深度也更深了一些。但写总结确实是一个很好的自我梳理和提升的过程。自我感觉在日常工作中思考得不够多，特别是一忙的时候，就光顾着干活而懒得跳出来多思考思考。以后的工作中，要通过定期写总结的方式来反思和总结近段时间的得失，做到清晰地思考和高效地行动。
补充
这是一份216页软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享！，其中包括了有基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。
结语
最后再唠唠一句，如果想以测试为长期发展职业目标，是需要时刻保持学习的，要使自己具备竞争力，无论你现在工作几年，只要行动起来，你就已经占优势了，好啦就到这里了，祝大家2022年能升职加薪，没入职的就早日拿到心仪公司的offer，事事顺遂。