Are you interested in testing the hardware or testing your software product? This is a hardware site.
As pointed out in comments RS232 is not a protocol standard it is a pinout/voltage level standard. The protocol does not really have a name UART protocol is probably the closest, but there are variations on a theme there.
But this brings up the question does your product rely on RS232 levels or "TTL" levels (as in 5V, or 3.3V or 1.8V or other). RS232C has a defined range for what a "1" and what a "0" is. So for example some random uart to RS232C product may land anywhere within that, if you are testing your hardware product you probably want to test those limits the low end to see if the product functions and the high end (+/- 15V) does not damage the product. Those would be the minimum tests on voltage levels, you can do more there.
While you may set the baud rate for a specific speed 9600 for example, the reality is you are rarely at that speed. Some hardware will use the proper crystal/reference, within a tolerance of course, to generate these speeds, but often, specifically on the uC side for sure, you are not doing that. On the ideal reference clock side you are creating an approximation, say 8MHz/9600 = 833.333...
so 8000000/833 = 9603 which may not seem like much but often these are often divided down say 8x and you want to run your mcu at the lowest clock you can to save power. 2000000/(16*9600) = 13.0208 which gives 9615. 16x oversampling and it gets worse.
Bottom line is sometimes the variation is small and sometimes not as small. This is assuming a perfect clock but if the mcu is using an internal R/C oscillator, then that clock has more error than a crystal reference and it can/will drift with temperature. So your two sides are not communicating at the same speed. The 8x or 16x oversampling helps with finding the middle of a bit cell, but one has to assume it is reset on the edge of the start bit so you have to make it through 10 give or take bit cells with the worst error both side has chosen. You seem to be asking about a software product and not necessarily hardware, but you asked if the physical layer works in the same way. NO absolutely not, different hardware and different computers can definitely affect the results/success.
Test your software for breaks. In uart terms this is a long period of zeros, last time I messed with windows, it very poorly handled breaks at the driver level, tools like hyperterm, etc you have to restart, plus any software I wrote, one would hope they would have fixed this buy now but uart is so low priority and even then com ports were going away, so why would they bother to fix it? See how your software handles this. Same goes for framing errors.
Your protocol that sits on top of the uart serial protocol needs to be able to handle various framing errors in some way. One good way is to packetize the communication, a start pattern, length perhaps, and some form of checksum or CRC, if the packet does not pass this self checking then discard it. Then the next layer of protocol above that have a solution for re-sending. In any case you should test various forms of error injection.
Being a high level language environment on windows there are many layers below your code and many different versions of windows and various update levels along with the hardware windows runs on in addition to your serial/uart solution. You cant possibly own/test all combinations, but you should test more than one. "Works on my machine" will only get you so far with a product.
Do you know the minimum requirements, if you go with a clean operating system install does your software work? What is the minimum number of things a user would need to install on a clean system, to get it to work. Are there minimum versions of these software items for your product to work? How much testing have you done to prove this? Could you handle tech support questions related to these issues?
Who controls this target arm based product? And it's software? You? Does this product work as is? Does it require the user to load/configure something? Does this product have firmware updates? Does your product work with the various updates? From either a tech support perspective or a product just working perspective do you have an array of these as test fixtures with various settings and firmware versions?
Hopefully you can get the idea of what you need to look at and think about. Can the hardware affect the success of your product, absolutely, both the computer and the serial interface options. And being windows, .net, C#, and uart/serial/RS232 that is a wide range of stuff that can go wrong and needs testing and tech support, and it is not possible to test all the combinations, but you had better test some of the combinations at a minimum.