软件测试 | Assignment汇总

最新推荐文章于 2024-08-09 15:54:35 发布

卫龙女孩

最新推荐文章于 2024-08-09 15:54:35 发布

阅读量654

点赞数 1

分类专栏：软件测试

本文链接：https://blog.csdn.net/cat_xing/article/details/94205168

版权

本文详细介绍了软件测试中关于Assignment的内容，包括原型方法在分析和设计阶段的作用，风险管理和预防措施，以及在SDLC不同阶段的测试要素。分析了需求变更、进度、预算、技术等多个风险因素，并评估了敏捷开发原则对风险的影响。同时，讨论了测试生命周期中的需求、设计、编码、测试、安装和维护阶段的测试目标和内容，强调了正确性作为测试要素的重要性。

摘要由CSDN通过智能技术生成

Assignment 1

题目

在这里插入图片描述

辅助或代替分析阶段

在这里插入图片描述

初步需求 -> 分析 -> 原型方法循环【快速分析修改初步需求 -> 快速构造 -> 用户使用 -> 评价反馈 -> 根据反馈继续循环直到得到明确的需求说明】 -> 需求说明 -> 设计 -> 设计说明 -> 编码 -> 程序系统 -> 编码 -> 软件产品 -> 运行维护

辅助设计阶段

在这里插入图片描述

初步需求 -> 分析 -> 需求说明 -> 设计 -> 原型方法循环【快速分析修改不同系统架构 -> 快速构造 -> 用户使用 -> 评价反馈 -> 根据反馈继续循环直到得到合适的系统架构（设计说明）】 -> 设计说明 -> 编码 -> 程序系统 -> 编码 -> 软件产品-> 运行维护

代替分析与设计阶段

在这里插入图片描述

初步需求 -> 分析 -> 原型方法循环【快速分析修改不同系统架构 -> 快速构造 -> 用户使用 -> 评价反馈 -> 不断循环直到获得明确的需求与合适的系统架构】设计说明 -> 编码 -> 程序系统 -> 编码 -> 软件产品-> 运行维护

代替分析、设计和实现阶段

在这里插入图片描述

初步需求 -> 分析 -> 原型方法循环【快速分析修改初部需求、不同系统架构和不同的功能实现算法 -> 快速构造 -> 用户使用 -> 评价反馈 -> 不断循环直到获得明确的需求、合适的系统架构与性能较好的功能实现算法】-> 程序系统 -> 编码 -> 软件产品-> 运行维护

代替全部开发阶段

在这里插入图片描述

初步需求 -> 分析 -> 原型方法循环【快速分析修 -> 快速构造 -> 用户使用 -> 评价反馈 -> 循环直至得到合适的需求说明、设计说明和程序系统】-> 软件产品-> 运行维护

Assignment 2

题目

在这里插入图片描述

原则

在这里插入图片描述

风险

在这里插入图片描述

风险理解

需求变更风险

由于与客户沟通不畅、对客户的需求了解不足造成的风险，在软件开发项目整个生命周期的中都存在的风险

需求变更风险是指需求已经成为项目基准,但需求还在继续变化;需求定义欠佳,而进一步的定义会扩展项目范畴;添加额外的需求;产品定义含混的部分比预期需要更多的时间;在做需求中客户参与不够;缺少有效的需求变化管理过程。

进度风险、预算风险、管理能力风险、信息安全风险

由于管理人员素质不够，经验不足，沟通不畅，任务或其分配不合理，对项目的控制力度不够造成的各种风险

进度风险：有些项目对进度要求非常苛刻(进度要求不高的项目，我们同样要考虑该风险)，项目进度的延迟意味着违约或市场机会的错失。软件的工期常常是制约软件项目的主要因素。软件项目工期估算是软件项目初期最困难的工作之一。很多情况下，软件用户对软件的需求是出于实际情况的压力，希望项目承担方尽快开发出软件来。在软件招标时，开发方为了尽可能争取到项目，对项目的进度承诺出已远远超出实际能做到的项目进度，使项目在开始时就存在严重的时间问题。软件开发组织在工期的压力下，往往放弃文档的编写与更新，结果在软件项目的晚期大量需要通过文档进行协调时，却拖累软件进度越来越慢。此外，由于用户配合问题、资源调配等问题也可能使软件项目不能在预定的时间内完成任务。软件项目过程中有自身的客观规律性，用户对软件项目的进度要求不能与软件开发过程的时间需要相矛盾。

应用技术风险、质量控制风险、软件设计与开发工具风险、员工技能风险

由于技术力量不足，开发环境工具不足造成的风险

应用技术风险：在软件项目开发和建设的过程中，战略管理技术因素是一个非常重要的因素。项目组一定要本着项目的实际要求，选用合适、成熟的技术，千万不要无视项目的实际情况而选用一些虽然先进但并非项目所必须且自己又不熟悉的技术。如果项目所要求的技术项目成员不具备或掌握不够，则需要重点关注该风险因素。重大的技术风险包括：软件结构体系存在问题，使完成的软件产品未能实现项目预定目标;项目实施过程中才用全新技术，由于技术本身存在缺陷或对技术的在掌握不够深入，造成开发出的产品性能以及质量低劣。
质量控制风险：任何软件项目实施过程中缺乏质量标准，或者忽略软件质量监督环节都将对软件的开发构成巨大的风险。有些项目，用户对软件质量有很高的要求，如果项目组成员同类型项目的开发经验不足，则需要密切关注项目的质量风险。矫正质量低下的不可接受的产品,需要比预期更多的测试、设计和实现工作;开发额外的不需要的功能(镀金),延长了计划进度;严格要求与现有系统兼容,需要进行比预期更多的测试、设计和实现工作;要求与其他系统或不受本项目组控制的系统相连,导致无法预料的设计、实现和测试工作;在不熟悉或未经检验的软件和硬件环境中运行所产生的未预料到的问题;开发一种全新的模块将比预期花费更长的时间;依赖正在开发中的技术将延长计划进度。
软件设计与开发工具风险：软件项目开发和实施过程，所必须用到的管理工具、开发工具、测试工具等是否能及时到位、到位的工具版本是否符合项目要求等，是项目组需要考虑的风险因素。有些软件项目属于多用户并发的应用系统，系统对性能要求很高，这时项目组就需要关注项目的性能风险。

人力资源风险、政策风险、市场风险、营销风险

由于公司或项目组内外部环境变化所导致的风险

人力资源风险：软件的开发不同于其他的工程，它是智力密集型、劳动密集型、项目，受人员资源的影响很大。软件的开发在不同的工程阶段，需要的人员不同，同样需要团队成员之间的密切配合。在人力资源使用过程中，人员能力的表现往往体现在软件成果监控的困难导致对人员能力观察的困难。人员流失、人员不能适合软件项目的要求，都可造成人力资源上的风险。人力资源的能力(包括业务能力和技术能力)和素质，对项目的进展、项目的质量具有很大的影响，项目经理在项目的建设过程需要实时关注该因素。

如何预防风险

软件测试 | 预防风险

对敏捷开发原则的风险评估

选择第3条原则（经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期）进行评估。

需求变更风险
原则3能减轻该风险。用户的需求可能会随着时间而不断发生变化，尽快地交付软件能够促使项目双方人员以积极协作的心态开展工作，减少变更，确定进度。
进度风险
原则3能减轻该风险。尽可能早地交付软件，能够保证其中一个阶段的顺利完成，避免用户需求因为开发时间过长，受到市场影响而更改需求，对整个工程的进度造成影响。
预算风险
原则3能减轻该风险。开发周期越长，投入的人力物力也就越多，需要的经费也越大，因此开发的周期越短，越能够减少预算风险。
管理能力风险
原则3能减轻该风险。随着开发时间的增长，对软件各部分的功能、性能的管理也越来越复杂，对于项目的管理者的管理能力要求也越高，因此，尽早地交付软件能够有效地减少管理能力风险。
信息安全风险
原则3能减轻该风险。随着软件开发周期的增长，软件中潜在的漏洞也可能会增多，这时候如果包含有客户数据的重要信息，则可能会被有计谋者诡探进行攻击，造成损失。因此尽可能早地交付能够有效地减少信息安全风险。
应用技术风险
原则3能减轻该风险。软件开发周期的增长，可能面临着信息技术的革新，从而造成产品在一定程度上具有竞争劣势，或者由于需求变更，项目所需要使用到的实际应用技术可能在此前并没有包含在项目所需技术中，进而导致项目进度缓慢，甚至失败。因此尽早地交付产品，能够有效规避应用技术风险。
质量控制风险
一方面，软件开发周期的增长，必然会对质量的把控越来越难，因为软件规模也会随着周期的增长而不断增大，这时候对软件系统的质量把控变得更为复杂，需要工作人员的技术更加成熟，因此原则3能减轻该风险。

另一方面，为了保证软件的质量，有时需要进行比预期更多的测试、设计和实现工作，而较短的开发周期可能会导致放弃一些这方面的工作，因此原则3也可能带来质量控制风险。
软件设计与开发工具风险
原则3能减轻该风险。软件开发周期的增长，初始设计的一些缺陷与不足可能就会呈现出来，而且开发规模可能会与预期有所不同，而造成原有开发工具不能适应，因此如果能够缩短软件开发的周期，就能够有效规避软件设计与开发工具风险。
员工技能风险
原则3能减轻该风险。随着软件开发周期的增长，软件的规模不断增大，软件在继续开发，深度测试和系统分析方面对员工的能力要求也越来越大，如果员工的能力不能达到要求，就可能需要进行培训或者招募新的有能力的员工，而这些方面无不增加了软件开发的成本。
人力资源风险
原则3能减轻该风险。软件开发周期增长，在开发初期的员工可能会因为各种原因而离开，这时候造成的代码重新理解、客户接触者更替等问题，这时候对人力资源的管理也更加困难和复杂，因此尽可能快地交付软件能够有效地规避这种问题。
政策风险
原则3能减轻该风险。如果软件的开发周期过长，可能会因为政府的某些政策原因而导致最终的软件产品无法上线，这时候所有付出的资本都会流失，从而造成重大影响，因此尽可能早地交付软件，能够避免这些意外的发生。
市场风险
原则3能减轻该风险。如果软件的开发周期过长，那么市场对于当前软件产品的定位就可能会发生变化，这时候当前开发软件的价值可能就会减少，因此尽可能早地交付软件，能够有效地在最适应的市场发挥最大的价值。
营销风险
原则3能减轻该风险。如果软件的开发周期过长，那么由于市场需求的改变，对于营销者的压力也会明显增大，因为可能软件产品的竞争力与其他对手相比略有不足，在宣传力度上要花费的时间的金钱也越多，从而造成成本的增多，因此尽早地交付软件能够有效地避免这些事情的发生。

Assignment3 测试要素

题目

在这里插入图片描述

生命周期测试

在这里插入图片描述

测试要素

在这里插入图片描述

测试要素在 SDLC 不同阶段的测试内容

在这里插入图片描述

解答

选择的测试要素：正确性
软件作品：“挣闲钱”项目

需求阶段测试

目标
简单来说，需求阶段测试的目标就是保证需求分析的正确性和充分性。具体地说，需求阶段测试的目标则是保证需求正确反映出用户的需要，需求已经被定义和文档化，项目的花费和收益成正比，需求的控制被明确，有合理的流程可以遵循，有合理的方法可供选择。

对于“正确性”这一测试要素而言，这一阶段的目标是定义功能规格说明。
内容
提交了已定义的规格说明。

设计阶段测试

目标
在设计阶段，测试的任务是对设计进行评审，分析测试要素，给测试要素打分，当需求分析发生变化，设计文档也要修改，测试要对修改的部分进行检查，以保证设计和需求的一致性。

对于“正确性”这一测试要素而言，这一阶段的目标是设计符合需求。
内容

在概要设计阶段，组内的测试人员应阐述测试方法和测试评估标准，编写测试计划，安排具有里程碑的测试日程；
在详细设计阶段，测试人员要开发或获取确认支持工具，生成功能测试数据和测试用例，以此来检查设计中的缺漏情况、逻辑错误、模块接口不匹配、数据结构不合理、错误I/O假定、用户界面不充分等。从而保证设计符合需求。例如，需要检查学生端页面的设计是否能实现规定的功能，交易模块逻辑是否正确。

编码阶段测试

目标
对于“正确性”这一测试要素而言，这一阶段的目标是程序符合设计。
内容
通过测试工具如支持程序走查和检查的代码静态分析工具和支持单元“黑盒”测试和单元“白盒”测试的动态测试工具进行测试，测试程序是否符合设计。例如，测试学生接下并完成一次任务时，钱包余额是否符合设计。

测试阶段

目标
进行功能测试，运行部分或全部系统，确认用户的需求被满足。
内容
功能测试包括可靠性、文件完整性、审计追踪、功能正确性、互连等项测试，检验系统在各种环境和重复的事务条件下能否正确地执行系统的需求，控制计算机文件的完整性，追踪一个原始事务到总的控制，按用户规定的需求测试应用功能，与其他应用系统能否正确地通信。例如，对页面元素进行验证：字符限长，非法验证，非空校验，提示语，二次弹窗，非空集合等等。