软件测试入门理论丶

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

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

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

第二阶段：需求分析阶段   

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

第四阶段：软件编码阶段   

第五极端：软件测试阶段   

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

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

      为什么都要形成文档：项目管理的需要

      作用：描述客户对于软件的期望和要求

      供大家评审：需求有没有错误或不一致，需求是否可以测试，进一步理解用户的需求，为后续的测试作准备第一阶段：需求分析

      需求分析：

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该怎么办？：
  • 1、尽力去查找出错原因，比如有什么特别的操作或特定的环境和数据
  • 2、在测试报告中详细描述测试操作步骤，bug发生的症状，bug发生的具体环境描述，这样对于再次重现有一定的参考作用
  • 3、无法重现的bug尝试多次，再次出现后可以直接叫程序员过来看
  • 4、无法重现的严重bug，因为几率原因，重现不了或难以重现的不代表没有发生，可以尝试多次，写下发生的概率。开发对程序比测试熟悉的多，及时无法重现，程序员也需会了解问题所在
• + - 测试时很难发现bug怎么办？
  • 第一种正常执行用例
    • 1：如果测试的人只有我一个的时候，看测试的版本是开发中的还是已经上线的，如果是开发中的未上线的版本，未发现bug就要引起注意了，毕竟大部分情况是能发现bug的。
    • 2：如果测试的人不止你一个人的时候，看看其他人是否能发现bug——分组讨论

      • 场景1、如果测试的bug不多，那说明软件质量应该还不错， 测试不出来bug 也不要着急，

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

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

第五阶段：测试评估阶段

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

七：敏捷测试流程

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

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

软件测试可以尽早的进行,并且可以根据被测物的不同而分层次进行   

八：企业测试人员组织

企业测试人员组织

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