Standardy dokumentacji planu testów API

Question

Mam pytanie do doświadczonych testerów API, szczególnie tych, którzy pracują w dużych organizacjach. Otrzymałem zadanie zidentyfikowania wszelkich standardów branżowych w zakresie dokumentacji planów testów API. Jak dotąd odkryłem, że standard IEEE 829 i ISO 29119 można wykorzystać do ogólnego informowania o testowaniu oprogramowania.

Czy są jednak jakieś najlepsze praktyki, wytyczne lub standardy dotyczące dokumentowania planów testów API, które możesz polecić na podstawie własnego doświadczenia?

Answer 1

Moje osobiste podejście:

Na wysokim poziomie

Przetestuj punkty końcowe interfejsu API, kody stanu i dane za pomocą testów dymu, radości i smutku

Na poziomie szczegółowym należy zadać następujące pytania.
Odpowiedzi podpowiedzą, co i jak przetestować.

• Jaka dokumentacja istnieje?
• Jaką funkcjonalność zapewnia?
• Czy obsługuje współbieżność?
• Jakie są punkty końcowe interfejsu API?
• Czy interfejs API jest wewnętrzny czy zewnętrzny?
• Które punkty końcowe są idempotentne?
• Czy punkty końcowe są bezstanowe czy stanowe?
• Czy jakieś przepływy pracy * 1 różnią się w zależności od klienta?
• Czy są wymagania dotyczące wydajności?
• Czy punkty końcowe API tworzą przepływ pracy?
• Jakich walidacji oczekuje się w przypadku danych?
• Jaki system lub biblioteka stoi za API?
• Czy musimy kpić z usług zależnych?
• Czy ogranicza ruch, czyli ograniczanie szybkości?
• Jakie (jeśli w ogóle) podejście do wersjonowania jest używane?
• Czy interfejs API obsługuje wiele języków?
• Jeśli już korzystasz z SOAPui, w jaki sposób jest on zintegrowany?
• Czy interfejs API jest ograniczony do kraju lub regionu?
• Czy udostępnia kody pośredniczące klientów w określonych językach?
• Jakie kody stanu są oczekiwane dla danych punktów końcowych?
• Jaki format i struktura domeny istnieją dla danych?
• Czy interfejs API używa HATEOS * 2 do samodzielnej dokumentacji?
• Jakiego rodzaju walidację / testowanie danych można przeprowadzić?
• Jakie API jest obsługiwane przez używaną przeze mnie platformę testową?
• Jakie czynności są wykonywane, np. GET, PUT, POST itp.?
• Czy musimy przygotowywać zależne dane testowe lub usługi?
• Jakie podejścia inne niż API będą potrzebne do weryfikacji danych?
• Czy istnieją definicje API, np. WADL, WSDL, Thrift?
• Jakie podejścia inne niż API będą potrzebne do przygotowania danych?
• Jaki (jeśli w ogóle) mechanizm autoryzacji („jaki”) zostanie zastosowany?
• Jaki (jeśli w ogóle) mechanizm uwierzytelniania („kto”) zostanie zastosowany?
• Kto będzie z niego korzystał, zewnętrzni programiści czy inny moduł wewnętrzny?
• Jakie formaty: SOAP, REST, GraphQL, Thrift, ProtoBuffer, Other?

* 1 Przepływy pracy często wymagają wielu wywołań API i mogą mieć między nimi zależności

* 2 HATEOS - Hypertext As The Engine Of Application State, który umożliwia samodzielne wykrywanie interfejsu API