软件测试 入门理论丶

 

 

一：软件测试的定义：根据用户需求行业规范，采用一些测试方法或一些工具对被测系统（程序数据文档）进行相应的测试（审核，运行，评估），尽早尽快的发现软件问题，提高软件的质量。

 

二：软件测试的生命周期：

第一阶段：问题的定位与规划阶段    

第二阶段：需求分析阶段   

第三阶段：软件的设计阶段（概要设计，详细设计）

第四阶段：软件编码阶段   

第五极端：软件测试阶段   

第六阶段：运行与维护阶段 

 

三：软件测试的需求   需求规格说明书（产平经理编辑）：收集客户的反馈，市场人员的调研，收集市场需求，和市场人员沟通，业内需求（行业规范，功能需求）

      为何都要造成文档：项目管理的须要

      做用：描述客户对于软件的指望和要求

      供你们评审：需求有没有错误或不一致，需求是否能够测试，进一步理解用户的需求，为后续的测试做准备第一阶段：需求分析

      需求分析：

1：学习需求，充分理解需求   

2：找出需求中的问题（模糊不清，有歧义），如需求文档已经发布或测试已经开始执行提交文档bug单的状况 （二者瞒住一个就须要提文档bug单）

3：准确评估测试点和工做量（为写用例奠基基础）   

 

四：软件测试的分类：

技术划分   

-白盒测试；（针对单元测试）对内部代码逻辑进行测试，关注输出对于输入的正确性   

-灰盒测试：（针对集成测试）基于白盒与黑盒之间   

-黑盒测试：（针对系统测试）依据需对求程序的多面处进行测试经过软件的外部表现来发现其缺陷。

                   

状态划分   

1：动态 - 手工，自动化，半自动化

2：静态 -文档评审（雪球评审，设计评审，测试文档（猜想是计划，用例，报告），用户手册）

             -代码走查：开发人员之间相互阅读代码检查代码是否符合编程规范   注：代码走查发现的问题比单元测试的多

                      

阶段划分   

1：单元测试：根据系统设计文档，主要测试程序的源代码和内部逻辑，力度最小，通常是开发小组采用百合测试 

                    注：不关注代码是否符合编程规范

                                     

 2：集成测试：依据系统设计文档和需求文档，属于单元测试和（确认测试）系统测试之间起到桥接的做用  

                    单元测试以后进行，由开发小组运用灰盒测试技术进行测试 

                    即验证内部代码逻辑又关注需求实现（跑通基本功能不会像系统测试那样验证多种异常场景）

                                     

3：确认测试：依据需求文档，在集成测试后，经过集成测试以后，软件已彻底组装起来，接口方面的错误也已排除，

                    确认测试便可开始。   

                    确认测试应检查软件可否按合同要求进行工做，便是否知足软件需求说明书中的确认标准。

 

4：冒烟测试：进行时间：新版本发布后   测试内容：对软件的基本功能点的流程测试确保经过冒烟（软件可否跑起来）   

                                     

5：系统测试：依据需求文档，粒度最大，通常由独立测试小组采用黑河测试验证多种场景下功能是否符合课采用手工或自动化

         -包括：

                 功能测试-对产品的功能进行验证，根据测试用例逐项进行验证                                               

                 性能测试- 测试软件处理业务的速度（同时并发，同时在线）

                 压力测试-系统正常运行的极限状态

                 健壮性测试-异常状况下软件正常运行的能力（包括容错力和恢复力）

                 可靠性测试-长时间的运行看软件有没有问题（如手机用长了会卡顿）   

                 安全性测试-指软件防止非法入侵的能力（属于技术问题也属于管理问题）

 

6：探索性测试：天马行空的的设计和执行测试用例，利用软件程序所提供的信息只有发挥，没有限制不受任何条件的约束的探索程序的各类功能      

                                     

7：alpha和beta测试：

                   alpha：（内测）在受控制环境下进行的测试，技术人员会在现场

                    beta：（公测）开发者一般不在测试现场,于是开发者没法 控制测试现场

                       注：通常应用于大型公用软件，没有具体用例，这两种测试都是从实际终端用户角度出发对软件功能和性能进行测试

 

8：回归测试：1：bug修复后且在新的测试版本发布后须要进行回归测试

                    2：bug修复后的回归测试在交付前须要进行全量用例回归的测试也叫（顶版测试）

                        确保BUG修改后有没有引入新的bug致使其余部分有没有产生错误

 

9：验收测试：验收测试与系统测试很是类似主要区别是验收测试是由客户或用户执行

 

五：测试工做的开展

测试启动准则：

1：需求已经就绪，测试计划制定并经过审核   

2：用例已经设计完并经过审核 

3：测试的对象已经开发完等待测试

4：测试环境已经搭建，测试数据准备好了

测试结束准则:

1：产品经过验收测试且用例覆盖率，用例执行率，用例经过率都达到相应的指标 

2；出现的问题得以修复且再次执行用例没有新的问题出现   

3：项目规划时间到期，测试用例执行完成（覆盖率达到多少），bug出现收敛

 

基于测试用例的准则

基于缺陷密度的准则则

基于试运行期间缺陷密度

 

六：传统测试流程

第一阶段：需求分析

• 1：学习需求，充分理解需求（了解项目的整个实现背景，挖掘隐藏需求）
• 2：分析需求的合理性，找出需求中的问题（模糊不清，有歧义）
• • 1：功能描述不清晰的
  • 2：有歧义的
  • 3：文字表述错误的
  • 4：‘多’‘等’‘长时间’等模糊字眼
  • 5：需求重复的
  • 6：一些模棱两可的描述
  • 7：先后功能冲图
  • 8：潜在性需求可提出（为了产品质量更好，若是是客户定制的那么客户更加满意）
  • 9：异常操做需求可提出（是做为软件系统基本的逻辑异常问题处理机智）
• 3：准确评估测试点和工做量（为写用例奠基基础）
• 4：熟悉业务
• 5：罗列出个功能点
• 6：记录评审的问题，便于跟踪问题
• 7：对设计方案看能不给出比较好的建议

第二阶段：制定测试计划：

• why（什么）---什么项目   为什们进行测试
• what（在那一反面）---测试那些方面（不一样阶段的测试内容）
• when（什么时间）---测试不一样阶段的起止时间（开始和结束，里程碑）
• where（在什么地方）---相应文档，缺陷存放在什么位置，测试环境等
• who（谁；什么人）---项目相关人员，安排那些人员进行测试
• how（如何作）---（测试方案技术层面）如何去作，使用那些工具以及那些方法进行测试
• 计划做用：在测试以前编写的，是用来指导测试行为的（管理层面的）

第三阶段：测试设计阶段（写用列）

• + - 黑盒测试的特色：
  • 黑盒测试只有采用穷举时输入测试，把全部可能考虑到，实际上测试有无穷多个，彻底测试是不可能的
• + - 测试用例概述：
  • 测试用例的定义：设计一种状况（输入数据）软件在种场景下可以正常运行而且达到指望执行结果则经过如不能正常运行并且重复发生，那多是一个软件缺陷
  • 软件测试过程管理：软件测试是软件质量管理中最实际的行动，同时也是耗时最大的一项工做（组织，步骤，计划的开展）（量化，测试用例是具体的量化行为之一）
• 测试用例设计方法：
  • 等价类
    • 有效等价类：规范有意义，合理的输入
    • 无效等价类:不合理或无心义的输入
  • 边界值
    • 边界值法：以边界状况的处理做为主要目标专门设计测试用例额的方法
    • 边界点
      • 上点：边界上的点
      • 内点：区间内的点
      • 离点：离上点最近且不与上点为同一等价类的点
  • 错误推敲法
    • 单元测试时列出在模块中常见的错误在模块
    • 之前产品中曾经发现的错误
    • 产品在客户实用过程当中发现的错误
    • 整体体发生错误的状况
    • 一些公共的模块
    • 修复了bug功能和模块
  • 因果突图法
    • 概述：
      • 分析需求规格说明书哪些是缘由哪些是结果
      • 选择条件以及对应的结果
    • 使用范围：1：多输入的状况下条件没有顺序性
    • + - 基本步骤
      • 1：分析哪些是缘由哪些是结果
      • 2：分析描述语义的内容，并将其表示成链接各个缘由与各个结果的因果图
      • 3：把因果图图写成断定表
    • 断定表(合并类似的内容
      • 条件桩；列出了问题的全部条件
      • 条件項；列出特定条件的的取值
      • 动做桩；列出问题规定可能采起的全部操做
      • 动做項：各类取值条件下应该才去的的动做
  • 正交法（PICT工具）
    • + - 1：在安装PICT的目录中新建一个txt文件并把须要组合的参数输入进去
      • 账户名: 空,不存在,超长,超短,正常
      • 密码: 空,超长,超短,不匹配,正常
      • 验证码: 空,超长,超短,不匹配,正常
    • 2：打开开cmd进入pict的目录内  执行命令：pict  参数文件  (可在命令增长文件保存的路径)
  • 场景法
    • 概述;：运用场景对系统发生的功能或业务流程进行描述，从而列出出问题的一种方法  /   模拟特色场景发生的事情事件来触发某个动做的发生，观察最终结果，从而来发现软件的存在问题
    • 场景法的路径：基本流（用户的正常操做）和备选流（基本流之外一系列的异常操做）在基本流和备选流的 过程当中能够采用前面的等价值和边界值，因果图法等从而达到各类测试方法的融合。
    • + - 设计方法
      • 1描述基本流和各项备选流
      • 2根据基本流备选流生成测试场景
      • 3对每个场景生成测试用例
        • 1：首先进行等价类划分
        • 2：再进行边界值的划分
      • 4复审用例，去掉多余的用例，对每个测试用例肯定测试数据值（注：简单的用列能合并就合并）
    • 是测试使用最多的方法，策略：先对于项目测试先使用用场景法进行测试并进行场景法编写用例，尽量在场景法里面融合其余方法，对于输入框，能够编写单独的用例进行进一步策测试
• 用例例格式基本要素：
  • 1用例编号
  • 2测试项目
  • 3测试标题
  • 4级别（优先级）
    • 越基础的功能和用户经常使用的优先级越高，复杂异常的低
  • 5预置条件
  • 6操做步骤
  • 7预期输出
  • + - 8测试结果
    • pass：表现与预期一致
    • falt：与预期不同
    • NA：功能未完成/环境不支持/没有工具
    • block：有bug阻塞（备注阻塞bug的ID）
  • 9测试者
  • 10测试时间
  • 11：备注
• 需求不明确如何写用例：
  • 1：能够去问下开发看看开发如何去描述的
  • 2：能够参考一下同类竞品
  • 3：有经验的话根据我的经验
  • 4：还能够请教领导
• 测试用例的做用：
  • 1避免盲目测试使测试重点突出目的明确，软件更新后只须要修改少部分测试用例
  • 2:通用化和复用化使软件测试易于开展，有助于不断改进工做。
  • 3时间紧迫的话能够分清重点。 是测试工做的见证
• 测试用例的维护：
  • 及时更新，及时补充，及时修改，删除冗余的用例
• + - 如何保证测试用例对需求的覆盖：
  • 1：测试需求的获取分为两步
    • 显式需求
      • 原始需求说明书
      • 产品规格说明书
      • 软件需求文档
      • 通用的协议规范
      • 有无继承性文档
      • 经验库有无课借鉴的
    • 隐性需求
      • 用户的主观感觉
      • 市场的主流观点
      • 专业人士的评价
  • 2：将不一样的需求产生一个个需求点
    • 界定需求点的范围
    • 利用各类测试设计方法产生不一样的测试点
  • 3：需求有变更及时更新用例
  • 4：经过用例评审，团队人员一块儿讨论补充和完善
  • 5：用例执行阶段保证100%执行率，对新增的需求及时补充用例
  • 6：将测试的需求，测试的用例，发现的bug关联起来，便于管理和跟踪，同时也便于查看需求覆盖率

第四阶段：测试（系统测试）执行阶段——提bug

• 执行前（冒烟测试/确认测试）
• + - 执行中（提交缺陷）
  • + - 1软件缺陷的定义
    • 软件未实现产平说书要求的功能明
    • 软件出现了产品说明书指明不该该出现的错误
    • 出现了产品说明说未提到的功能
    • 软件没有实现产品说明书虽未明确说起但应该实现的目标功能
    • 软件难以理解，不易使用  运行速度慢，或者软件测试员人为用户会认为很差的地方
  • + - 2软件缺陷报告的原则
    • 尽早报告软件缺陷。有效描述给出说明问题的一系列明确步骤（对事不对人）
    • 对软件缺陷报告跟踪到底（天天到公司先看下bug状态，监视其修复全过程）
    • 每一个报告只针对一个缺陷
  • + - 3软件缺陷报告描述
    • 缺陷ID
    • 缺陷状态
    • 缺陷标题
    • 缺陷的详细描述
    • 缺陷的严重程度
    • 缺陷的紧急程度
    • 缺陷提交人
    • 缺陷提交时间
    • 缺陷所属项目/模块
    • 缺陷指定解决人 解决时间     最终解决人
    • ·缺陷处理结果描述
    • 缺陷结果复核人
    • 缺陷复合结果描述
    • 测试环境说明
    • 必要的附件（对于某些文职难以描述的结果使用图片等附件）
  • + - 4软件缺陷严重程度：
    • + - A类-（致命）错误致命：系统崩溃，数据丢失，死机，拥塞等
      • 不能执行重要功能
      • 程序硬气的死机
      • 死循环  数据库发生死锁
      • 应错误致使的程序中段
      • 与数据库连接错误
    • + - B-较（严重）的错误（严重的影响系统或基本功能的实现且没有办法更正
      • 程序错误
      • 程序接口错误
      • 数据库的表。业务规则。缺陷值未加完整性等约束条件
    • + - C- 类（通常）描述不清，内容错别字，易用性差
      • 界面不规范
      • 辅助说明描述不清楚或不描述
      • 输入输出不规范
      • 长操做做未给用户提示
      • 未采用行业术语
      • 可输入区域和只读区域没有明显区分标志
    • D-类（轻微）建议优化：建议软件优化的方面
  • + - 6软件缺陷的管理
    • 缺陷管理概述：
      • 在软件的生命周期中识别，管理，沟通任何缺陷的过程，确保软件跟踪管理而不丢失
      • 通常须要跟踪管理工具帮助进行管理（禅道 ，bugzila）
    • 缺陷管理做用：
      • 对bug进行管理，使得相关测试人员能够经过该系统进行无缝对接，及时交流和沟通而且记录bug的整个生命周期
  • + - 7软件缺陷生命周期
    • 发现识别bug——提交bug——分析和定位bug——修改相应的程序处理bug——验证修改——关闭缺陷——经过分析bug的共性，防止再次发生
  • + - 8软件缺陷处理流程

    • 流程：识别---新建--编辑----提交---分配（从新分配）---修复---                                                                                   验证(验证不经过)---关闭（从新打开）---总结防止bug再次产生      最后进行回归测试

• 如何定位BUG？

  • WEB：打开f12，进入开发者模式，再去点击列表，f12里面去看 查询出来的页面内容，你点击这个按钮的时候，他会向后 台发送请求，类表查询，能够从开发者模式页面查看具体 请求信息和返回的请求报文信息，看Reponse（响应）里 面，若是返回有数据，数据对的，就是前端的问题，是前端本身没有获取到，可是后端是给了你的。

    APP：经过抓包来查看请求或响应数据

• + - 如何找到高质量的bug：
  • 1：充分学习产品的需求，知识和流程
  • 2：充分考虑异常包含逻辑异常，甚至开发设计中的异常
  • 3：充分了解客户需求，客户使用场景，客户使用流程，多从客户角度出发
• + - 如何提交高质量的bug：
  • 1：发现bug先确认不是本身的误操做
  • 2:：记录bug出现的步骤和保留现场（必要时提供日志和现象截图）
  • 3：最后提交bug（达到下面要求）
  • a：准确——每一个组成部分描述准确
  • b：清晰——描述清晰，易于理解
  • c：简洁——只包含必要的信息
  • d：完整——复现bug的完整步骤和其余本质信息
  • e：一致——按照一致的格式书写缺陷报告
• + - 什么是高质量的bug：
  • a：影响功能的
  • b：迄今为止都未被发现的
  • c：形成影响比较大的bug
• + - bug漏测如何处理？
  • 1：对漏测的缘由进行分析，和自我反省
  • 2：对漏测的bug进行归类，寻找弥补的方法
  • 3：对这次行为进行总结检讨
• + - 提交的bug开发拒绝了怎么办：
  • 第一步：首先在bug系统备注沟通（如承认开发的观点则关闭）——来回沟通屡次
  • 第二步：直接找开当面沟通（把我认为是bug的理由和须要的证据给他看）——还不认可是bug
    • 告诉开发这个问题被客户发现后产生的影响和后果
  • 第三步：找本身的领导和产品经理说明状况（对事不对人）——若是还未解决
  • 第四步：开会讨论（通常找了领导就会出结果）
• + - 对于难以重现的bug该怎么办？：
  • 一、尽力去查找出错缘由，好比有什么特别的操做或特定的环境和数据
  • 二、在测试报告中详细描述测试操做步骤，bug发生的症状，bug发生的具体环境描述，这样对于再次重现有必定的参考做用
  • 三、没法重现的bug尝试屡次，再次出现后能够直接叫程序员过来看
  • 四、没法重现的严重bug，由于概率缘由，重现不了或难以重现的不表明没有发生，能够尝试屡次，写下发生的几率。开发对程序比测试熟悉的多，及时没法重现，程序员也需会了解问题所在
• + - 测试时很难发现bug怎么办？
  • 第一种正常执行用例
    • 1：若是测试的人只有我一个的时候，看测试的版本是开发中的仍是已经上线的，若是是开发中的未上线的版本，未发现bug就要引发注意了，毕竟大部分状况是能发现bug的。
    • 2：若是测试的人不止你一我的的时候，看看其余人是否能发现bug——分组讨论

      • 场景一、若是测试的bug很少，那说明软件质量应该还不错， 测试不出来bug 也不要着急，

        场景二、其余人可以发现bug，可是你发现不了， 这个状况就要去思考，你的测试方法是否是不对， 你对需求是否理解到位，是否还有遗漏， 仔细分析下其余人发现的bug是否在本身负责的模块存在，这时须要：测试人员需突破思惟定势,打破常规须要补充新的测试用例.尤为须要补充一些覆盖无效等价类的测试用例.

  • 第二种状况：
    • 第二种状况：新人到公司， 为了让新人尽快熟悉业务，会让新人跑跑 测试用例， 这个时候测试的模块通常都比较成熟了，或者可能都已经上线了， 发现不了bug很正常

第五阶段：测试评估阶段

• 1：撰写测试报告：
  • 1：测试的模块
    • （模块开始和结束的测试时间）
    • （设计的用例数和执行数）
    • （用例经过多少失败多少）
    • （有多少bug，已解决多少bug）
    • （遗留的问题）
  • 2：汇报一下大体的结果
  • 3：遗留问题和风险说明
  • 4：评估是否符合上线标准
• 经过：上线
• 不经过：打会修改字后重测

   

七：敏捷测试流程

H模型  有什么就测就测什么，体现的软件测试尽早开始   

H模型中：软件测试过程活动彻底独立,贯穿于整个产品的周期,与其余流程并发地进行,某个测试点准备就绪时,就能够从测试准备阶段进行到测试执行阶段。

软件测试能够尽早的进行,而且能够根据被测物的不一样而分层次进行   

 

八：企业测试人员组织

企业测试人员组织

• 条件特别好的  1：1
• 条件比较好的  有独立的测试团队服务于多个开发
• 条件通常的 到达系统测试测试阶段外面调配测试人员加本公司开发一块儿测
• + - 条件差的没有专门的测试人员
  • 需求：业务，学习以前的bug单
  • 搭建测试管理系统（禅道，项目软件搭建运行经过运行软件进一不步了解）
  • 编写用例，执行，文档化
• + - 测试工程师的分类：
  • 系统测试工程师
  • 性能测试工程师
  • 自动化测试工程
  • 测试开发工程师