“开发最看不起测试？”

工作不被认可，自我价值得不到体现，面对枯燥重复性地工作，让一些测试人员开始怀疑自己的选择，甚至有些人选择转行。

鄙视链无处不在，测试人员如何翻身做主，成为一名在开发团队有话语权的人？从最基础但又最重要的功能测试说一说影响这种看法的几个关键点：

任务质量的高低：全面细致的测试，高质量的上线，是测试人员最重要的工作职责。开发最怕的是什么？线上问题。一旦系统出现线上问题，必然会影响领导对他能力的怀疑，影响他的绩效考核等。而如果任务经过测试人员测试，上线后，少有问题发生，便会增加开发人员对测试人员能力的认可和信任，之后的开发任务也会主动地交给测试人员，另一方面也是给开发自己减少风险。反之，经过测试人员的测试，线上问题仍不在少数，和开发自测没有太大的区别，那结果可想而知，可有可无嘛。所以如果你们公司需求不经过测试，开发就不敢上线（抛开流程限制的因素），那么恭喜你，开发已经认可测试的价值对测试人员产生了依赖。

系统业务逻辑的掌握：决定了测试的深度。业务掌握地越详细，测试点设计地越全面；需求评审的时候，测试人员积极思考新的需求对老业务产生的影响，是否合理，或许会发现产品经理设计出来的方案不符合当前业务或与老业务有逻辑冲突。当测试人员对产品业务了如指掌，以后在需求评审的时候，产品和开发会重视测试人员的意见，防止功能遗漏或者功能无法形成闭环等问题的发生。

问题的分析定位：快速准确定位和分析问题需要经验的积累。发现的问题越多，针对问题剖析的越透彻，越能丰富你的测试思维。在以后得工作中，类似的问题你就会关注，测试点的设计也会越来越完善。举个简单地例子，日期控件的测试（日期控件精确到日而不是秒），你也许会测试某个日期范围内能筛选出数据，而且这些数据在你的筛选条件内，那就证明日期筛选没问题。但也许有个细节你会忽略，当你想筛选2023-01-01这一天的数据，开始和结束日期如何选择呢?如果都选择2023-01-01，能筛选出这一天的数据吗？如果有，那么开发对这一块做了特殊处理。因为日期控件，时间默认是零点 00:00:00，即筛选条件2023-01-01 00:00:00 至2023-01-01 00:00:00范围内的数据，显然是不对的，无法满足当天数据的筛选需求。如果没有筛到数据，可以直接跟开发说，结束日期的时间是不是没有设置为23:59:59或筛选条件是不是精确到时间来判断而不是日期，开发就可以准确快速地定位问题并修复。这样以来，开发不仅感激你帮助他们减少排查问题的时间，同时也认识到测试人员的重要性。测试人员发现bug是工作职责，但测试人员对于奇怪的bug可以向开发了解一下产生的根本原因，是逻辑判断问题？sql语句问题？分支合并问题？等等。bug见多了，时间久了，排查问题的能力自然而然就提升了。

体验上的优化建议：测试不要小看这个问题，不要把用户体验当做是UI和产品经理的工作。用户体验也是测试人员在工作中需要关注的点。UI和产品更多地是出页面效果，而测试才是功能验收地第一批真正用户。作为一名合格地测试人员，你在工作中，更多地是站在真实用户的角度测试和使用软件，检查开发出来的功能是否易操作，功能介绍是否清晰易理解，是否有冗余步骤等而不是简单的验收功能。举个简单地例子，很多软件都有搜索功能，如果点击搜索按钮跳转到搜索页，但光标没有定位到搜索输入框，还需要用户二次点击搜索输入框才可以输入关键词，你感觉这样的体验是否友好呢？如果工作中，测试人员对产品有比较友好的建设性意见，在之后的工作中，产品和开发同样会重视测试人员的意见，甚至推动产品经理对之后的prd设计，更加地严谨。

工作态度：各行各业，对待工作都要积极认真负责。工作中，测试人员积极配合产品和开发确认业务逻辑或排查问题。如果遇到开发修改代码未经测试，直接上线，测试要主动向上级反馈。确保每次发版，测试人员对修改的代码都是经过充分测试并确认可发布。如果工作中，遇到时间冲突的任务，测试人员可以跟开发及项目经理说明实际情况，尽量协调时间错开上线，如果时间无法协调而且测试人力不足，应由测试人员评估能否开发自测上线，如果可以，测试人员列出测试点，开发参考测试点全面测试，上线后，测试人员在空闲地时候，及时验收，千万不要直接回绝，否则在以后类似的优化任务，开发可能会忽略测试直接上线，那么长此以往，测试也就不再重要。所以，对待工作中的问题，积极主动推动和反馈，让公司看见测试人员的态度，只要合理，必然会接受。

当然还有其他方面产生影响，比如与开发友好相处，工具的灵活应用，自动化性能脚本的设计等等。