软件测试理论
2018-01-15 14:13 钱先生 阅读(349) 评论(0) 编辑 收藏 举报以下内容引自: http://bbs.eeworld.com.cn/thread-463139-1-1.html
软件测试经典资料大推荐（十二）---探索式软件测试
程序员之间流传着这样一句顺口溜：有人喜欢创造世界，他们做了开发者；有的人喜欢开发者，他们做了测试员。
什么是软件测试？软件测试就是一场本该在用户面前发生的灾难提前在自己面前发生了，这会让他们生出一种救世主的感觉，拯救了用户，也就拯救者这个软件，避免了他们被卸载的命运。
近年来，软件测试一直呈现出火爆的发展势头。为什么软件测试最近这么火。在这背后是有一定的深层次原因的。在中国的很多软件企业存在着重开发、轻测试的现象，造成日后的软件产品的质量问题频出，很多公司都表示市场上软件测试人员实在太少，想聘请也没有这方面的人才，所以只好退而求其次拿软件开发人员急用。所以尽快招聘软件测试人员已经成为当务之急。
基于前述现状，我们搜集整理了目前网络上有关软件测试方面的经典资料，其中相当大一部分是电子书。希望能够让大家对软件测试有一个全面深入的了解。
探索式软件测试
谈论软件质量的方法有很多，感兴趣的听众也有很多。本书是为软件测试人员而写的，写的是一种我认为比其他任何缺陷都重要的特殊缺陷：即逃过所有各种检测手段而最终存在于发布产品中的缺陷。
任何一个软件公司发布的产品都有缺陷。缺陷是怎么引入的？为什么没有在代码审核、单元测试、静态分析或其他面向开发人员的活动中把它们找出来？为什么自动化测试没有找出它们？那些缺陷有些什么特质使其能逃过手工测试？
什么是找出产品缺陷的最好方法？
本书针对的正是最后一个问题。在第2章“手工测试”中，我提出了一个观点：因为用户是在使用软件过程中找到这些缺陷的，所以我们的测试人员也应该通过使用软件来找到它们。无论使用自动化测试和单元测试，还是其他一些手段，都难以接触到这些缺陷。无论测试人员怎么实现自动化测试，即使全部都自动化，这些缺陷还是会处处作怪，并在产品中屡屡重现从而伤害最终用户。
问题在于很多现代化手工测试实践都缺乏目的性，随机性强且重复性强。有些人可能还会加上一条：手工测试无聊透顶。本书试图为手工测试流程提供一些指导、技术和规划。
在第3章“局部探索式测试法”中，针对测试人员在运行任何一个测试用例时都需要做出很多细微的战术层面决定，我给出了详尽的指导建议。测试人员必须决定对于某个特定的输入字段应该使用什么输入值，或者给应用程序使用的文件提供什么数据。在测试过程中，必须做出许多这样的小决定。在缺乏指导的情况下，这些决定常常是未经分析且不是最优化的。在向一个文本框内输入一个数时，选择整数4难道就胜过整数400么？应该用长度为32字节的字符串还是长度为256字节的字符串？选择一个而不选另一个是有一定道理的，这一切都取决于处理该输入的软件的具体情况。鉴于测试人员每天都要做出数百次这样的小决定，在这里提供有效的指导建议显得至关重要。
在第4章“全局探索式测试法”中，针对测试人员在编制测试计划和测试用例设计时需要考虑哪些广泛的战略性问题，我也给出了一些指导建议。这些技术都基于“漫游测试”（tour）概念，如同一个导游带领旅游团队参观大都市中一系列著名景点一样，这种漫游测试法指出的路线可以指导测试人员如何探索软件的方方面面。这里的探索并不一定是随机的或者漫无目的的。本书所记录的方法已经成为微软和谷歌的许多测试人员日常工作的一部分。诸如“地标测试法”（landmark tour）和“极限测试法”（intellectual’s tour）等词汇已经列入了手工测试人员的标准词汇表中。测试技术以前确实被称作“漫游”，但是用整个旅游业来隐喻软件测试，并在测试实际发布的应用程序时，大规模使用这些隐喻的名称，还属于本书的一个创举。
全局探索式测试法对于制定完整的测试策略给出了指导建议。例如，如何创建一组特性覆盖率（feature coverage）较高的测试用例？如何确定是否要在一个单独的测试用例中使用多个特性？如何创建一个完整的测试用例套件（test case suite），从而使软件尽可能地满负荷工作以便能找到更多重要的缺陷？这些都是设计测试用例和保证测试套件质量时必须解决的重大问题。
在第5章“混合探索测试技术”中，通过把探索式测试和传统的脚本或基于场景的测试技术相结合，进一步扩展了漫游的概念。我们将讨论如何修改各种端到端场景（end-to-end scenario）、测试脚本（test script）或用户故事（user story），来创造更多的变化情况，以激发传统静态测试技术查找缺陷的潜力。
在第6章“探索式测试的实际应用”中，来自微软不同产品组的五位客串作者提供了他们使用漫游技术后得到的经验报告。这些作者和他们的团队在真实的开发环境中，把漫游方法应用在真实的软件上。他们记录了各自是如何使用漫游、修改漫游甚至创建自己的漫游的。这些内容来自于使用漫游法测试重要的关键软件产品的测试人员，属于真正的第一手资料。
最后，我用两章内容总结前面各章所讨论的内容。在第7章“漫游测试的棘手问题”中，描述了我认为的测试中最困难的几个问题，以及如何将那些具有高度针对性的探索式测试方法融入一个更广泛的解决方案中。在第8章“软件测试的未来”中，我更进一步讨论在未来几年中，诸如虚拟化、可视化甚至电视游戏之类的技术将如何改变测试的面貌。附录包括我对测试职业生涯的看法，收集了我以前一些深受读者喜爱的文章（加入了一些新的注解），其中一些文章已经无法在其他地方看到了。
任何一个软件公司发布的产品都有缺陷。缺陷是怎么引入的？为什么没有在代码审核、单元测试、静态分析或其他面向开发人员的活动中把它们找出来？为什么自动化测试没有找出它们？那些缺陷有些什么特质使其能逃过手工测试？
什么是找出产品缺陷的最好方法？
本书针对的正是最后一个问题。在第2章“手工测试”中，我提出了一个观点：因为用户是在使用软件过程中找到这些缺陷的，所以我们的测试人员也应该通过使用软件来找到它们。无论使用自动化测试和单元测试，还是其他一些手段，都难以接触到这些缺陷。无论测试人员怎么实现自动化测试，即使全部都自动化，这些缺陷还是会处处作怪，并在产品中屡屡重现从而伤害最终用户。
问题在于很多现代化手工测试实践都缺乏目的性，随机性强且重复性强。有些人可能还会加上一条：手工测试无聊透顶。本书试图为手工测试流程提供一些指导、技术和规划。
在第3章“局部探索式测试法”中，针对测试人员在运行任何一个测试用例时都需要做出很多细微的战术层面决定，我给出了详尽的指导建议。测试人员必须决定对于某个特定的输入字段应该使用什么输入值，或者给应用程序使用的文件提供什么数据。在测试过程中，必须做出许多这样的小决定。在缺乏指导的情况下，这些决定常常是未经分析且不是最优化的。在向一个文本框内输入一个数时，选择整数4难道就胜过整数400么？应该用长度为32字节的字符串还是长度为256字节的字符串？选择一个而不选另一个是有一定道理的，这一切都取决于处理该输入的软件的具体情况。鉴于测试人员每天都要做出数百次这样的小决定，在这里提供有效的指导建议显得至关重要。
在第4章“全局探索式测试法”中，针对测试人员在编制测试计划和测试用例设计时需要考虑哪些广泛的战略性问题，我也给出了一些指导建议。这些技术都基于“漫游测试”（tour）概念，如同一个导游带领旅游团队参观大都市中一系列著名景点一样，这种漫游测试法指出的路线可以指导测试人员如何探索软件的方方面面。这里的探索并不一定是随机的或者漫无目的的。本书所记录的方法已经成为微软和谷歌的许多测试人员日常工作的一部分。诸如“地标测试法”（landmark tour）和“极限测试法”（intellectual’s tour）等词汇已经列入了手工测试人员的标准词汇表中。测试技术以前确实被称作“漫游”，但是用整个旅游业来隐喻软件测试，并在测试实际发布的应用程序时，大规模使用这些隐喻的名称，还属于本书的一个创举。
全局探索式测试法对于制定完整的测试策略给出了指导建议。例如，如何创建一组特性覆盖率（feature coverage）较高的测试用例？如何确定是否要在一个单独的测试用例中使用多个特性？如何创建一个完整的测试用例套件（test case suite），从而使软件尽可能地满负荷工作以便能找到更多重要的缺陷？这些都是设计测试用例和保证测试套件质量时必须解决的重大问题。
在第5章“混合探索测试技术”中，通过把探索式测试和传统的脚本或基于场景的测试技术相结合，进一步扩展了漫游的概念。我们将讨论如何修改各种端到端场景（end-to-end scenario）、测试脚本（test script）或用户故事（user story），来创造更多的变化情况，以激发传统静态测试技术查找缺陷的潜力。
在第6章“探索式测试的实际应用”中，来自微软不同产品组的五位客串作者提供了他们使用漫游技术后得到的经验报告。这些作者和他们的团队在真实的开发环境中，把漫游方法应用在真实的软件上。他们记录了各自是如何使用漫游、修改漫游甚至创建自己的漫游的。这些内容来自于使用漫游法测试重要的关键软件产品的测试人员，属于真正的第一手资料。
最后，我用两章内容总结前面各章所讨论的内容。在第7章“漫游测试的棘手问题”中，描述了我认为的测试中最困难的几个问题，以及如何将那些具有高度针对性的探索式测试方法融入一个更广泛的解决方案中。在第8章“软件测试的未来”中，我更进一步讨论在未来几年中，诸如虚拟化、可视化甚至电视游戏之类的技术将如何改变测试的面貌。附录包括我对测试职业生涯的看法，收集了我以前一些深受读者喜爱的文章（加入了一些新的注解），其中一些文章已经无法在其他地方看到了。
======================================================================
其它测试书籍，均引自同作者:
软件性能测试过程详解与案例剖析
本书围绕基础、案例、工具三个方面组织内容，给出了软件测试的基础知识，介绍了软件性能测试过程，并通过实际工程实例展示如何系统地开展性能测试。本书在第一版的基础上对不合时宜的章节进行了改写和补充，并根据性能测试的发展增加了三个部分的内容：“Web前端性能”，“敏捷性能测试”以及“JMeter应用与实例”，力图给软件性能测试工程师及相关人员提供较为全面的软件性能测试印象及参考。
本书不仅仅是一本讲述软件性能测试基础知识的书，也不是一本工具的使用手册，当然更不是一本入门类的书籍。本书面向具有一定测试基础，期望能够通过实际案例去感受和领悟性能测试的测试工程师。书中包含了作者多年在性能测试方面的经验总结，其中精选的案例覆盖多种架构和平台，涉及多个行业，可对实际工作起到直接的指导作用，同时，本书包含了所有会在性能测试中使用的模板，稍加修改即可应用在实际项目中。
本书探讨了50个至关重要的最佳实践、缺陷及解法。这些具体项目是从作者丰富的实践检验中收集而来，能够使质量保证专业人员和测试管理人员即刻提高其理解能力和技巧，避免重大错误，并实现当前水准的测试程序。 本书以介绍如何将测试运用到软件开发生命周期的所有阶段中为重点——从需求定义到设计直至最终代码。书中的50课主要集中于讲述软件测试的关键方面：测试计划、设计、文档、执行、管理测试小组、单元测试、自动化测试、非功能测试等。
软件测试的艺术
该书信息密度不低，第一章以一个小测试作为引子，第二章阐述全书的核心思想，后面各章就讨论了详细的方式方法。所谓详细也是相对而言，能打下进一步学习的基础就足够了。实例很少，偏向于原则、理论、概念。
本书全面系统地介绍了软件测试理论及应用技术，不仅讲述基本的测试技能，也讲述成为一个成功的软件测试员所必须掌握的高级技能。其目的在于引导读者通过基础知识和必要技能的学习而成为一个优秀的软件测试员，知道如何迅速在任一计算机程序中发现问题，如何计划一个有效的测试步骤，如何清楚地报告发现的问题，以及如何告知软件在何时发布。
《软件测试之魂：核心测试设计精解（第2版）》以测试设计为主线，首先介绍了软件测试行业在过去十多年来的发展变化——如今，实实在在地发生在我们身边的一起起软件质量事故，无不昭示着软件测试行业朝阳的到来。如何把握测试技术，把测试工作做得精透，成为测试行业的佼佼者，也是很多读者朋友关心的话题。《软件测试之魂：核心测试设计精解（第2版）》接下来首先明确了测试的目标，然后介绍了测试设计的各个环节，包括测试架构的设计、测试需求分析与测试策略制定、测试方案的设计、用例的设计、测试执行流程设计、测试输出的管理设计、测试过程的控制方法设计等。
最后，以追逐软测之理念进行延展，旨在帮助读者理解站在测试工作之上看测试，如何超越自我进行测试创新，为走出一条属于自己的测试精华之路提供指引。
最后，以追逐软测之理念进行延展，旨在帮助读者理解站在测试工作之上看测试，如何超越自我进行测试创新，为走出一条属于自己的测试精华之路提供指引。
话说程序调试
《话说程序调试》介绍对程序错误进行分析的思路、排查的方法，结合编译原理透彻地解释出错现象；介绍链接错误及其产生原因，以及运行时错误及其产生原因，并采用相应的程序演示运行时错误的调试方法。
《话说程序调试》还介绍调试程序逻辑错误常用的策略和技术。最后介绍程序调试测试与用例设计、科学设计测试用例等知识，其中涉及相关的软件测试技术。《话说程序调试》以较流行的turboc2．0集成环境作为编程环境，但是所述程序调试方法并不局限于c语言或turboc2．0环境。《话说程序调试》各章都引用c++程序示例，可帮助初学者拓展知识。
《话说程序调试》还介绍调试程序逻辑错误常用的策略和技术。最后介绍程序调试测试与用例设计、科学设计测试用例等知识，其中涉及相关的软件测试技术。《话说程序调试》以较流行的turboc2．0集成环境作为编程环境，但是所述程序调试方法并不局限于c语言或turboc2．0环境。《话说程序调试》各章都引用c++程序示例，可帮助初学者拓展知识。
google软件测试之道
Google软件测试之道》从内部视角告诉你这个世界上知名的互联网公司是如何应对21世纪软件测试的独特挑战的。《Google软件测试之道》抓住了Google做测试的本质，抓住了Google测试这个时代最复杂软件的精华。《Google软件测试之道》描述了测试解决方案，揭示了测试架构是如何设计、实现和运行的，介绍了软件测试工程师的角色；讲解了技术测试人员应该具有的技术技能；阐述了测试工程师在产品生命周期中的职责；讲述了测试管理及在Google的测试历史或在主要产品上发挥了重要作用的工程师的访谈，这对那些试图建立类似Google的测试流程或团队的人受益很大。
本书是遗留代码调试和优化领域的代表性著作，是作者10多年来在软件bug中“驱魔”经验的结晶，Amazon五星评论。不仅从实用性角度深入、系统地讲解了调试和优化遗留代码的方法、技术和最佳实践，而且从源头上阐述如何避免掉进维护遗留代码的泥潭，编写出易于维护，甚至不需要维护的高质量代码。
有效用例模式-软件测试用书
笑傲测试
http://download.eeworld.com.cn/detail/tiankai001/554664
《笑傲测试》是以武侠小说体裁撰著的软件工程测试项目管理书。全书将软件测试实战的全过程融会于侠义执著、幽默调侃的情境中，系统的测试定义、流程方法、技术规范、管理要点等技术管理信息能在充实而惬意、严谨又不失快慰的氛围里得到接受、理解和实施。读此书不仅能使初入门者轻松快捷地了解测试、掌握操作，又能让资深者在饭后茶余悠闲地领会作者对测试要义的准确把握，深厚谙熟的技术和人文功底。 本书既可作为职业培训和高校教辅读物，又是一本优质实用的业务指导书。
调试对软件开发至关重要。然而，即使对于有经验的程序员，调试也决非易事。
本书是一部优秀的软件调试实战指南，作者总结了自己和身边同事多年的经验教训，详细阐述了调试的方方面面。书中内容共分为三大部分。第一部分借助软件特有的功能展示缺陷是怎么产生的，介绍了建立在实证方法之上的核心调试方法；第二部分阐述怎样发现代码中存在需要修复的问题，以及如何将调试融入到整个软件开发过程中去；第三部分讨论如何避免一些常见的缺陷。
本书秉承了Pragmatic图书简洁实用的风格，总结了大量方法与经验，
本书是一部优秀的软件调试实战指南，作者总结了自己和身边同事多年的经验教训，详细阐述了调试的方方面面。书中内容共分为三大部分。第一部分借助软件特有的功能展示缺陷是怎么产生的，介绍了建立在实证方法之上的核心调试方法；第二部分阐述怎样发现代码中存在需要修复的问题，以及如何将调试融入到整个软件开发过程中去；第三部分讨论如何避免一些常见的缺陷。
本书秉承了Pragmatic图书简洁实用的风格，总结了大量方法与经验，
