汇总：测试基础理论

Love The Way You Lie 2022-05-08 09:20 256阅读 0赞

软件产品的组成：  
    程序+数据+文档  
      
软件开发过程：软件产品从最初的构思到公开发行的过程      
      
软件开发模型：  
    瀑布  
    V  
    W  
    迭代  
    敏捷  
      
瀑布模型：  
    线形、顺序的开发模型  
      
    上一个阶段完成后才能进行下一个阶段  
      
     计划：项目经理                  计划  
     需求分析：产品经理                写文档《需求文档》/《需求规格说明书》  
     设计：架构师、设计部门           框架、UI界面                                        框架和静态界面  
     编码：研发                        实现需求规格说明书中的需求                            程序  
     测试：测试部门                    验证程序是否与需求规格说明书中的需求一致            测试报告  
     运维：运维部门                    管理和维护生产环境中的代码                            生产环境  
       
    瀑布模型特点：  
        线性化模型结构

各阶段具有里程碑特征

基于文档的驱动

严格的阶段评审机制

瀑布模型的优缺点：  
        优点：  
       --有利于大型软件开发过程的人员的组织和管理  
       --有利于 开发方法和工具的使用  
       --提高了软件的质量和效率  
        缺点：  
       --各阶段的划分完全固定，阶段之间产生大量文档，极大的增加了工作量。  
       --由于是线性的，用户只有等到末期才能见到开发成果，极大的增加了开发的风险。  
       --早期的错误可能要等到开发后期的测试阶段才能发现，极大的增加了修复成本。

V模型：      
    需求分析                            验收测试    --质量保证  
        概要设计                    系统测试        --SIT 测试  
            详细设计            集成测试            --开发、测试      
                编码        单元测试                --开发

优点：  
        1.既有底层测试又有高层测试  
        2.将开发阶段清楚的表象出来，便于控制开发过程  
        3.当所有阶段都结束时，软件开发就结束了

缺点：  
        1.容易让人误解为测试是在开发完成后的阶段  
        2.由于它的顺序性，当编码完成之后，正式进入测试时，这时发现的一些bug可能不容易找到其根源，并且代码修改起来很困难。  
        3.实际中，由于需求变更较大，导致要重复变更需求、设计、编码、测试。返工量大。

W模型：  
    需求分析            需求测试                                系统安装            验收测试  
        概要设计            概要设计测试                    系统构建            系统测试  
            详细设计            详细设计测试            模块集成            集成测试  
                编码实现            单元测试  
          
          
    优点：      
        1.将测试贯穿到整个软件的生命周期中，且除了代码要测试，需求、设计等都要测试。  
        2.更早的介入到软件开发中，能尽早的发现缺陷进行修复。  
        3.测试与开发独立起来，并与开发并行。

缺点：  
         对有些项目，开发过程中根本没有文档产生，故W模型无法使用。 对于需求和设计的测试技术要求很高，实践起来很困难。

迭代式开发：  
    迭代增量式开发、迭代进化式开发  
      
    在迭代式开发方法中，整个开发工作被组织为一系列的短小的、固定长度（如3周）的小项目，被称为一系列的迭代  
          
    迭代一个版本

软件项目成员：

\--------------------------------------------------------  
    软件的质量：  
        内部特性  
        外部特性  
        使用特性

针对一个纸杯如何进行测试：      
        1.装水  
        2.喝水  
        3.会不会漏水  
        4.是否耐高温，是否烫手  
        5.容量、大小、形状、外观  
        6.有没有毒、材料是否安全  
        7.是否可回收  
        8.异味  
        9.是否会刺手、是否防滑  
        10.液体、固体、化学药品是否能装  
        11.长时间装水时  
        12.硬度，是否抗摔，抗压性，能承受多大的力  
          
          
软件测试的概念：      
      
      
      
回归测试：  
    回归问题本身的bug  
    回归相关的功能  
          
          
验收测试：  
    正式验收：  
    α测试：开发在旁边  
    β测试：开发不在旁边  
          
          
测试流程：  
    需求分析  
    测试计划  
    测试方案  
    测试实现：测试用例、编写脚本、环境搭建  
    测试执行：测试用例执行、bug管理、测试报告  
          
          
测试需求：  
    功能性：  
        切换不同的注册方式  
        手机号码：11位，1开头，第二位不能012  
        图片验证码：图片验证码值一致，图片更换  
        验证码获取：发送短信给手机号码，60S后再次获取  
        短信验证码：在规定时间内有效，值为正确  
        密码：少于6位，6~16之间，大于16位，大小写，不同的类型  
        确认密码：与密码一致  
        超链接，勾选框，勾选框与立即注册之间的关联  
        立即注册：是否可点  
      
    非功能性：  
        字体颜色、大小、排版、输入框、按钮  
          
    共用需求：  
        注册方式的标题文字一致，颜色一致，选中的文字为白色  
        输入框前的标题：必填项带\*号，文字右对齐，字体颜色大小一致  
        输入框下面的提示文字：为灰色，选中输入框时下面的字体变为黑色，输入框变为黑色  
        链接字体颜色：蓝色，大小一致  
          
          
          
          
          
    功能性：  
        登录：职员代码、密码，密码不匹配，密码匹配：密码过期  
        密码使用等于或大于90天，超链接  
        密码变更：  
            原密码：正确、错误  
            新密码：小于6位，6~10位，大于10位，数字和字母(大写、小写)，其他文字符号  
            确认密码：与新密码一致  
      
    非功能性：  
        界面布局、文字颜色、大小、按钮、输入框  
          
    共用需求：字体颜色、大小  
          
          
\------------------------------------------  
测试用例：  
    用例八要素：  
        用例编号  
        用例标题  
        项目名称  
        优先级  
        预置条件  
        测试输入  
        操作步骤  
        预期结果  
          
          
    用例编号：  
        通过测试用例编号能得到产品编号、测试阶段、项目名、测试功能  
          
        编号规范：  
            产品编号-/\_测试阶段(ST，UT，IT)-项目名-测试功能-001  
          
          
          
          
    测试项目：  
        测试哪块的功能模块就写哪个功能模块  
          
      
    用例标题：\*\*  
        用一句简单的话描述用例关注点  
        用例标题不能重复  
          
      
    优先级：  
        高：核心业务，基本流  
        中：基本业务，备选流  
        低：一般业务，备选流  
          
          
    预置条件：(前提条件)  
        执行测试用例时需要满足的前提条件  
          
        3种前提：  
            1.环境设置  
            2.先执行其他用例  
            3.需要某些权限才能执行  
          
      
    测试输入：  
        执行测试用例时需要输入的外部信息  
              
            3种信息：  
                1.手工输入（数据）  
                2.文件(上传)  
                3.数据库记录(单元测试)  
                  
    操作步骤：  
        执行用例的过程描述清楚  
          
      
    预期结果：  
        用例中最重要的部分，直接影响到测试的结果  
          
        1.界面提示  
        2.数据库变化  
        3.相关信息的变化

商品品牌：  
                贵人鸟1-->贵人鸟  
                  
            商品--贵人鸟1-->贵人鸟

前台界面商品品牌信息

等价类：  
    是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例  
    如果子集中的数据不会让程序出错，那么子集中其他的数据也不会出错

有效等价类：  
      
      
    无效等价类：

什么情况下用到等价类划分：  
        1.规定了取值范围  
        2.规定输入值的集合  
        3.输入条件为布尔量时  
      
    如何使用：  
        1.划分为有效和无效两类  
        2.列出所有的有效类和无效类  
        3.用最少的用例覆盖最多的有效类  
        4.一种无效类对应一条测试用例  
      
      
      
      
边界值：  
    边界上的值作为测试数据进行测试  
      
    应用范围：  
        1.输入条件规定了值的范围  
        2.规定了值的个数  
        3.给出了输入域或输出域的集合  
        4.内部数据结构，给出了长度  
      
      
      
      
      
    上点  
    离点  
    内点  
      
    上点：边界上的一个点  
    离点：  
        闭区间\[\]：上点外的点    闭区间:包含边界上的点   6>=位数<=20  
        开区间():上点内的点        开区间:不包含边界上的点   6>位数<20  
    内点：范围内的任意一个点

长度6~20位：闭区间  
      
    上点：6，20  
    内点：7~19任意一个点  
    离点：5,21  
      
    长度6~20位：开区间  
    上点：6,20  
    内点：7~19任意一个点  
    离点：7,19

错误推测法：  
    基于 经验和直觉设计测试用例  
      
      
          
场景法：  
    也叫流程分析法，把程序看成路径，用路径分析方法来设计测试用例  
      
      
          
淘宝购物：

判定表：  
    建立判定表可遵循的步骤：  
        1）列出条件桩和动作桩  
        2）确定规则的个数，用来为规则编号。  
        　若有n个原因，且每个原因的可取值为0或者1，那么将会有2n个规则。  
        3）完成所有条件项的填写。  
        4）完成所有的动作项的填写。（得到初始判定表）  
        5）合并相似规 则，用以对初始判断表进行简化。  
          
        合并原则：  
            动作项相同，条件项N-1个相同

\-----------------------------------------------------  
测试用例评审：  
    1.评审用例对需求的覆盖率是否达到100%  
    2.测试用例是否有遗漏的(一个功能中测试用例是否有遗漏)  
    3.测试用例的期望结果是否正确  
      
    用例评审：  
        部门评审  
        项目组评审

冒烟测试：挑选优先级高的用例  
      
    系统测试阶段：  
          
        用例执行：  
            查看预期结果与实际结果是否一致

测试执行顺序：  
            先功能，后性能，系统较稳定或更新较慢时进行自动化测试  
                (接口性能测试不需要功能完成，只要接口联调通过)  
            一般按照模块执行：先执行有效的，再执行无效的  
            项目紧急时，先执行优先级高的用例  
            探索性测试

测试执行：  
        环境搭建：  
            文档开发提供  
            网络上找环境搭建手册，搭建好基础环境，代码包问开发人员修改配置信息(数据库连接，日志文件)  
              
            环境更新：  
                只需要更新代码包即可，基础环境(LAMP，LJMT)不用动  
          
                /usr/apache2/htdocs/suger    --替换整个suger文件夹即可  
                tomcat/webapps/suger        --替换整个suger文件夹即可

.java--->.class    全量包：.war        增量包：代码、配置文件不更新 .zip   
          
        注意用例的前提条件和特殊说明：  
            执行用例的顺序  
          
        测试用例要全部执行：  
            为了避免漏测  
          
        不要忽视任何偶现问题：  
            隐藏较深，比较难发现  
                不要忽视任何测试过程中的小细节，看系统日志  
                系统日志：  
                    1.代码包中配置文件中的日志文件(log4j.properties log4j.xml)  
                    2.web服务器日志：  
                        apache：/usr/logs/http        apache/logs  
                        tomcat:tomcat/logs  
          
        加强测试过程记录：  
            测试用例标记，是否已执行，执行情况  
              
            发现错误后，提交到缺陷管理系统中，日志记录，记录在缺陷中  
          
          
        详细记录预期与实际结果的不一致：  
            记录实际结果是什么情况，提交bug到缺陷管理系统中  
          
        提交缺陷时与开发的关系处理：  
            有理有据提出问题  
          
        测试用例的更新:  
            1.测试用例补充  
            2.测试用例无法执行时删除  
            3.冗余测试用例删除  
            4.测试用例修改  
              
    关于缺陷：  
        缺陷、bug、错误、问题

缺陷：  
    缺陷定义：  
        1.软件未实现需求和规格要求的功能  
        2.软件出现了需求和规格指明不该出现的错误  
        3.实现了没有提及的功能  
        4.未实现没有明确提及但应该实现功能  
        5.难以理解，不易使用，运行缓慢，或用户认为不好  
        6.预期结果与实际结果不一致  
              
    缺陷定义标准：  
        1.与需求不符  
        2.不符合用户习惯

测试结束标准：  
        1.用户执行率100%  
        2.严重和致命的缺陷修复率100%  
        3.一般和轻微缺陷修改率95%  
        4.缺陷呈收敛状态  
        5.遗留问题经过三方评估