Giải ngân hàng câu hỏi đảm bảo chất lượng phần mềm PTIT

Giải ngân hàng câu hỏi SQA ptit giá rẻ cho sinh viên, giải đầy đủ các bài trong đề cương của cô ngọc gửi cho anh em ôn tập trong kỳ thi vấn đáp sắp tới, giúp bạn tự tin vượt qua kỳ thi mà không có bất kỳ nỗi sợ hãi nào

Câu hỏi 1.1: Lỗi phần mềm gì? Nguyên nhân gây lỗi phần mềm? - Lỗi phần mềm(Software Error) phần code sai lôi cú pháp, logic hoăc lỗi phân tích, thiết kế - Nguyên nhân gây lỗi: Lỗi định nghĩa yêu cầu Quan hệ Client-developer tồi Sai phạm có chủ ý với yêu cầu phần mềm Lỗi thiết kế logic Lỗi lập trình Khơng tn thủ hướng dẫn viết tài liệu code Thiếu sót trình kiểm thử Lỗi giao diện người dùng thủ tục Lỗi tài liệu Câu hỏi 1.4: Kể độ đo đặc trưng chất lượng McCall? Giải thích nội dung nó? McCall có 11 tiêu chí; chia thành nhóm – Tiêu chí vận hành sản phẩm + Tính đắn – Correctness : Đặc tả độ sác, tính tồn vẹn, thời gian outputs + Tính tin cậy – Reliability : Định tỉ lệ lỗi cho chức hệ thống + Tính hiệu - Efficiency : Tài ng phần cứng cần để thực chức phần mềm + Tính tồn vẹn – Integrity : Bảo mật hệ thống, ngăn truy cập trái phép + Tính khả dụng - Usability : Tính dễ học, dễ dùng, hiệu – Tiêu chí sửa đổi sản phẩm + Tính bảo trì – Maintainability : Mức cơng sức cần đề tìm ngun nhân+ sửa + xác nhận sửa đc failures.(Liên quan đến cấu trúc modul, kiến trúc , thiết kế tài liệu) + Tính linh hoạt – Flexibility : Bảo trì cải tiến dễ dàng + Tính kiểm thử – Testability : Có lưu lại kq trung gian để hỗ trợ test? Có tạo file log, backup? – Tiêu chí chuyển giao sản phẩm + Khả di động – Portability : Cài môi trường (phần cứng khác, hệ điều hành khác,…) mà trì mơi trường cũ + Khả tái sử dụng – Reusability : Có thể tái sử dụng phần phần mềm cho ứ/dụng khác + Khả tương thích – Interoperability : phần mềm có cần interface với hệ thống có Câu hỏi 1.6: Trình bày kỹ thuật Walkthrough • Walkthrough: Kỹ thuật đánh giá khơng thức(nên ko có ng quản lý, giám đốc dự án) Những người tham gia phải xem tài liệu trước họp (ít vài ngày) Tác giả giải thích tài liệu/ sản phẩm cho nhóm (tác giả, điều phối viên, giám định viên, đại diện ng dùng, chuyên gia bảo trì) + Mọi người đặt câu hỏi cho ý kiến bổ sung số lĩnh vực để bảo đảm chất lượng kỹ thuật tài liệu sản phẩm + Buổi giám định xảy vào lúc đâu việc phát triển sản phẩm phần mềm Mục đích họp giám định để tìm lỗi nhanh, ko tìm giải pháp Sau giám định, tác giả phải làm lại sửa lỗi Câu hỏi 1.7: Trình bày kỹ thuật Inspection • Inspection: Kỹ thuật đánh giá thức Tài liệu, sản phẩm người tác giả trực tiếp liên quan(Ngươi kiểm duyệt, tác giả, tester, thiết kế, coder) kiểm tra cách chi tiết để phát lỗi, vi phạm tiêu chuẩn, vấn đề khác (nếu có) + Về bản, tổ chức thực chặt chẽ walkthrough Vai trò người tham gia phân định rõ ràng Tài liệu chuẩn bị cho việc xem xét chuẩn bị trước chu đáo + Quá trình duyệt thảo bắt đầu sau giai đoạn code unit test Sau buổi họp lỗi tìm đc đc sửa lại, đem duyệt thảo lại đạt tiêu chuẩn kết thúc q trình Câu hỏi 1.10: Trình bày tóm tắt SQA tiêu chuẩn IEEE std1028 Chất lượng phần mềm là: (1) Mức độ mà hệ thống, thành phần, hay tiến trình đáp ứng đặc tả yêu cầu (2) Mức độ mà hệ thống, thành phần, hay tiến trình đáp ứng nhu cầu/mong muốn khách hàng/người dùng - Lập kế hoạch cài đặt cách hệ thống! - Chỉ tiến độ và truyền tải tin cậy phần mềm phát triển - Với tiến trình phát triển phần mềm phương pháp luận; cách thức để làm; - Với đặc tả yêu cầu kỹ thuật phải có - SQA bao gồm tiến trình phát triển bảo trì dài hạn Do vậy, ta cần xem xét vấn đề chất lượng cho phát triển bảo trì SQA Hành động SQA phải bao gồm lập lịch lập ngân sách - SQA phải vấn đề nảy sinh không đáp ứng ràng buộc thời gian– bỏ bớt chức năng? Ràng buộc ngân sách thoả hiệp nguồn lực phân bổ bị không đủ cho phát triển và/hoặc bảo trì SQA là: "Tập hoạt động có hệ thống cung cấp chứng khả qui trình phần mềm tạo sản phẩm phần mềm khớp với việc sử dụng Do hội tụ SQA giám sát liên tục tồn thể vịng đời phát triển phần mềm để đảm bảo chất lượng sản phẩm chuyển giao Điều yêu cầu giám sát qui trình sản phẩm Trong đảm bảo qui trình, SQA cung cấp việc quản lí với phản hồi khách quan liên quan tới tuân thủ kế hoạch, thủ tục, chuẩn phân tích chấp thuận Các hoạt động đảm bảo sản phẩm hội tụ vào mức độ thay đổi chất lượng sản phẩm bên pha vòng đời, yêu cầu, thiết kế, viết mã kế hoạch kiểm thử Mục tiêu nhận diện khử bỏ khiếm khuyết tồn vịng đời sớm được, giảm chi phí kiểm thử bảo trì Câu hỏi 1.11: Trình bày mức tiêu chuẩn CMM? Khởi đầu: Quy trình sản xuất phần mềm có đặc điểm tự phát, thành cơng dựa vào nỗ lực cá nhân tài Lặp: Các quy trình quản lý dự án thiết lập để kiểm soát chi phí, kế hoạch khối lượng hồn thành Ngun lý quy trình hình thành nhằm đạt thành công phần mềm tương tự Xác lập: Quy trình phần mềm cho hoạt động quản lý sản xuất tài liệu hóa, chuẩn hóa tích hợp vào quy trình phần mềm chuẩn nhà sản xuất Các dự án sử dụng quy trình phần mềm hiệu chỉnh phê duyệt dựa quy trình chuẩn nhà sản xuất để phát triển bảo trì sản phẩm phần mềm Kiểm sốt: Thực đo lường chi tiết quy trình phần mềm chất lượng sản phẩm Cả quy trình sản xuất sản phẩm phần mềm kiểm soát theo định lượng Tối ưu: Quy trình liên tục cải tiến dựa ý kiến phản hồi từ việc sử dụng quy trình, thí điểm ý tưởng quản lý công nghệ - CMMI viết tắt cho Capability Maturity Model Integration - Mơ hình trưởng thành lực tích hợp - khn khổ cho cải tiến qui trình phần mềm Nó dựa khái niệm thực hành tốt kĩ nghệ phần mềm giải thích kỉ luật mà cơng ty dùng để cải tiến qui trình họ - CMM bao gồm levels 18 KPAs (Vùng quy trình quan trọng - Key Process Area) Level 1: Khởi đầu (lộn xộn, khơng theo chuẩn) khơng có KPAs Level 2: Lặp (quản lý dự án, tn thủ quy trình) có KPAs Level 3: Xác lập (thể chế hóa) có KPAs Level 4: Kiểm sốt (định lượng) có KPAs Level 5: Tối ưu (cải tiến quy trình) có KPAs Level 1: Initial(Ban đầu): Level bước khởi đầu CMM, doanh nghiệp, cơng ty phần mềm, cá nhóm, cá nhân đạt Ở lever CMM chưa u cầu tính Ví dụ: khơng u cầu quy trình, khơng u cầu người, miễn cá nhân, nhóm, doanh nghiệp… làm phầm mềm đạt tới CMM Đặc điểm mức 1: - Hành chính: Các hoạt động lực lượng lao động quan tâm hàng đầu thực cách vỗi vã hấp tấp Không thống nhất: Đào tạo quản lý nhân lực nhỏ lẻ chủ yếu dựa vào kinh nghiệp cá nhân Quy trách nhiệm: Người quản lý mong phận nhân điều hành kiểm sóat hoạt động lực lượng lao động Quan liêu: Các hoạt động lực lượng lao động đáp ứng mà không cần phân tích ảnh hưởng Doanh số thường xuyên thay đổi: Nhân viên không trung thành với tổ chức Level 2: Repeatable (được quản lý): Mục tiêu(Goal): hoạt động đề xuất dự án phần mềm phải lên kế hoạch viết tài liệu đầy đủ Có KPA (Key Process Area) bao gồm sau - Requirement Management ( Lấy yêu cầu khách hàng, quản lý yêu cầu đó) - Software Project Planning ( Lập kế hoạch cho dự án) - Software Project Tracking (Theo dõi kiểm tra tiến độ dự án) - Software SubContract Managent ( Quản trị hợp đồng phụ phần mềm) - Software Quality Assurance (Đảm bảo chất lượng sản phẩm) - Software Configuration Management (Quản trị cấu hình sản phẩm=> yêu cầu khách hàng không) Các KPA( Key Process Areas) trọng tới thành phần sau : + Chế độ đãi ngộ + Đào tạo + Quản lý thành tích + Phân cơng lao động + Thông tin giao tiếp + Môi trường làm việc Để đạt Level người quản lý phải thiết lập nguyên tắc quản lý hoạt động diễn Họ có trách nhiệm quản lý đội ngũ Level 3: Defined (được định ra) - + + + + + Các vùng tiến trình chủ chốt mức nhằm vào hai vấn đề dự án tổ chức, tổ chức (cơng ty) tạo nên cấu trúc hạ tầng thể chế trình quản lý sản xuất phần mềm hiệu qua tất dự án KPA trọng tới yếu tố sau : Văn hóa cá thể Cơng việc dựa vào kỹ Phát triển nghiệp Hoạch định nhân Phân tích kiến thức kỹ Để đạt level người quản lý phải biến đổi cải tiến hoạt động diễn ra, cải tiến môi trường làm việc Level 4: Managed (được quản lý định lượng) Các vùng tiến trình chủ yếu mức tập trung vào thiết lập hiểu biết định lượng trình sản xuất phần mềm sản phẩm phần mềm xây dựng Đó Quản lý trình định lượng (Quantitative Process Management) Quản lý chất lượng phần mềm (Software Quality Management) Các KPA level trọng tới: + + + + + Chuẩn hóa thành tích tổ chức Quản lý lực tổ chức Công việc dựa vào cách làm việc theo nhóm Xây dựng đội ngũ chuyên nghiệp Cố vấn Để đạt level phải đo lường chuẩn hóa Đo lường hiệu đáp ứng cơng việc, chuẩn hóac phát triển kỹ năng, lực cốt lõi Level trọng vào người đứng đầu cơng ty, họ có khả quản lý công việc Level 5: Optimising (tối ưu) Các vùng tiến trình chủ yếu mức bao trùm vấn mà tổ chức dự án phải nhắm tới để thực hồn thiện q trình sản xuất phần mềm liên tục, đo đếm Đó Phịng ngừa lỗi (Defect Prevention), Quản trị thay đổi công nghệ (Technology Change Management), Quản trị thay đổi trình (Process Change Management) Để đạt Level doanh nghiệp phải liên tục cải tiến hoạt động tổ chức, tìm kiếm phương pháp đổi để nâng cao lực làm việc lực lượng lao động tổ chức, hỗ trợ nhân phát triển sở trường chuyên môn Chú trọng vào việc quản lý, phát triển lực nhân viên, Huấn luyện nhân viên trở thành chuyên gia Câu hỏi 1.12: Mục tiêu SQA gì? Các hoạt động đảm bảo chất lượng phần mềm hoạt động nào? - Đảm bảo chất lượng phần mềm hoạt động nhằm mục tiêu sản xuất phần mềm có chất lượng cao o Mục tiêu hoạt động SQA phát triển phần mềm  Đảm bảo mức độ tin cậy chấp nhận phần mềm tuân thủ yêu cầu kỹ thuật chức  Đảm bảo mức độ tin cậy chấp nhận phần mềm tuân thủ yêu cầu quản lý thời gian tài  Khởi đầu quản lý hoạt động để phát triển phần mềm hoạt động SQA cải thiện đạt hiệu cao o Mục tiêu hoạt động SQA bảo trì phần mềm  Đảm bảo mức độ tin cậy chấp nhận hoạt động bảo trì phần mềm tuân thủ yêu cầu kỹ thuật chức  Đảm bảo mức độ tin cậy chấp nhận hoạt động bảo trì phần mềm tuân thủ yêu cầu quản lý thời gian tài  Khởi đầu quản lý hoạt động để bảo trì phần mềm hoạt động SQA cải tiến hiệu - Có hoạt động chính: (1) Áp dụng công nghệ kĩ thuật hiệu (phương pháp, công cụ) (2) Tiến hành rà sốt kỹ thuật thức (3) Thực kiểm thử nhiều tầng (4) Tuân theo chuẩn phát triển (5) Kiểm soát tài liệu PM thay đổi chúng (6) Thực đo lường (7) Báo cáo bảo quản lý báo cáo Câu hỏi 1.13: Khảo sát nhu cầu SQA gồm nội dung gì? Nhằm trả lời câu hỏi gì? - Gồm ba nội dung nhằm trả lời ba câu hỏi + Kiểm kê sách SQA: sách, thủ tục, chuẩn có pha phát triển? + Đánh giá vai trò kỹ nghệ phần mềm, bảo đảm chất lượng tổ chức có quyền lực đến đâu? + Đánh giá mối quan hệ SQA: Giao diện chức SQA với đơn vị khác nào? Với người thực rà sốt kỹ thuật thức, quản lý cấu hình thử nghiệm - Nếu có nhu cầu SQA cần phải tiến hành đánh giá cẩn thận quy tắc bỏ phiếu Câu hỏi 1.15: Ca kiểm thử gì? Mục tiêu thiết kế ca kiểm thử? - Một ca kiểm thử (test case) công nghệ phần mềm tập hợp điều kiện hay biến để theo thử nghiệm xác định xem ứng dụng hệ thống phần mềm làm việc cách xác hay khơng - Mục đích: + Muốn tìm nhiều sai với nỗ lực thời gian nhỏ + Chứng minh tồn lỗi + Không chứng minh khơng có lỗi Câu hỏi 1.16: Kiểm thử hộp trắng gì? Nêu đặc trưng nó? - Là hình thức kiểm thử mà kiểm thử viên biết cấu trúc bên chương trình (mã nguồn, xử lý liệu, …) Việc kiểm thử dựa phân tích cấu trúc bên thành phần/hệ thống Kiểm tra mã nguồn chi tiết thủ tục (thuật toán), đường logic (luồng điều khiển), trạng thái chương trình (dữ liệu) - Đặc trưng: + Kiểm thử hộp trắng dựa vào thuật giải cụ thể, vào cấu trúc liệu bên đơn vị phần mềm cần kiểm thử để xác địnhđơn vị phần mềm có thực không + Người kiểm thử hộp trắng phải có kỹ năng, kiến thức định để hiểu chi tiết đoạn code cần kiểm thử + Thường tốn nhiều thời gian công sức mức độ kiểm thử nâng lên cấp kiểm thử tích hợp hay kiểm thử hệ thống + Do kỹ thuật chủ yếu dùng để kiểm thử đơn vị Trong lập trình hướng đối tượng, kiểm thử đơn vị kiểm thử tác vụ class chức + Có hoạt động kiểm thử hộp trắng: Kiểm thử luồng điều khiển kiểm thử dòng liệu Câu hỏi 1.17: Kiểm thử hộp đen gì? Nêu đặc trưng nó? - Kiểm thử hộp đen (Black-box Testing): Là hình thức kiểm thử mà kiểm thử viên không cần biết đến cách thức hoạt động, mã nguồn, xử lý liệu bên thành phần/hệ thống Công việc cần làm nhập liệu đầu vào (input) kiểm tra kết trả có mong muốn hay không - Đặc trưng: + Cơ sở: đặc tả, điều kiện vào/ra cấu trúc liệu + Nhằm thuyết minh chức phần mềm đủ vận hành + Thực phép thử qua giao diện + + + + + + Thường phát lỗi đặc tả yêu cầu, thiết kế Dễ dàng thực Chi phí thấp Được sử dụng để kiểm thử phần mềm mức: modul, tích hợp, hàm, hệ thống Đơn giản hoá kiểm thử mức độ đánh giá khó kiểm thử Khó đánh giá giá trị chưa kiểm thử hay khơng + Ít ý tới cấu trúc logic nội Câu hỏi 1.18: Có loại công cụ tự động trợ giúp kiểm thử, mô tả nội dung loại? - Công cụ kiểm thử tự động (Testing Tools) chia thành nhóm chính: Design, GUI(Graphical User Interface), Load and Performance, Management, Implementation, Evaluation (Sự đánh giá), Static Analysis (Phân tích tĩnh)và ngồi cịn có : Defect Tracking, Websites Miscellaneous(Hỗn Hợp) Test Design Tools + Các công cụ giúp bạn định “test” cần để thực thi Kiểm thử liệu kiểm thử trưởng hợp (Test data and test case) sinh ra(generators) + Test design tools giúp tạo “Test case”, số đầu vào test tối thiểu (là phần test case) + Có tổng cộng khoảng 15 Tools GUI Test Tools + Các công cụ tự động thực thi kiểm thử (Test) cho “products” với giao diện người dùng Graphic Công cụ tự động kiểm tra Client/Server, bao gồm load testers + GUI Testing trinh kiểm thử giao diện người dùng ứng dụng phát chức xác ứng dụng Load and Performance Tools + Load testing trình đặt nhu cầu hệ thống thiết bị đo phản ứng Load testing thực để xác định hành vi hệ thống theo điều kiện tải bình thường mong đợi Nó giúp để xác định khả hoạt động tối đa ứng dụng vướng mắc xác dịnh yếu tố gây suy thoái + Performance testing thực để xác định hệ thống có đáp ứng yêu cầu ổn định khối cơng việc cụ thể Nó phục vụ việc kiểm tra, đo lường, xác minh chất lượng thuộc tính hệ thống, chẳng hạn khả mở rộng, độ tin cậy sử dụng tài nguyên Test Management Tools + Test managerment tools sử dụng để lưu trữ thơng tin q trình kiểm thử làm việc nào, kế hoạch hoạt động kiểm thử báo cáo tình hình hoạt động đảm bảo chất lượng phần mềm Test Implementation Tools + Dụng cụ khác giúp bạn thực kiểm tra Ví dụ, cơng cụ tự động tạo thói quen cịn sơ khai đây, cơng cụ mà cố gắng để làm cho thất bại rõ ràng (máy phát điện khẳng định, vv) Test Evaluation Tools + Công cụ giúp bạn đánh giá chất lượng kiểm tra bạn Các công cụ bảo hiểm mã Static Analysis Tools Công cụ phân tích chương trình mà khơng cần chạy chúng Số liệu công cụ rơi vào thể loại Câu hỏi 1.19: Đồ thị luồng điều khiển gồm yếu tố nào? Đồ thị luồng điều khiển dùng để làm gì? - Đồ thị dịng điều khiển đồ thị có hướng gồm đỉnh tương ứng với câu lệnh/nhóm câu lệnh cạnh dịng điều khiển câu lệnh/nhóm câu lệnh Những yếu tố đồ thị luồng điều khiển: + Điểm bắt đầu đơn vị chương trình + Khối xử lý chứa câu lệnh khai báo tính tốn + Điểm định ứng với câu lệnh điều kiện khối lệnh rẽ nhánh lặp + Điểm nối ứng với câu lệnh sau lệnh rẽ nhánh + Điểm kết thúc ứng với điểm kết thúc đơn vị chương trình - Mục tiêu phương pháp kiểm thử luồng điều khiển đảm bảo đường thi hành đơn vị phần mềm cần kiểm thử chạy Rất tiếc thực tế, công sức thời gian để đạt mục tiêu lớn, đơn vị phần mềm nhỏ Câu hỏi 1.20: Đồ thị luồng liệu gồm yếu tố nào? Đồ thị luồng liệu dùng để làm gì? Định nghĩa:Đồ thị dịng liệu chương trình/đơn vị chương trình đồ thị có hướng G = , với: - N tập đỉnh tương ứng với câu lệnh def c-use biến sử dụng đơn vị chương trình Đồ thị G có hai đỉnh đặc biệt đỉnh bắt đầu (tương ứng với lệnh def biến tham số) đỉnh kết thúc đơn vị chương trình - E tập cạnh tương ứng với câu lệnh p-use biến Một số khái niệm: Def: câu lệnh gán giá trị cho biến Undef: khai báo biên chưa cấp giá trị cho Use: câu lệnh sử dụng biến (tính tốn kiểm tra điều kiện) C-use: câu lệnh sử dụng biến để tính tốn giá trị biến khác P-use: câu lệnh sử dụng biến biểu thức điều kiện (câu lệnh rẽ nhánh, lặp, ) Lý cần kiểm thử dịng liệu: • Cần chắn biến gán giá trị, tức phải xác định đường biến từ điểm bắt đầu nơi định nghĩa đến điểm mà biến sử dụng • Ngay gán giá trị cho biến giá trị sinh chưa xác tính tốn biểu thức điều kiện sai (biến sử dụng sai) Câu hỏi 1.21: Nêu loại điều kiện cấu trúc điều khiển cho ví dụ? Có loại sai điều kiện kiểm thử? - Điều kiện logic cấu trúc điều khiển: + Điều kiện đơn: biến logic (Boolean) biểu thức quan hệ, có tốn tử NOT (!) đứng trước, VD: NOT (a>b) + Biểu thức quan hệ: biểu thức có dạng E1 E2, E1, E2 biểu thức số học toán tử quan hệ dạng sau: =, = =, !=, ví dụ, a > b+1 + Điều kiện phức: gồm hai hay nhiều điều kiện đơn, toán tử logic AND (&&) OR (||) NOT (!) dấu ngoặc đơn “(“ “)” VD: (a > b + 1) AND (a 1 && b==0) { x=x/a; } for ( int i = 1; i < 3; i++){ if true x=x+1; } a Vẽ đồ thị luồng điều khiển b Từ đồ thị luồng điều khiển, xác định tạp ̂ các đuờ ̛ ng từ đầu vào tới đầu để bao phủ đuợ ̛ c toàn bộngã rẽ (branch) : có đường tất 1-2-5-6-end 1-2-5-6-7-8-6-end 1-2-3-5-6-end 1-2-3-6-7-8-6-end 1-2-3-4-5-6-end 1-2-3-4-5-6-7-8-6-end c Liẹu ̂ tất cả các đuờ ̛ ng có khả thi hay khong? ̂ Nếu khong ̂ chỉ những đuờ ̛ ng khong ̂ khả thi d Xác định test case tương ứng với đường khả thi Câu hỏi 3.19: Chương trình SquaresLoopRange( start-number, stop-number) hiển thị bình phương dãy số từ start-number tới stop-number Nếu start-number lớn stop-number error message cần hiển thị: Start-limit greater than stop-limit! Sq a Viết chương trình b Thiết kế test cases c Viết code JUnit tương ứng a code public class Squares { int startNum; int stopNum; public Squares(int startNum, int stopNum) { this.startNum = startNum; this.stopNum = stopNum; } public String show(){ if(startNum