前言

为何写作本书

我们曾经思考过这样一个问题，如何才能将自己积累的技术和知识进行抽象总结，将逐步解决问题的过程立体化、可视化地展现给大家，而不只是简单地介绍一个结果。我们技术团队之所以决定写这本书，就是希望通过介绍我们的实战经验和解决问题的思路，帮助大家在“质量与效率”的提升上打开新的思路。

“质量与效率”一直是我们关注的焦点。相对于软件开发，软件测试起步较晚，缺乏拥有专业知识的人才。即便是大学开设的软件工程专业，针对软件测试的介绍也只是涉及少量的概念和设计测试用例的方法。专业的测试并不是简单地翻译需求。目前有很多测试人员只是在简单地执行需求翻译的工作，没有结合业务实现、质量模型和测试用例，没有用科学的方法设计测试场景，这就导致测试用例质量低下，只能应用于单个特定点的测试场景。

有些人认为功能测试很低端（从效率、技术含量和市场反馈的价值综合得出如此结论），甚至有相当一部分测试人员也认为，功能测试意义不大，希望从事测试工具的开发工作，因为那样看上去更高端，更具有挑战性。

其实，功能测试、自动化测试、性能测试、安全测试、测试框架开发、平台研发等工作都是为了提高软件测试的质量，没有高低贵贱之分，都是必要的辅助手段。可以将软件测试类比为一个兵团，上述这些工作是不同的兵种，在面对一场战役的时候，我们需要考虑的是如何排兵布阵，以赢得战役，而不是排列兵种的等级。

不同的时代对测试人员有不同的要求。

起初是“保姆时代”，以发现Bug为荣，对测试人员的基本要求是具备良好的测试思维，测试人员主要利用系统测试方法进行测试。业内关注的焦点是黑盒测试，白盒测试和灰盒测试偏少，效率偏低。由于黑盒测试大部分是通过人工在系统界面中手动进行的，从而导致业界普遍认为测试就是“点点点”。

随着软件复杂度的不断提高，交付质量变得越来越重要，我们急需提升测试的效率，压力测试和安全测试等各种专项测试以及各种测试平台和工具随之出现。

时代的进一步发展对测试提出了更高的要求，从产品研发后期寻找Bug转变为提前预防Bug。

小步迭代、快速上线的敏捷开发时代，再次对测试提出了更高的要求，持续集成、快速验证、全方位监控线上质量，需要测试人员更早地介入产品研发的整个过程，以便更好、更全面地了解产品。测试左移到开发阶段进行代码评审、单元测试，右移到运维阶段进行持续部署、线上监控，从而可以更加立体地保障软件的质量。

如今是一个输出测试能力的时代，测试人员不仅要提升自己的效率，而且要赋能研发人员，帮助他们提升自己的自测水平。