Kontekst testowanego systemu określa poziom pokrycia testowania w oparciu o strukturę, który należy osiągnąć. Im bardziej newralgiczny jest dany system, tym wyższy stopień pokrycia jest wymagany. W ogólności, osiągnięcie wyższego stopnia pokrycia wiąże się z koniecznością poświęcenia większej ilości czasu i zasobów.

Czasami wymagany poziom pokrycia jest określony przez odpowiednie standardy dotyczące danego typu oprogramowania. Na przykład, jeśli oprogramowanie ma być stosowane w awionice, musi być zgodne ze standardem DO-178B (w Europie: ED-12B). Standard ten określa następujące poziomy warunków awarii:

• A. Katastroficzny: awaria może spowodować brak działania podstawowych funkcji niezbędnych do bezpiecznego kontynuowania lotu lub lądowania.
• B. Niebezpieczny: awaria może mieć poważny, negatywny wpływ na bezpieczeństwo i funkcjonowanie systemu.
• C. Wysoki: awaria jest istotna, ale mniej poważna niż w przypadku poziomu A lub B.
• D. Niski: awaria jest zauważalna, ale ma mniejszy wpływ niż w przypadku poziomu C.
• E. Bez konsekwencji: awaria nie ma wpływu na bezpieczeństwo.

Jeśli system ma kategorię A, musi zostać przetestowany z pokryciem ZPWD. Jeśli został sklasyfikowany na poziomie B, należy uzyskać w testach pokrycie na poziomie decyzji, a uzyskanie pokrycia ZPWD jest opcjonalne. Dla poziomu C wymagane jest co najmniej pokrycie instrukcji kodu.

Podobnie, norma IEC-61508 jest międzynarodowym standardem dotyczącym bezpieczeństwa funkcjonalnego programowalnych elektronicznych systemów związanych z bezpieczeństwem. Standard został przyjęty w wielu dziedzinach, m.in. w przemyśle motoryzacyjnym i kolejnictwie, w procesach produkcyjnych, elektrowniach jądrowych i w przemyśle maszynowym. Krytyczność definiuje się przy użyciu skali poziomów nienaruszalności bezpieczeństwa (ang. Safety Integrity Level; SIL), przy czym 1 oznacza najniższą, a 4 najwyższy jego poziom. Zalecane są następujące poziomy pokrycia:

• 1. Zalecane pokrycie instrukcji kodu i gałęzi.
• 2. Zdecydowanie zalecane pokrycie instrukcji kodu oraz zalecane pokrycie gałęzi.
• 3. Zdecydowanie zalecane pokrycie instrukcji kodu i gałęzi.
• 4. Zdecydowanie zalecane pokrycie ZPWD.

W nowoczesnych środowiskach rzadko się zdarza, by całe przetwarzanie odbywało się w obrębie jednego systemu. Należy przetestować interfejsy API zawsze wtedy, gdy część przetwarzania ma być realizowana zdalnie. Zakres działań dotyczących testowania API powinien zależeć od tego, jak newralgiczny jest dany system.

Jak zwykle, techniczny analityk testowy, który chce wybrać metody używane w testach, musi wziąć pod uwagę kontekst testowanego systemu.