Linuxy 1...2...3

SromotnikJadowity

Administrator

Dołączył: 2015-06-07

Liczba postów: 11

Kolos KOMBAJN

Kolos 1 :
Debugger modyfikuje kod źródłowy programu
- FAŁSZ – nie modyfikuje tylko sprawdza
Scentralizowane systemy zarządzania wersjami (np. Subversion) oparte są na architekturze P2P
- FAŁSZ – bo na klient-server / server-klient
Refactoring powoduje modyfikacje w funkcjonalności programu
- FAŁSZ – tylko eliminuje powtarzające się linijki, funkcjonalność ta sama
W systemie Subversion w wyniku wysłania nowej wersji określonego pliku do repozytorium całe repozytorium
uzyskuje nowy numer rewizji
- PRAWDA - numer rewizji oznacza numer kolejnego wykonania Commita

W kodzie występuje przynajmniej jeden błąd kompilacji
- PRAWDA - powinno być

int [] tab

Błąd występujący w kodzie może ujawnić się w trakcie wykonania programu
-PRAWDA - Wyciek pamięci ZAWSZE może ujawnić się w trakcie działania programu. Np. Gdy zabraknie Ci w
końcu RAM.

Wycieki pamięci powstają w wyniku alokowania przez program zbyt małej ilości pamięci
- FAŁSZ - fałsz bo wycieki powstają kiedy nie zwalniamy pamięci
Nowy programista, który dołącza do projektu przechowywanego w repozytorium zarządzanym przez system
Subversion powinien znać adres url repozytorium
- PRAWDA - jezeli nie zna to nie polaczy sie z nim
Dostęp do repozytorium zarządzanego przez Subversion nie jest możliwy z wykorzystaniem protokołu ftp
- FAŁSZ - dostęp do repozytorium jest tylko przez http i ssh
Generowanie dokumentacji technicznej projektu za pomocą Javadoc polega na przetworzeniu specjalnych komentarzy
umieszczonych w kodzie Java na strony www
- PRAWDA - Wykorzystuje się do tego adnotacje w komentarzach
Scentralizowane systemy zarządzania wersjami (np. Subversion) oparte są na architekturze klient-server
- PRAWDA - bo po prostu są oparte ;D
TortoiseSVN jest tekstowym klientem systemu Subversion
- FAŁSZ - bo jest graficzną nakładką
Wycieki pamięci są automatycznie naprawiane przez Valgrind
- FAŁSZ - Valgrind tylko wskaże nam wyciek
Repozytorium kodu źródłowego zarządzane przez system Subversion powinno zawierać zgodnie z zaleceniami katalog
trunk przechowujący alternatywne gałęzie projektu
- FAŁSZ - przechowuje tylko wersję roboczą
Breakpoint w debugger’e oznacza miejsce rozpoczęcia wykonywania programu
- FAŁSZ - nie rozpoczęcia tylko zakończenia przebiegu
Klient Subversion może być oferowany przez środowisko programistyczne IDE
- PRAWDA - jak najbardziej, NetBeans oferuje
W systemie Git klonowanie zdalnego repozytorium powoduje powstanie pełnej kopi repozytorium na lokalnej
maszynie
- PRAWDA - no tak
Repozytorium kodu źródłowego zarządzane przez system Subversion powinno zawierać zgodnie z zaleceniami katalog
BRANCHES przechowujący główną linię rozwojową kodu źródłowego projektu
- FAŁSZ - Katalog branches jest na poboczne gałęzie projektu
Przykładem refectoringu kodu jest dodanie nowej metody (nowej funkcjonalności) do istniejącej klasy
- FALSZ - nie tworzy nowej funkcjonalności tylko minimalizuje powtarzające się
Sprawdzenie zawartości repozytorium zarzadzanego przez Subversion jest możliwe bez konieczności tworzenia lokalnej
kopi repozytorium
- PRAWDA - tak, przez protokól SSH lub HTTP
W systemie Git operacj push służy do wysłania lokalnych zmian do zdalnej kopi repozytorium
- PRAWDA - tak sie dzieje dokładnie
Błąd występujący w kodzie zostanie wykryty przez Dr Memory
- FAŁSZ - Program się nie skompiluje, wiec nie zostanie utworzony plik wykonywalny (a Dr Memory sprawdza pliki
wykonywalne)
Refaktoring powoduje zmiany w kodzie źródłowym oprogramowania
- PRAWDA - minimalizuje powtarzające się
Historia zmian w Subversion dostarcza informacji na temat kto wprowadzał zmiany w danej rewizji
- PRAWDA - można sprwdzić to w logach
Sprawdzenie zawartości repozytorium zarzadzanego przez Subversion nie jest możliwe bez konieczności tworzenia
lokalnej kopi repozytorium
- FAŁSZ - bo jest możliwe przez protokół SSH lub HTTP
Nowy programista, który dołącza do projektu przechowywanego w repozytorium zarządzanym przez system
Subversion może obejrzeć zawartość repozytorim w przeglądarce internetowej jeżeli dostęp do repozytorium
odbywa się poprzez protokół http
- PRAWDA - przez protokół HTTP
Przykładem refectoringu kodu jest zastąpienie podobnych albo takich samych fragmentów kodu przez procedurę
- PRAWDA - dokładnie tak to działa
Wycieki pamięci zostaną wykryte podczas kompilacji kodu za pomocą kompilatora, np. g++
- FAŁSZ - kompilator nie wykrywa co innego gdyby odpalić valgrind –leak
Konflikt w systemie Subversion może powstać podczas wykonywania komendy checkout
- FAŁSZ - pobiera aktualna wersja wiec chyba bez konfliktu, konflikt może być przy commit jeżeli ktoś już
wcześniej zatwierdzi zanim Ty to zrobisz
Dostęp do repozytorium zarządzanego przez Subversion może odbywać się przez protokół http
- PRAWDA – i przez SSH też
W systemie Git operacja COMMIT przenosi zmiany z kopi lokalnej do zdalnego repozytorium
- PRAWDA - po to jest właśnie by przenieść dane do zdalnego repozytorium komp -> repozyrotium
Analiza programu za pomocą Dr Memory nie wymaga wcześniejszej kompilacji kodu
- FAŁSZ - Dr Memory sprwadza pliki wykonawalne, wiec musi wczesniej byc skompilowany
Valgrind nie zasygnalizuje czytania poza zakresem statycznie alokowanej tablicy
- PRAWDA - wg wykładu "valgrind nie wykrwya błędów związanych ze statycznie alokowanymi obszarami
pamięci"
Jedną z możliwości debugger'a GDB jest wyświetlenie aktualnego stosu wywołań funkcji
- PRAWDA - pozwala na to komendą -bt
Środowisko wytwórcze Eclipse jest środowiskiem modułowym, rozszerzalnym poprzez plugin'y
- PRAWDA - mozna rozszerzac instalując dodatkowe pluginy
Debugger jest standardowym wyposażeniem większości środowisk programistycznych
- PRAWDA - większośc środowisk go posiada
Polecenie diff w systemie Subversion pozwala na porównanie kopi lokalnej i kopi znajdującej się w repozytorium
określonego pliku
- PRAWDA - tak to działa
TortoiseSVN jest graficznym klientem systemu Git
- FAŁSZ - TortoiseSVN jest gaficznym klientem SVN a nie GIT
Debugger może zostać uruchomiony mimo istnienia błędów kompilacji
- PRAWDA - po to jest
Operacja commit w systemie Subversion przenosi zmiany z repozytorium zdalnego do lokalnej kopi użytkownika
- FAŁSZ – przenosi z lokalnej do repo, komp -> repo a nie odwrotnie, do tego służy update lub /co/
Historia zmian w Subversion dostarcza informacji na temat plików zmodyfikowanych w poszczególnych rewizjach
- PRAWDA - TAK w logach
Historia zmian w Subversion dostarcza informacji na temat używanego przez użytkownika klienta SVN
- FAŁSZ - nie umieszcza takiej informacji, umieszcza jedynie datę, komentarz i co zostało zmodyfikowane

svnadmin create repo - tworzy repozytorium

svn mkdir trunk branches tags – tworzy 3 katalogi, sa niezbędne !

svn ci -m "blabla" – wystawia komentarz do potwierdzenia akcji

svn list – wyswietla zawartość repozytorium

svn co <ścieżka> - sprawdzasz zawartośc repozytorium i aktualizujesz na swoim kompie

svn update – zaktualizowanie projektu na kompie przez najnowsza wersje z repozytorium, można wskazać konkretny
numer rewizji(-r revision czyli wersji) która chcemy pobrać

System GIT - rozproszone repozytorium, każdy ma pełną kopię repozytorium, KAŻDY może być centralnym serwerem
git commit -m "Dodano" - potwierdź ale na swoim kompie
git push origin master - aktualizuj na serverze
r run - wypisanie linii do wystapienia pierwszego bledu (jego objaw)
l list - kontekst linii na której się zatrzymał
bt - stos wywołań do czasu wystapienia błędu
q - opuszczenie debuggera GDB
g++ -g toupper.cpp -o toupper – kompilacja z debuggerem

Kolos 2:
1. F Aby program instalacyjny zbudowany w œrodowisku MS Visual Studio sprawdza³, czy komputer na którym instalowana jest aplikacja posiada odpowiedni rozmiar pamiêci RAM, nale¿y sformu³owaæ w³aœciwy warunek w edytorze Custom Actions.

2. F Aby wprowadziæ w systemie bugzilla nowe zg³oszenie o b³êdzie nie trzeba posiadaæ konta u¿ytkownika

3. T Aby wykonaæ profilowanie nale¿y najpierw skompilowaæ program, a nastêpnie uruchomiaæ go wiele razy tak aby pokryta zosta³a jak najwiêksza czêœæ kodu.

4. F Blok kodu, który znacz¹co wp³ywa na trudnoœci podczas instalacji oprogramowania nazywany jest w¹skim gard³em aplikacji (ang. bottle neck).

5.T B³¹d w systemie Bugzilla mo¿e zmieniaæ swoje statusy tylko zgodnie z cyklem ¿ycia b³êdu.

6. T Bugzilla mo¿e byæ wykorzystywana do zarz¹dzania b³êdami w systemie informatycznym, jak równie¿ wymaganiami, poprawkami i zmianami.

7. F Bugzilla jest narzêdziem s³u¿¹cym do profilowania aplikacji.

8. T Celem testów akceptacyjnych jest sprawdzenie czy oprogramowanie jest gotowe i mo¿e byæ przekazane u¿ytkownikowi.

9. F Cykl ¿ycia b³êdu okreœla stan w jakim b³¹d siê aktualnie znajduje oraz jego historiê.

10. F Dokumentacja u¿ytkownika oprogramowania powinna zawieraæ udokumentowany kod.

11. T Doxygen nie potrafi aktualizowaæ wygenerowanej dokumentacji interpretuj¹c tylko zmienione pliki.

12. F Doxygen nie pozwala na generowanie dokumentacji technicznej dla aplikacji napisanej w jêzyku C++.

13. F Doxygen pozwala na generowanie dokumentacji technicznej tylko dla aplikacji napisanej w jêzyku Java.

14. F Doxygen umo¿liwia tworzenie dokumentacji tylko pojedynczych plików.

15. F Doxygen wymaga u¿ywania znaczników HTML do opisu komentarzy.

16. F G³ównym celem optymalizacji czasowej oprogramowania jest zmniejszenie zapotrzebowania na zasoby pamiêciowe.

17. T Graf wywo³añ funkcji tworzony przez profilery pozwala wykryæ funkcje, które same w sobie nie zajmuj¹ du¿o czasu wykonania natomiast wywo³ywane z nich funkcje stanowi¹ w¹skie gard³o aplikacji.

18. T Instrukcja budowy pakietu rpm powinna byæ zapisana w pliku spec.

19. F Javadoc posiada bardziej rozbudowane formaty wejœciowe i wyjœciowe ni¿ Doxygen.

20. F Jedna instancja systemu Bugzilla mo¿e obs³ugiwaæ tylko jeden produkt (np. aplikacjê).

21. T Komentarz interpretowany przez Doxygen musi wyst¹piæ bezpoœrednio przed deklaracj¹ czy definicj¹ pliku, klasy, itd.

22. F Makro %_topdir w pliku .rpmmacros definiuje œcie¿kê do katalogu z tymczasowymi plikami tworzonymi w trakcie budowy pakietu rpm.

23. F Manualna instrumentacja przeprowadzana w celu profilowania aplikacji polega na rêcznym podliczaniu charakterystyk czasu wykonania danych fragmentów kodu.

24. F Microsoft Test Manager nie mo¿e byæ wykorzystany do analizy aplikacji w innych jêzykach tj. PHP, Java czy Delphi.

25. T Microsoft Test Manager nie wymaga posiadania kodu Ÿród³owego.

26. T NetBeans Profiler oprócz profilowania u¿ycia procesora oraz pamiêci pozwala na œledzenie aktywnoœci poszczególnych w¹tków aplikacji.

27. F Parametr Resolution okreœlaj¹cy sposób rozwi¹zania zg³oszenia o b³êdzie w systemie Bugzilla mo¿e przyjmowaæ wartoœci New, Assigned i Closed.

28. T Parametr Resolution okreœlaj¹cy sposób rozwi¹zania zg³oszenia o b³êdzie w systemie Bugzilla mo¿e przyjmowaæ miêdzy innymi wartoœci Fixed, Duplicate, Invalid.

29. F Planowanie testów funkcjonalnych umo¿liwia Microsoft Test Manager oraz Microsoft Visual Studio.

30. F Plik konfiguracyjny Doxygen mo¿na wygenerowaæ tylko poprzez aplikacjê Doxywizard.

31. T Podczas tworzenia testu manualnego w Microsoft Test Manager mo¿liwe jest zdefiniowanie zmiennych oraz wartoœci jakie powinny przyjmowaæ.

32. F Podczas tworzenia testu manualnego w Microsoft Test Manager nie jest mo¿liwe zdefiniowanie zmiennych oraz wartoœci jakie powinny przyjmowaæ.

33. T Profil p³aski profilera GNU GProf nie pozwala obserwowaæ czasów wykonywania funkcji 'potomków' i 'rodziców'.

34. F Profilowanie aplikacji nie wymaga analizy otrzymanych danych czasowych.

35. F Profilowanie aplikacji polega na statycznej analizie oprogramowania.

36. T Profilowanie aplikacji nie polega na statycznej analizie oprogramowania.

37. T Profilowanie aplikacji równoleg³ych pozwala œledziæ proces wymiany komunikatów pomiêdzy procesorami/procesami.

 

39. T Profilowanie aplikacji wykonywane jest w celu zoptymalizowania aplikacji zarówno pod wzglêdem czasowym jak i pamiêciowym.

40. F Profilowanie na poziomie linii kodu umo¿liwia dok³adne wskazanie b³êdu kompilacji.

41. T Profiler IBM Rational Quantify pozwala na graficzne i tekstowe porównywanie wydajnoœci kolejnych wersji oprogramowania (czyli jaki wp³yw mia³y wprowadzone poprawki).

42. F Profiler IBM Rational Quantify pozwala tylko na tekstowe (lista funkcji) porównywanie wydajnoœci kolejnych wersji oprogramowania (czyli jaki wp³yw mia³y wprowadzone poprawki).

43. F Profilery aplikacji stworzonych w zarz¹dzanych jêzykach programowania nie pozwalaj¹ na profilowanie zu¿ywanej pamiêci.

44. T Profilery bazuj¹ce na instrumentacji zbieraj¹ informacje na temat wydajnoœci aplikacji poprzez wstawiane dodatkowych instrukcji do kodu.

45. F Profilery statystyczne wykorzystuj¹ zdarzenia (ang. events), które przekazywane s¹ jako procedury zwrotne.

46. F Program instalacyjny zbudowany w œrodowisku MS Visual Studio zawsze instaluje aplikacjê w domyœlnej lokacji.

47. F Program instalacyjny zbudowany w œrodowisku MS Visual Studio zawsze tworzy skrót do instalowanego programu na pulpicie.

48. F Raporty generowane przez profilery pokazuj¹ miejsca wyst¹pienia b³êdów z pamiêci¹ (np. brak dealokacji).

49. F S³owo kluczowe @param mo¿e byæ u¿yte jako link do istniej¹cych funkcji, plików, klas oraz URLi.

50. T S³owo kluczowe @see mo¿e byæ u¿yte jako link do istniej¹cych funkcji, plików, klas, oraz URLi.

51. F Œrodowisko MS Visual Studio pozwala na tworzenie programów instalacyjnych tylko dla aplikacji zbudowanych w tym œrodowisku.

52. T Œrodowisko MS Visual Studio pozwala na tworzenie programów instalacyjnych dla aplikacji stworzonych w dowolnej technologii.

53. T Testowanie integracyjne s³u¿y do sprawdzenia czy komponenty tworzonego oprogramowania wspó³pracuj¹ ze sob¹.

54. F W generatorze Javadoc s³owa kluczowe w komentarzu nale¿y poprzedziæ \ lub @

55. T W generatorze Javadoc s³owa kluczowe w komentarzu nale¿y poprzedziæ znakiem @.

56. T W NetBeans Profiler w wyniku analizy wydajnoœci CPU uzyskujemy informacje o czasie spêdzonym przez analizowan¹ aplikacjê na wykonywaniu poszczególnych jej funkcji.

57. T W Microsoft Test Manager nie mo¿na pisaæ lub modyfikowaæ kodu Ÿród³owego aplikacji.

58. F W systemie Bugzilla b³¹d o statusie Resolved i rozdzielczoœci (Resolution) Duplicate oznacza, ¿e zg³oszenie zosta³o uznane za niepoprawne.

59. T W systemie Bugzilla status b³êdu informuje o aktualnym etapie obs³ugi zg³oszenia.

60. T Warunek sprawdzaj¹cy przed rozpoczêciem procesu instalacji, czy komputer wyposa¿ony jest w co najmniej 1GB pamiêci RAM, w programie instalacyjnym zbudowanym w œrodowisku MS Visual Studio powinien byæ sformu³owany nastêpuj¹co: PhysicalMemory>=1024.

62. F Warunek sprawdzaj¹cy przed rozpoczêciem procesu instalacji, czy komputer wyposa¿ony jest w co najmniej 2GB pamiêci RAM, w programie instalacyjnym zbudowanym w œrodowisku MS Visual Studio powinien byæ sformu³owany nastêpuj¹co: RAM>=2g

63. T Wprowadzaj¹c zg³oszenie o b³êdzie w systemie Bugzilla nale¿y okreœliæ miêdzy innymi œrodowisko (Hardware, OS), w którym b³¹d mia³ miejsce.

64. F Wprowadzaj¹c zg³oszenie o b³êdzie w systemie Bugzilla nale¿y okreœliæ Ÿród³o pozyskania aplikacji (Shop, Website), w której b³¹d mia³ miejsce.

65. F Wymagania funkcjonalne oprogramowania okreœlaj¹ ograniczenia systemu wynikaj¹ce z potrzeb u¿ytkowników oraz z ograniczeñ bud¿etowych i strategii firmy etc.

66. T Za pomoc¹ polecenia rpmbuild zaleca siê zbudowanie pakietu instalacyjnego rpm wed³ug specyfikacji okreœlonej w odpowiednim pliku spec.

67. T Zalet¹ profilerów statystycznych jest brak narzutu zwi¹zanego z dodatkowym kodem w profilowanej aplikacji.

68. T Zapytania umo¿liwiaj¹ce sprawdzenie wyników testów uruchamiane s¹ w zak³adce track programu Microsoft Test Manager.

69. F Zg³oszenie o b³êdzie wprowadzone w systemie Bugzilla trafia do administratora systemu.

70. T Zg³oszenie o b³êdzie wprowadzone w systemie Bugzilla trafia do osoby odpowiedzialnej (Assigned to) za komponent okreœlony w zg³oszeniu.

71. F Znacznik @param w Javadoc s³u¿y do opisu atrybutów wystêpuj¹cych w komentowanej klasie.

72. T Znacznik @return w Javadoc s³u¿y do opisu wyniku zwracanego przez komentowan¹ metodê.