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

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (815.41 KB, 61 trang )

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
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:..........................................................................................................11
18. Vẽ sơ đồ tiến trình của hoạt động rà soát và giải thích sơ bộ nội dung củ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 ?.....................................................................................................................................12

19. Nội dung cơ bản của một cuộc họp rà soát: Thành phần, thời gian, công việc cần là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 :............................................................................................................15
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 với 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?.................................................17
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
1

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
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
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ó?..........................................................28
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?............29
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?.......................30
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ì?..........................................................................................................................31
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ơ bản trong đồ thị dòng là cái gì? Độ phức tạp của chu trình là gì? Nêu các công
thức tính độ phức tạp?.........................................................................................................................32
51. Ma trận kiểm thử được cấu trúc như thế nào? Nó dùng để làm gì?...............................................33
52. Nêu các loại điều kiện trong cấu trúc điều khiển và cho ví dụ? Có những loại sai nào trong điều
kiện khi kiểm thử?...............................................................................................................................33
53. Chiến lược kiểm thử phân nhánh nghĩa là gì? Yêu cầu đặt ra cho kiểm thử phân nhánh là gì?....33
i. Chọn một trường hợp kiểm thử để bắt đầu............................................................................34
ii. Trường hợp sau giống cái đầu chỉ thay đổi một sô thông số cho phù hợp thôi....................34
iii. Tiếp tục cho đên 'C' xuất phát.............................................................................................34
iv. Sử dụng các đặc tả của chương trình dể quyết định xem loại dữ liệu nào nên làm(tốt nhất là
việc này nên làm bởi các nhà phân tích)...................................................................................34
v. Thực hiện đi bộ qua chương trình.........................................................................................34
54. Chiến lược kiểm thử miền là gì? Nó dựa trên tư tưởng nào?.......................................................34
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ệ?....................................................................35
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
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

2

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 hì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

3

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
- understandable: dễ hiểu
ví dụ: phần này các bạn nên lấy chính bài tập lớn của các bạn để minh chứng. Mỗi điều kiện có 1 ví
dụ là hay nhất.
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 ?
Theo ISO 9126 có 6 nhân tố chính:

4

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 )

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 ?
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:
Fq = c1 _ m1 + c2 _ m2 + . . . + cn _ mn
Trong đó Fq: là một nhân tố chất lượng phần mềm, ci là các hệ trọng số, mi 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)

Giải thích các độ đo:
Correctness: là độ đo phần mềm có làm đúng theo đặc tả và thỏa mãn đầy đủ các yêu cầu của khách

hàng
Reliability: là độ đo phần mềm có thể thực hiện các chức năng mong muốn với độ chính xác cho
trước không
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.
6

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

đượ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ượng
củ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ác
chuẩ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?

Trả lời:
Các hoạt động đảm bảo chất lượng phần mềm là một hoạt động bao trùm lên tất cả quá trình phát
triển phần mềm.
Điều này có nghĩa là trong quá trình phát triển phần mềm, hoạt động đảm bảo chất lượng phần
mềm cần phải được thực hiện ở mỗi giai đoạn, và bắt đầu thực hiện ngay từ giai đoạn ban đầu, chứ
không phải đến khi có sản phẩm mới thực hiện việc bảo đảm 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ượng
phầ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ỉnh
cần thiết để dự án đạt được chất lượng cao nhất.
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?
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ển
khai 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ào hoạ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ến
trú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 sau
nà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ần

mề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ần
mề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ác
lỗ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ất
bạ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ển
củ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 : />•

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 theo
mong 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ần
mề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ác
nhà 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 :

9

1. Activity 1 -- A SQA plan is prepared for the software project according to a documented
procedure.
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 software
development 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êu
chuẩ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 software
engineering 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 are
documented 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ác tà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ũng nắ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.

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?
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ớm
hơ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ần
mề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ục tiêu của FTR là (5) :
- khám phá ra những lỗi (errors) trong chức năng, logic, hay sự thực hiện đối với bất kỳ miêu tả nào
của phần mềm;

- để thẩm định xác minh rằng phần mềm rà soát xong phù hợp với các yêu cầu của 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:
Sản phẩm
làm ra

Lập kế
hoạch

Xem tổng
thể
Chuẩn bị

Họp rà
soát

Làm lại

11
Theo sát

SP làm ra
đã thẩm định

Giai đoạn rà soát
Lập kế hoạch
Xem tổng thể

Chuẩn bị
Họp rà soát
Soạn lại
Theo sát

Mô tả
Xác định sản phẩm làm ra được rà soát và lập lịch rà soát.
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.
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.
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.
Sản phẩm làm ra được sửa lại phù hợp yêu cầu và đặc 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. Vẽ sơ đồ tiến trình của hoạt động rà soát và giải thích sơ bộ nội dung của mỗi
bước.

 Planning: Xác định các công việc sẽ được rà soát và lên kế hoạch rà soá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 này có thể có hoặc không trong quá trình rà soát, dành cho các thành viên
của nhóm đang còn lạ với các công việc được rà soát có thời gian để định hướng các công
việc được rà soát.
 Individual Preparation: Các thành viên làm việc độc lập nhằm tìm ra các khiếm khuyết của
sản phẩm.
 Inspection meeting: Các thành viên thảo luận về các khiếm khuyến của sản phẩm đã được

tìm ra.
 Rework: Sản phẩm sẽ được sửa lại để thỏa mãn các yêu cầu và đặc tả.
 Follow-up: Sản phẩm sau khi được sửa lại sẽ được kiểm chứng, kết quả rà soát cuối cùng sẽ
được tập hợp và tổng kết lại. Quá trình kiểm duyệt kết thú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
nghe tà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:

12

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ảo
luậ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òn hơn không được yêu).
13

19. Nội dung cơ bản của một cuộc họp rà soát: Thành phần, thời gian, công việc cần
làm, phương châm.
 Thành phần:
o Tác giả: Là người trực tiếp làm ra sản phẩm được rà soát. Đây là người sẽ sửa lại sản
phẩm trong trường hợp sản phẩm có sai sót.
o Người rà soát: Đóng vai trò rà soát chính trong cuộc họp. Người rà soát sẽ phân tích
và tìm ra các sai sót trong sản phẩm.
o Người điều hành: Điều hành cuộc họp, đảm bảo cuộc họp đi đúng theo kế hoạch đề
ra.
o Reader: Người chịu trách nhiệm giúp nhóm rà soát xuyên suốt trong toàn bộ cuộc họp
bằng cách đọc các đơn vị logic cần kiểm duyệt.
o Recorder: Người ghi chép lại toàn bộ nội dung cuộc họp.
 Thời gian: Được tiến hành sau khi các thành viên đã có thời gian tự tìm ra các khiếm khuyết
của sản phẩm. Và kết quả của quá trình họp sẽ là đầu vào cho quá trình rework của các tác
giả.
 Công việc cần làm:
o Rà soát các modun của công việc, tranh luận cùng nhau để xác định một sai sót được
tìm ra ở bước trước có thực sự đúng là sai sót cần phải sửa chữa hay không.
o Sắp xếp, lập danh sách và tổng kết lại các sai sót đã được thảo luận.

o Lập báo cáo.
 Phương châm: Chỉ tập trung thảo luận vào các sai sót của sản phẩm, tránh bị chuyển hướng
sang khắc phục sai sót. Khắc phục sai sót được dành cho tác giả ở giai đoạn rework căn cứ
vào danh sách các sai sót có ở bước họp.

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.
2. Bản đánh giá về sản phẩm:
a) Nội dung: cho biết sản phẩm có phải chỉnh sửa gì không, có được chấp nhận không.
b) Vai trò:
o Từ kết quả đánh giá, các nhà quản lý xem xét đến tài chính cho đầu tư xay dựng
sản phẩm, thời hạn giao nộp sản phẩm, để có biện pháp thích hợp.
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.

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

•

•

•

•

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ồm
bả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êu
cầu của người dùng.
Các sản phẩm cần rà soát:
Quy trình phần mềm trải qua rất nhiều giai đoạn, mỗi giai đoạn đều có những sản phẩm công việc
khác nhau. Việc rà soát tiến hành trên tất cả các sản phẩm này. Các sản phẩm rà soát có thể là:
• Các đặc tả yêu cầu phần mềm
• Tài liệu thiết kế mức cao
• Các module code
Câu 22.Các danh mục rà soát :
a. rà soát kỹ nghệ hệ thống
15

b.

c.

d.
e.
f.

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êu
chí đã đề ra trong đặc tả không?.
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ập
không?.
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 đề ra
chưa, những yêu cầu đó có chính xác so với đặc tả không?.
rà soát thiết kế phần mềm
Phần mềm thiết kế có đúng tiêu chuẩn đã đặt ra trong đặc tả phần mềm chưa?.
rà soát khâu lập mã phần mềm
Mật mã phần mềm có được thiết lập an toàn như trong đặc tả đã đề ra không?
rà soát kiểm thử phần mềm
Công việc kiểm thử đã 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?

a
b

c
g

f
h

m

d

e

i

j

k

l

p

q

r

n

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
D2 = 1 – ( S2/S1 ) – module độc lập
D3 = 1-(S3/S1) – độc lập của tiến trình trước
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

16

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

24. Sử dụng công thức

∑ w D với ∑ w
i

i

i

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ó.
17

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ó?
Trả lời:
Công thức tính khiếm khuyết của sản phẩm ở một pha phát triển phần mềm(Phase
Containment Effectiveness(PCE)):

Trong đó:
PCEi: Số khiếm khuyết của sản phẩm ở pha i
Ei : Số lượng lỗi đã được tìm thấy trong pha i

18

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ết
tì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.
19

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ủa
chươ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):

20

•

•
•

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

Nhóm 2.4
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 :
Trả lời :
- Thất bại của phần mềm là phần mềm đã đem ra sử dụng ngoài thực tế nhưng không đáp ứng được
các yêu cầu của công việc.
- Có các thang bậc :
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 hoạt động trung bình theo thống kê giữa thời điểm một hệ thống bắt đầu vận
hành và thời điểm xảy ra sự cố đầu tiên của nó xảy ra.
Được tính như sau:
MTBF= MTTF+ MTTR
Trong đó MTTF (mean-time-to-failure) và MTTR (mean-time-to-repair)
Tính sẵn sàng (Availability)
Tính sẵn sàng của phần mềm là xác suất mà một chương trình đang vận hành theo những yêu
cầu tại một điểm và được xác định như sau:
Availability = [ MTTF/( MTTF+ MTTR)]x100%

Trong đó MTTF (mean-time-to-failure) và MTTR (mean-time-to-repair)

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
21

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 sinh
ra.
• 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 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 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 cho

22

toà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

23

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ên
quan đế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:

24

Câu 37. Tại sao phải kiểm thử phần mềm? Mục tiêu kiểm thử là gì? Từ đó có
những quan niệm sai gì về kiểm thử phần mềm?
Tại sao phải kiểm thử phần mềm
+ Do phần mềm rất hay có lỗi, do đó cần kiểm thử để phát hiện các lỗi, sửa nó , và làm tăng độ tin
cậy của phần mềm.
+ Do việc sửa các lỗi bị phát hiện muộn thường là rất tốn kém
+ Để đảm bảo phần 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ột
lỗi nào.
+ Kiểm thử tốt nhất khi hệ thống đã đưa vào sử dụng
+ Chỉ kiểm thử một hoặc hai lần
+ Người lập trình có thể làm tất cả các công việc kiểm thử một khi họ đã code xong.
….
(Practical Guide to Software System Testing, 1.2 Testing Myths )

Câu 38. Thế nào là một ca kiểm thử tốt? ca kiểm thử thành công? Lợi ích phụ
của kiểm thử là gì?
• Một ca kiểm thử tốt là một ca kiểm thử có nhiều khả năng 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,

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

Tài liệu liên quan

Tài liệu bạn tìm kiếm đã sẵn sàng tải về