Linuxy 1...2...3

SromotnikJadowity

Administrator

Dołączył: 2015-06-07

Liczba postów: 11

Kolos II

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ê.