企业官网建设流程全解析

摘要：本文系统梳理了软件开发的核心流程与测试基础。首先明确区分了用户需求与软件需求，通过网上书店案例展示了需求分析过程。接着详细介绍了软件生命周期（需求分析、设计、编码、测试、交付、维护）及四大主流开发模型：瀑布模型（线性流程）、螺旋模型（强调风险分析）、增量/迭代模型（分块开发与持续优化）以及敏捷模型（小步快跑、持续交付）。文章还阐述了Bug的定义、等级划分及其从新建到关闭的全生命周期管理流程。最后，从测试角度讲解了白盒测试（静态/动态，含六种覆盖方法）与黑盒测试的区别，以及按测试阶段划分的单元测试、集成测试、系统测试和回归测试。全文强调测试应贯穿开发全程，不同模型适用于不同项目规模，敏捷方法能有效应对需求变更。

目录

目录

一、两种需求

具体例子：一个“网上书店”系统

二、开发模型

1.软件开发的生命周期

2.开发模型

1）瀑布模型

2）螺旋模型

3）增量模型与迭代模型

4）敏捷模型

三、Bug

1.Bug的定义

2.Bug的生命周期

1）bug的等级

2）提交bug

3）bug的修复流程

四、测试分类

1.白盒测试

2.黑盒测试

3.测试阶段

总结

一、两种需求

实际工作中通常听到两种需求：“用户需求”和“软件需求”。

用户需求：用户基于需要，用自然语言或图表等提出的需求，重点是没有经过合理评估的。

软件需求：根据用户需求进行合理分析后（技术可行性、成本投入、市场可行性、收益情况），判断用户需求是否合理，若合理则详细描述实现这些需求必须的功能、性能、约束等。软件需求是开发、测试的依据。

具体例子：一个“网上书店”系统

用户需求：

“作为购书者，我希望系统能根据我的历史购买和浏览记录，在我下次登录时，直接在首页向我推荐我可能感兴趣的新书，这样我就不用每次都去搜索了。”

用户这个需求就很模糊：什么是“感兴趣”？“推荐”以什么形式呈现？

软件需求（需求分析细化后）：

1. 功能需求：

   • 首页新增个性化推荐区：用户登录后，系统应在首页顶部展示一个标题为“猜你喜欢”的推荐栏。

   • 推荐逻辑：推荐算法需基于用户近90天的购买、加入购物车、收藏及浏览超过10秒的商品数据，与商品标签（如“悬疑”、“刘慈欣”、“豆瓣8分以上”）进行匹配。

   • 展示规则：该栏目每次展示6本图书，包括封面、书名、作者和价格。如果匹配到的图书不足6本，则用网站当前热销榜的图书补齐。

   • 刷新频率：用户每次刷新首页或重新登录时，推荐结果应更新。

2. 非功能需求：

   • 性能要求：推荐栏的加载时间不应超过2秒，不能拖慢首页整体加载。

   • 准确性：推荐图书与用户兴趣标签的匹配准确率应达到85%以上（需后台数据统计验证）。

一句话总结：用户需求定义了“做什么事”，而软件需求定义了“正确地做事”。

二、开发模型

1.软件开发的生命周期

如同生物，软件也有自己的生命周期，大致可分为：

需求分析——整体计划——系统设计——编码——测试——交付——维护

下面总结每个阶段的任务与产出：

需求分析

• 做什么：搞清楚用户到底要什么，系统要完成什么功能，达到什么性能。

• 产出：用户需求和软件需求规格说明书。

整体计划

• 做什么：对各个需求或功能进行规划，多长时间完成该需求，以及每段时间具体完成哪些功能。

• 产出：计划文档。

系统设计

• 做什么：根据软件需求设计出整个大任务的“建筑图纸”，分为概要设计和详细设计。

• 概要设计（架构设计）

  • 任务：设计系统整体结构、模块划分、数据库、接口等宏观方案。

  • 产出：概要设计说明书、架构图、数据库设计图。

• 详细设计

  • 任务：将每个模块细化到类、函数、数据结构层面，描述内部具体逻辑。

  • 产出：详细设计说明书、伪代码。

编码

• 任务：根据详细设计编写代码，实现各模块功能，并进行单元测试确保功能正确。

• 产出：程序源码、单元测试用例与报告、可部署的程序包。

测试

• 任务：将软件作为整体，验证它是否满足需求规格，找出缺陷。包含单元测试、集成测试、系统测试、验收测试。

• 产出：测试计划、测试用例、测试报告、缺陷报告。

交付

• 任务：将经过测试的软件交付给用户或发布上线。

• 产出：部署手册、用户手册、交付验收单。

维护

• 任务：上线后持续运行保障，修复缺陷，进行适应性修改或功能增强。

• 产出：维护记录、变更报告、软件升级包。

值得注意的是：测试活动贯穿整个软件生命周期，而不是最后才做，防止最后的错误导致的全体反工。

2.开发模型

什么是开发模型？

把软件生命周期中“做什么、怎么做、何时做”的组织方式固定下来的一种工作套路或框架。它规定了开发活动（分析、设计、编码、测试、交付等）的顺序、阶段划分和流转规则，目的是让软件开发过程更有条理、效率更高、风险更可控。

1）瀑布模型

瀑布模型是最经典的成熟的可用模型，他的特点是：每个流程只执行一次（如流水从高到低），整体是线性的开发流程，不能逆行。

瀑布模型最大的缺陷在于：

①测试后置。前各个阶段产生的问题直到测试才被发现，导致大面积的返工。

②周期太长。最终交付产品得等到最后才被看到，可能导致需求过时。

综上，瀑布模型适合用在需求固定得小项目开发中。

2）螺旋模型

相较于瀑布模型，螺旋模型在瀑布模型的每个阶段都增加了风险分析，以减少前面各阶段的遗留问题，避免出现大面积反工。但这些新增加的风险分析也增加了开发成本，耗时耗力。

螺旋模型的特点是：每个阶段都增加风险分析以实现全过程的风险管控，强调各个阶段的开发质量，但耗时耗力。

螺旋模型适合大型的、复杂的、风险大的开发项目。

3）增量模型与迭代模型

增量模型就是将大需求拆分成各个小功能，每个小功能独立开发交付上线。

迭代模型是从一个不完善的版本开始，经过多轮反馈和修改，不断改进同一套功能的质量和深度。

增量模型和迭代模型在实际开发中常互相配合着去使用。增量模型是逐块建造，而迭代模型是在原基础上精益求精。

增量模型和迭代模型常用于大型且需求不明确的项目开发。

4）敏捷模型

实际开发中，经常中途收到需求变更或者功能合并等请求。为减少返工的开发时间与成本，经过不断摸索实现了敏捷模型。

敏捷模型又分为多种，常用的是迭代式增量软件开发模型，即将增量模型与迭代模型混合使用，每个增量模块都在迭代中开发。它的核心原理：小步快跑，持续交付。

比如做一款手机App：不是先花半年写好100页需求，再花一年开发完所有功能，最后测试上线。而是把产品切成多个版本。第一个周期，只专注做“用户登录和浏览商品”这个最小功能模块，做出一个能跑的原型。第二个周期，再在上面增加“搜索和下单”功能。每个周期结束，都有东西可以展示、获得反馈。

迭代式增量软件开发模型总体由三种角色和五个会议组成：

三个角色：产品经理、项目经理、研发团队。

五个会议：项目计划会议、迭代梳理会议、每日站会、演示会议、回顾会议。

1. 项目规划会

   • 内容：产品负责人讲解优先级最高的需求，团队评估工作量，一起确定“这个冲刺我们要完成哪些任务”。

   • 产出：当前迭代的待办列表和迭代目标。

2. 迭代梳理会议

   • 内容：团队与产品负责人一起，对未来的需求进行细化、估算优先级。

   • 目的：确保需求清单总是清晰有序，为下次迭代规划做好准备。

3. 每日站会

   • 内容：每天必开，团队站着回答三个问题：昨天做了什么？今天要做什么？遇到什么障碍？

   • 目的：同步进展，暴露问题，不是汇报工作。

4. 演示会议

   • 内容：开发结束时，团队向产品负责人、用户等干系人现场演示已完成的功能。

   • 目的：获取反馈，判断是否完成了冲刺目标。这是检验“增量”的会议。

5. 回顾会议

   • 内容：评审会之后，团队内部闭门复盘。讨论哪些做得好，哪些可以改进，并制定出具体改进计划。

   • 目的：提升团队效能和幸福感。这是检验“迭代过程”本身的会议。

以炒菜为例，帮助理解：

三、Bug

1.Bug的定义

通常bug的可分成两类：

1.规格需求文档中存在且正确的需求，程序与之不匹配的错误。

2.需求文档中没有提到的功能，以用户需求为准：当软件没有实现用户预期的功能时就是bug。

2.Bug的生命周期

1）bug的等级

2）提交bug

提bug的基本要素包括：问题出现的版本、环境，问题复现的步骤、预期结果与实际结果。

3）bug的修复流程

1. New（新建）

2. Assigned（分配）：架构师指派给负责“调味算法”的开发工程师。

3. Fix（修复）：开发排查原因（发现是硬编码），修改代码，本地自测通过。

4. Resolved（已解决）：提交代码合并到当前迭代分支，并备注根本原因为“编码逻辑缺陷”。

5. Verified（已验证）：测试员在下一轮迭代，确认修复，关闭该Bug。

6. 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的定义、分级标准（崩溃/严重/一般/建议）及其全生命周期管理流程（新建→分配→修复→验证→关闭）。

全文强调测试应贯穿开发全程，不同模型适用于不同规模项目，而敏捷方法能有效应对需求变更。