测试需求分析具体分两步：
1、测试需求的获取
需求的来源：
显式需求：
（1）原始需求说明书
（2）产品规格书
（3）软件需求文档
（4）有无继承性文档
（5）经验库
（6）通用的协议规范
隐式需求：用户的主观感受，市场的主流观点，专业人士的评价分析。
2、需求的分析 ，产生测试需求文档
将不同的需求来源划分成一个个需求点，针对每一点进行测试分析：
（1）界定测试范围
（2）利用各种测试设计的方法产生测试点
在测试方法方面，可做如下注意：
其一，分析出口入口。从入口分析，将可能出现的环境，条件，操作等内容分类组合，然后根据各位测试达人的方法进行整合，逐一验证。从出口分析，将可能出现的结果进行统计，根据结果的不同追根溯源，再找到不同的操作以及条件等内容，统计成文档，逐一验证。
其二，多种测试手法的学习和使用。大家可能更多的关心测试方法，但是具体操作的手法也是需要注意的。毕竟测试方法比较容易找到，各位达人都很熟悉。如果将每个人不同的测试手法总结出来并在自己的测试实施中加以使用，可能会收到意想不到的成果。
在测试流程方面，可作如下注意：
其一，初期要做好需求分析。将需求逐渐细化到小功能点，针对每个功能点进行测试设计。对于完成的测试设计文档，经过项目相关人员的检查评审，做成所需要的初稿。
其二，在测试过程中，根据需求变更和具体测试执行过程中遇到的问题完善测试设计文档。
其三，测试执行结束后，对于出现的问题进行总结。其中包含自己本身发现的问题，也可能会有客户提出的问题。将总结出来的结果融合到测试设计当中去，进一步完善测试设计文档。
对于一次测试，是不可能有覆盖度全面的测试的。需要多次去总结积累，才会使测试越来越全面。
在测试流思维方面，可作如下注意：
其一，测试全面不等于全面测试。不同阶段对于软件测试有不同的要求，比如在0.8版本以前，对于不重要的画面问题或是细小的功能问题就不需要关心。但是在验收阶段，这些内容可能更需要注意。
其二，学无止境，只有不断的去学习不断的去思考，才能使自己测试的能力更强，测试对象的全面性也更完整。
二、当测试需求分析完成，并且形成文档后，要进行测试需求评审，保证需求的准确性以及完整性。
三、测试需求完成以后，可以根据测试需求设计测试用例。
要保证测试用例能够全面覆盖测试需求，要包含所有的情况。
测试用例设计上划分为单功能测试用例和测试场景设计，单功能测试覆盖的需求中的功能点，测试场景覆盖需求中的业务逻辑。
在设计测试用例的时候，可以使用多种测试用例设计方法。
首先进行等价类划分，包括输入条件和输出条件的等价类划分，合理设置有效等价类和无效等价类,这是减少工作量和提高测试效率最有效的方法。
必须使用边界值分析，经验表明，这种方法设计出的用例能发现很多程序错误。
可以使用错误推测法追加一些测试用例，这需要依靠您的智慧和经验。
对照程序逻辑检查已设计出的测试用例的逻辑覆盖度，如果没有达到覆盖标准应当再补充足够的测试用例。
如果程序的功能说明中含有输入条件的组合情况，一开始就可选因果图和判定表驱动法。
对于参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳效果。
对于业务流清晰的系统，可以利用场景法贯穿整个测试方案过程，在案例中综合使用各种测试方法。
当测试用例设计完成后，要组织测试用例的评审，这样可以吸取别人的意见，减少遗漏，补全测试用例。
四、测试用例编写完成后，就是测试执行，测试用例执行100%覆盖。
在测试执行过程中，要继续对测试用例补充完善，确保提高测试覆盖率。
五、在整个测试过程中，需求都是不可能不变的，所以要及时的更新测试需求、测试用例。
六、要将测试需求、测试用例以及发现的bug关联起来，便于管理和跟踪，同时也便于查看覆盖率。
最后，我们不可能做到没有遗漏，只能说尽量覆盖的更全。另外，所有用例，最好是产品，开发，测试一起评审，不能测试说了算，防止思维局限导致遗漏。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
