WAŻNE (Kluczowe wymaganie): Głównym celem jest stworzenie stabilnego mechanizmu przeprowadzania płatności w systemie Business Wave (lub podobnym), który imituje działania rzeczywistego użytkownika na fizycznym urządzeniu z Androidem. Użycie automatyzacji webowej (Selenium/Playwright) nie jest brane pod uwagę z powodu rygorystycznych kontroli Device ID i blokad przeglądarek. Rozwiązanie powinno działać na zasadzie „telefon-robot”, który przyjmuje polecenia przez API, samodzielnie odczytuje OTP z przychodzących SMS-ów i wykonuje kliknięcia w interfejsie aplikacji mobilnej lub mobilnej wersji strony.
1. Pełny opis zadania
Konieczne jest wdrożenie warstwy programowej, która przekształci smartfon z Androidem w wykonawczy węzeł bramki płatniczej. System powinien otrzymywać przez API dane (komu i ile przelać), sprawdzać stan autoryzacji, w razie potrzeby przeprowadzać logowanie (w tym wprowadzenie OTP) i realizować transakcję do potwierdzenia.
2. Główne etapy scenariusza (Workflow)
Odbiór polecenia: Serwer otrzymuje żądanie POST z parametrami {phone_number, amount, wallet_address}.
Sprawdzenie sesji: Skrypt sprawdza, czy aplikacja jest otwarta i czy użytkownik jest zalogowany. Jeśli użytkownik się wylogował — inicjuje logowanie.
Obsługa 2FA (OTP):
Skrypt wprowadza numer telefonu i hasło.
Oczekuje na przyjście SMS-a na tym samym urządzeniu.
Automatycznie wyodrębnia kod z tekstu SMS-a i wprowadza go w polu potwierdzenia.
Wykonanie płatności: Nawigacja po punktach menu, wprowadzenie kwoty i adresu partnera, naciśnięcie przycisku „Wyślij”.
Potwierdzenie: Odczytanie statusu transakcji z ekranu (sukces/błąd) i wysłanie wyniku z powrotem na główny serwer.
3. Wymagania technologiczne (opcje do wyboru dla wykonawcy)
Oczekujemy użycia jednego z następujących podejść:
Opcja A (Preferowana): Zestawienie Tasker + AutoInput + Join/AutoRemote. To zapewni szybki rozwój i natywną obsługę SMS-ów oraz interfejsu bez uprawnień Root.
Opcja B: Automatyzacja przez ADB (Android Debug Bridge) i skrypty Pythona na serwerze, które zarządzają podłączonym telefonem.
Opcja C: Profesjonalny framework Appium, jeśli wykonawca udowodni jego stabilność dla tego zadania.
4. Wymagania dotyczące API
Wykonawca musi zapewnić prosty lokalny lub chmurowy punkt końcowy do:
5. Bezpieczeństwo i odporność na awarie
Obsługa błędów: Jeśli SMS nie przyjdzie w ciągu 60 sekund lub aplikacja zawiesi się, system powinien zwrócić błąd i spróbować ponownie uruchomić proces.
Logowanie: Zachowanie historii działań i zrzutów ekranu błędów.
Prywatność: Imitacja „ludzkich” opóźnień między kliknięciami a wprowadzaniem tekstu.
6. Kryteria akceptacji
System pomyślnie przeprowadza 10 z 10 testowych płatności z rzędu.
Automatyczne logowanie działa bez ręcznej interwencji.
OTP poprawnie wyodrębniane z SMS-a w 100% przypadków.
Wideo: załączone
Czekam:
1) czy pracowałeś z Tasker lub Appium w zadaniach niezwiązanych z prostym testowaniem.
2) terminy
3) kwoty
