MollieWagoner2: Die Seite wurde neu angelegt: „Začněte malou sadou testů, které pokrývají nejčastější cesty uživatelů. Nesnažte se automatizovat všechno najednou. Testovací prostředí udržujte oddělené od produkčního a data pro testy připravujte skriptem, ne ručně. Nestabilní testy, které jednou projdou a podruhé ne, jsou horší než žádné – lidé jim přestanou věřit a začnou je ignorovat. Pokud test opakovaně selhává bez skutečné chyby v aplikaci, opravte ho…“

2026-10-01T18:17:36Z

Die Seite wurde neu angelegt: „Začněte malou sadou testů, které pokrývají nejčastější cesty uživatelů. Nesnažte se automatizovat všechno najednou. Testovací prostředí udržujte oddělené od produkčního a data pro testy připravujte skriptem, ne ručně. Nestabilní testy, které jednou projdou a podruhé ne, jsou horší než žádné – lidé jim přestanou věřit a začnou je ignorovat. Pokud test opakovaně selhává bez skutečné chyby v aplikaci, opravte ho…“

Neue Seite

Začněte malou sadou testů, které pokrývají nejčastější cesty uživatelů. Nesnažte se automatizovat všechno najednou. Testovací prostředí udržujte oddělené od produkčního a data pro testy připravujte skriptem, ne ručně. Nestabilní testy, které jednou projdou a podruhé ne, jsou horší než žádné – lidé jim přestanou věřit a začnou je ignorovat. Pokud test opakovaně selhává bez skutečné chyby v aplikaci, opravte ho nebo smažte. REST staví na jasných zdrojích a HTTP sémantice. Každý endpoint má svou odpověď, cache se řeší na úrovni URL a v prohlížeči nebo na CDN tomu rozumí i člověk, který projekt nezná. Typická chyba je rozbití zdrojů na příliš jemné endpointy, které klient musí skládat ručně. Druhá častá chyba je naopak příliš tlustý endpoint, který vrací polovinu databáze a klient z něj použije dvě položky. Pomáhá držet se pravidla, že endpoint odpovídá jednomu zdroji a jedna odpověď odpovídá jednomu kontextu obrazovky. U GraphQL se také mění práce s cache. HTTP cache na úrovni URL zmizí, protože vše jde na jeden endpoint přes POST. Řešením je persistované dotazy, cache na úrovni resolverů nebo dedikovaná vrstva. Pokud tým nemá kapacitu na monitoring a optimalizaci dotazů, bývá REST levnější na provoz i na údržbu. Naopak pokud klienti neustále žádají nové kombinace polí, REST se zvrhne v desítky účelových endpointů a GraphQL je čistší. Hranice, které se v praxi osvědči Základní cyklus má tři kroky a plete se pořád dokola. git status ukáže, co se změnilo. git add soubor přesune změnu do přípravy (staging). git commit -m "popis" ji uloží jako bod v historii. Kdo vynechá git add, diví se, že commit je prázdný. Kdo naopak přidá omylem celý adresář přes git add ., dostane do historie i to, co tam nechce. Zpráva commitu nemá být „oprava" nebo „změny" — za měsíc nebudeš vědět, co se opravovalo. Piš krátce, ale konkrétně: „oprava dělení nulou v exportu". Ruční testování je nenahraditelné tam, kde rozhoduje lidský úsudek. Patří sem ověření plynulosti přechodů, chování aplikace při příchozím hovoru, práce s oprávněními, přepnutí do režimu na pozadí nebo rotace displeje. Testovací scénáře pište jako krátké kroky s jasným očekávaným výsledkem. Typická chyba: tester zapíše, že „aplikace se zasekla", ale už neuvede, na kterém zařízení, s jakou verzí systému a po jaké konkrétní akci. Bez těchto údajů vývojář chybu neopraví. Poslední vrstvou je omezení práv databázového účtu. Aplikační účet nemá mít právo měnit strukturu, vypínat triggery ani přistupovat k tabulkám, které nepotřebuje. Když se injektáž přesto prosadí, škoda zůstane omezená. Kontrolu dělejte pravidelně, ne jednou při nasazení. Práva se v čase rozšiřují a zapomenuté granty zůstávají. Bezpečnost není jednorázové nastavení, ale rutina, která přežije i vaše další vydání. Kdy má smysl sáhnout po automatizaci Automatizace se vyplatí u opakujících se regresních testů: přihlášení, vyplnění formuláře, dokončení nákupu, načtení seznamu položek. Nástroje pro automatizaci mobilních aplikací obvykle pracují dvěma způsoby. První přistupuje k aplikaci jako k černé skříňce a hledá prvky podle textu, identifikátoru nebo pozice na obrazovce. Druhý vkládá do kódu testovací značky, což je spolehlivější, ale vyžaduje spolupráci s vývojáři. Pozor na selektory vázané na pořadí prvků – po jakékoli úpravě rozvržení se celá sada testů rozpadne. Podmínky zjednodušuj pomocí návratů. Místo hlubokého if s dlouhým else použij takzvaný early return: ošetři krajní případ na začátku a zbytek nech bez odsazení. Nepiš if (podminka) return true else return false , stačí return podminka. Vyhýbej se magickým číslům a řetězcům — dej jim název v konstantě. A hlavně: názvy drž konzistentní. Když jednou používáš uzivatel, nepřepínej střídavě na user a u. Pro efektivní pokrytí je potřeba kombinovat oba přístupy. Automatizace odvede rutinu při každé změně kódu, ruční testování odhalí to, co skript nevidí – neobvyklé chování, nesrozumitelné hlášky, problémy s čitelností na malém displeji. Výsledky měřte podle počtu odhalených vad, ne podle počtu spuštěných testů. Ať už zvolíte kteroukoli cestu, bez reálných zařízení a skutečných uživatelů zůstane část chyb skrytá až do vydání. Testování mobilních aplikací se výrazně liší od testování webových stránek. Na jedné platformě běží aplikace na stovkách zařízení s různými verzemi operačního systému, velikostmi displeje a výkonem. Kdo začne testovat až po dokončení vývoje, obvykle skončí s hromadou chyb, které se špatně reprodukují. Rozdíl mezi ručním a automatizovaným testováním přitom není v tom, které je lepší, ale v tom, co má smysl řešit jak.

Ruční testování versus automatizace v mobilních aplikacích - Versionsgeschichte