摘要本文系统梳理了软件开发的核心流程与测试基础。首先明确区分了用户需求与软件需求通过网上书店案例展示了需求分析过程。接着详细介绍了软件生命周期需求分析、设计、编码、测试、交付、维护及四大主流开发模型瀑布模型线性流程、螺旋模型强调风险分析、增量/迭代模型分块开发与持续优化以及敏捷模型小步快跑、持续交付。文章还阐述了Bug的定义、等级划分及其从新建到关闭的全生命周期管理流程。最后从测试角度讲解了白盒测试静态/动态含六种覆盖方法与黑盒测试的区别以及按测试阶段划分的单元测试、集成测试、系统测试和回归测试。全文强调测试应贯穿开发全程不同模型适用于不同项目规模敏捷方法能有效应对需求变更。目录目录一、两种需求具体例子一个“网上书店”系统二、开发模型1.软件开发的生命周期2.开发模型1瀑布模型2螺旋模型3增量模型与迭代模型4敏捷模型三、Bug1.Bug的定义2.Bug的生命周期1bug的等级2提交bug3bug的修复流程四、测试分类1.白盒测试2.黑盒测试3.测试阶段总结一、两种需求实际工作中通常听到两种需求“用户需求”和“软件需求”。用户需求用户基于需要用自然语言或图表等提出的需求重点是没有经过合理评估的。软件需求根据用户需求进行合理分析后技术可行性、成本投入、市场可行性、收益情况判断用户需求是否合理若合理则详细描述实现这些需求必须的功能、性能、约束等。软件需求是开发、测试的依据。具体例子一个“网上书店”系统用户需求“作为购书者我希望系统能根据我的历史购买和浏览记录在我下次登录时直接在首页向我推荐我可能感兴趣的新书这样我就不用每次都去搜索了。”用户这个需求就很模糊什么是“感兴趣”“推荐”以什么形式呈现软件需求需求分析细化后功能需求首页新增个性化推荐区用户登录后系统应在首页顶部展示一个标题为“猜你喜欢”的推荐栏。推荐逻辑推荐算法需基于用户近90天的购买、加入购物车、收藏及浏览超过10秒的商品数据与商品标签如“悬疑”、“刘慈欣”、“豆瓣8分以上”进行匹配。展示规则该栏目每次展示6本图书包括封面、书名、作者和价格。如果匹配到的图书不足6本则用网站当前热销榜的图书补齐。刷新频率用户每次刷新首页或重新登录时推荐结果应更新。非功能需求性能要求推荐栏的加载时间不应超过2秒不能拖慢首页整体加载。准确性推荐图书与用户兴趣标签的匹配准确率应达到85%以上需后台数据统计验证。一句话总结用户需求定义了“做什么事”而软件需求定义了“正确地做事”。二、开发模型1.软件开发的生命周期如同生物软件也有自己的生命周期大致可分为需求分析——整体计划——系统设计——编码——测试——交付——维护下面总结每个阶段的任务与产出需求分析做什么搞清楚用户到底要什么系统要完成什么功能达到什么性能。产出用户需求和软件需求规格说明书。整体计划做什么对各个需求或功能进行规划多长时间完成该需求以及每段时间具体完成哪些功能。产出计划文档。系统设计做什么根据软件需求设计出整个大任务的“建筑图纸”分为概要设计和详细设计。概要设计架构设计任务设计系统整体结构、模块划分、数据库、接口等宏观方案。产出概要设计说明书、架构图、数据库设计图。详细设计任务将每个模块细化到类、函数、数据结构层面描述内部具体逻辑。产出详细设计说明书、伪代码。编码任务根据详细设计编写代码实现各模块功能并进行单元测试确保功能正确。产出程序源码、单元测试用例与报告、可部署的程序包。测试任务将软件作为整体验证它是否满足需求规格找出缺陷。包含单元测试、集成测试、系统测试、验收测试。产出测试计划、测试用例、测试报告、缺陷报告。交付任务将经过测试的软件交付给用户或发布上线。产出部署手册、用户手册、交付验收单。维护任务上线后持续运行保障修复缺陷进行适应性修改或功能增强。产出维护记录、变更报告、软件升级包。值得注意的是测试活动贯穿整个软件生命周期而不是最后才做防止最后的错误导致的全体反工。2.开发模型什么是开发模型把软件生命周期中“做什么、怎么做、何时做”的组织方式固定下来的一种工作套路或框架。它规定了开发活动分析、设计、编码、测试、交付等的顺序、阶段划分和流转规则目的是让软件开发过程更有条理、效率更高、风险更可控。1瀑布模型瀑布模型是最经典的成熟的可用模型他的特点是每个流程只执行一次如流水从高到低整体是线性的开发流程不能逆行。瀑布模型最大的缺陷在于①测试后置。前各个阶段产生的问题直到测试才被发现导致大面积的返工。②周期太长。最终交付产品得等到最后才被看到可能导致需求过时。综上瀑布模型适合用在需求固定得小项目开发中。2螺旋模型相较于瀑布模型螺旋模型在瀑布模型的每个阶段都增加了风险分析以减少前面各阶段的遗留问题避免出现大面积反工。但这些新增加的风险分析也增加了开发成本耗时耗力。螺旋模型的特点是每个阶段都增加风险分析以实现全过程的风险管控强调各个阶段的开发质量但耗时耗力。螺旋模型适合大型的、复杂的、风险大的开发项目。3增量模型与迭代模型增量模型就是将大需求拆分成各个小功能每个小功能独立开发交付上线。迭代模型是从一个不完善的版本开始经过多轮反馈和修改不断改进同一套功能的质量和深度。增量模型和迭代模型在实际开发中常互相配合着去使用。增量模型是逐块建造而迭代模型是在原基础上精益求精。增量模型和迭代模型常用于大型且需求不明确的项目开发。4敏捷模型实际开发中经常中途收到需求变更或者功能合并等请求。为减少返工的开发时间与成本经过不断摸索实现了敏捷模型。敏捷模型又分为多种常用的是迭代式增量软件开发模型即将增量模型与迭代模型混合使用每个增量模块都在迭代中开发。它的核心原理小步快跑持续交付。比如做一款手机App不是先花半年写好100页需求再花一年开发完所有功能最后测试上线。而是把产品切成多个版本。第一个周期只专注做“用户登录和浏览商品”这个最小功能模块做出一个能跑的原型。第二个周期再在上面增加“搜索和下单”功能。每个周期结束都有东西可以展示、获得反馈。迭代式增量软件开发模型总体由三种角色和五个会议组成三个角色产品经理、项目经理、研发团队。五个会议项目计划会议、迭代梳理会议、每日站会、演示会议、回顾会议。项目规划会内容产品负责人讲解优先级最高的需求团队评估工作量一起确定“这个冲刺我们要完成哪些任务”。产出当前迭代的待办列表和迭代目标。迭代梳理会议内容团队与产品负责人一起对未来的需求进行细化、估算优先级。目的确保需求清单总是清晰有序为下次迭代规划做好准备。每日站会内容每天必开团队站着回答三个问题昨天做了什么今天要做什么遇到什么障碍目的同步进展暴露问题不是汇报工作。演示会议内容开发结束时团队向产品负责人、用户等干系人现场演示已完成的功能。目的获取反馈判断是否完成了冲刺目标。这是检验“增量”的会议。回顾会议内容评审会之后团队内部闭门复盘。讨论哪些做得好哪些可以改进并制定出具体改进计划。目的提升团队效能和幸福感。这是检验“迭代过程”本身的会议。以炒菜为例帮助理解三、Bug1.Bug的定义通常bug的可分成两类1.规格需求文档中存在且正确的需求程序与之不匹配的错误。2.需求文档中没有提到的功能以用户需求为准当软件没有实现用户预期的功能时就是bug。2.Bug的生命周期1bug的等级2提交bug提bug的基本要素包括问题出现的版本、环境问题复现的步骤、预期结果与实际结果。3bug的修复流程New新建Assigned分配架构师指派给负责“调味算法”的开发工程师。Fix修复开发排查原因发现是硬编码修改代码本地自测通过。Resolved已解决提交代码合并到当前迭代分支并备注根本原因为“编码逻辑缺陷”。Verified已验证测试员在下一轮迭代确认修复关闭该Bug。Closed关闭/Reopen重开如果改完发现错误仍在则状态回退为Reopen进入下一次迭代继续处理——这正是迭代式开发容忍变更、快速纠错的价值所在。四、测试分类1.白盒测试白盒测试分为静态测试和动态测试。“静”与“动”指的是是否运行代码其中静态测试就是不运行被测软件而是静态的检查程序代码、界面、文档等内容中可能存在错误的地方。而动态测试指的是实际运行被测试的软件输入相关数据并检查得出的结果与预期是否相符合。动态测试方法主要为六种语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。语句覆盖顾名思义这次测试检查的是被测软件中的所有代码是否能都执行到比如一些 if-else、switch语句等。判定覆盖代码中的if-else语句要测试这两条语句是否都能执行覆盖到即if为true时能执行为false时也能执行。条件覆盖若if-else或者switch中采用的是表达式语句形如A and/or B…那么需要设计测试用例让每个原子条件即A或B等的真假都出现至少一次。判定条件覆盖设计测试用例同时满足“判定覆盖”和“条件覆盖”。即每个判定的真/假都要出现且每个原子条件的真/假也都要出现。条件组合覆盖设计测试用例让每个判定内部的所有原子条件组合都至少出现一次。如对于A and B共有 4 种组合(T,T)、(T,F)、(F,T)、(F,F)。路径覆盖设计测试用例覆盖程序中从起点到终点的所有可能逻辑路径把程序流程图里的每一条分支路线都走一遍。2.黑盒测试顾名思义⿊盒测试就是在完全不考虑程序逻辑和内部结构的情况下“两眼一黑”的只检查系统功能是否按照需求规格说明书的规定正常使⽤、是否能适当的接收输⼊数据⽽输出正确的结果满足规范需求。所以黑盒测试需要从用户角度出发设计测试用例要站在用户的角度想会用到哪些功能会遇到哪些问题。黑河测试的测试⽤例是基于软件需求开发⽂档 黑盒测试⽤到的测试⽅法有等价类边界值场景法经验法等。3.测试阶段按照测试阶段分整个测试又分为单元测试、集成测试、系统测试、回归测试。单元测试测的是软件中最小的、不可再分的代码单元即在不依赖其他模块的情况下测单个函数的输入输出是否正确。集成测试测多个单元/函数/模块组装在一起后的接口和交互测模块之间的数据传递、API调用、消息队列、数据库连接是否通畅正常。系统测试模拟真实用户环境测整个完整的软件/硬件系统是否正常测整个开发任务的业务流程是否正确以及非功能性需求性能、安全、兼容性、易用性。这常用到设计的六大维度功能/界面/性能等。回归测试在旧版本代码上添加新功能后要测试以前的功能是否正常确保修改了代码修Bug或加新功能之后没有把以前正常的功能搞坏即“引入新缺陷”。总结本文探讨了软件开发中的核心概念与实践。首先区分用户需求与软件需求指出前者是用户模糊表达后者需经可行性分析转化为具体功能要求。其次详解软件生命周期需求分析、设计、编码、测试等及主流开发模型瀑布模型线性流程、螺旋模型强调风险分析、增量/迭代模型分块开发与持续优化以及敏捷模型小步快跑。特别说明敏捷开发通过角色分工产品/项目经理、研发和五大会议计划会、站会等实现快速响应变更。最后阐述Bug的定义、分级标准崩溃/严重/一般/建议及其全生命周期管理流程新建→分配→修复→验证→关闭。全文强调测试应贯穿开发全程不同模型适用于不同规模项目而敏捷方法能有效应对需求变更。