软件测试的方法一共有几种
大体有以下四种，还有很多。
1、按是否查看程序内部结构分为：
（1）、黑盒测试（black-box testing）：只关心输入和输出的结果
（2）、白盒测试（white-box testing）：去研究里面的源代码和程序结构
2、按是否运行程序分为：
（1）、静态测试（static testing）：是指不实际运行被测软件，而只是静态地检查程序代码、界面或文档可能存在的错误的过程。
静态测试包括：
对于代码测试，主要是测试代码是否符合相应的标准和规范。
对于界面测试，主要测试软件的实际界面与需求中的说明是否相符。
对于文档测试，主要测试用户手册和需求说明是否真正符合用户的实际需求。
（2）、动态测试（dynamic testing），是指实际运行被测程序，输入相应的测试数据，检查输出结果和预期结果是否相符的过程
3、按阶段划分：
（1）、单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。
桩模块（stud）是指模拟被测模块所调用的模块，驱动模块（driver）是指模拟被测模块的上级模块，驱动模块用来接收测试数据，启动被测模块并输出结果。
（2）、集成测试（integration testing），是单元测试的下一阶段，是指将通过测试的单元模块组装成系统或子系统，再进行测试，重点测试不同模块的接口部门。
集成测试就是用来检查各个单元模块结合到一起能否协同配合，正常运行。
（3）、系统测试（system testing），指的是将整个软件系统看做一个整体进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行测试。
系统测试的主要依据是《系统需求规格说明书》文档。
（4）、验收测试（acceptance testing），指的是在系统测试的后期，以用户测试为主，或有测试人员等质量保障人员共同参与的测试，它也是软件正式交给用户使用的最后一道工序。
验收测试又分为a测试和beta测试，其中a测试指的是由用户、 测试人员、开发人员等共同参与的内部测试，而beta测试指的是内测后的公测，即完全交给最终用户测试。
4、黑盒测试分为功能测试和性能测试：
（1）、功能测试（function testing），是黑盒测试的一方面，它检查实际软件的功能是否符合用户的需求。
包括逻辑功能测试（logic function testing）
界面测试（UI testing）UI=User Interface
易用性测试（usability testing）：是指从软件使用的合理性和方便性等角度对软件系统进行检查，来发现软件中不方便用户使用的地方。
兼容性测试（compatibility testing）：包括硬件兼容性测试和软件兼容性测试
（2）、性能测试（performance testing）
软件的性能主要有时间性能和空间性能两种
时间性能：主要指软件的一个具体事务的响应时间（respond time）。
空间性能：主要指软件运行时所消耗的系统资源。
软件性能测试分为：
一般性能测试：指的是让被测系统在正常的软硬件环境下运行，不向其施加任何压力的性能测试。
稳定性测试也叫可靠性测试（reliability testing）：是指连续运行被测系统检查系统运行时的稳定程度。
负载测试（load testing）：是指让被测系统在其能忍受的压力的极限范围之内连续运行，来测试系统的稳定性。
压力测试（stress testing）：是指持续不断的给被测系统增加压力，直到将被测系统压垮为止，用来测试系统所能承受的最大压力。(Validate the system or software can allowed the biggest stress.)
5、其他测试类型：
回归测试（regression testing）是指对软件的新的版本测试时，重复执行上一个版本测试时的用例。
冒烟测试（smoke testing），是指在对一个新版本进行大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。
随机测试（random testing），是指测试中所有的输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误。
扩展资料 :
测试流程
1、制定测试计划。
2、编辑测试用例。
3、执行测试用例。
4、发现并提交BUG。
5、开发组修正BUG。
6、对已修正BUG进行返测。
7、修正完成的BUG将状态置为已关闭，未正确修正的BUG重新激活。
软件测试测试阶段
单元测试
单元测试是对软件组成单元进行测试，其目的是检验软件基本组成单位的正确性，测试的对象是软件设计的最小单位：模块。
集成测试
集成测试也称联合测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。其主要目的是检查软件单位之间的接口是否正确，集成测试的对象是已经经过单元测试的模块。
系统测试
系统测试主要包括功能测试、界面测试、可靠性测试、易用性测试、性能测试。 功能测试主要针对包括功能可用性、功能实现程度（功能流程&业务流程、数据处理&业务数据处理）方面测试。
回归测试
回归测试指在软件维护阶段，为了检测代码修改而引入的错误所进行的测试活动。回归测试是软件维护阶段的重要工作，有研究表明，回归测试带来的耗费占软件生命周期的1/3总费用以上。
与普通的测试不同，在回归测试过程开始的时候，测试者有一个完整的测试用例集可供使用。
因此，如何根据代码的修改情况对已有测试用例集进行有效的复用是回归测试研究的重要方向，此外，回归测试的研究方向还涉及自动化工具，面向对象回归测试，测试用例优先级，回归测试用例补充生成等。
现状
软件开发中出现错误或缺陷的机会越来越多，市场对软件质量重要性的认识逐渐增强。所以，软件测试在软件项目实施过程中的重要性日益突出。
但是，现实情况是，与软件编程比较，软件测试的地位和作用，还没有真正受到重视，对于很多人（甚至是软件项目组的技术人员）还存在对软件测试的认识误区，这进一步影响了软件测试活动开展和真正提高软件测试质量。
（1）、误区之一：软件开发完成后进行软件测试
人们一般认为，软件项目要经过以下几个阶段：需求分析，概要设计，详细设计，软件编码，软件测试，软件发布。据此，认为软件测试只是软件编码后的一个过程。这是不了解软件测试周期的错误认识。软件测试是一个系列过程活动，包括软件测试需求分析，测试计划设计，测试用例设计，执行测试。
因此，软件测试贯穿于软件项目的整个生命过程。在软件项目的每一个阶段都要进行不同目的和内容的测试活动，以保证各个阶段的正确性。软件测试的对象不仅仅是软件代码，还包括软件需求文档和设计文档。软件开发与软件测试应该是交互进行的，例如，单元编码需要单元测试，模块组合阶段需要集成测试。
如果等到软件编码结束后才进行测试，那么，测试的时间将会很短，测试的覆盖面将很不全面，测试的效果也将大打折扣。更严重的是如果此时发现了软件需求阶段或概要设计阶段的错误，如果要修复该类错误，将会耗费大量的时间和人力。
（2）、误区之二：软件发布后如果发现质量问题，那是软件测试人员的错
这种认识很打击软件测试人员的积极性。软件中的错误可能来自软件项目中的各个过程，软件测试只能确认软件存在错误，不能保证软件没有错误，因为从根本上讲，软件测试不可能发现全部的错误。从软件开发的角度看，软件的高质量不是软件测试人员测出来的，是靠软件生命周期的各个过程中设计出来的。
出现软件错误，不能简单地归结为某一个人的责任，有些错误的产生可能不是技术原因，可能来自于混乱的项目管理。应该分析软件项目的各个过程，从过程改进方面寻找产生错误的原因和改进的措施。
（3）、误区之三：软件测试要求不高，随便找个人做都行
很多人都认为软件测试就是安装和运行程序，点点鼠标，按按键盘的工作。这是由于不了解软件测试的具体技术和方法造成的。随着软件工程学的发展和软件项目管理经验的提高，软件测试已经形成了一个独立的技术学科，演变成一个具有巨大市场需求的行业。
软件测试技术不断更新和完善，新工具，新流程，新测试设计方法都在不断更新，需要掌握和学习很多测试知识。所以，具有编程经验的程序员不一定是一名优秀的测试工程师。软件测试包括测试技术和管理两个方面，完全掌握这两个方面的内容，需要很多测试实践经验和不断学习的精神。
（4）、误区之四：软件测试是测试人员的事情，与程序员无关
开发和测试是相辅相成的过程，需要软件测试人员、程序员和系统分析师等保持密切的联系，需要更多的交流和协调，以便提高测试效率。另外，对于单元测试主要应该由程序员完成，必要时测试人员可以帮助设计测试样例。
对于测试中发现的软件错误，很多需要程序员通过修改编码才能修复。程序员可以通过有目的的分析软件错误的类型、数量，找出产生错误的位置和原因，以便在今后的编程中避免同样的错误，积累编程经验，提高编程能力。
（5）、误区之五：项目进度吃紧时少做些测试，时间富裕时多做测试
这是不重视软件测试的表现，也是软件项目过程管理混乱的表现，必然会降低软件测试的质量。一个软件项目的顺利实现需要有合理的项目进度计划，其中包括合理的测试计划，对项目实施过程中的任何问题，都要有风险分析和相应的对策，不要因为开发进度的延期而简单的缩短测试时间、人力和资源。
因为缩短测试时间带来的测试不完整，对项目质量的下降引起的潜在风险，往往造成更大的浪费。克服这种现象的最好办法是加强软件过程的计划和控制，包括软件测试计划、测试设计、测试执行、测试度量和测试控制。
（6）、误区之六：软件测试是没有前途的工作，只有程序员才是软件高手
由于我国软件整体开发能力比较低，软件过程很不规范，很多软件项目的开发都还停留在“作坊式”和“垒鸡窝”阶段。项目的成功往往靠个别全能程序员决定，他们负责总体设计和程序详细设计，认为软件开发就是编写代码，给人的印象往往是程序员是真正的牛人，具有很高的地位和待遇。
因此，在这种环境下，软件测试很不受重视，软件测试人员的地位和待遇自然就很低了，甚至软件测试变得可有可无。随着市场对软件质量的不断提高，软件测试将变得越来越重要，相应的软件测试人员的地位和待遇将会逐渐提高。
在软件过程比较规范的大公司，软件测试人员的数量和待遇与程序员没有多大差别，优秀测试人员的待遇甚至比程序员还要高。软件测试将会成为一个具有很大发展前景的行业，软件测试大有前途，市场需要更多具有丰富测试技术和管理经验的测试人员，他们同样是软件专家。
前景
随着软件产业的发展，软件产品的质量控制与质量管理正逐渐成为软件企业生存与发展的核心。几乎每个大中型IT企业的软件产品在发布前都需要大量的质量控制、测试和文档工作，而这些工作必须依靠拥有娴熟技术的专业软件人才来完成。
软件测试工程师就是这样的一个企业重头角色。业内人士分析，该类职位的需求主要集中在沿海发达城市，其中北京和上海的需求量分别占去33%和29%。民企需求量最大，占19%，外商独资欧美类企业需求排列第二，占15%。
然而，现状是：一方面企业对高质量的测试工程师需求量越来越大越大，另一方面国内原来对测试工程师的职业重视程度不够，使许多人不了解测试工程师具体是从事什么工作。这使得许多IT公司只能通过在实际工作中进行淘汰的方式对测试工程师进行筛选，因此国内在短期将出现测试工程师严重短缺的现象。
根据对网络招聘IT人才情况的了解，许多正在招聘软件测试工程师的企业很少能够在招聘会上顺利招到合适的人才。在具体工作过程中，测试工程师的工作是利用测试工具按照测试方案和流程对产品进行功能和性能测试，甚至根据需要编写不同的测试用例，设计和维护测试系统，对测试方案可能出现的问题进行分析和评估。
对软件测试工程师而言，必须具有高度的工作责任心和自信心。任何严格的测试必须是一种实事求是的测试，因为它关系到一个产品的质量问题，而测试工程师则是产品出货前的把关人，所以，没有专业的技术水准是无法胜任这项工作的。
同时，由于测试工作一般由多个测试工程师共同完成，并且测试部门一般要与其他部门的人员进行较多的沟通，所以要求测试工程师不但要有较强的技术能力而且要有较强的沟通能力。
参考资料：百度百科-软件测试
功能测试常用方法都有哪些？
一，页面链接检查；二，相关性检查；三，检查按钮的功能是否正确；四，字符串长度检查；五，字符类型检查；六，标点符号检查；七，中文字符的处理；八，检查带出信息的完整性；九，信息重复；十，检查删除功能；十一，检查添加和修改是否一致；十二，检查修改重名；十三，检查多次使用back键的情况；十四，搜索功能检查；十五，输入信息位置；十六，上传下载文件检查；十七，必填项检查；十八，快捷键检查；十九，回车键检查。
软件测试方法的分类有哪些
1）按照测试技术划分
黑盒测试：功能测试，必须
白盒测试：逻辑结构测试，代码的逻辑、算法、结构是否正确，要求必须懂得代码，需要编写测试用例，可选
灰盒测试：介于中间
注意：在单元测试时，白盒应用相对较多，在集成测试时，灰盒测试应用相对较多，在系统、验收测试时一般就不会使用白盒测试和灰盒测试了。
2）按是否需要运行代码划分
静态测试：界面测试，文档测试，代码测试【重点关注代码的规范性，一般检查变量的命名，注释的频率，编程的规范性，不需要写测试用例，一般只需要有代码审查单】
注意：一般经常把白盒测试和静态测试的要素结合在一起，形成静态白盒测试
动态测试：运行程序进行检查，检查实际输出结果和预期结果是否相符
3）按软件特性分类
功能测试
性能测试
软件测试的方法有哪几种？
《全国计算机等级考试三级教程软件测试》
目录
第1章 软件测试的基本概念
1.1 软件质量的概念
1.1.1 软件质量的定义
1.1.2 软件质量的属性
1.1.3 软件质量模型
1.1.4 软件质量的度量
1.1.5 影响软件质量的主要因素
1.2 软件测试的概念
1.2.1 软件测试的定义与目的
1.2.2 软件测试的原则
1.3 软件的缺陷与错误
1.3.1 软件缺陷的定义和类型
1.3.2 软件缺陷的级别
1.3.3 软件缺陷产生的原因
1.3.4 软件缺陷的构成第1章 软件测试的基本概念
1.1 软件质量的概念
1.1.1 软件质量的定义
1.1.2 软件质量的属性
1.1.3 软件质量模型
1.1.4 软件质量的度量
1.1.5 影响软件质量的主要因素
1.2 软件测试的概念
1.2.1 软件测试的定义与目的
1.2.2 软件测试的原则
1.3 软件的缺陷与错误
1.3.1 软件缺陷的定义和类型
1.3.2 软件缺陷的级别
1.3.3 软件缺陷产生的原因
1.3.4 软件缺陷的构成
1.3.5 修复软件缺陷的代价
1.4 软件测试的经济学与心理学
1.4.1 软件测试的心理学
1.4.2 软件测试的经济学
1.5 软件质量保证
1.5.1 软件质量保证概要
1.5.2 软件质量保证活动的实施
1.5.3 软件的验证与确认
1.5.4 验证和确认任务分析
本章小结
第2章 软件生存周期中测试的实施
2.1 软件开发阶段
2.1.1 软件生存周期
2.1.2 软件测试的生存周期模型
2.1.3 软件测试过程模型
2.1.4 测试信息流
2.2 需求获取与分析阶段的测试
2.2.1 需求评审的实施
2.2.2 需求规格说明的评审
2.2.3 Wiegers 用例与需求评审表
2.2.4 基于原型的测试
2.2.5 基于需求的测试覆盖率评估
2.3 设计阶段的测试
2.3.1 设计的测试因素
2.3.2 设计评审的实施
2.3.3 设计规格说明的评审
2.3.4 设计元素的覆盖原则
2.4 编程阶段的测试
2.4.1 白盒测试与黑盒测试
2.4.2 源代码的控制流覆盖原则
2.4.3 源代码的数据流覆盖原则
2.4.4 源代码的静态分析与动态测试
2.5 运行和维护阶段的测试
2.6 回归测试
2.6.1 回归测试的概念
2.6.2 回归测试的类型
2.6.3 回归测试的时机
2.6.4 回归测试的实施
本章小结
第3章 代码检查、走查与评审
3.1 桌上检查
3.1.1 桌上检查的实施
3.1.2 桌上检查的检查表
3.2 代码检查
3.2.1 特定的角色和职责
3.2.2 代码检查的实施
3.2.3 用于代码检查的检查表
3.3 走查
3.3.1 特定的角色和职责
3.3.2 走查的实施
3.3.3 走查中的静态分析技术
3.4 同行评审
3.4.1 同行评审的角色和职责
3.4.2 同行评审的内容
3.4.3 评审的方法和技术
3.4.4 评审工作
本章小结
第4章 白盒测试
4.1 覆盖率的概念
4.2 逻辑覆盖
4.2.1 语句覆盖与块覆盖
4.2.2 判定覆盖（分支覆盖）
4.2.3 条件覆盖
4.2.4 条件/判定覆盖
4.2.5 条件组合覆盖
4.2.6 路径覆盖
4.2.7 ESTCA覆盖
4.2.8 LCSAJ覆盖
4.3 路径测试
4.3.1 分支结构的路径测试
4.3.2 循环结构的路径测试
4.3.3 圈复杂度与基本路径测试
4.4 数据流测试
4.4.1 定义∕使用测试的几个定义
4.4.2 定义∕使用测试举例
4.4.3 定义∕使用路径测试覆盖指标
4.5 基于覆盖的测试用例选择
4.5.1 覆盖率的使用
4.5.2 使用最少的测试用例来达到覆盖
4.6 程序插桩技术
4.6.1 程序插桩
4.6.2 用于测试覆盖率的程序插桩
4.6.3 用于断言检测的程序插桩
4.6.4 用于数据流异常检测的程序插桩
本章小结
第5章 黑盒测试
5.1 等价类测试
5.1.1 等价类的概念
5.1.2 等价类测试的原则
5.1.3 等价类方法测试用例设计举例
5.2 边界值分析
5.2.1 边界值分析的概念
5.2.2 选择测试用例的原则
5.2.3 边界值方法测试用例设计举例
5.3 基于判定表的测试
5.3.1 判定表的概念
5.3.2 基于判定表的测试用例设计举例
5.4 基于因果图的测试
5.4.1 因果图的适用范围
5.4.2 用因果图生成测试用例
5.4.3 因果图法测试用例设计举例
5.5 基于状态图的测试
5.5.1 状态图
5.5.2 利用状态转换树生成测试用例
5.5.3 利用状态转换表生成测试用例
5.6 基于功能图的测试
5.6.1 功能图
5.6.2 功能图法设计测试用例举例
5.7 基于用例和场景的测试
5.7.1 基本流和备选流
5.7.2 利用用例和场景设计测试用例的实例
5.8 基于有向图的测试用例设计
5.8.1 使用基于有向图的测试的场合
5.8.2 基于事务流建模设计测试用例
5.8.3 基于控制流建模设计测试用例
5.8.4 基于有向图设计测试用例的过程
5.9 基于正交实验设计法的测试
5.9.1 提取功能说明，构造因子／ 状态表
5.9.2 加权筛选，生成因素分析表
5.9.3 利用正交表构造测试数据集
5.10 其他黑盒测试用例设计技术
本章小结
第6章 单元测试和集成测试
6.1 单元测试的基本概念
6.1.1 单元测试的定义
6.1.2 单元测试与集成测试、系统测试的区别
6.1.3 单元测试环境
6.2 单元测试策略
6.2.1 自顶向下的单元测试策略
6.2.2 自底向上的单元测试策略
6.2.3 孤立测试
6.2.4 综合测试
6.3 单元测试分析
6.3.1 模块接口
6.3.2 局部数据结构
6.3.3 独立路径
6.3.4 出错处理
6.3.5 边界条件
6.4 单元测试的测试用例设计原则
6.4.1 单元测试的测试用例设计步骤
6.4.2 单元测试中的白盒测试与黑盒测试
6.5 集成测试的基本概念
6.6 集成测试策略
6.6.1 基于分解的集成策略
6.6.2 基于功能的集成
6.6.3 基于路径的集成
6.6.4 基于调用图的集成
6.7 集成测试分析
6.7.1 体系结构分析
6.7.2 模块单元分析
6.7.3 接口分析
6.7.4 风险分析
6.7.5 可测试性分析
6.7.6 集成测试策略分析
6.7.7 常见的集成测试故障
6.8 集成测试的测试用例设计原则
6.8.1 集成测试的测试用例设计步骤
6.8.2 场景测试
本章小结
第7章 系统测试
7.1 系统测试概念
7.2 系统测试的方法
7.2.1 功能测试
7.2.2 协议一致性测试
7.2.3 性能测试
7.2.4 压力测试
7.2.5 容量测试
7.2.6 安全性测试
7.2.7 失效恢复测试
7.2.8 备份测试
7.2.9 GUI测试
7.2.10 健壮性测试
7.2.11 兼容性测试
7.2.12 可使用性测试
7.2.13 安装测试
7.2.14 文档测试
7.2.15 在线帮助测试
7.2.16 数据转换测试
7.3 系统测试的实施
7.3.1 确认测试
7.3.2 α 测试和β测试
7.3.3 验收测试
7.3.4 系统测试问题总结、分析
7.4 做好系统测试的原则
本章小结
第8章 软件性能测试和可靠性测试
8.1 软件性能测试的基本概念
8.1.1 软件性能
8.1.2 软件性能测试
8.2 软件性能测试的执行
8.2.1 性能测试的过程与组织
8.2.2 性能分析
8.2.3 性能测试的自动化
8.3 软件可靠性的概念
8.4 软件可靠性测试的执行
8.4.1 软件可靠性测试的过程
8.4.2 软件可靠性预测
8.5 软件故障数目的预测
8.6 软件可靠性分析
本章小结
第9章 面向对象软件的测试
9.1 面向对象软件测试的问题
9.1.1 面向对象的基本特点引起的测试问题
9.1.2 面向对象程序的测试组织问题
9.2 面向对象软件的测试模型及策略
9.3 面向对象程序的单元测试
9.3.1 方法层次的测试
9.3.2 类层次的测试
9.3.3 类树层次的测试
9.4 面向对象软件的集成测试
9.4.1 面向对象软件的集成测试策略
9.4.2 针对类间连接的测试
9.4.3 面向对象软件集成测试的UML支持
9.5 面向对象软件的系统测试
本章小结
第10章 Web应用软件测试
10.1 Web应用软件的特点
10.1.1 Web应用软件的概念
10.1.2 Web应用软件的特点
10.1.3 Web应用软件的基本结构
10.1.4 Web应用软件的常用开发技术
10.2 应用服务器的分类和特征
10.2.1 三层和多层体系结构
10.2.2 应用服务器的分类
10.2.3 应用服务器对Web应用软件测试的影响
10.3 Web 应用软件的测试策略
10.3.1 表示层的测试
10.3.2 业务层的测试
10.3.3 数据层的测试
10.3.4 层间的集成测试
10.4 Web应用软件的系统测试技术
10.4.1 功能测试
10.4.2 性能测试
10.4.3 易用性测试
10.4.4 内容测试
10.4.5 安全性测试
10.4.6 接口测试
10.5 基于数据库的Web应用软件的性能测试
10.6 Web应用软件的系统安全检测与防护
10.6.1 入侵检测
10.6.2 漏洞扫描
10.6.3 安全策略
本章小结
第11章 其他测试
11.1 兼容性测试
11.1.1 硬件兼容性测试
11.1.2 软件兼容性测试
11.1.3 数据兼容性测试
11.2 易用性测试
11.2.1 易安装性测试
11.2.2 功能易用性测试
11.2.3 用户界面测试
11.3 极限测试
11.3.1 极限编程基础
11.3.2 极限测试
11.3.3 JUnit简介
11.4 文档测试
11.4.1 文档测试的范围
11.4.2 用户文档的内容
11.4.3 用户文档的测试
本章小结
第12章 软件测试过程和管理
12.1 软件测试过程
12.1.1 测试过程的概念
12.1.2 测试过程的抽象模型
12.1.3 测试阶段中的测试活动
12.2 测试过程组织与管理
12.2.1 软件测试过程管理的特点
12.2.2 软件测试过程的人员组织
12.3 测试策划管理
12.3.1 测试策划的目标
12.3.2 测试需求分析
12.3.3 测试策略与测试方法
12.3.4 测试策划工作流程
12.3.5 测试计划的要点
12.4 测试设计与实现管理
12.4.1 软件测试设计与实现主要内容
12.4.2 软件测试设计与实现要点
12.4.3 测试用例的设计方法
12.4.4 测试用例的管理
12.4.5 测试开发
12.5 测试环境管理
12.5.1 测试环境的定义
12.5.2 测试环境是测试的基础
12.5.3 测试环境的各要素
12.5.4 测试环境准备
12.6 测试执行管理
12.6.1 基于测试环境的测试用例执行
12.6.2 测试用例执行的记录与跟踪
12.6.3 软件缺陷的跟踪和管理
12.6.4 测试执行活动结束
12.7 测试质量分析
12.7.1 评估系统测试的覆盖程度
12.7.2 软件缺陷分析方法
12.8 测试总结管理
12.9 测试过程改进
12.9.1 软件测试过程改进的概念
12.9.2 软件测试过程改进的具体方法
本章小结
第13章 软件自动化测试
13.1 自动化测试的原理与方法
13.2 自动化测试的限制
13.3 自动化测试用例的生成
13.3.1 脚本的作用、质量和编写原则
13.3.2 脚本的基本结构
13.4 测试执行自动化
13.5 测试结果比较自动化
13.5.1 自动比较的基本概念
13.5.2 动态比较
13.5.3 执行后比较
13.6 基于STAF／STAX的自动化测试框架
13.7 测试工具的分类与选择
13.7.1 测试工具的分类
13.7.2 测试工具的选择
13.8 主流测试工具
13.8.1 主流单元测试工具
13.8.2 主流功能测试工具
13.8.3 主流负载测试工具
13.8.4 主流软件测试管理工具
本章小结
第14章 软件测试的标准和文档
14.1 软件测试的标准
14.1.1 软件测试规范
14.1.2 软件测试文档编制规范
14.2 软件测试文档格式和模板
14.2.1 软件测试文档格式
14.2.2 软件测试部分模板
本章小结
第15章 软件测试实践
15.1 软件测试过程管理实践
15.1.1 测试实践中的测试过程类型
15.1.2 测试策划实践
15.1.3 测试设计与实现的实践
15.1.4 测试执行实践
15.1.5 测试总结实践
15.1.6 QESuite Web 1.0 软件测试过程管理平台实践
15.2 白盒测试实践
15.2.1 QESAT／C简介
15.2.2 被测程序link.c说明
15.2.3 测试准备
15.2.4 静态分析
15.2.5 动态测试
白盒测试的测试方法
白盒测试的测试方法有代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、域测试、符号测试、路径覆盖和程序变异。
白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。六种覆盖标准发现错误的能力呈由弱到强的变化：
1.语句覆盖每条语句至少执行一次。
2.判定覆盖每个判定的每个分支至少执行一次。
3.条件覆盖每个判定的每个条件应取到各种可能的值。
4.判定/条件覆盖同时满足判定覆盖条件覆盖。
5.条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
6.路径覆盖使程序中每一条可能的路径至少执行一次。
白盒测试是什么意思？白盒测试方法包括哪些？
白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。
白盒测试是一种测试用例设计方法，盒子指的是被测试的软件，白盒指的是盒子是可视的，你清楚盒子内部的东西以及里面是如何运作的。
"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。"白盒"法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。
采用什么方法对软件进行测试呢?常用的软件测试方法有两大类：静态测试方法和动态测试方法。其中软件的静态测试不要求在计算机上实际执行所测程序，主要以一些人工的模拟技术对软件进行分析和测试；而软件的动态测试是通过输入一组预先按照一定的测试准则构造的实例数据来动态运行程序，而达到发现程序错误的过程。
在动态分析技术中，最重要的技术是路径和分支测试。