尽管名称相似,软件开发生命周期 (SDLC) 和软件测试生命周期 (STLC) 是两种不同且截然不同的方法,可确保软件开发中的项目成功。让我们看看如何在您的软件开发项目中充分利用它们 -
软件开发生命周期 (SDLC) 是一个术语,指的是创建软件的过程。
根据 Winston Royce 博士于 1970 年发表的研究论文,软件开发生命周期 (SDLC) 是用于交付软件的线性过程序列。程序如下 -
采集要求
一旦发现组织应用环境中的差距或机会,就必须充分理解和记录业务需求,以便选择最佳解决方案。在此阶段,避免立即跳到解决方案的诱惑至关重要,利益相关者可能需要指导和帮助,以对他们可能已经拥有的任何解决方案偏好保持开放的态度。
在这一点上,确保当前的应用程序不满足或无法满足标准至关重要。通过收集需求和审查当前的应用程序组合,解决方案架构师、业务分析师和其他具有类似技能的人可以在此步骤中提供帮助。
在这一点上,与组织中的其他人联系以查看其他领域是否也需要已确定的或可比较的需求始终是一个好主意,以避免构建或采购重复的系统并允许重用系统。
此阶段的主要结果将是业务需求文档 (BRD),其中将包括所有必要功能的列表,可能会使用 MoSCoW(必须/应该/可能/现在不会)等方法进行优先排序,并使用按业务领域进行适当的可追溯性。
在对新计划的要求进行适当记录和批准后,可以开始设计工作。在这个阶段,企业应该考虑是否将他们的资源更好地用于构建自定义系统或从市场上购买东西。可能需要招标程序,例如投标请求 (RFP) 或信息请求 (RFI)。
一般来说,如果需要高度标准化的功能(例如,工资单、约会安排和电子销售点),通常最好为这些所谓的“记录系统”或“区分系统。” 这些系统被称为“创新系统”,当它们具有行业或组织独有的要求或提供提供竞争优势的能力时,它们更有可能适用于定制结构。
业务分析师和 UX 设计师可以在整个设计阶段进行协作,以开发系统外观的线框或模型。技术架构师和解决方案设计师可能会开始构建系统架构并做出技术堆栈、托管和编程语言决策,同时牢记组织当前的技能集和供应商。
设计阶段的主要输出将因每个系统而异,但它们很可能包括线框图、系统架构图、技术堆栈选择以及所需资源技能的指示。
软件开发人员在构建阶段将“需求”和“设计”阶段的输出转化为可用的软件。这可能包括创建前端、后端、数据库、微服务和各种其他组件。
该软件将被构建以提供需求文档中指定的功能,并且最好的项目将在整个阶段保持最终用户的参与,以确保正在构建的东西与最初陈述的需求紧密一致,因为有时构建的东西可以偏离这一点。
测试分析师将在整个测试过程中对程序执行各种验证测试,包括性能测试、负载测试和探索性手动测试。主要目标是确保在构建阶段完成的工作具有足够高的质量,以承受在正常操作设置下对系统的要求,并弄清楚当超过这些标准时会发生什么.
用户验收测试现在可以开始验证系统的行为是否符合需求收集阶段的既定期望,而在构建阶段用户和开发团队之间的紧密协作可以帮助最大限度地减少返工并消除意外。
该程序被放入所需的生产环境和平台中,并在部署阶段运行。这些环境可以是公司数据中心的实际服务器,也可以是越来越流行的云托管平台。
最终用户培训预计将在此阶段开始,以确保每个人都了解如何使用新系统,并且将完成从先前遗留系统的任何数据传输,以避免需要“双重密钥”。
与将在“一切照旧”状态下支持和维持系统的团队的讨论应该已经开始,并且在整个培训阶段应该考虑到这些团队,以确保他们能够支持系统项目组已经解散。
该系统将移交给团队,该团队将在维护阶段为其在公司的余生提供支持。为了让服务台运算符知道如何向适当的团队发送用户支持查询,需要开发适当的文档和帮助文件。
系统的增强和更改可能会随着时间的推移而进行,例如,如果发现新的需求或如果发生监管变化等外部因素,则必须考虑这样做的方法,即是否保留内部资源来使此类更改,或者这些更改是否会临时外包给外部供应商。
查看我们的帖子,了解有关软件开发生命周期的更多信息以及如何扩展它以确保安全性贯穿始终:[实用指南] 安全软件开发生命周期。
软件测试生命周期 (STLC) 是一种方法,可确保从系统开发的开始到结束都实施充分、彻底、严格的测试。它分为五个阶段,如下 -
需求分析
测试团队检查在 SDLC 需求阶段准备的业务需求文档 (BRD),以便在需求分析阶段识别新系统所需的重要成果和功能。
测试团队将与关键利益相关者和业务分析师一起检查 BRD,以确保每个人都了解正在创建的内容以及它应该如何工作。他们还应考虑系统的业务关键性以及任何适用的监管要求,以确保满足任何合规性需求。
一旦功能和后果已知,测试团队将能够计划他们将如何实施他们的测试。他们将为项目创建一个测试策略文档,概述他们将如何使用可用的不同技术,包括手动、自动化、集成和单元测试。他们可能会开始列出需要编写的确切测试用例或脚本,以验证系统是否经过彻底测试。
在定义了高级测试用例和方法之后,可以开始使用更多信息充实测试脚本,例如需要评估的个人用户体验,无论是从快乐路径还是从边缘案例的角度来看。
测试环境的设置
在建立了系统的可行版本之后,测试团队可以开始构建一个与生产和开发环境不同的合适的测试环境。在这个测试环境中,他们将确保建立了正确的用户配置文件、正确的用户登录凭据和足够的测试数据来运行他们的脚本。
测试的执行和结束
最后,在建立稳定的环境后,测试团队执行他们准备的脚本并将他们的发现报告给项目团队和利益相关者。当项目团队处理结果然后重新测试它们时,可能需要多次执行此步骤和其他步骤。
下表突出显示了 SDLC 和 STLC 之间的主要区别。
因素 | SDLC | STLC |
---|---|---|
Title | 软件交付生命周期是用于描述软件交付方式的术语。 | Lifecycle of Software Testing |
概括 | 关心开发软件 | Concerned about software testing |
客观的 | 确定软件系统构建良好。 | Ensure that software systems are well tested. |
阶段 | 需求设计、构建、测试、部署和维护 | Analyze the requirements Planning the development of tests Execution and closure of the environment |
相关人员 | 整个项目团队 | Testers/QA Engineer |
输出 | 可以使用的软件系统 | 经过全面测试的软件系统 |
总而言之,SDLC 和 STLC 是两个不同但互补的程序,在开发新系统时必须同时解决。
SDLC 参与新系统的开发,而 STLC 只关心它们的测试。
SDLC 是一个线性过程,可确保您设计和构建正确的系统,但 STLC 是一种技术,可让您彻底测试已开发的内容。
尽管 STLC 是一种独立的测试方法,但这并不排除在 SDLC 中包含质量保证。STLC 不是优秀设计的替代品或开发不良的补救措施;质量应该嵌入到软件中,而不是“测试出来”。
任何成功的新软件系统几乎肯定会包括 SDLC 和 STLC。
SDLC 以分阶段和系统的方式提供定义明确的软件项目。STLC 可以对此类计划进行彻底测试,以验证它们是否有效、可靠和有用。