Wprowadzenie do testowania oprogramowania (Ammann & Offutt) wspomina na str. 32 5-poziomowy model dojrzałości testowej:

Poziom 0 Nie ma różnicy między testowaniem a debugowaniem.

Poziom 1 Celem testów jest wykazanie, że oprogramowanie działa.

Poziom 2 Celem testów jest wykazanie, że oprogramowanie nie działa.

Poziom 3 Celem testów nie jest udowodnienie niczego konkretnego, ale ograniczenie ryzyka korzystania z oprogramowania.

Poziom 4 Testowanie to dyscyplina mentalna, która pomaga wszystkim specjalistom IT opracowywać oprogramowanie wyższej jakości.

Chociaż nie wchodzą w szczegóły. Jakie są różnice między debugowaniem a testowaniem?

Testowanie ma na celu wykrycie defektów w kodzie lub pod innym kątem, aby udowodnić na odpowiednim poziomie (nigdy nie może być 100%), że program robi to, co powinien. Może być ręczny lub zautomatyzowany i ma wiele różnych rodzajów, takich jak testowanie jednostki, integracji, systemu / akceptacji, obciążenia, obciążenia, namaczania itp.

Debugowanie to proces znajdowania i usuwania określonego błędu z programu. Jest to zawsze ręczny, jednorazowy proces, ponieważ wszystkie błędy są różne.

Domyślam się, że autor oznacza, że ​​na poziomie 0 wykonywane są tylko testy ręczne, w sposób ad hoc, bez planu testów ani niczego innego, aby upewnić się, że tester faktycznie dokładnie przetestował testowaną funkcję i że testy mogą być niezawodnie powtórzone.

Debugowanie to ręczny proces krok po kroku, który jest zaangażowany, nieustrukturyzowany i zawodny. Testując poprzez debugowanie, tworzysz scenariusze, które nie są powtarzalne, a zatem bezużyteczne do testowania regresji. Wszystkie poziomy inne niż 0 (w twoim przykładzie) wykluczają debugowanie w moim widoku z tego właśnie powodu.

Debugowanie to próba naprawienia znanych i nieznanych problemów poprzez metodyczne przeglądanie kodu. Podczas debugowania zwykle nie skupiasz się na kodzie jako całości i prawie zawsze pracujesz w backendie, w rzeczywistym kodzie.

Testowanie jest próbą stworzenia problemu poprzez różne sposoby użycia kodu, który można następnie debugować. Prawie zawsze odbywa się to w przestrzeni użytkownika, w której kod jest uruchamiany tak, jak użytkownik końcowy uruchamiałby go i próbował go przerwać.

Mówiąc najprościej, mówi się, że „błąd” miał miejsce, gdy program podczas wykonywania nie zachowuje się tak, jak powinien. Oznacza to, że nie daje oczekiwanych wyników ani rezultatów. Każda próba znalezienia źródła tego błędu, znalezienia sposobów na poprawienie zachowania i wprowadzenia zmian w kodzie lub konfiguracji w celu rozwiązania problemu może być nazwana debugowaniem.

Testowanie polega na upewnieniu się, że program lub kod działa poprawnie i niezawodnie w różnych warunkach: „Testujesz” swój kod, wprowadzając dane wejściowe, standardowe poprawne dane wejściowe, celowo nieprawidłowe dane wejściowe, wartości graniczne, zmieniając środowisko (system operacyjny, plik konfiguracyjny) . Zasadniczo możemy powiedzieć, że próbujesz odkryć błędy i ostatecznie „debugować” je w procesie testowania. Mam nadzieję, że to pomaga.

Nie ma żadnych. Jeśli zrobisz to dobrze:

Hit 'em High, Hit' em Low :

Testowanie regresji i wyciskanie Saffa

Kent Beck, Three Rivers Institute

Streszczenie: Aby skutecznie izolować defekt, zacznij od testu na poziomie systemu, a następnie stopniowo dołączaj i przycinaj, aż uzyskasz możliwie najmniejszy test demonstrujący defekt.

Testowanie to przywilej, z którego korzystasz przed wydaniem klientowi.

Błędy to koszmar, który znosisz po wydaniu klientowi.

Inni wspominali o różnicach między testowaniem a debugowaniem.

Chciałbym podkreślić wspólną część. Gdy tester znajdzie defekt, należy go odizolować. Debugowanie jest jedną z technik izolowania problemu i znajdowania głównych przyczyn poprzez analizę stanu aplikacji i jej kodu w czasie wykonywania. W rzeczywistości debugowanie definiowane jest w słownikach Oxford jako „proces identyfikowania i usuwania błędów ze sprzętu komputerowego lub oprogramowania”.

Kto będzie izolować (lub w szczególności debugować) defekt, bez względu na to, czy będzie to tester, czy programista, to drugorzędne pytanie.

Wymieniony model dojrzałości testowej to opis mentalności zespołu programistów.

Lista sugeruje, nie mówiąc wprost, w jaki sposób zmiana mentalności wpływa na sposób przeprowadzania testów.

W miarę awansu zespołu programistów na kolejny poziom, zakres testowania zostaje poszerzony.

Na poziomie 0 testy nie są wykonywane, ponieważ zespół uważa, że ​​nie jest to konieczne.

Na poziomie 1 przeprowadzane są testy w celu zapewnienia nominalnego zasięgu podstawowych funkcji.

Na poziomie 2 testowanie jest poszerzone o wszystko na poziomie 1 i dodaje do testów destrukcyjnych (oddany zespół testowy, który ma dostęp do wszystkich informacji, do których mają dostęp programiści, w tym do kodu źródłowego i plików binarnych, i próbuje znaleźć błędy, które mogą być wywołane z roli użytkownika)

Na poziomie 3 oprócz wszystkiego na poziomach 1-2 dodano testowanie niefunkcjonalne / testowanie niepoprawności (takie jak charakterystyki wydajności).

Na poziomie 4 cele testowania oprogramowania są dobrze zrozumiałe dla każdej osoby, w tym dla personelu IT zajmującego się obsługą klienta. W ten sposób pracownicy IT będą mogli przekazać informacje zwrotne na temat scenariuszy do przetestowania, poprawiając pokrycie ryzyka na poziomie 4.

(Zastrzeżenie: Nie mam dostępu do podręcznika, dlatego moja terminologia może być niepoprawna).

Błędy są widocznymi błędami. Debugowanie to proces rozpoczęty po zaprojektowaniu przypadku testowego. Jest to trudniejsze zadanie niż testowanie, ponieważ w procesie debugowania musimy znaleźć źródło błędu i usunąć go, więc czasami debugowanie frustruje użytkownika.

Mówiąc w kategoriach codziennych, praktycznych, myślę, że to całkowicie zależy od kontekstu .

W med-dużym zespole, pracującym zgodnie z wysokimi / bardzo wysokimi standardami (systemy bankowe, wojskowe, na dużą skalę, z wysokim budżetem lub systemami o krytycznym znaczeniu dla biznesu), myślę, że wyraźnie „debugowanie” powinno być „wynikiem testów” i są wyraźnie bardzo różne rzeczy . Idealnie testowanie prowadzi do debugowania (w środowisku testowym), a podczas produkcji potrzebujemy prawie zerowego z nich.

Testy mają szeroki zakres, są regularne i bardzo sformalizowane - podczas gdy debugowanie jest szczególnym procesem, który zdarza się czasami, gdy zachodzi potrzeba naprawienia określonej awarii - co nie jest oczywiste i wymaga głębszego badania funkcjonowania systemu i wynikowych wyników.

Tutaj moim zdaniem testowanie jest czymś niezbędnym, podczas gdy debugowanie jest specyficznym narzędziem potrzebnym tylko wtedy, gdy rozwiązanie problemu jest nieprzejrzyste.

Całkowicie rozumiem oczywistą użyteczność TDD dla dużych zespołów i systemów, niż po prostu nie stać mnie na buggy. Ma to również sens w przypadku złożonych (często „back-endowych”) systemów lub jeśli w kodzie występuje wysoki stopień złożoności w porównaniu do danych wyjściowych. Wtedy „testowanie” ma realistyczną szansę na poinformowanie, kiedy i dlaczego wystąpią awarie. Systemy, które wykonują wiele skomplikowanych prac i / lub dają wyraźnie mierzalne wyniki, są na ogół łatwe do przetestowania, dlatego testowanie różni się od debugowania. W takich przypadkach testowanie silnie implikuje opartą na procedurze, sformalizowaną metodę potwierdzania lub odrzucania dopasowania oczekiwań i rzeczywistych wyników. Testowanie odbywa się cały czas i czasami informuje nas o potrzebie debugowania.

Byłoby cudownie, gdyby była to wszechobecna prawda, bardzo bym chciał, gdyby moje cykle programistyczne były ograniczone przez jasno określone wyjście binarne (czerwony, zielony), ale ...

W moim przypadku (co jest zresztą szczególne - praca w 98% solo na niedużych, niedofinansowanych internetowych systemach administracyjnych zorientowanych na dane) po prostu naprawdę nie widzę, jak TDD może mi pomóc. A raczej „debugowanie” i „testowanie” są praktycznie takie same.

Głównie jednak użycie terminu „testowanie” implikuje / ściśle wiąże się z metodologią TDD.

Wiem, że jest to całkowicie, całkowicie bez Zeitgeist „unikaj niewierzącego, unikaj, unikaj”, godne pogardy rzeczy do powiedzenia. Ale myśląc o moim kontekście, z praktycznym kapeluszem, po prostu nawet nie jestem niejasny, w mojej najdzikszej wyobraźni widzę, jak TDD może pomóc mi w dostarczeniu większej wartości do moich klientów.

A raczej zdecydowanie nie zgadzam się z powszechnym założeniem, że „testowanie” jest procesem opartym na formalnym kodzie.

Moje podstawowe zastrzeżenie (mające zastosowanie w moim szczególnym * kontekście *) polega na tym, że ...

Jeśli nie mogę napisać kodu, który działa niezawodnie - to do diabła, że mam napisać kod, który działa niezawodnie, aby przetestować ten przypuszczalnie nietypowy kod.

Dla mnie nigdy nie widziałem żadnego przykładu ani argumentu, który (w moim szczególnym kontekście) zachęciłby mnie na tyle, żebym nawet niepokoił się myślami o napisaniu pojedynczego testu , mógłbym teraz napisać jakiś śmiesznie nieistotny kod testowy, może „czy moje repozytorium zwraca użytkownika encja o nazwie == X, kiedy proszę o to dokładnie - i tylko to -? ale prawdopodobnie jest we mnie więcej użyteczności, pisząc ten streaming, może-internet-naprawdę-jest-po prostu-głupi-wytrysku- samozadowolenie - dziko niedoinformowany - gotujący się we krwi szef - marnotrawnie głupiutki śmieć, ale po prostu czuję potrzebę odgrywania tu roli adwokata diabła. (Mam nadzieję, że ktoś pokaże mi światło i nawróci mnie, może to da moim klientom lepszy stosunek jakości do ceny?).

Prawdopodobnie „debugowanie” czasami jest tym samym co „testowanie”. Rozumiem przez to, że w codziennym życiu zawodowym spędzam co najmniej jedną trzecią mojego czasu, grając z lokalną wersją mojego systemu w różnych przeglądarkach, desperacko próbując różnych różnych zwariowanych rzeczy, próbując przerwać moją pracę, a następnie badając powody, dla których zawiodło i ich poprawienie.

W 100% zgadzam się z oczywistą użytecznością w mantrze TDD „czerwony / zielony / refaktor”, ale dla mnie (pracując w niskim budżecie, solo Dev RIA land) naprawdę bardzo chciałbym, aby ktoś pokazał mi, jak mógłbym być może , logicznie i niezwykle realistycznie, uzyskam jakąkolwiek dodatkową wartość, pisząc więcej ( tak jak potencjalnie wadliwy kod testowy) niż ja faktycznie wchodzę w interakcję z pełnym (i zasadniczo tylko) efektem moich wysiłków, które są zasadniczo związane z prawdziwą ludzką interakcją.

Dla mnie, gdy programiści mówią o „testowaniu”, zwykle oznacza to TDD.

Staram się kodować tak, jakby istniały testy, myślę, że wszystkie wzorce / praktyki i trendy, do których zachęcał cały ten rozwój skoncentrowany na testowaniu, są fantastyczne i piękne, ale dla mnie w moim małym świecie „testowanie” nie polega na pisaniu większej ilości kodu, a tak naprawdę testowanie realnego świata generuje go w zbliżający się realistyczny sposób, i to jest właściwie to samo co debugowanie, a raczej aktywną zmianą jest tutaj „debugowanie”, które jest bezpośrednim rezultatem niezautomatyzowanych „testowania” zorientowanych na człowieka. Jest to sprzeczne z ogólnie przyjętym poglądem na „testowanie” jako coś zautomatyzowanego i formalnego oraz „debugowanie” jako coś ludzkiego i doraźnego lub nieustrukturyzowanego.

Jeśli celem jest naprawdę stosunek jakości do ceny / wysiłku, a tworzysz interaktywne aplikacje internetowe, to wynikiem wysiłku są strony internetowe i bardzo zasadniczo ich reakcja na wkład człowieka - więc „testowanie” najlepiej osiągnąć przez testowanie te strony internetowe poprzez rzeczywistą interakcję człowieka. Gdy ta interakcja prowadzi do nieoczekiwanych lub niepożądanych wyników, następuje „debugowanie”. Debugowanie jest również ściśle związane z ideą kontroli stanu programu w czasie rzeczywistym. Testowanie jest ogólnie związane z automatyzacją, co moim zdaniem jest często niefortunnym skojarzeniem.

Jeśli celem jest naprawdę wartość wysiłku, a automatyczne testowanie jest wydajne i bardzo korzystne, podczas gdy debugowanie jest albo wynikiem tych testów, albo słabym zamiennikiem automatycznych testów, to dlaczego jest drugą najczęściej odwiedzaną witryną na świecie (Facebook ) tak często wypełnione oślepiająco oczywistymi (dla użytkowników, ale wyraźnie nie zespołem testującym i kodem testującym) błędami?

Może dlatego, że koncentrują się na uspokajających zielonych światłach i zapominają o faktycznym wykorzystaniu wyników swojej pracy?

Czy zbyt wielu programistów uważa, że ​​testowanie to coś, co robisz z kodem, a debugowanie to coś, co robisz od czasu do czasu z IDE, ponieważ ikona zmienia kolor na czerwony i nie możesz zrozumieć, dlaczego? Sądzę, że słowa te wiążą się z niefortunnymi ocenami wartości, które na ogół zaciemniają praktyczną rzeczywistość tego, na czym powinniśmy się skupić, aby wypełnić luki między oczekiwaniami a wynikami.

Po prostu,

Testowanie oznacza znalezienie danych wejściowych, które powodują awarię oprogramowania podczas debugowania, to proces znajdowania usterki danej awarii.