测试面试题（通俗易懂）持续更新ing

1 测试理论

1.1 测试基础

1.1.1 什么是软件测试？

软件就像游戏，开发是造游戏，软件测试是试玩找 Bug，让游戏更好玩。

1.1.2 软件测试的目的？

找毛病保好用：像检查新玩具，找出软件毛病，让它好用不出错。

防问题于未然：提前排查软件问题，免得用的时候掉链子，耽误事儿。

让用户满意：确保软件符合大家期望，用起来舒心，不闹心。

1.1.3 软件测试的目标？

挑刺避雷：挑出软件毛病，让用户避开 “坑”。

质量把关：像质检员查商品，保证软件质量杠杠的。

促成信任：确保软件靠谱，让用户和企业放心。

1.1.4 软件测试的原则？

早测：做饭时早尝咸淡，开发中早测软件，问题早发现。

全测：吃饭要尝遍菜，软件各个功能、场景都得测。

重规：走路要守交规，测试按既定规则来，结果才靠谱。

记痕：雁过留痕，测试发现问题要记录，方便修复。

追根：打破砂锅问到底，找到问题根源，防止反复出现。

客测：自己菜好不好吃，客人尝了才算，软件也得经用户检验。

1.1.5 测试的工作流程？

了解需求：好比接任务，先搞清楚软件要干啥。

制定计划：像旅行规划，安排好测啥、咋测、啥时候测。

设计用例：想各种招儿，琢磨咋把软件 “折腾” 一遍找问题。

执行测试：按想好的招儿，实际操作软件，看有没有问题。

报告问题：发现问题就告诉开发人员，让他们去修。

复查验证：修好后再看看，确认问题真没了。

1.1.6 测试工程师的职责？

测试工程师就像软件 “质检员”：

需求解读：弄懂软件要实现啥，明确 “质检标准”。
计划制定：规划咋测试，啥时候测，像安排质检流程。
用例设计：琢磨各种招，给软件挑刺儿。
执行测试：动手操作软件，使劲儿找毛病。
问题汇报：发现问题及时告诉开发，附上 “病历”。
跟进修复：复查开发改过的地方，确保毛病根治。

1.1.7 软件的分类？

1.1.8 测试的主要方面？

功能：看软件该有的功能，能不能用，准不准。像计算器算得对不对。

性能：瞧瞧软件速度快不快，稳不稳。比如网购抢单卡不卡。

兼容性：试试软件在不同设备、系统上，能不能正常跑。好比 APP 在不同手机上都能用。

1.1.9 软件测试的对象？

软件测试对象，不只是能用的软件，还包括：

需求文档：好比建房图纸，得先查它合不合理。
设计文档：看房子咋布局，有没有漏洞。
代码：这是房子的 “砖头瓦块”，得检查质量。
软件本身：房子盖好，看看能不能正常住人。

1.1.10 什么是“测试案例”？

测试案例就像软件的 “找茬攻略” ，写明用啥数据、咋操作软件，以此找出软件毛病。比如网购下单，攻略会写选啥商品、填啥地址，看下单能否成功。

1.1.11 怎么编写测试案例？

编写测试案例，就三步：

明确目标：搞清楚要测软件哪部分，像确定检查手机 APP 的登录功能。
设计场景：想各种使用情况，比如输对、输错密码，模拟正常与异常登录。
写清步骤：按操作顺序写好，先打开 APP，再点登录框，输信息，最后点登录按钮，写明期望结果。

1.1.12 软件测试的两种方法？

软件测试主要有两种方法：

黑盒测试：不看软件内部构造，像蒙眼玩玩具，只从外面操作，看功能对不对。
白盒测试：好比拆开玩具研究内部结构，针对代码逻辑来测试。

1.1.13 测试结束的标准是什么？

以下从三个常见角度，用简短话语解释测试结束标准：

指标达标：好比考试，缺陷数、严重程度等指标，达到预定标准就能结束。
计划完成：按测试计划，该测的功能、场景都测完，就可以停。
风险可控：软件问题带来的风险，在大家能接受的范围内，就能收工。

1.1.14 软件的生命周期？

软件就像人，有自己的一生：

出生（计划与需求分析）：决定软件要做啥。
成长（设计与开发）：搭建架构、编写代码。
体检（测试）：查找问题并修复。
工作（部署与维护）：投入使用，不断优化。
退休（退役）：不再满足需求，被淘汰。

1.1.15 软件测试按过程分为三个步骤？

单元测试：把软件拆成小块，就像检查乐高零件，单个测试每个小功能，看零件好不好用。

集成测试：把测好的小块拼一起，像组装乐高部件，看看拼起来能不能协同工作。

系统测试：完整软件像组装好的乐高成品，放真实环境里测试，看整体功能、性能等合不合格。

1.1.16 面向对象的设计如何影响测试？

面向对象设计好比搭积木，不同积木块是对象。对测试影响有：

单元测试易开展：每个积木块（对象）独立，方便单独测试，像检查单个积木是否完整。
集成测试有挑战：积木组合复杂，测试组合效果难，好比多种积木拼一起，检查整体结构稳不稳。
测试重点明确：对象有封装性，关注接口测试，类似只看积木连接口是否匹配。
可复用性影响：积木能重复用，测试复用部分要确保新场景也适用，像同块积木换个地方搭，检查是否还好

1.1.17 软件带来错误的原因很多。主要的原因有哪些？

软件出错，主要三原因：

需求不清：好比建房图纸乱画，开发不知咋做，功能易出错。
设计缺陷：房子布局没规划好，软件架构差，运行常出乱子。
代码失误：工人砌墙歪歪扭扭，代码写得有漏洞，问题自然来。

1.1.18 做好软件测试的一些关键点？

做好软件测试，抓住这几点：

早参与：开发刚起步就介入，像建房从打地基就盯着，早发现问题。
全覆盖：功能、性能、兼容等，里里外外都测到，不留死角。
重细节：数据边界、异常情况不放过，细节藏着大问题。
常沟通：和开发、需求方多交流，有疑问及时解决。
用工具：善用自动化测试工具，提升效率和准确性。

1.1.19 软件测试的步骤是什么？

领任务：搞懂软件要实现啥功能，明确测试方向。

做计划：安排测什么、啥时候测、咋测，像制定作战计划。

写用例：设计各种操作场景，思考咋找出软件毛病。

动手测：按写好的场景，实际操作软件找问题。

报问题：发现毛病告诉开发人员，详细说明情况。

再检查：开发修复后，复查确认问题解决。

1.1.20 如何录制测试脚本？

用 Jmeter 录测试脚本，分四步：

搭环境：打开 Jmeter，像准备好工具包。
设代理：在 Jmeter 里设个 “传话筒”（代理服务器），让它能听到软件消息。
开录制：启动录制功能，好比打开录音机。
操作软件：正常使用软件，Jmeter 就会像录音机一样，把操作过程记成脚本。

1.1.21 软件测试的测试方法包括哪些？

软件测试方法主要两类：

黑盒测试：不看内部构造，只像顾客用产品，检查功能、性能、兼容性等，看好不好用。
白盒测试：深入代码内部，像工程师检修，查代码逻辑、结构，确保代码质量。

细分还有：

功能测试：看软件功能齐不齐全、能不能用，像检查电视每个频道能不能正常播放。

回归测试：软件改了后，再测一遍，确认新改动没把老功能搞坏，好比修了水管，看看其他地方水流还正不正常。

负载测试：给软件加点工作任务，看它在正常压力下干活顺不顺，类似看看小货车装正常重量货物能不能平稳跑。

压力测试：使劲给软件加任务，看它极限在哪，会不会崩溃，就像拼命给货车装货，看最多能装多少。

性能测试：瞧瞧软件干活速度快不快、占资源多不多，比如网速快不快，内存占多少，类似看货车跑多快，耗多少油。

可用性测试：站在用户角度，看软件好不好上手，界不界面友好，就像看新家电操作容不容易。

安装 / 卸载测试：检查软件能不能顺利安装到设备上，不用时能不能干净卸载，类似检查新家具能不能顺利组装和拆卸。

安全测试：找找软件有没有安全漏洞，会不会被坏人钻空子，像检查家门有没有安全隐患。

兼容性测试：看看软件在不同系统、设备上能不能正常工作，好比看一把钥匙能不能开不同的锁。

α 测试：在公司内部，开发人员和测试人员一起测试，就像自家先检查新玩具好不好玩。

β 测试：交给部分真实用户去用，收集反馈，类似把新玩具给邻居家孩子玩，听听意见。

1.1.22 怎样估计测试工作量？

评估测试工作量，抓住这几样：

功能数量：功能多，事儿就多。像复杂游戏比简单计算器要测的多。
复杂度：逻辑复杂、交互多，测试更费劲儿。比如电商平台比普通记账软件难测。
技术难度：新框架、新技术，测试要花时间研究。像用前沿 VR 技术的软件。
类似经验：有类似项目经验，上手快，工作量小。
测试方法：自动化能省时间，手工测试花功夫。
人员能力：熟手效率高，新手可能慢。

1.1.23 测试设计的问题？

测试设计常遇这些问题：

覆盖不全：有些功能、场景没考虑到，像检查汽车，忘了测喇叭。
用例不准：设计的测试场景和数据不精准，难发现问题，好比用错钥匙，开不了锁。
依赖混乱：测试步骤间依赖关系没理清，一处变，全乱套，类似多米诺骨牌摆错。
缺乏复用：重复设计相似测试，浪费精力，像每次都重造轮子。

1.1.24 当测试过程发生错误时，有哪几种解决办法？

测试出错，三种解决办法：

修复问题：找到出错根源，像医生治病，开发动手改代码，解决错误。
绕过问题：暂时没办法修复，就想辙避开它，不影响主要功能，类似路不通绕着走。
记录并跟踪：先把问题详细记下来，持续盯着，等合适时机再处理，如同给问题做标记，方便之后 “算账”。

1.1.25 测试执行的问题？

环境岔劈：测试环境和实际用的不一样，好比在泥路试车，实际跑高速，结果没准。

用例拉胯：测试用例写得不好，漏测或者找不出问题，像用坏尺子量东西，结果不准。

执行偏差：没按测试用例来，或者记录不认真，类似不按菜谱做菜，还记错步骤。

资源短缺：时间、人手、设备不够，活儿干不完，好比人少菜多，做不过来。

1.1.26 测试评估的目标？

测试评估就俩大目标：

看质量：检查软件毛病多不多、性能好不好，像给商品挑刺，判断质量高低。
做决策：给开发、产品等团队提供参考，决定软件能不能上线，要不要改，类似给领导汇报，辅助做决策。

1.1.27 如何提高测试？

提高测试可这么做：

技术升级：学新工具、新方法，像给武器升级。比如掌握新自动化测试框架。
流程优化：简化步骤、明确分工，让测试像流水线，高效有序。
沟通加强：和开发、需求方多交流，及时解决疑问，避免方向跑偏。
经验积累：每次测试后总结，下次遇到类似问题处理更快。
团队培训：大家一起学习成长，提升整体实力，就像团队成员武功都变强。

1.1.28 C/S 模式的优点和缺点？

优点

速度快：客户端和服务器分工干活，就像两人合作搬重物，处理数据快，反应灵敏。
体验好：能根据客户需求定制客户端，就像量体裁衣，用起来顺手。
较安全：重要数据在服务器集中管理，就像把钱存银行，安全有保障。

缺点

维护烦：客户端软件更新时，每个都得单独弄，就像给一群人挨个发新衣服。
兼容难：不同系统和设备上的客户端适配麻烦，好比一双鞋难配所有人的脚。
成本高：要在客户端和服务器两边投入资源，就像养两个 “孩子” 花费大。

1.1.29 B/S 模式的优点和缺点？

优点

使用方便：打开浏览器就能用，无需安装客户端，就像去公共图书馆，直接借阅。
易于维护：只需更新服务器端，不用管客户端，好比给一栋楼统一换灯泡。
跨平台强：各种系统、设备都能访问，如同万能钥匙，适应不同锁。

缺点

响应较慢：依赖网络，请求都经服务器，像事事问领导，速度受影响。
功能受限：浏览器功能有限，复杂操作难实现，好比小勺子难盛大碗汤。
安全隐患：数据在网络传输，易被攻击，如同快递在途中可能被截。

1.1.30 测试结束的标准是什么？

测试结束有这几个标准：

用例跑完：计划好的测试场景都试过了，就像作业全做完。
问题解决：发现的毛病大多修复，剩下的不影响主要功能，好比伤口快愈合。
指标达标：性能、兼容性等指标符合要求，像考试成绩及格。
时间到点：达到预定测试时间，就像比赛有时间限制。

1.1.31 怎么才能够全面的测试到每一个点？

要全面测试每个点，这么做：

懂需求：吃透软件要干啥，就像战士了解作战目标。
多设计：用等价类、边界值等方法设计丰富测试用例，像撒大网捕鱼。
全覆盖：功能、性能、安全等方面一个不落，好比打扫房间每个角落。
靠工具：借助自动化测试工具辅助，如请帮手一起干活。
常复盘：每次测试后总结，查漏补缺，像打完仗总结经验。

1.1.32 开发与测试的关系？

开发和测试是软件项目里的好搭档：

目标一致：都想做出好用没毛病的软件，好比两人一起盖结实漂亮的房子。
分工不同：开发负责建软件，像工人盖楼；测试负责挑毛病，像质检员查楼质量。
相互依赖：开发成果是测试对象，没楼质检员没事干；测试反馈助开发改进，质检员反馈能让工人把楼盖得更好。
循环协作：开发改问题后测试再验证，像工人修楼后质检员再查，反复直到合格。

1.1.33 测试怎么和开发沟通？

测试与开发沟通，记住这几招：

问题讲清：发现问题，说清在哪、咋出现，像指给对方钥匙插哪孔，孔啥样。
态度友好：别指责，要合作，大家目标都是修复问题，像队友一起打怪。
提供证据：用截图、报错日志当证据，类似打官司拿证据说话。
商量解决：别光提问题，一起想办法，好比两人一起找路。
及时反馈：开发修复后，及时告知结果，像汇报任务完成情况。

1.1.34 测试过程？

定计划：好比规划旅行，想好测啥、啥时候测、用啥方法，让测试有方向。
写用例：设计各种场景，像设想旅行中各种状况，看看软件应对得咋样。
做测试：按场景实际操作软件，找毛病，如同真去旅行体验。
管缺陷：发现问题告诉开发，盯着他们修，类似发现东西坏了找师傅修。
做总结：回顾整个过程，看看有啥收获，像旅行结束写游记。

1.1.35 测试出口准则？

测试出口准则，就像考试交卷标准：

用例达标：测试用例都执行完，且结果符合预期，好比试卷题目全做完且答对。
缺陷受控：严重缺陷修复，轻微缺陷评估通过，类似严重错误纠正，小瑕疵能接受。
指标满足：性能、安全等指标达到要求，如同考试分数达到及格线。
资源用尽：时间、人力等资源耗尽，像考试时间到。

1.1.36 测试完成标准？

测试完没，看这几条：

用例跑完：计划的测试场景都试过，像作业全部写完。
问题处理：严重问题解决，小问题评估后不影响大局，好比大病治好，小伤不碍事。
指标合格：性能、安全等指标达到要求，类似考试成绩达标。
时间用尽：到了预定测试时间，如同比赛结束哨声响起。

1.1.37 测试活动中统计了那些数据?

测试活动统计这些数据：

用例相关：用例总数，像作业总量；执行数，看完成多少；通过率，了解做对没。
缺陷情况：发现多少缺陷，类似生病症状数；修复多少，看治好了没；遗留多少，清楚还剩啥毛病。
时间进度：测试开始、结束时间，像比赛起止时间；各阶段耗时，了解哪步花时间多。
人员投入：每人参与时长，看谁干活久；负责模块，明确分工。

1.1.38 如何选择用户测试的工作产品？

选用户测试工作产品，记住这几点：

看目标：和项目目标匹配，如想推新社交功能，就测相关模块，像射箭要对准靶心。
选常用：挑用户常用功能或场景，像餐厅常点的菜先试味道。
挑复杂：复杂部分易藏问题，如复杂的支付流程，类似迷宫易迷路。
有风险：有风险的地方，像新开发模块，类似新修路段可能有隐患。
听反馈：参考之前反馈，哪总被吐槽就测哪，像总漏水的屋顶多检查。

1.1.39 测试环境描述在哪儿？

测试环境描述一般在俩地儿：

测试计划：像旅行计划写明在哪玩，测试计划里会讲用啥系统、软件版本、网络等环境条件。
测试报告：类似旅行总结，测试报告回顾测试过程，也会提及测试环境，方便了解测试背景。

1.1.40 进行测试时产生了哪些文档或记录？

测试时会产出这些 “宝贝”：

测试计划：好比作战蓝图，写明为啥测、测啥、咋测、啥时候测。
测试用例：像一份任务清单，列着各种测试场景和操作步骤。
测试记录：记录测试过程，啥时候测的、结果咋样，类似考试草稿。
缺陷报告：专门 “挑刺”，写发现啥问题、在哪、咋出现的。
测试报告：类似总结陈词，汇总测试结果，说软件到底行不行。

1.1.41 测试人员需要何时参加需求分析？

测试人员在需求分析刚启动就该参加。好比建房，从设计图纸阶段就介入，才能清楚房子啥样，知道咋检查质量。早参与能提前熟悉需求，发现需求模糊、矛盾等问题，避免后期测试像盲人摸象，还能提前规划测试，提高效率。

1.1.42 产品测试完以后由谁来发布？

产品测试完，通常开发团队发布。因为他们熟悉代码和底层架构，像工匠熟悉自己造的物件，能把产品部署到生产环境。但发布前，开发会和产品经理、测试人员沟通，确保产品符合需求且没问题，就像出发前确认路线和车况。有时运维团队也参与，帮忙把产品平稳发布上线。

1.1.43 软件测试与调试的关系

软件测试与调试，关系像看病：

测试找病：测试是给软件 “体检”，找它的毛病，就像医生检查病人症状。
调试治病：调试是针对测试找出的问题，去分析病根，把软件修好，类似医生诊断后开方抓药治疗。
先后接力：先测试发现问题，再靠调试解决，两者紧密配合，保障软件健康，如同体检和治病结合让人恢复健康。

1.1.44 质量的八大特性是什么？各种特性的定义？

质量八大特性及其定义，简单记：

功能性：软件能完成该做的事，像计算器能算对结果。
可靠性：在规定条件和时间正常运行，如手机常时间用不死机。
易用性：容易上手使用，像共享单车扫码就会骑。
效率：完成任务快且占资源少，如软件秒开不卡顿。
维护性：方便修改、修复，像自行车零件好更换。
可移植性：能在不同环境运行，如游戏电脑手机都能玩。
兼容性：与其他软件、硬件等配合好，如打印机适配多种系统。
安全性：保护数据安全，防止信息泄露，像银行软件保护存款信息。

1.1.45 什么是软件的“质量”？

软件 “质量” 就像商品品质。好质量的软件，功能完好能满足需求，像精准导航的地图软件；用起来稳定可靠，不易出错崩溃，如同从不掉链子的交通工具；操作简单易上手，类似傻瓜式相机；运行效率高，不卡顿不拖沓，好似跑得又快又稳的汽车；还具备安全性，能保护数据，好比坚固的保险箱。总之，质量高的软件，用户用着舒心、放心

1.1.46 软件质量应该从哪些方面来评价？

评价软件质量，看这几方面：

功能：该有的功能都好使，像闹钟能准时响。
稳定：用的时候不崩溃、不出错，类似汽车不抛锚。
易用：上手容易，老人小孩都会用，好比共享单车扫码就会骑。
速度：运行快，打开、加载不磨蹭，像网速快视频秒播。
安全：数据不泄露，账号不被盗，类似家门锁好丢不了东西。
兼容：不同设备、系统都能用，如游戏手机平板都能玩。

1.1.47 什么是“软件质量保障”？

“软件质量保障” 就是给软件当 “保镖”。从软件开始构思，到开发、测试，再到上线后的维护，一路保驾护航。确保软件功能好用，像家电能正常运行；用起来稳定，不轻易出故障，如同坚固的桥梁；还得安全，保护数据不泄露，类似守护好保险柜。总之，让软件达到高质量标准，让用户放心用。

1.1.48 为什么软件会有毛病？

软件出毛病，原因有这些：

需求不清：开发像盖楼，需求不明就像图纸乱画，盖出来自然问题多。
逻辑复杂：软件逻辑像迷宫，路线越多越容易走错，功能复杂就易出错。
时间紧促：开发时间短，像赶工建房，质量难保证，毛病就容易冒出来。
人员疏漏：开发人员也是人，难免有疏忽，就像写字偶尔会写错。
环境变化：软件环境像天气，一旦改变，软件就可能不适应，好比人换环境会生病。

1.1.49 什么是 UML ？

UML 就是软件界的 “通用语言”。开发软件时，大家想法不同，UML 用图形来表达，像用图纸盖房子。类图展示软件有啥 “零件”，顺序图讲操作咋按顺序来，让团队沟通更顺畅，开发少走弯路。

1.1.50 什么是 CMM ？

CMM 就像是软件企业的 “成长指南” 和 “实力评级表”。它把软件企业开发管理成熟度分成五级，从混乱无序到优化创新。企业按它的标准改进，能提升开发效率和软件质量，就像游戏打怪升级，级别越高，在软件江湖里越厉害。

1.1.51 比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系？

区别
- 黑盒、白盒看视角
  - 黑盒测试：像顾客用产品，不管内部构造，只看输入输出，比如点外卖只看送来啥。
  - 白盒测试：似维修师傅，了解内部结构，针对代码逻辑测试，好比拆开家电找故障。
- 单元、集成、系统看范围
  - 单元测试：专注软件最小模块，类似检查机器单个零件，开发人员常做。
  - 集成测试：测试模块组合，就像把零件组装后看衔接，模块间通信是重点。
  - 系统测试：把软件当整体，在类似真实环境测，像新车上路跑全流程。
- 验收测试看目的：用户或客户主导，确认软件是否符合业务需求，好比买家收货看是否想要。
联系
- 开发流程上，先单元测试，再集成测试，接着系统测试，最后验收测试。
- 黑盒、白盒测试方法贯穿其中，黑盒常用于系统和验收测试，白盒在单元测试用得多。

1.1.52 比较负载测试、压力测试，容量测试和强度测试区别？

负载测试：像给车装货，看车在正常载货量下跑得咋样，测试软件在常规业务量下的性能，比如普通上班日网站的访问情况。
压力测试：继续给车加码，看加到极限车会怎样，测试软件在超出常规负载时的表现，如电商大促时网站承受大量用户访问。
容量测试：类似看车最大能装多少货，确定软件能处理的最大业务量，像计算网站最多能容纳多少用户同时在线。
强度测试：模拟恶劣环境，比如让车在暴雨、高温等极端条件下跑，考察软件在资源受限或异常环境下的稳定性，如低内存、高网络延迟时软件的运行。

1.1.53 测试执行过程的三个阶段？

测试执行分三阶段：

初测：像初次体检，全面过一遍，快速找明显问题，让软件先 “大致健康”。
细测：如同专家会诊，针对功能细节、边界情况深挖，揪出隐藏毛病。
回归：好比病后复查，看之前问题修复没，有无新问题，确保软件彻底 “痊愈”。

1.1.54 什么是验证、评价、预排、检查？

验证：
就像验货，看东西是不是和说的一样。在软件里，确认软件功能、性能等和预先设定的要求相符，比如检查手机功能是否达到说明书描述。
评价：
类似打分，综合考量好坏。对软件整体质量，从功能、易用性等多方面评估，给出一个总体看法，像给一部电影评价好不好看。
预排：
好比提前彩排，事先梳理流程、找出可能问题。在软件测试前，规划测试活动，预测风险，比如演出前预演找出节目衔接问题。
检查：
如同仔细查看有无瑕疵。对软件特定部分，如代码、文档详细审查，找错误或缺陷，像检查文章错别字和语病。

1.1.55 什么是兼容性测试？兼容性测试侧重哪些方面？

兼容性测试，就是看软件在不同 “伙伴” 身边能否正常玩耍。

它侧重这些方面：

设备：电脑、手机、平板等不同设备，像软件在苹果和安卓手机上都能正常用。
系统：Windows、iOS、Linux 等各类操作系统，类似软件在 Win10 和 Win11 系统都适配。
浏览器：IE、Chrome、Firefox 等，比如网页在不同浏览器显示和功能都正常。
软件：与其他常用软件，像办公软件与杀毒软件能共存不冲突。

1.1.56 我现在有个程序，发现在 Windows 上运行得很慢，怎么判别是程序存在问题还是软硬件系统存在问题？

想分清是程序还是软硬件的问题，试试这些招：

换设备对比：在其他 Windows 电脑上跑程序，都慢，可能程序有毛病；有的快，这台电脑软硬件可能有问题。就像同一款游戏，别人电脑不卡，你电脑卡，可能你电脑有状况。
测其他程序：运行别的类似程序，都慢，可能是软硬件拖后腿；其他程序快，那大概率是这个程序本身问题。好比你家网速看视频都卡，可能网络不行；但看别的视频不卡，就这个视频源有问题。
查资源占用：打开任务管理器，程序占用资源多，像 CPU、内存高，可能程序优化差；资源占用正常，软硬件出状况的可能性大。就像一辆车，油耗高可能车发动机不好；油耗正常但跑不快，可能路或其他部件有问题。

1.1.57 测试的策略有哪些？

黑盒/白盒，静态/动态，手工/自动，冒烟测试，回归测试，公测（Beta 测试的策略）

1.1.58 正交表测试用例设计方法的特点是什么？

正交表测试用例设计方法特点如下：

高效省钱：用较少测试用例覆盖多因素组合，像花小钱办大事，省时间精力。
均衡全面：各因素各水平均匀搭配，能全面反映因素影响，如同均匀撒网捕鱼。
科学靠谱：基于数理统计原理，设计科学合理，测试结果可信度高，像按精准配方做菜。

1.1.59 描述使用禅道，TAPD 缺陷管理工具对软件缺陷（BUG）跟踪的管理的流程？

禅道

发现提交：测试人员找到 BUG，在禅道里填详细信息，如出现位置、步骤、现象。
分配处理：项目经理把 BUG 分给开发人员。
修复验证：开发修复后标记，测试再验证，通过则关闭，不通过就打回重新修复。

TAPD

记录上报：发现 BUG 后在 TAPD 记录，写清问题特征。
流转指派：缺陷按规则流转，负责人指派给开发。
解决确认：开发解决，测试确认，完成就归档，没好就继续处理。

1.1.60 描述测试用例设计的完整过程？

需求理解：吃透软件要干啥，像明白菜谱要做啥菜。
分析要素：找出功能、输入输出、边界等关键点，如确定做菜食材和用量。
选设计法：依据情况挑等价类、边界值等方法，好比选炒菜、清蒸做法。
编写用例：按方法写步骤、预期结果，类似写清做菜流程和成品样子。
评审优化：大家一起挑刺完善，如厨师交流改进菜品。
入库更新：存进用例库，软件变了就更新，像菜谱随食材更新。

1.1.61 单元测试的策略有哪些？

单元测试策略有：

孤立测试：像把零件单独检查，不考虑和其他模块交互，专注测单个模块。
自顶向下：从顶层模块开始，逐步向下测，如同建楼从楼顶开始逐层往下检查。
自底向上：先测底层模块，再往上组合测，就像先把地基等基础弄好再盖上层。
三明治测试：结合自顶向下和自底向上，中间层最后测，类似做三明治分层来。

1.1.62 你所熟悉的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……）？

常见软件测试类型

功能、性能、安全、兼容性、易用性测试等。

区别

功能测试：查软件功能对不对，像检查电视能否正常播放节目。
性能测试：看软件在不同负载下的表现，如测试网站能承受多少人同时访问。
安全测试：找软件安全漏洞，像给银行系统检查有无被盗刷风险。
兼容性测试：测软件在不同环境能否正常工作，如检查游戏在不同手机上能否运行。
易用性测试：评软件好不好用，像判断 APP 操作是否简单顺手。

1.1.63 软件缺陷（或者叫 Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？

缺陷记录内容

基本信息：编号、状态、严重程度、优先级，类似病人病历号、病情阶段、轻重和处理顺序。
重现步骤：操作步骤、输入数据，就像说清生病前吃了啥做了啥。
预期与实际结果：本该怎样、实际怎样，好比预期身体无恙却生病了。
环境信息：软硬件环境，如在哪台设备、啥系统下出的问题。

提交高质量记录方法

清晰准确：步骤、结果描述不含糊，像描述症状不能模棱两可。
完整全面：信息无遗漏，如同病历各项信息都得填全。
可重现：步骤别人按做也能出问题，就像医生按描述能复现病情。
客观中立：不主观猜测，只陈述事实，如不能没证据就说软件是被攻击了。

1.1.64 软件的评审一般由哪些人参加？其目的是什么？

参加人员

开发人员：软件代码的编写者。
测试人员：负责找软件问题。
需求人员：明确软件该有啥功能。
项目经理：统筹项目进度。
客户代表：提出使用需求和期望。

目的

找错纠错：大家一起挑刺，发现软件需求、设计、代码里的错误。
统一理解：让各方对软件目标、功能等达成一致看法。
保证质量：提前消除隐患，提升软件最终质量。
把控进度：确认各阶段是否达标，保障项目按时完成。

1.1.65 测试活动中，如果发现需求文档不完善或者不准确，怎么处理？

精准记录：像侦探记线索，详细记下需求文档里不完善、不准确的地方。
及时沟通：马上找需求人员、产品经理说问题，好比发现食材不对找厨师反馈。
共同研讨：和相关人员一起商量，明确正确需求，就像大家一起定新菜谱。
更新文档：根据讨论结果修改需求文档，让它变准确完善，如同更新菜谱内容。
重新评估：按新文档评估测试计划、用例，不合适就调整，似按新菜谱改做菜流程。

1.1.66 阶段评审与项目评审有什么区别？

时间点不同

阶段评审：项目进行中，完成某个阶段就评，像盖楼每层建好都检查。
项目评审：项目结束时开展，如楼盖好后整体验收。

关注重点不同

阶段评审：看该阶段成果对不对、能否进入下一阶段，如检查每层楼结构是否达标。
项目评审：评估整个项目目标有无达成、质量咋样、效益好不好，像看整栋楼是否符合设计且能盈利。

参与人员不同

阶段评审：主要是该阶段涉及的人员，如某层楼施工人员和监理。
项目评审：各方人员都有，像开发商、业主、质检部门等。

1.1.67 阐述工作版本的定义？

工作版本就像是软件在制作过程中的一个个 “半成品快照”。开发人员每完成一部分功能或做了一些修改后，把软件保存成一个特定状态，这就是一个工作版本。它能让团队成员清楚软件当前进度，方便测试找问题、开发回溯修改，就像游戏存档，随时能回到某个状态接着玩。

1.1.68 什么是桩模块？什么是驱动模块？

桩模块

当你测一个大软件里的某个小模块时，这个小模块要和其他模块配合，但那些模块还没做好。这时就造个 “假伙伴” 来假装和它配合，这个 “假伙伴” 就是桩模块。好比小朋友玩过家家，没有真的蛋糕，就用积木假装蛋糕。

驱动模块

测试小模块，得给它提供数据让它运行起来。驱动模块就像个 “小司机”，给小模块送数据，指挥它开始干活，就像大人推动小朋友的玩具车让它跑起来。

1.1.69 什么是扇入？什么是扇出？

扇入和扇出是衡量软件模块间调用关系的概念：

扇入：好比一个明星有多少粉丝来找他，指有多少其他模块调用当前模块，扇入数高说明该模块复用性好，像大明星粉丝众多。
扇出：如同一个人要去帮助多少人，是指当前模块调用其他模块的数量，扇出数合理表示模块功能单一职责明确，若太多就像一个人忙不过来要帮太多人，可能出问题。

1.1.70 你认为做好测试计划工作的关键是什么？

做好测试计划关键有三点：

需求吃透：像厨师了解菜谱，清楚软件要实现啥功能，才能定好测试范围和重点。
安排合理：人员分工、时间规划要合适，就像球队排兵布阵和赛程安排，保证测试顺利开展。
灵活应变：软件会变，计划得跟着调整，如同航行时根据风向调整船帆，保证测试效果。

1.1.71 你觉得对于测试有哪些基本素质要求？

测试基本素质要求有：

细心耐心：像找茬高手，不放过代码、功能一点小毛病，有耐心反复测。
逻辑清晰：理清软件流程和逻辑，能顺藤摸瓜找问题，像侦探推理。
沟通力强：和开发、产品等有效沟通，准确传达问题，像桥梁连接各方。
学习力好：软件技术不断变，要快速学新东西，跟上更新步伐。
有责任心：把软件质量当自己责任，不敷衍，保证交付质量。

1.1.72 一套完整的测试应该由哪些阶段组成？

一套完整测试分四阶段：

计划：就像制定作战方案，定目标、范围、方法和资源安排。
设计：如同绘制地图，设计测试用例，规划咋发现问题。
执行：好比按图索骥，运行用例，记录结果，揪出软件毛病。
总结：类似战后复盘，分析结果，写报告，为后续项目做参考。

1.1.73 软件测试的流程是什么？

软件测试流程四步走：

测前准备：了解软件需求，规划测试，备好资源，就像打仗前研究作战计划、备齐武器。
用例设计：根据需求设计测试步骤和预期结果，如同制定菜谱。
执行测试：按用例操作软件，记录发现的问题，好比按菜谱做菜并挑毛病。
测试总结：分析结果，出报告，提改进建议，如做菜后总结经验。

1.1.74 说说你对 SQA 的职责和工作活动(如软件度量)的理解？

SQA 职责

SQA 即软件质量保证，就像软件项目的 “质量警察”。它要确保软件开发过程和成果符合既定标准和要求，对项目全程质量负责，保护软件不 “生病”，让客户放心用。

工作活动

过程监控：时刻盯着开发流程，看是不是按规矩来的，就像交警指挥交通，保证大家按规则行驶。
文档审查：仔细检查各种开发文档，保证内容完整、准确，如同审核合同条款，避免漏洞。
软件度量：收集、分析软件相关数据，比如代码行数、缺陷数量等，就像给软件做体检，通过指标判断健康状况。
问题反馈：发现问题及时告诉相关人员，并监督改进，类似医生诊断后给出治疗方案并跟进。

1.1.75 单元测试的主要内容？

单元测试主要测单个代码单元，像零件质检：

功能：查代码单元能否实现预期功能，如加法函数结果是否正确。
逻辑：看代码逻辑有无错误，比如条件判断、循环是否按设定执行。
接口：测与其他单元交互的接口对不对，数据传递是否正常。
边界：试边界情况有无异常，像数组越界、数值最大最小情况。

1.1.76 集成测试也叫组装测试或者联合测试，请简述集成测试的主要内容？

集成测试就像组装机器后调试，主要内容有：

接口测试：检查模块间接口，看数据传递是否顺畅，如同检查零件连接是否紧密。
功能验证：验证组合模块功能是否正确，好比测试组装好的机器能否正常运转。
全局数据：查看全局数据在模块交互时有无异常，类似检查机器各部分共享的能源供应是否稳定。
冲突检查：找出模块集成后可能出现的冲突和不一致，就像排查机器运行时各部件有无相互干扰。

1.1.77 简述集成测试与系统测试关系？

集成测试和系统测试是软件测试接力赛的两棒：

先后顺序：集成先，把模块组装测接口功能；系统后，将整个软件当整体测。就像先组装汽车部件，再测试整辆车。
测试范围：集成侧重模块连接交互；系统涵盖软件所有功能、性能、兼容性等。如同前者查部件连接，后者评整车表现。
目标相同：都是为提升软件质量，保证满足需求，像接力赛都为冲过终点。

1.1.78 软件测试的文档测试应当贯穿于软件生命周期的全过程，其中用户文档是文档测试的重点。那么软件系统的用户文档包括哪些？

软件系统用户文档是给用户用的说明资料，主要有：

用户手册：像产品说明书，教用户咋安装、操作软件，比如怎么登录、使用功能。
操作指南：聚焦具体操作步骤，详细到每一步点啥、填啥，类似做菜步骤。
帮助文档：用户遇问题能查，类似字典，有常见问题解答和操作技巧。
发布说明：讲软件新特性、修复的问题、使用注意事项，如同新品介绍亮点和禁忌。

1.1.79 软件系统中除用户文档之外，文档测试还应该关注哪些文档？

除用户文档外，文档测试还得关注：

需求文档：是开发源头，像建筑蓝图，要保证需求完整准确无歧义。
设计文档：包含架构、模块设计等，如同施工图纸，查设计是否合理可行。
测试文档：如计划、用例、报告，类似考试安排、题目和成绩，看测试规划和结果有无问题。
维护文档：记录维护信息，像病历档案，确保故障修复等内容清晰。

1.1.80 简述软件系统中用户文档的测试要点？

用户文档测试要点如下：

内容准确：信息和软件实际一致，像地图得和实际路线相符。
表述清晰：文字简单易懂，无歧义，就像说明书让人一看就会。
完整全面：涵盖安装、操作、常见问题等内容，似字典啥都能查到。
示例有效：案例可实际操作，能解决问题，如同示范做菜能做出好菜。
格式规范：排版、字体等统一美观，好比书本排版看着舒服。

1.1.81 如何理解强度测试？

强度测试就像给软件 “极限施压”。正常使用软件好比人正常走路，强度测试则是让软件在远超平常的恶劣条件下运行，比如短时间内有海量用户访问、处理超大任务量等，看看它在这种 “极限奔跑” 状态下会不会 “累瘫”，能不能正常应对不崩溃、不出错，以此来检验软件的抗压能力和稳定性。

1.1.82 如何理解压力、负载、性能测试测试？

压力测试

好比让运动员挑战极限，给软件不断增加压力，如大量并发用户或超大任务，看它到啥程度会崩溃出错，测的是软件最大承受力。

负载测试

如同给货车装不同重量货物，逐步增加软件负载，观察不同负载下软件性能表现，找能稳定运行的最大负载。

性能测试

就像给运动员做全面体能评估，考察软件在不同条件下的性能指标，如响应时间、吞吐量等，确保满足使用要求。

1.1.83 什么是系统瓶颈？

系统瓶颈就像马路最窄的路段。软件或系统运行时，某个部分处理能力跟不上整体节奏，就像窄路段让车流变慢，限制了整个系统的性能和效率，使系统无法更快更好地完成任务。

1.1.84 文档测试主要包含什么内容？

文档测试内容有：

准确性：信息和实际一致，像地图与实际地形相符。
完整性：涵盖所有必要信息，如说明书无关键步骤缺失。
一致性：不同文档说法统一，像各版本介绍同一功能无矛盾。
可读性：表述简单易理解，类似故事书小孩也能读懂。
规范性：格式、术语等合规统一，如论文符合学术规范。

1.1.85 功能测试用例需要详细到什么程度才是合格的？

合格的功能测试用例要像一份清晰菜谱：

操作明确：写明每一步做啥，如 “点首页登录按钮”，不能含糊。
预期清晰：结果一目了然，如 “成功跳转登录页”，不模棱两可。
覆盖充分：正常、异常情况都有，像炒菜考虑各种火候。
无关不写：不添多余信息，简洁直达目标，像菜谱无废话。

1.1.86 配置和兼容性测试的区别是什么？

配置测试和兼容性测试有明显不同：

配置测试：就像给汽车调不同挡位，主要看软件在不同硬件配置（如内存、CPU）、软件设置（如系统参数）下，自身功能能否正常运行。
兼容性测试：好比检查汽车和不同道路、加油站的适配，重点测软件和其他软件（如浏览器、数据库）、硬件设备（如打印机、手机）、不同环境（如操作系统、网络）协同工作时有无问题。

1.1.87 没有产品说明书和需求文档地情况下能够进行黑盒测试吗？

能做但受限。黑盒测就像不看内部构造试玩具功能。没说明书和需求文档，能凭经验常识发现明显问题，如玩具开关没反应；但不清楚该有啥功能玩法，像不知玩具隐藏技能，难全面深入测试。

1.1.88 测试中的“杀虫剂怪事”是指什么？

“杀虫剂怪事” 就像害虫会对杀虫剂产生抗药性。在软件测试里，总用同样测试用例，开始能找出不少缺陷，但时间一长，软件对这些 “测试杀虫剂” 适应了，新缺陷就难发现。得更新测试用例，像换种杀虫剂，才能继续揪出问题。

1.1.89 在配置测试中，如何判断发现的缺陷是普通问题还是特定的配置问题？

就像判断人不舒服是普通生病还是特定环境不适。在不同配置下反复测：若各配置都出问题，就是普通问题，如同在哪都咳嗽是感冒；若只特定配置下有问题，那就是配置问题，好比在花粉多的地方才过敏。

1.1.90 为什么尽量不要让时间有富裕的员工去做一些测试？

这就像让业余厨师救场做大餐。时间富裕员工往往没专业测试技能和经验，就像业余厨师不懂专业烹饪技巧。可能不熟悉测试方法、工具，难以全面找出软件问题，还可能因不重视测试流程而打乱节奏，影响软件测试质量和项目进度。

1.1.91 完全测试程序是可能的吗？

完全测试程序基本不可能，就像把沙滩上沙子全数清。程序运行情况巨多，数据输入组合无数，测试时间和资源有限，没法把所有情况都测一遍，只能挑重点测。

1.1.92 软件测试的风险主要体现在哪里？

软件测试风险就像探险有危险：

时间不足：工期紧测不完，像探险没时间走遍所有地方。
人力不够：测试人员少或能力差，如同探险队人手不足还没经验。
工具不佳：工具不好使，像探险没好装备。
需求多变：软件要求老变，测试跟着折腾，似探险目标老改。
缺陷难察：藏得深的问题难发现，如探险遇隐蔽陷阱。

1.1.93 发现的缺陷越多，说明软件缺陷越多吗？

不一定。发现缺陷多可能真因软件毛病多，像烂苹果坏点一眼可见；但也可能是测试投入大、方法好，就像仔细挑水果能找出更多小毛病，不代表别的水果没藏着问题。

1.1.94 所有的软件缺陷都能修复吗？所有的软件缺陷都要修复吗？

并非都能修复

软件缺陷像衣服破洞，有的容易补，比如小代码错误；但有些因技术限制、时间成本高等，就像衣服布料特殊难修补，没法修复。

并非都要修复

有些缺陷影响小，修复成本却高，好比衣服上小线头，不影响穿就不用管；而严重影响使用的缺陷，像衣服破大洞，就得修。

1.1.95 软件测试人员就是 QA 吗？

不全是。软件测试人员主要找软件毛病，像抓小偷。QA 更像警察局长，除找问题，还得规划测试流程、保障质量体系，确保整个开发过程合规，让软件质量有保障。

1.1.96 如何减少测试人员跳槽带来的损失？

减少测试人员跳槽损失，可这么做：

留资料：让测试员整理好测试用例、报告等文档，像给后来人留地图。
做交接：安排老员工带新员工，传授经验，好比师傅带徒弟。
稳军心：给留下员工激励，保持团队稳定，就像给守城士兵发奖赏。
善规划：提前培养后备力量，以防不时之需，如同家里备着干粮。

1.1.97 测试产品与测试项目的区别是什么？

测试产品和测试项目有这些区别：

测试产品：像长期守护一座城，产品通常持续迭代更新，要反复测保证稳定，关注整体质量和用户体验，覆盖不同版本和功能组合。
测试项目：如同打一场战役，有明确起止时间和目标，完成特定任务就结束，聚焦本次项目需求，确保按要求交付。

1.1.98 和用户共同测试（UAT 测试）的注意点有哪些？

和用户共同测软件（UAT 测试），注意这些：

目标清晰：提前和用户讲清测啥、咋用，像导游介绍路线景点。
环境真实：用和实际一样的软硬件、数据，如按真战场练兵。
及时沟通：用户反馈问题马上记，快速交流解疑惑，似消防员速灭火。
文档记录：详细记测试过程、结果和问题，如史官写历史。
范围把控：按预定范围测，别跑偏浪费精力，像司机按路线开车。

1.1.99 如何编写提交给用户的测试报告？

给用户写测试报告，要像给朋友讲电影：

简单开场：介绍软件是啥、测试干了啥，像说电影名字和类型。
结果突出：挑重点讲软件好不好用、有啥问题，类似讲电影精彩和槽点。
数据说话：用数字说测试情况，如成功率、出错率，像列电影票房评分。
建议清晰：给出改进办法，就像给电影提拍续集建议。
排版舒服：格式简洁、图表直观，似电影海报一目了然。

1.1.100 测试工具在测试工作中是什么地位？

测试工具在测试工作里就像武器之于战士。没有它，测试靠手动，耗时费力效果差，像战士赤手空拳；有了它，能提高效率、精准定位问题，如战士有先进枪炮，是提升战斗力的关键帮手。

1.1.101 写出 bug 报告流转的步骤，每步的责任人及主要完成的工作？

发现与提交

责任人：测试人员
工作：找到软件 Bug 后，详细记录复现步骤、现象等信息，提交到 Bug 管理系统。就像警察发现罪犯，记录其特征后上报警局。

审核与分配

责任人：测试负责人
工作：检查 Bug 报告完整性和有效性，将其分配给对应开发人员。类似警局领导审核案件信息，分配给具体警员。

修复

责任人：开发人员
工作：根据 Bug 报告分析原因并修复，在系统标记修复状态。如同警员抓到罪犯并处理。

验证

责任人：测试人员
工作：对修复后的 Bug 进行再次测试，确认是否真的解决。好比检查罪犯是否被妥善处理。

关闭或重新打开

责任人：测试人员
工作：若验证通过，关闭 Bug；若未解决，重新打开并补充新情况。就像确认罪犯被处理好则结案，没处理好就重查。

1.1.102 写出 bug 报告当中一些必备的内容？

Bug 报告必备内容有：

标题：简洁概括问题，像给病人诊断写病名。
复现步骤：清楚写明咋操作出问题，如讲做菜步骤。
实际结果：说清操作后看到啥异常，像描述病人症状。
预期结果：表明正常该是啥样，如说病治好啥状态。
环境信息：列出软硬件环境，如讲病人生活环境。

1.1.103 开发人员老是犯一些低级错误怎么解决？

培训提升：组织基础技能培训，像给新手司机开驾驶课，增强知识储备。
规范约束：制定代码规范和检查清单，如设交通规则，让开发有章可循。
审查纠错：开展代码审查，像老司机带新手检查车况，及时揪错。
激励改进：设奖惩制度，表现好奖励、总犯错惩罚，似比赛有输赢奖惩。
交流分享：组织经验交流，像车友会分享驾驶心得，避免再犯。

1.1.104 软件的构造号与版本号之间的区别？BVT(BuildVerificationTest)

构造号与版本号区别

版本号像软件的大标签，代表重大功能更新、大改进，能看出软件大概处于啥发展阶段，如 Windows 10、11。构造号则是小标签，记录每次编译的编号，反映具体编译情况，同一版本可能有多个构造号。好比一个班级是版本号，班里每个同学编号是构造号。

BVT（Build Verification Test）

BVT 就是构建验证测试，好比房子建好先粗检。在软件新版本构建后，快速对主要功能做简单测试，看能不能正常运行，要是有大问题就及时返工，免得后续浪费时间精力。

1.1.105 测试在开发阶段的作用？

测试在开发阶段就像盖楼时的质检。

开发前期，测试帮忙挑需求毛病，避免方向跑偏，好比建楼前查图纸漏洞。

开发中，及时揪出代码问题，让开发能马上改，如同盖楼时边建边查墙歪不歪。

开发后期，全面检查软件，保证交付质量，就像楼盖好后整体验收。

1.1.106 一个完整的开发流程是什么样的？

1.1.107 测试与开发各个阶段的关系？

1.1.108 在软件开发过程中5 个常见的问题是什么?

需求不清：就像盖房没图纸，开发方向易跑偏。
沟通不畅：团队像没配合的乐队，进度受影响。
进度失控：工期如脱缰野马，交付时间难保证。
质量不佳：软件似残次品，问题多影响使用。
成本超支：预算像漏水钱包，资金易超出预期。

1.1.109 针对软件开发过程中的问题，有哪些解决方法？

需求不清：和客户深度聊，用原型、案例明确想法，像和建筑师确定房屋蓝图。
沟通不畅：定期开会、用协作工具，成员多交流，如乐队常合练。
进度失控：合理排期、设里程碑监控，像给行程设站点。
质量不佳：做好测试，严格按规范开发，如给产品设质检关卡。
成本超支：精准预算、监控开支，像管家管账。

1.1.110 阐述软件生命周期都有哪些阶段？常见的软件生命周期模型有哪些？

软件生命周期阶段

就像养孩子，软件也有几个成长时期：

需求分析：了解用户想要啥功能，像琢磨孩子要学啥本领。
设计：规划软件架构和模块，如同给孩子规划成长路径。
编码：把设计变成代码，类似按路径让孩子一步步成长。
测试：检查软件有无问题，就像给孩子做体检。
维护：对软件更新修复，好比持续关注孩子健康成长。

常见软件生命周期模型

瀑布模型：一步接一步，像瀑布水流，前一阶段完才到下一阶段。
敏捷模型：灵活快速，小步快跑，不断响应需求变化，像短跑选手灵活应变。
迭代模型：分多次迭代开发，每次增加功能，如同搭积木逐步完善。

1.1.111 Beta 测试与Alpha 测试有什么区别？

Alpha 测试好比大厨在厨房自己先尝尝菜，是开发团队内部在模拟实际环境下对软件进行的测试，能及时调整改进。

Beta 测试就像把菜端出去让顾客试吃，是将软件交给部分外部用户在真实使用环境下测试，收集更广泛反馈，发现更多潜在问题

1.1.112 你认为做好测试用例工作的关键是什么？

做好测试用例工作，关键有仨：
一是 “懂需求”，就像厨师清楚客人口味，精准覆盖软件功能；
二是 “设计妙”，像排兵布阵，用等价类、边界值等方法设计，高效找问题；
三是 “常更新”，软件变，用例跟着改，似地图随城市发展更新。

1.1.113 简述一下缺陷的生命周期？

缺陷生命周期就像病人看病流程：

发现：测试人员找出缺陷，好比医生查出病症。
提交：记录信息上报，如同医生开病历。
分配：负责人分给开发人员，类似安排专家会诊。
修复：开发人员修改，就是医生治病。
验证：测试人员检查，看治没治好。
关闭：问题解决，相当于病人康复出院；若没解决，则重新进入流程。

1.1.114 软件的安全性应从哪几个方面去测试？

软件安全性测试可从这几方面下手：

身份认证：查登录时用户名、密码等验证是否可靠，像检查进门钥匙对不对。
授权访问：看不同用户权限是否合理，防止越权操作，好比规定不同人能进哪些房间。
数据加密：测数据传输和存储有无加密，确保不被窃取篡改，如给重要文件上密码锁。
漏洞扫描：找软件代码漏洞，像检查房子有没有贼能钻进来的洞。
应急处理：看面对攻击、故障时恢复能力，类似房子着火后灭火重建能力。

1.1.115 软件配置管理工作开展的情况和认识？

开展情况

软件配置管理就像给软件建个 “档案室”。得先把软件各种资料，像代码、文档都收集好，分类存起来。然后对这些资料的修改进行严格记录，谁改的、啥时候改的、为啥改，都要一清二楚。团队成员取用资料时也得有规范，不能乱拿乱放。

认识

它特别重要，能保证软件版本不乱套，不会出现一个功能改了这版丢了那版的情况。就像给软件上了个 “保险”，开发过程更有序，出问题也能快速找到源头解决，还方便不同成员协同工作。

1.1.116 引入测试管理的含义？

引入测试管理就像给测试团队配个 “指挥官”。

没 “指挥官” 时，测试工作可能乱成一锅粥，测试任务分配不明确、进度难把控、结果没标准。

有了测试管理，能合理安排测试人员和任务，就像指挥官排兵布阵；能实时掌握测试进度，保证按时完成，如同指挥官把控作战节奏；还能统一测试标准和流程，让测试结果更可靠，好比指挥官制定作战规则。

1.1.117 什么是版本控制，常用的版本控制系统有哪些？

版本控制

版本控制就像给文件建时光机。能记录文件每次修改，可随时回到过去版本，也能对比不同版本差异。多人合作时，还能避免修改冲突，清楚谁改了啥，好比记录一群人对故事的修改过程。

常用系统

Git：灵活强大，分布式管理，像热闹集市大家都能自主交易信息，全球开发者爱用。
SVN：集中式管理，版本库像大仓库，大家从这取改文件，操作简单易上手。

1.1.118 为什么要在一个团队中开展软件测试工作？

在团队开展软件测试，就像给房子做质检。

软件有问题，好比房子有隐患，会让用户用得糟心，还砸了软件名声。测试能提前揪出问题，让软件更稳定、可靠，就像质检能保证房子质量。而且不同人看法不同，测试人员站在用户角度找毛病，能让软件更合用户心意，给团队带来好口碑，赚更多用户。

1.1.119 您在以往的测试工作中都曾经具体从事过哪些工作？其中最擅长哪部分工作？

我曾经做过web 测试，后台测试，客户端软件，其中包括功能测试，性能测试，用户体验测试。
最擅长的是功能测试。

1.1.120 测试计划工作的目的是什么？测试计划工作的内容都包括什么？其中哪些是最重要的？

目的

测试计划就像打仗的作战计划，目的是让测试工作有方向、有秩序，合理分配人力、时间，确保软件能被全面、高效地测试，及时发现问题。

内容

范围：明确测哪些软件功能。
方法：确定用啥方式测。
进度：规划测试时间安排。
资源：列出需要的人力、设备等。
风险：预估可能遇到的问题及对策。

最重要的

范围和进度最重要。范围不清，测试就会像无头苍蝇；进度没规划好，测试可能延期，影响软件交付。

1.1.121 您所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用？

等价类划分法

把输入数据分有效和无效等价类。比如测一个输入年龄的框，1 - 120 岁是有效等价类，小于 1 和大于 120 是无效等价类。设计用例时，从每个等价类选代表值测试，像选 20（有效）、0（无效）、150（无效），能以少量用例覆盖大量情况。

边界值分析法

关注输入数据边界。还以年龄输入框为例，边界值就是 1、120 及临近值 0、2、119、121。这些边界最易出错，用这些值设计用例，可提高发现问题概率。

因果图法

分析输入条件因果关系来设计。如登录系统，输入正确用户名和密码能登录成功，这是因果。用因果图把关系画出来，再转成测试用例，涵盖各种因果组合，像测用户名对密码错、用户名错密码对等情况。

错误推测法

凭经验推测可能出错地方设计用例。比如已知某系统曾在大文件上传时崩溃，就针对大文件上传设计用例，如上传最大允许大小文件、超大文件等。

1.1.122 请以您以往的实际工作为例，详细的描述一次测试用例设计的完整的过程？

之前测一个电商 APP 商品搜索功能，测试用例设计过程如下：

1. 了解需求

和产品经理沟通，搞清搜索功能要支持商品名称、类别、价格区间搜索，支持模糊匹配。好比知道要建啥样的房子。

2. 分析输入输出

输入有搜索关键词、类别筛选、价格范围；输出是符合条件商品列表。这就像确定建房子的材料和样子。

3. 选设计方法

用等价类划分和边界值分析。比如关键词分有效（如 “手机”）、无效（特殊符号）等价类；价格范围考虑边界值，像最低 0 元、最高 9999 元。

4. 设计用例

正常搜索：输 “手机” 搜商品。
模糊搜索：输 “苹” 搜苹果相关产品。
价格筛选：选 1000 - 2000 元搜对应商品。
无效输入：输 “@#$” 看提示。

5. 评审用例

和开发、产品一起讨论，看是否覆盖需求、有无遗漏，类似建房前检查图纸。

6. 用例入库

没问题后，把用例放进测试用例库，等执行测试，如同把设计方案存档备用。

1.1.123 您以往是否曾经从事过性能测试工作？如果有，请尽可能的详细描述您以往的性能测试工作的完整过程?

我做过性能测试，以电商 APP 大促活动前测试为例：

1. 确定目标

明确要测响应时间、吞吐量等指标，比如规定商品详情页打开时间不能超 3 秒。就像给比赛定规则。

2. 制定计划

规划好测哪些功能，如搜索、下单；啥时候测；要多少测试设备和人员。类似赛前安排赛程和人员分工。

3.准备环境

搭建和线上一样的测试环境，装软件、配服务器参数，像赛前布置场地。

4. 设计用例

按不同场景设计，如高并发下单、多人同时搜索。好比为比赛设计不同项目。

5. 执行测试

用工具模拟大量用户访问，记录性能数据。就像开始比赛并记录成绩。

6. 分析结果

对比指标找问题，如响应时间过长、吞吐量不达标。如同分析比赛成绩找不足。

7. 给出报告

写明问题、影响和建议，给开发人员。就像赛后写总结报告。

8. 跟踪优化

盯着开发改问题，改完再测，直到性能达标。类似督促改进后再比赛看效果。

1.1.124 你对测试最大的兴趣在哪里？为什么？

我对测试最大兴趣在于解谜。软件就像复杂谜题，表面看似正常，实则藏着各种问题。每次测试，都像抽丝剥茧找线索，把隐藏的缺陷一个个揪出来，特有成就感。好比福尔摩斯探案，揭开真相那刻，兴奋又满足。

1.1.125 你以前工作时的测试流程是什么？

以前工作时，测试流程像接力赛：

需求了解：和产品团队唠明白软件要干啥，像听清比赛规则。
测试计划：规划测啥、咋测、啥时候测，类似安排赛程。
用例设计：想办法找软件毛病，列出测试步骤，好比设计比赛项目。
环境搭建：准备好测试用的软硬件，像布置比赛场地。
执行测试：按计划测，找问题就记录，仿佛比赛时按规则打分。
缺陷跟踪：盯着开发修复问题，直到解决，如同监督选手改正失误。
测试总结：汇总情况，为下次测试攒经验，就像赛后总结。

1.1.126 当开发人员说不是BUG 时，你如何应付？

重讲需求：咱再对照需求文档唠唠，这功能明摆着要达到啥样，现在没做到，可不是小问题。就像按菜谱做菜，没达到菜谱标准，那就是没做好。
亮测试证据：您看，我多次测试都出这状况，还有操作步骤和结果记录，可不是偶然的。好比您开车老在一个地方出状况，肯定得重视。
站用户角度：用户要是碰到这，使用体验得多差，咱得为他们考虑。就像卖东西，得让顾客用着满意。
找第三方评理：要是还僵持，咱找产品经理或领导来定夺，大家一起商量。类似俩人吵架，找个明白人评评理。

1.1.127 测试总结报告包括那些项？

测试总结报告，好比学期成绩单，得有这些：

基本信息：软件名、版本、测试时段，像成绩单上学生姓名、班级、学期。
测试概要：测了啥功能，咋测的，类似学科和学习方法。
测试结果：发现多少问题，解决多少，剩多少，如同考试成绩和错题情况。
缺陷分析：问题出在哪，为啥会有，像分析错题原因。
测试结论：软件达没达到要求，能不能上线，类似给学生下学习评定。
改进建议：以后咋做得更好，好比给学习提改进方法。

1.1.128 测试工作进行到一半是，发现时间不够，你如何处理？

要是测试进行到一半发现时间不够，就像跑步跑到一半发现时间快到终点了，得这么办：

重新评估：赶紧瞧瞧哪些测试还没做，哪些最重要。就像看看赛程还有哪段没跑，哪段关键。
调整计划：先测最重要的功能，不重要的先放放，或者简化测试步骤。好比优先跑关键路段，其他路段快速过。
求助支援：跟领导说情况，看看能不能加派人手或者延长时间。类似跟教练喊，多给点助力或宽限点时间。
沟通协调：和开发团队唠唠，让他们先修严重的问题。如同跟队友商量，先处理紧急状况

1.1.129 如果你是测试组长你如何对项目及组员进行管理？

要是我当测试组长，管理就像带队打比赛：

明确目标：跟组员讲清项目要测啥，啥标准算达标，像告诉队员比赛要干啥，咋算赢。
合理分工：根据组员特长分任务，擅长找漏洞的测关键功能，细心的查文档，如同给队员安排合适位置。
制定计划：安排好啥时候测啥，啥时候出报告，像规划比赛赛程。
指导监督：组员遇到难题，我给方法思路，还常检查进度和质量，类似教练指导并监督训练。
促进沟通：定期开小组会，让大家交流问题，跟开发、产品团队也多沟通，就像比赛要和裁判、对手交流。
激励组员：组员表现好，及时夸，给奖励，让大家有干劲，如同给表现好的队员喝彩奖励。

1.1.130 缺陷报告严重级别的划分？

缺陷报告严重级别就像医院给病人病情分级：

致命：软件直接没法用，像人生命垂危。比如电商 APP 付款功能彻底崩溃，没法交易。
严重：主要功能受损，影响核心使用，类似人重病但还能撑。像搜索商品结果全错，严重影响购物。
一般：功能有瑕疵，不影响大局，好比人有点小毛病。如商品详情页个别图片加载慢，但能看到内容。
轻微：外观或小细节问题，类似人有点小擦伤。像界面文字排版不太整齐。

1.1.131 开发人员修复缺陷后，如何保证不影响其他功能？

开发人员修复缺陷后，要像装修完检查房子其他地方有无损坏一样，通过这些办法保证不影响其他功能：

回归测试：把之前因这个缺陷测过的功能，再测一遍，看修复后是否正常。好比修好漏水，再看看周围墙皮、地板有无受潮。
全面冒烟测试：对软件主要功能快速过一遍，确认整体 “健康”。类似房子主要房间快速查看，看有无大问题。
自动化测试：用工具自动跑常用功能测试，像派机器人巡逻，快速发现异常。
交叉测试：不同测试人员换着测，避免思维局限，就像不同人检查房子，能发现更多问题。

1.1.132 发现问题后你是如何判断其是否是BUG，你是如何确认是前端问题还是后端问题？

判断是否是 BUG

就像判断东西有没有坏，看它是不是和说好的不一样。软件功能要是和需求文档里写的不同，或者出现崩溃、异常，那大概率是 BUG。比如文档说按钮点击该弹出菜单，结果没反应，这就是 BUG。

确认前端还是后端问题

如果界面上按钮、图片显示不正常，或者交互效果不对，像按钮点不动、图片变形，可能是前端问题，这就好比房子外观装修不对劲。要是数据显示不对，比如本该显示最新订单，却还是旧的，或者操作后数据没正确保存，那可能是后端问题，类似房子内部结构、水电线路出毛病。还可以通过抓包工具看数据传输，前端数据正常发，后端没正确处理，就是后端问题；前端数据发错，就是前端问题。

1.1.133 修复一个BUG 而导致其他的BUG 出现，该如何处理？

这就好比修水管，修好一处却漏了别处。先得赶紧把新冒出来的问题记下来，像给漏水点做标记。然后重新评估之前的修复方案，看看哪里出岔子，是不是改动影响了其他部分。接下来，和开发团队一起商量，重新规划修复办法，要保证新方案不会再引发别的问题。最后，修复完新问题，还得全面复查，确保软件其他地方都没问题，就像修好水管后检查全屋水路。

1.1.134 缺陷处理流程？

缺陷处理就像治病：

发现报告：测试人员像医生发现病症，详细记录缺陷症状、位置等信息，写报告上报。
确认分诊：开发和测试一起会诊，判断是不是真病（缺陷），该分给哪个开发小组治。
修复安排：开发组长安排 “治疗方案” 和时间，开发人员动手修复。
验证复查：测试人员复查，看病治好没，没好就打回重治。
关闭归档：确认治好，缺陷关闭存档，像病人康复出院记录存档。

1.1.135 介绍一下测试整体项目流程？

测试整体项目流程就像盖房子：

了解需求：和 “房主”（产品经理等）沟通，搞清楚房子要啥样，软件要实现啥功能。
制定计划：规划啥时候开工、用啥材料（测试资源），怎么盖（测试方法），确定各阶段时间节点。
设计用例：就像设计施工图纸，想好从哪测、咋测才能找出软件毛病。
搭建环境：准备好 “施工场地”，安装好软件运行所需的软硬件。
执行测试：按 “图纸” 动手测试，像工人按图施工，找问题就记录下来。
跟踪缺陷：督促开发人员 “修补漏洞”，定期看修复进度。
测试总结：房子盖完验收，总结测试情况，为下次 “盖房” 积累经验。

1.1.136 在实际项目中你是如何做测试计划？

做测试计划就像规划一场旅行：

明确目的地：和产品团队聊，搞清楚软件要测啥功能，这就是咱的 “目的地”。
定行程安排：啥时候开始测、每个阶段多久，像确定哪天出发、在哪停留多久。
列所需物品：要多少测试人员，准备啥工具，如同列出旅行要带的东西。
规划路线：先测核心功能，再测边边角角，类似先去主要景点，再逛小众地方。
考虑风险：预估可能遇到的问题，像旅行考虑天气变化，准备应对办法。
分享计划：和团队成员说说，确保大家都清楚要干啥，就像和旅伴沟通行程。

1.1.137 你是如何制定测试过程中的时间进度表的？

制定测试时间进度表，就像规划一场运动会赛程：

明确项目任务：把测试要做的事，像功能测试、性能测试等，都列出来，这是一个个 “比赛项目”。
评估任务时长：根据经验和任务难度，估摸每个测试任务要多久，好比预估每个项目比赛耗时。
确定先后顺序：想想哪些任务得先做，哪些能后做，比如先功能测试没问题了，再性能测试，类似运动会先初赛再决赛。
安排时间节点：给每个任务开始和结束时间定个日子，像确定每个项目比赛日期。
留缓冲时间：赛程里得有点弹性时间，万一有意外状况，测试也留些时间应对突发，比如设备故障。
沟通调整：和团队成员、领导聊聊，看看这进度合不合理，不合适就调整，就像和运动员、裁判商量赛程安排。

1.1.138 测试计划都包括那些项？

测试计划像旅行攻略，包含这些：

目标景点：明确测啥软件功能，类似定好去哪些景点。
行程安排：啥时候开始、结束测试，各阶段时间，好比哪天去哪。
同行伙伴：要多少测试人员，谁负责啥，如同确定同行人员分工。
交通装备：需啥测试工具，类似选啥交通工具。
路线规划：先测啥后测啥，类似规划旅行路线。
风险预案：可能遇啥问题，咋解决，比如考虑天气变化咋应对

1.1.139 bug 有哪些等级？

1.1.140 根据你的经验说说你对软件测试/质量保证的理解？

软件测试就像给软件 “体检”，专门揪出软件里的毛病，像功能不好使、运行会崩溃这些问题。它能让软件在到用户手里前，尽可能把问题解决掉。

质量保证呢，更像是给软件 “把关”，从软件设计开始，一直到最后交付，每个环节都盯着，保证开发过程规范，用的方法靠谱，让软件从 “出生” 就有好质量，确保软件能稳定、好用。

1.1.141 QA 和 QC 的区别是什么？

QA 像工程监理，关注流程。从项目开头就盯着，确保开发按规范流程走，像监督盖楼按标准步骤施工，预防问题产生。

QC 似产品质检员，侧重结果。对开发出的软件进行检测，找功能、性能等方面缺陷，好比检查盖好的楼有没有质量问题。

1.1.142 如何定义所提交bug 的严重等级和优先等级的？

严重等级就看软件 “病” 得多重：

致命：软件直接 “瘫倒”，关键功能全废，像电商 APP 支付功能彻底罢工，没法交易。
严重：主要功能 “受伤”，核心使用受影响，比如视频 APP 播放视频总卡顿，严重影响观看。
一般：功能 “有点小毛病”，但不耽误大局，像 APP 某些页面加载稍慢。
轻微：只是外观这类 “小擦伤”，例如界面文字颜色搭配有点怪。

优先等级看啥时候得 “治病”：

立即解决：严重影响业务，用户急着用的功能出问题，如电商大促时支付故障，必须马上修。
高优先级：影响核心业务，尽快修复，像购物车添加商品失败，得尽快处理。
中优先级：普通功能问题，不着急，有时间就修，比如个人资料修改页面提示语不清晰。
低优先级：不影响使用，有空再弄，比如 APP 角落小图标不太美观。

1.1.143 Web 和 APP 测试的异同有哪些？

相同点

功能测试：Web 和 APP 都得测功能，像注册登录、数据查询，看能不能正常用，好比检查车能不能跑。
兼容性测试：Web 要适配不同浏览器，APP 要适配不同设备，都得保证各种情况下能正常显示和操作，类似车要能在不同路况跑。
性能测试：都关注响应速度、稳定性，页面加载快不快，会不会崩溃，如同看车跑起来顺不顺。
安全性测试：都要防数据泄露、非法访问，像给车加防盗锁。

不同点

平台依赖：Web 靠浏览器，主要测浏览器兼容性；APP 依赖手机系统，要针对不同系统（安卓、iOS）测试，类似不同场地对车的要求不同。
交互方式：Web 多靠鼠标键盘；APP 有触摸、手势操作，像车有不同驾驶方式。
网络环境：APP 在移动网络下使用，要测弱网、网络切换影响；Web 一般在稳定网络，类似车在不同路况行驶。

1.1.144 怎么理解回归测试？是否思考过如何减少回归测试工作量？

回归测试，就像给治好病的人复查，看之前修复的软件问题是不是真好了，有没有新毛病。开发改完 BUG 后，咱得重新测相关功能，确保软件没 “旧病复发” 或 “衍生新病”。

要减少回归测试工作量，有这些招：

自动化测试：能用工具自动测的，别手动，像让机器人帮忙复查，效率高又准确。
精准定位：搞清楚改的代码影响哪些功能，只测这些，不盲目全测，好比看病只查相关部位。
复用结果：之前测试结果能用的，直接拿来参考，别重复劳动，像参考以前病历。

1.1.145 一条软件缺陷（或BUG）包括哪些内容？请完整列出？

一条软件缺陷（BUG）好比一份 “病情报告”，包含：

编号：就像病历号，给缺陷一个独一无二的身份。
标题：简单概括问题，类似 “头痛”，说明哪出状况。
发现时间：啥时候发现的，类似看病时间。
发现人：谁找到的问题，就像报告病情的人。
所属模块：软件哪个部分有问题，像身体哪个部位生病。
严重程度：问题多严重，如 “致命”“严重”，类似病情轻重。
优先级：得啥时候解决，比如 “立即解决”，像看病急诊还是普通门诊。
详细描述：具体症状，怎么操作出现的问题，类似病情详细描述。
重现步骤：别人按这步骤也能复现问题，像告诉医生怎么引发头痛。
预期结果：本该咋样，像正常头不该痛。
实际结果：实际出现啥情况，如头就是痛。
附件：截图、日志等证据，类似看病拍的片子。

1.1.146 单元测试、集成测试、系统测试的侧重点是什么？

单元测试、集成测试、系统测试，就像组装飞机时不同阶段的检查：

单元测试：聚焦零件，侧重检查单个软件组件，像发动机零件，看它功能对不对、逻辑错没错，保证每个零件都能用。
集成测试：关注零件拼接，测组件间接口和交互，像发动机和机翼连接，确保各部分连起来能协同工作。
系统测试：着眼整机，把软件当完整飞机，测功能、性能、兼容性等，看整体是否符合要求，能不能顺利 “起飞”。

1.1.147 怎样才能成为一个优秀的测试工程师？

想当优秀测试工程师，要做到：

火眼金睛：对软件问题超敏感，像福尔摩斯一样，功能不对、性能不佳，都能快速发现。
熟悉业务：了解软件是干啥的，就像熟悉自家房子布局，这样才能全面测试。
技术过硬：掌握各种测试方法和工具，像会用各种检测仪器，准确找出问题。
沟通达人：跟开发、产品团队交流顺畅，有问题好好说，一起解决，别闹矛盾。
善于总结：每次测试完，琢磨咋能测更好，积累经验，下次更厉害。

1.1.148 测试计划要安排哪些方面？

测试计划好比出行规划，要安排这些：

引言：说明为啥要测这软件，类似为啥选这趟旅行，介绍背景目的。
测试内容：确定测软件哪些功能，像定好去景点玩啥项目。
测试规则：明确咋判断软件好不好，啥算通过测试，如同旅行时的游戏规则。
测试环境：准备软件运行条件，像去旅行得挑好天气路况。
项目任务：给测试人员分工，谁测啥，类似旅行团队成员各有职责。
实施计划：规划测试啥时候开始结束，各阶段干啥，如同旅行行程表。
风险管理：预估测试可能遇到的问题，像旅行考虑意外状况，想好咋应对。

1.1.149 为什么要有测试报告？一份日常的测试报告通常需要说明哪些内容？

为啥要有测试报告

测试报告就像体检报告，医生（测试人员）做完检查（测试）得告诉大家（团队成员）软件 “身体状况” 咋样，有没有病（缺陷），好让开发 “治病”，产品经理了解情况做决策。

日常测试报告内容

基本信息：软件名称、版本，测试时间，像体检报告写清是谁啥时候体检。
测试范围：测了软件哪些功能，类似体检都查了哪些项目。
测试结果：功能好不好用，性能达不达标，好比身体各项指标是否正常。
缺陷情况：发现啥问题，严重程度、数量，类似体检查出啥病、病情轻重。
遗留问题：没解决的问题，像体检没治好的病，要继续关注。
结论建议：软件能不能上线，有啥改进建议，类似医生给健康结论和调养建议。

1.1.150 在您参与或负责的项目测试中,发生过哪些棘手的问题,最后是如何解决的?您在这个过程中做了什么?

有次测电商 APP，新功能上线后，支付成功率超低，这问题棘手。

我先详细记录问题表现，不同网络、支付方式下的报错。接着和开发一起抓包分析，发现是支付接口数据传输加密算法更新，和部分银行系统对接出问题。

我们联系银行技术团队，三方沟通确定是加密密钥格式差异。开发调整加密算法，适配银行要求，我重新测试各种支付场景，确认支付成功率恢复正常。

1.1.151 在测试工作中,您常使用的测试方法有哪些?它们都是在什么场景下使用的?

手工测试：
- 场景：功能测试时，像检查 APP 注册登录，点点按钮、填填信息，看功能正常不。新功能刚开发，自动化测试还没搭建好，就靠手工快速测个大概。
自动化测试：
- 场景：重复性高的测试，比如每天检查网站页面加载是不是正常，用工具自动跑，省时省力。项目稳定，需要频繁回归测试，自动化能快速验证修改没影响其他功能。
边界值测试：
- 场景：输入数据有范围限制时，像注册密码要求 6 - 18 位，就测 6 位、18 位及附近数值，看软件会不会出问题。
等价类划分测试：
- 场景：输入数据种类多，把它们分类，每类选代表测。比如年龄输入，分合法成年、合法未成年、非法负数，测这几类就知整体情况。
异常测试：
- 场景：模拟网络中断、断电等异常，看软件咋办。像 APP 在地铁信号不好时，功能会不会错乱，以此提升软件稳定性。

1.1.152 什么是测试用例,设计测试用例时,您常用的设计方法有哪些?应如何设计才能保证测试用例的覆盖率?

测试用例就像是给软件准备的 “考试试卷”，明确了要考软件什么内容以及怎么考，用来判断软件是否合格。

常用设计方法：

等价类划分：把输入数据分类，每类选代表测试。比如注册年龄，可分合法成年、合法未成年、非法负数等类，选几个代表值测试。
边界值分析：关注数据边界，像密码设置 6 - 18 位，测 6、18 及附近数值，看软件是否正常。
场景法：模拟用户实际使用场景，如网购场景，从选商品到支付完成，看流程是否顺畅。

保证覆盖率：

全面梳理功能：列出软件所有功能和特性，确保每个都有测试用例。
多角度思考：从不同用户角色、数据类型、操作顺序等方面设计，避免遗漏。
定期审查更新：项目有变化及时调整用例，新功能添加后补充相关测试点。

1.1.153 黑盒测试主要是为了发现那几类错误?

黑盒测试好比蒙眼挑水果，主要揪出这几类 “坏水果”：

功能缺失：水果该有的味道没有，软件该有的功能没实现，像视频 APP 不能播放视频。
功能错误：水果味道不对，软件功能结果出错，比如计算器算错数。
界面问题：水果卖相不好，软件界面显示错乱，像按钮位置不对。
兼容性毛病：水果在不同地方放坏了，软件在不同设备、系统上出故障，如 APP 在安卓手机闪退。
性能不佳：水果不耐放，软件响应慢、易崩溃，比如网站加载超久。
安全性漏洞：水果被污染，软件数据可能泄露或遭非法访问，像登录密码能被轻易破解。

1.1.154 测试工作的流程?缺陷状态有什么?设计测试用例有几种方法？

测试工作流程

需求分析：和产品团队唠唠，搞清楚软件要干啥，像弄明白要盖啥样的房子。
测试计划：规划啥时候测、谁来测、用啥测，类似规划建房啥时候动工、谁干活、用啥工具。
测试用例设计：想出各种办法测软件，好比设计咋检查房子质量。
测试环境搭建：准备好软件运行的 “窝”，像给房子准备好场地。
执行测试：按计划和用例测软件，找毛病，就像按设计检查房子。
缺陷管理：发现问题记录上报，跟踪修复，类似房子有问题让人来修。
测试总结：总结经验，看看以后咋测更好，像建房结束总结经验下次改进。

缺陷状态

新建：刚发现问题，像刚发现房子有个小裂缝。
打开：问题确认，等开发处理，好比裂缝确认了，通知施工队。
已修复：开发说修好了，类似施工队说缝补上了。
待验证：等测试复查，看修得行不行，像去看看缝补得咋样。
关闭：测试通过，问题解决，好比裂缝修好了没问题。
拒绝：开发觉得不是问题，不处理，类似施工队觉得裂缝不算事儿。

设计测试用例方法

等价类划分：把输入数据分类，选代表测试，比如给年龄分类，选几个年龄测。
边界值分析：关注数据边界，像密码长度限制，测边界数值。
场景法：模拟用户实际操作场景，如网购流程，看软件顺不顺。
错误推测：凭经验猜哪可能出错，重点测，像感觉房子角落易漏雨，多检查。

1.2 需求分析

1.2.1 需求人员需要何时参加需求分析？

需求人员从项目刚开始，就得参加需求分析，就像盖房子，从打算建房那一刻起，就得参与讨论房子要啥样：

初始阶段：项目启动，需求人员要和各方聊，像客户、老板，弄清楚为啥做这软件，大方向是啥，类似明确建房是自住还是商用。
细化过程：随着讨论深入，得把需求一点点细化，每个功能具体啥样，就像确定房子每个房间咋布局。
变动时期：要是项目中途需求有变化，不管是客户提新要求，还是市场情况变了，需求人员都得马上跟上，好比房子盖一半，主人想改格局，需求人员得重新分析。

1.2.2 如果需求一直在变化怎么办？

需求老变，就像盖房子时房主总改想法。咱得这么办：

沟通确认：多和提需求的人唠唠，弄明白为啥变，像问问房主为啥突然要改房间布局，确保理解到位。
评估影响：看看这变化对开发、测试有多大影响，好比算算改格局对工期、成本的影响。
调整计划：根据影响，重新安排时间、人员，像调整建房进度和施工人员分工。
记录跟踪：把每次需求变化都记好，谁提的、啥时候改的，类似记录好房主每次改想法的情况。
团队同步：让开发、测试等所有人都知道需求变了，像通知所有施工人员房间布局改了。

1.3 测试模型

1.3.1 常见测试模型有哪些？

特点：这是一种古老的瀑布模型，反映了实际和测试之间的关系。
局限：仅仅把测试过程作为编码之后的一个阶段，忽视了测试对需求分析,系统设计的验证，如果前面
设计错误，得一直到后期的验收测试才被发现，耗时耗力。

特点：测试与开发同时进行，在V 模型的基础上，增加了在开发阶段的同步测试。
局限：仍然不支持迭代，减少了一定错误发生率，但是需按照流水线进行设计、编码和测试。

V 模型

优点：简单直观，开发与测试阶段一一对应，像建房各步骤与检查环节清晰匹配，易理解和管理，能保证每个开发阶段都有相应测试，质量把控强。
缺点：灵活性差，需求或设计有变动，后续测试调整难，如同房子图纸改了，后面施工和检查全得跟着大动，且测试介入晚，前期问题发现迟。

W 模型

优点：测试与开发并行，需求分析、设计等阶段都有测试介入，更早发现问题，降低修复成本，像边建房边检查，及时纠错。
缺点：虽强调尽早测试，但仍受线性流程限制，对需求频繁变更适应差，变更时协调成本高，类似建房按固定流程，改方案麻烦。

H 模型

优点：高度灵活，测试可在任何就绪点启动，不依赖特定阶段，像随时能对建房某个环节检查，能快速响应需求变更，适应敏捷开发。
缺点：对管理要求高，若无有效管理，易致测试过程混乱，如建房检查没规划，到处乱查，影响效率和质量。

X 模型

优点：重视探索性测试，鼓励测试人员在测试中学习、发现新问题，能挖掘隐藏较深的缺陷，像建房时不断探索新检查点。
缺点：过于依赖测试人员经验和能力，缺乏系统性规划，可能导致测试不全面，如同建房检查全凭个人感觉，容易遗漏关键处。

1.3.2 请根据”V”模型分别概述测试人员在软件的需求定义阶段、设计阶段、编码阶段、系统集成阶段的工作任务及其相应生成的文档？

需求定义阶段
- 工作任务：理解需求，从测试角度提意见，比如问清用户对软件功能的具体期望，像网购 APP 要明确搜索商品、下单等功能细节，确保需求清晰合理，没漏洞。
- 生成文档：《需求评审报告》，记录需求中发现的问题、建议，给开发和需求方参考。
设计阶段
- 工作任务：分析设计文档，看架构、模块划分合不合理，比如研究电商 APP 架构，判断各功能模块交互是否顺畅，为测试计划和用例设计做准备。
- 生成文档：《测试计划初稿》，初步规划测试目标、范围、策略，像确定测哪些功能，用啥方法测。
编码阶段
- 工作任务：设计测试用例，细化测试步骤，比如针对 APP 登录功能，设计输入正确、错误账号密码等各种情况的测试场景。
- 生成文档：《测试用例文档》，详细记录每个测试用例的目的、步骤、预期结果。
系统集成阶段
- 工作任务：按测试用例执行集成测试，检查模块集成后功能是否正常，像测试电商 APP 各功能模块集成后，购物流程能否顺利完成。
- 生成文档：《集成测试报告》，记录测试结果，发现的缺陷及解决情况。

1.4 测试计划

1.4.1 测试计划工作的目的是什么？测试计划工作的内容都包括什么？其中哪些是最重要？

测试计划工作的目的

测试计划就像出行计划，目的是让测试工作有序进行。确保清楚要测啥软件、啥时候测、咋测，避免盲目测试，提高测试效率和质量，保证软件能按时按要求交付，就像按出行计划顺利游玩。

测试计划工作的内容

项目概述：介绍软件是干啥的，类似说去哪旅行，有啥特色。
测试目标：明确测完要达到啥标准，比如软件功能正常、性能达标，像旅行要达到玩得开心、安全归来的目标。
测试范围：确定测软件哪些功能，就像定好旅行要去哪些景点。
测试策略：选择测试方法，如手工还是自动化，类似决定是自驾还是跟团旅行。
测试资源：安排人力、设备，像确定旅行要几个人、用啥交通工具。
进度安排：规划各阶段时间，像制定旅行日程表。
风险评估：预估可能遇到的问题，如软件功能复杂导致测试时间长，类似旅行考虑天气不好等意外。
人员分工：给测试人员分配任务，类似旅行团队成员分工。

最重要的内容

测试范围和目标：这俩是基础，不清楚测啥、要达到啥标准，测试就没方向，好比不知道去哪旅行、想达到啥旅行目的，行程就没法安排。
进度安排和人员分工：关乎测试能否顺利推进，没合理时间规划和分工，工作易混乱，类似旅行没日程和分工，旅行会乱套。

1.4.2 测试计划编写的六要素？

测试计划编写六要素，就像筹备一场运动会：

Why（为什么）：明确为啥要测这个软件，是新功能上线，还是修复漏洞，类似为啥举办运动会，是为了选拔人才还是全民健身。
What（是什么）：确定要测软件哪些功能、特性，像运动会要确定有哪些比赛项目。
When（什么时候）：规划测试各阶段啥时候开始、啥时候结束，比如运动会哪天开幕、各项赛事何时进行。
Where（在哪里）：准备测试环境，软件在哪运行，类似确定运动会在哪个场地举办。
Who（谁来做）：安排谁负责测试工作，哪些人做啥任务，好比确定运动会谁当裁判、谁参赛。
How（怎么做）：选择测试方法，用啥工具、策略，类似决定运动会按什么规则比赛，用什么设备。

1.4.3 项目版本执行过程中，测试人员如何把控测试进度？

测试进度把控就像开车看导航，得这么做：

按计划走：事先定好测试计划，啥时候测啥功能，像规划好开车路线，按计划推进，别跑偏。
紧盯任务：把测试任务细分，明确每个任务的时间节点，就像导航里每个路段预计的通行时间，实时关注完成情况。
及时汇报：发现进度慢了，赶紧告诉团队，像开车堵了及时通知同行的人，一起想办法。
灵活调整：要是需求变了或者遇到难题，合理调整计划，类似前方修路，重新规划路线。
协调资源：缺人手或者工具不好使，赶紧协调解决，好比车没油了得找加油站。

1.4.4 制定测试计划之前需要了解什么问题？

制定测试计划前，得像出门前了解目的地情况一样，搞清楚这些：

软件是啥：弄明白软件要干啥，有啥功能，类似知道要去的地方有啥好玩的。
为啥做它：了解项目目标，为啥开发这软件，像知道为啥选这个目的地旅行。
啥时候要：明确软件啥时候交付，类似确定啥时候必须到达目的地。
给啥人用：搞懂软件面向哪些用户，类似知道去的地方适合啥样的游客。
在哪能用：清楚软件运行环境，像知晓目的地的气候、交通条件。
有啥限制：了解资源、预算方面的限制，类似出门知道带了多少钱、有多少时间。

1.4.5 测试计划都包括哪些项？

测试计划就像旅行规划，得涵盖这些项：

为啥测：说明测试软件的目的，像为啥选这个地方旅行，是新功能上线还是修复漏洞。
测啥：确定要测的软件功能、特性，类似规划旅行要去的景点。
啥时候测：安排各测试阶段的时间，像规划旅行每天的行程。
在哪测：准备测试环境，如软件运行的系统、设备，类似确定旅行住宿、活动场地。
谁来测：给测试人员分工，类似旅行团队成员各司其职。
咋测：选择测试方法和工具，像决定旅行交通方式和携带装备。
啥标准：明确软件通过测试的标准，类似设定旅行满意度标准。
可能出啥问题：预估测试风险及应对办法，像旅行考虑可能遇到的意外和解决措施。

1.4.6 怎样做好测试计划？

做好测试计划，好比筹备一场精彩派对，要做到：

摸透需求：和相关人员充分沟通，像和派对主办方打听清楚目的、主题，明确软件要实现啥，这是基础。
合理规划：安排好测试啥、啥时候测、谁来测。如同规划派对流程、环节及人员分工，确保有条不紊。
选对方法：根据软件特点挑测试方法和工具，就像按派对类型选合适场地布置和娱乐方式，提高效率。
留足弹性：预估可能出现的问题，像派对考虑天气变化等突发状况，提前准备应对策略，方便灵活调整。
团队通气：测试计划要让团队成员都清楚，如同派对安排告知每位参与者，保证大家目标一致。

1.4.7 什么是测试资源？

测试资源就像是打仗的粮草弹药，是保障测试工作顺利开展的各种东西。

包括人力，也就是干活的测试人员，像军队里的士兵；还有物力，像测试工具、软件运行的设备（手机、电脑等），这是打仗的武器装备；另外，时间也算，啥时候完成啥测试任务，如同作战计划的时间安排；甚至知识经验也算，就像军队积累的战术技巧，能帮测试人员更好发现问题。

1.4.8 测试有哪些风险和问题？

测试就像走迷宫，会碰到这些风险和问题：

需求不清：不知道软件到底要干啥，像迷宫没地图，测试方向不明。
时间不够：测试时间紧张，像在迷宫里限时走出，可能漏测功能。
人员不足：干活人手少，一个人跑多个区域，测试难全面。
技术难题：遇到复杂技术，像迷宫里的机关，不知咋测。
环境不稳：软件运行环境老变，像迷宫布局总改，测试结果不准。
缺陷反复：刚修复的问题又出现，像迷宫里的陷阱反复掉进去。

1.5 测试策略

1.5.1 什么是“测试策略”？

测试策略就好比作战计划，是为了把软件测试好，决定采用的一系列方法和手段。比如，是全面细致地查每个功能（类似地毯式搜索敌人），还是重点关注关键功能（类似集中火力攻打要害据点）；是手动一个个去测，还是用工具自动测；啥时候开始测，先测哪些后测哪些。它能让测试工作更有序、高效，像作战计划引导军队打胜仗一样，帮助找到软件里的问题。

1.5.2 测试策略包括哪些？

测试策略好比不同的捕鱼方法，常见的有：

全面测试：像撒大网捕鱼，对软件所有功能、数据、场景全面测，确保无遗漏，但耗时费力。
重点测试：如同专挑大鱼捕，着重测关键功能、高风险模块，快速定位严重问题，适合时间紧情况。
自动化测试：用机器自动捕鱼，借助工具对重复、规律任务自动测，省时省力，适合稳定项目。
探索性测试：像在新水域摸索捕鱼，测试中凭经验找新问题，挖掘隐藏较深缺陷。
基于风险测试：先找最危险鱼群，优先测风险高的部分，根据风险高低分配资源。

1.5.3 系统测试的策略有哪些？

系统测试策略，就像不同的看病套路，用来给软件系统全面体检：

功能遍历：一个一个检查软件功能，像医生挨个查身体器官功能，确保每个功能都正常。
性能摸底：看看软件在各种压力下的表现，类似测一个人在高强度运动时的体能，看会不会 “累垮”。
兼容性排查：试试软件在不同环境下能不能用，好比看看一个人在不同气候地区能不能适应。
安全扫描：找找软件有没有安全漏洞，像给房子查防盗措施，防止数据泄露等问题。
易用性体验：站在用户角度感受软件好不好用，类似体验看病流程方不方便。

1.6 测试类型

1.6.1 请列出你所知道的软件测试种类，至少5 项？

1.6.2 黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系？

想象软件是一辆组装好的汽车：

黑盒测试：不看汽车内部构造，只从外部看它能不能跑、灯亮不亮、喇叭响不响，关注整体功能，像普通用户开车体验。
白盒测试：打开汽车引擎盖，研究内部零件怎么运作，测试内部代码逻辑，类似修车师傅检查发动机构造。
单元测试：把汽车一个个小零件，比如螺丝、齿轮拿出来单独检查，确保零件质量，是针对单个代码模块的测试。
集成测试：把检查好的零件组装成发动机、底盘等部件，看看这些部件组合起来能不能正常工作，是对模块间接口和集成功能的测试。
系统测试：把所有部件组装成完整汽车，在各种路况（不同环境）下开，测试整体功能、性能等，类似汽车出厂前全面检测。
验收测试：用户亲自试驾，看这车是不是自己想要的，满足需求就收货，是用户确认软件是否符合要求的测试。

联系上，单元测试是基础，先保证零件质量；接着集成测试，确保部件组装正常；再系统测试，检验整车情况；最后验收测试，由用户拍板。黑盒、白盒测试方法可用于各个阶段，黑盒关注外在表现，白盒深入内部逻辑。

1.6.3 黑盒测试和白盒测试常用的测试方法有哪些，举个例子？

黑盒测试

等价类划分：把输入数据分类，挑代表测试。比如注册账号，密码要求 6 - 18 位，就分小于 6 位、6 - 18 位、大于 18 位三类，分别选 5 位、8 位、20 位密码测试。
边界值分析：关注数据边界情况。还是注册密码，除了用边界值 6 位和 18 位，还测临近值 5 位、7 位、17 位、19 位。
场景法：模拟用户实际操作流程。以网购为例，模拟选商品、加购物车、下单、支付整个流程，看是否顺畅。

白盒测试

语句覆盖：让测试用例能执行到程序的每一条语句。比如一段简单代码判断数字奇偶性，写个测试用例输入奇数，再写个输入偶数，就覆盖了判断奇偶数的不同语句。
判定覆盖：使测试用例能让程序中每个判断的取真和取假分支至少执行一次。像判断用户登录，用户名密码正确登录成功，用户名或密码错误登录失败，两种情况都测到，就实现判定覆盖。

1.6.4 简述黑盒测试和白盒测试的优缺点？

黑盒测试

优点：
- 贴近用户：像顾客只看商品好不好用，不关心咋生产，能从用户角度找问题，发现软件功能上的毛病。
- 无需代码知识：测试人员不用懂代码，只要知道软件干啥，就能上手测，上手快。
- 全面覆盖：能无死角测各种输入输出组合，像检查商品所有功能，确保功能完整性。
缺点：
- 难定位问题：发现软件有毛病，可不知是哪段代码出问题，像商品坏了，但不知是生产哪环节出错。
- 测试用例多：要覆盖各种情况，得写好多测试用例，费时间精力，像检查商品每个细节，工作量大。

白盒测试

优点：
- 精准定位：能深入代码内部，像医生用仪器查身体，精确找到代码逻辑错误，方便开发修复。
- 优化代码：测试时能发现代码冗余、结构不合理处，帮助开发优化代码，让软件更高效。
缺点：
- 依赖代码知识：测试人员得懂代码，像医生得懂人体构造，门槛高，不是谁都能干。
- 忽略整体功能：太专注代码逻辑，可能忽略软件整体功能是否符合用户需求，像只关心零件，不管商品整体好不好用。

1.6.5 在没有产品说明书和需求文档的情况下能够进行黑盒测试的设计吗？

就算没有产品说明书和需求文档，也能搞黑盒测试设计，就像没有菜谱也能做菜。

办法

参考类似产品：看看同类软件，了解大概该有啥功能。比如测新音乐 APP，参考其他热门音乐 APP，像播放、下载、创建歌单这些功能大概率都得有，就针对这些功能设计测试。
找相关人员打听：问开发、市场人员，或者潜在用户，了解软件大概用途和核心功能。比如问市场人员，这款新电商 APP 主打啥商品、面向啥用户，从而确定测试重点。
亲自摸索软件：自己上手操作软件，像第一次用新东西，看看有哪些界面、按钮能点，能完成啥操作。就像玩新游戏，边玩边发现可玩的内容，以此设计测试用例。

不过，没有产品说明书和需求文档，就像做菜没菜谱，心里没底，可能会遗漏重要功能的测试，所以要是能补上这些文档，测试会更靠谱。

1.6.6 单元测试的策略有哪些，主要内容有哪些？

单元测试策略

孤立测试：像把每个零件单独拿出来检查，只关注单个模块，不管和其他模块的关系，专注测这个模块自身功能，快速发现模块内部问题。
自顶向下：好比搭积木从最上面开始，先测高层模块，逐步向下测底层模块。先验证主要功能框架，再深入细节，能较早发现模块间接口问题。
自底向上：和自顶向下相反，从底层模块开始测，像搭积木先搭好底部基础。底层模块测好后，为上层模块测试提供稳定基础，减少测试依赖。

主要内容

功能测试：检查模块功能对不对，就像检查零件能不能实现它该有的作用。比如一个计算模块，测它加减乘除运算结果是否正确。
边界测试：看看模块在边界情况下咋样，类似检查零件在极限条件下的表现。比如输入数据范围是 1 - 100，测 1、100 以及临近值 0、101 时模块的反应。
异常测试：试试模块遇到异常情况咋办，好比看零件碰到突发状况能不能应对。像给模块输入错误数据类型，看它会不会报错或崩溃。

1.6.7 简述集成测试的过程？

集成测试就像组装乐高，过程如下：

准备工作：好比准备好乐高零件和图纸。先确定要集成哪些模块，准备好测试环境、工具，像搭乐高要先找好场地、备好工具。
模块组装：开始把小模块像乐高块一样拼起来。按设计要求，从简单组合到复杂，比如先把几个基础功能模块集成，再逐步加入更多模块。
接口测试：检查模块连接的地方，就像看乐高块拼接处是否紧密。测试模块间数据传递、调用是否正常，确保接口不出错。
功能测试：看看组装好的部分功能全不全、正不正常，类似检查拼好的乐高造型功能对不对。比如集成了支付和订单模块，测试下单支付流程能否完成。
问题修复与复测：要是发现问题，就像乐高拼错了拆掉重拼。开发人员修复，测试人员再重新测，直到集成部分稳定、符合要求。

1.6.8 集成测试进入的准则？退出的准则？

集成测试进入准则

模块完工：每个要集成的模块得像造好的零件，代码编写完成，且通过单元测试，确保单个模块质量合格。
文档齐全：要有类似建筑图纸的文档，像详细设计文档、接口文档，明确模块咋组装、接口咋用，为集成测试指引方向。
环境就位：测试环境得准备好，软硬件条件都得有，好比搭建好舞台，让模块在上面 “表演”。

集成测试退出准则

测试达标：按计划写的测试用例都执行完，像剧本里的戏都演了，而且覆盖到所有接口和关键场景，确保无遗漏。
缺陷处理：发现的缺陷得处理好，严重的马上解决，轻微的评估后决定咋处理，像房子漏雨得修好，小瑕疵也得有说法。
结果达标：集成后的功能、性能都得符合要求，像组装好的机器得能正常稳定运行。

1.6.9 集成测试通常都有那些策略？

集成测试策略，就像不同的拼图方法，各有特点：

大爆炸集成：把所有模块像一把拼图全倒出来，一次性拼在一起测试。简单直接，但出问题难定位，适合模块少且简单的情况。
自顶向下集成：如同从拼图的顶部开始拼，先集成主控制模块，再逐步向下添加子模块。能较早验证系统框架，但底层模块可能需桩模块辅助，增加复杂度。
自底向上集成：从拼图底部一块块往上拼，先集成底层模块，再向上集成高层模块。测试时可利用真实模块，减少桩模块使用，但要到后期才能看到整体架构。
三明治集成：结合自顶向下和自底向上，先分别测试顶层和底层，再从两头往中间集成，像做三明治，兼具两者优点，减少测试成本。
核心系统先行集成：先挑最重要、最核心的模块拼图，像先拼出拼图的关键图案，再围绕它集成其他模块，能快速验证核心功能，适用于核心功能突出的项目。
高频集成：像拼图拼几块就检查一下，频繁地将新完成的模块集成并测试，及时发现问题，适合敏捷开发，让开发与测试紧密配合。

1.6.10 设计系统测试计划需要参考哪些项目文挡？

设计系统测试计划，好比盖房子参考各种图纸，要用到这些项目文档：

需求规格说明书：像房子的设计蓝图，写明软件要实现啥功能，有啥性能要求，帮确定测试范围和重点。
概要设计文档：类似房子的整体框架图，展示软件架构、模块组成及关系，便于规划测试策略，了解模块如何协同工作。
详细设计文档：如同房子的细节施工图，对模块内部设计和接口详细说明，有助于设计具体测试用例，关注模块功能实现细节。
项目计划：像施工进度表，明确项目各阶段时间安排，让测试计划与之匹配，确保测试进度合理。
用户文档：类似房子的使用说明，介绍软件操作方法和用户场景，从用户角度确定测试场景，保证软件易用性。

1.6.11 系统测试计划是否需要同行审批，为什么？

系统测试计划需要同行审批，就好比建房图纸要经其他行家看看。

原因

查漏补缺：自己写计划可能有遗漏或考虑不周的地方，同行从不同视角能发现问题。比如你规划测试网络购物流程，同行可能提醒你遗漏了促销活动期间的特殊情况测试。
确保可行：同行有类似经验，能判断计划里的测试方法、时间安排等是否现实。像你打算一天测完复杂系统所有功能，同行会指出这不切实际。
统一标准：保证测试计划符合团队或行业标准。如同建房要符合建筑规范，同行审批确保计划遵循大家认可的规则。
促进协作：审批过程大家交流想法，增进对测试计划的理解，方便后续协作。就像建房前大家对图纸达成共识，施工时配合更默契。

1.6.12 系统测试阶段低级缺陷较多怎么办？

系统测试阶段低级缺陷多，别慌，按这几步走：

揪出源头：和开发团队一起找为啥低级缺陷多。是需求没搞懂，像没看清地图走错路；还是开发粗心，像做题不细心算错数；又或是代码审查马虎，类似考试没检查出错误。
加强管控：如果是需求问题，重新梳理明确，确保大家理解一致；要是开发粗心，制定规范，多检查几遍；代码审查不严格，就加强审查力度，像给试卷多安排几次批改。
提升能力：给开发和测试人员培训，补补相关知识技能。比如数据校验老出错，就专门培训数据校验方法，像学生哪科弱就补哪科。
总结复盘：把这些低级缺陷整理分析，以后测试前多注意，像整理错题集，考试前多看看，避免再犯。

1.6.13 系统测试的进入和退出准则？

系统测试进入准则

搭建好 “舞台”：软硬件环境得准备齐全，就像演出前舞台布置好，保证软件能在设定环境运行。
模块 “零件” 合格：各个模块都通过集成测试，像所有零件都单独检查没问题，确保基础质量。
有 “施工蓝图”：需求、设计等文档得完备，如同建房有详细图纸，明确测试范围和要求。

系统测试退出准则

完成 “考试”：测试用例全执行完，像试卷题目都做完，且覆盖各种场景。
解决 “错题”：发现的缺陷按严重程度分级处理，严重问题修复，轻微问题评估影响，类似考试错题纠正，难题重点解决。
达到 “标准”：软件功能、性能达标，符合需求规格说明，好比学生成绩达到及格线。

1.6.14 系统测试包含哪些方面？

系统测试就像给软件做全面体检，包含这些方面：

功能测试：检查软件功能齐不齐全、正不正常，好比检查人能不能正常走路、吃饭，像购物软件得能正常下单、支付。
性能测试：看看软件在各种压力下的表现，类似测人在长跑时的体能，像多人同时登录软件，看它会不会变慢或崩溃。
兼容性测试：试试软件在不同环境能用不，就像看一个人在不同气候地区能否适应，如不同浏览器、操作系统下软件功能是否正常。
安全测试：找找软件有没有安全漏洞，像给房子检查防盗措施，防止数据泄露、非法访问等问题。
易用性测试：站在用户角度感受软件好不好用，类似体验看病流程是否方便，比如界面是否简洁易懂、操作是否便捷。

1.6.15 什么是验收测试？

验收测试就好比买东西时的最终验货。软件做好后，用户或相关方亲自查看，看软件是不是和之前说好的一样，功能全不全、好不好用，符不符合需求。只有通过验收测试，这软件才能正式 “收货” 投入使用。

1.6.16 软件验收测试具体包括哪些测试？

软件验收测试，就像给软件 “验货”，有这些测试：

功能验收：检查软件功能是不是和说好的一样。比如外卖软件，得能正常下单、跟踪配送，像买手机得能正常打电话、发短信。
性能验收：看看软件在实际使用中有啥表现。人多同时用会不会变慢，像高峰时段电梯挤了很多人，运行还顺不顺畅。
兼容性验收：试试软件在不同环境能不能用。不同手机、电脑、浏览器上都得好使，类似不同插座，电器都能插上用。
易用性验收：站在用户角度，感受软件好不好上手。界面清不清楚，操作麻不麻烦，像用新家电，一看就知道咋用。
文档验收：检查相关说明文档齐不齐全。使用手册、安装指南得有，像买家具，得有组装说明书。

1.6.17 什么是功能测试？

功能测试，就像检查玩具好不好使。拿到一个软件，按它该有的功能一项项试。比如音乐软件，看能不能播放、暂停、切歌，像检查玩具车能不能跑、转弯，确保软件功能和设计的一样，能满足用户基本使用需求。

1.6.18 请问功能测试和性能测试的区别是什么？

功能测试和性能测试，就像考察运动员的两个方面：

功能测试：看运动员会不会各项技能，像检查篮球运动员会不会投篮、传球。对应软件，就是测试软件功能能不能实现，比如购物软件，看能不能正常加购、下单。只要功能能用，就过关。
性能测试：看运动员在高强度比赛中的表现，比如篮球运动员在激烈对抗、长时间比赛时，体能、命中率等情况。对软件来说，是测试在高压力场景下，像大量用户同时使用时，软件的响应速度、稳定性等，会不会变慢、崩溃。

1.6.19 什么是兼容性测试？

兼容性测试，就好比检查一把钥匙能不能开多把锁。软件得在不同环境下都能正常用，像不同的手机型号、电脑系统、浏览器，就如同不同的锁。看看软件在这些 “锁” 里，功能是否正常，会不会出现乱码、闪退等问题。

1.6.20 什么是易用性测试？

易用性测试，就是站在用户角度，看软件好不好用。好比买了个新电器，一看说明书或摆弄几下，就能轻松上手，操作起来顺手、舒服，那这电器易用性就好。软件也一样，界面简洁易懂，功能按钮好找，操作流程不复杂，用户体验感棒，就说明软件易用性佳。

1.6.21 什么是文档测试？

文档测试，就像是检查产品说明书靠不靠谱。软件配套文档，像使用手册、安装指南等，得准确、完整、易懂。比如安装指南，要按步骤能顺利装上软件；使用手册，得把功能讲明白，不然就像说明书含糊，让人不知咋用产品。

1.6.22 怎么做好文档测试？

要做好文档测试，记住这几点：

看全不全：像检查购物清单，文档该有的内容，像安装说明、操作指南、常见问题解答，一个都不能少。
查准不准：好比核对菜谱配料，文档里的信息，像功能描述、步骤顺序，必须和软件实际情况相符。
瞧懂不懂：当作给老人写短信，文字简单直白，别用生僻词，排版清晰，让人一看就明白。
审连不连：仿佛检查链条，文档各部分内容逻辑连贯，不能前面说东后面说西。
对格式：类似整理书架，格式统一规范，字体、字号、缩进都得整齐。

1.6.23 文档测试要注意什么？

文档的读者群、文档的术语、文档的正确性、文档的完整性、文档的一致性、文档的易用性、样例与示例、文档的语言。

1.6.24 什么是安全测试？

安全测试就像给软件 “加固防盗门”。要检查软件有没有漏洞，会不会被坏人钻空子，比如防止黑客窃取用户数据、非法访问系统，确保软件在各种安全威胁下，能像坚固的房子一样，保护好内部信息和功能安全。

1.6.25 怎么做安全测试？用什么工具？有什么优缺点？

怎么做安全测试

找漏洞：像侦探找线索，用工具扫描软件代码和系统，找可能被攻击的地方，比如 SQL 注入、跨站脚本漏洞。
权限测试：看看不同用户权限对不对，好比检查不同人钥匙能不能开对门，普通用户不能有管理员权限。
数据保护：检查数据传输和存储安不安全，像确认快递包裹会不会丢件，加密的数据不能轻易被破解。

常用工具及优缺点

Nessus
- 优点：扫描能力强，像厉害的探测器，能发现各种漏洞，覆盖范围广，大中小型系统都适用。
- 缺点：结果报告复杂，像专业医学报告，非专业人士难读懂，配置和使用有点复杂。
OWASP ZAP
- 优点：开源免费，适合预算少的团队，像免费的得力助手，操作简单，容易上手。
- 缺点：对复杂环境扫描深度不够，像浅尝辄止的食客，可能遗漏一些隐蔽漏洞。
AppScan
- 优点：专注 Web 应用安全，像 Web 领域的安全专家，功能全面，扫描精准度高。
- 缺点：价格贵，像豪华跑车，成本高，对系统资源消耗大。

1.6.26 什么时候适用自动化测试？

自动化测试适用场景，记住这几类：

重复多的任务：好比反复搬砖，像每天多次登录系统的测试，机器做比人工快且准。
大数据量：如同处理海量文件，要输入大量数据测试，自动化测试能快速完成。
持续集成：类似接力赛，开发不断更新代码，自动化测试随时跟上检测问题。
性能压力：好比模拟马拉松比赛，测试软件在高压力下表现，自动化可精准模拟大量用户并发。

1.6.27 什么时候不宜使用自动化的情况？

以下情况不适合自动化测试：

项目急，时间少：好比火烧眉毛，马上要交成果，自动化测试搭建慢，来不及。
测试只做一次：就像只吃一顿饭，没必要买个高级厨具，手工测更省事。
需求老变：好比总改图纸的房子，自动化脚本老得跟着改，成本高。
环境不稳定：像地基不稳的楼，每次测试环境不一样，自动化难跑出靠谱结果。
探索性测试：如同探险，事先不知道会发现啥，人工灵活测试更合适。

1.6.28 什么是性能测试？

测试，就像给软件 “跑马拉松”。看看软件在大量用户同时使用，或长时间运行时，速度快不快、稳不稳。比如网购软件，大促时多人抢购，不卡顿、不崩溃，才说明性能好。

1.6.29 您在从事性能测试工作时，是否使用过一些测试工具？如果有，请试述该工具的工作原理，并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的？

我用过 LoadRunner 做性能测试。它就像个 “软件健身房教练”，能模拟超多 “虚拟用户” 去使用软件，看软件在压力下的表现。

工作原理：

虚拟用户生成：LoadRunner 把要测试的业务流程，像登录、下单等，变成一个个 “剧本”，让虚拟用户照着演。这些虚拟用户能模拟真实用户在软件上的操作。
场景设置：好比安排一场比赛，你可以设定虚拟用户啥时候入场（并发数量、加载时间），怎么跑业务流程，模拟出各种真实使用场景。
数据收集与分析：虚拟用户在 “表演” 过程中，LoadRunner 就像个记录员，收集软件的各种数据，像响应时间、吞吐量等，最后分析这些数据，告诉你软件性能咋样。

实际应用例子：
之前测试一个电商 APP。我们用 LoadRunner 模拟 “双 11” 抢购场景。先把用户从打开 APP、搜索商品、加入购物车到下单支付的流程录制成脚本。然后设置场景，让 1000 个虚拟用户同时登录 APP，500 个用户并发加入购物车，300 个用户同时下单。运行测试后，LoadRunner 收集到下单操作平均响应时间从平常的 2 秒飙升到 10 秒，系统吞吐量也明显下降。这就表明系统在高并发下性能不足，开发团队根据这些数据优化代码，再次测试后，响应时间缩短到 5 秒，性能得到显著提升。

1.6.30 您认为性能测试工作的目的是什么？做好性能测试工作的关键是什么？

性能测试目的

性能测试就像给软件做 “体能检测”，目的有仨：

看稳不稳：瞧瞧软件在多人同时用，或者长时间运行时，会不会像累垮的运动员一样崩溃、出错，确保它能稳定 “服役”。
测速度：好比给运动员掐表，看看软件响应速度快不快，操作后能不能马上出结果，别让用户等太久。
找瓶颈：如同找出运动员哪部分体能弱，发现软件在啥情况下性能会变差，方便开发团队优化。

做好性能测试关键

懂业务：得像熟悉运动员比赛项目一样，了解软件是干啥的，常见使用场景有哪些，这样测试才贴合实际。
准模拟：尽可能逼真地模拟真实使用情况，像模拟比赛现场压力，多考虑用户数量、操作频率这些因素。
会分析：拿到测试数据，要像教练分析运动员表现一样，找出性能问题根源，给开发团队提供有用建议。

1.6.31 性能测试什么时候开始最合适？

性能测试好比给车做高速路试驾，最合适在这时候：

软件功能基本稳定，像车的零部件都安装妥当，不会老掉螺丝。不然边修功能边测性能，就像车还在组装就上高速，结果没意义。

开发完成集成测试，各模块像车的各部件已组装好且能协同运作，这时测性能，能看到整体表现。太早，车还没成型，测不出啥；太晚，有问题再改，成本就高啦。

1.6.32 并发性能测试的目的主要体现在三个方面？

并发性能测试，好比看一群人同时进商场，目的有仨：

查响应：看看软件像商场服务，人多了回应快不快，操作后多久出结果，别让用户干等。
测稳定：瞧瞧软件在多人同时用的压力下，会不会像人多商场出故障，会不会崩溃、报错。
找瓶颈：找出软件在哪方面像商场设施不够用，哪部分性能撑不住，方便优化改进。

1.6.33 Jmeter做性能测试流程？描述一个具体性能测试案例使用Jmeter进行性能测试？

Jmeter 做性能测试流程

搭场景：就像布置舞台，添加线程组设定虚拟用户数、并发数等。
设请求：好比写好台词，添加 HTTP 请求等，明确要测的接口信息。
加监听：如同安排观众，添加聚合报告等监听器来收集测试数据。
跑测试：让 “演员”（虚拟用户）开始表演，运行测试计划。
看结果：根据监听器的数据，像看演出反馈，分析软件性能。

具体案例

要测一个新闻 APP 的新闻列表接口。

搭场景：在 Jmeter 里建线程组，设 100 个虚拟用户，10 秒内全部启动，循环 5 次。
设请求：添加 HTTP 请求，填好新闻列表接口的 URL、请求方法、参数等。
加监听：添加聚合报告、图形结果监听器。
跑测试：运行测试计划，Jmeter 模拟 100 个用户不断请求新闻列表。
看结果：从聚合报告看平均响应时间、吞吐量等，若响应时间长、吞吐量低，说明接口性能有问题。

1.7 测试流程

1.7.1 软件测试的基本流程有哪些？

软件测试基本流程分四步：

测前准备：熟悉软件功能、业务，备好测试环境、数据，就像打仗备粮草。
设计用例：想好咋测软件，写清输入输出和预期结果，好比列菜谱。
执行测试：按用例操作软件，记录结果，找出缺陷，如同照菜谱做菜尝味道。
总结报告：整理结果，写报告反馈问题，为软件优化指方向，似战后总结。

1.7.2 测试结束的标准是什么？

测试结束就像一场考试交卷，有这些标准：

用例跑完：所有测试用例都执行过，像做完试卷每道题。
缺陷搞定：严重缺陷都修复，一般问题改得差不多，小毛病不影响使用，如同试卷错误基本改正。
符合要求：软件性能、功能等达到预先定的标准，好比成绩达到及格线。
时间到点：在计划时间内完成，若没新严重问题就结束，就像考试时间截止。

1.7.3 软件测试的原则是什么？

软件测试有这几个原则：

尽早测试：就像早发现树苗歪了早扶正，开发时就开始测，早揪出问题。
重点突出：别眉毛胡子一把抓，像找宝藏先去概率大的地儿，测关键功能和模块。
全面覆盖：每个角落都瞅瞅，像打扫屋子旮旯也不能放过，各种输入、场景都要测。
避免自测：自己难挑自己刺，软件开发者别自己测自己写的，找别人更客观。
缺陷统计：记好发现的问题，像记错题本，方便分析原因改进软件。

1.8 用例设计

1.8.1 什么是测试用例，测试用例的基本要素？

什么是测试用例

测试用例就像做题的 “参考答案模板”。在软件测试里，它是为了检验软件是否能正常工作而精心设计的一组输入数据和对应的预期输出结果。通过执行测试用例，就能知道软件有没有问题。

测试用例基本要素

编号：每个测试用例都有专属 “身份证号”，方便管理和查找。
标题：简单概括测啥，让人一眼明白测试内容，就像文章标题。
测试项目：明确测软件哪个功能模块，比如登录模块、支付模块。
测试条件：执行测试的前提，好比做实验要先准备好环境，如网络正常、账号已注册。
输入数据：给软件的 “题”，像登录时输入的账号密码。
操作步骤：说明咋操作软件，一步一步来，像按菜谱做菜。
预期结果：做完测试应有的结果，是判断软件对错的标准，如登录成功跳转到主页。

1.8.2 怎样写测试用例?

写测试用例就像写游戏攻略，按这几步来：

定目标：明确要测软件的啥功能，像游戏要闯哪关。
想场景：考虑各种使用情况，正常用、输错数据、极端条件，好比游戏里的不同关卡。
列步骤：一步步写清咋操作软件，像攻略的操作指南。
写输入：确定操作时输入啥，如账号密码。
设结果：预想操作后软件该有的反应，对不对一眼便知。
编编号：给每个用例一个号，方便管理查找。

1.8.3 描述测试用例设计的完整过程？

测试用例设计就像做一套试卷，过程如下：

熟悉需求：先读懂软件要实现啥功能，好比看清考试范围。
拆分功能：把软件功能分成小块，像把试卷按题型划分。
选方法：用等价类划分、边界值分析等方法设计题，如确定每类题型的出题思路。
写用例：明确每个测试用例的输入、操作步骤和预期结果，就像写出每道题的题干、答题步骤和答案。
评审用例：大家一起检查用例合不合理，如同老师审核试卷。
更新完善：根据反馈修改用例，就像调整试卷题目。

1.8.4 好的测试用例有哪些特点？

好的测试用例就像好的猎手，具备这些特点：

目标明确：清楚测软件哪功能，像猎手瞄准猎物。
覆盖全面：各种情况都测到，好比撒大网捕鱼。
步骤清晰：操作咋做一目了然，似导航指路。
结果可判：预期结果明确，能快速知软件对错，如考试有标准答案。
独立性强：每个用例互不干扰，像独立作战的士兵。
简洁高效：不啰嗦，能快速执行，像快刀斩乱麻。

1.8.5 测试用例制定的原则？

制定测试用例，遵循这些原则：

全面覆盖：要像给房子做全面体检，软件各种功能、场景都得测到。
重点突出：不能眉毛胡子一把抓，关键功能多设计用例，就像重点照顾身体重要器官。
独立可判：每个用例都能单独运行，结果好坏一看便知，好比单人比赛胜负分明。
简洁高效：步骤别太复杂，快速执行出结果，像快递高效送达。
可重复用：今天测能用，明天测还能用，避免重复劳动，如工具可反复使用。

1.8.6 测试用例是否纳入测试基线管理？测试用例发生变更的流程？测试用例如何进行标识？

是否纳入测试基线管理

测试用例要纳入测试基线管理。就像画画得先有个底稿，测试基线是稳定版本，把确定好的测试用例放进去，后续改和测都有标准，避免混乱。

变更流程

提申请：发现要改，填变更申请表说清为啥改。
做评估：专家评估变更影响，如对进度、成本等影响。
获批准：领导同意才能改。
改内容：按要求修改测试用例。
再评审：大家一起检查改得对不对。
更新库：评审通过后，把新测试用例放库里，旧的标记。

标识方法

编号：每个测试用例有唯一编号，像身份证，按规则编方便找。
状态标记：标上新建、执行中、已完成等状态，快速了解进度。
版本号：改一次加个版本号，清楚版本迭代。

1.8.7 什么时候编写测试用例？依据是什么？如何保证测试用例与需求的一致性？需要同行评审吗？

编写时间

需求明确、功能稳定时就开始写，好比房子设计图定了，就着手列装修步骤。

编写依据

以软件需求文档为蓝图，像做菜按菜谱来，明确功能、性能等要求。

保证一致性

写完用例和需求逐条核对，让开发讲功能，测试按此写用例再对比。

是否同行评审

要同行评审。就像多人一起审核装修方案，不同视角找问题，确保用例合理可行、贴合需求。

1.8.8 测试用例如何设计的？举个案例说明设计了那些测试用例？

测试用例设计方法

先熟悉软件功能和需求，像了解游戏规则。再用等价类划分（把输入分有效和无效组）、边界值分析（测边界情况）等方法，设计出覆盖各种情况的测试用例。

案例：登录功能测试用例

以一个 APP 登录功能为例：

有效等价类用例
- 输入正确手机号和密码，点击登录，预期成功登录进入主页。
- 手机号和密码用全数字、字母、符号组合，登录成功。
无效等价类用例
- 输入错误手机号，密码正确，提示手机号有误。
- 手机号正确，输错密码，提示密码错误。
- 手机号为空，提示请输入手机号。
- 密码为空，提示请输入密码。
边界值用例
- 手机号用最短和最长合法位数，看能否登录。
- 密码用最短和最长允许长度，测试登录情况。

1.8.9 如何保证用例覆盖到罕见缺陷？举个案例说明自己怎么覆盖到罕见缺陷的？

保证覆盖罕见缺陷方法

脑洞大开想场景：突破常规，想些稀奇古怪的使用情况和极端条件。
数据 “乱来” 测试：用一些不常见、不规则的数据去测软件。
历史经验参考：看看之前类似软件出过啥罕见问题，在新测试里加上对应用例。
多人一起琢磨：大家集思广益，不同视角发现更多可能。

案例

测一个电商 APP 商品搜索功能，常规用例测着没问题。后来想到可能有人会用生僻字和特殊符号组合搜索，就加了像 “★卍囧商品名★卍囧” 这样的用例，结果发现 APP 崩溃了。原来是代码没处理好特殊字符，这罕见缺陷就被覆盖到啦。

1.8.10 写测试用例时要注意什么问题？举个案例说明自己在写测试用例的时候注意了那些问题？

写测试用例注意事项

目的清晰：清楚每个用例要测啥功能，别模糊。
覆盖全面：各种正常、异常场景都考虑到。
步骤明确：操作步骤一步步写清楚，让人能照着做。
结果可判：预期结果要明确能判断对错。
独立无扰：每个用例别相互影响。

案例

测某视频 APP 播放功能，写用例时，明确用例目的是测不同格式视频播放情况。覆盖正常格式（MP4）和罕见格式（AVI）播放场景。步骤详细写清从打开 APP 到选择视频播放的操作。预期结果定好不同格式播放是否正常、有无卡顿。还保证每个用例可独立运行，避免前面播放操作影响后面测试，最终高效完成测试。

1.8.11 如何在有限的情况下提高测试效率，保证产品的上线质量？

提高测试效率保证上线质量的方法

抓重点：先测核心功能和关键模块，就像先盖房子主体。比如电商 APP，优先测商品搜索、下单支付。
挑工具：用自动化测试工具，像用机器代替人工快速干活。例如用 Selenium 测网页功能。
借经验：参考以前类似项目问题，提前设用例，少走弯路。
巧合作：测试和开发、产品及时沟通，有问题马上解决。
做复用：把常用测试用例、脚本存好，下次直接用。

1.8.12 如何降低漏测率？

降低漏测率，可这么做：

用对方法：等价类划分、边界值分析等方法结合用，像用不同网眼的网捕鱼，覆盖各种情况。
多轮测试：初测、复测、回归测，像反复检查作业，不放过问题。
积累经验：参考老项目缺陷，提前布防，像打疫苗防疾病。
团队协作：测试、开发、产品多交流，不同视角找问题，像多人一起找宝藏。
借助工具：用自动化工具和测试管理工具，提升效率和准确性，像用放大镜找细微瑕疵。

1.8.13 测试用例的基本设计方法（等级类划分法，边界值分析法，错误推断法，因果图判定表法，正交实验法，流程法，场景法）？分别对每种设计方法进行举例说明？

等价类划分法

把输入数据分有效和无效等价类，测代表值就行，省时间。
例：登录框输用户名，长度 3 - 15 字符为有效等价类，取 5 字符测；小于 3 或大于 15 为无效等价类，取 2 和 16 字符测。

边界值分析法

重点测边界值，软件边界易出错。
例：年龄输入框限制 18 - 60 岁，测 17、18、19、59、60、61 这些边界和临近值。

错误推断法

凭经验猜可能出错地方来设计用例。
例：电商 APP 支付，根据经验，余额不足、网络中断时易出错，就针对这些设计用例。

因果图判定表法

分析输入条件因果关系，用判定表列出组合和结果。
例：申请信用卡，年龄超 18、有稳定收入才能通过。年龄超 18 是因，有稳定收入是因，通过申请是果。列出四种因果组合及对应结果来设计用例。

正交实验法

用正交表挑部分有代表性组合测。
例：测网页颜色、字体、图片大小对用户体验影响，每种因素有几种取值，用正交表选少量组合测试。

流程法

按软件业务流程设计用例。
例：在线购物，按浏览商品、加入购物车、结算、支付、收货评价流程设计用例。

场景法

模拟用户使用场景设计用例。
例：社交 APP，模拟新用户注册登录、添加好友、发动态、聊天场景来设计用例。

1.8.14 测试为什么要写测试用例？

测试写测试用例，好处多多：

测有方向：就像有地图，明确要测啥功能、咋测，不盲目。
避免遗漏：覆盖各种场景，像撒大网，让问题无处逃。
方便协作：团队成员一看就懂，像按剧本演戏，配合更默契。
结果可判：有预期结果作标准，快速判断软件好坏。
重复可用：以后再测或版本更新，拿出来就能用，省时间。

1.9 缺陷Bug

1.9.1 什么是缺陷报告？报告的作用？缺陷报告的要点？

什么是缺陷报告

缺陷报告就是给软件 “看病” 的病历，记录软件出了啥毛病，像哪里崩溃、功能不对等。

报告的作用

开发人员能根据它精准 “治病”，修复软件问题。
方便项目管理者掌握软件质量状况，决定能否上线。
为后续版本迭代提供参考，避免再犯老毛病。

缺陷报告的要点

编号：给缺陷一个专属 “身份证”，方便管理。
标题：简洁概括问题，一看就知道大概毛病。
描述：详细说清复现步骤、实际结果和预期结果，像讲清症状。
严重程度：分严重、一般等，让开发知道先治哪个 “病”。
状态：标记新建、修复中、已修复等，掌握处理进度。

1.9.2 缺陷报告的优先级别？

缺陷报告优先级别就像医院看病排号，决定先修哪个问题：

紧急：软件直接瘫痪，关键功能没法用，像心脏病发作，得马上治。比如交易系统无法结算。
高：影响重要功能，部分业务开展不了，类似骨折，要尽快处理。如电商 APP 不能下单。
中：功能能用但有瑕疵，体验受影响，如同感冒，抽空解决。像页面按钮位置偏移。
低：不影响主要功能，小毛病，类似皮外伤，有空再修。如界面文字有个别错别字。

1.9.3 简单概述缺陷报告？

缺陷报告是给软件问题做的 “诊断书”。它记录软件哪有毛病，比如啥功能出错、咋操作出的错。

作用是让开发清楚问题在哪，好去修复；帮管理者了解软件质量，决定上线时机。

要点有编号、标题（简洁说问题）、复现步骤、实际和预期结果、严重程度（分高低）、处理状态（如待修复）。优先级别像看病排号，紧急的马上修，低的有空再管。

1.9.4 缺陷报告包括哪些项？

缺陷报告就像软件 “病历”，包含这些项：

基本信息：编号，是缺陷 “身份证”；标题，简洁概括问题。
复现详情：环境，如系统、浏览器；步骤，写清咋操作出问题；数据，涉及的输入内容。
结果对比：实际结果，软件真实反应；预期结果，本该有的表现。
评估情况：严重程度，分高、中、低；优先级，定修复先后。
处理进展：状态，如新建、修复中；备注，补充额外说明。

1.9.5 软件测试缺陷报告的 5C 原则？

软件测试缺陷报告的 5C 原则，是让报告更优质的秘诀：

Correct（准确）：描述问题要精准，就像指认罪犯不能认错人，数据、现象都得对。
Clear（清晰）：表述清晰易懂，别让人看得一头雾水，像指路要说明白方向。
Concise（简洁）：不啰嗦，抓住重点说，如同演讲简明扼要。
Complete（完整）：信息全，复现步骤、结果等一个不少，像拼图得拼完整。
Consistent（一致）：前后说法、格式统一，好比一套制服风格一致。

1.9.6 软件缺陷的生命周期？

软件缺陷生命周期就像人生不同阶段：

发现期：测试人员找到缺陷，就像发现病人。
提交期：把缺陷信息写进报告提交，如同给病人建档。
确认期：开发人员核实是不是真有问题，类似医生诊断病情。
修复期：开发动手改问题，好比医生治病。
验证期：测试再测看修好没，像复查病情。
关闭期：缺陷解决，关闭报告，病人康复出院。若没修好，可能回到修复期继续处理。

1.9.7 缺陷描述（报告单）中应该包括哪些内容？

缺陷报告单内容就像给软件 “病情” 写档案：

身份信息：缺陷编号、标题，快速定位和识别问题。
症状表现：实际结果，即软件出啥毛病；预期结果，软件该啥样。
发病环境：系统、浏览器等运行环境，像说清病人在哪生的病。
发病过程：详细操作步骤，怎样让问题出现，类似记录病人发病经过。
病情评估：严重程度、优先级，判断问题影响大小和处理先后。
处理进展：状态，如新建、修复中；备注，补充额外信息。

1.9.8 如何提高缺陷的记录质量？

提高缺陷记录质量，可这么做：

描述精准：像画画精细勾勒，写清操作步骤、环境配置、实际和预期结果，不模糊。
格式统一：用固定模板，就像穿统一校服，让大家一看就懂。
准确评估：合理定严重程度和优先级，好比看病准确判断病情轻重缓急。
附上证据：有截图、日志等，如同断案有证据，方便开发定位。
及时更新：随处理情况改状态，像实时更新病人病历。

1.9.9 如果一个缺陷被提交后，开发人员认为不是问题，怎么处理？

若开发认为提交的缺陷不是问题，可这么办：

重新沟通：测试和开发再交流，测试详细讲复现步骤和问题影响，开发说为啥不是问题。
拉人判断：请产品经理或技术专家来评估，让专业人做裁判。
再次测试：测试换环境、数据重新测，看是不是特殊情况导致误判。
记录留痕：不管结果怎样，把沟通过程和最终结论记录好，方便后续参考。

1.9.10 软件缺陷产生的原因？

软件产品说明书（需求）——56%
设计——27%
编写代码——7%
其他——10%

1.9.11 什么是Bug？举例子说明？

Bug 就是软件里的毛病，会让软件出状况，没法正常干活。

举例：

功能出错：计算器做加法，“2 + 3” 算出结果是 “6”，这和正确答案不一样，就是功能有 Bug。
界面问题：手机 APP 里有个按钮点不动，或者文字显示不全，歪七扭八的，这是界面方面的 Bug。
系统崩溃：玩游戏正激烈，突然游戏 “闪退”，直接关闭了，这就是严重的 Bug 导致系统崩溃。

1.9.12 缺陷处理流程？举例说明？

缺陷处理流程就像治病流程：

发现报告：测试人员找到缺陷，写报告描述症状，好比病人挂号跟医生说病情。
评估确认：开发和测试一起判断是不是真缺陷，确定严重程度和优先级，如同医生诊断病情。
修复解决：开发人员动手改缺陷，就像医生治病。
验证关闭：测试人员再测，确认修好就关闭报告，若没好则打回重新处理，类似复查，好了就出院。

举例：测试发现电商 APP 购物车总价算错，提交报告。开发评估后确定是 Bug 且较严重。开发修改代码修复，测试重新计算购物车总价，结果正确就关闭此缺陷报告。

1.9.13 缺陷的等级划分？举例各种等级的缺陷？

缺陷等级划分就像给病人病情分轻重，方便安排治疗：

致命级：软件基本没法用，关键功能崩了。比如金融系统交易全出错，钱数乱套。
严重级：重要功能受大影响，部分业务开展不了。像电商 APP 不能下单付款。
一般级：功能能用但有瑕疵，体验受影响。如视频 APP 播放有轻微卡顿。
轻微级：不咋影响功能，小毛病。像页面上文字有个别错别字。

1.9.14 开发人员修复缺陷后，如何保证不影响其他功能？

开发修复缺陷后，这么保证不影响其他功能：

回归测试：重新跑一遍和修复处有关的老测试用例，就像考完试检查错题附近题目。比如修了登录缺陷，再测登录及依赖登录的功能。
关联检查：看看修复部分和其他功能有无关联，有的话重点测关联处。例如改了购物车计算，就检查支付、库存功能。
全面覆盖：用自动化工具跑全量测试用例，像用大网捞鱼，整体查一遍。
多人协作：测试、开发一起评审修复代码，不同视角发现潜在问题。

1.9.15 状态为已修改的缺陷，实际没有修改怎么办？

若 “已修改” 缺陷实际没改，这么办：

重新反馈：测试人员再跟开发说，附上没改的证据，像截图、日志。
联合排查：和开发一起找原因，看是理解有误、修复出错，还是新问题导致。
升级处理：若沟通没用，找开发领导或项目负责人协调解决。
记录跟踪：把整个过程记好，跟踪后续处理情况。

1.9.16 生产软件的最终目的是为了满足客户需求，我们以客户需求作为评判软件质量的标准，认为软件缺陷（ Software Bug ）的具体含义包括哪些几个因素？

软件缺陷（Software Bug）具体含义包含这些因素：

功能不符：软件功能和客户要的不一样。比如客户要能筛选价格区间的购物 APP，结果做出来没这功能。
运行出错：使用中软件崩溃、死机或报错。像客户用办公软件时总弹出错误提示。
性能不佳：响应慢、处理时间长等，影响使用。如客户期望网页秒开，实际要等很久。
易用性差：操作复杂、界面不友好，客户用着费劲。例如客户想要简洁操作，软件却步骤繁多。
兼容性低：在不同环境或设备上用不了或显示异常。比如客户需在多种手机系统用软件，结果部分系统不兼容。

1.9.17 如何进行缺陷评估？举例说明？

缺陷评估就像给病人诊断病情，从两方面着手：

严重程度

看缺陷对软件功能和使用的影响大小。

严重：软件关键功能瘫痪，无法正常运行。比如银行系统无法进行转账操作。
一般：部分功能受影响，但不影响整体使用。如电商 APP 商品详情页图片加载缓慢。
轻微：不影响功能使用，只是一些小瑕疵。像界面上文字有个别错别字。

优先级

考虑修复缺陷的紧急程度。

高：严重影响业务，需立即修复。如支付系统出现错误，导致无法完成交易。
中：影响部分业务，可在短期内修复。如用户注册时验证码无法正常接收。
低：对业务影响较小，可稍后修复。如页面背景颜色与设计稍有偏差。

综合严重程度和优先级，就能对缺陷进行全面评估，合理安排修复顺序。

1.10 测试案例

1.10.1 给你一个网站，你应该如何测试？举实际测试例子？

测试网站可按这几步：

功能测试：检查各功能能否正常用。如电商网站，测试商品搜索、加入购物车、结算等功能。比如搜 “手机”，看结果是否相关，选商品加购物车，看数量和总价对不对，结算时试不同支付方式能否成功。
性能测试：看网站响应速度等性能指标。用工具模拟多人访问，测响应时间。比如模拟 100 人同时登录论坛，看多久能打开页面，发帖加载时间长不长。
兼容性测试：检查在不同浏览器、设备上显示和功能是否正常。比如在 Chrome、Firefox 浏览器，以及手机、平板上打开新闻网站，看文章排版、图片显示有无问题。
界面测试：查界面布局、美观度等。如检查网站按钮大小、颜色是否协调，文字有无乱码。像社交网站，看个人资料页头像、昵称位置是否合适，文字有无错漏。
安全测试：找网站安全漏洞。如用工具扫描有无 SQL 注入、跨站脚本攻击风险。比如在登录框输入特殊字符，看会不会导致网站数据泄露或系统崩溃。

1.10.2 一个有广告的纸杯子，请设计测试用例？

功能度：用水杯装水看漏不漏；水能不能被喝到安全性：杯子有没有毒或细菌
可靠性：杯子从不同高度落下的损坏程度
可移植性：杯子在不同的地方、温度等环境下是否都可以正常使用
兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等
易用性：杯子是否烫手、是否有防滑措施、是否方便饮用
用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述
疲劳测试：将杯子盛上水放24 小时检查泄漏时间和情况；盛上汽油放24 小时检查泄漏时间和情况等
压力测试：用根针并在针上面不断加重量，看压强多大时会穿透
跌落测试: 杯子加包装(有填充物),在多高的情况摔下不破损
震动测试: 杯子加包装(有填充物),六面震动,检查产品是否能应对恶劣的铁路\公路\航空运输

外观

尺寸规格：量纸杯高度、杯口直径等，看是否和设计一致。例：设计高 10cm，实测也是。
印刷质量：查广告图案、文字是否清晰、完整、颜色对。例：无重影、掉色、缺字。
清洁情况：看杯身有无污渍、划痕。例：无咖啡渍、无明显刮痕。

物理性能

承重能力：装规定容量水，看是否变形、漏水。例：装 250ml 水，放置 5 分钟不漏水。
耐温性能：分别装冷水和热水，看纸杯有无变软、异味。例：装 80℃热水，纸杯不烫手、不变形。

广告内容

合规性：查广告有无违法违规内容。例：无虚假宣传、无违禁词汇。
可读性：在不同光线下看广告文字是否易读。例：强光和弱光下文字都清晰。

安全性

材料安全：检测纸杯材料有无有害物质。例：无重金属超标。
卫生情况：查有无细菌超标。例：符合卫生标

1.10.3 一个身份证号码输入框，怎么设计用例？

格式方面

正确格式：输 18 位合法身份证号，看能否正常录入，如 “11010519491231002X”。
错误位数：分别输 17 位、19 位号码，像 “11010519491231002” 和 “11010519491231002XX”，应有错误提示。
非法字符：输入含字母（除最后一位 X）、特殊符号的内容，如 “1101051949123100@2”，给出错误提示。

逻辑方面

出生日期逻辑：输出生日期不合理的号码，如 “20250230” 在 18 位号码里，提示错误。
校验位逻辑：改正确号码的校验位，如 “11010519491231002Y”，应有错误提示。

边界情况

最大最小值：输最小 18 位合法号 “110105000101001X” 和最大号 “65900499991231999X”，看能否正常处理。
空值与空格：不输内容或输入空格，应提示必填。

1.10.4 登录功能怎么设计测试用例？

正常情况

正确信息：输入正确用户名和密码，点登录，看能否成功进入系统。
记住密码：选记住密码，下次打开，看是否自动填充。

异常情况

信息错误：分别输错用户名、密码，或两者都错，看提示是否准确。
空值情况：用户名、密码留空，点登录，看是否提示必填。
格式错误：输不符合格式的用户名或密码，如含特殊符号，看有无错误提醒。

其他情况

多次失败：连续输错多次，看是否有锁定账号或验证码机制。
登录超时：登录界面开着很久，再操作，看是否需重新加载或登录。

1.10.5 移动端和web 端测试有什么区别？举例子说明？

界面布局

移动端：屏幕小，布局适配多样。如手机银行 APP，在不同尺寸手机上，转账按钮位置和大小得适配。
Web 端：屏幕大，布局相对固定。如网上银行网页，在不同电脑显示器上布局差异小。

性能方面

移动端：受设备性能、网络影响大。如玩手游，老手机加载慢，4G 网络差时可能卡顿。
Web 端：性能较稳定，主要受浏览器和服务器影响。如访问新闻网站，主流浏览器和稳定网络下，加载速度变化小。

操作方式

移动端：有触摸、滑动、手势等操作。如相册 APP，可双指缩放图片。
Web 端：靠鼠标点击、滚动条操作。如电商网页，用鼠标选商品、翻页。

系统兼容性

移动端：要适配多种系统和版本。如社交 APP，在 iOS 和安卓不同版本上都得能用。
Web 端：主要考虑主流浏览器。如办公网站，要在 Chrome、Firefox 上正常显示。

1.10.6 测试一个C/S 客户端时，需要考虑的因素？

测试 C/S 客户端时，要考虑这些因素：

功能

基本功能：检查登录、注册、数据查询等是否正常。如登录时输对信息能成功登录。
业务流程：验证业务操作流程是否顺畅。像电商客户端，从选商品到下单付款流程要通。

性能

响应时间：看操作响应是否快。如搜索商品，结果要很快显示。
并发处理：测试多人同时使用情况。如多人同时登录，系统不崩溃。

兼容性

系统兼容：在不同操作系统能用。如 Windows、Mac 系统都适配。
版本兼容：和服务器版本兼容。新客户端版本要和老服务器版本兼容。

安全

数据安全：保证数据传输加密。如密码等敏感信息加密传输。
访问控制：限制非授权访问。如未登录用户不能访问个人信息。

易用性

界面友好：操作方便、界面美观。如按钮位置合理、文字清晰。
提示明确：操作提示易懂。如出错有明确错误提示。

1.10.7 测试电梯，请详细描述?

外观与结构

整体外观：查看电梯轿厢、门等有无划痕、变形、掉漆，就像看新衣服有没有破洞、掉色。
尺寸规格：测量轿厢长宽高、门的大小等，确保符合设计标准，好比做衣服要按尺码来。
部件完整性：检查按钮、显示屏、扶手等部件是否齐全，如同检查自行车零件有没有缺失。

功能

运行功能：
- 上下移动：在各楼层按上下键，看电梯能否正常到达，类似坐公交车看是否能到站点。
- 速度：感受运行速度是否平稳、适中，别像坐过山车一样忽快忽慢。
门控功能：
- 开关门：进出时，门能正常开关，且开关过程无卡顿、异响，就像家里的门要开关顺滑。
- 安全保护：用手挡门，门应立即停止关闭并重新打开，防止夹人，好比有个保护罩。
按钮功能：
- 楼层按钮：按不同楼层按钮，电梯能准确响应，如同输入目的地导航能带你去。
- 特殊按钮：紧急呼叫、报警按钮按下后，能与外界取得联系，就像遇到危险能喊救命。

性能

载重性能：放入规定重量的物品，电梯仍能正常运行，就像货车要能拉得动货。
可靠性：多次运行，看是否会出现故障，好比一辆车开很多次都不能抛锚。

安全

安全装置：检查限速器、安全钳等安全装置是否有效，类似汽车的刹车要灵敏。
应急照明：模拟停电，看应急照明能否及时亮起，保证被困人员安全，如同黑暗中有盏灯。

舒适性

噪音：运行时噪音不能太大，让人感觉安静舒适，就像在图书馆不能太吵。
通风：轿厢内通风良好，空气清新，就像房间要空气流通。

1.10.8 对一只圆珠笔进行测试?

外观

完整性：看笔身、笔帽、笔尖有无破损、裂缝，像检查玩具有没有缺胳膊少腿。
尺寸：量长度、粗细，是否和标准相符，好比买衣服要看尺码对不对。
颜色图案：颜色正不正，图案清不清晰，有无掉色、印刷错误，就像看画的色彩和线条。

书写功能

流畅度：在不同纸张上写，线条连贯，无断墨、卡顿，如同水流要顺畅。
笔迹粗细：笔迹粗细均匀，和标识一致，就像头发粗细得差不多。
墨水颜色：颜色纯正，和宣传一样，不能有杂色，好比水果颜色要鲜艳。

耐用性

笔帽插拔：多次插拔笔帽，看是否松动，类似开关门看合页紧不紧。
笔尖耐磨：写很多字，笔尖不损坏，墨水正常流出，像鞋子鞋底要耐磨。

安全性

材料无毒：确保笔的材料没毒，不会危害健康，如同食物不能有毒。
无尖锐边角：笔身光滑，无尖锐处，防止划伤手，就像家具边角要圆润。

1.10.9 游戏测试与软件测试的区别？

游戏测试和软件测试有不少区别，主要体现在以下几个方面：

测试对象

游戏测试：主要针对游戏，像《王者荣耀》《原神》这类，包括游戏的剧情、角色、关卡、道具等。
软件测试：针对各种软件，比如办公软件、财务软件、打车软件等，侧重功能、性能等。

测试重点

游戏测试：看重游戏的趣味性、沉浸感。比如剧情是否吸引人，角色技能是否平衡，关卡难度是否合适。
软件测试：更关注功能的准确性、稳定性。像计算软件的结果要精确，办公软件不能轻易崩溃。

测试方法

游戏测试：常采用探索性测试，玩家可自由探索游戏世界找问题。还注重多人联机测试，看多人对战或合作时是否有问题。
软件测试：多用黑盒测试、白盒测试等方法。黑盒测功能是否符合需求，白盒看代码逻辑有无错误。

用户体验要求

游戏测试：对画面、音效要求高，画面要精美，音效要贴合场景，操作手感也要好，不然玩家会觉得不爽。
软件测试：主要要求界面简洁易用，操作流程合理，能快速完成任务，对美观度要求没那么高。

兼容性测试

游戏测试：要在各种游戏主机、不同型号手机、不同电脑配置上测试，确保都能流畅运行。
软件测试：主要在不同操作系统、浏览器、硬件设备上测试，保证软件能正常使用。

1.10.10 想象一个登录框，包括ID、密码、登录、取消，记住密码（复选框）尽可能的写出你想到的测试点？

输入合法性

ID：
- 输正确 ID，能正常识别。
- 输错误、不存在 ID，有提示。
- 输空 ID，提示必填。
- 超长、超短 ID，看是否限制。
- 含特殊字符 ID，是否允许。
密码：
- 输正确密码，正常登录。
- 输错误密码，有提示。
- 输空密码，提示必填。
- 不同强度密码（简单、复杂），能否接受。
- 超长、超短密码，是否限制。

功能按钮

登录：
- 输正确 ID 和密码，点登录成功登录。
- 输错误信息，点登录提示错误。
- 未输信息，点登录提示完善。
- 快速、多次点击登录，看是否异常。
取消：点取消，清除输入信息或返回上一界面。
记住密码：
- 勾选，下次打开自动填充密码。
- 不勾选，下次打开不填充。
- 勾选登录后换账号登录，原密码不保留。

界面显示

输入框：大小、位置合适，输入时文字显示正常。
按钮：大小、颜色、文字清晰，点击有反馈效果。
复选框：勾选、取消勾选状态明显。

安全相关

密码显示：密码框默认密文显示，可设置明文查看。
防止暴力破解：多次输错有锁定账号或验证码机制。

1.10.11 针对添加购物车这个测试点说一下你要怎么测试“添加购物车”？

正常操作

商品添加：选商品点添加，购物车数量增加，商品显示对。如选件衣服加购物车，能看到衣服信息。
多件添加：选多件商品，都能成功加入，数量对应。像选三件不同衣服，都显示且数量是三。
不同规格：商品不同规格（颜色、尺码）能分别添加。如衣服不同颜色、尺码可分别加。

异常情况

无库存：选无库存商品，提示不能加，购物车不增加。
网络问题：模拟断网加购物车，提示网络问题，恢复后可正常操作。

边界情况

最大数量：加最大允许数量商品，能正常处理。
最小数量：加一件商品，能正常添加。

关联功能

总价计算：加商品后，购物车总价计算正确。
删除商品：添加后删除，购物车更新，总价变化。

1.10.12 网上银行转账是怎么测的，设计一下测试用例？

功能测试

正常转账
- 同行本地：用足额账户向同行本地账户转小、中、大不同金额，查转出账户余额减少、转入账户增加且交易记录正确。如从 A 行本地账户转 100 元到 A 行本地 B 账户。
- 同行异地：向同行异地账户转，确认资金到账及手续费扣除情况。如 A 行本地转 A 行外地账户。
- 跨行转账：向其他银行账户转，验证到账时间和手续费，如 A 行转 B 行。
异常转账
- 余额不足：用余额少的账户转大额，提示余额不足且账户金额不变。
- 账户错误：输错账号、户名，提示信息不符，资金不转出。
- 重复转账：短时间内重复提交相同转账，提示已处理或防重机制生效。

性能测试

响应时间：测不同金额转账响应时间，确保在合理范围。
并发测试：模拟多人同时转账，看系统能否正常处理，无卡顿、崩溃。

安全测试

密码验证：转账时输错登录、支付密码，限制尝试次数，锁定账户。
安全工具：用 U 盾、短信验证码时，验证工具有效性和操作流程。

界面测试

布局合理性：检查转账页面各元素布局，操作方便，提示信息清晰。
提示信息：操作时提示准确易懂，如转账成功、失败提示。

2 Linux 基础

2.1 Linux 基础

2.1.1 Linux 常用命令？

文件与目录操作

ls - 列出目录内容

ls -l：详细列表
ls -a：显示隐藏文件

cd - 切换目录

cd /path/to/directory：进入指定目录
cd ..：返回上一级目录
cd ~：返回用户主目录

pwd - 显示当前工作目录

mkdir - 创建目录

mkdir dirname：创建目录
mkdir -p dir1/dir2：递归创建目录

rmdir - 删除空目录

rmdir dirname：删除空目录

rm - 删除文件或目录

rm filename：删除文件
rm -r dirname：递归删除目录
rm -f filename：强制删除文件

cp - 复制文件或目录

cp file1 file2：复制文件
cp -r dir1 dir2：递归复制目录

mv - 移动或重命名文件或目录

mv file1 file2：重命名文件
mv file1 /path/to/directory：移动文件

touch - 创建空文件或更新文件时间戳

touch filename：创建空文件或更新时间戳

cat - 查看文件内容

cat filename：显示文件内容
cat file1 file2 > file3：合并文件

more / less - 分页查看文件内容

more filename：分页查看文件
less filename：更强大的分页查看工具

head / tail - 查看文件开头或结尾部分

head -n 10 filename：查看文件前10行
tail -n 10 filename：查看文件最后10行
tail -f filename：实时查看文件新增内容

文件权限与所有权

chmod - 修改文件权限

chmod 755 filename：设置文件权限为755
chmod u+x filename：给文件所有者添加执行权限

chown - 修改文件所有者

chown user:group filename：修改文件所有者和所属组

chgrp - 修改文件所属组

chgrp groupname filename：修改文件所属组

文件查找与比较

find - 查找文件

find /path -name "filename"：按名称查找文件
find /path -type f -mtime -7：查找7天内修改过的文件

grep - 文本搜索

grep "pattern" filename：在文件中搜索指定模式
grep -r "pattern" /path：递归搜索目录中的文件

diff - 比较文件差异

diff file1 file2：比较两个文件的差异

系统信息与管理

uname - 显示系统信息

uname -a：显示所有系统信息

top / htop - 实时显示系统进程

top：实时显示系统进程和资源使用情况
htop：更友好的进程查看工具

ps - 显示当前进程

ps aux：显示所有进程

kill - 终止进程

kill PID：终止指定进程
kill -9 PID：强制终止进程

df - 显示磁盘使用情况

df -h：以易读格式显示磁盘使用情况

du - 显示目录或文件大小

du -sh /path：显示目录或文件的总大小

free - 显示内存使用情况

free -h：以易读格式显示内存使用情况

uptime - 显示系统运行时间

网络相关

ping - 测试网络连接

ping example.com：测试与指定域名的连接

ifconfig / ip - 显示或配置网络接口

ifconfig：显示网络接口信息
ip addr show：显示IP地址信息

netstat - 显示网络连接、路由表、接口统计信息

netstat -tuln：显示所有监听端口

ssh - 远程登录

ssh user@host：通过SSH登录远程主机

scp - 安全复制文件

scp file user@host:/path：将文件复制到远程主机

wget / curl - 下载文件

wget http://example.com/file：下载文件
curl -O http://example.com/file：下载文件

压缩与解压

tar - 打包和解包文件

tar -cvf archive.tar /path：打包文件
tar -xvf archive.tar：解包文件
tar -czvf archive.tar.gz /path：打包并压缩文件
tar -xzvf archive.tar.gz：解压并解包文件

gzip / gunzip - 压缩和解压缩文件

gzip filename：压缩文件
gunzip filename.gz：解压缩文件

zip / unzip - 压缩和解压缩文件

zip archive.zip file1 file2：压缩文件
unzip archive.zip：解压缩文件

用户与权限管理

useradd / userdel - 添加/删除用户

useradd username：添加用户
userdel username：删除用户

passwd - 修改用户密码

passwd username：修改用户密码

su / sudo - 切换用户或执行命令

su username：切换用户
sudo command：以超级用户权限执行命令

其他常用命令

echo - 输出文本

echo "Hello World"：输出文本

date - 显示或设置系统日期和时间

date：显示当前日期和时间

history - 显示命令历史

history：显示命令历史记录

alias - 创建命令别名

alias ll='ls -la'：创建别名

man - 查看命令手册

man command：查看命令的使用手册

2.1.2 在Linux 系统中，一个文件的访问权限是755，其含义是什么？

755 表示该文件所有者对该文件具有读、写、执行权限，该文件所有者所在组用户及其他用户对该文件具有读和执行权限。

2.1.3 查看某进程号？

ps -ef | grep ps_name
ps -ef | grep ps_number

2.1.4 grep 和find 的区别？grep 都有哪些用法？

grep 和 find 区别

grep：是文本搜索工具，在文件内容里找符合特定模式的文本，就像在书里找特定的句子。
find：是文件查找工具，按文件名、大小、修改时间等条件在文件系统里找文件，如同在图书馆找某本书。

grep 用法

基本查找：grep "关键词" 文件名，在文件里找含关键词的行。如grep "apple" fruits.txt，在 fruits.txt 里找有 “apple” 的行。
忽略大小写：grep -i "关键词" 文件名，不区分大小写找。如grep -i "Apple" fruits.txt，能找到 “apple”“Apple” 等。
递归查找：grep -r "关键词" 目录名，在目录及其子目录所有文件里找。如grep -r "banana" /home/user/docs。
反向查找：grep -v "关键词" 文件名，找不含关键词的行。如grep -v "grape" fruits.txt。

2.1.5 动态查看日志文件？动态查看倒数500行日志？

tail -f app.log

tail -n 500 -f app.log 或 tail -nf 500 app.log

2.1.6 以/etc/passwd 的前五行内容为例，提取用户名？

在 Linux 里，/etc/passwd 文件每行是一个用户信息，用户名在第一个字段，各字段用冒号分隔。

要提取它前五行的用户名，可用 head -5 先取前五行，再用 cut -d: -f1 按冒号分割取第一个字段（即用户名）。

命令是：head -5 /etc/passwd | cut -d: -f1

3.MySQL 基础

3.1MySQL基础知识

3.1.1 MySQL 简介

MySQL 是一款超流行的开源数据库管理系统，就像一个大仓库，专门帮你有条理地存放和管理数据。

存储数据

能把各类信息，像用户信息、商品数据等，按照不同的 “表” 整齐存起来，好比仓库里用不同货架分类放东西。

方便查询

可以用特定的语句快速找到你想要的数据，就像在仓库里能快速定位到需要的物品。比如查某个用户的订单，一找就出来。

多用户使用

允许多个用户同时访问和操作数据，就像多个员工可以同时进出仓库取放东西。

安全可靠

有安全机制保护数据不被随意更改或泄露，还能备份数据，防止丢失，如同仓库有锁和应急预案。

很多网站、软件系统都用 MySQL 来管理数据，简单又强大。

3.2 MySQL 操作

3.2.1 数据库和表的基本操作

连接数据库

好比开门进仓库，用命令mysql -u用户名 -p，输入密码后就能进入数据库系统这个 “大仓库”。

创建数据库

如同在仓库里划分出一个新区域，用CREATE DATABASE 数据库名;。

选择数据库

确定你要在哪个区域操作，用USE 数据库名;。

创建表

在区域里摆上货架放东西，用CREATE TABLE 表名(字段名数据类型, ...);定义表结构。

插入数据

往货架上放物品，INSERT INTO 表名(字段1, 字段2) VALUES (值1, 值2);。

查询数据

在仓库找东西，SELECT 字段1, 字段2 FROM 表名 WHERE 条件;能按条件精准查找。

更新数据

修改货架上物品信息，UPDATE 表名 SET 字段=新值 WHERE 条件;。

删除数据

把货架上物品拿走，DELETE FROM 表名 WHERE 条件;。

删除表和数据库

拆除货架和关闭区域，分别用DROP TABLE 表名;和DROP DATABASE 数据库名; 。

3.2.2 Mysql数据类型

数值类型

整数：
- TINYINT：像小盒子，存 -128 到 127 这种小整数（无符号 0 到 255），比如存年龄小范围统计。
- INT：常用大箱子，能存 -21 亿到 21 亿多的整数，像用户 ID 。
- BIGINT：超大仓库，存超级大整数，适合记录超大量数据的编号。
小数：
- FLOAT：存单精度小数，精度有限像大概估算，适合对精度要求不高的，如商品大致价格。
- DECIMAL：高精度小数，像精确称重，存金额这种要精准的数值。

字符串类型

CHAR：固定长度 “盒子”，提前定好大小，空间占满，适合长度固定的，如身份证号。
VARCHAR：可变长度 “袋子”，按需装东西，省空间，适合长度不固定的，如用户名。
TEXT：大 “记事本”，能存大量文本，像文章内容。

日期和时间类型

DATE：只存日期，像日历上圈日期，格式 “YYYY - MM - DD”，如生日。
TIME：只存时间，格式 “HH:MM:SS”，如上班打卡时间。
DATETIME：存日期和时间，如记录事件发生的完整时刻。

JSON 类型

JSON：用于存储 JSON 文档，MySQL 5.7.8 及以上版本支持。

空间数据类型

GEOMETRY: 可以存储任何类型的几何数据。
POINT: 存储一个点 (X, Y)。
LINESTRING: 存储一条线。
POLYGON: 存储一个多边形。
MULTIPOINT: 存储多个点。
MULTILINESTRING: 存储多条线。
MULTIPOLYGON: 存储多个多边形。
GEOMETRYCOLLECTION: 存储多个几何对象的集合。

3.2.3 数据库约束

约束是什么

MySQL 数据库约束就像游戏规则，能保证数据的准确性和可靠性，让数据库里的数据整齐、规范。

有哪些

主键约束（PRIMARY KEY）：好比每个学生的学号，唯一且不能为 NULL，能唯一标识表中的每一行数据。
唯一约束（UNIQUE）：如同身份证号，要求列里的值都不一样，但可以有一个 NULL 值。
非空约束（NOT NULL）：像必填项，规定列的值不能为 NULL。
外键约束（FOREIGN KEY）：类似班级和学生的关系，建立两个表之间的关联，保证数据的一致性。
检查约束（CHECK）：自定义规则，例如规定年龄必须大于 0。

怎么用

创建表时添加

CREATE TABLE 学生 (
    学号 INT PRIMARY KEY,
    姓名 VARCHAR(20) NOT NULL,
    身份证号 VARCHAR(18) UNIQUE,
    班级编号 INT,
    年龄 INT,
    FOREIGN KEY (班级编号) REFERENCES 班级(班级编号),
    CHECK (年龄 > 0)
);

给已存在表添加

-- 添加主键约束
ALTER TABLE 学生 ADD PRIMARY KEY (学号);
-- 添加唯一约束
ALTER TABLE 学生 ADD UNIQUE (身份证号);
-- 添加非空约束
ALTER TABLE 学生 MODIFY 姓名 VARCHAR(20) NOT NULL;
-- 添加外键约束
ALTER TABLE 学生 ADD FOREIGN KEY (班级编号) REFERENCES 班级(班级编号);
-- 添加检查约束（MySQL 8.0.16 及以上支持）
ALTER TABLE 学生 ADD CONSTRAINT chk_年龄 CHECK (年龄 > 0);

3.2.4 数据操作

数据添加

插入单行数据

用 INSERT INTO 表名(列1,列2,...) VALUES(值1,值2,...); ，明确告诉数据库要把数据放到哪个表的哪些列里。比如有个 “学生” 表，要插入一个学生信息，就写 INSERT INTO 学生(姓名,年龄) VALUES('张三', 18);，就像把写着 “张三，18 岁” 的货物放到 “学生” 这个货架对应位置。

插入多行数据

格式是 INSERT INTO 表名(列1,列2,...) VALUES(值1,值2,...),(值3,值4,...); 。好比一次搬好几件货物到货架，如 INSERT INTO 学生(姓名,年龄) VALUES('李四', 19),('王五', 20); ，能同时插入多个学生信息。

数据查询

简单找东西

用 SELECT 列名 FROM 表名; ，比如 SELECT 姓名 FROM 学生; ，能找出 “学生” 表中所有人的姓名，就像在仓库指定货架找对应物品。

按条件找

加 WHERE ，像 SELECT 姓名 FROM 学生 WHERE 年龄 > 18; ，只找年龄大于 18 的学生姓名，如同按特定要求筛选货物。

排序再找

用 ORDER BY ，SELECT * FROM 学生 ORDER BY 年龄 ASC; 按年龄从小到大排着找，ASC 是升序，DESC 是降序，好比把货物按规则排好再挑。

分组统计

用 GROUP BY 和聚合函数，SELECT 班级, COUNT(*) FROM 学生 GROUP BY 班级; 按班级分组统计人数，就像把货物按类别放一起数数。

多表联合找

表之间有关联时用 JOIN ，SELECT 学生.姓名, 成绩.分数 FROM 学生 JOIN 成绩 ON 学生.ID = 成绩.学生ID; 把两个表关联查学生姓名和分数，如同把不同货架货物关联起来找。

数据修改

改单个数据

用 UPDATE 表名 SET 列名 = 新值 WHERE 条件; 。比如 UPDATE 学生 SET 年龄 = 20 WHERE 姓名 = '张三'; ，就是找到叫 “张三” 的学生，把他年龄标签改成 20 。

改多个数据

一个 UPDATE 语句里能改多列。像 UPDATE 学生 SET 年龄 = 21, 班级 = '二班' WHERE 姓名 = '李四'; ，同时给 “李四” 换年龄和班级标签。

全量修改

要是不写 WHERE 条件，表中所有行对应列数据都会改。如 UPDATE 学生 SET 性别 = '女'; ，所有学生性别标签都变成女。不过这得谨慎用，容易出错。

数据删除

按条件删

用DELETE FROM 表名 WHERE 条件;。比如DELETE FROM 学生 WHERE 姓名 = '张三';，就像从 “学生” 货架把叫 “张三” 的货物拿走。

全量删

DELETE FROM 表名; 不写条件，会把表中所有数据清掉，像把整个货架货物清空。但表结构还在，还能再放新货。

删表

用DROP TABLE 表名;，这是连货架都拆了，表和里面数据都没了。

3.3 高级操作

3.3.1 事务

事务是什么

MySQL 事务就像你打包做一组事，要么这组事都成功，像盖房子每个环节都完成，房子盖好；要么都失败，一旦有一步出错，就全推倒重来，保证数据的一致性和完整性。比如银行转账，从 A 账户转钱到 B 账户，转钱和收钱这俩操作得都成功，不然就都不执行。

如何使用事务

开始事务：用START TRANSACTION开启，就像喊 “开始干活”。
执行操作：在这之后写一系列增删改查语句，好比组员开始做事。
提交事务：若操作都成功，用COMMIT结束事务，成果保存，如同任务完成被认可。
回滚事务：若有问题，用ROLLBACK撤销操作，回到事务开始前，像任务搞砸一切重来。

也可通过设置SET AUTOCOMMIT = 0关闭自动提交，手动控制事务范围。

MySQL 事务有四大特性，可记为 ACID：

原子性（Atomicity）

事务就像一个不可分割的原子。里面的操作要么全部成功，要么全部失败。好比你用手机转账，转钱和收钱这俩操作必须都完成，要是中间出问题，就都不执行，钱不会平白消失或多出。

一致性（Consistency）

事务执行前后，数据库数据要保持合法状态。比如银行账户转账，不管怎么转，所有账户的总金额应该不变。就像你把一兜苹果从一个房间搬到另一个房间，苹果总数不会变。

隔离性（Isolation）

多个事务同时执行时，相互之间要隔离，不能互相干扰。就像几个人在不同房间同时做不同的事，互不影响。比如一个事务在修改数据，另一个事务读取数据时，不会读到修改到一半的混乱数据。

持久性（Durability）

事务一旦提交成功，它对数据库的改变就是永久的。即使遇到系统崩溃、断电等情况，数据也不会丢失。好比你在纸上写好的字，写完就固定在那了。

3.3.2 索引

索引是什么

MySQL 索引好比书的目录，它能帮数据库快速定位数据位置。没索引时找数据像逐页翻书，有索引则能按 “目录” 快速找到，极大提升查询速度。不过它会占存储空间，数据更新时索引也得更新。

如何使用索引

创建索引：建表时可直接加，如 CREATE TABLE 员工 (id INT, 姓名 VARCHAR(20), INDEX(姓名)); ；表已存在，用 CREATE INDEX idx_姓名 ON 员工(姓名); 。
查询利用索引：查询语句条件列有索引，数据库就自动用索引加速。如 SELECT * FROM 员工 WHERE 姓名 = '张三'; ，若 “姓名” 有索引，查询会更快。
避免索引失效：别在索引列上做计算、函数操作，否则索引不起作用。如 SELECT * FROM 员工 WHERE YEAR(入职时间) = 2023; ，若对 “入职时间” 建索引，此查询会让索引失效。

3.3.3 视图

视图是什么

MySQL 视图就像是给数据库里的数据拍了张 “快照”，或者说是开了扇 “窗户”。它本身不存数据，而是基于 SQL 查询语句，从一个或多个表中选取数据形成的虚拟表。比如你经常要查看员工表中销售部门员工信息，就可以创建个视图把这些信息集中展示，就像从窗户一眼看到你想看的风景。

如何使用视图

创建视图：用 CREATE VIEW 视图名 AS 查询语句; 。例如，CREATE VIEW 销售员工视图 AS SELECT * FROM 员工 WHERE 部门 = '销售部'; ，这样就创建了一个展示销售部员工信息的视图。
查询视图：和查询普通表一样，SELECT * FROM 销售员工视图; ，直接从视图里拿你想要的数据。
修改视图：用 CREATE OR REPLACE VIEW 视图名 AS 新查询语句; 。要是想让视图显示销售部里业绩大于 100 万的员工，就可以写 CREATE OR REPLACE VIEW 销售员工视图 AS SELECT * FROM 员工 WHERE 部门 = '销售部' AND 业绩 > 1000000; 。
删除视图：用 DROP VIEW 视图名; ，比如 DROP VIEW 销售员工视图; ，这个视图就没了。

3.3.4 统计函数

COUNT

好比数数，能统计行数。用法：COUNT(列名)或COUNT(*)。如COUNT(*) FROM 学生表，统计学生表有多少条记录；COUNT(成绩) FROM 成绩表，统计成绩列非空值数量。

SUM

像算总和，计算某列数值总和。用法：SUM(列名)。如SUM(销售额) FROM 销售表，算出销售表中销售额总和。

AVG

类似求平均分，算某列数值平均值。用法：AVG(列名)。如AVG(年龄) FROM 员工表，得出员工表中员工平均年龄。

MAX 和 MIN

MAX 是找最大，MIN 是找最小。用法：MAX(列名)和MIN(列名)。如MAX(价格) FROM 商品表找到最贵商品价格；MIN(分数) FROM 考试表找到最低分数。

3.3.5 其他常用

ORDER BY

这是最常用的排序 “法宝”。就像给同学们排队，能按成绩高低、年龄大小排。用法是 SELECT * FROM 表名 ORDER BY 列名 [ASC|DESC];。ASC 是升序，从小到大排；DESC 是降序，从大到小排。比如 SELECT * FROM 学生表 ORDER BY 成绩 DESC;，就是按成绩从高到低排列学生信息。

LIMIT

可理解为 “截取一段队伍”。用法是 SELECT * FROM 表名 LIMIT 起始位置, 数量; 。若 SELECT * FROM 学生表 LIMIT 0, 5;，就是从第 1 条记录开始，取 5 条记录，常和 ORDER BY 搭配，取排序后的前几条数据。

GROUP BY

如同按班级把学生分组。先按某列分组，再结合统计函数计算。用法是 SELECT 列1, 统计函数(列2) FROM 表名 GROUP BY 列1;。如 SELECT 班级, COUNT(*) FROM 学生表 GROUP BY 班级;，按班级分组统计每个班的学生数量。

HAVING

是分组后的 “筛选员”，和 WHERE 类似，但用于 GROUP BY 之后筛选分组结果。如 SELECT 班级, COUNT(*) FROM 学生表 GROUP BY 班级 HAVING COUNT(*) > 30;，筛选出学生数量超过 30 人的班级。

ROW_NUMBER()

给查询结果逐行编号，就像给排队的人发号码牌。用法 ROW_NUMBER() OVER (ORDER BY 列名)，比如 SELECT ROW_NUMBER() OVER (ORDER BY 成绩) AS 排名, * FROM 学生表，能按成绩给学生依次排名。

RANK()

也是排名，但遇到相同值时排名相同，且会跳过后续名次。好比比赛，两人并列第一，下一人就是第三。用法 RANK() OVER (ORDER BY 列名)，如 SELECT RANK() OVER (ORDER BY 分数) AS 排名, * FROM 考试表。

DENSE_RANK()

同样用于排名，相同值排名相同，不过后续名次连续。还是比赛，两人并列第一，下一人就是第二。用法 DENSE_RANK() OVER (ORDER BY 列名)，例如 SELECT DENSE_RANK() OVER (ORDER BY 销量) AS 排名, * FROM 销售表。

3.4 备份和恢复

3.4.1 备份数据库

备份是什么

MySQL 数据库备份就像给重要文件复印一份，防止原文件丢失、损坏或出错。数据库里的数据可能因硬件故障、软件错误、人为误操作等丢失，备份能让你在意外发生后恢复数据。

使用 mysqldump 工具

备份整个数据库：打开命令行，输入 mysqldump -u 用户名 -p 数据库名 > 备份文件名.sql，按提示输入密码，就会把指定数据库备份到 .sql 文件。比如 mysqldump -u root -p mydb > mydb_backup.sql 。
备份部分表：mysqldump -u 用户名 -p 数据库名表名1 表名2 > 备份文件名.sql ，能只备份指定的表。例如 mysqldump -u root -p mydb users orders > mydb_part_backup.sql 。

3.4.2 恢复数据库

恢复是什么

MySQL 数据库恢复就像是把之前备份的 “数据副本” 重新放回数据库，好比文件丢失后用复印件还原成原本文件。当数据库数据因各种意外丢失、损坏时，通过恢复操作能让数据回到之前正常的状态。

使用备份文件恢复

使用 mysql 命令：在命令行输入 mysql -u 用户名 -p 数据库名 < 备份文件名.sql，输入密码后，就能把 .sql 文件里的数据恢复到指定数据库。比如 mysql -u root -p mydb < mydb_backup.sql ，可将之前备份的 mydb 数据库恢复。
使用图形化工具：像 Navicat 这类工具，有导入功能。在工具里选中要恢复的数据库，通过操作导入 .sql 备份文件完成恢复。

4.Web 测试

4.1 Web 测试

4.1.1 描述用浏览器访问www.baidu.com 的过程？

DNS 解析

你在浏览器输入 “www.baidu.com”，就像你要去一个叫百度的地方，但只知道名字。浏览器会找 “地址簿”（DNS 服务器）问百度具体在哪（对应的 IP 地址）。

TCP 连接

拿到 IP 地址后，浏览器就像打电话，通过 TCP 协议和百度服务器 “建立通话”，确定双方能正常交流，这个过程叫 TCP 三次握手。

HTTP 请求

连接建立好，浏览器就像写信，把你要访问百度页面的请求内容（如请求类型、请求资源等）按照 HTTP 协议格式写好，发给百度服务器。

服务器处理请求

百度服务器收到 “信” 后，查看请求内容，去自己 “仓库”（数据库等）找你要的网页数据。

HTTP 响应

服务器把找到的网页数据按 HTTP 协议格式打包成 “回信”，发给你的浏览器。

浏览器解析渲染页面

浏览器收到 “回信”，打开里面的网页代码，像搭积木一样，把文字、图片等元素组合成漂亮的百度页面展示给你。

TCP 断开连接

看完页面，浏览器像结束通话，通过 TCP 四次挥手和百度服务器 “挂断电话”，断开连接。

4.1.2 以京东首页为例，设计用例框架。（注意框架设计逻辑，区域划分，专项测试等，不需要详细用例。）？

框架设计逻辑

围绕京东首页功能、性能、兼容性等核心维度展开，确保全面覆盖测试要点。按不同特性划分测试模块，便于组织和执行用例。

区域划分

头部区域：包含搜索框、导航菜单、用户登录等。可测搜索功能准确性、导航跳转是否正确、登录注册流程等。
轮播图区域：测试图片展示、切换效果、链接跳转。
商品推荐区域：验证商品展示数量、类型、推荐逻辑是否合理，商品详情页能否正常打开。
底部区域：测试版权信息、帮助中心、客服链接等是否可用。

专项测试

功能测试：各区域基本功能，如点击、输入、跳转等是否正常。
性能测试：检测页面加载时间、响应时间，特别是高并发下的性能表现。
兼容性测试：在不同浏览器（如 Chrome、Firefox）、不同设备（电脑、平板、手机）上查看页面显示和功能是否正常。
安全测试：检查登录信息加密、防止 SQL 注入、XSS 攻击等安全机制是否有效。

4.1.3 如何测试购买下单和退货流程？

以下是测试购买下单和退货流程的通俗方法：

购买下单流程测试

加购测试：像平时购物一样，选好商品，点击 “加入购物车”，看看商品是不是真的进了购物车，数量、规格啥的对不对。
下单测试：从购物车结算或者直接购买，填好收货地址、选择支付方式等信息，点 “提交订单”，看能不能顺利生成订单，订单信息准不准。
支付测试：选好支付渠道，比如微信、支付宝或者银行卡，输密码或者做其他支付操作，看能不能支付成功，支付后订单状态会不会变成 “已支付”。
异常测试：故意填错收货地址、用没钱的卡支付、网络断了等，看看系统会不会提示错误，能不能处理这些异常情况。

退货流程测试

发起退货：找到已经买的商品，点 “申请退货”，选好退货原因、退货数量，提交申请，看商家那边能不能收到申请，自己这边显示的申请状态对不对。
审核环节：等商家审核，看看审核时间是不是在规定范围内，审核结果会不会正确显示，比如同意退货或者拒绝退货。
退货寄件：商家同意退货后，填好物流单号寄回商品，看系统能不能正确记录物流信息，有没有提示寄件成功。
收货退款：商家收到退货后，检查商品没问题，应该给退款，看看钱是不是能退到原来支付的地方，退款金额对不对，退款后的订单状态是不是变成 “已退货”

4.1.4 什么是sql 注入，什么是跨站脚本，什么是跨站请求伪造？

以下是对 SQL 注入、跨站脚本、跨站请求伪造的通俗解释：

SQL 注入

SQL 注入就像是黑客偷偷往你和数据库之间传递的信息里加了坏代码。比如你在一个登录框输入用户名和密码，正常应该是去数据库查有没有这个用户。但黑客会输入一些特殊的 SQL 语句，让数据库以为是正常命令，从而执行一些危险操作，像获取用户数据、修改数据甚至删除整个数据库内容。

跨站脚本（XSS）

跨站脚本就好像黑客在一个正规网站的页面里偷偷藏了恶意的脚本程序。当你访问这个被攻击的页面时，你的浏览器不知道这是坏东西，就会运行这个脚本。然后黑客就可以通过这个脚本做坏事，比如偷你的账号密码、获取你的浏览记录，还能修改网页内容让它看起来乱七八糟。

跨站请求伪造（CSRF）

跨站请求伪造就像黑客骗你去做一些你不想做的事情。比如你已经登录了银行网站，在没退出的情况下又访问了一个被黑客控制的恶意网站。黑客在这个恶意网站里偷偷放了一些代码，会让你的浏览器以为你自己主动向银行网站发送了转账等操作请求，而银行网站不知道是被骗了，就会执行这个请求，导致你的钱被转走或者其他操作被恶意执行。

4.1.5 给你一个网站怎么开展测试？

拿到一个网站进行测试可以从以下几个方面入手：

功能测试

链接测试：点点所有链接，看能不能打开正确页面，有没有死链。
表单测试：在登录框、搜索框等表单里输各种内容，看看能不能正常提交、验证，数据存得对不对。
按钮测试：按按按钮，像提交、删除、返回这些，看看反应是不是对的，有没有啥异常。
导航测试：用用导航栏、菜单，看能不能方便地找到各个页面，层级和切换是不是顺畅。

性能测试

加载速度：看页面打开要多久，图片、脚本这些加载快不快，会不会卡。
响应时间：操作一下，比如搜索、提交，看看系统多久给回应。
压力测试：模拟好多人同时用这个网站，看看会不会变慢、崩溃，数据会不会乱。

兼容性测试

浏览器：在 IE、Chrome、Firefox 这些常见浏览器上看看网站样子和功能对不对，有没有显示错乱。
设备：在电脑、平板、手机上都试试，看看布局和操作是不是都正常，有没有适配问题。

安全测试

登录安全：看看账号密码是不是加密存的，有没有防暴力破解的办法。
数据传输：传数据的时候，比如登录、支付，看看是不是加密的，会不会被人偷。
漏洞检查：找找有没有 SQL 注入、跨站脚本这些漏洞，防止黑客攻击。

界面测试

布局：看看页面上的东西排得整不整齐，有没有重叠、错位，看着是不是舒服。
风格：颜色搭配、字体啥的是不是协调统一，符合网站的风格定位。

4.1.6 电商支付模块的测试如何展开？

电商支付模块测试可从以下方面展开：

基本功能测试

支付方式：测试微信、支付宝、银行卡等常见支付方式能否顺利完成支付，检查支付成功、失败、取消等各种场景。
金额准确性：分别用整数、小数、大额、小额等不同金额测试，确保支付金额与订单金额一致，找零、优惠计算准确。
支付流程：检查从选择支付方式到输入密码或验证码，再到支付结果反馈的整个流程是否顺畅，有无卡顿、报错。

异常情况测试

网络问题：模拟断网、弱网环境，查看支付是否能正确处理，如显示加载中、自动重试或提示网络异常，网络恢复后能否继续支付。
支付风险：故意输错密码、验证码，或使用挂失、冻结的卡支付，检查系统是否有相应提示和限制，能否防止盗刷等风险。
并发支付：模拟多人同时支付同一商品或大量订单并发支付，检查系统是否能正常处理，有无超卖、数据混乱等问题。

兼容性测试

设备兼容：在手机、平板、电脑等不同设备上进行支付测试，确保支付页面显示正常，功能无异常。
系统兼容：针对不同操作系统，如 iOS、安卓、Windows 等，测试支付模块的兼容性，保证支付流程顺畅。
浏览器兼容：在主流浏览器如 Chrome、Safari、微信浏览器等中进行支付测试，查看是否有兼容性问题。

安全测试

数据加密：检查支付过程中用户账号、密码、银行卡号等敏感信息是否加密传输和存储，防止信息泄露。
防篡改测试：尝试篡改支付金额、订单信息等数据，检查系统能否识别并阻止，确保支付安全。
接口安全：检测支付接口是否有防攻击机制，如防止 SQL 注入、XSS 攻击等，保障接口安全。

其他测试

支付记录：查看支付成功后，订单状态是否正确更新，支付记录是否完整、准确，可查询和追溯。
退款功能：测试正常退款、部分退款等情况，检查退款流程是否顺畅，退款金额是否准确到账。

4.1.7 如何开展兼容性测试？web兼容性测试？App兼容性测试？

以下是关于如何开展 web 兼容性测试和 App 兼容性测试的通俗解释：

web 兼容性测试

浏览器：找 IE、Chrome、Firefox、Safari 等常见浏览器，看网页在这些浏览器里打开后，页面布局乱不乱，按钮、菜单能不能点，图片、视频显示正不正常，脚本运行有没有错。
分辨率：把电脑屏幕分辨率调成各种常见的尺寸，像 1920×1080、1366×768 等，看网页内容会不会挤在一起或者有空缺，排版是不是合理。
操作系统：在 Windows、Mac OS、Linux 这些系统上打开网页，检查网页的功能和显示有没有问题，比如字体、颜色会不会变样。
网络：用 4G、5G、Wi-Fi，还有模拟慢速网络，看看网页加载速度怎么样，会不会有加载不全或者加载出错的情况。

App 兼容性测试

操作系统：对安卓和 iOS 系统，要覆盖不同的版本，像安卓 10、11、12，iOS 14、15、16 等，看看 App 在这些系统上能不能正常安装、打开，功能用起来有没有问题，界面会不会变形。
设备型号：选不同品牌、不同尺寸的手机和平板，像华为、苹果、小米、三星等，看看 App 在这些设备上的显示效果、触摸操作、性能表现等是不是都正常，有没有适配问题。
屏幕尺寸和分辨率：考虑不同的屏幕大小和分辨率，检查 App 的界面布局、图片显示等会不会因为屏幕的不同而出现显示异常，按钮是不是容易点到。
硬件功能：测试 App 用到的手机硬件功能，比如摄像头、麦克风、蓝牙、GPS 等，看看在不同设备上调用这些功能时是不是正常，有没有权限问题或者功能失效的情况。

其次借助第三方测试工具，对于APP 的兼容性测试，推荐的是百度众测平台和云测平台，我经常使用的是云测平台，这两款测试工具里面包含了安卓和iOS 的测试；测试很齐全，包括功能测试、深度兼容测试、性能测试、网络环境测试，还可以模拟海量用户测试，，还可以导入自己编写的测试用例进行功能测试，里面还包括测试专家的测试，当然了找专家是要花钱滴。基本进行兼容性测试是不需要花钱的；测试工程师把打包好的apk 或者IPA 文件，上传到测试平台，选择需要测试的设备型号，开始任务即可；等待一段时间，在等待的时间你是不需要盯着的，你可以做其他的工作。测试完成后会生成一份测试报告，可以查看错误页面和错误日志，如果需要调整，那么提交bug，告知程序员修改即可。

4.1.8 nginx,tomcat,apache 都是什么？

Nginx、Tomcat、Apache 都是常见的服务器软件，它们的功能和特点各有不同：

Nginx：像个聪明的交通指挥员。主要用来处理 HTTP 请求，能高效地分发流量，让网站可以应对很多人同时访问。还能做反向代理、负载均衡，把请求合理分配到不同服务器上，也能缓存一些常用数据，加快网站访问速度。
Tomcat：好比是 Java 程序的专属舞台。专门用来运行 Java 编写的 Web 应用程序，像 JSP、Servlet 这些。为 Java 程序提供运行需要的环境，让它们能正常展示网页、处理业务逻辑等。
Apache：就像个勤劳的搬运工。主要职责是接收和处理 HTTP 请求，把网页内容准确地发送给用户。能处理静态网页，性能稳定，有很多模块可以扩展功能，是 Web 服务器领域的老牌选手。

4.1.9 apache 和 nginx 的区别？

Apache 和 Nginx 有以下区别：

处理请求方式
- Apache：像个勤劳的多面手，采用多进程或多线程模式，每个请求都派一个 “小助手” 专门处理，在处理动态请求上经验丰富，但人多了有时会忙不过来。
- Nginx：像个高效的调度员，采用事件驱动的异步非阻塞模式，一个人能同时处理好多事，擅长快速处理静态请求，并发处理能力强，能轻松应对大量连接。
功能侧重
- Apache：以强大的模块系统著称，有很多功能模块，能通过各种模块来实现各种复杂功能，如身份验证、加密等，配置相对灵活复杂。
- Nginx：主打高性能的 HTTP 服务器和反向代理功能，在反向代理、负载均衡方面表现出色，配置简洁，容易上手。
适用场景
- Apache：适合对动态内容处理要求高、需要大量模块扩展功能的网站，如一些传统的企业级应用网站。
- Nginx：适合高并发、对静态资源请求多的场景，像大型门户网站、电商网站等的前端服务器，常用来做动静分离。

4.1.10 Selenium 有哪些定位元素方法？Playwright 有那些定位元素的方法？Selenium 和 Playwright 的区别？

Selenium 和 Playwright 都是常用的自动化测试工具，以下是它们定位元素的方法及二者的区别：

Selenium 定位元素方法

id 定位：好比按身份证找人，每个元素的 id 是唯一的，通过它能快速精准找到元素。
name 定位：类似按名字找人，用元素的 name 属性来定位，不过可能有重名，不一定很准。
class name 定位：像按衣服款式找人，通过元素的 class 属性找，可能找到一群穿 “同款衣服” 的元素。
tag name 定位：如同按职业找人，用元素的标签名找，比如所有的按钮都叫 button，会找到一堆同类型的。
xpath 定位：像是给元素画了张详细地图，通过路径表达式精准描述元素位置，能定位复杂结构的元素。
css selector 定位：类似用地址找小区里的房子，通过 CSS 选择器规则来定位，也很灵活精准。

Playwright 定位元素方法

按选择器定位：和 Selenium 的 css selector 类似，用 CSS 选择器规则来精准找到元素。
按文本定位：就像按人说的话找人，通过元素里显示的文本内容来定位，很直观。
按属性定位：如同按人的特征找人，利用元素的属性，比如 data-id 等自定义属性来定位。
按角色定位：类似按人的身份定位，根据元素的角色，像按钮、输入框等角色来定位元素。

Selenium 和 Playwright 的区别

语言支持
- Selenium：支持多种语言，如 Java、Python、C# 等，方便不同技术背景的人使用。
- Playwright：主要支持 JavaScript、Python 和.NET，对前端开发人员和 Python 开发者友好。
操作体验
- Selenium：操作浏览器比较直接，通过各种命令模拟用户操作，但对新特性支持可能慢些。
- Playwright：操作更现代、灵活，能更方便地处理新的浏览器特性，像处理弹出框、多标签页等。
执行速度
- Selenium：执行速度相对受浏览器和驱动影响，在高并发场景可能性能有瓶颈。
- Playwright：采用多进程架构，执行速度快，在处理大量自动化任务时效率更高。
跨浏览器支持
- Selenium：需要针对不同浏览器安装相应驱动，配置相对繁琐。
- Playwright：内置对多种浏览器支持，无需额外安装驱动，配置简单。

5.App 测试

5.1 App 测试

5.1.1 什么是Android 四大组件？

Android 四大组件是 Activity（活动）、Service（服务）、Broadcast Receiver（广播接收器）和 Content Provider（内容提供者），以下是具体介绍：

Activity（活动）：相当于 APP 里的一个个页面，比如微信的聊天页面、朋友圈页面等，负责和用户交互，展示内容和获取用户输入。
Service（服务）：就像在后台默默工作的小助手，不提供直接的用户界面，比如音乐播放服务、文件下载服务，在后台完成特定任务。
Broadcast Receiver（广播接收器）：像是消息的 “小耳朵”，用来接收系统或应用发出的各种广播消息，比如电池电量变化、网络连接变化等广播，然后做出相应反应。
Content Provider（内容提供者）：如同一个数据仓库管理员，用于在不同的应用之间共享和存储数据，比如可以让一个应用访问另一个应用的联系人数据等。

5.1.2 当点击APP 图标启动程序，说明将要发生那些过程？

当点击 APP 图标启动程序，会发生以下过程：

系统响应：手机系统收到点击信号，知道你要打开 APP，开始准备工作。
加载 APP 信息：从手机存储里找到 APP 的相关数据和代码，读取配置文件等，了解 APP 长啥样、有啥功能。
初始化进程：为 APP 开辟一块专属的运行空间，安排好各种资源，像给 APP 准备好工作场地和工具。
检查更新：有些 APP 会趁机看看有没有新版本，有的话可能提示你更新。
连接服务器：如果 APP 需要联网获取数据，就开始和服务器建立连接，像向服务器 “打招呼” 要数据。
显示启动界面：先给你展示一个启动画面，让你知道 APP 在努力启动中。
加载主界面：把 APP 的主界面显示出来，包括各种按钮、菜单、内容等，准备好让你使用。
加载数据：把 APP 运行需要的数据，比如用户信息、设置、新闻内容等都加载进来，让 APP 能正常工作。

5.1.3 APP 测试的内容主要包括哪些，如何开展？

功能测试

内容：检查 APP 各项功能是否正常，如注册登录、数据查询、支付、消息推送等功能是否可用，有无漏洞。
开展方式：按照功能模块编写测试用例，逐一操作各项功能，检查是否符合预期结果，可采用黑盒测试方法，关注输入与输出是否正确。

性能测试

内容：测试 APP 的响应时间、吞吐量、内存使用、CPU 占用等性能指标，看在不同负载下运行是否流畅稳定。
开展方式：使用专业性能测试工具，模拟不同用户数量和操作频率，监测性能指标变化，分析是否存在性能瓶颈。

兼容性测试

内容：测试 APP 在不同操作系统版本、设备型号、屏幕分辨率下的兼容性，确保显示和功能正常。
开展方式：选取主流的操作系统和设备型号，安装 APP 进行测试，检查界面是否适配、功能是否可用，也可借助云测试平台提高效率。

异常测试

热启动应用:应用在后台长时间待机;应用在后台待机过程中，手机重启
网络切换和中断恢复:网络切换;中断恢复：
电话信息中断恢复升级，安装。

卸载测试

升级测试：临近版本升级(1.0->1.1);跨版本(1.0->....->2.2)
安装测试：首次安装;覆盖安装(同版本，不同版本覆盖);卸载后安装
卸载测试：首次卸载;卸载安装后在卸载

安全测试

内容：检查 APP 的用户数据加密、网络传输安全、权限管理等是否存在安全漏洞，防止数据泄露等问题。
开展方式：利用安全测试工具进行漏洞扫描，检查代码中的安全隐患，模拟攻击场景验证系统的安全性。

界面测试

内容：评估 APP 界面的布局、色彩搭配、字体、图标等是否美观、易用，符合设计规范和用户习惯。
开展方式：对照设计稿，通过人工查看和操作，检查界面元素是否显示正常、布局是否合理，关注用户操作的便捷性和视觉效果。

稳定性测试

内容：测试 APP 在长时间运行和大量操作下是否会出现崩溃、卡顿、数据丢失等问题，确保系统稳定。
开展方式：采用自动化测试工具，编写脚本模拟长时间、高频率的操作，记录 APP 运行状态，观察是否出现异常。

5.1.4 Android 的兼容性测试都考虑哪些内容？

Android 的兼容性测试主要考虑以下内容：

操作系统版本

不同 Android 系统版本有不同特性和 API，要测试 APP 在各主流版本上的功能、界面显示等是否正常，像低版本不支持的新特性在高版本上能否正常运行，高版本的新限制是否影响 APP 在低版本的使用。

设备型号与厂商

不同厂商的设备，如华为、小米、OPPO 等，硬件特性和定制系统不同，要检查 APP 在各种设备上的性能、稳定性，比如摄像头、传感器等硬件功能调用是否正常，有无因厂商定制导致的兼容性问题。

屏幕分辨率与尺寸

从小屏手机到平板，屏幕分辨率和尺寸多样，要确保 APP 界面布局合理、元素显示完整且操作流畅，不会出现按钮重叠、文字截断等问题。

硬件差异

设备的 CPU、GPU、内存等硬件配置有别，需测试 APP 在不同性能硬件上的运行情况，如是否能流畅运行大型游戏或处理大量数据，有无卡顿、发热、耗电快等问题。

网络环境

涵盖 2G、3G、4G、5G 和 Wi-Fi 等网络，要验证 APP 在不同网络类型和信号强度下的网络连接稳定性、数据传输准确性，比如加载图片、视频是否正常，在线支付是否成功。

应用间交互

APP 可能与系统应用或其他第三方应用交互，要测试与常见应用的兼容性，如分享功能是否能正常调起其他应用，被其他应用调用时是否稳定。

特殊设置与功能

考虑设备的语言、时区、无障碍设置等，检查 APP 在不同语言环境下文字显示和功能是否正常，在特殊设置下是否能正确响应。

5.1.5 针对App 的安装功能，写出测试点？

针对 App 的安装功能，测试点主要有以下这些：

基本安装

正常安装：从应用商店或其他正规渠道下载后，点击安装按钮，看能否顺利安装到手机上。
不同来源安装：除应用商店外，试试从官网、第三方平台等不同来源下载安装包，看是否都能成功安装。

安装选项

权限授予：安装过程中，检查各项权限请求是否正常弹出，如相机、麦克风等权限，点击允许或拒绝后，App 功能是否受影响。
安装位置选择：若手机支持，看看能否选择安装到手机内存或 SD 卡，安装后 App 运行是否正常。

环境相关

不同系统版本：在各种主流及非主流的 Android 或 iOS 系统版本上安装，检查是否有兼容性问题。
不同设备：在不同品牌、型号、屏幕尺寸的手机、平板等设备上安装，查看安装是否顺利及运行效果。

特殊情况

空间不足：故意让手机存储剩余空间很少，测试安装时是否有足够空间，是否有提示及应对措施。
中断安装：安装过程中，试试中断操作，如关机、切换网络、插拔 SD 卡等，之后能否继续安装或恢复正常。
重复安装：已安装该 App 的情况下，再次安装，看是提示更新还是覆盖安装，数据是否丢失。
安装依赖：若 App 有依赖的其他软件或插件，检查不安装依赖时能否安装成功，安装顺序是否有要求。
App 版本覆盖测试：先安装一个1.0 版本的App，再安装一个高版本(1.1 版本)的App，检查是否被覆盖。
回退版本测试：先装一个2.0 版本的App，再安装一个1.0 版本的App，正常情况下版本是可以回退的。

安装后检查

图标与快捷方式：安装完成后，查看手机桌面是否有 App 图标，图标是否显示正常，点击能否打开 App。
功能检查：进入 App，简单测试各项主要功能，看是否能正常使用，数据是否加载正确。

5.1.6 常用的ADB 命令？

ADB（Android Debug Bridge）是安卓开发和测试中常用的工具，以下是一些常用的 ADB 命令：

adb devices：查看连接到电脑的安卓设备列表，能让你知道有哪些设备可以操作。
adb install [apk 路径]：用于安装 APK 文件到安卓设备上，比如 “adb install C:\test.apk” 就能把 test.apk 安装到设备。
adb uninstall [包名]：卸载设备上的应用，只要输入应用的包名就能卸载，如 “adb uninstall com.example.app”。
adb shell：进入设备的命令行界面，就像打开了设备的 “控制台”，可以执行更多设备内部的命令。
adb pull [设备路径] [本地路径]：从设备上拉取文件到电脑，例如 “adb pull /sdcard/test.txt C:\” 能把设备上的 test.txt 文件复制到电脑 C 盘。
adb push [本地路径] [设备路径]：把电脑上的文件推送到设备，和 pull 相反，如 “adb push C:\test.txt/sdcard/”。
adb logcat：查看设备的日志信息，能帮助开发者了解应用运行情况，排查问题。
adb reboot：重启安卓设备，简单直接让设备重启。
adb kill-server：关闭 ADB 服务器，有时出现问题可以先关闭再重新启动来解决。
adb start-server：启动 ADB 服务器，一般电脑连接设备后自动启动，必要时也可以手动启动。

5.1.7 在查看 logcat 命令日志时候怎么内容保存到本地文件？

输出重定向：logcat >> log_file_name

5.1.8 App 崩溃（闪退），可能是什么原因导致的？

App 崩溃（闪退）可能有以下原因：

代码问题

空指针异常：程序用到了不该为空的对象，结果发现是空的，就像要打开一个不存在的盒子，肯定会出问题。
数组越界：访问数组元素时超出了数组的范围，好比去一个只有 5 个房间的楼里找第 6 个房间，肯定找不到就崩溃了。
内存泄漏：程序不断申请内存却不释放，内存被占满了，App 就像没地方放东西的仓库，只能崩溃。

系统兼容性

版本不兼容：App 用了新系统的特性，但用户手机是旧系统，或者反过来，就像新钥匙开不了旧锁。
设备差异：不同手机的硬件、屏幕尺寸、分辨率不同，App 在某些设备上显示或运行可能会出问题，就像胖瘦不同的人穿同一件衣服效果不一样。

数据问题

数据冲突：多个数据来源的信息相互矛盾，让 App 不知道该听谁的，比如同时收到两条不一样的指令。
数据损坏：数据在传输或存储过程中出了错，App 读取到坏数据就像读了一本缺页错字的书，没法正常运行。

网络问题

网络不稳定：网络时断时续，App 加载数据不完整，就像拼图少了几块，肯定拼不出来。
网络异常：网络突然中断，正在进行的网络请求没完成，App 可能就不知道该怎么办了，只好崩溃。

外部因素

权限不足：App 需要的权限没被用户允许，像拍照 App 没拿到相机权限，要用的时候就会崩溃。
其他软件冲突：手机上其他软件和 App 有冲突，就像两个人抢着用一个东西，容易出乱子。

5.1.9 如何测试监测app 的内存使用、CPU 消耗、流量使用情况？

以下是测试监测 App 内存使用、CPU 消耗、流量使用情况的方法：

测试工具

Android：一般用 Android Studio 自带的 Profiler，能直观看到 App 内存、CPU、流量的实时数据变化，好比给 App 装了个 “体检仪”。也可以用命令行工具 ADB，输入相关命令获取这些数据信息。
iOS：通常使用 Xcode 的 Instruments 工具，它就像一个 “多面手”，能深入分析 App 各方面性能，包括内存、CPU 和流量使用情况。

测试场景

启动 App：监测启动时的资源占用，看内存是不是一下子升很高，CPU 是不是忙不过来，有没有异常的流量消耗，就像看一个人刚起跑时的状态。
切换页面：在 App 不同页面间快速切换，观察内存、CPU 有没有突然大幅波动，流量有没有不正常的增加，好比观察一个人在不同房间穿梭时的状态。
执行功能：使用 App 的各种功能，像拍照、上传文件等，看这些操作下内存、CPU 的变化，以及流量消耗是否合理，如同看一个人做不同工作时的能量消耗。
后台运行：把 App 放后台，过一会儿看看内存有没有持续增加，CPU 是不是还在高负荷运转，流量有没有异常，就像看一个人休息时是否还在偷偷 “干活”。
长时间运行：让 App 运行很长时间，观察内存会不会越用越多，CPU 会不会过热，流量是不是一直稳定，类似看一个人长时间工作后的状态。

5.1.10 弱网测试怎么测？Fiddler怎么进行弱网测试？

以下是关于弱网测试及 Fiddler 进行弱网测试的通俗解释：

弱网测试方法

模拟工具：用专业的网络模拟工具，像 NetEm、Network Link Conditioner 等，能设置各种网络参数，模拟出网络不稳定、信号差的情况，看看 App 在这种条件下的表现，比如加载速度、数据传输是否正常，会不会报错。
真机测试：去一些真实的网络信号不好的地方，比如地下室、偏远山区，直接用手机等真机运行 App，检查它在实际弱网环境中的功能是否受影响，页面加载是不是很慢，视频会不会卡顿。
运营商设置：有些运营商提供网络限制的设置选项，可以通过调整这些设置来降低网络速度和质量，以此测试 App 在不同弱网条件下的稳定性和兼容性。

Fiddler 弱网测试步骤

打开设置：打开 Fiddler，在菜单栏找到 Rules，点击下拉菜单中的 Customize Rules，会弹出一个脚本编辑窗口。
设置规则：在脚本编辑窗口里找到 “OnBeforeResponse” 函数，在里面添加代码来设置弱网条件，比如修改响应速度、丢包率等参数。例如，想要设置 3G 网络的速度，可以添加代码来限制下载和上传速度。
启用规则：修改完代码后保存，然后在 Fiddler 的 Rules 菜单中，确保你设置的弱网规则被勾选启用，这样 Fiddler 就开始按照设定的弱网条件来拦截和处理网络请求了。
进行测试：在手机或其他设备上运行要测试的 App，Fiddler 会拦截 App 的网络请求，并按照设置的弱网条件来模拟网络环境，观察 App 在这种弱网情况下的各种表现，如页面加载时间、数据是否加载完整、操作是否卡顿等。

5.1.11 Appium 是什么？如何使用？以一个真实的测试用例，用Appium编码进行测试?

以下是关于 Appium 的相关解释：

Appium 是什么

Appium 是一款开源的移动端自动化测试框架，能让你用多种编程语言，比如 Java、Python 等，来写代码测试手机应用，不管是安卓还是 iOS 系统的 App 都能测，就像是一个能帮你自动操作手机 App 的 “小助手”，可以模拟点击、滑动等各种操作来检查 App 功能对不对、好不好用。

Appium 如何使用

环境搭建：得先装 Appium 服务器，再把相关的驱动程序准备好，像安卓的 adb、iOS 的 Xcode 相关工具等，还要配置好测试用的编程语言环境，比如 Python 得装好相关库。
连接设备：用 USB 线或者通过网络把手机或模拟器连到电脑上，让 Appium 能找到要测试的设备。
编写脚本：用你熟悉的编程语言写测试脚本，告诉 Appium 要测什么，比如打开 App、点击某个按钮、输入文字等操作。
执行测试：运行写好的脚本，Appium 就会按照你的指令去操作 App，然后检查操作结果对不对，把测试结果反馈给你。

测试用例及代码示例

假设要测试一个简单的安卓计算器 App，检查加法运算功能是否正确，用 Python 和 Appium 来写测试代码如下：

import time
from appium import webdriver

# 设备及App配置信息
desired_caps = {
    'platformName': 'Android',
    'platformVersion': '11',
    'deviceName': 'Pixel 5',
    'appPackage': 'com.example.calculator',
    'appActivity': 'com.example.calculator.MainActivity'
}

# 启动Appium驱动，连接设备并打开App
driver = webdriver.Remote('http://localhost:4723/wd/hub', desired_caps)

# 点击数字按钮
driver.find_element_by_id('digit_5').click()
driver.find_element_by_id('plus_button').click()
driver.find_element_by_id('digit_3').click()
driver.find_element_by_id('equal_button').click()

# 等待计算结果显示
time.sleep(2)

# 获取结果文本
result = driver.find_element_by_id('result_text').text

# 验证结果是否正确
assert result == '8'

# 关闭App
driver.quit()

posted @ 2025-02-13 22:45 没关系都是…… 阅读(34) 评论(0) 编辑收藏举报

刷新页面返回顶部

登录后才能查看或发表评论，立即登录或者逛逛博客园首页

相关博文：

· 01 设计测试用例

· Jmeter如何做性能测试

· 软件测试基础知识篇

· 软件测试基础知识 + 面试理论（超详细）

· 软件测试相关的面试题及答案

阅读排行：
· 分享4款.NET开源、免费、实用的商城系统
· 全程不用写代码，我用AI程序员写了一个飞机大战
· MongoDB 8.0这个新功能碉堡了，比商业数据库还牛
· 白话解读 Dapr 1.15：你的「微服务管家」又秀新绝活了
· 记一次.NET内存居高不下排查解决与启示

公告

昵称：没关系都是……
园龄： 1年10个月
粉丝： 0
关注： 0

+加关注

2025年3月

日

一

二

三

四

五

六

you-ni

测试面试题（通俗易懂）持续更新ing

1 测试理论

1.1 测试基础

1.1.1 什么是软件测试？

1.1.2 软件测试的目的？

1.1.3 软件测试的目标？

1.1.4 软件测试的原则？

1.1.5 测试的工作流程？

1.1.6 测试工程师的职责？

1.1.7 软件的分类？

1.1.8 测试的主要方面？

1.1.9 软件测试的对象？

1.1.10 什么是“测试案例”？

1.1.11 怎么编写测试案例？

1.1.12 软件测试的两种方法？

1.1.13 测试结束的标准是什么？

1.1.14 软件的生命周期？

1.1.15 软件测试按过程分为三个步骤？

1.1.16 面向对象的设计如何影响测试？

1.1.17 软件带来错误的原因很多。主要的原因有哪些？

1.1.18 做好软件测试的一些关键点？

1.1.19 软件测试的步骤是什么？

1.1.20 如何录制测试脚本？

1.1.21 软件测试的测试方法包括哪些？

1.1.22 怎样估计测试工作量？

1.1.23 测试设计的问题？

1.1.24 当测试过程发生错误时，有哪几种解决办法？

1.1.25 测试执行的问题？

1.1.26 测试评估的目标？

1.1.27 如何提高测试？

1.1.28 C/S 模式的优点和缺点？

1.1.29 B/S 模式的优点和缺点？

1.1.30 测试结束的标准是什么？

1.1.31 怎么才能够全面的测试到每一个点？

1.1.32 开发与测试的关系？

1.1.33 测试怎么和开发沟通？

1.1.34 测试过程？

1.1.35 测试出口准则？

1.1.36 测试完成标准？

1.1.37 测试活动中统计了那些数据?

1.1.38 如何选择用户测试的工作产品？

1.1.39 测试环境描述在哪儿？

1.1.40 进行测试时产生了哪些文档或记录？

1.1.41 测试人员需要何时参加需求分析？

1.1.42 产品测试完以后由谁来发布？

1.1.43 软件测试与调试的关系

1.1.44 质量的八大特性是什么？各种特性的定义？

1.1.45 什么是软件的“质量”？

1.1.46 软件质量应该从哪些方面来评价？

1.1.47 什么是“软件质量保障”？

1.1.48 为什么软件会有毛病？

1.1.49 什么是 UML ？

1.1.50 什么是 CMM ？

1.1.51 比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系？

1.1.52 比较负载测试、压力测试，容量测试和强度测试区别？

1.1.53 测试执行过程的三个阶段？

1.1.54 什么是验证、评价、预排、检查？

1.1.55 什么是兼容性测试？兼容性测试侧重哪些方面？

1.1.56 我现在有个程序，发现在 Windows 上运行得很慢，怎么判别是程序存在问题还是软硬件系统存在问题？

1.1.57 测试的策略有哪些？

1.1.58 正交表测试用例设计方法的特点是什么？

1.1.59 描述使用 禅道，TAPD 缺陷管理工具对软件缺陷（BUG）跟踪的管理的流程？

1.1.60 描述测试用例设计的完整过程？

1.1.61 单元测试的策略有哪些？

1.1.62 你所熟悉的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……）？

1.1.63 软件缺陷（或者叫 Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？

1.1.64 软件的评审一般由哪些人参加？其目的是什么？

1.1.65 测试活动中，如果发现需求文档不完善或者不准确，怎么处理？

1.1.66 阶段评审与项目评审有什么区别？

1.1.67 阐述工作版本的定义？

1.1.68 什么是桩模块？什么是驱动模块？

1.1.69 什么是扇入？什么是扇出？

1.1.70 你认为做好测试计划工作的关键是什么？

1.1.71 你觉得对于测试有哪些基本素质要求？

1.1.72 一套完整的测试应该由哪些阶段组成？

1.1.73 软件测试的流程是什么？

1.1.74 说说你对 SQA 的职责和工作活动(如软件度量)的理解？

1.1.75 单元测试的主要内容？

1.1.76 集成测试也叫组装测试或者联合测试，请简述集成测试的主要内容？

1.1.59 描述使用禅道，TAPD 缺陷管理工具对软件缺陷（BUG）跟踪的管理的流程？

1.1.110 阐述软件生命周期都有哪些阶段？常见的软件生命周期模型有哪些？