前言 用户购买产品的同时，也得容忍缺陷。 ——司各特·沃兹沃斯 任何使用过电脑的人都知道，软件从未达到过完美的状态。从最初的程序到如今的应用程序，软件开发的复杂性以及开发人员可能犯的错都是导致软件无法尽善尽美的原因。此外，随着硬件、操作系统、运行环境、驱动程序、平台和数据库等的不断变化，软件开发的难度进一步增加，成为全人类最令人称奇的专业领域之一。 然而，仅仅令人称奇是不够的。正如本书第1 章“软件质量”所指出的，人们需要高质量的软件。显然，保证质量并不只是软件测试人员的责任。软件应该以正确的方式构建，像可靠性、安全性、性能等问题，都应纳入系统设计阶段加以考虑，而非留到开发后期。 然而，一旦涉及理解软件缺陷的本质，测试人员总是站在最前线。如果没有测试人员发挥其洞察力、技术专长和应变能力，那么实现软件质量全面解决方案的希望将变得渺茫。 谈论软件质量的方法有很多，感兴趣的听众也有很多。本书主要面向软件测试人员，讨论了一种特殊类型的缺陷，我认为这类缺陷比其他缺陷更为关键：那些能够逃避所有检测手段并最终出现在已发布产品中的缺陷。 大部分软件产品都有缺陷。这些缺陷是如何引入的？为什么它们没有在代码评审、单元测试、静态分析或其他面向开发者的活动中被发现？为什么自动化测试未能发现它们？这些缺陷具有哪些特别之处，使它们能够逃过手工测试的检测？ 是否存在找出产品缺陷的最佳方法？ 本书讨论的正是最后一个问题。在第2 章讨论手工测试时，我指出，由于用户在使用软件过程中发现了这些缺陷，因此测试时也应通过使用软件来发现它们。然而，对于自动化测试和单元测试等，这些缺陷往往无法被发现。无论如何实现自动化，这些缺陷都可能继续影响你，并最终出现在用户面前。 问题在于，许多现行的手工测试实践缺乏明确的目的性，且带有随机性和重复性。有些人可能会认为手工测试无聊至极。本书旨在为手工测试的过程提供一些指导、技术和规划。 在第3 章中，针对测试人员在执行测试用例时所需做出的局部战术层面的决策，我提供了详细的指导建议。针对某个特定的输入字段或者应用程序使用数据时要用哪些输入值，测试人员必须做出决策。在测试过程中，必须做出许多这样的局部决策。如果没有适当的指导，这些决策往往缺乏有效的分析，甚至还可能不是最优的选择。比如，需要在一个文本框中输入数字时，整数4 是否比整数400 更合适？我应该用长度为 32 个字节的字符串还是长度为 256 个字节的字符串？选择一个而非另一个必然有其原因，这取决于软件将要处理的输入的具体情况。考虑到测试人员每天都需要做出数百个这样的局部决策，给出有效的指导就变得至关重要。 在第4 章中，针对测试人员在制订测试计划和设计测试用例时所需考虑的全局战术层面问题，我也提供了详细的指导建议。这些技术均基于“漫游测试”概念，通过归纳出的各种测试方法，引导测试人员探索应用程序的各个路径，类似于导游带领游客打卡大城市里各个著名的地标。这种探索并不一定是随机或无目的的。本书介绍的方法已经被纳入微软和谷歌测试人员的日常工作。当然，这种测试方法早在很久前就被称为‘漫游测试’，但将旅游类比应用于整个软件测试过程，特别是针对实际发布的大规模应用程序，是本书首创。 全局探索式测试为制定全面的测试策略提供了指导建议。如何创建功能覆盖率较高的用例集？如何在一个单独的测试用例中确定是否要包含多个功能的使用？如何创建一个全面的测试用例套件，以便在软件高负荷运行时发现更多严重的缺陷？这些问题都是设计测试用例和构建高质量测试套件时必须在第一时间解决的。 在第5 章中，通过结合探索式测试技术和传统基于脚本或场景的测试技术，我进一步拓展了漫游测试的概念。我要讨论如何通过修改端到端场景、测试脚本或用户故事的方法来创造更多变化，并增加传统静态测试技术发现缺陷的可能。 在第6 章中，来自微软各个产品线的5 位特邀作者提供了他们在漫游测试技术方面的经验汇报。这几名作者和他们的团队在真实的开发环境下，把漫游测试技术应用到真实的软件上，并记录了他们使用、修改漫游测试方法甚至创造自己方法的过程，是测试人员将漫游测试技术应用于关键产品的第一手资料。 最后，我用两章的内容来总结前面各章讨论的内容，以此作为本书的结尾。在第7 章中，我描述了我认为测试中最困难的几个问题，以及如何将具有较强针对性的探索式测试方法整合为一个更全面的解决方案。在第8 章中，我进一步讨论虚拟化、可视化、电子游戏等技术，以及它们如何在未来的几年内改变软件测试行业。附录中包括我对测试职业生涯的看法，以及过去深受读者喜爱的一些文章，这些文章夹叙夹议，其中一些文章在别的地方已经无法找到。 我希望你能够享受自己的阅读过程，就像我享受自己的写作过程一样。

• 暂无课件
• 暂无样章
• 暂无网络资源

扫描二维码
下载APP了解更多

版权图片链接