Jestem studentem pracującym nad moim BE (CS), a moje pytanie jest następujące:

1. Czy potrzebne są testy w dziedzinie oprogramowania?
2. Jeśli tworzymy oprogramowanie z wielką starannością, to dlaczego powinniśmy testować?
3. Czy po przetestowaniu możemy być pewni , że osiągnęliśmy ten cel (produkt / oprogramowanie działa zgodnie z przeznaczeniem), ponieważ przeprowadziliśmy dla niego testy ? Czy to możliwe?

Moje pytanie: Czy potrzebne jest testowanie oprogramowania ?

Tak. Ponieważ bez względu na to, jak dobry jesteś, nie możesz myśleć o wszystkim.

• Zostaniesz również poproszony, aby twoje oprogramowanie robiło rzeczy, których nigdy nie zamierzałeś.
• Nigdy też nie będziesz mieć tak jasnych wymagań, że będziesz w stanie wymyślić każdą możliwość, aby upewnić się, że kod się nie zepsuje.
• Będziesz także pracował z oprogramowaniem i aplikacjami innych ludzi, które nie zawsze będą działać zgodnie z przeznaczeniem, ale założysz, że działa lub powinno prowadzić do wad w twoim „idealnym” przypadku.

tak

Z tego samego powodu, dla którego szef kuchni smakuje swoje jedzenie podczas gotowania.

Pracuję z kimś, kto tak myśli, uważa, że ​​ponieważ jest starszym programistą, nie musi już testować swojego kodu. Firma nie rozumie, jak niebezpieczne jest to podejście, i zamiast go zwolnić, zatrudniła więcej programistów, aby zająć się zaległościami. Nie wiedząc, skąd bierze się ten zaległości, myślą, że to część tego, na czym polega programowanie. Zasadniczo mamy 3 programistów pracujących w tym trybie i zespół 20, którzy nie robią nic poza testowaniem i naprawianiem błędów, które tworzą ci trzej.

BRAK OF PROPER BADANIA ZABIJA .

Tak więc, chyba że jesteś BOGIEM lub jakąkolwiek wersją jakiejś doskonałej wszechwiedzącej istoty (teraz chciałbym to zobaczyć) lub chyba, że ​​chcesz aktywnie zostać zwolnionym bardzo szybko, zdecydowanie sugeruję, abyś zaczął testować.

Oprogramowanie jest pisane przez ludzi.

Ludzie są niedoskonali i popełniają błędy.

W miarę wzrostu złożoności przedsięwzięcia rośnie potencjalna liczba (i wpływ) błędów, niedopatrzeń lub rzeczy zapomnianych - zwykle wykładniczo.

Tak, potrzebne są testy. Daje równowagę i perspektywę.

Czy udasz się na lot z systemem operacyjnym, o którym wiesz, że używałeś go na swoim laptopie i dał ci ekran śmierci w ulubionym kolorze? Pomyśl o tym.

Żaden program kodujący nie jest idealny. Daleko, daleko, naprawdę daleko. Potrzebujesz testów, a testerzy często przedstawiają perspektywę (znaną również jako przypadki użycia), której brakowało programistom.

Wyszukaj najsłynniejsze błędy oprogramowania w Google, aby dowiedzieć się, co mam na myśli.

Na poziomie uczelni zapoznaj się z programowaniem opartym na testach, testowaniem jednostkowym i zwinnymi praktykami, aby dowiedzieć się, gdzie jest teraz.

Testowanie jest absolutną koniecznością dla każdej nietrywialnej (pod względem wielkości lub funkcji) aplikacji, która ma być faktycznie używana. Nie znajdziesz żadnego programisty, który dba o jego / jej rzemiosło (o czym świadczy ich wizyta na tej stronie), który odpowiedziałby, że testowanie nie jest konieczne.

Oprócz tego, co zostało już opublikowane, posiadanie pełnego zestawu zautomatyzowanych testów jednostkowych w dowolnej aplikacji sprawi, że będziesz bardziej pewny przyszłych zmian kodu. Ta większa pewność (ponieważ testy jednostkowe zapewniają WIELKĄ siatkę bezpieczeństwa) spowoduje szybsze zmiany kodu w istniejących aplikacjach (z powodu mniejszego śledzenia wstecznego / podwójnego sprawdzania)

Errare humanum est

Nie ma czegoś takiego jak oprogramowanie wolne od błędów.

Najbardziej wykwalifikowany programista pisze kod z błędami. Nawet gdyby istniał idealny programista, nadal występowałyby błędy z powodu rozbieżności między:

• potrzeby użytkownika i dokumenty specyfikacji
• specyfikacja i projekt
• oczekiwane i rzeczywiste środowiska sprzętowe i programowe
• wczoraj i dziś prawda: wszystko wymienione powyżej podlega zmianom, które nie są doskonale zgłaszane na każdym etapie procesu rozwoju.

Idealny programista to tylko część całości. A idealni programiści nie istnieją.

Większość prawdziwych programów:

a) zawierają setki wierszy kodu lub więcej rozproszonych po wielu plikach;
b) zostały opracowane przez więcej niż jednego programistę;
c) używane w środowiskach innych niż środowisko programisty

Zatem jeśli nie sprawdzisz, jak program działa w rzeczywistej sytuacji, szansa, że ​​w ogóle nie zadziała, byłaby bliska 100%.

Oprócz wszystkich innych świetnych odpowiedzi, nawet jeśli wiesz, że jest doskonały i wolny od błędów, pomyśl o innych programistach, którzy będą mieli do czynienia z twoim kodem w przyszłości. Nie będą tego wiedzieć tak jak ty i będą chcieli polegać na twoich testach, aby upewnić się, że niczego nie zepsuły po dokonaniu zmiany. Dotyczy to oczywiście również ciebie, gdy nie widziałeś swojego kodu od roku!

TAK.

Oto kolejna nieco bardziej subtelna perspektywa, która nie została jeszcze całkowicie omówiona:

Nigdy nie lekceważ potrzeby „niezależnej weryfikacji” . To ten sam powód, dla którego dobrze jest mieć kilku niezależnych redaktorów przeglądających twoją pracę przed przesłaniem dużego tekstu do publikacji. Bez względu na to, jak dobry jesteś pisarz, od czasu do czasu przekręcisz mózgiem i napiszesz coś w stylu „zamiast” zamiast „to” lub coś takiego. Jeśli ponownie przeczytasz to sam, nawet dość ostrożnie, zwykle będziesz za nim tęsknić, ponieważ twój mózg automatycznie akceptuje przebieg procesu myślowego jako prawidłowy i przeskakuje nad błędem. Dla świeżego zestawu oczu ten błąd jest zwykle dość rażący.

To samo dzieje się w programowaniu: dość łatwo jest wejść w przepływ, w którym albo twój kod, albo podstawowe „testowanie programistyczne” własnego kodu - wygląda poprawnie, ponieważ testujesz go i używasz w określony sposób. Ale kiedy pojawia się kolejna para rąk i klika coś w nieco inny sposób lub w innej kolejności, wszystko się psuje.

Teraz, oczywiście, mogłaby teoretycznie zejść trasę formalnie weryfikacji każdą możliwość i logiczny oddział w kodzie siebie, ale dla nietrywialne oprogramowania będzie to znacznie bardziej kosztowne i czasochłonne niż o kogoś innego Bang Na kod dla ciebie. I prawdopodobnie nadal będziesz tęsknić za rzeczami, o których nigdy nie pomyślałeś.

Czego jeszcze nie zmieniono: nawet jeśli Twój kod jest doskonały, nadal nie jesteś bezpieczny. Kompilatory zawierają błędy, które mogą powodować, że nawet idealny kod zachowuje się niepoprawnie po kompilacji. Systemy operacyjne zawierają błędy, które mogą powodować, że doskonały plik binarny zachowuje się nieprawidłowo po uruchomieniu. Sprzęt zawiera błędy, które mogą powodować problemy.

Dlatego też testowanie na jednej maszynie nie wystarcza w przypadku produktów komercyjnych. Muszą zostać przetestowane na możliwie wielu kombinacjach sprzętu i oprogramowania, które mogą napotkać na wolności, na ile to możliwe.

Lider zespołu piszącego oprogramowanie promu kosmicznego poleciał przed każdym uruchomieniem, aby zaznaczyć, że oprogramowanie nie zaszkodzi promowi.

Jak myślisz, co dałoby mu taką pewność?

Cały czas testujesz kod, po prostu go kompilując i używając. W niektórych IDE podczas pisania otrzymujesz kontrolę poczytalności. O ile nie uruchomisz kodu, testujesz.

To, ile testujesz, naprawdę jest źródłem tego rodzaju pytań, a odpowiedź na to pytanie sprowadza się do ryzyka. Testujesz tyle, ile ma sens testowanie z punktu widzenia zarządzania ryzykiem. Testowanie wszystkiego lub niczego jest zwykle niemożliwe. Testowanie prawie nic nie jest zwykle złym posunięciem. Wszystko pomiędzy jest uczciwą grą, w zależności od poziomu ryzyka i ekspozycji twojego produktu.

Pachnie jak zadanie domowe.

Czy potrzebne są testy w dziedzinie oprogramowania?

Tak. Absolutnie. Na wszystkich poziomach. Poza kilkoma wyspecjalizowanymi domenami nie jesteśmy jeszcze na etapie, w którym możemy matematycznie udowodnić, że nasz kod jest poprawny względem określonych błędów (przynajmniej w rozsądnym terminie), więc musimy rzucić w niego kamieniami, aby sprawdzić, czy i gdzie się psuje.

Jeśli tworzymy oprogramowanie z wielką starannością, to dlaczego powinniśmy testować?

Testowanie nie polega tylko na wykrywaniu błędów kodowania. Chodzi również o upewnienie się, że wszystkie wymagania zostały spełnione, a cały system działa zgodnie z oczekiwaniami. Jeśli mam wymaganie, aby nieudana transakcja zwróciła określony kod błędu, muszę napisać test, aby sprawdzić, czy funkcjonalność istnieje i czy działa poprawnie.

A wszystko to zakłada, że ​​specyfikacja i projekt są kompletne, poprawne i wewnętrznie spójne, co często nie jest prawdą. Nawet jeśli spełniasz specyfikację do litery i postępujesz zgodnie z projektem aż do ostatniej kropki i średnika, jeśli specyfikacja lub projekt jest zły, wtedy będą problemy w czasie integracji. Często testy systemu lub integracji odbywają się, gdy dowiadujesz się, że sama specyfikacja jest błędna i wymaga aktualizacji (patrz historia wojny poniżej).

Czy po przetestowaniu możemy być pewni, że osiągnęliśmy ten cel (produkt / oprogramowanie działa zgodnie z przeznaczeniem), ponieważ przeprowadziliśmy dla niego testy? Czy to możliwe?

Nie, nie do 100%. Nie możemy przetestować każdej możliwej kombinacji danych wejściowych lub ścieżek wykonania w żadnym innym, niż najprostszym kodzie. Nie możemy uwzględnić wszystkich czynników środowiskowych. Nie możemy sobie wyobrazić wszystkich możliwych trybów awarii.

Możemy przetestować do tego stopnia, że ​​jesteśmy dość pewni, że nie ma żadnych dużych problemów. Ponownie dlatego musimy testować na wszystkich poziomach. Napisz zestaw testów, aby upewnić się, że kod poprawnie obsługuje warunki brzegowe (złe dane wejściowe, nieoczekiwane wyniki, wyjątki itp.). Test jednostkowy w celu sprawdzenia, czy kod spełnia jego wymagania. Test systemu w celu weryfikacji przetwarzania od końca do końca. Test integracji w celu sprawdzenia, czy wszystkie komponenty poprawnie się ze sobą komunikują. Przeprowadź testy użyteczności, aby upewnić się, że całość działa w taki sposób, że klienci nie chcą cię zastrzelić.

Scenariusz w świecie rzeczywistym - pracowałem nad systemem zaplecza, który od czasu do czasu wysyłał aktualizacje usługi GUI do wyświetlenia w tabeli na ekranie. Podczas projektu dodano wymaganie dodania filtrowania do wyświetlacza (np. Operator mógł wybrać opcję wyświetlania podzestawu wpisów w tabeli). Błąd projektowy nr 1 - filtrowanie powinno zostać wykonane przez usługę GUI (mam to dziwne, antykwarskie przekonanie, że funkcje zarządzania wyświetlaniem powinny być odpowiedzialne za oprogramowanie do zarządzania wyświetlaniem), ale z powodu polityki i mojej niezdolności do rozpoznania problemów, zanim one staną się problemy , wymóg ten został nałożony na usługę zaplecza. No dobra, nie ma problemu, mogę to zrobić. Filtruj zmiany stanu, otrzymuję wiadomość, a następnie wysyłam wiadomość tworzenia lub usuwania wiadomościkażdy wiersz w tabeli , ponieważ tak działa interfejs (błąd projektowy nr 2 - nie ma możliwości wysłania aktualizacji do wielu wierszy w jednym komunikacie; nie możemy nawet wysłać pojedynczej wiadomości „wyczyść” lub „usuń” do wyczyszczenia cały stół).

Cóż, wszystko działa dobrze podczas programowania; testy jednostkowe, systemowe i integracyjne pokazują, że przesyłam odpowiednie informacje i poprawnie obsługuję zmiany filtrów. Następnie przechodzimy do testów użyteczności, a całość mocno spada , ponieważ ilość danych była przytłaczająca. Opóźnienie sieci między moją usługą zaplecza a GUI było rzędu od 0,15 do 0,25 sekundy. Nieźle, jeśli musisz wysyłać aktualizacje tylko dla kilkunastu wierszy. Śmiertelny, gdy musisz wysłać aktualizacje za kilkaset. Zaczęliśmy otrzymywać raporty o błędach, że GUI zamarzało po zmianie stanu filtra; no nie, działo się tak, że trwało to kilka minut zaktualizować wyświetlacz, ponieważ protokół wiadomości z aktualizacją jeden wiersz na raz nie był w stanie poradzić sobie ze scenariuszem w świecie rzeczywistym.

Zauważ, że wszystko to mogło i powinno być oczekiwane przez wszystkich, od głównego wykonawcy aż do małego starego mnie, gdybyśmy wcześniej zadali sobie trud nawet najbardziej podstawowej analizy. Jedyną obroną, którą zaoferuję, jest to, że zamykamy drugi rok sześciomiesięcznego projektu, który zostanie zniszczony niemal natychmiast po dostawie, i wszyscy desperacko czekamy na jego powrót.

Co prowadzi nas do ostatniego powodu testowania - CYA. Realne projekty zawodzą z różnych powodów, wiele z nich ma charakter polityczny i nie wszyscy działają w dobrej wierze, gdy coś pójdzie nie tak. Wskazujcie palcami, wysuwajcie oskarżenia i pod koniec dnia musicie być w stanie wskazać zapis pokazujący, że przynajmniej wasze rzeczy działały tak, jak powinny.

Testowanie będzie zawsze wykonywane i zawsze będą znajdować się błędy. Wystarczy, że albo zespół przeprowadzi testy wewnętrznie, albo użytkownik końcowy będzie testerem. Koszt błędu znalezionego przez użytkownika końcowego jest znacznie wyższy niż w przypadku wykrycia go podczas testowania.

Sugerowałbym podjęcie dobrego kursu informatyki odpornej na awarie. Staranne projektowanie oprogramowania jest tylko jednym z filarów osiągnięcia niezawodności oprogramowania. Pozostałe dwa filary to wystarczające testy i zbędny projekt. Podstawowym celem jest uwzględnienie wykładniczej liczby nieznanych warunków awarii i nadanie priorytetu radzeniu sobie z niektórymi ze znanych:

1.) wyeliminować jak najwięcej możliwych awarii poprzez projektowanie i prawidłowe wdrożenie 2.) wyeliminować nieprzewidziane błędy z fazy projektowania i niewłaściwej implementacji poprzez różne formy testowania (jednostka, integracja, losowe) 3.) radzić sobie z wszelkimi pozostałymi awariami poprzez redundancję ( temporal => przelicz, spróbuj ponownie lub spacja => zachowaj kopie, parzystość)

Jeśli wyeliminujesz fazę testowania, pozostawiasz sobie tylko fazy projektowania i redundancji w celu usunięcia awarii.

Ponadto, z punktu widzenia produktu, twoi interesariusze (np. Kierownictwo, użytkownicy, inwestorzy) będą chcieli pewnego rodzaju zapewnienia, że ​​twój produkt spełnia określone specyfikacje jakości i bezpieczeństwa, kryteria itp. Poza tym, czy nie testowałeś oprogramowania, które skonstruowałeś tylko po to, by mieć „kontrolę zdrowia psychicznego”? Wszystkie te powody sprawiają, że testowanie oprogramowania jest bardziej atrakcyjne.

Wszystkie programy mają błędy, przynajmniej na początek.

Było kilka badań, które zbiegają się w około 1 błędzie na każde pięć wierszy nieprzetestowanego kodu.

Lekcja historii:

W latach sześćdziesiątych IBM potrzebował programu „NOP”, aby mogli wykonywać pewne funkcje w JCL bez uruchamiania programu. Deweloperzy wymyślili jednowierszowy program asemblerowy, w którym cały kod był zawarty w nazwie „IEFBR14”, a rzeczywisty kod to:

       BR 14 * brach to return address in register 14

Podczas długiego okresu użytkowania ten program jednoliniowy był przedmiotem 2 zgłoszeń błędów i pięciu poprawek.

Refaktoryzacja kodu jest naprawdę szybsza, gdy masz testy jednostkowe. Test jednostkowy pokazuje również proste użycie konkretnej funkcji, więc masz małe „howto”, które może być naprawdę przydatne w dużych projektach, w których programiści nie znają dokładnie całego kodu.

Kiedy rozwijasz się z TDD (programowanie testowe), nie masz niepotrzebnych programów pobierających / ustawiających itp. Po prostu tworzysz to, czego potrzebujesz.

Aby odpowiedzieć # 3 na twoje pytanie:

Będąc programistą i testerem oprogramowania, tak, możesz być pewien, że spełniasz wymagania oprogramowania podczas testowania.

{założenie kapelusza kontroli jakości}

W jaki sposób? Można to zrobić, śledząc testy od kodu testowego do kryteriów akceptacji, kryteriów akceptacji do funkcji i funkcji do wymagań. Jeśli prześledzisz każdy pojedynczy test w górę łańcucha projektowego i zostaną one odwzorowane na jedno lub więcej wymagań, możesz być pewien, że twoje testy są używane w celu upewnienia się, że kod spełnia jego wymagania (chociaż przywołuje to pojęcie odpowiedniego pokrycia testowego, które jest inny temat). Jeśli nie możesz prześledzić testu w łańcuchu projektowym, prawdopodobnie testujesz rzeczy, które nie są wymagane, a to jest strata czasu. Kryteria akceptacji mogą również obejmować sprawdzanie niepożądanych zachowań - możesz je również przetestować, co zbliży cię o krok do wydania wysokiej jakości.

{Hat QA off}

Żaden kod nigdy nie jest wolny od błędów, po prostu mniej kosztowny w czasie, gdy poświęca się więcej wysiłku na ocenę jego jakości podczas programowania.

Od 3 lat jestem testerem oprogramowania. Początkowo sam byłem sceptycznie nastawiony do konieczności testowania, ponieważ pomyślałem, że jeśli dział rozwoju i kierownictwo projektu wykonają swoją pracę, to nie powinny pojawić się błędy w oprogramowaniu.

Ale tak nie jest. ++++++++

Często zdarzają się błędy, niektóre z nich mają kluczowe znaczenie dla funkcjonowania projektu. Istnieją również testy różnych przeglądarek (co oznacza testowanie na różnych istniejących przeglądarkach, takich jak SAFARI, FIREFOX, CHROME i Internet Explorer) i pracowałem nad projektem, w którym proste przyciski interfejsu, takie jak TAK i NIE, w oknie ankiety, w których nie działa tylko we wszystkich przeglądarkach niektórzy z nich.

Pracowałem nad testowaniem stron internetowych i testowałem proste ZMIANY TEKSTU i pomyślałem sobie, że w żaden sposób na ziemi nie mogą istnieć wady tej prostej pracy, ale tak się nie dzieje.

Widziałem również, gdy nowi programiści dołączają do zespołu i otrzymują aktualizację do istniejącego złożonego formularza aplikacji internetowej z szeregiem linków / wywołań do stron zewnętrznych, błąd wystąpił z powodu braku komunikacji między starymi i nowymi programistami, z różnych powodów (brak czasu na edukację, brak woli edukacji i tak dalej).

TAK

Wyobraź sobie, że twoje oprogramowanie jest tylko funkcją logiczną ORAZ (b1, b2), gdzie b1 i b2 są tylko bitami. Do tego potrzebne są 4 przypadki testowe, aby upewnić się, że oprogramowanie jest wolne od błędów, jeśli otoczenie zapewnia dokładnie to, co zostało określone.

Teraz twój system składa się z wielu funkcji, których najprostsza jest znacznie bardziej skomplikowana niż ta funkcja logiczna. Jak upewnisz się, że nie zawiera błędów?

(ciąg dalszy nastąpi)