企业官网建设流程全解析

本文系统阐述了软件缺陷的定义、分类及管理流程。软件缺陷指在开发生命周期中导致产品未达预期的各类问题，包括功能缺失、错误、多余功能等。文章详细分析了缺陷产生原因（文档、设计、管理等），并指出并非所有缺陷都需要修复，需权衡时间、风险、成本等因素。重点介绍了缺陷发现方法（边界条件测试、状态转换测试等）、报告要素（编号、优先级、类型等）及编写规范。最后以共享单车扫码功能为例，展示了从正常到异常的系统性测试思路。全文强调缺陷管理的规范性、可追溯性和风险控制意识。

一、软件缺陷

1、软件缺陷的定义

指在软件开发生命周期中，由于设计、编码或测试阶段的错误或疏忽，导致软件产品未能满足预期功能、性能或用户需求的问题

1. 软件未实现产品说明书要求的功能；例如某个特定功能完全缺失——少功能
2. 软件出现了产品说明书指明不应该出现的错误；如将内部异常信息（Java Exception、404错误等）直接展示给终端客户——功能错误
3. 软件实现了产品说明书未提到的功能；可能带来额外测试负担和潜在风险——多功能
4. 软件未实现产品说明书虽未明确提及但应该实现的目标；如密码加密等及基础安全功能——隐性功能错误
5. 软件难以理解、不易使用、运行速度慢，或者软件测试员认为最终用户会认为不好——不易使用

注意：尚未发现或未观察到的软件缺陷只能说是潜在缺陷。

1.1 软件实现了产品说明书未提到得功能

风险分析：增加代码复杂度，提高出现缺陷的概率

可能泄露商业机密（如未发布的功能）

破坏产品说明书的严肃性和规范性

如要添加新功能处理流程：

必须提交文档bug单，要求更新产品说明书

禁止直接基于口头约定或主观判断开发功能

1.2 文档bug单和文档评审的区别

文档评审：针对未定稿的草稿文档进行意见收集，通常在文档发布前进行。评审的目的是发现潜在问题，确保文档的准确性、完整性和易读性。（相当于房屋交付前的整改；开发商负责）

文档bug单：针对已正式发布的文档提出修改要求，记录文档中的错误或缺陷，用户或测试人员发现错误后提交bug单，由相关人员修复。（房屋交付后的维修；需动用维修基金）

文档bug单针对已存在的问题，核心是问题追踪和修复。文档评审是预防性的，旨在提前发现问题。

1.3 文档修改后的标准流程

• 产品经理更新产品说明书

• 测试负责人重新安排测试计划

• 测试人员编写新测试用例

• 组织测试用例评审

• 执行正式测试

重点提醒：绝对禁止跳过测试用例编写直接测试，这是不规范的操作

2、为什么会出现软件缺陷

文档因素：产品说明书编写得不全面、不完整和不准确，而且经常更改，或整个开发组没有很好的沟通和理解

设计问题：软件设计过程中片面、多变、理解与沟通不足

管理压力：文档不足（如需求文档缺失）、进度压力（销售催促快速上线）

编码缺陷：设计、编码错误直接引入软件缺陷

实施错误：软件实施过程中安装、配置错误（如内存分配不当、端口配置错误，例如千兆端口误配为百兆）

3、并非所有软件缺陷都需要修复

3.1 无需修复的常见情况

时间限制：市场压力导致产品发行有时间要求

风险考量：修改影响模块较多，可能引发更大风险（选择遗留）

性价比低：修复成本远高于缺陷影响（如对客户影响小的次要问题）

重现困难：缺陷报告中问题难以复现（但严重问题仍需处理）

3.2 例题1：安装配置缺陷修复与否的讨论

修复决策：

常规情况：必须修复

特殊情形：若修复尝试多次无效/代价过高，改为在安装说明书中添加警告标记

替代方案：通过规范文档严格标注特殊配置要求替代代码修改

3.3 缺陷报告问题难重现的处理方式

处理原则：难复现并不是判断缺陷严重性的依据

严重问题的处理：

安排资深开发人员跟踪

采用代码走查、调试手段排查

实施优化措施（如添加异常保护机制）

4、如何发现软件缺陷

除了根据软件需求说明书写测试用例来发现缺陷外，可以尝试使用如下建议：

①查找时间依赖和竞争条件的问题（特定时间点的高并发场景，用户数特别多；如双十一购物节期间的用户登录、下单——通过压力测试模拟高峰时段用户行为）

②查找边界条件软件缺陷、内存泄漏和数据溢出缺陷

边界条件：系统在输入/输出边界值附近的行为异常，如 0 < X < 1023 时输入 1024

内存泄漏：程序关闭后未完全释放内存，可通过Windows任务管理器或Linux的free/top命令检测

数据溢出：类比1升杯子倒入1.2升水，强调数据类型范围

③查找状态转换时出现的缺陷

④查找资料依赖性：内存、网络、硬件等方面的缺陷

⑤查找和硬件相关方面的缺陷，比如硬件兼容性方面的缺陷

5、软件缺陷的核心内容

1. 缺陷的标题：描述缺陷的核心问题
2. 缺陷的预置条件：缺陷产生的前提
3. 缺陷的复现步骤：复现缺陷的过程
4. 缺陷的预期结果：希望得到的结果
5. 缺陷的实际结果：实际得到的结果
6. 缺陷的必要附件：图片、日志等信息（证据）

6、软件缺陷提交要素

①缺陷报告编号：缺陷的唯一标识

②严重程度：

• 严重（S1）：主功能
• 一般（S2）：次要功能
• 轻微（S3）：易用性、界面
• 建议（S4）：建议性问题

③优先级：24小时之内解决（P0）、发布前必须修复（P1）、可以在下一个版本中修复（P3）

④Bug类型：代码错误、兼容性问题、设计缺陷、性能问题

⑤缺陷状态：New（新建）、Open（打开）、Close（关闭）、Postponed：延期

7、软件缺陷类型

功能错误、界面（UI）页面错误、兼容性、数据（数据库）、易用性、改进建议、架构缺陷

8、报告软件缺陷的原则

尽快报告软件缺陷：

• 软件缺陷发现的越早，在进度中留下的修复时间就越多，该缺陷修复的可能性就越高；

有效描述软件缺陷：

• 只解释事实和演示、描述软件缺陷必需的细节；给出说明问题的一系列明确步骤；

在报告软件缺陷时不要做评价：

• 软件缺陷只针对产品，不针对具体的人，只陈述事实

对软件缺陷报告跟踪到底：

• 发现并报告了软件缺陷之后，继续监视其修复的全过程

每一个报告只针对一个软件缺陷

8、缺陷报告示例

8.1、缺陷提交注意事项

1. 可复现：缺陷可以复现
2. 规范性：符合公司或者项目要求
3. 唯一性：一个缺陷一个问题

8.2 缺陷编写规范

1. 准确：描述的信息是正确的
2. 具体：有细节且是真实特定的
3. 简洁易懂：描述简单容易理解
4. 次序清晰：描述缺陷过程有条件，有先后顺序

9、例题：共享单车扫码开车的测试点

思考框架：应从正常到异常、从简单到复杂、从常用到不常用的顺序进行系统思考

功能边界：明确测试范围仅限于软件功能本身，不包括硬件设计问题（如二维码位置、反光等）

完整性原则：需要考虑功能在各种条件下的表现是否符合预期

基本流程：打开软件——点击扫码——打开摄像头——扫码成功提示——开始成功提取单车

正常：

• 扫描成功：白天扫描

• 故障车辆：返回车辆故障，并提示推荐附近可用车辆

• 已预约车辆：返回车子已经被预约

• 正在被使用车辆：防止重复开锁，提示 " 车辆正在使用中 "

异常：

1）设备异常：

• 网络异常：2G/无网络时的降级处理

• 摄像头异常：包括硬件损坏和权限拒绝两种情况

• 服务端异常：应有超时机制和友好提示（服务端宕机）

2）二维码异常

• 部分损坏（10%损坏率）的识别能力

• 不同光线条件下的识别稳定性

3）业务异常：

• 防止同一账户同时开多辆车

• 避免多人同时扫描同一辆车