一、IT（Information Technology），信息科技和产业
1.软件：
一系列按照特定顺序组织的计算机数据和指令的集合程序（项目包）+数据（通过界面操作对数据库的增删改查）+文件（安装说明书、文档）
2.产品：
能够供给市场，被人们使用和消费，能够满足人的某种需求的任何东西，包括有形和无形
3.项目：
通过一系列活动（相互关联），有一个明确的目标，在特定的时间、预算、资源内，依据规范完成
4.软件测试：
使用人工和自动手段来运行或测试某个系统的过程，目的在于检验是否满足规定的需求或是弄清结果与实际结果之间的差别，功能测试，性能测试
5.为什么做软件测试：
降低项目成本，定义需求和设计，及时处理缺陷，有效的发现问题，尽早知道所处缺陷的情况
6.软件测试任职要求：
软实力：责任心，沟通学习能力，团队合作，耐心，细心，信心等
硬实力：学历，技术，专业，技能，经验
二、软件生命周期：
request for proposal（需求调研，市场人员）
requirement analysis（需求分析，产品经理）
design（设计，选取框架等，概设，祥设）
coding（开发，编码）
testing（测试）
depoly（发布）
production support（运维，产品支持，技术支持）
sign off（下线）
三、测试基本原则：
1.测试是上下文相关的
基于软件所处的行业，所处的背景，医药、公司内部使用、淘宝...对于同一个测试点，测试强度是不同的
2.穷尽测试是不可能的
不可能把所有程序的所有的操作都测一遍
3.测试尽早介入
从需求开始就做测试，尽早的在前期发现问题
4.杀虫剂悖论
版本更替，不能使用相似的测试用例，很有可能发现不了新的问题
5.缺陷群集性
二八原则，当发现某一模块出现问题，那么这一模块也会有其他问题
6.测试证明存在缺陷
而不是为了证明不存在缺陷，隐藏在某个内部中，只是当前的测试用例还没有把问题暴露处理
7.无错谬误
软件是肯定存在问题，只是还没有发现
四、软件开发模型
1、研发模型：瀑布型
要求文档比较详尽
测试在编码完成后进行，发现需求问题，维护成本较高
2、研发模型：原型
需求分析阶段，会提前和客户确认（功能，页面等）
原型设计，一旦确定，就没有价值（需要花时间人力去做），避免后期发现问题，维护成本高
需求文档详尽程度要求没有那么高
3、研发模型：敏捷模型
以人为核心，迭代，循序渐进的开发方法（先发布核心部分功能（优先级，核心，重要），抢先占领市场，通过迭代的方式逐步完善）
五、软件测试模型
1、测试模型：V模型
单元测试，测试的是代码本身（开发人员），依据详细设计说明书
集成测试，多个代码集成在一起，关注的是软件功能本身，依据概要设计说明书
系统测试，非功能性的需求，依据需求规格说明书（可能会有概设文档和详设文档），
验收测试，客户组织验收，依据用户需求
优点：既包含低层测试又包含高层测试，低层是验证代码的正确性，高层是为了整个系统满足用户的需求
局限性：必须依照过程一步一步完成，不能体现尽早的和不断的进行软件测试的原则
2、测试模型：W模型，双V模型
需求测试，概要设计测试，详细设计测试，主要是对需求文档进行评审工作
优点：测试文档尽早提交，会有更多的检查时间
尽早的面对规格说明书的挑战
尽早的找出缺陷所在，从而可以帮助改进项目内部质量
局限性：无法支持迭代
3、测试模型：H模型
优点：不仅仅是测试的执行，也包括其他的活动
是独立的过程，贯穿产品整个生命周期，与其他流程并发进行
可以尽早准备，尽早执行
根据被测试的不同分层次进行
可以按照某个次序先后进行，也可以反复
六、软件测试阶段
1、需求测试：重点检查需求规格说明书
2、单元测试：类，函数，单元
正确性检验，检测模块对《详细设计说明书》LLD的符合程度
3、集成测试：对单元之间及单元与第三方接口之间的测试
检测模块对《概要设计说明书》的符合程度
策略：自底向上（驱动代码开发），自顶向下（桩模块开发），渐增式（一次只增加一个未测的模块）
4、系统测试：集成测试没有问题的前提下，将已经集成好的软件系统，与《需求规格说明书》做比较，发现与需求不符的地方
5、确认测试：有效性测试，验证软件的有效性，软件性能与特性是否与用户要求一致
6、验收测试：满足达到发布条件，用户来验收测试，成员包括项目成员，用户代表，利益相关者，对成品进行验收测试
Alpha测试：内部，模拟/真实
Beta测试：外部，真实
UAT（User acceptance Test）测试（用户接受度测试）：验证系统的可用性
7、回归测试：测试或其他活动中发现的缺陷经过修改后的测试，对系统其他的功能没有影响，任何一个阶段都可以发生，单元，集成，系统
7.1回归测试策略：
7.1.1完全重复测试
重新执行所有在前期测试阶段建立的测试用例
7.1.2选择性重复测试
有选择的重新执行部分在前期测试阶段建立的测试用例
|.覆盖修改法：指测试出错的部分被修改的部分完全覆盖
||.周边影响法（常用）：不但包含本身，还要分析影响周边的功能
|||.指标达成方法：重新测试前，先确定覆盖要达成的指标
7.2回归测试流程（单元，集成，系统）：
7.2.1制定回归测试策略
7.2.2确定回归的版本
7.2.3回归测试版本发布，按照回归测试策略执行回归测试
7.2.4回归测试通过，关闭缺陷跟踪单
7.2.5不通过，缺陷跟踪单提交开发人员，开发人员重新修改问题，再次提交测试人员回归测试
7.3回归测试自动化，针对要回归的测试用例
冒烟测试：测试时间短，选取基本的，核心的，重要的功能进行测试，如果不通过就没有必要进行后续的正式的测试工作，执行者是版本编译人员
七、软件测试类型
1.功能测试：是根据产品的需求规格说明书和测试需求列表，验证产品功能的实现是否符合产品需求规格
目标：|.是否有不正确的或遗漏的功能
||.是否满足用户需求和系统设计的隐藏需求
|||.输入的信息系统能否正确接受，能否正确输出结果
2.性能测试（Performance Testing）：就是用来测试软件集成系统中的运行性能，必须有工具支持，有专用于GUI或Web的性能测试工具，如Loadrunner（收费，模拟用户数），Jmeter（接口性能测试），SilkPerformer，WebLoad
目标：度量系统相对于预定义目标的差距
性能测试收集的信息：
CPU的使用情况
IO的使用情况
内存使用情况
信道使用情况
模块执行时间百分比
模块等待IO完工的百分比
指令随时间的跟踪路径
每一组指令页换入和换出的次数
系统反应时间
系统吞吐量，即每个时间单元的处理数量
所有主要指令的单元执行时间
3.负载测试：超过被测对象标准性能负荷指标下，验证系统的负载承受能力，要求超负荷情况下，依然正常实现业务功能
通过不断对被测对象施加负荷，观测被测对象在不同负载下的性能表现
4.压力测试（处理速度）：调查系统在其资源超负荷的情况下的表现，这类测试需要在一种需要反常数量、频率或资源的方式下执行系统
目标：通过极限方法发现软件的薄弱环节软件的自我保护能力，主要验证系统的可靠性，找到系统薄弱环节（成千上万的用户同时操作）
5.容量测试（处理数量）：指系统承受超额的数据容量来发现他能否正确处理
容量测试是面向数据的，并且它的目的是显示系统可以处理目标内确定的数据容量。
容量测试的例子：
l．使用编译器编译一个极其庞大的源程序；
ll．一个操作系统的任务队列被充满；
lll.庞大的Email信息和文件充满了Internet。
6.安全性测试（功能性测试范畴）：验证集成在系统内的保护机制是否能够在实际中保护系统不受非法的侵入，用来保证系统本身数据的完整性和保密性，如受到恶意攻击时，设备的自我保护能力，病毒防护能力，自定义通信协议安全性
安全性问题：
I．没有口令是否可以登录到系统中
Ii．各级用户权限划分是否合理
Iii．错误和文件访问是否适当地被记录
Iiii．系统配置数据是否能正确保存，系统故障时是否能恢复
安全性测试内容：系统的登录、用户管理、防火墙、系统数据、WEB的安全性、数据库的安全性、内部通信协议、系统防病毒测试
7.GUI测试：用户系统界面测试，测试工具有QTP（后期版本称为utf），selenium（开源的），包括界面实现与界面设计的吻合情况和确认界面处理的正确性
GUI测试对象：简单界面元素，组合类的界面元素，完整界面
8.可用性测试：基于用户的，是为了检测用户在理解和使用系统方面到底有多好。主要考虑产品是否符合实际应用情况，是否符合用户习惯或特殊要求，操作方式是否方便合理、设备和用户间的交互信息是否准确易于理解、是否遵从行业习惯、外观/界面是否美观等。应涉及到所有和用户有交互的功能或子系统。这包括系统功能、系统发布、帮助文本和过程，以保证用户能够舒适地和系统交互
一些测试人员应当关注的可用性问题：
•过分复杂的功能或者指令；
•困难的安装过程；
•错误信息不准确或者过于简单；
•用户被迫去记住太多的信息；
•语法、格式和定义不一致
9.安装卸载测试：系统的可安装性测试，主要是根据软件的测试特性列表、软件安装、配置文档，设计安装过程的测试用例，发现软件在安装过程中的错误
目的：不仅是找安装软件本身的错误，而且还要找安装文档的错误。在安装软件系统时，会有多种选择，要分配和装入文件与程序，布置适当的配置，进行程序的联结。而安装测试就要找出这些安装过程中出现的错误
10.异常测试：系统异常测试又叫系统容错和可恢复性测试，它是通过人工干预手段使系统产生软、硬件异常，通过验证系统异常前后的功能和运行状态，达到检验系统的容错、排错和恢复的能力。它是系统可靠性评价的重要手段
容错处理：
•系统自动处理
•人工干预处理
注意：
•系统异常测试还与系统的指标测试有关系，当系统需要提供的服务能力大于系统的设计指标时，也属于系统异常的情况，因此应该结合起来加以考虑
•系统的可靠性是设计出来的，而不是测试出来的。测试出来的数据有助于为我们进行进一步的系统优化设计积累经验，设计和测试是一个互为反馈的过程
11.文档测试：目标是验证用户文档是正确的并且保证操作手册的过程能够正确工作。
12.网络测试（接口测试）：网络测试是在网络环境下和其他设备对接，进行系统功能、性能与指标方面的测试，保证设备对接正常
内容：
网络测试考察系统的处理能力、系统兼容性、系统稳定可靠性及用户使用等方面。如通信产品，主要进行协议测试：
•一致性测试：检测所实现的系统与协议规范符合程度
•性能测试：检测协议实体或系统的性能指标（数据传输率、联接时间，执行速度、吞吐量、并发数等）
•互操作性测试：检测同一协议不同实现厂商之间，同一协议不同实现版本之间、或同一类协议不同实现版本之间互通能力和互连操作能力
•坚固性测试：检测协议实体或系统在各种恶劣环境下运行的能力（信道被切断、通信设备掉电、注入干扰报文等）
13.稳定性测试：系统稳定性测试目的是评价系统在一定负荷情况下、长时间的运行情况。包括系统在一定负荷下，再增加新的业务，原有的业务是否受影响，新的业务是否能正常工作，系统资源有无泄漏，数据有无不一致的情况，系统性能是否会降下来，关键点是长时间的运行后，系统的状况如何，系统平均无故障时间MTBF是否满足系统设计要求。
14.兼容性测试：兼容性测试验证被测对象与硬件、其他软件之间的兼容情况
八、软件测试方法
1.黑盒测试和白盒测试、灰盒测试
黑盒测试：已知产品的需求规格，不知道内部实现（代码），可以进行测试证明每个需求是否实现
黑盒测试把被测对象看成一个黑盒，只考虑其整体特性，不考虑其内部具体实现。
黑盒测试针对的被测对象可以是一个系统、一个子系统、一个模块、一个子模块、一个函数等。
黑盒测试又可以被称为基于规格的测试。
常见的黑盒测试类型
•功能性测试，一种是顺序测试每个程序特性或功能，另一种途径是一个模块一个模块的测试，即每个功能在其最先调用的地方被测试；
•容量测试，检测软件在处理海量数据时的局限性，能发现系统效率方面的问题；
•负载测试，检测系统在一个很短时间内处理一个巨大的数据量或执行许多功能调用上的能力；
•恢复性测试，主要保证系统在崩溃后能够恢复外部数据的能力；
黑盒测试的特点：
•对于更大的代码单元来说（子系统甚至系统级）比白盒测试效率要高；
•测试人员不需要了解实现的细节，包括特定的编程语言；
•从用户的视角进行测试，很容易被大家理解和接受；
•有助于暴露任何规格不一致或有歧义的问题；
白盒测试：已知产品的内部实现过程，可以通过测试证明每种内部操作是否符合设计规格的要求，依据被测软件分析程序内部构造，根据内部构造设计用例，来对内部控制流程进行测试，可完全不顾整体功能实现情况，白盒测试是基于程序结构的逻辑驱动测试。
白盒测试又可以被称为玻璃盒测试、透明盒测试、开放盒测试、结构化测试、逻辑驱动测试
为什么进行白盒测试
I．白盒测试一般在测试前期进行，通过达到一定的逻辑覆盖率指标，使得软件内部逻辑控制结构上的问题能基本得到消除
Ii．白盒测试能保证内部逻辑结构达到一定的覆盖程度，能够给予软件代码质量更大的保证
Iii．白盒测试发现问题后解决问题的成本较低
白盒测试常用技术：静态分析和动态分析
静态分析：控制流分析、数据流分析、信息流分析等
动态分析：逻辑覆盖测试（分支测试、路径测试等）、程序插装等
白盒测试方法：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖，组合覆盖
灰盒测试：
•根据利用的被测对象信息的不同，会采用不同的方法进行测试。
•利用被测对象的整体特性信息，采用黑盒测试方法
•利用被测对象的内部具体实现信息，采用白盒测试方法
•如果既利用被测对象的整体特性信息，又利用被测对象的内部具体实现信息，采用的就是灰盒测试方法。两种信息占的比例不同，相应的灰度就不同。完全是整体特性信息，就是黑盒测试，完全是内部具体实现信息，就是白盒测试
•典型的灰盒测试比如集成测试和系统测试时借助log信息
2.静态测试与动态测试
静态测试：不运行被测试的软件系统，采用其他手段和技术对被测试软件进行检测，如代码走读、文档评审、程序分析，常用的技术有静态分析技术
静态分析技术：是一种不通过执行程序而分析程序执行的技术
功能：检查软件的表示和描述是否一致，没有冲突或者歧义，瞄准的是纠正软件系统在描述、表示和规格上的错误
主要有三种不同的程序测试可能性：
考虑程序是否满足编码规则，语法上是否具有一致性和完整性
考虑文档描述是否规范、准确、便于查阅
考虑程序与文档之间的一致性
动态测试：按照预先设计的数据和步骤去运行被测试软件系统，从而对被测试系统进行检测的一种测试技术，常用的有
3.人工测试和自动化测试
人工测试：测试活动（评审、测试设计、测试执行等）由人来完成，狭义上是指测试执行由人工完成
自动化测试：指通过计算机模拟人的测试行为，替代人的测试活动，狭义上只测试由计算机完成
自动化测试的意义：
对新版本运行前一版本执行的测试，提高回归测试效率，
可以运行更多更频繁的测试，比如冒烟测试，
可以执行手工测试困难或不可能的测试，比如大量的重复的操作或者集成测试，
更好的利用资源，比如测试仪器或者被测试对象
自动化测试的限制：
不能取代手工测试，只能提高测试有效性，不能发现更多的缺陷
手工测试比自动化测试发现的更多
对测试设计依赖性极大，测试设计的不好会遗漏问题
对软件开发具有很大的依赖性，开发上 变更会导致前面的自动化测试完全失效
工具本身不具备想象力
九、软件测试流程
•测试计划阶段 – 测试计划
•测试设计阶段 – 测试方案
•测试实现阶段 – 测试用例、测试规程
•测试执行阶段 – 测试报告
主要的测试文档：
1.测试计划：指明测试范围、方法、资源，以及相应测试活动的时间进度安排表的文档。
2.测试方案：指明为完成软件或软件集成特性的测试而进行的设计测试方法的细节文档。
3.测试用例：指明为完成一个测试项的测试输入、预期结果、测试执行条件等因素的文档。
4.测试规程：指明执行测试时测试活动序列的文档。
5.测试报告：指明执行测试结果的文档。
6.测试日报：每天测试执行情况的记录和总结。
系统测试过程与开发阶段：
系统测试各阶段的输入，输出
测试工程师系统测试各阶段任务：
软件需求阶段：评审软件需求规格说明书
软件设计阶段：评审软件概要设计说明书、软件详细设计说明书、协助编写系统测试计划
软件编码阶段：设计系统测试用例、准备测试资源（测试工具、测试环境等）、开发测试脚本、开发测试工具、准备测试数据
软件测试阶段：执行测试用例、提交缺陷单、跟踪缺陷、回归测试、提交测试报告
十、软件测试质量
1.软件质量是许多质量属性的综合体现，正确性，精确性，健壮性，可靠性，容错性、性能、易用性、安全性、可扩展性、可复用性、兼容性、可移植性、可测试性、可维护性、灵活性等
2.分为两大类：功能性与非功能性
3.质量模型：一组特性及特性之间的关系，他提供规定质量需求和评价质量的基础
