CÂU HỎI ÔN TẬP KỸ NGHỆ PHẦN MỀM NÂNG CAO Tập hợp 87 câu hỏi và đáp án môn học này Câu 1: a. Độ tin cậy phần mềm: là độ đo về mức tốt của các dịch vụ mà hệ cung cấp cho máy tính b. Một số cách đo độ tin cậy của phần mềm: Xác suất thất bại tính theo đòi hỏi Tỷ lệ xuất hiện thất bại Thời gian trung bình giữa 1 thất bại liên tiếp nhau Độ đo mức sẵn sàng hoạt động của hệ
Trang 1CÂU HỎI ÔN TẬP KỸ NGHỆ PHẦN MỀM NÂNG CAO
Câu 1:
a Độ tin cậy phần mềm: là độ đo về mức tốt của các dịch vụ mà hệ cung cấp cho máy tính
b Một số cách đo độ tin cậy của phần mềm:
- Xác suất thất bại tính theo đòi hỏi
- Tỷ lệ xuất hiện thất bại
- Thời gian trung bình giữa 1 thất bại liên tiếp nhau
- Độ đo mức sẵn sàng hoạt động của hệ
Câu2: Cái gì được dùng làm cơ sở để kiểm định chất lượng phần mềm:
Để đánh giá chất lượng phần mềm người ta dựa vào quan điểm chính sau:
Yêu cầu phần mềm là cơ sở để đo chất lượng:
Sự phù hợp với yêu cầu là có chất lượng
Phù hợp yêu cầu cả về số lượng và chất lượng
Yêu cầu thể hiện bằng đặc tả - đặc tả phải có chuẩn của nó mới kiểm tra được
Các chuẩn đặc tả xác định một bộ các tiêu chuẩn phát triển, các tiêu chuẩn này hướng dẫncách thức làm ra phần mềm: nếu không tuân thủ các tiêu chuẩn đó thì hầu như chắc chắn làchất lượng sẽ kém
Luôn có một tập các yêu cầu ngầm thường ít được nhắc đến
Quá thông dụng, hiển nhiên (sử dụng cửa số)
Không thể hiện ra ngoài (quy tắc nghiệp vụ)
Nếu phần mềm chỉ phù hợp với các yêu cầu đã hiển thị mà chưa phù hợp với yêu cầu ngầmthì chất lượng phần mềm là đáng nghi ngờ
Cần làm rõ yêu cầu và đưa vào đặc tả càng nhiều càng tốt
Câu 3: Các nhân tố ảnh hưởng lên chất lượng phần mềm có mấy mức độ? Những loại
nhân tố nào ảnh hưởng đến chất lượng?
- Có 2 loại mức độ ảnh hưởng
Nhân tố trực tiếp
Nhân tố gián tiếp
- Có 3 loại nhân tố ảnh hưởng đến chất lượng
Đặc trưng chức năng
Khả năng đương đầu với những thay đổi
khả năng thích nghi với môi trường mới
Câu 4: Nêu các đặc trưng ảnh hưởng lên chất lượng của mỗi loại nhân tố: đặc trưng chức
năng, khả năng thích nghi với thay đổi, khả năng thích nghi với môi trường
McCall đề xuất 11 nhân tố và phân thành 3 loại:
(1) đặc trưng chức năng
(2) khả năng đương đầu với những thay đổi
(3) khả năng thích nghi với môi trường mới
Loại 1: Các đặc trưng chức năng - (5)
Tính đúng đắn
- Có làm đúng với cái tôi muốn hay không?
- Có thỏa mãn những điều đã được đặc tả chưa?
- Có thực hiện được những mục tiêu nhiệm vụ của khách hàng chưa?
o Độ đày đủ
o Độ hòa hợp
o Độ lần vết được
Tính tin tưởng được
- mức hy vọng vào sự thực hiện các chức năng dự kiến
- mức chính xác được đòi hỏi
Trang 2o Độ chính xác
o Độ phức tạp
o Độ hòa hợp
o Độ dung thứ lỗi
o Độ đo mođun hoá
o Độ đơn giản – dễ hiểu.
o Độ đo khả năng huấn luyện
Loại 2: khả năng đương đầu với những thay đổi - (3)
Tính bảo trì được: nỗ lực đòi hỏi để định vị và xác định được một sai trong chươngtrình
o Độ đơn giản - dễ hiểu
Tính mềm dẻo: nỗ lực đòi hỏi để cải biên một chương trình
o Độ đơn giản - dễ hiểu
Tính thử nghiệm được: nỗ lực đòi hỏi để thử nghiệm một chương trình và bảo đảmrằng nó thực hiện chức năng được dự định cho nó
o Độ kiểm toán được
Trang 3 Loại 3: khả năng thích nghi với môi trường mới - (3)
Tính mang chuyển được: nỗ lực đòi hỏi để chuyển nó từ một môi trường phầncứng/phần mềm này sang một môi trường phần cứng/phần mềm khác
o Độ đo mođun hoá
o Độ tự tạo tài liệu
o Độ độc lập hệ thống phần mềm
Tính liên tác được: nỗ lực đòi hỏi để ghép đôi một hệ thống vào một hệ thống khác
o Độ tương đồng giao tiếp
o Độ tương đồng dữ liệu
o Độ khái quát
o Độ đo mođun hoá.
Có hai mức độ ảnh hưởng
Nhân tố trực tiếp: có thể thực tiếp đo như lỗi/KLOC/ đơn vị thời gian
Nhân tố gián tiếp: nhân tố chỉ có thể đo được một cách gián tiếp như tính bảo trì
Nhân tố
Độ đo Đúngđắn Tincậy
được
Hiệuquả
Toànvẹn
Khảdụng Bảotrì
được
Mềmdẻo
Thửnghiệmđược
g lạiđược
Liêntácđược
Trang 4 Nhân tố trực tiếp: có thể trực tiếp đo như lỗi/KLOC/ đơn vị thời gian
Câu 6: Kể ra các độ đo đặc trưng chất lượng chính của McCall? Giải thích nội dung của
nó?
McCall đề xuất 22 độ đo sau:
(1) Độ kiểm toán được: có thể kiểm tra dễ dàng về việc tuân thủ các chuẩn
(2) Độ chính xác: Độ chính xác của tính toán và điều khiển
(3) Độ tương đồng giao tiếp: mức độ sử dụng các giao diện, giao thức và giải thông chuẩn (4) Độ đầy đủ: mức độ theo đó các việc cài đặt đầy đủ cho các chức năng yêu cầu đã được
đạt tới
(5) Độ phức tạp: tránh dùng chương trình có độ phức tạp cao
(6) Độ súc tích (conciseness): độ gọn của chương trình dưới dạng số dòng mã.
(7) Độ hoà hợp (consistancy): việc dùng kỹ thuật thiết kế và tư liệu thống nhất trong toàn
(10)Độ hiệu qủa thực hiện: hiệu năng khi chạy của chương trình
(11)Độ khuếch trương được:Mức độ theo đó thiết kế kiến trúc, dữ liệu hay thủ tục có thể
được mở rộng
(12)Độ khái quát: độ rộng rãi của ứng dụng tiềm năng của các thành phần chương trình.
(13)Độ độc lập phần cứng: mức độ theo đó phần mềm tách biệt được với phần cứng mà
nó vận hành
(14)Trang bị đồ nghề đủ (instrumentation):mức độ theo đó chương trình điều phối thao tác
của riêng nó và xác định các lỗi xuất hiện
(15)Độ đo mođun hoá: sự độc lập chức năng của các thành phần trong chương trình
(16)Độ dễ thao tác: Việc dễ vận hành trong chương trình
(17)Độ an ninh: có sẵn cơ chế kiển soát hay bảo vệ chương trình và dữ liệu.
(18)Độ tự tạo tài liệu (self-doccumentation): mức độ theo đó mã gốc cung cấp tài liệu có ý
nghĩa
(19)Độ đơn giản - dễ hiểu: mức độ theo đó người ta có thể hiểu được chương trình không
khó khăn
Trang 5(20)Độ độc lập hệ thống phần mềm: mức độ theo đó chương trình được độc lập với các tính
năng ngôn ngữ lập trình, các đặc trưng hệ điều hành và những ràng buộc môi trườngkhông chuẩn khác
(21)Độ lần vết được: khả năng theo dõi các dấu vết của một biểu diễn thiết kế hay thành
phần của chương trình thực hiện so với yêu cầu
(22)Độ đo khả năng huấn luyện: Mức độ theo đó phần mềm trợ giúp làm cho người dùng
mới dùng được hệ thống
Câu 7: Giải thích nội dung các thuộc tính chất lượng phần mềm sau đây và nêu ra các độ
đo liên quan được sử dụng để đo thuộc tính đó:
Tính đúng đắn
- Làm đúng với khách hàng mong muốn
- Có thỏa mãn những điều đã được đặc tả (những yêu cầu của đối tượng khác)
o Độ đày đủ
o Độ hòa hợp
o Độ lần vết được
Tính tin cậy được
- Có thể trông đợi vào sự thực hiện các chức năng dự kiến
- mức chính xác được đòi hỏi
o Độ chính xác
o Độ phức tạp
o Độ hòa hợp
o Độ dung thứ lỗi
o Độ đo mođun hoá
o Độ đơn giản – dễ hiểu.
o Độ đo khả năng huấn luyện
Tính bảo trì được: nỗ lực cần để định vị và xác định được một lỗi trong chương trình làchấp nhận được
o Độ đơn giản - dễ hiểu
Tính mềm dẻo: nỗ lực cần để cải biên một chương trình là chấp nhận được
Trang 6o Độ đơn giản - dễ hiểu
Tính thử nghiệm được: nỗ lực cần để thử nghiệm một chương trình và bảo đảm rằng
nó thực hiện đúng chức năng dự định là chấp nhận được
o Độ kiểm toán được
o Độ phức tạp
o Trang bị đồ nghề đủ
o Độ đo mođun hoá
o Độ tự cấp tài liệu
o Độ đơn giản - dễ hiểu
Tính mang chuyển được: nỗ lực đòi hỏi để chuyển nó từ một môi trường phầncứng/phần mềm này sang một môi trường phần cứng/phần mềm khác là chấp nhậnđược
o Độ đo mođun hoá
o Độ tự tạo tài liệu
o Độ đo mođun hoá.
Câu 8: Đảm bảo chất lượng phần mềm xuất phát từ đâu? Tiến triển của nó như thế nào
- Khi phần mềm trở thành sản phẩm có nhu cầu và đòi hỏi đảm bảo chất lượng:
• Từ nhu cầu của khách hàng
• Từ nhà sản xuất: đảm bảo tính đồng đều của sản phẩm, cải thiện chất lượng thườngxuyên
- Sự phát triển của SQA
• Bảo đảm chất lượng là một hoạt động cốt yếu trong bất kỳ một doanh nghiệp nào làm rasản phẩm được người khác dùng
• Lịch sử bảo đảm chất lượng phần mềm (SQA) diễn ra song song với bảo đảm chất ượng trong chế tạo phần cứng
Trang 7l-• Các chuẩn bảo đảm chất lượng phần mềm đầu tiên được đưa ra trong quân sự, thờinhững năm 70 và nhanh chóng lan ra lĩnh vực thương mại
Câu 9:Tại sao cần đảm bảo chất lượng phần mềm? Nó đóng vai trò gì trong một doanh
nghiệp phát triển phần mềm?
Đảm bảo chất lượng phần mềm là các hoạt động nhằm mục tiêu là sản xuất ra phần mềm có chất lượng cao.
Phải đảm bảo chất lượng phần mềm vì
• Từ nhu cầu của khách hàng
• Từ nhà sản xuất: đảm bảo tính đồng đều của sản phẩm làm ra
• Giúp nhà phân tích có được đặc tả chất lượng cao
• Giúp nhà thiết kế có được thiết kế chất lượng cao
• Theo dõi chất lượng phần mềm
• Đánh giá ảnh hưởng của thay đổi về phương pháp luận và thủ tục lên chất lượng phầnmềm
• SQA có những lợi ích sau:
- phần mềm có ít các khiếm khuyết tiềm ẩn hơn và do đó mất ít công sức và thời gian
thử nghiệm và bảo trì
- Độ tin cậy cao hơn và do đó khách hàng thoả mãn hơn
- Giảm phí tổn bảo trì
- Giảm phí tổn tổng thể toàn bộ vòng đời của phần mềm
nó đóng vai trò trong một doanh nghiệp phát triển phần mềm
• Bảo đảm chất lượng là một hoạt động cốt yếu trong bất kỳ một doanh nghiệp nào làm rasản phẩm được người khác dùng
Câu 10: Trong một tổ chức ai là người tham gia vào hoạt động đảm bảo chất lượng? Vai
trò và trách nhiệm của mỗi đối tượng đó là gì?
Những người trong tổ chức có trách nhiệm bảo đảm chất lượng phần mềm:
- các kỹ sư phần mềm,
- các nhà quản lý dự án,
- khách hàng,
- người bán hàng,
- các cá nhân trong nhóm SQA.
• Nhóm SQA đóng vai trò như đại diện của khách hàng - để xem chất lượng phần mềmvới quan điểm khách hàng
• Có đáp ứng được các nhân tố chất lượng không?
• Có tuân theo các chuẩn dự định trước không?
• Các thủ tục phương pháp kỹ thuật có thực sự đóng vai trò của chúng trong hoạtđộng SQA?
Câu 11: Mục tiêu của SQA là gì? Các hoạt động chính đảm bảo chất lượng phần mềm là
những hoạt động nào?
Đảm bảo chất lượng phần mềm là các hoạt động nhằm mục tiêu là sản xuất ra phần mềm có chất lượng cao.
Có 7 hoạt động chính:
1 Áp dụng các phương pháp kỹ thuật tiến bộ
2 Tiến hành rà soát kỹ thuật chính thức
Trang 8Câu 12: Giải thích nội dung tóm tắt của mỗi hoạt động chính đảm bảo chất lượng?
1 Áp dụng các phương pháp kỹ thuật: giúp cho
- người phân tích có được đặc tả chất lượng cao
- người thiết kế có được thiết kế với chất lượng cao
2 Tiến hành rà soát kỹ thuật chính thức: được nhóm kỹ thuật tiến hành với mục đích là pháthiện ra vấn đề chất lượng
3 Kiểm thử phần mềm: là một chiến lược nhiều bước với một loạt các phương pháp thiết kếcác trường hợp kiểm thử giúp đảm bảo phát hiện ra các lỗi một cách hiệu quả
4 Bắt tuân theo các chuẩn: Là hình thức được áp dụng cho tiến trình kỹ nghệ phần mềmthay đổi tuỳ theo công ty
5 Khống chế các thay đổi: đóng góp trực tiếp vào chất lượng phần mềm nhờ
+ Chính thức hoá các yêu cầu đổi thay
+ Đánh giá bản chất của sự đổi thay
+ Khống chế các ảnh hưởng của sự đổi thay
+ Đe doạ chủ yếu của chất lượng đến từ sự thay đổi, thay đổi là bản chất của phầnmềm
+ thay đổi tạo ra tiềm năng sinh ra sai và tạo ra hiệu ứng phụ lan truyền
Áp dụng trong suốt quá trình phát triển và trong quá trình bảo trì
6 Đo lường: dùng để theo dõi chất lượng phần mềm và thẩm định tác dụng của những thayđổi phương pháp luận và thủ tục lên chất lượng phần mềm đã được cải tiến
7 Báo cáo và bảo quản các báo cáo: Kết quả của các cuộc họp xét duyệt , kiểm toán, kiểmsoát thay đổi, kiểm thử phải trở thành một phần của bản ghi lịch sử cho một dự án vàphải được phân phát cho nhóm phát triển trên cơ sở điều-cần - phải- biết
Câu 13: Rà soát phần mềm được hiểu là gì (khái niệm, mục tiêu, cách thức áp dụng)? Nêu các lợi ích của việc ra soát?
Khái niệm: Rà soát là việc xem xét, đánh giá sản phẩm được tiến hành mỗi giai đoạn để phát hiện ra những khiếm khuyết cần sửa chữa trước khi sang giai đoạn sau
Mục tiêu:
• Chỉ ra các chỗ khiếm khuyết cần phải cải thiện
• Khẳng định những sản phẩm đạt yêu cầu
• Kiểm soát việc đạt chất lượng kỹ thuật tối thiểu của sản phẩm
Cách thức áp dụng: Rà soát được áp dụng tại các thời điểm khác nhau trong quá trình phát triển phầm mềm
Có nhiều kiểu rà soát khác nhau:
• Các cuộc họp xét duyệt không chính thức
• Cuộc trình bày chính thức trước cử tọa gồm khách hàng, nhà quản lý, nhân viên kỹthuật (chỉ tập trung vào các rà soát kỹ thuật chính thức FTR-Format Technical Review)
Các lợi ích của việc ra soát
Lợi ích hiển nhiên của FTR là sớm phát hiện các “khiếm khuyết” phần mềm để có thểchỉnh sửa từng khiếm khuyết một trước khi bước sang bước tiếp theo của quá trìnhphần mềm
Các nghiên cứu của công nghiệp phần mềm đã chỉ ra rằng: các hoạt động thiết kế tạo
ra đến 50%-60% tổng số các khiểm khuyết tạo ra trong phát triển phần mềm
Chi phí chỉnh sửa một khiếm khuyết tăng lên nhanh chóng sau mỗi giai đoạn VD: Lỗikhông được phát hiện trong thiết kế tốn phí 1.0 để sửa chữa, trước kiểm thử nghiệm:6.5; trong thử nghiệm: 15 và sau khi phân phát sẽ là từ 60.0 đến 100.0
Câu 14: Các hình thức của hoạt động rà soát? trình bày khái niệm, mục tiêu của rà soát kỹ
thuật chính thức?
Có nhiều kiểu rà soát khác nhau:
• Các cuộc họp xét duyệt không chính thức
Trang 9• Cuộc trình bày chính thức trước khách hàng, nhà quản lý, thành viên kỹ thuật
Rà soát do các kỹ sư phần mềm thực hiện, là một phương tiện hiệu quả để cải thiện chấtlượng phần mềm
Rà soát kỹ thuật chính thức(FTR):
- Khái niệm: là hoạt động đảm bảo chất lượng phần mềm do những người đang tham
gia phát triển phần mềm thực hiện
- Mục tiêu:
(1) Phát hiện các lỗi trong chức năng, trong logic, trong triển khai
(2) Kiểm thử sự phù hợp của phần mềm với yêu cầu(3) Bảo đảm rằng phần mềm phù hợp với các chuẩn đã định sẵn (4) Đảm bảo “ phần mềm đã được phát triển theo một cách thức nhất quán.(5) Làm cho dự án dễ quản lý hơn
(6) Ngoài ra dùng để làm cơ sở huấn luyện các kỹ sư trẻ và có ích ngay cảcho những kỹ sư đã có kinh nghiệm
Câu 15: Vẽ sơ đồ tiến trình hoạt động rà soát va giải thích sơ bộ nội dung mỗi bước?
Giải thích:
- Mỗi cá nhân phát triển phải thông báo cho lãnh đạo dự án biết rằng sản phẩm đã
hoàn tất và cần phải rà soát
- Lãnh đạo dự án thông báo cho người chịu trách nhiệm rà soát biết
- Người chịu trách nhiệm lãnh đạo rà soát:
o Xem xét sản phẩm để đọc, rà soát
o Tạo ra các bản sao của sản phẩm , phân cho 2,3 người ra soát
o Thiết lập chương trình họp rà soát
- Những thực hiện rà soát: thường tốn 1-2 giờ để rà soát viết các bản ghi chú : tham
gia cuộc họp rà soát
Câu 16: Trình bày nội dung cơ bản 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 , sản phẩm?
Bất kể thế nào, mọi cuộc họp rà soát phải:
Thành phần: Có từ 3 đến 5 người liên quan tới việc rà soát, gồm có:
• lãnh đạo rà soát
• tất cả các cá nhân rà soát
• người tạo ra sản phẩm được rà soát
Thời gian:
• Phải có sự chuẩn bị trước, tuy nhiên mỗi người không quá 2 giờ chuẩn bị
• Cuộc họp nên ít hơn 2 giờ Mỗi cuộc họp rà soát chỉ hạn chế trong một phần nhỏ, cụthể
Công việc cần làm:
Trang 10• Trọng tâm của các cuộc họp rà soát là về sản phẩm: một thành phần (một thành phầncủa đặc tả yêu cầu, một thiết kế modul chi tiết, một danh sách mã nguồn cho mộtmodul)
• Phải đưa ra một trong 3 quyết định sau đây:
- Chấp nhận sản phẩm không cần chỉnh sửa
- Khước từ sản phẩm vì những lỗi nghiêm trọng
- Chấp nhận cho chỉnh sửa sản phẩm, sau khi chỉnh sửa phải có cuộc họp rà soát lại
• Mọi thành viên tham gia cuộc họp phải ký vào quyết định
Phương châm rà soát:
• Cần thiết lập trước phương châm rà soát, phân phát cho những người làm nhiệm vụ ràsoát, thống nhất tán thành và tuân thủ Một rà soát mà không khống chế được thì có thểcòn xấu hơn là không rà soát
• 10 điều tối thiểu trong phương châm rà soát kỹ thuật chính thức:
(1) rà soát sản phẩm, không rà soát người làm nó
(5) Nên có ghi chú trên bảng tường
(6) Giới hạn số người tham dự và kiên trì các dự kiến
(7) Lập một danh sách các kiểm tra cho từng sản phẩm sẽ được rà soát:
Giúp nhà lãnh đạo rà soát cấu trúc các cuộc họp FTR
Giúp người rà soát tập trung vào các vấn đề quan trọng
Danh sách kiểm tra lập cho từng loại sản phẩm:ành cho việc phân tích, thiết kế,
mã hoá kiểm tra và bảo trì
Một tập thể các đại diện sẽ xem lại danh sách này để trình
(8) Cấp phát nguồn lực và thời biểu cho các FTR: xem nó là một nhiệm vụ trong quátrình phát triển phần mềm, và cũng phải dự tính các cải biên cần thiết cho sự kiệnchưa dự đoán được
(9) Cần phải tiến hành huấn luyện chính thức cho các cá nhân ra soát
(10) Rà soát lại các rà soát trước đây
Câu 17: Các sản phẩm của cuộc họp rà soát là gì? Nội dung, vai trò của mỗi sản phẩm đó?
Sản phẩm của cuộc họp rà soát là:
• Báo cáo các vấn đề nảy sinh do các cá nhân rà soát nêu ra
• Một danh sách các vấn đề cần giải quyết do cuộc họp thống nhất
để nhận ra vùng có vấn đề trong sản phẩm được rà soát
dùng như một danh sách các khoản mục hành động để chỉ cho người làm ra sảnphẩm cần chỉnh sửa
Cần thiết lập một thủ tục để bảo đảm rằng các khoản mục trong danh sách đó sẽđược chỉnh sửa thực sự
• Một văn bản tổng kết cuộc họp rà soát đó, văn bản này phải chỉ rõ
Rà soát cái gì
Ai rà soát
Tìm thấy cái gì? và kết luận
Câu 18: Khi nào tiến hành rà soát? Cần rà soát những sản phẩm gì
- Mọi sản phẩm tạo ra ở mỗi bước đều được rà soát (không chỉ sản phẩm cuối cùng)
- Rà soát được tiến hành suốt quá trình phát triển
Trang 11- Tiến trình phát triển chung nhất gồm 4-5 giai đoạn:
Rà soát bám theo các sản phẩm của rà soát này
Câu 19: Trình bày nội dung danh mục rà soát của?
Danh mục rà soát trong kỹ nghệ hệ thống:
Bảo đảm chất lượng mức này là đánh giá yêu cầu thẩm duyệt ở mức hệ thống: Một cuộc họp lớn gồm đại diện các đơn vị liên quan
(1) Các chức năng chủ yếu đã được xác định đủ và rõ ràng(không mơ hồ)?
(2) Các giao diện giữa các hệ con của hệ thống đã được xác định đủ và đúng hay chưa?(3) Các ràng buộc thực thi đã được thiết lập cho toàn hệ thống và cho từng phần tử hay ch-ưa?
(4) Các ràng buộc thiết kế đã được thiết lập cho từng phần tử hay chưa?
(5) khả năng chọn đã là đã tốt nhất chưa?
(6) Giải pháp này có khả thi kỹ thuật không?
(7) Cơ chế kiểm chứng và thẩm duyệt đã đwợc thiết lập hay chưa?
(8) Có sự hoà hợp giữa các phần tử của hệ thống hay chưa?
Rà soát việc lập kế hoạch
Lập kế hoạch dự án phần mềm dựa trên sản phẩm của kỹ nghệ hệ thống để đưa ra các nội dungchủ yếu:
+ Phạm vi công việc kiểm tra thực hiện
+ ước lượng nguồn lực, giá cả, thời gian công việc
+ Lịch biểu thực hiện
+ Tổ chức, nhân sự, cơ chế triển khai
+ đánh giá rủi ro và kế hoạch khác
Danh mục
(1)Phạm vi của phần mềm đã xác định đúng đắn chưa? có bị hạn chế hay không?
(2)Thuật ngữ có trong sáng không?
(3)Các nguồn lực (người, chi phí, thời gian): có đủ tương xứng với phạm vi đó không? Cácnguồn lực đã có sẵn sàng chưa?cơ sở dự đoán giá cả có hợp lý không? dữ liệu năng xuất
và chất lượng trước đây có được sử dụng không? Sự khác biệt của ước lượng đã được sử
lý chưa?
(4)Các công việc lên lịch biểu đã: xác định thích hợp chưa? Sắp xếp trình tự thực hiện đúnglogic chưa? bố trí song song có phù hợp với các nguồn lực đã sẵn có hay không?
(5)Phương án tổ chức và nhân sự đã hợp lý chưa?
(6)Các rủi ro trong tất cả các hạng mục quan trọng đã: xác định và đánh giá đầy đủ chưa?Lập kế hoạch quản lý và kế hoạch thích hợp chưa?
(7)Các nhiệm vụ đã thật sự được xác định và sắp xếp tuần tự chưa?, tính song song có hợp
lý đối với các nguồn lực đã sẵn có hay chưa?
(8)Ngân sách và giới hạn chót được dự kiến: có hiện thực hay không? có phù hợp với lịchbiểu không?
Trình bày những nội dung cơ bản (mục tiêu, nội dung, danh mục) của
- rà soát phân tích yêu cầu phần mềm
- rà soát thiết kế phần mềm ( tương ứng với từng giai đoạn thiết kế)
- rà soát lập mã phần mềm
- rà soát kiểm thử phần mềm (tương ứng với kế hoạch và thủ tục kiểm thử)
- rà soát bảo trì phần mềm (ứng với kế hoạch và thủ tục kiểm thử)
Trang 12 rà soát phân tích yêu cầu phần mềm
Mục tiêu: thẩm định và xác minh yêu cầu phần mềm
phải chỉ ra các nhu cầu của người dùng là được thoả mãn
Các yêu cầu phải nhất quán, nghĩa là không mâu thuẫn nhau
Các yêu cầu phải đầy đủ: chúng phải chứa mọi chức năng và mọi ràng buộc mà người
sự phù hợp và tính đúng đắn của mô hình phân tích
Với các hệ thống lớn cần tăng cường:
Các rà soát kỹ thuật chính thứcviệc đánh giá các nguyên mẫu cũng như các cuộc họp với khách hàng
Danh mục: xem xét các chủ đề sau:
(1) Phân hoạch vấn đề (hệ con) có đầy đủ hay không?
(2) Các giao diện trong và ngoài đã thực sự được xác định chưa?
(3) Phân tích lĩnh vực thông tin có đầy đủ, phi mâu thuẫn và chính xác hay ko?
(4) Mô hình dữ liệu đã thực sự phản ánh các đối tượng dữ liệu, các thuộc tính và các
quan hệ?
(5) Tất cả các yêu cầu có thể lần vết được ở mức hệ thống không?
(6) Đã làm bản mẫu dành cho người sử dụng (khách hàng) chưa?
(7) Liệu có thực hiện được với những ràng buộc quy định bởi các phần tử hệ thống
khác hay không?
(8) Các yêu cầu có phù hợp với lịch biểu, nguồn lực và kinh phí hay không?
(9) Các chuẩn thẩm định có đầy đủ hay không?
rà soát thiết kế phần mềm ( tương ứng với từng giai đoạn thiết kế)
Mục tiêu: Hướng đến thiết kế đảm bảo hai yêu cầu
Cấu trúc tốt (phân hoạch, giao diện, modul hoá)
Thuật toán tốt (ít phức tạp, tốc độ cao, dễ hiểu)
Dữ liệu tốt (cấu trúc, biểu diễn)
Có thể lần vết được (dễ hiểu, dễ kiểm tra)
Có 2 kiểu rà soát thiết kế (phù hợp với bước triển khai):
rà soát thiết kế sơ bộ - preliminary design review (đánh giá việc dịch các yêu cầu thành thiết kế dữ liệu và thiết kế kiến trúc),
rà soát thiết kế trọn vẹn - design walkthrough (tập trung vào tính đúng đắn của thuật toán)
Trang 13 Rà soát thiết kế sơ bộ
(1) Các yêu cầu phần mềm có được phản ánh trong kiến trúc phần mềm hay không?(2) Có đạt được sự môđun hoá hiệu quả không? Các môđun có độc lập chức năng hay không
(3) Kiến trúc chơng trình có được phân tách không?
(4) Các giao diện đã được xác định cho các môđun và các phần tử hệ thống ngoại lai ưa?
ch-(5) Cấu trúc dữ liệu có phù hợp với lĩnh vực thông tin chưa?
(6) Cấu trúc dữ liệu có phù hợp với yêu cầu phần mềm chưa?
(7) Khả năng bảo trì đã được xem xét chưa?
(8) Các nhân tố chất lượng đã được đánh giá rõ ràng chưa?
Rà soát thiết kế toàn bộ
(1) Thuật toán có hoàn thành chức năng mong muốn không?
(2) Thuật toán có đúng đắn logic không?
(3) Giao diện có phù hợp với thiết kế kiến trúc không?
(4) Độ phức tạp logic có phải chăng hay không?
(5) Sử lý sai đã được đặc tả chưa?
(6) Cấu trúc dữ liệu cục bộ có thật sự đã được xác định?
(7) Kiến tạo lập trình cấu trúc đã xuyên suốt chưa?
(8) Các chi tiết thiết kế đã tuân theo ngôn ngữ thực hiện chưa?
(9) Dùng các đặc điểm hệ điều hành hay là phụ thuộc ngôn ngữ?
(10) Đó dùng logic compound hoặc logic inverse?
(11) Khả năng bảo trì đã được xét tới chưa
rà soát lập mã phần mềm
Mục tiêu: rà soát hướng đến mã nguồn đạt được
phản ánh đầy đủ, phù hợp với thiết kế
phù hợp với ngôn ngữ sử dụng (chuẩn, cú pháp, khai báo dữ liệu )
Văn bản chương trình tốt (không lỗi chính tả, có cấu trúc, nhất quán )
(1) Thiết kế có thực sự được dịch thành mã chưa?
(2) Có các sai sót chính tả hoặc in ấn nào không?
(3) Có thực sự dùng các quy ước ngôn ngữ hay không?
(4) Có phục tùng về các chuẩn mẫu lập mã đối với phong cách ngôn ngữ, ghi chú (5) Có ghi chú nào không đúng đắn hoặc mơ hồ?
(6) Kiểu dữ liệu và khai báo dữ liệu có chính xác hay không?
Đánh giá một cách phê phán các kế hoạch kiểm thử và các thủ tục kiểm thử
hướng đến đảm bảo các phương pháp, các chiến lược và các kỹ thuật được sử dụng và
Trang 14 Tài liệu kiểm thử: các ca kiểm thử, tiến trình, lịch trình
Các yêu cầu: phần cứng, phần mềm, nhân sự
Kiểm soát quá trình kiểm thử
(3) Các chức năng chủ yếu có được trình diễn sớm không?
(4) Kế hoạch thử nghiệm có phù hợp với kế hoạch dự án tổng thể hay không?
(5) Lịch trình thử nghiệm có được xác định rõ ràng hay không?
(6) Nguồn lực và công cụ thử nghiệm đã đợc minh định và đã sẵn sàng hay chưa?
(7) Đã thiết lập cơ chế lưu trữ các báo cáo chưa?
(8) Các bộ lái (driver) và các cuống (stub) thử nghiệm đã được minh định chưa?; công việc phát triển chúng đã được lập lịch chưa?
(9) Thử nghiệm cường độ chịu áp lực cho phần mềm đã được đặc tả chưa?
(10) Cả hai loại thử nghiệm hộp trắng và hộp đen đã được đặc tả chưa?
(11) Có phải tất cả các đường logic độc lập đều được thử nghiệm?
(12) Có phải tất cả các ca thử nghiệm đều đã được minh định và lập danh sách với đủ các kết qủa chờ mong?
(13) Việc xử lý sai có được thử nghiệm?
(14) Các giá trị biên có được thử nghiệm?
(15) Các yêu cầu thời gian và sự diễn tiến có được thử nghiệm?
(16) Các biến thể chấp nhận được của kết quả thử nghiệm mong đợi đã được đặc tả chưa?
rà soát bảo trì phần mềm (ứng với kế hoạch và thủ tục kiểm thử)
(1) Đã xét đến các hiệu ứng phụ gắn với các đổi thay hay chưa?
(2) Xem xét yêu cầu đổi thay đã được lập tài liệu, được đánh giá và được chấp thuận hay chưa?
(3) Báo cáo xem xét sự đổi thay cho tất cả các bên quan tâm hay chưa?
(4) Các rà soát kỹ thuật chính thức thích hợp đã được tiến hành hay chưa?
(5) Một rà soát chấp thuận cuối cùng đã được thực hiện để bảo đảm rằng toàn bộ phần mềm
đã thực sự được cập nhật, được thử nghiệm và được thay thế hay chưa?
D6: Đặc trưng vào/ra của mô dun D6=1-s7/s1
Trang 15Câu20:Số đo độ phức tạp của McCabedựa trên cái gì và những đại lượng cụ thể nào?
- Số đo dựa trên độ phức tạp chu trình trong đồ thị chương trình của một modun
+ Số chu trình có chu trình lồng nhau
+ Số chu trình trong một chu trình
- Người ta cũng dùng các miền phẳng của đồ thị phẳng để biểu diễn đồ thị chương trình
Câu21: Đảm bảo chất lượng phần mềm dựa trên thống kê nghĩa là gì?Nó gồm những công việc gì? Kể ít nhất năm nguyên nhân của những khuyết điểm trong phần mềm?
Là bảo đảm chất lượng thống kê phản ánh một xu thế ngày càng tăng trong công nghiệp.Công việc bao gồm:
- Thu thập và phân loại thông tin khiếm khuyết phần mềm
- Cố gắng lần vết để tìm ra nguyên nhân
- Dùng nguyên lý Pare cô lập 20% khiếm khuyết
- Sau khi tìm được nguyên nhân sẽ chỉnh sửa các nguyên nhân của khiếm khuyết
Các nguyên nhân gây ra khiếm khuyết có thể là:
- Đặc tả không đầy đủ hoặc sai sót (IES)
- Hiểu nhầm khi giao tiếp với khách hàng (MCC)
- Lệch hướng dự định khi đặc tả (IDS)
- Vi phạm các chuẩn lập trình (VPS)
- Sai trong biểu diễn dữ liệu (EDR)
- Không phù hợp với giao diện modun (IMI)
- Sai trong logic thiết kế (EDL)
- Thử nghiệm sai hoặc không đầy đủ (IET)
Câu 22: Tiếp cận hình thức cho SQA nghĩa là gì? Quá trình phòng sạch là gì? Phương
châm của kỹ thuật này là gì?
Người ta nhận thấy cần phải dùng một cách tiếp cận hình thức hơn trong việc bảo đảmchất lượng phần mềm, cách tiếp cận này sẽ bổ sung cho các hoạt động mô tả ở trênTiếp cận hình thức hoá: đặc tả hình thức cho phép chứng minh tính đúng đắn, kiểm tralỗi, chuyển tự động thành chương trình làm tăng chất lượng
- Kiểm chứng chương trình một cách hình thức (chứng minh tính đúng đắn) và bảo đảmchất lượng phần mềm thống kê hợp lại với nhau cho ta ta một kỹ thuật cải thiện chấtlượng sản phẩm, được gọi là quá trình phòng sạch
- Phương châm của kỹ thuật này là: Phòng khiếm khuyết hơn là trừ khiếm khuyết Câu23: Độ tin cậy của phần mềm là cái gì? Đo độ tin cậy dựa trên những dữ liệu nào?
- Độ tin cậy của phần mềm là một yếu tố quan trọng trong chất lượng phần mềm
- Độ tin cậy phần mềm được định nghĩa theo thuật ngữ thống kê: “xác suất thao tác khôngthất bại của chương trình máy tính trong một môi trường đặt biệt với một thời gian đã định rõ”
- Độ tin cậy của phần mềm được đo trực tiếp và được đánh giá qua các dữ liệu phát triển và các dữ liệu lịch sử
Câu 24: Nêu chỉ 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 của nó?
- Với các hệ thống dựa trên máy tính thì một số đo đơn giản về độ tin cậy chính là thời gian trung bình giữa hai lần thất bại kế tiếp (MTBF- Mean Time Between Failure):
MTBF = MTTF + MTTR
- MTTF (Mean Time To Failure) là thời gian hoạt động liên tục trung bình
- MTTR (Mean Time To Repair) là thời gian sửa xong lỗi trung bình
Ý nghĩa:
MTBF là cách đo hữu ích hơn nhiều so với tỷ số “số khiếm khuyết”/KLOC (LOC-Line OfCode) vì người dùng cuối cùng quan tâm tới những thất bại chứ không quan tâm đếm lỗi (nhànghiên cứu)
Trang 16MT – Fa – Fc -Fd MT
Do các lỗi trong chương trình không có cùng mức độ (nặng, nhẹ khác nhau) nên số các lỗichỉ cho ta một chỉ số nhỏ về độ tin cậy của hệ thống
VD: Khi đưa 1 chương trình vào vận hành trong 14 tháng , trong các lỗi chưa được pháthiện có lỗi chỉ được phát hiện sau dăm chục năm, các lỗi còn lại với MTBF khoảng 18-24tháng
- Độ sẵn sàng phần mềm là xác suất để chương trình vận hành đúng với yêu cầu ở các thờiđiểm đã định và được tính như sau:
MTTF/(MTTF + MTTR) x100%
Ý nghĩa
Thể hiện tỷ lệ thời gian làm việc trung bình trong tổng thời gian vận hành
Là độ đo gián tiếp về khả năng bảo trì được (số này càng gần 100 là đã bảo trì tốt)
Câu 25: Có những mô hình độ tin cậy nào? Nó dựa trên tham biến nào và trên giả thiết
nào? Mô hình độ tin cậy gieo hạt dựa trên ý tưởng nào? Mục tiêu để làm gì
Có hai mô hình độ tin cậy phần mềm:
- Mô hình tiên đoán độ tin cậy như là một hàm của thời gian lịch
- Mô hình tiên đoán độ tin cậy như là một hàm của thời gian xử lý đã trôi qua (thời gian
vận hành của CPU) Loại này được coi là tốt hơn
Các mô hình độ tin cậy phần mềm dựa trên các giả thiết:
- Thời gian gỡ lỗi giữa các xuất hiện sai có phân phối mũ với nhịp độ xuất hiện sai, nhịp độnày tỷ lệ thuận với số các lỗi còn lại
- Mỗi lỗi bị phát hiện sẽ được loại trừ ngay lập tức và số lỗi còn lại giảm đi 1
- Nhịp độ thất bại giữa các lỗi là không thay đổi
Các giả thiết này còn phải bàn: vì một lỗi được loại trừ thì có thể nhiều lỗi khác lại đượcsinh ra
Một lớp các mô hình độ tin cậy phần mềm dựa vào các đặc trưng tồn tại của một chươngtrình và tính toán số dự đoán các sai tồn tại trong phần mềm
Các mô hình này dựa trên các quan hệ định lưwngj như một hàm của độ đo tính phức tạp,chúng liên kết thiết kế đặc chủng hoặc các thuộc tính hướng mã của chương trình với “mộtước định số khải phát các lỗi được tin rằng có trong chương trình đã cho”
Mô hình độ tin cậy gieo hạt dựa trên ý tưởng nào? Mục tiêu để làm gì?
Ý tưởng: Một chương trình được gieo một cách ngẫu nhiên một số các lỗi(k) hiệu chuẩn(calibration) vào một chương trình; sau đó đem kiểm thử (bằng một số ca thử nghiệm); tính
xác suất tìm được j lỗi trong tập J lỗixem như tương ứng với xác suất tìm được k lỗi đã gieo trong K lỗi đã nhúng vào chương trình
j/J=k/K
Mục đích:
- dùng như một chỉ báo của độ tin cậy phần mềm;
- hoặc một cách thực tiễn hơn như một độ đo “năng lực phát hiện sai” của một tập hợp các
là gây ra thất bại của toàn hệ thống
Độ an toàn phần mềm xem xét lại cách thức lỗi nảy sinh trong một điều kiện nào đó có thểdẫn tới rủi ro Nghĩa là lỗi không được xem xét trong chân không mà được đánh giá tronghoàn cảnh của toàn bộ hệ thống dựa trên máy tính
Có các phương pháp như:
Phân tích cây lỗi:
Trang 17 dựng lên một mô hình đồ thị các tổ hợp tuần tự và song song các sự kiện dẫn đến một sựkiện hay một trạng thái hệ thống mạo hiểm
Dùng một cây lỗi phát triển tốt có thể quan sát được hậu quả của một dãy các thất bại liênkết với nhau, xuất hiện trong các thành phần khác nhau của hệ thống
Logic thời gian thực: xây dựng mô hình hệ thống bằng các đặc tả các sự kiện và các hànhđộng tương ứng Mô hình sự kiện – hành động có thể được phân tích bằng cách dùng cáctoán tử logic để thử nghiệm các quyết đoán an toàn đối với các thành phần của hệ thống vàđịnh thời cho chúng
Mô hình lưới petry: dùng để xác định xem lỗi nào là nghiêm trọng nhất
Câu 27: Khảo sát nhu cầu SQA gồm những nội dung gì? nhằm trả lời các câu hỏi gì?nếu
có nhu cầu thì mình làm gì?
- Gồm ba nội dung nhằm trả lời ba câu hỏi
+ Kiểm kê các chính sách SQA: chính sách, thủ tục, chuẩn nào đã có trong các pha pháttriển?
+ Đánh giá vai trò của kỹ nghệ phần mềm, bảo đảm chất lượng trong tổ chức hiện tại cóquyền lực đến đâu?
+ Đánh giá mối quan hệ SQA: Giao diện chức năng giữa SQA với các đơn vị khác nhưthế nào? với các người thực hiện rà soát kỹ thuật chính thức, quản lý cấu hình và thử nghiệm
- Nếu có nhu cầu thì cần phải tiến hành đánh giá cẩn thận bằng quy tắc bỏ phiếu
Câu 28: Có những vấn đề gì đạt ra khi triển khai SQA? Lợi íchcủa SQA là gì? Nguyên tắc
chi phí hiệu quả của SQA là gì?
- SQA có những vấn đề sau đây
+ Khó thiết lập trong một tổ chức nhỏ: khó có nguồn lực để thực hiện các hoạt động cầnthiết mà hiện chưa có
+ Nó biểu thị một thay đổi có tính văn hoá: nên chẳng bao giờ dễ dàng thực hiện
+ Nó đòi hỏi tiêu tốn không ít tiền
- SQA có những lợi ích sau đây:
+ Phần mềm có ít các khiếm khuyết tiềm ẩn hơn và do đó mất ít công sức và thời giankiểm thử và bảo trì
+ Độ tin cậy cao hơn và do đó khách hàng thoả mãn hơn
+ Giảm phí tổn bảo trì
+ Giảm phí tổn tổng thể toàn bộ vòng đời của phần mềm
- Nguyên tắc chi phí: Ở mức cơ bản SQA được xem là hiệu quả về chi phí nếu
C3>C1 + C2
Ở đây:
+ C3 là chi phí từ các sai do không có SQA
+ C1 là chi phí cho SQA của chương trình
+ C2 là chi phí do các sai không tìm thấy khi chương trình đã có SQA
Câu 29: Tại sao phải kiểm thử phần mềm? Mục tiêu kiểm thử là gì? Từ đó có quan niệm
già sai về kiểm thử phần mềm?
Kiểm thử phần mềm là yếu tố quyết định của SQA và khâu điển hình của rá soát đặc tả thiết kế
và lập mã
Lý do cần kiểm thử phần mềm:
muốn nhìn thấy phần mềm như là một phần tử của hệ thống hoạt động
Hạn chế chi phí phải trả cho các thất bại do lỗi gây ra sau này
có kế hoạch tốt cho suốt quá trình phát triển
o Tầm quan trọng Kiểm thử chiếm:
- 40% tổng công sức phát triển
- >=30% tổng thời gian phát triển
Trang 18Độ tin cậy dự đoán
Với phần mềm ảnh hưởng tới sinh mạng chi phí có thể gấp từ 3 dến 4 lần tổng chi phíkhác cộng lại
Mục tiêu kiểm thử (Glen Myers): Kiểm thử là một quá trình vận hành chương trình để tìm
Một ca kiểm thử thắng lợi làm lộ ra khiếm khuyết, đồng thời mang lại các lợi ích phụ:
chứng tỏ rằng các chức năng phầm mềm làm việc tương ứng với đặc tả,
chứng tỏ các yêu cầu thực thi là phù hợp
có thêm các chỉ số độ tin cậy phần mềm và các chỉ số về chất lượng phần mềm nóichung
“Kiểm thử không thể chứng minh được việc không có khiếm khuyết, nó chỉ có thể chứngminh rằng khiếm khuyết phần mềm hiện hữu”
Người ta thường có những quan niệm sai gì về kiểm thử phần mềm?
- Người phát triển không tham gia kiểm thử
- Phần mềm được công bố một cách rộng rãi để người lạ kiểm thử nó một cách tàn nhẫn
- Người kiểm thử chỉ quan tâm khi kiểm bắt đầu
- Kiểm thử có thể chứng minh được phần mềm không có khiếm khuyết
- Phép kiểm thử thành công là kiểm thử không tìm ra lỗi nào
Một ca kiểm thử thắng lợi làm lộ ra khiếm khuyết, đồng thời mang lại các lợi ích phụ:
chứng tỏ rằng các chức năng phầm mềm làm việc tương ứng với đặc tả,
chứng tỏ các yêu cầu thực thi là phù hợp
có thêm các chỉ số độ tin cậy phần mềm và các chỉ số về chất lượng phần mềm nóichung
Câu 31: Biểu đồ dòng thông tin kiểm thử mô tả cái gì? vẽ biểu đồ của nó?
Biểu đồ dòng thông tin kiểm thử tuân theo hình mẫu được mô tả như sau:
Hai lớp được cung cấp cho tiến trình kiểm thử:
(1) Cấu hình phần mềm: Bản Đặc tả yêu cầu phần mềm, bản Đặc tả thiết kế, chương trình gốc (2) Cấu hình kiểm thử: Kế hoạch và thủ tục kiểm thử, các công cụ kiểm thử dự định dùng, các
ca kiểm thử cùng kết quả dự kiến.
Kiểm thử được tiến hành và tất cả các kết quả được đánh giá bằng cách so sánh với kếtquả dự kiến Khi phát hiện lỗi, việc gỡ lỗi bắt đầu được tiến hành
Trang 19Tiến trình gỡ lỗi thường không dự kiến được thời gian nên việc lập lịch kiểm thử trởnên khó khăn.Ví dụ: 1 lỗi chỉ ra sự sai biệt độ 0.01% giữa kết quả trông đợi và thực tại cóthể mất 1 giờ, 1 ngày hay 1 tháng để chuẩn đoán và sửa chữa.
Khi các kết quả kiểm thử được thu thập và đánh giá thì chất lượng và độ tin cậy phầnmềm dần được khẳng định Nếu hay gặp phải lỗi nghiêm trọng yêu cầu sửa đổi thết kế thìchất lượng và độ tin cậy là đáng ngờ và cần kiểm thử thêm
Mặt khác, nếu các chức năng phần mềm dường như làm việc đúng và lỗi gặp phải là dễsửa thì có thể rút ra một trong hai kết luận:
(1) Chất lượng và độ tin cậy phần mềm chấp nhận được
(2) Kiểm thử không tương xứng để làm lộ ra những lỗi nghiêm trọng
Nếu việc kiểm thử không làm lộ ra lỗi nào thì có thể hoài nghi rằng cấu hình kiểm thửchưa được cân nhắc đúng mức, các lỗi vẫn còn ẩn núp trong phần mềm và sẽ bị phát hiệnbởi người dùng
Câu 32: Kể các đối tượng và phương pháp kiểm thử phần mềm? Mỗi phương pháp đó
thường được sử dụng vào giai đọan nào của quá trình phát triển?
Đối tượng và phương pháp kiểm thử
Phương pháp Hộp trắng Hộp đen và trắng Hộp đen Mô hình
Mỗi phương pháp đó thường được sử dụng vào giai đoạn nào của quá trình phát triển:
- Hộp trắng: sử dụng trong giai đoạn Mã hóa
Trong các thập kỷ 80-90 đã có nhiều loại phương pháp thiết kế ca kiểm thử
Các phương pháp tốt phải cho một cơ chế giúp ta bảo đảm tính đầy đủ và cung cấp cho tamột khả năng thật sự phát hiện được các sai trong phần mềm
Có thể kiểm thử theo một trong hai kỹ thuật sau:
Kiểm thử hộp đen
Kiểm thử hộp trắng
Câu 34: Kiểm thử hộp trắng là cái gì? Nó nhằm kiểm tra những nội dung nào?
Kiểm thử trực tiếp trên mã nguồn
Khám xét các chi tiết thủ tục, các con đường logic, các trạng thái của chương trình
Chú ý rằng số con đường logic là lớn một chương trình nhỏ, chẳng hạn chỉ có 100 dòngPASCAL với một vòng lặp thì số con đường có thể xét lên đến 1014 và giả sử một kiểmthử hetes 1ms thì tốn 3170 năm làm kiểm thử cho tất cả các con đường đó
Sử dụng cấu trúc điều khiển của thiết kế thủ tục để hình thành các ca kiểm thử
Đảm bảo:
o Mọi con đường độc lập trong modun cần được thực hiện ít nhất một lần
o Mọi ràng buộc logic được thực hiện cả hai phía đúng và phía sai
o Thực hiện tất cả các vòng lặp biên của nó và cả với các biên vận hành
o Thực hiện Các cấu trúc dữ liệu nội tại để đảm bảo tính hiệu lực của nó
Câu 35: Kiểm thử hộp đen là cái gì? Nó giúp kiểm tra những nội dung nào của đối tượng
kiểm thử?
Chỉ thực hiện các phép thử tiến hành qua giao diện phần mềm
Trang 20 Dùng để thuyết minh các chức năng phần mềm đủ và vận hành đúng
Ít chú ý tới cấu trúc logic nội tại của phần mềm
Câu 36: Chiến lược kiểm thử phần mềm là cái gì? Nêu các nguyên tắc trong chiến lược
kiểm thử phần mềm?
Một chiến lược kiểm thử phần mềm là sự tích hợp các kỹ thuật thiết kế ca kiểm thử tạothành một kế hoạch gồm một dãy các bước hướng dẫn quá trình kiểm thử phần mềmthành công
Mỗi chiến lược kiểm thử phần mềm:
Phải tích hợp được:
- việc lập kế hoạch thử nghiệm
- việc thiết kế ca sử dụng
- việc tiến hành kiểm thử
- việc thu thập và đánh giá các thông tin kết quả
Phải đủ mềm dẻo để cổ vũ óc sáng tạo và việc theo ý khác hàng (mà tất cả các hệ thốnglớn dựa trên máy tính đều cần kiểm thử tương xứng)
Kiểm thử là một tập các hoạt động có thể lập kế hoạch trước được và được tiến hànhmột cách có hệ thống Chính vì vậy mà cần xác định một khuôn mẫu cho việc kiểm thửphần mềm trong tiến trình kỹ nghệ phần mềm
Nêu các nguyên tắc trong chiến lược kiểm thử phần mềm?
Các đặc trưng khái quát khôn mẫu
Bắt đầu mức modul và tiếp tục cho đến khi tích hợp thành một hệ thống dựa trên máytính trọn vẹn
Các kỹ thuật kiểm thử khác nhau là thích hợp tại những thời điểm khác nhau
Được cả người phát triển và nhóm kiểm thử độc lập cùng tiến hành
kiểm thử và gỡ lỗi, song việc gỡ lỗi phải thích ứng với từng chiến lược kiểm thử
Nguyên tắc
Chiến lược kiểm thử phần mềm phải thích ứng với các kiểm thử mức thấp (kiểm tra xemtừng khúc mã nguồn có được thực thi đúng đắn không) cũng như với các kiểm thử mứccao (thẩm định xem các chức năng hệ thống chủ yếu có đúng theo yêu cầu của kháchhàng không)
Mỗi chiến lược phải cung cấp các hướng dẫn cho những người thực hành để tiến hànhkiểm thử và cung cấp một tập các cột mốc cho các nhà quản lý để quản lý hoạt động đảmbảo chất lượng
Quá trình kiểm thử phải đo được để có thể nhận ra các vấn đề càng sớm càng tốt
Câu 37: Nêu các bước của chiến lược kiểm thử thời gian thực và giải thích nội dung của
mỗi bước
Gồm bốn bước:
1 Kiểm thử tác vụ: Kiểm thử từng tác vụ một cách độc lập với nhau (bằng cả kỹ thuật hộptrắng và hộp đen) Nó cho phép phát hiện sai về logic và chức năng Chưa phát hiện hiệnsai về thời gian và ứng xử
2 Kiểm thử ứng xử:
- Sử dụng công cụ CASE tạo mô hình hệ thống để mô phỏng ứng xử của hệ thờigian thực, xem ứng xử của nó như hậu quả của sự kiện ngoài Dùng kết quả hoạtđộng phân tích này để thiết kế ca kiểm thử (tương tự kỹ thuật đồ thi nhân quả)
- Phân lớp sự kiện: (tương tự phân hoạch tương đương)
Câu 38: Kiểm thử hộp trắng dựa trên cơ sơ nào để thiết kế ca kiểm thử? Thiết kế ca kiểm
thử phải đảm bảo điều kiện gì?
Kiểm thử hộp trắng sử dụng cấu trúc điều khiển của thiết kế thủ tục để hình thành các ca kiểmthử
Thiết kế ca kiểm thử phải đảm bảo:
Trang 21- Bảo đảm rằng mọi con đường độc lập trong một môđun đều được thực hiện ít nhất mộtlần.
- Mọi ràng buộc logic được thực hiện cả phía true và false
- Thực hiện tất cả các vòng lặp ở biên của nó và cả với biên vận hành của nó
- Thực hiện các cấu trúc dữ liệu nội tại để bảo đảm tính hiệu lực của nó
Câu 39: Ma trận thử nghiệm được cấu trúc như thế nào? Nó được dùng để làm gì?
Cấu trúc: Ma trận kiểm thử là ma trận vuông có kích thước bằng số các nút trong đồ thị dòng
- Mỗi dòng/cột ứng với tên một nút
- Mỗi ô là tên một cung nối nút dòng đến nút cột
Ma trận kiểm thử được sử dụng như là một dữ liệu có cấu trúc để kiểm tra các con đường cơbản
Để ma trận kiểm thử trở thành công cụ mạnh mẽ trong việc đánh giá cấu trúc điều khiểnchương trình khi thử nghiệm người ta sử dụng ma trận có trọng số (thêm trọng số cho cáccung) Trọng số có thể là:
- Xác suất cung đó được tiến hành
- Thời gian xử lý tốn trong quá trình đi ngang qua cung đó
- Bộ nhớ đòi hỏi trong quá trình đi ngang qua cung đó
- Nguồn lực được đòi hỏi trong quá trình đi ngang qua cung đó
Ma trận kiểm thử dùng như một dữ liệu có cấu trúc để kiểm tra các đường cơ bản (Vì thủtục để suy dẫn ra đồ thị dòng và xác định một tập các đường cơ bản tuân theo việc máy móchóa)
Câu 40: Nêu các loại điều khiển trong cấu trúc điều khiển và cho ví dụ? Có những loại sai
nào trong điều kiện khi kiểm thử
Các loại điều khiển:
- Điều khiển đơn: là 1 biến bool hoặc 1 biểu thức quan hệ (có thể có toán tử phủđịnh đứng đầu)
Biểu thức quan hệ là một biểu thức Bool xác định quan hễ giữa 2 biểu thức số họcbằng một phép so sánh: <, <=, =, >=, #
- Điều kiện kết hợp là điều kiện cấu thành từ hơn một điều kiện đơn nhờ các toán
tử Bool: hoặc hợp, giao, phủ địnhcác loại sai
- Sai biến, toán tử bool, sai số hạng trong biểu thức toán tử Bool, sai toán tử quan hệ, saibiểu thức số học
Câu 41: Kiểm thử điều khiển dòng dữ liệu nghĩa là gì? Cho ví dụ?
Phương pháp kiểm thử dòng dữ liệu là kiểm thử tuyển chọn các đường của chương trình tươngứng với việc định vị các xác định biến và các sử dụng biến trong chương trình Người ta đãnghiên cứu một số chiến lược thử nghiệm dòng dữ liệu và so sánh chúng
Giả sử rằng mỗi câu lệnh của chương trình được gán với số câu lệnh duy nhất và mỗi hàmkhông được cải biên các tham số của nó và các biến toàn cục
Với mỗi câu lệnh S ta định nghĩa:
DEF(S) = {X | câu lệnh S chứa định nghĩa của X}
USE(S) = {X | câu lệnh S chứa một sử dụng X}
Nếu S là câu lệnh if hoặc câu lệnh vòng lặp thì DEF(S) là rỗng, còn USE(S) được xác định tùytheo điều kiện trong S
Giả thiết: định nghĩa của biến X ở câu lệnh S là còn sống tại câu lệnh S’ nếu có một con đường
từ S tới S’ mà trên con đường đó không chứa một định nghĩa nào khác của X
Một dây truyền sử dụng (DU dây truyền) của X là DU=[X,S,S’] với X trong DEF(S), và trongUSE(S’) và định nghĩa X trong S vẫn còn sống trong S’
Chiến lược thử nghiệm dòng dữ liệu đòi hỏi rằng mọi DU đều phải được phủ ít nhất một lần
Trang 22Kiểm thử DU không bảo đảm phủ tất cả các nhánh của chương trình; tuy nhiên một nhánhkhông được phủ bởi DU kiểm thử là rất hiếm.
Kiểm thử dòng dữ liệu là hữu ích để chọn các đường của chương trình có chứa lồng các câulệnh if hoặc vòng lặp
If C4Then B4;
Else B5;
Endif;
Else
If C3Then B2;
Else B3;
EndifEndif
DU của X từ Bi 0<i<=5 tới B6 và các dây chuyền DU khac có thể được bao quát bằng cáchlàm cho năm đường này có chứa những việc lặp của chu trình
khác về việc vượt cận hay giá trị bị loại ra
+ Tiến dần ra ngoài, thực hiện phép kiểm thử cho vòng lặp tiếp nhưng giữ tất cảcác vòng lặp bên ngoài hơn ở giá trị tối thiểu và các vòng lặp lồng bên trong khác ở giátrị “điển hình”
+ Tiếp tục cho tới khi mọi vòng lặp đã được kiểm thử hết
1 Vòng lặp nối tiếp: Dùng cho các
vòng lặp đơn nếu mỗi vòng lặp là
độc lập Tuy nhiên nếu 2 vòng lặp
nối nhau và số đếm của vòng lặp 1
được dùng làm giá trị khởi đầu cho
vòng lặp 2 thì các vòng lặp là không
độc lập nhau Khi các vòng lặp là
không độc lập thì áp dụng cho các vòng lặp lồng nhau
2 Vòng lặp phi cấu trúc: Bất kỳ khi nào có
thể được lớp vòng lặp này nên được thiết
kế lại để phản ánh việc dùng các kết cấu
lập trình có cấu trúc
Trang 23Câu 42: Mô hình của kiểm thử hộp đen quan tâm đến những nhân tố nào của phần mềm?
Nó nhằm tìm ra các loại sai nào? Nêu các phương pháp áp dụng cho nó?
Phương pháp kiểm thử hộp đen tập trung vào các yêu cầu chức năng của phần mềm
Việc kiểm thử hộp đen nhằm tìm các loại sai sau:
- Chức năng thiếu hoặc không đúng
- Sai về giao diện
- Sai trong cấu trúc hoặc trong truy cập dữ liệu ngoài
- Sai thực thi chức năng
- Sai khởi đầu hoặc kết thúc modun
Nêu các phương pháp áp dụng cho kiểm thử hộp đen?
- Phân hoạch tương đương: chia miền vào của chương trình thành các lớp dữ liệu để đưa
ra các ca kiểm thử
- Phân tích giá trị biên (BVA): là kĩ thuật bổ sung thêm cho phân hoạch tương đương.Thay vì chọn bất cứ phần tử nào của lớp tương đương, BVA chọn các ca kiểm thử sátvới lớp tương đương Thay vì tập trung vào điều kiện vào, BVA còn đưa ra các ca kiểmthử từ miền ra Phương pháp này cho rằng số lớn các sai xuất hiện ở biên nhiều hơn làvùng dữ liệu trung tâm Không những chú ý đến dữ liệu trong và sát biên mà còn chú ýđến dữ liệu ngoài và sát biên
- Đồ thị nhân quả: cung cấp cách biểu diễn chính xác các điều kiện logic và hành độngtương ứng
- Kiểm thử so sánh(kiểm thử dựa vào nhau): thực thi nhiều bản khác nhau cho cùng mộtđặc tả Thực hiện các kỹ thuật kiểm thử hộp đen trên với các sản phẩm cho cùng các cakiểm thử và cùng các dữ liệu vào So sánh các kết quả thu được Nếu có khác biệt thìnhư thế có sai trong một sản phẩm nào đó
Câu 43: Trình bày phương pháp phân hoach: nguyên tắc, mục tiêu và thiết kế ca kiểm thử?
Phương châm xác định lớp tương đương là gi?
- Nguyên tắc: chia miền vào của chương trình thành các lớp dữ liệu để đưa ra các ca kiểmthử
- Mục tiêu: Nhằm tìm ra một ca kiểm thử để bộ lộ một lớp sai, bởi vậy nó rút gọn số cakiểm thử cần phát triển
- Thiết kế ca kiểm thử: Dựa trên đánh giá các lớp tương đương đối với một điều kiện vào.Lớp tương đương biểu thị cho một tập các trạng thái hợp lệ hay không hợp lệ đối vớiđiều kiện vào
- Phương châm:
o Điều kiện vào là phạm vi rộng hay một giá trị đặc biệt thì cần xác định:
+ Một lớp tương đương hợp lệ
+ Hai lớp tương đương không hợp lệ
o Điều kiện vào đặc tả một thành phần của một tập hoặc điều kiện Bool thì cần xácđịnh:
+ Một lớp tương đương hợp lệ
+ Một lớp tương đương không hợp lệ
Câu 44: Kỹ thuật nhân quả nghĩa là gì? Nêu các bước của ký thuật đó?
Kỹ thuật đồ thị nhân quả là một kỹ thuật thiết kế ca kiểm thử, nó cung cấp một biểu diễn chínhxác các điều kiện logic và các hành động tương ứng
Trang 24o Chuyển đồ thị đó thành bảng quyết định
o Các quy luật của bảng quyết định đó được sử dụng xây dựng các ca kiểm thử
Câu 45: Chiến lươc kiểm thử thời gian thực gồm mấy bước? là những bước nào? Giải
thích nội dung cơ bản mỗi bước?
Chiến lược kiểm thử thời gian thực gồm 4 bước:
- Kiểm thử tác vụ: kiểm thử từng tác vụ một cách độc lập với nhau (cho cả kỹ thuật hộptrắng và kỹ thuật hộp đen) Kiểm thử loại này cho phép:
o Phát hiện các sai về logic và chức năng
o Không phát hiện các sai về thời gian và ứng xử
- Kiểm thử ứng xử:
o Sử dụng công cụ CASE tạo mô hình hệ thống để mô phỏng ứng xử của một hệthời gian thực và xem ứng xử của nó như là một hậu quả của các sự kiện từ ngoài.Kết quả các hoạt động phân tích này có thể được dùng để thiết kế các ca kiểm thử
o Dùng kỹ thuật tương tự như phân hoạch tương đương đương phân lớp sự kiện.Mỗi sự kiện được kiểm thử riêng và ứng xử của hệ thi hành được được khámnghiệm để phát hiện các sai do việc xử lý kết hợp với các sự kiện đó
o Kiểm thử mọi lớp sự kiện Các sự kiện được đưa vào trong hệ thống theo thứ tựngẫu nhiên và với tần suất ngẫu nhiên nhằm phát hiện các sai ứng xử
- Kiểm thử liên tác: kiểm thử để tìm các sai liên quan đến thời gian Các tác vụ khôngđồng bộ khi có liên tác với các tác vụ khác Vì thế cần kiểm thử với các nhịp điệu dữliệu và tải xử lý khác nhau để xác định xem liệu các sai đồng bộ liên tác có xảy rakhông Hơn nữa, các tác vụ không đồng bộ do giao tiếp phụ thuộc hàng đợi thông điệphoặc truy cập kho dữ liệu (data store) cũng được thử để bộc lộ các sai về cỡ dữ liệu
- Kiểm thử hệ thống: sau khi tích hợp phần cứng và phần mềm tiến hành kiểm thử hệthống để tìm ra các sai về giao diện
Câu 46: Kiểm thử đơn vị là gì? Quan hệ của nó với hoạt động mã hóa như thế nào?
Kiểm thử đơn vị là tiến trình kiểm thử tập trung kiểm chứng vào đơn vị nhỏ nhất của thiết kếphần mềm đó là môđun Kiểm thử đơn vị bao giờ cũng hướng theo hộp trắng và bước này cóthể được tiến hành song song cho nhiều môđun
Nó kiểm thử các phần sau:
- Thử nghiệm giao diện
- Khám nghiện cấu trúc dữ liệu cục bộ
- Thử nghiệm với các điều kiện biên
- Các đường độc lập
- Các đường xử lý sai
Quan hệ của nó với hoạt động mã hóa:
- Kiểm thử đơn vị thường được coi là phần phụ thêm của bước mã hóa
- Sau khi bước mã nguồn đã được phát triển, được rà soát và kiểm tra tính đúng đắn cúpháp thì việc thiết kế ca kiểm thử đơn vị bắt đầu
Câu 47: Kiểm thử tích hợp thực hiện khi nào? Tại sao phải kiểm thử tích hợp?
Kiểm thử tích hợp là một kỹ thuật có tính hệ thống để xây dựng cấu trúc chương trình ngay khiđang tiến hành kiểm thử để phát hiện sai liên kết với giao diện
Phải kiểm thử tích hợp vì:
- Dữ liệu có thể bị mất khi đi qua một giao diện
- Một mođun có thehẻ có một hiệu ứng bất lợi vô tình lên các môđun khác
- Các chức năng phụ khi kết hợp lại có thể không sinh ra chức năng chính mong muốn
- Các điều không chính xác riêng rẽ có thể bị phóng đại đến mức không chấp nhận được
- Các cấu trúc dữ liệu toàn cục có thể để lộ ra các vấn đề…
Trang 25Câu 48: Có những phương pháp gì được áp dụng cho kiểm thử tích hợp? mô tả tóm tắt nội
dung mỗi phương pháp?
Có các phương pháp:
- Phương pháp “big-bang”: cố gắng tích hợp không tăng dần tức là xây dựng chương trìnhbằng cách tiếp cận vụ nổ lớn “big-bang” Tất cả các môdun đều được tổ hợp trước Toàn bộchương trình được kiểm thử như một tổng thể và thường sẽ là một kết quả hỗn loạn Gặp phảimột tập hợp các lỗi Việc sửa đổi gặp khó khăn vì việc cô lập nguyên nhân bị phức tạp bởi việctrải rộng trên toàn chương trình Khi những lỗi này đã được sửa thì những lỗi mới lại xuất hiện
và tiến trình này cứ tiếp diễn trong vòng lặp vô hạn
- Phương pháp tích hợp trên xuống: đây là một phương pháp tích hợp tăng dần với việc xâydựng cấu trúc chương trình Các môđun được tích hợp bằng cách đi dần xuống theo trật tự điềukhiển, bắt đầu với môđun điều khiển chính (chương trình chính) Các môđun phụ thuộc (vàphụ thuộc cuối cùng) vào môđun điều khiển chính sẽ được tổ hợp dần vào trong cấu trúc theohoặc chiều sâu trước hay chiều rộng trước
- Phương pháp tích hợp dưới lên: bắt đầu xây dựng và kiểm thử với các môđun nguyên tử (tức
là các môdun ở mức thấp nhất trong cấu trúc chương trình) Vì các môđun này được tích hợp
từ dưới lên nên việc xử lý yêu cầu đối với các môđun phụ thuộc vào một mức nào đó bao giờcũng có sẵn và nhu cầu về cuống bị dẹp bỏ
Câu 49: Các tài liệu kiểm thử tích hợp gồm những loại gì?
+ Môi trường và nguồn lực
+ Thủ tục kiểm thử n (mô tả thử nghiệm cho build n)
+ Thứ tự tích hợp
+ Mục đích
+ Các môđun được kiểm thử
+ Các kiểm thử đơn vị cho các môđun trong build
+ Mô tả kiểm thử cho môđun m
Trang 26 Khi phần mềm được xây dựng cho một khách hàng:
một hoạt động được tiến hành để khách hàng thẩm định mọi yêu cầu
tiến hành kiểm thử là người sử dụng đầu cuối chứ không phải người đặt hàng
kiểm thử chấp thuận có thể tiến hành vài tuần hoặc vài tháng một lần, nhờ đó màbộc lộ được các lỗi tích luỹ làm suy giảm hệ thống theo thời gian
Khi phần mềm được xây dựng cho nhiều người dùng:
kiểm thử chấp thuận bởi một khách hàng là không thực tế
Do đó phải dùng quá trình kiểm thử alpha và beta cho nhiều người tiến hành để bộc
lộ các sai mà có lẽ chỉ các người sử dụng đầu cuối mới có thể phát hiện được
Kiểm thử Alpha
được bên phát triển tiến hành
phần mềm sẽ được dùng trong bối cảnh tự nhiên để người phát triển "nhòm qua vai"người sử dụng và báo cáo các sai và các vấn đề sử dụng
được tiến hành trong một môi trường được điều khiển (theo kế hoạch của người pháttriển)
Kiểm thử Beta
được một hay nhiều người đặt hàng tiến hành
không hiện diện người phát triển
áp dụng phần mềm trong môi trường thực, không có sự kiểm soát của người pháttriển
khách hàng sẽ báo cáo tất cả các vấn đề (thực hoặc tưởng tượng) mà họ gặp trongquá trình kiểm thử cho người phát triển một cách định kỳ
dựa theo báo cáo đó người phát triển tiến hành sửa đổi và chuẩn bị phân phối bảnphát hành cho toàn bộ các người đặt hàng
Câu 51 : Nội dung chính của kiểm thử hệ thống ? Nêu một số câu hởi đặt ra cho kiểm thử
hệ thống ?
Hệ thống dựa vào máy tính do nhiều bên xây dựng, người phát triển phần mềm chỉ làmột bên
Việc kiểm thử hệ thống dễ có nguy cơ "đổ lỗi cho nhau"
Người phát triển phần mềm cần đoán trước các vấn đề giao diện có thể nảy ra và
Phát hiện các thiết kế đường xử lý sai thông qua kiểm thử tất cả các thông tin đến từcác phần tử khác của hệ thống
Tiến hành một loạt kiểm thử mô phỏng các dữ liệu xấu hoặc các sai tiềm tàng kháctại giao diện phần mềm
Báo cáo các kết quả kiểm thử để làm chứng cớ phòng ngừa đổ lỗi cho nhau
Những người tham gia vào trong việc hoạch định và thiết kế các kiểm thử hệ thống
để bảo đảm rằng phần mềm được kiểm thử đầy đủ
Việc kiểm thử hệ thống thực tế là một loạt các bước kiểm thử khác nhau có mục đíchchính là thử đầy đủ hệ thống dựa trên máy tính
Câu 52 :Trình bày công đoạn kiểm thử phục hồi, kiểm thử an ninh, kiểm thử áp lực, kiểm
thử thi hành ? Kiểm thử phục hồi là gì ?
Nhiều hệ thống cần phải phục hồi sau lỗi để lại tiếp tục xử lý trong một thời gian đã đặc
Kiểm thử phục hồi là kiểm thử hệ thống bắt buộc phần mềm phải hỏng theo nhiều cách
để xem có phục hồi được hay không
Có 2 cách phục hồi:
Trang 27 Nếu phục hồi tự động (được thực hiện bởi bản thân hệ thống): khởi động lại, cơ chếcheckpoint, phục hồi dữ liệu và cho chạy lại sẽ được đánh giá là đúng đắn
Nếu phục hồi đòi hỏi sự can thiệp của con người thì phải đánh giá thời gian trungbình dùng để sửa chữa và xác định xem liệu nó đã ở trong giới hạn chấp nhận đượckhông?
Kiểm thử an ninh là gì ?
Kiểm thử an ninh cố gắng kiểm tra cơ chế bảo vệ được xây dựng trong hệ thống có cóđạt được các hiệu quả trước các đột nhập không hợp pháp hay không?
Cần chú ý tới tất cả các loại tấn công: "trước mặt", "ngang sườn", "sau lưng"
Khi kiểm thử an ninh, người kiểm thử đóng vai trò của kẻ đột nhập hệ thống
Về nguyên tắc, đủ thời gian và nguồn lực thì cuối cùng sẽ đột nhập được
Bài toán thiết kế hệ thống đặt ra là:
Làm cho việc thâm nhập tốn phí nhiều hơn giá trị thu được
Công sức bỏ ra để xây dựng công cụ bảo vệ phải ít hơn giá trị mất đi nếu bị đột nhập
các kiểm thử có thể đòi hỏi bộ nhớ tối đa các tài nguyên khác có thể phải thực hiện
các ca kiểm thử có thể gây ra đập vỡ hệ điều hành
các ca kiểm thử có thể gây ra việc tiêu tốn dữ liệu thường trú trên đĩa cứng
Về bản chất, người kiểm thử cố gắng phá vỡ chương trình
Một loại khác của kiểm thử áp lực là kiểm thử nhạy cảm: làm bộc lộ các tổ hợp dữ liệu(lớp dữ liệu vào có hiệu lực) hay sự kiện mà có thể gây ra việc xử lý không ổn địnhhoặc không chính xác
Kiểm thử có thể làm bộc lộ các tình thế dẫn đến sự suy giảm hoặc thất bại hệ thống tiềmẩn
Câu53 : Cấu hình phần mềm là cái gì? Nội dung các khoản mục chính trong cấu hình
phần mềm gồm những gì?
Kết quả của quá trình kỹ nghệ phần mềm là các thông tin có thể được chia thành 3 loại:
Các chương trình máy tính (cả mức nguồn và mức chạy được)
Các tài liệu mô tả chương trình máy tính đó (nhằm đến cả những người thực hành kỹthuật lẫn những người dùng)
Trang 28 Các cấu trúc dữ liệu (cả bên trong và ngoài chương trình)
Các khoản mục cấu thành các thông tin đó được sản ra như là một bộ phận của quá trình
kỹ nghệ phần mềm được tập hợp lại gọi là CẤU HÌNH PHẦN MỀM
* Nội dung cấu hình phần mềm gồm
Mô tả thiết kế dữ liệu
Mô tả thiết kế kiến trúc
Mô tả thiết kế mođun
Mô tả thiết kế giao diện
Mô tả đối tượng (nếu dùng kĩ thuật hướng đối tượng)
Mã nguồn và kiểm thử
Kế hoạch và thủ tục kiểm thử
Các ca kiểm thử và các kết quả được ghi lại
Các sổ tay vận hành và sổ tay lắp đặt
Chương trình thi hành được
Các mođun và mã thi hành được
Các mođun đã liên kết
Mô tả cơ sở dữ liệu
Lược đồ và cấu trúc các file
Nội dung hồ sơ ban đầu
Câu 54 : Quản lý cấu hình nhằm mục tiêu gì?Năm nhiệm vụ của quản lý cấu hình là gì
Mục tiêu nguyên thuỷ của quản lý cấu hình phần mềm là kiểm soát các thay đổi
Sau này có thêm các mục tiêu:
Minh định các khoản mục cấu hình, các version của phần mềm
Sự kiểm toán cấu hình phần mềm cũng bảo đảm rằng phần mềm đã được phát triểnđúng và việc báo cáo tất cả các thay đổi là được áp dụng cho cấu hình đó
Năm nhiệm vụ của quản lý cấu hình là
Xác định cấu hình
Kiểm soát version
Kiểm soát thay đổi
Kiểm toán cấu hình
Và báo cáo
Câu55 : Phương pháp gì được áp dụng cho việc quản lý cấu hình? Mốc giới là cái gì? Sử
dụng mốc giới để kiểm soát sự thay đổi như thế nào?
Phương pháp hướng đối tượng áp dụng cho việc quản lý cấu hình
Mốc giới là một ranh giới được đặt ra:
Trước nó thì có thể thay đổi nhanh chóng và không chính thức
Trang 29 Sau nó thì có thể thay đổi, nhưng cần các thủ tục đặc biệt và chính thức để có thểđánh giá và kiểm thử từng thay đổi một
Đường mốc giới là để đánh dấu việc phân phát một vài khoản mục cấu hình phần mềm
Tại đường mốc giới các khoản mục cấu hình phần mềm tương ứng được đưa vào cơ sở
dữ liệu dự án
Câu 56 : Trình bày tiến trình kiểm soát sự thay đổi?
Nhận ra nhu cầu thay đổi
Người dùng đệ trình yêu cầu thay đổi
Người phát triển đánh giá
Sinh ra báo cáo về thay đổi
Người có thẩm quyền quyết định kiểm soát thay đổi
Xếp hạng các yêu cầu, sinh ra thứ tự thay đổi kỹ thuật
Các (khoản mục) đối tượng cấu hình "check out" Thông báo cho người
dùngThực hiện thay đổi
Ra soát thay đổi (kiểm toán)
Các (khoản mục) đối tượng cấu hình "check in"
Thiết lập các đường mốc giới kiểm thử
Xem lại các thay đổi sẽ được bao gồm vào trong lần
phân phát mới
Xây dựng lại phiên bản mới của phần mềm
Rà soát lại sự thay đổi của tất cả các khoản mục cấu hình
(kiểm toán)
Bao gồm các thay đổi vào trong phiên bản mới
Phân phối phiên bản mới
Câu 57: Phiên bản là cái gì? Làm thế nào để kiểm soát các phiên bản
* Phiên bản là một thực thể mới của một CI (Configuration Item) sau khi đã qua một hoặcnhiều lần xem xét và thay đổi
* Kiểm soát các phiên bản =tổ hợp các thủ tục và các công cụ để quản lý các phiên bản khácnhau của các đối tượng cấu hình (đã được tạo ra trong quá trình kỹ nghệ phần mềm)
Câu 58 :Kiểm toán cấu hình phần mềm nghĩa là gì? Hoạt động kiểm toán cần trả lời những
câu hỏi gì?
Kiểm toán cấu hình phần mềm bổ sung cho rà soát kỹ thuật chính thức bằng cách đánhgiá một đối tượng cấu hình cho các đặc tính mà thường không được xét trong quá trình
rà soát
Hoạt động kiểm toán cần trả lờinhưng câu hỏi sau:
Thay đổi được đặc tả trong trật tự thay đổi kỹ thuật đã được thực hiện hay chưa?Nhưng cải biên phụ nào được phối hợp?
Rà soát kỹ thuật chính thức đã được tiến hành để đánh giá sự đúng đắn kỹ thuật haychưa?
Các chuẩn kỹ nghệ phần mềm đã thực sự được tuân thủ chưa?
Đổi thay đó đã nổi bật lên trong các khoản mục phần mềm chưa? Có đặc tả ngày vàtác giả của đổi thay đó không? Các thuộc tính của đối tượng cấu hình đó đã phản ánhđược đổi thay đó chưa?
Các thủ tục quản lý cấu hình phần mềm để quan sát đổi thay đó, ghi lại nó, báo cáo
về nó có được tuân thủ hay không?
Tất cả các khoản mục cấu hình phần mềm đã thực sự được cập nhật chưa?
Trang 30Vẽ mô hình biểu diễn giai đoạn 1 trong tiến trình phát triển PM.
Vẽ mô hình biểu diễn giai đoạn 2 trong tiến trình phát triển PM.
Trang 31Vẽ mô hình biểu diễn giai đoạn 3 trong tiến trình phát triển PM.
Vẽ sơ đồ nguyên tắc hoạt động phương pháp mô hình hóa.
Trang 32MỤC LỤC
MỤC LỤC 1CÂU HỎI ÔN TẬP KỸ NGHỆ PHẦN MỀM NÂNG CAO 4
1 Chất lượng và đảm bảo chất lượng phần mềm 41.1 Khái niệm về đảm bảo chất lượng 4Câu 1 Chất lượng của một sản phẩm phần được sản xuất là gì? Đối với phần mềm định nghĩa này
có đúng không? Làm thế nào để áp dụng định nghĩa đó? 4Câu2 Cái gì được dùng làm cơ sở để kiểm định chất lượng phần mềm: 4Câu 3 Để làm cơ sở cho việc kiểm định chất lượng, đặc tả các yêu cầu phần mềm cần thoả mãn các điều kiện gì? Nêu một vài ví dụ về điều kiện đưa ra 5Câu 4 Các nhân tố ảnh hưởng lên chất lượng phần mềm có mấy mức độ? Những loại nhân tố nàoảnh hưởng đến chất lượng? 5Câu 5 Nêu các đặc trưng ảnh hưởng lên chất lượng của mỗi loại nhân tố: đặc trưng chức năng, khả năng thích nghi với thay đổi, khả năng thích nghi với môi trường? 5Câu 6 Có thể đo trực tiếp chất lượng phần mềm không? Tại sao? Vậy phải đo bằng cách nào? 10Câu 7 Kể ra các độ đo đặc trưng chất lượng chính của McCall? Giải thích nội dung của nó? 10Câu 8 Giải thích nội dung các thuộc tính chất lượng phần mềm sau đây và nêu ra các độ đo liên quan được sử dụng để đo thuộc tính đó: 11Câu 9 Nêu các đặc trưng chất lượng theo Hawlett? Giải thích nội dung mỗi loại 131.2 Tiến hóa của hoạt động đảm bảo chất lượng 14Câu 10 Đảm bảo chất lượng phần mềm xuất phát từ đâu? Tiến triển của nó như thế nào? 14Câu 11 Tại sao cần đảm bảo chất lượng phần mềm? Nó đóng vai trò gì trong một doanh nghiệp phát triển phần mềm? 14Câu 12 Khi nào cần thực hiện các hoạt động đảm bảo chất lượng phần mềm? 15Câu 13 Trong một tổ chức, những ai tham gia vào hoạt động đảm bảo chất lượng? Vai trò và trách nhiệm của mỗi đối tượng đó là gì? 15Câu 14 Mục tiêu của SQA là gì? Các hoạt động chính đảm bảo chất lượng phần mềm là những hoạt động nào? 15Câu 15 Giải thích nội dung tóm tắt của mỗi hoạt động chính đảm bảo chất lượng? 161.3 Rà soát phần mềm 16Câu 16 Rà soát phần mềm được hiểu là gì (khái niệm, mục tiêu, cách thức áp dụng)? Nêu các lợi ích của việc ra soát?Nếu không thực hiện rà soát thì sao? 16Câu 17 Các hình thức của hoạt động rà soát? trình bày khái niệm, mục tiêu của rà soát kỹ thuật chính thức? 17Câu 18 Vẽ sơ đồ tiến trình hoạt động rà soát va giải thích sơ bộ nội dung mỗi bước? 18Câu 19 Trình bày nội dung cơ bản 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? 18Câu 20 Các sản phẩm của cuộc họp rà soát là gì? Nội dung, vai trò của mỗi sản phẩm đó? 19Câu 21 Khi nào tiến hành rà soát? Cần rà soát những sản phẩm gì 20
Trang 33Câu 22 Trình bày nội dung, danh mục rà soát 20
2 Các độ đo đặc trưng chất lượng phần mềm 252.1 Các độ đo chỉ số chất lượng chương trình 25Câu 23 Nêu các ký hiệu và giải thích các độ đo: s1,s2,s3,s4,s5,s6,s7 và D1=1&0, (D2=1-s2/s1), (D3=1-s3/s1), (D4=1-s5/s1), (D5=1-s6/s5), (D6=1-s7/s5)? 25Câu 24 Sử dụng công thức wiDi với wi = 1 như thế nào và để làm gì? 26Câu 25 Giải thích nội dung các thành phần và ý nghĩa độ đo SMI và cách
sử dụng nó? 26Câu 26 Số đo độ phức tạp của McCabe dựa trên cái gì và những đại lượng cụ thể nào? 26+ Số chu trình có chu trình lồng nhau 26+ Số chu trình nhiều nhất trong một chu trình 26Câu 27 Đảm bảo chất lượng phần mềm dựa trên thống kê nghĩa là gì?Nó gồm những công việc gì? Kể ít nhất 5 nguyên nhân của những khuyết điểm trong phần mềm? 27Câu 28 Nêu công thức khiếm khuyết của một sản phẩm ở một pha phát triển? và công thức tính khiếm khuyết của sản phẩm cuối cùng? Giải thích ý nghĩa của nó? 27Câu 29 Tiếp cận hình thức cho SQA nghĩa là gì? Quá trình phòng sạch là gì? Phương châm của
kỹ thuật này là gì? 282.2 Các độ đo về sự tin cậy và an toàn 28Câu 30 Độ tin cậy của phần mềm là cái gì? Đo độ tin cậy dựa trên những dữ liệu nào? 28Câu 31 Thế nào là thất bại của phần mềm? Có mấy thang bậc? Là những thang bậc nào? 29Câu 32 Nêu chỉ 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 của nó? 29Câu 33 Có những mô hình độ tin cậy nào? Nó dựa trên tham biến nào và trên giả thiết nào? Mô hình độ tin cậy gieo hạt dựa trên ý tưởng nào? Mục tiêu để làm gì? 29Câu 34 Độ an toàn phần mềm là cái gì? Có những phương pháp nào để phân tích độ an toàn? 30Câu 35 Khảo sát nhu cầu SQA gồm những nội dung gì? Nhằm trả lời các câu hỏi gì? Nếu có nhu cầu thì mình làm gì? 31Câu 36 Có những vấn đề gì đạt ra khi triển khai SQA? Lợi ích của SQA là gì? Nguyên tắc chi phíhiệu quả của SQA là gì? 31
3 Kiểm thử phần mềm 323.1 Khái niệm về kiểm thử 32Câ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ó quan niệm sai gì vềkiểm thử phần mềm? 32Câ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ụ kiểm thử là gì? 33Câu 39 Biểu đồ dòng thông tin kiểm thử mô tả cái gì? Vẽ biểu đồ của nó? 33Câu 40 Nêu các đối tượng, các phương pháp kiểm thử phần mềm? Mỗi phương pháp đó thường được sử dụng vào giai đọan nào của quá trình phát triển? 34Câ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ử? 34Câu 42 Kiểm thử hộp trắng là cái gì? Nêu các đặc trưng của nó? 35Câu 43 Kiểm thử hộp đen là cái gì? Nêu các đặc trưng của nó? 35Câu 44 Chiến lược kiểm thử phần mềm là cái gì? Nêu các nguyên tắc trong chiến lược kiểm thử phần mềm? 36Câu 45 Nêu các bước của chiến lược kiểm thử thời gian thực và giải thích nội dung của mỗi bước? 36Câu 46 Có những loại công cụ tự động nào trợ giúp kiểm thử, mô tả nội dung của mỗi loại? 37Câu 47 Ai là người phải tham gia kiểm thử phần mềm? Nêu vai trò và trách nhiệm của mối đối tượng? 383.2 Các phương pháp kiểm thử 38
a Kiểm thử hộp trắng 38Câu 48 Kiểm thử hộp trắng dựa trên cơ sơ nào để thiết kế ca kiểm thử? Thiết kế ca kiểm thử phảiđảm bảo điều kiện gì? 38Câu 49 Đồ thị dòng gồm những yếu tố nào? Xây dựng nó dựa vào đâu? Nó có đặc trưng gì? Đồ thị dòng dùng để làm gì? 38
Trang 34Câu 50 Con đường cơ bản trong đồ 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? 39Câu 51 Ma trận kiểm thử được cấu trúc như thế nào? Nó được dùng để làm gì? 41Câu 52 Nêu các loại điều kiện trong cấu trúc điều khiển và cho ví dụ? Có những loại sai nào trong điều kiện khi kiểm thử? 41Câu 53 Chiến lược kiểm thử phân nhánh nghĩa là gì? Yêu cầu đặt ra cho kiểm thử phân nhánh là gì? 41Câu 54 Chiến lược kiểm thử miền là cái gì? Nó dựa trên tư tưởng nào? 42Câu 55 Chiến lược kiểm thử BRO là cái gì? Nó dựa trên tư tưởng nào? 42Câu 56 Lấy ví dụ về các điều kiện “ràng buộc đầu ra” cho các trường hợp: 1 biến Bool, hợp của biến Bool và biểu thức quan hệ, hợp của hai biểu thức quan hệ? 42Câu 57 Kiểm thử điều khiển dòng dữ liệu nghĩa là gì? Cho ví dụ? 43Câu 58 Kiểm thử điều khiển vòng lặp nghĩa là gì? Cho ví dụ? 44
b Kiểm thử hộp đen 45Câu 59 Mô hình của kiểm thử hộp đen quan tâm đến những nhân tố nào của phần mềm? Nó nhằm tìm ra các loại sai nào? Nêu các phương pháp áp dụng cho nó? 45Câu 60 Trình bày phương pháp phân hoạch: nguyên tắc, mục tiêu và thiết kế ca kiểm thử?
Phương châm xác định lớp tương đương là gi? 45Câu 61 Phân tích giá trị biên nghĩa là gì? Phương châm phân tích giá trị biên là gì? 46Câu 62 Kỹ thuật nhân quả nghĩa là gì? Nêu các bước của kỹ thuật này? 46Câu 63 Chiến lược kiểm thử thời gian thực gồm mấy bước? là những bước nào? Giải thích nội dung cơ bản mỗi bước? 47
c Kiểm thử đơn vị 47Câu 64 Kiểm thử đơn vị là gì? Quan hệ của nó với hoạt động mã hóa như thế nào? 47Câu 65 Hoạt động kiểm thử đơn vị gồm những nội dung gì? Nó liên quan đến những nhân tố nào? Nêu một vài câu hỏi kiểm thử cho các nhân tố đó? 48Câu 66 Kỹ thuật kiểm thử đơn vị sử dụng là gì? vì sao phải sử dụng kỹ thuật đó? Có những khó khăn thuận lợi gì? 49
d Kiểm thử tích hợp 49Câu 67 Kiểm thử tích hợp thực hiện khi nào? Tại sao phải kiểm thử tích hợp? 49Câu 68 Có những phương pháp gì được áp dụng cho kiểm thử tích hợp? Mô tả tóm tắt nội dung mỗi phương pháp? 50Câu 69 Nêu các bước kiểm thử tích hợp từ trên xuống? Ưu nhược điểm của cách tiếp cận này? .50Câu 70 Nêu các bước kiểm thử tích hợp từ dưới lên? Ưu nhược điểm của cách tiếp cận này? 51Câu 71 Các tài liệu kiểm thử tích hợp gồm những loại gì? 51
e Kiểm thử hệ thống 52Câu 72 Kiểm thử Beta là cái gì? Kiểm thử Alpha là cái gì? Nêu sự giống và khác nhau cơ bản giữa chúng? 52Câu 73 Nội dung chính của kiểm thử hệ thống? Nêu một số câu hỏi đặt ra cho kiểm thử hệ
thống? 53Câu 74 Kiểm thử phục hồi là gì? 53Câu 75 Kiểm thử an ninh là gì? 53Câu 76 Kiểm thử áp lực là gì? 54Câu 77 Kiểm thử thi hành là gì? 54Câu 78 Gỡ rối được hiểu là gì? Nó thực hiện khi nào? Khó khăn của việc gỡ rối là gì? 55Câu 79 Trình bày tiến trình gỡ rối? Cách thức gỡ rối? Ưu nhược điểm của chúng? 55
f Quản lý cấu hình 56Câu 80 Quản lý cấu hình phần mềm là cái gì? Nội dung của hoạt động quản lý cấu hình gồm những công việc gì? 56Câu 81 Cấu hình phần mềm được hiểu là cái gì? Nội dung các khoản mục chính trong cấu hình phần mềm gồm những gì? 57Câu 82 Quản lý cấu hình nhằm mục tiêu gì? Năm nhiệm vụ của quản lý cấu hình là gì? 58Câu 83 Phương pháp gì được áp dụng cho việc quản lý cấu hình? Mốc giới là cái gì? Sử dụng mốc giới để kiểm soát sự thay đổi như thế nào? 58
Trang 35Câu 84 Trình bày tiến trình kiểm soát sự thay đổi? 59
Biểu đồ tiến trình kiểm soát sự thay đổi 59
Câu 85 Phiên bản là cái gì? Làm thế nào để kiểm soát các phiên bản? 60Câu 86 Kiểm toán cấu hình phần mềm nghĩa là gì? Hoạt động kiểm toán cần trả lời những câu hỏi gì? 60Câu 87 Báo cáo hiện trạng nghĩa là gì? Nó cần trả lời được những câu hỏi gì? Đầu ra của báo cáohiện trang dành cho ai? Mục tiêu của nó là gì? 61
Trang 36CÂU HỎI ÔN TẬP KỸ NGHỆ PHẦN MỀM NÂNG CAO
1 Chất lượng và đảm bảo chất lượng phần mềm
1.1 Khái niệm về đảm bảo chất lượng
Câu 1 Chất lượng của một sản phẩm phần được sản xuất là gì? Đối với phần mềm định nghĩa này có đúng không? Làm thế nào để áp dụng định nghĩa đó?
- Chất lượng của sản phẩm được thể hiện bằng các đặc trưng phù hợp với các đặc tả củanó
- Định nghĩa này là chung cho mọi sản phẩm Với phần mềm có một số vấn đề:
Phần mềm có yêu cầu mà chưa có đặc tả
các chuẩn phát triển đã được tư liệu hoá tường minh
các đặc trưng không tường minh được trông đợi từ tất cả các phần mềm đã đượcphát triển theo cách chuyên nghiệp:
Theo quan điểm của người phát triển thì một phần mềm tốt là một phần mềm ít lỗi Đóchính là chất lượng của chương trình Vấn đề là làm thế nào để chương trình chạy giống nhưthiết kế Chất lượng của phần mềm theo quan điểm này chính là quan điểm chất lượng theo
kiểu lập trình Nguời ta cũng gọi chất luợng này là chất lượng theo nghĩa cần thiết vì nó phản
ánh cái bắt buộc phải làm có tính nguyên tắc mặc dù nói chung nguời ta không đạt được
Đã có một sự thay đổi lớn trong cách quan niệm chất lượng của phần mềm Theo quan
điểm của khách hàng, phần mềm tốt là phần mềm đáp ứng tốt yêu cầu của khách hàng và dễ dùng, dễ bảo trì Đó là chất lượng theo quan điểm thiết kế Vấn đề là làm thế nào để thiết kế đáp ứng đúng nhu cầu của người sử dụng Người ta cũng nói đó là chất lượng theo nghĩa hấp dẫn vì nó hướng tới người dùng
Còn một khía cạnh mới trong quan niệm chất lượng của phần mềm đó là độ tin cậy, được
hiểu là tính chính xác, tính ổn định, tính an toàn của phần mềm Kể từ khi máy tính trở thành
hạ tầng mới của xã hội, độ tin cậy của phần mềm trở nên hết sức quan trọng đối với các hoạt
động xã hội Đây là chất lượng theo nghĩa xã hội đo mức độ ảnh hưởng của sản phấm tới mọi
người (không kể chính người phát triển và NSD trực tiếp)
Một phần mềm tốt không những phải đáp ứng nhu cầu của người phát triển mà phải thoả
mãn người sử dụng và có độ tin cậy cao Vậy có thể định nghĩa: Chất lượng là mức độ thoả mãn của NSD đối với sản phẩm hay dịch vụ.
Câu2 Cái gì được dùng làm cơ sở để kiểm định chất lượng phần mềm:
Để đánh giá chất lượng phần mềm người ta dựa vào quan điểm chính sau:
- Yêu cầu phần mềm là cơ sở để đo chất lượng:
Sự phù hợp với yêu cầu là có chất lượng
Phù hợp yêu cầu cả về số lượng và chất lượng
- Yêu cầu thể hiện bằng đặc tả - đặc tả phải có chuẩn của nó mới kiểm tra được
- Các chuẩn đặc tả xác định một bộ các tiêu chuẩn phát triển, các tiêu chuẩn này hướngdẫn cách thức làm ra phần mềm: nếu không tuân thủ các tiêu chuẩn đó thì hầu như chắc chắn
là chất lượng sẽ kém
- Luôn có một tập các yêu cầu ngầm thường ít được nhắc đến
Quá thông dụng, hiển nhiên (sử dụng cửa số)
Không thể hiện ra ngoài (quy tắc nghiệp vụ)
- Nếu phần mềm chỉ phù hợp với các yêu cầu đã hiển thị mà chưa phù hợp với yêu cầungầm thì chất lượng phần mềm là đáng nghi ngờ
Trang 37- Cần làm rõ yêu cầu và đưa vào đặc tả càng nhiều càng tốt
Câu 3 Để làm cơ sở cho việc kiểm định chất lượng, đặc tả các yêu cầu phần mềm cần thoả mãn các điều kiện gì? Nêu một vài ví dụ về điều kiện đưa ra.
Yêu cầu phần mềm là cơ sở để đo chất lượng Yêu cầu thể hiện ra bằng đặc tả và đặc tảphải có chuẩn của nó mới kiểm tra được Các chuẩn đặc tả xác định một bộ các tiêu chuẩn pháttriển, các tiêu chuẩn này hướng dẫn cách thức làm ra phần mềm: nếu không tuân thủ các tiêuchuẩn đó thì hầu chắc chắn là chất lượng sẽ thiếu sót
Câu 4 Các nhân tố ảnh hưởng lên chất lượng phần mềm có mấy mức độ? Những loại nhân tố nào ảnh hưởng đến chất lượng?
- Có 2 loại mức độ ảnh hưởng
Nhân tố trực tiếp
Nhân tố gián tiếp
- Có 3 loại nhân tố ảnh hưởng đến chất lượng
Đặc trưng chức năng
Khả năng đương đầu với những thay đổi
Khả năng thích nghi với môi trường mới
Câu 5 Nêu các đặc trưng ảnh hưởng lên chất lượng của mỗi loại nhân tố: đặc trưng chức năng, khả năng thích nghi với thay đổi, khả năng thích nghi với môi trường?
McCall đề xuất 11 nhân tố và phân thành 3 loại:
(1) đặc trưng chức năng
(2) khả năng đương đầu với những thay đổi
(3) khả năng thích nghi với môi trường mới
Loại 1: Các đặc trưng chức năng - (5)
(1) Tính đúng đắn
- Có làm đúng với cái tôi muốn hay không?
- Có thỏa mãn những điều đã được đặc tả chưa?
- Có thực hiện được những mục tiêu nhiệm vụ của khách hàng chưa?
Các độ đo liên quan:
o Độ đầy đủ
o Độ hòa hợp
o Độ lần vết được
(2) Tính tin tưởng được
- Có thể trông đợi vào sự thực hiện các chức năng dự kiến
- Mức chính xác được đòi hỏi
Các độ đo liên quan:
(3) Tính hiệu quả: Tổng nguồn lực tính toán và mã yêu cầu để thực hiện các chức
năng của chương trình là thích hợp
Các độ đo liên quan:
o Độ súc tích
o Độ hiệu quả thực hiện
o Độ dễ thao tác
Trang 38 (4) Tính toàn vẹn: là sự khống chế được việc truy cập của những người không được
phép tới phần mềm và dữ liệu của hệ thống
Các độ đo liên quan:
o Độ kiểm toán được
o Độ đo khả năng huấn luyện
Loại 2: Khả năng đương đầu với những thay đổi - (3)
(1)Tính bảo trì được: nỗ lực đòi hỏi để định vị và xác định được một lỗi trong chương
o Độ đơn giản – dễ hiểu
(2) Tính mềm dẻo: nỗ lực đòi hỏi để cải biên một chương trình là chấp nhận được
Các độ đo liên quan:
o Độ đơn giản - dễ hiểu
(3) Tính kiểm thử được: nỗ lực cần để kiểm thử một chương trình và bảo đảm rằng nó
thực hiện đúng chức năng được dự định là chấp nhận được
Các độ đo liên quan:
o Độ kiểm toán được
o Độ phức tạp
o Trang bị đồ nghề đủ
o Độ mođun hoá
o Độ tự cấp tài liệu
o Độ đơn giản - dễ hiểu
Loại 3: khả năng thích nghi với môi trường mới - (3)
(1) Tính mang chuyển được: nỗ lực đòi hỏi để chuyển nó từ một môi trường phần
cứng/phần mềm này sang một môi trường phần cứng/phần mềm khác
Các độ đo liên quan:
o Độ khái quát
o Độ độc lập phần cứng
o Độ đo mođun hoá
Trang 39o Độ đo mođun hoá
o Độ tự tạo tài liệu
o Độ độc lập hệ thống phần mềm
(3) Tính liên tác được: nỗ lực đòi hỏi để ghép đôi một hệ thống vào một hệ thống
khác
Các độ đo liên quan:
o Độ tương đồng giao tiếp
o Độ tương đồng dữ liệu
o Độ khái quát
o Độ đo mođun hoá
Có hai mức độ ảnh hưởng
Nhân tố trực tiếp: có thể thực tiếp đo như lỗi/KLOC/ đơn vị thời gian
Nhân tố gián tiếp: nhân tố chỉ có thể đo được một cách gián tiếp như tính bảo trì
Trang 40Nhân tố
Độ đo
Đúngđắn
Tin cậyđược
Hiệuquả
Toànvẹn
Khảdụng
Bảo trìđược
Mềmdẻo
Kiểm thửđược
Mang chuyểnđược
Sử dụnglại được
Liên tácđược