第一节：
前言：从概念入手，才能少走弯路并且对与此相关的问题有一个正确的认识进而解决问题，应了解什么是软件、软件的内容及其生命周期。
软件：程序+数据+文档的集合
软件的生命周期：可行性分析、需求分析、概要设计、详细设计、编码、测试、使用、维护（当软件所产生的利润低于维护费用时其生命周期接受）
程序：能够实现软件功能的对应代码
数据分为三部分：
开发数据：指的是开发人员在进行开发某一功 能过程中调试人员所传入的数据（理想数据）
测试数据：指的是测试人员在测试过程中所传入的数据（现实数据）
用户数据：用户真实存在使用的数据
文档：与程序开发、维护、使用有关的文本；比如用户文档（测试输出：测试计划、测试方案、测试用例、缺陷报告、阶段性总结报告、总结报告、试运行报告等等）
测试：测试的一切依据都必须回归到需求（用户的要求）
软件测试含义：在软件工程学中，检测被测软件或系统是否满足需求的过程（由IEEE机构提出此概念）
软件的分类：
系统软件（window系列、linux系列）
支撑软件（插件、中间件）
开发软件（程序人员应用开发（开发IDE）、数据库IDE、测试自动化）
应用软件（娱乐、专业办公）
软件测试的目的：发现问题并解决问题
如果没有测试那么后期的维护费用会剧增，而如果在整个过程中存在在测试的话那么后期维护会趋于平稳甚至下降
课外了解：
1. 软件是一种逻辑实体而不是物理实体，具有抽象性
2. 软件没有明显的制造过程，提高质量要在软件开发方面下功夫
3. 软件使用期间不存在磨损、老化问题，但会退化，需要进行修改与维护（这也是测试存在的意义之一）
4. 软件开发至今尚未摆脱人工开发的方式
第二节：
职位架构：
项目经理（PM）：
开发工程师（DE）：
系统测试工程师（STE）：
界面设计（美工）（UI）：
数据分析(DBA)：
需求分析（SRS）：
项目：5w原则：what、when、where、who、how
在软件工程学中，实现用户所提出的需求的一系列过程称为项目
产品：
项目不一定是成品，产品一定是项目（错）
项目是产品的过程，产品是项目的过程（对）
产品的完成一定要经过项目的过程（错），而项目的结束不一定得到产品
项目可能随时停止，此时则无法得到成品
产品也可能存在失败的产品（vista）
项目与产品的区别：
从用户角度分：项目针对的是单一用户或者是多个用户而言的，而产品针对的是市场而言
从技术角度分：项目的需求是可变的，而产品的需求是固定的
从价格角度分：针对项目的费用而言，项目要比产品耗费更大；产品的利润要大于项目
测试需具备：
素质：团队合作能力、良好的沟通能力、用心、探索创新精神
技术：1.简单的代码走读能力
2.熟练掌握软件测试概念和软件测试流程
3.熟练掌握软件测试设计方法
4.熟悉数据库基础（简单的增删改查操作），全会
5.熟悉环境的搭建（项目部署）
6.熟悉测试工具的使用：缺陷管理工具、自动化管理工具、性能测试工具
7.白盒测试理论和技术、集成测试理论和技术（高阶）
测试过程提交问题开发不予理会解决方法：（人事问题）
首先沟通，定位问题所在，告知这个问题会导致后果（公司损失，无法满足客户要求等）；
一直催；若催促无效，不管这个人，问题提交至领导，并且看领导是否解决妥当
在周会、月会之类的项目会议上提出（发现的问题一定要跟踪到底）
项目的架构：
B/s(browser server)浏览器 服务器
C/s(client server)客户端 服务器
B/s和c/s混合架构（oracle数据库）
测试原则：
1. 测试必须尽早地参与（立项时候就开始需求分析）
2. 测试必须回归需求
3. 测试无法穷举
4. 测试可以提高软件质量，无法保证质量
5. 测试应用用户角度去发现问题（开发人员思维存在局限性）
6. 设计一条用例尽可能覆盖多条路径
7. 设计一条用例能发现至今从未发现的问题
测试与调试的区别：
按含义分：1.测试：在软件工程学中，检测被测软件或系统是否满足需求的过程（由IEEE机构提出此概念）
2.调试：使用相关工具进行检测代码是否达到预期值的过称
按执行者：1.测试：测试人员
2.调试：开发人员
按时间分：1测试：有计划性有目的性的
2调试：是随时性的
按目标分：1测试：处于用户角度尽可能地完善系统的功能
2调试：完成任务
课外知识：TMM软件测试成熟度模型，用于衡量企业软件测试专业化程度，国内大部分处于第三级（大公司），五个成熟度等级
1. 初始级 测试过程无序的，甚至是混乱的
2. 定义级 测试已具备基本的测试技术和方法，测试与调试已被明确的区分开
3. 集成级 测试已经融入到软件的生命周期，遵循V模型，从需求分析开始制定测试计划
4. 管理和度量级 测试包含各个阶段的评审、验证活动
5. 优化级 能制定缺陷预防计划，防止已识别的缺陷再次发生
第三节
定义：Error(错误) fail（失败） bug defect（缺陷）
缺陷的产生： 主要由环境因素和人为因素导致
在针对一个系统开发过程中，如果开发人员过于自信，在开发过程中犯了一个错误（error），那么将会使得测试结果无法达到预期（缺陷），最后会称该开发为失败的开发（fail）
缺陷：测试一个软件过程中发现某一功能无法达到预期结果成为称为（即bug）：1+1=2
错误：指的是人为操作导致，功能没有实现2+3
在IT业界中，缺陷没有准确的定义，并且缺陷（defect）和错误（error）统称为bug
缺陷和错误没有直接或者间接关系
缺陷一定是错误，错误不一定是缺陷（X）
缺陷可能是错误产生的，错误产生的不一定是缺陷(X)
漏洞：指软件系统功能、安全等各个点需要增强修复的操作
主要产生缺陷的原因：
1）需求不明确
2）相关文档不齐全
3）开发过于自信
4）相关技术无法满足要求
5）相关人员沟通不及时
6）测试人员测试不完全
7）环境因素等
缺陷分类：
有效缺陷：不符合需求的且被开发人员认可的缺陷
无效缺陷：不符合需求的且不被开发人员所认可的，但测试人员认可的缺陷（一种测试误提
合法的无效缺陷：存在的、不符合需求的但开发目前技术无法修复的
提交重复性bug的原因：
1）测试任务分配不合理，使得测试人员重复测试。
2）版本控制问题（SVN CVS VSS）
3)BUG管理不当
Bug的管理方式：
1）word
2）excel
3）缺陷管理工具（testdirector（TD）,QC(quality center),开源：jira,bugzilla,bugfree,禅道）mantis已过时
重现bug的必要性：
1）便于开发人员对bug的定位（排除法）
2）便于对bug的重现率进行统计（例如：偶然bug的产生）（将会使用自动化的形式进行检测）
3）提高了开发与测试的工作效率
产生无效缺陷的原因：+重复性bug的原因
1）测试任务分配不合理，测试人员重复测试
2）版本控制问题
3）bug管理不当
4）需求不明确
5）环境因素（开发环境，测试环境，用户真实环境）
TD、QC-----mercury----HP公司（所有的测试工具都是兼容性非常差，维护力度非常大）
针对于TD装在本机且本机访问的话：IP地址、localhost.127.0.0.1、计算机名
缺陷状态（重点！）：
当测试人员发现一个bug，在缺陷管理工具上新建一个bug，指派给测试经理。测试经理验证bug是否重现，若未重现，则将bug关闭；反之则将bug打开指派至相关开发人员或开发经理，并将bug状态设置为打开。
开发人员接受bug后验证bug是否为有效bug，若问题确实存在，则修复并关闭；
若开发人员发现bug在现阶段无法修复，则通知测试人员将bug延期，在下一版本回归测试过程中，测试人员将延期bug重新打开指派至开发人员，待开发人员验证是否可以修复；
若开发人员验证当前bug为无效bug，则将其拒绝并指派至测试人员，测试人员验证开发人员拒绝的bug是否可以关闭，否则将其重新打开指派至开发人员，开发人员重新验证bug是否有效，若有效则修复。
经过反复多轮的回归测试，最终所有bug都需要关闭（注：开发人员只有拒绝权限）
第四节
TD的使用：
License-------密钥B343P-44B44-43444-6444S
Domain 域
Remove和delete项目：一个在硬盘上仍然存在资料
Custom用户的界面
缺陷的内容：（按重要性分先后）
前置条件（为测试步骤省略一系列重复性操作步骤且对后续测试无影响）、测试环境、操作步骤、预期结果、实际结果
状态、严重级、优先级、
所属模块、缺陷标题、发现人、发现日期、备注、发现版本、修复人、修复日期
描述bug：简单明了，通俗易懂，详细准确
例：修改字体，字体无变换
前置条件：能成功打开记事本
测试环境：硬件环境：cpu、显卡等
软件环境：操作系统等
操作步骤：1）点击“格式”
2）点击“字体”
3）选择“宋体”
4）点击“确定”
预期结果：1）示例中的内容变为宋体格式 2）记事本中的内容为宋体格式
实际结果：1）示例中的内容格式无变换 2）记事本中的内容也无变化
附件：截图等
建议：等
严重级：
最高严重级：系统崩溃、闪退、数据丢失、内存泄露
较高严重级：功能未实现、数据错误、软件兼容性问题
一般严重级：界面问题（协调、美观、布局是否合理）、显示（明文密码）、错别字
建议：体验性用户操作（用户易用性操作）
优先级： 对bug要求修复的紧急程度进行定义声明
最高优先级、较高优先级、一般优先级、最低优先级：
优先级别高的bug严重级别一定高（错）------公司logo问题
严重级别高的bug优先级别一定高（错）------合法的无效缺陷，当前技术无法达到
严重级别高的bug优先级别通常会高（对）
缺陷内容：前置条件、测试环境、操作步骤、预期结果、实际结果、状态、严重级、优先级、所属模块、缺陷标题、发现人
缺陷报告：
（1）简单描述
（2）用一句话简单地描述清楚问题
（3）详细描述
1）被测试软件版本、状态、严重级别、优先级别、提交日期、提交人
2）描述问题的基本环境（操作系统、硬件环境、网络环境、被测试软件的运行环境）
3）使用最少步骤去重现测试工程师的操作步骤和使用的数据
4）测试工程师根据上述信息可以给出对问题的简单分析
第五讲
试环境：测试人员进行软件测试的环境，并且该环境是尽可能的去模拟用户的环境
开发环境：开发人员进行开发软件所处的环境，并且该环境是理想环境
用户环境：软件需要进行发布实施的用户现场
4. 测试环境与开发环境分开
１）测试环境更切合真实性，便于发现问题
２）便于版本控制
３）便于缺陷管理
5. 如果存在偶然bug或者重现困难的bug如何解决：
1）环境（版本、兼容性问题）
2）操作（记录操作，让其他人来重复一遍）
3）改变思维测试（正向思维，逆向思维）
项目流程：
第六节
1. 测试计划：
1）合理分配人力物力资源
2）时间表的制定
3）测试策略 (确定被测系统需要进行哪些类型的测试)
4）风险规避措施 （时间、人员、技术、环境、需求变更）
2. 测试计划作用：
1）对整个测试过程具有指导作用
2）便于测试工作的管理
3）提高测试效率
3. 测试方案：
1）时间表
2）测试策略（具体类型对应的测试方法）
3）任务模块的具体分配
4. 概要设计(HLD)：
1）系统架构图、系统结构图、系统框架等
2）主要表示通过需求进行使用专业术语转换而来开发内部熟悉的东西，主要包含对整个系统初步的结构设计
3）定义模块间抽象化概念
5. 详细设计(LLD)：主要包括程序流程图、数据流图、类图
6. 阶段性总结报告：
1）对该阶段所耗费的相关资源进行统计
2）分析缺陷分布情况
3）为下一轮测试提供建议
7. 阶段性总结报告的作用：
1）为下一次测试提供指导作用
2）为下一次测试起里程碑作用
3）方便总结报告的编写
8. 总结报告：
1）对每一阶段的总结性进行综合
2）测试结果（判断版本是否通过）
3）注意事项（造成错误结果的操作及正确操作）
9. 总结报告的作用：
1）为其他项目测试提供基准
2）为验收测试提供准则
3）确保所有功能都已经被测试
10．二八定律：百分之二十的模块会发现百分之八十的缺陷（连锁反应造成）
11. SRS（需求分析）
12. Demo版本（初始版本）
1）要求整个被测系统的主体功能必须全部实现
2）配置文档：用于搭建测试环境（内容：搭建步骤）
13. 冒烟测试：
1）内容：在测试用例库中选取主体业务流程的测试用例进行执行
2）
第一次，提交Demo版本时，又称预测试；若执行通过率超过80%，则测试人员会接受该Demo版本；
第二次，在验收时，确保验收版本为准确版本（给用户的版本的准确性）；确保主业务流程没有问题
14. 提交Demo版本后的开发人员：
1）完善其他模块功能
2）对bug的修复
3）对被测软件程序代码进行优化
4）参与其他项目的开发
15. 提交缺陷报告后的测试人员：
1）相关测试输出的整理
2）参与其他项目的测试
3）缺陷跟踪
4）在后期测试过程中对测试用例库的维护（追加测试用例）
5）其他项目的维护（产品部提交相关问题到测试部进行重现，然后定位问题，然后给开发修复）
第七节
1. 用户手册
（1）本地（在安装包内）
（2）联机（在软件服务器下载）
2. 说明书：内容简洁明了，图文并茂
（1）操作内容
（2）注意事项
（3）运行环境
（4）专业术语
3. 文档测试
（1）术语
（2）标题
（3）内容
（4）图表和截屏
（5）示例
（6）错别字
（7）排版
4. 验收
（1）alpha测试：先由产品部验收，再交给用户（在公司内部环境验收）
（2）beta测试：直接交给用户（在用户真实环境中验收，用户产生报告交给公司）
5. 验收准则
（1）用户需求功能全部实现
（2）不存在残留的一、二、三级bug
（3）所有软件功能实现符合概要设计与详细设计
（4）所有相关项目的输出工件齐全
6. 评审的作用
（1）需求明确，利于开发与测试工作的进展
（2）及时发现并解决问题
（3）使项目管理更规范，提高工作效率
（4）利于归纳总结，增加测试经验
开发模型
（1）瀑布模型
1）可行性分析、需求分析、软件计划、软件设计、软件测试、软件维护
2）一般用于大型项目
3）优点：
a. 层次分明，每阶段结束都有总结
b. 需求分析、软件测试与维护都有用户参与
c. 需求分析与软件计划准备充分
4）缺点：
a. 流程不可逆
b. 若需求更改，后期维护费用高
c. 用户是一个不稳定因素
d. 风险高
e. 测试没有尽早参与
（2）快速原型
1）基于原型所进行的再开发
2）优点：
a. 项目成本和周期减少
b. 风险相对较低
c. 反复修改与改进，使产品更符合需求
3）缺点：
a. 必须拥有一个符合用户需求的原型
b. 原型差距越大，成本越高
c. 开发与测试交互过多，工作量大
d. 管理复杂
（3）螺旋模型
1）制定计划、风险分析、实施工程、客户评估
2）优点：
a. 风险最小
b. 后期维护成本低
c. 每个周期结束都得到客户认可
d. 具有灵活性
3）缺点：
a. 周期太长
b. 用户必须参与
c. 版本过多，工作量大，管理复杂
（4）敏捷开发模型：继承了快速原型和螺旋模型的综合体
1）优点：灵活、敏捷
2）缺点：不适用于大型项目
为什么测试需要尽早的参与？
1）尽早发现问题尽早解决，降低成本
2）需求越渐明确
3）减少后期维护工作量，降低后期维护难度
BVT测试(Best Version Test)：
优先级测试（在设计测试用例过程中会进行对测试用例添加优先级的项，然后如果时间紧急则会根据当初定义的优先级用例进行执行），在项目发布后，后期还必须要将其余的测试用例都执行完成（发现的问题后期需要进行跟踪解决）
单元测试过程中将会发现约百分之八十的缺陷，因为单元测试是所有测试中最早开始的，并且在刚开始的版本集中发现最多bug
第八节
测试模型：V、W、H、X
（1）V模型：
1）优点：
a. 前期开发有足够的时间进行编码（准确分析理解需求）
b. 开发与测试之间在项目中层次分明
2）缺点：
a. 测试没有尽早参与
b. 开发与测试之间的交互甚少
c. 测试时间不够充裕（测试不全面，质量无法提高）
d. 项目周期较长（先开发后测试）
（2）W模型：相当于由两个V模型构成，一个V模型为开发过程、一个V模型为测试过程
1）优点：
a. 测试实现了尽早的参与
b. 开发与测试具有良好的交互（及时发现并解决问题）
c. 具有足够的时间进行测试
d. 开发与测试实现了并行操作
2）缺点：
a. 开发没有足够的时间（设计阶段不够具体不够详细）
b. 增加了开发的工作量（在开发设计阶段除了编码阶段还要修复bug）
c. 缺陷控制困难（bug无法进行集中式处理解决—解决：按阶段提交）
d. 版本控制问题（阶段性提交）
（4）H模型：前期准备阶段开发与测试相互独立，后期开发与测试进行交互（交互点是在开发提交demo版本给测试部时，并且根据配置文档进行搭建测试环境）
1）优点：
a. 开发与测试交互合理（提高工作效率）
b. 开发与测试前期准备工作充足
c. 开发与测试内部流程相互独立
2）缺点：
a. 开发与测试前期缺少交互（导致各自对需求理解存在偏差）
b. 进度控制困难（无法确定交互点）
c. 后期工作量增加
（5）X模型：相当于是由开发人员逐个模块进行开发，开发后交由测试人员进行测试，等所有模块全部开发完成后进行集成，然后测试人员对整个系统进行全面测试。适合集成测试阶段使用的模型。并且与敏捷开发模型相似
1）优点：
a. 测试点细、面广（每个模块进行独立测试）
b. 实现了多类型测试
c. 能够尽可能多的发现问题
2）缺点：
a. 单元、集成测试时间耗费过多，使得系统测试不全面
b. 集成阶段测试困难（有可能存在兼容问题）
c. 流程复杂，测试开发工作量大
d. 封版实现困难
第九节
测试分类
按结构分：黑盒测试、白盒测试、灰盒测试
按是否执行分：静态测试、动态测试
按阶段分：单元测试、集成测试、系统测试、验收测试（alpha测试、beta测试）
1.黑盒测试又称为功能测试，不考虑内部逻辑运算，只考虑外部功能的实现
2.白盒测试又称为结构测试、逻辑驱动测试，不考虑外部功能，只考虑内部逻辑运算的实现（分多个单元测试）
3.灰盒测试：白+黑 同时关注外部功能的实现也关注内部逻辑运算的实现
4.静态测试：指不运行被测对象，人工对被测对象和文档进行分析和检查，实际上是对需求分析、技术说明书、程序源代码等进行检查。包括代码审查，代码走读，桌面检查，技术评审，静态分析。
5.动态测试：指实际运行被测对象，检测是否符合客户需求的过程。（软件测试的含义）
6.单元测试：以一小段代码块为基础进行测试，比如某一属性或方法
与白盒测试的区别：
1.白盒测试按结构分，单元测试按阶段分；分类不同，含义不同
2.白盒测试是对整个的逻辑测试，单元测试是对一小段代码块测试
3.单元测试的用例设计参照白盒测试六大法（实际执行的是单元测试，n次单元测试组合成 为白盒测试）
7.集成测试：模块与模块之间的接口测试，渐增式、非渐增式、自底向上、自顶向下（模块与模块之间要有良好的独立性，高内聚，低耦合）
8.系统测试：指被测对象经过系统（一系列）的测试，比如：功能测试，界面测试，性能测试，易用性测试，兼容性测试等一系列测试。
9.验收测试：alpha测试（公司内部验收后交给用户验收），beta测试（直接给用户验收，用户真实环境）
10.性能测试：模拟用户真实操作，分析所产生的性能指标是否满足客户需求的过程，比如：压力测试、负载测试、并发测试、配置测试、强度测试、疲劳测试
11.压力测试：对服务器一步一步施压，检测被测对象性能瓶颈的过程
12.负载测试：检测服务器在一定压力下各项性能指标是否满足客户需求的过程
13.并发测试：针对集合点的测试（分为同一操作的并发、不同操作的并发）
14.易用性测试：检测被测对象是否符合用户操作习惯（单击，双击，快捷键）
15.兼容性测试：硬件兼容（机器与机器之间，如：打印机），软件兼容（支撑软件，开发软件，系统软件，应用软件）
16.安全测试：防火墙（硬件防火墙，如路由器）、软件防火墙（如：windows自带防火墙）、系统漏洞、远程协助、安全策略、病毒（SQL数据库注入，通过网络实现攻击）
17.可靠性测试：指被测对象在稳定环境下运行能否正常运行一段时间（7x24或3x24）
18.异常测试：检测被测对象的容错能力，进行特殊的操作（除数为0）
19.恢复性测试：指被测对象异常关闭时重新启动时能否恢复到上一步的操作（word文档不定定时保存）
20.变态测试：对被测对象进行破坏性的操作：断电、杀进程等
21.健壮性测试：评估被测对象承受破坏性操作的能力
22.数据库测试：大数据容量测试（大量数据集中增加或删除或改动或查询的操作）、历史数据测试（将不经常使用的数据迁移到历史数据库中腾出空间来注入新的数据，要求准确性）
23.穿越测试：银行、游戏、游戏行业，主要使用场景发设计用例（数据穿越后的准确性）
24.web测试：网页、网站、cookies（缓存）
25.文档测试：内容测试（正确准确）、语句测试（通顺无错别字）
26.回归测试：在新版本测试之前验证上一版本的bug是否已经修复的过程，可存在多个回归测试。
27.随机测试：执行随机抽取的测试用例
