测试工作当中的坑，总是填着填着就成了神！

Time will tell.

之前一直在外包企业做电商的测试，从接触项目到结束项目，真心累，却觉得自己成长了很多。初入测试，都是在等着测试组长或者经理安排需求点，然后自己在那吭哧吭哧的点点点。或者压根没有人安排活，只能自己硬着头皮上，没有前辈的脚印，自己就是先锋。

工作

一直做黑盒测试，从开始的手忙脚乱，到慢慢形成了自己的一套工作程序：项目接触，需求搜集、分析，测试计划，方案编写制定，测试用例框架搭建、用例编写、用例评审，用例执行以及完善订正，bug追踪、回归，测试报告提交。

一整套流程下来后，之后再接项目就不会那么慌乱了，心里有底了，以上是软件测试流程。项目接洽，报价、竞标，做需求，设计数据库，分配模块进行分期开发，测试介入测试，代码冻结，客户验收，项目上线，ab、性能、安全测试。

这是整个项目的大流程，可能由于项目的类别，流程顺序上可能有点不同。

在我的经历中，最让我纠结的是让开发改bug、让客户砍需求、让甲方验货、收钱；我亢奋的走入测试行业，力求精益求精，但是经常听到：差不多就行了，没必要这么干 . . .

让我一再地迷茫，我要不要坚持己见；或者我就不管了，反正你们觉得可以就行，然后把一个怪胎不负责的扔给他们，这就是你们要的，不能怪我喽，哎，当时可是把我纠结死了，终究是too young啊！

来点分享

和客户聊天永远报喜不报忧，和开发沟通永远不要针锋相对，和老总喝茶一定废话少说。以上废话完了，来点水货：

1、测试工作切忌上手就开测，一定要好好的了解一下项目的背景，这样你可以很好的掌控测试的力度和大方向；

2、测试计划方案制定之前，最重要的是确定测试范围和标准以及问题确认的对接人，范围边界一定要非常非常的清楚，切忌模糊，否则后面等着吐血吧；

3、测试计划和方案制定的时候有必要和开发负责人、项目经理了解一下目前项目的项目计划和真实进度，以此为依据制定一下测试计划；

4、尽力去了解整个系统，可能此时连UI页面都没有，你可以参考一下类似的系统或者网站，脑补一下系统整体流程以及相关系统之间的联系交互；

5、第4点差不多了，就开始写测试用例框架，用例不用写的很细，从整体梳理一下测试思路，数据、业务规则、UI或者拆分模块、或者先接口后功能再集成最后场景，随机应变吧。骨架搭好了，就可以和需求一个字一个字的扣了。

6、此时应该是属于需求再次确认的阶段了，在写用例的时候发现的需求疑问应该是最多的，要是维护一个需求确认清单，绝对会让你事半功倍的；

7、测试的一切工作的基础不是需求文档，而是你的测试用例，所以一定要将需求和项目的一切变动都实时的更新转化到你的测试用例里面，后续可能会出现很多扯皮的事情，所以此时的测试用例是你工作的底气，你懂的；

8、测试软件过程中，忌讳一遇到问题就马上找开发，测试的工作时间是碎片化的，但是开发的工作时间一定不能是碎片的，否则开发会疯的；对于何时去找开发处理问题，那要看你发现的问题属于什么，如果是页面样式错位了，手机号长度没有限制这些，那就先缓缓吧，不急于一时的；如果是阻断测试流程了，给开发先发个信息，说明问题修复的优先级，等5分钟，喝口水，如果开发没有及时回复，口头沟通一下（让尽快暂停手头活，优先修复一下问题），这样会好一些；

9、测试初期是bug急剧增加的时期，测试工作也是阻碍重重，不要抱怨，把问题好好整理一下，好多问题都是其中某一个引起的连锁问题，一个解决，其他的都不存在了，所以尝试去找到那个关键问题，让开发干掉它；中期bug的增量和修复量就平稳了，也是最累的时候，一定要坚持住；后期的bug如果出现平稳下滑，那么恭喜你，测试的质量不错；如果急速下滑，要谨慎遗漏和修复引起的新问题；如果还在急剧增加，赶紧看看是需求变更了还是数据库或者版本管理出现问题了，这种情况基本不用考虑准时上线了；

10、测试结束，上线了，根据2/8原则，客观分析系统质量，以及风险，待优化和注意的点，这样在团队下期项目开始后，会轻松很多的，其实此时是体现测试最大价值的地方，但是绝大时候都没人关注此时的软件测试报告（悲伤）。

絮叨

以上就是今天跟大家的一点分享，希望看过本篇文章之后，让正在做测试和准备做测试的小伙伴们对自己今后的工作方向有点了解，如果你喜欢软件测试这个行业的话，可以加入我们175317069一起学习，群有行业深潜多年的测试人技术分析讲解。最后祝愿你能成为一名优秀的软件测试工程师。

喜欢的话，欢迎【评论】、【点赞】、【关注】礼貌三连

Time will tell.（时间会证明一切）