【实测】关于‘钱学森弹道’应用软件测试的设计与实现(03)【终极方案-目标趋向】

简介: 【实测】关于‘钱学森弹道’应用软件测试的设计与实现(03)【终极方案-目标趋向】

  实测系列是纯硬核技术文章,并且是博主亲自演示已经落地取得一定成果的技术和原创教程,无偿进行分享,大家一键三,支持一下!

   继续讲一个最终的复杂方案:

  4.目标趋向随机法

   这个方案不需要线上日志,也能大致预测出用户动作。毕竟真实用户,他下单的目的就是下单成功,他的所有操作都是奔着最终下单成功这件事去做的。只不过中间操作路线有不同,但总归不会去做很多无用功。而这才是一发导弹要命中目标的真实写照。

   前面的三个方案中,其实都弱化了对目标节点的趋向性,都是在恰好碰目标,碰到了就终止,碰不到就继续碰。虽然算法简单,性价比也高,但让driver失去了灵魂,而真实的用户操作是有灵魂的。并且,我们测试的目的,就是达到目标点为前提,找出各种路线上的bug。所以我们仍然要回归最纯正的钱学森弹道技术上来。

   钱学森弹道的真正可怕之处在于,导弹像有灵魂一样,看似随机,却实际全是假动作,也并非无头苍蝇乱撞,最终总是能击中目标,并且其中有个最主要的特点就是:导弹可没有走过回头路。结合到我们自动化测试中,就是避免所有无用功路径,一切随机,都要朝着距离目的地节点更近的方向走。

   这里再额外说一个适用场景,未来会有很多的AI识别自动化的风控技术出现,自动化的脚步一秒就被识破了,而你想通过完全随机伪装也可能被AI迅速识别出来,这个拦截就好像是老美的爱国者或者铁穹系统,我们的自动化driver导弹,能否突破拦截,并且成功实现目标呢?归根结底,还是要有灵魂。

   具体的实现方案是这样的:driver在抵达某个节点后,在寻找下一个节点时,虽然仍然是随机方案,但是我们要记录其相对最终目标节点的距离,这个距离我称之为(偏移量),我们所有的随机路线,随机节点选择,都是要尽量减少偏移量,使之最终为0,也就是到了目标节点。

   比如:driver在某个节点后,计算出有5个方向可以走:

   其中有1个方向是【回头路】会让偏移量增大,直接pass;

   其中有1个方向是【平移路】,偏移量不变,直接pass;

   其中一个方向是【死路】,没有其他路线,直接pass(注意,死路也有偏移量,只是需要回头,要大很多);

   还剩有两个方向是【前进路】会让偏移量变小,但是变小的幅度不同,我们全都要走,这就是2个路线用例了。

   而这个思路,这里就涉及到两个问题:

   1. 如果只有一个回头路,怎么办?

   如果只有一个回头路,说明这条路线是一条死路,直接抛弃。而事实上,我们在上一个节点选择的时候,也不可能选中这个死路,因为死路的偏移量并不会变小,所以我们一开始就不会选,选了证明你算法有bug。

   2. 如果只有平移路可以走,怎么办?

   如果只有平移路,没有前进路。这种仍然是算法出了bug,平移路的叫法是在当前节点有前进路的基础上才有平移路。如果没有前进路,那么这个平移路能否抵达目的地?能的话,那就应该叫前进路。不能的话,那这条路本就是死路,压根不会走进来。

   所以,其实如果这个算法足够优秀,很多异常问题其实都压根不用过多思考,但这里不光算法复杂,更麻烦的是,要如何获取各个节点距离目标节点的偏移量。继续听:

   其实,这个路线更像是一个复杂迷宫,通往出口的路线和走法很多,但是我们要就是要找出其中没有走回头路也没有走死胡同的所有有用功路线。

   我们想快速找到所有路线的物理办法有什么?

   1. 灌水法,通过注满水在整个迷宫通道,然后你会发现只有能走通的路线水是流动的,你把一些墨汁从入口挤入,就会发现墨汁沿着正确的路线开始走了....

   2. 蚂蚁寻路法,把很多蚂蚁从入口放进去,经过他们无休止的尝试后最终会发现可以走通的路线并做好气味记号,之后的蚂蚁便不再会走死胡同或回头路了。

   这两种方案其实本质都是一样的,都是靠着大量填充来找出答案,我们现在要做的就是找出每个节点的分类,是回头路,还是平移路,还是死路,还是前进路,前进路的话距离最终的偏移量是多少问题。

   俗话说,不走到最后你是不知道真理的。一个节点到底分类是什么偏移量是多少?我们必须要知道这个节点到目标节点的路径才行。死胡同就是死胡同,走到最后一步才知道,那我们就要走到底才行。

   这个方案听起来很笨重,类似于穷举,但其实做起来并不难。一个公司的一个软件产品,也就统计一次即可,属于一劳永逸的事,算法也很简单,就直接用我们一开始的方案完全随机碰撞法,最终统计出每个节点到目标节点的路线中最短的那条,那条一共有多长就是该节点的偏移量。

   比如:B节点到E(目标)节点。路线有很多,其中假设 B-C-D-E是最短的,那B的偏移量就是3,如果B是个死路,那么路线就肯定要回头,B-A-C-D-E,那B的偏移量就是4。

   但要注意,从B节点的路线中,我们不可以直接草率的推断出 C节点偏移量,比如B-C-D-E路线中,B的偏移量是3,那C的偏移量难道就是2么?其实并不是,在现实场景中,如果是从B走到C,那么就一定要经过D才能到E,但如果一开始是从A到C那就可能不用经过D,比如路线【A-C-E】,那这么看C的偏移量就是1。

   那么此刻问题又出现了,如果driver恰好运行到B的时候,它面前的C的偏移量是多少?是2还是1?这并非C本身的属性,而是要取决于前面的节点是A还是B,这里面就是说C是有个叠加态的,当你不确定怎么走的时候,C的偏移量即是2也是1,当你走了A或者B之后,C的偏移量就会坍塌成1个,要么2要么1。

   所以,我们在记录各个节点偏移量的时候,并非是单纯的1维字典:{A:4,B:3,C:2,D:1,E:0} 。

   而是一个2维甚至多维的嵌套字典:{A:{B:3,C:1},B:{C:2}} ,这个嵌套字典中,可以记录出,当driver在A节点时可以走B也可以直接走C,直接走C,那么C的偏移量就是1,也就说再一步就可以直通E。而当driver走了B的话,那么此刻只有C一条路走,而且C的偏移量变成了2。

   现实中,决定一个节点偏移量的可能并非只是前一个节点,可能是多个节点步骤共同决定的。所以情况还是非常复杂的,这个字典也可能是多维的。不过只要你算法写的好,在完全随机碰撞法的所有结果中进行提取就可以自动生成一个你都不需要看的多维字典,然后用本方法选择节点偏移量的时候,直接套用。比如即有A又有F又有D的情况下,又恰好走了M,此时的C是可以走的,且C偏移量是1。这种感觉。而你是不需要操心那么多的,有些事吧,看起来麻烦,但是你只要找出万变不离其宗的宗,就发现一切都自动迎刃而解。

   这个方案讨论到此结束。欢迎观看后续实现算法。

   如果上述你看的云里雾里,那么这里我们把方案还原回导弹的运行,你就会恍然大悟了!

   导弹发射后,有个节点,距离目的地10公里的高空一个确定的点。如果导弹是直着冲过去,那么导弹通过这个点后距离目的地可能1分钟就能到达。如果导弹是打斜方向经过这个点,那么为了要调整方向和必要的减速等,就需要2分钟才能到达目的地。所以哪怕同一个点,你经过的姿势不同,这个点的偏移量也是不同的。这个姿势,就是你之前经过的点决定的。

   在上面的方案中,大家甚至听到了薛定谔的猫理论,甚至联想到了多元平行宇宙和坍塌成既定事实的论点。从这,大家也能感受到钱学森弹道的神秘和强大了吧?

   而如果想彻底研究明白这个弹道,还要去理解一个实验:光的双缝干涉实验。

   先说结论:观测和不观测是会影响到实验结果的,主观意识可以影响到客观事实,而未来甚至可以改变过去,即果会影响因。什么叫做因果律武器这就是

   在我们的这个钱学森弹道测试法中,到底是如何解释和运用这些听起来匪夷所思,但有确实存在的结论呢?欢迎收看下一节哦!

相关文章
|
15天前
|
敏捷开发 测试技术 持续交付
探索自动化测试在敏捷开发中的应用与挑战
本文深入探讨了自动化测试在现代软件开发流程,特别是敏捷开发环境中的重要作用和面临的挑战。通过分析自动化测试的基本原理、实施策略以及在实际项目中的应用案例,揭示了其在提高软件质量和加速产品交付方面的巨大潜力。同时,文章也指出了自动化测试实施过程中可能遇到的技术难题、成本考量及团队协作问题,并提出了相应的解决策略,为软件开发团队提供了有价值的参考和指导。
|
19天前
|
编解码 测试技术 开发工具
测试 iPhone 应用在不同屏幕尺寸和分辨率下的响应式效果
【10月更文挑战第23天】测试 iPhone 应用在不同屏幕尺寸和分辨率下的响应式效果是确保应用质量和用户体验的重要环节。通过手动测试、自动化测试、视觉效果评估、性能测试、用户体验测试等多种方法的综合运用,能够全面地发现应用在响应式效果方面存在的问题,并及时进行解决和优化。同时,持续的测试和优化也是不断提升应用质量和用户满意度的关键。
|
17天前
|
前端开发 数据管理 测试技术
前端自动化测试:Jest与Cypress的实战应用与最佳实践
【10月更文挑战第27天】本文介绍了前端自动化测试中Jest和Cypress的实战应用与最佳实践。Jest适合React应用的单元测试和快照测试,Cypress则擅长端到端测试,模拟用户交互。通过结合使用这两种工具,可以有效提升代码质量和开发效率。最佳实践包括单元测试与集成测试结合、快照测试、并行执行、代码覆盖率分析、测试环境管理和测试数据管理。
34 2
|
17天前
|
Web App开发 定位技术 iOS开发
Playwright 是一个强大的工具,用于在各种浏览器上测试应用,并模拟真实设备如手机和平板。通过配置 `playwright.devices`,可以轻松模拟不同设备的用户代理、屏幕尺寸、视口等特性。此外,Playwright 还支持模拟地理位置、区域设置、时区、权限(如通知)和配色方案,使测试更加全面和真实。例如,可以在配置文件中设置全局的区域设置和时区,然后在特定测试中进行覆盖。同时,还可以动态更改地理位置和媒体类型,以适应不同的测试需求。
Playwright 是一个强大的工具,用于在各种浏览器上测试应用,并模拟真实设备如手机和平板。通过配置 `playwright.devices`,可以轻松模拟不同设备的用户代理、屏幕尺寸、视口等特性。此外,Playwright 还支持模拟地理位置、区域设置、时区、权限(如通知)和配色方案,使测试更加全面和真实。例如,可以在配置文件中设置全局的区域设置和时区,然后在特定测试中进行覆盖。同时,还可以动态更改地理位置和媒体类型,以适应不同的测试需求。
17 1
|
18天前
|
前端开发 JavaScript 数据可视化
前端自动化测试:Jest与Cypress的实战应用与最佳实践
【10月更文挑战第26天】前端自动化测试在现代软件开发中至关重要,Jest和Cypress分别是单元测试和端到端测试的流行工具。本文通过解答一系列问题,介绍Jest与Cypress的实战应用与最佳实践,帮助开发者提高测试效率和代码质量。
28 2
|
29天前
|
监控 测试技术 持续交付
掌握跨平台测试策略:确保应用的无缝体验
【10月更文挑战第14天】在多元化设备和操作系统的今天,跨平台测试策略成为确保应用质量和性能的关键。本文探讨了跨平台测试的重要性、核心优势及实施步骤,涵盖Web、移动和桌面应用的测试方法,帮助开发者提高应用的无缝体验。
|
30天前
|
机器学习/深度学习 人工智能 自然语言处理
探索AI在软件测试中的创新应用与实践###
本文旨在探讨人工智能(AI)技术如何革新软件测试领域,提升测试效率、质量与覆盖范围。通过深入分析AI驱动的自动化测试工具、智能化缺陷预测模型及持续集成/持续部署(CI/CD)流程优化等关键方面,本研究揭示了AI技术在解决传统软件测试痛点中的潜力与价值。文章首先概述了软件测试的重要性和当前面临的挑战,随后详细介绍了AI技术在测试用例生成、执行、结果分析及维护中的应用实例,并展望了未来AI与软件测试深度融合的趋势,强调了技术伦理与质量控制的重要性。本文为软件开发与测试团队提供了关于如何有效利用AI技术提升测试效能的实践指南。 ###
|
1月前
|
机器学习/深度学习 弹性计算 自然语言处理
前端大模型应用笔记(二):最新llama3.2小参数版本1B的古董机测试 - 支持128K上下文,表现优异,和移动端更配
llama3.1支持128K上下文,6万字+输入,适用于多种场景。模型能力超出预期,但处理中文时需加中英翻译。测试显示,其英文支持较好,中文则需改进。llama3.2 1B参数量小,适合移动端和资源受限环境,可在阿里云2vCPU和4G ECS上运行。
|
15天前
|
NoSQL 测试技术 Go
自动化测试在 Go 开源库中的应用与实践
本文介绍了 Go 语言的自动化测试及其在 `go mongox` 库中的实践。Go 语言通过 `testing` 库和 `go test` 命令提供了简洁高效的测试框架,支持单元测试、集成测试和基准测试。`go mongox` 库通过单元测试和集成测试确保与 MongoDB 交互的正确性和稳定性,使用 Docker Compose 快速搭建测试环境。文章还探讨了表驱动测试、覆盖率检查和 Mock 工具的使用,强调了自动化测试在开源库中的重要性。
|
8天前
|
JSON Java 测试技术
SpringCloud2023实战之接口服务测试工具SpringBootTest
SpringBootTest同时集成了JUnit Jupiter、AssertJ、Hamcrest测试辅助库,使得更容易编写但愿测试代码。
37 3