Test case design

I am designing test cases for an online system. This system is composed of several WCF Web services, some ASP.NET web sites, and a SQL server backend database.

Currently, the Web UI part is not available yet. But the Web services are available. And the major workflow of the system can be achieved by various Web services calls.

I have the following test plan for now:

1. Baseline test: Test each of the Web service methods.

I am planning to take approaches such as Equivalence Class Partitioning, etc. But the problem is, all the parameters of these Web service methods are of system specific types, not simple types like date or integer. How could I enforce the Equivalence Class Partitioning?

2. Task oriented test: Combine several Web service method开发者_StackOverflows to test certain user scenarios.

The problem is, without a testable UI, I have to simulate the Web service method calls on both the server and client side. Is this a reasonable approach?

And suddenly, it seems to me that the above test can only be called API testing. Do I miss anything?

Sorry if I didn't make myself clear enough, since I am new to testing.

Thanks.

Add:

The callers of the Web service methods are some internal partners and they know these methods well. So should I test the functionality of the system only? Can I just ignore the method baseline test in bullet 1?

---

1. ECP is a logical classification of data so I am not sure why the type system (simple/custom types) is relevant. Please provide more details

2. Whether you have UI or not, you will have to provide a simple service/facade kind of api which will do the orchestration of various web services. So API testing is the good approach. You still want to test each WS independently.

---

I know what I'm saying doesn't answer all of the questions asked, but I really think that you should into unit testing much of your code. If think you will end up with a lot of tests, which requires a lot of maintenance, if you choose to test everything by calling WCF services. Write a lot of unit tests of the business logic inside your services, and make a few integration tests against a running server.