测试+开发 ？= 不可调和的矛盾

　　在好的项目组中，和谐的测试和开发犹如一对好的矛和盾，相互制约又相互协调，在求职面试时，经常会遇到一个相同的问题，在测试项目或者产品的过程如何协调与开发人员的关系，即如何处理工作性质所带来的开发和测试的矛盾。刚涉足测试时，我不能很好的体会到这种矛盾，只能浅层的想象测试是挑开发的毛病，开发当然也不乐意老让人挑毛病，所以就有了矛盾。之后翻阅一些书籍，里面谈到测试和开发的协调需要上升到一定的高度，即“双赢”，就是大家共同的目标是一致的，就是维护好整个项目让客户打到最佳满意度，这样会这很大程度上避免一些“冲突”，实现工作中的双赢，理论上这是个很好很和谐的概念，这样回答面试官不加分也不至于扣分。

　　但是在实际操作中，很多现实因素会制约这种思想，比如其一：大家为了减少项目出错的风险，卯足了劲去查bug，免不了有钻牛角尖的情况发生，再要是同时开发人员会将bug的数量作为其考核的标准，那么测试和开发之间的“硝烟”是终日挥散不去的。其二：测试和开发获取的信息的不平等抑或不一致，由于开发人员在整个项目开发过程中获取的需求信息，需求变得信息，项目流程信息等比测试人员更广泛或者时间上更快捷，导致与最终测试人员的思想不一致而产生一些错报或者漏报的bug，倘若再加上沟通不善，会对整个项目进度和流程产生很大的影响；信息不一致则是开发和测试在理解需求上产生分歧，从需求阶段就产生矛盾势必会满意至编码阶段和测试阶段，解决这样的矛盾的结果就是拖延项目的进度。

　　测试如矛，开发如盾，在初期，矛若知道盾之强弱，便可及时修补其弱点，那么这就首先要求开发和测试从项目出去就需要保持一个一致的状态，无论从需求信息，需求变更信息，风险信息，技术瓶颈信息，项目难度信息，都需要保持同等及时的认知，这就需要测试和开发人员相互沟通得当及时。其次在处理bug的问题上，好习惯的测试人员会在开发之前撰写case阶段就根据自身经验预测开发人员容易忽视的逻辑从而预先告知防止错漏的发生。其三，对于bug的分析和争议，测试人员应该多从用户的可重现性，bug的风险性，解决bug所需要的时间和价值性价比等方面共同商榷，最后定夺一个处理bug的最佳方案，一个被提出的bug也并非只有解决，不解决和无效者几种状态，可以根据整个项目的情况来定夺它，目前不解决也不一定是永远都不解决，最重要的是它对产品的影响力和投入的估计要得当适合，才能查出一个高性价比的产品，最终获得收益的最大化，同时开发和测试也获得了双赢的局面。

　　以子之矛，攻子之盾，在古代或许是绝对的对立，但是对于测试和开发谁说一支好的矛一定要攻破盾，一支好的盾一定抵御得了任何矛，好的矛与好的盾，不断的磨合和进步，终有一天会默契得强过任何矛盾，所向披靡。

　　我的测试 == 痛&&快乐

　　我的第一份实习工作是在一个外企做黑盒WEBGUI测试。刚刚进入软件测试的我那个时候对软件测试也一无所知，甚至一开始我的职位都是：测试执行人员。跟我一起奋斗的同伴们，每天都在不断的自我抱怨中拿着那些别人写好的测试用例，一遍一遍在同一个页面上重复的点击某个按钮。大家都似乎认同一个道理：这就算测试？运行自己写或者别人写的case，机械的像在碰运气一样的去寻找或许存在的bug。

　　我曾在心里质疑过自己的选择，但是我最终还是觉得，即便是在这样的环境里面，我能学到应该不止这些。我能做的应该也不止这样，否则我的路在哪里？人无法预料未来，只能把握现在。如果你想未来能走得更远，更宽，那么今天就一定要努力。这也是我当时想的，并且努力去做的。其实喜欢与否，有的时候也在于你是否有兴趣去探求，去思考和了解这个行业里面的浮在表面之外那些东西。不了解，就很难喜欢，不喜欢，又有什么机会会因为兴趣而去努力呢？或许，世界本来就是不公平的，在某些人的眼中，看别人潇洒的谈笑，自己却要如此艰涩的生活着；或许，世界本来就是公平的，你善待了你的生命，虔诚的为了自己的理想去努力，即使不能硕果累累，取得的成绩可圈可点，对于我的人生，痛并快乐着，这就已经足够。