There's really no 'correct' answer, as the server in question could have multiple network interfaces, each with it's own IP address and thus URL.
Not only that, the IP address could go through a firewall that does a selective forward of the packets. In other words, the firewall "is" www.companyname.com, not your server. If a request for port 80 or 443 hits the firewall, it forwards it to server1. If a request for 8080 or 8081 hits the firewall, it forwards to server2.
Now, you mention:
Of course, that URL takes me to the live site
Does it? My guess is, you don't have a firewall, and the cert is used simply for an HTTPS certificate, but if you hit www.companyname.com:8081 you're hitting your test site; this is, of course, assuming the test site is identical to the live site. If it is not, then there's really no good way to find out the IP. You'll need to do some sleuthing at the hardware level on the server and determine what IP ranges it has, and how the hosting facility maps external IP's to those ranges. That's not hard, but it varies dramatically from site to site.
On a cloud provider, you look at the virtual networking. On a co-location site, you check with the local infrastructure. On a cable modem, you check the firewall, etc.
Thanks. How do I look for an external IP address?
The easiest way is to do a tracert from the server to say 8.8.8.8.
You then look for an IP address that isn't in the private IP ranges. (wherever this server his hosted almost certainly uses private IP ranges in it's internal system.)
The easiest way is https://www.whatismyip.com/
Most cloud centers now will do this to you:
Tracing route to dns.google [8.8.8.8]
over a maximum of 30 hops:
1 * * * Request timed out.
2 * * * Request timed out.
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.
6 * * * Request timed out.
7 * * * Request timed out.
8 * * * Request timed out.
More than twenty years ago, most Unix systems had a bug with malformed PING's, that could crash the O/S. Windows itself had a problem SENDING the malformed PING, but not receiving. (it's not a security problem if you're suicidal). As a result, everyone has this general idea that "pings are bad". (You can use PINGS to conduct a denial of service attack). So many, many hosts will block PING's. I'm not convinced with any modern O/S that's patched that there's a problem, and pings can be an important diagnostic tool.
If you're on such a cloud, 'whatismyip' is about the only way to go, and even that's not guaranteed.