第1章概述为什么要进行软件测试？就是因为软件缺陷的存在。
因为只有通过测试，才可以发现软件缺陷。
也只有发现了缺陷，才可以将软件缺陷从软件产品或软件系统中清理出去。
软件缺陷是任何程序、系统中的问题，和产品设计书的不一致性，不能满足用户的需求IEEE 国际标准729给出了软件缺陷的定义——软件缺陷就是软件产品中所存在的问题，最终表现为用户所需要的功能没有完全实现，不能满足或不能全部满足用户的需求根据软件缺陷的定义，可以从两方面考虑：☐从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；☐从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。
软件缺陷的主要类型/现象：☐功能、特性没有实现或部分实现☐设计不合理，存在缺陷☐实际结果和预期结果不一致☐运行出错，包括运行中断、系统崩溃、界面混乱☐数据结果不正确、精度不够☐用户不能接受的其他问题，如存取时间过长、界面不美观软件缺陷的产生①技术问题，算法错误，语法错误，计算和精度问题，接口参数传递不匹配②团队工作误解、沟通不充分③软件本身文档错误、用户使用场合(user scenario)，时间上不协调、或不一致性所带来的问题，系统的自我恢复或数据的异地备份、灾难性恢复等问题验证和确认Verification：Are we building the product right？是否正确地构造了软件？即是否正确地做事，验证开发过程是否遵守已定义好的内容。
验证产品满足规格设计说明书的一致性Validation：Are we building the right product? 是否构造了正是用户所需要的软件？即是否正在做正确的事。
验证产品所实现的功能是否满足用户的需求需求评审和设计评审是验证软件产品的需求定义和设计实现，验证所定义的产品特性是否符合客户的期望、系统的设计是否合理、是否具有可测试性以及满足非功能质量特性的要求。
这个阶段主要通过对需求文档、设计文档等阅读、讨论，从中发现软件需求工程和系统设计中所存在的问题。
产品需求审查是软件开发重要环节之一，也是测试活动之一，即静态测试——需求验证。
需求评审归为静态测试范畴，包含了文档评审和技术评审双重内容，通常通过正式的评审会议来进行。
而测试人员主要起着评审员的作用，检查需求定义是否合理和清楚。
单元测试的对象是程序系统中的最小单元---模块或组件上，在编码阶段进行，针对每个模块进行测试，主要通过白盒测试方法，从程序的内部结构出发设计测试用例，检查程序模块或组件的已实现的功能与定义的功能是否一致、以及编码中是否存在错误。
多个模块可以平行地、对立地测试，通常要编写驱动模块和桩模块单元测试一般由编程人员和测试人员共同完成集成测试，也称组装测试、联合测试、子系统测试，在单元测试的基础上，将模块按照设计要求组装起来同时进行测试，主要目标是发现与接口有关的模块之间问题两种集成方式：一次性集成方式和增殖式集成方式。
功能测试，依据产品设计规格说明书完成对产品功能进行操作，以验证系统是否满足用户的功能性需求系统测试是将软件放在整个计算机环境下，包括软硬件平台、某些支持软件、数据和人员等，在实际运行环境下进行一系列的测试，包括恢复测试、安全测试、强度测试和性能测试等第2章需求和设计评审产品需求审查是软件开发重要环节之一，也是测试活动之一，即静态测试——需求验证。
借助需求审查保证用户需求在市场/产品需求文档及其相关文档中得到准确、完整、无歧义的反映，并使各类开发人员在需求理解上达成一致软件评审是对软件元素或者项目状态的一种评估手段，以确定其是否与计划的结果保持一致，并使其得到改进。
技术评审文档评审管理（流程）评审检查表（checklist）是一种常用的的质量保证手段，也是正式技术评审的必要工具，评审过程往往由检查表驱动。
一份精心设计的检查表，对于提高评审效率、改进评审质量具有很大帮助。
可靠性。
人们借助检查表以确认被检查对象的所有质量特征均得到满足，避免遗漏任何项目。
☐效率。
检查表归纳了所有检查要点，比起冗长的文档，使用检查表具有更高的工作效率。
软件缺陷并不只是在编程阶段才产生，需求和设计阶段同样会产生缺陷。
测试需求测试目标取决于软件质量需求，而这种需求分为功能性需求和非功能性需求，功能性的需求相对容易确定，非功能性的测试需求难以确定。
☐在制定测试计划之前，必须清楚测试需求☐明确测试需求的优先级☐测试需求分解得越细，对测试用例的设计质量越有帮助☐详细的测试需求还是衡量测试覆盖率的重要依据☐测试需求是规划具体项目资源和时间的基础。
功能性测试需求功能性测试需求主要是根据产品规格说明书来检验被测试的系统是否满足软件各方面的功能的使用要求，包括用户界面的友好性。
☐程序安装、启动正常，有相应的提示框、错误提示☐各项功能符合设计要求，正常运行并输出正确结果☐功能逻辑合理，并能处理各种异常操作☐能接受正确的数据输入，输出结果准确，格式清晰☐系统的各种状态按照业务流程而变化并保持稳定☐支持各种应用环境，能配合硬件设备非功能性需求非功能性质量需求，包括系统性能、安全性、兼容性、扩充性，其测试需求会因不同的项目类型差异较大☐客户端软件，如字处理软件、媒体播放软件等占用较少资源，在容错性、兼容性等方面要求高。
☐Web应用系统对性能、安全性等有很高要求☐客户端/服务器应用系统。
☐大型复杂企业级系统。
需求评审归为静态测试范畴，包含了文档评审和技术评审双重内容，通常通过正式的评审会议来进行。
而测试人员主要起着评审员的作用，检查需求定义是否合理和清楚。
设计审查成功的产品开发和演化依赖于体系结构恰当的选择。
软件设计一般可以分为体系结构设计和详细设计。
测试人员参与设计评审保证需求能在设计中得到准确和完整的表示，也就是保证产品规格说明书的质量。
☐系统架构的审查☐设计规格说明书的审查☐系统部署设计的审查☐多层次审查:high-level low-level系统设计的评审标准☐设计技术评审标准。
稳定、清晰、合理☐非功能性质量特性的设计评审要求。
安全、性能、稳定、扩展、可靠。
☐评审的输入：体系结构文档、设计规范与指南、风险列表☐评审的输出：经认可的软件体系结构文档、变更需求、评审记录☐评审的检查点：软件体系结构、设计模式、部署视图、进程视图、封装体、协议。
第3章测试用例设计测试用例（test case）是可以被独立执行的一个过程，这个过程是一个最小的测试实体，不能再被分解。
测试用例也就是为了某个测试点而设计的测试操作过程序列、条件、期望结果及其相关数据的一个特定的集合。
测试用例要描述Why ——为什么而测？What ——测什么？Where ——在哪里测？When ——什么时候开始测？Which ——哪些输入数据？How ——如何操作软件？为什么需要测试用例☐如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。
☐测试用例是测试工作的指导，是软件测试的必须遵守的准则，更是软件测试质量稳定的根本保障。
☐软件测试是有组织性、步骤性和计划性的，为了能将软件测试的行为转换为可管理的、具体量化的模式，需要创建和维护测试用例单个测试用例的质量要求❖具有可操作性❖具备所需的各项信息❖各项信息描述准确、清楚❖测试目标针对性强❖验证点完备，而且没有太多的验证点❖没有太多的操作步骤，例如不超过7步❖符合正常业务惯例。
整体测试用例的质量要求❖覆盖率。
依据特定的测试目标的要求，尽可能覆盖所有的测试范围、功能特性和代码。
❖易用性。
测试用例的设计思路清晰、组织结构层次合理，测试用例操作的连贯性好，使单个模块的测试用例执行顺畅。
❖易维护性。
应该以很少的时间来完成测试测试用例的维护工作，包括添加、修改和删除测试用例。
易用性和易读性，也有助于易维护性。
❖粒度适中。
既能覆盖各个特定的场景，保证测试的效率；又能处理好不同数据输入的测试要求，提高测试用例的可维护性。
良好测试用例的特征❖可以最大程度地找出软件隐藏的缺陷❖可以最高效率的找出软件缺陷❖可以最大程度地满足测试覆盖要求❖既不过分复杂、也不能过分简单❖使软件缺陷的表现可以清楚的判定▪测试用例包含期望的正确的结果▪待查的输出结果或文件必须尽量简单明了❖不包含重复的测试用例❖测试用例内容清晰、格式一致、分类组织第4章自动化测试自动化测试（automated test）是相对手工测试（manual test）而存在的一个概念，由手工逐个地运行测试用例的操作过程被测试工具自动执行的过程所代替。
测试工具的使用是自动化测试的主要特征自动化测试焦点集中在测试执行，主要是由测试工具自动地完成测试。
测试自动化指“一切可以由计算机系统自动完成的测试任务都已经由计算机系统或软件工具、程序来承担并自动执行”自动化测试测试工具测试执行单项活动测试自动化理念全过程所有测试活动包括测试设计测试管理在系统功能逻辑测试、验收测试、适用性测试、涉及交互性测试时，多采用手工测试方法；单元测试、集成测试、系统负载或性能、可靠性测试等比较适合采用TA；对那种不稳定、开发周期短或一次性的软件等不适合TA工具本身缺乏想象力和创造性，自动测试只能发现15%的缺陷，而手工测试可以发现85%的缺陷；代码分析代码的静态分析的关键是建立各种规则，而这种规则的建立是依赖于相应编程语言的语法。
如依据EBNF（扩展巴科斯-诺尔范式）对Java代码的分析。
脚本技术线性脚本，是录制手工执行的测试用例得到的脚本，这种脚本包含所有的击键、移动、输入数据等，所有录制的测试用例都可以得到完整的回放。
结构化脚本，类似于结构化程序设计，具有各种逻辑结构、函数调用功能。
数据驱动脚本，将测试输入存储在独立的（数据）文件中，而不是存储在脚本中。
关键字驱动脚本，是数据驱动脚本的逻辑扩张开源工具解决方案❖单元测试：JUnit & XUnit 家族❖功能测试：Selenium、Abbo AutoIT/AutoHotkey❖性能测试：JMeter❖数据库：DBprobe❖网络监控：Wireshark/Ethereal, Netcat, Snort第5章单元测试单元测试就是对已实现的软件最小单元进行测试，以保证构成软件系统的各个单元的质量单元测试活动中，强调被测试对象的独立性单元测试应从各个层次来对单元内部算法、外部功能实现等进行检验，包括对程序代码的评审和通过运行单元程序来验证其功能特性等内容。
单元测试的目标单元实现了其特定的功能，如果需要，返回正确的值单元的运行能够覆盖预先设定的各种逻辑在单元工作过程中，其内部数据能够保持完整性，包括全局变量的处理、内部数据的形式、内容及相互关系等不发生错误可以接受正确数据，也能处理非法数据，在数据边界条件上，单元也能够正确工作该单元的算法合理，性能良好该单元代码经过扫描，没有发现任何安全性问题单元测试主要采用白盒测试方法，辅以黑盒测试方法。