软件生命周期中的测试1.1

知识点

解释在软件开发生命周期中开发活动和测试活动之间的关系

识别为什么软件开发生命周期模型必须适应项目周期和产品特性的原因

开发模型和测试

软件测试不是孤立存在的,测试活动与开发活动息息相关;

软件测试活动不仅仅包括测试执行,它应该贯穿于整个软件的生命周期之中;

不同的开发生命周期模型需要对应不同的测试阶段、测试活动和测试方法;

瀑布模型

软件生命周期中的测试1.1

瀑布模型的阶段

用户需求:用户需求一般由用户提出,系统人员或者产品市场人员从客户或将来的系统用户中收集原始项目的信息和要求;

需求分析:对用户需求进行可行性分析,并对用户需求和要求进行详细描述,并最终得到管理层和客户的批准。通过需求分析,定义了开发系统的目的和需要实现的特性和功能;

概要设计:明确系统的架构、系统的模块数量,以及各个模块之间的接口、数据结构,以及可能的网络环境支持和后台数据库等。简单地说,就是将需求映射到新系统的功能和框架上,从而可以对每个子系统进行独立的开发;

详细设计:细化概要设计的框架,定义每个子系统的任务、行为、内部结构以及与其他子系统的接口;

编码和实现:通过编程语言实现所有已经定义的单元,比如模块、单元和类等;

测试:作为开发周期的一个阶段,主要是指测试执行活动;

运行维护:软件系统或者产品发布,在用户中使用,以及根据反馈进行必要的维护活动;

瀑布模型的特点

软件测试是开发过程中的一个阶段,对产品质量进行的最后检查;

在客户需求明确,以及开发过程中没有频繁的需求变更,比较适合瀑布开发模型;

假如需求不明确,或者需求经常发生变更,采用瀑布模型是非常不适合的;

V模型

软件生命周期中的测试1.1

V模型的阶段

除了前面瀑布模型中介绍的用户需求、需求分析、详细设计、概要设计、编码和实现几个阶段之外,还强调了不同的测试级别概念;

单元测试:验证软件单元是否按照单元规格说明(详细设计说明)正确执行,即保证每个最小的单元能够正常运行。单元测试一般由开发人员来执行,首先设定最小的测试单元,然后通过设计相应的测试用例来验证各个单元功能的正确性;

集成测试:检查多个单元是否按照系统概要设计描述的方式协同工作。集成测试的主要关注点是系统能够成功编译,实现了主要的业务功能,系统各个模块之间数据能够正常通信等;

系统测试:验证整个系统是否满足需求规格说明;

验收测试:从用户的角度检查系统是否满足合同中定义的需求或者用户需求;

V模型的特点

V模型体现的主要思想是开发和测试同等重要,左侧代表的是开发活动,而右侧代表的是测试活动;

V模型针对每个开发阶段,都有一个测试级别与之相对应;

测试依旧是开发生命周期中的阶段,与瀑布模型不同的是,有多个测试级别与开发阶段对应;

V模型适用于需求明确和需求变更不频繁的情形;

V模型的验证和确认

验证Verification:通过检查和提供客观证据来证实指定的需求是否满足。也就是说,输入与输出之间的比较;

确认Validation:通过检查和提供客观证据来证实特定目的的功能或应用是否已经实现。在确认时,应考虑使用和应用的条件范围要远远大于输入时确定的范围;

软件生命周期中的测试1.1

非线性模型

软件生命周期中的测试1.1

需求是可变的:某些应用软件的需求与外部环境、公司经营策略或经营内容等密切相关,这些都是经常调整和变化的,因此需求也是变化的;

需求是模糊的:许多用户对他们的需求最初只是模糊的概念,想要求一个对需求只有初步设想的人准确无误地说出全部需求,显然是不切实际的;

用户和开发者难于沟通:大多数用户和领域专家不熟悉计算机和软件技术,而软件开发人员也往往不熟悉用户的专业领域,开发人员和用户之间很难做到完全沟通和相互理解,在需求分析阶段做出的用户需求常常是不完整、不正确的;

软件生命周期中的测试1.1

增量模型的特点

增量模型在每个阶段交付满足客户需求的一个子集的可运行产品。因此可以较好的适应变化,以及控制风险;

增量的一个缺点是后面并入的构件不能破坏已构造好的系统部分,这需要软件具备开放式的体系结构;

在开发过程中,需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于线性模型,但也很容易退化为边做边改模型,从而是软件过程的控制失去整体性;

迭代模型

软件生命周期中的测试1.1

迭代模型的特点

迭代模型包括了一系列的迭代,每一个迭代都包括了一些或者很多的开发活动(需求、分析、设计、实现等等);

每个后续的迭代都建立在前一个迭代的基础上以使系统得到发展和细化,直到最终产品被完成;

迭代模型中集成不是在项目的尾声进行的“大动作”,每一次迭代都以集成构建系统各部分结束,这样不断的积累将使日后的返工最小化;

开发模型的选择

在前期需求明确的情况下尽量采用瀑布模型或改进型的瀑布模型;

在用户无信息系统使用经验,需求分析人员技能不足情况下一定要借助原型;

在不确定性因素很多,或者需求不稳定的情况下,无法有效地进行计划的情况下,尽量采用增量迭代和螺旋模型;

资金和成本无法一次到位情况下可以采用增量模型,软件产品分多个版本进行发布;

对于完全多个独立功能开发可以在需求阶段就分功能并行,但每个功能内都应该遵循瀑布模型;

对于全新系统的开发必须在总体设计完成后再开始增量或并行;

对于编码人员经验较少情况下建议不要采用敏捷或迭代等生命周期模型;

增量、迭代和原型可以综合使用,但每一次增量或迭代都必须有明确的交付和出口准则;

什么是好的测试?

好的测试应该具备:

每个开发活动都有相对应的测试活动;

每个测试级别都有其特有的测试目标;

对于每个测试级别,需要在相应的开发活动过程中进行相应的测试分析和设计;

在开发生命周期中,测试人员在文档初稿阶段就应该参与文档的评审;

来源:竹涧科技

声明:本站部分文章及图片转载于互联网,内容版权归原作者所有,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!

上一篇 2021年10月17日
下一篇 2021年10月17日

相关推荐