Test and Maintenance – Thạc Bình Cường Tổng hợp câu hỏi Chất lượng sản phẩm sản xuất ? Đối với phần mềm, định nghĩa có không ? Làm để áp dụng định nghĩa đó? Câu Cái làm sở để kiểm định chất lượng phần mềm? Câu Để làm sở cho việc kiểm định chất lượng, đặc tả phần mềm cần thỏa mãn điều kiện gì? Nêu vài ví dụ điều kiện đưa ? 4 Các nhân tố ảnh hưởng đến chất lượng phần mềm có mức độ ? Những loại nhân tố ảnh hưởng đến chất lượng ? .4 Nêu đặc trưng ảnh hưởng lên chất lượng loại nhân tố ? Có thể đo trực tiếp chất lường phần mềm không? Tại ? Vậy phải đo cách ? Các độ đo đặc trưng chất lượng McCall giải thích nội dung ? .6 Giải thích nội dung thuộc tính chất lượng phần mềm sau nêu độ đo liên quan sử dụng để đo thuộc tính Các đặc trưng chất lượng theo Hawlett + giải thích nội dung: 10 Đảm bảo chất lượng phần mềm xuất phát từ đâu? Tiến triển nào? .8 11 Tại cần đảm bảo chất lượng phần mềm? Nó đóng vai trò doanh nghiệp phát triển phần mềm? Câu 12: Khi cần thực hoạt động đảm bảo chất lượng phần mềm? Câu 13 : Trong tổ chức, tham gia vào hoạt động đảm bảo chất lượng? Vai trò trách nhiệm đối tượng? Câu 14 : 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? 15 Giải thích nội dung tóm tắt hoạt động đảm bảo chất lượng? .10 16 Rà soát phần mềm hiểu (Khái niệm, mục tiêu, cách thức áp dụng)? Nêu lợi ích việc rà soát? Nếu không thực rà soát sao? .11 Câu 17 Các hình thức hoạt động rà soát: 11 Câu 18 Sơ đồ tiến trình rà soát: 11 18 Vẽ sơ đồ tiến trình của hoạt động rà soát và giải thích sơ bộ nội dung của mỗi bước 12 Câu 19: Trình bày nội dung họp rà soát: thành phần, thời gian, công việc cần làm, phương châm ? 12 19 Nội dung bản của một cuộc họp rà soát: Thành phần, thời gian, công việc cần làm, phương châm 14 Câu 20: Các sản phẩm họp rà soát gì? Nội dung, vài trò sản phẩm đó? 14 20 Các sản phẩm họp rà soát? Vai trò sản phẩm 15 21 Khi tiến hành rà soát? Cần rà soát sản phẩm gì? .15 Câu 22.Các danh mục rà soát : 15 23 Nêu ký hiệu giải ghích nội dung, ý nghĩa đại lượng: s1…s7, độ đo trung gian? .16 24 Sử dụng công thức với để làm .17 25 Giải thích nội dung thành phần ý nghĩa độ đo SMI cách sử dụng nó? 17 26 Số đo độ phức tạp McCabe dựa đại lượng cụ thể nào? 17 27 Đảm bảo chất lượng phần mềm dựa thống kê nghĩa gì? Nó gồm công việc gì? Kể nguyên nhân khiếm khuyết phần mềm? .17 Câu 28: Nêu công thức tính khiếm khuyết sản phầm pha phát triển? công thức tính khiếm khuyểt sản phẩm cuối cùng? Giải thích ý nghĩa nó? 18 Câu 29: Quá trình phòng gì? Phương châm kỹ thuật gì? 19 30 Độ tin cậy phần mềm hiểu gì? Đo độ tin cậy dựa liệu nào? 20 Câu 31 : Thế thất bại phần mềm, có thang bậc, thang bậc : .21 Câu 32 Nêu tiêu để tính độ tin cây? Nêu công thức tính độ sẵn sàng? Giải thích ý nghĩa chúng? 21 37 Tại phải kiểm thử phần mềm? Mục tiêu kiểm thử gì? Từ có quan niệm sai kiểm thử phần mềm? 24 Câu 41: Một ca kiểm thử gì? Mục tiêu thiết kế ca kiểm thử? Các bước để thiết kế ca kiểm thử? 28 Câu 42: Kiểm thử hộp trắng gì? Nêu đặc trưng nó? 28 43 Kiểm thử hộp đen gì? Nêu đặc trưng nó? .29 44 Chiến lược kiểm thử phần mềm gì? Nêu nguyên tắc chiến lược kiểm thử phần mềm? 29 45 Nêu bước chiến lược kiểm thử thời gian thực giải thích nội dung bước? 29 46 Có loại công cụ tự động trợ giúp kiểm thử? Mô tả nội dung loại? .30 47 Ai người phải tham gia kiểm thử phần mềm? Nêu vai trò trách nhiệm đối tượng?31 48 Kiểm thử hộp trắng dựa sở để thiết kế ca kiểm thử? Thiết kế ca kiểm thử phải đảm bảo điều kiện gì? 31 49 Đồ thị dòng gồm yếu tố nào? Xây dựng dựa vào đâu? Nó có đặc trưng gì? Đồ thị dòng dùng để làm gì? 32 50 Con đường bản đồ thị dòng là cái gì? Độ phức tạp của chu trình là gì? Nêu các công thức tính độ phức tạp? .32 51 Ma trận kiểm thử được cấu trúc thế nào? Nó dùng để làm gì? .33 52 Nêu các loại điều kiện cấu trúc điều khiển và cho ví dụ? Có những loại sai nào điều kiện kiểm thử? .33 53 Chiến lược kiểm thử phân nhánh nghĩa là gì? Yêu cầu đặt cho kiểm thử phân nhánh là gì? 33 i Chọn trường hợp kiểm thử để bắt đầu 34 ii Trường hợp sau giống đầu thay đổi sô thông số cho phù hợp 34 iii Tiếp tục cho đên 'C' xuất phát 34 iv Sử dụng đặc tả chương trình dể định xem loại liệu nên làm(tốt việc nên làm nhà phân tích) 34 v Thực qua chương trình .34 54 Chiến lược kiểm thử miền là gì? Nó dựa tư tưởng nào? .34 55 Chiến lược kiẻm thử BRO gì? Nó dựa tư tưởng nào? 35 56 Lấy ví dụ đièu kiện “ràng buộc ra” cho trườg hợp: biến Boolean, hợp biến Boolean thức quan hệ, hợp biểu thức quan hệ? 35 57 Kiểm thử điều khiển dòng liệu nghĩa gì? cho ví dụ 36 58k48 Kiểm thử điều khiển vòng lặp nghĩa gì? cho ví dụ 37 58k47 Kiểm thử điều khiển vòng lặp nghĩa gì? cho ví dụ 39 59K47 Mô hình kiểm thử hộp đen quan tâm đến nhân tố phần mềm? Nó nhằm tìm loại sai nào? Nêu phương pháp áp dụng cho nó? 40 60K47 Trình bày phương pháp phân hoạch: nguyên tắc, mục tiêu thiết kế ca kiểm thử? Phương pháp xác định lớp tương đương gì? .41 64 Kiểm thử đơn vị gì? Quan hệ với hoạt động mã hóa nào? 44 Kế hoạch kiểm thử unit .46 67 Kiểm thử tích hợp thực nào? Tại phải kiểm thử tích hợp? Nêu số câu hỏi đặt cho kiểm thử tích hợp? 46 68 Có phương pháp áp dụng cho kiểm thử tích hợp? Mô tả tóm tắt nội dung phương pháp? .47 Câu 69k48 nêu bước kiểm thử tích hợp từ xuống? Ưu nhược điểm cách tiếp cận này? 47 69k47 Nêu bước kiểm thử tích hợp từ xuống Ưu nhược điểm cách tiếp cận này? .48 Câu 70k48 nêu bước kiểm thử tích hợp từ lên? Ưu nhược điểm cách tiếp cận này? 48 70k47 Nêu bước kiểm thử tích hợp từ lên Ưu nhược điểm cách tiếp cận 49 71 Các tài liệu kiểm thử tích hợp gồm loại ? .49 72 Kiểm thử Beta ? Kiểm thừ Alpha ? Nêu giống khác chúng ? 50 73 Nội dung kiểm thử hệ thống ? Nêu số câu hỏi đặt cho kiểm thử hệ thống ? 50 74 Kiểm thử phục hồi ? 50 75 Kiểm thử an ninh ( mức độ an toàn hệ thống ) ? 51 78 Gỡ rối hiểu gì? Nó thực nào? Khó khăn việc gỡ rối gì? 51 Câu 79K48 Trình bày tiến trình gỡ rối? Các cách thức gỡ rối? Ưu nhược điểm chúng? 52 Câu 80 : Quản lý cấu hình phần mềm gi? Nội dung hoạt động quản lý cấu hình gồm công việc gì? .53 Câu 81K48 :Cấu hình phần mềm hiểu gì? nội dung khoản mục cấu hình phần gồm gì? 55 81K47 Cấu hình phần mềm hiểu gì? Nội dung khoản mục cấu hình phần mềm gồm gì? 55 Câu 82K48 Quản lý cấu hình nhằm mục tiêu gì? Năm nhiệm vụ quản lý cấu hình gì? .56 82K47 Quản lý cấu hình nhằm mục tiêu gì? nhiệm vụ quản lý cấu hình gì? 58 Câu 83K48 Phương pháp áp dụng cho việc quản lý cấu hình ? Mốc giới ? Sử dụng mốc giới để kiểm soát thay đổi ? .58 83K47 Phương pháp áp dụng cho việc quản lý cấu hình Mốc giới gì? Sử dụng mốc giới để kiểm soát thay đổi 58 Câu 84 Trình bày tiến trình kiểm soát thay đổi 59 85 Phiên ? Làm để kiểm soát phiên ? .60 86 Kiểm toán cấu hình phần mềm nghĩa ? Hoạt động kiểm toán cần trả lời cho cầu hỏi ? .60 87 Báo cáo trạng ? Nó cần trả lời câu hỏi gì? Đầu báo cáo trạng dành cho ? Mục tiêu gì? 61 Chất lượng sản phẩm sản xuất ? Đối với phần mềm, định nghĩa có không ? Làm để áp dụng định nghĩa đó? Chất lượng đơn giản sản phẩm phải theo thiết kế Từ định nghĩa ta thấy có hai yếu tố chất lượng là: - Chất lượng thiết kế: đặc điểm nhà thiết kế gán cho sản phẩm - Chất lượng sản xuất: mức độ tuân thủ đặc tả thiết kế sản xuất sản phẩm Theo Pressman chất lượng phần mềm: “Conformance to explicitly stated functional and performance requirements, explicitly documented development standards, and implicit characteristics that are expected of all professionally developed software.” Từ định nghĩa có điểm quan trọng: - yêu cầu phần mềm tảng để đo chất lượng Thiếu sót yêu cầu  thiếu sót chất lượng - chuẩn xác định qui định tiêu chí cách mà phần mềm sản xuất thiếu sót tiêu chí dẫn đến thiếu sót chất lượng - tập yêu cầu không bắt buộc thường không để ý(maintainability…), phấn mềm thỏa mãn yêu cầu bắt buộc không thỏa mãn đủ yêu cầu không băt buộc chất lượng phần mềm trước Vậy để đảm bảo chất lượng phần mềm đặc tả, qui trình sản xuất phải rõ ràng, đầy đủ phải tuân thủ chặt chẽ Câu Cái làm sở để kiểm định chất lượng phần mềm? Từ định nghĩa Pressman chất lượng phần mềm ta thấy sở để kiểm định chất lượng phần mềm gồm: - đặc tả phần mềm yêu cầu: bao gồm yêu cầu bắt buộc(chức năng) yêu cầu không bắt buộc(phi chức năng): SRS - chuẩn xây dựng phần mềm áp dụng: kiến trúc phần mềm, quy cách lập trình, chuẩn tính tiện dụng, hiệu Câu Để làm sở cho việc kiểm định chất lượng, đặc tả phần mềm cần thỏa mãn điều kiện gì? Nêu vài ví dụ điều kiện đưa ? Để đảm bảo chất lượng phần mềm đặc tả phần mềm phải: - correct(chính xác) - unambiguous(không nhập nhằng) - complete(đầy đủ) - consistent (nhất quán) - rank for importance and stability(các yêu cầu xếp hạng theo độ quan trọng ổn định) - verifiable: kiểm chứng - modifiable: sửa - traceable: theo dõi - understandable: dễ hiểu ví dụ: phần bạn nên lấy tập lớn bạn để minh chứng Mỗi điều kiện có ví dụ hay Các nhân tố ảnh hưởng đến chất lượng phần mềm có mức độ ? Những loại nhân tố ảnh hưởng đến chất lượng ? Theo ISO 9126 có nhân tố chính: Functionality: mức độ thỏa mãn phần mềm với yêu cầu đặt ra, bao bồm thuộc tính con: đồng bộ, xác, liên tác, tương thích, bảo mật Reliability: tính thời gian phần mềm sẵn sàng để phục vụ; gồm thuộc tính: đăn, khả chịu lỗi, khả phục hồi Usability: mức độ dễ dùng phần mềm, gồm: dễ học, dễ hiểu, dễ thao tác Efficency: mức độ phần mềm tối ưu hóa tài nguyên; gồm: thời gian đáp ứng, quản lý tài nguyên Maintainability: mức độ dễ dàng sửa phần mềm, gồm: khả phần tích được, khả sửa đổi được, khả kiểm thử được, độ ổn định Portability: mức độ dễ dàng chuyển phần mềm sang môi trường mới; gồm: khả thích nghi, khả cài đặt, khả thay Nêu đặc trưng ảnh hưởng lên chất lượng loại nhân tố ? xem câu Functionality • Phù hợp • Đúng đắn • Liên kết tốt người, liệu hệ thống • Làm theo yêu cầu • Tính bảo mật Reliability • Xử lý tin cậy • Khả khôi phục liệu • khả tìm lỗi, báo lỗi Usability • Dễ học thuộc, dễ hiểu, dễ thành thạo, dễ sử dụng Efficency • Quản lý thời gian • Quản lý nguồn tài nguyên Maintainability • Chạy ổn định • Có khả phân tích liệu • Có khả thay đổi phù hợp • Có khả kiểm tra Portability • Khả cài đặt • Khả thay thế, cập nhật nâng cấp • Khả thích hợp với nhiều cấu hình máy tính (Theo ISO 9126 ) Có thể đo trực tiếp chất lường phần mềm không? Tại ? Vậy phải đo cách ? Thường khó, có nhiều trường hợp đo chất lượng phần mềm cách trực tiếp từ nhân tố chất lượng Để giải vấn đề người ta xây dựng lên độ đo phương pháp đo chất lượng phần mềm Khi chất lượng phần mềm có dạng sau: Fq = c1 _ m1 + c2 _ m2 + + cn _ mn Trong Fq: nhân tố chất lượng phần mềm, ci hệ trọng số, mi độ đo nhân tố Các độ đo đặc trưng chất lượng McCall giải thích nội dung ? MacCall, Richard Walters nhóm nhân tố thành nhóm tập trung vòa khía cạnh phần mềm: - đặc tính hoạt động(Product Operational) - khả thích nghi với thay đổi(Product revision) - khả thích nghi với môi trường mới(Product transition) Giải thích độ đo: Correctness: độ đo phần mềm có làm theo đặc tả thỏa mãn đầy đủ yêu cầu khách hàng Reliability: độ đo phần mềm thực chức mong muốn với độ xác cho trước không Usability: số lượng tài nguyên code cần thiết để chương trình chức Giải thích nội dung thuộc tính chất lượng phần mềm sau nêu độ đo liên quan sử dụng để đo thuộc tính a Giải thích nội dung thuộc tính chất lượng phần mềm: - Tính đắn (Correctness): Là mức mà chương trình thỏa mãn đặc tả hoàn thành mục tiêu nhiệm vụ khách hàng - Tính tin cậy (Reliability): Là mức mà chương trình đáp ứng chức mong đợi với độ xác cho trước - Tính hiệu (Efficiency): Là lượng tài nguyên mã nguồn cần thiết sử dụng chương trình để thực chức - Tính toàn vẹn (Integrity): Là mức mà phần mềm liệu bị điều khiển người dùng bất hợp pháp - Tính khả dụng (Usability): Là công sức cần thiết bỏ để học, thao tác, chuẩn bị đầu vào, hiểu đầu chương trình -Tính bảo trì (Maintainability): Là công sức cần thiết bỏ để định vị sửa lỗi chương trình - Tính mềm dẻo (Flexibility): Là công sức cần thiết bỏ để chỉnh sửa thao tác chương trình - Tính thử nghiệm (Testability): Là công sức cần thiết bỏ để kiểm thử chương trình chắn chương trình thực chức mong đợi - Tính khả chuyển (Portability): Là công sức cần thiết bỏ để chuyển chương trình từ môi trường phần cứng và/hay hệ thống phần mềm sang môi trường khác - Tính liên tác (Interoperability): Là công sức cần thiết bỏ để liên kết với hệ thống khác - Tính sử dụng lại (Reusability): Là mức mà chương trình (hay phần chương trình) sử dụng lại ứng dụng khác (đề không hỏi, nêu cho đủ thôi) b Các độ đo liên quan sử dụng để đo thuộc tính, xem bảng dưới: (giải thích chi tiết độ đo Câu 7) (nguồn: p510, 511 SE Pressman) Các đặc trưng chất lượng theo Hawlett + giải thích nội dung: - Chức (Functionality): ước lượng cách đánh giá tập đặc trưng khả chương trình; mà nhìn chung chức đưa ra, cộng với an toàn toàn hệ thống - Tính khả dụng (Usability): ước lượng yếu tố người, bao gồm toàn bộ: tính thẩm mĩ (aesthetic), tính quán (consistency), tài liệu - Tính tin cậy (Reliability): đươc ước lượng cách tính toán tần suất thiệt hại có cố, xác kết đầu ra, thời gian trung bình xảy cố (MTTF – Mean Time To Failure), khả khôi phục sau cố, khả dự đoán (predictability) chương trình - Hiệu (Performance): đo tốc độ xử lý, thời gian phản hồi, lượng tài nguyên sử dụng, thông lượng tính hiệu - Tính hỗ trợ (Supportability): kết hợp khả mở rộng chương trình, khả thích nghi, khả phục vụ - thuộc tính chung nhất, thêm vào đó, tính bảo trì được, tính kiểm thử được, khả tích hợp được, khả cấu hình được, buộc hệ thống cài đặt, buộc vấn đề cục hóa 10 Đảm bảo chất lượng phần mềm xuất phát từ đâu? Tiến triển nào? - Đảm bảo chất lượng phần mềm với chức điều khiển lần giới thiệu Bell Labs vào năm 1916 - Trong năm từ 1950 đến 1960s, người lập trình chủ động kiểm soát chất lượng phần mềm họ viết - Tới năm 1970, chuẩn đảm bảo chất lượng phần mềm giới thiệu lần quân đội theo thỏa thuận phát triển phần mềm - Vào năm 1987, định nghĩa rộng đưa [SCH87] ( Lạy chúa ko hiểu SCH87 ??? ông Schneider phịa ra) 11 Tại cần đảm bảo chất lượng phần mềm? Nó đóng vai trò doanh nghiệp phát triển phần mềm? Trả lời : Phát triển phần mềm qúa trình phức tạp đầy rủi ro Có rủi ro kỹ thuật phần mềm hoạt động không mong đợi, hay phức tạp để thao tác, chỉnh sửa hay bảo trì; có rủi ro phạm vi vượt qúa chi phí thời gian định trước Mục đích SQA giảm thiểu rủi ro : - Kiểm tra trình phát triển phần mềm có phù hợp với phần mềm cần xây dựng không Đảm bảo việc phát triển đắn với chuẩn (Standards)và thủ tục (Procedures) lựa chọn đề Đảm bảo thiếu xót sản xuất, trình phát triển, tiêu chuẩn phát sửa đổi cho phù hợp Việc đảm bảo chất lượng phần mềm công việc quan trọng pha trình phát triển phần mềm Đó sở để đến sản phẩm đắn, thỏa mãn yêu cầu bà mong muôn phát triển phần mềm Đối với doanh nghiệp phát triển phần mềm, việc đảm bảo chất lượng công việc thiếu doanh nghiệp muốn phát triển hướng, thu hút khách hàng Thực trình đảm bảo chất lượng phần mềm giúp công ty tiết kiệm nguồn lực chi phí cho trình phát triển, đồng thời thu sản phẩm đắn, thỏa mãn yêu cầu khách hàng Để việc đảm bảo chất lượng đắn phù hợp công ty nên theo đuổi làm theo chuẩn Đảm bảo chất lượng phần mềm Câu 12: Khi cần thực hoạt động đảm bảo chất lượng phần mềm? Trả lời: Các hoạt động đảm bảo chất lượng phần mềm hoạt động bao trùm lên tất trình phát triển phần mềm Điều có nghĩa trình phát triển phần mềm, hoạt động đảm bảo chất lượng phần mềm cần phải thực giai đoạn, bắt đầu thực từ giai đoạn ban đầu, đến có sản phẩm thực việc bảo đảm chất lượng phần mềm Với giai đoạn trình phát triển dự án có hoạt động đảm bảo chất lượng phần mềm khác dựa tiêu chuẩn yêu cầu khác nhau, nhằm có điều chỉnh cần thiết để dự án đạt chất lượng cao Câu 13 : Trong tổ chức, tham gia vào hoạt động đảm bảo chất lượng? Vai trò trách nhiệm đối tượng? Trả lời : (Ở nghĩ câu hỏi nói hoạt động đảm bảo chất lượng phần mềm tổ chức làm phần mềm :D) Trong trình sản xuất phần mềm, việc đảm bảo chất lượng phần mềm tiến hành triển khai theo suốt tất giai đoạn vòng đời phát triển phần mềm, từ giai đoạn xác định yêu cầu đến triển khai kiểm thử Và người tham gia xây dựng phần mềm phải tham gia vào hoạt động đảm bảo chất lượng cho phần mềm Đó : • Phân tích viên : Đảm nhận vai trò xác minh phân tích yêu cầu người dùng Việc xác định yêu cầu xác đảm bảo cho phần mềm đáp ứng yêu cầu khách hàng • Thiết kế viên : chuyển yêu cầu phân tích thành thiết kế cho hệ thống, đưa kiến trúc vững cho phần mềm, thiết kế phù hợp với môi trường lập trình phát triển sau Công việc thiết kế chi tiết hóa yêu cầu khách hàng thành chức phần mềm Nếu thiết kế sai thiếu phải trả giá đắt triển khai dẫn tới đổ vỡ • Lập trình viên : Xây dựng phát triển phần mềm đáp ứng yêu cầu tiêu chuẩn xác định Lập trình tốt tránh lỗi bản, lỗi phát sinh triển khai chất lượng phần mềm tăng lên • Tester : xác định yêu cầu đáp ứng thực đắn, xác định lỗi xử lý trước triển khai Đây có lẽ người có vai trò quan trọng công tác đảm bảo chất lượng phần mềm Nếu tester yếu kém, thiếu trình độ dẫn tới dự án thất bại triển khai Trên thực tế, việc kiểm thử lồng vào giai đoạn phát triển phần mềm để tăng độ xác chất lượng cho phần mềm Câu 14 : 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? Trả lời Mục tiêu SQA(Software Quality Assurance) : (Nguồn : http://www2.umassd.edu/swpi/sei/tr25f/tr25_l2e.html) • SQA giúp thực công việc có kế hoạch • Đảm bảo sản phẩm phần mềm đáp ứng tiêu chuẩn, yêu cầu chất lượng theo mong muốn • Giúp cho nhóm cá nhân nắm vững hoạt động đảm bảo chất lượng phần mềm có kết tốt • Các vấn đề vướng mắc mà giải dự án phần mềm đưa cho nhà quản lý thẩm quyền(tránh tình trạng không làm mà nhận) Các hoạt động : Activity A SQA plan is prepared for the software project according to a documented procedure Một kế hoạch SQA đề cho dự án phần mềm Activity The SQA group's activities are performed in accordance with the SQA plan Các hoạt động nhóm SQA thực theo kế hoạch SQA đề Activity The SQA group participates in the preparation and review of the project's software development plan, standards, and procedures Nhóm SQA tham gia vào việc chuẩn bị tổng quát kế hoạch phát triển phần mềm, tiêu chuẩn thủ tục cần thiết Activity The SQA group reviews the software engineering activities to verify compliance Nhóm SQA xem xét hoạt đông kỹ nghệ phần mềm để đạt mục đích mong muốn Activity The SQA group audits designated software work products to verify compliance Nhóm SQA kiểm tra công việc thiết kế để đạt yêu cầu đề Activity The SQA group periodically reports the results of its activities to the software engineering group Nhóm SQA báo cáo kết định kỳ hoạt động xây dựng phần mềm Activity Deviations identified in the software activities and software work products are documented and handled according to a documented procedure Xác định hành động không phù hợp thủ tục công việc xây dựng phần mềm theo tài liệu đặc tả Activity : Tiến hành kiểm thử giai đoạn vòng đời phát triển phần mềm Cụ thể từ giai đoạn xác định yêu cầu người dùng đến triển khai, kiểm thử bảo trì(Các bạn tự trình bày phần nắm rồi_câu 13) Câu 15 : Giải thích tóm tắt hoạt động đảm bảo chất lượng phần mềm ? (Trình bày mở rộng ý câu 14) 15 Giải thích nội dung tóm tắt hoạt động đảm bảo chất lượng? The test process: Mô tả pha quan trọng tiến trình kiểm thử Requirements traceability: Kiểm thử nên vạch kế hoạch để tất yêu cầu kiểm thử riêng lẻ Tested items: Xác định trước thành phần phần mềm cần test Testing schedule: Một danh mục kiểm thử tài nguyên xác định cho danh mục Test recording procedures: Hệ thống lại kết kiểm thử Hardware and software requirements: Các công cụ phần mềm yêu cầu ước lượng phần cứng cần dùng Constraints: Thúc ép để đạt tiến trình kiểm thử, ví dụ lường trước việc thiếu số lượng vị trí 10 dành cho giao diện mô đun Cho dù không tìm thấy vấn đề kiểm thử đơn vị, lỗi thường xuất mô đun ghép lại Nếu lỗi xuất kiểm thử tích hợp bạn phải quay lui trở tiến trình trước sửa vấn đề Cũng cần phải sửa lại tài liệu thiết kế Trước tiến hành kiểm thử tích hợp, phải định nghĩa rõ ràng mô đun nối theo thứ tự 68 Có phương pháp áp dụng cho kiểm thử tích hợp? Mô tả tóm tắt nội dung phương pháp? Kiểm thử tăng dần : Trong kiểm thử tăng dần, mô đun hoàn tất kiểm thử móc nỗi liên tiếp với mô đun khác Kiểm thử tăng dần phân thành ba loại sau: + Kiểm thử xuống + Kiểm thử lên + Kiểm thử tổ hợp Kiểm thử không tăng: Trong kiểm thử này, tất mô đun có việc kiểm thử đơn vị hoàn tất móc nối cho chạy Kiểm thử không tăng điển hình kiểm thử Big Bang Câu 69k48 nêu bước kiểm thử tích hợp từ xuống? Ưu nhược điểm cách tiếp cận này? Bắt đầu với unit ( main unit) Thay unit liên quan bị gọi main unit stub(mẩu), coi unit mẩu , mẫu này: - Được coi phần mềm giả ( dummy software) - Các mẫu phản ứng giống phản ứng unit mà thay - Dễ lập trình Kiểm thử giao diện main unit Kiểm thử với unit khác ( ví dụ A): lặp lại bước từ 1, 2, 3, unit kiểm thử giao diện chúng kiểm thử, lần kiểm thử giao diện unit ( hình vẽ minh họa phía dưới) 47 Ưu nhược điểm : Dễ dàng phân lập lỗi Khó làm việc lập trình tiến hành kiểm thử song song giai đoạn khởi đầu Thích hợp cho phát triển hệ thống 69k47 Nêu bước kiểm thử tích hợp từ xuống Ưu nhược điểm cách tiếp cận này? Kiểm thử xuống dùng để phát triển hệ thống theo thứ tự từ mô đun cao tới mô đun thấp Mô đun mức cao móc nối với mô đun cac tiếp tất mô đun khác móc nối theo trình tự mô đun từ mức cao tới mức thấp Các mô đun quan trọng kiểm thử thường xuyên mô đun quan trọng, làm tăng độ tin cậy giao diện mô đun mức cao Tiền điều khiển cho việc dùng kiểm thử chỗ thân chương trình phỉa tạo việc dùng thiết kế có cấu trúc Bởi mô đun cấp cao với số nhỏ chương trình phát triển trước, nên khó làm việc lập trình tiến hành kiểm thử song song giai đoạn khởi đầu Thích hợp cho việc phát triển hệ thống Câu 70k48 nêu bước kiểm thử tích hợp từ lên? Ưu nhược điểm cách tiếp cận này? Bắt đầu từ unit mức thấp Thay unit gọi unit driver (trình điều khiển), driver coi : - Được coi phần mềm giả ( dummy software) - Vẫn tạo gọi ( calls) gọi unit mà thay - Khó lập trình Kiểm thử giao diện unit Lặp lại bước từ đến với unit khác 48 Ưu nhược điểm Dễ dàng phân lập lỗi Có thể làm việc lập trình tiến hành kiểm thử song song giai đoạn khởi đầu Thích hợp cho việc phát triển phiên sửa đổi hệ thống 70k47 Nêu bước kiểm thử tích hợp từ lên Ưu nhược điểm cách tiếp cận Kiểm thử lên dùng để phát triển hệ thống theo trình tự mô đun mức thấp tới mức cao Kiểm thử tiến hành việc móc nối mô đun theo trình tự mức thấp tơi mức cao Khi kiểm thử tích hợp hoàn tất chương trình kiểm thử theo điều kiện vận hành thực tế Bởi số mô đun mức thấp với số lớn chương trình phát triển trước hết, nên làm việc lập trình tiến hành kiểm thử song song giai đoạn khởi đầu Xem hệ thống kiểm thử, cần có trình điều khiển Thích hợp cho việc phát triển phiên sửa đổi hệ thống 71 Các tài liệu kiểm thử tích hợp gồm loại ? - Các loại tài liệu kiểm thử tích hợp o Tài liệu phạm vi kiểm thử ( scope and testing ) o Tài liệu kế hoạch kiểm thử  Kiểm thử theo pha  Lên lịch kiểm thử  Kiểm thử mức tổng quát  Kiểm thử môi trường tài nguyên o Tài liệu thủ tục kiểm thử n  Yêu cầu kiểm thử tích hợp • Mục đích kiểm thử 49 • Modules kiểm thử Kiểm thử đơn vị cho modules xây dựng Tài liệu mô tả kiểm thử module m Tài liệu mô tả tổng quan phần mềm Tài liệu liệt kê kết mong đợi xuất Tài liệu kiểm thử môi trường Tài liệu ghi lại công cụ hay công nghệ áp dụng trình tiến hành kiểm thử  Tài liệu kiểm thử liệu  Những kết mong đợi xây dựng n o Kết thực tế o Tài liệu tham khảo o Các phụ lục liên quan       72 Kiểm thử Beta ? Kiểm thừ Alpha ? Nêu giống khác chúng ? - Kiểm thử Beta : bước kiểm thử mà bước phát triển kiểm thử truớc hoàn thành Quá trình tiến hành kiểm thử lần cuối nhằm tìm lỗi kiểm chứng ràng buộc trứoc công bố tiến hành phân phối sản phẩm Kiểm thử Alpha : bước kiểm thử ứng dung mà trình phát triển hoàn thiện lẽ thay đổi dù nhỏ thiết kế phát sinh lỗi Giống : Cả hai trình kiểm thử thường thực end – users hay nhóm người khác người cài đặt hay tester Khác : Kiểm thử Alpha bước kiểm thử mà ứng dụng hoàn thiện kiểm thử Beta bước kiểm thử mà trình phát triển kiểm thử hoàn thiện bước trước 73 Nội dung kiểm thử hệ thống ? Nêu số câu hỏi đặt cho kiểm thử hệ thống ? - Kiểm thử hộp đen ( Black – Box ) : Không quan tâm đến việc thiết kế, kiến trúc hay cách thức cài đặt hệ thống Kiểm thử dựa yêu cầu chức hệ thống Kiểm thử hệ thống : loại kiểm thử hộp đen ( black – box ) Kiểm thử dựa tất đặc tả yêu cầu bao trùm lên tất thành phần kết hợp hệ thống Nội dung : Phần mềm thành phần hệ thống Phần mềm tích hợp với thành phần khác hệ thống hệ thống tích hợp chúng lại kiểm tra tính hợp lệ phần mềm sau tích hợp Một số câu hỏi đặt cho kiểm thử hệ thống : o Phần mềm dựa hệ thống ( software based systems ) có khả phục hồi không ? o Phần mềm dựa hệ thống có đảm bảo tính bảo mật không ? o Phần mềm dựa hệ thống có đảm bảo ứng suất không ? o Phần mềm dựa hệ thống có thực thi cách đắn không ? 74 Kiểm thử phục hồi ? - Kiểm thử mức độ phục hồi hệ thống từ “mảnh vỡ” phần mềm ( recovers from crashes – dịch “mảnh vỡ” thóat ý chưa ? - HaiNguyen), từ cố phần cứng, trí vấn đề trầm trọng 50 75 Kiểm thử an ninh ( mức độ an toàn hệ thống ) ? - Kiểm thử mức độ bảo vệ hệ thống trước truy cập trái phép từ bên lẫn bên hệ thống, chống lại loại phá hoại có chủ định, … để làm điều này, đòi hỏi hệ thống phải kiểm thử công phu tỉ mỉ 76 Kiểm thử áp lực gì? Test áp lực phương pháp test để xem hệ thống có đáp ứng với điều kiện khắc nghiệt thời gian dài hay không Thông thường test áp lực áp dụng với sản phẩm web server hay chương trình nhiệm vụ collect data - Đối với web server ta tiến hành cho client truy xuất liên tục với cường độ cao (trong phạm vi chấp nhận web server) khoảng thời gian dài để xem web server đáp ứng tất yêu cầu phục vụ hay không - Đối với chương trình collect data phải liên tục cung cấp data để chương trình collect thời gian dài xem có bị bỏ sót liệu hay bị chương trình có bị treo hay không Thông thường để thực test áp lực người ta thường dùng automation script không làm manual 77 Kiểm thử thi hành gì? Kiểm thử thi hành (PT-performance test) dạng kiểm tra tự động, để tìm điểm “thắt cổ chai” phần mềm cần kiểm tra, qua giúp cho người làm phần mềm có thay đổi thích hợp để tăng khả thực thi phần mềm Bên cạnh giúp người kiểm tra biết thông số ngưỡng phần mềm, đề tiêu chuẩn cho lần kiểm tra sau Khi thực PT, người kiểm tra phải đề kết mong đợi cách rõ ràng Ví dụ: ứng dụng web, cần biết thông số quan trọng là: số kết nối đồng thời mà server phục vụ, thời gian (bao nhiêu phút/giây) mà trình duyệt nhận kết từ server Khi thực PT người ta thường chọn thời điểm mà chương trình tương đối ổn định Thông thường chức nằm tình cần kiểm tra hiệu kiểm tra chạy Điều giúp cho việc phân tích đánh giá kết PT dễ dàng đắn 78 Gỡ rối hiểu gì? Nó thực nào? Khó khăn việc gỡ rối gì? Gỡ rối hiểu gì? Gỡ rối tiến trình có phương pháp để tìm kiếm giảm số lượng lỗi (bug) nhược điểm (defect) chương trình máy tính, nhờ làm cho chương trình chạy mong muốn Gỡ rối thực nào? Gỡ rối thực kiểm thử Tiến trình gỡ rối bắt đầu với việc thực thi trường hợp kiểm thử (test-case), kết kiểm thử không tương xứng với mong đợi Thông thường, không tương xứng triệu chứng 51 nguyên nhân chưa biết Tiến trình gỡ rối cố gắng tìm nguyên nhân triệu chứng, từ tiến tới việc sửa lỗi Khó khăn việc gỡ rối gì? • Triệu chứng nguyên nhân cách xa (geographically remote) Nghĩa là, triệu chứng xuất đoạn chương trình nguyên nhân thật lại nằm nơi hoàn toàn khác • Triệu chứng tạm thời biến lỗi khác sửa • Triệu chứng thực gây lỗi (nonerrors) • Triệu chứng gây sai sót người (thường không dễ để dò vết) • Triệu chứng kết vấn đề thời gian (timing problem) xử lý • Việc tái tạo lại điều kiện đầu vào cách xác khó khăn • Triệu chứng gián đoạn Lỗi phổ biến hệ thống nhúng, phần cứng phần mềm tách rời Triệu chứng gây nguyên nhân phân tán số tác vụ (task) chạy xử lý khác Câu 79K48 Trình bày tiến trình gỡ rối? Các cách thức gỡ rối? Ưu nhược điểm chúng? Tiến trình gỡ rối: Là tiến trình để xác định nguyên nhân lỗi sửa lỗi.Do đầu tiến trình là: - Nguyên nhân lỗi tìm sửa lại - Nguyên nhân lỗi không tìm Xác định lỗi Thiết kế việc sửa lỗi Kết kiểm thử Đặc tả Sửa chữa lỗi Kiểm tra lại chương trình Trường hợp kiểm thử Các cách thức gỡ rối, ưu nhược điểm chúng: Brute force (Thô) Sử dụng triết lý “để máy tính tìm lỗi” phương pháp hiệu việc cô lập nguyên nhân lỗi áp dụng phương pháp khác thất bại Là tổng hợp nhiều phương pháp: - Xổ nhớ (Memory dump) - Dò vết chạy (Run-time trace) - Chương trình tải với câu lệnh WRITE Nhược điểm: Mặc dù với số lượng lớn thông tin tạo cuối dẫn đến thành công thường gây lãng phí thời gian công sức Backtracking (Lần ngược) 52 Bắt đầu từ nơi mà triệu chứng phát hiện, dò ngược lại mã nguồn (bằng tay) tìm nguyên nhân Thích hợp với chương trình nhỏ Nhược điểm: Khi số lượng dòng code lớn số khả quay lại trở nên lớn Cause elimination (Loại trừ nguyên nhân) Dữ liệu liên quan tới phát sinh lỗi tổ chức để cô lập nguyên nhân tiềm Một “giả thuyết nguyên nhân” đặt liệu sử dụng để chứng minh bác bỏ giả thuyết đó.Một danh sách khả phát triển kiểm thử nguyên nhân để loại trừ dần nguyên nhân Nếu kiểm tra nguyên nhân có khả gây lỗi thật liệu lọc phép thử để cô lập lỗi Các giả thuyết sử dụng lặp lại Nhược điểm : Phụ thuộc nhiều vào kinh nghiệm ,khả phán đoán đưa giả thuyết nguyên nhân gây lỗi Phải kiểm thử nhiều giả thuyết Câu 80 : Quản lý cấu hình phần mềm gi? Nội dung hoạt động quản lý cấu hình gồm công việc gì? a) Quản lý cấu hình phần mềm gi?  Quản lý cấu hình phần mềm trình điều khiển(controlling) theo dõi(monitoring) sự thay đổi tiến trình của hệ thống phần mềm  Quản lý cấu hình phần mềm bao gồm các hoạt động sau :  Quản lý các tiền trình quản lý cấu hình phần mềm (software configuration management process)  Xác định cấu hình phần mềm.( software configuration identification)  Điều khiển cấu hình phần mềm.( software configuration control)  Trạng thái accounting cấu hình phần mềm (software configuration status accounting)  Kiểm toán cấu hình phần mềm (software configuration auditing)  Phân phối và quản lý software release (software release management and delivery) b) Nội dung hoạt động quản lý cấu hình gồm công việc gì?  Quản lý các tiền trình quản lý cấu hình phần mềm :  Phạm vi quản lý cấu hình phần mềm:  Vòng đời, kế hoạch và thời hạn phần mềm  Người chỉ huy dự án (đồng lòng, sắp xếp được)  Reuse phần mềm  development and target platforms  Các công cụ phát triển phần mềm  Các giàng buộc và sự chỉ đạo quản lý cấu hình phần mềm 53  Kế hoạch quản lý cấu hình phần mềm và cấu hình phần mềm  Sự tổ chức và trách nhiệm  Thời hạn và các phương sách quản lý cấu hình phần mềm  Thực thi và chọn các công cụ  Sự điều khiển của nhà cung cấp  Điều khiển bề mặt chung (Interface control)  Kế hoạch quản lý cấu hình phần mềm  Sự giám sát của quản lý cấu hình phần mềm  Xác định cấu hình phần mềm :  Xác định các khoản mục để điều khiển :  Cấu hình phần mềm  Items cấu hình phần mềm  Quan hệ item cấu hình phần mềm  Version software  Xác định các cấu hình đã được phê chuẩn  Các items cấu hình phần mềm đã thu được  Thư viện phần mềm  Điều khiển cấu hình phần mềm  Yêu cầu, đánh giá và sự tán thành sự thay đổi phần mềm  Thực hiện sự thay đổi phần mềm  Sự chệch hướng và sự khước từ  Software Configuration Status Accounting :  Thông tin trạng thái cấu hình phần mềm  Báo cáo các trạng thái cấu hình  Kiểm toán cấu hình phần mềm :  Kiểm toán cấu hình các chức phần mềm  Kiểm toán cấu hình các Software physical  Phân phối và quản lý software release :  Software building  Software release management Tài liệu tham khảo chính : http://cs.wwc.edu/~aabyan/435/Configuration.html Author : Đào văn Tâm CNPMK48 DHBK HA NOI 54 Câu 81K48 :Cấu hình phần mềm hiểu gì? nội dung khoản mục cấu hình phần gồm gì? Trong truyền thông hệ thống máy tính, cấu hình xếp đơn vị chức (functional units) theo tự nhiên, số lượng đặc trưng Thường thường cấu hình đôi với lựa chọn phần cứng, phần mềm tài liệu Cấu hình phản ánh chức hệ thống thực thi nó(wikipedia-computer configuration) The output of the software process is information that may be divided into three broad categories: (1) computer programs (both source level and executable forms); (2) documents that describe the computer programs (targeted at both technical practitioners and users), and (3) data (contained within the program or external to it) The items that comprise all information produced as part of the software process are collectively called a software configuration Cách mà hệ thống cài đặt xếp thành phần để tạo nên hệ thống Cấu hình phần cứng phần mềm kết hợp hai a Như theo định nghĩa cấu hình phần mềm tiêu chuẩn, tài liệu áp dụng để xây dựng phần mềm b Nội dung khoản mục cấu hình phần mềm là: - Tài liệu dự án:  Các tài liệu lưu trữ phục vụ cho dự án  Phương thức đặt tên cho tài liệu - Version, Variant, Realease  Version mà có đôi chút khác biệt mặt chức với trường hợp trước  Các thuộc tính  Các thay đổi so với phiên trước  Variant (system instance) đồng mặt chức lại không phân biệt mặt chức với khác  Realease cung cấp cho người sử dụng bên ngoài, người phát triển  Các file cấu hình :xác định release cấu hình theo cách  Các file liệu cần thiết cho OS  Các chương trình cài đặt shell script để cài đặt hệ thống vào máy cứng  Các tài liệu điện tử giấy  Các gói liên kết công khai - Các vấn đề hệ thống xây dựng phần mềm( system problem)  Quyết định tạo phiên release  Hệ thống dựng (system building) 81K47 Cấu hình phần mềm hiểu gì? Nội dung khoản mục cấu hình phần mềm gồm gì? Cấu hình phần mềm hiểu gì? Bao gồm tập hợp đối tượng có liên quan qua lại lẫn nhau, kết hoạt động kỹ nghệ phần mềm Bao gồm item chứa tất thông tin sinh phần tiến trình phần mềm 55 Nội dung khoản mục cấu hình phần mềm gồm gì? • Đặc tả thiết kế (Design specification) • Mô hình liệu (Data model) • Thành phần N (Component N) • Mã nguồn (Source code) • Đặc tả kiểm thử (Test specification) Câu 82K48 Quản lý cấu hình nhằm mục tiêu gì? Năm nhiệm vụ quản lý cấu hình gì? Quản lí cấu hình Khi tạo phiên phần mềm có số thay đổi như:  Thay đổi phần cứng hệ điểu hành  Có thể có số chức  Chỉnh sửa theo số yêu cầu riêng khách hàng Vì lí cần phải có quy trình quản lí tất thay đổi => xuất khái niệm quản lí cấu hình Configuration management - Quản lí cấu hình - CM: trình quản lí tiến hóa phần mềm, quản lí tất hoạt động thay đổi hệ thống nhằm quản lí chi phí hiệu thay đổi  Quản lí cấu hình liên quan đến trình phát triển, ứng dụng thủ tục chuẩn nhằm quản lí tiến hóa phần mềm  Quản lí cấu hình xem phần trình quản lí chất lượng phần mềm nói chung  Khi nói đến quản lí cấu hình, hệ thống phần mềm gọi baselines coi điểm bắt đầu cho tiến trình khác 56  Mục đích QLCH để thiết lập bảo đảm tính toàn vẹn sản phẩm trung gian sản phẩm sau dự án phần mềm, xuyên suốt chu kỳ sống dự án Năm nhiệm vụ quản lí cấu hình:  Xác định chuẩn CM ( configuration management):  Thông thường công ty thường áp dụng tập chuẩn việc quản lí cấu hình riêng  Chuẩn mô tả cách định danh danh mục cấu hình, cách chuyển đổi điểu khiển, cách quản lí phiên phần mềm  Có thể xây dựng từ chuẩn quốc tế IEEE  Có số chuẩn CM tồn với mô hình waterfall, cần phải xây nâng cấp thành chuẩn phù hợp với tình hình  Đồng việc phát triển kiểm thử phần mềm:  Quản lí trình xây dựng phần mềm theo mô hình phát triển nhanh  Lập kế hoạch quản lí cấu hình phần mềm  Quản lí đặc tả phần mềm, tài liệu, thiết kế, chương trình, liệu test,sổ tay khách hàng,  Phân loại tài liệu  Xác định thủ tục quản lí cấu hình cấu hình gốc baselines  Xác định sách điểu khiển quản lí version  Xác định ghi cấu hình  Xác định tool quản lí cấu hình phần mềm, sở liệu quản lí cấu hình phần mềm  Quản lí Cơ sở liệu cấu hình  Quản lí thay đổi cấu hình Các thay đổi xuất phát từ khách hàng, từ nhóm phát triển, từ thị trường  Quản lí version chuyển giao phần mềm  Quản lí công cụ sử dụng để cấu hình phần mềm thay đổi trình sử dụng công cụ quản lí cấu hình phần mềm 57 82K47 Quản lý cấu hình nhằm mục tiêu gì? nhiệm vụ quản lý cấu hình gì? Quản lý cấu hình nhằm mục tiêu gì? Mục tiêu để đạt suất tối đa cách tối thiểu sai lầm Trách nhiệm kiểm soát thay đổi, chịu trách nhiệm việc nhận diện đối tượng cấu hình phần mềm, phiên khác phần mềm, kiểm toán cấu hình phần mềm để đảm bảo phần mềm phát triển đắn, báo cáo thay đổi Năm nhiệm vụ quản lý cấu hình gì? • Nhận diện đối tượng cấu hình phần mềm (Identification of objects in the software configuration) • Kiểm soát phiên (Version control) • Kiểm soát thay đổi (Change control) • Kiểm toán cấu hình (Configuration audit) • Báo cáo trạng (Status reporting) Câu 83K48 Phương pháp áp dụng cho việc quản lý cấu hình ? Mốc giới ? Sử dụng mốc giới để kiểm soát thay đổi ?  Quản lý cấu hình xét cách toàn diện bao gồm : quản lý cấu hình phần mềm (SCM), quản lý cấu hình phần cứng (HCM) quản lý cấu hình sử dụng (Operational CM) Trong SCM tập trung vào quản lý source code suốt trình phát triển Operational CM lại tập trung vào quản lý cấu hình thành phần hệ thống (như phần mềm, phần cứng, tài liệu xác định dịch vụ) sở hạ tầng công nghệ thông tin Các phương pháp áp dụng cho quản lý cấu hình: o Lập ban quản lý: o Kiểm soát thay đổi o Hỗ trợ phát hành o Quản lý tiến trình Mốc giới: khái niệm quản lý cấu hình phần mềm nhằm giúp điều khiển thay đổi mà không gây ảnh hưởng trầm trọng tới hệ thống Sử dụng mốc giới để kiểm soát thay đổi : o Một mốc giới đặc tả sản phẩm mà thông thường xem xét chấp nhận vào lúc giờ, sau xem cho phát triển xa o Trong kỹ nghệ phần mềm, cột mốc dùng để đánh dấu phát triển phần mềm Nó hay nhiều cấu hình phần mềm thời điểm khác trình phát triển phần mềm    83K47 Phương pháp áp dụng cho việc quản lý cấu hình Mốc giới gì? Sử dụng mốc giới để kiểm soát thay đổi • • • Phương pháp áp dụng cho việc quản lý cấu hình : Mốc giới ( baseline ) : khái niệm quản lý cấu hình phần mêm nhằm giúp điều khiển thay đổi mà không gây thay đổi cản trở trầm trọng Sử dụng mốc giới để kiểm soát thay đổi : 58 • • Một mốc giới đặc tả sản phẩm mà thông thường xem xét chấp nhận vào lúc giờ, sau xem cho phát triển xa Trong kỹ nghệ phần mềm, cột mốc dùng để đánh dấu phát triển phần mềm Nó hay nhiều cấu hình phần mềm thời điểm khác trình phát triển phần mềm Câu 84 Trình bày tiến trình kiểm soát thay đổi  Tiến trình kiểm soát thay đổi trình yêu cầu, xác định mức độ hoàn thành, lên kế hoạch, thực thi đánh giá thay đổi hệ thống Nó bao gồm hai mục đích : Hỗ trợ xử lí thay đổi lên kế hoạch thực thay đổi  Kiểm soát thay đổi trình quan trọng, đem lại lợi ích lớn (do hệ thống cải thiện làm vừa lòng yêu cầu khách hàng) gây mối nguy hại khó lường (do phá hoại hệ thống thay quyền quản lý)  Tiến trình kiểm soát thay đổi: If thay đổi hợp lý Then Đánh giá làm thay đổi thực thi Ước lượng giá thay đổi Đệ trình yêu cầu để thay đổi tới ủy ban điều khiển (control board) If thay đổi chấp nhận Then Repeat Thực thay đổi tới phần mềm Xem xét thay đổi phần mềm với yêu cầu chất lượng Until chất lượng phần mềm thỏa đáng Tạo phiên hệ thống Else Từ chối thay đổi Else Từ chối thay đổi  Có số chuẩn CM tồn với mô hình waterfall, cần phải xây nâng cấp thành chuẩn phù hợp với tình hình  Đồng việc phát triển kiểm thử phần mềm:  Quản lí trình xây dựng phần mềm theo mô hình phát triển nhanh  Lập kế hoạch quản lí cấu hình phần mềm  Quản lí đặc tả phần mềm, tài liệu, thiết kế, chương trình, liệu test,sổ tay khách hàng,  Phân loại tài liệu  Xác định thủ tục quản lí cấu hình cấu hình gốc baselines  Xác định sách điểu khiển quản lí version  Xác định ghi cấu hình 59  Xác định tool quản lí cấu hình phần mềm, sở liệu quản lí cấu hình phần mềm  Quản lí Cơ sở liệu cấu hình  Quản lí thay đổi cấu hình Các thay đổi xuất phát từ khách hàng, từ nhóm phát triển, từ thị trường  Quản lí version chuyển giao phần mềm  Quản lí công cụ sử dụng để cấu hình phần mềm thay đổi trình sử dụng công cụ quản lí cấu hình phần mềm 85 Phiên ? Làm để kiểm soát phiên ? • • Phiên thể hệ thống có số khác biệt chức so với thể khác hệ thống Để kiểm soát phiên ( version control ) kết hợp số thủ tục công cụ o Các thủ tục ( procedures ) để xác nhận phiên đưa cách khác để xác định phiên thành phần công nghệ :  Đánh số phiên ( version numbering )  Cấu trúc nguồn gốc phiên ( version derivation structure )  Xác định thuộc tính ( atttribute- based identification ) o Các công cụ quản lý phiên :  Version and release identification  Storage management  Change history recording  Independent development  Project support 86 Kiểm toán cấu hình phần mềm nghĩa ? Hoạt động kiểm toán cần trả lời cho cầu hỏi ? Kiểm toán cấu hình phần : phương pháp nhằm đảm bảo sản phẩm phần mềm xây dụng theo yêu cầu xác định, xem item có thể yêu cầu không, kiểm tra hoat động phần mềm có áp dụng dúng có khả kiểm soát hay không Hoạt động kiểm toán cần trả lời cho câu hỏi sau : • Có thay đổi xác định ECO ( ?) tạo hay không Các sửa đổi thêm vào kết hợp lại với chưa? • Đã có kiểm duyệt kĩ thuật thức thự để đánh giá đắn kĩ thuật hay chưa? • Quy trình phần mềm có tuân theo khuôn mẫu không tiêu chuẩn công nghệ phần mềm áp dụng đắn chưa.? • Sự thay đổi có phải “ bật “ SCI ( software configuration item ) Các thuộc tính đối tượng cấu hình có phẩn ánh thay đổi không ? • Các thủ tục cấu hình phần mềm để lưu ý, ghi nhận báo cáo thay đổi có trước hay chưa ? 60 • Mối quan hệ tất khoản mục cấu hình phần mềm ( software configuration items ) cập nhật xác hay chưa.? 87 Báo cáo trạng ? Nó cần trả lời câu hỏi gì? Đầu báo cáo trạng dành cho ? Mục tiêu gì? Status reporting có nghĩa thể đặc điểm thông số sản phẩm nhằm tạo thông tin cần thiết, sãn sàng có ích để quản lý cách hiệu phát triển sản phẩm bảo trì Status reporting cần trả lời câu hỏi sau : • Điều xảy ? ( what happened ?) • Ai làm điều ?( who did it ) • Điều xảy ( what did it happen ? ) • Cái khác bị ảnh hưởng ? ( what else will be affected ? ) Đầu báo cáo trạng dành cho người phát triển phần mềm ( software developers ) Mục tiêu Status reporting nhằm tạo thông tin cần thiết, sãn sàng có ích để quản lý cách hiệu phát triển sản phẩm bảo trì 61 [...]... triển? (Do trong đề cương câu hỏi ôn tập phần 3.2 của thầy có nói các phương pháp kiểm thử phần mềm là : a Kiểm thử hộp trắng, b Kiểm thử hộp đen, c Kiểm thử đơn vị, d Kiểm thử tích hợp, e Kiểm thử hệ thống…-> sẽ nói tất) Các phương pháp kiểm thử phần mềm : + Kiểm thử hộp trắng + Kiểm thử hộp đen + Kiểm thử đơn vị + Kiểm thử tích hợp 26 + Kiểm thử hệ thống + Kiểm thử xác nhận + Kiểm thử hồi quy Đối... vấn đề về phần cứng Các quan niệm sai về kiểm thử phần mềm: 24 Câu 37 Tại sao phải kiểm thử phần mềm? Mục tiêu kiểm thử là gì? Từ đó có những quan niệm sai gì về kiểm thử phần mềm? Tại sao phải kiểm thử phần mềm + Do phần mềm rất hay có lỗi, do đó cần kiểm thử để phát hiện các lỗi, sửa nó , và làm tăng độ tin cậy của phần mềm + Do việc sửa các lỗi bị phát hiện muộn thường là rất tốn kém + Để đảm bảo phần. .. phần mềm Xem việc phân tích yêu cầu phần mềm đã chính xác với những yêu cầu khách hàng đề ra chưa, những yêu cầu đó có chính xác so với đặc tả không? rà soát thiết kế phần mềm Phần mềm thiết kế có đúng tiêu chuẩn đã đặt ra trong đặc tả phần mềm chưa? rà soát khâu lập mã phần mềm Mật mã phần mềm có được thiết lập an toàn như trong đặc tả đã đề ra không? rà soát kiểm thử phần mềm Công việc kiểm thử đã... Assurance,Pressman ( p.197)) 37 Tại sao phải kiểm thử phần mềm? Mục tiêu kiểm thử là gì? Từ đó có những quan niệm sai gì về kiểm thử phần mềm? Việc kiểm thử phần mềm là cần thiết để xác định phần mềm được tạo ra có đáp ứng đúng các yêu cầu hay không Mục tiêu của kiểm thử: - Phát hiện tất cả các lỗi có thể được trong khoảng thời gian cho trước - Xác định xem một sản phẩm phần mềm có đáp ứng các đặc tả yêu cầu... tương đương Phân tích giá trị biên o Kiểm thử hộp trắng  Thực hiện bên trong chương trình  Sử dụng các đặc tả chi tiết Kiểm thử hộp trắng thường được áp dụng ở giai đoạn đầu của kiểm thử, còn kiểm thử hộp đen được áp dụng ở giai đoạn sau của kiểm thử Câu 41: Một ca kiểm thử là cái gì? Mục tiêu thiết kế ca kiểm thử? Các bước để thiết kế một ca kiểm thử? -Một ca kiểm thử ( Test case ) – (slide 3.32):... chiến lược kiểm thử phần mềm? *Chiến lược kiểm thử phần mềm là: phải tìm ra được lỗi trong phần mềm đó và thiết lập chất lượng cho phần mềm này “Chỉ có kiểm thử mọi khía cạnh mới có thể chỉ ra được 1 chương trình là không có lỗi Tuy nhiên, việc kiểm thử mọi khía cạnh này là điều không thể.” *Nguyên tắc trong chiến lược kiểm thử phần mềm: • Tất cả các kiểm thử nên có khả năng theo dõi được các yêu cầu... cho việc kiểm thử phần mềm: nguyên lý Pareto hàm ý rằng 80% tất cả các lỗi phát hiện trong quá trình kiểm thử sẽ có khả năng theo dõi tới 20% tất cả các thành phần chương trình.Dĩ nhiên, vấn đề này là phải hoàn toàn tách biệt các thành phần khả nghi này và phải kiểm thử chúng hoàn toàn • Việc kiểm thử nên bắt đầu “trong quy mô nhỏ” và tiến hành việc kiểm thử sau đó “trong quy mô lớn”: Kiểm thử đầu tiên... bất cứ một lỗi nào + Kiểm thử tốt nhất khi hệ thống đã đưa vào sử dụng + Chỉ kiểm thử một hoặc hai lần + Người lập trình có thể làm tất cả các công việc kiểm thử một khi họ đã code xong … (Practical Guide to Software System Testing, 1.2 Testing Myths ) Câu 38 Thế nào là một ca kiểm thử tốt? ca kiểm thử thành công? Lợi ích phụ của kiểm thử là gì? • Một ca kiểm thử tốt là một ca kiểm thử có nhiều khả năng... thông báo hay kho dữ liệu sẽ được kiểm thử để phát hiện ra lỗi trong việc định kích cỡ cho các kho lưu trữ dữ liệu này - Kiểm thử hệ thống (system testing): phần mềm và phần cứng được tích hợp và kiểm thử hệ thống được thực hiện để phát hiện ra lỗi trong giao diện giữa phần mềm /phần cứng Hầu hết các hệ thống thời gian thực đều xử lý ngắt Do đó việc kiểm thử khả năng kiểm soát các sự kiện boolean là... chính xác và có ích về các vấn đề xảy ra Mục tiêu chính của quá trình kiểm thử là: phát hiện các lỗi trong phần mềm, bao gồm các lỗi trong: +yêu cầu từ phân tích yêu cầu +thiết kế tài liệu trong đặc tả thiết kế +lập trình +tài nguyên và môi trường hệ thống +các vấn đề về phần cứng Các quan niệm sai về kiểm thử phần mềm: + Kiểm thử là một công việc chán ngắt, buồn tẻ + Kiểm thử có thể phát hiện ra tất ... niệm sai kiểm thử phần mềm: 24 Câu 37 Tại phải kiểm thử phần mềm? Mục tiêu kiểm thử gì? Từ có quan niệm sai kiểm thử phần mềm? Tại phải kiểm thử phần mềm + Do phần mềm hay có lỗi, cần kiểm thử để... c Kiểm thử đơn vị, d Kiểm thử tích hợp, e Kiểm thử hệ thống…-> nói tất) Các phương pháp kiểm thử phần mềm : + Kiểm thử hộp trắng + Kiểm thử hộp đen + Kiểm thử đơn vị + Kiểm thử tích hợp 26 + Kiểm. .. phải kiểm thử phần mềm? Mục tiêu kiểm thử gì? Từ có quan niệm sai kiểm thử phần mềm? Việc kiểm thử phần mềm cần thiết để xác định phần mềm tạo có đáp ứng yêu cầu hay không Mục tiêu kiểm thử: