• Błąd jest wynikiem błędu kodowania

• Wada to odchylenie od wymagań

To znaczy: defekt nie musi oznaczać błędu w kodzie , to może być funkcją, która nie została zaimplementowana, ale zdefiniowana w wymaganiach oprogramowania.

Ze strony Wikipedii na temat testowania oprogramowania :

Nie wszystkie defekty oprogramowania są spowodowane błędami kodowania. Jednym z częstych źródeł kosztownych defektów są luki w wymaganiach, np. Nierozpoznane wymagania, które skutkują pomyłkami projektanta programu. [14] Częstym źródłem luk w wymaganiach są wymagania niefunkcjonalne, takie jak testowalność, skalowalność, łatwość utrzymania, użyteczność, wydajność i bezpieczeństwo.

Komentarze

• Oba są ” odchyleniami od wymagań ” tak, jak to widzę.
• Defekt nie ' nie musi być błędem. Ponadto błąd nie ' nie musi oznaczać niespełnienia wymagania, a zatem nie jest ' odchyleniem od wymagania '
• Wydaje się, że brakuje Ci sedna @ Martina. Tak, błąd może być wadą. Tak, wada może być błędem. Ale to nie jest ' t zawsze prawda. Tylko dlatego, że niektóre nakładają się, czy ' nie oznacza, że są identyczne! Diagram Venna błędu & Usterka – > (())
• @Dan McGrath: w zasadzie to, co tu zrobiłeś, to twoja własna definicja błędu. Ale ogólnie nie ma ' żadnego zdefiniowanego znaczenia, to ' to tylko inżynierski żargon!
• @DanMcGrath : Twój diagram Venna jest bezużyteczny. Może to oznaczać ({}) lub ({)} . Zakładam, że miałeś na myśli drugie.

Cytując Ilene Burnstein z książki Praktyczne testowanie oprogramowania (zalecane), kto wykracza poza definicję w„ Standardach IEEE Collection for Software Engineering ”(1994) i„ IEEE Standard Glossary of Software Engineering Terminology ”(standard 610.12, 1990):

Błąd

Błąd to błąd, nieporozumienie lub nieporozumienie ze strony programisty

Do kategorii programistów zaliczamy inżynierów oprogramowania, programistów, analityków i testerów. Na przykład programista może błędnie zrozumieć zapis projektu lub może nieprawidłowo wpisać nazwę zmiennej.

Błędy (wady)

Usterka (defekt) jest wprowadzana do oprogramowania w wyniku błędu. Jest to anomalia w oprogramowaniu, która może spowodować, że będzie działać niepoprawnie, a nie zgodnie ze specyfikacją.

Błędy lub defekty są czasami nazywane „błędami”. Użycie tego ostatniego terminu trywializuje wpływ błędów na jakość oprogramowania. Użycie terminu „defekt” jest również związane z artefaktami oprogramowania, takimi jak wymagania i dokumenty projektowe. Defekty występujące w tych artefaktach są również spowodowane błędami i zwykle są wykrywane w procesie przeglądu.

Błędy

Awaria to niezdolność systemu oprogramowania lub komponentu do wykonywania wymaganych funkcji w ramach określonych wymagań wydajnościowych.

Podczas wykonywania komponentu lub systemu oprogramowania tester, programista, lub użytkownik zauważy, że nie daje to oczekiwanych rezultatów. W niektórych przypadkach określony rodzaj niewłaściwego zachowania wskazuje na występowanie określonego rodzaju błędu. Można powiedzieć, że rodzaj złego zachowania jest objawem winy.Doświadczony programista / tester będzie miał bazę wiedzy o błędach / objawach / przypadkach awarii (modele usterek, jak opisano w rozdziale 3) przechowywaną w pamięci. Nieprawidłowe zachowanie może obejmować tworzenie nieprawidłowych wartości dla zmiennych wyjściowych, niepoprawną odpowiedź ze strony urządzenia lub nieprawidłowy obraz na ekranie. Podczas programowania błędy są zwykle obserwowane przez testerów, a błędy są lokalizowane i naprawiane przez programistów.

Możesz przeczytać cały rozdział w Książkach Google, tutaj .

Istnieje kilka różnych terminów związanych z błędami oprogramowania. Fragment kursu, w którym uczestniczyłem:

• Błąd : ludzkie działanie lub zaniechanie co skutkuje usterką.

• Błąd : Błąd to oprogramowanie defekt (nieprawidłowy krok, definicja procesu lub danych) powodujący awarię.

• Błąd : Tak samo jak błąd.

• Błąd : niezdolność oprogramowania do wykonywania wymaganych funkcji w ramach określonych wymagań wydajnościowych.

W związku z tym nie ma różnicy między defektem a błędem. Jednak niektórzy twierdzą, że błąd jest błędem wykrytym przed wydaniem oprogramowania, podczas gdy wada jest wykryta przez klienta.

Nie mogłem się powstrzymać przed opublikowaniem słynnego „pierwszego faktycznego przypadku znalezienia błędu „.

Komentarze

• Wreszcie ktoś, kto przeczytał: testingstandards.co.uk/bs_7925-1_online.htm
• That ' nie skąd go otrzymałem, ale mogą mieć wspólne źródło (lub to może być źródłem).
• Tak, wiele, wiele lat temu spędziłem trochę czasu próbując naprawić błąd. w jednej komórce na ekranie pojawiło się irytujące migotanie i nie miało to sensu. W końcu odleciało. (To było w erze białego tekstu na czarnym ekranie, miejsce, o którym mowa, znajdowało się na tyle daleko w prawo, że zawsze było czarne Edytowałem, więc zauważyłem to tylko wtedy, gdy program umieścił za sobą trochę bieli.)

O jej.

W dawnych czasach – wadliwe działanie komputera było spowodowane różnymi rzeczami – w tym szczurami przeżuwającymi przewody i prawdziwymi owadami (stworzeniami) dostającymi się do prac.

termin BUG utknął jako termin, który oznacza, że coś nie działa zgodnie z oczekiwaniami.

BUG należy traktować jako żargonowy termin oznaczający usterkę.

Defekt jest technicznie poprawnym terminem. że rzecz nie działa tak, jak powinna.

Wszędzie tam, gdzie to możliwe, użycie DEFECT zamiast BUG faktycznie niesie ze sobą konotację, że uznajemy nasze błędy (nasze wady, nasz brak zrozumienia wymagań użytkownika lub rzeczy przeoczyliśmy w implementacji) zamiast ubierać się w bardziej trywialnie brzmiący „błąd”.

Użyj DEFECT.

Staraj się nie używać terminu BUG. Jest głupi, nieistotny, historyczny i trywializujący.

Komentarze

• Dlaczego chcesz usunąć z użycia dobrze zrozumiały termin techniczny? I ' przepraszam … tak, BŁĄD jest historyczny – ale jeśli uważasz, że programiści uważają błędy (ogólnie w przeciwieństwie do konkretnych) za trywialne tylko dlatego, że są nazywane błędami lub termin jako nieistotny ze względu na swoje pochodzenie, to ' obawiam się, że przemienienie się w zrzędliwego w średnim wieku jest całkowicie uzasadnione. Aha, i jak wskazuje @Dan, błędy są defektami, ale defekty nie są ' t koniecznie błędami, co dodatkowo sugeruje, że termin ma wartość.
• @Murph, a ” błąd ” to eufemizm określający błąd programistyczny. Nieświadomie przyciąga to swego rodzaju gremlina, nad którym deweloper nie ma kontroli. To nieprawda – jest to błąd i uznanie tego jest krokiem w kierunku bardziej profesjonalnego zachowania. (Oczywiście Imho :-))
• Oczywiście nie zgadzam się (-: Wiem dokładnie, kto jest odpowiedzialny za błędy – kodowanie i błędy logiczne – które mam w kodzie. (I iv id ( cóż, jakiś programista), a nie jakiś gremlin, popełnił błąd.
• W kontaktach z klientami możesz nazwać te rzeczy błędami lub wadami. Błędy to żargon. Wady to poza żargonem stwierdzenie, że nie jest tak, jak być powinno. ” Wady ” to termin, który zachęca do jasnej komunikacji – także poza wspólnotą programistów jak w środku.(Nie zgadzam się też, że istnieje różnica między błędem a defektem).
• Defekty to właściwy termin. Ile programów jest publikowanych z błędami i wszyscy to akceptujemy? Ale ile programów jest udostępnianych z błędami? Nie ' nie zaakceptowalibyśmy tego, ponieważ termin oznacza większą wagę i wiemy, że ' jest naszą własną winą za błąd, a raczej niż błąd, w którym możemy winić pogodę lub porę dnia.

Ze standardu IEEE Glosariusz terminologii inżynierii oprogramowania, cytowany w Body Engineering Body of Knowledge KA w zakresie testowania oprogramowania i jakości oprogramowania:

błąd. Zobacz: błąd; błąd.

błąd. (1) Różnica między obliczoną, zaobserwowaną lub zmierzoną wartością lub stanem a prawdziwą, określoną lub teoretycznie poprawną wartością lub warunkiem. Na przykład różnica 30 metrów między wynikiem obliczonym a wynikiem prawidłowym. (2) Nieprawidłowy krok, proces lub definicja danych. Na przykład niepoprawna instrukcja w programie komputerowym. (3) Niepoprawny wynik. Na przykład obliczony wynik 12, gdy prawidłowy wynik to 10. (4) Czynność ludzka, która daje niepoprawny wynik. Na przykład nieprawidłowe działanie ze strony programisty lub operatora. Uwaga: Chociaż wszystkie cztery definicje są powszechnie używane, w jednym rozróżnieniu przypisuje się definicję 1 do słowa „błąd”, definicję 2 do słowa „usterka”, definicję 3 do słowa „awaria”, a definicję 4 do słowa „błąd”. Zobacz a2so: błąd dynamiczny; błąd krytyczny; błąd lokalny; błąd semantyczny; błąd składniowy; błąd statyczny; przejściowy błąd.

awaria. Niezdolność systemu lub komponentu do wykonywania wymaganych funkcji w ramach określonych wymagań wydajnościowych. Uwaga: W dyscyplinie tolerancji na błędy rozróżnia się działanie człowieka (błąd), jego przejaw (awaria sprzętu lub oprogramowania), skutek błędu (awaria) oraz wielkość, o jaką wynik jest nieprawidłowy (błąd). Zobacz także: crash; zależna awaria; wyjątek; Tryb awaryjny; współczynnik awaryjności; ciężka awaria; początkowa awaria; niezależna awaria; losowa awaria; miękka awaria; zablokowany błąd.

błąd. (1) Wada urządzenia lub komponentu sprzętowego; na przykład zwarcie lub przerwany przewód. (2) Nieprawidłowy krok, proces lub definicja danych w programie komputerowym. Uwaga: Ta definicja jest używana głównie przez dyscyplinę tolerancji na błędy. W powszechnym użyciu do wyrażenia tego znaczenia używane są terminy „błąd” i „błąd”. Zobacz też: błąd wrażliwy na dane; program wrażliwy błąd; równoważne wady; maskowanie błędów; sporadyczny błąd.

Myślę, że definicja awarii jest najbardziej odpowiednia. Wszystko zaczyna się od pomyłki, czy to w wymaganiach, projekcie, implementacji, czy w przypadku / procedurze testowej. Jeśli błąd ten przejawia się w oprogramowaniu, staje się błędem. Awaria jest spowodowana istnieniem jednego lub więcej błędów w oprogramowaniu.

Nie lubię jednak formalnej definicji błędu. Bardzo wolę definicję podaną przez dukeofgaming w jego odpowiedzi , jednak ta odpowiedź jest standardową definicją błędu IEEE.

Odpowiedź Dana McGratha dobrze to ułożyła.

• Błąd jest wynikiem błędu w kodowaniu
• Defekt jest odchyleniem od wymagań

Może przykład uczyniłby to bardziej zrozumiałym.

Przykład: Klient chciał, aby formularz internetowy mógł zapisać i zamknąć okno.

Scenariusz 1: Formularz sieciowy ma przycisk zapisywania i kolejny przycisk zamykania. Wynik: Defect, ponieważ klient chciał, aby przycisk 1 zapisał i zamknął okno. Programista źle zrozumiał i utworzył je osobno. Ponieważ oba przyciski spełniały swoje wymagania, nie jest to błąd, ale defekt, ponieważ nie spełniał wymagań klienta.

Scenariusz nr 2: formularz sieciowy ma przycisk zapisz & zamykania, ale tylko zapisuje, ale nie zamyka. Wynik: Pluskwa. Ponieważ przycisk nie działa zgodnie z wymaganiami / oczekiwaniami. Deweloper wie, że powinien dać taki wynik, ale ostatecznie się nie udało. (Być może błąd w kodowaniu)

Nie jestem pewien, czy to czyni go jaśniejszym.

p / s: od programisty z punktu widzenia (byłem kiedyś), zarówno usterki, jak i błędy są równie ważne. Nadal będziemy to naprawiać.

Napotkaliśmy nawet dziwne anomalie, które klasyfikowaliśmy jako błędy i nieustannie próbujemy dowiedzieć się, co jest przyczyną i jak to naprawić. Nazywanie tego błędami nie czyni tego trywialnym w porównaniu z defektami.

Komentarze

• Co nazywamy błędnymi wymaganiami?
• @ gnasher729 jeśli przez błędne wymagania miałeś na myśli, że programiści źle je zrozumieli, to pomyślałem, że ' jest defektem. Ale jeśli miałeś na myśli błędne wymagania, ponieważ użytkownik podał niewłaściwe wymagania, co skutkuje końcową pracą, nie rozwiązuje początkowego problemu, to jest to poza błędami i wadami, ponieważ jest to problem z sesją zbierania wymagań, a nie z rozwojem.

Oto jedno, które zrobiłem wcześniej dla mojego pracodawcy Q-LEAP na podstawie słownictwa ISTQB, a także sprawdziłem słownictwo IEEE. Cieszyć się.

Błąd i wada? To samo, chociaż można o tym dyskutować bez końca. Mamy naprawdę inne zmartwienia, życie jest już wystarczająco skomplikowane itp.

Przykład w jaki sposób termin jest używany w środowisku naturalnym, z „How Google Tests Software” s. 113. Otwórz artykuł „Oprogramowanie IEEE” i jest używany w ten sam sposób. Rzeczywiście, rzadko można spotkać słowo „defekt” w prawdziwym życiu.

Life of a Bug

Błędy i raporty o błędach to jedyny artefakt, który rozumie każdy tester. Znajdowanie błędów, segregowanie błędów, naprawianie błędów i cofanie błędów to puls i przepływ pracy jakość oprogramowania. Jest to część testowania, która jest najbardziej konwencjonalna w Google, ale nadal istnieje kilka interesujących odchyleń od normy. W tej sekcji ignorujemy błędy, które są zgłaszane w celu śledzenia elementów pracy i używamy tego terminu do identyfikacji rzeczywisty uszkodzony kod. W związku z tym błędy często reprezentują codzienny i godzinny przepływ pracy zespołów inżynierów.

Rodzi się błąd. Błędy są wykrywane i zgłaszane przez wszystkich w Google. Produkt Menedżerowie zgłaszają błędy, gdy wychwycą problemy we wczesnych kompilacjach, które różnią się od ich specyfikacji / przemyśleń. Programiści zgłaszają błędy, gdy zdadzą sobie sprawę, że przypadkowo sprawdzili problem lub znajdą problem w innym miejscu w bazie kodu lub podczas testowania produktów Google. Błędy pojawiają się również w terenie, od testerów pochodzących z tłumu, testów od dostawców zewnętrznych, i są zgłaszane przez menedżerów społeczności monitorujących grupy dyskusyjne Google dotyczące poszczególnych produktów. Wiele wewnętrznych wersji aplikacji umożliwia szybkie zgłaszanie błędów za pomocą jednego kliknięcia, na przykład mapy Google. Czasami programy tworzą błędy za pośrednictwem interfejsu API.

Różnica polega na tym, że termin „błąd” brzmi magicznie. Tak jakby program mógł losowo zawierać błędy po zakończeniu programowania. Jeśli ma przypadkowe błędy, oznacza to, że nie spełniałeś specyfikacji i twój program jest w błędzie.

Defekt oznacza błąd, w przypadku którego program nie jest zgodny ze specyfikacjami. Jest to poważniejsze i zasadniczo mówi, że każdy błąd to ogromny problem z programem, a to oznacza, że program nie nadaje się do wydania.

Różnica polega na nastawieniu programistów, którzy używają tych terminów. Istnieją miliony programów, które są publikowane z błędami i ludzie nie mają nic przeciwko temu, ponieważ z jakiegoś powodu akceptują że błąd jest magiczny i losowy oraz że każdy program zawiera co najmniej jeden błąd. Jednak programista, który używa terminu „defekt”, może czuć się niekomfortowo, publikując program z defektem, ponieważ termin ten oznacza większą wagę.

Konsekwencje preferowania jednego terminu od drugiego wpływają na nas codziennie.

Poza konkretnym błędem / zadaniem / zgłoszeniem / defektem / problemem / jakąkolwiek instancją systemu śledzenia słowa te nie mają żadnego dokładnego znaczenia, dlatego omawianie różnicy między nimi jest bezcelowe. Rozstrzygając przepływ pracy, należy ustalić terminologię i podać opisy.

W moim obecnym środowisku „usterką” jest dowolny element w Jira. Wygląda na to, że sama Jira używa terminu „problem”. Być może odziedziczyliśmy go z jakiegoś wcześniejszego systemu.„Błąd” to rodzaj problemu, w którym coś nie działa zgodnie z oczekiwaniami i opisem w dokumentacji. „Żądanie funkcji”, gdy coś działa zgodnie z oczekiwaniami, ale poprawa jest pożądana (może to być oczywiste i ważne, ale jeśli opisane jest bieżące zachowanie, nadal jest to żądanie funkcji). Jest więcej typów, ale te 2 są używane przez osoby spoza zespołu programistów, aby o coś zapytać.

Jeśli wybierasz nazwy typów problemów, „błąd” i „wada” brzmią podobnie do mnie. Różnica między nimi jest stylistyczna. Ponieważ angielski nie jest moim językiem ojczystym, tak naprawdę nie widzę go zbyt wiele i nie jestem pewien, czy to, co widzę, jest poprawne.