In a game like Starcraft often there is only one entrance in the base (a ramp or just a map bottleneck). You can find out if there is only one entrance by trancing two or three paths to the base(lets call them scout paths) from different locations on the map. One location could be the enemy base the other locations could be places on the opposite side of the map.

No bad idea, but ther are the usual problems of such stochastic approach utilizing randomness. E.g., if all your random locations on the map are on the left of the base, than you might miss the entrance on the right.
Randomness includes bad luck, and to avoid it, you need more ‘samples’, or locations in your case. It also matters that the samples are well distributed. E.g. if you generate them using a 4x4 grid over the whole map, chances you would miss the right entrance are smaller than using 16 of random points over the map.

However, i think there is a better way: Instead tracing paths from random points to the base, you can use Dijkstra to grow paths outwards from the base. No goal is needed, just grow the paths until they have a distance large enough to ensure we're outside. Would look like this:

All the possible paths from the base form a tree. The green start point in the base is the root.

We get many red end points, and we know the shrotest path to each of them.

So we also know the shortest path from each red point to the base, obviously. Which is what you're interested in.

Now we can walk the path from each red do to the base, and we could increase a counter for each path segment we visit. Would look like this maybe:

The less entrances you have, the higher the numbers near them.
So maybe you could use that number to identify entries, or more generaral: Locations worth to defend, and paths more likely to be visited than others.

Comparing this with your idea to use random points of the whole map, using Dijsktra your entire map would be filled with paths, so you do much more work. And maybe even better: You do not need to come up with good random points at all. And maybe you do not need to classify an ‘entrance’ either. Maybe the number is all you need to get expected behavior.

(Maybe the number can be computed already while doing the path finding, and there is no need to traverse the paths.)

You could use Dijkstra too, I haven't thought of that.

After looking at your pictures I've realized two or three paths in my approach might not be enough. What you can do is run the operation once, block the bottleneck area where paths begin to overlap then run the pathfinder a second time. If no path is found in the second attempt the blocked bottleneck is the only entrance in the base.

If no path is found in the second attempt the blocked bottleneck is the only entrance in the base.

Non quite, it's only that the probability of an existing second entry has been reduced from doing one more attempt.

But for a watertight solution, we could do this:
After one entry is found, block it temporarily, then do a new search (i would do so still from the base outwards).
We repeat this until no more entry can be found, then we can be sure to have them all.

But ofc. we can only guarantee correctness if we can robustly classify what's inside the base and what's outside, which is just another variant of that same hard problem. (There is a similar problem in topology, which is finding smallest loops identifying holes or handles. That's a NP hard or complete problem. Greedy algorithms exist but they are very slow.)

However, for AI it's probably good enough to have a faster solution with a good probability to be right. It does not need to be perfect, i guess.