整体测试文档

本文主要根据软件开发W模型来阐述完整的软件测试。

图1.4 软件测试过程W模型

需求测试

一、什么是需求测试

需求测试是根据需求分析来的。

什么是需求分析？需求分析明确用户需要的是什么功能，用户会怎样使用系统。

什么是需求测试？就是测试需求分析，测试需求分析中的功能是否满足客户需求，需求实现方案是否可取，功能点是否可测试等。明确的测试要点，分析测试执行时对应的测试方案/方法。

二、为什么要做需求分析

1、需求分析的必要性

如果要成功的做一个测试项目，首先必须了解测试规模、复杂程度与可能存在的风险，这些都需要通过详细的测试需求来了解。所谓知己知彼，百战不殆。测试需求不明确，只会造成获取的信息不正确，无法对所测软件有一个清晰全面的认识，测试计划就毫无根据可言，只凭感觉不做详细了解就下定论的项目是失败的。

测试需求分析越详细精准，表明对所测软件的了解越深，对所要进行的任务内容就越清晰，就更有把握保证测试的质量与进度。

如果把测试活动比作软件生命周期，测试需求分析就相当于软件的需求规格，测试策略相当于软件的架构设计，测试用例相当于软件的详细设计，测试执行相当于软件的编码过程。只是在测试过程中，我们把”软件”两个字全部替换成了”测试”。这样，我们就明白了整个测试活动的依据来源于测试需求，所以需求分析是整个测试活动必不可少的环节。

2、不做需求分析的后果

不做需求分析或需求分析不到位，可能会产生很严重的问题，比如：

（1）浪费时间和资源实现了用户不需要的需求；

（2）遗漏了需求文档中没提到，但很重要的需求，导致客户满意度降低。

（3）需求分析不到位，错误的估计了测试的工作量，导致延误发布周期，可能会降低发布质量。

以上的几个问题，在实际开发中是比较常见的，主要的原因就是需求分析不到位，会导致影响客户的满意度。

三、怎么做需求测试

1、通过需求文档了解需求的实现背景

拿到一个需求后，我们首先应该通读需求文档，先通过需求文档，对要做的需求的背景有个整体的了解，其实这个过程也是对需求文档测试的过程，对需求整体的了解后，我们可以先

记录自己的一些疑惑，为后面需求的分析做一个准备工作，这个环节我们应该更多的了解一些需求的目的和一些用户的使用场景。

2、分析需求合理性

可以通过业务知识来分析需求的合理性，而不是单单通过系统是怎样实现的来判断需求是否合理，这也是测试人员必备的技能之一，即需要我们有深厚的业务功底，然后在通过结合系统现有的实现来分析需求的合理性。

在我看来需求是否合理主要包括两个方面：第一，满足客户需求。第二，在系统原有的基础上，尽量减少改动成本。

3、确定测试的范围和优先级

通过以上对需求的分析，我们就可以确定测试的范围和优先级了。首先我们要确定好这个需求所涉及的全部测试点，然后通过分析，分析出测试范围的优先级。

4、细化测试点并确定测试方法

确定了测试范围和优先级后，就可以对各模块进行细化，可以用MindManager列出个模块下的测试点，各模块或大的测试点需要写出对应的测试方法，或测试策略。是否需要性能测试、白盒测试，是否需要提前准备数据，或会遇到什么样的测试难点，采取怎样的应对措施。

5、查缺补漏

做完了需求的细化后，要对自己做的需求分析从头到尾在捋一遍，查看有没有什么遗漏的，因为需求也又可能遗漏的地方。主要关注有没有场景需求没有考虑全面，涉及的修改范围被遗漏了，以及一些特殊的关联配置没有考虑到的，另外如果需求做了一些变动也要及时补充需求分析，主要是分析变动可能带来的风险，以及准备哪些应对之策。

四、需求测试常用的几种方法

通过评审规格说明书来测试需求

正确性：对照原始需求检查SRS

必要性：不能回溯到出处的需求项可能是多余的

优先级：恰当划分并标识

明确性：不使用含糊的词汇

可测性：每项需求都必须是可验证的

完整性：不能遗漏必要和必需的信息

一致性：与原始需求一致、内部前后一致

可修改性：良好的组织结构使需求易于修改

SRS测试步骤

第一步：获取最新版本的SRS，同时尽量取得用户原始需求文档

第二步：阅读和尝试理解SRS描述的所有需求项

第三步：对照SRS Review Checklist进行检查并记录

第四步：针对检查结果进行讨论、修订SRS后回到第一步，直到Checklist的所有项通过

软件需求规格说明书评审检查单模板

概要设计测试