测试分析在整个测试过程中占据很重要的位置，测试分析做好了，使一些项目设计方面考虑不足的因素在前期就被发现，降低了项目的风险，提高了测试效率，节约了很多的成本，良好的分析性思维有助于我们更好的做好测试分析工作。
分析性思维
分析性思维（Analytical Thinking）属于逻辑性、理性、科学性的思维方式，也可以说是“纵向思维”——根据逻辑不断深入问题的一种思维方式。是以一次前进一步为特征。包括归纳推理、演绎推理、证明等逻辑思维。是指经过仔细研究、逐步分析，最后得出明确结论的思维方式。
分析性思维帮助我们建立一种循序渐进的思维方法，从收集问题的相关信息、比较不同来源的信息、明确真正的问题得出适当的问题解决方案，一步一步地去解决问题：
- 明确要解决的问题，以及要达到的目的或目标；
- 为解决问题收集相关的各种数据、信息；
- 整理和分析数据、信息，为解决问题找到依据、原因；
- 分析和识别问题所面对的假设、条件、场景；
- 从依据、假定等处罚，进行逻辑推理，得出解决方案；
- 从工程角度看，得出一个解决方案还远没有结束，必须得到多个解决方案；
- 为评估解决方案设立评估标准，即评价什么样的解决方案是更优的方案；
- 基于评估标准，分析各个方案的利益、所带来的负面影响等；
- 基于上述评估分析（定性或定量），从上述方案中选出一个较优的方案；
- 给出明确的结论或观点，为结论做出合理的解释。
说了这么多，还没谈到软件测试。别急，现在就来讨论：
- 软件测试和分析性思维究竟有什么关系？
- 分析性思维对软件测试究竟有多大价值？
- 分析性思维如何应用于软件测试中？
分析性思维与软件测试的关系
软件测试方法就是基于分析性思维构建起来的，把软件测试看作是软件工程的一个分支，具有符合科学逻辑的、结构化的知识体系，是相对客观、严谨、规范，完全可以分析、度量的。从这个角度看，人们通过分析能够完整理解软件，通过分析能够全面验证软件需求、设计和实现的一致性。
从测试工作本身来看，测试就是尽可能多地找出软件中存在的漏洞，评估软件产品质量。这个过程完全可以通过分析推理，发现软件需求、设计和实现上的漏洞，通过比较分析、综合性分析，依据客观数据（包括缺陷数据、性能指标等）来准确地评估软件质量。
谈到分析性思维，就需要我们理性，讲科学、重逻辑。通过上面的分析，实际上也清楚地告诉我们：软件测试是这么一回事、软件测试的工作如何去做……
分析性思维对软件测试的价值
测试分析设计体系，一个最主要的目的就是使测试工作前移，加强测试需求分析阶段的活动，在软件分析设计阶段就介入测试，使得一些设计方面的缺陷和不足被早期的发现。降低了项目的成本。
没有分析性思维，就无法完成软件测试，无论是什么样的标准、模型，终究离不开分析的过程，除非不需要思维，完全对照某个标准进行检查，或者说什么仪器能够自动读出数据，就能得出测试的结果。但现实中，我们还无法将产品需求、客户期望直接输入到某个工具中，就能得出测试结果。况且，我们面对的测试系统都比较复杂，产品需求、客户的期望也需要经过分析整理，才能成为质量的要求、测试的目标，才能作为测试的输入。测试的输出结果也要分析，才能知道究竟如何影响软件产品整体质量、或某个质量属性。
分析性思维可以让我们在测试工作中从整体地、多角度地、多层次地分析问题，有不同的思考，就会有不同的测试策略、测试方法，会决定我们是如何制定测试项的优先级，会影响我们的测试分析、设计与执行的某些活动。
分析性思维在软件测试的应用
在测试中要解决的问题很多，包括需求的可测试性、确定测试范围、测试风险排序、制定测试策略、设计测试用例、测试结果评估、产品质量评价等，这些地方都是分析性思维发挥巨大作用的地方。例如，就以“确定测试范围”为例，讨论一下如何运用分析性思维。
- 为什么要确定测试范围？确保测试能够达到测试目标。测试目标是什么？保证新实现的业务特性正常运行、已有业务不受影响。
- 为了确定测试范围，需要收集各种信息，例如这个项目哪些功能做了修改？从业务关系看哪些功能会受影响？还可以了解系统内部结构，或借助工具进行代码依赖性分析，了解如果哪些功能的代码修改了，会影响哪些代码、从而会影响哪些功能？新的版本会不会改数据库？产品线上的数据和改动的数据库是否兼容？最近一段时间，有没有新的终端设备、新的操作系统版本、新的浏览器版本发布？是否支持？开发会不会做代码重构？如果代码重构，会重构哪些模块的代码？性能、安全性、兼容性……有什么新要求？
- 整理获得的业务信息、运行环境信息？要修改的代码模块、受影响的代码信息，找出这些信息和测试范围之间的关系。
- 研发过程中，这些改动是确定的？会不会增加新的需求？哪些改动在什么情况下会取消？哪些需求相对明确？哪些需求相对不稳定？
- 基于项目质量、进度要求要求，基于对业务、系统的理解，确定测试项。
- 如果开发质量及时提测，测试范围可能会适当增加；如果代码耦合性偏高，测试范围要增大；如果开发提测时间延误，测试范围要相应缩小……
- 测试范围的确定主要平衡的就是效率和质量，而这取决于本项目的特点和特定的期望（项目目标）。清楚选择不同的测试范围，可能带来的测试风险或带来额外的测试工作量。
- 根据基于风险的测试策略和本项目的特定期望（质量第一或进度第一），来决定优先考虑的测试方案。