一、感受到近来周围朋友的观点和思想似乎与我大相径庭，有时候我不禁开始怀疑自己，鼓起勇气，吐槽一下个人的观点吧！
　　1 有人对我说说：做测试的学代码干嘛，能看得懂可以了。
　　2 有人看到我在写代码: 问我是不是要跳槽做开发。
　　3 有人看到我在写代码: 问我是不是对代码特别感兴趣。
　　回答这些的时候真心感到一丝的无奈
　　我并不喜欢写代码，也没觉得写代码有多高端更是不想跳槽做开发。
　　我只是单纯的想做好测试工作，所谓的"知己知彼":
　　做测试的人应该要知道“被测系统“是怎么做出来的，应该是一个很正常的想法吧。
 

　　二、以下是我列举一下:掌握编码能体现的至少表面上能看到的方面吧
　　1 设计测试用例的针对性，全面性能有所提高
　　程序里的每一个if语句其实都是一个等价类case，每一个方法的入参和返回值都是边界值的case，
　　程序里的每一个分支路径，异常的捕获都是一个很好的流程CASE，弥补需求说明书上很难覆盖到的测试点
　　2 能够更好的与开发沟通
　　参加详细设计评审时能更好的融入到开发的角色中一起思考解决方案，并能从测试的角度来提出疑问与建议。
　　更加清晰的定位BUG所在的模块及影响范围，减少沟通时间，并加快开发的修复BUG的效率
　　3 挖掘到深层次BUG的几率增加
　　通常BUG的出现不是偶发的，基本都处于比较密集的状态分布着，但在平日的测试过程中往往浅层次的BUG被发现了而深层次的BUG被彻底掩盖
　　当测试人员有代码功底的时候，是会对某些BUG，某些模块较为敏感的，进而有几率挖掘到更深层次的BUG，
　　方法可以是选择与开发一起走查代码，或是追加测试用例都是能提高BUG挖掘的几率。
　　4 自身进步的速度加快
　　其他类型的编程语言或新技术学习时效率能够提高（算是LR，QTP这类的能提供录制回放功能的软件，如果到了更高层面的使用也是需要描述性编程的）
　　与开发的人员沟通时，获益的几率提高（新名词，新思想出现时不再陌生）
　　在测试的过程中提高自己的几率变高（会觉得某些实现做的很出色从而会去留心的看）
　　5 区分自己与业务人员的区别
　　测试人员不应该是只满足于熟悉业务，
　　这样很难体现出与业务人员的”区别“了。
 

　　三、总结
　　有些论坛上的确是有人在讨论测试人员到底需不需要掌握开发技能
　　我的看法:编码能力应该算是一个测试人员本职能力的体现吧，现在却被拿来讨论该不该掌握的技术，是不是不合适？
　　不过我有时也在想，如果让需求人员来做测试，以他们对于业务的专精程度是否能测的更好？这个问题抛给今后的我吧！