测试理论知识

软件的研发模型

     1.软件产品中的过程文件
        用户需求、项目计划、版本计划、技术选型报告、竞争对手调研报告
        概要设计、详细设计、测试计划、测试方案、测试用例、测试报告、缺陷跟踪单……

    2.瀑布模型
        计划---->需求分析---->设计---->编码---->测试---->运行、维护
        特点：
            ·线性化模型结构
            ·各阶段具有里程碑特征
            ·基于文档的驱动
            ·严格的阶段评审机制
        优点：
            ·有利于大型软件研发过程中人员的组织和管理
            ·有利于开发方法和工具的使用
            ·提高了软件的质量和效率      
        缺点：
            ·不灵活
        
    3.V模型
        用户需求---->需求分析---->概要设计---->详细设计---->编码---->单元测试---->集成测试---->系统测试---->验收测试
        优点：
            ·软件测试分成若干级别，能够提高软件质量
            ·软件测试和开发级别一一对应
        缺点：
            ·忽略了软件测试对象不止程序，还包括文档
            ·软件测试是最后阶段，需求阶段的问题，只能到验收测试阶段才能发现
            
    4.W模型，又称双V模型        
        优点：
            ·测试活动和开发活动是同步进行
            ·软件测试的对象不仅仅是程序，还包括文档
            ·尽早的投入测试可以降低开发成本         
        缺点：
            ·无法迭代，测试活动和开发活动保持着一种线性的前后关系，上一阶段结束后才能正式开始下一阶段的工作
        
    5.X模型
        ·最早引入探索性测试的研发流程
        ·软件分为几个片区，然后集成在一起形成最终的软件
        
    6.快速原型
        ·又称原型定义，非线性模型，主要用于小公司，客户到最后才知道软件的最终模样，
          先做成一个demo，给客户看一个样板
          
    7.螺旋模型
        ·非线性化模型
        ·引入了风险管理、进行评估
        
    8.软件的生命周期
        ·需求---->设计---->编码---->测试---->维护---->升级---->废弃
        ·测试的设计文档：测试方案和测试用例
        ·开发的设计文档：概要设计和详细设计
        ·软件测试贯穿于软件的生命周期
        
    9.软件的测试流程
        ·需求分析---->测试计划---->测试方案---->测试用例---->测试执行---->测试报告
        
    10.一般项目中的成员
        ·项目经理(PM)
        ·架构师
        ·程序员
        ·软件测试工程师：初级、中级、高级、专家；测试经理、交付经理、部门经理、部门总监
        ·资料工程师
        ·配置管理员(CMO)
        ·QA
        ·产品经理(BA)
        ·UI设计
        ·DBA：数据库管理员

软件测试基础

    1.软件测试的经典定义：在规定的条件下，操作程序，发现缺陷，评估质量
    
    2.软件测试的目的：尽可能多的发现软件的缺陷、预防缺陷、对软件质量进行度量和评估，以提高软件的质量
    
    3.软件测试的范围：程序、数据、文档
    
    4.软件测试的起源来自于软件工程
    
    5.质量的定义：软件与明确和隐含定义的需求相一致的程度
    
    6.软件测试的原则：
        ·所有软件测试都应该追溯到用户需求，需求是软件测试的依据
        ·应当把尽早地和不断地测试作为软件测试的座右铭
            尽早测试能够提前发现缺陷，降低修复成本
            不断测试指测试的分级，通过多级测试更能提高软件的质量
        ·完全测试是不可能的，软件测试需要终止，处于成本考虑和现实考虑
        ·软件测试无法显示软件的潜在缺陷，缺陷是发现不完的
        ·充分注意测试中的群集现象：二八定律，80%的缺陷出现在20%的模块，发现的缺陷越多，残留的缺陷也越多
        ·程序员应避免检查自己的程序，测试的心理学
        ·尽量避免测试的随意性
        
    7.软件测试的风险
        进度风险、质量风险、人员风险、成本风险、变更风险
        
    8.软件测试工程师所具备的素质
        综合素质：
            ·细心、耐心、责任心、自信心
            ·沟通能力、语言及文字表达能力
            ·团队的协作能力
            ·逻辑思维能力和发散性思维能力
            ·发现问题的敏锐度、观察能力
            ·具有丰富的软件测试经验
        
        专业素质：
            ·熟悉软件研发流程及测试流程的知识
            ·熟悉测试理论知识、测试技术和方法、测试文档的编写能力
            ·掌握测试工具如：管理工具、自动化、性能、安全
            ·计算机相关知识：数据库、开发语言、操作系统、网络基础
            
    9.软件测试工程师的职责
        ·搭建测试环境
        ·编写软件测试用例
        ·执行软件测试
        ·报告软件缺陷
        ·验证修复的缺陷
        ·报告测试的状态

软件测试的分类

1.按照测试阶段划分

        按照测试阶段划分：单元测试、集成测试、系统测试、验收测试

        单元测试

            ·对软件中的最小可测单元进行测试，如：C语言中的函数、Java中的类、UI界面中的窗口
            ·侧重检查程序的内部结构、逻辑控制及异常处理
            ·单元测试能发现软件80%的缺陷
            ·单元测试90%是由开发人员测试，10%由测试人员测试
            ·单元测试工具，如：Java语言中的Junit、Python语言中的Unittest和Pytest
            ·单元测试的依据是详细设计

        集成测试

            ·又称为组装测试或者联合测试
            ·在单元测试的基础上、将所有的模块按照要求进行组装成系统或者子系统
            ·侧重检查模块和模块之间的接口及接口数据传递的正确性、以及对组装后的整体功能进行测试
            ·集成测试的依据是概要设计   

                集成测试分类

                非增量式集成：又称为一次性集成，首先对每个模块分别进行测试，然后将所有的
                模块集成在一起进行的测试，最终得到要求的软件系统
                优点：集成速度快、时间短、所需人力资源少
                缺点：一次性集成的成功率低，发现问题后很难定位问题
                
                增量式集成：
                    自顶向下增量式集成，需要编写桩程序
                    自底向上增量式集成，需要编写驱动程序

        系统测试

            将已经集成并确认好的软件与计算机硬件、网络、软件结合成一个整体进行的测试
            
            参考依据：需求规格说明书
            
            系统测试的范围：
                功能测试、性能测试、压力测试、容量测试、安全性测试、可用性测试
                GUI测试、安装测试、配置测试、异常测试、备份测试、健壮性测试
                文档测试、在线帮助测试、网络测试、稳定性测试

        验收测试

            ·确定产品是否能够满足合同或者用户所规定的需求
            ·检查软件的功能及性能与用户需求的符合度、文档资料的完整性和正确性
            
            分类：
                正式验收：有正规的测试过程、需要制定验收测试计划、测试方案、选择测试用例、执行测试、提交测试结果
                
                非正式验收：
                    α(阿尔法)测试：软件开发公司组织内部人员模拟各类用户行为对即将上市的产品进行测试
                    β(贝塔)测试：软件开发公司组织各方面典型客户在日常工作中的实际使用、并要求用户报告情况
                                 然后提出改进建议、公司再进行完善
                                  
                    区别：
                        负责人不同：阿尔法测试由软件开发公司内部人员负责测试，贝塔测试由典型的用户负责测试
                        测试环境不同：阿尔法测试在公司内部环境，贝塔测试在生产环境
                        发现问题时是否可控：阿尔法测试可控，贝塔测试不可控
                        问题记录人：阿尔法测试由测试人员，贝塔测试由典型的用户

    2.软件测试按照是否运行程序划分

        ·动态测试：实际运行被测试的软件，输入相应的测试数据，检查实际输出结果是否和预期结果相一致的过程
        ·静态测试：不运行被测试的软件，而只是静态的检查代码、界面或者文档

    3.软件测试按照是否查看代码划分

        ·黑盒测试：又称为功能测试、不关注程序内部逻辑结构和算法，只关注软件的功能及性能与需求规格的符合度，主要适用于系统测试、验收测试
        ·白盒测试：又称为结构测试、基于程序代码的测试、只关注程序代码的结构和算法，不关注软件外部的整体功能及性能指标，主要适用于单元测试
        ·灰盒测试：介于白盒和黑盒测试之间的测试、既要关注软件的整体功能，又要关注程序内部的实现，关注程度没有白盒那么深入，主要适用于集成测试、接口测试

    4.其他划分

        回归测试、冒烟测试、随机测试、交叉测试、App测试、Web测试……

        
需求分析

    1.主要是解决测试什么的问题，明确测试的地方
    
    2.以需求规格说明书为基础、进行细化和分解
    
    3.测试的范围：主要指的是明确的和隐含的需求
    
    4.需求分析谁来做：有经验的软件测试工程师
    
    5.需求分析的时间：
        通常占项目周期的10-20%左右的时间(工作日)
        
    6.输出的文档
        测试需求分析文档，编写的工具主要是mindmanager、Xmind
        
    7.评审人
        组内的测试人员、产品经理、开发代表、测试经理、项目经理、QA
        
    8.需求分析的特征
        ·需求项必须是可核实的
        ·需求分析需要指出正确的条件和错误的条件
        ·需求分析不包含具体的数据
        
    9.需求分析方法：
        ·测试要点分析
        ·功能交互分析
        ·质量特性分析
        ·测试类型分析
        
    10.需求分析的过程
        需求采集----->需求分析----->需求评审
        
        依据：        需求规格说明书        需求分析方法        测试需求 
                          ||                 ||                   ||
                          ||                 ||                   ||
                       需求采集              需求分析            需求评审
                          ||                 ||                   ||
                          ||                 ||                   ||
        输出：        原始测试需求表          测试要点            评审结论

测试计划 

    1.编写人：测试经理或者测试组长
    
    2.参考依据：需求分析的结果、项目计划
    
    3.读者对象
        上：领导
        中：项目经理、产品经理、QA
        下：组内的软件测试工程师、组外：其他项目组的测试经理
        
    4.如何制定测试计划
        ·认真做好测试资料的搜集工作、主要是搜集人和设备
        ·明确测试的目标、主要指时间目标、质量目标
        ·坚持5W原则，明确内容和过程
            why：测试的目的
            what：测试的范围
            when：测试的时间
            who：测试的参与人
            where：项目中输出的文档、缺陷报告单、软件包等存放的位置
            
    5.采用评审和更新的机制，保证测试计划满足实际需求
    
    6.编写时间
        测试需求分析完成后，实际大概为2-5天，在整个测试过程中处于不断修改的状态
        
    7.测试计划的内容
        项目概述、目的和范围、测试的通过准则、读者对象、测试的参考资料
        测试的策略、硬件环境和软件环境、启动条件、结束条件、测试周期
        人力投入、任务分配及进度安排、测试的风险
            
        测试的策略：又称测试的类型，主要指的是功能测试、性能测试、兼容性测试、回归测试
                    集成测试、安全性测试……
                    
        启动条件：
            ·测试用例编写完成，并通过评审
            ·开发编码完成，并通过自测
            ·开发提交了转测试申请单及相关配置
            ·冒烟测试通过
        
        结束条件：
            ·测试任务全部完成，人力投入充分
            ·需求覆盖率达到100%，测试用例通过率达到100%
            ·缺陷密度达到预定标准
                预定标准：高验收标准：3-5个
                          一般验收标准：6-10个
                缺陷密度=Bug总数/代码量   代码量单位为：Kloc，即千行        
            ·缺陷修复率达到100%，遗留的bug需要给出规避措施
            ·bug的趋势呈正态分布或者收敛状态
            ·需求规格中的所有功能已全部正确实现
            ·交付件齐全、验收测试通过

     
测试方案

     1.概念：测试方案是对需求分析的结果进行细化和分解得到的功能点，主要是解决"怎么做"的问题
    
    2.时间：测试计划编写完成后
            时间周期：大型项目：二周左右(工作日)
                          中小型项目：一周左右(工作日)
                      
    3.编写人：具有丰富经验的软件测试工程师
    
    4.评审人：组内的测试工程师、开发代表、产品经理、测试经理、项目经理、QA

测试用例 

        1.概念：它是一份测试设计文档、描述了输出动作和一个期望结果、目的是确定程序的某个特性是正常的工作
    
    2.参考依据：需求规格说明书、需求分析的结果、测试方案
    
    3.编写人：具有丰富经验的软件测试工程师
    
    4.编写时间：测试方案评审完成且通过评审、编写时间占整个项目周期30%左右的时间
    
    5.输出文档：测试用例
    
    6.编写工具：Excel、word、bugfree、zentao、testlink
    
    7.评审人：组内的测试工程师、开发代表、产品经理、测试经理、项目经理、QA
    
    8.用例的组成：
        用例编号、功能模块、标题、优先级、预置条件、操作步骤、预期结果、设计人、设计时间、备注
        
        用例编号：
            ·不能重复、格式：项目名-模块名-编号        如：QQ-登录-0001
            
        功能模块：
            ·主要是方便分配任务、知道用例的所属路径、一般编写二级模块，也写三级模块，如：QQ-发送消息
            
        用例标题：
            ·标题不能重复
            ·标题中不涉及具体的数据
            ·标题中没有句号，最多一个逗号
            ·标题中不能写bug
            ·标题中不能有歧义
            ·标题长度通常不超过24个字符
            ·标题和预期结果相呼应
            ·格式：在什么地方+条件+结果
            
        优先级：
            ·目的是为了在测试时间不充足的情况下，按照优先级的比例抽取主要功能模块，如：冒烟测试、回归测试
            ·根据重要性和使用频率来确定用例的优先级、两高得高、一高一低为中、两低为低
            ·优先级高中低的比例为：1:3:1
            ·正常场景的用例比异常场景的用例高一个等级
            
        预置条件：
            ·在具体的测试步骤之前需要准备的前提条件，如：登录某个网站之前，需要注册账号
            ·它包含具体的测试数据
            ·测试时需要的环境信息
            
        操作步骤：
            ·在具体的功能界面中输入数据和操作的按钮
            ·操作步骤包含具体的测试数据
            
        预期结果：
            ·测试用例的期望结果、用例指明测试执行后要达到什么样的结果
            
黑盒测试用例的设计方法：
    1.概念：黑盒测试又称功能测试、数据驱动测试或者是基于需求规格说明书的测试、是从用户观点出发的测试
    
    2.测试用例设计要点：
        ·用最少的测试用例尽可能全面地覆盖所有的需求
        ·穷举测试数据太大、完全测试是不可能的、测试需要终止
            所以需要使用科学的测试用例设计方法、选择具有代表性的数据进行测试
            
    3.黑盒测试用例常用设计方法：
        ·等价类、边界值、错误推测法、场景法   (重点掌握)
        ·因果图、判定表、正交设计实验法
        
    4.等价类
        ·定义：把所有可能的输入数据划分成若干部分、然后从每个子集中选取少数具有代表性的数据作为测试用例
        
        ·有效等价类：指对程序的规格说明来说是合理的、这些数据构成的集合称为有效等价类
        
        ·无效等价类：指对程序的规格说明来时是不合理或者无意义的输入数据所构成的集合称为无效等价类
        
        ·标准：
            完备测试：将集合划分为互不相交的一组子集、而子集的并集是整个集合
            避免冗余：子集互不相交
            
        ·设计方法：
            1).在输入条件规定了取值范围或值的个数的情况下，则可以建立一个有效等价类和两个无效等价类
            2).在输入条件规定了值的集合或者规定了必须如何的条件、可确定一个有效等价类和一个无效等价类
            3).在输入条件是一个布尔量的情况下，可以确定一个有效等价类和一个无效等价类
            4).在规定了输入数据的一组值，并且程序要对每一个值分别处理的情况下，可确定N个有效等价类和一个无效等价类
            5).在规定了输入数据必须遵守的规则的情况下，可确定一个有效等价类和若干个无效等价类(从不同角度违反规则)
            6).在确知了已划分的等价类中各元素在程序处理中的方式不同的情况下，则应该将等价类进一步划分为更小的等价类
            
        ·等价类测试用例设计原则：
            1).为每一个等价类规定一个唯一的编号
            2).设计一个新的用例，使其尽可能多的覆盖尚未被覆盖的有效等价类，重复这一步骤，直到所有的有效等价类都被覆盖为止
            3).设计一个新的用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步骤，直到所有的无效等价类都被覆盖为止
            
    5.边界值
        是对等价类划分方法的补充
            ·上点有效、离点无效
            ·上点无效、离点有效
            
            上点：即取值范围的端点
            离点：及取值范围端点左右两边的值
            
    6.错误推测法 
        基于经验和直觉推测程序中所有可能存在的各种错误，从而针对性的设计测试用例
        
        如： 
            ·对于日历控件需要考虑闰年的2月29号
            ·多条相同数据，怎样排序
            ·密码中加入空格
            ·密码不支持拷贝，但是可以在密码输入框中粘贴内容
            ·两用户同时删除同一条数据
            ·不勾选数据，删除数据，应有提示消息
            ·查找的时候输入通配符
            ·新增时考虑数据是否唯一
            ·app软件使用过程中来电话、软件是否能够继续使用
            ·退出用户登录界面、使用Backspace键回退，是否能够回退到登录界面
            
    7.场景法
        
        概念：又称流程分析法、是将软件系统的某个流程看成路径、用路径分析的方法来设计测试用例，根据
              流程的顺序依次进行组合，使得流程的各个分支都能覆盖
              
        设计测试用例的步骤：
            ·分析需求、根据需求规格说明书描述出程序的基本流程和各项备选流
            ·根据基本流和备选流生成不同的场景
            ·对每一个场景生成相应的测试用例
            
        举例：
            电商网购平台
                基本流：
                    打开网购平台----->注册账号----->登录账号----->挑选商品----->加入购物车
                    ----->提交订单----->支付订单----->生成订单----->卖家发货----->买家确认收货
                    ----->评价商品----->售后流程
                    
                备选流：
                    ·未注册平台账号
                    ·用户名密码错误
                    ·没有选购商品
                    ·支付密码错误
                    ·支付账号余额不足
                    ·用户选购商品时退出了系统
                    
    8.黑盒测试用例设计方法选择的策略
        ·首先进行等价类划分、将无限的测试变成有限
        ·在任何情况下都必须使用边界值分析方法
        ·然后使用错误推测法追加一些异常场景的用例
        ·对于业务流程清晰的系统、可以采用场景法贯穿整个测试流程

测试执行

    1.概念：根据编写的测试用例、按照用例步骤进行执行，查看预期结果和实际结果是否一致，如果不一致则为bug
    
    2.参考依据：测试用例
    
    3.执行人：软件测试工程师
    
    4.开始时间：测试用例编写完成并通过评审，且达到测试执行的准入条件
    
    5.时间周期：占整个项目周期时长40%左右的时间
        测试执行过程中时间的安排，假设总的项目周期为66天
        测试执行分为三轮测试，时间安排如下：13:8:5--------->按照5:3:2的比例进行分配
        测试执行分为四轮测试，时间安排如下：10:8:5:3------->按照4:3:2:1的比例进行分配7.
        
    6.输出文档：测试执行结果
    
    7.测试用例的执行结果
        new：用例尚未被执行时的状态
        pass：当执行结果和预期结果一致
        fail：当执行结果和预期结果不一致
        block：当因为软件有缺陷而妨碍了测试用例步骤的执行，且该缺陷不是我们的测试点
        investigate：当用例在执行过程中需要消耗较多的时间来观察期间的结果
        
    8.执行测试过程中的注意事项
        ·搭建软件测试环境
        ·测试用例全部执行
        ·不要忽视任何的偶现现象
        ·加强测试过程中的记录
        ·提交缺陷时与开发关系处理要恰当
        ·提交一份优秀的问题报告单
        ·及时更新测试用例
        
    9.提交缺陷时，开发人员不认可缺陷怎样处理？
        ·首先进行自我检查，依据需求确定该缺陷是否有问题
        ·确定是问题，拿出依据，与开发人员有理有据地沟通
        ·如果沟通无效，告知测试经理，经问题升级提交给项目组变更控制委员会(CCB)裁决是否为问题
        
    10.缺陷的分布特征
        ·群集现象(二八定律)
        ·测试进行得越多，新缺陷就越难被发现，此时需要拓宽测试思路，寻找新的突破点
        ·并非所有的缺陷都需要修复
            如：修复风险太大，不值得修复
                没有足够的时间进行修复，并且该缺陷不会影响本版本发布的新功能
                
    11.测试执行过程中发现的bug太多，怎样处理？
        ·说明冒烟测试进行的不充分，不彻底
        ·发现bug越多的模块，残留的bug也越多，同时说明开发的编码质量太差，会影响到测试的质量和效率
          此时应该将版本打回，要求开发人员自测，自测通过后再提交代码
          
    12.幽灵bug的处理方案？
        ·截图、保留证据、必要时录制视频、抓包、查看日志文件
        ·在本机进行多次尝试重现该问题，若能够重现，则记录该问题
        ·若不能重现，则在其他电脑尝试是否能够重现该问题
        ·若不能重现，但是问题比较严重，找开发人员协助定位
        ·对于难以重现或者偶发性问题，不能马上关闭问题单，需要将问题单
          挂起，看后续版本是否存在，如果不存在，在关闭问题单
          
    13.缺陷的内容
        缺陷ID 、缺陷标题、缺陷状态、缺陷级别、缺陷优先级、测试版本、测试阶段、缺陷类型
        重现步骤(缺陷描述)、实际结果、预期结果、缺陷所属模块、提交人、提交时间、修改人
        修改时间、关闭时间、附件
        
        ·缺陷ID：缺陷的编号，bug管理系统自动生成
        
        ·缺陷标题：对所发现的bug通过简洁的文字进行描述
        
        ·缺陷状态：
            1).软件测试工程师发现问题，在缺陷管理系统提单给开发人员，此时bug的状态为new
            2).开发人员打开测试人员提交的缺陷，确认问题是否存在，此时bug的状态为open
            3).开发人员确认是bug，并且将该bug修复完成后，此时bug的状态为fixed
            4).测试人员回归测试验证开发修复的bug，验证通过，此时bug的状态为closed
            5).开发人员确认测试提交的bug为非问题，此时bug的状态为rejected
            6).开发人员确认测试提交的问题是问题，并延迟解决，此时bug的状态为pending
            7).测试人员回归测试验证开发修复的bug，验证不通过，此时bug的状态为reopen
            
        ·缺陷级别：致命、严重、一般、轻微
            致命：程序的主要功能丧失，系统崩溃、闪退等现象导致程序不能使用
            严重：由于该问题引起部分功能无法使用、程序的接口错误、导致功能交互失败
            一般：重要界面显示错误、关键步骤未给出有效提示、下载数据时无进度条提示
            轻微：界面的排版错误、系统操作不方便，但是可以使用
            
        ·缺陷优先级：4、3、2、1
        
        ·测试版本：即本次发布新功能的版本号
        
        ·测试阶段：BVT(build verification testing)冒烟测试
                    SIT(system integration testing)系统集成测试
                    UAT(user acceptance testing)用户验收测试
                    
        ·缺陷类型
            文档缺陷：文档不容易理解、文档缺失、文档描述错误
            设计缺陷：主要指的是需求设计不合理
            配置缺陷：软件在使用过程中配置文件、导致的缺陷
            界面缺陷：系统界面排版、界面中文字错误
            功能缺陷：功能没有正确实现
            性能缺陷：业务处理性能低、查询性能低、统计报表性能低
            可靠性缺陷：用户登录错误、用户权限导致错误、越权操作
        
        ·缺陷描述：又称为重现步骤，指导开发人员具体怎样去重现该问题的步骤
        
        ·实际结果：执行用例后得到的结果
        
        ·预期结果：需求中期望实现的结果
        
        ·bug所属模块：bug在那个模块下测试发现的
        
        ·提交时间：发现问题的时间
        
        ·提交人：发现问题的软件测试工程师
        
        ·修改人：缺陷修复对应的开发人员
        
        ·修改时间：开发修复完问题的时间
        
        ·关闭时间：软件测试工程师回归测试，关闭问题的时间
        
        ·附件：主要是为了开发人员快速定位问题，提供分析问题的依据，通常有：截图、抓包、录制视频、报错的日志文件
        
    14.提单的5C原则：
        ·correct(准确)：问题单中每个组成部分的描述准确，不会引起误解
        ·clear(清晰)：问题单中每个组成部分描述清晰，易于理解
        ·concise(简洁)：只包含必不可少的信息，不包含任何多余的内容
        ·complete(完整)：包含复现该缺陷的完整步骤
        ·consistent(一致)：按照一致的格式书写全部缺陷报告单
        
    15.缺陷的生命周期
        ·提交、确认、分配、修复、验证、关闭
        
    16.常用的bug管理工具
        禅道(zentao)、bugfree、QC、mantis、DTS……

                
测试报告 

    1.概念：主要是对测试结果、测试过程中质量和产品质量进行评估、总结和描述
    
    2.参考依据：测试计划、测试用例执行结果、缺陷数据
    
    3.负责人：测试经理或者测试组长
    
    4.开始时间：测试用例执行完成且达到测试结束的标准，编写时间通常为1-3天
    
    5.评审人：组内的测试工程师、开发代表、产品经理、测试经理、项目经理、QA
    
    6.测试报告中的内容
        项目背景、测试目的、测试范围、测试策略、测试环境、测试工具、人员组成
        人力资源和工作量的投入数据统计、遗留问题、测试风险、测试过程中质量的评估
        测试结论、规避措施、附件
        
        测试策略：
            功能测试、性能测试、兼容性测试、冒烟测试、回归测试、集成测试、安全性测试……
            
        测试用例的数据统计
            三个月的项目用例数在1200-1500之间
            一个月迭代一次的项目用例数在200左右
            
        缺陷数据统计
            三个月的项目缺陷数在270-300左右
            一个月迭代一次的项目缺陷数在80-100左右

质量

    1.质量包含内部质量、外部质量、使用质量
        外部质量：明确的需求
        内部质量：隐含的需求
        使用质量：用户在使用过程中对产品的质量进行评估
        
    2.影响质量的三要素：技术、流程、组织
    
    3.CMMI：软件能力成熟度模型综合
        初始级、受管理级、已定义级、定量管理级、持续优化级
        
    4.质量的六大特性及27个子特性
        
        ·功能性：适合性、准确性、互操作性、安全保密性、功能性的依从性
        ·可靠性：成熟性、容错性、易恢复性、可靠性的依从性
        ·易用性：易理解性、易学性、易操作性、吸引性、易用性的依从性
        ·效  率：时间特性、资源利用性、效率依从性
        ·维护性：易分析性、易改变性、稳定性、易测试性、维护性的依从性
        ·可移植性：适应性、易安装性、共存性、易替换性、可移植性的依从性