Đảm Bảo Chất Lượng Phần Mềm (HC)  1

Mục Lục

CÂ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 ........................................................................................... 4

1.1. Khái niệm về đảm bảo chất lượng ............................................................................................................... 4

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 đó? ................................................................ 4

Câu2. Cái gì được dùng làm cơ sở để kiểm định chất lượng phần mềm: ............................................ 5

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

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? ..................................................................................................................... 6

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? .................................. 6

Câ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?

 ................................................................................................................................................................................. 11

Câ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ó? ... 11

Câ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 đó: ............................................................................................ 13

Câ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. ......................... 16

1.2. Tiến hóa của hoạt động đảm bảo chất lượng ......................................................................................... 17

Câ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? ........ 17

Câ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? ....................................................................................................................................... 18

Câ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? ............................. 19

Câ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ì? ..................................................................................................... 19

Câ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? ................................................................................................................................................... 19

Câ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? ..................... 20

1.3. Rà soát phần mềm .......................................................................................................................................... 21

Câ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? ............................................................. 21

Câ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? .......................................................................................................................................................... 21

Câ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? ................ 22

Câ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? .......................................................................................................................................... 22

Câ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 đó? ...... 24

Câu 21. Khi nào tiến hành rà soát? Cần rà soát những sản phẩm gì ................................................... 25

Câu 22. Trình bày nội dung, danh mục rà soát ........................................................................................... 25

2. Các độ đo đặc trưng chất lượng phần mềm ............................................................................................... 32

2.1. Các độ đo chỉ số chất lượng chương trình ............................................................................................. 32

Đảm Bảo Chất Lượng Phần Mềm (HC)  2

Câ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)? .......................................................................... 32

Câu 24. Sử dụng công thức  với wi = 1 như thế nào và để làm gì? ...................................................... 33

Câ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ó? .............. 33

Câ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?............ 34

Câ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? .......................................... 34

Câ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ó? ........................................... 35

Câ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ì? .............................................................................................................................................. 36

2.2. Các độ đo về sự tin cậy và an toàn ............................................................................................................ 37

Câ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? .............. 37

Câ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? ........ 37

Câ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ó? ......................................................................................................................................................................... 37

Câ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ì? .................................................. 38

Câ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?

 ................................................................................................................................................................................. 39

Câ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ì? .................................................................................................................................. 39

Câ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ì? ............................................................................................................................ 40

3. Kiểm thử phần mềm .......................................................................................................................................... 40

3.1. Khái niệm về kiểm thử ................................................................................................................................... 40

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ó quan niệm sai gì

về kiểm thử phần mềm? ................................................................................................................................... 40

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ụ kiểm thử là gì? . 42

Câu 39. Biểu đồ dòng thông tin kiểm thử mô tả cái gì? Vẽ biểu đồ của nó? ..................................... 42

Biểu đồ dòng thông tin kiểm thử tuân theo hình mẫu được mô tả như sau: ............................................... 42

Câ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? .................................................... 43

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ử? ............................................................................................................................................................. 44

Câu 42. Kiểm thử hộp trắng là cái gì? Nêu các đặc trưng của nó? ...................................................... 44

Câu 43. Kiểm thử hộp đen là cái gì? Nêu các đặc trưng của nó? ......................................................... 45

Câ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? ................................................................................................................................................... 45

Câ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? .................................................................................................................................................................... 46

Câ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? ... 47

Đảm Bảo Chất Lượng Phần Mềm (HC)  3

Câ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? .................................................................................................................................................................. 48

3.2. Các phương pháp kiểm thử ......................................................................................................................... 48

a. Kiểm thử hộp trắng ............................................................................................................................................ 48

Câ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ì? .............................................................................................................................. 48

Câ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ì? ........................................................................................................................... 49

Câ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? ................................................................................................................... 49

Câu 51. Ma trận kiểm thử được cấu trúc như thế nào? Nó được dùng để làm gì? .......................... 50

Câ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ử? ......................................................................................................................... 51

Câ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ì? ...................................................................................................................................................................... 52

Câ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?.......................................... 52

Câu 55. Chiến lược kiểm thử BRO là cái gì? Nó dựa trên tư tưởng nào? .......................................... 52

Câ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ệ? ............................................... 53

Câu 57. Kiểm thử điều khiển dòng dữ liệu nghĩa là gì? Cho ví dụ? ..................................................... 53

Câu 58. Kiểm thử điều khiển vòng lặp nghĩa là gì? Cho ví dụ? ............................................................. 55

b. Kiểm thử hộp đen .............................................................................................................................................. 56

Câ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ó? ............................................. 56

Câ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? ...................................................................................... 56

Câ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ì? .................... 57

Câ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? ......................................... 57

Câ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? ................................................................................................................................... 58

c. Kiểm thử đơn vị .................................................................................................................................................. 59

Câ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? ................... 59

Câ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ố đó? ....................................................................... 59

d. Kiểm thử tích hợp .............................................................................................................................................. 62

Câ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? ............................. 62

Câ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? ................................................................................................................................. 62

Câ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? ....................................................................................................................................................................... 63

Câ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? 63

Câu 71. Các tài liệu kiểm thử tích hợp gồm những loại gì?.................................................................... 64

Đảm Bảo Chất Lượng Phần Mềm (HC)  4

e. Kiểm thử hệ thống ............................................................................................................................................. 65

Câ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? ......................................................................................................................................................... 65

Câ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? ................................................................................................................................................................... 66

Câu 74. Kiểm thử phục hồi là gì? ................................................................................................................... 67

Câu 76. Kiểm thử áp lực là gì? ........................................................................................................................ 67

Câu 77. Kiểm thử thi hành là gì? .................................................................................................................... 68

Câ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ì? .............. 68

Câ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? .................... 69

f. Quản lý cấu hình ................................................................................................................................................. 70

Câ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ì? .......................................................................................................................................... 70

Câ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ì? ............................................................................................................................... 71

Câ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ì? ............. 73

Câ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? ...................................................................................... 73

Câu 84. Trình bày tiến trình kiểm soát sự thay đổi? ................................................................................. 73

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? ............................................. 74

Câ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ì? .................................................................................................................................................................... 75

Câ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áo hiện trang dành cho ai? Mục tiêu của nó là gì? ................................................................................. 75

CÂ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 đó?  

Đảm Bảo Chất Lượng Phần Mềm (HC)  5

- 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ủa nó.  

- Đị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ả  

• Phần mềm có đặc tả nhưng lại mù mờ

• Có những yêu cầu tự nhiên nên không được đặc tả  

- Chất lượng phần mềm là:  

• việc tuân thủ các yêu cầu chức năng và sự hoàn thiện đã được phát biểu tường minh 

• 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 đã được phá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  

Đảm Bảo Chất Lượng Phần Mềm (HC)  6

• 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ẫ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ầu ngầm thì

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. Để 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át triể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êu chuẩ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:  

Đảm Bảo Chất Lượng Phần Mềm (HC)  7

(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:  

o Độ chính xác  

o Độ phức tạp  

o Độ hòa hợp  

o Độ dung thứ lỗi  

o Độ mođun hoá  

o Độ đơn giản - dễ hiểu.  

o Độ lần vết được  

 (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.  

Đảm Bảo Chất Lượng Phần Mềm (HC)  8

Các độ đo liên quan:  

o Độ súc tích  

o Độ hiệu quả thực hiện  

o Độ dễ thao tác  

 (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 Trang bị đồ nghề đủ  

o Độ an ninh.  

 (5) Tính khả dụng: công sức để học hiểu, thao tác, chuẩn bị đầu vào, thể hiện đầu ra của chương

trình  

Các độ đo liên quan:  

o Độ dễ thao tá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 trình là

chấp nhận được.  

Các độ đo liên quan:  

o Độ súc tích  

o Độ hoà hợp  

o Trang bị đồ nghề đủ  

o Độ mođun hoá  

o Độ tự cấp tài liệu  

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  

Đảm Bảo Chất Lượng Phần Mềm (HC)  9

Các độ đo liên quan:  

o Độ phức tạp  

o Độ súc tích  

o Độ hoà hợp  

o Độ khuếch trương đư¬ợc  

o Độ khái quát  

o Độ đo mođun hoá  

o Độ tự cấp tài liệu  

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á  

Đảm Bảo Chất Lượng Phần Mềm (HC)  10

o Độ tự cấp tài liệu  

o Độ độc lập hệ thống phần mềm  

 (2) Tính sử dụng lại đ¬ược: một chương trình (hoặc một phần của nó) có thể được dùng lại trong

một ứng dụng 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á  

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ì 

Nhân tố

Độ đo Đúng đắn Tin cậy được Hiệu quả Toàn vẹn Khả dụng Bảo trì được Mềm dẻo Kiểm thử được

Mang chuyển được Sử dụng lại được Liên tác được  

Kiểm toán được X x  

Chính xác x  

Tương đồng giao tiếp x  

Đảm Bảo Chất Lượng Phần Mềm (HC)  11

Đầy đủ X  

Phức tạp x x x  

Súc tích x x x  

Hòa hợp X x x x  

Tương đồng dữ liệu x  

Dung thứ lỗi x  

Hiệu quả thực hiện x  

Khuyếch trương được x  

Độc lập phần cứng x x  

Trang bị đủ đồ nghề X x x  

Đo Modul hóa x x x x x x x  

Dễ thao tác x x  

An ninh X  

Tự tạo tài liệu x x x x x  

Đơn giản - Dễ hiểu x x x x  

Độc lập hệ thống phần mềm x x  

Lần vết được X x  

Khả năng huấn luyện x  

Khái quát x x x x  

 Câ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?  

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 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ó?  

• McCall đề xuất 22 độ đo sau:  

Đảm Bảo Chất Lượng Phần Mềm (HC)  12

(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  bộ

chương trình.  

(8) Độ tư¬ơng đồng dữ liệu: việc dùng các cấu trúc và kiểu dữ liệu chuẩn trong toàn bộ chương

trình  

(9) Độ dung thứ lỗi: những hỏng hóc xuất hiện khi chương trình gặp phải một lỗi được chấp nhậ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.  

(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ường không chuẩn khác.

Đảm Bảo Chất Lượng Phần Mềm (HC)  13

(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 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 đó:  

(1) 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)  

Các độ đo liên quan:  

o Độ đầy đủ  

o Độ hòa hợp  

o Độ lần vết được  

(2) 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  

Các độ đo liên quan:  

o Độ chính xác  

o Độ phức tạp  

o Độ hòa hợp  

o Độ dung thứ lỗi  

o Độ mođun hoá  

o Độ đơn giản - dễ hiểu.  

o Độ lần vết được  

(3) Tính hiệu quả: tổng lượng nguồn lực tính toán và mã yêu cầu khi thực hiện các chức năng của

chương trình là thích hợp  

Đảm Bảo Chất Lượng Phần Mềm (HC)  14

Các độ đo liên quan:  

o Độ súc tích  

o Độ hiệu quả thực hiện  

o Độ dễ thao tác  

(4) Tính toàn vẹn: là sự khống chế được việc truy cập trái phép tới phần mềm và dữ liệu hệ thống  

Các độ đo liên quan:  

o Độ kiểm toán được  

o Trang bị đồ nghề đủ  

o Độ an ninh.  

(5) Tính khả dụng: công sức để học hiểu, thao tác, chuẩn bị đầu vào, thể hiện đầu ra của chương

trình là chấp nhận nhận được  

Các độ đo liên quan:  

o Độ dễ thao tác  

o Độ đo khả năng huấn luyện  

(6) 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  

Các độ đo liên quan:  

o Độ súc tích  

o Độ hoà hợp  

o Trang bị đồ nghề đủ  

o Độ mođun hoá  

o Độ tự cấp tài liệu  

o Độ đơn giản - dễ hiểu  

(7) 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  

Các độ đo liên quan:  

Đảm Bảo Chất Lượng Phần Mềm (HC)  15

o Độ phức tạp  

o Độ súc tích  

o Độ hoà hợp  

o Độ khuếch trương đư¬ợc  

o Độ khái quát  

o Độ mođun hoá  

o Độ tự cấp tài liệu  

o Độ đơn giản - dễ hiểu  

(8) 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 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 Độ đo mođun hoá  

o Độ tự cấp tài liệu  

o Độ đơn giản - dễ hiểu  

(9) 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 là chấp nhận đượ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á  

o Độ tự cấp tài liệu  

o Độ độc lập hệ thống phần mềm  

Đảm Bảo Chất Lượng Phần Mềm (HC)  16

(10) Tính sử dụng lại đ¬ược: khả năng chương trình (hoặc một phần của nó) có thể được dùng lại

trong một ứng dụng 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á  

o Độ tự tạo tài liệu  

o Độ độc lập hệ thống phần mềm  

(11) Tính liên tác đư¬ợc: nỗ lực đòi hỏi để ghép hệ thống chương trình vào một hệ thống khác là

chấp nhận đượ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â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. 

Các đặc trưng chất lượng FURPS của Hawlett-Packard 1  

- F: Functionality - Nhân tố chức năng  

Được định giá bằng tập hợp các tính chất và khả năng của chương trình đó, độ khái quát các chức

năng được thực hiện và độ an ninh của toàn hệ thống.  

- U: Usability - Nhân tố khả dụng  

Được đánh giá bằng việc xét các nhân tố con người, thẩm mỹ, sự hoà hợp và tư liệu cung cấp

- R: Reability - Nhân tố tin cậy  

Được đánh giá bằng:  

+ Tần suất thất bại và độ nghiêm trọng của nó  

+ Tính chính xác của các kết quả ra  

Đảm Bảo Chất Lượng Phần Mềm (HC)  17

+ Thời gian trung bình giữa hai thất bại kề nhau  

+ Khả năng phục hồi sau thất bại  

+ Khả năng đoán trước được thất bại của chương trình  

- P: Performance - Nhân tố thi hành  

Được đánh giá bằng  

+ Tốc độ xử lý  

+ Thời gian đáp ứng  

+ Độ sử dụng nguồn lực  

+ Năng suất và hiệu năng  

- Supportability - Nhân tố mang chuyển  

Đánh giá bằng tổ hợp các khả năng:  

+ Mở rộng chương trình  

+ Độ thích nghi  

+ Phục vụ được (bảo trì được)  

+ Kiểm thử được  

+ Sự tương hợp  

+ Cấu hình được (khả năng tổ chức và khống chế các yếu tố của cấu hình phần mềm, để dễ dàng

cài đặt hệ thống và dễ dàng định vị các chỗ có vấn đề)  

1.2. Tiến hóa của hoạt động đảm bảo chất lượng  

Câ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?  

a) Đảm bảo chất lượng phần mềm xuất phát từ:  

(1) 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 (nhu cầu)  

• 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ường xuyên  

Đảm Bảo Chất Lượng Phần Mềm (HC)  18

(2) Từ thực tiễn: Kinh nghiệm cho phép hoạtk động đảm bảo chất lượng phần mềm ngày càng

được hoàn thiện. Hiểu về vai trò của nó và tăng thêm các hoạt động đảm bảo chất lượng.  

b) 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 ra sả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 l-ượng trong

chế tạo phần cứng.  

• 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ời những

năm 70 và nhanh chóng lan ra lĩnh vực th¬ương mại  

Câ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?  

Đả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ần mề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 kiể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  

• SQA đó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 ra sản

phẩm đ¬ược ngư¬ời khác dùng  

Đảm Bảo Chất Lượng Phần Mềm (HC)  19

Câ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?  

Chất lượng phần mềm được thiết kế bên trong sản phẩm hay hệ thống do đó nó được bắt đầu

ngay từ khi phân tích và nó giúp người phân tích đạt tới đặc tả chất lượng cao và người thiết kế thì

phát triển thiết kế với chất lượng cao.  

Câ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ì?  

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,  

- Thành viê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ềm vớ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 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?  

Đả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ông nghệ kĩ thuật hiệu quả (phương pháp, công cụ)  

(2) Tiến hành rà soát kỹ thuật chính thức  

(3) Thực hiện kiểm thử nhiều tầng  

(4) Tuân theo các chuẩn phát triển  

(5) Kiểm soát tài liệu Fm và thay đổi của chúng  

Đảm Bảo Chất Lượng Phần Mềm (HC)  20

(6) Thực hiện đo l¬ường  

(7) Báo cáo và bảo quản lý các báo cáo.  

Câ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?

(1) Áp dụng công nghệ kĩ thuật hiệu quả (phương pháp, công cụ) giúp để:  

- 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: tác dụng không kém gì kiểm thử để phát hiện khiếm

khuyết  

(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ả. Tuy nhiên, chỉ kiểm thử

phần mềm không thể tìm ra được hầu hết các sai  

(4) Tuân theo các chuẩn và các thủ tục chính thức là nhu cầu và điều kiện cho SQA. Tuy nhiên còn

tuỳ thuộc mỗi công ty. Có 2 loại chuẩn và thử tục: do khách hàng hay chính quyền quy định; tự

công ty đặt ra.  

- Đánh gí sự phù hợp với các chuẩn là một phần của việc rà soát chính thức  

- Khi cần phải kiểm chứng (verification) sự phù hợp, nhóm SQA có thể tiến hành kiểm toán (audit)

riêng.  

(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ần mềm  

+ Thay đổi tạo ra tiềm năng sinh ra sai và tạo ra hiệu ứng phụ lan truyền  

- Khống chế thay đổi áp dụng trong suốt quá trình phát triển và trong quá trình bảo trì.  

(6) Thực hiện đo l¬ường: dùng để theo dõi chất lượng phần mềm đánh giá ảnh hưởng 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.  

- Các độ đo phần mềm hướng đến 2 mặt: quản lý (thủ tục); kĩ thuật (phương pháp)  

(7) Báo cáo và bảo quản lý các báo cáo:  

Đảm Bảo Chất Lượng Phần Mềm (HC)  21

- Lập và lưu trữ báo cáo về SQA: phổ biến các thông tin SQA (người cần có thể biết); cung cấp các

thủ tục để thu thập thông tin.  

- Đối tượng báo cáo là kết quả của các hoạt động SQA: rà soát, kiểm toán, khống chế đổi thay,

kiểm thử và các hoạt động SQA khác.  

- Người phát triển sử dụng theo quy tắc "cần-thì-biết" trong suốt quá trình dự án.  

1.3. Rà soát phần mềm  

Câ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?  

• 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 phần 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ó diện mạo không đổi, ổn định)  

• 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á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ình phầ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ỗi không được

phát hiện trong thiết kế tốn phí 1.0 để sửa chữa, trước kiểm kiểm thử: 6.5; trong kiểm thử: 15 và

sau khi phân phối sẽ là từ 60.0 đến 100.0  

Câ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?  

• Các kiểu rà soát:  

• Họp xét duyệt không chính thức  

• Họp chính thức trước với các thành viên: 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)  

Đảm Bảo Chất Lượng Phần Mềm (HC)  22

• Rà soát kĩ thuật chính thức FTR chủ yếu 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ất lượ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:  

• Phát hiện các lỗi trong chức năng, trong logic, trong triển khai (implementation).  

• Kiểm thử sự phù hợp của phần mềm với yêu cầu  

• Khẳng định phần đã đạt yêu cầu  

• Bảo đảm rằng phần mềm phù hợp với các chuẩn đã định sẵn  

• Đảm bảo " phần mềm đã được phát triển theo một cách thức nhất quán" (uniform manner)  

• Làm cho dự án dễ quản lý hơn  

• 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 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?

Giải thích:  

- 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:  

• Xem xét sản phẩm để đọc, rà soát  

• Tạo ra các bản sao của sản phẩm, phân cho 2,3 người ra soát  

• 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 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?  

Đảm Bảo Chất Lượng Phần Mềm (HC)  23

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:  

• 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ần củ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ột modul)  

• Cuối buổi 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ó  

(2) Lập chương trình nghị sự và duy trì nó.  

(3) Hạn chế tranh luận và bác bỏ: các vấn đề tranh luận nên để ghi nhớ cho các thảo luận tiếp tục  

(4) Trình bày rõ ràng mạch lạc các vùng có vấn đề nhưng không gượng ép giải quyết mọi vấn đề

nhận thấy. FTR không giải quyết vấn đề, việc giải quyết vấn đề sau FTR và thường do chính người

làm ra sản phẩm thực hiện, có thể nhờ sự trợ giúp của vài cá nhân khác.  

Đảm Bảo Chất Lượng Phần Mềm (HC)  24

(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 (checklist) 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: 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ện chưa dự đoán được (sẽ xuất

hiện do một FTR)  

(9) Cần phải tiến hành huấn luyện chính thức cho cá nhân ra soát  

(10) Rà soát lại các rà soát trước đây.  

Câ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 đó?  

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

 Một văn bản tổng kết cuộc họp rà soát đó  

Nội dung, vai trò của mỗi sản phẩm:  

• Bản danh sách các vấn đề tồn tại  

 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ản phẩm cần

chỉnh sửa  

 Thiết lập 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ì?  

Đảm Bảo Chất Lượng Phần Mềm (HC)  25

 Ai rà soát?  

 Tìm thấy cái gì? và kết luận  

Câu 21. 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  

- Tiến trình phát triển chung nhất gồm 4-5 giai đoạn:  

 Kỹ nghệ hệ thống (lập kế hoạch triển khai)  

 Phân tích, xác định yêu cầu phần mềm  

 Thiết kế phần mềm  

 Kiểm thử phần mềm  

 Bảo trì (với sản phẩm đặt hàng)  

Rà soát bám theo các sản phẩm của rà soát này  

Câu 22. Trình bày nội dung, danh mục rà soát  

a) 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ó sự hoà hợp giữa các phần tử của hệ thống hay chư¬a?  

(8) Cơ chế kiểm chứng và thẩm duyệt đã đư¬ợc thiết lập hay chư¬a?  

b) Rà soát việc lập kế hoạch  

Đảm Bảo Chất Lượng Phần Mềm (HC)  26

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 dung

chủ 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 phục  

+ Các kế hoach khác  

Danh mục rà soát:  

(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ác

nguồ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 đúng logic

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ịch biểu

không?  

c) Rà soát phân tích yêu cầu phần mềm  

- Rà soát phân tích yêu cầu phần mềm: tập trung bào khả năng viết ra các yêu cầu hệ thống; sự

phù hợp và đúng đắn của mô hình phân tích.  

- Với các hệ thống lớn thì cần tăng cường: các rà soát kĩ thuật chính thức; việc đánh giá các

nguyên mẫu cũng như các cuộc họp với khách hàng.  

- Các yêu cầu của hệ thống phần mềm: yêu cầu chức năng, yêu cầu phi chức năng, yêu cầu ngoại

lai.  

Đảm Bảo Chất Lượng Phần Mềm (HC)  27

- Rà soát phân tích yêu cầu là phục vụ việc thẩm định và xác minh.  

• Nội dung thẩm định yêu cầu phần mềm:  

- Phải chỉ ra các nhu cầu người dùng được thoả mãn chưa  

- Các yêu cầu phải nhất quán: không mâu thuẫn nhau  

- Các yêu cầu phải đầy đủ: phải chứa mọi chức năng và mọi ràng buộc mà người dùng nhắm đến.  

- Các yêu cầu phải hiện thực: có khả năng thực hiện được.  

- Sự tương hợp với mô hình hệ thống và kế hoạch triển khai  

• Danh mục rà soát phân tích yêu cầu:  

(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 không?  

(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) 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?

d) 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  

(1) Phản ánh đúng các yêu cầu đặc tả  

 Đủ các phần

 Đủ chức năng và ràng buộc  

 Dữ liệu đủ, phù hợp  

(2) Có chất lượng tốt  

Đảm Bảo Chất Lượng Phần Mềm (HC)  28

 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)  

• Nội dung:  

 Rà soát kỹ thuật chính thức cho khâu thiết kế tập trung vào:  

 thiết kế dữ liệu  

 thiết kế kiến trúc  

 thiết kế thủ tục.  

 Có 2 kiểu rà soát thiết kế (phù hợp với 2 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, gaio

diện cấu trúc DL).  

• Danh mục rà roát  

 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ự modul hoá hiệu quả không?  

(3) Các modul có độc lập chức năng hay không  

(4) Kiến trúc ch¬ương trình có đư¬ợc phân tách cấu trúc không?  

(5) Các giao diện đã đư¬ợc xác định cho các modul và các phần tử hệ thống ngoại lai ch¬ưa?  

(6) Cấu trúc dữ liệu có phù hợp với lĩnh vực thông tin chưa?  

(7) Cấu trúc dữ liệu có phù hợp với yêu cầu phần mềm ch¬ưa?  

(8) Khả năng bảo trì đã đư¬ợc xem xét chư¬a?  

(9) Các nhân tố chất l¬ượng đã đ¬ược đánh giá rõ ràng chưa?  

Đảm Bảo Chất Lượng Phần Mềm (HC)  29

 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) Nguyên lý 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 hệ điều hành hay ldùng các đặc trưng độc lập ngôn ngữ?  

(10) Có dùng logic component hoặc logic inverse?  

(11) Khả năng bảo trì đã đ¬ược xét tới chưa  

e) 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ó phong cách tốt: cấu trúc, nhất quán, định dạng

chuẩn...)  

• Danh mục rà soát  

(1) Thiết kế đã 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?  

Đảm Bảo Chất Lượng Phần Mềm (HC)  30

(7) Các hằng số vật lý có đúng đắn hay không?  

(8) Có phải tất cả các khoản mục của danh sách thiết kế trọn vẹn là được áp dụng rộng rãi hon

trước hay không?  

f) 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ử)  

• Mục tiêu:  

- Đá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, chiến lược và kỹ thuật được sử dụng và kế hoạch tốt  

• Nội dung:  

- Loại hình kiểm thử:  

 Kiểm thử đơn vị (modul)  

 Kiểm thử tích hợp (chức năng)  

 Kiểm thử hệ thống  

 Kiểm thử chấp nhận (alpha, beta)  

- Chiến lược kiểm thử:  

 Từ trên xuống  

 Từ dưới lên  

 Vụ nổ lớn (big bang)  

- Kỹ thuật kiểm thử:  

 Kiểm thử hộp đen  

 Kiểm thử hộp trắng  

 Kiểm thử áp lực (tải trọng)  

 Kiểm thử luồn sợi (cho hệ thời gian thực)

 Sử dụng CASE  

- Kế hoạch kiểm thử tổng thể  

Đảm Bảo Chất Lượng Phần Mềm (HC)  31

1. Giới thiệu chung  

 Mô tả hệ thống cần kiểm thử  

 Các mục tiêu kiểm thử  

 Phương pháp sử dụng  

 Tài liệu hỗ trợ  

2. Kế hoạch  

 Thời gian, địa điểm  

 Tài liệu kiểm thử: các ca kiểm thử, tiến trình, lịch trình  

 Điều kiện  

3. Các yêu cầu: phần cứng, phần mềm, nhân sự  

4. Kiểm soát quá trình kiểm thử  

• Danh mục rà soát kế hoạch kiểm thử phần mềm:  

(1) Các pha kiểm thử chủ yếu có thực sự đư¬ợc định rõ và đư¬ợc xắp xếp thứ tự hay chưa?  

(2) Tiêu chuẩn yêu cầu kiểm thử có đư¬ợc thiết lập nh¬ư một phần của pha phân tích yêu cầu

phần mềm hay không?  

(3) Các chức năng chủ yếu có đư¬ợc trình diễn sớm không?  

(4) Kế hoạch kiểm thử có phù hợp với kế hoạch dự án tổng thể hay không?  

(5) Lịch trình kiểm thử có đư¬ợc xác định rõ ràng hay không?  

(6) Nguồn lực và công cụ kiểm thử đã đư¬ợ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 thiết bị và các tình huống kiểm thử đã đ¬ược minh định ch¬ưa?  

(9) Công việc phát triển kiểm thử đã được lập lịch chư¬a?  

(10) Kiểm thử áp lực cho phần mềm đã được đặc tả chư¬a?  

(11) Cả hai loại kiểm thử hộp trắng và hộp đen đã đư¬ợc đặc tả ch¬ưa?  

(12) Có phải tất cả các đư¬ờng logic độc lập đều đ¬ược kiểm thử?  

Đảm Bảo Chất Lượng Phần Mềm (HC)  32

(13) Có phải tất cả các ca kiểm thử đều đã đ¬ược minh định và lập danh sách với đủ các kết quả

mong đợi?  

(14) Việc xử lý sai có đ¬ược kiểm thử?  

(15) Các giá trị biên có đư¬ợc kiểm thử?  

(16) Các yêu cầu thời gian và sự diễn tiến có đư¬ợc kiểm thử?  

(17) Các biến thể chấp nhận đ¬ược của kết quả kiểm thử mong đợi đã đ¬ược đặc tả chư¬a?  

g) 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 kiểm thử và đ¬ược thay thế hay chưa?

2. Các độ đo đặc trưng chất lượng phần mềm  

2.1. Các độ đo chỉ số chất lượng chương trình  

Câ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)?  

Chỉ số chất lượng về cấu trúc thiết kế DSQI (Design Structured Quanlity Index - IEEE  Standard

982.1-1988)  

 Các đại lượng  

 S1: tổng số các modul trong kiến trúc chương trình  

 S2: số các mô đun có chức năng phụ thuộc vào: dữ liệu vào từ nguồn hay dữ liệu vào do thủ tục

ngoài modul sinh ra  

 S3: số các modul có chức năng phụ thuộc vào xử lý trước đó  

 S4: số các modul với lối vào và lối ra là duy nhất (xử lý ngoại lệ không được xem là lối ra bội)  

 S5: tổng số các khoản mục dữ liệu (các đối tượng dữ liệu, các file và tất cả các thuộc tính xác

định chúng)  

Đảm Bảo Chất Lượng Phần Mềm (HC)  33

 S6: số các các khúc dữ liệu (các bản ghi khác nhau hay các đối tượng đơn lẻ)  

 S7: số các khoản mục dữ liệu đáng chú ý  

 Các độ đo trung gian  

 D1 (Cấu trúc chương trình) =1 khi thiết kế kiến trúc dùng chỉ một phương pháp nhất định, và =0

khi khác  

 D2 (Độ độc lập dữ liệu của modul) = 1-(S2/S1)  

 D3 (Độ độc lập xử lý của modul) = 1-(S3/S1)  

 D4 (Đặc trưng vào/ra của modul) = 1-(S4/S1)

 D5 (Kích cỡ cơ sở dữ liệu) = 1-(S6/S5)  

 D6 (Độ phân chia cơ sở dữ liệu) = 1-(S7/S5)  

Câu 24. Sử dụng công thức  với wi = 1 như thế nào và để làm gì?

Công thức tính chỉ số chất lượng cấu trúc thiết kế  

wi là trọng số tương đối của tầm quan trọng của từng giá trị trung gian Di  

(Nếu tất cả các Di có trọng số bằng nhau thì wi=0,167)  

- Cần ghi lại DSQI của các thiết kế thành công trước đây, tính trung bình của chúng.  

- Nếu DSQI lần này xa giá trị trung bình đó thì cần tiếp tục công việc thiết kế và rà soát.  

Tương tự nếu tiến hành một số thay đổi chính với thiết kế hiện có thì có thể tính toán được hiệu

quả của những thay đổi này lên DSQI.  

Câ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ó?  

Chỉ số trưởng thành phần mềm SMI (Software Mutirity Index) (IEEE Standard 982.1-1998): cho biết

tính ổn định của sản phẩm phần mềm được phát triển.  

- Sự trưởng thành của phần mèm liên quan đến sự phát triển quy mô và tính ổn định liên quan đến

sự thay đổi các thành phần cấu trúc của phần mềm theo thời gian.  

- Đây là độ đo bảo trì.  

Các tham số sử dụng để tính SMI:  

Đảm Bảo Chất Lượng Phần Mềm (HC)  34

 MT: số các mô đun phát hành lần này  

 Fc: số các modul có thay đổi trong lần phát hành này  

 Fa: số các modul được thêm vào trong lần này  

 Fd: số các modul của lần phát hành trước bị bỏ đi trong lần phát hành này  

- Khi SMI gần bằng 1 thì sản phẩm bắt đầu ổn định.  

- SMI cũng có thể được dùng:  

 Như độ đo cho các hoạt động bảo trì phần mềm theo kế hoạch  

 Thời gian trung bình để tạo ra lần phát hành sản phẩm phần mềm  

 Các mô hình kinh nghiệm cho nỗ lực bảo trì có thể được phát triển.  

Câ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?  

 McCabe xác định số đo độ phức tạp của chương trình (mã nguồn) dựa trên độ phức tạp chu

trình trong đồ thị chương trình của một modul.  

+ Số chu trình có chu trình lồng nhau  

+ Số chu trình nhiều nhất 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â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?  

- Đảm bảo 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.  

- Thế nào là đảm bảo chất lượng thống kê? Là phương pháp đảm bảo chất lượng bằng cách thổng

kê dữ liệu khiếm khuyết phần mềm khi phát triển và tìm cách khử bỏ nó.  

Công việc bao gồm:  

-Thu thập và phân loại thông tin về các khiếm khuyết phần mềm.  

- Lần vết để tìm nguyên nhân  

- Dùng nguyên lý Pareto cô lập 20% nguyên nhân có thể tương ứng với 80% khiếm khuyết.  

- Tiến hành chỉnh sửa để loại bỏ nguyên nhân của khiếm khuyết.  

Đảm Bảo Chất Lượng Phần Mềm (HC)  35

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 modul (IMI)  

- Sai trong logic thiết kế (EDL)  

- Kiểm thử sai hoặc không đầy đủ (IET)  

- Tài liệu viết không đầy đủ hoặc không chính xác (IID)  

- Sai trong khi dịch thiết kế sang ngôn ngữ lập trình (PLT)  

- Giao diện người - máy mơ hồ hoặc không phù hợp (HCI)  

- Các linh tinh khác (MIS)  

Câ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ó?

- Người phát triển cần phải tính chỉ số khiếm khuyết cho mỗi bước chính phát triển phần mềm  

- Các thông tin để tính mức độ khiếm khuyết  

 Di= tổng số các khiếm khuyết  

 Si= số các khiếm khuyết nghiêm trọng  

 Mi= Số các khiếm khuyết vừa phải  

 Ti =số các khiếm khuyết nhỏ  

- Với mỗi bước chính trong phát triển phần mềm cần tính chỉ số pha PIi:  

PIi=w1(Si/Di) + w2(Mi/Di) + w3(Ti/Di)  

Trong đó w1, w2, w3 là trọng số tương ứng với các khiếm khuyết nghiêm trọng, vừa phải và

nhỏ.Trọng số này ước lượng mức thiệt hại mà loại đó mang lại  

Đảm Bảo Chất Lượng Phần Mềm (HC)  36

- Chỉ số khiếm khuyết tổng hợp DI được tính như sau:  

DI= (1PI1 + 2PI2 +...+iPIi)/PS  

Trong đó PS là kích cỡ của sản phẩm (là LOC = số dòng mã, hoặc số tuyên bố thiết kế, hoặc số

trang tài liệu) tuỳ theo từng bước.  

Theo công thức: hệ số khiếm khuyết càng về bước sau càng lớn.  

Câ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ì?  

a) Tiếp cận hình thức cho SQA  

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 đảm chấ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ên  

Tiế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 tra lỗi, chuyển

tự động đặc tả thành chương trình  

 Tăng chất lượng đáng kể  

Phương pháp hình thức hoá bao gồm:  

- Tìm công cụ đặc tả hình thức phần mềm (thường với các công cụ toán học)  

- Cho phép chứng minh được tính đúng đắn của đặc tả  

- Xây dựng các phép biến đổi để từng bước chuyển đặc tả thành chương trình  

- Chứng minh được các phép biến đổi là đúng đắn: luôn cho đặc tả đúng về hệ thống.  

b) Quá trình phòng sạch - Cleanroom  

Quá trình phòng sạch = Kiểm chứng chương trình một cách hình thức (chứng minh tính đúng đắn)

+ đảm bảo chất lượng phần mềm thống kê.  

- Phương châm của kĩ thuật này là: phòng khiếm khuyết hơn trừ khiếm khuyết  

- Cơ sở lý luận rằng: nên dành nhiều thời gian cho kiểm chứng chương trình toán học hơn là cho

gỡ lỗi.  

- Dùng quá trình này thì số khiếm khuyết cho mỗi LOC giảm đảng kể: với các dự án phần mềm có

kích cỡ từ 1000 đến 50000 LOC dùng quá trình phòng sạch đã tìm thấy 90% khiếm khuyết trước

khi kiểm thử chương trình lần đầu tiên.  

- Đến 1992 công nghệ phần mềm phòng sạch vẫn chưa được áp dụng rộng rãi trong công nghiệp.

Cần phải có các thay đổi thực chất trong cả quản lý cũng như trong kỹ thuật trước khi áp dụng

phương pháp này.  

Đảm Bảo Chất Lượng Phần Mềm (HC)  37

2.2. Các độ đo về sự tin cậy và an toàn  

Câ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?  

- Độ 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ê là: "Xác suất thao tác không thấ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 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?  

Khi nói đến độ tin cậy phần mềm thì nảy sinh câu hỏi "thất bại" nghĩa là gì? Thất bại là việc không

thi hành đúng các yêu cầu phần mềm.  

Các thang bậc thất bại:  

- Mức độ: Từ một sự phiền phức đến một thảm hoạ  

- Thời gian: Để loại trừ một thất bại có khi chỉ vài giây, đến cả tuần, cả tháng.  

- Hậu quả: Loại bớt một thất bại có thể lại sinh ra lỗi khác và kéo theo thất bại khác.

Câ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ó?  

- Độ tin cậy của các hệ thống dựa trên máy tí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  

Trong đó:  

MTTF (Mean Time To Failure): thời gian hoạt động liên tục trung bình  

MTTR (Mean Time To Repair): thời gian sửa xong lỗi trung bình  

- Ý nghĩa độ tin cậy:  

+ 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 Of Code) 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).  

+ Các lỗi trong chương trình không có cùng mức độ (số lỗi chỉ cho một chỉ số nhỏ về độ tin cậy):

Phần lớn lỗi tìm thấy sau khi vận hành 14 tháng, Rất ít lỗi chỉ được phát hiện sau hàng chục năm;

Các lỗi còn lại với MTBF khoảng 18-24 tháng.  

Đảm Bảo Chất Lượng Phần Mềm (HC)  38

- Độ 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 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ì?  

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). Musa cho rằng loại này 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 được sinh 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 nội tại của một chương trì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ượng 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  

- Ý tưởng: 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 kiểm thử), tính xác suất tìm được j lỗi trong tập J lỗi

xem 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 (tỉ lệ lỗi đã phát hiện)  

- Mục đích:  

Đảm Bảo Chất Lượng Phần Mềm (HC)  39

+ 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 ca

kiểm thử.  

Câ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?  

An toàn phần mềm là một hoạt động bảo đảm chất lượng phần mềm tập trung vào việc minh định

và đánh giá các mối nguy hiểm tiềm ẩn có thể gây ảnh hưởng phản tác dụng thậm chí là gây ra

thất bại của toàn hệ thống.  

- Quá trình mô hình hoá và phân tích được thực hiện như một pahanf của an toàn phần mềm nhằm

phát hiện vấn đề.  

- Thoạt tiên, minh định và đánh giá có phê phán các rủi ro, các mối nguy hiểm tiềm ẩn. Sau đó

dùng các kĩ thuật phân tích để đánh giá độ nghiêm trọng và xác suất xuất hiện.

- Để có hiệu quả, cần phải phân tích phần mềm trong ngữ cảnh của toàn hệ thống. Có thể dùng

các kĩ thuật phân tích như: phân tích cây lỗi, logic thời gian thực, mô hình lưới PETRY.  

Các phương pháp phân tích an toàn  

- Phân tích cây lỗi:  

+ Dựng lên một mô hình đồ thị của 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ên kế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ác toá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 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ì?  

- 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át triể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?  

Đảm Bảo Chất Lượng Phần Mềm (HC)  40

+ Đá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.  

Một khi ba câu hỏi trên đã được trả lời thì mức độ mạnh hay yếu đã được minh bạch.  

- Nếu có nhu cầu SQA 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 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ì?  

- Triển khai SQA có những vấn đề sau đây:  

+ Khó thiết lập trong một tổ chức nhỏ: vì thiếu nguồn lực để thực hiện các hoạt động cần thiết mà

hiện chưa có.  

+ Cần sự thay đổi có tính văn hoá: nên chẳng bao giờ dễ dàng thực hiện  

+ Tốn không ít công sức và tiền của  

- 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 gian kiể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í hiệu quả:  

Ở 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

 3. Kiểm thử phần mềm  

3.1. Khái niệm về kiểm thử  

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ó quan

niệm sai gì về kiểm thử phần mềm?  

Đảm Bảo Chất Lượng Phần Mềm (HC)  41

 Tại sao phải 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ã.  

[Deutsch] Việc phát triển hệ thống phần mềm bao gồm hàng loạt các hoạt động sản xuất, nơi

những cơ hội cho việc chen sai lầm của con người vào là rất lớn. Lỗi có thế bắt đầu xuất hiện tại

chính lúc khởi đầu tiến trình nơi các mục tiêu.. có thể được xác định sai hay không hoàn chỉnh,

cũng như các giai đoạn thiết kế và phát triển về sau.  

- Theo Glen Mayers: Kiểm thử phần mềm là quá trình vận hành chương trình để tìm ra lỗi.  

- Vấn đề: Cần vận hành như thế nào để hiệu suất tìm ra lỗi là cao nhất? và chi phí (thời gian, công

sức) là ít nhất?

 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 (xem sản phầm)  

 Hạn chế chi phí phải trả cho các thất bại do lỗi gây ra sau này (hiệu quả)  

 Có kế hoạch tốt nâng cao chất lượng cho suốt quá trình phát triển (giải pháp)  

 Tầm quan trọng của kiểm thử phần mềm:  

 Chi phí của 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  

 Với phần mềm ảnh hưởng tới sinh mạng chi phí có thể gấp từ 3 đến 5 lần tổng chi phí khác cộng

lại.  

- Kiểm thử tốt sẽ giúp: Giảm chi phí phát triển; Tăng độ tin cậy của sản phẩm phần mềm.  

 Mục tiêu kiểm thử phần mềm:  

- Mục tiêu trước mắt: Cố gắng tạo ra các ca kiểm thử để chỉ ra lỗi của phần mềm được xây dựng

(tức là "đánh đổ" phần mềm). Nghe có vẻ mang  Dễ gây ra những vấn đề về tâm lý.tính "phá hoại" 

 xây dựng.- Mục tiêu cuối cùng: có một chương trình tốt, chi phí ít   

 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ử  

Đảm Bảo Chất Lượng Phần Mềm (HC)  42

- 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  

- Chỉ cần kiểm thử một lần  

 Kiểm thử phần mềm là một phần của hoạt động lớn hơn là "xác minh (Verification) và thẩm định

(Validation)"  

Verification: "Are we building the product right?"  

Validation: "Are we building the right product?"  

+ Xác minh: là một tập hợp các hoạt động để đảm bảo rằng phần mềm thực hiện đúng chức năng

đã được đặc tả.  

+ Thẩm đinh: là một tập các hoạt động để đảm bảo rằng phần mềm đã được đáp ứng đúng yêu

cầu của khách hàng.  

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ụ

kiểm thử là gì?  

 Ca kiểm thử tốt là ca kiểm thử có xác suất cao trong việc tìm ra một lỗi chưa được phát hiện.  

 Một ca kiểm thử thắng lợi làm lộ ít nhất một lỗi còn chưa được phát hiện.  

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ụ:  

+ Thuyết minh rằng các chức năng phần mềm tương ứng với đặc tả (xác minh)  

+ Yêu cầu thực thi là phù hợp (thẩm định)  

+ Cung cấp thêm các chỉ số độ tin cậy và chỉ số về chất lượng phần mềm nói chung (thẩm định)  

"Kiểm thử không thể chứng minh được việc không có khiếm khuyết, nó chỉ có thể chứng minh rằng

khiếm khuyết phần mềm hiện hữu"  

Câu 39. 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  

Đảm Bảo Chất Lượng Phần Mềm (HC)  43

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

Sơ đồ dòng thông tin của tiến trình kiểm thử:  

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ết quả dự

kiến. Khi phát hiện lỗi, việc gỡ lỗi bắt đầu được tiến hành.  

Tiế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ần mề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ện bởi người dùng.  

Câ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?  

Đối tượng và phương pháp kiểm thử  

Loại Đơn vị Tích hợp Thẩm định Hệ thống  

Đối tượng Mã Thiết kế Yêu cầu Toàn hệ thống  

Phương pháp Hộp trắng Hộp đen Hộp đen Mô hình  

Kỹ thuật Đồ thị dòng, ma trận k.thử phân nhánh Cuống, bộ lái Phân hoạch, giá trị biên, đồ thị nhân

quả Mô phỏng  

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  

- Hộp trắng và đen: thiết kế  

- Hộp đen: Yêu cầu  

- Mô hình: Kĩ nghệ hệ thống  

Đảm Bảo Chất Lượng Phần Mềm (HC)  44

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ử?  

Thiết kế ca kiểm thử thường với mong muốn tìm ra được nhiều sai nhất với nỗ lực và thời gian là

nhỏ nhất.  

Trong các thập kỷ 80-90 đã nghiên cứu 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ế: bảo đảm tính đầy đủ (không sót phần nào) và cung cấp

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 (khi biết chức năng xác định mà một sản phẩm đã được thiết kế để thực hiện

thì có thể tiến hành kiểm thử xem từng chức năng có vận hành đúng hay không?)  

+ Kiểm thử hộp trắng (biết cách làm việc bên trong của sản phẩm, tiến hành kiểm thử để đảm bảo

rằng "tất cả các bánh răng đều ăn khớp", tức là đảm bảo rằng sự vận hành bên trong thực hiện

tương ứng với đặc tả và tất cả các thành phần bên trong đã được thử một cách thích hợp)  

[Tsuneo Yamaura] Chỉ có duy nhất một luật khi thiết kế ca kiểm thử: bao hàm hết tất cả các trường

hợp nhưng không được quá nhiều ca kiểm thử.  

Câu 42. Kiểm thử hộp trắng là cái gì? Nêu các đặc trưng của nó?  

- Đối tượng kiểm thử: Kiểm thử trực tiếp trên mã nguồn (mức modul đơn vị)  

- Khám xét các chi tiết thủ tục (thuật toán), các con đường logic (luồng điều khiển), các trạng thái

của chương trình (dữ liệu)  

- Vấn  đề  trở  ngại:  Số con  đường  logic  là  lớn.  Chẳng  hạn  chương trình  nhỏ  chỉ  có  100  dòng

PASCAL 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ểm thử hết

1ms thì tốn 3170 năm làm kiểm thử cho tất cả các con đường đó.  

- Cách thức: 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ử  

- Nội dung kiểm thử (kiểm thử cái gì?):  

+ Mọi lệnh được thực hiện (đầy đủ)  

+ Mọi điều kiện được kiểm tra (rẽ nhánh)  

+ Mọi chu trình được duyệt qua (lặp lại)  

+ Mọi cấu trúc dữ liệu được dùng (dữ liệu)  

+ Mọi tiến trình từ đầu đến kết thúc (từng luồng điều khiển)

- Yêu cầu đặt ra:  

Đảm Bảo Chất Lượng Phần Mềm (HC)  45

+ Mọi con đường độc lập trong modul cần được thực hiện ít nhất một lần.  

+ Mọi ràng buộc logic được thực hiện cả hai phía đúng (true) và phía sai (false)  

+ Tất cả các vòng lặp ở biên của nó và cả các biên vận hành phải được thực hiện  

+ Mọi cấu trúc dữ liệu nội tại được dùng để đảm bảo tính hiệu lực của nó.  

- Lý do kiểm thử hộp trắng:  

+ Các sai logic và giả thiết không đúng đắn tỉ lệ nghịch với xác suất để một con đường logic được

thi hành.  

+ Thực tế: mọi con đường logic đều có thể được thi hành trên 1 cơ sở nhất định (ta cho rằng 1 con

đường logic nào đó là không thể được thi hành).  

+ Có những sai chính tả có thể là ngẫu nhiên trên đường ta không kiểm tra.  

Câu 43. Kiểm thử hộp đen là cái gì? Nêu các đặc trưng của nó?  

- Khái niệm: Kiểm thử hộp đen là phương pháp kiểm thử yêu cầu chức năng tập trung vào các yêu

cầu chức năng của phần mềm.  

- Đặc trưng:  

+ Nhằm thuyết minh các chức năng phần mềm đủ và vận hành đúng  

+ Thực hiện các phép thử qua giao diện  

+ Cơ sở: đặc tả, các điều kiện vào/ra và cấu trúc dữ liệu  

+ Ít chú ý tới cấu trúc logic nội tại của nó  

- Đối tượng: Modul, hệ con, toàn hệ thống.  

Câ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?  

- Khái niệ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ạo

thà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ềm thành công.  

- Nó đưa ra một bản đồ các đường đi để:  

+ Nhà phát triển tổ chức đảm bảo chất lượng  

+ Khách hàng: biết các phần việc kiểm thử với công sức, thời gian và nguồn lực cần thiết.  

- Yêu cầu chiến lược kiểm thử:  

Đảm Bảo Chất Lượng Phần Mềm (HC)  46

+ Phải tích hợp được việc lập kế hoạch kiểm thử, việc thiết kế ca kiểm thử, việc tiến hành kiểm thử

và 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ách hàng (mà tất cả các hệ thống lớ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ành một cách

có hệ thống. Chính vì vậy mà cần xác định một khuôn mẫu (template) cho việc kiểm thử phần mềm

trong tiến trình kỹ nghệ phần mềm  

- Các đặc trưng có tính khuôn mẫu:  

+ Bắt đầu ở mức modul và tiếp tục cho đến khi tích hợp ở mức hệ thống dựa trên máy tính trọn

vẹn.  

+ Các kỹ thuật kiểm thử khác nhau là thích hợp cho 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ử đi trước 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 xem từng

khúc mã nguồn có được thực thi đúng đắn không) cũng như các kiểm thử mức cao (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ách hà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ành kiểm thử

và cung cấp các cột mốc cho các nhà quản lý để quản lý hoạt động đảm bả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 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?  

- Hệ thời gian thực là hệ thống đáp ứng đúng, chính xác các sự kiện của môi trường.  

- Chiến lược kiểm thử hệ thời gian thực: Rất khó khăn và kết quả chưa nhiều.

- Chiến lược kiểm thử 4 bước:  

1. Kiểm thử tác vụ: Kiểm thử từng tác vụ (operation) một cách độc lập với nhau (bằng cả kỹ thuật

hộp trắ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ện sai

về thời gian và ứng xử.  

2. Kiểm thử ứng xử:  

Đảm Bảo Chất Lượng Phần Mềm (HC)  47

+ Sử dụng công cụ CASE tạo mô hình hệ thống để mô phỏng ứng xử của hệ thời gian 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 đồ thị nhân quả)  

+ Phân lớp sự kiện (tương tự phân hoạch tương đương). Kiểm thử từng lớp sự kiện và nhận ứng

xử của hệ thi hành để phát hiện các sai do xử lý đáp ứng các sự kiện đó.  

+ 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ử.  

3. Kiểm thử liên tác: tìm các sai liên quan đến đáp ứng thời gian do không đồng bộ  

+ Các tác vụ không đồng bộ khi liên tác với các tác vụ khác. Vì thế cần kiểm thử với nhịp điệu dữ

liệu và mức tải với các xử lý khác nhau.  

+ Các tác vụ không đồng bộ do giao tiếp phụ thuộc hàng đợi thông điệp hoặc truy nhập kho dữ liệu

cũng được thử để bộc lộ các sai về cỡ dữ liệu.  

4. Kiểm thử hệ thống: sau khi tích hợp phần cứng và phần mềm cần tiến hành kiểm thử hệ thống

để tìm ra các sai.  

+ Giao diện (giữa phần cứng và phần mềm)  

+ Môi trường (tác động từ môi trường, các sự kiện)  

+ Các ngắt (các loại ngắt và các xử lý xảy ra như hậu quả của ngắt)  

Câ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?  

- Bộ phân tích tĩnh: phân tích cấu trúc và định dạng chương trình.  

- Bộ kiểm toán mã: xem phần mềm có phù hợp với các chuẩn mã tối thiểu chưa?  

- Bộ phận xử lý khai báo: xem những khai báo ứng xử của chương trình có thật sự phù hợp với sự

thực hiện chương trình thực hay không?  

- Bộ sinh tệp kiểm thử: cho ra các giá trị tiền xác định, các tệp vào điển hình cho chương trình chịu

kiểm thử.  

- Bộ sinh dữ liệu kiểm thử: giúp lựa chọn dữ liệu để làm chương trình ứng xử theo một cách đặc

biệt.  

- Bộ xác minh kết quả: đưa ra báo cáo giá trị trung bình kết quả cho chuyên gia đảm bảo chất

lượng phần mềm.  

- Các trợ giúp cho quá trình kiểm thử:  

+ Cài đặt một chương trình dự định trong môi trường kiểm thử  

Đảm Bảo Chất Lượng Phần Mềm (HC)  48

+ Nuôi chương trình đo bằng dữ liệu vào  

+ Mô phỏng ứng xử của các mô dun phụ  

- Bộ so sánh đầu ra: so sánh một tập dữ liệu ra với một tập khác để xác định sự khác biệt.  

- Hệ tiến hành ký hiệu: dùng đặc tả đại số  

- Mô phỏng môi trường: là một hệ thống dựa vào máy tính chuyên biệt có thể kiểm thử các môi

trường ngoại lai của phần mềm thời gian thực và mô phỏng các điều kiện vận hành đông thực sự.  

- Bộ phân tích dòng dữ liệu: phân tích quy mô và tần suất dòng dữ liệu.  

Câ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?  

- Kiểm thử phần mềm gồm cả người phát triển và nhóm kiểm thử độc lập  

- Người kiểm thử luôn chịu trách nhiệm kiểm thử đơn vị (modul) do mình phát triển và bảo đảm mỗi

modul đó thực hiện đúng chức năng được thiết kế.  

- Trong nhiều trường hợp, người phát triển cũng tham gia kiểm thử tích hợp.  

- Chỉ sau khi kiến trúc phần mềm đã đầy đủ thì nhóm kiểm thử độc lập mới bắt đầu làm việc.  

- Vai trò của nhóm kiểm thử độc lập là gỡ bỏ những vấn đề cố hữu do "người xây dựng kiểm thử

tạo ra chúng".

+ Gỡ bỏ mâu thuẫn về mối quan tâm.  

+ Trả công cho việc tìm lỗi.  

- Kết quả của nhóm kiểm thử độc lập cần được gửi cho tổ chức bảo đảm chất lượng phần mềm.  

- Người phát triển không được đẩy chương trình sang người kiểm thử rồi bỏ đi.  

- Người phát triển cùng làm việc với người kiểm thử xuyên suốt một dự án phần mềm để bảo đảm

việc kiểm thử được tiến hành triệt để.  

3.2. Các phương pháp kiểm thử  

a. Kiểm thử hộp trắng  

Câ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ì?  

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ểm thử.

Đảm Bảo Chất Lượng Phần Mềm (HC)  49

Thiết kế ca kiểm thử phải đảm bảo:  

- Bảo đảm rằng mọi con đường độc lập trong một modul đều được thực hiện ít nhất một lầ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 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ì?  

- Đồ thị dòng là một kĩ thuật dùng cho kiểm thử hộp trắng, được Tom McCabe đưa ra đầu tiên.  

- Đồ thị dòng gần giống đồ thị luồng điều khiển của chương trình.  

- Phương pháp đương cơ sở làm cho người thiết kế ca kiểm thử có thể suy dẫn ra một cách đo độ

phức tạp logic của thiết kế thủ tục và dùng cách đo này như một hướng dẫn để xác định một tập cơ

sở các đường thực hiện. Các ca kiểm thử được suy dẫn ra để thực hiện một tập cơ sở, được đảm

bảo để thực hiện mọi câu lệnh trong chương trình ít nhất một lần trong khi kiểm thử.  

- Đồ thị dòng nhận được từ đồ thị luồng điều khiển của chương trình bằng cách:  

+ Gộp các lệnh tuần tự  

+ Thay lệnh rẽ nhánh và điểm kết thúc của các đường điều khiển bằng 1 nút vị tự.  

- Cấu trúc đồ thị dòng gồm:  

+ Mỗi nút (hình tròn) biểu thị một hay một số lệnh tuần tự, hoặc thay cho điểm hội tụ các đường

điều khiển.  

+ Mỗi cạnh nối hai nút biểu diễn dòng điều khiển.  

 Kết quả:  

+ Chia mặt phẳng thành nhiều miền.  

+ Một nút là vị từ biểu thị sự phân nhánh hoặc hội nhập của cung.  

Đồ thị dòng dùng để biểu diễn thiết kế thủ tục  

Câ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?  

Các đường cơ bản trong đồ thị dòng:  

Đảm Bảo Chất Lượng Phần Mềm (HC)  50

 - Độ phức tạp của chu trình  

+ Để đảm bảo các câu lệnh đều được kiểm thử ít nhất một lần, cần tìm tất cả các đường điều khiển

độc lập trong chương trình (khác với các đường khác ít nhất một lệnh).  

+ Số các đường độc lập của một chương trình là giới hạn trên của số các kiểm thử cần phải tiến

hành. Nó được gọi là độ phức tạp chu trình của chương trình.  

+ Các đường độc lập của 1 chương trình trùng với các đường độc lập của đồ thị dòng (tìm đơn

giản hơn)  

Một tập cơ bản con đường độc lập là tập:  

- Mọi cạnh của đồ thị dòng đều có mặt trong một con đường của tập này.  

- Mỗi con đường của tập đó đều chứa ít nhất một cung không có mặt trong mọi con đường khác

của nó.  

- Số lượng các con đường của tập này cho ta số đo độ phức tạp chu trình của một chương trình  

Ví dụ: 

 Đường độc lập:  

- Đường 1: 1-11  

- Đường 2: 1-2-3-4-5-10-1-11  

- Đường 3: 1-2-3-6-7-9-10-1-11

- Đường 4: 1-2-3-6-8-9-10-1-11  

Các công thức tính độ phức tạp chu trình  

+ Độ phức tạp chu trình V(G) đối với 1 đồ thị dòng G được tính theo các cách sau:  

V(G) = số miền phẳng  

V(G) = E - N + 2 (Với E là số cạnh, N là số nút của đồ thị dòng)  

V(G) = P + 1 (Với P là số nút vị từ - nút có chứa một điều kiện, được đặc trưng bởi hai hay nhiều

cạnh phát ra từ nó)  

Giá trị V(G) cung cấp cho chúng ta một cận trên về số các đường độc lập bao gồm tập cơ sở, và

kết quả là một cận trên về số các phép kiểm thử phải được thiết kế và thực hiện để đảm bảo bao

quát tất cả các câu lệnh chương trình.  

Câu 51. Ma trận kiểm thử được cấu trúc như thế nào? Nó được dùng để làm gì?  

Đảm Bảo Chất Lượng Phần Mềm (HC)  51

- Cấu trúc ma trận kiểm thử:  

+ Ma trận kiểm thử là một ma trận vuông có kích thước bằng số các nút trong đồ thị dòng, trong đó:

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. (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óc hóa)  

+ Nhân liên tiếp k ma trận này được ma trận chỉ số con đường k cung từ nút dòng tới nút cột.  

- Để 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ển chương

trình khi kiểm thử người ta sử dụng ma trận có trọng số (thêm trọng số cho các cung) như sau:  

+ Xác suất cung đó được thực thi.  

+ Thời gian xử lý của tiến trình đi qua cung đó.  

+ Bộ nhớ đòi hỏi của tiến trình đi qua cung đó.  

+ Nguồn lực được đòi hỏi của tiến trình đi qua cung đó.  

Câ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ử?  

- Điều kiện logic của cấu trúc điều khiển:  

+ Điều kiện đơn: là 1 biến Bool (có thể có toán tử phủ định): X  

+ Điều kiện đơn: là biểu thức quan hệ giữa 2 biểu thức số học  

, với là phép so sánh: <, ≤, =, ≥ hay ≠  

A, B là biểu thức số học  

+ Điều kiện phức hợp: cấu thành từ hơn một điều kiện đơn nhờ các toán tử Bool: hoặc , và , phủ

định  

, trong đó Xi là điều kiện đơn, & là toán tử Bool.  

- Kiểu sai trong điều kiện logic kiểm thử:  

+ Sai biến Bool  

+ Sai toán tử Bool  

+ Sai số hạng trong biểu thức toán tử Bool  

Đảm Bảo Chất Lượng Phần Mềm (HC)  52

+ Sai toán tử quan hệ  

+ Sai biểu thức số học.  

Câ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ì?  

- Kiểm thử phân nhánh là chiến lược kiểm thử từng điều kiện chương trình  

- Kiểm thử nhánh: Với mỗi điều kiện kết hợp C thì các nhánh "true" và "false" của C và mỗi điều

kiện đơn trong C phải được kiểm thử ít nhất 1 lần.  

- Yêu cầu: Không chỉ phát hiện sai trong điều kiện đó mà mà còn phát hiện các sai khác trong

chương trình.  

Câ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?  

- Chiến lược kiểm thử miền đòi hỏi 3 hoặc 4 kiểm thử cho một biểu thức quan hệ: gồm các trường

hợp <, >, = và có thể ≠ nữa.  

Ví dụ:  

Với biểu thức quan hệ có dạng E1 <toán tử quan hệ> E2 thì cần tới 3 phép kiểm thử để làm cho

giá trị của E1 lớn hơn, bằng hoặc nhỏ hơn giá trị của E2 tương ứng. Nếu <toán tử quan hệ> là

không đúng và E1 và E2 đúng thì 3 phép kiểm thử này đảm bảo phát hiện ra toán tử sai. Để phát

hiện ra lỗi trong E1 và E2, phép kiểm thử làm cho giá trị của E1 lớn hơn hay bé hơn giá trị của E2

nên tạo ra sự khác biệt giữa hai giá trị này nhỏ nhất có thể có được.  

- Với biểu thức Bool có n biến sẽ cần 2n phép kiểm thử có thể có (n>0) nên có chỉ thuận lợi nếu n

nhỏ và sẽ thiếu thực tế nếu n lớn.

Câu 55. Chiến lược kiểm thử BRO là cái gì? Nó dựa trên tư tưởng nào?  

BRO = kiểm thử nhánh và toán tử quan hệ (Branch & Relational Operation)  

- Chiến lược kiểm thử BRO là kiểm thử toán tử quan hệ và nhánh. Kỹ thuật này đảm bảo việc phát

hiện ra các lỗi quan hệ và nhánh trong điều kiện mà tất các các biến Bool và toán tử quan hệ chỉ

xuất hiện 1 lần và không có biến chung.  

BRO dùng đến "ràng buộc điều kiện cho điều kiện cần thử".  

Giả sử: , Xi: điều kiện đơn, &: toán tử Bool. Cần đặc tả ràng buộc đầu ra của Xi tương ứng với điều

kiện D đã xác định?  

+ Ta nói rằng ràng buộc Xi của điều kiện D là được phủ bởi một sự thực thi của C nếu như trong

quá trình thực thi đó, đầu ra của mỗi điều kiện đơn Xi tr D thoả mãn các ràng buộc tương ứng. Có

nghĩa là: khi giâ trị của D đã cho, ta cần tìm các điều kiện ràng buộc mà mỗi Xi (1 thành viên của D)

cần thoả mãn để đảm bảo được giá trị của D.  

Đảm Bảo Chất Lượng Phần Mềm (HC)  53

- Tư tưởng: Cho phép thử nhạy cảm sai cho biểu thức Bool. Với một biểu thức Bool duy nhất (một

biểu thức Bool mà mỗi biến Bool chỉ xuất hiện 1 lần) với n biến Bool (n>0) chúng ta có thể dễ dàng

sinh ra một tập kiểm thử ít hơn 2n phép thử sao cho tập kiểm thử này đảm bảo phát hiện ra nhiều

lỗi toán tử Bool và cũng là hiệu quả để phát hiện các lỗi khác.  

Câ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ệ?  

- Với một biến Bool B. thì ràng buộc đầu ra của B là t (true) hoặc f (false)  

- Với một biểu thức quan hệ thì ràng buộc đầu ra của nó là toán tử quan hệ: có thể nhận một trong

4 giá trị >, <, =, ≠  

- Xét điều kiện , A và B là 2 biến Bool. Khi đó ràng buộc đầu ra của C là một cặp giá trị của t và f.

Chiến lược kiểm thử BRO đòi hỏi rằng tập 3 cặp ràng buộc (t,t), (t,f), (f,t) đểu được phủ bởi các

thực thi của C:  

Cặp (t,t) ứng với C=t  

Cặp (t,f) và (f,t) ứng với C=f  

- Xét điều kiện C là hội biến Bool và biểu thức quan hệ: A & (B=E). Khi đó các ràng buộc của C là

các cặp (t,t), (t,f), (f,t): với (B=E) có giá trị t tương ứng với =, và giá trị f tương ứng với < hoặc >.

Bởi vậy, tập các ràng buộc đầu ra của C phải gồm 4 phần tử: (t,=), (t,<), (t,>), (f,=). Phủ của các

ràng buộc này đảm bảo phát hiện được sai biến Bool hoặc toán tử quan hệ trong C.  

- Xét điều kiện C: (A>B)&(E=F). Tập ràng buộc đầu ra sẽ là(t,t), (t,f), và (f,t) và tương ứng sẽ là:

(>,=), (>,<), (>,>), (=,=) và (<,=). Phủ của ràng buộc này đảm bảo rằng phát hiện được sai ở các

toán tử trong quan hệ C.  

Câu 57. 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. Đã có một số chiến

lược kiểm thử 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àm khô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ùy theo

điều kiện trong S.  

Đảm Bảo Chất Lượng Phần Mềm (HC)  54

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 DU sử dụng của X là DU=[X,S,S'] với X trong DEF(S), và trong USE(S') và định

nghĩa X trong S vẫn còn sống trong S'.  

+ Chiến lược kiểm thử 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.  

+ Kiể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ánh khô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âu lệnh

if hoặc chu trình lồng nhau.  

Ví dụ:  

Proc x  

B1;  

Do while C1  

If C2  

Then  

If C4  

Then B4;  

Else B5;  

Endif;  

Else  

If C3  

Then B2;  

Else B3;  

Endif  

Endif  

Enddo;  

Đảm Bảo Chất Lượng Phần Mềm (HC)  55

B6;  

End proc;  

Giả sử biến X được định nghĩa trong câu lệnh cuối của các khối B1, B2, B3, B4, B5 và được dùng

trong câu lệnh đầu tiên của các khối B2, B3, B4, B5 và B6. Chiến lược kiểm thử DU đòi hỏi việc

thực hiện của đường đi ngắn nhất từ mỗi Bi 0<i<=5 tới mỗi Bj 1<j<=6 (Việc kiểm thử như vậy cũng

bao quát mọi việc dùng biến X trong các điều kiện C1,C2, C3, C4) Mặc dầu có tới 25 dây chuyền

DU của biến X, chúng ta chỉ cần năm đường đi để bao quát các dây chuyền 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ách làm cho năm đường này có

chứa những việc lặp của chu trình.  

Câu 58. Kiểm thử điều khiển vòng lặp nghĩa là gì? Cho ví dụ?  

- Kiểm thử vòng lặp là một kỹ thuật kiểm thử hộp trắng tập trung hoàn toàn vào tính hợp lệ của kết

cấu vòng lặp. Có thể xác định 4 lớp vòng lặp khác nhau: vòng lặp đơn, vòng lặp lồng, vòng lặp nối

tiếp, vòng lặp phi cấu trúc  

- Vòng lặp đơn: tập các kiểm thử được áp dụng cho vòng lặp đơn với n là số tối đa các bước được

phép qua vòng lặp  

+ Nhảy qua toàn bộ vòng lặp  

+ Chỉ qua một bước vòng lặp  

+ Hai bước qua vòng lặp  

+ m bước qua chu trình với m<n  

+ n-1, n, n +1 bước qua vòng lặp  

- Vòng lặp lồng: Số phép kiểm thử có thể sẽ tăng theo cấp số nhân khi mức độ lồng nhau tăng lên:

+ Bắt đầu từ vòng lặp bên trong nhất. Đặt tất cả các vòng lặp khác vào giá trị tối thiểu  

+ Tiến hành kiểm thử vòng lặp đơn cho vòng lặp bên trong nhất trong khi giữ các vòng lặp bên

ngoài ở giá trị tham số lặp tối thiểu. Bổ sung các kiểm thử 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.  

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

Đảm Bảo Chất Lượng Phần Mềm (HC)  56

- 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

b. Kiểm thử hộp đen  

Câ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ó?  

- 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 modul  

- 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át vớ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ểm thử 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 động tươ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 ca kiể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 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?  

- 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ểm thử.  

Cơ sở: dữ liệu trong 1 lớp tương đương tác động như nahu lên chương trình, tạo ra cùng 1 trạng

thái, đúng hay sai của chương trình.  

Đảm Bảo Chất Lượng Phần Mềm (HC)  57

 rút gọn số ca kiểm thử cần phát triển- Mục tiêu: Nhằm tìm ra một ca kiểm thử để bộ lộ một lớp sai 

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

kiểm thử được thiết kế cho từng lớp tương đương.  

- Phương châm:  

1. Điều kiện vào là phạm vi rộng giới hạn một miền hay những giá trị đặc biệt thì cần xác định:  

+ 1 lớp tương đương hợp lệ  

+ 2 lớp tương đương không hợp lệ  

2. Đ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:  

+ 1 lớp tương đương hợp lệ  

+ 2 lớp tương đương không hợp lệ  

Câ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ì?  

+ Các sai có xu hướng xuất hiện ở biên của vùng dữ liệu (hơn là ở trung tâm).  

+ Các sai có thể cả trong và ngoài biên.  

+ Kiểm thử không chỉ chú ý đến các dữ liệu biên mà con chú ý đến các dữ liệu sát biên (trong,

ngoài).  

- Phân tích giá trị biên nghĩa là chọn lựa các ca kiểm thử nhằm thực hiện các giá trị biên và sát

biên.  

- Phương châm:  

3. Nếu điều kiện vào là một miền giới hạn bởi a và b thì cần thiết kế các ca kiểm thử cho cả a và b,

và cả trên, dưới a và b.  

4. Nếu điều kiện vào đặc tả một số giá trị thì thiết kế các ca kiểm thử cho cả các số trên và dưới số

nhỏ nhất và lớn nhất.  

Áp dụng các phương châm 1 và 2 cho cả điều kiện ra.  

Áp dụng điều kiện giá trị biên cho cả chương trình trung gian có các biên của cấu trúc dữ liệu được

mô tả.  

Câ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?  

Đảm Bảo Chất Lượng Phần Mềm (HC)  58

- 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ính xác

các điều kiện logic và các hành động tương ứng.  

- Kĩ thuật này gồm 4 bước:  

1. Lập danh sách các nguyên nhân (điều kiện vào) và kết quả (hành động thực hiện) cho từng

modul và gán giá trị định danh cho chúng..  

Được xây dựng dựa trên các modul chức năng.  

2. Phát triển một đồ thị nhân quả  

3. Chuyển đồ thị đó thành bảng quyết định  

4. Sử dụng các quy luật của bảng quyết định để xây dựng các ca kiểm thử.

Câ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?  

Chiến lược kiểm thử thời gian thực gồm 4 bước:  

1. Kiểm thử tác vụ: Kiểm thử từng tác vụ (operation) một cách độc lập với nhau (bằng cả kỹ thuật

hộp trắ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ện sai

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ời gian 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 đồ thị nhân quả)  

+ Phân lớp sự kiện (tương tự phân hoạch tương đương). Kiểm thử từng lớp sự kiện và nhận ứng

xử của hệ thi hành để phát hiện các sai do xử lý đáp ứng các sự kiện đó.  

+ 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ử.  

3. Kiểm thử liên tác: tìm các sai liên quan đến đáp ứng thời gian do không đồng bộ  

+ Các tác vụ không đồng bộ khi liên tác với các tác vụ khác. Vì thế cần kiểm thử với nhịp điệu dữ

liệu và mức tải với các xử lý khác nhau.  

+ Các tác vụ không đồng bộ do giao tiếp phụ thuộc hàng đợi thông điệp hoặc truy nhập kho dữ liệu

cũng được thử để bộc lộ các sai về cỡ dữ liệu.  

4. Kiểm thử hệ thống: sau khi tích hợp phần cứng và phần mềm cần tiến hành kiểm thử hệ thống

để tìm ra các sai.  

+ Giao diện (giữa phần cứng và phần mềm)  

Đảm Bảo Chất Lượng Phần Mềm (HC)  59

+ Môi trường (tác động từ môi trường, các sự kiện)  

+ Các ngắt (các loại ngắt và các xử lý xảy ra như hậu quả của ngắt).  

c. Kiểm thử đơn vị  

Câ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?  

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à modul. 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 modul.  

Nó kiểm thử các phần sau:  

- Kiểm thử giao diện  

- Khám nghiện cấu trúc dữ liệu cục bộ.  

- Kiểm thử 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 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ố đó?  

- Kiểm thử đơn vị có các nội dung:  

+ Kiểm thử giao diện  

+ Khám nghiệm cấu trúc dữ liệu cục bộ  

+ Kiểm thử với các điều kiện biên  

+ Các đường độc lập  

+ Các đường xử lý sai  

- Câu hỏi kiểm thử cho các nhân tố:  

Đảm Bảo Chất Lượng Phần Mềm (HC)  60

+ Tham số:  

• Số lượng các tham số có bằng đối số hay không?  

• Các tính chất của tham số và của đối số có đồng nhất không?  

• Các đơn vị của tham số và của đối số có đồng nhất không?  

• Số các đối số được truyền để gọi modul có bằng số các tham số hay không?  

• Các thuộc tính của các đối được truyền để gọi modul có trùng với các thuộc tính của các tham số

hay không?  

• Hệ thống đơn vị của các đối được truyền để gọi modul có trùng với hệ thống đơn vị của các tham

số hay không?  

• Số thuộc tính và các cái khác của các đối của các hàm được định sẵn có đúng đắn hay không?

• Mọi tham khảo liên quan tới các tham số hiện không kết hợp với đầu vào chứ?  

• Các đối chỉ đọc đã được đổi chưa?  

• Các định nghĩa biến toàn cục có như một trong suốt modul không?  

• Các ràng buộc đã chuyển qua như là tham số chưa?  

+ Vào ra: Khi một modul có thực hiện I/O ngoại lai thì phải tiến hành thêm:  

• Tính chất của các file có đúng đắn hay không?  

• Các câu lệnh OPEN/CLOSE có đúng đắn không?  

• Đặc tả hình thức có đúng với các câu lệnh I/O?  

• Cỡ của buffer có đúng với cỡ của bản ghi không?  

• Các file có mở trước khi sử dụng không?  

• Các điều kiện end-of-file có được xử lý?  

• Các sai lầm I/O có được xử lý?  

• Có sai văn bản nào trong thông tin ra?  

+ Dữ liệu cục bộ: Cấu trúc dữ liệu cục bộ cho modul còn là nguồn gây lỗi chung. Vì thế nên thiết kế

các kiểm thử để bóc trần các lỗi loại sau:  

• Đánh máy không đúng hoặc không nhất quán.  

Đảm Bảo Chất Lượng Phần Mềm (HC)  61

• Giá trị ngầm định hoặc giá trị khởi thuỷ sai.  

• Tên các biến không đúng (sai chữ hoặc mất chữ)  

• Kiểu dữ liệu không nhất quán.  

• Ngoại biệt về địa chỉ, underflow, overflow.  

- Thủ tục tính toán: Các sai thường thấy về tính toán là:  

• Hiểu lầm hoặc ưu tiên các phép tính số học không đúng.  

• Các phép toán trộn mode.  

• Khởi sự không đúng đắn.  

• Sự không chính xác  

- Dòng điều khiển: Sau việc so sánh thì các dòng điều khiển bị thay. Các ca kiểm thử cần bộc lộ

các sai như:  

• So sánh các kiểu dữ liệu khác nhau.  

• Ưu tiên hoặc toán tử logic không đúng đắn.  

• Dự đoán một đẳng thức, trong khi sai số làm cho đẳng thức không chắc có thực.  

• Các giá trị hoặc so sánh không đúng đắn.  

• Không kết thúc vòng lặp hoặc kết thúc không chính xác.  

• Khó thoát được khi tình cờ gặp sự lặp phân kỳ  

• Các biến lặp bị cải biên không chính xác.  

- Sai tiềm ẩn:  

• Mô tả sai là khó hiểu  

• Sai được ghi là không tương ứng với sai đã gặp  

• Điều kiện sai gây ra bị hệ thống can thiệp trước khi xử lý sai  

• Xử lý điều kiện ngoại lệ là không đúng đắn  

• Mô tả sai là không cung cấp đủ thông tin để trợ giúp định vị nguyên nhân của sai  

Đảm Bảo Chất Lượng Phần Mềm (HC)  62

Câ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ì?  

Kiểm thử đơn vị sử dụng các kỹ thuật:  

- Kiểm thử đường cơ sở, kiểm thử vòng lặp: Vì các trường hợp kiểm thử nên được thiết kế để phát

hiện ra lỗi do tính toán sai, so sánh sai hay luồn điều khiển không đúng. Đây là kỹ thuật hiệu quả để

phát hiện một phạm vi rộng các lỗi  

- Kiểm thử biên (nhiệm vụ cuối cùng, có lẽ là quan trọng nhất): Vì phần mềm thường thất bại tại

các biên của chúng. Tức là lỗi thường xuất hiện khi phần tử thứ n của mảng n chiều được xử lý;

khi lần lặp thứ i của chu trình với i bước được gọi, khi các giá trị tối thiểu hay tối đa cho pháp được

gặp phải. Khó khăn: Các trường hợp kiểm thử chạy qua cấu trúc dữ liệu, luồng điều khiển và giá trị

dữ liệu ngay dưới, ở tại và ngay trên cực đại và cực tiểu rất thường phát hiện ra lỗi.  

d. Kiểm thử tích hợp  

Câ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?  

- 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. Kiểm thử tích hợp nhằm nhận được

một phần hay toàn bộ hệ thống như mong đợi.  

- Mục đích: tậndungj các modul đã kiểm thử đơn vị và xây dựng chương trình sao cho nó đảm bảo

tuân theo thiết kế.  

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ó thể có một hiệu ứng bất lợi vô tình lên các modul 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 đề.....  

Câ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?  

Các phương pháp áp dụng cho kiểm thử tích hợ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ình bằng

cách tiếp cận vụ nổ lớn "big-bang". Tất cả các modul đề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ải mộ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ệc trả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.  

Đảm Bảo Chất Lượng Phần Mềm (HC)  63

- 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ây dựng

cấu trúc chương trình. Các modul được tích hợp bằng cách đi dần xuống theo trật tự điều khiển,

bắt đầu với modul điều khiển chính (chương trình chính). Các modul phụ thuộc (và phụ thuộc cuối

cùng) vào modul điều khiển chính sẽ được tổ hợp dần vào trong cấu trúc theo hoặ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 modul nguyên tử (tức là

các modul ở mức thấp nhất trong cấu trúc chương trình). Vì các modul 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 modul 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 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?  

Quá trình tích hợp từ trên xuống được thực hiện theo 5 bước:  

1. Modul điều khiển chính được dùng như bộ lái kiểm thử (test driver) và tất cả các modul phụ trợ

được thay thế bởi các cuống (stub).  

2. Thay thế dần từng cuống bởi modul thực thi tương ứng.  

3. Sau khi tích hợp modul đó, tiến hành các kiểm thử tương ứng.  

4. Sau khi hoàn thành đủ tập các kiểm thử này thì thay một cuống (stub) khác bằng modul thực

(nghĩa là quay lại bước 2).  

5. Có thể kiểm thử lại (toàn bộ hoặc một phần các kiểm thử trước) để bảo đảm rằng không có sai

mới nào được sinh ra.  

6. Tiếp tục lặp lại từ bước 2 cho tới khi toàn bộ cấu trúc chương trình được xây dựng.  

Ưu, nhược điểm:  

+ Ưu: Kiểm thử được chức năng điều khiển chủ yếu sớm.  

+ Nhược: Cần thiết các cuống + Các khó khăn kèm theo cuống.  

+ Chiến lược này có vẻ không phức tạp, nhưng thực tế nảy ra các vấn đề logic: khi xử lý ở mức

thấp lại đòi hỏi phải đủ tương xứng với mức cao.  

+ Các cuống được thay thế cho các modul mức thấp, do đó không 1 dữ liệu có ý nghĩa nào có thể

chảy ngược lên trong cấu trúc của chương trình. Người kiểm thử đứng trước 2 lựa chọn: (1) để trễ

nhiều việc kiểm thử tới khi cuống được thay thế bằng modul thực tế, (2) xây dựng các cuống thực

hiện những chức năng giới hạn mô phỏng cho modul thực tại, và (3) tích hợp phần mềm từ đáy

cấp bậc lên.  

Câ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?  

Đảm Bảo Chất Lượng Phần Mềm (HC)  64

- Bắt đầu xây dựng và kiểm thử từ các modul nguyên tố: việc xử lý nếu có đòi hỏi các modul phụ

trợ thì các modul thực sự đã sẵn sàng (cuống đã bị loại).

- Được thực hiện qua 4 bước:  

1. Các modul mức thấp được tổ hợp vào trong các cụm (cluster) thực hiện một chức năng phụ trợ

đặc biệt (các cluster gọi là các build)  

2. Một bộ lái (chương trình điều khiển kiểm thử) được viết để phối hợp đầu vào và đầu ra của ca

kiểm thử.  

3. Kiểm thử cụm đó.  

4. Tháo bỏ các driver và các cụm được tổ hợp ngược lên trong cấu trúc chương trình  

Ưu nhược điểm:  

+ Ưu: Thiết kế ca kiểm thử dễ và không cần cuống  

+ Nhược: luôn chứa chương trình như một chỉnh thể cho đến khi modul cuối cùng được thêm vào.

Câu 71. Các tài liệu kiểm thử tích hợp gồm những loại gì?  

- Một kế hoạch kiểm thử tổng thể và một mô tả các kiểm thử đặc biệt phải được đưa vào "đặc tả

kiểm thử". Đặc tả này phải được phân phối trong tiến trình kỹ nghệ phần mềm và trở thành 1 bộ

phận cấu hình phần mềm.  

Tài liệu kiểm thử bao gồm:  

I. Phạm vi kiểm thử  

II. Kế hoạch kiểm thử  

A. Các giai đoạn và khối kiểm thử  

B. Lịch biểu  

C. Tổng phí phần mềm  

D. Môi trường và tài nguyên  

III. Thủ tục kiểm thử n (mô tả việc kiểm thử cho khối n)  

A. Thứ tự tích hợp  

1. Mục đích  

Đảm Bảo Chất Lượng Phần Mềm (HC)  65

2. Modul cần kiểm thử  

B. Kiểm thử đơn vị cho các modul trong khối  

1. Mô tả kiểm thử cho modul m  

2. Mô tả tổng phí phần mềm  

3. Kết quả dự kiến  

C. Môi trường kiểm thử  

1. Công cụ hay kỹ thuật đặc biệt  

2. Mô tả tổng phí phần mềm  

D. Dữ liệu ca kiểm thử  

E. Kết quả dự kiến cho khối n  

IV. Kết quả kiểm thử thực tế  

V. Tham khảo  

VI. Phụ lục  

- Phạm vi kiểm thử: tổng quát các tính chất về chức năng đặc biệt, về sự thực hiện, về thiết kế nội

tại cần kiểm thử, công sức kiểm thử được giới hạn lại, tiêu chuẩn đầy đủ cho từng pha được mô tả

và ràng buộc về lịch trình được lập tài liệu  

- Kế hoạch kiểm thử: mô tả chiến lược tích hợp tổng thể; kiểm thử được chia thành các pha và các

build nhằm đến các tính chất ứng xử và các chức năng đặc biệt.  

e. Kiểm thử hệ thống  

Câ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?  

- Người phát triển thực ra không thể đoán trước được khách hàng thực sự dùng một chương trình

như thế nào  

+ Các chỉ dẫn sử dụng có thể bị hiểu lầm  

+ Các tổ hợp dữ liệu lạ có thể bị sử dụng bất kỳ  

+ Đầu ra có vẻ là rõ ràng với người kiểm thử nhưng lại khó hiểu đối với người dùng  

Đảm Bảo Chất Lượng Phần Mềm (HC)  66

- Khi phần mềm dành cho 1 người đặt hàng thì hoạt động kiểm thử chỉ được 1 khách hành tiến

hành để thẩm định mọi yêu cầu. Tiến hành kiểm thử này do 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 đặt hàng, thì kiểm thử chấp nhận bởi một khách

hàng là không thực tế. Quá trình kiểm thử Alpha và kiểm thử Beta cho nhiều người tiến hành là bắt

buộc. Chỉ có những người sử dụng đầu cuối mới có thể phát hiện được các sai cho lớp người dùng

đa dạng.  

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 (vì thế

còn gọi là kiểm thử sau lư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át triển)  

+ Dữ liệu cho kiểm thử Alpha thường là dữ liệu mô phỏng.  

Kiểm thử Beta: được nhiều người đặt hàng tiến hành, không có mặt người phát triển.

+ Áp dụng trong môi trường thực, không có sự kiểm soát của người phát triể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 trong quá trình

kiểm thử cho người phát triển một cách định kỳ.  

+ 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ản phát hành bản

hoàn thiện cho toàn bộ những người đặt hàng.  

Câ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?  

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

- 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ác tạ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  

Đảm Bảo Chất Lượng Phần Mềm (HC)  67

- 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 đích chính là thử

đầy đủ hệ thống dựa trên máy tính.  

Câu 74. 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 tả trước  

+ Có trường hợp, hệ thống cần thứ lỗi, nghĩa là việc xử lý lỗi bắt buộc không được làm ngưng hoạt

động của toàn bộ hệ thống.  

+ Trong trường hợp khác, lỗi phải được khắc phục theo từng chu kỳ được đặc tả nếu không thiệt

hại kinh tế nghiêm trọng sẽ xuất hiện.  

- Kiểm thử phục hồi là bắt buộc phần mềm phải hỏng theo nhiều cách để xem khả năng phục hồi

của nó đến đâu.  

Có 2 cách phục hồi:  

- 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). Sau

khi phục hồi dữ liệu, hệ thống tự khởi động lại thì được đánh giá là đúng đắn.  

¬- Phục hồi đòi hỏi sự can thiệp của con người: Cần đánh giá thời gian trung bình dùng để sửa

chữa trong giới hạn cho phép hay không?  

Câu 75. 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?  

- Xét tất cả các loại đột nhập có thể "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: Mọi đột nhập là có thể nếu đủ thời gian và nguồn lực.  

- Bài toán thiết kế hệ thống an ninh đặt ra là:  

+ Làm cho việc đột tốn phí nhiều hơn giá trị thu được do đột nhập  

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

Chi phí công cụ bảo về < lợi ích do bảo vệ đột nhập  

Chi phí để đột nhập > lợi ích thu được từ đột nhập  

Câu 76. Kiểm thử áp lực là gì?  

Đảm Bảo Chất Lượng Phần Mềm (HC)  68

- Các kỹ thuật kiểm thử hộp trắng và hộp đen được dùng để đánh giá chức năng và sự thi hành

của chương trình ở mức bình thường  

- Kiểm thử áp lực là vận hành hệ thống với đòi hỏi nguồn lực với số lượng, tần suất và cường độ dị

thường.  

- Chẳng hạn:  

+Kiểm thử để sinh ra 10 ngắt trong 1 giây trong khi tỉ lệ trung bình chỉ là một hoặc hai  

+ tỉ lệ dữ liệu vào có thể tăng lên theo một cấp độ lớn nào đó để xác định cách các chức năng vào

sẽ đáp ứng

+ 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: cố gắng 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 định hoặc không

chính xác.  

Câu 77. Kiểm thử thi hành là gì?  

- Với hệ nhúng và hệ thời gian thực, phần mềm cung cấp chức năng nhưng không phù hợp với các

yêu cầu thi hành đều là không chấp nhận được.  

- Kiểm thử thi hành được thiết kế để kiểm thử việc vận hành run-time của phần mềm khi hệ thống

được tích hợp.  

- Kiểm thử thi hành xuất hiện trong tất cả các bước của quá trình kiểm thử, tuy nhiên chỉ đến khi tất

cả các phần tử của hệ thống đã được tích hợp thì kiểm thử mới có thể thực sự là chắc chắn  

- Kiểm thử thi hành thường gắn liền với kiểm thử áp lực vì cả hai thường đòi hỏi các dụng cụ phần

cứng và phần mềm chuyên dụng. Vì cần đo sự tổng hợp nguồn lực (trong, ngoài) và nhờ dụng cụ

ngoại lai để có thể giám sát các khoảng vận hành, các sự kiện ngắt (log) khi nó xuất hiện, có thể

lấy mẫu các trạng thái máy.  

- 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â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ì?  

- Kết quả của kiểm thử thường mới chỉ ra lỗi và cho thấy những triệu chứng vấn đề của phần mềm.

Nguyên nhân của lỗi hay vấn đề có thể chưa rõ: biểu lộ bên ngoài của sai và nguyên nhân bên

trong của sai có thể không có quan hệ rõ ràng.  

Đảm Bảo Chất Lượng Phần Mềm (HC)  69

- Kiểm thử thành công dẫn đến việc gỡ rối. Gỡ rối không phải  khác vớilà kiểm thử mà là tìm

nguyên nhân gây lỗi để loại trừ lỗi  kiểm thử.  

- Khó khăn của gỡ rối:  

+ Triệu chứng có thể xa nguyên nhân (về không gian). Nghĩa là những triệu chứng có thể xuất hiện

trong một phần này của chương trình, trong khi nguyên nhân thực tế có thể định vị ở một vị trí xa  

+ Triệu chứng có thể tạm thời biến mất khi có một sai khác được sửa.  

+ Triệu chứng thực tế có thể bị gây ra không lỗi (như do sự không chính xác của việc làm tròn số)  

+ Triệu chứng có thể thực sự gây ra bởi sai của người dùng mà không dễ theo dõi được  

+ Triệu chứng có thể là kết quả của vấn đề thời gian chứ không phải là vấn đề xử lý.  

+ Có thể khó tái thể hiện các điều kiện đầu vào (ứng dụng thời gian thực, thứ tự đầu vào không xác

định).  

+ Triệu chứng có thể bị gián đoạn, lúc có lúc không (các hệ nhúng với liên kết phần cứng và phần

mềm không tháo rời được)  

+ Triệu chứng có thể do các nguyên nhân được phân tán trong một số các nhiệm vụ chạy trên các

bộ xử lý khác nhau.  

Câ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?  

Tiến trình gỡ rối:  

- Quá trình gỡ rối luôn dẫn tới 2 khả năng:  

+ Tìm ra nguyên nhân, chỉnh sửa và khử được lỗi.  

+ Không tìm được nguyên nhân: trường hợp này cần thiết kế một ca kiểm thử để giúp việc thẩm

định nghi ngờ và như vậy công việc tìm sai lại dẫn đến tiếp tục kiểm thử như một vòng lặp.  

Các cách thức gỡ rối:  

- Vũ dũng vô mưu:  

+ Đây là cách chung nhất, nhưng lại ít hiệu quả nhất; chỉ áp dụng phương sách này khi không còn

cách nào khác.

+ Triết lí "hãy để cho máy tính tìm ra sai": xem xét tất cả, ghi lại tất cả với hy vọng tìm ra trong đống

thông tin khổng lồ đó nguyên nhân của sai.  

+ Mặc dù cũng có thể dẫn tới thành công nhưng thường là phí công sức và thời gian, nhiều trường

hợp không khả thi  

Đảm Bảo Chất Lượng Phần Mềm (HC)  70

- Lần theo vết cũ:  

+ Cũng ít thông dụng và có thể dùng thắng lợi trong các chương trình nhỏ.  

+ Bắt đầu lần ngược từ chỗ thấy triệu chứng sai trong mã nguồn (bằng tay!) cho tới khi định vị

được sai.  

+ Khi số dòng lệnh tăng lên thì số con đường đi ngược có thể có nhiều đến mức không quản lý nổi.

- Loại trừ nguyên nhân:  

+ Cách làm: tổ chức lại dữ liệu liên quan đến xuất hiện sai để cô lập nguyên nhân tiềm ẩn.  

+ Một "giả thuyết nguyên nhân" được đặt ra từ dữ liệu trên được dùng để chứng tỏ hoặc phản

chứng giả thiết đó, một danh sách các nguyên nhân tiểm ẩn được đặt ra và các kiểm thử được tiến

hành để loại trừ các nguyên nhân trong danh sách đó.  

+ Nếu kiểm thử chỉ ra một nguyên nhân nào đó có hứa hẹn thì tinh chế dữ liệu liên quan để cô lập

lỗi.  

+ Khi đã tìm thấy lỗi thì phải chỉnh sửa. Nhưng việc sửa một lỗi có thể gây ra nhiều sai khác.  

+ Để sửa triệt để, trước khi sửa nên tự hỏi để tìm giải pháp:  

Nguyên nhân này có thể sinh ra ở phần khác của chương trình hay không (trong nhiều tình thế,

một khiếm khuyết chương trình có thể gây ra một mẫu sai logic mà nó có thể được sinh ra ở một

nơi khác).  

Lỗi nào có thể được sinh ra tiếp? Trước khi chỉnh sửa nên xét lại mã nguồn (tốt hơn hết là xét lại

thiết kế) để định giả sử gắn kết giữa logic và cấu trúc dữ liệu.  

Làm gì để ngăn cản lỗi này ngay chỗ đầu tiên? (thường có nhiều giải pháp để nhà thiết kế lựa

chọn)  

f. Quản lý cấu hình  

Câ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ì?  

Quản lý cấu hình phần mềm:  

+ Là tập các hoạt động để quản lý các thay đổi trong suốt vòng đời phần mềm  

+ Là một hoạt động đảm bảo chất lượng phần mềm, được áp dụng cho tất cả các pha của kỹ nghệ.

+ Bao trùm suốt tiến trình phát triển và tiến hoá của phần mềm.  

Đảm Bảo Chất Lượng Phần Mềm (HC)  71

Nội dung của hoạt động quản lý cấu hình phần mềm:  

+ Xác định các thay đổi  

+ Kiểm soát các thay đổi  

+ Đảm bảo các thay đổi đã được thực hiện  

+ Báo cáo các thay đổi cho người quan tâm.  

Quản lý cấu hình khác bảo trì phần mềm:  

- Bảo trì phần mềm là các hoạt động kỹ nghệ xuất hiện sau khi phân phối phần mềm và nó đi vào

hoạt động.  

- Quản lý cấu hình phần mềm là các hoạt động theo dõi và kiểm soát, từ bắt đầu dự án phát triển

phần mềm và chỉ kết thúc khi mà phần mềm không hoạt động nữa.  

Câ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ì?  

- 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)  

+ 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 lên các thành phần của phần mềm được tạo ra như là những chế tác

(artifact) của tiến trình kỹ nghệ phần mềm được tập hợp lại trong một cái tên chung gọi là CẤU

HÌNH PHẦN MỀM.  

- Các chế tác này có nhiều mức khác nhau:  

+ Bộ phận - tổng thể (phạm vi)  

+ Chưa hoàn thiện - hoàn thiện (theo tiến trình, chất lượng)

+ Ở các mức tiến hoá khác nhau (các phiên bản - version)  

Các khoản mục cấu hình phần mềm (Software configuration items - SCI)  

 Đặc tả hệ thống (system specification)  

 Kế hoạch dự án phần mềm (project baseline)  

Đảm Bảo Chất Lượng Phần Mềm (HC)  72

 Đặc tả yêu cầu (software requiements)  

 Đặc tả yêu cầu phần mềm  

 Nguyên mẫu thi hành được hoặc nguyên mẫu "giấy tờ"  

 Sổ tay sử dụng sơ đẳng  

 Các đặc tả thiết kế (design specification):  

 Dữ liệu (data design)  

 Kiến trúc (architectural design)  

 Modul (modul design)  

 Giao diện (interface design)  

 Đối tượng (object design - nếu dùng kĩ thuật hướng đối tượng)  

 Mã nguồn (source code) và kiểm thử (test)  

 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  

 Sổ tay người sử dụng  

 Các tài liệu bảo trì  

 Các báo cáo những vấn đề phần mềm  

 Các yêu cầu bảo trì  

Đảm Bảo Chất Lượng Phần Mềm (HC)  73

 Đặt thay đổi kỹ nghệ  

 Các chuẩn và các thủ tục cho kỹ nghệ phần mềm  

Câ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ì?  

- 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:  

+ Xác định các khoản mục cấu hình, các version của phần mềm.  

+ 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à  

+ 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 phần mềm:  

 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  

 Báo cáo thay đổi  

Câ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?  

- Phương pháp hướng đối tượng áp dụng cho việc quản lý cấu hình.  

- Đường mốc giới (baseline) là khái niệm được đặt ra:  

+ Trước mốc giới, cấu hình có thể thay đổi nhanh chóng và không chính thức.  

+ Sau mốc giới, cần các thủ tục đặc biệt và chính thức để có thể đánh giá và kiểm soát sự thay đổi

cấu hình  

- Đường mốc giới để đánh dấu việc cập nhật hay 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 lần đầu được đưa vào cơ sở dữ liệu dự

án hay được lấy ra sửa đổi và được cập nhật trở lại.  

Câu 84. Trình bày tiến trình kiểm soát sự thay đổi?  

Đảm Bảo Chất Lượng Phần Mềm (HC)  74

Biểu đồ tiến trình kiểm soát sự thay đổi

 - Khi một yêu cầu thay đổi được đệ trình cần định giá trị nhằm: sử dụng kĩ thuật thích hợp; hiệu

ứng phụ có thể có, ảnh hưởng lên tổng thể các đối tượng cấu hình khác và lên các chức năng hệ

thống và lên chi phí sự án vì thay đổi đó...  

- Kết quả đánh giá về sự đổi thay được báo cáo cho người có thẩm quyền kiểm soát đổi thay

(change control authority - CCA), có quyền tối hậu về tình trạng & quyết định đổi thay.  

- Mệnh lệnh kĩ nghệ thay đổi (ECO) được tạo ra cho từng thay đổi được chấp thuận. Lệnh này

được mô tả các thay đổi cần tìm, các ràng buộc phải tuân theo, các tiêu chuẩn rà soát và kiểm

toán.  

- Đối tượng cần thay đổi được "check out" khỏi cơ sở dữ liệu dự án, được thay đổi, và các hoạt

động đảm bảo chất lượng phần mềm cần được áp dụng.  

- Sau đó, đối tượng này được "check in" vào cơ sở dữ liệu & một cơ chế kiểm soát phiên bản được

sử dụng.

- Quá trình "check in" và "check out" thực thi hai điều quan trọng của kiểm soát đổi thay là: kiểm

soát truy cập và kiểm soát đồng bộ.  

- Một bản sao của đối tượng đường mốc được cải biên. Sau việc đảm bảo chất lượng phần mềm

và kiểm thử hoàn âtts, phiên bản đã được cải biên của đối tượng đó được "check in", cả đối tượng

và mốc giới này được mở khoá.  

- Đường mốc được tạo ra khi đối tượng đó đã được rà soát kĩ thuật chính thức & đã được chấp

thuận.  

- Sau đó, kiểm soát thay đổi mức dự án được thực thi.  

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?  

- 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ặc nhiề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ác nhau

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

- Quản lý cấu hình cho phép người sử dụng đặc tả các cấu hình thay thế của hệ thống phần mềm =

lựa chọn các phiên bản thích hợp và gắn kết với các thuộc tính; nhờ đó mà cho phép đặc tả một

cấu hình bằng mô tả tập các thuộc tính mong muốn.  

- Để xây dựng một biến thế thích hợp của một phiên bản của một chương trình, mỗi thành phần

của phiên bản được gán một "bộ thuộc tính" - là một danh sách các đặc trưng.  

- Một phiên bản hay biến thể được xây dựng cần xác định thành phần nào được dùng hay cần thay

đổi.  

Đảm Bảo Chất Lượng Phần Mềm (HC)  75

- Một các cách khác để hình thành khái niệm về quan hệ giữa các thành phần, các biến thể, các

phiên bản là biểu diễn chúng như một pool đối tượng.  

- Mỗi thành phần được cấu tạo bởi một bộ các đối tượng trong cùng một mức xét duyệt. Mỗi biến

thể là một bộ các dối tượng trong cùng một mức xét duyệt. Xác định khi các thay đổi mỗi phiên bản

chủ yếu đã được thực hiện đối với một vài đối tượng.  

Câ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ì?  

- Kiểm toán cấu hình (configuration review) là một nhân tố quan trọng của quá trình thẩm định, rà

soát này đảm bảo rằng các yếu tố của cấu hình phần mềm đã thực sự được phát triển, lập danh

mục, và có các chi tiết cần thiết để trợ giúp pha bảo trì của vòng đời phần mềm.  

+ 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 đánh giá 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ời nhữ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 hay chư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 để giám sát đổi thay đó, ghi lại và 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 liên quan đã thực sự được cập nhật chưa?  

Câ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áo hiện trang dành cho ai? Mục tiêu của nó là gì?  

- Khái niệm báo cáo hiện trạng cấu hình:  

Báo cáo hiện trạng cấu hình (configuration status reporting - CSR) còn gọi là kiểm toán hiện trạng

là một nhiệm vụ quản lý cấu hình phần mềm, nó trả lời các câu hỏi sau:

Cái  gì  đã  xảy  ra?  Ai  làm?  Xảy  ra  khi  nào?  Sẽ  còn  ảnh  hưởng  nào  khác  nữa? 

+  Thông  tin  báo  cáo  trình  trạng  cấu  hình  gắn  chặt  với  các  nhiệm  vụ  trong  kiểm  toán  đổi  thay. 

-   Đầu ra của báo cáo hiện trạng cấu hình có thể được đặt trên một cơ sở dữ liệu trực tuyến sao cho những

người  phát  triển  phần  mềm  hay  những  người  bảo  trì  có  thể  truy  cập  các  thông  tin  thay  đổi. 

-   Báo cáo hiện trạng cấu hình đóng vai trò cốt tử cho thắng lợi của một dự án phát triển phần mềm lớn. 

-   Mục tiêu: Mục tiêu của nó là giúp ta loại trừ vấn đề bất cập liên quan nhiều người bằng cách cải thiện

giao  tiếp  giữa  họ. 

Đảm Bảo Chất Lượng Phần Mềm (HC)  76

-  Vấn  đề  bất  cập: 

+   Xây  dựng  phần  mềm  cho  một  đặc  tả  phần  cứng  đã  không  dùng  nữa. 

+   Tiến  hành  một  thay  đổi  đề  xuất  mà  nó  đã  được  thực  hiện. 

+   Sử  dụng  1  thành  phần  đang  sửa  đổi  có  lỗi. 

+   Cải biên cùng một khoản mục cấu hình với những ý định khác nhau, thậm chí là mâu thuẫn nhau.