测试 认识bug

一、软件测试生命周期与测试模型

 

1. 软件（开发）生命周期：包括需求分析、计划、设计、编码、测试、运行维护阶段。需求分析是起始点，明确用户需求，后续阶段依此展开 。例如开发电商软件，需求分析阶段确定商品展示、购物车、支付等功能需求，后续阶段围绕实现这些需求推进 。

2. 测试模型

- V模型：以用户需求为起点，需求分析与系统、概要设计、详细设计、编码逐步推进，对应验收测试、系统测试、集成测试、单元测试。明确标注测试过程，但缺点是将测试置于编码之后，发现问题修改成本高 。比如开发管理系统，按V模型，编码完成才开始测试，若此时发现需求理解偏差，修改涉及多阶段 。

- W模型（双V模型）：解决V模型测试后置问题，开发和测试并行。需求分析与设计阶段有测试准备，各开发阶段都有对应测试阶段。但存在缺点，将需求、设计等活动视为串行，难以支持敏捷开发 。如敏捷开发模式下，需求常动态变化，W模型难适应 。

 

二、BUG相关

 

1. bug概念：指计算机程序中错误、缺陷、疏忽或故障，使程序无法正确运行，源于源代码或程序设计阶段失误 。比如除法运算代码中未处理除数为0情况，运行时会报错，这就是bug 。

2. 描述bug的要素：包括问题出现的版本、环境、步骤、预期结果、实际结果。明确要素可提高沟通效率，避免模糊描述。例如“在谷歌浏览器版本135.0.7049.43（64位） 、Windows11家庭版环境下，打开chrome浏览器，输入网址http://xxxxxxxx ，切换到第一个banner，预期小程序码不被遮挡可扫描，实际小程序码被登录窗口遮挡无法扫描” 。

3. bug级别：一般分崩溃、严重、一般、次要。划分意义在于评估程序员开发能力、确定年终奖挂钩、安排修复顺序、反映测试人员能力。例如程序员A开发的软件中严重bug少，相比程序员B开发能力可能更优 。

4. bug的生命周期：测试人员创建bug（new ），开发人员确认是否有效，无效则拒绝（Rejected ），有效则打开（open ） 。根据优先级和时间判断是否立即修改，不立即修改则延迟（Delay ），修改后为已修复（Fixed ），测试人员验证，验证通过关闭（closed ），未通过重新打开（Reopen ） 。

5. 与开发产生争执的解决办法

- 先检查自身bug描述是否清晰。比如描述“浏览器打开链接失败”就不清晰，应明确浏览器、版本、链接及失败表现等 。

- 站在用户角度抛问题。如某功能操作复杂影响用户体验，从用户角度指出 。

- BUG定级要有依据。通过bug描述文档确认级别 。

- 提高自身技术和业务水平，能提问题也能给解决方案。如发现数据保存失败，可建议修改数据表字段格式 。

- 必要时进行bug评审，由测试、开发、产品代表参与，解决bug处理方式及分析原因等 。

 

三、测试用例相关

 

1. 测试用例概念：为实施测试向被测系统提供的一组集合，包含测试环境、操作步骤、测试数据、预期结果等要素。例如测试登录功能，测试环境为某浏览器和系统版本，操作步骤是输入用户名和密码点击登录，测试数据为具体用户名和密码，预期结果是成功登录或提示错误 。

2. 设计测试用例的方法

- 基于需求的设计方法：依据软件需求设计用例，确保覆盖需求功能 。如电商软件需求有商品搜索功能，设计用例包含不同关键词搜索、搜索结果展示等测试 。

- 具体的设计方法：包括等价类、边界值、判定表法、正交法、场景法、错误猜测法等 。比如边界值法，测试电商软件购物车添加商品数量，测试0、最大限制数量及临界值 。