测试需求分析指南

测试需求分析指南 

 1. 前言  

1.1 什么是测试需求？  确切地讲，所谓的测试需求就是在项目中要测试什么。我们在测试活动中，首先需要明确测试需求（What），才能决定怎么测（How），测试时间（When），需要多少人（Who），测试的环境是什么（Where），测试中需要的技能、工具以及相应的背景知识，测试中可能遇到的风险等等，以上所有的内容结合起来就构成了测试计划的基本要素。而测试需求是测试计划的基础与重点。  就像软件的需求一样，测试需求根据不同的公司环境，不同的专业水平，不同的要求，详细程度也是不同的。但是，对于一个全新的项目或者产品，测试需求力求详细明确，以避免测试遗漏与误解。   

 1.2 为什么要做测试需求？  如果要成功的做一个测试项目，首先必须了解测试规模、复杂程度与可能存在的风险，这些都需要通过详细的测试需求来了解。所谓知己知彼，百战不殆。测试需求不明确，只会造成获取的信息不正确，无法对所测软件有一个清晰全面的认识，测试计划就毫无根据可言。活在自己世界里的人是可悲的，只凭感觉不做详细了解就下定论的项目是失败的。  测试需求越详细精准，表明对所测软件的了解越深，对所要进行的任务内容就越清晰，就更有把握保证测试的质量与进度。  如果把测试活动比作软件生命周期，测试需求就相当于软件的需求规格，测试策略相当于软件的架构设计，测试用例相当于软件的详细设计，测试执行相当于软件的编码过程。只是在测试过程中，我们把”软件”两个字全部替换成了”测试”。这样，我们就明白了整个测试活动的依据来源于测试需求。 

 2. 测试需求分析方法  

2.1 测试需求分析依据  通常是以被测产品的需求为原型进行分析转变而来，测试需求主要通过以下途径来进行收集：  

1）与待测软件相关的各种文档资料。如软件需求规格、Use case、界面设计、项目会议或与客户沟通时有关于需求信息的会议记录、其他技术文档等。 

   2）与客户或系统分析员的沟通。   

 3）业务背景资料。如待测软件业务领域的知识等。  

 4）正式与非正式的培训。 

 5）其他。如果以旧系统为原型，以全新的架构方式来设计或完善软件，那么旧系统的原有功能跟 特性就成为了最有效的测试需求收集途径。  

2.2 测试需求架构划分  测试需求分析应首先进行测试需求架构划分并先进行评审,通过后才进行后续的测试需求展开分析，从产品整体上考虑有哪些功能、测试类型需要进行分析，列出测试特性列表，也方便下一步展开具体分析。  首先，这里需要对功能进行一下定义以达成共识，功能是指能独立实现一个基本业务处理要求，为了降低测试需求设计的复杂性及依赖性，测试需求架构罗列的功能是指最小功能点，即不可再继续分解。 

 (1) 应用程序： 

 A. 一般是最底层的菜单项为最小功能点，但如果最底层的菜单项不能体现一个独立的业务流 程时，可采用上一层的菜单项为最小功能点。 

 B. 还有某些比较特殊没有体现在菜单项的功能也需要作为最小功能点考虑，如POS应用程序 的冲正功能等。  

(2) 驱动：一般是以一个API为最小功能点。  然后，再考虑产品实际用户使用的场合及用户特点考虑哪些测试类型，如故障及恢复、功能集成、性能要求、安装测试、软硬件兼容性等，此处需要从产品层面考虑，而不是从功能点层面考虑。 

 2.3 测试需求分析过程 

2.3.1 测试需求收集  测试需求的收集主要通过对测试依据进行分析整理，最后生成一个以测试的观点出发的checklist，用来作为测试该软件的主要工作内容。    在整个信息收集过程中，务必确保软件的功能与特性被正确理解。因此，测试需求分析人员必须具备优秀的沟通能力与表达能力。

  2.3.2 测试类型划分 

2.3.3 测试类型细化 

2.3.4 生成测试需求树

 2.3.5 测试风险分析 

 3. 总结

3.1分析功能步骤的方法：

　　>>列出所有可测的功能点

　　>>对每个功能点进行分层分析（接口、UI）

　　>>功能点之间有哪些耦合关系

　　>>有哪些可能的异常流程

3.2通用异常情况：

　　>>网络环境：网络中断、网络切换、丢包延时

　　>>服务器资源：服务器无响应、响应慢、无法连接服务器

　　>>系统环境：被测系统文件缺失、PC或 手机系统缺少必要组件、权限不足

　　>>异常中断：断电、通话中断

3.3如何找到隐藏需求：

　　>>了解需求整体架构

　　>>熟悉所有实现细节

　　>> 代入用户角色，实际场景中推测