Đề cương kiểm thử phần mềm

Thực hiện quátrình đảm bảo chất lượng phần mềm sẽ giúp công ty tiết kiệm được nguồn lực chi phí cho quá trình phát triển, đồng thời thu được sản phẩm đúng đắn, thỏa mãn được các yêu cầu

Test and Maintenance – Thạc Bình Cường

Tổng hợp các câu hỏi

1 Chất lượng của một sản phẩm được sản xuất là gì ? Đối với phần mềm, định nghĩa đó có đúng

không ? Làm thế nào để áp dụng định nghĩa đó? 4

Câu 2 Cái gì được làm cơ sở để kiểm định chất lượng phần mềm? 4

Câu 3 Để làm cơ sở cho việc kiểm định chất lượng, đặc tả phần mềm cần thỏa mãn điều kiện gì? Nêu một vài ví dụ về điều kiện đưa ra ? 4

4 Các nhân tố ảnh hưởng đế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 ? 4

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ố ? 5

6 Có thể đo được 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 ? 6

7 Các độ đo đặc trưng chất lượng chính của McCall và giải thích nội dung của nó ? 6

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 đó 6

9 Các đặc trưng chất lượng theo Hawlett + giải thích nội dung: 7

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

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

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

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ò trách nhiệm của từng đối tượng? 9

Câu 14 : Mục tiêu của SQA là gì? Các hoạt động đảm bảo chất lượng phần mềm là những hoạt động nào? 9

Câu 15 : Giải thích tóm tắt các hoạt động đảm bảo chất lượng phần mềm ? 10

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

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 rà soát? Nếu không thực hiện rà soát thì sao? 11

Câu 17 Các hình thức của hoạt động rà soát: 11

Câu 18 Sơ đồ tiến trình rà soát: 12

18 Vẽ sơ đồ tiến trình của hoạt động rà soát và giải thích sơ bộ nội dung của mỗi bước 12

Câu 19: Trình bày nội dung 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 ? 13

19 Nội dung cơ bản của một cuộc họp rà soát: Thành phần, thời gian, công việc cần làm, phương châm 14

Câu 20: Các sản phẩm của cuộc họp rà soát là gì? Nội dung, vài trò của mỗi sản phẩm đó? 14

20 Các sản phẩm của cuộc họp rà soát? Vai trò của các sản phẩm này 15

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

Câu 22.Các danh mục rà soát : 16

23 Nêu các ký hiệu và giải ghích nội dung, ý nghĩa các đại lượng: s1…s7, và các độ đo trung gian? .16

24 Sử dụng công thức wiD ivới wi như thế nào và để làm gì 17

25 Giải thích nội dung các thành phần và ý nghĩa của độ đo SMI và cách sử dụng nó? 17

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

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ể ra ít nhất 5 nguyên nhân của những khiếm khuyết trong phần mềm? 18

Câu 28: Nêu công thức tính khiếm khuyết của 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ó? 18

Câu 29: Quá trình phòng sạch là gì? Phương châm của kỹ thuật này là gì? 19

30 Độ tin cậy của phần mềm hiểu là cái gì? Đo độ tin cậy dựa trên những dữ liệu nào? 20

Nhóm 2.4 21

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

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 chúng? 21

Nhóm 3.2 23

37 Tại sao phải kiểm thử phần mềm? Mục tiêu kiểm thử là gì? Từ đó có những quan niệm sai gì về kiểm thử phần mềm? 24

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

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

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

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

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 mỗi bước? 30

46 Có những loại công cụ tự động nào trợ giúp kiểm thử? Mô tả nội dung mỗi loại? 31

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?31 48 Kiểm thử hộp trắng dựa trên cơ sở nào để thiết kế các ca kiểm thử? Thiết kế ca kiểm thử phải đảm bảo điều kiện gì? 32

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ác đặc trưng gì? Đồ thị dòng dùng để làm gì? 32

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

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

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

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ì? 34

54 Chiến lược kiểm thử miền là gì? Nó dựa trên tư tưởng nào? 35

55 Chiến lược kiẻm thử BRO là gì? Nó dựa trên tư tưởng nào? 35

56 Lấy ví dụ về các đièu kiện “ràng buộc ra” cho các trườg hợp: 1 biến Boolean, hợp của biến Boolean và thức quan hệ, hợp của 2 biểu thức quan hệ? 36

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

58k48 Kiểm thử điều khiển vòng lặp nghĩa là gì? cho ví dụ 37

58k47 Kiểm thử điều khiển vòng lặp nghĩa là gì? cho ví dụ 39

Câu 59)K48 Mô hình của kiểm thử hộp đen quan tâm đến 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ó? 39

59K47 Mô hình của kiểm thử hộp đen quan tâm đến 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ó? 40

60K47 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 pháp xác định lớp tương đương là gì? 41

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

Kế hoạch kiểm thử unit 46

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? Nêu một số câu hỏi đặt ra cho kiểm thử tích hợp? 46

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? 47 Câu 69k48 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? 47

69k47 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? 48

Câu 70k48 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? 48

70k47 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 49

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

72 Kiểm thử Beta là gì ? Kiểm thừ Alpha là gì ? Nêu sự giống và khác nhau cơ bản giữa chúng ? 50 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 ? 50

74 Kiểm thử phục hồi là gì ? 50

75 Kiểm thử an ninh ( mức độ an toàn của hệ thống ) là gì ? 51

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ì? 51

Câu 79K48 Trình bày tiến trình gỡ rối? Các cách thức gỡ rối? Ưu nhược điểm của chúng? 52

Câu 80 : Quản lý cấu hình phần mềm là gi? Nội dung của hoạt động quản lý cấu hình gồm những công việc gì? 53

Câu 81K48 :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 của cấu hình phần gồm những gì? 55

81K47 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 của cấu hình phần mềm gồm những gì? 55

Câu 82K48 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ì? 56

82K47 Quản lý cấu hình nhằm mục tiêu gì? 5 nhiệm vụ của quản lý cấu hình là gì? 58

Câu 83K48 Phương pháp gì được áp dụng cho việc quản lý cấu hình ? Mốc giới là cái gì ? Sử dụng mốc giới để kiểm soát sự thay đổi như thế nào ? 58

83K47 Phương pháp gì được áp dụng cho việc quản lý cấu hình Mốc giới là gì? Sử dụng mốc giới để kiểm soát sự thay đổi như thế nào 58

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

85 Phiên bản là gì ? Làm thế nào để kiểm soát các phiên bản ? 60

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 cho cầu hỏi gì ? 60

87 Báo cáo hiện trạng 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 trạng dành cho ai ? Mục tiêu của nó là gì? 61

1 Chất lượng của một sản phẩm được sản xuất là gì ? Đối với phần mềm, định nghĩa

đó có đúng không ? Làm thế nào để áp dụng định nghĩa đó?

Chất lượng đơn giản là sản phẩm phải đúng theo thiết kế

Từ định nghĩa ta thấy có hai yếu tố của chất lượng là:

- Chất lượng thiết kế: là những đặc điểm nhà thiết kế gán cho sản phẩm

- Chất lượng sản xuất: là mức độ tuân thủ đặc tả thiết kế khi sản xuất sản phẩm

Theo Pressman thì chất lượng phần mềm: “Conformance to explicitly stated functional and performance requirements, explicitly documented development standards, and implicit characteristics that are expected of all professionally developed software ”

Từ định nghĩa trên có 3 điểm quan trọng:

- yêu cầu phần mềm là nền tảng để đo chất lượng Thiếu sót về yêu cầu  thiếu sót về chất lượng

- một chuẩn xác định qui định các tiêu chí về cách mà phần mềm được sản xuất thiếu sót các tiêu chí đó dẫn đến thiếu sót về chất lượng

- tập các yêu cầu không bắt buộc thường không được để ý(maintainability…), nếu phấn mềm thỏa mãn các yêu cầu bắt buộc nhưng không thỏa mãn đây đủ các yêu cầu không băt buộc thìchất lượng của phần mềm là không biết trước

Vậy để đảm bảo chất lượng phần mềm thì đặc tả, qui trình sản xuất phải rõ ràng, đầy đủ và phải được tuân thủ chặt chẽ

Câu 2 Cái gì được làm cơ sở để kiểm định chất lượng phần mềm?

Từ định nghĩa của Pressman về chất lượng phần mềm ta thấy cơ sở để kiểm định chất lượng phần mềm gồm:

- các đặc tả phần mềm về yêu cầu: bao gồm cả yêu cầu bắt buộc(chức năng) và yêu cầu không bắt buộc(phi chức năng): SRS

- các chuẩn xây dựng phần mềm được áp dụng: các kiến trúc phần mềm, quy cách lập trình, chuẩn về tính tiện dụng, hiệu quả

Câu 3 Để làm cơ sở cho việc kiểm định chất lượng, đặc tả phần mềm cần thỏa mãn điều kiện gì? Nêu một vài ví dụ về điều kiện đưa ra ?

Để đảm bảo chất lượng phần mềm đặc tả phần mềm phải:

- correct(chính xác)

- unambiguous(không nhập nhằng)

- complete(đầy đủ)

- consistent (nhất quán)

- rank for importance and stability(các yêu cầu được xếp hạng theo độ quan trọng và ổn định)

- verifiable: có thể kiểm chứng được

- modifiable: có thể sửa được

- traceable: có thể theo dõi được

Functionality: mức độ thỏa mãn của phần mềm với những yêu cầu được đặt ra, bao bồm các thuộc

tính con: đồng bộ, chính xác, liên tác, tương thích, bảo mật

Reliability: tính bằng thời gian phần mềm sẵn sàng để phục vụ; gồm các thuộc tính: đúng đăn, khả

năng chịu lỗi, khả năng phục hồi

Usability: mức độ dễ dùng của phần mềm, gồm: dễ học, dễ hiểu, dễ thao tác

Efficency: là mức độ phần mềm tối ưu hóa tài nguyên; gồm: thời gian đáp ứng, quản lý tài nguyên Maintainability: mức độ dễ dàng khi sửa phần mềm, gồm: khả năng phần tích được, khả năng sửa

đổi được, khả năng kiểm thử được, độ ổn định

Portability: mức độ dễ dàng khi chuyển phần mềm sang một môi trường mới; gồm: khả năng thích

nghi, khả năng cài đặt, khả năng thay thế

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

xem câu 7

Functionality

 Phù hợp

 Đúng đắn

 Liên kết tốt giữa con người, dữ liệu và hệ thống

 Làm đúng theo yêu cầu

 Tính bảo mật

Reliability

 Xử lý tin cậy

 Khả năng khôi phục dữ liệu

 khả năng tìm lỗi, báo lỗi

Usability

 Dễ học thuộc, dễ hiểu, dễ thành thạo, dễ sử dụng

Efficency

 Quản lý thời gian

 Quản lý nguồn tài nguyên

Maintainability

 Chạy ổn định

 Có khả năng phân tích dữ liệu

 Có khả năng thay đổi phù hợp

 Có khả năng kiểm tra

Portability

 Khả năng cài đặt

 Khả năng thay thế, cập nhật và nâng cấp

 Khả năng thích hợp với nhiều cấu hình máy tính

(Theo ISO 9126 )

6 Có thể đo được 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 ?

Thường là khó, có nhiều trường hợp là không thể đo được chất lượng phần mềm một cách trực tiếp

từ các nhân tố chất lượng Để giải quyết vấn đề này người ta đã xây dựng lên các độ đo và các phương pháp đo chất lượng phần mềm Khi đó chất lượng phần mềm sẽ có dạng như sau:

F q = c1 _ m1 + c2 _ m2 + + c n _ m n

Trong đó Fq: là một nhân tố chất lượng phần mềm, c i là các hệ trọng số, m i là các độ đo trên nhân tố đó

7 Các độ đo đặc trưng chất lượng chính của McCall và giải thích nội dung của nó ?

MacCall, Richard và Walters nhóm các nhân tố thành nhóm tập trung vòa 3 khía cạnh của phần mềm:

- các đặc tính về hoạt động(Product Operational)

- khả năng thích nghi với các thay đổi(Product revision)

- khả năng thích nghi với môi trường mới(Product transition)

Usability: số lượng tài nguyên và code cần thiết để chương trình hiện chức năng của mình

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

a Giải thích nội dung các thuộc tính chất lượng phần mềm:

- Tính đúng đắn (Correctness): Là mức mà chương trình thỏa mãn được đặc tả của mình và hoàn thành được những mục tiêu nhiệm vụ của khách hàng

- Tính tin cậy được (Reliability): Là mức mà chương trình có thể đáp ứng được những chức năng mong đợi với một độ chính xác cho trước

- Tính hiệu quả (Efficiency): Là lượng tài nguyên và mã nguồn cần thiết được sử dụng bởi chương trình để thực hiện một chức năng nào đó

- Tính toàn vẹn (Integrity): Là mức mà phần mềm và dữ liệu bị điều khiển bởi những người dùng bất hợp pháp

- Tính khả dụng (Usability): Là công sức cần thiết bỏ ra để học, thao tác, chuẩn bị đầu vào,

và hiểu được đầu ra của chương trình

-Tính bảo trì được (Maintainability): Là công sức cần thiết bỏ ra để định vị và sửa lỗi của chương trình

- Tính mềm dẻo (Flexibility): Là công sức cần thiết bỏ ra để chỉnh sửa một thao tác chương trình

- Tính thử nghiệm được (Testability): Là công sức cần thiết bỏ ra để kiểm thử chương trình

và chắc chắn rằng chương trình thực hiện được những chức năng mong đợi

- Tính khả chuyển (Portability): Là công sức cần thiết bỏ ra để chuyển chương trình từ một môi trường phần cứng và/hay hệ thống phần mềm sang môi trường khác

- Tính liên tác được (Interoperability): Là công sức cần thiết bỏ ra để liên kết với một hệ thống khác

- Tính sử dụng lại được (Reusability): Là mức mà chương trình (hay các phần của chương trình) được sử dụng lại trong các ứng dụng khác (đề bài không hỏi, nêu ra cho đủ thôi)

b Các độ đo liên quan được sử dụng để đo thuộc tính, xem bảng dưới:

(giải thích chi tiết độ đo ở Câu 7)

(nguồn: p510, 511 SE Pressman)

9 Các đặc trưng chất lượng theo Hawlett + giải thích nội dung:

- Chức năng (Functionality): được ước lượng bằng cách đánh giá tập các đặc trưng và khả năng của chương trình; mà nhìn chung là các chức năng đã được đưa ra, cộng với sự an toàn của toàn bộ

hệ thống

- Tính khả dụng (Usability): được ước lượng bởi yếu tố con người, bao gồm toàn bộ: tính thẩm

mĩ (aesthetic), tính nhất quán (consistency), và tài liệu

- Tính tin cậy được (Reliability): đươc ước lượng bằng cách tính toán tần suất và sự thiệt hại khi

có sự cố, sự chính xác của kết quả đầu ra, thời gian trung bình xảy ra sự cố (MTTF – Mean Time To Failure), khả năng khôi phục sau sự cố, và khả năng dự đoán (predictability) của chương trình

- Hiệu năng (Performance): được đo bởi tốc độ xử lý, thời gian phản hồi, lượng tài nguyên sử dụng, thông lượng và tính hiệu quả

- Tính hỗ trợ (Supportability): là sự kết hợp khả năng mở rộng chương trình, khả năng thích nghi, khả năng phục vụ - là 3 thuộc tính chung nhất, thêm vào đó, là tính bảo trì được, tính kiểm thử

được, khả năng tích hợp được, khả năng cấu hình được, rằng buộc khi hệ thống được cài đặt, và rằng buộc khi vấn đề được cục bộ hóa

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?

- Đảm bảo chất lượng phần mềm cùng với các chức năng điều khiển lần đầu tiên được giới thiệu tại Bell Labs vào năm 1916

- Trong những năm từ 1950 đến 1960s, những người lập trình chủ động kiểm soát chất lượngcủa phần mềm họ viết ra

- Tới năm 1970, các chuẩn về đảm bảo chất lượng phần mềm được giới thiệu lần đầu tiên trong quân đội theo thỏa thuận về phát triển phần mềm

- Vào năm 1987, định nghĩa rộng được đưa ra trong [SCH87] ( Lạy chúa ko hiểu SCH87 là cái gì ??? hình như do ông Schneider phịa ra)

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?

Trả lời :

Phát triển phần mềm là một qúa trình phức tạp đầy rủi ro Có những rủi ro về kỹ thuật như phần mềm hoạt động không như mong đợi, hay quá phức tạp để thao tác, chỉnh sửa hay bảo trì; có những rủi ro về phạm vi như vượt qúa chi phí và thời gian đã định trước Mục đích của SQA là giảm thiểu những rủi ro đó :

- Kiểm tra quá trình phát triển phần mềm có phù hợp với phần mềm cần xây dựng không

- Đảm bảo việc phát triển là đúng đắn với các chuẩn (Standards)và các thủ tục

(Procedures) đã lựa chọn và đề ra

- Đảm bảo rằng các thiếu xót về sản xuất, về quá trình phát triển, về các tiêu chuẩn đều được phát hiện và sửa đổi cho phù hợp

Việc đảm bảo chất lượng phần mềm là công việc rất quan trọng trong các pha của quá trình phát triển phần mềm Đó là cơ sở để đi đến 1 sản phẩm đúng đắn, thỏa mãn được các yêu cầu bà mong muôn khi phát triển phần mềm

Đối với mỗi doanh nghiệp phát triển phần mềm, việc đảm bảo chất lượng là công việc không thể thiếu nếu doanh nghiệp đó muốn phát triển đúng hướng, thu hút được khách hàng Thực hiện quátrình đảm bảo chất lượng phần mềm sẽ giúp công ty tiết kiệm được nguồn lực chi phí cho quá trình phát triển, đồng thời thu được sản phẩm đúng đắn, thỏa mãn được các yêu cầu của khách hàng Để việc đảm bảo chất lượng là đúng đắn và phù hợp công ty nên theo đuổi và làm theo cácchuẩn về Đảm bảo chất lượng phần mềm

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?

Với mỗi giai đoạn trong quá trình phát triển của dự án có những hoạt động đảm bảo chất lượngphần mềm khác nhau dựa trên những tiêu chuẩn và yêu cầu khác nhau, nhằm có những điều chỉnhcần thiết để dự án đạt được chất lượng cao nhất

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ò trách nhiệm của từng đối tượng?

Trả lời : (Ở đây mình nghĩ câu hỏi nói về hoạt động đảm bảo chất lượng phần mềm trong một tổ

chức làm phần mềm :D)

Trong quá trình sản xuất phần mềm, việc đảm bảo chất lượng phần mềm được tiến hành và triểnkhai theo suốt tất cả các giai đoạn trong vòng đời phát triển phần mềm, từ giai đoạn xác định yêu cầuđến khi triển khai và kiểm thử Và những người tham gia xây dựng phần mềm đều phải tham gia vàohoạt động đảm bảo chất lượng cho phần mềm Đó là :

 Phân tích viên : Đảm nhận vai trò xác minh và phân tích yêu cầu của người dùng Việc xácđịnh yêu cầu chính xác đảm bảo cho phần mềm đáp ứng được yêu cầu của khách hàng

 Thiết kế viên : chuyển các yêu cầu đã được phân tích thành thiết kế cho hệ thống, đưa ra kiếntrúc vững chắc cho phần mềm, thiết kế phù hợp với môi trường lập trình và phát triển saunày Công việc thiết kế sẽ chi tiết hóa các yêu cầu khách hàng thành các chức năng của phầnmềm Nếu thiết kế sai hoặc thiếu có thể phải trả giá đắt khi triển khai và có thể dẫn tới đổ vỡ

 Lập trình viên : Xây dựng và phát triển phần mềm đáp ứng các yêu cầu và tiêu chuẩn đã xácđịnh Lập trình tốt sẽ tránh các lỗi cơ bản, các lỗi phát sinh khi triển khai và chất lượng phầnmềm tăng lên

 Tester : xác định rằng mọi yêu cầu được đáp ứng và thực hiện đúng đắn, xác định được cáclỗi và xử lý trước khi triển khai Đây có lẽ là người có vai trò quan trọng nhất trong công tácđảm bảo chất lượng phần mềm Nếu tester yếu kém, thiếu trình độ sẽ dẫn tới một dự án thấtbại ngay khi triển khai Trên thực tế, việc kiểm thử được lồng vào các giai đoạn phát triểncủa phần mềm để tăng độ chính xác và chất lượng cho phần mềm

Câu 14 : Mục tiêu của SQA là gì? Các hoạt động đảm bảo chất lượng phần mềm là những hoạt động nào?

Trả lời

Mục tiêu của SQA(Software Quality Assurance) :

(Nguồn : http://www2.umassd.edu/swpi/sei/tr25f/tr25_l2e.html)

 SQA giúp thực hiện các công việc có kế hoạch

 Đảm bảo sản phẩm phần mềm đáp ứng được các tiêu chuẩn, các yêu cầu và chất lượng theomong muốn

 Giúp cho các nhóm và các cá nhân nắm vững được các hoạt động đảm bảo chất lượng phầnmềm và có kết quả tốt

 Các vấn đề vướng mắc mà không thể giải quyết trong dự án phần mềm được đưa ra cho cácnhà quản lý thẩm quyền(tránh tình trạng không làm được mà vẫn nhận)

Các hoạt động :

1 Activity 1 A SQA plan is prepared for the software project according to a documentedprocedure

Một kế hoạch SQA được đề ra cho dự án phần mềm

2 Activity 2 The SQA group's activities are performed in accordance with the SQA plan

Các hoạt động của nhóm SQA được thực hiện theo kế hoạch SQA đã đề ra

3 Activity 3 The SQA group participates in the preparation and review of the project's softwaredevelopment plan, standards, and procedures

Nhóm SQA tham gia vào việc chuẩn bị và tổng quát về kế hoạch phát triển phần mềm, các tiêuchuẩn và các thủ tục cần thiết

4 Activity 4 The SQA group reviews the software engineering activities to verify compliance.Nhóm SQA xem xét các hoạt đông kỹ nghệ phần mềm để đạt được mục đích như mong muốn

5 Activity 5 The SQA group audits designated software work products to verify compliance.Nhóm SQA kiểm tra công việc thiết kế để đạt được các yêu cầu đã đề ra

6 Activity 6 The SQA group periodically reports the results of its activities to the softwareengineering group

Nhóm SQA báo cáo các kết quả định kỳ về hoạt động xây dựng phần mềm

7 Activity 7 Deviations identified in the software activities and software work products aredocumented and handled according to a documented procedure

Xác định các hành động không phù hợp trong các thủ tục và công việc xây dựng phần mềm theo cáctài liệu đặc tả

8 Activity 8 :

Tiến hành kiểm thử trong các giai đoạn của vòng đời phát triển phần mềm Cụ thể từ giai đoạn xácđịnh yêu cầu người dùng đến triển khai, kiểm thử và bảo trì(Các bạn tự trình bày phần này vì ai cũngnắm được cả rồi_câu 13)

Câu 15 : Giải thích tóm tắt các hoạt động đảm bảo chất lượng phần mềm ?

(Trình bày mở rộng các ý của câu 14)

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 The test process: Mô tả các pha quan trọng nhất của tiến trình kiểm thử.

2 Requirements traceability: Kiểm thử nên được vạch kế hoạch để tất cả các yêu cầu được

kiểm thử riêng lẻ

3 Tested items: Xác định trước các thành phần phần mềm cần được test.

4 Testing schedule: Một danh mục kiểm thử và tài nguyên xác định cho danh mục này.

5 Test recording procedures: Hệ thống lại kết quả kiểm thử.

6 Hardware and software requirements: Các công cụ phần mềm yêu cầu và ước lượng phần

cứng cần dùng

7 Constraints: Thúc ép để đạt được tiến trình kiểm thử, ví dụ khi lường trước được việc thiếu

số lượng ở vị trí này

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 rà soát? Nếu không thực hiện rà soát thì sao?

Trả lời:

1 Rà soát phần mềm (Software inspections):

a Khái niệm: Rà soát phần mềm là công việc khảo sát phần mềm với mục đích là phát hiện

ra các điều không bình thường (anomalies) và các khuyết điểm (defects) của phần mềm

so với đặc tả của nó Rà soát không yêu cầu việc thực thi một hệ thống, vì thế có thể được

sử dụng trước khi cài đặt

b Mục tiêu: Phát hiện ra các điều không bình thường và các khuyết điểm của phần mềm so

với nguồn mô tả

c Các thức áp dụng: Có thể áp dụng cho mọi mô tả của hệ thống (requirements, design,

configuration data, test data, …) Các thủ tục của nó bao gồm:

 Tổng quan hệ thống được mô tả cho đội rà soát

 Mã và các tài liệu kết hợp được phân phát tới đội rà soát

 Rà soát tại các điểm, phát hiện ra lỗi và ghi lại

 Các sửa đổi được thực hiện để sửa chữa các lỗi được phát hiện

 Rà soát lại có thể cần hoặc không sau đó

2 Lợi ích của việc rà soát: Thống nhất giữa các công việc và tài liệu mô tả các công việc đó

(requirements, design, configuration data, …) Và giúp cho các lỗi tiềm ẩn được phát hiện sớmhơn trước khi thực hiện phần mềm

3 Nếu không thực hiện rà soát thì: Các lỗi tiềm tàng là không được phát hiện sớm Việc xa rời tài

liệu đặc tả là không thể tránh khỏi khi đi vào cài đặt cụ thể Có thể dẫn tới chệch hướng phầnmềm

Câu 17 Các hình thức của hoạt động rà soát:

-Technical Review:

-Software (Fagan) Inspection, Structured Walkthrough (Yourdon):

-Audit

Rà soát kỹ thuật hình thức(FTR hoặc walkthrough hoặc một inspection)

Rà soát kỹ thuật hình thức:(FORMAL TECHNICAL REVIEWS(FTR))

[Software Engineering, Practicer’s Approarch, 8.5]

Rà soát kỹ thuật hình thức là một hoạt động đảm bảo chất lượng phần mềm do các kỹ sư phần mềm (và người khác) thực hiện

- để đảm bảo rằng phần mềm được miêu tả theo các chuẩn định nghĩa từ trước;

- để có được phần mềm được phát triển theo một cách nhất quán;

- để làm cho các dự án dễ quản lý hơn

Câu 18 Sơ đồ tiến trình rà soát:

11

Lập kế hoạch

Chuẩn bị Họp rà

Sản phẩm

Giai đoạn rà soát Mô tả

Lập kế hoạch Xác định sản phẩm làm ra được rà soát và lập lịch rà soát

Xem tổng thể Pha tùy chọn, các thành viên trong đội không quen với sản phẩm

làm ra được rà soát sự định hướng

Chuẩn bị Các thành viên rà soát công việc tìm kiếm một cách riêng biệt

những thiếu sót trong sản phẩm làm ra

Họp rà soát Các thành viên gặp mặt để thảo luận những thiếu sót trong sản

phẩm làm ra

Soạn lại Sản phẩm làm ra được sửa lại phù hợp yêu cầu và đặc tả

Theo sát Soạn lại được thẩm định, xác minh, dữ liệu rà soát cuối cùng được

tập hợp và tổng kết, và việc rà soát chính thức khép lại

18 Vẽ sơ đồ tiến trình của hoạt động rà soát và giải thích sơ bộ nội dung của mỗi bước.

 Planning: Xác định các công việc sẽ được rà soát và lên kế hoạch rà soát: bao gồm những

người tham gia vào đội rà soát (thường gồm người điều hành, tác giả, và một vài nhân viên),

và thời gian địa điểm cuộc họp Bước này cũng xem xét tất cả các thành viên của đội, nếu ai

đó chưa biết về công việc thì phải được overview

 Overview: Bước này có thể có hoặc không trong quá trình rà soát, dành cho các thành viên

của nhóm đang còn lạ với các công việc được rà soát có thời gian để định hướng các công việc được rà soát

 Individual Preparation: Các thành viên làm việc độc lập nhằm tìm ra các khiếm khuyết của

sản phẩm

 Inspection meeting: Các thành viên thảo luận về các khiếm khuyến của sản phẩm đã được

tìm ra

 Rework: Sản phẩm sẽ được sửa lại để thỏa mãn các yêu cầu và đặc tả.

 Follow-up: Sản phẩm sau khi được sửa lại sẽ được kiểm chứng, kết quả rà soát cuối cùng sẽ

được tập hợp và tổng kết lại Quá trình kiểm duyệt kết thúc

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 ?

Cuộc họp rà soát nhằm mục đích phát hiện ra các thiếu sót của sản phẩm dựa trên việc lắng nghetài liệu sản phẩm, thảo luận về thiếu sót và ghi nhận thiếu sót đó

Các thành phần tham gia gồm:

o Đội rà soát (inspection team)

 Lắng nghe reader để phát hiện ra các thiếu sót

 Thảo luận để xác định xem đó có phải đúng là thiếu sót không

o Tác giả sản phẩm (author)

 Lắng nghe và ghi chép những thiếu xót để sửa chữa

o Người điều phối (moderator)

 Điều phối các hoạt động trong cuộc họp

 Đảm bảo định hướng cuộc họp là phát hiện các thiếu sót, tránh đi vào thảoluận về sửa chữa các thiếu sót

o Reader

 Đọc to các đoạn tài liệu đáng chú ý về sản phẩm cho đội rà soát nghe

o Người ghi chép (recorder)

 Ghi lại những thiếu sót đã được mọi người nhất trí

Thời gian họp:

o không nên quá 2 h

o cần dành chút thời gian ban đầu cuộc họp cho các rà soát viên sẵn sàng

Các công việc cần làm trong cuôc họp:

1 giới thiệu về cuộc họp

a mục đích cuộc họp

b các bên tham gia và vai trò của từng bên

2 đọc tài liệu về sản phẩm

a reader đọc to các đoạn tài liệu đáng chú ý để đội rà soát nghe

3 phát hiện và ghi lại những thiếu xót của sản phẩm

a mỗi cá nhân của đội rà soát nếu phát hiện ra thiếu sót gì sẽ nêu ra

b Mọi người thảo luận xem nó có đúng là thiếu sót không

c Nếu đúng thì người ghi chép sẽ ghi lại thiếu sót đó một cách rõ ràng và ngắn gọn

4 Nhìn lại danh sách những thiếu sót

5 đánh giá về sản phẩm Có các đánh giá sau:

a chấp nhận hoàn toàn : điều này thực tế hiếm

b chấp nhận với 1 chút chỉnh sửa nhỏ

c Chỉnh sửa quan trọng và cần có rà soát lại sau khi sửa xong

d Xây dựng lại sản phẩm

Phương châm: chắc là thà phát hiện nhầm còn hơn bỏ sót (cái này được suy ra từ thà yêu nhầm cònhơn không được yêu).

19 Nội dung cơ bản của một cuộc họp rà soát: Thành phần, thời gian, công việc cần làm, phương châm.

o Recorder: Người ghi chép lại toàn bộ nội dung cuộc họp

 Thời gian: Được tiến hành sau khi các thành viên đã có thời gian tự tìm ra các khiếm khuyết của sản phẩm Và kết quả của quá trình họp sẽ là đầu vào cho quá trình rework của các tác giả

Câu 20: Các sản phẩm của cuộc họp rà soát là gì? Nội dung, vài trò của mỗi sản phẩm đó?

Các sản phẩm của cuộc họp rà soát gồm:

1 danh sách các thiếu sót

a) Nội dung: gồm các thiếu sót của sản phẩm đã được đội rà soát phát hiện ra

b) Vai trò:

o Dùng đánh giá về sản phẩm xem có thiếu sót đến mức phải làm lại không

o Dùng cho tác giả căn cứ vào đó để sửa lại sản phẩm

3 Form tổng hợp đầy đủ các thiếu sót

o Nó chẳng qua chỉ là viết lại ds thiếu sót ở trên một cách quy củ theo mẫu biểu để hợp pháp, chính thức hóa tài liệu

4 các chú ý về cuộc họp

o ghi lại những bài học, kinh nghiệm rút ra từ cuộc họp, để lần sau tổ chức tốt hơn

20 Các sản phẩm của cuộc họp rà soát? Vai trò của các sản phẩm này

 Product disposition : Quyết định đối với sản phẩm: Có 3 mức là A- Accept, C Chấp nhận

có điều kiện, R- rà soát tiếp sau khi sửa lại Các quyết định này sẽ đề cập đến các thủ tục tiếp theo để kiểm chứng công việc sửa lại của tác giả (Author)

o A- Accept: Chấp nhận sản phẩm đã hoàn thành, mà không cần phải phải kiểm chứng việc sửa lại Tuy nó không công nhận là sản phẩm đã hoàn toàn hết lỗi, nhưng đảm bảo sẽ không có khiếm khuyết so với bản đặc tả của nó, và những lỗi nếu có chỉ là những lỗi nhỏ, có thể được giải quyết bởi tác giả

o C – Conditionaly : Chấp nhận có điều kiện Sản phẩm chỉ được chấp nhận nếu như được người điều hành (Moderator) kiểm chứng lại sau khi tác giả đã sửa Sản phẩm

có tồn tại lỗi, tuy nhiên những lỗi này không trầm trọng quá mức, và không đi ngược lại thiết kế của nó

o R – ReInspection: Phải rà soát lại sau khi nó được tác giả sửa lại Việc rà soát lại sẽ được tiến hành bao gồm tác giả, người điều hành và ít nhất một thành viên của đội rà soát cũ Trong trường hợp này, sản phẩm có nhiều lỗi nghiêm trọng và có nhiều thay đổi đáng kể so với thiết kế của nó

 Completed master defect list (Software Inspection defect list) : Danh sách các lỗi đã được rà soát Bản này liệt kê tất cả các lỗi được phát hiện ra trong cuộc họp Nó là tài liệu giúp cho tác giả sửa lại sản phẩm của mình và là cơ sở để đánh giá lại sản phẩm sau khi đã sửa lại

 Completed Software Inspection Defect Summary form : Báo cáo tổng kết lại toàn bộ hoạt động rà soát phần mềm Tài liệu tổng kết các kết quả mà cuộc họp đã đạt được, bao gồmbảng danh sách lỗi, mức độ ảnh hưởng của các lỗi

 Completed software inspection meeting notice : Biên bản đầy đủ của cuộc họp Ghi lại toàn bộ hoạt động cuộc họp: bao gồm nhân sự, công việc, thời gian, diễn biến cũng như kết quả cuộc họp

 Partially completed Software Inspection Summary Report : Báo cáo tổng kết từng phần của hoạt động rà soát Báo cáo chi tiết cho từng phần của rà soát theo từng module của sản phẩm

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

Rà soát được tiến hành đối với mọi sản phẩm tại mọi giai đoạn của quy trình công nghệ phần mềm Mục đích của nó là phát hiện ra lỗi và những bất thường của sản phẩm so với tài liệu thiết kế Rà soát được áp dụng cho tất cả các bước: phân tích, thiết kế, cấu hình dữ liệu (configuration data) và

dữ liệu kiểm thử….Rà soát và kiểm thử là hai quá trình bổ sung cho nhau, và không mâu thuẫn với

kỹ thuật kiểm chứng Cả hai kỹ thuật này đều được sử dụng trong quy trình xác nhận và kiểm chứng (validation and verification) Việc rà soát có thể kiểm tra hiệu năng so với đặc tả chứ phải so với yêucầu của người dùng

Câu 22.Các danh mục rà soát :

a rà soát kỹ nghệ hệ thống

Xem hệ thống có sử dụng những công nghệ đã đặt ra không, những công nghệ đó có đạt tiêuchí đã đề ra trong đặc tả không?

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

Xem việc lập kế hoạch có chính xác không, công việc có tiến triển như đúng kế hoạch đã lậpkhông?

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

Xem việc phân tích yêu cầu phần mềm đã chính xác với những yêu cầu khách hàng đề rachưa, những yêu cầu đó có chính xác so với đặc tả không?

Công việc kiểm thử đã làm đầy đủ chưa, kiểm thử đã chính xác chưa?

23 Nêu các ký hiệu và giải ghích nội dung, ý nghĩa các đại lượng: s1…s7, và các độ

đo trung gian?

S1 = tổng số module

S2 = # modules dependent upon correct dât source or produces data used , excl control ( ???)

S3 = số module phụ thuộc các tiến trình trước

S4 = tổng số item cơ sở dữ liệu

S5 = số item cơ sở dữ liệu là duy nhất ( unique)

S6 = số đoạn cơ sở dữ liệu

S7 = số module chỉ có 1 đầu vào và ra ( single entry and exit )

D1 = 1 nếu phương pháp thiết kế hình cung được sử dụng , nếu ko là 0

D4 = 1 – (S5/S4) – kích cỡ cơ sở dữ liệu

D5 = 1 – (S6/S4) DB compartmentalization ( ??? ) – chia để trị cơ sở dữ liệu

D6 = 1 – (S7/S1 ) – Module entrance/exit

24 Sử dụng công thức wiD ivới wi như thế nào và để làm gì.

Chỉ số chất lượng của thiết kế: Design Structure Quality Index

DSQL = Sum ( wiDi) trong đó wi là đô nặng có tổng là 1

- Càng gần tới 1 , chất lượng càng cao

- Nếu giá trị quá bé , cần đầu tư thiết kế hơn nữa

- Sư dụng tốt nhất khi so sánh , ví dụ với các dự án thành công lúc trước

25 Giải thích nội dung các thành phần và ý nghĩa của độ đo SMI và cách sử dụng nó?

Software Maturity Index (SMI)

SMI = [MT - (Fc + Fa + Fd)] / MT

MT = Số modules trong lần phát hành hiện tại

Fc = số modules trong lần phát hành hiện tại được thay đổi

Fa = Số modules trong lần phát hành hiện tại được thêm vào

Fd = Số modules trong lần phát hành trước bị xóa khỏi lần phát hành hiện tại

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 ?

Dựa trên việc tính toán dùng biểu đồ để miêu tả control flow của chương trình MCC bao gồm các model trong việc phân tích và kiểm tra (analyzability and testibility)

1 /cách tính MCC là MCC=E-N+2

Trong đó

E: là số cạnh (number of edge)N: là số nút (number of nodes)

Nó cũng chỉ ra rằng một chương trình với miêu tả nhị phân

2/ cách tính MCC=P+1

P: là số thuộc tính của nodes (vd: if, while, case…)

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ể ra ít nhất 5 nguyên nhân của những khiếm khuyết trong phần

mềm?

Đảm bảo chất lượng phần mềm dựa trên thống kê nghĩa là 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 các thông tin về các khiếm khuyết phần mềm

 Cố gắng 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

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 của giao diện môđun (IMI)

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

 Thử nghiệm 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 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 tính khiếm khuyết của 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ó?

Ei : Số lượng lỗi đã được tìm thấy trong pha i

Di : Số lượng lỗi được trong pha i nhưng chưa được tìm thấy cho đến khi đến pha i+n

( những lỗi này gọi là khiếm khuyết)

(pha i biểu diễn một pha trong vòng phát triển phần mềm như analys, design, coding, test,…)

Công thức tính khiếm khuyết của sản phẩm cuối cùng (Total Containment Effectiveness

(TCE)):

Trong đó:

E: Số lỗi được tìm thấy trong toàn bộ sản phẩm

DpreRelease: Số khiếm khuyết tìm thấy trước khi release

DReleased: Số khiếm khuyết tìm thấy sau khi đã released sản phẩm

Ý nghĩa: Những khiếm khuyết có thể đáng giá gấp nhiều lần lỗi tìm thấy Những khiếm khuyết được phát hiện sau khi triển khai phần mềm còn đáng giá hơn cả những khiếm khuyếttìm thấy trong những pha phát triển phần mềm Vì vậy việc phát hiện những khiếm khuyết trong các pha phần mềm là quan trọng 2 công thức trên biểu thị khả năng phát hiện khiếm khuyết trong số các lỗi được tìm thấy PCE&TCE càng cao càng chứng tỏ sản phẩm tốt theo quan điểm phát hiện khiếm khuyết

Câu 29: Quá trình phòng sạch là gì? Phương châm của kỹ thuật này là gì?

Định nghĩa:

Quá trình phòng sạch(Cleanroom process) là một công nghệ và quá trình quản lí cho việc phát triển phần mềm chất lượng cao với sự đảm bảo về độ tin cậy Quá trình phòng sạch được phát triển bắt đầu bởi Harlan Mills Cleanroom trong công nghệ phần mềm bản chất là quá trình ngăn ngừa các khiếm khuyết, hay nói đúng hơn là gỡ bỏ các khiếm khuyết của phần mềm, giống như một cách xác nhận độ tin cậy trong quá trình sử dụng

Kĩ thuật:

Đặc điểm nổi bật của Cleanroom là nó hoạt động theo cách truyền thống, phát triển từ những công nghệ thủ công đến những công nghệ cơ bản theo một cách rất chặt chẽ Kĩ thuật Cleanroom tạo ra các phần mềm chuẩn bằng thiết kế chính xác, bền vững nó được đảm bảo bằng việc kiểm tra thống

kê Đồng thời nó làm giảm được thời gian cho kế hoạch phát triển tiếp theo và tránh được việc phải thực hiện lại các công việc đã làm

Sự khác nhau trong chi phí sản xuất chính là sự khác nhau giữa việc kết hợp của các lỗi tìm thấy trong vòng đời phần mềm Bằng cách phát hiện ra các lỗi có thể xảy ra ngay ban đầu, Cleanroom đã giảm được chi phí cho lỗi trong khi phát triển và tránh được tác động của các thuật toán thất bại, do

đó chi phí cho toàn bộ vòng đời phát triển phần mềm bằng kĩ thuật Cleanroom có thể thấp hơn các

kĩ thuật thông thường

Nền tảng phát triển của kĩ thuật Cleanroom :

 Nâng cấp phát triển dưới điều khiển chất lượng thống kê (statistical quality control_SQC)

 Nâng cấp, phát triển dựa trên nền tảng toán học

 Kiểm thử phần mềm dựa trên nguyên lí thống kê

30 Độ tin cậy của phần mềm hiểu là cái gì? Đo độ tin cậy dựa trên những dữ liệu nào?

Độ tin cậy phần mềm là một nhân tố quan trọng của chất lượng phần mềm

Độ tin cậy phần mềm được đo trực tiếp & được đánh giá qua các dữ liệu phát triển và các dữ liệu lịch sử

Độ tin cậy phần mềm được định nghĩa theo thuật ngữ thống kê: “xác suất thao tác không thất bại củachương trình máy tính trong một môi trường đặc biệt với một thời gian đã định rõ”

 “thất bại” được hiểu 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:

o Mức độ: có khi chỉ là sự phiền phức, có khi là một thảm hoạ.

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

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

khác

Đo độ tin cậy dựa trên những dữ liệu nào?

Độ 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) mà: MTBF = MTTF + MTTR

Trong đó:

MTTF là thời gian hoạt động liên tục trung bình

MTTR là thời gian sửa xong lỗi trung bình

MTTF = (t11+ t21+ … tn1)/n

MTTR =(t12+ t22+ … tn2)/n

(Hình minh họa các lần thất bại xẩy ra)(t1, t2, t3, …tn = nhịp độ lỗi, ti1= làm việc , ti2= sửa lỗi )

Ý nghĩa độ tin cậy MTBF

MTBF là hữu ích hơn nhiều so với tỷ số “số khiếm khuyết / KLOC”: vì người dùng cuối chỉ quan

tâm tới thất bại họ

gặp, không quan tâm tới đếm lỗi.

Các lỗi trong chương trình không có cùng mức độ (số các 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,

 Có rất ít lỗi chỉ được phát hiện sau dăm chục năm,

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

1 Phải sửa lại theo yêu cầu mới sử dụng được

2 Phải thêm các chức năng mới sử dụng được

3 Thiết kế sai, phải xây dựng lại từ đầu

4 Hoàn toàn vô ích, yêu cầu ngay từ đầu đã sai, phần mềm phải vứt bỏ

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 chúng?

Độ tin cây (Reliability )

Tiêu chuẩn của sự tin cậy là Thời gian trung bình giữa các sự cố(mean time between failure MTBF) Là thời gian hoạt động trung bình theo thống kê giữa thời điểm một hệ thống bắt đầu vận hành và thời điểm xảy ra sự cố đầu tiên của nó xảy ra

-Được tính như sau:

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

Độ 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) mà: MTBF = MTTF + MTTR

Trong đó:

MTTF là thời gian hoạt động liên tục trung bình

MTTR là thời gian sửa xong lỗi trung bình

Có hai loại mô hình tiên đoán độ 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 hai tốt hơn

Các mô hình độ tin cậy:

 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 được 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 sinhra

 Dựa vào các đặc trưng nội tại của 1 chương trình và tính toán số dự đoán các sai tồn tại trongphầ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 gieo hạt độ tin cậy

Ý 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

Mục tiêu: Các mô hình gieo hạt có thể dùng như một chỉ báo của độ tin cậy phần mềm; hoặc 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 thử nghiệm

Câu 34: Độ an toàn phầm mềm là cái gì? Nêu các phương pháp phân tích độ an toàn phầm mềm.

Trước khi phần mềm được sử dụng trong những hệ thống không an toàn, thường được kiểm soát trong những thiết bị điện tử và cơ học thông thường (không lập trình được).Các kỹ thuật an toàn hệ thống được thiết kế để đối phó với những hỏng hóc ngẫu nhiên trong những hệ thống này.Những lỗi

thiết kế do con người không được xem xét một khi giả thiết rằng mọi khuyết điểm do những lỗi gây

ra bởi con người có thể được tránh hay loại bỏ hoàn toàn trước khi truyền lệnh và thao tác

Khi phần mềm được sử dụng như một phần của hệ điều khiển, độ phức tạp có thể tăng theo mức độ quan trọng hoặc hơn nữa Những lỗi thiết kế tinh vi gây ra bởi một lỗi gì đó của con người có thể bị tìm ra và loại trừ trong điều khiển thông thường trên nền phần cứng trở nên khó phát hiện hơn khi phần mềm được sử dụng

Độ an toàn phần mềm là độ hoạt động nhằm bảo đảm chất lượng phần mềm tập trung vào nhận dạng

và đánh giá những nguy cơ tiềm tàng có thể ảnh hưởng tiêu cực đến phần mềm và gây ra thất bại chotoàn hệ thống Nếu những nguy cơ thể nhận diện sớm trong quá trình xây dựng phần mềm, những đặc tính thiết kế phần mềm được chỉ định rõ sẽ có thể loại bỏ hoặc điều khiển được các nguy cơ.Một quá trình mô hình hóa và phân tích được quản lý như một phần của độ an toàn phần mềm Đầu tiên , các nguy cơ được nhận dạng và gộp nhóm theo độ nguy hiểm và rủi ro.Một khi các nguy cơ mức hệ thống được nhận dạng , các kỹ thuật phân tích được sử dụng để định độ nguy hiểm và xác suất xảy ra Để có hiệu quả, phần mềm phải được phân tích trong ngữ cảnh của toàn bộ hệ thống

Kỹ thuật phân tích như phân tích cây khuyết điểm ,lôgic thời gian thực ,hay các mô hình mạng Petri

có thể dự đoán dây chuyền sự kiện có thể gây ra những nguy cơ và xác suất mà toàn bộ sự kiện xuất hiện để tạo ra dây chuyền

Câu 35 Khảo sát nhu cầu SQA gồm những nội dung gì? nhằm trả lời cho câu hỏi gì? Nếu có nhu cầu thì làm gì?

Khảo sát nhu cầu SQA để đảm bảo rằng các cấp độ yêu cầu về chất lượng phải đạt được trong sản phẩm phần mềm, bao gồm định nghĩa các chuẩn và các thủ tục tương đương và đảm bảo rằng sản phẩm phần mềm được dựa theo các chuẩn đó Nên tập trung vào phát triển một “văn hóa chất lượng”nơi mà chất lượng được xem như là có khả năng đáp ứng cho tất cả mọi người

Nhằm trả lời cho câu hỏi “Chất lượng là gì?”

Nếu có nhu cầu thì phải:

Đảm bảo chất lượng: thiết lập các thủ tục và các chuẩn mang tính tổ chức cao cho chất lượng

Hoạch định chất lượng : chọn lựa các thủ tục và các chuẩn có thể áp dụng được cho một dự

án riêng biệt và sửa đổi chúng theo yêu cầu

Giám sát chất lượng: đảm bảo rằng các thủ tục và các chuẩn được tuân theo theo bởi nhóm phát triển phần mềm

Nhóm 3.2

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

Những vấn đề gì đặt ra khi triển khai SQA :

+ Cần phải định nghĩa rõ ràng thế nào là chất lượng phần mềm - “software quality”

+ Một khi đã hiểu rõ định nghĩa chất lượng phần mềm, cần xây dựng một hệ thống các hoạt động đảm bảo chất lượng , để đảm bảo rằng mọi bước sản xuất phần mềm đều có thể đưa ra những sản phẩm có chất lượng cao.

+ Thực hiện các hoạt động đảm bảo chất lượng đó trên mọi dự án phần mềm

+ Sử dụng các độ đo chất lượng để dựa vào đó ta có thể so sánh , và từ đó có những cải tiến quy trình, làm tăng chất lượng của sản phẩm cuối cùng

(Software Engineering, Chapter 8 Software Quality Assurance,Pressman ( p.193))

Lợi ích của SQA

Khi chất lượng luôn được quan tâm, nhấn mạnh trong tất cả các bước sản xuất phần mềm, sẽ giúp làm giảm số lượng các công việc phải làm lại, sửa chữa lại Do đó làm giảm chi phí sản xuất, và quan trọng hơn là làm giảm thời gian đưa sản phẩm vào thị trường…

(Software Engineering, Chapter 8 Software Quality Assurance,Pressman ( p.193))

Nguyên tắc chi phí hiệu quả của SQA

(Ở đây tớ hiểu chi phí hiệu quả là chi phí cần bỏ ra để đạt hiệu quả mong muốn)

Chi phí chất lượng (quality cost) bao gồm tất cả các chi phí cần bỏ ra để thực hiện các hoạt động liênquan đến việc đảm bảo chất lượng Chi phí chất lượng có thể chia làm 3 nhóm chính: Chi phí cho công tác phòng ngừa, chi phí cho công tác đánh giá, thẩm định, và chi phí khắc phục lỗi

+ Chi phí cho công tác phòng ngừa bao gồm: Chi phí lập kế hoạch đảm bảo chất lượng, chi phí rà soát , chi phí cho các thiết bị, phượng tiện dùng để kiểm thử, chi phí training…

+ Chi phí cho công tác đánh giá, thẩm định bao gồm các loại chi phí : Chi phí kiểm tra theo dõi từng quá trình, chi phí bảo dưỡng các thiết bị, chi phí kiểm thử…

+ Chi phí khắc phục lỗi bao gồm hai loại : Chi phí cho việc khắc phục các lỗi được phát hiện trước khi sản phẩm được giao cho khách hàng, và chi phí cho việc khắc phục các lỗi xảy ra sau khi sản phẩm đã được chuyển giao cho khách hàng Với các lỗi được phát hiện trước khi sản phẩm được chuyển giao cho khách hàng, ta phải mất các chi phí như: Chi phí cho việc phân tích lỗi, cho việc sửa lại, hoặc làm lại toàn bộ…

Với các lỗi xuất hiện sau khi sản phẩm đã được chuyển giao cho khách hàng, ta phải mất thêm các chi phí như: Chi phí giải quyết các phàn nàn của khách hàng, chi phí trợ giúp, các chi phí liên quan đến bảo hành…

(Software Engineering, Chapter 8 Software Quality Assurance,Pressman ( p.197))

37 Tại sao phải kiểm thử phần mềm? Mục tiêu kiểm thử là gì? Từ đó có những quan niệm sai gì về kiểm thử phần mềm?

Việc kiểm thử phần mềm là cần thiết để xác định phần mềm được tạo ra có đáp ứng đúng các yêu cầu hay không

Mục tiêu của kiểm thử:

- Phát hiện tất cả các lỗi có thể được trong khoảng thời gian cho trước

- Xác định xem một sản phẩm phần mềm có đáp ứng các đặc tả yêu cầu của nó hay không

- Đảm bảo chất lượng kiểm thử phần mềm với chi phí thấp nhất

- Tạo ra các Test-case có chất lượng cao, thực hiện các Tests có hiệu quả, đưa ra các báo cáo chính xác và có ích về các vấn đề xảy ra

Mục tiêu chính của quá trình kiểm thử là: phát hiện các lỗi trong phần mềm, bao gồm các lỗi trong:

- yêu cầu từ phân tích yêu cầu

- thiết kế tài liệu trong đặc tả thiết kế

- lập trình

- tài nguyên và môi trường hệ thống

- các vấn đề về phần cứng

Các quan niệm sai về kiểm thử phần mềm:

Câu 37 Tại sao phải kiểm thử phần mềm? Mục tiêu kiểm thử là gì? Từ đó có những quan niệm sai gì về kiểm thử phần mềm?

Tại sao phải kiểm thử phần mềm

+ Do phần mềm rất hay có lỗi, do đó cần kiểm thử để phát hiện các lỗi, sửa nó , và làm tăng độ tin cậy của phần mềm

+ Do việc sửa các lỗi bị phát hiện muộn thường là rất tốn kém

+ Để đảm bảo phần mềm tin cậy, đáp ứng được các yêu cầu đề ra , tránh bị khách hàng kiện…

Mục tiêu của kiểm thử:

+ Phát hiện tất cả các lỗi có thể được trong khoảng thời gian cho trước

+ Xác định xem một sản phẩm phần mềm có đáp ứng các đặc tả yêu cầu của nó hay không

+ Đảm bảo chất lượng kiểm thử phần mềm với chi phí thấp nhất

+ Tạo ra các Test-case có chất lượng cao, thực hiện các Tests có hiệu quả, đưa ra các báo cáo chính xác và có ích về các vấn đề xảy ra

Mục tiêu chính của quá trình kiểm thử là: phát hiện các lỗi trong phần mềm, bao gồm các lỗi trong:+yêu cầu từ phân tích yêu cầu

+thiết kế tài liệu trong đặc tả thiết kế

+lập trình

+tài nguyên và môi trường hệ thống

+các vấn đề về phần cứng

Các quan niệm sai về kiểm thử phần mềm:

+ Kiểm thử là một công việc chán ngắt, buồn tẻ

+ Kiểm thử có thể phát hiện ra tất cả các lỗi , và chứng minh rằng một hệ thống không có bất cứ mộtlỗi nào

+ Kiểm thử tốt nhất khi hệ thống đã đưa vào sử dụng

+ Chỉ kiểm thử một hoặc hai lần

+ Người lập trình có thể làm tất cả các công việc kiểm thử một khi họ đã code xong

…

(Practical Guide to Software System Testing, 1.2 Testing Myths )

Câu 38 Thế nào là một ca kiểm thử tốt? ca kiểm thử thành công? Lợi ích phụ của kiểm thử là gì?

• Một ca kiểm thử tốt là một ca kiểm thử có nhiều khả năng tìm ra một lỗi chưa được phát hiện cho

đến thời điểm hiện tại

• Một ca kiểm thử thành công là một ca kiểm thử mà phát hiện ra một lỗi chưa được phát hiện cho

đến thời điểm hiện tại

Mục tiêu là thiết kế ra được các test case có thể giúp phát hiện nhiều lớp lỗi khác nhau với chi phí vềthời gian và công sức thấp nhất.

Lợi ích phụ của kiểm thử: Kiểm thử giúp chứng tỏ các chức năng phần mềm có khả năng hoạt động

theo đúng các đặc tả, và có khả năng đáp ứng được các yêu cầu về hành vi và hiệu năng Ngoài ra,

dữ liệu thu thập được từ quá trình kiểm thử cho thấy tính tin cậy của phần mềm và biểu thị một chút

(Software Testing, University Of South Australia, Phần 1.1 Testing Fundamentals)

Do đó nếu theo tinh thần như trên thì có thể thay bằng hình ở Slide 1.12 của thầy, và phần giải thích sau đó (3 phần : What to test , How to test, How are the Result evaluated)

Câu 40K48 Nêu các đối tượng, các phương pháp kiểm thử phần mềm? chúng thường được sử dụng vào giai đoạn nào của quá trình phát triển?

(Do trong đề cương câu hỏi ôn tập phần 3.2 của thầy có nói các phương pháp kiểm thử phần mềm là: a Kiểm thử hộp trắng, b Kiểm thử hộp đen, c Kiểm thử đơn vị, d Kiểm thử tích hợp, e Kiểm thử

hệ thống…-> sẽ nói tất)

+ Kiểm thử hồi quy

Đối tượng và giai đoạn sử dụng đối với từng phương pháp :

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

Là phương pháp kiểm thử dùng để kiểm tra tính đúng đắn của cấu trúc bên trong của chương trình hoặc đoạn chương trình, kiểm tra tất cả các lệnh rẽ nhánh, các vòng lặp, các cấu trúc dữ liệu…+ Kiểm thử hộp đen

Dùng để đánh giá xem chương trình hoặc đoạn chương trình có đáp ứng được những yêu cầu đề ra không, chỉ tập trung vào các yêu cầu chức năng của phần mềm mà không quan tâm đến chi tiết cài đặt

+ Kiểm thử đơn vị : Đối tượng là các modun Được thực hiện trong giai đoạn trước khi các mô đun được tích hợp với các modun khác Ta thường dùng phương pháp kiểm thử hộp trắng trong giai đoạn này

+ Kiểm thử tích hợp : Đối tượng là một số hay toàn bộ các modun được tích hợp với nhau Thực hiện trong giai đoạn sau khi các môdun đã được phát triển và kiểm thử đơn vị thành công

+ Kiểm thử hệ thống : Đối tượng là toàn bộ hệ thống hoàn chỉnh Thực hiện trong giai đoạn toàn

bộ hệ thống đã được tích hợp hoàn chỉnh Kiểm thử đơn vị và kiểm thử tích hợp đã thành công Ta thường sử dụng phương pháp kiểm thử hộp đen trong giai đoạn này

+ Kiểm thử xác nhận : Đối tượng là toàn bộ hệ thống Thường dùng trong giai đoạn bàn giao hệ thống-> chứng minh cho khách hàng thấy hệ thống đạt được các tiêu chuẩn đã đề ra

+ Kiểm thử hồi quy : Đối tượng có thể là từng thành phần hay toàn bộ hệ thống Thường được sử dụng trong giai đoạn bảo trì hệ thống

40K47 Các đổi tượng, các phương pháp kiểm thử phần mềm? Chúng thường được sử dụng vào giai đoạn nào của quá trình phát triển?

o Hướng vào các đặc tả bên ngoài

o Chủ yếu là kiểm tra giao diện của các hàm vào ra

o Các kĩ thuật thường dùng:

Lược đồ nguyên nhân kết quả

Phân đoạn tương đương

Phân tích giá trị biên

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

 Thực hiện bên trong chương trình

 Sử dụng các đặc tả chi tiết

Kiểm thử hộp trắng thường được áp dụng ở giai đoạn đầu của kiểm thử, còn kiểm thử hộp đen được

áp dụng ở giai đoạn sau của kiểm thử

Câu 41: Một ca kiểm thử là cái gì? Mục tiêu thiết kế ca kiểm thử? Các bước để thiết kế một ca kiểm thử?

-Một ca kiểm thử ( Test case ) – (slide 3.32):

Là một bộ đầu vào và đầu ra được sử dụng để kiểm thử hệ thống

-Mục tiêu thiết kế ca kiểm thử : (slide 3.32)

Mục tiêu của việc thiết kế các ca kiểm thử đó là tạo ra một bộ các ca kiểm thử có hiệu quả trong việc xác nhận hệ thống tuân thủ đúng các điều kiện đã đặt ra từ trước + phát hiện ra các điểm yếu của hệ thống ( các điểm yếu này sẽ tình cờ được phát hiện ra trong quá trình kiểm thử chứ không hề được xác định trước )

-Các bước thiết kế một ca kiểm thử :

+ Xác định đối tượng cần test

+ Xác định môi trường mà ta sử dụng để test

+ Xác định dữ liệu để test ( đầu vào, đầu ra )

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

- Kiểm thử hộp trắng ( hay còn gọi là kiểm thử cấu trúc ) là một pp kiểm thử dùng để kiểm tra tính đúng đắn của cấu trúc bên trong của hệ thống

Các đặc trưng :

- Sử dụng để đảm bảo : (software testing – 1.2)

+ Tất cả các con đường ( hiểu nôm na với câu lệnh switch – case thì mỗi case là một con đường ) được thử, thực nghiệm ít nhất một lần

+ Tất cả các biểu thức logic được thực nghiệm, thử với cả hai trường hợp TRUE và FALSE + Tất cả các vòng lặp được thực hiện bên trong giới hạn của nó

+ Tất cả các cấu trúc dữ liệu đều được kiểm tra để đảm bảo tính hợp lệ.

- Kiểm thử hộp trắng có thể phát hiện ra những lỗi logic,lỗi thiết kế

- Yêu cầu sự hiểu biết về cấu trúc bên trong hệ thống

- Có thể áp dụng với đơn vị, tích hợp hay hệ thống Tuy nhiên thường là áp dụng cho kiểm thử đơnvị

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

Kiểm thử hộp đen

Mục đích: Xác định đầu ra có đúng mong đợi không khi dữ liệu đầu vào đã biết

 Phân đoạn tương đương: Bản chất dữ liệu là vô hạn, nên cần phân chia dữ liệu ra thành cácđoạn

o Mục đích: giảm số lượng test bằng cách chọn các tập dữ liệu đại diện

o Thực hiện: mỗi đoạn đại diện cho một số dữ liệu việc kiểm thử chỉ thực hiện trênđại diện đó

o Ưu điểm: Test theo mức trừu tượng hơn là trường áp dụng: màn hình, menu hay mứcquá trình

 Phân tích giá trị biên: rất quan trọng

 Đoán lỗi:

o Dựa vào trực giác hoặc kinh nghiệm

o Nhược điểm: không phát hiện được lỗi

Đặc trưng: thường áp dụng để kiểm thử dữ liệ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?

*Chiến lược kiểm thử phần mềm là: phải tìm ra được lỗi trong phần mềm đó và thiết lập chất lượng cho phần mềm này

“Chỉ có kiểm thử mọi khía cạnh mới có thể chỉ ra được 1 chương trình là không có lỗi Tuy nhiên, việc kiểm thử mọi khía cạnh này là điều không thể.”

*Nguyên tắc trong chiến lược kiểm thử phần mềm:

• Tất cả các kiểm thử nên có khả năng theo dõi được các yêu cầu của khách hàng: Như chúng ta

đã biết, mục đích của kiểm thử phần mềm là phải các lỗi không dự đoán trước được

• Kiểm thử nên được lập kế hoạch trước khi quá trình kiểm thử diễn ra: kế hoạch kiểm thử có thể bắt đầu ngay khi tài liệu đặc tả yêu cầu được hoàn thành Việc định nghĩa chi tiết các trường

hợp kiểm thử có thể bắt đầu ngay khi mô hình thiết kế được hóa cứng Do vậy, tất cả các Test phải được lập kế hoạch và thiết kế trước khi việc lập trình bắt đầu

• Áp dụng nguyên lý Pareto cho việc kiểm thử phần mềm: nguyên lý Pareto hàm ý rằng 80% tất

cả các lỗi phát hiện trong quá trình kiểm thử sẽ có khả năng theo dõi tới 20% tất cả các thành phần chương trình.Dĩ nhiên, vấn đề này là phải hoàn toàn tách biệt các thành phần khả nghi này và phải kiểm thử chúng hoàn toàn

• Việc kiểm thử nên bắt đầu “trong quy mô nhỏ” và tiến hành việc kiểm thử sau đó “trong quy

mô lớn”: Kiểm thử đầu tiên lập kế hoạch và thực thi đặt trọng tâm lên các thành phần đặc biệt Khi

việc kiểm thử được tiến hành điểm quan trọng là tìm ra lỗi trong việc tích hợp các thành phần với nhau và cuối cùng là trong toàn bộ hệ thống

• Việc kiểm thử hết mọi khía cạnh là điều không thể.

• Để đem lại hiệu quả cao nhất, việc kiểm thử nên được kiểm soát bởi “người thứ ba”

Black box

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 mỗi bước?

Chiến lược kiểm thử thời gian thực đó là các chiến lược kiểm thử cho các hệ thống thời gian thực.Những đặc trưng của các hệ thống thời gian thực đưa ra nhiều thách thức đối với công việc kiểm thử.Những người thiết kế các trường hợp kiểm thử không chỉ phải xem xét các trường hợp kiểm thử hộpđen và hộp trắng mà còn phải xét cả việc chia thời gian cho dữ liệu và cơ chế song song cho cácnhiệm vụ giải quyết dữ liệu đó Trong nhiều tình huống, dữ liệu kiểm thử được cung cấp cho hệthống thời gian thực đang ở trong một trạng thái sẽ phát sinh các xử lý đúng, nhưng cùng dữ liệu đóđược cung cấp khi hệ thống đang ở một trạng thái khác lại có thể dẫn tới lỗi

Chiến lược kiểm thử thời gian thực bao gồm 4 bước:

- Kiểm thử nhiệm vụ (task testing): bước đầu tiên trong kiểm thử phần mềm thời gian thực là kiểm

thử từng nhiệm vụ một cách độc lập Tức là, các kiểm thử hộp đen và hộp trắng được thiết kế vàthực hiện cho từng nhiệm vụ Mỗi nhiệm vụ được thực hiện độc lập nhau trong những phép kiểm thửnày Việc kiểm thử từng nhiệm vụ sẽ phát hiện ra lỗi về logic và chức năng nhưng không phát hiện

ra lỗi về thời gian hay hành vi

- Kiểm thử hành vi (behavioral testing): kiểm thử hành vi sử dụng các mô hình hệ thống đã được tạo

ra bằng các công cụ CASE Các mô hình này có thể mô phỏng hành vi của một hệ thống thời gianthực và xem xét hành vi của nó như hậu quả của các sự kiện bên ngoài Các hoạt động phân tích này

có thể làm cơ sở cho việc thiết kế các trường hợp kiểm thử sẽ được tiến hành khi phần mềm thờigian thực đã được xây dựng Thực hiện:

+ Dùng một kỹ thuật tương tự như phân hoạch tương đương để phân loại các sự kiện (nhưngắt, tín hiệu điều khiển, dữ liệu) cho kiểm thử

+ Mỗi một sự kiện này được kiểm thử riêng biệt và hành vi của hệ thống thực hiện đượckiểm tra để phát hiện ra lỗi

+ Khi từng lớp sự kiện đã được kiểm thử xong thì các sự kiện được đưa ra cho hệ thống theotrật tự ngẫu nhiên và với tần số ngẫu nhiên Hành vi của phần mềm sẽ được xem xét để phát hiện ralỗi hành vi

- Kiểm thử liên nhiệm vụ (intertask testing): khi các lỗi trong từng nhiệm vụ và lỗi hành vi của hệ

thống đã được cô lập thì việc kiểm thử chuyển sang các lỗi có liên quan tới thời gian Các nhiệm vụkhông đồng bộ (dị bộ) được dùng để liên lạc nhiệm vụ này với nhiệm vụ khác sẽ được kiểm thử vớicác tỉ lệ dữ liệu và tải xử lý khác nhau để xác định xem có các lỗi đồng bộ nhiệm vụ xuất hiện Bêncạnh đó, các nhiệm vụ liên lạc thông qua một hàng đợi thông báo hay kho dữ liệu sẽ được kiểm thử

để phát hiện ra lỗi trong việc định kích cỡ cho các kho lưu trữ dữ liệu này

- Kiểm thử hệ thống (system testing): phần mềm và phần cứng được tích hợp và kiểm thử hệ thống

được thực hiện để phát hiện ra lỗi trong giao diện giữa phần mềm/phần cứng Hầu hết các hệ thốngthời gian thực đều xử lý ngắt Do đó việc kiểm thử khả năng kiểm soát các sự kiện boolean là chủyếu Có thể sử dụng biểu đồ chuyển trạng thái, các đặc tả điều khiển, các tester phải lập danh sáchcác ngắt có thể và các xử lý tương ứng với các ngắt đó

46 Có những loại công cụ tự động nào trợ giúp kiểm thử? Mô tả nội dung mỗi loại?

Kiểm thử phần mềm thường chiếm 40% chi phí cho một dự án xây dựng phần mềm nên các công cụkiểm thử tự động có thể làm giảm thời gian kiểm thử (không làm giảm tính kỹ lưỡng) sẽ rất có giátrị Thừa nhận lợi ích tiềm năng này, các nhà nghiên cứu và người sử dụng đã phát triển thế hệ đầutiên các công cụ kiểm thử tự động:

- Bộ phân tích tĩnh: các hệ thống phân tích chương trình này hỗ trợ cho "việc chứng minh" các lý lẽ

tĩnh - những mệnh đề yếu kém về cấu trúc và định dạng của chương trình

-Bộ kiểm toán mã: những bộ lọc chuyên dụng này dùng để kiểm tra chất lượng của phần mềm để

đảm bảo rằng nó đáp ứng được các chuẩn mã hóa tối thiểu