测试学习（一）

测试

• 软件测试

    用来验证软件功能是否满足用户需求。

• 软件测试的目的和原则

    目的：验证软件有或没有问题。
    原则：以客户为中心，遵循软件测试的规范、流程、标准和要求。

• 软件测试与软件调试的区别

    目的：测试的任务是发现程序中的缺陷；调试的任务是定位并且解决程序中的问题。
    参与角色：测试主要由测试人员与开发人员来执行（黑盒测试主要由测试人员完成、单元/集成测试主要由开发人员来执行）；调试由开发人员完成。
    执行阶段：测试贯穿整个软件的开发生命周期；调试一般在开发阶段。

• 软件开发中的需求

    满足用户的期望或规定的文档（合同、规范、标准）所需要的条件或权限，包括用户需求和软件需求。
    1.软件需求从用户需求转化而来。
    2.用户需求转化为软件需求的核心是沟通。

• BUG

    1.当且仅当规格说明书（软件需求说明书）存在并且正确，程序和规格说明之间不符合，则称之为软件错误（BUG）。
    2.当用户的需求存在并且合理，程序没有满足用户的需求，称之为BUG。

• 测试用例

    为实施测试而向被测试的系统提供的一组集合，该集合包括：测试环境、操作步骤、测试数据、预期结果等因素。

• 软件开发模型

  1.瀑布模型：
            

    瀑布模型是线性顺序进行的软件开发模式：START——计划——需求分析——设计——编码——测试——END
  优点：强调了开发的阶段性；强调了早起计划及需求调查；强调产品测试。
  缺点：由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程；风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会。

  2.螺旋模型：
           

     螺旋模型是渐进式开发模型的代表之一。一般适用于软件开发初期简洁需求不是很明确，且规模大、复杂度高、风险大的项目。
  优点：强调严格的全过程风险管理；强调各开发阶段的质量。
  缺点：引入了非常严格的风险识别、风险分析和风险控制，对风险管理的技能水平要求高，需要人员、资金、时间的投入。

  3.增量模型

     增量模型是把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件。运用增量模型的软件开发过程是递增式的过程。
  优点：待开发软件系统模块化，可分批次提交软件产品；以组件为单位降低了软件开发的风险；开发顺序灵活。
  缺点：待开发软件系统必须可以模块化。

  4.迭代模型：

     分阶段进行，每一个阶段都执行一个传统的，完整的串行过程，其中包括不同比例的需求分析、设计、编码和测试等活动。
  优点：降低了在一个增量上的开支风险；降低了产品无法按照既定进度进入市场的风险；加快了整个开发工作的速度；更加适应用户的需求变化。
  缺点：技术要求高。
（迭代模型长与增量模型结合使用：抗风险能力强）

   5.敏捷：（轻文档、轻流程、重目标、重产出）

      敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
   优点：个体和交互胜过过程和工具；可以工作的软件胜过面面俱到的文档；客户合作胜过合同谈判；响应变化胜过遵循计划
      敏捷开发技术的12个原则：
      1．我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
      2．即使到了开发的后期，也欢迎改变需求。
      3．经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。
      4．在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
      5．围绕被激励起来的个人来构建项目。
      6．在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
      7．工作的软件是首要的进度度量标准。
      8．敏捷过程提倡可持续的开发速度。
      9．不断地关注优秀的技能和好的设计会增强敏捷能力。
      10．简单使未完成的工作最大化。
      11．最好的构架、需求和设计出自于自组织的团队。
      12．每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
  缺点： 注重人员的沟通，忽略文档的重要性，若项目人员流动大太，又给维护带来不少难度，特别项目存在新手比较多时，老员工比较累；需要项目中存在经验较强的人，要不大项目中容易遇到瓶颈问题.

     Scrum流程：
             
    1. 角色
      产品负责人 Product Owner： 负责维护产品订单的人，代表利益相关者的利益。
      Scrum主管 Scrum Master： 为Scrum过程负责的人，确保scrum的正确使用并使得Scrum的收益最大化。一般不翻译。
      开发团队 Team: 由负责自我管理开发产品的人组成的跨职能团队。
    2.工件
      产品列表 Product Backlog：根据用户价值进行优先级排序的高层需求。
      冲刺订单 Sprint Backlog：要在冲刺中完成的任务的清单。
      产品增量 Increment：最终交付给客户的内容
    3.活动
      计划会 Sprint Planning Meeting：在每个冲刺之初，由产品负责人讲解需求，并由开发团队进行估算的计划会议。
      每日立会 Daily Standup Meeting：团队每天进行沟通的内部短会，因一般只有15分钟且站立进行而得名。
      评审会 Review Meeting：在冲刺结束前给产品负责人演示并接受评价的会议。
      反思会/回顾会 Retrospective Meeting：在冲刺结束后召开的关于自我持续改进的会议。
    4.其他
      冲刺 Sprint: 一个时间周期（通常在2周到1个月之间），开发团队会在此期间内完成所承诺的一组订单项的开发

• 软件测试V模型

                
   特点：单元测试所对应的是详细设计环节，也就是说，单元测试的测试用例是和详细设计一起出现的，在研发人员做详细设计的时候，相应的测试人员也就把测试用例写了出来；集成测试对应概要设计，在做模块功能分析及模块接口，数据传输方法的时候，就把集成测试用例根据概要设计中模块功能及接口等实现方法编写出来，以备以后作集成测试的时候可以直接引用；而系统测试，就是根据需求分析而来，在系统分析人员作系统分析，编写需求说明书的时候测试人员就根据客户需求说明书，把最后能实现系统功能的各种测试用例写出来，为做最后系统测试作准备。
   优点：后期测试的每一个阶段对应前期开发的阶段，有明确的的测试依据。
   缺点：V模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析,系统设计的验证，需求的满足情况一直到后期的验收测试才被验证，不利于项目前期风险的及时发现。

• 软件测试W模型

          
   特点：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等开发输出的文档同样要测试（这里针对设计文档，一般可以划分为需求设计文档、概要设计文档、详细设计文档和代码文档）， 也就是说，测试与开发是同步进行的。
   优点：尽早发现软件缺陷可降低软件开发的成本。
   缺点：在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持敏捷开发。对于当前软件开发复杂多变的情况，W模 型并不能解除测试管理面临着困惑。