软件生命周期

软件生命周期概念？
1、别称：软件生存周期 或 软件开发生命周期
2、概念：指的是软件从产生到报废的整个过程，是一种时间的概念

软件生命周期包括哪些阶段？
1、客户问题引入或定义（客户要求的功能点，上线时间，达成的目的）
2、可行性分析：
      ① 成本和盈利
      ② 政治风险   
      ③ 法律因素（涉及到黄赌毒）
      ④技术问题，主要是看当前项目组的技术水平是否能实现客户要求
3、项目招投标：主要看哪个公司要的钱少
4、项目立项：
       ① 成立项目组；
       ② 人力安排；
       ③ 采购服务器、办公用品之类的设施
5、需求分析：产品经理输出需求文档，进一步细化客户要求，比如采用什么样的形式实现客户的需求
6、开发阶段（设计，编码，测试）：
       ① 项目经理；
       ② 产品经理；
       ③ 开发经理：
                   开发人员：写代码
                   前端开发
                   后端开发
                   UI设计师：输出效果图
        ④ 测试经理：测试人员：对开发出来的软件进行测试，保证交付的产品的质量
7、维护阶段：运维人员：处理客户的问题，或者线上的问题
8、停服：下架了，不再提供相关服务

软件生命周期模型：
1、瀑布开发模型：
      优点：每个工作节点都比较清晰，工作的先后顺序比较分明
      缺点：工作流程比较固化，比较难以应对频繁变更需求的项目，在每个阶段的工作，标准不明确
2、V模型：（重点）
       1、用户需求阶段：产品经理对接客户
       2、需求分析阶段：产品经理去引入客户需求，将客户的需求进行提炼，召开需求澄清会议；又叫需求评审：经过多次的讨论输出一个基线化的文档，叫需求文档，也叫需求规格说明书。
需求澄清会议是由产品经理召开，参与者:开发、测试。
基线文档:一般拥有固定格式，代表双方达成一致，一般不会修改。
       3、概要设计：又叫HLD，就是把形目中需要实现的功能区域，划分为A模块、B模块，概要设计一般由开发做，输出概要文档。
       4、详细设计：又叫LLD，把概要设计中区分好的模块，针对每个功能点怎样实现，做出详细的规定，输出详细设计文档。
       5、编码和实现：又叫CODing阶段，开发人员编写代码，然后将编写好的代码进行打包【rar、war、jar】
       6、单元测试：又称白盒测试，一般由开发测试。主要是开发对于代码的语法和逻辑进行测试，又叫代码走查。
       7、集成测试（IT）：又称灰盒测试、API接口测试，测试岗由此接入；主要是保证模块单独的测试没有问题，和模块的交互功能的正常，依据概要设计文档为标准
       8、系统测试  (ST)：又称黑盒测试、功能测试，本环节，不注重代码层面，只关注软件的功能是否可以正常使用，系统与系统之间的交互是否正常，包括第三方系统的交互。
       9、验收测试（UAT）:依据用户提出的需求为标准
       α测试：公司内部的人员进行模拟用户的操作进行验收测试，发现缺陷的话，此时开发人员对缺陷进行修改。
       β测试：产品交付到客户的手中，客户参与验收进行测试，由客户进行问题收集，以邮件的形式统一交给项目组，由项目组来修改。
   
   
3、H模【最重要】：
   
      1、SRS澄清会议：需求评审会议，产品经理召开，参会人员：开发、测试 、产品
      2、review：审阅、评审
      3、TPM:测试经理输出测试计划和测试方案（规定的测试范围，人力安排，时间节点的安排，风险分析；例如：时间风险，组内由新人加入的话需要重点关注新人负责的模块，可能会由漏测或者效率不高的情况）
      4、项目组中由哪些评审会议?
           1）需求评审：由产品召开，参会人员：开发、测试、产品；在需求评审中，一般测试人员主要项目中的一场场景的处理和开发进行确认和约定，并保持对需求文档的理解跟开发和产品是一致的
           2）用例评审：测试人员召开，参会人员：开发、测试、产品，在用例评审中，测试人员主讲，主要是看我们测试组编写的测试用例的覆盖度和测试方法以及测试策略是否正确，还要对测试用例的预期结果跟开发保持一致，避免后续返工以及因为缺陷的问题与开发有争执
           3）交叉评审：测试组内同事之间进行评审，一般没有产品参与
           4）组内评审：项目组的开发、测试、ui设计师、产品一起评审
           5）会议评审：有客户参与的评审会议
     testlink：一款用例管理工具，相似的平台：禅道
TPM搭建测试环境，项目组中有哪些环境？
        1、开发环境：开发人员进行编码和代码调试的环境---dev环境
        2、测试环境：测试人员进行测试活动的环境--sit环境
        3、准生产环境/预发布环境：模拟用户的场景，产品经理进行验收的环境，这里的代码和即将要上线的代码是一样的---uat环境
        4、生产环境/线上环境/正式环境，真实的客户使用的环境
环境搭建好后，开发人员进行代码打包，有TPM或者测试骨干或者运维部署项目包，项目包一般部署在Linux系统上的。
冒烟测试：在集成测试和系统测试之前进行，一般选择一些主线的流程/主体功能进行测试，主要是看主体功能是否能够跑通，冒烟测试不通过直接打回给开发人员进行修复，修改完成后继续冒烟测试，直到冒烟测试通过才可以进行接来的测试。
sit1：称为全量测试，就是把所有案例全部执行一遍，有bug的话需要协助定位bug。
sit2：又称为回归测试，主要是针对第一轮出现的bug的案例和有可能会影响到的案例进行重复执行，重点复测，防止开在修复bug的时候引发新的bug
       回归测试的内容：
       1）第一轮出现缺陷的案例
       2）可能会影响到的模块
       3）增量案例：在测试过程中增加的案例
       4）冒烟测试
测试准出的标准
       1、需求中规定的功能，得以实现
       2、所有的案例全部执行通过
       3、发新的缺陷，要全部修复，或者遗留1到2个建议性缺陷，不影响功能的使用和客户体验
项目、产品、版本有什么关系？
      1、先有项目，后有产品，一个产品有多个版本
项目上线：
       1、上线前：测试人员进行交叉测试，或者随机测试
       2、上线中：整理当前版本输出的文档，进行归档---需求文档、测试计划、测试大纲、测试用例
       3、上线后：在正式环境中进行线上验证（所有的测试活动都要按照用户的操作来进行；测试环境中出现过bug的模块进行验证）
测试报告：
       1、测试范围
       2、不测试范围
       3、bug-list：bug列表，主要是每一轮测试测出来有哪些bug，bug的修复情况，产生的原因分析
       4、风险分析：1）遗留缺陷的影响2）新人负责的板块可能有漏测
       5、本次迭代业务总结：
            1）业务上的总结，比如加入了优惠券的功能
            2）工作方法的总结，比如在工作中遇到了哪些阻塞性的问题，占用太长时间，以后怎么规避
如果发版以后发现了很严重的bug，导致项目崩溃，一时难以修复，怎么办？
       回滚，也叫版本退回
敏捷迭代：
       1、周期短，1-2周一个版本
       2、轻量级，每个版本任务量不大
       3、晨会，15-20分钟
                   1）昨天工作机会，实际工作情况，有哪些差异，导致差异的原因
                   2）今天工作计划，预计完成进度，有没有发现风险
增量开发：
       1、适合复杂且周期比较长的项目，可以将项目进行独立的功能划分，发呢多个版本上线
       2、可以避免前期公司投入过多人力物力，降低风险
测试的基本准则：
       1、测试不仅仅是软件本身的测试
             1）了解项目的背景和目的
             2）考虑外在的环境因素对项目的影响----弱网
       2、测试应该尽早介入
             1）需求评审的时候介入，对需求了解的更透彻，为后面的编写测试用例打下基础
             2）降低项目延期的风险
             3）测试介入的越早，问题修复的成本就越低
       3、二八原则
            80%的缺陷会集中在20%的区域内----开发修复缺陷的过程中很有可能引发新的bug
       4、杀虫剂效应
            在测试过程中，发现案例存在遗漏，或者案例的回归已经发现不了新的bug了
解决方法：做案例增量
11、测试活动的生命周期
       1）测试计划
       2）测试分析与设计，主要做一些测试大纲类和测试用例的文件
       3）测试的执行，根据测试案例进行测试活动
       4）测试报告的输出
       5）测试资产--》需求文档、测试计划、测试大纲、测试用例、测试报告，业务上的知识沉淀文档