UI自动化的经典八股以及黑盒测试八股
UI自动化八股
印象最深的bug
前言猜想
当时我们做的是一个金融管理系统，里边有个客户列表，当时按照测试用例去执行的时候，发现出现点击客户删除却无法删除，于是就提了一个单，但是开发后来发现删除客户没问题，又给我打回，后来我去查看服务器日志结合数据库，去进行定位，发现在出现
删除异常操作的时候，没有输出日志。这时，又去尝试了一下删除其他人，发现可以删除，同时有日志的输出，抛开日志不谈，当时出现这个问题我第一想法就是是否是数据库里的某一列的参数加了外键，导致删除不了，然后我就去数据库查看，发现并没有，然后我就尝试把出现异常的那条数据里边的参数一个一个去改，尝试是不是能成功删除，当客户名称被改掉后，发现删除成功。经过对比和推断，我推测如果客户名称一样就会无法删除，并且不会输出日志，其他情况删除功能是正常的，然后我把数据库中其中一个客户的名称改掉之后，果然两个都能删掉。
验证
定位BUG：接下来我去验证我的想法，我找了一个可以正常删除的这个客户，我看了一下开发打的日志，我们开发在日志里边有打他的SQL语句，我发现他是通过客户名查到了这个客户ID，然后用delete语句去删除，通过where ID等于去删除。那么当名字相同的客户查到了两个ID而代码里删除 delete 的时候用的是等于号，等于两个ID，数据库不支持这样的语法。所以给我提示的是删除异常。那么最后我们的开发进行修复，修修这个bug的方式是将用户进行删除动作的时候，传参改为传前端的点击的客户的ID，让后端直接通过ID去删除，因为这个ID是一个主键全局唯一的不重复的。同时将 delete 语句中的等于号改成了in支持单个删，也支持批量删。
语句分析
- 原始的删除语句中，可能是使用了类似以下的形式
DELETE FROM 表名 WHERE ID = 值;
在这种情况下，如果数据库中存在多个具有相同名称的记录，而这些记录分别拥有不同的ID，那么在执行上述语句时，将会匹配到多个ID，从而导致错误。因为SQL的DELETE语句一次只能删除一个记录，而无法同时删除多个记录。
- 为了修复这个问题，开发人员可能进行了如下修改：
DELETE FROM 表名 WHERE ID IN (值1, 值2, ...);
这样的修改将允许在一次数据库查询中同时删除多个记录，通过将多个ID包含在IN子句中实现。这样，即使数据库中存在多个具有相同名称的记录，也可以通过其唯一的ID来精确地删除每条记录。
你在ui自动化发现的报错一般是哪些情况
1、一般都是元素定位不到的问题，可能是开发改了页面元素改了结构，之前用的 xpath定位就有可能报错。
2、可能是第三方库更新了版本导致了库与库之间不兼容，比如 ddddocr 由于 pillow 库
更新了，导致 ddddocr 中有一个函数报错，后面对 pillow 库降级处理就可以了。
3、或者是网络延迟，导致页面还未跳转成功，最后导致元素定位不到，需要加等待
4、或者是代码问题，比如别的同事写的代码健壮性不够，后面出现自动化代码报错
5、或者是需求更改，代码还未修改报错，比如之前一些主干功能现在修改了一点点功
能，可能会导致 U 自动化需要部分重写。
6、可能是真的有 bug，也会报错，比如 elementnotfound，或者断言错误，这种情况可能是页面点击按钮，未跳转，或者页面文件不匹配，或者颜色不匹配，或者就是功能未完步
你是怎么做自动化测试
1、我一般会查看哪些功能是比较稳定的，然后查看是否被覆盖，如果没有覆盖，就会找到对应的功能测试用例，然后根据功能测试用例去编写自动化的脚本
2、对元素做定位，对预期结果做断言，然后跑通过之后，再提交到 git 上，并把功能测试用例标记为已覆盖自动化。
哪些功能用例不好做成UI自动化
1、新功能这些，因为不稳定，一般稳定后才做自动化
2、手机验证码，这块无法做自动化。
3、需要人眼去识别的，比如判断两个图片是否完全一样
4、滑块验证码，点击顺序的验证码。
5、比如账号注册是需要企业微信扫码的，这种扫码是无法自动化的，扫了码还要做人脸识别。
6、购买年费，需要扫码付款，这也做不了。
黑盒测试八股
如果给你一个网站，你如何测试？
1、查找需求说明、网站设计 等相关文档，分析测试需求。
2、制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：
功能性测试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试。
3、设计测试用例：
功能性测试可以包括，但不限于以下几个方面
链接测试，链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回等；
多媒体元素是否可以正确加载和显示；
多语言支持是否能够正确显示选择的语言等。
性能测试一般从以下三个方面考虑
压力测试：进行压力测试时，可以使用工具如Apache JMeter、LoadRunner、Gatling等，通过设置并发用户数、请求频率等参数来模拟高负载情况。
负载测试：在进行负载测试时，可以逐渐增加并发用户数或请求量，观察网站的响应时间、吞吐量和资源利用率等指标，以确定其性能极限和瓶颈。
强度测试：强度测试通过模拟持续高负载，监测系统资源使用情况和日志，以确保网站稳定运行。
数据库测试
数据库一般需要考虑连接性，对数据的存取操作，数据内容的验证等方面。
安全测试
基本的登录功能的检查；
是否存在溢出错误，导致系统崩溃或者权限泄露；
关于开发语言的常见安全性问题检查，例如 SQL 注入；
兼容性测试
浏览器的兼容性；操作系统的兼容性；软件平台的兼容性；数据库的兼容性。
4.开展测试，并记录缺陷。
合理的安排调整测试进度，提前获取测试所需的资源，建立管理体系（例如，需求变更、风险、配置、测试文档、缺陷报告、人力资源等内容）。定期评审，对测试进行评估和总结，调整测试的内容。
目前主要的测试用例设计方法是什么
- 白盒测试：逻辑覆盖；循环覆盖；基本路径覆盖。
- 黑盒测试：边界值分析法；等价类划分；错误猜测法；因果图法；状态图法；测试大纲法；随机测试；场景法。
用过黑盒测试的哪些方法，分别怎么测试的
介绍自己负责的测试模块，以及测试的功能，以及日常负责的测试任务
测试模块和功能：
1.用户管理模块
测试用户注册、登录、权限管理等功能。
验证用户角色划分是否准确，如学生、教师、管理员等。
2.课程管理模块
测试课程添加、修改、删除等功能。
验证课程信息展示是否准确、课程时间表的生成和显示等功能。
3.成绩管理模块
测试成绩录入、查询、统计等功能。
验证成绩计算准确性、成绩报表生成等功能。
4.选课管理模块
测试学生选课、退课、课程冲突检测等功能。
验证选课系统的稳定性和性能，防止选课时出现系统崩溃或超时。
5.考试管理模块
测试考试安排、试卷生成、阅卷等功能。
验证考试系统的安全性和稳定性，防止考试数据泄露或意外中断。
课程管理模块测试任务
- 需求分析和测试计划编写:根据需求文档和功能规格，编写课程管理模块的测试计划，确定测试范围、测试环境和测试资源。
- 测试用例设计：设计各种场景下的测试用例，包括正常情况、边界值情况和异常情况。
- 在测试环境中逐步执行设计好的测试用例，记录测试结果，包括添加课程时的界面交互、系统响应时间，以及验证修改课程信息功能的正确性和稳定性。
- 缺陷管理：在发现任何缺陷时，应立即报告并记录在缺陷管理系统中，例如，当修改课程信息时，若课程名称字段允许输入超出最大长度的字符但系统未给出错误提示，则期望系统应该限制课程名称的输入长度并给出相应的错误提示。
- 性能和安全测试：结合 LoadRunner 录制脚本并执行测试场景
通过以上操作，可以使用 LoadRunner 对课程管理模块进行性能测试，并验证系统在添加和修改课程信息时的响应时间和资源利用情况。同时，可以使用 LoadRunner 对课程管理页面进行安全测试，检查是否存在权限控制方面的漏洞，确保只有授权用户能够访问和修改课程信息。
