Myślę, że to zależy od kontekstu. Czy najczęściej kończysz wdrażanie specyfikacji i chcesz rozpocząć końcowe testowanie, czy ogólnie mówisz w dowolnym momencie podczas cyklu programowania? Jak niektórzy wspominają w odpowiedziach, twoi implementatorzy zazwyczaj piszą testy jednostkowe, które można uznać za część testów Whtie Box, ponieważ ci koderzy rozumieją wewnętrzne działania i chcą potwierdzić funkcjonalność ich implementacji przed zatwierdzeniem.
Chris
Odpowiedzi:
11
Cokolwiek musi być najbardziej poprawne.
Poważnie, testowanie białych pól (tj. Testowanie wewnętrznych elementów kodu) powinno być idealnie przeprowadzane z testami jednostkowymi przez programistę, który napisał kod. Testy jednostkowe będą budowane z czasem, a część procesu kompilacji, abyśmy nie marnowali czasu słabego testera kodem, o którym wiemy, że nie działa tak, jak powinien. Testy jednostkowe stają się tym ważniejsze, im mniejszy jest twój zespół - szczególnie dlatego, że nie masz armii testerów, którzy mogliby rozwiać problemy.
Testowanie czarnej skrzynki (tj. Testowanie przez interfejs użytkownika / systemu) jest zwykle tym, co robi większość testerów.
Wszystkim testom należy nadać priorytet, jak ważna jest funkcja dla gotowego produktu. Jeśli misją jest zapewnienie narzędzia do wykonywania X, a produkt nie robi X, to duży problem.
Dobrze powiedziane, najlepsza odpowiedź, jaką przeczytałem do tej pory.
Chris
5
czarny
Testowanie czarnej skrzynki w celu weryfikacji funkcji. Testowanie białych skrzynek w razie potrzeby, jeśli coś jest zepsute. Jeśli wszystkie testy czarnej skrzynki przejdą pomyślnie i zasięg jest dobry, testy białej skrzynki nie są konieczne.
Chyba, że oczywiście testy czarnej skrzynki pominęły testowanie kluczowego elementu funkcjonalności lub konfiguracji:}
Alan
3
@Alan: ten sam argument dotyczy testów białych skrzynek, stąd zastrzeżenie „zasięg jest dobry”
Steven A. Lowe
1
Uzgodnione - chyba moje oświadczenie zależy od twojej definicji dobrego zasięgu.
Alan
1
@DocBrown Absolutnie nie rozumiem, jak to, co wyjaśniłeś, jest czymś zdalnym, jak testowanie whitebox. Testowanie Whitebox polega na podążaniu ścieżkami rozgałęzień danej implementacji i pisaniu przypadków testowych, które wykonają wszystkie ścieżki. Jeśli nie masz jeszcze implementacji, nie możesz z definicji wykonywać testów whitebox. Z TDD i BDD piszesz testy ogólnego kształtu podanego kiedy. Skonfigurujesz dane wejściowe lub stan wstępny, uruchomisz urządzenie i sprawdzisz dane wyjściowe lub stan końcowy lub połączenia z osobami trzecimi. To jest definicja testowania blackboksa.
Sammi,
1
@SamJudge: o ile mi wiadomo, kiedy zaglądasz do kodu implementacji i używasz tych informacji do zaprojektowania bardzo szczegółowych danych testowych (które następnie są przekazywane przez interfejs publiczny), uzasadnione jest nazywanie tego testu białych skrzynek. Taki test również kończy się niepowodzeniem, jeśli wynik nie jest zgodny z oczekiwaniami. Jeśli później przyjrzysz się tylko testowi, możesz nie być w stanie powiedzieć jasno „ten test został opracowany przy użyciu podejścia do białej skrzynki (lub czarnej skrzynki)”, oczywiście.
Doc Brown
3
Czarna skrzynka.
Komponenty białej skrzynki są zwykle zależne od komponentów czarnej skrzynki, więc najpierw chciałbym przetestować czarną skrzynkę, a następnie przejść do białej skrzynki.
Nie jestem pewien, co masz na myśli przez „komponenty czarnej skrzynki” i „komponenty białej skrzynki” - dla mnie są one po prostu „komponentami” (które można przetestować ze znajomością kodu lub architektury lub bez niego.
Alan
Nie rozumiem sugerowanej tutaj relacji „zależnej”. Biała czarna i czarna skrzynka nie są elementami, a raczej stylem testowania dowolnego elementu, jak wspomina Alan. Różnica polega na podejściu zastosowanym do przetestowania danego komponentu.
Chris,
2
Najpierw wykonujesz białe testy, myśląc jako programista / programista, aby upewnić się, że wszystko będzie dobrze. Następnie wykonujesz testy czarnej skrzynki, zwykle próbując myśleć, jakbyś był użytkownikiem końcowym, nie myśląc o wewnętrznej strukturze programu. Czasami musisz myśleć jak programista / programista, nawet jeśli wykonujesz czarne testy, ponieważ możesz testować wewnętrzny moduł napisany przez inną osobę i nie masz dostępu do kodu.
Jeśli chcesz mieć dobry cykl testowy, powinieneś mieć różne osoby wykonujące jedno i drugie :
Deweloper skoncentrowany głównie na testach białych skrzynek wie, co ostatnio zmieniło się w kodzie, które obszary są bardziej złożone (a zatem mogą się zepsuć) itp., I może odpowiednio skoncentrować wysiłki w tych obszarach, które najprawdopodobniej wprowadzą nowe wady.
Z drugiej strony tester kontroli jakości skoncentrowany na testowaniu czarnej skrzynki może łatwiej podejść do testowania jak użytkownik końcowy. Bez wewnętrznej wiedzy o kodzie mogą przyjąć nowe podejście i nie są stronnicze od wiedzy o tym, w jaki sposób wdrażane są różne części rozwiązania. Wyłapią błędy, które deweloper mógł przeoczyć, lub regresje spowodowane zmianami kodu, które przypadkowo zepsuły inne obszary aplikacji.
Aby odpowiedzieć na twoje pytanie, najpierw należy wykonać testy białej skrzynki. Ale naprawdę musisz mieć inną osobę wykonującą testy czarnej skrzynki, jeśli chcesz, aby była skuteczna.
Chciałbym zacząć od testowania czarnej skrzynki, a następnie użyć informacji o zasięgu kodu lub debugera, aby dowiedzieć się, co robię i przeanalizować, co się dzieje.
Ale prawdziwa odpowiedź to zależy . Prawdopodobnie zagłębię się w kod wcześniej (a nawet najpierw), jeśli przeprowadzam testy API, ale znacznie później, jeśli moim celem jest przyjrzenie się dużym scenariuszom od końca do końca.
-1, TDD to testy białej skrzynki. W TDD bardzo ważne jest, aby wiedzieć, co robi kod zaangażowany w test (a czego nie), aby napisać następny test. Czarna skrzynka testowania oznacza, że ktoś, kto nie ma pojęcia o kodzie (tester, kogoś, kto nawet nie musi wiedzieć, jak do kodu), projektuje testy.
Doc Brown
1
Zatem nie ćwiczymy TDD w ten sam sposób. TDD dla mnie polega na egzekwowaniu specyfikacji klasy / funkcji: testy są napisane w celu sprawdzenia, czy klasa / funkcja zachowuje się zgodnie ze specyfikacją, ale może mniej obchodzić się, jak kod zachowuje się za kulisami, o ile te specyfikacje są przestrzegane ... co jest konieczne, biorąc pod uwagę, że testy zostały napisane przed funkcjonalnością.
Matthieu M.,
1
Testowanie czarnej skrzynki, ponieważ piszesz testy, zanim kod będzie istniał. Tester musi opracowywać czasochłonne testy automatyczne równolegle z pisaniem kodu programisty, aby był wydajny w małym zespole.
Jeśli kod jest już napisany, sugeruję, abyś poświęcił trochę czasu na szkicowanie zasięgu testu z czarnego pola, aby upewnić się, że masz trochę czasu na burzę mózgów, zanim zaśmiecisz mózg właściwym kodem. Możesz jednak przejść do białej skrzynki i spojrzeć na kod, zanim przejdziesz zbyt daleko wraz z faktycznymi testami, aby wyczuć obszary ryzykowne i nadać priorytet testom, które wcześniej przeprowadziłeś burzy mózgów (i uzupełnij je o nowe testy wymyślone przez patrząc na fragmenty kodu, które wydają się skomplikowane lub wątpliwe).
Ani. Staram się pisać dobre testy, używając mojego Right BICEP , pamiętając o PRAWIDŁOWYCH warunkach brzegowych, bez względu na kolejność, o jakiej się pomyślą. Są to oba akronimy zaproponowane w Pragmatic Unit Testing .
Moim celem jest skupienie się na pisaniu dobrych testów, a nie na tym, który kolor napisać jako pierwszy.
„Biały” i „czarny” nie są terminami testów jednostkowych, więc oczywiście nie martwisz się o to. Testy jednostkowe to de facto białe pudełko.
Ethel Evans,
@Ethel Evans: Z definicji nie są to testy białych skrzynek. Zdecydowana większość testów jednostkowych to testy białych skrzynek, ale nie jest to wymagane. Wszelkie testy odwzorowujące dziedzinę danych wejściowych na zakres wyników funkcji są testami jednostkowymi, ale nie muszą znać szczegółów implementacji.
Steven Evers,
0
Najpierw zrób to w białej skrzynce .
Po drugie przejdź do testowania czarnej skrzynki.
> Testowanie czarnej skrzynki
I. Tester powinien sprawdzić funkcjonalność aplikacji, takie jak pole tekstowe, przycisk opcji, pole listy, przycisk poleceń itp.
II. Tester powinien sprawdzić, czy aplikacja nie działa, takie jak logo, obraz, pisownia itp. Itp.
III. Tester powinien sprawdzić cały przepływ aplikacji.
Odpowiedzi:
Cokolwiek musi być najbardziej poprawne.
Poważnie, testowanie białych pól (tj. Testowanie wewnętrznych elementów kodu) powinno być idealnie przeprowadzane z testami jednostkowymi przez programistę, który napisał kod. Testy jednostkowe będą budowane z czasem, a część procesu kompilacji, abyśmy nie marnowali czasu słabego testera kodem, o którym wiemy, że nie działa tak, jak powinien. Testy jednostkowe stają się tym ważniejsze, im mniejszy jest twój zespół - szczególnie dlatego, że nie masz armii testerów, którzy mogliby rozwiać problemy.
Testowanie czarnej skrzynki (tj. Testowanie przez interfejs użytkownika / systemu) jest zwykle tym, co robi większość testerów.
Wszystkim testom należy nadać priorytet, jak ważna jest funkcja dla gotowego produktu. Jeśli misją jest zapewnienie narzędzia do wykonywania X, a produkt nie robi X, to duży problem.
źródło
czarny
Testowanie czarnej skrzynki w celu weryfikacji funkcji. Testowanie białych skrzynek w razie potrzeby, jeśli coś jest zepsute. Jeśli wszystkie testy czarnej skrzynki przejdą pomyślnie i zasięg jest dobry, testy białej skrzynki nie są konieczne.
źródło
Czarna skrzynka.
Komponenty białej skrzynki są zwykle zależne od komponentów czarnej skrzynki, więc najpierw chciałbym przetestować czarną skrzynkę, a następnie przejść do białej skrzynki.
źródło
Najpierw wykonujesz białe testy, myśląc jako programista / programista, aby upewnić się, że wszystko będzie dobrze. Następnie wykonujesz testy czarnej skrzynki, zwykle próbując myśleć, jakbyś był użytkownikiem końcowym, nie myśląc o wewnętrznej strukturze programu. Czasami musisz myśleć jak programista / programista, nawet jeśli wykonujesz czarne testy, ponieważ możesz testować wewnętrzny moduł napisany przez inną osobę i nie masz dostępu do kodu.
źródło
Jeśli chcesz mieć dobry cykl testowy, powinieneś mieć różne osoby wykonujące jedno i drugie :
Deweloper skoncentrowany głównie na testach białych skrzynek wie, co ostatnio zmieniło się w kodzie, które obszary są bardziej złożone (a zatem mogą się zepsuć) itp., I może odpowiednio skoncentrować wysiłki w tych obszarach, które najprawdopodobniej wprowadzą nowe wady.
Z drugiej strony tester kontroli jakości skoncentrowany na testowaniu czarnej skrzynki może łatwiej podejść do testowania jak użytkownik końcowy. Bez wewnętrznej wiedzy o kodzie mogą przyjąć nowe podejście i nie są stronnicze od wiedzy o tym, w jaki sposób wdrażane są różne części rozwiązania. Wyłapią błędy, które deweloper mógł przeoczyć, lub regresje spowodowane zmianami kodu, które przypadkowo zepsuły inne obszary aplikacji.
Aby odpowiedzieć na twoje pytanie, najpierw należy wykonać testy białej skrzynki. Ale naprawdę musisz mieć inną osobę wykonującą testy czarnej skrzynki, jeśli chcesz, aby była skuteczna.
źródło
Chciałbym zacząć od testowania czarnej skrzynki, a następnie użyć informacji o zasięgu kodu lub debugera, aby dowiedzieć się, co robię i przeanalizować, co się dzieje.
Ale prawdziwa odpowiedź to zależy . Prawdopodobnie zagłębię się w kod wcześniej (a nawet najpierw), jeśli przeprowadzam testy API, ale znacznie później, jeśli moim celem jest przyjrzenie się dużym scenariuszom od końca do końca.
źródło
Powiedziałbym, że najpierw testuje Black Box , po prostu dlatego, że jako zwolennik TDD testy są pisane zanim kod (lub box) istnieje.
Testy White Box (o ile rozumiem) są bardziej przydatne w sposobie debugowania.
źródło
Testowanie czarnej skrzynki, ponieważ piszesz testy, zanim kod będzie istniał. Tester musi opracowywać czasochłonne testy automatyczne równolegle z pisaniem kodu programisty, aby był wydajny w małym zespole.
Jeśli kod jest już napisany, sugeruję, abyś poświęcił trochę czasu na szkicowanie zasięgu testu z czarnego pola, aby upewnić się, że masz trochę czasu na burzę mózgów, zanim zaśmiecisz mózg właściwym kodem. Możesz jednak przejść do białej skrzynki i spojrzeć na kod, zanim przejdziesz zbyt daleko wraz z faktycznymi testami, aby wyczuć obszary ryzykowne i nadać priorytet testom, które wcześniej przeprowadziłeś burzy mózgów (i uzupełnij je o nowe testy wymyślone przez patrząc na fragmenty kodu, które wydają się skomplikowane lub wątpliwe).
źródło
Ani. Staram się pisać dobre testy, używając mojego Right BICEP , pamiętając o PRAWIDŁOWYCH warunkach brzegowych, bez względu na kolejność, o jakiej się pomyślą. Są to oba akronimy zaproponowane w Pragmatic Unit Testing .
Moim celem jest skupienie się na pisaniu dobrych testów, a nie na tym, który kolor napisać jako pierwszy.
źródło
Najpierw zrób to w białej skrzynce .
Po drugie przejdź do testowania czarnej skrzynki.
> Testowanie czarnej skrzynki
I. Tester powinien sprawdzić funkcjonalność aplikacji, takie jak pole tekstowe, przycisk opcji, pole listy, przycisk poleceń itp.
II. Tester powinien sprawdzić, czy aplikacja nie działa, takie jak logo, obraz, pisownia itp. Itp.
III. Tester powinien sprawdzić cały przepływ aplikacji.
Uwaga: Aby sprawdzić warunki dodatnie i ujemne.
źródło