测试用例设计
我正在为在线系统设计测试用例。该系统由多个 WCF Web 服务、一些 ASP.NET 网站和一个 SQL Server 后端数据库组成。
目前Web UI部分还没有推出。但 Web 服务是可用的。系统的主要工作流程可以通过各种Web服务调用来实现。
我现在有以下测试计划：
1。基线测试：测试每个Web服务方法。
我打算采取等价类分区等方法。但问题是，这些Web服务方法的所有参数都是系统特定的 /em> 类型，而不是像日期 或整数 这样的简单类型。我如何强制执行等价类分区？
2.面向任务的测试：结合多种Web服务方法来测试某些用户场景。
问题是，如果没有可测试的UI，我必须在服务器端和客户端上模拟Web服务方法调用。这是一个合理的做法吗？
突然间，我觉得上面的测试只能称为API测试。我错过了什么吗？
抱歉，如果我说得不够清楚，因为我是测试新手。
谢谢。
Add：
Web服务方法的调用者是一些内部合作伙伴，他们非常了解这些方法。那么我应该只测试系统的功能吗？我可以忽略第 1 条中的方法基线测试吗？
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 methods 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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我知道我所说的并不能回答所有提出的问题，但我确实认为您应该对大部分代码进行单元测试。如果您选择通过调用 WCF 服务来测试所有内容，那么您最终会进行大量测试，这需要大量维护。为服务内的业务逻辑编写大量单元测试，并针对正在运行的服务器进行一些集成测试。
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.
ECP 是数据的逻辑分类，因此我不确定为什么类型系统（简单/自定义类型）是相关的。请提供更多详细信息
无论您是否有 UI，您都必须提供一个简单的服务/外观类型的 api，它可以编排各种 Web 服务。所以API测试是一个很好的方法。您仍然希望独立测试每个 WS。
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
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.