测试技术会从7个方面对测试过程进行指导。
范围 ：测试的对象。例如，功能测试的测试对象通常是一个具体的功能或特性。
覆盖 ：测试的程度。例如，如果测试时间很有限，测试人员通常只能测试一个功能的主要场景；如果测试时间充裕，他会测试更多的场景和操作方式，以扩大测试覆盖。通常，测试人员会统一考虑测试的范围和覆盖。
测试者 ：由谁来执行测试。例如，许多软件厂商提供Beta版本供用户试用，以便收集他们对早期版本的意见。对于Beta测试，其测试执行者就是软件试用者。
风险 ：测试要去发现的潜在问题。例如，Google ACC所重点侦测的风险是产品的功能不能提供有竞争力的特性。
活动 ：测试如何执行。例如，两因素组合测试规定测试用例集要覆盖任意两个因素的取值组合。
评估和测试先知 ：如何评价测试是否通过。例如，测试人员会使用软件的先前版本来判断软件的行为是否向后兼容。
结果导向 ：测试的目标。例如，BVT（build verification testing）的目标是检查构建是否足够稳定可用于更大范围的测试。

第一，基于覆盖的测试技术关注测试的范围和覆盖

典型的测试技术如下。
功能测试 ：覆盖产品的功能。
功能或特性的集成测试 ：覆盖功能之间的交互。
漫游测试 ：其基本策略是搜索产品的一个区域，并收集相关信息。这通常要求覆盖指定的一组测试对象。
等价类分析 ：覆盖所有的等价类。
边界测试 ：覆盖边界值和邻近区域。
最佳代表测试 ：要求从众多测试用例中选择最有代表性的测试用例，常见的例子包括用户最可能使用的数据、给产品最大挑战的数据、最能暴露风险的数据等。
域测试 ：从一个数值集合中选择测试输入数据，等价类分析和边界测试是典型的域测试技术。如果穷尽测试不可行，那么域测试要选择出典型的测试数据，然后分别加以覆盖。
测试想法目录 ：包括测试想法列表、质量特性列表、缺陷目录等启发式想法集合。测试人员要依次检查每个想法，选择合适的想法来设计具体的测试。
逻辑表达式 ：覆盖逻辑表达式的所有可能输入。
多变量测试 ：使用某种覆盖标准去测试多个变量的取值组合，组合测试是一种多变量测试技术。
状态变迁测试 ：覆盖状态机中所有的变迁。
用户界面测试 ：覆盖所有用户可访问的界面元素。
基于规格说明的测试 ：检查规格说明的所有陈诉得到正确地实现。
基于需求的测试 ：检查所有需求被正确地实现。
依从性测试 ：检查软件符合所有需要满足的法律和约定。
配置测试 ：覆盖所有或典型的软硬件配置组合。
本地化测试 ：覆盖所有被本地化的元素，包括界面字符串、日期格式、货币格式、字符集等。

第二，基于测试者的测试技术关注谁来执行测试 。

用户测试 ：让实际用户测试产品。通常，测试人员与用户一起工作，收集用户发现的缺陷和提出的意见。
Alpha测试 ：让产品的早期用户（通常是公司同事）试用产品。
Beta测试 ：让一批实际用户测试产品。测试人员不与用户共同测试，但会分析用户提交的缺陷。
缺陷大扫除 ：邀请项目团队的所有人员参与测试，旨在让不同的人通过不同的视角来检查软件，从而在短时间内（缺陷大扫除通常持续1~2天）发现大量的缺陷。
专家测试 ：邀请领域专家和测试人员结对测试。
结对测试 ：让测试人员和测试人员结对、测试人员和程序员结对，从而产生更多差异化的测试想法。
内部试用 ：让项目团队在日常工作中使用自己开发的产品，从而
尽早发现实际用户会遇到的问题。
本地化测试 ：让熟悉目标市场文化的人来测试软件。

第三，基于风险的测试技术关注潜在问题 。

边界测试 ：其关注的是软件在处理边界值时很可能出错的风险。
快速测试 ：一组很轻便的测试方法，针对一组典型的软件错误实施攻击。
约束测试 ：利用输入约束、输出约束、计算约束和数据约束对软
件进行测试。这些约束往往涉及软件能力的边界，会暴露软件的不足。
逻辑表达式 ：关注多个条件变量的组合，以检查软件能否处理一些罕见的情况。
压力测试 ：关注软件如何应对远远超过正常工作量的负荷，此时一些隐藏的缺陷很可能会暴露。
负载测试 ：关注软件能否有效地使用资源去处理工作负载。其针对的风险是软件不能合理地使用资源，当工作负载还没有到达预期上限时，它已经占用了太多的资源，且处理速度变得很慢。
性能测试 ：关注软件能否在可接受的时间内完成计算任务。其针对的风险是软件的反应速度不能满足用户的期望。
基于历史的测试 ：要求测试人员分析先前版本中所发现的错误，识别出可能再次复现的缺陷，利用它们去设计测试。其针对的风险是程序员会犯同样的错误，或者某些缺陷描述了业务或技术面临的
根本性困难，很难彻底解决。
基于风险的多变量测试 ：从风险的角度测试多个变量的取值组合。
可用性测试 ：检查软件是否容易学习和使用。其关注的风险是糟糕的软件设计让用户感到挫折，以致他们会使用竞争对手的产品。
配置和兼容性测试 ：检查软件在不同软硬件平台上的表现，所针对的风险是产品可能在某些平台上失败。
互操作性测试 ：检查软件与相关系统的交互。因为几个系统通常由不同的团队开发，他们对交互协议可能有不同的解读，所以系统交互总是会暴露出各种复杂的问题。
长序列测试 ：反复且随机地运行一组测试用例。因为测试序列漫长且覆盖面广，它可能暴露内存泄漏、竞态条件、悬挂指针等问题。

第四，基于活动的测试技术关注如何执行测试 。

游击测试 ：测试人员在固定的时间盒内，对软件的特定区域实施基于风险的测试。
两因素组合测试 ：测试人员需要生成符合两因素组合覆盖标准的测试数据。通常测试人员会利用组合测试工具生成测试数据。
随机测试 ：利用随机数生成器去产生测试数据、安排测试顺序或选择测试对象。
用例测试 ：根据用例或序列图来设计测试序列，以覆盖软件的操作序列。
情景测试 ：创建一个或一组故事来测试软件在故事场景中的表现。
安装测试 ：在不同的平台上安装和卸载软件，并检查操作结果。
回归测试 ：运行已有的测试用例来再次测试相同的功能。
长序列测试 ：要求测试整晚运行或持续几天，以发现一些短时间测试不能发现的问题。
猴子测试 ：要求测试人员构建自动化测试程序，来随机地、持续地、自动地测试产品。例如，测试程序基于产品的自动机模型和当前状态，随机地选择触发事件，以触发状态变迁，并持续迭代下去。在此过程中，测试程序会判断变迁是否正确、产品是否出现错误。
性能测试 ：要求测试人员识别用户使用产品的典型模式，确定需要评估的性能指标，然后构造出相应的测试流程去考察软件的性能。

第五，基于评估的测试技术关注如何判断测试通过 。

功能等价测试 ：比较被测软件的行为和参考软件（例如已经发布的上一版软件）的行为。如果被测软件的行为与参考软件不一致，那么它很可能出现错误。
数学先知 ：根据数学规则判断测试结果的对错。例如，三角函数、求平方根、矩阵转置等计算的结果都需要满足数学定理和计算法则。
约束检查 ：根据一组规则判断测试是否通过。例如，测试随机数生成函数时，测试人员很难判断每一个输出是否正确。他可以持续调用该函数，收集一大批随机数结果，然后分析这批数据。如果数据分布足够均匀，不存在明显的规律，那么该函数的质量就较好；如果数据分布呈现出某种规律，以致测试人员可以预测下一次输出的取值，那么该函数还需要改进。
自检验数据 ：包含可以用于检验的数据。例如，为了暴露对数据的异常修改，测试人员计算了数据的哈希值，让它随数据在系统中传播。每经过一个模块后，测试程序会重新计算数据的哈希值，并与先前保存的值进行比较。如果两个值不同，那么数据被该模块篡改。
比较已保存的结果 ：通过对比前后两个版本产生的数据，来侦测新版本可能引入的错误。比较规格说明或其他权威文档 ：根据权威文档来判断软件的行为是否正确。
基于诊断的测试 ：会使用软件的调试功能或一些调试辅助工具。当调试功能被打开或辅助工具被启用时，这些面向诊断的代码会持续检查产品的状态。当测试人员运行测试时，它们可以发现产品的异常状态，如内存泄漏、句柄泄漏、未处理系统调用错误等，并报告给测试人员。可检验的状态模型 ：使用测试人员构建的状态机为测试先知。测试程序调用软件接口，以驱动状态变迁，然后比较软件的实际状态和预期状态，以检查可能的错误。

第六，结果导向的测试技术关注于特定目标或文档 。

构建检验 ：其目标是判断当前构建是否足够好，能否提供给测试小组或更广泛的用户去测试。
确认测试 ：运行精心设计的确认测试用例，其目标是证明软件满足预先定义的要求。
用户接受测试 ：运行用户指定或认可的一批测试用例，其目标是证明软件达到了用户可接受的标准。
认证测试 ：要求测试小组提供证据以表明产品或产品制造过程满足某个认证标准。
利用以上分类系统，测试人员可以判断一个测试技术的驱动因素是什么，了解它着眼于何处、又省略了哪些方面。在学习测试技术时，测试人员可以快速定位它在分类系统中的位置。在选择测试技术时，他可以同时运用来自不同分支的测试技术，以实施多样化的测试。