Jak duże firmy programistów sprawdzają błędy w swoich programach?

Zastanawiałem się, jak duże firmy programistów sprawdzają błędy w swoich programach.

Czy tylko testują to na kilku komputerach?

Oto niektóre techniki, których używa Google.

1. Zatrudnij dobrych programistów, którzy prawdopodobnie produkują niezawodny kod.
2. Test jednostkowy mocno.
3. Użyj przeglądu kodu .
4. Ustaw ciągłą kompilację, aby wychwycić problemy z integracją.
5. Posiadaj dedykowane działy kontroli jakości. Oznacza to zarówno osoby testujące, jak i zautomatyzowane programy (na przykład wykorzystujące Selenium), które symulują użytkowników końcowych.
6. Monitoruj produkcję, aby uchwycić dowody niewłaściwego zachowania.

Uszeregowałem je według tego, co podejrzewam, według malejącej kolejności skuteczności w wykrywaniu błędów.

Większe firmy zwykle mają całe całe działy Q / A, które są odpowiedzialne za testowanie kodu i upewnianie się, że działa tak, jak powinien. Zazwyczaj jest tak, jak opisałeś - grupa ludzi testuje wiele maszyn. Czasami testy są zautomatyzowane, a czasem nie. Zobacz Quality Assurance - Wikipedia

Wiele razy sami programiści znajdą błędy podczas procesu programowania. Ponadto klienci często jako pierwsi znajdują błąd.

Mniejsze firmy, takie jak te, w których obecnie pracuję, stosują praktykę Agile Testing

Powiedziałbym, że chodzi o dojrzałość firmy, a nie o wielkość :) Są duże firmy, które mają słabe praktyki rozwojowe i małe firmy, które są w czołówce.

Ogólnie rzecz biorąc, dojrzały zespół programistów zaangażuje się w następujące działania do 1; zminimalizować wprowadzanie nowych błędów do systemu i 2; znajdź błędy w istniejącym systemie.

Testy jednostkowe: są to „mini-sterowniki” dla poszczególnych metod, aby upewnić się, że metoda robi to, co mówi. Są to zawsze testy automatyczne.

Testy integracyjne: testy te mają na celu sprawdzenie, czy w systemie działa większa jednostka funkcjonalności. Może to obejmować testowanie integracji bazy danych lub integracji z bibliotekami stron trzecich. Są to również testy automatyczne.

Testy akceptacyjne: testy akceptacyjne są zapisywane w celu przetestowania wymagań użytkownika. Zazwyczaj testują one „szczęśliwą ścieżkę”. W moim zespole testy te mają na celu wykazanie, że jeśli użytkownik będzie korzystał z funkcji zgodnej z przeznaczeniem, nie będzie miał problemów. Może być ręczny lub automatyczny.

Testy funkcjonalne: testy te są podobne do testów akceptacyjnych, ale testują także „nieszczęśliwą ścieżkę”. Testy te oznaczają przetestowanie mało oczywistych scenariuszy. Może być ręczny lub automatyczny.

Testy regresyjne: używamy tego terminu do „pełnego testowania” systemu przed udostępnieniem go klientom. Ręczny lub automatyczny.

Testy goryla: (tylko ręczne). Jest to rodzaj testowania, gdy bardzo inteligentni ludzie celowo próbują przerwać aplikację.

Testy wydajności Celem jest upewnienie się, że wydajność jest akceptowalna i nie zmniejsza się z czasem. Zwykle zautomatyzowany.

Testy stabilności: testy te mają na celu zapewnienie stabilności systemu w czasie. Zautomatyzowane.

Ciągła integracja: jest to system, który automatycznie sprawdza kod, kompiluje go i uruchamia automatyczne testy. Twoje szybsze testy (jednostka, integracja) będą uruchamiane za każdym razem, gdy programista zatwierdzi kod. Niektóre inne są uruchamiane co noc (akceptacja, funkcjonalność) lub co tydzień (wydajność, stabilność).

Raporty pokrycia kodu: pokazuje, ile części kodu jest testowane. Kod, który nie jest objęty testem, jest bardziej podatny na uszkodzenie.

Różne narzędzia analizujące kod: Zazwyczaj pokazują one, gdzie kod musi zostać ponownie podzielony na faktury, aby był mniej podatny na potencjalne błędy.

Programowanie w parach: dwóch programistów współpracujących w celu zapewnienia funkcjonalności. „Spójna para jest lepsza niż suma jej części”.

Najważniejsze do zabrania to: automatyzacja i ciągła integracja .

To zależy od firmy i opracowywanych produktów.

Po pierwsze, wiele firm egzekwuje praktyki kodowania, takie jak przeglądy kodu i obowiązkowe podszywanie się (narzędzia do automatycznego wykrywania błędów), aby zmniejszyć liczbę błędów w repozytorium. Wiele firm przyjęło również testy jednostkowe. Tak jest w przypadku mojej pracy (Google). Po wpisaniu kodu testy są przeprowadzane na wszystkich elementach, aby upewnić się, że nie zostaną wprowadzone żadne nowe błędy.

Po drugie, wiele firm ma działy kontroli jakości odpowiedzialne za sprawdzanie poprawności zachowań. Jest to szczególnie powszechne w finansach (gdzie błędy mogą być kosztowne, a zasady sprawdzania poprawności są złożone), ale występuje również w firmach, które sprzedają produkty użytkownikom, których wycofanie może być kosztowne (np. Intel, Microsoft itp.).

Po trzecie, ilekroć jest to możliwe, firmy przeprowadzają Dogfooding (ich użytkownicy używają produktu wewnętrznie), a następnie wypuszczają ograniczone wersje beta. Na tym etapie wychwytuje się wiele błędów. Na przykład ludzie pracujący w firmie Microsoft używają nowszych wewnętrznych wersji pakietu Office, Windows i DevStudio niż to, co masz na zewnątrz. Następnie ograniczone grupy użytkowników lub zakontraktowane firmy mogą pobrać próbkę. Podobnie w Google używamy wewnętrznych wersji Gmaila i Dokumentów przed wydaniem. Firmy produkujące gry organizują otwarte bety w celu przetestowania swoich produktów i obciążenia serwerów itp.

Oczywiście odpowiedź brzmi „It dpends”, ale dam próbkę z mojego największego do tej pory projektu, w którym w szczycie zaangażowanych było około 50 programistów.

Podstawowa konfiguracja: oprogramowanie zaplecza do przetwarzania dużych ilości danych za pomocą BizTalk.

Pierwszą linią obrony są testy jednostkowe. W naszym przypadku były one wykonywane codziennie dla wszystkiego sprawdzanego w kontroli źródła i zwykle niektóre z nich były wykonywane ręcznie przez programistę przed odprawą. Testy jednostkowe zostały napisane głównie przez programistów, ale czasem poprawione przez dodatkowe testy przez testerów.

Kolejnym krokiem była cotygodniowa kompilacja Virtual PC, w której testerzy przeprowadzili serię głównie zautomatyzowanych kompleksowych testów przepływu danych w oparciu o dokumenty specyfikacji dla każdego komponentu.

Następnie ten sam wirtualny komputer został wzbogacony o pewne dane biznesowe całkiem zbliżone do rzeczywistych i przetestowany ponownie z pewnymi konkretnymi przypadkami użycia.

Następnie Virtual PC został połączony z innymi komponentami systemu (również głównie wirtualnymi) z innych działów do cyklu testów integracyjnych opartych na kompleksowych testach od użytkownika wprowadzającego dane do końca przepływu danych.

Na innej ścieżce pakiety instalacyjne zostały przetestowane przez dostawcę systemów, aby sprawdzić, czy zostały poprawnie zainstalowane w środowisku produkcyjnym i czy można je przywrócić, jeśli coś się nie powiedzie.

Po instalacji w środowisku produkcyjnym przeprowadziliśmy testy obciążenia i obciążenia, aby przetestować ogólną stabilność (nie należy tego lekceważyć, gdy uruchomisz 10 serwerów BizTalk, 8 serwerów SQL i kilka innych specjalistycznych urządzeń, takich jak akcelerator XML oraz dedykowane Archiwum - wszystkie oczywiście skupione).

Kiedy byliśmy zadowoleni ze wszystkich testów, kod został wprowadzony do produkcji. Dostajesz dość duże opóźnienie, aby naprawić błędy w kodzie (na przykład 4-6 tygodni dla całego cyklu testowego), i wykonanie wszystkich tych testów jest drogie, ale ogólna stabilność była całkiem dobra. W rzeczywistości najlepsze, jakie widziałem do tej pory. Znowu jest to dość ważne w systemie, który każdego dnia przetwarza kilka milionów dolarów. Twoje wymagania mogą się różnić, ale tak to zrobiliśmy i działało.

Oryginalne pytanie wydaje się bardziej ogólne pod względem koncepcyjnym niż większość bardzo szczegółowych odpowiedzi, które zostały udzielone.

Spójrzmy na to z wyższego poziomu (mniej szczegółowe). Oprogramowanie jest opracowywane w celu zaspokojenia określonych potrzeb od kogoś (osoby, firmy, cokolwiek).

Potrzeby te muszą zostać zamapowane na poszczególne historie / wymagania, które zostałyby ostatnio (w fazie budowy) zaimplementowane w kodzie źródłowym.

Dobrze zdefiniowane historie / wymagania są niezbędne dla zespołu zapewniania jakości (QA) (rzeczywistych testerów oprogramowania), aby zweryfikować ostateczny kod, gdy zostanie wykonany, odpowiada wymaganiom tych historii i wymagań. W tym celu zespół ds. Kontroli jakości tworzy „przypadki testowe” w celu przeprowadzenia tej weryfikacji.

Kod, po wydaniu zespołowi ds. Kontroli jakości, zostanie przetestowany i wykryte zostaną błędy. Błędy różnych typów i ciężkości. Błędy są śledzone, a programiści przydzielają je, aby w końcu je naprawić.

Korzystanie z maszyn wirtualnych umożliwia obecnie testerowi uruchamianie różnych środowisk na tym samym prawdziwym sprzęcie. Czasami jednak potrzebujesz niektórych komputerów poświęconych fazie kontroli jakości.

Mam nadzieję, że to pomoże ci zrozumieć (z grubsza) cały proces.

Cóż, nie znoszę być cyniczny, ale przy liczbie otwartych błędów w pewnym systemie operacyjnym „urządzenia” wydaje się, że im większa i bogatsza firma, tym więcej błędów są w stanie stworzyć i dostarczyć do użytkownika końcowego. Jeśli oprogramowanie działa i wygląda fajnie, po prostu i tak je wypuszcza. Jeśli menedżerowie uważają, że jest gotowy, to jest gotowy. To wtedy naprawdę paskudne robaki zaczynają wychodzić z stolarki, a użytkownicy końcowi stają się świnkami morskimi. Dziesięć lat później większość błędów zostanie opracowana (i kilka dodanych dla lepszej oceny), a firma będzie gotowa przejść do następnego wielkiego pomysłu.