想起初入公司那一会，面试都紧张的不行，提前一个小时到公司楼下踱步，超紧张。一进入公司人事就让同事带我去熟悉项目去了，那时候贼忐忑，毕竟自己都只有理论经验，实战经验太少了，当天回到宿舍就马上打开项目网站在那研究，熟悉业务。由于公司就我一个测试，当时可真是迷茫，只能自己在哪点点点，没人给自己安排活，硬着头皮上，做开路先锋
一直做黑盒测试，从开始写个测试用例都手忙脚乱到现在摸索出自己的工作方式：接触项目，有需求文档就要来需求文档，分析构思如何测试，测试用例的编写，用例执行以及用例补充完善，bug追踪，回归，测试报告以及相关测试文档提交
一整套流程下来，之后在去测试新的项目你就不会慌了
我亢奋的走入测试行业，总想测试到完美，却也会听到：小项目来的，没必要
总结测试上班的处事原则：和客户聊天一定是报喜不报忧，报忧也是无关紧要的忧。和开发沟通耐心点，不要针锋相对，毕竟闹掰了对谁都不好。和老板喝茶一定要废话少说，不要抱怨太多，实在是需要帮助在跟老总说
废话说完，测试思想送给大家
1、测试工作切忌上手就开测，一定要好好的了解项目背景以及相关需求，不明白一定要问清楚，这样你可以很好的掌控测试的力度和大方向；
2、测试计划方案制定之前，最重要的是确定测试范围和测试标准。以需求为标准，切忌测试人员以开发设计的功能为标准
3、测试计划和方案制定的时候有必要和开发负责人、项目经理了解一下目前项目的项目计划和真实进度，以此为依据制定一下测试计划；
4、尽力去了解整个系统，空闲的时候可以好好想想项目的功能交互，各功能之间会不会出现反人类的“骚”操作，这样的“骚”操作往往是bug出现的地方
5、编写测试用例框架，从整体梳理一下测试思路，数据、业务规则、UI或者拆分模块、或者先接口后功能再集成最后场景，随机应变吧。骨架搭好了，就需要对应需求了。
6、测试的一切工作的基础不是需求文档，而是你的测试用例，所以一定要将需求和项目的一切变动都实时的更新转化到你的测试用例里面，为了避免成为背锅侠，所以此时的测试用例是你工作的底气也是你的工作成果，你懂的；
7、测试软件过程中，忌讳一遇到问题就马上找开发，测试的工作时间是碎片化的，但是开发的工作时间一定不能是碎片的，否则开发会疯的；对于测试进行不下去的bug你可以实时找开发外，其他的比较重要的你要收集好一起反馈给开发
8、测试初期是bug急剧增加的时期，测试工作也是阻碍重重，不要抱怨，把问题好好整理一下，好多问题都是其中某一个引起的连锁问题，一个解决，其他的都不存在了，所以切忌不要再错误的流程下再进行操作，导致你提了10多个bug,发现只要解决一个问题，其他问题就会消失，所以切忌不要这样去加大自己的工作量，也不用让开发觉得你提的bug质量都好差，所以尝试去找到那个关键问题，让开发干掉它；
中期bug的增量和修复量就平稳了，也是最累的时候，一定要坚持住；
后期的bug如果出现平稳下滑，那么恭喜你，测试的质量不错；如果急速下滑，要谨慎遗漏和修复引起的新问题；如果还在急剧增加，赶紧看看是需求变更了还是数据库或者版本管理出现问题了。
9、测试结束，上线了，根据2/8原则，客观分析系统质量，以及风险，待优化和注意的点。