2023年11月30日发(作者：)
软件测试流程及⽅法详解
软件测试类型（共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)：以⽤户为主的测试，软件开发⼈员和质量保证⼈员参加，由⽤户设计测试⽤例。不是对系统进⾏全覆盖测
试，⽽是对核⼼业务流程进⾏测试。
测试阶段：系统测试通过之后
测试对象：整个系统（软硬件）
测试⼈员：最终⽤户或需求⽅
测试依据：⽤户需求，验收标准
服务端⼀般会提供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相关的概念：以插⼊断⾔的⽅式进⾏测试（类似⿊盒测试）
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等级划分标准
r（崩溃）【Fatal致命的】：阻碍开发或测试⼯作的问题；造成系统崩溃、死机、⾮法退出、死循环，导致数据库数据丢失，与数
据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发⽣死锁、系统关键性能不达标，数据通信错误或接
⼝不通等
al（严重）：系统主要功能部分丧失、数据库保存调⽤错误、⽤户数据丢失，⼀级功能菜单不能使⽤但是不影响其他功能的测试。功
能设计与需求严重不符，模块⽆法启动或调⽤，程序重启、⾃动退出，关联程序间调⽤冲突，安全问题、稳定性等。如：软件中数据保存后
数据库中显⽰错误，⽤户所要求的功能缺失，程序接⼝错误，数值计算统计错误、服务程序频繁需要重启(每天2次或以上)、周边接⼝出现故
障(需考虑接⼝时效/数量等综合情况)等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。
（⼀般）：功能没有完全实现但是不影响使⽤，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错
误、边界条件错误，删除没有确认框、数据库表中字段过多、 数据来源不正确;、⽆数据有效性检查或检查不合理等(该问题实际测试中存在
最多，合理安排解决BUG，解决率关系版本的优化程度)
（次要）：界⾯、菜单布局错误或不合理、焦点控制不合理、性能缺陷，光标,滚动条定位错误，建议类问题，不影响操作功能的执
⾏，可以优化性能的⽅案等。如：错别字、界⾯格式不规范，页⾯显⽰重叠、不该显⽰的要隐藏，描述不清楚，提⽰语丢失，⽂字排列不整
齐，光标位置不正确，⽤户体验感受不好，可以优化性能的⽅案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及
时处理）
ible（辅助性缺陷）： 建议优化类、缺少产品使⽤、帮助⽂档、系统安装或配置⽅⾯需要信息、长时间操作未给⽤户进度提⽰、显
⽰格式不规范、长时间操作未给⽤户进度提⽰等
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.⼆⼋原则
原则
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.本地和云的混合⽹络
⽹络
软件开发环境
1.开发环境（开发⼈员）
2.测试环境（测试⼈员）
3.⽣产环境（⼜叫正式环境，是指客户使⽤的环境）
软件测试的⽬的
1.为了发现程序员在开发中存在的代码以及逻辑错误。
2.为了审核产品的完成是符合⽤户的需求的。
3.为了提⾼客户的体验。
4.为了交付更⾼质量的产品。
测试结果书⾯材料
测试报告
测试数据管理⽅法
测试数据包括业务测试数据、基础数据（配置数据等）
1.测试基础数据可备份和还原
2.测试数据的原⼦化，可⾼度复⽤
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'
只输出感兴趣的内容——grep -o 'proctime:toal:d+' ；grep -o 'proctime:toal:d+' | grep -o 'd+ '；grep -o 'proctime:toal:d+'
| grep -o 'd+ ' | sort -n | uniq -c
将wf⽇志归类——grep -o 'w+.(cpp|h):d+' | 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.表单测试：提交信息
s测试：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
ace检查⽹页性能（性能分析⼯具）
nner性能测试⼯具原理：录制+回放模拟⽤户实际操作场景，监控并分析运⾏结果。
可⽤性测试
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）:⽤于代替所测模块调⽤的⼦模块。桩模块可以做少量的数据操作，不需要把⼦模块所有功能都带进来，但不容许什么
事情也不做。
打桩：⼀般在做单元或集成测试时，如果某个程序单元的某条语句，需要调⽤的⼀个外部函数还没有设计、编码、调试完成的话，可以只让
它简单地返回⼏个⽀持测试⽤例的值就可以了，这种状态的外部函数⼀般就叫做“打桩”。
发布评论