今天离五一放假还有7天！！！！！！！！！今天下午去吃魏家凉皮的麻酱凉皮，不要辣老好吃了。但是最绝的还是他家的双球，榛果巧克力和朗姆葡萄简直绝配~~~

        言归正传言归正传，我是一个完全的自动化测试新手，正在一步一步地学习Airtest框架。接下来的文章我将记录我的入门过程，希望与大家分享我的探索经历。如果各位在阅读中发现任何问题或建议，请随时指出，我们共同进步。学习路上难免会遇到挑战，但每一次尝试都是成长的机会。

         在进入测试之前我针对要测试的微信小程序写了一个思维导图，把主功能测试部分按点整理了出来，所以今天这篇文章我就第一个主功能——供应商查询（supplier）的第二部分——供应商搜索来进行脚本编写。

        我想先说一下最近的一点小感悟吧，其实我一直以为Airtest的“点点点”可以实现对小程序的全流程测试。什么意思呢，就比如说我今天编写代码的时候想要在搜索框输入关键字/词，然后如果搜索之后的列表中存在与这个关键字/词相同或高度匹配的资料，并且不能出现别的不相关资料才算测试通过，我以为光靠之前的那种方法完全可以实现，但是怎么写都绕不开”提前匹配好图像“这个弯，所以我意识到现在练习的”点点点“已经完全不够用了。不过学习不就是这样嘛，完全不会到认知偏差，再到修正思路，再到学习补足，so，接下来我将会在之前的基础上继续探索，加强学习！

        所以我今天会用到相关性校验，因为我前面提到的那种思路”点点点“无法实现，涉及到接口测试与抓包，所以我退而求其次用只要存在与关键字相关的就是测试通过，不管不相关的是否出现。后续我将先学习OCR，然后再学习抓包，之后学习接口，一步一步与Airtest进行结合。

 一、设计思路

1. 进入供应商页面；

2. 重置筛选条件（回到首页，确保初始状态）；

3. 根据测试用例选择搜索类型：
   3.1 港口搜索；
   3.2 供应商搜索；

4. 判断搜索结果：
   4.1 是否显示“暂无数据”；
   4.2 结果是否与关键字相关（弱相关校验，通过预设图片判断）；

5. 报告输出 pass / fail / error，并自动截图记录。

二、代码编写

（1）模块一：相关图片字典（related_dict）

        使用 Python 字典保存各个关键字（如“花莲”、“泉州”、“上海佳珏船务公司”等）对应的模板图片，方便在相关性校验时直接调用，避免重复写Template。对于未配置的关键字，则跳过相关性校验，只验证是否有数据。

（2）模块二（函数一）：进入供应商页面（enter_supplier_page）

        滑动页面，点击小程序入口，点击供应商菜单。属于所有测试用例的前置条件。

（3）模块三（函数二）：重置筛选（reset_filter）

        由于每个测试用例执行前需要恢复初始状态，将重置操作封装成函数。对于返回按钮与首页按钮使用了if-else判断：如果存在首页按钮则直接点击；否则先点击返回按钮，再点击首页按钮，确保彻底重置到初始状态。

（4）模块四（函数三）：港口搜索（port_seacher）

1. 点击搜索框进入搜索界面；

2. 点击输入框；

3. 使用text（keyword）输入关键字；

4. 等待搜索结果加载。

（5）模块五（函数四）：供应商搜索（supplier_seacher）

        逻辑与港口搜索类似，但搜索入口略有不同（直接点击输入框搜索）。封装为独立函数以区分搜索类型。

（6）模块六（函数五）：无数据判断（check_no_data）

        捕获“暂无数据”页面的特定图像，定义为no_data_img,使用exists()判断是否存在，作为结果判定的依据之一。

（7）模块七（函数六）：弱相关校验（check_related）

1. 从related_dict中获取关键字对应的目标图片；

2. 如果没有配置图片，则直接返回Ture（只验证有结果即可）；

3. 如果配置了图片，则在页面中循环查找（最多 5 次），每次找不到则向上滑动（swipe），直到找到相关结果；

4. 找到返回Ture，否则返回False。

        这一步是为了验证搜索结果是否“明显相关”，避免出现“有数据但与关键字无关”的情况。

（8）模块八（函数七）：执行一个完整的测试用例（test_seacher）

根据正向与逆向测试思路编写：

1. 调用reset_filter()重置状态；

2. 根据search_type调用港口搜索或供应商搜索；

3. 使用check_no_data()判断是否出现“暂无数据”；

4. 根据expect_empty期望值进行判断：

   • 期望无数据：如果has_no_data为真则通过，否则失败；

   • 期望有数据：如果has_no_data为假且check_related(keyword)返回真，则通过，否则失败；

5. 通过snapshot(msg=...)自动截图并记录结果；

6. 异常捕获：任何异常都返回False，并截图标记为error。

（9）模块九（函数八）：总调度（run_all）

1. 调用enter_supplier_page()进入供应商页面；

2. 定义一个列表results存储每条用例的执行结果；

3. 编写港口搜索用例（正向：花莲、泉州；逆向：西安，期望无数据）；

4. 编写供应商搜索用例（正向：全名、上海、佳珏；逆向：西安，期望无数据）；

5. 统计通过数量并输出汇总结果。

三、结果展示

（1）用例一：

（2）用例二：

（3）用例三：

        这个用例本来结果应该返回”显示暂无数据“（”西安“没有被配置入港口中），但是由于存在缺陷，所以不相关被显示在列表中，导致测试失败。

（4）用例四：

（5）用例五：

（6）用例六：

（7）用例七：

（8）最终结果：

四、问题总结

        在本次编写脚本的过程中，遇到的最核心问题是如何在 UI 自动化中合理判断搜索结果的正确性。一开始我尝试通过“匹配所有结果是否完全符合关键字”的方式来校验，但很快发现这种方式不可行：一方面错误结果是无法穷举的；另一方面，UI 层基于图像识别，无法像接口层那样精确判断字段内容，容易出现误判。针对这一问题，我调整了测试思路，将校验方式改为“弱相关性验证”，即只判断搜索结果中是否存在与关键字明显相关的资料卡片，同时结合“暂无数据”提示进行辅助判断。

        今天编写的搜索功能脚本整体没有上一篇复杂，但是思路上却大不相同了，总结如下：通过图片模板识别实现搜索框定位与关键字输入，结合参数化设计实现多用例复用；在结果校验阶段采用“弱相关匹配 + 无数据判断”的策略，兼顾功能验证与实现可行性；在执行过程中引入循环滑动查找机制，应对列表类页面的动态加载问题；同时构建统一测试用例函数与主流程调度模块，实现搜索测试流程的结构化与标准化；并结合异常捕获、自动截图与日志记录机制，提高脚本的稳定性与问题定位效率。整体来看，本次脚本在功能完整性、可维护性以及工程化程度上都有明显提升。

本篇文章先介绍这么多，待我下篇文章再继续奋斗！！！！！