1 软件测试基础软件测试工程师：查找错误和缺陷，然后要求开发人员进行修改，保证软件质量。
漏洞（360安全漏洞）：硬件，软件，协议的具体实现或系统安全策略存在
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.基本图形：输入和输出的对应关系
- 使用因果图分析程序
- 1.找出所有输入条件（编号）
- 2.明确所有输出结果（编号） 3.明确所有输入的制约关系及组合关系--简单的排列组合
- 哪些能组合---决定测试用例的数量
- 哪些不能组合
- 4.明确所有输出之间的制约关系及组合关系--简单的排列组合
- 哪些能组合
- 哪些不能组合
- 5.找出什么样的输入会产生哪种输出，组合的对应关系
- 6.根据因果图，写出判定表，按照输入输出确定相应的情况
- 7.根据判断表设计测试用例
- 局限性：每个控件的条件（或取值）最好为2-3个
- 复选框
- 单选框
- 按没按下
- 有3个选项的下拉列表
- 4.判定表
- 适合判定表发的条件
- 以判定表的形式给出或很容易转换成判定表
- 条件排列顺序不影响结果
- 规则排列顺序不影响结果
- 当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。（列之间没有关系）
- 如果规则要执行多个操作，这些操作的执行顺序无关紧要。（转账，先转账后提醒或先提醒后转账无所谓）
- 判定表的组成
- 条件桩（输入）
- 动作桩（输出）
- 条件项（什么输入--组合）
- 动作项（条件项输入对应的输出）
- 适合判定表发的条件
- 5.正交排列法
- 由来：拉丁方→数独
- 正交拉丁方：2个不同的拉丁方叠合在一起，形成n^2个有序数对
- 应用场合：在一个界面中有多个控件，每个控件有多个取值，不可能也没有必要进行穷举，如何使用最少最优的组合进行测试
- 正交表：Ln(mk) -----n代表行数，k代表列数（控件的个数），m代表每个控件包含的取值个数
- 正交排列法分析
- 1.分析需求：列出控件及其取值
- 2.根据控件和控件的取值个数，选择一个合适的正交表，通过m和k确定
- 通过k控件的个数确定正交表的次幂
- 通过m控件的取值确定正交表的底
- 3.把控件及其取值映射到正交表中
- 4.根据正交表，编写用例
- 正交表的一行转化成一条用例
- 常用正交表----去查
- 局限性
- 正交表个数有限，并且一般要求每个控件取值相等，在实践中很难
- 正交表选择数据的思想
- 公平
- 均匀
- 6.场景法
- 模拟用户操作软件时的场景，用于测试系统的业务流程
- 应用场合
- 1.界面特点：没有太多填写项，主要通过鼠标的点击，双击，拖拽等完成操作
- 2.把自己当做用户使用该软件可能会遇到的情景
- 主要目的：测试软件的主要业务流程，主要功能的正确性和主要错误处理能力
- 核心概念
- 1.基本流（正确流）：模拟正确操作流程
- 2.备选流（错误流）：模拟错误操作流程
- 场景法是基于等价类划分的一种操作方法（技术层面）
- 场景法的应用是基于软件业务（需求）的深入理解（业务层面)
- 场景法分析程序
- 1.根据需求找到基本流和备选流：找到所有正确操作流程和错误操作流程
- 2.列出场景：把每个基本流和备选流当做一个场景
- 3.根据场景编写测试用例
- 可以根据流程图进行分析
- 7.测试大纲方法
- 多个窗口，每个窗口有多个操作，
- 步骤
- 1.列出每个窗口的输入动作
- 2.找到各个窗口之间的联系，并据此编写测试用例
- 大纲是一种着眼于需求的办法，为了列出各种测试条件，就需要转为大纲的形式
- 在根和每个叶节点之间存在唯一路径，每条路径定义一个特定输入条件集合，用于定义测试用例。
- 8.状态转换图（工作中几乎没用）
- 1.等价类划分
- 测试用例的用途：
- 防止遗漏
- 版本重复测试
- 监督过程
- 评估结果
- 提高效率
- 缩短周期
- 测试用例方法选择的综合策略
- 最重要
- 1.场景法：测试主要业务流程，主要功能和错误处理
- 2.等价类划分：少数代表某一类
- 重要
- 1.边界值：对分界点及两边的点进行测试
- 2.判定表（因果图）：考虑多个控件的组合会产生不同的输出组合
- 次重要
- 1.正交排列法：判定表的简化，数量大无法全部测试的情况
- 2.测试大纲法：类树形的方法
- 最重要
- 软件测试的基本理论
- 软件开发阶段划分
- 需求分析（要求了解）
- 根据客户的要求，产生需求规格说明书
- 引言
- 编写目的
- 项目背景
- 用户组织结构
- 用户相关业务
- 任务概述
- 目标
- 运行环境
- 条件和限制
- 功能需求
- 功能描述
- 数据流图级数据元素描述（数据字典）
- 职工基本信息
- 性能需求
- 数据精确度
- 时间特性
- 适应性
- 运行需求
- 安全性
- 用户界面
- 接口要求
- 故障处理及恢复要求
- 其他要求
- 参考资料
- 引言
- 需求测试审查书
- 1.用户覆盖了用户提出的所有需求项？
- 2.用词是否清晰，语义是否存在歧义的地方
- 3.是否清楚描述了软件需要做什么以及不做什么
- 4.是否描述了软件的目标环境，包括硬件环境
- 5.是否对需求项进行了合理的编号
- 6.需求项是否前后一致，彼此不冲突
- 7.是否清楚的说明了系统的每个输入，输出格式，以及输入输出之间的对应关系
- 8.是否清晰描述了软件系统的性能要求
- 9.需求的优先级是否合理分配
- 10.是否描述了各种约束条件
- 根据客户的要求，产生需求规格说明书
- 概要设计（初步设计图）
- 系统分析员审查软件计划，软件需求分析文档，提供最佳推荐方案
- 概要设计说明书
- 引言
- 编写目的
- 项目背景
- 定义（标准）
- 参考资料
- 任务概述
- 目标
- 运行环境
- 需求概述
- 条件与限制
- 现状
- 组织机构
- 参与角色
- 现有系统概述
- 总体设计
- 系统平台
- 协同办公自动化系统
- 。。。（各种系统展开）
- 接口设计
- 外部接口
- 数据结构设计
- 逻辑结构设计
- 系统架构设计
- 发布打包设计
- 报表设计
- 出错设计
- 数据安全性设计
- 操作安全性设计
- 引言
- 详细设计（详细设计图）
- 为每个模块确定使用的算法，并用适当的工具（流程图）表达算法实现的过程，写出模块详细过程性描述
- 详细设计说明书
- 引言
- 编写目的
- 项目背景
- 定义
- 参考资料
- 总体设计
- 需求概述
- 软件结构
- 程序描述
- 系统平台
- 。。。
- 引言
- 编码（完成设计图）
- 程序猿跟你详细设计，利用编程语言编写程序
- 四个阶段引入的缺陷比例
- 需求说明书：56%
- 程序设计：24%
- 编码阶段：14%
- 其他：6%
- 需求分析（要求了解）
- 软件测试阶段划分
- 单元测试
- 单独功能进行测试
- 依据：详细设计文档
- 以黑盒测试（功能测试）为主，重点核心模块可以进行白盒测试（检查代码）
- 可能需要编写驱动模块或桩模块
- 驱动模块：模拟被测模块的上一级模块
- 桩模块：模拟被测模块的下一级模块
- 在实际工程中，为了节约项目成本，单元测试经常只由开发人员完成
- 集成测试
- 也叫组装测试，在单元测试的基础上，将所有的程序模块进行有序的，递增的测试
- 主要验证程序单元或部件的接口关系（调用关系），逐步集成为符合要求的系统
- 集成测试有很多版本，拿到一个新版本，必须先做一个冒烟测试
- 冒烟测试：利用较少的时间（0.5-2天），较少的人（1-3人，经验更丰富）对软件的主要功能进行测试，主要判断该软件是否值得一测
- 一个新版本的测试思路
- 1.冒烟测试：判断是否值得测试
- 2.返测：对发现的缺陷是否修复进行测试
- 3.回归测试：对上一个版本的用例，在重新执行一遍，保证软件旧功能正确
- 4.对新添加的功能进行测试
- 系统测试
- 在真实或模拟系统运行的环境下，检查完整程序系统能否和系统（硬件，外设，网络，系统软件，支持平台）正确配置，连接，并满足用户需求。
- 目的：验证和确认是否达到原始目标，对集成的硬件和软件系统进行测试
- 对整个系统进行全面完整的过程
- 在系统测试之前一般有“确认测试”
- 确认测试：大型的冒烟测试+确认相关文档是否齐全（尤其是交给用户的文档）
- 验收测试
- 用户接受度测试，用户体验测试，UAT（user acceptance test）
- α测试:由最终的用户在开发的环境中，对软件进行测试（可以由开发方自主完成）
- β测试：由最终的用户在实际的环境中，对软件进行测试使用
- 对于没有固定用户群体的公共类软件（办公软件，游戏，输入法）一般存在公共测试，公测版本，让用户免费体验，发现bug，由用户反馈。
- 单元测试
- 软件测试模型
- 概念：测试模型体现的是开发和测试的对应关系
- 常见模型
- V模型（最重要的）
- 优缺点
- 优点：测试阶段明确，包括单元级和用户级，与开发关系明确
- 缺点：容易理解成，测试只是开发后的一个工作，不符合越早测试和不断测试原则
- 深入理解：
- 越早测试：在编码前，需要对相关需求文档，开发文档进行测试，越早测试
- 计划性：根据相关文档，在测试执行前编写各个阶段的测试计划，测试用例等
- W模型
- 双V，同样体现了开发和测试的对应关系
- V模型（最重要的）
- 软件测试的分类
- 按照测试技术划分
- 黑盒测试（功能测试）:必须的，完全不考虑程序内部的结构和处理过程，通过外部表现发现其缺陷和错误
- 功能测试
- 界面测试
- 冒烟测试
- 回归测试
- 业务测试
- 兼容性测试
- 易用性测试
- 自动化测试
- WEB自动化测试
- 接口自动化测试
- 性能测试
- 性能测试
- 负载测试
- 压力测试
- 容量测试
- 并发测试
- 持久性测试
- 安全测试
- 手动操作
- 自动化审计
- 功能测试
- 白盒测试（结构测试）：可选的，对代码进行测试，检测代码的缺陷，清楚的了解程序结构和处理过程，检测所有的程序结果和处理过程，
- 重点看代码的逻辑，算法，结果是否正确
- 静态分析
- 动态分析
- 逻辑覆盖测试
- 语句覆盖
- 判定覆盖
- 条件覆盖
- 路径覆盖
- 插桩测试
- 逻辑覆盖测试
- 重点看代码的逻辑，算法，结果是否正确
- 灰盒测试：介于黑盒和白盒，关注输入和输出的正确性
- 先黑盒测试，发现错误的部分用白盒测试
- 其他测试
- 随机测试
- 探索性测试
- α测试
- β测试
- 总结：
- 单元测试：白盒较多
- 集成测试：灰盒较多
- 系统测试，验收测试：不会又白盒和灰盒
- 黑盒测试（功能测试）:必须的，完全不考虑程序内部的结构和处理过程，通过外部表现发现其缺陷和错误
- 按是否需要运行代码划分
- 静态测试：界面测试，文档测试，代码测试
- 测试重点：代码的规范性，变量的命名，注释频率
- 不用写测试用例，只需要代码审查单
- 动态测试：通过人工或使用工具运行程序进行检查，分析执行状态和外部表现
- 静态测试：界面测试，文档测试，代码测试
- 按照测试技术划分
- 按软件特性分类
- 功能测试
- 性能测试：分布式软件，负载测试，压力测试，容量测试等
- 返测
- 回归测试
- 随机测试：随机输入进行测试
- 测试团队的组织架构
- 金字塔管理模式
- 测试总监
- 产品线测试经理/主管
- 测试组长
- 测试A
- 测试B
- 测试组长
- 产品线测试经理/主管
- 测试组长
- 测试C
- 测试D
- 测试组长
- 产品线测试经理/主管
- 测试总监
- 矩阵化管理模式
- 研发经理
- 项目经理
- 研发人员
- 金字塔管理模式
- 软件开发阶段划分
- 测试人员知识体系
- 软件测试基础知识
- 软件测试流程
- 测试用例设计方法
- 兼容性测试/易用性测试
- 缺陷管理
- 测试工具使用
- 测试文档编写
- 软件测试的原则
- 所有的测试应该追溯到用户需求
- 尽早启动测试工具
- pareto法则用于软件测试
- 28效率法则：在分析，设计实现阶段的复审核测试能发现和避免80%的缺陷，系统测试阶段又能找出其余缺陷的80%，最后的4%只会在用户的大范围，长时间的使用才暴露出来
- 穷尽测试是不可能的
- 杀虫剂怪事
- 软件测试的越多，对测试的免疫力越强。
- 前进两步，后退一步
- 三心二意：细心，信心，耐心。沟通意识，预防意识
- 软件测试工程标准
- ISO9000
- CMM
- 测试策略要素
- 测试安排发布计划
- 测试范围
- 测试资源
- 测试环境
- 测试方法
- 测试用例方法
- 文档管理
- 风险管理
- 上线跟踪验证
- 测试方案列表
- 1.需求说明
- 1.1 需求汇总
- 1.2 需求变更
- 2.总体计划安排和负责人
- 2.1 测试计划进度表
- 3.测试方案
- 3.1 测试重点
- 3.2 联测方案
- 3.3测试策略方法
- 3.4测试工具平台
- 4.环境搭建部署及数据准备
- 4.1 环境拓扑
- 4.2 应用部署
- 4.3 数据准备
- 5.测试执行计划
- 5.1 测试计划
- 5.2正向用例
- 5.3 反向用例
- 5.4 用例评审
- 6.测试工单
- 6.1冒烟工单
- 6.2 单测工单
- 6.3 联测工单
- 6.4 预发布验证工单
- 6.5 灰度验证工单
- 6.6线上验证工单
- 7.测试限制及无法测试功能列表
- 8.测试情况日汇总＆风险点、待确认列表
- 8.1 每日测试情况及风险点
- 1.需求说明
- 测试分析过程
- 1.分析需求
- 2.测试计划
- 3.测试范围及测试重点
- 4.测试策略及工具‘
- 5.测试用例设计方法
- 6.测试环境
- 7.联调测试
- 8.测试限制
- 9测试风险
- 测试方案评审
- 采用的测试方法
- 等价类划分的依据
- 测试数据的选取和准备
- 流程测试的路径组合
- 数据比对选取的对象和数据检查点
- 是否需要模拟数据及模拟数据的方法
- 基于风险的测试取舍
- 测试管理工具QualityCenter
- 基本概念
- 1.自动化工具分类
- 功能自动化工具：功能测试
- QuickTestProfessional(QTP）
- 性能管理工具
- LoadRunner
- 测试管理工具
- QualityCenter(质量中心)：对整个测试流程进行管理
- 版本管理
- 需求管理
- 用例管理
- 执行用例
- 缺陷跟踪管理
- 数据分析统计管理
- 白盒测试工具
- Junit
- Jtest
- 功能自动化工具：功能测试
- 虚拟机的概念
- 模拟计算机
- VMware Workstation
- QC简介
- 惠普公司产品，是B/S结构的产品，QC软件需要安装在服务器版的操作系统中
- Winserver2003/2008
- 数据库：sqlserver
- 如何访问
- 。。。。。。。
- （不重要，跳过）
- 1.自动化工具分类
- 基本概念
1.3 功能测试项目实训
-
- 酒店管理系统
- 理论联系实际
- 熟悉完整规范的软件测试流程
- 1.通过用户帮助手册，熟悉系统需求，熟悉软件各功能模块的基本使用
- 先熟悉整体
- 一级模块：来宾登记
- 二级模块：散客开单|团体开单|续/退押金
- 三级模块：
- 描述信息：建立宾客消费账单，需要填写客房信息，宾客信息，追加房间。
- 重要级别:urgent
- 先熟悉整体
- 2.编写核心模块的测试用例
- 房间设置（最小模块，最小单位）
- 房间设置数据分析
- 子模块名称：房间设置_添加类型
- 控件名称：房间类型
- 数据要求：1-40个字符，不为空，不能重复
- 有效等价类：1-40个字符
- 无效等价类：为空，重复，>40字符
- 边界值：0,1,2 39,40,41---0为空，已经有了
- 所属用例
- 备注:
- 允许开钟点房应该控制钟点房标准计费和钟点房特殊计费
- 钟点房特殊计费选项
- 下拉列表
- 选择选项
- 没有选项
- 边界值，第一项，最后一项
- 保存
- 按钮
- 打折设置
- 按钮
- 后面就针对多个控件分别写，都是一样的写法
- 房间设置测试用例
- 用例编号：系统维护_系统设置_房间设置_添加类型001
- 用例描述
- 目的
- 1.所有填写项正确，房间类型可以添加成功
- 2.允许开钟点房，，不允许钟点房特殊计费
- 预置条件
- 步骤
- 1.在“系统设置-房间设置”选项卡中点击“添加类型”按钮
- 2.在“增加房间类型”窗口中
- 房间类型：家庭经济套件
- 床位数量：3
- 预设单价：300/天
- 预设单价：180/半天
- 预设押金：300元
- 钟点房标准计费：40/小时
- 钟点房特殊计费复选框：不选择
- 允许开钟点房复选框：选择
- 3.点击“保存”按钮
- 目的
- 预期结果
- 1.打开“增加房间类型”窗口
- 3.“增加房间类型”窗口关闭，房间类型添加成功，重点检查
- “房间类型”表格
- “按房间类型过滤”下拉列表
- 主窗口中可以看到“家庭经济套件”选项卡
- 该种类型的房间可以开普通钟点房
- 说明
- 检查2，3项需要退出一次系统
- 检查第4项，需要添加该种类型房间才能测试
- 实际结果
- 房间设置数据分析
- 散客开单---场景法
- 编号：1
- 主要场景（测试点）：宾客类型
- 普通宾客
- VIP宾客
- 折扣卡
- 储值卡
- 协议宾客
- 所属用例
- 测试用例
- 用例编号：来宾登记_散客开单001
- 用例描述
- 目的：
- 1.为付款方式提供取值
- 2.为营销人员提供取值
- 步骤：
- 1.在“系统设置-计费设置”选项卡中的“押金类型”分组框中点击“添加”按钮
- 2.添加2中押金类型：中国银行信用卡和中信信用卡
- 。。。
- 目的：
- 预期结果
- 实际结果
- 3.执行测试用例，测试软件，发现缺陷，提交bug
- 4.阅读软件测试计划
- 5.编写测试总结报告
- 1.通过用户帮助手册，熟悉系统需求，熟悉软件各功能模块的基本使用
- 酒店管理系统
2.1 JAVA程序设计
-
- 暂时跳过
2.2 数据库技术
-
- 1.数据库基本概念
- 数据库，数据库管理系统，应用程序，用户
- 关系模型：二维表格，实体和实体之间的联系
- 属性：列，字段，域
- 元组：行，记录
- 主键：主属性，主关键字（唯一且非空）
- ER图：1:1,1：n,m:n
- 关系范式：消除数据冗余
- 第一范式：每个属性不可再分，不允许以数组，集合等方式存储
- 第二范式：在1NF的基础上，添加一个主键（主属性）
- 第三范式：在2NF的基础上，解除非主属性之间的依赖关系
- 非主属性的依赖关系：拆表
- 常见的数据库设计都使用3NF
- 2.数据库结构
- 物理结构：底层存储，例特殊文件（存储的地方）
- 主数据文件
- 事务日志文件
- 辅助数据文件
- 逻辑结构：便于分析解读（展示的地方）
- 能够在管理器中看到的，操作的数据库对象
- 物理结构：底层存储，例特殊文件（存储的地方）
- SQL语句
- 结构化查询语言（Structured Query Language）
- 通过SQL脚本，让DBMS执行，影响DB的底层，返回查询结果
- DDL 数据定义语言：定义结果
- create 创建
- drop 删除
- alter 改变
- DML 数据操纵语言：操纵表中的数据
- CURD（create update read delete）
- insert 插入
- delete 删除
- update 修改
- select 查询：DQL（数据查询语言）
- TCL 事物控制语言：Transaction 事物
- start
- commit:成功，提交事务
- rollback：失败，回滚事务
- 主流数据库的约束
- 主键约束：PK primary key
- PK=UK+NN 唯一且非空
- 唯一约束: UK unique
- 外键约束：FK foreign key
- 非空约束： NN not null
- 检查约束： CK check
- 默认值约束 default
- 主键约束：PK primary key
- 索引
- 目的：提高查询效率，提高数据库性能
- 类型
- 聚簇索引
- 记录的索引顺序和物理顺序相同（拼音查询）
- 非聚簇索引
- 记录的索引顺序和物理顺序不相同（偏旁部首）
- 作者索引
- 出版社索引
- 年代索引
- create index 索引名 on 表名（某个字段）
- 聚簇索引
- 索引的底层原理
- 数据结构：B树--平衡二叉查找树
- 查找方式：折半查找
- 数据库优化：针对字段建立索引
- 建立索引会增加系统开销
- 1.占据表空间
- 2.增加，删除，修改数据，效率降低，需要重新调整索引结构
- 适合：大海捞针，很少修改的情况
- 视图
- 目的: 简化SQL语句，不会占据表空间，不会提高sql效率
- 创建视图：create view my_view SQL语句
- 使用视图：select * from my_view
- select distinct * from Book;
- 1.数据库基本概念
2.3 软件开发项目实训
3.1 功能测试工具QuickTest Professional
熟练掌握功能测试自动化工具QTP ，学会使用VBScript编写测试脚本，提高测试效率
3.2 功能测试工具Qtp项目实训
3.3 白盒测试技术与白盒测试工具
4.1 性能测试工具LoadRunner
4.2Linux操作系统及网络环境
-
- ls
- adduser:添加用户
- userdel: 删除用户
- passwd：设置密码
- man
- info
- ifconfig:查看IP地址
- netconfig:设置IP地址
- service network restart:重启netconfig
- service iptables stop:关闭防火墙
- ping:网络是否畅通
- SSH远程连接Linux系统
- Linux历史
- 分区
- /---根分区，所有文件都存放在这
- /boot---启动分区，存放Linux内存的分区
- swap---交互分区，存放虚拟内存的分区
- /bin---可执行文件和命令
- /boot---启动目录，包括启动过程中大部分文件
- /dev---设置文件目录
- /etc:配置文件存放地
- /home:用户的目录
- fdisk -l ：查看设置了哪些分区
- mkdir
- ls -al
- rmdir
- 绝对路径和相对路径
- pwd
- cd
- cp
- cat
- mv
- chmod 修改文档权限
- vi的使用
- vi的三种模式
- 一般模式
- 编辑模式
- 指令列模式
- 模式转化
- 使用vi指令进入一般模式
- 一般模式下，i/o/a/r进入编辑模式
- 编辑模式下，esc进入一般模式
- 一般模式下，：，/,?，进入指令列模式
- vi XXX:新键文档
- vi的三种模式
4.3 性能测试工具LR项目实训
4.4综合项目测试
