0 前言
我们生活在一个软件无处不在的时代。在这一点上，软件是不可避免的。其中有些软件微不足道，只是为了娱乐或打发时间，而有些软件则是最关键的任务，能够维持人的生死之间的微妙平衡。我们将接触到的大多数软件都属于这一连续统一体的某一部分。它可能出现在网络上、手机上、手表上，或者测量我们运动时水瓶的重量，提醒我们在重要时刻补充水分。即使我们没有直接与之互动，软件也在我们生活中的许多领域运行着，我们甚至没有考虑到这些领域，包括我们的金融机构、发电厂、医疗成像系统，或者在不断进行试验，以找到合成化学反应或对抗致命病毒的最佳方法。
所有这些软件交互领域的共同点是什么？必须有人来创建和部署它们，但也许最重要的是，必须有人来测试它们。在过去的几十年里，"有人"已经成为一种趋势，而更多的是"有东西"，这意味着自动测试在某种程度上承担了所有的测试工作。当然，软件可以完成上千名测试人员的工作，不是吗？然而，在新闻媒体和一些备受关注的案例中，人们又开始意识到，也许，仅仅是也许，拥有真正了解测试的人是重要的、必要的，而且应该准备好从事这项工作。做测试工作的人不需要有"测试员"的头衔。他们可以是软件开发人员，也可以是从事激情项目的业余爱好者，还可以是在服务器群中运行系统、确保系统可运行和人们能够访问系统的人员。在整个软件开发生命周期中，测试发生在多个层面。
在最基本的层面上，测试是在科学方法中进行的实际实验。它是提出"如果......会怎样"的问题。这是对软件进行偷偷摸摸的***难的乐趣所在，试图找到软件容易受到攻击的地方，进行测试的人可以在这些地方支持或反驳手头的想法。软件是否适合使用，还是存在问题？
我们编写这本《软件测试技术》的目的，就是要帮助您--我们尊敬的读者--掌握软件测试的乐趣和冒险精神（是的，软件测试当然会很有趣，而且往往就是一场冒险）。我们希望为您提供软件测试的技能、流程和技巧，或许还能为您提供一些新颖的方法。如果你觉得这听起来很有趣，那就加入我们吧。
本书电子版本可V或ding钉 pythontesting 一瓶酒钱获取，谢谢！
0.1 超越点点点
加尔文学院教授帕特里克-贝利（Patrick Bailey）曾做过一份研究报告，他问人们他们的角色是什么，如果他们只能做一种形式的测试，那会是什么？贝利惊人地发现，人们倾向于将最有价值的测试与其角色联系起来。程序员认为单元测试有价值，内部客户认为用户验收测试有价值，业务分析师认为系统测试有价值，等等。
例如，项目经理往往将工作视为流水线。任何以"计划工作，工作计划"为口号并有文档偏好的人都会喜欢把测试写下来然后执行的想法。当我们看到这样的尝试时，坦率地说，结果的价值较低。因此，公司会批评那些按按钮的人，甚至嘲笑他们。我们创造了糟糕的测试人员，然后惩罚他们。
这可能是第一个错误，也是过去最常见的错误。如今，我们看到一些人看到了第一个错误，知道这是愚蠢的，并把所有的人类测试都看作是那种低价值、照本宣科的练习。这部分人将测试视为其他东西--图形用户界面自动化、低级单元检查，或许还有 API测试。所有这些在本书中都有其作用和地位，但它们也未能捕捉到良好测试中的即兴元素。我们将在第1章的图形用户界面层面介绍探索测试。
换句话说，本书并不局限于点点点，而是在整个过程中，在熟练人员手中发生的一些事情，需要在各个层面加以研究和应用。
我们这本书的范围是通过演练代码来快速了解软件状态的所有方法。我们首先承认，这并不是软件质量的全貌。它不包括如何创建良好的需求，也不包括如何执行代码检查或配对程序。我们将测试视为一种反馈机制，但它并不是唯一的反馈机制。
我们认为，"只是测试"对于一本书来说绰绰有余。反馈非常重要。它常常被忽视，也常常做得不好。本书的第二部分涉及将测试整合到交付流程中。第三部分涉及"政治实践"，即如何提供能被组织有效利用的反馈。
如果你曾经听到过"我们为什么不测试那个"、"我们为什么不发现那个错误"，或者最糟糕的是，"好吧，你发现了那个错误，并将其列为必须修复的优先事项，我们坚持认为可以推迟，但你为什么不更有效地宣传呢"，那么这本书就是为你准备的。这本书也适合你，如果：
- 如果你总是在软件中看到一些看似显而易见的错误，而你却希望其他人能发现这些错误。
- 如果你想更好地快速查找信息并很好地表达信息，从而改变过程的结果。
- 如果您希望想出办法，利用您发现的信息来降低漏洞注入率。
- 如果您希望能够诊断并解释您是如何进行关键的风险/回报权衡的。
希望你现在已经意识到，测试是一项严肃、成熟的风险管理工作。任何初学者都能遵循流程，任何中级测试人员都能让大多数软件团队陷入等待修复的拖延之中。测试的真正价值不在于此，而在于做出明智的风险/回报决策，将有限的资源投入到风险管理中。
您可以将其视为三个层次的测试。第一层，以最简单的方式使用应用程序。这是"快乐之路"。第二个层次的测试人员正在寻找漏洞。这种测试人员认为自己的工作就是发现错误，或者正如有人说的那样，在"让开发人员哭泣"的同时"高兴得咯咯直笑"。第一个层次的人可能会过于赞同，而第二个层次的人则可能会对开发产生敌意。在第三个层面上，我们要考虑在哪些风险上投入多少时间，以便在质量上"不被愚弄"，同时尽量不影响交付速度。在某些情况下，及早发现产品问题可以提高交付速度。
0.2 什么是测试？
在不久前或很久之前，作者之一马修还是西密歇根州一家健康保险公司的测试主管。该保险公司与当地一家全国知名的咨询公司签订了合同，让其参与一些软件维护工作。其中一位顾问是一位出色的编码员，他沮丧地推开键盘，大喊："这完全无法测试！"
马特拿起键盘和鼠标，开始操作软件，说："当然可以，看着吧！" 紧接着他又说："哦，你不是说代码无法测试，你是说你没有办法让计算机通过预定义的练习来运行它并检查结果。你的意思是说它不能......也许不能自动测试？
这是帕特-贝利（Pat Bailey）在加尔文大学的研究中所谈到的另一个例子。对于程序员来说，"测试"就是检查功能的自动化代码。而对于保险公司的员工马特来说，测试就是找出软件信息的过程。
几乎就在这个故事发生的同时，我们的导师之一 Cem Kaner 博士正在发表题为 "测试是一门社会科学 "的演讲 (https://kaner.com/pdfs/KanerSocialScienceTASSQ.pdf)。在演讲中，Kaner 博士是这样定义软件测试的。
软件测试是
- 一项技术调查
- 为提供与质量相关的信息而进行的
- 关于软件产品
- 给利益相关者
本书倾向于使用这一定义。测试就是找出你所构建的东西是否真的能完成你要求它做的事情。虽然你可以用进度表、糟糕的设计和不起作用的代码来欺骗自己，但测试是确保我们不被愚弄的第一个过程。Kaner接着说："许多最重要的测试工作看起来更像是应用心理学、经济学、商业管理（等），而不是编程"。
这可能会让很多程序员不高兴，也许也会让一些DevOps人员不高兴。毕竟，2020年代测试工作的圣杯就是实现所有检查工作的自动化。一般来说，这意味着快速运行所有检查，并自动报告结果，无需人工参与，简称 NHI（No Humans Involved）。
我们并不是反对自动化或工具化。我们的问题是缺乏如何做好测试的信息。
- 给定一个测试框架（或练习）...
- 我们应该先运行（或编写）什么测试？
- 测试结果会告诉我们什么？
- 何时停止？
- 当我们停止时，我们知道了什么？
这听起来像是一个互动练习，第一次测试的结果为第二次测试提供了参考。我们可以从该练习中选择一些子集，将其转化为算法，写成代码，然后例行运行，看看今天的结果明天是否会有不同。有人称之为回归测试。甚至还可以在代码之前创建自动检查，有时称为测试驱动开发（TDD Test Driven Development）。即使测试是自动化的，我们更感兴趣的还是找出运行什么以及运行结果如何的过程。
有些人将制度化的、随时运行的代码与反馈驱动的探索过程区分开来。其中，迈克尔-博尔顿（Michael Bolton）使用"检查"一词来指不假思索的算法比较，而"测试"则指通常包括检查在内的更广泛的活动。我们认为这很有帮助，因为 "自动测试"失去了我们之前看到的 Kaner 博士定义中的一些味道。
你读完这本书后，你应该能够审视一个用户界面或应用程序接口，找出许多不同的测试方法，并有工具来分割你有限的时间，以决定在哪些测试方法上花多少时间，向别人描述这些方法。
这本书讲述的是我们（马修-豪瑟和迈克尔-拉森）的故事。书中包括我们如何进行测试、为什么要测试、是什么影响了我们对测试的思考，以及为您准备的一些练习。为此，我们不得不做一些非常规的事情，比如在我、你、我们、马特和迈克尔之间变换 "人称"。我们必须写下你可能不同意的观点，以及可能与你无关的经历。我们面临的最大挑战之一就是如何删减内容，了解哪些内容对读者最有价值。在进行了数百次播客访谈、广泛咨询和参加了百余次会议之后，我们认为自己对这些内容有了一定的了解。然而，一本书能让我们获得更广泛的潜在读者反馈。我们期待听到读者您的意见，告诉我们哪些地方可以措辞更谨慎，哪些地方应该增减或修改。
参考资料
- 软件测试精品书籍文档下载持续更新 https://github.com/china-testing/python-testing-examples 请点赞，谢谢！
- 本文涉及的python测试开发库 谢谢点赞！ https://github.com/china-testing/python_cn_resouce
- python精品书籍下载 https://github.com/china-testing/python_cn_resouce/blob/main/python_good_books.md
- Linux精品书籍下载 https://www.cnblogs.com/testing-/p/17438558.html
0.3 本书的读者对象
本书适用于任何希望了解软件测试过程和思维方式的人，也适用于希望将有助于更好地测试和理解系统的想法和方法付诸实践的人，还适用于希望在软件开发过程中为那些不能为自己代言的人代言的人。请注意，这并不预设阅读本书的人是一名专门的软件测试人员。我们鼓励每一个参与软件开发的人，包括程序员、产品和项目经理、业务分析师、系统管理员，以及任何对其组织所创建的软件有切身利益的人，尽可能提高自己的能力和稳健性。
0.4 本书内容
第1章，测试和设计测试，这一章介绍了作为风险管理活动的测试，重点是重要软件部分的强大测试思想。它讨论了错误理论、无脚本测试以及包括模型驱动测试和浸泡测试在内的各种方法。
第2章"工具和自动化中的基本问题"讨论了测试自动化中的常见误区，并分享了多年的经验。该章涵盖了雷区回归问题和战舰问题等概念，最后提出了解决这些自动化难题的方法。
第3章"面向程序员的测试"侧重于开发人员测试，涵盖单元测试、测试驱动开发和网络API测试等主题。最后以Python为例，介绍了创建单元测试的实践练习。
第4章"面向客户的测试"探讨了面向客户的自动化测试的细微差别，讨论了图形用户界面自动化模式、示例规范和低代码/无代码工具，旨在帮助读者分析和优化用户界面测试。
第5章"专业测试"深入探讨了测试的专业领域，包括性能和负载测试、安全性、可访问性、国际化和规范测试，每个领域都有其独特的挑战和方法。
第6章"测试相关技能"扩展到测试设计和执行之外，重点介绍识别错误、沟通问题、计划和记录工作、度量以及影响测试流程变化等技能。
第7章"测试数据管理"探讨测试数据管理问题，并提供创建、存储、编辑、删除和恢复数据状态的技术，以推动高效的应用测试和可靠的测试工具。
第8章"交付模式与测试"拓宽了测试与瀑布式、Scrum和DevOps等软件交付模式的互动范围。本章将帮助读者理解并优化测试与这些模式之间的互动。
第9章"良好测试的拼图"分解了测试的各个组成部分，如配方、覆盖率和缺陷，并鼓励读者根据自己的需求将这些元素重新组合成一个有凝聚力的测试策略。
第10章"整合你的测试策略"在前一章的基础上，指导读者分析当前的测试状态、确定风险的优先级，以及沟通和实施全面的测试策略。
第11章"精益软件测试"介绍了精益软件测试，并结合了测试和运营管理技术。它涵盖了七种浪费、流程、限制以及精益度量和测量方法等主题。
第12章案例研究和经验报告，使用案例研究和经验报告，提供来自实际领域的真实经验教训和策略，为测试挑战和解决方案提供实用见解。
第13章"测试活动还是测试角色？"探讨了谁应该执行测试活动的细微差别，讨论了文化冲突、风险缓解团队以及各种测试模式（如左移和持续测试）。
第14章"软件测试的哲学和伦理"探讨了测试的哲学和伦理层面。本章探讨了测试的局限性、道德推理的价值以及测试过程中清晰沟通的重要性。
第15章"关于工作的言语和语言"侧重于沟通，强调测试中准确语言和语境的重要性，探讨不同的测试流派以及过程和技能之间的区别。
第16章"测试策略应用"将本书的概念应用到实际场景中，包括移动测试策略的参考实施和软件测试中人工智能的批判性研究，为测试策略应用提供了一个全面的视角。