5.22回顾

第二讲   软件的生命周期
【为什么要测试？】
1、软件的非正常运行或者自身的缺陷（BUG）会引发很多的问题。
2、软件是由代码和文档组成的，而这些都是由人来设计和编写的，而人都会犯错，多少都会存在一些问题。
3、环境也会影响测试，以致软件出现失效现象。
4、软件测试只是质量保障的关键活动之一，测试人员只是其中一部分，还需要整个团队去维护，客户需求需要梳理，开发也需要自测。
【什么是测试】：
在软件行业中由多种说法比如;1验证软件的正确性——如何证明软件有错，测试人员就是需要证明软件是否存在问题
                                            2发现软件中的自身缺陷——测试人员就是为了找软件中的问题
【发现软件中的缺陷的3种说法】：
1测试就是为了证明程序有错
2一个好的测试用例在于它能发现以前所未发现的错误
3一个成功的测试在于它能发现前所未有的错误的测试
【软件生命周期包括哪些阶段】
1、客户问题的引入或者定义
客户的需求一般会比较笼统粗糙，多少会存在一些问题，需要和产品经理进行沟通讨论
2、可行性分析
是否赚钱，是否合法，是否能得到技术支持
3、项目招标
主要考虑交付的时间，项目的成本
4、项目立项
成立一个项目组，要招人;开发，测试，运维，数据库等等，还涉及到前一阶段交付什么，后一阶段交付什么
5、需求分析
产品经理是主角，对客户的需求进行提炼，梳理逻辑从而转为项目需求，在交给开发测试——开发测试人员进行阅读理解分析并记录问题，——在产品经理组织的评审会上（产品经理主讲，开发和测试旁听并提出之前发现的问题）——讨论，修改并确定基线化文档
6、开发测试阶段（设计 编码 测试）
开发编写代码，编写完后自测，测试了解需求，编写用例，执行用例提交BUG，——测试完成安排上线
7、维护
运维人员负责维护，客户一般交30%的定金，软件交付后在支付剩余部分，其中10%用于一年的维护

w模型对测试人员要求过高，
敏捷开发模型：研发周期短，项目进行快，互联网公司多，
【v模型】  （项目的阶段）【重点】
1用户的需求 ：用户提出需求，但不一定完善规范，需要产品经理和客户沟通并提炼
2需求分析阶段：产品经理根据客户需求提炼出项目需求，（研发团队要看懂的）——给到开发和测试运维等——开发测试进行阅读分析并记录下问题——在产品经理召开的评审会上，产品经理主讲，开发测试旁听并提出问题——讨论是否合理并修改——最后形成需求规则说明书
3概要设计阶段：HLD 开发做的 ，搭建多个框架模块，但还不清楚具体作用
4详细设计阶段：LLD  开发做的，针对概要设计阶段搭建的框架模块去充实内容，实现具体的功能作用
5编码和实现阶段： 开发做的，就是根据详细设计然后编码代码coding
6单元测试阶段:UT  开发做的，代码测试也叫白盒测试，就是一个透明的盒子，里面的逻辑都可以看清，也能清楚内部结构和数据测试。由开发人员自测（白盒测试中分两种方法：语句覆盖 和路径覆盖，其中路径覆盖最强
7集成测试   IT     测试做的   接口测试也叫灰盒测试，就是把开发人员一个个编写好的框架模块进行窜连起来，之前开发自测的一个个模块没有问题，但需要测试把这些模块窜连起来还是否同样能够正常
8系统测试   ST  测试做的  功能测试，就是对整个系统全部进行测试，以及第三方测试接口都需要没有问题才可以（比如登录淘宝也可以通过微信支付宝等登录）
其中集成测试和系统测试由可以合并成系统集成测试 SIT测试（包含接口测试和功能测试）
9验收测试阶段： UAT  （验收环境和测试环境）由产品经理对内验收
验收测试又分两种
α（阿尔法）是 内部测试：由产品经理和测试一起模拟用户场景进行测试，发现问题，立刻交给开发修复，同时测试人员需要跟进。
β（贝塔)   是外部测试，就是软件已经交付客户，客户或者客户方测试进行验收时发现问题，研发团队这边需要让客户统一收集，以邮件形式抄送给相关人，再由测试人员对这些问题进行验证，并分出等级，协助开发尽快修复。

【一般的问题】
【软件上线后，客户发现问题怎么办？】
收集客户发现的问题，对这些问题在测试环境包括线上真实环境下进行操作，看是否是客户操作失误，如果测试环境下没有问题，那可能是代码漏传，上传代码看下还是否有问题。如果确实存在问题，对这些问题进行划分等级，严重致命的和一般的，通知上级领导，如果短期修复不了，对那些严重的问题看是否需要回滚代码并注意数据备份，并及时跟进问题直到修复。
【你上一家公司的项目有哪些阶段？每个阶段的输入输出是什么？】
阶段                             输入                             输出
需求分析阶段              测试开发产品开会讨论               需求规格说明书
概要设计阶段              需求规格说明书                     概要设计说明书
详细设计阶段              概要设计说明书                     详细设计说明书
编码阶段                  开发编写代码                       整个代码包（.war .jar .zip）
单元测试阶段              对各自开发的模块进行代码测试       单元测试报告
系统集成测试阶段          编写测试用例和执行测试用例         系统集成测试报告
验收测试阶段              产品和测试开发或者客户验收测试     验收测试报告


【H模型】：就是项目流程或者是测试流程（接到一个项目怎么去细致开展）

项目和版本的区别：项目高于版本，比如一个项目持续很久，期间会更新很多的版本。
项目和产品的区别：先有项目后有产品（参考软件生命周期就可以了解）
【大致流程梳理】：
1需求澄清（评审）                                                 产品经理开发测试运维等讨论出一个规范文档
2概要设计HLD                                                        测试了解需求
3详细设计LLD                                                         测试继续了解需求，根据项目周期输出测试计划
4开发编写代码                                                         测试人员根据需求编写测试用例和评审用例
5开发把编写好的代码打成一个代码包（。jar等）        运维部署测试环境并且将代码包部署到测试环境
6测试人员进行测试，根据执行用例测试
有问题提问题，交给开发修复，进行回归测试
7所有问题都已修复，回归测试都验证完并且没问题
8测试人员输出一个测试总结报告交付测试领导。领导会根据这个报告做上线准备

【如何进行细化】
1、（对一个项目如何进行需求澄清和评审的？下面就是答案）
产品经理根据客户需求提炼出项目需求（研发团队看的懂的）——给到研发团队开发测试——阅读分析讨论，记录得出的问题——在产品经理通知开评审会的时候，由产品经理主讲，开发测试旁听并提出问题——最终形成一个需求规格说明书

2、开发根据需求文档编写概要设计说明书ULD——测试人员了解需求——最终评审

3、开发根据概要设计编写详细的设计说明书LLD——测试人员继续深入了解需求——目的是挖掘需求中隐形的显示的关联的需求点——根据项目周期，测试经理输出测试计划（包括测试范围，安排人员，规定的时间，资源等），一般测试计划由测试经理或者测试组长或者测试骨干制定。

4、开发人员编写代码（coding），测试人员根据需求文档编写测试用例——编写完后进行用例评审，谁写的谁来讲。——评审完后有可能由增减修改，——修改后发给领导或者发到用例管理工具里
    TE:测试工程师   TC:测试用例    testlink  :用例管理工具

你们公司评审一般都有哪几种？
用的最多的一般是组内评审：项目组内部成员领导开发测试运维ui等
                         也有交叉评审 和会议评审

5、打包部署：运维人员搭建测试环境，——开发人员把代码打成代码包交给运维，——运维把代码包部署到测试环境中（基于linux上）包根据服务器来定——运维给测试人员IP地址账号密码
一般会问你们公司一般由哪几种环境？
1测试环境： 测试人员用的(内部环境）
2线上环境：开发人员联调自测用的（内部环境）
3线上环境;   生产环境，真实环境   （外部环境）

6、测试人员开始测试
测试人员首先进行冒烟测试，就是对主体功能进行测试，一般用50条用例进行测试（最先起源于硬件行业，比如电路板)
（什么是主体功能？对最重要最根本最主要的进行测试，确保成功才能进行下一步）——如果冒烟测试不通过，把版本打会给开发，——开发修复问题后更新原版本后冒烟测试通过——测试人员执行SIT测试（SIT测试叫做系统集成测试或者叫全量测试）——可能会进行多次的SIT测试。
       SIT 1使用多少用例测试出多少问题，测试过程中有可能出现用例漏写，需要再增加的，输出小结报告
      SIT 2回归测试（增量测试，用例数量的增加）新增的用例需要测试，修复的问题需要测试，冒烟测试，发现问题的相关联模块也需要测试。抽取全部用例的部分用例再测试，发现问题继续提出
   不断多次SIT测试，直到所有回归测试没有问题，输出测试总结报告，发给直属领导，领导据此做上线准备。


【H模型总结】  工作流程和测试流程
产品经理接到客户需求，进行分析提炼形成项目需求，下发给项目组成员阅读分析并记录一些发现的问题，这时产品经理会开展一个评审会议，由产品经理主讲，开发测试提出之前记录的问题，进行讨论分析，产品经理进行调整最后形成一个基线化文档（需求规格说明书），开发编写代码，测试编写测试计划，并根据测试计划编写测试用例，进行评审，然后由运维把开发给到的代码包部署到准好的测试环境中，由测试人员进行冒烟测试，如果不通过打回版本给开发，如果通过了在进行SIT测试（系统集成测试），发现BUG并提出，等开发修复好后进行回归测试，直到所有的BUG全部修复，最终输出测试总结报告给指数领导进行上线准备。

【常见问题：】
1、H模型中的1表示什么？
表示由一个易用性的BUG，不影响使用，但必须报告给领导，可以留到下一版本解决
2、你们公司一定要BUG为0才能上线吗？
表示不一定，如果说是致命的严重的，BUG需要为0，避免影响正常使用，但如果存在易用性的BUG,可以报告领导，留到下版本解决
3、你们测试准出的标准是什么？
表示所有功能都实现且符合需求规定，所有回归测试都测试没问题且BUG都通过且关闭，输出测试总结报告以及其它文档
4、你们公司测试准入标准是什么？
表示所i有文档都已经输出（包括需求文档，开发文档，测试用例文档，测试计划等）
开发编写好代码且通过了单元测试，研发的功能也符合需求文档的要求
测试用例已经评审通过
测试环境已经搭建好且代码包已经部署到测试环境中

【测试活动的生命周期】  
测试计划（了解了需求文档输出了输出了需求规格说明书）——测试分析和设计（测试计划已经输出，设计测试用例）——测试实现和执行（测试用例已经写好且通过评审）——测试准出（也就是测试报告)就是之前的全部测试用例都测试完并且BUG也修复了——测试资产归档（一般指app 配手机情况下）

【测试的基本原则】     
测试需要以需求规格说明书为准
测试需要测试软件包括文档
测试对象一般淘宝类的要求性能，银行类的要求安全