软件测试（相关概念）(二)

1. 需求

什么是需求?

• 用户需求：
  可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成 的任务。该需求一般比较简略。

• 软件需求：
  或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能,是一个文档

• 在进行软件开发的时候会把用户需求转化为软件需求,软件需求是开发人员和测试人员工作的直接依据
  

从测试软件人员角度看需求:

软件需求是测试人员进行测试工作的基本依据，测试人员将软件需求转换成测试用例。
案例: 用户登录

案例：
QQ登录

测试人员转换为测试点:

如何深入了解需求:

• 在需求分析和设计阶段就开始介入
• 参加需求评审会议：
  为什么做这样一个需求、收益达到什么标准、软件要做成什么样，测试开始的时间…
• 查阅文档：
  需求文档，技术文档。
• 沟通:
  找产品了解软件功能，找开发了解软件实现。

3. 测试用例

测试用例是一组集合，包含：测试环境，测试数据，预期结果，操作步骤…

案例:
leecode在线OJ

• 测试环境：leecode提供了测试环境（Chrome浏览器）
• 测试数据：输入的测试数据
• 预期结果：通过率100%
• 操作步骤：写代码，提交

测试用例的产生就是为了解决以下的问题:

• 不知道是否较全面的测试了所有功能
• 测试的覆盖率无法衡量
• 对新 版本的重复测试很难实施
• 存在大量冗余测试影响测试效率

• 为什么有测试用例
  • 测试用例提高测试人员工作效率/降低测试人员工作的重复性
  • 测试用例是建立自动化测试的基础

测试用例案例：
手机打电话

3. 软件的生命周期:

软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间：需求分析、计划、设计、编码、测试、运行维护。

1. 需求分析：
   分析需求是否合理，需求是否完整。
2. 计划：
   谁开发，谁测试，开发多久，测试多久…
3. 设计：
4. 编码：
   写代码
5. 测试：
   测试人员测试，撰写测试报告
6. 运行维护：如果有上线问题，此时测试人员需要协助开发定位问题和解决问题。

4. 开发模型

• 瀑布模型
  
  • 特点：
    瀑布模型的每一个阶段都只执行一 次，是线性顺序进行的
  • 优点：
    • 每个阶段做什么产出什么非常清晰。
    • 强调开发的阶段性、强调早期计划及需求调查、强调产品测试。
  • 缺点：
    • 测试人员介入太晚，风险往往迟至后期的测试阶段才显露，因而失去及早发现问题的机会。
    • 依赖于早期进行的唯一一次需求调查，不能适应需求的变化。
    • 由于是单一流程，开发中的经验教训不能反馈应用于本产 品的过程。
  • 适合项目：
    小型项目

• 螺旋模型
  

• 优点：
  每个阶段都会进行风险分析，避免一些线上问题发生
• 缺点：
  风险分析可能会分析错，需要人力财力投入
• 适用项目：
  适用于比较大的项目，风险比较多

• 增量、迭代
  • 增量是逐块建造的概念.
    例如画一幅人物画，我们可以先画人的头部，再画身体，再画手脚……
  • 迭代是反复求精的概念.
    同样是画人物画，我们可以先画整体轮廓，再勾勒出基本雏形，再细化、着色。
  • 增量开发模型鼓励用户反馈，在每个迭代过程中促使开发小组以一种循环的、可预测的方式驱动产品的开发。在这种开发模式下每一次的迭代都意味着可能有需求的更改、构建出新的可执行软件版本，意味着测试需要频繁进行，测试人员需要与开发人员更加紧密地协作。

• 敏捷 :
  拥抱变化,轻流程,重交付,轻文档,重交互.
  敏捷宣言：
  • 个体与交互重于过程和工具（个体之间面对面沟通）
  • 可用的软件重于完备的文档（开发文档，需求文档）
  • 客户协助重于合同谈判
  • 响应变化重于遵循计划
  • 在每次对比中，后者并非全无价值，但是更看重前者

• 敏捷的 scrume模式：

  • 三大角色：

    • 产品经理 Product Owner：
      负责整理user story(用户故事)，定义其商业价值，对其进行排序，制定发布 计划，对产品负责。
    • 项目经理Scrum Master：负责召开各种会议，协调项目，为研发团队服务。
    • 研发团队Team：
      研发团队则由不同技能的成员组成:后端开发,前端开发,UI设计师,测试. 通过紧密协同，完成每一次迭代的目标，交付产品。

  • 五种会议：

    • 发布计划会议：
      产品经理负责讲解user story
    • 迭代计划会议：
      项目团队队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每个任务都有明确的负责人，并完成工时的初估计。
    • 每日站会：
      每天scurm master召集站立会议，团队成员回答昨天做了什么、今天计划做什么…
    • 演示会议：
      迭代结束之后召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代…
    • 回顾会议：
      项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进…

  • 流程：

    1. 产品经理收集用户信息
    2. 项目经理将需求进行优先级划分:
       计划项目什么时候开始?
       什么时候结束?
       由谁去做?
    3. 每日站会
       汇报昨天的工作有没有完成?
       遇到了什么问题?
       今天计划做什么?
    4. 演示会议
       演示，提出建议形成下一次迭代的需求
    5. 总结会议

总结:
scrum将产品的开发分解为若干个小sprint(迭代)，其周期从1周到4周不等，但不会超过4 周。参与的团队成员一般是5到9人。每期迭代要完成的user story是固定的。每次迭代会产生一定的交付。

• 产品负责人负责整理user story，形成左侧的product backlog。
• 发布计划会议：
  product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出 就是制定出这一期迭代要完成的story列表，sprint backlog。
• 迭代计划会议：
  项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每 个任务都有明确的负责人，并完成工时的初估计。
• 每日例会：
  每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什 么问题。
• 演示会议：
  迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取 得的成果。期间大家的反馈记录下来，由po整理，形成新的story。
• 回顾会议：
  项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达 到持续改进的效果。

5. 测试模型

• V模型
  

  • 用户需求：
    项目经理将用户需求收集形成软件需求
  • 需求分析与系统设计：
    验证需求是否正确，确定编程语言，确定框架。
  • 概要设计：
    项目结构如何设计。
  • 详细设计：
    每个接口涉及哪些库表，涉及哪些任务
  • 编码：
    写代码。
  • 单元测试：
    Java中测试每一个方法、类，C语言中每一个函数。
  • 集成测试：
    将许多方法集成到一起测试。
  • 系统测试：
    模块和模块之间没有影响
  • 验收测试：
    验收的人：产品、运营。

• 特点：
  左边是开发，右边是测试，类似于瀑布模型。
  明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间 各阶段的对应关系 。

• 优点：
  测试被分成许多类型。
  单元和集成测试应检测程序的执行是否满足软件设计的要求；
  系统测试应检测系统功 能、性能的质量特性是否达到系统要求的指标；
  验收测试确定软件的实现是否满足用户需要或合同 的要求。

• 缺点：
  测试人员介入太晚，发现问题时机太晚。

• W模型
  
  • 特点：
    开发测试一个V，测试一个V，测试与开发的并行，W模型增加了软件各开发阶段中应同步进行的验证和确认活动。
    测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的 。
  • 优点：
    测试人员尽早介入需求，有利于尽早地全面的发现问题。
  • 缺点：
    测试人员和开发人员一定程度上还是串行的，不能拥抱变化，不能适用于敏捷。

• 敏捷中的测试
  • 轻文档
  • 快速迭代
    • 测试工作的核心内客是没有变的，就是不断地找Bug，只是要调整好自己的心态，一切以敏捷的原则为主。
    • 测试人员不能依赖文档，测试用例作用减弱，更多的采用思维导图、探索性测试（强调自由度，设计和执行同时执行，根据测试结果不断调整测试计划）、自动化测试
    • 敏捷讲求合作，在敏捷项目组中，测试人员应该更主动点，多向开发人员了解需求、讨论设计、一 起研究Bug出现的原因。

6. 软件测试的生命周期

需求分析 —> 测试计划 —> 测试设计、测试开发 —> 测试评估。

1. 需求分析：
   需求是否完整，需求是否正确。
2. 测试计划：
   确定软件由谁测试?
   什么时候开始测试?
   什么时候结束测试?
   测试哪些模块?
3. 测试设计测试开发：
   测试人员写测试用例（手工测试用例、自动化测试用例）,编写测试工具。
4. 测试执行：
   执行测试用例.
5. 测试评估：
   从测试人员产生测试报告进行评估。
   
   

• 软件测试&软件开发生命周期

1. 需求阶段：
   测试人员了解需求、对需求进行分解，得出测试需求
2. 计划阶段：
   根据需求编写测试计划/测试方案
3. 设计阶段 ：
   测试人员适当的了解设计，对于设计测试用例是很有帮助，测试人员搭建测试用例框架，根据需求和设计编写一部分测试用例
4. 编码阶段 ：
   测试人员一般是不需要编码的，但已经编码的模块，专业的白盒测试人员可以计划执行单元测试，完善、细化测试用例以及调整测试计划和方案。
5. 测试阶段 ：
   测试阶段是软件测试人员最为重要的工作阶段，根据测试用例和计划执行测试，在执行的过程中记录、管理缺陷，测试完成后编写测试报告。
6. 运行维护 ：
   测试人员需要参与项目的实施工作。测试人员对项目产品的业务和操作非常了解，加上测试人员 的沟通表达能力一般都比较强，所以测试人员可以参与用户使用软件的培训，在试运行项目时收集 问题并及时反馈给相关负责人。

7. BUG/CASE

• BUG的定义：
  • 当且仅当规格说明书(软件需求文档)是存在的并且正确，程序与规格说明书之间的不匹配才是BUG。
  • 当程序没有实现其最终用户合理预期的功能要求时，就是软件BUG。

• 如何描述BUG ?
  • 发现问题的版本
  • 出现问题的环境：
    软件环境、硬件环境、浏览器版本、机型、操作系统环境、分辨率…
  • 错误重现的步骤
  • 预期行为的描述：
    要让开发人员指导怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需求提出的故障，能写明需求的来源是最好的。
  • 错误行为的描述（截图、录屏）：
    crash等可以上传log，UI问题可以有截图。
  • 其他：
    故障的分类、优先级的分类…
  • 不要把多个bug放到一起

案例：

如何定义BUG的级别 ?

1. Blocker（崩溃）：
   阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等,需要停止测试,打回测试
2. Critical（严重）：
   系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等
3. Major（一般）：
   功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等
4. Minor（次要）：
   界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等。

• BUG的生命周期
  
  ● New
  新发现的Bug，未经评审决定是否指派给开发人员进行修改。
  ● Open
  确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
  ● Fixed
  开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
  ● Rejected
  如果认为不是Bug，则拒绝修改。
  ● Delay
  如果认为暂时不需要修改或暂时不能修改，则延后修改。理论上delay的BUG未来一定会被修复。
  ● Closed
  修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。
  Reopen
  如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。
  ● 无效的bug
  open->closed , open-rejected-closed

8. 产生争执了怎么办？

1. 先检查自身
   确保操作没有问题,确保自己对需求理解的没有问题,确保bug描述足够清楚
2. 站在用户角度考虑问题
   应该让开发人员了解到Bug对用户可能造成的困扰，这样才能促使开发人员更加积极地、高质量地修改Bug。在争执时可以问一句：如果你是用户，你可以接受么？
3. BUG定级要有理有据
4. 提高自身的技术和业务水平.
   不光要发现问题, 最好也能提出解决方案
5. 一定不能争吵
6. 好好说，注重话术
7. 第三方会议BUG评审：
   • 开会之前的准备：
     明确问题产生的原因，问题是什么，解决方案是什么
   • 测试代表:
     主要从Bug的具体表现、严重程度等方面提供信息，并提出自己对Bug的处理意见。需要注意的是，测试人员不应该一味地要求对Bug进行修改，因为修改可能带来回归的风险，同时带来的是回归测试的工作量，如果时间比较紧迫，修改后剩余的时间若不足以做一次有效的回归测试，可能不修改是个明智的选择。
   • 开发代表:
     主要从修改缺陷的难度和风险出发，考虑缺陷修改需要付出的代价，以及可能影响的范围、可能引发的风险等，如果决定要修改，还要讨论出修改的初步方案。
   • 产品代表:
     主要从产品的整体计划、用户的要求等方面对缺陷的修改必要性、缺陷修改的时间和版本提出自己的意见。 这在微软的做法叫“Bug三方讨论会”，参加者一般是测试人员、开发人员和项目经理。
   • 分析缺陷产生的原因，找出预防的对策。 缺陷评审还应该包括原因分析，找出Bug出现的原因，尤其是那些重复出现的Bug。应该找出出现错误的根源，并且制定出相应的预防措施，确保同类型的Bug不再出现。
   • 开会之后：
     问题要不要解决?
     什么时候解决?
     谁解决?

Bug的跟踪以及状态变更应该遵循一些基本原则：

• 测试人员对每一个缺陷的修改必须重新取一个包含更改后的代码的新版本进行回归测试，确保相同的问题不再出现，才能关闭缺陷。
• 对于拒绝修改和延迟修改的Bug，需要经过包含测试人员代表和开发人员代表、用户方面的代表（或代表用户角度的人）的评审。

9. 如何开始第一次测试？

1. 充分理解需求
   • 阅读所有项目有关的文档，包括：需求文档、设计文档、用户手册
   • 项目功能问题问产品，模块底层如何实现问开发
   • 尽可能参加各种会议
   • 熟悉项目使用的测试管理工具
   • 阅读旧有BUG库了解系统功能
   • 了解公司的规范要求，特别是用例编写规范
2. 确定测试计划
   • 测试的计划是什么？
   • 测试的内容是什么？
   • test case有多少？
   • 安排了几天执行？
   • 有没有自由测试的时间？
   • 我要测试的内容开发人员是谁？需求人员是谁？
   • 分配给我的测试内容是否需要特殊的测试资源？
   • 资源是否满足需要？
3. 执行测试
   BUG开发修复之后一定要验收。
4. 项目上线+维护

10. 测试的执行和BUG管理

1. 打开待测试的系统
2. 打开测试管理工具用例模块，开始执行用例
3. 发现bug！进行复现并确认bug的复现步骤
4. 记录bug
5. 沟通bug
6. 验证以前提交的bug
7. 确认本次测试完成
8. 编写测试报告
   

• 执行测试时处理要做到测试用例和需求的覆盖外，还要有临时发挥的能力感悟以及随机测试可以发现很多根据测试用例无法发现的缺陷。
• 不能拘泥于测试用例或者已经有的测试方法，在测试执行过程中要不断总结测试方法和测试故障模型。

11. 如何发现更多的BUG

1. 二八原则：
   80%的故障集中于20%的模块，80%的故障集中于20%的开发人员。
2. 多进行逆向思维和发散性思维，依赖于测试人员的经验（没有测试经只能多写测试用例，多看别人的测试用例）。
3. 不要局限于用例和需求文档。
4. 尽早介入项目，尽早介入需求。