测试基础知识

一、什么是软件测试？软件测试的目的和原则？

1) 找bug
2) 评价一个程序或系统属性好还是不好,即评价软件质量
3) 用人工/自动手段测试，检验是否符合满足要求，或者与预期的差距
4) 目的：找bug，验证正确性；

原则：以客户 为中心，遵循软件测试的规范、流程、标准和要求

二、测试与调试区别

1) 目的：
测试是发现问题；
调试是定位并解决问题
2)参与人员不同
    测试由测试人员和开发人员共同完成，其中测试人员主要负责黑盒测试，开发人员主要负责单元/集成测试；
    调试由开发人员完成
3)执行阶段
    测试在软件开发整个周期；
    调试只在开发阶段

三、需求(了解)

分为用户需求和软件需求；满足用户正式文档规定的条件和权能

四、什么是软件缺陷(bug)？

1.有需求规格说明书且正确，与之不匹配的:
    1)软件没达到需求说明书要求的功能
    2)软件出现了需求规格说明书指明的不应该出现的错误
2.无需规格说明书以用户的合理期望为标准

五、软件开发的流程(软件生命周期)？

软件生命周期是指从软件的设想开始，到软件不再使用而结束的时间。

需求分析->计划->设计->编码->测试->运行维护

六、软件测试的流程?

需求分析→测试计划→ 测试设计、测试开发→ 测试执行→ 测试评估

相应开发周期测试做什么？

需求阶段
测试人员了解需求，得出测试需求

计划阶段
根据需求编写测试计划/测试方案

设计阶段 
测试人员搭建测试用例框架，根据需求和设计编写一部分测试用例

编码阶段 
已经编码的模块，专业的白盒测试人员可以计划执行单元测试，完善、细化测试用例以及调整测试计划和方案。

测试阶段 
根据测试用例和计划执行测试，在执行的过程中记录、管理缺陷，测试完成后编写测试报告。

运行维护
测试人员需要参与项目的实施工作。

七、四种软件开发模型

• 瀑布模型：
  强调：阶段式开发
  适合：串行，适合需求相对稳定的项目
  缺点：每个阶段只能执行一次；测试晚，成本高
• 螺旋模型：
  特点：渐进式开发
  强调：风险
  适合：规模庞大，复杂度高，风险大的项目
• 增量，迭代
  降低项目风险，前期需求不大明确
• • 增量：分块构建 特点：鼓励用户反馈
• • 迭代：先大致构建轮廓，再细化
• 敏捷
  敏捷宣言：重交互，轻文档，客户参与，拥抱变化

    敏捷开发方式：scrum迭代（sprint）开发：scrum 将产品的开发分解为若干个小spint（迭代）
          周期：1-4周
           人数: 5~9人
           每天例会：15分钟之内 ，昨天完成了什么，遇到什么问题，今天计划完成什么
           流程： 主要人员：PO(产品经理)、SM(scrum master项目经理)
           1.PO(产品经理),整体user story
           2.发布计划(PO)：user story 估算，排序，确定本次迭代完成的user story
           3.发布迭代会议(SM)：任务认领，评估完成时间
           4.站立会：每天
           5.演示会议：客户，PO，记录问题完成user story
           6.总结会议

            敏捷中的测试：
            轻文档 解决办法 ：沟通
            快速迭代 解决办法： 自动化测试

八、软件测试模型

• V模型
  
  是瀑布模型的变种，将测试阶段和软件开发阶段对应起来。明确了在测试过程中，有不同类型的测试。
  缺点：测试介入太晚，成本高

用户需求：学习需求 了解需求(用户需要什么、软件做成什么样、有哪些功能)的背景目的（参与度低）
需求分析与系统： 了解需求 编写测试计划
概要设计：主要是架构实现，表述各模块功能
详情设计：对模块深入分析
编码阶段：重点进行 测试用例编写

单元测试：按设定的最小单元进行测试，主要测试程序代码
集成测试：测试各模块结合后的功能实现
系统测试：黑盒测试人员执行，前期测功能，后期测性能 环境搭建，数据准备，测试执行，缺陷管理，编写测试报告
验收测试：单元测试与集成测试测试人员不参与

九、bug详解

如何描述bug

错误出现的版本、错误出现的环境、错误重现的步骤、预期的行为、错误的行为

bug级别

崩溃：阻碍开发或测试工作的问题 如：系统崩溃、死机
严重：主要功能丧失 如：用户数据丢失
一般：功能不完全实现但不影响使用 如：操作时间长、删除没有确认框
次要：性能缺陷，不影响操作功能执行

bug的生命周期

• 状态转换图
  
• 各状态解析：
• • new:发现一个bug,没确定是否需要修改
• • open:确定是bug,并且需要修改
• • 开发人员三种选择：
• • • 认为是bug且需要现在修改，走Fixed流程
• • • 认为不是bug,走rejected->clsed流程。拒绝修改rejected
• • • 认为是bug,但不是致命bug，延期修改delay
• • Fixed:开发人员修改后，将bug状态表示为修改状态，等待测试人员回购回归测试
• • 测试人员两种选择：
• • • closed:回归测试通过则关闭bug
• • • reopen:回归测试不通过则重新打开bug等开发人员修改
• 无效的bug
• • open->closed
• • open->rejected->closed