1.软件测试基础

• 软件测试工程师：查找错误和缺陷，然后要求开发人员进行修改，保证软件质量。
• 漏洞（360安全漏洞）：硬件，软件，协议的具体实现或系统安全策略存在缺陷，从而可以使攻击者在未授权的情况下破坏系统。
• 千年虫问题：年份存2年，超过百年会出现bug。1900→2000
• 开发和测试的比例：4:1→10:1
• 手工测试、功能自动化测试、性能自动化测试、白盒测试
• 1-3-5年规划：手工测试工程师，功能自动化测试工程师，性能测试工程师
• 需要的技术：计算机操作系统，软件开发技术、软件测试技术、自动化工具

1.1 Windows操作系统及网络基础

　　熟悉windows操作系统和计算机基础知识，能够搭建软件测试环境，熟悉网络协议。

• 什么是软件：软件=程序+文档
• 什么是软件缺陷：
  • 软件未出现说明书要求的功能
  • 软件出现了说明书指明不应该出现的错误　
  • 软件出现了说明书未提到的功能
  • 软件未实现说明书虽未明确提及但应该实现的功能
  • 软件难以理解，不易使用，运行缓慢或者从测试员角度看，最终用户会认为不好。　
• 什么是软件测试：在现有软件中寻找缺陷的过程
• 软件测试的历史：defect（缺陷），bug(臭虫)，debug（调试）
• 计算机层次：计算机硬件，操作系统，应用软件　
• 裸机包含软件：BIOS(Basic input/output system 基本输入输出系统)
• 常见操作系统：Windows ,linux , unix , IOS
• 软件分类：系统软件，应用软件
• 硬件测试软件：3DMark　　
• 常见数据库管理软件：SQLserver,Oracle,Mysql
• 软件结构分类：单机软件，分布式软件（BS,CS）
• 进制转换：十进制，八进制，二进制，十六进制
• 逻辑代数：与，或，非

1.2 软件测试基础理论（重点）

　　掌握软件测试的核心技术，熟悉整个测试流程，相关文档的编写，测试管理工具QC的使用。

• 软件缺陷和缺陷报告
  • 测试人员的职责
  • 编写缺陷报告
  • 缺陷报告的处理流程　　
• 测试人员的职责
  • 编写测试计划
  • 编写测试用例（重点）-1000条用例
  • 执行测试，发现缺陷提交缺陷报告--50条
  • 验证所发现的缺陷是否得到修改
  • 编写测试总结报告--测试客观事实说话--3篇
• 编写缺陷报告
  • 用缺陷报告告诉开发人员所发生的问题（记录，跟踪）
  • 1.缺陷编号（defect ID）：　
  • 2.缺陷标题（summary）:描述缺陷
  • 3.缺陷发现者（Detected By):发现者
  • 4.发现缺陷的日期（Detected on date）
  • 5.缺陷所属的模块（subject）:在测试哪个模块的时候发现bug
  • 6.发现缺陷的版本（Detected in release）:在测试哪个版本的时候发现bug
  • 7.指派给谁处理（Assigned to）:给开发经理
  • 8.缺陷的状态（status）:
    • new:新提交或新发现的bug
    • open:确实存在该缺陷，开发组承认的bug
    • rejected:不认识是缺陷，开发组不承认bug
    • fixed:已经修复的bug
    • close:返测成功的bug,归档的bug
    • reopen:返测不成功的bug，重新open该bug
    • 缺陷报告处理流程
    • 
    • 一个缺陷的生命周期：New-open-fixed-closed
  • 9.缺陷的严重程度（severity）:对软件的影响
    • Urgent:造成系统死机，重启，崩溃的缺陷
    • Veryhigh:非常严重的缺陷
    • High:大的缺陷
    • Medium:中等程度
    • Low:小的缺陷
    • Bug level definition(bug 等级定义)
  • 10.缺陷的优先级（priority）:希望修复bug的优先度
  • 11.缺陷描述（description）:把发现缺陷的步骤，使用的数据记录下来，使程序猿根据描述清楚所发生的事情
    • 1.在“第一个数”文本框中输入：10
    • 2.在“第二个数”文本框中输入：0
    • 3.点击“/”按钮
    • 4.在“错误提示对话框”中点击“确定”按钮
    • 预期结果：“错误提示框”关闭，程序继续运行
    • 实际结果：程序关闭　　
  • 缺陷报告的用途
    • 1.记录bug
    • 2.对bug进行分类
    • 3.跟踪bug
    • 4.对bug进行分析统计
  • 如何识别缺陷
    • 1.通过测试用例中的预期结果进行判断
    • 2.看需求，通过缺陷的5点定义识别
    • 3.沟通（开发，需求，用户）
  • 一个缺陷报告只提交一个缺陷
  • 缺陷描述清晰，准确，易读，使用最少的步骤，保证能重现
  • 对缺陷的严重性，优先级划分准确，客观
  • 认真审核，避免出错，不要夸大缺陷，
  • 小的缺陷也要报告，及时报告缺陷
  • 对于不可重现的缺陷也要报告
  • 不做任何评价
  • 截图技巧：
• 测试用例
  • 测试用例：主要记录测试的过程、步骤、输入的数据，预期结果等内容。是执行测试之前由测试人员编写的指导测试的重要文档。
  • 解决的问题：测什么，怎么测和如何测试的问题
  • 写测试用例需要的东西：需求文档，开发文档，用户手册，与相关人员讨论，结合开发出的软件写
  • 测试用例应该包含的：用例编号，测试目的，用例描述，预期结果
  • 编写用例的方法
    • 1.等价类划分
      • 根据程序对数据的要求划分若干个区域，从少数代表性数据作为测试用例。每一类代表数据在测试中的作用等价于这类中的其他值
      • 应用场合：只要有数据输入的地方
      • 思想：利用具有代表性的数据代表一类用于测试
      • 概念：
        • 有效等价类：对程序有意义，合理的输入数据集合。得到正确的计算结果
        • 无效等价类：对程序无意义，不合理的输入数据集合。错误提示或不让输入
      • 如何使用等价类划分编写测试用例
        • 1.明确测试对象：一个控件一个控件去测，保证其他控件正确
        • 2.根据需求划分等价类
          • 有效等价类：-99----99之间的整数
          • 无效等价类：非整数，不在区间内，
        • 3.细化等价类
          • 把第二步中不是特别细致的进行详细划分
          • 有些情况不是根据显式需求，而是根据数据存储方式理解
          • 有效等价类：正负数分开（正负数存储补码区别）
          • 无效等价类：非整数（小数，字母，符号，汉字，空）
        • 4.建立等价类表（熟练之后只需要这步）
          • • 编号                   数据要求
            • 　　1                       <99
            • 2                       小数
            • 3                       字母
            • 。。。                  。。。
        • 5.编写测试用例
        • 编写等价类表→编写测试用例　　
        • 正数的补码是其本身，负数的补码是其正数按位取反加1.　　　　　　　　　　　　　　　　　　
    • 2.边界值
      • 应用场合：只要有数据输入的地方，有效和无效数据的分界点，需要单独拿出来测试。
        • 有数据范围的：-99----99
        • 有字符个数要求：要求1-20个字符
        • 边界值一般和等价类一起应用
      • 测试用例写法：用例编号，用例数值，预期结果，实际结果，被测边界
      • 如何使用：把边界值（3个点）单独写用例
      • 具体表
        • 控件名称，数据要求，有效等价类，无效等价类，边界值，所属用例　　
      • 用例的优化：对于不同控件的有效等价类及有效边界值可以尽可能在一条用例中测试。不同控件的有效等价类（边界）可以组合。　　
        • 用例编号，测试目的，用例描述，预期结果，实际结果　　
        • 等级类划分经验
          • 1.有效等价类可以在需求中找到
          • 2.无效等价类
            • 为空
            • 重复
            • 超出范围　　
            • 填写项允许格式（整数，小数，字符）
            • 小数点位数要求　　　　
    • 3.因果图
      • 应用场合：在一个界面中，有多个控件，需要考虑控件的组合关系，组合会产生输出结果。
      • 因果图核心
        • 1.因---原因，input
        • 2.果---结果，output
        • 使用图形的方式，分析软件输入和输出的对应关系。
      • 图形符号
        • 1.基本图形：输入和输出的对应关系
          • a-b 恒等
          • a~b 非
          • a,b v d 或
          • a,b ^ d 与
        • 2.约束（限制条件）图形：单独限制输入或输出
          • E a,b,c 互斥，至多只有1个1（无默认值）
          • I  a,b,c 包含，至少存在一个1
          • O a,b,c 唯一，有且仅有1个1（有默认值）
          • R a,b 要求  ， a,b必须同时为1或为0（自动登录--记住密码自动勾选）
          • M a,b 屏蔽，a,b必须相反
      • 使用因果图分析程序　　
        • 1.找出所有输入条件（编号）
        • 2.明确所有输出结果（编号）

        3.明确所有输入的制约关系及组合关系--简单的排列组合

        • 哪些能组合---决定测试用例的数量
        • 哪些不能组合
        • 4.明确所有输出之间的制约关系及组合关系--简单的排列组合
          • 哪些能组合
          • 哪些不能组合　　
        • 5.找出什么样的输入会产生哪种输出，组合的对应关系
        • 6.根据因果图，写出判定表，按照输入输出确定相应的情况
        • 7.根据判断表设计测试用例
        • 　
        • 　　　　　　　　　　　　　　　　　　　　　　
      • 局限性：每个控件的条件（或取值）最好为2-3个
        • 复选框
        • 单选框
        • 按没按下
        • 有3个选项的下拉列表　　　　
    • 4.判定表
      • 适合判定表发的条件
        • 以判定表的形式给出或很容易转换成判定表
        • 条件排列顺序不影响结果
        • 规则排列顺序不影响结果
        • 当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。（列之间没有关系）
        • 如果规则要执行多个操作，这些操作的执行顺序无关紧要。（转账，先转账后提醒或先提醒后转账无所谓）
      • 判定表的组成
        • 条件桩（输入）
        • 动作桩（输出）
        • 条件项（什么输入--组合）
        • 动作项（条件项输入对应的输出）　　　
          　　　　
    • 5.正交排列法
      • 由来：拉丁方→数独
      • 正交拉丁方：2个不同的拉丁方叠合在一起，形成n^2个有序数对
      • 应用场合：在一个界面中有多个控件，每个控件有多个取值，不可能也没有必要进行穷举，如何使用最少最优的组合进行测试
      • 正交表：L_n(m^k)　-----n代表行数，k代表列数（控件的个数），m代表每个控件包含的取值个数
      • 正交排列法分析
        • 1.分析需求：列出控件及其取值
        • 2.根据控件和控件的取值个数，选择一个合适的正交表，通过m和k确定
          • 通过k控件的个数确定正交表的次幂
          • 通过m控件的取值确定正交表的底
        • 3.把控件及其取值映射到正交表中
        • 4.根据正交表，编写用例
          • 正交表的一行转化成一条用例
        • 常用正交表----去查　
      • 局限性
        • 正交表个数有限，并且一般要求每个控件取值相等，在实践中很难
      • 正交表选择数据的思想
        • 公平
        • 均匀　　　　　　
    • 6.场景法
      • 模拟用户操作软件时的场景，用于测试系统的业务流程
      • 应用场合
        • 1.界面特点：没有太多填写项，主要通过鼠标的点击，双击，拖拽等完成操作
        • 2.把自己当做用户使用该软件可能会遇到的情景
      • 主要目的：测试软件的主要业务流程，主要功能的正确性和主要错误处理能力
      • 核心概念
        • 1.基本流（正确流）：模拟正确操作流程
        • 2.备选流（错误流）：模拟错误操作流程
      • 场景法是基于等价类划分的一种操作方法（技术层面）
      • 场景法的应用是基于软件业务（需求）的深入理解（业务层面)
      • 场景法分析程序
        • 1.根据需求找到基本流和备选流：找到所有正确操作流程和错误操作流程
        • 2.列出场景：把每个基本流和备选流当做一个场景
        • 3.根据场景编写测试用例
        • 可以根据流程图进行分析　　　　　　　　　　　　　　
    • 7.测试大纲方法
      • 多个窗口，每个窗口有多个操作，
      • 步骤
        • 1.列出每个窗口的输入动作
        • 2.找到各个窗口之间的联系，并据此编写测试用例
      • 大纲是一种着眼于需求的办法，为了列出各种测试条件，就需要转为大纲的形式
      • 在根和每个叶节点之间存在唯一路径，每条路径定义一个特定输入条件集合，用于定义测试用例。
        • 　　　
        • 　　　　　
    • 8.状态转换图（工作中几乎没用）
  • 测试用例的用途：
    • 防止遗漏
    • 版本重复测试
    • 监督过程
    • 评估结果　
    • 提高效率
    • 缩短周期　
  • 测试用例方法选择的综合策略
    • 最重要
      • 1.场景法：测试主要业务流程，主要功能和错误处理
      • 2.等价类划分：少数代表某一类　
    • 重要
      • 1.边界值：对分界点及两边的点进行测试
      • 2.判定表（因果图）：考虑多个控件的组合会产生不同的输出组合
    • 次重要
      • 1.正交排列法：判定表的简化，数量大无法全部测试的情况
      • 2.测试大纲法：类树形的方法　
  • 软件测试的基本理论
    • 软件开发阶段划分
      • 需求分析（要求了解）
        • 根据客户的要求，产生需求规格说明书　
          • 引言
            • 编写目的
            • 项目背景　
              • 用户组织结构　
              • 用户相关业务　　
          • 任务概述
            • 目标
            • 运行环境
            • 条件和限制
          • 功能需求
            • 功能描述
            • 数据流图级数据元素描述（数据字典）
              • 职工基本信息　　
          • 性能需求
            • 数据精确度
            • 时间特性
            • 适应性
          • 运行需求
            • 安全性
            • 用户界面
            • 接口要求
            • 故障处理及恢复要求
            • 其他要求
          • 参考资料　　　　　　　　　　　　　　　　　　　
      • 概要设计（初步设计图）
        • 系统分析员审查软件计划，软件需求分析文档，提供最佳推荐方案
        • 概要设计说明书　
          • 引言
            • 编写目的
            • 项目背景
            • 定义（标准）
            • 参考资料
          • 任务概述
            • 目标
            • 运行环境
            • 需求概述
            • 条件与限制　　
          • 现状
            • 组织机构
            • 参与角色
            • 现有系统概述
          • 总体设计
            • 系统平台
            • 协同办公自动化系统
            • 。。。（各种系统展开）
          • 接口设计
            • 外部接口
          • 数据结构设计
            • 逻辑结构设计
          • 系统架构设计
          • 发布打包设计
          • 报表设计
          • 出错设计
          • 数据安全性设计
          • 操作安全性设计　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
      • 详细设计（详细设计图）
        • 为每个模块确定使用的算法，并用适当的工具（流程图）表达算法实现的过程，写出模块详细过程性描述
        • 详细设计说明书
          • 引言
            • 编写目的
            • 项目背景
            • 定义
            • 参考资料
          • 总体设计
            • 需求概述
            • 软件结构
          • 程序描述
            • 系统平台
            • 。。。　　　　　　　　　　　　
      • 编码（完成设计图）　　
        • 程序猿跟你详细设计，利用编程语言编写程序
      • 四个阶段引入的缺陷比例
        • 需求说明书：56%
        • 程序设计：24%
        • 编码阶段：14%
        • 其他：6%　　　　　　
    • 软件测试阶段划分
      • 单元测试
        • 单独功能进行测试　　
        • 依据：详细设计文档
        • 以黑盒测试（功能测试）为主，重点核心模块可以进行白盒测试（检查代码）
        • 可能需要编写驱动模块或桩模块
          • 驱动模块：模拟被测模块的上一级模块　
          • 桩模块：模拟被测模块的下一级模块
        • 在实际工程中，为了节约项目成本，单元测试经常只由开发人员完成　　
      • 集成测试
        • 也叫组装测试，在单元测试的基础上，将所有的程序模块进行有序的，递增的测试
        • 主要验证程序单元或部件的接口关系（调用关系），逐步集成为符合要求的系统
        • 集成测试有很多版本，拿到一个新版本，必须先做一个冒烟测试
        • 冒烟测试：利用较少的时间（0.5-2天），较少的人（1-3人，经验更丰富）对软件的主要功能进行测试，主要判断该软件是否值得一测
        • 一个新版本的测试思路
          • 1.冒烟测试：判断是否值得测试
          • 2.返测：对发现的缺陷是否修复进行测试
          • 3.回归测试：对上一个版本的用例，在重新执行一遍，保证软件旧功能正确
          • 4.对新添加的功能进行测试　　　
      • 系统测试
        • 在真实或模拟系统运行的环境下，检查完整程序系统能否和系统（硬件，外设，网络，系统软件，支持平台）正确配置，连接，并满足用户需求。
        • 目的：验证和确认是否达到原始目标，对集成的硬件和软件系统进行测试
        • 对整个系统进行全面完整的过程
        • 在系统测试之前一般有“确认测试”
        • 确认测试：大型的冒烟测试+确认相关文档是否齐全（尤其是交给用户的文档）　
      • 验收测试
        • 用户接受度测试，用户体验测试，UAT（user acceptance test）
        • α测试:由最终的用户在开发的环境中，对软件进行测试（可以由开发方自主完成）
        • β测试：由最终的用户在实际的环境中，对软件进行测试使用
        • 对于没有固定用户群体的公共类软件（办公软件，游戏，输入法）一般存在公共测试，公测版本，让用户免费体验，发现bug，由用户反馈。
        • 　　
      • 　　
    • 软件测试模型
      • 概念：测试模型体现的是开发和测试的对应关系　　
      • 常见模型
        • V模型（最重要的）
          • 　　
          • 优缺点
            • 优点：测试阶段明确，包括单元级和用户级，与开发关系明确
            • 缺点：容易理解成，测试只是开发后的一个工作，不符合越早测试和不断测试原则
          • 深入理解：
            • 越早测试：在编码前，需要对相关需求文档，开发文档进行测试，越早测试
            • 计划性：根据相关文档，在测试执行前编写各个阶段的测试计划，测试用例等　　　　
        • W模型　　
          • 　　
          • 双V，同样体现了开发和测试的对应关系
    • 软件测试的分类　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

1.3 功能测试项目实训

2.1 JAVA程序设计

2.2 数据库技术

2.3 软件开发项目实训

3.1 功能测试工具QuickTest Professional

　　熟练掌握功能测试自动化工具QTP ，学会使用VBScript编写测试脚本，提高测试效率

3.2 功能测试工具Qtp项目实训

3.3 白盒测试技术与白盒测试工具

4.1 性能测试工具LoadRunner

4.2Linux操作系统及网络环境

4.3 性能测试工具LR项目实训

4.4综合项目测试

原文地址：https://www.cnblogs.com/shuimohei/p/11949465.html