软件测试类型（共19种）
1.按照测试类型划分：
功能测试(Function Testing)：测试软件的功能是否符合功能需求，通常采用黑盒测试方式。一般由独立测试人员
执行。
性能测试(Performance Testing)：测试软件在各种情况下的性能，如在正常情况下或者最大负载下的状况。包括内存测试、CPU测试、响应时间测试、唤醒率测试、强度测试、容量测试、基准测试等。
安全测试(Security Testing )：测试该系统防止非法侵入的能力。在IT软件产品的生命周期中，特别是产品开发基本完成到发布阶段，对产品进行检验以验证产品是否符合安全需求定义和产品质量标准的过程。（比如登录，注册功能等）
易用性测试：测试软件是否易用，主观性比较强。一般要根据很多用户的测试反馈信息，才能评价易用性。
兼容性测试：测试该系统与其他软件或者系统平台（软件/硬件）的兼容性。包括自身兼容性（历史版本数据，功能兼容）、平台兼容性（window平台、Linux平台等的兼容）、设备兼容性（Android产品，iOS产品等的兼容）、与其他软件兼容性等。
部署测试：也叫安装测试，确保该软件在正常或异常情况下都能进行安装（进行首次安装、升级、完整的或自定义的安装--正常情况；磁盘空间不足，缺少目录创建权限，安装过程中关机重启--异常情况）（部署方式：分布式部署，集中部署等）
文档测试：检验样品用户文档的完整性，正确性，一致性，易理解性，易浏览性。包括用户手册，配置手册、安装手册，使用说明，用户帮助文档等。
本地化测试：不同区域不同版本的测试（中文版本测试，英文版本测试等）
无障碍测试：针对特定的用户群体，比如老年人，残疾人等类型的用户
竞品测试：同类产品在功能、性能等方面的对比测试。
2.按是否查看程序内部结构分类
黑盒测试（Black-Box Testing）：又称数据驱动测试，从用户角度出发，把测试对象比作黑盒，关注程序外部结构，不关注内部逻辑，针对输入对应的输出是否正确进行测试（是对功能的测试）。即针对软件界面和软件功能进行测试，以此来确认软件的功能和界面是否正确或遗漏，数据库访问是否正常，会出现性能错误，初始化错误和程序终止错误等bug。
灰盒测试(Gray-Box Testing)： 是一种综合测试方法，他将黑盒测试和白盒测试相结合，基于程序运行时的外部表现又结合内部逻辑结构来设计用例，执行程序并采集路径执行信息和外部用户接口结果的测试技术。
白盒测试(White-Box Testing)：结构测试或逻辑驱动测试，是一种按照程序内部逻辑结构和编码结构，设计测试数据并完成测试的一种测试方法。
3.按是否运行程序分类
静态测试(Static Testing)：指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行找错。技术应用包括控制流分析技术、数据流分析技术、信息流分析技术等。
软件质量的衡量方面：功能性（Functionality）、可靠性(Reliability)、可用性(Usability)、有效性(Efficiency)、可维护性(Maintainability)、可移植性(Portablity)
动态测试(Dynamic Testing)：是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等性能指标。组成部分：构造测试用例、执行程序 、分析程序的输出结果。技术应用包括逻辑覆盖率测试技术（分支测试技术、路径测试技术等），程序插装等。
4.按阶段测试分类
单元测试(Unit Testing)：又称模块测试，是针对软件设计的最小单位----程序模块或功能模块，进行正确性检验的测试工作。其目的在于检验程序各模块是否存在各种差错，是否能正确地实现了其功能，满足其性能和接口要求。常用方法：白盒测试。
测试阶段：编码后
测试对象：最小模块
测试人员：白盒测试工程师或开发工程师
测试依据：代码和注释+详细设计文档
测试方法：白盒测试
测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试
集成测试(Integration Testing)：又叫组装测试或联合，是单元测试的多级扩展，是在单元测试的基础上进行的一种有序测试。旨在检验软件单元之间的接口关系，以期望通过测试发现各软件单元接口之间存在的问题，最终把经过测试的单元组成符合设计要求的软件。常用测试方法：灰盒测试。
测试阶段：一般单元测试执行之后进行
测试对象：模块间的接口
测试人员：白盒测试工程师或开发工程师
测试依据：单元测试的模块+概要设计文档
测试方法：灰盒测试（黑盒测试和白盒测试相结合）
测试内容：模块之间的数据传输、模块之间的功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响。
确认测试：又称有效性测试。任务是验证软件的功能和性能及其它特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明书中已经明确规定。它包含的信息就是软件确认测试的基础。
系统测试(System Testing)：是为判断系统是否符合要求而对集成的软、硬件系统进行的测试活动、它是将已经集成好的软件系统，作为基于整个计算机系统的一个元素，与计算机硬件、外设、某些支持软件、人员、数据等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。
测试阶段：集成测试通过之后
测试对象：整个系统（软硬件）
测试人员：黑盒测试工程师
测试依据：需求规格说明书
测试方法：黑盒测试
测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等。
验收测试(Acceptance Testing)：以用户为主的测试，软件开发人员和质量保证人员参加，由用户设计测试用例。不是对系统进行全覆盖测试，而是对核心业务流程进行测试。
测试阶段：系统测试通过之后
测试对象：整个系统（软硬件）
测试人员：最终用户或需求方
测试依据：用户需求，验收标准
测试方法：黑盒测试
测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性，程序设计文档及说明书等。
alpha测试：用户在开发环境下（模拟实操环境）进行测试，受开发方控制，用户数量相对较少，时间比较 集中。目的是：评价软件产品的FLURPS（即功能、局域化、可使用性、可靠性、性能和支持） 测试时间：软件正式发布前。测试对象：不能有程序员或测试员完成。
beta测试：用户公司组织各方面的典型终端用户在生产环境下进行，是一种验收测试。用户不受开发方控制，可以自由地测试，用户数量相对较多，时间不集中。测试时间：alpha测试过后特点：测试规模大，测试周期长。
5.黑盒测试分类
功能测试：菜单、工具栏、快捷键、下拉框、按钮、单选按钮、复选按钮、切换、链接（集成测试阶段）、触发键
1.逻辑功能测试：
2.UI界面测试：登录界面、总界面、输入/出界面（增删改查）、处理界面、输出界面、报表界面、提示界面
3.易用性测试：
4.兼容性测试：
5.接口测试：也叫业务流程测试（包括功能模块之间、模块与模块之间、子系统之间），分为内部接口（即函数调用[导入导出]）和外部接口两部分。服务器接口、外部接口、错误处理。接口测试工具：charles，postman,jmeter等。
注：
服务端一般会提供JSON格式的数据给客户端，所以我们在服务端需要进行接口测试，确保服务端提供的接口并转换的JSON内容正确，对分支、异常流有相应的返回值。此块测试可以采用itest框架进行测试。最方便的是采用httpclient进行接口测试。进行服务端测试时，需要开发提供一份接口文档。
6.容错测试：数据长度、数据类型、非法操作等
性能（时间-、空间）测试：TPS吞吐量、响应速度、CPU占用率、内存占用率等
名词解释：
平均吞吐量：单位时间内处理事务的个数
平均响应速度：做一个事务处理所用时间
时间性能：软件的一个具体事务的响应时间
空间性能：软件运行时所消耗的系统资源
测试项目：
1.可靠性测试：硬件方面（材料等），如高低温测试，防水防尘测试等。
2.稳定性测试：稍大于业务量的一个负载，对系统进行的一个持续的长时间的测试，比如24*5，连续5天施加压力，确定系统能在较长时间运行下的系统稳定性的情况；1小时触发600条信息，那么8个、10个等发信息的条数测试。
3.负载测试：确认系统正常指标下的最大负载。步骤：在测试过程中，逐步增加负载，并记录被测系统响应的性能表现，最终确认出系统的最大负载。
4.压力测试：确认系统所能承受的最大极限。是指在极限压力情况下，系统崩溃的极限条件测试。大用户测试（针对B/S而言）
5.容量测试：大数据量测试。
6.强度测试：系统续航量测试
7.安全性测试：
8.恢复测试：突然断电（系统触发正常启动；数据包要在断电的地方继续进行处理）
9.标杆测试：
10.并发测试：指多个用户在同一时间对同一条数据的删除或者修改等处理
11.配置测试：分为最低配置和推荐配置两种。
12.安装测试：安装过程和卸载过程
13.文档测试：交给用户的文档。例如：系统帮助、用户使用手册、用户安装手册
14.可用性测试：靠经验。
15.初始化测试：是指系统刚刚安装完成后，在数据位空的情况下，如果被调用的模块为空，点击调用模块的时候，是否进行容错的测试。
16.数据完整性测试：是指当主表的某一条件信息被删除后，和这一条相关的从表的信息都应该被删除。如果某些数据的主键是由数据库本身而实现的，可以不用删除，如果有些主从表是由程序员写的代码而实现，则要进行数据完整性的测试。
6.是否手工执行
手工测试(Manual Testing)：由人一个一个的输入用例，然后观察结果，和机器测试相对应，属于比较原始但是必须的一个步骤。
优点：自动化无法替代探索性测试、发散思维类无既定结果的测试。
缺点:执行效率慢，量大易错。
自动化测试(Automation Testing)：在预设条件下运行系统或应用程序，评估运算结果，预先条件应包括正常条件和异常条件。即模仿人的动作和行为。一般常用的自动化测试如功能测试自动化（默认）、性能测试自动化、安全测试自动化等
7.其他测试类型
回归测试(Regresson Testing )：对软件版本的新版本进行测试时，重复执行上一个版本测试时的用例。在发生修改后重新测试新版本的软件以保证修改的正确性，以及修改后没有引发新的错误。回归测试是开发人员修改已提交的bug后，测试人员进行再一轮的测试，主要是检测bug是否被修复，bug相关功能是否被影响。
冒烟测试(Smoke Testing)：对一个系统进行大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。冒烟测试又称为版本验证测试，他的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件的基本功能正常，可以进行后续的正式测试工作。冒烟测试是在开发人员交付软件时进行的大体预测，主要是针对整体流程和主体功能进行测试。
随机测试(Ad-hoc Testing)：
恢复测试()：
探索性测试(Exploratory Tesing)：是一种测试思维技术（方式）。他强调的是测试人员的主观能动性，抛弃繁杂的测试计划和测试用例设计过程，强调在碰到问题时及时改变测试策略。
返测：针对程序员修改的错误进行测试，验证错误是否被修正。
注：
1.单元测试
-
模块接口的测试
-
局部数据结构的测试
-
独立路径测试
-
错误处理测试
-
边界测试
单元测试的模块
-
被测模块：被测试的程序的模块
-
驱动模块：用来模拟测试模块的上一级模块，相当于被测模块的主程序
-
桩模块：用来模拟被测模块工作过程中所调用的模块
-
单元测试的工具：Junit相关的概念：以插入断言的方式进行测试（类似黑盒测试）
-
针对被测代码或者被测的功能点先创建测试类，然后在类里面创建一个个测试方法。通过实例化对象调用被测方法，用断言进行实际值预期值比较。
-
单元测试的方法：以白盒测试法为主（覆盖），先静态检查代码是否符合规范，再动态运行代码，检查结果。除了需要验证结果是否正确，还需要检查程序的容错能力、边界值处理等问题。
2.集成测试
-
一次性的集成big-bang：把所有通过了单元测试的模块按设计要求一次全部组装起来，然后进行整体测试。时间随变短了但急于求成。
-
渐进地集成
-
自上而下：从主程序模块开始按深度或广度优先策略边组装边测试
-
自下而上：从最底层模块开始组装和集成测试
-
汉堡包：两者进行结合，树状图每层画线，顶层采用自顶向下，底层采用自底向上
-
相邻的集成：上下三层进行集成
-
成对集成：先成对再相邻
-
基于MM路径的集成：MM路径不是可执行路径，描述单元之间的控制转移。
-
最终得到调用图，然后就会到基本路径测试，找复杂度，找路径，得到测试用例的套路
-
3.系统测试
-
方法：黑盒测试
-
内容：易用性、国际化本地化、性能、功能、界面、兼容性、安全性、文档、安装
白盒测试用例设计方法
1.基本路径测试
2.边界值分析
3.逻辑覆盖率测试（分支测试、路径测试）
4.循环测试
5.数据流分析技术测试
6.程序插桩测试
7.变异测试
8.控制流分析技术测试
9.信息流分析技术测试
依据：详细设计说明书及其代码构架。
优点：1.迫使测试人员去仔细的思考软件的实现；2.可以检测代码中的每条分支和路径；3.揭示隐藏在代码中的错误；4.对代码的测试比较彻底；5.实现代码最优化。
缺点：1.价格昂贵；2.无法检测代码中遗漏的路径和数据敏感性错误；3.不验证规格的正确性。
注：
1.逻辑覆盖
语句覆盖->判定覆盖->判定/条件覆盖->条件组合覆盖->路径覆盖 \_条件覆盖/
-
语句覆盖：每条语句执行一次
-
判定覆盖：每个判定分支至少执行一次
-
条件覆盖：每个判定条件应取到各种可能的值
-
判定/条件覆盖：同时满足判定和条件
-
条件组合覆盖：每个判定条件的每一种组合各出现一次
-
路径覆盖：每一条可能的路径至少执行一次
关系：
-
条件组合覆盖＞判定覆盖＞语句覆盖(即如果达到条件组合覆盖，就达到判定覆盖和语句覆盖：如果达到判定覆盖，就达到语句覆盖，下面类似理解)。
-
条件组合覆盖＞条件覆盖。
-
条件覆盖不一定包含判定覆盖、语句覆盖。
-
判定覆盖不一定包含条件覆盖。
-
路径覆盖，判定覆盖＞语句覆盖。
2.基本路径测试
-
基于程序圈复杂度产生的测试方法，画出控制流程图，算圈复杂度，找到独立路径并压缩为基本路径集合，根据集合中每条路径设计用例。把复合逻辑表达式拆成单个表达式
-
圈复杂度用于计算程序的基本的独立路径数目（每条新的独立路径都必须包含一条新的有向边，从入口到出口互不相同的路径数）
-
圈复杂的V(G) = e - n + 2p【边-节点+2*连接区域数，连接区域p通常为1】=P+1【判定节点数+1】
-
一般来说，一个单元模块的最大复杂度V(G)<10
-
如果把覆盖的路径数压缩到一定限度内，例如程序中的循环体只执行0次和1次，就成为基本路径测试，通过导出基本路径集合，从而设计测试用例，保证这些路径至少通过一次
3.基于数据流的测试
-
基于真的数据定义到数据的使用来进行测试，需要找到定义的节点（包括赋值的和比较的）和使用的节点。
-
定义节点DEF：输入语句、赋值语句、循环语句和过程调用；变量的值会发生变化的语句
-
使用节点USE：数出语句、赋值语句、条件语句、循环控制语句、过程调用
-
需要找到所有这段功能代码从哪里开始定义，到哪里开始执行，把路径找出来。什么是定义使用路径（某一变量在最初节点定义到最终节点被使用）、定义清除路径（某一个变量从它的定义节点到使用节点这个过程中没有对这个变量进行二次定义）
4.循环测试
-
前提是程序是结构化的。
-
简单循环测试
-
0次通过循环
-
1次通过循环
-
2次通过循环
-
m次通过循环（m<=循环最大次数）
-
m-1，m，m+1次通过循环
黑盒测试用例设计方法
1.基于用于需求的测试
2.功能图分析方法
3.等价类划分方法
4.边界值分析方法
5.错误推测方法
6.因果图方法
6.判定表驱动分析方法
7.正交试验设计方法
依据：用户需求规格说明书和详细设计说明书
注：
1.常见的边界值
-
16bit整数32767～-32768
-
报表第一行和最后一行
-
屏幕光标最左上和最右下
-
数组的第一个和最后一个
-
循环的第0、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、淘宝、图书馆管理系统等。
软件缺陷（Enhancemental--Bug）
1.未实现产品说明书要求功能
2.出现说明书中指明不应出现的错误
3.实现了说明书中未提及的功能（画蛇添足）
4.未实现产品说明书未提及，但是应实现的功能
5.难以理解，不易使用，运行缓慢
软件BUG等级划分标准
测试BUG等级划分标准
1.Blocker（崩溃）【Fatal致命的】：阻碍开发或测试工作的问题；造成系统崩溃、死机、非法退出、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、系统关键性能不达标，数据通信错误或接口不通等
2.Critical（严重）：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误、服务程序频繁需要重启(每天2次或以上)、周边接口出现故障(需考虑接口时效/数量等综合情况)等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。
3.Major（一般）：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多、 数据来源不正确;、无数据有效性检查或检查不合理等(该问题实际测试中存在最多，合理安排解决BUG，解决率关系版本的优化程度)
4.Minor（次要）：界面、菜单布局错误或不合理、焦点控制不合理、性能缺陷，光标,滚动条定位错误，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）
5.Negligible（辅助性缺陷）： 建议优化类、缺少产品使用、帮助文档、系统安装或配置方面需要信息、长时间操作未给用户进度提示、显示格式不规范、长时间操作未给用户进度提示等
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模型：无实际意义，仅说明可以独立测试。
软件测试原则
1.测试来源于需求原则
2. 8-2原则：
-
测试中发现的错误80%很可能起源于程序中的20%
-
提前测试可发现80%，系统测试找出剩余bug的80%（总体的16%），最后的4%可能只有用户大范围长时间使用后才暴露出来
-
80%的工程用在20%的需求上（即关键需求）
3.软件缺陷的寄生虫性：找到的缺陷越多说明软件遗留的缺陷越多
4.避免自己测试自己的程序
5.回归测试：避免引入新的错误。
软件测试注意事项
-
测试不是开发后期的一个阶段
-
测试入门其实稍容易，但要求技术一样高
-
测试多数情况下不能覆盖所有输入
-
不要“有时间多测，没时间少测”
-
软件测试不止是测试人员的事，也是开发人员的事
-
调试和测试不一样
-
测试绝非只运行一下软件看结果对不对
-
L10N：本地化测试
-
I18N：国际化测试
交互对象
1.系统管理或是运维人员
2.开发人员
3.测试人员
4.其他对测试环境或相关技术有影响的人员
5.用户对象
常见软件测试错误情况占比
属于需求分析和软件设计错误的约占64%，属于程序编写错误的仅占36%。
软件快速应用开发模型
V模型：又叫RAD模型（Rap Application Development Model，快速应用开发模型），构型类似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程序bug分析定位技巧
web前端包括：JavaScript、ActionScript、CSS、HTML、Flash、交互式设计、视觉设计等。
bug定位通用思路：现象-->原因-->验证字段-->结论-->现象。
bug定位归因
1.测试环境方面
-
是否安装了flash及flash的版本--可能导致部分页面显示出问题，目前常用的版本为flash10
-
是否开启了浏览器插件--插件可能导致浏览器行为的变化，除非测试要求，否则一律禁用插件。
-
是否开启了安全软件--可能会截包、弹窗拦截、防钓鱼等。
2.浏览器方面
-
不同浏览器的支持标准--不同内核的浏览器对js及各种标准的支持不同，因此页面解析出来的效果可能不同。如【IE：trident】、【Firefox：gecko】、【Chrome：webkit】、【Safari：webkit】。
-
浏览器的设置--禁用js；禁用弹窗；禁用cookie等。
-
浏览器cache策略---js,css,图片 等都有可能被cache住。CTRL+F5：强制刷新请求。
-
cookie问题----跨域，过期等。
3.网络方面
-
是否发出了正确的请求--请求url、参数变量。content数据。
-
是否得到了正确的应答---HTTP的返回值：200-正确；302--对象已移动；404--没找到页面。返回数据体。
-
是否性能问题--异步请求的数量过多；网速过慢。
4.字符编码方面
-
页面乱码--百度后端存储基本上使用的是GBK编码，前端提交可能是UTF-8编码，后端对非GBK编码一般采取实体储存。可能出现编码没有转换。转换的时候没有判断半个汉字（转掉了半个汉字导致崩溃）
-
url错误---URL路径中汉字编码使用的shi是UTF-8编码，参数中使用系统默认编码，flash脚本中使用的都是UTF-8编码。
安全方面
-
Xss漏洞--输入一些特定的字符页面出现错乱或有恶意代码被执行，RD未对特殊字符转义完整。
性能方面
-
图片数量---页面中同一个域的图片的数量控制在16个以下，IE会控制同一个域图片并行的下载数量。
-
页面抖动--异步请求的数量过多
-
加载失败--限速情况下，超时。
bug定位常用工具：
Firfox--firebug、web developer、live http headers、http fox ;
IE插件--HTTPwatch
第三方工具---fiddler
慢速网模拟工具---firefox throttle.
Web后端bug分析
后端包含运行在服务器上的程序、脚本和服务。例：各种罗及处理系统、数据存储系统等。
后端可能发现的问题--逻辑、数据、策略、接口、性能等。
测试bug定位归因
1.数据流方面
-
上下游模块是否正常连接---模块的ip和端口的配置，白/黑名单配置，session授权等。
-
模块的数据发送接收是否正常--日志是否有滚动，是否显示发送了数据或接收到数据，数据是否完整，跨机房，负载均衡算法（从哪些机器上获取数据）。
-
非socket的数据传输--共享内存（是否分配，key的配置等），cache（是否创建、脏数据等），数据库（配置，连接，表，触发器，存储过程）、文件（大小、访问权限）
-
模块之间的接口--协议的一致性（mcpack1,mcpack2等），字段的一致性（一个按signed解析，一个按unsigned解析），字段复用等。
2.处理逻辑方面
-
程序的各种配置--功能是否kai开启/关闭，词表是否加载，各种阈值的配置，超时配置等。
-
程序日志--日志级别，交互的流程，处理的流程等。
-
各种边界--数据边界（int，long），文件边界（空文件，分文件的边界），时间边界等。
-
各种资源的使用--cache是否遗留脏数据，并发和锁死。
3.系统和环境方面
-
系统资源--CPU、IO、句柄、内存、网络状态、数据库状态，数据库连接数。
-
环境资源---程序版本、内核版本，网络（外网）访问权限，系统动态库不一致等
4.程序和代码方面
-
确认问题出现的位置--日志中的代码行，gdb中的代码行，抛出异常显示的代码行
-
获取当时的运行时信息--Gdb core文件 ，gdb attach到进程，查看堆栈，查看寄存器，设置breakpoint,watchpoint ,查看内部数据。
-
获取程序和系统信息---Strace查看系统调用，系统状态获取（ps,top,/proc/pid/*,vmstat,netstat）
-
更深入的手段--反汇编（IL Spy）、查看寄存器，gdb高级应用
注：
gdb工具： UNIX及UNIX-like下的调试工具， 像VC、BCB等IDE的调试。
后端测试bug定位
日志查看命令
-
查看压力--tail -f as. log | grep '^NOTICE' | awk '{print $3}' |uniq -c
-
排除日志中的特定内容——grep -v 'pattern' as.log
-
只输出感兴趣的内容——grep -o 'proctime:toal:\d+' as.log；grep -o 'proctime:toal:\d+' as.log | grep -o '\d+ '；grep -o 'proctime:toal:\d+' as.log | grep -o '\d+ ' | sort -n | uniq -c
-
将wf日志归类——grep -o '\w+\.(cpp|h):\d+' as.log.wf | sort | uniq -c
gdb常用命令
-
bt——查看堆栈信息
-
print——打印某变量值
-
break——设置断点
-
x/i——翻译当前指令为汇编
-
info thread——查看所有线程，星号*标记的是当前线程
-
thread num——切换到线程号为num的线程
-
set scheduler -locking on——锁定在线程：输入continue命令以后，当前线程继续执行，其它线程不执行
-
set scheduler-locking off——这是默认设置，输入continue命令以后，所有线程都继续执行
性能测试
-
旨在获取系统在特定一种或多种环境下，在不同的外部输入压力(包含极限)的条件下的系统各项指标的测试
-
进程相关——ps，top，/proc/pid/*
-
系统相关——vmstat,top,iostat,sar,df,lsof
-
网络相关——netstat
bug定位归因：
1.压力工具方面
-
工具的功能和性能--能否达到预期压力，启动压力的机械性能，压力工具是否有异常连接关闭，压力工具如何处理异常，长连接短连接，并发个数
-
工具运行环境--压力机器的带宽，是否跨机房。
2.被测试系统方面
-
机器性能--系统所在机器性能，机器网络带宽，机器的内存，SD卡，硬盘等
-
系统本身--系统的下游模块的性能，系统的配置，系统的数据量，系统的特点状态（cache、dump、merge），系统的部署，程序的bug等
3.环境方面
-
操作系统相关---是否和线上一致，内核版本，刷脏叶时间，有没有调用directIO
-
查看系统状态--Ps,top,/proc/pid/*,vmstat,netstat.
注：
正确的思路+丰富的业务知识+丰富的技术背景知识+较好的调试和开发能力 = 强大的bug定位能力。
Web测试流程
功能测试
1.链接测试：链接测试必须在集成测试阶段完成
2.表单测试：提交信息
3.Cookies测试：Cookie是指网站用于辨别身份，进行会话（session）跟踪而存储在客户端的数据。源头：服务器产生并发送给客户端的。用途：提供一个方便的功能以简化用户输入，节省访问页面的时间。
cookies创建对象类型：JavaScript、VBScript等HTLM页面中的客户端脚本，使用MS win32 Internet函数（Internetsetcookie和Internetgetcookie）的win32程序、JSP/ASP等页面中的服务器端脚本。
禁用Cookie：1.可能会导致某些web系统无法正常运行 2.使用户无法进行匿名访问3.使web系统无法跟踪用户的浏览习惯。
第三方Cookie和第一方Cookie：1.第一方cookie是与宿主域名相关联的cookie2.第三方cookie是来自任何其他域名的cookie
持久Cookie和会话Cookie：会话cookie是Cookie存储在内存中，持久cookie是cookie储存在硬盘中，被写入用户配置文件夹下的cookie文件夹，浏览器临时文件索引会使用指向cookie文件的指针进行更新。
cookie测试：
a.会话cookie测试：重新登录时没有上次操作的痕迹。
b.持久cookie测试的常规测试：重新登录时保留上次操作的痕迹。
c.持久cookie测试的更新测试：重新登录前进行其他操作，检查是否仍保留上次操作的痕迹。
d.持久cookie测试的设置测试：在浏览器中对cookie是否禁用或者cookie的使用级别进行测试。如在IE浏览器的“选项”功能中，“安全”选项卡和“隐私”选项卡就可以对cookie进行设置。
4.设计语言测试：版本的差异可以引起客户端或服务器端严重的问题。除了 HTML 的版本问题外，不同的脚本语言，例如 Java 、 JavaScript、 ActiveX 、 VBScript 或 Perl 等也要进行验证。
5.数据库测试：数据库为Web提供空间，在 Web 应用中，最常用的数据库类型是关系型数据库，可以使用 SQL 对信息进行处理。两大错误类型：数据一致性错误和数据输出错误。
数据一致性错误：主要是由于用户提交的表单信息不正确而造成的
输出错误：主要是由于网络速度或程序设计问题等引起的。
性能测试（测试工具：LoadRunner）
1.连接速度测试：用户连接到 Web 应用系统的速度根据上网方式（电话拨号、宽带上网）的变化而变化。另有超时限制等。
2.负载测试：测量 Web 系统在某一负载级别上的性能，以保证 Web 系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问 Web 系统的用户数量，也可以是在线数据处理的数量。
3.压力测试：压力测试是测试系统的限制和故障恢复能力，也就是测试 Web 应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到 Web 应用系统崩溃，接着当系统重新启动时获得存取权。压力测试的区域包括表单、登陆和其他信息传输页面等
4.网页性能Firefox插件：Yslow，Findbug，PageSpeed
5.Dynatrace检查网页性能（性能分析工具）
6.LoadRunner性能测试工具原理：录制+回放模拟用户实际操作场景，监控并分析运行结果。
可用性测试
1.导航测试： Web 应用系统的用户趋向于目的驱动，很快地扫描一个 Web 应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。导航的另一个重要方面是 Web 应用系统的页面结构、导航、菜单、连接的风格是否一致。确保简洁明了。
2.图形测试：一个 Web 应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等，确保图形有明确的用途。作用： 广告宣传、美化页面。格式：一般用JPG或GIF压缩。
3.内容测试：用来检验 Web 应用系统提供信息的正确性、准确性和相关性。（商品价目表、office纠错功能、网页拓展链接功能）
4.整体界面测试：指整个 Web 应用系统的页面结构设计，是给用户的一个整体感。方式：调查问卷形式。
兼容性测试
1.平台兼容性测试：操作系统类型Windows 、 Unix 、 Macintosh 、 Linux等，与用户系统的配置有关。
2.浏览器测试：浏览器是 Web 客户端最核心的构件，来自不同厂商的浏览器对 Java 、 JavaScript 、 ActiveX 、 plug-ins 或不同的 HTML 规格有不同的支持。包括浏览器类型及版本测试。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和 Java 的设置也不一样。方式：创建兼容性矩阵。
ActiveX 是 Microsoft 的产品，是为 Internet Explorer 而设计的；JavaScript 是 Netscape 的产品；Java 是 Sun 的产品
安全性测试
1.测试区域：Web 应用系统基本采用先注册，后登陆的方式。测试重点内容：必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。
2. Web 应用系统是否有超时的限制，即登录超时提醒。
3.保证 Web 应用系统的安全性，保留日志文件。实现测试信息记录及可追踪性。
4.当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。
5.服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。需测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。
自动化测试
主要方式：录制+回放+脚本。
常用的自动化测试工具：
功能测试工具：QTP
性能测试工具：LoadRunner
-
写脚本或者录制脚本
-
使用用户自定义参数
-
场景设计
-
产生虚拟用户的机制：使用控制器，来控制模拟多少用户。
-
使用监听器，查看测试结果
(1)、驱动模块（driver）：相当于所测模块的主程序。它接收测试数据，把这些数据传送给所测模块，最后再输出实际测试结果；
(2)、桩模块（stub）:用于代替所测模块调用的子模块。桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不容许什么事情也不做。
打桩：一般在做单元或集成测试时，如果某个程序单元的某条语句，需要调用的一个外部函数还没有设计、编码、调试完成的话，可以只让它简单地返回几个支持测试用例的值就可以了，这种状态的外部函数一般就叫做“打桩”。
