自学软件测试day3

本文系统阐述了软件缺陷的定义、分类及管理流程。软件缺陷指在开发生命周期中导致产品未达预期的各类问题包括功能缺失、错误、多余功能等。文章详细分析了缺陷产生原因文档、设计、管理等并指出并非所有缺陷都需要修复需权衡时间、风险、成本等因素。重点介绍了缺陷发现方法边界条件测试、状态转换测试等、报告要素编号、优先级、类型等及编写规范。最后以共享单车扫码功能为例展示了从正常到异常的系统性测试思路。全文强调缺陷管理的规范性、可追溯性和风险控制意识。目录一、软件缺陷1、软件缺陷的定义1.1 软件实现了产品说明书未提到得功能1.2 文档bug单和文档评审的区别1.3 文档修改后的标准流程2、为什么会出现软件缺陷3、并非所有软件缺陷都需要修复3.1 无需修复的常见情况3.2 例题1安装配置缺陷修复与否的讨论3.3 缺陷报告问题难重现的处理方式4、如何发现软件缺陷5、软件缺陷的核心内容6、软件缺陷提交要素7、软件缺陷类型8、报告软件缺陷的原则8、缺陷报告示例8.1、缺陷提交注意事项8.2 缺陷编写规范9、例题共享单车扫码开车的测试点一、软件缺陷1、软件缺陷的定义指在软件开发生命周期中由于设计、编码或测试阶段的错误或疏忽导致软件产品未能满足预期功能、性能或用户需求的问题软件未实现产品说明书要求的功能例如某个特定功能完全缺失——少功能软件出现了产品说明书指明不应该出现的错误如将内部异常信息Java Exception、404错误等直接展示给终端客户——功能错误软件实现了产品说明书未提到的功能可能带来额外测试负担和潜在风险——多功能软件未实现产品说明书虽未明确提及但应该实现的目标如密码加密等及基础安全功能——隐性功能错误软件难以理解、不易使用、运行速度慢或者软件测试员认为最终用户会认为不好——不易使用注意尚未发现或未观察到的软件缺陷只能说是潜在缺陷。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、软件缺陷的核心内容缺陷的标题描述缺陷的核心问题缺陷的预置条件缺陷产生的前提缺陷的复现步骤复现缺陷的过程缺陷的预期结果希望得到的结果缺陷的实际结果实际得到的结果缺陷的必要附件图片、日志等信息证据6、软件缺陷提交要素①缺陷报告编号缺陷的唯一标识②严重程度严重S1主功能一般S2次要功能轻微S3易用性、界面建议S4建议性问题③优先级24小时之内解决P0、发布前必须修复P1、可以在下一个版本中修复P3④Bug类型代码错误、兼容性问题、设计缺陷、性能问题⑤缺陷状态New新建、Open打开、Close关闭、Postponed延期7、软件缺陷类型功能错误、界面UI页面错误、兼容性、数据数据库、易用性、改进建议、架构缺陷8、报告软件缺陷的原则尽快报告软件缺陷软件缺陷发现的越早在进度中留下的修复时间就越多该缺陷修复的可能性就越高有效描述软件缺陷只解释事实和演示、描述软件缺陷必需的细节给出说明问题的一系列明确步骤在报告软件缺陷时不要做评价软件缺陷只针对产品不针对具体的人只陈述事实对软件缺陷报告跟踪到底发现并报告了软件缺陷之后继续监视其修复的全过程每一个报告只针对一个软件缺陷8、缺陷报告示例8.1、缺陷提交注意事项可复现缺陷可以复现规范性符合公司或者项目要求唯一性一个缺陷一个问题8.2 缺陷编写规范准确描述的信息是正确的具体有细节且是真实特定的简洁易懂描述简单容易理解次序清晰描述缺陷过程有条件有先后顺序9、例题共享单车扫码开车的测试点思考框架应从正常到异常、从简单到复杂、从常用到不常用的顺序进行系统思考功能边界明确测试范围仅限于软件功能本身不包括硬件设计问题如二维码位置、反光等完整性原则需要考虑功能在各种条件下的表现是否符合预期基本流程打开软件——点击扫码——打开摄像头——扫码成功提示——开始成功提取单车正常扫描成功白天扫描故障车辆返回车辆故障并提示推荐附近可用车辆已预约车辆返回车子已经被预约正在被使用车辆防止重复开锁提示 车辆正在使用中 异常1设备异常网络异常2G/无网络时的降级处理摄像头异常包括硬件损坏和权限拒绝两种情况服务端异常应有超时机制和友好提示服务端宕机2二维码异常部分损坏10%损坏率的识别能力不同光线条件下的识别稳定性3业务异常防止同一账户同时开多辆车避免多人同时扫描同一辆车