• 友情提示,fiddler 自己学倒是没啥,公司或者企业使用有可能被发律师函~

  • 供参考哈,仅个人思路。

    1. 先明确业务问题

    下架报异常导致的下架失败,是真失败还是假失败,这条数据还展示的 c 端商品列表,是应该展示,还是不应该展示。

    如果下架接口报异常,但是实际是成功的,比如数据库状态发生变更等,理论上 c 端商品列表不应该展示,那就结合代码或者开发人员去定位问题,此时应该要去定位三个问题,a.下架接口报异常的问题 b.下架接口报异常,但是却成功下架的问题 c.下架接口报异常,但是成功下架,C 端商品列表还展示的问题

    如果下架接口报异常,实际也是失败的,这条数据应该展示在 c 端商品列表,那么就需要看下架接口为什么报异常。是环境问题还是需要定位的缺陷

    1. 再回到自动化测试本身

    从得到的信息看,是接口自动化测试,那么以上场景应该划分到下架接口,还是展示的 c 端商品列表接口(比如下架失败,展示商品列表接口的用例),应该有明确的规范,避免用例重复覆盖。

    另外,这条用例失败后,会不会影响自动化测试稳定性,自动化到这里就不再执行了,还是说就是普通的一个用例失败,也是需要考虑的。

    自动化测试用例,很多时候因为各种原因,不会覆盖异常、失败的场景,此时是否需要把这些场景支持或者用手工测试覆盖,也是需要考虑的。

  • 测试嫌弃自己的一生 at 2024年11月26日

    研也匆匆 测也匆匆 恨不能想疯
    改也匆匆 上也匆匆 一切都随风
    狂测一轮 延期一轮 快上一轮
    背锅一轮 谁与我生死与共

  • 有,如果看不了代码,会给工作增加很多困扰和不确定性

  • 只要不被裁,蒙着眼走

  • 一杯茶的功夫,你就被优化了

  • 那些 “被消失” 的缺陷 at 2024年11月07日

    没管理者乱来谁愿意搞这些鬼名堂

  • 有目标有行动的苟着

  • 最大的作用是代替了以前需要查的工具书。

  • AI agent 基本都长这样

  • 测试软考中级有必要考吗 at 2024年10月28日

    个人觉得还是有必要的。
    新入行的有个系统的认知。
    老家伙可以对自己的知识结构进行一定梳理。
    主要是钱不多也不难

  • AI 写的用例可以帮你做出好看的数据,比如领导 PPT 上 XX% 的用例已经用 AI 编写,反正他们又不看用例质量的。

    具体实际效果如人饮水,冷暖自知。叫得越凶的,往往是离一线越远的。

  • 安全测试学习 at 2024年10月14日

    以下是问的 AI,我觉得没啥毛病(学习内容可能少了点,毕竟安全什么都要懂)。

    学习安全测试是一个系统的过程,以下是一个为期三个月的学习计划,可根据个人情况进行调整:

    第一阶段:基础知识(1-4 周)

    1. 了解安全测试概念

      • 学习网络安全和应用安全的基本概念。
      • 推荐书籍:《Web Application Security Testing Cookbook》。
    2. 学习基础网络知识

      • TCP/IP 协议、HTTP/HTTPS 协议。
      • 推荐资源:Coursera 或 Udacity 上的网络安全课程。
    3. 掌握操作系统基础

      • 熟悉 Linux 和 Windows 的基本操作。
      • 学习命令行操作和常用工具。

    第二阶段:安全测试工具与技术(5-8 周)

    1. 学习常用安全测试工具

      • 了解并实践使用工具,如 Burp Suite、OWASP ZAP、Nmap、Metasploit 等。
    2. 进行静态和动态分析

      • 学习静态代码分析工具(如 SonarQube)。
      • 学习动态应用测试(DAST)的基本方法。
    3. 学习渗透测试基础

      • 学习渗透测试的流程和方法论。
      • 推荐阅读《The Web Application Hacker's Handbook》。

    第三阶段:实践与项目(9-12 周)

    1. 进行模拟测试

      • 在虚拟环境中进行模拟测试,尝试攻击和防御。
      • 可以使用 DVWA(Damn Vulnerable Web Application)进行练习。
    2. 参与线上 CTF(Capture The Flag)竞赛

      • 通过 CTF 平台(如 Hack The Box、TryHackMe)提升实战技能。
    3. 总结与复习

      • 复习所学的知识,整理笔记和心得。
      • 尝试撰写测试报告,总结测试发现与整改建议。

    额外资源

    • 在线课程:Udemy、Coursera 上的网络安全课程。
    • 书籍推荐
      • 《Hacking: The Art of Exploitation》
      • 《Penetration Testing: A Hands-On Introduction to Hacking》

    进阶学习

    • 根据自己的兴趣深入研究特定领域,如移动安全、云安全或 IoT 安全。

    希望这个学习计划对你有所帮助!如需进一步细化某部分内容,请告诉我。

    1. 让干系人相信你覆盖全了,哪怕一个用例,你能做到相信
    2. 不会出生产问题
    3. 如果出了生产问题,让大家觉得怪不了你
  • 除了 tesseract、PaddleOCR、EasyOCR 等,还可以直接调用 LLM~

  • 求大佬解惑 jmeter 压测 at 2024年10月10日

    先搞清楚测试目的,测试范围、测试场景(负载?容量?疲劳?or 其他)、业务指标等
    确定这些才能弄清楚有几个事物,然后放到事物控制器下。
    至于线程组,一般根据你测试需求来,比如你对同一个事物做负载测试和疲劳测试,参数肯定是不一样的,就弄多个线程。
    类似以下格式:
    /线程 1_负载/事物查看首页/news 请求
    /线程 2
    疲劳/事物_查看首页/news 请求

  • 大家股市挣钱了没 at 2024年10月08日

    银证转账都给干异常了。。。可怕

  • 面试官请回答 at 2024年09月29日

    呔!倒反天罡,反问是你来面试我的吗,you out!

    其实很多技术面试官并不是管理者,这么问有些时候不是很适合。

  • 请问大家如何进行提效? at 2024年09月23日

    学到了学到了,真·干货

  • 已删除 at 2024年09月23日

    赚钱么,不寒碜。行业如果领域知识门槛高,你自己写挺好的。

  • 做点自己喜欢的,热爱的并花大量时间在上面

  • 生活怪圈 at 2024年08月28日

    一个月强制改一次密码且不能与历史一样才叫痛苦,逼我在密码里加了时间戳

  • 测试用例最佳实践 at 2024年08月27日

    我来说点我实际工作中的:

    无论功能大小,能不写测试用例就不写。
    测试用例一般没时间严格和完整的执行。
    长期的项目,测试用例也没有持续维护。
    压根儿不使用版本控制软件对测试用例进行版本控制。
    一切为了统计需要。
    测试点列列就差不多了,规则穿肠过,用例心中留。
    能录制就不代码,能代码就不再写一遍用例。
    根据优先级和风险应对紧急发布。

  • 测试最终的归宿是什么? at 2024年08月21日

    承包地之后,从打工人变成给自己打工了,我觉得只要不想着赚大钱,还是不会像现在这么焦虑