这是一个残酷的世界，无论我们多么努力，结果可能还是不如意。这一点，软件人深有体会，不管我们多么认真地编码，多么仔细地测试，仍然无法抵挡Bug顽强地冒出来。
如果Bug被发布出去了，谁将为此背锅负责？
谁失职谁负责! --开发说
测试团队的职责就是测试，保证软件产品质量，如果产品的bug没有被及时发现，给用户造成了损失，这就是测试工作没有做到位，理应为结果负责。
Bug是我写的吗? --测试问
测试角色的职责是测试，但是软件产品的设计实现并不是由测试团队负责的，Bug的出现，最根本的原因是软件本身的设计和实现出了问题，测试不应该为此负主要责任。
如果丢球就是守门员的错，那么， 奥利弗-卡恩以门将身份获得2002年世界杯金球奖，是因为他没有丢过球吗？！
如果我的代码没有Bug，那要测试做什么呢? --开发问。
我们总是对自己做的东西有着迷之自信，但是，人总有考虑不周的时候，有犯错的时候，有脑子进水的时候，我们深知这一点，所以，才需要专门的测试角色，以独立的眼光审视和检查，发现我们没有察觉的问题。
我们是最后一环，不是唯一一环 --测试说。
正如开发过程会出Bug，测试过程也会出”Bug“。测试工作中的”Bug“之一，就是未能及时发现软件产品的Bug，使产品缺陷直接影响到了用户。
软件研发是一个系统工程，大家的职责分工有侧重点，但是参与其中的每一个角色都应该为项目负责。守门员无疑是把守球门的最后一道闸，但在最后的防线之前，还有10人！如果前锋软脚蟹，中场闲庭信步，后腰用目光防守，在球门线上供上布冯也无济于事啊。
测试不就是鼠标点点点嘛，这也做不好? --开发说。
开发是软件研发的核心团队，是真正实现客户需求的力量，我们开发人员要懂编程语言，懂面向对象，懂前端后端，懂消息队列，懂数据库，懂业务逻辑，懂颈椎病的防治。。。你们测试只要用鼠标在UI上点点点就可以了，这么简单的事情也做不好？
雷声阵阵，大战在即。双方都充满怨气，这么聊下去，免不了刀光剑影。这是在现实中经常出现的情况，对此，我想对测试团队给出几点建议。
1
怼回！
如果说测试的工作就是用鼠标点点点，开发的工作不也就是用键盘敲敲敲嘛，你们自己也是一身绿毛，有什么资格说我是妖怪？
所以，更重要的，是到底用键盘敲下了什么，用鼠标点击验证了什么。大家都可以往纸上涂墨，但不是所有人都是书法家。
2
反思！
但是，我们必须清醒地认识到，怼回去只是为了不堵心，逞口舌之快并不能解决问题。
凭心而论，开发的工作比测试更重要，这是事实。我见过很多中小软件公司没有专职的测试职位，但是我还没有见过哪家开发的工作是其他角色兼任的。事实上，很多测试工程师确实技术水平不够高，这让测试工作的质量和效率徘徊在一个低位水平，也让测试在与开发的冲突中屡处下风，相当被动。
所以，测试工程师需要拿出行动来，改变这种局面。
3
行动！
身为测试工程师，我们先扪心自问：我们做测试，是因为技术水平不如开发，做不了开发工作，只能做测试么？
不得不承认，很多情况下是这样的！虽然也有很多情况是个人选择，守城的并不一定弱，也可以是因为愿意守城、擅长守城，
但是，即使最开始是因为“被选择”做的测试工作，开始了鼠标“点点点”的软件测试职业生涯，我们也应该着力突破，除了提高测试设计等能力之外，我们还应该尝试学习自动化测试。
理由非常简单：软件是用代码来解决现实世界的问题，作为软件从业人员，我们用代码来解决自己工作中的问题，不是自然而然的思路吗？作为先锋队，开发已经拿着代码的加特林在突突突了，作为后防，测试还拿着木棒守城？
是时候了，扔掉木棒捡起枪，从这本书开始！
这本书，是关于软件自动化测试，但是它不会直接给出“正确”的终极解决方案(我自己也没有)，而是演示如何从基础出发，发现问题，探索方向，解决问题，迭代和改进方案，重点在“渔”，而不在“鱼”。这是软件测试的应有思路。
本书的内容按难易程度组织成入门、进阶和高阶三个层级，内容设计前后衔接，互相呼应，读者可以清晰地看到细节打磨的过程。不同技术水平的读者，都可以在相应的层级看到精心设计的内容和范例，可行的工程实践，以及上升到更高层级需要的技能和思考方向。
戳这里，买一本码农徐西宁的新书：
《软件自动化测试实战解析-基于Python3编程语言》
友情提示：出版社特别提供了额外的粉丝限时福利（2021年8月有效），有更多优惠哦：
* 本书的范例代码提供免费下载, 请关注公众号，发送消息“代码”，即可得到下载地址 *
