Opis projektu
PrzetłumaczoneProwadzimy sklep internetowy i spodziewamy się dużej sezonowej wyprzedaży za kilka tygodni. Ruch wzrośnie gwałtownie w ciągu kilku minut, gdy kampania się rozpocznie, a my musimy wiedzieć z wyprzedzeniem, czy strona wytrzyma szczyt, czy zawiedzie przy realizacji zamówienia. Szukamy inżyniera QA, który zaprojektuje i przeprowadzi realistyczne testy obciążeniowe na naszej kopii stagingowej i przygotuje jasny raport, na podstawie którego możemy działać.
Praca powinna modelować rzeczywiste zachowanie kupujących, a nie ślepe trafienia: przeglądanie katalogu, wyszukiwanie, otwieranie stron produktów, dodawanie przedmiotów do koszyka i finalizowanie zamówienia, wymieszane w realistycznych proporcjach. Chcemy testów na kilku poziomach współbieżności do uzgodnionego szczytu, krótkiego scenariusza szczytowego, który symuluje pierwsze minuty wyprzedaży, oraz powtarzalnych skryptów, które możemy uruchomić ponownie po poprawkach. Raport musi wskazywać wąskie gardła — wolne zapytania, cienkie buforowanie, nasycony pulę lub słaby serwer — z liczbami, a nie przypuszczeniami, i klasyfikować je według wpływu.
Dostęp do środowiska stagingowego i logów zostanie zapewniony. Wynikiem są skrypty testowe, surowe wyniki oraz dokument z priorytetowymi ustaleniami i rekomendacjami. Proszę opisać swoje narzędzia i jak utrzymujesz testy blisko rzeczywistego ruchu.
W zakresie:
— realistyczne scenariusze użytkowników i realistyczna mieszanka;
— profile obciążenia ramp-up i spike;
— raport o wąskich gardłach sklasyfikowany według wpływu z wyraźnymi liczbami.
Praca powinna modelować rzeczywiste zachowanie kupujących, a nie ślepe trafienia: przeglądanie katalogu, wyszukiwanie, otwieranie stron produktów, dodawanie przedmiotów do koszyka i finalizowanie zamówienia, wymieszane w realistycznych proporcjach. Chcemy testów na kilku poziomach współbieżności do uzgodnionego szczytu, krótkiego scenariusza szczytowego, który symuluje pierwsze minuty wyprzedaży, oraz powtarzalnych skryptów, które możemy uruchomić ponownie po poprawkach. Raport musi wskazywać wąskie gardła — wolne zapytania, cienkie buforowanie, nasycony pulę lub słaby serwer — z liczbami, a nie przypuszczeniami, i klasyfikować je według wpływu.
Dostęp do środowiska stagingowego i logów zostanie zapewniony. Wynikiem są skrypty testowe, surowe wyniki oraz dokument z priorytetowymi ustaleniami i rekomendacjami. Proszę opisać swoje narzędzia i jak utrzymujesz testy blisko rzeczywistego ruchu.
W zakresie:
— realistyczne scenariusze użytkowników i realistyczna mieszanka;
— profile obciążenia ramp-up i spike;
— raport o wąskich gardłach sklasyfikowany według wpływu z wyraźnymi liczbami.
Rozwój oprogramowania Gotówka, Przelew bankowy
