测试基础2

2.过程质量（管理者）

1. （能力成熟度模型）CMM质量管理体系（主要做过程，看重过程和文档）（行业标准）：
标识：软件 开发管理水平
强调软件 过程改进
体现承接项目的能力
核心：把开发视为一个过程，对每个阶段进行把控，
目标是：让每个阶段：更科学化，更合理，有一个标准进行监控，更标准，最终实现 商业目标，让整个软件开发风险降得更低


CMM质量管理体系等级：
初始级
重复级：借鉴有的东西，拿来照猫画虎
定义级：定义、实施这个过程
管理级：在3这个过程上，度量标准，根据标准管理
优化级：优化，不断完善改进过程



题：
1.质量模型解决的是什么问题？并说出你所知道的质量模型？
解决产品质量问题，我们来验证。。。。。（其他要自我扩展）

2.质量管理体系解决的是什么问题？并说出你所知道的质量管理体系？
解决：1.给没有规则体系以及质量不稳定的组织一个向上的标准体系，是在质量方面指挥和控制组织的协调活动的优化，从而让公众相信企业具有一定的产品质量保证能力和质量管理水平
      2.ISO9000一族（是一类标准的统称）：ISO9001、ISO9002、ISO9003、ISO19011

3.SQA和QC的区别和联系？***

4.测试是为开发服务的吗？（或者问叫你必须选一个证实或证伪）（开放性）***

相辅相成，终是为公司盈利，开发为正方面（证实）保障，测试为反方向（证伪）保障，都是保障产品质量

不行，一定要两个都要

5.各个质量属性，分别与哪些测试类型对应？
软件质量的总结



 2.敏捷（不看重过程和文档）
 



项目管理：  

            进度（按时）(一定不能延期，成本最高)

           
           铁三角   

     成本           质量


质量度量（量化）：
没有描述就没有度量
没有度量就没有产品

seven：


软件定义：
程序+数据（内部数据和外部数据）+文档
程序：源程序（满足用户需要的功能的源程序）
数据：
 1.外部数据
  输入、输出
 2.内部数据
文档：软件开发过程中一系列的文档。比如使用说明书（面向用户、面向开发者的）


被测对象：软件
可用、能用（大多数用户认为是有效的）、好用

软件测试7大原则
1、测试尽早介入
2、穷尽的测试是不可能的
3、测试显示软件存在的缺陷
4、缺陷集群性
5、杀虫剂悖论
6、测试活动依赖于测试内容
7、无错就是最好的谬误
软件测试潜规则
1、 可以规划缺陷的数量
2、 测试在前期工作只能是学习
3、 姜是老的辣，用例是陈的香
4、 任何一个项目都是可以复制的
5、 超出设计规格的缺陷不是都是缺陷
6、 规格是测试出来的，不是设计出来的

软件正确理解：
       1.运行时，提供要求的功能和性能的计算机程序集合
       2.程序能正确处理信息的数据和数据结构
       3.提供给人们可读的、可理解的技术数据和图文资料




测试对象：程序(开发+脚本)、数据、文档 (需求说明书、用户手册)(详细设计、概要设计、需求分析、用户需求)
测试级别（测试阶段）：单元测试(UT)、集成测试(IT)、系统测试(ST)、(用户)验收测试(UAT)
测试方法：*************************
 1. UT、IT、ST、UAT（按阶段、级别分类）：*******************************

     UT(最小力度的测试(函数、程序代码等)，通过详细设计说明书来检验，功能性)
     IT(把已经通过单元测试的模块集合起来，检验是否符合概要说明书，通过 接口来看功能(接口、架构、ui))
     ST（检验是否符合需求规格说明书）（有前中后3轮，UAT可以提前到2轮(1.预测试、ui。2.回归、功能。3.回归、功能、性能)）（一定要在用户环境下测试，一致）
     UAT(用户(外部用户、内部用户)验证软件产品与用户需求的符合程度)
Alpha测试：受控测试，用户不一定参加
Beta测试：不受控测试，一定有用户代表参加的，研发人员有可能会在有可能不在(更严)


 2. 黑白灰


    黑盒(IPO)：只关注输入和输出结果，不关注内部结构(依据文字类用例)，主要站在用户的角度进行，（基于需求规格说明书）
    白盒：关注程序内部结构(依据代码用例)，开发角度


 3. 自动化、人工          
 4. 动、静(3类静态:走查、检视、评审(严))(静态被测对象：代码、文档、ui原型)（从运行起来的角度）（基于逻辑结构，设计说明书）
 5. 开发、用户、第三方
冒烟测试：来源硬件




题：
1.黑、白测试和UT、IT、ST的联系？
 ut有黑白，以白为主 黑辅(因为对单元的认识不同)，测试主体：开发人员
 it黑白间
 st以黑为主，白辅，测试主体：测试人员


很多企业：
 第一种：（很多企业跳过it，ut下阶段集成和系统组合直接sit）
 第二种：持续集成


2.黑、白测试和静态、动态的联系？
黑：静：评审（规格文档）。动：程序运行起来
白：静     动：
3.黑盒和白盒测试的定义和区别？
4.alpha、beta测试的区别？*************
5.有it为什么还要有st？
ut、it都是测功能性，质量不仅测功能还有性能，功能基础，终质量






测试策略：





（st）系统测试类型：
1.功能测试
  

  1、业务测试：与单个模块没有太大的关系。应该对不同的模块组合起来实现不同的业务，来进行测试。功能+业务流程(各个功能组合起来实现的业务流程)。
  2、通过测试(正向)：测试时，所有的输入、预期等都是正确的。
  3、失败测试(反向)：测试时，所有的输入、预期等都是错误的。

 

验证系统提供的功能是否符合用户需求
功能测试的主要测试内容：
1.验证这个功能有没有
2.验证这个功能是否正确
3.验证这个功能是否冗余
需求来源不明确或没有需求就对一个系统的功能进行测试，应该如何进行：增、删、改、查。
增、删、改、查指的是在测试功能点的时候，尽可能的往这四个方向去测试。

2.专项测试：

  性能测试(属于质量的一个环节) (检测系统是否满足用户要求的性能指标)
    负载测试：施加负载量的过程，直到测试到极限
    压力(强度)测试：当确定最大负载量时，直接给一个重的压垮，看系统的恢复力和响应力
    可靠测试：两次故障时间间隔越短，越可靠
    稳定测试：越可靠越稳定
 
    配置测试(更多是在硬件。目的：验证软件在不同硬件的配置下软件的运行能力)
    并发测试
    容量测试
    基准测试


  兼容性测试（特定的硬件平台之下，不同软件间、操作系统、网络环境、数据库等下的运行能力）(更多是在软件)((wps、office叫数据兼容)、向前向后兼容、版本兼容、标准和规范(少))
     确定系统兼容在哪个浏览器运行？
     1.调研客户的浏览器使用习惯
     2.看是什么客户
     3.厂商
     4.浏览器收费否、年限
  安全性测试（安全、防护提高让攻击者所付出的代价不成正比）（目的：验证系统的安全机制具 合法 方式访问，同时防范 非法 的侵入）（包含 数据备份和恢复测试(少单独列出)）
     测合法访问一般是功能测试，方式有：1.用户权限设置。2.密码复杂度设置。3.安全日志(和 4.数据权限(数据库)绑在一起)(涉及隐私要加密)
     测非法方法：1.安全扫描(app scan)。2.攻击手段(跨站点脚本攻击)
  回归测试
  易用测试（文字、图片、导航(菜单测试)、链接(死链)、文档）
  文档测试(操作手册提供方式在线(快捷键f1)还是离线。1.目标群体：用户群体是谁。根据面向的群体内容不同。2.检查，操作手册提到的功能一定要是实现的。3.使用手册注意事项是否和软件吻合)
  本地化测试
  国际化测试
  安装测试（安装、升级、卸载(反安装)。1.是否提供安装手册。2.是否有程序的依赖包。 校验安装成功：1.界面反馈是否有响应反映。2.运行一下是否成功。3.写入文件位置是否存在。(安装程序路径尽量不超过三层)）

  

**********************************************************************************************************************题
题：
1.没有需求，需求不明确，让你展开测试，怎么测功能？
对增删改查展开测


2.专测和用户来测得区别？
查看数据库，比对。通过用例的预期结果看出




业务功能模块（功能+业务流程）(业务测试、正反测试)


过程：用户需求 -》需求分析（需求分析工程师） -》 概设 -》 详设
                                                （概详是核心）

一般企业：  
1-2过程：需求-细化-需求文档-评审
2.（需求规格说明书 也叫 基线）
  
                         （2个必要）
功能模块难度：核心 基本 辅助(支持)

写需求时注意：1.每个模块简述功能是做什么的
              2.最好开始有背景，概论，摘要
              3.某些地方有些用例


写前可以有一个总体要求，包括系统架构，什么语言，等等


评审：1.有歧义
      2.结果不唯一
      3.前后不一致



******************************************************************************************测试执行流程
测试的执行流程：1.需求评审
                2.预测试
                3.回归测试
                4.交叉测试


评审属于哪里？（各有各的分发）
1.软件研发角度：需求分析
2.测试角度并分流程阶段的角度：执行阶段
3.很多企业把流程12放一起



需求测试是一种黑盒测试流程策略。通过分析检查系统的需求定义，尽早地修正和验证需求，然后使用各种黑盒测试设计方法来设计：最小数量的测试用例，满足最大的需求功能覆盖


需求变更


*************************************************************************************************************SRS作用
SRS的作用：1.用户：与用户达成一致，是一个需求沟通的结果 （外部作用）
           2.开发：进度、计划、设计、实施提供基础 （内部作用）
           3.测试：STP、用户手册、提供基础 （内部作用）


*************************************************************************************************************需求测试检查点
需求测试检查点：1.完整性：包含所有的需求；输入处理；确定与待确定的都要标识
                2.正确性：正确描述软件需要实现的功能
                3.二义性：需求传递失真
                4.一致性：各子系统间不矛盾、不冲突
                5.可验证性：可验证，可实现
                6.统一性：ui界面风格，操作的提示
                7.易理解性：需求中是否有需求的原因背景、用户使用场景，采用 用户能理解的语言表达等。多问why，是核心功能？支持功能？等。



*************************************************************************************************************测试计划
什么是测试计划？
      明确测试的对象，并且通过对资源、时间、风险、测试范围的预算、人力、测试通过失败标准等方面的综合分析和规划，保证软件测试工作有效的实施
      资源（人、系统、硬件、软件、网络）
      时间（什么时间做什么事、什么时候完成）
      风险（做事情都有风险，对高风险模块重点测试）
      测试范围（哪些测，哪些不测）

      预算（经济成本）（文档一般不体现）

测试计划要写的内容：

项目说明   =====   项目是干什么的

测试范围   =====   明确 测试对象 *

测试手段和策略   =====    用黑、白，哪些测试技术 *

通过和失败标准   =====    测试可交付性，达到什么程度，测试可以交付用户 *

暂停和重启测试的标准

测试的可交付性

测试任务分配    =====    测试人员、任务量分配、级别 *

测试用例规范（基本）：

1.编号（从001开始）

    命名规则：1 产品名称—st—系统测试项（大的模块）—测试子项—001

              2 产品名称—st—测试类型（FUNC）—系统测试项—001

    作用：用例编号和相应文档的对应关系：1 需求覆盖

                                  2  测试报告

                                  3  缺陷报告

2.项目名称（可以加测试子项）

模块覆盖率

子模块（测试子项）

和用例编号中的：测试项—测试子项对应起来·

*3.标题

要求：简明扼要，重点描述（不超20字，不要重复），通过标题反映测试的是什么

 

4.前置条件（没前置条件操作步骤繁琐，作用：总结语言）

在什么样的状态下，去做下面的事（规定测试用例执行的前置条件）

可以包括测试环境

*5.操作步骤（怎么做，做什么）

完整性、清晰性、可操作性

可以把动作和输入数据放在一起

6.用例级别（优先级，根据功能模块来分）

划分目的（重要紧急程度(先测)）

划分依据（按照功能的重要程度）

如何确定用例的优先级（分级目的：重要的先执行，重要的先测，不重要的后测或者不测）

正向（基本流）

逆向（备选流）

1非常高：核心+基本

2高：核心+备选，基本+正向

3中：基本+备选，

4低：基本+备选

 

题：

可不可以带风险发布版本？

可带风险发布（根据功能模块(核心、基本、辅助)分大小—用户的影响程度）

 

*7.预期结果

根据SRS，用例执行后，期望得到的结果

输出结果要求

8.执行结果（用例执行结果）

通过，（实际与预期相符）

失败，（实际与预期不相符）

阻塞

 

题：（面试）

1. 你们项目组要不要写测试用例？

2. 你们公司的用例规范怎么制定的？为什么？

刚开始怎么组成的---》后来发现问题---》怎么改进的

3.用例最难的？

一个用例几个人执行，结果不唯一

4.没有用例怎么办？进度紧张怎么测试？（面）

熟悉团队–》为什么会没有

基于个人经验写出简易化的用例（chicklist），当做测试标题，测试点，围绕这个走（缺点：依赖于设计的人、执行的人）

5.用例的价值有哪些？

6.测试用例有哪些作用？

 

 

用例管理

1.      用例工具的选择

2.      用例结构与元素的设计

3.      用例维护

黑盒测试用例设计方法：

1.基于用例：

1.基于输入、输出：等价类

边界值

2.基于条件组合：因果图

正交试验                                                 

判定表                                         

3.基于状态转换：状态转换

4.基于流程分析：场景分析（重点是测流程，流程涉及的功能他是不关心的）（功能流程不会分开，都测）

2.基于缺陷

5.基于个人经验：错误推测

1. 等价类

什么是等价：任意挑选的一个数据去发现错误 与验证软件能成功运行还是缺陷是等价的

有效

无效

使用步骤：

1.      根据输入项划分有效和无效有哪些（例：输入项：皮肤颜色。有效：黄。无效：黑、白）

2.      为每个等价类编号

3.      设计用例尽可能多的来覆盖有效和无效，直到完成

一条尽可能多的覆盖有效。1-n

一条覆盖一条无效。1-1

 

2. 边界值：（例：1-30）

上点：边界上的（1, 30）

离店：离边界近的点（0-31）

内点：边界内的（1-30）

一般测：有效：1，30。  无效：0, 31

有时间的话：测极值

 

（问：功能测试验证哪些）

3. 错误推测

新增功能测试：

正向（正面、通过）：

验证：正确输入各个字段值，看系统是否提交成功

预期结果：

 1.界面（提示操作成功的提示信息）

 2.功能（相关模块是否正确添加了数据）

 3.DB（数据库中是否添加了相关数据）

反向（负面，失败）

验证：错误输入页面当中，某个字段，是否会提示操作失败

预期结果：

1.界面（提示操作失败的提示信息）

 2.功能（没有产生相关数据）

 3.DB（没有相关数据记录）

验证：界面中各个字段名称以及控件类型，是否和需求保持一致

不急于开展测试  （软件的实现与需求的一致）

核对需求

校验：各个字段相应生成规则

长度、类型、格式  （等价类、边界值、对每个字段一一覆盖）

验证：页面中必填项字段 

界面：是否有标志、背景颜色  （UI、功能）

功能：实现是否正确       

 必填项不填时，是否有提示信息        

验证：页面字段唯一性

用户名  （1：界面：给提示 2：功能正确）

邮箱

已注册过的，是否再次注册     

 

验证：各个按钮功能 

如：确定、清除、取消  （控件）         

 相应的按钮功能是否实现正确                    

验证：权限限制

 时效性：在一定的时间范围内，你有此权限    

过了时效后，限制了此功能  

权限划分

验证：初始值  

是否有初始值  

初始值是否正确

验证：特殊字符  

输入/出数据为0     （边界值）

输入数据位：空格  

输入超长数据、极值数据   

特殊字符                        

验证：自动加载的数据

 如：高级选项，自动弹出的内容

 

 

删除功能的测试  ===常见测试点

         邮件删除，文件删除，记录删除，邮箱当中的删除

         通过测试：能成功删除； 失败测试：记录不被删除

         选择一条记录的时候，进行删除，系统是否提示操作成功，相关模块和数据库中是否删除数据；显示删除成功，数据库中未删除

         取消删除，来验证相关模块和数据库中，没有删除数据

         删除操作（不可恢复的操作），弹出确认删除的提示窗口，应该支持确定和取消相应的操作；高危行为，防止进行误删除

         验证删除：单条，多条，全部记录的情况，是否提示都正确，是否相应模块和数据库中显示都正确（无效：空）

         删除操作，是软删除还是彻底删除，软删除（没哟真正删除，只是在前台无法看到，任然存在于后台，或者其他位置，需要验证：软删除后，数据是否可以恢复）

         多记录分页显示的时候，验证删除功能是否正确，最后一页当中是否只有一条记录，删除是否会报错，页码是否会减1，并定位于前一页

         删除权限的验证，有权限的才可以；普通用户新增的帖子，只有本人或者管理员才可以删除

         易用性角度：批量删除是否支持（手机、邮箱）

         多条删除、全部删除、取消全选功能是否实现

         空数据的时候，选择删除

 

 

修改与查询？

修改：满足新增的需求规格    ===  关注数据库

修改：关注可修改项 与 不可修改项   ====  不可修改项，一条用例覆盖

 

查询结果：精确、模糊（单字符匹配、全模糊匹配）

查询方式：但条件查询/ 多条件查询

查询结果：对于查询条件的清空（常见：清空查询条件，不清空查询结果）

查询结果：关注翻页：关注数据列表的正确   =====   数据库sql语句

 

 

测试执行阶段的策略（常常用的测试）：

1.冒烟测试（预测试）-》

2.按用例执行-》（执行3轮，1.发现问题。2.改问题，没发现有bug加bug。3.改了再全面测一下）

3.发散测试-》（快捷键、符合用户习惯，密码不允许复制粘贴，什么时候自动清空）

4.交叉测试-》

5.回归测试

 

 

4.状态转换

有效类：有限。  无效类：无限

输入：事件。  输出：状态

状态：饿-》饱-》撑

事件：吃、等等等

5.条件组合

例题：

         1.全单值（所有都可以组合，但是只组合一次）简单、不完善

做法：

         2.简单组合（基本组合）（做加法）（相同+相同+不同，相同+不同+相同，不同+相同+相同）  （全组合：做乘法(等价于判定表)）

         3.全对偶

         4.判定表

 条件桩(输入项)      条件项（每个项的取值、数据）

定义：实质：把输入中所有可能的情况进行组合，并汇总所对应的操作结果。各种组合类型的全值组合

步骤：1.列出：所有的条件桩和动作桩（条件项、动作项）（根据需求分析输入输出）

                            （一般输0， 1,  或 Y， N）（条件桩、项之间与顺序无关）

                   2.计算规则的个数（用例条数）

                   3.填充条件项和动作项到判定表（实际就是在完善(用例)操作步骤、输入数据、预期结果）

                   4.合并/化简规则（业务处理来的）

                            合并规则：两条或两条以上规则有相同的操作，且条件项之间存在较为类似的关系，需要进行规则的合并，用—代替（合并后不同的条件随意选）

                            不推荐合并：在业务逻辑上是可以的，在业务逻辑上不确定

 

优点：1.充分考虑输入条件间的组合，对组合情况。覆盖充分

2.把复杂的问题按各种可能的情况一一列举出来，进行全部罗列，简明易于理解

3.每个用例覆盖多种输入情况，有利于提高测试效率

4.对输入条件间的约束关系做了考虑，避免了无效用例

缺点：1.输入较多时，判定表规模非常大

                   2.合并有可能存在着测漏的风险

                   3.是一个全值组合，会产生冗余用例

                   4.不能表达重复执行的动作

适用范围：输入输出比较多，输入之间和输出之间相互制约的条件比较多的情况 

        

5.  因果图（和判定表没有本质区别，因果图可以说是判定表，反之）

问：他们两有没有附属关系？

没有本质区别，和附属没有关系，一眼看不出输入和结果就可以画因果图

6. 正交试验（每一行一个用例）

4：因子（输入条件）

3：水平（每个条件下3个元素）

正交表设计步骤：需求分析，提取各分类 及分类下的元素

                    选择合适的正交表，进行套用

填入相应的数据，生成用例

定义：     使用已经创建好的表格（正交表(有很多个)），来安排试验并进行数据分析的一种科学试验设计方法                

特点：     1.用例代表性强，用例数量又不大

                    2.借助正交表，可以从大量的试验数据中，筛选出合适的、有代表性的值，从而合理展开测试。即简化了用例，又尽量充分覆盖测试（取值均匀）

缺点：分析出来的需求和已有的正交表不对应时，就不能用，有局限性

         7.两两组合

         测查询：花瓣查找（常规）（确定一个，先加再减）不同人思路不同，覆盖率不同

测试需求（贯通）：

测试执行(规范)（星号是必须测得）：

1.    冒烟测试(预测试)：

1测试员做预测试（测试环境(尽可能与用户环境一致)）

转测试前开发做，转测试后我们验证

2在进行正式或全面测试之前进行最基本的测试（初验）（只测1级）

3目的：暴露软件基本概念失效等严重问题

核心+正向测试：1级（占所有比例：10%-20%）             

核心+逆向测试：2级            

基本+正向测试：2级

*2.全面测试(用例测试)

完了之后做发散

3.交叉测试

4.发散测试

围绕这个点发散，防止随意性

*5.回归测试（1、2、3）

         *1针对发现的错误，对开发修改后进行再一次的验证，

         2验证修改后相关的模块是否有影响(交互)

         3对没有错误的也再进行测试，在迭代增量后，验证是否对老功能有影响（增加有风险）

 

前提条件：

         1开发修改错之后

         2这一轮回归上一轮（版本）（一版本最少修复78%再进入下一版本）

目的：

         1变更点(缺陷)本身实现的正确性

         2是否影响到原有功能的正确使用（交互模块、老模块）

软件变更：

         新增需求、变更需求

         缺陷修复

         代码优化，代码移植

策略：

1基于用例：

2基于bug：

缺陷

题：

1.      Bug单填写还有哪些需要完善的？

1 . bug定义模块

2 . bug解决说明模块

3. bug回归记录模块

2.      实际工作中，对于bug的管理会出现哪些现象？

1提交

2录入

3重现、主动、协助解决

4用例更新

5评审

6回归

7版本发布

8线上问题

9偶发bug（不一定会重现）

10特定的数据发现特定的bug（边界）

3.      实际工作中，bug库有哪些应用？

         1.对内

         2.对外

4.      如何提高bug敏感度？（照bug思维的培养）

5.      如何确定两个bug还相同的bug？

 

常见缺陷单：

项目信息、版本信息、发现时间  ======   系统自动填上

【概述】  =====  字数不超太多

【详述】

         【环境信息】

         【操作步骤】

         【预期结果】

         【实际结果】

         【备注】

【附件】：截图、录屏

【缺陷严重程度】 ==========   缺陷对用户的影响程度

         【致命、严重、一般、提示】

【优先级】 =======    开发针对某一个缺陷，先修改，还是后修改的，修改优先级

         【备注】严重度与优先级没有必然联系，企业常见参考：根据严重度的级别不同，进行先后修改

【下一步处理人】   =====   缺陷单交给谁来处理，可根据 不同的处理流程（简单 和标准），分别交给不同的人

【实际工作会遇到的问题】：测试与开发人员的沟通交流：

                            1：开发重现缺陷单的时候，需要：按操作步骤去重现；

                            2：开发团队不认可测试提交的缺陷严重度；

                            3：测试提交的缺陷，开发不认可，不修改；

                            4：常见的下一步处理人：由系统管理员或CMO（配置管理员）根据不同的管理系统或工具配置，你们中需要选择相对应人员的账号即可

缺陷单格式：

缺陷管理流程：

缺陷管理工具：bugfree、jira

项目管理工具：禅道（cd的前生是bf）

测试轮数：

测试3轮（一般），敏捷（4轮，还有验收）

可以有4轮，给自己一个预防有问题的、缓冲的时间

St-》3轮（1：全面。2：回归。3：全面）-》验收测试3轮（有用户）

 

Story（2轮）—》迭代测试（2轮）--》sit（3轮）

 

 

 

1000行代码---20-15条用例

一般一天一个模块-----执行50—100个用例

 

python
xmind思维导图
IE lester 可以模拟ie6-10，测兼容