6.22

.软件的非正常运行或者自身的缺陷也会引发
问题.
        非正常运行:异常条件-逆向思维执行测试.
        自身的缺陷:软件在开发完成之后是没有被执行测试的
        所有会存在许多问题.

2.软件是由代码和文档组成的,人都有可能犯错.
        1.需求文档--开发是依据需求文档的说明执行
        代码的开发.

3.环境也会引发软件失效.
        1.每个环境的配置情况不一样,这些环境的配置
        也会导致软件无法使用.
       
4.软件测试活动只是关键的质量保证活动之一
        1.产品经理编写需求文档的质量.
        2.开发代码的质量都是在保证软件的质量.
       
测试用例:
        测试用例是测试人员执行测试的依据.


软件生命周期执行的阶段:
1.客户的问题引入定义:
        客户提出需求,产品经理对接客户收集客户需求.

2.可行性分析:
        对象:客户的需求.
        经济:1.当前客户的需求实行的话,那么是否可以带来具体的
        经济效益
                 2.当前项目组的资金是否可以支持项目运作.
       
        法律:1.禁止黄赌毒.
       
        政治:1.不能出现政治敏感话题.
       
        技术:1.当前项目的技术,是否可以实现客户的需求?

项目的招投标:
        1.开发公司拟建发布公告,吸引有资质的承包商来承担
        当前项目组的部分开发工作.

项目立项:
        1.项目组成立,招人,制定工作计划,制定项目周期,
        分配工作.

需求分析:
        当前功能具体的需求文档/原型图进行分析.
        1.开发分析完成之后执行开发工作
        2.测试分析了解需求,方便后续更加全面执行测试
       
开发阶段:
        1.开发设计开发逻辑,编写代码
        2.测试人员执行测试,找出产品bug进行修复.

维护阶段:
        1.软件发送给用户使用,在用户使用的过程当前持续
        的跟进用户的情况,进行改进.
        2.准备下一阶段的开发工作
       
典型的软件生命周期模型有哪些？
        什么是软件生命周期模型?
                就是当前软件开发具体实施的内容阶段.
               
        H模型,v模型,w模型,瀑布模型,增量开发模型,
        迭代开发模型,敏捷开发模型.
       
瀑布模型:
        1970提出的开发模型.
        优点:
        1.按阶段进行展开,每一个阶段的结束,代表下一个
        阶段的开展,适用于项目管理.
        2.瀑布模型,清晰的表达了开发测试的阶段.是第一个
        重视测试的模型.
       
        缺点:
        1.如果开发按照流程走下去,一旦出现修改需求,或者开发
        理解错误需求,就会导致项目返工的情况,增加成本的开支
       
        2.现实场景当中都是按照用户的需求不断的完善当前的工
        作
        3.测试人员介入的阶段太晚,对于早期的阶段工作内容不清楚
        导致测试覆盖程度不够.
       
V模型:
       
        v模型阶段:
        用户需求:
                产品经理引用客户的需求.整理输出成需求文档
                /原型图
               
        需求分析:
                分析当前的需求文档/原型图,分析当前的业务逻辑
                以及功能实现是否正确.以及当前的技术是否可以支
                持对应的开发工作
       
        概要设计:简称HLD(由开发人员设计,设计当前的开发产品
        的开发框架,以及服务器和数据库相关配置的设计.以及大
        致的业务逻辑设计.)
       
        详细设计:简称(LLD 由开发人员进行设计,参照概要设计文
        档,设计当前交互的接口,以及数据结构的设计.前端页面逻
        辑的设计,ui设计等等.)
       
        编码阶段:依照详细设计文档,执行编码.开发程序.
       
        单元测试:简称ut,又称白盒测试.由开发人员针对自己所写
        的代码进行检测,通过观察或者运行代码,检测项目是否符
        合标准的.
       
        集成测试:简称 IT
        集成测试的内容:
        1.模块与模块合并集成,是否会产生影响,出现适配的问题
        2.模块与模块之间的数据传递是否正常.
        3.模块与模块之间的功能调用是否正常.
       
        系统测试:简称 ST
        集成测试通过,所有的模块都兼容,没有产生问题,
        然后执行系统测试.
        系统测试:又称全量测试,包含项目当中所有功能的测试,
        界面测试,可用性测试,可靠性测试,易用性测试,界面测试
        ,性能安全测试.都需要被执行.
       
       
        验收测试:又称UAT:
        由谁进行验收?
                1.可以由当前开发的项目组成员组织验收
                2.可以由客户方进行验收.
               
        α:阿尔法: 都是当前项目组成员组织进行验收测试,从新测试
        当前的项目,看他是否达到了用户使用标准.推动版本的发布,
        给用户使用.
        β:beta:客户方进行验收,我们当前项目组需要派出代表给
        客户讲解需求,客户组织验收,根据用户具体反馈的问题,做
        持续的更近解决.
       
V模型的输出和输出的关系:
        输入:用户需求  输出:需求分析
        输入:需求分析  输出:概要设计
        输入:概要设计  输出:详细设计
        输入:详细设计  输出:编码阶段
        输入:编码阶段  输出:单元测试
        输入:单元测试  输出:集成测试
        输入:集成测试  输出:系统测试
        输入:系统测试  输出:验收测试
       
先阶段系统测试以及集成测试以及合并:
        简称 SIT 系统集成测试,在这个阶段所
        有集成测试的内容,系统测试的内容在同
        一个阶段进行执行
       
v模型虽然他概括了所有的测试阶段的流程,但是他的
测试流程阶段依旧在开发编码之后,对于前面的问题
在我执行测试的阶段才引入,导致我需求理解不透彻,
测试覆盖不全面,导致增加测试市场.


H 模型:
        项目和产品的区别?
                现有项目再有产品.产品是当前项目输出的结果.
       
        项目和版本的区别?
                项目是一个工程.
               
                版本指的是实际输出产品的版本号.
                每个项目的初始版本都是v1.0,
                项目是包含版本的,一个项目当中可以包含多个
                版本.
       
       
        SRS(需求规格说明书,需求文档/原型图)       
        test case TC(测试用例)
        testlink(bug用例管理工具)
       
       
        电商的主体业务流程
        -->商品添加-->进行支付--->下单成功-->待发货
       
        如果支付功能出现问题,就造成了阻塞.后续的功能
        测试人员无法进行开展.
        只有主体的流程畅通,才能针对每个节点的子功能
        进行检测.
       
       

敏捷开发模型:
        1990提出.
        1.能够快速的适应市场的变化,一旦市场需求变了,我也可以
        根据用户情况更快的改动.
        2.交付周期短,大概1-2左右一个版本, 项目紧急就是1个礼拜
        一个版本,不紧急可能1-2左右时间完成一个版本的开发.
       
        缺点:
        1.针对开发以及测试的能力要求比较高,敏捷开发模式一般
        很少会有实质性的文档产生,强调的是人与人之间的沟通.
        2.测试的覆盖程度不够全面,会经常产生问题.

增量开发模式:
        1.将已知/代开发的功能进行模块化,分批次的进行开发
        交付给用户进行使用.(也是根据用户需求紧急程度来进行
        交付功能.)
       
        2.开发的顺序灵活,能够自由的调整开发顺序,也可以快速的
        适应市场.

迭代开发模型:       
        1.先做成一个项目交给用户使用,在用户使用的过程当中,
        我在进行频繁的迭代,增加一些新的功能.这些功能都是
        未知的,根据市场的需求进行迭代功能.
       

测试的基本原则:
        1.测试标准是用户需求:
                但前测试的软件是否达到了用户使用标准.
               
        2.测试不单单是软件本身的测试:
                1.网络
                2.硬件配置
                3.环境
                4.兼容
        二八原则：
                模块如果出现比较多的bug,那么我们更加仔细的测试
                这个当前模块,因为bug可以引发更多bug的产生.
               
               
测试计划的(测试的准入)条件与控制:
        测试的准入:
        软件到达怎样的条件之后.测试人员介入测试.
        1.当前所有开发的功能已经按照需求文档实现
        2.开发完成单元测试,并向测试提交测试报告申请单
        3.输入的单元测试报告.
       
测试分析与设计:
        分析:需求文档当中具体的需求
        设计:设计执行测试的测试用例

测试的实现与执行:
        执行编写的测试用例,找出软件当中的问题.


测试报告(测试的准出):


测试过程当中资产归档(测试的总结)
        产生一些文档
                测试用例,测试bug都需要进行归档留存.
                资产:测试机(收集)
       
        针对此次测试工程,有哪些做出总结.
        (具体那个环节做的不好.进行总结)