在软件测试过程中，以最小的成本将软件质量风险降至最低，这就是精准测试。宏观上，测试分析是响应精准测试的实践，贯穿整个测试过程，并对整个测试过程起指导作用；实践中，测试分析在测试阶段中的位置如图所示:
图测试分析在测试流程中的位置
在项目中，我们往往根据需求和代码来进行分析，最后得到一个包含需求背景、开发实现分析、测试纬度等内容的xmind格式的简版分析报告。
图测试分析xmind模版
这里结合实践说明一下分析的过程以及分析侧重点。本文主要针对于增量的需求进行测试分析，对于全量的新项目，侧重点可能并不适用。
基于需求的测试分析互联网项目一般都追求快节奏，所以需求描述得比较简单，甚至可能会有一些重要逻辑未考虑的情况，对这样的需求进行分析时，推荐使用NLP模型来进行需求分析，理解需求、消除歧义。关于NLP模型可参见这里。NLP模型帮助测试同学理清需求，借助传统的用例设计的方法(正交分解、判定表、边界值、等价类、场景法等等)，可以设计出一些基于需求的用例。对需求进行测试分析，可以得到黑盒的测试策略，这一步可以在需求提出即可立即开展。
基于实现的测试分析通过查看开发的提交，分析开发实现，进而得到测试策略。下面重点说明一下基于实现的测试分析，也正是有别于传统基于需求的用例设计的分析方法。
一、查看代码提交SVN的提交是进行代码测试分析的输入，根据开发的提交Reversion来进行实现分析，进而得到最终的测试策略。
代码提交要求：
1、减少提交次数量：提交次数过多，Review人员容易被中间版本误导，影响review效率，提高review的成本。
2、提交与需求(bug)关联：提交必须与需求关联，并且一次提交必须仅与一个需求关联。
3、不提交无关代码：开发提交的代码中往往包含一些与需求无关的代码，可能是预埋逻辑，可能是备选方案。这些代码会影响Review人员的注意力，甚至会引起漏分析（预埋逻辑时未分析、真正使用该逻辑时也未分析）。
项目中测试人员应提醒开发注意养成良好的提交习惯。目前电脑管家全面推行使用公司组件Rain，规范化提交。
拿到与需求关联的提交后，我们可按照以下步骤进行分析：
二、理清类关系（可选）对于一般业务来说，一次迭代涉及的类不会太多，通过一些分析软件如understand可以立即生成类图供查看。类图虽然不能直接反应出业务逻辑，但对于理解开发实现的大致结构很有作用。通过类图可获取到一次迭代涉及哪些类以及类之间的继承关系，了解类大致成员有哪些。
understand生成的类图
三、寻找核心业务入口一般来说业务总会有一个入口点，找到入口点才能顺藤摸瓜。例如一个Button点击之后的很有可能是触发类似OnButtonClick的回调函数，那么这个函数即是我们的入口函数。有的业务有多条业务线，可能有多个入口，列出每个入口，后面一条条进行分析。
四、查找函数调用链从入口函数出发，找到所有业务函数调用链。这一步骤是整个测试分析的核心，直接关系到测试分析的质量。在查找业务函数调用链的过程中，注意核心函数的逻辑结构，如果非常复杂，可以借助控制流图来单独对函数内部结构进行分析，检查每个分支是否符合需求逻辑。
understand生成的控制流图
五、寻找测试点和开发Review有点不同，我们是带着测试分析的目的去Review的，即根据代码来找寻测试点。面对大量的代码提交，不要被代码带进去，深究一些非核心的细节往往会本末倒置，始终保持怀疑的态度去找寻测试点。对于一般windows程序，这里总结几个侧重点，可能并不正确，请大家拍砖。
重逻辑
UI往往在测试执行中容易发现问题，而逻辑的触发可能比较隐蔽，测试执行中不易触发。在项目时间紧张的情况下，把时间花在理清逻辑上更重要，也容易发现问题。当然一些逻辑触发意味着UI的变化，这样可以借UI印证逻辑的变化，是更好不过了。
重边界
黑盒测试中有专门说到边界值的用例设计方法，这里同样也需要北京根治白癜风医院北京中医白癜风医学研究