简述软件设计与需求分析的方法(浅谈需求分析方法)
今天,我们来谈谈需求分析,想必朋友们经常进行需求分析,可是对于需求分析,你又知道多少呢?
2.测试需求的定义及目的
1.1 测试需求的定义
确切地讲,所谓的测试需求就是在项目中要实现什么功能。为了达到什么目的。我们在测试活动中,首先需要明确测 试需求什么内容(What),才能决定怎么测(How),测试时间(When),需要多少人(Who),测试的环境是什么(Where),测试中需要的技能、工具以及相应的背景知识,测试中可能 遇到的风险等等,以上所有的内容结合起来就构成了测试计划的基本要素。而测试需求是测试计划的基础与重点。测试计划是框架,测试需求是需要实现的内容。 但是对于软件的需求来说,会根据不同的公司环境,不同的专业水平,不同的要求,详细 程度会不一样。但是,对于一个全新的项目或者产品,测试需求力求尽量详细与明确,以避免测 试遗漏与误解。
1.2 我们一直不停地做需求分析,但是我们为什么要需求分析?
如果要成功的做一个测试项目,首先必须了解测试规模、复杂程度与可能存在的风险,这些 都需要通过详细的测试需求来了解。所谓知己知彼,百战不殆。测试需求不明确,只会造成 获取的信息不正确,无法对所测软件有一个清晰认识全面,测试计划就毫无根据可言。 测试需求越详细精准,表明对所测软件的了解越深,对所要进行的任务内容就越清晰,就更 有把握保证测试的质量与进度。如果把测试活动比作软件生命周期,测试需求就相当于软件的需求规格,测试策略在测试活动中相当于软 件的架构设计,测试用例相当于软件的详细设计,都是起到一个依据的作用。这样,也使得整个测试有据可循,流程更加严谨规范。

2.测试需求分析方法
2.3.1.1 测试需求收集
测试需求的收集主要通过对测试依据进行分析整理,最后生成一个以测试的观点出发的 思维导图,用来作为测试用例设计的主要工作内容。设计测试用例的检查要点包括需求的正确性、必要性、优先级、明确性、可测性、完整性、一致性、可修改性:在整个信息收集过程中,务必确保软件的功能与特性被正确理解。因此,测试需求分析人员 必须具备优秀的沟通能力与表达能力。当然,在书写测试用例之前,必须先进行用例评审,为了确保开发测试与需求的意见保持一致,参照此用例进行测试。
2.3.1.2 测试类型细化
考虑产品实际用户使用的场合及用户特点考虑哪些测试类型,除开功能测试外,还有自动化测试、性能要求、安全测试、软硬件兼容性等,此处需要从产品层面考虑,而不是从功能点 层面考虑。
对划分的每个测试类型进行细化。软件测试需求是开发测试用例的依据,测试需求分解得越 详细精准,对所有要进行的任务就越清晰,对测试用例的设计的帮助也越大,虽然每个公司对需求设计用例度的要求不同,但需求设计的详细程度是衡量测试覆盖度的重要指标。没有详细的测试需求就无法有效的统计软件测试覆盖度。最细化的设计方法是针对测试目的设计单一最小功能点来进行测试用例的设计,即每个测试项为一 个测试功能点。
但在实际情况中,可根据需求上线的紧急情况不同,进行灵活处理。如测试时间特别紧张可采用设计测试点来代替测试用例的方法。
2.3.1.3 生成测试需求思维导图
已细化的测试需求中,由于在提取时,可能存在着重复或冗余,需要不断进行优化和改善。删除测试需求中存在的重复的、冗余的含有关系的测试项。如果有类似的测试项,则需要对 其进行合并。最后生成质量优秀的测试用例结构,也称之为需求分析树。
建议使用思维导图进行书写,一目了然。
2.3.2 测试风险分析
由于我们在本文中所谈的测试是根据需求设计方面的内容,所以在此只谈软件测试用例设计所包含的风险,不包含其他风险。软件的输入、输出等在规则上存在一定的限制以及约束,另一方面虽然我们对测试用例进行了优化,但这还是不能保证测试需求不可能全面的覆盖,从而形成了一定的测试风险。测试需求 中必须对不分析或不测试部分形成的风险应提前抛出。
好了。有关冒烟测试我们就先说到这里,欢迎补充。

声明:本站所有文章资源内容,如无特殊说明或标注,均为采集网络资源。如若本站内容侵犯了原著者的合法权益,可联系本站删除。





