测试
测试需要具备的素质
基础的理论知识、编程语言的功底、自动化测试工具、计算机基础知识
业务分析能力：分析业务的流程，分析被测业务数据、分析被测系统的框架、分析业务模块、分析测试所需资源、分析测试完成目标
缺陷洞察能力：一般缺陷的发现能力、隐形问题的发现能力、发现连带问题的能力、发现问题隐患的能力、尽早发现问题的能力
团队协作能力，合理进行人员的分工、协助组员完成任务、配合完成测试任务、配合开发完成重现缺陷、督促进度
专业技术能力、掌握测试基础知识、编程、计算机网络知识
问题解决能力，技术上的问题、工作中的问题、沟通问题；
沟通表达能力，和技术人员、产品人员、上下级的沟通；
宏观把控能力，有效控制测试时间、有效控制测试成本、有效制定测试计划、有效进行风险评估、有效控制测试方向。
软件开发和软件测试有什么区别
软件开发是通过写代码来生成一个软件，也就是从无到有的过程。 而软件测试则是测试一个软件有没有问题，能不能上线，也就是把软件变得更好，起到把关质量的作用。 软件开发是有产品产出的，而软件测试则没有，但是这并不影响软件测试的重要性。
测试用例在什么阶段写
测试用例要尽早写，通常会在测试设计阶段来写测试用例，即《需求规格说明书》和《测试计划》都已经完成之后
w模型
测试项目具体的工作
搭建测试环境
撰写测试用例
执行测试用例
写测试计划，测试报告
测试，并提交BUG表单
跟踪bug修改情况
执行自动化测试，编写脚本，执行，分析，报告
进行性能测试，压力测试等其他测试，执行，分析，调优，报告
如果让你来测试扫码支付，你会考虑哪些场景？
-
功能测试用例
卡的类型：
一类户：借记卡、信用卡、各个开户行
二类户：虚拟账户如微信里的零钱账户、支付宝的余额宝、电子账户
二维码的商户类型（微信、支付宝、汇宜、银联）
支付限额（单笔限额、累计限额、日累计、月累计、支付笔数）
退款（退款入口、退款进度、退款结果）
对账
资金流动（我方扣款数额正确，对方收款数额正确）数额及时效
支付结果展示、交易明细
连续扫码支付，每天的扫码支付次数限制及数额限制
二维码有效期
有无相机权限
前后置摄像头
像素低端的手机能否扫码成功
兼容性，兼容性（不同手机厂商自带相机功能实现不一致） -
安全性：
1.是否有超时超次限制
2.测试用户操作时相关信息是否写入了日志文件、是否可追踪等
3.如果使用了安全套字，需要测试加密是否正确，加密前后的信息完整性，正确性 -
性能
1.用户操作的响应时间
2.系统的吞吐量（TPS）
3.系统的硬件资源情况（CPU、硬盘、磁盘）
4.网络资源占用情况等。 -
异常场景
异常情况（卡异常、余额不足）
微信测试发红包功能
微信发红包的测试可以从功能(正常+异常)、性能、安全、兼容性、界面、易用性进行测试。
-
功能测试
-
在红包钱数，和红包个数的输入框中只能输入数字
-
红包里最多和最少可以输入的钱数 200 0.01
-
拼手气红包最多可以发多少个红包 ，超过最大拼手气红包的个数是否有提醒
-
当红包钱数超过最大范围是不是有对应的提示
-
发送的红包个数超过最大范围是不是有提示
-
余额不足时，红包发送失败
-
在红包描述里是否可以输入汉字，英文，符号，表情，纯数字，汉字英语符号，是否可以输入它们的混合搭配
-
输入红包钱数是不是只能输入数字
-
红包描述里许多能有多少个字符 10个
-
红包描述，金额，红包个数框里是否支持复制粘贴操作
-
红包描述里的表情可以删除
-
发送的红包别人是否可以领取
-
发的红包自己可不可以领取 2人
-
24小时内没有领取的红包是否可以退回到原来的账户
-
超过24小时没有领取的红包，是否还可以领取
-
用户是否可以多次抢一个红包
-
发红包的人是否还可以抢红包 多人
-
红包的金额里的小数位数是否有限制
-
可以按返回键，取消发红包
-
断网时，无法抢红包
-
可不可以自己选择支付方式
-
余额不足时，会不会自动匹配支付方式
-
在发红包界面能否看到以前的收发红包的记录
-
红包记录里的信息与实际收发红包记录是否匹配
-
支付时可以密码支付也可以指纹支付
-
如果直接输入小数点，那么小数点之前应该有个0
-
支付成功后，退回聊天界
-
发红包金额和收到的红包金额应该匹配
-
是否可以连续多次发红包
-
输入钱数为0，"塞钱进红包"置灰
-
-
性能测试
1.弱网时抢红包，发红包时间
2.不同网速时抢红包，发红包的时间
3.发红包和收红包成功后的跳转时间
4.收发红包的耗电量
5.退款到账的时间 -
兼容性
1.iOS和安卓是否都可以发送红包
2.电脑端是否可以抢微信红包 -
界面测试
1.发红包界面没有错别字
2.发红包和收红包界面排版合理
3.发红包和收红包界面颜色搭配合理 -
安全测试
1.对方微信号异地登录，是否会有提醒
2.红包被领取以后，发送红包人的金额会减少，收红包金额会增加
3.发送红包失败，余额和银行卡里的钱数不会少
4.红包发送成功，是否会收到微信支付的通知 -
易用性测试
1.红包描述，可以通过语音输入
2.支付方式可以为指纹支付也可以为密码支付
说下常用的黑盒测试方法？什么情况下用哪种？
等价类划分、边界值分析、错误推断法、因果图法、判定表分析法、正交试验法、功能图法、场景法；
等价类划分：等价类划分的方法就是将程序的输入域划分为若干部分，也可以说是若干个等价类，然后从各个部分中选取少数代表性数据进行测试。
边界值分析法：边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
错误推测法：测试者根据经验、知识和直觉来发现软件的错误，来推测程序中可能存在的各种错误，从而有针对性地进行测试
因果图法：是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况
判定表分析法：判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。
正交试验法：正交是从大量的试验点钟挑选出适量的、具有代表性的点。正交试验设计就是研究多因素多水平的一种设计方法，它是一种基于正交、高效率、经济的试验设计方法
功能图法：一个程序的功能说明通常由动态说明和静态说明组成。动态说明描述了输入数据的次序或转移的次序。静态说明描述了输入条件与输出条件之间的对应关系。
场景法：多数软件系统都是用事件触发来控制业务流程，事件触发时的情景便形成了场景，场景的不同触发顺序构成了用例。
白盒测试黑盒测试的区别吗
黑盒测试：
黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。
“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，因此不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。
常用的黑盒测试方法有：等价类划分法；边界值分析法；因果图法；场景法；正交实验设计法；判定表驱动分析法；错误推测法；功能图分析法。
白盒测试：
白盒测试也称为结构测试或逻辑驱动测试，是针对被测单元内部是如何进行工作的测试。它根据程序的控制结构设计测试用例，主要用于软件或程序验证。白盒测试法检查程序内部逻辑结构，对所有的逻辑路径进行测试，是一种穷举路径的测试方法，但即使每条路径都测试过了，但仍然有可能存在错误。因为：穷举路径测试无法检查出程序本身是否违反了设计规范，即程序是否是一个错误的程序；穷举路径测试不可能检查出程序因为遗漏路径而出错；穷举路径测试发现不了一些与数据相关的错误。
白盒测试需要遵循的原则有：1. 保证一个模块中的所有独立路径至少被测试一次；2. 所有逻辑值均需要测试真（true）和假（false）；两种情况；3. 检查程序的内部数据结构，保证其结构的有效性；4. 在上下边界及可操作范围内运行所有循环。
常用白盒测试方法：
静态测试：不用运行程序的测试，包括代码检查、静态结构分析、代码质量度量、文档测试等等，它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具（Fxcop）自动进行。
动态测试：需要执行代码，通过运行程序找到问题，包括功能确认与接口测试、覆盖率分析、性能分析、内存分析等。
白盒测试中的逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。六种覆盖标准发现错误的能力呈由弱到强的变化：
1.语句覆盖每条语句至少执行一次。
2.判定覆盖每个判定的每个分支至少执行一次。
3.条件覆盖每个判定的每个条件应取到各种可能的值。
4.判定/条件覆盖同时满足判定覆盖条件覆盖。
5.条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
6.路径覆盖使程序中每一条可能的路径至少执行一次。
测试扫码支付，测试场景
二维码场景用例
针对二维码写用例，可以分：
1.生成的二维码是不是能正确识别，支付方拿着手机能扫的出来
2.二维码的准确性，扫码后的功能对不对（本来是收款码，要是生成付款码，那就不对了）
3.二维码的尺寸，清晰度
4.二维码是否会刷新（一般收款码不会变，付款码会定时刷新）
5.离二维码距离。离二维码角度，正面扫码，侧面扫码，横竖屏扫码，拍照后本地识别扫码。Android和iOS不同设备扫码，会正常显示吗
扫码场景
扫码是支付方的使用场景了
1.网络环境，无网络的时候，二维码还能不能扫
2.扫码的时候，是能自己输入金额，还是固定的支付金额（个人收款是用户随便输入金额，生成的订单扫码是固定金额）
3.如果是商户生成的固定的订单，用户是否可以串改金额？
4.如果是商户生成的固定的订单，用户支付后，能不能重复支付？
5.多用户同时扫码支付场景，固定订单，只能被支付一次
支付场景
-
支付金额场景：
1.支付的金额是否可以为空，为0，负数
2.支付的金额最多几位小数，一般是2位小数，精确到分
3.单笔最大金额
4.单日最大金额 -
支付方式：
1.支付方式：余额，余额宝，花呗，信用卡，银行卡
2.支付顺序，默认的支付顺序是怎样的（或者自己设置的支付顺序）
3.当第一个支付余额不足的时候，是否能默认用第二顺序的支付，依次类推
4.不同的支付方式，会有单笔限制，比如不同银行卡会有不同额度 -
支付密码：
当用户选择了支付方式，支付金额后，下一步就是输入交易密码
1.密码支付，还是指纹支付，还是刷脸支付
2.密码正确，交易成功
3.密码错误，交易失败
4.交易失败后，是否能重新支付
5.用户取消支付
6.用户不支付，放着让它过期超时 -
支付状态：
支付之后，那么就会有支付状态
1.支付失败，订单状态
2.支付成功，订单状态
3.用户取消支付，订单状态
4.支付超时，订单状态 -
对账：
1.支付方支付成功后，钱是不是变少了
2.收款方收款后，是立即到账，还是延迟到账?
3.收款方如果没网，对方支付成功后，下次联网是否能看到收款记录
4.当然支付宝还有语言播报：支付宝到账xx元 -
退款：
支付方付款后，突然反悔了，那么此时就涉及到退款功能了
1.退款是原路返回，还是怎样的？
2.立即到账，还是人工处理？
3.退款时候有没有扣手续费？
4.退款后，订单状态变更 -
手续费：
说到手续费，如果对方是花呗，信用卡，那么就涉及手续费的问题
1.对方花呗，信用卡付款，手续费扣比例对不对？
2.退款的时候，手续费会不会算你的？ -
红包和券
1.如果支付方有平台红包可以用，是否能抵扣平台红包，收款方不受红包影响
2.还有券的使用，满减券，是否能叠加，还是固定商品使用券
3.涉及退款的时候，这些红包和券是作废，还是原路返回
余额宝测试用例
用户角度：
功能性测试：用户能否成功生成用于支付的二维码或二维码，二维码出现后屏幕能否变成增亮的模式，用户能否成功选取不同的付款方式，比如“花呗”、“账户余额”、“余额宝”、“银行账户”等。扫码完成后，用户能否收到支付成功的界面，并且界面能正确显示用户支付的金额，包括付款信息、是否使用优惠、折扣等。
界面测试：打开支付宝后，能否正确显示界面，二维码的界面是否正确，支付的每个步骤界面是否正确。不会出现前端界面错误，或者打开不了界面。
易用性测试：在整个用户支付的过程中，操作步骤是否简易方便。
兼容性：测试扫码支付功能，在不同手机品牌，不同操作系统下是否兼容。
安全测试：二维码如果超过安全时间后能否自动更新为新的二维码。测试整个支付流程的安全机制能否成功实现。
压力测试：持续的扫码，测试扫码支付功能在强压的状态下，工作状态如何。
网络测试：测试在不同网络环境下，不同网络信号强度的情况下，整个支付流程是否出现卡顿，卡顿的点容易出现在哪里。
商家角度：
功能性测试：扫码枪能否成功扫到用户手机中的二维码，扫码成功后能否收到钱，并且成功生成收款的界面。支付宝后台、商家后台、用户手机能否成功传输支付结果信息。
易用性测试：在不同光线，屏幕不同亮度的情况下，能否成功完成扫码收款的功能。
微信发送图片的测试用例
功能测试：
- 点击原图发送，接受方是否接收原图
- 是否可以正常发送和接受图片
- 一次最多发送几个图片
- 图片的个数是否有限制，最新版的微信最多可以发送99张连续的图片
- 图片尺寸过大是否可以发送
- 图片尺寸过小是否可以发送
- 不同格式的图片是否可以发送，比如png，jpg，jpge
- 发送图片后，接受方不点击查看原图，原图多久后失效
- 图片是否可以在相册中选择，是否可以直接拍照发送
- 发送的图片是否可以撤回
- 发送图片失败是否可以重试
- 发送的图片是否可以删除
性能测试：
- 发送图片，上传需要多久
- 图片接收需要多久，是否在需求的时间内
兼容性测试:
- 不同的手机系统、不同的版本、不同的浏览器、不同的手机型号、不同的电脑版本和系统是否兼容
- 在网络条件不好的情况下，是否可以正常的收发消息
界面显示：
- 双方的头像是否正常
- 消息显示是否正常
场景组合测试(网络测试)：
- 给网络条件不好或者无网络的好友发消息，恢复网络条件时，是否能接收正常
- 给网络条件不好或者无网络的好友发语音、视频消息时，恢复网络条件时，是否有提示
- 正在编辑文字消息时，语音、视频聊天中断结束后，是否回到正在编辑的聊天框
- 正在语音、视频聊天时，电话或者短信进入，是否会有提示
- 语音、视频聊天时，手机进入低电量模式，是否会有提示
微信发送朋友圈的测试用例
微信朋友圈测试用例_赵jc的博客-CSDN博客_微信朋友圈测试用例
如何进行接测试
通过模拟客户端 or Web浏览器向服务器发送请求，服务器接收请求后对接收到的数据做处理，同时向客户端返回应答
1、判断请求: 是否正确, 系统默认的请求成功，会返回200状态码, 假如请求错误返回400, 404, 500等状态码
2、判断数据: 返回数据的正确性与完整性
3、判断安全性: 接口一般不会随意暴露在网上被其他人任意调用,一般我们会对接口做出一些限制,比如请求次数、请求频率限制等等
接口测试：
接口文档
接口文
主要包括如下几个部分：
- 接口说明
- 请求方式
- 请求URL
- 请求参数
- 返回数据
- 返回实例
接口用例设计原则
接口测试的原理就是模拟客户端向服务器发送请求报文，服务器接收请求报文后对相应的报文做处理并向客户端返回应答，客户端接收应答的过程。
接口测试采用的方法其实与黑盒测试一致的，甚至可以把接口测试理解为没有界面的功能测试。只不过接口测试的测试点更多一些，除了界面上需要验证的各种功能点，还包括接口的安全、接口的性能等。
一般测试用例的设计要从单接口参数的校验到整个业务功能点的验证，还可以验证一些安全性和异常情况。
微信提现测试用例
1.功能测试：
- 输入金额大于/小于/等于可提现金额
- 输入的提现金额大于可提现金额时是否会有提示
- 提现金额输入框是否可以输入除数字以外的字符、最多允许几位小数
- 连接点多次提交按钮，进行重复提交
- 提交之后，没有绑定银行卡，是否会有提示，临时添加银行卡，并且选择该银行卡；
- 验证提现时输入交易密码正确与否的情况
- 验证提现超时情况;
- 当提现失败，资金退回
- 验证在ios、安卓，web端的提现场景；
2.UI界面：
- 界面排版是否错位
- 是否有错别字
- 风格是否统一
3.性能：
- 提现金额的到账时间是多久
- 是否有金额到账提示
- 金额提现成功之后，可提现金额一栏是否会减少相对应的金额
4.安全：
- 提现的金额是否成功进入对应的账户
- 提现是否有密码验证/指纹验证
5.弱网：
- 网络兼容性2/3/4/5g
- 网络异常
6.易用性：
- 是否易操作、易理解
微信登陆界面的测试用例
- 功能测试：
- 输入正确的用户名和密码，点击提交按钮，验证是否能够正确登录
- 输入错误的用户密码，验证登录是否失败，是否有相应的提示信息
- 登陆成功后能否跳转到正确页面‘
- 检查是否能够选择不同的登陆方式进行登录，如使用手机号、微信二维码
- 记住用户名功能
- 登陆失败后，不能记录密码功能
- 密码是否有非明文显示，使用星号圆点等符号代替
- 有验证码时，要考虑文字是否扭曲程度过大不容易识别，刷新按钮是否好用
- 登陆页面中的忘记密码、注册、登出等连接是否正确
- 输入密码的时候，大写键盘键盘开启有提示信息
- 什么都不输入点击提交按钮，是否有提示信息
- 界面测试：
- 布局是否合理，按钮和输入框是否整齐
- 输入框和按钮的长度，高度是否符合要求
- 界面设计风格和UI的设计风格是否统一
- 界面中的文件是否简洁易懂，有无错别字
- 性能测试：
- 打开登陆界面，需要的时间是否在需求要求的时间内
- 输入正确的用户名和密码之后，检查登录成功体跳转页面的时间是否在需求时间内
- 模拟大量用户登录，检查一定压力下是否可以正确的进行登陆跳转
- 安全测试：
- 登陆成功生成的cookie，是否同意被盗取
- 用户名和密码是否通过加密的方式，发送给web服务器
- 用户名和密码的验证应该是服务端验证
- 密码和用户名的输入框，应该屏蔽sql注入
- 防止暴力破解，检测是否有登录次数显示
- 是否支持多用户在同一台机器上登录
- 同一个用户是否能在多个机器上登录
- 兼容性测试
- 不同移动端和PC端功能是否正确
- 同平台下的不同微信版本版本登录是否正常
- 不同分辨率下的显示是否正常
- 本地化测试
- 不同于语言环境下， 页面显示是否正确
如何对页面进行测试
- ui测试：
- 页面布局，页面样式检查，控件长度是否正确
- 是否支持快捷键
- 功能测试：
- 对页面上的各个控件进行测试
- 密码框是否为明文显示，输入是否做了去空格处理
- 安全测试：方式sql注入，脚本注入测试；后台验证测试，对于比较重要的表单，进行后台安全测试；数据是否经过了加密处理
- 兼容性测试
- 性能测试
购物车测试用例
- 界面测试
- 界面布局排版是否合理
- 是否有错别字
- 不同卖家的商品是否有明显的区分
- 功能测试：
- 未登录时
- 将商品加入购物车，页面跳转到登录页面，登陆成功之后加入的商品是否存在
- 点击购物车菜单，跳转到登录页面
- 登陆后
- 所有的链接是否正确
- 商品是否可以成功加入购物车
- 购物车的商品是否有限制
- 商品总数是否正确
- 删除功能是否好用
- 价格显示是否正确
- 商品文字太长时是否能够完整显示
- 店铺名字太长时是都能够完整显示
- 可以用券的商品是否打标
- 新加入购物车商品的排序
- 购物车的结算功能是否好用
- 未登录时
- 兼容性测试
- 不同浏览器
- 不同移动端
- 易用性:
- 删除是否有提示
- 是否有返回顶部功能
- 商品结算时是否显示明细
- 性能测试
- 压力测试
- 并发测试
测试发开需要的能力
需要软件测试的理论基础，比如白盒黑盒测试
需要编程语言的基础
计算机基础知识
需要具备：
业务分析能力，分析业务的整体流程、分析被测业务的数据、分析被测系统的架构、分析被测业务的模块、分析测试所需要的资源、分析测试完成目标
缺陷洞察能力，一般缺陷的发现能力、协助组员解决问题、配合完成测试任务、配合开发重现缺陷、督促项目的整体进度
专业技术，掌握测试基本原理、掌握计算机知识、熟练运用测试工具
解决问题的能力、技术上的问题、工作的问题
沟通表达能力，和技术人员、产品人员、上下级的沟通
商品文字太长时是否能够完整显示
8. 店铺名字太长时是都能够完整显示
9. 可以用券的商品是否打标
10. 新加入购物车商品的排序
11. 购物车的结算功能是否好用
3. 兼容性测试
- 不同浏览器
- 不同移动端
- 易用性:
- 删除是否有提示
- 是否有返回顶部功能
- 商品结算时是否显示明细
- 性能测试
- 压力测试
- 并发测试
测试发开需要的能力
需要软件测试的理论基础，比如白盒黑盒测试
需要编程语言的基础
计算机基础知识
需要具备：
业务分析能力，分析业务的整体流程、分析被测业务的数据、分析被测系统的架构、分析被测业务的模块、分析测试所需要的资源、分析测试完成目标
缺陷洞察能力，一般缺陷的发现能力、协助组员解决问题、配合完成测试任务、配合开发重现缺陷、督促项目的整体进度
专业技术，掌握测试基本原理、掌握计算机知识、熟练运用测试工具
解决问题的能力、技术上的问题、工作的问题
沟通表达能力，和技术人员、产品人员、上下级的沟通
宏观把控能，有效控制测试时间、有效控制测试成本、有效执行测试计划、有效进行风险评估、有效把控测试方向。