Well, it is hard to comment on this since we do not know the environment in which you are testing or the abilities you will have to test.
However, if you are using OSPF you know from RFC 1583 that it routes datagrams based upon both the destination address and type of service. It gets this information from the IP header. So your test cases can include the information that is in the IP header.
From the topology, each router constructs a tree of the shortest paths with itself as the root. This shortest-path tree gives the route to each destination. So, in that case, you could model a test system (if you have such) where you know the shortest route and see if that is, in fact, taken.
This protocol also provides inherent load balancing, something that you can test. Thus you have test cases for that.
All exchanges between routers are authenticated in OSPF. So you can check to make sure that ACK signals are being sent correctly by monitoring the requests/transactions.
You can also test for specific aspects of OSPF, such as the abilitly of sites to subnet and the ability to support both host and network specific routes. You can also test for the area-localization specific aspects. (I assume you know that all routers in an area must agree on that area's parameters. This is because separate instances of the link-state algorithm is run for each area and so most configuration parameters are defined on a localized basis. All routers belonging to an area must agree on that area's configuration and your routing information will not get through.
If you are using "virtual" links in your configuration, you can check if those appear contiguous. (They should.)
There are other aspects to this, of course, but as you can probably see all I am doing is taking the basics of what makes OSPF work and thinking what could prove that it is working that way.