关于需求分析:测试需求分析和设计

2次阅读

共计 4831 个字符，预计需要花费 13 分钟才能阅读完成。

1. 前言

1.1 什么是测试需要？

确切地讲，所谓的测试需要就是在我的项目中要测试什么。咱们在测试流动中，首先须要明确测试需要（What），能力决定怎么测（How），测试工夫（When），须要多少人（Who），测试的环境是什么（Where），测试中须要的技能、工具以及相应的背景常识，测试中可能遇到的危险等等，以上所有的内容联合起来就形成了测试计划的基本要素。而测试需要是测试计划的根底与重点。
就像软件的需要一样，测试需要依据不同的公司环境，不同的业余程度，不同的要求，具体水平也是不同的。然而，对于一个全新的我的项目或者产品，测试需要力求具体明确，以防止测试脱漏与误会。

1.2 为什么要做测试需要？

如果要胜利的做一个测试项目，首先必须理解测试规模、复杂程度与可能存在的危险，这些都须要通过具体的测试需要来理解。所谓知己知彼，百战不殆。测试需要不明确，只会造成获取的信息不正确，无奈对所测软件有一个清晰全面的意识，测试计划就毫无根据可言。活在本人世界里的人是可悲的，只凭感觉不做具体理解就下定论的我的项目是失败的。
测试需要越具体精准，表明对所测软件的理解越深，对所要进行的工作内容就越清晰，就更有把握保障测试的品质与进度。
如果把测试流动比作软件生命周期，测试需要就相当于软件的需要规格，测试策略相当于软件的架构设计，测试用例相当于软件的具体设计，测试执行相当于软件的编码过程。只是在测试过程中，咱们把“软件”两个字全副替换成了“测试”。这样，咱们就明确了整个测试流动的根据来源于测试需要。

2. 测试需要分析方法

2.1 测试需要剖析根据

通常是以被测产品的需要为原型进行剖析转变而来，测试需要次要通过以下路径来进行收集：
与待测软件相干的各种文档资料。如软件需要规格、Use case、界面设计、我的项目会议或与客户沟通时有对于需要信息的会议记录、其余技术文档等。
与客户或系统分析员的沟通。
业务背景材料。如待测软件业务畛域的常识等。
正式与非正式的培训。
其余。如果以旧零碎为原型，以全新的架构形式来设计或欠缺软件，那么旧零碎的原有性能跟个性就成为了最无效的测试需要收集路径。

2.2 测试需要架构划分

测试需要剖析应首先进行测试需要架构划分并先进行评审，通过后才进行后续的测试需要开展剖析，从产品整体上思考有哪些性能、测试类型须要进行剖析，列出测试个性列表，也不便下一步开展具体分析。
首先，这里须要对性能进行一下定义以达成共识，性能是指能独立实现一个根本业务解决要求，为了升高测试需要设计的复杂性及依赖性，测试需要架构列举的性能是指最小性能点，即不可再持续合成。
(1)应用程序：
A. 个别是最底层的菜单项为最小性能点，若最底层的菜单项不能体现一个独立的业务流程时，可采纳上一层
的菜单项为最小性能点。
B. 还有某些比拟非凡没有体现在菜单项的性能也须要作为最小性能点思考，如 POS 应用程序中交易的冲正性能
等。
(2) 驱动：个别是以一个 API 为最小性能点。
而后，再思考产品理论用户应用的场合及用户特点思考哪些测试类型，如故障及复原、性能集成、性能要求、装置测试、软硬件兼容性等，此处须要从产品层面思考，而不是从性能点层面思考。

2.3 测试需要剖析过程

2.3.1 测试需要收集

测试需要的收集次要通过对测试根据进行剖析整顿，最初生成一个以测试的观点登程的 checklist（检查表），用来作为测试该软件的次要工作内容。检查表的查看要点包含需要的正确性、必要性、优先级、明确性、可测性、完整性、一致性、可修改性：
在整个信息收集过程中，务必确保软件的性能与个性被正确理解。因而，测试需要剖析人员必须具备优良的沟通能力与表达能力。

2.3.1.1 测试类型划分

依据测试需要收集取得的 checklist(检查表)，对每一条测试需要，从 GB/T16260.1 定义的软件品质子个性角度登程，确定所对应的品质子个性。即，从适用性、准确性、互操作性、窃密安全性、成熟性、容错性、易恢复性、易了解性、易学性、以操作性、吸引性、工夫个性、资源利用性、易剖析性、易扭转性、稳定性、易测试性、适应性、易装置性、共存性、易替换性和依从性方面的定义登程，确定每一条测试需要所对应的品质子个性。从而对这些品质子个性进行测试类型划分，如：功能测试、易用性测试（装置测试、性能易用性测试、用户界面测试、辅助零碎测试）、兼容性测试、可靠性测试、文档测试、性能测试，强度测试等。

2.3.1.2 测试类型细化

对划分的每个测试类型进行细化。软件测试需要是开发测试用例的根据，测试需要合成得越具体精准，表明对软件的理解越深，对所有要进行的工作就越清晰，对测试用例的设计品质的帮忙也越大，具体的测试需要还是掂量测试覆盖度的重要指标，测试需要是计算测试笼罩的分母，没有具体的测试需要就无奈无效的进行软件测试笼罩计算。最好达到细化的后果是分支的最末端（测试项）针对的测试目标是繁多的最小的性能点的测试，即每个测试项为一个测试性能点。

2.3.1.3 生成测试需要树

已细化的测试需要中，因为在提取时，可能存在着反复或冗余，须要进行删除和合并需要。删除测试需要中存在的反复的、冗余的含有关系的测试项。如果有相似的测试项，则须要对其进行合并。最终生成测试需要树。

2.3.2 测试危险剖析

因为软件的输出、输入、解决存在肯定的限度和束缚，另一方面因为测试树中进行了必要的删除和合并，这导致测试需要不可能是全面的笼罩，从而造成了肯定的测试危险。测试需要中必须对不剖析或不测试局部给出相应的危险剖析阐明。

3. 总结

以上次要形容了测试需要相干实践和取得测试需要树的个别过程。为具体我的项目施行测试中提供了一套获取测试需要树的参考计划。理论的测试类型划分和测试需要树生成的模式或粒度，因我的项目而不同，需灵便利用。