全网最全面的软件测试常见面试题3500问，涵盖一线大厂面试题，背完就能拿捏面试官

四、项目

4.1 简单介绍下最近做过的项目

根据自己的项目整理完成，要点：

1）项目背景、业务、需求、核心业务的流程

2）项目架构，B/S还是C/5，数据库用的什么? 中间件用的什么？后台什么语言开发的？

是否有做App端，是否有H5是否开发小程序等等。

3）项目前端有哪些功能模块，后台有哪些功能模块？

视频教程：【呕心沥血】耗时7天整理的金三银四必看的软件测试频面试题 涵盖 接口自动化测试框架面试题_哔哩哔哩_bilibili

4.2 拿一个你所负责的模块，讲下具体怎么测的?

根据自己的项目整理完成，核心要点：

1）拿一个你负责过的模块，核心业务模块讲解

2）业务流程是怎样的，需求怎么样，有什么规则没，规则简单介绍

3）你是如何分析的，讲明分析思路，测试点，主要怎么考虑测试的，主要核心测试重点在哪里，

用了什么测试方法等等。

4.3 你在这个项目里面主要做了些什么工作？

1. 在这个项目中，主要是以功能测试跟后台接口测试为主，主要参加了需求评审会议，用例的编写，

参与用例的评审，执行测试。

1. 协助开发定位问题解决发现的bug，编写测试报告，协助上线。
2. 另外就是做了APP的一些相关项测试，像兼容性测试、稳定性测试、安装卸载版本覆盖测试和app性能都是有做过的，例外后期有做过接口自动化等。主要就是做了这些工作。

[这个具体根据你自己的简历上写的来说]

4.4 你们项目组有多少人、开发多少个、测试多少个?

[公司具体人数，可以不太清楚，项目组多少一定清楚]

[这个一定要根据自己的简历项目大小来说，不能乱说]

产品1、项目1个、架构师1个、前端3个、后端5个、ios1个、Android 1个、

测试3个(测试主管，核心测试人员)、运维1个、UI一个

4.5 测试人员怎么分工的?

1）我们测试组3人，1个测试组长，2个测试，一般都是根据需求的复杂程度大小来，

尽量是自己熟悉哪个版块的就继续做那个版块。

1. 比如：我这边主要是负责前端大部分的功能模块，还有接口测试跟ui自动化测试，另一个同事主要是功能测试这边，组长这边也负责一些功能测试，包括一些性能跟安全测试。
2. 其实测试工作也划分的没有那么细，后期我们也会做交叉测试，相互测试功能，性能跟安全测试我也会参与一下。

4.6 项目的送代周期? 多久一选代? 一个版本你们发现多少bug

[切记工具自己所选择的项目来回答]

我们公司是这样的，迭代还是蛮快的，一般是两个星期一个迭代，迭代测试两轮。Bug的话不一定哦，关键还得看开发，哈哈，开发的版本质量好的话，BUG就会少些，整个版本比较好的情况下大概也就二十来个BUG，当然如果遇到开发是个新手，那么找到60-70个也是很常见的，比如之前的那个金融项目，足足发现了72个BUG，这样的情况下追踪BUG的工作量都比较的大，如果是版本选代的话，那么基本就不会出现多少BUG了。

参考答案2

因为我们项目的用户活动和三方合作平台比较多，一般半个月或者1个月肯定会有一个迭代版本，

假如用户或者合作方突然有很紧急的需求，那一般老大他们会向上发邮件和OA呈批给(产品经理，项目经理)，如果通过了就会马上加急处理这个需求，测试完成直接上线。

现在都是维护为主，但新需求也不断有，一般一个版本上百个bug是有的。

4.7 你们整个项目写了多少用例，你负责的模块大概写了多少用例?

[切记己根据自己的项目及负责的模块来]

答：这个得根据项目的复杂程度，我们最近做的这个也还好，整个项目写了大概2干3百多条(有点多了)，我负责的模块就写了一千多条(你要思考，你负责了哪些模块，大概评估下，不要乱喊)。

总结注意点：没有标准答案，先说你的前置条件，再说数据，只要你前置条件和数据匹配即可。

4.8 最近的版本写了多少用例?

(总结注意点：没有标准答案，先说你的前置条件，再说数据，只要你前置条件和数据匹配即可

特别注意：你如果是半个月的版本，一般给你两天写用例，你自己评估下写多少。

半个月的版本：1-2天需求分析，1-2天写用例，1天评审用例，其余的时间就是执行回归bug，编写测试报告)

最近的版本因为没有特别的用户活动，产品那边也没有给特别大的改动需求，我负责的

有5个模块吧，大概有180多条用例。

4.9 你的需求分析一般几天，用例大概写了多长时间?执行了多长时间?

如果按照2周一个版本来算的话，我们需求分析一般是由产品SE先组织我们开会，讲清新版本需求，然后我们再花1天到1天半时间去详细分析需求，另外有2天左右时间来写用例，写完用例会进行用例评审，后面的时间基本就是在执行用例，提bug，并跟进bug修复问题。

4.10 在uat测试的时候，突然客户临时要大量的数据

备注说明：uat：测试人员提供用例，uat环境已搭建好，他就开始来执行，如果发现问题，

需要协助，谁负责这个需求，就找对应的人，发现bug，提交到uat版本里面，修复完了，

客户需要回归验证的，我们公司只是辅助他去执行测试。

答案：

看他需要的数据能不能从上个版本，或者生产环境导入数据进来测试，如果没有，我们看能不能 批量修改数据去测试，如果不行，我们只能通过存储过程造数据了。

4.11 发现哪些映像比较深刻bug/经典bug?

根据自己的项目来准备，核心要点：

1）有哪些经典或者说影响比较深刻的Bug，最好是与业务相关的Bug，不要举例说前端的Bug

2）具体怎么分析，讲明你的分析过程。如何定位的......

比如:业务逻辑漏洞；

支付功能:

1）商品选择支付的时候，实际已扣款成功，但是用户后台显示该商品没有付款，

导致不能使用该商品提供的服务。

2）商品所显示的价格是x元，但是实际支付的时候显示和扣款的价格是y元(x≠y)

找密码流程：

按照常规操作，会直接跳跃了某个必须的流程(流程缺失)，但是通过url修改参数又可以访问到 该流程，存在安全和逻辑漏洞。

安全漏洞：

1）登录账户：退出or注销之后，浏览器返回键回退之后又可以回到已登录的页面继续操作，识 别用户身份的信息并没有失效，用登录后才能访问的url直接访问也可以登录，安全漏洞。

2）搜索功能：前端页面的搜索输入框中输入特殊敏感符号

(如script> alert(document.cookie)

  cookie信息直接以弹框的形式暴露出来。

3）新增功能：一开始没有限制字符的类型和数量，当输入特殊符号、超长的字符，

提交后直接抛出包含有 INSERT INTO的完整SQL语句。

4）前端搜索：以敏感字符直接搜索后，客户端和服务端都没有任何字符过滤or转义处理，

直接把数据库和网站服务器的名称、版本暴露。

数据调用/加载异常:

1）翻页功能：有时候会出现前面几页翻页和数据显示都是正常的，往后再翻页就会

出现翻页不了or加载的数据异常。

1. 前端页面有几级菜单的情况下，程序都已经调用过，第一级是正常展示的，但是第二级、

三级有可能被折叠而没有显示在浏览器显示。

3）定位到某个导航主题，调用的数据并不是该主题分类的数据，而是调用成了其他分类的数据。

不可逆操作，导致流程受阻：

1）APP测试，orH5页面测试，触发某个操作，比如手机触屏下滑刷新页面，不能恢复到操作前 的正常页面。

2）输入某个异常值提交之后，程序没有相关的处理机制，导致页面保存，没法继续进行其他操 作。

3）登录方式切换：登录时有几种不同的方式，如：密码登录&短信验证码登录，但同一时刻默认 只能显示一种登录方式，当从密码登录界面点击短信登录切换到短信验证码登录界面之后， 没有切换返回密码登录界面的功能。

4）删除异常：正常情况下可以从列表中删除记录，但是若先对列表记录执行了搜索功能之后， 再次删除的时候可能出现删除无响应而删除不了数据。

5）弹框阻止：当触发某个操作，如“保存”、提交”or某个开关按钮，界面中弹单出一个提示框， 此提示框不管怎么操作都无法关闭，直接阻碍了页面上其他功能的操作。

附件上传时，未控制格式尺寸和容量大小，系统处理出现异常：

1）文件上传功能：没有限制上传的文件格式、尺寸和大小，当上传非常规文件(如js文件)、大 容量文件(如：图片大小>20M)，较大分辨率(如：1600×1200)，服务器没有相应的异常处理 机制，导致网站出现持续长时间的卡顿，影响后续操作。

2）上传的是非常规的文件，如js格式文件，程序无相关控制，直接将js文件上传到数据库， 前端页面访问时若不能解析则出现异常页面。

缺少非空判断，服务器报500错误：

1）编辑包含多个字段的页面时，有一些字段在程序中控制是必填的(事先未知)，但是没有任何 说明提示，当不填写这些字段，直接保存时会出现服务器异常页面，报500状态错误。(特别 是在管理后台容易出现此场景)

2）在形如以下结构的if函数中，关系表达式的条件没有对某个变量(该变量因代码疏漏未作初 始化赋值)进行非空判断，就直接执行语句体，程序已空值null进行参与运算而出现异常， 如500错误if(关系表达式)样式导致异常。

3）某个功能(如：金额输入和统计)在A页面程序限制只能输入正整数，而在B页面却没有相应 控制，若不小心在B页面输入了非正整数，比方小数，A和B的数据分别传递到到同一个C 页面时数据处理会出现异常。

4）文章上传/图片上传：超长字符的文章内容or较大尺寸的图片上传，程序没有进行相关的压 缩和截取，直接完全调取到前端页面，导致浏览样式异常，

App测试过程中常Bug: https：/www.cnblogs.com/123456ww/12198075.html

[经典bug：前端申请借款中，用户没有信用额度或者借款金额超过了用户信用额度但是却能成功提交审核]

[发现途径：我是在模拟借款人，借款金额提示我的可用额度为0，但是我输入5000的借款金额点击提交审核提示我提交成功，等待审核]

[解决：首先我去数据库查找到对应的表，比对我的信用额度跟界面显示的数据是否一样，一样我就把数据库的记录，填写的借款信息和我借款成功的界面显示截图都保存好。之后提交这个bug，开发人员通过修改代码，我再复测，有没有重现bug]

[还有一个就是在借款流程中，我们通过修改数据库中的数据，把借款时间修改了，制造出一个逾期未还款的数据，结果显示还款的金额比借款金额还少，而且管理要收得特别高，存在不合理性]

[还有一个是在产品上线后，运维人员在统计数据时发现少了一条数据，我们去数据库检查发现0分0秒的数据没有统计，后来开发人员修改了代码之后就解决了]

1）服务费计算错误，计算公式开发这边写错，本来是利息0.3，写成003，开发修复bug。

2）退出用户，后退还可以进入到原来的登录完成操作后的界面，原始，退出用户，没有删除用 户对应的 session，导致后退完成后，用户用户 cookie可以进行操作。

3）重新选择下拉框，输入信息全部清空，原因，修改类型，重新刷新界面，输入数据，并没有 保存缓存里面，导致一刷新，原来信息没有，解决，开发选择不同借款类型，不再进行刷新。

4）借款标题，输入xss攻击代码，导致接口所有的数据不存在显示，因为xss脚本，当然代码 处理，开发这边进行转义字符串。

5）谷歌浏览器登录不成功，显示验证码。

4.12 每个阶段测试开发在干嘛（比如你写用例的时候开发在干嘛？）

1）需求阶段，大家都在了解需求

2）测试准备，

测试编写用例，开发做概要设计，详细设计，然后就是编写代码，编写接口文档，设计文档。

1. 测试执行阶段，

测试人员执行用例，发现bug、提交bug、开发修复bug(开发还有可能在开发未完成的功能)

4.13 你们公司是否敏捷开发

可以说是，也可以说不是。[具体看你了不了解敏捷开发模式]

[问了我有没有做过敏捷测试]

扩展知识储备：

1、什么是敏捷开发

敏捷开发以用户的需求进化为核心，采用达代、循序渐进的方法进行软件开发。

在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，

具语可视、可集成和可运行使用的特征，换言之，就是把一个大项目分为多个相互联系，

但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

2、敏捷开发优缺点：

特点：

1. 能适应快速的客户需求变化，快速的交付，注重与客户的沟通。最优先要做的是通过尽早的、

持续的交付有价值的软件，把项目拆分成各个小的子项目，快速开发快速交付，有问题及时调整， 适合高风睑项目。

1. 交付周期短，交付的时间间隔越短越好，一周一个迭送代，甚至有时候一周多个选代，

不过每个选代版本的需求不会太多，注重项目持续选代开发交付。

1. 整个项目开发期间，业务人员和开发人员必须天天都在一起工作，团队规模不能太大，

团队间强调面对面的交谈。

4、更关注可交付可以使用的软件，而非文档。

5、对团队技术要求高，能快速适应客户对需求的变化。

6、敏捷团队只专注于开发项目中当前最需要的、最具价值的部分。这样能很快地投入开发，另外， 较短的迭代周期使团队成员能迅速进入开发状态。

优点：

1、敏捷开发的高适应性，以人为本的特性，适应客户的更快需求变化，更快的交付成果。

2.更加的灵活并且更加充分的利用了每个开发者的优势，调动了每个人的工作热情。

缺点：

1、由于其项目周期很长，所以很难保证开发的人员不更换，而没有文档就会造成在交

接的过程中出现很大的困难。

2.特别项目存在新手比较多时，老员工比较累.(对开发团队人员的技木要求高)

3、敏捷开发流程图：

4.14 你这个项目做了多久? 你这个项目现在的用户里有多少? 活跃量多少?

时间根据简历来

比如：一年时间，金融项目：100W用户2W活跃用户

五、测试思维

5.1 打电话功能怎么去测？

我们会从几个方面去测试：界面、功能、兼容性、易用性、安全、性能、异常。

1）界面我们会测试下是否跟界面原型图一致，考虑浏览器不同显示比例，屏幕分辨率。

2）功能：给不同人员打电话，不同号码打电话，不同运营商，测试每个按钮是否正常使用，拨打号 码，是输入还是，复制过程，还是其他地方跳转过来，多次拨打电话，双卡选择不同电话卡。

3）兼容性：不同手机型号，厂商，不同系统版本，屏幕大小，分辨率，内存大小

4）易用性：操作是否说的越多越好

5.2 给你一个杯子怎么测？

功能测试：

主要关注水杯基本功能

1、水杯是否可以正常装水

2、水杯是否可以正常喝水

3、水杯是否有盖子，盖子是否可以正常盖住

4、水杯是否有保温功能，保温功能是否正常保温

5、水杯是否会漏水，盖住盖子拧紧后是否会漏水

界面测试：

主要关注水杯外观、颜色、设计等方面

1、外观是否完整

2、外观是否舒适

3、颜色搭配及使用是否让人感到舒适

4、杯子外观大小是否适中

5、杯子是否有图案，图案是否易磨损

易用性测试：

主要关注水杯使用是否方便

1、水杯喝水时否方便

2、水杯拿起放下是否方便，这里会行注到水杯形状的测试

3、水杯装水是否方便

4、水杯携带是否方方便

5、水杯是否有防清功能

6、水杯装有低温或者高温水时，是否会让手感到不适

性能测试：

1、水杯装满水时，是否会露出来

2、水杯最大使用次数

3、水杯的保温性是否达到要求

4、水杯的耐寒性是否达到要求

5、水杯的耐热性是否达到要求

6、水杯掉落时时，是否可以正常使用

7、水杯长时间放置时，是否会发生泄露

兼容性测试：

主要关注水杯是否可以装其他液体，如果汁、汽油、酒精等

可移植性测试：

主要关注水杯放置环境等

1、将水杯放在常温环境中，使用是否正常

2、将水杯放在零下的环境中，使用是否正常

3、将水杯放在高于正常温度的环境中，使用是否正常

安全性测试：

主要关注水杯外观和各种异常条件下是否释放有毒物质等

1、当水杯装满热水时，水杯是否会烫手

2、当水杯装上水后，是否会产生有毒物质

3、把水杯放在零下环境时，是否会产生有毒物质

4、把水杯放在高温环境时，是否会产生有毒物质

5.3 图像上传功能的测试点

1.检查图片上传路径

2.检查图像上传和修改功能

3.检查各种扩展图像文件的上传（例如JPEG、PNG、BMP等）

4.检查文件名中含有空格或其他可用特殊字符的图片的上传

5.检查重复名称图片上传

6.图片尺寸大于最大允许值，上传时应该显示适当的错误消息

7.检查上传的图片文件类型外的其它文件时(例如txt、doc、pdf、exe等等)，

应该显示适当的错误消息。

8.检查如果上传的图片满足指定的高度和宽度(如果有定义的话)则可以成功上传，否则不能上传。

9.上传大尺寸图片时应显示上传进度条

10.检查上传过程中的取消按钮是否有效

11.检查文件选择对话框中的文件列表是否只显示支持文件类型

12.检查上传多个图像的功能

13.上传后检查图像质量，图像质量不应该改变

14.检查用户是否能够使用/查看上传的图像

5.4 搜索框的测试

1)搜索按钮功能是否能够实现，验证搜索框的功能是否与需求一致

2)点搜索后，原先的搜索条件是否清空。

3)直看比较长的名称是否能查到输入过长查询数据，看其有没判断，报错系统是否会截

取允许的长度来检索结果。

4)是否有忽略空格的功能，需要有忽略前置空格和后置空格的功能，但不能把中间空格忽略

5)不输入任何内容点击搜索看查询的结果

6)查看搜索框内的默认内容是否与设置的一致，焦点放置搜索框中，搜索框默认内容是否自动被清空

7)输入系统中存在的与之匹配的条件看其的查询后数据的完整性显示记录条数正确、文字折行显示正 确页面布局美观列标题项、列显示内容、排序方式符合需求定义。

8)组合中文和各种特殊符号输入查看能否正确搜索到合的内容

9)输入系统中不存在的与之匹配的条件，是否搜索出信息或者给予提示信息

10)使用复制粘贴，测试搜索框是否能执行

11)注意在光标停留的地方输入信息时，光标和所输入的信息会否跳到别的地方

12)反复输入相同的数据(5次以上)看是否报错

13)敏感词汇，提示用户为敏感词汇

{

语句提1；

}else{

语句提2

}

3.某个被调用的方法中缺少某些参数的定义，在不知情的情况下，直接调用时传递了未定义过的参数or类型不匹配的参数到该方法，如果对应网站是处理批量的业务，则可能会导致大面积的500异常页面，对网站正常业务和SEO排名损失风险比较大。

4.新增、编辑->保存，对所提交的字段有的末作非空限制，可以直接保存成功，保存后以空内容展示，可能存在不确定性，比如操作已保存成功的空记录时，是否会影响其他正常添加的记录，是相互独立的，还是会牵连到其他所有的类型。

服务器配置错误(漏配or错配)，更新后出现500 or 404：

1.服务器配置文件，如 web.config中把前端访问的url地址写错，直接发布更新之后，前端页 面访问可能会出现404错误。

2.程序代码中的某些逻辑错误和服务器配置相冲突时，前端页面触发某些特定按钮or页面可能 会出现500错误。

数据传递过程无控制，导致数据输出到界面功能异常or样式变形：

1. 搜索功能：有的页面本身有回显所搜索关键词的功能，搜索输入框填写的keywords字符较长

(如：100字符)，直接搜索后这些长字符显示在页面中，使得页面原来的样式变形，

甚至有的功能按钮被挤到页面之外而不能使用。

2.新增功能：对于新增字段的长度没有任何限制，超长字符新增可以保存成功，回到列表页也没有对 显示的字符长度进行控制，所有字符长度都展示在列表，挤压其他字段的

14)不同搜所的条件之间来回选择，查看是否出现页面错误

15)测试多个搜所条件时，要注意搜所条件的组合测试，可能不同组合的测试会报错

16)点击搜索框，看能否在搜索栏下方显示提供设置好的最近热门搜索词，点击任一可以

直达搜索结果页

17)点击搜索框时，到有搜所历史时，能显示历史搜所内容，历史搜所内容应从上到下按

时间排序，点击清空历史清空所有搜索记录

18)直看搜索框最大输入字符数

5.5 给你一个电梯，你怎么测

功能测试：

1)测试电梯能否实现正常的上升和下降功能

2)电梯的按钮是否都可以使用

电梯内分楼层键是否正常

电梯内开关门键是否正常

电梯内的报鳘键是否正常使用

电梯外的上下键是否正常

3)电梯门的打开，关闭是否正常

4)报警装置是否可用

5)与其他电梯之间是否协作良好

6)通风状况如何

7)突然停电时的情况。

8)关注显示屏，电梯内外的显示屏显示的电梯层数、运行方向是否正常

9)有障碍物时，电梯门的感应系统是否有效

10)上升途中的响应

电梯本来在1楼，如果有人按18楼，那么电梯在上升到5楼的时候，有人按了10楼

这时候是否会在10楼先停下来;

电梯下降到10层时显示满员，此时若8层有人等待电梯，是否在8层停

11)是否有手机信号

可靠性测试：

1)门关上的一刹那出现障碍物。

2)同时按关门和开门按钮。

3)点击当前楼层号码

4)多次点击同一楼层号码

5)同时按上键和下键

易用性测试：

1)电梯的按钮的设计符合般人的习惯吗

2)楼层按键高度(小孩和一些身高矮的用户会按键不方便)

3)电梯是否有地毯、夏天是否有空调、通风条件、照明条件、手机信号是否通畅

4)电梯是否有扶手，是否有专针对残疾人的扶手等等

压力测试：

1)看电梯的最大承重量，在负载过重时报警装置是否有提醒

2)在一定时间内不断让电梯上升、下降

稳定性测试：

1)看电梯在最大负载下平稳运行的最长时间

安全性测试:

1)下坠时是否有制动装置

2)暴力破坏电梯时是否报警，超重是否报警

3)停电情况下电梯是否有应急电源装置

性能测试：

1)测试电梯负载单人时的运行情况(基准测试)

2)多人时的运行情况(负载测试)

3)一定人数下较长时间的运作(稳定性测试)

4)更长时间运作时的运行情况(疲劳测试)

5)不断增加人数导致电梯报警(拐点压力测试)

5.6 更换头像的测试点（站在app的角度来分析）

功能测试：

1，点击头像可以放大观看

2，查看头像是否支持放大，缩小

3，刚创建账号时是否显示默认头像

4，查看头像之后点击其它区域自动退出

5，头像支持的图片格式，图片大小

6，支持相机拍摄的图片和从网上下载的图片

7，选择完图片后是否有一个定框

8，选择相片方式，从手机相册获取

9，选择相片方式，用手机照相机拍照

10，头像显示的是方形还是圆形

11，选择图片范围时图片是否支持放大/缩小

12，选择好图片区域后保存，头像是否居中显示，还是只显示选择图片区域的某个角落

13，保存完图片后是否会有提示更换头像成功

14，修改头像后去app其它模块时是否马上刷新显示最新的头像

15，进入更换头像界面时可以取消更换头像

16，选择从相册选取图片还是从照相机时都能取消，返回到修改头像界面

17，头像是否支持本地缓存，断开网络之后是否还能显示头像

18，网络异常时，修改头像失败，是否会有提示

弱网测试：

双卡的情况下，切换到另一张卡

连接到一个假热点

用 fiddler模拟2G、3G、4G情况下的弱网情况

从手机流量切换到wifi

性能测试：

上传的时间

上传过程中

手机死机? 手机没电? 手机卡停机?

上传成功以后，去数据库查看有没有

上传成功后，退出登录，在登录看是否是更新后的头像

上传成功后，删除头像，切换到其他页面，再切换回来看头像的展示情况

兼容性测试：

更换成功后，在不同手机屏幕，不同分辨率，不同手机型号，不同系统版本的情况下，头像的展示

5.7  qq登陆界面怎么测试，分析

主要考察：测试者是否熟悉各种测试方法，是否有丰富的 App/eb测试经验，以及相关开发经验，以及设计 Test case的能力

功能测试( Function test)

1)输入正确的用户名和密码，点击提交按钮，验证是否能正确登录

2)输入错误的用户名或者密码，验证登录会失败，是否有相应的错误提示信息

3)登录成功后是否跳转到正确的页面

4)用户名和密码，如果太短或者太长，应该怎么处理

5)用户名和密码，中有特殊字符，和其他非英文的情况

6)记住用户名和密码的功能

7)登陆失败后，不能记录密码的功能

8)用户名和密码输入时前后有空格的处理

9)密码是否可见，是否用星号标识

界面测试(U|Test)

1)布局是否合理，2个 Testbox和个按钮是否对齐

2) Textbox和按钮的长度、高度是否复合要求

3)界面是否美观

4)图片，颜色，字体，超链接，是否都显示正确

性能测试( performance test)

1)打开登录页面，需要几秒

2)输入正确的用户名和密码后，登录成功跳转到新页面，不超过5秒

3)能支持多少个用户同时登陆

安全性测试( Security test)

1)登录成功后生成的Cookie，是否是httponly(否则容易被脚本盗取)

2)用户名和密码是否通过加密的方式，发送给Web服务器

3)用户名和密码的验证，应该是用服务器端验证，而不能单单是在客户端用 javascript验证

4)用户名和密码的输入框，应该屏蔽SQL注入攻击

5)用户名和密码的的输入框，应该禁止输入脚本(防止XSS攻击

6)错误登陆的次数限制(防止暴力破解)

兼容性测试( Compatibility Test)

1)不同的平台是否能正常工作，比如 Windows，Mac

2)移动设备上是否正常工作，比如 iPhone， Andriod

3)不同的分辨率

4)不同的浏览器大小(浏览器最大化，和非最大化)

5.8 微信点赞

功能测试：

1)给某个好友点赞，点赞数+1，点赞栏显示具体点赞人的名字，该用户手动点赞回馈

2)点完赞后，共同好友在点赞区能看到该人是不是点赞了，非共同好友看不到

3)两个头像一样的人点赞，能否正确显示

4)点完赞后，在点击点变成点赞取消

5)取消点赞-不通知用户

6)点赞后，通知用户，取消，在点赞，此时不通知用户

7)多个用户同时对其点赞，点赞数正常

8)最多能点多少个赞-边界值测试

9)可以从点击点赞区头像，进入相应人的主页查看

10)点赞是否按照时间顺序排序

11)点赞后是否能够正常评论

app端测试：

1)弱网情况下，点赞能否实时更新

2)点赞时，有短信或者电话进来，能否显示点赞情况

3)耗电量，耗流量关注

性能测试：

1)大量用户并发点赞时，该接口的响应时间，最大承受的qps

2)大量用户并发点赞时，此时界面进行点赞，点赞功能是否正常

兼容性测试：

1)不同手机型号，点功能，显示功能是否正常

总结：下方是作者从功能测试到自动化测试拿到年薪34w，花费三年打造的软件测试到测试开发全职业生涯资料包，有需要的话可以点击文章末尾的小卡片备注000领取哈

 接口自动化测试：

三天搞定python接口自动化测试框架项目实战全套教程【高启强推荐】
web自动化测试：最新最全花1W买的Python+Selenium全栈Web自动化测试
app自动化测试：【大厂首选】最新最全的appium自动化测试框架实战 从0到1封装全教程
测试开发：一口气拿下三家大厂offer的测试开发全套教程以及python全栈自动化测试
面试：【呕心沥血】耗时7天整理的金三银四必看的软件测试频面试题 涵盖 接口自动化测试框架面试题
简历：金三银四面试全网最牛的软件测试简历包装 看完直接拿捏大厂面试官
postman：年入58w的测试开发讲解的全套postman接口测试 接口自动化测试全套教程
跨平台框架：大厂标配技术栈RobotFramework自动化测试框架实战，不用代码也可以做自动化
框架：
pytest：顶尖框架教程pytest自动化测试框架 接口自动化测试框架全套阿里大厂内部教程
unittest：一线大厂测试开发讲解的一整套unittest自动化测试框架，全程干货，详细讲解
httprunner：阿里大佬手敲50套httprunner接口自动化测试框架 附加框架源码+快速入职教程