您的位置: 首页  >  文章  >  软件测试基本概念

软件测试基本概念

分类: 文章 • 2022-10-28 22:36:41
  1. 什么是需求
    满足用户的期望或者规定的文档（合同，标准，规范）所需要的条件和权能，包含用户需求和软件需求
  2. 什么是bug
    （1）当且仅当规格说明（软件需求）是存在的并且正确，程序与规格说明之间的不匹配，才是软件缺陷。
    （2）当没有需求规格说明书时，判断标准以最终用户需求为准，当程序没有实现其最终用户合理预期的功能要求时，就是软件缺陷。
  3. 什么是测试用例
    测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境（软件，硬件）、操作步骤、测试数据、预期结果等要素，还有标题，测试模块，重要性，前提条件等
    例：网易邮箱登陆测试用例
    软件测试基本概念
  4. 软件开发模型
    软件生命周期：指从软件产品的设想开始到软件不再使用而结束的时间。 如果把软件看成是有生命的事物，那么软件的生命周期可以分成6个阶段，即需求分析、计划、设计、编码、测试、运行维护。
    （1）瀑布模型：适合需求稳定的项目
    （2）螺旋模型：适合项目庞大，前期需求不是很明确，风险比较大的
    （3）增量，迭代：例如：系统有A、B、C、D四个业务模块，2周时间
    增量模型：第一周完成A、B两个功能模块，第二周完成C、D两个功能模块
    迭代模型：第一周完成A、B、C、D4个业务模块的基本框架和基本功能，第二周完成较复杂的业务功能
    （4）敏捷：
    敏捷宣言：个体与交互重于过程和工具；可用的软件重于完备的文档；客户协作重于合同谈判；响应变化重于遵循计划；在每对比对中，后者并非全无价值，但我们更看重前者。
    敏捷开发有很多种方式，其中scrum是比较流行的一种
    scrum里面的角色：
    PO：product owner，产品经理，负责把用户需求转换成user story
    SM：scrum master，项目经理，负责召开各种会议，协调项目，为研发团队服务
    ST：scrum team，研发团队，交付一个高质量可用的产品
    scrum的基本流程：
    产品负责人负责整理user story，形成左侧的product backlog。
    发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的story列表，sprint backlog。
    迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每个任务都有明确的负责人，并完成工时的初估计。
    每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么，今天计划做什么，有什么问题。
    演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由po整理，形成新的story。
    回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改进的效果。
    敏捷/scrum的特点：轻文档，轻流程，重目标，重产出
    轻量级：迭代周期短（1-4周），参与人员少（5-9人）
  5. 软件测试模型
    （1）V模型
    软件测试基本概念
    优点：后期的测试阶段和前期的阶段可以一一对应起来，清楚的标注每一个测试阶段的依据
    缺点：仅仅把测试作为在编码之后的一个阶段，未在需求阶段就进入测试
    （2）W模型（双V模型）
    软件测试基本概念
    特点：测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的
    有点：测试介入早，有利于尽早的全面的发现问题
    缺点：阶段性比较强，上一阶段完全结束，才可正式开始下一个阶段工作。无法支持敏捷开发模式。
  6. 软件测试的生命周期（软件测试流程）：
    需求分析→测试计划→ 测试设计、测试开发→ 测试执行→ 测试评估
    软件开发的生命周期：
    需求分析、计划、设计、编码、测试、运行维护
  7. 如何描述一个bug
    描述bug的目的是让开发人员更好的定位bug
    要素：版本号，测试环境（硬件，软件），操作步骤，预期结果，实际结果
    其他：截图，修改意见，错误日志，出现问题的时间，测试数据（重要）
  8. bug的级别（bug的严重程度）
    崩溃：系统无法正常运行。例如：运行系统死机，死循环，数据库死锁
    严重：系统可运行，但不稳定。例如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误
    一般：系统可以稳定的运行，但功能没有完全的实现。例如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框
    次要：建议类，例如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏
  9. bug的生命周期
    ● New:新发现的Bug，未经评审决定是否指派给开发人员进行修改。
    ● Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
    ● Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
    ● Rejected：如果开发人员认为不是Bug，则拒绝修改。
    ● Delay:如果开发人员认为暂时不需要修改或暂时不能修改，则延后修改。
    ● Closed：bug经测试人员的回归测斌验证通过，则关闭Bug。
    ● Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。
  10. 如何发现更多的bug？
    1、软件测试存在二八原则，80%的故障集中于20%的模块，如果某部分问题较多，加强测试广度和深度！
    2、开发人员也存在二八原则，80%的故障集中于20%的开发人员，如果某些开发人员的bug较多，加强他开发模
    块的测试广度和深度！
  11. 由于一个bug和开发人员产生冲突怎么办
    （1）先检查自身，是否bug描述不清楚
    （2）站在用户角度考虑问题 ，去劝说开发人员
    （3）BUG定级要按照公司的标准，规范
    （4）提高自身的技术和业务水平. 不光要提出问题, 最好也能提出解决方案
    （5）发起Bug评审

相关推荐