Pretty much everything has been said already, but to extend on a few aspects.
If you want failsafe testing on a test device before deploying on your production router, you can only do so on an exact same model. Differences between embedded devices are just too big to deduce that if the update is running fine on tl-wdr3600/ mips, it would also work on tl-wdr4900/ powerpc this doesn't work at all. An image that works on the tl-wdr3600 is very, very likely to also fine on the tl-wdr4300 (which is nearly identical hardware, just 2x2 instead of 3x3 wireless), expecting that it will also work on the closely related WNDR3800 (NAND flash, different vendor, so different bootloader constraints) is (while likely in practice) already quite a stretch; and e.g. the tl-wdr3500 (different switch than the tl-wdr3600/4300) has shown that even despite very similar hardware issues can creep in at any time that don't show up on the more common hardware (tl-wdr3600/ tl-wdr4300).
A major part of your configuration is the network setup, here you will see three major (very, very-) different approaches:
- legacy swconfig
while the traditional way for most OpenWrt devices, this approach has been rejected by mainline kernel developers and accordingly efforts are underway to get rid of it (newer targets may use dsa from the start, older ones are scheduled to be ported over) - dsa
this is the new/ mainline way to configure managed switches, for userspace, each port is represented as an individual interface, allowing hardware offloaded switching via 'normal' linux userspace configuration (iproute2, tc, brctl, etc.).
mvebu, mt762x have already switched, PRs for ipq806x, ipq40xx and ath79 exist and are fully functional - only the sheer amount of supported devices makes it hard to actually pull the trigger (without (fear of-) breaking devices). - independent network interfaces
this is commonly found on x86_64, ARM SBCs (RPi4, rockchip, sunxi, etc.), bridging and VLANs are configured 'naturally' in the linux kernel.
If you know (very well-) what you're doing, you can (manually) transpose the configurations between these device classes, but configurations have very different syntax and semantics between these different network management approaches. Given how massive the differences are, you really want to have production/ test devices using the same switch setup (everything else would not be representative and cause you massive headache going back and forth).
As an aside, even different devices both using swconfig can act rather differently - there is still the possibility of one model using two CPU-ports or only one, or using a dedicated interface for WAN - so even there configurations might not be as uniform between 'similar' devices as you might imagine.
If you just want to test "software services" (e.g. dhcp, adblock, VPN setups, etc.), you can replicate that on pretty much any supported device (including virtual machines), but anything closer to the hardware and especially the networking side of it, you do want like-for-like testing on (at least close to-) identical hardware between production and testing. The question if it will boot up and 'work' at all can only conclusively answered on identical (same model) hardware.
While the tl-wdr4900 is capable hardware, it's also very exotic and plagued by very low bootloader imposed size limits for the kernel, this hardware is fragile and has a very unclear path into the future - at this point there are no tl-wdr4900 images for 22.03~, and it's not very likely to be fixable for 22.03.0 and beyond.
OpenWrt can work pretty well on x86_64 hardware (see Tips for getting cheap used x86-based firewall with full Gbit NAT (a PC Engines APU) if you are in the US for a selection of interesting affordable low-power/mid-to-high-performance/multiple-ethernet-ports/mostly-no-wlan devices), likewise the RPi4, NanoPi r2s/ r2c/ r4s/ r5s maybe be rather interesting for higher speed connections.