문서화되지 않은 웹 서비스를 테스트하는 방법?

Question

나는이 질문에 최근에 와서, 누군가가 테스터로서 나의 접근 방식을 도와 주길 바래.

기능이 변경되어 동일한 설명서가없는 웹 서비스가 있다고 가정합니다. 같은 것을 테스트하기위한 귀하의 접근 방법은 무엇입니까?

업데이트 : 데이터베이스 기능이 변경되고 설명서가없는 경우에도 동일한 대답이 유지됩니까?

Answer 1

설명서 없이는 테스트 할 수 없습니다. 어떤 결과가 기대되는지 어떻게 알 수 있습니까?

---

어쩌면 잘못된 장소에서 "문서"를 찾고있을 수도 있습니다. 누군가가 이러한 변화를 일으켰습니다. 그들은 데이터베이스와 서비스에 어떤 변화를 줄 것인지 알려주는 정보를 가지고있었습니다. 요구 사항 문서가있을 수도 있지만 설계 문서가있을 수도 있습니다.

변경 사항을 파악하여 변경된 사항을 파악하십시오. 이 정보를 사용하여 테스트 변경 방법을 결정하십시오.

Answer 2

일반적으로 웹 서비스는 제공 서비스와 발신자간에 일관된 계약을 제공합니다. 백엔드 구현이 변경 될 수 있지만 서비스 용 인터페이스는 일관되게 유지되도록 지정합니다.

서비스에서 사용할 수있는 기능을 확인하고 싶다면 사용 가능한 기능 및 메시지 유형을 설명하는 메타 데이터를 제공 할 수 있습니다. 일반적으로 다른 스키마가 있지만 웹 서비스 URL에 "? wsdl"을 추가하여 액세스 할 수 있습니다.

사용 가능한 기능에 대해 잘 알고 있으면 테스트 프레임 워크를 통해 호출하고 일반적인 테스트 프로세스에 따라 응답을 평가할 수 있습니다.

Answer 3

유용한 방법으로 서비스를 사용하는 경우 아마도 문서화되지 않았지만 일부 알려진 결과를 반환하는 호출이있을 것입니다. 이 경우 현재의 서비스에 대한 기대치를 검증하는 테스트를 작성합니다. 적어도 변경이 이루어지면 변경되는 비트가 무엇인지 알 수있는 가능성이 더 커집니다. 어떻게 블랙 박스 웹 서비스의 API를 발견하는

1) :

Answer 4

그것은 당신이 두 가지 질문 중 하나를 요청 수 있습니다 보인다.
이 경우 가장 좋은 소스는 웹 서비스의 소스 (문서의 존재 실패)이거나 기존 클라이언트 또는 서비스의? wsdl입니다.

2) 웹 서비스의 올 바르고 잘못된 답변을 찾는 방법.
이 경우 요구 사항이나 설명서 또는 올바른 클라이언트가 필요합니다. 아마도이 경우에 가장 많이 존재할 가능성이있는 것은 클라이언트입니다. 또는 웹 서비스가 외부에서 결과를 확인할 수있는 일부 기능을 구현할 수도 있습니다.