功能测试(FunctionTesting)：测试软件的功能是否符合功能需求，通常采用黑盒测试方式。一般由独立测试人员执行。
易用性测试：测试软件是否易用，主观性比较强。一般要根据很多用户的测试反馈信息，才能评价易用性。
兼容性测试：测试该系统与其他软件或者系统平台（软件/硬件）的兼容性。包括自身兼容性（历史版本数据，功能兼容）、平台兼容性（window平台、Linux平台等的兼容）、设备兼容性（Android产品，iOS产品等的兼容）、与其他软件兼容性等。
部署测试：也叫安装测试，确保该软件在正常或异常情况下都能进行安装（进行首次安装、升级、完整的或自定义的安装--正常情况；磁盘空间不足，缺少目录创建权限，安装过程中关机重启--异常情况）（部署方式：分布式部署，集中部署等）
文档测试：检验样品用户文档的完整性，正确性，一致性，易理解性，易浏览性。包括用户手册，配置手册、安装手册，使用说明，用户帮助文档等。
本地化测试：不同区域不同版本的测试（中文版本测试，英文版本测试等）
无障碍测试：针对特定的用户群体，比如老年人，残疾人等类型的用户
竞品测试：同类产品在功能、性能等方面的对比测试。
2.按是否查看程序内部结构分类
灰盒测试(Gray-BoxTesting)：是一种综合测试方法，他将黑盒测试和白盒测试相结合，基于程序运行时的外部表现又结合内部逻辑结构来设计用例，执行程序并采集路径执行信息和外部用户接口结果的测试技术。
白盒测试(White-BoxTesting)：结构测试或逻辑驱动测试，是一种按照程序内部逻辑结构和编码结构，设计测试数据并完成测试的一种测试方法。
3.按是否运行程序分类
静态测试(StaticTesting)：指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行找错。技术应用包括控制流分析技术、数据流分析技术、信息流分析技术等。
软件质量的衡量方面：功能性（Functionality）、可靠性(Reliability)、可用性(Usability)、有效性(Efficiency)、可维护性(Maintainability)、可移植性(Portablity)
动态测试(DynamicTesting)：是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等性能指标。组成部分：构造测试用例、执行程序、分析程序的输出结果。技术应用包括逻辑覆盖率测试技术（分支测试技术、路径测试技术等），程序插装等。
4.按阶段测试分类
单元测试(UnitTesting)：又称模块测试，是针对软件设计的最小单位----程序模块或功能模块，进行正确性检验的测试工作。其目的在于检验程序各模块是否存在各种差错，是否能正确地实现了其功能，满足其性能和接口要求。常用方法：白盒测试。
测试阶段：编码后
测试对象：最小模块
测试人员：白盒测试工程师或开发工程师
测试依据：代码和注释+详细设计文档
测试方法：白盒测试
测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试
集成测试(IntegrationTesting)：又叫组装测试或联合，是单元测试的多级扩展，是在单元测试的基础上进行的一种有序测试。旨在检验软件单元之间的接口关系，以期望通过测试发现各软件单元接口之间存在的问题，最终把经过测试的单元组成符合设计要求的软件。常用测试方法：灰盒测试。
测试阶段：一般单元测试执行之后进行
测试对象：模块间的接口
测试依据：单元测试的模块+概要设计文档
测试方法：灰盒测试（黑盒测试和白盒测试相结合）
测试内容：模块之间的数据传输、模块之间的功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响。
确认测试：又称有效性测试。任务是验证软件的功能和性能及其它特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明书中已经明确规定。它包含的信息就是软件确认测试的基础。
系统测试(SystemTesting)：是为判断系统是否符合要求而对集成的软、硬件系统进行的测试活动、它是将已经集成好的软件系统，作为基于整个计算机系统的一个元素，与计算机硬件、外设、某些支持软件、人员、数据等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。
测试阶段：集成测试通过之后
测试对象：整个系统（软硬件）
测试人员：黑盒测试工程师
测试依据：需求规格说明书
测试方法：黑盒测试
测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等。
验收测试(AcceptanceTesting)：以用户为主的测试，软件开发人员和质量保证人员参加，由用户设计测试用例。不是对系统进行全覆盖测试，而是对核心业务流程进行测试。
测试阶段：系统测试通过之后
测试人员：最终用户或需求方
测试依据：用户需求，验收标准
测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性，程序设计文档及说明书等。
5.黑盒测试分类
功能测试：菜单、工具栏、快捷键、下拉框、按钮、单选按钮、复选按钮、切换、链接（集成测试阶段）、触发键
1.逻辑功能测试：
3.易用性测试：
4.兼容性测试：
5.接口测试：也叫业务流程测试（包括功能模块之间、模块与模块之间、子系统之间），分为内部接口（即函数调用[导入导出]）和外部接口两部分。服务器接口、外部接口、错误处理。接口测试工具：charles，postman,jmeter等。
注：
6.容错测试：数据长度、数据类型、非法操作等
名词解释：
空间性能：软件运行时所消耗的系统资源
测试项目：
1.可靠性测试：硬件方面（材料等），如高低温测试，防水防尘测试等。
3.负载测试：确认系统正常指标下的最大负载。步骤：在测试过程中，逐步增加负载，并记录被测系统响应的性能表现，最终确认出系统的最大负载。
4.压力测试：确认系统所能承受的最大极限。是指在极限压力情况下，系统崩溃的极限条件测试。大用户测试（针对B/S而言）
5.容量测试：大数据量测试。
6.强度测试：系统续航量测试
7.安全性测试：
8.恢复测试：突然断电（系统触发正常启动；数据包要在断电的地方继续进行处理）
9.标杆测试：
11.配置测试：分为最低配置和推荐配置两种。
12.安装测试：安装过程和卸载过程
13.文档测试：交给用户的文档。例如：系统帮助、用户使用手册、用户安装手册
14.可用性测试：靠经验。
15.初始化测试：是指系统刚刚安装完成后，在数据位空的情况下，如果被调用的模块为空，点击调用模块的时候，是否进行容错的测试。
6.是否手工执行
手工测试(ManualTesting)：由人一个一个的输入用例，然后观察结果，和机器测试相对应，属于比较原始但是必须的一个步骤。
优点：自动化无法替代探索性测试、发散思维类无既定结果的测试。
缺点:执行效率慢，量大易错。
自动化测试(AutomationTesting)：在预设条件下运行系统或应用程序，评估运算结果，预先条件应包括正常条件和异常条件。即模仿人的动作和行为。一般常用的自动化测试如功能测试自动化（默认）、性能测试自动化、安全测试自动化等
7.其他测试类型
冒烟测试(SmokeTesting)：对一个系统进行大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。冒烟测试又称为版本验证测试，他的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件的基本功能正常，可以进行后续的正式测试工作。冒烟测试是在开发人员交付软件时进行的大体预测，主要是针对整体流程和主体功能进行测试。
随机测试(Ad-hocTesting)：
恢复测试()：
探索性测试(ExploratoryTesing)：是一种测试思维技术（方式）。他强调的是测试人员的主观能动性，抛弃繁杂的测试计划和测试用例设计过程，强调在碰到问题时及时改变测试策略。
返测：针对程序员修改的错误进行测试，验证错误是否被修正。
1.单元测试
单元测试的模块
2.集成测试
3.系统测试
1.基本路径测试
2.边界值分析
3.逻辑覆盖率测试（分支测试、路径测试）
4.循环测试
5.数据流分析技术测试
6.程序插桩测试
7.变异测试
8.控制流分析技术测试
9.信息流分析技术测试
依据：详细设计说明书及其代码构架。
优点：1.迫使测试人员去仔细的思考软件的实现；2.可以检测代码中的每条分支和路径；3.揭示隐藏在代码中的错误；4.对代码的测试比较彻底；5.实现代码最优化。
缺点：1.价格昂贵；2.无法检测代码中遗漏的路径和数据敏感性错误；3.不验证规格的正确性。
1.逻辑覆盖
语句覆盖->判定覆盖->判定/条件覆盖->条件组合覆盖->路径覆盖\_条件覆盖/关系：
2.基本路径测试
3.基于数据流的测试
1.基于用于需求的测试
2.功能图分析方法
3.等价类划分方法
4.边界值分析方法
5.错误推测方法
6.因果图方法
6.判定表驱动分析方法
7.正交试验设计方法
依据：用户需求规格说明书和详细设计说明书
1.常见的边界值
2.决策表
适合于问题有多个条件，条件有多种组合执行不同操作
规则：条件的任意组合，判定表中的一列（贯穿条件项和动作项）。判定表有多少列就代表有多少条规则。
规则的化简：有的规则相互包含，可以化简
3.因果图
找出所有的原因，找出结果，可能还有中间结果的产生，在画因果图时注意。
从输入考虑
I：连虚线出去，如连到ab，表示ab中至少有一个必须成立
E：连虚线出去，如连到ab，表示ab不能同时成立
R：如处于a指向b的虚线三角箭头上，表示a出现时b也必须出现，不可能一个出现一个不出现
从输出考虑
M：如处于a指向b的虚线三角箭头上，表示a为1时b必须为0，a为0时b值不定
连线：恒等
～：非
∨：或
∧：且
ci：原因
ei：结果
画出因果图后，根据图得到决策表从而得到相应的测试数据：原因节点+中间节点为条件桩，结果结点为动作桩。
软件=文档+程序+数据
文档：是与开发、维护和使用有关的图文资料。
程序：是按实现设计的功能和性能要求执行的指令序列。
window、Linux、DOS系统、ios系统等。
王者荣耀、wechat、淘宝、图书馆管理系统等。
1.未实现产品说明书要求功能
2.出现说明书中指明不应出现的错误
3.实现了说明书中未提及的功能（画蛇添足）
4.未实现产品说明书未提及，但是应实现的功能
5.难以理解，不易使用，运行缓慢
测试BUG等级划分标准
1.Blocker（崩溃）【Fatal致命的】：阻碍开发或测试工作的问题；造成系统崩溃、死机、非法退出、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、系统关键性能不达标，数据通信错误或接口不通等
2.Critical（严重）：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误、服务程序频繁需要重启(每天2次或以上)、周边接口出现故障(需考虑接口时效/数量等综合情况)等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。
4.Minor（次要）：界面、菜单布局错误或不合理、焦点控制不合理、性能缺陷，光标,滚动条定位错误，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）
BUG状态标准
待处理（new）：测试人员或用户发现新问题后提交的状态
已确认（open）：经测试人员及研发人员讨论后确认是BUG，提交的状态，由测试人员来设置。
已处理（fixed）：经研发人员确认是BUG后修复的状态，修改还没有验证，由开发人员来设置。
已修改（closed）：测试人员认为问题已经修改，通过验证，由测试人员设置。
仍存在（reopened）：测试人员认为BUG未修复成功，问题仍然存在，由测试人员设置。
不是问题（reject）：研发人员确认不是BUG，或者建议与意见决定不采纳。
暂不处理（hold）：当前版本不做修改，后续版本再考虑，由研发人员或测试人员设置。
（1）激活状态(Active或Open)。
（2）已修正状态(Fixed或Resolved)。
（3）关闭或非激活状态(Close或Inactive)。
正确评估和区分软件缺陷的严重性和优先级。
严重性：
A类：Blocker（崩溃）【Fatal致命的】
B类：Critical（严重）
C类：Major（一般）
D类：Minor（次要）
E类：Negligible（可忽略的）
优先级：
P1类：立即解决
P2类：高优先级
P3类：正常排队
P4类：低优先级
优先级确定方法：
1.二八原则
2.ABC原则
3.四象限原则（轻重缓急）
软件缺陷类型：
1.功能缺陷
2.系统缺陷
3.加工缺陷
4.数据缺陷
5.代码缺陷
为了发现程序中的错误而执行程序的过程，即对软件（程序）的漏洞进行检查发现，衡量软件质量，并对其能否满足规定的需求或弄清预期结果和实际结果的差别。
程序、数据、文档
缺陷具有放大的特点，随着阶段的推进发现bug的成本会指数型上升，所以并不是代码级的测试才叫测试，而是开发过程各个阶段越早开始测试越好。
1.瀑布模型：1.需求分析->2.设计（概要、详细）->3.编程->4.测试（单元、集成、系统）->5.维护
2.V模型（瀑布-改）：1.需求分析--2.概要设计--3.详细设计--4.软件编码--5.单元测试--6.集成测试--7.系统测试--8.验收测试
3.W模型：1.需求分析--需求测试--2.概要设计--功能测试--3.详细设计--设计测试--4.软件编码--5.单元测试--6.集成测试--7.系统测试--确认测试--8.验收测试
4.H模型：无实际意义，仅说明可以独立测试。
2.8-2原则：
3.软件缺陷的寄生虫性：找到的缺陷越多说明软件遗留的缺陷越多
4.避免自己测试自己的程序
5.回归测试：避免引入新的错误。
1.系统管理或是运维人员
2.开发人员
3.测试人员
5.用户对象
属于需求分析和软件设计错误的约占64%，属于程序编写错误的仅占36%。
V模型：又叫RAD模型（RapApplicationDevelopmentModel，快速应用开发模型），构型类似V。其开发阶段为：1.需求分析--2.概要设计--3.详细设计--4.软件编码--5.单元测试--6.集成测试--7.系统测试--8.验收测试
1.解放程序员和售后服务人员
2.软件测试可以降低软件质量风险，使程序员能够更专心于解决程序的算法和效率；同时经过严格检验的完整产品也减轻了售后服务人员的工作量。
PC、手机、平板、嵌入式设备等
1.本地网络
2.云平台网络
3.本地和云的混合网络
4.WiFi网络
1.开发环境（开发人员）
2.测试环境（测试人员）
3.生产环境（又叫正式环境，是指客户使用的环境）
1.为了发现程序员在开发中存在的代码以及逻辑错误。
2.为了审核产品的完成是符合用户的需求的。
3.为了提高客户的体验。
4.为了交付更高质量的产品。
测试报告
测试数据包括业务测试数据、基础数据（配置数据等）
1.测试基础数据可备份和还原
2.测试数据的原子化，可高度复用
3.测试数据的可定制
4.测试数据的可自动化维护（包括但不限于配置、业务测试数据等等）
1.高效的规划好可用的资源（团队资源利用率）
2.混合环境的管理（云技术、云+私有服务）
3.复杂环境管理（业务、服务、部署、跨团队协作等）
4.复杂的配置（基础环境更多和技术应用更广）
1.在初始化测试环境前，应当全面的检测环境的连通性
2.检查所有的硬件、软件、需求、配置等，并形成checklist
3.确定所有测试设备、浏览器等版本信息，并形成checklist
4.严格规划测试环境的使用计划，例如准入准出原则，什么适合更新，什么时候发布，什么节点清理等等
5.尽可能的自动化进行管理维护
需求分析
制定测试计划
设计测试用例与编写（一个好的高质量的测试用例在于能发现至今未发现的错误，一个成功的测试是发现了至今未发现的错误的测试）
实施测试
提交缺陷报告
生成测试总结和报告
web前端包括：JavaScript、ActionScript、CSS、HTML、Flash、交互式设计、视觉设计等。
bug定位通用思路：现象-->原因-->验证字段-->结论-->现象。
bug定位归因
1.测试环境方面
2.浏览器方面
3.网络方面
4.字符编码方面
安全方面
性能方面
bug定位常用工具：
IE插件--HTTPwatch
第三方工具---fiddler
慢速网模拟工具---firefoxthrottle.
后端包含运行在服务器上的程序、脚本和服务。例：各种罗及处理系统、数据存储系统等。
后端可能发现的问题--逻辑、数据、策略、接口、性能等。
测试bug定位归因
1.数据流方面
2.处理逻辑方面
3.系统和环境方面
4.程序和代码方面
gdb工具：UNIX及UNIX-like下的调试工具，像VC、BCB等IDE的调试。
日志查看命令
gdb常用命令
性能测试
bug定位归因：
1.压力工具方面
2.被测试系统方面
3.环境方面
正确的思路+丰富的业务知识+丰富的技术背景知识+较好的调试和开发能力=强大的bug定位能力。
功能测试
1.链接测试：链接测试必须在集成测试阶段完成
2.表单测试：提交信息
cookies创建对象类型：JavaScript、VBScript等HTLM页面中的客户端脚本，使用MSwin32Internet函数（Internetsetcookie和Internetgetcookie）的win32程序、JSP/ASP等页面中的服务器端脚本。
禁用Cookie：1.可能会导致某些web系统无法正常运行2.使用户无法进行匿名访问3.使web系统无法跟踪用户的浏览习惯。
持久Cookie和会话Cookie：会话cookie是Cookie存储在内存中，持久cookie是cookie储存在硬盘中，被写入用户配置文件夹下的cookie文件夹，浏览器临时文件索引会使用指向cookie文件的指针进行更新。
cookie测试：
d.持久cookie测试的设置测试：在浏览器中对cookie是否禁用或者cookie的使用级别进行测试。如在IE浏览器的“选项”功能中，“安全”选项卡和“隐私”选项卡就可以对cookie进行设置。
4.设计语言测试：版本的差异可以引起客户端或服务器端严重的问题。除了HTML的版本问题外，不同的脚本语言，例如Java、JavaScript、ActiveX、VBScript或Perl等也要进行验证。
5.数据库测试：数据库为Web提供空间，在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。两大错误类型：数据一致性错误和数据输出错误。
数据一致性错误：主要是由于用户提交的表单信息不正确而造成的
输出错误：主要是由于网络速度或程序设计问题等引起的。
性能测试（测试工具：LoadRunner）
2.负载测试：测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。
3.压力测试：压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。压力测试的区域包括表单、登陆和其他信息传输页面等
4.网页性能Firefox插件：Yslow，Findbug，PageSpeed
5.Dynatrace检查网页性能（性能分析工具）
6.LoadRunner性能测试工具原理：录制+回放模拟用户实际操作场景，监控并分析运行结果。
可用性测试
1.导航测试：Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保简洁明了。
4.整体界面测试：指整个Web应用系统的页面结构设计，是给用户的一个整体感。方式：调查问卷形式。
兼容性测试
1.平台兼容性测试：操作系统类型Windows、Unix、Macintosh、Linux等，与用户系统的配置有关。
2.浏览器测试：浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java、JavaScript、ActiveX、plug-ins或不同的HTML规格有不同的支持。包括浏览器类型及版本测试。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。方式：创建兼容性矩阵。
ActiveX是Microsoft的产品，是为InternetExplorer而设计的；JavaScript是Netscape的产品；Java是Sun的产品安全性测试
1.测试区域：Web应用系统基本采用先注册，后登陆的方式。测试重点内容：必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。
3.保证Web应用系统的安全性，保留日志文件。实现测试信息记录及可追踪性。
4.当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。
自动化测试
主要方式：录制+回放+脚本。
常用的自动化测试工具：
功能测试工具：QTP
性能测试工具：LoadRunner
(1)、驱动模块（driver）：相当于所测模块的主程序。它接收测试数据，把这些数据传送给所测模块，最后再输出实际测试结果；
(2)、桩模块（stub）:用于代替所测模块调用的子模块。桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不容许什么事情也不做。
打桩：一般在做单元或集成测试时，如果某个程序单元的某条语句，需要调用的一个外部函数还没有设计、编码、调试完成的话，可以只让它简单地返回几个支持测试用例的值就可以了，这种状态的外部函数一般就叫做“打桩”。