测试面试题总结
功能测试
1.app和web测试的相同点和不同点 ***
相同点：
A.测试用例相同。
B.同样的测试方法：都会依据效果图来检查UI,根据需求文档测试功能。
C.都需要兼容性测试
D.都需要测试应用系统的稳定性。
不同点：
A.App的安装卸载测试（全新安装，升级安装，第三方工具安装，第三方工具卸载，直接卸载删除）,web没有安装卸载一说
B.app消息推送测试，手机授权测试，前后台切换。
C.App的中断测试：来电中断，短信中断，蓝牙，闹钟，拔插数据线，手机锁定，手机断电，手机问题（系统死机重启）。
D.兼容性测试：Web项目考虑不同内核的浏览器兼容，app需要考虑手机不同的操作系统（android/ios），不同的操作系统版本,不同机型，不同屏幕分辨率等。
E.网路测试：不同网络与运营商，目前我国有三大运营商如：电信，移动，联通，不同的网络制式，如：GSM,CDMA,3G，4G，5G等，在不好或无网络的情况下的APP行为。
F.app测试如果设备不足，可以考虑使用云测平台（百度云测，testin云测等）。
2.app测试的关注点/app测试一般测哪些东西 ***
功能测试，安装卸载测试，升级测试，安全性测试，消息推送，前后台切换，ui测试，兼容性测试，网络环境测试，性能测试，中断测试
3.web测试的关注点 ***
功能测试，兼容性测试，ui测试 ,安全性测试
4.如何确保测试用例覆盖所有需求点 /如何保证产品的质量**
测试用例覆盖率很难达到100%，越复杂的功能越难保证，只能说尽量提高测试覆盖率。
通过以下手段可以提高覆盖率：
1、编写测试用例前，检查相关需求、设计文档是否有问题（功能描述不清，设计逻辑缺陷），如有问题找相关设计或者开发问清楚。
2、然后整理成需要覆盖的功能列表或者思维导图，功能列表包含新增和修改功能点，性能需求也要列出来（因为要整理对应的性能测试用例）
3、需要对既有功能进行一个梳理（显性需求和隐形需求都要分析），还需要检查是否会与其他功能有交互，整理出影响点。
4、把功能列表发给组员，并找时间进行会议评审，主要对功能等进行查漏补缺。
5、最后才行进测试用例编写，注意编写规范。
6、编写完毕后，把测试用例发给组员，开会进行评审，主要对检查点、用例规范进行查漏补缺。
7、执行测试用例过程中，发现用例不完善或者错误，需对测试用例进行及时的修改与调优
8、测试完毕后对漏测的bug进行测试用例补充。
5.你提交bug的时候提交哪些内容？***
标题，复现步骤，预期结果，实际结果，测试环境，优先级，严重程度，指派给谁，所属模块，附件，缺陷类型
6.bug状态/bug流转过程 **
新建：刚发现的缺陷 已指派：已经由测试人员将缺陷指派给开发人员进行处理 已打开：开发人员正在修复缺陷 已修复：开发人员完成缺陷修复，还未进行回归测试 已拒绝：发开人员拒绝修复 已延期：对缺陷进行延缓处理 已关闭：由测试人员回归测试后，缺陷不存在了 重新打开：由测试人员回归测试后，发现缺陷任然存在
7.开发不认bug/如果你发现了一个bug，开发不认，怎么办？***
1.找开发沟通，看他为什么不认,可能有两种情况
2.第一种情况：开发可能说，产品改需求了，
----我们需要找产品确认，如果是改了，根据新需求改用例，改完重新测试
---- 如果产品说没有改，把他们叫到一起，确认
3.第二种情况：需求没有改，双方理解的需求不一致，一起找产品确定，
----开发理解的正确，根据新的理解改用例，改完重新测试
----我们理解的正确，让开发改bug
8.bug不能复现咋办？ **
A.首先考虑环境问题，看是否能够还原原来的环境
B.尽量回想发生问题时的复现步骤，不要漏掉任何一个细节，按照步骤的组合尝试复现
C.与开发人员配合，让开发人员对相应的代码检查，看是否通过代码层面检查出问题
D.保留发生bug时的log，附加到提交的Bug中，希望可以通过log中找到一些蛛丝马迹。
E.查看代码，也许是代码变更，引起的Bug
F.遇到问题就要提，不能放过任何一个Bug，在提交的Bug描述中加上一句话，那就是复现概率，尝试20次，出现一次或尝试10次，交给开发，开发会根据Bug的复现概率，调整改Bug的优先级。
9.你在项目中最经典的BUG是什么？/你印象最深的一个bug ***
开放题，可以说涉及到前后端的问题,将定位饭分析的过程,之前讲过两个业务逻辑（processon上画过图）
比如
小明在淘宝app 商品详情中 点击了添加购物车 ,然后进入购物车后发现购物车中没有该条商品.
或者
小明在淘宝app中 支付了一笔订单(微信支付), 然后发现 本应该订单依然还在 待支付中, 待发货中没有该笔订单, 而小明的账户上的钱已经被扣除了.
自己编类似的bug，然后给出分析和定位问题的过程
最终问题是哪里的，你是怎么定位出来的
10.用例评审的流程，通过的规则/审核内容是什么 *
两轮：内部评审，外部评审（产品，开发）
评审内容：
1.用例设计的结构安排是否清晰、合理,是否利于高效对需求进行覆盖。
2.优先级安排是否合理。
3.是否覆盖测试需求上的所有功能点
4.用例是否具有很好可执行性.例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法
5.是否已经删除了冗余的用例
6.是否包含充分的负面测试用例（反例）。充分的定义，如果在这里使用2/8法则，那就是4倍于正面用例的量，毕竟一个健壮的软件,其中80％的代码都是在“保护”20％的功能实现
7.是否从用户层面来设计用户使用场景和使用流程的测试用例
8.是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。
9.用例是否按照公司规定模板进行编写
用例评审的检查项（不用背）：
1.用例是否按照公司定义的模板进行编写
2.用例的本身描述是否清晰，是否存在歧义
3.用例内容是否正确，是否与需求目标一致
4.用例的期望结果是否确定，唯一
5.操作步骤应与描述一致
6.是否覆盖了所有需求 **
7.用例是否冗余 **
8.是否具有可执行性
9.是否是从用户层面来设计用户使用场景和使用流程的测试用例
10.场景测试用例是否覆盖最复杂的业务流程
11.是否包含正面，反面的用例 **
12.对于系统自动生成的输出项是否注明了生成规则
13.测试用例应包含对中间和后台数据的检查
14.是否有正确的名称和编号
15.是否标明优先级
16.是否包含配置信息：测试环境，数据，前置条件，用户授权等
17.测试步骤应具体，清晰
18.自动化测试脚本必须带有注解（包括：目的，输入，期望结果等）
19.非功能测试需求或不可测试需求是否再用例中列出并说明
11.你们公司测试计划谁写？有哪些内容 *
一般是测试经理/测试组长写，
测试目的，测试资源，测试范围，测试风险（重点），人员分工（重点），测试策略，测试准则，测试进度（重点），测试输出
12.v模型和w模型 **
13.测试用例（case）/测试点该怎么写（给定业务说测试点，比如水杯测试点，抖音评论/发红包/转账/朋友圈点赞/登录测试点）
分析：可以从 功能，性能，ui，易用性，安全，兼容性，app专项测试（如果是移动端项目的话） 这七方面展开说，采用总分的形式说，先说可以从五方面考虑，再每个方面细说，结合设计测试用例的方法
- 微信红包：
--功能-单个红包：
1、红包金额为空、0、0.01、200.00、200.01、199.99、200
2、留言输入数字、字母、汉字、特殊字符
3、留言长度
4、留言复制粘贴
5、表情选择收藏表情、其他表情
6、删除表情、重新选择表情
7、选择支付方式 零钱、银行卡、添加新卡支付。其中钱数<红包钱数、其中钱数=红包钱数、其中钱数>红包钱数
8、使用指纹确认付款（正确的、错误的指纹）
9、使用密码确认付款（正确的、错误的密码）
10、红包成功发送后 相应支付方式中钱数减少（减少金额与红包金额一致）
11、接受者能看到红包具体信息，红包金额、留言、表情均能正确显示
12、红包被拆开后显示已领取，领取者零钱中增加正确金额，再次领取只能查看红包信息
13、发红包者自己领红包
14、红包24小时未被领取提示红包被退回，相应支付方式中钱数增加（增加金额与红包金额一致），对方不能领红包
-- 功能-群发红包-普通红包：（只写了与单个红包不同的地方）
1、红包个数 为空、0、001、100、99、101
2、红包拆开每个金额一样 均为发红包时设置的单个金额对应的钱数
3、红包被拆时，有相应提示
4、发红包者自己领红包
5、红包24小时内未被拆完，剩余钱被退回，相应支付方式中钱数增加
-- 群发红包-拼手气红包：
1、红包总额/红包个数<0.01
2、红包每个人拆开金额不同，总金额与发红包设置的总额一致
3、红包24小时内拆完后显示最佳手气
4、红包24小时内未被拆完不显示最佳手气
兼容性：安卓、苹果 不同型号版本手机
UI测试：界面无错别字，风格统一, 和设计图保持一致
中断测试：不同应用之间切换、断网、来电、短信、低电量、手机没电
网络测试：2g/3g/4g/5g WiFi 移动联通电信 弱网 无网
- 朋友圈点赞：
-- 功能测试
1.点赞后是否显示结果；
2.点赞后是否可以取消；
3.点赞取消后是否可以重复点赞；
4.共同好友点赞后，是否有消息提醒；
5.非共同好友点赞后，是否有消息提醒；
6.点击点赞人昵称，是否可以跳转到他/她的主页；
7.自己能否给自己点赞；
8.屏蔽了该用户，共同好友点赞是否提示；
9.点赞人有备注时，是否展示备注昵称；
10.点赞后删除好友，是否继续展示其点赞；
-- UI界面测试
1.界面是否简介美观；
2.点赞后动态特效是否正常显示；
3.朋友圈界面图片是否正常显示；
4.朋友圈界面文字是否正常显示；
-- 性能测试
1.点赞人数过多是否能正常显示；
2.同一时间点赞人数过多是否正常收到提示；、
-- 安全测试
1.发送部分可见的朋友圈，其余人不可见；
2.发送部分可见的朋友圈，点赞后共同好友不可见；
-- 弱网测试
1.弱网环境下，点赞是否成功；
2.弱网环境下，点赞的时间；
-- 易用性测试
发送部分可见，是否可以沿用上次的名单；
- 淘宝搜索框：
-- 功能测试：
1.输入可查到结果的正常关键字，检索到的内容、链接准确性
2.输入不可查到结果的关键字，有无错误信息提示
3.输入一些特殊的内容，如空字符、特殊字符等，可引入等价类划分的方法等
4.返回的商品结果排序：价格、销量、评价、综合
5.返回结果庞大时，限制第一页的输出量，需支持翻页
6.多选项搜索：关键字、品牌、产地、价格区间、 是否天猫、是否全国购
7.是否支持模糊搜索，支持通配符的查询
8.网速慢的情况下的搜索
9.搜索结果为空的情况
10.未登录情况和登录情况下的搜索（登录情况下，存储用户搜索的关键字、搜索习惯）
-- 性能测试：
1.压力测试：在不同开发用户数压力下的表现（评价指标如响应时间等）
2.负载测试：看极限能承载多大用户量同时正常使用
3.稳定性测试：常规压力下能保持多久持续稳定运行
4.内存测试：有无内存泄露现象
5.大数据量测试：如模拟从海量数据中搜索结果、搜索出的海量结果列示出来，如何表现等
-- 易用性测试：
1.交互界面的设计是否便于、易于使用
2.依据不同的查询结果会有相关的人性化提示，查不到时告知，查到时统计条数并告知，有疑似输入条件错误时提示可能正确的输入项等等处理
3.查询出的结果罗列有序，如按销量或其他排序综合，确保每次查询的结果位置按规则列示方便定位，显示字体、字号、色彩便于识别等等
4.标题查询、全文检索、模糊查询、容错查询、多关键字组织查询（空格隔开）等实用检索方式是否正常
5.输入搜索条件的空间风格设计、位置摆放是否醒目便于使用者注意到，有无快照等快捷查询方式等人性化设计
-- 兼容性：
1.Windows/Linux等各类操作系统下及各版本下的应用
2.IE/Fireox/Goolge/360/QQ/edge等各类浏览器下及各版本下、各种显示分辨率条件下的应用
3.SQL/ORACLE/MySQL等各类数据库存储下的兼容性测试
4.简体中文、繁体中文、英文等各类语种软件平台下的兼容性测试
5.iphone/ipad/安卓等各类移动应用平台下的兼容性测试
6.与个相关的监控程序的兼容性测试，如输入法、杀毒、监控、防火墙等工具同时使用
-- 安全性:
1.被删除、加密、授权的数据，不允许被SQL注入等攻击方式查出，是否有安全控制设计
2.录入一些数据库查询的保留字符，如单引号、%等，造成查询SQL拼接出来的语句产生漏洞，如可以查出所有数据等等，这方面要有一些黑客攻击的思想并引入一些工具和技术，如爬网等
3.通过白盒测试技术，检查一下在程序设计上是否存在安全方面的隐患
4.对涉及国家安全、法律禁止的内容是否进行了相关的过滤和控制
- 购物车：
-- 界面测试
1.打开淘宝购物车页面后，页面的布局是否合理，是否完整。
2.不同卖家的商品在不同的table区域显示，区分明显。
3.页面的功能按钮可以正常显示。
4.商品的最下方显示失效宝贝。
5.页面的最低端显示“你可能喜欢”
6.向下滑动页面，在购物车顶端展示“购物车”。
7.购物车中如果存在有商品降价、库存不足、限购件数等，在商品详情的下面，会有对应的字体展示。
-- 基本功能
1.购物车页面的所有连接是否正常。
2.从商品信息页面添加的商品能显示在购物车中。
3.若未登录，点击购物车中的商品直接进行结算，则提示用户输入用户名和密码，或者提示用户进行注册。
4.若没有选择任何商品，点击结算，则提示用户“请添加要结算的商品”。
5.勾选商品后，已选商品的总价（和优惠满减活动）会显示。
6.勾选商品，点击结算按钮后，进去确认订单信息页面。
7.购物车页面中，可以对添加商品信息做信息的修改，并自动保存成功。
8.可以在购物车中重新修改商品规格。
9.购物车能添加的商品种类是有数量上限的。
10.结算的时候商品可以全选，选择底部的全选按钮。
11.可以在购物车页面对宝贝进行管理。
-- 性能功能易用安全界面
1.是否能一件批量付款
2.是否有全选、全不选的功能
3.是否能删除商品
4.能否把购物车了的商品移入收藏夹
5.是否有商品规格、购买数量的显示
6.是否有商品名称的显示
7.是否有店铺活动、满减优惠、降价显示
8.每个商品是否有店铺名称的提示
9.点击商品店铺能否进入店铺查看商品
10.点击商品名称能否进入商品详情页
11.是否有领券的文字提示
12.是否会显示领取优惠券之后的优惠价格
13.失效的商品是否还会出现在购物车的历史记录中
14.每件商品是否有对应商品图片的展示
15.是否有凑单提示
16.在购物车页面能否再次选择商品的种类
17.划到购物车页面的底部，有没有推荐商品展示
18.不支持发货的地区是否会有提示，商品前面的全选、全不选多选框是否会变灰色
19.当没有全选、全不选的多选框，没有选择任何商品时，点击 结算 按钮是否会跳转页面
20.是否有删除商品、批量删除的功能
21.是否有寻找相似商品的功能
-- 性能测试
1.打开购物车时间是否在已定的用户可以棘手的时间范围内。
2.编辑购物车：删除、添加商品需要的时间。
3.在购物车页面选择需要购买的商品进行结算的时候，结算金额可不可以实时显示。
4.清空失效商品需要的时间。
5.打开购物车页面要多久
6.快捷键功能知否支持
-- 兼容性测试
1.iOS：不同型号，不同的iOS系统。
2.安卓：不同品牌，不同型号，不同的安卓系统。
3.不同浏览器上的测试功能是否正常
-- 网络环境
1.3G、4G、WiFi网络环境下应用的各功能可正常运行。
2.网络异常时，数据交换是否会有提醒。
3.中途断网再很快连网，数据是否可以自动恢复，正常加载。
4.只允许内网访问的APP，在连接到外网时是否会有提醒。
-- 异常测试
1.没有内存时，APP是否能够正常相应。
2.横竖屏切换展示。
3.APP运行时网络中断。
4.反复操作某一个功能，不断点击和刷新，是否出现闪退。
5.APP运行时接入电话、短信、社交软件的信息提示时，是否能够正常运行。
登录测试用例设计：
一. 界面测试设计要点:
1. 界面的设计风格是否与UI的设计风格统一,布局是否合理, 按钮是否对齐
2. web的话, 对页面缩放登录模块是否与缩放比例缩放
3.界面中的文字简洁易懂,没有错别字
二. 功能测试设计要点:
1. 输入已注册的用户名和正确的密码，验证是否成功登录
2. 输入已注册的用户名和不正确的密码，验证是否成功失败，且提示信息正确
3. 输入未注册的用户名和任意密码，验证是否登录失败，且提示信息正确
4. 使用未激活账户登录，验证是否登录失败
5. 使用被停用用户登录，验证是否登录失败
6. 用户名和密码两者都为空，验证是否登录失败，且提示信息正确
7. 用户名和密码两者之一为空，验证是否登录失败，并且提示信息正确
8. 如果登录功能启用了验证码功能，在用户名和密码正确的情况下，输入正确的验证码，验证是否登录成功
9. 如果登录功能启用了验证码功能，在用户名和密码正确的情况下，输入错误的验证码，验证是否登录失败，且提示信息正确
10.用户名和密码是否大小写敏感
11.页面上的密码框是否加密显示、或者是否需要有明暗码切换按钮
12.后台系统创建的用户第一次登录成功时，是否提示修改密码
13.忘记用户名和忘记密码的功能是否可用
14.前端页面是否根据设计需求限制用户名和密码长度
15.如果登录功能需要验证码，点击验证码图片或者点击换一张是否可以更换验证码，更换后的验证码是否可用
16.刷新页面是否会刷新验证码
17.如果验证码有时效性，需要分别时效性内和时效性外验证码的有效性
18.用户登录成功但是会话超时后，继续操作是否会重定向到用户登录界面
19.不同级别的用户，比如管理员和普通用户，登录系统后权限是否正确
20.页面默认焦点是否定位在用户输入框中
21.快捷键Tab和Enter等，是否可以正常使用
22.为空和输入空格字符串的校验是否一致
23.使用中文键盘输入字母和使用英文键盘输入字母传入后端的字符长度是否一致
24.成功登录后的session的时效设置
25.输入栏是否设置快速删除按钮
26.用户名和密码是否支持特殊字符和中文
27.浏览器的前进后退按钮，是否有效
28.成功登出后，点击浏览器回退按钮，是否可以继续操作系统
29.需求中是否有登录时间限制，如果有验证时间限制是否有效
30.验证不同登录方式的正确性：扫码、账号密码、第三方……
31.若支持手机号+验证码登录，验证码是否有时间限制，移动设备是否可以直接获取验证码
32.操作错误提示信息是否简单明了
三. 性能测试设计要点:
1. 单用户登录的响应时间是否小于3秒
2. 单用户登录时，后台请求数量是否过多
3. 高并发场景下用户登录的响应时间是否小于5秒
4. 高并发场景下服务端的监控指标是否符合预期
5. 高集合点并发场景下，是否存在资源死锁和不合理资源等待
6. 长时间大量用户连续登录和登出，服务器是否存在内存泄露
7. 输入内容校验是否加入了函数防抖
四. 安全测试设计要点:
1. 用户密码后台存储是否加密
2. 用户密码在网络传输过程中是否加密
3. 密码是否具有有效期，密码有效期到期后，是否提示需要修改密码
4. 不登录的情况下，在浏览器中直接输入登录后的URL地址,验证是否会重新定向到用户登录界面
5. 密码输入框是否不支持复制粘贴
6. 密码输入框内输入的密码是否都可以在页面源码模式下被查看
7. 用户名和密码输入框分别输入典型的“SQL注入攻击”字符串，验证系统的返回页面
8. 用户名和密码输入框分别输入典型的“XSS跨站脚本攻击”字符串，验证系统行为是否被篡改
9. 连续多次登录失败的情况下，系统是否会阻止后续的尝试以应对暴力破解
10.同一用户在同一终端的多种浏览器上登录，验证登录功能的互斥性是否符合设计预期
11.同一用户先后在多台终端的浏览器上登录，验证登录是否具有互斥性
12.是否可以记住密码，记住的密码保存是否加密，记住的密码是否有有效期，过了有效期后是否清空密码
13.是否支持第三方登录
14.密码的强弱性，复杂度校验
15.异地登录校验、更换设备登录校验、登陆信息异常是否考虑账户冻结停用、是否允许第三方平台存储密码
16.是否可以使用登录的api发送登录请求，并绕开验证码校验
17.是否可以用抓包工具抓到的请求包直接登录
18.截取到的token等信息，是否可以在其他终端上直接使用，绕开登录，token过期时间校验
19.登录错误后的提示是否存在安全隐患
五. 兼容性测试要点:
1. 不同浏览器下，验证登录页面的显示以及功能正确性
2. 相同浏览器的不同版本下验证登录页面的显示以及功能正确性
3. 不同移动设备终端的不同浏览器下，验证登录页面显示以及功能的正确性
4. 不同分辨率的界面下，验证登录页面的显示以及功能正确性
六. 用户体验设计要点:
1. 输入框是否有一键清除功能
2. 输入错误用户名/密码登录失败, 提示最好是密码或者用户名错误
3. 输入的密码个数最好与输入框加密的个数不相同
4. 如何验证码是纯数字, 点击验证码输入框弹出数字键盘
5. 点击用户/密码字段可以鼠标焦点跳到对应的输入框中
14.设计测试用例的七个方法 *
边界值分析法，等价类划分法，场景法，错误推断法，判定表，因果图，正交实验法（前3个最常用）
确定上点内点离点：(0,18],[0,18),(0,18),[0,18]
上点：边界上的点
内点：域内的点
离点：离上点最近的点，开内闭外
有效等价类：符合需求说明书要求的数据
无效等价类：不符合需求说明书要求的数据
15.你们公司测试工作的流程 ***
原型图格式：.rp 启动的软件：axure/蓝湖在线查看 ui设计图：蓝湖/本地设计图 ui还原度：软件和设计图之间的
16.测试报告内容*
编写目的，测试人员（重点），测试环境，测试进度（重点），用例执行情况（是），缺陷统计（重点），缺陷分析（重点），测试总结（重点），风险分析（重点），遗留问题（重点）
17.上线相关
Android安装包后缀：.apk(之前)，.aab(android app bundle)
ios安装包后缀：.ipa(iphone app)
是否参与上线工作？？？
只做验收，后续工作不参与，他们大概这么做的
后端/前端html：部署服务器
Android上线： 开发/项目经理 将安装包提交到各个应用市场（应用宝，360应用市场，各个手机应用，goole应用市场），进行审核，审核通过就可以上线
ios上线： 开发/项目经理 将安装包提交到app store，进行审核（比较严），审核通过就可以上线
苹果税：是指苹果对于App Store的收费APP都会抽成30%（虚拟商品）的行为。
18.如果你是测试负责人，如果下个星期三上线，你发现测试任务完不成了，怎么办？
分析：从两方面考虑，1.应对本次危机；2.反思为什么导致这次的危机
第一方面：应对危机
1.加班,其次找关系好的同事
2.从其他组调人过来
3.考虑延期
4.砍掉一部分需求
5.外包出去
第二方面：反思
1.测试：水平不行（换人，内部培训），人力不足（招人）
2.产品：比如，频繁修改需求/新增需求
3.UI：水平不行（换人，内部培训），人力不足（招人）
4.开发：水平不行（换人，内部培训），人力不足（招人）
19.黑盒测试、白盒测试、灰盒测试 **
- 黑盒测试(Black Box -Test):把被测试的软件看做一个黑盒子，我们不去关心盒子里边的结构是什 么样子，只关心软件的输入数据和输出结果 有人把黑盒测试比作中医，通过“望闻问切”来判断是否有问题。
“望”:观察软件的行为是否正常。
“闻”:检查输出的结果是否正确。
“问”:输入各种信息，结合“望”，“闻”来观察软件的响应。
“切”:像中医一样给软件“把把脉”，敲击一下软件的某些“关节”
- 白盒测试:是一种按照程序内部逻辑结构和编码结构设计测试数据并完成测试的测试方法
- 灰盒测试:一种基于程序运行时的外部表现同时又结合程序内部结构来设计测试数据的测试方法
20.按照测试阶段分类，测试分为哪几类 **
单元测试、集成测试、系统测试、验收测试
单元测试:对一个模块、一个函数或者一个类来进行正确性检验的测试方法集成测试:单元测试后，将单独的模块按照设计要求组装成为子系统或系统，作为整体进行测试的 测试方法系统测试:集成测试后，将硬件、软件看作一个整体,对系统的功能及性能的总体测试验收测试:系统测试后以用户测试为主，或有测试人员共同参与检验软件质量的测试方法
21.冒烟测试和回归测试是什么 **
冒烟测试:验证系统的核心功能是否能够正常运行的测试方法回归测试:指开发修改bug后，重新进行测试以确认是否修复成功，修改有没有导致其他代码产生错误的测试方法
22.软件的分类
1.根据应用场景分类：
工具类软件、游戏型软件、媒体型软件、电商型软件等
2.根据软件架构分类：
单机版软件、分布式软件
2.1单机版软件：office、红警等
2.2分布式软件：
C/S架构软件:客户端需安装专门软件，如QQ 微信等
B/S架构软件:客户端为浏览器 ，如百度、hao123等
23.BS/CS架构的区别是什么？*
概念：所谓的架构就是用来指导我们软件开发的一种思维，目前最长见的就是BS/CS.
B---browser 浏览器
C---client 客户端
S---server 服务端
区别：
A.标准：相对于cs架构来说Bs架构的两端都是使用现成的成熟产品，bs会显示的标准一些。
B.效率：相对于bs架构来说cs中的客户端可以分担一些数据的处理，执行效率会高一些。
C.安全：bs架构当中得到数据的传输都是以Http协议进行传输的，而Http协议又是明文输出。可以被抓包，那么bs架构相比cs架构显得就不那么安全了，（其实都是相对的）。
D.升级：bs架构只需要在服务器端将数据进行更新，前台只需要刷新页面就可以升级，而cs架构必须要将两端都进行更新才可以。
E.开发成本：相对于bs架构来说cs当中的客户端需要自己开发，bs不用，所以说cs成本会高一些。
24.Android手机和IOS手机,系统有什么区别?**
A.运行机制不同:IOS采用的是沙盒运行机制,安卓采用的是虚拟机运行机制
B.两者后台制度不同:IOS中任何第三方程序都不能在后台运行,安卓中任何程序都能在后台运行,直到没有+内存才会关闭
C.IOS中用于UI指令权限最高,安卓中数据处理指令权限最高
25.你搭建过什么环境 ***
1.安装JDK，配置环境变量
2.安装测试需要的工具，像Jmeter，postman，抓包工具
3.安装Android sdk，配置环境变量，方便使用monkey对Android软件测试
4.安装Python环境和ide，写python脚本，做接口自动化和ui自动化
5.服务器上安装ServerAgent，监测服务器性能
26.开发环境与测试环境有什么区别？
开发环境：是在编码阶段，一般我们的代码基本上都是在开发环境中，不会在生产与测试环境，如操作系统，web服务器，语言环境，php,数据库等等。
测试环境：项目完成后，供测试找Bug,以及修改Bug后调试的环境。
生产环境： 项目数据前后端已经疏通，部署到阿里云上有客户去使用以及访问，供用户使用的环境
27.请描述下接口测试与UI测试是如何协同测试的？
A.有一部分是重叠的，Ui测试是通过前端写的界面，是来调用接口的，而接口测试是直接调用接口。
B.排除前端的处理逻辑与调用的正确性，在理论上接口测试是可以覆盖所有的Ui测试，但实际中，如接口层覆盖所有的业务流，在Ui上只测试前端的逻辑，而最终的结果会忽视很多原有的功能点，导致了Ui测试的不充分，那么会在人多且时间充分的时候，可以尝试接口去做业务流的全覆盖，否则不要轻易的去尝试。
28.App常见崩溃的原因？
A.设备碎片化：由于设备极具多样性，App在不同的设备上可能有不同表现形式。
B.宽带限制：宽带不佳的的网络对APP所需的快速响应时间不够。
C.网络的变化：不同网络间的切换可能会影响App的稳定性。
D.内存管理：可能内存过低，或非是授权的内存位置的使用可能会导致App失败。
E.用户过多：连续数量过多可能会导致App崩溃。
F.代码错误：没有经过测试的新功能，可能会导致App在生产环境中失败。
第三方服务：广告或弹出屏幕可能会导致App崩溃。
30.如何提交高质量的软件缺陷记录（报告）？ *
A.ui要统一、准确。
B.尽量使用业界惯用的表达术语和表达方法
C.每条缺陷报告只包括一个缺陷
D.不可重现的缺陷也要报告
E.明确指明缺陷类型
F.明确指明缺陷严重等级和优先等级
G.描述 (Description) ，简洁、准确，完整，揭示缺陷实质，记录缺陷或缺陷出现的位置
短行之间使用自动数字序号，使用相同的字体、字号、行间距
短行之间使用自动数字序号，使用相同的字体、字号、行间距，可以保证各条记录格式一致，做到规范专业。
H.每一个步骤尽量只记录一个操作
I.确认步骤完整，准确，简短
J.根据缺陷，可选择是否进行图象捕捉
31.如果回归测试不通过怎么办? **
说明未通过的原因,把bug打回去让开发重新修复
32.压力测试,负载测试,稳定性测试
压力测试: 在强负载下的测试,查看系统在峰值情况下是否有功能隐患,系统是否具有良好的容错能力和可恢复能力
负载测试:通过逐渐增加系统负载,确定在满足系统的性能指标的情况下,找出系统能承受的最大负载和极限负载的测试
稳定性测试:给定一个用户正常的业务负载,然后进行长时间的测试(1天-1周),并最终保证服务器能满足线上业务需求
33.项目迭代周期 **
一般是 2周- 1个月, 这个和新增功能的多少/难易有关
另外 大版本更新的时候(比如1.x.x 升级到 2.0.0) , 所有功能都要重新测试
34.团队大小 **
产品经理:1,项目经理:1,ui:2,前端:2,后端:3,Android:2,ios:3,测试:2,
可以说测试部门有挺多人,派到这个项目组的有2个
自己编,合理就可以了,前端:后端:android:ios:测试 = 接近 1:1
sql语句 ***
-------了解---------
显示数据库：show databases;
数据库创建：create database 数据库名;
数据库切换：use 数据库;
查看当前库的所有表：show tables;
创建表：create table 表名（ 列名 类型, 列名 类型 ）;
查看表结构：desc 表名;
删除表：drop table 表名；
删除库：drop database 库名；
-----掌握-------
插入数据：insert into 表名 values();
删除数据：delete from 表名 where 条件;
修改数据：update 表名 set 键=值，键=值 where 条件；（update student set name=’张三’ where name=’zhangsan’； ）
-----查询 重点掌握-------
查询所有：select * from 表名;
条件查询：select * from 表名 where 条件;
查询所有学生成绩，并输出效果为 姓名 语文 英语 数学：
select name as 姓名,chinese as 语文,english as 英语,math as 数学 from student
查询数学成绩在80-90之间的同学：
select * from student where math between 80 and 90
查询数学语文英语都大于80的同学成绩 or或者 ，and 并且：
select * from student where math>80 and english>80 and chinese >80;
模糊查询 ：_代表1个字符 ；%代表0个及其以上的字符
查询所有姓名中包含张的同学：select * from student where name like ‘%张%’
升序：asc
select * from 表名 order by 表中的字段 asc(MySQL中默认是升序排列，可不写) ；
降序：desc
select * from 表名 order by 表中的字段 desc ；
（按照数学成绩从大到小查询：select * from student order by math desc;）
分页查询：limit，
select * from table limit m,n；其中m是指记录从m+1开始,，N代表取n条记录。
取出第3条至第6条，4条记录 ：select * from student limit 2,4
分组查询：group by 字段
根据性别分类，查出对应性别的人数（比如，男：20，女：19）：
select sex，count(*) from employee group by sex;
分组查询加条件 ：使用having，不使用where
根据性别，查询大于18岁的人数
select sex，count(*) from employee group by sex having age>18;
count 个数
sum 总数
avg 平均数
max 最大值
min 最小值
语文的平均成绩：select avg(chinese) from student;
统计一下班级语文最高分和最低分：
select max(chinese) from student;
select min(chinese) from student;
班级里边有多少学生：select count(*)from student;
子查询：一个查询的结果 作为另一个查询的条件
先查括号里面的，查到kaifa班级的id，根据id去student表查到对应class_id的学生：
select * from student where class_id=(select id from class where name="kaifa");
内连接查询：inner join on 查询两张表，设定条件，将两张表中对应的数据查询出来
select * from customer c inner join 、 o on c.id=o.customer_id;
左外连接：left join on，将两张表对应的数据查询出来，同时**将左表自己没有关联的数据也查询出来（）
select * from customer c left join orders o on c.id=o.customer_id;
右外连接：right join on 设定条件，将两张表对应的数据查询出来，同时将右表自己没有关联的所有数据查询出来
select * from customer c right join orders o on c.id=o.customer_id;
去重：distinct
SELECT distinct 字段1,字段2 FROM 表名
常用Linux命令 ***
• 目录操作
• cd usr/ 切换到该目录下usr目录
• cd .. 切换到上一层目录
• cd / 切换到系统根目录
• mkdir 目录名称 创建目录
• ls 目录名称 查询该目录下所有的目录和文件
• ls [-a] 目录名称 查询该目录下所有的目录和文件,包含隐藏文件
• ls [-l] 目录名称 查询该目录下所有的目录和文件的详细信息
• find / -name 目录名称 查找/root下的目录(文件) ****
• mv 目录名称 新目录名称 修改目录名称
• mv 目录名称 目录的新位置 剪切
• cp -r 目录名称 目录的目标位置 拷贝 ***
• rm -rf 目录 强制删除目录
• 文件操作
• 创建空文件：touch 文件名称 ***
• 查看文件内容：cat/more/less/tail 文件 ***
• 动态查看/实时查看文件(日志)：tail -f 文件 ***
• 查看文件前10行：head -n 10 文件名 ***
• 查看文件后5行：tail -n 5 文件名 ***
• 关键字搜索 ：grep 要搜索的字符串 要搜索的文件 ***
• 修改文件内容：vi/vim 文件（-->进入文件----->命令模式------>按i进入编辑模式----->编辑文件 **------->按**Esc进入命令模式--输入：进入底行模式-**---->**输入wq/q!） ***
• 强制删除文件：rm -rf 文件 ***
• 文件的打包压缩 :tar -zcvf 文件名.tar 要打包的文件 ***
• 文件的解压:tar -xvf 文件名.tar ***
• 扩充:将文件解压到固定位置 :tar -xvf 文件名.tar -C 指定解压的位置
• 查询当前所在位置 : pwd
• 查看进程: ps -ef | grep 进程名称(tomcat/mysql) ***
• 杀死进程:kill -9 进程pid ***
• 查看端口号:netstat -an | grep 端口号(3306) ***
• 查看服务器ip : ifconfig ***
• 查看网络是否能正常使用
• ping 外网地址 查看是否能访问外网
• ping 内网ip 查看是否能访问内网 ***
• 权限命令 :chmod 777 文件 赋权 ***
• 查看cpu :top ***
• 查看磁盘信息 : df -h ***
• 查看内存信息: free ***
• 切换管理员账户：su，然后输入密码
• 由root 切换到test用户：su test
性能测试
1.Jmeter做分布式压测的配置
压力机:
在Jmeter bin/jmeter.properties中修改server.rmi.ssl.disable=false，改为true
启动jmeter-server
控制机:
bin/jmeter.properties 中修改server.rmi.ssl.disable=false，改为true
bin/jmeter.properties 中remote_hosts填入压力机的ip和端口号,多个使用","隔开
点击运行–>远程启动
2.性能测试怎么做的？***
1.做性能需求分析，挑选了用户使用最频繁/核心功能的接口来做性能测试，比如：首页列表，搜索，提交订单等
2.确定性能指标，比如：事务通过率为99.99%，90%的事务响应时间不超过3秒，错误率为0.01%，CPU和内存的使用率为80%以下，TPS。
3.搭建性能测试环境，准备好性能测试数据。
4.使用Jmeter开发脚本，包括:参数化，断言，关联,监听器等。
5.设计性能测试场景，使用了分布式压测,我们这个项目做了50并发用户的单功能循环30min的基准测试，然后逐渐增加并发用户数（150/300/500...），执行1-2小时的负载测试，看系统有没有性能瓶颈；
6.分析性能测试结果，如果有性能瓶颈，收集相关的日志提单给开发做性能调优。
7.开发调优后，回归性能测试(可能需要来回优化回归多次)
8.测出最大负载后 做稳定性测试（1天-7天）
9.完成后输出负载测试和稳定性测试报告
怎么操作(不用背,有可能问细节的时候说)：
1.服务器需要启动ServerAgent
2.添加两个组件（ServerAgent组件，TPS）+监听器（聚合报告）+ 断言+关联
3.线程数量（并发用户量），循环次数永久+调度器(设置持续时间)
4.结果分析，整理报告
3.怎样分析性能测试结果？ *
1.查看聚合报告和服务器的资源使用图，检查响应时间，事务成功率，CPU，内存和IO使用率是否达到要求，如果出错率达到了总请求数的0.01%，我们会检查是什么原因导致的，修改好后，重新测试；
2.如果出现了性能瓶颈，比如响应时间，或者CPU使用率不达标，我们会从服务器上导出日志，分析是哪个地方导致响应时间过长，如果分析不出来，就叫上开发一起讨论，确定问题后，就提单给开发修复，修复好了就进行回归测试。
任何指标只要一小段时间不达标,都需要分析优化,比如cpu/内存 持续3分钟超过80%
4.性能测试关注的指标 ***
响应时间，并发用户数，吞吐量，TPS，错误率，资源使用率（CPU，内存，磁盘IO，网络）
TPS和QPS区别：
QPS：服务器每秒处理的请求数量
TPS：服务器每秒处理的事务数量，1个事务包含1个或者多个请求
5.你们项目最佳的并发用户数是多少？*
我们当时做到1500（500-1500）个并发用户的时候，查询功能的响应时间超过了性能指标2秒多，吞吐量开始变小，也就是说吞吐量已经达到峰值，开始掉头向下了。
6.如何判断网络是否存在瓶颈？*
在性能测试结束之后，我们会根据性能测试的结果，查看在整个性能测试过程中，网络的吞吐量是多少，如果网络的吞吐量占到了服务器的70%以上，我们就认为网络存在瓶颈，通常会增加带宽或者压缩传输数据。
7.如何判断响应时间不达标 *
我们90%响应时间要求是3s，响应时间不达标的话，我们会根据性能测试结果先检查看下是否是服务器带宽存在问题，如果带宽存在瓶颈，则会考虑增加带宽或者压缩传输数据，如果带宽没有问题的话，我们会从服务器上导出日志，开发一起讨论分析是哪个地方导致响应时间过长，确定问题后，就提单给开发修复，修复好了就进行回归测试。
8.如何判断CPU使用率不达标 *
我们CPU使用率要求不超过80%，CPU使用率不达标，我们会从服务器上导出日志，分析是哪个地方导致CPU使用率不达标，如果分析不出来，就叫上开发一起讨论，确定问题后，就提单给开发修复，修复好了就进行回归测试。
9.日活，月活，下载量 (不用背,了解即可)
日活（DAU，daily active user）：日活跃用户
月活（MAU，month active user）：月活跃用户
下载量：app的下载次数
下载量>=月活>=日活
UV（Unique visitor）
是指通过互联网访问、浏览这个网页的自然人。访问您网站的一台电脑客户端为一个访客。00:00-24:00内相同的客户端只被计算一次。一天内同个访客多次访问仅计算一个UV。
PV（Page View）
即页面浏览量或点击量，用户每1次对网站中的每个网页访问均被记录1个PV。用户对同一页面的多次访问，访问量累计，用以衡量网站用户访问的网页数量。
10.服务器怎么优化/调优*
分为软件优化和硬件优化
软件优化：架构重构，算法优化，编译优化，代码优化
硬件优化：增加cpu，内存条，磁盘，提升宽带，分布式，负载均衡
接口测试
一.网络基础
1.http和https的区别？*
简单来说，HTTPS协议是由SSL/TLS+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安 全。区别主要如下：
1、https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
3、http和https使用的是完全不同的连接方式，用的默认端口也不一样，前者是80，后者是443。
4、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证
的网络协议，比http协议安全。
2.get和post请求的区别？*
- GET后退按钮/刷新无害，POST数据会被重新提交（浏览器应该告知用户数据会被重新提交）。
- GET书签可收藏，POST为书签不可收藏。
- GET能被缓存，POST不能缓存 。
- GET历史参数保留在浏览器历史中。POST参数不会保存在浏览器历史中 GET对数据长度有限制，当发送数据时，GET 方法向 URL 添加数据；URL 的长度是受限制的（URL 的最大 长度是 2048 个字符）。POST无限制。
- 与 POST 相比，GET 的安全性较差，因为所发送的数据是 URL 的一部分。在发送密码或其他敏感信息时绝 不要使用 GET ！
- POST 比 GET 更安全，因为参数不会被保存在浏览器历史或 web 服务器日志中。
- GET的数据在 URL 中对所有人都是可见的。POST的数据不会显示在 URL 中。
3.请求方式有哪些？
get，post，put，delete，
4.常见的状态码有哪些？***
100：这个状态码是告诉客户端应该继续发送请求，这个临时响应是用来通知客户端的，部分的请求服务器已经接受，但是客户端应继续发送求请求的剩余部分，如果请求已经完成，就忽略这个响应，而且服务器会在请求完成后向客户发送一个最终的结果
200：这个是最常见的http状态码，表示服务器已经成功接受请求，并将返回客户端所请求的最终结果
202：表示服务器已经接受了请求，但是还没有处理，而且这个请求最终会不会处理还不确定
204：服务器成功处理了请求，但没有返回任何实体内容 ，可能会返回新的头部元信息
301:永久重定向，资源已永久分配新URI
302:临时重定向，资源已临时分配新URI
400:Bad Request 请求报文语法错误或参数错误
401:Unauthorized 需要通过HTTP认证，或认证失败
403:Forbidden 请求资源被拒绝
404:Not Found,户端请求的资源没有找到
500：服务器遇到未知的错误，导致无法完成客户端当前的请求
503:服务器超负载或停机维护
5.http请求的组成？
请求行：请求的第一行是“方法URI协议/版本”例如：GET/sample.jsp HTTP/1.1
请求头（消息报头）：包含许多有关的客户端环境和请求正文的有用信息。例如，请求头可以声明浏览器所用的语言，请求正 文的长度等。
请求正文：请求头和请求正文之间是一个空行，这个行非常重要，它表示请求头已经结束，接下来的是请求正文。请求正 文中可以包含客户提交的查询字符串信息：username=jinqiao&password=1234
6.http响应的组成
状态行：由http版本协议，状态码，状态码描述组成，如 HTTP/1.1 200 OK
响应头（消息报头）：服务器传递给客户端用于说明服务器的一些信息，以及将来继续访问该资源时的策略
响应正文（响应体）：是服务端返回给客户端的HTML文本内容，或者其他格式的数据，比如：视频流、图片或者音频数据。
7.cookie，session，token区别*
token
令牌，是用户身份的验证方式。
最简单的token组成:uid(用户唯一的身份标识)、time（当前时间的时间戳）、sign（签名）。
session
会话，代表服务器与浏览器的一次会话过程，这个过程是连续的，也可以时断时续。
session因为请求（request对象）而产生；session是一个容器，可以存放会话过程中的任何对象；session的创建与使用总是在服务端，浏览器从来都没有得到过session对象；session是一种http存储机制，目的是为武装的http提供持久机制。
cookie
储存在用户本地终端上的数据，服务器生成，发送给浏览器，下次请求统一网站给服务器。cookie中存放着一个sessionID，请求时会发送这个ID；
cookie与session区别
cookie数据存放在客户端上，session数据放在服务器上；
cookie不是很安全，且保存数据有限；
session一定时间内保存在服务器上,当访问增多，占用服务器内存。
session与token
作为身份认证，token安全性比session好；Session 认证只是简单的把User 信息存储到Session 里，因为SID 的不可预测性，暂且认为是安全的。这是一种认证手段。 而Token ，如果指的是OAuth Token 或类似的机制的话，提供的是 认证 和 授权 ，认证是针对用户，授权是针对App 。其目的是让 某App有权利访问 某用户 的信息。
token与cookie
Cookie是不允许垮域访问的，但是token是支持的， 前提是传输的用户认证信息通过HTTP头传输；token就是令牌，比如你授权（登录）一个程序时，他就是个依据，判断你是否已经授权该软件；cookie就是写在客户端的一个txt文件，里面包括你登录信息之类的，这样你下次在登录某个网站，就会自动调用cookie自动登录用户名；session和cookie差不多，只是session是写在服务器端的文件，也需要在客户端写入cookie文件，但是文件里是你的浏览器编号.Session的状态是存储在服务器端，客户端只有session id；而Token的状态是存储在客户端。
上面的供理解，下面需要记忆
它们三个都是用来验证用户身份的（鉴权）
token令牌，是用户身份的验证方式（登录后获取，可以获取用户相关的数据，一般都是app在用），存储在用户端。
session会话，因为请求而产生；session是一个容器，可以存放会话过程中的任何对象，存储在服务器，当访问增多，占用服务器内存，
cookie，储存在用户本地终端上的数据，服务器生成，发送给浏览器，下次请求统一网站给服务器。cookie中存放着一个sessionID，请求时会发送这个ID；
token安全性比session好，Session 认证只是简单的把User 信息存储到Session 里，而Token ，如果指的是OAuth Token 或类似的机制的话，提供的是 认证 和 授权 ，认证是针对用户，授权是针对App
二.抓包
1. 说一下抓包 ***
抓包：抓包是将网络传输发送与接收的数据包进行截获、重发、编辑、转存等操作，也用来检查网络安全，常见的抓包工具：Charlers，Fiddler,WireShark...
作用：
1.定位前后端问题：
app:
通过抓包看网络请求
web:
浏览器按f12, 点到network,在下面找到对应的网络请求
看url还有参数，如果url和参数不对，前端的问题，如果没有问题
看响应数据，如果响应数据有问题的，那么就是后端问题，如果数据没有问题
就是前端问题
2.模拟404
3.模拟弱网
4.mock测试
2. 怎么定位前后端问题 *****
app:
通过抓包看网络请求
web:
浏览器按f12, 点到network,在下面找到对应的网络请求
看url还有参数，如果url和参数不对，前端的问题，如果没有问题
看响应数据，如果响应数据有问题的，那么就是后端问题，如果数据没有问题
就是前端问题
3. 抓包的时候遇到乱码没 *
有的
1.没有信任证书导致的,因为https是加密传输的
2.数据本身还做过加密，除非拿到密钥，否则没办法解密
4. mock测试，rewrite用过没有，map remote/local用过没有 **
mock测试：模拟我们想要的请求和测试数据返回
charles
断点：断点可用修改请求数据和响应数据，一般用来临时修改
map：
本质上都是重定向
map local（拿本地文件替换服务器返回的数据）
map remote（拿另外一个链接返回的数据替换原来的数据）
rewrite：通过正则匹配的方式，修改请求/响应数据
5.具体操作(不用背)
5.1怎么信任证书
把抓包工具的证书导出，在对应的浏览器/手机中信任
charles具体操作(不问不用说):
安装:help --> ssl proxying--> install charles root certificate
导出:help-->ssl proxying-->save Charles root certificate，选择.cer格式的证书
信任:chrome浏览器：设置 → 管理证书（安全） → 导入
5.2移动端怎么抓包
1.pc和手机在同一个wifi下
2.手机需要设置代理，ip和端口号
3.信任证书
4.开启app进行抓包
5.3map local 使用步骤
Tools--Map Local --> 指定本地文件
5.4map remote使用步骤
tools--map remote -->指定重定向的链接
5.5断点修改请求参数
选中链接-->右键 -->选择“BreakPoints” -->刷新网页 -->Edit Request,修改请求信息-->Execute
5.6断点修改响应数据
选中链接-->右键 -->选择“BreakPoints” -->刷新网页 -->Edit Response”,修改响应数据-->Execute
5.7 rewrite
Tools-Rewrite -->添加对应的链接,规则
5.8弱网 使用步骤
Proxy-->Throttling Settings(节流阀设置) -->可以选择3G,4G,56kbps,256kbps....
5.9模拟404 使用步骤
tools——>blocklist--> 添加网址
三.接口测试
3.1 说一下Postman（是什么，有什么用，使用过它的什么功能）***
Postman是一款强大的http调试工具，我们一般使用它来做接口测试
常用的功能：
1. 创建测试和生产环境，添加对应的环境变量，比如baseUrl，
2. 创建接口集，里面添加项目的接口
3. 添加接口，可以发起get/post/delete/put等请求
4. Get请求查询参数放入Params中，post请求参数放入Body中，可以是普通键值对，json/html/xml/文件，请求头都是放入Headers里面
5. Pre-request Script预处理脚本，在发起网络请求之前会调用的js代码，可以在里面获取一些动态的参数，比如时间戳，随机数等
6. Tests脚本，在发起网络成功拿到响应之后调用，可以在里面添加断言，判断响应数据是否正确
7. Mock测试，模拟服务器返回自己想要的测试数据
8. 参数化：环境变量，全局变量，csv文件
参数化 --不需要记
1.写一个csv/txt文档，把测试数据放入
2.建接口集，里面写接口
3.接口传递的参数不能写死，使用关联的方式（{{key}}），key应该是csv文件表头名字
4.双击接口集，点击右上角的run，打开Runner
5.配置参数
Iterations（迭代次数，测试数据有几个，就写几）
Delay: 延迟对应的事件发起请求
data：选择csv文件
Data file type： 选择文件的类型（text/csv）
6.点击运行
3.2 如果没有接口文档，怎么办？ *
1.可以找前端开发要关于 接口的类
2.抓包获取
3.3 接口case包含哪些内容？**
用例标题，优先级，所属模块，资源路径，请求参数，请求方式，测试数据，预期结果（应该有结果），实际结果
3.4 有依赖关系/关联的接口怎么测试 *****
比如B接口的请求参数是A接口的响应数据
我们需要请求A接口，拿到数据后，把需要的数据提取出来，放入B接口进行请求
具体实现的话使用我们常用的那些工具都可以，像postman，Jmeter，python脚本都行
1.postman：请求A接口，在Tests脚本里面写js代码，将数据解析后提取想要的数据，存为全局/环境变量，在B接口请求的时候关联使用（{{id}}）
2.Jmeter：请求A接口，给A接口添加后处理器--正则提取器，通过正则的方式，将数据提取出来变成用户变量，在B接口中关联使用（${id}）
3.python: 使用requests请求A接口，拿到响应后解析成json，然后取出想要的数据，进行B接口的请求，将取出的参数塞入即可
3.5 接口测试的流程 ***
1.找后端拿到接口文档
2.写测试计划
3.分析接口（接口间业务关系，关联接口的数据，请求参数，请求头(token，os，版本),响应数据（数据格式，字段，错误分析））
4.写用例，评审用例
5.执行用例去测试；自动化：根据用例写脚本（requests+pytest/unittest），手动：postman/jmeter测试
6.结果分析
7.bug提交
8.修复之后 回归测试
3.6 接口测试测什么/关注什么/验证什么/测试点 ***
自动化测试
Python 及自动化基础
1.您知道Python中的可变不可变数据类型有哪些？ **
可变数据类型有列表(list)、集合(set)、字典(dict)
不可变数据类型有数字(number)、字符串(str)、元祖(tuple)、不可变集合(frozenset)
2.面向对象三要素及其意义吗？****
面向对象是相对于面向过程来讲的，面向过程是 所有的事情都得自己去做, 而面向对象是把相关的数据和方法组织为一个整体来看待，完成任务只需要找有相关功能的对象即可。
咱们整个世界就是面向对象的世界,比如我想告诉你一个消息,不需要千里迢迢的跑过去亲口对你说,只需要通过电话/微信就可以,电话/微信就是具有通话功能的对象,我只需要会用它就可以,不需要知道它的实现原理
面向对象三要素是：封装、继承、多态
封装：将有共同的属性和方法封装到同一个类下面，对外只提供访问的的接口,不提提供实现细节
继承：子类继承父类，可以具备父类已有的非私有属性和方法，解决代码重用
多态：多态的前提是继承, 指的是基类的同一个方法在不同的派生类中有着不同的功能,比如猫和狗都继承动物类,但是猫爱好吃鱼,狗爱好吃骨头,这就是多态
3.列举Python的魔法方法 *
主要魔法方法
__new__：类的构造器，创建初始化后的基本实例对象，相当于是类的骨架子
__init__：类的数据初始化方法，用来给实例话对象添加属性的
__del__：类的析枸器(这是C/C++的叫法)，专门用来在实例销毁前调用，释放资源的
__call__：可以将实例对象直接声明为一个方法调用，方便调用过程，保护内部实现
相关属性获取方法
__getattr__：获取某个属性时，比如对于字典的key值获取或者列表的索引获取
__setattr__：设置某个属性时，比如设置某个索引对应的值，或者字典对应key的value更新创建
比较操作符
__lt__、__le__：小于判断、小于等于
__eq__、__ne__：等于、不等于判断时，用的就是这个方法
__gt__、__ge__：大于判断、大于等于判断
4.列表，元组，字典区别 ***
python中3种内建的数据结构:列表、元组和字典
列表：[]表示，可变的数据类型，即这种类型是可以被改变的，并且列表是可以嵌套的
元组：（）表示，元组是不可变的，可以嵌套
字典：{}表示，存储键值对的，键要求唯一，字典中的键/值对是没有顺序的
5.unittest怎么使用
1.写一个py文件，导入unittest
2.写一个类，继承unittest.TestCase
3.复写setup（准备测试环境），teardown（还原测试环境），写以test打头的方法，里面可以通过断言去验证一些逻辑
4.另一个py文件中，使用测试套件（TestSuite），把想要执行的用例添加进来
5.使用TextTestRunner/HtmlTestRunner，运行测试套件
6.怎样导包
1.建议在条件允许的情况下，使用绝对路径导入，而不是相对路径。
比如有两个包，w/a/c.py,在f包下有个g.py,想要在g.py中使用c.py,可以这么导包 import w.a.c 或者 from w.a import c
2.系统的模块，像time，os，还有自己下载的模块，比如requests，在sys.path（sys.path是python的搜索模块的路径集）中是有路径的，所以可以直接import
3.如果想把另一个模块中的py文件导入当前项目，可以将另一个模块的路径添加到sys.path中，然后导包，比如，在C:\\tool\\myTool\\calc.py,可以这样导包
import sys
sys.path.append(“C:\\tool\\myTool\\”)
import calc
7. 八大定位 ***
id：
className：
name：
tagName：
xpath：
css选择器：
link_text:
partial_link_text:
使用的api是
find_element(by,value)
8.常用的selenium api方法及作用*
FixFox/Chrome（）：获取浏览器驱动
get（）：请求某个网址
find_element():查找元素
send_keys():给文本框输入内容
click（）：点击
move_to_element()（ActionsChain中的方法）: 把鼠标移动到元素上
driver.execute_script('window.scrollTo(0,0)'):执行js代码 (这个是滑动到顶部)
element.get_attribute(属性的键)：获取属性的值
quite（）：退出浏览器
close（）：关闭当前窗口
switch_to.frame():切换frame
switch_to.window:切换window
clear():清楚输入框内容
text:获取文本
9.selenium如何切换窗口/frame/警告框
获取当前窗口的句柄： handles = driver.window_handlers
切换窗口：driver.switch_to.window(handles[n])
切换frame：driver.switch_to.frame(value)
切换alert：driver.switch_to.alert
10.常用的python模块*
单元测试模块：unittest，pytest
ui自动化模块：selenium，appium
时间模块：time
数学计算模块：math
执行系统命令模块：os
随机数模块：random
mysql数据库：pymsql
string模块：str
网络请求:requests
11.浏览器等待的三种方式*
固定等待：time.sleep(seconds)
显示等待：WebDriverWait（）
隐式等待：driver.implicitly_wait()
12.什么是po模型及它的优点
PageObject，将页面的元素定位和元素行为封装成一个basepage类，其他page继承basepage，一个页面对应一个类
PageObject 设计模式核心思想是：测试对象（页面）和测试用例（页面操作+测试数据）分离；调用所需页面对象中的行为，组成测试用例。在用例中，是看不到元素定位和元素操作的。
优点：
1. PO提供了一种业务流程与页面元素操作分离的模式，这使得测试代码变得更加清晰
2. 页面对象与用例分离，使得我们更好的复用对象
3. 可复用的页面方法代码会变得更加优化
4. 更加有效的命令方式使得我们更加清晰的知道方法所操作的UI元素
13.PO模型的核心要素
1. 在PO模式中抽离封装一个BasePage类，该基类应该拥有一个webdriver实例的属性
2. 每一个page都继承BasePage，通过driver来管理本page中元素，将page中的操作封装成一个个方法
3. TestCase继承unittest.Testcase类，并依赖page类，从而实现相应的测试步骤
14.pymysql **
import pymysql
# 连接数据库
con =pymysql.connect(host="127.0.0.1",
user="root",
password="123456",
database="h2106",
port=3306)
# 拿到游标 ，查询结果是列表嵌套 字典
cursor = con.cursor(cursor=pymysql.cursors.DictCursor)
sql = "select * from stu;"
# 执行sql语句
cursor.execute(sql)
# 拿到结果
data = cursor.fetchall()
print(data)
# 关闭游标
cursor.close()
# 关闭数据库
con.close()
1.连接数据库的方法
connect()
2.连接数据库需要的参数
host(主机ip),port(端口号),user(用户名),password(密码),database(数据库名)
3.执行sql语句
cursor.execute(sql语句)
4.拿到数据
cursor.fetchall()
ADB
1.说一下adb **
adb 是Android debug bridge（安卓调试桥），是sdk提供一个工具，可以操作管理app+设备
查看手机cpu情况：adb shell dumpsys cpuinfo
应用的内存使用情况：adb shell dumpsys meminfo +包名
查看电池状态:adb shell dumpsys battery
安装软件：adb install -r (APK路径)
卸载软件：adb uninstall 包名
将手机日志输出到本地文件中：adb logcat -v time process > C:/log/aa.txt
开启服务：adb start-server
关闭服务：adb kill-server
查看设备：adb devices
将电脑文件传输到移动端：adb push 电脑路径 移动端路径
adb push C:\log\aa.txt /storage/emulated/0
将移动端文件传输到电脑：adb pull 移动端路径 电脑路径
adb pull /storage/emulated/0/博雅东湖.mp4 C:\log\bo.mp4
列出手机装的所有app的包名：adb shell pm list packages
清除应用缓存信息:adb shell pm clear [packagename]
2.monkey测试(为什么叫monkey) ***
monkey 是adb下的一个子命令，可以在Android手机屏幕上产生随机的触摸事件，可以对Android app进行压测
adb shell monkey -p 包名 -s 6009 --throttle（则挼陶） 300 --ignore（一格弄娃儿）-crashes（科挼晒死） --ignore-timeouts（太买科死） --pct-touch（陶吃） 90 -v 300000 >C:\log\log.txt
-p 包名 ----******
-s 6009: 指定种子，值相同，产生的事件序列也相同 ----******
--throttle <毫秒> ： 指定用户操作（即事件）间的间隔 ----******
--ignore-crashes：忽略崩溃 -----*****
--ignore-timeouts：忽略超时，（ANR） -----*****
--pct-touch 设置点击事件百分比 -----*****
--pct-motion 设置滑动事件百分比 -----*****
-v,-v-v,-v-v-v: 日志详细程度
300000： 产生的事件个数（一般都是10w+的次数）
>C:\log\log.txt ： 日志输出的位置
时间：3-5H
晚上下班 的时候，运行，等到 早上上班 结束了，分析
测试结果处理:
1.把日志存到电脑上
2.查找异常信息
a.XXXException(NUllPointerException,
ArrayIndexOutOfBoundsException,FileNotFoundException...)
b.ForceClosed(程序强制关闭) （ctrl+f搜索‘Fatal’）
c.ApplicationNot Response(应用程序无响应)(搜索anr)
d.out of memory (内存溢出)
3.把搜到的异常信息整理一下，发给开发（把异常那行及下面10几行）
接口自动化
1.说说你接口自动化是怎么做的
1.找后端拿到接口文档
2.分析接口（接口间业务关系，关联接口的数据，请求参数，请求头(token，os，版本),响应数据（数据格式，字段，错误分析））
3.写接口测试用例
4.把测试数据放入csv文件
5.在unittest的testcase类中（写一个类，继承unittest.TestCase），写test打头的方法，把csv读取的测试数据放入requests做网络请求，然后把拿到的响应数据断言判断，或者使用pymysql连接数据库查询数据并比对
6.在另一个py文件中使用TestSuite调用TestCase中的方法，配合HtmlTestRunner 生成测试报告
7.将报告以邮件的形式发送给自己和领导
2.自动化的细节 ***
response = request.get()/post()
# 1.响应码
response.status_code
# 2.响应json数据
response.json()
# 3.字符串格式的json 转换为json/字典
json = eval(字符串)
# 4.json/字典转换为字符串
str1 = str（字典/json）
UI自动化
1.介绍一下你对项目中哪些功能做了自动化，怎么做得
我们做自动化的话，一般需要选取那种比较固定的功能，比如搜索，登录，注册等，这些功能在我们迭代的时候一直存在，所以选这些功能。
自动化说白了就是将手动测试的步骤全部转换成代码，由代码完成对应的操作，比如人可以通过眼睛看到按钮/输入框的位置，代码不行，需要通过元素定位的方式找到按钮/输入框，代码也没有手，点击也是得通过click方法完成，还有其他的像输入框输入内容，需要调用send_keys（）
我的脚本使用了PO模型，将元素操作和业务进行了分离，元素操作封装成了BasePage，具体的业务的写入了具体的业务类，比如SearchPage，LoginPage，LocatePage，验证是通过unittest验证的
(下面是举例,拿自己的项目业务举例)
说一下我写过的搜索功能（拿简书举例）吧，配置浏览器和url信息后，脚本会帮我们启动对应的浏览器，chrome或者火狐等，
进入主页面后通过id定位到搜索输入框（可以xpath定位，id定位，class定位...），调用send_keys()输入想要搜索的内容，
通过xpath定位到搜索按钮，代码调用点击click()方法，结果会在新的窗口展示
通过driver.switch_to.window(handles[n])切换窗口，
搜索结果上面部分是用户，下面部分是文章，我们需要验证用户和文章 是和我们搜索关键字相匹配的
验证用户很简单，通过class把所有用户的元素获取到，然后获取用户名（元素.text），然后通过断言判断用户名是否包含搜索关键字
验证文章的话我们需要验证文章的作者，标题，文章的内容，只要有三者有一个包含关键字，那结果就是正确的，同样我们获取作者，标题，文章内容的文本，断言判断文本中是否包含搜索关键字（怎么判断，find）
git
git和svn都是是项目版本控制的工具, 可以跟踪项目各个文件的变化
svn是集中式的版本控制工具,git是分布式的
用户配置
git config --global user.name "用户名"
git config --global user.email "邮箱"
初始化仓库
git init
克隆仓库
git clone 仓库地址
添加所有文件
git add --all
从暂存区提交 -m：注释
git commit -m '注释内容'
拉取远端内容
git pull
将本地历史推送到远程
git push
创建一个分支
git branch 分支名称
删除一个分支
git branch -d 分支名称
切换分支
git checkout 分支名称
合并分支
git merge
将当前分支回退到历史某个版本
git reset
查看提交历史记录
git log
对状态的跟踪
git status
.gitignore忽略文件: 不想被跟踪的文件可以配置到这里
文章来源
您阅读本篇文章共花了：
发表评论