Software Testing and Quality Assurance T-1

KIỂM THỬ PHẦN MỀM
VÀ ĐẢM BẢO CHẤT LƯỢNG

Lý thuyết và thực hành
KSHIRASAGAR NAIK
Khoa Kỹ thuật Điện và Máy tính
Đại học Waterloo, Waterloo
CHUYẾN ĐI PRIYADARSHI
NEC Laboratories America, Inc.
A JOHN WILEY & SONS, INC., PUBLICATION

Bản quyền © 2008 của John Wiley & Sons, Inc. Mọi quyền được bảo lưu.
Được xuất bản bởi John Wiley & Sons, Inc., Hoboken, New Jersey Được xuất bản đồng thời ở
Canada
Không một phần nào của ấn phẩm này có thể được sao chép, lưu trữ trong một hệ thống truy xuất,
hoặc truyền tải dưới bất kỳ hình thức nào hoặc bằng bất kỳ phương tiện nào, điện tử, cơ khí,
photocopy, ghi âm, quét, hoặc bằng cách khác, trừ khi được cho phép theo Mục 107 hoặc 108 của
Hoa Kỳ năm 1976 Đạo luật Bản quyền của Tiểu bang, mà không có sự cho phép trước bằng văn bản
của Nhà xuất bản hoặc ủy quyền thông qua việc thanh toán phí mỗi bản sao thích hợp cho Trung tâm
Xóa bản quyền, Inc., 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 750-4470
hoặc trên web tại www.copyright.com. Các yêu cầu cấp phép đối với Nhà xuất bản phải được gửi tới
Phòng Cấp phép, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax
(201) 748-6008 hoặc trực tuyến tại http : //www.wiley.com/go/permission.
Giới hạn trách nhiệm pháp lý / Tuyên bố từ chối bảo hành: Mặc dù nhà xuất bản và tác giả đã nỗ lực
hết sức để chuẩn bị cuốn sách này, họ không tuyên bố hoặc bảo đảm về tính chính xác hoặc đầy đủ
của nội dung cuốn sách này và đặc biệt từ chối bất kỳ bảo đảm ngụ ý nào về khả năng bán được hoặc
thể dục cho một mục đích cụ thể. Không có bảo hành nào có thể được tạo ra hoặc mở rộng bởi các
đại diện bán hàng hoặc các tài liệu bán hàng bằng văn bản. Những lời khuyên và chiến lược trong tài
liệu này có thể không phù hợp với tình huống của bạn. Bạn nên tham khảo ý kiến của một chuyên gia
nếu thích hợp. Nhà xuất bản và tác giả đều không chịu trách nhiệm về bất kỳ tổn thất lợi nhuận hoặc
bất kỳ thiệt hại thương mại nào khác, bao gồm nhưng không giới hạn ở các thiệt hại đặc biệt, ngẫu
nhiên, do hậu quả hoặc các thiệt hại khác.
Để biết thông tin chung về các sản phẩm và dịch vụ khác của chúng tôi hoặc để được hỗ trợ kỹ thuật,
vui lòng liên hệ với Bộ phận Chăm sóc Khách hàng của chúng tôi tại Hoa Kỳ theo số (800) 762-2974,
bên ngoài Hoa Kỳ theo số (317) 572-3993 hoặc fax (317) 572- 4002.
Wiley cũng xuất bản sách của mình dưới nhiều định dạng điện tử. Một số nội dung xuất hiện trong
bản in có thể không có sẵn ở định dạng điện tử. Để biết thêm thông tin về các sản phẩm của Wiley,
hãy truy cập trang web của chúng tôi tại www.wiley.com.
Dữ liệu Biên mục của Thư viện Quốc hội:
Naik, Kshirasagar, 1959–
Kiểm thử phần mềm và đảm bảo chất lượng / Kshirasagar Naik và Priyadarshi Tripathy. P. cm.
Bao gồm tài liệu tham khảo và chỉ mục.
ISBN 978-0-471-78911-6 (vải)
CONTENTS
Lời nói đầu xvii
Danh sách các hình xxi
xxvi
Danh sách các bảng
i
CHƯƠNG 1 CÁC KHÁI NIỆM VÀ NGUYÊN NHÂN CƠ BẢN 1
1.1 Cuộc cách mạng về chất lượng 1

1.2 Chất lượng phần mềm 5
1.3 Vai trò của Kiểm tra 7
1.4 Xác minh và xác thực 7
1.5 Thất bại, Lỗi, Lỗi và Lỗi 9
1.6 Khái niệm về độ tin cậy của phần mềm 10
1.7 Mục tiêu của Kiểm tra 10
1.8 Test Case là gì? 11
1.9 Kết quả Dự kiến 12
1.10 Khái niệm về kiểm tra hoàn chỉnh 13
1.11 Vấn đề trọng tâm trong thử nghiệm 13
1.12 Hoạt động kiểm tra 14
1.13 Mức độ kiểm tra 16
1.14 Nguồn thông tin để lựa chọn trường hợp thử nghiệm 18
1.15 Kiểm tra hộp trắng và hộp đen 20
1.16 Lập kế hoạch và Thiết kế Thử nghiệm 21
1.17 Thực hiện kiểm tra theo dõi và đo lường 22
1.18 Công cụ kiểm tra và tự động hóa 24
1.19 Tổ chức và quản lý nhóm kiểm tra 26
1.20 Nội dung cuốn sách 27
Tài liệu tham khảo 28
Bài tập 30
CHƯƠNG 2 LÝ THUYẾT VỀ KIỂM TRA CHƯƠNG TRÌNH 31
2.1 Các khái niệm cơ bản trong lý thuyết kiểm tra 31

2.2 Lý thuyết của Goodenough và Gerhart 32
2.2.1 Các khái niệm cơ bản 32
2.2.2 Lý thuyết về kiểm tra 34
2.2.3 Lỗi chương trình 34
2.2.4 Các điều kiện về độ tin cậy 36
2.2.5 Mặt hạn chế của lý thuyết 37
2.3 Lý thuyết của Weyuker và Ostrand 37
vii
viii
NỘI DUNG
2.4 Lý thuyết về Gourlay 39
2.4.1 Một vài định nghĩa 40
2.4.2 Sức mạnh của các phương pháp thử 42
2.5 Tính đầy đủ của Kiểm tra 42
2.6 Hạn chế của Kiểm tra 45 2.7 Tóm tắt 46
Tổng quan Văn học 47
Bài tập 49
CHƯƠNG 3 KIỂM TRA ĐƠN VỊ 51
3.1 Khái niệm về Kiểm thử đơn vị 51

3.2 Kiểm tra đơn vị tĩnh 53
3.3 Phòng ngừa khiếm khuyết 60
3.4 Kiểm tra đơn vị động 62
3.5 Thử nghiệm đột biến 65
3.6 Gỡ lỗi 68
3.7 Kiểm thử đơn vị trong lập trình eXtreme 71
3.8 JUnit: Khung cho Kiểm thử Đơn vị 73
3.9 Các công cụ để kiểm tra đơn vị 76 3.10 Tóm tắt 81
Bài tập 86
CHƯƠNG 4 KIỂM TRA LƯU LƯỢNG ĐIỀU KHIỂN
88
4.1 Ý tưởng cơ bản 88

4.2 Đề cương kiểm tra luồng kiểm soát 89
4.3 Đồ thị luồng điều khiển 90
4.4 Đường dẫn trong Đồ thị luồng điều khiển 93
4.5 Tiêu chí lựa chọn đường dẫn 94
4.5.1 Tiêu chí 96 về mức độ phù hợp trên tất cả các đường dẫn
4.5.2 Mức độ phù hợp của Tuyên bố Tiêu chí 97
4.5.3 Tiêu chí về độ phủ chi nhánh 98
4.5.4 Dự đoán mức độ phù hợp Tiêu chí 100
4.6 Tạo đầu vào kiểm tra 101
4.7 Ví dụ về Lựa chọn Dữ liệu Thử nghiệm 106
4.8 Chứa Đường dẫn Bất khả thi 107
4.9 Tóm tắt 108
Bài tập 111 11
CHƯƠNG 5 KIỂM TRA DÒNG DỮ LIỆU 2
5.1 Ý tưởng chung 112
5.2 Sự bất thường của luồng dữ liệu 113
5.3 Tổng quan về Kiểm tra luồng dữ liệu động 115
5.4 Biểu đồ luồng dữ liệu 116
NỘI DUNG
5.5 Điều khoản luồng dữ liệu 119
ix
5.6 Tiêu chí kiểm tra luồng dữ liệu 121
5.7 So sánh các tiêu chí lựa chọn kiểm tra luồng dữ liệu 124
5.8 Con đường khả thi và Tiêu chí lựa chọn thử nghiệm 125
5.9 So sánh các kỹ thuật kiểm tra 126
5.10 Tóm tắt 128
Tạp chí Văn học 129
Bài tập 132
CHƯƠNG 6 KIỂM TRA TRONG MIỀN 135
6.1 Lỗi tên miền 135

6.2 Kiểm tra lỗi miền 137
6.3 Các nguồn của Miền 138
6.4 Các loại lỗi miền 141
6.5 BẬT và TẮT Điểm 144
6.6 Tiêu chí lựa chọn thử nghiệm 146
6.7 Tóm tắt 154
Bài tập 156
CHƯƠNG 7 KIỂM TRA TÍCH HỢP HỆ THỐNG 158
7.1 Khái niệm về kiểm thử tích hợp 158

7.2 Các loại giao diện khác nhau và lỗi giao diện 159
7.3 Mức độ chi tiết của Kiểm tra Tích hợp Hệ thống 163
7.4 Kỹ thuật tích hợp hệ thống 164
7.4.1 Cộng dồn 164
7.4.2 Từ trên xuống 167
7.4.3 Từ dưới lên 171
7.4.4 Sandwich và Big Bang 173
7.5 Tích hợp phần mềm và phần cứng 174
7.5.1 Kiểm tra xác minh thiết kế phần cứng 174
7.5.2 Ma trận tương thích phần cứng và phần mềm 177
7.6 Kế hoạch Kiểm tra Tích hợp Hệ thống 180
7.7 Tích hợp thành phần Off-the-Shelf 184
7.7.1 Kiểm tra thành phần Off-the-Shelf 185
7.7.2 Kiểm tra tích hợp 186
7.8 Tóm tắt 187
Bài tập 190
CHƯƠNG 8 CÁC DANH MỤC KIỂM TRA HỆ THỐNG 192
8.1 Phân loại các Kiểm tra Hệ thống 192

8.2 Kiểm tra cơ bản 194
8.2.1 Thử nghiệm khởi động 194
8.2.2 Kiểm tra nâng cấp / hạ cấp 195
NỘI DUNG
x
8.2.3 Thử nghiệm điốt phát sáng 195
8.2.4 Kiểm tra chẩn đoán 195
8.2.5 Kiểm tra giao diện dòng lệnh 196
8.3 Kiểm tra chức năng 196
8.3.1 Kiểm tra Hệ thống Truyền thông 196
8.3.2 Kiểm tra mô-đun 197
8.3.3 Kiểm tra Ghi nhật ký và Truy tìm 198
8.3.4 Kiểm tra hệ thống quản lý yếu tố 198
8.3.5 Thử nghiệm cơ sở thông tin quản lý 202
8.3.6 Kiểm tra giao diện người dùng đồ họa 202
8.3.7 Kiểm tra bảo mật 203
8.3.8 Kiểm tra tính năng 204
8.4 Kiểm tra độ bền 204
8.4.1 Kiểm tra giá trị ranh giới 205
8.4.2 Thử nghiệm đi xe đạp điện 206
8.4.3 Thử nghiệm Chèn và Loại bỏ Trực tuyến 206
8.4.4 Kiểm tra tính khả dụng cao 206
8.4.5 Kiểm tra nút xuống cấp 207
8.5 Kiểm tra khả năng tương tác 208
8.6 Kiểm tra hiệu suất 209
8.7 Kiểm tra khả năng mở rộng 210
8.8 Kiểm tra căng thẳng 211
8.9 Kiểm tra tải và độ ổn định 213
8.10 Kiểm tra độ tin cậy 214
8.11 Kiểm tra hồi quy 214
8.12 Kiểm tra tài liệu 215
8.13 Kiểm tra quy định 216
8.14 Tóm tắt 218
Bài tập 221
CHƯƠNG 9 KIỂM TRA CHỨC NĂNG 222
9.1 Các khái niệm kiểm tra chức năng của Howden 222
9.1.1 Các loại biến khác nhau 224
9.1.2 Véc tơ thử nghiệm 230
9.1.3 Kiểm tra một chức năng trong ngữ cảnh 231
9.2 Mức độ phức tạp của việc áp dụng thử nghiệm chức năng 232
9.3 Thử nghiệm theo cặp 235
9.3.1 Mảng trực giao 236
9.3.2 Theo thứ tự tham số 240
9.4 Phân vùng lớp tương đương 244
9.5 Phân tích giá trị ranh giới 246
9.6 Bảng Quyết định 248
9.7 Thử nghiệm ngẫu nhiên 252
9.8 Đoán lỗi 255
9.9 Phân vùng danh mục 256
9.10 Tóm tắt 258
NỘI DUNG
xi
Bài tập 262
CHƯƠNG 10 TEST THẾ HỆ TỪ CÁC MÔ HÌNH FSM 265
10.1 Mô hình hướng trạng thái 265

10.2 Điểm kiểm soát và quan sát 269
10.3 Máy trạng thái hữu hạn 270
10.4 Tạo thử nghiệm từ FSM 273
10.5 Phương pháp tham quan chuyển tiếp 273
10.6 Kiểm tra với xác minh trạng thái 277
10.7 Trình tự đầu vào-đầu ra duy nhất 279
10.8 Phân biệt trình tự 284
10,9 Đặc điểm trình tự 287
10.10 Kiến trúc thử nghiệm 291
10.10.1 Kiến trúc cục bộ 292
10.10.2 Kiến trúc phân tán 293
10.10.3 Kiến trúc phối hợp 294
10.10.4 Kiến trúc từ xa 295
10.11 Kiểm tra và Kiểm tra Ký hiệu Kiểm tra Phiên bản 3 (TTCN-3) 295
10.11.1 Mô-đun 296
10.11.2 Khai báo dữ liệu 296
10.11.3 Cổng và các thành phần 298
10.11.4 Bản án trường hợp thử nghiệm 299
10.11.5 Trường hợp thử nghiệm 300
10.12 FSM mở rộng 302
10.13 Tạo thử nghiệm từ các mô hình EFSM 307
10.14 Tiêu chí phạm vi bổ sung để kiểm tra hệ thống 313
10.15 Tổng kết 315 Ôn tập Ngữ văn 316
Bài tập 318
CHƯƠNG 11 THIẾT KẾ THỬ NGHIỆM HỆ THỐNG 321
11.1 Các yếu tố thiết kế thử nghiệm 321

11.2 Nhận dạng Yêu cầu 322
11.3 Đặc điểm của các yêu cầu có thể kiểm tra 331
11.4 Nhận dạng khách quan bài kiểm tra 334
11.5 Ví dụ 335
11.6 Mô hình hóa quy trình thiết kế thử nghiệm 345
11.7 Kết quả kiểm tra mô hình hóa 347
11.8 Các chỉ số chuẩn bị cho thiết kế thử nghiệm 349
11.9 Hiệu quả thiết kế trường hợp thử nghiệm 350
11.10 Tổng kết 351 Ôn tập văn học 351
Tài liệu tham khảo 353 Bài tập 353
NỘI DUNG
CHƯƠNG 12 QUY HOẠCH THỬ NGHIỆM VÀ TỰ ĐỘNG HÓA HỆ THỐNG
355
xii
12.1 Cấu trúc của Kế hoạch kiểm tra hệ thống 355
12.2 Giới thiệu và Mô tả tính năng 356
12.3 Giả định 357
12.4 Phương pháp tiếp cận thử nghiệm 357
12.5 Cấu trúc bộ thử nghiệm 358
12.6 Môi trường thử nghiệm 358
12.7 Chiến lược thực thi kiểm tra 361
12.7.1 Chiến lược kiểm tra hệ thống đa chu trình 362
12.7.2 Đặc điểm của các chu kỳ kiểm tra 362
12.7.3 Chuẩn bị cho chu kỳ thử nghiệm đầu tiên 366
12.7.4 Lựa chọn các trường hợp kiểm tra cho chu kỳ kiểm tra cuối cùng
369
12.7.5 Ưu tiên các trường hợp thử nghiệm 371
12.7.6 Chi tiết về ba chu kỳ thử nghiệm 372
12.8 Ước tính Nỗ lực Kiểm tra 377
12.8.1 Số lượng trường hợp thử nghiệm 378
12.8.2 Nỗ lực tạo trường hợp thử nghiệm 384
12.8.3 Nỗ lực thực thi trường hợp thử nghiệm 385
12.9 Các mốc thời gian lên lịch và kiểm tra 387
12.10 Tự động hóa kiểm tra hệ thống 391
12.11 Đánh giá và lựa chọn các công cụ tự động hóa kiểm tra 392
12.12 Hướng dẫn lựa chọn thử nghiệm cho tự động hóa 395
12.13 Đặc điểm của các trường hợp kiểm thử tự động 397
12.14 Cấu trúc của một trường hợp kiểm thử tự động 399
12.15 Cơ sở hạ tầng tự động hóa thử nghiệm 400
12,16 Tóm tắt 402 Ôn tập Ngữ văn 403
Bài tập 406
CHƯƠNG 13 THỬ NGHIỆM HỆ THỐNG 408
13.1 Ý tưởng cơ bản 408

13.2 Các khiếm khuyết về mô hình hóa 409
13.3 Chuẩn bị sẵn sàng để bắt đầu kiểm tra hệ thống 415
13.4 Các chỉ số để kiểm tra hệ thống theo dõi 419
13.4.1 Các chỉ số để giám sát việc thực hiện kiểm tra 420
13.4.2 Ví dụ về chỉ số thực thi kiểm tra 420
13.4.3 Các chỉ số để giám sát các báo cáo lỗi 423
13.4.4 Ví dụ về chỉ số báo cáo lỗi 425
13.5 Phân loại khiếm khuyết trực giao 428
13.6 Phân tích nguyên nhân khiếm khuyết 431
13.7 Thử nghiệm Beta 435
13,8 Chuyến hàng của khách hàng đầu tiên 437
13.9 Báo cáo kiểm tra hệ thống 438
13.10 Sản phẩm duy trì 439
13.11 Đo lường hiệu quả kiểm tra 441
13.12 Tổng kết 445 Ôn tập văn học 446
NỘI DUNG
Bài tập 448
xiii
CHƯƠNG 14 KIỂM TRA CHẤP NHẬN 450
14.1 Các loại kiểm tra chấp nhận 450
14.2 Tiêu chí chấp nhận 451
14.3 Lựa chọn tiêu chí chấp nhận 461
14.4 Kế hoạch kiểm tra chấp nhận 461
14.5 Thực hiện kiểm tra chấp nhận 463
14.6 Báo cáo kiểm tra nghiệm thu 464
14.7 Kiểm tra sự chấp nhận trong Lập trình eXtreme 466
14.8 Tóm tắt 467
Bài tập 469
CHƯƠNG 15 ĐỘ TIN CẬY CỦA PHẦN MỀM 47
1
15.1 Độ tin cậy là gì? 471
15.1.1 Lỗi và Thất bại 472
15.1.2 Thời gian 473
15.1.3 Khoảng thời gian giữa các lần hỏng
hóc 474
15.1.4 Đếm số lỗi trong khoảng thời gian định
kỳ
15.1.5 Cường độ lỗi 476 475
15,2 Định nghĩa về độ tin cậy của phần mềm
477 15.2.1 Định nghĩa đầu
tiên về độ tin cậy của phần mềm 477
15.2.2 Định nghĩa thứ hai về độ tin cậy của phần mềm
478
15.2.3 So sánh các định nghĩa về độ tin cậy của phần
mềm 479
15.3 Các yếu tố ảnh hưởng đến độ tin cậy của phần mềm
479
15.4 Các ứng dụng của độ tin cậy phần mềm 481
15.4.1 So sánh các công nghệ kỹ thuật phần mềm 481
15.4.2 Đo lường tiến độ kiểm tra hệ thống 481
15.4.3 Kiểm soát hệ thống trong hoạt động 482
15.4.4 Hiểu rõ hơn về quy trình phát triển phần mềm 482
15,5 Hồ sơ hoạt động 482
15.5.1 Hoạt động 483
15.5.2 Trình bày hồ sơ hoạt động 483
15,6 Các mô hình về độ tin cậy 486
15,7 Tóm tắt 491
Bài tập 494
CHƯƠNG 16 TỔ CHỨC NHÓM KIỂM TRA 49
6
xiv
16.1 Nhóm kiểm tra 496
16.1.1 Nhóm kiểm tra tích hợp 496
16.1.2 Nhóm kiểm tra hệ thống 497
16.2 Nhóm đảm bảo chất lượng phần mềm 499
16.3 Hệ thống phân cấp nhóm 500
NỘI DUNG
16.4 Nhân sự hiệu quả của kỹ sư thử nghiệm 501
16.5 Tuyển dụng kỹ sư kiểm tra 504
16.5.1 Tuyển dụng việc làm 504
16.5.2 Hồ sơ công việc 505
16.5.3 Sơ yếu lý lịch 505
16.5.4 Điều phối Nhóm Phỏng vấn 506
16.5.5 Phỏng vấn 507
16.5.6 Ra quyết định 511
16.6 Giữ lại kỹ sư kiểm tra 511
16.6.1 Con đường sự nghiệp 511
16.6.2 Đào tạo 512
16.6.3 Hệ thống phần thưởng 513
16,7 Xây dựng nhóm 513
16.7.1 Kỳ vọng 513
16.7.2 Nhất quán 514
16.7.3 Chia sẻ thông tin 514
16.7.4 Tiêu chuẩn hóa 514
16.7.5 Môi trường thử nghiệm 514
16,7,6 Nhận biết 515 16,8 Tóm tắt 515
Văn học 516
Bài tập 517
CHƯƠNG 17 CHẤT LƯỢNG PHẦN MỀM 519
17.1 Năm quan điểm về chất lượng phần mềm 519

17.2 Các yếu tố và tiêu chí chất lượng của McCall 523
17.2.1 Yếu tố chất lượng 523
17.2.2 Tiêu chí chất lượng 527
17.2.3 Mối quan hệ giữa các yếu tố chất lượng và tiêu chí 527
17.2.4 Chỉ số chất lượng 530
17.3 Các đặc tính chất lượng của ISO 9126 530
17.4 Tiêu chuẩn chất lượng phần mềm ISO 9000: 2000 534
17.4.1 Các nguyên tắc cơ bản của ISO 9000: 2000 535
17.4.2 Các yêu cầu của ISO 9001: 2000 537
17,5 Tóm tắt 542
Bài tập 545
CHƯƠNG 18 CÁC MÔ HÌNH NĂNG LỰC 546
18.1 Ý tưởng cơ bản trong quy trình phần mềm 546

18.2 Mô hình trưởng thành năng lực 548
18.2.1 Kiến trúc CMM 549
xv
18.2.2 Năm mức độ trưởng thành và các lĩnh vực quá trình chính 550
18.2.3 Các đặc điểm chung của các thực hành chính 553
18.2.4 Ứng dụng CMM 553
18.2.5 Tích hợp mô hình trưởng thành năng lực (CMMI) 554
NỘI DUNG
18.3 Cải tiến quy trình kiểm tra 754
18.4 Kiểm tra độ trưởng thành Mô hình 774
18,5 Tóm tắt 790
Bài tập 793
CHÚ GIẢI THUẬT NGỮ 581
INDEX 600
xvi
PREFACE
karmany eva dhikaras te; ma phalesu kadachana; ma karmaphalahetur
bhur; ma te sango stv akarmani.
Quyền của bạn là chỉ làm việc; nhưng không bao giờ đến hoa quả của
nó; có thể bạn không bị thúc đẩy bởi thành quả của các hành động;
cũng không để cho sự chấp trước của bạn hướng tới không hành
động. -Bhagavad Gita
Chúng tôi đã chứng kiến sự phát triển vượt bậc trong ngành công
nghiệp phần mềm trong 25 năm qua. Các ứng dụng phần mềm đã
phát triển mạnh mẽ từ các lĩnh vực xử lý dữ liệu ban đầu và tính toán
khoa học vào cuộc sống hàng ngày của chúng ta theo cách mà chúng
ta không nhận ra rằng một số loại phần mềm thực thi khi chúng ta
làm một việc gì đó bình thường, chẳng hạn như gọi điện thoại, khởi
động ô tô, bật lò vi sóng và thanh toán bằng thẻ ghi nợ. Quy trình sản
xuất phần mềm phải đáp ứng hai thách thức lớn. Đầu tiên, các quy
trình phải tạo ra phần mềm chi phí thấp trong thời gian ngắn để các
tập đoàn có thể duy trì khả năng cạnh tranh. Thứ hai, các quy trình
phải tạo ra phần mềm có thể sử dụng được, đáng tin cậy và an toàn;
những thuộc tính này thường được gọi là thuộc tính chất lượng. Chất
lượng phần mềm tác động đến một số yếu tố quan trọng trong cuộc
sống hàng ngày của chúng ta, chẳng hạn như nền kinh tế, an ninh cá
nhân và quốc gia, sức khỏe và sự an toàn.
Cách đây 25 năm, kiểm thử chiếm khoảng 50% tổng thời gian
và hơn 50% tổng số tiền chi tiêu cho một dự án phát triển phần mềm
— và điều này vẫn đúng cho đến ngày nay. Những ngày đó, ngành
công nghiệp phần mềm còn nhỏ hơn nhiều, và học viện đã cung cấp
một khóa học toàn diện, duy nhất mang tên Kỹ thuật phần mềm để
đào tạo sinh viên đại học về những kiến thức cơ bản của phát triển
phần mềm. Mặc dù kiểm thử phần mềm đã là một phần của tài liệu kỹ
thuật phần mềm cổ điển trong nhiều thập kỷ, nhưng chủ đề này hiếm
khi được đưa vào chương trình giảng dạy đại học chính thống. Một số
trường đại học đã bắt đầu cung cấp một lựa chọn về kỹ thuật phần
mềm bao gồm ba khóa học chuyên biệt, đó là Đặc tả yêu cầu, Thiết
kế phần mềm và Kiểm tra và Đảm bảo chất lượng. Ngoài ra, một số
trường đại học đã giới thiệu các chương trình cấp bằng đại học và sau
đại học đầy đủ về kỹ thuật phần mềm.
Xem xét tác động của chất lượng phần mềm, hoặc sự thiếu hụt
của nó, chúng tôi nhận thấy rằng giáo dục kiểm thử phần mềm đã
không được thực hiện đúng mức. Lý tưởng nhất, nghiên cứu nên dẫn
đến việc phát triển các công cụ và phương pháp luận để sản xuất phần
mềm chất lượng cao, chi phí thấp và sinh viên phải được đào tạo về
các nguyên tắc cơ bản về thử nghiệm. Nói cách khác, nghiên cứu
kiểm thử phần mềm không nên chỉ mang tính chất hàn lâm mà phải
cố gắng trở nên thiết thực đối với người tiêu dùng trong ngành. Tuy
nhiên, trên thực tế, có
xvii
LỜI NÓI ĐẦU
là một khoảng cách lớn giữa các kỹ năng kiểm tra cần thiết trong
ngành và những gì được giảng dạy và nghiên cứu trong các trường
đại học.
Mục tiêu của chúng tôi là cung cấp cho học sinh và giáo viên
một bộ tài liệu giáo dục toàn diện bao gồm những phát triển cơ bản
trong lý thuyết kiểm tra và các thực hành kiểm tra phổ biến trong
ngành. Chúng tôi dự định cung cấp cho sinh viên “bức tranh toàn
cảnh” về kiểm tra và đảm bảo chất lượng, bởi vì khái niệm chất lượng
phần mềm khá rộng. Có nhiều loại hệ thống phần mềm khác nhau với
những đặc điểm phức tạp của riêng chúng. Chúng tôi đã không cố
gắng giải quyết cụ thể các thách thức thử nghiệm của họ. Thay vào
đó, chúng tôi đã trình bày lý thuyết và thực hành thử nghiệm như
những bước đệm rộng rãi giúp sinh viên hiểu và phát triển các thực
hành thử nghiệm cho các hệ thống phức tạp hơn.
Chúng tôi quyết định viết cuốn sách này dựa trên kinh nghiệm
giảng dạy và công nghiệp của chúng tôi trong việc kiểm tra và đảm
bảo chất lượng phần mềm. Trong 15 năm qua, Sagar đã thường xuyên
giảng dạy kỹ thuật phần mềm và kiểm thử phần mềm, trong khi Piyu
đã thực hiện kiểm tra thực hành và quản lý các nhóm kiểm tra để
kiểm tra bộ định tuyến, thiết bị chuyển mạch, mạng dữ liệu không
dây, mạng lưu trữ và thiết bị phòng chống xâm nhập. . Kinh nghiệm
của chúng tôi đã giúp chúng tôi lựa chọn và cấu trúc nội dung của
cuốn sách này để làm cho nó phù hợp như một cuốn sách giáo khoa.
Ai nên đọc cuốn sách này?
xviii
Chúng tôi đã viết cuốn sách này để giới thiệu cho sinh viên và các
chuyên gia phần mềm những ý tưởng cơ bản trong lý thuyết kiểm
thử, kỹ thuật kiểm thử, thực hành kiểm thử và đảm bảo chất lượng.
Sinh viên đại học về kỹ thuật phần mềm, khoa học máy tính và kỹ
thuật máy tính chưa có kinh nghiệm trước trong ngành công nghiệp
phần mềm sẽ được giới thiệu về chủ đề này theo cách thức từng bước.
Các học viên cũng sẽ được hưởng lợi từ cách trình bày có cấu trúc và
tính chất toàn diện của tài liệu. Học viên cao học có thể sử dụng cuốn
sách như một nguồn tài liệu tham khảo. Sau khi đọc toàn bộ cuốn
sách, người đọc sẽ hiểu thấu đáo về các chủ đề sau:
Cơ bản về lý thuyết và khái niệm thử nghiệm
Các phương pháp hỗ trợ sản xuất phần mềm chất lượng
Kỹ thuật kiểm thử phần mềm
Các mô hình vòng đời của các yêu cầu, khuyết tật, trường hợp thử
nghiệm và kết quả thử nghiệm
Các mô hình quy trình cho đơn vị, tích hợp, hệ thống và thử nghiệm
chấp nhận
Xây dựng các nhóm kiểm tra, bao gồm tuyển dụng và giữ chân các
kỹ sư kiểm tra
Mô hình chất lượng, mô hình thành thục năng lực, mô hình trưởng
thành thử nghiệm và mô hình cải tiến quy trình thử nghiệm
Cuốn sách này nên được đọc như thế nào?
Mục đích của cuốn sách này là dạy cách thực hiện kiểm thử phần
mềm. Chúng tôi trình bày một số tài liệu cơ bản cần thiết trong
Chương 1 và lưu cách trình bày của phần mềm
xix
câu hỏi chất lượng cho phần sau của cuốn sách. Rất khó để thảo luận
một cách thông minh đối với những người mới bắt đầu về chất lượng
phần mềm có ý nghĩa như thế nào cho đến khi người ta có một cảm
giác chắc chắn về những gì kiểm thử phần mềm thực hiện. Tuy nhiên,
những người thực hành có nhiều kinh nghiệm kiểm thử có thể chuyển
sang Chương 17, có tên là “Chất lượng phần mềm”, ngay sau Chương
1.
Có ba cách khác nhau để đọc cuốn sách này tùy thuộc vào sở thích
của ai đó. Đầu tiên, những ai quan tâm đến các khái niệm kiểm thử
phần mềm và muốn áp dụng các ý tưởng này nên đọc Chương 1
(“Các khái niệm cơ bản và sơ bộ”), Chương 3 (“Kiểm thử đơn vị”),
Chương 7 (“Kiểm thử tích hợp hệ thống”) và Chương 8–14, liên quan
đến kiểm tra mức hệ thống. Thứ hai, những người quản lý kiểm tra
quan tâm đến việc cải thiện hiệu quả kiểm tra của nhóm của họ có thể
đọc Chương 1, 3, 7, 8–14, 16 (“Tổ chức nhóm kiểm tra”), 17 (“Chất
lượng phần mềm”) và 18 (“Mô hình trưởng thành” ). Thứ ba, người
mới bắt đầu nên đọc cuốn sách từ đầu đến cuối.
Ghi chú cho người hướng dẫn
Cuốn sách có thể được sử dụng như một văn bản trong một khóa học
giới thiệu về kiểm thử phần mềm và đảm bảo chất lượng. Một trong
những tác giả đã sử dụng nội dung của cuốn sách này trong một khóa
học đại học mang tên Kiểm thử và Đảm bảo Chất lượng Phần mềm
trong vài năm tại Đại học Waterloo. Một khóa học giới thiệu về kiểm
thử phần mềm có thể bao gồm các phần được chọn từ hầu hết các
chương ngoại trừ Chương 16. Đối với một khóa học tập trung nhiều
hơn vào các kỹ thuật kiểm thử hơn là các quy trình, chúng tôi khuyên
bạn nên chọn Chương 1 (“Khái niệm cơ bản và sơ bộ”) đến 15 (“ Độ
tin cậy của phần mềm ”). Khi được sử dụng như một văn bản bổ sung
trong khóa học kỹ thuật phần mềm, các phần được chọn từ các
chương sau có thể giúp sinh viên thấm nhuần các khái niệm cơ bản
trong kiểm thử phần mềm:
Chương 1: Các khái niệm cơ bản và sơ bộ
Chương 3: Kiểm thử đơn vị
Chương 7: Kiểm thử tích hợp hệ thống
Chương 8: Hạng mục Kiểm tra Hệ thống
Chương 14: Kiểm tra chấp nhận
Các tài liệu bổ sung cho người hướng dẫn có tại trang web Wiley sau:
http: /www.wiley.com/sagar.
Sự nhìn nhận
Trong quá trình chuẩn bị cuốn sách này, chúng tôi đã nhận được sự
ủng hộ của nhiều người, bao gồm nhà xuất bản, các thành viên trong
gia đình chúng tôi, bạn bè và đồng nghiệp của chúng tôi. Sự hỗ trợ đã
được thực hiện dưới nhiều hình thức khác nhau. Đầu tiên, chúng tôi
muốn cảm ơn các biên tập viên của chúng tôi, cụ thể là Anastasia
xx
Wasko, Val Moliere, Whitney A. Lesch, Paul Petralia và Danielle
Lacourciere, những người đã hướng dẫn chúng tôi rất nhiều về
chuyên môn và kiên nhẫn trả lời các câu hỏi khác nhau của chúng tôi.
Bạn của chúng tôi, Tiến sĩ Alok Patnaik đã đọc toàn bộ bản thảo và
đưa ra nhiều đề xuất để cải thiện chất lượng trình bày của cuốn sách;
chúng tôi cảm ơn anh ấy vì
LỜI NÓI ĐẦU
tất cả nỗ lực và động viên của anh ấy. Tác giả thứ hai, Piyu Tripathy,
muốn cảm ơn các đồng nghiệp cũ của mình tại Nortel Networks,
Cisco Systems và Airvana Inc., và các đồng nghiệp hiện tại tại NEC
Laboratories Hoa Kỳ.
Cuối cùng, sự hỗ trợ của bố mẹ vợ, bố mẹ chồng và các đối tác của
chúng tôi đáng được đề cập đặc biệt. Tôi, Piyu Tripathy, muốn cảm
ơn người vợ thân yêu Leena của tôi, người đã gánh vác nhiều công
việc gia đình và gia đình để cho tôi thời gian mà tôi cần để viết cuốn
sách này. Và tôi, Sagar Naik, xin cảm ơn người vợ yêu thương Alaka
của tôi vì sự ủng hộ vô giá của cô ấy và đã luôn ở bên cạnh tôi. Tôi
cũng muốn cảm ơn những cô con gái quyến rũ của tôi, Monisha và
Sameeksha, và cậu con trai thú vị, Siddharth, đã thấu hiểu chúng khi
tôi viết cuốn sách này. Tôi biết ơn anh trai tôi, Gajapati Naik, vì tất cả
sự hỗ trợ của anh ấy. Chúng tôi rất vui vì giờ đây chúng tôi có nhiều
thời gian hơn cho gia đình và bạn bè.
Kshirasagar Naik
Đại học Waterloo Waterloo
Priyadarshi Tripathy
NEC Laboratories America, Inc. Princeton
LISTOFFIGURES
1.1 Chu kỳ Shewhart 2
1,2 Sơ đồ Ishikawa 4
1,3 Ví dụ về các trường hợp thử nghiệm cơ bản 11
1,4 Ví dụ về trường hợp thử nghiệm với chuỗi < đầu vào, kết quả mong đợi > 12
1,5 Tập hợp con của miền đầu vào thực hiện một tập hợp con của hành vi 14
chương trình
1,6 Các hoạt động khác nhau trong thử nghiệm chương trình 14
1,7 Các giai đoạn phát triển và thử nghiệm trong mô hình V 16
1,8 Kiểm thử hồi quy ở các cấp độ kiểm thử phần mềm khác nhau. (Từ tham
chiếu 41.
© 2005 John Wiley & Sons.) 17
2.1 Thực thi một chương trình với một tập con của miền đầu vào 32
2,2 Ví dụ về lựa chọn đường dẫn không phù hợp 35
2.3 Các cách khác nhau để so sánh sức mạnh của các phương pháp thử nghiệm: (
a ) tạo ra tất cả các trường hợp thử nghiệm
sản xuất bằng phương pháp khác; ( b ) các tập kiểm tra có các phần tử chung.43
2,4 Bối cảnh áp dụng thử nghiệm đầy đủ 44
3.1 Các bước trong quy trình xem xét mã 55
3.2 Môi trường thử nghiệm đơn vị động 63
3,3 Quy trình đầu tiên thử nghiệm trong XP. (Từ tài liệu tham khảo 24. © 2005 72
IEEE.)
3,4 Mã giả mẫu để thực hiện kiểm tra đơn vị 73
3.5 Khẳng định khẳng định () ném một ngoại lệ 75
3.6 Bộ thử nghiệm mẫu 76
4.1 Quy trình tạo dữ liệu đầu vào kiểm tra để kiểm tra luồng kiểm soát 90
4.2 Các ký hiệu trong CFG 91
4.3 Chức năng mở ba tệp 91
4.4 Biểu diễn CFG cấp cao của openfiles (). Ba nút được đánh số
1, 2 và 3. 92
4,5 Biểu diễn CFG chi tiết của openfiles (). Các số 1–21 là các nút 93
4,6 Hàm tính giá trị trung bình của các số nguyên đã chọn trong một mảng.
Chương trình này là sự điều chỉnh của “Hình 2. Một chương trình mẫu”
trong ref. 10. (Được sự cho phép
xxii
từ Hiệp hội Máy tính Úc.) 94
4,7 Một đại diện CFG của ReturnAverage (). Các số 1–13 là các nút. 95
4.8 Các mũi tên đứt nét thể hiện các nhánh không được bao hàm bởi câu lệnh
bao gồm trong
Bảng 4.4 99
4,9 CFG một phần với ( a ) phép toán OR và ( b ) phép toán AND 100
4,10 Ví dụ về một đường dẫn từ Hình 4.7 102
4,11 Vị từ đường dẫn cho đường dẫn trong Hình 4.10 102
4,12 Phương pháp trong Java để giải thích sự thay thế biểu tượng [11] 103
4,13 Biểu thức vị từ đường dẫn cho đường dẫn trong Hình 4.10 105
4,14 Một ví dụ khác về đường dẫn từ Hình 4.7 105
4,15 Biểu thức vị từ đường dẫn cho đường dẫn được hiển thị trong Hình 4.14 106
4,16 Dữ liệu đầu vào thỏa mãn các ràng buộc của Hình 4.13 106
xxi
DANH MỤC CÁC HÌNH
4,17 Quy trình tìm kiếm nhị phân 111
5.1 Chuỗi tính toán cho thấy sự bất thường của luồng dữ liệu 113
5.2 Sơ đồ chuyển trạng thái của một biến chương trình. (Từ bản 115
tham khảo 2. © 1979 IEEE.)
5.3 Định nghĩa và sử dụng các biến 117
5,4 Biểu đồ luồng dữ liệu của ví dụ ReturnAverage () 118
5.5 Mối quan hệ giữa các tiêu chí kiểm tra DF (luồng dữ liệu).
(Từ tham chiếu 4. © 1988
IEEE.) 125
5,6 Mối quan hệ giữa các tiêu chí kiểm tra FDF (luồng dữ liệu
khả thi).
(Từ tham chiếu 4. © 1988 IEEE.) 127
5,7 Giới hạn của các kỹ thuật phát hiện lỗi khác nhau 128
5,8 Quy trình tìm kiếm nhị phân 133
5.9 Quy trình tìm kiếm nhị phân đã sửa đổi 133
6.1 Minh họa khái niệm miền chương trình 137
6.2 Một chức năng để giải thích các miền chương trình 139
6,3 Biểu diễn đồ thị luồng điều khiển của hàm trong Hình 6.2 139
6.4 Các miền thu được từ các vị từ được diễn giải trong Hình 140
6.3
6,5 Các dự đoán xác định miền TT trong Hình 6.4 141
6.6 Điểm BẬT và TẮT 146
6,7 Sự dịch chuyển ranh giới dẫn đến miền giảm (bất bình đẳng 147
đóng)
6,8 Sự dịch chuyển ranh giới dẫn đến miền mở rộng (bất bình 149
đẳng đóng)
6.9 Ranh giới nghiêng (bất bình đẳng đóng) 149
6.10 Lỗi đóng cửa (bất bình đẳng đóng) 150
6,11 Sự dịch chuyển ranh giới dẫn đến miền giảm (bất bình đẳng 151
mở)
6.12 Sự dịch chuyển ranh giới dẫn đến miền mở rộng (bất bình 152
đẳng mở)
6.13 Ranh giới nghiêng (bất bình đẳng mở) 153
6.14 Lỗi đóng (bất bình đẳng mở) 153
6.15 Biên giới bình đẳng 154
6.16 Miền D 1 , D 2 và D 3 157
7.1 Hệ thống phân cấp mô-đun với ba cấp độ và bảy mô-đun 168
7.2 Tích hợp từ trên xuống của mô-đun A và B 169
7.3 Tích hợp từ trên xuống của các mô-đun A, B và D 169
7.4 Tích hợp từ trên xuống của các mô-đun A, B, D và C 169
7,5 Tích hợp từ trên xuống của các mô-đun A, B, C, D và E 170
7.6 Tích hợp từ trên xuống của các mô-đun A, B, C, D, E và F 170
7.7 Tích hợp từ trên xuống của các mô-đun A, B, C, D, E, F và 170
G
7.8 Tích hợp từ dưới lên của các mô-đun E, F và G 171
7.9 Tích hợp từ dưới lên của các mô-đun B, C và D với E, F và 172
G
7.10 Tích hợp từ dưới lên của mô-đun A với tất cả các mô-đun 172
khác
7,11 Quy trình ECO phần cứng 179
7.12 Quy trình ECO phần mềm 180
7.13 Hệ thống phân cấp mô-đun của hệ thống phần mềm 190
8.1 Các loại kiểm tra hệ thống 193
8.2 Các loại bài kiểm tra cơ bản 194
8,3 Các loại kiểm tra chức năng 197
8,4 Các loại kiểm tra độ bền 205
8.5 Mạng truy cập vô tuyến 1xEV-DO điển hình. (Được sự cho 206
phép của Airvana, Inc.)
xxiv
9.1 Hộp lựa chọn tần số của đặc điểm kỹ thuật Bluetooth 224
9.2 Một phần của mẫu ON479 của T1 chung — 2001, do 227
CCRA xuất bản
DANH MỤC CÁC HÌNH xxiii

9.3 Các biến liên quan đến chức năng 231
9.4 Chức năng trong ngữ cảnh 232
9.5 ( a ) Nhận các giá trị đầu ra từ một vectơ đầu vào và ( b )
lấy một đầu vào
vectơ từ một giá trị đầu ra trong thử nghiệm chức năng 233
9.6 Kiểm tra chức năng nói chung 234
9.7 Hệ thống S với ba biến đầu vào 235
9.8 (a) Quá nhiều đầu vào kiểm tra; (b) một đầu vào được 244
chọn từ mỗi tên miền phụ
9,9 Vàng tiêu chuẩn oracle 253
9.10 Tiên tri tham số 253
9.11 Tiên tri thống kê 254
10.1 Phổ của hệ thống phần mềm 266
10.2 Hệ thống chi phối dữ liệu 266
10.3 Hệ thống kiểm soát chi phối 267
10.4 Kiểu FSM của máy tính xách tay khởi động kép 267
10.5 Tương tác giữa hệ thống và môi trường của nó được mô 268
hình hóa dưới dạng FSM
10,6 PCO trên điện thoại 269
10.7 Mô hình FSM của một PBX 270
10.8 Mô hình FSM của PBX 271
10.9 Tương tác của trình tự thử nghiệm với SUT 274
10.10 Trường hợp thử nghiệm bắt nguồn từ chuyến tham quan 275
chuyển tiếp
10.11 Mô hình khái niệm về trường hợp kiểm thử với xác minh 278
trạng thái
10.12 Máy trạng thái hữu hạn G 1 (Từ tham chiếu 5. © 1997 281
IEEE.)
10.13 Cây UIO cho G 1 trong Hình 10.12. (Từ bản tham khảo 5. 282
© 1997 IEEE.)
10.14 Xác định các trình tự UIO trên cây UIO của Hình 10.13 283
10.15 Máy trạng thái hữu hạn G 2 286
10.16 Phân biệt cây trình tự cho G 2 trong Hình 10.15 286
10.17 FSM không có trình tự phân biệt. (Từ tài liệu tham khảo.
11. © 1994
IEEE.) 287
10.18 Cây DS cho FSM (Hình 10.17) 288
10.19 Tóm tắt về N -entity trong kiến trúc tham chiếu OSI 291
10.20 Kiến trúc thử nghiệm cục bộ trừu tượng 292
10.21 Kiến trúc kiểm tra bên ngoài trừu tượng 292
10.22 Kiến trúc cục bộ 293
10.23 Kiến trúc phân tán 293
10.24 Kiến trúc phối hợp 294
10.25 Kiến trúc từ xa 295
10.26 Cấu trúc của mô-đun trong TTCN-3 297
10.27 Định nghĩa của hai kiểu phụ 297
10.28 Mẫu tham số để xây dựng thông báo sẽ được gửi đi 298
10.29 Mẫu tham số để xây dựng thông báo sẽ nhận được 298
10.30 Kiểm tra (a) máy tính hàm căn bậc hai (SRF) và ( b )
cổng giữa
máy kiểm tra và máy tính SRF 299
10.31 Xác định loại cổng 300
10.32 Liên kết cổng với thành phần 300
10.33 Trường hợp thử nghiệm để kiểm tra máy tính SRF 301
10.34 Thực thi trường hợp thử nghiệm 302
10.35 So sánh chuyển đổi trạng thái của FSM và EFSM 303
10.36 Truy cập có kiểm soát vào cửa 304
10,37 SDL / GR 305
DANH MỤC CÁC HÌNH
10,38Đặc điểm kỹ thuật hành vi kiểm soát cửa 306
10,39Đặc điểm kỹ thuật hành vi kiểm soát cửa 307
10,40Chuyến tham quan chuyển tiếp từ hệ thống kiểm soát cửa 309
của Hình 10.38 và 10.39
10,41Kiểm tra hệ thống kiểm soát cửa ra vào 309
10.42Hành vi đầu ra và đầu vào thu được từ chuyến tham quan 310
chuyển tiếp của Hình 10.40
10.43Kiểm tra hành vi thu được bằng cách tinh chỉnh nếu một310
xxvi
phần trong Hình 10.42
10.44Kiểm tra hành vi có thể nhận được các sự kiện không mong 311
muốn (xuất phát từ Hình 10.43)
10.45Hành vi cốt lõi của trường hợp thử nghiệm để thử nghiệm
hệ thống kiểm soát cửa (bắt nguồn từ
Hình 10.44) 312
10.46Giao diện người dùng của ATM 314
10.47Liên kết các nút với các tùy chọn của người dùng 314
10.48Ràng buộc các nút với số tiền mặt 315
10.49FSM G 318
10,50FSM H 318
10,51FSM K 319
10,52FSM không xác định 319
11.1 Biểu đồ chuyển đổi trạng thái của yêu cầu 323
11,2 Cấu trúc bộ thử nghiệm 336
11.3 Dịch vụ liên kết giữa các dịch vụ FR và ATM 337
11.4 Chuyển đổi FR sang tế bào ATM 338
11,5 Cấu trúc bộ thử nghiệm FrAtm 342
11,6 Sơ đồ chuyển đổi trạng thái của một ca kiểm thử 345
11,7 Biểu đồ chuyển đổi trạng thái của kết quả trường hợp thử 349
nghiệm
12.1 Khái niệm về chiến lược thực thi thử nghiệm dựa trên chu 363
kỳ
12,2 Biểu đồ Gantt cho dự án thử nghiệm liên kết dịch vụ FR – 390
ATM
12.3 Tiêu chí rộng của việc đánh giá công cụ tự động hóa thử 393
nghiệm
12.4 Hướng dẫn lựa chọn thử nghiệm cho tự động hóa 396
12,5 Đặc điểm của các trường hợp kiểm thử tự động 397
12,6 Sáu bước chính trong trường hợp kiểm thử tự động 399
12,7 Các thành phần của cơ sở hạ tầng tự động hóa 401
13.1 Biểu đồ chuyển đổi trạng thái biểu diễn vòng đời của 409
khuyết tật
13,2 Dự kiến thực hiện các trường hợp thử nghiệm hàng tuần ở 417
dạng biểu đồ tích lũy
13.3 Chỉ số PAE của Bazooka (PE: thực thi dự kiến; AE: thực
thi)
dự án 421
13.4 Biểu đồ Pareto cho sự phân bố khuyết tật được trình bày 431
trong Bảng 13.12
13,5 Sơ đồ nguyên nhân - ảnh hưởng cho DCA 434
15.1 Mối quan hệ giữa MTTR, MTTF và MTBF 475
15,2 Biểu diễn đồ thị hồ sơ hoạt động của hệ thống thông tin thư 484
viện
15.3 Cường độ hỏng hóc λ là hàm của lỗi tích lũy μ ( λ 0 = 9 lỗi
15.4 trên một đơn vị thời gian, ν 0 = 500 lỗi, θ = 0. 0075 )
Cường độ lỗi λ như hàm của thời gian thực hiện τ ( λ 0 = 9 488
lỗi trên một đơn vị thời gian, ν 0 = 500 lỗi, θ = 0. 0075 ) 490
thời gian, ν 0 = 500 lần hỏng hóc, θ = 0 . 0075) 490
16.1 Cấu trúc của các nhóm kiểm tra 498
16.2 Cấu trúc của nhóm đảm bảo chất lượng phần mềm 499
16.3 Hệ thống phân cấp nhóm kiểm tra 500
16.4 Sáu giai đoạn của quy trình tuyển dụng hiệu quả 505
15.5 Lỗi tích lũy μ như hàm của thời gian thực hiện τ ( λ 0 = 9 lỗi
trên mỗi đơn vị
DANH SÁCH CÁC HÌNH xxv
16.5 Tổ chức kiểm tra hệ thống như một phần của phát triển
518
17.1 Mối quan hệ giữa các yếu tố chất lượng và chỉ tiêu chất lượng
[6] 528
17.2 Mô hình chất lượng mẫu ISO 9126 tinh chỉnh các tính năng
của tiêu chuẩn thành
đặc điểm phụ. (Từ tham chiếu 4. © 1996 IEEE.) 532
18.1 Cấu trúc CMM. (Từ ref. 3. © 2005 John Wiley & Sons.)
549
18.2 Các mức độ trưởng thành của SW-CMM. (Từ ref. 3 © 2005
John Wiley & Sons.) 550
18.3 Cấu trúc năm cấp của TMM. (Từ ref. 5. © 2003 Springer.)
568
LISTOFTABLES
3.1 Hệ thống phân cấp của tài liệu hệ thống 56
3.2 Danh sách kiểm tra đánh giá mã 58
3,3 Phép đo độ phức tạp McCabe 79
4.1 Ví dụ về Đường dẫn trong CFG của Hình 4.7 95
4.2 Tên miền đầu vào của openfiles () 97
4.3 Đầu vào và Đường dẫn trong openfiles () 97
4.4 Các đường dẫn cho Báo cáo Mức độ bao phủ của CFG 98
trong Hình 4.7
4,5 Các đường dẫn đến phạm vi phủ sóng chi nhánh của CFG 99
trong Hình 4.7
4,6 Hai trường hợp cho Báo cáo đầy đủ và Phạm vi chi nhánh
của CFG của
Hình 4.9 a 101
4,7 Diễn giải vị ngữ đường dẫn của đường dẫn trong Hình 4.10104
4.8 Diễn giải vị ngữ đường dẫn của đường dẫn trong Hình 4.14105
4,9 Dữ liệu kiểm tra cho tuyên bố và phạm vi chi nhánh 106
5.1 Bộ nút Def () và c-use () trong Hình 5.4 120
5.2 Dự đoán và p-use () Tập hợp các cạnh trong Hình 5.4 121
6.1 Hai cách diễn giải câu lệnh if () thứ hai trong Hình 6.2 140
6.2 Phát hiện dịch chuyển ranh giới dẫn đến giảm tên miền
(Bất bình đẳng đóng) 148
6,3 Phát hiện dịch chuyển ranh giới dẫn đến tên miền được mở
rộng
(Bất bình đẳng đóng) 149
6.4 Phát hiện độ nghiêng ranh giới (Bất bình đẳng đóng) 150
6,5 Phát hiện lỗi đóng cửa (Bất bình đẳng đóng) 151
6.6 Phát hiện dịch chuyển ranh giới dẫn đến giảm tên miền 151
(Bất bình đẳng mở)
6,7 Phát hiện dịch chuyển ranh giới dẫn đến miền được mở 152
rộng (Bất bình đẳng mở)
6,8 Phát hiện độ nghiêng ranh giới (Bất bình đẳng mở) 153
6.9 Phát hiện lỗi đóng cửa (Bất bình đẳng mở) 154
7.1 Mẫu yêu cầu đăng ký 166
7.2 Ví dụ về ma trận tương thích phần cứng / phần mềm 178
7.3 Khung cho Kế hoạch SIT 181
7.4 Khung tiêu chí đầu vào để bắt đầu tích hợp hệ thống 182
7,5 Khung tiêu chí thoát tích hợp hệ thống 182
8.1 Các chức năng của EMS 199
8.2 Cơ quan phê duyệt theo quy định của các quốc gia khác 217
nhau
9.1 Số lượng giá trị đặc biệt của đầu vào cho mô-đun FBS của 230
Hình 9.1
9.2 Các miền đầu vào và đầu ra của các chức năng của P trong 234
Hình 9.6
9.3 Các trường hợp kiểm tra theo cặp cho Hệ thống S 236
9.4 L 4 ( 2 3 ) Mảng trực giao 236
9.5 Mảng trực giao thường được sử dụng 237
9,6 Các giá trị khác nhau cần được kiểm tra trong các kết hợp 238
xxvii
xxviii DANH SÁCH CÁC BẢNG
9,7 L 9 ( 3 4 ) Mảng trực giao 239
9,8 L 9 ( 3 ) Mảng trực giao sau các yếu tố ánh xạ
4
239
9,9 Các trường hợp thử nghiệm được tạo sau khi ánh xạ các 240
mức còn lại
9.10 Các trường hợp thử nghiệm được tạo để bao gồm từng loại 246
tương đương
9,11 Bảng Quyết định Bao gồm Bộ Điều kiện và Hiệu lực 248
9,12 Thanh toán Bảng quyết định tính toán với các giá trị cho 250
mỗi quy tắc
9.13 Thanh toán Bảng quyết định tính toán sau khi giảm cột 251
9.14 Bảng quyết định để tính toán thanh toán 252
10.1 PCO để kiểm tra tổng đài điện thoại 270
10,2 Tập hợp các quốc gia trong FSM của Hình 10.8 272
10.3 Bộ đầu vào và đầu ra trong FSM của Hình 10.8 272
10.4 Chuyến tham quan chuyển tiếp bao gồm tất cả các quốc gia 276
trong Hình 10.8
10,5 Chuyển đổi trạng thái không được bao gồm trong các277
chuyến tham quan chuyển tiếp của Bảng 10.4
10,6 Chuyến tham quan chuyển tiếp bao gồm tất cả các chuyển 277
đổi trạng thái trong Hình 10.8
10,7 Chuỗi UIO có độ dài tối thiểu thu được từ Hình 10.14 284
10,8 Ví dụ về khối nhà nước 284
10,9 Đầu ra của FSM G 2 trong Đáp ứng với Trình tự đầu vào 11 287
ở các quốc gia khác nhau
10.10Chuỗi đầu ra được tạo bởi FSM của Hình 10.17 như là 289
phản hồi cho W 1
10,11Chuỗi đầu ra được tạo bởi FSM của Hình 10.17 như là 289
phản hồi cho W 2
10.12Trình tự thử nghiệm cho chuyển đổi trạng thái ( D , A , a / 290
x ) của FSM trong Hình 10.17
11.1 Ma trận bảo hiểm [ A ij ] 322
11,2 Tóm tắt trường lược đồ yêu cầu 324
11.3 Thông tin tài liệu thay đổi kỹ thuật 329
11.4 Đặc điểm của Thông số kỹ thuật chức năng có thể kiểm tra 333
11,5 Ánh xạ các tham số FR QoS sang tham số ATM QoS 340
11,6 Tóm tắt lược đồ trường hợp thử nghiệm 346
11,7 Tóm tắt lược đồ bộ thử nghiệm 348
11,8 Tóm tắt lược đồ kết quả kiểm tra 348
12.1 Phác thảo Kế hoạch Kiểm tra Hệ thống 356
12,2 Thiết bị cần được mua sắm 360
12.3 Tiêu chí đầu vào cho chu kỳ kiểm tra hệ thống đầu tiên 368
12.4 Số lần kiểm tra không thành công để bắt đầu RCA trong 374
chu kỳ kiểm tra 1
12,5 Số lần kiểm tra không thành công để bắt đầu RCA trong 375
chu kỳ kiểm tra 2
12,6 Ước tính nỗ lực thử nghiệm cho liên kết dịch vụ FR-ATM 379
PVC
12,7 Biểu mẫu cho tính toán điểm chức năng chưa điều chỉnh 382
12,8 Các yếu tố ảnh hưởng đến nỗ lực phát triển 382
12,9 Mối quan hệ thực nghiệm giữa các điểm chức năng và LOC383
12.10Hướng dẫn về Nỗ lực Tạo Trường hợp Kiểm tra Thủ công 384
12,11Hướng dẫn về Nỗ lực Thực thi Trường hợp Kiểm tra Thủ386
công
12.12Hướng dẫn ước tính nỗ lực thực hiện hồi quy theo cách thủ
công
Các trường hợp kiểm tra 386
12,13Lợi ích của kiểm tra tự động 391
13.1 Các trạng thái khiếm khuyết được mô hình trong Hình 13.1 410
13,2 Các trường tóm tắt lược đồ khiếm khuyết 412
13.3 Chuyển đổi trạng thái sang năm quốc gia có thể tiếp theo từ 413
trạng thái mở
13.4 Đề cương của Tài liệu Làm việc Thực thi Kiểm tra 416
13,5 Chỉ số EST trong Tuần 4 của Dự án Bazooka 422
13,6 Số liệu EST trong Bazooka được theo dõi trên cơ sở hàng 423
tuần
DANH SÁCH CÁC BẢNG xxix
13.7 Số liệu DAR cho Stinger Project 425
13.8 Trạng thái DRR hàng tuần cho Dự án thử nghiệm Stinger
426
13,9 OD hàng tuần trên cơ sở ưu tiên cho dự án thử nghiệm Stinger
427
13.10 CD hàng tuần được quan sát bởi các nhóm khác nhau cho dự
án thử nghiệm Stinger 427
13.11 ARD Metric cho Bayonet 428
13.12 Dữ liệu thử nghiệm mẫu của Dự án thử nghiệm cưa máy
430
13.13 Khung cho Tiêu chí phát hành Beta 436
13.14 Cấu trúc của Báo cáo Kiểm tra Hệ thống Cuối cùng 438
13,15 Thang điểm cho độ tuổi khiếm khuyết 443
13.16 Tiêm khuyết điểm so với Khám phá trên Dự án Boomerang
443
13.17 Số lượng khiếm khuyết tính theo độ tuổi khiếm khuyết trên
Project Boomerang 444
13.18 Chỉ số ARD cho Dự án thử nghiệm 448
13,19 cho PhAge 449
14.1 Sơ lược về ATP 462
14.2 Thông tin tài liệu ACC 464
14.3 Cấu trúc của Báo cáo tình trạng kiểm tra nghiệm thu
465
14.4 Cấu trúc của Báo cáo Tóm tắt Kiểm tra Nghiệm thu 466
15.1 Ví dụ về Hồ sơ Hoạt động của Hệ thống Thông tin Thư viện
484
17.1 Yếu tố chất lượng của McCall 524
17.2 Phân loại các yếu tố chất lượng của McCall 527
17.3 Tiêu chí Chất lượng của McCall 529
18.1 Yêu cầu đối với các cấp độ trưởng thành khác nhau 564
18.2 Ma trận độ chín thử nghiệm 566
33
CHAPTER
1
BasicConceptsandPreliminaries
Phần mềm giống như entropy. Nó khó nắm bắt, không cân nặng, và
tuân theo định luật thứ hai của nhiệt động lực học, tức là nó luôn
tăng.
—NormanRalphAugustine
1.1 CÁCH MẠNG VỀ CHẤT LƯỢNG
Mọi người tìm kiếm chất lượng trong mọi hiện vật do con người tạo
ra. Chắc chắn, khái niệm chất lượng không bắt nguồn từ hệ thống
phần mềm. Thay vào đó, khái niệm chất lượng có thể đã cũ giống
như nỗ lực của con người trong việc sản xuất hàng loạt các đồ tạo tác
và đồ vật có kích thước lớn. Trong vài thập kỷ qua, một cuộc cách
mạng về chất lượng đã và đang lan nhanh trên toàn thế giới với sự
bùng nổ của Internet. Cạnh tranh toàn cầu, gia công phần mềm, bao
tiêu và ngày càng tăng kỳ vọng của khách hàng đã đưa khái niệm
chất lượng lên hàng đầu. Việc phát triển các sản phẩm chất lượng với
lịch trình chặt chẽ hơn là rất quan trọng để một công ty có thể thành
công trong nền kinh tế toàn cầu mới. Theo truyền thống, nỗ lực cải
tiến chất lượng tập trung vào giai đoạn cuối của chu kỳ phát triển sản
phẩm bằng cách nhấn mạnh vào việc phát hiện và sửa chữa các
khuyết tật. Ngược lại, cách tiếp cận mới để nâng cao chất lượng bao
gồm tất cả các giai đoạn của quá trình phát triển sản phẩm - từ phân
tích yêu cầu đến việc cung cấp sản phẩm cuối cùng cho khách hàng.
Mọi bước trong quá trình phát triển phải được thực hiện theo tiêu
chuẩn cao nhất có thể. Một quy trình chất lượng hiệu quả phải tập
trung vào [1]:
 Quan tâm nhiều đến yêu cầu của khách hàng
 Nỗ lực không ngừng nâng cao chất lượng
 Tích hợp các quy trình đo lường với thiết kế và phát triển sản
phẩm
34 CHƯƠNG 1 CÁC KHÁI NIỆM VÀ NGUYÊN NHÂN CƠ BẢN
 Đẩy khái niệm chất lượng xuống cấp thấp nhất của tổ chức
 Phát triển quan điểm cấp hệ thống với trọng tâm là phương
pháp luận và quy trình
 Loại bỏ lãng phí thông qua cải tiến liên tục
Kiểm thử phần mềm và đảm bảo chất lượng: Lý thuyết và thực hành,
được biên tập bởi Kshirasagar Naik và Priyadarshi Tripathy Bản
quyền © 2008 John Wiley & Sons, Inc.
Một phong trào chất lượng bắt đầu ở Nhật Bản trong những
năm 1940 và 1950 bởi William Edwards Deming, Joseph M. Juran
và Kaoru Ishikawa. Vào khoảng năm 1947, W. Edwards Deming
“cũng đến thăm Ấn Độ, sau đó tiếp tục đến Nhật Bản, nơi ông được
yêu cầu tham gia một phái đoàn thống kê chịu trách nhiệm lập kế
hoạch điều tra dân số Nhật Bản năm 1951” [2], tr. 8. Trong chuyến
thăm Nhật Bản nói trên, Deming đã mời các nhà thống kê đến một
cuộc họp ăn tối và nói với họ tầm quan trọng của họ và những gì họ
có thể làm cho Nhật Bản [3]. Tháng 3 năm 1950, ông trở lại Nhật
Bản theo lời mời của Giám đốc điều hành Kenichi Koyanagi của
Hiệp hội các nhà khoa học và kỹ sư Nhật Bản (JUSE) để giảng dạy
một khóa học cho các nhà nghiên cứu, công nhân, giám đốc điều
hành và kỹ sư Nhật Bản về phương pháp kiểm soát chất lượng thống
kê (SQC). Kiểm soát chất lượng bằng thống kê là một ngành học dựa
trên các phép đo và số liệu thống kê. Các quyết định được đưa ra và
các kế hoạch được phát triển dựa trên việc thu thập và đánh giá dữ
liệu thực tế dưới dạng thước đo, thay vì trực giác và kinh nghiệm.
Các phương pháp SQC sử dụng bảy công cụ quản lý chất lượng cơ
bản: phân tích Pareto, sơ đồ nguyên nhân và kết quả, lưu đồ, biểu đồ
xu hướng, biểu đồ, biểu đồ phân tán và biểu đồ kiểm soát [2].
Vào tháng 7 năm 1950, Deming đã tổ chức một cuộc hội thảo kéo dài
8 ngày dựa trên các phương pháp kiểm soát chất lượng thống kê của
Shewhart [4, 5] cho các kỹ sư và giám đốc điều hành Nhật Bản. Ông
đã giới thiệu chu trình kế hoạch - làm - kiểm tra - hành động (PDCA)
trong buổi hội thảo, mà ông gọi là chu trình Shewhart (Hình 1.1).
Chu trình Shewhart minh họa chuỗi hoạt động sau: thiết lập mục tiêu,
chỉ định chúng cho các mốc có thể đo lường được và đánh giá tiến độ
so với các mốc đó. Các ghi chú bài giảng năm 1950 của Deming đã
35
tạo cơ sở cho một loạt các cuộc hội thảo về phương pháp SQC do
JUSE tài trợ và cung cấp các tiêu chí cho Giải thưởng Deming nổi
tiếng của Nhật Bản. Công việc của Deming đã kích thích một số loại
công nghiệp khác nhau, chẳng hạn như radio, bóng bán dẫn, máy
ảnh, ống nhòm, máy khâu và ô tô.
Từ khoảng năm 1950 đến khoảng năm 1970, các ngành công nghiệp
ô tô ở Nhật Bản, đặc biệt là Toyota Motor Corporation, đã đưa ra một
nguyên tắc sáng tạo để nén khoảng thời gian từ khi khách hàng đặt
hàng đến khi thanh toán qua ngân hàng, được gọi là “nguyên tắc tinh
gọn”. Mục tiêu là giảm thiểu việc tiêu thụ các tài nguyên không tạo
thêm giá trị cho sản phẩm. Nguyên tắc tinh gọn đã được chương trình
Đối tác Mở rộng Sản xuất của Viện Tiêu chuẩn và Công nghệ Quốc
gia (NIST) xác định là “một phương pháp tiếp cận có hệ thống để xác
định và loại bỏ lãng phí thông qua cải tiến liên tục, đưa sản phẩm
theo chiều hướng của khách hàng sự hoàn hảo, ”tr.1. Người ta
thường tin rằng các nguyên tắc tinh gọn đã được bắt đầu ở Nhật Bản
bởi Taiichi Ohno của Toyota [7], nhưng
Henry Ford
Act Plan
Lập kế hoạch —Thiết lập mục tiêu và quy
PDCA trình để mang lại kết quả.
Thực hiện —Thực hiện kế hoạch và đo lường
Check Do hiệu suất của nó.
Kiểm tra — Đánh giá các phép đo và báo
cáo kết quả cho những người ra quyết định.
Hành động — Quyết định những thay đổi cần thiết để cải thiện quy
trình.
Hình 1.1 Chu trình Shewhart.
đã sử dụng các bộ phận của Lean ngay từ khoảng năm 1920, bằng
chứng là trích dẫn sau (Henry Ford, 1926) [61], tr.1:
Một trong những thành tựu đáng chú ý trong việc giữ giá các
sản phẩm Ford ở mức thấp là chu kỳ sản xuất dần dần được rút
ngắn. Một bài báo trong quá trình sản xuất càng dài và càng được di
chuyển nhiều thì chi phí cuối cùng của nó càng lớn.
Khái niệm này đã được phổ biến ở Hoa Kỳ bởi một nghiên
cứu của Viện Công nghệ Massachusetts (MIT) về chuyển động từ
sản xuất hàng loạt sang sản xuất, như được mô tả trong The Machine
That Changed the World, của James P. Womack, Daniel T. Jones và
Daniel Roos, New York: Rawson và Cộng sự, 1990. Tư duy tinh gọn
tiếp tục lan rộng đến mọi quốc gia trên thế giới và các nhà lãnh đạo
đang điều chỉnh các nguyên tắc ngoài sản xuất ô tô, sang hậu cần và
phân phối, dịch vụ, bán lẻ, chăm sóc sức khỏe, xây dựng, bảo trì và
phát triển phần mềm [8].
Nhận xét: Walter Andrew Shewhart là một nhà vật lý, kỹ sư và nhà
thống kê người Mỹ và được biết đến như là cha đẻ của kiểm soát chất
lượng thống kê. Shewhart làm việc tại Phòng thí nghiệm Điện thoại
Bell từ khi thành lập vào năm 1925 cho đến khi nghỉ hưu vào năm
1956 [9]. Công việc của ông được tóm tắt trong cuốn sách Kiểm soát
kinh tế của chất lượng sản phẩm được sản xuất, do McGraw-Hill
xuất bản năm 1931. Năm 1938, công trình của ông thu hút sự chú ý
của nhà vật lý W. Edwards Deming, người đã phát triển một số đề
xuất phương pháp luận của Shewhart ở Nhật Bản từ năm 1950. trở đi
và đặt tên tổng hợp của mình là chu trình Shewhart.
Năm 1954, Joseph M. Juran của Hoa Kỳ đề xuất nâng cao mức độ
quản lý chất lượng từ các đơn vị sản xuất đến toàn bộ tổ chức. Ông
nhấn mạnh tầm quan trọng của tư duy hệ thống bắt đầu từ yêu cầu
sản phẩm, thiết kế, thử nghiệm nguyên mẫu, vận hành thiết bị phù
hợp và phản hồi quy trình chính xác. Hội thảo của Juran cũng trở
thành một phần trong các chương trình giáo dục của JUSE [10].
Juran đã thúc đẩy việc chuyển từ SQC sang TQC (kiểm soát chất
lượng toàn diện) ở Nhật Bản. Điều này bao gồm các hoạt động toàn
công ty và giáo dục về kiểm soát chất lượng (QC), đánh giá, vòng
tròn chất lượng và thúc đẩy các nguyên tắc quản lý chất lượng. Thuật
ngữ TQC được đặt ra bởi một người Mỹ, Armand V. Feigenbaum,
trong cuốn sách Nguyên tắc, Thực hành và Quản trị Kiểm soát Chất
lượng năm 1951 của ông. Nó đã được tái bản vào năm 2004 [11].
Đến năm 1968, Kaoru Ishikawa, một trong những cha đẻ của TQC ở
Nhật Bản, đã phác thảo, như thể hiện trong phần sau, các yếu tố
chính của quản lý TQC [12]:
Chất lượng đi đầu chứ không phải lợi nhuận ngắn hạn.
Khách hàng đến trước chứ không phải nhà sản xuất.
Các quyết định dựa trên sự kiện và dữ liệu.
Ban quản lý có sự tham gia và tôn trọng tất cả nhân viên.
37
Việc quản lý được điều hành bởi các ủy ban chức năng chéo bao gồm
việc lập kế hoạch sản phẩm, thiết kế sản phẩm, mua hàng, sản xuất,
bán hàng, tiếp thị và phân phối.
Ghi chú: Vòng tròn chất lượng là một nhóm công nhân tình nguyện,
thường là các thành viên trong cùng một bộ phận, họ thường xuyên
gặp nhau để thảo luận về các vấn đề và trình bày với cấp quản lý
những ý tưởng của họ để khắc phục chúng. Vòng tròn chất lượng
được bắt đầu ở Nhật Bản vào năm 1962 bởi Kaoru Ishikawa như một
phương pháp cải tiến chất lượng khác. Phong trào ở Nhật Bản được
điều phối bởi JUSE.
Một trong những phương pháp TQC sáng tạo được phát triển ở Nhật
Bản được gọi là Ishikawa hay sơ đồ nguyên nhân và kết quả. Kaoru
Ishikawa phát hiện ra từ dữ liệu thống kê rằng sự phân tán trong chất
lượng sản phẩm đến từ bốn nguyên nhân phổ biến, đó là vật liệu,
máy móc, phương pháp và phép đo, được gọi là 4 Ms (Hình 1.2).
Mũi tên ngang đậm chỉ chất lượng, trong khi mũi tên chéo trong
Hình 1.2 là những nguyên nhân có thể có ảnh hưởng đến chất lượng.
Vật liệu thường khác nhau khi nguồn cung cấp hoặc yêu cầu về kích
thước khác nhau. Máy móc hoặc thiết bị cũng hoạt động khác nhau
tùy thuộc vào sự thay đổi trong các bộ phận của chúng và chúng chỉ
hoạt động tối ưu trong một phần thời gian. Các phương pháp hoặc
quy trình thậm chí còn gây ra những biến thể lớn hơn do thiếu đào
tạo và hướng dẫn viết tay kém. Cuối cùng, các phép đo cũng thay đổi
do thiết bị lạc hậu và hiệu chuẩn không phù hợp. Sự thay đổi trong 4
tham số Ms có ảnh hưởng đến chất lượng của sản phẩm. Sơ đồ
Ishikawa đã ảnh hưởng đến các công ty Nhật Bản để tập trung sự chú
ý kiểm soát chất lượng của họ vào việc cải tiến vật liệu, máy móc,
phương pháp và phép đo.
Phong trào chất lượng toàn diện ở Nhật Bản đã dẫn đến sự tham gia
rộng rãi của ban lãnh đạo cấp cao. Nhiều công ty ở Nhật Bản có
nhiều tài liệu về các hoạt động chất lượng của họ. Các giám đốc điều
hành cấp cao ở Hoa Kỳ hoặc không tin rằng chất lượng quan trọng
hoặc không biết bắt đầu từ đâu cho đến khi National Broadcasting
Corporation (NBC), một mạng lưới truyền hình của Hoa Kỳ, phát
sóng bộ phim tài liệu "Nếu Nhật Bản có thể ... Tại sao chúng ta
không thể?" lúc 9 giờ 30 phút ngày 24 tháng 6 năm 1980 [2]. Bộ
phim tài liệu được sản xuất bởi Clare Crawford-Mason và được kể
bởi Lloyd Dobyns. Mười lăm phút của chương trình được dành cho
Tiến sĩ Deming và công việc của ông. Sau
Materials Machines
Quality
Effect
Methods Measurements
Causes
Hình 1.2 Sơ đồ Ishikawa.
phát sóng, nhiều giám đốc điều hành và lãnh đạo chính phủ nhận ra
rằng việc chú trọng đổi mới vào chất lượng không còn là một lựa
chọn cho các công ty Mỹ mà là một điều cần thiết để kinh doanh
trong một thị trường thế giới cạnh tranh ngày càng mở rộng và khắt
khe hơn. Ford Motor Company và General Motors ngay lập tức áp
dụng phương pháp SQC của Deming vào quy trình sản xuất của họ.
Các công ty khác như Dow Chemical và Hughes Aircraft cũng làm
theo. Triết lý quản lý TQC của Ishikawa đã trở nên phổ biến ở Hoa
Kỳ. Hơn nữa, sự nhấn mạnh vào chất lượng trong các công ty sản
xuất của Mỹ đã khiến Quốc hội Hoa Kỳ thành lập Giải thưởng Chất
lượng Quốc gia Malcolm Baldrige — tương tự như Giải thưởng
Deming ở Nhật Bản — vào năm 1987 để công nhận các tổ chức đạt
được thành tựu về chất lượng và nâng cao nhận thức về tầm quan
trọng của chất lượng xuất sắc như một lợi thế cạnh tranh [6]. Trong
Giải thưởng Quốc gia Baldrige, chất lượng được coi là thứ do khách
hàng xác định và do đó trọng tâm là chất lượng hướng đến khách
hàng. Mặt khác, trong Giải thưởng Deming, chất lượng được xem
như một thứ được các nhà sản xuất xác định bằng cách phù hợp với
các thông số kỹ thuật và do đó, trọng tâm là sự phù hợp với các thông
số kỹ thuật.
39
Ghi chú: Malcolm Baldrige là Bộ trưởng Thương mại Hoa Kỳ từ
năm 1981 cho đến khi ông qua đời trong một vụ tai nạn xe ngựa vào
tháng 7 năm 1987. Baldrige là người đề xuất quản lý chất lượng như
một chìa khóa cho sự thịnh vượng và sức mạnh lâu dài của đất nước
ông. Ông quan tâm cá nhân đến hành động cải tiến chất lượng, cuối
cùng được đặt theo tên ông, và đã giúp soạn thảo một trong những
phiên bản đầu tiên của nó. Để ghi nhận những đóng góp của ông,
Quốc hội đã đặt tên cho giải thưởng này để vinh danh ông.
Theo truyền thống, khái niệm TQC và tinh gọn được áp dụng
trong quá trình sản xuất. Quá trình phát triển phần mềm sử dụng các
khái niệm này như một công cụ khác để hướng dẫn sản xuất phần
mềm chất lượng [13]. Những khái niệm này cung cấp một khuôn khổ
để thảo luận về các vấn đề sản xuất phần mềm. Kiến trúc mô hình
trưởng thành khả năng phần mềm (CMM) [14] được phát triển tại
Viện Kỹ thuật Phần mềm dựa trên các nguyên tắc về chất lượng sản
phẩm đã được phát triển bởi W. Edwards
Deming [15], Joseph M. Juran [16], Kaoru Ishikawa [12], và Philip
Crosby [17].
1.2 CHẤT LƯỢNG PHẦN MỀM
Câu hỏi "Chất lượng phần mềm là gì?" gợi ra nhiều câu trả lời khác
nhau. Chất lượng là một khái niệm phức tạp - nó có nghĩa là những
thứ khác nhau đối với những người khác nhau và nó phụ thuộc nhiều
vào ngữ cảnh. Garvin [18] đã phân tích chất lượng phần mềm được
nhìn nhận như thế nào theo những cách khác nhau trong các lĩnh vực
khác nhau, chẳng hạn như triết học, kinh tế học, tiếp thị và quản lý.
Bài báo của Kitchenham và Pfleeger [60] về chất lượng phần mềm
đưa ra một giải trình ngắn gọn về chất lượng phần mềm. Họ thảo
luận năm quan điểm về chất lượng một cách toàn diện như sau:
Transcendental View: Nó hình dung chất lượng như một thứ có thể
được công nhận nhưng rất khó xác định. Quan điểm siêu việt không
chỉ dành riêng cho chất lượng phần mềm mà đã được áp dụng trong
các lĩnh vực phức tạp khác
của cuộc sống hàng ngày. Ví dụ, Năm 1964, Thẩm phán Potter
Stewart của Tòa án Tối cao Hoa Kỳ, trong khi ra phán quyết về vụ án
Jacobellis kiện Ohio, 378 US 184 (1964), liên quan đến việc bang
Ohio cấm bộ phim Pháp Les Amants (“The Lovers”) về nội dung
khiêu dâm, đã viết “Hôm nay tôi sẽ không cố gắng xác định thêm các
loại tài liệu mà tôi hiểu sẽ được chấp nhận trong mô tả tốc ký đó; và
có lẽ tôi không bao giờ có thể thành công khi làm như vậy một cách
dễ hiểu. Nhưng tôi biết điều đó khi tôi nhìn thấy nó, và hình ảnh
chuyển động liên quan đến trường hợp này không phải vậy ”(nhấn
mạnh thêm).
Chế độ xem của người dùng: Nó coi chất lượng là phù hợp với mục
đích. Theo quan điểm này, trong khi đánh giá chất lượng của một sản
phẩm, người ta phải đặt ra câu hỏi quan trọng: “Sản phẩm có thỏa
mãn nhu cầu và mong đợi của người dùng hay không?”
Quan điểm sản xuất: Ở đây chất lượng được hiểu là sự phù hợp với
đặc điểm kỹ thuật. Mức chất lượng của một sản phẩm được xác định
bởi mức độ mà sản phẩm đó đáp ứng các thông số kỹ thuật của nó.
Quan điểm về sản phẩm: Trong trường hợp này, chất lượng được
xem như gắn liền với các đặc tính vốn có của sản phẩm. Các đặc tính
vốn có của một sản phẩm, đó là các phẩm chất bên trong, quyết định
các phẩm chất bên ngoài của nó.
Quan điểm dựa trên giá trị: Chất lượng, theo quan điểm này, phụ
thuộc vào số tiền khách hàng sẵn sàng trả cho nó.
Khái niệm về chất lượng phần mềm và những nỗ lực để hiểu nó dưới
dạng các đại lượng có thể đo lường được bắt đầu từ giữa những năm
1970. McCall, Richards, và Walters [19] là những người đầu tiên
nghiên cứu khái niệm chất lượng phần mềm về các yếu tố chất lượng
và tiêu chí chất lượng. Yếu tố chất lượng thể hiện đặc tính hành vi
của hệ thống. Một số ví dụ về các yếu tố chất lượng cấp cao là tính
đúng đắn, độ tin cậy, hiệu quả, khả năng kiểm tra, khả năng bảo trì và
khả năng tái sử dụng. Tiêu chí chất lượng là một thuộc tính của yếu
tố chất lượng có liên quan đến phát triển phần mềm. Ví dụ, mô đun là
một thuộc tính của kiến trúc của một hệ thống phần mềm. Một phần
mềm có tính mô-đun cao cho phép các nhà thiết kế đặt các thành
phần gắn kết trong một mô-đun, do đó cải thiện khả năng bảo trì của
hệ thống.
Nhiều mô hình chất lượng phần mềm khác nhau đã được đề xuất để
xác định chất lượng và các thuộc tính liên quan của nó. Những cái có
ảnh hưởng nhất là ISO 9126 [20–22] và CMM [14]. Mô hình chất
lượng ISO 9126 được phát triển bởi một nhóm chuyên gia dưới sự
bảo trợ của Tổ chức Tiêu chuẩn hóa Quốc tế (ISO). Tài liệu ISO
41
9126 xác định sáu loại đặc tính chất lượng rộng, độc lập: chức năng,
độ tin cậy, khả năng sử dụng, hiệu quả, khả năng bảo trì và tính di
động. CMM được phát triển bởi Viện Kỹ thuật Phần mềm (SEI) tại
Đại học Carnegie Mellon. Trong khuôn khổ CMM, quy trình phát
triển được đánh giá trên thang điểm từ 1–5, thường được gọi là cấp
độ 1 đến cấp độ 5. Ví dụ: cấp độ 1 được gọi là cấp độ ban đầu, trong
khi cấp độ 5 — tối ưu hóa — là cấp độ cao nhất của quá trình trưởng
thành.
Trong lĩnh vực kiểm thử phần mềm, có hai mô hình quy trình nổi
tiếng, đó là mô hình cải tiến quy trình kiểm thử (TPI) [23] và Mô
hình độ chín kiểm thử (TMM) [24]. Hai mô hình này cho phép một
tổ chức đánh giá trạng thái hiện tại của các quy trình kiểm thử phần
mềm của họ, xác định lĩnh vực logic tiếp theo để cải tiến và đề xuất
một kế hoạch hành động để cải tiến quy trình kiểm tra.
1.3 VAI TRÒ CỦA KIỂM TRA

Kiểm thử đóng một vai trò quan trọng trong việc đạt được và đánh
giá chất lượng của một sản phẩm phần mềm [25]. Một mặt, chúng tôi
cải thiện chất lượng của sản phẩm khi chúng tôi lặp lại chu trình
kiểm tra - tìm lỗi - sửa chữa trong quá trình phát triển. Mặt khác,
chúng tôi đánh giá mức độ tốt của hệ thống khi chúng tôi thực hiện
các bài kiểm tra cấp hệ thống trước khi phát hành một sản phẩm. Do
đó, như Friedman và Voas [26] đã mô tả ngắn gọn, kiểm thử phần
mềm là một quá trình xác minh để đánh giá và cải tiến chất lượng
phần mềm. Nói chung, các hoạt động đánh giá chất lượng phần mềm
có thể được chia thành hai loại lớn, đó là phân tích tĩnh và phân tích
động.
Phân tích tĩnh: Như thuật ngữ “tĩnh” gợi ý, nó dựa trên việc kiểm
tra một số tài liệu, cụ thể là tài liệu yêu cầu, mô hình phần mềm, tài
liệu thiết kế và mã nguồn. Phân tích tĩnh truyền thống bao gồm xem
xét mã, kiểm tra, xem qua, phân tích thuật toán và bằng chứng về
tính đúng đắn. Nó không liên quan đến việc thực thi mã đang được
phát triển thực tế. Thay vào đó, nó kiểm tra mã và lý do trên tất cả
các hành vi có thể xảy ra trong thời gian chạy. Tối ưu hóa trình biên
dịch là phân tích tĩnh tiêu chuẩn.
Phân tích động: Phân tích động của một hệ thống phần mềm liên
quan đến việc thực hiện chương trình thực tế để chỉ ra các lỗi chương
trình có thể xảy ra. Các thuộc tính hành vi và hiệu suất của chương
trình cũng được quan sát. Các chương trình được thực thi với cả các
giá trị đầu vào điển hình và được lựa chọn cẩn thận. Thông thường,
tập hợp đầu vào của một chương trình có thể lớn không thực tế. Tuy
nhiên, để xem xét thực tế, một tập hợp con hữu hạn của tập đầu vào
có thể được chọn. Do đó, trong quá trình thử nghiệm, chúng tôi quan
sát một số hành vi của chương trình đại diện và đi đến kết luận về
chất lượng của hệ thống. Việc lựa chọn cẩn thận một tập hợp thử
nghiệm hữu hạn là rất quan trọng để đi đến kết luận đáng tin cậy.
Bằng cách thực hiện các phân tích tĩnh và động, các học viên muốn
xác định càng nhiều lỗi càng tốt để những lỗi đó được khắc phục ở
giai đoạn đầu của quá trình phát triển phần mềm. Phân tích tĩnh và
phân tích động về bản chất là bổ sung cho nhau, và để có hiệu quả tốt
hơn, cả hai phải được thực hiện lặp đi lặp lại và luân phiên. Các nhà
thực hành và nhà nghiên cứu cần xóa bỏ ranh giới giữa phân tích tĩnh
và phân tích động và tạo ra một phân tích lai kết hợp các điểm mạnh
của cả hai cách tiếp cận [27].
1.4 XÁC NHẬN VÀ XÁC NHẬN
Hai khái niệm tương tự liên quan đến kiểm thử phần mềm thường
được các học viên sử dụng là xác minh và xác nhận. Cả hai khái
niệm đều trừu tượng về bản chất, và mỗi khái niệm có thể được thực
hiện bằng một tập hợp các hoạt động cụ thể, có thể thực thi được. Hai
khái niệm được giải thích như sau:
Xác minh: Loại hoạt động này giúp chúng tôi đánh giá hệ thống
phần mềm bằng cách xác định xem sản phẩm của một giai đoạn phát
triển nhất định có đáp ứng các yêu cầu được thiết lập trước khi bắt
đầu giai đoạn đó hay không. Người ta có thể lưu ý rằng một sản
phẩm có thể là một sản phẩm trung gian, chẳng hạn như đặc điểm kỹ
thuật yêu cầu, đặc điểm kỹ thuật thiết kế, mã, hướng dẫn sử dụng,
hoặc thậm chí là sản phẩm cuối cùng. Các hoạt động kiểm tra tính
đúng đắn của một giai đoạn phát triển được gọi là hoạt động xác
minh.
Xác thực: Các hoạt động kiểu này giúp chúng tôi xác nhận rằng một
sản phẩm đáp ứng được mục đích sử dụng của nó. Hoạt động xác
nhận nhằm xác nhận rằng một sản phẩm đáp ứng được mong đợi của
khách hàng. Nói cách khác, các hoạt động xác nhận tập trung vào sản
43
phẩm cuối cùng, được thử nghiệm rộng rãi theo quan điểm của khách
hàng. Việc xác nhận xác nhận liệu sản phẩm có đáp ứng được kỳ
vọng chung của người dùng hay không.
Việc thực hiện muộn các hoạt động xác nhận thường có rủi ro do dẫn
đến chi phí phát triển cao hơn. Các hoạt động xác nhận có thể được
thực hiện ở giai đoạn đầu của chu kỳ phát triển phần mềm [28]. Có
thể tìm thấy một ví dụ về việc thực hiện sớm các hoạt động xác nhận
trong phương pháp luận phát triển phần mềm eXtreme Programming
(XP). Trong phương pháp của XP, khách hàng tương tác chặt chẽ với
nhóm phát triển phần mềm và tiến hành kiểm tra chấp nhận trong
mỗi lần lặp lại phát triển [29].
Quá trình xác minh thiết lập sự tương ứng của một giai đoạn triển
khai của quá trình phát triển phần mềm với đặc điểm kỹ thuật của nó,
trong khi quá trình xác nhận thiết lập sự tương ứng giữa hệ thống và
kỳ vọng của người dùng. Người ta có thể so sánh xác minh và xác
nhận như sau:
Các hoạt động xác minh nhằm xác nhận rằng một người đang xây
dựng sản phẩm một cách chính xác, trong khi các hoạt động xác nhận
nhằm xác nhận rằng một người đang xây dựng sản phẩm chính xác
[30].
Hoạt động xác minh xem xét các sản phẩm công việc tạm thời, chẳng
hạn như đặc tả yêu cầu, thiết kế, mã và hướng dẫn sử dụng, trong
vòng đời dự án để đảm bảo chất lượng của chúng. Các thuộc tính
chất lượng mà hoạt động xác minh tìm kiếm là tính nhất quán, tính
đầy đủ và tính đúng đắn ở mỗi giai đoạn phát triển chính của hệ
thống. Mặt khác, xác nhận được thực hiện vào cuối quá trình phát
triển hệ thống để xác định xem toàn bộ hệ thống có đáp ứng nhu cầu
và mong đợi của khách hàng hay không.
Hoạt động xác minh được thực hiện trên các sản phẩm tạm thời bằng
cách áp dụng hầu hết các kỹ thuật phân tích tĩnh, chẳng hạn như kiểm
tra, hướng dẫn và đánh giá, đồng thời sử dụng các tiêu chuẩn và danh
sách kiểm tra. Việc xác minh cũng có thể bao gồm phân tích động,
chẳng hạn như thực thi chương trình thực tế. Mặt khác, xác nhận
được thực hiện trên toàn bộ hệ thống bằng cách thực sự chạy hệ
thống trong môi trường thực của nó và sử dụng nhiều loại thử
nghiệm.
1.5 THẤT BẠI, LỖI, LỖI VÀ ĐÁNH BẠI

Trong tài liệu về kiểm thử phần mềm, người ta có thể tìm thấy các
tham chiếu đến các thuật ngữ lỗi, lỗi, lỗi và lỗi. Mặc dù ý nghĩa của
chúng có liên quan với nhau, nhưng có sự khác biệt quan trọng giữa
bốn khái niệm này. Sau đây, chúng tôi trình bày ba thuật ngữ đầu tiên
khi chúng được hiểu trong cộng đồng máy tính chịu lỗi:
Thất bại: Lỗi được cho là xảy ra bất cứ khi nào hành vi bên ngoài
của hệ thống không phù hợp với quy định trong đặc tả hệ thống.
Lỗi: Lỗi là một trạng thái của hệ thống. Trong trường hợp không có
bất kỳ hành động sửa chữa nào của hệ thống, trạng thái lỗi có thể dẫn
đến lỗi không được quy cho bất kỳ sự kiện nào xảy ra sau lỗi.
Lỗi: Lỗi là nguyên nhân được phân xử của lỗi.
Một lỗi có thể vẫn không được phát hiện trong một thời gian dài, cho
đến khi một số sự kiện kích hoạt nó. Khi một sự kiện kích hoạt lỗi,
trước tiên nó sẽ đưa chương trình vào trạng thái lỗi trung gian. Nếu
tính toán được phép tiếp tục từ trạng thái lỗi mà không có bất kỳ
hành động sửa chữa nào, chương trình cuối cùng sẽ gây ra lỗi. Ngoài
ra, trong tính toán chịu lỗi, các hành động sửa chữa có thể được thực
hiện để đưa một chương trình từ trạng thái lỗi sang trạng thái mong
muốn sao cho việc tính toán tiếp theo cuối cùng không dẫn đến lỗi.
Do đó, quá trình biểu hiện lỗi có thể được trình bày ngắn gọn dưới
dạng một chuỗi hành vi [31] như sau: lỗi → lỗi → thất bại. Chuỗi
hành vi có thể lặp lại trong một thời gian, nghĩa là, sự thất bại của
một thành phần có thể dẫn đến sự thất bại của một thành phần tương
tác khác.
Định nghĩa về thất bại ở trên giả định rằng thông số kỹ thuật đã cho
là có thể chấp nhận được đối với khách hàng. Tuy nhiên, nếu đặc
điểm kỹ thuật không đáp ứng được mong đợi của khách hàng, thì tất
nhiên, ngay cả việc triển khai không có lỗi cũng không thể làm hài
lòng khách hàng. Đó là một nhiệm vụ khó khăn để đưa ra định nghĩa
chính xác về lỗi, lỗi hoặc lỗi của phần mềm, bởi vì “yếu tố con
người” liên quan đến sự chấp nhận chung của một hệ thống. Trong
một bài báo có tiêu đề “Thất bại phần mềm là gì” [32], Ram
Chillarege nhận xét rằng trong phần mềm kinh doanh phần mềm hiện
đại, phần mềm thất bại có nghĩa là “kỳ vọng của khách hàng không
được đáp ứng và / hoặc khách hàng không thể làm việc hữu ích với
sản phẩm,” p. 354.
45
Roderick Rees [33] mở rộng nhận xét của Chillarege về lỗi phần
mềm bằng cách chỉ ra rằng “lỗi chỉ là vấn đề về chức năng [và do đó]
liên quan đến mục đích, chứ không phải về việc một vật có còn
nguyên vẹn hay không” (trang 163). Để chứng minh điều này,
Behrooz Parhami [34] đã đưa ra ba ví dụ thú vị để chỉ ra sự liên quan
của một quan điểm như vậy trong bối cảnh rộng lớn hơn. Một trong
những ví dụ được trích dẫn ở đây (trang 451):
Hãy xem xét một tổ chức nhỏ. Những khiếm khuyết trong các chính
sách thăng tiến nhân viên của tổ chức có thể gây ra những sự thăng
tiến không phù hợp, được xem như là lỗi. Các thái độ và sự không
hài lòng kết quả là lỗi trong trạng thái của tổ chức. Nhân sự hoặc bộ
phận của tổ chức có thể bắt đầu hoạt động sai do các sai sót, do đó
gây ra sự suy giảm tổng thể về hiệu suất. Kết quả cuối cùng có thể là
tổ chức không đạt được mục tiêu.
Có một sự khác biệt nhỏ giữa khuyết tật và lỗi trong ví dụ trên, đó là,
việc thực hiện chính sách bị lỗi có thể dẫn đến quảng cáo bị lỗi.
Trong bối cảnh phần mềm, một hệ thống phần mềm có thể bị lỗi do
các vấn đề thiết kế; một số trạng thái hệ thống sẽ để lộ ra một khiếm
khuyết, dẫn đến sự phát triển của các lỗi được xác định là các giá trị
tín hiệu hoặc các quyết định không chính xác trong hệ thống. Trong
công nghiệp, thuật ngữ lỗi được sử dụng rộng rãi, trong khi trong các
nhà nghiên cứu, thuật ngữ lỗi phổ biến hơn. Đối với tất cả các mục
đích thực tế, hai thuật ngữ này đồng nghĩa với nhau. Trong cuốn sách
này, chúng tôi sử dụng hai thuật ngữ thay thế cho nhau theo yêu cầu.
1.6 LƯU Ý VỀ ĐỘ TIN CẬY CỦA PHẦN MỀM

Bất kể chúng tôi chạy chu trình kiểm tra – tìm lỗi – sửa chữa bao
nhiêu lần trong quá trình phát triển phần mềm, một số lỗi có khả
năng không được chúng tôi chú ý và những lỗi này cuối cùng sẽ xuất
hiện tại trang web của khách hàng. Do đó, một thước đo định lượng
hữu ích trong việc đánh giá chất lượng của một phần mềm là độ tin
cậy của nó [35]. Độ tin cậy của phần mềm được định nghĩa là xác
suất hoạt động không có lỗi của hệ thống phần mềm trong một thời
gian xác định trong một môi trường xác định. Mức độ tin cậy của hệ
thống phụ thuộc vào các yếu tố đầu vào gây ra lỗi mà người dùng
cuối có thể quan sát được. Độ tin cậy của phần mềm có thể được ước
tính thông qua thử nghiệm ngẫu nhiên, theo đề xuất của Hamlet [36].
Vì khái niệm về độ tin cậy là đặc trưng cho “môi trường cụ thể”, dữ
liệu thử nghiệm phải được rút ra từ phân phối đầu vào để gần giống
với cách sử dụng hệ thống trong tương lai. Việc nắm bắt mô hình sử
dụng trong tương lai của một hệ thống theo nghĩa chung được mô tả
trong một biểu mẫu được gọi là hồ sơ hoạt động. Khái niệm về hồ sơ
hoạt động của một hệ thống được John D. Musa tại Phòng thí nghiệm
AT&T Bell tại Phòng thí nghiệm Bell của AT&T đưa ra từ những
năm 1970 đến những năm 1990 [37, 38].
1.7 MỤC TIÊU KIỂM TRA
Các bên liên quan trong quá trình thử nghiệm là lập trình viên, kỹ sư
thử nghiệm, người quản lý dự án và khách hàng. Bên liên quan là
một người hoặc một tổ chức có ảnh hưởng đến các hành vi của hệ
thống hoặc người bị tác động bởi hệ thống đó [39]. Các bên liên quan
khác nhau xem quá trình kiểm tra từ các khía cạnh khác nhau như
được giải thích dưới đây:
Nó hoạt động: Trong khi triển khai một đơn vị chương trình, người
lập trình có thể muốn kiểm tra xem đơn vị đó có hoạt động trong
trường hợp bình thường hay không. Các lập trình viên nhận được
nhiều sự tin tưởng nếu đơn vị hoạt động theo sự hài lòng của họ. Ý
tưởng tương tự cũng áp dụng cho toàn bộ hệ thống — khi một hệ
thống đã được tích hợp, các nhà phát triển có thể muốn kiểm tra xem
hệ thống có thực hiện các chức năng cơ bản hay không. Ở đây, vì lý
do tâm lý, mục tiêu của thử nghiệm là cho thấy rằng hệ thống hoạt
động, thay vì nó không hoạt động.
Nó không hoạt động: Một khi lập trình viên (hoặc nhóm phát triển)
hài lòng rằng một đơn vị (hoặc hệ thống) hoạt động ở một mức độ
nhất định, nhiều thử nghiệm hơn được tiến hành với mục tiêu tìm ra
lỗi trong đơn vị (hoặc hệ thống).
Ở đây, ý tưởng là cố gắng làm cho đơn vị (hoặc hệ thống) thất bại.
1.8 TRƯỜNG HỢP KIỂM TRA LÀ GÌ?

Giảm nguy cơ hỏng hóc: Hầu hết các hệ thống phần mềm phức tạp
đều chứa các lỗi khiến hệ thống bị lỗi theo thời gian. Khái niệm "thất
bại theo thời gian" này dẫn đến khái niệm về tỷ lệ thất bại. Khi các
lỗi được phát hiện và khắc phục trong khi thực hiện ngày càng nhiều
47
thử nghiệm, tỷ lệ hỏng hóc của hệ thống nói chung sẽ giảm xuống.
Do đó, mục tiêu cấp cao hơn của việc thực hiện các bài kiểm tra là
giảm nguy cơ thất bại xuống mức có thể chấp nhận được.
Giảm chi phí thử nghiệm: Các loại chi phí khác nhau liên quan đến
quá trình thử nghiệm bao gồm chi phí thiết kế, duy trì và thực hiện
các trường hợp thử nghiệm, chi phí phân tích kết quả thực hiện từng
trường hợp thử nghiệm, chi phí ghi lại các trường hợp thử nghiệm và
chi phí thực thi hệ thống và ghi chép lại hệ thống.
Do đó, số lượng trường hợp thử nghiệm được thiết kế càng ít thì chi
phí thử nghiệm liên quan càng ít. Tuy nhiên, sản xuất một số lượng
nhỏ các trường hợp thử nghiệm tùy ý không phải là một cách tốt để
tiết kiệm chi phí. Mục tiêu cao nhất của việc thực hiện các thử
nghiệm là tạo ra phần mềm có độ rủi ro thấp với số lượng trường hợp
thử nghiệm ít hơn. Ý tưởng này dẫn chúng ta đến khái niệm về tính
hiệu quả của các trường hợp thử nghiệm. Do đó, các kỹ sư kiểm thử
phải lựa chọn một cách thận trọng các trường hợp kiểm thử ít hơn,
hiệu quả hơn.
1.8 TRƯỜNG HỢP KIỂM TRA LÀ GÌ?
Ở dạng cơ bản nhất của nó, một ca kiểm thử là một cặp đơn giản của
< đầu vào, kết quả mong đợi > . Nếu một chương trình đang được
thử nghiệm được mong đợi tính căn bậc hai của các số không âm, thì
bốn ví dụ về các trường hợp thử nghiệm được thể hiện trong Hình
1.3.
Trong các hệ thống không trạng thái, nơi mà kết quả chỉ phụ thuộc
vào đầu vào hiện tại, các trường hợp kiểm thử có cấu trúc rất đơn
giản, như thể hiện trong Hình 1.3. Một chương trình tính căn bậc hai
của các số không âm là một ví dụ về hệ thống không trạng thái. Một
trình biên dịch cho ngôn ngữ lập trình C là một ví dụ khác về hệ
thống không trạng thái. Trình biên dịch là một hệ thống không trạng
thái vì để biên dịch một chương trình, nó không cần biết về các
chương trình mà nó đã biên dịch trước đó.
Trong các hệ thống hướng trạng thái, trong đó kết quả của chương
trình phụ thuộc cả vào trạng thái hiện tại của hệ thống và đầu vào
hiện tại, một trường hợp thử nghiệm có thể bao gồm
TB 1 : <0, 0>,
TB 2 : <25, 5>,
TB 3 : <40, 6.3245553>,
TB 4 : <100,5,
10,024968>.
Hình 1.3 Các ví dụ về các trường hợp kiểm thử cơ bản.
TS 1 : <kiểm tra số dư, $ 500,00>, <rút tiền, '' số
tiền? ''>, <$ 200,00, '' $ 200,00 ''>, <kiểm tra
số dư, $ 300,00>.
Hình 1.4 Ví dụ về trường hợp kiểm thử với chuỗi < đầu vào,
kết quả mong đợi > .
chuỗi các cặp < đầu vào, kết quả mong đợi > . Hệ thống chuyển
mạch điện thoại và máy rút tiền tự động (ATM) là những ví dụ về hệ
thống hướng nhà nước. Đối với máy ATM, một trường hợp kiểm tra
để kiểm tra chức năng rút tiền được thể hiện trong Hình 1.4. Ở đây,
chúng tôi giả định rằng người dùng đã nhập các đầu vào được xác
thực, chẳng hạn như thẻ tiền mặt và số nhận dạng cá nhân (PIN).
Trong trường hợp thử nghiệm TS 1 , “kiểm tra số dư” và “rút tiền”
trong bộ giá trị thứ nhất, thứ hai và thứ tư thể hiện việc nhấn các
phím thích hợp trên bàn phím ATM. Giả định rằng tài khoản người
dùng có $ 500,00 và người dùng muốn rút số tiền là $ 200,00. Kết
quả dự kiến “$ 200,00” trong bộ thứ ba đại diện cho tiền mặt do máy
ATM phân phối. Sau khi thực hiện thao tác rút tiền, người dùng đảm
bảo rằng số dư còn lại là $ 300,00.
Đối với các hệ thống hướng trạng thái, hầu hết các trường hợp kiểm
thử bao gồm một số hình thức quyết định và thời gian trong việc
cung cấp đầu vào cho hệ thống. Một trường hợp thử nghiệm có thể
bao gồm các vòng lặp và bộ định thời, chúng tôi không hiển thị tại
thời điểm này.
1.9 DỰ KIẾN OUTCOME
Kết quả của việc thực hiện chương trình là một thực thể phức tạp có
thể bao gồm những điều sau đây: • Các giá trị do chương trình tạo ra:
Đầu ra cho quan sát cục bộ (số nguyên, văn bản, âm thanh, hình ảnh)
Đầu ra (tin nhắn) để lưu trữ, thao tác hoặc quan sát từ xa
Thay đổi trạng thái:
Thay đổi trạng thái của chương trình
49
Thay đổi trạng thái của cơ sở dữ liệu (do các thao tác thêm, xóa và
cập nhật)
Một chuỗi hoặc tập hợp các giá trị phải được diễn giải cùng nhau để
kết quả có giá trị
Một khái niệm quan trọng trong thiết kế kiểm thử là khái niệm tiên
tri. Tiên tri là bất kỳ thực thể nào — chương trình, quy trình, chuyên
gia về con người hoặc cơ quan dữ liệu — cho chúng ta biết kết quả
mong đợi của một thử nghiệm hoặc tập hợp các thử nghiệm cụ thể
[40]. Một trường hợp thử nghiệm chỉ có ý nghĩa nếu có thể quyết
định về khả năng chấp nhận của kết quả được tạo ra bởi chương trình
được thử nghiệm.
Tốt nhất, kết quả mong đợi của một thử nghiệm nên được tính toán
trong khi thiết kế trường hợp thử nghiệm. Nói cách khác, kết quả
kiểm tra được tính toán trước khi chương trình
1.11 VẤN ĐỀ TRUNG TÂM TRONG KIỂM TRA
được thực thi với đầu vào kiểm tra đã chọn. Ý tưởng ở đây là người
ta có thể tính toán kết quả mong đợi từ sự hiểu biết về các yêu cầu
của chương trình. Việc tính toán trước kết quả mong đợi sẽ loại bỏ
bất kỳ sai lệch triển khai nào trong trường hợp trường hợp thử
nghiệm được thiết kế bởi nhà phát triển.
Trong những trường hợp đặc biệt, khi việc tính toán một kết quả
mong đợi duy nhất là cực kỳ khó, không thể hoặc thậm chí không
mong muốn, người ta nên xác định các kết quả mong đợi bằng cách
kiểm tra các kết quả thử nghiệm thực tế, như được giải thích trong
phần sau:
Thực thi chương trình với đầu vào đã chọn.
Quan sát kết quả thực tế của việc thực hiện chương trình.
Xác minh rằng kết quả thực tế là kết quả mong đợi.
Sử dụng kết quả thực tế đã được xác minh làm kết quả mong đợi
trong các lần chạy trường hợp thử nghiệm tiếp theo.
1.10 KHÁI NIỆM VỀ KIỂM TRA HOÀN THIỆN
Không có gì lạ khi thấy mọi người tuyên bố như "Tôi đã thử nghiệm
chương trình một cách toàn diện." Kiểm tra toàn bộ hoặc toàn bộ có
nghĩa là không có lỗi nào chưa được phát hiện ở cuối giai đoạn kiểm
tra. Tất cả các vấn đề phải được biết khi kết thúc thử nghiệm hoàn
chỉnh. Đối với hầu hết các hệ thống, việc kiểm tra hoàn chỉnh là gần
như không thể vì những lý do sau:
Miền của các đầu vào có thể có của một chương trình quá lớn để
được sử dụng hoàn toàn trong việc kiểm tra hệ thống. Có cả đầu vào
hợp lệ và đầu vào không hợp lệ. Chương trình có thể có một số lượng
lớn các trạng thái. Có thể có những ràng buộc về thời gian đối với
các đầu vào, tức là, một đầu vào có thể hợp lệ tại một thời điểm nhất
định và không hợp lệ vào những thời điểm khác. Giá trị đầu vào hợp
lệ nhưng không đúng thời gian được gọi là giá trị đầu vào không phù
hợp. Miền đầu vào của một hệ thống có thể rất lớn để được sử dụng
hoàn toàn trong việc thử nghiệm một chương trình.
Các vấn đề thiết kế có thể quá phức tạp để kiểm tra hoàn toàn. Thiết
kế có thể đã bao gồm các quyết định và giả định thiết kế ngầm. Ví
dụ, một lập trình viên có thể sử dụng một biến toàn cục hoặc một
biến tĩnh để điều khiển việc thực thi chương trình.
Có thể không tạo được tất cả các môi trường thực thi có thể có của hệ
thống. Điều này trở nên quan trọng hơn khi hành vi của hệ thống
phần mềm phụ thuộc vào thế giới thực, bên ngoài, chẳng hạn như
thời tiết, nhiệt độ, độ cao, áp suất, v.v.
1.11 VẤN ĐỀ TRUNG TÂM TRONG KIỂM TRA
Chúng ta phải nhận ra rằng mặc dù kết quả của việc kiểm tra hoàn
chỉnh, tức là phát hiện ra tất cả các lỗi, rất đáng mong đợi, nhưng đó
là một nhiệm vụ gần như bất khả thi và nó có thể không được cố
gắng. Điều tốt nhất tiếp theo là chọn một tập hợp con của miền đầu
vào để kiểm tra một chương trình.
Input domainD ProgramP
D1 Apply inputs P1 Observe outcome
D2
P2
Hình 1.5 Tập hợp con của miền đầu vào thực hiện một tập hợp
con của hành vi chương trình.
Xem hình 1.5, cho D là miền đầu vào của chương trình P. Giả sử
chúng ta chọn một tập con D 1 của D, nghĩa là D 1 ⊂ D, để kiểm tra
chương trình P. Có thể D 1 chỉ là một bài tập . P 1 , nghĩa là P 1 ⊂ P, về
51
hành vi thực thi của P, trong trường hợp đó lỗi với phần khác, P 2 , sẽ
không bị phát hiện.
Bằng cách chọn một tập con của miền đầu vào D 1 , kỹ sư thử nghiệm
cố gắng suy ra các thuộc tính của toàn bộ chương trình P bằng cách
quan sát hành vi của một phần P 1 trong toàn bộ hành vi của P trên
các đầu vào D 1 đã chọn . Do đó, việc lựa chọn tập con của miền đầu vào
phải được thực hiện một cách có hệ thống và cẩn thận để việc suy
diễn được chính xác và đầy đủ nhất có thể. Ví dụ, ý tưởng về phạm
vi bảo hiểm được xem xét trong khi lựa chọn các trường hợp thử
nghiệm.
1.12 CÁC HOẠT ĐỘNG KIỂM TRA
Để kiểm thử một chương trình, một kỹ sư kiểm thử phải thực hiện
một chuỗi các hoạt động kiểm thử. Hầu hết các hoạt động này đã
được thể hiện trong Hình 1.6 và được giải thích như sau. Những giải
thích này tập trung vào một trường hợp thử nghiệm duy nhất.
Xác định mục tiêu cần kiểm tra: Hoạt động đầu tiên là xác định
mục tiêu cần kiểm tra. Mục tiêu xác định ý định hoặc mục đích của
việc thiết kế một hoặc nhiều trường hợp thử nghiệm để đảm bảo rằng
chương trình hỗ trợ mục tiêu. Một mục đích rõ ràng phải được liên
kết với mọi trường hợp thử nghiệm.
Compute expected outcome for the selected input
Result
analysis
Selected input Observe actual
Program (P )
outcome
Environment
Assign a test verdict

Hình 1.6 Các hoạt động khác nhau trong kiểm thử chương
trình.
1.12 CÁC HOẠT ĐỘNG KIỂM TRA
Chọn đầu vào: Hoạt động thứ hai là chọn đầu vào kiểm tra. Lựa
chọn đầu vào kiểm tra có thể dựa trên đặc điểm kỹ thuật yêu cầu, mã
nguồn hoặc kỳ vọng của chúng tôi. Đầu vào kiểm tra được chọn bằng
cách ghi nhớ mục tiêu kiểm tra.
Tính toán kết quả mong đợi: Hoạt động thứ ba là tính toán kết quả
mong đợi của chương trình với các đầu vào đã chọn. Trong hầu hết
các trường hợp, điều này có thể được thực hiện từ sự hiểu biết tổng
thể, ở mức độ cao về mục tiêu kiểm tra và đặc điểm kỹ thuật của
chương trình được kiểm tra.
Thiết lập môi trường thực thi của chương trình: Bước thứ tư là
chuẩn bị đúng môi trường thực thi của chương trình. Trong bước
này, tất cả các giả định bên ngoài chương trình phải được thỏa mãn.
Một vài ví dụ về các giả định bên ngoài một chương trình như sau:
Khởi tạo hệ thống cục bộ, bên ngoài chương trình. Điều này có thể
bao gồm việc tạo kết nối mạng, cung cấp hệ thống cơ sở dữ liệu phù
hợp, v.v.
Khởi tạo bất kỳ hệ thống từ xa, bên ngoài nào (ví dụ: quy trình đối
tác từ xa trong một ứng dụng phân tán.) Ví dụ: để kiểm tra mã máy
khách, chúng tôi có thể cần khởi động máy chủ tại một trang web từ
xa.
Thực thi chương trình: Trong bước thứ năm, kỹ sư kiểm thử thực
hiện chương trình với các đầu vào đã chọn và quan sát kết quả thực
tế của chương trình. Để thực hiện một trường hợp thử nghiệm, các
đầu vào có thể được cung cấp cho chương trình tại các vị trí thực tế
khác nhau vào những thời điểm khác nhau. Khái niệm phối hợp kiểm
thử được sử dụng trong việc đồng bộ hóa các thành phần khác nhau
của một trường hợp kiểm thử.
Phân tích kết quả kiểm tra: Hoạt động kiểm tra cuối cùng là phân
tích kết quả của việc thực hiện kiểm tra. Ở đây, nhiệm vụ chính là so
sánh kết quả thực tế của việc thực hiện chương trình với kết quả
mong đợi. Độ phức tạp của việc so sánh phụ thuộc vào độ phức tạp
của dữ liệu được quan sát. Kiểu dữ liệu quan sát có thể đơn giản như
một số nguyên hoặc một chuỗi ký tự hoặc phức tạp như một hình
ảnh, một video hoặc một đoạn âm thanh. Vào cuối bước phân tích,
một kết quả kiểm tra được gán cho chương trình. Có ba loại phán
quyết chính của bài kiểm tra, đó là vượt qua, không đạt và bất phân
thắng bại, như được giải thích bên dưới.
Nếu chương trình tạo ra kết quả mong đợi và mục đích của trường
hợp thử nghiệm được thỏa mãn, thì kết quả đạt được sẽ được chỉ
định.
53
Nếu chương trình không tạo ra kết quả mong đợi, thì kết quả không
thành công sẽ được ấn định.
Tuy nhiên, trong một số trường hợp, có thể không chỉ định một phán
quyết đạt hoặc không rõ ràng. Ví dụ: nếu thời gian chờ xảy ra trong
khi thực hiện trường hợp thử nghiệm trên một ứng dụng được phân
phối, chúng tôi có thể không có đủ khả năng để chỉ định kết quả đạt
hoặc không đạt rõ ràng. Trong những trường hợp đó, một kết quả thử
nghiệm không thể kết luận được sẽ được chỉ định. Một kết quả kiểm
tra không kết luận có nghĩa là cần phải thực hiện thêm các bài kiểm
tra khác để tinh chỉnh kết quả không thể kết luận thành một kết quả
đạt hoặc không đạt rõ ràng.
Một báo cáo thử nghiệm phải được viết sau khi phân tích kết quả thử
nghiệm. Động cơ để viết báo cáo thử nghiệm là để sửa lỗi nếu thử
nghiệm phát hiện ra lỗi. Một báo cáo thử nghiệm chứa các mục sau
đây để cung cấp thông tin:
Giải thích cách tái tạo lỗi.
Phân tích sự thất bại để có thể mô tả nó.
Một con trỏ đến kết quả thực tế và trường hợp thử nghiệm, hoàn
chỉnh với đầu vào, kết quả mong đợi và môi trường thực thi.
1.13 MỨC ĐỘ KIỂM TRA
Kiểm thử được thực hiện ở các cấp độ khác nhau liên quan đến hệ
thống hoàn chỉnh hoặc các bộ phận của nó trong suốt vòng đời của
một sản phẩm phần mềm. Một hệ thống phần mềm trải qua bốn giai
đoạn thử nghiệm trước khi nó thực sự được triển khai. Bốn giai đoạn
này được gọi là kiểm thử đơn vị, tích hợp, hệ thống và mức chấp
nhận. Ba cấp độ kiểm thử đầu tiên được thực hiện bởi một số bên liên
quan khác nhau trong tổ chức phát triển, trong đó kiểm thử chấp nhận
được thực hiện bởi khách hàng. Bốn giai đoạn thử nghiệm đã được
minh họa dưới dạng mô hình được gọi là mô hình V cổ điển trong
Hình 1.7.
Trong kiểm thử đơn vị, người lập trình kiểm tra các đơn vị chương
trình riêng lẻ, chẳng hạn như thủ tục, hàm, phương pháp hoặc lớp,
một cách riêng biệt. Sau khi đảm bảo rằng các đơn vị riêng lẻ hoạt
động ở mức độ thỏa đáng, các mô-đun được lắp ráp để xây dựng các
hệ thống con lớn hơn bằng cách tuân theo các kỹ thuật kiểm tra tích
hợp. Kiểm thử tích hợp do các nhà phát triển phần mềm và kỹ sư
kiểm thử tích hợp cùng thực hiện. Mục tiêu của
Development Testing
Requirements Acceptance
High-level
design System
Detailed
design Integration
Coding Unit
Legend
Validation
Verification
Hình 1.7 Các giai đoạn phát triển và thử nghiệm trong mô hình
V.
1.13 MỨC ĐỘ KIỂM TRA
kiểm thử tích hợp là xây dựng một hệ thống ổn định hợp lý có thể
chịu được sự khắc nghiệt của kiểm thử cấp hệ thống. Kiểm tra mức
hệ thống bao gồm nhiều loại kiểm tra, chẳng hạn như kiểm tra chức
năng, kiểm tra bảo mật, kiểm tra độ mạnh mẽ, kiểm tra tải, kiểm tra
độ ổn định, kiểm tra căng thẳng, kiểm tra hiệu suất và kiểm tra độ tin
cậy. Kiểm thử hệ thống là một giai đoạn quan trọng trong quy trình
phát triển phần mềm vì yêu cầu phải đáp ứng một lịch trình chặt chẽ
gần ngày giao hàng, để phát hiện ra hầu hết các lỗi và xác minh rằng
các bản sửa lỗi đang hoạt động và không dẫn đến các lỗi mới. Kiểm
thử hệ thống bao gồm một số hoạt động riêng biệt: tạo kế hoạch thử
nghiệm, thiết kế bộ thử nghiệm, chuẩn bị môi trường thử nghiệm,
thực hiện các thử nghiệm bằng cách tuân theo một chiến lược rõ ràng
và giám sát quá trình thực hiện thử nghiệm.
Kiểm thử hồi quy là một cấp độ kiểm thử khác được thực hiện trong
suốt vòng đời của hệ thống. Kiểm tra hồi quy được thực hiện bất cứ
khi nào một thành phần của hệ thống được sửa đổi. Ý tưởng chính
trong kiểm tra hồi quy là xác định chắc chắn rằng việc sửa đổi không
tạo ra bất kỳ lỗi mới nào trong phần không phải sửa đổi. Nói một
55
cách chính xác, kiểm thử hồi quy không phải là một cấp độ kiểm thử
riêng biệt. Thay vào đó, nó được coi là một giai đoạn con của kiểm
thử cấp đơn vị, tích hợp và cấp hệ thống, như được minh họa trong
Hình 1.8 [41].
Trong thử nghiệm hồi quy, các thử nghiệm mới không được thiết kế.
Thay vào đó, các bài kiểm tra được chọn, ưu tiên và thực thi từ nhóm
các trường hợp kiểm thử hiện có để đảm bảo rằng không có gì bị
hỏng trong phiên bản mới của phần mềm. Kiểm thử hồi quy là một
quá trình tốn kém và chiếm phần lớn nỗ lực kiểm tra trong ngành.
Nên chọn một tập hợp con các trường hợp thử nghiệm từ nhóm hiện
có để giảm chi phí. Một câu hỏi quan trọng là có bao nhiêu và trường
hợp kiểm thử nào nên được chọn để các trường hợp kiểm thử được
chọn có nhiều khả năng phát hiện ra các lỗi mới hơn [42–44].
Sau khi hoàn thành thử nghiệm cấp hệ thống, sản phẩm được giao
cho khách hàng. Khách hàng thực hiện một loạt các thử nghiệm của
riêng họ, thường được gọi là thử nghiệm chấp nhận. Mục tiêu của
kiểm thử chấp nhận là để đo lường chất lượng của sản phẩm, thay vì
tìm kiếm các khuyết tật, là mục tiêu của kiểm tra hệ thống. Một khái
niệm chính trong kiểm thử chấp nhận là kỳ vọng của khách hàng từ
hệ thống. Vào thời điểm kiểm tra chấp nhận, khách hàng nên phát
triển các tiêu chí chấp nhận của họ dựa trên kỳ vọng của riêng họ từ
hệ thống. Có hai loại kiểm thử chấp nhận như được giải thích trong
phần sau:
Kiểm tra sự chấp nhận của người dùng (UAT)
Kiểm tra chấp nhận kinh doanh (BAT)
Regression testing
Unit Integration System Acceptance

testing testing testing testing
Hình 1.8 Kiểm thử hồi quy ở các cấp độ kiểm thử phần mềm
khác nhau. (Từ tài liệu tham khảo 41. © 2005
John Wiley & Sons.)
Khách hàng tiến hành thử nghiệm chấp nhận người dùng để đảm bảo
rằng hệ thống đáp ứng các tiêu chí chấp nhận theo hợp đồng trước
khi được ký kết để đáp ứng nhu cầu của người dùng. Mặt khác, BAT
được thực hiện trong tổ chức phát triển của nhà cung cấp. Ý tưởng
khi có BAT là để đảm bảo rằng hệ thống cuối cùng sẽ vượt qua kiểm
tra chấp nhận của người dùng. Đây là một cuộc diễn tập của UAT tại
cơ sở của nhà cung cấp.
1.14 NGUỒN THÔNG TIN ĐỂ LỰA CHỌN TRƯỜNG HỢP
XÉT NGHIỆM
Việc thiết kế các trường hợp thử nghiệm đã tiếp tục nằm trong tầm
ngắm của cộng đồng nghiên cứu và các nhà thực hành. Quá trình
phát triển phần mềm tạo ra một lượng lớn thông tin, chẳng hạn như
đặc tả yêu cầu, tài liệu thiết kế và mã nguồn. Để tạo ra các thử
nghiệm hiệu quả với chi phí thấp hơn, các nhà thiết kế thử nghiệm
phân tích các nguồn thông tin sau:
 Yêu cầu và thông số kỹ thuật chức năng
 Mã nguồn
 Miền đầu vào và đầu ra
 Hồ sơ hoạt động
 Mô hình lỗi
Yêu cầu và Đặc tả Chức năng Quá trình phát triển phần mềm bắt
đầu bằng việc nắm bắt nhu cầu của người dùng. Bản chất và số lượng
nhu cầu của người dùng được xác định khi bắt đầu phát triển hệ
thống sẽ khác nhau tùy thuộc vào mô hình vòng đời cụ thể sẽ được
tuân theo. Chúng ta hãy xem xét một vài ví dụ. Trong mô hình
Waterfall [45] của phát triển phần mềm, một kỹ sư yêu cầu cố gắng
nắm bắt hầu hết các yêu cầu. Mặt khác, trong một mô hình phát triển
phần mềm nhanh nhẹn, chẳng hạn như XP [29] hoặc Scrum [46–48],
chỉ có một số yêu cầu được xác định ngay từ đầu. Một kỹ sư thử
nghiệm xem xét tất cả các yêu cầu mà chương trình dự kiến sẽ đáp
ứng bất kỳ mô hình vòng đời nào được chọn để thử nghiệm một
chương trình.
Các yêu cầu có thể đã được quy định một cách không chính thức,
chẳng hạn như sự kết hợp của văn bản rõ ràng, phương trình, số liệu
và lưu đồ. Mặc dù dạng đặc tả yêu cầu này có thể không rõ ràng,
nhưng khách hàng có thể dễ dàng hiểu được. Ví dụ: thông số kỹ thuật
Bluetooth bao gồm khoảng 1100 trang mô tả giải thích cách hoạt
động của các hệ thống con khác nhau của giao diện Bluetooth. Đặc
điểm kỹ thuật được viết dưới dạng văn bản rõ ràng bổ sung các
phương trình toán học, biểu đồ trạng thái, bảng và hình. Đối với một
57
số hệ thống, các yêu cầu có thể đã được nắm bắt dưới dạng ca sử
dụng, biểu đồ mối quan hệ-thực thể và biểu đồ lớp. Đôi khi các yêu
cầu của hệ thống có thể đã được chỉ định bằng ngôn ngữ hoặc ký
hiệu chính thức, chẳng hạn như Z, SDL, Estelle hoặc máy trạng thái
hữu hạn. Cả thông số kỹ thuật không chính thức và chính thức đều là
nguồn chính của các trường hợp kiểm thử [49].
1.14 NGUỒN THÔNG TIN ĐỂ LỰA CHỌN TRƯỜNG HỢP
XÉT NGHIỆM
Mã nguồn Trong khi đặc tả yêu cầu mô tả hành vi dự kiến của hệ
thống, mã nguồn mô tả hành vi thực tế của hệ thống. Các giả định và
ràng buộc cấp cao có dạng cụ thể trong quá trình thực hiện. Mặc dù
một nhà thiết kế phần mềm có thể tạo ra một thiết kế chi tiết, nhưng
các nhà lập trình có thể đưa các chi tiết bổ sung vào hệ thống. Ví dụ,
một bước trong thiết kế chi tiết có thể là “sắp xếp mảng A”. Để sắp
xếp một mảng, có nhiều thuật toán sắp xếp với các đặc điểm khác
nhau, chẳng hạn như lặp, đệ quy và tạm thời sử dụng một mảng khác.
Do đó, các ca kiểm thử phải được thiết kế dựa trên chương trình [50].
Miền đầu vào và đầu ra Một số giá trị trong miền đầu vào của
chương trình có ý nghĩa đặc biệt và do đó phải được xử lý riêng biệt
[5]. Để minh họa điểm này, chúng ta hãy xem xét hàm giai thừa. Giai
thừa của một số nguyên không âm n được tính như sau:
giai thừa (0) = 1; giai thừa (1) = 1;
giai thừa (n) = n * giai thừa (n-1);
Một lập trình viên có thể triển khai sai chức năng giai thừa như
giai thừa (n) = 1 * 2 * ... * n;
mà không xét đến trường hợp đặc biệt của n = 0. Việc thực hiện sai ở
trên sẽ tạo ra kết quả đúng với tất cả các giá trị dương của n, nhưng
sẽ không thành công với n = 0.
Đôi khi ngay cả một số giá trị đầu ra cũng có ý nghĩa đặc biệt và một
chương trình phải được kiểm tra để đảm bảo rằng nó tạo ra các giá trị
đặc biệt cho tất cả các nguyên nhân có thể xảy ra. Trong ví dụ trên,
giá trị đầu ra 1 có ý nghĩa đặc biệt: (i) nó là giá trị nhỏ nhất được tính
bởi hàm giai thừa và (ii) nó là giá trị duy nhất được tạo ra cho hai đầu
vào khác nhau.
Trong miền số nguyên, các giá trị 0 và 1 thể hiện các đặc điểm đặc
biệt nếu các phép toán số học được thực hiện. Các đặc điểm này là 0
× x = 0 và 1 × x = x với mọi giá trị của x. Do đó, tất cả các giá trị đặc
biệt trong các miền đầu vào và đầu ra của một chương trình phải
được xem xét trong khi thử nghiệm chương trình.
Hồ sơ hoạt động Như thuật ngữ gợi ý, hồ sơ hoạt động là một đặc
điểm định lượng về cách một hệ thống sẽ được sử dụng. Nó được tạo
ra để hướng dẫn các kỹ sư kiểm thử lựa chọn các trường hợp kiểm
thử (đầu vào) bằng cách sử dụng các mẫu sử dụng hệ thống. Khái
niệm về cấu hình hoạt động, hoặc cấu hình sử dụng, được phát triển
bởi Mills et al. [52] tại IBM trong bối cảnh Kỹ thuật Phần mềm
Phòng sạch và Musa [37] tại Phòng thí nghiệm AT&T Bell để giúp
phát triển các hệ thống phần mềm với độ tin cậy tốt hơn. Ý tưởng là
để suy ra, từ các kết quả thử nghiệm quan sát được, độ tin cậy trong
tương lai của phần mềm khi nó được sử dụng thực tế. Để làm điều
này, các đầu vào thử nghiệm được chỉ định một phân phối xác suất
hoặc hồ sơ, theo sự xuất hiện của chúng trong hoạt động thực tế.
Cách các kỹ sư kiểm thử chỉ định xác suất và lựa chọn các trường
hợp kiểm thử để vận hành một hệ thống có thể khác đáng kể so với
cách người dùng thực tế vận hành hệ thống. Tuy nhiên, để ước tính
chính xác độ tin cậy của một hệ thống, điều quan trọng là phải kiểm
tra một hệ thống bằng cách xem xét các cách nó thực sự sẽ được sử
dụng trên thực địa. Khái niệm này đang được sử dụng để kiểm tra các
ứng dụng web, nơi dữ liệu phiên người dùng được thu thập từ các
máy chủ web để chọn các trường hợp kiểm thử [53, 54].
Mô hình lỗi Các lỗi đã gặp trước đây là một nguồn thông tin tuyệt
vời để thiết kế các trường hợp thử nghiệm mới. Các lỗi đã biết được
phân loại thành các lớp khác nhau, chẳng hạn như lỗi khởi tạo, lỗi
logic và lỗi giao diện, và được lưu trữ trong kho lưu trữ [55, 56]. Các
kỹ sư kiểm tra có thể sử dụng những dữ liệu này trong việc thiết kế
các bài kiểm tra để đảm bảo rằng một loại lỗi cụ thể không nằm trong
chương trình.
Có ba loại kiểm tra dựa trên lỗi: đoán lỗi, phân tích lỗi và phân tích
đột biến. Khi đoán lỗi, một kỹ sư kiểm tra áp dụng kinh nghiệm của
mình để (i) đánh giá tình hình và đoán vị trí và loại lỗi nào có thể tồn
tại, và (ii) thiết kế các bài kiểm tra để xác định cụ thể các loại lỗi đó.
Khi gieo hạt lỗi, các lỗi đã biết được đưa vào một chương trình và bộ
thử nghiệm được thực thi để đánh giá hiệu quả của bộ thử nghiệm.
Việc gieo hạt lỗi đưa ra giả định rằng một bộ thử nghiệm tìm thấy
các lỗi được tạo hạt giống cũng có khả năng tìm thấy các lỗi khác.
59
Phân tích đột biến tương tự như phân tích lỗi, ngoại trừ các đột biến
đối với các câu lệnh của chương trình được thực hiện để xác định khả
năng phát hiện lỗi của bộ thử nghiệm. Nếu các trường hợp thử
nghiệm không có khả năng tiết lộ các lỗi như vậy, kỹ sư thử nghiệm
có thể chỉ định các trường hợp thử nghiệm bổ sung để tiết lộ các lỗi
đó. Kiểm tra đột biến dựa trên ý tưởng mô phỏng lỗi, trong khi gieo
hạt lỗi dựa trên ý tưởng tiêm lỗi. Trong phương pháp chèn lỗi, một
lỗi được chèn vào một chương trình và một tiên tri có sẵn để khẳng
định rằng lỗi được chèn thực sự đã làm cho chương trình không
chính xác. Mặt khác, trong mô phỏng lỗi, việc sửa đổi chương trình
không được đảm bảo sẽ dẫn đến chương trình bị lỗi. Trong mô phỏng
lỗi, người ta có thể sửa đổi một chương trình không chính xác và
biến nó thành một chương trình đúng.
1.15 KIỂM TRA HỘP TRẮNG VÀ HỘP ĐEN
Ý tưởng chính trong Phần 1.14 là các trường hợp kiểm thử cần được
thiết kế bằng cách xem xét thông tin từ một số nguồn, chẳng hạn như
đặc điểm kỹ thuật, mã nguồn và các thuộc tính đặc biệt của các miền
đầu vào và đầu ra của chương trình. Điều này là do tất cả các nguồn
đó cung cấp thông tin bổ sung cho các nhà thiết kế thử nghiệm. Hai
khái niệm rộng rãi trong thử nghiệm, dựa trên các nguồn thông tin để
thiết kế thử nghiệm, là thử nghiệm hộp trắng và hộp đen. Kỹ thuật
kiểm thử hộp trắng còn được gọi là kỹ thuật kiểm thử cấu trúc, trong
khi kỹ thuật kiểm thử hộp đen được gọi là kỹ thuật kiểm thử chức
năng.
Trong kiểm thử cấu trúc, người ta chủ yếu kiểm tra mã nguồn với
trọng tâm là luồng điều khiển và luồng dữ liệu. Luồng điều khiển đề
cập đến luồng điều khiển từ lệnh này sang lệnh khác. Điều khiển
chuyển từ lệnh này sang lệnh khác theo một số cách, chẳng hạn như
lệnh này xuất hiện sau lệnh khác, lệnh gọi hàm, truyền thông báo và
ngắt. Các câu lệnh điều kiện làm thay đổi luồng điều khiển bình
thường, tuần tự trong một chương trình. Luồng dữ liệu đề cập đến
việc truyền các giá trị từ một biến hoặc hằng số sang một biến khác.
Các định nghĩa và cách sử dụng các biến xác định khía cạnh luồng dữ
liệu trong một chương trình.
1.16 LẬP KẾ HOẠCH VÀ THIẾT KẾ THỬ NGHIỆM
Trong thử nghiệm chức năng, người ta không có quyền truy cập vào
các chi tiết bên trong của một chương trình và chương trình được coi
như một hộp đen. Kỹ sư kiểm thử chỉ quan tâm đến phần có thể truy
cập được bên ngoài chương trình, tức là chỉ đầu vào và kết quả có thể
nhìn thấy bên ngoài. Một kỹ sư thử nghiệm áp dụng đầu vào cho một
chương trình, quan sát kết quả có thể nhìn thấy bên ngoài của chương
trình và xác định liệu kết quả của chương trình có phải là kết quả
mong đợi hay không. Đầu vào được chọn từ đặc tả yêu cầu của
chương trình và thuộc tính của miền đầu vào và đầu ra của chương
trình. Một kỹ sư thử nghiệm chỉ quan tâm đến chức năng và các tính
năng được tìm thấy trong đặc tả của chương trình.
Tại thời điểm này, rất hữu ích để xác định sự khác biệt giữa các
phạm vi của kiểm tra cấu trúc và kiểm tra chức năng. Một người áp
dụng các kỹ thuật kiểm tra cấu trúc cho các đơn vị riêng lẻ của một
chương trình, trong khi các kỹ thuật kiểm tra chức năng có thể được
áp dụng cho cả một hệ thống và các đơn vị chương trình riêng lẻ. Vì
các lập trình viên cá nhân biết chi tiết về mã nguồn mà họ viết nên
bản thân họ thực hiện kiểm tra cấu trúc trên các đơn vị chương trình
riêng lẻ mà họ viết. Mặt khác, kiểm thử chức năng được thực hiện ở
cấp độ giao diện bên ngoài của hệ thống và nó được tiến hành bởi
một nhóm đảm bảo chất lượng phần mềm riêng biệt.
Chúng ta hãy xem xét một đơn vị chương trình U là một phần của
chương trình lớn hơn P. Một đơn vị chương trình chỉ là một đoạn mã
nguồn với một mục tiêu được xác định rõ ràng và các miền đầu vào
và đầu ra được xác định rõ ràng. Bây giờ, nếu một lập trình viên lấy
các trường hợp kiểm thử để kiểm tra U từ kiến thức về các chi tiết
bên trong của U, thì lập trình viên đó được cho là đang thực hiện
kiểm thử cấu trúc. Mặt khác, nếu người lập trình thiết kế các trường
hợp kiểm thử từ mục tiêu đã nêu của đơn vị U và từ kiến thức của họ
về các thuộc tính đặc biệt của các miền đầu vào và đầu ra của U, thì
người đó được cho là đang thực hiện kiểm thử chức năng trên cùng
đơn vị U.
Các ý tưởng về kiểm thử cấu trúc và kiểm thử chức năng không cung
cấp cho các lập trình viên và kỹ sư kiểm thử lựa chọn thiết kế các
trường hợp kiểm thử từ mã nguồn hay từ đặc tả yêu cầu của một
chương trình. Tuy nhiên, các chiến lược này được sử dụng bởi các
nhóm người khác nhau vào những thời điểm khác nhau trong vòng
61
đời của phần mềm. Ví dụ: các lập trình viên riêng lẻ sử dụng cả kỹ
thuật kiểm tra cấu trúc và chức năng để kiểm tra mã của riêng họ,
trong khi các kỹ sư đảm bảo chất lượng áp dụng ý tưởng kiểm thử
chức năng.
Bản thân việc kiểm tra cấu trúc hay kiểm tra chức năng đều không đủ
tốt để phát hiện hầu hết các lỗi. Ngay cả khi người ta chọn tất cả các
đầu vào có thể, một kỹ thuật kiểm tra cấu trúc không thể phát hiện tất
cả các lỗi nếu thiếu các đường dẫn trong một chương trình. Theo trực
quan, một đường dẫn được cho là bị thiếu nếu không có mã để xử lý
một điều kiện có thể xảy ra. Tương tự, nếu không có kiến thức về các
chi tiết cấu trúc của một chương trình, nhiều lỗi sẽ không được phát
hiện. Do đó, phải sử dụng kết hợp cả kỹ thuật kiểm thử cấu trúc và
chức năng trong kiểm thử chương trình.
1.16 LẬP KẾ HOẠCH VÀ THIẾT KẾ THỬ NGHIỆM
Mục đích của việc lập kế hoạch kiểm thử hệ thống, hay đơn giản là
lập kế hoạch kiểm thử, là để sẵn sàng và tổ chức cho việc thực hiện
kiểm thử. Một kế hoạch kiểm tra cung cấp một khuôn khổ, phạm vi,
chi tiết về nguồn lực cần thiết, nỗ lực cần thiết, lịch trình của các hoạt
động và ngân sách. Khuôn khổ là một tập hợp các ý tưởng, dữ kiện
hoặc hoàn cảnh mà các thử nghiệm sẽ được tiến hành. Phạm vi đã
nêu phác thảo lĩnh vực hoặc phạm vi của các hoạt động thử nghiệm.
Phạm vi bao gồm các khía cạnh quản lý của thử nghiệm, thay vì các
kỹ thuật chi tiết và các trường hợp thử nghiệm cụ thể.
Thiết kế kiểm thử là một giai đoạn quan trọng của kiểm thử phần
mềm. Trong giai đoạn thiết kế thử nghiệm, các yêu cầu hệ thống
được nghiên cứu kỹ lưỡng, các tính năng của hệ thống cần kiểm tra
được xác định kỹ lưỡng, và xác định mục tiêu của các trường hợp thử
nghiệm và hành vi chi tiết của các trường hợp thử nghiệm. Các mục
tiêu thử nghiệm được xác định từ các nguồn khác nhau, cụ thể là đặc
tả yêu cầu và đặc tả chức năng, và một hoặc nhiều trường hợp thử
nghiệm được thiết kế cho mỗi mục tiêu thử nghiệm. Mỗi trường hợp
thử nghiệm được thiết kế như một sự kết hợp của các thành phần thử
nghiệm mô-đun được gọi là các bước thử nghiệm. Các bước kiểm tra
này có thể được kết hợp với nhau để tạo ra các bài kiểm tra nhiều
bước, phức tạp hơn. Một trường hợp kiểm thử được chỉ định rõ ràng
để người khác có thể dễ dàng mượn, hiểu và sử dụng lại nó.
Thật thú vị khi lưu ý rằng một cách tiếp cận tập trung vào thử
nghiệm mới để phát triển hệ thống đang dần xuất hiện. Cách tiếp cận
này được gọi là phát triển theo hướng kiểm tra (TDD) [57]. Trong
phát triển theo hướng thử nghiệm, các lập trình viên thiết kế và triển
khai các trường hợp thử nghiệm trước khi mã sản xuất được viết.
Cách tiếp cận này là một thực tiễn quan trọng trong các quy trình
phát triển phần mềm nhanh nhẹn hiện đại như XP. Các đặc điểm
chính của quy trình phát triển phần mềm linh hoạt là (i) phát triển gia
tăng, (ii) mã hóa đơn vị và kiểm thử chấp nhận được thực hiện bởi
lập trình viên cùng với khách hàng, (iii) kiểm tra hồi quy thường
xuyên, và (iv) viết mã kiểm thử, một trường hợp kiểm thử tại một
thời điểm, trước mã sản xuất.
1.17 THI CÔNG KIỂM TRA THEO DÕI VÀ ĐO LƯỜNG
Giám sát và đo lường là hai nguyên tắc chính được tuân thủ trong
mọi nỗ lực khoa học và kỹ thuật. Các nguyên tắc tương tự cũng được
áp dụng cho các giai đoạn thử nghiệm của phát triển phần mềm. Điều
quan trọng là phải theo dõi một số số liệu thực sự đại diện cho tiến
trình thử nghiệm và tiết lộ mức chất lượng của hệ thống. Dựa trên
các số liệu đó, ban quản lý có thể kích hoạt các hành động khắc phục
và phòng ngừa. Bằng cách đưa ra một bộ thước đo nhỏ nhưng quan
trọng, ban quản lý điều hành sẽ có thể biết liệu họ có đang đi đúng
hướng hay không [58]. Các chỉ số thực thi kiểm tra có thể được phân
loại rộng rãi thành hai lớp như sau:
Các chỉ số để giám sát việc thực hiện kiểm tra
Các chỉ số để giám sát các khuyết tật
Lớp số liệu đầu tiên liên quan đến quá trình thực thi các trường hợp
thử nghiệm, trong khi lớp thứ hai liên quan đến các khiếm khuyết
được tìm thấy do kết quả của việc thực thi thử nghiệm. Các chỉ số
này cần được theo dõi và phân tích định kỳ, chẳng hạn như hàng
ngày hoặc hàng tuần. Để kiểm soát hiệu quả một dự án thử nghiệm,
điều quan trọng là phải thu thập thông tin hợp lệ và chính xác về dự
án. Một ví dụ như vậy là biết chính xác thời điểm kích hoạt tiêu chí
hoàn nguyên cho chu kỳ thử nghiệm và bắt đầu phân tích nguyên
nhân gốc rễ của
1.17 THI CÔNG KIỂM TRA THEO DÕI VÀ ĐO LƯỜNG
63
các vấn đề trước khi có thể thực hiện nhiều thử nghiệm hơn. Bằng
cách kích hoạt tiêu chí hoàn nguyên như vậy, người quản lý thử
nghiệm có thể sử dụng hiệu quả thời gian của các kỹ sư thử nghiệm
và có thể là tiền bạc, bằng cách tạm dừng chu kỳ thử nghiệm trên một
sản phẩm có quá nhiều lỗi để thực hiện một thử nghiệm hệ thống có
ý nghĩa. Nhóm quản lý phải xác định và giám sát các số liệu trong
khi quá trình thử nghiệm đang diễn ra để có thể đưa ra các quyết định
quan trọng [59]. Điều quan trọng là phải phân tích và hiểu các chỉ số
thử nghiệm, thay vì chỉ thu thập dữ liệu và đưa ra quyết định dựa trên
những dữ liệu thô đó. Các chỉ số chỉ có ý nghĩa nếu chúng cho phép
ban quản lý đưa ra các quyết định dẫn đến chi phí sản xuất thấp hơn,
giảm độ trễ trong giao hàng và cải thiện chất lượng của hệ thống
phần mềm.
Đánh giá định lượng là quan trọng trong mọi lĩnh vực khoa học và kỹ
thuật. Đánh giá định lượng được thực hiện thông qua đo lường. Phép
đo cho phép người ta đánh giá các thông số quan tâm theo cách định
lượng như sau:
Đánh giá hiệu quả của một kỹ thuật được sử dụng trong việc thực
hiện một nhiệm vụ. Người ta có thể đánh giá hiệu quả của một kỹ
thuật tạo thử nghiệm bằng cách đếm số lượng các khuyết tật được
phát hiện bởi các trường hợp thử nghiệm được tạo ra bằng cách tuân
theo kỹ thuật và những lỗi được phát hiện bởi các trường hợp thử
nghiệm được tạo ra bằng các phương tiện khác. • Đánh giá năng suất
của các hoạt động phát triển. Người ta có thể theo dõi năng suất bằng
cách đếm số lượng trường hợp thử nghiệm được thiết kế mỗi ngày,
số lượng trường hợp thử nghiệm được thực hiện mỗi ngày, v.v.
Đánh giá chất lượng của sản phẩm. Bằng cách theo dõi số lượng lỗi
được phát hiện mỗi tuần thử nghiệm, người ta có thể quan sát mức
chất lượng của hệ thống.
Đánh giá thử nghiệm sản phẩm. Để đánh giá quá trình thử nghiệm
sản phẩm, hai phép đo sau đây là rất quan trọng:
Chỉ số hiệu quả của trường hợp thử nghiệm: Mục tiêu của số liệu này
gấp đôi như được giải thích trong những điều sau: (1) đo lường “khả
năng phát hiện lỗi” của bộ thử nghiệm và (2) sử dụng số liệu này để
cải thiện quy trình thiết kế thử nghiệm. Trong các giai đoạn kiểm thử
đơn vị, tích hợp và hệ thống, các lỗi được phát hiện khi thực hiện các
trường hợp kiểm thử theo kế hoạch. Ngoài các lỗi này, các lỗi mới
cũng được tìm thấy trong giai đoạn thử nghiệm mà không có trường
hợp thử nghiệm nào được thiết kế. Đối với những lỗi mới này, các
trường hợp thử nghiệm mới được thêm vào bộ thử nghiệm. Các
trường hợp thử nghiệm mới đó được gọi là trường hợp thử nghiệm đã
thoát (TCE). Việc thoát thử nghiệm xảy ra do thiếu sót trong thiết kế
thử nghiệm. Nhu cầu thử nghiệm nhiều hơn xảy ra khi các kỹ sư thử
nghiệm có được những ý tưởng mới trong khi thực hiện các trường
hợp thử nghiệm theo kế hoạch.
Đo lường hiệu quả của nỗ lực thử nghiệm: Điều quan trọng là đánh
giá hiệu quả của nỗ lực thử nghiệm trong quá trình phát triển sản
phẩm. Sau khi một sản phẩm được triển khai tại địa điểm của khách
hàng, người ta quan tâm đến hiệu quả của thử nghiệm đã được thực
hiện. Một thước đo phổ biến để đánh giá hiệu quả của thử nghiệm là
số lượng lỗi do khách hàng tìm thấy mà các kỹ sư thử nghiệm không
tìm thấy trước khi phát hành sản phẩm. Những khiếm khuyết này đã
thoát khỏi nỗ lực thử nghiệm của chúng tôi.
1.18 CÔNG CỤ THỬ NGHIỆM VÀ TỰ ĐỘNG HÓA
Nói chung, kiểm thử phần mềm là một công việc đòi hỏi nhiều lao
động. Điều này là do các trường hợp thử nghiệm được tạo theo cách
thủ công và thường được thực thi theo cách thủ công. Hơn nữa, kết
quả của việc thực hiện thử nghiệm được phân tích thủ công. Thời
gian của những công việc đó có thể được rút ngắn bằng cách sử dụng
các công cụ thích hợp. Kỹ sư thử nghiệm có thể sử dụng nhiều công
cụ khác nhau, chẳng hạn như máy phân tích mã tĩnh, máy tạo dữ liệu
thử nghiệm và máy phân tích mạng, nếu một ứng dụng hoặc giao
thức dựa trên mạng đang được thử nghiệm. Những công cụ đó rất
hữu ích trong việc tăng hiệu quả và hiệu quả của thử nghiệm.
Tự động hóa kiểm tra là điều cần thiết cho bất kỳ bộ phận kiểm tra và
đảm bảo chất lượng nào của một tổ chức để tiến tới trở nên hiệu quả
hơn. Các lợi ích của tự động hóa thử nghiệm như sau:
Tăng năng suất của người thử nghiệm
Phạm vi kiểm tra hồi quy tốt hơn
Giảm thời lượng của các giai đoạn thử nghiệm
Giảm chi phí bảo trì phần mềm
Tăng hiệu quả của các trường hợp thử nghiệm
65
Tự động hóa thử nghiệm tạo cơ hội để cải thiện kỹ năng của các kỹ
sư thử nghiệm bằng cách viết chương trình, và do đó nâng cao tinh
thần của họ. Họ sẽ tập trung hơn vào việc phát triển các trường hợp
kiểm thử tự động để tránh trở thành nút thắt trong việc cung cấp sản
phẩm ra thị trường. Do đó, kiểm thử phần mềm trở thành một công
việc ít tẻ nhạt hơn.
Tự động hóa kiểm tra cải thiện phạm vi kiểm thử hồi quy do tích lũy
các trường hợp kiểm thử tự động theo thời gian. Tự động hóa cho
phép một tổ chức tạo ra một thư viện phong phú các trường hợp kiểm
thử có thể tái sử dụng và tạo điều kiện thực hiện một tập hợp các
trường hợp kiểm thử nhất quán. Ở đây, tính nhất quán có nghĩa là
khả năng của chúng tôi để tạo ra kết quả lặp lại cho cùng một tập hợp
các bài kiểm tra. Có thể rất khó để tạo lại kết quả thử nghiệm trong
thử nghiệm thủ công, bởi vì các điều kiện chính xác tại thời điểm và
điểm hư hỏng có thể không được biết chính xác. Trong kiểm thử tự
động, việc thiết lập các điều kiện ban đầu của hệ thống trở nên dễ
dàng hơn, do đó dễ dàng tái tạo các kết quả kiểm tra hơn. Tự động
hóa kiểm tra đơn giản hóa công việc gỡ lỗi bằng cách cung cấp nhật
ký chi tiết, rõ ràng về các hoạt động và các bước kiểm tra trung gian.
Điều này dẫn đến một cách tiếp cận thử nghiệm có tổ chức, có cấu
trúc và có thể tái tạo hơn.
Việc thực hiện tự động các trường hợp thử nghiệm làm giảm thời
gian đã trôi qua để thử nghiệm và do đó, nó dẫn đến thời gian đưa ra
thị trường ngắn hơn. Các trường hợp kiểm thử tự động tương tự có
thể được thực hiện theo cách không bị giám sát vào ban đêm, do đó
sử dụng hiệu quả các nền tảng khác nhau, chẳng hạn như phần cứng
và cấu hình. Nói tóm lại, tự động hóa làm tăng hiệu quả thực thi thử
nghiệm. Tuy nhiên, khi kết thúc quá trình kiểm thử, điều quan trọng
là phải phân tích kết quả kiểm tra để xác định số lượng trường hợp
kiểm thử đạt hay không đạt. Và, nếu một trường hợp thử nghiệm
không thành công, người ta sẽ phân tích lý do cho sự thất bại của nó.
Về lâu dài, tự động hóa thử nghiệm có hiệu quả về chi phí. Nó làm
giảm đáng kể chi phí bảo trì phần mềm. Trong giai đoạn duy trì của
một hệ thống phần mềm, các bài kiểm tra hồi quy được yêu cầu sau
mỗi lần thay đổi hệ thống là quá nhiều. Kết quả là, kiểm thử hồi quy
trở nên tốn quá nhiều thời gian và công sức nếu không có tự động
hóa.
1.18 CÔNG CỤ THỬ NGHIỆM VÀ TỰ ĐỘNG HÓA

Một loại kiểm thử lặp đi lặp lại rất cồng kềnh và tốn kém để thực
hiện thủ công, nhưng nó có thể được tự động hóa dễ dàng bằng cách
sử dụng các công cụ phần mềm. Một loại ứng dụng lặp đi lặp lại đơn
giản có thể làm rò rỉ bộ nhớ trong một phần mềm. Tuy nhiên, ứng
dụng phải được chạy trong một thời gian dài đáng kể, ví dụ, trong
nhiều tuần, để lộ bộ nhớ bị rò rỉ. Do đó, việc kiểm tra thủ công có thể
không hợp lý, trong khi với tự động hóa, việc rò rỉ bộ nhớ rất dễ xảy
ra. Ví dụ, thử nghiệm căng thẳng là một ứng cử viên hàng đầu cho tự
động hóa. Thử nghiệm căng thẳng đòi hỏi tải trong trường hợp xấu
nhất trong một thời gian dài, điều này rất khó thực hiện bằng phương
pháp thủ công. Kiểm tra khả năng mở rộng là một lĩnh vực khác có
thể được tự động hóa. Thay vì tạo ra một giường thử nghiệm lớn với
hàng trăm thiết bị, người ta có thể phát triển một trình mô phỏng để
xác minh khả năng mở rộng của hệ thống.
Tự động hóa kiểm tra rất hấp dẫn, nhưng nó đi kèm với một thẻ giá.
Cần phân bổ đủ thời gian và nguồn lực để phát triển bộ kiểm thử tự
động. Việc phát triển các trường hợp kiểm thử tự động cần được
quản lý giống như một dự án lập trình. Đó là, nó nên được thực hiện
một cách có tổ chức; nếu không thì khả năng thất bại là rất cao. Một
bộ thử nghiệm tự động có thể mất nhiều thời gian hơn để phát triển vì
bộ thử nghiệm cần được gỡ lỗi trước khi có thể được sử dụng để thử
nghiệm. Cần phân bổ đủ thời gian và nguồn lực để duy trì bộ kiểm
thử tự động và thiết lập môi trường kiểm tra. Hơn nữa, mỗi khi hệ
thống được sửa đổi, việc sửa đổi phải được phản ánh trong bộ kiểm
thử tự động. Do đó, một bộ kiểm thử tự động nên được thiết kế như
một hệ thống mô-đun, được điều phối thành các thư viện có thể tái sử
dụng, được tham chiếu chéo và có thể truy xuất trở lại tính năng đang
được kiểm tra.
Điều quan trọng cần nhớ là tự động hóa thử nghiệm không thể thay
thế thử nghiệm thủ công. Sự sáng tạo, khả năng biến đổi và khả năng
quan sát của con người không thể bị bắt chước thông qua tự động
hóa. Tự động hóa không thể phát hiện một số vấn đề mà con người
có thể dễ dàng quan sát được. Thử nghiệm tự động không tạo ra các
biến thể nhỏ theo cách mà con người có thể làm được. Một số loại
kiểm tra nhất định, chẳng hạn như khả năng sử dụng, khả năng tương
tác, tính mạnh mẽ và khả năng tương thích, thường không phù hợp
67
với tự động hóa. Quá khó để tự động hóa tất cả các trường hợp thử
nghiệm; thường thì 50% của tất cả các trường hợp kiểm thử cấp hệ
thống có thể được tự động hóa. Sẽ luôn cần một số thử nghiệm thủ
công, ngay cả khi tất cả các trường hợp thử nghiệm cấp hệ thống đều
được tự động hóa.
Mục tiêu của tự động hóa thử nghiệm không phải để giảm số lượng
người đứng đầu trong bộ phận thử nghiệm của một tổ chức, mà để
cải thiện năng suất, chất lượng và hiệu quả của việc thực hiện thử
nghiệm. Trên thực tế, tự động hóa kiểm thử yêu cầu số lượng người
đứng đầu lớn hơn trong bộ phận kiểm thử trong năm đầu tiên, vì bộ
phận này cần tự động hóa các trường hợp kiểm thử và đồng thời tiếp
tục thực hiện các kiểm thử thủ công. Ngay cả sau khi hoàn thành việc
phát triển khung tự động thử nghiệm và các thư viện trường hợp thử
nghiệm, số lượng người đứng đầu trong bộ phận thử nghiệm không
giảm xuống dưới mức ban đầu. Tổ chức kiểm thử cần giữ lại các
thành viên trong nhóm ban đầu để cải thiện chất lượng bằng cách
thêm nhiều trường hợp thử nghiệm hơn vào kho lưu trữ trường hợp
thử nghiệm tự động.
Trước khi một dự án tự động hóa thử nghiệm có thể được tiến hành,
tổ chức phải đánh giá và giải quyết một số cân nhắc. Danh sách các
điều kiện tiên quyết sau đây phải được xem xét để đánh giá liệu tổ
chức đã sẵn sàng cho việc tự động hóa thử nghiệm hay chưa:
Các trường hợp kiểm thử được tự động hóa đã được xác định rõ.
Các công cụ kiểm tra và cơ sở hạ tầng đã có sẵn.
Các chuyên gia tự động hóa thử nghiệm đã có kinh nghiệm thành
công trước đó trong tự động hóa. • Ngân sách thích hợp nên được
phân bổ cho việc mua sắm các công cụ phần mềm.
1.19 TỔ CHỨC VÀ QUẢN LÝ ĐỘI KIỂM TRA
Kiểm thử là một hoạt động phân tán được tiến hành ở các cấp độ
khác nhau trong suốt vòng đời của phần mềm. Các cấp độ khác nhau
này là kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống và kiểm
thử chấp nhận. Hợp lý là có các nhóm thử nghiệm khác nhau trong
một tổ chức cho mỗi cấp độ thử nghiệm. Tuy nhiên, hợp lý hơn - và
là trường hợp trong thực tế - các bài kiểm tra mức đơn vị được phát
triển và thực hiện bởi chính các lập trình viên chứ không phải một
nhóm kỹ sư kiểm thử đơn vị độc lập. Lập trình viên phát triển một
đơn vị phần mềm nên có quyền sở hữu và chịu trách nhiệm sản xuất
phần mềm chất lượng tốt theo sự hài lòng của mình. Kiểm thử tích
hợp hệ thống được thực hiện bởi các kỹ sư kiểm tra tích hợp hệ
thống. Các kỹ sư kiểm thử tích hợp tham gia cần phải biết rất rõ về
các mô-đun phần mềm. Điều này có nghĩa là tất cả các kỹ sư phát
triển đã xây dựng chung tất cả các đơn vị được tích hợp cần phải
tham gia vào thử nghiệm tích hợp. Ngoài ra, các kỹ sư kiểm tra tích
hợp nên biết kỹ lưỡng cơ chế xây dựng, đây là chìa khóa để tích hợp
các hệ thống lớn.
Nhóm thực hiện kiểm tra cấp hệ thống thực sự được tách biệt với
nhóm phát triển và nó thường có số lượng người đứng đầu riêng và
ngân sách riêng. Nhiệm vụ của nhóm này là đảm bảo rằng các yêu
cầu hệ thống đã được đáp ứng và hệ thống có thể chấp nhận được.
Các thành viên của nhóm kiểm tra hệ thống tiến hành các hạng mục
kiểm tra khác nhau, chẳng hạn như chức năng, độ mạnh mẽ, căng
thẳng, tải, khả năng mở rộng, độ tin cậy và hiệu suất. Họ cũng thực
hiện các bài kiểm tra chấp nhận nghiệp vụ được xác định trong kế
hoạch kiểm tra chấp nhận của người dùng để đảm bảo rằng hệ thống
cuối cùng sẽ vượt qua kiểm tra chấp nhận của người dùng tại trang
web của khách hàng. Tuy nhiên, thử nghiệm chấp nhận người dùng
thực được thực hiện bởi nhóm người dùng đặc biệt của khách hàng.
Nhóm người dùng bao gồm những người từ các nền tảng khác nhau,
chẳng hạn như kỹ sư đảm bảo chất lượng phần mềm, cộng tác viên
kinh doanh và kỹ sư hỗ trợ khách hàng. Một thực tế phổ biến là tạo
một nhóm kiểm tra chấp nhận người dùng tạm thời bao gồm những
người có nền tảng khác nhau, chẳng hạn như kỹ sư kiểm tra tích hợp,
kỹ sư kiểm tra hệ thống, kỹ sư hỗ trợ khách hàng và kỹ sư tiếp thị.
Sau khi người dùng chấp nhận hoàn thành, nhóm sẽ được tháo dỡ.
Nên có ít nhất hai nhóm thử nghiệm trong một tổ chức: nhóm thử
nghiệm tích hợp và nhóm thử nghiệm hệ thống.
Việc thuê và giữ chân các kỹ sư thử nghiệm là những nhiệm vụ đầy
thách thức. Phỏng vấn là cơ chế chính để đánh giá người nộp đơn.
Phỏng vấn là một kỹ năng được cải thiện khi thực hành. Cần phải có
một quy trình tuyển dụng để có hiệu quả trong việc tuyển dụng các
kỹ sư thử nghiệm xuất sắc. Để giữ chân các kỹ sư thử nghiệm, ban
lãnh đạo phải nhận ra tầm quan trọng của các nỗ lực thử nghiệm
ngang bằng với các nỗ lực phát triển. Ban quản lý nên coi các kỹ sư
69
thử nghiệm là các chuyên gia và là một phần của nhóm tổng thể cung
cấp các sản phẩm chất lượng.
1.20 NGOÀI SÁCH
1.20 NGOÀI SÁCH
Với phần giới thiệu cấp cao ở trên về chất lượng và kiểm thử phần
mềm, bây giờ chúng tôi đã sẵn sàng để phác thảo các chương còn lại.
Mỗi chương trong cuốn sách bao gồm các chủ đề kỹ thuật, quy trình
và / hoặc quản lý liên quan đến kiểm thử phần mềm. Các chủ đề đã
được thiết kế và sắp xếp để tạo điều kiện cho người đọc trở thành
một chuyên gia kiểm thử phần mềm. Trong Chương 2, chúng tôi
cung cấp phần giới thiệu khép kín về lý thuyết và các hạn chế của
kiểm thử phần mềm.
Các chương từ 3 đến 6 xử lý từng kỹ thuật thử nghiệm đơn vị một,
càng định lượng càng tốt. Các chương này mô tả cả kiểm thử đơn vị
tĩnh và động. Kiểm thử đơn vị tĩnh đã được trình bày trong một
khuôn khổ chung được gọi là xem xét mã, thay vì các kỹ thuật riêng
lẻ được gọi là kiểm tra và hướng dẫn. Kiểm thử đơn vị động, hoặc
kiểm thử đơn vị dựa trên thực thi, tập trung vào kiểm soát luồng,
luồng dữ liệu và thử nghiệm miền. Khung JUnit, được sử dụng để tạo
và thực thi các bài kiểm tra đơn vị động, được giới thiệu. Chúng tôi
thảo luận về một số công cụ để thực hiện hiệu quả kiểm thử đơn vị.
Chương 7 thảo luận về khái niệm kiểm thử tích hợp. Cụ thể, năm loại
kỹ thuật tích hợp, cụ thể là từ trên xuống, từ dưới lên, bánh sandwich,
vụ nổ lớn và tăng dần, được giải thích. Tiếp theo, chúng ta thảo luận
về việc tích hợp các thành phần phần cứng và phần mềm để tạo thành
một hệ thống hoàn chỉnh. Chúng tôi giới thiệu một khuôn khổ để
phát triển kế hoạch kiểm thử tích hợp hệ thống. Chương này được
hoàn thành với một cuộc thảo luận ngắn gọn về thử nghiệm tích hợp
của các thành phần sẵn có.
Các chương 8–13 thảo luận về các khía cạnh khác nhau của kiểm thử
cấp hệ thống. Sáu chương này giới thiệu cho người đọc các chi tiết
kỹ thuật của kiểm thử hệ thống vốn là thực hành trong công nghiệp.
Các chương này thúc đẩy đánh giá cả định tính và định lượng của
một quá trình thử nghiệm hệ thống. Các chương nhấn mạnh sự cần
thiết phải có một nhóm kiểm thử hệ thống độc lập. Một quy trình
giám sát và kiểm soát thử nghiệm hệ thống được giải thích rõ ràng.
Chương 14 dành cho kiểm tra chấp nhận, bao gồm các tiêu chí kiểm
tra chấp nhận, lập kế hoạch kiểm tra chấp nhận và thực hiện kiểm tra
chấp nhận.
Chương 15 bao gồm các khái niệm cơ bản về độ tin cậy của phần
mềm và ứng dụng của chúng vào kiểm thử phần mềm. Chúng tôi
thảo luận về khái niệm hồ sơ hoạt động và ứng dụng của nó trong thử
nghiệm hệ thống. Chúng tôi kết thúc chương với mô tả về một ví dụ
và thời gian phát hành một hệ thống bằng cách xác định độ dài bổ
sung của thử nghiệm hệ thống. Thời gian thử nghiệm bổ sung được
tính bằng cách sử dụng ý tưởng về độ tin cậy của phần mềm.
Trong Chương 16, chúng tôi trình bày cấu trúc của các nhóm kiểm
thử và cách các nhóm này có thể được tổ chức trong một công ty
phần mềm. Tiếp theo, chúng tôi thảo luận về cách thuê và giữ chân
các kỹ sư thử nghiệm bằng cách cung cấp đào tạo, thiết lập hệ thống
khen thưởng và thiết lập một con đường sự nghiệp hấp dẫn cho họ
trong tổ chức thử nghiệm. Chúng tôi kết thúc chương này với mô tả
về cách xây dựng và quản lý một nhóm thử nghiệm với trọng tâm là
làm việc theo nhóm hơn là lợi ích cá nhân.
Chương 17 và 18 giải thích các khái niệm về chất lượng phần mềm
và các mô hình trưởng thành khác nhau. Chương 17 tập trung vào
các yếu tố và tiêu chí chất lượng và mô tả các tiêu chuẩn ISO 9126
và ISO 9000: 2000. Chương 18 bao gồm CMM, được phát triển bởi
SEI tại Đại học Carnegie Mellon. Hai mô hình liên quan đến thử
nghiệm, cụ thể là mô hình TPI và TMM, được giải thích ở cuối
Chương 18.
Chúng tôi xác định các từ chính được sử dụng trong sách trong phần
chú giải ở cuối sách. Người đọc sẽ tìm thấy khoảng 10 bài tập thực
hành ở cuối mỗi chương. Một danh sách các tài liệu tham khảo được
bao gồm ở cuối mỗi chương cho độc giả muốn tìm kiếm các cuộc
thảo luận chi tiết hơn về một số chủ đề. Cuối cùng, mỗi chương,
ngoại trừ chương này, chứa một phần đánh giá tài liệu, về cơ bản,
cung cấp các gợi ý đến tài liệu nâng cao hơn liên quan đến các chủ
đề. Các tài liệu nâng cao hơn dựa trên nghiên cứu hiện tại và các
quan điểm thay thế.
CHAPTER
2
TheoryofProgramTesting
Người nào yêu thích thực hành mà không có lý thuyết cũng giống
như người thủy thủ lên [a] con tàu mà không có bánh lái và la bàn và
không bao giờ biết mình có thể đặt ở đâu.
—LeonardodaVinci
2.1 CÁC KHÁI NIỆM CƠ BẢN TRONG KIỂM TRA LÝ
THUYẾT
Ý tưởng về kiểm thử chương trình cũng cũ như lập trình máy tính.
Khi các chương trình máy tính ngày càng lớn hơn kể từ những ngày
đầu của chúng vào những năm 1960, nhu cầu loại bỏ các khuyết tật
khỏi chúng một cách có hệ thống đã nhận được nhiều sự quan tâm
hơn. Cả cộng đồng nghiên cứu và các học viên đều tham gia sâu hơn
vào việc kiểm thử phần mềm. Do đó, vào những năm 1970, một lĩnh
vực nghiên cứu mới được gọi là lý thuyết thử nghiệm đã xuất hiện.
Lý thuyết kiểm tra nhấn mạnh vào những điều sau:
Phát hiện lỗi thông qua kiểm tra dựa trên thực thi
Thiết kế các trường hợp kiểm thử từ các nguồn khác nhau, cụ thể là
đặc tả yêu cầu, mã nguồn và các miền đầu vào và đầu ra của chương
trình
Chọn một tập hợp con các trường hợp thử nghiệm từ tập hợp tất cả
các trường hợp thử nghiệm có thể có [1, 2]
Hiệu quả của chiến lược lựa chọn trường hợp thử nghiệm [3–5]
Phép thử được sử dụng trong quá trình thử nghiệm [6, 7]
Ưu tiên thực hiện các trường hợp kiểm thử đã chọn [8]
Phân tích đầy đủ các trường hợp thử nghiệm [9–15]
Nền tảng lý thuyết về kiểm thử cung cấp cho người kiểm tra và nhà
phát triển cái nhìn sâu sắc có giá trị về hệ thống phần mềm và quy
trình phát triển. Do đó, người kiểm thử thiết kế các trường hợp kiểm
thử hiệu quả hơn với chi phí thấp hơn. Trong khi xem xét lý thuyết
kiểm tra, có thể có một kỳ vọng lớn rằng nó cho phép chúng ta phát
72 CHƯƠNG 2 LÝ THUYẾT VỀ KIỂM TRA CHƯƠNG TRÌNH
hiện tất cả các khiếm khuyết trong một chương trình máy tính. Bất kỳ
lý thuyết kiểm thử nào cũng phải kế thừa giới hạn cơ bản của kiểm
thử. Hạn chế của kiểm tra đã được Dijkstra nói rõ nhất: Kiểm tra chỉ
có thể tiết lộ sự hiện diện của lỗi, không bao giờ là sự vắng mặt của
chúng [16]. Bất chấp
31
hạn chế cho biết, thử nghiệm vẫn là phương pháp thực tế và đáng tin
cậy nhất để phát hiện khuyết tật và cải tiến chất lượng.
Trong chương này, ba lý thuyết kiểm thử nổi tiếng sẽ được thảo luận.
Đó là lý thuyết của Goodenough và Gerhart [17], lý thuyết của
Weyuker và Ostrand [18], và lý thuyết của Gourlay [19].
Goodenough và Gerhart đã giới thiệu một số khái niệm chính như
kiểm tra lý tưởng, độ tin cậy và tính hợp lệ của kiểm tra, tiêu chí lựa
chọn kiểm tra, kiểm tra kỹ lưỡng và năm loại lỗi chương trình.
Weyuker và Ostrand đã tinh chỉnh một số ý tưởng trên dưới dạng tiêu
chí đáng tin cậy thống nhất, tiêu chí hợp lệ thống nhất và thử nghiệm
lý tưởng thống nhất. Gourlay đã giới thiệu khái niệm về hệ thống thử
nghiệm và phương pháp chung để so sánh các phương pháp thử
nghiệm khác nhau.
2.2 LÝ THUYẾT VỀ GOODENOUGH VÀ GERHART
Goodenough và Gerhart đã xuất bản một bài báo lớn [17] vào năm
1975 về lựa chọn dữ liệu thử nghiệm. Bài báo này đã đưa ra một khái
niệm thử nghiệm cơ bản, xác định một số loại lỗi chương trình và
đưa ra lý thuyết để lựa chọn dữ liệu thử nghiệm từ miền đầu vào của
một chương trình. Mặc dù lý thuyết này không phải là không có
những lời chỉ trích, nhưng nó được trích dẫn rộng rãi và được đánh
giá cao trong cộng đồng nghiên cứu về kiểm thử phần mềm.
2.2.1 Các khái niệm cơ bản
Gọi D là miền đầu vào của chương trình P. Gọi T ⊆ D. Kết quả của
việc thực hiện P với đầu vào d ∈ D được ký hiệu là P (d) (Hình 2.1):
73
OK (d): Xác định một vị từ OK (d) thể hiện khả năng chấp nhận kết
quả P (d). Do đó, OK (d) = true nếu và chỉ khi P (d) là một kết quả có
thể chấp nhận được.
SUCCESSFUL (T): Với T ⊆ D cho trước, T là một phép thử thành
công, ký hiệu là SUCCESSFUL (T), nếu và chỉ khi, ∀ t ∈ T, OK (t).
Do đó, SUCCESSFUL (T) = true nếu và chỉ khi, ∀ t ∈ T, OK (t).
Thử nghiệm lý tưởng: T tạo thành một thử nghiệm lý tưởng nếu
Được (t) ∀ t ∈ T ⇒ Được (d) ∀ d ∈ D
Một bài kiểm tra lý tưởng được diễn giải như sau. Nếu từ việc thực
hiện thành công một mẫu miền đầu vào, chúng ta có thể kết luận rằng
chương trình không có lỗi, thì mẫu đó là một phép thử lý tưởng. Các
học viên có thể
Input domainD
Program P(d)
T P
Hình 2.1 Thực thi một chương trình với một tập con của miền
đầu vào.
diễn giải một cách lỏng lẻo "không có lỗi" là "không có nhiều lỗi gây
ra hậu quả nghiêm trọng." Tính hợp lệ của định nghĩa trên về một bài
kiểm tra lý tưởng phụ thuộc vào cách thực hiện bài tập T “kỹ lưỡng”
P. Một số người đánh đồng bài kiểm tra kỹ lưỡng với bài kiểm tra
toàn bộ hoặc toàn bộ, trong trường hợp đó T = D.
COMPLETE (T, C): Kiểm tra kỹ lưỡng T được định nghĩa là một
kiểm tra thỏa mãn COMPLETE (T, C), trong đó COMPLETE là một
vị từ xác định cách một số tiêu chí lựa chọn kiểm tra C được sử dụng
để chọn một tập dữ liệu kiểm tra cụ thể T từ D . COMPLETE (T, C)
sẽ được định nghĩa trong phần sau của phần này. Về cơ bản, C xác
định các thuộc tính của một chương trình phải được thực hiện để tạo
thành một bài kiểm tra toàn diện.
Tiêu chí đáng tin cậy: Tiêu chí lựa chọn C là đáng tin cậy nếu và chỉ
khi mọi thử nghiệm được chọn bởi C đều thành công hoặc không thử
nghiệm nào được chọn thành công. Vì vậy, độ tin cậy đề cập đến tính
nhất quán.
Tiêu chí hợp lệ: Tiêu chí lựa chọn C hợp lệ nếu và chỉ khi P không
đúng C chọn ít nhất một bộ thử nghiệm T không thành công đối với
P. Do đó, tính hợp lệ đề cập đến khả năng tạo ra kết quả có ý nghĩa.
Fundamental Theorem. (∃T ⊆ D)(COMPLETE(T,C) ∧
RELIABLE(C) ∧ VALID(C) ∧ SUCCESSFUL(T)) ⇒ (∀d ∈
D)OK(d)
Proof.
Gọi P là một chương trình và D là tập đầu vào của P. Gọi d là thành
viên của D. Chúng ta giả sử rằng P không thành công trên đầu vào d.
Nói cách khác, kết quả thực tế của việc thực hiện P với đầu vào d
không giống như kết quả mong đợi. Ở dạng ký hiệu của chúng ta, ¬
OK (d) là đúng. VALID (C) ngụ ý rằng tồn tại một bộ dữ liệu kiểm
tra T hoàn chỉnh sao cho ¬ THÀNH CÔNG (T). RELIABLE (C) ngụ
ý rằng nếu một thử nghiệm hoàn chỉnh không thành công, tất cả các
thử nghiệm đều thất bại. Tuy nhiên, điều này dẫn đến một mâu thuẫn
là tồn tại một bài kiểm tra hoàn chỉnh được thực hiện thành công.
Người ta có thể bị cám dỗ để tìm ra một tiêu chí đáng tin cậy và hợp
lệ, nếu nó tồn tại, để có thể phát hiện ra tất cả các lỗi với một tập hợp
nhỏ các trường hợp thử nghiệm. Tuy nhiên, có một số khó khăn trong
việc áp dụng lý thuyết trên, như được giải thích như sau:
Vì lỗi trong một chương trình là không xác định, nên không thể
chứng minh độ tin cậy và tính hợp lệ của một tiêu chí. Một tiêu chí
được đảm bảo là đáng tin cậy và hợp lệ nếu nó chọn toàn bộ miền
đầu vào D. Tuy nhiên, điều này là không mong muốn và không thực
tế.
Cả độ tin cậy và tính hợp lệ đều không được bảo toàn trong quá trình
gỡ lỗi, khi các lỗi liên tục biến mất.
Nếu chương trình P đúng, thì bất kỳ thử nghiệm nào cũng thành công
và mọi tiêu chí lựa chọn đều đáng tin cậy và hợp lệ.
Nếu P không đúng, nói chung không có cách nào để biết liệu một
tiêu chí có lý tưởng hay không nếu không biết các lỗi trong P.
2.2.2 Lý thuyết về kiểm tra
Gọi D là miền đầu vào của chương trình P. Gọi C là tập các vị từ
kiểm tra. Nếu d ∈ D thỏa mãn vị từ kiểm tra c ∈ C, thì c (d) được cho
là đúng. Chọn dữ liệu để thỏa mãn một vị từ kiểm tra có nghĩa là
chọn dữ liệu để thực hiện tổ hợp điều kiện trong quá trình thực thi P.
75
Với ý tưởng trên, COMPLETE (T, C), trong đó T ⊆ D, được định
nghĩa như sau:
COMPLETE(T,C) ≡ (∀c ∈ C)(∃t ∈ T)c(t) ∧ (∀t ∈ T)(∃c ∈ C)c(t)
Lý thuyết trên có nghĩa là, đối với mọi vị từ kiểm tra, chúng tôi chọn
một kiểm tra sao cho vị từ kiểm tra được thỏa mãn. Ngoài ra, đối với
mọi thử nghiệm được chọn, tồn tại một vị từ thử nghiệm được thỏa
mãn bởi thử nghiệm đã chọn. Các định nghĩa về một thử nghiệm lý
tưởng và tính kỹ lưỡng của một thử nghiệm không tiết lộ bất kỳ mối
quan hệ nào giữa chúng. Tuy nhiên, chúng ta có thể thiết lập mối
quan hệ giữa hai người theo cách sau.
Gọi B là tập hợp các lỗi (hoặc lỗi) trong một chương trình P được tiết
lộ bởi một thử nghiệm lý tưởng T I. Để một kỹ sư kiểm thử xác định
một tập hợp các vị từ kiểm tra C 1 và thiết kế một tập hợp các trường
hợp kiểm tra T 1 , sao cho thỏa mãn COMPLETE (T 1 , C 1 ). Gọi B 1
đại diện cho tập hợp các lỗi được tiết lộ bởi T 1 . Không có gì đảm
bảo rằng T 1 tiết lộ tất cả các lỗi. Sau đó, kỹ sư thử nghiệm xác định
một tập hợp các vị từ thử nghiệm lớn hơn C 2 sao cho C 2 ⊃ C 1 và
thiết kế một tập hợp các trường hợp thử nghiệm mới T 2 sao cho thỏa
mãn T 2 ⊃ T 1 và COMPLETE (T 2 , C 2 ). Gọi B 2 là tập hợp các lỗi
được tiết lộ bởi T 2 . Giả sử rằng các trường hợp thử nghiệm bổ sung
được chọn phát hiện ra nhiều lỗi hơn, chúng ta có B 2 ⊃ B 1 . Nếu kỹ
sư thử nghiệm lặp lại quá trình này, cuối cùng anh ta có thể xác định
một tập hợp các vị từ thử nghiệm C I và thiết kế một tập hợp các
trường hợp thử nghiệm T I sao cho thỏa mãn COMPLETE (T I , C I )
và T I tiết lộ toàn bộ tập hợp các lỗi B Trong trường hợp này, T I là
một thử nghiệm toàn diện thỏa mãn COMPLETE (T I , C I ) và đại
diện cho một tập hợp thử nghiệm lý tưởng.
2.2.3 Lỗi chương trình
Bất kỳ cách tiếp cận nào để kiểm tra đều dựa trên các giả định về
cách xảy ra lỗi của chương trình. Lỗi do hai nguyên nhân chính:
Lỗi xảy ra do sự hiểu biết không đầy đủ của chúng tôi về tất cả các
điều kiện mà một chương trình phải đối phó.
Lỗi xảy ra do chúng tôi không nhận ra rằng một số điều kiện kết hợp
nhất định yêu cầu các phương pháp điều trị đặc biệt.
Goodenough và Gerhart phân loại các lỗi chương trình như sau:
Lỗi logic: Loại lỗi này có nghĩa là một chương trình tạo ra kết quả
không chính xác, không phụ thuộc vào tài nguyên được yêu cầu. Có
nghĩa là, chương trình không thành công do các lỗi có trong chương
trình chứ không phải do thiếu tài nguyên. Các lỗi logic có thể được
chia thành ba loại:
Lỗi yêu cầu: Điều này có nghĩa là chúng tôi không nắm bắt được yêu
cầu thực sự của khách hàng.
Lỗi thiết kế: Điều này cho thấy chúng tôi không đáp ứng được yêu
cầu đã hiểu.
Lỗi xây dựng: Điều này thể hiện sự thất bại của chúng tôi trong việc
đáp ứng một thiết kế. Giả sử rằng một bước thiết kế cho biết “Sắp
xếp mảng A.” Để sắp xếp mảng có N phần tử, người ta có thể chọn
một trong một số thuật toán sắp xếp. Để cho
for (i = 0; i < N; i++) {
:
}
là cấu trúc vòng lặp for mong muốn để sắp xếp mảng. Nếu một lập
trình viên viết vòng lặp for dưới dạng
for (i = 0; i <= N; i++){
:
}
sau đó xảy ra lỗi xây dựng trong quá trình thực hiện.
• Lỗi hiệu suất: Loại lỗi này dẫn đến việc chương trình không thể
tạo ra kết quả mong đợi trong giới hạn tài nguyên được chỉ định hoặc
mong muốn.
Việc kiểm tra kỹ lưỡng phải có khả năng phát hiện ra các lỗi phát
sinh từ bất kỳ lý do nào ở trên. Tiêu chí lựa chọn dữ liệu thử nghiệm
phải phản ánh thông tin thu được từ mỗi giai đoạn phát triển phần
mềm. Vì mỗi loại lỗi được biểu hiện dưới dạng tác động không phù
hợp do quá trình triển khai tạo ra, nên sẽ hữu ích nếu phân loại các
nguồn lỗi theo thuật ngữ triển khai như sau:
Thiếu các đường dẫn luồng điều khiển: Theo trực quan, đường dẫn
luồng điều khiển, hay đơn giản là một đường dẫn, là một chuỗi
hướng dẫn khả thi trong một chương trình. Một đường dẫn có thể bị
thiếu trong chương trình nếu chúng ta không xác định được điều kiện
và chỉ định đường dẫn để xử lý điều kiện đó. Một ví dụ về đường dẫn
bị thiếu là chúng ta không thể kiểm tra ước số 0 trước khi thực hiện
phép chia. Nếu chúng tôi không nhận ra rằng một số chia có thể nhận
77
giá trị 0, thì chúng tôi sẽ không đưa vào một đoạn mã để xử lý trường
hợp đặc biệt. Do đó, một tính toán mong muốn nhất định sẽ bị thiếu
trong chương trình.
Lựa chọn đường dẫn không phù hợp: Một chương trình thực hiện
một đường dẫn không phù hợp nếu một điều kiện được thể hiện
không chính xác. Trong Hình 2.2, chúng tôi cho thấy một hành vi
mong muốn và một hành vi được thực hiện. Cả hai hành vi đều giống
nhau ngoại trừ trong phần điều kiện của câu lệnh if. Phần if của hành
vi được triển khai có chứa điều kiện bổ sung B. Có thể dễ dàng thấy
rằng
Hành vi mong Hành vi đã thực hiện
muốn
nếu (A) proc1 if (A && B) proc1 ();
();
else proc2 else proc2 ();
();
Hình 2.2 Ví dụ về lựa chọn đường dẫn không phù hợp.
cả phần mong muốn và phần được triển khai đều hoạt động theo
cùng một cách đối với tất cả các kết hợp giá trị của A và B ngoại trừ
khi A = 1 và B = 0.
Hành động không phù hợp hoặc bị thiếu: Có ba trường hợp của loại
lỗi này:
Người ta có thể tính toán một giá trị bằng một phương pháp không
nhất thiết phải cho kết quả chính xác. Ví dụ, một biểu thức mong
muốn là x = x × w , trong khi nó bị viết sai thành x = x + w . Hai biểu
thức này tạo ra kết quả giống hệt nhau cho một số kết hợp của x và w
, chẳng hạn như x = 1,5 và w = 3, chẳng hạn.
Không thể gán giá trị cho một biến là một ví dụ về hành động bị
thiếu.
Gọi một hàm với danh sách đối số sai là một loại hành động không
phù hợp.
Nguy cơ chính do một hành động không phù hợp hoặc thiếu là hành
động đó chỉ không chính xác trong một số điều kiện kết hợp nhất
định. Do đó, người ta phải thực hiện những việc sau để tìm dữ liệu
thử nghiệm tiết lộ lỗi một cách đáng tin cậy:
Xác định tất cả các điều kiện liên quan đến hoạt động chính xác của
một chương trình.
Chọn dữ liệu thử nghiệm để thực hiện tất cả các kết hợp có thể có
của các điều kiện này.
Ý tưởng chọn dữ liệu thử nghiệm ở trên dẫn chúng ta đến việc xác
định các thuật ngữ sau:
Dữ liệu thử nghiệm: Dữ liệu thử nghiệm là các giá trị thực tế từ miền
đầu vào của chương trình đáp ứng chung một số tiêu chí lựa chọn thử
nghiệm.
Vị ngữ kiểm tra: Vị từ kiểm tra là một mô tả các điều kiện và tổ hợp
các điều kiện liên quan đến hoạt động chính xác của chương trình:
Các vị từ kiểm tra mô tả các khía cạnh của một chương trình sẽ được
kiểm tra.
Dữ liệu thử nghiệm khiến những khía cạnh này được kiểm tra.
Các vị từ thử nghiệm là động lực thúc đẩy việc lựa chọn dữ liệu thử
nghiệm.
Các thành phần của các vị từ kiểm tra phát sinh trước tiên và chủ yếu
từ các thông số kỹ thuật của một chương trình.
Các điều kiện và vị từ khác có thể được thêm vào khi việc triển khai
được xem xét.
2.2.4 Điều kiện về độ tin cậy
Tập hợp các vị từ kiểm tra ít nhất phải thỏa mãn các điều kiện sau để
có bất kỳ cơ hội đáng tin cậy nào. Những điều kiện này là chìa khóa
để kiểm tra có ý nghĩa:
Mọi điều kiện rẽ nhánh riêng lẻ trong một chương trình phải được
biểu diễn bằng một điều kiện tương đương trong C.
Mọi điều kiện kết thúc tiềm năng trong chương trình, ví dụ, tràn, phải
được biểu diễn bằng một điều kiện trong C.
Mọi điều kiện liên quan đến hoạt động chính xác của chương trình
được ngụ ý bởi đặc tả và kiến thức về cấu trúc dữ liệu của chương
trình phải được biểu diễn dưới dạng điều kiện trong C.
2.3 LÝ THUYẾT VỀ WEYUKER VÀ OSTRAND 2.2.5 Mặt hạn
chế của lý thuyết
Một số khó khăn ngăn cản chúng tôi áp dụng lý thuyết của
Goodenough và Gerhart về một phép thử lý tưởng như sau [18]:
Các khái niệm về độ tin cậy và tính hợp lệ đã được xác định đối với
toàn bộ miền đầu vào của một chương trình. Một tiêu chí được đảm
bảo là đáng tin cậy và hợp lệ nếu và chỉ khi nó chọn toàn bộ miền
làm thử nghiệm duy nhất. Vì thử nghiệm toàn diện như vậy là không
79
thực tế, người ta sẽ gặp nhiều khó khăn trong việc đánh giá độ tin cậy
và tính hợp lệ của một tiêu chí.
Các khái niệm về độ tin cậy và tính hợp lệ đã được xác định đối với
một chương trình. Tiêu chí lựa chọn thử nghiệm đáng tin cậy và hợp
lệ cho một chương trình có thể không giống như vậy cho một chương
trình khác. Tính tốt của một bộ thử nghiệm phải độc lập với các
chương trình riêng lẻ và các lỗi trong đó.
Cả tính hợp lệ và độ tin cậy đều không được bảo toàn trong suốt quá
trình gỡ lỗi. Trong thực tế, khi quan sát thấy lỗi chương trình,
chương trình sẽ được gỡ lỗi để xác định lỗi và các lỗi thường được
sửa ngay sau khi chúng được tìm thấy. Trong giai đoạn gỡ lỗi này,
khi chương trình thay đổi, độ lý tưởng của bộ thử nghiệm cũng vậy.
Điều này là do một lỗi đã được tiết lộ trước khi gỡ lỗi sẽ không được
tiết lộ nữa sau khi gỡ lỗi và sửa lỗi. Do đó, các thuộc tính của các
tiêu chí lựa chọn thử nghiệm thậm chí không phải là “đơn điệu” theo
nghĩa là luôn có được hoặc được bảo toàn hoặc luôn bị mất hoặc
được bảo toàn.
2.3 LÝ THUYẾT VỀ WEYUKER VÀ OSTRAND
Một vấn đề quan trọng trong lý thuyết của Goodenough và Gerhart là

độ tin cậy và tính hợp lệ của một tiêu chí phụ thuộc vào sự hiện diện
của các lỗi trong một chương trình và kiểu của chúng. Weyuker và
Ostrand [18] đưa ra một lý thuyết đã được sửa đổi, trong đó tính hợp
lệ và độ tin cậy của các tiêu chí lựa chọn thử nghiệm chỉ phụ thuộc
vào đặc điểm kỹ thuật của chương trình, chứ không phải là một
chương trình. Họ đề xuất khái niệm về tiêu chí lựa chọn kiểm tra lý
tưởng thống nhất cho một đặc điểm kỹ thuật đầu ra nhất định. Theo
lý thuyết của Goodenough và Gerhart, ẩn trong định nghĩa của các vị
từ OK (d) và SUCCESSFUL (T) là một chương trình P. Bằng cách
viết tắt SUCCESSFUL () là SUCC (), hai vị từ được viết lại như sau:
OK (P, d): Xác định một vị từ OK (P, d) thể hiện khả năng chấp nhận
kết quả P (d). Do đó, OK (P, d) = true nếu và chỉ khi P (d) là kết quả
chấp nhận được của chương trình P.
SUCC (P, T): Đối với T ⊆ D cho trước, T là bài kiểm tra thành công
cho một chương trình
P, được ký hiệu là SUCC (P, T), nếu và chỉ khi, ∀ t ∈ T, OK (P, t).
Do đó, SUCC (T) = true nếu và chỉ khi, ∀ t ∈ T, OK (P, t).
Với các định nghĩa ở trên của OK (P, d) và SUCC (P, T), các khái
niệm về tiêu chí có giá trị thống nhất, tiêu chí đáng tin cậy thống nhất
và lựa chọn thử nghiệm lý tưởng thống nhất được định nghĩa như
sau.
Tiêu chí C hợp lệ đồng nhất: Tiêu chí C hợp lệ đồng nhất iff
( ∀ P) [ ( ∃ d ∈ D) (¬ OK (P, d)) ⇒ ( ∃ T ⊆ D) (C (T) & ¬ SUCC (P,
T)) ]
Tiêu chí C đáng tin cậy đồng nhất: Tiêu chí C có độ tin cậy đồng đều
iff
( ∀ P) ( ∀ T 1 , ∀ T 2 ⊆ D) [ (C (T 1 ) & C (T 2 )) ⇒ ( SUCC (P, T 1 )
⇔ SUCC (P, T 2 )) ]
Lựa chọn thử nghiệm lý tưởng đồng nhất: Tiêu chí lựa chọn thử
nghiệm lý tưởng đồng nhất cho một thông số kỹ thuật nhất định vừa
có giá trị thống nhất vừa có độ tin cậy đồng nhất.
Bộ định lượng bên ngoài ( ∀ P) ràng buộc biến tự do P trong định
nghĩa của tiêu chí hợp lệ đồng nhất C về cơ bản có nghĩa là phần còn
lại của vị từ giữ cho tất cả các chương trình P đối với một đặc tả đầu
ra nhất định. Tương tự, bộ định lượng bên ngoài ( ∀ P) ràng buộc
biến tự do P trong định nghĩa của tiêu chí C đáng tin cậy đồng nhất
có nghĩa là phần còn lại của vị từ giữ cho tất cả các chương trình P
đối với một đặc tả đầu ra nhất định.
Vì tiêu chí lựa chọn kiểm tra lý tưởng thống nhất được xác định trên
tất cả các chương trình cho một đặc điểm kỹ thuật nhất định, nó
nhằm giải quyết tất cả các khó khăn phụ thuộc vào chương trình
trong các định nghĩa do Goodenough và Gerhart đưa ra. Tuy nhiên,
khái niệm về lựa chọn thử nghiệm lý tưởng đồng nhất cũng có một số
sai sót. Ví dụ, đối với bất kỳ chương trình quan trọng nào, không thể
có tiêu chí lý tưởng thống nhất không tầm thường theo nghĩa chọn
toàn bộ miền đầu vào D. Một tiêu chí C được cho là hợp lệ nếu hợp
của tất cả các thử nghiệm được chọn bởi C là D. Do đó, các định lý
sau đây.
Định lý. Tiêu chí C có giá trị đồng nhất nếu và chỉ khi C có giá
trị nhỏ.
Bằng chứng. Rõ ràng là một tiêu chí có giá trị tầm thường là hợp lệ.
Bây giờ chúng ta cần chỉ ra rằng một tiêu chí C không có giá trị tầm
thường thì không thể có giá trị thống nhất đối với một đặc tả đầu ra
nhất định. Đối với bất kỳ phần tử d nào không có trong bất kỳ phép
81
thử nào của C, người ta có thể viết một chương trình sai cho d và
đúng cho D - { d } .
Định lý. Tiêu chí C là đáng tin cậy đồng nhất nếu và chỉ khi C chọn
một bộ thử nghiệm duy nhất.
Bằng chứng. Nếu C chỉ chọn một bài kiểm tra, nó rõ ràng là đáng tin
cậy cho bất kỳ chương trình nào. Bây giờ, giả sử rằng C chọn các
phép thử khác nhau T 1 và T 2 và t ∈ T 1 nhưng t ∈ / T 2 . Một chương
trình P tồn tại đúng đối với kiểm tra đầu vào trong T 2 nhưng không
chính xác trên t. Do đó, hai bài kiểm tra cho kết quả khác nhau đối
với P, và C là không đáng tin cậy.
Bây giờ, chúng ta có thể kết hợp hai định lý trên để có hệ quả sau.
Hệ quả. Tiêu chí C có giá trị thống nhất và đáng tin cậy đồng nhất
nếu và chỉ khi C chỉ chọn tập thử nghiệm duy nhất T = D.
2.4 LÝ THUYẾT VỀ GOURLAY
Hàm ý quan trọng của hệ quả trên là tính hợp lệ đồng nhất và độ tin
cậy đồng nhất dẫn đến kiểm tra toàn diện — và kiểm tra toàn diện
được coi là không thực tế. Tiếp theo, hệ quả ở trên được định dạng
lại để nói rằng bất kể tiêu chí lựa chọn bài kiểm tra được sử dụng và
bất kể các bài kiểm tra được chọn, ngoại trừ toàn bộ D, người ta luôn
có thể viết một chương trình có thể đánh bại các bài kiểm tra. Một
chương trình P được cho là đánh bại bài kiểm tra T nếu P vượt qua T
nhưng không thành công trên một số đầu vào hợp lệ khác. Điều này
diễn giải tuyên bố nổi tiếng của Dijkstra rằng kiểm tra chỉ có thể tiết
lộ sự hiện diện của lỗi, không bao giờ là sự vắng mặt của chúng [16].
Độ tin cậy và hiệu lực của tiêu chí lựa chọn thử nghiệm là những
mục tiêu lý tưởng, và những mục tiêu lý tưởng hiếm khi đạt được. Sẽ
rất hữu ích nếu bạn tìm kiếm những mục tiêu ít lý tưởng hơn nhưng
có thể sử dụng được. Bằng cách giải quyết các mục tiêu ít lý tưởng
hơn, về cơ bản chúng ta chấp nhận thực tế rằng tính đúng đắn của các
chương trình lớn không phải là điều mà chúng ta cố gắng đạt được.
Weyuker và Ostrand [18] đã đưa ra khái niệm về tiêu chí tiết lộ liên
quan đến miền phụ, trong đó miền phụ S là một tập hợp con của
miền đầu vào D. Một tiêu chí lựa chọn kiểm tra C sẽ tiết lộ cho miền
phụ S nếu bất cứ khi nào S chứa đầu vào mà được xử lý không chính
xác thì mọi bộ kiểm tra thỏa mãn C đều không thành công. Nói cách
khác, nếu bất kỳ thử nghiệm nào được chọn bởi C được thực hiện
thành công, thì mọi thử nghiệm trong S đều tạo ra kết quả chính xác.
Vị từ được gọi là REVEALING (C, S) nắm bắt ý tưởng trên trong

định nghĩa sau:
QUAY LẠI (C, S) iff ( ∃ d ∈ S) (¬ OK (d)) ⇒ ( ∀ T ⊆ S) (C (T) ⇒ ¬
SUCC (T))
Ưu điểm chính trong tiêu chí tiết lộ là nó chỉ liên quan đến một tập
hợp con của miền đầu vào, thay vì toàn bộ miền đầu vào. Bằng cách
xem xét một tập hợp con của miền đầu vào, các lập trình viên có thể
tập trung vào các lỗi cục bộ. Một nhiệm vụ quan trọng trong việc áp
dụng ý tưởng về tiêu chí tiết lộ là phân vùng đầu vào thành các tên
miền phụ nhỏ hơn, điều này giống như việc phân vùng một vấn đề
thành một tập hợp các bài toán con. Tuy nhiên, việc phân chia một
vấn đề thành các bài toán con đã được công nhận là một nhiệm vụ
khó khăn.
Mục tiêu lý tưởng trong phát triển phần mềm là tìm hiểu xem một
chương trình có đúng hay không, trong đó một chương trình đúng là
không có lỗi. Nhiều kết quả nghiên cứu đã được báo cáo trong lĩnh
vực tính đúng đắn của chương trình. Tuy nhiên, do tính chất hạn chế
cao của các kỹ thuật xác minh chương trình, không nhà phát triển nào
cố gắng chứng minh tính đúng đắn của các chương trình nhỏ, ví dụ,
vài nghìn dòng, chứ chưa nói đến các chương trình lớn với hàng triệu
dòng mã. Thay vào đó, thử nghiệm được chấp nhận trong ngành như
một cách thực tế để tìm ra lỗi trong các chương trình. Mặt trái của
thử nghiệm là nó không thể được sử dụng để giải quyết câu hỏi về
tính đúng đắn của chương trình, đó là mục tiêu lý tưởng. Mặc dù thử
nghiệm không thể giải quyết vấn đề về tính đúng đắn của chương
trình, nhưng cần có một lý thuyết thử nghiệm để cho phép chúng ta
so sánh sức mạnh của các phương pháp thử nghiệm khác nhau.
Để thúc đẩy một cuộc thảo luận lý thuyết về kiểm thử, chúng tôi bắt
đầu với một quy trình lý tưởng để phát triển phần mềm, bao gồm các
bước sau:
Một khách hàng và một nhóm phát triển xác định các nhu cầu.
Nhóm phát triển nhận đặc điểm kỹ thuật và cố gắng viết một chương
trình để đáp ứng đặc điểm kỹ thuật.
83
Một kỹ sư kiểm thử lấy cả đặc điểm kỹ thuật và chương trình và
chọn một tập hợp các trường hợp kiểm thử. Các trường hợp kiểm thử
dựa trên đặc điểm kỹ thuật và chương trình.
Chương trình được thực hiện với dữ liệu thử nghiệm đã chọn và kết
quả thử nghiệm được so sánh với kết quả mong đợi.
Chương trình được cho là có lỗi nếu một số thử nghiệm không thành
công.
Có thể nói chương trình sẵn sàng sử dụng nếu nó vượt qua tất cả các
trường hợp thử nghiệm.
Chúng tôi tập trung vào việc lựa chọn các trường hợp thử nghiệm và
giải thích kết quả của chúng. Chúng tôi giả định rằng thông số kỹ
thuật là chính xác và thông số kỹ thuật là trọng tài duy nhất về tính
đúng đắn của chương trình. Chương trình được cho là đúng nếu và
chỉ khi nó đáp ứng các thông số kỹ thuật. Lý thuyết thử nghiệm của
Gourlay [19] thiết lập mối quan hệ giữa ba tập hợp thực thể, cụ thể là
thông số kỹ thuật, chương trình và thử nghiệm, đồng thời cung cấp
cơ sở để so sánh các phương pháp khác nhau để lựa chọn thử
nghiệm.
2.4.1 Một vài định nghĩa
Tập hợp tất cả các chương trình được ký hiệu là P , tập hợp tất cả các
thông số kỹ thuật là S và tập hợp tất cả các thử nghiệm bằng T. Các
thành viên của P sẽ được ký hiệu là p và q, các thành viên của S sẽ
được ký hiệu là r và s, và các thành viên của T sẽ được ký hiệu là t và
u.
Các chữ cái viết hoa sẽ biểu thị các tập con của P , S và T. Ví dụ, p ∈
P ⊆ P và t ∈ T ⊆ T , trong đó t biểu thị một trường hợp kiểm tra duy
nhất. Tính đúng đắn của một chương trình p đối với một đặc điểm kỹ
thuật s sẽ được ký hiệu bằng p corrs. Cho trước s, p và t, vị từ p ok (t)
s có nghĩa là kết quả của phép thử p theo t được đánh giá là thành
công theo đặc tả s. Người đọc có thể nhớ rằng T biểu thị một tập các
trường hợp kiểm tra, và p ok (T) s đúng nếu và chỉ khi p ok (t) s ∀ t ∈
T.
Chúng ta phải nhận ra rằng nếu một chương trình đúng, thì nó sẽ
không bao giờ tạo ra bất kỳ kết quả không mong muốn nào đối với
đặc điểm kỹ thuật. Do đó, p corrs ⇒ p ok (t) s
∀ t.
Sự định nghĩa. Hệ thống thử nghiệm là một tập hợp , trong đó P , S và T là các tập tùy ý, corr ⊆ P × S , các tập
hợp, ok ⊆ T × P × S , và
∀ p ∀ s ∀ t (p corr s ⇒ p ok (t) s) .
Sự định nghĩa. Cho một hệ thống thử nghiệm một hệ thống mới < P , S , được gọi là cấu trúc tập
hợp là tập hợp của tất cả các tập con của T , và trong đó p
ok . (Người đọc có thể nhớ lại rằng T là
thành viên của T
Định lý. , một cấu trúc tập hợp trên hệ
thống thử nghiệm , bản thân nó là một hệ thống thử nghiệm.
Bằng chứng. Chúng ta cần chứng minh rằng (T) s .
Giả sử rằng p corr s được giữ nguyên. Theo giả định, hệ thống ban
đầu là một hệ thống thử nghiệm. Do đó, ∀ t, p ok (t) s . Nếu chúng ta
chọn một tập kiểm tra T, chúng ta biết rằng, ∀ t ∈ T, p ok (t) s . Do
đó, p ok s nắm giữ.
Cấu trúc tập hợp được diễn giải như sau. Một thử nghiệm bao gồm
một số thử nghiệm thuộc một số loại, và sự thành công của thử
nghiệm nói chung phụ thuộc vào sự thành công của tất cả các thử
nghiệm. Trên thực tế, đây là quy tắc trong thực hành kiểm thử, nơi
một kỹ sư kiểm thử phải chạy đi chạy lại một chương trình trên nhiều
dữ liệu kiểm tra khác nhau. Không thực hiện được bất kỳ lần chạy
nào cũng đủ để làm mất hiệu lực của chương trình.
Sự định nghĩa. Đưa ra một hệ thống thử nghiệm một hệ thống mới được gọi là cấu trúc lựa chọn, trong đó T là tập hợp
các tập con của
T , và ở đâu p ok (t) s). (Người đọc có thể nhớ
lại rằng T là thành viên của T bởi vì T ⊆ T. )
Định lý. , một cấu trúc lựa chọn trên hệ thống
thử nghiệm , bản thân nó là một hệ thống thử
nghiệm.
Bằng chứng. Tương tự như định lý trước, chúng ta cần chứng minh
rằng p corrs
85
S. Giả sử rằng p corrs. Do đó, ∀ t, p ok (t) s. Nếu chúng ta chọn một
tập kiểm tra khác T, chúng ta biết rằng ∃ t ∈ T sao cho p ok (t) s. Do
đó, chúng ta có thể viết p ok (t) s)), và
). Tập kiểm tra rỗng φ phải được loại trừ khỏi (
T ') vì hệ thống kiểm tra phải bao gồm ít nhất một thử nghiệm.
Sự lựa chọn xây dựng mô hình hóa tình huống trong đó một kỹ sư
thử nghiệm được cung cấp một số cách thay thế để thử nghiệm
chương trình, tất cả đều được giả định là tương đương.
Sự định nghĩa. Phương pháp kiểm tra là một hàm M: P × S →
T.
Đó là, trong trường hợp chung, một phương pháp thử nghiệm lấy đặc
điểm kỹ thuật S và một chương trình thực thi P và tạo ra các trường
hợp thử nghiệm. Trong thực tế, các phương pháp kiểm tra chủ yếu
phụ thuộc vào chương trình, phụ thuộc vào đặc điểm kỹ thuật hoặc
hoàn toàn phụ thuộc vào mong đợi của khách hàng, như được giải
thích dưới đây:
Chương trình phụ thuộc: Trong trường hợp này, T = M (P), nghĩa
là, các trường hợp kiểm thử chỉ được suy ra dựa trên mã nguồn của
hệ thống. Đây được gọi là thử nghiệm hộp trắng. Ở đây, một phương
pháp kiểm tra có kiến thức đầy đủ về các chi tiết bên trong của một
chương trình. Tuy nhiên, từ quan điểm của thử nghiệm thực tế, một
phương pháp hộp trắng thường không được áp dụng cho toàn bộ
chương trình. Người ta áp dụng một phương pháp như vậy cho các
đơn vị nhỏ của một hệ thống lớn nhất định. Một đơn vị đề cập đến
một chức năng, thủ tục, phương pháp, v.v. Phương pháp hộp trắng
cho phép kỹ sư thử nghiệm sử dụng các chi tiết của đơn vị chương
trình. Việc sử dụng một đơn vị chương trình một cách hiệu quả đòi
hỏi sự hiểu biết thấu đáo về đơn vị đó. Do đó, các phương pháp kiểm
tra hộp trắng được các lập trình viên sử dụng để kiểm tra mã của
chính họ.
Phụ thuộc đặc điểm kỹ thuật: Trong trường hợp này, T = M (S),
nghĩa là, các trường hợp kiểm thử chỉ được suy ra dựa trên đặc điểm
kỹ thuật của một hệ thống. Đây được gọi là thử nghiệm hộp đen. Ở
đây, một phương pháp kiểm tra không có quyền truy cập vào các chi
tiết nội bộ của một chương trình. Phương pháp như vậy sử dụng
thông tin được cung cấp trong đặc điểm kỹ thuật của hệ thống.
Không có gì lạ khi sử dụng toàn bộ một thông số kỹ thuật trong việc
tạo ra các trường hợp thử nghiệm vì các thông số kỹ thuật có kích
thước nhỏ hơn nhiều so với việc triển khai tương ứng của chúng. Các
phương pháp hộp đen thường được sử dụng bởi nhóm phát triển và
một nhóm kiểm tra hệ thống độc lập.
Sự phụ thuộc vào kỳ vọng: Trong thực tế, khách hàng có thể tạo
các trường hợp thử nghiệm dựa trên kỳ vọng của họ từ sản phẩm tại
thời điểm nhận hệ thống. Các trường hợp thử nghiệm này có thể bao
gồm các thử nghiệm hoạt động liên tục, thử nghiệm khả năng sử
dụng, v.v.
2.4.2 Sức mạnh của các phương pháp thử nghiệm
Người thử nghiệm quan tâm đến các phương pháp để tạo ra các
trường hợp thử nghiệm và so sánh các phương pháp thử nghiệm để
họ có thể xác định một phương pháp thử nghiệm thích hợp. Gọi M và
N là hai phương pháp kiểm tra. Đối với M ít nhất là tốt bằng N,
chúng ta phải có tình huống rằng bất cứ khi nào N tìm thấy lỗi, M.
Nói cách khác, bất cứ khi nào một chương trình bị lỗi trong một
trường hợp thử nghiệm được tạo ra bằng phương pháp N, nó cũng sẽ
bị lỗi theo a trường hợp thử nghiệm được sản xuất theo phương pháp
M, đối với cùng một thông số kỹ thuật. Do đó, F N ⊆ F M , trong đó F
N và F M lần lượt là tập hợp các lỗi được phát hiện bởi các tập thử
nghiệm được tạo ra bằng phương pháp N và M.
Gọi T M và T N lần lượt là tập các trường hợp kiểm tra được tạo ra bởi
phương pháp M và N. Sau đó, chúng ta cần làm theo hai cách để so
sánh sức mạnh phát hiện lỗi của chúng.
Trường hợp 1: T M ⊇ T N. Trong trường hợp này, rõ ràng là phương
pháp M ít nhất cũng tốt như phương pháp N. Điều này là do phương
pháp M tạo ra các trường hợp thử nghiệm cho thấy tất cả các lỗi được
tiết lộ bởi các trường hợp thử nghiệm được tạo ra bằng phương pháp
N. Trường hợp này được mô tả trong Hình 2.3a.
Trường hợp 2: T M và T N trùng nhau , nhưng T M T N. Trường hợp này cho
thấy rằng T M không hoàn toàn chứa T N. Để có thể so sánh khả năng
phát hiện lỗi của chúng, chúng tôi thực hiện chương trình P trong cả
hai bộ trường hợp thử nghiệm, cụ thể là T M và T N. Gọi F M và F N lần
lượt là tập hợp các lỗi được phát hiện bởi các tập kiểm tra T M và T N.
Nếu F M ⊇ F N , thì chúng ta nói rằng phương pháp M ít nhất cũng tốt
như phương pháp N. Tình huống này được giải thích trong Hình
2.3b.
87
2.5 ĐIỀU KIỆN THỬ NGHIỆM
Thử nghiệm mang lại cho các nhà thiết kế và lập trình viên sự tin
tưởng vào một thành phần phần mềm hoặc một sản phẩm hoàn chỉnh
nếu nó vượt qua các trường hợp thử nghiệm của họ. Giả sử rằng một
tập hợp các trường hợp thử nghiệm
2.5 ĐIỀU KIỆN THỬ NGHIỆM
S N
TM
TN
P M
(a)
S N TN Execute
FN
P
TM FM
P M
(b)
Hình 2.3 Các cách khác nhau để so sánh sức mạnh của các
phương pháp thử nghiệm: (a) tạo ra tất cả các trường hợp thử nghiệm
được tạo ra bởi một phương pháp khác; (b) các tập kiểm tra có các
phần tử chung.
T đã được thiết kế để kiểm tra một chương trình P. Chúng tôi thực
hiện P với tập kiểm tra T. Nếu T để lộ lỗi trong P, thì chúng tôi sửa
đổi chương trình để cố gắng sửa những lỗi đó. Ở giai đoạn này, có
thể cần thiết kế một số trường hợp thử nghiệm mới, bởi vì, ví dụ,
chúng tôi có thể bao gồm một thủ tục mới trong mã. Sau khi sửa đổi
mã, chúng tôi thực thi chương trình với bộ thử nghiệm mới. Do đó,
chúng tôi thực hiện vòng lặp kiểm tra và sửa chữa cho đến khi không
còn lỗi nào nữa được tiết lộ bởi bộ kiểm tra được cập nhật. Bây giờ
chúng ta phải đối mặt với một tình huống khó xử như sau: P thực sự
không có lỗi, hay là T không đủ tốt để tiết lộ những lỗi còn lại của P?
Từ thử nghiệm, chúng tôi không thể kết luận rằng P là không có lỗi ,
vì, như Dijkstra đã quan sát, thử nghiệm có thể cho thấy sự hiện diện
của các lỗi, nhưng không phải là sự vắng mặt của chúng. Vì vậy, nếu
P vượt qua T, chúng ta cần biết rằng T là “đủ tốt” hay nói cách khác,
T là một tập hợp các phép thử. Điều quan trọng là phải đánh giá mức
độ đầy đủ của T bởi vì nếu T được phát hiện là không đầy đủ, thì cần
thiết kế thêm nhiều trường hợp kiểm thử, như minh họa trong Hình
2.4. Sự đầy đủ của T nghĩa là T có kiểm tra kỹ lưỡng P. hay không.
Tốt nhất, thử nghiệm nên được thực hiện với một tập hợp thử nghiệm
đầy đủ T. Về mặt trực quan, ý tưởng đằng sau việc chỉ định một tiêu
chí để đánh giá mức độ đầy đủ của thử nghiệm là để biết liệu thử
nghiệm đã được thực hiện đầy đủ hay chưa. Chúng tôi sẽ sớm quay
lại ý tưởng về tính đầy đủ của thử nghiệm. Trong trường hợp không
đủ tính năng kiểm tra, các nhà phát triển sẽ buộc phải sử dụng các
biện pháp đặc biệt để quyết định thời điểm ngừng kiểm tra. Một số ví
dụ về các biện pháp đột xuất để ngừng thử nghiệm như sau [13]:
Dừng lại khi thời gian được phân bổ để kiểm tra hết hạn.
Dừng lại khi đến thời điểm phát hành sản phẩm.
Dừng lại khi tất cả các trường hợp thử nghiệm thực thi mà không để
lộ lỗi.
Hình 2.4 mô tả hai khái niệm quan trọng liên quan đến thiết kế thử
nghiệm và đánh giá tính đầy đủ của thử nghiệm như sau:
Design a set of test cases T
to test a programP.
Execute P with T.
Yes
Does T reveal Fix the faults in P. If there
faults in P? is a need, augmentT with
new test cases.
No
No
Is T an
Augment T with new test cases.
adequate test set?
Yes
Stop
Hình 2.4 Bối cảnh áp dụng thử nghiệm đầy đủ.

89
Tính đầy đủ của bộ thử nghiệm T được đánh giá sau khi thấy rằng T
không còn lỗi nào nữa. Người ta có thể tranh luận: Tại sao không
thiết kế các trường hợp kiểm thử để đáp ứng một tiêu chí đầy đủ?
Tuy nhiên, điều quan trọng là phải thiết kế các trường hợp thử
nghiệm độc lập với tiêu chí đầy đủ bởi vì mục tiêu chính của thử
nghiệm là xác định lỗi và do đó, thiết kế thử nghiệm không bị ràng
buộc bởi một tiêu chí đầy đủ. Ví dụ về tiêu chí thiết kế kiểm thử như
sau: Chọn các trường hợp kiểm thử để thực thi tất cả các câu lệnh
trong chương trình ít nhất một lần. Tuy nhiên, khó khăn với tiêu chí
thiết kế thử nghiệm như vậy là chúng ta có thể không biết liệu mọi
câu lệnh chương trình có thể được thực thi hay không. Do đó, rất khó
để đánh giá mức độ đầy đủ của bộ thử nghiệm được chọn qua đó.
Cuối cùng, vì mục tiêu của thử nghiệm là phát hiện ra các lỗi, nên
không có ích lợi gì khi đánh giá tính đầy đủ của bộ thử nghiệm miễn
là các lỗi được tiết lộ.
Một tập kiểm tra đầy đủ T không nói lên điều gì về tính đúng đắn của
một chương trình. Hiểu biết chung về tính đúng đắn là chúng tôi đã
tìm và sửa tất cả các lỗi trong một chương trình để làm cho nó
“đúng”. Tuy nhiên, trên thực tế, việc tìm và sửa tất cả các lỗi trong
một chương trình là không thực tế - mặc dù rất mong muốn . Do đó,
một mặt, tiêu chí đầy đủ có thể không thử
2.6 CÁC GIỚI HẠN CỦA VIỆC KIỂM TRA
để hướng tới tính đúng đắn của chương trình. Mặt khác, một chương
trình không có lỗi không nên biến bất kỳ tập thử nghiệm T tùy ý nào
thành một thử nghiệm thích hợp.
Hai điểm trên cho chúng ta biết một khái niệm quan trọng: rằng tính
đầy đủ của một tập kiểm tra được đánh giá độc lập với các quy trình
thiết kế kiểm thử cho các chương trình được kiểm tra. Một cách trực
quan, một tập kiểm tra T được cho là phù hợp nếu nó bao gồm tất cả
các khía cạnh của tính toán thực tế được thực hiện bởi một chương
trình và tất cả các phép tính theo đặc điểm kỹ thuật của nó. Hai
phương pháp thực tế để đánh giá mức độ đầy đủ của thử nghiệm như
sau:
Seeding lỗi: Phương pháp này đề cập đến việc cấy ghép một số lỗi
nhất định trong chương trình P và thực hiện P với tập kiểm tra T.
Nếu T tiết lộ k phần trăm lỗi được cấy ghép, chúng tôi giả định rằng
T chỉ tiết lộ k phần trăm lỗi ban đầu. Nếu 100% lỗi được cấy ghép đã
được T tiết lộ, chúng tôi cảm thấy tin tưởng hơn về tính đầy đủ của
T. Có thể tìm thấy một cuộc thảo luận kỹ lưỡng về việc gieo hạt lỗi
trong Chương 13.
Đột biến theo chương trình: Cho chương trình P, đột biến là
chương trình thu được bằng cách tạo ra một thay đổi nhỏ đối với P.
Trong phương pháp đột biến theo chương trình, một loạt các đột biến
thu được từ P. Một số đột biến có thể chứa lỗi và phần còn lại tương
đương với P. Tập hợp thử nghiệm T được cho là phù hợp nếu nó
khiến mọi đột biến bị lỗi tạo ra kết quả không mong muốn. Một cuộc
thảo luận kỹ hơn về đột biến chương trình có thể được tìm thấy trong
Chương 3.
2.6 CÁC GIỚI HẠN CỦA VIỆC KIỂM TRA
Tốt nhất, tất cả các chương trình phải đúng, nghĩa là không có lỗi nào
trong một chương trình. Do tính chất không thực tế của việc chứng
minh ngay cả các chương trình nhỏ là đúng, khách hàng và nhà phát
triển phần mềm dựa vào hiệu quả của thử nghiệm. Trong phần này,
chúng tôi giới thiệu hai hạn chế chính của thử nghiệm:
Kiểm tra nghĩa là thực thi một chương trình với một tập con nhỏ,
thích hợp của miền đầu vào của chương trình. Một tập hợp con nhỏ,
thích hợp của miền đầu vào được chọn vì chi phí có thể không cho
phép chọn tập hợp con lớn hơn nhiều, chưa nói đến tập hợp đầu vào
đầy đủ. Kiểm tra với tập hợp đầu vào đầy đủ được gọi là kiểm tra
toàn diện. Do đó, nhu cầu cố hữu để kiểm tra một chương trình với
một tập con nhỏ của miền đầu vào đặt ra một giới hạn cơ bản về hiệu
quả của việc kiểm thử. Giới hạn ở dạng chúng ta không thể ngoại suy
tính đúng đắn của kết quả cho một tập hợp con thích hợp của miền
đầu vào đối với tính đúng đắn của chương trình. Nói cách khác, ngay
cả khi một chương trình vượt qua tập kiểm tra T, chúng ta cũng
không thể kết luận rằng chương trình đó đúng.
Khi chúng tôi đã chọn một tập hợp con của miền đầu vào, chúng tôi
phải đối mặt với vấn đề xác minh tính đúng đắn của đầu ra chương
trình cho đầu vào thử nghiệm riêng lẻ. Đó là, một đầu ra chương
trình được kiểm tra để xác định xem chương trình có thực hiện chính
xác trên đầu vào thử nghiệm hay không. Cơ chế xác minh tính đúng
đắn của đầu ra chương trình được gọi là tiên tri. Khái niệm về một lời
91
tiên tri được thảo luận chi tiết trong Chương 9. Xác định tính đúng
đắn
của một đầu ra chương trình không phải là một nhiệm vụ tầm
thường. Nếu một trong hai điều kiện sau đây được giữ nguyên, một
chương trình được coi là không thể đánh giá được [20]:
Không tồn tại một lời tiên tri.
Quá khó để xác định đầu ra chính xác.
Nếu không có cơ chế xác minh tính đúng đắn của kết quả đầu ra
chương trình hoặc mất một khoảng thời gian bất thường để xác minh
kết quả đầu ra, thì sẽ không thu được gì nhiều khi chạy thử nghiệm.
2.7 TÓM TẮT
Mục tiêu lý tưởng, trừu tượng của kiểm thử là tiết lộ tất cả các lỗi
trong hệ thống phần mềm mà không kiểm tra toàn bộ phần mềm. Ý
tưởng này là cơ sở của khái niệm về một bài kiểm tra lý tưởng được
phát triển bởi Goodenough và Gerhart [17]. Một bài kiểm tra lý
tưởng được cho là một tập con nhỏ, thích hợp của toàn bộ miền đầu
vào và chúng ta sẽ có thể ngoại suy kết quả của một bài kiểm tra lý
tưởng để lập trình tính đúng đắn. Nói cách khác, theo nghĩa trừu
tượng, nếu một chương trình vượt qua tất cả các bài kiểm tra trong
một tập hợp bài kiểm tra được lựa chọn cẩn thận, được gọi là bài
kiểm tra lý tưởng, chúng ta có thể khẳng định rằng chương trình đó là
đúng.
Cùng với khái niệm về một bài kiểm tra lý tưởng là một tiêu chí lựa
chọn bài kiểm tra cho phép chúng tôi chọn ra các thành viên của một
bài kiểm tra lý tưởng. Tiêu chí lựa chọn thử nghiệm được đặc trưng
bởi độ tin cậy và tính hợp lệ. Tiêu chí đáng tin cậy là tiêu chí lựa
chọn các trường hợp kiểm thử sao cho một chương trình vượt qua tất
cả các bài kiểm tra hoặc không đạt tất cả các bài kiểm tra. Mặt khác,
tiêu chí hợp lệ là tiêu chí chọn ít nhất một bộ thử nghiệm không
thành công trong trường hợp chương trình có lỗi. Nếu một tiêu chí
vừa hợp lệ vừa đáng tin cậy, thì bất kỳ thử nghiệm nào được lựa chọn
bởi tiêu chí là một thử nghiệm lý tưởng. Lý thuyết có một vài nhược
điểm. Đầu tiên, các khái niệm về độ tin cậy và tính hợp lệ đã được
định nghĩa đối với một chương trình và toàn bộ miền đầu vào của nó.
Thứ hai, cả độ tin cậy và tính hợp lệ đều không được bảo toàn trong
suốt giai đoạn gỡ lỗi của quá trình phát triển phần mềm.
Lỗi xảy ra do chúng tôi không hiểu đầy đủ về tất cả các điều kiện mà
một chương trình phải đối phó và chúng tôi không nhận ra rằng các
tổ hợp điều kiện nhất định yêu cầu phương pháp điều trị đặc biệt.
Goodenough và Gerhart phân loại lỗi thành năm loại: lỗi logic, lỗi
yêu cầu, lỗi thiết kế, lỗi xây dựng và lỗi hiệu suất.
Weyuker và Ostrand [18] đã cố gắng loại bỏ những nhược điểm của
lý thuyết của Goodenough và Gerhart bằng cách đề xuất khái niệm
về một phép thử lý tưởng thống nhất. Khái niệm này được định nghĩa
đối với tất cả các chương trình được thiết kế để đáp ứng một đặc
điểm kỹ thuật, thay vì chỉ một chương trình — do đó khái niệm “tính
đồng nhất” trên tất cả các phiên bản chương trình cho một đặc điểm
kỹ thuật nhất định. Hơn nữa, ý tưởng về tính đồng nhất đã được mở
rộng để kiểm tra các tiêu chí lựa chọn dưới dạng một tiêu chí đồng
nhất đáng tin cậy và có giá trị thống nhất. Tuy nhiên, lý thuyết của họ
cũng không thực tế vì một tiêu chí có giá trị thống nhất và đáng tin
cậy đồng nhất chọn toàn bộ miền đầu vào của một chương trình, do
đó gây ra kiểm tra toàn diện. Tiếp theo, ý tưởng về một bài kiểm tra
lý tưởng đã được mở rộng sang một tập hợp con thích hợp của miền
đầu vào được gọi là miền phụ và khái niệm về tiêu chí tiết lộ đã được
xác định.
ĐÁNH GIÁ TÌNH HÌNH
Mặc dù thử nghiệm không thể giải quyết câu hỏi về tính đúng đắn
của chương trình, các phương pháp thử nghiệm khác nhau vẫn tiếp
tục được phát triển. Ví dụ, có các phương pháp thử nghiệm dựa trên
đặc điểm kỹ thuật và phương pháp thử nghiệm dựa trên mã. Điều
quan trọng là phát triển một lý thuyết để so sánh sức mạnh của các
phương pháp kiểm tra khác nhau. Gourlay [19] đưa ra một lý thuyết
để so sánh sức mạnh của các phương pháp kiểm tra dựa trên khả
năng phát hiện lỗi của chúng.
Một hệ thống phần mềm trải qua nhiều chu kỳ kiểm tra - sửa chữa -
kiểm tra lại cho đến khi, lý tưởng là không còn lỗi nào được tiết lộ.
Các lỗi được khắc phục bằng cách sửa đổi mã hoặc thêm mã mới vào
hệ thống. Ở giai đoạn này, có thể cần thiết kế các trường hợp thử
nghiệm mới. Khi không còn lỗi nào được tiết lộ, chúng ta có thể kết
luận theo cách này: hoặc không có lỗi nào trong chương trình hoặc
các bài kiểm tra không thể phát hiện ra lỗi. Vì chúng ta không có
cách nào để biết chính xác tình hình, nên việc đánh giá mức độ đầy
93
đủ của bộ thử nghiệm là rất hữu ích. Không cần đánh giá mức độ đầy
đủ của các thử nghiệm miễn là chúng bộc lộ lỗi. Hai cách thực tế để
đánh giá mức độ đầy đủ của thử nghiệm là gieo lỗi và đột biến
chương trình.
Cuối cùng, chúng tôi đã thảo luận về hai hạn chế của thử nghiệm.
Hạn chế đầu tiên của thử nghiệm là nó không thể giải quyết câu hỏi
về tính đúng đắn của chương trình. Nói cách khác, bằng cách kiểm
tra một chương trình với một tập con thích hợp của miền đầu vào và
không quan sát thấy lỗi nào, chúng tôi không thể kết luận rằng không
còn lỗi nào trong chương trình. Hạn chế thứ hai của thử nghiệm là
trong một số trường hợp, chúng tôi không biết đầu ra mong đợi của
một chương trình. Nếu đối với một số đầu vào, đầu ra dự kiến của
một chương trình không được biết hoặc không thể xác định được nó
trong một khoảng thời gian hợp lý, thì chương trình đó được gọi là
không thể kiểm tra được [20].
Weyuker và Ostrand [18] đã chỉ ra bằng các ví dụ về cách tạo các tên
miền phụ tiết lộ từ mã nguồn. Ví dụ chính của họ là bài toán phân
loại tam giác nổi tiếng. Bài toán phân loại tam giác như sau. Chúng
ta hãy xem xét ba số nguyên dương A, B và C. Vấn đề là tìm xem
các số nguyên đã cho có biểu diễn các cạnh của tam giác đều, các
cạnh của tam giác vuông vô hướng hay không, v.v.
Weyuker [13] đã đưa ra khái niệm suy luận chương trình để nắm bắt
khái niệm về tính đầy đủ của dữ liệu thử nghiệm. Về cơ bản, suy luận
chương trình đề cập đến việc dẫn xuất một chương trình từ đặc tả của
nó và một mẫu hành vi đầu vào - đầu ra của nó. Mặt khác, quá trình
thử nghiệm bắt đầu với đặc điểm kỹ thuật S và chương trình P và
chọn các cặp đầu vào - đầu ra đặc trưng cho mọi khía cạnh của các
phép tính thực tế được thực hiện bởi chương trình và các phép tính
dự định được thực hiện bởi đặc điểm kỹ thuật. Do đó, kiểm tra
chương trình và suy luận chương trình được coi là các quá trình
nghịch đảo. Tập kiểm tra T được cho là phù hợp nếu T chứa đủ dữ
liệu để suy ra các phép tính được xác định bởi cả S và P. Tuy nhiên,
Weyuker [13] giải thích rằng tiêu chí đầy đủ như vậy không thể sử
dụng trên thực tế. Đúng hơn, tiêu chí này tốt nhất có thể được sử
dụng như một hướng dẫn. Bằng cách xem xét khó khăn trong việc sử
dụng tiêu chí, Weyuker xác định hai tiêu chí đầy đủ yếu hơn, đó là
đầy đủ chương trình và đầy đủ thông số kỹ thuật. Tập kiểm tra T
được cho là đủ chương trình nếu nó chứa đủ dữ liệu để suy ra các
phép tính được xác định bởi P. Tương tự, tập kiểm tra T được cho là
đặc tả phù hợp nếu nó chứa đủ dữ liệu để suy ra các phép tính được
xác định bởi S. đề xuất rằng tùy thuộc vào cách dữ liệu thử nghiệm
được chọn, một trong hai tiêu chí có thể được nới lỏng. Ví dụ, nếu T
có nguồn gốc từ S, thì việc đánh giá xem T có phù hợp với chương
trình hay không sẽ rất hữu ích. Vì T được chọn từ S, nên T dự kiến sẽ
chứa đủ dữ liệu để suy ra các phép tính được xác định bởi S, và
không cần đánh giá tính đầy đủ của đặc điểm kỹ thuật của T. Tương
tự, nếu T có nguồn gốc từ P, sẽ rất hữu ích khi đánh giá xem T có
đầy đủ thông số kỹ thuật hay không.
Các sinh viên được khuyến khích đọc bài báo của Stuart H. Zweben
và John S. Gourlay có tựa đề “Về tính đầy đủ của các tiên đề về dữ
liệu thử nghiệm của Weyuker” [15] Các tác giả nêu vấn đề về điều gì
tạo nên một hệ tiên đề cũng như những gì cấu thành tiên đề thích
hợp. Weyuker phản hồi những lời chỉ trích ở cuối bài báo. Những
sinh viên đó chưa bao giờ nhìn thấy một cuộc trao đổi chuyên nghiệp
như vậy; điều này đáng đọc cho riêng khía cạnh này. Bài báo này
phải được đọc cùng với bài báo của Elaine Weyuker có tựa đề “Tiên
đề hóa tính đầy đủ của dữ liệu kiểm tra phần mềm” [12].
Martin David và Elaine Weyuker [9] trình bày một khái niệm thú vị
về khoảng cách giữa các chương trình để nghiên cứu khái niệm về
tính đầy đủ của dữ liệu thử nghiệm. Cụ thể, chúng tương đương với
khả năng của một bộ thử nghiệm để có thể phân biệt thành công một
chương trình đang được thử nghiệm với tất cả các chương trình đủ
gần với nó và khác nhau về hành vi đầu vào - đầu ra với chương trình
đã cho.
Weyuker [12, 21] đã đề xuất một tập hợp các thuộc tính để đánh giá
các tiêu chí về tính đầy đủ của dữ liệu thử nghiệm. Một số ví dụ về
tiêu chí đầy đủ là (i) đảm bảo phạm vi bao phủ của tất cả các nhánh
trong chương trình đang được thử nghiệm và (ii) đảm bảo rằng các
giá trị biên của tất cả dữ liệu đầu vào đã được chọn cho chương trình
đang được thử nghiệm. Parrish và Zweben [11] đã chính thức hóa các
thuộc tính đó và xác định các phụ thuộc trong tập hợp. Họ chính thức
95
hóa các thuộc tính đầy đủ liên quan đến các tiêu chí không sử dụng
đặc điểm kỹ thuật của chương trình đang được thử nghiệm.
Frankl và Weyuker [10] đã so sánh khả năng phát hiện lỗi tương đối
của một số kỹ thuật kiểm tra cấu trúc, cụ thể là kiểm tra luồng dữ
liệu, kiểm tra đột biến và kỹ thuật bao phủ điều kiện, với kiểm tra
nhánh. Họ đã chỉ ra rằng ba kỹ thuật trước đây tốt hơn so với kiểm
tra nhánh theo hai biện pháp xác suất.
Một khảo sát tốt về tính đầy đủ của thử nghiệm được trình bày trong
một bài báo của Hong Zhu, Patrick AV Hall và John HR May có tựa
đề “Mức độ phù hợp và phạm vi kiểm tra của đơn vị phần mềm”
[14]. Trong bài viết này, các loại tiêu chí kiểm tra mức độ đầy đủ
khác nhau được đề xuất trong tài liệu được khảo sát, sau đó là tóm tắt
các phương pháp so sánh và đánh giá các tiêu chí kiểm tra đầy đủ.
CHAPTER
3
UnitTesting
Kiến thức không có giá trị gì trừ khi bạn đưa nó vào thực tế.
—AntonChekhov
3.1 KHÁI NIỆM VỀ KIỂM TRA ĐƠN VỊ
Trong chương này, chúng ta xem xét mức độ đầu tiên của kiểm thử,
đó là kiểm thử đơn vị. Kiểm thử đơn vị đề cập đến việc kiểm tra các
đơn vị chương trình một cách riêng biệt. Tuy nhiên, không có sự
thống nhất về định nghĩa của một đơn vị. Một số ví dụ về các đơn vị
thường được hiểu là hàm, thủ tục hoặc phương thức. Ngay cả một
lớp trong ngôn ngữ lập trình hướng đối tượng cũng có thể được coi là
một đơn vị chương trình. Về mặt cú pháp, một đơn vị chương trình là
một đoạn mã, chẳng hạn như hàm hoặc phương thức của lớp, được
gọi từ bên ngoài đơn vị và có thể gọi các đơn vị chương trình khác.
Hơn nữa, một đơn vị chương trình được giả định để thực hiện một
chức năng được xác định rõ cung cấp một mức độ trừu tượng nhất
định để thực hiện các chức năng mức cao hơn. Chức năng được thực
hiện bởi một đơn vị chương trình có thể không có liên kết trực tiếp
với một chức năng cấp hệ thống. Do đó, một đơn vị chương trình có
thể được xem như một đoạn mã thực hiện một chức năng ở cấp độ
“thấp”. Trong chương này, chúng tôi sử dụng thuật ngữ đơn vị và
mô-đun thay thế cho nhau.
Bây giờ, khi một đơn vị chương trình thực hiện một chức năng, việc
kiểm tra đơn vị đó trước khi nó được tích hợp với các đơn vị khác là
điều đương nhiên. Do đó, một đơn vị chương trình được kiểm tra một
cách riêng biệt, tức là, theo cách độc lập. Có hai lý do để kiểm tra
một đơn vị theo cách độc lập. Đầu tiên, các lỗi được tìm thấy trong
quá trình thử nghiệm có thể được quy cho một đơn vị cụ thể để có
thể dễ dàng sửa chữa. Hơn nữa, kiểm thử đơn vị loại bỏ sự phụ thuộc
vào các đơn vị chương trình khác. Thứ hai, trong quá trình thử
nghiệm đơn vị, cần xác minh rằng mỗi lần thực thi riêng biệt của một
3.2 KIỂM TRA ĐƠN VỊ THỐNG KÊ 97
đơn vị chương trình tạo ra kết quả mong đợi. Về chi tiết mã, một
thực thi riêng biệt đề cập đến một đường dẫn riêng biệt trong đơn vị.
Lý tưởng nhất là tất cả các khả năng có thể — hoặc càng nhiều càng
tốt — các thực thi riêng biệt phải được xem xét trong quá trình thử
nghiệm đơn vị. Điều này đòi hỏi phải lựa chọn cẩn thận dữ liệu đầu
vào cho mỗi lần thực thi riêng biệt. Một lập trình viên có quyền truy
cập trực tiếp vào vectơ đầu vào của đơn vị bằng cách thực thi đơn vị
chương trình một cách riêng biệt. Quyền truy cập trực tiếp này giúp
dễ dàng thực thi nhiều đường dẫn khác nhau nhất có thể. Nếu nhiều
đơn vị được ghép lại với nhau cho
51
thử nghiệm, sau đó một lập trình viên cần tạo đầu vào thử nghiệm có
mối quan hệ gián tiếp với các vectơ đầu vào của một số đơn vị được
thử nghiệm. Mối quan hệ gián tiếp nói trên gây khó khăn cho việc
kiểm soát việc thực hiện các đường dẫn riêng biệt trong một đơn vị
đã chọn.
Kiểm thử đơn vị có một phạm vi hạn chế. Một lập trình viên sẽ cần
xác minh xem mã có hoạt động chính xác hay không bằng cách thực
hiện kiểm tra cấp đơn vị. Một cách trực quan, một lập trình viên cần
kiểm tra một đơn vị như sau:
Thực thi mọi dòng mã. Điều này là mong muốn vì lập trình viên cần
biết điều gì sẽ xảy ra khi một dòng mã được thực thi. Trong trường
hợp không có những quan sát cơ bản như vậy, những bất ngờ ở giai
đoạn sau có thể tốn kém. • Thực thi mọi vị từ trong đơn vị để đánh
giá chúng thành true và false riêng biệt.
Quan sát rằng thiết bị thực hiện chức năng dự kiến của nó và đảm
bảo rằng nó không có lỗi đã biết.
Bất chấp các thử nghiệm trên, không có gì đảm bảo rằng một thiết bị
được thử nghiệm đạt yêu cầu là đúng về mặt chức năng từ góc độ
toàn hệ thống. Không phải mọi thứ liên quan đến một đơn vị đều có
thể được kiểm tra một cách riêng biệt vì những hạn chế của việc
kiểm tra riêng biệt. Điều này có nghĩa là một số lỗi trong một đơn vị
98 CHƯƠNG 3 KIỂM TRA ĐƠN VỊ
chương trình chỉ có thể được tìm thấy sau đó, khi đơn vị đó được tích
hợp với các đơn vị khác trong giai đoạn thử nghiệm tích hợp và thử
nghiệm hệ thống. Mặc dù không thể tìm thấy tất cả các lỗi trong một
đơn vị chương trình một cách riêng biệt, nhưng vẫn cần đảm bảo
rằng một đơn vị hoạt động tốt trước khi nó được sử dụng bởi các đơn
vị chương trình khác. Việc tích hợp một đơn vị bị lỗi với các đơn vị
khác không có mục đích vì những lý do sau: (i) nhiều thử nghiệm
tiếp theo sẽ gây lãng phí tài nguyên và (ii) việc tìm ra nguyên nhân
gốc rễ của các lỗi trong một hệ thống tích hợp sẽ tiêu tốn nhiều tài
nguyên hơn.
Kiểm thử đơn vị được thực hiện bởi lập trình viên viết đơn vị chương
trình vì người lập trình đã quen thuộc với các chi tiết bên trong của
đơn vị. Mục tiêu của lập trình viên là hài lòng rằng thiết bị hoạt động
như mong đợi. Vì một lập trình viên phải xây dựng một đơn vị không
có lỗi trong đó, nên một kiểm thử đơn vị được thực hiện bởi người đó
để họ hài lòng ngay từ đầu và để làm hài lòng các lập trình viên khác
khi đơn vị đó được tích hợp với các đơn vị khác. Điều này có nghĩa
là tất cả các lập trình viên phải chịu trách nhiệm về chất lượng công
việc của chính họ, có thể bao gồm cả mã mới và các sửa đổi đối với
mã hiện có. Ý tưởng ở đây là đẩy khái niệm chất lượng xuống mức
thấp nhất của tổ chức và trao quyền cho mỗi lập trình viên chịu trách
nhiệm về chất lượng của chính mình. Vì vậy, lợi ích tốt nhất của lập
trình viên là thực hiện các hành động phòng ngừa để giảm thiểu số
lượng lỗi trong mã. Các khiếm khuyết được tìm thấy trong quá trình
kiểm thử đơn vị là nội bộ của nhóm phát triển phần mềm và không
được báo cáo lên hệ thống phân cấp nhân sự để được tính trong các
chỉ số đo lường chất lượng. Mã nguồn của một đơn vị không được
các thành viên nhóm khác sử dụng để giao tiếp cho đến khi lập trình
viên hoàn thành việc kiểm tra đơn vị và kiểm tra trong đơn vị đó với
hệ thống điều khiển phiên bản.
Kiểm thử đơn vị được tiến hành trong hai giai đoạn bổ sung:
Kiểm tra đơn vị tĩnh
Kiểm tra đơn vị động
Trong thử nghiệm đơn vị tĩnh, một lập trình viên không thực thi đơn
vị; thay vào đó, mã được kiểm tra tất cả các hành vi có thể xảy ra
trong thời gian chạy. Kiểm thử đơn vị tĩnh còn được gọi là kiểm thử
đơn vị không dựa trên thực thi, trong khi kiểm thử đơn vị động dựa
trên thực thi. Trong thử nghiệm đơn vị tĩnh, mã của mỗi đơn vị được
xác nhận theo yêu cầu của đơn vị bằng cách xem xét mã. Trong quá
trình xem xét, các vấn đề tiềm ẩn được xác định và giải quyết. Ví dụ,
trong ngôn ngữ lập trình C, hai lệnh tạm dừng chương trình là abort
() và exit (). Mặc dù cả hai có liên quan chặt chẽ với nhau, nhưng
chúng có những tác động khác nhau như được giải thích dưới đây:
Abort (): Điều này có nghĩa là kết thúc chương trình bất thường.
Theo mặc định, lệnh gọi abort () dẫn đến chẩn đoán thời gian chạy và
chương trình tự hủy. Việc phá hủy chương trình có thể xóa và đóng
các tệp đã mở hoặc xóa các tệp tạm thời, tùy thuộc vào việc triển
khai.
Exit (): Điều này có nghĩa là chấm dứt chương trình có thời hạn.
Nghĩa là, lệnh gọi exit () đóng các tệp đã mở và trả về mã trạng thái
cho môi trường thực thi.
Việc sử dụng abort () hay exit () tùy thuộc vào ngữ cảnh có thể dễ
dàng phát hiện và giải quyết trong quá trình kiểm tra đơn vị tĩnh.
Nhiều vấn đề được phát hiện sớm hơn dẫn đến ít lỗi hơn được xác
định trong giai đoạn thử nghiệm động và dẫn đến ít lỗi hơn trong các
sản phẩm được vận chuyển. Hơn nữa, thực hiện các bài kiểm tra tĩnh
ít tốn kém hơn so với việc thực hiện các bài kiểm tra động. Rà soát
mã là một thành phần của quy trình giảm thiểu lỗi và có thể giúp phát
hiện các vấn đề thường gặp trong quá trình phát triển phần mềm. Sau
một vòng xem xét mã, thử nghiệm đơn vị động được tiến hành.
Trong thử nghiệm đơn vị động, một đơn vị chương trình thực sự
được thực thi và kết quả của nó được quan sát. Kiểm tra đơn vị động
có nghĩa là kiểm tra mã bằng cách thực sự chạy nó. Có thể lưu ý rằng
kiểm thử đơn vị tĩnh không phải là một giải pháp thay thế cho kiểm
thử đơn vị động. Một lập trình viên thực hiện cả hai loại kiểm tra.
Trong thực tế, kiểm thử đơn vị động từng phần được thực hiện đồng
thời với kiểm thử đơn vị tĩnh. Nếu toàn bộ kiểm thử đơn vị động đã
được thực hiện và kiểm thử đơn vị tĩnh xác định được các vấn đề
nghiêm trọng thì kiểm thử đơn vị động phải được lặp lại. Kết quả của
sự lặp lại này, lịch trình phát triển có thể bị ảnh hưởng. Để giảm
thiểu xác suất của sự kiện như vậy, yêu cầu phải thực hiện thử
nghiệm đơn vị tĩnh trước khi kiểm tra đơn vị động cuối cùng.
3.2 KIỂM TRA ĐƠN VỊ THỐNG KÊ
Kiểm thử đơn vị tĩnh được tiến hành như một phần của niềm tin triết
học lớn hơn rằng một sản phẩm phần mềm phải trải qua một giai
đoạn kiểm tra và sửa chữa ở mỗi mốc quan trọng trong vòng đời của
nó. Tại một mốc nhất định, sản phẩm không cần phải ở dạng cuối
cùng. Ví dụ, hoàn thành mã hóa là một cột mốc quan trọng, mặc dù
việc mã hóa tất cả các đơn vị có thể không tạo ra sản phẩm mong
muốn. Sau khi mã hóa, cột mốc tiếp theo là kiểm tra tất cả hoặc một
số lượng đáng kể các đơn vị tạo thành các thành phần chính của sản
phẩm. Do đó, trước khi các đơn vị được kiểm tra riêng bằng cách
thực thi chúng, chúng phải được xem xét và hiệu chỉnh thông thường
như người ta thường hiểu. Ý tưởng đằng sau việc xem xét là tìm ra
các khuyết tật càng gần điểm xuất phát của chúng càng tốt để các
khuyết tật đó được loại bỏ với ít nỗ lực hơn và sản phẩm tạm thời
chứa ít khuyết tật hơn trước khi thực hiện nhiệm vụ tiếp theo.
Trong thử nghiệm đơn vị tĩnh, mã được xem xét bằng cách áp dụng
các kỹ thuật thường được gọi là kiểm tra và hướng dẫn. Định nghĩa
ban đầu về kiểm tra được đặt ra bởi Michael Fagan [1] và định nghĩa
hướng dẫn của Edward Yourdon [2]:
Kiểm tra: Nó là một nhóm đồng nghiệp xem xét từng bước một sản
phẩm làm việc, với mỗi bước được kiểm tra dựa trên các tiêu chí đã
định trước.
Hướng dẫn: Đây là một bài đánh giá trong đó tác giả dẫn dắt nhóm
thông qua việc thực hiện sản phẩm theo cách thủ công hoặc mô
phỏng bằng cách sử dụng các tình huống được xác định trước.
Bất kể việc xem xét được gọi là kiểm tra hay hướng dẫn, nó là một
cách tiếp cận có hệ thống để kiểm tra mã nguồn một cách chi tiết.
Mục tiêu của bài tập như vậy là để đánh giá chất lượng của phần
mềm được đề cập, chứ không phải chất lượng của quá trình được sử
dụng để phát triển sản phẩm [3]. Các đánh giá kiểu này được đặc
trưng bởi sự chuẩn bị đáng kể của các nhóm nhà thiết kế và lập trình
với mức độ quan tâm khác nhau đến dự án phát triển phần mềm.
Việc kiểm tra mã có thể tốn nhiều thời gian. Hơn nữa, không có quy
trình khám bệnh nào là hoàn hảo. Người giám định có thể đi đường
tắt, có thể không có hiểu biết đầy đủ về sản phẩm và có thể chấp
nhận một sản phẩm không được chấp nhận. Tuy nhiên, quy trình xem
xét mã được thiết kế tốt có thể tìm ra các lỗi có thể bị bỏ sót bằng
cách kiểm tra dựa trên thực thi. Chìa khóa thành công của việc xem
xét mã là phân chia và chinh phục, nghĩa là, có một giám khảo kiểm
tra các phần nhỏ của đơn vị một cách riêng biệt, đồng thời đảm bảo
những điều sau: (i) không có gì bị bỏ qua và (ii) tính đúng đắn của tất
cả các phần được kiểm tra của mô-đun ngụ ý tính đúng đắn của toàn
bộ mô-đun. Việc phân chia quá trình xem xét thành các bước rời rạc
phải đảm bảo rằng mỗi bước đủ đơn giản để có thể thực hiện mà
không cần kiến thức chi tiết về các bước khác.
Mục tiêu của việc xem xét mã là xem xét mã, không phải để đánh giá
tác giả của mã. Có thể xảy ra xung đột giữa tác giả của mã và những
người đánh giá, và điều này có thể làm cho các cuộc họp không hiệu
quả. Do đó, việc rà soát mã phải được lập kế hoạch và quản lý một
cách chuyên nghiệp. Cần có sự tôn trọng lẫn nhau, cởi mở, tin tưởng
và chia sẻ kiến thức chuyên môn trong nhóm. Các hướng dẫn chung
để thực hiện xem xét mã bao gồm sáu bước như được nêu trong Hình
3.1: sẵn sàng, chuẩn bị, kiểm tra, làm lại, xác nhận và thoát. Đầu vào
cho bước sẵn sàng là các tiêu chí phải được đáp ứng trước khi bắt
đầu quá trình xem xét mã và quá trình này tạo ra hai loại tài liệu, một
yêu cầu thay đổi (CR) và một báo cáo. Các bước và tài liệu này được
giải thích trong phần sau.
Bước 1: Sẵn sàng Tác giả của đơn vị đảm bảo rằng đơn vị được
kiểm tra đã sẵn sàng để xem xét. Một đơn vị được cho là sẵn sàng
nếu nó đáp ứng các tiêu chí sau:
Tính đầy đủ: Tất cả các mã liên quan đến đơn vị được xem xét phải
có sẵn. Điều này là do những người đánh giá sẽ đọc mã và cố gắng
hiểu nó. Sẽ không hiệu quả khi xem lại mã đã viết một phần hoặc mã
sẽ được sửa đổi đáng kể bởi lập trình viên.
Criteria Readiness
Preparation
Change
Examination requests
Rework
Validation
Exit Report
Hình 3.1 Các bước trong quá trình xem xét mã.
Chức năng tối thiểu: Mã phải biên dịch và liên kết. Hơn nữa, mã
phải được kiểm tra ở một mức độ nào đó để đảm bảo rằng nó thực
hiện các chức năng cơ bản của nó.
Khả năng đọc: Vì việc xem xét mã liên quan đến việc đọc mã thực
tế của các lập trình viên khác, điều cần thiết là mã phải có khả năng
đọc cao. Một số đặc điểm mã tăng cường khả năng đọc là định dạng
thích hợp, sử dụng tên định danh có ý nghĩa, sử dụng dễ dàng các cấu
trúc ngôn ngữ lập trình và mức độ trừu tượng thích hợp bằng cách sử
dụng các lệnh gọi hàm. Trong trường hợp không có khả năng đọc,
những người đánh giá có thể sẽ nản lòng trong việc thực hiện nhiệm
vụ một cách hiệu quả.
Độ phức tạp: Không cần phải lên lịch họp nhóm để xem xét mã đơn
giản mà lập trình viên có thể dễ dàng xem xét. Mã được xem xét phải
có đủ độ phức tạp để đảm bảo việc xem xét của nhóm. Ở đây, độ
phức tạp là một thuật ngữ tổng hợp đề cập đến số câu lệnh điều kiện
trong mã, số phần tử dữ liệu đầu vào của đơn vị, số phần tử dữ liệu
đầu ra do đơn vị tạo ra, quá trình xử lý mã theo thời gian thực và số
của các đơn vị khác mà mã giao tiếp với nhau.
Yêu cầu và tài liệu thiết kế: Phiên bản mới nhất được phê duyệt của
đặc điểm kỹ thuật thiết kế cấp thấp hoặc các mô tả thích hợp khác
BẢNG 3.1 Thứ bậc của tài liệu hệ thống
Yêu cầu: Tiếp thị cấp cao hoặc đề xuất sản phẩm.
Đặc tả chức năng: Phản ứng của kỹ thuật phần mềm đối với đề xuất
tiếp thị.
Thiết kế cấp cao: Kiến trúc hệ thống tổng thể.
Thiết kế cấp thấp: Đặc tả chi tiết của các mô-đun trong kiến trúc.
Lập trình: Mã hóa các mô-đun.
yêu cầu của chương trình (xem Bảng 3.1) nên có sẵn. Các tài liệu này
giúp người đánh giá xác minh xem mã đang xem xét có triển khai các
chức năng mong đợi hay không. Nếu tài liệu thiết kế cấp thấp có sẵn,
nó sẽ giúp người đánh giá đánh giá xem mã có triển khai thiết kế một
cách thích hợp hay không.
Tất cả những người tham gia vào quá trình xem xét đều được thông
báo về lịch họp nhóm xem xét hai hoặc ba ngày trước cuộc họp. Họ
cũng được cung cấp một bản sao của gói công việc để xem xét. Việc
xem xét được tiến hành liên tục từ 1 đến 2 giờ. Các cuộc họp kéo dài
ngày càng ít hiệu quả hơn vì sự chú ý của con người bị hạn chế. Tốc
độ xem xét mã được giới hạn trong khoảng 125 dòng mã (bằng ngôn
ngữ cấp cao) mỗi giờ. Việc xem lại mã phức tạp với tốc độ cao hơn
sẽ dẫn đến việc chỉ làm bóng trên mã, do đó đánh bại mục đích cơ
bản của việc xem lại mã. Thành phần của nhóm đánh giá bao gồm
một số người với các vai trò khác nhau. Các vai trò này được giải
thích như sau:
Người điều hành: Một cuộc họp đánh giá do người điều hành chủ
trì. Người kiểm duyệt là một cá nhân được đào tạo, người hướng dẫn
tốc độ của quá trình xem xét. Người điều hành chọn những người
đánh giá và lên lịch các cuộc họp đánh giá. Myers gợi ý rằng người
điều hành là thành viên của một nhóm từ một dự án không liên quan
để bảo toàn tính khách quan [4].
Tác giả: Đây là người đã viết mã để được xem xét.
Người trình bày: Người thuyết trình là người không phải là tác giả
của mã. Người thuyết trình đọc mã trước để hiểu nó. Người thuyết
trình trình bày mã của tác giả trong cuộc họp đánh giá vì những lý do
sau: (i) một nhà phát triển phần mềm bổ sung sẽ hiểu công việc trong
tổ chức phần mềm; (ii) nếu lập trình viên ban đầu rời công ty với một
thông báo ngắn, ít nhất một lập trình viên khác trong công ty biết
những gì đang được thực hiện; và (iii) lập trình viên ban đầu sẽ có
cảm giác tốt về công việc của mình, nếu ai đó đánh giá cao công việc
của họ. Thông thường, người thuyết trình đánh giá cao tác phẩm của
tác giả.
ghi chép: Người ghi chép tài liệu về các vấn đề được tìm thấy trong
quá trình xem xét và các hành động tiếp theo được đề xuất. Người đó
phải khác với tác giả và người kiểm duyệt.
Người đánh giá: Đây là những chuyên gia trong lĩnh vực chủ đề của
mã đang được xem xét. Quy mô nhóm phụ thuộc vào nội dung của
tài liệu được xem xét. Theo quy tắc chung, quy mô nhóm là từ 3 đến
7. Thông thường nhóm này không có người quản lý mà tác giả báo
cáo. Điều này là do tác phẩm đang diễn ra của tác giả đang được xem
xét, và không phải tác phẩm đã hoàn thành cũng như bản thân tác giả
đang được xem xét.
Người quan sát: Đây là những người muốn tìm hiểu về mã đang
được xem xét. Những người này không tham gia vào quá trình xem
xét mà chỉ đơn giản là những người quan sát thụ động.
Bước Chuẩn bị Trước cuộc họp, mỗi người đánh giá sẽ xem xét
2: cẩn thận gói công việc. Người đánh giá phải đọc mã và hiểu
tổ chức và hoạt động của nó trước cuộc họp đánh giá. Mỗi
người đánh giá phát triển những điều sau:
Danh sách các câu hỏi: Một người đánh giá chuẩn bị một
danh sách các câu hỏi sẽ được hỏi, nếu cần, của tác giả để
làm rõ các vấn đề nảy sinh từ việc đọc của họ. Hướng dẫn
chung về những gì cần kiểm tra khi đọc mã được nêu trong
Bảng 3.2.
CR tiềm năng: Người đánh giá có thể đưa ra yêu cầu chính
thức để thực hiện thay đổi. Đây được gọi là các yêu cầu thay
đổi chứ không phải là báo cáo lỗi. Ở giai đoạn này, vì lập
trình viên vẫn chưa công khai mã, nên sẽ thích hợp hơn để
đưa ra đề xuất với tác giả để thực hiện các thay đổi, hơn là
báo cáo một khiếm khuyết. Mặc dù CR tập trung vào các lỗi
trong mã, các báo cáo này không được đưa vào thống kê lỗi
liên quan đến sản phẩm.
Cơ hội cải tiến được đề xuất: Người đánh giá có thể đề xuất
cách khắc phục sự cố, nếu có, trong mã đang xem xét. Vì
những người đánh giá là chuyên gia trong lĩnh vực chủ đề
của mã, nên không có gì lạ khi họ đưa ra các đề xuất cải tiến.
Bước Kiểm tra Quy trình kiểm tra Các hoạt động tiếp
3: theo:
Tác giả trình bày về logic thủ tục được sử dụng trong mã, các đường
dẫn biểu thị các phép tính chính và sự phụ thuộc của đơn vị đang
được xem xét vào các đơn vị khác.
Người thuyết trình đọc từng dòng mã. Người đánh giá có thể đưa ra
câu hỏi nếu mã được thấy là có khiếm khuyết. Tuy nhiên, các vấn đề
không được giải quyết trong cuộc họp. Người đánh giá có thể đưa ra
các đề xuất chung về cách sửa chữa các khiếm khuyết, nhưng việc
thực hiện các biện pháp sửa chữa sau khi cuộc họp kết thúc là tùy
thuộc vào tác giả của quy tắc.
Người ghi chép tài liệu các yêu cầu thay đổi và các đề xuất để khắc
phục sự cố, nếu có. CR bao gồm các chi tiết sau:
Đưa ra mô tả ngắn gọn về vấn đề hoặc mục hành động.
Chỉ định mức độ ưu tiên (chính hoặc phụ) cho CR.
Chỉ định một người theo dõi vấn đề. Vì vấn đề tiềm ẩn của tài liệu
CR, nên cần có sự tương tác giữa tác giả
BẢNG 3.2 Danh sách kiểm tra đánh giá mã
Mã có thực hiện những gì đã được chỉ định trong đặc điểm kỹ thuật
thiết kế không?
Quy trình được sử dụng trong mô-đun có giải quyết được vấn đề một
cách chính xác không?
Một mô-đun phần mềm có sao chép một mô-đun hiện có khác có thể
được sử dụng lại không?
Nếu các mô-đun thư viện đang được sử dụng, có đúng thư viện và
phiên bản phù hợp của thư viện đang được sử dụng không?
Mỗi mô-đun có một điểm vào duy nhất và một điểm thoát duy nhất
không? Nhiều chương trình điểm đầu ra và điểm vào khó kiểm tra
hơn.
Độ phức tạp theo chu kỳ của mô-đun có lớn hơn 10 không? Nếu có,
thì rất khó để kiểm tra đầy đủ mô-đun.
Mỗi chức năng nguyên tử có thể được xem lại và hiểu trong 10-15
phút không? Nếu không, nó được coi là quá phức tạp.
Các quy ước đặt tên có được tuân theo cho tất cả các số nhận dạng,
chẳng hạn như con trỏ, chỉ số, biến, mảng và hằng số không? Điều
quan trọng là phải tuân thủ các tiêu chuẩn mã hóa để dễ dàng giới
thiệu một người đóng góp mới (lập trình viên) cho sự phát triển của
hệ thống.
Mã đã được nhận xét đầy đủ chưa?
Tất cả các biến và hằng số đã được khởi tạo chính xác chưa? Đã
kiểm tra đúng loại và phạm vi chưa?
Các biến toàn cục hoặc biến chia sẻ, nếu có, có được kiểm soát cẩn
thận không?
Có các giá trị dữ liệu được mã hóa cứng trong chương trình không?
Thay vào đó, chúng nên được khai báo dưới dạng các biến.
Các con trỏ có được sử dụng đúng cách không?
Các khối bộ nhớ có được động có được phân bổ sau khi sử dụng
không?
Mô-đun có kết thúc bất thường không? Mô-đun cuối cùng sẽ kết
thúc?
Có khả năng xảy ra một vòng lặp vô hạn, một vòng lặp không bao
giờ thực thi hoặc một vòng lặp có lối ra sớm không?
Tất cả các tệp đã được mở để sử dụng và bị đóng khi kết thúc chưa?
Có các phép tính sử dụng các biến có kiểu dữ liệu không nhất quán
không? Có khả năng xảy ra tràn hoặc tràn không?
Mã lỗi và thông báo điều kiện có được tạo ra bằng cách truy cập một
bảng thông báo chung không? Mỗi mã lỗi phải có một ý nghĩa và tất
cả các ý nghĩa phải có sẵn ở một nơi trong bảng chứ không phải nằm
rải rác trên toàn bộ mã chương trình.
Mã có di động không? Mã nguồn có thể thực thi trên nhiều kiến trúc
bộ xử lý và trên các hệ điều hành khác nhau trong suốt thời gian tồn
tại của nó. Nó phải được thực hiện theo cách không loại trừ nhiều
loại môi trường thực thi này.
Mã có hiệu quả không? Nói chung, không nên hy sinh tính rõ ràng,
dễ đọc hoặc tính đúng đắn để đạt được hiệu quả. Việc xem xét mã
nhằm phát hiện các lựa chọn triển khai có ảnh hưởng xấu đến hiệu
suất của hệ thống.
của mã và một trong những người đánh giá, có thể là người đánh giá
đã thực hiện CR.
4. Đặt thời hạn để giải quyết CR.
Người điều hành đảm bảo rằng cuộc họp vẫn tập trung vào quá trình
xem xét. Người điều hành đảm bảo rằng cuộc họp đạt được tiến độ ở
một tốc độ nhất định để đạt được mục tiêu của cuộc họp.
Vào cuối cuộc họp, một quyết định được đưa ra về việc có nên gọi
một cuộc họp khác để xem xét thêm quy tắc hay không. Nếu quá
trình xem xét dẫn đến việc làm lại toàn bộ quy tắc hoặc các vấn đề
quan trọng được xác định trong quá trình này, thì một cuộc họp khác
thường được triệu tập. Nếu không, cuộc họp thứ hai sẽ không được
lên lịch và tác giả được giao trách nhiệm sửa các CR.
Bước Làm lại Khi kết thúc cuộc họp, người ghi chép bản tóm tắt
4: cuộc họp bao gồm các thông tin sau: • Danh sách tất cả các
CR, ngày sửa những CR và tên của những người chịu trách
nhiệm xác nhận CR.
Danh sách các cơ hội cải tiến
Biên bản cuộc họp (tùy chọn)
Một bản sao của báo cáo được phân phát cho tất cả các thành
viên của nhóm đánh giá. Sau cuộc họp, tác giả làm việc trên
các CR để sửa chữa các vấn đề. Tác giả ghi lại những cải tiến
được thực hiện đối với mã trong CRs. Tác giả cố gắng giải
quyết các vấn đề trong khung thời gian đã thỏa thuận bằng
cách sử dụng các quy ước mã hóa phổ biến [5].
Bước Xác thực Các CR được xác nhận độc lập bởi người kiểm
5: duyệt hoặc một người khác được chỉ định cho mục đích này.
Quá trình xác nhận bao gồm việc kiểm tra mã đã sửa đổi như
được ghi trong CR và đảm bảo rằng các cải tiến được đề xuất
đã được triển khai chính xác. Phiên bản sửa đổi và cuối cùng
của kết quả của cuộc họp đánh giá được phân phối cho tất cả
các thành viên trong nhóm.
Bước Thoát Tóm tắt quá trình xem xét, được cho là hoàn tất nếu
6: tất cả các hành động sau đã được thực hiện:
Mọi dòng mã trong thiết bị đã được kiểm tra.

Nếu có quá nhiều khiếm khuyết được tìm thấy trong một mô-đun,
mô-đun đó sẽ được xem xét lại một lần nữa sau khi tác giả áp dụng
các hiệu chỉnh. Theo nguyên tắc chung, nếu hơn 5% tổng số dòng mã
được cho là gây tranh cãi, thì việc xem xét thứ hai sẽ được lên lịch.
Tác giả và những người đánh giá đạt được sự đồng thuận rằng khi áp
dụng các hiệu chỉnh, mã sẽ có khả năng không có sai sót. • Tất cả các
CR đều được ghi lại và xác nhận bởi người kiểm duyệt hoặc người
khác. Các hành động tiếp theo của tác giả được ghi lại.
Một báo cáo tóm tắt của cuộc họp bao gồm các CR được phân phát
cho tất cả các thành viên của nhóm đánh giá.
Hiệu quả của kiểm thử tĩnh bị giới hạn bởi khả năng của người đánh
giá để tìm ra các khiếm khuyết trong mã bằng các phương tiện trực
quan. Tuy nhiên, nếu sự xuất hiện của các khuyết tật phụ thuộc vào
một số giá trị thực tế của các biến, thì việc xác định các khuyết tật đó
bằng mắt thường là một nhiệm vụ khó khăn. Do đó, một đơn vị phải
được thực thi để quan sát các hành vi của nó để đáp ứng với nhiều
loại đầu vào. Cuối cùng, bất cứ điều gì có thể là hiệu quả của các bài
kiểm tra tĩnh, người ta không thể cảm thấy tự tin nếu không thực sự
chạy mã.
Số liệu đánh giá mã Điều quan trọng là phải thu thập dữ liệu đo
lường liên quan đến quá trình xem xét, để quá trình xem xét có thể
được đánh giá, hiển thị cho lãnh đạo cấp trên như một chiến lược
kiểm tra và được cải thiện để hiệu quả hơn. Hơn nữa, việc thu thập
các số liệu trong quá trình xem xét mã tạo điều kiện thuận lợi cho
việc ước tính thời gian xem xét và nguồn lực cho các dự án trong
tương lai. Vì vậy, xem xét mã là một chiến lược kiểm tra khả thi có
thể được sử dụng hiệu quả để cải thiện chất lượng của sản phẩm ở
giai đoạn đầu. Các chỉ số sau có thể được thu thập từ việc xem xét
mã:
Số dòng mã (LOC) được xem xét mỗi giờ
Số CR được tạo trên một nghìn dòng mã (KLOC)
Số CR được tạo mỗi giờ
Tổng số CR được tạo cho mỗi dự án
Tổng số giờ dành cho việc xem xét mã cho mỗi dự án
3.3 PHÒNG NGỪA ĐÁNH BẠI
Vì lợi ích tốt nhất của các lập trình viên nói riêng và công ty nói
chung là giảm số lượng CR được tạo ra trong quá trình xem xét mã.
Điều này là do CR là dấu hiệu của các vấn đề tiềm ẩn trong mã và
những vấn đề đó phải được giải quyết trước khi các đơn vị chương
trình khác nhau được tích hợp. Giải quyết các CR có nghĩa là tiêu tốn
nhiều nguồn lực hơn và có khả năng trì hoãn dự án. Do đó, điều cần
thiết là phải áp dụng khái niệm phòng ngừa lỗi trong quá trình phát
triển mã. Trong thực tế, các lỗi được lập trình viên vô tình đưa vào.
Những tai nạn đó có thể được giảm bớt bằng cách thực hiện các biện
pháp phòng ngừa. Sẽ rất hữu ích khi phát triển một bộ hướng dẫn để
xây dựng mã giảm thiểu lỗi như được giải thích trong phần sau. Các
hướng dẫn này tập trung vào việc kết hợp các cơ chế phù hợp vào
mã:
Xây dựng các công cụ chẩn đoán nội bộ, còn được gọi là mã thiết bị,
vào các đơn vị. Mã thiết bị hữu ích trong việc cung cấp thông tin về
trạng thái bên trong của thiết bị. Các mã này cho phép các lập trình
viên nhận ra các cơ chế theo dõi và truy tìm tích hợp sẵn. Thiết bị đo
đạc đóng một vai trò thụ động trong thử nghiệm đơn vị động. Vai trò
bị động theo nghĩa quan sát và ghi lại các hành vi bên trong mà
không chủ động kiểm tra một đơn vị. • Sử dụng các điều khiển tiêu
chuẩn để phát hiện các điều kiện lỗi có thể xảy ra. Một số ví dụ về
phát hiện lỗi trong mã được chia cho 0 và chỉ số mảng nằm ngoài
giới hạn. • Đảm bảo rằng mã tồn tại cho tất cả các giá trị trả về, một
số trong số đó có thể không hợp lệ. Các hành động tiếp theo thích
hợp cần được thực hiện để xử lý các giá trị trả về không hợp lệ.
Đảm bảo rằng các trường dữ liệu bộ đếm và tràn bộ đệm và dòng
dưới được xử lý thích hợp.
Cung cấp thông báo lỗi và văn bản trợ giúp từ một nguồn chung để
những thay đổi trong văn bản không gây ra sự mâu thuẫn. Thông báo
lỗi tốt
3.3 PHÒNG NGỪA ĐÁNH BẠI

xác định nguyên nhân gốc rễ của vấn đề và giúp người dùng giải
quyết vấn đề [7].
Xác thực dữ liệu đầu vào, chẳng hạn như các đối số, được truyền cho
một hàm.
Sử dụng các xác nhận để phát hiện các điều kiện bất khả thi, việc sử
dụng dữ liệu không xác định và hành vi chương trình không mong
muốn. Một khẳng định là một câu lệnh Boolean không bao giờ được
sai hoặc chỉ có thể sai nếu đã xảy ra lỗi. Nói cách khác, một khẳng
định là kiểm tra một điều kiện được cho là đúng, nhưng nó có thể gây
ra vấn đề nếu nó không đúng. Xác nhận nên được sử dụng thường
xuyên để thực hiện các loại kiểm tra sau:
Đảm bảo rằng các điều kiện tiên quyết được thỏa mãn trước khi bắt
đầu thực thi aunit. Điều kiện tiên quyết là một hàm Boolean trên các
trạng thái của một đơn vị xác định kỳ vọng của chúng ta về trạng thái
trước khi bắt đầu một hoạt động trong mã.
Đảm bảo rằng các điều kiện hậu kỳ mong đợi là đúng trong khi thoát
khỏi đơn vị. Hậu điều kiện là một hàm Boolean trên trạng thái của
một đơn vị xác định kỳ vọng của chúng ta về trạng thái sau khi một
hoạt động đã được hoàn thành. Các điều kiện hậu có thể bao gồm
một sự bất biến.
Đảm bảo rằng các giá trị bất biến được giữ nguyên. Đó là, kiểm tra
các trạng thái bất biến — các điều kiện dự kiến sẽ không thay đổi
trong quá trình thực thi một đoạn mã.
Để lại xác nhận trong mã. Bạn có thể hủy kích hoạt chúng trong
phiên bản mã đã phát hành để cải thiện hiệu suất hoạt động của hệ
thống.
Ghi lại đầy đủ các khẳng định có vẻ không rõ ràng.
Sau mỗi lần tính toán chính, hãy tính toán ngược lại (các) đầu vào từ
các kết quả trong chính mã. Sau đó, so sánh kết quả với các đầu vào
thực tế để biết tính đúng đắn. Ví dụ, giả sử rằng một đoạn mã tính
căn bậc hai của một số dương. Sau đó bình phương giá trị đầu ra và
so sánh kết quả với đầu vào. Nó có thể cần thiết để chấp nhận một
khoảng sai số trong quá trình so sánh.
Trong các hệ thống liên quan đến việc truyền thông điệp, quản lý bộ
đệm là một hoạt động nội bộ quan trọng. Các tin nhắn đến được lưu
trữ trong một bộ đệm đã được cấp phát. Sẽ rất hữu ích khi tạo ra một
111
sự kiện cho biết tính khả dụng của bộ đệm thấp trước khi hệ thống
hết bộ đệm. Xây dựng một quy trình để liên tục theo dõi tính khả
dụng của bộ đệm sau mỗi lần sử dụng, tính toán dung lượng trống
còn lại trong bộ đệm và gọi một quy trình xử lý lỗi nếu số lượng
không gian đệm khả dụng quá thấp.
Phát triển một quy trình hẹn giờ đếm ngược từ một thời gian đặt
trước cho đến khi nó chạm 0 hoặc được đặt lại. Nếu phần mềm bị kẹt
trong một vòng lặp vô hạn, bộ đếm thời gian sẽ hết hạn và một quy
trình xử lý ngoại lệ có thể được gọi. • Bao gồm một bộ đếm vòng lặp
trong mỗi vòng lặp. Nếu vòng lặp đã từng được thực thi ít hơn số lần
tối thiểu có thể hoặc nhiều hơn số lần tối đa có thể, thì hãy gọi một
quy trình xử lý ngoại lệ.
Xác định một biến để chỉ ra nhánh của logic quyết định sẽ được thực
hiện. Kiểm tra giá trị này sau khi quyết định đã được thực hiện và
nhánh bên phải đã được cho là đã được thực hiện. Nếu giá trị của
biến chưa được đặt trước, có thể có một điều kiện rơi vào logic.
3.4 KIỂM TRA ĐƠN VỊ ĐỘNG HỌC
Kiểm thử đơn vị dựa trên thực thi được gọi là kiểm thử đơn vị động.
Trong thử nghiệm này, một đơn vị chương trình thực sự được thực
thi một cách riêng biệt, như chúng ta thường hiểu về nó. Tuy nhiên,
thực thi này khác với thực thi thông thường theo cách sau:
Một đơn vị đang được kiểm tra được đưa ra khỏi môi trường thực thi
thực tế của nó.
Môi trường thực thi thực tế được mô phỏng bằng cách viết thêm mã
(sẽ giải thích ở phần sau của phần này) để đơn vị và môi trường giả
lập có thể được biên dịch cùng nhau.
Tổng hợp đã biên dịch ở trên được thực thi với các đầu vào đã chọn.
Kết quả của một quá trình thực thi như vậy được thu thập theo nhiều
cách khác nhau, chẳng hạn như quan sát trực tiếp trên màn hình,
đăng nhập vào tệp và thiết bị phần mềm của mã để tiết lộ hành vi
thời gian chạy. Kết quả được so sánh với kết quả mong đợi. Bất kỳ
sự khác biệt nào giữa kết quả thực tế và dự kiến đều có nghĩa là thất
bại và lỗi nằm trong mã.
Một môi trường để kiểm thử đơn vị động được tạo ra bằng cách mô
phỏng ngữ cảnh của đơn vị được kiểm tra, như thể hiện trong Hình
3.2. Bối cảnh của một bài kiểm tra đơn vị bao gồm hai phần: (i) một
đơn vị gọi của đơn vị và (ii) tất cả các đơn vị được gọi bởi đơn vị.
Môi trường của một thiết bị được mô phỏng vì thiết bị được thử
nghiệm cách ly và môi trường mô phỏng phải là một môi trường đơn
giản để mọi lỗi được phát hiện do vận hành thiết bị đều có thể chỉ
thuộc về thiết bị được thử nghiệm. Đơn vị gọi được gọi là trình điều
khiển thử nghiệm và tất cả các mô phỏng của các đơn vị được gọi bởi
đơn vị đang thử nghiệm được gọi là sơ khai. Trình điều khiển thử
nghiệm và các cuống được gọi là giàn giáo. Các chức năng của trình
điều khiển thử nghiệm và sơ khai được giải thích như sau:
Trình điều khiển thử nghiệm: Trình điều khiển thử nghiệm là một
chương trình gọi đơn vị đang được thử nghiệm. Đơn vị được kiểm tra
thực thi với các giá trị đầu vào nhận được từ trình điều khiển và khi
kết thúc, trả về một giá trị cho trình điều khiển. Người lái xe so sánh
kết quả thực tế, nghĩa là, giá trị thực tế được trả về bởi thiết bị được
thử nghiệm, với kết quả dự kiến từ thiết bị và báo cáo kết quả thử
nghiệm tiếp theo. Trình điều khiển thử nghiệm hoạt động như đơn vị
chính trong quá trình thực thi. Trình điều khiển không chỉ tạo điều
kiện cho việc biên dịch mà còn cung cấp dữ liệu đầu vào cho đơn vị
đang được kiểm tra ở định dạng mong đợi.
Stubs: Stubs là một “chương trình con giả” thay thế một đơn vị được
gọi bởi đơn vị đang kiểm tra. Stubs thay thế các đơn vị được gọi bởi
đơn vị được kiểm tra. Một sơ khai thực hiện hai nhiệm vụ. Đầu tiên,
nó cho thấy bằng chứng cho thấy sơ khai là,
3.4 KIỂM TRA ĐƠN VỊ ĐỘNG HỌC
113
Test Results
driver
Call and pass input

parameters Output parameters
Unit Under Test
Call Acknowledge Call Acknowledge
Print Stub Stub Print
Hình 3.2 Môi trường kiểm thử đơn vị động.

trên thực tế, được gọi là. Bằng chứng như vậy có thể được hiển thị
bằng cách chỉ in một tin nhắn. Thứ hai, phần sơ khai trả về một giá
trị được tính toán trước cho người gọi để đơn vị được kiểm tra có thể
tiếp tục thực thi.
Trình điều khiển và phần sơ khai không bao giờ bị loại bỏ sau khi
hoàn thành bài kiểm tra đơn vị. Thay vào đó, chúng được sử dụng lại
trong tương lai trong kiểm tra hồi quy của đơn vị nếu có nhu cầu như
vậy. Đối với mỗi đơn vị, cần có một trình điều khiển thử nghiệm
chuyên dụng và một số sơ khai theo yêu cầu. Nếu chỉ có một trình
điều khiển thử nghiệm được phát triển để kiểm tra nhiều đơn vị, trình
điều khiển sẽ là một trình điều khiển phức tạp. Bất kỳ sửa đổi nào đối
với trình điều khiển để phù hợp với những thay đổi trong một trong
các đơn vị đang thử nghiệm có thể có tác dụng phụ trong việc kiểm
tra các đơn vị khác. Tương tự, trình điều khiển thử nghiệm không
nên phụ thuộc vào các tệp dữ liệu đầu vào bên ngoài mà thay vào đó,
nên có tập dữ liệu đầu vào được tách biệt riêng. Phương pháp tiếp
cận tệp dữ liệu đầu vào riêng biệt trở thành một lựa chọn rất thuyết
phục cho một lượng lớn dữ liệu đầu vào thử nghiệm. Ví dụ: nếu hàng
trăm phần tử dữ liệu kiểm tra đầu vào được yêu cầu để kiểm tra nhiều
hơn một đơn vị, thì tốt hơn nên tạo một tệp dữ liệu kiểm tra đầu vào
riêng biệt hơn là bao gồm cùng một bộ dữ liệu kiểm tra đầu vào trong
mỗi trình điều khiển kiểm tra được thiết kế để kiểm tra đơn vị.
Trình điều khiển thử nghiệm phải có khả năng tự động xác định sự
thành công hay thất bại của thiết bị được thử nghiệm đối với mỗi dữ
liệu thử nghiệm đầu vào. Nếu thích hợp, trình điều khiển cũng nên
kiểm tra rò rỉ bộ nhớ và các vấn đề trong phân bổ và phân bổ bộ nhớ.
Nếu mô-đun mở và đóng tệp, trình điều khiển thử nghiệm nên kiểm
tra xem các tệp này có được để ở trạng thái mở hoặc đóng dự kiến
sau mỗi lần kiểm tra hay không. Trình điều khiển thử nghiệm có thể
được thiết kế để kiểm tra các giá trị dữ liệu của biến nội bộ mà thông
thường sẽ không có sẵn để kiểm tra ở các mức thử nghiệm tích hợp,
hệ thống hoặc chấp nhận.
Trình điều khiển thử nghiệm và các cuống được kết hợp chặt chẽ với
thiết bị được thử nghiệm và phải đi kèm với thiết bị trong suốt vòng
đời của nó. Trình điều khiển thử nghiệm và các sơ khai của một đơn
vị phải có thể tái sử dụng và bảo trì được. Mỗi khi một đơn vị được
sửa đổi, lập trình viên nên kiểm tra xem có nên sửa đổi trình điều
khiển và sơ khai tương ứng hay không. Bất cứ khi nào một lỗi mới
được phát hiện trong thiết bị, trình điều khiển thử nghiệm tương ứng
phải được cập nhật với một bộ dữ liệu đầu vào mới để phát hiện lỗi
đó và các lỗi tương tự trong tương lai. Nếu thiết bị dự kiến sẽ chạy
trên các nền tảng khác nhau, thì trình điều khiển thử nghiệm và các
sơ khai cũng nên được xây dựng để thử nghiệm thiết bị trên các nền
tảng mới. Cuối cùng, trình điều khiển thử nghiệm và các sơ khai phải
được xem xét, tham chiếu chéo với đơn vị mà chúng được viết, và
đăng ký vào hệ thống kiểm soát phiên bản như một sản phẩm cùng
với thiết bị.
Tài liệu thiết kế cấp thấp cung cấp hướng dẫn lựa chọn dữ liệu kiểm
tra đầu vào có khả năng phát hiện ra các lỗi. Việc lựa chọn dữ liệu
thử nghiệm rộng rãi dựa trên các kỹ thuật sau:
Kiểm tra luồng điều khiển: Sau đây là phác thảo của thử nghiệm
luồng điều khiển: (i) vẽ biểu đồ luồng điều khiển từ một đơn vị
chương trình; (ii) chọn một vài tiêu chí kiểm tra luồng kiểm soát; (iii)
xác định các đường dẫn trong đồ thị luồng điều khiển để thỏa mãn
các tiêu chí lựa chọn; (iv) lấy biểu thức vị từ đường dẫn từ các đường
dẫn đã chọn; và (v) bằng cách giải biểu thức vị từ đường dẫn cho một
đường dẫn, tạo ra các giá trị của các đầu vào cho đơn vị chương trình
115
được coi là trường hợp kiểm tra để thực hiện đường dẫn tương ứng.
Phần thảo luận kỹ lưỡng về thử nghiệm dòng điều khiển được đưa ra
trong Chương 4.
Kiểm tra luồng dữ liệu: Sau đây là phác thảo của kiểm tra luồng dữ
liệu: (i) vẽ biểu đồ luồng dữ liệu từ một đơn vị chương trình; (ii)
chọn một vài tiêu chí kiểm tra luồng dữ liệu; (iii) xác định các đường
dẫn trong biểu đồ luồng dữ liệu để thỏa mãn các tiêu chí lựa chọn;
(iv) lấy biểu thức vị từ đường dẫn từ các đường dẫn đã chọn; và (v)
bằng cách giải biểu thức vị từ đường dẫn, tạo ra các giá trị của các
đầu vào cho đơn vị chương trình được coi là trường hợp kiểm tra để
thực hiện đường dẫn tương ứng. Chương 5 thảo luận chi tiết hơn về
kiểm thử luồng dữ liệu.
Kiểm tra miền: Trong kiểm tra luồng điều khiển và luồng dữ liệu,
không có loại lỗi cụ thể nào được xem xét một cách rõ ràng để phát
hiện. Tuy nhiên, thử nghiệm miền có một cách tiếp cận mới để phát
hiện lỗi. Trong cách tiếp cận này, một loại lỗi được gọi là lỗi miền
được xác định và sau đó dữ liệu kiểm tra được chọn để bắt các lỗi đó.
Nó được thảo luận chi tiết trong Chương 6.
Kiểm thử chương trình chức năng: Trong kiểm thử chương trình
chức năng, người ta thực hiện các bước sau: (i) xác định các miền
đầu vào và đầu ra của một chương trình; (ii) đối với một miền đầu
vào nhất định, hãy chọn một số giá trị đặc biệt và tính toán kết quả
mong đợi; (iii) đối với một miền đầu ra nhất định, hãy chọn một số
giá trị đặc biệt và tính toán các giá trị đầu vào sẽ khiến đơn vị tạo ra
các giá trị đầu ra đó; và (iv) xem xét các kết hợp khác nhau của các
giá trị đầu vào đã chọn ở trên. Chương 9 thảo luận về kiểm thử chức
năng.
3.5 KIỂM TRA MUTATION
Thử nghiệm đột biến có một lịch sử phong phú và lâu đời. Nó có thể
được bắt nguồn từ cuối những năm 1970 [8–10]. Thử nghiệm đột
biến ban đầu được đề xuất bởi Dick Lipton, và bài báo của DeMillo,
Lipton và Sayward [9] thường được trích dẫn như một tài liệu tham
khảo chính. Kiểm thử đột biến là một kỹ thuật tập trung vào việc đo
lường tính đầy đủ của dữ liệu kiểm thử (hoặc các trường hợp kiểm
thử). Mục đích ban đầu đằng sau thử nghiệm đột biến là để lộ và xác
định vị trí điểm yếu trong các trường hợp thử nghiệm. Do đó, thử
nghiệm đột biến là một cách để đo lường chất lượng của các trường
hợp thử nghiệm, và thử nghiệm thực tế của các đơn vị chương trình
là một lợi ích bổ sung. Kiểm thử đột biến không phải là một chiến
lược kiểm tra như kiểm tra luồng kiểm soát hoặc kiểm tra luồng dữ
liệu. Nó nên được sử dụng để bổ sung cho các kỹ thuật kiểm thử đơn
vị truyền thống.
Đột biến của chương trình là một sửa đổi của chương trình được tạo
ra bằng cách đưa vào một thay đổi cú pháp hợp pháp, nhỏ, duy nhất
trong mã. Một chương trình đã được sửa đổi để thu được được gọi là
một chương trình đột biến. Thuật ngữ đột biến đã được vay mượn từ
sinh học. Một số đột biến này tương đương với chương trình gốc,
trong khi một số khác bị lỗi. Một dị nhân được cho là bị giết khi việc
thực hiện một trường hợp thử nghiệm khiến nó không thành công và
người đột biến được coi là đã chết.
Một số phần tử đột biến tương đương với chương trình đã cho, tức là
những phần tử đột biến đó luôn tạo ra kết quả đầu ra giống như
chương trình gốc. Trong thế giới thực, các chương trình lớn thường
bị lỗi và các trường hợp kiểm thử cũng chứa lỗi. Kết quả của việc
thực thi một đột biến có thể khác với kết quả mong đợi, nhưng một
bộ thử nghiệm không phát hiện ra lỗi vì nó không có trường hợp thử
nghiệm phù hợp. Trong trường hợp này, đột biến được gọi là có thể
giết được hoặc cứng đầu, tức là tập hợp các trường hợp thử nghiệm
hiện có không đủ để giết nó. Điểm đột biến cho một tập hợp các
trường hợp thử nghiệm là tỷ lệ phần trăm đột biến không tương
đương bị giết bởi bộ thử nghiệm. Bộ thử nghiệm được cho là đủ đột
biến nếu điểm đột biến của nó là 100%. Phân tích đột biến là một quá
trình gồm hai bước:
Tính đầy đủ của một bộ thử nghiệm hiện có được xác định để phân
biệt chương trình đã cho với các phần tử đột biến của nó. Một bộ thử
nghiệm nhất định có thể không đủ để phân biệt tất cả các chất đột
biến không tương đương. Như đã giải thích ở trên, những dị nhân
không tương đồng nào không thể xác định được bằng bộ thử nghiệm
đã cho được gọi là dị nhân cứng đầu.
Các trường hợp thử nghiệm mới được thêm vào bộ thử nghiệm hiện
có để tiêu diệt những kẻ đột biến cứng đầu. Quá trình nâng cao bộ
117
thử nghiệm lặp đi lặp lại cho đến khi bộ thử nghiệm đạt được mức
điểm đột biến mong muốn.
Chúng ta hãy xem xét chương trình P sau đây tìm thứ hạng tương
ứng với lần đầu tiên giá trị lớn nhất xuất hiện trong mảng. Để đơn
giản, chúng ta giả sử rằng chương trình P đọc ba đối số đầu vào và in
ra thông báo tương ứng:
main(argc,argv)
int argc, r, i;
char *argv[];
{ r = 1;
for i = 2 to 3 do
if (atoi(argv[i]) > atoi(argv[r])) r = i;
printf("Value of the rank is %d \n", r);
exit(0); }
Now let us assume that we have the following test suite that tests
the program P:
Test case 1:
Input: 1 2 3
Output: Value of the rank is 3 Test case 2:
Input: 1 2 1
Output: Values of the rank is 2 Test case 3:
Input: 3 1 2
Output: Value of the rank is 1
Now, let us mutate the program P. We can start with the following
changes:
Mutant 1: Change line 5 to
for i = 1 to 3 do
Mutant 2: Change line 6 to
if (i > atoi(argv[r])) r = i;
Mutant 3: Change line 6 to if (atoi(argv[i]) >= atoi(argv[r])) r = i;
Mutant 4: Change line 6 to if (atoi(argv[r]) > atoi(argv[r])) r = i;
If we run the modified programs against the test suite, we will get
the following results:
Mutants 1 and 3: The programs will completely pass the test suite.
In other words, mutants 1 and 3 are not killed.
Mutant 2: The program will fail test case 2.
Mutant 4: The program will fail test case 1 and test case 2.
Nếu tính điểm đột biến, chúng ta thấy rằng chúng ta đã tạo ra 4 dị
nhân, và 2 trong số đó đã bị giết. Điều này cho chúng ta biết rằng
điểm đột biến là 50%, giả sử rằng đột biến 1 và 3 là không tương
đồng.
119
Điểm số được cho là thấp. Nó thấp bởi vì chúng tôi giả định rằng đột
biến 1 và 3 không tương đương với chương trình ban đầu. Chúng tôi
phải chứng minh rằng một trong hai người đột biến
1 và 3 là những dị nhân tương đương hoặc có thể giết được. Nếu
chúng có thể giết được, chúng tôi cần thêm các trường hợp thử
nghiệm mới để tiêu diệt hai dị nhân này. Đầu tiên, chúng ta hãy phân
tích đột biến 1 để tìm ra một bài kiểm tra "kẻ giết người". Sự khác
biệt giữa P và đột biến 1 là điểm xuất phát. Đột biến 1 bắt đầu với i =
1, trong khi P bắt đầu với i = 2. Không có tác động đến kết quả r. Do
đó, chúng tôi kết luận rằng đột biến 1 là một đột biến tương đương.
Thứ hai, chúng tôi thêm một trường hợp thử nghiệm thứ tư như sau:
Trường hợp thử nghiệm 4:
Đầu vào: 2 2 1
Sau đó chương trình P sẽ tạo ra kết quả "Giá trị của thứ hạng là 1" và
đột biến 3 sẽ tạo ra đầu ra "Giá trị của thứ hạng là 2." Do đó, dữ liệu
thử nghiệm này giết chết đột biến 3, cho chúng ta điểm đột biến là
100%.
Để sử dụng kỹ thuật kiểm tra đột biến nhằm xây dựng một bộ thử
nghiệm mạnh mẽ, kỹ sư kiểm tra cần thực hiện theo các bước được
nêu dưới đây:
Bước Bắt đầu với một chương trình P và một tập hợp các trường
1: hợp kiểm tra T đã biết là đúng.
Bước Chạy từng trường hợp thử nghiệm trong T với chương trình
2: P. Nếu một trường hợp thử nghiệm không thành công, nghĩa
là kết quả đầu ra không chính xác, chương trình P phải được
sửa đổi và thử nghiệm lại. Nếu không có lỗi, sau đó tiếp tục
với bước 3.
Bước Tạo một tập hợp các đột biến { P i } , mỗi đột biến khác với
3: P bằng cách sửa đổi P đơn giản, đúng về mặt cú pháp.
Bước Thực hiện từng trường hợp thử nghiệm trong T với mỗi P i đột
4: biến . Nếu đầu ra của P i đột biến khác với đầu ra của chương trình
gốc P, thì P i đột biến được coi là không chính xác và được cho
là bị giết bởi trường hợp thử nghiệm. Nếu P i tạo ra kết quả
chính xác như chương trình ban đầu P cho các bài kiểm tra
trong T, thì một trong những điều sau đây là đúng:
P và P i là tương đương. Có nghĩa là, các hành vi của chúng
không thể được phân biệt bởi bất kỳ bộ test case nào. Lưu ý
rằng vấn đề chung quyết định liệu một đột biến có tương
đương với chương trình gốc hay không là không thể quyết
định.
P i là có thể giết được. Tức là, các trường hợp thử nghiệm
không đủ để tiêu diệt P i đột biến . Trong trường hợp này, các
trường hợp thử nghiệm mới phải được tạo.
Bước Tính điểm đột biến cho tập hợp các trường hợp thử nghiệm
5: T. Điểm đột biến là tỷ lệ phần trăm các thể đột biến không
tương đương bị giết bởi dữ liệu thử nghiệm, nghĩa là, Điểm
đột biến = 100 × D / (N - E), trong đó D là các thể đột biến
đã chết, N là tổng số thể đột biến và E là số thể đột biến
tương đương.
Bước Nếu mức đầy đủ của đột biến ước tính của T trong bước 5
6: không đủ cao, thì hãy thiết kế một trường hợp thử nghiệm
mới để phân biệt P i với P, thêm trường hợp thử nghiệm mới
vào T và chuyển sang bước 2. Nếu mức độ đầy đủ được tính
toán của T nhiều hơn hơn một ngưỡng thích hợp, sau đó
chấp nhận T là một thước đo tốt về tính đúng đắn của P đối
với tập các chương trình đột biến P i và ngừng thiết kế các
trường hợp thử nghiệm mới.
Thử nghiệm đột biến đưa ra hai giả định chính:
Giả thuyết về lập trình viên có năng lực: Giả định này nói rằng các
lập trình viên nói chung là có năng lực và họ không tạo ra các
chương trình “ngẫu nhiên”. Do đó, chúng ta có thể giả định rằng đối
với một vấn đề nhất định, một lập trình viên sẽ tạo ra một chương
trình đúng trừ những lỗi đơn giản. Nói cách khác, những người đột
biến được xem xét là những người có độ lệch nhỏ so với chương
trình ban đầu. Trên thực tế, những đột biến như vậy thu được bằng
cách áp dụng một cách có hệ thống và máy móc một tập hợp các
phép biến đổi, được gọi là toán tử đột biến, vào chương trình đang
được thử nghiệm. Các toán tử đột biến này được mong đợi để mô
hình hóa các lỗi lập trình do lập trình viên thực hiện. Trong thực tế,
điều này có thể chỉ đúng một phần.
Hiệu ứng khớp nối: Giả định này lần đầu tiên được đưa ra vào năm
1978 bởi DeMillo et al. [9]. Giả thiết có thể được khôi phục lại vì các
lỗi phức tạp được kết hợp với các lỗi đơn giản theo cách mà một bộ
121
thử nghiệm phát hiện tất cả các lỗi đơn giản trong một chương trình
sẽ phát hiện hầu hết các lỗi phức tạp. Giả định này đã được Offutt
[11] ủng hộ về mặt kinh nghiệm và được chứng minh về mặt lý
thuyết bởi Wah [12]. Tiền đề cơ bản của thử nghiệm đột biến do
Geist et al. [13] là: Nếu phần mềm có lỗi, thường sẽ có một tập hợp
các đột biến chỉ có thể bị giết bởi một trường hợp thử nghiệm cũng
phát hiện ra lỗi đó.
Kiểm tra đột biến giúp người kiểm tra đưa ra, bằng giả thuyết, các
loại lỗi khác nhau trong mã và phát triển các trường hợp kiểm tra để
tiết lộ chúng. Ngoài ra, kiểm tra toàn diện có thể được thực hiện bằng
cách lựa chọn thích hợp các hoạt động đột biến. Tuy nhiên, một số
lượng tương đối lớn các chương trình đột biến cần được thử nghiệm
dựa trên nhiều trường hợp thử nghiệm trước khi có thể phân biệt
được các chương trình đột biến này với chương trình gốc. Chạy các
trường hợp thử nghiệm, phân tích kết quả, xác định các dị nhân
tương đương [14], và phát triển các trường hợp thử nghiệm bổ sung
để tiêu diệt các dị nhân cứng đầu đều tốn thời gian. Các công cụ kiểm
tra tự động mạnh mẽ như Mothra [15] có thể được sử dụng để đẩy
nhanh quá trình kiểm tra đột biến. Gần đây, với sự sẵn có của sức
mạnh tính toán khổng lồ, đã có sự trỗi dậy của các quy trình kiểm tra
đột biến trong cộng đồng công nghiệp để sử dụng như một phương
pháp hộp trắng cho kiểm thử đơn vị [16, 17]. Các nhà nghiên cứu đã
chỉ ra rằng với sự lựa chọn thích hợp của các chương trình đột biến,
kiểm tra đột biến cũng mạnh mẽ như kiểm tra đường dẫn, kiểm tra
miền [18] và kiểm tra luồng dữ liệu [19].
3.6 NỢ
Lập trình viên, sau khi chương trình bị lỗi, xác định lỗi tương ứng và
sửa chữa nó. Quá trình xác định nguyên nhân của lỗi được gọi là gỡ
lỗi. Gỡ lỗi xảy ra do một thử nghiệm tiết lộ lỗi. Myers đã đề xuất ba
cách tiếp cận để gỡ lỗi trong cuốn sách Nghệ thuật kiểm thử phần
mềm [20] của ông:
Brute Force: Cách tiếp cận brute-force để gỡ lỗi được nhiều lập
trình viên ưa thích. Ở đây, triết lý “để máy tính tìm ra lỗi” được sử
dụng.
3.6 NỢ
Các câu lệnh in nằm rải rác khắp mã nguồn. Các câu lệnh in này
cung cấp một dấu vết thô sơ về cách mã nguồn đã thực thi. Sự sẵn có
của một công cụ gỡ lỗi tốt làm cho các câu lệnh in này trở nên thừa.
Trình gỡ lỗi động cho phép kỹ sư phần mềm điều hướng bằng cách
lướt qua mã, quan sát đường dẫn nào đã thực thi và quan sát cách giá
trị của các biến thay đổi trong quá trình thực thi được kiểm soát. Một
công cụ tốt cho phép lập trình viên gán giá trị cho một số biến và
điều hướng từng bước thông qua mã. Mã công cụ có thể được tích
hợp vào mã nguồn để phát hiện các vấn đề và ghi lại các giá trị trung
gian của các biến để chẩn đoán vấn đề. Người ta có thể sử dụng kết
xuất bộ nhớ sau khi xảy ra lỗi để hiểu trạng thái cuối cùng của mã
được gỡ lỗi. Nhật ký và kết xuất bộ nhớ được xem xét để hiểu điều gì
đã xảy ra và lỗi xảy ra như thế nào.
Loại bỏ nguyên nhân: Cách tiếp cận loại bỏ nguyên nhân có thể
được mô tả tốt nhất là một quá trình liên quan đến quy nạp và suy
diễn [21]. Trong phần cảm ứng, đầu tiên, tất cả dữ liệu thích hợp liên
quan đến sự cố được thu thập, chẳng hạn như những gì đã xảy ra và
các triệu chứng là gì. Tiếp theo, dữ liệu thu thập được sắp xếp theo
hành vi và triệu chứng, và mối quan hệ của chúng được nghiên cứu
để tìm ra một mô hình để cô lập các nguyên nhân. Giả thuyết nguyên
nhân được đưa ra và dữ liệu trên được sử dụng để chứng minh hoặc
bác bỏ giả thuyết. Trong phần suy luận, danh sách tất cả các nguyên
nhân có thể xảy ra được phát triển theo thứ tự khả năng xảy ra của
chúng và các thử nghiệm được tiến hành để loại bỏ hoặc chứng minh
từng nguyên nhân theo thứ tự giảm dần khả năng xảy ra của chúng.
Nếu các thử nghiệm ban đầu chỉ ra rằng một giả thuyết cụ thể cho
thấy có hứa hẹn, thì dữ liệu thử nghiệm sẽ được tinh chỉnh để cố
gắng tách biệt vấn đề khi cần thiết.
Backtracking: Trong cách tiếp cận này, lập trình viên bắt đầu tại
một điểm trong đoạn mã mà ở đó lỗi được quan sát thấy và truy tìm
lại quá trình thực thi đến điểm nó xảy ra. Kỹ thuật này được các lập
trình viên thường xuyên sử dụng và điều này rất hữu ích trong các
chương trình nhỏ. Tuy nhiên, xác suất truy tìm lại lỗi giảm khi kích
thước chương trình tăng lên, vì số lượng đường dẫn ngược tiềm năng
có thể trở nên quá lớn.
Thông thường, các kỹ sư phần mềm nhận thấy các vấn đề khác chưa
được phát hiện trước đó trong khi gỡ lỗi và áp dụng bản sửa lỗi.
123
Những lỗi mới được phát hiện này không nên được sửa cùng với việc
sửa chữa trong tiêu điểm. Điều này là do kỹ sư phần mềm có thể
không hiểu đầy đủ về phần mã gây ra lỗi mới. Cách tốt nhất để đối
phó với tình huống như vậy là nộp CR. CR mới cho lập trình viên cơ
hội thảo luận vấn đề này với các thành viên khác trong nhóm và kiến
trúc sư phần mềm, đồng thời nhận được sự chấp thuận của họ đối với
đề xuất của lập trình viên. Sau khi CR được chấp thuận, kỹ sư phần
mềm phải gửi lỗi vào cơ sở dữ liệu theo dõi lỗi và có thể tiến hành
sửa chữa. Quá trình này cồng kềnh và nó làm gián đoạn quá trình gỡ
lỗi, nhưng nó hữu ích cho các dự án rất quan trọng. Tuy nhiên, các
lập trình viên thường không tuân theo điều này vì thiếu một thủ tục
để thực thi nó.
Gỡ lỗi Heuristic Mục tiêu của việc gỡ lỗi là xác định chính xác
nguyên nhân gây ra lỗi. Sau khi xác định được nguyên nhân, các biện
pháp khắc phục sẽ được thực hiện để khắc phục lỗi. Gỡ lỗi được tiến
hành bởi các lập trình viên, tốt nhất là bởi những người đã viết mã,
bởi vì lập trình viên là người tốt nhất hiểu rõ về mã nguồn để phân
tích mã một cách hiệu quả và hiệu quả. Gỡ lỗi thường là một quá
trình tốn thời gian và dễ xảy ra lỗi, thường được thực hiện dưới áp
lực. Gỡ lỗi liên quan đến sự kết hợp của đánh giá có hệ thống, trực
giác và đôi khi là một chút may mắn. Đưa ra một triệu chứng của
một vấn đề, mục đích là để cô lập và xác định nguyên nhân cụ thể
của nó. Có thể tuân theo các kinh nghiệm sau để tách và sửa nó:
Bước Tái tạo (các) triệu chứng.
1: Đọc hướng dẫn xử lý sự cố của sản phẩm. Hướng dẫn này
có thể bao gồm các điều kiện và nhật ký, được tạo bằng mã
thông thường hoặc mã chẩn đoán được viết riêng cho mục
đích khắc phục sự cố có thể được bật. • Cố gắng tái tạo các
triệu chứng khi bật mã chẩn đoán.
Thu thập tất cả thông tin và tiến hành phân tích nhân quả
Mục tiêu của phân tích nhân quả là xác định nguyên nhân
gốc rễ của vấn đề và bắt đầu các hành động để nguồn gốc
của các khiếm khuyết được loại bỏ.
Bước Hình thành một số giả thuyết có khả năng xảy ra cho nguyên
2: nhân của vấn đề dựa trên phân tích nhân quả.
Bước Xây dựng một kịch bản kiểm tra cho mỗi giả thuyết được
3: chứng minh hoặc bác bỏ. Điều này được thực hiện bằng
cách thiết kế các trường hợp thử nghiệm để cung cấp các kết
quả rõ ràng liên quan đến một giả thuyết. Các trường hợp
kiểm thử có thể là tĩnh (xem lại mã và tài liệu) và / hoặc
động về bản chất. Tốt hơn là các trường hợp thử nghiệm
không phá hủy, có chi phí thấp và cần nhu cầu phần cứng bổ
sung tối thiểu. Một trường hợp thử nghiệm được cho là phá
hủy nếu nó phá hủy thiết lập phần cứng. Ví dụ, cắt cáp trong
quá trình thử nghiệm được gọi là thử nghiệm phá hủy.
Bước Ưu tiên thực hiện các ca kiểm thử. Các trường hợp kiểm thử
4: tương ứng với các giả thuyết có khả năng xảy ra cao được
thực thi trước. Ngoài ra, không thể bỏ qua yếu tố chi phí. Do
đó, người ta mong muốn thực hiện các trường hợp thử
nghiệm chi phí thấp đầu tiên sau đó là các trường hợp đắt
tiền hơn. Người lập trình cần xem xét cả hai yếu tố.
Bước Thực hiện các trường hợp kiểm tra để tìm ra nguyên nhân
5: của một triệu chứng. Sau khi thực hiện một trường hợp thử
nghiệm, hãy kiểm tra kết quả để tìm bằng chứng mới. Nếu
kết quả thử nghiệm cho thấy một giả thuyết cụ thể có triển
vọng, thì dữ liệu thử nghiệm sẽ được tinh chỉnh để cố gắng
tách biệt khiếm khuyết. Nếu cần, hãy quay lại các bước
trước đó hoặc loại bỏ một giả thuyết cụ thể.
Bước Khắc phục sự cố.
6:
Khắc phục sự cố có thể là một nhiệm vụ đơn giản, chẳng hạn như
thêm một dòng mã hoặc thay đổi một biến trong một dòng mã hoặc
một nhiệm vụ phức tạp hơn như sửa đổi một số dòng mã hoặc thiết
kế một đơn vị mới. Trong trường hợp phức tạp, sửa chữa lỗi là một
hoạt động nghiêm ngặt.
Nếu quá trình xem xét mã đã được hoàn thành cho mô-đun đã nhận
được bản sửa lỗi, thì việc xem xét mã phải được thực hiện lại một lần
nữa để tránh
3.7 ĐƠN VỊ KIỂM TRA TRONG LẬP TRÌNH MỞ RỘNG
bất kỳ tác dụng phụ nào (thiệt hại tài sản thế chấp) do những thay đổi
có hiệu lực trong mô-đun.
Sau khi xem xét mã có thể, hãy áp dụng bản sửa lỗi.
125
Kiểm tra lại thiết bị để xác nhận rằng nguyên nhân thực sự của lỗi đã
được tìm thấy. Thiết bị được gỡ lỗi và sửa đúng cách nếu các thử
nghiệm cho thấy lỗi quan sát được không xảy ra nữa.
Nếu không có trường hợp kiểm thử đơn vị động nào tiết lộ sự cố, thì
hãy thêm một trường hợp kiểm thử mới vào kiểm thử đơn vị động để
phát hiện các lần tái xuất hiện có thể xảy ra hoặc các vấn đề tương tự
khác.
Đối với đơn vị được xem xét, xác định tất cả các trường hợp thử
nghiệm đã vượt qua. Bây giờ, hãy thực hiện kiểm thử hồi quy trên
đơn vị với các trường hợp kiểm thử đó để đảm bảo rằng các lỗi mới
không được đưa vào. Đó là lý do tại sao điều quan trọng là phải lưu
trữ tất cả các trường hợp thử nghiệm đã được thiết kế cho một đơn vị.
Do đó, ngay cả các trường hợp kiểm thử cấp đơn vị cũng phải được
quản lý một cách có hệ thống để giảm chi phí phát triển phần mềm.
Bước 7: Ghi lại những thay đổi đã được thực hiện. Khi một lỗi đã
được khắc phục, những thay đổi sau đây là bắt buộc phải được áp
dụng:
Ghi lại các thay đổi trong chính mã nguồn để phản ánh sự thay đổi.
Cập nhật tài liệu hệ thống tổng thể.
Các thay đổi đối với các trường hợp thử nghiệm đơn vị động.
Gửi lỗi vào cơ sở dữ liệu theo dõi lỗi nếu vấn đề được tìm thấy sau
khi mã được đăng ký vào hệ thống kiểm soát phiên bản.
3.7 ĐƠN VỊ KIỂM TRA TRONG LẬP TRÌNH MỞ RỘNG
Cách tiếp cận TDD để phát triển mã được sử dụng trong phương
pháp của XP [22, 23]. Khía cạnh quan trọng của phương pháp TDD
là lập trình viên viết các bài kiểm tra cấp thấp trước khi viết mã sản
xuất. Đây được gọi là thử nghiệm đầu tiên [24] trong phát triển phần
mềm. Viết các đơn vị theo hướng kiểm tra là một khái niệm quan
trọng trong phương pháp XP. Trong XP, một số bài kiểm tra đơn vị
được mã hóa trước, sau đó một hệ thống đơn giản, từng phần được
triển khai để vượt qua các bài kiểm tra. Sau đó, một bài kiểm tra đơn
vị mới nữa được tạo và mã bổ sung được viết để vượt qua bài kiểm
tra mới, nhưng không nhiều hơn, cho đến khi tạo một bài kiểm tra
đơn vị mới. Quá trình được tiếp tục cho đến khi không còn gì để
kiểm tra. Quá trình được minh họa trong Hình 3.3 và được trình bày
dưới đây:
Bước Chọn một yêu cầu, đó là một câu chuyện.

1:
Bước Viết một trường hợp thử nghiệm sẽ xác minh một phần nhỏ
2: của câu chuyện và gán kết quả không thành công cho phần
đó.
Bước Viết mã triển khai một phần cụ thể của câu chuyện để vượt
3: qua bài kiểm tra.
Bước Thực hiện tất cả các bài kiểm tra.
4:
Story
Understand
Add a single test
Add code for the test
Execute all tests
Fail Pass
Rework on code Results
No
Yes Story
complete
Next story
Hình 3.3 Quy trình đầu tiên thử nghiệm trong XP. (Từ tài liệu
tham khảo 24. © 2005 IEEE.)
Bước 5: Làm lại mã và kiểm tra mã cho đến khi tất cả các bài
kiểm tra vượt qua.
Bước 6: Lặp lại các bước 2–5 cho đến khi câu chuyện được
triển khai đầy đủ.
Chu trình đơn giản trong Hình 3.3 cho thấy rằng, ở đầu mỗi chu kỳ,
mục đích là tất cả các thử nghiệm đều vượt qua ngoại trừ trường hợp
thử nghiệm mới được thêm vào. Trường hợp thử nghiệm mới được
giới thiệu để thúc đẩy sự phát triển mã mới. Vào cuối chu kỳ, lập
trình viên thực hiện tất cả các bài kiểm tra đơn vị, đảm bảo rằng mỗi
bài kiểm tra đều vượt qua và do đó, nhiệm vụ theo kế hoạch của mã
vẫn hoạt động. Một nhà phát triển TDD phải tuân theo ba luật do
Robert C. Martin đề xuất [25]:
127
Người ta không thể viết mã sản xuất trừ khi đơn vị thử nghiệm thất
bại đầu tiên được viết.
Người ta không được viết nhiều bài kiểm tra đơn vị hơn mức đủ để
không đạt.
Người ta không được viết nhiều mã sản xuất hơn mức đủ để làm cho
bài kiểm tra đơn vị không đạt được thông qua.
Ba luật này đảm bảo rằng người ta phải viết một phần của bài kiểm
tra đơn vị bị lỗi và sau đó viết mã sản xuất vừa đủ để bài kiểm tra
đơn vị đó vượt qua. Mục tiêu của ba luật này không phải là tuân theo
chúng một cách nghiêm ngặt — nó là giảm khoảng thời gian giữa
việc viết các bài kiểm tra đơn vị và mã sản xuất.
Việc tạo các bài kiểm tra đơn vị giúp nhà phát triển tập trung vào
những việc cần phải thực hiện. Các yêu cầu, tức là câu chuyện của
người dùng, được gắn kết chắc chắn bằng các bài kiểm tra đơn vị.
Các bài kiểm tra đơn vị được phát hành vào kho mã cùng với mã mà
chúng kiểm tra. Mã không có thử nghiệm đơn vị có thể không được
phát hành. Nếu một bài kiểm tra đơn vị được phát hiện bị thiếu, nó
phải được tạo ra ngay lập tức. Việc tạo các bài kiểm tra đơn vị một
cách độc lập trước khi mã hóa sẽ thiết lập các kiểm tra và cân bằng
và cải thiện cơ hội đưa hệ thống vào đúng ngay lần đầu tiên.
3.8 THÁNG 6: KHUNG ĐỂ KIỂM TRA ĐƠN VỊ
Các bài kiểm tra đơn vị cung cấp một mạng lưới an toàn gồm các bài
kiểm tra hồi quy và kiểm tra xác nhận để các lập trình viên XP có thể
cấu trúc lại và tích hợp một cách hiệu quả.
Trong XP, mã đang được phát triển bởi hai lập trình viên làm việc
cùng nhau. Khái niệm này được gọi là lập trình cặp. Hai lập trình
viên ngồi cạnh nhau trước màn hình. Một người phát triển mã một
cách chiến thuật và người kia kiểm tra nó một cách có phương pháp
bằng cách ghi nhớ câu chuyện mà họ đang triển khai. Nó tương tự
như chiến lược kiểm tra hai người do Bisant và Lyle đề xuất [26].
Việc kiểm tra mã được thực hiện bởi một cặp tác giả - giám khảo
theo các bước rời rạc, kiểm tra một phần nhỏ của việc triển khai câu
chuyện một cách riêng biệt, đây là chìa khóa cho sự thành công của
quá trình xem xét mã.
JUnit là một khung kiểm tra đơn vị cho ngôn ngữ lập trình Java được
thiết kế bởi Kent Beck và Erich Gamma. Kinh nghiệm thu được với
JUnit đã thúc đẩy sự phát triển của phương pháp luận TDD [22]. Ý
tưởng trong khuôn khổ JUnit đã được chuyển sang các ngôn ngữ
khác, bao gồm C # (NUnit), Python (PyUnit), Fortran (fUnit) và C +
+ (CPPUnit). Họ các khung công tác kiểm thử đơn vị này được gọi
chung là xUnit. Phần này sẽ giới thiệu các khái niệm cơ bản của
JUnit cho người đọc.
Giả sử rằng chúng ta muốn kiểm tra các phương thức riêng lẻ của
một lớp được gọi là PlanetClass. Đặt Move () là một phương thức
trong PlanetClass sao cho Move () chỉ nhận một tham số đầu vào
kiểu số nguyên và trả về giá trị kiểu số nguyên. Người ta có thể làm
theo các bước sau, được minh họa bằng cách sử dụng mã giả trong
Hình 3.4, để kiểm tra Move (): • Tạo một thể hiện đối tượng của
PlanetClass. Hãy để chúng tôi gọi ví dụ là sao Hỏa. Bây giờ chúng ta
quan tâm đến việc thử nghiệm phương thức Move () bằng cách gọi
nó trên đối tượng Mars.
Chọn một giá trị cho tất cả các tham số đầu vào của Move () - hàm
này chỉ có một tham số đầu vào. Hãy để chúng tôi biểu diễn giá trị
đầu vào của Move () theo x. • Biết giá trị mong đợi được trả về bởi
Move (). Đặt giá trị trả về mong đợi là y.
:
Planet Mars = Hành tinh mới (); // Khởi tạo lớp Planet để tạo // một
đối tượng Mars.
x = ...; // Chọn một giá trị cho x. y = ...; // Giá trị mong đợi được
trả về bởi lệnh gọi Move (x). z = Mars.Move (x); // Gọi phương
thức Mars () trên đối tượng Mars.
if (z == y) print ("Đã vượt qua bài kiểm tra"); else print ("Kiểm tra
không thành công."); :
Hình 3.4 Mã giả mẫu để thực hiện kiểm thử đơn vị.
Gọi phương thức Move () trên đối tượng Mars với giá trị đầu vào là
x. Gọi z là giá trị được trả về bởi Move ().
Bây giờ so sánh y với z. Nếu hai giá trị giống hệt nhau, thì phương
thức Move () trong đối tượng Mars sẽ vượt qua bài kiểm tra. Nếu
không, bài kiểm tra được cho là đã thất bại.
Tóm lại, năm bước của kiểm thử đơn vị như sau:
Tạo một đối tượng và chọn một phương thức để thực thi.
129
Chọn giá trị cho các tham số đầu vào của phương thức.
Tính toán các giá trị mong đợi sẽ được phương thức trả về.
Thực thi phương thức đã chọn trên đối tượng đã tạo bằng cách sử
dụng các giá trị đầu vào đã chọn.
Xác minh kết quả của việc thực thi phương thức.
Thực hiện kiểm thử đơn vị dẫn đến việc lập trình viên tiêu tốn một số
tài nguyên, đặc biệt là thời gian. Do đó, rất hữu ích khi sử dụng một
khung lập trình chung để viết mã các trường hợp thử nghiệm riêng lẻ,
tổ chức một tập hợp các trường hợp thử nghiệm như một bộ thử
nghiệm, khởi tạo môi trường thử nghiệm, thực thi bộ thử nghiệm,
dọn dẹp môi trường thử nghiệm và ghi lại kết quả thực thi. của các
trường hợp thử nghiệm riêng lẻ. Trong ví dụ minh họa trong Hình
3.4, việc tạo đối tượng Mars là một phần của quá trình khởi tạo. Hai
câu lệnh print () là ví dụ về việc ghi lại kết quả của việc thực hiện
kiểm tra. Ngoài ra, người ta có thể ghi kết quả của việc thực thi thử
nghiệm vào một tệp.
Khung JUnit đã được phát triển để làm cho việc viết thử trở nên đơn
giản. Khung công tác cung cấp một lớp cơ bản, được gọi là TestCase,
để viết các trường hợp kiểm thử. Lập trình viên cần mở rộng lớp
TestCase để viết một tập hợp các trường hợp thử nghiệm riêng lẻ. Có
thể lưu ý rằng để viết, ví dụ, 10 trường hợp kiểm thử, người ta không
cần viết 10 lớp con của lớp TestCase. Đúng hơn, một lớp con, chẳng
hạn như MyTestCase, của TestCase, có thể chứa 10 phương thức —
một phương thức cho mỗi trường hợp thử nghiệm.
Lập trình viên cần đưa ra các khẳng định về trạng thái của các đối
tượng trong khi mở rộng lớp TestCase để viết các trường hợp kiểm
thử. Ví dụ, trong mỗi trường hợp thử nghiệm, cần phải so sánh kết
quả thực tế của một phép tính với kết quả dự kiến. Mặc dù câu lệnh if
() có thể được sử dụng để so sánh sự bằng nhau của hai giá trị hoặc
hai đối tượng, nhưng việc viết một câu lệnh khẳng định để đạt được
điều tương tự được xem là tốt hơn. Lớp TestCase mở rộng một lớp
tiện ích được gọi là Assert trong khuôn khổ JUnit. Về cơ bản, lớp
Assert cung cấp các phương thức, như được giải thích ở phần sau, để
đưa ra khẳng định về trạng thái của các đối tượng được tạo và thao
tác trong khi kiểm tra.
khẳng địnhTrue (điều kiện Boolean): Khẳng định này được chấp
nhận nếu điều kiện là đúng; nếu không, nó không thành công.
khẳng địnhEquals (Đối tượng mong đợi, Đối tượng thực tế): Xác
nhận này được chuyển nếu đối tượng mong đợi và thực tế là bằng
nhau theo phương thức equals (); nếu không, khẳng định không thành
công.
khẳng định _ nếu không, khẳng định
không thành công. Đối với mỗi kiểu nguyên thủy int, float, double,
char, byte, long, short và boolean, xác nhận có phiên bản quá tải.
khẳng định nếu không, khẳng định không thành công. Xác nhận có
một phiên bản quá tải cho các đầu vào float.
khẳng địnhSame (Đối tượng mong đợi, Đối tượng thực tế): Xác nhận
này được chuyển nếu các giá trị kỳ vọng và thực tế tham chiếu đến
cùng một đối tượng trong bộ nhớ; nếu không, khẳng định không
thành công.
khẳng địnhNull (Đối tượng thử nghiệm đối tượng): Xác nhận này
được chuyển nếu đối tượng thử nghiệm là null; nếu không thì khẳng
định không thành công. khẳng địnhFalse (điều kiện Boolean): Đây là
điều kiện ngược lại logic với khẳng địnhTrue ().
Người đọc có thể lưu ý rằng danh sách các khẳng định trên không
đầy đủ. Trên thực tế, người ta có thể xây dựng các xác nhận khác
trong khi mở rộng lớp TestCase. Khi một xác nhận không thành
công, một lập trình viên có thể muốn biết ngay bản chất của lỗi đó.
Điều này có thể được thực hiện bằng cách hiển thị một thông báo khi
xác nhận không thành công. Mỗi phương thức xác nhận được liệt kê
ở trên chấp nhận một tham số đầu tiên tùy chọn kiểu String — nếu
xác nhận không thành công, thì giá trị Chuỗi sẽ được hiển thị. Điều
này tạo điều kiện cho lập trình viên hiển thị thông báo mong muốn
khi xác nhận không thành công. Ngoài ra, khi bị lỗi, phương thức
khẳng định Equals () sẽ hiển thị một thông báo tùy chỉnh hiển thị giá
trị mong đợi và giá trị thực tế. Ví dụ, một phương thức khẳng
địnhEquals () có thể hiển thị như sau:
junit.framework.AssertionFailedError: dự kiến: <2006> nhưng
là: <2060>.
Tại thời điểm này, điều thú vị là chỉ có các thử nghiệm thất bại mới
được báo cáo. Các bài kiểm tra không thành công có thể được báo
cáo bằng nhiều cách khác nhau, chẳng hạn như hiển thị thông báo,
hiển thị số nhận dạng cho trường hợp thử nghiệm và đếm tổng số
131
trường hợp thử nghiệm không thành công. Về cơ bản, một phương
thức xác nhận ném một ngoại lệ, được gọi là AssertionFailedError,
khi xác nhận không thành công và JUnit bắt lấy ngoại lệ. Đoạn mã
hiển thị trong Hình 3.5 minh họa cách hoạt động của khẳng định
khẳng định (): Khi khung công tác JUnit bắt được một ngoại lệ, nó sẽ
ghi lại thực tế là xác nhận không thành công và chuyển sang trường
hợp thử nghiệm tiếp theo. Sau khi thực hiện tất cả các trường hợp thử
nghiệm, JUnit tạo ra một danh sách tất cả các thử nghiệm đã thất bại.
Trong Hình 3.6, chúng tôi trình bày một ví dụ về bộ thử nghiệm chứa
hai trường hợp thử nghiệm.
Để thực thi hai trường hợp thử nghiệm, người ta cần tạo một thể hiện
đối tượng của
static public void precisionTrue (Boolean condition) {if (! condition)
ném mới AssertionFailedError (); }
Hình 3.5 Khẳng định khẳng định () ném một ngoại lệ.
nhập TestMe; // TestMe là lớp có các phương thức // sẽ được kiểm
tra.
nhập junit.framework. *; // Cái này chứa lớp TestCase.
public class MyTestSuite mở rộng TestCase {// Tạo một lớp con
// của TestCase
public void MyTest1 () {// Phương thức này là trường hợp thử
nghiệm đầu tiên TestMe object1 = new TestMe (...); // Tạo ra một
// phiên bản của TestMe với // tham số mong muốn
int x = object1.Method1 (...); // gọi Method1
// trên object1
khẳng địnhEquals (365, x); // 365 và x được mong đợi và
// các giá trị thực tế, tương ứng
}
public void MyTest2 () {// Phương thức này là trường hợp thử
nghiệm thứ hai TestMe object2 = new TestMe (...); // Tạo ra một
cái khác
// phiên bản của TestMe
// với các tham số mong muốn
double y = object2.Method2 (...); // gọi Method2
// trên object2
khẳng địnhEquals (2,99, y, 0,0001d); // 2,99 là dự kiến
// giá trị; y là thực tế

// giá trị; 0,0001 là dung sai
// mức độ }
}
Hình 3.6 Bộ thử nghiệm ví dụ.
MyTestSuite và gọi hai phương thức MyTest1 () và MyTest2 (). Hai
phương thức, cụ thể là Phương pháp 1 () và Phương pháp () 2, có
được gọi trên hai trường hợp khác nhau của lớp TestMe hay không
phụ thuộc vào mục tiêu riêng của hai trường hợp thử nghiệm đó. Nói
cách khác, chính lập trình viên là người quyết định có nên tạo hai
phiên bản của lớp TestMe hay không.
Phần này không có nghĩa là trình bày kỹ lưỡng các khả năng của
khung công tác JUnit. Người đọc được tham khảo các nguồn khác,
chẳng hạn như Bí quyết JUnit của Rainsberger [27] và Thử nghiệm
đơn vị thực dụng của Hunt và Thomas [28]. Ngoài ra, các công cụ
như Korat [29], Symstra [30], và Eclat [31] để kiểm tra đơn vị Java
đang được các nhà nghiên cứu phát triển và sử dụng.
3.9 CÁC CÔNG CỤ ĐỂ KIỂM TRA ĐƠN VỊ
Các lập trình viên có thể hưởng lợi từ việc sử dụng các công cụ trong
kiểm thử đơn vị bằng cách giảm thời gian kiểm thử mà không phải
hy sinh tính kỹ lưỡng. Các công cụ nổi tiếng trong cuộc sống hàng
ngày là trình soạn thảo, trình biên dịch, hệ điều hành và trình gỡ lỗi.
Tuy nhiên, trong một số trường hợp,
môi trường thực thi thực của một đơn vị có thể không có sẵn cho một
lập trình viên trong khi mã đang được phát triển. Trong những trường
hợp như vậy, một trình giả lập của môi trường rất hữu ích trong việc
kiểm tra và gỡ lỗi mã. Các loại công cụ khác hỗ trợ kiểm tra đơn vị
hiệu quả như sau:
Code Auditor: Công cụ này được sử dụng để kiểm tra chất lượng của
phần mềm để đảm bảo rằng nó đáp ứng một số tiêu chuẩn mã hóa tối
thiểu. Nó phát hiện các vi phạm nguyên tắc lập trình, đặt tên và kiểu.
Nó có thể xác định các phần mã không thể được chuyển giữa các hệ
điều hành và bộ xử lý khác nhau. Hơn nữa, nó có thể đề xuất những
cải tiến đối với cấu trúc và phong cách của mã nguồn. Ngoài ra, nó
còn đếm số lượng LOC có thể được sử dụng để đo năng suất, tức là,
133
LOC được tạo ra trên một đơn vị thời gian và tính toán mật độ
khuyết tật, tức là số lượng khuyết tật trên mỗi KLOC.
Bound Checker: Công cụ này có thể kiểm tra việc ghi ngẫu nhiên vào
vùng lệnh của bộ nhớ hoặc vào bất kỳ vị trí bộ nhớ nào khác bên
ngoài vùng lưu trữ dữ liệu của ứng dụng. Điều này lấp đầy không
gian bộ nhớ không sử dụng bằng một mẫu chữ ký (mẫu nhị phân
riêng biệt) như một cách để xác định sau này xem có bất kỳ không
gian bộ nhớ nào trong số này đã bị ghi đè hay không. Công cụ có thể
đưa ra thông báo chẩn đoán khi xảy ra vi phạm ranh giới trên các
mục dữ liệu. Nó có thể phát hiện sự vi phạm các ranh giới của mảng,
ví dụ, khi chỉ số mảng hoặc con trỏ nằm ngoài phạm vi cho phép của
nó. Ví dụ, nếu một mảng z được khai báo có phạm vi từ z [0] đến z
[99], nó có thể phát hiện các lần đọc và ghi bên ngoài phạm vi lưu trữ
này, ví dụ, z [ - 3] hoặc z [10].
Trình lập tài liệu: Các công cụ này đọc mã nguồn và tự động tạo mô
tả và biểu đồ cây người gọi / callee hoặc mô hình dữ liệu từ mã
nguồn.
Trình gỡ lỗi tương tác: Những công cụ này hỗ trợ các nhà phát triển
phần mềm triển khai các cách tiếp cận gỡ lỗi khác nhau được thảo
luận trong chương này. Các công cụ này phải có khả năng dò lại và
điểm ngắt để cho phép các lập trình viên hiểu được động lực của việc
thực thi chương trình và xác định các khu vực có vấn đề trong mã.
Trình gỡ lỗi điểm ngắt dựa trên logic suy diễn. Các điểm ngắt được
đặt theo phân tích heuristic của mã [32]. Một loại trình gỡ lỗi phổ
biến khác được gọi là trình gỡ lỗi toàn trí (ODB), trong đó không có
suy luận. Nó chỉ đơn giản là theo dấu vết của các giá trị “xấu” trở lại
nguồn của chúng — không cần “đoán” nơi đặt các điểm ngắt. ODB
giống như "con rắn trong cỏ", nghĩa là, nếu bạn nhìn thấy một con
rắn trong cỏ và bạn kéo đuôi nó, thì sớm muộn gì bạn cũng chui vào
đầu nó. Ngược lại, những người gỡ lỗi điểm ngắt gặp phải vấn đề
“thằn lằn trong cỏ”, tức là khi bạn nhìn thấy con thằn lằn và túm lấy
đuôi của nó, con thằn lằn sẽ đứt đuôi và bỏ đi [33].
Trình giả lập trong mạch: Trình giả lập trong mạch, thường được gọi
là ICE, là một công cụ phát triển phần mềm vô giá trong thiết kế hệ
thống nhúng. Nó cung cấp kết nối Ethernet tốc độ cao giữa trình gỡ
lỗi máy chủ và bộ vi xử lý mục tiêu, cho phép các nhà phát triển thực
hiện các hoạt động gỡ lỗi cấp nguồn phổ biến, chẳng hạn như xem bộ
nhớ và kiểm soát số lượng lớn thanh ghi, chỉ trong vài giây. Nó rất
quan trọng đối với việc khởi động hội đồng quản trị, giải quyết các
vấn đề phức tạp và sản xuất hoặc thử nghiệm sản phẩm. Nhiều trình
giả lập có các tính năng nâng cao, chẳng hạn như phân tích hiệu suất,
phân tích vùng phủ sóng, lưu vào bộ đệm các dấu vết cũng như khả
năng kích hoạt và điểm ngắt trước.
Bộ phát hiện rò rỉ bộ nhớ: Các công cụ này kiểm tra việc phân bổ bộ
nhớ cho một ứng dụng yêu cầu bộ nhớ, nhưng không phân bổ được.
Chúng phát hiện các sự cố tràn sau trong các chương trình ứng dụng:
Đọc bất hợp pháp, nghĩa là, truy cập vào bộ nhớ không được cấp cho
ứng dụng hoặc ứng dụng không được phép truy cập.
Đọc bộ nhớ chưa được khởi tạo.
Bộ nhớ động ghi đè lên một vị trí bộ nhớ chưa được cấp phát cho
ứng dụng.
Đọc từ một vị trí bộ nhớ không được cấp phát hoặc không được khởi
tạo trước khi thực hiện thao tác đọc.
Các công cụ theo dõi heap, theo dõi phân bổ heap cho các ứng dụng
và phát hiện rò rỉ bộ nhớ. Các công cụ này cũng xây dựng các cấu
hình sử dụng bộ nhớ, ví dụ, lệnh nguồn dòng mã nào truy cập một
địa chỉ bộ nhớ cụ thể.
Trình phân tích mã tĩnh (Đường dẫn): Các công cụ này xác định các
đường dẫn để kiểm tra, dựa trên cấu trúc của mã, chẳng hạn như
thước đo độ phức tạp theo chu kỳ của McCabe (Bảng 3.3). Các công
cụ này phụ thuộc vào ngôn ngữ nguồn và yêu cầu mã nguồn được
biên dịch lại bằng công cụ. Những công cụ này có thể được sử dụng
để cải thiện năng suất, quản lý tài nguyên, chất lượng và khả năng dự
đoán bằng cách cung cấp các chỉ số đo lường độ phức tạp.
Hỗ trợ kiểm tra phần mềm: Các công cụ có thể giúp lập lịch kiểm tra
nhóm. Chúng cũng có thể cung cấp trạng thái của các mục đã được
xem xét và các hành động tiếp theo cũng như phân phối các báo cáo
giải quyết vấn đề. Chúng có thể được tích hợp với các công cụ khác,
chẳng hạn như bộ phân tích mã tĩnh.
Trình phân tích phạm vi kiểm tra: Các công cụ này đo lường phạm vi
kiểm tra nội bộ, thường được thể hiện dưới dạng cấu trúc kiểm soát
của đối tượng kiểm tra và báo cáo số liệu về phạm vi kiểm tra. Máy
phân tích vùng phủ sóng theo dõi và báo cáo những đường dẫn nào
đã được thực hiện trong quá trình thử nghiệm đơn vị động. Máy phân
135
tích phạm vi kiểm tra là công cụ mạnh mẽ giúp tăng độ tin cậy về
chất lượng sản phẩm bằng cách đảm bảo rằng các kiểm tra bao gồm
tất cả các bộ phận cấu trúc của một đơn vị hoặc một chương trình.
Một khía cạnh quan trọng trong phân tích phạm vi kiểm tra là xác
định các phần của mã nguồn chưa bao giờ được chạm vào bởi bất kỳ
bài kiểm tra đơn vị động nào. Phản hồi từ các báo cáo phạm vi tới mã
nguồn giúp dễ dàng thiết kế các trường hợp kiểm thử đơn vị mới để
bao gồm các đường dẫn cụ thể chưa được kiểm tra.
Trình tạo dữ liệu thử nghiệm: Các công cụ này hỗ trợ lập trình viên
trong việc chọn dữ liệu thử nghiệm khiến chương trình hoạt động
theo cách mong muốn. Trình tạo dữ liệu thử nghiệm có thể cung cấp
một số khả năng ngoài những điều cơ bản về tạo dữ liệu:
Họ đã tạo ra một số lượng lớn các biến thể của tập dữ liệu mong
muốn dựa trên mô tả về các đặc điểm đã được đưa vào công cụ.
Họ có thể tạo dữ liệu đầu vào thử nghiệm từ mã nguồn.
Chúng có thể tạo ra các lớp và giá trị tương đương gần với ranh giới.
Họ có thể tính toán mức độ mong muốn của việc kiểm tra giá trị ranh
giới.
BẢNG 3.3 Phép đo độ phức tạp McCabe
Phép đo độ phức tạp của McCabe dựa trên độ phức tạp theo chu
kỳ của đồ thị chương trình cho một mô-đun. Chỉ số có thể được
tính bằng công thức v = e - n + 2, trong đó
v = độ phức tạp chu kỳ của đồ thị,
e = số cạnh (luồng chương trình giữa các nút)
n = số nút (nhóm tuần tự của câu lệnh chương trình)
Nếu một đồ thị được kết nối mạnh được xây dựng (một trong đó
có một cạnh giữa nút thoát và nút vào), phép tính là v = e - n + 1.
Ví dụ: Một đồ thị chương trình, được minh họa dưới đây, được sử
dụng để mô tả luồng điều khiển. Mỗi nút được khoanh tròn đại
diện cho một chuỗi các câu lệnh chương trình và luồng điều khiển
được biểu diễn bằng các cạnh có hướng. Đối với đồ thị này, độ
phức tạp chu kỳ là v = 9 - 8 + 2 = 3
n=8
e=9
Nguồn: Từ ref. 6.
Họ có thể ước tính khả năng dữ liệu thử nghiệm có thể tiết lộ lỗi.
Họ có thể tạo ra dữ liệu để hỗ trợ phân tích đột biến.
Tự động tạo đầu vào kiểm tra là một lĩnh vực nghiên cứu tích cực.
Một số công cụ, chẳng hạn như CUTE [34], DART [35], và hệ thống
EGT [36], đã được các nhà nghiên cứu phát triển để cải thiện phạm
vi kiểm tra.
Khai thác thử nghiệm: Loại công cụ này hỗ trợ việc thực hiện các bài
kiểm tra đơn vị động bằng cách giúp (i) cài đặt đơn vị được kiểm tra
trong môi trường kiểm tra gần như không đau, (ii) điều khiển thiết bị
đang được kiểm tra với dữ liệu đầu vào ở định dạng đầu vào dự kiến,
(iii) tạo các sơ khai để mô phỏng hành vi của các mô-đun cấp dưới và
(iv) nắm bắt kết quả thực tế do đơn vị đang thử nghiệm tạo ra và ghi
lại hoặc hiển thị nó ở dạng có thể sử dụng được. Các công cụ nâng
cao có thể so sánh kết quả mong đợi với kết quả thực tế và ghi lại kết
quả kiểm tra cho mỗi dữ liệu kiểm tra đầu vào.
Màn hình hiệu suất: Các đặc tính thời gian của các thành phần phần
mềm có thể được theo dõi và đánh giá bằng các công cụ này. Những
công cụ này rất cần thiết cho bất kỳ hệ thống thời gian thực nào để
đánh giá các đặc tính hoạt động của hệ thống, chẳng hạn như độ trễ
và thông lượng. Ví dụ, trong các hệ thống viễn thông, các công cụ
này có thể được sử dụng để tính toán độ trễ đầu cuối của một cuộc
gọi điện thoại.
Bộ phân tích mạng: Hệ điều hành mạng như phần mềm chạy trên bộ
định tuyến, bộ chuyển mạch và hệ thống máy khách / máy chủ được
kiểm tra bởi bộ phân tích mạng. Những công cụ này có khả năng
phân tích lưu lượng và xác định các khu vực có vấn đề. Nhiều công
137
cụ mạng này cho phép các kỹ sư kiểm tra theo dõi các chỉ số hiệu
suất và chẩn đoán các vấn đề về hiệu suất trên toàn mạng. Các công
cụ này được cải tiến để cải thiện khả năng giám sát an ninh mạng
(NSM) nhằm phát hiện sự xâm nhập [37].
Trình mô phỏng và Trình mô phỏng: Những công cụ này được sử
dụng để thay thế phần mềm và phần cứng thực hiện không khả dụng.
Cả hai loại công cụ này đều được sử dụng vì lý do đào tạo, an toàn và
kinh tế. Một số ví dụ là trình mô phỏng chuyến bay, trình mô phỏng
thiết bị đầu cuối và trình mô phỏng cho các trạm thu phát cơ sở trong
mạng di động di động. Những công cụ này được kết hợp với bộ tạo
lưu lượng và bộ phân tích hiệu suất để tạo ra một khối lượng lớn dữ
liệu đầu vào.
Bộ tạo lưu lượng: Khối lượng lớn dữ liệu cần thiết để tạo áp lực cho
các giao diện và hệ thống tích hợp được tạo ra bởi bộ tạo lưu lượng.
Chúng tạo ra các luồng giao dịch hoặc gói dữ liệu. Ví dụ, trong thử
nghiệm bộ định tuyến, người ta cần một lưu lượng mô phỏng các
luồng gói Giao thức Internet (IP) có kích thước khác nhau đến từ các
nguồn khác nhau. Các công cụ này có thể thiết lập các tham số cho
tốc độ đến trung bình của gói, thời lượng và kích thước gói. Cấu hình
hoạt động có thể được sử dụng để tạo lưu lượng truy cập để kiểm tra
tải và độ ổn định.
Kiểm soát phiên bản: Hệ thống kiểm soát phiên bản cung cấp các
chức năng để lưu trữ một chuỗi các bản sửa đổi của phần mềm và các
tệp thông tin liên quan đang được phát triển. Bản phát hành hệ thống
là một tập hợp các tệp được liên kết từ góc độ công cụ kiểm soát
phiên bản. Các tệp này có thể chứa mã nguồn, mã đã biên dịch, tài
liệu và thông tin môi trường, chẳng hạn như phiên bản của công cụ
được sử dụng để viết phần mềm. Mục tiêu của kiểm soát phiên bản là
đảm bảo một quá trình phát triển phần mềm có hệ thống và có thể
theo dõi được, trong đó tất cả các thay đổi được quản lý chính xác, để
hệ thống phần mềm luôn ở trạng thái được xác định rõ. Với hầu hết
các công cụ kiểm soát phiên bản, kho lưu trữ là nơi trung tâm chứa
bản sao chính của tất cả các tệp.
Hệ thống quản lý cấu hình (CMS) mở rộng kiểm soát phiên bản từ
phần mềm và tài liệu để kiểm soát những thay đổi được thực hiện đối
với phần cứng, phần sụn, phần mềm, tài liệu, kiểm tra, đồ đạc kiểm
tra, tài liệu kiểm tra và môi trường thực thi trong suốt quá trình phát
triển và hoạt động của hệ thống. Do đó, các công cụ quản lý cấu hình
lớn hơn, các biến thể tốt hơn của các công cụ kiểm soát phiên bản.
Các đặc điểm của công cụ quản lý cấu hình và kiểm soát phiên bản
như sau:
Kiểm soát truy cập: Các công cụ giám sát và kiểm soát quyền truy
cập vào các thành phần. Người ta có thể chỉ định người dùng nào có
thể truy cập một thành phần hoặc một nhóm các thành phần. Người
ta cũng có thể hạn chế quyền truy cập vào các thành phần hiện đang
được sửa đổi hoặc thử nghiệm.
Tham khảo chéo: Các công cụ có thể duy trì liên kết giữa các thành
phần liên quan, chẳng hạn như báo cáo sự cố, thành phần, bản sửa lỗi
và tài liệu.
3.10 TÓM TẮT
Người ta có thể hợp nhất các tệp và phối hợp nhiều bản cập nhật từ
các phiên bản khác nhau để tạo ra một tệp hợp nhất.
Theo dõi các sửa đổi: Các công cụ duy trì hồ sơ của tất cả các sửa
đổi đối với các thành phần. Những điều này cũng cho phép hợp nhất
các tệp và phối hợp nhiều bản cập nhật từ các phiên bản khác nhau
để tạo ra một tệp hợp nhất. Chúng có thể theo dõi những điểm tương
đồng và khác biệt giữa các phiên bản của mã, tài liệu và thư viện thử
nghiệm. Họ cũng cung cấp một dấu vết kiểm tra hoặc lịch sử của
những thay đổi từ phiên bản này sang phiên bản khác.
Tạo bản phát hành: Các công cụ có thể tự động tạo các bản phát
hành hệ thống mới và cách ly các phiên bản phát triển, thử nghiệm và
vận chuyển của sản phẩm.
Quản lý Phiên bản Hệ thống: Các công cụ cho phép chia sẻ các
thành phần chung giữa các phiên bản hệ thống và sử dụng có kiểm
soát các phiên bản hệ thống. Chúng hỗ trợ điều phối phát triển song
song, bảo trì và tích hợp nhiều thành phần giữa một số lập trình viên
hoặc nhóm dự án. Họ cũng điều phối các nhóm phát triển và thử
nghiệm phân tán về mặt địa lý.
Lưu trữ: Các công cụ hỗ trợ lưu trữ tự động các thành phần và phiên
bản hệ thống đã ngừng hoạt động.
3.10 TÓM TẮT
Chương này bắt đầu với mô tả về kiểm thử cấp độ đơn vị, có nghĩa là
xác định các lỗi trong một đơn vị chương trình được phân tích và
139
thực hiện một cách riêng biệt. Hai loại kiểm thử đơn vị bổ sung đã
được giới thiệu: kiểm thử đơn vị tĩnh và kiểm thử đơn vị động. Kiểm
thử đơn vị tĩnh bao gồm việc kiểm tra trực quan và phân tích mã,
trong khi đơn vị chương trình được thực thi theo cách có kiểm soát
trong kiểm thử đơn vị động.
Tiếp theo, chúng tôi mô tả quy trình xem xét mã, bao gồm sáu bước:
sẵn sàng, chuẩn bị, kiểm tra, làm lại, xác thực và thoát. Mục tiêu của
việc xem xét mã là để đánh giá chất lượng của phần mềm được đề
cập, không phải chất lượng của quá trình được sử dụng để phát triển
sản phẩm. Chúng tôi đã thảo luận về một số chỉ số cơ bản có thể
được thu thập từ quá trình xem xét mã. Các số liệu đó tạo điều kiện
cho việc ước tính thời gian xem xét và các nguồn lực cần thiết cho
các dự án tương tự. Ngoài ra, các chỉ số làm cho việc xem xét mã
hiển thị cho quản lý cấp trên và cho phép quản lý cấp trên hài lòng
với khả năng tồn tại của việc xem xét mã như một công cụ kiểm tra.
Chúng tôi đã giải thích một số biện pháp phòng ngừa có thể được
thực hiện trong quá trình phát triển mã để giảm số lỗi trong một
chương trình. Các biện pháp phòng ngừa đã được trình bày dưới
dạng một tập hợp các hướng dẫn mà các lập trình viên có thể tuân
theo để xây dựng mã. Về cơ bản, các hướng dẫn tập trung vào việc
kết hợp các cơ chế phù hợp vào mã.
Tiếp theo, chúng tôi đã nghiên cứu chi tiết về kiểm thử đơn vị động.
Trong thử nghiệm đơn vị động, một đơn vị chương trình thực sự
được thực thi và kết quả của việc thực thi chương trình được quan
sát. Các khái niệm về trình điều khiển thử nghiệm và sơ khai đã được
giải thích trong ngữ cảnh của một đơn vị đang được thử nghiệm.
Trình điều khiển thử nghiệm là một trình gọi của đơn vị được kiểm
tra và tất cả các “mô-đun giả” được gọi bởi đơn vị được gọi là sơ
khai. Chúng tôi đã mô tả cách phân tích đột biến có thể được sử dụng
để xác định điểm yếu trong dữ liệu thử nghiệm được sử dụng cho thử
nghiệm đơn vị. Phân tích đột biến nên được sử dụng kết hợp với các
kỹ thuật kiểm thử đơn vị truyền thống như phân tích miền hoặc phân
tích luồng dữ liệu. Nghĩa là, kiểm tra đột biến không phải là một giải
pháp thay thế cho kiểm tra miền hoặc phân tích luồng dữ liệu.
Với mô hình kiểm tra đơn vị tại chỗ để phát hiện ra các lỗi, chúng tôi
đã kiểm tra cách các lập trình viên có thể xác định lỗi bằng cách gỡ
lỗi một đơn vị. Gỡ lỗi xảy ra do một bài kiểm tra phát hiện ra một
khiếm khuyết. Chúng tôi đã thảo luận về ba cách tiếp cận để gỡ lỗi:
bạo lực, loại bỏ nguyên nhân và bẻ khóa ngược. Mục tiêu của việc gỡ
lỗi là xác định chính xác nguyên nhân gây ra lỗi. Với các triệu chứng
của một vấn đề, mục đích là để cô lập và xác định nguyên nhân cụ
thể của nó. Chúng tôi đã giải thích một phương pháp heuristic để
thực hiện gỡ lỗi chương trình.
Tiếp theo, chúng tôi đã giải thích kiểm thử đơn vị động là một phần
không thể thiếu của quá trình phát triển phần mềm XP. Trong quy
trình XP, các bài kiểm tra đơn vị được tạo trước khi mã hóa — điều
này được gọi là bài kiểm tra đầu tiên. Phương pháp thử nghiệm đầu
tiên thiết lập các kiểm tra và cân bằng để cải thiện cơ hội hoàn thành
công việc ngay lần đầu tiên. Sau đó, chúng tôi đã giới thiệu khung
công tác JUnit, được sử dụng để tạo và thực hiện các bài kiểm tra
đơn vị động.
Chúng tôi đã kết thúc chương với mô tả về một số công cụ có thể
hữu ích trong việc cải thiện hiệu quả của kiểm thử đơn vị. Các công
cụ này thuộc các loại sau: trình kiểm tra mã, trình kiểm tra ràng buộc,
trình tài liệu, trình gỡ lỗi tương tác, trình mô phỏng trong mạch, trình
phát hiện rò rỉ bộ nhớ, trình phân tích mã tĩnh, công cụ hỗ trợ kiểm
tra phần mềm, trình phân tích phạm vi kiểm tra, trình tạo dữ liệu
kiểm tra, công cụ tạo kiểm tra khai thác, màn hình hiệu suất, máy
phân tích mạng, trình mô phỏng và trình mô phỏng, trình tạo lưu
lượng và các công cụ để kiểm soát phiên bản.
4.6 ĐẦU VÀO KIỂM TRA PHÁT 141
CHAPTER
4
ControlFlowTesting
Người kiểm soát hiện tại, kiểm soát quá khứ. Người kiểm soát quá
khứ, kiểm soát tương lai.
—GeorgeOrwell
4.1 Ý TƯỞNG CƠ BẢN
Hai loại câu lệnh cơ bản trong một đơn vị chương trình là câu lệnh
gán và câu lệnh điều kiện. Câu lệnh gán được biểu diễn rõ ràng bằng
cách sử dụng ký hiệu gán, “ = ”, chẳng hạn như x = 2 * y ;, trong đó
x và y là các biến. Điều kiện chương trình là cốt lõi của các câu lệnh
điều kiện, chẳng hạn như vòng lặp if (), for (), vòng lặp while () và
goto. Ví dụ, trong if (x! = Y), chúng tôi đang kiểm tra sự bất đẳng
thức của x và y. Trong trường hợp không có câu lệnh điều kiện, các
lệnh chương trình được thực hiện theo trình tự mà chúng xuất hiện. Ý
tưởng về việc thực hiện liên tiếp các lệnh dẫn đến khái niệm luồng
điều khiển trong một đơn vị chương trình. Các câu lệnh điều kiện
thay đổi dòng điều khiển mặc định, tuần tự trong một đơn vị chương
trình. Trên thực tế, ngay cả một số lượng nhỏ các câu lệnh điều kiện
cũng có thể dẫn đến một cấu trúc luồng điều khiển phức tạp trong
một chương trình.
Lời gọi hàm là một cơ chế để cung cấp tính trừu tượng trong thiết kế
chương trình. Một lệnh gọi đến một hàm chương trình dẫn đến điều
khiển nhập hàm được gọi. Tương tự, khi hàm được gọi thực hiện câu
lệnh trả về của nó, chúng ta nói rằng điều khiển thoát khỏi hàm. Mặc
dù một hàm có thể có nhiều câu lệnh trả về, để đơn giản, người ta có
thể cấu trúc lại hàm để có chính xác một câu trả về. Một đơn vị
chương trình có thể được xem là có điểm vào được xác định rõ và
điểm ra được xác định rõ. Việc thực hiện một chuỗi các lệnh từ điểm
vào đến điểm thoát của một đơn vị chương trình được gọi là đường
dẫn chương trình. Có thể có một số lượng lớn, thậm chí vô hạn
đường dẫn trong một đơn vị chương trình. Mỗi đường dẫn chương
142 CHƯƠNG 4 KIỂM TRA LƯU LƯỢNG ĐIỀU KHIỂN
trình có thể được đặc trưng bởi một đầu vào và một đầu ra mong đợi.
Một giá trị đầu vào cụ thể làm cho một đường dẫn chương trình cụ
thể được thực thi; dự kiến rằng đường dẫn chương trình thực hiện
tính toán mong muốn, do đó tạo ra giá trị đầu ra mong đợi. Do đó, có
vẻ tự nhiên khi thực thi càng nhiều đường dẫn chương trình càng tốt.
Chỉ thực hiện một số lượng lớn
88
4.2 KIỂM TRA LƯU LƯỢNG ĐIỀU KHIỂN NGOÀI TRỜI
, với chi phí cao hơn, có thể không hiệu quả trong việc để lộ các
khuyết tật. Lý tưởng nhất, người ta phải cố gắng thực hiện ít đường
dẫn hơn để có hiệu quả tốt hơn.
Các khái niệm về luồng điều khiển trong chương trình máy tính [1],
đường dẫn chương trình [2], và kiểm tra luồng điều khiển [2–8] đã
được nghiên cứu trong nhiều thập kỷ. Các công cụ đang được phát
triển để hỗ trợ kiểm tra luồng điều khiển [9]. Các công cụ như vậy
xác định các đường dẫn từ một đơn vị chương trình dựa trên tiêu chí
do người dùng xác định, tạo đầu vào tương ứng để thực hiện một
đường dẫn đã chọn, đồng thời tạo ra các bản gốc chương trình và
trình điều khiển để thực hiện kiểm tra. Kiểm thử dòng điều khiển là
một loại kiểm tra cấu trúc, được thực hiện bởi các lập trình viên để
kiểm tra mã do họ viết. Khái niệm này được áp dụng cho các đơn vị
mã nhỏ, chẳng hạn như một hàm. Các trường hợp kiểm thử để kiểm
tra luồng điều khiển được bắt nguồn từ mã nguồn, chẳng hạn như
một đơn vị chương trình (ví dụ, một chức năng hoặc phương pháp),
chứ không phải từ toàn bộ chương trình.
Về mặt cấu trúc, một đường dẫn là một chuỗi các câu lệnh trong một
đơn vị chương trình, trong khi về mặt ngữ nghĩa, nó là một thể hiện
thực thi của đơn vị đó. Đối với một tập hợp dữ liệu đầu vào nhất
định, đơn vị chương trình thực hiện một đường dẫn nhất định. Đối
với một tập hợp dữ liệu đầu vào khác, đơn vị có thể thực thi một
đường dẫn khác. Ý tưởng chính trong thử nghiệm dòng kiểm soát là
chọn một vài đường dẫn trong một đơn vị chương trình một cách
thích hợp và quan sát xem các đường dẫn đã chọn có tạo ra kết quả
mong đợi hay không. Bằng cách thực hiện một vài đường dẫn trong
một đơn vị chương trình, lập trình viên cố gắng đánh giá hành vi của
toàn bộ đơn vị chương trình.
4.2 KIỂM TRA LƯU LƯỢNG ĐIỀU KHIỂN NGOÀI TRỜI
Ý tưởng tổng thể về việc tạo dữ liệu đầu vào thử nghiệm để thực hiện
thử nghiệm dòng điều khiển đã được mô tả trong Hình 4.1. Các hoạt
động được thực hiện, kết quả trung gian được tạo ra bởi các hoạt
động đó và sở thích của lập trình viên trong quá trình tạo thử nghiệm
được giải thích dưới đây.
Đầu vào: Mã nguồn của một đơn vị chương trình và một tập hợp các
tiêu chí lựa chọn đường dẫn là đầu vào cho quá trình tạo dữ liệu thử
nghiệm. Sau đây, hai ví dụ về tiêu chí lựa chọn đường dẫn được đưa
ra.
Thí dụ. Chọn các đường dẫn sao cho mọi câu lệnh
được thực thi ít nhất một lần.
Thí dụ. Chọn các đường dẫn sao cho mọi câu lệnh có điều kiện, ví
dụ, một câu lệnh if (), được đánh giá là true và false ít nhất một lần
trong các trường hợp khác nhau. Một câu lệnh điều kiện có thể đánh
giá là true trong một đường dẫn và false trong một đường dẫn thứ
hai.
Tạo đồ thị luồng điều khiển: Đồ thị luồng điều khiển (CFG) là một
biểu diễn đồ họa chi tiết của một đơn vị chương trình. Ý tưởng đằng
sau việc vẽ một CFG là có thể hình dung tất cả các đường dẫn trong
một đơn vị chương trình. Quá trình vẽ CFG từ một đơn vị chương
trình sẽ được giải thích trong phần sau. Nếu quá trình tạo thử nghiệm
được tự động hóa, trình biên dịch có thể được sửa đổi để tạo CFG.
Path
selection
criteria
Draw a
Program Control Select Selected
control flow
unit flow graph paths paths
graph
Inputs
Generate
test input
data
Are
No the selected
paths
feasible?
Yes
Process of generating test input data
Output Test input

data
Hình 4.1 Quy trình tạo dữ liệu đầu vào kiểm tra để kiểm tra
luồng điều khiển.
Lựa chọn đường dẫn: Các đường dẫn được chọn từ CFG để đáp ứng
các tiêu chí lựa chọn đường dẫn và nó được thực hiện bằng cách xem
xét cấu trúc của CFG.
Tạo dữ liệu đầu vào kiểm tra: Một đường dẫn có thể được thực thi
nếu và chỉ khi một trường hợp nhất định của các đầu vào cho đơn vị
chương trình khiến tất cả các câu lệnh điều kiện dọc theo đường dẫn
được đánh giá thành true hoặc false theo quy định của luồng điều
khiển. Con đường như vậy được gọi là con đường khả thi. Nếu
không, con đường được cho là không khả thi. Điều cần thiết là xác
định các giá trị nhất định của các đầu vào từ một đường dẫn nhất
định để đường dẫn thực thi.
Kiểm tra tính khả thi của một con đường: Ý tưởng đằng sau việc
kiểm tra tính khả thi của một con đường đã chọn là đáp ứng các tiêu
chí lựa chọn con đường. Nếu một số đường dẫn đã chọn không khả
thi, thì các đường dẫn mới sẽ được chọn để đáp ứng các tiêu chí.
4.3 ĐỒ THỊ LƯU LƯỢNG ĐIỀU KHIỂN
CFG là một biểu diễn đồ họa của một đơn vị chương trình. Ba ký
hiệu được sử dụng để xây dựng một CFG, như thể hiện trong Hình
4.2. Một hình chữ nhật đại diện cho một tuần tự
4.3 ĐỒ THỊ LƯU LƯỢNG ĐIỀU KHIỂN
True False
Computation Decision
Sequential computation Decision point Merge point

Hình 4.2 Các ký hiệu trong CFG.
tính toán. Tính toán tuần tự tối đa có thể được biểu diễn bằng một
hình chữ nhật hoặc nhiều hình chữ nhật, mỗi hình tương ứng với một
câu lệnh trong mã nguồn.
Chúng tôi gắn nhãn mỗi hộp tính toán và quyết định bằng một số
nguyên duy nhất. Hai nhánh của hộp quyết định được gắn nhãn T và
F để đại diện cho các đánh giá đúng và sai tương ứng của điều kiện
trong hộp. Chúng tôi sẽ không gắn nhãn một nút hợp nhất, vì người
ta có thể dễ dàng xác định các đường dẫn trong CFG ngay cả khi
không xem xét rõ ràng các nút hợp nhất. Hơn nữa, việc không đề cập
đến các nút hợp nhất trong một đường dẫn sẽ làm cho mô tả đường
dẫn ngắn hơn.
Chúng tôi xem xét hàm openfiles () được hiển thị trong Hình 4.3 để
minh họa quá trình vẽ một CFG. Hàm có ba câu lệnh: câu lệnh gán
int i = 0 ;, câu lệnh điều kiện if () và câu lệnh return (i). Người đọc có
thể lưu ý rằng bất kể đánh giá của if (), hàm thực hiện cùng một hành
động, cụ thể là null. Trong Hình 4.4, chúng tôi cho thấy một đại diện
cấp cao của
TẬP TIN * fptr1, * fptr2, * fptr3; / * Đây là các biến toàn cục. *
/
int openfiles () {
/*
Hàm này cố gắng mở các tệp "tệp1", "tệp2" và "tệp3" để truy
cập đọc và trả về số tệp đã mở thành công. Con trỏ tệp của tệp
đã mở được đặt trong các biến toàn cục.
*/
int i = 0;
nếu(
(((fptr1 = fopen ("file1", "r"))! = NULL) && (i ++)
&& (0)) ||
(((fptr2 = fopen ("file2", "r"))! = NULL) && (i ++)
&& (0)) ||
(((fptr3 = fopen ("file3", "r"))! = NULL) && (i ++))
); return (i);
}
Hình 1 4.3 Chức năng mở ba tệp.
Điểm i=0 đầu vào
TF 2
Điểm if() thoát Hình 4.4 Biểu diễn CFG cấp cao của
các tệp openfiles (). Ba nút được đánh số 1, 2 và 3.
luồng điều khiển trong openfiles () với ba nút được
đánh 3 số 1, 2 và 3. Biểu đồ luồng chỉ hiển thị hai đường
return(i)
dẫn trong openfiles ().
Kiểm tra kỹ hơn phần điều kiện của câu lệnh if () cho thấy rằng
không chỉ có các toán tử Boolean và quan hệ trong phần điều kiện,
mà còn có các câu lệnh gán. Một số ví dụ của họ được đưa ra dưới
đây:
Câu lệnh gán: fptr1 = fopen (“file1”, “r”) và i ++
Toán tử quan hệ: fptr1! = KHÔNG
Toán tử Boolean: && và ||
Việc thực thi các câu lệnh gán trong phần điều kiện của câu lệnh if
phụ thuộc vào các điều kiện thành phần. Ví dụ, hãy xem xét điều
kiện thành phần sau trong phần if:
(((fptr1 = fopen ("file1", "r"))! = NULL) && (i ++) && (0))
Điều kiện trên được thực hiện như sau:

Thực hiện câu lệnh gán fptr1 = fopen (“file1”, “r”).
Thực thi phép toán quan hệ fptr1! = KHÔNG.
Nếu toán tử quan hệ ở trên đánh giá là false, hãy bỏ qua việc đánh
giá các thành phần điều kiện tiếp theo (i ++ ) && (0).
Nếu toán tử quan hệ được đánh giá là true, thì đầu tiên (i) được đánh
giá là true hoặc false. Bất kể kết quả của đánh giá này như thế nào,
câu lệnh tiếp theo được thực thi là (i ++ ).
Nếu (i) được đánh giá là true, thì điều kiện (0) được đánh giá. Nếu
không, đánh giá (0) bị bỏ qua.
Trong hình 4.5, chúng tôi hiển thị một CFG chi tiết cho hàm
openfiles (). Hình vẽ minh họa một thực tế là CFG có thể chiếm một
cấu trúc phức tạp ngay cả đối với một đơn vị chương trình nhỏ.
Chúng tôi đưa ra một phương thức Java, được gọi là ReturnAverage
(), trong Hình 4.6. Phương thức chấp nhận bốn tham số, cụ thể là giá
trị, AS, MIN và MAX, trong đó giá trị là một mảng số nguyên và AS
là kích thước tối đa của mảng. Mảng có thể chứa ít phần tử hơn AS;
một kịch bản như vậy được biểu diễn về mặt ngữ nghĩa bằng cách có
giá trị - 999 biểu thị phần cuối của mảng. Ví dụ: AS = 15,
4.4 CÁC BÉ TRONG ĐỒ THỊ DÒNG ĐIỀU KHIỂN
1
i=0
2 8
fptr1 = fopen("file1", "r") fptr2 = fopen("file2", "r")
3 9
fptr1 != NULL fptr2 != NULL
T F T F
4 10
T i F T i F
11 12
5 6
i++ i++ i++ i++
7 F 13
0 0
F
T T
14
fptr3 = fopen("file3", "r")
15
T fptr3 != NULL
16 F
T i F
17
18
i++ i++
20 19
null null
21
return(i)
Hình 4.5 Biểu diễn CFG chi tiết của openfiles (). Các số 1–21 là các
nút.
trong khi phần tử thứ 10 của mảng là - 999, có nghĩa là có 10 phần tử
— 0–9 – trong mảng. MIN và MAX là hai giá trị số nguyên được sử
dụng để thực hiện các phép tính nhất định trong phương thức.
Phương thức tính tổng các giá trị của tất cả các phần tử của mảng
nằm trong phạm vi đóng [MIN, MAX], đếm số của chúng và trả về
giá trị trung bình của chúng. CFG của phương pháp được thể hiện
trong Hình 4.7.
4.4 CÁC BÉ TRONG ĐỒ THỊ DÒNG ĐIỀU KHIỂN
Chúng tôi giả định rằng một biểu đồ luồng điều khiển có chính xác
một nút vào và chính xác một nút ra để thuận tiện cho việc thảo luận.
Mỗi nút được gắn nhãn bằng một
public static double ReturnAverage (int value [], int
AS, int MIN, int MAX) {
/*
Chức năng: ReturnAverage Tính giá trị trung bình
của tất cả các số đó trong mảng đầu vào trong phạm
vi dương [MIN, MAX]. Kích thước tối đa của mảng
là AS. Tuy nhiên, kích thước mảng có thể nhỏ hơn
AS trong trường hợp này phần cuối của đầu vào
được biểu thị bằng -999.
*/
int i, ti, tv, sum; av đôi;
i = 0; ti = 0; tv = 0; tổng = 0;
while (ti <AS && value [i]! = -999) {
ti ++; if (value [i]> = MIN && value [i] <= MAX)
{tv ++; sum = sum + value [i];
} i ++;
}
nếu (tv> 0)
av = (gấp đôi) sum / tv;
khác av = (kép) -999;
return (av);
}
Hình 4.6 Hàm tính giá trị trung bình của các số nguyên được
chọn trong một mảng. Chương trình này là sự điều chỉnh của “Hình
2. Một chương trình mẫu” trong ref. 10. (Với sự cho phép của Hiệp
hội Máy tính Úc.)
giá trị số nguyên. Ngoài ra, hai nhánh của nút quyết định được gắn
nhãn true (T) hoặc false (F) một cách thích hợp. Chúng tôi quan tâm
đến việc xác định các đường vào - lối ra trong CFG. Một đường dẫn
được biểu diễn dưới dạng một chuỗi các nút tính toán và quyết định
từ nút vào đến nút thoát. Chúng tôi cũng chỉ định liệu điều khiển
thoát ra khỏi nút quyết định thông qua nhánh đúng hay sai của nó
trong khi đưa nó vào một đường dẫn.
Trong Bảng 4.1, chúng tôi chỉ ra một vài đường dẫn từ đồ thị luồng
điều khiển của Hình 4.7. Người đọc có thể lưu ý rằng chúng tôi đã tự
ý chọn các đường dẫn này mà không áp dụng bất kỳ tiêu chí lựa chọn
đường dẫn nào. Chúng tôi đã mở vòng lặp chỉ một lần trong đường
dẫn 3 , trong khi đường dẫn 4 mở cùng một vòng lặp hai lần và đây
là hai đường dẫn riêng biệt.
4.5 TIÊU CHÍ LỰA CHỌN PATH
Một CFG, chẳng hạn như trong Hình 4.7, có thể có một số lượng lớn
các đường dẫn khác nhau. Người ta có thể bị cám dỗ để kiểm tra việc
thực thi mỗi và mọi đường dẫn trong một đơn vị chương trình. Đối
với một đơn vị chương trình có số lượng đường dẫn nhỏ, việc thực
thi tất cả các đường dẫn có thể
Initialize: value[], AS 1
MIN, MAX
i = 0, ti = 0, 2
tv = 0, sum =0
3
F T
ti < AS
4
F T
value[i] != −999
5
10
F T ti++
tv > 0
6
F
value[i] >= MIN
11 12
av = (double) −999 av = (double)sum/tv T
7
F
value[i] <= MAX
T
8
tv++
sum = sum + value[i]
13
9
return(av) i++
Hình 4.7 Biểu diễn CFG của ReturnAverage (). Các số 1–13 là các
nút.
BẢNG 4.1 Các ví dụ về đường dẫn trong CFG của Hình 4.7
Đường dẫn 1 1-2-3 (F) -10 (T) -12-13

Đường dẫn 2 1-2-3 (F) -10 (F) -11-13
Đường dẫn 3 1-2-3 (T) -4 (T) -5-6 (T) -7 (T) -8-9-3 (F) -10 (T) -
12-13
Đường dẫn 4 1-2-3 (T) -4 (T) -5-6 (T) -7 (T) -8-9-3 (T) -4 (T) -5-6
(T) -7 (T) -8-9-3 (F) -10 (T) -12-13
là mong muốn và có thể đạt được. Mặt khác, đối với một đơn vị
chương trình có nhiều đường dẫn, việc thực thi mọi đường dẫn riêng
biệt có thể không thực tế. Do đó, các lập trình viên sẽ có hiệu quả
hơn khi chọn một số lượng nhỏ các đường dẫn chương trình để cố
gắng tiết lộ các khiếm khuyết trong mã. Với tập hợp tất cả các con
đường, người ta phải đối mặt với câu hỏi "Tôi chọn những con
đường nào để thử nghiệm?" Khái niệm về tiêu chí lựa chọn đường
dẫn là hữu ích để trả lời câu hỏi trên. Sau đây, chúng tôi nêu những
ưu điểm của việc chọn đường dẫn dựa trên các tiêu chí đã xác định:
Tất cả các cấu trúc chương trình được thực hiện ít nhất một lần. Lập
trình viên cần quan sát kết quả của việc thực hiện từng cấu trúc
chương trình, ví dụ, các câu lệnh, điều kiện Boolean và trả về. •
Chúng tôi không tạo các đầu vào kiểm tra thực thi lặp lại cùng một
đường dẫn. Thực hiện cùng một đường dẫn nhiều lần là một sự lãng
phí tài nguyên. Tuy nhiên, nếu mỗi lần thực thi một đường dẫn
chương trình có khả năng cập nhật trạng thái của hệ thống, chẳng hạn
như trạng thái cơ sở dữ liệu, thì nhiều lần thực thi trên cùng một
đường dẫn có thể không giống nhau. • Chúng tôi biết các tính năng
của chương trình đã được thử nghiệm và những tính năng chưa được
thử nghiệm. Ví dụ, chúng ta có thể thực thi một câu lệnh if chỉ một
lần để nó đánh giá là true. Nếu chúng tôi không thực hiện lại nó một
lần nữa vì đánh giá sai của nó, ít nhất chúng tôi biết rằng chúng tôi đã
không quan sát kết quả của chương trình với một đánh giá sai về câu
lệnh if.
Bây giờ chúng tôi giải thích các tiêu chí lựa chọn đường dẫn nổi
tiếng sau đây:
Chọn tất cả các đường dẫn.
Chọn các đường dẫn để đạt được phạm vi báo cáo hoàn chỉnh.
Chọn các đường dẫn để đạt được phạm vi bao phủ chi nhánh hoàn
chỉnh.
Chọn các đường dẫn để đạt được mức độ bao phủ của vị từ.
4.5.1 Tiêu chí về mức độ phù hợp cho tất cả các đường dẫn
Nếu tất cả các đường dẫn trong CFG được chọn, thì người ta có thể
phát hiện tất cả các lỗi, ngoại trừ các lỗi do thiếu đường dẫn. Tuy
nhiên, một chương trình có thể chứa một số lượng lớn các đường
dẫn, hoặc thậm chí vô số đường dẫn. Hàm openfiles () nhỏ, không có
vòng lặp được hiển thị trong Hình 4.3 chứa hơn 25 đường dẫn.
Người ta không biết liệu một con đường có khả thi hay không tại thời
điểm lựa chọn các con đường, mặc dù chỉ có tám trong số tất cả các
con đường đó là khả thi. Nếu một người chọn tất cả các đường có thể
có trong một chương trình, thì chúng tôi nói rằng tiêu chí lựa chọn tất
cả các đường đã được thỏa mãn.
Chúng ta hãy xem xét ví dụ về hàm openfiles (). Hàm này cố gắng
mở ba tệp file1, file2 và tệp3. Hàm trả về một số nguyên đại diện cho
số tệp mà nó đã mở thành công. Một tệp được cho là đã được mở
thành công với quyền truy cập “đọc” nếu tệp tồn tại. Sự tồn tại của
một tệp là “có” hoặc “không”. Do đó, miền đầu vào của hàm bao
gồm tám sự kết hợp của sự tồn tại của ba tệp, như được thể hiện
trong Bảng 4.2.
Chúng ta có thể theo dõi một đường dẫn trong CFG của Hình 4.5 cho
mỗi đầu vào, tức là mỗi hàng của Bảng 4.2. Lý tưởng nhất là chúng
tôi xác định các đầu vào kiểm tra để thực thi một đường dẫn nhất
định trong
BẢNG 4.2 Miền đầu vào của tệp openfiles ()
Existence of file1 Existence of
Existence of file2 file3
No No No
No No Yes
No Yes No
No Yes Yes
Yes No No
Yes No Yes
Yes Yes No
Yes Yes Yes
BẢNG 4.3 Đầu vào và Đường dẫn trong openfiles ()

Input Path
<No, No, No> 1-2-3(F)-8-9(F)-14-15(F)-19-21
<Yes, No, No> 1-2-3(T)-4(F)-6-8-9(F)-14-15(F)-19-21
<Yes, Yes, 1-2-3(T)-4(F)-6-8-9(T)-10(T)-11-13(F)-14-
Yes> 15(T)-16(T)-18-20-21
chương trình; điều này sẽ được giải thích sau trong chương này.
Chúng tôi đưa ra ba ví dụ về các đường dẫn được thực thi bởi các
đầu vào thử nghiệm (Bảng 4.3). Theo cách này, chúng ta có thể xác
định tám con đường khả thi trong Hình 4.5. Tiêu chí lựa chọn tất cả
các đường dẫn là mong muốn vì nó có thể phát hiện ra các lỗi; tuy
nhiên, nó khó đạt được trong thực tế.
4.5.2 Tiêu chí Mức độ phù hợp của Tuyên bố
Phạm vi của câu lệnh đề cập đến việc thực hiện các câu lệnh chương
trình riêng lẻ và quan sát kết quả. Chúng tôi nói rằng mức độ phù hợp
của câu lệnh là 100% đã đạt được nếu tất cả các câu lệnh đã được
thực thi ít nhất một lần. Mức độ phù hợp của tuyên bố hoàn chỉnh là
tiêu chí yếu nhất trong việc kiểm tra chương trình. Bất kỳ bộ thử
nghiệm nào đạt được ít hơn phạm vi tuyên bố cho phần mềm mới
được coi là không thể chấp nhận được.
Tất cả các câu lệnh của chương trình được biểu diễn dưới một số
hình thức trong CFG. Đề cập đến phương thức ReturnAverage ()
trong Hình 4.6 và CFG của nó trong Hình 4.7, bốn câu lệnh gán
i = 0; ti = 0; tv = 0; tổng = 0;
đã được đại diện bởi nút 2 . Câu lệnh while đã được biểu diễn dưới
dạng một vòng lặp, trong đó điều kiện điều khiển vòng lặp
(ti <AS && value [i]! = -999)
đã được đại diện bởi các nút 3 và 4 . Do đó, bao hàm một câu lệnh
trong chương trình có nghĩa là truy cập một hoặc nhiều nút đại diện
cho câu lệnh, chính xác hơn là chọn một đường vào-ra khả thi bao
gồm các nút tương ứng. Vì một đường vào-lối ra bao gồm nhiều nút,
chúng ta chỉ cần chọn một vài đường dẫn để bao phủ tất cả các nút
của CFG. Do đó, vấn đề cơ bản là chọn một vài con đường khả thi để
bao phủ tất cả các nút của CFG nhằm đạt được tiêu chí bao phủ câu
lệnh hoàn chỉnh. Chúng tôi tuân theo các quy tắc này trong khi chọn
đường dẫn:
Chọn đường đi ngắn. • Chọn các đường đi có chiều dài ngày càng
dài. Mở vòng lặp nhiều lần nếu có nhu cầu.
Chọn các đường dẫn dài, "phức tạp" tùy ý.
Người ta có thể chọn hai đường dẫn trong Hình 4.4 để đạt được
phạm vi hoàn chỉnh của câu lệnh.
4.5.3 Tiêu chí về phạm vi chi nhánh
Về mặt cú pháp, một nhánh là một cạnh đi ra từ một nút. Tất cả các
nút hình chữ nhật có nhiều nhất một nhánh đi ra (cạnh). Nút thoát của
CFG không có nhánh đi. Tất cả các nút kim cương có hai nhánh đi
ra. Che một nhánh có nghĩa là chọn một đường dẫn bao gồm nhánh.
Phạm vi chi nhánh hoàn chỉnh có nghĩa là chọn một số đường dẫn
sao cho mọi chi nhánh đều được bao gồm trong ít nhất một đường
dẫn.
Trong một cuộc thảo luận trước đó, chúng tôi đã chỉ ra rằng người ta
có thể chọn hai con đường, SCPath 1 và SCPath 2 trong Bảng 4.4,
để đạt được phạm vi báo cáo đầy đủ. Hai đường dẫn này bao phủ tất
cả các nút (câu lệnh) và hầu hết các nhánh của CFG được thể hiện
trong Hình 4.7. Các nhánh không bị che bởi hai đường dẫn này đã
được tô đậm bằng các nét đứt nét đậm trong Hình 4.8. Các nhánh
không được che phủ này tương ứng với ba điều kiện độc lập
value [i]! = -999 value [i]> = MIN value [i] <= MAX
đánh giá thành sai. Điều này có nghĩa là với tư cách là một lập trình
viên, chúng tôi không quan sát thấy kết quả của việc thực thi chương
trình do các điều kiện đánh giá thành sai. Do đó, phạm vi nhánh hoàn
chỉnh có nghĩa là chọn đủ số lượng đường dẫn sao cho mọi điều kiện
được đánh giá là đúng ít nhất một lần và sai ít nhất một lần.
Chúng ta cần chọn thêm các đường đi để che các nhánh được tô đậm
bởi các nét đứt nét đậm trong hình 4.8. Bảng 4.5.
BẢNG 4.4 Các đường dẫn cho Báo cáo Mức độ bao phủ của
CFG trong Hình 4.7
SCPath 1 1-2-3 (F) -10 (F) -11-13

SCPath 2 1-2-3 (T) -4 (T) -5-6 (T) -7 (T) -8-9-3 (F) -10 (T) -
12-13
Initialize: value[], AS 1
MIN, MAX
i = 0, ti = 0, 2
tv = 0, sum = 0
3
F T
ti < AS
4
F
value[i] != −999 T
5
10
F T ti++
tv > 0
6
F
value[i] >= MIN
11 12
av = (double)−999 av = (double)sum/tv T
7
F
value[i] <= MAX
T
8
tv++
sum = sum + value[i]
13
9
return(av) i++
Hình 4.8 Các mũi tên đứt nét thể hiện các nhánh không được
bao hàm trong câu lệnh bao trùm trong Bảng 4.4.
BẢNG 4.5 Các đường dẫn đến phạm vi phủ sóng chi nhánh
của CFG trong Hình 4.7
BCPath 1 1-2-3 (F) -10 (F) -11-13

BCPath 2 1-2-3 (T) -4 (T) -5-6 (T) -7 (T) -8-
9-3 (F) -10 (T) -12-13
BCPath 3 1-2-3 (T) -4 (F) -10 (F) -11-13
BCPath 4 1-2-3 (T) -4 (T) -5-6 (F) -9-3 (F) -

10 (F) -11-13
BCPath 5 1-2-3 (T) -4 (T) -5-6 (T) -7 (F) -9-
3 (F) -10 (F) -11-13
4.5.4 Dự đoán tiêu chí mức độ phù hợp

Chúng tôi tham khảo CFG một phần của Hình 4.9a để giải thích khái
niệm về phạm vi vị từ. OB1, OB2, OB3 và OB là bốn biến Boolean.
Chương trình tính toán các giá trị của các biến riêng lẻ OB1, OB2 và
OB3— chi tiết tính toán của chúng không liên quan đến cuộc thảo
luận của chúng ta và đã được bỏ qua. Tiếp theo, OB được tính như
trong CFG. CFG kiểm tra giá trị của OB và thực thi OBlock1 hoặc
OBlock2 tùy thuộc vào việc OB đánh giá tương ứng là true hay false.
Chúng ta chỉ cần thiết kế hai trường hợp kiểm thử để đạt được cả
phạm vi bao phủ của câu lệnh và phạm vi chi nhánh. Chúng tôi chọn
các đầu vào sao cho bốn điều kiện Boolean trong Hình 4.9a đánh giá
theo các giá trị được hiển thị trong Bảng 4.6. Người đọc có thể lưu ý
rằng chúng tôi đã chỉ ra một cách để buộc OB phải đúng. Nếu chúng
ta chọn các đầu vào để hai trường hợp này giữ nguyên, thì chúng ta
không quan sát thấy tác động của các phép tính diễn ra trong các nút
2 và 3 . Có thể có lỗi trong phần tính toán của nút 2 và 3 sao cho
OB2 và OB3 luôn đánh giá là sai.
1 1
Compute OB1 Compute AB1
2 2
Compute OB2 Compute AB2
3 Compute OB3 3 Compute AB3
4 OB = OB1 || OB2 || OB3 4 AB = AB1 && AB2 && AB3
5 5
T F T F
if(OB) if(AB)
6 7 6 7
OBlock1 OBlock2 ABlock1 ABlock2
(a) (b)
Hình 4.9 CFG một phần với (a) hoạt động OR và (b) hoạt động
AND.
BẢNG 4.6 Hai trường hợp cho Báo cáo đầy đủ và Phạm vi
nhánh của CFG trong Hình 4.9a
Các
trường OB1 OB2 OB3 OB
hợp
1 T F F T
2 F F F F
Do đó, cần phải thiết kế các trường hợp kiểm thử sao cho một đường
dẫn được thực thi trong tất cả các điều kiện có thể. Nhánh False của
nút 5 (Hình 4.9a) được thực thi theo đúng một điều kiện, cụ thể là khi
OB1 = False, OB2 = False và OB3 = False, trong khi nhánh true thực
thi theo bảy điều kiện. Nếu tất cả các kết hợp có thể có của các giá trị
chân lý của các điều kiện ảnh hưởng đến đường dẫn đã chọn đã được
khám phá trong một số thử nghiệm, thì chúng tôi nói rằng đã đạt
được phạm vi bao hàm của vị từ. Do đó, đường dẫn lấy nhánh thực
sự của nút 5 trong Hình 4.9a phải được thực thi cho tất cả bảy tổ hợp
giá trị chân lý có thể có của OB1, OB2 và OB3 dẫn đến OB = True.
Một tình huống tương tự cũng xảy ra đối với CFG một phần được thể
hiện trong Hình 4.9b, trong đó AB1, AB2, AB3 và AB là các biến
Boolean.
4.6 ĐẦU VÀO KIỂM TRA PHÁT ĐIỆN
Trong Phần 4.5, chúng tôi đã giải thích khái niệm về các tiêu chí lựa
chọn đường dẫn để bao gồm các khía cạnh nhất định của một chương
trình với một tập hợp các đường dẫn. Các khía cạnh của chương trình
mà chúng tôi xem xét là tất cả các câu lệnh, đánh giá đúng và sai của
từng điều kiện và sự kết hợp của các điều kiện ảnh hưởng đến việc
thực hiện một đường dẫn. Bây giờ, khi đã xác định được một đường
dẫn, câu hỏi đặt ra là làm thế nào để chọn các giá trị đầu vào sao cho
khi chương trình được thực thi với các đầu vào đã chọn, các đường
dẫn đã chọn sẽ được thực thi. Nói cách khác, chúng ta cần xác định
các yếu tố đầu vào để buộc thực hiện các đường dẫn. Trong phần sau,
chúng tôi xác định một số thuật ngữ và đưa ra ví dụ về việc tạo đầu
vào thử nghiệm cho một đường dẫn đã chọn.
1. Vectơ đầu vào: Một vectơ đầu vào là tập hợp tất cả các thực thể dữ
liệu được đọc bởi quy trình mà các giá trị của chúng phải được cố
định trước khi vào quy trình. Các thành viên của một vectơ đầu vào
của một quy trình có thể có các dạng khác nhau như được liệt kê
dưới đây:
 Nhập đối số cho một quy trình
 Các biến và hằng số toàn cục
 Các tập tin
 Nội dung của thanh ghi trong lập trình hợp ngữ
 Kết nối mạng
 Hẹn giờ
Tệp là một phần tử đầu vào phức tạp. Trong một trường hợp, sự tồn
tại đơn thuần của một tệp có thể được coi là đầu vào, trong khi trong
một trường hợp khác, nội dung của tệp được coi là đầu vào. Do đó, ý
tưởng về một vectơ đầu vào tổng quát hơn khái niệm về các đối số
đầu vào của một hàm.
Thí dụ. Một vectơ đầu vào cho openfiles () (Hình 4.3) bao gồm sự
hiện diện hoặc vắng mặt của từng tệp file1, file2 và tệp3.
Thí dụ. Vectơ đầu vào của phương thức ReturnAverage () được hiển
thị trong Hình 4.6 là < value [], AS, MIN, MAX > .
Vị từ: Vị từ là một hàm logic được đánh giá tại một điểm quyết định.
Thí dụ. Cấu trúc ti < AS là vị từ trong nút quyết định 3 của
Hình 4.7.
Thí dụ. OB cấu trúc là vị từ trong nút quyết định 5 của Hình
4.9.
Vị từ đường dẫn: Vị từ đường dẫn là tập hợp các vị từ được liên kết
với một đường dẫn.
Đường dẫn trong Hình 4.10 chỉ ra rằng các nút 3 , 4 , 6 , 7 và 10 là
các nút quyết định. Vị từ liên kết với nút 3 xuất hiện hai lần trong
đường dẫn; trong trường hợp đầu tiên, nó đánh giá là true và trong
trường hợp thứ hai, nó đánh giá là false. Vị từ đường dẫn được liên
kết với đường dẫn đang được xem xét được thể hiện trong Hình 4.11.
Chúng tôi cũng chỉ định đánh giá dự định của các vị từ thành phần
như được tìm thấy trong đặc tả đường dẫn. Ví dụ, chúng tôi chỉ định
giá trị [i] đó! = - 999 phải đánh giá thành true trong vị từ đường dẫn
trong Hình 4.11. Chúng tôi giữ thông tin bổ sung này vì hai lý do
sau:
Trong trường hợp không có thông tin bổ sung này biểu thị đánh giá
dự định của một vị từ, chúng ta sẽ không có cách nào để phân biệt
giữa hai trường hợp của vị từ ti < AS, cụ thể là 3 (T) và 3 (F) , được
liên kết với nút 3 .
1-2-3 (T) -4 (T) -5-6 (T) -7 (T) -8-9-3 (F) -10 (T) -12-13
Hình 4.10 Ví dụ về một đường dẫn từ Hình 4.7.
≡ Đúng sự
ti <NHƯ
thật
value [i]! = -999
≡
value [i]> = MIN
≡ Đúng ,
value [i] <=
Đúng ≡
MAX ti <AS tv>
≡ Đúng Sai
0
≡
Hình 4.11 Vị từ đường dẫn cho đường dẫn trong Hình 4.10.
Chúng ta phải biết liệu các vị từ thành phần riêng lẻ của một vị từ
đường dẫn đánh giá thành true hay false để tạo ra các đầu vào bắt
buộc đường dẫn.
4. Diễn giải vị từ: Vị từ đường dẫn trong Hình 4.11 bao gồm các
phần tử của vectơ đầu vào < value [], AS, MIN, MAX > , một vectơ
của các biến cục bộ < i, ti, tv > và hằng số - 999 . Các biến cục bộ
không hiển thị bên ngoài một hàm nhưng được sử dụng để
• giữ các kết quả trung gian, • trỏ đến các phần tử của mảng, và •
kiểm soát các lần lặp vòng lặp.
Nói cách khác, chúng không đóng vai trò gì trong việc lựa chọn đầu
vào buộc các đường dẫn phải thực thi. Do đó, chúng ta có thể dễ
dàng thay thế tất cả các biến cục bộ trong một vị từ bằng các phần tử
của vectơ đầu vào bằng cách sử dụng ý tưởng thay thế ký hiệu.
Chúng ta hãy xem xét phương pháp thể hiện trong Hình 4.12. Vectơ
đầu vào cho phương thức trong Hình 4.12 được cho bởi < x1, x2 > .
Phương thức xác định một biến cục bộ y và cũng sử dụng các hằng
số 7 và 0. Vị từ
x1 + y> = 0
có thể được viết lại thành
x1 + x2 + 7> = 0
bằng cách thay thế biểu tượng y bằng x 2 + 7. Vị từ được viết lại
x1 + x2 + 7> = 0
chỉ được biểu thị theo vectơ đầu vào < x1, x2 > và vectơ không đổi <
0,7 > . Do đó, diễn giải vị từ được định nghĩa là quá trình thay thế
các phép toán một cách tượng trưng dọc theo một đường dẫn để biểu
thị các vị từ chỉ theo vectơ đầu vào và một vectơ không đổi.
Trong một CFG, có thể có một số đường dẫn khác nhau dẫn đến
điểm quyết định từ nút ban đầu, với mỗi đường dẫn thực hiện các
phép tính khác nhau. Do đó, một vị từ có thể có các cách hiểu khác
nhau tùy thuộc vào cách điều khiển đến vị từ đang xem xét.
public static int SymSub (int x1, int x2) {int y;

y = x2 + 7; if (x1 + y> = 0) return (x2 + y);
else return (x2 - y);
}
Hình 4.12 Phương pháp trong Java để giải thích sự thay thế biểu
tượng [11].
5. Biểu thức vị từ đường dẫn: Một vị từ đường dẫn được thông dịch
được gọi là biểu thức vị từ đường dẫn. Biểu thức vị từ đường dẫn có
các thuộc tính sau:
Nó không chứa các biến cục bộ và chỉ bao gồm các phần tử của
vectơ đầu vào và có thể là vectơ của hằng số.
Nó là một tập hợp các ràng buộc được xây dựng từ các phần tử của
vectơ đầu vào và có thể là một vectơ của hằng số.
Các giá trị đầu vào buộc đường dẫn có thể được tạo ra bằng cách giải
quyết tập hợp các ràng buộc trong một biểu thức vị từ đường dẫn.
Nếu tập hợp các ràng buộc không thể được giải quyết, không tồn tại
đầu vào có thể khiến đường dẫn đã chọn thực thi. Nói cách khác, con
đường đã chọn được cho là không khả thi.
Một đường dẫn không khả thi không có nghĩa là một hoặc nhiều
thành phần của biểu thức vị từ đường dẫn là không thể thỏa mãn. Nó
chỉ đơn giản có nghĩa là tổng số kết hợp của tất cả các thành phần
trong một biểu thức vị từ đường dẫn là không thể thỏa mãn. • Tính
bất khả thi của một biểu thức vị từ đường dẫn gợi ý rằng người ta
xem xét các đường dẫn khác trong nỗ lực đáp ứng tiêu chí lựa chọn
đường dẫn đã chọn.
Thí dụ. Hãy xem xét đường dẫn trong Hình 4.10 từ CFG của Hình
4.7. Bảng 4.7 cho thấy các nút của đường dẫn trong cột 1, mô tả
tương ứng của mỗi nút trong cột 2 và cách diễn giải của mỗi nút
trong cột 3. BẢNG 4.7 Diễn giải vị trí đường dẫn của đường dẫn
trong Hình 4.10.
Interpreted
Node Node Description
Description
1 Input vector:
<value[], AS, MIN,
MAX>
2 i = 0, ti = 0,
3(T) tv = 0, sum = 0 ti<AS 0<AS
4(T) value[i]! = −999 value[0]! = −999
5 ti++ ti = 0+1 = 1
6(T) value[i]> = MIN value[0]> = MIN
7(T) value[i]< = MAX value[0]< =
MAX
8 tv++ tv = 0+1 = 1
sum = sum+value[i] sum =
0+value[0]
=value[0]
i
9 3(F) ++ ti<AS i = 0+1 = 1
1<AS
10(T) tv>0 1>0
12 13 av = (double) sum/tv av = (double)
return(av) value[0]/1
return(value[0])
Lưu ý: Các mục in đậm trong cột 1 biểu thị các vị từ được thông
dịch.
Đánh giá dự định của mỗi vị từ được diễn giải có thể được tìm thấy
trong cột 1 của cùng một hàng.
Chúng tôi chỉ ra biểu thức vị từ đường dẫn của đường dẫn đang được
xem xét trong Hình 4.13 để rõ ràng hơn. Các hàng của Hình 4.13 thu
được từ Bảng 4.11 bằng cách kết hợp từng vị từ được diễn giải trong
cột 3 với đánh giá dự kiến của nó trong cột 1. Bây giờ người đọc có
thể so sánh Hình 4.11 và 4.13 để lưu ý rằng các vị từ trong Hình 4.13
là cách diễn giải của các vị từ tương ứng trong Hình 4.11.
Thí dụ. Chúng tôi chỉ ra trong Hình 4.14 một đường dẫn không khả
thi xuất hiện trong CFG của Hình 4.7. Vị từ đường dẫn và cách diễn
giải của nó được thể hiện trong Bảng 4.8, và biểu thức vị từ đường
dẫn được thể hiện trong Hình 4.15. Biểu thức vị từ đường dẫn không
thể giải được vì ràng buộc 0 > 0 ≡ True là không thể thỏa mãn. Do
đó, đường dẫn trong Hình 4.14 là một đường dẫn không khả thi.
Hình 4.13 Biểu thức vị từ đường dẫn cho đường dẫn trong Hình
4.10.
1-2-3 (T) -4 (F) -10 (T) -12-13.
Hình 4.14 Một đường dẫn ví dụ khác từ Hình 4.7.
BẢNG 4.8 Giải thích về vị từ của đường dẫn trong hình 4.14.
Interpreted
Node Node Description
Description
1 Input vector:
<value[], AS, MIN,
MAX>
2 i = 0, ti = 0,
3(T) tv = 0, sum = 0 ti<AS 0<AS
4(F) value[i]! = −999 tv>0
value[0]! = −999
10(T) 0>0
12 13 av = (double)sum/tv av =
return(av) (double)value[0]/0
return((double)
value[0]/0)
Lưu ý: Các mục in đậm trong cột 1 biểu thị các vị từ được thông
dịch.
≡ True ........ (1)True ........
0 < AS
(2)
value[0] != -999
≡
0>0
≡ True ........ (3)
Hình 4.15 Biểu thức vị từ đường dẫn cho đường dẫn trong Hình
4.14.
AS = 1
MIN = 25
MAX = 35 giá trị [0] = 30
Hình 4.16 Dữ liệu đầu vào thỏa mãn các ràng buộc của Hình
4.13.
6. Tạo dữ liệu đầu vào từ biểu thức vị từ đường dẫn: Chúng ta phải
giải biểu thức vị từ đường dẫn tương ứng để tạo ra dữ liệu đầu vào có
thể buộc chương trình thực hiện một đường dẫn đã chọn. Chúng ta
hãy xem xét biểu thức vị từ đường dẫn trong hình 4.13. Chúng tôi
quan sát thấy rằng ràng buộc 1 luôn được thỏa mãn. Các ràng buộc 1
và 5 phải được giải cùng nhau để có được AS = 1. Tương tự, các
ràng buộc 2, 3 và 4 phải được giải cùng nhau. Chúng tôi lưu ý rằng
MIN <= value [0] <= MAX và value [0]! = - 999. Do đó, chúng ta có
nhiều lựa chọn để chọn các giá trị MIN, MAX và giá trị [0]. Một ví
dụ về các giải pháp của các ràng buộc của Hình 4.13 được thể hiện
trong Hình 4.16.
4.7 VÍ DỤ VỀ LỰA CHỌN DỮ LIỆU THỬ NGHIỆM
Chúng tôi đưa ra các ví dụ về dữ liệu thử nghiệm đã chọn để đạt

được báo cáo đầy đủ và phạm vi chi nhánh. Chúng tôi đưa ra bốn bộ
dữ liệu thử nghiệm trong Bảng 4.9. Hai tập dữ liệu đầu tiên bao gồm
tất cả các câu lệnh của CFG trong Hình 4.7. Tuy nhiên, chúng tôi cần
tất cả bốn bộ dữ liệu thử nghiệm để có phạm vi chi nhánh hoàn
chỉnh.
Nếu chúng ta thực thi phương thức ReturnAverage được hiển thị
trong Hình 4.6 với bốn bộ dữ liệu đầu vào kiểm tra được hiển thị
trong Hình 4.9, thì mỗi câu lệnh của phương thức được thực thi ít
nhất một lần và mọi điều kiện Boolean đánh giá một lần thành true
và
BẢNG 4.9 Dữ liệu kiểm tra cho báo cáo và phạm vi nhánh
Véc
tơ
Tập đầu
dữ vào
liệu T
thử BẰ MI ỐI
giá trị[]
nghi NG N Đ
ệm A
1 1 5 20 [10]
2 1 5 20
3 1 5 20
4 1 5 20 [25]
167
4.8 CHỨA CÁC BỆNH NHÂN KHÔNG DỄ DÀNG
một lần thành sai. Chúng tôi đã thử nghiệm kỹ lưỡng phương pháp
với ý nghĩa là toàn bộ chi nhánh. Tuy nhiên, có thể đưa ra các lỗi đơn
giản trong phương pháp mà có thể không bị phát hiện khi phương
pháp với bốn bộ dữ liệu thử nghiệm ở trên được thực thi. Hai ví dụ về
chèn lỗi được đưa ra dưới đây. Thí dụ. Chúng ta thay thế câu lệnh
đúng av = (double) sum / tv;
với một tuyên bố bị lỗi
av = (gấp đôi) sum / ti;
trong phương pháp. Ở đây lỗi là phương pháp tính giá trị trung bình
của tổng số đầu vào, được ký hiệu bằng ti, thay vì tổng số đầu vào
hợp lệ, được ký hiệu bằng tv.
Thí dụ. Chúng tôi thay thế câu lệnh đúng
sum = sum + value [i];
với một tuyên bố bị lỗi
sum = value [i]; trong phương pháp. Ở đây lỗi là phương thức không
còn tính toán tổng của tất cả các đầu vào hợp lệ trong mảng. Mặc dù
có lỗi, tập dữ liệu thử nghiệm đầu tiên cho kết quả chính xác do tính
đúng ngẫu nhiên.
Hai ví dụ về lỗi ở trên dẫn chúng ta đến các kết luận sau: • Người ta
phải tạo ra dữ liệu thử nghiệm để đáp ứng các tiêu chí lựa chọn nhất
định, bởi vì các tiêu chí lựa chọn đó xác định các khía cạnh của
chương trình mà chúng ta muốn đề cập.
Các thử nghiệm bổ sung, dài hơn nhiều so với các thử nghiệm đơn
giản được tạo ra để đáp ứng các tiêu chí về phạm vi bảo hiểm, phải
được tạo sau khi các tiêu chí về phạm vi bảo hiểm đã được đáp ứng.
Đưa ra một tập hợp dữ liệu thử nghiệm cho một chương trình, chúng
ta có thể đưa các lỗi vào chương trình mà các trường hợp thử nghiệm
đó không bị phát hiện.
4.8 CHỨA CÁC BỆNH NHÂN KHÔNG DỄ DÀNG
Woodward, Hedley và Hennell [12] đã xác định được một số vấn đề

thực tế trong việc áp dụng ý tưởng kiểm tra đường đi. Đầu tiên, một
CFG có thể chứa một số lượng rất lớn các đường dẫn; do đó, thách
thức trước mắt là quyết định chọn đường dẫn nào để lấy các trường
hợp thử nghiệm. Thứ hai, có thể không khả thi khi thực hiện nhiều
đường dẫn đã chọn. Vì vậy, sẽ rất hữu ích khi áp dụng chiến lược lựa
chọn đường đi: Thứ nhất, chọn càng nhiều đường đi càng ngắn càng
khả thi; tiếp theo, chọn các đường dẫn dài hơn để đạt được mức độ
bao phủ tốt hơn của các câu lệnh, nhánh và vị từ. Một số lượng lớn
các đường dẫn không khả thi trong CFG làm phức tạp quá trình lựa
chọn thử nghiệm. Để đơn giản hóa kiểm thử đơn vị dựa trên đường
dẫn, sẽ hữu ích khi giảm số lượng đường dẫn không khả thi trong một
đơn vị chương trình thông qua thiết kế ngôn ngữ, thiết kế chương
trình và chuyển đổi chương trình. Brown và Nelson [13] đã chứng
minh khả năng viết mã không có đường dẫn khả thi.
Bertolino và Marre [14] đã đưa ra một thuật toán để tạo ra một tập
hợp các đường dẫn, để bao gồm tất cả các nhánh của một CFG, nhằm
giảm số lượng các đường dẫn không khả thi trong tập hợp đã chọn.
Thuật toán của họ dựa trên ý tưởng về một đồ thị dòng chảy giảm,
được gọi là ddgraph. Thuật toán sử dụng các khái niệm về sự thống
trị và hàm ý giữa các cung của một ddgraph.
Yates và Malevris [15] đã đề xuất một chiến lược để giảm số lượng
các con đường không khả thi trong một tập hợp các con đường để đạt
được độ bao phủ chi nhánh. Họ đề xuất chọn một bìa đường dẫn,
nghĩa là, một tập hợp các đường dẫn, mỗi đường dẫn cấu thành của
chúng bao gồm một số vị từ tối thiểu. Ngược lại, nếu một đường dẫn
liên quan đến một số lượng lớn các vị từ, ít có khả năng tất cả các vị
từ đồng thời giữ, do đó làm cho đường dẫn không khả thi. Họ đã
chứng minh một cách thống kê hiệu quả của chiến lược.
Phép đo độ phức tạp chu kỳ [16] của McCabe (Bảng 3.3) đưa ra cách
giải thích lý thuyết đồ thị thú vị về đồ thị dòng chương trình. Nếu
chúng ta coi các phép đo độ phức tạp theo chu kỳ là các đường dẫn
trong biểu đồ dòng chảy, thì có khả năng là một số đường dẫn không
khả thi sẽ được xây dựng. Cuộc thảo luận trên đưa chúng ta đến kết
luận rằng mặc dù ý tưởng về phạm vi báo cáo và phạm vi chi nhánh
có vẻ đơn giản và dễ hiểu, không dễ dàng để đạt được đầy đủ các tiêu
chí về phạm vi bao phủ đó ngay cả đối với các chương trình nhỏ.
4.9 TÓM TẮT
Khái niệm về một đường dẫn trong một đơn vị chương trình là một
khái niệm cơ bản. Giả sử rằng một đơn vị chương trình là một hàm,
một đường dẫn là một chuỗi các lệnh có thể thực thi được từ khi bắt
đầu thực thi hàm đến một câu lệnh trả về trong hàm. Nếu không có
169
điều kiện phân nhánh trong một đơn vị chương trình, thì chỉ có một
đường dẫn trong hàm. Nói chung, có nhiều điều kiện phân nhánh
trong một đơn vị chương trình, và do đó có nhiều đường dẫn. Một
đường dẫn khác với đường dẫn khác bởi ít nhất một chỉ dẫn. Một
đường dẫn có thể chứa một hoặc nhiều vòng lặp, nhưng cuối cùng,
một đường dẫn dự kiến sẽ kết thúc quá trình thực thi của nó. Do đó,
một đường dẫn có độ dài hữu hạn về số lượng lệnh mà nó thực hiện.
Người ta có thể có một biểu diễn đồ họa của một đơn vị chương trình,
được gọi là biểu đồ luồng điều khiển, để nắm bắt khái niệm về luồng
điều khiển trong đơn vị chương trình.
Mỗi đường dẫn tương ứng với một hành vi riêng biệt của đơn vị
chương trình, và do đó chúng ta cần kiểm tra mỗi đường dẫn với ít
nhất một trường hợp thử nghiệm. Nếu có một số lượng lớn các đường
dẫn trong một chương trình, một lập trình viên có thể không có đủ
thời gian để kiểm tra tất cả các đường dẫn. Do đó, cần phải chọn một
vài đường dẫn bằng cách sử dụng một số tiêu chí lựa chọn đường
dẫn. Tiêu chí lựa chọn đường dẫn cho phép chúng ta chọn một vài
đường dẫn để đạt được một loại phạm vi bảo hiểm nhất định của các
đơn vị chương trình. Một số chỉ số mức độ phù hợp nổi tiếng là mức
độ phù hợp của tuyên bố, mức độ chi nhánh và mức độ bao phủ vị từ.
Một số đường dẫn nhất định được chọn từ CFG để đạt được mức độ
bao phủ mong muốn của một đơn vị chương trình. Ở cấp độ trừu
tượng, mỗi đường dẫn bao gồm một chuỗi các vị từ và các câu lệnh
gán (tính toán). Các vị từ có thể là hàm của các biến cục bộ, toàn cục
các biến và hằng số, và những biến đó được gọi là vị từ đường dẫn.
Tất cả các biến vị ngữ dọc theo đường dẫn phải đánh giá thành true
khi điều khiển đến các biến vị ngữ để một đường dẫn có thể thực thi
được. Người ta phải chọn các đầu vào, được gọi là đầu vào buộc
đường dẫn, sao cho các biến vị ngữ đường dẫn đánh giá là true để có
thể thực hiện đường dẫn. Quá trình lựa chọn đầu vào bắt buộc đường
dẫn liên quan đến việc chuyển đổi các biến vị ngữ đường dẫn thành
một dạng không có biến cục bộ. Dạng vị từ đường dẫn như vậy được
gọi là biểu thức vị từ đường dẫn. Biểu thức vị từ đường dẫn chỉ bao
gồm vectơ đầu vào và có thể là vectơ hằng số. Người ta có thể tạo ra
các giá trị của vectơ đầu vào, được coi như một trường hợp kiểm tra,
để thực hiện một đường dẫn bằng cách giải biểu thức vị từ đường dẫn
tương ứng. Các công cụ đang được thiết kế để tạo đầu vào kiểm tra từ
các đơn vị chương trình.
Nếu một đơn vị chương trình thực hiện các cuộc gọi hàm, có thể các
vị từ đường dẫn là hàm của các giá trị được trả về bởi các hàm đó.
Trong trường hợp như vậy, có thể khó giải quyết một biểu thức vị từ
đường dẫn để tạo các trường hợp thử nghiệm. Kiểm tra đường dẫn có
thể áp dụng cho các đơn vị chương trình cấp thấp hơn so với các đơn
vị chương trình cấp trên có chứa nhiều lệnh gọi hàm.
Clarke [3] mô tả một hệ thống tự động để tạo dữ liệu thử nghiệm từ

các chương trình FORTRAN. Hệ thống dựa trên ý tưởng về việc lựa
chọn các đường dẫn chương trình, xác định các điều kiện đường dẫn
và giải quyết các điều kiện đó để tạo ra các đầu vào. Khi chương trình
được thực hiện với các đầu vào đã chọn, các đường dẫn tương ứng sẽ
được thực thi. Tự động tạo đầu vào kiểm tra là một nhiệm vụ khó
khăn. Vấn đề chung của việc tạo thử nghiệm từ mã nguồn là một vấn
đề nan giải. Để giảm thiểu vấn đề, đã có những đề xuất chọn đường
dẫn theo những cách nhất định. Ví dụ: chọn các đường dẫn thực hiện
các vòng lặp trong một số lần bị hạn chế. Tương tự, hãy chọn các
đường dẫn được giới hạn cho số lượng câu lệnh tối đa. Điều này là do
các đường dẫn dài hơn có thể có nhiều vị từ hơn và có khả năng phức
tạp hơn. Hệ thống tạo đầu vào kiểm tra cho các đường dẫn có thể
được mô tả bằng một tập hợp các ràng buộc đường dẫn tuyến tính.
Các sinh viên được khuyến khích đọc hướng dẫn của JC Huang có
tựa đề “Cách tiếp cận để kiểm tra chương trình”, Khảo sát điện toán
ACM, Vol. 8, số 3, tháng 9 năm 1975, trang 113–128. Bài viết này
thảo luận về một phương pháp xác định các điều kiện đường dẫn để
cho phép đạt được phạm vi bao phủ chi nhánh. Nó giới thiệu cho
người đọc ký hiệu phép tính vị từ để biểu thị các điều kiện đường đi.
Ramamoorthy, Ho, và Chen [7] thảo luận về tính hữu ích của việc
thay thế biểu tượng trong việc tạo ra các vị từ đường dẫn để kiểm tra
một đường dẫn. Tham chiếu mảng là một vấn đề lớn trong thay thế
ký hiệu vì các giá trị chỉ mục có thể không được biết trong quá trình
thực thi ký hiệu. Các tham chiếu đến mảng được ghi lại trong một
bảng trong khi thực hiện ký hiệu và sự không rõ ràng được giải quyết
171
khi đầu vào kiểm tra được tạo để đánh giá các biểu thức chỉ số con.
Một vấn đề lớn khác là xác định số lần thực hiện một vòng lặp.
Xem xét rằng việc thực thi biểu tượng đòi hỏi các thao tác đại số
phức tạp, Korel [17] đã đề xuất một ý tưởng thay thế dựa trên việc
thực thi chương trình thực tế đang được thử nghiệm, các phương
pháp tối thiểu hóa hàm và phân tích luồng dữ liệu. Dữ liệu kiểm tra
được thu thập cho chương trình bằng cách sử dụng các giá trị cụ thể
của các biến đầu vào. Luồng điều khiển của chương trình được giám
sát trong khi thực hiện chương trình. Nếu một quá trình thực thi, tức
là, một đường dẫn chương trình, là một điều không mong muốn, thì
các thuật toán tối thiểu hóa hàm được sử dụng để xác định các giá trị
của các biến đầu vào khiến đường dẫn không mong muốn được thực
thi. Trong cách tiếp cận này, các giá trị của chỉ số mảng và con trỏ
được biết trước ở mỗi bước thực hiện chương trình. Do đó, cách tiếp
cận này giúp chúng ta khắc phục những khó khăn trong việc xử lý
mảng và con trỏ.
Một cuốn sách tuyệt vời về kiểm thử chương trình dựa trên đường
dẫn là Kỹ thuật kiểm thử phần mềm của Beizer [5]. Người đọc có thể
tìm thấy nhiều điều hơn nữa thông qua việc xử lý chủ đề trong cuốn
sách nói trên.
Công cụ kiểm tra của ParaSoft [9] cho phép các lập trình viên thực
hiện kiểm tra dựa trên luồng đối với các đơn vị chương trình được
viết bằng C, C ++ và Java. Nếu một đơn vị chương trình đang được
kiểm tra gọi một đơn vị chương trình khác, công cụ sẽ tạo một bản
gốc thay thế cho đơn vị được gọi. Nếu một lập trình viên muốn kiểm
soát những giá trị trả về nào được sử dụng, họ có thể tạo một bảng sơ
khai xác định ánh xạ đầu vào - kết quả.
CHAPTER
5
DataFlowTesting
Một sai sót không trở thành sự thật bởi lý do của sự lan truyền nhân
rộng, cũng như sự thật không trở thành sai lầm bởi vì không ai nhìn
thấy nó. -Tên người
5.1 Ý TƯỞNG CHUNG
Một đơn vị chương trình, chẳng hạn như một hàm, chấp nhận các giá
trị đầu vào, thực hiện các phép tính trong khi gán các giá trị mới cho
các biến cục bộ và toàn cục, và cuối cùng, tạo ra các giá trị đầu ra.
Do đó, người ta có thể hình dung một loại "luồng" giá trị dữ liệu giữa
các biến dọc theo đường dẫn thực thi chương trình. Một giá trị dữ
liệu được tính toán trong một bước thực thi chương trình nhất định sẽ
được sử dụng trong bước sau. Ví dụ, một chương trình có thể mở một
tệp, do đó nhận được giá trị cho một con trỏ tệp; trong bước sau, con
trỏ tệp dự kiến sẽ được sử dụng. Theo trực giác, nếu việc sử dụng
con trỏ tệp sau này không bao giờ được xác minh, thì chúng ta không
biết liệu việc gán giá trị trước đó cho biến con trỏ tệp có ổn hay
không. Đôi khi, một biến có thể được xác định hai lần mà không cần
sử dụng biến ở giữa. Người ta có thể thắc mắc tại sao định nghĩa đầu
tiên của biến không bao giờ được sử dụng. Có hai động lực để kiểm
tra luồng dữ liệu như sau. Đầu tiên, một vị trí bộ nhớ tương ứng với
một biến chương trình được truy cập theo cách mong muốn. Ví dụ,
một vị trí bộ nhớ có thể không được đọc trước khi ghi vào vị trí đó.
Thứ hai, bạn nên xác minh tính đúng đắn của giá trị dữ liệu được tạo
cho một biến — điều này được thực hiện bằng cách quan sát rằng tất
cả các cách sử dụng của giá trị đều tạo ra kết quả mong muốn.
Ý tưởng cơ bản ở trên về kiểm tra luồng dữ liệu cho chúng ta biết
rằng một lập trình viên có thể thực hiện một số thử nghiệm trên các
giá trị dữ liệu, được gọi chung là kiểm tra luồng dữ liệu. Kiểm thử
luồng dữ liệu có thể được thực hiện ở hai cấp độ khái niệm: thử
nghiệm luồng dữ liệu tĩnh và thử nghiệm luồng dữ liệu động. Như
173
tên cho thấy, kiểm tra luồng dữ liệu tĩnh được thực hiện bằng cách
phân tích mã nguồn và nó không liên quan đến việc thực thi mã
nguồn thực tế. Kiểm tra luồng dữ liệu tĩnh được thực hiện để phát
hiện ra các khiếm khuyết tiềm ẩn trong các chương trình. Các lỗi
chương trình tiềm ẩn thường được gọi là dữ liệu
112
5.2 PHÂN TÍCH LƯU CHUYỂN DỮ LIỆU
dòng chảy bất thường. Mặt khác, kiểm tra luồng dữ liệu động liên
quan đến việc xác định các đường dẫn chương trình từ mã nguồn dựa
trên một lớp tiêu chí kiểm tra luồng dữ liệu.
Người đọc có thể lưu ý rằng có nhiều điểm tương đồng giữa thử
nghiệm luồng điều khiển và thử nghiệm luồng dữ liệu. Hơn nữa, có
một sự khác biệt chính giữa hai cách tiếp cận. Những điểm tương
đồng bắt nguồn từ thực tế là cả hai cách tiếp cận đều xác định các
đường dẫn chương trình và nhấn mạnh vào việc tạo các trường hợp
thử nghiệm từ các đường dẫn chương trình đó. Sự khác biệt giữa hai
phương pháp này nằm ở chỗ các tiêu chí lựa chọn thử nghiệm dòng
kiểm soát được sử dụng trong phương pháp trước, trong khi các tiêu
chí lựa chọn thử nghiệm dòng dữ liệu được sử dụng trong phương
pháp sau.
Trong chương này, trước tiên chúng ta nghiên cứu khái niệm dị
thường của luồng dữ liệu được xác định bởi Fosdick và Osterweil
[1]. Tiếp theo, chúng ta thảo luận chi tiết về kiểm tra luồng dữ liệu
động.
5.2 PHÂN TÍCH LƯU CHUYỂN DỮ LIỆU
Dị thường là một cách làm điều gì đó lệch lạc hoặc không bình
thường. Ví dụ, đây là một tình huống bất thường khi gán liên tiếp hai
giá trị cho một biến mà không sử dụng giá trị đầu tiên. Tương tự,
việc sử dụng giá trị của một biến trước khi gán giá trị cho biến là
điều bất thường. Một tình huống bất thường khác là tạo ra một giá trị
dữ liệu và không bao giờ sử dụng nó. Sau đây, chúng tôi giải thích ba
loại tình huống bất thường liên quan đến việc tạo và sử dụng các giá
174 CHƯƠNG 5 KIỂM TRA DÒNG DỮ LIỆU
trị dữ liệu. Ba tình huống bất thường được gọi là dị thường loại 1 ,
loại 2 và loại 3 [1]. Những bất thường này có thể là biểu hiện của các
lỗi lập trình tiềm ẩn. Chúng tôi sẽ giải thích lý do tại sao sự bất
thường của chương trình không cần thiết dẫn đến lỗi chương trình.
Được xác định và sau đó được xác định lại (Loại 1): Xem xét chuỗi
tính toán từng phần được thể hiện trong Hình 5.1, trong đó f1 (y) và
f2 (z) biểu thị các hàm với đầu vào y và z tương ứng. Chúng ta có thể
giải thích hai câu lệnh trong Hình 5.1 theo một số cách như sau:
Tính toán được thực hiện bởi câu lệnh đầu tiên là dư thừa nếu câu
lệnh thứ hai thực hiện tính toán dự định.
Câu lệnh đầu tiên có lỗi. Ví dụ, phép tính đầu tiên dự định có thể là
w = f1 (y).
Câu lệnh thứ hai có lỗi. Ví dụ, phép tính thứ hai dự định có thể là v =
f2 (z).
Loại lỗi thứ tư có thể xuất hiện trong trình tự đã cho dưới dạng một
câu lệnh thiếu giữa hai lỗi. Ví dụ, v = f3 (x) có thể là câu lệnh mong
muốn nằm giữa hai câu lệnh đã cho.
:
x = f1 (y) x
= f2 (z)
:
Hình 5.1 Trình tự tính toán cho thấy sự bất thường của luồng
dữ liệu.
Người lập trình phải đưa ra cách diễn giải mong muốn, mặc dù người
ta có thể diễn giải hai câu lệnh đã cho theo một số cách, Tuy nhiên,
có thể nói rằng có một sự bất thường về luồng dữ liệu trong hai câu
lệnh đó, cho thấy rằng chúng cần được kiểm tra để loại bỏ bất kỳ sự
nhầm lẫn nào trong tâm trí của người đọc mã.
Không xác định nhưng được tham chiếu (Loại 2): Dạng bất thường
thứ hai của luồng dữ liệu là sử dụng biến không xác định trong tính
toán, chẳng hạn như x = x - y −w , trong đó biến w chưa được khởi
tạo bởi lập trình viên. Ở đây, người ta có thể tranh luận rằng mặc dù
w chưa được khởi tạo, lập trình viên dự định sử dụng một biến khởi
tạo khác, chẳng hạn như y, thay cho w . Dù ý định thực sự của lập
trình viên có thể là gì đi nữa thì cũng tồn tại sự bất thường trong việc
sử dụng biến w và người ta phải loại bỏ sự bất thường đó bằng cách
khởi tạo w hoặc thay thế w bằng biến dự định.
175
Đã xác định nhưng không được tham chiếu (Loại 3): Loại bất thường
thứ ba của luồng dữ liệu là xác định một biến và sau đó hủy xác định
nó mà không sử dụng nó trong bất kỳ tính toán tiếp theo nào. Ví dụ,
hãy xem xét câu lệnh x = f (x, y) trong đó một giá trị mới được gán
cho biến x. Nếu giá trị của x không được sử dụng trong bất kỳ phép
tính tiếp theo nào, thì chúng ta nên nghi ngờ về phép tính được biểu
diễn bởi x = f (x, y). Do đó, dạng bất thường này được gọi là "được
xác định nhưng không được tham chiếu."
Huang [2] đã giới thiệu ý tưởng về "trạng thái" của các biến chương
trình để xác định sự bất thường của luồng dữ liệu. Ví dụ, ban đầu,
một biến có thể vẫn ở trạng thái “không xác định” (U), nghĩa là chỉ
một vị trí bộ nhớ đã được cấp cho biến nhưng chưa có giá trị nào
được gán. Sau đó, người lập trình có thể thực hiện tính toán để xác
định (d) biến dưới dạng gán giá trị cho biến — đây là khi biến
chuyển sang trạng thái “được xác định nhưng không được tham
chiếu” (D). Sau đó, lập trình viên có thể tham chiếu (r), nghĩa là đọc,
giá trị của biến, do đó chuyển biến sang trạng thái “được xác định và
tham chiếu” (R). Biến vẫn ở trạng thái R miễn là người lập trình tiếp
tục tham chiếu đến giá trị của biến. Nếu người lập trình gán một giá
trị mới cho biến, biến đó sẽ chuyển về trạng thái D. Mặt khác, lập
trình viên có thể thực hiện một hành động để hủy xác định (u) biến.
Ví dụ: nếu một tệp đã mở bị đóng, giá trị của con trỏ tệp sẽ không
được hệ điều hành cơ bản nhận dạng nữa, và do đó con trỏ tệp trở
thành không xác định. Các kịch bản trên mô tả các hành động bình
thường trên các biến và được minh họa trong Hình 5.2.
Tuy nhiên, các lập trình viên có thể mắc sai lầm khi thực hiện các
hành động sai khi một biến ở trạng thái nhất định. Ví dụ, nếu một
biến ở trạng thái U — tức là, biến đó vẫn chưa được xác định — và
một lập trình viên đọc (r) biến đó, thì biến đó sẽ chuyển sang trạng
thái (A) bất thường. Trạng thái bất thường của một biến có nghĩa là
một sự bất thường trong lập trình đã xảy ra. Tương tự, trong khi một
biến ở trạng thái D và người lập trình không xác định (u) biến hoặc
xác định lại (d) biến, thì biến đó sẽ chuyển sang trạng thái (A) bất
thường. Khi một biến đi vào trạng thái bất thường, nó vẫn ở trạng
thái đó bất kể hành động nào — d, u hoặc r —được thực hiện. Các
hành động đưa một biến từ trạng thái mong muốn, chẳng hạn như U
hoặc D, sang trạng thái bất thường được minh họa trong Hình 5.2.
5.3 TỔNG QUAN VỀ KIỂM TRA DÒNG DỮ LIỆU ĐỘNG

u
d
U D R
d r r
u
d, u
r
A
d, u, r
Truyền thuyết:
Những trạng thái Hành
động
U: Không xác định d: Xác
D: Được xác định nhưng khôngđịnh r:
được tham chiếu Tham
R: Được xác định và tham chiếu chiếu
A: Bất thường u:
Không
xác
định
Hình 5.2 Biểu đồ chuyển trạng thái của một biến chương trình.
(Từ bản tham khảo 2. © 1979 IEEE.)
Bây giờ rất hữu ích để tạo mối liên hệ giữa các dị thường loại 1 , loại
2 và loại 3 và sơ đồ chuyển trạng thái được thể hiện trong Hình 5.2.
Các dị thường loại 1 , loại 2 và loại 3 được biểu thị bằng các chuỗi
hành động dd, ur và du, tương ứng, trong Hình 5.2.
Sự bất thường của luồng dữ liệu có thể được phát hiện bằng cách sử
dụng ý tưởng về thiết bị đo đạc chương trình. Nói một cách trực
quan, thiết bị đo chương trình có nghĩa là kết hợp mã bổ sung vào
một chương trình để theo dõi trạng thái thực thi của nó. Ví dụ, chúng
ta có thể viết mã bổ sung trong một chương trình để theo dõi chuỗi
trạng thái, cụ thể là U, D, R và A, được duyệt qua bởi một biến. Nếu
chuỗi trạng thái chứa dãy con dd, ur và du, thì một sự bất thường của
luồng dữ liệu được cho là đã xảy ra.
Sự hiện diện của luồng dữ liệu bất thường trong chương trình không
nhất thiết có nghĩa là việc thực thi chương trình sẽ dẫn đến thất bại.
Sự bất thường của luồng dữ liệu chỉ đơn giản có nghĩa là chương
177
trình có thể bị lỗi, và do đó lập trình viên phải điều tra nguyên nhân
của sự bất thường đó. Chúng ta hãy xem xét sự bất thường của dd
trong hình 5.1. Nếu mục đích thực sự của lập trình viên là thực hiện
phép tính thứ hai và phép tính đầu tiên không tạo ra tác dụng phụ, thì
phép tính đầu tiên chỉ thể hiện sự lãng phí sức mạnh xử lý. Do đó, sự
bất thường dd nói trên sẽ không dẫn đến lỗi chương trình. Mặt khác,
nếu thiếu một câu lệnh ở giữa hai câu lệnh, thì chương trình có thể
dẫn đến lỗi. Các lập trình viên phải phân tích nguyên nhân của sự bất
thường của luồng dữ liệu và loại bỏ chúng.
5.3 TỔNG QUAN VỀ KIỂM TRA DÒNG DỮ LIỆU ĐỘNG
Trong quá trình viết mã, một lập trình viên thao tác với các biến để
đạt được hiệu quả tính toán mong muốn. Thao tác với biến xảy ra
theo một số cách, chẳng hạn như khởi tạo biến, gán giá trị mới cho
biến, tính toán giá trị của một biến khác bằng cách sử dụng giá trị của
biến và kiểm soát luồng thực thi chương trình.
Rapps và Weyuker [3] nói với chúng ta một cách thuyết phục rằng
chúng ta không nên cảm thấy tự tin rằng một biến đã được gán giá trị
chính xác nếu không có trường hợp kiểm thử nào gây ra việc thực
hiện một đường dẫn từ phép gán đến một điểm mà giá trị của biến
được sử dụng. Trong động cơ ở trên để kiểm tra luồng dữ liệu, (i)
việc ấn định một giá trị chính xác có nghĩa là liệu một giá trị cho biến
đã được tạo chính xác hay chưa và (ii) việc sử dụng một biến đề cập
đến việc tạo thêm các giá trị cho cùng một biến hoặc các biến khác
và / hoặc kiểm soát dòng chảy. Một biến có thể được sử dụng trong
một vị từ, nghĩa là, một điều kiện, để chọn một luồng điều khiển
thích hợp.
Ý tưởng trên cho chúng ta một dấu hiệu về sự tham gia của một số
loại đường dẫn chương trình nhất định trong kiểm thử luồng dữ liệu.
Kiểm tra luồng dữ liệu bao gồm việc lựa chọn các đường dẫn vào - ra
với mục tiêu bao gồm các mẫu sử dụng và định nghĩa dữ liệu nhất
định, thường được gọi là tiêu chí kiểm tra luồng dữ liệu. Cụ thể, các
đường dẫn chương trình nhất định được chọn trên cơ sở các tiêu chí
kiểm tra luồng dữ liệu. Tiếp theo các ý tưởng chung trong kiểm tra
luồng kiểm soát mà chúng ta đã thảo luận trong Chương 4, chúng tôi
đưa ra một phác thảo về việc thực hiện kiểm tra luồng dữ liệu như
sau:
Vẽ biểu đồ luồng dữ liệu từ một chương trình.

Chọn một hoặc nhiều tiêu chí kiểm tra luồng dữ liệu.
Xác định các đường dẫn trong biểu đồ luồng dữ liệu thỏa mãn các
tiêu chí lựa chọn.
Tìm ra các biểu thức vị từ đường dẫn từ các đường dẫn đã chọn và
giải các biểu thức đó để lấy đầu vào kiểm tra.
Người đọc có thể nhớ lại rằng quá trình lấy biểu thức vị từ đường
dẫn từ một đường dẫn đã được giải thích trong Chương 4. Ý tưởng
tương tự cũng áp dụng để lấy biểu thức vị từ đường dẫn từ một
đường dẫn thu được từ biểu đồ luồng dữ liệu. Do đó, trong phần còn
lại của chương này, chúng tôi sẽ giải thích quy trình vẽ biểu đồ luồng
dữ liệu từ một đơn vị chương trình và thảo luận về các tiêu chí kiểm
tra luồng dữ liệu.
5.4 ĐỒ THỊ DỮ LIỆU
Trong phần này, chúng tôi giải thích các ý chính trong biểu đồ luồng
dữ liệu và phương pháp để vẽ nó. Trong thực tế, người lập trình
không thể vẽ biểu đồ luồng dữ liệu bằng tay. Thay vào đó, trình dịch
ngôn ngữ được sửa đổi để tạo ra biểu đồ luồng dữ liệu từ các đơn vị
chương trình. Biểu đồ luồng dữ liệu được vẽ với mục tiêu xác định
các định nghĩa dữ liệu và việc sử dụng chúng như được thúc đẩy
trong phần trước. Mỗi lần xuất hiện của một biến dữ liệu được phân
loại như sau:
Định nghĩa: Điều này xảy ra khi một giá trị được di chuyển vào vị trí
bộ nhớ của biến. Tham chiếu đến hàm C VarTypes () trong Hình 5.3,
câu lệnh gán i = x; là một ví dụ về định nghĩa của biến i.
Undefinition hoặc Kill: Điều này xảy ra khi giá trị và vị trí không bị
ràng buộc. Đề cập đến hàm C VarTypes (), đầu tiên
(iptr = malloc (sizeof (int));
5.4 ĐỒ THỊ DỮ LIỆU
Hình 5.3 Định nghĩa và sử dụng các biến.
câu lệnh khởi tạo biến con trỏ số nguyên iptr và
iptr = i + x;
khởi tạo giá trị của vị trí được trỏ tới bởi iptr. Iptr thứ hai = malloc
(sizeof (int));
câu lệnh xác định lại biến iptr, do đó xác định lại vị trí đã được iptr
trỏ tới trước đó.
179
Sử dụng: Điều này xảy ra khi giá trị được tìm nạp từ vị trí bộ nhớ của
biến. Có hai hình thức sử dụng của một biến như được giải thích bên
dưới.
Sử dụng tính toán (c-use): Điều này ảnh hưởng trực tiếp đến quá
trình tính toán đang được thực hiện. Trong c-use, một giá trị mới
tiềm năng của một biến khác hoặc của cùng một biến được tạo ra.
Tham chiếu đến hàm C VarTypes (), câu lệnh
* iptr = i + x;
đưa ra các ví dụ về việc sử dụng c của các biến i và x.
Sử dụng vị từ (p-use): Điều này đề cập đến việc sử dụng một biến
trong một vị từ kiểm soát luồng thực thi. Tham chiếu đến hàm C
VarTypes (), câu lệnh
if (* iptr> y) ... đưa ra các ví dụ về cách sử dụng p của các biến y và
iptr.
Biểu đồ luồng dữ liệu là một biểu đồ có hướng được xây dựng như
sau:
Một chuỗi các định nghĩa và cách sử dụng c được liên kết với mỗi
nút của biểu đồ.
Một tập hợp các công dụng p được liên kết với mỗi cạnh của đồ thị.
Nút nhập có định nghĩa của từng tham số và từng biến phi địa
phương xuất hiện trong chương trình con.
Nút thoát có một định nghĩa của mỗi biến cục bộ.
Ví dụ: Chúng tôi hiển thị biểu đồ luồng dữ liệu trong Hình 5.4 cho ví
dụ ReturnAverage () được thảo luận trong Chương 4, Nút ban đầu,
nút 1 , đại diện cho việc khởi tạo vectơ đầu vào < value, AS, MIN,
MAX > . Nút 2 đại diện cho việc khởi tạo bốn biến cục bộ i, ti, tv và
sum trong quy trình. Tiếp theo, chúng tôi giới thiệu một nút NULL,
nút 3 , hãy nhớ rằng điều khiển sẽ quay trở lại phần đầu của vòng lặp
while. Nút 3 cũng biểu thị thực tế là điều khiển chương trình thoát
khỏi vòng lặp while tại nút NULL. Câu lệnh ti ++ được biểu diễn bởi
nút 4 . Vị từ được liên kết với cạnh (3, 4) là phần điều kiện của vòng
lặp while, cụ thể là
((ti <AS) && (value [i]! = -999))
Các câu lệnh tv ++ và sum = sum + value [i] được biểu diễn bởi nút 5
.
Do đó, phần điều kiện của câu lệnh if đầu tiên tạo thành vị từ được
liên kết với cạnh (4, 5) , cụ thể là
1 Initialize: value[],
AS, MIN, MAX
True
2 i = 0, ti = 0,
tv = 0, sum = 0
True
3
NULL
~((ti < AS) && ((ti < AS) &&

(value[i] != −999)) (value[i] != −999))
7 4
NULL ti++
~(tv > 0) (tv > 0) ((value[i] >= MIN) &&
(value[i] <= MAX)) ~((value[i] >= MIN) &&
8 9 5
(value[i] <= MAX))
av = (double) tv++
−999 av = (double)sum/tv sum = sum + value[i]
True True True 6

True
10 i++
return(av)
Hình 5.4 Đồ thị luồng dữ liệu của ví dụ ReturnAverage ().

5.5 ĐIỀU KHOẢN LƯU CHUYỂN DỮ LIỆU
((giá trị [i]> = MIN) && (giá trị [i] <= MAX))
Câu lệnh i ++ được biểu diễn bởi nút 6 . Vị từ được kết hợp với cạnh
(4, 6) là sự phủ định của phần điều kiện của câu lệnh if, cụ thể là,
((giá trị [i]> = MIN) && (giá trị [i] <= MAX)).
Vị từ liên kết với cạnh (5, 6) là đúng vì có một luồng điều khiển vô
điều kiện từ nút 5 đến nút 6 . Việc thực thi vòng lặp while kết thúc
khi điều kiện của nó được đánh giá là false. Do đó, vị từ liên kết với
cạnh (3, 7) là sự phủ định của vị từ liên kết với cạnh (3, 4) , cụ thể là,
~
((ti <AS) && (value [i]! = -999))
Có thể lưu ý rằng không có tính toán nào được thực hiện trong một
nút NULL. Đề cập đến câu lệnh if thứ hai, av = (double) - 999 được
biểu thị bởi nút 8 và av = (double) sum / tv được biểu diễn bởi nút 9 .
Do đó, vị từ liên kết với cạnh (7, 9) là
(tv> 0),
và vị từ được liên kết với cạnh (7, 8) là
~
(tv> 0).
181
Cuối cùng, câu lệnh return (av) được biểu diễn bởi nút 10 và vị từ
True được liên kết với cả hai cạnh (7, 8) và (7, 9) .
5.5 ĐIỀU KHOẢN LƯU CHUYỂN DỮ LIỆU
Một biến được định nghĩa trong một câu lệnh được sử dụng trong
một câu lệnh khác có thể xuất hiện ngay lập tức hoặc một số câu lệnh
sau định nghĩa. Chúng tôi quan tâm đến việc tìm kiếm các đường dẫn
bao gồm các cặp định nghĩa và sử dụng các biến. Trong phần này,
chúng tôi giải thích nhóm tiêu chí lựa chọn đường dẫn cho phép
chúng ta chọn các đường dẫn với độ mạnh khác nhau. Người đọc có
thể lưu ý rằng đối với mọi đường dẫn khả thi, chúng ta có thể tạo một
trường hợp thử nghiệm. Trong phần sau, trước tiên chúng tôi giải
thích một số thuật ngữ, sau đó chúng tôi giải thích một số tiêu chí lựa
chọn bằng cách sử dụng các thuật ngữ đó.
Sử dụng c toàn cục: Sử dụng c của một biến x trong nút i được cho là
sử dụng c toàn cục nếu x đã được xác định trước đó trong một nút
khác với nút i.
Ví dụ: Việc sử dụng c của biến tv trong nút 9 là cách sử dụng c toàn
cục vì tv đã được xác định trong các nút 2 và 5 (Hình 5.4).
Định nghĩa Đường dẫn rõ ràng: Đường dẫn (i - n 1 - ··· - n m - j), m ≥
0, được gọi là đường dẫn rõ định nghĩa (đường dẫn rõ ràng) đối với
biến x
từ nút i đến nút j và
từ nút i đến cạnh (n m , j)
nếu x chưa được xác định hoặc chưa được xác định trong các nút n 1 ,
... , n m . Người đọc có thể lưu ý rằng định nghĩa của một đường dẫn
rõ ràng là không quan tâm đến trạng thái của x trong các nút i và j.
Ngoài ra, một đường dẫn rõ ràng không loại trừ các vòng lặp. Do đó,
đường dẫn 2-3-4-6-3-4-6-3-4-5 , bao gồm một vòng lặp, là một
đường dẫn rõ ràng.
Ví dụ: Các đường dẫn 2-3-4-5 và 2-3-4-6 là các đường dẫn rõ ràng
đối với tv biến từ nút 2 đến 5 và từ nút 2 đến nút 6 , tương ứng
(Hình 5.4).
Định nghĩa toàn cục: Một nút i có định nghĩa toàn cục của một biến x
nếu nút i có định nghĩa là x và có một đường dẫn rõ ràng đối với x từ
nút i đến một số
• nút chứa c-use toàn cục hoặc • cạnh chứa p-use of
biến x. Người đọc có thể lưu ý rằng chúng tôi không định nghĩa việc
sử dụng p toàn cục của một biến tương tự như sử dụng c toàn cục.
Điều này là do mọi công dụng p được liên kết với một cạnh — chứ
không phải một nút.
Trong Bảng 5.1, chúng tôi chỉ ra tất cả các định nghĩa toàn cục và c-
use toàn cục xuất hiện trong biểu đồ luồng dữ liệu của Hình 5.4; def
(i) biểu thị tập hợp các biến có định nghĩa toàn cục trong nút i.
Tương tự, c-use (i) biểu thị tập hợp các biến có công dụng c toàn cục
trong nút i. Chúng tôi hiển thị tất cả các vị từ và công dụng p xuất
hiện trong biểu đồ luồng dữ liệu của Hình 5.4 trong Bảng 5.2; vị từ
(i, j) biểu thị vị từ được liên kết với cạnh (i, j) của biểu đồ luồng dữ
liệu trong Hình 5.4; p-use (i, j) biểu thị tập hợp các biến có p-use trên
cạnh (i, j).
Đường dẫn đơn giản: Đường dẫn đơn giản là đường dẫn trong đó tất
cả các nút, ngoại trừ nút đầu tiên và nút cuối cùng, là khác biệt.
BẢNG 5.1 Bộ nút Def () và c-use () trong Hình 5.4
Node
def(i) c-use(i)
si
1 {value, AS, MIN, MAX} {}
2 {i, ti, tv, sum} {}
{} {}
{ti} {ti}
5 { } {tv, i,
sum,
value}
{i}
{i}
{} {}
{av} {}
9 {av} {
}
183
5.6 TIÊU CHÍ KIỂM TRA DÒNG DỮ LIỆU
BẢNG 5.2 Các dự đoán và p-use () Tập hợp các cạnh trong
Hình 5.4
Edges (i, j) predicate(i, j) p-use(i, j)
(1, 2) True {}
(2, 3) True {}
(3, 4) (ti<AS) && (value[i] ! = −999) {i, ti, AS,
value}
(4, 5) (value[i]< = MIN) && (value[i]> ={i, MIN, MAX,
(4, 6) MAX) value}
∼((value[i]< = MIN) && (value[i]> = {i, MIN, MAX,
MAX)) value}
(5, 6) True {}
(6, 3) True {}
(3, 7) ∼((ti<AS) && (value[i] ! = −999)) {i, ti, AS,
(7, 8) ∼(tv>0) value}
{tv}
(7, 9) (tv>0) {tv}
(8, 10) True {}
(9, 10) True {}
Ví dụ: Các đường dẫn 2-3-4-5 và 3-4-6-3 là các đường dẫn đơn
giản (Hình 5.4).
Đường dẫn không có vòng lặp: Đường dẫn không có vòng lặp là
đường dẫn trong đó tất cả các nút đều khác biệt.
Đường dẫn hoàn chỉnh: Đường dẫn hoàn chỉnh là đường dẫn từ nút
vào đến nút thoát.
Du-path: Một đường dẫn (n 1 - n 2 - ··· - n j - n k ) là một đường dẫn sử
dụng định nghĩa (du-path) liên quan đến (wrt) biến x nếu nút n 1 có
định nghĩa toàn cục của x và một trong hai
nút n k có công dụng c toàn cục là x và (n 1 - n 2 - ··· - n j - n k ) là một
đường dẫn đơn giản rõ ràng wrt x hoặc
edge (n j , n k ) có p-sử dụng x và (n 1 - n 2 - ··· - n j ) là một đường dẫn
wrtx rõ ràng, không có vòng lặp
Ví dụ: Xét định nghĩa toàn cục và sử dụng c toàn cục của biến tv
trong các nút 2 và 5 , tương ứng, 2-3-4-5 là một con đường du.
Ví dụ: Xét định nghĩa tổng thể và sử dụng p của biến tv trong các nút
2 và trên cạnh (7, 9) , tương ứng, 2-3-7-9 là một đường đi.
Trong phần này, chúng tôi giải thích bảy loại tiêu chí kiểm tra luồng
dữ liệu. Các tiêu chí này dựa trên hai khái niệm cơ bản, đó là định
nghĩa và cách sử dụng - cả công dụng c và công dụng p - của các
biến.
Tất cả các định nghĩa: Đối với mỗi biến x và cho mỗi nút i sao cho x
có định nghĩa toàn cục trong nút i, hãy chọn một đường dẫn hoàn
chỉnh bao gồm một đường dẫn rõ ràng từ nút i đến
nút j có sử dụng c toàn cục của x hoặc
edge (j, k) có công dụng p của x.
Ví dụ: Hãy xem xét biến tv, có các định nghĩa toàn cục trong các nút
2 và 5 (Hình 5.4 và các Bảng 5.1 và 5.2). Đầu tiên, chúng ta xem xét
định nghĩa toàn cục của nó trong nút 2 . Chúng tôi tìm thấy c-use
toàn cục của tv trong nút 5 và tồn tại một đường dẫn rõ ràng 2-3-4-5
từ nút 2 đến nút 5 . Chúng tôi chọn một đường dẫn hoàn chỉnh 1- 2-
3-4-5-6-3-7-9-10 bao gồm đường dẫn rõ ràng 2-3-4-5 để đáp ứng
tiêu chí tất cả các lỗi. Chúng tôi cũng tìm thấy p-dụng của biến tv
trên cạnh (7, 8) và tồn tại một đường dẫn rõ ràng 2-3-7-8 từ nút 2 đến
cạnh (7, 8) . Chúng tôi chọn một đường dẫn hoàn chỉnh 1- 2-3-7-8-10
bao gồm đường dẫn rõ ràng 2-3-7-8 để đáp ứng tiêu chí tất cả các độ
lệch . Bây giờ chúng ta xem xét định nghĩa của tv trong nút 5 . Trong
nút 9 có sử dụng c toàn cục của tv, và trong các cạnh (7, 8) và (7, 9)
có p-sử dụng tv. Có một đường dẫn rõ ràng 5-6-3-7-9 từ nút 5 đến
nút 9 . Do đó, chúng tôi chọn một đường dẫn hoàn chỉnh 1-2-3-4- 5-
6-3-7-9-10 bao gồm đường dẫn rõ ràng 5-6-3-7-9 để đáp ứng tiêu chí
tất cả các lỗi . Người đọc có thể lưu ý rằng đường dẫn đầy đủ 1-2-3-
4-5-6-3-7-9-10 bao gồm tiêu chí all-defs cho biến tv được xác định
trong các nút 2 và 5 . Để đáp ứng tiêu chí all-defs, phải thu được các
đường dẫn tương tự cho các biến i, ti và sum.
All-c-use: Đối với mỗi biến x và cho mỗi nút i, sao cho x có định
nghĩa toàn cục trong nút i, hãy chọn các đường dẫn hoàn chỉnh bao
gồm các đường dẫn rõ ràng từ nút i đến tất cả các nút j sao cho có
một toàn cục c -sử dụng x trong j.
185
Ví dụ: Hãy để chúng tôi có được các đường dẫn để thỏa mãn tiêu chí
sử dụng tất cả c đối với biến ti. Chúng tôi tìm thấy hai định nghĩa
toàn cục của ti ở nút 2 và 4 . Tương ứng với định nghĩa toàn cục
trong nút 2 , có một c-sử dụng toàn cục của ti trong nút 4 . Tuy nhiên,
tương ứng với định nghĩa toàn cục trong nút 4 , không có c-sử dụng
toàn cục của ti. Từ định nghĩa toàn cục trong nút 2 , có một đường
dẫn rõ ràng đến việc sử dụng c toàn cục trong nút 4 ở dạng 2-3-4 .
Người đọc có thể lưu ý rằng có bốn đường dẫn hoàn chỉnh bao gồm
đường dẫn rõ ràng 2-3-4 như sau:
1- 2-3-4-5-6-3-7-8-10 , _
1- 2-3-4-5-6-3-7-9-10 , _
1- 2-3-4-6-3-7-8-10 và 1- 2-3-4-6-3-7-9-10 . _ _
Người ta có thể chọn một hoặc nhiều đường dẫn trong số bốn đường
dẫn trên để thỏa mãn tiêu chí sử dụng tất cả c liên quan đến biến ti.
Tất cả-p-sử dụng: Đối với mỗi biến x và mỗi nút i sao cho x có định
gồm các đường dẫn rõ ràng từ nút i đến tất cả các cạnh (j, k) sao cho
có một p-sử dụng của x trên cạnh (j, k).
Ví dụ: Hãy để chúng tôi nhận được các đường dẫn để thỏa mãn tiêu
chí sử dụng tất cả p đối với tv biến. Chúng tôi tìm thấy hai định nghĩa
toàn cục của tv trong các nút 2 và 5 . Tương ứng với định nghĩa toàn
cục trong nút 2 , có một công dụng p của tv trên các cạnh (7, 8) và (7,
9) . Có các đường dẫn rõ ràng từ nút 2 đến các cạnh (7, 8) và (7, 9) ,
lần lượt là 2-3-7-8 và 2-3-7-9 . Ngoài ra, có các đường dẫn rõ ràng từ
nút 5 đến các cạnh
(7, 8) và (7, 9) , lần lượt là 5-6-3-7-8 và 5-6-3-7-9 . Sau đây, chúng
tôi xác định bốn đường dẫn hoàn chỉnh bao gồm bốn đường dẫn rõ
ràng ở trên:
1- 2-3-7-8-10 , _
1- 2-3-7-9-10 , _
1-2-3-4- 5-6-3-7-8-10 , và 1-2-3-4- 5-6-3-7-9-10 . _
All-p-using / Một số c-use: Tiêu chí này giống với tiêu chí all-p-use
ngoại trừ khi một biến x không có p-use. Nếu x không có công dụng
p, thì tiêu chí này giảm xuống tiêu chí một số công dụng c được giải
thích bên dưới.
Một số công dụng c: Đối với mỗi biến x và mỗi nút i sao cho x có
định nghĩa toàn cục trong nút i, hãy chọn các đường dẫn hoàn chỉnh
bao gồm các đường dẫn rõ ràng từ nút i đến một số nút j sao cho có
một c- toàn cục sử dụng x trong nút j.
Ví dụ: Hãy để chúng tôi nhận được các đường dẫn để đáp ứng tiêu
chí all-p-use / some-c-use đối với biến i. Chúng tôi tìm thấy hai định
nghĩa toàn cục của i trong các nút 2 và 6 . Không có cách sử dụng p
của i trong Hình 5.4. Do đó, chúng tôi xem xét một số công dụng c
của biến i. Tương ứng với định nghĩa toàn cục của biến i trong nút 2 ,
có một sử dụng c toàn cục của i trong nút 6 và có một đường dẫn rõ
ràng từ nút 2 đến nút 6 ở dạng 2-3-4-5 -6 . Do đó, để đáp ứng tiêu chí
all-p-use / some-c-using đối với biến i, chúng tôi chọn đường dẫn
hoàn chỉnh 1- 2-3-4-5-6 -3-7-9-10 bao gồm đường dẫn def-clear 2-3-
4-5-6 .
All-c-use / Some-p-using: Tiêu chí này giống với tiêu chí all-c-use
ngoại trừ khi một biến x không có c-use toàn cục. Nếu x không có c-
use toàn cục, thì tiêu chí này giảm xuống tiêu chí some-p-use được
giải thích bên dưới.
Một số công dụng: Đối với mỗi biến x và mỗi nút i sao cho x có định
gồm các đường dẫn rõ ràng từ nút i đến một số cạnh (j, k) sao cho có
một p-sử dụng của x trên cạnh (j, k).
Ví dụ: Hãy để chúng tôi lấy các đường dẫn để đáp ứng tiêu chí all-c-
use / some-p-using đối với AS biến. Chúng tôi chỉ tìm thấy một định
nghĩa chung về AS trong nút 1 . Không có c-sử dụng AS toàn cầu
trong Hình 5.4. Vì vậy, chúng tôi xem xét một số công dụng p của
AS. Tương ứng với định nghĩa toàn cục của AS trong nút 1 , có p-lần
sử dụng AS trên các cạnh (3, 7) và (3, 4) và có các đường dẫn rõ ràng
từ nút 1 đến hai cạnh đó, cụ thể là 1 -2-3-7 và 1-2-3-4 , tương ứng.
Có nhiều đường dẫn hoàn chỉnh bao gồm hai đường dẫn rõ ràng. Một
đường dẫn ví dụ như vậy được đưa ra là 1-2-3-4-5-6-3-7-9-10 .
Tất cả các mục đích sử dụng: Tiêu chí này là sự kết hợp của tiêu chí
sử dụng tất cả p và tiêu chí sử dụng đa năng đã thảo luận ở trên.
Tất cả các đường dẫn: Đối với mỗi biến x và cho mỗi nút i sao cho x
có định nghĩa toàn cục trong nút i, hãy chọn các đường dẫn hoàn
chỉnh bao gồm tất cả các đường dẫn du từ nút i
187
cho tất cả các nút j sao cho có một việc sử dụng c toàn cục của x
trong j và
với tất cả các cạnh (j, k) sao cho có một công dụng của x trên (j, k).
Trong Chương 4, chúng tôi đã giải thích một thủ tục để tạo đầu vào
kiểm tra từ một đường dẫn chương trình vào - ra. Có nhiều điểm
tương đồng giữa thử nghiệm dựa trên luồng kiểm soát và thử nghiệm
dựa trên luồng dữ liệu. Sự khác biệt của chúng nằm ở cách hai kỹ
thuật chọn đường dẫn chương trình.
5.7 SO SÁNH TIÊU CHÍ LỰA CHỌN KIỂM TRA DÒNG DỮ
LIỆU
Đã thấy một số lượng tương đối lớn các tiêu chí lựa chọn thử nghiệm
dựa trên các khái niệm về luồng dữ liệu và luồng điều khiển, rất hữu
ích khi tìm ra các mối quan hệ giữa chúng. Với một cặp tiêu chí lựa
chọn thử nghiệm, chúng ta sẽ có thể so sánh hai tiêu chí này. Nếu
chúng ta không thể so sánh chúng, chúng ta nhận ra rằng chúng
không thể so sánh được. Rapps và Weyuker [3] đã định nghĩa khái
niệm về mối quan hệ bao gồm để tìm hiểu xem đối với một cặp tiêu
chí lựa chọn nhất định, tiêu chí này có bao gồm tiêu chí kia hay
không. Trong phần sau, bằng một đường dẫn hoàn chỉnh, chúng ta có
nghĩa là một đường dẫn từ nút vào của biểu đồ luồng đến một trong
các nút thoát của nó.
Định nghĩa: Cho hai tiêu chí lựa chọn thử nghiệm c 1 và c 2 , c 1 bao
gồm c 2 nếu với mọi đồ thị xác định / sử dụng bất kỳ tập hợp các
đường đi hoàn chỉnh của đồ thị thỏa mãn c 1 cũng thỏa mãn c 2 .
Định nghĩa: Cho hai tiêu chí lựa chọn bài kiểm tra c 1 và c 2 , c 1 hoàn
toàn bao gồm c 2 , được ký hiệu là c 1 → c 2 , với điều kiện c 1 bao gồm
c 2 và đối với một số đồ thị xác định / sử dụng có một tập hợp các
đường dẫn hoàn chỉnh của đồ thị thỏa mãn c 2 nhưng không thỏa mãn
c 1.
Có thể dễ dàng nhận thấy rằng quan hệ “ → ” là một quan hệ bắc
cầu. Hơn nữa, với hai tiêu chí c 1 và c 2 , có thể cả c 1 → c 2 và c 2 → c
1 đều không đúng, trong trường hợp đó chúng ta gọi hai tiêu chí là không
thể so sánh được. Việc chứng minh mối quan hệ bao hàm nghiêm
ngặt hoặc mối quan hệ không thể so sánh được giữa hai tiêu chí lựa
chọn trong một ngôn ngữ lập trình với ngữ nghĩa tùy ý có thể không
thực hiện được. Do đó, để cho thấy mối quan hệ bao hàm chặt chẽ
giữa một cặp tiêu chí lựa chọn, Rapps và Weyuker [3] đã xem xét
một ngôn ngữ lập trình bị hạn chế với cú pháp sau:
Start statement: start
Input statement: read x1,...,xn, where xi,...,n are
variables.
Assignment statement: y←f (x1,...,xn), where y, xi,...,n are
variables, and f is a function.
Output statement: print e1,...,en, where e1,...,en are
output values.
Unconditional transfer goto m, where m is a label.
statement:
Conditional transfer statement: if p(x1,...,xn), then goto m, where p
is a predicate.
Halt statement: stop
5.8 TIÊU CHÍ LỰA CHỌN BỆNH NHÂN VÀ TIÊU CHÍ THỬ
NGHIỆM
All-paths
All-du-paths
All-uses
All-c-uses/Some-p-uses All-p-uses/Some-c-uses
All-c-uses All-p-uses
All-defs
All-branches
All-statements
Hình 5.5 Mối quan hệ giữa các tiêu chí kiểm tra DF (luồng dữ liệu).
(Từ tham chiếu 4. © 1988 IEEE.)
Frankl và Weyuker [4] đã mở rộng mối quan hệ hơn nữa; những gì
họ đã chứng minh đã được tóm tắt trong Hình 5.5. Ví dụ: tiêu chí lựa
chọn tất cả các đường dẫn bao gồm nghiêm ngặt tiêu chí tất cả các
189
đường dẫn. Tương tự, tiêu chí all-c-use / some-p-use bao gồm cả tiêu
chí all-defs.
Tuy nhiên, chúng tôi không thể tìm thấy mối quan hệ bao hàm chính
xác giữa cặp all-c-use và all-p-using. Gọi P x c là tập hợp các đường đi
được chọn theo tiêu chí all-c-use liên quan đến một biến x. Bây giờ
chúng ta không thể nói một cách chắc chắn rằng liệu tập đường dẫn P
x có thỏa mãn tiêu chí sử dụng tất cả p đối với cùng một biến x hay
c
không. Tương tự, cho P x p là tập hợp các đường dẫn được chọn bởi
tiêu chí sử dụng tất cả p liên quan đến biến x. Bây giờ chúng ta
không thể nói chắc chắn rằng liệu tập đường dẫn P x p có thỏa mãn
tiêu chí sử dụng tất cả c đối với cùng một biến x hay không. Do đó,
hai tiêu chí all-c-use và all-p-using là không thể so sánh được.
Lưu ý mối quan hệ giữa tiêu chí lựa chọn thử nghiệm dựa trên luồng
dữ liệu và tiêu chí lựa chọn thử nghiệm dựa trên luồng điều khiển,
như thể hiện trong Hình 5.5. Hai tiêu chí lựa chọn thử nghiệm dựa
trên luồng điều khiển trong Hình 5.5 là tất cả các nhánh và tất cả các
câu lệnh. Tiêu chí all-p-use bao gồm nghiêm ngặt tiêu chí tất cả các
nhánh, ngụ ý rằng người ta có thể chọn nhiều đường dẫn hơn từ biểu
đồ luồng dữ liệu của một đơn vị chương trình hơn là từ biểu đồ luồng
điều khiển của nó.
5.8 TIÊU CHÍ LỰA CHỌN BỆNH NHÂN VÀ TIÊU CHÍ THỬ
NGHIỆM
Cho một đồ thị luồng dữ liệu, một đường dẫn là một chuỗi các nút và
các cạnh. Đường hoàn chỉnh là một chuỗi các nút và các cạnh bắt đầu
từ nút ban đầu của đồ thị đến một trong các nút thoát của nó. Một
đường dẫn hoàn chỉnh có thể thực thi được nếu tồn tại sự gán giá trị
cho các biến đầu vào và biến toàn cục sao cho tất cả các biến vị ngữ
đường dẫn đều đánh giá là true, do đó làm cho đường dẫn có thể thực
thi được. Đường dẫn thực thi còn được gọi là đường dẫn khả thi. Nếu
không có sự gán giá trị nào như vậy cho các biến đầu vào và các biến
toàn cục thì chúng ta gọi là đường dẫn không khả thi hoặc không thể
thực hiện được.
Vì chúng ta quan tâm đến việc chọn đầu vào để thực thi đường dẫn,
chúng ta phải đảm bảo rằng tiêu chí lựa chọn thử nghiệm chọn đường
dẫn thực thi. Giả sử rằng chúng ta muốn kiểm tra một chương trình
bằng cách chọn các đường dẫn để thỏa mãn một tiêu chí lựa chọn nào
đó C. Gọi P C là tập các đường dẫn được chọn theo tiêu chí C cho một
đơn vị chương trình nhất định. Như một ví dụ cực đoan, nếu tất cả
các đường dẫn trong P C là không khả thi, thì tiêu chí C đã không
giúp ích gì cho chúng ta theo bất kỳ cách nào. Để một tiêu chí C trở
nên hữu ích, nó phải chọn một tập hợp các đường dẫn có thể thực thi
hoặc khả thi. Frankl và Weyuker [4] đã sửa đổi các định nghĩa của
tiêu chí lựa chọn thử nghiệm để mỗi tiêu chí chỉ chọn ra những con
đường khả thi. Nói cách khác, chúng tôi sửa đổi định nghĩa của tiêu
chí C để có được tiêu chí C * chỉ chọn các con đường khả thi và C *
được gọi là tiêu chí kiểm tra luồng dữ liệu khả thi (FDF). Ví dụ: tiêu
chí (Tất cả-c-dùng) * là sự điều chỉnh của Tất cả-c-sử dụng sao cho
chỉ những con đường khả thi được chọn bởi (Tất cả-c-dùng) *, như
được định nghĩa bên dưới.
(All-c-use) *: Đối với mỗi biến x và cho mỗi nút i, sao cho x có định
nghĩa toàn cục trong nút i, hãy chọn các đường dẫn hoàn chỉnh khả
thi bao gồm các đường dẫn rõ ràng từ nút i đến tất cả các nút j sao
cho ở đó là cách sử dụng c toàn cục của x trong j.
Do đó, tiêu chí lựa chọn thử nghiệm (Tất cả đường dẫn) *, (Tất cả
đường dẫn) *, (Tất cả các mục đích sử dụng) *, (Tất cả các mục đích
sử dụng / Một số mục đích sử dụng) *, (Tất cả các mục đích sử
dụng / Some-c-use) *, (All-c-use) *, (All-puses) *, (All-defs) *, (All-
branch) *, và (All-statement) * chỉ chọn các đường dẫn khả thi, và do
đó, chúng được gọi là các tiêu chí kiểm tra luồng dữ liệu khả thi
(FDF). Frankl và Weyuker [4] đã chỉ ra rằng mối quan hệ bao hàm
chặt chẽ giữa các tiêu chí lựa chọn thử nghiệm, như được trình bày
trong Hình 5.5, không đúng nếu các tiêu chí lựa chọn chỉ chọn những
con đường khả thi. Mối quan hệ mới giữa các tiêu chí lựa chọn thử
nghiệm FDF được tóm tắt trong Hình 5.6. Mặc dù có vẻ hữu ích khi
chỉ chọn các đường khả thi và do đó chỉ xem xét các tiêu chí lựa
chọn kiểm tra FDF, chúng tôi đang phải đối mặt với vấn đề khả năng
phân giải. Cụ thể hơn, không thể quyết định được nếu một tập hợp
các đường dẫn nhất định có thể thực thi được hay không. Chúng tôi
không thể tự động hóa việc áp dụng tiêu chí lựa chọn kiểm tra FDF,
nếu chúng tôi không biết khả năng thực thi của đường dẫn. Mặt khác,
tiêu chí kiểm tra luồng dữ liệu có thể trở nên không phù hợp nếu tất
cả các đường dẫn đã chọn của nó là không khả thi, trong trường hợp
đó tiêu chí được coi là không đủ. Do đó, một kỹ sư kiểm thử phải lựa
191
chọn giữa việc sử dụng một tiêu chí lựa chọn không phù hợp và một
tiêu chí không thể hoàn toàn tự động.
5.9 SO SÁNH CÁC KỸ THUẬT THỬ NGHIỆM
Cho đến nay chúng ta đã thảo luận về hai kỹ thuật chính để tạo dữ
liệu thử nghiệm từ mã nguồn, đó là lựa chọn đường dẫn dựa trên
luồng điều khiển và lựa chọn đường dẫn dựa trên luồng dữ liệu.
Chúng tôi cũng giải thích một số tiêu chí để chọn đường dẫn từ biểu
đồ luồng điều khiển và biểu đồ luồng dữ liệu của một chương trình.
Các lập trình viên thường chọn ngẫu nhiên dữ liệu thử nghiệm dựa
trên sự hiểu biết của riêng họ về đoạn mã mà họ đã viết. Do đó, điều
đương nhiên là
5.9 SO SÁNH CÁC KỸ THUẬT THỬ NGHIỆM
(All-paths)*
(All-du-paths)* (All-branches)*
(All-uses)*
(All-c-uses/Some-p-uses
)* (All-p-uses/Some-c-uses
)*
(All-c-uses)* (All-defs)* (All-p-uses)* (Tất cả các báo cáo)

*
Hình 5.6 Mối quan hệ giữa các tiêu chí kiểm tra FDF (luồng dữ
liệu khả thi). (Từ tài liệu tham khảo 4. ©
IEEE năm 1988.)
so sánh hiệu quả của ba kỹ thuật tạo thử nghiệm, đó là lựa chọn thử
nghiệm ngẫu nhiên, lựa chọn thử nghiệm dựa trên luồng điều khiển
và lựa chọn thử nghiệm dựa trên luồng dữ liệu. So sánh các kỹ thuật
đó dường như không phải là một việc dễ dàng. Một cách dễ dàng và
chấp nhận được để so sánh chúng là áp dụng các kỹ thuật đó cho
cùng một nhóm chương trình có các lỗi đã biết và thể hiện tính hiệu
quả của chúng theo hai chỉ số sau:
Số lượng trường hợp thử nghiệm được sản xuất
phần trăm lỗi đã biết được phát hiện
Ntafos [5] đã báo cáo về kết quả của một thử nghiệm so sánh hiệu
quả của ba kỹ thuật lựa chọn thử nghiệm. Thí nghiệm liên quan đến
bảy chương trình toán học với các lỗi đã biết. Đối với kỹ thuật dựa
trên luồng điều khiển, tiêu chí mức độ bao phủ nhánh đã được chọn,
trong khi tiêu chí về mọi công dụng được chọn để kiểm tra luồng dữ
liệu. Thử nghiệm ngẫu nhiên cũng được áp dụng cho các chương
trình. Kiểm tra luồng dữ liệu, kiểm tra nhánh và kiểm tra ngẫu nhiên
đã phát hiện lần lượt 90%, 85,5% và 79,5% trong số các lỗi đã biết.
Tổng cộng 84 trường hợp thử nghiệm được thiết kế để đạt được
phạm vi sử dụng, 34 trường hợp thử nghiệm được thiết kế để đạt
được phạm vi bao phủ nhánh và 100 trường hợp thử nghiệm được
thiết kế theo phương pháp thử nghiệm ngẫu nhiên. Chúng tôi diễn
giải kết quả thử nghiệm như sau:
Một lập trình viên có thể tạo ngẫu nhiên một số lượng lớn các trường
hợp thử nghiệm để tìm ra hầu hết các lỗi. Tuy nhiên, người ta sẽ chạy
ra các trường hợp thử nghiệm để tìm ra một số lỗi còn lại. Thử
nghiệm ngẫu nhiên không có vẻ là không hiệu quả, nhưng
Number of faults detected
Total number of faults in a program

Reduce this gap
by using a technique
Luồng kiểm soát ngẫu nhiên — Luồng dữ liệu — Kỹ thuật thử

nghiệm dựa trên thử nghiệm dựa trên thử nghiệm mới
Hình 5.7 Giới hạn của các kỹ thuật phát hiện lỗi khác nhau.
nó phải chịu chi phí cao hơn các kỹ thuật hệ thống, cụ thể là kỹ thuật
luồng điều khiển và kỹ thuật luồng dữ liệu.
Lựa chọn thử nghiệm dựa trên phạm vi nhánh tạo ra ít trường hợp
thử nghiệm hơn nhiều so với kỹ thuật ngẫu nhiên, nhưng đạt được
193
mức độ phát hiện lỗi gần như tương tự như kỹ thuật ngẫu nhiên. Do
đó, tiết kiệm đáng kể chi phí thử nghiệm chương trình.
Tiêu chí kiểm thử toàn dụng cung cấp cho lập trình viên một cách
mới để thiết kế nhiều trường hợp kiểm thử hơn và tiết lộ nhiều lỗi
hơn so với tiêu chí phạm vi nhánh. • Tất cả các kỹ thuật này đều có
những hạn chế cố hữu khiến chúng không thể tiết lộ tất cả các lỗi. Do
đó, cần phải sử dụng nhiều kỹ thuật kiểm tra khác nhau và phát triển
các kỹ thuật mới. Ý tưởng này được mô tả trong Hình 5.7. Mục tiêu
của chúng tôi là giảm khoảng cách giữa tổng số lỗi có trong một
chương trình và các lỗi được phát hiện bằng các kỹ thuật tạo thử
nghiệm khác nhau.
5.10 TÓM TẮT
Luồng dữ liệu trong một chương trình có thể được hình dung bằng
cách xem xét thực tế là một đơn vị chương trình chấp nhận dữ liệu
đầu vào, biến đổi dữ liệu đầu vào thông qua một chuỗi tính toán và
cuối cùng là tạo ra dữ liệu đầu ra. Do đó, người ta có thể hình dung
các giá trị dữ liệu được chuyển từ một câu lệnh gán xác định một
biến đến một câu lệnh gán khác hoặc một vị từ mà giá trị được sử
dụng.
Ba hành động cơ bản được liên kết với một biến là undefine (u), xác
định (d) và tham chiếu (r). Một biến hoàn toàn không được xác định
khi nó được tạo mà không được gán giá trị. Mặt khác, một biến có
thể không được xác định rõ ràng. Ví dụ, khi một tệp đã mở bị đóng,
biến giữ con trỏ tệp sẽ trở thành không xác định. Chúng tôi đã giải
thích ý tưởng về “trạng thái” của một biến, cụ thể là, không xác định
(U), xác định (D), tham chiếu (R) và bất thường (A), bằng cách xem
xét ba hành động cơ bản trên một biến. Trạng thái A đại diện cho
thực tế là biến đã được truy cập theo cách bất thường gây ra sự bất
thường của luồng dữ liệu.
Các hành động riêng lẻ trên một biến không gây ra sự bất thường của
luồng dữ liệu. Thay vào đó, các chuỗi hành động nhất định dẫn đến
sự bất thường của luồng dữ liệu và ba chuỗi hành động đó là dd, ur
và du. Một biến tiếp tục duy trì ở trạng thái bất thường bất kể các
hành động tiếp theo sau khi nó đi vào trạng thái đó. Sự hiện diện đơn
thuần của dòng dữ liệu bất thường trong một chương trình có thể
không dẫn đến lỗi chương trình. Lập trình viên phải điều tra nguyên
nhân của sự bất thường và sửa đổi mã để loại bỏ nó. Ví dụ, một câu
lệnh bị thiếu trong mã có thể gây ra sự bất thường dd, trong trường
hợp đó, lập trình viên cần viết mã mới.
Đường dẫn chương trình là một khái niệm cơ bản trong kiểm thử.
Một trường hợp thử nghiệm có thể được tạo từ một đường dẫn thực
thi. Số lượng các đường dẫn khác nhau được chọn để thực hiện là
thước đo mức độ thử nghiệm được thực hiện. Lựa chọn đường dẫn
dựa trên phạm vi của câu lệnh và phạm vi nhánh dẫn đến một số
lượng nhỏ đường dẫn được chọn để thực thi. Do đó, tồn tại một
khoảng cách lớn giữa thử nghiệm dòng kiểm soát và thử nghiệm toàn
diện. Khái niệm kiểm tra luồng dữ liệu cung cấp cho chúng ta một
cách để thu hẹp khoảng cách giữa thử nghiệm luồng kiểm soát và thử
nghiệm toàn diện.
Khái niệm kiểm tra luồng dữ liệu cung cấp cho chúng ta các tiêu chí
lựa chọn mới để chọn nhiều đường dẫn chương trình để kiểm tra hơn
là những gì chúng ta có thể chọn bằng cách sử dụng ý tưởng về kiểm
tra luồng điều khiển. Cụ thể, tiêu chí lựa chọn kiểm tra luồng dữ liệu
là all-du-path, all-defs, all-c-use, all-p-using, all-use, all-c-using /
some-p-using và all- p-using / some-c-use. Để so sánh hai tiêu chí lựa
chọn, khái niệm về mối quan hệ bao hàm nghiêm ngặt được cho là
hữu ích.
Osterweil và Fosdick [6] đã triển khai một hệ thống, được gọi là

DAVE, để phân tích các chương trình FORTRAN và phát hiện các
dạng bất thường của luồng dữ liệu ur, dd và du. DAVE phát hiện
những điểm bất thường đó bằng cách thực hiện tìm kiếm đồ thị luồng
cho từng biến trong một đơn vị chương trình nhất định. Đối với các
chương trình có lệnh gọi chương trình con, hệ thống hoạt động theo
cách từ dưới lên, tức là các chương trình con được gọi sẽ được phân
tích trước khi phân tích trình gọi.
Các lập trình viên cần lưu ý rằng rất khó áp dụng ý tưởng phân tích
luồng dữ liệu cho tất cả các loại cấu trúc dữ liệu và cấu trúc chương
trình. Việc phân tích các mảng là một trong những khó khăn như vậy.
Fosdick và Osterweil [1] đã lưu ý rằng các vấn đề nảy sinh khi các
phần tử khác nhau của cùng một mảng được tác động theo những
195
cách khác nhau, do đó làm phát sinh các mẫu định nghĩa, tham chiếu
và xác định khác nhau. Các hệ thống phân tích luồng dữ liệu tĩnh ,
chẳng hạn như DAVE, không đánh giá các biểu thức chỉ mục và do
đó không thể cho chúng tôi biết phần tử mảng nào đang được tham
chiếu trong một biểu thức nhất định. Các hệ thống như vậy cố gắng
giải quyết vấn đề này bằng cách coi toàn bộ mảng là một biến duy
nhất, thay vì một tập hợp các biến khác nhau cùng kiểu. Fosdick và
Osterweil đã chỉ ra rằng các chương trình đệ quy gây khó khăn trong
phân tích luồng dữ liệu. Một phong cách lập trình có thể gây khó
khăn trong phân tích luồng dữ liệu là chuyển một biến duy nhất làm
đối số nhiều lần. Điều này là do DAVE giả định rằng tất cả các tham
số của chương trình con là các biến riêng biệt.
Laski và Korel [7] lập luận rằng kiểm tra luồng dữ liệu thu hẹp
khoảng cách giữa kiểm thử nhánh và kiểm tra tất cả các đường dẫn.
Một mặt, trong kiểm thử nhánh, người ta chọn một tập hợp các
đường dẫn để bao phủ tất cả các nhánh của đồ thị luồng điều khiển
của một đơn vị chương trình; người ta cần chọn một số lượng nhỏ
các đường dẫn để thỏa mãn tiêu chí. Mặt khác, kiểm tra tất cả các
đường dẫn cũng giống như kiểm tra toàn bộ. Kiểm thử luồng dữ liệu
cho phép lập trình viên lựa chọn nhiều đường dẫn hơn so với kiểm
thử nhánh. Về cơ bản, trong kiểm tra luồng dữ liệu, các vòng lặp
được mở ra để thực hiện các cặp định nghĩa - sử dụng.
Herman [8] đã yêu cầu một lập trình viên áp dụng kiểm tra luồng dữ
liệu cho một số đơn vị chương trình cỡ vừa với khoảng 800 câu lệnh.
Điều thú vị cần lưu ý là các lỗi được phát hiện trong quá trình thử
nghiệm thường được tìm thấy trong khi cố gắng thiết lập dữ liệu thử
nghiệm để đáp ứng các đường dẫn đã chọn, thay vì trong khi kiểm tra
kết quả chạy thử nghiệm. Thực tế là các lỗi chương trình được tìm
thấy trong quá trình thiết kế thử nghiệm có ý nghĩa quan trọng trong
việc phát triển hệ thống và lựa chọn các thử nghiệm có thể được thực
hiện đồng thời để tạo ra một hệ thống chất lượng tốt hơn.
Bài báo của Ural [9] trình bày một phương pháp tạo các trường hợp
thử nghiệm từ các thông số kỹ thuật của các giao thức truyền thông
được đưa ra bằng ngôn ngữ Estelle. Phương pháp này liên quan đến
phân tích luồng dữ liệu tĩnh về các thông số kỹ thuật. Phương pháp
này được tóm tắt như sau: (i) biến đổi một thông số kỹ thuật thành
một đồ thị có chứa cả luồng điều khiển và các khía cạnh của luồng
dữ liệu; (ii) phát hiện sự bất thường của luồng dữ liệu trong đặc tả; và
(iii) tạo các trường hợp thử nghiệm để bao gồm tất cả các cặp định
nghĩa-sử dụng.
Bài báo của Ntafos [10] giải thích tổng quan mở rộng về các chiến
lược kiểm tra luồng dữ liệu về mức độ bao phủ tương đối của chúng
đối với cấu trúc của chương trình và số lượng các trường hợp kiểm
thử cần thiết để đáp ứng từng chiến lược. Ngoài ra, bài báo còn mở
rộng hệ thống phân cấp phụ thuộc được giới thiệu bởi Rapps và
Weyuker [3] bằng cách bao gồm TER n = 1. Để biết chi tiết về các
mức phân cấp thử nghiệm, được ký hiệu là n ở trên và tỷ lệ hiệu quả
thử nghiệm (TER), bạn đọc tham khảo bài viết của Woodward,
Hedley và Hennell [11].
Khái niệm lựa chọn đường dẫn chương trình dựa trên luồng dữ liệu
đã được các nhà nghiên cứu khác nhau, cụ thể là Laski và Korel [7],
Ntafos [5], và Rapps và Weyuker [3], nghiên cứu theo nhiều cách
khác nhau. Để tạo điều kiện thuận lợi cho việc so sánh và đơn giản
hóa cuộc thảo luận, Clarke, Podgurski, Richardson và Zeil [12] xác
định tất cả các tiêu chí của luồng dữ liệu bằng cách sử dụng một bộ
thuật ngữ duy nhất. Họ đưa ra một hệ thống phân cấp phụ mới của
các tiêu chí lựa chọn kiểm tra luồng dữ liệu bằng cách sửa đổi hệ
thống phân cấp phụ của Rapps và Weyuker [7] được thể hiện trong
Hình 5.5.
Koh và Liu [3] đã trình bày một cách tiếp cận hai bước để tạo ra các
đường dẫn kiểm tra cả luồng điều khiển và luồng dữ liệu trong việc
triển khai các giao thức truyền thông dựa trên ý tưởng về các máy
trạng thái hữu hạn mở rộng. Đầu tiên, hãy chọn một tập hợp các
đường dẫn để bao hàm một tiêu chí lựa chọn luồng dữ liệu. Thứ hai,
bổ sung một cách có chọn lọc các chuyển đổi trạng thái trong tập hợp
các đường dẫn đã chọn với các trình tự kiểm tra trạng thái để có thể
đảm bảo luồng điều khiển và có thể bảo toàn vùng phủ của luồng dữ
liệu. Phương pháp thiết kế thử nghiệm của Sarikaya, Bochmann và
Cerny [14] cũng tạo ra các đường dẫn để đạt được phạm vi bao phủ
chung của luồng điều khiển và luồng dữ liệu trong các đặc tả Estelle
của các giao thức truyền thông.
Các nhà nghiên cứu đã mở rộng cách tiếp cận kiểm tra luồng dữ liệu
cổ điển để kiểm tra các chương trình hướng đối tượng [15–18].
Harrold và Rothermel [16] đã áp dụng khái niệm kiểm thử luồng dữ
197
liệu vào việc kiểm tra các lớp trong chương trình hướng đối tượng.
Ba cấp độ thử nghiệm mà họ đã đề xuất là thử nghiệm nội bộ, thử
nghiệm giữa các vòng và thử nghiệm nội kính. Kiểm tra giữa các
phương pháp giống như dữ liệu
NGƯỜI GIỚI THIỆU
kiểm thử luồng được thực hiện trên một đơn vị trong ngôn ngữ lập
trình thủ tục, chẳng hạn như C. Kiểm tra liên tục tương tự như việc
tích hợp các đơn vị chương trình trong một ngôn ngữ lập trình thủ
tục. Cuối cùng, kiểm thử nội bộ đề cập đến việc gọi các phương thức
công khai của một lớp theo một trình tự ngẫu nhiên, có thể chấp nhận
được.
Khái niệm kiểm thử luồng dữ liệu cổ điển được áp dụng cho một đơn
vị chương trình tại một thời điểm đã được mở rộng sang kiểm tra
luồng dữ liệu liên thủ tục . Ý tưởng về luồng dữ liệu liên thủ tục đã
được nghiên cứu rộng rãi trong tài liệu (xem tài liệu tham khảo 19 và
thư mục bài báo của Harrold và Soffa [20]).
Thông thường các lập trình viên sử dụng khả năng của con trỏ trong
ngôn ngữ C và C ++ . Phân tích luồng dữ liệu trở nên khó khăn khi
con trỏ được chuyển giữa các thủ tục. Pande, Landi và Ryder [21] đã
định nghĩa một thuật ngữ gọi là định nghĩa đạt tới, là tập hợp tất cả
các điểm mà giá trị của một biến được ghi lần cuối. Đối với một cấp
của hướng con trỏ, họ đưa ra một thuật toán thời gian đa thức cho
vấn đề. Để phát triển thuật toán, nhóm tác giả đã đưa ra khái niệm về
đồ thị luồng điều khiển liên thủ tục, là sự kết hợp giữa đồ thị luồng
điều khiển và đồ thị cuộc gọi. Họ chứng minh rằng vấn đề chung của
việc xác định các định nghĩa tiếp cận liên thủ tục là khó khăn.
Lemos, Vincenzi, Maldonado, và Masiero [22] đã áp dụng ý tưởng
kiểm tra luồng dữ liệu cho các chương trình hướng khía cạnh [23].
Khái niệm lập trình hướng khía cạnh được phát triển để giải quyết
khó khăn trong việc nắm bắt rõ ràng các quyết định thiết kế cấp cao
nhất định ở cấp mã. Các thuộc tính của các quyết định thiết kế đó
được gọi là các khía cạnh, và do đó có tên là lập trình hướng khía
cạnh. Lý do khiến một số quyết định thiết kế khó thể hiện ở cấp mã
là chúng cắt ngang chức năng cơ bản của hệ thống [23]. Đương
nhiên, một khía cạnh khó viết mã có khả năng khó kiểm tra và xác
minh hơn. Để đạt được mục đích này, công trình của Lemos et al.
[22] có được ý nghĩa. Họ đã đề xuất khái niệm về biểu đồ định
hướng khía cạnh sử dụng (AODU), dựa trên ý tưởng về biểu đồ

hướng dẫn luồng dữ liệu [24] và xác định các tiêu chí phạm vi mới,
chẳng hạn như tất cả các mục đích sử dụng ngoại lệ, độc lập, tất cả-
các mục đích sử dụng ngoại lệ và tất cả các mục đích sử dụng chéo.
Zhao [25] đã áp dụng ý tưởng kiểm tra luồng dữ liệu ở cấp độ hạt thô
trong các chương trình hướng khía cạnh. Tác giả đã mở rộng khái
niệm kiểm thử lớp do Harrold và Rothermel nghiên cứu [16].
Cuốn sách Kỹ thuật kiểm thử phần mềm năm 1990 của Beizer [26]
đưa ra một giải thích tuyệt vời về khái niệm kiểm thử luồng dữ liệu.
int binsearch(int X, int V[], int n){ int low, high, mid; low = 0; high
= n - 1; while (low <= high) {
mid = (low + high)/2; if (X < V[mid]) high = mid - 1;
else if (X > V[mid]) low = mid + 1;
else return mid;
} return -1;
}
Hình 5.8 Quy trình tìm kiếm nhị phân.
int modifiedbinsearch(int X, int V[], int n){

int low, high, mid; low = 0; high = n - 1; while
(low <= high) { mid = (low + high)/2; if (X <
V[mid]) { high = mid - 1; mid = mid - 1;
} else if (X > V[mid]) low = mid + 1;
else return mid;
} return -1;
}
Hình 5.9 Quy trình tìm kiếm nhị phân đã sửa đổi.
Xác định sự bất thường của luồng dữ liệu trong đoạn mã được cho
trong Hình 5.9.
199
Bằng cách tham khảo biểu đồ luồng dữ liệu thu được trong bài tập 1,
hãy tìm một tập hợp các đường hoàn chỉnh thỏa mãn tiêu chí lựa
chọn tất cả các độ lệch liên quan đến biến giữa.
Bằng cách tham khảo biểu đồ luồng dữ liệu thu được trong bài tập 1,
hãy tìm một tập hợp các đường hoàn chỉnh đáp ứng tiêu chí lựa chọn
tất cả các độ lệch liên quan đến biến cao.
Viết một hàm trong C sao cho tiêu chí sử dụng tất cả tạo ra nhiều
casesthan kiểm tra tiêu chí tất cả các nhánh.
Khoảng cách giữa thử nghiệm tất cả các nhánh và thử nghiệm tất cả
các đường dẫn có nghĩa là gì và làm cách nào để kiểm tra luồng dữ
liệu lấp đầy khoảng cách?
Giải thích tại sao sự hiện diện của luồng dữ liệu bất thường không có
nghĩa là việc thực thi chương trình chắc chắn sẽ tạo ra kết quả không
chính xác.
Sự bất thường của chương trình đã được xác định bằng cách xem xét
ba phép toán, đó là xác định (d), tham chiếu (r) và không xác định
(u). Ba chuỗi hoạt động được xác định là bất thường của chương
trình là dd, du và ur. Giải thích tại sao phần còn lại của chuỗi hai hoạt
động không được coi là bất thường của chương trình.
Xác định một số khó khăn trong việc xác định sự bất thường của
luồng dữ liệu trong các chương trình.
CHAPTER
6
DomainTesting
Ngay cả khi cho rằng thiên tài đã trải qua thử nghiệm kiểm tra quan
trọng không có lỗi, chúng ta nên xem xét rằng mọi thứ anh ta đã phát
hiện trong một miền nhất định hầu như không là gì so với những gì
còn lại được khám phá. —SantiagoRam´onyCajal
6.1 LỖI MIỀN
Hai yếu tố cơ bản của chương trình máy tính là miền đầu vào và
đường dẫn chương trình. Miền đầu vào của chương trình là tập hợp
tất cả dữ liệu đầu vào của chương trình. Đường dẫn chương trình là
một chuỗi các hướng dẫn từ khi bắt đầu chương trình đến một số
điểm quan tâm trong chương trình. Ví dụ, phần cuối của chương
trình là một điểm quan tâm. Một điểm quan tâm khác là khi chương
trình chờ nhận một đầu vào khác từ môi trường của nó để nó có thể
tiếp tục thực thi. Nói cách khác, một đường dẫn chương trình, hay
đơn giản là đường dẫn, tương ứng với một số luồng điều khiển trong
chương trình. Một đường dẫn được cho là khả thi nếu tồn tại một dữ
liệu đầu vào khiến chương trình thực thi đường dẫn. Nếu không, con
đường được cho là không khả thi.
Howden [1] đã xác định được hai loại lỗi lớn, đó là lỗi tính toán và
lỗi miền, bằng cách kết hợp các khái niệm về dữ liệu đầu vào và
đường dẫn chương trình. Sau đây là hai loại lỗi được giải thích.
Lỗi tính toán: Lỗi tính toán xảy ra khi một dữ liệu đầu vào cụ thể
khiến chương trình thực thi đúng, tức là, đường dẫn mong muốn,
nhưng giá trị đầu ra bị sai. Lưu ý rằng giá trị đầu ra có thể sai ngay cả
khi đường dẫn mong muốn đã được thực thi. Điều này có thể xảy ra
do một hàm sai được thực thi trong một câu lệnh gán. Ví dụ, hãy xem
xét một đường dẫn mong muốn chứa kết quả câu lệnh = f (a, b),
trong đó a và b là các giá trị đầu vào. Lỗi tính toán có thể xảy ra nếu
câu lệnh được thay thế bằng câu lệnh bị lỗi, chẳng hạn như result = f
(b, a). Do đó, kết quả của việc thực hiện đường dẫn có thể bị sai do
201
lỗi trong câu lệnh gán và điều này có thể xảy ra bất chấp việc thực thi
một đường dẫn đúng.
135
Lỗi miền: Lỗi miền xảy ra khi một dữ liệu đầu vào cụ thể khiến
chương trình thực thi sai, nghĩa là không mong muốn, đường dẫn
trong chương trình. Một chương trình có thể chọn một đường dẫn
không chính xác nếu có lỗi trong một hoặc nhiều câu lệnh điều kiện
trong chương trình. Chúng ta hãy xem xét một câu lệnh điều kiện có
dạng if (p) then f1 () else f2 (). Nếu có lỗi trong việc xây dựng vị từ
p, thì lệnh gọi hàm sai sẽ được gọi, do đó gây ra một đường dẫn
không chính xác được thực thi.
Hai loại lỗi chương trình trên khiến chúng ta xem một chương trình
máy tính đang thực hiện một chức năng ánh xạ trừu tượng như sau.
Lý tưởng nhất là đối với mỗi giá trị đầu vào, chương trình sẽ gán một
đường dẫn chương trình để thực thi; cùng một đường dẫn chương
trình có thể được chỉ định riêng (tức là được thực thi) cho một tập
hợp con các giá trị đầu vào. Ở đây, tập hợp con của các giá trị đầu
vào khiến cùng một đường dẫn được thực thi được tham chiếu đến
một miền đầu vào hoặc miền phụ. Do đó, chương trình được cho là
ánh xạ miền tới một đường dẫn bên trong chính nó. Vì có một số
lượng lớn các giá trị trong miền đầu vào của chương trình và có một
số lượng lớn các đường dẫn trong một chương trình, chúng ta có thể
xem một chương trình đang phân vùng không gian đầu vào thành
một số lượng hữu hạn các miền con và gán một đường dẫn chương
trình riêng biệt cho mỗi tên miền phụ đầu vào.
Chúng tôi giải thích thêm về khái niệm miền chương trình bằng cách
sử dụng Hình 6.1. Tập D là toàn bộ tập đầu vào của một chương trình
P (Hình 6.1a). Ta gọi D là miền của toàn bộ chương trình. Tập hợp D
có thể là một tập hợp vô hạn và P có thể không có hành vi tính toán
khác nhau đối với từng phần tử của D. Thay vào đó, P có thể thực
hiện cùng một phép tính cho tất cả các phần tử trong một tập hợp con
nhất định của D. Ví dụ, như trong Hình 6.1b , P thực hiện năm phép
tính khác nhau, mỗi phép tính cho mỗi tập con D 1 , ... , D 5 . Có thể
202 CHƯƠNG 6 KIỂM TRA TRONG NƯỚC
lưu ý rằng phân hoạch của D không được nhìn thấy bên ngoài P.
Thay vào đó, P có một cơ chế khái niệm, được xây dựng sẵn, như
minh họa trong Hình 6.1c, để quyết định phương pháp tính toán cần
thiết để chọn một nhánh cụ thể khi P được gọi với một đầu vào nhất
định. Một bộ phân loại đầu vào như vậy có thể không tồn tại trong
một chương trình ở một dạng duy nhất, có thể nhận dạng rõ ràng.
Khái niệm có thể tồn tại như một thực thể như một khái niệm xuyên
suốt; nó là xuyên suốt vì các phần của bộ phân loại đầu vào có thể
được tìm thấy trong các mô-đun chương trình khác nhau. Chúng tôi
chỉ ra năm phép tính khác nhau, lần lượt tính cho D 1 thông qua phép
tính cho D 5 , cho các tập con D 1 , ... , D 5 (Hình 6.1c). Phần của P
quyết định phép tính nào sẽ gọi cho một phần tử nhất định của D
được gọi là bộ phân loại đầu vào. Chúng tôi nhắc nhở người đọc rằng
cấu trúc của một chương trình có thể không giống với trường hợp mà
chúng tôi đã chỉ ra bên trong vòng tròn lớn hơn trong Hình 6.1c.
Hình này chỉ đơn giản biểu thị thực tế là một chương trình thực hiện
các phép tính khác nhau cho các tập con khác nhau của miền đầu vào
của nó. Các chương trình thực hiện phân loại đầu vào thông qua
chuỗi các vị từ, mặc dù bộ phân loại đầu vào có thể không tồn tại
dưới dạng một mô-đun đơn lẻ.
Do đó, một chương trình sẽ thực hiện tính toán sai nếu có lỗi trong
phần phân loại đầu vào. Với phông nền trên, chúng tôi định nghĩa hai
thuật ngữ sau:
Miền là một tập hợp các giá trị đầu vào mà chương trình thực hiện
cùng một phép tính cho mọi thành viên của tập hợp đó. Chúng tôi
quan tâm đến các miền cực đại để chương trình thực hiện các phép
tính khác nhau trên các miền liền kề.
6.2 KIỂM TRA CÁC LỖI TRONG MIỀN
Program output
Input domainD ProgramP
(a)
Input domainD
203
D3 D1 Program output
D2 ProgramP
D4
D5
(b)
ProgramP
Computation
Input domainD
for D 1
D3 D1 Conceptual Program output

input :
D2 :
D4 classifier
D5
Computation
for D 5
(c)
Hình 6.1 Minh họa khái niệm miền chương trình.
Một chương trình được cho là có lỗi miền nếu chương trình thực hiện
sai phân loại đầu vào. Giả sử rằng các miền liền kề thực hiện các
phép tính khác nhau, một lỗi miền sẽ khiến chương trình tạo ra kết
quả đầu ra không chính xác.
6.2 KIỂM TRA CÁC LỖI TRONG MIỀN
Ý tưởng về thử nghiệm miền được White và Cohen nghiên cứu lần
đầu tiên vào năm 1978 [2, 3]. Có một sự khác biệt cơ bản giữa kỹ
thuật kiểm tra dựa trên biểu đồ luồng và kiểm tra miền. Theo đồ thị
luồng, chúng ta có nghĩa là đồ thị luồng điều khiển và đồ thị luồng
dữ liệu. Sự khác biệt được giải thích như sau:
Chọn các đường dẫn từ biểu đồ luồng điều khiển hoặc biểu đồ luồng
dữ liệu để đáp ứng các tiêu chí về mức độ phù hợp nhất định. Để
nhắc nhở người đọc, tiêu chí bao phủ luồng điều khiển là phạm vi
câu lệnh, phạm vi nhánh và phạm vi vị ngữ. Tương tự, các tiêu chí
được nghiên cứu để bao hàm các khía cạnh định nghĩa và sử dụng
của các biến trong một chương trình là all-defs, all-c-use, all-p-using
và all-use, để đặt tên cho một số ít. Các vị từ đường dẫn được phân
tích để lấy dữ liệu thử nghiệm. Trong khi lựa chọn đường dẫn và dữ
liệu thử nghiệm tương ứng, không có giả định nào được đưa ra về
loại lỗi thực tế mà các trường hợp thử nghiệm đã chọn có thể phát
hiện ra, nghĩa là không có loại lỗi cụ thể nào được xem xét một cách
rõ ràng để phát hiện.
Kiểm tra miền có một cách tiếp cận hoàn toàn mới để phát hiện lỗi.
Người ta xác định một loại lỗi, được gọi là lỗi miền và chọn dữ liệu
kiểm tra để phát hiện những lỗi đó. Nếu một chương trình có lỗi
miền, những lỗi đó sẽ được tiết lộ bởi các trường hợp thử nghiệm.
Chúng tôi thảo luận chi tiết các khái niệm sau:
Nguồn miền: Bằng chương trình ví dụ, chúng tôi giải thích cách các
vị từ chương trình hoạt động như một bộ phân loại đầu vào.
Các loại lỗi miền: Chúng tôi giải thích cách những sửa đổi nhỏ đối
với vị từ chương trình, có thể được hiểu là lỗi lập trình, có thể dẫn
đến lỗi miền.
Chọn dữ liệu thử nghiệm để hiển thị lỗi miền: Tiêu chí lựa chọn
thử nghiệm được giải thích để chọn các giá trị đầu vào. Dữ liệu thử
nghiệm được chọn tiết lộ các loại lỗi miền cụ thể.
6.3 NGUỒN CỦA MIỀN
Miền có thể được xác định từ cả thông số kỹ thuật và chương trình.

Chúng tôi giải thích phương pháp xác định tên miền từ mã nguồn
bằng các bước sau:
Vẽ biểu đồ luồng điều khiển từ mã nguồn đã cho.
Tìm tất cả các cách giải thích có thể có của các vị từ. Nói cách khác,
biểu thị các vị từ chỉ theo vectơ đầu vào và có thể là vectơ hằng số.
Người đọc có thể lưu ý rằng một vị từ trong một chương trình có thể
có nhiều cách diễn giải, bởi vì điều khiển có thể đến một nút vị từ
thông qua các đường dẫn khác nhau.
Phân tích các vị từ được thông dịch để xác định các miền.
Trong phần sau, chúng tôi giải thích quy trình trên để xác định tên
miền. Chúng tôi đưa ra một ví dụ về hàm C trong Hình 6.2 để minh
họa một thủ tục để xác định các miền.
Hàm chấp nhận hai đầu vào x và y và trả về một số nguyên. Biểu
diễn đồ thị luồng điều khiển của codedomain () được thể hiện trong
Hình 6.3. Hai vị từ trong hai câu lệnh if () đã được biểu diễn bởi các
nút 3 và 6 trong Hình 6.3. Vị ngữ
P 1 : c> 5
6.3 NGUỒN CỦA MIỀN
205
int codedomain(int x, int y){
int c, d, k c = x + y; if (c > 5) d = c - x/2; else d = c + x/2;
if (d >= c + 2) k = x + d/2; else k = y + d/4;
return(k);
}
Hình 6.2 Một chức năng giải thích các miền chương trình.
trong câu lệnh if () đầu tiên chỉ có một cách diễn giải, đó là
P 1 : x + y> 5
bởi vì chương trình điều khiển đến câu lệnh if () chỉ qua một đường
dẫn từ nút ban đầu. Tuy nhiên, vị ngữ
Initialize: x, y 1
c =x +y 2
P1 3 P 1: x + y > 5
False True
c >5
5 4
d = c + x/2 d = c − x /2
P 1: False P 1: True
P2 6
P 2: x ≥ 4 False Tr ue P 2: x ≤− 4
d >= c + 2
8 7
k = y + d/4 k = x + d/2
9
return (k)
Hình 6.3 Biểu diễn đồ thị luồng điều khiển của hàm trong Hình
6.2.
P 2: d ≥ c + 2
trong câu lệnh if () thứ hai nhận được hai cách diễn giải, vì điều
khiển chương trình có thể đạt đến câu lệnh if () thứ hai theo hai
đường dẫn: (i) khi if () đầu tiên đánh giá là true và (ii) khi if () đầu
tiên đánh giá là sai. Hai cách giải thích này được tóm tắt trong Bảng
6.1.
Chúng tôi giải thích một thủ tục để có được các miền từ cách diễn
giải của P 1 và P 2 (Hình 6.3). Chúng tôi hiển thị một lưới hai chiều có
nhãn x và y trong Hình 6.4. Kích thước lưới đủ lớn để hiển thị tất cả
các miền của chương trình đang được xem xét. Chúng ta xem xét lần
lượt các nút vị từ của đồ thị luồng điều khiển (Hình 6.3). Vị từ P 1
chia lưới thành hai vùng. Ranh giới P 1 được biểu diễn bởi một đường
thẳng được biểu diễn bởi đẳng thức x + y = 5. Tất cả các điểm trên,
trừ đường thẳng này, thỏa mãn vị từ P 1 .
BẢNG 6.1 Hai cách diễn giải thứ hai nếu ()
Evaluation of Interpretatio
n of
P1 P2
True x ≤ −4
False x ≥4
Tuyên bố trong Hình 6.2

1214
TT
TF
P 2 (P 1 = False)
6
P1
P 2 (P 1 = True)
...7
01
y
−1
FF
FT
−7 −6
−7 −6 −4 −1 0 1 ...4 7
x
Hình 6.4 Các miền thu được từ các vị từ được thông dịch trong
Hình 6.3.
6.4 CÁC LOẠI LỖI TRONG MIỀN
207
Tiếp theo, chúng ta xem xét hai cách giải thích của vị từ P 2 . Đối với
P 1 = Đúng,
P 2 có cách giải thích sau
P 2: x ≤ - 4
Do đó, P 2 chia thêm khu vực, hoặc tập hợp các điểm, được xác định
bởi P 1 = True thành hai tập hợp tương ứng với hai giá trị chân lý của
nó. Ranh giới P 2 , khi P 1 đánh giá là true, được biểu thị bằng đường
thẳng x = - 4. Vùng ở bên trái của ranh giới P 2 và phía trên ranh giới
P 1 tương ứng với P 1 P 2 = TT, và khu vực bên phải ranh giới P 2 và
phía trên ranh giới P 1 tương ứng với P 1 P 2 = TF.
Với P 1 = Sai, P 2 có cách hiểu như sau:
P 2 : x> 4
Nói cách khác, P 2 chia thêm khu vực, hoặc tập hợp các điểm, được
xác định bởi P 1 = False thành hai tập hợp tương ứng với hai giá trị
chân lý của nó. Ranh giới P 2 , khi P 1 đánh giá là sai, được biểu thị
bằng đường thẳng x = 4. Diện tích ở bên phải của ranh giới P 2 và bên
dưới ranh giới P 1 tương ứng với P 1 P 2 = FT, và diện tích bên trái
biên P 2 và bên dưới biên P 1 tương ứng với P 1 P 2 = FF trong Hình
6.4.
Người đọc có thể lưu ý rằng nếu một chương trình chứa k vị từ trong
một chuỗi thì số miền tối đa thu được là 2 k . Trong thực tế, số miền
thu được nhỏ hơn nhiều so với 2 k , bởi vì các tổ hợp giá trị chân trị
nhất định của k vị từ đó có thể không giữ đồng thời.
Người đọc có thể nhớ lại các thuộc tính sau của miền:
Miền là một tập hợp các giá trị mà chương trình thực hiện các phép
tính giống hệt nhau.
Một miền có thể được biểu diễn bằng một tập hợp các vị từ. Các
phần tử riêng lẻ của miền thỏa mãn các vị từ của miền.
Ví dụ: Miền TT trong Hình 6.4 được biểu diễn toán học bởi tập hợp
các vị từ trong Hình 6.5.
Từ góc độ hình học, một miền được xác định bởi một tập hợp các
ràng buộc được gọi là các bất đẳng thức biên. Các thuộc tính của một
miền được thảo luận về các thuộc tính của ranh giới của nó như sau:
P1: P2: x + y> 5 x <= ≡True
−4 ≡True
Hình 6.5 Các dự đoán xác định miền TT trong Hình 6.4.
Ranh giới đã đóng: Một ranh giới được cho là bị đóng nếu các điểm
trên ranh giới được bao gồm trong miền quan tâm.
Ví dụ: Xét miền TT trong Hình 6.4 và ranh giới của nó được xác
định bởi bất đẳng thức
P 2: x ≤ - 4
Ranh giới trên là ranh giới đóng của miền TT .
Ranh giới mở: Một ranh giới được cho là mở nếu các điểm trên ranh
giới không thuộc miền quan tâm.
Ví dụ: Xét miền TT trong Hình 6.4 và ranh giới của nó được xác
định bởi bất đẳng thức
P 1 : x + y> 5
Ranh giới trên là ranh giới mở của miền TT . Người đọc có thể nhận
thấy rằng chính ký hiệu bình đẳng ( = ) trong một toán tử quan hệ sẽ
xác định xem một ranh giới có bị đóng hay không. Nếu toán tử quan
hệ trong bất đẳng thức biên có ký hiệu đẳng thức trong đó, thì biên là
một biên đóng; nếu không thì đó là một ranh giới mở.
Miền đóng: Miền được cho là bị đóng nếu tất cả các ranh giới của nó
bị đóng.
Miền mở: Miền được cho là mở nếu một số ranh giới của nó mở.
Điểm cực trị: Điểm cực trị là điểm mà hai hoặc nhiều ranh giới giao
nhau.
Các miền liền kề: Hai miền được cho là liền kề nếu chúng có điểm
chung là bất bình đẳng về ranh giới.
Một đường dẫn chương trình sẽ có lỗi miền nếu không có công thức
sai vị từ đường dẫn. Sau khi giải thích một vị từ đường dẫn không
chính xác, biểu thức vị từ đường dẫn khiến một đoạn ranh giới
được dịch chuyển khỏi vị trí chính xác của nó hoặc
có một toán tử quan hệ không chính xác.
Lỗi miền có thể do
một vị ngữ được chỉ định không chính xác hoặc
một phép gán không chính xác ảnh hưởng đến một biến được sử
dụng trong vị từ.
Bây giờ chúng ta thảo luận về các loại lỗi miền khác nhau:
209
Lỗi đóng cửa: Lỗi đóng cửa xảy ra nếu một ranh giới đang mở khi ý
định có một ranh giới đóng, hoặc ngược lại. Một số ví dụ về lỗi đóng
cửa là:
• Toán tử quan hệ ≤ được thực hiện dưới dạng < . • Toán tử quan hệ
< được thực hiện dưới dạng ≤ .
Lỗi ranh giới dịch chuyển: Lỗi biên dịch chuyển xảy ra khi ranh giới
được thực hiện song song với đường biên dự định. Điều này xảy ra
khi số hạng không đổi của bất đẳng thức xác định ranh giới nhận một
giá trị khác với giá trị dự định. Nói một cách cụ thể, sai số dịch
chuyển biên xảy ra do sự thay đổi độ lớn hoặc dấu của số hạng không
đổi của bất đẳng thức.
Ví dụ: Hãy xem xét ranh giới được xác định bởi vị từ sau (Hình 6.4):
P 1 : x + y> 5
Nếu ý định của người lập trình là xác định một ranh giới được đại
diện bởi vị từ
: x + y> 4
thì biên được xác định bởi P 1 là song song, nhưng không trùng với
biên được xác định bởi .
Lỗi nghiêng-ranh giới: Nếu hệ số hằng số của các biến trong một vị
từ xác định ranh giới nhận các giá trị sai, thì lỗi biên nghiêng sẽ xảy
ra.
Ví dụ: Hãy xem xét ranh giới được xác định bởi vị từ sau (Hình 6.4):
P 1 : x + y> 5
Nếu ý định của người lập trình là xác định một ranh giới được đại
diện bởi vị từ
thì biên được xác định bởi P 1 nghiêng so với biên được xác định bởi
.
Người đọc có thể nhớ lại rằng đối với tất cả các điểm dữ liệu trong
một miền, chương trình sẽ thực hiện các phép tính giống hệt nhau.
Không khó để nhận thấy rằng các điểm dữ liệu đầu vào nằm trong
miền sai nếu có lỗi đóng, ranh giới bị dịch chuyển hoặc ranh giới
nghiêng. Giả sử rằng các miền có kích thước lớn nhất theo nghĩa là
các miền liền kề thực hiện các phép tính khác nhau, một chương trình
sẽ tạo ra kết quả sai do các phép tính sai được thực hiện trên các
điểm dữ liệu đầu vào nằm trong các miền sai.
6.5 ĐIỂM BẬT VÀ TẮT
Trong kiểm thử miền, lập trình viên nhắm mục tiêu các lỗi miền
trong đó các trường hợp kiểm thử được thiết kế với mục tiêu tiết lộ
các lỗi miền như đã thảo luận trong Phần 6.4. Do đó, điều cần thiết là
chúng ta phải xem xét một đặc tính quan trọng của lỗi miền, được
nêu như sau: Các điểm dữ liệu trên hoặc gần ranh giới nhạy cảm nhất
với lỗi miền. Trong quan sát này, chúng tôi nhạy cảm có nghĩa là các
điểm dữ liệu rơi vào các miền sai. Do đó, mục tiêu là xác định các
điểm dữ liệu nhạy cảm nhất với lỗi miền để có thể phát hiện lỗi bằng
cách thực hiện chương trình với các giá trị đầu vào đó. Trong phần
sau, chúng tôi xác định hai loại điểm dữ liệu gần ranh giới miền, đó
là điểm BẬT và điểm TẮT :
Điểm BẬT: Cho một đường biên, điểm BẬT là một điểm trên đường
biên hoặc “rất gần” với đường biên.
Định nghĩa này gợi ý rằng chúng ta có thể chọn điểm BẬT theo hai
cách. Do đó, người ta phải biết khi nào nên chọn một điểm BẬT theo
cách nào: • Nếu một điểm có thể được chọn nằm chính xác trên
đường biên, thì hãy chọn điểm đó làm điểm BẬT . Nếu bất đẳng thức
biên dẫn đến một giải pháp chính xác, hãy chọn một giải pháp chính
xác làm điểm BẬT .
• Nếu một bất đẳng thức biên dẫn đến một nghiệm gần đúng, hãy
chọn một điểm rất gần biên.
Ví dụ: Xét bất đẳng thức biên sau. Sự bất bình đẳng này không liên
quan đến ví dụ đang chạy của chúng ta trong Hình 6.4.
P ON1 : x + 7 y ≥ 6
Với x = - 1, vị từ P ON1 dẫn đến nghiệm chính xác của y = 1. Do đó,
điểm ( - 1, 1) nằm trên biên.
Tuy nhiên, nếu chúng ta chọn x = 0, vị từ P ON1 dẫn đến một nghiệm gần đúng của
y ở dạng y = 0,8571428 .... Vì y không có giải pháp chính xác, chúng
tôi cắt ngắn nó thành 0,857 hoặc làm tròn nó thành 0,858. Chúng tôi
nhận thấy rằng điểm (0, 0,857) không thỏa mãn vị từ P ON1 , trong khi
điểm (0, 0,858) thì có. Do đó, (0, 0,858) là một điểm ON nằm rất gần
với ranh giới P ON1 .
Ví dụ: Hãy xem xét một miền có ranh giới mở sau:
P ON2 : x + 7 y < 6
Các điểm nằm chính xác trên ranh giới được xác định bởi vị từ
211
không phải là một phần của miền đang được xem xét. Điểm ( - 1, 1)
nằm chính xác trên ranh giới P ON2 và là một điểm BẬT. Lưu ý rằng
điểm ( - 1, 1) không phải là một phần của miền đang được xem xét.
Tương tự, điểm (0, 0,858), gần như ở trên ranh giới, tức là, rất gần
với đường biên, là một điểm BẬT và nó nằm ngoài miền quan tâm.
6.5 ĐIỂM BẬT VÀ TẮT
Điểm TẮT: Điểm TẮT của một đường biên nằm cách xa đường
biên. Tuy nhiên, trong khi chọn điểm TẮT , chúng ta phải xem xét
liệu một ranh giới là mở hay đóng đối với một miền:
Nếu miền mở đối với ranh giới, thì điểm TẮT của ranh giới đó là
điểm bên trong miền trong phạm vi-khoảng cách từ ranh giới.
Nếu miền bị đóng đối với ranh giới, thì điểm TẮT của ranh giới đó
là điểm bên ngoài đường biên trong phạm vi-khoảng cách. Biểu
tượng biểu thị một giá trị nhỏ tùy ý.
Ví dụ: Xét một miền D 1 với một ranh giới đóng như sau:
P TẮT 1: x+7y≥6
Vì ranh giới bị đóng, một điểm TẮT nằm bên ngoài miền; điều này
có nghĩa là bất bình đẳng biên không được thỏa mãn. Lưu ý rằng
điểm ( - 1, 1) nằm chính xác trên ranh giới và nó thuộc miền. Do đó,
( - 1, 1) không phải là điểm TẮT. Tuy nhiên, điểm ( - 1, 0,99) nằm
ngoài miền và nó không phải là một phần của miền đang được xem
xét. Điều này dễ dàng xác minh bằng cách thay x = - 1 và y = 0,99
vào bất đẳng thức P OFF1 ở trên , tạo ra giá trị là 5,93. Do đó, ( - 1, 0,99)
là điểm TẮT.
Ví dụ: Hãy xem xét miền D 2 tiếp giáp với miền D 1 trong ví dụ trên
với một ranh giới mở như sau:
P TẮT 2 : x+7y<6
Có thể lưu ý rằng chúng ta đã thu được POFF2 từ POFF1 bằng cách
đảo ngược bất đẳng thức ≥ . Vì ranh giới P OFF2 mở, một điểm TẮT
nằm bên trong miền. Có thể dễ dàng xác minh rằng điểm ( - 1, 0,99)
nằm bên trong D 2 , và do đó nó là điểm TẮT đối với miền D 2 đối với
biên P TẮT2 .
Tóm tắt Các ý tưởng trên về điểm BẬT và TẮT dẫn đến các kết luận
sau:
Trong khi kiểm tra một ranh giới đóng, các điểm BẬT nằm trong
miền được kiểm tra, trong khi các điểm TẮT nằm trong miền liền kề.
Trong khi kiểm tra một ranh giới mở, các điểm BẬT nằm trong miền
liền kề, trong khi các điểm TẮT nằm trong miền đang được kiểm tra.
Các ý tưởng trên đã được giải thích thêm trong Hình 6.6, cho thấy
hai miền D 1 và D 2 lần lượt được xác định bởi các vị từ x < 4 và x ≥ 4.
Do đó, ranh giới thực tế được xác định bởi vị từ sau:
P BẬT , TẮT: x=4
Trong hình, chúng ta chỉ ra hai điểm BẬT A và B, trong đó A nằm
chính xác trên đường biên và B nằm “rất gần” với đường biên. Do
đó, ta có A = 4 và
Ranh giới:
Open with respect to
D1
Closed with respect to
D2
DomainD 1 (x < 4) DomainD 2 (x ≥ 4)
B
x
C
x x axix
ε
x
A
ON point forD 1 and D 2 (very close to boundary)

ON point forD 1 and D 2 (lying exactly on boundary)
Điểm TẮT đối với D 1 và D 2 (nằm cách xa biên) Hình 6.6 Các điểm
BẬT và TẮT.
B = 4.00001 chẳng hạn. Chúng tôi chỉ ra một điểm TẮT C nằm trong
D cách biên 1 . Điểm C = 3,95 nằm bên trong miền D 1 và bên ngoài
miền D 2 .
6.6 TIÊU CHUẨN LỰA CHỌN KIỂM TRA
Trong phần này, chúng tôi giải thích một tiêu chí để lựa chọn thử
nghiệm và hiển thị rằng dữ liệu thử nghiệm được chọn để tiết lộ các
lỗi miền được xác định trong Phần 6.4. Trước khi chúng tôi giải thích
213
tiêu chí lựa chọn, chúng tôi nêu các giả định được thực hiện trong thử
nghiệm miền như sau: • Một chương trình thực hiện các phép tính
khác nhau trong các miền liền kề. Nếu giả định này không đúng, thì
các điểm dữ liệu nằm trong các miền sai có thể không có bất kỳ ảnh
hưởng nào đến kết quả chương trình và do đó sẽ không quan sát được
các lỗi.
• Vị từ biên là các hàm tuyến tính của các biến đầu vào. Đây không
phải là một giả định mạnh mẽ khi cho rằng hầu hết các vị từ trong
các chương trình đời thực là tuyến tính. Điều này là do các lập trình
viên có thể dễ dàng hình dung các vị từ tuyến tính và sử dụng chúng.
Chúng tôi đưa ra tiêu chí sau để kiểm tra miền và cho thấy rằng dữ
liệu kiểm tra được chọn bằng cách sử dụng tiêu chí này tiết lộ lỗi
miền:
Tiêu chí lựa chọn thử nghiệm: Đối với từng miền và từng ranh giới,
hãy chọn ba điểm A, C và B theo trình tự BẬT – TẮT – BẬT.
Tiêu chí này tạo ra dữ liệu thử nghiệm tiết lộ lỗi miền. Cụ thể, các
loại lỗi sau được xem xét:
 Ranh giới bất bình đẳng khép kín
 Sự thay đổi ranh giới dẫn đến miền bị giảm
 Sự thay đổi ranh giới dẫn đến một miền được mở rộng
 Độ nghiêng ranh giới
 Lỗi đóng cửa
 Mở ranh giới bất bình đẳng
 Sự thay đổi ranh giới dẫn đến miền bị giảm
 Sự thay đổi ranh giới dẫn đến một miền được mở rộng
 Độ nghiêng ranh giới
 Lỗi đóng cửa
 Ranh giới bình đẳng
Trong phân tích của chúng tôi dưới đây, chúng tôi xem xét hai miền
liền kề D 1 và D 2 . Chúng ta giả sử rằng phép tính chương trình liên
quan đến D 1 và D 2 lần lượt là f 1 và f 2 , và f .
1a (Bất bình đẳng đóng) Dịch chuyển ranh giới dẫn đến miền giảm:
Ranh giới giữa hai miền D 1 và D 2 đã dịch chuyển một lượng nhất
định (xem Hình 6.7). Hình vẽ cho thấy ranh giới thực giữa hai miền
và vị trí tùy ý của ranh giới dự kiến. Người ta phải nhớ rằng chúng ta
không biết vị trí chính xác của ranh giới mong đợi. Ranh giới dự kiến
chỉ được hiển thị để giải thích rằng ranh giới thực tế đã di chuyển ra
khỏi ranh giới dự kiến để hiểu khái niệm về sự dịch chuyển ranh giới.
Ranh giới giữa hai miền được đóng lại đối với miền D 1 . Do đó, hai
6.6 TIÊU CHÍ LỰA CHỌN KIỂM TRA 215
D 2, f2 Expected boundar
y
xC
x x
A B
Actual boundary
(closed with respect toD 1)
D 1, f1
Hình 6.7 Dịch chuyển biên dẫn đến miền giảm (bất bình đẳng
đóng).
Điểm BẬT A và B thuộc miền D 1 , và điểm TẮT C thuộc miền D 2 .
Do đó đầu ra thực tế từ chương trình tương ứng với dữ liệu kiểm tra
A, B và C lần lượt là f 1 (A), f 1 (B) và f 2 (C). Rõ ràng từ Hình 6.7
rằng trong trường hợp không có bất kỳ sự dịch chuyển biên nào, tất
cả các điểm kiểm tra đều thuộc miền D 1 . Do đó, đầu ra dự kiến
tương ứng với dữ liệu kiểm tra A, B và C lần lượt là f 1 (A), f 1 (B) và
f 1 (C). Các kết quả đầu ra này được liệt kê trong Bảng 6.2. Chúng tôi
quan sát thấy, bằng cách so sánh cột thứ hai và cột thứ ba của Bảng
6.2, rằng đầu ra thực tế và đầu ra dự kiến không giống nhau đối với
điểm dữ liệu C. Do đó, điểm dữ liệu C cho thấy lỗi dịch chuyển biên.
Điều quan trọng là phải hiểu những điều sau vào thời điểm này:
Chúng ta không cần biết vị trí chính xác của ranh giới dự kiến. Điều
này là do những gì chúng ta thực sự cần là kết quả chương trình
mong đợi theo ba điểm dữ liệu A, B và C, có thể được tính toán từ
đặc điểm kỹ thuật của chương trình mà không cần tìm ra ranh giới
mong đợi một cách rõ ràng.
Cả ba điểm dữ liệu A, B và C không cần phải để lộ cùng một lỗi.
Mục đích của chúng tôi là cho thấy rằng dữ liệu thử nghiệm được
chọn theo tiêu chí đã nêu tiết lộ tất cả các lỗi miền. Mục đích được
thỏa mãn nếu ít nhất một điểm dữ liệu tiết lộ lỗi. Các phần tử khác
nhau của tập hợp { A, B, C } hiển thị các loại lỗi miền khác nhau.
Nếu điểm C cách biên một độ lớn, thì độ dịch chuyển biên có độ lớn
nhỏ hơn không thể bị phát hiện. Điều này là do đầu ra dự kiến f 2 (C)
giống với đầu ra thực tế f 2 (C).
1b (Bất bình đẳng đóng) Dịch chuyển ranh giới dẫn đến miền được
mở rộng: Để phát hiện lỗi này, chúng tôi sử dụng Hình 6.8, trong đó
ranh giới giữa hai miền D 1 và D 2 đã dịch chuyển so với vị trí dự kiến
của nó sao cho kích thước của miền D 1 dưới sự cân nhắc đã được mở
rộng. Một lần nữa, chúng tôi không biết vị trí chính xác của ranh giới
dự kiến. Ranh giới giữa hai miền được đóng lại đối với miền D 1 . Do
đó, hai điểm ON A và B thuộc miền D 1 , và điểm TẮT C thuộc miền
D 2 . Do đó, kết quả đầu ra thực tế từ chương trình tương ứng với dữ
liệu kiểm tra A, B và C lần lượt là f 1 (A), f 1 (B) và f 2 (C). Từ Hình
6.8, rõ ràng rằng, trong trường hợp không có bất kỳ sự dịch chuyển
biên nào, tất cả các điểm kiểm tra đều thuộc miền D 2 . Do đó, các
đầu ra dự kiến tương ứng với dữ liệu thử nghiệm A, B và C lần lượt
là f 2 (A), f 2 (B) và f 2 (C). Chúng tôi quan sát thấy từ Bảng 6.3 rằng
đầu ra thực tế và đầu ra dự kiến không giống nhau đối với các điểm
dữ liệu A và B. Do đó, các điểm dữ liệu A và B BẢNG 6.2 Phát
hiện sự dịch chuyển ranh giới dẫn đến miền bị giảm (Bất bình
đẳng đóng)
Dữ liệu thử Đã phát
Sản lượng thực tế Sản lượng mong đợi
nghiệm hiện lỗi
Một f 1 (A) f 1 (A) Không
B f 1 (B) f 1 (B) Không
C f 2 (C) f 1 (C) Đúng
D 2, f2
Actual boundary
xC (closed with respect to
D 1)
x x
A B
D 1, f1 Expected boundary
Hình 6.8 Sự dịch chuyển biên dẫn đến miền mở rộng (bất bình
đẳng đóng).
BẢNG 6.3 Phát hiện dịch chuyển ranh giới dẫn đến miền
được mở rộng (Bất bình đẳng đóng)
Một f 1 (A) f 2 (A) Đúng
B f 1 (B) f 2 (B) Đúng

C f 2 (C) f 2 (C) Không
bộc lộ đứt gãy biên dịch chuyển. Nếu độ lớn của sự dịch chuyển nhỏ
hơn — độ lớn mà điểm TẮT cách xa ranh giới — thì sự dịch chuyển
đường biên không thể được phát hiện bởi những dữ liệu thử nghiệm
này.
Độ nghiêng ranh giới 1c (Bất bình đẳng đóng): Trong Hình 6.9, ranh
giới giữa hai miền D 1 và D 2 đã nghiêng một lượng đáng kể. Ranh
giới giữa hai miền được đóng lại đối với miền D 1 . Do đó, hai điểm
ON A và B thuộc miền D 1 , và điểm TẮT C thuộc miền D 2 . Do đó,
kết quả đầu ra thực tế từ chương trình tương ứng với dữ liệu kiểm tra
A, B và C lần lượt là f 1 (A), f 1 (B) và f 2 (C). Rõ ràng từ Hình 6.9
rằng trong trường hợp không có bất kỳ độ nghiêng biên nào thì điểm
kiểm tra A nằm trong miền D 1 và các điểm kiểm tra B và C nằm
trong miền D 2 . Do đó, kết quả đầu ra mong đợi tương ứng với thử
nghiệm
Expected boundary
D 2, f2
xC
x x
A B
Actual boundary
D 1, f1 D 1)
(closed with respect to
Hình 6.9 Biên nghiêng (bất đẳng thức đóng).

dữ liệu A, B và C lần lượt là f 1 (A), f 2 (B) và f 2 (C). Bằng cách so
sánh cột thứ hai và cột thứ ba của Bảng 6.4, chúng tôi nhận thấy rằng
đầu ra thực tế và đầu ra dự kiến không giống nhau đối với điểm thử
nghiệm B. Do đó, điểm thử nghiệm B cho thấy lỗi biên nghiêng.
Lỗi đóng 1d (Bất bình đẳng đóng): Ranh giới dự kiến giữa hai miền
trong Hình 6.10 bị đóng đối với miền D 1 . Tuy nhiên, trong một triển
khai thực tế, nó đang mở đối với D 1 , dẫn đến lỗi đóng. Ranh giới
giữa hai miền thuộc miền D 2 . Hai điểm ON A và B thuộc miền D 2
và điểm TẮT C thuộc miền D 1 . Do đó, kết quả đầu ra thực tế từ
chương trình tương ứng với dữ liệu kiểm tra A, B và C lần lượt là f 2
(A), f 2 (B) và f 1 (C). Trong trường hợp không có bất kỳ lỗi đóng cửa
nào, cả ba điểm kiểm tra A, B và C đều nằm trong miền D 1 . Các kết
quả đầu ra này được liệt kê trong Bảng 6.5. Bằng cách so sánh cột
thứ hai và cột thứ ba của Bảng 6.5, chúng tôi nhận thấy rằng đầu ra
thực tế và đầu ra dự kiến không giống nhau đối với các điểm dữ liệu
A và B. Do đó, các điểm dữ liệu A và B tiết lộ lỗi biên đóng.
2a (Bất bình đẳng mở) Dịch chuyển ranh giới dẫn đến miền giảm: Để
giải thích việc phát hiện loại lỗi này, chúng tôi sử dụng Hình 6.11,
trong đó ranh giới giữa hai miền D 1 và D 2 đã dịch chuyển một lượng
nhất định. Ranh giới giữa hai miền là mở đối với miền D 1 . Do đó,
hai điểm ON A và B thuộc miền D 2 , và điểm TẮT C thuộc miền D 1
. Do đó, kết quả đầu ra thực tế từ chương trình tương ứng với dữ liệu
kiểm tra A, B và C lần lượt là f 2 (A), f 2 (B) và f 1 (C). Rõ ràng từ
Hình 6.11 rằng, trong trường hợp không có bất kỳ sự dịch chuyển
biên nào, tất cả các điểm kiểm tra đều thuộc miền D 1 . Do đó, kết quả
đầu ra dự kiến tương ứng với dữ liệu thử nghiệm A, B,
BẢNG 6.4 Phát hiện độ nghiêng biên (Bất bình đẳng đóng)
D 2, f2
Ranh giới mong đợi
(đóng đối với D 1 )
x x
A xC
B Ranh giới thực tế (mở đối với D 1 )
Hình 6.10 Sai số đóng (bất đẳng
D 1, f1
thức đóng).
BẢNG 6.5 Phát hiện lỗi đóng cửa
(Bất bình đẳng đóng)
D 2, f2 Expected boundar
y
x x
A x B
C Actual boundary
(open with respect to
D 1)
D 1, f1
Hình 6.11 Sự dịch chuyển biên dẫn đến miền giảm (bất bình
đẳng mở).
và C lần lượt là f 1 (A), f 1 (B) và f 1 (C). Bằng cách so sánh cột thứ
hai và cột thứ ba của Bảng 6.6, chúng tôi nhận thấy rằng đầu ra thực
tế và đầu ra dự kiến không giống nhau đối với điểm dữ liệu C. Do đó,
điểm dữ liệu C cho thấy lỗi dịch chuyển biên.
2b (Bất bình đẳng mở) Dịch chuyển ranh giới dẫn đến miền được mở
rộng: Chúng tôi sử dụng Hình 6.12 để giải thích việc phát hiện loại
lỗi này. Ranh giới giữa hai miền D 1 và D 2 đã dịch chuyển để mở
rộng kích thước của miền D 1 đang được xem xét. Ranh giới giữa hai
miền là mở đối với miền D 1 . Do đó, hai điểm ON A và B thuộc
miền D 2 , và điểm TẮT C thuộc miền D 1 . Do đó, kết quả đầu ra
thực tế từ chương trình tương ứng với dữ liệu kiểm tra A, B và C lần
lượt là f 2 (A), f 2 (B) và f 1 (C) . Theo Hình 6.12, trong trường hợp
không có bất kỳ sự dịch chuyển biên nào, tất cả các điểm kiểm tra
đều thuộc miền D 2 . Do đó, các đầu ra dự kiến tương ứng với dữ liệu
thử nghiệm A, B và C lần lượt là f 2 (A), f 2 (B) và f 2 (C). Các kết quả
đầu ra này BẢNG 6.6 Phát hiện dịch chuyển ranh giới dẫn đến
miền giảm (bất bình đẳng mở)
D 2, f2
Ranh giới thực tế
x x (mở đối với D 1 )
A x B
C Ranh giới mong đợi
D 1, f1
Hình 6.12 Sự dịch chuyển biên dẫn đến miền mở rộng (bất bình
đẳng mở).
được liệt kê trong Bảng 6.7. Từ Bảng 6.7, chúng tôi quan sát thấy
điểm dữ liệu C cho thấy lỗi dịch chuyển biên.
2c (Bất bình đẳng mở) Độ nghiêng biên: Chúng tôi giải thích lỗi
nghiêng biên bằng cách tham khảo Hình 6.13, trong đó ranh giới giữa
hai miền D 1 và D 2 bị nghiêng. Một lần nữa, chúng tôi không biết vị
trí chính xác của ranh giới dự kiến. Ranh giới giữa hai miền là mở
đối với miền D 1 . Do đó, hai điểm ON A và B thuộc miền D 2 , và
điểm TẮT C thuộc miền D 1 . Do đó, kết quả đầu ra thực tế từ
chương trình tương ứng với dữ liệu kiểm tra A, B và C lần lượt là f 2
(A), f 2 (B) và f 1 (C). Hình 6.13 cho thấy trong trường hợp không có
bất kỳ điểm kiểm tra độ nghiêng biên A và C nào nằm trong miền D 1
, và điểm kiểm tra B nằm trong miền D 2 . Do đó, các kết quả đầu ra
mong đợi tương ứng với dữ liệu thử nghiệm A, B và C lần lượt là f 1
(A), f 2 (B) và f 1 (C). Chúng tôi so sánh cột thứ hai và cột thứ ba của
Bảng 6.8 để thấy rằng đầu ra thực tế và đầu ra dự kiến không giống
nhau đối với điểm thử nghiệm A. Do đó, điểm thử nghiệm A bộc lộ
lỗi biên nghiêng.
Lỗi đóng 2d (Bất bình đẳng mở): Việc phát hiện loại lỗi này được
giải thích bằng cách sử dụng hai miền của Hình 6.14, trong đó ranh
giới dự kiến giữa hai miền là mở đối với miền D 1 . Tuy nhiên, trong
một triển khai thực tế, nó bị đóng đối với D 1 , dẫn đến lỗi đóng. Hai
điểm ON A và B thuộc miền D 1 và điểm TẮT C thuộc miền D 2 . Do
đó, kết quả đầu ra thực tế từ chương trình tương ứng với dữ liệu kiểm
tra A, B và C lần lượt là f 1 (A), f 1 (B) và f 2 (C). Hình 6.14 cho thấy
rằng, trong trường hợp không có bất kỳ lỗi đóng nào, cả ba điểm
kiểm tra A, B và C đều nằm trong miền D 2 . Bảng 6.9 cho thấy kết
quả đầu ra thực tế và kết quả đầu ra dự kiến. Bằng BẢNG 6.7 Phát
hiện dịch chuyển ranh giới dẫn đến miền được mở rộng (Bất
bình đẳng mở)
C f 1 (C) f 2 (C) Đúng

D 2, f2 Ranh giới dự kiến
Ranh giới thực tế (mở đối với D 1 )
Hình 6.13 Đường biên nghiêng
x x
A x B (bất đẳng thức mở).
C BẢNG 6.8 Phát hiện độ
D 1, f1 nghiêng biên (Bất bình đẳng mở)
So sánh cột thứ hai và cột thứ ba của Bảng 6.9, chúng tôi quan sát
thấy rằng đầu ra thực tế và đầu ra dự kiến không giống nhau đối với
các điểm dữ liệu A và B. Do đó, các điểm dữ liệu A và B tiết lộ lỗi
biên đóng.
3. Ranh giới bình đẳng: Đôi khi một miền có thể bao gồm một ranh
giới bình đẳng kẹp giữa hai miền mở, như thể hiện trong Hình 6.15,
trong đó D 1 và D 2 là hai miền mở đối với ranh giới bình đẳng chung
của chúng. Trong trường hợp này, để kiểm tra đường biên chung,
chúng tôi chọn hai điểm BẬT A và B trên đường biên và hai điểm
TẮT C và D — nằm trong mỗi miền mở.
D 2, f2
Expected boundary
(open with respect to
D 1)
xC
x x
A B
Actual boundary
(closed with respect toD 1)
D 1, f1
Figure6.14 Closureerror(openinequality).
BẢNG 6.9 Phát hiện lỗi đóng cửa (Bất bình đẳng mở)

6.7 TÓM TẮT
Hai loại lỗi chương trình, cụ thể là lỗi tính toán và lỗi miền, đã được
xác định. Lỗi tính toán xảy ra khi giá trị đầu vào khiến chương trình
thực thi đường dẫn chính xác, nhưng đầu ra chương trình không
chính xác do lỗi trong câu lệnh gán. Lỗi miền xảy ra khi giá trị đầu
vào khiến chương trình thực thi sai đường dẫn. Một chương trình
thực hiện một đường dẫn sai do lỗi trong các câu lệnh điều kiện. Một
chương trình có thể được xem như một bộ phân loại trừu tượng phân
vùng miền đầu vào thành một số miền con hữu hạn sao cho một
đường dẫn chương trình riêng biệt thực thi cho mỗi miền con đầu
vào. Do đó, một chương trình được xem là ánh xạ các miền con đầu
vào tới các đường dẫn thực thi của nó. Tên miền phụ của chương
trình có thể được xác định bằng cách xem xét các đường dẫn riêng lẻ
trong chương trình và đánh giá các vị từ đường dẫn. Mỗi miền phụ,
còn được gọi là miền, được xác định bởi một tập hợp các ranh giới.
Thông thường, các điểm dữ liệu đầu vào sẽ rơi vào miền sai nếu có
lỗi trong việc xác định ranh giới miền, do đó thực hiện sai đường
dẫn. Các miền đầu vào được đặc trưng bởi một số thuộc tính, chẳng
hạn như ranh giới đóng, ranh giới mở, miền đóng, miền mở, điểm
cực trị và miền liền kề. Tiếp theo, ba loại lỗi biên, cụ thể là lỗi đóng,
lỗi biên dịch chuyển và lỗi biên nghiêng, đã được xác định. Với một
miền và các ranh giới của nó, khái niệm về điểm BẬT và TẮT đã
được giải thích. Cuối cùng, một tiêu chí lựa chọn kiểm tra đã được
xác định để chọn các điểm kiểm tra để tiết lộ lỗi miền. Cụ thể, tiêu
chí lựa chọn như sau: Đối với mỗi miền và mỗi ranh giới, chọn ba
điểm A, C và B theo trình tự BẬT – TẮT – BẬT .
DomainD3
defined by an equality boundary
and associated computation
f3
Open x
B
D2, f2 x C
xD
Ax Open
D1, f1
Figure6.15 Equalityborder.

Kể từ khi White và Cohen đề xuất khái niệm thử nghiệm miền vào
năm 1978, nó đã được phân tích và mở rộng theo nhiều cách. Năm
1982, Clarke, Hassell và Richardson [4] đã chỉ ra rằng một số lỗi
miền không bị phát hiện bởi chiến lược White và Cohen. Tiếp theo,
họ đề xuất một chiến lược, cụ thể là chiến lược V × V, để cải thiện
thử nghiệm miền. Nếu đường viền miền đang xét chứa V đỉnh, thì
chiến lược V × V sẽ chọn V điểm BẬT — một điểm BẬT càng gần
mỗi đỉnh càng tốt — và điểm V TẮT . Các điểm V TẮT được chọn
ở một khoảng cách đồng nhất từ đường viền. Zeil, Afifi và White [5]
đã giới thiệu chiến lược kiểm tra miền để phát hiện lỗi tuyến tính
trong các hàm vị từ phi tuyến. Một vài biến thể khác của thử nghiệm
miền đã được đề xuất bởi White và Perera [6] và Onoma, Yamaura,
và Kobayashi [7].
Zeil [8] xem xét các lỗi miền có thể do lỗi trong biểu thức số học và
quan hệ đơn giản. Các biểu thức này bị hạn chế đối với các phép tính
dấu phẩy động hoặc số nguyên. Các kỹ thuật phát hiện lỗi, được gọi
là kỹ thuật nhiễu loạn, được trình bày để tiết lộ các lỗi miền.
Koh và Liu [9] đã trình bày một cách tiếp cận để tạo ra các đường
dẫn kiểm tra cả luồng điều khiển và luồng dữ liệu trong việc triển
khai các giao thức truyền thông. Các giao thức được giả định được
mô hình hóa như các máy trạng thái hữu hạn mở rộng. Cách tiếp cận
lựa chọn đường dẫn bao gồm hai bước: (i) chọn một tập hợp các
đường dẫn để bao hàm tiêu chí lựa chọn luồng dữ liệu và (ii) tăng
cường một cách có chọn lọc các chuyển đổi trạng thái trong tập hợp
đường dẫn đã chọn với trình tự kiểm tra trạng thái để đảm bảo luồng
điều khiển và vùng phủ sóng của luồng dữ liệu có thể được bảo toàn.
Việc tăng cường chuyển đổi trạng thái được thực hiện bằng cách sử
dụng khái niệm miền hiệu quả.
Jeng và Weyuker [10] đã đề xuất một chiến lược kiểm tra miền đơn
giản có thể áp dụng cho các loại vị từ tùy ý và phát hiện cả lỗi tuyến
tính và phi tuyến tính cho cả không gian biến liên tục và rời rạc. Hơn
nữa, chiến lược yêu cầu một số lượng điểm kiểm tra không đổi. Có
nghĩa là, số lượng điểm kiểm tra không phụ thuộc vào kích thước
hoặc loại đường viền hoặc số lượng đỉnh trên đường viền đang xét.
225
Kỹ thuật đơn giản hóa của họ yêu cầu chúng ta tạo một điểm BẬT và
một điểm TẮT cho một đường viền bất đẳng thức (tức là, ≤ , < , ≥ ,
hoặc > ) . Đối với đường viền bằng nhau (tức là = ) hoặc không bằng
nhau (tức là = ), cần có một điểm kiểm tra BẬT và hai điểm TẮT .
Kỹ thuật tạo thử nghiệm yêu cầu (i) điểm BẬT nằm trên đường viền,
(ii) điểm TẮT nằm ngoài đường viền và (iii) cặp BẬT-TẮT càng
gần nhau càng tốt. Hajnal và Forgacs [11] đã đưa ra một thuật toán để
tạo ra các điểm BẬT – TẮT có thể được sử dụng bởi chiến lược thử
nghiệm miền đơn giản.
Ngược lại, chiến lược lựa chọn thử nghiệm của White và Cohen [3]
yêu cầu lựa chọn N điểm BẬT trong mọi trường hợp, trong đó N là
thứ nguyên của không gian đầu vào và chiến lược Clarke, Hassell và
Richardson [4] yêu cầu lựa chọn của V điểm ON , trong đó V là số
đỉnh trên đường viền đang xét.
Zhao, Lyu và Min [12] đã nghiên cứu một cách tiếp cận để tạo ra các
điểm kiểm tra BẬT – TẮT cho các đường viền vị từ chuỗi ký tự
được liên kết với các đường dẫn chương trình. Họ sử dụng ý tưởng
cắt chương trình [13] để tính toán các giá trị hiện tại của các biến
trong các vị từ. Các tác giả tương tự đã chỉ ra trong tài liệu tham khảo
[14] rằng các chiến lược kiểm tra phân vùng tương đối không hiệu
quả trong việc phát hiện các lỗi liên quan đến những thay đổi nhỏ
trong ranh giới miền đầu vào và đã trình bày một cách tiếp cận kiểm
tra khác dựa trên phân tích miền đầu vào của các thông số kỹ thuật và
chương trình.
Có thể tìm thấy một cách xử lý công phu về kiểm tra miền trong cuốn
sách của Beizer [15]. Beizer giải thích cách ý tưởng về các miền có
thể được sử dụng trong việc thử nghiệm giao diện giữa các đơn vị
chương trình.
CHÚNG TÔI Howden. Độ tin cậy của Chiến lược Kiểm tra Phân tích
Đường dẫn. Giao dịch IEEE về Kỹ thuật phần mềm, tháng 9 năm
1976, trang 208–215.
LJ White và EI Cohen. Chiến lược miền để kiểm tra chương trình
máy tính. Bài báo được trình bày tại Hội thảo IEEE về Tài liệu và
Kiểm tra Phần mềm, Fort Lauderdale, FL, 1978, trang 335–346.
LJ White và EI Cohen. Chiến lược miền để kiểm tra chương trình

máy tính. Giao dịch IEEE về Kỹ thuật phần mềm, tháng 5 năm 1980,
trang 247–257.
L. Clarke, H. Hassell và D. Richardson. Xem xét kỹ việc kiểm tra tên
miền. Giao dịch IEEE về Kỹ thuật phần mềm, tháng 7 năm 1982,
trang 380–392.
SJ Zeil, FH Afifi và LJ White. Phát hiện lỗi tuyến tính thông qua
kiểm tra miền. Giao dịch ACM về Phương pháp và Kỹ thuật Phần
mềm, tháng 10 năm 1992, trang 422–451.
LJ White và IA Perera. Một biện pháp thay thế để phân tích lỗi của
DomainTestingStrategy. Trong Kỷ yếu của Hội thảo ACM SIGSOFT
/ IEEE về Kiểm thử Phần mềm, Banff, Canada, IEEE Press, New
York, 1986, trang 122–131.
AK Onoma, T. Yamaura và Y. Kobayashi. Các phương pháp tiếp cận
thực tế để kiểm tra miền: Cải tiến và tổng quát hóa. Trong Kỷ yếu của
COMPSAC, Tokyo, IEEE Computer Society Press, Piscataway, NJ,
1987, trang 291–297.
SJ Zeil. Kỹ thuật lo lắng để phát hiện lỗi miền. Giao dịch IEEE về Kỹ
thuật phần mềm, tháng 6 năm 1989, trang 737–746.
LS Koh và MT Liu. Lựa chọn đường dẫn thử nghiệm dựa trên tên
miền hiệu quả. Trong Kỷ yếu của Hội nghị Quốc tế về Giao thức
Mạng, Boston, IEEE Computer Society Press, Piscataway, NJ,
10/1994, trang 64–71.
B. Jeng và EJ Weyuker. Chiến lược kiểm tra miền đơn giản. Giao
dịch ACM về Phương pháp và Kỹ thuật Phần mềm, tháng 7 năm
1994, trang 254–270.
A. Hajnal và I. Forgacs. Một thuật toán tạo dữ liệu thử nghiệm áp
dụng cho các lỗi miền.Trong Kỷ yếu của Hội nghị chuyên đề quốc tế
ACM SIGSOFT về Phân tích và Kiểm tra phần mềm, Clearwater
Beach, FL, ACM Press, New York, tháng 3 năm 1998, trang 63–72.
R. Zhao, MR Lyu và Y. Min. Kiểm tra miền dựa trên dự đoán chuỗi
ký tự. Được trình bày tại Hội nghị Chuyên đề Thử nghiệm Châu Á,
Tây An, Trung Quốc, Nhà xuất bản Hiệp hội Máy tính IEEE,
Piscataway, NJ, 2003, trang 96–101.
F. Mẹo. Khảo sát về kỹ thuật cắt ghép chương trình. Tạp chí Ngôn
ngữ Lập trình, tháng 9 năm 1995, trang 121–189.
227
R. Zhao, MR Lyu và Y. Min. Phương pháp tiếp cận kiểm tra phần
mềm mới dựa trên phân tích miền của thông số kỹ thuật và chương
trình. Trong Kỷ yếu của Hội nghị chuyên đề lần thứ 14 về Kỹ thuật
Độ tin cậy của Phần mềm, Colorado, IEEE Computer Society Press,
New York, 2003, trang 60–70.
B. Beizer. Kỹ thuật kiểm thử phần mềm, xuất bản lần thứ 2. Van
Nostrand Reinhold, New York, 1990.
Bài tập
Giải thích lỗi tính toán và lỗi miền là gì.
Đưa ra một ví dụ về mã hiển thị lỗi tên miền.
Y-axis
5 D3
D1
−5 (0, 0) 5 X-axis
D2
−5
Figure6.16 Domains D 1 , D 2 ,and D 3 .

Giải thích sự khác biệt giữa thử nghiệm dựa trên luồng kiểm soát và
thử nghiệm dựa trên độc đoán.
Nhớ lại rằng chiến lược kiểm tra miền yêu cầu chúng tôi chọn các
điểm kiểm tra trên và / hoặc rất gần với ranh giới miền. Tại sao chúng
tôi không chọn các điểm thi xa ranh giới?
Xét ba miền D 1 , D 2 và D 3 được thể hiện trong Hình 6.16. Miền D 3
bao gồm tất cả các điểm nằm trên đường thẳng được chỉ định. Giả sử
rằng khoảng X và Y lớn nhất của cả ba miền lần lượt là [ - 5, 5] và [ -
5, 5], đưa ra các giá trị cụ thể của các điểm kiểm tra cho miền D 3 .
Nêu bốn loại lỗi miền và giải thích cách chúng xảy ra.
Giải thích các thuật ngữ sau: biên đóng, biên mở, miền đóng, miền
mở, điểm cực trị, miền kề.
Giải thích ý tưởng về điểm BẬT và điểm TẮT .
Giải thích rõ ràng tiêu chí lựa chọn thử nghiệm trong thử nghiệm dựa
trên miền và cho thấy lỗi bất bình đẳng đóng (dịch chuyển biên dẫn
đến miền giảm) được phát hiện bởi các điểm kiểm tra được chọn bởi
tiêu chí lựa chọn.
Xác định một số khó khăn trong việc áp dụng khái niệm kiểm thử
miền vào kiểm thử chương trình thực tế.
CHAPTER
7
SystemIntegrationTesting
Tôi chỉ trích bằng cách tạo ra, không phải bằng cách tìm ra lỗi.
—MarcusTulliusCicero
7.1 KHÁI NIỆM VỀ KIỂM TRA TÍCH HỢP
Mô-đun phần mềm, hoặc thành phần, là một phần tử độc lập của hệ
thống. Các mô-đun có giao diện được xác định rõ ràng với các mô-
đun khác. Một mô-đun có thể là một chương trình con, hàm, thủ tục,
lớp hoặc tập hợp các phần tử cơ bản đó được ghép lại với nhau để
cung cấp một dịch vụ cấp cao hơn. Hệ thống là một tập hợp các mô-
đun được kết nối với nhau theo một cách nhất định để hoàn thành
một mục tiêu hữu hình. Hệ thống con là một hệ thống tạm thời không
được tích hợp hoàn toàn với tất cả các mô-đun. Nó còn được gọi là
subassembly.
Trong các dự án vừa phải đến lớn, từ hàng chục đến hàng trăm lập
trình viên thực hiện chia sẻ mã của họ dưới dạng mô-đun. Các mô-
đun được kiểm tra riêng lẻ, thường được gọi là kiểm thử đơn vị, bởi
các lập trình viên tương ứng của họ bằng cách sử dụng các kỹ thuật
kiểm thử hộp trắng. Ở cấp độ kiểm thử đơn vị, hệ thống tồn tại từng
phần dưới sự kiểm soát của các lập trình viên. Nhiệm vụ chính tiếp
theo là đặt các mô-đun, tức là các mảnh ghép lại với nhau để tạo nên
hệ thống hoàn chỉnh. Xây dựng một hệ thống làm việc từ các phần
không phải là một nhiệm vụ đơn giản, vì nhiều lỗi giao diện. Ngay cả
việc xây dựng một hệ thống ổn định hợp lý từ các thành phần cũng
liên quan đến nhiều thử nghiệm. Đường dẫn từ các thành phần được
thử nghiệm đến xây dựng một hệ thống có thể phân phối bao gồm hai
giai đoạn thử nghiệm chính, đó là thử nghiệm tích hợp và thử nghiệm
hệ thống. Mục tiêu chính của thử nghiệm tích hợp là lắp ráp một hệ
thống ổn định hợp lý trong môi trường phòng thí nghiệm sao cho hệ
thống tích hợp có thể chịu được sự khắc nghiệt của thử nghiệm hệ
thống toàn diện trong môi trường thực tế của hệ thống. Tầm quan
230 CHƯƠNG 7 KIỂM TRA TÍCH HỢP HỆ THỐNG
trọng của kiểm thử tích hợp bắt nguồn từ ba lý do như được nêu dưới
đây. • Các mô-đun khác nhau thường được tạo bởi các nhóm các nhà
phát triển khác nhau. Các nhà phát triển có thể đang làm việc tại các
trang web khác nhau. Mặc dù chúng tôi đã nỗ lực hết sức trong việc
thiết kế hệ thống và tài liệu, nhưng việc hiểu sai, nhầm lẫn và
158
7.2 CÁC LOẠI GIAO DIỆN VÀ LỖI GIAO DIỆN KHÁC
NHAU
sơ suất có xảy ra trong thực tế. Lỗi giao diện giữa các mô-đun được
tạo ra bởi các lập trình viên khác nhau và thậm chí bởi cùng một lập
trình viên đang tràn lan. Chúng ta sẽ thảo luận về các nguồn lỗi giao
diện trong Phần 7.2.
• Kiểm tra đơn vị của các mô-đun riêng lẻ được thực hiện trong một
môi trường được kiểm soát bằng cách sử dụng trình điều khiển kiểm
tra và sơ khai. Stub là mô-đun giả chỉ trả về các giá trị được xác định
trước. Nếu một mô-đun trong kiểm thử đơn vị gọi một số mô-đun
khác, hiệu quả của kiểm thử đơn vị bị hạn chế bởi khả năng kiểm tra
hiệu quả tất cả các đường dẫn của lập trình viên. Do đó, với những
hạn chế cố hữu của kiểm thử đơn vị, rất khó để dự đoán hành vi của
một mô-đun trong môi trường thực tế của nó sau khi kiểm thử đơn vị
được thực hiện. • Một số mô-đun dễ bị lỗi hơn các mô-đun khác, vì
tính phức tạp vốn có của chúng. Điều cần thiết là xác định những cái
gây ra hầu hết các thất bại.
Mục tiêu của tích hợp hệ thống là xây dựng một phiên bản "hoạt
động" của hệ thống bằng cách (i) kết hợp các mô-đun với nhau theo
cách tăng dần và (ii) đảm bảo rằng các mô-đun bổ sung hoạt động
như mong đợi mà không làm ảnh hưởng đến chức năng của các mô-
đun đã được ghép lại với nhau. . Nói cách khác, kiểm thử tích hợp hệ
thống là một kỹ thuật có hệ thống để lắp ráp một hệ thống phần mềm
trong khi tiến hành kiểm tra để phát hiện ra các lỗi liên quan đến giao
diện. Chúng tôi đảm bảo rằng các mô-đun được đơn vị kiểm tra hoạt
động chính xác khi chúng được kết hợp với nhau theo quy định của
thiết kế. Kiểm thử tích hợp thường tiến hành từ các cụm lắp ráp con
231
nhỏ có chứa một vài mô-đun đến các cụm lớn hơn chứa ngày càng
nhiều mô-đun. Các sản phẩm phần mềm lớn, phức tạp có thể trải qua
nhiều lần lặp lại các chu trình xây dựng và kiểm tra trước khi chúng
được tích hợp hoàn toàn.
Kiểm thử tích hợp được cho là hoàn tất khi hệ thống được tích hợp
hoàn toàn với nhau, tất cả các trường hợp kiểm thử đã được thực
hiện, tất cả các lỗi nặng và trung bình được tìm thấy đã được sửa và
hệ thống được kiểm tra lại.
NHAU
Mô-đun hóa là một nguyên tắc quan trọng trong thiết kế phần mềm
và các mô-đun được giao tiếp với các mô-đun khác để thực hiện các
yêu cầu chức năng của hệ thống. Một giao diện giữa hai mô-đun cho
phép một mô-đun truy cập vào dịch vụ được cung cấp bởi mô-đun
kia. Nó thực hiện một cơ chế để chuyển điều khiển và dữ liệu giữa
các mô-đun. Ba mô hình phổ biến cho các mô-đun giao tiếp như sau:
Giao diện cuộc gọi thủ tục: Một thủ tục trong một mô-đun gọi một
thủ tục trong một mô-đun khác. Người gọi chuyển quyền điều khiển
cho mô-đun được gọi. Người gọi có thể chuyển dữ liệu cho thủ tục
được gọi và thủ tục được gọi có thể chuyển dữ liệu cho người gọi
trong khi trả lại quyền điều khiển cho người gọi.
Giao diện bộ nhớ dùng chung: Một khối bộ nhớ được chia sẻ giữa
hai mô-đun. Khối bộ nhớ có thể được cấp phát bởi một trong hai mô-
đun
hoặc một mô-đun thứ ba. Dữ liệu được ghi vào khối bộ nhớ bởi một
mô-đun và được đọc từ khối kia.
Giao diện truyền thông báo: Một mô-đun chuẩn bị thông báo bằng
cách khởi tạo các trường của cấu trúc dữ liệu và gửi thông báo đến
mô-đun khác. Hình thức tương tác mô-đun này phổ biến trong các hệ
thống dựa trên máy khách-máy chủ và hệ thống dựa trên web.
Lập trình viên kiểm tra các mô-đun để họ hài lòng. Câu hỏi đặt ra là:
Nếu tất cả các mô-đun được kiểm tra đơn vị hoạt động riêng lẻ, tại
sao các mô-đun này lại không thể hoạt động khi được đặt cùng nhau?
Vấn đề nảy sinh khi chúng ta “ghép chúng lại với nhau” vì lỗi giao
diện tràn lan. Lỗi giao diện là những lỗi liên quan đến cấu trúc tồn tại
bên ngoài môi trường cục bộ của mô-đun nhưng mô-đun đó sử dụng
[1]. Perry và Evangelist [2] đã báo cáo vào năm 1987 rằng lỗi giao
diện chiếm tới một phần tư tổng số lỗi trong hệ thống mà họ đã kiểm
tra. Họ phát hiện ra rằng trong số tất cả các lỗi cần sửa trong một mô-
đun, hơn một nửa là do lỗi giao diện. Perry và Evangelist đã phân
loại các lỗi giao diện như sau:
Xây dựng: Một số ngôn ngữ lập trình, chẳng hạn như C, thường tách
biệt đặc tả giao diện khỏi mã thực thi. Trong chương trình C, người
lập trình có thể viết một câu lệnh #include header.h, trong đó
header.h chứa một đặc tả giao diện. Vì đặc điểm kỹ thuật giao diện
nằm ở đâu đó so với mã thực tế, các lập trình viên bỏ qua đặc điểm
kỹ thuật giao diện trong khi viết mã. Do đó, việc sử dụng câu lệnh
#include không phù hợp sẽ gây ra lỗi xây dựng.
Chức năng không đầy đủ: Đây là những lỗi gây ra bởi các giả định
ngầm trong một phần của hệ thống rằng phần khác của hệ thống sẽ
thực hiện một chức năng. Tuy nhiên, trên thực tế, “phần khác” không
cung cấp chức năng như mong đợi - do người lập trình đã viết mã
phần kia cố ý hay vô ý.
Vị trí của chức năng: Sự bất đồng hoặc hiểu sai về vị trí của chức
năng trong phần mềm dẫn đến loại lỗi này. Vấn đề nảy sinh do
phương pháp luận thiết kế, vì những tranh chấp này không nên xảy ra
ở cấp mã. Cũng có thể do nhân viên thiếu kinh nghiệm góp phần gây
ra vấn đề.
Các thay đổi về chức năng: Thay đổi một mô-đun mà không điều
chỉnh chính xác sự thay đổi đó trong các mô-đun liên quan khác sẽ
ảnh hưởng đến chức năng của chương trình.
Chức năng được bổ sung: Một mô-đun chức năng hoàn toàn mới,
hoặc khả năng, đã được thêm vào dưới dạng sửa đổi hệ thống. Bất kỳ
chức năng được bổ sung nào sau khi mô-đun được đăng ký vào hệ
thống kiểm soát phiên bản mà không có CR đều được coi là lỗi.
Sử dụng sai giao diện: Một mô-đun mắc lỗi khi sử dụng giao diện
của mô-đun được gọi. Điều này có thể xảy ra trong giao diện cuộc
gọi thủ tục. Lạm dụng giao diện có thể ở dạng sai loại tham số, sai
thứ tự tham số hoặc truyền sai số lượng tham số.
NHAU
Hiểu sai về giao diện: Một mô-đun gọi có thể hiểu sai đặc điểm kỹ
thuật giao diện của một mô-đun được gọi. Mô-đun được gọi có thể
233
giả định rằng một số tham số được truyền tới nó thỏa mãn một điều
kiện nhất định, trong khi người gọi không đảm bảo rằng điều kiện đó
được giữ nguyên. Ví dụ, giả sử rằng một mô-đun được gọi sẽ trả về
chỉ số của một phần tử trong một mảng các số nguyên. Mô-đun được
gọi có thể chọn thực hiện tìm kiếm nhị phân với giả định rằng mô-
đun gọi cung cấp cho nó một mảng được sắp xếp. Nếu người gọi
không sắp xếp được mảng trước khi gọi mô-đun thứ hai, chúng ta sẽ
có một trường hợp hiểu nhầm giao diện.
Thay đổi cấu trúc dữ liệu: Đây có bản chất tương tự như các vấn đề
chức năng đã thảo luận ở trên, nhưng chúng có khả năng xảy ra ở cấp
độ thiết kế chi tiết. Vấn đề phát sinh khi kích thước của cấu trúc dữ
liệu không đủ hoặc nó không chứa đủ số lượng trường thông tin. Vấn
đề bắt nguồn từ việc thiết kế cấp cao không xác định được đầy đủ các
yêu cầu về khả năng của cấu trúc dữ liệu. Chúng ta hãy xem xét một
ví dụ trong đó một mô-đun đọc dữ liệu và giữ nó trong một cấu trúc
bản ghi. Mỗi bản ghi chứa tên người, sau đó là số nhân viên và mức
lương của họ. Bây giờ, nếu cấu trúc dữ liệu được xác định cho 1000
bản ghi, thì khi số lượng bản ghi tăng lên vượt quá 1000, chương
trình chắc chắn bị lỗi. Ngoài ra, nếu ban quản lý quyết định trao tiền
thưởng cho một vài nhân viên xuất sắc, có thể sẽ không có bất kỳ
không gian lưu trữ nào được phân bổ cho các thông tin bổ sung.
Xử lý lỗi không đầy đủ: Mô-đun được gọi có thể trả về mã lỗi cho
mô-đun đang gọi. Tuy nhiên, mô-đun gọi có thể không xử lý được lỗi
đúng cách.
Bổ sung cho Xử lý Lỗi: Những lỗi này là do các thay đổi đối với các
mô-đun khác đã chỉ định các thay đổi trong việc xử lý lỗi mô-đun.
Trong trường hợp này, chức năng cần thiết bị thiếu trong quá trình xử
lý lỗi hiện tại có thể giúp theo dõi lỗi hoặc các kỹ thuật xử lý lỗi hiện
tại yêu cầu sửa đổi.
Xử lý hậu kỳ không đầy đủ: Những lỗi này là do lỗi chung trong việc
giải phóng các tài nguyên không còn cần thiết, ví dụ: không thể phân
bổ bộ nhớ.
Hỗ trợ giao diện không đầy đủ: Chức năng thực tế được cung cấp
không đủ để hỗ trợ các khả năng được chỉ định của giao diện. Ví dụ:
một mô-đun chuyển giá trị nhiệt độ bằng độ C cho một mô-đun diễn
giải giá trị bằng độ F.
Lỗi khởi tạo / giá trị: Không thể khởi tạo hoặc gán giá trị thích hợp
cho cấu trúc dữ liệu biến đổi dẫn đến loại lỗi này. Các vấn đề kiểu
này thường do sơ suất đơn giản. Ví dụ, giá trị của một con trỏ có thể
thay đổi; nó có thể trỏ đến ký tự đầu tiên trong một chuỗi, sau đó đến
ký tự thứ hai, sau đó đến ký tự thứ ba, v.v. Nếu lập trình viên quên
khởi động lại con trỏ trước khi sử dụng lại hàm đó, con trỏ cuối cùng
có thể trỏ đến mã.
Vi phạm Ràng buộc Dữ liệu: Việc triển khai không hỗ trợ mối quan
hệ cụ thể giữa các mục dữ liệu. Điều này có thể xảy ra do thông số
kỹ thuật thiết kế chi tiết không đầy đủ.
Các vấn đề về thời gian / hiệu suất: Những lỗi này là do đồng bộ hóa
không đầy đủ giữa các quá trình giao tiếp. Điều kiện cuộc đua là một
ví dụ về các loại lỗi này. Trong cuộc đua cổ điển, có hai sự kiện có
thể xảy ra là sự kiện a và sự kiện b lần lượt xảy ra trong quá trình
giao tiếp quy trình A và quy trình B. Có cơ sở hợp lý để mong đợi sự
kiện a trước sự kiện b. Tuy nhiên, trong một điều kiện bất thường, sự
kiện b có thể xảy ra trước sự kiện a. Chương trình sẽ thất bại nếu nhà
phát triển phần mềm không lường trước khả năng xảy ra sự kiện b
trước sự kiện a và không viết bất kỳ đoạn mã nào để đối phó với tình
huống này.
Phối hợp các thay đổi: Những lỗi này do không thông báo được các
thay đổi đối với một mô-đun phần mềm cho những người chịu trách
nhiệm về các mô-đun có liên quan khác nhau.
Giao diện Phần cứng / Phần mềm: Những lỗi này phát sinh do việc
xử lý phần mềm của các thiết bị phần cứng không đầy đủ. Ví dụ, một
chương trình có thể gửi dữ liệu với tốc độ cao cho đến khi bộ đệm
đầu vào của thiết bị được kết nối đầy. Sau đó, chương trình phải tạm
dừng cho đến khi thiết bị giải phóng bộ đệm đầu vào của nó. Chương
trình có thể không nhận ra tín hiệu từ thiết bị rằng nó không còn sẵn
sàng để nhận thêm dữ liệu. Mất dữ liệu sẽ xảy ra do sự thiếu đồng bộ
giữa chương trình và thiết bị.
Lỗi giao diện không thể được phát hiện bằng cách thực hiện kiểm thử
đơn vị trên các mô-đun vì kiểm thử đơn vị khiến quá trình tính toán
xảy ra trong một mô-đun, trong khi tương tác bắt buộc phải xảy ra
giữa các mô-đun để phát hiện lỗi giao diện. Rất khó để quan sát các
lỗi giao diện bằng cách thực hiện kiểm tra mức hệ thống, vì những
235
lỗi này có xu hướng được chôn giấu trong nội bộ hệ thống. Những ưu
điểm chính của việc tiến hành thử nghiệm tích hợp hệ thống như sau:
Các khiếm khuyết được phát hiện sớm.
Nó dễ dàng hơn để sửa chữa các khuyết tật được phát hiện trước đó.
Chúng tôi nhận được phản hồi sớm hơn về sức khỏe và khả năng
chấp nhận của các mô-đun riêng lẻ và trên hệ thống tổng thể.
Lập lịch sửa chữa các khiếm khuyết rất linh hoạt và nó có thể trùng
lặp với quá trình phát triển.
Kiểm thử tích hợp hệ thống được thực hiện bởi nhóm tích hợp hệ
thống, còn được gọi là nhóm kỹ thuật xây dựng. Các kỹ sư kiểm thử
tích hợp cần phải biết chi tiết của các mô-đun phần mềm. Điều này
có nghĩa là đội ngũ kỹ sư xây dựng các mô-đun cần phải tham gia
vào quá trình tích hợp hệ thống. Người kiểm tra tích hợp nên quen
thuộc với các cơ chế giao diện. Các kiến trúc sư hệ thống nên tham
gia vào việc thử nghiệm tích hợp của các hệ thống phần mềm phức
tạp vì thực tế là họ có bức tranh toàn cảnh hơn về hệ thống.
7.3 CẤP CỨU CỦA KIỂM TRA TÍCH HỢP HỆ THỐNG
7.3 CẤP CỨU CỦA KIỂM TRA TÍCH HỢP HỆ THỐNG
Kiểm tra tích hợp hệ thống được thực hiện ở các mức độ chi tiết khác
nhau. Kiểm thử tích hợp bao gồm cả cách tiếp cận kiểm tra hộp trắng
và hộp đen. Kiểm thử hộp đen bỏ qua các cơ chế bên trong của hệ
thống và chỉ tập trung vào các đầu ra được tạo ra để đáp ứng với các
đầu vào và điều kiện thực thi đã chọn. Mã được coi là một hộp đen
lớn bởi người kiểm tra không thể kiểm tra các chi tiết bên trong của
hệ thống. Người kiểm tra biết đầu vào của hộp đen và quan sát kết
quả mong đợi của việc thực thi. Kiểm thử hộp trắng sử dụng thông
tin về cấu trúc của hệ thống để kiểm tra tính đúng đắn của nó. Nó có
tính đến các cơ chế bên trong của hệ thống và các mô-đun. Trong
phần sau, chúng tôi giải thích các ý tưởng về thử nghiệm giữa các hệ
thống, thử nghiệm liên hệ thống và thử nghiệm theo cặp.
Kiểm thử giữa các hệ thống: Hình thức kiểm thử này tạo thành kiểm
thử tích hợp mức độ thấp với mục tiêu kết hợp các mô-đun lại với
nhau để xây dựng một hệ thống gắn kết. Quá trình kết hợp các mô-
đun có thể tiến triển theo cách tăng dần giống như việc xây dựng và
thử nghiệm các bản dựng kế tiếp, được giải thích trong Phần 7.4.1.
Ví dụ, trong một hệ thống dựa trên máy khách-máy chủ, cả máy
khách và máy chủ đều là các thực thể riêng biệt chạy ở các vị trí khác
nhau. Trước khi các tương tác của máy khách với máy chủ được
kiểm tra, điều cần thiết là phải xây dựng riêng máy khách và hệ
thống máy chủ từ các tập hợp mô-đun tương ứng của chúng theo kiểu
gia tăng. Tài liệu thiết kế cấp thấp, trình bày chi tiết đặc điểm kỹ
thuật của các mô-đun trong kiến trúc, là nguồn của các trường hợp
kiểm thử.
Kiểm thử giữa các hệ thống: Kiểm tra giữa các hệ thống là một giai
đoạn kiểm tra cấp cao, yêu cầu giao tiếp các hệ thống được kiểm tra
độc lập. Trong giai đoạn này, tất cả các hệ thống được kết nối với
nhau và việc kiểm tra được tiến hành từ đầu đến cuối. Thuật ngữ end
to end được sử dụng trong các hệ thống giao thức truyền thông và
thử nghiệm end-to-end có nghĩa là bắt đầu thử nghiệm giữa hai thiết
bị đầu cuối truy cập được kết nối với nhau bởi một mạng. Mục đích
trong trường hợp này là để đảm bảo rằng sự tương tác giữa các hệ
thống hoạt động cùng nhau, nhưng không phải để thực hiện một thử
nghiệm toàn diện. Chỉ một tính năng được thử nghiệm tại một thời
điểm và trên cơ sở giới hạn. Sau đó, tại thời điểm kiểm tra hệ thống,
một bài kiểm tra toàn diện được tiến hành dựa trên các yêu cầu và
điều này bao gồm chức năng, khả năng tương tác, căng thẳng, hiệu
suất, v.v. Tích hợp hệ thống máy khách-máy chủ, sau khi tích hợp
riêng mô-đun máy khách và mô-đun máy chủ, là một ví dụ về thử
nghiệm liên hệ thống. Tích hợp hệ thống kiểm soát cuộc gọi và hệ
thống thanh toán trong mạng điện thoại là một ví dụ khác về thử
nghiệm liên hệ thống. Các trường hợp kiểm thử có nguồn gốc từ tài
liệu thiết kế cấp cao, trình bày chi tiết kiến trúc hệ thống tổng thể.
Kiểm thử theo cặp: Có thể có nhiều cấp độ trung gian của kiểm tra
tích hợp hệ thống giữa hai cấp độ cực đoan trên, đó là kiểm tra giữa
các hệ thống và kiểm tra liên hệ thống. Thử nghiệm theo cặp là một
loại thử nghiệm tích hợp ở mức độ trung gian. Trong tích hợp theo
cặp, chỉ có hai hệ thống được kết nối với nhau trong một hệ thống
tổng thể được thử nghiệm tại một thời điểm. Mục đích của thử
nghiệm theo cặp là để đảm bảo rằng hai hệ thống đang được xem xét
có thể hoạt động cùng nhau, giả định rằng các hệ thống khác trong
môi trường tổng thể hoạt động như mong đợi. Toàn bộ cơ sở hạ tầng
mạng cần phải có để hỗ trợ việc kiểm tra các tương tác của hai hệ
thống, nhưng phần còn lại của các hệ thống không phải là đối tượng
237
của các bài kiểm tra. Cơ sở hạ tầng kiểm tra mạng phải đơn giản và
ổn định trong quá trình kiểm tra theo cặp. Mặc dù kiểm tra theo cặp
nghe có vẻ đơn giản, nhưng một số vấn đề có thể làm phức tạp quá
trình kiểm tra. Vấn đề lớn nhất là tác dụng phụ ngoài ý muốn. Ví dụ,
trong thử nghiệm giao tiếp giữa một phần tử mạng (nút vô tuyến) và
hệ thống quản lý phần tử, nếu một thiết bị khác (bộ điều khiển nút vô
tuyến) trong mạng dữ liệu không dây 1xEV-DO, được thảo luận
trong Chương 8, không thành công trong quá trình thử nghiệm, nó có
thể kích hoạt một lượng lớn bẫy đối với hệ thống quản lý yếu tố.
Việc tháo gỡ khối lượng lớn bẫy này có thể khó khăn.
7.4 KỸ THUẬT TÍCH HỢP HỆ THỐNG
Một trong những mục tiêu của kiểm thử tích hợp là kết hợp các mô-
đun phần mềm thành một hệ thống làm việc để có thể thực hiện các
bài kiểm tra mức hệ thống trên toàn bộ hệ thống. Kiểm thử tích hợp
không cần đợi cho đến khi tất cả các mô-đun của hệ thống được mã
hóa và kiểm tra đơn vị. Thay vào đó, nó có thể bắt đầu ngay khi có
các mô-đun liên quan. Một mô-đun được cho là có sẵn để kết hợp với
các mô-đun khác khi biểu mẫu yêu cầu đăng ký của mô-đun, sẽ được
thảo luận trong phần này, đã sẵn sàng. Một số cách tiếp cận phổ biến
để thực hiện tích hợp hệ thống như sau:
Tăng dần
Từ trên xuống
Từ dưới lên
Bánh mì sandwich
Vụ nổ lớn
Trong phần còn lại của phần này, chúng tôi giải thích các cách tiếp
cận trên.
7.4.1 Gia tăng
Theo cách tiếp cận này, thử nghiệm tích hợp được tiến hành theo
cách gia tăng như một loạt các chu kỳ thử nghiệm như Deutsch đề
xuất [3]. Trong mỗi chu kỳ thử nghiệm, một vài mô-đun khác được
tích hợp với một bản dựng hiện có và đã được thử nghiệm để tạo ra
một bản dựng lớn hơn. Ý tưởng là hoàn thành một chu kỳ thử
nghiệm, để các nhà phát triển sửa chữa tất cả các lỗi được tìm thấy và
tiếp tục chu kỳ thử nghiệm tiếp theo. Hệ thống hoàn chỉnh được xây
dựng từng bước, từng chu kỳ, cho đến khi toàn bộ hệ thống hoạt
động và sẵn sàng cho thử nghiệm cấp hệ thống.
Hệ thống được xây dựng như một sự liên tiếp của các lớp, bắt đầu
với một số mô-đun cốt lõi. Trong mỗi chu kỳ, một lớp mới được
thêm vào lõi và được kiểm tra để tạo thành lõi mới. Lõi mới nhằm
mục đích khép kín và ổn định. Ở đây, “khép kín” có nghĩa là chứa tất
cả mã cần thiết để hỗ trợ một tập hợp các chức năng và “ổn định” có
nghĩa là hệ thống con (tức là hệ thống mới, một phần) có thể hoạt
động trong 24 giờ mà không có bất kỳ sự bất thường nào. Số lượng
chu kỳ kiểm tra tích hợp hệ thống và tổng thời gian tích hợp được
xác định bởi các tham số sau:
7.4 KỸ THUẬT TÍCH HỢP HỆ THỐNG 239
Số lượng mô-đun trong hệ thống

Độ phức tạp tương đối của các mô-đun (độ phức tạp theo chu kỳ)
Độ phức tạp tương đối của các giao diện giữa các mô-đun
Số lượng mô-đun cần thiết để được nhóm lại với nhau trong mỗi chu
kỳ thử nghiệm
Liệu các mô-đun được tích hợp đã được kiểm tra đầy đủ trước đó hay
chưa
Thời gian quay vòng cho mỗi chu kỳ kiểm tra – gỡ lỗi – sửa chữa
Xây dựng một bản dựng là một quá trình mà các mô-đun riêng lẻ
được tích hợp để tạo thành một hình ảnh phần mềm tạm thời. Hình
ảnh phần mềm là một tệp nhị phân phần mềm được biên dịch. Bản
dựng là một hình ảnh phần mềm tạm thời để thử nghiệm nội bộ trong
tổ chức. Cuối cùng, bản dựng cuối cùng sẽ là một ứng cử viên để thử
nghiệm hệ thống và một hệ thống đã được thử nghiệm như vậy sẽ
được phát hành cho khách hàng. Việc xây dựng một hình ảnh phần
mềm bao gồm các hoạt động sau:
Thu thập các phiên bản mô-đun được cấp phép, thử nghiệm của đơn
vị mới nhất
Biên dịch mã nguồn của các mô-đun đó
Kiểm tra mã đã biên dịch vào kho lưu trữ
Liên kết các mô-đun đã biên dịch thành các cụm lắp ráp con
Xác minh rằng các cụm lắp ráp phụ là chính xác
Thực hiện kiểm soát phiên bản
Một bản dựng đơn giản chỉ liên quan đến một số lượng nhỏ các mô-
đun được tích hợp với một bản dựng đã được thử nghiệm trước đó
trên một nền tảng đáng tin cậy và được hiểu rõ. Không có công cụ
hoặc thủ tục đặc biệt nào cần được phát triển và lập thành tài liệu để
xây dựng đơn giản. Mặt khác, các quy trình có tổ chức, được lập
thành văn bản được áp dụng cho các bản dựng phức tạp. Quá trình
xây dựng trở nên phức tạp nếu một số lượng lớn các mô-đun được
tích hợp với nhau và một số lượng lớn các mô-đun đó là mới với các
giao diện phức tạp. Các giao diện này có thể nằm giữa các mô-đun
phần mềm và thiết bị phần cứng, trên các nền tảng và giữa các mạng.
Đối với các bản dựng phức tạp, công cụ kiểm soát phiên bản được
khuyên dùng để tự động hóa quá trình xây dựng và để quay vòng
nhanh chu kỳ kiểm tra-gỡ lỗi-sửa chữa.
Việc tạo bản dựng hàng ngày [4] rất phổ biến trong nhiều tổ chức vì
nó tạo điều kiện cho việc phân phối hệ thống nhanh hơn. Nó nhấn
mạnh vào thử nghiệm gia tăng nhỏ, tăng đều đặn số lượng trường hợp
thử nghiệm và thử nghiệm hồi quy từ bản dựng này sang bản dựng
khác. Hệ thống tích hợp được kiểm tra bằng cách sử dụng các trường
hợp kiểm thử tự động, có thể tái sử dụng. Nỗ lực được thực hiện để
sửa chữa các khiếm khuyết được tìm thấy trong chu kỳ thử nghiệm.
Một phiên bản mới của hệ thống được xây dựng từ các mô-đun hiện
có, được sửa đổi và mới được phát triển và có sẵn để kiểm tra lại. Các
phiên bản trước của bản dựng được giữ lại để tham khảo và khôi
phục. Nếu không tìm thấy khiếm khuyết trong mô-đun của bản dựng
trong đó mô-đun đã được giới thiệu, thì mô-đun sẽ được chuyển tiếp
từ bản dựng này sang bản dựng khác cho đến khi tìm thấy một lỗi. Có
quyền truy cập vào phiên bản mà mô-đun bị lỗi được giới thiệu ban
đầu rất hữu ích trong việc gỡ lỗi và sửa chữa, hạn chế tác dụng phụ
của các bản sửa lỗi và thực hiện phân tích nguyên nhân gốc rễ. Trong
quá trình phát triển, tích hợp và thử nghiệm hệ thống, một thông lệ
điển hình là giữ lại 7–10 bản dựng trước đây.
Nhà phát triển phần mềm điền vào biểu mẫu yêu cầu đăng ký trước
khi mô-đun phần mềm mới hoặc mô-đun có sửa lỗi được tích hợp vào
một bản dựng. Biểu mẫu được nhóm kỹ sư xây dựng xem xét để phê
duyệt. Sau khi nó được chấp thuận, mô-đun có thể được xem xét để
tích hợp. Các phần chính của mẫu đăng ký được nêu trong Bảng 7.1.
Ý tưởng đằng sau việc có cơ chế yêu cầu đăng ký là gấp bốn lần:
Tất cả các tệp yêu cầu cập nhật phải được xác định và các thành viên
khác trong nhóm biết.
Mã mới phải được xem xét trước khi tích hợp.
Mã mới phải được kiểm tra đơn vị.
Phạm vi đăng ký được xác định.
Ghi chú phát hành chứa thông tin sau đi kèm với một bản dựng:
Điều gì đã thay đổi kể từ lần xây dựng cuối cùng?
Những khiếm khuyết còn tồn tại nào đã được sửa chữa?
Những khiếm khuyết nổi bật trong bản dựng là gì?
Những mô-đun hoặc tính năng mới nào đã được thêm vào?
BẢNG 7.1 Biểu mẫu yêu cầu đăng ký
Author Name of the person requesting

this check-in
Today’s date month, day, year
Check-in request date month, day, year
Category (identify all that apply) New Feature: (Y, N)
Enhancement: (Y, N)
Defect: (Y, N); if yes: defect
numbers:
Are any of these major defects:
(Y, N)
Are any of these moderate
defects: (Y, N)
Short description of check-in Describe in a short paragraph the
feature, the enhancement, or the
defect fixes to be checked in.
Number of files to be checked in Give the number of files to be
checked in. Include the file
names, if possible.
Code reviewer names Provide the names of the code
reviewers.
Command line interface changes (Y, N); if yes, were they:
made Documented? (Y, N)
Reviewed? (Y, N, pending)
Does this check-in involve (Y, N); if yes, include the header
changes to global header? file names.
Does this check-in involve (Y, N); if yes, were they
changes in output logging? documented? (Y, N)
Unit test description Description of the unit tests
conducted
Comments Any other comments and issues
Những mô-đun hoặc tính năng hiện có nào đã được nâng cao, sửa đổi
hoặc xóa?
Có bất kỳ khu vực nào mà các thay đổi không xác định có thể đã xảy
ra không?
Chiến lược thử nghiệm được tạo cho mỗi bản dựng mới dựa trên
thông tin trên. Các vấn đề sau được giải quyết trong khi lập kế hoạch
chiến lược thử nghiệm:
Những trường hợp kiểm thử nào cần được chọn từ kế hoạch kiểm thử
tích hợp hệ thống, như đã thảo luận trong Phần 7.6, để kiểm tra các
thay đổi? Các trường hợp thử nghiệm này có cung cấp phạm vi tính
năng của các tính năng mới và được sửa đổi không? Nếu cần, hãy
thêm các trường hợp thử nghiệm mới vào kế hoạch thử nghiệm tích
hợp hệ thống.
Những trường hợp kiểm thử hiện có nào có thể được sử dụng lại mà
không cần sửa đổi để kiểm tra hệ thống đã sửa đổi? Những trường
hợp thử nghiệm không thành công nào trước đây nên được thực thi lại
để kiểm tra các bản sửa lỗi trong bản dựng mới?
Phạm vi của kiểm thử hồi quy từng phần nên được xác định như thế
nào? Một kiểm tra hồi quy đầy đủ có thể không được chạy trên mỗi
bản dựng do việc quay vòng các bản dựng thường xuyên. Ít nhất, bất
kỳ trường hợp thử nghiệm nào trước đó liên quan đến các khu vực đã
được sửa đổi phải được thực thi lại. • Thời gian ước tính, nhu cầu tài
nguyên và chi phí để kiểm tra bản dựng này là bao nhiêu? Một số bản
dựng có thể bị bỏ qua dựa trên ước tính này và các hoạt động hiện tại,
vì các kỹ sư kiểm tra tích hợp có thể chọn đợi bản dựng sau.
7.4.2 Từ trên xuống
Các hệ thống có cấu trúc phân cấp dễ dàng áp dụng các cách tiếp cận
tích hợp từ trên xuống và từ dưới lên. Trong hệ thống phân cấp, có
một mô-đun cấp cao nhất, thứ nhất được phân tách thành một vài mô-
đun cấp hai. Một số mô-đun cấp hai có thể được tiếp tục phân tách
thành các mô-đun cấp ba, v.v. Một số hoặc tất cả các mô-đun ở bất kỳ
cấp nào có thể là mô-đun đầu cuối, trong đó mô-đun đầu cuối là mô-
đun không bị phân hủy nữa. Một mô-đun nội bộ, còn được gọi là mô-
đun danh nghĩa, thực hiện một số tính toán, gọi các mô-đun cấp dưới
của nó và trả lại quyền điều khiển và kết quả cho người gọi của nó.
Trong các phương pháp tiếp cận từ trên xuống và từ dưới lên, một tài
liệu thiết kế cung cấp hệ thống phân cấp mô-đun được sử dụng làm
tài liệu tham khảo để tích hợp các mô-đun. Ví dụ về phân cấp mô-đun
được thể hiện trong Hình 7.1, trong đó mô-đun A là mô-đun trên
cùng; mô-đun A đã được phân tách thành các mô-đun B, C và D. Các
mô-đun B, D, E, F và G là các mô-đun đầu cuối, vì chúng chưa được

phân rã thêm. Cách tiếp cận từ trên xuống được giải thích như sau:
Bước 1: Để IM đại diện cho tập hợp các mô-đun đã được tích hợp và
D các sơ khai cần thiết. Ban đầu, IM chứa mô-đun cấp cao nhất và các
sơ khai tương ứng với tất cả các mô-đun cấp dưới của cấp cao nhất
G
Hình 7.1 Hệ thống phân cấp mô-đun với ba cấp và bảy mô-đun.
mô-đun. Giả định rằng mô-đun cấp cao nhất đã vượt qua
tiêu chí đầu vào của nó.
Bước Chọn một thành viên sơ khai M trong IM đã đặt. Gọi M là
2: môđun thực tương ứng với sơ khai M . Chúng tôi nhận được
tập hợp CM mới từ IM bằng cách thay thế sơ khai M với M
và bao gồm trong CM tất cả các sơ khai tương ứng với các
mô-đun cấp dưới của M. Chúng tôi coi CM là một hợp của
bốn tập hợp: { M } , CMs, CMi, CMr, trong đó CM là tập
hợp sơ khai, CMi là tập hợp mô-đun có giao diện trực tiếp
với M và CMr là phần còn lại của các mô-đun trong CM.
Bước Bây giờ, hãy kiểm tra hành vi kết hợp của CM. Kiểm tra CM
3: có nghĩa là áp dụng đầu vào cho mô-đun cấp cao nhất của hệ
thống. Có thể lưu ý rằng mặc dù nhóm tích hợp có quyền
truy cập vào mô-đun trên cùng của hệ thống, nhưng không
thể thực hiện tất cả các loại kiểm tra. Điều này rõ ràng là
CM không đại diện cho hệ thống đầy đủ. Trong bước này,
nhóm tích hợp kiểm tra một tập hợp con các chức năng hệ
thống được thực hiện bởi các mô-đun thực tế trong CM.
Nhóm tích hợp thực hiện hai loại kiểm tra:
Chạy các trường hợp thử nghiệm để phát hiện bất kỳ lỗi giao
diện nào giữa M và các thành viên của CMi.
Thực hiện kiểm tra hồi quy để đảm bảo rằng sự tích hợp của
các mô-đun trong hai bộ CMi và CMr là thỏa mãn khi có
mặt của mô-đun M. Người ta có thể lưu ý rằng trong các lần
lặp trước, các giao diện giữa các mô-đun trong CMi và CMr
đã được kiểm tra và các lỗi đã được khắc phục. Tuy nhiên,
các thử nghiệm nói trên được thực hiện với M —Một sơ khai
của M — chứ không phải M. Sự hiện diện của M trong hệ
thống tích hợp cho đến thời điểm này cho phép chúng tôi
kiểm tra các giao diện giữa các mô-đun trong tập hợp CMi
và CMr kết hợp, vì khả năng hệ thống hỗ trợ nhiều chức

năng hơn với M.
Hai loại kiểm tra trên được tiếp tục cho đến khi nhóm tích
hợp hài lòng rằng không có lỗi giao diện đã biết. Trong
trường hợp phát hiện ra lỗi giao diện thì phải sửa lỗi đó
trước khi chuyển sang bước tiếp theo.
Bước Nếu tập hợp CM trống, sau đó dừng lại; nếu không, đặt IM =
4: CM và chuyển sang bước 2.
Bây giờ, chúng ta hãy xem xét một ví dụ về tích hợp từ trên xuống
bằng cách sử dụng Hình 7.1. Sự tích hợp của các mô-đun A và B
bằng cách sử dụng sơ khai C và D (biểu diễn bằng các hộp màu xám)
được thể hiện trong Hình 7.2. Tương tác giữa các mô-đun A và B bị
hạn chế nghiêm trọng bởi tính chất giả của C và D . Tương tác giữa A
và B là cụ thể, và do đó, nhiều thử nghiệm hơn được thực hiện sau
khi các mô-đun bổ sung được tích hợp. Tiếp theo, như trong
Hình 7.3, sơ khai D đã được thay thế bằng phiên bản thực
tế D. Chúng tôi thực hiện hai loại kiểm tra: thứ nhất, kiểm tra giao
diện giữa A và D; thứ hai, thực hiện kiểm tra hồi quy để tìm kiếm các
khiếm khuyết giao diện giữa A và B khi có mô-đun D. Stub C đã
được thay thế bằng mô-đun thực tế C và các sơ khai mới E, F và G đã
được thêm vào hệ thống tích hợp (Hình 7.4). Chúng tôi thực hiện các
bài kiểm tra như sau: Đầu tiên, kiểm tra giao diện giữa A và C; thứ
hai, kiểm tra các mô-đun kết hợp A, B và D với sự có mặt của C
(Hình 7.4). Phần còn lại của quá trình tích hợp được mô tả trong Hình
7.5 và 7.6 để có được hệ thống cuối cùng của Hình 7.7.
Các ưu điểm của phương pháp từ trên xuống như sau:
Các kỹ sư kiểm tra tích hợp hệ thống (SIT) liên tục quan sát các chức
năng cấp hệ thống khi quá trình tích hợp tiếp tục. Các chức năng như
vậy được quan sát sớm bao lâu phụ thuộc vào sự lựa chọn của họ về
thứ tự mà các mô-đun được tích hợp. Việc quan sát sớm các chức
năng của hệ thống là rất quan trọng vì nó mang lại cho họ sự tự tin tốt
hơn.
Việc cô lập các lỗi giao diện trở nên dễ dàng hơn vì tính chất gia tăng
của tích hợp từ trên xuống. Tuy nhiên, không thể kết luận lỗi giao
diện là do module M. mới được tích hợp. Lỗi giao diện
Hình 7.5 Tích hợp từ trên xuống của các mô-đun A, B, C, D và

E.
Hình 7.6 Tích hợp từ trên xuống của các mô-đun A, B, C, D, E
và F.
Hình 7.7 Tích hợp từ trên xuống của các mô-đun A, B, C, D, E,
F và G.
có thể do triển khai sai mô-đun đã được tích hợp trước đó nhiều. Điều
này có thể xảy ra vì các thử nghiệm trước đó đã được thực hiện có
hoặc không có sơ khai cho M và khả năng đầy đủ của M chỉ đơn giản
là cho phép các kỹ sư thử nghiệm tiến hành nhiều thử nghiệm hơn có
thể do M. • Các trường hợp thử nghiệm được thiết kế để kiểm tra sự
A
tích hợp của mô-đun M được sử dụng lại
trong quá trình kiểm tra hồi quy được
thực hiện sau khi tích hợp các mô-đun
B C D
khác.
Vì các đầu vào kiểm tra được áp dụng
E F G cho mô-đun cấp cao nhất, điều tự nhiên
là các trường hợp thử nghiệm đó tương
ứng với các chức năng của hệ thống và
A
việc thiết kế các trường hợp thử nghiệm
đó dễ dàng hơn các trường hợp thử
B C D nghiệm được thiết kế để kiểm tra các
chức năng nội bộ của hệ thống. Những
E F G trường hợp thử nghiệm đó có thể được
sử dụng lại trong khi thực hiện các thử
nghiệm cấp hệ thống, khắt khe hơn.
A Các hạn chế của phương pháp từ trên
xuống như sau:
B C D Cho đến khi một tập hợp các mô-đun
nhất định đã được tích hợp, có thể không
quan sát được các chức năng có ý nghĩa
E F G
của hệ thống vì thiếu các mô-đun cấp
A
thấp hơn và sự hiện diện của các phần sơ khai. Cần phải phân tích cẩn
thận để xác định thứ tự các mô-đun để tích hợp sao cho các chức
Figure7.2 Top-downintegrationofmodules
năng của hệ thống được quan sát
B C D
sớm nhất có thể.
AandB.
Figure7.3 Top-downintegrationofmodules
B C D
A,B,andD.
A
246
B CHƯƠNG 7 C KIỂM TRA TÍCH HỢP
D HỆ THỐNG
Việc lựa chọn trường hợp thửFigure7.4

nghiệm Top-downintegrationofmodules
và thiết kế sơ khai ngày càng
E F
trở nên khó khăn khi Gcác sơ khai nằm cách xa mô-đun cấp cao nhất.
A,B,D,andC.
Điều này là do các sơ khai hỗ trợ hành vi hạn chế và bất kỳ quá trình
chạy thử nghiệm nào ở cấp cao nhất phải được hạn chế để thực hiện
hành vi hạn chế của các sơ khai cấp thấp hơn.
7.4.3 Từ dưới lên
Trong cách tiếp cận từ dưới lên, tích hợp hệ thống bắt đầu bằng việc
tích hợp các mô-đun cấp thấp nhất. Một mô-đun được cho là ở mức
thấp nhất nếu nó không gọi một mô-đun khác. Giả định rằng tất cả
các mô-đun đã được kiểm tra riêng trước đó. Để tích hợp một tập hợp
các mô-đun cấp thấp hơn theo cách tiếp cận này, chúng ta cần xây
dựng một mô-đun trình điều khiển thử nghiệm gọi các mô-đun được
tích hợp. Khi việc tích hợp nhóm mô-đun cấp thấp hơn mong muốn
được tìm thấy là thỏa mãn, trình điều khiển được thay thế bằng mô-
đun thực tế và một trình điều khiển thử nghiệm khác được sử dụng để
tích hợp nhiều mô-đun hơn với tập hợp mô-đun đã được tích hợp.
Quá trình tích hợp từ dưới lên tiếp tục cho đến khi tất cả các mô-đun
đã được tích hợp.
Bây giờ chúng ta đưa ra một ví dụ về tích hợp từ dưới lên cho hệ
thống phân cấp mô-đun của Hình 7.1. Các mô-đun cấp thấp nhất là E,
F và G. Chúng tôi thiết kế một trình điều khiển thử nghiệm để tích
hợp ba mô-đun này, như trong Hình 7.8. Có thể lưu ý rằng các mô-
đun E, F và G không có giao diện trực tiếp giữa chúng. Tuy nhiên,
các giá trị trả về được tạo bởi một mô-đun có thể được sử dụng trong
một mô-đun khác, do đó có một giao diện gián tiếp. Trình điều khiển
thử nghiệm trong Hình 7.8 gọi các mô-đun E, F và G theo cách tương
tự như các lệnh gọi của chúng theo mô-đun C. Trình điều khiển thử
nghiệm bắt chước mô-đun C để tích hợp E, F và G một cách hạn chế,
vì nó đơn giản hơn nhiều trong khả năng hơn mô-đun C. Trình điều
khiển thử nghiệm được thay thế bằng mô-đun thực tế — trong trường
hợp này là C — và trình điều khiển thử nghiệm mới được sử dụng
sau khi người thử nghiệm hài lòng với hành vi kết hợp của E, F và G
(Hình 7.9). Tại thời điểm này, nhiều mô-đun hơn, chẳng hạn như B
và D, được tích hợp với hệ thống tích hợp cho đến nay. Trình điều
khiển thử nghiệm bắt chước hành vi của mô-đun A. Chúng ta cần bao
gồm mô-đun B và D vì chúng được gọi bởi A và trình điều khiển thử
nghiệm bắt chước A (Hình 7.9). Trình điều khiển thử nghiệm được
thay thế bằng mô-đun A (Hình 7.10) và các thử nghiệm tiếp theo
được thực hiện sau khi người thử nghiệm hài lòng với hệ thống tích
hợp được thể hiện trong Hình 7.9.
Các ưu điểm của phương pháp từ dưới lên như sau. Nếu các mô-đun
cấp thấp và các chức năng kết hợp của chúng thường được gọi bởi
các mô-đun khác, thì sẽ hữu ích hơn khi kiểm tra chúng trước để có
thể thực hiện tích hợp hiệu quả có ý nghĩa các mô-đun khác. Trong
Test trường hợp không có chiến lược
driver như vậy, người kiểm tra sẽ viết
các sơ khai để mô phỏng các mô-
E F G
đun cấp thấp thường được gọi,
điều này sẽ chỉ cung cấp khả năng
kiểm tra hạn chế của các giao diện.
Hình 7.8 Tích hợp từ dưới lên của các mô-đun E, F và G.
Hình 7.9 Tích hợp từ dưới lên của các mô-đun B, C và D với E,
F và G.
Hình 7.10 Tích hợp từ dưới lên của mô-đun A với tất cả các mô-
đun khác.
Những nhược điểm của phương pháp từ dưới lên như sau:
Các kỹ sư kiểm tra không thể quan sát các chức năng cấp hệ thống từ
một hệ thống tích hợp một phần. Trên thực tế, họ không thể quan sát
các chức năng cấp hệ thống cho đến khi có trình điều khiển thử
nghiệm cấp cao nhất.
Nói chung, các quyết định thiết kế chính được thể hiện trong các mô-
đun cấp cao nhất, trong khi hầu hết các mô-đun cấp thấp phần lớn
thực hiện các chức năng đầu vào - đầu ra thường được biết đến. Việc
phát hiện ra các sai sót lớn trong thiết kế hệ thống có thể không thực
hiện được cho đến khi các mô-đun cấp cao nhất đã được tích hợp.
Bây giờ chúng ta so sánh các phương pháp tiếp cận từ trên xuống và
từ dưới lên như sau:
Xác thực các Quyết định Thiết kế Chính: Các mô-đun cấp cao nhất
chứa các quyết định thiết kế chính. Các lỗi trong quyết định thiết kế
được phát hiện sớm nếu tích hợp được thực hiện theo cách từ trên
xuống. Trong cách tiếp cận từ dưới lên, những lỗi đó được phát hiện
vào cuối quá trình tích hợp.
Quan sát các chức năng cấp hệ thống: Một áp dụng đầu vào kiểm
tra cho mô-đun cấp cao nhất, tương tự như thực hiện kiểm tra cấp hệ
thống theo cách rất hạn chế trong cách tiếp cận từ trên xuống. Điều
này tạo cơ hội cho nhân viên SIT và nhóm phát triển quan sát sớm
các chức năng cấp hệ thống trong quá trình tích hợp. Tuy nhiên, các
quan sát tương tự chỉ có thể được thực hiện theo cách tiếp cận từ dưới
lên khi kết thúc tích hợp hệ thống.
Khó khăn trong việc thiết kế các trường hợp kiểm thử: Theo cách
tiếp cận từ trên xuống, khi ngày càng nhiều mô-đun được tích hợp và
các sơ khai nằm xa mô-đun cấp cao nhất, việc thiết kế hành vi sơ khai
và đầu vào thử nghiệm ngày càng trở nên khó khăn. Điều này là do
các sơ khai trả về các giá trị được xác định trước và kỹ sư kiểm tra
phải tính toán các giá trị đó cho một đầu vào kiểm tra nhất định ở cấp
cao nhất. Tuy nhiên, trong cách tiếp cận từ dưới lên, người ta thiết kế
hành vi của trình điều khiển thử nghiệm bằng cách đơn giản hóa hành
vi của mô-đun thực tế.
Khả năng tái sử dụng của các trường hợp kiểm thử: Trong cách
tiếp cận từ trên xuống, các trường hợp kiểm thử được thiết kế để kiểm
tra giao diện của một mô-đun mới được tích hợp được sử dụng lại
trong việc thực hiện kiểm tra hồi quy trong lần lặp sau. Các trường
hợp kiểm thử đó được sử dụng lại như các trường hợp kiểm thử cấp
hệ thống. Tuy nhiên, theo cách tiếp cận từ dưới lên, không thể sử
dụng lại tất cả các trường hợp thử nghiệm được tích hợp vào trình
điều khiển thử nghiệm, ngoại trừ trình điều khiển thử nghiệm cấp cao
nhất. Cách tiếp cận từ trên xuống tiết kiệm tài nguyên dưới dạng thời
gian và tiền bạc.
7.4.4 Sandwich và Big Bang
Trong phương pháp sandwich, một hệ thống được tích hợp bằng cách
sử dụng kết hợp các phương pháp tiếp cận từ trên xuống và từ dưới
lên. Hệ thống phân cấp được xem như bao gồm ba lớp. Lớp dưới
cùng chứa tất cả các mô-đun thường được gọi. Phương pháp từ dưới
lên được áp dụng để tích hợp các mô-đun ở lớp dưới cùng. Lớp trên
cùng chứa các mô-đun thực hiện các quyết định thiết kế chính. Các
mô-đun này được tích hợp bằng cách sử dụng cách tiếp cận từ trên
xuống. Phần còn lại của các mô-đun được đưa vào lớp giữa. Chúng
tôi có những lợi thế của cách tiếp cận từ trên xuống mà không cần
phải viết sơ khai cho mô-đun cấp thấp. Là một trường hợp đặc biệt,
lớp giữa có thể không tồn tại, trong trường hợp đó, một mô-đun nằm
ở lớp trên cùng hoặc ở lớp dưới cùng. Mặt khác, nếu lớp giữa tồn tại,
thì lớp này có thể được tích hợp bằng cách sử dụng cách tiếp cận vụ
nổ lớn sau khi lớp trên và lớp dưới đã được tích hợp.
Trong cách tiếp cận big-bang, đầu tiên tất cả các mô-đun đều được
kiểm tra riêng. Tiếp theo, tất cả các mô-đun đó được ghép lại với
nhau để xây dựng toàn bộ hệ thống được kiểm tra tổng thể. Đôi khi
các nhà phát triển sử dụng cách tiếp cận vụ nổ lớn để tích hợp các hệ
thống nhỏ. Tuy nhiên, đối với các hệ thống lớn, cách tiếp cận này
không được khuyến khích vì những lý do sau:
Trong một hệ thống có một số lượng lớn các mô-đun, có thể có nhiều
khiếm khuyết về giao diện. Rất khó để xác định nguyên nhân hỏng
hóc có phải do lỗi giao diện trong một hệ thống lớn và phức tạp hay
không.
Trong các hệ thống lớn, sự hiện diện của một số lượng lớn các lỗi
giao diện không phải là một kịch bản khó xảy ra trong phát triển phần
mềm. Vì vậy, sẽ không hiệu quả về chi phí nếu lạc quan bằng cách
ghép các mô-đun lại với nhau và hy vọng nó sẽ hoạt động.
Solheim và Rowland [5] đã đo lường hiệu quả tương đối của các
chiến lược tích hợp từ trên xuống, từ dưới lên, bánh sandwich và big-
bang cho các hệ thống phần mềm. Nghiên cứu thực nghiệm chỉ ra
rằng các chiến lược tích hợp từ trên xuống là hiệu quả nhất trong việc
sửa chữa các khiếm khuyết. Các chiến lược từ trên xuống và lớn đã
tạo ra những hệ thống đáng tin cậy nhất. Các chiến lược từ dưới lên
thường kém hiệu quả nhất trong việc sửa chữa các khiếm khuyết và
tạo ra các hệ thống kém tin cậy nhất. Các hệ thống được tích hợp bởi
chiến lược bánh mì kẹp có độ tin cậy vừa phải khi so sánh.
7.5 TÍCH HỢP PHẦN MỀM VÀ PHẦN CỨNG
Một thành phần là một phần cơ bản của một hệ thống, và nó phần lớn
độc lập với các thành phần khác. Nhiều sản phẩm yêu cầu phát triển
cả thành phần phần cứng và phần mềm. Hai loại thành phần này được
tích hợp để tạo thành sản phẩm hoàn chỉnh. Ngoài ra, một loại thành
phần thứ ba, tài liệu sản phẩm, được phát triển song song với hai
thành phần đầu tiên. Tài liệu sản phẩm là sự tích hợp của các loại tài
liệu riêng lẻ khác nhau. Mục tiêu chung là giảm thời gian đưa sản
phẩm ra thị trường bằng cách loại bỏ tính chất tuần tự của các quá
trình phát triển sản phẩm.
Về mặt phần cứng, các mô-đun hoặc linh kiện phần cứng riêng lẻ có
bản chất đa dạng, chẳng hạn như khung máy, bảng mạch in, bộ
nguồn, khay quạt để làm mát và tủ để giữ sản phẩm. Về mặt tài liệu,
các mô-đun được tích hợp với nhau bao gồm hướng dẫn cài đặt,
hướng dẫn khắc phục sự cố và hướng dẫn sử dụng bằng nhiều ngôn
ngữ tự nhiên.
Điều cần thiết là phải kiểm tra cả phần mềm và các thành phần phần
cứng riêng lẻ càng nhiều càng tốt trước khi tích hợp chúng. Trong
nhiều sản phẩm, không có thành phần nào có thể được kiểm tra hoàn
toàn mà không có thành phần kia. Thông thường, các tiêu chí đầu vào
cho cả thành phần phần cứng và phần mềm được thiết lập và thỏa
mãn trước khi bắt đầu tích hợp các thành phần đó. Nếu phần cứng
đích không khả dụng tại thời điểm tích hợp hệ thống, thì một trình giả
lập phần cứng sẽ được phát triển. Trình giả lập thay thế nền tảng phần
cứng mà phần mềm được kiểm tra cho đến khi phần cứng thực sự khả
dụng. Tuy nhiên, không có gì đảm bảo rằng phần mềm sẽ hoạt động
trên phần cứng thực ngay cả khi nó hoạt động trên trình giả lập.
Tích hợp các thành phần phần cứng và phần mềm thường được thực
hiện theo cách lặp đi lặp lại. Hình ảnh phần mềm với số lượng mô-
đun phần mềm cốt lõi tối thiểu được tải trên phần cứng nguyên mẫu.
Trong mỗi bước, một số lượng nhỏ các bài kiểm tra được thực hiện
để đảm bảo rằng tất cả các mô-đun phần mềm mong muốn đều có
trong bản dựng. Tiếp theo, các thử nghiệm bổ sung được chạy để xác
minh các chức năng cần thiết. Quá trình lắp ráp bản dựng, tải trên
phần cứng đích và kiểm tra bản dựng tiếp tục cho đến khi toàn bộ sản
phẩm được tích hợp. Nếu một vấn đề được phát hiện sớm trong tích
hợp phần cứng / phần mềm và vấn đề có thể được giải quyết dễ dàng,
thì vấn đề sẽ được khắc phục mà không có bất kỳ sự chậm trễ nào.
Nếu không, việc tích hợp các thành phần phần mềm và phần cứng có
thể tiếp tục một cách hạn chế cho đến khi tìm ra và phân tích được
nguyên nhân gốc rễ của vấn đề. Việc tích hợp bị trì hoãn cho đến khi
các bản sửa lỗi, dựa trên kết quả của phân tích nguyên nhân gốc rễ,
được áp dụng.
7.5.1 Kiểm tra xác minh thiết kế phần cứng

Một quy trình kỹ thuật phần cứng được xem như bao gồm bốn giai
đoạn: (i) lập kế hoạch và đặc tả, (ii) thiết kế, triển khai nguyên mẫu
và thử nghiệm, (iii) tích hợp với hệ thống phần mềm và (iv) sản xuất,
phân phối và dịch vụ hiện trường . Việc kiểm tra mô-đun phần cứng
trong giai đoạn thứ hai của quá trình phát triển phần cứng mà không
có phần mềm có thể được tiến hành ở một mức độ hạn chế. Một kế
hoạch kiểm tra xác minh thiết kế phần cứng (DVT) được nhóm phần
cứng chuẩn bị và thực hiện trước khi tích hợp với hệ thống phần
mềm. Các bài kiểm tra phần cứng chính được thảo luận bên dưới.
đoán Kiểm tra chẩn đoán là kiểm tra phần cứng cơ bản nhất. Các
bài kiểm tra như vậy thường được nhúng vào thành phần cơ bản của
hệ thống đầu vào - đầu ra (BIOS) và được thực hiện tự động bất cứ
khi nào hệ thống bật nguồn. Thành phần BIOS thường nằm trên bộ
nhớ chỉ đọc (ROM) của hệ thống. Kiểm tra này được thực hiện như
một loại kiểm tra độ tỉnh táo của mô-đun phần cứng. Kiểm tra chẩn
đoán tốt bao gồm tất cả các mô-đun trong hệ thống. Kiểm tra chẩn
đoán là kiểm tra đầu tiên được thực hiện để cô lập mô-đun phần cứng
bị lỗi.
Thử nghiệm phóng điện tĩnh điện Khái niệm thử nghiệm phóng
điện (ESD) rất cũ và nó đảm bảo rằng hoạt động của hệ thống không
bị ảnh hưởng bởi ESD sau khi đã thực hiện các biện pháp phòng
ngừa thường được chấp nhận. Có ba tiêu chuẩn công nghiệp phổ biến
về kiểm tra ESD dựa trên ba mô hình khác nhau: mô hình cơ thể
người (HBM), mô hình máy (MM) và mô hình thiết bị tích điện
(CDM). HBM là mô hình lâu đời nhất và là mô hình ESD được công
nhận rộng rãi nhất. Nó được phát triển vào thời điểm mà hầu hết các
hư hỏng ESD xảy ra khi mọi người chạm vào các thành phần phần
cứng mà không tiếp đất thích hợp. Điện dung và trở kháng của cơ thể
con người rất khác nhau, vì vậy các giá trị thành phần trong mô hình
được đặt tùy ý để tạo điều kiện cho thử nghiệm so sánh. Các thiết bị
bị hư hỏng bởi HBM thường có các mối nối bị hư hỏng do nhiệt,
đường kim loại nóng chảy hoặc các dạng hư hỏng khác do dòng điện
đỉnh cao và điện tích cao bị tiêu tán trong vài trăm nano giây. Mô
hình này vẫn được áp dụng bất cứ khi nào mọi người xử lý thiết bị, vì
vậy người ta nên thực hiện kiểm tra HBM trên tất cả các thiết bị mới.
MM được sử dụng chủ yếu ở Nhật Bản và Châu Âu. Mô hình này
ban đầu được phát triển như một HBM “trường hợp xấu nhất” để sao
chép loại lỗi do máy tự động chọn và đặt được sử dụng để lắp ráp
bảng mạch in (PCB). Mô hình mô phỏng một máy trở kháng thấp
phóng điện dung cao vừa phải (ví dụ: 200 pF) qua một thiết bị. Sự
phóng điện được tạo ra bằng cách sử dụng MM có thể gây ra thiệt hại
ở điện áp tương đối thấp. Cuối cùng, CDM tái tạo các hư hỏng ESD
thực tế xảy ra trong các thiết bị nhỏ, đóng gói bằng nhựa. Khi một
thiết bị đóng gói trượt trên một bề mặt, nó tích tụ điện tích do tác
động ba điện (ma sát) giữa thân nhựa và bề mặt. Do đó, thiết bị nhận
7.5 TÍCH HỢP PHẦN MỀM VÀ PHẦN CỨNG 253
một khoản phí tạo ra điện thế. Trong HBM và MM, một thứ gì đó
bên ngoài thiết bị sẽ tích lũy điện tích. Đối với các thiết bị nhỏ, tiềm
năng có thể cao một cách đáng ngạc nhiên. Cần có điện thế ít nhất là
650 V để nhân đôi thiệt hại quan sát được.
phát xạ điện từ Các thử nghiệm kiểm tra sự phát xạ điện từ được
thực hiện để đảm bảo rằng hệ thống không phát ra bức xạ quá mức
ảnh hưởng đến hoạt động của các thiết bị lân cận. Tương tự, các thử
nghiệm được tiến hành để đảm bảo rằng hệ thống không nhận được
bức xạ quá mức để tác động đến hoạt động của chính nó. Lượng khí
thải cần quan tâm như sau:
Điện trường bức xạ phát xạ
Từ trường bức xạ phát xạ
Phát xạ dẫn điện xoay chiều (AC) dẫn điện (điện áp)
Phát xạ dẫn tín hiệu và nguồn AC và dòng điện một chiều (DC)
(hiện hành)
Phát xạ dẫn băng tần giọng nói tương tự
Kiểm tra điện Một loạt các kiểm tra điện được thực hiện trên các
sản phẩm có thành phần phần cứng. Một thử nghiệm như vậy được
gọi là thử nghiệm “chất lượng tín hiệu”, trong đó các bộ phận khác
nhau của hệ thống được kiểm tra xem có điện áp không phù hợp hoặc
dòng điện tiềm ẩn nào tại các cổng và thiết bị ngoại vi có thể truy cập
bên ngoài hay không. Một loại kiểm tra điện khác là quan sát hệ
thống hoạt động như thế nào để đáp ứng các loại điều kiện nguồn
khác nhau như AC, DC và pin. Ngoài ra, các thử nghiệm được tiến
hành để kiểm tra giới hạn an toàn của thiết bị khi nó tiếp xúc với các
điều kiện bất thường. Tình trạng bất thường có thể do sét đánh hoặc
lỗi nguồn AC.
Kiểm tra nhiệt Các thử nghiệm nhiệt được thực hiện để quan sát
xem hệ thống có thể chịu được các điều kiện nhiệt độ và độ ẩm mà
nó sẽ trải qua ở cả chế độ hoạt động và không hoạt động hay không.
Hệ thống được đặt trong một buồng nhiệt và chạy qua một loạt các
chu kỳ nhiệt độ và độ ẩm. Các thành phần tạo ra nhiệt, chẳng hạn
như CPU và card Ethernet, được thiết bị với cảm biến nhiệt để xác
minh xem các thành phần có vượt quá nhiệt độ hoạt động tối đa của
chúng hay không. Một loại thử nghiệm nhiệt đặc biệt là sốc nhiệt, khi
nhiệt độ thay đổi nhanh chóng.
Kiểm tra môi trường Các thử nghiệm môi trường được thiết kế để
xác minh phản ứng của hệ thống đối với các loại điều kiện khắc
nghiệt khác nhau gặp phải trong thế giới thực. Một trong những bài
kiểm tra như vậy bao gồm sốc và rung từ các công trình xây dựng lân
cận và đường cao tốc. Máy móc hạng nặng gần đó, công trình nặng,
thiết bị công nghiệp nặng, giao thông xe tải / tàu hỏa hoặc máy phát
điện dự phòng có thể gây ra rung động tần số thấp có thể gây ra các
sự cố không liên tục. Điều quan trọng là phải biết liệu rung động tần
số thấp như vậy có gây ra các vấn đề lâu dài như các đầu nối trở nên
lỏng lẻo hoặc các vấn đề ngắn hạn như ổ đĩa bị treo hay không. Kiểm
tra môi trường cũng bao gồm những bất ngờ khác mà hệ thống có thể
gặp phải. Ví dụ, trong môi trường chiến trường, máy tính và các trạm
thu phát sóng thường phải chịu khói, cát, đạn, lửa và các điều kiện
khắc nghiệt khác.
Kiểm tra Xử lý và Đóng gói Thiết bị Các kiểm tra này nhằm xác
định mức độ mạnh mẽ của hệ thống đối với các hoạt động vận
chuyển và lắp đặt thông thường. Đóng gói và thiết kế bao bì tốt đảm
bảo rằng thùng vận chuyển sẽ cung cấp cho hệ thống lô hàng không
bị hư hại. Việc tham gia sớm các kỹ năng thiết kế này sẽ cung cấp
thông tin đầu vào về vị trí của các tay cầm và các phần nhô ra của hệ
thống khác có thể là nguyên nhân gây ra hỏng hóc. Lựa chọn độ dày
kim loại và dây buộc hợp lý sẽ cung cấp hiệu suất đầy đủ cho các hệ
thống được lắp đặt vào vị trí cuối cùng của chúng.
Kiểm tra độ ồn Giới hạn độ ồn âm thanh được quy định để đảm bảo
rằng nhân viên có thể làm việc gần hệ thống mà không vượt quá giới
hạn an toàn do cơ quan Quản lý An toàn và Sức khỏe Nghề nghiệp
(OSHA) địa phương quy định hoặc các mức độ thương lượng khác.
Ví dụ, độ ồn của đĩa cứng quay, đĩa mềm và các ổ đĩa khác phải được
kiểm tra so với giới hạn của chúng.
Kiểm tra an toàn Các thử nghiệm an toàn được thực hiện để đảm
bảo rằng những người sử dụng hoặc làm việc trên hoặc gần hệ thống
không tiếp xúc với các mối nguy hiểm. Ví dụ, nhiều máy tính xách
tay chứa pin có thể sạc lại thường chứa các chất độc hại nguy hiểm
như cadmium và niken. Cần phải cẩn thận đầy đủ để đảm bảo rằng
các thiết bị này không bị rò rỉ các hóa chất nguy hiểm trong bất kỳ
trường hợp nào.
Kiểm tra độ tin cậy Các mô-đun phần cứng có xu hướng bị lỗi theo
thời gian. Giả định rằng (i) mô-đun có tỷ lệ hỏng hóc không đổi trong
suốt thời gian hoạt động hữu ích của chúng và (ii) tỷ lệ hỏng hóc của
mô-đun tuân theo quy luật phân phối theo cấp số nhân. Tỷ lệ lỗi
thường được đo bằng thời gian trung bình giữa các lần hỏng hóc
(MTBF), và nó được biểu thị bằng MTBF = tổng thời gian / số lần
hỏng hóc. Xác suất để một mô-đun sẽ hoạt động trong một thời gian
T mà không bị lỗi được cho bởi R (T) = exp ( - T / MTBF). Số liệu
MTBF là số liệu đo lường độ tin cậy cho các mô-đun phần cứng. Nó
thường được tính theo đơn vị giờ, ngày hoặc tháng.
MTBF cho một mô-đun hoặc một hệ thống được lấy từ nhiều nguồn
khác nhau: các thử nghiệm trong phòng thí nghiệm, dữ liệu lỗi thực
tế tại hiện trường và các mô hình dự đoán. Một cách khác để tính
toán độ tin cậy và tuổi thọ của hệ thống là tiến hành các bài kiểm tra
tuổi thọ nhanh (HALT). HALTs dựa trên nguyên tắc nén thời gian
logarit để mô phỏng toàn bộ vòng đời của hệ thống chỉ trong vài
ngày. Điều này được thực hiện bằng cách áp dụng mức độ căng
thẳng cao hơn nhiều so với những gì tồn tại trong quá trình sử dụng
hệ thống thực tế. Mức độ căng thẳng cao buộc sự cố xảy ra trong thời
gian ngắn hơn đáng kể so với điều kiện vận hành bình thường. HALT
thường bao gồm chu kỳ nhiệt độ nhanh, rung trên tất cả các trục, biến
đổi điện áp hoạt động và thay đổi tần số đồng hồ cho đến khi hệ
thống bị lỗi. HALT chỉ yêu cầu một vài đơn vị sản phẩm và thời gian
thử nghiệm ngắn để xác định các giới hạn cơ bản của công nghệ đang
được sử dụng. Nói chung, mọi điểm yếu phải được xác định và khắc
phục (tức là, thiết kế lại) nếu nó không đáp ứng các giới hạn quy định
của hệ thống. Hiểu khái niệm về độ tin cậy của sản phẩm là quan
trọng đối với bất kỳ tổ chức nào nếu tổ chức đó dự định cung cấp bảo
hành hệ thống trong một thời gian dài. Người ta có thể dự đoán với
độ chính xác cao chi phí chính xác liên quan đến lợi nhuận trong một
thời gian bảo hành có giới hạn và kéo dài. Ví dụ: đối với một hệ
thống có MTBF là 250.000 giờ và thời gian hoạt động có lãi là 5 năm
(438.000 giờ), chúng ta có R (438.000) = exp ( - 43.800 / 250.000) =
0,8392, điều này nói lên rằng có một xác suất 0,8932 rằng sản phẩm
sẽ hoạt động trong năm năm mà không bị hỏng hóc. Một cách giải
thích khác về số lượng là 83,9% các đơn vị trong lĩnh vực này sẽ vẫn
hoạt động vào cuối năm năm. Nói cách khác, 16,1% thiết bị cần được
thay thế trong vòng năm năm đầu tiên.
7.5.2 Ma trận tương thích phần cứng và phần mềm
Thông tin về khả năng tương thích của phần cứng và phần mềm được
duy trì dưới dạng ma trận tương thích. Một ma trận như vậy ghi lại
sự tương thích giữa các bản sửa đổi khác nhau của phần cứng và các
phiên bản khác nhau của phần mềm và được sử dụng để phát hành
chính thức sản phẩm. Lệnh thay đổi kỹ thuật (ECO) là một tài liệu
chính thức mô tả sự thay đổi đối với phần cứng hoặc phần mềm. Tài
liệu ECO bao gồm ma trận khả năng tương thích phần cứng / phần
mềm và được phân phối tới
BẢNG 7.2 Ví dụ về ma trận tương thích phần cứng / phần
mềm
RNC RN EMS PDSN Thử Thử
nghiệm nghiệm
Phần Phần cứngPhần cứngPhần cứngPhần cứng bởi SIT bởi ST
mềm
Phóng Phiên bản Phiên bản Phiên bản Phiên bản
thích
2.0 hv1.0 hv2.0 hv3.2 hv2.0.3 Đúng Đúng
2,5 hv2.0 và hv2.0 hv4.0 và hv3.0 và Đúng Đúng
hv1.0 hv3.2 hv2.0.3
3.0 hv3.0 hv3.0 và hv5.0 hv4.0 và Đúng Vẫn
chưa
hv2.0 hv3.0
3.0 hv4.0 và hv3.0 hv5.0 hv4.5 Vẫn Vẫn
hv3.0 chưa chưa
Vẫn chưahv4.0 và hv3.0 hv6.0 hv5.0 Vẫn Vẫn
chưa chưa
quyết hv3.0
định
hoạt động, hỗ trợ khách hàng và đội bán hàng của tổ chức. Ví dụ về
ma trận tương thích cho mạng dữ liệu không dây 1xEV-DO, được
thảo luận trong Chương 8, được đưa ra trong Bảng 7.2.
Sau đây, chúng tôi cung cấp quy trình phê duyệt ECO phần cứng và
phần mềm trong một tổ chức. Kịch bản đầu tiên mô tả quy trình ECO
để kết hợp một phần cứng mới trong sản phẩm. Kịch bản thứ hai mô
tả quy trình ECO cho một bản sửa đổi phần mềm.
Kịch bản 1 Quá trình ECO phần cứng được thể hiện trong Hình 7.11.
Giả sử rằng nhóm phần cứng cần phát hành bản sửa đổi mới của
phần cứng hoặc phải đề xuất bản sửa đổi mới của phần cứng của nhà
sản xuất thiết bị gốc (OEM) cho nhóm vận hành / sản xuất. Các bước
của quy trình ECO để kết hợp phần cứng mới vào sản phẩm như sau:
Nhóm phần cứng đưa ra thông báo thay đổi thiết kế cho bản sửa đổi
phần cứng mới. Thông báo này bao gồm việc xác định các thay đổi
phần cứng cụ thể có khả năng ảnh hưởng đến phần mềm và sự không
tương thích giữa phần cứng đã sửa đổi và phần cứng khác. Nhóm
phần mềm xem xét thông báo với nhóm phần cứng để đánh giá tác
động của các thay đổi phần cứng và xác định các thay đổi phần mềm
ảnh hưởng đến cấu trúc phần cứng.
Nhóm phần cứng tạo ECO và xem xét nó với hội đồng kiểm soát
thay đổi (CCB) để đảm bảo rằng tất cả các tác động của ECO đều
được hiểu và thống nhất và tuân thủ các quy tắc đánh số phiên bản
cho các thành phần phần mềm. CCB tạo thành một nhóm các cá nhân
từ nhiều bộ phận chịu trách nhiệm xem xét và phê duyệt từng ECO.
ECO được phát hành và nhóm phần cứng cập nhật ma trận tương
thích phần cứng / phần mềm dựa trên thông tin nhận được từ quá
trình xem xét.
Hardware 1 Change
notification
HW/SW
review
ECO
CCB
review
Sales,
System operation,
3 Query
test customer,
support
Compatibility
4 matrix
Hình 7.11 Quy trình ECO phần cứng.

Nhóm kiểm tra hệ thống cập nhật ma trận tương thích sau khi đã
kiểm tra sự kết hợp nhất định của các phiên bản phần cứng và phần
mềm đã phát hành.
Kịch bản 2 Quá trình phát hành phần mềm ECO được thể hiện trong
Hình 7.12. Giả sử rằng nhóm cần phát hành một phiên bản phần mềm
mới cho nhóm vận hành / sản xuất. Các bước của quy trình ECO để
kết hợp phiên bản mới của sản phẩm phần mềm như sau:
Nhóm tích hợp hệ thống phát hành một bản dựng có ghi chú phát
hành xác định thông tin tương thích phần cứng với nhóm kiểm tra hệ
thống.
Nhóm kiểm tra hệ thống kiểm tra việc xây dựng và thông báo cho
nhóm phần mềm và các nhóm có liên quan khác trong tổ chức về kết
quả của các bài kiểm tra.
Nhóm kiểm tra hệ thống cho rằng một bản dựng cụ thể khả thi để
phát hành cho khách hàng. Nhóm kiểm tra hệ thống gọi một cuộc
họp đánh giá sự sẵn sàng giữa các chức năng để đảm bảo, bằng cách
xác minh kết quả kiểm tra, rằng tất cả các bộ phận của tổ chức đều
được chuẩn bị cho bản phát hành chính thức.
Nhóm phần mềm viết một ECO để chính thức phát hành bản xây
dựng phần mềm và xem xét nó với CCB sau khi hoàn thành việc
đánh giá mức độ sẵn sàng.
2
Build + release System

Software 1 1
notes test
3
3
Readiness
review
ECO
CCB
review 6
Sales–
operation,
customer
support Query
5
Compatibility
matrix
Hình 7.12 Quy trình ECO của phần mềm.

Bản dựng được coi là sẽ được phát hành sau khi ECO được phê
duyệt và lập thành văn bản.
Nhóm phần mềm cập nhật ma trận tương thích phần cứng / phần
mềm với thông tin về bản phát hành mới.
Nhóm kiểm tra hệ thống cập nhật ma trận tương thích sau khi đã
kiểm tra sự kết hợp nhất định của các phiên bản phần cứng và phần
mềm đã phát hành.
7.6 KẾ HOẠCH THỬ NGHIỆM TÍCH HỢP HỆ THỐNG
Tích hợp hệ thống yêu cầu một môi trường thực thi được kiểm soát,
giao tiếp nhiều giữa các nhà phát triển và các kỹ sư thử nghiệm, đưa
ra quyết định sáng suốt trong quá trình thực hiện và nhiều thời gian,
theo thứ tự hàng tháng, ngoài các nhiệm vụ cơ bản là thiết kế thử
nghiệm và thực hiện thử nghiệm. Tích hợp một hệ thống lớn là một
nhiệm vụ đầy thách thức, được xử lý với nhiều quy hoạch dưới hình
thức phát triển một kế hoạch SIT.
Khung hữu ích để chuẩn bị một kế hoạch SIT được nêu trong Bảng
7.3.
261
BẢNG 7.3 Khung cho Kế hoạch SIT
Phạm vi thử nghiệm

Cấu trúc của các mức độ tích hợp
Các giai đoạn kiểm tra tích hợp
Các mô-đun hoặc hệ thống con được tích hợp trong mỗi giai đoạn
Xây dựng quy trình và lịch trình trong từng giai đoạn
Môi trường cần thiết lập và các nguồn lực cần thiết trong mỗi giai
đoạn
Tiêu chí cho mỗi giai đoạn kiểm tra tích hợp n
Tiêu chuẩn nhập cảnh
Tiêu chí thoát
Các kỹ thuật tích hợp được sử dụng
Kiểm tra thiết lập cấu hình
Đặc điểm kỹ thuật kiểm tra cho từng giai đoạn kiểm tra tích hợp
Số ID trường hợp thử nghiệm
Dữ liệu đầu vào
Điều kiện ban đầu
Kết quả mong đợi
Quy trình kiểm tra
Làm thế nào để thực hiện kiểm tra này?
Làm thế nào để nắm bắt và diễn giải kết quả?
Kết quả kiểm tra thực tế cho từng giai đoạn kiểm tra tích hợp
Người giới thiệu
ruột thừa
Trong phần phạm vi kiểm thử, người ta sẽ tóm tắt kiến trúc hệ thống.
Cụ thể, trọng tâm là các đặc tính chức năng, nội bộ và hiệu suất sẽ
được kiểm tra. Các phương pháp tích hợp hệ thống và các giả định
được bao gồm trong phần này.
Phần tiếp theo, cấu trúc của các mức độ tích hợp, có bốn phần phụ.
Phần phụ đầu tiên giải thích việc phân chia kiểm thử tích hợp thành
các giai đoạn khác nhau, chẳng hạn như các giai đoạn chức năng, kết
thúc và độ bền. Phần phụ thứ hai mô tả các mô-đun sẽ được tích hợp
trong mỗi giai đoạn tích hợp. Phần phụ thứ ba mô tả quy trình xây
dựng sẽ được tuân theo: xây dựng hàng ngày, xây dựng hàng tuần,
xây dựng hai tuần một lần hoặc kết hợp chúng. Lịch trình tích hợp hệ
thống được đưa ra trong phần phụ thứ ba. Cụ thể, người ta xác định
ngày bắt đầu và ngày kết thúc cho mỗi giai đoạn thử nghiệm. Hơn
nữa, các cửa sổ khả dụng cho các mô-đun được kiểm tra đơn vị được
xác định. Trong tiểu mục thứ tư, môi trường thử nghiệm và các tài
nguyên cần thiết được mô tả cho từng giai đoạn tích hợp. Cấu hình
phần cứng, trình giả lập, trình mô phỏng phần mềm, công cụ kiểm tra
đặc biệt, trình gỡ lỗi, phần mềm phụ (ví dụ: sơ khai và trình điều
khiển) và các kỹ thuật kiểm tra được thảo luận trong phần phụ thứ tư.
Một quyết định quan trọng được thực hiện đối với thử nghiệm tích
hợp là thiết lập ngày bắt đầu và ngày dừng của mỗi giai đoạn thử
nghiệm tích hợp. Ngày bắt đầu và ngày dừng cho một giai đoạn được
xác định theo tiêu chí đầu vào và tiêu chí thoát, tương ứng. Các tiêu
chí này được mô tả trong phần thứ ba của kế hoạch. Khung xác định
tiêu chí đầu vào để bắt đầu tích hợp hệ thống được đưa ra trong Bảng
7.4. Tương tự, các tiêu chí thoát cho tích hợp hệ thống được đưa ra
trong Bảng 7.5. Cấu hình thử nghiệm và các kỹ thuật tích hợp (ví dụ:
từ trên xuống hoặc từ dưới lên) được sử dụng trong mỗi giai đoạn
này được mô tả trong phần này.
Phần đặc điểm kỹ thuật thử nghiệm mô tả quy trình thử nghiệm cần
tuân theo trong mỗi giai đoạn tích hợp. Các trường hợp kiểm thử chi
tiết, bao gồm đầu vào và kết quả mong đợi cho từng trường hợp,
được ghi lại trong phần đặc tả kiểm tra. Lịch sử của các kết quả kiểm
tra thực tế, các vấn đề hoặc đặc thù được ghi lại trong phần thứ năm
của kế hoạch SIT. Cuối cùng, các tài liệu tham khảo và phụ lục, nếu
có, được đưa vào kế hoạch thử nghiệm.
Kiểm thử tích hợp hệ thống được thực hiện trong các giai đoạn tăng
độ phức tạp để có hiệu quả và hiệu suất tốt hơn. Trong giai đoạn đầu
tiên, tính toàn vẹn của giao diện và tính hợp lệ của chức năng trong
hệ thống được kiểm tra. Trong giai đoạn thứ hai, các thử nghiệm từ
đầu đến cuối và theo cặp được tiến hành. Cuối cùng, trong giai đoạn
thứ ba, các bài kiểm tra căng thẳng và sức bền được thực hiện. Mỗi
giai đoạn tích hợp hệ thống được xác định trong kế hoạch SIT mô tả
một danh mục chức năng rộng trong cấu trúc phần mềm và nó có thể
liên quan đến một miền cụ thể của cấu trúc phần mềm hệ thống. Các
danh mục
263
BẢNG 7.4 Khung cho các tiêu chí đầu vào để bắt đầu tích hợp
hệ thống
Các thông số kỹ thuật về chức năng và thiết kế của Softwave phải

được viết, xem xét và phê duyệt.
Mã được xem xét và phê duyệt.
Kế hoạch kiểm tra đơn vị cho mỗi mô-đun được viết, xem xét và
thực hiện.
Tất cả các bài kiểm tra đơn vị đều vượt qua.
Toàn bộ biểu mẫu yêu cầu đăng ký phải được hoàn thành, gửi và phê
duyệt.
Đặc tả thiết kế phần cứng được viết, xem xét và phê duyệt.
Kiểm tra xác minh thiết kế phần cứng được viết, xem xét và thực
hiện.
Tất cả các bài kiểm tra xác minh thiết kế đều vượt qua.
Kế hoạch kiểm tra tích hợp phần cứng / phần mềm được viết, xem
xét và thực thi.
Tất cả các bài kiểm tra tích hợp phần cứng / phần mềm đều vượt qua.
BẢNG 7.5 Khung cho tiêu chí thoát tích hợp hệ thống
Tất cả mã được hoàn thành và đóng băng và không có thêm mô-đun

nào được tích hợp.
Tất cả các bài kiểm tra tích hợp hệ thống đều vượt qua.
Không có khiếm khuyết lớn nào là nổi bật.
Tất cả các lỗi vừa phải được tìm thấy trong giai đoạn SIT đều được
sửa và kiểm tra lại.
Không có nhiều hơn 25 khuyết tật nhỏ là nổi bật.
Hai tuần thời gian hoạt động của hệ thống trong môi trường thử
nghiệm tích hợp hệ thống mà không có bất kỳ sự cố nào, tức là, sự
cố.
Kết quả kiểm tra tích hợp hệ thống được ghi lại.

của các thử nghiệm tích hợp hệ thống và các trường hợp thử nghiệm
tương ứng được thảo luận dưới đây có thể áp dụng cho các giai đoạn
thử nghiệm khác nhau.
InterfaceIntegrity Các giao diện bên trong và bên ngoài được kiểm
tra khi mỗi mô-đun được tích hợp vào cấu trúc. Khi hai mô-đun được
tích hợp, giao tiếp giữa chúng được gọi là nội bộ, trong khi khi chúng
giao tiếp với môi trường bên ngoài, nó được gọi là bên ngoài. Các
thử nghiệm được yêu cầu thiết kế để phát hiện lỗi giao diện được
thảo luận trong Phần 7.2. Một phần quan trọng của kiểm tra giao diện
là ánh xạ định dạng thông báo đến với định dạng thông báo dự kiến
của mô-đun nhận và đảm bảo rằng hai định dạng này phù hợp. Các
bài kiểm tra được thiết kế cho mỗi thông báo đi qua giao diện giữa
hai mô-đun. Về cơ bản, các bài kiểm tra phải đảm bảo rằng:
Số lượng các tham số được gửi trong một tin nhắn đồng ý với số
lượng các tham số dự kiến sẽ được nhận.
Thứ tự tham số trong các thông báo khớp với thứ tự mong đợi.
Kích thước trường và kiểu dữ liệu khớp nhau.
Các ranh giới của mỗi trường dữ liệu trong một thông báo khớp với
các ranh giới mong đợi.
Khi một tin nhắn được tạo từ dữ liệu được lưu trữ trước khi được gửi
đi, tin nhắn đó phản ánh thực sự dữ liệu được lưu trữ.
Khi một tin nhắn đã nhận được lưu trữ, việc sao chép dữ liệu sẽ nhất
quán với tin nhắn đã nhận.
chức năng được thiết kế để phát hiện ra các lỗi chức năng trong mỗi
mô-đun sau khi nó được tích hợp với hệ thống. Các lỗi liên quan đến
cấu trúc dữ liệu cục bộ hoặc toàn cầu được phát hiện bằng các bài
kiểm tra như vậy. Các bài kiểm tra đơn vị đã chọn được thiết kế cho
từng mô-đun được thực thi lại trong quá trình tích hợp hệ thống bằng
cách thay thế các phần sơ khai bằng các mô-đun thực tế của chúng.
End-to-EndValidity được thực hiện để đảm bảo rằng một hệ thống
tích hợp hoàn toàn hoạt động cùng nhau từ đầu đến cuối. Các điểm
kiểm tra tạm thời trên luồng end-to-end giúp hiểu rõ hơn về các cơ
chế bên trong. Điều này giúp xác định các nguồn gốc của lỗi.
PairwiseValidity được thực hiện để đảm bảo rằng hai hệ thống bất kỳ
hoạt động bình thường khi được kết nối với nhau bởi một mạng. Sự
khác biệt giữa các bài kiểm tra theo cặp và các bài kiểm tra end-to-
end nằm ở điểm nhấn và loại trường hợp kiểm thử. Ví dụ: một cuộc
gọi miễn phí tới số 800 là một thử nghiệm đầu cuối của hệ thống điện
thoại, trong khi thử nghiệm kết nối giữa thiết bị cầm tay và tổng đài
chi nhánh riêng tại địa phương (PBX) là một thử nghiệm theo cặp.
265
giao diện được áp dụng ở cấp độ mô-đun trong quá trình tích hợp các
mô-đun để đảm bảo rằng các giao diện có thể duy trì tải. Mặt khác,
kiểm tra căng thẳng toàn bộ hệ thống được thực hiện tại thời điểm
kiểm tra cấp hệ thống. Các lĩnh vực sau được quan tâm đặc biệt trong
quá trình kiểm tra ứng suất giao diện:
Xử lý lỗi: Các lỗi kích hoạt sẽ được xử lý bởi các mô-đun.
Xử lý sự kiện: Các sự kiện kích hoạt (ví dụ: tin nhắn, thời gian chờ,
cuộc gọi lại) sẽ được xử lý bởi các mô-đun.
Cấu hình: Thêm, sửa đổi và xóa nhiều lần các đối tượng được quản
lý.
Ghi nhật ký: Bật cơ chế ghi nhật ký trong quá trình kiểm tra căng
thẳng để đảm bảo hoạt động thích hợp cho các điều kiện biên.
Tương tác mô-đun: Chạy thử nghiệm lặp đi lặp lại nhấn mạnh các
tương tác của một mô-đun với các mô-đun khác.
Chu kỳ CPU: Tạo ra hiệu suất sử dụng CPU cao bằng cách sử dụng
công cụ quá tải CPU; chú ý đến bất kỳ kết quả tràn hàng đợi nào và
các điều kiện vượt mức của nhà sản xuất / người tiêu dùng khác.
Sử dụng Bộ nhớ / Đĩa: Giảm mức nhân tạo của đống và / hoặc bộ
đệm bộ nhớ và dung lượng đĩa;
Đói: Đảm bảo rằng các quy trình hoặc nhiệm vụ không bị bỏ đói;
nếu không thì cuối cùng tràn hàng đợi đầu vào cho các quy trình bị
bỏ đói.
Chia sẻ tài nguyên: Đảm bảo rằng các tài nguyên, chẳng hạn như
heap và CPU, được chia sẻ giữa các quy trình mà không có bất kỳ
tranh chấp và tắc nghẽn nào.
Sự tắc nghẽn: Chạy các bài kiểm tra với cơ chế loại bỏ các gói một
cách ngẫu nhiên; kiểm tra các mô-đun với các liên kết bị tắc nghẽn.
Năng lực: Chạy thử nghiệm để đảm bảo rằng các mô-đun có thể xử
lý số lượng tối đa các yêu cầu hỗ trợ như kết nối và tuyến đường.
SystemEndurance Một hệ thống hoàn toàn được tích hợp dự kiến sẽ
hoạt động liên tục trong nhiều tuần mà không có bất kỳ sự cố nào.
Trong trường hợp hệ thống giao thức truyền thông, các quy tắc chính
thức quy định rằng hai hệ thống giao tiếp với nhau thông qua một
giao diện, tức là, một kênh giao tiếp. Ý tưởng ở đây là xác minh rằng
định dạng và thông báo liên lạc qua giao diện của các mô-đun hoạt
động trong một thời gian dài.
7.7 TÍCH HỢP THÀNH PHẦN NGOÀI KỆ
Thay vì phát triển một thành phần phần mềm từ đầu, các tổ chức đôi
khi mua các thành phần bán sẵn (OTS) từ các nhà cung cấp bên thứ
ba và tích hợp chúng với các thành phần của riêng họ [6]. Trong quá
trình này, các tổ chức tạo ra các hệ thống phần mềm ít tốn kém hơn.
Một vấn đề chính có thể phát sinh trong khi tích hợp các thành phần
khác nhau là sự không khớp giữa các đoạn mã do các bên khác nhau
phát triển thường không biết về nhau [7, 8].
Vigder và Dean [9] đã trình bày các yếu tố của một kiến trúc để tích
hợp và đã xác định các quy tắc tạo điều kiện thuận lợi cho việc tích
hợp các thành phần. Họ đã xác định một tập hợp các thành phần hỗ
trợ hữu ích để tích hợp các thành phần thực tế đang phục vụ. Các
thành phần hỗ trợ là giấy gói, keo và vải may.
7.7 TÍCH HỢP THÀNH PHẦN NGOÀI KỆ
Trình bao bọc là một đoạn mã mà người ta xây dựng để cách ly các
thành phần bên dưới với các thành phần khác của hệ thống. Ở đây cô
lập có nghĩa là đặt các hạn chế xung quanh thành phần cơ bản để hạn
chế khả năng của nó. Một thành phần keo cung cấp chức năng kết
hợp các thành phần khác nhau. Điều chỉnh thành phần đề cập đến
khả năng nâng cao chức năng của một thành phần. Việc chỉnh sửa
được thực hiện bằng cách thêm một số yếu tố vào một thành phần để
làm phong phú nó với một chức năng không được cung cấp bởi nhà
cung cấp. Việc sửa đổi không liên quan đến việc sửa đổi mã nguồn
của thành phần. Một ví dụ về chỉnh sửa là “script”, trong đó một ứng
dụng có thể được cải tiến bằng cách thực thi một script khi xảy ra
một số sự kiện. Rine và cộng sự. [10] đã đề xuất khái niệm bộ điều
hợp để tích hợp các thành phần. Một bộ điều hợp được liên kết với
mỗi thành phần; bộ điều hợp chạy một giao thức tương tác để quản lý
thông tin liên lạc giữa các thành phần. Các thành phần yêu cầu dịch
vụ từ những người khác thông qua các bộ điều hợp được liên kết của
chúng. Bộ điều hợp chịu trách nhiệm giải quyết bất kỳ sự không
khớp về giao diện cú pháp nào.
7.7.1 Kiểm tra thành phần ngoài giá
Các tổ chức của người mua thực hiện hai loại thử nghiệm trên một
thành phần OTS trước khi mua: (i) thử nghiệm chấp nhận thành phần
OTS dựa trên các tiêu chí được thảo luận trong Chương 14 và (ii)
tích hợp thành phần với các thành phần khác được phát triển trong
267
nhà hoặc mua từ một bên thứ ba. Nguyên nhân phổ biến nhất của các
vấn đề trong giai đoạn tích hợp là kiểm tra chấp nhận không đầy đủ
của thành phần OTS. Việc thiếu tài liệu rõ ràng về giao diện hệ thống
và ít hợp tác từ nhà cung cấp có thể tạo ra một thử thách trong việc
kiểm tra tích hợp, gỡ lỗi và sửa chữa các lỗi. Kiểm tra chấp nhận một
thành phần OTS yêu cầu phát triển và thực hiện một kế hoạch kiểm
tra chấp nhận dựa trên các tiêu chí chấp nhận cho thành phần ứng
viên. Tất cả các vấn đề được giải quyết trước khi quá trình tích hợp
hệ thống bắt đầu. Trong quá trình kiểm tra tích hợp, các thành phần
phần mềm bổ sung, chẳng hạn như keo hoặc lớp bọc, có thể được
phát triển để liên kết thành phần OTS với các thành phần khác để
hoạt động bình thường. Các thành phần phần mềm mới này cũng
được thử nghiệm trong giai đoạn tích hợp. Tích hợp các thành phần
OTS là một nhiệm vụ đầy thách thức vì các đặc điểm sau được xác
định bởi Basili và Boehm [11]:
Người mua không có quyền truy cập vào mã nguồn.
Nhà cung cấp kiểm soát sự phát triển của nó.
Nhà cung cấp đã cài đặt cơ sở không tầm thường.
Voas [12] đã đề xuất ba loại kỹ thuật kiểm tra để xác định tính phù
hợp của một thành phần OTS:
Kiểm tra thành phần hộp đen: Điều này được sử dụng để xác định
chất lượng của thành phần.
Thử nghiệm tiêm lỗi cấp hệ thống: Điều này được sử dụng để xác
định mức độ chịu đựng của hệ thống đối với một thành phần bị lỗi.
Việc tiêm lỗi ở cấp độ hệ thống không chứng tỏ độ tin cậy của hệ
thống; thay vào đó, nó có thể dự đoán hành vi của hệ thống nếu thành
phần OTS bị lỗi.
Kiểm tra Hệ thống Hoạt động: Loại kiểm tra này được sử dụng để
xác định khả năng chịu đựng của hệ thống phần mềm khi thành phần
OTS hoạt động chính xác. Kiểm tra hệ thống hoạt động được tiến
hành để đảm bảo rằng một thành phần OTS phù hợp tốt với hệ thống.
Các thành phần OTS do các tổ chức nhà cung cấp sản xuất được gọi
là các thành phần thương mại sẵn có (COTS). Một thành phần COTS
được định nghĩa bởi Szyperski et al. [13] (p. 34) là “một đơn vị cấu
thành với các giao diện được chỉ định theo hợp đồng và chỉ phụ
thuộc ngữ cảnh rõ ràng. Một thành phần phần mềm có thể được triển
khai độc lập và phụ thuộc vào thành phần của các bên thứ ba ”. Giao
diện là điểm truy cập của các thành phần COTS mà qua đó thành
phần khách có thể yêu cầu một dịch vụ được khai báo trong giao diện
của thành phần cung cấp dịch vụ. Weyuker [14] khuyến nghị rằng
các nhà cung cấp xây dựng các thành phần COTS phải cố gắng hình
dung ra nhiều cách sử dụng có thể có của thành phần và phát triển
một loạt các kịch bản thử nghiệm toàn diện. Một thành phần phải
không có sai sót vì những người mua thận trọng sẽ thực hiện một
lượng thử nghiệm đáng kể trong khi tích hợp thành phần đó với hệ
thống của họ. Nếu người mua tiềm năng gặp phải một số lượng lớn
các khuyết tật trong thành phần COTS, họ có thể không chấp nhận
thành phần đó. Vì vậy, lợi ích tốt nhất của nhà chế tạo thành phần là
đảm bảo rằng các thành phần được kiểm tra kỹ lưỡng. Một số đồ tạo
tác có liên quan nên được lưu trữ và / hoặc sửa đổi cho mỗi thành
phần COTS, bởi vì người mua tiềm năng có thể yêu cầu những đồ tạo
tác này có chất lượng cao. Các đồ tạo tác được lưu trữ bao gồm:
Các yêu cầu riêng lẻ, bao gồm các con trỏ giữa đặc tả chức năng
phần mềm và các triển khai tương ứng: Thông tin này giúp bạn dễ
dàng theo dõi khi mã hoặc thông số kỹ thuật được sửa đổi, điều này
ngụ ý rằng thông số kỹ thuật vẫn được cập nhật. • Bộ thử nghiệm,
bao gồm ma trận xác định nguồn gốc yêu cầu: Điều này sẽ cho thấy
phần nào của chức năng được thử nghiệm không đầy đủ hoặc hoàn
toàn không. Ngoài ra, nó xác định các trường hợp kiểm thử (i) phải
được thực hiện dưới dạng kiểm tra hồi quy hoặc (ii) cần được cập
nhật khi thành phần trải qua một thay đổi. • Kết quả đạt - không đạt
của từng trường hợp thử nghiệm trong bộ thử nghiệm: Điều này cho
biết chất lượng của thành phần COTS. • Chi tiết của các trường hợp
thử nghiệm riêng lẻ, bao gồm đầu vào và đầu ra dự kiến: Điều này
tạo điều kiện thuận lợi cho việc kiểm tra hồi quy các thay đổi đối với
một thành phần.
Báo cáo kiểm tra hệ thống tương ứng với bản phát hành cuối cùng
của thành phần COTS, bao gồm các đặc điểm hiệu suất, giới hạn khả
năng mở rộng, quan sát độ ổn định và khả năng tương tác của thành
phần COTS: Tài liệu này là một tài nguyên hữu ích cho người mua
tiềm năng trước khi họ bắt đầu kiểm tra chấp nhận các thành phần
COTS .
7.7.2 Kiểm tra tích hợp
269
Một thành phần được sử dụng lại trong môi trường ứng dụng mới
yêu cầu phát hiện, chẩn đoán và xử lý lỗi phần mềm theo thời gian
thực. Các phương pháp kiểm tra tích hợp (BIT) để sản xuất
7.8 TÓM TẮT
Các thành phần phần mềm tự kiểm tra có khả năng phát hiện lỗi
trong thời gian chạy. Một thành phần phần mềm có thể chứa các
trường hợp kiểm thử hoặc có thể sở hữu các phương tiện có khả năng
tạo ra các trường hợp kiểm thử mà người dùng thành phần có thể truy
cập theo yêu cầu [15]. Các khả năng tương ứng cho phép điều này
được gọi là khả năng kiểm thử tích hợp sẵn của các thành phần phần
mềm. Trong phương pháp luận của BIT, khả năng kiểm tra được kết
hợp vào các thành phần phần mềm, để việc kiểm tra và bảo trì có thể
được thực hiện khép kín.
Wang và cộng sự. [16] đã đề xuất một mô hình BIT có thể hoạt động
ở hai chế độ, đó là chế độ bình thường và chế độ bảo trì. Trong chế
độ bình thường, các khả năng BIT là minh bạch đối với người dùng
thành phần và thành phần không khác với các thành phần không hỗ
trợ BIT khác. Tuy nhiên, trong chế độ bảo trì, người dùng thành phần
có thể kiểm tra thành phần với sự trợ giúp của các tính năng BIT của
nó. Người dùng thành phần có thể gọi các phương thức tương ứng
của thành phần, các phương thức này thực hiện kiểm tra, tự đánh giá
kết quả của nó và xuất ra bản tóm tắt kiểm tra. Các tác giả mô tả một
khung kỹ thuật chung để nâng cao BIT. Một trong những giả định
của họ là thành phần được thực thi dưới dạng một lớp. Lợi ích của
việc triển khai như vậy là các phương thức cho BIT có thể được
chuyển đến một lớp con bằng cách kế thừa.
Hornstein và Edler [17] đã đề xuất kiến trúc a¨ component +
BIT bao gồm ba loại thành phần, đó là BIT, bộ kiểm tra và bộ xử lý.
Các thành phần BIT là các thành phần hỗ trợ BIT. Các thành phần
này thực hiện các giao diện bắt buộc nhất định. Người kiểm tra là các
thành phần truy cập các khả năng BIT của các thành phần BIT thông
qua các giao diện tương ứng và chứa các trường hợp kiểm thử ở một
dạng nhất định. Cuối cùng, trình xử lý là các thành phần không trực
tiếp đóng góp vào việc kiểm tra nhưng cung cấp cơ chế khôi phục
trong trường hợp hỏng hóc.
7.8 TÓM TẮT
Chương này bắt đầu với mục tiêu và mô tả về kiểm thử tích hợp hệ
thống. Người ta tạo ra một “phiên bản làm việc của hệ thống” bằng
cách đặt các mô-đun lại với nhau theo cách gia tăng trong khi thực
hiện các thử nghiệm để phát hiện ra các loại lỗi khác nhau liên quan
đến giao diện. Tiếp theo, chúng tôi đã khám phá các mức độ chi tiết
khác nhau trong kiểm tra tích hợp hệ thống: kiểm tra giữa các hệ
thống, kiểm tra liên hệ thống và kiểm tra theo cặp.
Sau đó, chúng tôi đã kiểm tra năm loại kỹ thuật tích hợp hệ thống
thường được sử dụng: từ trên xuống, từ dưới lên, bánh sandwich,
bigbang và tăng dần. Chúng tôi đã so sánh những kỹ thuật đó một
cách chi tiết. Kỹ thuật gia tăng được sử dụng rộng rãi trong ngành
công nghiệp.
Chúng tôi đã mô tả việc tích hợp các thành phần phần cứng và phần
mềm để tạo thành một sản phẩm hoàn chỉnh. Điều này dẫn đến cuộc
thảo luận về quy trình kỹ thuật phần cứng và cụ thể là các loại kiểm
tra xác minh thiết kế phần cứng khác nhau: chẩn đoán, phóng tĩnh
điện, phát xạ điện từ, điện, nhiệt, môi trường, đóng gói và xử lý, âm
thanh, an toàn và độ tin cậy. Cuối cùng, chúng tôi đã mô tả hai kịch
bản của một quy trình thay đổi kỹ thuật theo thứ tự. Hai kịch bản
được sử dụng để theo dõi ma trận khả năng tương thích phần cứng /
phần mềm của một sản phẩm đã phát hành.
Chúng tôi đã cung cấp một khung kế hoạch kiểm tra tích hợp. Các
danh mục kiểm tra sau đây, được bao gồm trong kế hoạch kiểm tra
tích hợp, đã được thảo luận chi tiết: kiểm tra tính toàn vẹn của giao
diện, kiểm tra tính hợp lệ chức năng, kiểm tra tính hợp lệ đầu cuối,
kiểm tra tính hợp lệ theo cặp, kiểm tra ứng suất giao diện và kiểm tra
độ bền.
Cuối cùng, chúng tôi đã mô tả sự tích hợp của các thành phần OTS
với các thành phần khác. Một tổ chức, thay vì phát triển một cấu
phần phần mềm từ đầu, có thể quyết định mua phần mềm COTS từ
nguồn của bên thứ ba và tích hợp phần mềm đó với hệ thống phần
mềm của riêng mình. Người bán thành phần COTS phải cung cấp
BIT cùng với các thành phần, trong khi tổ chức người mua phải thực
hiện ba loại thử nghiệm để đánh giá phần mềm COTS: (i) thử nghiệm
chấp nhận thành phần phần mềm OTS để xác định chất lượng của
thành phần, (ii) hệ thống - kiểm tra lỗi cấp độ, được sử dụng để xác
định khả năng chịu đựng của hệ thống phần mềm đối với thành phần
271
OTS bị lỗi và (iii) kiểm tra hệ thống hoạt động, được sử dụng để xác
định khả năng chịu đựng của hệ thống phần mềm đối với thành phần
OTS hoạt động bình thường.
Đối với những người tích cực tham gia vào kiểm thử phần mềm hoặc
muốn biết thêm về các lỗi phần mềm phổ biến, phụ lục A của cuốn
sách của C. Kaner, J. Falk, và HQ Nguyen (Kiểm thử Phần mềm
Máy tính, Wiley, New York, 1999) là một kho lưu trữ tuyệt vời lỗi
phần mềm trong đời thực. Phần phụ lục bao gồm 12 loại với khoảng
400 loại lỗi khác nhau với hình ảnh minh họa.
Có thể tìm thấy một cuộc thảo luận tốt về kỹ thuật kiểm tra phần
cứng, chẳng hạn như kiểm tra cơ khí, điện tử và kiểm tra gia tốc,
trong cuốn sách của Patrick O'Connor (Kỹ thuật kiểm tra: Hướng dẫn
súc tích để thiết kế, phát triển và sản xuất hiệu quả về chi phí, Wiley,
New York, 2001 ). Tác giả (i) mô tả một loạt các phương pháp và
công nghệ hiện đại trong kỹ thuật kiểm tra phần cứng, (ii) đưa ra các
nguyên tắc về thiết kế, phát triển và sản xuất các sản phẩm và hệ
thống hiệu quả về chi phí, và (iii) phân tích lý do tại sao sản phẩm và
hệ thống bị lỗi và phương pháp nào sẽ ngăn chặn tốt nhất những lỗi
này.
Các nhà nghiên cứu liên tục làm việc về các chủ đề liên quan đến
chứng nhận các thành phần COTS. Bạn đọc quan tâm được đề nghị
đọc các bài viết sau. Mỗi bài viết này giúp hiểu được các vấn đề của
chứng chỉ phần mềm và tại sao nó lại quan trọng:
J. Voas, “Chứng nhận giảm chi phí ẩn của chất lượng kém,” IEEE
Software, Vol. 16, số 4, tháng 7 / tháng 8 năm 1999, trang 22–25.
J. Voas, “Phần mềm chứng nhận cho môi trường đảm bảo cao”,
IEEE Software, Vol. 16, số 4, tháng 7 / tháng 8 năm 1999, trang 48–
54.
J. Voas, “Phát triển Quy trình Chứng nhận Phần mềm Dựa trên Cách
sử dụng,” IEEE Computer, Vol. 16, số 8, tháng 8 năm 2000, trang
32–37.
S. Wakid, D. Kuhn và D. Wallace, “Hướng tới Kiểm tra và Chứng
nhận CNTT đáng tin cậy,” IEEE Software, Vol. 16, số 4, tháng 7 /
tháng 8 năm 1999, trang 39–47.
Độc giả tích cực tham gia thử nghiệm thành phần COTS hoặc quan
tâm đến cách xử lý chủ đề phức tạp hơn được khuyến nghị đọc cuốn
sách do S. Beydeda và V. Gruhn biên tập (Thử nghiệm các thành
phần và hệ thống thương mại-off-the-Shelf, Springer, Bonn, 2005 ).
Cuốn sách bao gồm 15 bài báo thảo luận rất chi tiết: (i) kiểm thử ngữ
cảnh các thành phần một cách độc lập, (ii) kiểm thử các thành phần
trong ngữ cảnh của một hệ thống và (iii) kiểm thử các hệ thống dựa
trên thành phần. Cuốn sách liệt kê một số tài liệu tham khảo tuyệt vời
về chủ đề này trong một thư mục.
Mô tả sự khác biệt giữa kỹ thuật kiểm thử hộp đen và hộp trắng?
Nếu một chương trình vượt qua tất cả các bài kiểm tra hộp đen, điều
đó có nghĩa là chương trình đó sẽ hoạt động bình thường. Sau đó,
ngoài kiểm tra hộp đen, tại sao bạn cần thực hiện kiểm tra hộp trắng?
Mô tả sự khác biệt giữa kiểm thử đơn vị và kiểm thử tích hợp?
Tại sao nên thực hiện kiểm thử tích hợp? Giai đoạn thử nghiệm này
có thể phát hiện ra những loại lỗi nào?
Thảo luận về những ưu điểm và nhược điểm của cách áp dụng từ trên
xuống và từ dưới lên đối với thử nghiệm tích hợp.
Tự động hóa các thử nghiệm tích hợp có giúp xác minh quy trình xây
dựng hàng ngày không? Biện minh cho câu trả lời của bạn.
Sử dụng hệ thống phân cấp mô-đun được cho trong Hình 7.13, hiển
thị thứ tự tích hợp mô-đun cho các phương pháp tiếp cận tích hợp từ
trên xuống và từ dưới lên. Ước tính số lượng sơ khai và trình điều
khiển cần thiết cho mỗi cách tiếp cận. Chỉ định các hoạt động kiểm
tra tích hợp có thể được thực hiện song song, giả sử bạn có ba kỹ sư
SIT. Dựa trên nhu cầu nguồn lực và khả năng thực hiện các hoạt
động SIT đồng thời, bạn sẽ chọn cách tiếp cận nào cho hệ thống này
và tại sao?
Giả sử rằng bạn định mua các thành phần COTS và tích hợp chúng
với dự án phần mềm truyền thông của bạn. Bạn sẽ phát triển loại tiêu
chí chấp nhận nào để tiến hành kiểm tra chấp nhận các thành phần
COTS?
Trong quá trình kiểm tra tích hợp các thành phần COTS với một hệ
thống phần mềm, có thể yêu cầu phát triển một phần mềm bao bọc
xung quanh thành phần OTS để hạn chế những gì nó có thể làm.
Thảo luận về các đặc điểm chung của một phần mềm gói
273
A
B C D
E F G H I
J K L M
Hình 7.13 Phân cấp mô-đun của hệ thống phần mềm.
cần có để có thể tích hợp COTS với hệ thống phần mềm mà không
gặp bất kỳ vấn đề gì.
Mô tả các trường hợp mà bạn sẽ áp dụng thử nghiệm hộp trắng, thử
nghiệm hộp sau hoặc cả hai kỹ thuật để đánh giá thành phần COTS.
Đối với dự án thử nghiệm hiện tại của bạn, hãy phát triển một kế
hoạch thử nghiệm tích hợp.
Hoàn thành Phần 5 (tức là kết quả kiểm tra thực tế cho mỗi giai đoạn
kiểm tra tích hợp) của kế hoạch kiểm tra tích hợp sau khi thực hiện
các trường hợp kiểm tra tích hợp mà bạn đã phát triển trong bài tập
11.
274 CHƯƠNG 8 CÁC DANH MỤC KIỂM TRA HỆ THỐNG
CHAPTER
8
SystemTestCategories
Theo quy luật, các hệ thống phần mềm không hoạt động tốt cho đến
khi chúng được sử dụng và liên tục bị lỗi trong các ứng dụng thực tế.
—DaveParnas
8.1 TÍNH THUẾ CỦA CÁC THỬ NGHIỆM HỆ THỐNG
Mục tiêu của kiểm thử mức hệ thống, còn được gọi là kiểm thử hệ
thống, là để xác định xem liệu việc triển khai có phù hợp với các yêu
cầu do khách hàng chỉ định hay không. Cần nhiều nỗ lực để đảm bảo
rằng các yêu cầu của khách hàng đã được đáp ứng và hệ thống có thể
chấp nhận được. Một loạt các bài kiểm tra cũng được thực hiện để
đáp ứng một loạt các kỳ vọng không xác định. Vì các hệ thống tích
hợp, bao gồm cả các thành phần phần cứng và phần mềm, thường
được sử dụng trong thực tế, nên cần có một cái nhìn rộng hơn nhiều
về hoạt động của hệ thống. Ví dụ, một hệ thống chuyển mạch điện
thoại không chỉ được yêu cầu cung cấp kết nối giữa hai người dùng
mà còn phải làm như vậy ngay cả khi có nhiều kết nối đang diễn ra
dưới một giới hạn trên nhất định. Khi đạt đến giới hạn trên về số
lượng kết nối đồng thời, hệ thống sẽ không hoạt động theo cách
không mong muốn. Trong chương này, chúng tôi xác định các danh
mục kiểm tra khác nhau ngoài kiểm tra chức năng cốt lõi. Việc xác
định các danh mục thử nghiệm mang lại cho chúng tôi những lợi thế
sau:
Các kỹ sư kiểm tra có thể tập trung chính xác vào các khía cạnh khác
nhau của hệ thống tại một thời điểm, đồng thời đánh giá chất lượng
của nó.
Các kỹ sư kiểm tra có thể sắp xếp thứ tự ưu tiên các nhiệm vụ của họ
dựa trên các hạng mục kiểm tra. Ví dụ, sẽ có ý nghĩa và hữu ích hơn
nếu chỉ xác định các hạn chế của hệ thống sau khi đảm bảo rằng hệ
thống thực hiện tất cả các chức năng cơ bản để kiểm tra sự thỏa mãn
của kỹ sư. Do đó, các bài kiểm tra căng thẳng, phát triển mạnh để xác
8.3 KIỂM TRA CHỨC NĂNG 275
định các hạn chế của hệ thống, được thực hiện sau các bài kiểm tra
chức năng. • Lập kế hoạch giai đoạn thử nghiệm hệ thống dựa trên
phân loại thử nghiệm cho phép kỹ sư thử nghiệm có được bộ thử
nghiệm cân bằng tốt. Những hạn chế thực tế làm cho nó khó được
thấu đáo và các cân nhắc kinh tế có thể hạn chế
192
8.1 TÍNH THUẾ CỦA CÁC THỬ NGHIỆM HỆ THỐNG
quá trình thử nghiệm không tiếp tục nữa. Tuy nhiên, điều quan trọng
là phải thiết kế một bộ thử nghiệm cân bằng, thay vì một bộ không
cân bằng với nhiều trường hợp thử nghiệm trong một danh mục và
không có thử nghiệm nào trong danh mục khác.
Sau đây, trước tiên chúng tôi trình bày phân loại của các bài kiểm tra
hệ thống (Hình 8.1). Sau đó, chúng tôi giải thích chi tiết từng danh
mục.
Các thử nghiệm cơ bản cung cấp bằng chứng rằng hệ thống có thể
được cài đặt, cấu hình và đưa về trạng thái hoạt động.
Kiểm tra chức năng cung cấp kiểm tra toàn diện trên toàn bộ các yêu
cầu trong khả năng của hệ thống.
Các bài kiểm tra độ chắc chắn xác định mức độ phục hồi của hệ
thống từ các lỗi đầu vào khác nhau và các tình huống hỏng hóc khác.
Kiểm tra khả năng tương tác xác định liệu hệ thống có thể tương tác
với các sản phẩm của bên thứ ba khác hay không.
Kiểm tra hiệu suất đo lường các đặc tính hoạt động của hệ thống, ví
dụ, thông lượng và thời gian phản hồi, trong các điều kiện khác nhau.
Kiểm tra khả năng mở rộng xác định giới hạn mở rộng của hệ thống
về quy mô người dùng, quy mô địa lý và mở rộng tài nguyên.
Kiểm tra ứng suất đặt một hệ thống bị căng thẳng để xác định các hạn
chế của hệ thống và khi nó bị lỗi, để xác định cách thức xảy ra lỗi.
Basic
Functionality
Robustness
Interoperability
Performance
Scalability
Types of system
tests
Stress
Load and stability
Reliability
Regression
Documentation
Regulatory
Hình 8.1 Các loại kiểm tra hệ thống.
Các bài kiểm tra tải và độ ổn định cung cấp bằng chứng rằng hệ
thống vẫn ổn định trong một thời gian dài dưới chế độ đầy tải.
Các bài kiểm tra độ tin cậy đo lường khả năng hệ thống duy trì hoạt
động trong một thời gian dài mà không phát sinh lỗi.
Kiểm tra hồi quy xác định rằng hệ thống vẫn ổn định khi nó xoay
vòng thông qua việc tích hợp các hệ thống con khác và thông qua các
nhiệm vụ bảo trì.
Kiểm tra tài liệu đảm bảo rằng các hướng dẫn sử dụng của hệ thống
là chính xác và có thể sử dụng được.
Kiểm tra quy định đảm bảo rằng hệ thống đáp ứng các yêu cầu của
các cơ quan quản lý của chính phủ ở các quốc gia nơi nó sẽ được
triển khai.
8.2 CÁC KIỂM TRA CƠ BẢN
Các thử nghiệm cơ bản (Hình 8.2) cung cấp bằng chứng sơ bộ rằng
hệ thống đã sẵn sàng cho các thử nghiệm nghiêm ngặt hơn. Các thử
nghiệm này cung cấp thử nghiệm giới hạn của hệ thống liên quan đến
các tính năng chính trong đặc tả yêu cầu. Mục tiêu là xác định rằng có
đủ bằng chứng cho thấy một hệ thống có thể hoạt động mà không cần
cố gắng thực hiện kiểm tra kỹ lưỡng. Các thử nghiệm cơ bản được
thực hiện để đảm bảo rằng các chức năng thường được sử dụng,
không phải tất cả các chức năng này đều có thể liên quan trực tiếp
đến các chức năng cấp người dùng, hoạt động để làm hài lòng chúng
tôi. Chúng tôi nhấn mạnh thực tế là các kỹ sư kiểm tra dựa vào việc
triển khai đúng các chức năng này để thực hiện kiểm tra các chức
năng cấp người dùng. Sau đây là các danh mục chính của hệ thống
con mà thử nghiệm đầy đủ được gọi là thử nghiệm cơ bản.
8.2.1 Kiểm tra khởi động
Kiểm tra khởi động được thiết kế để xác minh rằng hệ thống có thể
khởi động hình ảnh phần mềm (hoặc bản dựng) từ các tùy chọn khởi
động được hỗ trợ. Các tùy chọn khởi động bao gồm khởi động từ
ROM, thẻ FLASH và thẻ PCMCIA (Hiệp hội thẻ nhớ máy tính cá
nhân quốc tế). Các cấu hình tối thiểu và tối đa của hệ thống phải được
thử trong khi khởi động. Ví dụ, cấu hình tối thiểu của bộ định tuyến
bao gồm một thẻ dòng trong các khe cắm của nó, trong khi cấu hình
tối đa của bộ định tuyến có nghĩa là tất cả các khe chứa thẻ dòng.
Boot
Upgrade/downgrade
Types of basic tests Light emitting diode
Diagnostic
Command line interface

Hình 8.2 Các loại thử nghiệm cơ bản.
8.2 CÁC KIỂM TRA CƠ BẢN
8.2.2 Kiểm tra nâng cấp / hạ cấp
Kiểm tra nâng cấp / hạ cấp được thiết kế để xác minh rằng phần mềm
hệ thống có thể được nâng cấp hoặc hạ cấp (khôi phục) một cách
duyên dáng từ phiên bản trước sang phiên bản hiện tại hoặc ngược
lại. Giả sử rằng hệ thống đang chạy phiên bản thứ (n - 1) của bản
dựng phần mềm và có sẵn phiên bản thứ n của bản dựng phần mềm
mới. Câu hỏi đặt ra là làm cách nào để nâng cấp bản dựng từ phiên
bản thứ (n - 1) lên phiên bản thứ n. Quá trình nâng cấp đưa hệ thống
từ phiên bản thứ (n - 1) lên phiên bản thứ n có thể không thành công,
trong trường hợp đó, hệ thống được đưa trở lại phiên bản thứ (n - 1).
Các thử nghiệm được thiết kế trong nhóm con này để xác minh rằng
hệ thống hoàn nguyên thành công, tức là quay trở lại, về phiên bản
thứ (n - 1). Quá trình nâng cấp có thể không thành công do một số
điều kiện khác nhau: hủy bỏ do người dùng yêu cầu (người dùng làm
gián đoạn quá trình nâng cấp), gián đoạn mạng trong quá trình (môi
trường mạng gặp sự cố), khởi động lại hệ thống trong quá trình (có sự
cố nguồn ), hoặc tự phát hiện lỗi nâng cấp (nguyên nhân là do không
đủ dung lượng đĩa và không tương thích với phiên bản).
8.2.3 Kiểm tra điốt phát sáng
Các bài kiểm tra LED (điốt phát quang) được thiết kế để xác minh
rằng các chỉ báo trạng thái LED của hệ thống hoạt động như mong
muốn. Các đèn LED nằm trên mặt trước của hệ thống. Chúng cung
cấp chỉ báo trực quan về trạng thái hoạt động của mô-đun. Ví dụ, hãy
xem xét trạng thái của khung hệ thống: Màu xanh lục cho biết khung
đang hoạt động, tắt cho biết không có điện và màu xanh lá cây nhấp
nháy có thể cho biết một hoặc nhiều mô-đun con của nó bị lỗi. Các
thử nghiệm LED được thiết kế để đảm bảo rằng trạng thái hoạt động
trực quan của hệ thống và các mô-đun con là chính xác. Ví dụ về
kiểm tra LED ở cấp hệ thống và hệ thống con như sau: • Kiểm tra
LED hệ thống: xanh lá cây = OK, nhấp nháy xanh lá cây = lỗi, tắt =
không có nguồn.
Kiểm tra đèn LED liên kết Ethernet: màu xanh lá cây = OK, nhấp
nháy màu xanh lá cây = hoạt động, tắt = lỗi.
Kiểm tra liên kết cáp: màu xanh lá cây = OK, nhấp nháy màu xanh lá
cây = hoạt động, tắt = lỗi.
Người dùng xác định thẻ dòng T1 Kiểm tra đèn LED: màu xanh lá
cây = OK, nhấp nháy màu xanh lá cây = hoạt động, màu đỏ = lỗi, tắt
= không có nguồn.
8.2.4 Kiểm tra chẩn đoán
Kiểm tra chẩn đoán được thiết kế để xác minh rằng các thành phần
phần cứng (hoặc mô-đun) của hệ thống đang hoạt động như mong
muốn. Nó còn được gọi là tự kiểm tra tích hợp (BIST). Kiểm tra chẩn
đoán giám sát, cô lập và xác định các sự cố hệ thống mà không cần
khắc phục sự cố thủ công. Một số ví dụ về các xét nghiệm chẩn đoán
như sau:
Tự kiểm tra khi bật nguồn (POST): Đây là một tập hợp các quy
trình chẩn đoán tự động được thực hiện trong giai đoạn khởi động của
mỗi mô-đun con trong hệ thống. Các POST nhằm xác định xem phần
cứng có ở trạng thái thích hợp để thực thi hình ảnh phần mềm hay
không. Nó không nhằm mục đích toàn diện trong việc phân tích phần
cứng; thay vào đó, nó cung cấp mức độ tin cậy cao rằng phần cứng
đang hoạt động. Các POST thực thi trên các loại phần tử sau:
Kỉ niệm
Xe buýt địa chỉ và dữ liệu
Thiết bị ngoại vi
Kiểm tra Ethernet Loop-Back: Kiểm tra này tạo và gửi đi số lượng
mong muốn, là một tham số có thể điều chỉnh được, của các gói và
mong đợi nhận được cùng một số lượng gói Ethernet thông qua giao
diện loop-back — bên ngoài hoặc bên trong. Nếu lỗi xảy ra (ví dụ:
gói không khớp hoặc hết thời gian chờ), thông báo lỗi cho biết loại
lỗi, (các) nguyên nhân có thể xảy ra và (các) hành động được đề xuất
sẽ hiển thị trên bảng điều khiển. Dữ liệu được gửi đi được tạo ra bởi
một bộ tạo số ngẫu nhiên và được đưa vào bộ đệm dữ liệu. Mỗi khi
một gói được gửi đi, nó sẽ được chọn từ một điểm bắt đầu khác nhau
của bộ đệm dữ liệu, do đó bất kỳ hai gói nào được truyền liên tiếp
không có khả năng giống hệt nhau. Các kiểm tra này được thực hiện
để đảm bảo rằng card Ethernet đang hoạt động như mong muốn.
Kiểm tra lỗi bit (BERT): BERT trên bo mạch cung cấp các mẫu lỗi
bit tiêu chuẩn, có thể được truyền qua kênh cho mục đích chẩn đoán.
BERT liên quan đến việc truyền một mẫu bit đã biết và sau đó kiểm
tra mẫu đã truyền để tìm lỗi. Tỷ lệ giữa số bit có lỗi trên tổng số bit
được truyền được gọi là tỷ lệ lỗi bit (BER). Các thử nghiệm được
thiết kế để cấu hình tất cả các BERT từ giao diện dòng lệnh (CLI).
Các bài kiểm tra này được thực hiện để đảm bảo rằng phần cứng đang
hoạt động như mong muốn.
8.2.5 Kiểm tra giao diện dòng lệnh
Các bài kiểm tra CLI được thiết kế để xác minh rằng hệ thống có thể
được cấu hình hoặc cung cấp, theo những cách cụ thể. Điều này là để
đảm bảo rằng mô-đun phần mềm CLI xử lý các lệnh của người dùng
một cách chính xác như được ghi trong tài liệu. Điều này bao gồm
việc truy cập thông tin liên quan từ hệ thống bằng CLI. Ngoài các thử
nghiệm trên, các kịch bản thử nghiệm có thể được phát triển để xác
minh các thông báo lỗi được hiển thị.
8.3 KIỂM TRA CHỨC NĂNG
Các thử nghiệm chức năng (Hình 8.3) xác minh hệ thống càng kỹ
càng tốt trên toàn bộ các yêu cầu được quy định trong tài liệu đặc tả
yêu cầu.
Loại bài kiểm tra này được phân chia thành các nhóm chức năng
khác nhau như sau.
8.3.1 Kiểm tra Hệ thống Truyền thông
Các bài kiểm tra hệ thống thông tin liên lạc được thiết kế để xác minh
việc thực hiện các hệ thống thông tin liên lạc như được chỉ định trong
đặc tả yêu cầu của khách hàng.
Communication systems
Module
Logging and tracing
Element management
systems
Types of
functionality tests Managament information
base
Graphical user interface
Security
Feature
Hình 8.3 Các loại kiểm tra chức năng.

Ví dụ: một trong những yêu cầu của khách hàng có thể là hỗ trợ Yêu
cầu Bình luận (RFC) 791, là đặc tả Giao thức Internet (IP). Các thử
nghiệm được thiết kế để đảm bảo rằng việc triển khai IP tuân theo
tiêu chuẩn RFC791. Bốn loại thử nghiệm hệ thống thông tin liên lạc
được khuyến nghị tùy theo mức độ mà chúng cung cấp một dấu hiệu
về sự phù hợp [1]:
Các thử nghiệm kết nối cơ bản cung cấp bằng chứng cho thấy việc
triển khai có thể thiết lập kết nối cơ bản trước khi thực hiện thử
nghiệm kỹ lưỡng.
Kiểm tra khả năng kiểm tra xem việc triển khai cung cấp các khả
năng có thể quan sát được dựa trên các yêu cầu của hệ thống truyền
thông tĩnh. Yêu cầu tĩnh mô tả các tùy chọn, phạm vi giá trị cho các
tham số và bộ định thời.
Các bài kiểm tra hành vi cố gắng xác minh các yêu cầu của hệ thống
giao tiếp động của một quá trình triển khai. Đây là các yêu cầu và tùy
chọn xác định hành vi có thể quan sát được của một giao thức. Một
phần lớn các bài kiểm tra hành vi, cấu thành phần chính của các bài
kiểm tra hệ thống truyền thông, có thể được tạo ra từ các tiêu chuẩn
giao thức.
Kiểm tra độ phân giải của hệ thống thăm dò để đưa ra câu trả lời xác
định “có” hoặc “không” cho các yêu cầu cụ thể.
8.3.2 Kiểm tra mô-đun
Kiểm tra mô-đun được thiết kế để xác minh rằng tất cả các mô-đun
hoạt động riêng lẻ như mong muốn trong hệ thống. Sự tương tác lẫn
nhau giữa các mô-đun sẽ kết dính các thành phần này lại với nhau
thành một hệ thống hoàn chỉnh. Ý tưởng ở đây là đảm bảo rằng các
mô-đun riêng lẻ hoạt động chính xác trong toàn bộ hệ thống. Người
ta cần xác minh rằng hệ thống, cùng với phần mềm điều khiển các
mô-đun này, hoạt động như được chỉ định trong đặc tả yêu cầu. Ví
dụ, một bộ định tuyến Internet có chứa các mô-đun như thẻ đường
truyền, bộ điều khiển hệ thống, bộ nguồn và khay quạt. Các thử
nghiệm được thiết kế để xác minh từng chức năng. Đối với thẻ dòng
Ethernet, các bài kiểm tra được thiết kế để xác minh (i) tự động, (ii)
độ trễ, (iii) va chạm, (iv) loại khung và (v) độ dài khung. Các thử
nghiệm được thiết kế để đảm bảo rằng phần mềm đọc, báo cáo chính
xác trạng thái quạt và hiển thị trong các đèn LED của mô-đun cung
cấp (một màu xanh lá cây “đang hoạt động” và một màu đỏ “không
hoạt động”). Đối với thẻ dòng T1 / E1, các bài kiểm tra được thiết kế
để xác minh:
Đồng hồ: Nội bộ (định thời nguồn) và nhận phục hồi đồng hồ (định
thời vòng lặp).
báo: Phát hiện mất tín hiệu (LOS), mất khung hình (LOF), tín hiệu
chỉ báo cảnh báo (AIS) và chèn AIS.
Mã hóa dòng: Đảo ngược dấu thay thế (AMI) cho cả T1 và E1, thay
thế bằng 0 lưỡng cực 8 (B8ZS) chỉ cho T1 và lưỡng cực 3 mật độ cao
(HDB3) chỉ cho E1.
Phân khung: Tín hiệu số 1 (DS1) và phân khung E1.
Phân kênh: Khả năng chuyển lưu lượng người dùng qua các kênh
được ghép kênh từ một hoặc nhiều khe thời gian liền kề hoặc không
liền kề trên một liên kết T1 hoặc E1.
8.3.3 Kiểm tra Ghi nhật ký và Truy tìm nguồn gốc
Kiểm tra ghi nhật ký và truy tìm được thiết kế để xác minh các cấu
hình và hoạt động của ghi nhật ký và truy tìm. Điều này cũng bao
gồm việc xác minh nhật ký "bộ ghi dữ liệu chuyến bay: bộ nhớ flash
không bay hơi" khi hệ thống gặp sự cố. Các bài kiểm tra có thể được
thiết kế để tính toán tác động đến hiệu suất hệ thống khi tất cả các bản
ghi được bật.
8.3.4 Kiểm tra hệ thống quản lý yếu tố
Các bài kiểm tra EMS xác minh các chức năng chính là quản lý, giám
sát và nâng cấp các phần tử mạng của hệ thống thông tin liên lạc
(NE). Bảng 8.1 tóm tắt các chức năng của EMS. EMS giao tiếp với
các NE của nó bằng cách sử dụng, ví dụ: Giao thức quản lý mạng đơn
giản (SNMP) [2] và nhiều giao thức và cơ chế độc quyền.
EMS là một thành phần có giá trị của mạng hệ thống thông tin liên
lạc. Không phải tất cả EMS sẽ thực hiện tất cả các nhiệm vụ được liệt
kê trong Bảng 8.1. EMS có thể hỗ trợ một tập hợp con các nhiệm vụ.
Người dùng làm việc thông qua giao diện người dùng đồ họa EMS
(GUI) có thể hoàn thành một số hoặc tất cả các tác vụ. Truy cập từ xa
vào một EMS cho phép người vận hành truy cập thông tin quản lý và
kiểm soát từ bất kỳ vị trí nào. Điều này tạo điều kiện thuận lợi cho
việc triển khai lực lượng lao động phân tán có thể nhanh chóng phản
hồi các thông báo lỗi. Điều này có nghĩa là các máy trạm khách mỏng
có thể hoạt động qua Internet và mạng nội bộ của nhà cung cấp dịch
vụ. Trong nhóm con này, các bài kiểm tra được thiết kế để
BẢNG 8.1 Các chức năng của EMS
Fault Configuration Accounting Performance Security

Managemen Management Managemen Managemen Managemen
t t t t
Alarm System turn- Track Data Control NE
handling up service collection access
usage
Trouble Network Bill for Report Enable NE
detection provisioning services generation functions
Trouble Autodiscover Data Access logs
correction y analysis
Test and Back-up and
acceptance restore
Network Database
recovery handling
xác minh năm chức năng của EMS (Bảng 8.1). Điều này bao gồm cả
máy khách EMS và máy chủ EMS. Ví dụ về các thử nghiệm EMS
được đưa ra dưới đây.
Tự động khám phá: Phần mềm phát hiện EMS có thể được cài đặt
trên máy chủ để khám phá các phần tử gắn liền với EMS thông qua
mạng IP.
Thăm dò và đồng bộ hóa: Máy chủ EMS phát hiện tình trạng không
thể truy cập hệ thống trong một khoảng thời gian nhất định. Máy chủ
EMS đồng bộ hóa trạng thái cảnh báo, dữ liệu cấu hình và thời gian
của hệ thống định vị toàn cầu (GPS) từ NE.
Hoạt động kiểm toán: Cơ chế kiểm tra được kích hoạt bất cứ khi
nào một phần tử mạng không hoạt động trở lại. Cơ chế đồng bộ hóa
các cảnh báo giữa các NE ngoài dịch vụ trực tuyến trở lại và EMS.
Trình quản lý lỗi: Việc tạo ra các sự kiện quan trọng, chẳng hạn như
khởi động lại và đặt lại, được chuyển đổi thành cảnh báo và được lưu
trữ trong cơ sở dữ liệu EMS. EMS có thể gửi một email / trang đến
một địa chỉ đã định cấu hình khi một cảnh báo được tạo ra.
Trình quản lý hiệu suất: Dữ liệu được đẩy đến máy chủ EMS khi
bộ đệm dữ liệu đầy trong NE. Dữ liệu trong bộ đệm máy chủ được
lưu trữ trong các tệp sao lưu khi nó đầy.
Trình quản lý bảo mật: Nó hỗ trợ xác thực và ủy quyền các máy
khách EMS và NE. Máy chủ EMS thực hiện ủy quyền dựa trên các
đặc quyền của người dùng.
Chính sách: Máy chủ EMS hỗ trợ truyền tệp nhật ký có thể lập lịch
từ hệ thống. Cơ sở dữ liệu EMS được sao lưu định kỳ vào đĩa.
Ghi nhật ký: Máy chủ EMS hỗ trợ các cấp độ ghi nhật ký khác nhau
cho mọi mô-đun chính cần gỡ lỗi. Máy chủ EMS luôn ghi lại các lỗi
và ngoại lệ.
Quản trị và Bảo trì: Kiểm tra này định cấu hình số lượng tối đa các
máy khách EMS đồng thời. Máy chủ EMS sao lưu và khôi phục cơ sở
dữ liệu theo định kỳ.
Gọi máy khách: Một số máy khách có thể được gọi để tương tác với
máy chủ EMS.
Xem dữ liệu trực tiếp: Khách hàng có thể cung cấp trình xem dữ
liệu trực tiếp để theo dõi hiệu suất và hiển thị số liệu thống kê của hệ
thống.
Nhiệm vụ quản trị hệ thống: Máy khách có thể tắt máy chủ, định
cấu hình mức ghi nhật ký, hiển thị trạng thái máy chủ và bật tính
năng tự động khám phá.
Truyền tệp: Khách hàng có thể kiểm tra quá trình truyền tệp theo
yêu cầu bằng thanh tiến trình để cho biết tiến trình và hủy thao tác
truyền tệp theo yêu cầu.
Ví dụ về SNMP SNMP là một giao thức lớp ứng dụng tạo điều kiện
thuận lợi cho việc trao đổi thông tin quản lý giữa các phần tử mạng.
SNMP là một phần của kiến trúc quản lý mạng Internet bao gồm ba
thành phần: phần tử mạng, tác nhân và trạm quản lý mạng (NMS).
NE là một nút mạng có chứa tác nhân SNMP và nằm trên mạng được
quản lý. Các phần tử mạng thu thập và lưu trữ thông tin quản lý và
cung cấp thông tin này cho NMS qua giao thức SNMP. Các phần tử
mạng có thể là bộ định tuyến, máy chủ, nút vô tuyến, cầu nối, trung
tâm, máy tính chủ, máy in và modem. Tác nhân là một mô-đun phần
mềm quản lý mạng (i) nằm trên một NE, (ii) có kiến thức cục bộ về
thông tin quản lý và (iii) chuyển thông tin đó sang dạng tương thích
với SNMP. Một NMS, đôi khi được gọi là bảng điều khiển, thực thi
các ứng dụng quản lý để giám sát và điều khiển các phần tử mạng.
Một hoặc nhiều NMS tồn tại trên mỗi mạng được quản lý. EMS có
thể hoạt động như một NMS.
Cơ sở thông tin quản lý (MIB) là một thành phần quan trọng của hệ
thống quản lý mạng. MIB xác định các phần tử mạng (hoặc các đối
tượng được quản lý) sẽ được quản lý. Hai loại đối tượng được quản lý
tồn tại:
Đối tượng vô hướng xác định một thể hiện đối tượng duy nhất.
Các đối tượng dạng bảng xác định nhiều trường hợp đối tượng liên
quan được nhóm trong các bảng MIB.
Về cơ bản, MIB là một cửa hàng ảo cung cấp mô hình thông tin được
quản lý. Ví dụ, một MIB có thể chứa thông tin về số lượng gói đã
được gửi và nhận trên một giao diện. Nó chứa số liệu thống kê về số
•
lượng kết nối tồn tại trên cổng Giao thức điều khiển truyền (TCP)
cũng như thông tin mô tả khả năng truy cập các phần tử của MIB của
mỗi người dùng. SNMP không hoạt động trực tiếp trên các đối tượng
được quản lý; thay vào đó, giao thức hoạt động trên MIB. Đổi lại,
MIB là phản ánh của các đối tượng được quản lý và cơ chế quản lý
của nó phần lớn là độc quyền, có lẽ thông qua EMS.
Khía cạnh quan trọng của MIB là nó xác định (i) các yếu tố được
quản lý, (ii) cách người dùng truy cập chúng và (iii) cách chúng có
thể được báo cáo. MIB có thể được mô tả như một cây trừu tượng có
gốc không tên; các mục riêng lẻ được biểu thị như lá của cây. Một mã
định danh đối tượng xác định duy nhất một đối tượng MIB trong cây.
Việc tổ chức các mã định danh đối tượng tương tự như hệ thống phân
cấp số điện thoại; chúng được tổ chức phân cấp với các chữ số cụ thể
được ấn định bởi các tổ chức khác nhau. Cấu trúc Thông tin Quản lý
(SMI) xác định các quy tắc để mô tả thông tin quản lý. SMI chỉ định
rằng tất cả các đối tượng được quản lý đều có tên, cú pháp và cơ chế
mã hóa. Tên được sử dụng làm định danh đối tượng. Cú pháp xác
định kiểu dữ liệu của đối tượng. Cú pháp SMI sử dụng một tập hợp
con của các định nghĩa Ký hiệu Cú pháp Tóm tắt Một (ASN.1). Cơ
chế mã hóa mô tả cách thông tin liên quan đến đối tượng được quản
lý được định dạng như một chuỗi các mục dữ liệu để truyền trên
mạng.
Các phần tử mạng được giám sát và điều khiển bằng cách sử dụng
bốn lệnh SNMP cơ bản: đọc, ghi, bẫy và hoạt động truyền tải. Lệnh
đọc được sử dụng bởi NMS để giám sát các NE. Một NMS kiểm tra
các biến khác nhau được duy trì bởi các NE. Lệnh ghi được sử dụng
bởi một NMS để điều khiển các NE. Với lệnh ghi, một NMS thay đổi
giá trị của các biến được lưu trữ trong NE. Lệnh bẫy được sử dụng
bởi các NE để báo cáo không đồng bộ các sự kiện cho NMS. Khi một
số loại sự kiện nhất định xảy ra, một NE sẽ gửi một cái bẫy đến một
NMS. Các hoạt động truyền tải được NMS sử dụng để xác định các
biến mà NE hỗ trợ và để thu thập tuần tự thông tin trong một bảng
biến, chẳng hạn như bảng định tuyến.
SNMP là một giao thức yêu cầu / phản hồi đơn giản có thể gửi nhiều
yêu cầu. Sáu hoạt động SNMP được xác định. Thao tác Get cho phép
NMS truy xuất một đối tượng tức thì từ một tác nhân. Thao tác
GetNext cho phép NMS truy xuất phiên bản đối tượng tiếp theo từ
bảng hoặc danh sách bên trong tác nhân. Hoạt động GetBulk cho
phép một NMS thu được một lượng lớn thông tin liên quan mà không
cần liên tục gọi hoạt động GetNext. Thao tác Đặt cho phép NMS đặt
giá trị cho các cá thể đối tượng bên trong một tác nhân. Hoạt động
Bẫy được một tác nhân sử dụng để thông báo không đồng bộ cho
NMS về một số sự kiện. Hoạt động Thông báo cho phép một NMS
gửi thông tin bẫy đến một NMS khác.
Thông điệp SNMP bao gồm hai phần: tiêu đề và đơn vị dữ liệu giao
thức (PDU). Tiêu đề thư chứa hai trường, cụ thể là số phiên bản và
tên cộng đồng. Một PDU có các trường sau: Loại PDU, ID yêu cầu,
trạng thái lỗi, chỉ số lỗi và các ràng buộc biến. Các mô tả sau đây tóm
tắt các trường khác nhau:
Số phiên bản: Số phiên bản chỉ định phiên bản SNMP đang được sử
dụng.
Tên cộng đồng: Tên này xác định môi trường truy cập cho một
nhóm NMS. Các NMS trong một cộng đồng được cho là tồn tại trong
cùng một miền quản trị. Tên cộng đồng đóng vai trò là một hình thức
xác thực yếu vì các thiết bị không biết tên cộng đồng thích hợp sẽ bị
loại trừ khỏi các hoạt động SNMP.
Loại PDU: Điều này chỉ định loại PDU được truyền.
ID yêu cầu: ID yêu cầu được liên kết với phản hồi tương ứng.
Trạng thái Lỗi: Điều này cho biết một lỗi và hiển thị một loại lỗi.
Trong hoạt động GetBulk, trường này trở thành trường nonrepeater
bằng cách xác định số lượng biến được yêu cầu được liệt kê sẽ được
truy xuất không quá một lần từ đầu yêu cầu. Trường được sử dụng
khi một số biến là đối tượng vô hướng với một biến.
Chỉ mục lỗi: Chỉ mục lỗi liên kết lỗi với một trường hợp đối tượng
cụ thể. Trong hoạt động GetBulk, trường này trở thành trường Số lần
lặp lại tối đa. Trường này xác định số lần tối đa mà các biến khác
ngoài những biến được chỉ định bởi trường nonrepeater sẽ được truy
xuất.
Liên kết biến (varbinds): Bao gồm dữ liệu của một SNMP PDU.
Các liên kết biến liên kết các cá thể đối tượng cụ thể với giá trị hiện
•
tại của chúng (ngoại trừ các yêu cầu Get và GetNext, mà giá trị bị bỏ
qua).
8.3.5 Kiểm tra cơ sở thông tin quản lý
Các bài kiểm tra MIB được thiết kế để xác minh (i) các MIB tiêu
chuẩn bao gồm MIB II và (ii) các MIB doanh nghiệp cụ thể cho hệ
thống. Các thử nghiệm có thể bao gồm xác minh tác nhân trong hệ
thống triển khai các đối tượng mà nó tuyên bố. Mọi đối tượng MIB
đều được kiểm tra với các nguyên thủy sau: Get, GetNext, GetBulk
và Set. Cần xác minh rằng tất cả các bộ đếm liên quan đến MIB đều
được gia tăng một cách chính xác và tác nhân có khả năng tạo (i) các
bẫy đã biết (ví dụ: coldstart, warmstart, linkdown, linkup) và (ii) các
bẫy dành riêng cho ứng dụng (X .25 khởi động lại và đặt lại X.25).
8.3.6 Kiểm tra giao diện người dùng đồ họa
Trong các ứng dụng phần mềm hiện đại, người dùng truy cập các
chức năng thông qua GUI. Người dùng công nghệ máy khách-máy
chủ cảm thấy thuận tiện khi sử dụng các ứng dụng dựa trên GUI. Các
bài kiểm tra GUI được thiết kế để xác minh giao diện cho người dùng
ứng dụng. Các bài kiểm tra này xác minh các thành phần (đối tượng)
khác nhau như biểu tượng, thanh menu, hộp thoại, thanh cuộn, hộp
danh sách và nút radio. Cần kiểm tra tính dễ sử dụng (khả năng sử
dụng) của thiết kế GUI và báo cáo đầu ra từ quan điểm của người
dùng hệ thống thực tế. Tính hữu ích của trợ giúp trực tuyến, thông
báo lỗi, hướng dẫn và hướng dẫn sử dụng đã được xác minh. GUI có
thể được sử dụng để kiểm tra chức năng đằng sau giao diện, chẳng
hạn như phản hồi chính xác đối với các truy vấn cơ sở dữ liệu. GUI
cần phải tương thích, như đã thảo luận trong Phần 8.5 và nhất quán
trên các hệ điều hành, môi trường khác nhau và các đầu vào điều
khiển bằng chuột và bàn phím.
Tương tự như thử nghiệm GUI, một nhánh thử nghiệm khác, được
gọi là thử nghiệm khả năng sử dụng, đã phát triển trong vài năm qua.
Các đặc tính khả dụng có thể được kiểm tra bao gồm:
Khả năng tiếp cận: Người dùng có thể vào, điều hướng và thoát
tương đối dễ dàng không?
đáp ứng: Người dùng có thể làm những gì họ muốn và khi họ muốn
theo cách rõ ràng không? Nó bao gồm các yếu tố công thái học như
màu sắc, hình dạng, âm thanh và kích thước phông chữ.
Hiệu quả: Người dùng có thể làm những gì họ muốn với số bước và
thời gian tối thiểu không?
hiểu: Người dùng có hiểu cấu trúc sản phẩm với một lượng nỗ lực tối
thiểu không?
8.3.7 Kiểm tra bảo mật
Kiểm tra bảo mật được thiết kế để xác minh rằng hệ thống đáp ứng
các yêu cầu bảo mật: tính bảo mật, tính toàn vẹn và tính khả dụng.
Tính bảo mật là yêu cầu dữ liệu và các quy trình được bảo vệ khỏi tiết
lộ trái phép. Tính toàn vẹn là yêu cầu dữ liệu và quy trình được bảo
vệ khỏi sự sửa đổi trái phép. Tính khả dụng là yêu cầu dữ liệu và quy
trình được bảo vệ khỏi sự từ chối dịch vụ đối với người dùng được ủy
quyền. Chỉ riêng cách tiếp cận kiểm tra các yêu cầu bảo mật đã chứng
minh liệu các yêu cầu bảo mật đã nêu đã được thỏa mãn hay chưa bất
kể các yêu cầu đó có đầy đủ hay không. Hầu hết các đặc tả phần mềm
không bao gồm các yêu cầu tiêu cực và ràng buộc. Kiểm thử bảo mật
nên bao gồm các tình huống tiêu cực như sử dụng sai và lạm dụng hệ
thống phần mềm. Mục tiêu của thử nghiệm bảo mật là để chứng minh
[3] những điều sau:
Phần mềm hoạt động an toàn và nhất quán trong mọi điều kiện — cả
mong đợi và không mong đợi.
Nếu phần mềm bị lỗi, lỗi không khiến phần mềm, dữ liệu hoặc tài
nguyên của nó bị tấn công.
Không thể xâm phạm hoặc khai thác các vùng mã và các chức năng
không hoạt động.
Các giao diện và tương tác giữa các thành phần ở cấp ứng dụng,
khuôn khổ / phần mềm trung gian và hệ điều hành được bảo mật nhất
quán. • Các cơ chế xử lý lỗi và ngoại lệ giải quyết tất cả các lỗi và lỗi
theo những cách không để phần mềm, tài nguyên, dữ liệu của nó hoặc
môi trường của nó dễ bị sửa đổi trái phép hoặc tấn công từ chối dịch
vụ.
Sự phổ biến của Internet và các công nghệ truyền thông dữ liệu
không dây đã tạo ra những mối đe dọa bảo mật kiểu mới, chẳng hạn
như truy cập trái phép vào mạng dữ liệu không dây, nghe trộm lưu
•
lượng dữ liệu được truyền và tấn công từ chối dịch vụ [4]. Ngay cả
trong một doanh nghiệp, những kẻ xâm nhập mạng cục bộ không dây
có thể hoạt động một cách bí mật vì chúng không cần kết nối vật lý
vào mạng [5]. Một số kỹ thuật mới đang được phát triển để chống lại
các loại mối đe dọa bảo mật này. Các thử nghiệm được thiết kế để
đảm bảo rằng các kỹ thuật này hoạt động — và đây là một nhiệm vụ
đầy thách thức. Các loại kiểm tra bảo mật hữu ích bao gồm:
Xác minh rằng chỉ những quyền truy cập có thẩm quyền vào hệ thống
mới được phép. Điều này có thể bao gồm xác thực ID người dùng và
mật khẩu và xác minh thời hạn sử dụng của mật khẩu.
Xác minh tính đúng đắn của cả thuật toán mã hóa và giải mã cho các
hệ thống mà dữ liệu / thông điệp được mã hóa.
Xác minh rằng việc đọc bất hợp pháp các tệp mà thủ phạm không
được phép, không được phép.
Đảm bảo rằng bộ kiểm tra vi rút ngăn chặn hoặc hạn chế sự xâm nhập
của vi rút vào hệ thống.
Đảm bảo rằng hệ thống luôn sẵn sàng cho người dùng được ủy quyền
khi xảy ra cuộc tấn công zero-day.
Cố gắng xác định bất kỳ “cửa hậu” nào trong hệ thống thường được
các nhà phát triển phần mềm để ngỏ. Tràn bộ đệm là lỗ hổng phổ biến
nhất trong mã có thể bị lợi dụng để xâm phạm hệ thống. Cố gắng đột
nhập vào hệ thống bằng cách khai thác các cửa hậu.
Xác minh các giao thức khác nhau được sử dụng bởi máy chủ xác
thực, chẳng hạn như Dịch vụ Người dùng Quay số Xác thực Từ xa
(RADIUS), Giao thức Truy cập Thư mục Nhẹ (LDAP) và Trình quản
lý Mạng LAN NT (NTLM). • Xác minh các giao thức an toàn cho
giao tiếp máy khách-máy chủ, chẳng hạn như Lớp cổng bảo mật
(SSL). SSL cung cấp một kênh bảo mật giữa máy khách và máy chủ
chọn sử dụng giao thức cho các phiên web. Giao thức phục vụ hai
chức năng: (i) xác thực máy chủ web và / hoặc máy khách và (ii) mã
hóa kênh truyền thông.
Xác minh giao thức IPSec. Không giống như SSL, cung cấp các dịch
vụ ở lớp 4 và bảo mật thông tin liên lạc giữa hai ứng dụng, IPSec
hoạt động ở lớp 3 và bảo vệ các giao tiếp diễn ra trên mạng. • Xác
minh các giao thức bảo mật không dây khác nhau, chẳng hạn như
Giao thức xác thực mở rộng (EAP), Giao thức bảo mật lớp truyền tải
(TLS), Giao thức bảo mật lớp truyền tải đường hầm (TTLS) và Giao
thức xác thực mở rộng được bảo vệ (PEAP).
8.3.8 Kiểm tra tính năng
Kiểm tra tính năng được thiết kế để xác minh bất kỳ chức năng bổ
sung nào được xác định trong các thông số kỹ thuật yêu cầu nhưng
không được đề cập trong các loại trên. Ví dụ về các thử nghiệm đó là
chuyển đổi dữ liệu và thử nghiệm chức năng chéo. Kiểm thử chuyển
đổi dữ liệu là kiểm tra các chương trình hoặc quy trình được sử dụng
để chuyển đổi dữ liệu từ một hệ thống hiện có sang một hệ thống thay
thế. Một ví dụ là thử nghiệm công cụ di chuyển chuyển đổi cơ sở dữ
liệu Microsoft Access sang định dạng MySQL. Thử nghiệm chức
năng chéo cung cấp các thử nghiệm bổ sung về sự phụ thuộc lẫn nhau
giữa các chức năng. Ví dụ, việc xác minh các tương tác giữa các NE
và hệ thống quản lý phần tử trong mạng dữ liệu không dây 1xEV-
DO, như được minh họa sau trong Hình 8.5, được coi là kiểm tra
chức năng chéo.
8.4.KIỂM TRA KHÔNG CẦN THIẾT
Mạnh mẽ có nghĩa là mức độ nhạy cảm của một hệ thống đối với đầu
vào sai và những thay đổi trong môi trường hoạt động của nó. Các
thử nghiệm trong danh mục này được thiết kế để xác minh cách hệ
thống hoạt động trong các tình huống lỗi và trong môi trường hoạt
động đã thay đổi. Mục đích là cố tình phá vỡ hệ thống, không phải là
mục đích tự thân mà là một phương tiện để tìm ra lỗi. Rất khó để
kiểm tra mọi sự kết hợp của các trạng thái hoạt động khác nhau của
hệ thống hoặc hành vi không mong muốn của môi trường. Do đó, một
số lượng thử nghiệm hợp lý được chọn từ mỗi nhóm được minh họa
trong Hình 8.4 và được thảo luận dưới đây.
•
Boundary value
Power cycling
Types of On-line insertion and

robustness tests removal
High availability
Degraded node
Hình 8.4 Các loại kiểm tra độ bền.

8.4.1 Kiểm tra giá trị ranh giới
Kiểm tra giá trị biên được thiết kế để bao gồm các điều kiện biên, các
giá trị đặc biệt và các giá trị mặc định của hệ thống. Các bài kiểm tra
bao gồm việc cung cấp dữ liệu đầu vào không hợp lệ cho hệ thống và
quan sát cách hệ thống phản ứng với dữ liệu đầu vào không hợp lệ.
Hệ thống sẽ phản hồi bằng một thông báo lỗi hoặc bắt đầu một quy
trình xử lý lỗi. Cần xác minh rằng hệ thống xử lý các giá trị ranh giới
(thấp hơn hoặc cao hơn các giá trị hợp lệ) cho một tập hợp con các
thuộc tính có thể định cấu hình. Ví dụ về các thử nghiệm như vậy đối
với giao thức SNMP như sau:
Xác minh rằng một phản hồi lỗi sai sai được tạo ra khi Set nguyên
thủy được sử dụng để cung cấp một biến có kiểu không khớp với kiểu
được xác định trong MIB.
Xác minh rằng phản hồi lỗi sai sai_value được tạo ra khi Set nguyên
thủy được sử dụng để định cấu hình danh sách varbind với một trong
các varbind được đặt thành giá trị không hợp lệ. Ví dụ: nếu varbind
có thể có các giá trị từ tập 0,1,2,3, thì giá trị đầu vào có thể là - 1 để
tạo ra phản hồi giá trị sai. • Xác minh rằng một phản hồi lỗi too_big
được tạo ra khi Set nguyên thủy được sử dụng để định cấu hình danh
sách 33 varbinds. Điều này là do Set nguyên thủy chấp nhận 32
varbinds cùng một lúc.
Xác minh rằng phản hồi lỗi not_wbroken được tạo ra khi Set nguyên
thủy được sử dụng để định cấu hình một biến như được định nghĩa
293
•
trong MIB. • Giả sử rằng giao thức SNMP có thể hỗ trợ tối đa 1024
cộng đồng, hãy xác minh rằng không thể tạo cộng đồng thứ 1025.
Ví dụ về các bài kiểm tra độ bền cho mạng 1xEV-DO, như trong
Hình 8.5, như sau:
Giả sử rằng EMS có thể hỗ trợ tới 300 NE, hãy xác minh rằng EMS
không thể hỗ trợ NE thứ 301. Kiểm tra thông báo lỗi từ EMS khi
người dùng cố gắng định cấu hình phần tử mạng thứ 301.
E MS AAA
RN
RNC
IP IP
B ackhaul PDSN core
N etwork network
AT Billing
RADIUS
Hình 8.5 Mạng truy nhập vô tuyến 1xEV-DO điển hình. (Được
sự cho phép của Airvana, Inc.)
Giả sử rằng RNC có thể hỗ trợ 160.000 phiên đồng thời, hãy xác
minh rằng phiên thứ 160.001 không thể được thiết lập trên RNC.
Kiểm tra thông báo lỗi từ EMS khi người dùng cố gắng thiết lập
phiên thứ 160.001.
Giả sử rằng một trạm thu phát gốc (BTS) có thể hỗ trợ tối đa 93
người dùng đồng thời, hãy xác minh rằng người dùng thứ 94 không
thể kết nối với BTS.
8.4.2 Thử nghiệm đi xe đạp điện
Kiểm tra chu trình điện được thực hiện để đảm bảo rằng, khi có sự cố
nguồn trong môi trường triển khai, hệ thống có thể khôi phục sau sự
cố để trở lại hoạt động bình thường sau khi có điện trở lại. Ví dụ: xác
minh rằng kiểm tra khởi động thành công mỗi khi nó được thực thi
trong quá trình chạy điện.
8.4.3 Thử nghiệm Chèn và Loại bỏ Trực tuyến
Các thử nghiệm chèn và tháo trực tuyến (OIR) được thiết kế để đảm
bảo rằng việc chèn và tháo các mô-đun trực tuyến, phát sinh trong cả
•
hoạt động không tải và tải nặng, được xử lý và phục hồi một cách
duyên dáng. Sau đó hệ thống trở lại hoạt động bình thường sau khi
tình trạng lỗi được loại bỏ. Mục tiêu chính là đảm bảo rằng hệ thống
phục hồi từ sự kiện OIR mà không cần khởi động lại hoặc gặp sự cố
bất kỳ thành phần nào khác. Kiểm tra OIR được thực hiện để đảm
bảo hệ thống hoạt động không có lỗi trong khi mô-đun bị lỗi được
thay thế. Ví dụ, trong khi thay thế một thẻ Ethernet, hệ thống sẽ
không gặp sự cố.
8.4.4 Kiểm tra tính khả dụng cao
Các bài kiểm tra tính sẵn sàng cao được thiết kế để xác minh tính dự
phòng của các mô-đun riêng lẻ, bao gồm cả phần mềm điều khiển các
mô-đun này. Mục đích là để xác minh rằng
Hệ thống phục hồi nhanh chóng và nhanh chóng sau các lỗi phần
cứng và phần mềm mà không ảnh hưởng xấu đến hoạt động của hệ
thống. Khái niệm về tính sẵn sàng cao còn được gọi là khả năng chịu
lỗi. Tính sẵn sàng cao được thực hiện bằng các phương pháp chủ
động để tối đa hóa thời gian hoạt động của dịch vụ và giảm thiểu thời
gian ngừng hoạt động. Một mô-đun hoạt động ở chế độ hoạt động
trong khi một mô-đun khác ở chế độ chờ để đạt được 1 + 1 dự phòng.
Đối với chế độ hoạt động này, các thử nghiệm được thiết kế để xác
minh những điều sau:
Mô-đun dự phòng tạo ra một sự kiện OIR, tức là được hoán đổi nóng,
mà không ảnh hưởng đến hoạt động bình thường của hệ thống.
Thời gian khôi phục không vượt quá giới hạn được xác định trước
trong khi hệ thống đang hoạt động. Thời gian khôi phục là thời gian
cần thiết để mô-đun hoạt động trở thành mô-đun dự phòng và mô-đun
dự phòng trở thành hoạt động. • Máy chủ có thể tự động chuyển từ
chế độ đang hoạt động sang chế độ chờ trong trường hợp xảy ra sự
kiện lỗi. Một lỗi được cho là xảy ra khi một máy chủ dự phòng tiếp
quản khối lượng công việc của một máy chủ đang hoạt động.
Các thử nghiệm có thể được thiết kế để xác minh rằng không xảy ra
sự cố mà không có bất kỳ sự cố nào có thể quan sát được. Một thất
bại mà không có một thất bại có thể quan sát được được gọi là thất
bại thầm lặng. Điều này chỉ có thể được quan sát thấy trong các thử
295
•
nghiệm tải và độ ổn định được mô tả trong Phần 8.9. Bất cứ khi nào
xảy ra sự cố im lặng, một phân tích nhân quả phải được tiến hành để
xác định nguyên nhân của nó.
8.4.5 Kiểm tra nút được phân cấp
Các bài kiểm tra nút xuống cấp (còn được gọi là ngăn chặn sự cố) xác
minh hoạt động của hệ thống sau khi một phần của hệ thống trở nên
không hoạt động. Đây là một bài kiểm tra hữu ích cho tất cả các ứng
dụng quan trọng. Ví dụ về các bài kiểm tra nút xuống cấp như sau: •
Cắt một trong bốn kết nối vật lý T1 từ một bộ định tuyến đến một bộ
định tuyến khác và xác minh rằng cân bằng tải xảy ra giữa các phần
còn lại của ba kết nối vật lý T1. Xác nhận rằng các gói được phân
phối đồng đều giữa ba kết nối T1 đang hoạt động.
• Tắt cổng chính của bộ định tuyến và xác minh rằng lưu lượng tin
nhắn đi qua các cổng thay thế mà không bị gián đoạn dịch vụ rõ ràng
đối với người dùng cuối. Tiếp theo, kích hoạt lại cổng chính và xác
minh rằng bộ định tuyến trở lại hoạt động bình thường.
Ví dụ về Mạng dữ liệu không dây 1xEV-DO Đa truy cập phân chia
theo mã (CDMA) 2000 1xEV-DO (tiến hóa một lần, chỉ dữ liệu) là
công nghệ tiêu chuẩn hóa để cung cấp tốc độ dữ liệu cao ở giao diện
không khí giữa thiết bị đầu cuối truy cập (AT) và một trạm thu phát
gốc (BTS), còn được gọi là nút vô tuyến (RN) [6–8]. 1xEV-DO
Revision 0 cung cấp tốc độ dữ liệu cao nhất là 2,54 Mbits / s trên liên
kết thuận (từ BTS đến AT) chỉ sử dụng 1,25MHz độ rộng phổ và tốc
độ dữ liệu đỉnh là 153,6 kbits / s trên liên kết ngược. Chúng tôi cho
thấy một kiến trúc để kết nối tất cả các trạm BTS với Internet (mạng
lõi IP) trong
Hình 8.5. Trong kiến trúc này, bộ điều khiển trạm gốc (BSC), còn
được gọi là bộ điều khiển mạng vô tuyến (RNC), không cần được kết
nối trực tiếp bằng các liên kết vật lý, chuyên dụng với một tập hợp
các trạm BTS. Thay vào đó, các BTS được kết nối với RNC thông
qua mạng đường ngược IP. Việc kết nối như vậy dẫn đến việc điều
khiển linh hoạt các BTS bởi các RNC. Các RNC được kết nối với
Internet (mạng lõi IP) thông qua một hoặc nhiều nút phục vụ dữ liệu
gói (PDSN). Cuối cùng, EMS cho phép nhà khai thác quản lý mạng
1xEV-DO.
•
Các AT (máy tính xách tay, PDA, điện thoại di động) triển khai phía
người dùng cuối của 1xEV-DO và TCP / IP. Các AT giao tiếp với
RN qua đường hàng không 1xEV-DO. Các RN là các thành phần kết
thúc đường hàng không đến / từ các AT. Các chức năng được thực
hiện bởi RN là (i) điều khiển và xử lý đường hàng không vật lý, (ii)
xử lý lớp điều khiển truy cập phương tiện 1xEV-DO (MAC) và (iii)
giao tiếp thông qua mạng back-haul tới RNC. Ngoài ra, RN kết hợp
với RNC thực hiện chức năng di động chuyển giao nhẹ nhàng hơn
của giao thức 1xEV-DO, trong đó AT được giao tiếp với nhiều ăng-
ten khu vực của cùng một RN.
RNC là một thực thể kết thúc các thành phần lớp cao hơn của bộ giao
thức 1xEV-DO. RNC có các giao diện logic với RN, máy chủ xác
thực, ủy quyền và kế toán (AAA), các RNC khác và PDSN. RNC
chấm dứt các tương tác báo hiệu 1xEV-DO từ các AT và xử lý lưu
lượng người dùng để chuyển nó đến PDSN. Nó quản lý các tài
nguyên vô tuyến trên tất cả các RN trong miền của nó và thực hiện
quản lý tính di động dưới hình thức xử lý nhẹ nhàng và mềm mại.
Máy chủ AAA là thiết bị tính toán cấp nhà cung cấp dịch vụ chạy
giao thức RADIUS và có giao diện với cơ sở dữ liệu. Các máy chủ
này có thể được cấu hình cho hai chức năng AAA, cụ thể là AAA
mạng truy cập và mạng lõi AAA. Mạng truy nhập AAA được kết nối
với RNC, thực hiện chức năng xác thực đầu cuối. Mạng lõi AAA
được kết nối với PDSN, mạng này thực hiện xác thực người dùng ở
cấp IP. PDSN là một bộ định tuyến chuyên dụng thực hiện IP và IP di
động. PDSN có thể được triển khai như một thiết bị duy nhất, có tính
khả dụng cao hoặc nhiều thiết bị được nhóm lại với nhau để tạo thành
một thiết bị có tính khả dụng cao. PDSN là cạnh của mạng IP lõi liên
quan đến AT, có nghĩa là, điểm mà (i) lưu lượng Giao thức điểm-
điểm (PPP) của AT được kết thúc, (ii) người dùng được xác thực, và
(iii) các tùy chọn dịch vụ IP được xác định. Mạng IP lõi về bản chất
là một mạng gồm các bộ định tuyến. Máy chủ EMS là một hệ thống
kiểm soát trực tiếp các NE. Nó chịu trách nhiệm xử lý lỗi, cấu hình
mạng và quản lý thống kê của các giao diện mạng. Máy chủ EMS
giao tiếp với các NE thông qua TCP / IP. Máy chủ EMS được truy
cập thông qua một máy khách - chứ không phải trực tiếp - bởi nhân
297
•
viên quản lý mạng của một nhà khai thác mạng không dây. Máy
khách EMS là một máy trạm mà từ đó nhà điều hành mạng quản lý
mạng truy cập vô tuyến.
8.5 KIỂM TRA KHẢ NĂNG HỢP TÁC
Trong danh mục này, các bài kiểm tra được thiết kế để xác minh khả
năng hệ thống tương tác với các sản phẩm của bên thứ ba. Kiểm tra
khả năng tương tác thường kết hợp các phần tử mạng khác nhau trong
một môi trường thử nghiệm để đảm bảo rằng chúng hoạt động cùng
nhau. Nói cách khác, các bài kiểm tra được thiết kế để đảm bảo rằng
phần mềm có thể được kết nối với các
8.6 KIỂM TRA HIỆU SUẤT
hệ thống và vận hành. Trong nhiều trường hợp, trong quá trình kiểm
tra khả năng tương tác, người dùng có thể yêu cầu các thiết bị phần
cứng có thể hoán đổi cho nhau, có thể tháo rời hoặc có thể cấu hình
lại. Thông thường, một hệ thống sẽ có một tập hợp các lệnh hoặc
menu cho phép người dùng thực hiện các thay đổi cấu hình. Các hoạt
động cấu hình lại trong quá trình kiểm tra khả năng tương tác được
gọi là kiểm tra cấu hình [9]. Một loại kiểm tra khả năng tương tác
khác được gọi là kiểm tra khả năng tương thích (ngược). Kiểm tra
khả năng tương thích xác minh rằng hệ thống hoạt động theo cùng
một cách trên các nền tảng, hệ điều hành và hệ thống quản lý cơ sở
dữ liệu khác nhau. Kiểm tra khả năng tương thích ngược xác minh
rằng bản dựng phần mềm hiện tại hoạt động hoàn hảo với phiên bản
cũ hơn của nền tảng. Ví dụ, chúng ta hãy xem xét một mạng truy
nhập vô tuyến 1xEV-DO như trong Hình 8.5. Trong trường hợp này,
các bài kiểm tra được thiết kế để đảm bảo khả năng tương tác của
RNC với các sản phẩm sau từ các nhà cung cấp khác nhau: (i) PDSN,
(ii) PDA với thẻ 1xEV-DO, (iii) máy chủ AAA, (iv) PC với 1xEV-
Thẻ DO, (v) máy tính xách tay có thẻ 1xEV-DO, bộ định tuyến (vi)
từ các nhà cung cấp khác nhau, (vii) BTS hoặc RNC, và (viii).
8.6 KIỂM TRA HIỆU SUẤT
Kiểm tra hiệu suất được thiết kế để xác định hiệu suất của hệ thống
thực tế so với dự kiến. Các chỉ số hiệu suất cần được đo lường khác
nhau giữa các ứng dụng. Một ví dụ về hiệu suất dự kiến là: Thời gian
•
phản hồi phải dưới 1 phần nghìn giây 90% thời gian trong một ứng
dụng thuộc loại "push-to-talk". Một ví dụ khác về hiệu suất mong đợi
là: Một giao dịch trong hệ thống trực tuyến yêu cầu phản hồi dưới 1
giây 90% thời gian. Một trong những mục tiêu của kiểm tra hiệu suất
bộ định tuyến là xác định việc sử dụng tài nguyên hệ thống, để có tốc
độ thông lượng tổng hợp tối đa xem xét các gói không thả. Trong
danh mục này, các bài kiểm tra được thiết kế để xác minh thời gian
phản hồi, thời gian thực thi, thông lượng, sử dụng tài nguyên và tốc
độ lưu lượng.
Đối với các bài kiểm tra hiệu suất, người ta cần phải hiểu rõ về dữ
liệu cụ thể sẽ được thu thập để đánh giá các chỉ số hiệu suất. Ví dụ:
nếu mục tiêu là đánh giá thời gian phản hồi, thì người ta cần nắm bắt
(i) thời gian phản hồi đầu cuối (như người dùng bên ngoài nhìn thấy),
(ii) thời gian CPU, (iii) thời gian kết nối mạng, ( iv) thời gian truy cập
cơ sở dữ liệu, (v) thời gian kết nối mạng và (vi) thời gian chờ.
Một số ví dụ về các mục tiêu kiểm tra hiệu suất cho máy chủ EMS
như sau:
Ghi lại việc sử dụng CPU và bộ nhớ của máy chủ EMS khi các NEs
tạo ra 5, 10, 15, 20 và 25 bẫy mỗi giây. Thử nghiệm này sẽ xác nhận
khả năng máy chủ EMS nhận và xử lý số lượng bẫy đó trong một
giây.
Ghi lại việc sử dụng CPU và bộ nhớ của máy chủ EMS khi các tệp
nhật ký có kích thước khác nhau, chẳng hạn như 100, 150, 200, 250
và 300kb, được chuyển từ NE đến máy chủ EMS 15 phút một lần.
Một số ví dụ về các mục tiêu kiểm tra hiệu suất của SNMP nguyên
thủy như sau:
Tính toán thời gian phản hồi của Lấy nguyên thủy cho một varbind từ
MIB tiêu chuẩn hoặc MIB doanh nghiệp.
Tính toán thời gian phản hồi của bản gốc GetNext cho một varbind từ
MIB tiêu chuẩn hoặc MIB doanh nghiệp. • Tính toán thời gian phản
hồi của bản gốc GetBulk cho một varbind duy nhất từ MIB tiêu
chuẩn hoặc MIB doanh nghiệp.
Tính toán thời gian phản hồi của Set nguyên thủy cho một varbind từ
MIB tiêu chuẩn hoặc MIB doanh nghiệp.
299
•
Một số ví dụ về các mục tiêu kiểm tra hiệu suất của Bản sửa đổi
1xEV-DO 0 như sau:
Đo thông lượng liên kết chuyển tiếp BTS tối đa.
Đo thông lượng liên kết ngược BTS tối đa.
Đồng thời tạo ra dung lượng dữ liệu liên kết ngược và chuyển tiếp
BTS tốc độ tối đa.
Tạo số lượng thiết lập phiên được phép tối đa mỗi giờ.
Đo độ trễ thiết lập kết nối do AT khởi tạo.
Đo thông lượng liên kết chuyển tiếp BTS tối đa trên mỗi nhà cung
cấp dịch vụ khu vực cho 16 người dùng trong mô hình di động 3 km /
h. • Đo thông lượng liên kết chuyển tiếp BTS tối đa trên mỗi sóng
mang khu vực cho 16 người dùng trong mô hình di động 30 km / h.
Kết quả của việc thực hiện được đánh giá về khả năng chấp nhận của
chúng. Nếu chỉ số hiệu suất không đạt yêu cầu, thì các hành động sẽ
được thực hiện để cải thiện chỉ số đó. Cải thiện hiệu suất có thể đạt
được bằng cách viết lại mã, phân bổ nhiều tài nguyên hơn và thiết kế
lại hệ thống.
8.7 KIỂM TRA KHẢ NĂNG KỸ THUẬT
Tất cả các đồ tạo tác nhân tạo đều có giới hạn kỹ thuật. Ví dụ: ô tô có
thể di chuyển với tốc độ tối đa nhất định trong điều kiện đường xá tốt
nhất, tổng đài điện thoại có thể xử lý số lượng cuộc gọi tối đa nhất
định tại bất kỳ thời điểm nào, bộ định tuyến có số lượng giao diện tối
đa nhất định, v.v. Trong nhóm này, các bài kiểm tra được thiết kế để
xác minh rằng hệ thống có thể mở rộng đến các giới hạn kỹ thuật của
nó. Một hệ thống có thể hoạt động trong một trường hợp sử dụng hạn
chế nhưng có thể không mở rộng quy mô. Thời gian chạy của một hệ
thống có thể tăng theo cấp số nhân với nhu cầu và cuối cùng có thể bị
lỗi sau một giới hạn nhất định. Ý tưởng là để kiểm tra giới hạn của hệ
thống, nghĩa là, độ lớn của nhu cầu có thể được đặt trên hệ thống
trong khi vẫn tiếp tục đáp ứng các yêu cầu về độ trễ và thông lượng.
Một hệ thống hoạt động có thể chấp nhận được ở một cấp độ nhu cầu
có thể không mở rộng lên cấp độ khác. Kiểm tra tỷ lệ được tiến hành
để đảm bảo rằng thời gian phản hồi của hệ thống vẫn giữ nguyên
hoặc tăng một lượng nhỏ khi số lượng người dùng tăng lên. Các hệ
thống có thể mở rộng quy mô cho đến khi chúng đạt đến một hoặc
•
nhiều giới hạn kỹ thuật. Có ba nguyên nhân chính của những hạn chế
này:
Giới hạn lưu trữ dữ liệu — giới hạn về kích thước trường bộ đếm và
không gian đệm được phân bổ
8.8 KIỂM TRA CĂNG THNG
Giới hạn băng thông mạng — Tốc độ Ethernet 10Mbps và tốc độ
dòng thẻ T1 1,544Mbps
Giới hạn tốc độ — tốc độ CPU tính bằng megahertz
Phép ngoại suy thường được sử dụng để dự đoán giới hạn của khả
năng mở rộng. Hệ thống được thử nghiệm trên một loạt nền tảng hoặc
mạng ngày càng lớn hơn hoặc với một loạt khối lượng công việc
ngày càng lớn hơn. Việc sử dụng bộ nhớ và CPU được đo và vẽ biểu
đồ dựa trên kích thước của mạng hoặc kích thước của tải. Xu hướng
này được ngoại suy từ hoạt động quy mô lớn có thể đo lường và được
biết đến. Ví dụ, đối với một hệ thống giao dịch cơ sở dữ liệu, tính
toán hiệu suất hệ thống, nghĩa là sử dụng CPU và sử dụng bộ nhớ cho
100, 200, 400 và 800 giao dịch mỗi giây, sau đó vẽ biểu đồ về số
lượng giao dịch dựa trên việc sử dụng CPU và bộ nhớ. Ngoại suy các
kết quả đo được thành 20.0000 giao dịch. Hạn chế trong kỹ thuật này
là đường xu hướng có thể không chính xác. Hành vi hệ thống có thể
không suy giảm dần dần và duyên dáng khi các tham số được mở
rộng. Ví dụ về các bài kiểm tra khả năng mở rộng cho mạng 1xEV-
DO như sau: • Xác minh rằng máy chủ EMS có thể hỗ trợ số lượng
NE tối đa, chẳng hạn, 300, mà không có bất kỳ sự suy giảm nào về
hiệu suất EMS.
Xác minh rằng số lượng BTS tối đa, chẳng hạn, 200, có thể được đưa
vào một BSC.
Xác minh rằng số lượng phiên EV-DO tối đa, chẳng hạn, 16.000, có
thể được thiết lập trên một RNC. • Xác minh rằng số lượng kết nối
EV-DO tối đa, chẳng hạn, 18.400, có thể được thiết lập trên một
RNC.
Xác minh rằng công suất BTS tối đa cho cấu hình ba khu vực là 93
người dùng trên mỗi BTS.
301
•
Xác minh tỷ lệ chuyển cuộc gọi tối đa mềm hơn với số lượng cuộc
gọi giảm có thể chấp nhận được trên mỗi BTS. Lặp lại quy trình mỗi
giờ trong 24 giờ.
Xác minh tỷ lệ chuyển cuộc gọi mềm tối đa mà không bị rớt cuộc gọi
trên mỗi BTS. Lặp lại quy trình mỗi giờ trong 24 giờ.
8.8 KIỂM TRA CĂNG THNG
Mục tiêu của kiểm thử căng thẳng là để đánh giá và xác định hành vi
của một thành phần phần mềm trong khi tải được cung cấp vượt quá
khả năng thiết kế của nó. Hệ thống đang cố tình căng thẳng bằng cách
đẩy nó đến và vượt quá giới hạn quy định của nó. Các bài kiểm tra
căng thẳng bao gồm sự tranh chấp có chủ ý về nguồn lực khan hiếm
và kiểm tra sự không tương thích. Nó đảm bảo rằng hệ thống có thể
hoạt động ở mức chấp nhận được trong các điều kiện trường hợp xấu
nhất dưới tải trọng cao nhất dự kiến. Nếu vượt quá giới hạn và hệ
thống không thành công, thì cơ chế khôi phục sẽ được gọi. Các bài
kiểm tra căng thẳng được nhắm mục tiêu để đưa ra các vấn đề liên
quan đến một hoặc nhiều điều sau đây:
Bộ nhớ bị rò rỉ
Phân bổ bộ đệm và khắc bộ nhớ
Một cách để thiết kế kiểm tra căng thẳng là áp đặt các giới hạn tối đa
cho tất cả các đặc tính hiệu suất của hệ thống cùng một lúc, chẳng
hạn như thời gian đáp ứng, tính khả dụng và ngưỡng thông lượng.
Điều này thực sự cung cấp tập hợp các điều kiện trong trường hợp
xấu nhất mà theo đó hệ thống vẫn được dự kiến sẽ hoạt động ở mức
chấp nhận được.
Cách tốt nhất để xác định tắc nghẽn của hệ thống là thực hiện kiểm
tra căng thẳng từ các vị trí khác nhau bên trong và bên ngoài hệ
thống. Ví dụ, kiểm tra riêng từng thành phần của hệ thống, bắt đầu
với các thành phần trong cùng trực tiếp đến lõi của hệ thống, tiến dần
ra bên ngoài và cuối cùng là kiểm tra từ các vị trí xa bên ngoài hệ
thống. Kiểm tra mỗi liên kết bao gồm việc đẩy nó đến khả năng chịu
tải đầy đủ của nó để xác định hoạt động chính xác. Sau khi tất cả các
thành phần riêng lẻ được kiểm tra vượt quá khả năng cao nhất của
chúng, hãy kiểm tra toàn bộ hệ thống bằng cách kiểm tra đồng thời tất
cả các liên kết đến hệ thống ở công suất cao nhất của chúng. Tải có
•
thể được cố ý và tăng dần cho đến khi cuối cùng hệ thống không thực
hiện được; khi hệ thống gặp sự cố, quan sát nguyên nhân và vị trí hư
hỏng. Thông tin này sẽ hữu ích trong việc thiết kế các phiên bản sau
của hệ thống; tính hữu ích nằm trong việc cải thiện tính mạnh mẽ của
hệ thống hoặc phát triển các quy trình cho kế hoạch khôi phục sau
thảm họa. Một số ví dụ về kiểm tra ứng suất của mạng 1xEV-DO như
sau:
Xác minh rằng việc thiết lập lặp đi lặp lại và chia nhỏ các phiên telnet
tối đa tới BSC và BTS được thực hiện trong 24 giờ không dẫn đến (i)
rò rỉ số lượng bộ đệm hoặc dung lượng bộ nhớ hoặc (ii) tăng đáng kể
mức độ phân mảnh của bộ nhớ khả dụng . Các thử nghiệm nên được
thực hiện đối với cả những giọt nước mắt nhẹ nhàng và đột ngột của
phiên telnet. • Nhấn mạnh hai giao diện Ethernet của trạm BTS bằng
cách gửi lưu lượng truy cập Internet trong 24 giờ và xác minh rằng
không có sự cố hoặc rò rỉ bộ nhớ nào xảy ra. • Nhấn mạnh bốn giao
diện T1 / E1 của BTS bằng cách gửi lưu lượng truy cập Internet trong
24 giờ và xác minh rằng không có sự cố hoặc rò rỉ bộ nhớ nào xảy ra.
Xác minh rằng việc thiết lập lặp đi lặp lại và chia nhỏ kết nối AT
thông qua BSC được thực thi trong 24 giờ không dẫn đến (i) rò rỉ số
lượng bộ đệm hoặc dung lượng bộ nhớ và (ii) tăng đáng kể mức độ
phân mảnh của bộ nhớ khả dụng. Các phiên vẫn được thiết lập trong
suốt thời gian của bài kiểm tra.
Xác minh rằng các quá trình xử lý mềm và mềm lặp đi lặp lại được
thực hiện trong 24 giờ không dẫn đến rò rỉ số lượng bộ đệm hoặc
dung lượng bộ nhớ và không làm tăng đáng kể mức độ phân mảnh
của bộ nhớ khả dụng. • Xác minh rằng việc thực hiện lặp lại tất cả các
lệnh CLI trong 24 giờ không dẫn đến rò rỉ số lượng bộ đệm hoặc
dung lượng bộ nhớ và không làm tăng đáng kể mức độ phân mảnh
của bộ nhớ khả dụng.
Ví dụ về các thử nghiệm căng thẳng của tác nhân SNMP như sau:
Xác minh rằng việc lặp đi lặp lại các MIB thông qua SNMP được
thực thi trong 24 giờ không dẫn đến rò rỉ số lượng bộ đệm hoặc dung
lượng bộ nhớ và không làm tăng đáng kể mức độ phân mảnh của bộ
nhớ khả dụng
303
•
8.9 KIỂM TRA TẢI VÀ ỔN ĐỊNH
Xác minh rằng tác nhân SNMP có thể phản hồi thành công yêu cầu
GetBulk tạo ra một PDU lớn, tốt nhất là kích thước tối đa, là 8 kbyte
trong mức sử dụng CPU sau: 0, 50 và 90%. • Xác minh rằng một tác
nhân SNMP có thể xử lý đồng thời nhiều yêu cầu GetNext và
GetBulk trong khoảng thời gian thử nghiệm 24 giờ với các mức sử
dụng CPU sau: 0, 50 và 90%.
Xác minh rằng tác nhân SNMP có thể xử lý nhiều yêu cầu Nhận có
chứa một số lượng lớn các véc-ni trong khoảng thời gian thử nghiệm
24 giờ với các mức sử dụng CPU sau: 0, 50 và 90%.
Xác minh rằng tác nhân SNMP có thể xử lý nhiều yêu cầu Đặt có
chứa một số lượng lớn các véc-ni trong khoảng thời gian thử nghiệm
24 giờ trong các mức sử dụng CPU sau: 0, 50 và 90%.
8.9 KIỂM TRA TẢI VÀ ỔN ĐỊNH
Các bài kiểm tra tải và độ ổn định được thiết kế để đảm bảo rằng hệ
thống duy trì ổn định trong thời gian dài dưới chế độ đầy tải. Một hệ
thống có thể hoạt động hoàn hảo khi được kiểm tra bởi một số người
kiểm tra cẩn thận, những người thực hiện nó theo cách đã định. Tuy
nhiên, khi một số lượng lớn người dùng được giới thiệu với các hệ
thống và ứng dụng không tương thích chạy trong nhiều tháng mà
không khởi động lại, một số vấn đề có thể xảy ra: (i) hệ thống chậm
lại, (ii) hệ thống gặp sự cố về chức năng, (iii) ) hệ thống không hoạt
động một cách âm thầm, và (iv) hệ thống bị treo hoàn toàn. Kiểm tra
tải và độ ổn định thường bao gồm việc thực hiện hệ thống với người
dùng ảo và đo lường hiệu suất để xác minh xem hệ thống có thể hỗ
trợ tải dự kiến hay không. Loại thử nghiệm này giúp người ta hiểu
các cách hệ thống sẽ hoạt động trong các tình huống thực tế. Với sự
hiểu biết như vậy, người ta có thể lường trước và thậm chí ngăn ngừa
các vấn đề liên quan đến tải. Thông thường, các cấu hình hoạt động
được sử dụng để hướng dẫn thử nghiệm tải và độ ổn định [10]. Ý
tưởng là kiểm tra hệ thống theo cách nó sẽ được sử dụng thực tế trên
thực địa. Khái niệm về hồ sơ hoạt động được thảo luận trong Chương
15 về độ tin cậy của phần mềm.
Ví dụ về các mục tiêu kiểm tra tải và độ ổn định cho máy chủ EMS
như sau:
•
Xác minh hiệu suất của máy chủ EMS trong quá trình thăm dò nhanh
số lượng nút tối đa, chẳng hạn, 300. Ghi lại thời gian để thăm dò
nhanh 300 nút. Theo dõi việc sử dụng CPU trong quá trình thăm dò
nhanh và xác minh rằng kết quả nằm trong phạm vi chấp nhận được.
Người đọc được nhắc nhở rằng tính năng thăm dò nhanh được sử
dụng để kiểm tra xem một nút có thể truy cập được hay không bằng
cách thực hiện ping trên nút đó bằng thao tác SNMP Get.
Xác minh hiệu suất EMS trong quá trình thăm dò đầy đủ số lượng nút
tối đa, chẳng hạn, 300. Ghi lại thời gian để thăm dò đầy đủ 300 nút.
Theo dõi việc sử dụng CPU trong suốt quá trình thăm dò đầy đủ và
xác minh rằng kết quả nằm trong phạm vi chấp nhận được. Toàn bộ
thăm dò được sử dụng để kiểm tra trạng thái và bất kỳ thay đổi cấu
hình nào của các nút do máy chủ quản lý.
Xác minh hành vi của máy chủ EMS trong cơn bão bẫy SNMP. Tạo
bốn bẫy mỗi giây từ mỗi nút trong số 300 nút. Giám sát việc sử dụng
CPU trong quá trình xử lý bẫy và xác minh rằng kết quả nằm trong
phạm vi chấp nhận được.
Xác minh khả năng của máy chủ EMS để thực hiện tải xuống phần
mềm với số lượng nút tối đa, chẳng hạn, 300. Giám sát việc sử dụng
CPU trong quá trình tải xuống phần mềm và xác minh rằng kết quả
nằm trong phạm vi chấp nhận được. • Xác minh hiệu suất của máy
chủ EMS trong quá trình truyền tệp nhật ký về số lượng nút tối đa.
Giám sát việc sử dụng CPU trong quá trình truyền nhật ký và xác
minh rằng kết quả nằm trong phạm vi chấp nhận được.
Trong thử nghiệm tải và độ ổn định, mục tiêu là đảm bảo rằng hệ
thống có thể hoạt động trên diện rộng trong vài tháng, trong khi trong
thử nghiệm căng thẳng, mục tiêu là phá vỡ hệ thống do quá tải để
quan sát các vị trí và nguyên nhân hư hỏng.
8.10 KIỂM TRA ĐỘ TIN CẬY
Các bài kiểm tra độ tin cậy được thiết kế để đo khả năng duy trì hoạt
động của hệ thống trong thời gian dài. Độ tin cậy của một hệ thống
thường được biểu thị bằng thời gian trung bình để thất bại (MTTF).
Khi chúng tôi kiểm tra phần mềm và chuyển qua giai đoạn kiểm tra
hệ thống, chúng tôi quan sát thấy các lỗi và cố gắng loại bỏ các khiếm
305
•
khuyết và tiếp tục kiểm tra. Khi điều này tiến triển, chúng tôi ghi lại
khoảng thời gian giữa các lần thất bại liên tiếp. Gọi các khoảng thời
gian liên tiếp này được ký hiệu là t 1 , t 2 , ... , t i . Giá trị trung bình của
tất cả các khoảng thời gian thứ i được gọi là MTTF. Sau khi quan sát
thấy lỗi, các nhà phát triển sẽ phân tích và sửa chữa các lỗi, điều này
tiêu tốn một khoảng thời gian — chúng ta hãy gọi khoảng thời gian
này là thời gian sửa chữa. Trung bình của tất cả các lần sửa chữa
được gọi là thời gian trung bình để sửa chữa (MTTR). Bây giờ chúng
ta có thể tính toán một giá trị được gọi là thời gian trung bình giữa
các lần hỏng hóc (MTBF) là MTBF = MTTF + MTTR. Kỹ thuật
kiểm tra ngẫu nhiên được thảo luận trong Chương 9 được sử dụng để
đo độ tin cậy. Mô hình hóa và kiểm tra độ tin cậy của phần mềm
được thảo luận chi tiết trong Chương 15.
8.11 KIỂM TRA ĐỊA LÍ
Trong danh mục này, các bài kiểm tra mới không được thiết kế. Thay
vào đó, các trường hợp thử nghiệm được chọn từ nhóm hiện có và
được thực thi để đảm bảo rằng không có gì bị hỏng trong phiên bản
mới của phần mềm. Ý tưởng chính trong kiểm thử hồi quy là xác
minh rằng không có khiếm khuyết nào được đưa vào phần không thay
đổi của hệ thống do những thay đổi được thực hiện ở những nơi khác
trong hệ thống. Trong quá trình thử nghiệm hệ thống, nhiều khiếm
khuyết được tiết lộ và mã được sửa đổi để khắc phục những khiếm
khuyết đó. Kết quả của việc sửa đổi mã, một trong bốn trường hợp
khác nhau có thể xảy ra cho mỗi lần sửa chữa [11]:
Lỗi được báo cáo đã được sửa.
Lỗi được báo cáo không thể được sửa chữa mặc dù đã cố gắng.
8.12 KIỂM TRA TÀI LIỆU
Lỗi được báo cáo đã được sửa, nhưng một số thứ đã từng hoạt động
trước đây đã bị lỗi.
Lỗi được báo cáo không thể được sửa chữa mặc dù đã cố gắng và
một cái gì đó đã từng hoạt động trước đây đã thất bại.
Với bốn khả năng ở trên, có vẻ dễ dàng thực thi lại mọi trường hợp
thử nghiệm từ phiên bản n - 1 đến phiên bản n trước khi thử nghiệm
bất kỳ điều gì mới. Việc kiểm tra toàn bộ hệ thống như vậy có thể rất
tốn kém. Hơn nữa, các phiên bản phần mềm mới thường có nhiều
•
chức năng mới ngoài các bản sửa lỗi. Do đó, các thử nghiệm hồi quy
sẽ mất nhiều thời gian so với việc thử nghiệm mã mới. Kiểm thử hồi
quy là một nhiệm vụ tốn kém; một tập hợp con các trường hợp thử
nghiệm được lựa chọn cẩn thận từ bộ thử nghiệm hiện có để (i) tối đa
hóa khả năng phát hiện ra các khiếm khuyết mới và (ii) giảm chi phí
thử nghiệm. Các phương pháp lựa chọn thử nghiệm để kiểm tra hồi
quy được thảo luận trong Chương 13.
8.12 KIỂM TRA TÀI LIỆU
Kiểm tra tài liệu có nghĩa là xác minh tính chính xác kỹ thuật và khả
năng đọc của hướng dẫn sử dụng, bao gồm các hướng dẫn và trợ giúp
trực tuyến. Kiểm tra tài liệu được thực hiện ở ba cấp độ như được giải
thích trong phần sau:
Đọc kiểm tra: Trong kiểm tra này, tài liệu được xem xét về độ rõ
ràng, tổ chức, quy trình và độ chính xác mà không cần thực hiện các
hướng dẫn được lập thành văn bản trên hệ thống.
Kiểm tra thực hành: Trợ giúp trực tuyến được thực hiện và xác minh
các thông báo lỗi để đánh giá độ chính xác và tính hữu ích của chúng.
Kiểm tra chức năng: Các hướng dẫn có trong tài liệu được tuân theo
để xác minh rằng hệ thống hoạt động như đã được lập thành tài liệu.
Các bài kiểm tra cụ thể sau đây được khuyến nghị để kiểm tra tài
liệu: • Đọc tất cả các tài liệu để xác minh (i) sử dụng đúng ngữ pháp,
(ii) sử dụng thuật ngữ một cách nhất quán và (iii) sử dụng đồ họa
thích hợp nếu có thể.
Xác minh rằng bảng thuật ngữ kèm theo tài liệu sử dụng thuật ngữ
tiêu chuẩn, được chấp nhận phổ biến và bảng thuật ngữ đó xác định
đúng các thuật ngữ.
Xác minh rằng tồn tại một chỉ mục cho mỗi tài liệu và khối chỉ mục
khá phong phú và đầy đủ. Xác minh rằng phần chỉ mục trỏ đến các
trang chính xác.
Xác minh rằng không có sự mâu thuẫn nội bộ trong tài liệu.
Xác minh rằng phiên bản trực tuyến và phiên bản in của tài liệu là
giống nhau.
Xác minh quy trình cài đặt bằng cách thực hiện các bước được mô tả
trong sách hướng dẫn trong môi trường thực tế.
307
•
Xác minh hướng dẫn khắc phục sự cố bằng cách chèn lỗi và sau đó
sử dụng hướng dẫn để khắc phục lỗi.
Xác minh các ghi chú phát hành phần mềm để đảm bảo rằng những
ghi chú này mô tả chính xác (i) những thay đổi về tính năng và chức
năng giữa bản phát hành hiện tại và bản trước đó và (ii) tập hợp các
lỗi đã biết và tác động của chúng đối với khách hàng.
Xác minh trợ giúp trực tuyến về (i) khả năng sử dụng, (ii) tính toàn
vẹn, (iii) tính hữu ích của các siêu liên kết và các tham chiếu chéo
đến các chủ đề liên quan, (iv) tính hiệu quả của việc tra cứu bảng, và
(v) tính chính xác và hữu ích của các chỉ số.
Xác minh phần cấu hình của hướng dẫn sử dụng bằng cách định cấu
hình hệ thống như được mô tả trong tài liệu.
Cuối cùng, sử dụng tài liệu trong khi thực hiện các trường hợp kiểm
tra hệ thống. Xem qua các hoạt động và thủ tục làm việc đã được lên
kế hoạch hoặc hiện có của người dùng bằng cách sử dụng tài liệu để
đảm bảo rằng tài liệu phù hợp với công việc của người dùng.
8.13 KIỂM TRA QUY ĐỊNH
Trong danh mục này, hệ thống cuối cùng được chuyển đến các cơ
quan quản lý ở những quốc gia nơi sản phẩm dự kiến được đưa ra thị
trường. Ý tưởng là để có được các nhãn hiệu tuân thủ trên sản phẩm
từ các cơ quan đó. Các cơ quan phê duyệt quy định của các quốc gia
khác nhau được trình bày trong Bảng 8.2. Hầu hết các cơ quan quản
lý này cấp chứng chỉ tuân thủ về an toàn và EMC (tương thích điện
từ) / EMI (nhiễu điện từ) (phát xạ và miễn nhiễm). Các cơ quan quản
lý quan tâm đến việc xác định các sai sót trong phần mềm có khả
năng gây hậu quả về an toàn. Các yêu cầu về an toàn chủ yếu dựa
trên các tiêu chuẩn được công bố của chính họ. Ví dụ, nhãn hiệu CSA
(Hiệp hội Tiêu chuẩn Canada) là một trong những biểu tượng được
công nhận, chấp nhận và đáng tin cậy nhất trên thế giới. Dấu CSA
trên một sản phẩm có nghĩa là CSA đã kiểm tra một mẫu đại diện của
sản phẩm và xác định rằng sản phẩm đáp ứng các yêu cầu của CSA.
Người tiêu dùng quan tâm và có ý thức về an toàn sẽ tìm kiếm nhãn
hiệu CSA trên các sản phẩm họ mua. Tương tự, dấu CE (Conformite
Europ´ eenne) trên một sản phẩm cho thấy sự phù hợp với chỉ thị của
Liên minh Châu Âu về an toàn, sức khỏe, môi trường và bảo vệ
•
người tiêu dùng. Để một sản phẩm được bán ở Hoa Kỳ, sản phẩm đó
cần phải đáp ứng các yêu cầu quy định nhất định của Ủy ban Truyền
thông Liên bang (FCC).
An toàn phần mềm được định nghĩa dưới dạng các mối nguy hiểm.
Mối nguy là một trạng thái của một hệ thống hoặc một tình huống vật
chất mà khi kết hợp với các điều kiện môi trường nhất định có thể
dẫn đến tai nạn hoặc sự cố. Tai nạn hoặc sai sót là một sự kiện ngoài
ý muốn hoặc một loạt các sự kiện dẫn đến tử vong, thương tật, bệnh
tật, thiệt hại hoặc mất mát tài sản, hoặc gây hại cho môi trường [12].
Rủi ro là một điều kiện tiên quyết hợp lý cho một tai nạn. Bất cứ khi
nào có nguy cơ, hậu quả có thể là tai nạn. Sự tồn tại của trạng thái
nguy hiểm không có nghĩa là cuối cùng sẽ xảy ra tai nạn. Khái niệm
an toàn liên quan đến việc ngăn ngừa các mối nguy hiểm.
309
8.13 KIỂM TRA QUY ĐỊNH
BẢNG 8.2 Các cơ quan phê duyệt theo quy định của các quốc
gia khác nhau
Quốc gia Cơ quan phê duyệt chứng nhận theo quy định
Argentina IRAM là một hiệp hội tư nhân phi lợi nhuận và là
cơ quan chứng nhận quốc gia của Argentina cho
nhiều danh mục sản phẩm. Dấu an toàn IRAM được
đánh giá dựa trên sự tuân thủ các yêu cầu an toàn
của tiêu chuẩn IRAM quốc gia.
Úc và Cơ quan Truyền thông Úc (ACA) và Nhóm Quản lý
Mới Quang phổ Vô tuyến (RSM) của New Zealand đã
Zealand đồng ý về một kế hoạch hài hòa trong việc sản xuất
dấu C-tick quy định việc tuân thủ EMC của sản
phẩm.
Canada Hiệp hội tiêu chuẩn Canada
Cộng hòa Séc Cộng hòa Séc là quốc gia châu Âu đầu tiên áp dụng
các quy định đánh giá sự phù hợp dựa trên dấu CE
của Liên minh châu Âu mà không cần chứng nhận
hoặc thử nghiệm phê duyệt bổ sung.
Liên minh Châu Conformite Europ´ eenne´
Âu
Nhật Bản Dấu hiệu VCCI (Hội đồng tự nguyện kiểm soát sự
can thiệp của thiết bị công nghệ thông tin) do VCCI
quản lý đối với thiết bị công nghệ thông tin (ITE)
được bán tại Nhật Bản.
Hàn Quốc Tất cả các sản phẩm được bán tại Hàn Quốc bắt
buộc phải tuân thủ và phải được chứng nhận nhãn
hiệu MIC (Bộ Thông tin và Truyền thông). EMC và
kiểm tra an toàn là cả hai yêu cầu.
Mexico Các sản phẩm phải được kiểm tra tại Mexico về
nhãn hiệu NOM (Normality of Mexico) bắt buộc.
Cộng hòa nhân Dấu CCC (Chứng nhận Bắt buộc của Trung Quốc)
dân Trung Hoa là bắt buộc đối với nhiều loại sản phẩm được bán ở
Cộng hòa Nhân dân Trung Hoa.
Ba lan Dấu B an toàn của Ba Lan (B cho bezpieczny, có
310 CHƯƠNG 9 KIỂM TRA CHỨC NĂNG
nghĩa là “an toàn”) phải được hiển thị trên tất cả các
sản phẩm nội địa và nhập khẩu nguy hiểm.
Ba Lan không chấp nhận nhãn hiệu CE của Liên
minh Châu Âu.
Nga Chứng nhận GOST-R. Hệ thống chứng nhận này
được quản lý bởi
Ủy ban Nhà nước Nga về Tiêu chuẩn hóa, Đo
lường và Chứng nhận (Gosstandart). Gosstandart
giám sát và phát triển các chương trình chứng nhận
bắt buộc và tự nguyện trong ngành.
Singapore Nhãn hiệu PSB do Hội đồng Tiêu chuẩn và Năng
suất Singapore cấp. Cơ quan An toàn (PSB) là cơ
quan theo luật định do Bộ Thương mại và Công
nghiệp chỉ định để quản lý các quy định.
Nam Phi Chương trình an toàn cho hàng điện do Cục Tiêu
chuẩn Nam Phi (SABS) thay mặt chính phủ điều
hành.
SABS có thể cung cấp sự tuân thủ dựa trên việc nộp
báo cáo thử nghiệm từ bất kỳ phòng thí nghiệm
được công nhận nào.
Đài loan Hầu hết các sản phẩm được bán ở Đài Loan phải
được phê duyệt theo các quy định do BSMI (Cục
Tiêu chuẩn, Đo lường và Kiểm tra) đưa ra.
Hoa Kỳ Ủy ban Truyền thông Liên bang
Một phần mềm bị cô lập không thể gây ra thiệt hại vật chất. Tuy
nhiên, một phần mềm trong ngữ cảnh của một hệ thống và môi
trường nhúng có thể dễ bị tấn công. Ví dụ, một mô-đun phần mềm
trong ứng dụng cơ sở dữ liệu tự nó không nguy hiểm, nhưng khi nó
được nhúng vào hệ thống dẫn đường tên lửa, nó có thể nguy hiểm.
Nếu một tên lửa quay đầu lại do lỗi phần mềm trong hệ thống định vị
và phá hủy tàu ngầm đã phóng nó, thì đó không phải là một phần
mềm an toàn. Do đó, các nhà sản xuất và các cơ quan quản lý cố
gắng đảm bảo rằng phần mềm được an toàn trong lần đầu tiên nó
được phát hành.
Các tổ chức phát triển hệ thống phần mềm quan trọng về an toàn cần
có chương trình đảm bảo an toàn (SA) để loại bỏ các mối nguy hoặc
311
giảm rủi ro liên quan đến mức có thể chấp nhận được [13]. Hai
nhiệm vụ cơ bản được thực hiện bởi một nhóm kỹ sư SA như sau:
Cung cấp các phương pháp xác định, theo dõi, đánh giá và loại bỏ
các mối nguy liên quan đến một hệ thống.
Đảm bảo rằng an toàn được đưa vào thiết kế và triển khai một cách
kịp thời và hiệu quả về chi phí để giảm thiểu rủi ro do lỗi của người
sử dụng / người vận hành. Do đó, thiệt hại tiềm tàng trong trường
hợp xảy ra sai sót được giảm thiểu.
8.14 TÓM TẮT
Trong chương này, chúng tôi đã trình bày phân loại các bài kiểm tra
hệ thống với các ví dụ từ các lĩnh vực khác nhau. Chúng tôi đã giải
thích các loại kiểm tra hệ thống sau:
Các thử nghiệm cơ bản cung cấp bằng chứng rằng hệ thống có thể
được cài đặt, cấu hình và đưa về trạng thái hoạt động. Chúng tôi đã
mô tả năm loại kiểm tra cơ bản: khởi động, nâng cấp / hạ cấp, kiểm
tra điốt phát sáng, chẩn đoán và kiểm tra giao diện dòng lệnh.
Kiểm tra chức năng cung cấp kiểm tra toàn diện trên toàn bộ các yêu
cầu trong khả năng của hệ thống. Trong danh mục này, chúng tôi đã
mô tả tám loại kiểm tra: hệ thống truyền thông, mô-đun, ghi nhật ký
và truy tìm, hệ thống quản lý phần tử, cơ sở thông tin quản lý, giao
diện người dùng đồ họa, kiểm tra bảo mật và tính năng.
Các bài kiểm tra độ chắc chắn xác định quá trình khôi phục hệ thống
từ các điều kiện lỗi khác nhau hoặc các tình huống hỏng hóc. Trong
danh mục này, chúng tôi đã mô tả năm loại kiểm tra độ chắc chắn:
giá trị ranh giới, vòng quay công suất, chèn và loại bỏ trực tuyến,
tính khả dụng cao, kiểm tra nút xuống cấp.
Kiểm tra khả năng tương tác xác định xem hệ thống có thể tương tác
với các sản phẩm của bên thứ ba khác hay không.
Kiểm tra hiệu suất đo lường các đặc tính hoạt động của hệ thống, ví
dụ, thông lượng và thời gian phản hồi, trong các điều kiện khác nhau.
Kiểm tra khả năng mở rộng xác định giới hạn mở rộng của hệ thống.
Kiểm tra căng thẳng làm căng thẳng hệ thống nhằm xác định các hạn
chế của hệ thống và xác định cách thức xảy ra các lỗi nếu hệ thống
không thành công.
Các bài kiểm tra tải và độ ổn định cung cấp bằng chứng rằng, khi hệ
thống được tải với một số lượng lớn người dùng ở mức công suất tối
đa của nó, hệ thống sẽ ổn định trong một thời gian dài dưới lưu lượng
truy cập dày đặc.
Các bài kiểm tra độ tin cậy đo lường khả năng tiếp tục hoạt động của
hệ thống trong thời gian dài.
Kiểm tra hồi quy xác định rằng hệ thống vẫn ổn định khi nó xoay
vòng trong quá trình tích hợp với các dự án khác và thông qua các
nhiệm vụ bảo trì.
Kiểm tra tài liệu đảm bảo rằng các hướng dẫn sử dụng của hệ thống
là chính xác và có thể sử dụng được.
Kiểm tra quy định đảm bảo rằng hệ thống đáp ứng các yêu cầu của
các cơ quan quản lý của chính phủ. Hầu hết các cơ quan quản lý này
cấp giấy chứng nhận tuân thủ về an toàn, khí thải và khả năng miễn
nhiễm.
Có thể tìm thấy một cuộc thảo luận tốt về các khái niệm an toàn phần
mềm, chẳng hạn như sai sót, nguy cơ, phân tích mối nguy, phân tích
cây lỗi, phân tích cây sự kiện, các chế độ lỗi và phân tích hiệu ứng và
tường lửa, có thể được tìm thấy trong Chương 5 của cuốn sách của
Freidman và Voas [13] . Cuốn sách trình bày các ví dụ và ý kiến hữu
ích liên quan đến mối quan hệ của các khái niệm này với độ tin cậy
của phần mềm.
Đối với những độc giả tích cực tham gia vào thử nghiệm khả năng sử
dụng hoặc quan tâm đến cách xử lý chi tiết hơn về chủ đề này, cuốn
sách của Jeffrey Rubin (Sổ tay Kiểm tra khả năng sử dụng — Cách
lập kế hoạch, thiết kế và thực hiện thử nghiệm hiệu quả, Wiley, New
York, 1994) cung cấp một hướng dẫn tuyệt vời. Rubin mô tả chi tiết
bốn loại kiểm tra khả năng sử dụng: (i) khám phá, (ii) đánh giá, (iii)
xác nhận và (iv) so sánh. Cuốn sách liệt kê một số tài liệu tham khảo
tuyệt vời về chủ đề này trong phần thư mục của nó. Memon và cộng
sự. đã tiến hành nghiên cứu sáng tạo về các tiêu chí kiểm tra đầy đủ
và các thuật toán tạo dữ liệu kiểm tra tự động được điều chỉnh riêng
cho các chương trình có giao diện người dùng đồ họa. Đề nghị độc
giả quan tâm nghiên cứu các bài viết sau:
313
AM Memon, “Kiểm tra GUI: Cạm bẫy và quy trình”, IEEE
Computer, Vol. 35, số 8, 2002, trang 90–91.
AM Memon, ME Pollock và ML Soffa, “Tạo trường hợp thử nghiệm
GUI phân cấp bằng cách sử dụng lập kế hoạch tự động”, Giao dịch
IEEE về Kỹ thuật phần mềm, Vol. 27, số 2, 2001, trang 144–155.
AM Memon, ML Soffa và ME Pollock, “Tiêu chí phù hợp cho thử
nghiệm GUI,” trong Kỷ yếu của Hội nghị chuyên đề quốc tế ACM
SIGSOFT lần thứ 9 về Cơ sở kỹ thuật phần mềm, ACM Press, New
York 2001, trang 256–267.
Trong công việc được đề cập ở trên, GUI được biểu diễn dưới dạng
một loạt các toán tử có các điều kiện trước và điều kiện sau liên quan
đến trạng thái của GUI. Biểu diễn này phân loại các sự kiện GUI
thành bốn loại: sự kiện mở menu, sự kiện tập trung không hạn chế,
sự kiện tập trung hạn chế và sự kiện tương tác hệ thống. Các sự kiện
mở menu thường được kết hợp với việc sử dụng các menu kéo xuống
trong GUI. Các sự kiện tiêu điểm không hạn chế chỉ đơn giản là mở
rộng các tùy chọn tương tác có sẵn cho người dùng GUI, trong khi
các sự kiện tiêu điểm hạn chế yêu cầu sự chú ý của người dùng trước
khi các tương tác bổ sung có thể xảy ra. Cuối cùng, các sự kiện tương
tác hệ thống yêu cầu GUI tương tác với ứng dụng thực tế.
Một bộ sưu tập các bài luận xuất sắc về khả năng sử dụng và các khía
cạnh bảo mật của một hệ thống xuất hiện trong cuốn sách do LF
Cranor và S. Garfinkel biên tập (Security and Usability, O'Reilly,
Sebastopol, CA, 2005). Cuốn sách này bao gồm 34 bài báo đột phá
thảo luận về các nghiên cứu điển hình về thiết kế hệ thống an toàn có
thể sử dụng được. Cuốn sách này hữu ích cho các nhà nghiên cứu,
sinh viên và những người thực hành trong lĩnh vực bảo mật và khả
năng sử dụng.
Có thể tìm thấy các phương pháp xử lý nghiêm ngặt về mặt toán học
đối với phân tích hiệu suất và các khái niệm liên quan đến kỹ thuật
hiệu suất phần mềm trong các cuốn sách sau:
R. Jain, Nghệ thuật Phân tích Hiệu suất Hệ thống Máy tính, John,
New York, 1991.
CU Smith, Kỹ thuật Hiệu suất của Hệ thống Phần mềm, Addison-
Wesley, Reading, MA, 1990.
Mỗi cuốn sách này cung cấp một nền tảng lý thuyết cần thiết cho sự
hiểu biết của chúng ta về kỹ thuật hiệu suất.

Bài tập
Hệ thống quản lý yếu tố (EMS) là gì? Nó khác với trạm quản lý
mạng lưới (NMS) như thế nào?
Sự khác biệt giữa kiểm tra cấu hình, khả năng tương thích và khả
năng tương tác là gì?
Sự khác biệt giữa kiểm tra hiệu suất, căng thẳng và khả năng mở
rộng là gì? Sự khác biệt giữa kiểm tra tải và kiểm tra căng thẳng là
gì?
Sự khác biệt giữa hiệu suất và tốc độ là gì?
Tràn bộ đệm là lỗ hổng thường thấy nhất trong mã nhận biết mạng có
thể bị lợi dụng để xâm phạm hệ thống. Giải thích lý do.
Các cuộc tấn công zero-day là gì? Thảo luận về tầm quan trọng của
nó đối với việc bảo mật.
Thảo luận về tầm quan trọng của kiểm thử hồi quy khi phát triển một
phần mềm mới. Những trường hợp kiểm thử nào từ bộ thử nghiệm sẽ
hữu ích hơn trong việc thực hiện kiểm tra hồi quy?
Sự khác biệt giữa độ an toàn và độ tin cậy là gì? Sự khác biệt giữa
kiểm thử an toàn và kiểm tra bảo mật là gì?
Điểm giống nhau giữa an toàn phần mềm và khả năng chịu lỗi là gì?
Đối với mỗi tình huống sau đây, hãy giải thích xem đó là một mối
nguy hiểm hay một sự cố sai lầm:
Nước trong bể bơi trở nên nhiễm điện.
Một căn phòng chứa đầy carbon dioxide.
Một chiếc ô tô dừng đột ngột.
Một công ty điện thoại đường dài bị mất điện.
Một vũ khí hạt nhân bị phá hủy theo cách không có kế hoạch.
Điểm giống và khác nhau giữa đảm bảo chất lượng (QA) và đảm bảo
an toàn (SA) là gì?
Đối với dự án thử nghiệm hiện tại của bạn, hãy phát triển phân loại
các thử nghiệm hệ thống mà bạn thực hiện dựa trên việc triển khai.
315
CHAPTER
9
FunctionalTesting
Bài kiểm tra đánh giá trí thông minh bậc nhất là khả năng lưu giữ hai
ý tưởng trái ngược nhau trong đầu cùng một lúc mà vẫn giữ được khả
năng hoạt động.
—F.ScottFitzgerald
9.1 CÁC KHÁI NIỆM VỀ KIỂM TRA CHỨC NĂNG CỦA
HOWDEN
William E. Howden đã phát triển ý tưởng kiểm tra chức năng của các
chương trình khi đến thăm Thư viện Toán học và Thống kê Quốc tế
(IMSL) ở Houston vào năm 1977–1978. IMSL hiện được gọi là
Visual Numerics (http://www.vni.com/). Các thư viện IMSL là một
tập hợp toàn diện các hàm toán học và thống kê mà các lập trình viên
có thể nhúng vào các ứng dụng phần mềm của họ. IMSL sử dụng
công nghệ đã được chứng minh đã được kiểm tra kỹ lưỡng, ghi chép
đầy đủ và được bảo trì liên tục. Howden đã áp dụng ý tưởng kiểm tra
chức năng cho các chương trình từ phiên bản 5 của gói IMSL. Những
sai sót mà ông đã phát hiện ra có thể được coi là một chút tinh tế để
tồn tại đến trạng thái của ấn bản 5 [1].
Một hàm trong toán học được định nghĩa là một tập hợp các cặp có
thứ tự ( X i , Y i ), trong đó X i là vectơ giá trị đầu vào và Y i là vectơ
giá trị đầu ra. Trong thử nghiệm chức năng, một chương trình P được
xem như một hàm biến đổi vectơ đầu vào X i thành một vectơ đầu ra
Y i sao cho Y i = P (X i ) .
Các ví dụ
Hãy để . Ở đây, P là một hàm tính toán căn bậc hai tính toán
bình phương Y 1 của số nguyên không âm X 1 . Kết quả được gán cho
Y 1.
Cho Y 2 = C_compiler ( X 2 ). Chương trình P được xem như một
hàm C_compiler tạo mã đối tượng từ chương trình C X 2 . Mã đối
tượng được giữ trong Y 2 .
222
Cho Y 3 = TelephoneSwitch ( X 3 ). Một chương trình chuyển mạch
điện thoại P tạo ra nhiều loại âm sắc và tín hiệu giọng nói được biểu
diễn bằng vectơ
Y 3 = { nhàn rỗi, quay số, đổ chuông, bận nhanh, âm báo bận chậm,
giọng nói }
bằng cách xử lý dữ liệu đầu vào được biểu thị bằng vectơ
X 3 = { off hook, on hook, phone number, voice }.
Cho Y 4 = sort ( X 4 ). Chương trình P trong ví dụ này là việc triển
khai thuật toán sắp xếp tạo ra một mảng được sắp xếp Y 4 từ vectơ
đầu vào X 4 = {A, N} , trong đó A là mảng được sắp xếp và N là số
phần tử trong A .
Bốn ví dụ trên gợi ý rằng đôi khi việc xem một chương trình như một
hàm theo nghĩa toán học là dễ dàng và đôi khi nó khó hơn. Sẽ dễ
dàng hơn để xem một chương trình như một hàm khi các giá trị đầu
vào được chuyển đổi theo thuật toán hoặc toán học thành các giá trị
đầu ra, chẳng hạn như trong ví dụ đầu tiên và thứ tư ở trên. Trong ví
dụ thứ tư, Y 4 là một hoán vị nhất định của mảng đầu vào A. Sẽ khó
hơn khi xem một chương trình như một hàm khi các giá trị đầu vào
không được chuyển đổi trực tiếp thành các giá trị đầu ra. Ví dụ, trong
ví dụ thứ ba ở trên, một đầu vào off-hook không được biến đổi về
mặt toán học thành đầu ra âm quay số. Trong thử nghiệm chức năng,
chúng tôi không quan tâm đến các chi tiết của cơ chế mà một vectơ
đầu vào được biến đổi thành một vectơ đầu ra. Thay vào đó, một
chương trình được coi như một hàm theo nghĩa chung.
Ba yếu tố chính của một chức năng là đầu vào, đầu ra và sự chuyển
đổi dự kiến của đầu vào thành đầu ra. Bỏ qua các chi tiết về sự
chuyển đổi thực tế của đầu vào thành đầu ra, chúng tôi phân tích các
miền của đầu vào và các biến đầu ra của các chương trình để tạo ra
dữ liệu thử nghiệm. Bốn khái niệm chính trong kiểm thử chức năng
[2] như sau: • Xác định chính xác miền của mỗi đầu vào và mỗi biến
đầu ra.
317
Chọn các giá trị từ miền dữ liệu của mỗi biến có các thuộc tính quan
trọng.
Xem xét sự kết hợp của các giá trị đặc biệt từ các miền đầu vào khác
nhau để thiết kế các trường hợp thử nghiệm.
Xem xét các giá trị đầu vào sao cho chương trình đang thử nghiệm
tạo ra các giá trị đặc biệt từ các miền của các biến đầu ra.
Người ta có thể xác định miền của một đầu vào hoặc một biến đầu ra
bằng cách phân tích đặc điểm kỹ thuật yêu cầu và các tài liệu thiết
kế. Trong các phần tiếp theo, chúng ta thảo luận về phương pháp của
Howden để chọn dữ liệu kiểm tra từ các miền của biến đầu vào và
đầu ra.
9.1.1 Các loại biến khác nhau
Trong phần này, chúng ta xem xét các biến số, mảng, cấu trúc con và
các đối số của chương trình con và các giá trị quan trọng của chúng.
Các loại biến này thường được sử dụng làm đầu vào và đầu ra từ một
số lượng lớn các hệ thống để tính toán số. Gói MATLAB và một số
hệ thống phần mềm khai thuế là những ví dụ về các hệ thống như
vậy.
Biến số Miền của một biến số được xác định theo một trong
hai cách như sau:
Một tập hợp các giá trị rời rạc: Ví dụ về loại miền này là MODE =
{ 23 , 79 } từ đặc tả Bluetooth. Biến MODE là một biến số nhận một
trong hai giá trị từ tập { 23 , 79 } . Giá trị MODE được sử dụng trong
hoạt động mô-đun để xác định tần số kênh để truyền gói.
Một số phân đoạn giá trị liền kề: Ví dụ: đầu vào tổng thu nhập cho
phần mềm khai thuế cho một người hoặc công ty được chỉ định dưới
dạng giá trị từ phạm vi { 0 , ..., ∞} . Mỗi phân đoạn liền kề được đặc
trưng bởi giá trị nhỏ nhất (MIN) và giá trị lớn nhất (MAX).
Ví dụ: Các đầu vào và các biến đầu ra của mô-đun hộp chọn tần số
(FSB) của hệ thống truyền thông không dây Bluetooth được thể hiện
trong Hình 9.1. Công nghệ giao tiếp Bluetooth sử dụng kỹ thuật trải
phổ nhảy tần để truy cập phương tiện không dây. Kênh piconet được
xem như một chuỗi các khe có thể là vô hạn, trong đó một khe dài
625 μ s. Tần số mà một gói dữ liệu sẽ được truyền trong một khe
nhất định được tính toán bởi mô-đun FSB được minh họa trong Hình
9.1. Mô-đun FSB chấp nhận ba biến đầu vào MODE, CLOCK và
ADDRESS và tạo ra các giá trị của biến đầu ra INDEX. Cả bốn đều
là biến số. Miền của các biến này được đặc trưng như sau:
MODE: Miền của biến MODE là tập rời rạc { 23 , 79 } .
CLOCK: Biến CLOCK được biểu diễn bằng một số không dấu 28 bit
với MIN = 0x0000000 và MAX = 0xFFFFFFF. Gia số nhỏ nhất
Mode: {23, 79}
Lower 28 bits
48-bit Address Frequency
selection
box
28-bit Clock
Upper 27 bits Index: 0–78 or
0–22
Hình 9.1 Hộp chọn tần số của đặc điểm kỹ thuật Bluetooth.
trong ĐỒNG HỒ đại diện cho sự trôi qua của 312 . 5 μ s. Mô-đun
FSB sử dụng 27 bit trên của ĐỒNG HỒ 28 bit trong tính toán tần số.
ĐỊA CHỈ: Biến ADDRESS được biểu diễn bằng một số 48 bit không
dấu. Mô-đun FSB sử dụng 28 bit thấp hơn của ĐỊA CHỈ 48 bit. Do
đó, phạm vi ĐỊA CHỈ từ quan điểm của mô-đun FSB được chỉ định
như sau:
MIN = 0xyyyyy0000000, where yyyyy is a 20-bit arbitrary value.
MAX = 0xzzzzzFFFFFFF, where zzzzz is a 20-bit arbitrary value.
INDEX: This variable assumes values in a given range as specified
in the following:
MIN = 0.
MAX = 22 if MODE = 23.
.MAX = 78 if MODE = 79
Với đặc điểm miền của một biến số là một tập giá trị rời rạc hoặc như
một tập hợp các phân đoạn liền kề, dữ liệu thử nghiệm được chọn
bằng cách áp dụng các tiêu chí lựa chọn khác nhau tùy thuộc vào
việc sử dụng các biến đó, cụ thể là (i) đầu vào, (ii) đầu ra , (iii) sử
dụng kép, và (iv) đa loại. Biến sử dụng kép là biến giữ đầu vào cho
hệ thống đang được kiểm tra khi bắt đầu thực thi hệ thống và nhận
giá trị đầu ra từ hệ thống tại một thời điểm nào đó sau đó. Biến nhiều
kiểu là biến có thể chứa các giá trị đầu vào (hoặc thậm chí đầu ra)
của các kiểu khác nhau, chẳng hạn như số và chuỗi, tại các thời điểm
khác nhau. Trong phần này, chúng tôi đưa ra một ví dụ về một biến
319
như vậy từ một hệ thống ngoài đời thực. Tiếp theo, chúng tôi giải
thích bốn tiêu chí lựa chọn.
Tiêu chí lựa chọn cho các biến đầu vào: Nếu miền đầu vào là một tập
hợp các giá trị rời rạc, thì các thử nghiệm liên quan đến từng giá trị
sẽ được thực hiện. Miền của biến đầu vào MODE trong Hình 9.1 bao
gồm tập { 23 , 79 } . Mô-đun FSB được kiểm tra ít nhất một lần với
MODE = 23 và ít nhất một lần với MODE = 79. Nếu miền của một
biến bao gồm một hoặc nhiều phân đoạn giá trị, thì dữ liệu kiểm tra
được chọn như sau:
Xem xét giá trị nhỏ nhất của một phân đoạn.
Xem xét giá trị lớn nhất của một phân đoạn.
Xem xét một giá trị đại diện điển hình trong một phân khúc. • Xem
xét các giá trị nhất định có tính chất toán học đặc biệt. Các giá trị này
bao gồm 0, 1 và các số thực có giá trị tuyệt đối nhỏ. • Xem xét, nếu
có thể, các giá trị nằm ngoài một phân đoạn. Ở đây ý tưởng là quan
sát hành vi của chương trình để đáp ứng với đầu vào không hợp lệ. •
Trong trường hợp giá trị cực tiểu (cực đại) theo khái niệm của một
biến là −∞ ( + ∞ ), thì một giá trị âm (dương) lớn được chọn để biểu
diễn −∞ ( + ∞ ).
Tiêu chí lựa chọn cho biến đầu ra: Nếu miền của biến đầu ra bao
gồm một tập hợp nhỏ các giá trị rời rạc, thì chương trình được kiểm
tra với đầu vào dẫn đến việc tạo ra từng giá trị đầu ra. Biến đầu ra
của hộp nhảy tần trong Hình 9.1 có miền gồm hai bộ rời rạc { 0 , ...,
22 } và { 0 , ..., 78 } cho MODE = 23 và MODE = 79, tương ứng.
Hộp nhảy tần phải được thử nghiệm đầy đủ để nó tạo ra từng giá trị
đầu ra như mong muốn. Đối với một tập hợp lớn các giá trị rời rạc,
chương trình được thử nghiệm với nhiều đầu vào khác nhau khiến
chương trình tạo ra nhiều giá trị đầu ra khác nhau. Nếu một biến đầu
ra có miền bao gồm một hoặc nhiều đoạn số, thì chương trình được
kiểm tra như sau:
Kiểm tra chương trình với các đầu vào khác nhau để nó tạo ra các giá
trị nhỏ nhất của các phân đoạn.
Kiểm tra chương trình với các đầu vào khác nhau để nó tạo ra giá trị
lớn nhất của các phân đoạn.
Kiểm tra chương trình với các đầu vào khác nhau để nó tạo ra một số
giá trị nội thất trong mỗi phân đoạn.
Tiêu chí lựa chọn cho các biến sử dụng kép: Một biến thường đóng
vai trò là đầu vào cho chương trình (hoặc hàm) và giữ đầu ra từ
chương trình (hoặc hàm) ở cuối phép tính mong muốn. Một biến như
vậy được gọi là biến sử dụng kép. Các trường hợp thử nghiệm bổ
sung được thiết kế để đáp ứng các tiêu chí lựa chọn sau đây cho các
biến sử dụng kép:
Hãy xem xét một trường hợp thử nghiệm để chương trình tạo ra một
giá trị đầu ra khác với giá trị đầu vào của cùng một biến sử dụng kép.
Ý tưởng đằng sau bài kiểm tra này là để tránh sự chính xác ngẫu
nhiên của đầu ra.
Hãy xem xét một trường hợp thử nghiệm sao cho chương trình tạo ra
một giá trị đầu ra giống với giá trị đầu vào của cùng một biến sử
dụng kép.
Tiêu chí lựa chọn cho các biến nhiều loại: Đôi khi một biến đầu vào
có thể nhận các giá trị thuộc nhiều loại khác nhau. Ví dụ, một biến có
thể nhận các giá trị kiểu số nguyên trong một lệnh gọi chương trình
và kiểu chuỗi trong một lệnh gọi khác. Lập trình viên có thể khó xác
định một không gian lưu trữ duy nhất để chứa các giá trị thuộc các
kiểu khác nhau. Chương trình sẽ đọc giá trị đầu vào vào các vị trí
khác nhau (tức là các biến) tùy thuộc vào loại giá trị được cung cấp
bởi người dùng. Tình huống này yêu cầu chúng ta kiểm tra xem
chương trình có đọc đúng giá trị đầu vào hay không tùy thuộc vào
kiểu của nó và sau đó, xử lý chính xác giá trị đó. Các biến nhiều kiểu
như vậy có thể phát sinh trong các hệ thống ngoài đời thực và các
chương trình phải thực hiện các hành động cần thiết để xử lý chúng.
Nếu một biến đầu vào hoặc đầu ra có thể nhận các giá trị thuộc các
kiểu khác nhau, thì các tiêu chí sau được sử dụng:
Đối với biến đầu vào của kiểu đa dạng, chương trình được kiểm tra
với các giá trị đầu vào của tất cả các kiểu.
Đối với biến đầu ra có kiểu đa dạng, chương trình được kiểm tra với
các đầu vào khác nhau để biến chứa các giá trị thuộc tất cả các kiểu
khác nhau.
Ví dụ: Chúng tôi hiển thị một phần của các biểu mẫu thuế do Cơ
quan Hải quan và Doanh thu Canada (CCRA) chuẩn bị trong Hình
9.2. Bằng cách phân tích thông số kỹ thuật này, chúng tôi kết luận
rằng người nộp thuế (người dùng) nhập một số thực hoặc một ô trống
trong dòng 2.
321
Nhập thu nhập ròng của bạn từ dòng 236 của lợi tức 1
Nhập thu nhập ròng của vợ / chồng hoặc đối tác chung của bạn từ
trang 1 của tờ khai + 2 của bạn
Thêm dòng 1 và 2 Thu nhập cho các khoản tín dụng
Ontario = 3
Tách biệt không tự nguyện 6089
Nếu, vào ngày 31 tháng 12 năm 2001, _____________
bạn và vợ / chồng hoặc người thông luật
của bạn
đối tác chiếm các khu nhà chính riêng _____________
biệt cho y tế,
vì lý do giáo dục hoặc kinh doanh, hãy _____________
để trống dòng 2
và nhập địa chỉ của người đó vào vùng _____________
bên cạnh ô 6089.
Hình 9.2 Một phần của biểu mẫu ON479 của tổng quát T1 —
2001, do CCRA xuất bản.
giá trị đầu vào ở dòng 2 là một số thực đại diện cho thu nhập ròng
của vợ / chồng hoặc người bạn đời chung của người dùng nếu cả hai
người ở cùng một nơi ở vào ngày 31 tháng 12 năm 2001. Ngược lại,
nếu họ ở riêng biệt vì những lý do cụ thể , thì dòng 2 phải được để
trống và địa chỉ của vợ / chồng hoặc người bạn đời thông luật phải
được cung cấp trong ô 6089.
Rõ ràng, dòng 2 là đầu vào của hệ thống phần mềm khai thuế phải có
khả năng xử lý các loại giá trị khác nhau được nhập vào dòng 2 — cụ
thể là giá trị thực và giá trị trống, và giá trị trống không giống như
0,0. Điều này là do, nếu chúng ta đánh đồng ô trống với 0,0, thì hệ
thống phần mềm có thể không biết khi nào và làm thế nào để diễn
giải thông tin được cung cấp trong ô 6089. Đề cập đến đầu vào dòng
2 của Hình 9.2, chương trình khai thuế phải được kiểm tra như sau:
Giải thích dòng 2 là một biến số nhận các giá trị từ một khoảng và áp
dụng các tiêu chí lựa chọn như chọn giá trị nhỏ nhất, giá trị lớn nhất
và giá trị bên trong của khoảng xác định.
Diễn giải dòng 2 là một biến chuỗi nhận các giá trị từ một tập giá trị
rời rạc, trong đó tập rời rạc chỉ bao gồm một phần tử, cụ thể là một
khoảng trống.
Mảng Một mảng chứa các giá trị cùng kiểu, chẳng hạn như số
nguyên và số thực. Các phần tử riêng lẻ của một mảng được truy cập
bằng cách sử dụng một hoặc nhiều chỉ số. Trong một số ngôn ngữ lập
trình, chẳng hạn như MATLAB, một mảng có thể chứa các giá trị
của cả kiểu nguyên và kiểu thực. Một mảng có cấu trúc phức tạp hơn
một biến số riêng lẻ. Điều này là do ba thuộc tính riêng biệt sau đây
của một mảng. Ba thuộc tính được xem xét riêng lẻ và chung trong
khi thử nghiệm một chương trình.
Một mảng có thể có một hoặc nhiều thứ nguyên. Ví dụ, A [ i ] [ j ] là
phần tử ở hàng i và cột j của mảng A hai chiều . Kích thước mảng
được xem xét trong quá trình thử nghiệm vì các giá trị của chúng có
thể được sử dụng để điều khiển các vòng lặp for và while. Cũng
giống như chúng ta chọn các giá trị cực trị - cả giá trị nhỏ nhất và lớn
nhất - và giá trị trung gian của một biến số, chúng ta cần xem xét các
mảng có cấu hình khác nhau, chẳng hạn như mảng có kích thước tối
thiểu, mảng có kích thước lớn nhất, mảng có giá trị nhỏ nhất cho thứ
nguyên đầu tiên và giá trị tối đa cho thứ nguyên thứ hai, v.v.
Các phần tử mảng riêng lẻ được coi là các biến số riêng biệt. Mỗi giá
trị của một phần tử mảng có thể được đặc trưng bởi giá trị nhỏ nhất,
giá trị lớn nhất và các giá trị đặc biệt, chẳng hạn như 0, 1 và. Tất cả
các giá trị này cần phải xuất hiện trong các bài kiểm tra để quan sát
hành vi của chương trình trong khi xử lý các giá trị cực trị và đặc
biệt.
Một phần của mảng có thể được hiểu chung là một cấu trúc con riêng
biệt với các thuộc tính phụ thuộc vào ứng dụng cụ thể. Ví dụ, trong
lĩnh vực phân tích số, cấu trúc ma trận là một biểu diễn chung của
một tập các phương trình tuyến tính. Các phần tử đường chéo của ma
trận, ma trận tam giác dưới và ma trận tam giác trên là các cấu trúc
con có ý nghĩa trong phân tích số.
Cũng giống như chúng ta xem xét các giá trị đặc biệt của một biến
số, chẳng hạn như 0, 1 và một giá trị nhỏ, tồn tại các giá trị đặc biệt
của cấu trúc con của một mảng. Ví dụ, một số cấu trúc con nổi tiếng
của mảng hai chiều là các hàng và cột riêng lẻ, các phần tử đường
chéo, ma trận tam giác dưới và ma trận tam giác trên. Các cấu trúc
con này được hiểu là một tổng thể.
Tiêu chí lựa chọn cho kích thước mảng dựa trên ba bước trực quan
sau:
323
Chỉ định hoàn toàn các kích thước của một biến mảng. Trong các
ngôn ngữ lập trình như C và Java, các kích thước của một mảng được
xác định tĩnh. Mặt khác, trong ngôn ngữ lập trình MATLAB, không
có khái niệm như định nghĩa tĩnh của một chiều mảng. Thay vào đó,
một mảng có thể được xây dựng động mà không có bất kỳ giới hạn
nào được xác định trước.
Xây dựng các cấu hình đặc biệt, khác nhau của mảng bằng cách xem
xét các giá trị đặc biệt của các kích thước mảng riêng lẻ và sự kết hợp
của chúng. Hãy xem xét một mảng có k thứ nguyên, trong đó mỗi
thứ nguyên được đặc trưng bởi một giá trị nhỏ nhất, một giá trị lớn
nhất và một giá trị trung gian. Các lựa chọn này có thể được kết hợp
để tạo thành 3 k tập hợp kích thước khác nhau cho một mảng k chiều.
Chúng ta hãy lấy một ví dụ cụ thể với mảng hai chiều, trong đó k =
2. Hai kích thước thường được gọi là kích thước hàng và kích thước
cột. Số hàng tối thiểu của một mảng cho một ứng dụng có thể là một
giá trị tùy ý, chẳng hạn như 1. Tương tự, số hàng tối đa có thể là 20.
Số hàng trung gian là 10. Số cột tối thiểu của mảng có thể là 2 , số
cột tối đa có thể là 15 và số cột trung gian có thể là 8. Bằng cách xem
xét ba giá trị hàng và ba giá trị cột, người ta có thể liệt kê 3 k = 3 2 = 9
kết hợp của các cấu hình mảng khác nhau. Một số ví dụ về 9 cấu hình
khác nhau của mảng là 1 × 2, 1 × 15, 20 × 2, 20 × 15, v.v.
Áp dụng các tiêu chí lựa chọn của Phần 9.1.1 cho các phần tử riêng
lẻ của cấu hình mảng đã chọn.
Cấu trúc con Nói chung, cấu trúc có nghĩa là một kiểu dữ liệu có thể
chứa nhiều phần tử dữ liệu. Trong lĩnh vực phân tích số, cấu trúc ma
trận thường được sử dụng. Ví dụ, một tập hợp n phương trình tuyến
tính với n đại lượng chưa biết được biểu diễn bằng một ma trận n ×
(n + 1 ) . N hàng và n cột đầu tiên của ma trận đại diện cho các hệ số
của n phương trình tuyến tính, trong khi cột thứ (n + 1 ) đại diện cho
các hằng số của n phương trình. N hàng và n cột đầu tiên có thể được
coi là một cấu trúc con, trong khi cột thứ (n + 1 ) là một cấu trúc con
khác. Ngoài ra, các cột, hàng và phần tử riêng lẻ của ma trận có thể
được coi là các cấu trúc con riêng biệt. Nói chung, người ta có thể
xác định nhiều loại cấu trúc con của một cấu trúc nhất định. Với thực
tế là có thể có một số lượng lớn các cấu trúc con của một cấu trúc, sẽ
rất hữu ích khi tìm ra các cấu trúc con có thể xác định được về mặt
chức năng. Trong ví dụ trên về ma trận n × (n + 1 ) , cột thứ (n + 1 )
là một cấu trúc con có thể nhận dạng theo chức năng, trong khi phần
còn lại của ma trận là một cấu trúc con có thể nhận dạng theo chức
năng khác. Các cột riêng lẻ và các hàng riêng lẻ cũng là các cấu trúc
con có thể nhận dạng về mặt chức năng. Ví dụ, một hàng các giá trị
giống nhau có nghĩa là các hệ số của tất cả các biến và hằng số của
một phương trình có các giá trị giống hệt nhau. Đôi khi, các cặp cột
có thể tạo thành cấu trúc con. Ví dụ: người ta có thể sử dụng một cặp
cột để biểu thị số phức — một cột cho phần “thực” và một cột khác
cho phần “ảo”. Sẽ rất hữu ích khi xem xét cả cấu trúc đầy đủ và cấu
trúc con, chẳng hạn như hàng, cột và các phần tử riêng lẻ, trong thử
nghiệm chức năng liên quan đến cấu trúc ma trận. Các tiêu chí sau
được xem xét khi xác định các cấu trúc con:
Kích thước của kết cấu con: Chọn kích thước kết cấu sao cho kết
cấu con có thể nhận tất cả các giá trị kích thước có thể có. Ví dụ về
các cấu trúc con nhận các giá trị đặc biệt như sau: (i) số phần tử trong
một hàng là 1 và (ii) số phần tử trong một hàng là “lớn”.
Giá trị của phần tử của cấu trúc: Chọn giá trị của phần tử của cấu
trúc sao cho cấu trúc con nhận tất cả các giá trị đặc biệt có thể có. Ví
dụ về các cấu trúc con nhận các giá trị đặc biệt như sau: (i) tất cả các
phần tử của một hàng nhận giá trị 0, (ii) tất cả các phần tử nhận giá
trị 1 và (iii) tất cả các phần tử nhận giá trị.
Kết hợp các phần tử riêng lẻ với kích thước mảng: Kết hợp khía
cạnh thứ nguyên với khía cạnh giá trị. Ví dụ: người ta có thể chọn
một vectơ lớn — một hàng hoặc một cột — của các phần tử có các
giá trị đặc biệt giống hệt nhau, chẳng hạn như tất cả 0, tất cả 1, v.v.
SubroutineArguments Một số chương trình chấp nhận các biến đầu
vào có giá trị là tên của các hàm. Các chương trình như vậy được tìm
thấy trong các ứng dụng thống kê và phân tích số [1]. Kiểm thử chức
năng yêu cầu mỗi giá trị của một biến như vậy phải được đưa vào
một trường hợp kiểm thử. Hãy xem xét một chương trình P gọi một
hàm f (g, param_list ) , trong đó f () chấp nhận một danh sách các
tham số được ký hiệu là param_list và một tham số g khác thuộc kiểu
liệt kê. Khi f () được gọi, nó gọi hàm được tổ chức trong g . Cho các
giá trị của g được biểu diễn bởi tập {g 1 , g 2 , g 3 } . Chúng tôi thiết kế
ba trường hợp kiểm tra để thực thi f (g 1 , danh sách 1 ) , f (g 2 , danh
sách 2 ) và f (g 3 , danh sách 3 ) sao cho cuối cùng, g 1 () , g 2 () và g 3 ()
được thực thi.
325
9.1.2 Véc tơ thử nghiệm
Vectơ kiểm tra, còn được gọi là dữ liệu kiểm tra, là một thể hiện của
đầu vào cho một chương trình. Nó là một cấu hình nhất định của các
giá trị của tất cả các biến đầu vào. Giá trị của các biến đầu vào riêng
lẻ được chọn trong các phần trước phải được kết hợp để thu được véc
tơ kiểm tra. Nếu một chương trình có n biến đầu vào var 1 , var 2 , ... ,
var n có thể nhận lần lượt k 1 , k 2 , ... , k n giá trị đặc biệt, thì có k 1 × k
2 × · ·· × k n sự kết hợp có thể có của dữ liệu thử nghiệm.
Ví dụ: Chúng tôi hiển thị số lượng các giá trị đặc biệt của các biến
đầu vào khác nhau của mô-đun FSB của Hình 9.1 trong Bảng 9.1.
Variable MODE nhận các giá trị từ tập rời rạc có kích thước 2 và cả
hai giá trị từ tập rời rạc đều được xem xét. Các biến CLOCK và
MODE nhận các giá trị từ một khoảng thời gian và ba giá trị đặc biệt
cho mỗi giá trị đó được xem xét. Do đó, người ta có thể tạo ra 2 × 3 ×
3 = 18 vectơ thử nghiệm từ Bảng 9.1.
Một số chương trình chấp nhận một số lượng lớn các biến đầu vào.
Hệ thống phần mềm khai thuế là ví dụ của các chương trình như vậy.
Xem xét tất cả các kết hợp có thể có của một vài giá trị đặc biệt của
một số lượng lớn các biến đầu vào là một nhiệm vụ đầy thách thức.
Nếu một chương trình có n biến đầu vào, mỗi biến có thể nhận k giá
trị đặc biệt, thì có k n tổ hợp có thể có của các vectơ kiểm tra. Chúng
ta biết rằng k là một số nhỏ, nhưng n có thể lớn. Chúng ta có hơn một
triệu vectơ kiểm tra ngay cả với k = 3 và n = 20. Do đó, cần phải xác
định một phương pháp để giảm số lượng vectơ kiểm tra thu được
bằng cách xem xét tất cả các kết hợp có thể có của tất cả các bộ giá
trị đặc biệt của đầu vào biến.
Howden đề xuất rằng không cần kết hợp các giá trị của tất cả các
biến đầu vào để thiết kế một vectơ kiểm tra nếu các biến không liên
quan về mặt chức năng. Để giảm số lượng kết hợp đầu vào, Howden
đề nghị [3, 4] rằng chúng tôi tạo ra tất cả các kết hợp có thể có của
các giá trị đặc biệt của các biến nằm trong cùng một tập con có liên
quan về mặt chức năng. Bằng cách này, tổng số tổ hợp các giá trị đặc
biệt của các biến đầu vào bị giảm xuống. Rất khó để đưa ra một định
nghĩa chính thức
BẢNG 9.1 Số lượng giá trị đặc biệt của đầu vào cho mô-đun
FBS của Hình 9.1
Number of
Special
Variable Values (k) Special Values

MODE 2 {23, 79}
CLOCK 3 {0x0000000, 0x000FF00, 0xFFFFFFF}
ADDRES 3 { 0xFFFFF0000000, 0xFFFFF00FFF00,
S 0xFFFFFFFFFFFF}
Functionally
related variables
x1 x1
P
x2 x2 f1
z z
x3 P x3 d
x4 x4 f2
x5 x5
Functionally
related variables
(a) (b)
Hình 9.3 Các biến liên quan về mặt chức năng.
về ý tưởng của các biến liên quan đến chức năng, nhưng rất dễ dàng
để xác định chúng. Chúng ta hãy xem xét các ví dụ sau:
Các biến xuất hiện trong cùng một câu lệnh gán có liên quan về mặt
chức năng.
Các biến xuất hiện trong cùng một vị từ nhánh — ví dụ: phần điều
kiện của câu lệnh if — có liên quan về mặt chức năng.
Ví dụ: Chương trình P trong hình 9.3 a có năm biến đầu vào như x 1 ,
..., x 4 nhận ba giá trị đặc biệt và x 5 là biến Boolean. Tổng số tổ hợp
các giá trị đặc biệt của năm biến đầu vào là 3 4 × 2 = 162. Giả sử rằng
chương trình P có cấu trúc bên trong như thể hiện trong Hình 9.3 b ,
trong đó các biến x 1 và x 2 có liên quan về mặt chức năng và các biến
x 3 và x 4 có liên quan về mặt chức năng. Hàm f 1 sử dụng các biến đầu
vào là x 1 và x 2 . Tương tự, hàm f 2 sử dụng các biến đầu vào là x 3 và
x 4 . Biến đầu vào x 5 được sử dụng để quyết định xem đầu ra của f 1
hay đầu ra của f 2 sẽ là đầu ra của P. Chúng ta coi 3 2 = 9 kết hợp khác
327
nhau của x 1 và x 2 là đầu vào của f 1 , 9 kết hợp khác nhau của x 3 và x
4 làm đầu vào cho f 2 và hai giá trị khác nhau của x 5 vào hộp quyết
định d trong P. Chúng ta cần 36 tổ hợp [ ( 9 + 9 ) × 2] của năm biến
đầu vào x 1 , .. ., x 5 , nhỏ hơn nhiều so với 162.
9.1.3 Kiểm tra một chức năng trong ngữ cảnh
Chúng ta hãy xem xét một chương trình P và một hàm f trong P như
hình 9.4. Biến x là đầu vào cho P và cũng là đầu vào cho f . Giả sử
rằng x có thể nhận các giá trị trong khoảng [ −∞, + ∞ ] và f chỉ được
gọi khi vị từ x ≥ 20
x P
x
x > 20 f
Hình 9.4 Chức năng trong ngữ

cảnh.
nắm giữ. Nếu chúng ta không biết về vị từ x ≥ 20, thì chúng ta có khả
năng chọn tập dữ liệu kiểm tra sau để kiểm tra P:
x = + k, x = −k, x = 0 .
Ở đây, k là số có độ lớn.
Người đọc có thể lưu ý rằng hàm f sẽ được gọi chỉ một lần đối với x
= + k , giả sử rằng k ≥ 20, và nó sẽ không được gọi khi P được chạy
với hai dữ liệu kiểm tra khác vì thực hiện có điều kiện của f . Kiểm
tra hàm f riêng biệt sẽ yêu cầu chúng tôi tạo dữ liệu kiểm tra tương tự
như trên. Có thể lưu ý rằng hai điểm dữ liệu sau là dữ liệu không hợp
lệ vì chúng nằm ngoài phạm vi của x đối với f trong P. Phạm vi hợp
lệ của x đối với f là [20 , + ∞ ] và kiểm tra chức năng trong ngữ cảnh
yêu cầu chúng ta chọn các giá trị sau của x :
x = k trong đó x = y trong đó 20 x = 20
trong đó các ký hiệu được đọc lần lượt là “lớn hơn nhiều”
và “nhỏ hơn nhiều”.
9.2 TÍNH SO SÁNH CỦA VIỆC ÁP DỤNG KIỂM TRA CHỨC
NĂNG
Để có ý tưởng về khó khăn trong việc áp dụng khái niệm kiểm thử
chức năng, chúng ta hãy tóm tắt những điểm chính trong kiểm thử
chức năng như sau:
Xác định các biến đầu vào và đầu ra của chương trình và các miền dữ
liệu của chúng.
Tính toán các kết quả mong đợi như minh họa trong Hình 9.5 a cho
các giá trị đầu vào đã chọn.
Xác định các giá trị đầu vào sẽ khiến chương trình tạo ra các đầu ra
được chọn như minh họa trong Hình 9.5 b .
9.2 TÍNH SO SÁNH CỦA VIỆC ÁP DỤNG KIỂM TRA CHỨC

NĂNG
Input domains Output domains
(a)
Input domains Output domains
(b)
Hình 9.5 ( a ) Nhận các giá trị đầu ra từ một vectơ đầu vào và (
b ) lấy một vectơ đầu vào từ một giá trị đầu ra trong thử nghiệm chức
năng.
Tạo dữ liệu thử nghiệm bằng cách phân tích các miền đầu vào có hai
đặc điểm sau.
Số lượng các trường hợp thử nghiệm thu được từ phân tích các miền
đầu vào có thể là quá nhiều do yêu cầu thiết kế các vectơ thử nghiệm
đại diện cho các kết hợp khác nhau của các giá trị đặc biệt của các
biến đầu vào.
Việc tạo ra đầu ra mong đợi cho một vectơ thử nghiệm nhất định là
tương đối đơn giản. Điều này là do một nhà thiết kế thử nghiệm tính
329
toán kết quả đầu ra mong đợi từ sự hiểu biết và phân tích đặc điểm
kỹ thuật của hệ thống.
Mặt khác, tạo dữ liệu thử nghiệm bằng cách phân tích các miền đầu
ra có các đặc điểm sau:
Số lượng các trường hợp kiểm tra thu được từ phân tích các miền đầu
ra có thể sẽ ít hơn so với cùng một số biến đầu vào vì không cần phải
xem xét các kết hợp khác nhau của các giá trị đặc biệt của các biến
đầu ra.
Việc tạo ra một vectơ đầu vào cần thiết để tạo ra một giá trị đầu ra đã
chọn sẽ yêu cầu chúng ta phân tích đặc điểm kỹ thuật theo hướng
ngược lại, như minh họa trong Hình 9.5 b . Việc phân tích ngược như
vậy sẽ là một nhiệm vụ khó khăn hơn so với việc tính toán một giá trị
mong đợi theo hướng thuận, như được minh họa trong Hình 9.5 a .
Cho đến nay trong phần này chúng ta đã thảo luận về các cách áp
dụng ý tưởng kiểm thử chức năng cho toàn bộ chương trình. Tuy
nhiên, khái niệm cơ bản, tức là phân tích các miền đầu vào và đầu ra
của một chương trình, cũng có thể được áp dụng cho các mô-đun,
chức năng hoặc thậm chí các dòng mã riêng lẻ. Điều này là do mọi
phần tử máy tính có thể được mô tả theo các miền đầu vào và đầu ra
của nó, và do đó ý tưởng về kiểm tra chức năng có thể được áp dụng
cho phần tử máy tính đó.
Tham khảo Hình 9.6, chương trình P được phân tách thành ba mô-
đun M 1 , M 2 và M 3 . Ngoài ra, M 1 là hợp của các hàm f 1 và f 5 , M 2
là bao gồm các hàm f 2 và f 3 , và M 3 là bao gồm các hàm f 4 và f 6 .
Chúng ta có thể áp dụng ý tưởng kiểm tra chức năng cho toàn bộ
chương trình P, các mô-đun riêng lẻ M 1 , M 2 và M 3 , và các chức
năng riêng lẻ f 1 , ..., f 6 bằng cách xem xét các miền đầu vào và đầu ra
tương ứng của chúng như được liệt kê trong Bảng 9.2.
x1 P
M1
f1 y1
x2 f5
x3 y5
x4 f2 z
f6
y4
y2 y3 y6
f4
f3 M3
M2 Figure9.6 Functionaltesting
ingeneral.
BẢNG 9.2 Các miền đầu vào và đầu ra của các chức năng của
P trong Hình 9.6
Tên thực thể Biến đầu vào Biến đầu ra
P {x 1 , x 2 , x 3 , { z }
x 4}
M1 {x 1 , x 2 } {y 5 }
M2 {x 3 , x 4 } {y 4 }
M3 {năm 4 , năm 5 { z }
}
f1 {x 1 , x 2 } {y 1 }
f2 {x 3 , x 4 , y 3 } {y 2 , y 4 }
f3 {y 2 } {y 3 }
f4 {y 4 } {y 6 }
f5 {y 1 } {y 5 }
f6 {năm 5 , năm 6 { z }
}
Về mặt khái niệm, người ta có thể áp dụng kiểm thử chức năng ở bất
kỳ mức độ trừu tượng nào, từ một dòng mã duy nhất ở mức thấp nhất
đến toàn bộ chương trình ở mức cao nhất. Khi chúng ta xem xét các
mô-đun, chức năng và dòng mã riêng lẻ, nhiệm vụ xác định chính
xác các miền đầu vào và đầu ra của phần tử máy tính được kiểm tra
trở nên khó khăn hơn.
Phương pháp luận để phát triển các ca kiểm thử chức năng là một
quá trình phân tích phân tích đặc tả của một chương trình thành các
lớp hành vi khác nhau. Các trường hợp kiểm thử chức năng được
thiết kế cho từng lớp riêng biệt bằng cách xác định các miền đầu vào
331
và đầu ra của lớp. Việc xác định các miền đầu vào và đầu ra giúp
phân loại đặc tả thành các lớp khác nhau. Tuy nhiên, trong thực tế,
tổng số kết hợp đầu vào và đầu ra có thể rất lớn. Một số kỹ thuật nổi
tiếng có sẵn để giải quyết vấn đề này, chúng ta sẽ thảo luận trong các
phần sau.
9.3 KIỂM TRA CẶP
Thử nghiệm theo cặp là một trường hợp đặc biệt của thử nghiệm kết
hợp tất cả của một hệ thống có n biến đầu vào. Chúng ta hãy xem xét
n biến đầu vào ký hiệu là {v 1 , v 2 , ..., v i , ..., v n } . Để đơn giản, giả
sử rằng với mỗi biến v i , 1 ≤ i ≤ n , chúng ta chọn k giá trị quan tâm.
Kiểm tra kết hợp tất cả có nghĩa là xem xét tất cả k n vectơ kiểm tra
khác nhau. Mặt khác, kiểm tra theo cặp có nghĩa là mỗi tổ hợp giá trị
có thể có cho mỗi cặp biến đầu vào được bao phủ bởi ít nhất một
trường hợp kiểm tra. Thử nghiệm theo cặp yêu cầu một tập hợp con
các trường hợp thử nghiệm (vectơ) bao gồm tất cả các kết hợp theo
cặp giá trị thay vì tất cả các kết hợp giá trị có thể có của một tập hợp
các biến.
Thử nghiệm theo cặp còn được gọi là thử nghiệm tất cả các cặp / hai
chiều. Người ta cũng có thể tạo các bài kiểm tra ba bốn chiều hoặc 4
chiều để bao hàm tất cả các tổ hợp giá trị của ba hoặc bốn biến. Khi
tất cả các tổ hợp giá trị của ngày càng nhiều biến (ví dụ: 2, 3, 4, ... )
được xem xét, kích thước của bộ thử nghiệm tăng lên nhanh chóng.
Kết quả thực nghiệm [5] đối với các thiết bị y tế và hệ thống cơ sở dữ
liệu phân tán cho thấy rằng kiểm tra hai chiều sẽ phát hiện nhiều hơn
90% các khuyết tật, trong khi kiểm tra bốn chiều sẽ phát hiện 100%
các khuyết tật. Kiểm tra theo cặp sẽ phát hiện khoảng 70% lỗi, trong
khi kiểm tra sáu chiều sẽ phát hiện 100% lỗi cho các ứng dụng trình
duyệt và máy chủ.
Hãy xem xét hệ thống S trong Hình 9.7, có ba biến đầu vào X , Y và
Z. Gọi ký hiệu D (w) biểu thị tập giá trị của một biến w tùy ý . Đối
với ba biến X , Y và Z đã cho, tập giá trị của chúng như sau: D (X) =
{ True , False } , D (Y) = { 0 , 5 } và D (Z) = {Q, R} . Tổng số của
x y z
System S
Hình 9.7 Hệ thống S với ba biến đầu vào.
BẢNG 9.3 Các trường hợp kiểm tra theo cặp cho Hệ thống S
ID trường Đầu
Đầu vào
hợp thử Nhập Y vào
X
nghiệm Z
TC 1 ĐÚNG 0 Q
VẬY
TC 2 ĐÚNG 5 R
VẬY
TC 3 Sai 0 Q
TC 4 Sai 5 R
tất cả các trường hợp thử nghiệm kết hợp là 2 × 2 × 2 = 8. Tuy nhiên,
một tập hợp con của bốn trường hợp thử nghiệm, như được thể hiện
trong Bảng 9.3, bao gồm tất cả các kết hợp theo cặp. Các chiến lược
tạo thử nghiệm khác nhau để thử nghiệm theo cặp đã được báo cáo
trong tài liệu [6]. Trong phần này, hai kỹ thuật phổ biến, cụ thể là
mảng trực giao (OA) [7] và theo thứ tự tham số (IPO) [8], sẽ được
thảo luận.
9.3.1 Mảng trực giao
Mảng trực giao ban đầu được các nhà sư nghiên cứu như một dạng
số học tò mò [9]. Nó đã được CR Rao, một nhà thống kê, nghiên cứu
thêm vào cuối những năm 1940, [10]. Genichi Taguchi lần đầu tiên
sử dụng ý tưởng về mảng trực giao trong thiết kế thử nghiệm của
mình về quản lý chất lượng tổng thể (TQM) [11]. Phương pháp, được
gọi là phương pháp Taguchi, đã được sử dụng trong thiết kế thử
nghiệm trong lĩnh vực sản xuất và cung cấp một cách hiệu quả và có
hệ thống để tối ưu hóa các thiết kế về hiệu suất, chất lượng và chi
phí. Nó đã được sử dụng thành công ở Nhật Bản và Hoa Kỳ trong
việc thiết kế các sản phẩm chất lượng cao, đáng tin cậy với chi phí
thấp trong ngành công nghiệp ô tô và điện tử tiêu dùng. Mandl là
người đầu tiên sử dụng khái niệm mảng trực giao trong việc thiết kế
các trường hợp kiểm thử để kiểm tra từng cặp trình biên dịch [12].
333
Chúng ta hãy xem xét mảng hai chiều các số nguyên được hiển thị
trong Bảng 9.4. Mảng có một thuộc tính thú vị: Chọn ngẫu nhiên hai
cột bất kỳ và tìm tất cả các cặp (1,1), (1,2), (2,1), và (2,2); tuy nhiên,
không phải tất cả các kết hợp của 1 và 2 đều xuất hiện trong bảng. Ví
dụ, (2,2,2) là một kết hợp hợp lệ, nhưng nó không có trong bảng. Chỉ
có bốn trong số tám kết hợp có thể được tìm thấy trong bảng. Đây là
một ví dụ về mảng trực giao L 4 ( 2 3 ) . 4 chỉ ra rằng mảng có bốn
hàng, còn được gọi là số chạy. Phần 2 3 chỉ ra rằng mảng có ba cột,
đã biết
BẢNG 9.4 L 4 (2 3 ) Mảng trực giao
Các nhân tố
Chạy 1 2 3
1 1 1 1
2 1 2 2
3 2 1 2
4 2 2 1
BẢNG 9.5 Mảng trực giao thường được sử dụng
Số lượng tối đa
Số cột tối đa ở các cấp độ này Trực giao Số lượng Số lượng
Array RunsFactors2345
dưới dạng các yếu tố và mỗi ô trong mảng chứa hai giá trị khác nhau,
được gọi là mức. Mức có nghĩa là số lượng giá trị tối đa mà một yếu
tố duy nhất có thể đảm nhận. Số cột tối đa ở cấp 1 và 2 tương ứng là
0 và 3. Mảng trực giao thường được biểu thị bằng mẫu L Chạy ( Hệ số
mức ) . Các mảng trực giao thường được sử dụng được cho trong
Bảng 9.5.
Chúng ta hãy xem xét ví dụ trước của chúng ta về hệ thống S , trong
đó S có ba biến đầu vào X , Y và Z. Đối với ba biến X , Y và Z đã
cho, tập giá trị của chúng như sau: D (X) = { True , False } , D (Y) =
{ 0 , 5 } và D (Z) = {Q, R} .
Chúng ta hãy ánh xạ các biến với các yếu tố và giá trị đến các mức
vào mảng trực giao L 4 ( 2 3 ) (Bảng 9.4) với kết quả trong Bảng 9.3.
Trong cột đầu tiên, cho 1 = Đúng , 2 = Sai. Trong cột thứ hai, cho 1 =
0 , 2 = 5. Trong cột thứ ba, cho 1 = Q, 2 = R. Lưu ý rằng không phải
tất cả các kết hợp của tất cả các biến đã được chọn; thay vào đó, sự
kết hợp của tất cả các cặp biến đầu vào đã được bao gồm trong bốn
trường hợp thử nghiệm. Từ ví dụ trên, rõ ràng là các mảng trực giao
cung cấp một kỹ thuật để chọn một tập hợp con các trường hợp thử
nghiệm với các thuộc tính sau:
Kỹ thuật này đảm bảo kiểm tra sự kết hợp từng cặp của tất cả các
biến đã chọn.
335
Kỹ thuật này tạo ra ít trường hợp thử nghiệm hơn so với phương
pháp kết hợp tất cả.
Kỹ thuật này tạo ra một bộ thử nghiệm có sự phân bố đồng đều của
tất cả các kết hợp theo cặp.
Kỹ thuật này có thể được tự động hóa.
Sau đây, các bước của kỹ thuật tạo mảng trực giao được trình bày.
Các bước được giải thích thêm bằng một ví dụ chi tiết.
Bước Xác định số lượng biến đầu vào độc lập tối đa mà hệ thống
1: sẽ được kiểm tra. Điều này sẽ ánh xạ đến các yếu tố của
mảng — mỗi biến đầu vào ánh xạ tới một yếu tố khác nhau.
Bước Xác định số lượng giá trị lớn nhất mà mỗi biến độc lập sẽ
2: nhận. Điều này sẽ ánh xạ đến các cấp của mảng.
Bước Tìm một mảng trực giao phù hợp với số lần chạy nhỏ nhất L
3: Chạy (X
Y
) , trong đó X là số cấp và Y là số thừa số [7, 13].
Mảng phù hợp là mảng có ít nhất bao nhiêu yếu tố cần thiết
từ bước 1 và có ít nhất bao nhiêu cấp độ cho mỗi yếu tố đó
như đã xác định ở bước 2.
Bước Ánh xạ các biến với các yếu tố và giá trị của từng biến với
4: các mức trên mảng.
Bước Kiểm tra xem có bất kỳ mức “dư thừa” nào trong mảng chưa
5: được ánh xạ hay không. Chọn các giá trị hợp lệ tùy ý cho
các cấp còn lại đó.
Bước Chuyển biên các lần chạy thành các trường hợp thử nghiệm.
6:
Ví dụ về Web. Hãy xem xét một trang web được xem trên một số
trình duyệt với nhiều trình cắm và hệ điều hành (OS) khác nhau và
thông qua các kết nối khác nhau như trong Bảng 9.6. Bảng hiển thị
các biến và giá trị của chúng được sử dụng làm phần tử của mảng
trực giao. Chúng ta cần kiểm tra hệ thống với các kết hợp khác nhau
của các giá trị đầu vào.
Theo các bước đã trình bày trước đó, chúng ta hãy thiết kế một
mảng để tạo một tập hợp các trường hợp thử nghiệm để thử nghiệm
theo cặp:
Bước 1: Có bốn biến độc lập, đó là Trình duyệt, Trình cắm, Hệ
điều hành và Kết nối.
Bước 2: Mỗi biến có thể nhận nhiều nhất ba giá trị.
BẢNG 9.6 Các giá trị khác nhau cần được kiểm tra trong các
kết hợp
Biến Giá trị
Trình duyệt Netscape, Internet Explorer
(IE), Mozilla
Cắm vào Realplayer, Mediaplayer
Hệ điều hành Windows, Linux, Macintosh
Sự liên quan LAN, PPP, ISDN
Lưu ý: Mạng LAN, mạng cục bộ; PPP, Giao thức điểm-điểm; ISDN,
Mạng kỹ thuật số dịch vụ tích hợp.
BẢNG 9.7 L 9 (3 4 ) Mảng trực giao
Các
nhân tố
Chạy 1 2 3 4
1 1 1 1 1
2 1 2 2 2
3 1 3 3 3
4 2 1 2 3
5 2 2 3 1
6 2 3 1 2
7 3 1 3 2
số 8 3 2 1 3
9 3 3 2 1
Bước Mảng trực giao L 9 ( 3 4 ) như trong Bảng 9.7 là đủ tốt cho mục
3: đích này. Mảng có chín hàng, ba cấp cho các giá trị và bốn nhân
tố cho các biến.
Bước Ánh xạ các biến với các yếu tố và giá trị theo các cấp của mảng:
4: yếu tố 1 với Trình duyệt, yếu tố 2 với Trình cắm, yếu tố 3 với
Hệ điều hành và yếu tố 4 với Kết nối. Đặt 1 = Netscape, 2 = IE
và 3 = Mozilla trong cột Trình duyệt. Trong cột Trình cắm, cho
1 = Realplayer và 3 = Mediaplayer. Đặt 1 = Windows, 2 = Linux
và 3 = Macintosh trong cột OS. Đặt 1 = LAN, 2 = PPP và 3 =
337
ISDN trong cột Kết nối. Ánh xạ của các biến và giá trị vào mảng
trực giao được cho trong Bảng 9.8.
Bước Có các mức còn lại trong mảng không được ánh xạ. Yếu tố 2 có
5: ba mức được chỉ định trong mảng ban đầu, nhưng chỉ có hai giá
trị có thể có cho biến này. Điều này đã làm cho mức (2) bị bỏ lại
BẢNG 9.8 L 9 (3 4 ) Mảng trực giao sau các yếu tố ánh xạ
ID trường
Trình Hệ điều Sự liên
hợp thử Cắm vào
duyệt hành quan
nghiệm
TC 1 Netscape Realplayer các cửa sổ LAN
TC 2 Netscape 2 Linux PPP
TC 3 Netscape Mediaplaye Macintosh ISDN
r
TC 4 IE Realplayer Linux ISDN
TC 5 IE 2 Macintosh LAN
TC 6 IE Media các cửa sổ PPP
Player
TC 7 Mozilla Realplayer Macintosh PPP
TC 8 Mozilla 2 các cửa sổ ISDN
TC 9 Mozilla Media Linux LAN
Player
BẢNG 9.9 Các trường hợp thử nghiệm được tạo sau khi ánh
xạ các mức còn thừa
ID trường
Trình Hệ điều Sự liên
hợp thử Cắm vào
duyệt hành quan
nghiệm
TC 1 Netscape Realplayer các cửa sổ LAN
TC 2 Netscape Realplayer Linux PPP
TC 3 Netscape Media Macintosh ISDN
Player
TC 4 IE Realplayer Linux ISDN
TC 5 IE Media Macintosh LAN
Player
TC 6 IE Media các cửa sổ PPP
Player
TC 7 Mozilla Realplayer Macintosh PPP
TC 8 Mozilla Realplayer các cửa sổ ISDN
TC 9 Mozilla Media Linux LAN
Player
cho Plug-in biến sau khi ánh xạ các yếu tố. Người ta phải cung cấp
một giá trị trong ô. Việc lựa chọn giá trị này có thể tùy ý, nhưng để
có phạm vi phù hợp, hãy bắt đầu ở đầu cột Trình cắm và chuyển qua
các giá trị có thể có khi điền vào các cấp còn lại. Bảng 9.9 cho thấy
ánh xạ sau khi điền vào các mức còn lại bằng cách sử dụng kỹ thuật
đi xe đạp đã đề cập.
Bước 6: Chúng tôi tạo chín trường hợp thử nghiệm lấy các giá trị
trường hợp thử nghiệm từ mỗi lần chạy. Bây giờ chúng ta hãy kiểm
tra kết quả:
• Mỗi Trình duyệt được kiểm tra với mọi Trình cắm, với mọi Hệ điều
hành và với mọi Kết nối. • Mỗi Trình cắm được kiểm tra với mọi
Trình duyệt, với mọi Hệ điều hành và với mọi Kết nối. • Mỗi hệ điều
hành được kiểm tra với mọi Trình duyệt, với mọi Trình cắm và với
mọi Kết nối. • Mỗi Kết nối được kiểm tra với mọi Trình duyệt, với
mọi Trình cắm và với mọi Hệ điều hành.
9.3.2 Theo thứ tự tham số
Tai và Lei [8] đã đưa ra một thuật toán được gọi theo thứ tự tham số
(IPO) để tạo ra một bộ thử nghiệm cho phạm vi bao phủ của các biến
đầu vào. Thuật toán tạo ra một bộ thử nghiệm đáp ứng phạm vi bao
phủ theo cặp cho các giá trị của hai tham số đầu tiên. Sau đó, bộ thử
nghiệm được mở rộng bởi thuật toán để đáp ứng phạm vi phủ sóng
theo cặp đối với các giá trị của tham số thứ ba và tiếp tục làm như
vậy đối với các giá trị của từng tham số bổ sung cho đến khi tất cả
các tham số được bao gồm trong bộ thử nghiệm.
Thuật toán chạy trong ba giai đoạn, đó là khởi tạo, tăng trưởng theo
chiều ngang và tăng trưởng theo chiều dọc, theo thứ tự đó. Trong giai
đoạn khởi tạo, các trường hợp kiểm thử được tạo ra để bao hàm hai
biến đầu vào. Trong giai đoạn tăng trưởng theo chiều ngang, các
trường hợp thử nghiệm hiện có được mở rộng với các giá trị của các
biến đầu vào khác. Trong giai đoạn tăng trưởng theo chiều dọc, các
trường hợp thử nghiệm bổ sung được tạo ra sao cho bộ thử nghiệm
339
đáp ứng phạm vi bao phủ theo từng cặp cho các giá trị của các biến
mới. Để sử dụng các kỹ thuật tạo thử nghiệm IPO, người ta có thể
làm theo các bước được mô tả bên dưới. Giả sử rằng có n số biến ký
hiệu là {p i | 1 ≤ i ≤ n} và dấu gạch ngang biểu thị giá trị không xác
định của một biến.
Thuật toán: Theo thứ tự tham số
Đầu vào: Tham số p i và miền của nó D (p i ) = {v 1 , v 2 , ..., v q } ,
trong đó i = 1 , ..., n .
Đầu ra: Một bộ thử nghiệm T đáp ứng phạm vi bảo hiểm theo từng
cặp.
Giai đoạn khởi tạo:
Bước 1: Đối với hai tham số đầu tiên p 1 và p 2 , tạo bộ thử
nghiệm
T : = {(v 1 , v 2 ) | v 1 và v 2 lần lượt là giá trị của p 1 và p 2 }
Bước 2: Nếu i = 2 thì dừng lại. Ngược lại, với i = 3 , 4 , ..., n
lặp lại bước 3 và 4 .
Giai đoạn tăng trưởng theo chiều ngang:
Bước 3: Cho D (p i ) = {v 1 , v 2 , ..., v q } . Tạo một tập hợp
π i : = { cặp giá trị của p i và tất cả các giá trị của p 1 , p 2 , ..., p i - 1 }
Nếu | T | ≤ q, sau đó
{với 1 ≤ j ≤ | T |, mở rộng phép thử thứ j trong T bằng cách thêm các
giá trị v j và loại bỏ khỏi cặp π i được phép thử mở rộng}
khác
{với 1 ≤ j ≤ q, mở rộng phép thử thứ j trong T bằng cách thêm giá trị
v j và loại bỏ khỏi cặp π i được phép thử mở rộng;
đối với q <j ≤ | T |, hãy mở rộng phép thử thứ j trong T bằng cách
thêm một giá trị của p i sao cho phép thử kết quả bao gồm nhiều cặp
nhất trong π i và loại bỏ khỏi cặp π i trong phép thử mở rộng};
Giai đoạn tăng trưởng theo chiều dọc:
Bước 4: Cho (tập rỗng) và | π i |> 0;
cho mỗi cặp trong π i (cho các cặp chứa giá trị w của p k , 1 ≤ k <i và
giá trị u của p i )
{
nếu (T chứa một kiểm tra với — là giá trị của p k và u là giá trị của p
i)
sửa đổi kiểm tra này bằng cách thay thế — bằng w; khác
thêm một bài kiểm tra mới vào T có w là giá trị của p k , u là giá trị
của p i và — là giá trị của mọi tham số khác;
};
T: = T ;
Các trường hợp thử nghiệm có thể chứa - các giá trị sau khi tạo bộ
thử nghiệm T. Nếu p i là tham số cuối cùng, mỗi - giá trị p k , 1 ≤ k ≤ i
, được thay thế bằng bất kỳ giá trị nào của p k . Nếu không, các - giá
trị này được thay thế bằng các giá trị tham số trong giai đoạn tăng
trưởng ngang cho p i + 1 như sau: Giả sử rằng giá trị v của p i + 1
được chọn cho sự tăng trưởng theo chiều ngang của một phép thử có
chứa - là giá trị của p k , 1 ≤ k ≤ i . Nếu có các cặp được phát hiện liên
quan đến v và một số giá trị của p k , thì - đối với p k được thay thế
bằng một trong các giá trị này của p k . Nếu không, dấu - cho p k được
thay thế bằng bất kỳ giá trị nào của p k .
Ví dụ: Hãy xem xét hệ thống S trong Hình 9.7 có ba tham số đầu vào
X , Y và Z. Giả sử rằng tập hợp D , tập hợp các giá trị dữ liệu kiểm
tra đầu vào, đã được chọn cho mỗi biến đầu vào sao cho D (X) = {
True , False } , D (Y) = { 0 , 5 } và D (Z) = {P, Q, R} . Tổng số
trường hợp thử nghiệm có thể có là 2 × 2 × 3 = 12, nhưng thuật toán
IPO tạo ra sáu trường hợp thử nghiệm. Hãy để chúng tôi áp dụng
bước 1 của thuật toán.
Bước 1: Tạo một bộ thử nghiệm bao gồm bốn trường hợp thử
nghiệm với phạm vi bảo vệ từng cặp cho hai tham số đầu tiên X và Y
:
Bước i = 3 > 2; do đó, bước 2 và 3 phải được thực hiện.

2:
Bước Bây giờ D (Z) = {X, YP, Q, R} , là } . Tạo tập hợp π 3: = {
3: cặp giá trị của Z và giá trị của
Vì Z có ba giá trị nên ta có q = 3 và | T | = 4 > q = 3. Chúng tôi đã

mở rộng ( Đúng , 0 ), ( Đúng , 5 ) và ( Sai , 0 ) bằng cách thêm P, Q
341
và R tương ứng. Tiếp theo, chúng tôi loại bỏ các cặp ( Đúng , P) , (
Đúng , Q) , ( Sai , R) , ( 0 , P) , ( 5 , Q) và ( 0 , R) khỏi tập π 3 vì các
cặp này được bao phủ bởi bộ thử nghiệm mở rộng một phần. Bộ thử
nghiệm mở rộng T và π 3
trở thành
P) Q) ⎤ R) )
⎥⎥⎦
,
( Sai , Q) ( Đúng ,
( 0 , Q) R) ⎤
( 5 , R) ⎥⎥⎦
Bây giờ chúng ta cần chọn một trong P , Q và R cho ( Sai , 5 ) . Nếu
chúng ta thêm P vào ( Sai , 5 ) , phép thử mở rộng ( Sai , 5 , P) bao
hàm hai cặp còn thiếu ( Sai , P) và ( 5 , P) . Nếu chúng ta thêm Q vào
( Sai , 5 ) thì phép thử mở rộng ( Sai , 5 , Q) chỉ bao gồm một cặp còn
thiếu ( Sai , Q) . Nếu chúng ta thêm R vào ( Sai , 5 ) , phép thử mở
rộng ( Sai , 5 , R) chỉ bao gồm một cặp còn thiếu ( 5 , R) . Do đó,
thuật toán sẽ chọn ( Sai , 5 , P) làm trường hợp thử nghiệm thứ tư.
Loại bỏ các cặp ( Sai , P) và ( 5 , P) khỏi tập π 3 vì các cặp này được
bao phủ bởi bộ thử nghiệm mở rộng một phần. Bây giờ bộ thử
nghiệm mở rộng T và π 3 trở thành
Cho đến nay các thử nghiệm trong T vẫn chưa bao gồm bốn thử
nghiệm trong π 3 , đó là, ( Đúng , R) , ( Sai , Q) , ( 0 , Q) và ( 5 , R) .
Bước 4: Thuật toán sẽ tạo ra một tập hợp
từ hai cặp π 3 đầu tiên , đó là ( Đúng , R)
và ( Sai , Q) . Thuật toán thay đổi trường hợp thử nghiệm ( Sai , - ,
Q) thành ( Sai , 0 , Q) mà không thêm một trường hợp thử nghiệm
mới để bao hàm cặp tiếp theo ( 0 , Q) . Thuật toán sửa đổi trường hợp
thử nghiệm ( Đúng , - , R) thành ( Đúng , 5 , R) mà không thêm bất
kỳ trường hợp thử nghiệm mới nào để có thể bao hàm cặp ( 5 , R) .
Union tạo sáu trường hợp kiểm tra theo cặp như sau:
( Đún 0 , P) Q) ⎤
g , ( 5 , R) P)
Đ úng , 0 , Q) R)
5 , ⎥⎥⎥⎥⎥⎥⎦
0,
, 5,
9.4 THAM GIA LỚP TƯƠNG ĐƯƠNG
Miền đầu vào có thể quá lớn để tất cả các phần tử của nó được sử
dụng làm đầu vào kiểm tra (Hình 9.8 a ). Tuy nhiên, miền đầu vào có
thể được phân vùng thành một số miền phụ hữu hạn để chọn đầu vào
kiểm tra. Mỗi miền con được gọi là một lớp tương đương (EC) và nó
đóng vai trò là nguồn của ít nhất một đầu vào thử nghiệm (Hình 9.8 b
). Mục tiêu của phân vùng tương đương là chia miền đầu vào của hệ
thống đang được kiểm tra thành các lớp hoặc nhóm, các đầu vào. Tất
cả các đầu vào trong cùng một lớp có ảnh hưởng tương tự đến hệ
thống đang được thử nghiệm [14, 15]. EC là một tập hợp các đầu vào
mà hệ thống xử lý giống nhau khi hệ thống được kiểm tra. Nó đại
diện cho các điều kiện hoặc vị từ nhất định trên miền đầu vào. Điều
kiện đầu vào trên miền đầu vào là một vị từ trên các giá trị của miền
đầu vào. Đầu vào hợp lệ cho hệ thống là một phần tử của miền đầu
vào được mong đợi trả về giá trị nonerror. Đầu vào không hợp lệ là
đầu vào được mong đợi trả về giá trị lỗi. Các điều kiện đầu vào được
sử dụng để phân vùng đầu vào thành các EC với mục đích chọn đầu
vào.
Hướng dẫn cho các lớp Tương đương Phân vùng EC có thể được
lấy từ miền đầu vào bằng kỹ thuật heuristic. Người ta có thể ước
lượng các EC bằng cách xác định các lớp mà các hành vi chương
trình khác nhau được chỉ định. Việc xác định các EC trở nên dễ dàng
hơn với kinh nghiệm. Myers đề xuất các hướng dẫn sau để xác định
EC [16].
Điều kiện đầu vào chỉ định một phạm vi [a, b]: Xác định một EC cho
a ≤ X ≤ b và hai lớp khác cho X <a và X> b để kiểm tra hệ thống với
các đầu vào không hợp lệ.
Điều kiện đầu vào chỉ định một tập hợp các giá trị: Tạo một EC cho
mỗi phần tử của tập hợp và một EC cho một phần tử không hợp lệ.
343
Ví dụ: nếu đầu vào được chọn từ tập hợp N mục, thì N + 1 EC sẽ
được tạo:
(i) một EC cho mỗi phần tử của tập {M 1 }, {M 2 }, ..., {M N } và (ii)
một EC cho các phần tử bên ngoài tập {M 1 , M 2 , ... , M N } .
Điều kiện đầu vào chỉ định cho từng giá trị riêng lẻ: Nếu hệ thống xử
lý từng đầu vào hợp lệ khác nhau, thì hãy tạo một EC cho mỗi đầu
vào hợp lệ. Vì
4
3
(a) Miền đầu vào (b) Miền đầu vào được phân vùng
thành bốn miền phụ
Hình 9.8 (a) Quá nhiều đầu vào kiểm tra; (b) một đầu vào được
chọn từ mỗi miền phụ.
9.4 THAM GIA LỚP TƯƠNG ĐƯƠNG

ví dụ, nếu đầu vào là từ một menu, thì hãy tạo một EC cho mỗi mục
menu.
Điều kiện đầu vào chỉ định số lượng giá trị hợp lệ (giả sử N ): Tạo
một EC cho số lượng đầu vào chính xác và hai EC cho các đầu vào
không hợp lệ — một cho giá trị 0 và một cho nhiều hơn N giá trị. Ví
dụ: nếu một chương trình có thể chấp nhận 100 số tự nhiên để sắp
xếp, thì ba EC sẽ được tạo: (i) một cho 100 đầu vào hợp lệ của số tự
nhiên, (ii) một cho không có giá trị đầu vào và (iii) một cho hơn 100
số tự nhiên.
Điều kiện đầu vào chỉ định giá trị “phải có”: Tạo một EC cho giá trị
phải có và một EC cho giá trị không phải là giá trị phải có. Ví dụ:
nếu ký tự đầu tiên của mật khẩu phải là ký tự số, thì chúng tôi bắt
buộc phải tạo hai EC: (i) một cho các giá trị hợp lệ, { pswd | ký tự
đầu tiên của pswd có giá trị số } và (ii) một ký tự cho các giá trị
không hợp lệ, { pswd | ký tự đầu tiên của pswd không phải là số } .
Tách EC: Nếu các phần tử trong EC được phân vùng được hệ thống
xử lý khác nhau, thì hãy chia EC thành các EC nhỏ hơn.
Nhận dạng các trường hợp thử nghiệm từ các EC Sau khi xác
định các EC của miền đầu vào của một chương trình, các trường hợp
thử nghiệm cho mỗi EC có thể được xác định bằng cách sau:
Bước 1: Chỉ định một số duy nhất cho mỗi EC.
Bước 2: Đối với mỗi EC có đầu vào hợp lệ chưa được bao gồm trong
các trường hợp thử nghiệm, hãy viết một trường hợp thử nghiệm mới
bao gồm càng nhiều EC được phát hiện càng tốt.
Bước 3: Đối với mỗi EC có đầu vào không hợp lệ chưa được bao
gồm trong các trường hợp thử nghiệm, hãy viết một trường hợp thử
nghiệm mới bao gồm một và chỉ một trong số các EC chưa được đề
cập.
Tóm lại, các ưu điểm của phân vùng EC như sau:
Một số lượng nhỏ các trường hợp thử nghiệm là cần thiết để bao phủ
đầy đủ một miền đầu vào lớn.
Người ta có một ý tưởng tốt hơn về miền đầu vào được bao phủ với
các trường hợp thử nghiệm đã chọn.
Xác suất phát hiện ra các khuyết tật với các trường hợp thử nghiệm
đã chọn dựa trên phân vùng EC cao hơn so với một bộ thử nghiệm
được chọn ngẫu nhiên có cùng kích thước.
Cách tiếp cận phân vùng của EC không chỉ giới hạn ở các điều kiện
đầu vào; kỹ thuật này cũng có thể được sử dụng cho các miền đầu ra.
Ví dụ: Tổng thu nhập đã điều chỉnh. Hãy xem xét một hệ thống
phần mềm tính thuế thu nhập dựa trên tổng thu nhập đã điều chỉnh
(AGI) theo các quy tắc sau:
Nếu AGI từ $ 1 đến $ 29.500, thuế phải trả là 22% AGI.
Nếu AGI từ $ 29.501 đến $ 58.500, thuế phải trả là 27% AGI.
Nếu AGI từ 58,501 đô la đến 100 tỷ đô la, thuế phải trả là 36% AGI.
BẢNG 9.10 Các trường hợp thử nghiệm đã tạo để bao gồm
từng loại tương đương
Trường hợp Hạng tương
thử nghiệm đương
Con số Bài kiểm tra Kết quả mong đợi Đang được
giá trị thử nghiệm
TC 1 $ 22,000 $ 4,840 EC1
TC 2 $ 46,000 $ 12.420 EC3
TC 3 68.000 đô la $ 24.480 EC4
345
TC 4 -20.000 đô la Bị từ chối với một thông EC2
báo lỗi
TC 5 150 tỷ đô la Bị từ chối với một thông EC5
báo lỗi
Trong trường hợp này, miền đầu vào là từ $ 1 đến $ 100 tỷ. Có ba
điều kiện đầu vào trong ví dụ:
1 đô la ≤ AGI ≤ 29.500 đô la.
29.501 đô la ≤ AGI ≤ 58.500 đô la.
58,501 đô la ≤ AGI ≤ 100 tỷ đô la.
Đầu tiên, chúng tôi xem xét điều kiện 1, cụ thể là, 1 đô la ≤ AGI ≤
29.500 đô la, để tính được hai EC:
EC1: 1 đô la ≤ AGI ≤ 29.500 đô la; đầu vào hợp lệ.
EC2: AGI < 1; đâu vao không hợp lệ.
Sau đó, chúng tôi xem xét điều kiện 2, cụ thể là 29.501 đô la ≤ AGI ≤
58.500 đô la, để tính được một EC:
EC3: 29.501 đô la ≤ AGI ≤ 58.500 đô la; đầu vào hợp lệ.
Cuối cùng, chúng tôi xem xét điều kiện 3, cụ thể là 58.501 đô la ≤
AGI ≤ 100 tỷ đô la, để tính ra hai EC:
EC4: 58,501 đô la ≤ AGI ≤ 100 tỷ đô la; đầu vào hợp lệ.
EC5: AGI > 100 tỷ USD; đâu vao không hợp lệ.
Lưu ý rằng mỗi điều kiện được xem xét một cách riêng biệt trong
nguồn gốc của EC. Các điều kiện không được kết hợp để chọn EC.
Năm trường hợp thử nghiệm được tạo ra để bao gồm năm EC, như
được thể hiện trong Bảng 9.10.
Trong kỹ thuật phân vùng EC, một đầu vào thử nghiệm duy nhất
được chọn tùy ý để bao gồm một EC cụ thể. Chúng ta cần tạo đầu
vào thử nghiệm cụ thể bằng cách xem xét các điểm cực trị, bên trong
hoặc bên ngoài các phân vùng EC đã xác định. Điều này dẫn chúng
ta đến kỹ thuật tiếp theo, được gọi là phân tích giá trị ranh giới, tập
trung vào ranh giới của các EC để xác định các đầu vào thử nghiệm.
9.5 PHÂN TÍCH GIÁ TRỊ CƠ BẢN
Ý tưởng trung tâm trong phân tích giá trị ranh giới (BVA) là chọn dữ
liệu thử nghiệm gần ranh giới của miền dữ liệu để dữ liệu cả bên
trong và bên ngoài EC đều được chọn.
9.5 PHÂN TÍCH GIÁ TRỊ CƠ BẢN
Nó tạo ra các đầu vào kiểm tra gần các ranh giới để tìm ra các lỗi do
việc thực hiện các ranh giới không chính xác. Điều kiện biên là các
vị từ áp dụng trực tiếp trên và xung quanh ranh giới của EC đầu vào
và EC đầu ra. Trong thực tế, các nhà thiết kế và lập trình có xu
hướng bỏ qua các điều kiện biên. Do đó, các khuyết tật có xu hướng
tập trung gần ranh giới giữa các EC. Do đó, dữ liệu thử nghiệm được
chọn trên hoặc gần một ranh giới. Theo nghĩa đó, kỹ thuật BVA là sự
mở rộng và cải tiến của kỹ thuật phân vùng EC [17]. Trong kỹ thuật
BVA, các điều kiện biên cho mỗi EC được phân tích để tạo ra các
Hướng dẫn về BVA Như trong trường hợp phân vùng EC, khả năng
phát triển các trường hợp thử nghiệm hiệu quả chất lượng cao bằng
cách sử dụng BVA đòi hỏi kinh nghiệm. Các hướng dẫn thảo luận
dưới đây có thể áp dụng cho cả điều kiện đầu vào và điều kiện đầu
ra. Các điều kiện hữu ích trong việc xác định các trường hợp kiểm
thử chất lượng cao. Bằng các trường hợp thử nghiệm chất lượng cao,
chúng tôi muốn nói đến các trường hợp thử nghiệm có thể tiết lộ các
khiếm khuyết trong một chương trình.
EC chỉ định một phạm vi: Nếu một EC chỉ định một phạm vi giá trị,
thì hãy xây dựng các trường hợp thử nghiệm bằng cách xem xét các
điểm biên của phạm vi và các điểm ngay ngoài
ranh giới của phạm vi. Ví dụ, hãy để một EC
chỉ định phạm vi ≤ X ≤ 10 . 0. Điều này sẽ dẫn đến dữ liệu thử
nghiệm
{- 9 . 9 - 10 . 0 , - 10 . 1 } .
EC chỉ định một số giá trị: Nếu EC chỉ định một số giá trị, thì hãy
xây dựng các trường hợp thử nghiệm cho giá trị nhỏ nhất và lớn nhất
của số đó. Ngoài ra, hãy chọn giá trị nhỏ hơn giá trị nhỏ nhất và giá
trị lớn hơn giá trị lớn nhất. Ví dụ, hãy để đặc điểm kỹ thuật của EC
về ký túc xá sinh viên quy định rằng một đơn vị nhà ở có thể được
chia sẻ bởi một đến bốn sinh viên; các trường hợp thử nghiệm bao
gồm 1, 4, 0 và 5 sinh viên sẽ được phát triển.
EC chỉ định một tập hợp có thứ tự: Nếu EC chỉ định một tập hợp có
thứ tự, chẳng hạn như danh sách tuyến tính, bảng hoặc tệp tuần tự, thì
hãy tập trung sự chú ý vào phần tử đầu tiên và cuối cùng của tập hợp
đó.
347
Ví dụ: Chúng ta hãy xem xét năm EC được xác định trong ví dụ
trước của chúng tôi để tính thuế thu nhập dựa trên AGI. Kỹ thuật
BVA cho kết quả thử nghiệm như sau đối với mỗi EC. Các điểm dữ
liệu dư thừa có thể bị loại bỏ.
EC1: 1 đô la ≤ AGI ≤ 29.500 đô la; Điều này sẽ dẫn đến các giá trị là
$ 1, $ 0, $ –1, $ 1,50 và $ 29.499,50, $ 29.500, $ 29.500,50.
EC2: AGI < 1; Điều này sẽ dẫn đến các giá trị $ 1, $ 0, $ –1, $ –100
tỷ.
EC3: 29.501 đô la ≤ AGI ≤ 58.500 đô la; Điều này sẽ dẫn đến các giá
trị $ 29,500, $ 29,500,50, $ 29,501, $ 58,499, $ 58,500, $ 58,500,50,
$ 58,501.
EC4: 58,501 đô la ≤ AGI ≤ 100 tỷ đô la; Điều này sẽ dẫn đến các giá
trị là 58.500 đô la, 58.500,50 đô la, 58.501 đô la, 100 tỷ đô la, 101 tỷ
đô la.
EC5: AGI > 100 tỷ USD; Điều này sẽ dẫn đến 100 tỷ đô la, 101 tỷ đô
la, 10000 tỷ đô la.
Nhận xét. Chúng ta có nên kiểm tra giá trị AGI là $ 29.500,50 (tức là
giữa các phân vùng) hay không, và nếu có, kết quả sẽ như thế nào?
Vì chúng tôi chưa được biết liệu các giá trị thập phân có thực sự khả
thi hay không, nên quyết định tốt nhất cần đưa ra là kiểm tra giá trị
này và báo cáo kết quả.
9.6 BẢNG QUYẾT ĐỊNH
Một hạn chế chính của thử nghiệm dựa trên EC là nó chỉ xem xét
từng đầu vào riêng biệt. Kỹ thuật không xem xét điều kiện kết hợp.
Các kết hợp khác nhau của các lớp tương đương có thể được thử
bằng cách sử dụng một kỹ thuật mới dựa trên bảng quyết định để xử
lý nhiều đầu vào. Bảng quyết định đã được sử dụng trong nhiều năm
như một công cụ hữu ích để mô hình hóa các yêu cầu phần mềm và
các quyết định thiết kế. Nó là một ký hiệu đơn giản nhưng mạnh mẽ
để mô tả các hệ thống phức tạp từ hệ thống quản lý thông tin thư viện
đến các hệ thống thời gian thực nhúng [18].
Cấu trúc chung của một bảng quyết định được trình bày trong Bảng
9.11. Nó bao gồm một tập hợp các điều kiện (hoặc nguyên nhân) và
một tập hợp các tác động (hoặc kết quả) được sắp xếp dưới dạng một
cột ở bên trái của bảng. Trong cột thứ hai, bên cạnh mỗi điều kiện,
chúng ta có các giá trị có thể có của nó: có (Y), không (N) và không
quan tâm (gạch ngang). Ở bên phải của cột giá trị, chúng tôi có một
tập hợp các quy tắc. Với mỗi sự kết hợp của ba điều kiện {C 1 , C 2 , C
3 } , tồn tại một quy tắc từ tập {R 1 , R 2 , ···, R 8 } . Mỗi quy tắc bao
gồm câu trả lời có, không hoặc không quan tâm và chứa danh sách
các hiệu ứng liên quan {E 1 , E 2 , E 3 } . Sau đó, đối với mỗi tác động
có liên quan, số thứ tự tác động chỉ rõ thứ tự thực hiện tác động nếu
bộ điều kiện liên quan được thỏa mãn. Ví dụ, nếu C 1 và C 2 đúng
nhưng C 3 không đúng, thì E 3 phải được theo sau bởi E 1 . Tổng kiểm
tra được sử dụng để xác minh các kết hợp mà bảng quyết định đại
diện.
BẢNG 9.11 Bảng quyết định bao gồm tập hợp các điều kiện và
ảnh hưởng
Quy tắc hoặc Kết hợp
Các điều R
R1 R2 R3 R4 R5 R6 R7
kiện Giá trị 8
C1 Y, N, - Y Y Y Y N N N N
C2 Y, N, - Y Y N N Y Y N N
C3 Y, N, - Y N Y N Y N Y N
Các hiệu
ứng
E1 1 2 1
E2 2 1 2 1
E3 2 1 3 1 1
Checksum số 8 1 1 1 1 1 1 1 1
Dữ liệu thử nghiệm được chọn để mỗi quy tắc trong bảng được thực
thi và kết quả thực tế được xác minh với kết quả mong đợi. Nói cách
khác, mỗi quy tắc của bảng quyết định đại diện cho một trường hợp
thử nghiệm. Các bước trong việc phát triển các trường hợp kiểm thử
bằng cách sử dụng kỹ thuật bảng quyết định như sau:
Bước Người thiết kế thử nghiệm cần xác định các điều kiện và tác
1: động đối với từng đơn vị đặc điểm kỹ thuật. Một điều kiện là
một điều kiện đầu vào riêng biệt hoặc một EC của các điều
kiện đầu vào. Một hiệu ứng là một điều kiện đầu ra. Xác
349
định mối quan hệ logic giữa các điều kiện và các tác động.
Bước Liệt kê tất cả các điều kiện và ảnh hưởng dưới dạng một
2: bảng quyết định. Viết ra các giá trị mà điều kiện có thể nhận.
Bước Tính số tổ hợp có thể có. Nó bằng với số lượng các giá trị
3: khác nhau được nâng lên thành lũy thừa của số điều kiện.
Bước Điền vào các cột với tất cả các kết hợp có thể có — mỗi cột
4: tương ứng với một tổ hợp giá trị. Đối với mỗi hàng (điều
kiện), hãy làm như sau:
Xác định hệ số lặp lại (RF): chia số tổ hợp còn lại cho số giá
trị có thể có cho điều kiện đó.
Viết RF nhân với giá trị đầu tiên, sau đó RF nhân với giá trị
tiếp theo, và cứ tiếp tục như vậy cho đến khi hàng đầy.
Bước Giảm bớt các kết hợp (quy tắc). Tìm các kết hợp không quan
5: tâm — đặt dấu gạch ngang và nối cột nơi các cột giống hệt
nhau. Trong khi làm điều này, hãy đảm bảo rằng các hiệu
ứng giống nhau.
Bước Kiểm tra các kết hợp được bảo hiểm (quy tắc). Đối với mỗi
6: cột, hãy tính toán các kết hợp mà nó đại diện. Dấu gạch
ngang đại diện cho nhiều kết hợp như điều kiện có. Nhân
cho mỗi dấu gạch ngang xuống cột. Cộng tổng và so sánh
với bước 3. Nó phải giống nhau.
Bước Thêm hiệu ứng vào cột của bảng quyết định. Đọc từng cột
7: và xác định ảnh hưởng. Nếu nhiều hiệu ứng có thể xảy ra
trong một tổ hợp, thì hãy gán số thứ tự cho các hiệu ứng, do
đó chỉ định thứ tự thực hiện các hiệu ứng. Kiểm tra tính nhất
quán của bảng quyết định.
Bước Các cột trong bảng quyết định được chuyển thành các
8: trường hợp thử nghiệm.
Thử nghiệm dựa trên bảng quyết định có hiệu quả trong những điều
kiện nhất định như sau:
Các yêu cầu dễ dàng được ánh xạ vào một bảng quyết định.
Bảng quyết định kết quả không được quá lớn. Người ta có thể chia
một bảng quyết định lớn thành nhiều bảng nhỏ hơn.
Mỗi cột trong bảng quyết định là độc lập với các cột khác.
Ví dụ: Chúng ta hãy xem xét mô tả sau đây về một thủ tục thanh
toán. Các nhà tư vấn làm việc hơn 40 giờ mỗi tuần được trả lương
theo giờ của họ trong 40 giờ đầu tiên và gấp hai lần mức lương theo
giờ của họ cho những giờ tiếp theo. Các chuyên gia tư vấn làm việc
dưới 40 giờ mỗi tuần được trả lương cho số giờ làm việc theo giờ của
họ và báo cáo vắng mặt sẽ được lập. Công nhân cố định làm việc
dưới 40 giờ một tuần được trả lương và xuất trình báo cáo vắng mặt.
Công nhân cố định làm việc hơn 40 giờ một tuần được trả lương.
Chúng ta cần mô tả quy trình thanh toán ở trên bằng cách sử dụng
bảng quyết định và tạo các trường hợp thử nghiệm từ bảng.
Bước Từ mô tả trên, các điều kiện và ảnh hưởng được xác định
1: như sau:
C 1 : Công nhân cố định
C 2 : Làm việc < 40 giờ
C 3 : Làm việc chính xác 40 giờ C 4 : Làm việc > 40 giờ
E 1 : Trả lương
E 2 : Đưa ra báo cáo vắng mặt
E 3 : Trả theo giờ
E 4 : Thanh toán 2 × tỷ lệ hàng giờ
Bước Bảng quyết định với tất cả các điều kiện và ảnh hưởng được
2: thể hiện trong Bảng 9.12.
Bước Tổng số tổ hợp là 2 4 = 16.
3:
Bước 4: Các RF cho hàng 1, hàng 2, hàng 3 và hàng 4 lần lượt là
2 và 1. Do đó, hàng đầu tiên được điền với tám Y,
tiếp theo là tám N. Hàng thứ hai được điền với bốn Y, tiếp theo là
bốn N, v.v.
Bước 5: Nếu điều kiện C 1 : Công nhân thường xuyên là có và điều
kiện C 2 : Làm việc < 40 giờ là có, thì điều kiện C 3 : Làm việc đúng
40 giờ và C 4 : làm việc > 40 giờ không thành vấn đề. Do đó, các quy
tắc 1, 2, 3 và 4 có thể được rút gọn thành một quy tắc duy nhất mà
không ảnh hưởng đến các hiệu ứng.
BẢNG 9.12 Bảng quyết định tính toán thanh toán với các giá
trị cho mỗi quy tắc
Quy tắc hoặc Kết hợp
Các điều số
1 2 3 4 5 6 7 9 10 11 12 13 14 15 16
kiện Giá trị 8
C1 Y, N Y Y Y Y Y Y Y Y N N N N N N N N
351
C2 Y, N Y Y Y Y N N N N Y Y Y Y N N N N
C3 Y, N Y Y N N Y Y N N Y Y N N Y Y N N
C4 Y, N Y N Y N Y N Y N Y N Y N Y N Y N
Các hiệu
ứng
E 1E 2
E4
E4
Nếu điều kiện C 1 : Công nhân thường xuyên là có và điều kiện C 2 :
Làm việc < 40 giờ là không, thì điều kiện C 3 : Làm việc chính xác 40
giờ và C 4 : làm việc > 40 giờ không quan trọng. Do đó, các quy tắc
5, 6, 7 và 8 có thể được rút gọn thành một quy tắc duy nhất — người
lao động cố định được trả lương bất kể.
Nếu điều kiện C 1 : Không có lao động thường xuyên và điều kiện C 2
: Làm việc < 40 giờ là có, thì điều kiện C 3 : Làm việc chính xác 40
giờ và C 4 : làm việc > 40 giờ là phi vật chất. Do đó, các quy tắc 9,
10, 11 và 12 có thể được rút gọn thành một quy tắc duy nhất mà
không ảnh hưởng đến hiệu ứng.
Nếu điều kiện C 1 : Công nhân cố định và C 2 : Làm việc < 40 giờ là
không nhưng điều kiện C 3 : Làm việc đúng 40 giờ là có, thì quy tắc
13 và 14 có thể được rút gọn thành một quy tắc duy nhất.
Quy tắc 15 và 16 vẫn giữ nguyên như vậy. Tóm lại, 16 quy tắc có thể
được rút gọn thành tổng số 6 quy tắc, được trình bày trong Bảng
9.13.
Bước Tổng tổng cho các cột 1, 2, 3, 4, 5 và 6 lần lượt là 4, 4, 4, 2,
6: 1 và 1, như được thể hiện trong Bảng 9.14. Tổng tổng kiểm
tra là 16, giống như được tính ở bước 3.
Bước Trong bước này, các hiệu ứng được bao gồm cho mỗi cột
7: (quy tắc). Đối với cột đầu tiên, nếu thỏa mãn các điều kiện C
1 : Lao động thường xuyên và C 2 : Làm việc < 40 giờ thì
người lao động phải được trả lương và phải lập báo cáo nghỉ
việc; do đó, E 1 : Trả lương và E 2 : Đưa ra báo cáo vắng mặt
lần lượt được đánh dấu là 1 và 2 trong bảng quyết định — 1
và 2 cho biết thứ tự mà các tác động được mong đợi. Bảng
quyết định cuối cùng với các hiệu ứng được trình bày trong
Bảng 9.14. Lưu ý rằng đối với cột 6 không có hiệu ứng nào
được đánh dấu.
Bước Mục đích trường hợp thử nghiệm có thể được tạo ra từ cột 1,
8: có thể được mô tả như sau: Nếu một nhân viên là công nhân
cố định và làm việc ít hơn 40 giờ mỗi tuần, thì hệ thống sẽ
trả lương cho họ và tạo báo cáo vắng mặt. Tương tự, các
trường hợp thử nghiệm khác có thể được tạo từ phần còn lại
của các cột.
BẢNG 9.13 Bảng quyết định tính toán thanh toán sau khi giảm
cột
Quy tắc hoặc Kết
hợp
Các điều kiệnGiá trị 1 2 3 4 5 6
C1 Y, N Y Y N N N N
C2 Y, N Y N Y N N N
C3 Y, N - - - Y N N
C4 Y, N - - - - Y N
Các hiệu
ứng
E 1E 2
E4
E4
BẢNG 9.14 Bảng quyết định để tính toán thanh toán
Quy tắc hoặc Kết
hợp
Các điều kiện Giá trị 1 2 3 4 5 6
C1 Y, N Y Y N N N N
C2 Y, N Y N Y N N N
C3 Y, N - - - Y N N
C4 Y, N - - - - Y N
Các hiệu
ứng
E 1E 1 1 1
353
E2 2 2
E4 1 1 1
E4 2
Checksum 16 4 4 4 2 1 1
9.7 KIỂM TRA NGẪU NHIÊN
Trong phương pháp thử nghiệm ngẫu nhiên, các đầu vào thử nghiệm
được chọn ngẫu nhiên từ miền đầu vào của hệ thống. Chúng tôi giải
thích ý tưởng về thử nghiệm ngẫu nhiên bằng một ví dụ đơn giản √
của máy tính X , trong đó X là một số nguyên. Giả sử rằng hệ thống

sẽ được sử dụng trong môi trường mà đầu vào X nhận tất cả các giá
trị trong khoảng [1 , 10 8 ] với khả năng như nhau và kết quả phải
chính xác trong khoảng 2 × 10 - 4 . Để kiểm tra chương trình này,
người ta có thể tạo ra các số nguyên giả ngẫu nhiên phân bố đồng
đều trong khoảng [1 , 10 8 ]. Sau đó, chúng tôi thực hiện chương trình
trên mỗi đầu vào t này và thu được đầu ra z t . Với mỗi t , chúng ta
tính z t và z t 2 và so sánh z t 2 với t . Nếu bất kỳ đầu ra nào không nằm
trong khoảng 2 × 10 - 4 so với kết quả mong muốn, chương trình phải
được sửa và lặp lại thử nghiệm. Dựa trên ví dụ trên, thử nghiệm ngẫu
nhiên có thể được tóm tắt như một quy trình bốn bước [19]:
Bước Miền đầu vào được xác định.
1:
Bước Đầu vào kiểm tra được chọn độc lập với miền.
2:
Bước Hệ thống đang kiểm tra được thực thi trên các đầu vào này.
3: Các đầu vào tạo thành một tập hợp thử nghiệm ngẫu nhiên.
Bước Kết quả được so sánh với đặc tả hệ thống. Bài kiểm tra là
4: một thất bại nếu bất kỳ đầu vào nào dẫn đến kết quả không
chính xác; nếu không thì đó là một thành công.
Kiểm tra ngẫu nhiên tương ứng với lấy mẫu ngẫu nhiên đơn giản từ
miền đầu vào [20]. Nếu sự phân bố của các đầu vào đã chọn (bước 2)
giống với sự phân bố của các đầu vào trong kịch bản sử dụng dự kiến
(hồ sơ hoạt động), thì có thể thu được các ước tính thống kê về độ tin
cậy của chương trình từ các kết quả thử nghiệm. Thử nghiệm ngẫu
nhiên mang lại cho chúng tôi một lợi thế là dễ dàng ước tính độ tin
cậy của phần mềm từ các kết quả thử nghiệm. Đầu vào kiểm tra được
tạo ngẫu nhiên theo một
9.7 KIỂM TRA NGẪU NHIÊN
hồ sơ hoạt động và thời gian hỏng hóc được ghi lại. Dữ liệu thu được
từ thử nghiệm ngẫu nhiên sau đó có thể được sử dụng để ước tính độ
tin cậy. Các phương pháp kiểm tra khác không thể được sử dụng theo
cách này để ước tính độ tin cậy của phần mềm.
Một số lượng lớn các đầu vào thử nghiệm thường được yêu cầu để có
được kết quả thống kê có ý nghĩa. Do đó, một số loại tự động hóa
được yêu cầu để tạo ra một số lượng lớn các đầu vào để kiểm tra
ngẫu nhiên. Để tạo hiệu quả một tập hợp lớn các yếu tố đầu vào cho
ước tính thống kê, người ta cần biết hồ sơ hoạt động của hệ thống.
Mặt khác, kết quả mong đợi (bước 4) thường không rõ ràng. Việc
tính toán các kết quả mong đợi sẽ trở nên khó khăn nếu các đầu vào
được chọn ngẫu nhiên. Do đó, kỹ thuật này đòi hỏi phải có kỹ thuật
kiểm tra tốt để đảm bảo đánh giá đầy đủ các kết quả kiểm tra. Phép
thử kiểm tra là một cơ chế xác minh tính đúng đắn của các kết quả
đầu ra của chương trình. Thuật ngữ thử nghiệm tiên tri được đặt ra
bởi William E. Howden [21]. Một nhà tiên tri cung cấp một phương
pháp để (i) tạo ra kết quả mong đợi cho các đầu vào thử nghiệm và
(ii) so sánh kết quả mong đợi với kết quả thực tế của việc thực hiện
việc triển khai đang được thử nghiệm (IUT). Nói cách khác, nó bao
gồm hai phần: bộ tạo kết quả để thu được kết quả mong đợi và bộ so
sánh. Bốn loại oracles phổ biến như sau [22]:
Perfect Oracle: Trong sơ đồ này, hệ thống (IUT) được kiểm tra song
song với một hệ thống đáng tin cậy chấp nhận mọi đầu vào được chỉ
định cho IUT và luôn tạo ra kết quả chính xác. Hệ thống đáng tin cậy
là phiên bản IUT không có khiếm khuyết.
Chuẩn vàng Oracle: Phiên bản trước của hệ thống ứng dụng hiện có
được sử dụng để tạo ra kết quả mong đợi, như thể hiện trong Hình
9.9.
Tham số Oracle: Một thuật toán được sử dụng để trích xuất một số
tham số từ các đầu ra thực tế và so sánh chúng với các giá trị tham số
mong đợi, như trong Hình 9.10.
thống kê: Đây là một trường hợp đặc biệt của một nhà tiên tri tham
số. Trong một tiên tri thống kê, các đặc điểm thống kê của các kết
quả thử nghiệm thực tế được xác minh.
355
Golden
implementation Golden result
Test case
input Pass or fail
Test input Comparator
Implementation Actual result

under test
Hình 9.9 Tiên tri bản vị vàng.

Trusted Pass or fail
algorithm Reference Comparator
Test case parameters
input
Test input Actual parameters
Implementation Actual result Output

under test converter
Hình 9.10 Tiên tri tham số.

Hơn nữa, kết quả kiểm tra thực tế là ngẫu nhiên trong trường hợp
phần mềm ngẫu nhiên và kiểm tra ngẫu nhiên. Do đó, không thể đưa
ra một giá trị kỳ vọng chính xác. Trong sơ đồ này, đặc tính thống kê
mong đợi được so sánh với kết quả thử nghiệm thực tế. Một nhà tiên
tri thống kê không kiểm tra đầu ra thực tế mà chỉ kiểm tra một số đặc
điểm của nó. Do đó, một nhà tiên tri thống kê không thể quyết định
liệu một trường hợp thử nghiệm duy nhất có vượt qua hay không.
Nếu một lỗi xảy ra, việc xác định lỗi không thể được quy cho sự
thành công của một trường hợp thử nghiệm đơn lẻ; thay vào đó, toàn
bộ nhóm các trường hợp thử nghiệm được ghi nhận là thành công.
Quyết định của một nhà tiên tri thống kê không phải lúc nào cũng
đúng. Nói cách khác, tốt nhất có thể đưa ra xác suất cho một quyết
định chính xác. Hình 9.11 mô tả cấu trúc của một nhà tiên tri thống
kê [23]. Nó bao gồm một bộ phân tích thống kê và một bộ so sánh.
Bộ phân tích thống kê tính toán các đặc điểm khác nhau có thể được
mô hình hóa dưới dạng các biến ngẫu nhiên và chuyển nó đến bộ so
sánh. Bộ so sánh tính toán giá trị trung bình của mẫu thực nghiệm và
phương sai mẫu thực nghiệm của các đầu vào của nó. Hơn nữa, các
giá trị kỳ vọng và thuộc tính của các đặc tính được bộ so sánh tính
toán dựa trên các tham số phân phối của đầu vào thử nghiệm ngẫu
nhiên.
Thử nghiệm ngẫu nhiên thích ứng Trong thử nghiệm ngẫu nhiên
thích ứng, các đầu vào thử nghiệm được chọn từ tập hợp được tạo
ngẫu nhiên theo cách mà chúng được trải đều trên toàn bộ miền đầu
vào. Mục đích là chọn một số lượng nhỏ đầu vào thử nghiệm để phát
hiện lỗi đầu tiên. Một số đầu vào thử nghiệm ngẫu nhiên được tạo,
sau đó chọn đầu vào "tốt nhất" trong số đó. Chúng ta cần đảm bảo
rằng đầu vào thử nghiệm mới đã chọn không quá gần với bất kỳ đầu
vào nào đã chọn trước đó. Nghĩa là, các đầu vào thử nghiệm đã chọn
phải được phân phối càng cách nhau càng tốt.
Một kỹ thuật thử nghiệm ngẫu nhiên thích ứng được đề xuất bởi
Chen et al. [24] giữ hai bộ, cụ thể là T và C , như sau:
Tập thực thi T là tập hợp các đầu vào thử nghiệm riêng biệt đã được
chọn và thực thi mà không để lộ bất kỳ lỗi nào.
Tập ứng cử viên C là tập hợp các đầu vào thử nghiệm được chọn
ngẫu nhiên.
Ban đầu tập T là trống và đầu vào thử nghiệm đầu tiên được chọn
ngẫu nhiên từ miền đầu vào. Tập hợp T sau đó được cập nhật dần
dần với phần tử được chọn từ tập hợp C và được thực hiện cho đến
khi lỗi được tiết lộ. Từ tập C , một phần tử ở xa nhất so với tất cả các
phần tử trong tập T được chọn làm đầu vào kiểm tra tiếp theo. Tiêu
chí “xa nhất” có thể được xác định như sau. Để cho
Pass or fail
Distributional parameters
Comparator
Random
test input Characteristics
generator
Implementation Actual results Statistical
Test case under test analyzer
inputs
Hình 9.11 Tiên tri thống kê.

9.8 HƯỚNG DẪN LỖI
T = {t 1 , t 2 , ..., t n } là tập thực hiện và C = {c 1 , c 2 , ..., c k } là tập
ứng viên sao cho C ∩ T = φ . Tiêu chí là chọn phần tử c h sao cho tất
cả
,
trong đó dist được định nghĩa là khoảng cách Euclide. Trong miền
đầu vào thứ m , cho các đầu vào a = (a 1 , a 2 , ..., a m ) và b = (b 1 , b 2
, ..., b m ) , dist (a, b) =
. Cơmi=sở
1 (alý
i −luận
bi ) 2 của tiêu chí này là trải đều đầu vào bài kiểm tra
bằng cách tối đa hóa khoảng cách tối thiểu giữa đầu vào thử nghiệm
tiếp theo và các trường hợp thử nghiệm đã được thực thi.
Cần lưu ý rằng có nhiều cách khác nhau để xây dựng tập ứng viên C
làm phát sinh các phiên bản khác nhau của thử nghiệm ngẫu nhiên
357
thích ứng. Ví dụ: một tập hợp ứng viên mới có thể được xây dựng
với kích thước 10 mỗi khi đầu vào thử nghiệm được chọn. Nghiên
cứu thực nghiệm cho thấy thử nghiệm ngẫu nhiên thích ứng hoạt
động tốt hơn thử nghiệm ngẫu nhiên thông thường 50% [24]. Trong
so sánh trên, chỉ số hiệu suất là kích thước của bộ thử nghiệm được
sử dụng để phát hiện lỗi đầu tiên.
9.8 HƯỚNG DẪN LỖI
Đoán lỗi là một kỹ thuật thiết kế trường hợp thử nghiệm trong đó kỹ
sư thử nghiệm sử dụng kinh nghiệm để (i) đoán các loại và vị trí có
thể xảy ra của các khuyết tật và (ii) thiết kế các bài kiểm tra đặc biệt
để tiết lộ các khuyết tật. Ví dụ: nếu bộ nhớ được cấp phát động, thì
nơi tốt để tìm lỗi là phần mã sau khi bộ nhớ được cấp phát được sử
dụng — có khả năng bộ nhớ không sử dụng không được phân bổ.
Một kỹ sư kiểm thử có kinh nghiệm có thể đặt câu hỏi: Tất cả các
khối bộ nhớ được cấp phát có được phân bổ chính xác không?
Mặc dù kinh nghiệm được sử dụng nhiều trong việc đoán lỗi, nhưng
sẽ rất hữu ích nếu bạn thêm một số cấu trúc vào kỹ thuật này. Sẽ rất
tốt nếu bạn chuẩn bị một danh sách các loại lỗi có thể được phát hiện.
Danh sách lỗi có thể giúp chúng tôi đoán vị trí có thể xảy ra lỗi. Một
danh sách như vậy nên được duy trì từ kinh nghiệm thu được từ các
dự án thử nghiệm trước đó. Sau đây là các khu vực quan trọng của
mã nơi có nhiều khả năng bị lỗi nhất:
Các phần khác nhau của mã có độ phức tạp khác nhau. Người ta có
thể đo độ phức tạp của mã bằng độ phức tạp theo chu kỳ. Các phần
của mã có độ phức tạp chu kỳ cao có khả năng có lỗi. Do đó, việc tập
trung nhiều nỗ lực hơn vào những phần mã đó sẽ có hiệu quả. • Mã
đã được thêm vào hoặc sửa đổi gần đây có thể có các khiếm khuyết.
Xác suất vô tình tạo ra các khiếm khuyết khi bổ sung và sửa đổi mã
là cao. • Các phần mã có lịch sử lỗi trước đây có khả năng dễ bị lỗi.
Các khối mã như vậy có khả năng bị lỗi, do xu hướng phân cụm của
các khiếm khuyết, mặc dù đã nỗ lực loại bỏ các khiếm khuyết bằng
cách viết lại mã.
Các bộ phận của hệ thống sử dụng công nghệ mới, chưa được chứng
minh có khả năng chứa các khiếm khuyết. Ví dụ, nếu mã đã được tạo
tự động từ một thông số kỹ thuật chính thức của hệ thống, thì khả
năng cao hơn các lỗi được gắn vào mã.
Các phần của mã mà đặc tả chức năng đã được xác định lỏng lẻo có
thể bị lỗi nhiều hơn.
Các khối mã do các nhà phát triển mới làm quen tạo ra có thể bị lỗi.
Nếu một số nhà phát triển đã không cẩn thận trong quá trình viết mã
trước đây, thì bất kỳ mã nào do những nhà phát triển này viết nên
được kiểm tra chi tiết hơn.
Các phân đoạn mã mà nhà phát triển có thể có mức độ tin cậy thấp sẽ
được chú ý nhiều hơn. Các nhà phát triển biết các chi tiết bên trong
của hệ thống hơn bất kỳ ai khác. Do đó, họ nên được đánh giá về
mức độ thoải mái của họ và nỗ lực kiểm tra nhiều hơn ở những khu
vực mà nhà phát triển cảm thấy thiếu tự tin hơn về công việc của họ.
Những khu vực mà thực hành chất lượng còn kém cần được chú ý
thêm. Một ví dụ về thực hành chất lượng kém là không kiểm tra đầy
đủ một mô-đun ở cấp đơn vị. Một ví dụ khác về thực hành chất lượng
kém là không thực hiện xem xét mã cho một phần quan trọng của
mô-đun. • Một mô-đun liên quan đến nhiều nhà phát triển sẽ nhận
được nhiều nỗ lực thử nghiệm hơn. Nếu một số nhà phát triển đã làm
việc trên một phần cụ thể của mã, thì có khả năng xảy ra hiểu lầm
giữa các nhà phát triển khác nhau và do đó, có khả năng xảy ra lỗi
trong các phần này của mã.
9.9 PHẦN THỂ LOẠI
Phương pháp phân vùng danh mục (CPM) là một cách tổng quát hóa
và chính thức hóa phương pháp thử nghiệm chức năng cổ điển.
Người đọc được nhắc nhở về hai bước của phương pháp kiểm tra
chức năng cổ điển: (i) phân vùng miền đầu vào của đơn vị chức năng
cần kiểm tra thành các lớp tương đương và (ii) chọn dữ liệu kiểm tra
từ mỗi EC của phân vùng. CPM [25] là một phương pháp luận dựa
trên đặc điểm kỹ thuật có hệ thống, sử dụng đặc điểm kỹ thuật chức
năng không chính thức để tạo ra đặc điểm kỹ thuật thử nghiệm chính
thức. Công việc chính của nhà thiết kế thử nghiệm là phát triển các
danh mục, được xác định là các đặc điểm chính của miền đầu vào
của chức năng đang thử nghiệm. Mỗi danh mục được phân chia
thành các EC của đầu vào được gọi là các lựa chọn. Các lựa chọn
trong mỗi danh mục phải rời rạc và cùng nhau các lựa chọn trong
mỗi danh mục phải bao phủ miền đầu vào. Trong một bài báo sau
này [26], Grochtmann và Grimm mở rộng cách tiếp cận này bằng
359
cách nắm bắt các ràng buộc bằng cách sử dụng cấu trúc cây để giảm
số lượng các trường hợp kiểm thử không thể thực hiện được.
Ưu điểm chính của phương pháp này là tạo ra một đặc tả kiểm tra
chính thức được viết bằng các ngôn ngữ như ngôn ngữ đặc tả kiểm
tra (TSL) [27], Z [28], [29], hoặc ký hiệu kiểm tra và kiểm tra thử
nghiệm (TTCN) [30] đại diện cho một đặc tả chính thức không chính
thức hoặc ngôn ngữ tự nhiên. Đặc điểm kỹ thuật thử nghiệm chính
thức đưa ra
9.9 PHẦN THỂ LOẠI
kỹ sư thử nghiệm một cách hợp lý để kiểm soát việc tạo thử nghiệm
và dễ dàng sửa đổi để thích ứng với những thay đổi hoặc sai lầm
trong đặc điểm kỹ thuật chức năng. Việc sử dụng Z cho phép linh
hoạt hơn trong việc đặc tả các ràng buộc và nhiều thủ tục hơn trong
biểu diễn.
Phương pháp kiểm tra phân vùng danh mục bao gồm các bước sau:
Bước Phân tích đặc điểm kỹ thuật Phương pháp bắt đầu bằng
1: việc phân tích một đặc điểm kỹ thuật chức năng thành các
đơn vị chức năng có thể được kiểm tra riêng biệt. Đối với
mỗi đơn vị chức năng, hãy xác định những điều sau:
Các thông số của đơn vị chức năng
Đặc điểm của từng tham số, tức là các đặc điểm cơ bản của
các tham số ảnh hưởng đến việc thực thi đơn vị
Các đối tượng trong môi trường có trạng thái có thể ảnh
hưởng đến hoạt động của đơn vị chức năng
Đặc điểm của từng đối tượng môi trường
Tham số là đầu vào rõ ràng cho một đơn vị chức năng và
điều kiện môi trường là đặc điểm trạng thái của hệ thống tại
thời điểm thực hiện một đặc tả chức năng.
Bước Xác định danh mục Phân loại là sự phân loại các thuộc
2: tính chính (hoặc đặc điểm) của một thông số hoặc một điều
kiện môi trường. Ví dụ, hãy xem xét một chương trình P SORT
đọc một tệp đầu vào F chứa một mảng giá trị có độ dài thay
đổi của kiểu tùy ý. Đầu ra mong đợi là một hoán vị của đầu
vào với các giá trị được sắp xếp theo một số tiêu chí sắp xếp
tổng thể. Điều kiện môi trường cho P SORT là trạng thái của F
, có thể được phân thành ba loại, đó là Trạng thái F = Không
tồn tại, Trạng thái F = Tồn tại nhưng rỗng, và Trạng thái F =
Tồn tại và Không tồn tại. Các thuộc tính của danh mục tham
số đầu vào cho P SORT như sau: kích thước mảng, loại phần
tử, giá trị phần tử nhỏ nhất, giá trị phần tử lớn nhất và các vị
trí trong mảng của giá trị lớn nhất và nhỏ nhất. Các danh
mục có thể được lấy trực tiếp từ đặc điểm kỹ thuật chức
năng, thông tin thiết kế ngầm hoặc trực giác của kỹ sư thử
nghiệm. Thông thường các danh mục có nguồn gốc từ các
điều kiện tiên quyết và loại thông tin về các tham số đầu vào
và các thành phần trạng thái hệ thống.
Bước Phân vùng Danh mục thành Lựa chọn Phân chia mỗi
3: danh mục thành các lựa chọn riêng biệt bao gồm tất cả các
loại giá trị khác nhau có thể có cho danh mục. Mỗi lựa chọn
là một lớp giá trị tương đương được giả định là có các thuộc
tính giống hệt nhau khi có liên quan đến khả năng kiểm tra
và phát hiện lỗi. Các lựa chọn phải rời rạc và bao gồm tất cả
các danh mục. Trong khi các danh mục bắt nguồn từ một đặc
tả chức năng, các lựa chọn có thể dựa trên đặc điểm kỹ thuật
và kinh nghiệm trước đây của kỹ sư thử nghiệm về việc thiết
kế các trường hợp thử nghiệm hiệu quả, chẳng hạn như đoán
lỗi.
Trong ví dụ về chương trình sắp xếp P SORT , một cách khả thi
để phân vùng kích thước mảng danh mục là size = 0, size =
1, 2 ⇐ kích thước ⇐ 100 và kích thước > 100. Những lựa
chọn này chủ yếu dựa trên kinh nghiệm với khả năng
các lỗi. Việc lựa chọn một lựa chọn duy nhất từ mỗi danh mục xác
định một khung thử nghiệm, là cơ sở để xây dựng các trường hợp thử
nghiệm thực tế. Khung thử nghiệm bao gồm một tập hợp các lựa
chọn từ đặc điểm kỹ thuật, với mỗi danh mục đóng góp không hoặc
một lựa chọn. Vì các lựa chọn trong các danh mục khác nhau thường
xuyên tương tác với nhau theo những cách ảnh hưởng đến các trường
hợp thử nghiệm kết quả, các lựa chọn có thể được chú thích bằng các
ràng buộc (xem bước tiếp theo) để chỉ ra các mối quan hệ này. Trong
trường hợp không có ràng buộc, số lượng khung thử nghiệm tiềm
năng là tích số của số lượng lựa chọn trong mỗi danh mục — và điều
này có thể rất lớn.
Bước Xác định ràng buộc giữa các lựa chọn Ràng buộc là những
4: hạn chế giữa các lựa chọn trong các danh mục khác nhau có
361
thể tương tác với nhau. Một ràng buộc điển hình chỉ định rằng
một lựa chọn từ một danh mục không thể xảy ra cùng nhau
trong một khung thử nghiệm với các lựa chọn nhất định từ
một danh mục khác. Các lựa chọn và ràng buộc bắt nguồn từ
các đặc tả chức năng của ngôn ngữ tự nhiên nhưng thường có
thể được chỉ định bằng các phương pháp chính thức, do đó
làm cho việc phân tích của chúng dễ dàng tự động hóa hơn.
Với đặc điểm kỹ thuật cẩn thận về các ràng buộc, số lượng
khung thử nghiệm tiềm năng có thể giảm xuống một con số có
thể quản lý được.
Bước Chính thức hóa và Đánh giá Đặc tả Kiểm tra Chỉ định các
5: danh mục, lựa chọn và ràng buộc bằng cách sử dụng kỹ thuật
đặc tả tương thích với công cụ tạo kiểm tra, chẳng hạn như
TSL, Z hoặc TTCN, tạo ra các khung kiểm tra. Hầu hết các
công cụ tạo thử nghiệm cũng cung cấp các kỹ thuật tự động để
đánh giá tính nhất quán nội bộ của đặc tả chính thức. Việc
đánh giá này thường phát hiện ra các lỗi hoặc sự không nhất
quán trong đặc tả của các ràng buộc và đôi khi dẫn đến việc
phát hiện ra các lỗi trong đặc tả chức năng nguồn.
Bước Tạo và xác thực các trường hợp thử nghiệm Bước cuối
6: cùng trong quá trình sản xuất thử nghiệm là chuyển đổi các
khung thử nghiệm đã tạo thành các trường hợp thử nghiệm có
thể thực thi được. Nếu đặc điểm kỹ thuật kiểm tra bao gồm
các điều kiện sau phải được thỏa mãn, thì công cụ xác minh
các điều kiện sau. Trong trường hợp có sẵn triển khai tham
chiếu, các trường hợp thử nghiệm có thể được xác thực bằng
cách thực thi chúng và kiểm tra kết quả của chúng so với triển
khai tham chiếu. Việc xác nhận các trường hợp kiểm thử là
một quá trình tốn nhiều công sức trong trường hợp không có
triển khai tham chiếu [31].
9.10 TÓM TẮT
Chương này bắt đầu với phần giới thiệu về khái niệm kiểm thử chức
năng, bao gồm (i) xác định chính xác miền của từng biến đầu vào và
từng biến đầu ra, (ii) lựa chọn các giá trị từ miền dữ liệu có các thuộc
tính quan trọng, và (iii) kết hợp các giá trị của các biến khác nhau.
Tiếp theo, chúng tôi đã kiểm tra bốn loại biến khác nhau, đó là số,
mảng, cấu trúc con và chuỗi. Chỉ các tập hợp con có liên quan về mặt
chức năng của các biến đầu vào mới được coi là kết hợp
9.10 TÓM TẮT
để giảm tổng số kết hợp đầu vào [3, 4]. Bằng cách này, tổng số tổ
hợp các giá trị đặc biệt của các biến sẽ bị giảm đi. Sau đó, chúng tôi
thảo luận về phạm vi và độ phức tạp của kiểm thử chức năng. Tiếp
theo, chúng tôi giới thiệu bảy kỹ thuật kiểm tra như được tóm tắt
trong phần sau:
cặp: Kiểm tra theo cặp yêu cầu đối với một số lượng nhất định của
các tham số đầu vào cho hệ thống, mỗi tổ hợp giá trị có thể có cho
bất kỳ cặp thông số nào phải được bao phủ bởi ít nhất một trường
hợp thử nghiệm. Đây là một trường hợp đặc biệt của kiểm thử tổ hợp,
yêu cầu kiểm tra n -way tổ hợp, n = 1 , 2 , ..., N , trong đó N là tổng
số tham số trong hệ thống. Chúng tôi đã trình bày hai kỹ thuật lựa
chọn kiểm tra theo cặp phổ biến, đó là OA và IPO.
Phân vùng lớp tương đương: Mục đích của phân vùng EC là chia
miền đầu vào của hệ thống đang được thử nghiệm thành các lớp
(hoặc nhóm) các trường hợp thử nghiệm có ảnh hưởng tương tự đến
hệ thống. Phân vùng tương đương là một phương pháp có hệ thống
để xác định tập hợp các lớp điều kiện đầu vào thú vị cần được kiểm
tra. Chúng tôi đã cung cấp các hướng dẫn để xác định (i) các EC và
(ii) dữ liệu kiểm tra từ các EC cần được thực thi.
Phân tích giá trị ranh giới: Các điều kiện biên cho mỗi EC được
phân tích để tạo ra các trường hợp thử nghiệm. Điều kiện biên là các
vị từ áp dụng trực tiếp trên, trên và dưới ranh giới của EC đầu vào và
EC đầu ra. Chúng tôi đã giải thích các hướng dẫn hữu ích có thể áp
dụng cho các điều kiện đầu vào và đầu ra của EC đã xác định. Những
điều này rất hữu ích trong việc xác định các trường hợp kiểm tra chất
lượng.
Bảng Quyết định: Đây là một kỹ thuật đơn giản nhưng mạnh mẽ để
mô tả một hệ thống phức tạp. Bảng quyết định bao gồm một tập hợp
các điều kiện được đặt trên một tập hợp các hiệu ứng (hoặc kết quả)
để thực hiện ở dạng ma trận. Tồn tại một quy tắc cho mỗi sự kết hợp
của các điều kiện. Mỗi quy tắc bao gồm phản hồi Y (có), N (không)
hoặc— (không quan tâm) và chứa danh sách các hiệu ứng liên quan.
Do đó, mỗi quy tắc của bảng quyết định đại diện cho một trường hợp
thử nghiệm.
363
Kiểm tra ngẫu nhiên: Kỹ thuật kiểm tra ngẫu nhiên có thể được tóm
tắt như một quy trình gồm bốn bước:
Miền đầu vào được xác định.
Các đầu vào thử nghiệm được chọn độc lập từ miền này.
Hệ thống đang thử nghiệm được thực thi trên một tập hợp ngẫu nhiên
các đầu vào.
Kết quả được so sánh với đặc điểm kỹ thuật của hệ thống.
Bài kiểm tra là một thất bại nếu bất kỳ đầu vào nào dẫn đến kết quả
không chính xác; nếu không thì đó là một thành công.
Quy trình này yêu cầu một nhà tiên tri thử nghiệm để đảm bảo đánh
giá đầy đủ các kết quả thử nghiệm. Một nhà tiên tri thử nghiệm cho
chúng ta biết liệu một trường hợp thử nghiệm có vượt qua hay
không. Chúng tôi đã thảo luận về bốn loại oracles tiêu chuẩn, đó là,
hoàn hảo, vàng, tham số và thống kê. Chúng tôi cũng đã xem xét
khái niệm về thử nghiệm ngẫu nhiên thích ứng, trong đó các đầu vào
thử nghiệm được chọn từ một tập hợp được tạo ngẫu nhiên. Các đầu
vào kiểm tra này được trải đều trên toàn bộ miền đầu vào để đạt được
một số lượng nhỏ các đầu vào kiểm tra để phát hiện lỗi đầu tiên.
Đoán lỗi: Đây là một kỹ thuật thiết kế trường hợp thử nghiệm trong
đó kinh nghiệm của người thử nghiệm được sử dụng để (i) đoán loại
và vị trí của lỗi và (ii) thiết kế các thử nghiệm đặc biệt để xác định
các lỗi đó. Đoán lỗi là một cách tiếp cận đặc biệt trong việc thiết kế
các trường hợp thử nghiệm.
Phân vùng danh mục: Phương pháp phân vùng danh mục yêu cầu kỹ
sư kiểm thử phân chia đặc điểm kỹ thuật chức năng thành các đơn vị
chức năng độc lập có thể được kiểm tra riêng biệt. Phương pháp này
xác định các thông số đầu vào và các điều kiện môi trường, được gọi
là danh mục, bằng cách dựa vào hướng dẫn của kỹ sư thử nghiệm.
Tiếp theo, kỹ sư kiểm tra phân tách từng danh mục đã xác định thành
các lựa chọn loại trừ lẫn nhau được sử dụng để mô tả phân vùng của
đầu vào trong danh mục. Sau đó, các danh mục, lựa chọn và ràng
buộc được chỉ định bằng ngôn ngữ đặc tả chính thức như TSL. Đặc
điểm kỹ thuật sau đó được xử lý để tạo ra một bộ khung thử nghiệm
cho đơn vị chức năng. Kỹ sư thử nghiệm kiểm tra các khung thử
nghiệm và xác định xem có cần thiết bất kỳ thay đổi nào đối với đặc
điểm kỹ thuật thử nghiệm hay không. Cuối cùng, các khung thử
nghiệm được chuyển đổi thành các trường hợp thử nghiệm có thể
thực thi được.
Thuật toán IPO được thảo luận trong chương này đã được triển khai
trong một công cụ có tên là PairTest [8] cung cấp giao diện đồ họa để
giúp công cụ dễ sử dụng. Một công cụ kiểm tra được gọi là trình tạo
kiểm tra hiệu quả tự động (AETG) đã được tạo ra tại Telcordia và
được xuất bản trong hai bài báo sau:
DM Cohen, SR Dalal, ML Fredman và GC Patton, “Hệ thống
AETG: Cách tiếp cận để kiểm tra dựa trên thiết kế kết hợp,” Giao
dịch IEEE về Kỹ thuật phần mềm, Vol. 23, số 7, tháng 7 năm 1997,
tr.437–444.
DM Cohen, SR Dalal, J. Parelius, và GC Patton, “Phương pháp tiếp
cận thiết kế kết hợp để tạo thử nghiệm tự động,” IEEE Software, Vol.
13, số 5, tháng 9 năm 1996, tr.83–89.
Chiến lược được sử dụng trong công cụ này bắt đầu với một bộ thử
nghiệm trống và thêm một trường hợp thử nghiệm tại một thời điểm.
Công cụ tạo ra một số trường hợp thử nghiệm ứng viên theo một
thuật toán tham lam và sau đó chọn một trường hợp bao gồm các cặp
được phát hiện nhiều nhất.
Rất ít chủ đề liên quan đến kỹ thuật kiểm thử phần mềm dường như
gây tranh cãi hơn câu hỏi liệu việc sử dụng dữ liệu đầu vào kiểm tra
được tạo ngẫu nhiên có hiệu quả hay không. Hiệu quả tương đối của
thử nghiệm ngẫu nhiên (tức là lựa chọn ngẫu nhiên các đầu vào thử
nghiệm từ toàn bộ miền đầu vào) so với thử nghiệm phân vùng (tức
là chia miền đầu vào thành các miền phụ không trùng lặp và chọn
một đầu vào thử nghiệm từ mỗi miền phụ) đã là chủ đề của nhiều bài
nghiên cứu . Bạn đọc quan tâm có thể tham khảo các tài liệu sau đây
để biết một số cuộc thảo luận này:
Hãy xem xét hệ thống S trong Hình 9.7, có ba tham số đầu vào X , Y
và Z. Giả sử rằng tập hợp D , tập hợp các giá trị dữ liệu kiểm tra đầu
vào, đã được chọn cho mỗi biến đầu vào sao cho D (X) = { True,
False } , D (Y) = { 0 , 5 } và D (Z ) = {P, Q, R} . Sử dụng phương
pháp mảng trực giao được thảo luận trong chương này, tạo các
365
trường hợp kiểm tra theo cặp cho hệ thống này. So sánh kết quả với
bộ thử nghiệm được tạo bằng thuật toán IPO.
Thảo luận về mặt hạn chế của phương pháp luận mảng trực giao so
với thuật toánIPO.
Xét hệ thống S có thể nhận n tham số đầu vào và mỗi tham số có thể
nhận m giá trị. Đối với hệ thống này, hãy trả lời các câu hỏi sau:
Số lượng cặp tối đa trong một trường hợp thử nghiệm duy nhất cho
vỏ máy quét hệ thống này là bao nhiêu?
Trong trường hợp tốt nhất, có bao nhiêu trường hợp thử nghiệm có
thể cung cấp phạm vi bảo hiểm theo từng cặp đầy đủ? (C) Tính tổng
số cặp mà bộ thử nghiệm phải bao phủ.
(d) Giả sử rằng n = 13 và m = 3. Số lượng trường hợp thử nghiệm tối
thiểu được chọn để đạt được vùng phủ sóng theo cặp là bao nhiêu?
Hãy xem xét hệ thống phân loại tam giác sau, ban đầu được sử dụng
bởi Myers [16]: Hệ thống đọc theo ba giá trị dương từ đầu vào chuẩn.
Ba giá trị A, B và C được hiểu là đại diện cho độ dài các cạnh của
một tam giác. Sau đó, hệ thống sẽ in một thông báo trên đầu ra tiêu
chuẩn cho biết tam giác là vô hướng, cân, đều hay góc vuông nếu
một tam giác có thể được tạo thành. Trả lời các câu hỏi sau cho
chương trình trên:
Miền đầu vào của hệ thống là gì?
Điều kiện đầu vào là gì?
Xác định các lớp tương đương cho hệ thống?
Xác định các trường hợp thử nghiệm để bao gồm các EC đã được xác
định?
Hãy xem xét lại chương trình phân loại tam giác với một đặc điểm kỹ
thuật hơi khác: Chương trình đọc các giá trị nổi từ đầu vào tiêu
chuẩn. Ba giá trị A , B và C được hiểu là đại diện cho độ dài các cạnh
của một tam giác. Sau đó, chương trình sẽ in một thông báo đến đầu
ra tiêu chuẩn cho biết liệu tam giác, nếu nó có thể được tạo thành, là
hình vô hướng, cân, cạnh đều hay góc vuông. Xác định giá trị sau
cho chương trình trên:
Đối với trường hợp điều kiện biên A + B> C (tam giác vô hướng),
xác định các trường hợp kiểm tra để xác minh ranh giới.
Đối với trường hợp điều kiện biên A = C (tam giác cân), xác định các
trường hợp kiểm tra để xác minh đường biên.
Đối với trường hợp điều kiện biên A = B = C (tam giác đều), xác
định các trường hợp thử nghiệm để xác minh đường biên.
Đối với trường hợp điều kiện biên A 2 + B 2 = C 2 (tam giác vuông),
hãy xác định các trường hợp kiểm tra để xác minh đường biên.
Đối với trường hợp không tam giác, xác định các trường hợp thử
nghiệm để khám phá ranh giới.
Đối với đầu vào không dương tính, hãy xác định các điểm kiểm tra.
Xem xét đặc điểm kỹ thuật phân loại tam giác. Hệ thống đọc các giá
trị âm tính từ đầu vào chuẩn. Ba giá trị A, B và C được hiểu là đại
diện cho độ dài các cạnh của một tam giác. Sau đó, hệ thống sẽ in
một thông báo đến đầu ra tiêu chuẩn cho biết liệu tam giác, nếu nó có
thể được tạo thành, là vô hướng, cân, đều hay không phải là tam giác.
Phát triển một bảng quyết định để tạo các trường hợp thử nghiệm cho
đặc điểm kỹ thuật này.
Ưu điểm và nhược điểm của thử nghiệm ngẫu nhiên là gì?
Phép thử là gì? Sự khác biệt giữa một nhà tiên tri tham số và một nhà
tiên tri thống kê là gì?
Thảo luận về sự giống nhau giữa phương pháp kiểm tra dựa trên
bảng quyết định và dựa trên phân vùng danh mục.
CHAPTER
10
TestGenerationfromFSMModels
Các ngành khoa học không cố gắng giải thích, thậm chí họ hầu như
không cố gắng giải thích, họ chủ yếu làm ra các mô hình. Bởi một
mô hình có nghĩa là một cấu trúc toán học, với việc bổ sung các diễn
giải bằng lời nhất định mô tả các hiện tượng quan sát được. Việc biện
minh cho một cấu trúc toán học như vậy là hoàn toàn và chính xác
rằng nó được mong đợi sẽ hoạt động.
—JohnvonNeumann
10.1 MÔ HÌNH ĐỊNH HƯỚNG NHÀ NƯỚC
Hệ thống phần mềm có thể được phân loại rộng rãi thành hai nhóm,
cụ thể là hệ thống không trạng thái và hệ thống định hướng trạng
thái. Các hoạt động của một hệ thống không trạng thái không phụ
thuộc vào các đầu vào trước đó của hệ thống. Trình biên dịch là một
ví dụ về hệ thống không trạng thái vì kết quả của việc biên dịch một
chương trình không phụ thuộc vào các chương trình đã được biên
dịch trước đó. Phản ứng của hệ thống đối với đầu vào hiện tại phụ
thuộc vào các đầu vào trong quá khứ của hệ thống trong một hệ
thống hướng trạng thái. Hệ thống hướng trạng thái ghi nhớ trình tự
đầu vào mà nó đã nhận được cho đến nay dưới dạng trạng thái. Hệ
thống chuyển mạch điện thoại là một ví dụ về hệ thống định hướng
trạng thái. Việc giải thích các chữ số bằng tổng đài điện thoại phụ
thuộc vào các đầu vào trước đó, chẳng hạn như điện thoại tắt máy,
chuỗi các chữ số được quay và các phím được nhấn khác.
Một hệ thống hướng trạng thái có thể được xem như có một phần
kiểm soát và một phần dữ liệu. Phần điều khiển chỉ định trình tự của
các tương tác với môi trường của nó và phần dữ liệu chỉ định dữ liệu
được xử lý và lưu. Tùy thuộc vào đặc điểm của hệ thống, một hệ
thống có thể được định hướng chủ yếu là dữ liệu, chủ yếu là định
hướng điều khiển hoặc có sự kết hợp cân bằng của cả dữ liệu và điều
khiển, như minh họa trong Hình 10.1.
368 CHƯƠNG 10 TEST THẾ HỆ TỪ CÁC MÔ HÌNH FSM
Trong một hệ thống thống trị dữ liệu, hệ thống dành phần lớn thời
gian để xử lý các yêu cầu của người dùng và trình tự tương tác với
người dùng rất đơn giản. Do đó, phần điều khiển đơn giản hơn so với
phần xử lý dữ liệu, phần phức tạp hơn. Tình huống này được mô tả
trong Hình 10.2.
265
Hệ thống phần mềm
Hệ thống định hướng trạng thái không trạng thái

systems or
reactive systems
Data-dominated Control-dominated
systems systems
Partly data dominated

and partly control
hệ thống thống trị
Hình 10.1 Phổ của hệ thống phần mềm.
Data
User Control
interactions
Hình 10.2 Các hệ thống
chi phối dữ liệu.
Thí dụ. Ứng dụng duyệt web là một ví dụ về hệ thống thống trị dữ
liệu. Hệ thống dành một lượng thời gian đáng kể để truy cập dữ liệu
từ xa bằng cách đưa ra các yêu cầu http và định dạng nó để hiển thị.
Hệ thống phản hồi mỗi đầu vào lệnh từ người dùng và không có
nhiều thông tin trạng thái mà hệ thống phải nhớ. Cần có thông tin
trạng thái là thực hiện thao tác Quay lại . Hơn nữa, duyệt web không
369
phải là một ứng dụng phụ thuộc vào thời gian, ngoại trừ sự phụ thuộc
của nó vào các hoạt động Cơ bản của Giao thức Điều khiển Truyền /
Giao thức Internet (TCP / IP).
Trong hệ thống thống trị điều khiển, hệ thống thực hiện các tương tác
phức tạp (tức là nhiều tương tác phụ thuộc vào thời gian và chuỗi
dài) với người dùng của nó, trong khi lượng dữ liệu được xử lý là
tương đối nhỏ. Do đó, phần điều khiển là một phần lớn, trong khi
chức năng xử lý dữ liệu rất nhỏ. Tình huống này được mô tả trong
Hình 10.3.
Thí dụ. Hệ thống chuyển mạch điện thoại là một ví dụ về hệ thống
thống trị điều khiển. Lượng dữ liệu người dùng được xử lý là khá
nhỏ. Dữ liệu liên quan là
10.1 MÔ HÌNH ĐỊNH HƯỚNG NHÀ NƯỚC
Data
User Control
interactions
Figure10.3 Control-dominated
systems.
ánh xạ các số điện thoại tới thông tin chi tiết thiết bị, các sự kiện liên
tục do người dùng tạo ra, số điện thoại được gọi và có thể một số sự
kiện khác được thể hiện bằng cách nhấn các phím khác trên điện
thoại.
Phần điều khiển của hệ thống phần mềm thường có thể được mô hình
hóa như một máy trạng thái hữu hạn, (FSM), nghĩa là các tương tác
giữa hệ thống và người dùng hoặc môi trường của nó (Hình 10.2 và
10.3).
Chúng tôi đã mô hình hóa các tương tác của người dùng với máy tính
xách tay khởi động kép (Hình 10.4). Ban đầu, máy tính xách tay ở
trạng thái TẮT . Khi người dùng nhấn vào
WAKEUP/msg7
LINUX
STANDBY/msg5 SHUTDOWN/ msg9
LSTND
RESTART/ msg2 LINUX/ msg1
BOOT
RESTART/ msg4
WSTND
WINDOWS/ msg3
STANDBY/msg6
WIN
ON/msg0
WAKEUP/msg8
SHUTDOWN/ msg10
OFF
Hình 10.4 Mô hình FSM của một máy tính xách tay khởi động
kép.
nút BẬT nguồn , hệ thống chuyển sang trạng thái BOOT , nơi nó
nhận một trong hai đầu vào LINUX và WINDOWS . Nếu đầu vào
của người dùng là LINUX , thì hệ thống khởi động với hệ điều hành
Linux và chuyển sang trạng thái LINUX , trong khi đầu vào
WINDOWS khiến hệ thống khởi động với hệ điều hành Windows và
chuyển sang trạng thái WIN . Cho dù máy tính xách tay đang chạy
Linux hay Windows, người dùng có thể đặt máy ở trạng thái chờ.
Trạng thái chờ cho chế độ Linux là LSTND và cho chế độ Windows
là WSTND . Máy tính có thể được đưa về trạng thái hoạt động
LINUX hoặc WIN từ trạng thái chờ LSTND hoặc WSTND tương
ứng với đầu vào WAKEUP . Máy tính xách tay có thể được di
chuyển giữa các trạng thái LINUX và WIN bằng cách sử dụng đầu
vào RESTART . Máy tính xách tay có thể được tắt bằng cách sử
dụng đầu vào SHUTDOWN khi nó ở trạng thái LINUX hoặc WIN .
Máy tính xách tay cũng có thể được đưa về trạng thái TẮT bằng
cách sử dụng nút nguồn, nhưng chúng tôi không hiển thị các chuyển
đổi này trong Hình 10.4.
Người đọc có thể lưu ý rằng với mục đích tạo các trường hợp thử
nghiệm, chúng tôi không xem xét hành vi bên trong của hệ thống;
371
thay vào đó, chúng tôi giả định rằng hành vi bên ngoài của hệ thống
đã được mô hình hóa như một FSM. Nói chính xác hơn, các tương
tác của một hệ thống với môi trường của nó được mô hình hóa dưới
dạng FSM, như được minh họa trong Hình 10.5.
Bây giờ chúng ta có thể tạo
Environment sự tương ứng giữa Hình 10.5
và 10.4. Khối hệ thống
phần mềm trong Hình 10.5
có thể được xem như phần
mềm khởi động chạy trên
Software
system máy tính xách tay, và khối
môi trường trong Hình 10.5
có thể được xem như một
người dùng. FSM được hiển
thị trong Hình 10.4 mô hình
hóa các tương tác được hiển
thị bằng các mũi tên hai
chiều trong Hình 10.5.
Mô hình FSM về hành vi bên ngoài của hệ thống mô tả trình tự đầu
vào và đầu ra dự kiến từ hệ thống. Một mô hình như vậy là một
nguồn chính của các trường hợp thử nghiệm. Trong chương này,
chúng tôi giải thích cách lấy các trường hợp kiểm thử từ mô hình
FSM.
Hình 10.5 Tương tác giữa
hệ thống và môi trường của nó được mô hình hóa
Tương tác dưới dạng FSM.
10.2 ĐIỂM KIỂM SOÁT VÀ GIÁM SÁT
10.2 ĐIỂM KIỂM SOÁT VÀ GIÁM SÁT
Điểm kiểm soát và quan sát (PCO) là một điểm tương tác được chỉ
định rõ giữa hệ thống và người dùng của nó. Chúng tôi sử dụng thuật
ngữ người dùng theo nghĩa rộng để bao gồm tất cả các thực thể, bao
gồm cả người dùng con người và các hệ thống phần mềm và phần
cứng khác, nằm bên ngoài nhưng tương tác với hệ thống đang được
xem xét. PCO có các đặc điểm sau:
PCO đại diện cho một điểm mà hệ thống nhận đầu vào từ người dùng
và / hoặc tạo ra đầu ra cho người dùng.
Có thể có nhiều PCO giữa một hệ thống và người dùng của nó.
Ngay cả khi một hệ thống đang được thử nghiệm (SUT) là một hệ
thống phần mềm, thì đối với người dùng là con người, PCO có thể
“gần gũi” với người dùng hơn so với phần mềm đang được thử
nghiệm. Ví dụ: người dùng có thể tương tác với hệ thống thông qua
nút nhấn, màn hình cảm ứng, v.v. Chúng tôi muốn nhấn mạnh rằng
ngay cả khi chúng tôi có SUT phần mềm, chúng tôi có thể không có
bàn phím và màn hình để tương tác với hệ thống.
Trong trường hợp PCO là một thực thể vật lý, chẳng hạn như nút
nhấn, bàn phím hoặc loa, thì cần phải tìm các biểu diễn máy tính của
chúng để các trường hợp kiểm tra có thể được thực thi tự động.
Thí dụ. Giả sử rằng chúng ta có một hệ thống phần mềm điều khiển
một tổng đài điện thoại PBX để cung cấp kết nối giữa những người
dùng. SUT và người dùng tương tác thông qua các hệ thống con khác
nhau của điện thoại. Chúng tôi hiển thị chi tiết giao diện người dùng
của một điện thoại cơ bản để giải thích khái niệm về PCO (Hình
10.6) và tóm tắt các chi tiết đó trong Bảng 10.1.
1 2 3
Mouthpiece Speaker
4 5 6
PCO for voice input PCO for tone and To an
voice output exchange
7 8 9
* 0 #
Hook
PCO for on and off hook inputs
Ring indicator
Keypad PCO for phone ringing
PCO for dialing
Hình 10.6 PCO trên điện thoại.
BẢNG 10.1 PCO để kiểm tra tổng đài điện thoại
Xem trong /
ngoài
PCO của Hệ Sự mô tả
thống
Cái móc Trong Hệ thống nhận các sự kiện off-hook và
373
on-hook.
Bàn phím Trong Người gọi quay số và cung cấp đầu vào
điều khiển khác.
Chỉ báo đổ Ngoài Callee nhận được chỉ báo vòng.
chuông
Loa Ngoài Người gọi nhận được âm báo (quay số,
máy bận nhanh, máy bận chậm, v.v.) và
giọng nói.
Ống ngậm Trong Người gọi tạo ra đầu vào bằng giọng nói.
1 2 3 1 2 3
4 5 6 4 5 6
7 8 9 7 8 9
* 0 # * 0 #
Local phone Remote phone

(LP ) PBX (RP )
Hình 10.7 Mô hình FSM của một PBX.

Người đọc có thể nhận thấy rằng ngay cả đối với một thiết bị đơn
giản như điện thoại, chúng ta có năm PCO riêng biệt mà qua đó
người dùng tương tác với phần mềm chuyển mạch. Trong cuộc sống
thực, người dùng tương tác với phần mềm chuyển mạch thông qua
các PCO riêng biệt này và các hệ thống thực thi kiểm tra tự động
phải nhận ra các PCO riêng biệt đó. Tuy nhiên, để làm cho cuộc thảo
luận của chúng tôi về việc tạo trường hợp thử nghiệm từ các mô hình
FSM đơn giản, rõ ràng và ngắn gọn, chúng tôi sử dụng ít PCO hơn.
Chúng tôi chỉ định tất cả PCO trên điện thoại cục bộ theo LP và tất
cả PCO trên điện thoại từ xa bằng RP (Hình 10.7).
10.3 MÁY FINITE-STATE
FSM M được định nghĩa là một bộ như sau: M = <S, I, O, s 0 , δ, λ> ,

trong đó
S là một tập hợp các trạng thái,
Tôi là một tập hợp các đầu vào,
O là một tập hợp các đầu ra,

10.3 MÁY FINITE-STATE
s 0 là trạng thái ban đầu,
δ : S × I → S là hàm trạng thái tiếp theo và λ : S × I → O là hàm đầu
ra.
Lưu ý những điểm sau liên quan đến đầu vào và đầu ra vì tầm quan
trọng của khái niệm quan sát trong thử nghiệm hệ thống:
Xác định các đầu vào và đầu ra được quan sát bằng cách chỉ định rõ
ràng một tập hợp các PCO. Đối với mỗi chuyển đổi trạng thái, chỉ
định PCO tại đó đầu vào xảy ra và đầu ra được quan sát.
Có thể có nhiều đầu ra xảy ra ở các PCO khác nhau cho một đầu vào
duy nhất trong một trạng thái.
Đặc tả FSM về các tương tác giữa người dùng và hệ thống PBX được
thể hiện trong Hình 10.8. FSM có chín trạng thái riêng biệt như được
giải thích trong Bảng 10.2.
OH
LP: ONH/ - LP: OFH/ LP: DT
AD
LP: #1/ LP: RT, LP: #2/ LP: SBT
RP: RING LP: ONH/ -
375
SB
RNG LP: NOI/ LP: NOI/ LP: FBT

LP: FBT
RP: OFH/ LP: IT, RP: IT FB LP: ONH/ -

RP: NOI/ FBT
TK
LP: NOI/ LP: IT
RP: OFH/ -
LP: ONH/ RP: IT
LP: OFH/ LP: IT LP: NOI/ LP: DT

LON
RP: ONH/ LP: IT

RON IAF
RP: ONH/ -
LP: ONH/ -
LP: ONH/ -
OH
LP: ONH / -
LP: NOI / -
Hình 10.8 Mô hình FSM của PBX.
BẢNG 10.2 Tập hợp các quốc gia trong FSM của Hình 10.8
Viết tắt Hình thức mở rộng Nghĩa
OH Trên móc
Một chiếc điện thoại đang
được kết nối.
QUẢNG CÁO Thêm chữ số Người dùng đang quay số.
SB Bận chậm Hệ thống đã tạo ra một âm báo
bận chậm.
FB Bận chậm Hệ thống đã tạo ra một âm báo
bận nhanh.
RNG Vòng Điện thoại từ xa đang đổ
chuông.
TK Nói chuyện Một kết nối được thiết lập.
LON Cục bộ trên móc Điện thoại địa phương đang
kết nối.
RON Điều khiển từ xa trênĐiện thoại từ xa đang được kết
móc nối.
IAF Không hoạt động sau Điện thoại địa phương không
khi bận rộn nhanhhoạt động sau một thời gian
chóng bận rộn.
BẢNG 10.3 Bộ đầu vào và đầu ra trong FSM của Hình 10.8
Đầu vào Đầu ra
OFH: Tắt móc DT: Âm quay
số
ONH: Bắt đầu RING: Chuông
điện thoại
# 1: Số điện thoại hợp lệ RT: Nhạc
chuông
# 2: Số điện thoại không SBT: Âm báo
hợp lệ bận chậm
NOI: Không có đầu vào FBT: Âm báo
bận nhanh
IT: Giai điệu
nhàn rỗi
-: Không quan
tâm
Trạng thái ban đầu của FSM là OH, xuất hiện hai lần trong Hình
10.8, vì chúng tôi muốn tránh vẽ các đường chuyển tiếp từ các trạng
thái LON, RON và IAF trở lại trạng thái xuất hiện đầu tiên của OH ở
trên cùng.
Có năm ký hiệu đầu vào riêng biệt (Bảng 10.3) được FSM chấp
nhận. NOI đại diện cho người dùng không hành động; nghĩa là người
dùng không bao giờ cung cấp đầu vào ở một trạng thái nhất định.
Chúng tôi đã giới thiệu khái niệm NOI rõ ràng vì chúng tôi muốn mô
tả hành vi của một hệ thống mà không giới thiệu các sự kiện bên
trong, chẳng hạn như thời gian chờ. Có bảy biểu tượng đầu ra, một
trong số đó biểu thị đầu ra không quan tâm. Đầu ra không quan tâm
là trường hợp không có đầu ra hoặc đầu ra tùy ý bị người dùng bỏ
qua.
Có hai PCO trừu tượng được sử dụng trong FSM của Hình 10.8.
Chúng được gọi là LP và RP để đại diện cho một điện thoại cục bộ
được người gọi sử dụng và một điện thoại từ xa được đại diện bởi
377
callee, tương ứng. Chúng tôi gọi PCO trừu tượng LP và RP vì mỗi
LP và RP đại diện cho năm PCO thực, riêng biệt, như được giải thích
trong Phần 10.2. Các phần đầu vào và đầu ra của quá trình chuyển
đổi trạng thái được biểu diễn như sau:
PCO i : a
PCO j : b
10.5 PHƯƠNG THỨC CHUYẾN DU LỊCH
trong đó đầu vào a xảy ra ở PCO i và đầu ra b xảy ra ở PCO j . Nếu
một chuyển đổi trạng thái tạo ra nhiều đầu ra, chúng tôi sử dụng ký
hiệu
PCO i : a
trong đó đầu vào a xảy ra ở PCO i , đầu ra b xảy ra ở PCO j và đầu ra

c xảy ra ở PCO k . Chúng tôi sẽ trình bày một quá trình chuyển đổi
hoàn chỉnh bằng cú pháp sau:
< trạng thái hiện tại, đầu vào, đầu ra, trạng thái tiếp theo > hoặc <
trạng thái hiện tại, đầu vào / đầu ra, trạng thái tiếp theo >
Sự chuyển đổi trạng thái < OH, LP: OFH, LP: DT, AD > có nghĩa là
nếu FSM ở trạng thái OH và nhận đầu vào OFH (tắt móc) tại cổng
(PCO) LP, nó tạo ra đầu ra DT (âm quay số) tại cùng một cổng LP và
chuyển sang trạng thái AD (Hình 10.8).
10.4 TEST THẾ HỆ TỪ AN FSM
Với mô hình FSM M về các yêu cầu của hệ thống và I M của M triển
khai , nhiệm vụ kiểm tra ngay lập tức là xác nhận rằng việc triển khai
I M hoạt động như M quy định . Quá trình thử nghiệm xác minh rằng một
triển khai tuân theo đặc điểm kỹ thuật của nó được gọi là thử nghiệm
sự phù hợp. Ý tưởng cơ bản trong kiểm tra sự phù hợp được tóm tắt
như sau:
Nhận dãy chuyển đổi trạng thái từ M.
Biến mỗi chuỗi chuyển trạng thái thành một chuỗi thử nghiệm.
Kiểm tra I M với một tập hợp các trình tự thử nghiệm và quan sát xem
I M có sở hữu các chuỗi chuyển trạng thái tương ứng hay không.
Sự phù hợp của I M với M có thể được xác minh bằng cách cẩn thận
chọn đủ các chuỗi chuyển trạng thái từ M.
Trong các phần tiếp theo, trước tiên, chúng tôi giải thích các cách để
biến một chuỗi chuyển đổi trạng thái thành một chuỗi thử nghiệm.
Tiếp theo, chúng tôi giải thích quá trình lựa chọn các trình tự chuyển
đổi trạng thái khác nhau.
Trong phần này, chúng ta thảo luận về một quy trình để tạo ra một
trình tự thử nghiệm hoặc trường hợp thử nghiệm T c từ một trình tự
chuyển đổi trạng thái S t của một FSM M nhất định . Cụ thể, chúng
tôi xem xét các chuyến tham quan chuyển tiếp, trong đó chuyến tham
quan chuyển tiếp là một chuỗi các chuyển đổi trạng thái bắt đầu và
kết thúc ở trạng thái ban đầu. Naito và Tsunoyama [1] đã giới thiệu
phương pháp tham quan chuyển tiếp để tạo các trường hợp thử
nghiệm từ các thông số kỹ thuật FSM của các mạch tuần tự. Sarikaya
và Bochmann [2] là những người đầu tiên nhận thấy rằng phương
pháp tham quan chuyển tiếp có thể được áp dụng cho thử nghiệm
giao thức. Ví dụ về chuyến tham quan chuyển tiếp thu được từ
Test system
(Test sequence
)
PCO 1
SUT
PCO 2
Hình 10.9 Tương tác của trình tự thử nghiệm

với SUT.
Hình 10.8 như sau: < OH, LP: OFH, LP: DT, AD > , < AD, LP:
ONH, LP:
-, OH > . Người ta có thể dễ dàng xác định các thành phần trạng thái,
đầu vào và đầu ra mong đợi trong trình tự của Hình 10.8. Tuy nhiên,
có thể lưu ý rằng một trường hợp kiểm thử không chỉ đơn thuần là
một chuỗi các cặp < đầu vào, đầu ra mong đợi > , mà một trường hợp
kiểm thử hoàn chỉnh phải chứa hành vi bổ sung để nó có thể được
thực thi một cách tự động ngay cả khi SUT có lỗi. Hệ thống thử
nghiệm tương tác với SUT được thể hiện trong Hình 10.9. Một hệ
thống kiểm thử bao gồm một tập hợp các trường hợp thử nghiệm và
379
một bộ lập lịch trường hợp thử nghiệm. Bộ lập lịch quyết định trường
hợp thử nghiệm sẽ được thực hiện tiếp theo tùy thuộc vào các ràng
buộc phụ thuộc trường hợp thử nghiệm được chỉ định bởi nhà thiết
kế thử nghiệm. Một ca kiểm thử đang thực thi tạo ra các đầu vào cho
SUT và nhận các đầu ra từ SUT. Rõ ràng là một SUT bị lỗi có thể tạo
ra một đầu ra khác với đầu ra mong đợi, và đôi khi nó có thể không
tạo ra bất kỳ đầu ra nào. Do đó, hệ thống kiểm tra phải có khả năng
xử lý các trường hợp ngoại lệ này ngoài các trường hợp thông
thường. Ý tưởng này dẫn chúng ta đến việc hình thức hóa quy trình
thiết kế một trường hợp thử nghiệm hoàn chỉnh sau đây:
Một ca kiểm thử chứa một chuỗi dữ liệu đầu vào và đầu ra dự kiến.
Thông tin này được lấy từ đặc tả FSM của SUT.
Một trường hợp thử nghiệm phải được chuẩn bị để nhận các đầu ra
không mong muốn từ SUT.
Một trường hợp thử nghiệm không được đợi vô thời hạn để nhận
được kết quả đầu ra — dự kiến hoặc không mong đợi.
Ví dụ: Transition Tour. Chúng ta hãy suy ra một trường hợp kiểm
tra từ trình tự chuyển đổi trạng thái < OH, LP: OFH, LP: DT, AD > ,
< AD, LP: ONH, LP: -, OH > . Sẽ rất hữu ích khi tham khảo PCO
của Hình 10.9, giải thích mối quan hệ đầu vào - đầu ra giữa hệ thống
thử nghiệm và SUT. Một chuỗi các đầu vào cho SUT có thể thu được
từ mô hình FSM của nó. Ví dụ, chuỗi chuyển đổi trạng thái chứa
chuỗi đầu vào { OFH, ONH } . Do đó, hệ thống kiểm tra phải tạo ra
một chuỗi đầu ra { OFH, ONH } cho SUT. Do đó, đầu vào trong
chuỗi chuyển đổi trạng thái của FSM là đầu ra của hệ thống thử
nghiệm tại cùng một PCO. Đầu ra được biểu diễn bằng cách đặt
trước dấu chấm than ('!') Cho một sự kiện (hoặc tin nhắn)
1 LP! OFH
2 BẮT ĐẦU (TIMER1, d1)
3 LP? DT ĐI
QUA
4 HỦY (TIMER1)
5 LP! ONH
6 LP? KHÁC THẤT
BẠI
7 HỦY (TIMER1)
số 8 LP! ONH
9 ? TIMER1 THẤT
BẠI
10 HỦY (TIMER1)
11 LP! ONH
Hình 10.10 Trường hợp thử nghiệm phát sinh từ chuyến tham
quan chuyển tiếp.
trong Hình 10.10. Trong dòng 1 của Hình 10.10, LP! OFH có nghĩa
là hệ thống thử nghiệm xuất ra một sự kiện OFH tại PCO LP.
Một đầu ra được tạo ra trong quá trình chuyển đổi trạng thái của
FMS M được hiểu là đầu ra dự kiến của một I M thực hiện . Đôi khi việc
triển khai bị lỗi có thể tạo ra kết quả đầu ra không mong muốn. Đầu
ra của SUT trở thành đầu vào của hệ thống thử nghiệm. Do đó, một
đầu ra trong trình tự chuyển đổi trạng thái của FSM là đầu vào cho hệ
thống thử nghiệm tại cùng một PCO. Trong Hình 10.10, một đầu vào
được biểu diễn bằng cách thêm dấu chấm hỏi ('?') Vào trước một sự
kiện (hoặc tin nhắn). Do đó, trong dòng 3 của Hình 10.10, LP? DT có
nghĩa là hệ thống kiểm tra đã sẵn sàng nhận DT đầu vào tại PCO LP.
Ở đây hệ thống kiểm tra mong đợi nhận được một DT đầu vào tại
PCO LP, đã được chỉ định là LP? DT. Tuy nhiên, một SUT bị lỗi có
thể tạo ra một đầu ra không mong muốn thay vì đầu ra DT mong đợi
ở PCO LP. Ở dòng 6, hệ thống kiểm tra sẵn sàng nhận bất kỳ sự kiện
nào khác ngoài DT tại PCO LP. Người đọc có thể nhận thấy rằng
LP? DT ở dòng 3 và LP? OTHERWISE ở dòng 6 xuất hiện ở cùng
một mức độ thụt lề và cả hai dòng đều có cùng hành động tiền nhiệm
ngay START (TIMER1, d1) ở dòng 2.
Nếu một SUT không tạo ra bất kỳ đầu ra nào — dự kiến hoặc không
mong muốn — thì hệ thống thử nghiệm và SUT sẽ bị bế tắc, điều này
được ngăn chặn bằng cách đưa vào cơ chế thời gian chờ trong hệ
thống thử nghiệm. Trước khi hệ thống thử nghiệm bắt đầu chờ đầu
vào, hệ thống này sẽ khởi động một bộ hẹn giờ trong khoảng thời
gian nhất định như được hiển thị trong dòng 2. Tên của bộ hẹn giờ là
TIMER1 ở dòng 2 và khoảng thời gian chờ của nó là d1. Nếu SUT
không tạo ra đầu ra dự kiến DT hoặc bất kỳ đầu ra nào khác trong
khoảng thời gian d1 sau khi nhận OFH đầu vào tại PCO LP, hệ thống
381
kiểm tra sẽ tạo ra một sự kiện thời gian chờ nội bộ được gọi là
TIMER1, sự kiện này sẽ được nhận ở dòng 9. Một trong các các sự
kiện được chỉ định trong dòng 3, 6 và 9 cuối cùng xảy ra. Điều này
có nghĩa là hệ thống thử nghiệm không bị bế tắc khi có SUT bị lỗi.
Chỉ số mức độ phù hợp để chọn chuyến tham quan chuyển tiếp.
Người ta có thể thiết kế một trường hợp thử nghiệm từ một chuyến
tham quan chuyển tiếp. Một chuyến tham quan chuyển tiếp có thể
không đủ để bao gồm toàn bộ FSM, trừ khi đó là một chuyến tham
quan dài. Xem xét yêu cầu bắt buộc phải đơn giản hóa thiết kế thử
nghiệm và chỉ kiểm tra một phần nhỏ của việc triển khai với một
trường hợp thử nghiệm, cần phải thiết kế nhiều trường hợp thử
nghiệm. Một câu hỏi thường xuyên là: Một trong những trường hợp
thử nghiệm nên thiết kế bao nhiêu trường hợp? Do đó, cần phải xác
định một số chuyến tham quan chuyển tiếp từ FSM. Khái niệm về số
liệu mức độ phù hợp được sử dụng trong việc lựa chọn một tập hợp
các chuyến tham quan chuyển tiếp. Để kiểm tra việc triển khai dựa
trên FSM, hai chỉ số mức độ phù hợp thường được sử dụng là:
Phạm vi bảo hiểm của tiểu bang
Phạm vi chuyển tiếp
Chuyến tham quan chuyển tiếp cho phạm vi bảo hiểm của bang.
Chúng tôi chọn một tập hợp các chuyến tham quan chuyển tiếp sao
cho mọi trạng thái của FSM đều được tham quan ít nhất một lần để
đạt được tiêu chí về phạm vi bảo hiểm này. Chúng tôi đã xác định ba
chuyến tham quan chuyển tiếp, như được thể hiện trong Bảng 10.4,
để bao quát tất cả các trạng thái của FSM được thể hiện trong Hình
10.8. Người ta có thể dễ dàng thu được các chuỗi thử nghiệm từ ba
chuyến tham quan chuyển tiếp trong Bảng 10.4 theo các nguyên tắc
thiết kế được giải thích trong Phần 10.5 để chuyển một hành trình
chuyển tiếp thành một trình tự thử nghiệm. Mức độ bao phủ của tiểu
bang là yếu nhất trong số tất cả các tiêu chí lựa chọn được sử dụng để
tạo chuỗi thử nghiệm từ FSM. Ba chuyến tham quan chuyển tiếp
được thể hiện trong Bảng 10.4 bao gồm mọi trạng thái của FSM
được thể hiện trong Hình 10.8 ít nhất một lần. Tuy nhiên, trong số 21
chuyến chuyển tiếp bang, chỉ có 11 chuyến được bao phủ bởi ba
chuyến du lịch chuyển tiếp. 10 chuyển đổi trạng thái không được đề
cập trong ba hành trình chuyển tiếp đó được liệt kê trong Bảng 10.5.
Tiếp theo, chúng tôi xem xét một dạng tiêu chí bảo hiểm mạnh hơn,
đó là, phạm vi bảo hiểm chuyển tiếp.
Chuyến tham quan chuyển tiếp cho phạm vi bảo hiểm chuyển
tiếp. Chúng tôi chọn một tập hợp các chuyến tham quan chuyển tiếp
để mọi chuyển đổi trạng thái của FSM đều được tham quan ít nhất
một lần để đạt được tiêu chí về phạm vi bảo hiểm này. Chúng tôi đã
xác định chín hành trình chuyển tiếp, như được thể hiện trong Bảng
10.6, để bao gồm tất cả các chuyển đổi trạng thái của FSM được thể
hiện trong Hình 10.8. Người ta có thể dễ dàng thu được các chuỗi thử
nghiệm từ chín chuyến tham quan chuyển tiếp trong Bảng 10.6 theo
các nguyên tắc thiết kế được giải thích trong Phần 10.5 để chuyển
một chuyến tham quan chuyển tiếp thành một trình tự thử nghiệm.
BẢNG 10.4 Các chuyến tham quan chuyển tiếp bao gồm tất cả
các quốc gia trong Hình 10.8
Chuyến tham quan chuyển đổi số sê-ri
< OH, LP: OFH / LP: DT, AD > ; < AD, LP: # 2 / LP: SBT,
OH, AD, SB, FB, IAF SB > ; < SB, LP: NOI / LP: FBT, FB >
; < FB,
LP: NOI / LP: IT, IAF > ; < IAF, LP: ONH / -, OH >
< OH, LP: OFH / LP: DT, AD > ; < AD, LP: # 1 / { LP: RT,
OH, AD, RNG, TK, LON
RP: RING } , RNG > ; < RNG, RP: OFH / { LP: IT, RP: IT } ,
TK > ; < TK, LP: ONH / RP: IT, LON > ; < LON,
LP: NOI / -, OH >
< OH, LP: OFH / LP: DT, AD > ; < AD, LP: # 1 / { LP: RT,
OH, AD, RNG, TK, RON
RP: RING } , RNG > ; < RNG, RP: OFH / { LP: IT, RP: IT } ,
TK > ; < TK, RP: ONH / LP: IT, RON > ; < RON,
LP: ONH / -, OH >
10.6 KIỂM TRA VỚI SỰ KIỂM ĐỊNH CỦA NHÀ NƯỚC

BẢNG 10.5 Chuyển đổi trạng thái Không
Bao gồm các chuyến tham quan chuyển tiếp của Bảng 10.4
Chuyển đổi trạng thái số sê-ri

383
< AD, LP: ONH / -, OH >
< AD, LP: NOI / LP: FBT, FB >
< SB, LP: ONH / -, OH >
< FB, LP: ONH / -, OH >
< LON, LP: OFH / LP: IT, TK > 6 < LON, RP: ONH / -, OH >
< RON, RP: OFH / -, TK >
< RON, LP: NOI / LP: DT, AD > 9 < RNG, LP: ONH / -, OH >
10 < RNG, RP: NOI / FBT, FB >
BẢNG 10.6 Chuyến tham quan chuyển tiếp bao gồm tất cả các
chuyển đổi trạng thái trong Hình 10.8
Nối tiếp
Con số Chuyến tham quan chuyển tiếp
1 < OH, LP: OFH / LP: DT, AD > ; < AD, LP: # 2 / LP: SBT,
SB > ; < SB, LP: NOI / LP: FBT, FB > ; < FB, LP: NOI /
LP: IT, IAF > ; < IAF, LP: ONH / -, OH >
2 < OH, LP: OFH / LP: DT, AD > ; < QUẢNG CÁO, LP: # 1
/ \ { LP: RT, RP: RING \} , RNG > ; < RNG, RP: OFH / {
LP: IT, RP: IT } , TK > ; < TK, LP: ONH / RP: IT, LON > ;
< LON, LP: NOI / -, OH >
3 < OH, LP: OFH / LP: DT, AD > ; < AD, LP: # 1 / { LP: RT,
RP: RING } , RNG > ; < RNG, RP: OFH / { LP: IT, RP: IT
} , TK > ; < TK, RP: ONH / LP: IT, RON > ; < RON, LP:
ONH / -, OH >
4 < OH, LP: OFH / LP: DT, AD > ; < AD, LP: # 2 / LP: SBT,
SB > ; < SB, LP: ONH / -, OH > ;
5 < OH, LP: OFH / LP: DT, AD > ; < AD, LP: NOI / LP:
FBT, FB > ; < FB, LP: ONH / -, OH >
} , TK > ; < TK, LP: ONH / RP: IT, LON > ; < LON,
LP: OFH / LP: CNTT, TK > ; < TK, RP: ONH / LP: IT,
RON > ; < RON, RP: OFH / -,
TK > ; < TK, LP: ONH / RP: IT, LON > ; < LON, LP:
NOI / -, OH >
} , TK > ; < TK, RP: ONH / LP: IT, RON > ; < RON, LP:
NOI / LP: DT, AD > ; < AD, LP: ONH / LP: DT, OH >
số 8 < OH, LP: OFH / LP: DT, AD > ; < AD, LP: # 1 / { LP: RT,
RP: RING } , RNG > ; < RNG, LP: ONH / -, OH >
RP: RING } , RNG > ; < RNG, RP: NOI / FBT, FB > ; <
Initial state State transition under test
FB, LP: ONH / -, OH >
s0
10.6 KIỂM TRA VỚI SỰ
Transfer sequence KIỂM ĐỊNH CỦA NHÀ
NƯỚC
si sj
a/b
Reset sequence
sk
State verificationquence
se
Có hai hàm liên quan đến sự chuyển đổi trạng thái, đó là, một hàm
đầu ra ( λ ) và một hàm trạng thái tiếp theo ( δ ). Các trường hợp thử
nghiệm được tạo bằng cách sử dụng phương pháp tham quan chuyển
tiếp được thảo luận trong Phần 10.5 tập trung vào các kết quả đầu ra.
Bây giờ chúng ta thảo luận về một phương pháp
Hình 10.11 Mô hình khái niệm của trường hợp kiểm thử với xác
minh trạng thái.
để tạo các trường hợp thử nghiệm bằng cách nhấn mạnh vào cả đầu
ra và trạng thái tiếp theo của mọi chuyển đổi trạng thái của FSM. Dễ
dàng xác minh kết quả đầu ra vì chúng xuất hiện tại PCO, bên ngoài
hệ thống đang thử nghiệm. Tuy nhiên, việc xác minh trạng thái tiếp
theo của quá trình chuyển đổi trạng thái không phải là một nhiệm vụ
dễ dàng vì khái niệm trạng thái hoàn toàn là nội tại của một SUT.
Trạng thái tiếp theo của quá trình chuyển đổi trạng thái được xác
minh bằng cách áp dụng thêm các đầu vào cho SUT và quan sát phản
ứng của nó tại các PCO. Mô hình khái niệm về phương pháp tạo các
trường hợp thử nghiệm từ FSM với cả xác minh đầu ra và trạng thái
được minh họa trong Hình 10.11. Năm bước của phương pháp được
giải thích như sau. Phương pháp này được giải thích từ quan điểm
385
của việc kiểm tra sự chuyển đổi trạng thái từ trạng thái s i sang s j với
đầu vào a .
Phương pháp kiểm tra với xác minh của nhà nước
Bước 1: Giả sử rằng FSM đang ở trạng thái ban đầu, hãy chuyển
FSM từ trạng thái ban đầu s 0 sang trạng thái s i bằng cách áp dụng
một chuỗi các đầu vào được gọi là chuỗi truyền ký hiệu là T (s i ) . Có
thể lưu ý rằng các trạng thái khác nhau sẽ có các trình tự chuyển khác
nhau, nghĩa là . Đối với trạng thái tôi ,
T (s i ) có thể được lấy từ FSM. Vào cuối bước này, FSM ở
trạng thái s i .
Bước Trong bước này, chúng tôi áp dụng đầu vào a cho SUT và
2: quan sát đầu ra thực tế của nó, được so sánh với đầu ra dự
kiến b của FSM. Vào cuối bước này, một quá trình chuyển
đổi trạng thái được thực hiện chính xác sẽ đưa SUT sang
trạng thái mới s j . Tuy nhiên, một triển khai bị lỗi có thể đưa
nó đến một trạng thái khác với s j . Trạng thái mới của SUT
được xác minh trong bước sau.
Bước Áp dụng trình tự xác minh VER j cho SUT và quan sát trình
3: tự đầu ra tương ứng. Một thuộc tính quan trọng của VER j là
λ (s j , VER , VER . Ở cuối bước này,
SUT ở trạng thái s k .
Bước Di chuyển SUT trở lại trạng thái ban đầu s 0 bằng cách áp
4: dụng trình tự đặt lại RI. Giả định rằng một SUT đã thực hiện
đúng cơ chế đặt lại.
Bước Lặp lại các bước 1–4 cho tất cả các chuyển đổi trạng thái
5: trong FSM đã cho.
Đối với một chuyển đổi đã chọn từ trạng thái s i sang trạng thái s j với
đầu vào a , bốn bước trên tạo ra một chuyến tham quan chuyển tiếp
được xác định bởi trình tự đầu vào T (s i ) @ a @VER j @RI được áp
dụng cho hệ thống ở trạng thái ban đầu s 0 . Ký hiệu '@' đại diện cho
sự kết hợp của hai chuỗi. Áp dụng các nguyên tắc thiết kế thử
nghiệm được thảo luận trong Phần 10.5, người ta có thể rút ra một
trường hợp thử nghiệm từ các chuyến tham quan chuyển tiếp như
vậy. Việc xác định chuỗi chuyển T (s i ) ra khỏi chuỗi đầu vào T (s i )
@ a @VER j @RI cho trạng thái s i là một công việc đơn giản. Tuy
nhiên, nó không phải là tầm thường để xác minh trạng thái tiếp theo
của một triển khai. Có ba loại trình tự đầu vào thường được sử dụng
để xác minh trạng thái tiếp theo của SUT. Các trình tự đầu vào này
như sau:
Trình tự đầu vào-đầu ra duy nhất
Phân biệt trình tự • Trình tự đặc trưng
Trong các phần sau, chúng tôi giải thích ý nghĩa của ba loại trình tự
đầu vào và các cách để tạo ra các loại trình tự đó.
10.7 YÊU CẦU ĐẦU VÀO DUY NHẤT
Chúng tôi xác định một chuỗi đầu vào-đầu ra (UIO) duy nhất và giải
thích một thuật toán để tính chuỗi UIO từ FSM M = <S, I, O, s 0 , δ,
λ> , trong đó S , I , O , s 0 , δ , và λ đã được giải thích trong Phần
10.3. Đầu tiên, chúng tôi mở rộng ngữ nghĩa của δ và λ như sau:
Chúng tôi mở rộng miền của λ và δ để bao gồm các chuỗi ký hiệu
đầu vào. Ví dụ: đối với trạng thái s 0 và chuỗi đầu vào x = a 1 , ..., a k ,
chuỗi đầu ra tương ứng được ký hiệu là λ (s 0 , x) = b 1 , ..., b k , trong
đó và trạng thái cuối

cùng là
Tương tự, chúng tôi mở rộng miền và phạm vi của các hàm chuyển
đổi và đầu ra để bao gồm các tập hợp trạng thái. Ví dụ, nếu Q là một
tập các trạng thái và x là một chuỗi đầu vào, thì δ (Q, x) = {δ (s, x) | s
∈ Q} .
Nếu x và y là hai chuỗi đầu vào, ký hiệu x @ y biểu thị sự nối hai
chuỗi theo thứ tự đó.
Tiếp theo, chúng tôi xác định bốn thuộc tính của FSM như sau. Các
thuộc tính này rất cần thiết cho việc tính toán các chuỗi UIO.
387
Chỉ định hoàn toàn: Một FSM M được cho là hoàn toàn xác định nếu
đối với mỗi đầu vào a ∈ I có một chuyển trạng thái được xác định tại
mỗi trạng thái của M.
Tính xác định: Một FSM M được cho là xác định nếu (i) đối với mỗi
đầu vào a ∈ I có nhiều nhất một chuyển đổi trạng thái được xác định
tại mỗi trạng thái của M và (ii) không có sự kiện bên trong gây ra
chuyển đổi trạng thái trong FSM. Thời gian chờ là một ví dụ về các
sự kiện nội bộ có thể gây ra chuyển đổi trạng thái.
Giảm: Một FSM M được cho là giảm nếu đối với bất kỳ cặp trạng
thái nào là i và , có một chuỗi đầu vào y sao cho
.
Theo trực quan, FSM bị giảm nếu không có hai trạng thái nào tương
đương, nghĩa là tồn tại một chuỗi đầu vào phân biệt trạng thái này
với trạng thái khác.
Được kết nối mạnh mẽ: FSM M được cho là được kết nối mạnh mẽ
nếu có thể truy cập được bất kỳ trạng thái nào từ bất kỳ trạng thái nào
khác.
Chuỗi đầu vào-đầu ra y / λ (s i , y) được cho là chuỗi UIO cho trạng
thái s i nếu và chỉ khi . Hsieh [3]
đã đưa ra khái niệm về trình tự đầu vào - đầu ra đơn giản vào năm
1971 để xác định FSM. Sabnani và Dahbura [4] là những người đầu
tiên sử dụng thuật ngữ chuỗi UIO và áp dụng khái niệm này để thử
nghiệm các giao thức truyền thông. Sau đây, một thuật toán hiệu quả
để tính toán chuỗi UIO được giải thích [5].
Cho một FSM M , vectơ đường dẫn là tập hợp các cặp trạng thái
có hai thuộc tính sau: (i) biểu thị
trạng thái đầu và đuôi tương ứng của một đường dẫn, trong đó một
đường dẫn là một chuỗi các chuyển đổi trạng thái; (ii) một chuỗi đầu
vào - đầu ra giống hệt nhau được liên kết với tất cả các đường dẫn
trong véc tơ đường dẫn. Cho một vectơ đường đi PV
, vectơ ban đầu (IV) là một tập hợp có thứ
tự các trạng thái đầu của PV, nghĩa là, IV (PV) = (s 1 , ..., s i , ..., s k ) .
Tương tự, vectơ hiện tại (CV) là tập hợp có thứ tự các trạng thái đuôi
của PV, nghĩa là CV (PV) . Một vectơ đường dẫn
được cho là một vectơ singleton nếu nó chứa chính xác một cặp trạng
thái. Một vectơ đường đi được cho là một vectơ đồng nhất nếu tất cả
các phần tử của CV (PV) là giống hệt nhau. Có thể lưu ý rằng một
vectơ singleton cũng là một vectơ thuần nhất. Đối với FSM cấp n ,
chúng tôi xác định một vectơ đường dẫn ban đầu duy nhất (s 1 / s 1
, ..., s i / s i , ..., s n / s n ) sao cho một đường dẫn rỗng được liên kết với
tất cả các cặp trạng thái.
Cho một vectơ đường dẫn và nhãn đầu vào - đầu ra a / b của một quá
trình chuyển đổi, nhiễu loạn vectơ có nghĩa là tính toán một vectơ
đường dẫn mới PV từ PV và a / b . Được
PV và nhãn chuyển tiếp a / b , sự nhiễu
loạn của PV đối với nhãn cạnh a / b , ký hiệu là PV ,
được định nghĩa là
PV . Chúng tôi có thể
xáo trộn vô hạn tất cả các vectơ đường dẫn cho tất cả các nhãn
chuyển tiếp với FSM giảm và vectơ đường dẫn ban đầu của nó.
Người ta có thể hình dung hàm nhiễu loạn PV là một
cạnh từ PV nút đến PV nút mới với nhãn cạnh a / b . Ngoài ra, với
PV đã cho và tập nhãn chuyển tiếp L , chúng ta có thể sắp xếp | L |
mới | các nút { pert ( PV , a / b) ∀ a / b ∈ L} trên một mức. Có nghĩa
là, tất cả các vectơ đường đi của một FSM nhất định có thể được sắp
xếp dưới dạng một cây với các mức liên tiếp 1, 2, ... , ∞ . Cây như
vậy được gọi là cây UIO. Có thể lưu ý rằng bằng đồ thị một vectơ
đường dẫn được biểu thị bằng hai hàng trạng thái — hàng trên cùng
biểu thị IV (PV) và hàng dưới cùng biểu thị CV (PV). Về mặt lý
thuyết, cây UIO là cây có cấp độ vô hạn. Tuy nhiên, chúng ta cần cắt
tỉa cây dựa trên một số điều kiện, gọi là điều kiện cắt tỉa. Sau mỗi PV
nhiễu loạn , chúng tôi kiểm tra các điều kiện sau:
C1: CV (PV ) là một vectơ thuần nhất hoặc một vectơ singleton.
C2: Trên đường đi từ vectơ ban đầu đến PV, tồn tại PV như vậy mà
PV .
Trong khi xây dựng cây UIO, nếu một trong các điều kiện cắt tỉa
được thỏa mãn, chúng tôi tuyên bố PV là một vectơ đường dẫn đầu
cuối. Cho một cây UIO và một trạng thái s i của FSM, s i có một
chuỗi UIO nếu và chỉ khi cây UIO thu được từ M có một vectơ
đường đi đơn sao cho v i = IV (ψ) , tức là, v i là vectơ ban đầu của
singleton ψ . Chuỗi đầu vào - đầu ra được liên kết với các cạnh của
đường dẫn từ véc tơ đường dẫn ban đầu đến véc tơ đường dẫn
singleton là một chuỗi trạng thái UIO được tìm thấy trong véc tơ ban
389
đầu của đường đơn. Sau đây, chúng tôi trình bày một thuật toán để
tính cây UIO hữu hạn từ FSM.
Thuật toán. Tạo cây UIO
Đầu vào: M = <S, I, O, δ, λ > và L.
Đầu ra: cây UIO.
Phương pháp: Thực hiện các bước sau:
Bước 1: Để là tập các vectơ đường dẫn trong cây UIO. Ban đầu,
chứa vectơ ban đầu được đánh dấu là danh nghĩa.
Bước 2: Tìm một thành viên danh nghĩa chưa bị xáo trộn. Nếu
không có thành viên nào như vậy tồn tại, thì thuật toán kết thúc.
Bước 3: Tính toán và bổ sung
.
Đánh dấu ψ là bị xáo trộn và cập nhật cây UIO.
Bước 4: Nếu pert (ψ, a i / b i ) , được tính ở bước 3 , thỏa mãn
điều kiện kết thúc C1 hoặc C2 , thì đánh dấu ψ như một nút đầu cuối.
A Bước 5: Chuyển sang bước 2 .
0/0
Thí dụ. Xem xét FSM G 1 = <S, I, O, A, δ,
1/0 0/0 λ> của Hình 10.12, trong đó S = {A, B, C,
D} là tập hợp các trạng thái, I = { 0 , 1 } là
C B
1/0 tập hợp các đầu vào, O = { 0 , 1 } là tập
0/1 hợp các đầu ra, A là trạng thái ban đầu, δ :
1/0 S × I → S là hàm trạng thái tiếp theo và λ :
1/0
D 0/1
S × I → O là hàm đầu ra. Tập hợp các nhãn
chuyển tiếp riêng biệt được cho bởi L =
{ 0/0 , 0/1 , 1/0 } . Vectơ đường dẫn ban đầu được cho bởi
Hình 10.12 Máy trạng thái hữu hạn G 1 (Từ tham chiếu 5. © 1997
IEEE.)
ψ 1 = (A / A, B / B, C / C, D / D) và bị xáo trộn khi sử dụng tất cả các
thành viên của L như sau:
(A / B, B / A) = pert ( ψ 1 , 0/0 ) (C / D, D / D) = pert (ψ 1 , 0/1 ) (A /
D , B / B, C / A , D / C) = pert ( ψ 1 , 1/0 )
Bây giờ, chúng ta biểu diễn cây UIO ở dạng đồ họa. Chúng ta đặt ba
cạnh từ vectơ đường đi ban đầu ψ 1 = (A / A, B / B, C / C, D / D) đến
vectơ đường dẫn (A / B, B / A) , (C / D, D / D ) , và (A / D, B / B, C /
A, D / C) với các nhãn chuyển tiếp lần lượt là 0/0 , 0/1 và 1/0 , như
trong Hình 10.13. Người đọc có thể nhớ lại rằng
ABCD
ABCD
0/0 0/1 1/0
AB CD ABCD
BA DD DBAC
0/0 1/0
AB AB
AB BD
0/0 1/0
0/1
A B AB
A D BC
0/0 0/1 1/0
A B AB
A D BA 0/0 0/1 1/0
BC AD ABCD
AB DD CBDA
0/0 0/0
1/0 0/1 1/0
BC BC BD AC ABCD
BA DB AB DD ABCD
0/0 1/0
0/1 0/0 1/0
C B BC BD
A D CB BD
BA DB
0/0 1/0 0/0 1/0
0/1 0/1
C B BC D B BD
A D AB A D CB
0/0 0/1 1/0
D B BD
A D AB
Hình 10.13 Cây UIO cho G 1 trong Hình 10.12. (Từ bản tham
khảo 5. © 1997 IEEE.)
vectơ đường dẫn (C / D, D / D) là một nút đầu cuối vì vectơ hiện tại
của nó (D, D) là một vectơ thuần nhất. Do đó, vectơ đường dẫn (C /
D, D / D) không bị xáo trộn nữa, trong khi hai vectơ đường dẫn còn
lại (A / B, B / A) và (A / D, B / B, C / A, D / C ) bị xáo trộn thêm,
như thể hiện trong Hình 10.13. Một cây UIO hoàn chỉnh được thể
hiện trong Hình 10.13.
Hình 10.13 được vẽ lại dưới dạng Hình 10.14 bằng cách tô sáng một
chuỗi UIO có độ dài tối thiểu cho mỗi trạng thái. Chúng tôi đã xác
định bốn vectơ đường dẫn singleton, cụ thể là, (A / A) , (B / D) , (C /
A) và (D / A) , và đánh dấu các đường dẫn tương ứng dẫn đến chúng
391
từ vectơ đường dẫn ban đầu. Chúng tôi hiển thị trình tự UIO của bốn
trạng thái trong Bảng 10.7.
ABCD
ABCD
0/0 0/1 1/0
AB CD ABCD
BA DD DBAC
0/0 1/0
AB AB
AB BD
0/0 1/0
0/1
A B AB
A D BC
0/0 0/1 1/0
A B AB 1/0
A D BA 0/0 0/1
BC AD ABCD
AB DD CBDA
0/0
0/0
1/0 0/1 1/0
BC BC BD AC ABCD
BA DB AB DD ABCD
0/0 1/0
0/1 0/0 1/0
C B BC BD
D CB BD
A BA DB
0/0 1/0 0/0 1/0
0/1 0/1
C B BC D B BD
A D AB A D CB
0/0 0/1 1/0
D B BD
A D AB
Hình 10.14 Xác định trình tự UIO trên cây UIO của Hình 10.13.
BẢNG 10.7 Chuỗi tối thiểu của UIO
Độ dài thu được từ Hình 10.14
Tiểu Trình tự đầu Trình tự
bang vào đầu ra
Một 010 000
B 010 001
C 1010 0000
D 11010 00000
10.8 QUY TRÌNH ĐỊNH KỲ
Cho một FSM M = <S, I, O, s 0 , δ, λ> , một chuỗi đầu vào x được
cho là một chuỗi phân biệt nếu và chỉ khi ,
và .
Do đó, mọi trạng thái đều tạo ra một chuỗi đầu ra duy nhất để đáp
ứng với một chuỗi đầu vào phân biệt. Khái niệm phân biệt các trình
tự đã được nghiên cứu để giải quyết vấn đề nhận dạng máy trong
những ngày đầu của máy tính [6-9]. Bài toán nhận dạng máy như
sau: Đưa ra một triển khai FSM dưới dạng hộp đen và số trạng thái
của FSM, suy ra bảng trạng thái (tương đương, một máy trạng thái)
biểu thị chính xác hoạt động của hộp đen . Ngược lại, mục tiêu của
thử nghiệm kiểm tra là để quyết định xem việc triển khai hộp đen
nhất định của FSM có hoạt động theo biểu diễn bảng trạng thái nhất
định của FSM hay không.
Cho FSM M = <S, I, O, s 0 , δ, λ> với | S | = n , một khối trạng thái
được định nghĩa là một tập B gồm nhiều tập của S sao cho tổng các
con số của đa tập B bằng n . Do đó, một khối trạng thái có thể chỉ
chứa một tập đa với tất cả các trạng thái của M. Ngoài ra, một khối
trạng thái có thể chứa n nhiều tập với chính xác một phần tử trong
mỗi tập. Giả sử rằng S = {A, B, C, D} một số ví dụ về khối trạng thái
được cho trong Bảng 10.8.
Cho một khối trạng thái B = {W 1 , ..., W i , ..., W m } và một ký hiệu
đầu vào a ∈ I , chúng ta xác định một hàm B = dpert (B, a) sao cho
mỗi phần tử nhiều tập W i = (w i 1 , w i 2 , ..., w ik ) của B chúng ta thu
được một hoặc nhiều phần tử của B như sau:
Nếu hai trạng thái của W i tạo ra các đầu ra khác nhau để đáp ứng với
đầu vào a , thì các trạng thái tiếp theo của chúng được đặt trong các
tập đa khác nhau của B .
Các trạng thái tiếp theo của tất cả các trạng thái đó trong W i tạo ra
cùng một đầu ra để đáp ứng với đầu vào a được đặt trong cùng một
tập hợp B .
BẢNG 10.8 Ví dụ về khối trạng thái
Khối trạng thái 1 {(ABCD)}

Khối trạng thái 2 {(AB), (CC)}
Khối trạng thái 3 {(AB), (CD)}
393
Khối trạng thái 4 {(A), (B), (C), (D)} Khối trạng thái 5
{(A), (A), (B), (C)}
10.8 QUY TRÌNH ĐỊNH KỲ

Với một FSM giảm, khối trạng thái ban đầu chỉ bao gồm một phần tử
chứa tập hợp các trạng thái của FSM. Tiếp theo, chúng ta có thể xáo
trộn vô hạn tất cả các khối trạng thái cho tất cả các ký hiệu đầu vào
bằng cách sử dụng hàm dpert (). Người ta có thể xem hàm nhiễu loạn
B như một cạnh từ nút B đến nút mới
B với nhãn cạnh a . Cho một khối trạng thái và tập hợp các đầu vào I
, chúng ta có thể sắp xếp | I | các nút { dpert (B, a) , ∀ a ∈ I} cùng
cấp. Tất cả các khối trạng thái của một FSM nhất định có thể được
sắp xếp dưới dạng cây với các mức liên tiếp 1, 2, ... , ∞ . Cây như
vậy được gọi là cây DS. Về mặt lý thuyết, cây trình tự phân biệt (DS)
là cây có mức vô hạn. Tuy nhiên, một cây cấp hữu hạn sẽ phục vụ
mục đích của chúng ta. Cây cấp độ hữu hạn có được bằng cách cắt tỉa
cây dựa trên một số điều kiện, được gọi là điều kiện cắt tỉa, được xác
định bằng cách sử dụng các thuật ngữ sau:
D1: Khối trạng thái B là khối trạng thái thuần nhất nếu có ít nhất một
phần tử đa tập W i của B có trạng thái lặp lại.
D2: Một khối trạng thái B là một khối trạng thái đơn nếu tất cả các
phần tử của B có đúng một thành viên trạng thái.
D3: Trên đường dẫn từ khối trạng thái ban đầu đến khối trạng thái
hiện tại B tồn tại một khối trạng thái B.
Trong khi xây dựng cây DS, nếu một trong ba điều kiện sơ lược ở
trên được thỏa mãn, chúng ta khai báo khối trạng thái B là khối trạng
thái đầu cuối. Cho một cây DS của FSM M , M có một trình tự phân
biệt nếu và chỉ khi tồn tại một khối trạng thái đơn trong cây DS.
Trình tự các đầu vào từ khối trạng thái ban đầu đến khối trạng thái
đơn là DS của máy M. Sau đây, chúng tôi trình bày một thuật toán để
tính cây DS hữu hạn từ FSM.
Thuật toán. Thế hệ cây DS
Đầu vào: M = <S, I, O, s 0 , δ, λ> .
Đầu ra: cây DS.
Phương pháp: Thực hiện các bước sau:
Bước 1: Để là tập hợp các khối trạng thái trong cây DS. Ban đầu,
chứa khối trạng thái ban đầu được đánh dấu là danh nghĩa.
Bước 2: Tìm một thành viên danh nghĩa chưa bị xáo trộn. Nếu
không có thành viên nào như vậy tồn tại, thì thuật toán kết thúc.
Bước 3: Tính (ψ, a) và thêm . Đánh
dấu ψ bị xáo trộn và cập nhật cây DS.
Bước 4: Nếu dpert (ψ, a) , được tính ở bước 3 , thỏa mãn điều kiện
kết thúc D1 , D2 hoặc D3 , thì đánh dấu ψ như một nút đầu cuối.
Bước 5: Chuyển sang bước 2 .
Thí dụ. Chúng ta hãy xem xét một FSM G 2 = <S, I, O, A, δ, λ> ,
được hiển thị trong Hình 10.15, trong đó S = {A, B, C, D} là tập hợp
các trạng thái, I = { 0 , 1 } là tập hợp các đầu vào, O = { 0 , 1 } là tập
hợp các đầu ra, A là trạng thái ban đầu, δ : S × I → S
A 0/0
1/1 0/0
C B
1/0
0/1
1/1
1/0
D 0/1
Figure10.15 Finite-statemachine G 2 .
(ABCD )
0 1
(AB)(DD ) ( DC )(BA )
0 1
Hình 10.16 Cây trình tự phân biệt cho
G 2 (DD) (BA) (A) (C) (D) (B) trong Hình 10.15.
là hàm trạng thái tiếp theo và λ : S × I → O là hàm đầu ra. Cây DS
cho G 2 được thể hiện trong Hình 10.16. Khối trạng thái ban đầu chỉ
chứa một tập đa {A, B, C, D} , được biểu diễn dưới dạng nút ban đầu
( ABCD ). Chúng ta đã xáo trộn nút ban đầu ( ABCD ) với các thành
viên của tập đầu vào I = { 0 , 1 } . Sự lo lắng của khối trạng thái ban
đầu với đầu vào 0 tạo ra khối trạng thái ( AB ) ( DD ) vì những lý do
sau:
Các quốc gia A và B sản xuất cùng một đầu ra 0 với đầu vào 0 và
chuyển máy đến các trạng thái B và A tương ứng.
Các quốc gia C và D tạo ra cùng một đầu ra 1 với đầu vào 0 và
chuyển FSM đến cùng một trạng thái D.
395
Vì ( AB ) ( DD ) là một khối trạng thái đồng nhất, nó là một nút đầu
cuối trong cây DS, và do đó, nó không bị xáo trộn nữa. Sự lo lắng
của khối trạng thái ban đầu với đầu vào 1 tạo ra khối trạng thái ( DC
) ( BA ) vì những lý do sau:
thái A và D tạo ra cùng một đầu ra 0 với đầu vào 1 và chuyển máy
đến các trạng thái D và C tương ứng.
Các quốc gia B và C sản xuất cùng một đầu ra 1 với đầu vào 1 và
chuyển máy đến các trạng thái B và A tương ứng.
Chúng tôi thu được khối trạng thái đồng nhất ( DD ) ( BA ) bằng
cách xáo trộn khối trạng thái ( DC ) ( BA ) với đầu vào 0 và chúng
tôi thu được khối trạng thái singleton ( A ) ( C ) ( D ) ( B ) bằng khối
trạng thái xáo trộn ( DC ) ( BA ) với đầu vào 1. Cây DS hoàn chỉnh
được hiển thị
10.9 ĐẶC ĐIỂM GIAI ĐOẠN ĐẶC ĐIỂM
BẢNG 10.9 Đầu ra của FSM G 2 đáp ứng với trình tự đầu vào
11 ở các quốc gia khác nhau
Trạng thái Trình tự
hiện tại đầu ra
Một 00
B 11
C 10
D 01
trong Hình 10.16. Do đó, chuỗi đầu vào 11 đưa cây DS từ khối trạng
thái ban đầu của nó đến khối trạng thái singleton duy nhất của nó là
DS cho FSM G 2 . Trình tự đầu ra của FSM G 2 trong Hình 10.15 để
đáp ứng với trình tự đầu vào phân biệt 11 ở tất cả bốn trạng thái khác
nhau được trình bày trong Bảng 10.9.
Vẫn có thể xác định duy nhất trạng thái của FSM đối với các FSM
không có DS. FSM trong Hình 10.17 không có DS vì không có khối
trạng thái singleton trong cây DS, như trong Hình 10.18. Phương
pháp W được giới thiệu cho các FSM không có DS [9, 10]. Tập hợp
đặc trưng của trạng thái s i là tập hợp các trình tự đầu vào sao cho khi
mỗi trình tự được áp dụng cho việc thực hiện ở trạng thái i , thì tập
hợp các trình tự đầu ra được tạo ra bởi việc thực hiện sẽ xác định duy
nhất trạng thái i . Mỗi chuỗi của tập hợp đặc trưng của trạng thái s i
phân biệt trạng thái s i với một nhóm trạng thái. Do đó, việc áp dụng
tất cả các trình tự trong tập đặc trưng sẽ phân biệt trạng thái thứ i với
tất cả các trạng thái khác. Đối với đặc tả dựa trên FSM, một tập hợp
bao gồm các tập đặc trưng của mọi trạng thái được gọi là W -set =
{W b/y 1 , W 2 , ..., W p } của FSM. Các thành
a/y
B C viên của W -set được gọi là trình tự
a/y
đặc b/y
trưng của FSM đã cho.
b/y
Quy trình kiểm tra cơ bản để kiểm tra
b/y
sự A D chuyển đổi trạng thái ( s i , s j , a / b )
a/y
a/x bằng phương pháp W sau đây.
Trạng thái ban đầu Hình 10.17 FSM không có
trình tự phân biệt. (Từ tài liệu tham khảo. 11. © 1994
IEEE.)
(ABCD)
a b
(AA)(CB) (ABCD )
a b
(AA)(BC ) (DD)(CA)
a b
(AA)(BD) (BB)(CD)
a b a b
(AA) (C) (A) (DD) (AB) (CC) (B) (A) (AA) (CB)
a b
(AA)(A)(C ) (BB)(DA)
a b
Hình 10.18DS cây cho FSM (CC) (AA)
(AA) (BD) (Hình 10.17).
Kiểm tra chuyển tiếp (s i , s j , a / b) Sử dụng W-Method Lặp lại
các bước sau cho từng trình tự đầu vào của W -set:
Bước Giả sử rằng SUT đang ở trạng thái ban đầu, đưa SUT từ
1: trạng thái ban đầu s 0 sang trạng thái s i bằng cách áp dụng
trình tự truyền T (s i ) như trong Hình 10.11.
Bước Áp dụng đầu vào a và xác minh rằng SUT tạo ra đầu ra b .
2:
Bước Áp dụng trình tự xác minh từ W -set cho SUT và xác minh
3: rằng trình tự đầu ra tương ứng là như mong đợi. Giả sử rằng
397
SUT ở trạng thái k ở cuối bước này.
Bước Di chuyển SUT trở lại trạng thái ban đầu s 0 bằng cách áp
4: dụng trình tự đặt lại RI ở trạng thái s k .
Ví dụ: Characterizing Sequences. Xem xét đặc điểm kỹ thuật FSM
M = <S, I, O, A, δ, λ> , được hiển thị trong Hình 10.17, trong đó S =
{A, B, C, D} là tập các trạng thái, I = {a, b} là tập hợp các đầu vào,
O = {x, y} là tập hợp các đầu ra, A là trạng thái ban đầu, δ : × I → S
là hàm trạng thái tiếp theo và λ : S × I → O là hàm đầu ra . Kohavi
[9] đã sử dụng nhiều thử nghiệm để tạo W -set cho FSM này. Xét
chuỗi đầu vào W 1 = aba . Trình tự đầu ra được tạo bởi W 1 cho mỗi
trạng thái của FSM được trình bày trong Bảng 10.10. Trình tự đầu ra
được tạo bởi trình tự đầu vào W 1 có thể xác định xem trạng thái của
SUT là B hay C trước khi áp dụng W 1 . Điều này là do trạng thái B
dẫn đến trình tự đầu ra yyy , trong khi trạng thái C dẫn đến trình tự
đầu ra yyx . Tuy nhiên, W 1 không thể xác định trạng thái của SUT
nếu FSM ở A hoặc D vì trình tự đầu ra là xyx cho cả hai trạng thái,
như được thể hiện trong Bảng 10.10.
Bây giờ chúng ta hãy kiểm tra phản ứng của SUT đối với chuỗi đầu
vào W 2 = ba cho mỗi trạng thái. Các trình tự đầu ra được tạo bởi W 2
cho mỗi trạng thái của
BẢNG 10.10 Trình tự đầu ra được tạo bởi FSM của Hình 10.17
dưới dạng Phản hồi cho W 1
Các tiểu bang Đầu ra được tạo bởi W
bắt đầu 1 = aba
Một xyx
B yyy
C yyx
D xyx
BẢNG 10.11 Trình tự đầu ra được tạo bởi
FSM của Hình 10.17 như Đáp ứng với W 2
Các tiểu bang Đầu ra được tạo bởi
bắt đầu W 2 = ba
Một yx
B yx
C yy
D yy
FSM được thể hiện trong Bảng 10.11. Việc triển khai FSM tạo ra các
chuỗi đầu ra riêng biệt như là một phản hồi đối với W 2 nếu SUT ở A
hoặc D , như được thể hiện trong Bảng 10.11. Điều này là do các
trạng thái A và D dẫn đến các chuỗi đầu ra khác biệt yx và yy , tương
ứng. Do đó, W -set cho FSM bao gồm hai chuỗi đầu vào: W -set =
{W 1 , W 2 } , trong đó W 1 = aba và W 2 = ba . Trình tự chuyển giao
cho tất cả các trạng thái là T (B) = bb , T (C) = ba và T (D) = b .
Trình tự đầu vào đặt lại là RI = bababa . Trình tự đầu vào để kiểm tra
chuyển đổi trạng thái ( D , A , a / x ) được cho trong Bảng 10.12.
Trong Bảng 10.12, các cột có nhãn “thông báo tới SUT” và “thông
báo từ SUT” đại diện cho thông báo đầu vào được gửi đến SUT và
thông báo đầu ra dự kiến do SUT tạo ra, tương ứng. Trạng thái hiện
tại và trạng thái tiếp theo dự kiến của SUT được hiển thị trong các
cột có nhãn “trạng thái hiện tại” và “trạng thái tiếp theo” tương ứng.
Trong quá trình thử nghiệm, các đầu vào được áp dụng cho SUT theo
thứ tự được biểu thị bằng cột “bước”. Trong bước đầu tiên, một trình
tự chuyển giao được áp dụng để đưa SUT về trạng thái D. Trong
bước 2, quá trình chuyển đổi được thử nghiệm. Sau đó, W 1 = aba
được áp dụng để xác minh trạng thái (bước 3, 4 và 5). Tại thời điểm
này, quá trình chuyển đổi trạng thái chỉ được kiểm tra một phần, vì
W 1 không đủ để xác định trạng thái của một quá trình thực hiện.
Trình tự đặt lại RI = bababa (bước 6-11) được áp dụng theo sau là
trình tự chuyển T (D) = b (bước 12) để đưa SUT về trạng thái ban
đầu và về trạng thái D. Thử nghiệm được lặp lại cho cùng một quá
trình chuyển đổi bằng cách sử dụng W 2 = ba (bước 13–21). Nếu tất
cả các đầu ra nhận được từ SUT được xác định bởi FSM, thì quá
trình kiểm tra chuyển đổi trạng thái đã hoàn tất thành công. Nếu đầu
ra của SUT không phải là phản hồi mong đợi ở bất kỳ bước nào, thì
lỗi sẽ được phát hiện trong SUT.
BẢNG 10.12 Trình tự thử nghiệm cho chuyển đổi trạng thái (D,
A, a / x) của FSM trong Hình 10.17
Trạng
Tình trạng Nhắn tin cho Tin nhắn từ
Bươc thái tiếp
hiện tại SUT SUT
theo
399
Áp dụng T (D)
1 Một D b y
Kiểm tra chuyển tiếp
(D,A,a/x)
2 D Một một x
Áp dụng W 1
3 Một Một một x
4 Một D b y
5 D Một một x
Áp dụng RI
6 Một D b y
7 D Một một x
số 8 Một D b y
9 D Một một x
10 Một D b y
11 D Một một x
Áp dụng T (D)
12 Một D b y
Kiểm tra chuyển tiếp
(D,A,a/x)
13 D Một một x
Áp dụng W 2
14 Một D b y
15 D Một một x
Áp dụng RI
16 Một D b y
17 D Một một x
18 Một D b y
19 D Một một x
20 Một D b y
21 D Một một x

Bốn phương pháp chính — tham quan chuyển tiếp, phân biệt trình
tự, trình tự đặc trưng và trình tự đầu vào-đầu ra duy nhất — được
thảo luận để tạo các thử nghiệm từ FSM. Một câu hỏi tự nhiên xuất
hiện trong đầu là tính hiệu quả của các kỹ thuật này, tức là các loại
sai lệch được phát hiện bởi mỗi phương pháp này. Sidhu và Leung
[12] trình bày mô hình lỗi dựa trên kỹ thuật mô phỏng Monte Carlo
để ước tính phạm vi sự cố của bốn phương pháp tạo thử nghiệm ở
trên. Các tác giả đã giới thiệu 10 lớp khác nhau của đặc điểm kỹ
thuật bị lỗi ngẫu nhiên, mỗi lớp thu được bằng cách thay đổi ngẫu
nhiên một thông số kỹ thuật nhất định. Ví dụ, lỗi cấp I bao gồm việc
thay đổi ngẫu nhiên hoạt động đầu ra trong một thông số kỹ thuật
nhất định. Các tác giả kết luận rằng tất cả bốn phương pháp, ngoại
trừ phương pháp tham quan chuyển tiếp, có thể phát hiện tất cả các
lỗi đơn lẻ trái ngược với một số lỗi
10.10 KIẾN TRÚC KIỂM TRA
được giới thiệu trong một đặc điểm kỹ thuật nhất định. Ngoài ra, nó
cũng cho thấy rằng các trình tự phân biệt, đặc trưng và UIO có cùng
khả năng phát hiện lỗi. Một nghiên cứu khác, tương tự như nghiên
cứu của Sidhu và Leung, được báo cáo bởi Dahbura và Sabnani về
phương pháp trình tự UIO [13].
Tổng quan về bốn kiến trúc thử nghiệm trừu tượng do ISO phát triển
được trình bày trong phần này. Các tài liệu ISO [14–16] và Linn [17]
và Rayner [18] cung cấp thêm chi tiết về các kiến trúc thử nghiệm.
Kiến trúc kiểm tra ISO dựa trên kiến trúc tham chiếu Hệ thống mở
(OSI), bao gồm cấu trúc lớp phân cấp của các thực thể. Mục đích của
một thực thể ở lớp N là cung cấp một số dịch vụ nhất định, được gọi
là N -services, cho thực thể lớp trên của nó. Nó sử dụng dịch vụ được
cung cấp bởi lớp N- 1 trong khi cô lập các chi tiết triển khai của các
thực thể lớp dưới với các lớp trên. Các thực thể N ngang hàng giao
tiếp với nhau thông qua N - 1 nhà cung cấp dịch vụ bằng cách trao
đổi N -protocol đơn vị dữ liệu [(N) -PDUs], như trong Hình 10.19.
Tương tác của N -entity với các thực thể trên và dưới của nó được
xác định bởi N và N - 1 nguyên thủy dịch vụ trừu tượng (ASP).
401
Các kiến trúc thử nghiệm trừu tượng được mô tả dưới dạng các đầu
vào cho IUT có thể được cung cấp theo cách có kiểm soát và các đầu
ra tương ứng từ IUT được quan sát. Cụ thể, một kiến trúc kiểm tra
trừu tượng được mô tả bằng cách xác định các điểm gần IUT nhất
nơi các điều khiển và quan sát được xác định. Kiến trúc thử nghiệm
trừu tượng được phân loại thành hai loại chính: cục bộ và bên ngoài.
Các kiến trúc thử nghiệm cục bộ được đặc trưng bởi sự quan sát và
điều khiển được xác định theo các sự kiện xảy ra trong SUT tại các
ranh giới lớp ngay bên dưới và phía trên IUT, như thể hiện trong
Hình 10.20. Mặt khác
N + 1 Entity N + 1 Entity
N ASPs N ASPs
N Entity N PDUs N Entity
N − 1 ASPs N −1 ASPs
N − 1 Service provider
N Service provider
Hình 10.19 Tóm tắt thực thể N trong kiến trúc tham chiếu OSI.
Events
Implementation
under test
Sự kiện Hình 10.20 Kiến trúc kiểm thử cục bộ trừu

tượng.
Events
Events Implementation
under test
Service provider Figure10.21 Abstractexternaltestarchi-

tecture.
mặt khác, các kiến trúc thử nghiệm bên ngoài được đặc trưng bởi
việc quan sát và kiểm soát các sự kiện diễn ra bên ngoài từ SUT, ở
phía bên kia của nhà cung cấp dịch vụ cơ bản từ IUT, như thể hiện
trong Hình 10.21. Hệ thống mà IUT cư trú là một SUT. Các kiến trúc
bên ngoài giả định rằng một dịch vụ truyền thông cơ bản được sử
dụng trong thử nghiệm. Các kiến trúc thử nghiệm cục bộ chỉ có thể
áp dụng cho thử nghiệm nội bộ của các nhà cung cấp. Trong khi đó,
các kiến trúc thử nghiệm bên ngoài được áp dụng cho cả thử nghiệm
nội bộ của nhà cung cấp và người mua / trung tâm thử nghiệm bên
thứ ba. Có ba loại kiến trúc thử nghiệm bên ngoài, được thảo luận
cùng với kiến trúc thử nghiệm cục bộ, trong phần sau.
10.10.1 Kiến trúc cục bộ
Một giả định cơ bản trong kiến trúc cục bộ là tồn tại các giao diện
tiếp xúc bên trên và bên dưới IUT. Các giao diện này đóng vai trò là
PCO, tức là các điểm mà tại đó hệ thống thử nghiệm thực có thể cung
cấp đầu vào và quan sát đầu ra từ IUT. Kiến trúc kiểm tra bao gồm
hai phần tử khác biệt về mặt logic, được gọi là trình kiểm tra trên và
trình kiểm tra dưới, như thể hiện trong Hình 10.22. Các sự kiện kiểm
tra được chỉ định theo N ASP bên trên IUT, và N - 1 ASP và N PDU
bên dưới IUT. Sự phối hợp giữa người kiểm tra cấp trên và cấp dưới
được cung cấp bởi các quy trình phối hợp kiểm tra trong quá trình
kiểm tra.
Tóm lại, kiến trúc kiểm tra cục bộ bao gồm một bộ khai thác kiểm tra
xung quanh IUT, điều phối các hành động của người kiểm tra cấp
dưới và cấp trên. Vai trò của người kiểm tra cấp trên và cấp dưới là
kích thích IUT bằng cách trao đổi các sự kiện kiểm tra tại
403
Upper
tester
N ASPs
PCO
Test Implementation
coordination
under test
procedures
PCO
N PDUs
N − 1-ASPs
Lower
tester
Hình 10.22 Kiến trúc địa
phương.
giao diện trên và dưới của IUT. Kiến trúc cục bộ ngầm cung cấp khả
năng đồng bộ hóa và điều khiển người kiểm tra cấp trên và cấp dưới
vì cả hai đều là các phần tử của cùng một bộ khai thác kiểm tra.
10.10.2 Kiến trúc phân tán
Kiến trúc phân tán được minh họa trong Hình 10.23. Kiến trúc này là
một trong ba kiến trúc bên ngoài và không có giả định nào về sự tồn
tại của PCO bên dưới IUT. Kiến trúc kiểm tra này xác định các PCO
ở ranh giới dịch vụ phía trên IUT và ở phía đối diện của nhà cung
cấp dịch vụ N- 1 từ IUT.
Lưu ý rằng bộ kiểm tra thấp hơn và IUT nằm trong hai hệ thống khác
nhau. Bộ kiểm tra thấp hơn và IUT được kết nối bởi một dịch vụ cơ
bản cung cấp dịch vụ N- 1 sử dụng giao thức lớp thấp hơn và phương
tiện vật lý kết nối hai hệ thống. Người kiểm tra thấp hơn rõ ràng là
một thực thể ngang hàng của IUT trong Hình 10.23. Các mũi tên
giữa IUT và nhà cung cấp dịch vụ N- 1 không phải là giao diện thực,
chỉ
Test
coordination Upper
procedures tester
N ASPs
Lower
tester PCO
Implementation
N PDUs under test
PCO
N − 1 ASPs
Hình 10.23 Kiến trúc phân tán.
luồng khái niệm của N PDU. Các sự kiện kiểm tra được chỉ định theo
N ASP bên trên IUT và N - 1 ASP và N PDU từ xa, như thể hiện
trong Hình 10.23. Ba điểm quan trọng cần được ghi nhớ với kiến trúc
này: • Người thử nghiệm thấp hơn và IUT được tách biệt về mặt vật
lý với ngụ ý rằng chúng có thể quan sát cùng một sự kiện thử nghiệm
tại các thời điểm khác nhau.
• Có thể phân phối không theo trình tự, hỏng dữ liệu và mất dữ liệu
do chất lượng không đáng tin cậy của nhà cung cấp dịch vụ thấp hơn.
• Đồng bộ hóa và kiểm soát (thủ tục phối hợp kiểm tra) giữa người
kiểm tra cấp trên và cấp dưới khó khăn hơn do tính chất phân tán của
hệ thống kiểm tra.
Tóm lại, kiến trúc kiểm tra phân tán là một cấu trúc tương đương
logic của kiến trúc cục bộ với trình kiểm tra thấp hơn và IUT được
kết nối với nhau bởi một dịch vụ truyền thông. Tuy nhiên, cấu trúc
của kiến trúc cục bộ ngầm cung cấp khả năng đồng bộ hóa và điều
khiển người kiểm tra cấp trên và cấp dưới vì chúng là các phần tử
của cùng một bộ khai thác kiểm tra. Do đó, kiến trúc phân tán không
phải là một chức năng tương đương với kiến trúc cục bộ.
10.10.3 Kiến trúc phối hợp
Kiến trúc phối hợp là một sự nâng cao của kiến trúc phân tán. Việc
kiểm soát và quan sát N ASP được thực hiện bởi Giao thức quản lý
thử nghiệm (TMP). Chỉ có một PCO ở phía đối diện của nhà cung
cấp dịch vụ N- 1 từ IUT, như trong Hình 10.24. Lưu ý rằng, mặc dù
PCO xuất hiện giữa người kiểm tra phía trên và IUT, nó là tùy chọn;
như một sự lựa chọn của người triển khai, người kiểm tra trên có lẽ
được tích hợp như một phần của IUT. Hai đặc điểm phân biệt kiến
trúc phối hợp như sau:
405
Không có giao diện nào được tiếp xúc với bộ kiểm tra phía trên của
IUT (mặc dù điều này không bị loại trừ).
Đơn vị dữ liệu TMP và TMP tiêu chuẩn (TMPDU) được sử dụng để
giao tiếp giữa người kiểm tra cấp trên và người kiểm tra cấp dưới.
TMPDUs Upper
tester
Lower
tester PCO
Implementation
N PDUs under test
PCO
N − 1 ASPs
Hình 10.24 Kiến trúc phối hợp.
Test
coordlnation Upper
procedures tester
Lower
tester
Implementation
N PDUs under test
PCO
N − 1 ASPs
Hình 10.25 Kiến trúc Remote.
Người kiểm tra dưới được coi là bậc thầy của người kiểm tra trên.
Các hành động của người kiểm tra cấp trên được kiểm soát bởi người
kiểm tra cấp dưới thông qua TMP. Các sự kiện kiểm tra được chỉ
định theo N- 1 ASP, N PDU và TMPDU, như minh họa trong Hình
10.24.
10.10.4 Kiến trúc từ xa
Kiến trúc từ xa có thể áp dụng cho các IUT không có giao diện phía
trên lộ ra. Trong trường hợp không có người kiểm tra cấp trên, kiến
trúc kiểm tra xác định PCO từ IUT, ở phía đối diện của nhà cung cấp
dịch vụ N- 1. Các sự kiện thử nghiệm được xác định theo N- 1 ASP
và N PDU, như được chỉ ra trong Hình 10.25. Có hai đặc điểm chính
của kiến trúc này:
Không có giao diện nào ở đầu IUT được giả định.
Không có quy trình phối hợp kiểm tra rõ ràng nào được sử dụng.
Việc phối hợp giữa người kiểm tra cấp trên và cấp dưới là thủ công
(ví dụ: nói chuyện qua điện thoại). Sự phối hợp tiềm ẩn trong các
PDU do người thử nghiệm cấp dưới khởi xướng hoặc được cung cấp
bởi các hành động được thực hiện bởi thực thể lớp trên để kích thích
IUT.
Kiến trúc dựa trên giao thức đang được kiểm tra để đồng bộ hóa giữa
trình kiểm tra thấp hơn và IUT. Phán quyết phải được xây dựng dựa
trên kích thích do người thử nghiệm cấp dưới cung cấp và các phản
ứng của IUT do người thử nghiệm cấp dưới quan sát.
10.11 KIỂM TRA VÀ THUYẾT MINH KIỂM TRA THỬ
NGHIỆM PHIÊN BẢN 3 (TTCN-3)
10.11 KIỂM TRA VÀ THUYẾT MINH KIỂM TRA THỬ NGHIỆM PHIÊN BẢN 3 (TTCN-3) 407
Như tên cho thấy, TTCN-3 là một ngôn ngữ để chỉ định các trường
hợp kiểm thử [19]. Ngôn ngữ này ngày càng được chấp nhận trong
ngành như một ngôn ngữ đặc tả thử nghiệm sau khi nó được chuẩn
hóa bởi ETSI (Viện Tiêu chuẩn Viễn thông Châu Âu). Ngôn ngữ này
đã được thiết kế bằng cách lưu ý đến nhu cầu thử nghiệm các hệ
thống viễn thông phức tạp. Do đó, ngôn ngữ này đang được sử dụng
để viết các trường hợp thử nghiệm nhằm kiểm tra các giao thức
truyền thông phức tạp, chẳng hạn như Giao thức Khởi tạo Phiên
(SIP) và Giao thức Internet phiên bản 6 (IPv6).
Trong những nỗ lực ban đầu để phát triển ngôn ngữ đặc tả thử
nghiệm, từ viết tắt TTCN-1 là viết tắt của Tree and Tabular
Combation Notation phiên bản 1. TCCN được phát triển vào giữa
những năm 1980 và nó đã phát triển từ TTCN-1 thành TTCN-2 (Cây
và Bảng Kí hiệu kết hợp phiên bản 2) trong khi vẫn giữ nguyên cú
pháp và ngữ nghĩa cốt lõi của nó ở một mức độ lớn. Mặc dù đã có
nhiều nỗ lực trong quá trình phát triển TCCN, nhưng nó không được
chấp nhận rộng rãi như một ngôn ngữ đặc tả kiểm tra trong ngành.
Lý do cho sự vắng mặt của mối quan tâm rộng rãi đến ký hiệu phần
lớn là do khoảng cách lớn giữa cú pháp và ngữ nghĩa thực thi.
Vào năm 2001, TTCN-2 đã có một bước cải tiến lớn và TTCN-3 đã
xuất hiện trong ngày. Mặc dù TTCN-3 vẫn giữ các đặc điểm cơ bản
của TTCN-2, nhưng cú pháp của TTCN-3 được thiết kế phù hợp với
ngôn ngữ lập trình thủ tục. Các lập trình viên và nhà thiết kế kiểm
thử có thể viết các trường hợp kiểm thử theo cách họ viết chương
trình, do đó giảm khoảng cách giữa cú pháp và ngữ nghĩa thực thi.
Giao diện ngôn ngữ lập trình của TTCN-3 khiến nó dễ chấp nhận
hơn. TTCN-3 đã có nhiều cải tiến kể từ năm 2001 và cơ sở người
dùng và hỗ trợ ngày càng mở rộng. Ngày càng có nhiều công cụ hỗ
trợ và một nhóm tích cực duy trì ngôn ngữ.
Trong phần này, chúng tôi giới thiệu sơ lược về TTCN-3. Chúng tôi
tập trung vào các tính năng cốt lõi của TTCN-3, chẳng hạn như mô-
đun, kiểu dữ liệu, mẫu, cổng, thành phần và trường hợp thử nghiệm.
10.11.1 Mô-đun
Mô-đun là một đơn vị cơ bản để chỉ định các trường hợp kiểm thử.
Về mặt lập trình, một ca kiểm thử bao gồm một số khai báo dữ liệu
và một số hành vi thực thi, được chỉ định dưới dạng một hoặc nhiều
mô-đun. Hành vi thực thi của một trường hợp kiểm thử được gọi là
phần điều khiển. Cấu trúc của một mô-đun được thể hiện trong Hình
10.26.
10.11.2 Khai báo dữ liệu
TTCN-3 cho phép khai báo hằng và biến. Một hằng được biểu thị
bằng từ khoá const và giá trị của hằng được gán tại điểm khai báo.
Giá trị của một hằng số không thể thay đổi sau đó.
TTCN-3 có các quy tắc xác định phạm vi riêng cho tất cả các định
nghĩa dữ liệu. Tất cả các khai báo được thực hiện ở cấp độ “cao
nhất”, tức là cấp độ mô-đun, đều có thể truy cập được trong toàn bộ
mô-đun. Ở đây, cấp cao nhất có nghĩa là trước phần điều khiển. Khái
niệm "khối mã", được bao bọc bởi một cặp dấu ngoặc nhọn phù hợp,
giúp chúng ta hiểu các quy tắc xác định phạm vi. Các định nghĩa
được thực hiện trong một khối mã cụ thể chỉ có thể truy cập được
trong khối mã đó và số nhận dạng không được sử dụng lại trong các
khối mã lồng nhau. Nói cách khác, không tồn tại hai mục dữ liệu có
cùng tên nhưng phạm vi khác nhau. Không có biến nào có thể được
định nghĩa ở cấp mô-đun, và do đó, tất cả các khai báo ở cấp mô-đun
đều là hằng số. Sự vắng mặt của các biến cấp mô-đun có nghĩa là
không có các biến toàn cục.
/ * Người ta có thể ghi lại một mô-đun bằng cách viết nhận xét
theo cách này. * / // Các ý kiến bổ sung có thể được bao gồm ở
đây.
mô-đun ExampleTestModule1 {// Một mô-đun có thể để trống.
// Đầu tiên, xác định một số dữ liệu sẽ được sử dụng trong phần
điều khiển const integer MaxCount: = 15; số nguyên không đổi
UnitPacket = 256; // Có thể xác định thêm dữ liệu tại đây ...
// Thứ hai, chỉ định phần điều khiển để thực thi điều khiển {//
Phần điều khiển là tùy chọn var integer counter: = 0; var số
nguyên loopcount: = MaxCount; const integer PacketSize: =
UnitPacket * 4;
// Chỉ định thêm hành vi thực thi tại đây ...
} // Kết thúc phần điều khiển
} // cuối mô-đun TestCase1
Hình 10.26 Cấu trúc của mô-đun trong TTCN-3.
Vì một trường hợp thử nghiệm có thể có các thành phần phân tán,
nên rất khó để đảm bảo ngữ nghĩa của biến toàn cục trên các thành
phần thử nghiệm phân tán.
TTCN-3 hỗ trợ một tập hợp các kiểu tích hợp mạnh mẽ, chẳng hạn
như số nguyên, float, Boolean (phổ quát), chuỗi ký tự, kiểu xác định,
chuỗi bit, chuỗi lục phân, chuỗi bát phân, objid và mặc định. Một tập
hợp các kiểu tích hợp phong phú như vậy là điều cần thiết để kiểm
tra giao thức. TTCN-3 cũng cho phép định nghĩa các kiểu có cấu trúc
và kiểu danh sách từ các kiểu hiện có. Các cấu trúc để xác định các
kiểu có cấu trúc là liệt kê, ghi, đặt và liên hợp. Tương tự, các cấu trúc
để xác định kiểu danh sách là mảng, tập hợp và bản ghi.
TTCN-3 cho phép người lập trình sử dụng khái niệm kiểu con dữ
liệu. Định kiểu con có nghĩa là giới hạn các giá trị của một kiểu trong
một tập hợp con của tất cả các giá trị mà kiểu gốc cho phép. Ví dụ,
với tập hợp tất cả các số nguyên, người ta có thể tạo một kiểu con
của tất cả các số không dấu có thể được biểu diễn bằng 16 bit. Kiểu
con như vậy rất hữu ích trong việc biểu diễn số cổng trong khi thử
nghiệm bằng TCP. Hai ví dụ về kiểu con được thể hiện trong Hình
10.27, trong đó TCPPort là kiểu mới do người dùng xác định. Một
biến kiểu TCPPort có thể nhận các giá trị trong phạm vi 0, ... , 65535.
Tương tự, IPUserProtocol là một kiểu con của chuỗi ký tự. Một biến
kiểu IPUserProtocol có thể nhận các giá trị từ tập hợp đã cho và
không nằm ngoài tập hợp đó.
Một PDU trong một giao thức truyền thông có thể được xác định
bằng cách sử dụng một loại bản ghi. Trong một số giao thức, PDU
của chúng được gọi đơn giản là thông điệp. TTCN-3 cho phép một
gõ số nguyên TCPPort (0 .. 65535); // chuỗi ký tự kiểu số không
dấu 16 bit IPUserProtocol ('' TCP '', '' UDP '', '' OSPF '',
''XÉ TOẠC'' );
Hình 10.27 Định nghĩa của hai kiểu con.
xác định một trường PDU có độ dài bit tùy ý. Ví dụ, người ta có thể
xác định các trường PDU gồm 1 bit, 4 bit và 6 bit được tìm thấy
trong tiêu đề gói tin của IPv4 (Giao thức Internet phiên bản 4).
Thông thường, các giao thức đặt giới hạn về độ dài của một số
trường PDU. Các giới hạn như vậy được thể hiện dễ dàng bằng cách
sử dụng thuộc tính độ dài của các biến.
Người ta tạo ra các thể hiện của các kiểu đó bằng cách sử dụng các
giá trị cụ thể sau khi xác định một PDU hoặc một kiểu thông báo.
Các trường hợp cụ thể như vậy có hai ứng dụng: (i) gửi thông điệp
đến một thực thể giao thức từ xa và (ii) nhận thông báo có các giá trị
mong muốn. Các thể hiện cụ thể của các loại thông báo được gọi là
mẫu trong TTCN-3. TTCN-3 cho phép tham số hóa các mẫu để dễ
dàng tạo thông báo. Ví dụ về một mẫu được thể hiện trong Hình
10.28, trong đó MyMessage là một kiểu thông báo và SFCRequest là
một thể hiện của MyMessage. Loại MyMessage bao gồm bốn trường.
Trường phản hồi có thể được bỏ qua trong khi tạo một phiên bản của
mẫu.
Định nghĩa ví dụ về thông báo phản hồi kiểu MyMessage được hiển
thị trong Hình 10.29. Người ta có thể chỉ định thông điệp nào được
mong đợi nhận được từ một SUT bằng cách xác định thông báo phản
hồi. Trường nhận dạng có thể được sử dụng để liên kết thông báo
phản hồi với thông báo yêu cầu. MỘT "?" giá trị của trường đầu vào
trong SFCResponse cho chúng ta biết rằng trường có thể chứa bất kỳ
giá trị nào, giá trị này sẽ bị bỏ qua. Trường phản hồi trong
SFCResponse nhận được mang giá trị thực tế dự kiến nhận được từ
SUT.
10.11.3 Cổng và thành phần
Cơ sở hạ tầng thử nghiệm có thể bao gồm một hoặc nhiều thành phần
thử nghiệm, trong đó thành phần thử nghiệm là một thực thể có thể
gửi và / hoặc nhận thông báo (mẫu). Có
mẫu MyMessage SFCRequest (Id nhận dạng, Giá trị đầu vào): =
{Identity: = id,
msgtype: = Yêu cầu, đầu vào: = Ival,
response : = omit // '' bỏ qua '' là một từ khóa
}
Hình 10.28 Mẫu tham số hóa để xây dựng thông báo được gửi đi.
mẫu MyMessage
SFCResponse (Id nhận dạng, Phản hồi Rval): = {Identity: = id,
msgtype : = Response, input: =?, // Điều này có nghĩa là
trường có thể chứa bất kỳ
giá trị
phản hồi : = Rval
}
Hình 10.29 Mẫu được tham số hóa để xây dựng thông báo sẽ nhận
được.
SFC tester SFC
Request
Response
Time
(một)
Cổng máy
chủ SFC
Trình kiểm tra SFC
SFC
(b)
Hình 10.30 Máy tính kiểm tra (a) hàm căn bậc hai (SRF) và ( b )
cổng giữa máy kiểm tra và máy tính SRF.
nhu cầu giao tiếp giữa các thành phần thử nghiệm và giữa SUT và
các thành phần thử nghiệm. Các điểm diễn ra giao tiếp được gọi là
các cổng trong TTCN-3. Một cổng được mô hình hóa như một hàng
đợi FIFO (vào ra trước) vô hạn từ quan điểm của người nhận. Hai
loại ngữ nghĩa giao tiếp được liên kết với một cổng: ngữ nghĩa thông
báo và ngữ nghĩa cuộc gọi thủ tục. Người ta có thể chỉ định các loại
thông báo hoặc cuộc gọi mà một cổng xử lý và hướng đầu vào - đầu
ra của cổng. Một cổng có thể là cổng vào (đầu vào), cổng ra (đầu ra)
hoặc cổng vào ra (cả đầu vào và đầu ra). Chúng tôi giải thích thử
nghiệm của một máy tính hàm căn bậc hai (SFC) theo thành phần thử
nghiệm và thành phần SFC, như thể hiện trong Hình 10.30 a . Một
cổng giữa hai thành phần được thể hiện trong Hình 10.30 b . Khai
báo kiểu cổng vào ra xử lý các thông báo kiểu MyMessage được thể
hiện trong Hình 10.31. Hình 10.32 minh họa phần đính kèm của
thành phần thử nghiệm SFCTester với SFCServerPort. Thành phần
SFC được giả định đang chạy trên một cổng được gọi là
SFCServerPort.
10.11.4 Phán quyết trường hợp thử nghiệm
Một nhà thiết kế thử nghiệm muốn kết luận điều gì đó sau khi thực
hiện một trường hợp thử nghiệm. Ví dụ, hai kết luận đơn giản là liệu
SUT đã đạt hay không đạt trong bài kiểm tra. Nếu một SUT hoạt
động như mong đợi, thì điều tự nhiên là nó đã vượt qua bài kiểm tra;
nếu không thì thử nghiệm đã thất bại. Vì vậy, đạt và không đạt là hai
bài kiểm tra hiển nhiên
loại cổng thông báo SFCPort {// Loại SFCPort có '' thông báo ''
// ngữ nghĩa
inout MyMessage // Kiểu SFCPort thuộc kiểu inout
// sự điều khiển
// tin nhắn kiểu MyMessage}
Hình 10.31 Xác định loại cổng.
nhập thành phần SFCTester { port SFCPort SFCServerPort
}
Hình 10.32 Liên kết cổng với thành phần.
các bản án. Tuy nhiên, thường thì nhà thiết kế thử nghiệm có thể
không có đủ khả năng để kết luận rằng hệ thống đã đạt hay không đạt
một thử nghiệm. Trong trường hợp như vậy, nhà thiết kế thử nghiệm
chỉ định một kết quả thử nghiệm không kết luận được, có nghĩa là
các thử nghiệm tiếp theo cần được thực hiện để tinh chỉnh kết quả
không thể kết luận thành kết quả đạt hoặc không đạt.
TTCN-3 cung cấp một cơ chế để ghi lại các phán quyết thử nghiệm.
Được liên kết với mỗi thành phần thử nghiệm, có một biến được xác
định ngầm của loại kết quả. Giá trị ban đầu, mặc định của biến kết
quả kiểm tra được xác định ngầm là không có. Người thiết kế thử
nghiệm có thể gán các giá trị mới cho biến kết quả thử nghiệm bằng
cách gọi lệnh thiết lập hoạt động. Ví dụ, các lệnh gọi setverdict
(Pass), setverdict (Fail) và setverdict (Inconc) lần lượt gán các phán
quyết đạt, fail và không kết luận. Có một kết quả kiểm tra thứ tư, cụ
thể là lỗi, được ấn định bởi hệ thống thời gian chạy. Thời gian chạy
gán lỗi kết quả kiểm tra cho biến kết quả kiểm tra khi lỗi thời gian
chạy xảy ra. Ví dụ: chia một giá trị số cho 0 dẫn đến lỗi thời gian
chạy. TTCN-3 không cho phép trình thiết kế thử nghiệm đặt giá trị
của biến kết quả thành lỗi một cách rõ ràng, nghĩa là, lệnh thiết lập
hoạt động (lỗi) không được phép trong TTCN-3. Giá trị của phán
quyết được chỉ định cho đến nay trong một thành phần thử nghiệm
có thể được truy xuất bằng lệnh getverdict hoạt động.
10.11.5 Trường hợp thử nghiệm
Một trường hợp thử nghiệm đơn giản chạy trên thành phần
SFCTester được thể hiện trong Hình 10.33. Chúng tôi giả sử một
thông báo chuyển ngữ nghĩa giao tiếp giữa SFCTester thành phần thử
nghiệm và SUT, cụ thể là SFC. SFCTester gửi một bản tin yêu cầu
đến SFC và đợi một bản tin phản hồi từ SFC. Vì SFC bị lỗi có thể
không tạo ra thông báo phản hồi, SFCTester phải thoát khỏi trạng
thái chờ vô hạn có thể xảy ra. Do đó, chúng tôi xác định một bộ đếm
thời gian, cụ thể là, responseTimer, bằng cách sử dụng bộ đếm thời
gian từ khóa. Tiếp theo, trường hợp kiểm tra sẽ gửi một tin nhắn, cụ
thể là SFCMessage và bắt đầu hẹn giờ với
testcase hành vi thay thế SFCtestcase1 () chạy trên SFCTester {

timer responseTimer; // Định nghĩa bộ định thời SFCPort. gửi
(SFCRequest (7, 625)); responseTimer. bắt đầu (5.0);
alt {// Bây giờ xử lý ba trường hợp thay thế ... // Trường hợp 1:
Kết quả tính toán mong đợi // được nhận.
[] SFCPort. nhận (SFCResponse (7, 25)) { setverdict ( vượt qua
); responseTimer. dừng lại ;
}
// Trường hợp 2: Nhận được kết quả tính toán không mong
muốn //.
[] SFCPort. nhận được { setverdict ( fail ); responseTimer. dừng
lại ;
}
// Trường hợp 3: Không nhận được kết quả trong thời gian // hợp
lý.
[] responseTimer. timeout { setverdict ( fail );
}} dừng lại ;
} // Kết thúc trường hợp kiểm tra
Hình 10.33 Trường hợp thử nghiệm để kiểm tra máy tính SRF.
khoảng thời gian 5,0 s. SFCMessage chứa hai trường quan trọng, đó
là số nhận dạng và đầu vào. Chúng tôi quan tâm đến việc tính toán
căn bậc hai của đầu vào, giá trị này đã được cho giá trị là 625. Trong
ví dụ đã cho, số nhận dạng nhận một giá trị tùy ý, nhưng đã biết, là 7.
Sau khi gửi yêu cầu đến thành phần SFC và khởi động bộ đếm thời
gian, thành phần kiểm tra sẽ đợi thông báo dự kiến đến từ thành phần
SFC. Tại thời điểm này, ba tình huống khác nhau có thể phát sinh.
Đầu tiên, thành phần SFC có thể phản hồi chính xác với kết quả
mong đợi là 25 trong một thông báo có giá trị định danh là 7. Thứ
hai, thành phần SFC phản hồi với một giá trị không chính xác; ví dụ,
trường định danh có thể có giá trị không chính xác hoặc trường phản
hồi có thể có giá trị không bằng 25. Thứ ba, thành phần SFC có thể
không tạo ra phản hồi.
Trong trường hợp đầu tiên, SFCTester ghi lại kết quả kiểm tra đạt.
Trong trường hợp thứ hai, thành phần kiểm tra ghi lại kết quả kiểm
tra không đạt. Trong trường hợp thứ ba, thành phần kiểm tra xuất
hiện trong thời gian chờ đợi vô hạn và ghi lại kết quả kiểm tra không
thành công. Nếu một trong hai lựa chọn thay thế đầu tiên xảy ra,
thành phần thử nghiệm sẽ dừng bộ đếm thời gian một cách tự nhiên,
trong khi ở phương án thứ ba, thành phần thử nghiệm nhận được thời
gian chờ. Các hành vi thay thế đã được
mô-đun ExampleTestModule2 {
// Xác định các biến và hằng số được sử dụng ...
// Xác định các mẫu sẽ được sử dụng ...
// Xác định các cổng được sử dụng ...
// Liên kết các thành phần kiểm tra với các cổng ...
// Xác định các trường hợp thử nghiệm, chẳng hạn
như SFCtestcase1 ...
điều khiển { thực thi (SFCtestcase1 ()); }
}
Hình 10.34 Đang thực thi test case.
được thể hiện bằng cách sử dụng cấu trúc alt và các hành vi thay thế
riêng lẻ đã được thể hiện rõ ràng bằng cách sử dụng biểu tượng [].
Cuối cùng, trường hợp thử nghiệm SFCtestcase1 có thể được thực thi
bằng cách có một câu lệnh thực thi trong phần điều khiển của mô-
đun thử nghiệm, như thể hiện trong Hình 10.34.
10.12 FSMS ĐÃ GIA HẠN
Hai thành phần khái niệm của hệ thống phần mềm là luồng điều
khiển và thao tác dữ liệu. Mô hình FSM hữu ích trong việc mô tả mô
hình trước nhưng không có quy định để chỉ định mô hình sau. Mặc
dù có nhiều hệ thống có thể được mô hình hóa thuận tiện và chính
xác như FSM, nhiều hệ thống trong thế giới thực yêu cầu chúng ta
chỉ định các phép tính liên quan trong khi một hệ thống thực hiện
chuyển đổi từ trạng thái này sang trạng thái khác. Các phép tính liên
quan có thể có các dạng sau:
Thao tác với các biến cục bộ.
Bắt đầu và dừng hẹn giờ.
Tạo các phiên bản của quy trình.
So sánh các giá trị và đưa ra các quyết định về luồng điều khiển.
Truy cập cơ sở dữ liệu.
Trong phần này, chúng ta sẽ thường đề cập đến mô hình FSM của
một PBX điện thoại được thể hiện trong Hình 10.8. Cần phải ghi lại
thời gian bắt đầu của một cuộc gọi và điều này có thể được thực hiện
bằng cách ghi lại thời gian khi FSM chuyển sang trạng thái đàm
thoại. Cấu trúc để khởi động và dừng bộ định thời là điều cần thiết
đối với đặc điểm kỹ thuật của hệ thống thời gian thực. Thao tác với
các biến cục bộ và các bước nhảy có điều kiện là trọng tâm của việc
thực hiện lặp đi lặp lại một chuỗi chuyển trạng thái trong một số lần
nhất định. Truy cập cơ sở dữ liệu là điều cần thiết để ghi lại các giá
trị của các biến cục bộ cho các mục đích kinh doanh, chẳng hạn như
thanh toán và bảo trì.
Do đó, cần phải tăng cường cấu trúc cơ bản của quá trình chuyển đổi
trạng thái với khả năng thực hiện các tính toán bổ sung, chẳng hạn
như cập nhật giá trị của các biến, thao tác bộ định thời và đưa ra
quyết định. Như một phần mở rộng của FSM

dẫn đến một máy trạng thái hữu hạn mở rộng (EFSM). Các quy trình
trong Ngôn ngữ đặc tả và mô tả (SDL) [20, 21] là EFSM. Các quy
trình SDL được xây dựng dựa trên các khái niệm cơ bản sau:
Hệ thống, được mô tả theo thứ bậc bởi các phần tử được gọi là hệ
thống, khối, kênh, quy trình, dịch vụ, tín hiệu và tuyến tín hiệu
Hành vi, được mô tả bằng cách sử dụng phần mở rộng của khái niệm
FSM
Dữ liệu, được mô tả bằng cách sử dụng khái niệm kiểu dữ liệu trừu
tượng với việc bổ sung khái niệm về biến chương trình và cấu trúc
dữ liệu
Giao tiếp không đồng bộ qua các kênh là hàng đợi vô hạn
Đặc tả SDL có thể được viết dưới hai dạng khác nhau: SDL / GR và
SDL / PR. SDL / GR là một cú pháp đồ họa hiển thị hầu hết các cấu
trúc ngôn ngữ ở dạng đồ họa giống như biểu đồ luồng. Định nghĩa dữ
liệu chỉ có thể được biểu diễn bằng văn bản. Mặt khác, SDL / PR
được viết dưới dạng văn bản để máy xử lý. “PR” trong SDL / PR là
viết tắt của quá trình xử lý. Ánh xạ một-một được xác định giữa hai
dạng. Chúng tôi chỉ ra cấu trúc của sự chuyển đổi trạng thái trong
FSM trong Hình 10.35a. Sự chuyển đổi trạng thái này chỉ định rằng
nếu FSM - cái hoàn chỉnh chưa được hiển thị ở đây - nhận đầu vào a
ở trạng thái A, máy tạo ra đầu ra b và chuyển sang trạng thái B. Biểu
diễn SDL / GR của cùng một quá trình chuyển đổi được thể hiện
trong Hình 10,35b. Ví dụ này cho thấy rằng người ta có thể dễ dàng
biểu diễn FSM như một quy trình SDL. Sự chuyển đổi trạng thái của
Hình 10.35b đã được mở rộng trong Hình 10.35c bằng cách bao gồm
một khối tác vụ khởi động bộ định thời. Chúng tôi hiển thị hai
chuyển đổi trạng thái — một từ trạng thái A sang trạng thái B và một
chuyển đổi từ
417
A A A A
a a a
True False
Start timer (T ) P
a/b
Get Update value
b b resource of variables
b b
Start timer (T ) c
B B B B C
(a) (b) (c) (d)

Hình 10.35 So sánh chuyển đổi trạng thái của FSM và EFSM.
trạng thái A đến trạng thái C — bao gồm các khối nhiệm vụ và một
hộp quyết định (Hình 10.35d). Để tóm tắt cuộc thảo luận về EFSM,
EFSM tương tự như FSM với các tính toán liên quan đến mọi chuyển
đổi trạng thái. Sau đây, chúng tôi đưa ra mô hình EFSM của một hệ
thống trong đời thực.
Ví dụ: Hệ thống Kiểm soát Cửa. Chúng ta hãy xem xét một hệ
thống kiểm soát cửa, như được minh họa trong Hình 10.36. Cửa được
trang bị bộ phận cơ điện để nó có thể đóng mở bằng cách gửi tín hiệu
điện đến bộ phận này từ bảng điều khiển. Người dùng gõ một số gồm
bốn chữ số để vào cửa. Thiết bị kiểm soát cửa so sánh số do người
dùng cung cấp với số được lập trình. Nếu hai số trùng khớp thì hệ
thống điều khiển sẽ bật đèn xanh, gửi tín hiệu đến bộ phận cơ điện để
mở cửa và bắt đầu hẹn giờ gọi là DoorOpen. Nếu hai số không khớp
nhau, thì đèn đỏ sẽ sáng trong 5 giây sau đó là thông báo chào mừng
bạn nhập mã PIN.
Bộ phận cửa phát hiện có người qua cửa hay không. Nếu ai đó đi qua
cửa, bộ phận cửa sẽ gửi tín hiệu Đã qua đến bộ phận điều khiển. Nếu
không có ai đi qua cửa, thiết bị cửa sẽ gửi tín hiệu NotPassed đến
thiết bị điều khiển. Nếu thiết bị điều khiển không nhận được tín hiệu
Đã qua cũng như Không được cấp, thì cuối cùng nó sẽ nhận được
thời gian chờ từ bộ hẹn giờ Mở cửa. Bộ phận cửa phải tạo ra một tín
hiệu thích hợp bất kể người dùng có đi qua cửa hay không. Nếu thiết
bị cửa không tạo ra các tín hiệu này, thì bộ phận điều khiển sẽ giả
định rằng thiết bị cửa bị lỗi, làm cho đèn vàng bật, hiển thị thông báo
rằng người dùng không được chào đón và chờ ở trạng thái không
hoạt động cho công việc sửa chữa cần thiết được thực hiện.
Control signals Electromechanical
system for door control
Message area
Green light
1 2 3
Red light 4 5 6
7 8 9
Yellow light * 0 #
CANCEL
Bảng điều khiển cửa Cửa

Hình 10.36 Truy cập có kiểm soát vào cửa.
Nếu thiết bị điều khiển nhận được tín hiệu Đã qua hoặc Chưa đạt
trong khi đèn xanh đang bật, bộ hẹn giờ Mở cửa sẽ dừng, đèn xanh
tắt, tín hiệu được gửi đến cửa để đóng và cuối cùng, hệ thống tự sẵn
sàng để xử lý yêu cầu người dùng khác. Người dùng có thể thay đổi ý
định của mình trong khi nhập mã PIN bằng cách nhấn nút hủy. Hơn
nữa, hiệu quả hủy tương tự có thể đạt được bằng cách bỏ qua quá
trình nhập mã PIN được bộ đếm thời gian phát hiện.
Mô tả trên của hệ thống kiểm soát cửa đã được nêu trong SDL ở
Hình 10.37, 10.38 và 10.39. Sơ đồ mức hệ thống được tìm thấy trong
Hình 10.37 và hoạt động của hệ thống kiểm soát cửa có thể được tìm
thấy trong sơ đồ quy trình của Hình 10.38 và 10.39. Người đọc có thể
được nhắc nhở rằng chúng tôi đã chỉ rõ hoạt động của hệ thống kiểm
soát cửa dưới dạng EFSM dưới dạng quy trình SDL được thể hiện
trong Hình 10.38 và 10.39.
419
SYSTEM DOORCONTROL 1(2)
[(UserData
)] [(DoorControl
)]
FromUser Door Control Control
ToUser Unit Status
[(Light), (Message), [(DoorStatus
)]
(Star)]
SYSTEM DOORCONTROL 2(2)
SIGNALLIST Light = Off, On;

SIGNALLIST Message = Welcome, NotWelcome;
SIGNALLIST Star = Asterisk;
SIGNALLIST DoorControl = Open, Close;

SIGNALLIST DoorStatus = Passed, NotPassed;
SIGNALLIST UserData = 0, 1, ..., 9, CANCEL;
Hình 10.37 Hệ thống kiểm soát cửa SDL / GR.

Hình 10.38 Đặc tả hành vi kiểm soát cửa.

421
PROCESS DoorControl
DOOROPEN
Timeout
Passed NotPassed
(DoorOpen)
Stop Timer Stop Timer Off

(DoorOpen) (DoorOpen) to GreenLight
Off Off On
to GreenLight to GreenLight to Yellow
Close Close Not Welcome

to Door to Door to Display
Welcome Welcome
to Display to Display
Start Timer Start Timer

(ReadDigit) (ReadDigit)
GETDIGIT GETDIGIT IDLE Figure10.39 Doorcontrolbehavior

specification.
10.13 SỰ TẠO KIỂM TRA TỪ CÁC MÔ HÌNH EFSM
Phần này giải thích các cơ chế để tạo các trường hợp thử nghiệm từ
mô hình EFSM của một hệ thống. Cụ thể, chúng tôi tạo các trường
hợp thử nghiệm từ quy trình SDL. Giả sử rằng chúng ta có một mô
hình EFSM E và một chương trình P E triển khai E một cách chính
xác . Nhiệm vụ của chúng ta là tạo các trường hợp kiểm thử từ E để
kiểm tra chương trình P E. Tốt nhất, chúng ta muốn tạo một bộ thử
nghiệm T E từ E để bằng cách thử nghiệm P E với T E , chúng ta xác
minh xem P E có triển khai các chức năng được chỉ định trong E hay
không . Về mặt lý thuyết, nói chung, không thể thiết kế một bộ thử
nghiệm như vậy, khi áp dụng cho P E , có thể tiết lộ tất cả các lỗi với
P E. Tuy nhiên, trong thực tế, chúng tôi muốn thiết kế T E với mục tiêu
xác minh rằng P E hoạt động như mong đợi đối với các trình tự đầu
vào thường được sử dụng. Mục tiêu này đạt được bằng cách thiết kế
T E theo hai giai đoạn:
Giai đoạn 1: Xác định một tập hợp các trình tự chuyển đổi trạng thái
sao cho mỗi trình tự chuyển đổi trạng thái đại diện cho một trình tự
sử dụng chung.
Giai đoạn 2: Thiết kế một trường hợp kiểm thử từ mỗi trình tự
chuyển đổi trạng thái đã xác định ở trên.
Trong giai đoạn 1 , nhiệm vụ chính là xác định các chuỗi chuyển đổi
trạng thái với hai mục tiêu. Mục tiêu đầu tiên là việc triển khai P E có
hỗ trợ các chức năng được biểu diễn bởi các trình tự đã chọn hay
không. Mục tiêu thứ hai là để lộ những sai sót trong quá trình thực
hiện. Ở đây, một lần nữa, các trình tự chuyển đổi trạng thái được
chọn để đáp ứng một số tiêu chí về phạm vi bảo hiểm. Chúng tôi
nhắc nhở người đọc rằng tiêu chí phạm vi cung cấp cho chúng ta một
phương pháp có hệ thống để lựa chọn các chuỗi chuyển đổi trạng
thái. Ngoài ra, tiêu chí phạm vi cung cấp cho chúng ta số lượng trình
tự tối thiểu mà chúng ta cần xác định. Trong khi chọn trình tự chuyển
đổi trạng thái, chúng ta phải làm như sau:
Thực hiện các thử nghiệm để đảm bảo rằng SUT tạo ra các chuỗi kết
quả mong đợi để đáp ứng với các chuỗi đầu vào.
Thực hiện các thử nghiệm để đảm bảo rằng SUT thực hiện các hành
động phù hợp khi thời gian chờ xảy ra.
Thực hiện các bài kiểm tra để đảm bảo rằng SUT đã triển khai các
khối tác vụ khác một cách thích hợp, chẳng hạn như phân bổ và phân
bổ tài nguyên, truy cập cơ sở dữ liệu, v.v.
Như đã thảo luận trước đó trong chương này, có hai tiêu chí bao phủ
nổi tiếng để lựa chọn trình tự chuyển đổi trạng thái, đó là, phạm vi
bao phủ trạng thái và phạm vi bao phủ chuyển tiếp. Tiêu chí trước
đây có nghĩa là xác định một tập hợp các chuyến tham quan chuyển
tiếp sao cho mọi tiểu bang đều được đến thăm ít nhất một lần. Tiêu
chí thứ hai có nghĩa là xác định một tập hợp các chuyến tham quan
chuyển tiếp sao cho mọi quá trình chuyển đổi trạng thái đều được
tham quan ít nhất một lần. Giai đoạn 2 , tức là quá trình tạo một
trường hợp thử nghiệm từ một trình tự chuyển tiếp, được giải thích
trong phần sau bằng một ví dụ.
Ví dụ: Tạo thử nghiệm từ Hệ thống Kiểm soát Cửa ra vào. Chúng
tôi trình bày mô hình EFSM của hệ thống kiểm soát cửa trong Hình
423
10.38 và 10.39. Hệ thống điều khiển có bốn trạng thái, đó là
GETDIGIT, RED, DOOROPEN và IDLE. Sau một chuỗi các bước
khởi tạo, EFSM chuyển sang trạng thái ban đầu GETDIGIT. Hành vi
bình thường của hệ thống bị hạn chế đối với các chuyển đổi trạng
thái giữa ba trạng thái GETDIGIT, RED và DOOROPEN. Nếu bộ
phận cửa cơ điện không phản hồi tín hiệu từ hệ thống kiểm soát cửa,
EFSM sẽ chuyển từ trạng thái DOOROPEN sang trạng thái IDLE.
Trạng thái IDLE có thể được coi là trạng thái lỗi. Sau khi các lỗi với
bộ phận cửa được khắc phục và bộ điều khiển được thiết lập lại, hệ
thống sẽ chuyển từ trạng thái IDLE sang trạng thái GETDIGIT. Do
đó, bằng cách thêm một chuỗi nhiệm vụ từ trạng thái IDLE đến
START của EFSM, chúng ta có thể làm cho EFSM được kết nối
mạnh mẽ.
Giả sử rằng quá trình SDL của Hình 10.38 và 10.39 ở trạng thái
GETDIGIT, chúng tôi thiết kế một trường hợp thử nghiệm bao gồm
chuyến tham quan chuyển tiếp được thể hiện trong Hình 10.40.
Chuyến tham quan chuyển tiếp này thực hiện vòng lặp gây ra bởi các
đầu vào chữ số ở trạng thái GETDIGIT trong khi các chữ số đọc
chưa hoàn thành. Chúng tôi giả định rằng người dùng nhập một dãy
chữ số có thể chấp nhận được; nghĩa là, phân tích các chữ số trong ô
quyết định là đầy đủ và hợp lệ.
NHẬN DIỆN ⇒ ... NHẬN DIỆN ⇒ ... NHẬN DIỆN ⇒ CỬA
CUỐN ⇒ GETDIGIT.
Hình 10.40 Hành trình chuyển tiếp từ hệ thống kiểm soát cửa
trên Hình 10.38 và 10.39.
Người đọc có thể nhận thấy rằng điều khiển có thể chuyển từ trạng
thái DOOROPEN sang trạng thái GETDIGIT theo hai cách, cụ thể là
bằng cách nhận các đầu vào Đã qua và Chưa qua, tương ứng với việc
ai đó đi qua cửa và không đi qua cửa, tương ứng. Trong khi tạo một
trường hợp thử nghiệm để bao gồm chuyến tham quan chuyển đổi ở
trên, chúng tôi giả định rằng đầu vào Đạt xảy ra. Trong phần sau,
chúng tôi tạo một trường hợp thử nghiệm bằng cách sử dụng ba
nguyên tắc thiết kế thử nghiệm được thảo luận trong Phần 10.5:
Bước 1: Chúng tôi chuyển đổi các đầu vào và đầu ra trong chuyến
tham quan chuyển tiếp thành đầu ra và đầu vào mong đợi, tương ứng,
để rút ra hành vi cốt lõi của một trường hợp thử nghiệm. Chúng tôi
thu được các cổng, cụ thể là DISPLAY, KEYPAD, GREENLIGHT
và DOOR, như trong Hình 10.41 bằng cách phân tích hành trình
chuyển tiếp của Hình 10.40. Trình tự các đầu vào và đầu ra được tìm
thấy trong Hình 10.38 và 10.39, tương ứng với hành trình chuyển
tiếp thể hiện trong Hình 10.40, đã được chuyển đổi tương ứng thành
đầu ra và đầu vào, trong ký hiệu TTCN-3 của Hình 10.42. Người đọc
có thể lưu ý rằng hoạt động thử nghiệm được chỉ ra trong Hình 10.42
là về bốn cổng được xác định trong Hình 10.41.
Nếu hệ thống thử nghiệm nhận thấy rằng SUT hoạt động như quy
định trong Hình 10.42, thì nó sẽ chỉ định một kết quả thử nghiệm
Đạt. Chúng tôi biểu thị một cách không chính thức một điều kiện sao
cho một ca kiểm thử xuất ra một số chữ số ở dòng 3 của Hình 10.42.
Chúng tôi đã thu được hành vi kiểm tra được hiển thị trong Hình
10.43 từ Hình 10.42 bằng cách tinh chỉnh câu lệnh if trong dòng 3
của Hình 10.42 như sau. Chúng tôi khởi tạo bộ đếm có giá trị 0 ở
dòng 1 của
Display Keypad Green light
Door control SUT
Door
Test system
Hình 10.41 Thử nghiệm hệ thống kiểm soát cửa ra vào.

1. nhãn nhãn1 BÀN PHÍM. gửi (chữ số);
2. TRƯNG BÀY. nhận (Dấu hoa thị);
3. if (KHÔNG đủ số chữ số) goto label1; // Chưa ở
dạng TTCN-3.
4. CỬA. nhận (Mở);
5. ĐÈN XANH. nhận (Bật);
6. CỬA. gửi (Đã qua);
7. ĐÈN XANH. nhận (Tắt);
425
số 8. CỬA. nhận (Đóng);
9. TRƯNG BÀY. nhận (Chào mừng);
10. setverdict (Vượt qua);
Hình 10.42 Hành vi đầu ra và đầu vào thu được từ chuyến tham
quan chuyển tiếp Hình 10.40.
count := 0; // Count is of type integer.
label label1 KEYPAD.send( digit );
DISPLAY.receive( Asterisk );
count := count + 1;
if (count < 4) goto label1;
else {
DOOR.receive( Open );
GREENLIGHT.receive( On );
DOOR.send( Passed );
GREENLIGHT.receive( Off );
DOOR.receive (Close);
DISPLAY.receive(Welcome);
setverdict(Pass); 14. };
Hình 10.43 Hành vi kiểm tra thu được bằng cách tinh chỉnh nếu
một phần trong Hình 10.42.
Hình 10.43 và tăng bộ đếm ở dòng 4 sau khi hành vi thử nghiệm xuất
ra một chữ số. Phần điều kiện không chính thức của câu lệnh if trong
dòng 7 của Hình 10.42 đã được tinh chỉnh thành một điều kiện cụ thể
trong Hình 10.43 (dòng 5) bằng cách giả định rằng hệ thống kiểm
soát cửa chấp nhận một chuỗi các chữ số có độ dài 4.
Bước 2: Chúng tôi tăng cường một hành vi thử nghiệm để chuẩn bị
cho chính nó để nhận các sự kiện khác với các sự kiện dự kiến. Điều
này được thực hiện bằng cách bao gồm một sự kiện bất kỳ, được biểu
thị bằng dấu “?,” Như một sự kiện thay thế cho mỗi sự kiện dự kiến.
Khi chúng ta áp dụng bước chuyển đổi này cho hành vi thử nghiệm
được thể hiện trong Hình 10.43, chúng ta sẽ có được hành vi thử
nghiệm được thể hiện trong Hình 10.44. Ví dụ: bất kỳ sự kiện nào
được biểu thị bằng dấu “?” trong dòng 20 của Hình 10.44 được thiết
kế để phù hợp với bất kỳ sự kiện nào không khớp với sự kiện dự kiến
được chỉ định trong dòng 18. Các sự kiện bất kỳ trong các dòng 23,
26, 29, 32 và 36 là các sự kiện thay thế cho các sự kiện dự kiến trong
dòng 16 , 14, 11, 9 và 4, tương ứng.
427
count := 0; // Count is of type integer.
label label1 KEYPAD.send( digit );
alt {
[] DISPLAY.receive( Asterisk );
count := count + 1;
if (count < 4) goto label1;
else {
alt {
[] DOOR.receive( Open );
alt {
[] GREENLIGHT.receive( On );
DOOR.send( Passed );
alt {
[] GREENLIGHT.receive( Off );
alt {
[] DOOR.receive (Close);
alt {
[] DISPLAY.receive(Welcome);
setverdict(Pass);
[] DISPLAY.receive(?);
setverdict(Fail);
}
[] DOOR.receive(?);
setverdict(Fail);
}
[] GREENLIGHT.receive(?);
setverdict(Fail);
}
[] GREENLIGHT.receive(?);
setverdict(Fail);
}
[] DOOR.receive(?);
setverdict(Fail);
}
} // end of else
[] DISPLAY.receive(?);
Hình 10.44 Hành vi kiểm tra có thể nhận được các sự kiện không
mong muốn (xuất phát từ Hình 10.43).
Bước 3: Chúng tôi tăng cường hành vi kiểm tra với các bộ định thời
để hệ thống kiểm tra không rơi vào trạng thái bế tắc trong trường hợp
SUT không tạo ra đầu ra, nghĩa là trước khi chờ nhận một sự kiện dự
kiến, hành vi kiểm tra bắt đầu một bộ đếm thời gian. Sự kiện đầu vào
thời gian chờ tương ứng được chỉ định thay thế cho đầu vào dự kiến
và bất kỳ sự kiện nào được giải thích trước đó. Khi chúng ta áp dụng
bước chuyển đổi này cho hành vi kiểm tra được thể hiện trong Hình
10.44, chúng ta sẽ có được hành vi kiểm tra như trong Hình 10.45.
Cuối cùng, hành vi kiểm tra được tăng cường với các phán quyết
kiểm tra. Kết quả Đạt được chỉ định nếu hệ thống đang kiểm tra hoạt
động như mong đợi và điều này được thể hiện trong dòng 10 của
Hình 10.42. Kết quả Vượt qua ở dòng 10 của Hình 10.42 có thể được
tìm thấy ở dòng 13 trong Hình 10.43, dòng 19 trong Hình 10.44 và
dòng 27 trong Hình 10.45, khi chúng tôi
429
1. count := 0; // Count is of type integer.
2. label label1 KEYPAD.send( digit );
3. Timer1.start(d1);
4. alt {
5 [] DISPLAY.receive( Asterisk );
6. Timer1.stop;
7. count := count + 1;
8. if (count < 4) goto label1;
9. else {
10. Timer2.start(d2);
11. alt {
12. [] DOOR.receive( Open );
13. Timer2.stop; Timer3.start(d3);
14. alt {
15. [] GREENLIGHT.receive( On );
16. Timer3.stop;
17. DOOR.send( Passed );
18. Timer4.start( d4 );
19. alt {
20. [] GREENLIGHT.receive( Off );
21. Timer4.stop; Timer5.start( d5 );
22. alt {
23. [] DOOR.receive (Close);
24. Timer5.stop; Timer6.start( d6 );
25. alt {
26. [] DISPLAY.receive(Welcome);
27. Timer6.stop; setverdict(Pass);
28. [] DISPLAY.receive(?);
29. Timer6.stop; setverdict(Fail);
30. [] Timer6.timeout;
31. setverdict(Inconc);
32. }
Hình 10.45 Hành vi cốt lõi của trường hợp thử nghiệm để thử
nghiệm hệ thống kiểm soát cửa (bắt nguồn từ
Hình 10.44.)
10.14 TIÊU CHÍ BAO NHIÊU BỔ SUNG ĐỂ KIỂM TRA HỆ
THỐNG
tiếp tục làm cho trường hợp thử nghiệm ngày càng hoàn thiện hơn.
Chúng tôi chỉ định kết quả Không thành công khi hệ thống kiểm tra
nhận được một sự kiện không mong muốn dưới dạng bất kỳ sự kiện
nào và một phán quyết Không độc quyền khi hết thời gian chờ xảy
ra.
10.14 TIÊU CHÍ BAO NHIÊU BỔ SUNG ĐỂ KIỂM TRA HỆ
THỐNG
Chúng tôi đã thảo luận về hai tiêu chí bao phủ, đó là, phạm vi bao
phủ trạng thái và phạm vi chuyển đổi trạng thái, để chọn các trường
hợp thử nghiệm từ các mô hình FSM và EFSM của hệ thống phần
mềm trong Phần 10.5 và 10.13. Hai tiêu chí đó tập trung vào các
chuỗi sự kiện, có thể bao gồm các sự kiện nội bộ, xảy ra tại PCO.
Trong phần này, chúng tôi giải thích thêm một số tiêu chí bao phủ
phù hợp với các khái niệm về kiểm thử chức năng.
Người đọc có thể nhớ lại từ Chương 9 về kiểm thử chức năng mà
chúng tôi xác định các miền của các biến đầu vào và đầu ra và chọn
dữ liệu kiểm tra dựa trên các giá trị đặc biệt từ các miền đó. Ví dụ,
nếu một biến đầu ra nhận một số lượng nhỏ các giá trị rời rạc, thì các
trường hợp thử nghiệm được thiết kế để làm cho SUT tạo ra tất cả
các giá trị đầu ra đó. Nếu một biến đầu ra nhận các giá trị từ một
phạm vi liền kề, dữ liệu thử nghiệm được chọn sao cho SUT tạo ra
các điểm bên ngoài và một điểm bên trong trong phạm vi được chỉ
định.
Phù hợp với khái niệm ở trên về kiểm tra chức năng, sau đây, chúng
tôi giải thích một số tiêu chí phù hợp cho các hệ thống hướng sự kiện
được mô hình hóa dưới dạng FSM hoặc EFSM. Đầu tiên, chúng tôi
xác định PCO, còn được gọi là cổng - các điểm mà SUT tương tác
với thế giới bên ngoài. Tiếp theo, chúng tôi áp dụng các tiêu chí phù
hợp sau để chọn các trường hợp thử nghiệm:
Phạm vi PCO: Chọn các trường hợp kiểm tra sao cho SUT nhận một
sự kiện ở mỗi PCO đầu vào và tạo ra một sự kiện ở mỗi PCO đầu ra.
431
Chuỗi sự kiện tại PCO: Chọn các trường hợp thử nghiệm sao cho các
chuỗi đầu vào và đầu ra phổ biến xảy ra tại PCO. Theo một trình tự
chung, chúng ta có nghĩa là các trình tự thường thấy trong việc sử
dụng hệ thống.
Sự kiện xảy ra trong các bối cảnh khác nhau: Trong nhiều ứng dụng,
người dùng tạo ra một sự kiện cho hệ thống bằng cách nhấn một nút,
chẳng hạn. Ở đây, một nút biểu thị PCO đầu vào và nhấn nút biểu thị
một sự kiện. Tuy nhiên, ngữ nghĩa của việc nhấn nút, tức là diễn giải
các sự kiện tại PCO, phụ thuộc vào ngữ cảnh dữ liệu được hệ thống
sử dụng. Đối với một ngữ cảnh nhất định, dữ liệu thử nghiệm được
chọn sao cho tất cả các sự kiện, cả mong muốn và không mong
muốn, đều xảy ra trong ngữ cảnh.
Sự kiện không phù hợp: Một hệ thống dự kiến sẽ loại bỏ các sự kiện
không hợp lệ hoặc có lỗi. Mặt khác, các sự kiện không phù hợp là
những sự kiện bình thường xảy ra vào thời điểm không thích hợp.
Ví dụ: Máy giao dịch tự động. Chúng ta hãy xem xét giao diện
người dùng của hệ thống ATM như trong Hình 10.46. Người dùng
chọn một trong các tùy chọn giao dịch và chỉ định số tiền giao dịch
bằng cách sử dụng các nút từ B1 đến B6. Ý nghĩa của một
1 2 3
4 5 6
Display 7 8 9
B1 B2
OK 0 CANCEL
B3 B4
B5 B6 Cash card slot

Receipt slot
Cash dispensing door Deposit envelope door
Hình 10.46 Giao diện người dùng của ATM.

1 2 3
Select an option
4 5 6
<=Fund transfer Deposit =>
7 8 9
B1 B2
Withdraw =>
OK 0 CANCEL
B3 B4
Check balance =>
B5 B6 Cash card slot
Receipt slot
Hình 10.47 Ràng buộc các nút với các tùy chọn của người dùng.
nút thay đổi khi thông báo trong vùng hiển thị thay đổi. Ví dụ, người
dùng có thể chọn một tùy chọn giao dịch, chẳng hạn như Gửi tiền
hoặc Rút tiền, bằng cách nhấn các nút B2 hoặc B4, tương ứng như
trong Hình 10.47. Tuy nhiên, như trong Hình 10.48, khi cần chọn số
tiền, các nút B2 và B4 lần lượt thể hiện các tùy chọn $ 40 và $ 100.
Hơn nữa, tất cả các nút cho ngữ cảnh số tiền được hiển thị trong Hình
10.48 không đại diện cho cùng một loại dữ liệu. Ví dụ: các nút từ B1
đến B5 đại diện cho các giá trị nguyên, rời rạc, trong khi nút B6 cung
cấp cho người dùng một tùy chọn để chỉ định các giá trị khác. Trong
ngữ cảnh được hiển thị trong Hình 10.47, các nút B3 và B5 là không
xác định, và do đó, đó là những nguồn tiềm ẩn của các sự kiện không
mong muốn (sai sót). Các trường hợp kiểm thử phải được chọn để
quan sát cách hệ thống phản ứng với các sự kiện không xác định. Nút
OK tạo ra một sự kiện bình thường trong khi người dùng nhập mã
PIN sau khi lắp thẻ tiền mặt. Sự kiện OK về cơ bản cho hệ thống biết
rằng người dùng
10.15 TÓM TẮT
433
1 2 3
Select an amount 4 5 6
$ 20 $40 7 8 9
B1 B2
$ 60 $100 OK 0 CANCEL
B3 B4
B5 $ 160 OTHER B6 Cash card slot

Receipt slot
Hình 10.48 Ràng buộc các nút với số tiền mặt.

đã nhập xong mã PIN. Tuy nhiên, có thể không có ý nghĩa khi nhấn
OK trong ngữ cảnh được hiển thị trong Hình 10.48. Do đó, nhấn nút
OK sẽ tạo ra một sự kiện không phù hợp để hệ thống xử lý. Các
trường hợp kiểm thử cần được lựa chọn để xem xét các sự kiện
không phù hợp ngoài các sự kiện bình thường (hợp lệ) và bất thường
(không hợp lệ hoặc sai sót).
10.15 TÓM TẮT
Chương này bắt đầu với việc phân loại hệ thống phần mềm theo hệ
thống không trạng thái và hệ thống hướng trạng thái. Một hệ thống
không trạng thái không ghi nhớ các đầu vào trước đó, và do đó, phản
ứng của nó đối với đầu vào mới không phụ thuộc vào các đầu vào
trước đó. Mặt khác, một hệ thống hướng trạng thái ghi nhớ trình tự
đầu vào mà nó đã nhận được cho đến nay ở dạng trạng thái. Tiếp
theo, chúng tôi xem xét khái niệm về cổng trong bối cảnh kiểm thử
phần mềm. Các hệ thống định hướng nhà nước được mô hình hóa
dưới dạng FSM.
Chúng tôi đã giải thích hai phương pháp rộng rãi để tạo chuỗi thử
nghiệm từ việc triển khai FSM — một phương pháp không có xác
minh trạng thái và một phương pháp có xác minh trạng thái. Người ta
có thể thiết kế các chuỗi thử nghiệm yếu dưới dạng các chuyến tham
quan chuyển tiếp mà không cần sử dụng xác minh trạng thái. Mặt
khác, người ta có thể thiết kế các trình tự kiểm tra mạnh hơn bằng
cách thực hiện xác minh trạng thái với một trong ba loại trình tự, cụ
thể là trình tự đầu vào - đầu ra duy nhất, trình tự phân biệt và trình tự
đặc trưng.
Chúng tôi đã kiểm tra bốn kiến trúc thử nghiệm: cục bộ, phân tán,
phối hợp và từ xa với các phương pháp tạo thử nghiệm tại chỗ. Các
kiến trúc kiểm tra trừu tượng này được mô tả dưới dạng các đầu vào
có thể điều khiển được cấp cho IUT và các đầu ra có thể quan sát
được từ IUT. Khái niệm về điểm kiểm soát và quan sát (PCOs) được
giới thiệu. PCO là một điểm tương tác được gọi là cổng, có thể truy
cập được đối với thực thể thử nghiệm, giữa thực thể thử nghiệm và
IUT.
Chúng tôi đã cung cấp phần giới thiệu ngắn gọn về Kiểm tra và Ký
hiệu Kiểm soát Kiểm tra Phiên bản 3 (TTCN-3), đây là một ký hiệu
phổ biến để chỉ định các trường hợp kiểm tra cho một hệ thống
truyền thông. Cụ thể, các tính năng sau được mô tả với các ví dụ:
mô-đun, kiểu dữ liệu, mẫu, cổng, thành phần và trường hợp thử
nghiệm.
Cuối cùng, chúng tôi đã giới thiệu khái niệm về máy trạng thái hữu
hạn mở rộng (EFSM), có khả năng thực hiện các tính toán bổ sung
như cập nhật các biến, thao tác với bộ định thời và đưa ra quyết định.
Khái niệm về một quy trình trong SDL cho phép người ta chỉ định
một mô-đun ở dạng EFSM. Cuối cùng, chúng tôi đã trình bày các
cách tạo các trường hợp thử nghiệm từ mô hình EFSM.
Bạn có thể tìm thấy một bộ sưu tập tuyệt vời các bài báo về thử
nghiệm dựa trên FSM trong cuốn sách do Richard J. Linn và M.
Umit Uyar biên tập [11]. Nhiều bài báo tham khảo trong chương này
đã được tái bản trong sách.
Những người muốn biết thêm về thử nghiệm dựa trên EFSM có thể
tham khảo cuốn sách xuất sắc của B. Sarikaya (Các nguyên tắc của
Kỹ thuật Giao thức và Kiểm tra Sự phù hợp, Ellis Horwood, Hemel
Hempstead, Hertfordshire, 1993). Sarikaya đã giải thích các ngôn
ngữ đặc tả chính thức Estelle, SDL, LOTOS, TTCN (Ký hiệu kết hợp
dạng cây và bảng gốc), và Ký hiệu cú pháp trừu tượng Một (ASN.1)
trong phần đầu tiên của cuốn sách của mình. Trong phần thứ hai của
cuốn sách, ông giải thích việc tạo ra các chuyến tham quan chuyển
tiếp từ một mô hình thống nhất của Estelle, SDL và LOTOS bằng
cách sử dụng các khái niệm về luồng điều khiển và luồng dữ liệu.
435
Trong thập kỷ qua, các nhà nghiên cứu đã đề xuất một số kỹ thuật để
tạo các trường hợp thử nghiệm từ các FSM không xác định. Trong
phần sau, chúng tôi liệt kê những cái thường được tham chiếu:
Xem xét FSM của Hình 10.17 được thảo luận trong chương này,
cung cấp bảng trình tự thử nghiệm, tương tự như Bảng 10.12, cho
chuyển đổi trạng thái ( D , B , b / y ).
Sự khác biệt cơ bản giữa trình tự UIO và các phương pháp phân biệt
trình tự xác minh trạng thái là gì?
Xét FSM G = <S, I, O, A, δ, λ> , được hiển thị trong Hình 10.49,
trong đó S = {A, B, C} là tập các trạng thái, I = {a, b, c} là tập hợp
các đầu vào, O = {e, f} là tập hợp các đầu ra, A là trạng thái ban đầu,
δ : S × I → S là hàm trạng thái tiếp theo và λ : S × I → O là hàm đầu
ra .
Tạo một trình tự phân biệt cho FSM, nếu nó tồn tại.
Tạo trình tự mô tả đặc điểm cho FSM.
Tạo (các) trình tự UIO cho mỗi trạng thái của FSM, nếu chúng tồn
tại.
So sánh trình tự phân biệt với trình tự UIO được tạo từ FSM. Có bất
kỳ điểm tương đồng và / hoặc sự khác biệt nào giữa hai loại trình tự
không?
Xét FSM H = <S, I, O, A, δ, λ> của Hình 10.50, trong đó S = {A, B,
C, D, E, F, G} là tập các trạng thái, I = { ri , a, c, x, z} là tập hợp
b/f
Initial state c/f
a/e
A B
a/f
c/e c/e
b/e b/f
a/f Hình 10.49FSM G.

Initial state
A G
a/b a/b a/f x/d
E B F
z/b c/d a/f z/f
C D
Hình 10.50 FSM H.

b/y
Initial state
A B
b/x
a/x b/x
a/y a/x
Hình 10.51 FSM K.

trong số các đầu vào, O = { null , b, f, d} là tập hợp các đầu ra, A là
trạng thái ban đầu, δ : S × I → S là hàm trạng thái tiếp theo và λ : S ×
I → O là chức năng đầu ra.
Tạo (các) trình tự UIO cho mỗi trạng thái của FSM, nếu chúng tồn
tại.
Tạo trình tự thử nghiệm cho mỗi lần chuyển đổi của FSM bằng Trình
tự UIO để xác minh trạng thái. Giả sử rằng một đầu vào đặt lại ri sẽ
luôn đưa FSM trở lại trạng thái ban đầu A. FSM tạo ra một đầu ra
rỗng để đáp ứng với đầu vào ri.
Biểu diễn hai trường hợp thử nghiệm sau ở dạng TTCN-3 với các
phán quyết: ( B, C, c / d ) và ( A, B, a / b ).
Xem xét FSM K = <S, I, O, A, δ, λ> của Hình 10.51, trong đó S =
{A, B, C} là tập các trạng thái, I = {a, b} là tập các đầu vào , O = {x,
y} là tập các đầu ra, A là trạng thái ban đầu, δ : S × I → S là hàm
trạng thái tiếp theo và λ : S × I → O là hàm đầu ra.
Chứng tỏ rằng FSM K không có một trình tự phân biệt.
Bạn có thể tạo chuỗi UIO cho mỗi trạng thái của FSM này không?
Biện minh cho câu trả lời của bạn.
Tạo trình tự mô tả đặc điểm cho FSM.
Xem xét FSM không xác định NFSM = <S, I, O, A, δ, λ> của Hình
10.52, trong đó S = {A, B, C, D, E, F, G} là tập các trạng thái, I = {
ri , a, c, x, z} là tập đầu vào, O = { null , b, f, d} là tập đầu ra, A là
đầu
437
Initial state
A G
a/b a/b c/f x/d
E B F
z/b c/d c/f c/d
C D
Hình 10.52 FSM không xác định.

trạng thái, δ : S × I → S là hàm trạng thái tiếp theo, và λ : S × I → O
là hàm đầu ra. NFSM là không xác định có nghĩa là đối với một số
đầu vào a k ∈ I , có nhiều hơn một quá trình chuyển đổi với các đầu ra
khác nhau được xác định cho một số trạng thái.
Tạo (các) trình tự UIO cho mỗi trạng thái của NFSM, nếu chúng tồn
tại.
Bạn có nghĩ rằng các chuỗi UIO được tạo có thể xác định duy nhất
các trạng thái không? Hãy chứng minh cho câu trả lời của bạn.
Thiết lập một phương pháp luận để xác định duy nhất các trạng thái
của NFSM. (Gợi ý: Cấu trúc cây sẽ xác định trạng thái của NFSM
duy nhất.) Sử dụng phương pháp luận của bạn, tạo cây UIO cho từng
trạng thái của NFSM.
Tạo các trường hợp thử nghiệm cho các chuyển đổi sau: (a) ( F, G,
x / d ), (b) ( B, C, c / d ) và (c) ( A, B, a / b ).
Biểu diễn hai trường hợp thử nghiệm sau ở dạng TTCN-3 với các
phán quyết: ( B, C, c / d ) và ( A, B, a / b ).
Thảo luận về hiệu quả của khả năng phát hiện lỗi trong số các kiến
trúc trừu tượng nhất được trình bày trong chương này.
Thiết kế một thành phần kiểm tra để kiểm tra hệ thống, được trình
bày trong Hình 10.8, từ quan điểm của một điện thoại cục bộ. Trong
thành phần thử nghiệm của bạn, hãy xem xét chuyến tham quan
chuyển tiếp từng phần OH – AD – RNG – TK.
Giả sử rằng một điện thoại gọi (từ xa) cách xa điện thoại gọi (nội
hạt), hãy giải thích khó khăn bạn sẽ gặp phải khi thiết kế trường hợp
thử nghiệm trong TTCN-3 từ chuyến tham quan chuyển tiếp sau đây
trong Hình 10.8: OH – AD – RNG– TK –LON – TK – RON – AD –
OH.
Giải thích khái niệm về các phán quyết trường hợp thử nghiệm.
CHAPTER
11
SystemTestDesign
Nhiều thứ khó thiết kế lại dễ thực hiện.
—SamuelJohnson
11.1 CÁC YẾU TỐ THIẾT KẾ THỬ NGHIỆM
Hoạt động trung tâm trong thiết kế thử nghiệm là xác định các yếu tố
đầu vào và các kết quả mong đợi từ một hệ thống để xác minh xem
hệ thống có sở hữu các tính năng nhất định hay không. Tính năng là
một tập hợp các yêu cầu liên quan. Các hoạt động thiết kế thử
nghiệm phải được thực hiện một cách có kế hoạch để đáp ứng một số
tiêu chí kỹ thuật, chẳng hạn như hiệu quả và các tiêu chí kinh tế,
chẳng hạn như năng suất. Do đó, chúng tôi xem xét các yếu tố sau
trong quá trình thiết kế thử nghiệm: (i) các chỉ số về mức độ phù hợp,
(ii) hiệu quả, (iii) năng suất, (iii) xác nhận, (iv) bảo trì và (v) kỹ năng
của người dùng. Sau đây, chúng tôi đưa ra động lực để xem xét các
yếu tố này.
Các chỉ số đo lường mức độ phù hợp liên quan đến mức độ mà DUT
được kiểm tra bởi một bộ thử nghiệm được thiết kế để đáp ứng các
tiêu chí nhất định. Các chỉ số về phạm vi bảo hiểm cho chúng tôi hai
lợi thế. Đầu tiên, những điều này cho phép chúng tôi định lượng mức
độ mà một bộ thử nghiệm bao gồm các khía cạnh nhất định, chẳng
hạn như chức năng, cấu trúc và giao diện của một hệ thống. Thứ hai,
những điều này cho phép chúng tôi đo lường tiến trình kiểm tra hệ
thống. Các tiêu chí có thể là kiểm tra đường dẫn, kiểm tra nhánh hoặc
một tính năng được xác định từ đặc tả yêu cầu.
Mỗi trường hợp thử nghiệm được cung cấp một (các) định danh để
được liên kết với một tập hợp các yêu cầu. Sự liên kết này được thực
hiện bằng cách sử dụng ý tưởng về một ma trận bao phủ. Một ma
trận bao phủ [ A ij ] được tạo ra cho ý tưởng trên về phạm vi bao phủ
[1]. Cấu trúc chung của ma trận bao phủ [ A ij ] được biểu diễn như
trong Bảng 11.1, trong đó T i là viết tắt của trường hợp thử nghiệm
11.2 XÁC ĐỊNH YÊU CẦU 439
thứ i và N j là viết tắt của yêu cầu thứ j được bao phủ; [ A ij ] là viết
tắt của trường hợp thử nghiệm T i trên phần tử được thử nghiệm N j .
Tập hợp đầy đủ các trường hợp thử nghiệm, tức là một bộ thử
nghiệm và tập hợp đầy đủ các phần tử được thử nghiệm của ma trận
bao phủ được xác định là T c = {T 1 , T 2 , .., T q } và N c = {N 1 , N 2
, .., N p } tương ứng.
Phương pháp luận phát triển trường hợp thử nghiệm có cấu trúc phải
được sử dụng nhiều nhất có thể để tạo ra một bộ thử nghiệm. Phương
pháp luận phát triển có cấu trúc cũng giảm thiểu công việc bảo trì và
cải thiện năng suất. Thiết kế cẩn thận các trường hợp thử nghiệm
321
BẢNG 11.1 Ma trận phủ [A ij ]
Trường hợp Mã định danh yêu cầu
thử nghiệm N 1 N2 ... Np
Định danh
T1 A 11 A 12 ... A 1
p
T2 A 21 A 22 ... A 2
p
T3 A 31 A 32 ... A 3
p
... ... ... ... ...
Tq Aq 1 Aq 2 ... Aqp
trong giai đoạn đầu của quá trình phát triển bộ thử nghiệm đảm bảo
khả năng bảo trì của chúng khi các yêu cầu mới xuất hiện. Tính đúng
đắn của các yêu cầu là rất quan trọng để phát triển các trường hợp
thử nghiệm hiệu quả để phát hiện ra các khiếm khuyết. Do đó, phải
nhấn mạnh vào việc xác định và phân tích các yêu cầu mà từ đó các
mục tiêu kiểm tra được hình thành. Các trường hợp thử nghiệm được
tạo dựa trên các mục tiêu thử nghiệm. Một khía cạnh khác của sản
xuất trường hợp thử nghiệm là xác nhận các trường hợp thử nghiệm
440 CHƯƠNG 11 THIẾT KẾ THỬ NGHIỆM HỆ THỐNG
để đảm bảo rằng những trường hợp đó là đáng tin cậy. Điều tự nhiên
là mong đợi rằng một trường hợp kiểm thử thực thi đáp ứng được đặc
điểm kỹ thuật của nó trước khi nó được sử dụng để kiểm tra một hệ
thống khác. Điều này bao gồm việc đảm bảo rằng các trường hợp
kiểm thử có quy trình xử lý lỗi đầy đủ và các tiêu chí đạt - không đạt
chính xác. Chúng tôi cần phát triển một phương pháp luận để hỗ trợ
sản xuất, thực hiện và bảo trì bộ thử nghiệm. Một yếu tố khác cần lưu
ý là người dùng tiềm năng của bộ thử nghiệm. Bộ thử nghiệm nên
được phát triển với những người dùng này; bộ thử nghiệm phải dễ
dàng triển khai và thực thi trong các môi trường khác và các thủ tục
để thực hiện việc này cần phải được lập thành văn bản thích hợp.
Vòng đời sản xuất bộ thử nghiệm của chúng tôi xem xét tất cả sáu
yếu tố được thảo luận ở trên.
11.2 XÁC ĐỊNH YÊU CẦU
Bằng chứng thống kê được thu thập bởi Vinter [2] cho thấy tầm quan
trọng của các yêu cầu được nắm bắt trong quá trình phát triển các dự
án hệ thống thời gian thực nhúng. Vinter đã phân tích 1000 lỗi trong
quá trình nghiên cứu của mình, trong đó 23,9% báo cáo lỗi xuất phát
từ các vấn đề yêu cầu, chức năng 24,3%, cấu trúc thành phần (mã)
20,9%, dữ liệu 9,6%, triển khai 4,3%, tích hợp 5,2%, kiến trúc 0,9% ,
thử nghiệm 6,9% và 4,3% khác. Trong các báo cáo lỗi có liên quan
đến các vấn đề về yêu cầu, Vinter lập luận rằng 48% có thể được
phân loại là “hiểu lầm”. Thông thường, sự bất đồng tồn tại trong việc
giải thích chính xác một yêu cầu cụ thể. Thiếu các ràng buộc chiếm
19% các báo cáo lỗi xuất phát từ vấn đề yêu cầu trong khi các yêu
cầu thay đổi chiếm 27%. 6% khác được phân loại là các vấn đề
"khác". Những nghiên cứu thống kê này đã truyền cảm hứng cho các
học viên ủng hộ một tầm nhìn mới về xác định các yêu cầu.
Yêu cầu là một mô tả về nhu cầu hoặc mong muốn của người dùng
mà một hệ thống phải thực hiện. Có hai thách thức chính trong việc
xác định các yêu cầu. Đầu tiên là đảm bảo rằng các yêu cầu phù hợp
được nắm bắt, đó là điều cần thiết để đáp ứng mong đợi của người
dùng. Các yêu cầu phải được thể hiện dưới dạng sao cho người dùng
và người đại diện của họ có thể dễ dàng xem xét và xác nhận tính
đúng đắn của chúng. Do đó, “hình thức” của một yêu cầu rất quan
trọng đối với sự giao tiếp giữa người dùng (và những người đại diện
của họ) và đại diện của một tổ chức phát triển phần mềm. Thứ hai là
đảm bảo rằng các yêu cầu được truyền đạt rõ ràng cho các nhà phát
triển và người kiểm tra để không có bất ngờ khi hệ thống được
chuyển giao. Một nhóm phát triển phần mềm có thể không phụ trách
việc thu thập các yêu cầu từ người dùng. Ví dụ, một nhóm tiếp thị có
thể thu thập các yêu cầu. Trong trường hợp này, có thể không có liên
kết trực tiếp giữa người dùng cuối cùng và các nhóm kỹ thuật, chẳng
hạn như nhóm phát triển, nhóm tích hợp hệ thống và nhóm kiểm tra
hệ thống. Các nhóm giải thích các yêu cầu theo cách riêng của họ là
điều không mong muốn. Có hai hậu quả nghiêm trọng khi các nhóm
khác nhau giải thích một yêu cầu theo những cách khác nhau. Đầu
tiên, nhóm phát triển và nhóm kiểm tra hệ thống có thể có những
tranh luận trái ngược nhau về chất lượng của sản phẩm trong khi
phân tích các yêu cầu trước khi giao hàng. Thứ hai, sản phẩm có thể
không đáp ứng được mong đợi của người dùng. Do đó, điều cần thiết
là phải có sự trình bày rõ ràng về các yêu cầu và cung cấp nó ở một
nơi tập trung để tất cả các bên liên quan có cùng cách giải thích về
các yêu cầu [3].
Chúng tôi mô tả một mô hình chính thức để nắm bắt các yêu cầu xem
xét và phân tích trong một tổ chức nhằm đạt được hai mục tiêu trên.
Hình 11.1 cho thấy một biểu đồ trạng thái của một vòng đời yêu cầu
đơn giản hóa bắt đầu từ trạng thái gửi đến trạng thái đóng. Mô hình
chuyển tiếp này cung cấp các giai đoạn khác nhau của một yêu cầu,
trong đó mỗi giai đoạn được biểu thị bằng một trạng thái. Mô hình
này đại diện cho vòng đời của một yêu cầu từ khi bắt đầu cho đến khi
hoàn thành thông qua các trạng thái sau: đệ trình, mở, xem xét, gán,
cam kết, thực hiện, xác minh và cuối cùng là đóng. Tại mỗi trạng thái
này, chủ sở hữu thực hiện một số hành động nhất định và yêu cầu
được chuyển sang trạng thái tiếp theo sau khi hoàn thành các hành
động. Một yêu cầu có thể được chuyển sang trạng thái từ chối từ bất
kỳ trạng thái nào đang mở, xem xét, chỉ định, thực hiện và xác minh
vì một số lý do. Ví dụ, một giám đốc tiếp thị có thể quyết định
Submit Open Review Assign
Decline
Closed Verification Implement Commit
Hình 11.1 Biểu đồ chuyển đổi trạng thái của yêu cầu.
rằng việc thực hiện một yêu cầu cụ thể có thể không tạo ra doanh thu.
Do đó, giám đốc tiếp thị có thể từ chối một yêu cầu và chấm dứt quá
trình phát triển.
Biểu đồ chuyển đổi trạng thái hiển thị vòng đời của một yêu cầu
riêng lẻ có thể được thực hiện dễ dàng bằng cách sử dụng hệ thống
cơ sở dữ liệu với giao diện người dùng đồ họa (GUI). Người ta có thể
tùy chỉnh bất kỳ hệ thống theo dõi mã nguồn mở hiện có nào để thực
hiện mô hình yêu cầu được mô tả ở đây [4]. Ý tưởng đằng sau việc
thực hiện sơ đồ chuyển đổi trạng thái là có thể theo dõi các yêu cầu
khi các yêu cầu này chảy qua tổ chức [5, 6]. Một lược đồ yêu cầu
được thiết kế với các ngăn theo thẻ khác nhau bằng cách sử dụng
GUI và cơ sở dữ liệu thường được sử dụng. Sau đó, các yêu cầu có
thể được lưu trữ và các truy vấn được tạo ra để theo dõi và báo cáo
trạng thái của các yêu cầu. Danh sách các trường của lược đồ được
đưa ra trong Bảng 11.2. Cần phải triển khai một hệ thống truy cập an
toàn cho những người dùng khác nhau của cơ sở dữ liệu. Khách hàng
BẢNG 11.2 Tóm tắt trường lược đồ yêu cầu
Tên trường Sự mô tả
request_id Một số nhận dạng duy nhất được liên kết với
yêu cầu
Tiêu đề Tiêu đề của yêu cầu; tóm tắt một dòng về yêu
cầu
sự mô tả Mô tả yêu cầu
tiểu bang Tình trạng hiện tại của yêu cầu; có thể lấy
một giá trị từ tập hợp

{ Đã đóng, Từ chối, Gửi, Mở, Xem lại, Chỉ
định, Cam kết, Thực hiện, Xác minh, }
sản phẩm Tên sản phẩm
khách hàng Tên của khách hàng đã yêu cầu yêu cầu này
Ghi chú Ghi chú của người gửi; bất kỳ thông tin bổ
sung nào mà người gửi muốn cung cấp sẽ hữu
ích cho giám đốc tiếp thị hoặc giám đốc kỹ
thuật phần mềm
phát hành phần mềm Được chỉ định cho một bản phát hành phần
mềm; số phát hành phần mềm trong đó yêu
cầu được mong muốn có sẵn cho khách hàng
cuối
cam kết Số phát hành phần mềm sẽ có sẵn yêu cầu
quyền ưu tiên Mức độ ưu tiên của yêu cầu; có thể nhận giá
trị từ tập hợp { cao, bình thường }
mức độ nghiêm trọng Mức độ nghiêm trọng của yêu cầu; có thể
marketing_justificatio nhận giá trị từ setnormal } { quan trọng,
n Tiếp thị biện minh cho sự tồn tại của yêu cầu
eng_comment Nhận xét của giám đốc kỹ thuật phần mềm
sau khi xem xét các yêu cầu; nhận xét hữu ích
khi phát triển đặc tả chức năng, mã hóa hoặc
kiểm thử đơn vị
time_to_implement Ước tính theo người-tuần; thời gian cần thiết
để thực hiện yêu cầu, bao gồm phát triển đặc
tả chức năng, mã hóa, đơn vị và thử nghiệm
tích hợp
eng_assigned Được giao cho một kỹ sư bởi giám đốc kỹ
thuật phần mềm để xem xét yêu cầu
function_spec_title Tiêu đề đặc tả chức năng
function_spec_name Tên tệp đặc tả chức năng
function_spec_version Phiên bản mới nhất của đặc điểm kỹ thuật
chức năng
BẢNG 11.2 (Còn tiếp)
từ chối Giải thích lý do tại sao yêu cầu bị từ chối

ec_number Số tài liệu thay đổi kỹ thuật (EC)
tập tin đính kèm Tập tin đính kèm (nếu có)
tc_id Bộ nhận dạng trường hợp thử nghiệm; nhiều mã
định danh trường hợp thử nghiệm có thể được
nhập; các giá trị này có thể được lấy tự động từ
cơ sở dữ liệu của nhà máy thử nghiệm
tc_results Kết quả trường hợp thử nghiệm; có thể lấy giá trị
từ cơ sở dữ liệu đã thiết lập Không thành công,
Bị chặn, Không hợp lệ } ; có thể được lấy tự
động từ bài kiểm tra { Chưa được kiểm tra, Đã
đạt,
phương thức xác Phương thức xác minh; T — bằng cách thử
minh nghiệm; A — bằng cách phân tích; D — bằng
cách trình diễn; Tôi — bằng cách kiểm tra
verify_status Trạng thái xác minh (thông qua, không thành
công, không đầy đủ) của yêu cầu.
thử nghiệm tuân Tuân thủ; có thể nhận giá trị từ sự tuân thủ
thủ setcompliance, noncompliance } { sự tuân
thủ, một phần
Ghi chú của kỹ sư thử nghiệm; có thể chứa giải
thích về phân tích, kiểm tra hoặc trình diễn do kỹ
sư kiểm tra cung cấp cho khách hàng cuối
error_id Định danh khiếm khuyết; giá trị có thể được trích
xuất từ cơ sở dữ liệu của nhà máy thử nghiệm
cùng với kết quả thử nghiệm. Nếu trường
tc_results nhận giá trị "không thành công", thì mã
nhận dạng lỗi được liên kết với trường hợp thử
nghiệm không thành công để chỉ ra lỗi gây ra lỗi.
có thể được cấp quyền truy cập hạn chế vào cơ sở dữ liệu để họ có
thể thấy trạng thái của các yêu cầu của họ trong tổ chức. Khách hàng
có thể tạo ma trận xác định nguồn gốc từ hệ thống cơ sở dữ liệu yêu
cầu, giúp họ tin tưởng về phạm vi kiểm tra [7]. Ma trận xác định
nguồn gốc cho phép người ta tìm ra ánh xạ hai chiều giữa các yêu
cầu và trường hợp thử nghiệm như sau [8]:
Từ một yêu cầu đến một đặc điểm kỹ thuật chức năng đến các bài
kiểm tra cụ thể thực hiện các yêu cầu
Từ mỗi trường hợp thử nghiệm trở lại yêu cầu và thông số kỹ thuật
chức năng
Ma trận xác định nguồn gốc tìm thấy hai ứng dụng: (i) xác định và
theo dõi phạm vi chức năng của một thử nghiệm và (ii) xác định
những trường hợp thử nghiệm nào phải được thực hiện hoặc cập nhật
khi một hệ thống phát triển [9]. Rất khó để xác định mức độ bao phủ
đạt được bởi một bộ thử nghiệm mà không có ma trận xác định
nguồn gốc. Bộ thử nghiệm có thể chứa một số lượng lớn các thử
nghiệm cho các tính năng của hệ thống, nhưng nếu không có sự tham
khảo chéo được cung cấp bởi ma trận xác định nguồn gốc thì rất khó
để phân biệt liệu một yêu cầu cụ thể đã được đề cập đầy đủ hay chưa.
Định nghĩa sau đây của Gotel và Finkelstein [10] tóm tắt quan điểm
chung về truy xuất nguồn gốc các yêu cầu (trang 97):
Khả năng xác định nguồn gốc các yêu cầu là khả năng mô tả và tuân
theo vòng đời của một yêu cầu, theo cả hướng tiến và lùi, tức là từ
nguồn gốc của nó, thông qua quá trình phát triển và đặc điểm kỹ
thuật, đến việc triển khai và sử dụng tiếp theo, và qua các giai đoạn
cải tiến và lặp lại liên tục trong bất kỳ giai đoạn nào trong số này.
Trạng thái gửi Một yêu cầu mới được đưa vào trạng thái gửi để
cung cấp cho những người khác. Chủ sở hữu của trạng thái này là
người gửi. Một yêu cầu mới có thể đến từ các nguồn khác nhau:
khách hàng, giám đốc tiếp thị và giám đốc chương trình. Người quản
lý chương trình giám sát một bản phát hành phần mềm bắt đầu từ khi
thành lập cho đến khi hoàn thành và chịu trách nhiệm giao nó cho
khách hàng. Bản phát hành phần mềm là việc phát hành hình ảnh
phần mềm cung cấp các tính năng mới. Ví dụ: người ta có thể phát
hành một hệ điều hành cho khách hàng tám tháng một lần bằng cách
thêm các tính năng mới và sử dụng sơ đồ đánh số thích hợp, chẳng
hạn như bản phát hành OS 2.0, bản phát hành OS 2.1, v.v. Thông
thường, các yêu cầu được tạo ra từ khách hàng và giám đốc tiếp thị.
Một lỗi do kỹ sư thử nghiệm đệ trình có thể trở thành một yêu cầu
trong bản phát hành trong tương lai vì có thể rõ ràng rằng lỗi được
báo cáo không thực sự là một lỗi thực sự và nên được coi là một yêu
cầu cải tiến. Trong trường hợp có tranh chấp giữa các kỹ sư thử
nghiệm và các nhà phát triển, người quản lý chương trình có thể đưa
ra quyết định cuối cùng với sự tham khảo ý kiến của những người có
liên quan. Người quản lý chương trình có thể gửi một yêu cầu mới
dựa trên vấn đề được nêu ra trong khiếm khuyết nếu người đó quyết
định rằng thực tế, khiếm khuyết đang tranh chấp là một yêu cầu nâng
cao. Các trường sau đây của lược đồ được cung cấp trong Bảng 11.2
được điền khi một yêu cầu được gửi: request_id: Một mã định danh
duy nhất được liên kết với yêu cầu. ưu tiên: Mức độ ưu tiên của yêu
cầu — cao hoặc bình thường. title: Tiêu đề cho yêu cầu. người nộp:
Tên của người gửi. description: Mô tả ngắn gọn về yêu cầu. lưu ý:
Một số lưu ý về yêu cầu này, nếu có . sản phẩm: Tên của sản phẩm
mà yêu cầu được mong muốn. khách hàng: Tên của khách hàng đã
yêu cầu yêu cầu này.
Mức độ ưu tiên là một chỉ báo về thứ tự mà các yêu cầu cần được
thực hiện. Ưu tiên các yêu cầu [11] là một khía cạnh quan trọng trong
quy trình thiết kế các yêu cầu theo định hướng thị trường [12, 13].
Tất cả các yêu cầu ưu tiên cao cần được xem xét để thực hiện trước
các yêu cầu ưu tiên thông thường. Người gửi có thể chỉ định mức độ
ưu tiên cho một yêu cầu xác định mức độ quan trọng của yêu cầu đó.
Người quản lý tiếp thị có thể chuyển trạng thái từ gửi sang mở bằng
cách chỉ định quyền sở hữu cho chính mình.
Trạng thái mở Trong trạng thái này, giám đốc tiếp thị phụ trách yêu
cầu và điều phối các hoạt động sau đây.
Xem lại yêu cầu để tìm các mục trùng lặp. Người quản lý tiếp thị có
thể chuyển yêu cầu trùng lặp từ trạng thái mở sang trạng thái từ chối
bằng một lời giải thích và một con trỏ đến yêu cầu hiện có. Ngoài ra,
người đó có thể đảm bảo rằng không có sự mơ hồ nào trong yêu cầu
và nếu có bất kỳ sự không rõ ràng nào, hãy tham khảo ý kiến của
người gửi và cập nhật mô tả cũng như các trường ghi chú của yêu
cầu.
Đánh giá lại mức độ ưu tiên của yêu cầu được chỉ định bởi người gửi
và chấp nhận hoặc sửa đổi nó.
Xác định mức độ nghiêm trọng của yêu cầu. Có hai mức độ nghiêm
trọng được xác định cho mỗi yêu cầu: bình thường và nghiêm trọng.
Tùy chọn mức độ nghiêm trọng cung cấp một thẻ cho quản lý cấp
trên, chẳng hạn như giám đốc kỹ sư phần mềm, để xem xét yêu cầu.
Nếu mức độ nghiêm trọng là nghiêm trọng, thì đó là một lá cờ cho

giám đốc để hoàn thành việc xem xét càng sớm càng tốt. Việc ấn
định mức độ nghiêm trọng được thực hiện độc lập với mức độ ưu
tiên.
Đề xuất một bản phát hành phần mềm ưu tiên cho yêu cầu.
Đính kèm lý do tiếp thị cho yêu cầu. • Chuyển yêu cầu từ trạng thái
mở sang trạng thái xem xét bằng cách giao quyền sở hữu cho giám
đốc kỹ thuật phần mềm.
Người quản lý tiếp thị có thể từ chối một yêu cầu ở trạng thái mở và
chấm dứt quá trình phát triển, do đó chuyển yêu cầu sang trạng thái
từ chối với một lời giải thích thích hợp.
Các trường sau đây có thể được cập nhật bởi người quản lý tiếp thị,
người là chủ sở hữu của yêu cầu ở trạng thái mở:
ưu tiên: Đánh giá lại mức độ ưu tiên — cao hoặc bình thường — của
yêu cầu này. mức độ nghiêm trọng: Chỉ định mức độ nghiêm trọng
— bình thường hoặc nghiêm trọng — cho yêu cầu.
từ chối: Đưa ra lời giải thích về yêu cầu nếu bị từ chối.
software_release: Đề xuất bản phát hành phần mềm ưu tiên cho yêu
cầu.
marketing_justification: Cung cấp lý do tiếp thị cho yêu cầu.
mô tả: Mô tả yêu cầu, nếu có bất kỳ sự mơ hồ nào. Lưu ý: Hãy đưa ra
bất kỳ nhận xét hữu ích nào, nếu có nhu cầu.
xét Giám đốc kỹ thuật phần mềm là chủ sở hữu của yêu cầu trong
trạng thái xem xét. Một yêu cầu vẫn ở trạng thái xem xét cho đến khi
nó vượt qua quy trình kỹ thuật như được giải thích trong phần sau.
Giám đốc kỹ thuật phần mềm xem xét yêu cầu để hiểu nó và ước tính
thời gian cần thiết để thực hiện điều này. Do đó, giám đốc chuẩn bị
một phiên bản sơ bộ của đặc tả chức năng cho yêu cầu này. Đề án
này cung cấp một khuôn khổ để ánh xạ yêu cầu đối với đặc tả chức
năng sẽ được thực hiện. Giám đốc kỹ thuật phần mềm có thể chuyển
yêu cầu từ trạng thái xem xét sang trạng thái chỉ định bằng cách thay
đổi quyền sở hữu cho người quản lý tiếp thị. Hơn nữa, giám đốc có
thể từ chối yêu cầu này nếu không thể thực hiện được. Giám đốc có
thể cập nhật các trường sau:
eng_comment: Các nhận xét được tạo ra trong quá trình đánh giá
được ghi nhận trong trường này. Các nhận xét hữu ích trong việc
phát triển đặc tả chức năng, tạo mã hoặc thực hiện kiểm tra cấp đơn
vị.
time_to_implement: Trường này chứa thời gian ước tính tính bằng
người-tuần để thực hiện yêu cầu.
tài liệu đính kèm: Một tài liệu phân tích, nếu có, bao gồm các số liệu
và mô tả có khả năng hữu ích trong việc phát triển các thông số kỹ
thuật chức năng trong tương lai.
function_spec_title: Tên của đặc tả chức năng sẽ được viết cho yêu
cầu này.
function_spec_name: Tên tệp đặc tả chức năng.
function_spec_version: Số phiên bản mới nhất của đặc tả chức năng.
eng_assigned: Tên kỹ sư được giám đốc giao nhiệm vụ xem xét yêu
cầu.
định Người quản lý tiếp thị là chủ sở hữu của yêu cầu trong trạng
thái được chỉ định. Người quản lý tiếp thị chỉ định yêu cầu cho một
bản phát hành phần mềm cụ thể và chuyển yêu cầu sang trạng thái
cam kết bằng cách thay đổi quyền sở hữu cho người quản lý chương
trình, người sở hữu bản phát hành phần mềm cụ thể đó. Người quản
lý tiếp thị có thể từ chối yêu cầu và chấm dứt quá trình phát triển, do
đó chuyển yêu cầu sang trạng thái từ chối. Các trường sau đây được
cập nhật bởi người quản lý tiếp thị: từ chối_note và phần
mềm_release. Điều trước đây giữ một lời giải thích cho việc từ chối,
nếu nó được chuyển sang trạng thái suy giảm. Mặt khác, nếu yêu cầu
được chuyển sang trạng thái cam kết, người quản lý tiếp thị sẽ cập
nhật trường thứ hai để chỉ định bản phát hành phần mềm mà yêu cầu
sẽ có sẵn.
Trạng thái cam kết Người quản lý chương trình là chủ sở hữu của
yêu cầu trong trạng thái cam kết. Yêu cầu vẫn ở trạng thái này cho
đến khi nó được cam kết phát hành phần mềm. Người quản lý
chương trình xem xét tất cả các yêu cầu được đề xuất trong một bản
phát hành cụ thể do anh ta sở hữu. Người quản lý chương trình có thể
ấn định lại một yêu cầu cụ thể cho một bản phát hành phần mềm
khác bằng cách tham khảo ý kiến của giám đốc tiếp thị, giám đốc kỹ
thuật phần mềm và khách hàng. Người quản lý chương trình có thể
chuyển yêu cầu sang trạng thái triển khai sau khi nó được cam kết
với một bản phát hành phần mềm cụ thể. Tất cả các thông số kỹ thuật
chức năng nên được đóng băng sau khi một yêu cầu được cam kết,
nghĩa là thoát khỏi trạng thái cam kết. Điều quan trọng là phải ổn
định và đóng băng đặc điểm kỹ thuật chức năng để thiết kế và phát
triển thử nghiệm. Các kỹ sư kiểm tra phải hoàn thành việc xem xét
yêu cầu và đặc điểm kỹ thuật chức năng liên quan trên quan điểm
khả năng kiểm tra. Tiếp theo, các kỹ sư kiểm thử có thể bắt đầu thiết
kế và viết các trường hợp kiểm thử cho yêu cầu này, như đã thảo luận
trong Phần 11.6. Trường duy nhất được cập nhật bởi người quản lý
chương trình, người là chủ sở hữu của yêu cầu trong trạng thái cam
kết, là commit_release. Trường chứa số phát hành cho yêu cầu này.
Trạng thái triển khai Giám đốc kỹ thuật phần mềm là chủ sở hữu
của yêu cầu trong trạng thái triển khai. Trạng thái này ngụ ý rằng
nhóm kỹ thuật phần mềm hiện đang mã hóa và đơn vị thử nghiệm
yêu cầu. Giám đốc kỹ thuật phần mềm có thể chuyển yêu cầu từ
trạng thái triển khai sang trạng thái xác minh
BẢNG 11.3 Thông tin tài liệu thay đổi kỹ thuật
Số EC Một số duy nhất

(Các) yêu cầu bị ảnh (Các) ID yêu cầu và tiêu đề
hưởng
Sự cố / mô tả sự cố Mô tả ngắn gọn về vấn đề
Mô tả thay đổi bắt buộc Mô tả các thay đổi cần thiết đối với
mô tả yêu cầu ban đầu
Tác động kỹ thuật thứ Mô tả tác động của EC đối với hệ
cấp thống
Tác động của khách Mô tả tác động của EC đối với khách
hàng hàng cuối cùng
Thay đổi được đề xuất Tên của (các) kỹ sư
bởi
Thay đổi được phê Tên của (các) người phê duyệt
duyệt bởi
trạng thái sau khi việc thực hiện hoàn tất và phần mềm được phát
hành để kiểm tra hệ thống, Giám đốc có thể ấn định số EC và giải
thích rằng yêu cầu này không thể thực hiện được trong định nghĩa
hiện tại của nó. Tài liệu EC được đính kèm với định nghĩa yêu cầu.
Bản phác thảo của một tài liệu EC được đưa ra trong Bảng 11.3.
Giám đốc cũng có thể từ chối yêu cầu, nếu về mặt kỹ thuật không thể
thực hiện nó và chuyển yêu cầu sang trạng thái từ chối. Các trường
sau đây có thể được cập nhật bởi giám đốc, vì anh ta hoặc cô ta là
chủ sở hữu của một yêu cầu trong trạng thái triển khai:
suy_thường: Giải thích lý do yêu cầu bị từ chối nếu chuyển sang
trạng thái từ chối.
ec_number: Số tài liệu EC. tệp đính kèm: Tài liệu EC.
Trạng thái xác minh Người quản lý kiểm tra là chủ sở hữu của yêu
cầu trong trạng thái xác minh. Người quản lý kiểm tra xác minh yêu
cầu và xác định một hoặc nhiều phương pháp để ấn định kết quả
kiểm tra: (i) kiểm tra, (ii) kiểm tra, (iii) phân tích và (iv) chứng minh.
Nếu thử nghiệm là một phương pháp để xác minh một yêu cầu, thì
các số nhận dạng trường hợp thử nghiệm và kết quả của chúng sẽ
được cung cấp. Thông tin này được trích xuất từ nhà máy thử nghiệm
được thảo luận trong Phần 11.6. Kiểm tra có nghĩa là xem xét mã.
Phân tích có nghĩa là phân tích toán học và / hoặc thống kê. Trình
diễn có nghĩa là quan sát hệ thống đang hoạt động trực tiếp. Phán
quyết được chỉ định cho yêu cầu bằng cách cung cấp mức độ thông
tin tuân thủ: tuân thủ hoàn toàn, tuân thủ một phần hoặc không tuân
thủ. Một ghi chú thử nghiệm được bao gồm nếu một phương pháp
không phải là thử nghiệm được sử dụng để xác minh. Các ghi chú có
thể chứa giải thích về phân tích, kiểm tra hoặc chứng minh cho khách
hàng.
Yêu cầu có thể nhận được số EC từ người quản lý thử nghiệm như
một ghi chú thử nghiệm. Tài liệu của EC chỉ rõ bất kỳ sự thiếu hụt
nào trong việc thực hiện yêu cầu. Một sai lệch hoặc một lỗi được
phát hiện ở giai đoạn này hiếm khi có thể được sửa chữa. Thường
cần phải thương lượng với khách hàng thông qua một tài liệu EC đối
với yêu cầu. Người quản lý chương trình điều phối hoạt động thương
lượng này với khách hàng. Người quản lý thử nghiệm có thể từ chối
việc triển khai với số EC, giải thích rằng việc triển khai không phù
hợp với yêu cầu và chuyển sang trạng thái từ chối. Người quản lý
kiểm tra có thể chuyển yêu cầu sang trạng thái đóng sau khi nó đã
được xác minh và giá trị của trường verify_status được đặt thành “đã
đạt”. Các trường sau được người quản lý kiểm tra cập nhật vì họ là
chủ sở hữu của yêu cầu ở trạng thái xác minh:
suy_thường: Các lý do để từ chối yêu cầu này. ec_number: Số tài
liệu EC. tệp đính kèm: Tài liệu EC.
verify_method: Có thể lấy một trong bốn giá trị từ tập hợp { Thử
nghiệm, Phân tích, Trình diễn, Kiểm tra } .
verify_status: Có thể lấy một trong ba giá trị từ tập hợp { Đạt, Không
đạt, Chưa hoàn thành } , cho biết trạng thái xác minh cuối cùng của
yêu cầu.
tuân thủ: Có thể lấy một trong ba giá trị từ tập hợp { tuân thủ, tuân
thủ một phần, không tuân thủ } , cho biết mức độ mà hình ảnh phần
mềm tuân thủ các yêu cầu. tc_id: Các số nhận dạng trường hợp thử
nghiệm đáp ứng yêu cầu này.
tc_results: Kết quả trường hợp thử nghiệm cho các thử nghiệm trên.
Nó có thể nhận một trong năm giá trị từ tập hợp { Chưa được kiểm
tra, Đạt, Không đạt, Bị chặn, Không hợp lệ } . Các giá trị này được
trích xuất từ cơ sở dữ liệu của nhà máy thử nghiệm, được thảo luận
trong Phần 11.7.
error_id: Một định danh lỗi. Nếu trường tc_results nhận giá trị
"không thành công", thì mã nhận dạng lỗi được liên kết với trường
hợp thử nghiệm không thành công để chỉ ra lỗi gây ra lỗi. Giá trị này
được trích xuất từ cơ sở dữ liệu của nhà máy thử nghiệm.
testing_note: Có thể tổ chức giải thích về phân tích, kiểm tra hoặc
trình diễn mà kỹ sư thử nghiệm đưa ra cho khách hàng cuối.
Trạng thái đóng Yêu cầu được người quản lý kiểm tra chuyển sang
trạng thái đóng từ trạng thái xác minh sau khi nó được xác minh.
Trạng thái từ chối Ở trạng thái này, bộ phận tiếp thị là chủ sở hữu
của yêu cầu. Yêu cầu đến trạng thái này vì một số lý do sau:
Bộ phận tiếp thị đã từ chối yêu cầu này.
Về mặt kỹ thuật, không thể thực hiện yêu cầu này và có thể có số EC
liên quan.
Người quản lý thử nghiệm từ chối việc triển khai với số EC.
Nhóm tiếp thị có thể chuyển yêu cầu sang trạng thái gửi sau khi đã
cùng khách hàng xem xét. Giám đốc tiếp thị có thể giảm phạm vi của
yêu cầu sau khi thảo luận với khách hàng dựa trên thông tin EC và
gửi lại yêu cầu bằng cách chuyển nó sang trạng thái gửi.
11.3 CÁC ĐẶC ĐIỂM YÊU CẦU BẢNG THỬ

Các bài kiểm tra cấp hệ thống được thiết kế dựa trên các yêu cầu cần
được xác minh. Kỹ sư kiểm tra phân tích yêu cầu, các thông số kỹ
thuật chức năng liên quan và các tiêu chuẩn để xác định khả năng
kiểm tra của yêu cầu. Tác vụ trên được thực hiện ở trạng thái cam
kết. Phân tích khả năng kiểm tra có nghĩa là đánh giá các đặc điểm
hành vi tĩnh của yêu cầu tiết lộ các mục tiêu kiểm tra. Một cách để
xác định mô tả yêu cầu là có thể kiểm tra được như sau:
Thực hiện mô tả yêu cầu sau: Hệ thống phải thực hiện X. • Sau đó
đóng gói mô tả yêu cầu để tạo mục tiêu kiểm tra: Xác minh rằng hệ
thống thực hiện X một cách chính xác.
Xem lại mục tiêu kiểm tra này bằng cách đặt câu hỏi: Nó có khả thi
không? Nói cách khác, hãy tìm hiểu xem liệu có thể thực thi nó hay
không, giả sử rằng hệ thống và môi trường thử nghiệm có sẵn.
Nếu câu trả lời cho câu hỏi trên là có, thì mô tả yêu cầu là rõ ràng và
chi tiết cho mục đích thử nghiệm. Nếu không, cần phải thực hiện
nhiều công việc hơn để sửa đổi hoặc bổ sung mô tả yêu cầu.
Ví dụ, chúng ta hãy xem xét yêu cầu sau: Hình ảnh phần mềm phải
dễ dàng nâng cấp / hạ cấp khi mạng phát triển. Yêu cầu này quá rộng
và mơ hồ để xác định mục tiêu của một trường hợp thử nghiệm. Nói
cách khác, đó là một yêu cầu kém thủ công. Người ta có thể trình bày
lại yêu cầu trước đó như: Hình ảnh phần mềm phải dễ nâng cấp / hạ
cấp cho 100 phần tử mạng. Sau đó, người ta có thể dễ dàng tạo một
mục tiêu kiểm tra: Xác minh rằng hình ảnh phần mềm có thể được
nâng cấp / hạ cấp cho 100 phần tử mạng. Cần có thời gian, suy nghĩ
rõ ràng và can đảm để thay đổi mọi thứ.
Ngoài khả năng kiểm tra của các yêu cầu, các mục sau đây phải được
phân tích bởi các kỹ sư kiểm tra hệ thống trong quá trình xem xét:
An toàn: Các yêu cầu quan trọng về an toàn [14] đã được xác định
chưa? Các yêu cầu quan trọng về an toàn chỉ rõ những gì hệ thống
không được làm, bao gồm các phương tiện để loại bỏ và kiểm soát
các mối nguy và để hạn chế bất kỳ thiệt hại nào trong trường hợp xảy
ra sai sót.
Bảo mật: Các yêu cầu bảo mật [15], chẳng hạn như tính bảo mật,
tính toàn vẹn và tính khả dụng, đã được xác định chưa?
453
Tính đầy đủ: Đã hoàn thành tất cả các hạng mục thiết yếu chưa?
Tất cả các tình huống có thể xảy ra đã được giải quyết theo yêu cầu
chưa? Đã bỏ qua tất cả các mục không liên quan chưa?
Tính đúng đắn: Các yêu cầu có dễ hiểu và chúng đã được nêu ra mà
không mắc lỗi không? Có bất kỳ mặt hàng không chính xác?
Tính nhất quán: Có bất kỳ yêu cầu mâu thuẫn nào không?
Sự rõ ràng: Các tài liệu yêu cầu và các tuyên bố trong tài liệu có rõ
ràng, hữu ích và phù hợp không? Các sơ đồ, đồ thị và hình ảnh minh
họa có rõ ràng không? Những điều đó đã được thể hiện bằng cách sử
dụng ký hiệu thích hợp để có hiệu quả chưa? Những cái đó có xuất
hiện ở những nơi thích hợp không? Văn phong có rõ ràng không?
liên quan: Các yêu cầu có phù hợp với chủ đề không? Các yêu cầu
có hạn chế không cần thiết?
Tính khả thi: Các yêu cầu có khả thi không?
chứng: Các bài kiểm tra có thể được viết để chứng minh một cách
khách quan và kết luận rằng các yêu cầu đã được đáp ứng không?
Chức năng của hệ thống có thể được đo lường theo một cách nào đó
để đánh giá mức độ đáp ứng các yêu cầu không?
: Mỗi yêu cầu có thể được truy tìm các chức năng và dữ liệu liên
quan đến nó để những thay đổi trong một yêu cầu có thể dẫn đến việc
đánh giá lại dễ dàng không?
Đặc điểm kỹ thuật chức năng Một đặc điểm kỹ thuật chức năng
cung cấp:
Mô tả chính xác các chức năng chính mà hệ thống phải đáp ứng các
yêu cầu, mô tả việc thực hiện các chức năng và giải thích các rủi ro
công nghệ liên quan
Giao diện bên ngoài với các mô-đun phần mềm khác
Luồng dữ liệu như lưu đồ, sơ đồ trình tự giao dịch và FSM mô tả
trình tự hoạt động
Xử lý lỗi, sử dụng bộ nhớ và ước tính hiệu suất
Bất kỳ giới hạn kỹ thuật nào, nghĩa là, các yêu cầu được suy ra sẽ
không được hỗ trợ
Giao diện dòng lệnh hoặc hệ thống quản lý phần tử để cung cấp / cấu
hình tính năng nhằm gọi việc triển khai phần mềm liên quan đến tính
năng này
Một lần nữa, đặc điểm kỹ thuật chức năng phải được xem xét lại trên
quan điểm khả năng kiểm tra. Các đặc tính của các thông số kỹ thuật
chức năng có thể kiểm tra được nêu trong Bảng 11.4. Các thông số kỹ
thuật chức năng có nhiều khả năng được kiểm tra nếu chúng đáp ứng
tất cả các mục trong Bảng 11.4. Các vấn đề thường gặp với các đặc tả
chức năng bao gồm thiếu rõ ràng, không rõ ràng và không nhất quán.
Sau đây là các mục tiêu cần lưu ý khi xem xét đặc điểm kỹ thuật chức
năng [16]:
Yêu cầu đạt được: Điều cần thiết là đặc điểm kỹ thuật chức năng
xác định các yêu cầu chính thức cần đạt được. Bằng cách xem xét,
người ta xác định xem các yêu cầu đã được giải quyết bằng đặc điểm
kỹ thuật chức năng hay chưa.
Tính đúng đắn: Bất cứ khi nào có thể, các phần thông số kỹ thuật
phải được so sánh trực tiếp với tài liệu tham khảo bên ngoài để có
tính đúng đắn.
mở rộng: Đặc điểm kỹ thuật được thiết kế để dễ dàng điều chỉnh các
tiện ích mở rộng trong tương lai mà bạn có thể hình dung rõ ràng tại
thời điểm xem xét.
: Thông số kỹ thuật phải dễ hiểu. Vào cuối quá trình xem xét, nếu
người đánh giá không hiểu cách thức hoạt động của hệ thống, thì đặc
điểm kỹ thuật hoặc tài liệu của nó có thể bị thiếu sót.
BẢNG 11.4 Đặc điểm của các thông số kỹ thuật chức năng có
thể kiểm tra
Mục đích, mục tiêu và ngoại lệ được nêu rõ ràng. Giải quyết các mục
tiêu phù hợp.
Chứa đựng các yêu cầu và tiêu chuẩn mà tài liệu này tuân thủ.
Môi trường hoạt động được nêu rõ ràng. Đối với phần cứng, hệ điều
hành và phần mềm phát hành, tính năng này được nhắm mục tiêu.
Cấu hình phần cứng tối thiểu hỗ trợ ứng dụng này.
Liệt kê rõ ràng các chức năng chính mà hệ thống phải thực hiện.
Xác định rõ các tiêu chí thành công mà hệ thống phải đáp ứng để có
hiệu quả.
Cung cấp một mô hình dễ hiểu, có tổ chức và có thể bảo trì của các
quy trình, và dữ liệu hoặc đối tượng, sử dụng phương pháp có cấu
trúc chuẩn và nguyên tắc phân rã chức năng.
Sử dụng thuật ngữ tiêu chuẩn và được xác định rõ ràng (từ khóa,
bảng thuật ngữ, cú pháp và ngữ nghĩa).
455
Hiển thị sử dụng nhiều mô hình và đồ họa (ví dụ: SDL-GR, mô hình
trạng thái hữu hạn), không chủ yếu là tường thuật tiếng Anh.
Ghi lại các giả định.
Tài liệu phải có cấu trúc / dòng chảy tự nhiên và với mỗi tính năng
nguyên tử được gắn nhãn với một số nhận dạng để dễ dàng tham
khảo chéo các trường hợp thử nghiệm cụ thể.
Cần có quy trình xử lý ngoại lệ tiêu chuẩn, thông báo lỗi nhất quán và
chức năng trợ giúp trực tuyến.
Các giao diện bên ngoài, chẳng hạn như CLI, MIBs, EMS và giao
diện Web được xác định rõ ràng.
Đã nêu rõ ràng những đánh đổi có thể có giữa tốc độ, thời gian, chi
phí và tính di động.
Các yêu cầu về hiệu suất được xác định, thường là về gói tin trên
giây, giao dịch trên giây, thời gian khôi phục, thời gian phản hồi hoặc
các số liệu khác như vậy.
Giới hạn tỷ lệ và sử dụng tài nguyên (sử dụng CPU, sử dụng bộ nhớ)
được nêu chính xác.
Tài liệu về các bài kiểm tra đơn vị.
Lưu ý: SDL-GR, Đặc điểm kỹ thuật và Ngôn ngữ Mô tả Biểu diễn đồ

họa
Các thông số kỹ thuật và tài liệu như vậy cần được làm lại để làm cho
chúng dễ hiểu hơn.
Sự cần thiết: Mỗi mục trong tài liệu đều cần thiết.
đầy đủ: Đặc điểm kỹ thuật cần được kiểm tra xem có thiếu hoặc
không đầy đủ các mục. Tất cả các chức năng phải được mô tả cũng
như các thuộc tính quan trọng của dữ liệu đầu vào và đầu ra như khối
lượng và độ lớn.
triển khai: Cần có một đặc tả chức năng có thể thực hiện được trong
các ràng buộc tài nguyên nhất định sẵn có trong môi trường đích như
phần cứng, sức mạnh xử lý, bộ nhớ và băng thông mạng. Người ta có
thể thực hiện một đặc điểm kỹ thuật trong một khoảng thời gian ngắn
mà không cần đột phá về công nghệ.
Hiệu quả: Đặc điểm kỹ thuật chức năng phải tối ưu hóa những phần
của giải pháp đóng góp nhiều nhất vào hiệu suất (hoặc thiếu phần đó)
của hệ thống. Người đánh giá có quyền từ chối thông số kỹ thuật vì lý
do không hiệu quả trong việc xác định các yêu cầu về hiệu quả.
Tính đơn giản: Nói chung, việc đạt được và xác minh các yêu cầu
được nêu dưới dạng các thông số kỹ thuật chức năng đơn giản sẽ dễ
dàng hơn.
Các thành phần có thể tái sử dụng: Đặc điểm kỹ thuật nên sử dụng
lại các thành phần hiện có càng nhiều càng tốt và đủ mô-đun để các
thành phần chung có thể được trích xuất để sử dụng lại.
Tính nhất quán với các thành phần hiện có: Cấu trúc chung của
đặc điểm kỹ thuật phải nhất quán với các lựa chọn được thực hiện
trong phần còn lại của hệ thống. Nó không nên yêu cầu mô hình thiết
kế của một hệ thống phải thay đổi mà không có lý do thuyết phục.
Hạn chế: Các hạn chế cần thực tế và phù hợp với yêu cầu.
11.4 XÁC ĐỊNH MỤC TIÊU THỬ NGHIỆM
Câu hỏi "Tôi kiểm tra cái gì?" phải được trả lời bằng một câu hỏi
khác: "Tôi mong đợi hệ thống làm được gì?" Chúng ta không thể
kiểm tra hệ thống một cách toàn diện nếu chúng ta không hiểu nó. Do
đó, bước đầu tiên để xác định mục tiêu kiểm tra là đọc, hiểu và phân
tích đặc tả chức năng. Điều cần thiết là phải có nền tảng quen thuộc
với lĩnh vực chủ đề, các mục tiêu của hệ thống, quy trình kinh doanh
và người sử dụng hệ thống để phân tích thành công.
Chúng ta hãy xem xét yêu cầu đã sửa đổi trước đây của chúng tôi:
Hình ảnh phần mềm phải dễ dàng nâng cấp / hạ cấp cho 100 phần tử
mạng. Kỹ sư thử nghiệm cần hỏi một câu hỏi: Tôi cần biết gì để phát
triển một bộ mục tiêu thử nghiệm toàn diện cho yêu cầu trên? Một kỹ
sư kiểm tra tò mò cũng có thể hỏi những câu hỏi sau:
Chúng ta có phải nâng cấp hình ảnh phần mềm tuần tự trên từng phần
tử mạng hay đồng thời trên tất cả 100 phần tử không? Hoặc, chúng
tôi tiến hành một loạt 20 phần tử cùng một lúc?
Nguồn của bản nâng cấp là gì? Nguồn sẽ nằm trên máy chủ quản lý
phần tử?
“Dễ dàng” ở đây có nghĩa là gì? Nó có đề cập đến khoảng thời gian,
chẳng hạn, 200 giây, được thực hiện bởi quá trình nâng cấp?
Chúng ta có thể có sự kết hợp giữa hình ảnh phần mềm cũ và mới
trên các phần tử mạng khác nhau trên cùng một mạng không? Nói
cách khác, một hình ảnh phần mềm mới có tương thích với hình ảnh
cũ không?
457
Nếu chúng tôi hỗ trợ hình ảnh phần mềm cũ và mới trên các phần tử
mạng khác nhau trên cùng một mạng, thì EMS phải có khả năng quản
lý hai phiên bản của một phần mềm được cài đặt trên cùng một mạng.
EMS có thể quản lý các phần tử mạng chạy các phiên bản phần mềm
khác nhau không?
Phần mềm sẽ bị hạ cấp xuống phiên bản nào? Giả sử hình ảnh phần
mềm được nâng cấp lên bản phát hành thứ n từ bản phát hành thứ (n -
1 ) . Bây giờ, nếu hình ảnh phần mềm bị hạ cấp, thì nó nên được hạ
cấp xuống phiên bản nào— (n - 1 ) hay (n - 2 ) lần phát hành?
Trong khi hệ thống đang được nâng cấp, chúng ta có cần quan sát
việc sử dụng CPU của các phần tử mạng và máy chủ EMS không?
Hiệu suất sử dụng CPU dự kiến là bao nhiêu?
Chúng tôi phân tích nghiêm túc các yêu cầu để trích xuất các yêu cầu
được suy ra được nhúng trong các yêu cầu. Một yêu cầu được suy ra
là một yêu cầu mà một hệ thống được mong đợi sẽ hỗ trợ nhưng
không được nêu rõ ràng. Các yêu cầu suy ra cần được kiểm tra giống
như các yêu cầu đã nêu rõ ràng. Ví dụ, chúng ta hãy xem xét yêu cầu
rằng hệ thống phải có khả năng sắp xếp một danh sách các mục thành
một thứ tự mong muốn. Một mục tiêu kiểm tra rõ ràng là: Xác minh
rằng hệ thống có thể sắp xếp một danh sách các mục chưa được sắp
xếp. Tuy nhiên, có một số yêu cầu chưa xác định không được xác
nhận bởi mục tiêu thử nghiệm ở trên. Nhiều mục tiêu thử nghiệm
khác có thể được xác định cho yêu cầu:
Xác minh rằng hệ thống tạo ra danh sách các mục đã được sắp xếp
khi một danh sách các mục đã được sắp xếp được đưa ra làm đầu
vào. • Xác minh rằng hệ thống tạo ra danh sách các mục đã được sắp
xếp khi một danh sách các mục có độ dài khác nhau được đưa ra làm
đầu vào.
Xác minh rằng số lượng mục đầu ra bằng số lượng mục đầu vào.
Xác minh rằng nội dung của bản ghi đầu ra được sắp xếp giống với
nội dung của bản ghi đầu vào.
Xác minh rằng hệ thống tạo ra một danh sách các mục trống khi một
danh sách các mục trống được đưa ra làm đầu vào.
Kiểm tra hành vi hệ thống và danh sách đầu ra bằng cách đưa ra danh
sách đầu vào chứa một hoặc nhiều bản ghi trống (null).
Xác minh rằng hệ thống có thể sắp xếp một danh sách có chứa một
số lượng rất lớn các mục chưa được sắp xếp.
Các mục tiêu kiểm tra được tập hợp lại với nhau để tạo thành một
nhóm kiểm tra hoặc một nhóm con sau khi chúng đã được xác định.
Một tập hợp các nhóm (con) trường hợp kiểm thử được kết hợp một
cách hợp lý để tạo thành một nhóm lớn hơn. Cấu trúc phân cấp của
các nhóm thử nghiệm như trong Hình 11.2 được gọi là bộ thử
nghiệm. Cần phải xác định các nhóm kiểm tra dựa trên các loại kiểm
tra và tinh chỉnh các nhóm kiểm tra thành các tập hợp các mục tiêu
kiểm tra. Các trường hợp thử nghiệm riêng lẻ được tạo cho từng mục
11.5 VÍ DỤ 459
tiêu thử nghiệm trong các nhóm con; điều này được giải thích trong
phần tiếp theo với một ví dụ. Các nhóm kiểm tra có thể được lồng
vào một độ sâu tùy ý. Chúng có thể được sử dụng để hỗ trợ lập kế
hoạch và thực hiện kiểm tra hệ thống, tương ứng được thảo luận
trong Chương 13 và 13.
11.5 VÍ DỤ
Diễn đàn chuyển tiếp khung (FRF) xác định hai loại kịch bản liên kết
giữa chuyển tiếp khung (FR) / chế độ truyền không đồng bộ (ATM):
liên kết mạng [17] và liên kết dịch vụ [18]. Hai chức năng liên kết
này cung cấp một phương tiện mà hai công nghệ, cụ thể là ATM và
FR, có thể tương tác với nhau. Nói một cách đơn giản, mạng
Bộ thử nghiệm
Group 1 Group 2 Group N
Test objectives
Sub group 1 Sub group M
Sub subgroup 1 Sub subgroup K
Mục tiêu
kiểm tra
Mục tiêu kiểm tra Mục tiêu kiểm tra
Hình 11.2 Cấu trúc bộ kiểm thử.
Interworking cung cấp sự vận chuyển giữa hai thiết bị FR (hoặc thực
thể). Kết nối dịch vụ cho phép người dùng ATM làm việc với người
dùng FR một cách minh bạch và không ai biết rằng đầu bên kia sử
dụng một công nghệ khác.
Giả sử rằng một trong các yêu cầu là hỗ trợ liên kết dịch vụ như được
mô tả trong FRF.8 [18] trên một bộ chuyển mạch. Giám đốc kỹ thuật
phần mềm phát triển một đặc tả chức năng sau khi các yêu cầu được
giám đốc tiếp thị phê duyệt. Nhóm thử nghiệm phát triển một hạng
mục thử nghiệm dựa trên các yêu cầu và đặc điểm kỹ thuật chức
năng. Vì thông số kỹ thuật chức năng thực tế không có sẵn, chúng tôi
giả định như sau để đơn giản hóa:
Thuật ngữ FrAtm đề cập đến thành phần phần mềm cung cấp chức
năng liên kết dịch vụ kết nối ảo vĩnh viễn FR-ATM (PVC).
FrAtm hỗ trợ nhiều loại giao diện vật lý dựa trên tế bào ATM ở phía
ATM: OC3, E3, DS3, E1 và DS1. • FrAtm hỗ trợ nhiều loại giao
diện vật lý dựa trên khung ở phía FR: V.11, V.35, DS1, E1, DS3 và
E3.
Các thành phần con của FrAtm như sau: giao diện quản lý cục bộ
(LMI) và định danh kết nối liên kết dữ liệu (DLCI).
Các thành phần phần mềm FrAtm đang được triển khai trên bộ
chuyển mạch FR và ATM. Nói cách khác, cả FR và chức năng ATM
đều có sẵn trên cùng một công tắc.
Hãy để chúng tôi phân tích ngắn gọn chức năng liên kết dịch vụ
trước khi chúng tôi phát triển các hạng mục thử nghiệm khác nhau.
Hình 11.3 minh họa sự liên kết dịch vụ giữa FR và ATM. Kết nối
dịch vụ áp dụng khi (i) một người dùng dịch vụ FR
Mạng A Mạng B
I
W
B-CPE
F
FR I ATM UNI
CPE Frame relay W
network F ATM
FR UNI B-CPE
network
I ATM UNI
FR W
CPE F
FR UNI
Upper layer Optional protocol translation Upper layer
SSCS SSCS
0.922 0.922 0.922 0.922

C C C C CPCS CPCS
O O O O
R R R R SAR SAR
E E E E
ATM ATM ATM ATM
PHY PHY PHY PHY PHY PHY PHY PHY
Hình 11.3 Sự liên kết dịch vụ giữa các dịch vụ FR và ATM.

tương tác với người sử dụng dịch vụ ATM, (ii) người sử dụng dịch
vụ ATM không thực hiện các chức năng cụ thể của chuyển tiếp
khung và (iii) người sử dụng dịch vụ chuyển tiếp khung không thực
hiện các chức năng dành riêng cho dịch vụ ATM. Thiết bị tiền đề
khách hàng băng thông rộng (B-CPE) không biết rằng một thiết bị ở
11.5 VÍ DỤ 461
xa được gắn vào mạng FR. Như trong Hình 11.3, người dùng FR gửi
lưu lượng trên PVC thông qua mạng FR tới một chức năng liên kết
(IWF), sau đó ánh xạ nó tới một ATM PVC. Địa chỉ FR PVC – ánh
xạ địa chỉ PVC PVC và các tùy chọn khác được cấu hình bởi hệ
thống quản lý mạng liên kết với IWF. Một lần nữa, IWF có thể được
mở rộng cho các mạng như được hiển thị, nhưng nó có nhiều khả
năng được tích hợp vào bộ chuyển mạch mạng ATM hoặc bộ chuyển
mạch FR. Lưu ý rằng luôn có một ATM PVC trên mỗi FR PVC trong
trường hợp kết nối mạng dịch vụ. IWF có thể được giải thích bằng
cách sử dụng mô hình ngăn xếp giao thức được mô tả trong Hình
11.3. Ngăn xếp giao thức này sử dụng lớp con hội tụ dịch vụ cụ thể
“null” (SSCS) để mô tả IWF. SSCS này cung cấp các giao diện sử
dụng các giao diện nguyên thủy tiêu chuẩn cho lõi Q.922 DL ở một
bên và tới AAL5 (lớp thích ứng ATM) CPCS (lớp con hội tụ phần
chung) ở phía bên kia trong IWF. Hình 11.4 cho thấy sự biến đổi của
FR thành tế bào ATM.
FrameFormattingandDelimiting
FR tới ATM: Khung FR được ánh xạ thành AAL5 PDU; các cờ
khung, các bit 0 được chèn vào và CRC-16 bị loại bỏ. Tiêu đề khung
Q922 bị loại bỏ và một số trường của tiêu đề được ánh xạ vào các
trường tiêu đề ô ATM.
ATM đến FR: Phân định bản tin do AAL5 cung cấp được sử dụng
để xác định ranh giới khung; chèn các bit 0, CRC-16 và cờ. Các
trường giao thức và chức năng của ATM AAL5 PDU được dịch sang
các trường giao thức và chức năng của khung FR.
DLCI — Data link connection identifier, 12 bits

DLCI C/R EA C/R — Command/response, 1 bit
0 EA — Address extension, 1 bit
DLCI FE BE DE EA FECN — Forward explicit congestion notification, 1 bit
CN CN 1 BECN — Backward explicit congestion notification, 1 bit
DE — Discard eligibility, 1 bit
0.922header Data CRC-16

2 ×8 (1-n)× 8 2 ×8
CPCS PDU PAD CPCS-UU CPI Length CRC-32

2 ×8 (0−47)× 8 1 ×8 1 ×8 1 ×8 4 ×8
SAR SDU SAR SDU SAR SDU SAR SDU

48 × 8 48 × 8 48 × 8 48 × 8
ATM header SAR SDU

5 ×8 48 × 8
GFC — Generic flow control, 4 bits

VPI — Virtual path identifier, 8 bits
GFC VPI VCI — Virtual circuit identifier, 3 bits
For user information cells :
PTI <2> is set to 0
VPI VPI
PTI <1> is EFCI
PTI <0> is user–to–user indication
CLP — Cell loss priority, 1 bit
VCI 1 = congestion experienced
0 = no congestion
HEC — Header error control, 8 bits
VCI PTI CLP
HEC
Hình 11.4 Sự chuyển đổi FR sang tế bào ATM.

DiscardEli đủ điều kiện vàCellLossPosystemMapping
FR đến ATM: Chế độ 1 hoặc chế độ 2 có thể được chọn cho mỗi
PVC tại thời điểm đăng ký; mặc định là chế độ 1 hoạt động:
Chế độ 1: Trường tính đủ điều kiện (DE) bị loại bỏ trong khung lõi
Q.922 sẽ được ánh xạ tới trường ATM CLP của mọi ô được tạo ra
bởi quá trình phân đoạn của AAL5 PDU có chứa thông tin của khung
đó.
Chế độ 2: ATM CLP của mọi ô được tạo ra bởi quá trình phân đoạn
của AAL5 PDU chứa thông tin của khung đó sẽ được đặt thành giá
trị không đổi (0 hoặc 1) được định cấu hình tại thời điểm đăng ký
dịch vụ.
11.5 VÍ DỤ 463
ATM sang FR: Chế độ 1 hoặc 2 có thể được chọn cho mỗi PVC tại
thời điểm đăng ký; mặc định là chế độ 1 hoạt động:
Chế độ 1: Nếu một hoặc nhiều ô của khung được đặt trường CLP,
IWF sẽ đặt trường DE của khung lõi Q.922.
Chế độ 2: Trường DE của khung lõi Q.922 phải được đặt thành giá
trị không đổi (0 hoặc 1) được định cấu hình tại thời điểm đăng ký
dịch vụ.
Chuyển tiếpCongestionIndicationMapping
FR đến ATM: Chế độ 1 hoặc 2 có thể được chọn cho mỗi PVC tại
thời điểm đăng ký; mặc định là chế độ 1 hoạt động:
Chế độ 1: Trường FECN (Thông báo tắc nghẽn chuyển tiếp rõ ràng)
trong khung lõi Q.922 sẽ được ánh xạ tới trường ATM EFCI (Chỉ
báo tắc nghẽn chuyển tiếp rõ ràng) của mọi ô được tạo bởi quá trình
phân đoạn của AAL5 PDU có chứa thông tin về khung.
Chế độ 2: Trường FECN trong khung lõi Q.922 sẽ không được ánh
xạ tới trường ATM EFCI của các ô được tạo ra bởi quá trình phân
đoạn của AAL5 PDU có chứa thông tin của khung đó. Trường EFCI
luôn được đặt thành "tắc nghẽn không trải qua."
ATM thành FR: Nếu trường EFCI trong ô cuối cùng của khung phân
đoạn nhận được được đặt thành “đã trải qua tắc nghẽn”, IWF sẽ đặt
khung lõi FECN thành “đã xảy ra tắc nghẽn”.
BackwardCongestionIndicationMapping
FR đến ATM: BECN (Thông báo tắc nghẽn ngược rõ ràng) bị bỏ
qua.
ATM thành FR: BECN của khung lõi Q.922 được đặt thành 0.
Command / ResponseFieldMapping
FR đến ATM: Bit C / R của khung lõi Q.922 được ánh xạ tới bit ít
quan trọng nhất trong trường con người dùng với người dùng
(CPCS_UU) của lớp CPCS PDU hội tụ phần chung.
ATM đến FR: Bit ít quan trọng nhất trong trường CPCS_UU của
CPCS PDU được ánh xạ tới bit C / R của khung lõi Q.922.
DLCIFieldMapping Có một ánh xạ 1-1 giữa Q.922
DLCI và trường VPI / VCI (Mã nhận dạng đường dẫn ảo / Mã nhận
dạng mạch ảo) trong các ô ATM. Ánh xạ được xác định khi PVC
được thành lập. Sự liên kết có thể là tùy ý hoặc có hệ thống.
số chất lượng dịch vụ (QoS) của khung chuyển tiếp quản lý lưu
lượng (CIR, B c , B e ) sẽ được ánh xạ tới các thông số ATM QoS
(PCR, SCR, MBS) bằng cách sử dụng phương pháp 1, ánh xạ 1-1 của
Diễn đàn ATM Thông số kỹ thuật B-ICI (BISDN-Inter Carrier
Interface), được đưa ra trong Bảng 11.5. Giá trị của biến kích thước
khung được sử dụng trong tính toán có thể định cấu hình cho mỗi
PVC. Cũng có thể cấu hình cho mỗi PVC sẽ là CDVT.
BẢNG 11.5 Ánh xạ các tham số FR QoS sang tham số ATM
QoS
PCR 0 + 1 = AR / 8 × [OHA (n) ]

SCR 0 = CIR / 8 × [OHB (n) ]
MBS 0 = [ B c / 8 × ( 1 / ( 1 - CIR / AR )) + 1] × [OHB (n) ]
SCR 1 = EIR / 8 × [OHB (n) ]
MBS 1 = [ B e / 8 × ( 1 / ( 1 - EIR / AR )) + 1] × [OHB (n) ] CDVT =
1 / PCR 0 + 1
trong đó n - số octet thông tin người dùng trong khung
AR - tốc độ đường truyền truy cập
CIR - tốc độ thông tin cam kết, B c / T (bit / s)
EIR - tốc độ thông tin dư thừa, B e / T (bit / s), CIR + EIR < AR
B c - kích thước cụm đã cam kết (bit)
B e - kích thước cụm vượt quá (bit)
T - khoảng thời gian đo
PCR - tốc độ tế bào đỉnh (tế bào / s)
SCR - tốc độ tế bào duy trì (tế bào / s)
MBS - kích thước cụm tối đa (số ô)
CDVT - khả năng chịu sự thay đổi độ trễ của tế bào
| X | - số nguyên nhỏ nhất lớn hơn hoặc bằng X
OHA (n) = | (n + h 1 + h 2 ) / 48 | / (n + h 1 + h 2 ) , hệ số chi phí cho
tốc độ truy cập (ô / byte) h 1 = Kích thước tiêu đề FR (octet), 2 -, tiêu
đề 3 :, hoặc 4-octet h 2 = FR HDLC kích thước trên đầu của CRC-16
và cờ (4 octet)
OHB (n) = | (n + h 1 + h 2 ) / 48 | / n , hệ số chi phí cho tốc độ cam
kết / vượt mức (ô / byte) và chỉ số con 0 + 1, 0 hoặc 1 áp dụng cho
PCR, SCR, hoặc MBS ngụ ý các giá trị tham số cho dòng ô CLP = 0
+ 1, dòng ô CLP = 0 và dòng ô CLP = 1 tương ứng
11.5 VÍ DỤ 465
Lưu ý: Phương pháp này đặc trưng cho lưu lượng FR bằng cách sử
dụng ba thuật toán tốc độ ô chung (GCRA) được mô tả trong Phụ lục
B của đặc tả ATM Diễn đàn UNI, 1993. Các khung có n byte giao
diện người dùng.
PVCMapping
FR tới ATM: Khi IWF được thông báo rằng FR PVC thay đổi trạng
thái từ hoạt động sang không hoạt động, nó sẽ bắt đầu gửi các ô AIS
(Tín hiệu báo động) F5 OAM (Vận hành, Quản trị và Quản lý) trên
ATM PVC tương ứng. Một ô AIS F5 OAM được gửi một lần mỗi
giây cho đến khi trạng thái của PVC chuyển từ không hoạt động sang
hoạt động.
ATM thành FR: Khi IWF được thông báo rằng ATM PVC thay đổi
trạng thái từ hoạt động sang không hoạt động, nó sẽ đặt bit trạng thái
FR PVC thành không hoạt động. Lưu ý: ATM PVC được coi là
không hoạt động nếu (i) AIS hoặc RDI (Chỉ báo lỗi từ xa) nhận được
ô OAM hoặc (ii) biến MIB ILMI (Giao diện quản lý cục bộ tạm thời)
atmVccOperStatus là localDown hoặc end2endDown hoặc (iii) ATM
giao diện bị sập. ATM phản hồi các ô AIS đã nhận bằng cách gửi các
ô RDI.
UpperLayerUserProtocolEncapsulation Nhà cung cấp mạng có thể
định cấu hình một trong hai chế độ hoạt động sau cho từng cặp PVC
FR và ATM có thể tương tác liên quan đến việc đóng gói giao thức
trên:
Chế độ 1 - chế độ trong suốt: Các phương pháp đóng gói lớp trên sẽ
không được ánh xạ giữa các tiêu chuẩn ATM và FR.
Chế độ 2 — chế độ dịch: Các phương pháp đóng gói để mang nhiều
giao thức người dùng lớp trên (ví dụ: LAN sang LAN) qua FR PVC
và ATM PVC tương ứng với tiêu chuẩn RFC 1490 [19] và RFC 1483
[20]. IWF sẽ thực hiện ánh xạ giữa hai gói do sự không tương thích
của hai phương pháp. Chế độ này hỗ trợ sự liên kết của giao thức kết
nối internet (định tuyến và / hoặc bắc cầu).
FragmentationandReassembly
FR đến ATM: Khi IWF nhận các gói phân mảnh trên FR PVC, việc
lắp ráp lại phải được thực hiện trong khi chuyển tiếp khung đã lắp
ráp tới ATM PVC.
ATM sang FR: Phân mảnh phải được thực hiện trên CPCS PDU đã
nhận trước khi chuyển tiếp chúng tới FR PVC nếu CPCS PDU lớn
hơn kích thước khung tối đa được hỗ trợ trên FR PVC.
Hạng mục Thử nghiệm liên kết dịch vụ FR-ATM PVC Yêu cầu
liên kết dịch vụ FR-ATM PVC được chia thành sáu loại chính: (i)
chức năng, (ii) độ bền, (iii) hiệu suất, (iv) ứng suất, (v) tải và độ ổn
định, và (vi) hồi quy. Cấu trúc hoàn chỉnh của các hạng mục thử
nghiệm được cho trong Hình 11.5.
chức năng Kiểm tra chức năng được thiết kế để xác minh phần mềm
FrAtm một cách kỹ lưỡng nhất có thể đối với tất cả các yêu cầu được
chỉ định trong tài liệu FRF.8. Danh mục này đã được chia nhỏ hơn
nữa thành sáu phân nhóm chức năng khác nhau. Đối với mỗi phân
nhóm chức năng đã xác định, các mục tiêu kiểm tra được hình thành
để thực hiện đầy đủ chức năng. Trong mỗi mục tiêu thử nghiệm
nhóm con được thiết kế để bao hàm các giá trị hợp lệ. Các chức năng
chính sau đây của tính năng FrAtm phải được kiểm tra đầy đủ: (1)
kiểm tra cấu hình và giám sát, (2) kiểm tra quản lý lưu lượng, (3)
kiểm tra tắc nghẽn, (4) chức năng liên kết dịch vụ (SIWF) kiểm tra
ánh xạ chế độ dịch, (5 ) kiểm tra cảnh báo và (6) kiểm tra giao diện:
Kiểm tra cấu hình và giám sát: Kiểm tra được thiết kế để xác minh
tất cả các thuộc tính có thể cấu hình của thành phần FrAtm bằng cách
sử dụng lệnh CLI. Các thuộc tính có thể định cấu hình này phụ thuộc
vào việc triển khai và cần được xác định trong đặc tả chức năng.
Kiểm tra cấu hình cấu hình FrAtm bằng CLI. Các bài kiểm tra giám
sát xác minh khả năng sử dụng CLI để xác định trạng thái và hoạt
động của FrAtm. Bộ đếm thống kê được xác nhận về độ chính xác
bằng cách sử dụng số lượng lưu lượng truy cập đã biết.
Kiểm tra quản lý lưu lượng: Kiểm tra được thiết kế để xác minh ánh
xạ giữa các tham số lưu lượng ATM PCR 0 + 1 , SCR 0 + 1 và các
tham số thực thi tốc độ MBS và FR CIR, B c và B e . Việc lập bản đồ
giữa các tham số này phải được xem xét kỹ thuật và phần lớn phụ
thuộc vào sự cân bằng giữa xác suất tổn thất có thể chấp nhận được
và chi phí mạng.
11.5 VÍ DỤ 467
Configuration and
monitoring tests
Traffic management
tests
Congestion tests
SIWF translation
Functionality tests
mode mapping tests
Robustness tests Alarm tests
Performance tests Interface tests

FR–ATM test suite
Stress tests
Load and stability

tests
Regression tests
Hình 11.5 Cấu trúc bộ thử nghiệm FrAtm.

Kiểm tra tắc nghẽn: Các kiểm tra khác nhau được thiết kế để xác
minh mức độ của cơ chế kiểm soát tắc nghẽn FrAtm. Các mục tiêu
kiểm tra của mỗi bài kiểm tra như sau:
Xác minh rằng tốc độ tối đa dài hạn cho cụm đã cam kết là CIR.
Xác minh rằng tốc độ tối đa dài hạn cho cụm vượt quá là EIR.
Xác minh rằng các khung DE = 0 và DE = 1 tương ứng được tính
vào số lượng liên tục đã cam kết và số lượng vượt quá.
Xác minh rằng FrAtm đặt bit BECN trên FrAtm để báo hiệu tắc
nghẽn cục bộ cho người dùng FR.
Thử nghiệm ánh xạ chế độ dịch chức năng liên kết dịch vụ: Các thử
nghiệm được thiết kế để xác minh ánh xạ chế độ dịch SIWF từ FR
sang ATM và ngược lại với các mục tiêu sau:
Xác minh rằng đối với các khung từ FR đến ATM, IWF thay thế
đóng gói RFC 1490 bằng tiêu đề đóng gói RFC 1483. • Xác minh
rằng đối với các khung từ ATM đến FR, IWF thay thế đóng gói RFC
1483 bằng tiêu đề đóng gói RFC 1490.
Theo hướng FR-to-ATM, hãy xác minh rằng bit FECN trên một
khung nhất định ánh xạ trực tiếp vào bit EFCI của mọi ô tạo thành
khung nếu thuộc tính EFCI được định cấu hình là “bảo tồn”; nếu
không, bit EFCI của mọi ô được tạo được đặt thành 0.
Theo hướng ATM-to-FR, xác minh rằng bit EFCI của ô cuối cùng
cấu thành một khung nhất định được ánh xạ trực tiếp vào bit FECN
của khung đó.
Theo hướng FR-to-ATM, xác minh rằng bit DE của một khung nhất
định ánh xạ trực tiếp vào bit CLP của mọi ô tạo thành khung đó nếu
được định cấu hình.
Theo hướng ATM-to-FR, hãy xác minh rằng ánh xạ CLP-tới-DE có
thể được định cấu hình với các giá trị “giữ nguyên”, “luôn là 0” và
“luôn là 1”. • Theo hướng FR-to-ATM, xác minh rằng bit lệnh / phản
hồi (C / R) của khung FR được ánh xạ trực tiếp tới bit dữ liệu UU ít
quan trọng nhất trong CPCS của đóng gói AAL5.
Theo hướng ATM-to-FR, xác minh rằng bit ít quan trọng nhất của dữ
liệu UU trong CPCS được ánh xạ trực tiếp đến bit C / R của khung
FR cấu thành.
Theo hướng FR-to-ATM, xác minh rằng IWF sẽ gửi các ô AIS F5
OAM trên ATM PVC khi FR PVC thay đổi trạng thái từ hoạt động
sang không hoạt động. Ngoài ra, hãy xác minh rằng các ô OAM được
gửi một lần mỗi giây cho đến khi trạng thái của PVC chuyển từ
không hoạt động sang hoạt động.
Theo hướng ATM-to-FR, xác minh rằng IWF sẽ đặt bit trạng thái FR
PVC thành không hoạt động khi ATM PVC thay đổi trạng thái từ
hoạt động sang không hoạt động. Xác minh rằng các ô RDI được gửi
tương ứng với các ô AIS đã nhận.
Theo hướng FR-to-ATM, xác minh rằng IWF tập hợp lại các gói bị
phân mảnh đã nhận được trên FR PVC và chuyển tiếp nó đến ATM
PVC.
Theo hướng ATM-to-FR, xác minh rằng ID phân mảnh được thực
hiện bởi IWF trên CPCS PDU đã nhận trước khi chuyển tiếp chúng
đến FR PVC. Đảm bảo rằng kích thước CPCS PDU lớn hơn kích
thước khung tối đa được hỗ trợ trên FR PVC.
Kiểm tra cảnh báo: Kiểm tra được thiết kế để đảm bảo rằng các cảnh
báo khác nhau được tạo ra cho dịch vụ FR-ATM. Các mục tiêu thử
nghiệm của mỗi thử nghiệm như sau: • Xác minh rằng FrAtm tạo ra
các cảnh báo thích hợp trên mỗi PVC cho DLCI riêng lẻ.
11.5 VÍ DỤ 469
Xác minh rằng FrAtm tạo ra các cảnh báo thông báo thay đổi trạng
thái (SCN) khi trạng thái hoạt động thay đổi. Sự thay đổi trạng thái
có thể xảy ra khi liên kết đi lên hoặc đi xuống. Sự thay đổi trạng thái
cũng có thể xảy ra bằng cách khóa và mở khóa FrAtm.
Xác minh rằng FrAtm tạo ra các cảnh báo để cho biết việc nhận được
các tin nhắn không mong muốn.
Xác minh rằng các cảnh báo được tạo ra để chỉ ra lỗi không thể phân
bổ bộ nhớ để tạo dịch vụ hoặc tạo các thành phần con như DLCI.
6. Kiểm tra giao diện: Xác minh rằng FrAtm hỗ trợ V.11, V35, DS1,
E1, DS3 và E3 ở phía FR và giao diện OC3, E3 và DS3 ở phía ATM.
RobustnessTests One xác minh tính mạnh mẽ của việc triển khai
FrAtm đối với các tình huống lỗi:
Kiểm tra FrAtm: Xác minh rằng (i) thành phần phần mềm FrAtm có
thể xử lý khóa / mở khóa liên tục mà không gặp bất kỳ sự cố nào, (ii)
thành phần phần mềm DLCI có thể xử lý nhiều lệnh khóa / mở khóa
được tạo ở tốc độ cao và (iii) thành phần phần mềm DLCI có thể xử
lý khóa / mở khóa trong khi giao thông đang đi qua nút chuyển mà
không có bất kỳ sự cố nào.
Kiểm tra giá trị ranh giới: Xác minh rằng FrAtm xử lý các giá trị
ranh giới và giá trị bên dưới và các giá trị bên trên đường biên hợp lệ
cho một tập hợp con các thuộc tính có thể định cấu hình. Ví dụ: nếu
số lượng tối đa DLCI có thể định cấu hình là 1024, thì hãy thử định
cấu hình 1025 thành phần con DLCI và xác minh rằng thành phần
con DLCI thứ 1025 không được tạo.
Hiệu suất Các bài kiểm tra được thiết kế để đo độ trễ và thông lượng
dữ liệu trên các giao diện khác nhau trên cả FR và ATM. Các thử
nghiệm được tiến hành để đo độ trễ và thông lượng trên toàn bộ các
thẻ giao diện ATM và thẻ giao diện FR cho các kích thước khung
hình 64, 128, 256, 512, 1024, 2048 và 4096 byte.
StressT Kiểm tra được thiết kế để quan sát và nắm bắt hành vi của
các dịch vụ FR-ATM dưới nhiều loại cấu hình tải khác nhau. Các
mục tiêu kiểm tra của mỗi bài kiểm tra như sau:
Xác minh rằng FrAtm hoạt động mà không gặp trục trặc nào khi nó
bị căng thẳng trong 48 giờ trở lên trong khi các hoạt động khóa / mở
khóa và hoạt động truyền dữ liệu đang diễn ra.
Xác minh rằng FrAtm hoạt động mà không gặp trục trặc khi số lượng
DLCI tối đa ở phía FR sử dụng một thẻ FR và số lượng tối đa ATM
VCC (Kết nối kênh ảo) được định cấu hình.
LoadandStabilityTests Các bài kiểm tra được thiết kế để mô phỏng
cấu hình khách hàng thực bằng cách gửi lưu lượng dữ liệu thực. Đối
với những thử nghiệm này, việc thiết lập môi trường khách hàng
trong phòng thí nghiệm là một thách thức và tốn kém. Một ví dụ của
thử nghiệm này là xác minh rằng một tệp người dùng có thể được
chuyển đúng cách từ mạng FR sang mạng ATM bằng cách sử dụng
tính năng liên kết dịch vụ FR-ATM PVC.
RegressionTests Các trường hợp thử nghiệm mới không được thiết
kế; thay vào đó, các bài kiểm tra được chọn từ các nhóm đã giải thích
trước đó. Theo ý kiến của chúng tôi, một tập hợp con các trường hợp
kiểm thử từ mỗi nhóm con có thể được chọn làm kiểm thử hồi quy.
Ngoài ra, các trường hợp kiểm thử từ FR và ATM phải được chọn và
thực thi để đảm bảo rằng chức năng được hỗ trợ trước đó hoạt động
với thành phần phần mềm mới FrAtm.
471
11.6 LẬP MÔ HÌNH QUÁ TRÌNH THIẾT KẾ THỬ NGHIỆM
Deleted Deprecated
Create Draft Review Released
Update
Hình 11.6 Biểu đồ chuyển đổi trạng thái của một ca kiểm thử.
11.6 MÔ HÌNH HÓA QUY TRÌNH THIẾT KẾ THỬ NGHIỆM
Các mục tiêu thử nghiệm được xác định từ một đặc tả yêu cầu và một
trường hợp thử nghiệm được tạo cho mỗi mục tiêu thử nghiệm. Mỗi
trường hợp thử nghiệm được thiết kế như một sự kết hợp của các
thành phần mô-đun được gọi là các bước thử nghiệm. Các trường
hợp kiểm thử được quy định rõ ràng để người kiểm thử có thể nhanh
chóng hiểu, mượn và sử dụng lại các trường hợp kiểm thử.
Hình 11.6 minh họa mô hình vòng đời của một ca kiểm thử dưới
dạng biểu đồ chuyển đổi trạng thái. Mô hình chuyển đổi trạng thái
hiển thị các giai đoạn hoặc trạng thái khác nhau trong vòng đời của
một ca kiểm thử từ khi bắt đầu đến khi hoàn thành thông qua các
trạng thái sau: tạo, soạn thảo, xem xét, xóa, phát hành, cập nhật và
không dùng nữa. Một số hành động nhất định được thực hiện bởi
"chủ sở hữu" của trạng thái và trường hợp thử nghiệm chuyển sang
trạng thái tiếp theo sau khi hoàn thành các hành động. Sau đây, các
trạng thái được giải thích từng cái một. Người ta có thể dễ dàng triển
khai một cơ sở dữ liệu các trường hợp thử nghiệm bằng cách sử dụng
lược đồ trường hợp thử nghiệm được hiển thị trong Bảng 11.6.
Chúng tôi đề cập đến cơ sở dữ liệu các trường hợp thử nghiệm như
một nhà máy thử nghiệm.
CreateState Một trường hợp thử nghiệm được đặt ở trạng thái ban
đầu này bởi người tạo ra nó, được gọi là chủ sở hữu hoặc người tạo,
người bắt đầu thiết kế trường hợp thử nghiệm. Người tạo khởi tạo
các trường bắt buộc sau được liên kết với trường hợp thử nghiệm:
request_ids, tc_id, tc_title, origintor_group, Creator và test_category.

Trường hợp thử nghiệm được mong đợi để xác minh các yêu cầu
được đề cập đến trong trường request_ids. Nhóm khởi tạo là nhóm
nhận thấy cần phải kiểm tra. Người tạo có thể chỉ định trường hợp
thử nghiệm cho một kỹ sư thử nghiệm cụ thể, bao gồm cả chính anh
ta, bằng cách điền vào trường eng_assigned và chuyển trường hợp
thử nghiệm từ trạng thái tạo sang trạng thái nháp.
DraftState Chủ sở hữu của trạng thái này là nhóm kiểm tra, tức là
nhóm kiểm tra hệ thống. Ở trạng thái này, kỹ sư kiểm tra được chỉ
định nhập các thông tin sau: tc_author, mục tiêu, thiết lập, test_steps,
cleanup, pf_criteria, application_for_automation,
Automation_prinsive. Sau khi hoàn thành tất cả các trường bắt buộc,
kỹ sư kiểm thử có thể chỉ định lại trường hợp thử nghiệm cho người
tạo để thực hiện qua trường hợp thử nghiệm. Các
BẢNG 11.6 Tóm tắt lược đồ trường hợp thử nghiệm
Đồng ruộng Sự mô tả
tc_id Mã định danh trường hợp thử nghiệm
do tác giả thử nghiệm chỉ định (80 ký
tự)
tc_title Tiêu đề của trường hợp thử nghiệm
(120 ký tự)
người sáng tạo Tên của người đã tạo trường hợp thử
nghiệm
trạng thái Trạng thái hiện tại của bản ghi: tạo,
bản nháp, xem xét, phát hành, cập
nhật, xóa và không dùng nữa
chủ nhân Chủ sở hữu hiện tại của trường hợp
thử nghiệm
eng_assigned Kỹ sư kiểm tra được giao viết quy
trình kiểm tra
khách quan Mục tiêu của trường hợp thử nghiệm
(chuỗi nhiều dòng)
tc_author Tên tác giả trường hợp thử nghiệm
(tên người dùng)
origintor_group Nhóm khởi tạo thử nghiệm (nhóm thử
473
nghiệm hiệu suất, nhóm thử nghiệm
chức năng, nhóm thử nghiệm mở rộng,
v.v.)
test_category Tên danh mục kiểm tra (hiệu suất,
căng thẳng, khả năng tương tác, chức
năng, v.v.)
thành lập Danh sách các bước cần thực hiện
trước khi kiểm tra
bước kiểm tra Danh sách các bước kiểm tra
dọn dẹp Danh sách các hoạt động posttest
pf_criteria Danh sách các tiêu chí đạt / không đạt
request_ids Danh sách các tham chiếu đến ID yêu
cầu từ cơ sở dữ liệu yêu cầu
application_for_automation Nếu thử nghiệm có thể được / nên
được tự động hóa
tự động hóa Ưu tiên tự động hóa.
review_action Các mục hành động từ biên bản cuộc
họp đánh giá
Approver_names Danh sách tên người phê duyệt
trường hợp thử nghiệm vẫn ở trạng thái này cho đến khi người tạo xử
lý. Sau đó, người tạo có thể chuyển trạng thái từ trạng thái dự thảo
sang trạng thái xem xét bằng cách nhập tên của tất cả những người
phê duyệt vào trường Approver_names.
ReviewandDeletedStates Chủ sở hữu của trạng thái xem xét là người
tạo trường hợp thử nghiệm. Chủ sở hữu mời các kỹ sư và nhà phát
triển thử nghiệm để xem xét và xác thực trường hợp thử nghiệm.
Chúng đảm bảo rằng trường hợp thử nghiệm có thể thực thi được và
các tiêu chí đạt - không đạt được chỉ định rõ ràng. Các mục hành
động được tạo cho trường hợp thử nghiệm nếu bất kỳ trường nào cần
sửa đổi. Các mục hành động từ cuộc họp đánh giá được nhập vào
trường review_actions và các mục hành động được chủ sở hữu thực
thi để thực hiện các thay đổi đối với trường hợp thử nghiệm. Trường
hợp thử nghiệm chuyển sang trạng thái đã phát hành sau khi tất cả
những người đánh giá phê duyệt các thay đổi. Nếu những người đánh
giá quyết định rằng đây không phải là một trường hợp kiểm thử hợp
lệ hoặc nó không thể thực thi được, thì trường hợp kiểm thử đó sẽ
được chuyển sang trạng thái đã xóa. Mục hành động xem xét phải
yêu cầu xóa trường hợp thử nghiệm này để xóa trường hợp thử
nghiệm.
ReleasedandUpdateStates Một trường hợp thử nghiệm ở trạng thái đã
phát hành đã sẵn sàng để thực thi và nó trở thành một phần của bộ
thử nghiệm. Mặt khác, trường hợp thử nghiệm ở trạng thái cập nhật
ngụ ý rằng nó đang trong quá trình được sửa đổi thành
11.7 KẾT QUẢ KIỂM TRA MÔ HÌNH
nâng cao khả năng tái sử dụng của nó, được tinh chỉnh theo tiêu chí
đạt - không đạt và / hoặc đã sửa quy trình kiểm tra chi tiết. Ví dụ,
một trường hợp thử nghiệm có thể sử dụng lại nên được tham số hóa
thay vì được mã hóa cứng bằng các giá trị dữ liệu. Hơn nữa, một
trường hợp thử nghiệm nên được cập nhật để thích ứng với những
thay đổi về chức năng hệ thống hoặc môi trường. Người ta có thể cải
thiện khả năng lặp lại của trường hợp thử nghiệm để những người
khác có thể nhanh chóng hiểu, mượn và sử dụng lại nó bằng cách di
chuyển một trường hợp thử nghiệm trong vòng lặp cập nhật đã phát
hành một số ít lần. Ngoài ra, điều này cung cấp nền tảng và lý do cho
trường hợp thử nghiệm được tự động hóa. Một trường hợp thử
nghiệm phải độc lập với nền tảng. Nếu bản cập nhật liên quan đến
một thay đổi nhỏ, kỹ sư thử nghiệm có thể chuyển trường hợp thử
nghiệm trở lại trạng thái đã phát hành sau khi sửa chữa. Nếu không,
trường hợp thử nghiệm phải được xem xét thêm, điều này đạt được
bằng cách chuyển nó sang trạng thái xem xét. Một trường hợp thử
nghiệm có thể được sửa đổi một lần mỗi khi nó được thực thi.
DeprecatedState Một trường hợp thử nghiệm lỗi thời có thể được
chuyển sang trạng thái không dùng nữa. Tốt nhất, nếu nó đã không
được thực thi trong một năm, thì trường hợp thử nghiệm nên được
xem xét lại để tiếp tục tồn tại. Một trường hợp thử nghiệm có thể trở
nên lỗi thời theo thời gian vì những lý do sau. Đầu tiên, chức năng
của hệ thống đang được thử nghiệm đã thay đổi nhiều và do thiếu
bảo trì trường hợp thử nghiệm, trường hợp thử nghiệm trở nên lỗi
thời. Thứ hai, khi một trường hợp thử nghiệm cũ được cập nhật, một
số yêu cầu của trường hợp thử nghiệm ban đầu có thể không còn
được đáp ứng. Thứ ba, khả năng tái sử dụng của các trường hợp thử
nghiệm có xu hướng giảm dần theo thời gian khi tình hình thay đổi.
475
Điều này đặc biệt đúng với các trường hợp thử nghiệm không được
thiết kế với sự chú ý thích hợp để có thể tái sử dụng. Cuối cùng, các
trường hợp thử nghiệm có thể được chuyển tiếp một cách bất cẩn rất
lâu sau khi lý do ban đầu của chúng đã biến mất. Không ai có thể biết
lý do ban đầu cho một trường hợp thử nghiệm cụ thể, vì vậy nó tiếp
tục được sử dụng.
11.7 KẾT QUẢ KIỂM TRA MÔ HÌNH
Người quản lý thử nghiệm có thể sử dụng một lược đồ bộ thử nghiệm
để thiết kế một bộ thử nghiệm sau khi nhà máy thử nghiệm được tạo.
Một lược đồ bộ thử nghiệm, như được hiển thị trong Bảng 11.7, được
sử dụng để nhóm các trường hợp thử nghiệm để kiểm tra một bản
phát hành cụ thể. Lược đồ yêu cầu ID bộ thử nghiệm, tiêu đề, mục
tiêu và danh sách các trường hợp thử nghiệm được bộ thử nghiệm
quản lý. Người ta cũng xác định các trường hợp thử nghiệm riêng lẻ
sẽ được thực hiện (các chu kỳ thử nghiệm 1, 2, 3 và / hoặc hồi quy)
và các yêu cầu mà các trường hợp thử nghiệm thỏa mãn. Ý tưởng ở
đây là tập hợp một số trường hợp thử nghiệm đã phát hành được
chọn và đóng gói lại chúng để tạo thành một bộ thử nghiệm cho một
dự án mới.
Các kỹ sư thử nghiệm đồng thời thực hiện các trường hợp thử
nghiệm từ một bộ thử nghiệm đã chọn trên các giường thử nghiệm
khác nhau. Kết quả của việc thực hiện các trường hợp thử nghiệm đó
được ghi lại trong cơ sở dữ liệu của nhà máy thử nghiệm để thu thập
và phân tích các số liệu thử nghiệm. Trong một hệ thống lớn, phức
tạp với nhiều khiếm khuyết, có một số khả năng dẫn đến kết quả của
việc thực thi kiểm tra, không đơn thuần là đạt hoặc không đạt. Do đó,
chúng tôi mô hình hóa kết quả thực hiện kiểm tra bằng cách sử dụng
biểu đồ chuyển trạng thái như trong Hình 11.7, và lược đồ tương ứng
được cho trong Bảng 11.8. Hình 11.7 minh họa một biểu đồ trạng
thái của kết quả trường hợp thử nghiệm bắt đầu từ trạng thái chưa
được kiểm tra đến bốn trạng thái khác nhau: đạt, không thành công,
bị chặn và không hợp lệ.
BẢNG 11.7 Tóm tắt lược đồ bộ thử nghiệm
test_suite_id Giá trị nhận dạng duy nhất được chỉ định
bởi người khởi tạo

test_suite_title Tiêu đề bộ thử nghiệm, tiêu đề một dòng
cho bộ thử nghiệm
test_suite_objective Mục tiêu của bộ thử nghiệm, mô tả ngắn
gọn.
bài kiểm tra Danh sách tham chiếu các số nhận dạng
trường hợp thử nghiệm
test_id ID trường hợp thử nghiệm, đã chọn
test_title Tiêu đề trường hợp thử nghiệm, chỉ đọc,
được điền khi trường hợp thử nghiệm được
tạo
test_category Tên danh mục (hiệu suất, căng thẳng, khả
năng tương tác, chức năng, v.v.)
kiểm thử Kỹ sư chịu trách nhiệm kiểm tra
sw_dev Nhà phát triển phần mềm chịu trách nhiệm
về trường hợp thử nghiệm này, người sẽ
hỗ trợ kỹ sư thử nghiệm trong việc thực
hiện trường hợp thử nghiệm
quyền ưu tiên Mức độ ưu tiên của trường hợp thử
nghiệm
request_ids Mã định danh yêu cầu, chỉ đọc, được điền
khi trường hợp thử nghiệm được tạo
chu kỳ 1–3 Hộp kiểm để cho biết kiểm tra là trường
hợp kiểm tra chu kỳ 1, 2 hoặc 3
hồi quy Hộp kiểm để cho biết kiểm tra là trường
hợp kiểm tra hồi quy
BẢNG 11.8 Tóm tắt giản đồ kết quả thử nghiệm
tc_id Tham chiếu đến bản ghi nhận dạng trường
hợp thử nghiệm
test_title Tiêu đề trường hợp thử nghiệm, chỉ đọc,
được điền khi kết quả được tạo
test_category Tên danh mục kiểm tra (hiệu suất, căng
thẳng, khả năng tương tác, chức năng, v.v.)
477
trạng thái Trạng thái của kết quả trường hợp thử
nghiệm: đạt, không thành công, bị chặn,
không hợp lệ hoặc chưa được kiểm tra;
trạng thái ban đầu của trường hợp thử
nghiệm là "chưa được kiểm tra"
ngày chạy Ngày chạy trường hợp kiểm tra
thời gian Thời gian dành cho việc thực thi trường
hợp thử nghiệm
kiểm thử Tên người đã chạy thử nghiệm
phóng thích Phát hành phần mềm (03.00.00)
xây dựng Số tích hợp phần mềm (1–100).
khiếm khuyết Danh sách các khuyết tật làm cho thử
nghiệm không đạt; giá trị có thể đến từ cơ
sở dữ liệu theo dõi lỗi
test_suite Bộ thử nghiệm kết quả này liên quan đến
Trạng thái thực thi của một ca kiểm thử được đặt ở trạng thái ban đầu
chưa được kiểm tra sau khi thiết kế hoặc chọn một ca kiểm thử. Nếu
trường hợp thử nghiệm không hợp lệ cho bản phát hành phần mềm
hiện tại, kết quả trường hợp thử nghiệm sẽ được chuyển sang trạng
thái không hợp lệ. Ở trạng thái chưa được kiểm tra, mã định danh bộ
thử nghiệm được ghi chú trong một trường có tên là test_suite_id.
Trạng thái của kết quả thử nghiệm, sau khi bắt đầu thực thi một
trường hợp thử nghiệm, có thể thay đổi thành một trong các trạng
thái sau:
11.8 PHƯƠNG PHÁP CHUẨN BỊ THIẾT KẾ THỬ NGHIỆM
Passed
Untested Failed
Blocked
Invalid Figure11.7 Statetransitiondiagramoftest

caseresult.
đã vượt qua, không thành công, không hợp lệ hoặc bị chặn. Kỹ sư
kiểm thử có thể chuyển kết quả trường hợp thử nghiệm sang trạng
thái đã thông qua từ trạng thái chưa được kiểm tra nếu quá trình thực
hiện trường hợp thử nghiệm hoàn tất và đáp ứng các tiêu chí vượt
qua.
Nếu quá trình thực thi kiểm tra hoàn tất và đáp ứng các tiêu chí
không đạt, kỹ sư kiểm tra sẽ chuyển kết quả kiểm tra sang trạng thái
không thành công từ trạng thái chưa được kiểm tra và kết hợp lỗi với
trường hợp kiểm thử bằng cách khởi tạo trường lỗi_ids. Trường hợp
kiểm thử phải được thực thi lại khi nhận được bản dựng mới chứa
bản sửa lỗi. Nếu quá trình thực thi lại hoàn tất và đáp ứng các tiêu chí
vượt qua, kết quả kiểm tra sẽ được chuyển sang trạng thái đã vượt
qua.
Kết quả trường hợp thử nghiệm được chuyển sang trạng thái bị chặn
nếu không thể thực thi nó hoàn toàn. Nếu biết, số lỗi chặn việc thực
thi trường hợp kiểm thử được ghi lại trong trường lỗi_ids. Trường
hợp thử nghiệm có thể được thực thi lại khi nhận được bản dựng mới
giải quyết trường hợp thử nghiệm bị chặn. Nếu quá trình thực hiện
hoàn tất và đáp ứng các tiêu chí vượt qua, kết quả kiểm tra sẽ được
chuyển sang trạng thái đạt. Ngược lại, nếu nó đáp ứng các tiêu chí
không đạt, kết quả thử nghiệm được chuyển sang trạng thái không
đạt. Nếu việc thực thi không thành công do lỗi chặn mới, kết quả
kiểm tra vẫn ở trạng thái bị chặn và lỗi mới đã chặn trường hợp kiểm
tra được liệt kê trong trường lỗi_ids.
479
11.8 PHƯƠNG PHÁP CHUẨN BỊ THIẾT KẾ THỬ
NGHIỆM
Ban quản lý có thể muốn biết tiến độ, phạm vi và các khía cạnh năng
suất của công việc chuẩn bị trường hợp thử nghiệm đang được thực
hiện bởi một nhóm kỹ sư thử nghiệm. Những thông tin này cho phép
họ (i) biết liệu một dự án thử nghiệm có đang tiến triển theo đúng
tiến độ hay không và nếu cần nhiều nguồn lực hơn và (ii) lập kế
hoạch cho dự án tiếp theo của họ một cách chính xác hơn. Các số liệu
sau đây có thể được sử dụng để thể hiện mức độ sẵn sàng của thiết kế
thử nghiệm.
Trạng thái chuẩn bị của các trường hợp thử nghiệm (PST): Một
trường hợp thử nghiệm có thể trải qua một số giai đoạn hoặc trạng
thái, chẳng hạn như bản nháp và xem xét, trước khi nó được phát
hành như một trường hợp thử nghiệm hợp lệ và hữu ích. Do đó, rất
hữu ích để theo dõi định kỳ tiến trình thiết kế thử nghiệm bằng cách
đếm các trường hợp thử nghiệm nằm ở các trạng thái thiết kế khác
nhau — tạo, soạn thảo, xem xét, phát hành và xóa. Dự kiến rằng tất
cả các trường hợp thử nghiệm đã lên kế hoạch được tạo cho một dự
án cụ thể cuối cùng sẽ chuyển sang trạng thái đã phát hành trước khi
bắt đầu thực hiện thử nghiệm.
Thời gian sử dụng trung bình (ATS) trong thiết kế trường hợp thử
nghiệm: Sẽ rất hữu ích khi biết lượng thời gian cần thiết để một
trường hợp thử nghiệm chuyển từ khái niệm ban đầu, tức là tạo trạng
thái, đến khi nó được coi là có thể sử dụng được, tức là , trạng thái đã
phát hành. Số liệu này hữu ích trong việc phân bổ thời gian cho hoạt
động chuẩn bị thử nghiệm trong một dự án thử nghiệm tiếp theo. Do
đó, nó rất hữu ích trong việc lập kế hoạch kiểm tra.
Số lượng trường hợp kiểm thử có sẵn (NAT): Đây là số lượng trường
hợp kiểm thử ở trạng thái đã phát hành từ các dự án hiện có. Một số
trường hợp kiểm thử này được chọn để kiểm thử hồi quy trong dự án
kiểm thử hiện tại.
Số trường hợp kiểm thử theo kế hoạch (NPT): Đây là số trường hợp
kiểm thử nằm trong bộ kiểm thử và sẵn sàng thực hiện khi bắt đầu
kiểm tra hệ thống. Số liệu này hữu ích trong việc lập lịch thực hiện
kiểm tra. Khi quá trình thử nghiệm tiếp tục, các trường hợp thử
nghiệm mới, không có kế hoạch có thể được yêu cầu thiết kế. Một số
lượng lớn các trường hợp thử nghiệm mới so với NPT cho thấy việc
lập kế hoạch ban đầu không chính xác.
Mức độ phù hợp của Bộ thử nghiệm (CTS): Chỉ số này cung cấp
phần nhỏ của tất cả các yêu cầu được bao gồm trong một số trường
hợp thử nghiệm được chọn hoặc một bộ thử nghiệm hoàn chỉnh. CTS
là thước đo số lượng các trường hợp thử nghiệm cần thiết để được
lựa chọn hoặc thiết kế để có khả năng đáp ứng tốt các yêu cầu của hệ
thống.
11.9 HIỆU QUẢ THIẾT KẾ TRƯỜNG HỢP KIỂM TRA
Mục tiêu của thước đo hiệu quả thiết kế trường hợp thử nghiệm là (i)
đo lường “khả năng bộc lộ khiếm khuyết” của bộ thử nghiệm và (ii)
sử dụng thước đo này để cải thiện quy trình thiết kế thử nghiệm.
Trong quá trình kiểm tra mức hệ thống, các khiếm khuyết được phát
hiện do việc thực hiện các trường hợp kiểm thử theo kế hoạch. Ngoài
các khiếm khuyết này, các khiếm khuyết mới được tìm thấy trong
quá trình thử nghiệm mà không có trường hợp thử nghiệm nào được
lên kế hoạch. Đối với những khiếm khuyết mới này, các trường hợp
thử nghiệm mới được thiết kế, được gọi là trường hợp thử nghiệm đã
thoát (TCE). Việc thoát thử nghiệm xảy ra do thiếu sót trong quá
trình thiết kế thử nghiệm. Điều này xảy ra bởi vì các kỹ sư thử
nghiệm có được những ý tưởng mới trong khi thực hiện các trường
hợp thử nghiệm theo kế hoạch. Một số liệu thường được sử dụng
trong ngành để đo lường hiệu quả thiết kế trường hợp thử nghiệm là
năng suất thiết kế trường hợp thử nghiệm (TCDY), được định nghĩa
là
NPT
TCDY = × 100%
NPT + số TCE
TCDY cũng được sử dụng để đo lường hiệu quả của một giai đoạn
thử nghiệm cụ thể. Ví dụ, người quản lý tích hợp hệ thống có thể
muốn biết giá trị TCDY để kiểm tra tích hợp hệ thống của mình.
11.11 TỔNG QUAN TÀI LIỆU
11.10 TÓM TẮT
Chương này bắt đầu với phần giới thiệu về sáu yếu tố được xem xét
trong quá trình thiết kế các trường hợp thử nghiệm: số liệu về phạm
481
vi, hiệu quả, năng suất, xác nhận, bảo trì và kỹ năng của người dùng.
Sau đó, chúng tôi thảo luận các lý do để xem xét các yếu tố này trong
việc thiết kế các bài kiểm tra hệ thống.
Tiếp theo, chúng ta đã thảo luận về quá trình xác định yêu cầu.
Chúng tôi đã cung cấp một mô hình chuyển đổi trạng thái để theo dõi
các yêu cầu cá nhân khi chúng chảy qua tổ chức. Tại mỗi trạng thái
của mô hình chuyển đổi, chủ sở hữu thực hiện một số hành động nhất
định. Yêu cầu được chuyển sang trạng thái mới sau khi hoàn thành
các hành động. Chúng tôi đã trình bày một lược đồ yêu cầu có thể
được sử dụng để tạo ra một ma trận xác định nguồn gốc. Ma trận xác
định nguồn gốc tìm thấy hai ứng dụng: (i) xác định và theo dõi phạm
vi chức năng của bộ thử nghiệm và (ii) xác định trường hợp thử
nghiệm nào phải được thực hiện hoặc cập nhật khi hệ thống trải qua
một sự thay đổi. Ma trận xác định nguồn gốc cho phép người ta tìm
ra ánh xạ giữa các yêu cầu và các trường hợp thử nghiệm như sau:
Từ một yêu cầu đến một đặc điểm kỹ thuật chức năng đến các bài
kiểm tra cụ thể thực hiện chúng
Từ mỗi trường hợp thử nghiệm trở lại các yêu cầu và thông số kỹ
thuật chức năng
Tiếp theo, chúng tôi kiểm tra các đặc điểm của các yêu cầu có thể
kiểm tra và đặc điểm kỹ thuật chức năng. Chúng tôi đã cung cấp các
kỹ thuật để xác định các mục tiêu kiểm tra từ các yêu cầu và thông số
kỹ thuật chức năng. Một yêu cầu phải được phân tích để rút ra các
yêu cầu suy ra được nhúng trong yêu cầu. Một yêu cầu được suy ra là
bất cứ điều gì mà một hệ thống được mong đợi để thực hiện nhưng
không được nêu rõ ràng. Cuối cùng, chúng tôi đã chỉ ra các cách để
tạo cấu trúc phân cấp của các nhóm thử nghiệm, được gọi là bộ thử
nghiệm. Để làm ví dụ, chúng tôi đã minh họa chi tiết việc thiết kế bộ
kiểm tra hệ thống cho giao thức kết nối dịch vụ FR – ATM.
Tiếp theo, chúng tôi cung cấp một mô hình chuyển đổi trạng thái của
một trường hợp thử nghiệm từ khi bắt đầu đến khi hoàn thành. Tại
mỗi trạng thái của mô hình chuyển đổi, chủ sở hữu thực hiện một số
hành động nhất định. Trường hợp thử nghiệm được chuyển sang
trạng thái mới sau khi các hành động được hoàn thành. Chúng tôi đã
trình bày một lược đồ trường hợp thử nghiệm để tạo một nhà máy
thử nghiệm có thể được sử dụng để thiết kế bộ thử nghiệm và theo
dõi các chỉ số chuẩn bị cho trường hợp thử nghiệm.
Cuối cùng, chúng tôi đã cung cấp một số liệu được sử dụng trong
ngành để đo lường hiệu quả thiết kế trường hợp thử nghiệm, được
gọi là năng suất thiết kế trường hợp thử nghiệm. Mục tiêu của thước
đo tính hiệu quả của trường hợp thử nghiệm là (i) đo lường “khả
năng bộc lộ khiếm khuyết” của bộ thử nghiệm và (ii) sử dụng thước
đo này để cải thiện quy trình thiết kế thử nghiệm.
11.11 TỔNG QUAN TÀI LIỆU
Một cuộc thảo luận tốt về các yêu cầu kiểm tra được trình bày trong
bài báo của Suzanne Robertson, có tựa đề “Khởi đầu sớm để kiểm
tra: Cách kiểm tra các yêu cầu”, được tái bản trong Phụ lục A của
cuốn sách của E. Dustin, J. Rashka, và J. Paul (Tự động
Kiểm thử phần mềm: Giới thiệu, Quản lý và Hiệu suất, Addison-
Wesley, Reading, MA, 1999). Tác giả mô tả một tập hợp các bài
kiểm tra yêu cầu bao gồm mức độ liên quan, tính đồng nhất, khả
năng truy xuất nguồn gốc, tính đầy đủ và các phẩm chất khác mà các
yêu cầu thành công phải có.
Các mô hình tham chiếu truy xuất nguồn gốc các yêu cầu được mô tả
trong bài báo của B. Ramesh và M. Jarke (“Hướng tới các mô hình
tham chiếu để xác định nguồn gốc yêu cầu,” IEEE Trans Transaction
on Software Engineering, Vol.27, No.1, January 2001, pp. 58–93)
dựa trên một số nghiên cứu thực nghiệm. Việc thu thập dữ liệu cho
công việc kéo dài trong khoảng thời gian hơn ba năm. Nghiên cứu
chính bao gồm 30 cuộc thảo luận nhóm tập trung tại 26 tổ chức được
tiến hành trong nhiều lĩnh vực khác nhau, bao gồm quốc phòng, hàng
không vũ trụ, dược phẩm, điện tử và viễn thông. Những người tham
gia có trung bình 15,5 năm kinh nghiệm trong một số lĩnh vực chính
của phát triển hệ thống, bao gồm kỹ thuật phần mềm, quản lý yêu
cầu, kiểm thử phần mềm, tích hợp hệ thống, phân tích hệ thống, bảo
trì và triển khai phần mềm. Những người tham gia được phân loại
thành hai nhóm riêng biệt liên quan đến các thực hành truy xuất
nguồn gốc của họ. Những nhóm này được gọi là những người sử
dụng truy xuất nguồn gốc cấp thấp và cấp cao. Các mô hình tham
chiếu riêng biệt cho hai nhóm này được thảo luận trong bài báo.
Tiêu chuẩn IEEE 829-1983 (Tiêu chuẩn IEEE cho Tài liệu Kiểm tra
Phần mềm: IEEE / ANSI Standard) cung cấp các mẫu cho các thông
số kỹ thuật trường hợp kiểm thử và thông số kỹ thuật quy trình kiểm
483
tra. Đặc tả trường hợp thử nghiệm bao gồm các thành phần sau: định
danh đặc tả trường hợp thử nghiệm, các mục thử nghiệm, đặc điểm
kỹ thuật đầu vào, đặc điểm kỹ thuật đầu ra, nhu cầu môi trường đặc
biệt, yêu cầu thủ tục đặc biệt và phụ thuộc trường hợp thử nghiệm.
Đặc tả thủ tục thử nghiệm bao gồm các thành phần sau: mã định
danh đặc điểm kỹ thuật thủ tục thử nghiệm, mục đích, các yêu cầu cụ
thể và các bước thủ tục.
Một cách tiếp cận khác để đo lường hiệu quả trường hợp thử nghiệm
đã được đề xuất bởi Yuri Chernak (“Xác thực và cải thiện hiệu quả
trường hợp thử nghiệm”, IEEE Software, Tập 18, Số 1, Tháng 1 /
Tháng 2 năm 2001, trang 81–86). Chỉ số hiệu quả được gọi là trường
hợp thử nghiệm đã thoát được định nghĩa là
số lượng khuyết tật được tìm thấy bởi các trường hợp thử nghiệm
TCE = × 100%
tổng số khuyết tật
Tổng số khuyết tật trong phương trình trên là tổng các khuyết tật
được tìm thấy bởi các trường hợp thử nghiệm và các khuyết tật được
tìm thấy một cách tình cờ, mà tác giả gọi là “tác dụng phụ”. Chernak
minh họa phương pháp luận của mình với ứng dụng máy khách-máy
chủ bằng cách sử dụng giá trị TCE cơ sở ( < 75 cho trường hợp này)
để đánh giá hiệu quả của trường hợp thử nghiệm và thực hiện các cải
tiến quy trình thử nghiệm. Thiết kế thử nghiệm không hoàn chỉnh và
các thông số kỹ thuật chức năng không đầy đủ được phát hiện là
những nguyên nhân chính dẫn đến việc thoát thử nghiệm.
Việc xác minh chính thức các trường hợp thử nghiệm được trình bày
trong bài báo của K. Naik và B. Sarikaya, “Xác minh trường hợp thử
nghiệm bằng cách kiểm tra mô hình,” Các phương pháp chính thức
trong thiết kế hệ thống, Vol. 2, tháng 6 năm 1993, trang 277–321.
Các tác giả đã xác định bốn lớp thuộc tính an toàn và một thuộc tính
sống và thể hiện chúng dưới dạng công thức trong logic thời gian
thời gian phân nhánh. Họ đã trình bày một thuật toán kiểm tra mô
hình để xác minh các thuộc tính đó.
Bài tập
Giải thích sự khác biệt giữa các thước đo độ phủ và ma trận xác định
nguồn gốc.
Giải thích sự khác biệt giữa khả năng kiểm tra yêu cầu và khả năng
kiểm thử phần mềm.
Biện minh cho tuyên bố rằng khả năng kiểm tra phần mềm và khả
năng chịu lỗi là đối lập với nhau và việc đạt được cả hai cùng một lúc
cho cùng một phần mềm là không khả thi. Khi nào bạn muốn khả
năng kiểm tra cao và khi nào thì không trong vòng đời của một hệ
thống phần mềm quan trọng? Biện minh cho câu trả lời của bạn.
Sự khác biệt giữa khả năng kiểm tra và độ tin cậy của phần mềm là
gì? Điều gì quan trọng hơn trong một phần mềm: khả năng kiểm tra
cao hay độ tin cậy cao? Biện minh cho câu trả lời của bạn.
Trong một dự án kiểm thử phần mềm, số lượng các trường hợp kiểm
tra cấp đơn vị, tích hợp và hệ thống được chỉ định lần lượt là 250,
175 và 235. Số lượng trường hợp thử nghiệm được thêm vào trong
giai đoạn thử nghiệm đơn vị, tích hợp và hệ thống lần lượt là 75, 60
và 35. Tính toán TCDY cho các giai đoạn thử nghiệm đơn vị, tích
hợp và hệ thống.
Chuẩn bị một danh sách kiểm tra các mục sẽ đóng vai trò là đầu mối
để xem xét các tủ kiểm tra.
Trong những trường hợp nào kết quả thực thi của một trường hợp thử
nghiệm có thể bị chặn?
Thực hiện mô hình yêu cầu được thảo luận trong chương này.
Triển khai mô hình nhà máy thử nghiệm được thảo luận trong
chương này.
Đối với dự án thử nghiệm hiện tại của bạn, hãy phát triển hệ thống
phân cấp bộ thử nghiệm và xác định mục tiêu ít nhất cho mỗi trường
hợp thử nghiệm trong mỗi nhóm thử nghiệm (con).
Phát triển các trường hợp thử nghiệm chi tiết bằng cách sử dụng lược
đồ được xác định trong Bảng 11.6 làm khuôn mẫu cho các mục tiêu
thử nghiệm mà bạn đã xác định trong bài tập trước.
CHAPTER
12
SystemTestPlanning
andAutomation
Khi lập kế hoạch cho một năm, hãy trồng ngô. Khi lập kế hoạch cho
một thập kỷ, hãy trồng cây. Khi lập kế hoạch cho cuộc sống, hãy đào
tạo và giáo dục con người.
-Tục ngữ Trung Quốc
12.1 CẤU TRÚC CỦA KẾ HOẠCH KIỂM TRA HỆ THỐNG
Một kế hoạch tốt để thực hiện kiểm thử hệ thống là nền tảng của một
dự án phần mềm thành công. Trong trường hợp không có kế hoạch
tốt, rất khó có khả năng mức độ kiểm thử hệ thống mong muốn được
thực hiện trong thời gian quy định và không sử dụng quá nhiều
nguồn lực như nhân lực và tiền bạc. Hơn nữa, trong trường hợp
không có kế hoạch tốt, khả năng cao là sản phẩm kém chất lượng
được giao với chi phí cao hơn và trễ hơn so với ngày dự kiến.
Mục đích của việc lập kế hoạch kiểm thử hệ thống, hay đơn giản là
lập kế hoạch kiểm thử, là để sẵn sàng và tổ chức cho việc thực hiện
kiểm thử. Bắt đầu kiểm tra hệ thống theo cách đột xuất, sau khi tất cả
các mô-đun được đăng ký vào hệ thống kiểm soát phiên bản, sẽ
không hiệu quả. Làm việc dưới áp lực về thời hạn, mọi người, tức là
các kỹ sư kiểm tra, có xu hướng đi tắt và “hoàn thành công việc”,
dẫn đến việc vận chuyển một sản phẩm có nhiều lỗi. Do đó, nhóm hỗ
trợ khách hàng của tổ chức phải mất nhiều thời gian để giải quyết
những khách hàng không hài lòng và buộc phải tung ra một số bản vá
cho những khách hàng khó tính. Lập kế hoạch kiểm tra là điều cần
thiết để hoàn thành kiểm tra hệ thống và xuất xưởng sản phẩm chất
lượng ra thị trường đúng tiến độ. Lập kế hoạch kiểm thử hệ thống là
một phần của kế hoạch tổng thể cho một dự án phần mềm. Nó cung
cấp khuôn khổ, phạm vi, tài nguyên, lịch trình và ngân sách cho phần
thử nghiệm hệ thống của dự án.
486 CHƯƠNG 12 QUY HOẠCH THỬ NGHIỆM VÀ TỰ ĐỘNG HÓA HỆ THỐNG
Hiệu quả kiểm tra có thể được theo dõi và cải thiện, và có thể tránh
được sự chậm trễ không cần thiết với một kế hoạch kiểm tra tốt. Mục
đích của kế hoạch kiểm tra hệ thống được tóm tắt như sau:
355
BẢNG 12.1 Đề cương kế hoạch kiểm tra hệ thống
Giới thiệu
Sự miêu tả yếu tố
Giả định
Cách tiếp cận thử nghiệm
Cấu trúc bộ thử nghiệm
Môi trường thử nghiệm
Kiểm tra chiến lược thực hiện
Kiểm tra ước tính nỗ lực
Lập lịch trình và các mốc quan trọng
Nó cung cấp hướng dẫn cho quản lý điều hành để hỗ trợ dự án thử
nghiệm, do đó cho phép họ giải phóng các nguồn lực cần thiết để
thực hiện hoạt động thử nghiệm. • Nó thiết lập nền tảng của phần
kiểm thử hệ thống của dự án phần mềm tổng thể.
Nó cung cấp sự đảm bảo về phạm vi kiểm tra bằng cách tạo ra một
ma trận xác định nguồn gốc yêu cầu.
Nó phác thảo một lịch trình có trật tự của các sự kiện và các mốc
kiểm tra được theo dõi.
Nó chỉ định các nguồn lực về nhân sự, tài chính, thiết bị và cơ sở vật
chất cần thiết để hỗ trợ phần kiểm thử hệ thống của một dự án phần
mềm.
Hoạt động lập kế hoạch kiểm thử hệ thống kết hợp hai nhiệm vụ:
nghiên cứu và ước tính. Nghiên cứu cho phép chúng tôi xác định
phạm vi của nỗ lực thử nghiệm và các nguồn lực đã có sẵn trong nhà.
Mỗi bộ thử nghiệm chức năng chính bao gồm các mục tiêu thử
nghiệm có thể được mô tả theo kiểu giới hạn bằng cách sử dụng các
yêu cầu hệ thống và đặc điểm kỹ thuật chức năng làm tài liệu tham
487
khảo. Người đọc có thể tham khảo Chương 11 để thảo luận về các bộ
thử nghiệm được mô tả theo kiểu giới hạn.
Kế hoạch kiểm tra hệ thống được nêu trong Bảng 12.1. Chúng tôi
giải thích những cách người ta có thể tạo một kế hoạch thử nghiệm.
Kế hoạch thử nghiệm được phát hành để xem xét và phê duyệt sau
khi tác giả, tức là trưởng nhóm thử nghiệm hệ thống, hoàn thành nó
với tất cả các chi tiết thích hợp. Nhóm đánh giá phải bao gồm nhân
viên phát triển phần mềm và phần cứng, thành viên nhóm hỗ trợ
khách hàng, thành viên nhóm kiểm tra hệ thống và người quản lý dự
án chịu trách nhiệm về dự án. (Các) tác giả nên trưng cầu ý kiến về
kế hoạch thử nghiệm và xin ý kiến trước cuộc họp. Các ý kiến sau đó
có thể được giải quyết tại cuộc họp đánh giá. Kế hoạch kiểm thử hệ
thống phải được hoàn thành trước khi dự án phần mềm được cam
kết.
12.2 GIỚI THIỆU VÀ MÔ TẢ ĐẶC TRƯNG
Phần giới thiệu của kế hoạch kiểm tra hệ thống mô tả cấu trúc và
mục tiêu của kế hoạch kiểm tra. Phần này bao gồm (i) tên dự án thử
nghiệm, (ii) sửa đổi
12.4 CÁCH TIẾP CẬN KIỂM TRA
lịch sử, (iii) thuật ngữ và định nghĩa, (iv) tên người phê duyệt và
ngày phê duyệt, (v) tài liệu tham khảo, và (vi) tóm tắt phần còn lại
của kế hoạch thử nghiệm.
Phần mô tả tính năng tóm tắt các tính năng hệ thống sẽ được thử
nghiệm trong quá trình thực hiện kế hoạch thử nghiệm này. Nói cách
khác, mô tả cấp cao về các chức năng của hệ thống được trình bày
trong phần này. Mô tả tính năng cho ví dụ liên kết dịch vụ FR / ATM
được thảo luận trong Chương 11.
12.3 TIÊU THỤ
Phần giả định mô tả các khu vực mà các trường hợp thử nghiệm sẽ
không được thiết kế trong kế hoạch này do có nhiều mùa. Đầu tiên,
các thiết bị cần thiết để thực hiện kiểm tra khả năng mở rộng có thể
không có sẵn. Thứ hai, có thể không kịp thời mua sắm thiết bị của
bên thứ ba để tiến hành kiểm tra khả năng tương tác. Cuối cùng, có
thể không tiến hành các thử nghiệm tuân thủ đối với các cơ quan
quản lý và thử nghiệm môi trường trong phòng thí nghiệm. Các giả
•
định này phải được xem xét trong khi xem xét kế hoạch kiểm tra hệ
thống.
12.4 CÁCH TIẾP CẬN KIỂM TRA
Phương pháp thử nghiệm tổng thể là một khía cạnh quan trọng của
một dự án thử nghiệm bao gồm những điều sau:
Bài học kinh nghiệm từ các dự án thử nghiệm trước đây rất hữu ích
trong việc tập trung vào các khu vực có vấn đề trong quá trình thử
nghiệm. Các vấn đề do khách hàng phát hiện mà không mắc phải
trong quá trình thử nghiệm hệ thống trong các dự án trước đây sẽ
được thảo luận. Ví dụ, nếu một khách hàng gặp phải rò rỉ bộ nhớ
trong hệ thống trong dự án trước đây, thì phải thực hiện hành động để
loại bỏ sớm mọi rò rỉ bộ nhớ trong quá trình thực thi kiểm tra hệ
thống. Có thể cần một phản ứng thích hợp để phát triển các trường
hợp kiểm thử hiệu quả bằng cách sử dụng các công cụ phần mềm
tinh vi như máy phát hiện rò rỉ bộ nhớ trên thị trường.
Nếu có bất kỳ vấn đề nổi bật nào cần được kiểm tra theo cách khác,
ví dụ, yêu cầu cấu hình phần cứng và phần mềm cụ thể, thì những
vấn đề này cần được thảo luận ở đây.
Một chiến lược tự động hóa thử nghiệm để viết kịch bản là một chủ
đề thảo luận.
Các trường hợp thử nghiệm cần được xác định trong nhà máy thử
nghiệm có thể được sử dụng lại trong kế hoạch thử nghiệm này.
Cần chuẩn bị phác thảo về các công cụ, định dạng và sơ đồ tổ chức,
chẳng hạn như ma trận xác định nguồn gốc, sẽ được sử dụng và tuân
theo trong dự án thử nghiệm.
Cuối cùng, cấp độ đầu tiên của các loại kiểm tra, có khả năng áp
dụng cho tình huống hiện tại và như đã thảo luận trong Chương 8,
được xác định.
12.5 CẤU TRÚC TRANG WEB THỬ NGHIỆM
Các nhóm kiểm tra chi tiết và phân nhóm được nêu trong phần cấu
trúc bộ kiểm thử dựa trên các hạng mục kiểm tra được xác định trong
phần cách tiếp cận kiểm tra. Các mục tiêu kiểm tra được tạo cho từng
nhóm kiểm tra và phân nhóm dựa trên các yêu cầu hệ thống và đặc
điểm kỹ thuật chức năng được thảo luận trong Chương 11. Một ma
trận xác định nguồn gốc được tạo ra để tạo sự liên kết giữa các yêu
489
cầu và mục tiêu kiểm tra nhằm cung cấp mức độ tin cậy cao nhất.
Lưu ý rằng ở giai đoạn này, chỉ các bộ thử nghiệm cùng với các mục
tiêu thử nghiệm được xác định chứ không xác định các trường hợp
thử nghiệm chi tiết. Việc xác định các mục tiêu kiểm thử cung cấp
manh mối về tổng số các trường hợp kiểm thử mới cần được phát
triển cho dự án này. Nếu một số trường hợp kiểm thử hiện có, tự
động hoặc thủ công, cần được chạy dưới dạng kiểm thử hồi quy, thì
những trường hợp kiểm thử đó phải được bao gồm trong bộ kiểm
thử. Thông tin này hữu ích trong việc ước tính thời gian cần thiết để
tạo các trường hợp thử nghiệm và thực thi bộ thử nghiệm, như đã
thảo luận trong Phần 12.8. Cấu trúc bộ thử nghiệm cho ví dụ liên kết
dịch vụ FR / ATM được thảo luận trong Chương 11.
12.6 MÔI TRƯỜNG THỬ NGHIỆM
Cần phải lập kế hoạch và thiết kế môi trường thử nghiệm, còn được
gọi là giường thử nghiệm hoặc phòng thí nghiệm thử nghiệm, để làm
cho việc thực thi các trường hợp thử nghiệm cấp hệ thống có hiệu
quả. Đó là một thách thức để thiết kế môi trường thử nghiệm chỉ
chứa một tỷ lệ nhỏ các thiết bị và phương tiện được sử dụng trong
hoạt động thực tế vì hạn chế về ngân sách. Ý tưởng chính trong việc
sử dụng một tỷ lệ nhỏ thiết bị và cơ sở vật chất là làm nhiều hơn với
ít hơn. Mục tiêu ở đây là đạt được kiểm tra hiệu quả, theo đó hầu hết
các khiếm khuyết trong hệ thống được bộc lộ bằng cách sử dụng một
số lượng tài nguyên hạn chế. Người ta phải đổi mới trong việc thiết
kế giường thử sao cho các mục tiêu thử nghiệm được thực hiện bằng
cách thực hiện các trường hợp thử nghiệm trên giường thử nghiệm.
Người ta phải xem xét các lựa chọn thay thế, hoặc ít nhất, một phiên
bản thu nhỏ của môi trường triển khai từ quan điểm hiệu quả về chi
phí. Phải nỗ lực để tạo ra môi trường triển khai bằng cách sử dụng
trình mô phỏng, trình giả lập và các công cụ tạo lưu lượng truy cập
của bên thứ ba. Các công cụ như vậy được cho là hữu ích trong việc
tiến hành kiểm tra khả năng mở rộng, hiệu suất, tải và căng thẳng.
Một trình giả lập có thể không phải là sự thay thế lý tưởng cho thiết
bị thực, nhưng miễn là nó đáp ứng được mục đích thì nó đáng được
đầu tư. Chúng tôi đã giải thích trong Chương 8 rằng có nhiều loại
trường hợp thử nghiệm khác nhau được thiết kế ở cấp hệ thống. Do
đó, nhiều môi trường thử nghiệm được xây dựng trong thực tế vì
những lý do sau:
•
Để chạy các bài kiểm tra khả năng mở rộng, chúng tôi cần nhiều tài
nguyên hơn mức cần thiết để chạy các bài kiểm tra chức năng.
Cần có nhiều giường thử nghiệm để giảm thời gian thử nghiệm hệ
thống.
Chuẩn bị cho một môi trường thử nghiệm là một thách thức lớn trong
việc lập kế hoạch thử nghiệm. Điều này đặc biệt đúng trong việc thử
nghiệm các hệ thống phân tán và mạng máy tính nơi nhiều thiết bị
được kết nối thông qua các giao thức truyền thông. Ví dụ, thiết bị đó
bao gồm máy tính người dùng, máy chủ, bộ định tuyến, trạm gốc
trong mạng không dây
12.6 MÔI TRƯỜNG THỬ NGHIỆM
mạng, máy chủ xác thực và máy chủ thanh toán. Có thể mất vài
tháng để thiết lập một giường thử nghiệm hiệu quả cho các hệ thống
lớn và phức tạp . Nó đòi hỏi phải lập kế hoạch cẩn thận, mua sắm
thiết bị thử nghiệm và lắp đặt thiết bị trong một cơ sở thử nghiệm
khác với cơ sở phát triển phần mềm để việc thử nghiệm hệ thống
được thực hiện một cách hiệu quả. Các nhà phát triển có môi trường
thử nghiệm của riêng họ để thực hiện các thử nghiệm đơn vị và thử
nghiệm tích hợp. Tuy nhiên, một phòng thí nghiệm thử nghiệm hệ
thống chuyên dụng, riêng biệt, khác với phòng thí nghiệm được sử
dụng trong thử nghiệm đơn vị và tích hợp, là điều cần thiết vì những
lý do sau:
Kỹ sư kiểm thử cần có khả năng cấu hình lại môi trường kiểm thử.
Các hoạt động kiểm tra không cần can thiệp vào các hoạt động phát
triển hoặc hoạt động trực tiếp.
Tăng năng suất đạt được nhờ có phòng thí nghiệm kiểm tra chuyên
dụng.
Một vấn đề trọng tâm liên quan đến việc thiết lập phòng thí nghiệm
kiểm tra hệ thống là lý do để mua thiết bị. Lưu ý rằng cần phải chứng
minh từng mặt hàng được mua sắm. Có thể đưa ra lý do chính đáng
cho việc mua sắm thiết bị bằng cách trả lời các câu hỏi sau:
Tại sao chúng ta cần thiết bị này?
Tác động của việc không có thiết bị này là gì?
Có cách nào thay thế cho việc mua sắm thiết bị này không?
Trưởng nhóm kỹ thuật của nhóm kỹ thuật kiểm tra hệ thống nên thu
thập một số dữ kiện và thực hiện một số hoạt động chuẩn bị để có
491
câu trả lời cho những câu hỏi này. Các mục sau đây là một phần của
quy trình thu thập dữ kiện tốt:
Xem xét các yêu cầu hệ thống và đặc điểm kỹ thuật chức năng
Tham gia vào các quá trình xem xét để hiểu rõ hơn về hệ thống và
nêu lên những lo ngại tiềm ẩn liên quan đến việc chuyển đổi hệ thống
từ môi trường phát triển sang môi trường triển khai
Ghi lại những phát hiện của anh ấy hoặc cô ấy
Các hoạt động chuẩn bị sau được thực hiện để hỗ trợ việc phát triển
giường thử nghiệm hệ thống:
Nhận thông tin về kiến trúc triển khai của khách hàng, bao gồm phần
cứng, phần mềm và nhà sản xuất của chúng. Ví dụ, sơ đồ mạng triển
khai thực cùng với cấu hình phần mềm rất hữu ích trong việc thiết kế
phiên bản thu nhỏ của hệ thống trong phòng thí nghiệm. Tên nhà sản
xuất sẽ hữu ích trong việc mua sắm thiết bị chính xác để kiểm tra khả
năng tương tác và khả năng tương thích.
Nhận danh sách các sản phẩm của bên thứ ba sẽ được tích hợp với
SUT. Việc xác định các sản phẩm bên ngoài là rất quan trọng vì cần
phải thực hiện kiểm tra khả năng tương tác.
Liệt kê các công cụ kiểm tra của bên thứ ba được sử dụng để theo
dõi, mô phỏng và / hoặc tạo lưu lượng truy cập thực. Lưu lượng này
sẽ được sử dụng làm đầu vào cho SUT.
Xác định các công cụ phần mềm của bên thứ ba sẽ được sử dụng
theo giấy phép.
Xác định thiết bị phần cứng cần thiết để hỗ trợ các tính năng đặc biệt
được chỉ định trong mục tiêu yêu cầu / thử nghiệm, chẳng hạn như
tính khả dụng cao và các bài tập sao lưu / phục hồi trong môi trường
thử nghiệm.
Liệt kê số lượng bản sao phần cứng để thực hiện kiểm tra hệ thống
nếu dự án liên quan đến phần cứng mới.
Phân tích các mục tiêu kiểm tra chức năng, hiệu suất, căng thẳng, tải
và khả năng mở rộng để xác định các yếu tố của môi trường thử
nghiệm sẽ được yêu cầu để hỗ trợ các thử nghiệm đó.
Xác định các yêu cầu bảo mật cho môi trường thử nghiệm. Đảm bảo
rằng các trường hợp thử nghiệm bảo mật có thể được thực thi bằng
cách sử dụng môi trường thử nghiệm và kẻ xâm nhập không thể làm
gián đoạn các thử nghiệm căng thẳng và ổn định có thể chạy qua đêm
hoặc cuối tuần.
•
Liệt kê các bánh răng mạng nhỏ, nhưng cần thiết có thể được yêu cầu
để thiết lập phòng thí nghiệm thử nghiệm, chẳng hạn như thiết bị
chuyển mạch, máy chủ đầu cuối, trung tâm, bộ suy hao, bộ tách sóng,
máy tính cá nhân, máy chủ và các loại và kích cỡ cáp khác nhau để
kết nối các bánh răng này.
Liệt kê bất kỳ phụ kiện nào khác cần thiết để hỗ trợ quá trình kiểm
tra hệ thống, chẳng hạn như giá đỡ, phương tiện và tấm chắn đặc biệt
để ngăn bức xạ.
Sau các hoạt động thu thập và nghiên cứu thực tế ở trên, trưởng
nhóm phát triển một sơ đồ của một hoặc nhiều giường thử nghiệm
theo hai mục sau: • Bố cục đồ họa cấp cao của các kiến trúc thử
nghiệm
Bảng các loại thiết bị, số lượng và mô tả của chúng để hỗ trợ kiến
trúc thử nghiệm
Danh sách thiết bị cần được xem xét để xác định thiết bị có sẵn trong
nhà và những thiết bị cần mua sắm. Danh sách thiết bị cần mua sắm
tạo thành danh sách mua thiết bị thử nghiệm. Danh sách cần bao gồm
số lượng yêu cầu, thông tin đơn giá, bao gồm cả chi phí bảo trì và lý
do, như được nêu trong mẫu hiển thị trong Bảng 12.2. Trưởng nhóm
phải nêu rõ, đối với mỗi mục trong cột lý giải, lý do cho mục đó và
tác động của nó đối với việc kiểm tra hệ thống về mặt chất lượng và
thời gian đưa ra thị trường. Trưởng nhóm có thể lấy báo giá từ các
nhà cung cấp để có đơn giá chính xác. Trưởng nhóm thử nghiệm cần
theo dõi các thiết bị đã nhận và việc lắp đặt chúng sau khi ngân sách
được
BẢNG 12.2 Thiết bị cần được mua sắm
Thiết bị cần mua Số lượng Giá đơn vị Chi phí bảo trì
10.13 TEST THẾ HỆ TỪ CÁC MÔ HÌNH EFSM 493
được chấp thuận và các đơn đặt hàng được đặt. Người lãnh đạo cần
đảm bảo rằng các hoạt động này đang đi đúng hướng để đáp ứng tiến
độ tổng thể của dự án phần mềm.
12.7 CHIẾN LƯỢC THỰC HIỆN THỬ NGHIỆM
Điều quan trọng là phải có một kế hoạch trò chơi thích hợp sẵn sàng
trước khi nhóm kiểm tra hệ thống nhận được một hệ thống phần mềm
lần đầu tiên để thực hiện kiểm tra hệ thống.
Kế hoạch trò chơi ở dạng chiến lược thực thi thử nghiệm hệ thống để
thực hiện nhiệm vụ [1]. Chúng tôi giải quyết những lo ngại sau đây
bằng cách đưa ra kế hoạch trò chơi trước khi bắt đầu thử nghiệm hệ
thống:
Các trường hợp kiểm thử được thực thi bao nhiêu lần và khi nào?
Người ta làm gì với các trường hợp thử nghiệm không thành công?
Điều gì xảy ra khi có quá nhiều trường hợp thử nghiệm không thành
công?
Các trường hợp kiểm thử được thực hiện theo thứ tự nào?
Những trường hợp thử nghiệm nào sẽ được chạy ngay trước khi kết
thúc giai đoạn thử nghiệm hệ thống?
Trong trường hợp không có chiến lược thực thi kiểm tra hệ thống tốt,
rất khó có khả năng kiểm tra mức hệ thống mong muốn được thực
hiện trong thời gian nhất định và không sử dụng quá mức tài nguyên.
Chúng ta hãy xem xét một chiến lược thực hiện đơn giản. Giả sử
rằng một nhóm kiểm tra hệ thống đã thiết kế bộ kiểm thử T cho hệ
thống S. Do việc phát hiện và loại bỏ các khuyết tật và khả năng gây
ra nhiều khuyết tật hơn, S là một hệ thống đang phát triển có thể
được đặc trưng bởi một chuỗi các bản dựng B 0 , B 1 , B 2 , ..., B k ,
trong đó mỗi bản dựng là dự kiến sẽ có ít khiếm khuyết hơn so với
phiên bản tiền nhiệm. Một chiến lược đơn giản để thực hiện kiểm thử
hệ thống như sau: Chạy tập kiểm tra T trên B 0 để phát hiện tập hợp
các khuyết tật D 0 ; cho B 1 là một công trình thu được từ B 0 bằng
cách sửa chữa các khuyết tật D 0 ; chạy T trên B 1 để phát hiện tập
hợp các khuyết tật D 1 ; cho B 2 là một công trình thu được từ B 1 bằng
cách sửa chữa các khuyết tật D 1 ; và quá trình này có thể tiếp tục cho
đến khi mức chất lượng của hệ thống ít nhất là mức chất lượng mong
muốn. Người ta có thể áp dụng một chiến lược thực thi đơn giản như
vậy nếu tất cả các trường hợp thử nghiệm trong T có thể được thực
thi độc lập, nghĩa là không có trường hợp thử nghiệm nào bị chặn do
lỗi trong hệ thống. Nếu tất cả các lỗi được báo cáo được khắc phục
ngay lập tức và không có lỗi mới nào được đưa vào, thì quá trình
kiểm tra hệ thống có thể được coi là kết thúc bằng cách chạy T hai
lần: một lần trên B 0 để phát hiện D 0 và lần thứ hai trên B 1 để xác
nhận. Trong phần thảo luận ở trên, chúng tôi đề cập đến việc chạy T ,
hoặc một tập hợp con của nó, trên bản xây dựng mới của một phần
mềm SUT như một chu trình kiểm tra hệ thống.
Tuy nhiên, các quá trình thực hiện kiểm tra, phát hiện lỗi và sửa chữa
các lỗi được đan xen một cách phức tạp. Các đặc điểm chính của các
quá trình đó như sau:
Một số trường hợp kiểm thử không thể được thực hiện trừ khi một số
lỗi được phát hiện và sửa chữa.
Một lập trình viên có thể đưa ra các khiếm khuyết mới trong khi sửa
một lỗi, điều này có thể không thành công.
Nhóm phát triển phát hành một bản dựng mới để kiểm tra hệ thống
bằng cách làm việc trên một tập hợp con của các lỗi được báo cáo,
thay vì tất cả các lỗi.
Sẽ rất lãng phí tài nguyên để chạy toàn bộ tập thử nghiệm T trên một
bản dựng nếu quá nhiều trường hợp thử nghiệm bị lỗi.
Vì số lượng lỗi được báo cáo giảm đáng kể qua một vài lần lặp lại
thử nghiệm, nên không cần thiết phải chạy toàn bộ tập thử nghiệm T
để kiểm tra hồi quy — một tập con T được chọn cẩn thận được mong
đợi là đủ.
Do đó, chiến lược thực thi kiểm tra đơn giản được giải thích ở trên là
không thực tế. Một chiến lược thực thi hiệu quả và hiệu quả phải tính
đến các đặc điểm đó của việc thực hiện kiểm tra, phát hiện lỗi và loại
bỏ lỗi.
Chúng tôi trình bày một mô hình quy trình cho chiến lược thực thi
kiểm tra đa chu kỳ, dựa trên số liệu xác định rõ ràng tiêu chí đầu vào
để bắt đầu kiểm tra hệ thống, cách ưu tiên thực hiện các trường hợp
kiểm thử, khi nào chuyển từ chu kỳ kiểm tra này sang chu kỳ tiếp
theo, khi nào chạy lại kiểm tra không thành công các trường hợp, khi
nào thì tạm dừng chu kỳ thử nghiệm và bắt đầu phân tích nguyên
nhân gốc rễ và cách chọn một tập hợp con các trường hợp thử
10.13 TEST THẾ HỆ TỪ CÁC MÔ HÌNH EFSM 495
nghiệm trong chu kỳ thử nghiệm cuối cùng để kiểm tra hồi quy.
Chúng tôi mô tả mỗi chu kỳ thử nghiệm bằng một bộ sáu tham số:
mục tiêu, giả định, thực thi thử nghiệm, tiêu chí hoàn nguyên và mở
rộng, tiêu chí hành động và thoát. Ý tưởng đằng sau một chu trình
kiểm tra tham số hóa gồm hai phần: (i) mức chất lượng của hệ thống
được nâng lên theo cách có thể đo lường, kiểm soát và tăng dần có
thể từ mức thấp ban đầu đến mức cao cuối cùng và (ii) quá trình thử
nghiệm hệ thống được chia nhỏ thành một chuỗi các bước có thể lặp
lại. Các giá trị tham số trong mỗi chu kỳ kiểm tra cho phép người
lãnh đạo kiểm tra hệ thống kiểm soát hiệu quả tiến độ kiểm tra hệ
thống để hệ thống tiến một bước gần hơn đến mức chất lượng cuối
cùng mong muốn.
12.7.1 Chiến lược kiểm tra hệ thống đa chu trình
Ví dụ, ý tưởng về chiến lược thực thi kiểm tra đa chu kỳ với ba chu
kỳ được minh họa trong Hình 12.1a. Hình 12.1b cho thấy chất lượng
của sản phẩm tăng lên như thế nào từ chu kỳ thử nghiệm này sang
chu kỳ thử nghiệm. Trong một chu kỳ thử nghiệm, tất cả các trường
hợp thử nghiệm trong toàn bộ bộ thử nghiệm T , hoặc một tập hợp
con được chọn cẩn thận của T , được thực hiện ít nhất một lần. Dự
kiến rằng một số lỗi sẽ được khắc phục trong vòng đời của chu kỳ
thử nghiệm để mức chất lượng của hệ thống được nâng lên một
lượng nhất định, như minh họa trong Hình 12.1b. Sự cần thiết của hai
phân tích nguyên nhân gốc rễ, một của nhóm phát triển và một của
nhóm kiểm tra hệ thống, sẽ được giải thích ở phần sau của phần này.
Tổng số chu kỳ thử nghiệm sẽ được sử dụng trong các dự án thử
nghiệm riêng lẻ là vấn đề của quyết định quản lý dựa trên mức chất
lượng được giao mà người ta muốn đạt được, mức độ mà bộ thử
nghiệm đáp ứng các yêu cầu của hệ thống và tính hiệu quả sửa chữa
các khiếm khuyết.
12.7.2 Đặc điểm của các chu kỳ thử nghiệm
Mỗi chu kỳ thử nghiệm được đặc trưng bởi một bộ sáu tham số: mục
tiêu, giả định, thực thi thử nghiệm, hành động, tiêu chí hoàn nguyên
và mở rộng, và tiêu chí thoát. Các giá trị thích hợp phải được gán cho
các thông số này trong khi chuẩn bị một chiến lược thực hiện thử
nghiệm cụ thể. Trong Phần 12.7.6, chúng tôi đưa ra các trường hợp
thực tế, đại diện của các thông số này cho ba chu kỳ thử nghiệm,
trong đó chu kỳ thử nghiệm thứ ba là chu kỳ cuối cùng.
12.7 CHIẾN LƯỢC THỰC HIỆN THỬ NGHIỆM 497
Root cause analysis by

the development team
Revert
Begin Test Test Test

cycle 1 cycle 2 cycle 3 End
Root cause analysis by

the system test team
(a) Progress of system testing in terms of test cycles
Quality at the Quality at

beginning Cycle 1 Cycle 2 Cycle 3 the end
(b) Desired increase in quality level

Hình 12.1 Khái niệm về chiến lược thực thi kiểm thử dựa trên
chu kỳ.
Mục tiêu Một nhóm kiểm tra hệ thống đặt ra các mục tiêu riêng cần
đạt được trong mỗi chu kỳ kiểm tra. Những mục tiêu này là lý tưởng
theo nghĩa đây là những mục tiêu tiêu chuẩn rất cao, và do đó, có thể
không đạt được trong một chu kỳ thử nghiệm nhất định. Động lực để
thiết lập các mục tiêu lý tưởng là không biết mục tiêu nào yếu hơn là
mong muốn và có thể đạt được. Đặt mục tiêu yếu hơn có nguy cơ
không khuyến khích các nhóm phát triển và thử nghiệm đạt được
mục tiêu mạnh hơn. Do đó, chúng tôi đặt mục tiêu đạt được các mục
tiêu lý tưởng trong mỗi chu kỳ thử nghiệm, nhưng chúng tôi sẵn sàng
thoát khỏi chu kỳ thử nghiệm ngay cả khi các mục tiêu không hoàn
toàn đạt được. Tiêu chí thoát xác định sự kết thúc của một chu kỳ thử
nghiệm. Các mục tiêu được chỉ định về số lượng trường hợp thử
nghiệm cần vượt qua trong một chu kỳ thử nghiệm. Mặc dù các mục
tiêu cũng có thể được xác định về số lượng lỗi còn lại trong sản phẩm
phần mềm vào cuối mỗi chu kỳ kiểm tra hệ thống [2], việc dự đoán
số lượng lỗi còn lại là một nhiệm vụ rất khó khăn [3].
•
Nhận xét 1. Mục tiêu của một chu kỳ kiểm tra có thể bị thay đổi do
những trường hợp không lường trước được. Ví dụ, một chu kỳ thử
nghiệm bị kết thúc sớm vì chất lượng kém của phần mềm. Tuy nhiên,
nhóm kiểm thử hệ thống có thể tiến hành hoàn thành chu trình kiểm
thử hệ thống để có được kinh nghiệm thực hành và có thể xác định
nhu cầu cho các trường hợp kiểm thử bổ sung. Trong tình huống này,
mục tiêu cụ thể của chu trình kiểm thử có thể được thay đổi để hiểu
và nâng cao hiệu quả của các trường hợp kiểm thử.
Các giả định Một nhóm SIT và một nhóm kiểm tra hệ thống làm việc
theo cách tự chủ nhưng hợp tác trong một tổ chức. Nhóm SIT sản
xuất các bản dựng gần như thường xuyên, trong khi nhóm kiểm tra
hệ thống chọn các bản dựng để thử nghiệm theo lịch trình của riêng
mình, chẳng hạn như hai tuần một lần. Do đó, không phải tất cả các
bản dựng đều được chấp nhận để kiểm tra hệ thống. Trong phần giả
định, nhóm kiểm thử hệ thống ghi lại giả định của riêng mình về thời
điểm chọn các bản dựng để kiểm tra hệ thống. Các giả định thích hợp
phải được thực hiện để đạt được các mục tiêu. Ví dụ: hãy xem xét
một mục tiêu mà 90% các trường hợp thử nghiệm sẽ vượt qua trong
chu kỳ thử nghiệm năm tuần và một giả định khác rằng nhóm thử
nghiệm hệ thống sẽ chỉ chấp nhận một bản dựng mới từ nhóm SIT
trong chu kỳ thử nghiệm. Giả sử rằng vào cuối tuần thử nghiệm thứ
tư, tổng số trường hợp thử nghiệm đạt, không đạt và bị chặn lần lượt
là 70, 7 và 23%. Một trường hợp thử nghiệm được cho là bị chặn nếu
một lỗi ngăn cản việc thực hiện trường hợp thử nghiệm. Vì vậy, mục
tiêu không thể đạt được vào cuối tuần thứ năm. Nhóm có thể chấp
nhận các bản dựng từ nhóm SIT hàng ngày để tránh tình trạng này.
Người ta phải dành một lượng thời gian đáng kể để thiết lập các
giường thử nghiệm bằng cách cài đặt một bản dựng hàng ngày để
chọn một bản dựng hàng ngày để kiểm tra hệ thống. Do đó, người
quản lý thử nghiệm phải đưa ra một giả định thích hợp để cho phép
họ đạt được mục tiêu mong muốn.
TestExecution Các trường hợp thử nghiệm được thực thi đồng thời
trong nhiều môi trường thử nghiệm bằng cách sử dụng khái niệm ưu
tiên thử nghiệm. Ưu tiên các thay đổi thực hiện thử nghiệm giữa các
chu kỳ thử nghiệm. Điều này mang lại sự cân bằng giữa việc ưu tiên
các trường hợp thử nghiệm chỉ một lần trong toàn bộ thời gian thử
nghiệm hệ thống và ưu tiên các trường hợp thử nghiệm từ bản dựng
này sang bản dựng khác. Một số ý tưởng cơ bản trong ưu tiên kiểm
thử như sau: (i) các trường hợp kiểm thử thực hiện các chức năng cơ
bản có mức độ ưu tiên cao hơn phần còn lại trong chu kỳ kiểm thử
đầu tiên; (ii) các trường hợp thử nghiệm không thành công trong một
chu kỳ thử nghiệm có mức độ ưu tiên cao hơn trong chu kỳ thử
nghiệm sau; và (iii) các trường hợp thử nghiệm trong một số nhóm
thử nghiệm nhất định có mức độ ưu tiên cao hơn các nhóm khác. Có
ba điểm khác biệt giữa mức độ ưu tiên kiểm tra đã được nghiên cứu
trong quá khứ [4–6] và cách tiếp cận mới được trình bày trong cuốn
sách này, như sau:
Ưu tiên kiểm tra đã được xem xét phần lớn cho kiểm thử hồi quy.
Trong chiến lược thử nghiệm của chúng tôi, các trường hợp thử
nghiệm cũng được ưu tiên cho thử nghiệm phát triển. Các trường hợp
kiểm thử được ưu tiên trong quá trình kiểm tra hệ thống để thực hiện
sớm phần mã có khả năng bị tấn công để các nhà phát triển có nhiều
thời gian hơn để gỡ lỗi và sửa các lỗi, nếu có. Ví dụ, nếu các khiếm
khuyết được tiết lộ vào cuối chu kỳ thử nghiệm, các nhà phát triển có
thể không có đủ thời gian để sửa chữa các khiếm khuyết; hơn nữa,
nhóm kiểm tra hệ thống có thể không xác thực được các bản sửa lỗi
trong thời gian rất ngắn. Srivastava và Thiagarajan [7] trình bày một
kỹ thuật ưu tiên kiểm tra để kiểm tra hồi quy trong quá trình phát
triển. Thuật toán ưu tiên kiểm tra của họ dựa trên sự khác biệt ở mức
khối giữa mã nhị phân đã biên dịch của phiên bản trước của hệ thống
và phiên bản hiện tại của hệ thống sẽ được kiểm tra. Thuật toán ưu
tiên cố gắng chọn một bài kiểm tra từ các bài kiểm tra còn lại sẽ bao
gồm số lượng tối đa các khối còn lại bị ảnh hưởng, nghĩa là mới hoặc
đã sửa đổi.
Ưu tiên kiểm tra tạo ra một chuỗi các trường hợp kiểm thử có thứ tự,
trong khi nhu cầu và cơ hội để tạo ra các chuỗi thực thi thử nghiệm
đồng thời, nhỏ hơn đã bị bỏ qua. Trong cách tiếp cận của chúng tôi,
tính đồng thời của việc thực thi thử nghiệm và tầm quan trọng của
các trường hợp thử nghiệm đã được tính vào ưu tiên thử nghiệm.
Nhiều môi trường thử nghiệm đồng thời cho phép chúng tôi rút ngắn
thời gian thử nghiệm hệ thống. Kapfhammer [8] đề xuất ý tưởng
chạy các bài kiểm tra hồi quy trên nhiều máy giao tiếp.
Rất khó xảy ra trường hợp hàng chục kỹ sư làm việc trong một dự án
thử nghiệm có cùng mối quan tâm và kiến thức chuyên môn về tất cả
các khía cạnh của hệ thống. Ví dụ: một người có thể là chuyên gia
đánh giá hiệu suất, trong khi một người khác có thể hữu ích trong
việc kiểm tra giao diện người dùng. Các trường hợp kiểm thử thuộc
danh mục tương ứng của chúng được ưu tiên riêng.
RevertandExtensionCriteria Mỗi chu kỳ kiểm tra phải được hoàn
thành trong một thời gian quy định. Tuy nhiên, thời gian của một chu
kỳ thử nghiệm có thể được kéo dài trong một số trường hợp nhất
định và trong trường hợp xấu nhất, chu kỳ thử nghiệm phải được bắt
đầu lại từ đầu. Các điều kiện để kết thúc sớm chu kỳ thử nghiệm và
để kéo dài chu kỳ thử nghiệm phải được nêu chính xác. Về cơ bản,
khái niệm tiêu chí hoàn nguyên được sử dụng để đảm bảo rằng việc
kiểm tra hệ thống góp phần vào chất lượng tổng thể của sản phẩm
với chi phí giảm. Việc tiếp tục chu kỳ kiểm tra có thể không hữu ích
nếu phát hiện phần mềm có chất lượng quá kém. Mặt khác, chu kỳ
kiểm thử có thể được kéo dài do nhiều lý do khác nhau, chẳng hạn
như (i) nhu cầu thực hiện lại tất cả các trường hợp thử nghiệm trong
một nhóm thử nghiệm cụ thể vì một phần lớn các trường hợp thử
nghiệm trong nhóm không thành công hoặc (ii) một số lượng lớn
đáng kể các trường hợp thử nghiệm mới đã được thêm vào trong khi
quá trình thực thi thử nghiệm đang diễn ra. Ý tưởng về một tiêu chí
hoàn nguyên được thảo luận ở trên tương tự như ý tưởng về việc
dừng các quy tắc để kiểm tra [9].
Hành động Hai sự kiện không mong muốn có thể xảy ra trong khi
một chu kỳ thử nghiệm đang diễn ra: (i) quá nhiều trường hợp thử
nghiệm không thành công và (ii) nhóm kiểm thử hệ thống phải thiết
kế một số lượng lớn các trường hợp thử nghiệm mới trong chu kỳ thử
nghiệm. Một mặt, nhóm phát triển cố gắng hiểu điều gì đã xảy ra
trong quá trình phát triển khi có quá nhiều trường hợp thử nghiệm
không thành công. Mặt khác, khi phải thiết kế quá nhiều trường hợp
thử nghiệm mới, nhóm kiểm thử hệ thống sẽ cố gắng hiểu điều gì đã
xảy ra trong giai đoạn lập kế hoạch kiểm thử. Hai loại sự kiện yêu
cầu các loại phản hồi khác nhau từ nhóm phát triển và nhóm kiểm tra
hệ thống, như được giải thích bên dưới.
Sẽ rất hữu ích khi cảnh báo cho nhóm phát triển khi số lượng trường
hợp thử nghiệm không thành công đạt đến mức xác định trước. Do
đó, các nhà phát triển thực hiện một hành động dưới dạng phân tích
nguyên nhân gốc rễ (RCA). Trong phân tích này, các nhà phát triển
nghiên cứu các thành phần phần mềm để xác định xem lỗi có nằm
trong mã mới, cũ, được viết lại hay được sửa lại hay không, được
thảo luận trong Chương 13. Tiếp theo, câu hỏi sau được đặt ra: Liệu
có thể phát hiện ra lỗi khiếm khuyết trong giai đoạn trước đó trong
chu kỳ phát triển, chẳng hạn như xem xét thiết kế, đánh giá mã, thử
nghiệm đơn vị hoặc thử nghiệm tích hợp? Nếu câu trả lời là có, thì
các hành động khắc phục được thực hiện bằng cách cập nhật đặc
điểm kỹ thuật thiết kế, xem xét mã và thêm các trường hợp thử
nghiệm mới để kiểm thử đơn vị và kiểm tra tích hợp để cải thiện chất
lượng của các thành phần phần mềm dễ xảy ra lỗi này. Phân tích lỗi
chi tiết được thảo luận trong Chương 13 thực hiện kiểm tra hệ thống.
Các kỹ sư kiểm thử có thể thấy cần thiết phải thiết kế các trường hợp
thử nghiệm mới khi việc thực thi thử nghiệm bộc lộ các khiếm
khuyết và những khiếm khuyết đó đã được khắc phục. Tổng số
trường hợp thử nghiệm tiếp tục tăng khi quá trình thử nghiệm tiếp
tục. Sự gia tăng đáng kể số lượng các trường hợp thử nghiệm ngụ ý
rằng việc lập kế hoạch ban đầu cho thiết kế thử nghiệm không chính
xác lắm và điều này có thể ảnh hưởng xấu đến lịch trình thực hiện
thử nghiệm. Ngoài ra, ban quản lý có thể muốn biết lý do số lượng
trường hợp thử nghiệm ban đầu thấp. Nhóm kiểm tra hệ thống bắt
đầu RCA khi tổng số trường hợp thử nghiệm mới được thiết kế vượt
qua một ngưỡng nhất định. Nhóm thử nghiệm nghiên cứu tất cả các
trường hợp thử nghiệm mới và phân loại chúng thành các nhóm khác
nhau dựa trên các yêu cầu chức năng. Tiếp theo, đặc tả chức năng
và / hoặc bất kỳ tài liệu liên quan nào khác được nghiên cứu để hiểu
tại sao nhóm kiểm thử không thể xác định mục tiêu của các trường
hợp thử nghiệm mới này ngay từ đầu.
Tiêu chí ExitCriteria Chúng ta biết khi nào một chu kỳ kiểm tra đã
hoàn thành bằng cách áp dụng một tiêu chí thoát. Việc thực thi tất cả
các trường hợp thử nghiệm trong một bộ thử nghiệm hoặc một tập
hợp con của chúng, không có nghĩa là một chu trình đã hoàn thành.
Cần phải giám sát một số chỉ số chất lượng liên quan đến chu kỳ
kiểm tra. Ví dụ về các số liệu này được giải thích chi tiết cho ba chu
kỳ thử nghiệm. Việc xác định các tiêu chí thoát ra của chu kỳ thử
nghiệm cuối cùng là một vấn đề phức tạp. Nó liên quan đến bản chất
của sản phẩm (ví dụ: ứng dụng bọc ngoài so với hệ điều hành), chiến
lược kinh doanh liên quan đến sản phẩm, cơ hội và thời gian tiếp thị,
cũng như yêu cầu của khách hàng, chỉ là một vài [10]. Tiêu chí rút lui
được xem xét ở đây có quan điểm rằng chất lượng là một thuộc tính
quan trọng và thời gian đưa ra thị trường với những phẩm chất mong
muốn là mục tiêu chính.
12.7.3 Chuẩn bị cho chu kỳ thử nghiệm đầu tiên
Bạn nên hiểu các khái niệm sau để sẵn sàng cho chu kỳ kiểm tra đầu
tiên: (i) các trạng thái khác nhau của một khuyết tật đã biết dưới dạng
một vòng đời từ trạng thái mới đến trạng thái đóng, (ii) việc chỉ định
các trường hợp thử nghiệm để kiểm tra kỹ sư và (iii) tiêu chí đầu vào
cho chúng tôi biết khi nào bắt đầu chu kỳ kiểm tra đầu tiên. Những
khái niệm này được giải thích dưới đây.
LifeCycleofaDefect Ý tưởng đằng sau việc đưa ra một mô hình vòng
đời cho các khiếm khuyết là có thể theo dõi chúng từ thời điểm
chúng được phát hiện đến khi chúng được đóng lại. Vòng đời của
một khuyết tật được biểu diễn bằng một biểu đồ chuyển đổi trạng
thái với năm trạng thái: mới, được chỉ định, mở, giải quyết và đóng.
Các trạng thái của khuyết tật được sử dụng trong mô tả của các chu
kỳ thử nghiệm riêng lẻ. Một khiếm khuyết được đưa vào trạng thái
mới bởi một kỹ sư thử nghiệm, được gọi là người gửi, ngay khi nó
được tiết lộ bởi một trường hợp thử nghiệm không thành công. Sau
khi một lỗi ở trạng thái mới được xem xét và được coi là một lỗi thực
sự, nó sẽ được chuyển sang trạng thái được chỉ định, có nghĩa là lỗi
đó đã được chỉ định cho một nhà phát triển phần mềm. Nhà phát triển
phần mềm chuyển lỗi từ trạng thái được chỉ định sang trạng thái mở
ngay sau khi họ bắt đầu khắc phục lỗi. Sau khi nhà phát triển hài lòng
bằng cách kiểm tra đơn vị rằng lỗi đã được sửa, lỗi sẽ được chuyển
sang trạng thái đã giải quyết. Người gửi xác minh bản sửa lỗi bằng
cách thực hiện các trường hợp thử nghiệm không thành công liên
quan đối với bản dựng mới do nhóm phát triển chuẩn bị sau khi lỗi
chuyển sang trạng thái đã giải quyết. Nếu người gửi hài lòng bằng
cách kiểm tra hệ thống rằng một khiếm khuyết trong trạng thái được
giải quyết đã thực sự được sửa, lỗi đó sẽ được chuyển sang trạng thái
đóng và các trường hợp thử nghiệm liên quan được tuyên bố là đã
vượt qua. Nếu không, lỗi được chuyển trở lại trạng thái mở và các
trường hợp thử nghiệm liên quan vẫn được coi là không đạt. Mô hình
chi tiết về vòng đời của khuyết tật được thảo luận trong Chương 13.
AssignmentofTestCases Vì không một kỹ sư nào sẽ tự mình thực
hiện tất cả các trường hợp thử nghiệm, nên bạn nên chỉ định các
trường hợp thử nghiệm cho các kỹ sư thử nghiệm thích hợp bằng
cách xem xét chuyên môn và sở thích của họ. Việc chỉ định các
trường hợp thử nghiệm cho các kỹ sư kiểm thử có thể được thay đổi
từ chu kỳ kiểm thử sang chu kỳ kiểm thử vì ba lý do: (i) khi một
trường hợp kiểm thử được giao cho một kỹ sư khác, trường hợp kiểm
thử có thể được thực hiện theo một góc độ khác; (ii) cơ hội học hỏi
điều gì đó mới tạo tác động tích cực đến tinh thần của nhân viên; và
(iii) kiến thức về các trường hợp kiểm thử được phân bổ khắp nhóm
kiểm thử, vì vậy nếu một kỹ sư kiểm thử tạm thời không có mặt cho
nhiệm vụ, rất dễ dàng tìm được người thay thế có năng lực.
EntryCriteriaforFirstTestCycle Tiêu chí đầu vào cho chu kỳ kiểm tra
đầu tiên, được đưa ra trong Bảng 12.3, cho chúng ta biết khi nào
chúng ta nên bắt đầu thực hiện các kiểm tra hệ thống. Tiêu chí bao
gồm năm nhóm phụ thuộc vào năm nhóm chức năng chéo: tiếp thị,
phần cứng, phần mềm, công bố kỹ thuật và thử nghiệm hệ thống.
Mỗi nhóm có một hoặc nhiều mục điều kiện để được thỏa mãn. Thử
nghiệm hệ thống không nên bắt đầu cho đến khi tất cả các nhóm của
tiêu chí đầu vào được thỏa mãn. Nếu không, tiêu chí hoàn nguyên có
thể được kích hoạt sớm hơn trong quá trình thực thi kiểm tra hệ
thống.
Nhóm đầu tiên của tiêu chí đầu vào liên quan đến việc hoàn thành kế
hoạch dự án. Nhóm tiếp thị cung cấp lý do kinh doanh cho sản phẩm
được đề xuất và các yêu cầu của nó. Nhóm kỹ sư xác định cách tiếp
cận phát triển, môi trường thực thi, lịch trình các mốc quan trọng và
các rủi ro có thể xảy ra liên quan, xác định các yếu tố phụ thuộc của
sản phẩm vào các yếu tố khác. Kế hoạch dự án phần mềm phải được
xem xét và phê duyệt bởi các nhóm xuất bản phần mềm, phần cứng,
tiếp thị và kỹ thuật trước khi bắt đầu thử nghiệm hệ thống.
Kiểm tra hệ thống có thể bao gồm phần cứng mới, và do đó, nhóm
thứ hai của tiêu chí đầu vào là kiểm tra đầy đủ bất kỳ hệ thống phần
cứng mới hoặc hệ thống con nào được sử dụng bởi hệ thống phần
mềm. Kết quả đạt và không đạt được từ việc thực thi các trường hợp
thử nghiệm không thể được coi là đáng tin cậy nếu không có cơ sở
phần cứng ổn định. Điều quan trọng là đảm bảo rằng phần cứng đã
trải qua ba giai đoạn sau: (i) lập kế hoạch và đặc tả; (ii) thiết kế, triển
khai nguyên mẫu và thử nghiệm; và (iii) tích hợp với hệ thống phần
mềm.
Nhóm thứ ba của tiêu chí đầu vào là về việc hoàn thành công việc
phát triển và kiểm thử của nhóm phát triển phần mềm. Nó bao gồm
bảy tiêu chí, cung cấp bằng chứng rằng hệ thống đủ ổn định để chịu
được sự nghiêm ngặt của việc kiểm tra hệ thống. Tính ổn định của
một hệ thống nên dựa trên các số liệu và bằng chứng, chứ không phải
là các tuyên bố từ người quản lý phần mềm để bắt đầu kiểm tra hệ
thống. Ví dụ: cần có tài liệu về trạng thái đạt và không đạt hàng tuần
của tất cả các trường hợp thử nghiệm đơn vị và tích hợp để xem xét.
Kiểm tra đơn vị và hệ thống
BẢNG 12.3 Tiêu chí đầu vào cho chu kỳ kiểm tra hệ thống đầu
tiên
Tập đoàn Tiêu chuẩn
1. Tiếp thị 1. Kế hoạch dự án và / hoặc tài liệu yêu cầu hệ
thống đã hoàn chỉnh và được cập nhật.
2. Phần cứng Tất cả các phiên bản phần cứng đã được phê
duyệt cho khu vực triển khai hiện trường đều
có sẵn trong nhà. Danh sách các phiên bản
phần cứng này sẽ được cung cấp.
Quá trình kiểm soát phiên bản phần cứng được
thực hiện và được lập thành tài liệu.
Kế hoạch DVT phần cứng đã hoàn thành và có
kết quả.
3. Phần mềm Tất cả các thông số kỹ thuật chức năng (FS) đã
hoàn chỉnh và đã được cập nhật để đồng bộ với
quá trình triển khai. Danh sách các FS riêng lẻ,
bao gồm số phiên bản và trạng thái, phải được
cung cấp.
Tất cả các thông số kỹ thuật thiết kế (DS) đã
hoàn chỉnh và đã được cập nhật để đồng bộ với
quá trình triển khai. Danh sách các DS, bao
gồm số phiên bản và trạng thái, phải được cung
cấp.
Tất cả mã hoàn thành và đóng băng; chỉ cho
phép thay đổi mã để sửa lỗi hoàn hảo chứ
không phải các tính năng.
Đã có kiểm soát phiên bản phần mềm.
100% bài kiểm tra đơn vị được thực hiện và
vượt qua.
100% kiểm tra tích hợp hệ thống được thực
hiện và vượt qua.
Không có nhiều hơn hai sự cố duy nhất đã
được quan sát thấy trong hai tuần thử nghiệm
tích hợp vừa qua.
4. Công bố kỹ 12. Có sẵn phiên bản nháp của hướng dẫn sử
thuật dụng.
5. Kiểm tra hệ Đã có kế hoạch kiểm tra hệ thống (đã được
thống xem xét và phê duyệt).
Tài liệu làm việc thực thi kiểm tra đã có sẵn và
hoàn tất.
báo cáo kiểm tra tích hợp phải được nhóm kiểm tra hệ thống xem xét
kỹ lưỡng trước khi bắt đầu chu kỳ kiểm tra đầu tiên.
Nhóm thứ tư của tiêu chí đầu vào liên quan đến sự sẵn sàng của các
hướng dẫn sử dụng do người viết kỹ thuật viết. Trừ khi các hướng
dẫn sử dụng đã sẵn sàng, các kỹ sư kiểm tra hệ thống sẽ không thể
xác minh tính chính xác và khả năng sử dụng.
Nhóm thứ năm của tiêu chí đầu vào liên quan đến kế hoạch kiểm tra
hệ thống. Các trường hợp kiểm thử chi tiết được bao gồm trong kế
hoạch kiểm thử. Người ta có thể ước tính chất lượng của phần mềm
sớm trong giai đoạn kiểm thử hệ thống [11] bằng cách ghi lại các
trường hợp kiểm thử. Kế hoạch kiểm tra hệ thống phải được xem xét
và phê duyệt bởi các nhóm xuất bản phần mềm, phần cứng, tiếp thị
và kỹ thuật trước khi bắt đầu kiểm tra hệ thống.
Các cuộc họp đánh giá giữa các chức năng phải được tiến hành để
theo dõi trạng thái của các tiêu chí sẵn sàng, nêu trong Bảng 12.3, ít
nhất bốn tuần trước khi bắt đầu chu kỳ thử nghiệm đầu tiên. Đại diện
của năm nhóm phải tham dự cuộc họp đánh giá chức năng chéo để
cung cấp tình trạng trong các lĩnh vực tương ứng của họ. Bất kỳ
trường hợp ngoại lệ nào đối với các tiêu chí này phải được lập thành
văn bản, thảo luận và thống nhất tại cuộc họp đánh giá tình trạng
chức năng chéo cuối cùng.
12.7.4 Lựa chọn các trường hợp thử nghiệm cho chu kỳ thử nghiệm
cuối cùng
Mặc dù mong muốn thực hiện lại tất cả các trường hợp thử nghiệm
trong chu kỳ thử nghiệm cuối cùng, việc thiếu thời gian và chi phí bổ
sung có thể không cho phép nhóm kiểm tra hệ thống làm như vậy.
Khái niệm kiểm thử hồi quy chỉ được áp dụng trong chu kỳ kiểm tra
cuối cùng. Theo cách tiếp cận của chúng tôi, các trường hợp kiểm
thử được chọn dựa trên (i) kết quả của việc thực hiện trước chúng;
(ii) tư cách thành viên của họ trong các nhóm thử nghiệm nhất định:
cơ bản, chức năng, tính mạnh mẽ, khả năng tương tác, căng thẳng,
khả năng mở rộng, hiệu suất, tải và ổn định; và (iii) sự liên kết của
chúng với các thành phần phần mềm đã được sửa đổi.
Các trường hợp thử nghiệm được chọn theo ba bước: Trong bước
đầu tiên, bộ thử nghiệm được chia thành bốn thùng khác nhau — đỏ,
vàng, xanh lá cây và trắng — dựa trên các tiêu chí nhất định được mô
tả trong quy trình lựa chọn được đưa ra dưới đây. Thùng màu đỏ
được sử dụng để chứa các trường hợp kiểm thử phải được thực thi.
Thùng màu vàng được sử dụng để chứa các trường hợp thử nghiệm
hữu ích để thực thi. Thùng màu xanh lá cây được sử dụng để chứa
các trường hợp thử nghiệm sẽ không thêm bất kỳ giá trị nào cho thử
nghiệm hồi quy và do đó có thể được bỏ qua. Phần còn lại của các
trường hợp thử nghiệm được bao gồm trong thùng màu trắng. Nói
cách khác, các trường hợp thử nghiệm mà không thể đưa ra quyết
định cụ thể nào trong bước đầu tiên được đưa vào thùng màu trắng.
Trong bước thứ hai, các trường hợp thử nghiệm từ thùng trắng được
chuyển sang các thùng khác bằng cách xem xét các thành phần phần
mềm đã được sửa đổi trong quá trình thử nghiệm hệ thống và các
trường hợp thử nghiệm được liên kết với các thành phần đó. Cuối
cùng, trong bước thứ ba, các thùng màu đỏ và vàng được chọn để
kiểm tra hồi quy. Sau đây, chúng tôi trình bày quy trình lựa chọn thử
nghiệm:
Bước 1: Bộ thử nghiệm được chia thành các thùng màu đỏ,
vàng, xanh lá cây và trắng như sau:
Màu đỏ: Thùng màu đỏ chứa các loại trường hợp thử nghiệm sau
đây phải được thực thi:
Các trường hợp thử nghiệm không thành công ít nhất một lần trong
các chu kỳ thử nghiệm trước.
Các trường hợp thử nghiệm từ các nhóm thử nghiệm mà RCA đã
được nhóm phát triển thực hiện trong các chu kỳ thử nghiệm trước
đó.
Các trường hợp thử nghiệm từ các nhóm thử nghiệm ứng suất, khả
năng mở rộng và tải và độ ổn định. Các trường hợp thử nghiệm này
có nhiều khả năng tiết lộ các lỗi hỏng hóc của hệ thống. Chúng được
chọn để đảm bảo rằng bản dựng cuối cùng ổn định và xác suất hệ
thống gặp sự cố tại trang web của khách hàng là cực kỳ thấp.
Các trường hợp kiểm thử từ danh mục kiểm tra hiệu suất. Đặc tính
hiệu suất phải được đo lường dựa trên bản dựng cuối cùng sẽ được
phát hành cho khách hàng.
Màu vàng: Thùng màu vàng chứa các trường hợp thử nghiệm hữu
ích để thực thi. Thùng này bao gồm những trường hợp thử nghiệm có
mục tiêu tương tự với mục tiêu của các trường hợp thử nghiệm trong
thùng màu đỏ. Ví dụ: để một trường hợp kiểm tra với mục tiêu sau ở
trong thùng màu đỏ: Trong khi quá trình nâng cấp phần mềm đang
diễn ra, mức sử dụng CPU không được vượt quá 60%. Sau đó, một
trường hợp thử nghiệm với vật kính sau được đặt vào thùng màu
vàng: Xác minh rằng hình ảnh phần mềm có thể được nâng cấp lên
bản phát hành thứ n từ bản phát hành thứ (n - 1 ) trong vòng chưa
đầy 300 giây. Điều kiện, nghĩa là sử dụng CPU dưới 60%, cho chúng
ta biết khi nào cần thực hiện kiểm tra nâng cấp.
Màu xanh lá cây: Thùng màu xanh lá cây chứa các trường hợp thử
nghiệm sẽ không thêm bất kỳ giá trị nào vào thử nghiệm hồi quy và
do đó có thể bị bỏ qua. Thùng này bao gồm những trường hợp thử
nghiệm có các mục tiêu được bao phủ ngầm bởi việc thực hiện các
trường hợp thử nghiệm trong các thùng màu đỏ và vàng. Ví dụ: nếu
một trường hợp thử nghiệm với mục tiêu “Xác minh rằng một hình
ảnh phần mềm có thể được nâng cấp lên bản phát hành thứ n từ bản
phát hành thứ (n - 1 ) trong vòng chưa đầy 300 giây” nằm trong ngăn
màu vàng, thì trường hợp thử nghiệm cơ bản với mục tiêu “Phần
mềm có thể được nâng cấp lên bản phát hành thứ n từ bản phát hành
thứ (n - 1 ) ” được bao gồm trong thùng màu xanh lá cây.
Màu trắng: Các trường hợp thử nghiệm không thể đưa ra quyết định
cụ thể trong bước đầu tiên được bỏ vào thùng màu trắng. Điều này
bao gồm phần còn lại của các trường hợp thử nghiệm không rơi vào
thùng màu đỏ, vàng hoặc xanh lá cây.
Bước Các trường hợp kiểm thử từ thùng trắng được chuyển sang
2: các thùng khác bằng cách xem xét các thành phần phần mềm
đã được sửa đổi trong quá trình thử nghiệm hệ thống và các
trường hợp thử nghiệm được liên kết với các thành phần đó.
Các nhà phát triển phần mềm xác định tất cả các thành phần
phần mềm đã được sửa đổi sau khi bắt đầu chu kỳ thử
nghiệm đầu tiên. Mỗi trường hợp thử nghiệm từ thùng trắng
được ánh xạ tới các thành phần phần mềm đã xác định. Việc
ánh xạ này được thực hiện bằng cách phân tích mục tiêu của
trường hợp thử nghiệm và sau đó kiểm tra xem mã đã sửa
đổi của các thành phần phần mềm được xác định có được
thực thi bằng cách thực hiện các trường hợp thử nghiệm hay
không. Các trường hợp thử nghiệm được ánh xạ tới nhiều
hơn một, một hoặc không thành phần phần mềm sẽ được
chuyển tương ứng vào ngăn màu đỏ, vàng hoặc xanh lá cây.
Bước Các trường hợp kiểm tra từ các thùng màu đỏ và vàng được
3: chọn để kiểm tra hồi quy như sau:
Tất cả các trường hợp thử nghiệm từ thùng màu đỏ được chọn cho
chu kỳ thử nghiệm cuối cùng.
Tùy thuộc vào lịch trình, thời gian đưa ra thị trường và nhu cầu của
khách hàng, các trường hợp thử nghiệm từ thùng màu vàng được
chọn cho chu kỳ thử nghiệm cuối cùng.
Nhận xét 2. Sẽ rất hữu ích nếu bạn hiểu chiến lược lựa chọn được
giải thích ở trên. Thùng màu đỏ chứa các trường hợp thử nghiệm
phải được chọn trong chu kỳ thử nghiệm cuối cùng. Các trường hợp
thử nghiệm thuộc danh mục “phải thực thi” là (i) các trường hợp thử
nghiệm đã thất bại trong các chu kỳ thử nghiệm trước đó; (ii) các
trường hợp thử nghiệm từ các nhóm mà RCA đã được thực hiện
trong các chu kỳ thử nghiệm trước đó; (iii) các trường hợp thử
nghiệm từ các nhóm thử nghiệm ứng suất, khả năng mở rộng, và tải
và độ ổn định; và (iv) các trường hợp kiểm thử liên quan đến các
thành phần phần mềm đã được sửa đổi. Chúng tôi nhắc người đọc
rằng RCA cho một nhóm thử nghiệm được thực hiện nếu có quá
nhiều trường hợp thử nghiệm không thành công từ nhóm đó. Chúng
tôi nhấn mạnh vào một nhóm thử nghiệm bằng cách chọn các trường
hợp thử nghiệm của nó trong chu kỳ thử nghiệm cuối cùng. Các
trường hợp thử nghiệm từ các nhóm ứng suất, khả năng mở rộng, tải
và độ ổn định cũng được bao gồm trong chu kỳ thử nghiệm cuối
cùng theo mặc định, ngay cả khi các trường hợp thử nghiệm đó có
thể không liên quan đến các thành phần được sửa đổi. Cơ sở lý luận
cho việc đưa chúng vào là người ta phải kiểm tra lần cuối về các khía
cạnh căng thẳng, khả năng mở rộng, tải và ổn định của hệ thống phần
mềm — chẳng hạn như máy chủ, bộ định tuyến Internet và trạm cơ
sở trong giao tiếp không dây — có khả năng phục vụ hàng nghìn
người dùng cuối.
12.7.5 Ưu tiên các trường hợp thử nghiệm
Ưu tiên các trường hợp kiểm thử có nghĩa là ra lệnh thực hiện các
trường hợp kiểm thử theo các mục tiêu kiểm thử nhất định. Việc hình
thành các mục tiêu kiểm thử để ưu tiên các trường hợp kiểm thử
riêng lẻ là một nhiệm vụ cực kỳ khó khăn. Ở đây, chúng ta thảo luận
về mức độ ưu tiên kiểm thử theo nhóm các trường hợp kiểm thử có
các thuộc tính chung. Một ví dụ về mục tiêu kiểm tra để ưu tiên là:
Thực hiện số lượng trường hợp kiểm tra tối đa mà không bị chặn.
Hơn nữa, mối quan tâm lớn của các nhà phát triển phần mềm là các
kỹ sư kiểm tra báo cáo các lỗi nghiêm trọng (ví dụ, các lỗi liên quan
đến sự cố hệ thống) vào cuối chu kỳ kiểm tra. Điều này không giúp
họ có đủ thời gian để sửa chữa những khiếm khuyết đó. Ngoài ra, các
lỗi chặn cần phải được sửa sớm hơn trong các chu kỳ thử nghiệm để
thực hiện các trường hợp thử nghiệm bị chặn. Do đó, chúng ta cần ưu
tiên thực hiện các bài kiểm tra để phát hiện sớm các khiếm khuyết
nghiêm trọng trong các chu kỳ kiểm tra. Trong chiến lược thực thi
thử nghiệm dựa trên đa chu kỳ, mong muốn có các mục tiêu thử
nghiệm khác nhau để ưu tiên trong các chu kỳ thử nghiệm khác nhau
vì ba lý do: (i) ban đầu mức chất lượng của hệ thống được thử
nghiệm không cao lắm, (ii) chất lượng của hệ thống liên tục cải tiến
từ chu kỳ thử nghiệm này sang chu kỳ thử nghiệm khác, và (iii) một
loạt các khiếm khuyết được phát hiện khi quá trình thử nghiệm tiến
triển. Dưới đây, chúng tôi giải thích mức độ ưu tiên thử nghiệm trong
các chu kỳ thử nghiệm riêng lẻ.
Ưu tiên Kiểm tra trong Chu kỳ Kiểm tra 1
Nguyên tắc. Ưu tiên các trường hợp kiểm thử để cho phép số lượng
tối đa các trường hợp kiểm thử thực thi hoàn toàn mà không bị chặn.
Các kỹ sư kiểm thử thực hiện các trường hợp thử nghiệm được chỉ
định của họ trong các môi trường thử nghiệm khác nhau. Mỗi kỹ sư
ưu tiên thực hiện tập hợp con các trường hợp thử nghiệm của họ như
sau:
Mức độ ưu tiên cao được chỉ định cho các trường hợp thử nghiệm
trong nhóm thử nghiệm cơ bản và chức năng.
Ưu tiên trung bình được chỉ định cho các nhóm kiểm tra tính mạnh
mẽ và khả năng tương tác.
Mức độ ưu tiên thấp được chỉ định cho các trường hợp thử nghiệm
trong các nhóm sau: tài liệu, hiệu suất, ứng suất, khả năng mở rộng
và thử nghiệm tải và độ ổn định.
Các bài kiểm tra cơ bản cung cấp bằng chứng sơ khai rằng hệ thống
đã sẵn sàng cho các bài kiểm tra nghiêm ngặt hơn. Các bài kiểm tra
chức năng cung cấp một bài kiểm tra toàn diện trên toàn bộ các yêu
cầu trong khả năng của hệ thống. Cả hai nhóm thử nghiệm này đều
được ưu tiên cao trong chu kỳ thử nghiệm đầu tiên để đảm bảo rằng
mọi lỗi chức năng đều được khắc phục trước. Các khiếm khuyết về
chức năng có thể cản trở việc thực hiện của nhóm thử nghiệm khác.
Các bài kiểm tra độ căng, hiệu suất, khả năng mở rộng, tải và độ ổn
định cần có cấu hình phức tạp trên các nền tảng, hệ điều hành và hệ
quản trị cơ sở dữ liệu khác nhau. Việc thực hiện các bài kiểm tra này
phụ thuộc vào kết quả của các bài kiểm tra khả năng tương tác và độ
bền. Do đó, các trường hợp kiểm tra khả năng tương tác và độ bền
được thực hiện bên cạnh để loại bỏ bất kỳ vấn đề nào có thể cản trở
việc thực hiện các bài kiểm tra căng thẳng, hiệu suất, khả năng mở
rộng, tải và độ ổn định.
Nguyên tắc. Các trường hợp thử nghiệm không thành công trong chu
kỳ thử nghiệm trước được thực hiện sớm trong chu kỳ thử nghiệm.
Trong chu kỳ thử nghiệm thứ hai, các trường hợp thử nghiệm được
chỉ định lại cho các kỹ sư thử nghiệm dựa trên sự quan tâm và
chuyên môn của họ. Quy trình được mô tả trong Phần 12.7.4 được sử
dụng để phân phối tất cả các trường hợp thử nghiệm vào ba thùng
khác nhau: đỏ, vàng và xanh lá cây. Trong bước này, chúng tôi
không chọn một tập hợp con của bộ thử nghiệm. Thay vào đó, ý
tưởng phân vùng một bộ thử nghiệm được sử dụng nhiều hơn trong
việc ưu tiên các trường hợp thử nghiệm. Mỗi kỹ sư kiểm thử ưu tiên
thực hiện các trường hợp kiểm thử trong tập hợp con của họ như sau:
trong thùng màu đỏ.
Mức độ ưu tiên trung bình được chỉ định cho các trường hợp thử
nghiệm trong thùng màu vàng.
trong thùng màu xanh lá cây.
Nguyên tắc. Mức độ ưu tiên kiểm tra tương tự như trong chu kỳ
kiểm tra thứ hai, nhưng nó được áp dụng cho một tập hợp con được
chọn của các trường hợp kiểm thử được chọn để kiểm tra hồi quy.
Một lần nữa, các trường hợp thử nghiệm được chỉ định lại dựa trên
sự quan tâm và chuyên môn giữa các kỹ sư thử nghiệm. Sau đó, mỗi
kỹ sư kiểm thử ưu tiên thực hiện các trường hợp kiểm thử trong tập
hợp con được chỉ định của họ như sau:
trong thùng màu đỏ.
trong thùng màu vàng.
Người đọc có thể nhớ lại từ thảo luận của Phần 12.7.4 rằng các
trường hợp thử nghiệm trong thùng màu xanh lá cây không được
thực thi trong chu kỳ thử nghiệm cuối cùng.
12.7.6 Chi tiết về ba chu kỳ thử nghiệm
Khi chúng tôi chuyển từ chu kỳ thử nghiệm sang chu kỳ thử nghiệm,
các trường hợp thử nghiệm mới có thể được bao gồm và tiêu chí
hoàn nguyên và tiêu chí thoát được thực hiện nghiêm ngặt hơn để
chất lượng của hệ thống được cải thiện, thay vì xấu đi khi quá trình
thử nghiệm tiến triển. Lưu ý rằng chúng tôi đã đưa ra các giá trị của
các tham số trong một chu kỳ thử nghiệm. Các giá trị cụ thể được sử
dụng trong các chu kỳ thử nghiệm có thể tùy chỉnh theo khả năng và
nhu cầu thử nghiệm của tổ chức. Các giá trị được sử dụng trong bài
báo là các giá trị thực tế được sử dụng trong các dự án thử nghiệm
thực tế. Chúng tôi đã sử dụng các giá trị cụ thể trong mô tả các chu
kỳ thử nghiệm để làm cho các mô tả có ý nghĩa và có thể quan sát sự
cải thiện chất lượng từ chu kỳ thử nghiệm đến chu kỳ thử nghiệm.
Chu kỳ kiểm tra 1 Trong chu kỳ này, chúng tôi cố gắng phát hiện
hầu hết các lỗi bằng cách thực hiện tất cả các trường hợp kiểm thử.
Sáu thông số đặc trưng của chu kỳ thử nghiệm đầu tiên được mô tả
như sau.
Mục tiêu Chúng tôi dự định thực hiện tất cả các trường hợp thử
nghiệm từ bộ thử nghiệm và tối đa hóa số trường hợp thử nghiệm
được thông qua. Mục tiêu là đảm bảo rằng 98% các trường hợp thử
nghiệm đã vượt qua.
Giả định Nhóm kiểm tra hệ thống chấp nhận một hình ảnh phần mềm
mỗi tuần một lần trong bốn tuần đầu tiên và hai tuần một lần sau đó.
Khả năng một số trường hợp thử nghiệm bị chặn là nhiều hơn trong
bốn tuần đầu tiên của chu kỳ thử nghiệm vì các lỗi ưu tiên 1 (“quan
trọng”) được báo cáo sớm hơn trong chu kỳ thử nghiệm do việc thực
hiện các trường hợp thử nghiệm có mức độ ưu tiên cao hơn. Trừ khi
những khiếm khuyết này được giải quyết nhanh chóng, tốc độ thực
hiện kiểm tra có thể chậm lại. Do đó, việc chấp nhận hình ảnh phần
mềm mới hàng tuần là rất hữu ích. Chúng tôi đã quan sát thấy rằng
hình ảnh phần mềm trở nên ổn định hơn sau bốn tuần và quá trình
thực thi thử nghiệm không bị chặn. Sau đó, nhóm kiểm tra hệ thống
có thể chấp nhận hình ảnh phần mềm hai tuần một lần.
TestExecution Các trường hợp kiểm tra được thực thi theo chiến lược
ưu tiên cho chu kỳ kiểm tra này được giải thích trong Phần 12.7.5.
RevertandExtensionCriteria Về cơ bản, nếu số trường hợp thử
nghiệm không thành công đạt đến 20% tổng số trường hợp thử
nghiệm được thực thi, nhóm kiểm tra hệ thống sẽ bỏ qua chu kỳ thử
nghiệm này. Chu kỳ kiểm tra được bắt đầu lại khi nhóm phát triển
tuyên bố rằng các lỗi đã được khắc phục. Giả sử rằng có 1000 trường
hợp kiểm thử được thực thi. Nếu nhóm kiểm tra hệ thống quan sát
thấy 200 trường hợp thử nghiệm, tức là 20% trong số 1000 trường
hợp đầu tiên, chẳng hạn như 700 trường hợp thử nghiệm đã không
thành công, thì sẽ không có điểm nào để tiếp tục chu trình thử
nghiệm. Điều này là do chất lượng của sản phẩm quá thấp, và bất kỳ
thử nghiệm nào nữa trước khi các khuyết tật được khắc phục đều là
lãng phí nguồn lực thử nghiệm. Nếu quan sát thấy nhiều hơn hai sự
cố duy nhất trong chu kỳ thử nghiệm, nhóm thử nghiệm hệ thống sẽ
chạy thử nghiệm hồi quy sau khi các lỗi sự cố được khắc phục. Nếu
số lượng trường hợp thử nghiệm không thành công cho bất kỳ nhóm
trường hợp thử nghiệm nào, chẳng hạn như chức năng, hiệu suất và
khả năng mở rộng, đạt đến 20% số trường hợp thử nghiệm trong
nhóm trong chu kỳ thử nghiệm, thì nhóm thử nghiệm hệ thống sẽ
thực thi lại tất cả các trường hợp thử nghiệm trong nhóm đó trong
chu kỳ này sau khi các khuyết tật được cho là đã được sửa chữa. Do
đó, thời gian của chu kỳ thử nghiệm được kéo dài. Tương tự, nếu số
lượng các trường hợp thử nghiệm mới tăng 10% trong số các trường
hợp thử nghiệm hệ thống, chu kỳ thử nghiệm được mở rộng để ghi
lại các trường hợp thử nghiệm bổ sung.
Hành động Nhóm phát triển phần mềm khởi tạo RCA trong chu kỳ
thử nghiệm nếu tổng số trường hợp thử nghiệm không thành công đạt
đến một số giá trị đặt trước như trong Bảng 12.4. Ví dụ: nếu 25% của
tất cả các trường hợp thử nghiệm được thực thi không thành công
trong một tuần từ một nhóm duy nhất, thì nhóm phát triển sẽ thực
hiện RCA. Nhóm thử nghiệm hệ thống bắt đầu RCA nếu số lượng
trường hợp thử nghiệm mới tăng 10% tổng số trường hợp thử nghiệm
được thiết kế trước khi bắt đầu chu kỳ thử nghiệm.
BẢNG 12.4 Số lượng trường hợp thử nghiệm không thành
công để bắt đầu RCA trong chu kỳ thử nghiệm 1
Số lượng lỗi trường hợp thử nghiệm (%)

Số tuần tích
Tuần lễ độc thân
lũy
Nhóm thử nghiệm 25 20

đơn
Tất cả các nhóm thử 20 15
nghiệm
ExitCriteria Chu kỳ kiểm thử được coi là đã hoàn thành khi các vị từ
sau đây giữ được: (i) các trường hợp thử nghiệm mới được thiết kế
và lập thành văn bản cho những khiếm khuyết mà trường hợp thử
nghiệm hiện có không phát hiện được, được gọi là trường hợp thử
nghiệm thoát; (ii) tất cả các trường hợp kiểm thử được thực hiện ít
nhất một lần; (iii) 95% trường hợp thử nghiệm vượt qua; và (iv) tất
cả các khuyết tật đã biết đều ở trạng thái đóng.
Nhận xét 3. Việc thoát trường hợp kiểm thử xảy ra do thiếu sót trong
quá trình thiết kế kiểm thử. Chúng được xác định khi các kỹ sư kiểm
tra tìm thấy khuyết tật hoặc khi họ gặp phải các điều kiện không
được mô tả trong kế hoạch. Điều này xảy ra một cách tình cờ hoặc
khi một kịch bản thử nghiệm mới xảy ra để kiểm tra các kỹ sư trong
khi thực hiện các trường hợp kiểm thử đã lên kế hoạch. Khi các kỹ sư
kiểm tra tìm hiểu thêm về sản phẩm, họ phát triển các cách sáng tạo
để kiểm tra sản phẩm và tìm ra các khiếm khuyết mới. Những trường
hợp thử nghiệm này đã thoát khỏi nỗ lực thiết kế trường hợp thử
nghiệm, còn được gọi là tác dụng phụ [12].
Nhận xét 4. Một nhóm phát triển phần mềm có thể mất nhiều thời
gian hơn để sửa chữa các lỗi gây ra lỗi của 5% trường hợp kiểm thử.
Trong trường hợp đó, không có điểm nào để chờ khắc phục và trì
hoãn vô thời hạn việc hoàn thành chu kỳ thử nghiệm đầu tiên cho đến
khi có thêm 3% trường hợp thử nghiệm vượt qua để đạt được mục
tiêu đã nêu trong số 98% trường hợp thử nghiệm đã vượt qua được
đề ra cho lần thử nghiệm đầu tiên đi xe đạp. Thực tế là trường hợp
một số lỗi cần nhiều thời gian hơn để được sửa và một số bị hoãn lại
cho đến khi phát hành phần mềm tiếp theo. Nên thoát khỏi chu kỳ
kiểm tra đầu tiên để bắt đầu chu kỳ thứ hai nhằm sử dụng hiệu quả và
hiệu quả các nguồn lực. Trong mọi trường hợp, chiến lược của chúng
tôi trong chu kỳ thử nghiệm thứ hai là thực hiện tất cả các trường hợp
thử nghiệm, bao gồm cả 5% trường hợp thử nghiệm không thành
công.
Chu kỳ kiểm tra 2 Các bản sửa lỗi được tìm thấy trong chu kỳ kiểm
tra đầu tiên được xác minh trong chu kỳ kiểm tra thứ hai. Một trong
bốn khả năng xảy ra đối với mỗi sửa đổi trong khi sửa chữa một
khiếm khuyết: (i) khiếm khuyết được sửa mà không đưa ra một
khiếm khuyết mới; (ii) khiếm khuyết đã được sửa chữa, nhưng một
cái gì đó đang hoạt động bị hỏng; (iii) khuyết tật không được sửa
chữa cũng như không đưa ra các khuyết tật mới; và (iv) khiếm
khuyết không được sửa chữa, nhưng một cái gì đó khác bị hỏng. Hơn
nữa, tất cả các tiêu chí đầu vào có thể không được thỏa mãn trước khi
bắt đầu chu kỳ thử nghiệm đầu tiên, điều này có thể được giải quyết
bởi các nhóm chức năng chéo trong quá trình thực hiện chu kỳ thử
nghiệm đầu tiên. Đôi khi, một khách hàng khó tính có thể yêu cầu
đăng ký tính năng vào phút cuối trước khi bắt đầu chu kỳ thử nghiệm
thứ hai; nếu không, khách hàng sẽ không triển khai sản phẩm. Nên
thực hiện lại mọi trường hợp thử nghiệm trong chu kỳ thử nghiệm
thứ hai để đảm bảo rằng những thay đổi đó không ảnh hưởng xấu đến
chất lượng của phần mềm do những điểm không chắc chắn đó. Sáu
thông số đặc trưng của chu kỳ thử nghiệm thứ hai được mô tả dưới
đây.
Mục tiêu Tất cả các trường hợp thử nghiệm được thực hiện lại một
lần nữa để đảm bảo rằng không có thiệt hại tài sản đảm bảo nào do
các bản sửa lỗi được áp dụng trong chu kỳ thử nghiệm đầu tiên. Số
lượng trường hợp thử nghiệm đã vượt qua là tối đa, đảm bảo rằng
99% trường hợp thử nghiệm đã vượt qua vào cuối chu kỳ thử nghiệm
thứ hai.
Giả định Nhóm kiểm tra hệ thống chấp nhận hình ảnh phần mềm hai
tuần một lần. Điều này là do hệ thống tương đối ổn định sau khi trải
qua chu kỳ thử nghiệm đầu tiên.
RevertandExtensionCriteria Tại bất kỳ thời điểm nào trong chu kỳ
thử nghiệm, nếu tổng số trường hợp thử nghiệm không thành công
đạt đến 10% tổng số trường hợp thử nghiệm sẽ được thực hiện, nhóm
kiểm tra hệ thống sẽ ngừng thử nghiệm. Chu kỳ kiểm tra được khởi
động lại từ đầu sau khi nhóm phát triển tuyên bố rằng các lỗi đã được
khắc phục. Nếu quan sát thấy nhiều hơn một sự cố duy nhất trong
chu kỳ thử nghiệm này, nhóm thử nghiệm hệ thống sẽ chạy thử
nghiệm hồi quy sau khi các lỗi sự cố được khắc phục. Điều này có
nghĩa là thời gian của chu kỳ thử nghiệm được kéo dài. Nếu số lượng
trường hợp thử nghiệm không thành công đạt đến 10% tổng số lần
thử nghiệm trong một nhóm trong chu kỳ thử nghiệm, thì nhóm thử
nghiệm hệ thống thực hiện lại tất cả các trường hợp thử nghiệm từ
nhóm đó trong chu kỳ thử nghiệm này sau khi các lỗi được xác nhận
là đã được khắc phục. Do đó, thời gian của chu kỳ thử nghiệm cần
được kéo dài. Chu kỳ kiểm thử được mở rộng để ghi lại các trường
hợp thử nghiệm bổ sung nếu số lượng trường hợp thử nghiệm mới
tăng 5% tổng số trường hợp thử nghiệm.
Hành động Nhóm phát triển phần mềm khởi tạo RCA trong chu kỳ
kiểm tra nếu số lượng các trường hợp kiểm thử không thành công đạt
đến một số giá trị đặt trước như được trình bày trong Bảng 12.5. Ví
dụ: nếu 15% của tất cả các trường hợp thử nghiệm được thực thi
trong một tuần từ một nhóm duy nhất không thành công, thì nhóm
phát triển sẽ thực hiện RCA.
Nhóm thử nghiệm hệ thống bắt đầu RCA nếu số lượng trường hợp
thử nghiệm mới tăng lên 5% trên tổng số trường hợp thử nghiệm
trước khi bắt đầu chu kỳ thử nghiệm thứ hai. Giải thích cụ thể được
đưa ra nếu các trường hợp thử nghiệm mới được thêm vào trong chu
kỳ thử nghiệm đầu tiên và các trường hợp thử nghiệm mới cũng được
thêm vào trong chu kỳ thử nghiệm thứ hai.
BẢNG 12.5 Số lần lỗi trường hợp thử nghiệm để bắt đầu RCA
trong chu kỳ thử nghiệm 2
Số lượng lỗi trường hợp thử nghiệm (%)

Số tuần tích
Tuần lễ độc thân
lũy
Nhóm thử nghiệm 15 10
đơn
Tất cả các nhóm thử 10 5
nghiệm
ExitCriteria Chu kỳ kiểm thử được coi là đã hoàn thành khi giữ
nguyên sau: (i) các trường hợp thử nghiệm mới được thiết kế và lập
thành văn bản cho những khiếm khuyết mà trường hợp thử nghiệm
hiện có không phát hiện được, (ii) tất cả các trường hợp thử nghiệm
được thực thi ít nhất một lần, ( iii) 98% trường hợp thử nghiệm vượt
qua, và (iv) tất cả các khuyết tật đã biết đều ở trạng thái đóng.
Nhận xét 5. Một trong những tiêu chuẩn thoát ra là 98% các trường
hợp thử nghiệm phải vượt qua, cao hơn so với chu kỳ thử nghiệm
đầu tiên. Một lần nữa, các kỹ sư thử nghiệm không có lý do gì để chờ
các bản sửa lỗi và hoãn vô thời hạn việc hoàn thành chu kỳ thử
nghiệm thứ hai cho đến khi vượt qua được 1% trường hợp thử
nghiệm không thành công khác để đạt được mục tiêu vượt qua 99%
đã đặt ra trước khi bắt đầu chu kỳ thử nghiệm thứ hai.
Chu kỳ thử nghiệm 3 Trong chu kỳ thử nghiệm thứ ba và cuối
cùng, một tập hợp con các trường hợp thử nghiệm đã chọn của bộ thử
nghiệm gốc sẽ được thực thi lại để đảm bảo rằng phần mềm ổn định
trước khi nó được phát hành cho khách hàng. Mục tiêu của chu kỳ
kiểm thử này là thực hiện tất cả các trường hợp kiểm thử đã chọn dựa
trên một hình ảnh phần mềm duy nhất.
Mục tiêu Một tập hợp con các trường hợp thử nghiệm đã chọn từ bộ
thử nghiệm được thực thi lại. Quá trình lựa chọn các trường hợp
kiểm thử cho chu kỳ kiểm thử này đã được giải thích trong Phần
12.7.4. Vào cuối chu kỳ, phần mềm được phát hành cho khách hàng.
Do đó, 100% các trường hợp thử nghiệm được chọn sẽ vượt qua.
Giả định Nhóm kiểm tra hệ thống chỉ chấp nhận một hình ảnh phần
mềm ở đầu chu kỳ kiểm tra. Trong các trường hợp ngoại lệ, nhóm
thử nghiệm hệ thống có thể chấp nhận hình ảnh thứ hai trong chu kỳ
này, nhưng không được ít hơn ba tuần trước khi kết thúc chu kỳ thử
nghiệm.
RevertandExtensionCriteria Tại bất kỳ thời điểm nào trong chu kỳ
thử nghiệm, nếu tổng số trường hợp thử nghiệm không thành công
vượt quá 5% tổng số trường hợp thử nghiệm được thực hiện, nhóm
kiểm tra hệ thống sẽ ngừng thử nghiệm. Quá trình thử nghiệm cũng
bị dừng nếu quan sát thấy một sự cố duy nhất. Chu kỳ kiểm tra bắt
đầu lại từ đầu sau khi nhóm phát triển tuyên bố rằng các lỗi đã được
khắc phục, vì đây là chu kỳ kiểm tra cuối cùng trước khi phát hành.
Tất cả các trường hợp thử nghiệm đã chọn cần phải được thực thi lại
để đảm bảo rằng không có thiệt hại tài sản thế chấp do việc sửa chữa.
Do đó chu kỳ thử nghiệm này có thể được kết thúc và khởi động lại
lần nữa, nhưng không được kéo dài.
ExitCriteria Chu kỳ kiểm tra cuối cùng được coi là đã hoàn thành nếu
tất cả các vị từ này giữ: (i) tất cả các trường hợp kiểm tra đã chọn
được thực thi; (ii) có sẵn kết quả của tất cả các bài kiểm tra; (iii) 98%
trường hợp thử nghiệm vượt qua; (iv) 2% trường hợp thử nghiệm
không thành công không được từ các nhóm thử nghiệm căng thẳng,
hiệu suất, khả năng mở rộng và tải và độ ổn định; (v) hệ thống không
gặp sự cố trong ba tuần thử nghiệm cuối cùng; và (vi) báo cáo thử
nghiệm đã hoàn thành và được phê duyệt. Báo cáo thử nghiệm tóm
tắt thử nghiệm
12.8 ƯỚC LƯỢNG NỖ LỰC THỬ NGHIỆM 519
kết quả của cả ba chu kỳ thử nghiệm, đặc tính hoạt động, giới hạn
mở rộng quy mô (nếu có), quan sát độ ổn định và khả năng tương tác
của hệ thống.
Nhận xét 6. Một trong những tiêu chí thoát ra là 98% các trường hợp
kiểm thử phải vượt qua trong chu kỳ kiểm tra thứ ba. Người ta có thể
hỏi: Tại sao nó không phải là 100%? Đây là mục tiêu được đặt ra
trước khi bắt đầu chu kỳ thử nghiệm thứ ba. Cần lưu ý rằng các tiêu
chí thoát ra của chu kỳ thử nghiệm cuối cùng bị ảnh hưởng bởi sự
đánh đổi giữa thời gian, chi phí và chất lượng. Như Yourdon [13] đã
lập luận, đôi khi ít hơn hoàn hảo là đủ tốt. Chỉ các mục tiêu kinh
doanh và mức độ ưu tiên mới xác định được mức độ thấp hơn mức
hoàn hảo có thể chấp nhận được. Cuối cùng, các tiêu chí rút lui phải
liên quan đến các mục tiêu kinh doanh của tổ chức. Tiêu chí xuất
cảnh nói chung không chỉ dựa trên chất lượng; thay vào đó, họ xem
xét sự đổi mới và tính kịp thời của sản phẩm được tung ra thị trường.
Tất nhiên, đối với bất kỳ ứng dụng quan trọng nào, tỷ lệ vượt qua các
trường hợp kiểm tra hệ thống phải là 100%.
Kinh nghiệm của chúng tôi cho chúng tôi biết rằng ít hơn ba chu kỳ
kiểm tra là không đủ tốt để mang lại cho chúng tôi nhiều niềm tin
vào một hệ thống phần mềm lớn trừ khi mọi thứ hoạt động hoàn hảo
như kế hoạch — đây là một trường hợp hiếm. Bởi "sự hoàn hảo",
chúng tôi có nghĩa là (i) sản phẩm không thay đổi ngoài các bản sửa
lỗi, (iii) các bản sửa lỗi hoạt động như dự kiến và (iii) các kỹ sư thử
nghiệm không thêm bất kỳ trường hợp thử nghiệm mới nào. Hiếm
khi ba điều kiện này được thỏa mãn. Nhiều hơn ba chu kỳ thử
nghiệm có thể được lên lịch với các tiêu chí thoát thích hợp về việc
tăng tỷ lệ phần trăm các trường hợp thử nghiệm vượt qua trong các
chu kỳ thử nghiệm liên tiếp. Tuy nhiên, nhiều hơn ba chu kỳ thử
nghiệm sẽ phát sinh chi phí cao hơn nhiều, đồng thời trì hoãn việc
tung sản phẩm “đúng lúc” ra thị trường. Ban lãnh đạo không muốn trì
hoãn việc ra mắt sản phẩm trừ khi đó là một dự án mang tính sứ
mệnh quan trọng, trong đó mục tiêu là có một sản phẩm không có
khuyết tật. Tốt hơn là bạn nên lập kế hoạch kiểm tra hệ thống dựa
trên ba chu kỳ nhưng hãy bỏ qua chu kỳ kiểm tra thứ ba nếu không
có nhu cầu. Mặt khác, không mong muốn ngân sách cho hai chu kỳ
thử nghiệm và bị tụt lại phía sau khi phần mềm có chất lượng thấp.
12.8 DỰ TOÁN NỖ LỰC THỬ NGHIỆM
Nhóm kiểm thử hệ thống cần ước tính nỗ lực kiểm thử để đưa ra lịch
trình thực hiện kiểm thử. Một cách trực quan, nỗ lực kiểm tra xác
định khối lượng công việc cần phải thực hiện. Nói một cách cụ thể,
công việc này có hai thành phần chính:
Số lượng trường hợp thử nghiệm được tạo bởi một người trong một
ngày
Số lượng trường hợp thử nghiệm được thực hiện bởi một người trong
một ngày
Các thành phần trên cũng được gọi là năng suất thử nghiệm. Thật
không may, không có công thức toán học nào để tính toán các con số
về năng suất thử nghiệm. Thay vào đó, dữ liệu về nỗ lực thử nghiệm
được thu thập bằng cách đo lường thời gian tạo và thực hiện thử
nghiệm trong các dự án thực bằng cách xem vi mô của các quy trình
thử nghiệm thực. Nếu dữ liệu năng suất được thu thập cho nhiều dự
án thử nghiệm, có thể ước tính một thước đo năng suất thử nghiệm
trung bình. Kinh nghiệm của chúng tôi về vấn đề này được thảo luận
trong phần này.
Trong giai đoạn lập kế hoạch, điều tự nhiên là ước tính chi phí của
bài kiểm tra và thời gian hoàn thành bài kiểm tra. Hai tham số chi phí
và thời gian kết hợp với nhau được gọi là nỗ lực kiểm tra.
Trong hầu hết các trường hợp, ước tính của nỗ lực kiểm tra hệ thống
được kết hợp với ước tính của toàn bộ dự án phần mềm. Tuy nhiên,
sẽ rất hữu ích nếu tách ước tính nỗ lực thử nghiệm khỏi ước tính của
toàn bộ dự án để có đủ thời gian được phân bổ để lập kế hoạch thử
nghiệm hệ thống ngay từ đầu và tiến hành ngay khi các tiêu chí đầu
vào được thỏa mãn. Ba yếu tố chính trong việc ước tính nỗ lực kiểm
tra như sau:
Số lượng các trường hợp kiểm thử được thiết kế cho dự án phần mềm
Cần nỗ lực để tạo một trường hợp thử nghiệm chi tiết
Nỗ lực cần thiết để thực hiện một trường hợp thử nghiệm và phân
tích kết quả thực thi
Một số yếu tố khác ảnh hưởng đến nỗ lực kiểm tra như sau:
Cần nỗ lực để tạo môi trường thử nghiệm
Cần nỗ lực để đào tạo các kỹ sư thử nghiệm về các chi tiết của dự án
Sự sẵn sàng của các kỹ sư kiểm tra để kiểm tra hệ thống khi họ cần
Bây giờ chúng ta thảo luận về các cách để ước tính các yếu tố chính
ảnh hưởng đến nỗ lực kiểm tra. Người lập kế hoạch kiểm thử dựa vào
kinh nghiệm trong quá khứ của họ trong việc kiểm tra các dự án
tương tự và kiến thức kỹ lưỡng về dự án hiện tại để đưa ra ước tính
chính xác cho ba hạng mục chính trên.
12.8.1 Số lượng trường hợp thử nghiệm
Sẽ rất hữu ích nếu hiểu thuật ngữ “trường hợp thử nghiệm” thường
được sử dụng trước khi nó được sử dụng để ước tính. Mức độ chi tiết
của các trường hợp thử nghiệm có tác động đáng kể đến việc ước
tính số lượng trường hợp thử nghiệm cần thiết. Ví dụ, một người có
thể sử dụng thuật ngữ trường hợp thử nghiệm để chỉ một bước thử
nghiệm nguyên tử, đây chỉ là một tương tác đầu vào - đầu ra duy nhất
giữa người thử nghiệm và SUT. Một người khác có thể sử dụng cùng
một thuật ngữ test case để chỉ hàng trăm bước kiểm tra. Định nghĩa
của chúng tôi về trường hợp thử nghiệm độc lập với số bước thử
nghiệm cần thiết để xây dựng trường hợp thử nghiệm. Mức độ chi
tiết của một trường hợp thử nghiệm được kết hợp chặt chẽ với mục
tiêu hoặc mục đích của thử nghiệm. Một trường hợp thử nghiệm đơn
giản thường chứa 7–10 bước thử nghiệm, trong khi một trường hợp
thử nghiệm phức tạp có thể dễ dàng chứa 10–50 bước thử nghiệm.
Các bước kiểm tra là các khối xây dựng nguyên tử được kết hợp để
tạo thành một trường hợp kiểm tra đáp ứng một mục tiêu được xác
định rõ ràng. Chúng tôi thảo luận về một số cách để ước tính số
lượng trường hợp thử nghiệm.
Ước tính dựa trên danh mục nhóm thử nghiệm Có thể đơn giản
ước tính số lượng trường hợp thử nghiệm sau khi cấu trúc bộ thử
nghiệm và các mục tiêu thử nghiệm được tạo, như đã thảo luận trong
Phần 12.5, chỉ cần đếm số lượng các mục tiêu thử nghiệm. Tuy
nhiên, điều này sẽ đánh giá thấp tổng số trường hợp thử nghiệm được
thiết kế vào cuối chu kỳ thực thi thử nghiệm hệ thống. Điều này là do
khi quá trình thử nghiệm hệ thống tiến triển với các trường hợp thử
nghiệm được ước tính và thiết kế ban đầu, các kỹ sư thử nghiệm
muốn quan sát hành vi bổ sung của hệ thống do quan sát của họ về
một số lỗi không lường trước được của hệ thống. Số lượng trường
hợp thử nghiệm được sử dụng vào cuối giai đoạn thử nghiệm hệ
thống nhiều hơn ước tính ban đầu. Ước tính chính xác hơn về số
lượng trường hợp thử nghiệm cho mỗi nhóm sẽ thu được bằng cách
thêm “yếu tố fudge” 10–15% vào tổng số mục tiêu thử nghiệm được
xác định cho nhóm. Một mặt, việc đánh giá thấp số lượng các trường
hợp kiểm thử gây ra việc giảm phân bổ tài nguyên cho việc kiểm thử
hệ thống ngay từ đầu. Tuy nhiên, nó đòi hỏi nhiều nguồn lực hơn khi
cần thiết, gây ra sự chậm trễ không thể kiểm soát của dự án. Mặt
khác, việc đánh giá quá cao số lượng trường hợp thử nghiệm dẫn đến
việc sử dụng chúng không hiệu quả. Vì lý do thực tế, đối với bất kỳ
dự án thử nghiệm quy mô vừa phải, rủi ro vừa phải, hệ số an toàn
hợp lý, ở dạng yếu tố giả mạo, cần được đưa vào ước tính để dự
phòng cho những trường hợp không chắc chắn.
Trưởng nhóm kiểm thử có thể tạo một bảng bao gồm các nhóm kiểm
thử (phụ) và cho mỗi nhóm (phụ) số lượng trường hợp kiểm thử ước
tính . Một cột bổ sung có thể được đưa vào cho thời gian cần thiết để
tạo và thời gian cần thiết để thực hiện các trường hợp thử nghiệm, sẽ
được thảo luận sau trong Phần 12.8.2 và 12.8.3, tương ứng.
Ví dụ: FR – ATM PVC Service Interworking. Chúng ta hãy xem
xét ví dụ liên kết dịch vụ FR-ATM PVC được thảo luận trong
Chương 11. Ước tính nỗ lực thử nghiệm được đưa ra trong Bảng 12.6
dựa trên các hạng mục thử nghiệm và cấu trúc FrAtm được thảo luận
trong Chương 11. Cột đầu tiên được ước tính dựa trên số lượng các
mục tiêu thử nghiệm được xác định cho hệ thống. Quy trình để có
được các ước tính được đưa ra dưới đây. Ước tính của hai cột tiếp
theo của Bảng 12.6 lần lượt được thảo luận trong Phần 12.8.2 và
12.8.3.
Cần có một trường hợp thử nghiệm để kiểm tra thuộc tính cho từng
thuộc tính có thể định cấu hình của thành phần FrAtm. Do đó, chúng
tôi ước tính rằng 40 trường hợp thử nghiệm sẽ được yêu cầu để kiểm
tra chức năng cấu hình với giả định của chúng tôi là 40 thuộc tính
cấu hình. Tương tự, cần tạo 30 trường hợp thử nghiệm để kiểm tra
tính năng giám sát với giả định của chúng tôi rằng 30 thuộc tính giám
sát có sẵn trong việc triển khai thành phần FrAtm. Thông tin cấu hình
và thuộc tính giám sát phải có sẵn trong đặc điểm kỹ thuật chức năng
của
BẢNG 12.6 Ước tính nỗ lực thử nghiệm cho kết nối dịch vụ
FR-ATM PVC
Số ước tính Ngày của Ngày
một người của một
người
Nhóm thử nghiệm (phụ) trong số các để tạo thực thi
trường hợp thử
nghiệm
Cấu hình 40 4 6
Giám sát 30 4 4
Quản lý giao thông 3 2 3
Tắc nghẽn 4 2 4
Ánh xạ chế độ dịch SIWF 12 4 4
Báo thức 4 1 1
Giao diện 9 5 3
Mạnh mẽ 44 ( 4 + 40 ) 4 6
Màn biểu diễn 18 6 10
Căng thẳng 2 1,5 2
Tải và ổn định 2 1,5 2
hồi quy 150 ( 60 + 90 ) 0 15
Tổng cộng 318 35 60
Thành phần FrAtm. Các trường hợp kiểm tra quản lý lưu lượng được
ước tính dựa trên số lượng tham số QoS được ánh xạ từ FR đến
ATM, xấp xỉ 3. Số lượng kiểm tra giao diện được ước tính dựa trên
số lượng thẻ RF và ATM được hỗ trợ bởi thành phần FrAtm, là 9.
Một trường hợp thử nghiệm cần được tạo cho mỗi thẻ giao diện. Do
đó, 9 trường hợp kiểm thử được ước tính cho nhóm kiểm thử giao
diện. Bốn mươi bốn trường hợp thử nghiệm được ước tính cho nhóm
độ mạnh, 4 cho nhóm con FrAtm và 40 cho các thử nghiệm giá trị
biên. Một trường hợp kiểm tra giá trị biên cần được thiết kế cho mỗi
thuộc tính cấu hình. Do đó, chúng tôi đã ước tính 40 trường hợp thử
nghiệm để kiểm tra chức năng giá trị ranh giới. Các trường hợp kiểm
tra hiệu suất được ước tính dựa trên các giả định sau:
Đo độ trễ FrAtm với 3 loại thẻ ATM. Điều này yêu cầu chúng ta thiết
kế 3 trường hợp kiểm thử. • Đo độ trễ cho FrAtm với 6 loại thẻ FR.
Do đó, chúng ta cần thiết kế 6 trường hợp kiểm thử.
Đo thông lượng bằng cách sử dụng một thẻ FR tại một thời điểm. Có
6 loại thẻ FR, và do đó chúng ta cần 6 trường hợp thử nghiệm.
Đo thông lượng bằng cách sử dụng một thẻ ATM tại một thời điểm.
Có 3 loại thẻ ATM, và do đó chúng ta cần 3 trường hợp kiểm tra.
Số lượng các trường hợp thử nghiệm ước tính để kiểm tra hiệu suất
có thể thay đổi nếu sự kết hợp của các thẻ được xem xét với các mục
tiêu khác nhau. Cuối cùng, một số trường hợp thử nghiệm để kiểm
tra hồi quy được chọn từ các bộ thử nghiệm FR và ATM hiện có. Để
đơn giản, chúng tôi giả định rằng 60 và 90 trường hợp thử nghiệm
được chọn tương ứng từ các bộ thử nghiệm FR và ATM hiện có.
Ước tính dựa trên điểm chức năng Khái niệm điểm chức năng
được sử dụng để ước tính các nguồn lực bằng cách phân tích một tài
liệu yêu cầu. Phương pháp luận này lần đầu tiên được đề xuất bởi AJ
Albrecht vào năm 1979 [14, 15]. Phương pháp điểm hàm ngày càng
trở nên phổ biến trong ngành công nghiệp, mặc dù có cảm giác rằng
nó vẫn đang ở trạng thái thử nghiệm. Ý tưởng trung tâm trong
phương pháp điểm chức năng như sau: Cho một khung nhìn chức
năng của một hệ thống dưới dạng số lượng đầu vào của người dùng,
số lượng đầu ra của người dùng, số lượng truy vấn trực tuyến của
người dùng, số lượng tệp logic, và số lượng giao diện bên ngoài,
người ta có thể ước tính quy mô dự án theo số dòng mã cần thiết để
triển khai hệ thống và số lượng trường hợp kiểm thử cần thiết để
kiểm tra hệ thống.
Albrecht [14] đã chỉ ra rằng hữu ích khi đo lường một hệ thống phần
mềm về số lượng “chức năng” mà nó thực hiện và đưa ra một
phương pháp để “đếm” số lượng các chức năng đó. Số lượng các
chức năng đó được gọi là điểm chức năng. Điểm chức năng của hệ
thống là tổng trọng số của số lượng đầu vào, đầu ra, tệp chính và các
câu hỏi được tạo ra bởi phần mềm. Bốn bước tính toán điểm chức
năng của một hệ thống được mô tả dưới đây:
Bước 1: Xác định năm loại thành phần sau, còn được gọi là “loại
chức năng người dùng”, trong hệ thống phần mềm và đếm chúng
bằng cách phân tích tài liệu yêu cầu:
Số loại đầu vào bên ngoài (NI): Đây là số lượng riêng biệt của dữ
liệu người dùng hoặc đầu vào kiểm soát của người dùng đi vào ranh
giới của hệ thống. • Số kiểu đầu ra bên ngoài (NO): Đây là số lượng
riêng biệt của dữ liệu người dùng hoặc kiểu đầu ra điều khiển rời
khỏi ranh giới bên ngoài của hệ thống.
Số kiểu yêu cầu bên ngoài (NQ): Đây là số lượng riêng biệt của các
kết hợp đầu vào - đầu ra duy nhất, trong đó đầu vào gây ra và tạo ra
đầu ra ngay lập tức. Mỗi cặp đầu vào - đầu ra riêng biệt được coi là
một kiểu điều tra.
Số loại tệp nội bộ hợp lý (NF): Đây là số lượng riêng biệt của các
nhóm lôgic chính của dữ liệu người dùng hoặc thông tin điều khiển
trong hệ thống. Mỗi nhóm lôgic được coi như một tệp lôgic. Các
nhóm dữ liệu này được tạo ra, sử dụng và duy trì bởi hệ thống.
Số loại tệp giao diện bên ngoài (NE): Đây là số tệp riêng biệt được
truyền hoặc chia sẻ giữa các hệ thống. Mỗi nhóm dữ liệu hoặc điều
khiển chính rời khỏi ranh giới hệ thống được tính là một loại tệp giao
diện bên ngoài.
Bước Phân tích mức độ phức tạp của từng loại trong số năm loại
2: chức năng người dùng trên và phân loại chúng thành ba mức
độ phức tạp, cụ thể là đơn giản, trung bình hoặc phức tạp. Ví
dụ: các loại đầu vào bên ngoài là đơn giản, các loại tệp nội
bộ hợp lý có độ phức tạp trung bình và số lượng các loại tệp
giao diện bên ngoài có bản chất phức tạp.
Hệ số trọng số được liên kết với từng mức độ phức tạp của
từng loại chức năng người dùng. Hai loại chức năng người
dùng có cùng mức độ phức tạp không nhất thiết phải có cùng
hệ số trọng số. Ví dụ: các đầu vào đơn giản bên ngoài có thể
có hệ số trọng số là 3, trong khi các loại yêu cầu bên ngoài
đơn giản có thể có hệ số trọng số là 4. Gọi WFNI biểu thị hệ
số trọng số của các loại đầu vào bên ngoài, WFNO biểu thị
hệ số trọng số của các loại đầu ra bên ngoài, v.v. trên. Bây
giờ, điểm chức năng chưa điều chỉnh hoặc thô, được ký hiệu
là UFP, được tính là
UFP = WFNI × NI + WFNO × NO + WFNQ × NQ
+ WFNL × NL + WFNE × NE
Tính toán điểm chức năng chưa điều chỉnh bằng cách sử
dụng biểu mẫu trong Bảng 12.7.

Bước Albrecht [14] đã xác định được 14 yếu tố ảnh hưởng đến nỗ
3: lực phát triển cần thiết cho một dự án. Điểm — từ 0 đến 5 —
được chỉ định cho từng yếu tố trong số 14 yếu tố của một dự
án nhất định, trong đó 0 , 2 == ảnh hưởng vừa phải không có
hoặc không có ảnh hưởng- , 3 = ence nếu có, 1 = ảnh hưởng
không đáng kể ảnh hưởng trung bình , 4 = ảnh hưởng đáng
kể và 5 = ảnh hưởng mạnh mẽ. Tổng của 14 cấp này được
gọi là hệ số điều chỉnh độ phức tạp xử lý (PCA). 14 yếu tố
được liệt kê trong Bảng 12.8.
BẢNG 12.7 Biểu mẫu cho tính toán điểm chức năng chưa điều
chỉnh
Độ phức tạp (Sử dụng một mục trong mỗi hàng)
STT Định danhSimpleAverageComplexTotal
1 NI -×3=- -×4=- -×6=-

2 KHÔNG -×4=- -×5=- -×7=-
3 NQ -×7=- - × 10 = - - × 15 = -
4 NF -×5=- -×7=- - × 10 = -
5 NE -×3=- -×4=- -×6=-
Tổng số (UFP)
BẢNG 12.8 Các yếu tố ảnh hưởng đến nỗ lực phát triển
Yêu cầu sao lưu và phục hồi đáng tin cậy

Yêu cầu giao tiếp dữ liệu
Mức độ xử lý phân tán
Các yêu cầu thực hiện
Môi trường hoạt động mong đợi
Phạm vi của các mục dữ liệu trực tuyến
Mức độ nhập dữ liệu đa màn hình hoặc đa hoạt động
Mức độ cập nhật trực tuyến các tệp chính
Phạm vi đầu vào, đầu ra phức tạp, truy vấn trực tuyến và tệp
Mức độ xử lý dữ liệu phức tạp
Phần mở rộng mà mã hiện được phát triển có thể được thiết kế để sử

dụng lại
Phạm vi chuyển đổi và cài đặt bao gồm trong thiết kế
Mức độ cài đặt nhiều lần trong một tổ chức và nhiều tổ chức khách
hàng
Mức độ thay đổi và tập trung vào tính dễ sử dụng
Bước 4: Bây giờ, chúng tôi tính toán điểm chức năng (FP) của một
hệ thống bằng cách sử dụng biểu thức thực nghiệm sau:
FP = UFP × ( 0. 65 + 0. 01 × PCA )
Bằng cách nhân điểm chức năng chưa điều chỉnh, được ký hiệu là
UFP, với biểu thức 0,65 + 0,01 × PCA, chúng ta có cơ hội điều chỉnh
điểm chức năng thêm ± 35%. Sự điều chỉnh này được giải thích như
sau. Hãy để chúng tôi phân tích hai giá trị cực trị của PCA, cụ thể là
0 và 70 ( = 14 × 5):
PCA = 0: FP = 0 . 65 × UFP
PCA = 70: FP = UFP × ( 0. 65 + 0. 01 × 70 ) = 1 . 35 ×
UFP
Do đó, giá trị của FP có thể nằm trong khoảng từ 0,65 × UFP đến
1,35 × UFP. Do đó, chúng tôi điều chỉnh giá trị của FP trong phạm vi
± 35% bằng cách sử dụng các giá trị trung gian của PCA.
Chỉ số điểm chức năng có thể được sử dụng để ước tính số lượng
trường hợp thử nghiệm theo những cách sau:
Phương pháp gián tiếp: Ước tính kích thước mã từ các điểm chức
năng và sau đó ước tính số lượng trường hợp thử nghiệm từ kích
thước mã.
Phương pháp Trực tiếp: Ước tính số lượng trường hợp kiểm thử
trực tiếp từ các điểm chức năng.
Phương pháp gián tiếp Các điểm chức năng của hệ thống phần
mềm được tính toán bằng cách kiểm tra chi tiết các yêu cầu của hệ
thống từ cơ sở dữ liệu yêu cầu. Tại thời điểm tính toán như vậy, ngôn
ngữ lập trình mà hệ thống sẽ được triển khai có thể không được biết
đến. Việc triển khai hệ thống bằng các ngôn ngữ lập trình khác nhau
sẽ tạo ra các thước đo dòng mã (LOC) khác nhau. Do đó, việc lựa
chọn ngôn ngữ lập trình có ảnh hưởng trực tiếp đến chỉ số LOC.
Capers Jones [16] đã đưa ra mối quan hệ giữa các điểm chức năng và
kích thước mã của một hệ thống phần mềm. Cụ thể, ông đã đưa ra số
lượng LOC trên mỗi điểm chức năng cho một số ngôn ngữ lập trình
như trong Bảng 12.9.
Với tổng số điểm chức năng của một hệ thống, người ta có thể dự
đoán số LOC của một hệ thống phần mềm bằng cách đưa ra giả định
về một ngôn ngữ lập trình trong việc triển khai hệ thống. Tại thời
điểm này, cần phải sử dụng kinh nghiệm của một người trong việc
ước tính số lượng trường hợp kiểm thử được thiết kế để kiểm tra hệ
thống. Thực hành ước tính này khác nhau giữa các tổ chức và thậm
chí trong cùng một tổ chức đối với các loại hệ thống phần mềm khác
nhau.
Nghiên cứu thực nghiệm 30 năm của Hitachi Software [11] đưa ra
tiêu chuẩn về một trường hợp thử nghiệm trên 10–15 LOC. Một hệ
thống có 100 điểm chức năng và được thực hiện trong C sẽ tạo ra
kích thước mã là 100 × 128 = 12 , 800 dòng. Các trường hợp kiểm
thử được đánh số từ 850 đến 1280 được thiết kế để kiểm tra mức hệ
thống của hệ thống phần mềm đang được xem xét. Cần phải nhớ rằng
những trường hợp thử nghiệm này không bao gồm những trường hợp
thử nghiệm cần thiết cho thử nghiệm đơn vị và thử nghiệm tích hợp.
Điều này là do các kỹ sư kiểm thử trong nhóm kiểm thử hệ thống
phải không thiên vị và không bao giờ sử dụng lại các trường hợp
kiểm thử của các lập trình viên. Thay vào đó, nhóm kiểm tra hệ
thống thiết kế các trường hợp kiểm tra từ đầu.
BẢNG 12.9 Mối quan hệ thực nghiệm giữa
Điểm chức năng và LOC
LOC / FP
Ngôn ngữ lập trình
trung bình
Hợp ngữ 320
C 128
COBOL 106
FORTRAN 106
C
++ 64 32
Ngôn ngữ lập trình
Phương pháp trực tiếp Capers Jones [16] đã đưa ra mối quan hệ
trực tiếp giữa các điểm chức năng và tổng số trường hợp thử nghiệm
được tạo ra dưới dạng
Tổng số trường hợp thử nghiệm = (điểm chức năng) 1 . 2
Số lượng các trường hợp kiểm thử được ước tính ở trên bao gồm tất
cả các hình thức kiểm thử được thực hiện trên hệ thống phần mềm,
chẳng hạn như kiểm thử đơn vị, kiểm thử tích hợp và kiểm thử hệ
thống. Nó không phân biệt kích thước kiểm tra hệ thống với tổng số
nỗ lực kiểm tra.
Bây giờ rất hữu ích khi so sánh phương pháp ước lượng thử nghiệm
được sử dụng bởi Phần mềm Hitachi [11] và phương pháp Caper
Jones [16]. Phương pháp được Hitachi Software sử dụng ước tính số
lượng trường hợp thử nghiệm bằng cách xem xét kích thước mã theo
số lượng LOC, trong khi Caper Jones ước tính số lượng trường hợp
thử nghiệm bằng cách xem xét các điểm chức năng. Chúng tôi bắt
đầu với một số điểm chức năng nhất định và ước tính kích thước mã
từ đó để có một so sánh có ý nghĩa. Ví dụ, chúng tôi đã xem xét 100
điểm chức năng trong hai ví dụ trước. Tiếp theo, chúng tôi lấy thông
tin LOC bằng cách giả sử một ngôn ngữ lập trình nhất định để có thể
áp dụng cho phương pháp Phần mềm Hitachi. Giả sử rằng ngôn ngữ
đích của chúng ta là C, số lượng LOC ước tính được tạo ra trong C là
100 × 128 = 12 , 800 LOC. Phương pháp được Hitachi Software áp
dụng tạo ra 850–1280 trường hợp thử nghiệm để kiểm tra hệ thống
với 12.800 LOC, trong khi phương pháp Caper Jones ước tính 251
trường hợp thử nghiệm. Lưu ý rằng có sự khác biệt từ bốn đến năm
lần giữa số lượng trường hợp thử nghiệm được ước tính bởi hai
phương pháp. Sự khác biệt được giải thích như sau: Ngành công
nghiệp phần mềm Nhật Bản (ví dụ: Phần mềm Hitachi) sử dụng điểm
kiểm tra thuật ngữ thay vì trường hợp kiểm tra, và điểm kiểm tra
tương tự như một bước kiểm tra. Một trường hợp thử nghiệm thường
chứa từ 1 đến 10 bước thử nghiệm. Số lượng các trường hợp kiểm tra
được ước tính bằng cách sử dụng phương pháp Phần mềm Hitachi
thể hiện số bước kiểm tra (hoặc điểm kiểm tra). Bây giờ, nếu chúng
ta giả định rằng một trường hợp thử nghiệm chứa trung bình năm
bước thử nghiệm, thì số lượng trường hợp thử nghiệm được ước tính
bởi phương pháp Phần mềm Hitachi là từ 170 đến 256 và phạm vi
này gần hơn với 251 — con số ước tính theo phương pháp Caper
Jones .
12.8.2 Nỗ lực tạo trường hợp thử nghiệm
Cần phân bổ thời gian để tạo các trường hợp kiểm thử sau khi cấu
trúc bộ kiểm thử và các mục tiêu kiểm thử được xác định. Trung
bình, năng suất của việc tạo trường hợp thử nghiệm thủ công được
tóm tắt trong Bảng 12.10. Thời gian đại diện cho khoảng thời gian từ
mục nhập đến trạng thái tạo cho đến mục nhập đến trạng thái được
giải phóng của biểu đồ chuyển đổi trạng thái của một trường hợp
kiểm thử được thảo luận trong Chương 11.
BẢNG 12.10 Hướng dẫn về Nỗ lực Tạo Trường hợp Kiểm tra
Thủ công
Số lần kiểm tra
trung bình
Kích thước của trường hợp thử nghiệm Các trường hợp
mỗi người-Ngày
Trường hợp thử nghiệm nhỏ, đơn giản 7–15
(1–10 bước thử nghiệm nguyên tử)
Trường hợp thử nghiệm lớn, phức tạp 1,5–3
Các hoạt động liên quan đến việc tạo các trường hợp kiểm thử đã
được thảo luận chi tiết trong Chương 11 và được tóm tắt ở đây:
Đọc và hiểu các yêu cầu hệ thống và tài liệu đặc tả chức năng
Tạo các trường hợp thử nghiệm
Nhập tất cả các trường bắt buộc, bao gồm các bước kiểm tra và tiêu
chí đạt - không đạt • Xem xét và cập nhật trường hợp kiểm tra
Kỹ năng và hiệu quả của một kỹ sư kiểm thử là những yếu tố quan
trọng ảnh hưởng đến việc ước tính việc tạo trường hợp kiểm thử.
Chúng tôi giả định trong hướng dẫn của chúng tôi được cung cấp
trong Bảng 12.10 rằng một kỹ sư kiểm thử có kỹ năng phát triển các
trường hợp thử nghiệm, nghĩa là anh ta hoặc cô ta đã có từ bốn đến
sáu năm kinh nghiệm trong việc phát triển các trường hợp thử
nghiệm trong lĩnh vực chuyên môn liên quan. Caper Jones [17] ước
tính rằng các trường hợp thử nghiệm được tạo với tốc độ 30–300 mỗi
người / tháng. Nói cách khác, 1,5–15 trường hợp thử nghiệm có thể
được tạo bởi một người trong một ngày. Ước tính của chúng tôi về
việc tạo các trường hợp thử nghiệm cho từng nhóm liên kết dịch vụ
FR-ATM được đưa ra trong cột thứ ba của Bảng 12.6 dựa trên các
hướng dẫn được cung cấp trong Bảng 12.10.
12.8.3 Nỗ lực thực thi trường hợp thử nghiệm
Thời gian cần thiết để thực hiện một ca kiểm thử phụ thuộc vào mức
độ phức tạp của ca kiểm thử và chuyên môn của người thực thi về
chủ đề của hệ thống. Có thể cho rằng, các trường hợp thử nghiệm
trong lĩnh vực viễn thông là những trường hợp phức tạp nhất và đòi
hỏi sự hiểu biết về cấu hình của thiết bị chuyển mạch, bộ định tuyến
và các giao thức khác nhau. Trong mọi trường hợp, người ta phải
xem xét các yếu tố sau để ước tính nỗ lực làm việc cho việc thực hiện
thử nghiệm thủ công:
Hiểu các trường hợp thử nghiệm nếu các trường hợp thử nghiệm
chưa được tạo bởi người thực thi
Định cấu hình các giường thử nghiệm
Thực hiện các bước kiểm tra và đánh giá các bước kiểm tra
Xác định trạng thái thực thi (đạt - không đạt) của test case
Ghi lại các kết quả thử nghiệm trong cơ sở dữ liệu của nhà máy thử
nghiệm
Thu thập và phân tích dữ liệu nếu các trường hợp kiểm tra hiệu suất
và tải trọng đang được thực thi
Cập nhật trường hợp thử nghiệm trong nhà máy thử nghiệm, như đã
thảo luận trong Chương 11
Trong trường hợp không thành công, thực hiện các tác vụ sau:
Cố gắng tái tạo lỗi
Thực hiện các tình huống khác nhau liên quan đến lỗi được quan sát
thấy
Thu thập chi tiết về cấu hình, nhật ký và cấu hình phần cứng
Nộp báo cáo lỗi trong hệ thống theo dõi lỗi
Nếu nhà phát triển phần mềm không thể tái tạo lỗi, hãy theo dõi họ
trong việc gỡ lỗi và xác định vị trí của vấn đề
Một cách trực quan — và nó cũng có thể được quan sát — tốc độ
thực thi thử nghiệm tỷ lệ tuyến tính với tỷ lệ vượt qua các trường hợp
thử nghiệm. Nói cách khác, nếu tỷ lệ lỗi trường hợp thử nghiệm cao,
nó sẽ làm chậm tốc độ thực thi trường hợp thử nghiệm. Điều này là
do một kỹ sư kiểm thử cần giúp các nhà phát triển tái tạo vấn đề và
xác định nguyên nhân gốc rễ của vấn đề bằng cách thử và sai, điều
này làm mất rất nhiều thời gian từ việc thực hiện các trường hợp
kiểm thử.
Dựa trên kinh nghiệm của mình, chúng tôi đã tóm tắt tỷ lệ thực thi
của các trường hợp thử nghiệm cho cả thử nghiệm mới và thử
nghiệm hồi quy trong Bảng 12.11 và 12.12, tương ứng. Thời gian
thực hiện cho các trường hợp thử nghiệm mới được tạo khác với thời
gian cho thử nghiệm hồi quy. Sự khác biệt là do thực tế là các trường
hợp kiểm thử hồi quy đã được chạy trước đó và các bước kiểm tra
cũng như tiêu chí đạt - không đạt của chúng đã được xác nhận trước
đó. Tuy nhiên, nếu một kỹ sư kiểm thử chưa thực hiện một nhóm
kiểm tra hồi quy cụ thể trước đó, anh ta có thể phải dành nhiều thời
gian hơn để hiểu các kiểm tra và thiết lập giường kiểm tra để thực
hiện các kiểm tra hồi quy được chỉ định. Do đó, thời gian thực hiện
kiểm thử hồi quy gần giống như thời gian thực thi trường hợp kiểm
thử mới được tạo cho một kỹ sư thiếu kinh nghiệm. Do đó, tự động
hóa thử nghiệm phải được xem xét đối với các thử nghiệm hồi quy,
điều này sẽ được thảo luận trong phần sau của chương này.
Ước tính của chúng tôi về việc thực thi trường hợp thử nghiệm cho
từng nhóm liên kết dịch vụ FR-ATM được đưa ra trong cột thứ tư
của Bảng 12.6 dựa trên các hướng dẫn được cung cấp trong Bảng
12.11 và 12.12. Có thể lưu ý rằng nếu các kiểm tra hồi quy tự động
có sẵn, tổng thời gian thực hiện có thể đã được giảm xuống.
BẢNG 12.11 Hướng dẫn về Nỗ lực Thực hiện Test Case thủ
công
Số lần kiểm tra
trung bình
Kích thước của trường hợp thử nghiệm Các trường hợp
mỗi người-Ngày
Trường hợp thử nghiệm nhỏ, đơn giản 7–15
Trường hợp thử nghiệm lớn, phức tạp 1,5–2,5
BẢNG 12.12 Hướng dẫn ước tính nỗ lực thực hiện thủ công các
trường hợp kiểm tra hồi quy
Số hồi quy trung bình

Các trường hợp thử nghiệm mỗi người-ngày
Các trường
hợp kiểm
Không thực thi tra
Kích thước của trường hợp thử nghiệm Các trường hợp Đã thực
thử nghiệmhiện trước
trước đó đó
Trường hợp thử nghiệm nhỏ, đơn giản 10–15 10–20
Trường hợp thử nghiệm lớn, phức tạp 1–2,5 2,5–5
12.9 LẬP LỊCH VÀ KIỂM TRA SỮA RỬA MẶT

Vì lý do kinh tế và để đáp ứng thời hạn hợp đồng, điều quan trọng là
phải vạch ra lịch trình và các mốc quan trọng cho dự án thử nghiệm.
Các tổ chức bị hạn chế phát hành sản phẩm trong khung thời gian do
bộ phận tiếp thị và bán hàng của họ khuyến nghị vì tính cạnh tranh
cao ngày nay trên thị trường. Nhóm thử nghiệm hệ thống bị ràng
buộc phải phân phối nỗ lực thử nghiệm của mình để đáp ứng yêu cầu
tiếp thị để phát hành sản phẩm trong một khung thời gian quy định.
Người ta phải xem xét các con đường khác nhau để hoàn thành giai
đoạn thử nghiệm hệ thống đúng thời hạn mà không bị chậm trễ nhiều
trong việc cung cấp sản phẩm và không ảnh hưởng đến chất lượng
của sản phẩm. Khi lên lịch cho các hoạt động trong kiểm thử hệ
thống, người lãnh đạo của nhóm kiểm thử hệ thống cố gắng điều phối
các nguồn lực sẵn có để đạt được năng suất dự kiến. Người lãnh đạo
xem xét mọi sự phụ thuộc lẫn nhau giữa các nhiệm vụ và lên lịch cho
các nhiệm vụ song song bất cứ khi nào có thể. Các mốc quan trọng,
đánh giá và phân phối thử nghiệm được chỉ định trong lịch trình thử
nghiệm để phản ánh chính xác tiến độ của dự án thử nghiệm.
Lập lịch trình kiểm thử hệ thống là một phần của việc lập lịch trình
tổng thể của một dự án phát triển phần mềm. Nó được hợp nhất với
kế hoạch dự án phần mềm tổng thể sau khi có lịch trình kiểm tra hệ
thống. Điều cần thiết là phải hiểu và cân nhắc các bước sau để lên
lịch cho một dự án thử nghiệm một cách hiệu quả: • Xây dựng danh
sách chi tiết các nhiệm vụ, chẳng hạn như:
Mua sắm thiết bị để thiết lập môi trường thử nghiệm
Thiết lập môi trường thử nghiệm
Tạo các trường hợp thử nghiệm chi tiết cho từng nhóm và nhóm con
trong nhà máy thử nghiệm
Tạo bộ thử nghiệm trong nhà máy thử nghiệm
Thực thi các trường hợp kiểm thử trong chu kỳ kiểm tra hệ thống
Viết báo cáo thử nghiệm cuối cùng sau khi hoàn thành thử nghiệm hệ
thống
• Liệt kê tất cả các mốc quan trọng cần đạt được trong quá trình thử
nghiệm dự án, chẳng hạn như:
535
Xem xét kế hoạch thử nghiệm với các thành viên trong nhóm chức
năng chéo
Hoàn thành phiên bản đã được phê duyệt của kế hoạch thử nghiệm
Xem xét các trường hợp thử nghiệm mới được tạo và các trường hợp
thử nghiệm đã chọn để kiểm tra hồi quy
Hoàn thành các trường hợp kiểm thử; tất cả các trường hợp thử
nghiệm đều ở trạng thái đã phát hành để chúng có thể là một phần của
bộ thử nghiệm, như đã thảo luận trong Chương 11
Việc tạo bộ thử nghiệm sẽ được thực thi, như đã thảo luận trong
Chương 11
Chuẩn bị môi trường thử nghiệm
Ngày nhập cuộc họp đánh giá mức độ sẵn sàng
Phát hành chính thức hình ảnh phần mềm cho nhóm kiểm tra hệ
thống
Bắt đầu chu kỳ kiểm tra hệ thống đầu tiên
Kết thúc chu kỳ kiểm tra hệ thống đầu tiên
Bắt đầu chu kỳ kiểm tra hệ thống thứ hai
Kết thúc chu kỳ kiểm tra hệ thống thứ hai
Bắt đầu chu kỳ kiểm tra hệ thống cuối cùng
Kết thúc chu kỳ kiểm tra hệ thống cuối cùng
Ngày gửi báo cáo thử nghiệm cuối cùng
Xác định sự phụ thuộc lẫn nhau giữa các nhiệm vụ kiểm tra và bất kỳ
cột mốc phần mềm nào có thể ảnh hưởng đến quy trình công việc,
chẳng hạn như việc phát hành chính thức hình ảnh phần mềm cho
nhóm kiểm tra hệ thống. Ngoài ra, xác định các nhiệm vụ có thể được
thực hiện đồng thời. Một số ví dụ về việc triển khai đồng thời các tác
vụ thử nghiệm như sau:
Các giường thử nghiệm có thể được thiết lập đồng thời với việc tạo
các trường hợp thử nghiệm.
Việc tạo các trường hợp kiểm thử trong các nhóm khác nhau có thể
được thực hiện đồng thời.
Các trường hợp thử nghiệm từ các nhóm khác nhau có thể được thực
hiện đồng thời trên các giường thử nghiệm khác nhau.
Xác định các loại tài nguyên và kiến thức chuyên môn khác nhau cần
thiết để hoàn thành từng nhiệm vụ trong danh sách.
Ước tính số lượng tài nguyên cần thiết cho mỗi nhiệm vụ, chẳng hạn
như thiết bị và nguồn nhân lực, như đã thảo luận trước đó trong
chương này.
Xác định các loại và số lượng tài nguyên có sẵn cho dự án thử
nghiệm này, chẳng hạn như:
Nguồn nhân lực: những người có sẵn và ngày sẵn có, sự sẵn sàng bán
toàn thời gian của từng nguồn nhân lực riêng lẻ và lĩnh vực chuyên
môn của từng nguồn nhân lực riêng lẻ
Tài nguyên phần cứng / phần mềm: tính sẵn có của tất cả phần cứng /
phần mềm để xây dựng môi trường thử nghiệm như đã thảo luận
trong Phần 12.6
Giả sử rằng phần còn lại của các tài nguyên sẽ có sẵn vào những ngày
nhất định.
Phân bổ các nguồn lực cho từng nhiệm vụ. Việc phân bổ này được
thực hiện theo từng nhiệm vụ theo trình tự, bắt đầu từ ngày kết thúc
của dự án thử nghiệm. • Lên lịch ngày bắt đầu và ngày kết thúc của
mỗi nhiệm vụ. Ví dụ, nhiệm vụ thực thi thử nghiệm có thể dựa trên
các ước tính được thảo luận trong Phần 12.8.3. Cho phép trì hoãn các
sự kiện không lường trước được, chẳng hạn như bệnh tật, kỳ nghỉ,
đào tạo và cuộc họp.
Tại thời điểm này, hãy chèn phần còn lại của các mốc quan trọng vào
lịch trình tổng thể. Bạn có thể phải điều chỉnh việc phân bổ tài
nguyên và lịch trình. • Xác định ngày bắt đầu và ngày kết thúc sớm
nhất và muộn nhất có thể cho mỗi nhiệm vụ bằng cách tính đến bất
kỳ sự phụ thuộc lẫn nhau nào giữa các nhiệm vụ được xác định trước
đó.
Xem xét lịch trình về tính hợp lý của các giả định. Ở giai đoạn này,
bạn nên đặt những câu hỏi “nếu”. Phân tích và thay đổi lịch trình
thông qua các lần lặp lại khi các giả định thay đổi.
Xác định các điều kiện cần thiết để được thỏa mãn đối với lịch trình.
Ngoài ra, xác định kế hoạch dự phòng để chuẩn bị cho khả năng
những điều kiện đó không được đáp ứng. Ví dụ, nếu không thể thuê
một kỹ sư kiểm tra toàn thời gian vào một ngày nhất định, người ta
nên tìm một nhà thầu hoặc chuyển sang các kỹ sư kiểm tra khác từ
một dự án khác.
537
Ghi lại các giả định, chẳng hạn như (i) kỹ sư thử nghiệm mới phải
được thuê vào một ngày nhất định, (ii) thiết bị mới phải có sẵn trước
một ngày nhất định và (iii) không gian sẵn có để thiết lập môi trường
thử nghiệm. • Xem lại lịch trình với nhóm kiểm tra và nhận phản hồi
của họ. Lịch trình có thể không được đáp ứng nếu không có sự tham
gia tích cực của họ.
Ước tính nỗ lực thử nghiệm và lịch trình cần phải trải qua một vài
vòng lặp lại để làm cho chúng đáng tin cậy. Một công cụ phần mềm
tốt có sẵn trên thị trường rất có giá trị để sắp xếp lịch trình kiểm tra.
Một vấn đề lớn mà trưởng nhóm kiểm thử có thể gặp phải từ phía
quản lý là làm thế nào để rút ngắn thời gian thực hiện trường hợp
kiểm thử. Một số tác vụ có thể bị loại bỏ hoàn toàn bằng cách giảm
phạm vi và độ sâu của thử nghiệm. Nếu không thể, một người có thể
bao gồm các chuyên gia kiểm tra lành nghề với trình độ cao, yêu cầu
mọi người làm thêm giờ, và bổ sung thêm người và giường kiểm tra.
Một cách khác để giảm thời gian thực thi là tự động hóa trước tất cả
các trường hợp thử nghiệm để thời gian thực thi được giảm đáng kể.
Biểu đồ Gantt Biểu đồ Gantt thường được sử dụng để biểu diễn một
lịch trình dự án bao gồm thời gian của các nhiệm vụ riêng lẻ, sự phụ
thuộc của chúng và thứ tự của chúng. Biểu đồ Gantt điển hình hiển
thị đồ thị điểm bắt đầu và điểm kết thúc của mỗi nhiệm vụ — tổng
thời gian cần thiết để hoàn thành mỗi nhiệm vụ. Khi dự án tiến triển,
nó sẽ hiển thị tỷ lệ phần trăm hoàn thành của mỗi nhiệm vụ. Nó cho
phép người lập kế hoạch đánh giá thời gian của một dự án, xác định
các nguồn lực cần thiết và đưa ra thứ tự các nhiệm vụ cần được thực
hiện. Nó hữu ích trong việc quản lý sự phụ thuộc giữa các tác vụ. Nó
được sử dụng rộng rãi để lập kế hoạch và lập lịch dự án nhằm:
Đánh giá đặc điểm thời gian của một dự án
Hiển thị thứ tự nhiệm vụ
Hiển thị liên kết giữa các nhiệm vụ đã lên lịch
Xác định các nguồn lực liên quan
Giám sát việc hoàn thành dự án
Trong biểu đồ Gantt, mỗi nhiệm vụ có một hàng. Ngày chạy dọc theo
đầu theo gia số ngày, tuần hoặc tháng, tùy thuộc vào độ dài của dự
án. Thời gian dự kiến cho mỗi nhiệm vụ được biểu thị bằng một hình
chữ nhật nằm ngang hoặc một đường thẳng. Các nhiệm vụ có thể
chồng chéo hoặc chạy theo trình tự hoặc song song. Thường thì dự án
có những sự kiện quan trọng và người ta muốn hiển thị những sự kiện
đó trên dòng thời gian của dự án. Ví dụ, chúng tôi có thể muốn làm
nổi bật khi một nguyên mẫu được hoàn thành hoặc ngày xem xét kế
hoạch thử nghiệm. Người ta có thể nhập những thứ này trên biểu đồ
Gantt dưới dạng các sự kiện quan trọng và đánh dấu chúng bằng một
biểu tượng đặc biệt, thường là hình thoi. Các nhiệm vụ phải được giữ
ở một số lượng có thể quản lý được (không quá 15 hoặc 20) trong quá
trình xây dựng biểu đồ Gantt để biểu đồ phù hợp trên một trang. Các
dự án phức tạp hơn có thể yêu cầu các biểu đồ cấp dưới nêu chi tiết
thời gian của tất cả các nhiệm vụ phụ của các nhiệm vụ chính.
Thường sẽ hữu ích khi có thêm một cột chứa số hoặc tên viết tắt để
xác định thành viên nhóm chịu trách nhiệm về nhiệm vụ cho các dự
án nhóm.
Nhận xét. Ý tưởng về biểu đồ Gantt ban đầu được đề xuất vào năm
1917 bởi kỹ sư người Mỹ Henry L. Gantt. Ông đã phát triển biểu đồ
Gantt đầu tiên được sử dụng trong lập kế hoạch quy trình sản xuất.
Được chấp nhận như một công cụ quản lý dự án phổ biến ngày nay,
nó là một sự đổi mới có tầm quan trọng trên toàn thế giới vào những
năm 1920. Biểu đồ Gantt đã được sử dụng thành công trong các dự
án xây dựng lớn như dự án Đập Hoover bắt đầu vào năm 1931 và
mạng lưới đường cao tốc liên bang bắt đầu vào năm 1956.
Ví dụ: FR – ATM PVC Service Interworking. Chúng ta hãy xem
xét ví dụ liên kết dịch vụ FR-ATM PVC được thảo luận trong
Chương 11. Lịch trình thử nghiệm mức cao cho dự án thử nghiệm
này được thể hiện trong Hình 12.2 sử dụng biểu đồ Gantt. Chúng tôi
đã đưa ra các giả định sau khi lập kế hoạch lịch trình thử nghiệm:
Bốn kỹ sư thử nghiệm: Alex, Rohan, Inu và Lucy đã sẵn sàng cho dự
án này từ ngày đầu tiên và Alex là trưởng nhóm thử nghiệm cho dự
án này.
Tất cả bốn kỹ sư đều được đào tạo bài bản để tạo ra các trường hợp
thử nghiệm trong nhà máy thử nghiệm.
Tất cả họ đều am hiểu về lĩnh vực FR và giao thức ATM.
Alex mất năm ngày để phát triển kế hoạch thử nghiệm cho dự án này.
TÔITên nhiệm Khoảng Bắt Kết Tháng tháng tháng 2 Bước đều
vụ thời đầu thúc 12 Giêng
gian
539
1 Phát triển 5 ngày 3 7 Alex, Alex 1/7 Rohan
kế hoạch thán tháng Alex Rohan,
kiểm tra g1 1 1/10 cy
Lucy
Inu,
2 Xem lại kế 0 ngày 7 7 Lu Alex,Inu,
2/3
n, Lucy
hoạch kiểm thán tháng
Alex,
2/9
Inu,
tra g1 1 Roha 3/4
Alex
3 Cập nhật kế 1 ngày 10 10

2/14 3/4 năm
2/14
hoạch kiểm thán tháng ,Inu Inu, Lucy

tra g1 1 Alex,
han,Inu,Luc
Rohan
4 Kế hoạch 0 ngày 10 10
thử nghiệm thán tháng
đã được phê g1 1
duyệt
5 Mua sắm 7 ngày 11 19
6 thiết bị 10 ngày thán tháng
Thiết lập g1 1
môi trường 20 2
thử nghiệm thán tháng
g1 2
7 Tạo các 18 ngày 11 3
số 8 trường hợp 0 ngày thán tháng
thử nghiệm g1 2
trong nhà 3 3
máy thử thán tháng
nghiệm g2 2
Xem lại các
trường hợp
thử nghiệm
9 Cập nhật 4 ngày 4 9
10 các trường 0 ngày thán tháng
hợp thử g2 2
nghiệm 9 9
trong nhà thán tháng
máy thử g2 2
nghiệm
Các trường
hợp thử
nghiệm
đang ở
trạng thái
phát hành
11 Tạo bộ thử 1 ngày 10 10
12 nghiệm 1 ngày thán tháng
13 trong nhà 0 ngày g2 2
máy thử 11 11
nghiệm thán tháng
Cuộc họp g2 2
sẵn sàng 14 14
tiêu chí đầu thán tháng
vào g2 2
Bản phát
hành chính
thức của S /
W để kiểm
tra hệ thống
14 Bắt đầu chu 0 ngày 14 14
kỳ thử thán tháng
nghiệm đầu g2 2
tiên
15 Chu kỳ thử 15 ngày 14 4 Rohan,
16 nghiệm đầu 0 ngày thán tháng Lucy
tiên g2 3 Alex, Ro
Kết thúc 4 4
chu kỳ thử thán tháng
nghiệm đầu g3 3
tiên
kỳ kiểm tra thán tháng
thứ hai g3 3
18 Chu kỳ 15 ngày Ngày 25 Alex, Roha
19 kiểm tra thứ 0 ngày 7 tháng
hai thán 3
541
Kết thúc g 3 25
chu kỳ ngày tháng
kiểm tra thứ 25 3
hai thán
g3
20 Cuộc họp 0 ngày 25 25
đánh giá thán tháng
tiêu chí g3 3
phát hành
beta
21 Phát hành 1 ngày 28 28
phần mềm thán tháng
cho khách g3 3
hàng beta
kỳ kiểm tra thán tháng
thứ ba g3 3
23 Chu kỳ 5 ngày 29 4
24 kiểm tra thứ 0 ngày thán tháng
ba g3 4
Kết thúc 4 4
chu kỳ thán tháng
kiểm tra thứ g4 4
ba
25 Chuẩn bị 4 ngày 5 8
26 báo cáo thử 0 ngày thán tháng
nghiệm g4 4
Đưa ra 8 8
cuộc họp thán tháng
đánh giá g4 4
tiêu chí
27 Phát hành 1 ngày 13 13
phần mềm thán tháng
cho khách g4 4
hàng
Hình 12.2 Biểu đồ Gantt cho dự án thử nghiệm liên kết dịch vụ
FR-ATM.
12.10 TỰ ĐỘNG THỬ NGHIỆM HỆ THỐNG
Không ai có kế hoạch đi nghỉ trong thời gian thử nghiệm hệ thống.
Thiết bị thử nghiệm có sẵn cho dự án thử nghiệm này.
Việc thiết lập môi trường thử nghiệm và tạo các trường hợp thử
nghiệm được thực hiện đồng thời. Lucy được giao nhiệm vụ thiết lập
các giường thử nghiệm trong khi các kỹ sư còn lại được giao thiết kế
các trường hợp thử nghiệm. Chúng tôi đã ước tính khoảng 35 ngày-
người để tạo 168 trường hợp thử nghiệm, không bao gồm trường hợp
thử nghiệm hồi quy như được đưa ra trong Bảng 12.6. Do đó, chúng
tôi đã phân bổ 18 ngày để thiết kế các trường hợp thử nghiệm được
phân phối cho ba kỹ sư thử nghiệm, Alex, Inu và Rohan, với tổng số
ngày là 54 người. Điều này bao gồm đào tạo và hiểu biết về giao thức
kết nối internet của dịch vụ FR – ATM. Chu kỳ kiểm tra đầu tiên
được bắt đầu sau khi các tiêu chí đầu vào được xác minh tại cuộc họp
đánh giá mức độ sẵn sàng. Theo ước tính của chúng tôi, sẽ mất 60
ngày để thực hiện tất cả 318 trường hợp thử nghiệm đã chọn, bao
gồm cả các thử nghiệm hồi quy. Do đó, chúng tôi đã phân bổ 15 ngày
để thực hiện tất cả các trường hợp thử nghiệm bởi bốn kỹ sư thử
nghiệm, Alex, Inu, Rohan và Lucy, với tổng nguồn lực là 60 ngày
người. Sau chu kỳ thử nghiệm thứ hai, phần mềm dự kiến sẽ được
phát hành cho khách hàng beta. Một tập hợp con của các trường hợp
kiểm thử được chọn để kiểm tra hồi quy trong chu kỳ kiểm tra cuối
cùng. Do đó, chỉ có một tuần được phân bổ cho nhiệm vụ này. Phần
mềm được phát hành cho khách hàng sau khi báo cáo thử nghiệm
cuối cùng được tạo và xem xét.
12.10 TỰ ĐỘNG THỬ NGHIỆM HỆ THỐNG
Điều hoàn toàn cần thiết đối với bất kỳ tổ chức thử nghiệm nào cũng
phải tiến lên để trở nên hiệu quả hơn, đặc biệt là theo hướng tự động
hóa thử nghiệm. Các lý do để tự động hóa các trường hợp kiểm thử
được nêu trong Bảng 12.13. Điều quan trọng là phải nghĩ về tự động
hóa như một hoạt động kinh doanh chiến lược. Một hoạt động chiến
lược cần có sự hỗ trợ của quản lý cấp cao; nếu không rất có thể sẽ
thất bại do thiếu kinh phí. Nó phải phù hợp với sứ mệnh và mục tiêu
kinh doanh và mong muốn tăng tốc độ cung cấp hệ thống ra thị
543
trường mà không ảnh hưởng đến chất lượng. Tuy nhiên, tự động hóa
là một khoản đầu tư dài hạn; nó là một quá trình đang diễn ra. Nó
không thể đạt được trong một sớm một chiều; kỳ vọng cần được quản
lý để đảm bảo rằng nó có thể đạt được trên thực tế trong một khoảng
thời gian nhất định.
BẢNG 12.13 Lợi ích của Kiểm tra Tự động
Kỹ sư kiểm tra năng suất

Phạm vi kiểm tra hồi quy
Khả năng tái sử dụng của các trường hợp thử nghiệm
Tính nhất quán trong thử nghiệm
Giảm khoảng thời gian thử nghiệm
Giảm chi phí bảo trì phần mềm
Tăng hiệu quả kiểm tra
Tổ chức phải đánh giá và giải quyết một số cân nhắc trước khi tiến
hành tự động hóa thử nghiệm. Các điều kiện tiên quyết sau đây cần
được xem xét để đánh giá xem tổ chức đã sẵn sàng cho việc tự động
hóa thử nghiệm hay chưa:
Hệ thống ổn định và các chức năng của nó được xác định rõ ràng.
Các trường hợp kiểm thử được tự động hóa là rõ ràng.
công trước đó với tự động hóa.
Ngân sách đầy đủ đã được phân bổ cho việc mua sắm các công cụ
phần mềm.
Hệ thống phải đủ ổn định để tự động hóa có ý nghĩa. Nếu hệ thống
liên tục thay đổi hoặc thường xuyên gặp sự cố, chi phí bảo trì của bộ
thử nghiệm tự động sẽ khá cao để giữ cho các trường hợp thử nghiệm
được cập nhật với hệ thống. Tự động hóa kiểm tra sẽ không thành
công trừ khi có các quy trình kiểm tra chi tiết. Rất khó để tự động hóa
một trường hợp thử nghiệm không được xác định rõ để thực thi theo
cách thủ công. Nếu các bài kiểm tra được thực hiện theo cách đột
xuất mà không phát triển các mục tiêu kiểm tra, quy trình kiểm tra chi
tiết và tiêu chí đạt - không đạt, thì chúng chưa sẵn sàng để tự động
hóa. Nếu các trường hợp kiểm thử được thiết kế như đã thảo luận
trong Chương 11, thì tự động hóa có khả năng thành công hơn.
Các kỹ sư thử nghiệm phải có kinh nghiệm lập trình đáng kể. Không
thể tự động hóa các bài kiểm tra mà không sử dụng các ngôn ngữ lập
trình, chẳng hạn như Tcl (Ngôn ngữ lệnh của công cụ), C, Perl,
Python, Java và Expect. Phải mất hàng tháng để học một ngôn ngữ
lập trình. Việc phát triển một quy trình tự động hóa sẽ thất bại nếu
người kiểm thử không có các kỹ năng lập trình cần thiết hoặc miễn
cưỡng phát triển nó. Việc thêm nhà thầu tạm thời vào nhóm thử
nghiệm để tự động hóa các trường hợp thử nghiệm có thể không hoạt
động. Các nhà thầu có thể hỗ trợ phát triển các thư viện thử nghiệm
nhưng sẽ không thể duy trì một bộ thử nghiệm tự động trên cơ sở liên
tục.
Cần có đủ ngân sách để mua và duy trì phần mềm và công cụ phần
cứng mới để sử dụng trong tự động hóa thử nghiệm. Tổ chức nên
dành kinh phí để đào tạo nhân viên với các công cụ phần mềm và
phần cứng mới. Các chuyên gia lành nghề với nền tảng tự động hóa
tốt có thể cần được thêm vào nhóm thử nghiệm để thực hiện dự án tự
động hóa thử nghiệm. Do đó, số lượng người đứng đầu bổ sung nên
được lập ngân sách bởi giám đốc điều hành cấp cao của tổ chức.
12.11 ĐÁNH GIÁ VÀ LỰA CHỌN CÁC CÔNG CỤ TỰ ĐỘNG
THỬ NGHIỆM
Công cụ tự động hóa kiểm thử là một ứng dụng phần mềm hỗ trợ tự
động hóa các trường hợp kiểm thử mà nếu không sẽ được chạy theo
cách thủ công. Một số công cụ có sẵn trên thị trường, nhưng để kiểm
tra các hệ thống phức tạp, được nhúng vào thời gian thực, rất ít công
cụ kiểm tra thương mại có sẵn trên thị trường. Do đó, hầu hết các tổ
chức xây dựng các khuôn khổ tự động hóa thử nghiệm của riêng họ
bằng cách sử dụng các ngôn ngữ lập trình như C và Tcl. Điều cần
thiết là kết hợp cả phần cứng và phần mềm để kiểm tra thời gian thực
12.11 ĐÁNH GIÁ VÀ LỰA CHỌN CÁC CÔNG CỤ TỰ ĐỘNG
THỬ NGHIỆM
công cụ. Điều này là do thực tế là các loại thẻ giao diện đặc biệt được
yêu cầu để kết nối với SUT. Khả năng tính toán của máy tính cá nhân
có card giao diện mạng có thể không đủ tốt để gửi lưu lượng đến
SUT.
Các chuyên gia kiểm tra thường xây dựng các công cụ kiểm tra của
riêng họ trong các lĩnh vực công nghệ cao, chẳng hạn như thiết bị
545
viễn thông và ứng dụng dựa trên IP. Các công cụ kiểm tra thương mại
của bên thứ ba thường không khả dụng trong giai đoạn kiểm tra hệ
thống. Ví dụ, không có công cụ kiểm tra nào được bán trên thị trường
trong quá trình thử nghiệm hệ thống 1xEv-DO được mô tả trong
Chương 8. Tác giả thứ hai của cuốn sách này đã phát triển các công
cụ phần mềm nội bộ để mô phỏng các thiết bị đầu cuối truy cập bằng
cách sử dụng các sản phẩm của chính họ. Tuy nhiên, chúng tôi ủng
hộ rằng người thử nghiệm chỉ nên xây dựng các công cụ tự động hóa
thử nghiệm của riêng họ nếu họ không có giải pháp thay thế. Xây
dựng và duy trì công cụ tự động hóa thử nghiệm của riêng mình từ
đầu là những công việc tốn thời gian và là một công việc tốn kém.
Các tiêu chí đánh giá công cụ kiểm tra được xây dựng để lựa chọn
loại công cụ phần mềm phù hợp. Có thể không có công cụ đáp ứng
tất cả các tiêu chí. Do đó, chúng ta nên linh hoạt một chút trong quá
trình đánh giá các công cụ tự động hóa có sẵn trên thị trường. Các
tiêu chí rộng rãi để đánh giá các công cụ tự động hóa thử nghiệm đã
được phân loại thành tám loại sau như thể hiện trong Hình 12.3.
Tiêu chí phát triển thử nghiệm: Một công cụ kiểm tra tự động hóa
phải cung cấp ngôn ngữ kịch bản kiểm tra cấp cao, tốt nhất là không
độc quyền, dễ sử dụng, chẳng hạn như Tcl. Nó phải có khả năng giao
diện và điều khiển các mô-đun có thể được viết dễ dàng, chẳng hạn
như C, Tcl, Perl hoặc Visual Basic. Công cụ phải cung cấp cơ sở để
truy cập trực tiếp, đọc, sửa đổi và kiểm soát nội bộ của các tập lệnh
kiểm tra tự động. Dữ liệu thử nghiệm đầu vào nên được lưu trữ riêng
biệt với tập lệnh thử nghiệm nhưng dễ dàng tham chiếu chéo đến các
tập lệnh thử nghiệm tương ứng, nếu cần. Công cụ này nên có sẵn các
mẫu kịch bản thử nghiệm, trường hợp thử nghiệm, hướng dẫn và ví
dụ ứng dụng demo để chỉ ra cách phát triển các trường hợp thử
nghiệm tự động. Cuối cùng, không nên thực hiện thay đổi nào đối với
SUT để sử dụng công cụ. Của nhà cung cấp
Test development
Test maintenance Tool

evaluation
Test execution
criteria
Test results
Test management
GUI Testing
capability
Vendor
Qualification
Pricing
Hình 12.3 Các tiêu chí rộng của việc đánh giá công cụ tự động
hóa thử nghiệm.
môi trường được khuyến nghị phải phù hợp với môi trường thực hiện
trong phòng thí nghiệm thử nghiệm thực tế.
Tiêu chí Bảo trì Kiểm tra: Công cụ phải có một bộ tính năng phong
phú, chẳng hạn như khả năng kiểm soát phiên bản trên các trường
hợp thử nghiệm, dữ liệu thử nghiệm và di chuyển các trường hợp thử
nghiệm trên các nền tảng khác nhau. Công cụ phải cung cấp các
phương tiện mạnh mẽ, dễ sử dụng để duyệt, điều hướng, sửa đổi và
sử dụng lại các bộ thử nghiệm. Công cụ phải có khả năng chọn một
tập hợp con các trường hợp thử nghiệm để tạo thành một nhóm cho
một lần chạy thử nghiệm cụ thể dựa trên một hoặc nhiều đặc điểm
phân biệt. Một công cụ cần có các tính năng để cho phép sửa đổi và
nhân rộng các trường hợp thử nghiệm, dễ dàng bổ sung các trường
hợp thử nghiệm mới và nhập từ một trường hợp khác. Công cụ phải
có khả năng thêm nhiều thẻ vào một trường hợp thử nghiệm và sửa
đổi các thẻ đó để trường hợp thử nghiệm có thể dễ dàng được chọn
trong một nhóm con các trường hợp thử nghiệm có chung một đặc
điểm.
Tiêu chí thực thi thử nghiệm: Một công cụ tự động hóa phải cho phép
các trường hợp thử nghiệm được thực thi riêng lẻ, như một nhóm
hoặc theo một trình tự được xác định trước. Người dùng phải có khả
năng kiểm tra các kết quả tạm thời trong quá trình thực hiện một
nhóm các bài kiểm tra và thực hiện các tùy chọn khác cho phần còn
lại của các bài kiểm tra dựa trên các kết quả tạm thời. Người dùng sẽ
547
có tùy chọn tạm dừng và tiếp tục thực thi bộ thử nghiệm. Công cụ
phải có cơ sở để thực thi bộ thử nghiệm qua Internet. Công cụ phải
cho phép thực hiện đồng thời một số bộ thử nghiệm có thể được phân
phối trên nhiều máy để thực hiện song song. Điều này làm giảm đáng
kể thời gian cần thiết để kiểm tra nếu có nhiều máy kiểm tra. Công cụ
kiểm tra phải có khả năng giám sát, đo lường và chẩn đoán các đặc
tính hoạt động của SUT. Cuối cùng, công cụ phải có khả năng được
tích hợp với các công cụ phần mềm khác đang được sử dụng hoặc dự
kiến sử dụng.
Tiêu chí kết quả thử nghiệm: Công cụ thử nghiệm phải cung cấp quy
trình ghi nhật ký linh hoạt, toàn diện trong quá trình thực hiện bộ thử
nghiệm, có thể bao gồm các bản ghi chi tiết của từng trường hợp thử
nghiệm, kết quả thử nghiệm, ngày giờ và dữ liệu chẩn đoán thích
hợp. Một công cụ phải có khả năng tham chiếu chéo các kết quả thử
nghiệm trở lại các phiên bản phù hợp của các trường hợp thử nghiệm.
Nhật ký kết quả thử nghiệm có thể được lưu trữ ở định dạng dữ liệu
tiêu chuẩn của ngành và công cụ phải có một cách hiệu quả để truy
cập và duyệt các kết quả thử nghiệm đã lưu trữ. Công cụ phải cung
cấp khả năng truy vấn để trích xuất kết quả thử nghiệm, phân tích
trạng thái và xu hướng thử nghiệm, đồng thời tạo ra các báo cáo đồ
họa về kết quả thử nghiệm. Cuối cùng, công cụ phải có khả năng thu
thập và phân tích thời gian phản hồi và thông lượng để hỗ trợ kiểm
tra hiệu suất.
Tiêu chí quản lý kiểm thử: Một công cụ phải có khả năng cung cấp
cấu trúc kiểm thử, hoặc hệ thống phân cấp, cho phép các trường hợp
kiểm thử được lưu trữ và truy xuất theo cách mà tổ chức kiểm thử
muốn tổ chức. Công cụ phải có khả năng phân bổ các bài kiểm tra
hoặc nhóm bài kiểm tra cho các kỹ sư kiểm tra cụ thể và so sánh
trạng thái công việc với kế hoạch thông qua hiển thị đồ họa. Một
công cụ cần phải có các tính năng ủy quyền. Ví dụ: một nhà phát triển
tập lệnh thử nghiệm có thể được ủy quyền để tạo và cập nhật các tập
lệnh thử nghiệm, trong khi người thực thi tập lệnh thử nghiệm chỉ có
thể truy cập chúng ở chế độ chạy. Công cụ phải có khả năng gửi
email với kết quả kiểm tra sau khi hoàn thành việc thực thi bộ kiểm
tra.
12.12 HƯỚNG DẪN LỰA CHỌN KIỂM TRA ĐỂ TỰ ĐỘNG
HÓA
Tiêu chí về khả năng kiểm tra GUI: Công cụ kiểm tra GUI tự động
phải bao gồm tính năng ghi / phát lại cho phép các kỹ sư kiểm tra tạo,
sửa đổi và chạy các bài kiểm tra tự động trên nhiều môi trường. Các
công cụ này phải có khả năng nhận dạng và xử lý tất cả các loại đối
tượng GUI, chẳng hạn như hộp danh sách, nút radio, biểu tượng, cần
điều khiển, phím nóng và hình ảnh bản đồ bit với những thay đổi về
sắc thái màu và phông chữ trình bày. Hoạt động ghi lại của công cụ
ghi lại các tổ hợp phím do kỹ sư thử nghiệm nhập vào có thể được
biểu diễn dưới dạng tập lệnh bằng ngôn ngữ lập trình cấp cao và được
lưu để phát lại trong tương lai. Các công cụ này phải cho phép các kỹ
sư kiểm tra sửa đổi các kịch bản kiểm thử để tạo ra các quy trình
kiểm tra có thể sử dụng lại được để phát lại trên một hình ảnh phần
mềm mới để so sánh. Hiệu suất của một công cụ kiểm tra GUI cần
được đánh giá. Người ta có thể cân nhắc câu hỏi: Công cụ có thể ghi
và phát lại một kịch bản thử nghiệm phức tạp hoặc một nhóm các
kịch bản thử nghiệm nhanh đến mức nào?
Tiêu chí Chứng nhận Nhà cung cấp: Nhiều câu hỏi cần được đặt ra về
sự ổn định tài chính của nhà cung cấp, độ tuổi của công ty cung cấp
và khả năng hỗ trợ công cụ của nhà cung cấp. Nhà cung cấp phải sẵn
sàng sửa chữa các vấn đề phát sinh với công cụ. Phải có một lộ trình
tương lai cho sản phẩm. Cuối cùng, sự trưởng thành và thị phần của
sản phẩm phải được đánh giá.
Tiêu chí định giá: Định giá là một khía cạnh quan trọng của tiêu chí
đánh giá sản phẩm. Người ta có thể đặt một số câu hỏi: Giá cả có
cạnh tranh không? Nó có nằm trong phạm vi giá ước tính cho một lần
mua công cụ ban đầu không? Đối với một số lượng lớn giấy phép, có
thể thương lượng chiết khấu giá với nhà cung cấp. Cuối cùng, giấy
phép phải giới hạn rõ ràng chi phí bảo trì của công cụ thử nghiệm từ
năm này sang năm khác.
Các nhà cung cấp công cụ có thể đảm bảo chức năng của công cụ thử
nghiệm; tuy nhiên, kinh nghiệm cho thấy rằng các công cụ tự động
hóa kiểm tra thường không hoạt động như mong đợi trong môi trường
kiểm tra cụ thể. Vì vậy, bạn nên đánh giá công cụ kiểm tra bằng cách
sử dụng nó trước khi đưa ra quyết định mua nó. Trưởng nhóm thử
nghiệm cần liên hệ với nhà cung cấp công cụ để yêu cầu trình diễn.
Sau khi trình diễn công cụ, nếu nhóm thử nghiệm tin rằng công cụ đó
có tiềm năng, thì trưởng nhóm thử nghiệm có thể yêu cầu giấy phép
549
tạm thời của công cụ đó để đánh giá. Tại thời điểm này, đủ nguồn lực
được phân bổ để đánh giá công cụ kiểm tra. Người đánh giá cần hiểu
rõ về các yêu cầu của công cụ và nên lập kế hoạch đánh giá thử
nghiệm dựa trên các tiêu chí đã nêu trước đó. Mục tiêu ở đây là đảm
bảo rằng công cụ kiểm tra hoạt động như quảng cáo của nhà cung cấp
và công cụ đó là sản phẩm tốt nhất cho yêu cầu. Sau quá trình đánh
giá thực hành, một báo cáo đánh giá được chuẩn bị. Báo cáo ghi lại
trải nghiệm thực tế với công cụ này. Báo cáo này phải chứa thông tin
cơ bản, tóm tắt công cụ, phát hiện kỹ thuật và kết luận. Tài liệu này
được thiết kế để giải quyết các mối quan tâm của ban quản lý vì cuối
cùng nó phải được ban lãnh đạo điều hành phê duyệt.
12.12 HƯỚNG DẪN LỰA CHỌN KIỂM TRA ĐỂ TỰ ĐỘNG
HÓA
Các trường hợp kiểm thử chỉ nên được tự động hóa nếu có lợi ích
kinh tế rõ ràng so với việc thực hiện thủ công. Một số trường hợp
kiểm thử dễ tự động hóa trong khi những trường hợp khác lại cồng
kềnh hơn.
Hướng dẫn chung thể hiện trong Hình 12.4 có thể được sử dụng để
đánh giá tính phù hợp của các trường hợp thử nghiệm được tự động
hóa như sau:
Ít biến động: Một trường hợp thử nghiệm là ổn định và không có khả
năng thay đổi theo thời gian. Trường hợp thử nghiệm nên được thực
thi thủ công trước đó. Dự kiến rằng các bước kiểm tra và tiêu chí đạt -
không đạt sẽ không thay đổi nữa.
Khả năng lặp lại: Các trường hợp kiểm thử sẽ được thực hiện nhiều
lần nên được tự động hóa. Tuy nhiên, các trường hợp kiểm thử một
lần không nên được coi là tự động hóa. Các trường hợp kiểm thử
được thiết kế kém có xu hướng khó sử dụng lại không kinh tế cho quá
trình tự động hóa.
Rủi ro cao: Các trường hợp thử nghiệm rủi ro cao là những trường
hợp được chạy lại thường xuyên sau mỗi lần xây dựng phần mềm
mới. Các mục tiêu của các trường hợp thử nghiệm này quan trọng đến
mức người ta không thể không thực thi lại chúng. Trong một số
trường hợp, xu hướng phá vỡ các trường hợp thử nghiệm là rất cao.
Những trường hợp thử nghiệm này có khả năng mang lại hiệu quả về
lâu dài và là những ứng cử viên thích hợp cho tự động hóa.
Dễ dàng tự động hóa: Các trường hợp kiểm thử dễ tự động hóa bằng
cách sử dụng các công cụ tự động hóa nên được tự động hóa. Một số
tính năng của hệ thống dễ kiểm tra hơn các tính năng khác, dựa trên
đặc điểm của một công cụ cụ thể. Các đối tượng tùy chỉnh với các
tính năng đồ họa và âm thanh có thể sẽ đắt hơn để tự động hóa.
Khó thực hiện theo cách thủ công: Các trường hợp kiểm thử rất khó
thực hiện theo cách thủ công nên được tự động hóa. Việc thực hiện
thử nghiệm thủ công là một vấn đề lớn, chẳng hạn như gây mỏi mắt
do phải nhìn vào quá nhiều màn hình quá lâu trong thử nghiệm GUI.
Thật vất vả khi xem xét các kết quả nhất thời trong các ứng dụng thời
gian thực. Những trường hợp thử nghiệm khó chịu, khó chịu này là
những ứng cử viên tốt cho tự động hóa.
Nhàm chán và tiêu tốn thời gian: Các trường hợp thử nghiệm có tính
chất lặp đi lặp lại và cần được thực hiện trong thời gian dài hơn nên
được tự động hóa. Thời gian của người thử nghiệm nên được sử dụng
để phát triển các trường hợp thử nghiệm sáng tạo và hiệu quả hơn.
Less volatile
Repeatability
Guidelines
High risk for test
automation
Easy to automate
Manually dificult
Boring and time

consuming
Hình 12.4 Hướng dẫn lựa chọn thử nghiệm cho tự động hóa.
12.13 ĐẶC ĐIỂM CỦA CÁC TRƯỜNG HỢP KIỂM TRA TỰ
ĐỘNG
12.13 ĐẶC ĐIỂM CỦA CÁC TRƯỜNG HỢP KIỂM TRA TỰ
ĐỘNG
Thành phần lớn nhất của tự động hóa trường hợp thử nghiệm là lập
trình. Trừ khi các trường hợp kiểm thử được thiết kế và mã hóa đúng
cách, việc thực thi và bảo trì chúng có thể không hiệu quả. Các đặc
điểm thiết kế của các trường hợp kiểm thử hiệu quả đã được thảo luận
trong Chương 11. Một mô hình chính thức của lược đồ trường hợp
kiểm thử tiêu chuẩn cũng được cung cấp trong Chương 11. Trong
551
phần này, chúng tôi bao gồm một số điểm chính phù hợp với việc mã
hóa các trường hợp kiểm thử. Các đặc điểm của các trường hợp kiểm
thử tự động tốt được đưa ra trong Hình 12.5 và được giải thích như
sau.
Đơn giản: Trường hợp kiểm tra nên có một mục tiêu duy nhất. Các
trường hợp kiểm tra đa tính rất khó hiểu và khó thiết kế. Không được
có nhiều hơn 10–15 bước thử nghiệm cho mỗi trường hợp thử
nghiệm, không bao gồm các bước thiết lập và dọn dẹp. Các trường
hợp thử nghiệm đa năng có khả năng bị phá vỡ hoặc cho kết quả sai
lệch. Nếu việc thực hiện một bài kiểm tra phức tạp dẫn đến sự cố hệ
thống, thì rất khó để cô lập nguyên nhân của sự cố.
Mô-đun: Mỗi trường hợp thử nghiệm phải có một giai đoạn thiết lập
và dọn dẹp trước và sau các bước thử nghiệm thực thi, tương ứng.
Giai đoạn thiết lập đảm bảo rằng các điều kiện ban đầu được đáp ứng
trước khi bắt đầu các bước kiểm tra. Tương tự, giai đoạn dọn dẹp đặt
hệ thống trở lại trạng thái ban đầu, tức là trạng thái trước khi thiết lập.
Mỗi bước kiểm tra phải nhỏ và chính xác. Mỗi lần nên cung cấp một
kích thích đầu vào cho hệ thống và phản hồi được xác minh (nếu có)
với một phán quyết tạm thời. Các bước kiểm tra là xây dựng các khối
từ các thư viện có thể tái sử dụng được ghép lại với nhau để tạo thành
các trường hợp kiểm thử nhiều bước.
Mạnh mẽ và đáng tin cậy: Phán quyết trường hợp thử nghiệm (đạt -
không đạt) nên được chỉ định theo cách rõ ràng và dễ hiểu. Các
trường hợp thử nghiệm mạnh mẽ có thể bỏ qua các lỗi nhỏ như không
khớp một pixel trong màn hình đồ họa. Cần cẩn thận để giảm thiểu
kết quả thử nghiệm sai lệch. Các trường hợp kiểm thử phải có cơ chế
tích hợp để phát hiện và khôi phục lỗi. Ví dụ, một trường hợp thử
nghiệm
Simple
Modular
Robust Characteristics
and reliable
Reusable
Maintainable
Documented
Independent and
self-sufficient
Hình 12.5 Đặc điểm của các trường hợp kiểm thử tự động.
không cần phải chờ vô thời hạn nếu SUT bị lỗi. Thay vào đó, nó có
thể đợi một lúc và chấm dứt thời gian chờ vô thời hạn bằng cách sử
dụng cơ chế hẹn giờ.
Có thể tái sử dụng: Các bước kiểm tra được xây dựng để có thể cấu
hình được, nghĩa là các biến không được mã hóa cứng. Chúng có thể
lấy các giá trị từ một tệp có thể định cấu hình. Cần chú ý trong khi mã
hóa các bước kiểm tra để đảm bảo rằng một biến toàn cục duy nhất
được sử dụng, thay vì nhiều biến được mã hóa cứng, phi tập trung.
Các bước kiểm tra được thực hiện độc lập với môi trường kiểm tra
nhất có thể. Các trường hợp thử nghiệm tự động được phân loại thành
các nhóm khác nhau để các tập hợp con của các bước thử nghiệm và
trường hợp thử nghiệm có thể được trích xuất để sử dụng lại cho các
nền tảng và / hoặc cấu hình khác. Cuối cùng, trong GUI tự động hóa
các vị trí màn hình được mã hóa cứng phải được tránh.
Có thể bảo trì: Bất kỳ thay đổi nào đối với SUT sẽ có tác động đến
các trường hợp thử nghiệm tự động và có thể yêu cầu thực hiện các
thay đổi cần thiết đối với các trường hợp thử nghiệm bị ảnh hưởng.
Do đó, cần phải tiến hành đánh giá các trường hợp kiểm thử cần sửa
đổi trước khi phê duyệt dự án thay đổi hệ thống. Bộ thử nghiệm nên
được tổ chức và phân loại theo cách để dễ dàng xác định các trường
hợp thử nghiệm bị ảnh hưởng. Nếu một trường hợp thử nghiệm cụ
thể là theo hướng dữ liệu, thì dữ liệu thử nghiệm đầu vào được lưu
trữ riêng biệt với trường hợp thử nghiệm và được quy trình thử
nghiệm truy cập khi cần thiết. Các trường hợp kiểm thử phải tuân thủ
các định dạng tiêu chuẩn mã hóa. Cuối cùng, tất cả các trường hợp
thử nghiệm phải được kiểm soát bằng hệ thống kiểm soát phiên bản.
553
Được lập thành tài liệu: Các trường hợp kiểm thử và các bước kiểm
tra phải được ghi chép đầy đủ. Mỗi trường hợp thử nghiệm có một số
nhận dạng duy nhất và mục đích thử nghiệm là rõ ràng và dễ hiểu.
Tên người tạo, ngày tạo và lần cuối cùng nó được sửa đổi phải được
ghi lại. Phải có khả năng truy xuất nguồn gốc đối với các tính năng và
yêu cầu đang được kiểm tra bởi trường hợp thử nghiệm. Tình huống
mà trường hợp kiểm thử không thể được sử dụng được mô tả rõ ràng.
Các yêu cầu về môi trường được nêu rõ ràng với nguồn dữ liệu thử
nghiệm đầu vào (nếu có). Cuối cùng, kết quả, tức là đạt hay không
đạt, các tiêu chí đánh giá được mô tả rõ ràng.
Độc lập và tự đủ: Mỗi trường hợp thử nghiệm được thiết kế như một
thực thể gắn kết và các trường hợp thử nghiệm phải độc lập với nhau.
Mỗi trường hợp thử nghiệm bao gồm các bước thử nghiệm được liên
kết với nhau một cách tự nhiên. Tiền thân và kế thừa của bước kiểm
thử trong trường hợp kiểm thử cần được hiểu rõ ràng. Sẽ rất hữu ích
nếu giữ ba quy tắc độc lập sau trong khi tự động hóa các trường hợp
thử nghiệm:
Độc lập với giá trị dữ liệu: Việc dữ liệu có thể bị hỏng liên quan đến
một trường hợp thử nghiệm sẽ không ảnh hưởng đến các trường hợp
thử nghiệm khác.
Không độc lập với sự cố: Sự thất bại của một trường hợp thử nghiệm
không được gây ra một loạt các lỗi trong số lượng lớn các trường hợp
thử nghiệm tiếp theo.
Trạng thái cuối cùng độc lập: Trạng thái trong đó môi trường được để
lại bởi một trường hợp thử nghiệm sẽ không có tác động đến các
trường hợp thử nghiệm sẽ được thực thi sau này.
Chúng ta phải xem xét các đặc điểm được nêu trong phần này trong
quá trình phát triển các kịch bản thử nghiệm. Ngoài ra, chúng ta phải
tuân theo cú pháp của trường hợp kiểm thử được xác định trong phần
tiếp theo trong khi thực hiện một trường hợp kiểm thử.
12.14 CẤU TRÚC CỦA MỘT TRƯỜNG HỢP KIỂM TRA TỰ
ĐỘNG
12.14 CẤU TRÚC CỦA MỘT TRƯỜNG HỢP KIỂM TRA TỰ
ĐỘNG
Một trường hợp thử nghiệm tự động bắt chước các hành động của
người thử nghiệm trong việc tạo điều kiện ban đầu để thực hiện thử
nghiệm, nhập dữ liệu đầu vào để điều khiển thử nghiệm, thu nhận đầu
ra, đánh giá kết quả và cuối cùng là khôi phục hệ thống trở lại trạng
thái ban đầu. Sáu bước chính trong một trường hợp kiểm thử tự động
được thể hiện trong Hình 12.6. Các quy trình xử lý lỗi được kết hợp
trong mỗi bước để tăng khả năng bảo trì và tính ổn định của các
Thiết lập: Thiết lập bao gồm các bước để kiểm tra phần cứng, môi
trường mạng, cấu hình phần mềm và SUT đang chạy. Ngoài ra, tất cả
các tham số của SUT cụ thể cho trường hợp thử nghiệm được cấu
hình. Các biến khác liên quan đến trường hợp thử nghiệm được khởi
tạo.
Lái xe Kiểm tra: Bài kiểm tra được thúc đẩy bằng cách cung cấp dữ
liệu đầu vào cho SUT. Nó có thể là một bước hoặc nhiều bước. Dữ
liệu đầu vào phải được tạo theo cách mà SUT có thể đọc, hiểu và
phản hồi.
Ghi lại phản hồi: Phản hồi từ SUT được ghi lại và lưu lại. Có thể yêu
cầu thao tác dữ liệu đầu ra từ hệ thống để trích xuất thông tin liên
quan đến mục tiêu của trường hợp thử nghiệm.
Xác định Nhận định: Kết quả thực tế được so sánh với kết quả mong
đợi. Các quy tắc quyết định định trước được áp dụng để đánh giá bất
kỳ sự khác biệt nào giữa kết quả thực tế so với kết quả dự kiến và
quyết định xem kết quả thử nghiệm là đạt hay không đạt. Nếu một kết
quả không thành công được chỉ định cho trường hợp thử nghiệm, thì
thông tin chẩn đoán bổ sung là cần thiết. Người ta phải cẩn thận trong
việc thiết kế các quy tắc để gán một phán quyết đạt / không đạt cho
một trường hợp thử nghiệm. Quy trình thử nghiệm thất bại không
nhất thiết chỉ ra vấn đề với SUT — vấn đề có thể là dương tính giả.
Tương tự, một quy trình kiểm tra được thông qua không nhất thiết chỉ
ra rằng không có vấn đề với SUT — vấn đề có thể là do âm tính giả.
Các vấn đề về âm tính giả và dương tính giả có thể xảy ra do một số
lý do,
555
Setup
Drive the test

Steps in an
Capture the
automated
response
test case
Determine the
verdict
Log the verdict
Cleanup
Hình 12.6 Sáu bước chính trong trường hợp kiểm thử tự động.
chẳng hạn như lỗi thiết lập, lỗi thủ tục kiểm tra, lỗi logic tập lệnh
kiểm tra hoặc lỗi người dùng [18].
Ghi lại Phán quyết: Một bản ghi chi tiết về kết quả được ghi vào một
tệp nhật ký. Nếu trường hợp thử nghiệm không thành công, thông tin
chẩn đoán bổ sung là cần thiết, chẳng hạn như thông tin môi trường
tại thời điểm xảy ra sự cố, có thể hữu ích trong việc tái tạo sự cố sau
này.
Dọn dẹp: Hành động dọn dẹp bao gồm các bước để khôi phục SUT
về trạng thái ban đầu để có thể thực thi trường hợp thử nghiệm tiếp
theo. Các bước thiết lập và dọn dẹp trong trường hợp thử nghiệm cần
phải hiệu quả để giảm chi phí thực thi thử nghiệm.
12.15 KIỂM TRA CƠ SỞ HẠ TẦNG TỰ ĐỘNG HÓA
Cơ sở hạ tầng hoặc khuôn khổ tự động hóa thử nghiệm bao gồm các
công cụ thử nghiệm, thiết bị, tập lệnh thử nghiệm, quy trình và những
người cần thiết để thực hiện tự động hóa thử nghiệm hiệu quả và hiệu
quả. Việc tạo và duy trì một khuôn khổ tự động hóa thử nghiệm là
chìa khóa cho sự thành công của bất kỳ dự án tự động hóa thử
nghiệm nào trong một tổ chức. Việc triển khai một khuôn khổ tự
động hóa thường yêu cầu một nhóm kiểm thử tự động hóa, như đã
thảo luận trong Chương 16. Sáu thành phần của một khung tự động
hóa thử nghiệm được thể hiện trong Hình 12.7. Ý tưởng đằng sau cơ
sở hạ tầng tự động hóa là đảm bảo những điều sau:
Các công cụ và thiết bị kiểm tra khác nhau được phối hợp để làm việc
cùng nhau.
Thư viện các kịch bản trường hợp thử nghiệm hiện có có thể được sử
dụng lại cho các dự án thử nghiệm khác nhau, do đó giảm thiểu sự
trùng lặp trong nỗ lực phát triển.
Không ai tạo kịch bản thử nghiệm theo cách của riêng họ.
Tính nhất quán được duy trì trên các tập lệnh thử nghiệm.
Quá trình tự động hóa bộ thử nghiệm được phối hợp để nó có sẵn
trong thời gian thích hợp cho thử nghiệm hồi quy.
Mọi người hiểu trách nhiệm của họ trong kiểm thử tự động.
Hệ thống được kiểm tra: Đây là thành phần đầu tiên của cơ sở hạ tầng
tự động hóa. Các hệ thống con của hệ thống được kiểm tra phải ổn
định; nếu không tự động hóa kiểm tra sẽ không hiệu quả về chi phí.
Ví dụ, hệ thống 1xEV-DO được
System to mô tả trong Chương 8 bao gồm ba
be tested
hệ thống con, BTS, BSC và EMS.
Tất cả ba hệ thống con phải ổn
Test
Administrator
platform định và hoạt động cùng nhau trước
khi bắt đầu một dự án thử nghiệm
Components
tự động hóa.
Nền tảng thử nghiệm: Nền tảng thử
Tools Test nghiệm và các phương tiện, nghĩa
library
là, thiết lập mạng mà hệ thống sẽ
Automated
testing được thử nghiệm, phải có sẵn để
practices thực hiện dự án tự động hóa thử
nghiệm. Ví dụ: cần có quy trình tải
xuống hình ảnh của SUT, tiện ích quản lý cấu hình, máy chủ, máy
khách, bộ định tuyến, bộ chuyển mạch và trung tâm để thiết lập môi
trường tự động hóa để thực thi các tập lệnh thử nghiệm.
12.15 KIỂM TRA CƠ SỞ HẠ TẦNG TỰ ĐỘNG HÓA
Hình 12.7 Các thành phần của cơ sở hạ tầng tự động hóa.
Thư viện trường hợp thử nghiệm: Sẽ rất hữu ích khi biên dịch thư
viện các bước thử nghiệm có thể sử dụng lại của các tiện ích cơ bản
để được sử dụng như các khối xây dựng của tập lệnh thử nghiệm tự
động. Mỗi tiện ích thường thực hiện một nhiệm vụ riêng biệt để hỗ
trợ tự động hóa các trường hợp thử nghiệm. Ví dụ về các tiện ích như
vậy là ssh (shell an toàn) từ máy khách đến máy chủ, thoát từ máy
khách đến máy chủ, thu thập phản hồi, trích xuất thông tin, quy tắc
phán quyết, ghi nhật ký phán quyết, ghi lỗi, dọn dẹp và thiết lập.
557
Thực hành kiểm thử tự động: Các thủ tục mô tả cách tự động hóa các
trường hợp kiểm thử bằng cách sử dụng các công cụ kiểm thử và thư
viện trường hợp kiểm thử phải được lập thành văn bản. Mẫu của một
trường hợp kiểm thử tự động rất hữu ích để có được sự nhất quán trên
tất cả các trường hợp kiểm thử tự động được phát triển bởi các kỹ sư
khác nhau. Danh sách tất cả các tiện ích và hướng dẫn sử dụng chúng
sẽ cho phép chúng tôi đạt được hiệu quả tốt hơn trong tự động hóa
thử nghiệm. Ngoài ra, quy trình bảo trì thư viện phải được lập thành
văn bản.
Công cụ: Cần có các loại công cụ khác nhau để phát triển các kịch
bản thử nghiệm. Ví dụ về các công cụ đó là công cụ tự động hóa kiểm
tra, công cụ tạo lưu lượng, công cụ giám sát lưu lượng và công cụ hỗ
trợ. Các công cụ hỗ trợ bao gồm nhà máy thử nghiệm, phân tích yêu
cầu, theo dõi lỗi và các công cụ quản lý cấu hình. Việc tích hợp tự
động hóa thử nghiệm và các công cụ hỗ trợ, chẳng hạn như theo dõi
lỗi, là rất quan trọng để báo cáo tự động các lỗi cho các trường hợp
thử nghiệm không thành công. Tương tự, công cụ nhà máy thử
nghiệm có thể tạo ra các xu hướng thực hiện thử nghiệm tự động và
các mẫu kết quả.
Quản trị viên: Người quản trị khung tự động hóa (i) quản lý thư viện
trường hợp thử nghiệm, nền tảng thử nghiệm và công cụ thử nghiệm;
(ii) duy trì kho mẫu; (iii) cung cấp các hướng dẫn; và (iv) giúp các kỹ
sư kiểm thử viết kịch bản kiểm thử bằng cách sử dụng các thư viện
trường hợp thử nghiệm. Ngoài ra, quản trị viên cung cấp hỗ trợ
hướng dẫn cho người sử dụng các công cụ kiểm tra và duy trì mối
liên hệ với các nhà cung cấp công cụ và người dùng.
12.16 TÓM TẮT
Chương này tập trung vào tầm quan trọng của một kế hoạch kiểm tra
hệ thống. Chúng tôi đã trình bày phác thảo kế hoạch kiểm tra hệ
thống bao gồm giới thiệu, mô tả tính năng, giả định, cách tiếp cận,
cấu trúc bộ kiểm thử, môi trường kiểm tra, chiến lược thực thi, ước
tính nỗ lực kiểm tra, lập lịch và các mốc quan trọng. Chúng tôi đã
thảo luận về các quy trình để tạo ra một kế hoạch như vậy.
Chương này đã trình bày một mô hình quy trình hiệu quả để thực
hiện kiểm thử hệ thống phần mềm. Ý tưởng chính trong mô hình quy
trình này là nâng cao chất lượng của một hệ thống từ mức thấp ban
đầu lên mức cao cuối cùng trong một số bước được kiểm soát được
gọi là chu kỳ kiểm tra. Chúng tôi đã mô tả một chu kỳ thử nghiệm
theo sáu tham số: mục tiêu, giả định, thực thi thử nghiệm, tiêu chí
hoàn nguyên và mở rộng, tiêu chí hành động và thoát. Các thông số
này cho phép người quản lý kiểm tra kiểm soát hiệu quả tiến độ kiểm
tra hệ thống để hệ thống tiến gần hơn một bước đến mức chất lượng
cuối cùng. Chúng tôi đã giải thích một tiêu chí đầu vào cho chúng tôi
biết khi nào thử nghiệm hệ thống nên bắt đầu. Chúng tôi đã trình bày
các kỹ thuật mới để ưu tiên các trường hợp thử nghiệm từ chu kỳ thử
nghiệm đến chu kỳ thử nghiệm và lựa chọn các trường hợp thử
nghiệm để kiểm tra hồi quy trong chu kỳ thử nghiệm cuối cùng. Các
giá trị điển hình của các tham số đã được đưa ra cho các dự án thử
nghiệm dựa trên ba chu kỳ.
Chúng tôi đã thảo luận về các kỹ thuật, chẳng hạn như các điểm chức
năng, để ước tính số lượng trường hợp thử nghiệm cho một dự án thử
nghiệm với các ví dụ cụ thể. Các hướng dẫn để ước tính thời gian cần
thiết để tạo và thực hiện các trường hợp kiểm thử cấp hệ thống đã
được đề xuất. Chúng tôi đã trình bày các cách sử dụng biểu đồ Gantt
để tạo lịch trình thử nghiệm hệ thống và các mốc quan trọng cho dự
án thử nghiệm.
Tiếp theo, chúng tôi đã phác thảo các lợi ích của tự động hóa thử
nghiệm: (i) năng suất của kỹ sư thử nghiệm, (ii) phạm vi kiểm tra hồi
quy, (iii) khả năng tái sử dụng của các trường hợp thử nghiệm, (iv)
tính nhất quán trong thử nghiệm, (v) giảm khoảng thời gian thử
nghiệm, (vi) giảm chi phí bảo trì phần mềm và (vii) tăng hiệu quả
kiểm tra. Năm điều kiện tiên quyết sau đây phải được xem xét khi
đánh giá xem tổ chức thử nghiệm đã sẵn sàng cho việc tự động hóa
thử nghiệm hay chưa:
Hệ thống ổn định và các chức năng được xác định rõ ràng.
Các trường hợp kiểm thử cần được tự động hóa đã được xác định rõ.
công trước đó với tự động hóa.
Ngân sách thích hợp đã được phân bổ cho việc mua sắm các công cụ
phần mềm.
Chúng tôi đã trình bày một quy trình để đánh giá và lựa chọn các
công cụ kiểm tra của bên thứ ba có sẵn trên thị trường. Các tiêu chí
559
đánh giá công cụ thử nghiệm được phân loại thành tám loại: (i) phát
triển thử nghiệm, (ii) bảo trì thử nghiệm, (iii) thực hiện thử nghiệm,
(iv) kết quả thử nghiệm, (v) quản lý thử nghiệm, (vi) Khả năng thử
nghiệm GUI, (vii ) trình độ của nhà cung cấp và (viii) giá cả. Các tiêu
chí này được xây dựng để chọn đúng loại công cụ kiểm tra phần
mềm. Chúng tôi ủng hộ rằng các kỹ sư thử nghiệm chỉ nên xây dựng
các công cụ tự động hóa thử nghiệm của riêng họ nếu họ không có
giải pháp thay thế. Việc xây dựng và duy trì công cụ tự động hóa thử
nghiệm của riêng mình từ đầu tốn nhiều thời gian và là một công việc
tốn kém. Không có điểm nào trong
phát minh lại bánh xe nếu có sẵn các công cụ kiểm tra sẵn có đáp ứng
các tiêu chí.
Chúng tôi đã cung cấp các nguyên tắc chung để được sử dụng trong
việc lựa chọn các trường hợp thử nghiệm có thể được tự động hóa.
Các đặc điểm của các trường hợp kiểm thử có thể tự động hóa như
sau: ít biến động, lặp lại, rủi ro cao, dễ tự động hóa, khó thực hiện thủ
công, nhàm chán và tốn thời gian. Chúng tôi đã thảo luận về các đặc
điểm của các trường hợp kiểm thử tự động: đơn giản, mô-đun, có thể
tái sử dụng, có thể bảo trì, được lập thành tài liệu, tính mạnh mẽ,
đáng tin cậy và độc lập và tự cung cấp.
Cuối cùng, chúng tôi đã mô tả cấu trúc của một trường hợp thử
nghiệm tự động, bao gồm thiết lập, điều khiển thử nghiệm, ghi lại
phản hồi, xác định phán quyết, ghi lại kết quả và dọn dẹp. Chúng tôi
đã giải thích sự cần thiết của cơ sở hạ tầng tự động hóa thử nghiệm.
Chúng tôi đã cung cấp sáu thành phần của khuôn khổ tự động hóa
kiểm tra: (i) hệ thống được kiểm tra, (ii) nền tảng kiểm tra, (iii) thư
viện trường hợp kiểm thử, (iv) các thực hành kiểm thử tự động, (v)
các công cụ và ( vi) quản trị viên.
Mẫu kế hoạch kiểm tra chung đã được mô tả trong tiêu chuẩn IEEE
829-1983 (Tiêu chuẩn IEEE cho Tài liệu kiểm tra phần mềm: Tiêu
chuẩn IEEE / ANSI). Các chủ đề khác được mô tả trong tiêu chuẩn là
thông số kỹ thuật thiết kế thử nghiệm, thông số kỹ thuật trường hợp
thử nghiệm, thông số kỹ thuật quy trình thử nghiệm, báo cáo truyền
tải vật phẩm thử nghiệm và báo cáo kết quả thử nghiệm. Sau đây là
các phần của kế hoạch thử nghiệm như được định nghĩa trong tiêu
chuẩn:
Mã định danh kế hoạch kiểm tra: Một mã định danh duy nhất, hữu
ích nếu tất cả các tài liệu được lưu trữ trong cơ sở dữ liệu.
Giới thiệu: Mô tả tổng thể về dự án thử nghiệm. Điều này bao gồm
các tham chiếu đến tất cả các tài liệu liên quan.
Các hạng mục cần kiểm tra: Danh sách các thực thể (chức năng,
mô-đun, hệ thống và hệ thống con) sẽ được kiểm tra. Danh sách bao
gồm các tham chiếu đến thông số kỹ thuật và hướng dẫn sử dụng.
Các tính năng sẽ được kiểm tra: Xác định các tính năng sẽ được
kiểm tra. Tham khảo chéo chúng với các thông số kỹ thuật thiết kế
thử nghiệm.
Các tính năng không được kiểm tra: Cái nào và tại sao không.
Phương pháp tiếp cận: Mô tả cách tiếp cận tổng thể để kiểm tra.
Tiêu chuẩn cũng nói rằng phần này — chứ không phải phần lịch trình
— là nơi để xác định các ràng buộc, bao gồm thời hạn và sự sẵn có
của các nguồn lực (con người và thiết bị).
Tiêu chí Đạt / Không đạt: Một tập hợp các tiêu chí để quyết định
trường hợp kiểm thử đạt hay không đạt khi thực thi.
Tiêu chí Tạm dừng và Tiếp tục: Danh sách bất kỳ điều gì có thể
khiến thử nghiệm ngừng cho đến khi nó được khắc phục. Bạn sẽ phải
làm gì để tiếp tục thử nghiệm? Những thử nghiệm nào nên được thực
hiện lại vào thời điểm này?
Test Deliverables: Danh sách tất cả các tài liệu thử nghiệm sẽ được
viết cho dự án này.
Nhiệm vụ kiểm tra: Danh sách tất cả các nhiệm vụ cần thiết để
chuẩn bị và tiến hành kiểm tra. Chỉ ra sự phụ thuộc giữa các nhiệm
vụ, các kỹ năng đặc biệt cần thiết để thực hiện chúng, ai thực hiện
từng nhiệm vụ, mức độ nỗ lực tham gia và thời điểm hoàn thành mỗi
nhiệm vụ.
Môi trường thử nghiệm: Mô tả phần cứng, phần mềm, công cụ thử
nghiệm và các phương tiện phòng thí nghiệm cần thiết để tiến hành
thử nghiệm.
Trách nhiệm: Tên của các kỹ sư (hoặc nhóm) chịu trách nhiệm quản
lý, thiết kế, chuẩn bị và thực hiện các thử nghiệm.
Nhu cầu Nhân sự và Đào tạo: Cần bao nhiêu người? Họ cần đào
tạo gì?
561
Lập lịch: Danh sách tất cả các cột mốc có ngày tháng và thời điểm
cần đến tất cả các nguồn lực.
Rủi ro và Dự phòng: Các giả định rủi ro cao nhất trong kế hoạch thử
nghiệm là gì? Điều gì có thể xảy ra sai lầm để trì hoãn lịch trình, và
có thể làm gì với nó?
Phê duyệt: Ai phải phê duyệt kế hoạch này? Cung cấp không gian
cho chữ ký của họ.
Cangussu và cộng sự. [2] đã nghiên cứu một quy trình thử nghiệm
chung bằng cách sử dụng mô hình dựa trên biến trạng thái. Bằng cách
định lượng toán học tác động của các biến thể tham số đối với hành
vi của quá trình kiểm tra hệ thống, người quản lý kiểm tra hệ thống
có thể ước tính tác động của biến đổi thông số đối với lịch trình kiểm
tra.
Một số kỹ thuật lựa chọn kiểm thử hồi quy đã được các nhà nghiên
cứu đề xuất để giảm chi phí bảo trì phần mềm. Các kỹ thuật lựa chọn
thử nghiệm được đề xuất cho thử nghiệm hồi quy có thể được phân
loại rộng rãi thành hai loại dựa trên các loại thông tin mà chúng sử
dụng để thực hiện nhiệm vụ: dựa trên đặc điểm kỹ thuật và dựa trên
mã. Các bài viết sau đây thảo luận về việc lựa chọn các thử nghiệm
hồi quy sử dụng thông tin từ đặc tả và mã.
Ưu điểm và nhược điểm của tự động hóa thử nghiệm ban đầu, tức là,
đối với bản phát hành đầu tiên của một sản phẩm là gì?
Ưu điểm và nhược điểm của tự động hóa thử nghiệm muộn, tức là
sau khi phát hành sản phẩm đầu tiên là gì?
Xây dựng các tiêu chí đánh giá cho việc lựa chọn một công cụ theo
dõi lỗi.
Đánh giá hệ thống theo dõi lỗi ClearQuest bằng cách nhận bản dùng
thử của thetool từ IBM sử dụng các tiêu chí được phát triển cho bài
tập 13.
Các thành phần của cơ sở hạ tầng tự động hóa thử nghiệm là gì? Vai
trò của một quản trị viên khung tự động thử nghiệm là gì?
CHAPTER
13
SystemTestExecution
Thực hiện mọi hành động trong cuộc sống của bạn như thể đó là
hành động cuối cùng của bạn.
—MarcusAurelius
13.1 Ý TƯỞNG CƠ BẢN
Chuẩn bị và thực hiện các bài kiểm tra mức hệ thống là một giai
đoạn quan trọng trong quá trình phát triển phần mềm vì những điều
sau đây: (i) Có áp lực phải đáp ứng một lịch trình chặt chẽ gần với
ngày giao hàng; (ii) cần phát hiện ra hầu hết các khuyết tật trước khi
giao sản phẩm; và (iii) điều cần thiết là phải xác minh rằng các bản
sửa lỗi đang hoạt động và không dẫn đến các khiếm khuyết mới.
Điều quan trọng là phải giám sát các quá trình thực hiện kiểm tra và
sửa lỗi. Để có thể giám sát các quá trình kiểm tra đó, chúng tôi xác
định hai loại chỉ số chính: (i) trạng thái thực thi kiểm tra hệ thống và
(ii) trạng thái lỗi. Chúng tôi cung cấp một lược đồ lỗi chi tiết, trong
đó bao gồm một mô hình FSM chung về các lỗi để dễ dàng thu thập
các số liệu đó. Phân tích lỗi là một hoạt động quan trọng được thực
hiện bởi nhóm phát triển phần mềm trong khi sửa chữa các lỗi. Do
đó, trong chương này, chúng tôi mô tả ba loại kỹ thuật phân tích
khiếm khuyết: phương pháp luận nhân quả, trực giao và Pareto.
Ngoài ra, chúng tôi cung cấp ba chỉ số, đó là hiệu quả loại bỏ khuyết
tật, hư hỏng và tạo lỗi để đo hiệu quả kiểm tra. Mục tiêu của thước
đo hiệu quả kiểm tra là đánh giá hiệu quả của nỗ lực kiểm tra hệ
thống trong việc phát triển sản phẩm về số lượng lỗi thoát ra từ nỗ
lực kiểm tra hệ thống.
Sản phẩm đã sẵn sàng để thử nghiệm beta tại trang web của khách
hàng trong quá trình thử nghiệm hệ thống. Chúng tôi cung cấp một
khuôn khổ cho thử nghiệm beta và thảo luận về cách thử nghiệm beta
được tiến hành tại trang web của khách hàng. Hơn nữa, chúng tôi
13.2 CÁC ĐỊNH NGHĨA CỦA MÔ HÌNH
563
cung cấp cấu trúc chi tiết của báo cáo thực thi kiểm tra hệ thống,
được tạo trước khi công bố tính khả dụng chung của sản phẩm.
408
Chìa khóa cho một hệ thống theo dõi lỗi thành công nằm ở việc mô
hình hóa đúng các lỗi để nắm bắt quan điểm của nhiều bên liên quan,
được gọi là các nhóm chức năng chéo. Các nhóm chức năng chéo
trong một tổ chức là những nhóm có cổ phần khác nhau trong một
sản phẩm. Ví dụ: nhóm tiếp thị, nhóm hỗ trợ khách hàng, nhóm phát
triển, nhóm thử nghiệm hệ thống và nhóm duy trì sản phẩm được gọi
chung là nhóm chức năng chéo trong một tổ chức. Sẽ không đủ nếu
chỉ báo cáo một lỗi từ quan điểm phát triển phần mềm và quản lý sản
phẩm và tìm cách hiểu nó bằng cách tái tạo trước khi sửa chữa nó.
Trên thực tế, lỗi được báo cáo là một thực thể đang phát triển có thể
được biểu diễn một cách thích hợp bằng cách tạo cho nó một mô
hình vòng đời dưới dạng biểu đồ chuyển đổi trạng thái, như thể hiện
trong Hình 13.1. Các trạng thái được sử dụng trong Hình 13.1 được
giải thích ngắn gọn trong Bảng 13.1.
Mô hình chuyển đổi trạng thái cho phép chúng ta biểu diễn từng giai
đoạn trong vòng đời của khuyết tật bằng một trạng thái riêng biệt.
Mô hình đại diện cho vòng đời của một khiếm khuyết từ báo cáo ban
đầu đến lần đóng cuối cùng của nó thông qua các trạng thái sau: mới,
đã chỉ định, mở, đã giải quyết, chờ đợi, FAD, giữ, trùng lặp, tạm
dừng, không thể sản xuất, hoãn lại và đã đóng. Khi một khiếm
khuyết chuyển sang trạng thái mới, chủ sở hữu của trạng thái sẽ thực
hiện một số hành động nhất định. "Chủ sở hữu" của trạng thái có
khuyết điểm, chúng tôi có nghĩa là người hoặc nhóm người chịu
trách nhiệm thực hiện các hành động bắt buộc trong trạng thái đó.
Khi các hành động liên quan được thực hiện ở một trạng thái, lỗi sẽ
được chuyển sang trạng thái mới.
N
S F
564 P CHƯƠNG 13 THI CÔNG THỬ NGHIỆM HỆ THỐNG
A
W
I
Hai khái niệm chính liên quan
O đến các khiếm khuyết trong mô
hình hóa là mức độ ưu tiên và
H D mức độ nghiêm trọng. Một mặt,
R mức độ ưu tiên là thước đo mức
độ khẩn cấp của khiếm khuyết
cần được sửa chữa. Mặt khác,
C
mức độ nghiêm trọng là thước đo
mức độ ảnh hưởng bất lợi của
khuyết tật đối với hoạt động của sản phẩm. Do đó, việc phân công
mức độ ưu tiên và mức độ nghiêm trọng được thực hiện riêng biệt.
Sau đây, bốn cấp độ ưu tiên khuyết tật được giải thích:
Hình 13.1 Biểu đồ chuyển trạng thái biểu diễn vòng đời của
khuyết tật.
BẢNG 13.1 Các trạng thái khiếm khuyết được mô hình
trong Hình 13.1
Tiểu
Ngữ nghĩa Sự mô tả
bang
N Mới Một báo cáo sự cố với mức độ nghiêm trọng và
mức độ ưu tiên sẽ được đệ trình.
Một Giao Vấn đề được giao cho một người thích hợp.
O Mở Người được phân công đang tích cực vào cuộc để
giải quyết.
R Đã giải Người được phân công đã giải quyết vấn đề và
quyết đang chờ người gửi xác minh và đóng nó.
C Đã đóng cửa Người gửi đã xác minh giải pháp của vấn đề.
W Watt Người được chỉ định đang đợi thông tin bổ sung
từ người gửi.
F HAM MÊ Các khiếm khuyết được báo cáo không phải là
một khiếm khuyết thực sự. Đúng hơn, nó là một
chức năng như được thiết kế.
H Tổ chức Sự cố đang bị tạm dừng vì sự cố này không thể
được giải quyết cho đến khi sự cố khác được giải
quyết.
565
S Kệ Có một vấn đề trong hệ thống, nhưng một quyết

định có ý thức được đưa ra rằng vấn đề này sẽ
không được giải quyết trong tương lai gần. Chỉ
người quản lý phát triển mới có thể chuyển một
khiếm khuyết sang trạng thái này.
D Nhân bản Sự cố được báo cáo là bản sao của sự cố đã được
báo cáo.
Tôi Không có lợiSự cố được báo cáo không thể được tái tạo bởi
người được giao.
P Hoãn lại Sự cố sẽ được giải quyết trong bản phát hành
sau.
Nghiêm trọng: Các khiếm khuyết ở cấp độ này phải được giải quyết
càng sớm càng tốt. Việc kiểm tra sẽ không tiến triển cho đến khi một
lỗi nghiêm trọng đã biết được khắc phục.
Cao: Các khiếm khuyết ở cấp độ này phải được giải quyết với mức
độ ưu tiên cao. Không thể kiểm tra một tập hợp con các chức năng
của hệ thống trừ khi mức độ lỗi này được giải quyết.
Trung bình: Các khiếm khuyết ở cấp độ này sẽ không có bất kỳ ảnh
hưởng nào đến tiến độ kiểm tra. Các khuyết tật có mức độ ưu tiên
trung bình tự đứng ra.
Thấp: Các khiếm khuyết ở cấp độ này nên được giải quyết bất cứ khi
nào có thể.
Về mặt trực quan, một khiếm khuyết có mức độ ưu tiên quan trọng
ảnh hưởng đến một số lượng lớn các chức năng của hệ thống, một
khiếm khuyết có mức độ ưu tiên cao ảnh hưởng đến một tập hợp con
nhỏ hơn của các chức năng, một khiếm khuyết có mức độ ưu tiên
trung bình ảnh hưởng đến một chức năng riêng lẻ và một khiếm
khuyết có mức độ ưu tiên thấp được coi là kích ứng nhẹ. Sau đây,
bốn mức độ nghiêm trọng được giải thích:
Nghiêm trọng: Một khiếm khuyết nhận được mức độ nghiêm trọng
"nghiêm trọng" nếu một hoặc nhiều chức năng quan trọng của hệ
thống bị suy giảm do lỗi bị suy giảm và không có giải pháp thay thế.
Cao: Một khiếm khuyết nhận được mức độ nghiêm trọng "cao" nếu
một số chức năng cơ bản của hệ thống bị suy giảm nhưng vẫn tồn tại
một giải pháp khác.
566 CHƯƠNG 13 THI CÔNG THỬ NGHIỆM HỆ THỐNG
Trung bình: Một khiếm khuyết nhận được mức độ nghiêm trọng
“trung bình” nếu không có chức năng quan trọng nào bị suy giảm và
tồn tại một giải pháp cho lỗi.
Thấp: Một khiếm khuyết nhận được mức độ nghiêm trọng "thấp" nếu
vấn đề liên quan đến tính năng thẩm mỹ của hệ thống.
Theo trực giác, các khuyết tật có mức độ nghiêm trọng cao sẽ được
ưu tiên cao trong giai đoạn giải quyết, nhưng có thể nảy sinh một tình
huống trong đó khuyết tật có mức độ nghiêm trọng cao có thể được
ưu tiên thấp. Ví dụ: để hệ thống gặp sự cố khi ngày hệ thống được
đặt thành ngày 32 tháng 12. Mặc dù lỗi hỏng hóc gây ra hậu quả
nghiêm trọng, nhưng sự cố xảy ra vào ngày 32 tháng 12 là ngày hệ
thống khó có thể xảy ra trong các trường hợp bình thường. Khiếm
khuyết nói trên nhận được mức độ nghiêm trọng nghiêm trọng nhưng
mức độ ưu tiên thấp. Nói cách khác, nếu một khiếm khuyết nghiêm
trọng xảy ra với xác suất cực kỳ thấp, thì nó có thể không được sửa
ngay lập tức, tức là nó có thể được xử lý với mức độ ưu tiên thấp.
Một người nào đó báo cáo một khiếm khuyết sẽ đánh giá sơ bộ về
mức độ nghiêm trọng và mức độ ưu tiên của khiếm khuyết. Nếu có
tranh chấp giữa các nhóm chức năng chéo khác nhau liên quan đến
mức độ ưu tiên và mức độ nghiêm trọng của khiếm khuyết, có thể đạt
được thỏa thuận trong cuộc họp đánh giá thường xuyên. Lưu ý rằng
mức độ nghiêm trọng của lỗi vẫn không đổi trong suốt vòng đời của
nó, trong khi mức độ ưu tiên có thể thay đổi khi sản phẩm phần mềm
đến gần ngày phát hành. Một khiếm khuyết có thể được chỉ định mức
ưu tiên thấp khi bắt đầu thử nghiệm hệ thống nếu nó có thể không
ảnh hưởng đến tiến trình thử nghiệm, nhưng nó phải được sửa trước
khi phần mềm được phát hành. Ví dụ, một lỗi chính tả trong GUI có
thể là một lỗi có mức độ ưu tiên thấp khi bắt đầu thử nghiệm hệ
thống nhưng mức độ ưu tiên của nó trở nên cao khi ngày phát hành
đến gần.
Trong phần sau, chúng tôi mô tả các trạng thái của một khuyết tật
được mô hình hóa dưới dạng biểu đồ chuyển đổi trạng thái, như thể
hiện trong Hình 13.1 và giải thích cách một khuyết tật di chuyển từ
trạng thái này sang trạng thái khác. Khi một khuyết tật mới được tìm
thấy, nó sẽ được ghi lại trong một hệ thống theo dõi khuyết tật và
khuyết tật được đưa về trạng thái ban đầu như mới. Chủ sở hữu của
567
trạng thái này là giám đốc phát triển phần mềm. Ở trạng thái này, các
trường sau đây, được giải thích là các phần của lược đồ được đưa ra
trong Bảng 13.2, được khởi tạo: error_id, submit_date, product,
submitter, group, owner, headline, từ khóa, mức độ nghiêm trọng,
mức độ ưu tiên, có thể tái tạo, danh mục, phần mềm_version, bản
dựng, mô tả, h / w_configuration, s / w_configuration, tệp đính kèm,
ghi chú và number_tc_fail, tc_id.
Người quản lý phát triển phần mềm, là chủ sở hữu của trạng thái
mới, chuyển lỗi từ trạng thái mới sang trạng thái được chỉ định bằng
cách thay đổi quyền sở hữu cho nhà phát triển phần mềm hoặc cho
chính mình. Người quản lý phát triển phần mềm có thể từ chối khiếm
khuyết này bằng cách giải thích lý do tại sao nó không phải là khiếm
khuyết thực sự và chuyển khiếm khuyết sang trạng thái FAD với sự
thay đổi quyền sở hữu trở lại người gửi. Người quản lý phát triển có
thể thay đổi trạng thái thành trạng thái chờ đợi, có nghĩa là đó là một
khiếm khuyết thực sự và một quyết định có ý thức đã được đưa ra để
đảm bảo rằng khiếm khuyết này sẽ không được sửa chữa trong tương
lai gần. Tất cả các bên liên quan, đặc biệt là nhóm hỗ trợ khách hàng
của tổ chức, phải đồng ý loại bỏ khuyết tật trước khi khuyết tật được
chuyển sang trạng thái xếp dỡ. Có một số lý do để chuyển một khiếm
khuyết sang trạng thái xếp dỡ. Ví dụ, một lỗi có thể không ảnh hưởng
nhiều đến hoạt động của hệ thống trong môi trường hoạt động của
khách hàng và nó có thể tiêu tốn nhiều tài nguyên để sửa chữa nó.
Trong thực tế, rất ít khuyết tật hạ cánh ở trạng thái được che chở.
Trạng thái được chỉ định có nghĩa là ai đó đã được chỉ định để sửa
chữa lỗi nhưng công việc thực tế cần thiết để sửa lỗi vẫn chưa bắt
đầu. Sự phát triển phần mềm
BẢNG 13.2 Các trường tóm tắt lược đồ khiếm khuyết
khiếm khuyết Một số nhận dạng duy nhất, được tạo nội bộ cho
lỗi
tiểu bang Tình trạng hiện tại của khuyết tật; lấy một giá trị
từ setOpen, Resolved, Information, FAD, Hold,
Duplicate, Shelved, { New, Assigned,
Không thể sản xuất, Hoãn lại, Đã đóng }
tiêu đề
Tóm tắt một dòng về khiếm khuyết

mức độ nghiêm Mức độ nghiêm trọng của khuyết tật; nhận một
trọng giá trị từ setmedium, low } { critical, high,
người gửi ưu tiên Mức độ ưu tiên của khuyết tật; nhận một giá trị từ
setmedium low } { critical, high,
Tên của người gửi lỗi
chủ nhóm Nhóm liên kết của người gửi; nhận một giá trị từ
setsoftware, phần cứng, hỗ trợ khách hàng } { ST,
SIT,
Chủ sở hữu hiện tại của khiếm khuyết
có thể tái sản xuất Nói về có hoặc không, liệu khiếm khuyết có thể
được tái tạo hay không
tai nạn Nói về có hoặc không, có hay không lỗi khiến hệ
thống gặp sự cố
từ khóa Một số từ phổ biến có thể được kết hợp với khiếm
khuyết này cho mục đích tìm kiếm
sản phẩm Tên của sản phẩm đã tìm thấy lỗi
thể loại Tên danh mục kiểm tra đã phát hiện ra khiếm
khuyết
phiên bản phần Số phiên bản phần mềm có lỗi được quan sát thấy
mềm
xây dựng Số bản dựng mà trong đó lỗi đã được quan sát
thấy
submit_date Ngày gửi khiếm khuyết
sự mô tả Mô tả ngắn gọn về khiếm khuyết
h / Mô tả cấu hình phần cứng của giường thử nghiệm
w_configuration
s / Mô tả cấu hình phần mềm của giường thử nghiệm
w_configuration
tập tin đính kèm Tệp đính kèm, ở dạng tệp nhật ký, tệp cấu hình,
v.v., hữu ích trong việc tìm hiểu lỗi
ghi chú Ghi chú hoặc nhận xét bổ sung, nếu có
number_tc_fail Số lượng trường hợp thử nghiệm không thành
công hoặc bị chặn do lỗi
569
tc_id Danh sách các mã nhận dạng trường hợp thử

nghiệm của các trường hợp thử nghiệm đó, từ cơ
sở dữ liệu của nhà máy thử nghiệm, sẽ không
thành công do lỗi
dự Phiên bản phần mềm sẽ có sẵn bản sửa lỗi cho lỗi
báo_fix_version Số bản dựng sẽ có sẵn bản sửa lỗi cho lỗi
dự Phiên bản phần mềm thực sự có sẵn bản sửa lỗi
báo_build_number
fact_fix_version
real_build_numbe Số bản dựng mà bản sửa lỗi thực sự có sẵn
r
fix_description Mô tả ngắn gọn về sửa chữa lỗi
fix_date Ngày đăng ký sửa lỗi vào mã
Dupate_defect_id hiện tại được coi là bản sao của bản sao lỗi_id
request_id Mã định danh yêu cầu từ cơ sở dữ liệu yêu cầu
được tạo ra do thỏa thuận rằng khiếm khuyết được
chuyển thành yêu cầu
người quản lý hoặc nhà phát triển là chủ sở hữu của lỗi trong trạng
thái được chỉ định. Quyền sở hữu có thể thay đổi thành một nhà phát
triển phần mềm khác, người sẽ sửa lỗi. Nhà phát triển phần mềm
được chỉ định có thể chuyển lỗi từ trạng thái được chỉ định sang trạng
thái mở ngay khi quá trình sửa lỗi bắt đầu. Lưu ý rằng chỉ người quản
lý phát triển phần mềm mới chuyển một khiếm khuyết từ trạng thái
được chỉ định sang một trạng thái sau: chờ, hoãn và FAD. Quyền sở
hữu được thay đổi cho người gửi khi một khiếm khuyết được chuyển
sang trạng thái FAD.
Một nhà phát triển phần mềm, chủ sở hữu của lỗi, đang tích cực làm
việc để sửa lỗi ở trạng thái mở. Nhà phát triển khởi tạo các trường dự
báo_fix_version và dự báo_máy_năm của giản đồ lỗi được cung cấp
trong Bảng 13.2 để người gửi có thể lập kế hoạch và lên lịch kiểm tra
lại bản sửa lỗi. Một khiếm khuyết có thể nằm ở trạng thái mở trong
vài tuần. Nhà phát triển phần mềm chuyển lỗi từ trạng thái này sang
năm trạng thái có thể tiếp theo — không thể tạo ra, đã giải quyết,
chờ, giữ và trùng lặp — được giải thích trong Bảng 13.3 cùng với các
hành động cần thực hiện khi trạng thái bị thay đổi.
Nếu một nhà phát triển phần mềm đang làm việc trên một lỗi và hài
lòng rằng lỗi đã được sửa, họ sẽ chuyển lỗi sang trạng thái đã giải
quyết và thay đổi quyền sở hữu
BẢNG 13.3 Chuyển đổi trạng thái sang năm quốc gia có thể
tiếp theo từ trạng thái mở
Khả thi
Trạng thái tiếp
theo Hành động
Không có lợi Nếu chủ sở hữu, tức là nhà phát triển, không thể tái
tạo một khiếm khuyết, thì lỗi đó sẽ được chuyển sang
trạng thái không thể sản xuất được với quyền sở hữu
được đổi lại cho người gửi.
Chờ đợi Nếu lượng thông tin mà người gửi cung cấp không đủ
để hiểu và / hoặc sao chép lại khiếm khuyết, thì chủ sở
hữu sẽ yêu cầu người gửi thêm thông tin về lỗi đó. Về
cơ bản, nhà phát triển đang yêu cầu thêm thông tin về
lỗi trong trường ghi chú. Trường quyền sở hữu được
thay đổi trở lại người gửi.
Đã giải quyết Trường quyền sở hữu được thay đổi trở lại người gửi.
Các trường sau đây cần được điền vào:
Actual_fix_version: Phiên bản phần mềm có sẵn bản
sửa lỗi
Actual_build_number: Số bản dựng có sẵn bản sửa
lỗi.
Fixed_description: Mô tả ngắn gọn về bản sửa lỗi.
Nhà phát triển phải liệt kê tất cả các tệp được sửa đổi
và những gì đã được thay đổi trong tệp để khắc phục
sự cố.
Fixed_date: Ngày sửa lỗi và chuyển sang trạng thái đã
giải quyết.
Tổ chức Nó phải được giải thích trong trường ghi chú lý do tại
sao khiếm khuyết được chuyển đến trạng thái này.
Trạng thái lưu giữ có nghĩa là không có quyết định
chắc chắn nào được đưa ra liên quan đến lỗi vì vấn đề
phụ thuộc vào một số vấn đề khác, chẳng hạn như lỗi
571
phần mềm trong sản phẩm của bên thứ ba. Trừ khi các
vấn đề khác được giải quyết, vấn đề được mô tả trong
báo cáo lỗi sẽ không thể được giải quyết.
Nhân bản Nếu khiếm khuyết này giống với, tức là một bản sao
của một khiếm khuyết khác, thì số nhận dạng của
khiếm khuyết ban đầu được ghi lại trong trường
Dupate_defect_id.
của khiếm khuyết trở lại người gửi. Một khiếm khuyết trong trạng
thái đã giải quyết chỉ ngụ ý rằng lỗi đã được khắc phục để nhà phát
triển hài lòng và các thử nghiệm liên quan cần được thực hiện để xác
minh thêm khiếu nại trong bối cảnh rộng hơn. Người gửi chuyển lỗi
từ trạng thái đã giải quyết sang trạng thái đóng bằng cách khởi tạo
các trường sau của giản đồ lỗi sau khi xác minh rằng lỗi đã được
khắc phục: Verifier, closed_in_version, closed_in_build, closed_date
và verify_description. Về cơ bản, verify_description mô tả chi tiết
của quy trình xác minh. Trạng thái đóng dấu hiệu rằng lỗi đã được
giải quyết và xác minh. Mặt khác, nếu người xác minh tin rằng lỗi
vẫn chưa được sửa thực sự hoặc hoàn toàn, bản sửa lỗi sẽ bị từ chối
bằng cách chuyển lỗi trở lại trạng thái được chỉ định và quyền sở hữu
của lỗi được đổi lại cho nhà phát triển phần mềm chịu trách nhiệm.
Người xác minh cung cấp thông tin sau trong khi từ chối sửa:
Giải thích cho việc từ chối sửa chữa
Bất kỳ quan sát mới nào và / hoặc vấn đề gặp phải
Một khiếm khuyết được nhóm phát triển chuyển sang trạng thái FAD
nếu nhóm kết luận rằng đó không phải là một khiếm khuyết thực sự
và hệ thống hoạt động như mong đợi. Người đệ trình, chủ sở hữu của
khiếm khuyết trong trạng thái FAD, có thể liên quan đến nhóm phát
triển, nhóm hỗ trợ khách hàng, quản lý sản phẩm và người phụ trách
dự án để xem xét các khiếm khuyết trong trạng thái này. Có ba kết
quả thay thế có thể có của cuộc họp đánh giá khiếm khuyết:
Việc báo cáo lỗi là do lỗi thủ tục từ phía người gửi. Các khiếm
khuyết vẫn ở trạng thái FAD cho kết quả này. Ý tưởng đằng sau việc
giữ khiếm khuyết ở trạng thái FAD, chứ không phải ở trạng thái
đóng, là ghi lại thực tế là người gửi đã chỉ định nó là khiếm khuyết. •
Các khiếm khuyết được báo cáo là một khiếm khuyết thực sự. Lỗi
được chuyển đến trạng thái được chỉ định với một lưu ý cho người
quản lý phát triển phần mềm nói rằng đây là lỗi được tất cả các bên
đồng ý.
Một gợi ý được đưa ra rằng một yêu cầu cải tiến tính năng mới được
thực hiện để điều chỉnh hành vi hệ thống được coi là "lỗi" tại thời
điểm này. Người gửi chuyển lỗi đến trạng thái được chỉ định với một
lưu ý cho người quản lý phát triển nói rằng lỗi có thể được giải quyết
bằng cách tạo một yêu cầu mới và gửi mã định danh yêu cầu trong
trường request_id của lược đồ lỗi.
Nếu một lỗi không thể được sửa trong một bản phát hành cụ thể, nó
sẽ được chuyển sang trạng thái hoãn lại, nơi người quản lý phát triển
là chủ sở hữu của lỗi. Việc sửa lỗi bị hoãn lại do không có thời gian
sửa chữa cho một bản phát hành nhất định. Lỗi được chuyển, sau khi
bản phát hành để sửa lỗi được biết đến, đến trạng thái được chỉ định,
nơi các trường sau của giản đồ lỗi được khởi tạo: (i) dự
báo_mã_bản_số — bản dựng trong đó bản sửa lỗi sẽ có sẵn để thử
nghiệm — và (ii ) dự báo_fix_version — phiên bản sẽ có bản sửa lỗi.
Tất cả các lỗi còn tồn đọng vẫn còn mở được chuyển sang trạng thái
hoãn lại sau khi sản phẩm được xuất xưởng cho khách hàng, để có
thể lên lịch sửa chữa các lỗi đó
573
13.3 CHUẨN BỊ ĐỂ BẮT ĐẦU KIỂM TRA HỆ THỐNG
sẽ được sửa trong các bản phát hành phần mềm trong tương lai. Các
khuyết tật được chuyển đến trạng thái được ấn định sau khi nó được
hoàn thiện trong đó việc giải phóng các khuyết tật này sẽ được sửa
chữa. Trạng thái hoãn lại rất hữu ích trong việc theo dõi và lên lịch
cho tất cả các lỗi còn tồn đọng trong hệ thống phải được sửa trong
các bản phát hành trong tương lai.
Nếu nhà phát triển nhận thấy rằng thông tin do người gửi cung cấp
không đủ để sửa lỗi, nhà phát triển sẽ yêu cầu thông tin bổ sung từ
người gửi bằng cách chuyển lỗi từ trạng thái mở sang trạng thái chờ.
Trong trạng thái chờ đợi, người gửi là chủ sở hữu của lỗi. Người gửi
cung cấp thông tin mà nhà phát triển yêu cầu bằng cách khởi tạo
trường ghi chú của lược đồ lỗi, chuyển lỗi sang trạng thái được chỉ
định và thay đổi quyền sở hữu trở lại nhà phát triển phần mềm.
Nhà phát triển có thể cố gắng tái tạo các triệu chứng để hiểu được
khiếm khuyết. Nếu nhà phát triển không thể tái tạo lỗi được báo cáo,
lỗi sẽ được chuyển sang trạng thái không thể sửa chữa với quyền sở
hữu được thay đổi trở lại người gửi. Người gửi nỗ lực để tái tạo lỗi,
thu thập tất cả thông tin liên quan vào báo cáo lỗi và chuyển lỗi đến
trạng thái được chỉ định nếu lỗi được tái tạo. Nếu người gửi không
thể tái tạo khiếm khuyết, khiếm khuyết sẽ ở trạng thái không thể sản
xuất.
Có thể quan sát thấy rằng lỗi là do yếu tố bên ngoài gây ra, chẳng hạn
như lỗi trong sản phẩm của bên thứ ba đang được sử dụng. Không thể
sửa lỗi được báo cáo trừ khi lỗi ở bộ phận bên ngoài được giải quyết.
Trong trường hợp như vậy, lỗi được tạm giữ bằng cách chuyển nó
sang trạng thái lưu giữ, nơi người quản lý phát triển phần mềm là chủ
sở hữu của lỗi. Người quản lý phát triển phần mềm chuyển lỗi sang
trạng thái đã giải quyết hoặc trạng thái mở tùy thuộc vào việc lỗi
chính trong thành phần bên ngoài đã được giải quyết hay đang được
khắc phục, tương ứng.
Một khiếm khuyết ở trạng thái trùng lặp, trong đó người gửi là chủ sở
hữu, có nghĩa là vấn đề là một bản sao của một khiếm khuyết đã được
báo cáo trước đó. Định danh lỗi ban đầu được sử dụng để khởi tạo
trường lược đồ Dupate_defect_id. Khi lỗi trùng lặp ở trạng thái đóng,
người gửi phải xác minh lỗi này. Nếu xác minh thành công, người gửi
sẽ chuyển lỗi sang trạng thái đóng. Mặt khác, nếu việc xác minh
không thành công, người gửi sẽ từ chối khiếu nại về tính trùng lặp
bằng cách chuyển lỗi trở lại trạng thái được chỉ định, nơi nhà phát
triển phần mềm là chủ sở hữu của lỗi. Người xác minh phải đưa ra lý
do từ chối một khiếm khuyết là một sai sót trùng lặp. Thông tin này
chứa bất kỳ quan sát và / hoặc vấn đề gặp phải khi xác minh lỗi.
Trạng thái của các tiêu chí đầu vào được nêu trong Chương 13 phải
được theo dõi ít nhất bốn tuần trước khi bắt đầu chu kỳ kiểm tra hệ
thống đầu tiên. Bất kỳ trường hợp ngoại lệ nào đối với các tiêu chí
này phải được ghi nhận và thảo luận tại cuộc họp đánh giá tình trạng
dự án hàng tuần. Chúng tôi thảo luận về mục cuối cùng của tiêu chí
đầu vào, cụ thể là tài liệu làm việc thực thi kiểm tra đã có sẵn và hoàn
chỉnh. Khung của tài liệu như vậy được nêu trong Bảng 13.4 và được
giải thích sau đó. Tài liệu làm việc này do trưởng nhóm thử nghiệm
tạo, kiểm soát và theo dõi.
BẢNG 13.4 Sơ lược về tài liệu làm việc thực thi kiểm tra
Kỹ sư kiểm tra
Phân bổ các trường hợp thử nghiệm
Phân bổ giường thử nghiệm
Tiến trình tự động hóa
Tỷ lệ thực hiện kiểm tra dự kiến
Thực thi các trường hợp thử nghiệm không thành công
Phát triển các trường hợp thử nghiệm mới
Thử nghiệm hình ảnh hệ thống
Lịch họp rà soát khuyết điểm
Phần kỹ sư thử nghiệm chứa tên của các kỹ sư thử nghiệm được chỉ
định cho dự án này cũng như khả năng sẵn sàng và chuyên môn của
họ trong các lĩnh vực cụ thể của dự án. Yêu cầu đào tạo cho mỗi
thành viên trong nhóm có thể cần thiết để thực hiện thành công dự án
thử nghiệm được ghi chú chi tiết. Kế hoạch hành động và tiến độ đào
tạo cho từng thành viên trong nhóm được theo dõi trong phần này.
Bất kỳ vấn đề nào liên quan đến nguồn nhân lực sẵn có hoặc đào tạo
được chuyển đến trưởng dự án phần mềm.
575
Các trường hợp thử nghiệm được phân bổ giữa các kỹ sư thử nghiệm
dựa trên chuyên môn và sự quan tâm của họ sau khi bộ thử nghiệm
được tạo trong nhà máy thử nghiệm. Các kỹ sư phát triển phần mềm
và kỹ sư kiểm thử hệ thống được xác định và đưa vào các trường
sw_dev và tester của các trường hợp thử nghiệm tương ứng. Ý tưởng
ở đây là trao quyền sở hữu việc thực thi trường hợp thử nghiệm cho
từng kỹ sư thử nghiệm. Một kỹ sư kiểm thử xem xét các trường hợp
kiểm thử được phân bổ cho anh ta hoặc cô ta để hiểu chúng và ưu tiên
chúng với sự tham vấn của các nhà phát triển phần mềm. Mức độ ưu
tiên của trường hợp thử nghiệm được đặt thành một trong các giá trị
từ tập hợp { cao, trung bình, thấp } . Nếu cần, kỹ sư kiểm thử có thể
cập nhật các trường hợp kiểm thử để tinh chỉnh các quy trình kiểm tra
và các tiêu chí đạt - không đạt như đã thảo luận trong Phần 11.6. Các
hoạt động ưu tiên và phân bổ các trường hợp thử nghiệm giữa các kỹ
sư và nhà phát triển phần mềm được theo dõi trong phần phân bổ
trường hợp thử nghiệm và điều này phải được hoàn thành trước khi
bắt đầu chu kỳ thử nghiệm hệ thống. Điều này đạt được bằng cách
gọi một số cuộc họp với các thành viên trong nhóm của dự án phần
mềm.
Phần phân bổ giường thử nghiệm của tài liệu nêu rõ sự sẵn có của số
lượng và loại giường thử nghiệm và cách thức phân bổ các giường
thử nghiệm này để các trường hợp thử nghiệm được thực hiện đồng
thời. Một ánh xạ được thiết lập giữa các giường thử nghiệm có sẵn và
các nhóm con của các trường hợp thử nghiệm từ bộ thử nghiệm. Ánh
xạ dựa trên các yêu cầu cấu hình để thực thi các nhóm trường hợp thử
nghiệm. Kỹ sư thử nghiệm chịu trách nhiệm thực hiện một nhóm con
các trường hợp thử nghiệm sau đó sẽ được chỉ định đến giường thử
nghiệm đó. Kỹ sư thử nghiệm sở hữu giường thử cụ thể đó và phải
đảm bảo rằng giường thử đã hoạt động và sẵn sàng hoạt động trước
khi bắt đầu các chu kỳ thử nghiệm hệ thống. Cần phải thận trọng để
đảm bảo rằng mỗi kỹ sư thử nghiệm được phân bổ cùng một giường
thử nghiệm trong toàn bộ chu kỳ thực hiện thử nghiệm. Ý tưởng ở
đây là tối đa hóa hiệu quả thực thi của kỹ sư. Nếu cần thiết, các
giường thử nghiệm mới được tạo hoặc phân bổ từ các dự án khác để
thời gian nhàn rỗi được giảm thiểu.
Trong phần tiến trình tự động hóa của tài liệu, một bảng được tạo để
theo dõi tiến trình tự động hóa các trường hợp thử nghiệm và tính khả
dụng của các trường hợp thử nghiệm tự động đó để thực thi. Điều này
đặc biệt quan tâm trong trường hợp các trường hợp kiểm thử hồi quy
đã được phát triển trước đó và được thực thi theo cách thủ công,
nhưng quá trình tự động hóa của chúng đang được tiến hành. Trưởng
nhóm thử nghiệm tương tác với các kỹ sư tự động hóa thử nghiệm
chịu trách nhiệm để thu thập thông tin về tiến trình tự động hóa thử
nghiệm. Trong trường hợp các trường hợp thử nghiệm tự động có sẵn
đúng thời gian, tức là trước khi bắt đầu chu kỳ thử nghiệm, thì quá
trình thực thi thủ công theo lịch trình của các trường hợp thử nghiệm
này có thể bị bỏ qua. Thay vào đó, các trường hợp kiểm thử tự động
có thể được thực thi.
Trong phần tốc độ thực thi thử nghiệm dự kiến của tài liệu, một bảng
được tạo để hiển thị số lượng trường hợp thử nghiệm được dự đoán
sẽ được thực thi hàng tuần trong một chu kỳ thử nghiệm. Số lượng
trường hợp thử nghiệm dự kiến được theo dõi so với việc thực hiện
các trường hợp thử nghiệm thực tế trong chu kỳ thử nghiệm. Ví dụ,
chúng ta hãy xem xét tên dự án thử nghiệm, Bazooka, mà tổng số
trường hợp thử nghiệm được chọn là 1592. Việc thực hiện dự kiến
1592 trường hợp thử nghiệm hàng tuần trong chu kỳ thử nghiệm 14
tuần được thể hiện trong Bảng 13.2 trong dạng biểu đồ tích lũy. Việc
thực hiện 1592 trường hợp thử nghiệm dự kiến sẽ mất 14 tuần; 25
trường hợp thử nghiệm sẽ được thực hiện trong tuần đầu tiên; 75
trường hợp thử nghiệm sẽ được thực hiện trong tuần thứ hai; do đó,
100 trường hợp thử nghiệm sẽ được thực thi vào cuối tuần thứ hai.
Khi quá trình thực thi diễn ra, hàng thứ hai của Hình 13.2, cụ thể là,
các trường hợp thử nghiệm được thực thi thực sự, được cập nhật.
Điều này cung cấp cho nhóm thử nghiệm một ý tưởng về tiến trình
của thử nghiệm. Nếu số lượng các trường hợp kiểm thử được thực thi
thực sự thấp hơn nhiều so với con số dự kiến trong vài tuần, người
quản lý kiểm thử sẽ biết rằng dự án sẽ bị trì hoãn.
Một chiến lược để thực hiện các trường hợp thử nghiệm không thành
công và xác minh các bản sửa lỗi được nêu trong phần thực hiện các
trường hợp thử nghiệm không thành công của tài liệu. Có hai khả
năng xảy ra ở đây: (i) Các trường hợp thử nghiệm không thành công
được thực hiện trong chu kỳ thử nghiệm tiếp theo và (ii) các trường
577
hợp thử nghiệm không thành công được thực thi trong chu kỳ hiện tại
ngay sau đó
1800
1600
1400
1200
1000
800
600
400
200
0
wk1 wk2 wk3 wk4 wk5 wk6 wk7 wk8 wk9 wk10wk11wk12wk1 3 wk14
Projected execution 25 100 150 250 400 600 800 9501100125014001500155015 92

Actually executed
Hình 13.2 Dự kiến thực hiện các ca kiểm thử hàng tuần ở dạng
biểu đồ tích lũy.
như các bản sửa lỗi tương ứng có sẵn. Trong trường hợp đầu tiên, tất
cả các bản sửa lỗi, đã được tích hợp vào hệ thống, đều phải kiểm tra
hồi quy. Không có bản sửa lỗi nào được đưa vào hệ thống giữa chừng
trong chu kỳ thử nghiệm. Các bản sửa lỗi này có sẵn ở đầu chu kỳ thử
nghiệm. Trong trường hợp thứ hai, các bản sửa lỗi được kiểm tra
trong hệ thống kiểm soát phiên bản và một bản dựng mới được tạo.
Sau đó, bản dựng được kiểm tra bởi nhóm tích hợp hệ thống và sau
đó nó được phát hành cho nhóm kiểm tra hệ thống để được kiểm tra
lại bằng cách chạy các trường hợp thử nghiệm không thành công
trước đó. Nếu trường hợp thử nghiệm hiện đã vượt qua, thì bản sửa
lỗi đã được xác minh là đã giải quyết được lỗi. Tuy nhiên, mọi thiệt
hại về tài sản thế chấp có thể không được phát hiện. Một bản sửa lỗi
gây ra thiệt hại cho tài sản thế chấp được gọi là “bản sửa lỗi không
hợp lệ”, Một số ít các trường hợp thử nghiệm đã qua xung quanh bản
sửa lỗi có thể được thực thi lại sau khi một trường hợp thử nghiệm
không thành công trước đó được quan sát là đã vượt qua bất kể bản
sửa lỗi đã gây ra thiệt hại tài sản thế chấp. Ý tưởng là xác định vùng
có tác động cao của bản sửa lỗi, chọn một tập hợp các trường hợp thử
nghiệm đã được thông qua trước đó với sự tư vấn của nhà phát triển
phần mềm đã sửa lỗi và sau đó thực hiện các thử nghiệm đó như một
thử nghiệm hồi quy. Thông tin sau được thu thập và phân tích trong
việc lựa chọn các trường hợp kiểm thử hồi quy:
Các phần của mô-đun phần mềm đã được sửa đổi để kết hợp bản sửa
lỗi
Các lĩnh vực chức năng liên quan chặt chẽ đến việc sửa chữa và dễ bị
lỗi
Các loại khuyết tật có khả năng được đưa ra do việc sửa chữa
Dựa trên thông tin trên, các trường hợp thử nghiệm hiện tại hoặc mới
được chọn có nhiều khả năng phát hiện ra bất kỳ khiếm khuyết mới
nào có thể đã được đưa vào.
Các kỹ sư thử nghiệm tìm hiểu thêm về hệ thống và có vị trí tốt hơn
để phát triển các trường hợp thử nghiệm bổ sung trong chu kỳ thử
nghiệm đầu tiên của thử nghiệm. Điều này đặc biệt quan trọng khi
quan sát thấy một vấn đề có thể lặp lại và không có kịch bản thử
nghiệm nào trong bộ thử nghiệm. Trong trường hợp này, một trường
hợp thử nghiệm mới cần được thêm vào nhà máy thử nghiệm vì mục
tiêu dài hạn là cải thiện mức độ bao phủ và hiệu quả của bộ thử
nghiệm. Tuy nhiên, phải đưa ra quyết định liên quan đến việc bổ sung
trường hợp thử nghiệm vào nhà máy thử nghiệm trong chu kỳ thử
nghiệm hoặc sau khi hoàn thành chu kỳ thử nghiệm.
Phần phát triển các trường hợp thử nghiệm mới của tài liệu làm rõ
chiến lược để viết các trường hợp thử nghiệm mới trong quá trình
thực thi các trường hợp thử nghiệm. Nó phải được thông báo cho các
kỹ sư thử nghiệm trước khi bắt đầu chu kỳ thử nghiệm để một trong
các hành động sau được thực hiện:
Phát triển các trường hợp thử nghiệm mới trong chu kỳ thử nghiệm.
Bao gồm một ghi chú trong báo cáo lỗi nói rằng một trường hợp thử
nghiệm cần được phát triển sau đó cho lỗi này và tiếp tục thực hiện
các trường hợp thử nghiệm theo lịch trình.
Bạn nên thực hiện cách tiếp cận thứ hai, vì rất khó tìm thời gian để
viết các trường hợp kiểm thử trong quá trình thực hiện kiểm thử trừ
khi nó nằm trong lịch trình. Do đó, kỹ sư thử nghiệm nên quay lại các
khuyết tật riêng lẻ và thêm các trường hợp thử nghiệm vào nhà máy
thử nghiệm dựa trên báo cáo lỗi sau khi hoàn thành chu trình thử
nghiệm.
13.4 CÁC PHƯƠNG PHÁP THỬ NGHIỆM HỆ THỐNG THEO DÕI
579
Thông thường, các kỹ sư thử nghiệm tải hình ảnh phần mềm từ nhóm
tích hợp hệ thống xuống các giường thử nghiệm được phân bổ của họ
ít nhất hai hoặc ba tuần trước khi chính thức bắt đầu chu kỳ thử
nghiệm đầu tiên. Điều này cho phép kỹ sư thử nghiệm làm quen với
hình ảnh phần mềm và đảm bảo rằng giường thử nghiệm hoạt động
hoàn toàn. Hoạt động này được theo dõi cho từng kỹ sư kiểm tra hệ
thống trong phần thử nghiệm hình ảnh hệ thống của tài liệu làm việc,
ngay cả khi bản dựng không được phát hành chính thức để bắt đầu
kiểm tra hệ thống. Có một số lợi ích khi sử dụng hình ảnh phần mềm
dùng thử trước ngày bắt đầu chính thức của chu kỳ kiểm tra hệ thống:
Các kỹ sư kiểm thử được đào tạo để làm quen với hệ thống để năng
suất thực thi kiểm thử cao hơn trong chu kỳ kiểm tra hệ thống. • Để
đảm bảo rằng giường kiểm tra hoạt động mà không có bất kỳ thời
gian chết nào khi bắt đầu chu kỳ kiểm tra hệ thống.
Các trường hợp thử nghiệm cơ bản có thể được thực thi sớm hơn để
xác nhận các bước thử nghiệm.
Lịch trình của cuộc họp xem xét khiếm khuyết phải được thực hiện
trước khi bắt đầu chu kỳ kiểm tra hệ thống. Lịch trình được thiết lập
cho toàn bộ khoảng thời gian của chu kỳ thử nghiệm trước khi bắt
đầu thử nghiệm hệ thống. Người lãnh đạo kiểm tra có thể sử dụng
biểu đồ Gantt để thể hiện một lịch trình và đưa nó vào lịch trình phần
họp xem xét khiếm khuyết của tài liệu làm việc thực hiện kiểm tra.
Các thành viên trong nhóm đa chức năng từ phát triển phần mềm,
phát triển phần cứng và các nhóm hỗ trợ khách hàng được mời tham
dự cuộc họp này.
13.4 CÁC PHƯƠNG PHÁP THỬ NGHIỆM HỆ THỐNG THEO
DÕI
Việc thực thi kiểm tra hệ thống mang lại (ba) khía cạnh khác nhau
của phát triển phần mềm. Các nhà phát triển muốn biết mức độ mà hệ
thống đáp ứng các yêu cầu rõ ràng cũng như ngầm định. Không thể
dự đoán chính xác ngày giao hàng do sự không chắc chắn trong việc
khắc phục sự cố. Khách hàng rất vui khi nhận được sản phẩm. Do đó,
nó là một hoạt động thú vị và dễ thấy. Ở giai đoạn này, bạn nên theo
dõi một số số liệu thực sự đại diện cho tiến trình kiểm tra hệ thống và
tiết lộ mức chất lượng của hệ thống. Dựa trên các số liệu đó, ban
quản lý có thể kích hoạt các hành động để có các biện pháp khắc
phục và phòng ngừa. Bằng cách đưa một bộ thước đo nhỏ nhưng
quan trọng vào, quản lý điều hành có thể biết liệu họ có đang đi đúng
hướng hay không [1]. Chúng tôi tạo ra sự khác biệt giữa số liệu thống
kê và số liệu trong quá trình: Số liệu thống kê được sử dụng để phân
tích sau dự án nhằm thu thập kinh nghiệm và sử dụng nó trong các dự
án trong tương lai, trong khi số liệu trong quá trình cho phép chúng
tôi theo dõi tiến độ của dự án trong khi chúng tôi vẫn có cơ hội chỉ
đạo nhiên của dự án. Bằng cách xem xét ba dự án thử nghiệm lớn,
trong cuộc sống thực, chúng tôi phân loại các chỉ số thực thi thành
hai lớp:
Để giám sát việc thực hiện kiểm tra
Để giám sát các khuyết tật
Lớp số liệu đầu tiên liên quan đến quá trình thực thi các trường hợp
thử nghiệm, trong khi lớp thứ hai liên quan đến các khiếm khuyết
được tìm thấy do kết quả của việc thực thi thử nghiệm. Các chỉ số này
cần được theo dõi và phân tích định kỳ, chẳng hạn như hàng ngày
hoặc hàng tuần. Điều quan trọng là phải thu thập thông tin hợp lệ và
chính xác về dự án cho trưởng nhóm kiểm thử hệ thống để kiểm soát
hiệu quả dự án kiểm thử. Một ví dụ về kiểm soát hiệu quả dự án thử
nghiệm là xác định chính xác thời gian để kích hoạt các tiêu chí hoàn
nguyên cho một chu kỳ thử nghiệm và bắt đầu phân tích nguyên nhân
gốc rễ của các vấn đề trước khi thực hiện nhiều thử nghiệm hơn.
Người quản lý thử nghiệm có thể tận dụng hiệu quả thời gian của các
kỹ sư thử nghiệm bằng cách kích hoạt tiêu chí hoàn nguyên như vậy
và có thể là tiền, bằng cách tạm dừng chu kỳ thử nghiệm trên một sản
phẩm có quá nhiều lỗi để thực hiện một thử nghiệm hệ thống có ý
nghĩa. Do đó, mục tiêu của chúng tôi là xác định và theo dõi các chỉ
số trong khi quá trình kiểm tra hệ thống đang diễn ra để nhóm quản lý
có thể đưa ra các quyết định nhanh nhạy [2].
13.4.1 Các chỉ số để giám sát việc thực hiện kiểm tra
Mong muốn giám sát việc thực hiện các trường hợp kiểm thử hệ
thống của một dự án lớn liên quan đến hàng chục kỹ sư kiểm thử và
mất vài tháng. Việc thực hiện kiểm tra hệ thống cho các dự án lớn
được theo dõi hàng tuần khi bắt đầu và hàng ngày cho đến khi kết
thúc. Chúng tôi đặc biệt khuyên bạn nên sử dụng các công cụ tự
581
động, chẳng hạn như nhà máy thử nghiệm, để theo dõi và báo cáo
trạng thái thực thi trường hợp thử nghiệm. Các loại truy vấn khác
nhau có thể được tạo để lấy số liệu trong quá trình sau khi có cơ sở
dữ liệu. Các số liệu sau đây hữu ích trong việc theo dõi thành công
các dự án thử nghiệm:
Test Case Escapes (TCE): Các kỹ sư thử nghiệm có thể thấy cần
thiết phải thiết kế các trường hợp thử nghiệm mới trong quá trình thử
nghiệm, được gọi là trường hợp thử nghiệm thoát, khi quá trình thử
nghiệm tiếp tục. Số lượng trường hợp thử nghiệm thoát được theo dõi
khi nó tăng lên. Sự gia tăng đáng kể số lượng trường hợp thử nghiệm
thoát ra ngoài ngụ ý những thiếu sót trong quá trình thiết kế thử
nghiệm và điều này có thể ảnh hưởng xấu đến tiến độ dự án.
Tỷ lệ thực thi theo kế hoạch so với thực thi (PAE): Số lượng
trường hợp thử nghiệm thực tế được thực hiện hàng tuần được so
sánh với số trường hợp thử nghiệm theo kế hoạch [3]. Số liệu này
hữu ích trong việc đại diện cho năng suất của nhóm kiểm thử trong
việc thực hiện các trường hợp kiểm thử. Nếu tốc độ thực hiện thực tế
thấp hơn nhiều so với tốc độ dự kiến, các nhà quản lý có thể phải
thực hiện các biện pháp phòng ngừa để thời gian cần thiết cho việc
kiểm tra hệ thống không ảnh hưởng xấu đến tiến độ dự án.
Trạng thái thực thi của trường hợp thử nghiệm (EST): Sẽ rất hữu
ích khi theo dõi định kỳ số lượng trường hợp thử nghiệm nằm ở các
trạng thái khác nhau — không thành công, đạt, bị chặn, không hợp lệ
và chưa được kiểm tra — sau khi thực hiện chúng. Nó cũng hữu ích
khi chia nhỏ hơn những con số đó theo các danh mục thử nghiệm,
chẳng hạn như cơ bản, chức năng và độ mạnh mẽ.
13.4.2 Ví dụ về chỉ số thực thi kiểm tra
Chúng tôi đưa ra các ví dụ về số liệu thực thi trường hợp thử nghiệm
từ một dự án thử nghiệm ngoài đời thực có tên là Bazooka. Tổng
cộng có 1592 trường hợp thử nghiệm được thiết kế để thực thi. Việc
thực hiện dự kiến 1592 trường hợp thử nghiệm hàng tuần trong chu
kỳ thử nghiệm 14 tuần được hiển thị
PEAE
1800
1600
1400
1200
1000
800
600
400
200
0
wk1wk2wk 3 wk4wk5wk6wk7wk8wk 9 wk10wk11wk12wk1 3 wk14wk15wk16
PE 25100150250400600800 9501100125014001500155015 9215 9215 92
AE 5 451212 97542841 991114812541 3241426151515661581158115 91
Hình 13.3 Chỉ số PAE của dự án Bazooka (PE: thực hiện dự kiến;
AE: thực thi).
trong Hình 13.3 dưới dạng biểu đồ thanh tích lũy cho chỉ số PAE. 25
trường hợp thử nghiệm được lên kế hoạch thực hiện trong tuần đầu
tiên, 75 trường hợp trong tuần thứ hai. Tổng số 100 trường hợp thử
nghiệm dự kiến sẽ được thực hiện vào cuối 2 tuần đầu tiên. Hàng thứ
hai ở dưới cùng của Hình 13.3, những hàng thực sự được thực thi,
được cập nhật. Người ta nên theo dõi số lượng các trường hợp thử
nghiệm được dự kiến và thực thi trên cơ sở hàng tuần trong các chu
kỳ thực thi. Nếu có sự khác biệt lớn giữa cả hai, có thể thực hiện hành
động ngay lập tức để tìm hiểu nguyên nhân gốc rễ của nó và cải thiện
tốc độ thực thi trước khi quá muộn. Tỷ lệ thực hiện thử nghiệm thấp
hơn tốc độ kế hoạch, như được hiển thị trong bảng, trong 3 tuần đầu
tiên. Các kỹ sư thử nghiệm đã mất khoảng 3 tuần để hiểu toàn bộ hệ
thống và đưa ra tốc độ. Dự án thử nghiệm mất 16 tuần, thay vì 14
tuần theo kế hoạch, để hoàn thành một chu kỳ thực thi cho tất cả các
trường hợp thử nghiệm, bao gồm cả việc thực thi lại tất cả các trường
hợp không thành công. Ban đầu, các kỹ sư thử nghiệm đã không chạy
các trường hợp thử nghiệm cho các danh mục căng thẳng, tải và ổn
định vì một số bản sửa lỗi liên quan đến rò rỉ bộ nhớ chỉ được kiểm
tra vào cuối tuần 13. Do đó, chu kỳ thử nghiệm đã được kéo dài thêm
583
2 tuần nữa. để đảm bảo rằng hệ thống có thể hoạt động mà không bị
rò rỉ bộ nhớ trong một thời gian dài.
Chúng ta hãy xem xét ví dụ trước của chúng ta, dự án thử nghiệm
Bazooka, mà chúng tôi đã chọn 1592 trường hợp thử nghiệm. Chỉ số
EST mà chúng tôi theo dõi hàng tuần cho mỗi nhóm thử nghiệm liên
quan đến số lượng trường hợp thử nghiệm ở các trạng thái sau: đạt,
không thành công, không hợp lệ, bị chặn và chưa được kiểm tra. Ví
dụ, trạng thái thực hiện kiểm tra của tuần 4 được thể hiện trong Bảng
13.5.
BẢNG 13,5 Chỉ số EST trong Tuần 4 của Dự án Bazooka
Tổng cộng Thông
qua/
Số lượng Thực
thi
Nhóm kiểm Các trường hợp kiểm tra đã vượt qua không (%)
tra thành công bị chặn không hợp lệ được thực
hiện chưa được kiểm tra
Nền tảng 156 64 9 0 0 73 83 87,67
Chức năng 480 56 7 0 0 63 417 88,89
Mạnh mẽ 230 22 1 0 0 23 207 95,65
Khả năng 149 15 2 0 0 17 132 88,24
tương tác
Tải và ổn 43 1 0 0 0 1 42 100,00
định
Màn biểu 54 0 0 0 0 0 54 0,00
diễn
Căng thẳng 36 0 0 0 0 0 36 0,00
Khả năng 54 5 0 0 0 5 49 100,00
mở rộng
hồi quy 356 93 13 0 0 106 250 87,74
Tài liệu 34 số 8 1 0 0 9 25 88,89
Tổng cộng 1592 264 33 0 0 297 1295 88,89
Chúng tôi giải thích cách nhóm Bazooka kiểm soát tiến độ thử
nghiệm hệ thống. Tiêu chí hoàn nguyên cho một chu kỳ thử nghiệm
là một vị từ về mức chất lượng của sản phẩm về tỷ lệ phần trăm các
trường hợp thử nghiệm đã thực thi đã vượt qua. Nếu một tiêu chí như
vậy được giữ nguyên, chu kỳ kiểm tra sẽ bị tạm dừng. Một ví dụ về
tiêu chí hoàn nguyên là: Tại bất kỳ thời điểm nào trong chu kỳ thử
nghiệm, nếu tỷ lệ lỗi tích lũy đạt 20%, chu kỳ sẽ bắt đầu lại toàn bộ
sau khi các lỗi được báo cáo đã được khắc phục. Chúng tôi hiển thị
phần trăm các trường hợp thử nghiệm được thực thi đã vượt qua
trong cột ngoài cùng bên phải của Bảng 13.6. Tỷ lệ vượt qua là
71,11% vào cuối tuần thứ hai của Bazooka, có nghĩa là tỷ lệ không
đạt là 28,89%. Xem xét các tiêu chí hoàn nguyên ví dụ được đưa ra ở
trên, chu kỳ thử nghiệm nên được bỏ qua. Tuy nhiên, là một trường
hợp đặc biệt, nhóm quản lý dự án Bazooka đã đưa ra quyết định
không từ bỏ chu trình thử nghiệm vì những lý do sau:
Chỉ có 45 trong số 1592 trường hợp thử nghiệm đã được thực hiện.
Một số trường hợp thử nghiệm được coi là đã thất bại do lỗi thủ tục
từ phía các kỹ sư thử nghiệm; những trường hợp thử nghiệm này cuối
cùng được coi là đã vượt qua.
Nhóm Bazooka đã đưa ra quyết định nhất trí là chờ thêm một tuần và
theo dõi kết quả thử nghiệm hàng ngày. Tỷ lệ đậu đã tăng lên 89,26%
vào cuối tuần thứ ba, như thể hiện trong Bảng 13.6. Vì tỷ lệ thất bại
thấp hơn nhiều so với ngưỡng 20% để kích hoạt tiêu chí hoàn
nguyên, chu kỳ kiểm tra được tiếp tục cho đến khi hoàn thành.
Ví dụ trên cho chúng ta biết rằng điều quan trọng là phải phân tích
các chỉ số thử nghiệm, thay vì đưa ra quyết định dựa trên dữ liệu thô.
Thật thú vị khi lưu ý rằng tỷ lệ thất bại tích lũy cao nhất là 19,5% đã
được quan sát trong tuần thứ 6 và 841 trường hợp thử nghiệm —
hoặc 52% tổng số trường hợp thử nghiệm sẽ được thực hiện — đã
được thực hiện. Chu kỳ kiểm tra hệ thống sẽ bị bỏ qua với sự gia tăng
của
BẢNG 13.6 Chỉ số EST trong Bazooka được theo dõi trên cơ sở
hàng tuần
Thực thi/ Thông Thông
qua/ qua/
Tuần Thực thi Thông Thất bại Tổng cộng Tổng cộng Thực thi
qua (%) (%) (%)
585
1 5 5 0 0,31 0,31 100,00
2 45 32 13 2,83 2,01 71,11
3 121 108 13 7.60 6,78 89,26
4 297 264 33 18,66 16,58 88,89
5 542 451 91 34.05 28,33 83,21
6 841 677 164 52,83 42,53 80,50
7 991 835 156 62,25 52,45 84,26
số 8 1148 1009 139 72,11 63,38 87,89
9 1254 1096 158 78,77 68,84 87,40
10 1324 1214 110 83,17 76,26 91,69
11 1426 1342 84 89,57 84,30 94,11
12 1515 1450 65 95,16 91,08 95,71
13 1566 1519 47 98,37 95.41 97,00
14 1581 1567 14 99,31 98.43 99,11
15 1581 1570 11 99,31 98,62 99,30
16 1591 1580 11 99,94 99,25 99,31
Lưu ý: Tổng số trường hợp thử nghiệm hợp lệ 1592.
chỉ 0,5% trong tỷ lệ thất bại. Các trường hợp kiểm thử liên quan đến
các khu vực dễ bị tấn công nhất của hệ thống đã được thực hiện trên
cơ sở ưu tiên vào đầu chu kỳ. Do đó, có tối đa 164 trường hợp thử
nghiệm không thành công trong vòng 6 tuần thử nghiệm đầu tiên.
Các hình ảnh mới kèm theo các bản sửa lỗi đã được phát hành để
kiểm tra hệ thống sau tuần thứ 6. Các trường hợp kiểm thử không
thành công đã được thực thi lại và hệ thống đã vượt qua các kiểm tra
đó, do đó cải thiện tỷ lệ vượt qua, như được hiển thị trong cột ngoài
cùng bên phải của Bảng 13.6. Chỉ có một trường hợp thử nghiệm từ
nhóm căng thẳng vẫn ở trạng thái chưa được kiểm tra vào cuối tuần
16.
13.4.3 Các thước đo để theo dõi các báo cáo lỗi
Các truy vấn có thể được phát triển để lấy các loại thông tin khác
nhau từ cơ sở dữ liệu sau khi hệ thống theo dõi lỗi được đưa vào. Khi
các kỹ sư kiểm tra hệ thống gửi các khiếm khuyết, các khiếm khuyết
sẽ được phân tích thêm. Dữ liệu hữu ích có thể được thu thập từ quá
trình phân tích để định lượng mức chất lượng của sản phẩm dưới
dạng các số liệu sau:
Chức năng như được thiết kế (FAD) Count: Thông thường các kỹ
sư kiểm tra báo cáo các lỗi không thực sự là lỗi thực sự do hệ thống
hiểu nhầm, được gọi là FAD. Nếu số lượng khuyết tật trong trạng thái
FAD vượt quá 10% các khuyết tật được gửi, chúng tôi suy ra rằng các
kỹ sư kiểm tra có hiểu biết không đầy đủ về hệ thống. Số lượng FAD
càng thấp, mức độ hiểu biết hệ thống của các kỹ sư thử nghiệm càng
cao.
Số lượng lỗi không thể tạo ra (IRD): Người ta phải có khả năng tái
tạo lỗi tương ứng sau khi lỗi được báo cáo để các nhà phát triển có
thể hiểu được lỗi đó để có thể sửa chữa nó. Nếu một lỗi không thể
được tái tạo, thì các nhà phát triển có thể không có được cái nhìn hữu
ích về nguyên nhân của lỗi. Một khiếm khuyết không hiệu quả không
có nghĩa là khiếm khuyết đó có thể được bỏ qua. Nó chỉ đơn giản có
nghĩa là khiếm khuyết là một khiếm khuyết phức tạp và rất khó sửa
chữa. Số lượng khuyết tật ở trạng thái không thể sản xuất, hoặc số
lượng khuyết tật ẩn, là thước đo mức độ không đáng tin cậy của hệ
thống.
Tỷ lệ xuất hiện lỗi (DAR): Báo cáo lỗi đến từ các nguồn khác nhau
trong quá trình kiểm tra hệ thống: nhóm kiểm tra hệ thống (ST),
nhóm phát triển phần mềm (SW), nhóm SIT và những người khác với
mục tiêu riêng của họ. Nhóm “những người khác” bao gồm các nhóm
hỗ trợ khách hàng, tiếp thị và tài liệu. Các khuyết tật được báo cáo
bởi tất cả các nhóm này được tập hợp lại và tính toán tỷ lệ phần trăm
các khuyết tật do mỗi nhóm báo cáo hàng tuần. Đây được gọi là tỷ lệ
lỗi được báo cáo bởi mỗi nhóm.
Tỷ lệ bị từ chối (DRR) của lỗi: Nhóm phát triển phần mềm cố gắng
sửa các lỗi được báo cáo bằng cách sửa đổi mã hiện có và / hoặc viết
thêm mã. Hình ảnh phần mềm mới có sẵn để kiểm tra hệ thống thêm
sau khi các lỗi này được khắc phục. Nhóm kiểm tra hệ thống xác
minh rằng các lỗi đã thực sự được khắc phục bằng cách chạy lại các
bài kiểm tra thích hợp. Ở giai đoạn này, nhóm kiểm tra hệ thống có
thể nhận thấy rằng một số lỗi được cho là đã sửa vẫn chưa thực sự
được sửa. Những khuyết tật như vậy được sử dụng để tạo ra số lượng
DRR. Số lượng DRR thể hiện mức độ mà nhóm phát triển đã thành
587
công trong việc sửa chữa các khiếm khuyết. Nó cũng cho chúng ta
biết về năng suất của nhóm phát triển phần mềm trong việc sửa chữa
các lỗi. Số lượng DRR cao trong một số tuần nên cảnh báo vì khả
năng cao dự án trượt khỏi kế hoạch.
Tỷ lệ đóng khuyết điểm (DCR): Nhóm kiểm tra hệ thống xác minh
giải pháp bằng cách kiểm tra thêm sau khi một lỗi được xác nhận là
đã được giải quyết. Chỉ số DCR thể hiện hiệu quả của việc xác minh
các tuyên bố về các bản sửa lỗi.
Số lượng khuyết tật còn tồn tại (OD): Một khiếm khuyết được báo
cáo được cho là một khiếm khuyết còn tồn tại nếu khiếm khuyết tiếp
tục tồn tại. Số liệu này phản ánh mức chất lượng hiện hành của hệ
thống khi quá trình kiểm tra hệ thống tiếp tục. Số OD giảm dần qua
các chu kỳ thử nghiệm riêng lẻ là bằng chứng về mức chất lượng
ngày càng cao hơn đạt được trong quá trình thử nghiệm hệ thống của
một sản phẩm.
Số lượng lỗi sự cố (CD): Các lỗi gây ra sự cố hệ thống phải được
công nhận là một loại lỗi quan trọng vì sự cố hệ thống là một sự kiện
nghiêm trọng dẫn đến hệ thống hoàn toàn không khả dụng và có thể
mất dữ liệu [4]. Số liệu này, thường được gọi là số liệu độ ổn định, rất
hữu ích trong việc xác định xem có nên phát hành hệ thống với mức
độ ổn định hiện tại của nó hay không.
Số lượng đến và giải quyết khuyết tật (ARD): Rất hữu ích khi so
sánh tỷ lệ khuyết tật được tìm thấy với tốc độ phân giải của chúng
[5]. Giải quyết khiếm khuyết liên quan đến chi phí làm lại nên được
giảm thiểu bằng cách thực hiện công việc phát triển lần đầu tiên theo
cách tốt hơn. Do đó, số liệu này hữu ích cho nhóm phát triển và giúp
họ ước tính thời gian có thể cần để sửa tất cả các lỗi. Các hành động
được thực hiện để đẩy nhanh quá trình giải quyết lỗi dựa trên thông
tin này.
13.4.4 Ví dụ về chỉ số báo cáo lỗi
Chúng tôi đưa ra các ví dụ cho hầu hết các chỉ số ở trên bằng cách sử
dụng dữ liệu từ một dự án thử nghiệm thứ hai có tên là Stinger. DAR
hàng tuần từ mỗi nhóm của tổ chức thực hiện thử nghiệm cấp hệ
thống trong chu kỳ thực hiện thử nghiệm thứ hai trong 16 tuần được
thể hiện trong Bảng 13.7. Tổng số khuyết tật mở còn lại từ chu kỳ
kiểm tra đầu tiên được đưa ra trong hàng đầu tiên của bảng là tuần 0.
Số lỗi trung bình được gửi mỗi tuần bởi ST, SW, SIT và các lỗi khác
là 57, 15, 10 và 18, tương ứng. Ở đây, thuật ngữ “những người khác”
bao gồm các thành viên từ các nhóm hỗ trợ khách hàng, tiếp thị và tài
liệu. Tỷ lệ xuất hiện của các khuyết tật trong 6 tuần đầu tiên cao hơn
nhiều so với phần còn lại của chu kỳ thử nghiệm. Điều này là do thực
tế là các trường hợp thử nghiệm sớm trong chu kỳ thử nghiệm được
ưu tiên để loại bỏ các khiếm khuyết trong các phần dễ bị tổn thương
hơn của hệ thống.
Số lượng DRR cho dự án Stinger được thể hiện trong Bảng 13.8. Tỷ
lệ loại bỏ sai sót trung bình là 5,24%. Tỷ lệ bị từ chối là gần 6% trong
thời gian
BẢNG 13.7 Chỉ số DAR cho Dự án Stinger
ST SWSITOthersTotal
Số Số Số Số của trong số
tuần Phần trăm sai sót Phần trăm khiếm khuyết Phần trăm sai sót
Phần trăm sai sót
0 663 69,21 172 17,95 88 9,19 35 3,65 958 1 120 79,47 28 18,54 2
1,32 1 0,66 151 2 99 55,00 44 24,44 31 17,22 6 3,33 180 3 108 53,73
54 26,87 31 15,42 8 3,98 201 4 101 65,16 16 10,32 22 14,19 16 10,32
155
5 107 57.222111.232613.903317.65187 6 108
56.25168.333518.233317.19192 7 59
57.8400.0010.984241.18102 8 15
31.91919.1536.382042.5547 9 28
59.5700.0012.131838.3047 10 14
50.00414.2900.001035.7128 11 _ _ _ _
_ 59 53.6454.5598.183733.64110 13 28
54.9059.8000.001835.2951
23 51.1100.0000.002248.8945
12 31.582155.2637.8925.2638 16 24
38.712337.1000.001524.1962
Tổng 917 2471642931,621
Avearge 57 56.571515.241010.121818.08
589
BẢNG 13.8 Trạng thái DRR hàng tuần cho dự án thử nghiệm
Stinger
Số lượng Số lượng Số lượng Khuyết
tật
Tuần Đã xác minh Các khiếm Các khiếm Phế
khiếm khuyết khuyết đãkhuyết bị từphẩm
đóng chối (%)
1 283 269 14 4,95
2 231 216 15 6,49
3 266 251 15 5,64
4 304 284 20 6,58
5 194 183 11 5,67
6 165 156 9 5,45
7 145 136 9 6.21
số 8 131 122 9 6,87
9 276 262 14 5,07
10 160 152 số 8 5,00
11 52 49 3 5,77
12 80 74 6 7.50
13 71 71 0 0,00
14 60 58 2 3,33
15 121 119 2 1,65
16 97 96 1 1,03
Tổng 2636 2498 138
Avearge 165 156 9 5,24
8 tuần đầu tiên, và trong 4 tuần tiếp theo, con số này là khoảng 5%.
Trong phần còn lại của chu kỳ thử nghiệm, tỷ lệ từ chối giảm xuống
gần 1,5%.
Số lượng OD được cho trong Bảng 13.9. Các khuyết tật có mức độ
ưu tiên nghiêm trọng, cao, trung bình và thấp được ký hiệu lần lượt
bằng P1, P2, P3 và P4. Mức độ ưu tiên là thước đo mức độ sớm sửa
chữa các khuyết tật. Số lượng khuyết tật tồn đọng được chuyển tiếp
từ chu kỳ kiểm tra đầu tiên sang chu kỳ thứ hai được đưa ra trong
hàng đầu tiên của bảng dưới dạng thống kê tuần 0. Rõ ràng là từ số
liệu này, tổng số lỗi còn tồn tại giảm dần từ 958 xuống 81 trong vòng
16 tuần.
Số vụ va chạm được quan sát bởi các nhóm khác nhau trong 8 tuần
thử nghiệm cuối cùng được thể hiện trong Bảng 13.10. Có thể thấy rõ
từ bảng này rằng tổng số sự cố giảm dần từ 20 sự cố mỗi tuần xuống
còn 1 sự cố mỗi tuần. Người ta phải xem xét kỹ hơn những sự cố này
để xác định nguyên nhân gốc rễ của từng sự cố riêng lẻ. Nhóm phát
triển phải điều tra những sự cố này riêng lẻ.
Cuối cùng, chúng tôi đưa ra một ví dụ về số liệu ARD bằng cách xem
xét một dự án thử nghiệm thứ ba có tên Bayonet. Số lượng khuyết tật
dự kiến được gửi, giải quyết và vẫn còn mở trong bốn tuần đầu tiên
của chu kỳ thử nghiệm được đưa ra ở nửa trên của Bảng 13.11. Các
con số dự kiến được rút ra từ một dự án thử nghiệm trước đó [6] có
các đặc điểm rất giống với Bayonet. Khi bắt đầu chu kỳ thử nghiệm,
tổng số khuyết tật hở là 184. Trong số 184 khuyết tật này, 50 khuyết
tật thuộc mức ưu tiên P1 hoặc P2, 63 khuyết tật thuộc cấp độ P3 và
71 khuyết tật thuộc
BẢNG 13.9 OD hàng tuần trên cơ sở ưu tiên cho dự án thử
nghiệm Stinger
P1 P1P3P4Tổng
Tỷ lệ sai sót trong tuần
14 1.4621522.4439941.6533034.45958
19 2.2616419.5228033.3337744.88840
17 2.1113817.1623629.3541351.37804
11 1.4610814.3218124.0145460.21754 4 7
1.12447.0412319.6845172.16625
5 5 0,79 28 4,45 123 19,55 473 75,20 629 6 10 1,50 33 4,96 123
18,50 499 75,04 665 7 11 1,74 83 13,15 52 8,24 485 76,86 631
8 5 0,90 34 6,12 32 5,76 485 87,23 556 9 8 2,35 21 6,16 39 11,44 273
80,06 341 10 4 1,84 21 9,68 36 16,59 156 71,89 217 11 4 2,07 26
13,47 38 19,69 125 64,77 193
591
12 3 1,31 28 12,23 84 36,68 114 49,78 229 13 3 1,44 40 19,14 84
40,19 82 39,23 209 14 10 5.10 42 21,43 68 34,69 76 38,78 196 15 2
1,74 34 29,57 38 33,04 41 35,65 115 16 3 3,70 25 30,86 24 29,63 29
35,80 81
BẢNG 13.10 Đĩa CD hàng tuần được quan sát bởi các nhóm
khác nhau cho dự án thử nghiệm Stinger
S / W STSITOthersTotal
trong tuần Phần trăm số lần bị lỗi Phần trăm số lần bị lỗi Tỷ lệ
phần trăm số lần bị lỗi
9 6 30,00 8 40,00 6 30,00 0 0,00 20 10 5 31,25 6 37,50 3 18,75 2

12,50 16 11 4 25,00 9 56,25 0 0,00 3 18,75 16 12 3 33,33 4 44,44 0
0,00 2 22,22 9
13 2 22,22 6 66,67 0 0,00 1 11,11 9 14 1 14,29 2 28,57 1 14,29 3
42,86 7 15 0 0,00 2 66,67 1 33,33 0 0,00 3
16 0 0,001100,0000,0000,001
Tổng 21 38111181
Trung bình 3 25,93546,91113,58113,5810
mức P4. Số lượng thực tế của các khiếm khuyết đã gửi và đã giải
quyết được hiển thị ở nửa dưới của cùng một bảng. Số lượng khiếm
khuyết mở thực tế thấp hơn một chút so với con số dự kiến sau khi
hoàn thành tuần đầu tiên. Tuy nhiên, số lượng khiếm khuyết được
giải quyết thực tế thấp hơn nhiều so với con số dự kiến trong tuần thứ
hai. Điều này cho thấy rằng các nhà phát triển phần mềm đã chậm
hơn trong việc giải quyết các khiếm khuyết. Tổng số khuyết tật mở
vào cuối tuần thứ hai cao hơn con số ước tính. Ở giai đoạn này, người
quản lý phát triển phần mềm phải thực hiện các hành động để cải
thiện tỷ lệ giải quyết lỗi bằng cách tăng giờ làm việc hoặc chuyển các
nhà phát triển phần mềm từ dự án khác sang Bayonet. Trong
BẢNG 13.11 Chỉ số ARD cho Bayonet
Đã đệ trình Đã giải quyết M

ở
P1 + P2 P1 + P2
Tổn Tổn Tổn
P3
g g g P1
Tuầ Xây cộn P P cộn P cộn + P P
n dựng g 3 4 g 4 g P2 3 4
Dự kiến 6 7
184 50 3 1
1 xây 75 24 3 1 118 38 60 2 141 36 3 6
dựng 6 5 0 9 6
10
2 xây 75 24 3 1 118 38 60 2 98 22 1 6
dựng 6 5 0 5 1
11
3 xây 75 24 3 1 95 38 37 2 78 số 1 5
dựng 6 5 0 8 4 6
12
4 xây 14 5 7 2 20 10 5 5 72 3 1 5
dựng Thật sự 6 3
13
1 xây 67 23 2 1 119 37 49 3 132 36 4 5
dựng 7 7 3 1 5
10
2 xây 77 26 3 1 89 37 37 1 120 25 4 5
dựng 6 5 5 0 5
11
3 xây 62 18 3 1 100 36 52 1 82 7 2 5
dựng 2 2 2 0 5
12
4 xây 27 11 1 4 33 15 số 8 1 76 3 2 4
dựng 2 0 4 9
13
593
trường hợp này, người quản lý đã chuyển một nhà phát triển phần
mềm có kinh nghiệm đến dự án này để xúc tiến việc giải quyết các
khiếm khuyết còn tồn tại. Nên chuẩn bị sẵn phần trên của bảng trước
khi bắt đầu chu kỳ thử nghiệm. Nửa sau của bảng diễn biến khi chu
kỳ kiểm tra tiến triển để mọi người trong nhóm phát triển nhận thức
được tiến trình giải quyết lỗi.
13.5 PHÂN LOẠI ĐỊNH NGHĨA HỮU CƠ
Phân loại khiếm khuyết trực giao (ODC) [7] là một phương pháp để
nắm bắt nhanh chóng ngữ nghĩa của từng khiếm khuyết phần mềm.
Phương pháp luận ODC cung cấp cả sơ đồ phân loại các lỗi phần
mềm và một tập hợp các khái niệm cung cấp hướng dẫn phân tích dữ
liệu lỗi tổng hợp đã phân loại. Ở đây, tính trực giao đề cập đến bản
chất không dư thừa của thông tin được thu thập bởi các thuộc tính
khuyết tật và các giá trị của chúng được sử dụng để phân loại khuyết
tật. Việc phân loại khuyết tật xảy ra ở hai thời điểm khác nhau trong
vòng đời của khuyết tật. Đầu tiên, một khiếm khuyết được đặt ở trạng
thái mới ban đầu khi nó được phát hiện, trong đó các trường hợp dẫn
đến sự bộc lộ của khiếm khuyết và tác động có thể xảy ra thường
được biết đến. Thứ hai, một khiếm khuyết được chuyển sang trạng
thái đã được giải quyết, nơi bản chất chính xác của khiếm khuyết và
phạm vi sửa chữa được biết. Các danh mục ODC nắm bắt ngữ nghĩa
của một khiếm khuyết từ hai khía cạnh này. Ở trạng thái mới, người
gửi cần điền vào các trường hoặc thuộc tính ODC sau:
Hoạt động: Đây là hoạt động thực tế đang được thực hiện tại thời
điểm phát hiện ra lỗi. Ví dụ: nhà phát triển có thể quyết định xem xét
mã của một quy trình cụ thể trong giai đoạn thử nghiệm hệ thống.
Trong trường hợp này, thuật ngữ sẽ là “kiểm tra hệ thống”, trong khi
hoạt động là “xem xét mã”.
13.5 PHÂN LOẠI ĐỊNH NGHĨA HỮU CƠ

Kích hoạt: Môi trường hoặc điều kiện đã tồn tại để khuyết tật nổi
lên. Trình kích hoạt mô tả các yêu cầu để tái tạo khuyết tật.
Tác động: Điều này đề cập đến ảnh hưởng của lỗi đối với khách
hàng nếu lỗi đã thoát ra hiện trường.
Chủ sở hữu của lỗi chuyển lỗi sang trạng thái đã giải quyết khi lỗi đã
được sửa và cần điền vào các trường hoặc thuộc tính ODC sau:
Mục tiêu: Mục tiêu đại diện cho danh tính cấp cao, chẳng hạn như
thiết kế, mã hoặc tài liệu, của thực thể đã được cố định.
Loại khuyết tật: Loại khuyết tật đại diện cho việc sửa chữa thực tế
đã được thực hiện.
: Bộ định tính chỉ định liệu bản sửa lỗi được thực hiện do thiếu,
không chính xác hoặc mã không liên quan.
Nguồn: Nguồn cho biết liệu lỗi có được tìm thấy trong mã được phát
triển nội bộ, được sử dụng lại từ thư viện, được chuyển từ nền tảng
này sang nền tảng khác hay do nhà cung cấp cung cấp.
Tuổi: Lịch sử của thiết kế hoặc mã có vấn đề. Độ tuổi chỉ định xem
lỗi được tìm thấy trong mã mới, cũ (cơ sở), được viết lại hoặc được
sửa lại:
Mới: Lỗi nằm trong một chức năng mới được tạo bởi và cho dự án
hiện tại.
Cơ sở: Lỗi nằm trong một phần của sản phẩm chưa được sửa đổi bởi
dự án hiện tại và không phải là một phần của thư viện tái sử dụng
tiêu chuẩn. Dự án hiện tại không tiêm vào khiếm khuyết, và do đó nó
là một khiếm khuyết tiềm ẩn.
Viết lại: Lỗi được đưa ra là kết quả trực tiếp của việc thiết kế lại và /
hoặc viết lại một chức năng cũ trong nỗ lực cải thiện thiết kế hoặc
chất lượng của nó.
Đã sửa lại: Lỗi được đưa vào bởi giải pháp được cung cấp để sửa lỗi
trước đó.
Các thuộc tính ODC có thể được thu thập bằng cách sửa đổi một
công cụ theo dõi lỗi hiện có đang được sử dụng để mô hình hóa các
lỗi. Khi dữ liệu được thu thập, chúng phải được xác nhận và đánh giá
một cách thường xuyên. Các khuyết tật được phân loại riêng lẻ được
xem xét để đảm bảo tính nhất quán và đúng đắn của việc phân loại.
Dữ liệu đã sẵn sàng để đánh giá sau khi chúng đã được xác nhận.
Việc đánh giá không được thực hiện đối với từng khiếm khuyết riêng
595
lẻ; thay vào đó là các xu hướng và kiểu mẫu trong dữ liệu tổng hợp
được nghiên cứu. Đánh giá dữ liệu của dữ liệu được phân loại ODC
dựa trên mối quan hệ của các thuộc tính ODC với nhau và với các
thuộc tính không phải của ODC, chẳng hạn như danh mục, mức độ
nghiêm trọng và ngày gửi lỗi [8]. Ví dụ, mối quan hệ giữa các thuộc
tính của loại khuyết tật, định tính, chủng loại, ngày gửi và mức độ
nghiêm trọng của khuyết tật cần được xem xét để đánh giá tính ổn
định của sản phẩm.
Đánh giá ODC phải được thực hiện bởi một nhà phân tích quen
thuộc với dự án và quan tâm đến phân tích dữ liệu. Cần có một công
cụ thân thiện với người dùng để trực quan hóa dữ liệu. Nhà phân tích
ODC phải cung cấp phản hồi thường xuyên, chẳng hạn, hàng tuần,
cho nhóm phát triển phần mềm để có thể thực hiện các hành động
thích hợp. Sau khi phản hồi được đưa ra cho nhóm phát triển phần
mềm, họ có thể xác định và ưu tiên các hành động sẽ được thực hiện
để ngăn ngừa các khiếm khuyết tái diễn.
ODC cùng với việc áp dụng kỹ thuật phân tích Pareto [9, 10] cho
một dấu hiệu tốt về các bộ phận của hệ thống dễ bị lỗi và do đó, cần
phải kiểm tra nhiều hơn. Juran [9] đã phát biểu nguyên tắc Pareto rất
đơn giản là "tập trung vào số ít quan trọng chứ không phải số ít tầm
thường." Một cách diễn đạt khác của nguyên tắc là phát biểu rằng
80% vấn đề có thể được khắc phục với 20% nỗ lực, thường được gọi
là quy tắc 80–20. Nguyên tắc này hướng dẫn chúng tôi sử dụng hiệu
quả nỗ lực và nguồn lực. Ví dụ, giả sử rằng chúng ta có dữ liệu về
hạng mục thử nghiệm và tần suất xuất hiện các lỗi cho một dự án thử
nghiệm hệ thống Cưa xích giả định như được thể hiện trong Bảng
13.12. Dữ liệu được vẽ trên biểu đồ Pareto, thể hiện trong Hình 13.4,
là biểu đồ hình cột thể hiện tần suất xuất hiện các khuyết tật với
những khuyết tật thường xuyên xuất hiện trước nhất. Lưu ý rằng
chức năng và các nhóm cơ bản có nồng độ khuyết tật cao. Thông tin
này giúp các kỹ sư kiểm tra hệ thống tập trung vào chức năng và các
phần danh mục cơ bản của dự án thử nghiệm Cưa. Hướng dẫn chung
để áp dụng phân tích Pareto như sau:
Thu thập dữ liệu ODC và không phải ODC liên quan đến các khu
vực có vấn đề.
Xây dựng biểu đồ Pareto.
Sử dụng sơ đồ để xác định một số ít quan trọng là các vấn đề cần

được giải quyết trên cơ sở cá nhân.
Sử dụng sơ đồ để xác định nhiều vấn đề nhỏ là các vấn đề cần được
xử lý dưới dạng các lớp.
BẢNG 13.12 Dữ liệu thử nghiệm mẫu của thử nghiệm cưa máy
Dự án
Số lượng
Loại Sự xuất hiện
khiếm khuyết
1. Cơ bản 25
2. Chức năng 48
3. Độ bền 16
4. Khả năng tương tác 4
5. Tải trọng và ổn định 6
6. Hiệu suất 12
7. Căng thẳng 6
8. Khả năng mở rộng 7
9. Hồi quy 3
10. Tài liệu 2
13.6 PHÂN TÍCH NGUYÊN NHÂN ĐÁNH GIÁ
60
50
40
Defect frequency
30
20
10
2 1368574910
Loại
597
Hình 13.4 Biểu đồ Pareto phân bố khuyết tật được trình bày
trong Bảng 13.12.
Nhận xét. Vilfredo Federico Damaso Pareto là nhà xã hội học, nhà
kinh tế và triết học người Pháp - Ý. Ông đã có một số đóng góp quan
trọng, đặc biệt là trong nghiên cứu về phân phối thu nhập và phân
tích các lựa chọn của cá nhân. Năm 1906, ông đưa ra quan sát nổi
tiếng rằng 20% dân số sở hữu 80% tài sản ở Ý, sau đó được Joseph
M. Juran và những người khác khái quát thành cái gọi là nguyên tắc
Pareto (còn gọi là quy tắc 80–20) và được khái quát hóa thêm về khái
niệm phân phối Pareto.
13.6 PHÂN TÍCH NGUYÊN NHÂN NGUYÊN NHÂN
Ý tưởng về phân tích nhân quả khiếm khuyết (DCA) trong phát triển
phần mềm được sử dụng hiệu quả để nâng cao chất lượng sản phẩm
với chi phí thấp hơn. Phân tích nguyên nhân có thể được bắt nguồn
từ các tài liệu về kiểm soát chất lượng [11] như một trong những hoạt
động của vòng tròn chất lượng trong lĩnh vực sản xuất. Khái niệm
vòng tròn chất lượng được thảo luận trong Phần 1.1. Nguyên nhân
của các lỗi sản xuất được phân tích bằng cách sử dụng ý tưởng về
một vòng tròn chất lượng, sử dụng sơ đồ nguyên nhân và kết quả và
sơ đồ Pareto. Sơ đồ nguyên nhân - kết quả còn được gọi là sơ đồ
Ishikawa hoặc sơ đồ xương cá. Philip Crosby [12] đã mô tả một
nghiên cứu điển hình của một tổ chức có tên là “HPA Appliance”
liên quan đến việc sử dụng phân tích nhân quả để ngăn ngừa các lỗi
trên dây chuyền sản xuất. Phân tích nguyên nhân của các lỗi phần
mềm được thực hiện ở một số công ty Nhật Bản, thường là trong bối
cảnh các hoạt động của vòng tròn chất lượng [13, 14].
Ý tưởng về DCA được phát triển tại IBM [15]. Các khiếm khuyết
được phân tích để (i) xác định nguyên nhân gây ra lỗi, (ii) thực hiện
các hành động để ngăn chặn các lỗi tương tự xảy ra trong tương lai
và (iii) loại bỏ các khiếm khuyết tương tự có thể tồn tại trong hệ
thống hoặc phát hiện chúng ở thời điểm sớm nhất có thể trong quá
trình phát triển phần mềm. Do đó, DCA đôi khi được gọi là RCA
phòng ngừa khiếm khuyết hoặc khiếm khuyết [16]. Tầm quan trọng
của DCA đã được Watts S. Humphrey [17] thể hiện một cách ngắn
gọn như sau: “Trong khi việc phát hiện và sửa chữa các khiếm
khuyết là cực kỳ quan trọng, nó là một chiến lược phòng thủ vốn có.
Để thực hiện những cải tiến chất lượng đáng kể, bạn nên xác định
nguyên nhân của những khiếm khuyết này và thực hiện các bước để
loại bỏ chúng ”.
Trong bài viết hướng dẫn của mình [18], David N. Card giải thích
quy trình năm bước để tiến hành DCA. Card gợi ý ba nguyên tắc
chính để thúc đẩy DCA:
Giảm số lượng khuyết tật để cải thiện chất lượng: Người ta có thể
định nghĩa chất lượng phần mềm dưới dạng các yếu tố và thuộc tính
chất lượng, nhưng không cần thiết phải nói rằng một sản phẩm có
nhiều khuyết tật là thiếu chất lượng. Chất lượng phần mềm được cải
thiện bằng cách tập trung vào việc ngăn ngừa lỗi và phát hiện sớm
các lỗi.
Áp dụng kiến thức chuyên môn của địa phương khi có lỗi xảy ra:
Trách nhiệm của DCA nên được trao cho các nhà phát triển phần
mềm đã vô tình góp phần vào các sai sót. Họ có đủ điều kiện tốt nhất
để xác định điều gì đã xảy ra và cách ngăn chặn nó. DCA nên diễn ra
tại địa điểm thực tế xảy ra sự cố, thay vì trong một phòng họp từ xa.
Nói cách khác, DCA nên được thực hiện tại nguồn.
Tập trung vào các lỗi hệ thống: Một cách trực quan, một lỗi được
cho là một lỗi hệ thống nếu cùng một lỗi hoặc các lỗi tương tự xảy ra
nhiều lần. Các lỗi hệ thống chiếm một phần đáng kể trong các lỗi
được tìm thấy trong các dự án phần mềm. Việc xác định và ngăn
ngừa các lỗi hệ thống có tác động rất lớn đến chất lượng của sản
phẩm.
Như thuật ngữ gợi ý, DCA tập trung vào việc hiểu mối quan hệ
nguyên nhân - kết quả [19]. Ba điều kiện được thiết lập để chứng
minh mối quan hệ nhân quả giữa một nguyên nhân và một triệu
chứng ở dạng thất bại:
Phải có mối tương quan giữa nguyên nhân giả thuyết và kết quả.
Nguyên nhân được giả thuyết phải có trước hiệu ứng kịp thời.
Cơ chế liên kết nguyên nhân với kết quả phải được xác định.
Điều kiện đầu tiên chỉ ra rằng hiệu ứng có thể được quan sát thấy khi
một nguyên nhân xảy ra. Điều kiện thứ hai là hiển nhiên. Điều kiện
thứ ba yêu cầu điều tra, bao gồm năm bước để chọn ra các lỗi hệ
thống liên quan đến các hư hỏng phổ biến và truy tìm nguyên nhân
ban đầu của chúng:
599
Khi nào lỗi được phát hiện và lỗi tương ứng được tiêm vào? Lưu ý
giai đoạn phát triển, nghĩa là, xem xét mã, thử nghiệm đơn vị, thử
nghiệm tích hợp hoặc thử nghiệm hệ thống, nơi lỗi được quan sát
thấy. Tiếp theo, xác định giai đoạn phát triển trong đó lỗi tương ứng
được tiêm vào. Các nhà phát triển xác định các khu vực có vấn đề
hơn bằng cách xem xét thông tin trên.
Lược đồ nào được sử dụng để phân loại lỗi? Chúng tôi xác định các
lớp lỗi quan trọng trong bước này. Nhóm các lỗi lại với nhau giúp
chúng tôi xác định
13.6 PHÂN TÍCH NGUYÊN NHÂN ĐÁNH GIÁ
trong đó các vấn đề phổ biến có thể được tìm thấy. Người ta có thể
sử dụng sơ đồ Pareto để xác định các cụm vấn đề. Không giống như
lược đồ ODC, DCA không sử dụng một tập hợp các danh mục lỗi
được xác định trước. Mục tiêu của DCA không phải là phân tích tỷ lệ
phần trăm lỗi trong từng hạng mục, mà là phân tích từng lỗi để hiểu
lý do lỗi xảy ra và thực hiện các biện pháp phòng ngừa. Việc phân
loại lỗi dựa trên bản chất của công việc đã thực hiện, cơ hội mắc lỗi
và động thái hiện tại của dự án. Giả sử rằng trong quá trình phân tích
của chúng tôi, chúng tôi nhận thấy rằng có nhiều lỗi liên quan đến
giao diện chương trình. Sau đó, chúng ta có hai cấp độ phân loại lỗi:
(i) phân loại thô được gọi là lỗi giao diện và (ii) nhiều danh mục con
chi tiết, chẳng hạn như xây dựng, sử dụng sai giao diện và khởi tạo,
như đã thảo luận trong Phần 7.2.
Vấn đề thường gặp (lỗi hệ thống) là gì? Tập hợp các báo cáo sự cố
bao gồm một cụm lỗi, được xác định trong bước thứ hai ở trên, đưa
ra dấu hiệu của một lỗi hệ thống. Nói chung, lỗi hệ thống có liên
quan đến chức năng cụ thể của sản phẩm. Bỏ qua ảnh hưởng của các
lỗi riêng lẻ trong việc tìm ra các lỗi hệ thống trong quá trình xác
định.
Nguyên nhân chính của các sai sót là gì? Chúng tôi cố gắng theo dõi
lỗi trở lại nguyên nhân của nó và tìm hiểu nguyên nhân gốc rễ liên
quan đến nhiều lỗi trong cụm. Việc tìm ra nguyên nhân của sai sót
đòi hỏi (i) hiểu biết thấu đáo về quy trình và sản phẩm và (ii) kinh
nghiệm và khả năng phán đoán. Để đạt được mục tiêu này, chúng ta
có thể cần vẽ một sơ đồ nguyên nhân - kết quả như trong Hình 13.5.
Đầu tiên, vấn đề đang được phân tích phải được nêu ra và sau đó
nhánh chính của sơ đồ kết nối với tuyên bố vấn đề được vẽ. Thứ hai,
các nguyên nhân chung được sử dụng trong sơ đồ được thêm vào.
Các nguyên nhân chung thường chia thành bốn loại như Ishikawa đã
xác định [11]:
Công cụ: Các công cụ được sử dụng để phát triển hệ thống có thể
vụng về, không đáng tin cậy hoặc bị lỗi.
Đầu vào: Nó có thể không đầy đủ, không rõ ràng hoặc bị lỗi.
Phương pháp: Các phương pháp có thể không đầy đủ, không rõ
ràng, sai hoặc không được thực thi.
Con người: Họ có thể không được đào tạo hoặc hiểu biết đầy đủ.
Chúng ta cần động não để thu thập nguyên nhân cụ thể và gắn
nguyên nhân cụ thể với nguyên nhân chung chung phù hợp. Tầm
quan trọng của các nguyên nhân được xác định sẽ được thảo luận sau
khi tất cả các ý kiến đã được khám phá, tập trung vào các nguyên
nhân chính góp phần gây ra sai số hệ thống. Thường thì điều này
được tìm thấy trong cụm nguyên nhân dày đặc hơn trong sơ đồ. Sơ
đồ nguyên nhân - kết quả cung cấp một cách tập trung để giải quyết
vấn đề.
(v) Làm thế nào để ngăn chặn lỗi trong tương lai? Các hành động
nhằm ngăn ngừa, khắc phục hoặc giảm thiểu, được thực hiện sau khi
đã xác định được nguyên nhân chính gây ra lỗi hệ thống:
Tools Input
Brainstorm
Problem
Discuss
Effect
Methods People
Causes
Hình 13.5 Sơ đồ nguyên nhân - ảnh hưởng cho DCA.

Phòng ngừa: Một hành động phòng ngừa làm giảm nguy cơ xảy ra
các vấn đề tương tự trong tương lai. Ý tưởng là phát hiện một vấn đề
sớm hơn và sửa chữa nó.
Khắc phục: Một hành động khắc phục có nghĩa là sửa chữa các vấn
đề. Bản thân việc tấn công nguyên nhân có thể không hiệu quả trong
mọi tình huống.
601
Giảm nhẹ: Một hành động giảm nhẹ cố gắng chống lại những hậu
quả bất lợi của vấn đề. Các hành động giảm thiểu là một phần của
hoạt động quản lý rủi ro [20].
Có thể áp dụng kết hợp các hành động phòng ngừa, khắc phục và
giảm thiểu, tùy thuộc vào chi phí thực hiện các hành động và mức độ
của các triệu chứng quan sát được. Một kế hoạch hành động toàn
diện được tạo ra để thúc đẩy việc ngăn ngừa hoặc phát hiện các lỗi hệ
thống sớm nhất có thể trong quá trình phát triển phần mềm. Sau đây
là những câu hỏi điển hình cần đặt ra vào thời điểm này để đưa ra các
khuyến nghị:
Lỗi sớm nhất có thể được nhận ra là gì?
Những triệu chứng nào cho thấy khuyết tật có thể xảy ra một lần
nữa?
Chúng ta cần biết những gì để tránh những khiếm khuyết?
Làm thế nào chúng ta có thể làm mọi thứ khác nhau?
Các hành động được đề xuất cần phải cụ thể và chính xác để những
người khác có thể làm theo. Một số ví dụ phổ biến về các hành động
phòng ngừa và khắc phục như sau:
Đào tạo: Điều này cho phép mọi người nâng cao kiến thức của họ về
sản phẩm. Việc đào tạo có thể bao gồm các hành động cụ thể như tổ
chức một chuỗi hội thảo về các thành phần của sản phẩm, chuẩn bị
bài viết kỹ thuật về một khía cạnh phức tạp của sản phẩm và viết một
bài báo về các lỗi lặp lại.
13.7 KIỂM TRA BETA
Cải tiến trong giao tiếp: Đây là những hành động nhằm cải thiện
các thủ tục giao tiếp trong các tổ chức sản phẩm. Người ta có thể
nghĩ đến việc thông báo cho các lập trình viên và người kiểm tra qua
email khi đặc điểm kỹ thuật giao diện thay đổi. Tổ chức các cuộc họp
nhóm hàng tuần giúp làm rõ và phổ biến thông tin hữu ích.
Sử dụng Công cụ: Các hành động được thực hiện để phát triển các
công cụ mới hoặc nâng cao các công cụ hiện có hỗ trợ các quy trình.
Người ta có thể phát triển hoặc mua một công cụ để kiểm tra việc sử
dụng bộ nhớ hoặc thêm một số liệu phạm vi mới vào công cụ bao
phủ mô-đun.
Cải tiến Quy trình: Đây là những hành động cải tiến các quy trình
hiện có và xác định các quy trình mới. Những hành động như vậy có
thể sửa đổi quá trình thay đổi thiết kế hoặc thêm các mục mới vào
danh sách lỗi phổ biến.
13.7 KIỂM TRA BETA
Thử nghiệm beta được thực hiện bởi những người mua tiềm năng
trước khi phát hành chính thức sản phẩm. Mục đích của thử nghiệm
beta không phải để tìm ra khuyết tật mà là để thu thập thông tin phản
hồi từ hiện trường về khả năng sử dụng của sản phẩm. Có ba loại thử
nghiệm beta được thực hiện dựa trên mối quan hệ giữa người mua
tiềm năng và người bán:
Tiếp thị Beta: Mục đích ở đây là xây dựng nhận thức sớm và quan
tâm đến sản phẩm của những người mua tiềm năng.
Beta kỹ thuật: Mục tiêu ở đây là thu thập phản hồi về khả năng sử
dụng của sản phẩm trong môi trường thực với các cấu hình khác
nhau từ một số ít khách hàng thân thiện. Ý tưởng là thu thập phản hồi
từ một số ít khách hàng, những người cam kết dành nhiều thời gian
và suy nghĩ cho việc đánh giá của họ.
chấp nhận: Ý tưởng của thử nghiệm này là để đảm bảo rằng sản
phẩm đáp ứng các tiêu chí chấp nhận của nó. Đó là việc thực hiện
hợp đồng giữa người mua và người bán. Hệ thống được phát hành
cho một người mua cụ thể, người có thỏa thuận theo hợp đồng của
nhà sản xuất thiết bị gốc (OEM) với nhà cung cấp. Bản beta chấp
nhận cũng bao gồm mục tiêu của bản beta kỹ thuật. Thử nghiệm chấp
nhận được thảo luận trong Chương 14.
Các khiếm khuyết và tiến độ thực hiện kiểm thử cung cấp thông tin
hữu ích về chất lượng của hệ thống. Chất lượng của hệ thống đang
được phát triển là một mục tiêu di động trong quá trình thực thi thử
nghiệm. Quyết định về thời điểm phát hành hệ thống cho khách hàng
beta được đưa ra bởi các thành viên trong nhóm dự án phần mềm.
Hậu quả của việc phát hành sớm và chậm trễ như sau:
Nếu nó được phát hành quá sớm, quá nhiều lỗi trong hệ thống có thể
có tác động tiêu cực đến khách hàng tiềm năng và nó có thể tạo ra dư
luận xấu cho cả sản phẩm và công ty.
Nếu việc phát hành bị trì hoãn, các đối thủ cạnh tranh khác có thể
chiếm được thị trường.
Các tiêu chí phát hành beta do nhóm dự án thiết lập và các tiêu chí
này ít nghiêm ngặt hơn các tiêu chí chu kỳ kiểm tra hệ thống cuối
603
cùng được đưa ra trong Chương 13. Một khuôn khổ để viết các tiêu
chí phát hành beta được đưa ra trong Bảng 13.13. Tất cả các tiêu chí
phát hành beta trong Bảng 13.13 là tự giải thích, ngoại trừ mục cuối
cùng, cụ thể là tất cả các lỗi của trình chặn beta được xác định đều ở
trạng thái đóng. Các khiếm khuyết của trình chặn beta là tập hợp các
khiếm khuyết phải ở trạng thái đóng trước khi phần mềm được xem
xét để thử nghiệm beta. Ba tuần trước khi phát hành bản beta, các lỗi
của trình chặn beta được xác định tại cuộc họp dự án chức năng chéo.
Các khiếm khuyết này được theo dõi hàng ngày để đảm bảo rằng các
khiếm khuyết được giải quyết và đóng trước khi phát hành bản beta.
Trong khi chờ đợi, khi các khiếm khuyết mới được gửi đi, những
khiếm khuyết này được đánh giá để xác định xem đây có phải là
thuốc chẹn beta hay không. Nếu người ta kết luận rằng một khiếm
khuyết mới là một chất chẹn beta, thì lỗi đó sẽ được đưa vào danh
sách các thuốc chẹn beta và tất cả các khiếm khuyết sẽ được theo dõi
để đóng lại.
Chu kỳ thử nghiệm hệ thống tiếp tục đồng thời với thử nghiệm beta.
Các cuộc họp hàng tuần được thực hiện với khách hàng beta bởi
nhóm hỗ trợ beta, bao gồm các thành viên nhóm chức năng chéo của
dự án. Báo cáo trạng thái thử nghiệm hàng tuần từ khách hàng beta
được phân tích và các hành động được thực hiện để giải quyết vấn đề
bằng cách sửa chữa các lỗi hoặc cung cấp cho họ một giải pháp thay
thế cho các vấn đề mà khách hàng beta đưa ra. Nếu khách hàng beta
quyết định triển khai hệ thống, có thể đạt được thỏa thuận cung cấp
các bản vá lỗi bằng cách khắc phục mọi thiếu sót còn tồn đọng trong
hệ thống theo một khung thời gian nhất định. Chu kỳ thử nghiệm
cuối cùng với số lượng trường hợp thử nghiệm được thu nhỏ được
thực hiện như một bộ thử nghiệm hồi quy sau khi đạt được thỏa
thuận và sản phẩm được chuẩn bị cho chuyến hàng đầu tiên của
khách hàng (FCS).
BẢNG 13.13 Khung cho tiêu chí phát hành bản Beta
Chín mươi tám phần trăm tất cả các trường hợp thử nghiệm đã vượt
qua.
Hệ thống đã không gặp sự cố trong tuần trước của tất cả các thử
nghiệm.
Tất cả các khuyết tật được giải quyết phải ở trạng thái đóng.
Một ghi chú phát hành với tất cả các lỗi vẫn còn ở trạng thái mở cùng
với giải pháp thay thế phải có sẵn. Nếu cách giải quyết không tồn tại,
thì giải thích về tác động đối với khách hàng phải được đưa vào ghi
chú phát hành.
Không có khiếm khuyết nào có mức độ nghiêm trọng “tới hạn” ở
trạng thái mở.
Không có khiếm khuyết nào có mức độ nghiêm trọng "cao" có xác
suất xảy ra trên trang web của khách hàng lớn hơn 0,1.
Sản phẩm không có nhiều hơn một số khuyết tật nhất định với mức
độ nghiêm trọng “trung bình”. Số lượng có thể được xác định bởi các
thành viên trong nhóm dự án phần mềm.
Tất cả các trường hợp thử nghiệm để kiểm tra hiệu suất phải được
thực thi và kết quả phải được cung cấp cho khách hàng thử nghiệm
beta.
Kế hoạch thử nghiệm beta phải có sẵn từ tất cả các khách hàng beta
tiềm năng. Kế hoạch thử nghiệm beta không phải là cái gì khác ngoài
kế hoạch thử nghiệm chấp nhận của người dùng.
Bản thảo của hướng dẫn sử dụng phải có sẵn.
Các tài liệu đào tạo trên hệ thống có sẵn cho các kỹ sư hiện trường.
Nhóm hỗ trợ beta phải sẵn sàng cho các cuộc họp hàng tuần với từng
khách hàng beta.
Tất cả các lỗi của trình chẹn beta được xác định đều ở trạng thái
đóng.
13.8 VẬN CHUYỂN KHÁCH HÀNG ĐẦU TIÊN

13.8 CHUYỂN HÀNG CHO KHÁCH HÀNG ĐẦU TIÊN
Tiêu chí thoát ra của chu kỳ thử nghiệm cuối cùng phải được thỏa
mãn trước FCS được thiết lập trong phần chiến lược thực hiện thử
nghiệm của Chương 13. Cuộc họp đánh giá mức độ sẵn sàng của
FCS được tổ chức để đảm bảo rằng sản phẩm đáp ứng các tiêu chí
vận chuyển. Tiêu chí về lô hàng không chỉ là tiêu chí xuất cảnh của
chu kỳ thử nghiệm cuối cùng. Đánh giá này nên bao gồm các đại
diện từ các nhóm chức năng chính chịu trách nhiệm phân phối và hỗ
trợ sản phẩm, chẳng hạn như kỹ thuật, vận hành, chất lượng, hỗ trợ
khách hàng và tiếp thị sản phẩm. Một tập hợp các tiêu chí chung về
mức độ sẵn sàng của FCS như sau:
605
Tất cả các trường hợp thử nghiệm từ bộ thử nghiệm phải được thực
thi. Nếu bất kỳ trường hợp thử nghiệm nào không được thực thi, thì
giải thích cho việc không thực thi trường hợp thử nghiệm phải được
cung cấp trong cơ sở dữ liệu của nhà máy thử nghiệm.
Kết quả trường hợp thử nghiệm được cập nhật trong cơ sở dữ liệu
của nhà máy thử nghiệm với trạng thái đạt, không thành công, bị
chặn hoặc không hợp lệ. Thông thường, điều này được thực hiện
trong các chu kỳ kiểm tra hệ thống.
Cơ sở dữ liệu yêu cầu được cập nhật bằng cách chuyển từng yêu cầu
từ trạng thái xác minh sang trạng thái đóng hoặc trạng thái từ chối,
như đã thảo luận trong Chương 11, để có thể tạo thống kê tuân thủ từ
cơ sở dữ liệu. Tất cả các vấn đề liên quan đến EC phải được giải
quyết với nhóm phát triển.
Tỷ lệ vượt qua các trường hợp kiểm tra là rất cao, 98%.
Không có vụ tai nạn nào được ghi nhận trong hai tuần thử nghiệm
vừa qua.
Không có khuyết tật nào đã biết với mức độ nghiêm trọng hoặc
nghiêm trọng cao tồn tại trong sản phẩm.
Không có nhiều hơn một số khuyết tật nhất định đã biết với mức độ
nghiêm trọng trung bình và thấp tồn tại trong sản phẩm. Số ngưỡng
có thể được xác định bởi các thành viên trong nhóm dự án phần
mềm.
Tất cả các lỗi bộ chặn FCS được xác định đều ở trạng thái đóng.
Tất cả các khuyết tật được giải quyết phải ở trạng thái đóng.
Tất cả các lỗi còn tồn tại vẫn ở trạng thái mở hoặc được chỉ định đều
được bao gồm trong ghi chú phát hành cùng với cách giải quyết, nếu
có.
Các hướng dẫn sử dụng được đưa ra.
Hướng dẫn khắc phục sự cố có sẵn. • Báo cáo thử nghiệm được hoàn
thành và được phê duyệt. Chi tiết của một báo cáo thử nghiệm được
giải thích trong phần sau.
Một lần nữa, ba tuần trước FCS, các khiếm khuyết của trình chặn
FCS được xác định tại cuộc họp dự án chức năng chéo. Các khiếm
khuyết này được theo dõi hàng ngày để đảm bảo rằng các khiếm
khuyết được giải quyết và đóng cửa trước FCS. Trong thời gian chờ
đợi, khi các khiếm khuyết mới được gửi đi, chúng được đánh giá để
xác định xem đây có phải là chất chặn FCS hay không. Nếu kết luận
rằng một khiếm khuyết là một trình chặn, thì khiếm khuyết đó sẽ
được đưa vào danh sách trình chặn và được theo dõi cùng với các
khiếm khuyết khác trong danh sách để đóng nó.
13.9 BÁO CÁO THỬ NGHIỆM HỆ THỐNG
Trong các chu kỳ thực hiện thử nghiệm, báo cáo thử nghiệm được
tạo và phân phối như đã thảo luận trong Phần 13.4.2 và 13.4.4. Báo
cáo tóm tắt cuối cùng được tạo sau khi hoàn thành tất cả các chu kỳ
thử nghiệm. Cấu trúc của báo cáo cuối cùng được nêu trong Bảng
13.14.
Phần giới thiệu về phần dự án thử nghiệm của báo cáo thử nghiệm
tóm tắt mục đích của báo cáo theo kế hoạch thử nghiệm. Phần này
bao gồm các thông tin sau:
Tên dự án
Tên của hình ảnh phần mềm
Lịch sử sửa đổi của tài liệu này
Thuật ngữ và định nghĩa
Nhân viên kiểm tra
Phạm vi của tài liệu
Người giới thiệu
Phần tóm tắt kết quả thử nghiệm tóm tắt kết quả thử nghiệm cho từng
loại thử nghiệm được xác định trong kế hoạch thử nghiệm. Trong
mỗi chu kỳ kiểm thử, kết quả kiểm thử được tổng hợp dưới dạng số
lượng các trường hợp thử nghiệm đạt, không đạt, không hợp lệ, bị
chặn, không được kiểm tra và lý do không thực hiện được một số
trường hợp kiểm thử. Một trường hợp thử nghiệm có thể không được
thử nghiệm vì một số lý do, chẳng hạn như không có thiết bị và khó
khăn trong việc tạo kịch bản thử nghiệm bằng cách sử dụng thiết lập
giường thử nghiệm có sẵn. Sau này chỉ có thể thực hiện được tại một
trang web thử nghiệm beta thực sự. Đối với mỗi chu kỳ thử nghiệm,
dữ liệu sau được cung cấp trong phần này:
Ngày bắt đầu và ngày hoàn thành
Số lượng khuyết tật được nộp
Số lượng khuyết tật ở các trạng thái khác nhau, chẳng hạn như không
thể sản xuất, FAD, đã đóng, bị xếp dỡ, trùng lặp, bị hoãn, được chỉ
định và đang mở
607
BẢNG 13.14 Cấu trúc của Báo cáo Kiểm tra Hệ thống Cuối
cùng
Giới thiệu về dự án thử nghiệm

Tóm tắt kết quả kiểm tra
Đặc điểm hiệu suất
Các giới hạn về tỷ lệ
Quan sát độ ổn định
Khả năng tương tác của hệ thống
Ma trận tương thích phần cứng / phần mềm
Tình trạng yêu cầu tuân thủ
13.10 BỀN VỮNG SẢN PHẨM

Các vấn đề vẫn còn tồn tại trong hệ thống, bao gồm bất kỳ thiếu sót
hoặc khả năng thất bại nào, được tóm tắt trong phần này về mức độ
nghiêm trọng và tác động tiềm tàng của chúng đối với khách hàng.
Ví dụ, nếu mật khẩu không phân biệt chữ hoa chữ thường, thì nó nên
được ghi như vậy. Một ví dụ khác, nếu một hệ điều hành đặt giới hạn
20 cửa sổ có thể mở đồng thời, thì người dùng không nên mở nhiều
hơn 20 cửa sổ đồng thời; vượt quá giới hạn có thể gây ra sự cố hệ
thống.
Trong phần đặc tính hiệu suất của tài liệu, thời gian phản hồi của hệ
thống, thông lượng, sử dụng tài nguyên và kết quả đo độ trễ được mô
tả cùng với các môi trường thử nghiệm và công cụ được sử dụng
trong quá trình đo.
Các giới hạn của hệ thống được nêu trong phần giới hạn tỷ lệ của tài
liệu dựa trên các kết quả kiểm tra khả năng mở rộng. Một lần nữa,
các phương tiện và công cụ được sử dụng trong kiểm tra quy mô
được mô tả ở đây.
Phần quan sát độ ổn định nêu các thông tin sau:
Thời gian hoạt động theo số giờ của hệ thống
Số lượng sự cố được quan sát bởi các nhóm khác nhau, chẳng hạn
như nhà phát triển phần mềm, ST và SIT, trong mỗi tuần của chu kỳ
thử nghiệm
Mô tả các triệu chứng của các lỗi gây ra sự cố hệ thống ở trạng thái
không thể sửa chữa
Chúng tôi nêu rõ trong phần khả năng tương tác của tài liệu đó là các
hệ thống phần mềm và phần cứng của bên thứ ba mà các bài kiểm tra
khả năng tương tác của hệ thống đã được tiến hành. Danh sách có thể
bao gồm phần mềm và phần cứng mà hệ thống sẽ không tương tác
với nhau.
Một bảng hiển thị phiên bản phần mềm nào tương thích với những
phiên bản phần cứng nào trong phần ma trận tương thích phần cứng /
phần mềm. Việc tạo ra bảng này dựa trên các loại hệ thống phần
cứng khác nhau và các phiên bản phần mềm khác nhau được sử dụng
trong các chu kỳ kiểm tra hệ thống.
Cuối cùng, trong phần trạng thái yêu cầu tuân thủ của tài liệu thống
kê sự tuân thủ được tóm tắt bằng cách tạo chúng từ cơ sở dữ liệu yêu
cầu. Các báo cáo sau được tạo bằng cách tạo các truy vấn thích hợp
trên cơ sở dữ liệu:
Các yêu cầu tuân thủ, tuân thủ một phần hoặc không tuân thủ hình
ảnh phần mềm
Các yêu cầu được xác minh bằng thử nghiệm, phân tích, chứng minh
và kiểm tra
Các yêu cầu được đề cập trong từng trường hợp thử nghiệm của bộ
thử nghiệm cùng với trạng thái của trường hợp thử nghiệm
13.10 BỀN VỮNG SẢN PHẨM
Sau khi sản phẩm được chuyển đến một trong những khách hàng trả
tiền và nếu không có vấn đề lớn nào được khách hàng báo cáo trong
khung thời gian, chẳng hạn như ba tuần, thì tính khả dụng chung của
sản phẩm (GA) sẽ được công bố. Sau đó, dự án phần mềm được
chuyển sang một giai đoạn mới được gọi là giai đoạn duy trì. Mục
tiêu của giai đoạn này là duy trì chất lượng phần mềm trong suốt
vòng đời thị trường của sản phẩm. Các hoạt động bảo trì phần mềm
xảy ra bởi vì kiểm thử phần mềm không thể phát hiện ra tất cả các
khiếm khuyết trong một hệ thống phần mềm lớn. Ba hoạt động bảo
trì phần mềm sau đây do Swanson đặt ra [21]:
Khắc phục: Quá trình bao gồm cách ly và sửa chữa một hoặc nhiều
khiếm khuyết trong phần mềm.
Thích ứng: Quá trình sửa đổi phần mềm để giao diện phù hợp với
môi trường thay đổi, chẳng hạn như phiên bản phần cứng mới hoặc
phần mềm của bên thứ ba.
609
Hoàn thiện: Quá trình cải thiện phần mềm bằng cách bổ sung các
chức năng mới, cải tiến và / hoặc sửa đổi các chức năng hiện có.
Nhiệm vụ chính đầu tiên là xác định loại nhiệm vụ bảo trì sẽ được
tiến hành khi một báo cáo lỗi đến từ người dùng thông qua nhóm hỗ
trợ khách hàng. Nhóm duy trì, bao gồm các nhà phát triển và người
kiểm tra, được chỉ định ngay lập tức để khắc phục lỗi nếu lỗi được
khách hàng báo cáo được coi là sửa chữa về bản chất. Tình trạng của
tiến độ được cập nhật cho khách hàng trong vòng 24 giờ. Nhóm tiếp
tục làm việc cho đến khi một bản vá với bản sửa lỗi được phát hành
cho khách hàng. Nếu lỗi được báo cáo được coi là thích ứng hoặc
hoàn thiện về bản chất, thì nó được nhập vào cơ sở dữ liệu yêu cầu và
nó sẽ diễn ra theo các giai đoạn phát triển phần mềm thông thường.
Các kỹ sư kiểm tra duy trì khác với các kỹ sư kiểm tra hệ thống. Do
đó, trước khi quá trình chuyển đổi sản phẩm xảy ra, các kỹ sư duy trì
được cung cấp đủ khóa đào tạo về sản phẩm để thực hiện các hoạt
động thử nghiệm duy trì. Trên thực tế, các kỹ sư kiểm tra được luân
chuyển qua lại giữa nhóm kiểm tra hệ thống và nhóm duy trì. Các
nhiệm vụ chính của các kỹ sư thử nghiệm duy trì như sau:
Tương tác với khách hàng để hiểu môi trường thực tế của họ
Tái hiện các vấn đề mà khách hàng quan sát được trong môi trường
phòng thí nghiệm
Sau khi biết nguyên nhân gốc rễ của sự cố, hãy phát triển các trường
hợp thử nghiệm mới để xác minh nó • Phát triển các trường hợp thử
nghiệm nâng cấp / hạ cấp từ hình ảnh cũ sang hình ảnh bản vá mới
Tham gia vào quá trình xem xét mã
Chọn một tập hợp con các bài kiểm tra hồi quy từ nhóm các trường
hợp kiểm tra hiện có để đảm bảo rằng không có tác dụng phụ do bản
sửa lỗi
Thực thi các trường hợp thử nghiệm đã chọn
Xem lại ghi chú phát hành để biết tính đúng đắn
Tiến hành thử nghiệm để đánh giá hiệu quả thử nghiệm
13.11 ĐO LƯỜNG HIỆU QUẢ KIỂM TRA
Sẽ rất hữu ích khi đánh giá hiệu quả của nỗ lực thử nghiệm trong quá
trình phát triển sản phẩm. Sau khi một sản phẩm được triển khai
trong môi trường khách hàng, thước đo phổ biến để đánh giá hiệu
quả kiểm tra là số lượng lỗi mà khách hàng tìm thấy mà các kỹ sư
kiểm tra không tìm thấy trước khi phát hành sản phẩm. Những khiếm
khuyết này đã thoát khỏi nỗ lực thử nghiệm của chúng tôi. Một số
liệu thường được sử dụng trong ngành để đo lường hiệu quả kiểm tra
là hiệu quả loại bỏ khuyết tật (DRE) [22], được định nghĩa là
số lượng khuyết tật được tìm thấy trong thử nghiệm
DRE =
+
số lượng khuyết tật được tìm thấy trong thử nghiệm số lượng
khuyết tật không được tìm thấy
Chúng tôi thu được số lượng lỗi được tìm thấy trong quá trình thử
nghiệm từ hệ thống theo dõi lỗi. Tuy nhiên, việc tính toán số lượng
khuyết tật không được tìm thấy trong quá trình thử nghiệm là một
nhiệm vụ khó khăn. Một cách để ước tính con số này là đếm các lỗi
do khách hàng tìm thấy trong vòng sáu tháng đầu tiên kể từ khi hoạt
động. Có một số vấn đề cần được hiểu để diễn giải biện pháp DRE
theo cách hữu ích:
Do những hạn chế cố hữu của môi trường thử nghiệm thực tế trong
phòng thí nghiệm, rất khó tìm thấy một số lỗi nhất định trong quá
trình thử nghiệm hệ thống cho dù chúng tôi có kỹ lưỡng đến đâu
trong cách tiếp cận của mình. Người ta nên đưa những khiếm khuyết
này vào tính toán nếu mục tiêu là đo lường hiệu quả của nỗ lực thử
nghiệm bao gồm cả những hạn chế của môi trường thử nghiệm. Nếu
không, các loại khuyết tật này có thể bị loại khỏi tính toán.
Các khuyết tật do khách hàng gửi cần được bảo dưỡng sửa chữa
được xem xét trong phép đo này. Các lỗi được gửi cần bảo trì thích
ứng hoặc hoàn hảo không phải là vấn đề thực sự trong phần mềm;
thay vào đó chúng là những yêu cầu cải tiến tính năng mới. Do đó,
các khuyết tật cần bảo dưỡng thích ứng và hoàn thiện có thể được
loại bỏ khỏi tính toán.
Phải có hiểu biết rõ ràng về khoảng thời gian mà các lỗi được tính,
chẳng hạn như bắt đầu từ thử nghiệm đơn vị hoặc thử nghiệm tích
hợp hệ thống cho đến khi kết thúc thử nghiệm hệ thống. Một phải
nhất quán cho tất cả các dự án thử nghiệm. • Phép đo này không dành
cho một dự án; thay vào đó nó phải là một phần của xu hướng dài
hạn trong hiệu quả kiểm tra của tổ chức.
611
Nhiều công việc đã được thực hiện trên phương pháp gieo hạt lỗi
[23] để ước tính số lượng khuyết tật thoát ra. Theo cách tiếp cận này,
hiệu quả của việc kiểm tra được xác định bằng cách ước tính số
lượng khuyết tật thực tế bằng kỹ thuật ngoại suy. Cách tiếp cận là
đưa một số lượng nhỏ các khiếm khuyết đại diện vào hệ thống và đo
lường tỷ lệ phần trăm các khiếm khuyết được phát hiện bởi các kỹ sư
kiểm tra duy trì. Vì nhóm kiểm tra duy trì vẫn không biết về việc
gieo hạt, nên mức độ sản phẩm bộc lộ các khuyết tật đã biết cho phép
chúng tôi ngoại suy mức độ mà nó phát hiện ra các khuyết tật chưa
biết. Giả sử rằng sản phẩm chứa N khuyết tật và K khuyết tật được
gieo hạt. Khi kết thúc các thí nghiệm kiểm tra, nhóm kiểm tra duy trì
đã tìm thấy n khuyết tật không hạt và k có hạt. Lý thuyết gieo mầm
lỗi khẳng định những điều sau:
Ví dụ, hãy xem xét một tình huống mà 25 khuyết tật đã biết đã được
cố tình gieo vào một hệ thống. Chúng ta hãy giả định rằng những
người kiểm tra duy trì phát hiện 20 (80%) các khuyết tật được gieo
hạt này và phát hiện ra 400 khuyết tật bổ sung. Khi đó, tổng số
khuyết tật ước tính trong hệ thống là 500. Do đó, sản phẩm vẫn còn
500 - 400 = 100 khuyết tật đang chờ được phát hiện cộng với 5
khuyết tật hạt giống vẫn còn tồn tại trong mã. Sử dụng kết quả từ thử
nghiệm gieo hạt, có thể thu được tổng số lỗi đã thoát khỏi giai đoạn
thử nghiệm hệ thống. Ước tính này dựa trên giả định rằng tỷ lệ giữa
số khuyết tật được tìm thấy trên tổng số khuyết tật là 0,80 - tỷ lệ
tương tự như đối với các khuyết tật được gieo hạt. Nói cách khác,
chúng tôi giả định rằng 400 lỗi chiếm 80% tổng số lỗi được tìm thấy
bởi các kỹ sư kiểm tra bền vững trong hệ thống. Số lượng khiếm
khuyết ước tính còn lại vẫn còn ẩn trong hệ thống. Tuy nhiên, độ
chính xác của phép đo phụ thuộc vào cách tiêm các khuyết tật. Thông
thường, các khuyết tật được tiêm nhân tạo được trồng thủ công,
nhưng nó đã được chứng minh là khó thực hiện gieo hạt khuyết tật
trong thực tế. Không dễ để đưa ra các khuyết tật nhân tạo có thể có
tác động tương tự như các khuyết tật thực tế về mức độ khó phát
hiện. Nói chung, các khuyết tật nhân tạo dễ tìm thấy hơn nhiều so với
các khuyết tật thực tế.
Số liệu hư hỏng Các khiếm khuyết được đưa vào và loại bỏ ở các
giai đoạn khác nhau của chu kỳ phát triển phần mềm [24]. Các khiếm
khuyết được đưa ra trong giai đoạn phân tích yêu cầu, thiết kế cấp
cao, thiết kế chi tiết và mã hóa, trong khi những khiếm khuyết này
được loại bỏ trong giai đoạn thử nghiệm đơn vị, thử nghiệm tích hợp,
thử nghiệm hệ thống và giai đoạn thử nghiệm chấp nhận. Chi phí của
mỗi khuyết tật được tiêm vào trong giai đoạn X và loại bỏ trong giai
đoạn Y không được phân phối đồng nhất; thay vào đó chi phí tăng
lên khi khoảng cách giữa X và Y tăng lên . Sự chậm trễ trong việc
tìm kiếm các khuyết tật không hoạt động gây ra những tác hại lớn
hơn và việc sửa chữa sẽ tốn nhiều chi phí hơn vì các khuyết tật không
hoạt động có thể kích hoạt việc tiêm các khuyết tật liên quan khác,
cần được sửa chữa ngoài các khuyết tật không hoạt động ban đầu. Do
đó, một phương pháp kiểm tra hiệu quả sẽ phát hiện ra các khuyết tật
sớm hơn một phương pháp kiểm tra kém hiệu quả hơn. Do đó, một
thước đo hữu ích để đánh giá hiệu quả của thử nghiệm là tuổi lỗi,
được gọi là PhAge. Để làm ví dụ, chúng ta hãy xem xét Bảng 13.15,
cho thấy một thang đo độ tuổi. Trong ví dụ này, một khiếm khuyết
yêu cầu được phát hiện trong quá trình xem xét thiết kế cấp cao sẽ
được chỉ định PhAge là 1, trong khi một khiếm khuyết yêu cầu được
phát hiện ở giai đoạn thử nghiệm chấp nhận sẽ được chỉ định PhAge
là 7. Người ta có thể sửa đổi bảng để phù hợp với các giai đoạn khác
nhau của vòng đời phát triển phần mềm theo sau trong một tổ chức,
bao gồm cả số PhAge.
Nếu thông tin về giai đoạn giới thiệu khiếm khuyết có thể được xác
định, nó có thể được sử dụng để tạo một ma trận với các hàng tương
ứng với khiếm khuyết được đưa vào trong mỗi giai đoạn và các cột
tương ứng với các khuyết tật được phát hiện trong mỗi giai đoạn này
thường được gọi là mô hình động khuyết tật. Bảng 13.16 cho thấy
một ma trận được phát hiện được chèn vào – v từ một dự án thử
nghiệm tưởng tượng được gọi là Boomerang. Trong ví dụ này, có
BẢNG 13.15 Thang điểm cho độ tuổi khiếm khuyết
Giai đoạn được khám phá
Cao-
Giai đoạn Mức độ Chi Đơn vị Chấp nhận hệ thống
613
tiết tích hợp
Tiêm Yêu cầu thiết Thiết Kiểm tra Thử Thử Thử
kế kế mã hóa nghiệmnghiệm nghiệm
Yêu cầu 0 12 3 4 5 6 7
Thiết kế 0 1 2 3 4 5 6
cao cấp
Thiết kế 0 1 2 3 4 5
chi tiết
Mã hóa 0 1 2 3 4
BẢNG 13.16 Tiêm khuyết điểm so với Khám phá trên Project
Boomerang
Cao-
phaDet Chi tiếtUnitIntegration System AcceptanceTotal
tiêm Thiết kếDesignCoding TestingTestingTestingTestingDefects
Yêu cầu 0 7 3 1 0 0 2 4 17
Thiết kế cao 0 số 8 4 1 2 6 1 22
cấp
Thiết kế chi 0 13 3 4 5 0 25
tiết
Mã hóa 0 63 24 37 12 136
Bản tóm tắt 0 7 11 18 67 30 50 17 200
bảy khiếm khuyết yêu cầu được tìm thấy trong thiết kế cấp cao, ba
trong thiết kế chi tiết, một trong mã hóa, hai trong thử nghiệm hệ
thống và bốn trong giai đoạn thử nghiệm chấp nhận.
Giờ đây, một số liệu mới được gọi là độ hư hỏng [25, 26] được xác
định để đo lường các hoạt động loại bỏ khuyết tật bằng cách sử dụng
mô hình động độ tuổi và độ tuổi khuyết tật. Chỉ số hư hỏng được tính
như
( số lỗi phát hiện PhAge )
Sự hư hỏng = ×
tổng số khuyết tật
Bảng 13.17 cho thấy các giá trị hư hỏng đối với dự án thử nghiệm
Boomerang dựa trên số lượng khuyết tật được tìm thấy (Bảng 13.15)
được tính theo tuổi khuyết tật (Bảng 13.16). Ví dụ, trong quá trình
kiểm tra nghiệm thu, 17 lỗi đã được phát hiện, trong đó 4 lỗi được
cho là do các lỗi được đưa vào trong giai đoạn yêu cầu của dự án
Boomerang. Vì các khuyết tật được tìm thấy trong quá trình kiểm tra
chấp nhận có thể được tìm thấy trong bất kỳ giai đoạn nào trong số
bảy giai đoạn trước đó, các khuyết tật yêu cầu không hoạt động cho
đến khi kiểm tra chấp nhận được cấp PhAge là 7. Số khuyết tật yêu
cầu được phát hiện trong quá trình kiểm tra chấp nhận là 28 , nghĩa
là, 7 × 4 = 28. Các giá trị hư hỏng cho các yêu cầu, thiết kế cấp cao,
thiết kế chi tiết và giai đoạn mã hóa là 3 . 2 , 2 . 8 , 2 . 0 và 1 . 98,
tương ứng. Giá trị hư hỏng cho dự án thử nghiệm Boomerang là 2 . 2.
Giá trị hư hỏng gần bằng 1 là dấu hiệu của
TABLE13.17NumberofDefectsWeightedbyDefectAgeonProjectBoomerang
PhaseDiscovered
Spoilageas
Phase High-LevelDetailed UnitIntegrationSystemAcceptance TotalWeight/Total
Injected RequirementsDesignDesignCodingTestingTestingTestingTestingWeightDefectsDefects
Requiremants 0 7 6300122856173.294117647
High-leveldesign 0 883830663222.863636364
Detaileddesign 01361220051252.04
Coding 06348111482701361.985294118
Summary 0 714247268173824402002.2
14.2 TIÊU CHÍ CHẤP NHẬN
615
616 CHƯƠNG 14 KIỂM TRA CHẤP NHẬN
444
13.12 TÓM TẮT
một quá trình phát hiện khiếm khuyết hiệu quả hơn. Là một giá trị
tuyệt đối, chỉ số hư hỏng có rất ít ý nghĩa. Số liệu này hữu ích trong
việc đo lường xu hướng dài hạn của hiệu quả kiểm tra trong một tổ
chức.
13.12 TÓM TẮT
Chương này bắt đầu với một mô hình chuyển đổi trạng thái cho phép
chúng ta biểu diễn từng giai đoạn trong vòng đời của khuyết tật theo
một trạng thái. Tại mỗi trạng thái của mô hình chuyển đổi, chủ sở
hữu thực hiện một số hành động nhất định; khiếm khuyết được
chuyển sang trạng thái mới sau khi hoàn thành các hành động. Chúng
tôi đã trình bày một lược đồ lỗi có thể được sử dụng để theo dõi các
số liệu lỗi khác nhau. Hai khái niệm chính liên quan đến các khuyết
tật mô hình là mức độ ưu tiên và mức độ nghiêm trọng. Một mặt,
mức độ ưu tiên là thước đo mức độ khẩn cấp của một khiếm khuyết
cần được sửa chữa. Mặt khác, mức độ nghiêm trọng là thước đo mức
độ ảnh hưởng bất lợi của khuyết tật đối với hoạt động của sản phẩm.
Sau đó, chúng tôi khám phá ý tưởng về sự sẵn sàng kiểm tra để bắt
đầu kiểm tra cấp hệ thống. Chúng tôi đã thảo luận về ý tưởng về một
tài liệu làm việc thực thi kiểm tra cần được duy trì trước khi bắt đầu
thực hiện kiểm tra hệ thống để đảm bảo rằng các kỹ sư kiểm tra hệ
thống sẵn sàng bắt đầu thực hiện kiểm tra hệ thống. Chúng tôi
khuyên bạn nên theo dõi hai loại chỉ số trong quá trình thực hiện các
trường hợp kiểm tra cấp hệ thống:
Các chỉ số để giám sát việc thực hiện kiểm tra
Các chỉ số để giám sát các khuyết tật
Loại số liệu đầu tiên liên quan đến quá trình thực hiện các trường
hợp thử nghiệm, trong khi loại số liệu thứ hai liên quan đến các
khiếm khuyết được tìm thấy do kết quả của việc thực thi thử nghiệm.
Chúng tôi đã cung cấp các ví dụ về việc thực thi trường hợp thử
nghiệm và các chỉ số báo cáo lỗi từ các dự án thử nghiệm thực tế
khác nhau.
Tiếp theo, chúng tôi kiểm tra ba loại kỹ thuật phân tích khiếm
khuyết: ODC, nhân quả và phương pháp Pareto. Phân tích nguyên
14.2 TIÊU CHÍ CHẤP NHẬN 617
nhân được thực hiện để xác định nguyên nhân gốc rễ của các khuyết
tật và thực hiện các hành động để loại bỏ các nguồn gốc của khuyết
tật; điều này được thực hiện tại thời điểm sửa chữa các khuyết tật.
Trong phương pháp ODC, việc đánh giá không được thực hiện đối
với các khuyết tật riêng lẻ; thay vào đó, các xu hướng và mẫu trong
dữ liệu tổng hợp được nghiên cứu. Nguyên tắc Pareto dựa trên định
đề rằng 80% vấn đề có thể được khắc phục với 20% nỗ lực. Chúng
tôi đã chỉ ra rằng ODC cùng với việc áp dụng phân tích Pareto có thể
đưa ra dấu hiệu tốt về những phần nào của hệ thống dễ bị lỗi và có
thể yêu cầu thử nghiệm nhiều hơn.
Chúng tôi đã cung cấp các khuôn khổ cho các bản phát hành beta và
thảo luận về quá trình thử nghiệm beta như được tiến hành tại trang
web của khách hàng. Chúng tôi đã phân loại ba loại thử nghiệm beta:
beta tiếp thị, beta kỹ thuật và beta chấp nhận. Mục đích của tiếp thị
beta là xây dựng nhận thức sớm và quan tâm đến sản phẩm của
những người mua tiềm năng. Thử nghiệm beta kỹ thuật được thực
hiện để thu thập phản hồi về khả năng sử dụng của sản phẩm trong
môi trường thực tế với các cấu hình khác nhau. Ý tưởng là thu thập
phản hồi từ một số lượng hạn chế người dùng cam kết dành nhiều
thời gian và suy nghĩ cho việc đánh giá của họ. Thử nghiệm beta
chấp nhận được thực hiện để
đảm bảo rằng sản phẩm có thể chấp nhận được, tức là sản phẩm đáp
ứng các tiêu chí chấp nhận của nó. Nghiệm thu là việc thực hiện hợp
đồng giữa người mua và người bán.
Tiếp theo, chúng tôi cung cấp cấu trúc chi tiết của báo cáo thử
nghiệm hệ thống, báo cáo này phải được tạo trước khi công bố tính
khả dụng chung của sản phẩm. Khi sản phẩm được tuyên bố là có sẵn
thông thường, dự án phần mềm được chuyển sang một giai đoạn mới
được gọi là giai đoạn duy trì để bảo trì. Trong giai đoạn này, các kỹ
sư thử nghiệm duy trì chịu trách nhiệm thực hiện các hoạt động thử
nghiệm duy trì. Chúng tôi đã giải thích các nhiệm vụ của việc duy trì
các kỹ sư thử nghiệm trong chương này.
Cuối cùng, chúng tôi cung cấp hai số liệu được sử dụng để đo hiệu
quả kiểm tra: hiệu quả loại bỏ khuyết tật và hư hỏng. Mục tiêu của
thước đo hiệu quả thử nghiệm là đánh giá hiệu quả của nỗ lực thử
nghiệm hệ thống trong quá trình phát triển sản phẩm, tức là số lỗi đã
thoát khỏi nỗ lực thử nghiệm của chúng tôi. Chúng tôi đã trình bày
phương pháp gieo hạt lỗi để ước tính số lượng khuyết tật đã thoát ra.
Trong tài liệu tham khảo [4], một tập hợp các số liệu trong quá trình
cho các giai đoạn thử nghiệm của quá trình phát triển phần mềm
được mô tả. Đối với mỗi số liệu, các tác giả mô tả mục đích, dữ liệu,
diễn giải và sử dụng của nó và trình bày các ví dụ đồ họa với dữ liệu
thực tế. Các số liệu này có thể áp dụng cho hầu hết các dự án phần
mềm và là một phần không thể thiếu của kiểm thử cấp hệ thống.
Trong tài liệu tham khảo [8], ba nghiên cứu điển hình được trình bày
để đo lường hiệu quả kiểm tra bằng cách sử dụng ODC. Cả ba nghiên
cứu điển hình đều nêu bật cách các nhóm kỹ thuật có thể sử dụng dữ
liệu ODC để có phản hồi khách quan về quy trình phát triển và sự
phát triển của sản phẩm. Các nghiên cứu điển hình bao gồm thông tin
cơ bản về sản phẩm, cách thức thực hiện quy trình ODC của họ và
chi tiết của các đánh giá, bao gồm cả các hành động đã dẫn đến kết
quả.
Một số ví dụ xuất sắc về nỗ lực RCA khiếm khuyết trong kỹ thuật
phần mềm đã được xuất bản. Bạn đọc quan tâm vui lòng xem qua các
bài viết sau để biết thêm thông tin:
M. Leszak, DE Perry, và D. Stoll, “Phân loại và đánh giá khiếm
khuyết trong hồi cứu,” Tạp chí Hệ thống và Phần mềm, Vol. 61,
WD Yu, “Phương pháp tiếp cận phòng chống phần mềm trong phân
tích nguyên nhân gốc và mã hóa,” Tạp chí kỹ thuật Bell Labs, Vol. 3,
Bài báo của Leszak et al. mô tả quy trình hồi cứu với RCA khiếm
khuyết, phân tích số liệu quy trình và phân tích độ phức tạp phần
mềm của một phần tử mạng như một phần của mạng truyền dẫn
quang tại Lucent Technologies (nay là Alcatel-Lucent). Bài viết của
Yu thảo luận về các hướng dẫn do nhóm phát triển để tiến hành RCA
khiếm khuyết tại các tổ chức phát triển chuyển mạch Lucent khác
nhau.

26. RB Grady và DL Caswell. Số liệu phần mềm: Thiết lập một
chương trình toàn công ty. Prentice-Hall, Upper Saddle River, NJ,
1998.
Bài tập
Tại sao việc gán cả mức độ nghiêm trọng và mức độ ưu tiên cho một
khiếm khuyết lại quan trọng?
Triển khai lược đồ và mô hình lỗi được thảo luận trong chương này
bằng cách sử dụng công cụ theo dõi lỗi có sẵn trên thị trường thương
mại (viz., ClearQuest của IBM).
Tại sao các chỉ số trong quá trình cần được theo dõi hàng ngày hoặc
hàng tuần trong quá trình kiểm tra hệ thống?
Sự khác biệt giữa phân tích nhân quả, phân tích thống kê và
Paretoanalysis là gì? Phương pháp ODC thuộc loại nào?
Sửa đổi lược đồ được hiển thị trong Bảng 13.2, bao gồm các giá trị
của các trường và sơ đồ chuyển trạng thái trong Hình 13.1, để lập mô
hình ODC.
Số lỗi dự kiến được gửi, giải quyết và còn mở trong bốn tuần đầu
tiên của một dự án thử nghiệm được đưa ra ở nửa trên của Bảng
13.18. Số lượng thực tế của các khiếm khuyết đã gửi và đã giải quyết
được hiển thị ở nửa dưới của bảng. Tính số khuyết tật hở thực tế.
Đối với dự án thử nghiệm hệ thống hiện tại của bạn, hãy chọn một
tập hợp các số liệu trong quá trình được thảo luận trong chương này
và theo dõi nó trong giai đoạn thực hiện kiểm tra hệ thống.
Phát triển một bộ tiêu chí phát hành beta cho dự án thử nghiệm hiện
tại của bạn.
Viết báo cáo thử nghiệm hệ thống sau khi hoàn thành dự án thử
nghiệm hiện tại của bạn.
Trong một dự án thử nghiệm, số lượng khiếm khuyết được tìm thấy
trong các giai đoạn khác nhau của các khu vực thử nghiệm như sau:
thử nghiệm đơn vị, 163 khiếm khuyết; kiểm tra tích hợp, 186 lỗi;
kiểm tra hệ thống, 271 lỗi. Số lượng khuyết tật được tìm thấy bởi các
kỹ sư kiểm tra duy trì bằng cách tiến hành thử nghiệm gieo hạt lỗi là
57. Giá trị của DRE là gì? Tính giá trị của DRE kiểm tra hệ thống?
BẢNG 13.18 Chỉ số ARD cho dự án thử nghiệm
Đã đệ trình Đã giải quyết Op

en
P1 + P2 P1 + P2
Tổn Tổn P1 P P
P3
To g g + 3 4
We Xây t P P cộn P cộn P2
e k dựng al 3 4 g 4 g
Dự kiến 6 7
184 50 3 1
1 xây 75 24 3 1 118 38 60 2 141 36 3 6
dựng1 6 5 0 9 6
0
2 xây 75 24 3 1 118 38 60 2 98 22 1 6
dựng1 6 5 0 5 1
1
3 xây 75 24 3 1 95 38 37 2 78 số 1 5
dựng1 6 5 0 8 4 6
2
4 xây 14 5 7 2 20 10 5 5 72 3 1 5
dựng1 Thật sự 6 3
3
1 xây 60 26 1 1 105 35 40 3
dựng1 6 8 0
0
2 xây 77 28 3 1 89 37 37 1
dựng1 4 5 5
1
3 xây 62 20 3 1 78 24 42 1
dựng1 2 0 2
2
4 xây 24 15 1 1 72 20 25 2
dựng1 5 0 7
3
BẢNG 13.19 Thang đo cho PhAge

Giai Cấp độ Chi Đơn vị Hội Hệ chấp
đoạn cao tiết nhập thống thuận
Tiêm Yêu cầu Thiết Thiết Mã Thử Thử Thử Thử
kế kế hóa nghiệm nghiệm nghiệm nghiệm
Yêu cầu 0 1 2 4 6 số 8 10 14
kiến
Thiết kế 0 1 2 4 6 số 8 12
cao cấp
Thiết kế 0 1 2 4 6 10
chi tiết
Mã hóa 0 1 2 4 số 8
Sửa đổi lược đồ được hiển thị trong Bảng 13.2, bao gồm các giá trị
của các trường cần lấy trong mô hình động khuyết tật.
Sử dụng độ tuổi khuyết tật (PhAge) cho trong Bảng 13.19 để tính
toán lại độ hư hỏng cho dự án thử nghiệm Boomerang.
CHAPTER
14
AcceptanceTesting
Sự chấp nhận của người khác, ngoại hình, hành vi của họ, niềm tin
của họ, mang lại cho bạn sự yên bình và tĩnh lặng bên trong — thay
vì tức giận và oán giận.
-Vô danh
14.1 CÁC LOẠI KIỂM TRA CHẤP NHẬN
Một sản phẩm sẵn sàng được giao cho khách hàng sau khi nhóm
kiểm tra hệ thống hài lòng với sản phẩm bằng cách thực hiện các
kiểm tra cấp hệ thống. Khách hàng thực hiện kiểm tra nghiệm thu
dựa trên kỳ vọng của họ từ sản phẩm. Các dịch vụ được cung cấp bởi
một sản phẩm phần mềm có thể được sử dụng bởi hàng triệu người
dùng. Ví dụ, nhà cung cấp dịch vụ của mạng điện thoại di động là
khách hàng của hệ thống phần mềm chạy mạng điện thoại, trong khi
công chúng nói chung hình thành cơ sở người dùng bằng cách đăng
ký các dịch vụ điện thoại. Không có gì lạ khi một người nào đó có
hai vai trò là khách hàng và người dùng. Nhà cung cấp dịch vụ cần
đảm bảo rằng sản phẩm đáp ứng các tiêu chí nhất định trước khi nhà
cung cấp cung cấp dịch vụ cho công chúng. Thử nghiệm chấp nhận
là một thử nghiệm chính thức được thực hiện để xác định xem một
hệ thống có đáp ứng các tiêu chí chấp nhận hay không — các tiêu chí
mà hệ thống phải đáp ứng để được khách hàng chấp nhận. Nó giúp
khách hàng xác định có chấp nhận hệ thống hay không [1]. Khách
hàng thường có quyền từ chối nhận sản phẩm nếu các trường hợp
kiểm tra nghiệm thu không đạt. Có hai loại kiểm thử chấp nhận:
Kiểm tra sự chấp nhận của người dùng.
Kiểm tra chấp nhận kinh doanh.
UAT được thực hiện bởi khách hàng để đảm bảo rằng hệ thống đáp
ứng các tiêu chí chấp nhận hợp đồng trước khi được ký kết để đáp
ứng nhu cầu của người dùng. Việc lập kế hoạch thực tế và thực hiện
các bài kiểm tra nghiệm thu không phải do khách hàng trực tiếp thực
hiện. Thường thì các công ty tư vấn của bên thứ ba cung cấp dịch vụ
của họ để thực hiện nhiệm vụ này. Tuy nhiên, khách hàng phải nêu
rõ các tiêu chí chấp nhận để bên thứ ba tìm kiếm trong sản phẩm.
BAT được thực hiện trong tổ chức phát triển
450
của nhà cung cấp để đảm bảo rằng cuối cùng hệ thống sẽ vượt qua
UAT. Đây là một cuộc diễn tập của UAT tại cơ sở của nhà cung cấp.
Tổ chức phát triển của nhà cung cấp bắt nguồn và thực hiện các
trường hợp thử nghiệm từ hợp đồng của khách hàng, bao gồm các
tiêu chí chấp nhận.
Các tiêu chí chấp nhận phải được xác định và thống nhất giữa nhà
cung cấp và khách hàng để tránh bất kỳ loại tranh luận kéo dài nào.
Một trong hai bên hoặc công ty tư vấn của bên thứ ba có thể thiết kế
kế hoạch nghiệm thu. Tài liệu tiêu chí chấp nhận là một phần của hợp
đồng trong trường hợp phát triển thuê ngoài theo thỏa thuận OEM.
Nếu một số phần cứng là một phần không thể thiếu của hệ thống, thì
tiêu chí chấp nhận phần cứng được bao gồm trong thỏa thuận hợp
đồng. Nói chung, tổ chức tiếp thị của người mua xác định các tiêu chí
chấp nhận. Tuy nhiên, điều quan trọng là nhóm đảm bảo chất lượng
phần mềm của tổ chức của người mua phải bắt đầu đối thoại với
người bán và cung cấp một bộ tiêu chí chấp nhận “người đàn ông
rơm” để bộ phận tiếp thị xem xét và phản ứng. Người dùng, kỹ sư hệ
thống, kỹ sư hỗ trợ khách hàng và nhóm đảm bảo chất lượng phần
mềm của tổ chức của người mua lập kế hoạch thực tế và thực hiện
các bài kiểm tra chấp nhận sau khi các tiêu chí được thống nhất.
Nhân sự xây dựng kế hoạch nghiệm thu phải hiểu biết thấu đáo về
các tiêu chí nghiệm thu đã được thống nhất. Không có khả năng hệ
thống vượt qua tất cả các tiêu chí chấp nhận trong một lần đối với các
hệ thống lớn, phức tạp. Sẽ rất hữu ích nếu tập trung vào ba mục tiêu
chính sau đây của thử nghiệm chấp nhận vì những lý do thực tế:
Xác nhận rằng hệ thống đáp ứng các tiêu chí đã thỏa thuận. Các loại
tiêu chí rộng được giải thích trong Phần 14.2.
Xác định và giải quyết các chênh lệch, nếu có. Nguồn gốc của sự
khác biệt và cơ chế giải quyết chúng đã được giải thích trong Phần
14.5.
Xác định mức độ sẵn sàng của hệ thống đối với các hoạt động trực
tiếp. Việc chấp nhận cuối cùng của một hệ thống để triển khai phụ
thuộc vào kết quả của thử nghiệm chấp nhận. Nhóm nghiệm thu lập
biên bản nghiệm thu trong đó nêu các điều kiện nghiệm thu. Các chi
tiết của báo cáo nghiệm thu đã được giải thích trong Phần 14.6.
Thử nghiệm chấp nhận chỉ là một khía cạnh của việc hoàn thành hợp
đồng của thỏa thuận giữa nhà cung cấp và người mua. Thỏa thuận
hợp đồng có thể yêu cầu người bán cung cấp các tài liệu khác, chẳng
hạn như tài liệu giải pháp thiết kế đề cập đến tài liệu yêu cầu của
người mua. Nhóm kiểm tra chấp nhận có thể đánh giá khả năng chấp
nhận của thiết kế hệ thống về giao diện người dùng đồ họa, xử lý lỗi
và kiểm soát truy cập.
14.2 TIÊU CHÍ CHẤP NHẬN
Cốt lõi của bất kỳ thỏa thuận hợp đồng nào là một tập hợp các tiêu
chí chấp nhận. Một câu hỏi quan trọng là hệ thống phải đáp ứng
những tiêu chí nào để có thể được chấp nhận? Các tiêu chí chấp nhận
phải có thể đo lường được và tốt nhất là có thể định lượng được.
Nguyên tắc cơ bản của việc thiết kế các tiêu chí chấp nhận là đảm
bảo rằng chất lượng của hệ thống có thể chấp nhận được. Người ta
phải hiểu ý nghĩa của chất lượng của một hệ thống, đây là một khái
niệm phức tạp. Nó có nghĩa là những điều khác nhau đối với những
người khác nhau, và nó phụ thuộc nhiều vào ngữ cảnh [2].
Mặc dù những người khác nhau có thể có quan điểm khác nhau về
chất lượng, nhưng ý kiến của khách hàng sẽ chiếm ưu thế. Trên thực
tế, khái niệm chất lượng rất phức tạp và đa nghĩa [3]. Năm quan điểm
về chất lượng, cụ thể là chế độ xem siêu nghiệm, chế độ xem người
dùng, chế độ xem sản xuất, chế độ xem sản phẩm và chế độ xem dựa
trên giá trị, đã được giải thích trong Chương 17. Năm quan điểm ban
đầu được Garvin trình bày [3] trong bối cảnh sản xuất và chế tạo nói
chung và sau đó được giải thích bởi Kitchenham và Pfleeger [2]
trong bối cảnh phát triển phần mềm. Năm quan điểm được trình bày
dưới đây dưới dạng ngắn gọn:
Quan điểm siêu việt coi chất lượng là thứ có thể được công nhận
nhưng rất khó để mô tả hoặc định nghĩa.
Chế độ xem của người dùng coi chất lượng là thỏa mãn mục đích.
Quan điểm sản xuất coi chất lượng là phù hợp với đặc điểm kỹ thuật.
Quan điểm về sản phẩm gắn chất lượng với các đặc tính vốn có của
sản phẩm.
Quan điểm dựa trên giá trị đặt con số chi phí vào chất lượng — số
tiền khách hàng sẵn sàng trả cho nó.
Tiêu chí chấp nhận được xác định trên cơ sở nhiều khía cạnh này của
các thuộc tính chất lượng. Các thuộc tính này xác định sự hiện diện
hay không có chất lượng trong một hệ thống. Người mua hoặc Khách
hàng nên suy nghĩ về mức độ liên quan và tầm quan trọng tương đối
của các thuộc tính này trong tình huống duy nhất của chúng tại thời
điểm xây dựng tiêu chí chấp nhận. Các thuộc tính của chất lượng
được thảo luận dưới đây và đưa ra các ví dụ về tiêu chí chấp nhận
cho từng thuộc tính chất lượng.
Tính đúng đắn và đầy đủ của chức năng Người ta có thể đặt câu
hỏi: Hệ thống có làm những gì chúng ta muốn nó làm không? Tất cả
các tính năng được mô tả trong đặc tả yêu cầu phải có trong hệ thống
được phân phối. Điều quan trọng là phải chứng minh rằng hệ thống
hoạt động chính xác trong ít nhất hai đến ba điều kiện cho mỗi tính
năng như một phần của việc chấp nhận.
Người ta có thể chỉ ra tính đúng đắn về chức năng của một hệ thống
bằng cách sử dụng cơ sở dữ liệu yêu cầu, như đã thảo luận trong
Chương 11. Cơ sở dữ liệu được sử dụng để tạo ma trận xác định
nguồn gốc yêu cầu trong quá trình thử nghiệm cấp hệ thống. Về cơ
bản, ma trận truy xuất nguồn gốc cho chúng ta biết các trường hợp
thử nghiệm được sử dụng để xác minh một yêu cầu và tất cả các yêu
cầu được xác minh một phần bởi một trường hợp thử nghiệm. Ma
trận truy xuất nguồn gốc như vậy là một công cụ mạnh mẽ để cho
khách hàng thấy về tính đúng đắn của hệ thống. Điều quan trọng là
phải nhận được phản hồi sớm từ khách hàng về ma trận xác định
nguồn gốc các yêu cầu. Ý tưởng đằng sau phản hồi là đạt được thỏa
thuận về phương pháp xác nhận được sử dụng cho từng yêu cầu.
Quyết định này đặc biệt quan trọng vì một số phương pháp xác nhận
dễ thực hiện hơn và tốn ít thời gian hơn các phương pháp khác. Ví
dụ, phương pháp trình diễn tốn ít thời gian hơn phương pháp thử
nghiệm.
Trong thực tế, kiểm tra tính đúng đắn của chức năng nghiêm ngặt
được tiến hành trong giai đoạn kiểm tra hệ thống, thay vì trong quá
trình kiểm tra chấp nhận. Tuy nhiên, người mua có thể yêu cầu ma
trận xác định nguồn gốc yêu cầu trước khi bắt đầu thử nghiệm chấp
nhận để đảm bảo rằng hệ thống hoạt động theo đặc điểm kỹ thuật yêu
cầu.
Độ chính xác Câu hỏi đặt ra là: Hệ thống có cung cấp kết quả chính
xác không? Độ chính xác đo lường mức độ mà một giá trị được tính
toán vẫn gần với giá trị mong đợi. Độ chính xác thường được định
nghĩa theo mức độ của sai số. Một khoảng cách nhỏ — còn được gọi
là sai số trong phân tích số, chẳng hạn — giữa giá trị thực tế được hệ
thống tính toán và giá trị kỳ vọng thường được chấp nhận trong một
không gian liên tục. Vấn đề độ chính xác là khác nhau trong không
gian rời rạc, dẫn đến kết quả dương tính giả và âm tính giả. Kết quả
dương tính giả và âm tính giả là những nhược điểm nghiêm trọng
trong bất kỳ công cụ phần mềm chẩn đoán và giám sát nào.
Tính toàn vẹn của dữ liệu Tính toàn vẹn của dữ liệu đề cập đến
việc bảo toàn dữ liệu trong khi nó được truyền hoặc lưu trữ sao cho
giá trị của dữ liệu không thay đổi khi các hoạt động nhận hoặc truy
xuất tương ứng được thực hiện sau đó. Do đó, dữ liệu không được
xâm phạm khi thực hiện các thao tác cập nhật, khôi phục, truy xuất,
truyền và nhận. Yêu cầu về tính toàn vẹn của dữ liệu được đưa vào
tiêu chí kiểm tra chấp nhận để phát hiện ra các sai sót thiết kế có thể
dẫn đến hỏng dữ liệu. Trong các hệ thống thông tin liên lạc, kẻ xâm
nhập có thể thay đổi dữ liệu mà người gửi và người nhận không phát
hiện ra sự thay đổi đó. Nếu có cơ chế kiểm tra tính toàn vẹn, dữ liệu
có thể bị thay đổi, nhưng cơ chế này sẽ phát hiện ra sự giả mạo. Cơ
chế toàn vẹn dữ liệu phát hiện những thay đổi trong tập dữ liệu. Các
khái niệm về phân tích thông điệp và chữ ký số được sử dụng để bảo
toàn tính toàn vẹn của dữ liệu [4].
Nhận xét. Một thuật toán thông báo thông báo nhận vào một thông
điệp đầu vào có độ dài tùy ý và tạo ra một mã có độ dài cố định. Mã
có độ dài cố định được gọi là bản tóm tắt của thư gốc. Các thuật toán
thông báo thông báo thường được sử dụng là Thông báo 5 (MD5) và
Thuật toán băm an toàn 1 và 2 (SHA-1 và SHA-2).
Nhận xét. Chữ ký điện tử là một bản tóm tắt thông điệp được mã hóa
được nối vào tài liệu để lưu trữ hoặc truyền đi. Thông báo tóm tắt có
được bằng cách sử dụng, ví dụ: thuật toán MD5, SHA-1 hoặc SHA-
2. Thông báo thông báo tin nhắn được mã hóa bằng khóa riêng của
bên lưu trữ hoặc truyền tin nhắn.
liệu Chuyển đổi dữ liệu là việc chuyển đổi một dạng dữ liệu máy
tính sang một dạng dữ liệu máy tính khác. Ví dụ: chuyển đổi tệp từ
một phiên bản Microsoft Word sang phiên bản cũ hơn vì lợi ích của
những người chưa cài đặt phiên bản Word mới nhất. Kiểm tra chuyển
đổi dữ liệu là kiểm tra các chương trình hoặc thủ tục được sử dụng để
chuyển đổi dữ liệu từ các hệ thống hiện có để sử dụng trong các hệ
thống thay thế. Dữ liệu có thể được chuyển đổi thành một định dạng
không hợp lệ mà hệ thống mới không thể xử lý nếu điều này không
được thực hiện đúng cách; do đó dữ liệu sẽ không có giá trị.
Ngoài ra, dữ liệu có thể bị bỏ sót trong quá trình chuyển đổi dẫn đến
lỗ hổng hoặc lỗi hệ thống trong hệ thống mới. Không có khả năng xử
lý các tệp sao lưu hoặc lưu trữ dẫn đến không thể khôi phục hoặc
thẩm vấn dữ liệu cũ.
Một tiêu chí chấp nhận cho các biện pháp chuyển đổi dữ liệu và báo
cáo khả năng của phần mềm để chuyển đổi dữ liệu ứng dụng hiện có
sang các định dạng mới. Các câu hỏi sau phải được trả lời khi chỉ
định tiêu chí chấp nhận chuyển đổi dữ liệu:
Làm cách nào để chúng tôi có thể hoàn tác một chuyển đổi và quay
trở lại (các) phiên bản cơ sở dữ liệu trước đó nếu cần?
Cần bao nhiêu sự tham gia của con người để xác thực kết quả chuyển
đổi?
Dữ liệu hiện tại đang được sử dụng như thế nào và dữ liệu được
chuyển đổi sẽ được sử dụng như thế nào?
Liệu phần mềm chuyển đổi dữ liệu có tiến hành kiểm tra tính toàn
vẹn không?
Sao lưu và phục hồi Sao lưu và phục hồi dữ liệu là chức năng mặc
định của các hệ thống lớn, phức tạp. Điều này là do, mặc dù các hệ
thống dự kiến sẽ không gặp sự cố, nhưng trên thực tế, sự cố hệ thống
không phải là hiếm. Các tiêu chí chấp nhận sao lưu và phục hồi chỉ
định độ bền và mức độ khôi phục của phần mềm trong mỗi nền tảng
phần cứng. Mục đích của tiêu chí kiểm tra chấp nhận khôi phục là
phác thảo mức độ dữ liệu có thể được khôi phục sau sự cố hệ thống.
Các câu hỏi sau phải được trả lời trong việc xác định các tiêu chí
chấp nhận khả năng phục hồi:
Bao nhiêu dữ liệu có thể được khôi phục sau sự cố và làm thế nào?
Dữ liệu được phục hồi có nhất quán không?
Nói chung, hệ thống không thể phục hồi sau sự cố trừ khi dữ liệu đã
được sao lưu trước đó. Quá trình sao lưu bao gồm chụp ảnh nhanh
định kỳ về trạng thái của hệ thống và lưu chúng vào bộ nhớ ổn định
để truy xuất sau [5]. Các câu hỏi sau phải được trả lời trong việc chỉ
định các tiêu chí chấp nhận sao lưu:
Tần suất bắt đầu quá trình sao lưu là bao nhiêu?
Quá trình sao lưu mất bao lâu?
Bản sao lưu dự kiến sẽ hoạt động trực tuyến hay ngoại tuyến với hoạt
động bình thường bị tạm dừng trong quá trình sao lưu? • Quá trình
sao lưu có kiểm tra xem có đủ dung lượng lưu trữ để chứa tất cả dữ
liệu không?
Quá trình sao lưu có hoàn toàn tự động không?
Cạnh tranh Hệ thống phải cung cấp lợi thế khác biệt so với các
phương pháp hiện có và các sản phẩm cạnh tranh thông qua các tính
năng cải tiến. Một bản phân tích về khả năng cạnh tranh của sản
phẩm được cung cấp cho người mua. Tài liệu này chứa một nghiên
cứu so sánh về hệ thống với các sản phẩm có sẵn trên thị trường từ
các nhà cung cấp khác. Một phân tích cạnh tranh được thực hiện bởi
nhóm kỹ thuật hệ thống của tổ chức tiếp thị. Các câu hỏi sau cần
được trả lời trong việc xác định các tiêu chí chấp nhận báo cáo phân
tích cạnh tranh:
Các đối thủ cạnh tranh trực tiếp gần nhất của sản phẩm là gì?
Đối thủ cạnh tranh gián tiếp của sản phẩm là gì?
Đối thủ cạnh tranh tiềm năng là ai?
Hoạt động kinh doanh trong lĩnh vực sản phẩm có ổn định, tăng
trưởng hay giảm sút?
Có thể học được gì từ hoạt động sản phẩm hoặc từ quảng cáo của đối
thủ cạnh tranh?
Điểm mạnh và điểm yếu của đối thủ cạnh tranh là gì?
Làm thế nào để sản phẩm của họ khác với sản phẩm đang được phát
triển?
Khả năng sử dụng Câu hỏi đặt ra là: Hệ thống dễ sử dụng như thế
nào và nó có dễ học không? Mục tiêu của tiêu chí chấp nhận khả
năng sử dụng là đảm bảo rằng hệ thống linh hoạt, dễ dàng cấu hình
và tùy chỉnh hệ thống, trợ giúp trực tuyến có sẵn, khả dụng làm việc
xung quanh và giao diện sử dụng thân thiện. Các câu hỏi sau đây cần
được giải quyết trong việc xác định các tiêu chí chấp nhận khả năng
sử dụng:
Hệ thống sẽ giúp người dùng như thế nào trong công việc hàng
ngày?
Liệu năng suất, sự hài lòng của khách hàng, độ tin cậy và chất lượng
cuộc sống làm việc của người dùng có được cải thiện bằng cách sử
dụng hệ thống không?
Các menu, lệnh, màn hình và trợ giúp trực tuyến có rõ ràng với
người dùng thông thường không?
Các thủ tục người dùng có đơn giản, logic và rõ ràng đối với người
dùng thông thường không?
Hướng dẫn sử dụng có rõ ràng, dễ tiếp cận và dễ hiểu đối với người
dùng thông thường không?
Các phương pháp xử lý lỗi và ngoại lệ được hệ thống sử dụng có làm
tăng độ tin cậy và năng suất không?
Các báo cáo do hệ thống tạo ra có thứ tự, nhất quán và rõ ràng
không?
Hệ thống có dễ cài đặt không?
Hiệu suất Các đặc tính hiệu suất mong muốn của hệ thống phải được
xác định để dữ liệu đo được hữu ích. Các câu hỏi sau liên quan đến
đặc điểm kỹ thuật của các tiêu chí chấp nhận thực hiện:
Những loại đặc tính hiệu suất của hệ thống cần được đo lường?
Giá trị chấp nhận được cho mỗi thông số hiệu suất là bao nhiêu?
Ứng dụng tương tác với nguồn dữ liệu bên ngoài hoặc hệ thống nào?
• Loại khối lượng công việc nào nên được sử dụng trong khi chạy các
bài kiểm tra hiệu suất? Khối lượng công việc phải đại diện cho điều
kiện hoạt động có thể xảy ra trong thế giới thực về tải thấp, tải trung
bình và tải cao điểm.
Có cần phải thực hiện so sánh trước và sau kết quả hoạt động với
phiên bản trước của hệ thống không?
Thời gian khởi động Thời gian khởi động hệ thống phản ánh thời
gian khởi động để đi vào hoạt động. Các câu hỏi sau giải quyết các
tiêu chí chấp nhận khởi nghiệp:
Thời gian khởi động được xác định như thế nào?
Thời gian khởi động có bao gồm quá trình tự kiểm tra nguồn điện
của tất cả phần cứng hệ thống không?
Thời gian khởi động dài nhất có thể chấp nhận được là bao nhiêu?
Ứng suất Hệ thống phải có khả năng xử lý tải cực kỳ cao hoặc căng
thẳng. Cần phải xác định các hạn chế của hệ thống và sau đó nhấn
mạnh hệ thống để tìm ra kết quả khi hệ thống bị đẩy ra biên giới và
xa hơn. Giới hạn của hệ thống phải được xác định trong tiêu chí chấp
nhận. Các câu hỏi sau đây phải được giải quyết trong việc xác định
các tiêu chí chấp nhận ứng suất:
Các giới hạn thiết kế của hệ thống là gì?
Hành vi được mong đợi và chấp nhận được của cơ chế phục hồi là
gì?
Môi trường thử nghiệm nào, gần với kiến trúc triển khai của khách
hàng, là cần thiết để buộc hệ thống phải căng thẳng?
Độ tin cậy và tính khả dụng Độ tin cậy của phần mềm được định
nghĩa là xác suất mà phần mềm thực thi mà không bị lỗi trong một
khoảng thời gian cụ thể trong một môi trường cụ thể. Hệ thống chạy
càng lâu mà không bị lỗi thì hệ thống đó càng đáng tin cậy. Một số
lượng lớn các mô hình độ tin cậy có sẵn để dự đoán độ tin cậy của
phần mềm. Một mô hình độ tin cậy của phần mềm cung cấp một họ
các đường cong tăng trưởng mô tả sự suy giảm của tỷ lệ lỗi khi các
lỗi được gửi và đóng lại trong giai đoạn thử nghiệm hệ thống. Tỷ lệ
thất bại thường được tính theo MTBF. Mô hình tăng trưởng có thể trả
lời các câu hỏi sau, có thể là một phần của tiêu chí chấp nhận độ tin
cậy:
Tỷ lệ lỗi hiện tại của phần mềm là bao nhiêu?
Tỷ lệ thất bại sẽ là bao nhiêu nếu khách hàng tiếp tục thử nghiệm
chấp nhận trong một thời gian dài?
Có bao nhiêu lỗi có thể có trong phần mềm?
Bao nhiêu thử nghiệm phải được thực hiện để đạt được một tỷ lệ thất
bại cụ thể?
Mục tiêu tỷ lệ thất bại có thể chấp nhận được phải được đặt riêng cho
từng mức độ nghiêm trọng của vấn đề — từ nghiêm trọng đến thấp.
Một khách hàng có thể sẵn sàng chịu đựng hàng chục vấn đề mức độ
nghiêm trọng thấp mỗi ngày nhưng không quá một vấn đề nghiêm
trọng trong một năm.
Tính sẵn sàng của hệ thống bao gồm các phương pháp chủ động để
tối đa hóa thời gian hoạt động của dịch vụ, để giảm thiểu thời gian
ngừng hoạt động và giảm thiểu thời gian cần thiết để khôi phục sau
sự cố ngừng hoạt động. Thời gian ngừng hoạt động được đo bằng
MTTR. Việc tạo ra môi trường khách hàng được tạo điều kiện thuận
lợi bằng cách thu thập hồ sơ hoạt động từ khách hàng. Một hồ sơ
hoạt động mô tả các cách hệ thống được sử dụng. Người ta có thể
phát hiện ra một số khiếm khuyết trong hệ thống trong khi điều chỉnh
các thông số của hệ thống; điều chỉnh tham số sẽ cải thiện mức độ
sẵn sàng của hệ thống. Khách hàng phải sẵn sàng chia sẻ hồ sơ hoạt
động của môi trường máy tính của họ để cải thiện mức độ sẵn sàng
mục tiêu, đây có thể là thông tin độc quyền.
trì và Khả năng phục vụ Khả năng bảo trì của một hệ thống là khả
năng trải qua quá trình sửa chữa và phát triển của nó. Một cách để
mô tả đặc điểm của khả năng bảo trì là đo MTTR, phản ánh thời gian
cần thiết để phân tích một lỗi khắc phục, thiết kế một sửa đổi, thực
hiện thay đổi, kiểm tra và phân phối nó. Các yếu tố quan trọng, từ
quan điểm của khách hàng, là khả năng đáp ứng của dịch vụ hơn là
khả năng bảo trì kỹ thuật nội bộ của hệ thống. Sau đây là các tiêu chí
chấp nhận hữu ích từ quan điểm của khách hàng: • Khách hàng là
trọng tài cuối cùng trong việc đặt ra mức độ nghiêm trọng của một
vấn đề hệ thống. Nếu khách hàng gọi một vấn đề nghiêm trọng, nó
phải được khắc phục ngay lập tức. • Nếu một vấn đề hệ thống được
khách hàng đánh giá là nghiêm trọng, thì nhân viên phải được chỉ
định để giải quyết vấn đề đó ngay lập tức với mức độ ưu tiên cao
nhất.
Nếu mức độ nghiêm trọng của sự cố hệ thống được khách hàng đánh
giá là cao, thì nhân viên phải được chỉ định để giải quyết sự cố trong
giờ làm việc bình thường cho đến khi nó được giải quyết hoặc cho
đến khi một công việc được chuyển giao như một giải pháp tạm thời.
Các nhân viên chịu trách nhiệm giải quyết vấn đề phải đảm bảo rằng
có nỗ lực đáng kể được thực hiện để giải quyết vấn đề. Tuy nhiên, họ
có thể dành thời gian cho các hoạt động khác theo thứ tự ưu tiên.
Nếu sự cố hệ thống được khách hàng đánh giá là thấp, thì nhân viên
phải được chỉ định để giải quyết sự cố trong giờ làm việc bình
thường nếu thời gian cho phép. Nếu giải pháp sự cố liên quan đến
thay đổi phần mềm, thông thường sẽ đợi cho đến khi bản phát hành
phần mềm tiếp theo được triển khai để đưa ra giải pháp.
Tất cả các bản sửa lỗi nghiêm trọng và nghiêm trọng cao phải hoạt
động 100% khi được cài đặt.
Khả năng phục vụ liên quan chặt chẽ đến khả năng bảo trì của hệ
thống, được thiết kế để đảm bảo tính đúng đắn của các công cụ được
sử dụng để chẩn đoán và bảo dưỡng hệ thống. Ví dụ: phần mềm có
thể cần được bảo dưỡng từ xa thông qua kết nối Internet. Các tiện ích
chẩn đoán được sử dụng để theo dõi hoạt động và nguyên nhân của
bất kỳ sự cố nào. Các câu hỏi sau đây phải được giải quyết trong việc
xác định các tiêu chí chấp nhận khả năng sử dụng:
Những loại công cụ nào sẽ có sẵn để bảo dưỡng hệ thống?
Những công cụ này nên được sử dụng như thế nào?
Tính mạnh mẽ Tính mạnh mẽ của một hệ thống được định nghĩa là
khả năng phục hồi sau các lỗi, tiếp tục hoạt động trong điều kiện xấu
nhất và hoạt động đáng tin cậy trong một khoảng thời gian dài. Các
câu hỏi sau đây phải được giải quyết trong việc xác định các tiêu chí
chấp nhận độ chắc chắn:
Các loại lỗi mà hệ thống dự kiến sẽ khôi phục là gì?
Nguyên nhân hoặc nguồn gốc của các lỗi để chúng có thể được mô
phỏng trong môi trường thử nghiệm là gì?
Làm thế nào mà lỗi được bắt đầu hoặc được kích hoạt, trong thế giới
thực?
Những loại hành động sửa chữa và phục hồi nào được yêu cầu đối
với từng loại lỗi?
Những loại thảm họa nào có thể ập đến? Những tình huống đó là gì?
Phản ứng có thể chấp nhận được đối với từng tình huống đã xác định
này là gì?
Cơ chế khôi phục cho từng tình huống là gì? Nó có khả thi, được
hiểu và được chấp nhận không?
Làm thế nào có thể mô phỏng thảm họa để kiểm tra khả năng phục
hồi?
Thời gian đưa ra thị trường là một khía cạnh quan trọng của bất kỳ
thỏa thuận hợp đồng nào. Nhà cung cấp phải có khả năng cung cấp
hệ thống cho người mua trong khung thời gian đã thỏa thuận. Phần
thưởng và hình phạt gắn liền với các tiêu chí chấp nhận kịp thời như
sau:
Nếu việc viết mã được hoàn thành đúng thời hạn, người mua sẽ
thưởng thêm 5% tiền theo thỏa thuận trong hợp đồng.
Nếu hoàn thành kiểm tra cấp hệ thống đúng thời hạn, người mua sẽ
thưởng thêm 10% tiền theo thỏa thuận hợp đồng.
Đối với mỗi tuần chậm trễ trong việc hoàn thành các bài kiểm tra hệ
thống, nhà cung cấp phải trả khoản phạt 2% trên thỏa thuận hợp
đồng, với mức phạt tối đa là 20%.
Tính bảo mật và tính khả dụng Tiêu chí chấp nhận tính bảo mật
đáp ứng yêu cầu dữ liệu phải được bảo vệ khỏi tiết lộ trái phép và
tiêu chí chấp nhận tính khả dụng đối với yêu cầu dữ liệu phải được
bảo vệ khỏi sự từ chối dịch vụ (DoS) đối với người dùng được ủy
quyền. Các loại tiêu chí chấp nhận tính bảo mật và tính khả dụng
khác nhau như sau:
Không được phép truy cập trái phép vào hệ thống, nghĩa là xác thực
người dùng được thực hiện.
Các tệp và dữ liệu khác được bảo vệ khỏi sự truy cập trái phép.
Hệ thống được bảo vệ chống lại sự tấn công của virus, sâu và bot.
Các công cụ có sẵn để phát hiện các cuộc tấn công.
Có hỗ trợ chống lại cuộc tấn công DoS.
Quyền riêng tư trong giao tiếp đạt được bằng cách sử dụng mã hóa.
Tất cả dữ liệu khách hàng phải được lưu trữ ở một nơi an toàn theo
các chính sách về quyền của khách hàng, chẳng hạn như tính bảo
mật.
Nhận xét. Sâu được định nghĩa là một thành phần phần mềm có khả
năng lây nhiễm vào hệ thống máy tính theo cách tự động. Mặt khác,
một loại virus lây lan nhanh chóng đến một số lượng lớn máy tính.
Tuy nhiên, nó không thể làm như vậy với khả năng của chính nó; nó
lây lan bằng cách sử dụng sự hỗ trợ của một chương trình khác.
Nhận xét. Bot là một tác nhân phần mềm. Một bot tương tác với các
dịch vụ mạng khác dành cho mọi người như thể đó là một con người.
Một cách sử dụng điển hình của bot là thu thập thông tin. Một cách
sử dụng độc hại hơn đối với bot là điều phối và vận hành một cuộc
tấn công tự động trên các máy tính nối mạng, chẳng hạn như một
cuộc tấn công DoS phân tán.
Khả năng tương thích và khả năng tương tác Tính tương thích của
một hệ thống được định nghĩa là khả năng hoạt động theo cùng một
cách trên các nền tảng và cấu hình mạng khác nhau và với sự kết hợp
khác nhau của các ứng dụng khác. Mặt khác, khả năng tương tác của
một hệ thống được định nghĩa là khả năng giao tiếp với các phần tử
mạng khác và hoạt động chính xác như mong đợi. Thách thức chính
là xác định nền tảng, cấu hình và các ứng dụng khác mà hệ thống
tương thích. Các câu hỏi sau phải được giải quyết trong việc xác định
tiêu chí chấp nhận tính tương thích và khả năng tương tác:
Nền tảng hoặc cấu hình mà hệ thống phải hoạt động là gì?
Hệ thống có phải hoạt động theo cùng một cách trên các cấu hình
khác nhau không? Nếu không, các biến thể được chấp nhận là gì?
Các ứng dụng phải cùng tồn tại với hệ thống là gì?
Hệ thống phải tương tác với các phần tử mạng nào?
Tuân thủ Hệ thống phải tuân thủ các tiêu chuẩn kỹ thuật liên quan,
chẳng hạn như tiêu chuẩn IEEE, tiêu chuẩn giao diện hệ điều hành và
tiêu chuẩn IP. Ngoài ra, hệ thống phải tuân thủ các yêu cầu quy định
do các cơ quan bên ngoài thiết lập. Các câu hỏi sau đây phải được
giải quyết trong việc xác định các tiêu chí chấp nhận để tuân thủ:
Hệ thống cần tuân thủ những tiêu chuẩn kỹ thuật nào? Có bất kỳ
ngoại lệ nào đối với các tiêu chuẩn này không? Nếu có, hãy chỉ định
các trường hợp ngoại lệ.
Xác định các cơ quan quản lý phải chứng nhận hệ thống?
cài đặt và khả năng nâng cấp Mục đích của khả năng cài đặt và
nâng cấp hệ thống là để đảm bảo rằng hệ thống có thể được cài đặt và
nâng cấp một cách chính xác trong môi trường khách hàng. Nếu vì lý
do nào đó mà khách hàng muốn gỡ cài đặt hoặc hạ cấp phần mềm hệ
thống thì yêu cầu phải thực hiện một cách suôn sẻ. Việc cài đặt và
nâng cấp hệ thống được lên kế hoạch bằng cách xác định các mốc
quan trọng và các bước dự phòng. Tài liệu quy trình cài đặt và nâng
cấp hệ thống phải có sẵn với các bước cụ thể. Tiêu chí chấp nhận cài
đặt và nâng cấp hệ thống như sau:
Tài liệu phải xác định người cài đặt hệ thống, ví dụ, người dùng cuối
hoặc kỹ thuật viên được đào tạo từ phía nhà cung cấp.
Quá trình cài đặt hoặc nâng cấp dự kiến sẽ hoạt động trên phạm vi
nền tảng, cấu hình và phiên bản nào của phần mềm hỗ trợ? Các yêu
cầu phần cứng và phần mềm phải được giải thích rõ ràng trong tài
liệu.
Quá trình cài đặt hoặc nâng cấp có thể thay đổi môi trường hiện tại
của người dùng không? Nếu có, các rủi ro của sự thay đổi này cần
được ghi lại rõ ràng. • Quá trình cài đặt hoặc nâng cấp phải bao gồm
các bước chẩn đoán và sửa chữa được sử dụng trong trường hợp quá
trình không tiến triển như mong đợi.
Quá trình cài đặt hoặc nâng cấp phải chứa một quá trình gỡ cài đặt,
hạ cấp hoặc dự phòng có thể thực hiện được trong trường hợp một
quá trình cài đặt cụ thể không diễn ra như mong đợi.
Quá trình cài đặt hoặc nâng cấp phải hoạt động chính xác từ tất cả
các phương tiện phân phối khác nhau, chẳng hạn như tải xuống qua
Giao thức truyền tệp (FTP), CD-ROM và DVD.
Nếu hệ thống bao gồm quy trình cấp phép và đăng ký, nó sẽ hoạt
động trơn tru và phải được lập thành văn bản.
Hướng dẫn cài đặt hoặc nâng cấp phải đầy đủ, chính xác và có thể sử
dụng được.
Quá trình cài đặt hoặc nâng cấp phải được xác minh trong quá trình
kiểm tra hệ thống.
Không có lỗi nào còn tồn tại đối với quá trình cài đặt hoặc nâng cấp
hệ thống.
Khả năng mở rộng Khả năng mở rộng của một hệ thống được định
nghĩa là khả năng của nó để cung cấp hiệu suất có thể chấp nhận
được khi các số lượng sau đây tăng lên: (i) khu vực địa lý bao phủ
của hệ thống, (ii) quy mô hệ thống xét về số lượng phần tử trong hệ
thống, ( iii) số lượng người dùng, và (iv) khối lượng công việc trên
một đơn vị thời gian. Một hệ thống có thể hoạt động như mong đợi
trong các tình huống sử dụng hạn chế nhưng có thể không mở rộng
quy mô tốt lắm. Các câu hỏi sau phải được giải quyết trong việc xác
định các tiêu chí chấp nhận khả năng mở rộng:
Hệ thống dự kiến sẽ xử lý bao nhiêu người dùng đồng thời?
Hệ thống dự kiến sẽ xử lý bao nhiêu giao dịch trên một đơn vị thời
gian?
Hệ thống dự kiến sẽ hỗ trợ bao nhiêu bản ghi cơ sở dữ liệu?
Có bao nhiêu phần tử hoặc đối tượng phải được quản lý trong hoạt
động trực tiếp?
Khu vực địa lý lớn nhất mà hệ thống có thể bao phủ là gì?
14.4 KẾ HOẠCH KIỂM TRA CHẤP NHẬN
Tài liệu Chất lượng của tài liệu hướng dẫn sử dụng hệ thống phải
cao. Các tiêu chí chấp nhận tài liệu được xây dựng như sau:
Tất cả các tài liệu người dùng phải được nhóm đảm bảo chất lượng
phần mềm xem xét và phê duyệt về tính đúng đắn, chính xác, dễ đọc
và hữu ích.
Trợ giúp trực tuyến nên được nhóm đảm bảo chất lượng phần mềm
xem xét và ký tên.
14.3 LỰA CHỌN TIÊU CHÍ CHẤP NHẬN
Các tiêu chí chấp nhận được thảo luận ở trên cung cấp một ý tưởng
rộng rãi về nhu cầu và mong đợi của khách hàng, nhưng những tiêu
chí đó quá nhiều và rất chung chung. Khách hàng cần chọn một tập
hợp con của các thuộc tính chất lượng và sắp xếp thứ tự ưu tiên cho
chúng cho phù hợp với tình hình cụ thể của họ. Tiếp theo, khách
hàng xác định các tiêu chí chấp nhận cho từng thuộc tính chất lượng
đã chọn. Khi khách hàng và nhà cung cấp phần mềm đạt được thỏa
thuận về tiêu chí chấp nhận, cả hai bên phải ghi nhớ rằng việc thỏa
mãn các tiêu chí chấp nhận là sự đánh đổi giữa thời gian, chi phí và
chất lượng. Như Ed Yourdon đã nhận định, đôi khi kém hoàn hảo là
đủ tốt [6]. Chỉ các mục tiêu kinh doanh và mức độ ưu tiên mới có thể
xác định mức độ “kém hoàn hảo” mà cả hai bên có thể chấp nhận
được. Cuối cùng, các tiêu chí chấp nhận phải liên quan đến các mục
tiêu kinh doanh của tổ chức của khách hàng.
Nhiều tổ chức liên kết với các lĩnh vực ứng dụng khác nhau đã lựa
chọn và tùy chỉnh các thuộc tính chất lượng hiện có để xác định chất
lượng cho chính họ, có tính đến tình hình kinh doanh và thị trường cụ
thể của họ. Ví dụ, IBM đã sử dụng danh sách thuộc tính chất lượng
CUPRIMDS — khả năng, khả năng sử dụng, hiệu suất, độ tin cậy,
cài đặt, bảo trì, tài liệu và dịch vụ — cho các sản phẩm của mình [7].
Tương tự, đối với các ứng dụng dựa trên web [8], một tập hợp các
thuộc tính chất lượng được xác định theo thứ tự ưu tiên giảm dần: độ
tin cậy, khả năng sử dụng, bảo mật, tính khả dụng, khả năng mở
rộng, khả năng bảo trì và thời gian đưa ra thị trường. Sơ đồ ưu tiên
như vậy thường được sử dụng trong các lĩnh vực ứng dụng cụ thể. Ví
dụ, khả năng sử dụng và khả năng bảo trì được ưu tiên hơn hiệu suất
và độ tin cậy đối với một phần mềm xử lý văn bản. Mặt khác, có thể
638 CHƯƠNG 15 ĐỘ TIN CẬY CỦA PHẦN MỀM
ngược lại đối với hệ điều hành thời gian thực hoặc phần mềm viễn
thông.
14.4 KẾ HOẠCH KIỂM TRA CHẤP NHẬN
Lập kế hoạch kiểm tra chấp nhận bắt đầu ngay sau khi các tiêu chí
chấp nhận được biết. Việc phát triển sớm kế hoạch kiểm tra nghiệm
thu (ATP) cho chúng ta một bức tranh tốt về sản phẩm cuối cùng.
Mục đích của ATP là phát triển một phác thảo chi tiết của quy trình
để kiểm tra hệ thống trước khi thực hiện chuyển đổi sang việc sử
dụng hệ thống trong kinh doanh thực tế. Thông thường, ATP được
nhà cung cấp phân phối theo thỏa thuận hợp đồng, do đó việc kiểm
tra chấp nhận kinh doanh có thể được thực hiện trong tổ chức phát
triển của nhà cung cấp để đảm bảo rằng hệ thống cuối cùng đã vượt
qua kiểm tra chấp nhận.
Trong việc phát triển ATP, người ta nhấn mạnh vào việc chứng minh
rằng hệ thống hoạt động theo mong đợi của khách hàng, thay vì vượt
qua một loạt các bài kiểm tra toàn diện. Trong mọi trường hợp, hệ
thống dự kiến đã vượt qua một tập hợp các bài kiểm tra toàn diện
trong quá trình kiểm tra cấp hệ thống. ATP phải được giữ rất đơn
giản vì đối tượng của kế hoạch này có thể bao gồm những người từ
nhiều nguồn gốc khác nhau, chẳng hạn như các nhà quản lý tiếp thị
và kinh doanh. Một số người cho rằng ATP là thừa và không cần
thiết nếu một kế hoạch kiểm tra hệ thống toàn diện được phát triển.
Chúng tôi tin rằng ngay cả khi kế hoạch kiểm tra hệ thống là phù
hợp, kiểm tra chấp nhận thường phát hiện thêm các vấn đề quan
trọng. Hơn nữa, mối quan tâm của người dùng không được giải quyết
trong quá trình thử nghiệm cấp hệ thống.
Một ATP cần được viết và thực thi bởi nhóm người dùng đặc biệt
của khách hàng. Nhóm người dùng bao gồm những người từ các nền
tảng khác nhau, chẳng hạn như kỹ sư đảm bảo chất lượng phần mềm,
cộng tác viên kinh doanh và kỹ sư hỗ trợ khách hàng. Ngoài ra, các
trường hợp kiểm thử chấp nhận được thực thi tại môi trường hoạt
động của người dùng, trong khi các trường hợp kiểm thử cấp hệ
thống được thực thi trong môi trường phòng thí nghiệm. Kế hoạch
kiểm tra tổng thể để kiểm tra chấp nhận và mô tả các kiểm tra cụ thể
được ghi lại trong ATP. Cấu trúc của một ATP điển hình được trình
bày trong Bảng 14.1.
639
Phần giới thiệu của ATP mô tả cấu trúc của kế hoạch kiểm tra và
những gì chúng tôi dự định đạt được với kế hoạch kiểm tra này. Phần
này thường bao gồm (i) tên dự án thử nghiệm, (ii) lịch sử sửa đổi,
(iii) thuật ngữ và định nghĩa, (iv) tên của những người phê duyệt và
ngày phê duyệt, (v) tổng quan về kế hoạch, và (vi) người giới thiệu.
Đối với mỗi loại chất lượng từ tài liệu ký kết tiêu chí chấp nhận, hai
phần phụ được tạo ra: môi trường hoạt động và đặc tả trường hợp thử
nghiệm. Môi trường hoạt động đề cập đến việc thảo luận về việc
chuẩn bị địa điểm để thực hiện các trường hợp kiểm thử nghiệm thu.
Các trường hợp thử nghiệm được quy định cho từng tiêu chí chấp
nhận trong danh mục chất lượng.
Bản phác thảo về thời gian thực hiện các bài kiểm tra nghiệm thu
được cung cấp trong phần lịch trình của ATP. Việc thực hiện kiểm
tra chấp nhận không nhằm mục đích toàn diện và do đó nó không
tiếp tục lâu dài. Kiểm tra chấp nhận
BẢNG 14.1 Sơ lược về ATP
Giới thiệu
Nghiệm thu hạng mục. Đối với từng loại tiêu chí chấp nhận:
Môi trường hoạt động
Đặc tả trường hợp thử nghiệm
Số ID trường hợp thử nghiệm
Tiêu đề thử nghiệm
Mục tiêu kiểm tra
Quy trình kiểm tra
Lịch trình
Nguồn nhân lực
14.5 THỰC HIỆN KIỂM TRA CHẤP NHẬN

có thể mất đến sáu tuần đối với một hệ thống lớn. Điểm mấu chốt ở
đây là kiểm thử chấp nhận toàn diện, ở mức độ và độ sâu tương tự
như mục tiêu của kiểm thử cấp hệ thống, không bắt buộc phải chứng
minh rằng hệ thống đáp ứng các tiêu chí chấp nhận.
Phần nguồn nhân lực của ATP đề cập đến (i) việc xác định những
người kiểm tra chấp nhận hình thành tổ chức khách hàng và (ii) vai
trò cụ thể của họ trong việc thực hiện các trường hợp kiểm tra chấp
nhận. Phần này bao gồm chuẩn bị địa điểm kiểm tra nghiệm thu,
giám sát cài đặt phần cứng mới, nâng cấp phần mềm và thiết lập
mạng. Đây là những người am hiểu về môi trường hoạt động và hoạt
động kinh doanh . Ngoài ra, yêu cầu về nguồn nhân lực từ tổ chức
nhà cung cấp trong quá trình kiểm tra nghiệm thu được bao gồm
trong phần này. Các kỹ sư này thường thuộc nhóm kiểm tra hệ thống
của nhà cung cấp, những người đã tham gia kiểm tra hệ thống.
ATP được xem xét và phê duyệt bởi các nhóm liên quan, chẳng hạn
như nhóm tiếp thị, hỗ trợ khách hàng và đảm bảo chất lượng phần
mềm. Nó có thể được chia sẻ với tổ chức nhà cung cấp hệ thống.
14.5 THỰC HIỆN KIỂM TRA CHẤP NHẬN
Các trường hợp kiểm thử chấp nhận được chia thành hai nhóm con.
Nhóm con đầu tiên bao gồm các trường hợp thử nghiệm cơ bản và
nhóm thứ hai bao gồm các trường hợp thử nghiệm phức tạp hơn để
thực thi. Việc kiểm tra nghiệm thu được thực hiện trong hai giai
đoạn. Trong giai đoạn đầu, các trường hợp kiểm thử từ nhóm kiểm
thử cơ bản được thực thi. Nếu kết quả kiểm tra đạt yêu cầu, thì giai
đoạn thứ hai, trong đó các trường hợp kiểm thử phức tạp được thực
hiện, sẽ được thực hiện. Ngoài các trường hợp thử nghiệm cơ bản,
một tập hợp con của các trường hợp thử nghiệm cấp hệ thống được
thực hiện bởi các kỹ sư thử nghiệm chấp nhận để xác nhận độc lập
kết quả thử nghiệm. Rõ ràng, một câu hỏi quan trọng là: Tập hợp con
nào của các trường hợp kiểm thử cấp hệ thống được chọn? Nên chọn
ngẫu nhiên 5–10 trường hợp thử nghiệm từ mỗi loại thử nghiệm. Nếu
một phần rất lớn, hơn 0,95, trong số các trường hợp thử nghiệm cơ
bản vượt qua, thì giai đoạn thứ hai có thể tiến hành. Việc thực hiện
các bài kiểm tra phức tạp hơn có thể phản tác dụng nếu một phần
đáng kể các bài kiểm tra cơ bản không đạt.
Thực hiện kiểm tra chấp nhận là một hoạt động quan trọng được thực
hiện bởi khách hàng với sự hỗ trợ nhiều từ các nhà phát triển. Hoạt
động này bao gồm các hành động chi tiết sau:
Các nhà phát triển đào tạo khách hàng về cách sử dụng hệ thống.
Các nhà phát triển và khách hàng phối hợp khắc phục bất kỳ vấn đề
nào được phát hiện trong quá trình kiểm tra chấp nhận.
Các nhà phát triển và khách hàng giải quyết các vấn đề phát sinh từ
bất kỳ sự khác biệt nào về tiêu chí chấp nhận.
641
Nhân viên kiểm tra cấp hệ thống từ tổ chức phát triển đi đến địa điểm
của khách hàng, nơi các kiểm tra chấp nhận sẽ được tiến hành. Họ hỗ
trợ
BẢNG 14.2 Thông tin tài liệu ACC
1. Số ACC Một số duy nhất

2. Tiêu chí chấp nhận bị ảnh Tiêu chí chấp nhận hiện tại
hưởng
3. Sự cố / mô tả sự cố Mô tả ngắn gọn về vấn đề
4. Mô tả thay đổi cần thiết Mô tả những thay đổi cần thực hiện
đối với tiêu chí chấp nhận ban đầu
5. Các tác động kỹ thuật thứ Mô tả tác động của nó đối với hệ
cấp thống
6. Tác động của khách hàng Tác động của nó đối với người dùng
cuối
7. Thay đổi do Tên của (các) kỹ sư nghiệm thu
8. Thay đổi được phê duyệt Tên của (các) người phê duyệt từ cả
bởi hai bên
khách hàng trong việc chuẩn bị một địa điểm thử nghiệm và đào tạo
các kỹ sư nghiệm thu về cách sử dụng hệ thống. Họ cung cấp kết quả
kiểm tra cấp hệ thống sớm hơn cho các kỹ sư kiểm tra của khách
hàng để đưa ra quyết định không chính thức về hướng và trọng tâm
của nỗ lực kiểm tra chấp nhận. Ngoài ra, các kỹ sư kiểm tra hệ thống
tại chỗ trả lời các câu hỏi của khách hàng về hệ thống và hỗ trợ các
kỹ sư nghiệm thu thực hiện các kiểm tra nghiệm thu.
Bất kỳ lỗi nào gặp phải trong quá trình kiểm tra chấp nhận đều được
báo cáo cho tổ chức phát triển phần mềm thông qua các kỹ sư kiểm
tra hệ thống tại chỗ. Các khiếm khuyết được gửi thông qua hệ thống
theo dõi lỗi. Bản xây dựng phần mềm được nhà cung cấp kiểm tra lại
và hình ảnh phần mềm đạt yêu cầu được cung cấp cho khách hàng để
tiếp tục kiểm tra chấp nhận khi các lỗi đã được khắc phục. Các bài
kiểm tra không thành công được lặp lại sau khi hệ thống được nâng
cấp với hình ảnh phần mềm mới. Phải đạt được thỏa thuận giữa các
kỹ sư kiểm thử hệ thống tại chỗ và các kỹ sư kiểm thử nghiệm thu
khi nào thì chấp nhận một hình ảnh phần mềm mới để kiểm thử
nghiệm thu. Số lần hệ thống có thể được nâng cấp lên hình ảnh phần
mềm mới trong quá trình kiểm tra nghiệm thu được thương lượng
giữa khách hàng và nhà cung cấp. Nhiều lỗi của một hệ thống trong
quá trình kiểm tra chấp nhận là một dấu hiệu của chất lượng hệ thống
kém.
Có thể một kỹ sư kiểm tra nghiệm thu có thể gặp phải các vấn đề liên
quan đến tiêu chí chấp nhận trong quá trình thực hiện các trường hợp
kiểm tra nghiệm thu. Hệ thống có thể không cung cấp dịch vụ cho
người dùng như được mô tả trong tiêu chí chấp nhận. Bất kỳ sai lệch
nào so với các tiêu chí chấp nhận được phát hiện ở giai đoạn này có
thể không được khắc phục ngay lập tức. Kỹ sư kiểm tra chấp nhận có
thể tạo tài liệu thay đổi tiêu chí chấp nhận (ACC) để thông báo sự
thiếu sót trong tiêu chí chấp nhận cho nhà cung cấp. Định dạng đại
diện của tài liệu ACC được thể hiện trong Bảng 14.2. Báo cáo ACC
thường được cung cấp cho bộ phận tiếp thị của nhà cung cấp thông
qua các kỹ sư kiểm tra hệ thống tại chỗ.
14.6 BÁO CÁO KIỂM TRA CHẤP NHẬN
Các hoạt động kiểm tra chấp nhận được thiết kế để đạt được một
trong ba kết luận: Chấp nhận hệ thống như được giao, chấp nhận hệ
thống sau khi các sửa đổi được yêu cầu có
14.6 BÁO CÁO KIỂM TRA CHẤP NHẬN
được thực hiện, hoặc không chấp nhận hệ thống. Thông thường, một
số quyết định trung gian hữu ích được đưa ra trước khi đưa ra quyết
định cuối cùng:
• Quyết định được đưa ra về việc tiếp tục thử nghiệm chấp nhận nếu
kết quả của giai đoạn đầu tiên của thử nghiệm chấp nhận không có
triển vọng. Người ta có thể nhớ lại rằng các thử nghiệm cơ bản được
thực hiện trong giai đoạn đầu tiên. • Nếu kết quả kiểm tra không đạt
yêu cầu, các thay đổi sẽ được thực hiện đối với hệ thống trước khi
kiểm tra chấp nhận có thể tiến hành giai đoạn tiếp theo.
Các quyết định trung gian được thực hiện dựa trên đánh giá kết quả
của giai đoạn đầu tiên của thử nghiệm. Hơn nữa, trong quá trình thực
hiện nghiệm thu, tình trạng kiểm tra được xem xét vào cuối mỗi ngày
làm việc bởi trưởng nhóm nghiệm thu, kỹ sư kiểm tra hệ thống tại
chỗ và giám đốc dự án của khách hàng và nhà cung cấp. Nhóm
nghiệm thu chuẩn bị một báo cáo thử nghiệm làm cơ sở cho việc thảo
643
luận tại cuộc họp đánh giá trước khi họ họp để xem xét. Mẫu báo cáo
thử nghiệm được nêu trong Bảng 14.3.
Báo cáo thử nghiệm được xem xét hàng ngày để hiểu tình trạng và
tiến độ của thử nghiệm chấp nhận. Nếu các vấn đề nghiêm trọng gặp
phải trong quá trình kiểm tra chấp nhận, người quản lý dự án sẽ gắn
cờ các vấn đề cho quản lý cấp cao.
Vào cuối giai đoạn đầu tiên và giai đoạn thứ hai của thử nghiệm
nghiệm thu, một biên bản thử nghiệm nghiệm thu được lập bởi
trưởng nhóm thử nghiệm. Mẫu cho báo cáo thử nghiệm được nêu
trong Bảng 14.4. Hầu hết các thông tin từ báo cáo tình trạng thử
nghiệm có thể được sử dụng trong báo cáo tóm tắt thử nghiệm
nghiệm thu.
Định danh báo cáo xác định duy nhất báo cáo. Nó được sử dụng để
theo dõi tài liệu dưới sự kiểm soát của phiên bản.
Phần tóm tắt tóm tắt những hoạt động kiểm thử chấp nhận nào đã
diễn ra, bao gồm các giai đoạn kiểm thử, các bản phát hành phần
mềm được sử dụng và môi trường kiểm thử. Phần này thường bao
gồm các tham chiếu đến ATP, tiêu chí chấp nhận và đặc tả yêu cầu.
Phần phương sai mô tả bất kỳ sự khác biệt nào giữa thử nghiệm đã
được lập kế hoạch và thử nghiệm thực tế được thực hiện. Nó cung
cấp một cái nhìn sâu sắc về một quy trình để cải thiện việc lập kế
hoạch kiểm tra chấp nhận trong tương lai.
BẢNG 14.3 Cấu trúc của Báo cáo Tình trạng Kiểm tra Nghiệm
thu
1. Ngày Ngày báo cáo nghiệm thu

2. Trạng thái thực thi trường Số lượng trường hợp thử nghiệm được
hợp thử nghiệm thực thi ngày hôm nay
Số lượng trường hợp thử nghiệm vượt
qua
Số lượng trường hợp thử nghiệm không
thành công
3. Định danh khiếm khuyết Số lỗi đã gửi Mô tả ngắn gọn về vấn đề
4. (Các) số ACC Tiêu chí chấp nhận thay đổi (các) số tài
liệu, nếu có
5. Trạng thái thực thi thửTổng số trường hợp thử nghiệm được
thực thi Tổng số trường hợp thử
nghiệm tích lũy nghiệm vượt qua

Tổng số trường hợp thử nghiệm không
thành công
Tổng số trường hợp thử nghiệm chưa
được thực thi
BẢNG 14.4 Cấu trúc của Báo cáo Tóm tắt Kiểm tra Nghiệm
thu
Báo cáo số nhận dạng

Bản tóm tắt
Phương sai
Tóm tắt kết quả
Sự đánh giá
khuyến nghị
Tóm tắt các hoạt động
Phê duyệt
Trong phần tóm tắt kết quả của kết quả kiểm tra tài liệu được tóm tắt.
Phần này cho biết tổng số trường hợp kiểm thử được thực hiện, số
trường hợp kiểm thử đạt và số trường hợp kiểm thử không đạt; xác
định tất cả các khuyết tật; và tóm tắt các tiêu chí chấp nhận được thay
đổi.
Phần đánh giá cung cấp đánh giá tổng thể về từng loại thuộc tính chất
lượng được xác định trong tài liệu tiêu chí chấp nhận, bao gồm cả
những hạn chế của chúng. Đánh giá này dựa trên kết quả kiểm tra từ
mỗi hạng mục của kế hoạch kiểm tra. Các sai lệch của các tiêu chí
chấp nhận được ghi lại trong ACC trong quá trình kiểm tra chấp nhận
được thảo luận.
Phần khuyến nghị bao gồm khuyến nghị tổng thể của nhóm kiểm tra
chấp nhận: (i) chấp nhận hệ thống một cách vô điều kiện, (ii) chấp
nhận hệ thống với các điều kiện nhất định được đáp ứng, hoặc (iii) từ
chối hệ thống. Tuy nhiên, quyết định cuối cùng là do các chuyên gia
kinh doanh của nhà cung cấp và tổ chức người mua đưa ra.
Phần tóm tắt các hoạt động tóm tắt các hoạt động thử nghiệm và các
sự kiện chính. Phần này bao gồm thông tin về các nguồn lực được sử
dụng bởi các hoạt động khác nhau. Ví dụ, tổng số nhân lực tham gia
645
và thời gian dành cho mỗi hoạt động thử nghiệm chính được đưa ra.
Phần này hữu ích cho ban quản lý để ước tính chính xác các nỗ lực
kiểm tra chấp nhận trong tương lai.
Cuối cùng, tên và chức danh của tất cả những người sẽ phê duyệt báo
cáo này được liệt kê trong phần phê duyệt. Tốt nhất, những người
phê duyệt báo cáo này phải là những người đã phê duyệt ATP tương
ứng vì báo cáo tóm tắt mô tả tất cả các hoạt động được nêu trong
ATP. Nếu một số người đánh giá có những bất đồng nhỏ, họ có thể
lưu ý quan điểm của mình trước khi ký tên vào tài liệu.
14.7 KIỂM TRA CHẤP NHẬN TRONG LẬP TRÌNH eXtreme
Trong khuôn khổ XP [9], các câu chuyện của người dùng được sử
dụng làm tiêu chí chấp nhận. Các câu chuyện của người dùng được
sử dụng để ước tính thời gian cho mỗi lần lặp lại phát triển trong lập
kế hoạch phát hành (tiêu chí chấp nhận theo thời gian đến thị trường)
và kiểm tra chấp nhận. Các câu chuyện người dùng được viết bởi
khách hàng như những thứ mà hệ thống cần làm cho họ. Các
14.8 TÓM TẮT
các câu chuyện thường có khoảng hai đến ba câu văn bản được viết
bằng thuật ngữ của khách hàng. Một số thử nghiệm chấp nhận được
tạo để xác minh rằng câu chuyện của người dùng đã được triển khai
chính xác. Các bài kiểm tra chấp nhận được quy định theo một định
dạng đủ rõ ràng để khách hàng có thể hiểu và đủ cụ thể để nó có thể
được thực hiện.
Khách hàng có trách nhiệm xác minh tính đúng đắn của các phép thử
nghiệm thu và xem xét các kết quả thử nghiệm [10]. Các kết quả
kiểm tra chấp nhận được khách hàng xem xét để quyết định những
kiểm tra không đạt nào có mức độ ưu tiên cao nhất phải vượt qua
trong lần lặp tiếp theo. Một câu chuyện không hoàn chỉnh cho đến
khi nó vượt qua các bài kiểm tra chấp nhận liên quan.
Kiểm thử chấp nhận được thực hiện bởi một nhóm kiểm thử chấp
nhận, là một phần của nhóm phát triển. Lý tưởng nhất là các kiểm
thử chấp nhận nên được tự động hóa bằng cách sử dụng khung kiểm
thử đơn vị hoặc khung kiểm thử chấp nhận riêng biệt trước khi mã
hóa. Các kỹ sư kiểm tra chấp nhận và khách hàng có thể chạy các bài
kiểm tra nhiều lần mỗi ngày như một bộ kiểm thử chấp nhận hồi quy
sau khi các bài kiểm tra chấp nhận được tự động hóa. Một bộ kiểm
thử chấp nhận tự động không bị mất giá trị ngay cả sau khi khách
hàng đã chấp thuận việc triển khai thành công câu chuyện của người
dùng trong một lần lặp lại phát triển. Các bài kiểm tra chấp nhận đảm
nhận vai trò của các bài kiểm tra hồi quy để đảm bảo rằng các thay
đổi tiếp theo đối với hệ thống không ảnh hưởng đến chức năng không
thay đổi.
14.8 TÓM TẮT
Chương này bắt đầu với phần giới thiệu về hai loại kiểm thử chấp
nhận: kiểm thử chấp nhận của người dùng và kiểm thử chấp nhận của
doanh nghiệp. Tiếp theo, chương này mô tả các tiêu chí chấp nhận
dưới dạng các thuộc tính chất lượng. Việc xây dựng các tiêu chí chấp
nhận được điều chỉnh bởi các mục tiêu kinh doanh của tổ chức của
khách hàng.
Chúng tôi đã trình bày một phác thảo của một kế hoạch kiểm tra
chấp nhận và mô tả chi tiết cách tạo một kế hoạch như vậy. Cần phải
nhấn mạnh rằng hệ thống hoạt động theo mong đợi của khách hàng
trong việc phát triển kế hoạch kiểm tra chấp nhận, thay vì chỉ vượt
qua kiểm tra toàn diện. Ít nhấn mạnh hơn vào một hệ thống vượt qua
một loạt các bài kiểm tra toàn diện bởi vì kiểm tra nghiêm ngặt được
cho là đã xảy ra trong giai đoạn kiểm tra hệ thống.
Tiếp theo, chúng tôi thảo luận về việc thực hiện các kiểm thử chấp
nhận, đây là một hoạt động quan trọng được thực hiện bởi khách
hàng với sự hỗ trợ cần thiết của các nhà phát triển. Ba hoạt động
chính đã được xác định và thảo luận: (i) cung cấp đào tạo cho các kỹ
sư thử nghiệm của khách hàng, (ii) khắc phục sự cố trong quá trình
thử nghiệm chấp nhận và (iii) giải quyết các vấn đề liên quan đến bất
kỳ sự khác biệt nào liên quan đến tiêu chí chấp nhận. Sau đó, chúng
tôi mô tả việc tạo báo cáo kiểm tra chấp nhận, báo cáo này phải được
hoàn thành khi kết thúc kiểm tra chấp nhận.
Cuối cùng, chúng tôi đã giải thích cách user story được sử dụng
trong XP làm tiêu chí chấp nhận và các trường hợp kiểm thử chấp
nhận được tạo ra. Các thử nghiệm này được xem xét, tự động hóa và
thực hiện nhiều lần mỗi ngày như một bộ thử nghiệm chấp nhận hồi
quy với sự hiện diện của khách hàng tại chỗ.
647
Quy trình xử lý triệt để về tiêu chuẩn chất lượng phần mềm có thể
được tìm thấy trong ISO / IEC 9126-1: 2001, “Kỹ thuật phần mềm —
Chất lượng sản phẩm — Phần I: Mô hình chất lượng”. Nhóm tiêu
chuẩn đã khuyến nghị một khuôn khổ phân cấp cho các đặc tính và
đặc điểm phụ của chất lượng phần mềm. Sáu đặc điểm chất lượng
phần mềm cấp cao nhất là chức năng, độ tin cậy, khả năng sử dụng,
hiệu quả, khả năng bảo trì và tính di động.
Một phương pháp phân loại xuất sắc trong lĩnh vực thuộc tính chất
lượng đáng tin cậy được trình bày trong bài báo của Algirdas
Avizienis, Jean-Claude Laprie, Brian Ran-ˇ dell và Carl Landwehr,
“Các khái niệm cơ bản và phân loại của Máy tính Tin cậy và An
toàn,” Giao dịch IEEE trên Máy tính an toàn và đáng tin cậy, Vol. 1,
số 1, tháng 1 - tháng 3 năm 2004, trang 11–33. Trong bài viết này,
mối quan hệ giữa thuộc tính độ tin cậy và chất lượng bảo mật được
thảo luận rất chi tiết. Độ tin cậy được định nghĩa là một khái niệm
tích hợp bao gồm các thuộc tính sau: tính khả dụng, độ tin cậy, an
toàn, tính toàn vẹn và khả năng bảo trì. Mặt khác, bảo mật mang lại
mối quan tâm về tính bảo mật bên cạnh tính sẵn có và tính toàn vẹn.
Bài báo đề cập đến khái niệm về các mối đe dọa đối với độ tin cậy và
bảo mật (lỗi, lỗi, lỗi), các thuộc tính của chúng và các phương tiện để
đạt được chúng, chẳng hạn như ngăn ngừa lỗi, khả năng chịu lỗi, loại
bỏ lỗi và dự báo lỗi.
Một quan điểm thú vị về các đặc tính chất lượng phần mềm được
trình bày trong CK Prahalad và MS Krishnan, “Ý nghĩa mới của chất
lượng trong thời đại thông tin,” Harvard Business Review, tháng 9
năm 1999, trang 109–118. Các tác giả cung cấp một khuôn khổ để đo
lường hiệu suất của phần mềm trong danh mục công nghệ thông tin
của một công ty dựa trên ba thuộc tính cơ bản: tính tuân thủ, khả
năng thích ứng và sự đổi mới. Để đánh giá đúng chất lượng phần
mềm, các tác giả lập luận rằng các nhà quản lý phải đo lường các ứng
dụng dựa trên cả ba thuộc tính.
Các sinh viên được khuyến khích đọc bài báo của P. Hsia, D. Kung,
và C. Sell, “Yêu cầu phần mềm và kiểm tra chấp nhận,” Biên niên sử
về Kỹ thuật phần mềm, Vol. 3, số 0, tháng 1 năm 1997, trang 291–
317. Các tác giả trình bày một cách tiếp cận có hệ thống để phân tích
kịch bản và ứng dụng của nó vào kiểm thử chấp nhận. Dựa trên mô
hình, các tiêu chí kiểm thử chấp nhận khác nhau được xác định và
các loại kiểm thử chấp nhận khác nhau được thảo luận.
Cuốn sách có tựa đề Kiểm thử lập trình cực đoan (L. Crispin và T.
House, Addison-Wesley, Boston, MA, 2003) đưa ra một giải trình
tuyệt vời về đơn vị và kiểm thử chấp nhận trong XP. Cuốn sách được
chia thành ba phần: vai trò người thử nghiệm XP, lái thử thông qua
một dự án XP và bộ tài liệu sinh tồn khi gặp nguy hiểm trên đường.
Cuốn sách liệt kê một số cuốn sách xuất sắc về chủ đề này trong thư
mục của nó.
Bài tập
Các mục tiêu của kiểm thử chấp nhận là gì?
Sự khác biệt giữa UAT và BAT là gì?
Thảo luận về những thuận lợi và khó khăn của việc khách hàng tham
gia vào thử nghiệm.
Chất lượng phần mềm là gì?
Ai nên xác định các tiêu chí thuộc tính chất lượng chấp nhận của một
dự án thử nghiệm.
Bạn có thể nghĩ đến những thuộc tính phẩm chất nào khác không
được đề cập trong cuốn sách này?
Tấn công DoS nghĩa là gì? Giải thích tầm quan trọng của nó trong
kiểm thử chấp nhận.
Thuộc tính chất lượng bảo mật không được thảo luận rõ ràng trong
cuốn sách này. Tuy nhiên, nó có thể là sự kết hợp của các thuộc tính
con, được thảo luận trong cuốn sách này. Những thuộc tính phụ chất
lượng đó là gì?
Trong loạt ví dụ về ứng dụng sau đây, hãy cung cấp bốn thuộc tính
chất lượng quan trọng nhất được thảo luận trong cuốn sách này mà
bạn cho là quan trọng đối với các ứng dụng. Tại sao các thuộc tính
chất lượng lại được bạn chọn là những thuộc tính quan trọng?
Phần mềm viễn thông
Phần mềm trò chơi điện tử
Phần mềm hệ thống phát hiện xâm nhập (IDS)
Phần mềm chẩn đoán y tế để hỗ trợ bác sĩ
Trang web tải nhạc nổi tiếng
Hệ điều hành trên tàu thăm dò sứ mệnh không gian sâu
Hệ thống tính toán lương hưu
Hệ thống e-mail
649
Phần mềm hệ thống máy bay
Dịch vụ điện thoại bán tự động để giúp trả lời các câu hỏi về luật
nhập cư và quốc tịch
Tại sao các trường hợp kiểm thử chấp nhận được thực hiện trong hai
giai đoạn?
Tại sao các kỹ sư kiểm tra hệ thống bắt buộc phải có mặt tại nơi thực
thi ATP?
Đối với dự án phần mềm hiện tại bạn đang thực hiện, hãy trả lời các
câu hỏi sau:
Liệt kê các thuộc tính chất lượng quan trọng nhất đối với dự án của
bạn. Để tập trung vào các bài kiểm tra chấp nhận kinh doanh, hãy
chọn không quá sáu thuộc tính chất lượng từ danh sách này làm tiêu
chí chấp nhận quan trọng nhất cho hệ thống của bạn.
Tại sao các tiêu chí chấp nhận đã chọn lại là những tiêu chí quan
trọng nhất đối với hệ thống của bạn?
Có bất kỳ tiêu chí chấp nhận nào khác áp dụng cho hệ thống của bạn
nhưng không được liệt kê trong cuốn sách này không?
Dựa trên sáu tiêu chí chấp nhận đã chọn mà bạn đã xác định cho dự
án phần mềm của mình trong các câu hỏi trước:
Phát triển một ATP kinh doanh.
Thực thi ATP kinh doanh đối với hệ thống.
Tạo tài liệu ACC nếu bạn quan sát thấy bất kỳ sai lệch nào so với
tiêu chí chấp nhận trong quá trình thực hiện ATP.
Tạo báo cáo tóm tắt kiểm tra chấp nhận.
CHAPTER
15
SoftwareReliability
Thất bại chỉ là thành công có hậu miễn là dũng cảm '' huấn luyện
viên '' tham vọng. Thói quen bền bỉ là thói quen chiến thắng.
—HerbertKaufman
15.1 ĐỘ TIN CẬY LÀ GÌ?
Khái niệm độ tin cậy rất rộng, và nó có thể được áp dụng bất cứ khi
nào ai đó mong đợi điều gì đó hoặc ai đó “hành xử” theo một cách
nhất định. Ví dụ: một công tắc chiếu sáng dự kiến sẽ ở một trong hai
trạng thái — bật và tắt — do người dùng thiết lập. Nếu công tắc
chiếu sáng khiến đèn nhấp nháy ngay cả khi nguồn điện ổn định và
cáp kết nối không bị lỗi, chúng tôi nói rằng công tắc đó đã chuyển
sang trạng thái không đáng tin cậy. Với tư cách là khách hàng, chúng
tôi mong muốn một công tắc mới không gây ra hiện tượng nhấp
nháy. Chúng tôi nói rằng công tắc bị lỗi nếu nó làm cho đèn nhấp
nháy. Hơn nữa, một công tắc mới có thể hoạt động không có lỗi
trong vài năm trước khi bắt đầu gây ra hiện tượng nhấp nháy đèn.
Trong trường hợp đó, chúng tôi nói rằng hao mòn đã làm cho công
tắc hoạt động sai và do đó công tắc trở nên không đáng tin cậy. Do
đó, khái niệm lỗi được gắn liền với khái niệm độ tin cậy.
Một hệ thống phần cứng không có lỗi ban đầu hoạt động một cách
đáng tin cậy chỉ đơn giản là vì nó hoạt động như mong đợi do không
có lỗi trong thiết kế và sản xuất của nó. Khi hệ thống phần cứng mới
bắt đầu hoạt động, sự hao mòn có thể khiến nó phát triển lỗi, do đó
khiến hệ thống hoạt động theo cách không mong muốn hoặc không
đáng tin cậy. Các nguồn lỗi trong hệ thống phần mềm là lỗi thiết kế
và triển khai. Lỗi phần mềm thường xảy ra khi một chương trình
được thực thi trong một môi trường mà nó không được phát triển
hoặc thử nghiệm.
Độ tin cậy là một trong những thước đo được sử dụng để đo chất
lượng của một hệ thống phần mềm. Nó được cho là yếu tố chất lượng
quan trọng nhất được tìm kiếm trong một sản phẩm. Độ tin cậy là
một yếu tố chất lượng hướng đến người dùng liên quan đến hoạt
động của hệ thống và nó có tính đến tần suất xảy ra lỗi của hệ thống.
Theo trực giác, nếu người dùng của một hệ thống hiếm khi gặp lỗi hệ
thống, thì hệ thống đó được coi là đáng tin cậy hơn một hệ thống
thường xuyên bị lỗi hơn. Càng ngày càng có nhiều lỗi của một hệ
thống được quan sát bởi
471
651
người dùng, hệ thống càng ngày càng ít được coi là đáng tin cậy. Lý
tưởng nhất là nếu không có lỗi nào trong hệ thống phần mềm, người
dùng sẽ không bao giờ gặp lỗi hệ thống, do đó coi hệ thống có độ tin
cậy cao. Việc xây dựng một hệ thống “đúng”, tức là một hệ thống
không có lỗi, bản thân nó là một nhiệm vụ khó khăn vì các hệ thống
trong đời thực vốn đã rất phức tạp. Vấn đề xây dựng một hệ thống
không có lỗi trở nên khó khăn hơn khi các yếu tố thực tế được xem
xét. Ví dụ, phát triển hệ thống phần mềm chủ yếu là một hoạt động
kinh tế và các công ty hiếm khi có đủ thời gian và tiền bạc cần thiết
để tạo ra một hệ thống có độ tin cậy cao ngay cả khi họ có một đội
ngũ nhân sự có trình độ cao và giàu kinh nghiệm trong trường hợp
tốt nhất. Khái niệm cửa sổ thị trường có thể không cho phép một
công ty nỗ lực tạo ra một hệ thống “đúng”. Khoảng thời gian thị
trường được coi là khoảng thời gian có sẵn để giới thiệu một sản
phẩm trước khi sản phẩm đó bị một nhà cung cấp cạnh tranh vượt
qua về khả năng hoặc chi phí. Các cân nhắc kinh tế có thể khiến các
công ty đánh đổi độ tin cậy để chuyển sang cắt giảm chi phí và đáp
ứng tiến độ giao hàng.
Cho rằng có một số lỗi chưa biết trong một hệ thống được phân phối
và người dùng có thể chịu đựng một số lỗi, độ tin cậy của hệ thống
được thể hiện tốt nhất dưới dạng một biến liên tục chứ không phải là
một biến Boolean. Nhiều nỗ lực hơn được đưa vào giai đoạn phát
triển thường dẫn đến mức độ tin cậy cao hơn. Ngược lại, ít nỗ lực
hơn sẽ tạo ra các hệ thống có độ tin cậy thấp hơn. Do đó, khái niệm
độ tin cậy có thể được sử dụng để xem xét tầm quan trọng của các xu
hướng, trong việc thiết lập các mục tiêu và dự đoán khi nào các mục
tiêu đó sẽ đạt được. Ví dụ: các nhà phát triển có thể quan tâm đến
việc biết cách một quy trình phát triển nhất định, thời lượng kiểm thử
hệ thống hoặc kỹ thuật đánh giá thiết kế tác động như thế nào đến độ
tin cậy của phần mềm. Các nhà phát triển có thể quan tâm đến việc
biết tỷ lệ lỗi của hệ thống trong một môi trường hoạt động nhất định
để có thể quyết định thời điểm phát hành sản phẩm.
Bảo trì phần mềm liên quan đến việc thực hiện các loại thay đổi khác
nhau đối với hệ thống, cụ thể là các thay đổi đối với yêu cầu, thay đổi
thiết kế, thay đổi mã nguồn và thay đổi các trường hợp thử nghiệm.
Trong khi thực hiện những thay đổi đó, phần mềm sẽ trải qua một
giai đoạn không ổn định. Sự không ổn định ở dạng giảm độ tin cậy
của hệ thống. Mức độ tin cậy của hệ thống giảm trong quá trình bảo
trì hệ thống vì các lỗi bổ sung có thể xuất hiện trong khi thực hiện tất
cả các loại thay đổi đó đối với hệ thống. Về mặt trực quan, số lượng
thay đổi được thực hiện đối với hệ thống càng nhỏ thì mức độ tin cậy
hiện tại của hệ thống càng giảm. Mặt khác, quá nhiều thay đổi được
thực hiện đồng thời đối với hệ thống có thể làm giảm đáng kể mức
độ tin cậy. Do đó, số lượng thay đổi nên được thực hiện đối với một
sản phẩm tại một thời điểm nhất định phụ thuộc vào mức độ tin cậy
mà một sản phẩm sẵn sàng hy sinh tại thời điểm này.
15.1.1 Lỗi và Thất bại
Các khái niệm về lỗi, hỏng hóc và thời gian là trọng tâm trong hiểu
biết của chúng tôi về độ tin cậy. Nói chung, nếu người dùng không
bao giờ quan sát thấy lỗi, hệ thống được coi là rất đáng tin cậy. Mặt
khác, một hệ thống thường xuyên bị lỗi được coi là không đáng tin
cậy. Do đó, chúng tôi xem xét lại các điều khoản lỗi và lỗi trong
phần này. Một thất bại được cho là xảy ra nếu kết quả quan sát được
của việc thực hiện chương trình khác với kết quả mong đợi. Khái
niệm về kết quả có thể quan sát được là rất
rộng, và nó bao gồm nhiều thứ khác nhau, chẳng hạn như giá trị được
tạo ra, giá trị được truyền đạt, hiệu suất được thể hiện, v.v. Kết quả
mong đợi của việc thực thi chương trình được chỉ định như các yêu
cầu hệ thống. Yêu cầu hệ thống thường được nêu ở dạng rõ ràng
trong tài liệu yêu cầu. Đôi khi, do tính chất phức tạp của hệ thống
phần mềm, rất khó để trình bày rõ ràng tất cả các yêu cầu mong
muốn. Trong trường hợp không thể trình bày tất cả các yêu cầu một
cách rõ ràng, chúng tôi vẫn mong đợi một hệ thống hoạt động theo
những cách nhất định. Do đó, trong khi xem xét đâu là kết quả mong
đợi của việc thực hiện chương trình, người ta phải tính đến cả yêu
cầu hệ thống được mong đợi rõ ràng và được công bố rõ ràng. Hai
đặc điểm của thất bại như sau: (i) thất bại gắn liền với việc thực hiện
chương trình thực tế và (ii) thất bại là những khái niệm có thể quan
sát được.
Nguyên nhân thất bại được xét xử được gọi là lỗi. Trong khi xây
dựng một hệ thống phần mềm, một nhà thiết kế có thể đưa một lỗi
vào hệ thống một cách nhầm lẫn. Một lỗi có thể xuất hiện khi có một
khối mã bị lỗi, một khối mã bị thiếu cho một kịch bản thực thi không
653
lường trước được, v.v. Chỉ sự hiện diện của các lỗi trong một hệ
thống không gây ra lỗi. Thay vào đó, một hoặc nhiều phần bị lỗi của
hệ thống phải thực thi để lỗi tự biểu hiện thành lỗi hệ thống. Một lỗi
có thể gây ra nhiều lỗi tùy thuộc vào cách hệ thống thực thi mã bị lỗi
[1].
15.1.2 Thời gian
Thời gian đóng một vai trò quan trọng trong việc mô hình hóa các số
liệu đo độ tin cậy của phần mềm. Chúng ta hãy quay lại khái niệm về
độ tin cậy của công tắc chiếu sáng. Giả sử rằng một công tắc làm cho
đèn nhấp nháy trong vài giây và đặt khoảng cách thời gian trung bình
giữa hai lần nhấp nháy liên tiếp là sáu tháng. Ở đây, đèn nhấp nháy
có thể được coi là một lỗi có thể quan sát được của công tắc. Mặc dù
người dùng có thể bị kích thích bởi những lần nhấp nháy như vậy,
một số người vẫn có thể coi công tắc là đáng tin cậy vì khoảng cách
thời gian dài giữa hai lần nhấp nháy. Khoảng cách thời gian sáu
tháng có thể được coi là dài vì người dùng có thể không nhớ thời
điểm đèn nhấp nháy lần cuối. Tuy nhiên, nếu đèn nhấp nháy một vài
lần mỗi ngày, công tắc có vẻ kém tin cậy hơn và trở thành một ứng
cử viên để thay thế. Vì vậy, khái niệm về thời gian là quan trọng
trong việc hiểu khái niệm về độ tin cậy.
Có hai mô hình thời gian thường được xem xét trong nghiên cứu độ
tin cậy của phần mềm:
Thời gian thực hiện ( τ )
Lịch thời gian ( t )
Thời gian thực hiện đối với hệ thống phần mềm là thời gian thực tế
của bộ xử lý để thực hiện các lệnh của hệ thống phần mềm. Đôi khi
một bộ xử lý có thể thực thi mã từ các hệ thống phần mềm khác nhau
và do đó, thời gian thực thi riêng lẻ của chúng phải được xem xét
riêng biệt. Mặt khác, có nhiều hệ thống phần mềm được cho là sẽ
chạy liên tục trong nhiều tháng và nhiều năm mà không phát triển lỗi.
Ví dụ về các hệ thống này là phần mềm chuyển mạch điện thoại,
phần mềm kiểm soát không lưu và phần mềm giám sát các nhà máy
điện. Mặt khác, có những hệ thống phần mềm chạy một thời gian và
chấm dứt khi hoàn thành nhiệm vụ của chúng. Ví dụ, một trình biên
dịch kết thúc sau khi biên dịch một chương trình. Mặc dù khái niệm
độ tin cậy của phần mềm có thể được áp dụng cho tất cả các loại hệ
thống phần mềm, nhưng những hệ thống đang chạy liên tục thu hút
nhiều sự chú ý hơn.
Thời gian theo lịch là thời gian được mọi người, bao gồm cả các kỹ
sư phần mềm và quản lý dự án, hiểu và tuân theo phổ biến hơn trong
cuộc sống hàng ngày. Vì việc quan sát các lỗi, sửa các lỗi tương ứng
và thay thế phiên bản cũ của phần mềm bằng phiên bản mới gắn liền
với nhau trong vòng đời của hệ thống phần mềm, thời gian lịch rất
hữu ích cho những lý do thực dụng như kỹ sư rời công ty, kỹ sư nghỉ
việc. , và như thế.
Mô hình thời gian thứ ba đôi khi được gọi là thời gian đồng hồ của
một hệ thống phần mềm. Đồng hồ thời gian đề cập đến thời gian trôi
qua giữa thời gian bắt đầu và kết thúc thực hiện chương trình. Đồng
hồ thời gian bao gồm thời gian chờ của hệ thống phần mềm và thời
gian thực thi của các hệ thống phần mềm khác. Đồng hồ thời gian
không bao gồm tắt hệ thống.
Để hiểu rõ hơn về độ tin cậy của một phần mềm, người ta có thể đặt
những câu hỏi sau về lỗi và thời gian:
Khoảng thời gian giữa hai lần hỏng hóc liên tiếp là bao nhiêu?
Có bao nhiêu thất bại đã được quan sát thấy trong một khoảng thời
gian nhất định, ví dụ, trong một tháng hoặc một năm qua?
Tổng số lỗi quan sát được cho đến nay là bao nhiêu?
Câu trả lời cho các câu hỏi trên cho thấy mức chất lượng của một
phần mềm. Người ta có thể hỏi những câu hỏi trên bất cứ lúc nào sau
khi mã được phát triển. Bằng cách hỏi những câu hỏi trên trong quá
trình phát triển, người quản lý kiểm thử có thể theo dõi chất lượng
của phần mềm đang được cải thiện như thế nào. Mặt khác, bằng cách
trả lời các câu hỏi trong quá trình vận hành hệ thống, người ta có thể
biết được chất lượng sản phẩm được giao.
15.1.3 Khoảng thời gian giữa các lần hỏng
Người ta có thể suy ra một số đặc điểm của hệ thống phần mềm bằng
cách theo dõi khoảng thời gian giữa các lần hỏng hóc liên tiếp như
sau:
Một khoảng thời gian nhỏ giữa các lỗi liên tiếp cho chúng ta biết
rằng hệ thống phần mềm thường xuyên bị lỗi và do đó mức độ tin
cậy quá thấp. Điều này có thể xảy ra trong quá trình kiểm tra hệ
thống hoặc ngay cả khi hệ thống đang hoạt động. Nếu khoảng thời
gian giữa các lần hỏng hóc liên tiếp dài thì độ tin cậy được coi là cao,
655
mặc dù hệ thống không thường xuyên xảy ra lỗi. Các khái niệm về
khoảng thời gian “ngắn” và “dài” giữa các lần hỏng hóc liên tiếp là
vấn đề nhận thức của người dùng, phần lớn được xác định bởi hậu
quả của các lỗi. Ví dụ, nếu hệ điều hành của máy tính cá nhân bị lỗi
khoảng một lần trong năm, người dùng vẫn có thể coi hệ thống đó là
đáng tin cậy. Mặt khác, nếu một phần mềm kiểm soát không lưu
được cài đặt tại một sân bay quốc tế lớn bị sự cố một lần trong năm,
hệ thống sẽ được coi là không đáng tin cậy.
Trong ngành công nghiệp phần cứng, một số chỉ số độ tin cậy đã
được xác định bằng cách xem xét các phiên bản khi lỗi xảy ra và các
phiên bản
khi các lỗi tương ứng được sửa chữa. Ba số liệu thường được sử
dụng dựa trên khoảng thời gian là thời gian trung bình để sửa chữa
(MTTF), thời gian trung bình để sửa chữa (MTTR) và thời gian trung
bình giữa các lần hỏng hóc (MTBF). Khi xảy ra hỏng hóc, việc sửa
chữa hệ thống phải mất một khoảng thời gian nhất định. Giá trị trung
bình của tất cả các lần sửa chữa là MTTR. Chúng tôi giả định rằng
một hệ thống không hoạt động trong khi nó đang được sửa chữa. Do
đó, giá trị trung bình của tất cả các khoảng thời gian từ khi hoàn
thành nhiệm vụ sửa chữa đến khi xảy ra lỗi tiếp theo là MTTF. Giá
trị trung bình của khoảng thời gian giữa các lần hỏng hóc liên tiếp là
(MTBF). Các thuật ngữ MTTR, MTTF và MTBF được minh họa
trong Hình 15.1. Mối quan hệ hữu ích giữa ba chỉ số có thể được phát
biểu là MTBF = MTTF + MTTR. Có thể dễ dàng xác minh mối quan
hệ bằng cách xem xét các khoảng thời gian trong Hình 15.1.
Khi bắt đầu thử nghiệm cấp hệ thống, thường quan sát thấy một số
lượng lớn các hư hỏng với khoảng thời gian nhỏ giữa các lỗi liên
tiếp. Khi quá trình kiểm tra hệ thống tiếp tục và các lỗi thực sự được
khắc phục, khoảng thời gian giữa các lỗi liên tiếp sẽ tăng lên, do đó
đưa ra bằng chứng cho thấy độ tin cậy của sản phẩm đang tăng lên.
Bằng cách theo dõi khoảng thời gian giữa các lần hỏng hóc liên tiếp,
người ta có thể biết được độ tin cậy của hệ thống phần mềm.
15.1.4 Đếm số lỗi trong khoảng thời gian định kỳ
Thông tin hữu ích có thể được thu thập bằng cách theo dõi số lượng
lỗi tích lũy trên cơ sở định kỳ. Ví dụ: chúng tôi ghi lại số lỗi tích lũy
mỗi
Occurrences of failures Repairs performed
Start of
system operation
Time
MTTR
MTTF
MTBF
Hình 15.1 Mối quan hệ giữa MTTR, MTTF và MTBF.

tháng, vẽ biểu đồ dưới dạng biểu đồ thanh và quan sát mô hình. Việc
giám sát như vậy có thể được thực hiện trong quá trình kiểm tra hệ
thống cũng như trong khi hệ thống đang hoạt động. Trong quá trình
thử nghiệm hệ thống, việc giám sát có thể được thực hiện với tốc độ
nhanh, chẳng hạn như một lần mỗi tuần, vì số lượng lớn các lỗi được
quan sát thấy trong quá trình thử nghiệm. Các kỹ sư phát triển và
quản lý muốn quan sát sự cải thiện về độ tin cậy của hệ thống đang
được phát triển. Đối với một hệ thống đã hoạt động, việc giám sát có
thể được thực hiện một hoặc hai lần mỗi năm. Người ta có thể quan
sát thấy một số lỗi hệ thống trong quá trình hoạt động của nó vì hai lý
do. Đầu tiên, có một số lỗi còn sót lại trong hầu hết các hệ thống và
hệ thống có thể chưa được kiểm tra trong môi trường thực thi thực tế
của chúng. Thứ hai, các lỗi bổ sung có thể vô tình được đưa vào hệ
thống trong quá trình bảo trì hệ thống.
15.1.5 Cường độ lỗi
Bằng cách đếm tổng số lỗi đã quan sát được cho đến nay và vẽ biểu
đồ dữ liệu dưới dạng hàm thời gian, người ta có thể quan sát sự thay
đổi về độ tin cậy của hệ thống. Thông tin này hữu ích trong khi một
phần mềm đang được kiểm tra mức hệ thống cũng như trong khi hệ
thống đang hoạt động. Tốt nhất, mức độ tin cậy nên đạt được giá trị
ổn định sau một thời gian. Một biểu đồ tăng lên về số lỗi tích lũy cho
chúng ta biết rằng có nhiều lỗi hơn trong hệ thống và do đó hệ thống
657
được coi là không đáng tin cậy. Tốc độ tăng của biểu đồ là tốc độ mà
các lỗi đang được quan sát thấy. Nếu tỷ lệ tăng là rất nhỏ, chúng ta
biết rằng các thất bại hiếm khi được quan sát thấy.
Hai đại lượng liên quan đến lỗi thường được sử dụng để xác định độ
tin cậy của phần mềm là lỗi tích lũy, được ký hiệu bằng ký hiệu μ và
cường độ lỗi, được ký hiệu bằng ký hiệu λ . Cường độ hư hỏng được
biểu thị bằng số lần hư hỏng được quan sát thấy trên một đơn vị thời
gian. Người ta có thể coi thời gian thực hiện τ hoặc thời gian lịch t .
Trong chương này, chúng tôi xem xét thời gian thực hiện τ trong việc
mô hình hóa độ tin cậy của phần mềm. Tuy nhiên, người ta cũng có
thể sử dụng lịch thời gian. Ví dụ: nếu quan sát thấy 10 lỗi mỗi giờ
CPU, thì chúng tôi biểu thị cường độ lỗi là 10 lỗi mỗi giờ CPU.
Tương tự, nếu quan sát thấy 30 lỗi sau mỗi hai giờ, thì chúng tôi biểu
thị cường độ lỗi là 15 ( = 30/2 ) lỗi mỗi giờ CPU.
Cả μ và λ đều là hàm của thời gian. Số lỗi tích lũy μ là một hàm của
thời gian vì khi thời gian trôi qua, tổng số lỗi tăng đơn điệu. Hơn
nữa, λ là một hàm của thời gian vì ngày càng có nhiều lỗi được quan
sát và các lỗi tương ứng thực sự được sửa, chúng ta quan sát thấy số
lượng lỗi ngày càng ít hơn trên một đơn vị thời gian thực hiện. Lý
tưởng nhất là λ giảm theo τ . Tuy nhiên, trên thực tế, λ có thể là một
hàm ngẫu nhiên của τ vì các nhà phát triển có thể đưa ra nhiều lỗi
hơn trong khi cố gắng sửa một lỗi đã biết. Các đại lượng μ (τ) và λ
(τ) được giải thích như sau:
Đại lượng μ (τ) biểu thị tổng số lỗi quan sát được cho đến thời gian
thực thi τ kể từ khi bắt đầu thực thi hệ thống.
Đại lượng λ (τ) biểu thị số lỗi quan sát được trên một đơn vị thời gian
sau τ đơn vị thời gian thực hiện hệ thống từ đầu. Đại lượng này còn
được gọi là cường độ hư hỏng quan sát được tại thời điểm τ .
15.2 ĐỊNH NGHĨA VỀ ĐỘ TIN CẬY CỦA PHẦN MỀM
Với những định nghĩa này, không khó để thiết lập mối quan hệ sau
đây giữa μ (τ) và λ (τ) :
Ngược lại, nếu chúng ta biết hàm cường độ hỏng hóc, chúng ta thu
được hàm giá trị trung bình [2]:
15.2 ĐỊNH NGHĨA VỀ ĐỘ TIN CẬY CỦA PHẦN MỀM

Có hai thước đo độ tin cậy của phần mềm thường được sử dụng, đó
là xác suất hoạt động không có lỗi và cường độ lỗi. Khái niệm thất
bại là chung cho cả hai định nghĩa. Một chỉ số về bản chất là xác
suất, trong khi chỉ số kia là tuyệt đối. Hai định nghĩa không mâu
thuẫn với nhau. Thay vào đó, cả hai có thể được áp dụng đồng thời
cho cùng một hệ thống phần mềm mà không có bất kỳ sự mâu thuẫn
nào giữa chúng. Kỳ vọng của người dùng từ các hệ thống khác nhau
có thể khác nhau, và do đó sẽ hữu ích hơn nếu áp dụng một trong hai
điều đó cho một hệ thống nhất định. Trong phần sau, đầu tiên hai số
liệu được xác định, tiếp theo là các ví dụ về các ứng dụng của chúng
cho các hệ thống khác nhau.
15.2.1 Định nghĩa đầu tiên về độ tin cậy của phần mềm
Sự định nghĩa. Độ tin cậy của phần mềm được định nghĩa là xác
suất hoạt động không có lỗi của hệ thống phần mềm trong một thời
gian xác định trong một môi trường xác định.
Các yếu tố chính của định nghĩa trên về độ tin cậy như sau:
Xác suất của hoạt động không có lỗi
Khoảng thời gian hoạt động không có lỗi
Một môi trường thực thi nhất định
Độ tin cậy của phần mềm được thể hiện dưới dạng một biến ngẫu
nhiên liên tục do hầu hết các hệ thống phần mềm lớn đều có một số
lỗi không xác định và chúng có thể bị lỗi bất cứ lúc nào tùy thuộc
vào kiểu thực thi của chúng. Do đó, rất hữu ích khi biểu diễn độ tin
cậy của phần mềm như một đại lượng xác suất. Mặc dù hệ thống
phần mềm thỉnh thoảng bị lỗi, nhưng người dùng luôn quan tâm đến
việc hoàn thành nhiệm vụ của họ. Nhu cầu hoạt động không bị lỗi
trong một khoảng thời gian nhất định là rất quan trọng do thực tế là
người dùng dự định hoàn thành một tác vụ đòi hỏi một khoảng thời
gian thực hiện. Ví dụ: hãy xem xét một hệ thống phần mềm quản lý
hàng tồn kho được sử dụng bởi một cửa hàng lớn. Giả sử rằng cửa
hàng mở cửa từ 8 giờ sáng đến 8 giờ tối và họ đóng hệ thống sau giờ
làm việc của cửa hàng. Chủ cửa hàng hy vọng hệ thống kiểm kê sẽ
hoạt động trong ít nhất 12 giờ mà không xảy ra bất kỳ lỗi nào.
Người ta có thể xác định độ tin cậy của hệ thống phần mềm chạy trên
máy tính cá nhân (PC) như sau. Giả sử rằng một thư ký văn phòng
bật PC của anh ấy hoặc cô ấy mỗi sáng lúc 8h30 và tắt nó lúc 4h30
659
trước khi về nhà. Thư ký hy vọng rằng PC sẽ chạy trong tám giờ mà
không xảy ra bất kỳ lỗi nào. Nếu anh ta hoặc cô ta đến văn phòng
200 ngày trong một năm và quan sát thấy PC bị hỏng 5 lần vào
những ngày khác nhau trong một năm trong một vài năm, chúng ta
có thể nói rằng xác suất hoạt động không hỏng hóc của PC trong tám
giờ là 0,975 [ = ( 200 - 5 ) / 200].
Yếu tố thứ ba trong định nghĩa về độ tin cậy của phần mềm là môi
trường thực thi. Môi trường thực thi đề cập đến cách người dùng vận
hành hệ thống phần mềm. Không phải tất cả người dùng đều vận
hành một hệ thống phần mềm theo cùng một cách. Ví dụ, chúng ta
hãy xem xét trường hợp của một trình xử lý văn bản. Một nhóm
người dùng có thể đang xử lý các tài liệu có kích thước nhỏ, chẳng
hạn như 50 trang. Nhóm người dùng thứ hai có thể đang xử lý các tài
liệu có kích thước lớn, chẳng hạn, 1000 trang. Rõ ràng, hai nhóm
người dùng cung cấp hai môi trường thực thi khác nhau cho trình xử
lý văn bản. Ví dụ, để xử lý tài liệu có kích thước lớn, phần mềm có
khả năng gọi một phần mã của nó để quản lý không gian bộ nhớ mà
có thể không cần thiết để xử lý tài liệu có kích thước nhỏ. Ý tưởng về
cách người dùng vận hành một hệ thống dẫn đến khái niệm về môi
trường thực thi.
Khái niệm về môi trường thực thi là một phần thiết yếu của định
nghĩa về độ tin cậy của phần mềm. Hãy xem xét rằng một hệ thống
phần mềm hỗ trợ 10 chức năng khác nhau f 1 , ..., f 10 và có hai nhóm
người dùng. Một nhóm người dùng chỉ sử dụng các hàm f 1 , ..., f 7 và
nhóm thứ hai sử dụng tất cả các hàm. Cho các hàm f 1 , ..., f 7 không
bị lỗi, nhưng có lỗi trong các hàm f 8 , f 9 và f 10 . Do đó, nhóm người
dùng đầu tiên sẽ không bao giờ quan sát thấy bất kỳ lỗi nào đơn giản
bởi vì hoạt động của họ đối với hệ thống phần mềm không liên quan
đến các thành phần bị lỗi của phần mềm. Theo quan điểm của nhóm
người dùng đầu tiên, xác suất hoạt động không lỗi của phần mềm là
1,0. Mặt khác, nhóm người dùng thứ hai sẽ thỉnh thoảng quan sát
thấy lỗi tùy thuộc vào tần suất họ sử dụng các chức năng f 8 , f 9 và f 10
. Do đó, mức độ tin cậy mà nhóm người dùng thứ hai cảm nhận được
thấp hơn mức độ tin cậy của nhóm người dùng thứ nhất. Do đó, khái
niệm về môi trường thực thi là rất quan trọng đối với định nghĩa về
độ tin cậy của phần mềm. Trong phần sau của chương này, khái niệm
về hồ sơ hoạt động sẽ được thảo luận để mô tả môi trường thực thi.
15.2.2 Định nghĩa thứ hai về độ tin cậy của phần mềm
Sự định nghĩa. Cường độ lỗi là thước đo độ tin cậy của hệ thống
phần mềm hoạt động trong một môi trường nhất định.
Theo định nghĩa thứ hai, một hệ thống phần mềm có cường độ hỏng
hóc càng thấp thì độ tin cậy của nó càng cao. Để biểu thị mức độ tin
cậy hiện tại của hệ thống phần mềm, người ta chỉ cần nêu cường độ
hỏng hóc của hệ thống. Ví dụ: để một hệ thống phần mềm đang trong
giai đoạn kiểm tra hệ thống, nơi các kỹ sư kiểm tra đang quan sát các
lỗi với tỷ lệ 2 lỗi trên tám giờ thực thi hệ thống.
15.3 CÁC YẾU TỐ ẢNH HƯỞNG ĐẾN SỰ TIN CẬY CỦA
PHẦN MỀM
Sau đó, người ta có thể nêu mức độ tin cậy hiện tại của hệ thống là
0,25 lỗi mỗi giờ. Con số 0,25 lần hỏng hóc mỗi giờ nhận được bằng
cách chia 2 lần thất bại cho 8 giờ.
15.2.3 So sánh các định nghĩa về độ tin cậy của phần mềm
Định nghĩa đầu tiên về độ tin cậy của phần mềm nhấn mạnh tầm
quan trọng của một hệ thống phần mềm hoạt động mà không bị lỗi
trong một khoảng thời gian tối thiểu nhất định để hoàn thành một
giao dịch. Ở đây, độ tin cậy là thước đo phần nào trong tổng số giao
dịch mà hệ thống có thể hoàn thành thành công. Chúng ta hãy giả sử
rằng một robot tự hành được gửi đi khám phá đáy biển dưới nước và
phải mất ba ngày để hoàn thành mỗi vòng thăm dò. Trong trường
hợp này, chúng tôi cho rằng hệ thống phần mềm tích hợp trong rô bốt
dự kiến sẽ chạy ít nhất ba ngày liên tục để một vòng thăm dò được
hoàn thành thành công. Nếu một hệ thống rô bốt đã hoàn thành thành
công 99% tất cả các vòng thăm dò, chúng tôi nói rằng độ tin cậy của
hệ thống phần mềm là 0,99.
Định nghĩa thứ hai về độ tin cậy chỉ đơn giản là yêu cầu càng ít hỏng
hóc càng tốt. Một kỳ vọng như vậy có quan điểm rằng rủi ro thất bại
bất kỳ lúc nào cũng có tầm quan trọng đáng kể. Đây là trường hợp rất
phổ biến trong hoạt động của hệ thống kiểm soát không lưu trong sân
bay. Trường hợp này cũng có thể áp dụng cho hoạt động của bộ
chuyển mạch điện thoại. Theo định nghĩa này, không quan trọng hệ
thống đã hoạt động trong bao lâu mà không bị lỗi. Thay vào đó, việc
xảy ra một thất bại có ý nghĩa rất lớn. Ví dụ, việc hệ thống kiểm soát
giao thông trong sân bay bị lỗi có thể dẫn đến một thảm họa lớn.
661
15.3 CÁC YẾU TỐ ẢNH HƯỞNG ĐẾN SỰ TIN CẬY CỦA
PHẦN MỀM
Nhận thức của người dùng về độ tin cậy của hệ thống phần mềm phụ
thuộc vào hai loại thông tin, đó là (i) số lượng lỗi có trong phần mềm
và (ii) cách người dùng vận hành hệ thống. Loại thông tin thứ hai
được gọi là hồ sơ hoạt động của hệ thống. Số lượng lỗi được đưa vào
một hệ thống và việc các nhà phát triển không thể phát hiện ra nhiều
lỗi đó phụ thuộc vào một số yếu tố như được giải thích bên dưới:
Kích thước và độ phức tạp của mã: Số lượng LOC trong một hệ
thống phần mềm là thước đo kích thước của nó. Các hệ thống phần
mềm lớn với hàng trăm nghìn LOC có xu hướng có nhiều lỗi hơn các
hệ thống nhỏ hơn. Khả năng xảy ra lỗi trong một hệ thống lớn, do có
nhiều giao diện mô-đun hơn, cao hơn. Mã chứa càng nhiều câu lệnh
điều kiện thì hệ thống càng được coi là phức tạp. Do những cân nhắc
về kinh tế trong phát triển phần mềm, người ta có thể không có nhiều
thời gian để hiểu hoàn toàn một hệ thống lớn. Do đó, các lỗi được
đưa vào hệ thống trong tất cả các giai đoạn phát triển của nó. Tương
tự, trong khi loại bỏ các lỗi khỏi một hệ thống lớn, các lỗi mới có thể
được đưa vào.
Đặc điểm của quá trình phát triển: Nhiều tiến bộ đã đạt được
trong vài thập kỷ qua trong lĩnh vực kỹ thuật phần mềm. Các kỹ thuật
và công cụ mới đã được phát triển để nắm bắt các yêu cầu hệ thống,
thiết kế hệ thống phần mềm, triển khai thiết kế và kiểm tra hệ thống.
Ví dụ, các phương pháp chính thức, chẳng hạn như SDL (Ngôn ngữ
đặc tả và mô tả) và UML (Ngôn ngữ mô hình hóa hợp nhất), được sử
dụng để xác định các yêu cầu của các hệ thống phức tạp, thời gian
thực. Các kỹ thuật rà soát mã đã được phát triển để phát hiện các lỗi
thiết kế và triển khai. Các công cụ kiểm tra có sẵn để hỗ trợ các lập
trình viên trong quá trình kiểm tra cấp đơn vị và cấp hệ thống của họ.
Bằng cách phát triển một hệ thống dưới một ô kiểm soát chất lượng
lớn hơn dưới hình thức bao gồm các kỹ thuật và công cụ kỹ thuật
phần mềm ở trên, số lỗi còn lại trong hệ thống phần mềm có thể được
giảm bớt.
Giáo dục, Kinh nghiệm và Đào tạo Nhân sự: Ngành công nghệ
thông tin đã có sự phát triển vượt bậc trong khoảng 20 năm trở lại
đây. Tuy nhiên, giáo dục kỹ thuật phần mềm như một ngành học
riêng biệt ở cấp độ đại học chỉ mới xuất hiện trên quy mô lớn. Không
có gì lạ khi tìm thấy nhiều nhân sự ít được đào tạo để viết, sửa đổi và
kiểm tra mã trong các dự án lớn. Nhân sự thiếu các kỹ năng mong
muốn có thể khiến hệ thống mắc lỗi nhiều hơn.
Môi trường hoạt động: Việc phát hiện các lỗi còn lại trong hệ thống
phần mềm phụ thuộc vào khả năng của kỹ sư thử nghiệm trong việc
thực thi hệ thống trong môi trường hoạt động thực tế của nó. Nếu
một kỹ sư kiểm tra không vận hành hệ thống theo cách mà người
dùng sẽ làm, rất có thể lỗi sẽ không được phát hiện. Do đó, các kỹ sư
kiểm thử phải hiểu cách người dùng sẽ vận hành một hệ thống. Do
thiếu đủ thời gian và thiếu kinh nghiệm từ phía các kỹ sư phát triển
và thử nghiệm, các lỗi có thể được đưa vào hệ thống và những lỗi đó
có thể không được phát hiện trong quá trình thử nghiệm.
Do đó, độ tin cậy của phần mềm được xác định bởi sự kết hợp phức
tạp của một số yếu tố với các đặc điểm trên phạm vi rộng. Lý tưởng
nhất, từ quan điểm mô hình hóa, sẽ hữu ích khi có một mô hình toán
học thu nhận các tham số ảnh hưởng và cho chúng ta một giá trị cụ
thể về mức độ tin cậy của một hệ thống phần mềm. Tuy nhiên, một
mô hình lý tưởng như vậy đã không được nghĩ ra vì tính chất phức
tạp của vấn đề. Trên thực tế, các mô hình độ tin cậy được nghiên cứu
trong tài liệu xem xét một số lượng nhỏ các tham số ảnh hưởng. Mặc
dù phạm vi hạn chế của các mô hình đó, chúng tôi có được nhiều
hiểu biết sâu sắc về khái niệm phức tạp về độ tin cậy của phần mềm.
Ví dụ: các kỹ sư thử nghiệm càng thực thi một hệ thống trong quá
trình thử nghiệm cấp hệ thống, thì khả năng quan sát thấy các lỗi
càng cao. Bằng cách xác định và sửa chữa các lỗi gây ra những hỏng
hóc đó, các kỹ sư phát triển có thể cải thiện mức độ tin cậy của hệ
thống. Do đó, lượng thời gian kiểm thử ảnh hưởng trực tiếp đến mức
độ tin cậy của phần mềm. Do đó, một mô hình độ tin cậy có thể được
phát triển trong đó thời gian kiểm tra hệ thống, hay đơn giản là thời
gian, là biến số độc lập và mức độ tin cậy là biến số phụ thuộc trong
mô hình độ tin cậy. Bằng cách sử dụng mô hình như vậy, người ta có
thể dự đoán khoảng thời gian kiểm thử hệ thống cần thiết để đạt được
mức độ tin cậy phần mềm nhất định [3].
15.4 ỨNG DỤNG SỰ TIN CẬY CỦA PHẦN MỀM
15.4 ỨNG DỤNG SỰ TIN CẬY CỦA PHẦN MỀM
663
Độ tin cậy là một thước đo định lượng về khía cạnh chất lượng liên
quan đến lỗi của một hệ thống phần mềm. Một số yếu tố, như được
giải thích trong Phần 15.3, ảnh hưởng đến mức độ tin cậy của hệ
thống phần mềm. Việc đánh giá hiệu quả của các yếu tố ảnh hưởng là
điều đương nhiên.
15.4.1 So sánh các công nghệ kỹ thuật phần mềm
Để phát triển các hệ thống phần mềm chất lượng cao hơn với chi phí
hiệu quả, một số công nghệ đã được giới thiệu. Ví dụ, có rất nhiều
quy trình phát triển phần mềm, chẳng hạn như mô hình thác nước
[4], mô hình xoắn ốc [5], mô hình tạo mẫu [6], mô hình Lập trình
eXtreme [7] và mô hình Scrum [8, 9] . Về việc giới thiệu các công cụ
kiểm thử, nhiều kỹ thuật đã được nghiên cứu để tạo ra các trường
hợp kiểm thử. Một số kỹ thuật đã được giới thiệu để nắm bắt các yêu
cầu của khách hàng, chẳng hạn như sơ đồ mối quan hệ thực thể, sơ
đồ luồng dữ liệu và UML [10, 11]. Khi một công nghệ mới được
phát triển, cần phải đánh giá hiệu quả của nó trước khi hoàn toàn áp
dụng nó. Ba tiêu chí hữu ích để đánh giá một công nghệ từ quan
điểm quản lý như sau:
Chi phí áp dụng công nghệ là bao nhiêu?
Làm thế nào để công nghệ mới ảnh hưởng đến tiến độ phát triển?
Lợi nhuận từ công nghệ mới về chất lượng phần mềm là gì?
Khái niệm độ tin cậy của phần mềm có thể được sử dụng để đánh giá
một công nghệ mới về tính hữu dụng của nó trong việc cho phép các
nhà phát triển phần mềm tạo ra phần mềm chất lượng cao hơn. Ví dụ,
hãy xem xét hai công nghệ M 1 và M 2 . Nếu một ứng dụng được phát
triển bằng công nghệ M 1 để tạo ra hệ thống S 1 và công nghệ M 2
được sử dụng để tạo ra một hệ thống S 2 khác để thực hiện cùng một
ứng dụng, thì sẽ rất hữu ích khi quan sát sự khác biệt về mức độ tin
cậy của S 1 và S 2 . Bằng cách theo dõi mức độ tin cậy của hai hệ
thống S 1 và S 2 cho cùng một ứng dụng, người quản lý có thể quan
sát công nghệ nào hiệu quả hơn trong việc sản xuất các hệ thống
phần mềm có độ tin cậy cao hơn.
15.4.2 Đo lường tiến độ kiểm tra hệ thống
Đo lường tiến độ phát triển phần mềm là trọng tâm để quản lý một
dự án. Một câu hỏi quan trọng trong quản lý dự án là: Đã hoàn thành
bao nhiêu phần trăm? Câu trả lời cho câu hỏi cho chúng tôi biết liệu
tiến độ có được thực hiện theo kế hoạch hay không. Điều quan trọng
là phải theo dõi tiến trình kiểm tra hệ thống, vì nó tiêu tốn một phần
đáng kể tiền bạc và thời gian. Hai số liệu hữu ích để theo dõi tiến
trình kiểm tra cấp hệ thống như sau:
Phần trăm các trường hợp thử nghiệm được thực thi,
Phần trăm thực hiện thành công các thử nghiệm chức năng ưu tiên
cao
Khái niệm độ tin cậy của phần mềm có thể được sử dụng để đo lường
tiến độ của quá trình kiểm thử hệ thống. Ví dụ, người ta có thể theo
dõi cường độ hỏng hóc của SUT để biết hệ thống nằm ở đâu trên
thang độ tin cậy tại thời điểm này. Nếu cường độ hư hỏng hiện tại
lớn hơn nhiều so với cường độ hư hỏng có thể chịu được tại thời
điểm phát hành, chúng ta biết rằng còn nhiều việc phải làm. Mặt
khác, nếu sự khác biệt giữa cường độ hư hỏng hiện tại và cường độ
hư hỏng mong muốn là rất nhỏ, chúng ta nhận thấy rằng chúng ta đã
gần đạt được mục tiêu. Do đó, khái niệm độ tin cậy của phần mềm có
thể được sử dụng một cách khách quan để đo lường mức độ tiến bộ
đã đạt được trong kiểm thử cấp hệ thống [12, 13].
15.4.3 Điều khiển hệ thống hoạt động
Độ tin cậy của một hệ thống thường giảm do kết quả của các công
việc bảo trì. Lượng thay đổi được thực hiện đối với hệ thống càng
lớn thì mức độ tin cậy của hệ thống càng giảm. Ví dụ, giả sử rằng
một hệ thống có k số lỗi trên 1000 dòng mã khi bắt đầu kiểm tra hệ
thống. Giá trị của k có thể nhận được từ các phép đo thống kê. Bằng
cách thêm N dòng mã vào hệ thống như một phần của hoạt động bảo
trì, về mặt thống kê, Nk / 1000 lỗi được đưa vào hệ thống. Việc đưa
vào các lỗi mới sẽ làm giảm độ tin cậy của hệ thống và nó sẽ đòi hỏi
quá trình kiểm tra hệ thống kéo dài để phát hiện các lỗi và nâng cao
độ tin cậy của hệ thống bằng cách sửa các lỗi đó. Người quản lý dự
án có thể đưa ra giới hạn về số lượng thay đổi về độ tin cậy của hệ
thống đối với từng loại hoạt động bảo trì. Do đó, quy mô của một
công việc bảo trì có thể được xác định bằng mức độ tin cậy của hệ
thống có thể hy sinh trong một thời gian.
15.4.4 Hiểu rõ hơn về quy trình phát triển phần mềm
Khái niệm về độ tin cậy cho phép chúng ta định lượng khía cạnh chất
lượng liên quan đến lỗi của một hệ thống phần mềm. Việc định
lượng khía cạnh chất lượng của hệ thống phần mềm giúp các nhà
phát triển và quản lý có cái nhìn sâu sắc hơn về quá trình phát triển
665
phần mềm. Ví dụ, bằng cách quan sát cường độ lỗi khi bắt đầu thử
nghiệm hệ thống, người quản lý thử nghiệm có thể đưa ra quyết định
sáng suốt về việc kiểm tra hệ thống có thể mất bao lâu để giảm
cường độ lỗi xuống mức có thể chấp nhận được. Nói cách khác, các
nhà quản lý sẽ có khả năng đưa ra các quyết định sáng suốt.
15.5 HỒ SƠ VẬN HÀNH
Khái niệm về hồ sơ hoạt động, hoặc hồ sơ sử dụng, được phát triển

tại Phòng thí nghiệm AT&T Bell [14] và IBM [15, 16] một cách độc
lập. Như tên cho thấy, một hồ sơ hoạt động mô tả cách người dùng
thực tế vận hành một hệ thống. Hồ sơ hoạt động là một đặc điểm
định lượng về cách một hệ thống sẽ được sử dụng. Tuy nhiên, để ước
tính chính xác độ tin cậy của một hệ thống, người ta phải kiểm tra nó
bằng cách xem xét nó sẽ thực sự được sử dụng như thế nào trên thực
địa.
15.5.1 Hoạt động
Một hoạt động là một nhiệm vụ logic cấp hệ thống chính trong thời
gian ngắn, trả lại quyền kiểm soát cho trình khởi tạo khi hoạt động
hoàn tất và quá trình xử lý của nó về cơ bản khác với các hoạt động
khác. Sau đây, các đặc điểm chính của một hoạt động được giải
thích:
Chính có nghĩa là một hoạt động liên quan đến một yêu cầu chức
năng hoặc tính năng của hệ thống phần mềm.
Một hoạt động là một khái niệm logic theo nghĩa nó liên quan đến
phần mềm, phần cứng và hành động của người dùng. Các hành động
khác nhau có thể tồn tại dưới dạng các phân đoạn xử lý khác nhau.
Các phân đoạn thời gian xử lý khác nhau có thể liền kề, không liền
kề, tuần tự hoặc đồng thời.
Thời lượng ngắn có nghĩa là một hệ thống phần mềm đang xử lý
hàng trăm hoạt động mỗi giờ.
Quá trình xử lý khác biệt đáng kể có nghĩa là một hoạt động được coi
là một thực thể dưới dạng một số dòng mã nguồn và có khả năng cao
là một thực thể đó chứa một lỗi không được tìm thấy trong một thực
thể khác.
15.5.2 Trình bày hồ sơ hoạt động
Hồ sơ hoạt động của một hệ thống là tập hợp các hoạt động được hệ
thống hỗ trợ và xác suất xảy ra của chúng. Ví dụ: có ba hoạt động, cụ
thể là A, B và C, được hỗ trợ bởi một hệ thống và chúng xảy ra 50,
30 và 2% thời gian. Sau đó, hồ sơ hoạt động được biểu diễn bởi tập
hợp {(A, 0. 5 ) , (B, 0. 3 ) , (C, 0. 2 ) } . Hồ sơ hoạt động được thể
hiện theo hai cách thay thế:
Biểu diễn dạng bảng
Biểu diễn đồ họa
Biểu diễn dạng bảng của hồ sơ hoạt động Một hồ sơ hoạt động có
thể được biểu diễn dưới dạng bảng với ba cột như được thể hiện
trong Bảng 15.1. Ví dụ là về hệ thống thông tin thư viện. Cột đầu tiên
liệt kê tên của các thao tác, cột thứ hai cho biết tần suất sử dụng các
thao tác và cột cuối cùng cho biết xác suất sử dụng các thao tác.
Chúng tôi liệt kê hai loại hoạt động trả sách: trả sách đúng hạn và trả
sách trễ. Hai hoạt động liên quan đến một số xử lý riêng biệt vì sách
bị trả lại trễ có thể phải chịu một số hình phạt. Thao tác gia hạn sách
là sự kết hợp của một trong hai thao tác trả sách và thao tác kiểm tra
sách.
Biểu diễn bằng đồ thị của hồ sơ hoạt động Một hồ sơ hoạt động
cũng có thể được biểu diễn dưới dạng đồ họa như trong Hình 15.2. Ở
dạng đồ họa, một hồ sơ hoạt động được biểu diễn dưới dạng cấu trúc
cây bao gồm các nút và nhánh. Các nút đại diện cho các thuộc tính
của hoạt động và các nhánh đại diện cho các giá trị của các thuộc tính
với xác suất xuất hiện liên quan. Trong hình 15.2, bốn
BẢNG 15.1 Ví dụ về hồ sơ hoạt động của hệ thống thông tin
thư viện
Xác
Hoạt động Hoạt động mỗi giờ
suất
Sách đã được kiểm tra 450 0,45
Sách được trả lại trong thời 324 0,324
gian
Sách đã được gia hạn 81 0,081
Sách trả lại muộn 36 0,036
Sách báo bị mất 9 0,009
... ... ...
Tổng cộng 1000 1,0
667
Account
management = 0.4
2
Administration = 0.1
Reporting = 0.6
Check out = 0.5
3 Renewal = 0.09 .....

User service = 0.9
Loss = 0.01
Return = 0.4
Delayed = 0.1
4
1
In time = 0.9
Hình 15.2 Biểu diễn đồ thị hồ sơ hoạt động của hệ thống thông
tin thư viện.
các nút, cụ thể là 1, 2, 3 và 4 được hiển thị. Nút 1 đại diện cho thuộc
tính phạm vi của các hoạt động với hai giá trị, quản trị và dịch vụ
người dùng. Phạm vi của một hoạt động đề cập đến việc một hoạt
động là để quản trị hệ thống thông tin hay để cung cấp dịch vụ cho
người sử dụng. Xác suất xuất hiện của giá trị quản trị thuộc tính
phạm vi của một thao tác là 0,1 và xác suất xuất hiện của giá trị dịch
vụ người dùng là 0,9. Nút 2 đại diện cho một hoạt động quản trị,
trong khi nút 3 đại diện cho một hoạt động của người dùng. Có hai
thuộc tính của hoạt động quản trị, đó là quản lý tài khoản và báo cáo,
và xác suất xảy ra liên quan lần lượt là 0,4 và 0,6. Có bốn thuộc tính
của các hoạt động của người dùng, đó là thanh toán, gia hạn, mất mát
và trả lại, với xác suất xuất hiện liên quan của chúng là 0,5, 0,09,
0,01 và 0,4, tương ứng. Nút 4 đại diện cho một hoạt động trả về với
hai giá trị thuộc tính, cụ thể là bị trễ và trong thời gian, với xác suất
xuất hiện của chúng tương ứng là 0,1 và 0,9.
Điều hữu ích cần lưu ý là dạng bảng của hồ sơ hoạt động có thể dễ
dàng được tạo từ dạng đồ họa bằng cách xem xét tất cả các đường
dẫn có thể có trong dạng đồ họa và nhân xác suất xuất hiện trên mỗi
đường dẫn. Ví dụ: xác suất sách bị trả lại hoạt động trễ (0,036) trong
Bảng 15.1 có thể thu được từ dạng đồ họa được hiển thị trong Hình
15.2 bằng cách nhân các xác suất liên quan đến dịch vụ người dùng
(0,9), trả lại (0,4) và bị trì hoãn (0,1) .
ChooseTabularFormorGraphicalForm Có thể dễ dàng lấy được
dạng bảng của một hồ sơ hoạt động từ dạng đồ họa. Có thể dễ dàng
xác định hồ sơ hoạt động dưới dạng bảng nếu một hệ thống chỉ liên
quan đến một số lượng nhỏ hoạt động. Tuy nhiên, dạng đồ họa được
ưu tiên hơn nếu một hệ thống liên quan đến một số lượng lớn các
hoạt động. Các thao tác có thể dễ dàng được mô tả dưới dạng chuỗi
các bước xử lý nhỏ hơn sẽ phù hợp hơn với dạng đồ họa. Hơn nữa,
có thể dễ dàng xác định các thao tác bị thiếu dưới dạng đồ họa.
Sử dụng hồ sơ hoạt động trong quá trình kiểm tra hệ thống Khái
niệm về hồ sơ hoạt động được tạo ra để hướng dẫn các kỹ sư kiểm
thử lựa chọn các trường hợp kiểm thử. Tốt nhất, nên chọn ít nhất một
trường hợp thử nghiệm để thử nghiệm một hoạt động và tất cả các
hoạt động phải được đề cập trong quá trình thử nghiệm. Vì độ tin cậy
của phần mềm gắn liền với khái niệm cường độ hỏng hóc, nên một
hệ thống phần mềm có độ tin cậy tốt hơn có thể được tạo ra trong
một khoảng thời gian nhất định bằng cách thử nghiệm các hoạt động
thường xuyên hơn trước. Trong thực tế, các dự án vượt quá lịch trình
của chúng và có thể có xu hướng giao sản phẩm mà không có thử
nghiệm đầy đủ. Một hồ sơ hoạt động có thể được sử dụng để đưa ra
quyết định liên quan đến việc kiểm tra bao nhiêu và những phần nào
của hệ thống phần mềm cần được chú ý nhiều hơn. Cách các kỹ sư
kiểm thử lựa chọn các trường hợp kiểm thử để vận hành hệ thống có
thể khác đáng kể so với cách người dùng thực tế vận hành hệ thống.
Tuy nhiên, để ước tính chính xác độ tin cậy của hệ thống, hãy kiểm
tra hệ thống giống như cách nó sẽ được sử dụng thực tế trên thực địa.
Các cách sử dụng khác của cấu hình hoạt động Cấu hình hoạt
động của một hệ thống có thể được sử dụng theo một số cách trong
suốt mô hình vòng đời của một hệ thống phần mềm như sau:
Là tài liệu hướng dẫn thiết kế giao diện người dùng. Các thao tác
được sử dụng thường xuyên hơn nên dễ học và dễ sử dụng. • Đang
phát triển một phiên bản của hệ thống để phát hành sớm. Phiên bản
phát hành sớm có thể chứa các hoạt động được sử dụng thường
xuyên hơn.
669
Để xác định nơi cần thêm tài nguyên để phát triển hệ thống. Ví dụ,
nhiều tài nguyên hơn có thể được phân bổ để phát triển các hoạt động
được sử dụng thường xuyên hơn.
Là tài liệu hướng dẫn tổ chức hướng dẫn sử dụng. Ví dụ: các hoạt
động được sử dụng thường xuyên hơn được mô tả sớm hơn phần còn
lại.
15.6 MÔ HÌNH TIN CẬY
Các mô hình độ tin cậy được phát triển dựa trên các giả định sau:
Các lỗi trong chương trình là độc lập.
Thời gian thực hiện giữa các lần thất bại là rất lớn so với thời gian
thực hiện lệnh.
Không gian thử nghiệm tiềm năng bao gồm không gian sử dụng của
nó.
Tập hợp các đầu vào cho mỗi lần chạy thử nghiệm được chọn ngẫu
nhiên.
Tất cả các thất bại đều được quan sát.
Lỗi gây ra lỗi sẽ được khắc phục ngay lập tức nếu không, lỗi tái diễn
sẽ không được tính lần nữa.
Để hiểu ý tưởng về sự độc lập của lỗi trong giả thiết đầu tiên, chúng
ta có thể xem xét một ánh xạ giữa tập hợp các lỗi trong hệ thống và
tập hợp các lỗi do các lỗi gây ra. Các lỗi được cho là độc lập nếu có
mối quan hệ một-một hoặc một-nhiều giữa lỗi và lỗi. Do đó, nếu các
lỗi là độc lập và một lỗi được khắc phục, thì các lỗi đơn lẻ hoặc nhiều
lỗi tương ứng sẽ không còn được quan sát thấy nữa. Trong mối quan
hệ nhiều người, việc sửa một lỗi sẽ không loại bỏ được lỗi tương
ứng; tất cả các lỗi cần được sửa chữa để loại bỏ lỗi.
Giả thiết thứ hai liên quan đến khoảng thời gian thực thi giữa các lần
hỏng hóc cho chúng ta biết rằng hệ thống không bị lỗi quá thường
xuyên. Một hệ thống ổn định hợp lý là điều kiện tiên quyết để các mô
hình độ tin cậy có hiệu lực. Không có dự đoán có ý nghĩa nào có thể
được thực hiện nếu một hệ thống bị lỗi quá thường xuyên.
Giả định thứ ba, liên quan đến không gian thử nghiệm và không gian
sử dụng, ngụ ý rằng một hệ thống được thử nghiệm bằng cách ghi
nhớ cách nó sẽ được sử dụng. Ví dụ: hãy xem xét một hệ thống điện
thoại bao gồm ba tính năng: (i) xử lý cuộc gọi, (ii) thanh toán và (iii)
hoạt động quản trị. Giả sử rằng có 15 hoạt động cơ bản để hỗ trợ mỗi
tính năng. Mặc dù có tổng cộng 45 hoạt động, hoạt động thực tế của
hệ thống có thể tạo ra một số lượng lớn các kịch bản thực thi. Thiết
lập cuộc gọi giữa hai điện thoại là thao tác cơ bản trong nhóm xử lý
cuộc gọi và cập nhật hồ sơ khách hàng là thao tác cơ bản trong nhóm
quản trị. Hai hoạt động đó có thể được kiểm tra riêng biệt. Tuy nhiên,
có thể có nhu cầu cập nhật hồ sơ của khách hàng trong khi khách
hàng đang thực hiện cuộc gọi. Kiểm tra một tình huống hoạt động
như vậy khác với kiểm tra riêng lẻ hai hoạt động cơ bản. Tính hữu
ích của mô hình độ tin cậy phụ thuộc vào việc một hệ thống có được
kiểm tra hay không bằng cách xem xét không gian sử dụng của hệ
thống có thể được đặc trưng bởi một hồ sơ hoạt động.
Giả thiết thứ tư nhấn mạnh sự cần thiết phải chọn đầu vào thử
nghiệm một cách ngẫu nhiên. Ví dụ, đề cập đến hệ thống điện thoại
trong phần giải thích của giả định thứ ba, để kiểm tra chức năng thiết
lập cuộc gọi, chúng tôi chọn ngẫu nhiên số đích. Tính ngẫu nhiên
trong quá trình lựa chọn làm giảm bất kỳ sự thiên vị nào đối với các
nhóm dữ liệu thử nghiệm nhất định.
Giả định thứ năm liên quan đến các thất bại chỉ đơn giản cho chúng
ta biết chỉ xem xét sự khác biệt cuối cùng giữa hành vi hệ thống thực
tế và hành vi hệ thống dự kiến.
Ngay cả khi hệ thống ở trạng thái có lỗi, có thể không xảy ra lỗi hệ
thống nếu hệ thống đã được thiết kế để chịu được lỗi. Do đó, chỉ
những hư hỏng quan sát được mới được xem xét, thay vì xem xét khả
năng xảy ra hỏng hóc.
Giả định thứ sáu cho chúng ta biết cách đếm thất bại. Khi một lỗi
được quan sát thấy, người ta cho rằng lỗi tương ứng đã được phát
hiện và khắc phục. Bởi vì giả định đầu tiên rằng các lỗi là độc lập, hư
hỏng tương tự không được quan sát do một lỗi khác, không xác định.
Do đó, chúng tôi tính lỗi một lần cho dù lỗi tương ứng có được khắc
phục ngay lập tức hay không.
Chi tiết về sự phát triển của hai mô hình toán học về độ tin cậy được
trình bày. Trong hai mô hình này, cường độ lỗi như một thước đo độ
tin cậy được biểu thị dưới dạng một hàm của thời gian thực hiện. Đó
là, một biểu thức cho λ (τ) được phát triển. Các mô hình được phát
triển dựa trên ý tưởng trực quan sau: Khi chúng ta quan sát một lỗi hệ
thống khác và lỗi tương ứng được sửa, sẽ có ít lỗi còn lại trong hệ
671
thống hơn và cường độ lỗi của hệ thống sẽ nhỏ hơn với mỗi lỗi đã
được khắc phục. . Nói cách khác, khi số lượng lỗi tích lũy tăng lên,
cường độ lỗi sẽ giảm.
Trong ý tưởng trực quan ở trên, một khái niệm quan trọng là mô tả
đặc điểm của sự giảm cường độ hư hỏng như một hàm của số lượng
lỗi tích lũy. Trong chương này, hai mô hình độ tin cậy được phát
triển bằng cách xem xét hai quá trình giảm dần như sau:
Quá trình suy giảm 1: Sự giảm cường độ hư hỏng sau khi quan sát lỗi
và sửa lỗi tương ứng là không đổi. Mô hình độ tin cậy được phát
triển bằng cách sử dụng mô hình giảm cường độ hư hỏng này được
gọi là mô hình cơ bản.
Quá trình suy giảm 2: Sự giảm cường độ hư hỏng sau khi quan sát
thấy lỗi và sửa chữa lỗi tương ứng nhỏ hơn mức giảm trước đó. Nói
cách khác, việc sửa chữa một lỗi dẫn đến hỏng hóc sớm hơn làm cho
cường độ hư hỏng bị giảm đi một lượng lớn hơn so với việc sửa chữa
một lỗi gây ra hỏng hóc muộn hơn. Do đó, cường độ hư hỏng là cấp
số nhân với số lượng lỗi quan sát được. Mô hình độ tin cậy được phát
triển bằng cách sử dụng mô hình giảm cường độ hư hỏng này được
gọi là mô hình logarit.
Trong quá trình phát triển hai mô hình độ tin cậy, ký hiệu sau được
sử dụng:
μ biểu thị số lỗi trung bình được quan sát thấy.
λ biểu thị cường độ hư hỏng trung bình.
λ 0 biểu thị cường độ hư hỏng ban đầu được quan sát khi bắt đầu thử
nghiệm cấp hệ thống.
ν 0 biểu thị tổng số lỗi hệ thống mà chúng tôi dự kiến sẽ quan sát
được trong thời gian vô hạn kể từ khi bắt đầu thử nghiệm cấp hệ
thống.
θ biểu thị sự giảm cường độ hỏng hóc trong mô hình logarit. Thuật
ngữ này sẽ được giải thích kỹ hơn trong phần thảo luận về mô hình
logarit dưới đây.
Mô hình cơ bản Sự suy giảm không đổi về cường độ hư hỏng trên
mỗi lần hỏng hóc được quan sát được minh họa trong Hình 15.3,
trong đó đường thẳng thể hiện sự suy giảm hư hỏng
100
90 Initial failure intensity
80
70
Failure intensity
60
50 Basic model
40
30 Logarithmic model
20
10
0
0 100 200 300 400 500 600
Cumulative failures
Hình 15.3 Cường độ hư hỏng λ như hàm của hư hỏng tích lũy μ (
λ 0 = 9 hư hỏng trên một đơn vị thời gian, ν 0 = 500 hư hỏng, θ = 0.
0075) .
quy trình trong mô hình cơ bản. Ban đầu, cường độ hư hỏng quan sát
được là 9 lần hỏng hóc trên một đơn vị thời gian. Tổng số lỗi được
quan sát thấy trong thời gian vô hạn được giả định là 500. Khi tất cả
500 lỗi đã được quan sát và các lỗi tương ứng đã được khắc phục, sẽ
không quan sát thấy lỗi hệ thống nào nữa. Do đó, cường độ thất bại
trở thành 0 tại thời điểm chúng ta đã quan sát thấy thất bại cuối cùng.
Tốc độ giảm cường độ hư hỏng được biểu thị bằng độ dốc của đường
thẳng và bằng −λ 0 / ν 0 = - 9/500 trên một đơn vị thời gian. Đường
thẳng trong Hình 15.3 có thể được biểu diễn như sau:
Vì cả λ và μ đều là hàm của τ và λ (τ) là đạo hàm của μ (τ) , chúng ta

có
Bằng cách giải phương trình vi phân trên, chúng ta có

μ (τ) = ν 0 ( 1 - e − λ 0 τ / ν 0 )
và
λ (τ) = λ 0 e − λ 0 τ / ν 0
673
Mô hình lôgarit Đường cong trong Hình 15.3 minh họa quá trình
giảm cường độ hư hỏng trên mỗi lần hỏng hóc được quan sát trong
mô hình lôgarit. Cho dù chọn mô hình độ tin cậy nào, cường độ hư
hỏng quan sát được vẫn giữ nguyên. Do đó, trong Hình 15.3, cường
độ hư hỏng được quan sát ban đầu được chỉ ra là giống nhau, nghĩa là
9 lần hỏng trên một đơn vị thời gian, như trong mô hình cơ bản.
Tổng số lần hỏng hóc được quan sát thấy trong thời gian dài là vô
hạn. Do đó, cường độ hỏng hóc không bao giờ bằng không. Mối
quan hệ giữa cường độ hư hỏng và số lượng hư hỏng tích lũy cho
thấy rằng các lỗi được khắc phục ngay từ đầu gây ra sự giảm cường
độ hư hỏng lớn hơn so với các lỗi được khắc phục ở giai đoạn sau.
Quan điểm về việc giảm cường độ hư hỏng này phù hợp với các hệ
thống ngoài đời thực. Ví dụ, những lỗi làm cho một hệ thống bị lỗi
theo nhiều cách có khả năng biểu hiện trong các lỗi sớm hơn những
lỗi tự biểu hiện trong các lỗi ít hơn. Do đó, bằng cách sửa lỗi sớm,
người ta quan sát thấy sự sụt giảm cường độ hư hỏng lớn hơn so với
việc sửa lỗi ở giai đoạn sau.
Sự sụt giảm phi tuyến của cường độ hư hỏng trong mô hình lôgarit
được ghi lại bởi một tham số phân rã θ liên kết với một hàm số mũ
âm như được chỉ ra trong mối quan hệ sau đây giữa λ và μ :
λ (μ) = λ 0 e − θμ
Vì cả λ và μ đều là hàm của τ và λ (τ) là đạo hàm của μ (τ) , chúng ta
có thể
viết
Bằng cách giải phương trình vi phân trên, chúng ta thu được
So sánh các mô hình độ tin cậy Trong Hình 15.4, chúng tôi đã vẽ
biểu thức cho λ (τ) trong cả hai mô hình và trong Hình 15.5 là các
biểu thức cho μ (τ) . Chúng tôi đã giả định rằng cường độ lỗi ban đầu
là λ 0 = 9 lỗi trên một đơn vị thời gian trong cả hai mô hình, tổng số
lỗi được quan sát thấy trong thời gian vô hạn trong mô hình cơ bản là
ν 0 = 500 lỗi và tham số phân rã cường độ hỏng θ = 0 . 0075 trong mô
hình lôgarit.
Do đó, nếu chúng ta chọn một trong hai mô hình để áp dụng cho hệ
thống phần mềm ngoài đời thực, thì công việc tiếp theo là ước lượng
các thông số của mô hình. Điều này có thể được thực hiện bằng cách
lưu ý các trường hợp thời gian τ 1 , ..., τ k mà tại đó k lỗi đầu tiên μ (τ 1
) , ..., μ (τ k ) tương ứng xảy ra. Điều này cho chúng ta k điểm dữ liệu
(τ 1 , μ (τ 1 )) , ..., (τ k , μ (τ k )) . Sau đó, chúng tôi có thể xác định các
tham số của mô hình đã chọn để biểu đồ kết quả phù hợp với tập hợp
các điểm thực sự quan sát được. Ví dụ, chúng ta có thể sử dụng kỹ
thuật bình phương nhỏ nhất cho mục đích này.
Ví dụ Giả sử rằng một hệ thống phần mềm đang được kiểm tra mức
hệ thống. Cường độ lỗi ban đầu của hệ thống là 25 lỗi mỗi giờ CPU
và dòng điện
9
6
Failure intensity
3
Basic model
2
1 Logarithmic model
0
0 50 100 150 200 250 300 350 400
Execution time
Hình 15.4 Cường độ lỗi λ như hàm của thời gian thực hiện τ ( λ 0
= 9 lỗi trên một đơn vị thời gian, ν 0 = 500 lỗi, θ = 0. 0075) .
675
600
500
Basic model
400 Logarithmic model

Cumulative failure
300
200
100
0
0 100 200 300 400 500 600 700 800 900 1000
Execution time
Hình 15.5 Lỗi tích lũy μ như hàm của thời gian thực hiện τ ( λ 0 =
9 lỗi trên một đơn vị thời gian, ν 0 = 500 lỗi, θ = 0. 0075) .
15.7 TÓM TẮT
cường độ lỗi là 5 lần hỏng mỗi giờ CPU. Người quản lý dự án đã
quyết định rằng hệ thống sẽ chỉ được phát hành sau khi hệ thống đạt
đến mức độ tin cậy tối đa là 0,001 lỗi trên mỗi giờ CPU. Từ kinh
nghiệm, nhóm quản lý ước tính rằng hệ thống sẽ trải qua tổng cộng
1200 lỗi trong thời gian vô hạn. Tính toán thời gian kiểm tra hệ thống
bổ sung cần thiết trước khi hệ thống có thể được phát hành.
Đầu tiên, một mô hình độ tin cậy thích hợp cho hệ thống phần mềm
được chọn. Vì giả định rằng hệ thống sẽ trải qua tổng cộng 1200 lần
hỏng hóc trong thời gian vô hạn, chúng tôi sử dụng mô hình cơ bản.
Chúng ta hãy biểu thị cường độ hỏng hóc hiện tại và cường độ hỏng
hóc mong muốn tại thời điểm phát hành lần lượt là λ c và λ r . Giả sử
rằng cường độ sự cố hiện tại đã đạt được sau khi vận hành hệ thống
trong τ c giờ. Đặt cường độ hỏng hóc trong thời gian nhả λ r đạt được
sau khi thử nghiệm hệ thống trong tổng thời gian là τ r giờ.
Chúng ta có thể viết λ c và λ r là
λc = λ 0 e − λ 0 τc / ν 0 λr = λ 0 e − λ 0 τr / ν 0
Đại lượng λ r - λ c biểu thị lượng thời gian thử nghiệm hệ thống bổ
sung cần thiết để đạt được độ tin cậy
λ r tại thời điểm phát hành. Đại
lượng λ r - λ c có thể được biểu diễn
như sau:
hoặc
hoặc
⎪⎪⎩ 408 . 825 giờ
Do đó, cần phải kiểm tra hệ thống
thêm thời gian để CPU chạy thêm
408,825 giờ nữa để đạt được mức
độ tin cậy là 0,001 lỗi mỗi giờ.
15.7 TÓM TẮT
Chương này bắt đầu với phần giới thiệu các khái niệm sau: (i) lỗi và
hư hỏng, (ii) thời gian thực hiện và lịch, (iii) khoảng thời gian giữa
các lần hỏng hóc, (iv) các lỗi trong khoảng thời gian định kỳ, và (v)
cường độ hư hỏng. Với những khái niệm này, độ tin cậy của phần
mềm được xác định theo hai cách: (i) xác suất hoạt động không có lỗi
của hệ thống phần mềm trong một thời gian xác định trong một môi
trường cụ thể và (ii) cường độ lỗi như một thước đo độ tin cậy của
phần mềm.
Tiếp theo, chúng tôi thảo luận về nhận thức của người dùng về độ tin
cậy của phần mềm, điều này phụ thuộc vào hai yếu tố: (i) số lượng
lỗi có trong phần mềm và (ii) cách người dùng vận hành hệ thống,
tức là hồ sơ hoạt động của hệ thống. Số lượng lỗi được đưa vào hệ
thống và việc nhà phát triển không thể phát hiện ra nhiều lỗi đó sẽ
được thảo luận, bao gồm (i) kích thước và độ phức tạp của mã, (ii)
đặc điểm của quá trình phát triển, (iii) giáo dục, kinh nghiệm và đào
tạo của nhân sự, và (iii) môi trường hoạt động. Tóm lại, độ tin cậy
của phần mềm được xác định bởi sự kết hợp phức tạp của một số yếu
tố với các đặc điểm trên phạm vi rộng. Sau đó, chúng tôi giải thích
các ứng dụng khác nhau về độ tin cậy của phần mềm.
Sau đó, chúng tôi trình bày khái niệm về hồ sơ hoạt động do Musa
phát triển tại Phòng thí nghiệm Bell. Hồ sơ hoạt động là một đặc
điểm định lượng về cách người dùng thực tế vận hành một hệ thống.
677
Hồ sơ hoạt động được biểu diễn theo hai cách khác nhau: dạng bảng
và dạng đồ họa. Hồ sơ hoạt động có thể được sử dụng để hướng dẫn
thiết kế giao diện người dùng, xác định vị trí cần đặt nhiều tài nguyên
hơn để phát triển hệ thống, lựa chọn các trường hợp thử nghiệm và
phát triển các hướng dẫn sử dụng.
Cuối cùng, hai mô hình toán học về độ tin cậy đã được giải thích: mô
hình cơ bản và mô hình lôgarit. Trong hai mô hình này, cường độ lỗi
như một thước đo độ tin cậy được biểu thị dưới dạng một hàm của
thời gian thực hiện.
Việc đo lường độ tin cậy của các hệ thống phần mềm lớn đưa ra
những thách thức về cả kỹ thuật và quản lý. Các hệ thống phần mềm
lớn liên quan đến một số lượng lớn người dùng đồng thời, chẳng hạn
như vài nghìn người, và hầu hết chúng có thể nằm ở các vị trí địa lý
khác nhau. Một số ví dụ về hệ thống phần mềm lớn là phần mềm
kiểm soát hoạt động của mạng điện thoại di động, hệ thống mua hàng
trực tuyến và hệ thống ngân hàng, chỉ có thể kể tên một số. Các cuốn
sách của Musa, Iannino và Okumoto [7] và Musa [8] giải quyết một
số vấn đề liên quan đến độ tin cậy của phần mềm: Các vấn đề kỹ
thuật được Musa, Iannino và Okumoto giải quyết như sau:
Xác định tham số: Năm phương pháp xác định tham số, cụ thể là dự
đoán, ước lượng, xác định, công thức và / hoặc kinh nghiệm, và dữ
liệu, đã được thảo luận.
Các kỹ thuật cụ thể của dự án: Các kỹ thuật xử lý các vấn đề đặc
biệt khác nhau đã được thảo luận. Ví dụ, họ giải thích các cách để
ước tính thời gian thực hiện khi xảy ra lỗi. Một kỹ thuật dành riêng
cho dự án khác liên quan đến việc đo lường thời gian thất bại trong
nhiều lần lắp đặt.
Khái niệm về hồ sơ hoạt động đã được Musa trình bày rất chi tiết
(Kỹ thuật độ tin cậy của phần mềm, McGraw-Hill, New York, 1999).
Đặc biệt,
các hoạt động chính liên quan đến việc chuẩn bị một hồ sơ hoạt động
đã được thảo luận. Hơn nữa, việc xử lý sự phát triển của định nghĩa
hoạt động trong quá trình phát triển hệ thống đã được thảo luận.
Các khía cạnh quản lý về độ tin cậy của phần mềm đã được thảo luận
trong cuốn sách của cả Musa, Iannino, Okumoto [7] và Musa [8].
Musa, Iannino và Okumoto thảo luận về cách lập kế hoạch thực hiện
một chương trình độ tin cậy [7]. Cụ thể, các hoạt động sau đây đã
được giải thích để chạy một chương trình độ tin cậy:
Thu thập dữ liệu: Thu thập dữ liệu để phân tích độ tin cậy bao gồm
các hoạt động như dữ liệu nào cần thu thập, cách thúc đẩy người ghi
dữ liệu, cách thu thập dữ liệu dễ dàng, thu thập dữ liệu trong thời
gian thực, cung cấp kết quả và lưu trữ hồ sơ.
Sử dụng các nhà tư vấn: Các nhà tư vấn đóng một vai trò quan
trọng trong việc chuyển giao công nghệ liên quan đến kỹ thuật độ tin
cậy. Một nhà tư vấn có thể là một nhà tư vấn chuyên nghiệp bên
ngoài hoặc một cá nhân bên trong tổ chức. Bằng chuyên môn của
mình, các nhà tư vấn có tác động có giá trị trong toàn bộ tổ chức.
Musa, Iannino và Okumoto [17] trình bày thêm một số mô hình,
chẳng hạn như mô hình kiểu Poisson và mô hình kiểu nhị thức. Lyu
[19] trình bày một số mô hình độ tin cậy khác và dữ liệu lỗi thực tế
từ các hoạt động thực địa của các hệ thống phần mềm lớn.
Một phương pháp nổi bật khác tương tự như kiểm tra độ tin cậy được
gọi là kiểm tra thống kê, sử dụng mô hình thực nghiệm chính thức để
kiểm tra ngẫu nhiên theo mô hình sử dụng của phần mềm. Trong thử
nghiệm thống kê, một mô hình được phát triển để mô tả dân số sử
dụng phần mềm và mô hình được sử dụng để tạo ra một mẫu thống
kê chính xác về tất cả các mục đích sử dụng phần mềm có thể có.
Hiệu suất trên mẫu được sử dụng làm cơ sở cho các kết luận về độ tin
cậy hoạt động chung. Bạn đọc quan tâm có thể tham khảo cuốn sách
và các bài viết sau để thảo luận về chủ đề này:
Giả sử rằng một hệ thống phần mềm sẽ trải qua 150 lần hỏng hóc
trong thời gian vô hạn, cho đến nay hệ thống đã trải qua 60 lần hỏng
hóc. Cường độ lỗi ban đầu khi bắt đầu thử nghiệm hệ thống là 15 lỗi
mỗi giờ CPU. Cường độ hư hỏng hiện tại là bao nhiêu?
Giả sử rằng một hệ thống phần mềm đang trải qua các bài kiểm tra
cấp hệ thống và cường độ lỗi ban đầu là 15 lỗi mỗi giờ CPU. Tham
số phân rã cường độ hỏng hóc được tìm thấy là 0,025 cho mỗi lần
hỏng hóc. Cho đến nay các kỹ sư thử nghiệm đã quan sát thấy 60 lần
hỏng hóc. Cường độ hư hỏng hiện tại là bao nhiêu?
679
Giải thích hậu quả của việc không thỏa mãn giả định rằng không gian
thử nghiệm tiềm năng bao phủ không gian sử dụng của nó trong việc
phát triển hai mô hình độ tin cậy.
Giải thích cách xác định các tham số của mô hình cơ bản và mô hình
logarit.
Giải thích cách áp dụng khái niệm hồ sơ hoạt động cho các bài kiểm
tra hồi quy.
Giải thích cách ý tưởng về độ tin cậy của phần mềm có thể phát hiện
ra các yêu cầu còn thiếu.
Giải thích mối quan hệ giữa tính đúng đắn và các thuộc tính chất
lượng độ tin cậy của hệ thống phần mềm.
Một hệ thống phần mềm không chính xác, tức là bị lỗi, có thể được
coi là đáng tin cậy không?
Giải thích tại sao có thể không thỏa mãn một số giả định được sử
dụng trong hai mô hình độ tin cậy của phần mềm.
CHAPTER
16
TestTeamOrganization
Cuối cùng, tất cả các hoạt động kinh doanh có thể được thu gọn trong
ba từ: con người, sản phẩm và lợi nhuận. Trừ khi bạn có một đội tốt,
bạn không thể làm được gì nhiều với hai người còn lại. —LeeIacocca
16.1 NHÓM THỬ NGHIỆM
Có nhiều cách để tổ chức các nhóm kiểm tra. Không có cách nào
đúng hay sai để tổ chức các nhóm kiểm tra. Cơ cấu mà người ta chọn
sẽ ảnh hưởng đến năng suất, chất lượng, sự hài lòng của khách hàng,
tinh thần của nhân viên và ngân sách. Như chúng ta đã biết, kiểm thử
là một hoạt động phân tán, được phân phối theo thời gian và không
gian, được tiến hành trong các giai đoạn khác nhau của vòng đời phát
triển phần mềm. Các loại thử nghiệm rộng lớn khác nhau là thử
nghiệm đơn vị, thử nghiệm tích hợp, thử nghiệm hệ thống và thử
nghiệm chấp nhận. Hợp lý là có các nhóm kiểm thử khác nhau trong
một tổ chức cho mỗi giai đoạn kiểm thử của vòng đời phát triển phần
mềm. Tuy nhiên, khuyến nghị rằng các bài kiểm tra đơn vị được phát
triển và thực hiện bởi chính các nhà phát triển phần mềm, thay vì một
nhóm kỹ sư kiểm thử đơn vị độc lập. Lập trình viên phát triển một
đơn vị phần mềm nên có quyền sở hữu sản xuất phần mềm chất
lượng tốt để làm hài lòng của mình. Do đó, thay vì thành lập một
nhóm kiểm thử đơn vị, các nhà phát triển phần mềm nên được giao
trách nhiệm kiểm thử mã của riêng họ. Nhóm kiểm thử chấp nhận
được thành lập trên cơ sở nhu cầu bao gồm những người từ các nền
tảng khác nhau, chẳng hạn như kỹ sư kiểm tra tích hợp, kỹ sư kiểm
tra hệ thống, kỹ sư hỗ trợ khách hàng và kỹ sư tiếp thị. Nhóm thử
nghiệm được tháo dỡ sau khi công trình hoàn thành. Trong bất kỳ tổ
chức nào, nên có ít nhất hai nhóm thử nghiệm: nhóm thử nghiệm tích
hợp và nhóm thử nghiệm hệ thống. Trong các phần sau, chi tiết của
chúng sẽ được thảo luận.
16.1.1 Nhóm kiểm tra tích hợp
681
Kiểm thử tích hợp hệ thống, hay đơn giản, kiểm thử tích hợp, được
thực hiện bởi một nhóm kiểm tra tích hợp. Kiểm tra tích hợp yêu cầu
kiến thức kỹ lưỡng về các mô-đun
496
16.1 NHÓM THỬ NGHIỆM
và các giao diện của chúng. Vì các hệ thống lớn được tích hợp theo
cách gia tăng, có thể bằng cách sử dụng khái niệm bản dựng tăng
dần, nhân viên kiểm tra tích hợp phải rất thông thạo với ý tưởng bản
dựng. Do đó, đương nhiên là các nhà phát triển phần mềm, những
người đã cùng nhau xây dựng các mô-đun, phải tham gia vào việc
thực hiện kiểm thử tích hợp. Trên thực tế, bản thân các nhà phát triển
có thể tích hợp hệ thống. Các kiến trúc sư hệ thống cũng tham gia
vào việc kiểm tra tích hợp cho các hệ thống phức tạp vì họ đã hiểu rõ
về bức tranh toàn cảnh của hệ thống. Nhiệm vụ của nhóm này là đảm
bảo rằng các mô-đun được đơn vị kiểm tra hoạt động chính xác khi
chúng được kết hợp với nhau. Các mô-đun được kết hợp bằng cách
tuân theo cấu trúc phần mềm được xác định trong quá trình thiết kế
hệ thống. Tích hợp hệ thống được thực hiện như một phần của khái
niệm lớn hơn về phát triển hệ thống. Trưởng nhóm kiểm thử tích hợp
báo cáo cho người quản lý phát triển phần mềm. Ngoài việc tích hợp
hệ thống, nhóm thử nghiệm có thể thực hiện các nhiệm vụ khác,
chẳng hạn như kiểm tra mã, quản lý cấu hình, quản lý phát hành và
quản lý phòng thí nghiệm phát triển. Các hoạt động liên quan đến
nhóm này được mô tả trong Chương 7.
16.1.2 Nhóm kiểm tra hệ thống
Nhóm kiểm tra hệ thống là một nhóm có công việc chính là thực hiện
kiểm tra mà không có bất kỳ sự thiên vị và sợ hãi nào. Nhóm kiểm
tra hệ thống thực sự là một nhóm độc lập và nó thường có số lượng
người đứng đầu và ngân sách riêng biệt. Số lượng người đứng đầu
riêng biệt có nghĩa là mọi người được thuê và giữ lại cụ thể để thực
hiện thử nghiệm. Người đọc có thể nhớ lại rằng một số kỹ sư phát
triển đảm nhận vai trò của một kỹ sư kiểm tra tích hợp. Tuy nhiên, để
loại trừ khả năng xảy ra bất kỳ sự thiên vị nào trong kiểm thử cấp hệ
682 CHƯƠNG 16 TỔ CHỨC NHÓM KIỂM TRA
thống, nhiệm vụ được thực hiện bởi một nhóm riêng biệt chứ không
phải bởi một số thành viên của nhóm phát triển. Người quản lý của
nhóm này không báo cáo cho các nhà quản lý phát triển phần cứng
hoặc phần mềm. Đúng hơn, họ đều là đồng nghiệp ở cấp độ tổ chức.
Nhiệm vụ của nhóm này là đảm bảo rằng các yêu cầu hệ thống đã
được thỏa mãn và hệ thống có thể chấp nhận được. Nhóm kiểm thử
hệ thống tiến hành các hạng mục kiểm thử khác nhau như đã thảo
luận trong Chương 8. Để tạo điều kiện cho hệ thống cuối cùng được
khách hàng chấp nhận, nhóm thực hiện các kiểm thử chấp nhận
nghiệp vụ được xác định trong kế hoạch kiểm thử chấp nhận của
người dùng.
Nhóm kiểm tra hệ thống có thể được chia thành nhiều nhóm con tập
trung khi quy mô của một tổ chức trở nên lớn: nhóm kiểm tra phát
triển, nhóm kiểm tra hiệu suất, nhóm kiểm tra khả năng mở rộng,
nhóm kiểm tra tự động hóa và nhóm kiểm tra duy trì, như thể hiện
trong Hình 16.1. Mỗi nhóm có thể do một người quản lý trực tiếp
đứng đầu, người này lần lượt báo cáo cho người quản lý cấp cao phụ
trách nhóm thử nghiệm hệ thống. Cấu trúc nhóm kiểm tra hệ thống
phải thường xuyên được xem xét và điều chỉnh để đáp ứng các nhu
cầu thay đổi bên trong và bên ngoài. Lưu ý rằng cấu trúc của nhóm
kiểm tra hệ thống được tổ chức trên cơ sở chức năng, chứ không phải
trên cơ sở dự án. Một tổ chức lâu dài của một nhóm thử nghiệm sẽ
dẫn đến sự phát triển tốt hơn các kỹ năng của thành viên.
Để thành lập một nhóm thử nghiệm, một điều quan trọng là quy mô
của nhóm thử nghiệm hệ thống. Về cơ bản, điều này cho chúng ta
biết số lượng người nên thực hiện kiểm tra cấp hệ thống. Quy mô của
nhóm kiểm tra hệ thống ảnh hưởng đến chất lượng được cung cấp
của sản phẩm, chi phí phát triển của sản phẩm và thời gian cung cấp
sản phẩm. Tỷ lệ người thử nghiệm và nhà phát triển là một vấn đề
đang được tranh luận đáng kể. Trong thực tế, và là các giá trị
chung của tỷ lệ người thử nghiệm và nhà phát triển [1]. Một cách phù
hợp
683
Executive
management
Software System test Hardware

group group group
Integration Software
test group developers
Development Performance scalability Automation Sustaining

test group test group test group test group test group
Hình 16.1 Cấu trúc của các nhóm kiểm tra.
giá trị của tỷ lệ phụ thuộc vào bản chất của phần mềm đang được
phát triển. Giá trị của tỷ lệ được ước tính trong quá trình phát triển tài
liệu lập kế hoạch kiểm tra và nó đã được thảo luận trong Chương 12.
DevelopmentTestGroup Trọng tâm của nhóm này là thử nghiệm các
tính năng mới trong một bản phát hành cụ thể. Điều này bao gồm các
bài kiểm tra cơ bản, bài kiểm tra chức năng, bài kiểm tra độ bền, bài
kiểm tra khả năng tương tác, bài kiểm tra căng thẳng, bài kiểm tra tải
và độ ổn định, bài kiểm tra hồi quy, kiểm tra tài liệu và kiểm tra chấp
nhận kinh doanh.
Nhóm Kiểm tra Hiệu suất Nhóm này nhấn mạnh vào hiệu suất của hệ
thống. Các thử nghiệm được thực hiện để xác định các tắc nghẽn của
hệ thống và đưa ra các khuyến nghị cho các nhà phát triển để cải
thiện hiệu suất hệ thống. Nhóm sử dụng các công cụ kiểm tra, đo
lường và phân tích để thực hiện nhiệm vụ của mình. Nhóm này có
thể đảm nhận các trách nhiệm bổ sung như kiểm tra độ tin cậy.
ScalabilityTestGroup Trọng tâm của nhóm này là xác định xem hệ
thống có thể mở rộng quy mô đến các giới hạn kỹ thuật của nó hay
không. Ví dụ, một mạng điện thoại di động có thể đã được thiết kế
với một số giới hạn kỹ thuật nhất định, chẳng hạn như số lượng trạm
gốc tối đa mà nó có thể hỗ trợ, số lượng cuộc gọi đồng thời tối đa mà
nó có thể xử lý, v.v. Nhóm kiểm tra xem hệ thống được thiết kế có
thể đạt được các giới hạn đó hay không. Nhóm này có thể đảm nhận
các trách nhiệm bổ sung như kiểm tra tải và độ ổn định.
AutomationTestGroup Trách nhiệm của nhóm này là phát triển cơ sở
hạ tầng tự động hóa thử nghiệm, thư viện thử nghiệm và các công cụ
thử nghiệm. Nhóm này hỗ trợ các nhóm khác trong việc phát triển
các bộ kiểm thử tự động.
SustainingTestGroup Nhóm này duy trì chất lượng phần mềm trong
suốt vòng đời thị trường của sản phẩm. Nhóm này chịu trách nhiệm
duy trì khía cạnh khắc phục của bảo trì phần mềm. Nhóm làm việc
rất chặt chẽ với khách hàng và tiến hành kiểm tra hồi quy các phần
mềm vá lỗi.
16.2 NHÓM ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM
16.2 NHÓM ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM
Kiểm thử phần mềm là một phần của khái niệm lớn hơn về đảm bảo
chất lượng phần mềm. Kiểm tra bao gồm các quá trình tìm kiếm
khuyết tật và sửa chữa chúng. Các khiếm khuyết có thể được tìm
thấy thông qua sự kết hợp giữa kiểm tra mã và thực thi thực tế các
trường hợp thử nghiệm. Mặt khác, đảm bảo chất lượng phần mềm
không chỉ đề cập đến vị trí của các khiếm khuyết mà còn với các cơ
chế để ngăn ngừa các khiếm khuyết. Trong tiêu chuẩn IEEE 610-12-
1990 [2] đảm bảo chất lượng được định nghĩa như sau:
Một mô hình có kế hoạch và có hệ thống về tất cả các hành động cần
thiết để cung cấp đủ tin cậy rằng một mặt hàng hoặc sản phẩm phù
hợp với các yêu cầu kỹ thuật đã thiết lập
Một tập hợp các hoạt động được thiết kế để đánh giá quá trình sản
phẩm được phát triển hoặc sản xuất
Mục đầu tiên ở trên đề cập đến thử nghiệm góp phần vào chất lượng
của sản phẩm. Mục thứ hai là về bản chất thủ tục; nó bao gồm tích
cực đảm bảo cải tiến liên tục chất lượng sản phẩm. Điều này ngụ ý
rằng nhóm đảm bảo chất lượng phần mềm có vai trò lớn hơn trong
việc đảm bảo tuân thủ các thông lệ phát triển tốt nhất trong toàn tổ
chức. Một vai trò như vậy vượt ra ngoài phạm vi của một nhóm thử
nghiệm. Nhóm đảm bảo chất lượng phần mềm cần có đủ quyền hạn,
quyền lực và thường trực để làm việc với toàn bộ tổ chức trong việc
xác định các quy trình và ra lệnh cho các đồng nghiệp tuân theo các
quy trình [3]. Nhóm đảm bảo chất lượng phần mềm cần có đủ thành
viên để thực hiện công việc chuyên nghiệp và kỹ lưỡng trong việc
kiểm tra hệ thống cũng như công việc quản lý chất lượng. Khuyến
nghị có một nhóm riêng cho công việc quản lý chất lượng, như thể
hiện trong Hình 16.2, thay vì giao nhiệm vụ quản lý chất lượng cho
các kỹ sư kiểm tra hệ thống.
685
QualityManagementGroup Nhóm này hoạt động dựa trên việc tùy
chỉnh các quy trình phát triển phần mềm và đảm bảo rằng các quy
trình được tuân thủ. Nhóm chịu trách nhiệm tạo và thực hiện kế
hoạch chương trình quản lý chất lượng cho toàn bộ tổ chức bằng
cách tuân theo một khung tiêu chuẩn, chẳng hạn như mô hình chất
lượng ISO9000: 2000. Nhóm chủ động làm việc để thúc đẩy các sáng
kiến cải tiến quy trình trong toàn tổ chức. Nhóm nỗ lực tìm hiểu các
phương pháp hay nhất được áp dụng trên khắp thế giới thông qua
việc đo điểm chuẩn có hệ thống và kết hợp các phương pháp này với
phương pháp hiện có trong tổ chức. Nhóm có thể đảm nhận các trách
nhiệm bổ sung để triển khai
Quality assurance
group
Quality Management
System test group
group
Hình 16.2 Cấu trúc của nhóm đảm bảo chất lượng phần mềm.
thu thập, theo dõi và báo cáo tự động các chỉ số liên quan đến phát
triển sản phẩm, thử nghiệm và quản lý dự án.
Kiểm soát chất lượng là một thuật ngữ khác thường được sử dụng
trong tài liệu. Kiểm soát chất lượng được định nghĩa trong tiêu chuẩn
IEEE 610 [2] là một tập hợp các hoạt động được thiết kế để đánh giá
chất lượng của các sản phẩm được phát triển hoặc sản xuất. Thuật
ngữ này được sử dụng trong môi trường sản xuất hoặc sản xuất phần
cứng, nơi một số lượng lớn các mặt hàng vật chất được sản xuất và
vận chuyển. Mỗi mặt hàng đều phải trải qua một quá trình kiểm tra
để đảm bảo rằng chất lượng của sản phẩm đủ tốt để xuất xưởng; nếu
không, mặt hàng bị từ chối. Việc kiểm tra chất lượng được tiến hành
bởi nhóm kiểm soát chất lượng trong tổ chức sản xuất và người tiến
hành kiểm tra được gọi là kiểm soát viên chất lượng.
16.3 ĐỘI NGŨ KIỂM TRA HỆ THỐNG
Năm loại nhóm con trong nhóm kiểm tra hệ thống của một tổ chức
đã được xác định trong Phần 16.1.2. Mỗi nhóm con được tổ chức
theo kiểu phân cấp do người quản lý thử nghiệm đứng đầu. Quy mô
của một nhóm con thử nghiệm có thể tăng lên tối đa 12 kỹ sư thử
nghiệm. Một nhóm con có hơn 12 thành viên có thể được chia thành
hai nhóm con để quản lý tốt hơn. Các thành viên của một nhóm con
bao gồm các nhà lãnh đạo kỹ thuật, kỹ sư chính, kỹ sư cao cấp và kỹ
sư cấp dưới như được mô tả trong Hình 16.3.
Nhiệm vụ của các thành viên trong nhóm là khác nhau giữa các
nhóm con. Vai trò và trách nhiệm của từng thành viên trong nhóm
phải được xác định rõ ràng. Sau đây, chúng tôi đưa ra mô tả ngắn gọn
về vai trò và trách nhiệm của từng loại thành viên trong nhóm phổ
biến đối với hầu hết các tổ chức:
Người quản lý kiểm thử: Người quản lý của một nhóm con kiểm
thử là người chủ chốt phụ trách tất cả các khía cạnh của nhiệm vụ
kiểm thử được giao. Người quản lý lãnh đạo nhóm bằng cách làm
việc với các nhóm con thử nghiệm khác để thực hiện các chức năng
thử nghiệm nhằm đảm bảo rằng các sản phẩm chất lượng cao được
phát hành. Các trách nhiệm hành chính
Test
manager
Technical leader 1
Technical leader 2, ...
Principal engineer 1
Principal engineer 2, ...
Senior engineer 1
Senior engineer 2, ...
Junior engineer 1
Junior engineer 2, ...
Hình 16.3 Hệ thống phân cấp nhóm kiểm thử.
16.4 NHÂN VIÊN HIỆU QUẢ CỦA KỸ SƯ THỬ NGHIỆM
của một nhà quản lý bao gồm quản lý ngân sách, tuyển dụng nhân sự,
giao nhiệm vụ, đào tạo nhân sự, phát triển sự nghiệp của họ và xem
xét hiệu suất của họ. Các trách nhiệm kỹ thuật của người quản lý
kiểm thử bao gồm (i) phát triển kế hoạch kiểm tra, thực hiện kế
hoạch kiểm tra và xử lý các khủng hoảng; (ii) phát triển, tuân theo và
cải tiến các quy trình kiểm tra; và (iii) xác định, thu thập và phân tích
các chỉ số. Người quản lý chủ động trong việc cải thiện con người,
năng suất và quy trình. Người quản lý được mong đợi có thể làm việc
với các nhóm thử nghiệm khác trong công ty cũng như tổ chức thử
nghiệm khách hàng. Một nhóm thử nghiệm cụ thể có thể được đặt ở
những nơi khác nhau và thậm chí cả những quốc gia khác nhau.
687
Người quản lý kiểm tra hoạt động như một điểm nút giữa quản lý cấp
trên, quản lý dự án, quản lý chất lượng và những người tiếp thị.
Kỹ sư cấp cơ sở: Các kỹ sư thử nghiệm mới, chưa có kinh nghiệm
được đưa vào cấp độ cơ sở. Họ có được kinh nghiệm bằng cách hỗ
trợ các kỹ sư cấp cao và chính phụ trách việc thực hiện thử nghiệm,
thiết lập các giường thử nghiệm và phát triển các tập lệnh để tự động
hóa thử nghiệm. Họ cũng có thể được yêu cầu kiểm tra hướng dẫn sử
dụng, tính năng trợ giúp trực tuyến và giao diện người dùng đồ họa.
Kỹ sư cao cấp: Các kỹ sư cao cấp thiết kế, phát triển và thực hiện
các trường hợp thử nghiệm. Họ thiết kế và thiết lập các phòng thí
nghiệm và môi trường thử nghiệm. Các kỹ sư cấp cao hỗ trợ các nhà
phát triển phần mềm trong việc tái tạo các khiếm khuyết đã biết. Họ
tham gia vào các cuộc họp đánh giá kế hoạch thử nghiệm và hỗ trợ
bảo trì các phòng thí nghiệm thử nghiệm, bộ thử nghiệm tự động và
các công cụ thử nghiệm. Các công cụ kiểm tra bao gồm một hệ thống
theo dõi lỗi và một nhà máy kiểm tra.
Kỹ sư chính: Các kỹ sư chính là các chuyên gia thử nghiệm chịu
trách nhiệm lập kế hoạch thử nghiệm, tự động hóa thử nghiệm, lập kế
hoạch môi trường thử nghiệm, phát triển công cụ thử nghiệm, mua
sắm thiết bị thử nghiệm, mô hình hóa hiệu suất, kỹ thuật độ tin cậy
và thử nghiệm chấp nhận kinh doanh. Ngoài ra, các kỹ sư chính thực
hiện các trường hợp kiểm thử và cố vấn cho các kỹ sư cấp dưới trong
nhóm.
Các nhà lãnh đạo kỹ thuật: Một nhà lãnh đạo kỹ thuật thường cần
phối hợp nhiệm vụ của nhiều kỹ sư làm việc trong các dự án phức
tạp. Ở cấp độ này, kỹ sư cần có kỹ năng kiểm tra kỹ thuật của một kỹ
sư chính cũng như kỹ năng đàm phán, kỹ năng quản lý quy trình và
dự án, và kỹ năng giao tiếp. Trưởng nhóm kỹ thuật cung cấp định
hướng chiến lược cho kiểm thử phần mềm, hỗ trợ người quản lý
kiểm thử thu thập các chỉ số kiểm tra, điều phối các cuộc họp xem
xét kế hoạch kiểm tra, tham dự các cuộc họp đánh giá tiêu chí đầu
vào / ra và tham gia vào các cuộc họp đánh giá chức năng chéo như
xem xét yêu cầu, đánh giá đặc tả chức năng và lựa chọn tiêu chí vào /
ra.
Thiết kế các trường hợp kiểm thử để tiết lộ các khiếm khuyết trong
một hệ thống phức tạp là một nhiệm vụ đầy thách thức. Người ta có
thể không nhận được nhiều sự hài lòng từ việc thiết kế các trường
hợp thử nghiệm như khi thiết kế một hệ thống. Tuy nhiên, việc thiết
kế các trường hợp kiểm thử để phát hiện ra các khiếm khuyết trong
hệ thống chắc chắn là một công việc khó khăn. Tài năng kỹ thuật thử
nghiệm đỉnh cao không chỉ là mong muốn mà còn là điều cần thiết để
tạo ra các sản phẩm chất lượng cao. Một kỹ sư kiểm tra chất lượng
kém có thể gây ra nhiều thiệt hại về mặt báo cáo dương tính giả và
âm tính giả. Quy trình tuyển dụng nên tập trung vào việc không bao
giờ để xảy ra tình trạng phù hợp xấu, ngay cả khi điều đó có nghĩa là
vô tình từ chối một số phù hợp tốt. Người ta phải nhớ câu nói, bạn
chỉ có thể tốt như người của bạn. Một nhà lãnh đạo phải đặt ra tiêu
chuẩn cá nhân cho đội ngũ kỹ sư thử nghiệm giỏi nhất, phát triển họ
một cách đầy đủ và để họ tận dụng các cơ hội.
Trưởng nhóm phải có một bức tranh rõ ràng về kinh nghiệm và kỹ
năng cần thiết cho một vị trí thử nghiệm. Sẽ rất hữu ích khi ghi nhớ
các đặc điểm năm-C được Bill Hetzel [4] xác định mà một kỹ sư thử
nghiệm giỏi phải có.
Có kiểm soát: Một kỹ sư thử nghiệm phải có tổ chức, kỷ luật và
phương pháp trong công việc của mình.
Toàn diện: Một kỹ sư kiểm thử phải rất chú ý đến các chi tiết [5].
Cân nhắc: Một kỹ sư kiểm thử phải có các kỹ năng tốt giữa các cá
nhân như khả năng xử lý hành vi hung hăng, không dễ bị xúc phạm,
dễ uốn nắn, và cuối cùng, đưa các tình huống đi đến kết thúc đôi bên
cùng có lợi.
Tối quan trọng: Một kỹ sư kiểm thử phải rất giỏi trong phân tích và
tính quyết đoán. Tính quyết đoán thường bao gồm kiên trì, sử dụng
nhiều phương pháp lắng nghe phản xạ để xác định chính xác những
gì đang được truyền đạt.
Năng lực: Một kỹ sư kiểm tra phải biết các kỹ thuật kiểm tra, công
cụ, công nghệ và kiến thức miền có thể được sử dụng để thực hiện
công việc một cách hiệu quả.
Ngoài các đặc điểm năm-C, các kỹ sư thử nghiệm phải có các kỹ
năng sau [6] như một phần năng lực của họ để trở thành chuyên gia
thử nghiệm thành công:
Có uy tín với các nhà phát triển phần mềm
689
Hiểu thuật ngữ của nhà phát triển
Biết khi nào mã sẵn sàng để thử nghiệm
Có thể đánh giá tác động của một vấn đề đối với khách hàng
Hỗ trợ các nhà phát triển phần mềm trong quá trình giải quyết lỗi
Giảm kết quả dương tính giả và âm tính giả trong thử nghiệm
Phát triển kiến thức chuyên môn về tự động hóa thử nghiệm
Cố vấn cho các kỹ sư kiểm tra cơ sở
Một nhóm thử nghiệm thành công bao gồm các thành viên có sức
mạnh bổ sung cho nhau. Cần phải cố gắng tránh việc thuê các kỹ sư
kiểm tra, những người là hình ảnh phản chiếu của nhân viên hiện tại
hoặc của chính bạn. Nếu không, nhóm sẽ bị hạn chế về kỹ năng và
quan điểm hạn chế. Đội ngũ phải được cân bằng tốt với những người
có nhiều kỹ năng khác nhau. Cần có kinh nghiệm và khả năng kỹ
thuật tốt. Do đó, chúng tôi khuyên bạn nên có những người trong
nhóm thử nghiệm với
nền tảng và kinh nghiệm đa dạng, chẳng hạn như nhà phát triển,
người kiểm tra tích hợp, quản trị viên công nghệ thông tin, nhân viên
hỗ trợ kỹ thuật, người viết kỹ thuật, nhân viên quản lý chất lượng, kỹ
sư kiểm tra có kinh nghiệm và sinh viên mới tốt nghiệp. Vai trò của
những người có hoàn cảnh đa dạng như vậy được giải thích như sau.
Nhà phát triển: Chuyên môn của nhà phát triển về thiết kế hệ thống,
mã hóa và kiểm thử đơn vị rất hữu ích trong việc trở thành kỹ sư
kiểm thử hiệu quả. Để giao tiếp hiệu quả với các nhà phát triển phần
mềm, các kỹ sư kiểm thử phải sử dụng vốn từ vựng của họ, chẳng
hạn như đối tượng, lớp, kế thừa, đa hình, biến, con trỏ, cấu trúc, v.v.
để có uy tín với nhóm phát triển phần mềm. Kinh nghiệm phát triển
mã rất hữu ích khi một kỹ sư kiểm thử tham gia vào việc xem xét mã.
Một lý do khác để các kỹ sư kiểm thử có kinh nghiệm phát triển là có
thể tự động hóa các bài kiểm tra mà không gặp nhiều vấn đề. Tiêu
chí quan trọng trong việc tuyển dụng là phát triển năng lực và hiệu
quả trong dài hạn, dự đoán nhu cầu nhân sự và những thách thức mà
một người sẽ phải đối mặt trong tương lai. Về lâu dài, tự động hóa
các bài kiểm tra là một hoạt động quy trình then chốt để một tổ chức
kiểm tra thành công. Do đó, tốt hơn là nên nhân viên một nhóm kiểm
thử với nhân viên có nhiều kinh nghiệm viết mã.
Người kiểm tra tích hợp: Các kỹ sư kiểm tra tích hợp có kinh
nghiệm là một tài sản trong nhóm kiểm tra hệ thống. Khi một kỹ sư
kiểm tra tích hợp gặp lỗi, anh ta hoặc cô ta ở vị trí tốt hơn để xác
định khu vực mà vấn đề có thể tồn tại và hỗ trợ các nhà phát triển
tiến hành giải quyết lỗi. Nó tiết kiệm nhiều thời gian cho các nhà
phát triển vì họ không phải cố gắng tái tạo (các) vấn đề. Các kỹ sư
kiểm tra có kinh nghiệm kiểm tra tích hợp ở một vị trí tốt hơn để biết
khi nào mã sẵn sàng cho kiểm tra cấp hệ thống.
Công nghệ Thông tin: Quản trị viên công nghệ thông tin (CNTT)
rất am hiểu về cấu hình; thiết lập bộ định tuyến, máy chủ và tường
lửa; và xử lý sự cố. Ngoài ra, họ biết về các loại công cụ khác nhau
có sẵn trên thị trường. Các kỹ sư thử nghiệm có kinh nghiệm CNTT
có thể dễ dàng thiết lập môi trường thử nghiệm và duy trì các phòng
thí nghiệm thử nghiệm.
Nhân viên hỗ trợ kỹ thuật: Các kỹ sư hỗ trợ khách hàng thường là
những người kiểm tra giỏi, đặc biệt trong việc thực hiện các bài kiểm
tra cấp cao như kiểm tra nghiệm thu. Họ ở vị trí để đánh giá tác động
của một khiếm khuyết đối với khách hàng. Kiến thức của họ về các
chức năng kinh doanh và sự tương tác với nhiều khách hàng khác
nhau khiến họ trở nên vô giá đối với một nhóm thử nghiệm.
viết kỹ thuật: Một trong những nhiệm vụ của kỹ sư kiểm thử hệ
thống là xem qua tất cả các hướng dẫn sử dụng, hướng dẫn sử dụng,
hướng dẫn khắc phục sự cố và ghi chú phát hành. Do đó, sẽ rất hữu
ích nếu có những người viết kỹ thuật trong một nhóm thử nghiệm để
thực hiện các bài kiểm tra tài liệu. Ý tưởng khi thực hiện kiểm tra tài
liệu là đảm bảo rằng tất cả tài liệu của người dùng là chính xác và có
thể sử dụng được. Hơn nữa, chúng có thể hữu ích trong việc thực
hiện kiểm tra khả năng sử dụng và giao diện người dùng đồ họa.
Kỹ sư kiểm tra hệ thống: Sẽ hiệu quả và hiệu quả khi thuê các
chuyên gia kiểm tra đã được đào tạo, chẳng hạn như, bởi một công ty
khác, về kỹ thuật kiểm tra, công cụ, công nghệ và kiến thức miền.
Một kỹ sư kiểm thử có kinh nghiệm biết các chiến lược và kỹ thuật
kiểm tra khác nhau được sử dụng để tìm ra nhiều khiếm khuyết hơn
với ít nỗ lực hơn, bao gồm hiểu biết thấu đáo về kiến trúc hệ thống và
chức năng của chúng, ngôn ngữ lập trình, cấu trúc mã và triển khai.
Đây cũng là một cách tốt để có được kiến thức chuyên môn về các
công cụ kiểm tra cụ thể và kiến thức miền.
691
Sinh viên tốt nghiệp gần đây: Người ta có thể thuê những sinh viên
tốt nghiệp ngành kỹ thuật gần đây làm kỹ sư thử nghiệm cơ sở và đào
tạo họ theo cách mà người ta muốn. Họ rất háo hức, nhiệt tình và sẵn
sàng học hỏi thêm về thử nghiệm. Họ giỏi trong việc phát triển các
công cụ kiểm thử và tự động hóa các trường hợp kiểm thử. Sinh viên
mới tốt nghiệp cần sự cố vấn từ một kỹ sư kiểm thử cao cấp để làm
việc hiệu quả.
16.5 TUYỂN DỤNG KỸ SƯ THỬ NGHIỆM
Phỏng vấn là cách đánh giá chính của các ứng viên trong quá trình
tuyển dụng. Một người phải có kỹ năng tốt trong việc xác định điểm
mạnh và điểm yếu của một ứng viên. Tuy nhiên, phỏng vấn là một kỹ
năng được cải thiện cùng với thực hành. Những đặc điểm sau đây tạo
nên một người phỏng vấn xuất sắc:
Người phỏng vấn nên chuẩn bị trước.
Người phỏng vấn phải là người biết lắng nghe.
Người phỏng vấn phải tập trung vào việc đặt câu hỏi và thăm dò.
Người phỏng vấn cần ghi lại chính xác đánh giá của mình về ứng
viên trong buổi phỏng vấn.
Sẽ có hiệu quả nếu tạo cơ hội cho ứng viên đặt câu hỏi.
Sẽ hiệu quả khi tập trung vào các yêu cầu cụ thể của công việc cần
điền chứ không phải vào sơ yếu lý lịch.
Sẽ rất hữu ích nếu đánh giá một người nộp đơn dựa trên các dữ kiện
và dữ liệu, chứ không phải là “cảm giác ruột thịt” của một người.
Một quy trình tuyển dụng phải được thực hiện để có hiệu quả trong
việc thuê các kỹ sư thử nghiệm xuất sắc. Sáu giai đoạn đơn giản
được khuyến nghị nên thực hiện trong việc bố trí nhân sự cho nhóm
kiểm tra hệ thống, như được minh họa trong Hình 16.4.
16.5.1 Tuyển dụng việc làm
Bước đầu tiên trong việc tuyển dụng là nhận được sự chấp thuận của
ban quản lý điều hành, điều này đôi khi được gọi là có “số yêu cầu”.
Số yêu cầu có nghĩa là vị trí đã được phê duyệt bởi giám đốc tài
chính (CFO) của tổ chức. Mẫu đơn yêu cầu, thường có sẵn từ bộ
phận nhân sự, được điền và nộp cho giám đốc điều hành
Job requisition
Job profiling
Screening
resumes
Coordinating
interview team
Interviewing
Decision making
Hình 16.4 Sáu giai đoạn của quy trình tuyển dụng hiệu quả.
quản lý để phê duyệt. Các thông tin sau được cung cấp trong đơn
đăng ký: chức danh, mức lương và lý do. Người quản lý tuyển dụng
cần giải thích lý do tại sao và cho dự án thử nghiệm nào mà vị trí này
đang được tạo và giải thích tác động nếu vị trí này không được lấp
đầy. Mức lương có thể thay đổi tùy thuộc vào vị trí thử nghiệm, kinh
nghiệm và trình độ học vấn của ứng viên. Do đó, bạn nên đặt một
phạm vi, thay vì một con số chính xác. Tất nhiên, mức lương phải
dựa trên các hướng dẫn khuyến nghị do bộ phận nhân sự cung cấp.
Khuyến nghị có một số lượng yêu cầu cho vị trí thử nghiệm từ nguồn
nhân lực trước khi thực hiện bước tiếp theo trong quy trình tuyển
dụng.
16.5.2 Hồ sơ công việc
Trong hoặc sau giai đoạn trưng cầu, người ta xác định các yêu cầu cụ
thể, còn được gọi là hồ sơ công việc, của công việc sẽ được điền. Tại
thời điểm này, rất hữu ích khi ghi nhớ nguyên tắc: nếu bạn không
biết những gì bạn đang tìm kiếm, bạn sẽ không tìm thấy nó. Hồ sơ
việc làm phục vụ hai mục đích: (i) để các nhà tuyển dụng đăng tuyển
ở nhiều nơi khác nhau như cổng thông tin nghề nghiệp, hội chợ việc
làm, báo chí, và bộ phận tuyển dụng nhà nước và (ii) như một định
nghĩa chính thức về vai trò và trách nhiệm của nhân viên mới có thể
được sử dụng khi ứng viên được phỏng vấn. Hồ sơ công việc chứa
các thông tin sau:
Chức vụ
Nhiệm vụ và trách nhiệm thiết yếu
Kỹ năng và năng lực
Trải qua
693
Giáo dục, đào tạo, chứng chỉ, các biện pháp bảo mật (nếu được yêu
cầu)
16.5.3 Sàng lọc hồ sơ
Hồ sơ xin việc đến từ các nguồn khác nhau, bao gồm giới thiệu của
nhân viên, quảng cáo, hội chợ việc làm, cổng thông tin nghề nghiệp,
bảng việc làm đại học và cơ quan. Đánh giá hồ sơ so với hồ sơ công
việc không chậm trễ. Xác định các ứng viên đủ tiêu chuẩn bằng cách
giải quyết ba câu hỏi quan trọng sau:
Ứng viên có đủ kinh nghiệm và kỹ năng cần thiết để thực hiện công
việc không?
Động lực của ứng viên để thực hiện công việc là gì và liệu ứng viên
có phù hợp với văn hóa công ty hay không?
Ứng viên sẽ thực hiện công việc như thế nào?
Sơ yếu lý lịch của một ứng viên có khả năng trả lời câu hỏi đầu tiên.
Đối với hai câu hỏi còn lại, người ta có thể đặt lịch phỏng vấn với
ứng viên. Để cắt giảm chi phí và tiết kiệm thời gian, ý tưởng về một
cuộc phỏng vấn qua điện thoại đang được nhiều người quan tâm.
Cuộc phỏng vấn qua điện thoại sẽ tiếp tục không bị gián đoạn trong
30 phút và được ghi lại. Người ta có thể đặt những câu hỏi mở về
hành động trong quá khứ của ứng viên để khám phá hành vi của họ
và động lực đằng sau họ. Ví dụ về câu hỏi mở là: Hãy cho tôi biết về
một hoặc hai lỗi bạn đã báo cáo và cách bạn xác minh các bản sửa
lỗi. Một câu hỏi mở khác là: Động lực của bạn để làm loại công việc
này là gì?
Tại thời điểm này, rất hữu ích để nhớ lại các đặc điểm năm-C. Một
câu hỏi ví dụ khám phá đặc tính được kiểm soát là: Bạn có thể cho
tôi biết về một dự án cụ thể mà bạn đã có hàng triệu chi tiết không?
Một câu hỏi khám phá khả năng thăm dò của người nộp đơn là: Bạn
sử dụng phương pháp nào để theo dõi tất cả các khiếm khuyết mà
bạn cần xác minh? Vào cuối cuộc sàng lọc qua điện thoại, ứng viên
nên được phép đặt câu hỏi. Việc tuyển dụng là một con đường hai
chiều, có nghĩa là người quản lý bài kiểm tra tuyển dụng và ứng viên
cần phát triển sự tôn trọng lẫn nhau. Vào cuối cuộc kiểm tra qua điện
thoại, người ta sẽ có câu trả lời cho cả ba câu hỏi. Nếu câu trả lời cho
bất kỳ câu hỏi nào trong ba câu hỏi không tích cực, hồ sơ xin việc
nên được đặt sang một bên và kết thúc cuộc phỏng vấn. Nếu không,
một cuộc phỏng vấn tại chỗ với ứng viên nên được lên lịch.
16.5.4 Điều phối nhóm phỏng vấn

Phương pháp sử dụng nhiều người phỏng vấn giúp giảm sự thiên vị
cá nhân, sử dụng hiệu quả thời gian của từng người phỏng vấn và cho
phép thu thập thông tin chuyên sâu về ứng viên. Các nguyên tắc sau
có thể giúp làm cho quá trình phỏng vấn nhóm hiệu quả:
Một người điều phối quá trình phỏng vấn nhóm.
Quy mô nhóm có thể thay đổi từ ba đến sáu, và ít nhất một thành
viên phải từ một nhóm khác, chẳng hạn như phát triển phần mềm
hoặc hỗ trợ khách hàng. Các nhà quản lý khác có thể được đưa vào
nhóm để phỏng vấn các kỹ sư chính, trưởng nhóm kỹ thuật hoặc các
ứng viên quản lý.
Đưa cho mỗi người phỏng vấn một bản sao hồ sơ công việc và sơ
yếu lý lịch của ứng viên. Điều này sẽ đảm bảo rằng những người
phỏng vấn biết về lý lịch của ứng viên trước cuộc họp và những gì
cần tìm khi họ phỏng vấn.
Chỉ định cho mỗi người phỏng vấn một khía cạnh khác nhau của
công việc để mỗi người có thể tập trung vào một lĩnh vực cụ thể. Ví
dụ, một người có thể lấy thông tin
về kỹ năng kỹ thuật, kỹ năng khác về kỹ năng chuyên môn và thứ ba
về hành vi của ứng viên. Một số chồng chéo trong các lĩnh vực được
chỉ định của họ sẽ cho nhiều hơn một góc nhìn về mỗi lĩnh vực kỹ
năng.
Yêu cầu mỗi người phỏng vấn sử dụng một đề cương tiêu chuẩn
chứa các câu hỏi tập trung vào hành vi và thành tích trong quá khứ
của ứng viên trong lĩnh vực được đánh giá. Quyết định người phỏng
vấn sẽ nói với người nộp đơn về các khía cạnh khác nhau của công
việc và tổ chức kiểm tra để những người phỏng vấn không lặp lại
hoặc mâu thuẫn với nhau. Hẹn người phỏng vấn đó là người đầu tiên
gặp ứng viên.
Sau cuộc phỏng vấn, yêu cầu mỗi người phỏng vấn đánh giá ứng
viên về khía cạnh mà họ được chỉ định.
16.5.5 Phỏng vấn
Người ta phải nhớ rằng phỏng vấn là một quá trình thu thập thông tin
về ứng viên. Thông tin thu thập được dùng để đánh giá ứng viên
ngay sau buổi phỏng vấn. Đặt câu hỏi và thăm dò là hai khía cạnh
quan trọng của một cuộc phỏng vấn. Sau khi hỏi đúng câu hỏi, người
phỏng vấn nên giữ im lặng để cho phép ứng viên hình thành câu trả
695
lời và nên lắng nghe cẩn thận. Một câu hỏi tiếp theo sẽ giúp hiểu và
đánh giá mức độ chuyên sâu trong kinh nghiệm của ứng viên. Cung
cấp các ví dụ và thời gian để suy nghĩ sẽ giúp ứng viên đưa ra câu trả
lời. Người phỏng vấn có trách nhiệm cung cấp một môi trường đáng
nhớ. Để nâng cao hiệu quả của cuộc phỏng vấn, người được phỏng
vấn có thể thực hiện theo các bước sau:
Giới thiệu bản thân và vị trí của bạn để cuộc phỏng vấn bắt đầu nhẹ
nhàng.
Nếu bạn là người phỏng vấn đầu tiên, hãy giải thích các khía cạnh
khác nhau của công việc và tổ chức kiểm tra.
Đặt câu hỏi đầu tiên dựa trên lĩnh vực được chỉ định cụ thể cần được
khám phá. Ghi chú bằng cách diễn giải những gì đã nói. Thăm dò
cho đến khi bạn có được sự hiểu biết chính xác.
Đặt câu hỏi tiếp theo và thăm dò cho đến khi bạn hiểu rõ. Tương tự,
hãy đặt nhiều câu hỏi hơn.
Mời ứng viên đặt một vài câu hỏi.
Kết thúc cuộc phỏng vấn và giới thiệu ứng viên với người phỏng vấn
tiếp theo.
Hoàn thành đánh giá ngay sau khi phỏng vấn.
Trong cuộc phỏng vấn, hãy nhắm đến tỷ lệ nói chuyện của ứng viên
với người phỏng vấn là 80/20. Thể hiện năng lượng và thể hiện sự
nhiệt tình đối với công việc mà ứng viên đang được phỏng vấn. Hãy
chính xác với ngôn ngữ và ngắt lời ứng viên bằng các cụm từ “Tôi
hiểu”, “Tôi đồng ý” hoặc “Tôi đánh giá cao”. Xây dựng câu hỏi là
một khía cạnh quan trọng của một cuộc phỏng vấn thành công. Do
đó, hãy chuẩn bị sẵn một bảng câu hỏi trước khi phỏng vấn. Sau đây,
chúng tôi cung cấp một số câu hỏi mẫu theo từng chiều của đặc điểm
năm-C.
Tỉ mỉ và kỹ lưỡng:
Bạn có thể cho tôi biết về một dự án thử nghiệm cụ thể mà bạn đã có
một số lượng lớn chi tiết không? (Thăm dò) Bạn đã tổ chức chúng
như thế nào?
Hệ thống hóa và ngăn nắp:
Bạn làm gì để giữ cho mình đúng với các cam kết và ưu tiên của
mình?
Bạn có phương pháp nào để theo dõi những gì bạn đã đồng ý với
khách hàng hoặc đồng nghiệp?
Đáng tin cậy và đáng tin cậy:

Kể cho tôi nghe về một dự án nhóm mà bạn đã làm việc. (Thăm dò)
Dự án là gì và trách nhiệm được phân công và quản lý như thế nào?
(Thăm dò) Bạn đã quản lý trách nhiệm của mình như thế nào?
Chính xác và cẩn thận:
Làm thế nào để bạn tiếp cận việc hoàn thành các nhiệm vụ thử
nghiệm?
Hãy cho tôi một ví dụ về một dự án thử nghiệm đòi hỏi sự chính xác
và kỹ lưỡng.
Hướng dẫn tôi giải pháp của bạn cho một trong những vấn đề thử
nghiệm khó khăn nhất mà bạn phải đối mặt.
Thông tin liên lạc bằng văn bản:
Cá nhân bạn tuân theo những quy tắc hay tiêu chuẩn nào khi viết một
tài liệu kế hoạch kiểm tra? Mô tả khoảng thời gian bạn phải soạn một
tài liệu kế hoạch kiểm tra nghiệm thu để những người có hoàn cảnh
khác nhau xem.
Làm thế nào để bạn viết một báo cáo khuyết tật?
Hoàn thành và mang lại:
Mô tả khoảng thời gian khi bạn làm việc chăm chỉ cho một dự án thử
nghiệm chỉ để kết thúc mà không hoàn thành nó? (Thăm dò) Tại sao
nó không được hoàn thành? • Hãy kể cho tôi nghe về một dự án thử
nghiệm mà bạn đã dẫn đầu? (Thăm dò) Dự án đã hoàn thành những
gì và bạn đã làm gì?
Có thể điều chỉnh và dễ uốn:
Bạn đã bao giờ phải sang số giữa một dự án thử nghiệm chưa?
(Thăm dò) Chuyện gì đã xảy ra và bạn đã làm gì?
Người chơi đầy nghị lực và đồng đội:
Bạn thích làm việc một mình hay theo nhóm?
Những người làm việc trong các dự án thử nghiệm thường thấy rằng
các mức độ ưu tiên khác nhau hoặc những điều xảy ra vào phút chót
khiến bạn phải thay đổi công việc đang làm hoặc gây khó dễ cho
người khác. Điều đó đã bao giờ xảy ra với bạn chưa? (Thăm dò) Bạn
đã làm gì? • Hãy kể cho tôi nghe về một dự án thử nghiệm gần đây
đã thành công. (Thăm dò) Điều gì đã làm cho dự án thành công như
vậy?
Giao tiếp bằng lời nói:
697
Trong công việc gần đây nhất, bạn phải giao tiếp thường xuyên với
ai? (Thăm dò) Bạn đã giao tiếp với họ như thế nào? Bạn mô tả mình
là một người giao tiếp như thế nào?
Hãy cho tôi biết về cách thức và giọng điệu mà bạn đã sử dụng để
thảo luận về báo cáo khiếm khuyết với các thành viên khác trong
cuộc họp nhóm dự án.
Chính xác và xây dựng mối quan hệ:
Hãy kể cho tôi nghe về những mối quan hệ kinh doanh tốt nhất của
bạn.
Mô tả tình huống mà bạn phải xây dựng mối quan hệ với người nào
đó (nhà phát triển) mà bạn không thích.
Điều gì tạo nên một mối quan hệ công việc tốt?
Bạn thích làm việc với kiểu người nào?
Quyết tâm và ngoan cường:
Hãy kể cho tôi nghe về khoảng thời gian mà bạn thực sự phải kiên trì
để có được kết quả như mong muốn.
Hãy kể cho tôi nghe về một khiếm khuyết gây tranh cãi mà bạn ủng
hộ.
Định hướng kết quả và định hướng mục tiêu:
Bạn tự coi mình là mục tiêu hay định hướng nhiệm vụ? (Thăm dò)
Bạn có thể cho tôi một ví dụ? • Bạn có thể giải thích chiến lược mà
bạn đã làm theo trong dự án thử nghiệm cuối cùng của mình không?
(Thăm dò) Chiến thuật của bạn để thực hiện chiến lược là gì?
Bạn đã đặt mục tiêu cá nhân nào cho năm tới hoặc lâu hơn?
Mô tả nghề nghiệp mà bạn thấy cho chính mình trong thử nghiệm?
Học nhanh và học nhanh:
Mô tả một tình huống mà bạn phải học các kỹ năng kiểm tra mới một
cách nhanh chóng trước khi bạn có thể bắt đầu? (Thăm dò) Bạn đã
xử lý việc học tốc độ nhanh như thế nào?
Sáng tạo và có tầm nhìn xa:
Hãy cho tôi một số ví dụ cụ thể về các giải pháp sáng tạo đáng tự
hào? (Thăm dò) Những người khác nghĩ gì về họ?
Ngoài việc đánh giá các kỹ năng kỹ thuật và nội bộ của ứng viên, các
loại đánh giá khác được thực hiện để đảm bảo rằng ứng viên có thể
và sẽ thực hiện công việc. Những đánh giá này được giải thích ở
phần sau.
Đánh giá kỹ năng lắng nghe của ứng viên bằng cách quan sát xem
ứng viên có thường xuyên ngắt lời người phỏng vấn hay không. •
Đánh giá mức độ ứng viên trả lời các câu hỏi. Quan sát xem các câu
trả lời có được trình bày rõ ràng và ngắn gọn hay không.
Đánh giá các loại câu hỏi mà ứng viên đặt ra và liệu ứng viên có chủ
động để biết thêm về vị trí và công ty hay không.
Đánh giá phản hồi để biết liệu ứng viên có thực hiện công việc bất cứ
điều gì họ cần hay không.
Lưu ý thái độ của ứng viên đối với nghề thử nghiệm.
Lưu ý thái độ của ứng viên đối với người giám sát và đồng nghiệp ở
những nơi làm việc trước đây.
Nếu sơ yếu lý lịch chỉ ra những thay đổi công việc quá mức, hãy
quan sát cách ứng viên giải thích. Việc thay đổi công việc thường
xuyên có thể cho thấy ứng viên đó có thể không phải là một người ổn
định, dễ cảm thấy nhàm chán, hoặc không thể hòa đồng với đồng
nghiệp. • Không thuê một kỹ sư đã không nhận được công việc như
một nhà phát triển phần mềm. Một nhà phát triển phần mềm tồi
không có khả năng trở thành một người kiểm tra phần mềm tốt.
Điều quan trọng là chọn những câu hỏi hay, sâu sắc. Đồng thời, việc
đưa ra những câu hỏi không hiệu quả sẽ phản tác dụng. Một số ví dụ
về các loại câu hỏi không hiệu quả như sau:
Một câu hỏi đưa ra câu trả lời “có” hoặc “không” sẽ không hiệu quả
trừ khi ứng viên được yêu cầu biện minh cho câu trả lời.
Sẽ không hữu ích khi đưa ra lời dẫn dắt trong một câu hỏi. Ví dụ:
"Bạn chắc hẳn đã phải làm việc vào cuối tuần để hoàn thành mọi việc
đúng giờ?" có thể được điều chỉnh thành "Bạn đã làm gì để xử lý tình
huống?" để gợi ra một câu trả lời có ý nghĩa hơn.
Sẽ không có lợi khi đặt một câu hỏi đe dọa. Câu hỏi, "Tại sao bạn
không làm việc vào cuối tuần?" có thể bị coi là đe dọa. Một câu hỏi
như vậy có thể khiến ứng viên rơi vào tình thế phòng thủ và có thể
hạn chế phản ứng của họ trong phần còn lại của cuộc phỏng vấn.
Tránh các câu hỏi trắc nghiệm. Những câu hỏi này có thể tạo ra sự
bối rối trong tâm trí của ứng viên.
Hoàn toàn tránh những câu hỏi về triết học, niềm tin và quan điểm.
Một ví dụ là "Theo bạn, những phẩm chất nào cần thiết để trở thành
một kỹ sư kiểm thử hiệu quả?" Ứng viên có xu hướng trả lời những
gì người phỏng vấn muốn nghe.
699
Tránh những câu hỏi bất hợp pháp. Một câu hỏi có thể được coi là
bất hợp pháp nếu nó có thể được sử dụng để phân biệt đối xử chống
lại ứng viên trên cơ sở không mang tính quyết định đối với công
việc. Tránh những câu hỏi có thể thăm dò về tình trạng khuyết tật,
đặc điểm cá nhân hoặc hoàn cảnh cá nhân có thể xảy ra. Ví dụ về
những câu hỏi như sau:
Ngày sinh của bạn là gì?
Vợ bạn đang mong có một đứa con?
Vợ / chồng của bạn sẽ cảm thấy thế nào khi bạn đi du lịch?
Vợ / chồng của bạn làm nghề gì?
Bạn có bất kỳ khuyết tật nào có thể ngăn cản bạn thực hiện công việc
này không?
Nhân tiện, bạn đã nói bạn đến từ đâu?
16.6 ĐÀO TẠO KỸ SƯ KIỂM TRA

Cho tôi xem thẻ xanh của bạn?
Tôi có một đứa con nhỏ, bạn có bao nhiêu?
Con của bạn có đang ở nhà trẻ không?
Sẽ hiệu quả hơn nếu thực hiện đánh giá ứng viên ngay sau buổi
phỏng vấn. Điều này là do ấn tượng chung về ứng viên vẫn còn mới
mẻ trong tâm trí người phỏng vấn. Đánh giá phải bao gồm các thông
tin sau:
Thông tin cơ bản: Ghi rõ vị trí, tên ứng viên, tên người phỏng vấn và
ngày tháng.
Kỹ năng nghề nghiệp: Xếp loại theo thang điểm từ 1 (kém) đến 10
(xuất sắc).
Hạnh kiểm: Xếp loại theo thang điểm từ 1 (kém) đến 10 (xuất sắc).
Phù hợp với tổ chức: Xếp loại theo thang điểm từ 1 (kém) đến 10
(xuất sắc).
Điểm mạnh: Tóm tắt điểm mạnh của ứng viên cho vị trí này.
Điểm yếu: Tóm tắt điểm yếu của ứng viên cho vị trí này. • Nhận xét
chung: Nêu bất kỳ thông tin nào khác có thể hữu ích.
16.5.6 Ra quyết định
Bạn nên tổ chức một cuộc họp phỏng vấn của tất cả những người
phỏng vấn vào cuối cuộc phỏng vấn để so sánh xếp hạng cá nhân của
họ. Nếu có sự khác biệt giữa các xếp hạng, một sự đồng thuận sẽ
được tìm kiếm. Một ứng viên sắp được tuyển dụng cần phải thực
hiện kiểm tra tham chiếu. Việc kiểm tra như vậy cung cấp thông tin
bổ sung và có giá trị về ứng viên mà có thể không có được trong quá
trình phỏng vấn. Cần phải chú ý đến các từ mà các tham chiếu sử
dụng trong cuộc trò chuyện, do đó là thông điệp cơ bản. Người quản
lý tuyển dụng nên đưa ra quyết định càng nhanh càng tốt vì những
ứng viên giỏi không ở lại thị trường lâu.
16.6 ĐÀO TẠO KỸ SƯ KIỂM TRA
Giữ chân người kiểm tra là một thách thức lớn, đặc biệt là trong thị
trường ngày nay. Các kỹ sư kiểm thử phải biết rằng họ có sự hỗ trợ
từ các cấp quản lý khác nhau. Các nhà quản lý nên được khuyến
khích công nhận các nỗ lực kiểm tra ngang bằng với các nỗ lực phát
triển. Ban quản lý nên coi các kỹ sư thử nghiệm của mình như những
chuyên gia và là một phần của nhóm tổng thể cung cấp một sản phẩm
chất lượng. Sau đây là các yếu tố chính tác động tích cực đến khả
năng giữ chân các kỹ sư kiểm tra hệ thống giỏi của một tổ chức.
16.6.1 Con đường sự nghiệp
Mong muốn có một lộ trình nghề nghiệp rõ ràng trong nhóm kiểm
thử hệ thống để có thể thu hút và giữ chân các kỹ sư kiểm thử nhân
viên có năng lực. Mỗi tổ chức cần thiết lập lộ trình nghề nghiệp và
mức độ trách nhiệm riêng cho các kỹ sư kiểm thử. Điều này có thể
tương tự như phân cấp nhóm thử nghiệm được mô tả trong Phần
16.3. Một tổ chức có thể thiết lập các tiêu chí dựa trên hiệu suất và
kinh nghiệm để chuyển từ vai trò này sang vai trò khác. Để cung cấp
các sản phẩm chất lượng cao, thử nghiệm không phải là một con
đường sự nghiệp bế tắc. Phải có nhiều cơ hội trong một tổ chức để
các kỹ sư kiểm thử chuyển sang các lĩnh vực khác, chẳng hạn như
phát triển, kỹ thuật hệ thống, hỗ trợ khách hàng và quản lý dự án.
Người quản lý thử nghiệm phải làm việc với các thành viên trong
nhóm để thăng tiến trong sự nghiệp của họ — điều này đúng với bất
kỳ bộ phận nào của tổ chức và đối với các kỹ sư thử nghiệm hệ thống
cũng không khác.
16.6.2 Đào tạo
Công nghệ kiểm tra đang thay đổi gần như nhanh như sự phát triển.
Đào tạo là cần thiết để liên tục nâng cao kiến thức kiểm tra, kiến thức
kinh doanh, kỹ năng giao tiếp giữa các cá nhân, khả năng lãnh đạo,
kỹ năng giao tiếp và các vấn đề quy trình liên quan đến kiểm tra. Ví
701
dụ, các công cụ kiểm tra đang thay đổi theo công nghệ. Việc xây
dựng các công cụ tự động hóa nội bộ sẽ không còn hiệu quả về chi
phí khi có các tập đoàn chỉ tập trung vào nỗ lực đó. Các công cụ
kiểm tra cần được đánh giá liên tục để biết chúng có thể làm được gì
và không thể làm gì và các kỹ sư kiểm thử phải được đào tạo về các
công cụ mới. Nếu các kỹ sư thử nghiệm chưa thực hiện bất kỳ quá
trình tự động hóa thử nghiệm nào, họ nên được khuyến khích tham
dự một số bài giảng giới thiệu về tự động hóa thử nghiệm. Họ có khả
năng trở nên rất giỏi trong việc phát triển các trường hợp kiểm thử tự
động với một số khóa đào tạo. Có một số lựa chọn có sẵn để đào tạo
nhân viên [7]:
Đào tạo Thương mại Tại chỗ: Một nhà thầu cá nhân từ một công ty
khác được mời để đào tạo một nhóm kỹ sư kiểm tra hệ thống. Tài
liệu đào tạo được tùy chỉnh để đáp ứng nhu cầu riêng của nhóm.
Giảng viên cung cấp đào tạo thực hành về các công cụ kiểm tra để tự
động hóa, quy trình xem xét mã và thiết kế các trường hợp thử
nghiệm bằng cách sử dụng các ví dụ từ lĩnh vực quan tâm.
Đào tạo Diễn đàn Công khai: Các kỹ sư thử nghiệm cá nhân được
gửi đến một lớp đào tạo công khai. Điều này rất hữu ích nếu quy mô
nhóm nhỏ. Ở đây, người hướng dẫn không thể tùy chỉnh tài liệu cho
một vài sinh viên vì sinh viên có thể đến từ các công ty khác nhau
với nguồn gốc đa dạng.
Đào tạo nội bộ: Một số công ty thực hiện các chương trình đào tạo
nội bộ cho nhân viên mới về các quy trình phát triển và đảm bảo chất
lượng, chẳng hạn như quy trình chứng nhận ISO. Hạn chế của
phương pháp này là không có giảng viên giỏi và thiếu tài liệu đào tạo
tốt.
Đào tạo Chuyên ngành: Có nhiều chương trình đào tạo đặc biệt,
chẳng hạn như đào tạo hỗ trợ web và đào tạo từ xa. Có các chương
trình đào tạo dựa trên sản phẩm, chẳng hạn như kỹ sư hệ thống được
chứng nhận của Microsoft (MCSE) và chuyên gia kết nối internet
được chứng nhận của Cisco (CCIE). Điều quan trọng đối với một kỹ
sư kiểm tra hệ thống mạng là phải hiểu thấu đáo về cách thức hoạt
động của một hệ thống mạng, thay vì chỉ xem nó hoạt động như thế
nào.
Cố vấn: Đây là một quá trình mà một nhân viên mới làm việc với
một kỹ sư kiểm tra hệ thống có kinh nghiệm lâu năm được gọi là
người cố vấn. Công việc của người cố vấn là đào tạo và thúc đẩy sự
nghiệp của một kỹ sư thử nghiệm mới được thuê. Của một người cố
vấn
16.7 XÂY DỰNG ĐỘI
trách nhiệm bắt đầu vào ngày người mới đến làm việc. Một người cố
vấn có những trách nhiệm tối thiểu sau:
Hướng dẫn cách điền các thủ tục giấy tờ của công ty để hoàn thành
công việc
Xử lý các câu hỏi mà người đó có thể có liên quan đến các hoạt động
bình thường hàng ngày
Đào tạo nhân viên về phương pháp đang được sử dụng
Thảo luận về cách kiểm tra, kiểm tra tốt là gì, khi nào, như thế nào và
tại sao nên sử dụng các công cụ, v.v.
16.6.3 Hệ thống phần thưởng
Phần thưởng là một cách tuyệt vời để khuyến khích mọi người tiếp
tục cải thiện và ở lại tổ chức thử nghiệm. Tăng lương dựa trên thành
tích, điều chỉnh mức lương, quyền chọn cổ phiếu và môi trường văn
phòng là tất cả những điều có thể tạo ra sự khác biệt. Thanh toán
không phải là tất cả, nhưng nó chắc chắn là một vấn đề cần phải giải
quyết. Khuyến nghị nên có các kỹ sư kiểm tra 'thang lương trên các
nhà phát triển'. Ý tưởng chính là thu hút các nhà phát triển tham gia
vào nhóm thử nghiệm và sau đó đào tạo họ trở thành những người
kiểm tra hệ thống. Một cách khác để đánh giá cao công việc tốt của
các kỹ sư thử nghiệm là tổ chức một chương trình trao thưởng chính
thức với giấy chứng nhận, bảng và các giải thưởng khác, chẳng hạn
như phiếu quà tặng từ một nhà hàng rất đẹp, để vinh danh các đội vì
nỗ lực đặc biệt của họ.
16.7 XÂY DỰNG ĐỘI
Điều quan trọng là các kỹ sư thử nghiệm trong một nhóm phải làm
việc cùng nhau với tinh thần đoàn kết để tối đa hóa thành công cuối
cùng của nhóm. Xây dựng thái độ đồng đội có nghĩa là quản lý các
kỹ sư theo cách thúc đẩy tinh thần đồng đội thay vì lợi ích cá nhân.
Nó liên quan đến nỗ lực và thực hành liên tục giữa tất cả các thành
viên trong nhóm, bao gồm cả người quản lý nhóm. Các thành phần
thiết yếu của một môi trường làm việc tốt cho các kỹ sư kiểm thử
được giải thích như sau.
703
16.7.1 Kỳ vọng
Tất cả các kỹ sư thử nghiệm nên biết nhiệm vụ của họ là gì và những
kỳ vọng đi kèm với nhiệm vụ. Họ cũng nên biết những hậu quả lớn
hơn của việc không thể đáp ứng kỳ vọng. Vai trò và trách nhiệm của
một kỹ sư kiểm thử cần được xác định rõ ràng. Các thành viên trong
nhóm cần có cơ hội để làm rõ và nếu có thể, thương lượng về vai trò
và mối quan hệ của họ với nhau. Các thành viên trong nhóm có thể
được trao quyền để tự vạch ra trách nhiệm và vai trò và báo cáo các
đề xuất của họ cho người quản lý thử nghiệm. Người quản lý thử
nghiệm nên lên lịch một cuộc họp riêng hàng tuần với từng kỹ sư thử
nghiệm để nói về cách mọi thứ đang diễn ra và biết các kỹ sư cũng
như sở thích của họ ngoài công việc chính thức. Người quản lý cần
lắng nghe những mối quan tâm của họ và thể hiện sự đồng cảm, thấu
hiểu và khuyến khích. Các cuộc thảo luận không chính thức và chia
sẻ suy nghĩ có thể giúp họ hiểu được nhu cầu của mình một cách lâu
dài và người quản lý có thể giúp họ nâng cao lòng tự trọng của mình.
16.7.2 Tính nhất quán
Tính nhất quán thường là điều mà các kỹ sư kiểm tra hệ thống tìm
kiếm trong quá trình thử nghiệm của họ. Có nó trong quá trình thử
nghiệm cũng có lợi. Quy trình không nên là một quy trình trôi chảy
— nó phải luôn thay đổi. Ví dụ, khi khai báo một khuyết tật, mức độ
nghiêm trọng của khuyết tật phải được chỉ định dựa trên các tiêu chí
đã xác định và không được thay đổi tùy từng thời điểm. Nó nên được
sử dụng nhất quán trong toàn bộ tổ chức. Tính ổn định là điều cần
thiết để thử nghiệm thành công phần mềm và các quy trình tương tự
đối với các quy trình mà mọi người dự kiến sẽ tuân theo. Điều quan
trọng là phải phù hợp với các tiêu chí đầu vào và đầu ra để kiểm tra.
Nếu và khi sự không thống nhất được chấp nhận, cần nói rõ lý do cho
mọi người và nêu rõ hướng khắc phục.
16.7.3 Chia sẻ thông tin
Chia sẻ thông tin là chìa khóa để thành công. Cần tạo ra một bầu
không khí để lưu chuyển thông tin có giá trị cao, kịp thời, thông suốt
giữa bản thân và các kỹ sư kiểm tra hệ thống và khuyến khích việc
bày tỏ cởi mở các ý tưởng và quan điểm. Các phương pháp thể hiện ý
tưởng và quan điểm bao gồm e-mail, bảng trắng, thảo luận, thuyết
trình, kho tài liệu tập trung, và các cuộc họp ngắn và thường xuyên.
Các kỹ sư thử nghiệm phải được cập nhật thông tin hữu ích, chẳng
hạn như thay đổi chính sách của công ty, các dự án thử nghiệm sắp
tới và các sự kiện tổ chức. Điều quan trọng là đảm bảo rằng không có
bất ngờ cho các thành viên trong nhóm. Các thành viên trong nhóm
nên được khuyến khích chia sẻ thông tin có lợi bằng cách trò chuyện.
Giao tiếp trực tiếp và cởi mở với những người khác sẽ nuôi dưỡng
lòng tin, tăng cường luồng thông tin và xây dựng mối quan hệ bền
chặt hơn. Động não cũng là một phương pháp hiệu quả để chia sẻ
thông tin. Người quản lý cần ghi chép trong các phiên động não để
phân phát biên bản. Tại các phiên họp này, tất cả các ý kiến đều được
hoan nghênh, nhưng không có phân tích nào được thực hiện trong
các cuộc họp. Các buổi động não nói chung là vui vẻ và mang tính
giáo dục. Đôi khi, ý tưởng nghe có vẻ nực cười nhất lại trở thành
khái niệm trong tương lai.
16.7.4 Tiêu chuẩn hóa
Bắt buộc phải có một vốn từ vựng chuẩn về thuật ngữ để mọi người
hiểu những gì đang được nói. Ví dụ, trong một cuộc họp đánh giá
khuyết điểm gồm tám người, nếu một người quản lý kiểm tra đặt câu
hỏi "Sự khác biệt giữa mức độ ưu tiên và mức độ nghiêm trọng của
một khuyết điểm là gì?" người ta sẽ nghe nhiều câu trả lời khác nhau.
Việc chuẩn hóa thuật ngữ sẽ không chỉ giúp ích cho nhóm mà nếu nó
được chia sẻ với những người khác trong tổ chức, các thuật ngữ sẽ
bắt đầu hiển thị trong các yêu cầu và các tài liệu khác. Cuối cùng,
mọi người sẽ hiểu những gì đang được nói.
16.7.5 Môi trường thử nghiệm
Sẽ là hợp lý khi hỏi "Môi trường thử nghiệm có liên quan gì đến việc
xây dựng nhóm?" Có môi trường thử nghiệm có thể được chia sẻ sẽ
tăng cường đáng kể nỗ lực thử nghiệm. Tuy nhiên, nếu một người có
một môi trường thử nghiệm duy nhất, thì tinh thần đồng đội là rất
quan trọng để
16.8 TÓM TẮT
được đáp ứng. Có môi trường thử nghiệm tốt dẫn đến sự gắn kết
nhóm tốt hơn. Môi trường thử nghiệm nên cung cấp cho các kỹ sư
thử nghiệm quyền truy cập vào cơ sở dữ liệu theo dõi lỗi, cơ sở dữ
liệu nhà máy thử nghiệm, cơ sở dữ liệu cấu hình hệ thống và các
nguồn thông tin khác để thực hiện các trường hợp thử nghiệm và báo
cáo kết quả một cách hiệu quả. Nên có một phòng thí nghiệm thử
nghiệm riêng biệt, nơi các kỹ sư thử nghiệm có thể thiết lập môi
705
trường thử nghiệm để thực hiện các trường hợp thử nghiệm. Để giúp
tổ chức thử nghiệm tối đa hóa năng suất và hiệu quả thông qua phòng
thử nghiệm của họ, các ý tưởng sau đây cần được xem xét: (i) tạo
nhiều hơn một môi trường thử nghiệm, (ii) mua công cụ và thiết bị
mới, (iii) cập nhật thiết bị hiện có, (iv) ) thay thế thiết bị cũ, (v) giữ
cho môi trường thử nghiệm sạch sẽ, và (vi) giữ một bản kiểm kê tất
cả các thiết bị trong phòng thí nghiệm.
16.7.6 Nhận biết
Nó là hiệu quả và hiệu quả về chi phí để đánh giá công việc mà mọi
kỹ sư thử nghiệm thực hiện. Công nhận bằng lời nói cho những đóng
góp của kỹ sư nên được đưa ra. Công nhận và ăn mừng thành tích
của nhóm là một cách hiệu quả để ghi nhận những nỗ lực của cả
nhóm và duy trì động lực và đà phát triển. Nhóm thử nghiệm cần
được thông báo rằng nỗ lực của họ tạo ra sự khác biệt cho chất lượng
của sản phẩm thông qua một bản ghi nhớ cá nhân. Những buổi gặp
mặt đặc biệt, chẳng hạn như bữa trưa và bữa sáng của nhóm, nên
được tổ chức sau khi hoàn thành thành công một dự án thử nghiệm.
16.8 TÓM TẮT
Chương này đề cập đến việc tổ chức các nhóm kiểm tra về chức
năng, quản lý và nhân sự. Khuyến nghị là có ít nhất hai nhóm thử
nghiệm: nhóm thử nghiệm tích hợp và nhóm thử nghiệm hệ thống.
Kiểm thử đơn vị phải được thực hiện bởi các lập trình viên trong quá
trình mã hóa để không cần một nhóm kiểm thử riêng biệt cho kiểm
thử cấp đơn vị. Một nhóm kiểm tra tích hợp chủ yếu bao gồm các
nhà phát triển. Một nhóm kiểm tra hệ thống có thể được chia thành
một số nhóm con, mỗi nhóm xử lý một nhiệm vụ chuyên biệt, khi tổ
chức phát triển. Sự cần thiết phải phân biệt giữa nhóm đảm bảo chất
lượng và nhóm kiểm tra hệ thống đã được giải thích. Nhiệm vụ của
nhóm đảm bảo chất lượng rộng hơn nhiều so với nhóm kiểm tra hệ
thống. Nhóm đảm bảo chất lượng có vai trò lớn hơn trong việc đảm
bảo sự phù hợp với các thông lệ phát triển tốt nhất trong toàn tổ
chức, nằm ngoài phạm vi của nhóm kiểm tra hệ thống.
Tiếp theo, chi tiết về việc bố trí nhân sự hiệu quả các kỹ sư kiểm thử
cấp cơ sở, cấp cao và chính đã được trình bày. Sáu giai đoạn đơn
giản của việc tuyển dụng kỹ sư thử nghiệm đã được thảo luận: yêu
cầu công việc, lập hồ sơ công việc, sàng lọc sơ yếu lý lịch, điều phối
nhóm phỏng vấn, phỏng vấn và ra quyết định. Chương này giải thích
một số chi tiết về cách giữ chân các kỹ sư thử nghiệm bằng cách đào
tạo, khen thưởng và thiết lập một lộ trình nghề nghiệp rõ ràng cho họ
trong tổ chức thử nghiệm.
Cuối cùng, chương giải thích các cách để xây dựng và quản lý một
nhóm thử nghiệm với tinh thần đoàn kết theo cách thúc đẩy tinh thần
đồng đội thay vì lợi ích cá nhân. Sáu thành phần đã được thảo luận
để tối đa hóa hiệu quả của nhóm thử nghiệm: kỳ vọng, tính nhất
quán, chia sẻ thông tin, tiêu chuẩn hóa, môi trường thử nghiệm và
công nhận.
Có thể tìm thấy một cuộc thảo luận tốt về tổ chức nhóm kiểm tra,
nhân sự kỹ sư kiểm tra và quản lý nhóm kiểm tra trong Chương 8 và
9 của cuốn sách của Black [3] và Craig và Jaskiel [7], tương ứng.
Mỗi chương trình bày các ví dụ và ý kiến hữu ích liên quan đến việc
tuyển dụng, tổ chức thử nghiệm, thúc đẩy người thử nghiệm và quản
lý nhóm thử nghiệm. Ngoài ra, cuốn sách của Craig và Jaskiel trình
bày một chương xuất sắc, đó là Chương 10, về những gì tạo nên một
người quản lý kiểm tra giỏi. Có thể tìm thấy một hướng dẫn hay về
quản lý nhóm kiểm thử trong Chương 5 của cuốn sách của Dustin,
Rashka và Paul [1]. Chương này bao gồm các phần về cơ cấu tổ chức
của nhóm thử nghiệm, định cỡ nỗ lực thử nghiệm, tuyển dụng kỹ sư
thử nghiệm, vai trò và trách nhiệm của người quản lý thử nghiệm và
kỹ sư thử nghiệm.
Mô tả về con đường sự nghiệp cho kỹ sư kiểm thử có thể được tìm
thấy trong E. Weyuker, T. Ostrand, J. Brophy và R. Prasad,
“Clearing a Career Path for Software Tester,” IEEE Software, Vol.
17, số 2, tháng 3 / tháng 4 năm 2000, trang 76–82. Các tác giả mô tả
năm giai đoạn, đó là học việc, thành thạo, chuyên môn hóa, lãnh đạo
và người thử nghiệm cấp cao nhất, trong lộ trình nghề nghiệp của kỹ
sư thử nghiệm tại AT&T. Các nhà nghiên cứu đã xác định một nhóm
các kỹ năng kỹ thuật chung mà một kỹ sư thử nghiệm cần phải có.
Bộ kỹ năng chung bao gồm kiến thức về máy tính, kiến trúc hệ
thống, phương pháp phát triển phần mềm, hệ thống thông tin, hệ điều
hành và cơ sở dữ liệu.
707
Sổ tay Nhà quản lý Thành công (B. Davis, C. Skube, L. Hellervik, S.
Gebelein, và J. Sheard, Nhân sự Quyết định Quốc tế, Minneapolis,
1996) là một cuốn sách toàn diện về cải thiện kỹ năng quản lý. Cuốn
sách bao gồm các thảo luận kỹ lưỡng về cách trở thành một nhà quản
lý hiệu quả bằng cách thực hành chín khía cạnh / yếu tố: yếu tố hành
chính, yếu tố lãnh đạo, yếu tố giao tiếp cá nhân, yếu tố giao tiếp, yếu
tố động lực, yếu tố tự quản lý, yếu tố kiến thức tổ chức, yếu tố chiến
lược tổ chức và tư duy hệ số. Đây là một cuốn sách rất được khuyến
khích để trở thành một người quản lý thử nghiệm thành công.
RD Craig và SP Jaskiel. Kiểm thử phần mềm có hệ thống. Artech
House, Norwood, MA, 2002.
Bài tập
Tại sao nhóm kiểm tra tích hợp hoạt động trong nhóm phát triển?
Các bài kiểm tra cấp độ đơn vị được thiết kế và thực hiện bởi các nhà
phát triển riêng lẻ. Tại sao chúng ta không tạo một nhóm kiểm thử
đơn vị trong một nhóm phát triển tương tự như một nhóm kiểm tra
tích hợp?
Thảo luận về những thuận lợi và khó khăn của việc có một nhóm
systemtest độc lập được tách ra khỏi nhóm phát triển phần mềm với
cấu trúc báo cáo riêng.
Vai trò và trách nhiệm của người quản lý kiểm thử và người quản lý
đảm bảo chất lượng (phần mềm) là gì?
Giả sử rằng bạn là người quản lý kiểm tra hệ thống cho một tổ chức
phát triển phần mềm khởi động. Công ty của bạn phát triển phần
mềm trong lĩnh vực an ninh mạng. Bạn muốn thuê một kỹ sư thử
nghiệm mới cho nhóm của mình. Chuẩn bị hồ sơ công việc cho kỹ sư
thử nghiệm mà bạn có thể sử dụng để đăng tuyển và sàng lọc các ứng
viên.
Đối với tổ chức được mô tả trong bài tập 5, hãy chuẩn bị hồ sơ công
việc để thuê người quản lý đảm bảo thủy sản lãnh đạo nhóm quản lý
chất lượng.
Bạn có nghĩ rằng bạn có thể hỏi những câu hỏi sau trong một cuộc
phỏng vấn. Justifyyour câu trả lời.
Bạn có hút thuốc không? Chúng tôi duy trì một môi trường làm việc
không khói thuốc. Bạn có thể làm việc mà không hút thuốc trong
công việc?
Bạn đã bao giờ bị kết án về một tội nghiêm trọng?

Bạn đã bao giờ bị bắt?
Bạn đã bao giờ xét nghiệm dương tính với vi rút AIDS chưa?
Bạn là người đồng tính?
Sagar tên là gì?
Nó có phải là một cái tên Ấn Độ không?
Viết một số câu hỏi phỏng vấn của bạn để đánh giá kỹ sư thử nghiệm
trong các trang sau:
Quản lý thời gian
Giải quyết vấn đề
Quyết định
Đa nhiệm
Khả năng lãnh đạo
Động lực
Chân thành
Software
development
manager
Software Integration System test

developers testers group
Hình 16.5 Tổ chức thử nghiệm hệ thống như một phần của quá
trình phát triển.
Môi trường làm việc
Nhanh chóng và nhanh chóng
Trong các tổ chức khởi nghiệp nhỏ, nhóm kiểm tra hệ thống là một
phần của nhóm phát triển, như trong Hình 16.5. Bạn có nghĩ rằng nó
là một ý tưởng tốt để có cấu trúc này? Biện minh cho câu trả lời của
bạn.
Người quản lý kiểm thử đóng vai trò gì trong việc xây dựng nhóm
kiểm thử hệ thống?
17.2 CÁC YẾU TỐ VÀ TIÊU CHÍ CHẤT LƯỢNG CỦA MCCALL 709
CHAPTER
17
SoftwareQuality
Chất lượng không bao giờ là một tai nạn; nó luôn là kết quả của nỗ
lực thông minh. —JohnRuskin
17.1 NĂM QUAN ĐIỂM VỀ CHẤT LƯỢNG PHẦN MỀM
Trong những ngày đầu của máy tính, các nhà phát triển phần mềm
chủ yếu tập trung vào các chức năng của sản phẩm và hầu hết người
dùng cuối là các chuyên gia có trình độ cao, chẳng hạn như nhà toán
học, nhà khoa học và kỹ sư. Sự phát triển của máy tính cá nhân và
những tiến bộ trong mạng máy tính, World Wide Web, và giao diện
người dùng đồ họa đã làm cho phần mềm máy tính có khả năng truy
cập cao đối với mọi loại người dùng. Ngày nay, việc tin học hóa rộng
rãi nhiều quy trình mà trước đây thường được thực hiện bằng tay. Ví
dụ, cho đến cuối những năm 1990 người nộp thuế thường nộp tờ khai
trên giấy, nhưng ngày nay có rất nhiều hệ thống khai thuế dựa trên
web. Ngày càng có nhiều kỳ vọng của khách hàng về chất lượng tốt
hơn trong các sản phẩm phần mềm và các nhà phát triển đang phải
chịu áp lực rất lớn trong việc cung cấp các sản phẩm chất lượng cao
với chi phí thấp hơn. Mặc dù các sản phẩm cạnh tranh cung cấp các
chức năng giống nhau, nhưng các sản phẩm có giá thành thấp hơn
với các thuộc tính chất lượng tốt hơn mới tồn tại được trong thị
trường cạnh tranh. Do đó, tất cả các bên liên quan — người dùng,
khách hàng, nhà phát triển, người thử nghiệm và người quản lý —
trong một sản phẩm phải có hiểu biết rộng về khái niệm tổng thể về
chất lượng phần mềm.
Một số yếu tố ảnh hưởng đến việc tạo và mua các sản phẩm phần
mềm. Những yếu tố này là nhu cầu và mong đợi của người dùng, cân
nhắc của nhà sản xuất, các đặc tính vốn có của sản phẩm và giá trị
cảm nhận của sản phẩm. Để có thể nắm bắt được khái niệm chất
lượng, điều quan trọng là phải nghiên cứu chất lượng từ một góc độ
rộng hơn. Điều này là do khái niệm chất lượng có trước sự phát triển
710 CHƯƠNG 17 CHẤT LƯỢNG PHẦN MỀM
phần mềm. Trong một bài báo được trích dẫn nhiều được xuất bản
trên Tạp chí Quản lý Sloan [1], Garvin đã phân tích chất lượng được
nhìn nhận như thế nào trong các cách cư xử khác nhau trong các lĩnh
vực khác nhau, cụ thể là triết học, kinh tế, tiếp thị và quản lý:
Chế độ xem siêu nghiệm: Trong chế độ xem siêu nghiệm, chất lượng
chế độ xem siêu nghiệm là thứ có thể được công nhận thông qua kinh
nghiệm nhưng không được định nghĩa trong một số điều có thể hiểu
được
519
hình thức. Chất lượng được coi là một cái gì đó lý tưởng, là thứ quá
phức tạp để có thể xác định chính xác. Tuy nhiên, một đối tượng chất
lượng tốt sẽ nổi bật và nó dễ dàng được nhận ra. Vì bản chất triết học
của quan điểm siêu nghiệm, không có nỗ lực nào được thực hiện để
diễn đạt nó bằng các biện pháp cụ thể.
Chế độ xem người dùng: Chế độ xem người dùng liên quan đến mức
độ mà một sản phẩm đáp ứng nhu cầu và mong đợi của người dùng.
Chất lượng không chỉ được xem xét trên khía cạnh sản phẩm có thể
cung cấp, mà nó còn bị ảnh hưởng bởi các điều khoản dịch vụ trong
hợp đồng mua bán. Theo quan điểm này, người dùng quan tâm đến
việc liệu một sản phẩm có phù hợp để sử dụng hay không. Quan
điểm này mang tính cá nhân hóa cao. Ý tưởng về hồ sơ hoạt động,
được thảo luận trong Chương 15, đóng một vai trò quan trọng trong
quan điểm này. Do tính chất cá nhân hóa của quan điểm sản phẩm,
một sản phẩm được coi là có chất lượng tốt nếu nó thỏa mãn được
nhu cầu của một số lượng lớn khách hàng. Sẽ rất hữu ích khi xác
định những thuộc tính sản phẩm nào mà người dùng coi là quan
trọng. Người đọc có thể lưu ý rằng chế độ xem người dùng có thể
bao gồm nhiều yếu tố chủ quan ngoài các chức năng mong đợi trung
tâm đến sự hài lòng của người dùng. Ví dụ về các yếu tố chủ quan là
khả năng sử dụng, độ tin cậy, khả năng kiểm tra và hiệu quả.
Quan điểm sản xuất: Quan điểm sản xuất có nguồn gốc từ các lĩnh
vực sản xuất, chẳng hạn như lĩnh vực ô tô và điện tử. Theo quan
điểm này, chất lượng được coi là phù hợp với yêu cầu. Bất kỳ sai
lệch nào so với các yêu cầu đã nêu đều được coi là làm giảm chất
lượng của sản phẩm. Khái niệm về quá trình đóng một vai trò quan
trọng trong quan điểm sản xuất. Sản phẩm phải được sản xuất “ngay
lần đầu tiên” để giảm chi phí phát triển và chi phí bảo trì. Tuy nhiên,
không có gì đảm bảo rằng việc tuân thủ các tiêu chuẩn quy trình sẽ
dẫn đến sản phẩm tốt. Một số người chỉ trích quan điểm này với lập
luận rằng việc tuân thủ một quy trình chỉ có thể dẫn đến sự đồng nhất
trong các sản phẩm, và do đó, có thể sản xuất các sản phẩm kém chất
lượng một cách nhất quán. Tuy nhiên, chất lượng sản phẩm có thể
được nâng cao từng bước bằng cách liên tục cải tiến quy trình. Việc
phát triển mô hình phát triển năng lực (CMM) [2] và ISO 9001 [3]
dựa trên quan điểm sản xuất.
Quan điểm về sản phẩm: Giả thuyết trọng tâm trong quan điểm về
sản phẩm là: Nếu một sản phẩm được sản xuất với những đặc tính
bên trong tốt thì nó sẽ có những phẩm chất bên ngoài tốt. Chế độ
xem sản phẩm hấp dẫn vì nó tạo ra cơ hội khám phá các mối quan hệ
nhân quả giữa các đặc tính bên trong và phẩm chất bên ngoài của sản
phẩm. Theo quan điểm này, mức chất lượng hiện tại của một sản
phẩm cho biết sự có mặt hay không có các đặc tính của sản phẩm có
thể đo lường được. Quan điểm về chất lượng của sản phẩm có thể
được đánh giá một cách khách quan. Một ví dụ về quan điểm sản
phẩm về chất lượng phần mềm là mức độ mô đun cao, là một thuộc
tính bên trong, làm cho một phần mềm có thể kiểm tra và bảo trì
được.
Quan điểm dựa trên giá trị: Quan điểm dựa trên giá trị thể hiện sự
hợp nhất của hai khái niệm độc lập: sự xuất sắc và giá trị. Chất lượng
là thước đo của sự xuất sắc và giá trị là thước đo của giá trị. Ý tưởng
trung tâm trong việc dựa trên giá trị
17.1 NĂM QUAN ĐIỂM VỀ CHẤT LƯỢNG PHẦN MỀM
xem là số tiền khách hàng sẵn sàng trả cho một mức chất lượng nhất
định. Thực tế là chất lượng là vô nghĩa nếu một sản phẩm không có ý
nghĩa kinh tế. Về cơ bản, quan điểm dựa trên giá trị thể hiện sự đánh
đổi giữa chi phí và chất lượng.
Đo lường chất lượng Năm quan điểm giúp chúng ta hiểu các khía
cạnh khác nhau của khái niệm chất lượng. Mặt khác, đo lường cho
phép chúng ta có một cái nhìn định lượng về khái niệm chất lượng.
Sau đây, chúng tôi giải thích lý do phát triển quan điểm định lượng
của hệ thống phần mềm [4]:
Đo lường cho phép chúng tôi thiết lập các đường cơ sở cho các phẩm
chất. Các nhà phát triển phải biết mức chất lượng tối thiểu mà họ
phải cung cấp để một sản phẩm có thể chấp nhận được.
Các tổ chức thực hiện các cải tiến liên tục trong các mô hình quy
trình của họ — và một cải tiến đi kèm với nó. Các tổ chức cần biết
mức độ cải tiến về chất lượng đạt được với một chi phí nhất định
phát sinh do cải tiến quy trình. Mối quan hệ nhân quả này rất hữu ích
trong việc đưa ra các quyết định quản lý liên quan đến cải tiến quy
trình. Đôi khi, việc đầu tư nhiều hơn vào cải tiến quy trình có thể
đáng giá, trong khi một số thời điểm khác, lợi nhuận có thể không
đáng kể.
Mức chất lượng hiện tại của sản phẩm cần được đánh giá để có thể
khảo sát nhu cầu cải tiến.
Đo lường chế độ xem của người dùng Chế độ xem của người dùng
bao gồm một số yếu tố chất lượng, chẳng hạn như chức năng, độ tin
cậy và khả năng sử dụng. Có thể dễ dàng đo lường mức độ các chức
năng mà một sản phẩm phần mềm mang lại bằng cách thiết kế ít nhất
một trường hợp thử nghiệm cho mỗi chức năng. Một sản phẩm có thể
yêu cầu nhiều trường hợp thử nghiệm cho cùng một chức năng nếu
chức năng đó được thực hiện trong các môi trường thực thi khác
nhau. Sau đó, tỷ lệ giữa số trường hợp thử nghiệm được thông qua
trên tổng số trường hợp thử nghiệm được thiết kế để xác minh các
chức năng là thước đo các chức năng được cung cấp bởi sản phẩm.
Trong số các phẩm chất phản ánh quan điểm của người dùng, khái
niệm độ tin cậy đã thu hút sự chú ý nhiều nhất của các nhà nghiên
cứu.
Trong mô hình chất lượng ISO 9126, khả năng sử dụng được chia
thành ba đặc điểm phụ, đó là tính dễ học, tính dễ hiểu và khả năng
hoạt động. Khả năng học hỏi có thể được chỉ định là thời gian trôi
qua trung bình để một người dùng thông thường đạt được một mức
năng lực nhất định trong việc sử dụng sản phẩm. Tương tự, khả năng
hiểu được có thể được định lượng bằng thời gian trung bình mà một
người dùng thông thường cần để đạt được mức độ hiểu biết nhất định
về sản phẩm. Người ta có thể định lượng khả năng hoạt động theo
cách tương tự. Ý tưởng cơ bản của việc chia nhỏ khả năng sử dụng
thành khả năng học hỏi, khả năng hiểu và khả năng hoạt động có thể
được nhìn thấy trong kỹ thuật của Gilb [5]: Khái niệm chất lượng
được chia thành các phần thành phần cho đến khi mỗi phần có thể
được phát biểu dưới dạng các thuộc tính có thể đo lường trực tiếp.
Kỹ thuật của Gilb là một kỹ thuật chung có thể áp dụng cho nhiều
loại chất lượng ở cấp độ người dùng.
Phép đo Chế độ xem của nhà sản xuất Các nhà sản xuất quan tâm
đến việc đo lường hai đại lượng khác nhau sau:
Số lượng khuyết tật: Có bao nhiêu khuyết tật đã được phát hiện?
Chi phí làm lại: Chi phí bao nhiêu để sửa các lỗi đã biết?
Số lượng khuyết tật đại diện cho số lượng tất cả các khuyết tật đã
được phát hiện cho đến nay. Nếu một sản phẩm đang hoạt động, số
lượng này bao gồm các khuyết tật được phát hiện trong quá trình
phát triển và vận hành. Số lượng khuyết tật phản ánh chất lượng sản
phẩm được sản xuất. Việc chỉ đếm các khiếm khuyết không được sử
dụng nhiều trừ khi có thể làm gì đó để cải thiện quy trình phát triển
nhằm giảm thiểu số lượng khiếm khuyết trong các dự án tiếp theo.
Người ta có thể phân tích các khuyết tật như sau:
Đối với mỗi khiếm khuyết, xác định giai đoạn phát triển mà nó được
đưa vào và giai đoạn mà nó được phát hiện. Chúng ta hãy giả định
rằng một phần lớn các khuyết tật được đưa vào trong giai đoạn thu
thập yêu cầu và chúng được phát hiện trong quá trình kiểm tra hệ
thống. Sau đó, chúng tôi có thể kết luận rằng phân tích yêu cầu đã
không được thực hiện đầy đủ. Chúng tôi cũng có thể kết luận rằng
công việc được thực hiện sau đó, chẳng hạn như xác minh thiết kế và
thử nghiệm đơn vị, không đạt tiêu chuẩn cao. Nếu một số lượng lớn
các lỗi được tìm thấy trong quá trình vận hành hệ thống, người ta có
thể nói rằng việc kiểm tra hệ thống đã không được thực hiện một
cách nghiêm ngặt.
Phân loại các khuyết tật dựa trên các mô-đun. Giả sử rằng một mô-
đun là một thực thể gắn kết thực hiện một nhiệm vụ được xác định rõ
ràng, bằng cách xác định các mô-đun có chứa hầu hết các khiếm
khuyết, chúng ta có thể xác định được mọi thứ đang diễn ra sai ở đâu.
Thông tin này có thể được sử dụng để quản lý tài nguyên. Ví dụ, nếu
một số lượng lớn các khiếm khuyết được tìm thấy trong một mô-đun
giao tiếp trong một ứng dụng phân tán, thì nhiều tài nguyên hơn có
thể được phân bổ để đào tạo các nhà phát triển về các chi tiết của hệ
thống truyền thông.
Để so sánh khuyết tật giữa các mô-đun và sản phẩm một cách có ý
nghĩa, hãy chuẩn hóa số lượng khuyết tật theo kích thước sản phẩm.
Bằng cách chuẩn hóa số lượng khuyết tật theo kích thước sản phẩm
về số lượng LOC, chúng ta có thể thu được một thước đo, được gọi
là mật độ khuyết tật. Một cách trực quan, mật độ khuyết tật được
biểu thị bằng số lượng khuyết tật được tìm thấy trên một nghìn dòng
mã.
Tách biệt các khuyết tật được tìm thấy trong quá trình hoạt động với
những khuyết tật được tìm thấy trong quá trình phát triển. Tỷ lệ giữa
số lượng khuyết tật được tìm thấy trong quá trình vận hành trên tổng
số khuyết tật là thước đo hiệu quả của toàn bộ hoạt động thử nghiệm.
Nếu tỷ lệ này gần bằng 0, chúng ta có thể nói rằng thử nghiệm có
hiệu quả cao. Mặt khác, nếu tỷ lệ này càng xa giá trị lý tưởng của 0,
chẳng hạn, 0,2, thì rõ ràng là tất cả các hoạt động kiểm tra chỉ phát
hiện được 80% các khuyết tật.
Sau khi các lỗi được phát hiện, các nhà phát triển sẽ nỗ lực để sửa
chữa chúng. Cuối cùng, phải tốn một số tiền để sửa chữa các khiếm
khuyết — điều này ngoài chi phí “danh tiếng” đối với một tổ chức từ
những khiếm khuyết được phát hiện trong quá trình hoạt động. Chi
phí làm lại bao gồm tất cả các chi phí bổ sung liên quan đến các hoạt
động liên quan đến lỗi, chẳng hạn như sửa chữa tài liệu. Làm lại là
một chi phí bổ sung phát sinh do công việc được thực hiện theo cách
kém hoàn hảo trong lần đầu tiên nó được hoàn thành. Rõ ràng là
các tổ chức cố gắng giảm tổng chi phí phát triển phần mềm, bao gồm
cả chi phí làm lại. Chi phí làm lại có thể được chia thành hai phần
như sau:
Chi phí làm lại phát triển: Đây là chi phí làm lại phát sinh trước
khi sản phẩm được xuất xưởng cho khách hàng.
Chi phí làm lại hoạt động: Đây là chi phí làm lại phát sinh khi một
sản phẩm đang hoạt động.
Một mặt, chi phí phát triển lại là thước đo hiệu quả phát triển. Nói
cách khác, nếu chi phí làm lại phát triển bằng 0, thì hiệu quả phát
triển là rất cao. Mặt khác, chi phí vận hành lại là thước đo chất lượng
được cung cấp của sản phẩm đang vận hành. Nếu chi phí làm lại quá
trình phát triển bằng 0, thì chất lượng cung cấp của sản phẩm đang
vận hành là rất cao. Điều này là do khách hàng không gặp bất kỳ lỗi
nào và do đó, nhóm phát triển không dành bất kỳ nguồn lực nào để
sửa lỗi.
17.2 CÁC YẾU TỐ VÀ TIÊU CHÍ CHẤT LƯỢNG CỦA
MCCALL
Khái niệm về chất lượng phần mềm và những nỗ lực để hiểu nó dưới
dạng các đại lượng có thể đo lường được bắt đầu từ giữa những năm
1970. McCall, Richards, và Walters [6] là những người đầu tiên
nghiên cứu khái niệm chất lượng phần mềm về các yếu tố chất lượng
và tiêu chí chất lượng.
17.2.1 Yếu tố chất lượng
Yếu tố chất lượng thể hiện đặc tính hành vi của hệ thống. Một số ví
dụ về các yếu tố chất lượng cấp cao là tính đúng đắn, độ tin cậy, hiệu
quả, khả năng kiểm tra, tính di động và khả năng tái sử dụng. Danh
sách đầy đủ các yếu tố chất lượng sẽ được đưa ra trong phần sau của
phần này. Như các ví dụ cho thấy, các yếu tố chất lượng là các thuộc
tính bên ngoài của một hệ thống phần mềm. Khách hàng, nhà phát
triển phần mềm và kỹ sư đảm bảo chất lượng quan tâm đến các yếu
tố chất lượng khác nhau ở một mức độ khác nhau. Ví dụ, khách hàng
có thể muốn một phần mềm hiệu quả và đáng tin cậy với ít lo ngại về
tính di động. Các nhà phát triển cố gắng đáp ứng nhu cầu của khách
hàng bằng cách làm cho hệ thống của họ hiệu quả và đáng tin cậy,
đồng thời làm cho sản phẩm có thể di động và có thể tái sử dụng để
giảm chi phí phát triển phần mềm. Nhóm đảm bảo chất lượng phần
mềm quan tâm nhiều hơn đến khả năng kiểm thử của hệ thống để
một số yếu tố khác, chẳng hạn như tính đúng đắn, độ tin cậy và hiệu
quả, có thể dễ dàng được xác minh thông qua thử nghiệm. Yếu tố khả
năng kiểm thử cũng quan trọng đối với nhà phát triển và khách hàng:
(i) Nhà phát triển muốn kiểm tra sản phẩm của họ trước khi giao nó
cho nhóm đảm bảo chất lượng phần mềm và (ii) khách hàng muốn
thực hiện kiểm tra nghiệm thu trước khi giao sản phẩm. Trong Bảng
17.1, chúng tôi liệt kê các yếu tố chất lượng theo định nghĩa của
McCall và cộng sự. [6]. Bây giờ chúng tôi giải thích 11 yếu tố chất
lượng chi tiết hơn:
Tính đúng đắn: Một hệ thống phần mềm được kỳ vọng sẽ đáp ứng
các yêu cầu chức năng được chỉ định rõ ràng và các yêu cầu phi chức
năng được mong đợi ngầm định. Nếu một hệ thống phần mềm đáp
ứng tất cả các yêu cầu chức năng,
BẢNG 17.1 Các yếu tố chất lượng của McCall
Yếu tố chất
Sự định nghĩa
lượng
Tính đúng Mức độ mà một chương trình đáp ứng các thông số kỹ
đắn thuật của nó và hoàn thành các mục tiêu sứ mệnh của
người dùng
độ tin cậy Mức độ mà một chương trình có thể được mong đợi
để thực hiện chức năng dự kiến của nó với độ chính
xác cần thiết
Hiệu quả Số lượng tài nguyên máy tính và mã được yêu cầu bởi
một chương trình để thực hiện một chức năng
Sự toàn vẹn Mức độ có thể kiểm soát quyền truy cập vào phần
mềm hoặc dữ liệu của những người không được phép
Khả năng sử Cần nỗ lực để tìm hiểu, vận hành, chuẩn bị đầu vào và
dụng diễn giải đầu ra của một chương trình
Khả năng Cần nỗ lực để xác định vị trí và sửa chữa một khiếm
bảo trì khuyết trong một chương trình hoạt động
Khả năng Cần nỗ lực để kiểm tra một chương trình để đảm bảo
kiểm tra rằng nó thực hiện các chức năng dự kiến của nó
Uyển chuyển Cần nỗ lực để sửa đổi một chương trình hoạt động
Tính di động Cần nỗ lực để chuyển một chương trình từ môi trường
phần cứng và / hoặc phần mềm này sang môi trường
khác
Khả năng tái Mức độ mà các phần của hệ thống phần mềm có thể
sử dụng được sử dụng lại trong các ứng dụng khác
Khả năng Cần nỗ lực để ghép một hệ thống này với một hệ
tương tác thống khác
hệ thống được cho là đúng. Tuy nhiên, một hệ thống phần mềm
chính xác vẫn có thể không được khách hàng chấp nhận nếu hệ thống
không đáp ứng được các yêu cầu chưa xác định, chẳng hạn như độ ổn
định, hiệu suất và khả năng mở rộng. Mặt khác, ngay cả một hệ
thống không chính xác cũng có thể được người dùng chấp nhận.
Độ tin cậy: Rất khó để xây dựng các hệ thống phần mềm lớn chính
xác. Một vài chức năng có thể không hoạt động trong tất cả các tình
huống thực thi, và do đó, phần mềm được coi là không chính xác.
Tuy nhiên, phần mềm vẫn có thể được khách hàng chấp nhận vì các
tình huống thực thi gây ra lỗi hệ thống có thể không thường xuyên
xảy ra khi hệ thống được triển khai. Hơn nữa, khách hàng có thể
chấp nhận lỗi phần mềm thỉnh thoảng. Khách hàng vẫn có thể coi
một hệ thống không chính xác là đáng tin cậy nếu tỷ lệ hỏng hóc là
rất nhỏ và nó không ảnh hưởng xấu đến mục tiêu sứ mệnh của họ. Độ
tin cậy là nhận thức của khách hàng, và một phần mềm không chính
xác vẫn có thể được coi là đáng tin cậy.
Hiệu quả: Liên quan đến tính hiệu quả ở mức độ nào mà hệ thống
phần mềm sử dụng các tài nguyên, chẳng hạn như sức mạnh tính
toán, bộ nhớ, không gian đĩa, băng thông truyền thông và năng
lượng. Một hệ thống phần mềm phải sử dụng ít tài nguyên nhất có
thể để thực hiện các chức năng của nó. Ví dụ, bằng cách sử dụng ít
băng thông truyền thông hơn, một trạm gốc trong mạng điện thoại di
động có thể hỗ trợ nhiều người dùng hơn.
Tính toàn vẹn: Tính toàn vẹn của một hệ thống đề cập đến khả năng
chống lại các cuộc tấn công đối với tính bảo mật của nó. Nói cách
khác, tính toàn vẹn đề cập đến mức độ có thể kiểm soát việc truy cập
vào phần mềm hoặc dữ liệu của những người hoặc chương trình
không được phép. Tính toàn vẹn đã đảm nhận một vai trò nổi bật
trong các ứng dụng dựa trên mạng ngày nay. Tính toàn vẹn cũng là
một vấn đề trong hệ thống đa người dùng.
Khả năng sử dụng: Một hệ thống phần mềm được coi là có thể sử
dụng được nếu người dùng thấy nó dễ sử dụng. Người dùng chú
trọng nhiều vào giao diện người dùng của các hệ thống phần mềm.
Nếu không có giao diện người dùng tốt, hệ thống phần mềm có thể
hoạt động kém hiệu quả ngay cả khi nó sở hữu nhiều phẩm chất
mong muốn. Tuy nhiên, cần phải nhớ rằng một giao diện người dùng
tốt không thể tạo nên thành công cho một sản phẩm — ví dụ, sản
phẩm đó cũng phải đáng tin cậy. Nếu một phần mềm bị lỗi quá
thường xuyên, không có giao diện người dùng tốt thì nó có thể tiếp
tục tồn tại trên thị trường.
Khả năng bảo trì: Nói chung, bảo trì đề cập đến việc duy trì sản
phẩm để đối phó với sự hư hỏng của các bộ phận của chúng do tiếp
tục sử dụng sản phẩm. Khả năng bảo trì đề cập đến việc các nhiệm
vụ bảo trì có thể được thực hiện một cách dễ dàng và không tốn kém.
Đối với các sản phẩm phần mềm, có ba loại hoạt động bảo trì: sửa
chữa, thích ứng và hoàn thiện. Bảo trì khắc phục là một hoạt động
sau khi phát hành và nó đề cập đến việc loại bỏ các khiếm khuyết tồn
tại trong phần mềm tại chỗ. Các khuyết tật hiện có có thể đã được
biết tại thời điểm phát hành sản phẩm hoặc có thể đã xuất hiện trong
quá trình bảo trì. Bảo trì thích ứng liên quan đến việc điều chỉnh hệ
thống phần mềm theo những thay đổi trong môi trường thực thi. Bảo
trì hoàn hảo liên quan đến việc sửa đổi một hệ thống phần mềm để
cải thiện một số chất lượng của nó.
Khả năng kiểm tra: Điều quan trọng là có thể xác minh mọi yêu cầu,
cả được nêu rõ ràng và đơn giản là mong đợi. Khả năng kiểm tra có
nghĩa là khả năng xác minh các yêu cầu. Ở mọi giai đoạn phát triển
phần mềm, cần phải xem xét khía cạnh khả năng kiểm thử của một
sản phẩm. Cụ thể, đối với mỗi yêu cầu, chúng tôi cố gắng trả lời câu
hỏi: Người ta nên sử dụng quy trình nào để kiểm tra yêu cầu, và
người ta có thể xác minh nó dễ dàng như thế nào? Để làm cho một
sản phẩm có thể kiểm tra được, các nhà thiết kế có thể phải tạo ra
một thiết kế với các chức năng không có sẵn cho khách hàng.
Tính linh hoạt: Tính linh hoạt được phản ánh trong chi phí sửa đổi
một hệ thống hoạt động. Khi ngày càng có nhiều thay đổi được thực
hiện trong một hệ thống trong suốt giai đoạn hoạt động của nó, thì
những thay đổi tiếp theo có thể ngày càng tốn kém hơn. Nếu thiết kế
ban đầu không linh hoạt, rất có thể những lần thay đổi sau đó rất tốn
kém. Để đo tính linh hoạt của một hệ thống, người ta phải tìm ra câu
trả lời cho câu hỏi: Làm thế nào người ta có thể thêm một tính năng
mới vào hệ thống một cách dễ dàng?
Tính di động: Tính di động của một hệ thống phần mềm đề cập đến
việc nó có thể được điều chỉnh dễ dàng như thế nào để chạy trong
một môi trường thực thi khác. Môi trường thực thi là một thuật ngữ
rộng bao gồm nền tảng phần cứng, hệ điều hành, tính phân tán và
tính không đồng nhất của hệ thống phần cứng. Tính khả chuyển rất
quan trọng đối với các nhà phát triển vì một hệ thống thích ứng nhỏ
có thể làm tăng tiềm năng thị trường của nó. Hơn nữa, tính di động
cung cấp cho khách hàng một tùy chọn để dễ dàng di chuyển từ môi
trường thực thi này sang môi trường thực thi khác để sử dụng tốt nhất
các công nghệ mới nổi trong việc thúc đẩy hoạt động kinh doanh của
họ. Các nguyên tắc thiết kế tốt như tính mô-đun tạo điều kiện thuận
lợi cho tính di động. Ví dụ, tất cả các tính toán liên quan đến môi
trường có thể được bản địa hóa trong một vài mô-đun để chúng có
thể dễ dàng được xác định và sửa đổi để chuyển hệ thống sang môi
trường khác.
Khả năng tái sử dụng: Khả năng tái sử dụng có nghĩa là nếu một
phần đáng kể của một sản phẩm có thể được tái sử dụng, có thể với
sửa đổi nhỏ, trong một sản phẩm khác. Việc tái sử dụng các thành
phần nhỏ có thể không hiệu quả về mặt kinh tế. Khả năng tái sử dụng
giúp tiết kiệm chi phí và thời gian để phát triển và kiểm tra thành
phần đang được tái sử dụng. Trong lĩnh vực máy tính khoa học, các
thư viện toán học thường được tái sử dụng. Khả năng tái sử dụng
không chỉ giới hạn ở các bộ phận của sản phẩm, mà nó còn có thể
được áp dụng cho các quy trình. Ví dụ, chúng tôi rất quan tâm đến
việc phát triển các quy trình tốt mà phần lớn có thể lặp lại.
Khả năng tương tác: Trong thời đại kết nối mạng máy tính, các hệ
thống phần mềm bị cô lập đang dần trở nên hiếm hoi. Các hệ thống
phần mềm ngày nay được kết hợp ở cấp độ đầu vào - đầu ra với các
hệ thống phần mềm khác. Về mặt trực quan, khả năng tương tác có
nghĩa là đầu ra của một hệ thống có được chấp nhận như đầu vào của
hệ thống khác hay không; có khả năng là hai hệ thống chạy trên các
máy tính khác nhau được kết nối với nhau bởi một mạng. Khi chúng
ta xem xét các ứng dụng dựa trên Internet và các ứng dụng không
dây, nhu cầu về khả năng tương tác chỉ đơn giản là vượt quá. Ví dụ,
người dùng gói xử lý tài liệu, chẳng hạn như LaTex và Microsoft
Word, muốn nhập nhiều hình ảnh được tạo ra bởi các gói đồ họa
khác nhau. Do đó, các gói đồ họa và gói xử lý tài liệu phải tương
thích với nhau. Một ví dụ khác về khả năng tương tác là khả năng
chuyển vùng từ một mạng điện thoại di động ở quốc gia này sang
mạng di động khác ở quốc gia khác.
11 yếu tố chất lượng được xác định trong Bảng 17.1 đã được nhóm
thành ba loại lớn như sau:
Vận hành sản phẩm • Sửa đổi sản phẩm
Chuyển đổi sản phẩm
Các yếu tố của mỗi loại trong ba loại lớn được xác định và giải thích
thêm trong Bảng 17.2. Có thể lưu ý rằng ba loại trên liên quan nhiều
hơn đến các kỳ vọng của các hoạt động sau phát triển và ít liên quan
đến các hoạt động đang trong quá trình phát triển. Nói cách khác, các
yếu tố chất lượng của McCall nhấn mạnh nhiều hơn vào các mức
chất lượng của sản phẩm do một tổ chức cung cấp và các mức chất
lượng của sản phẩm được giao liên quan đến việc bảo trì sản phẩm.
Yếu tố chất lượng trong danh mục hoạt động của sản phẩm đề cập
đến chất lượng được giao. Khả năng kiểm tra là một yếu tố chất
lượng quan trọng có nhiều ý nghĩa đối với các nhà phát triển trong
quá trình phát triển và bảo trì sản phẩm. Khả năng bảo trì, tính linh
hoạt và tính di động là những yếu tố chất lượng mong muốn được tìm
kiếm
BẢNG 17.2 Phân loại các yếu tố chất lượng của McCall
Danh mục chất Yếu tố chất
Mục tiêu rộng
lượng lượng
Hoạt động của sản Tính đúng đắn Nó có làm những gì khách
phẩm hàng muốn không?
độ tin cậy Nó có thực hiện chính xác mọi
lúc không?
Hiệu quả Nó có nhanh chóng giải quyết
vấn đề dự định không?
Sự toàn vẹn Nó có an toàn không?
Khả năng sử Tôi có thể chạy nó không?
dụng
Bản sửa đổi sản Khả năng bảo trì Nó có thể được sửa chữa?
phẩm
Khả năng kiểm Nó có thể được kiểm tra?
tra
Uyển chuyển Nó có thể thay đổi được

không?
Chuyển đổi sản Tính di động Nó có thể được sử dụng trên
phẩm một máy khác?
Khả năng tái sử Các bộ phận của nó có thể
dụng được sử dụng lại không?
Khả năng tương Nó có thể giao tiếp với hệ
tác thống khác không?
trong một sản phẩm để nhiệm vụ hỗ trợ sản phẩm sau khi giao hàng
ít tốn kém hơn. Khả năng tái sử dụng là một yếu tố chất lượng có khả
năng giảm chi phí phát triển của một dự án bằng cách cho phép các
nhà phát triển sử dụng lại một số thành phần từ một sản phẩm hiện
có. Khả năng tương tác cho phép một sản phẩm cùng tồn tại với các
sản phẩm, hệ thống và tính năng khác.
17.2.2 Tiêu chí Chất lượng
Tiêu chí chất lượng là một thuộc tính của yếu tố chất lượng có liên
quan đến phát triển phần mềm. Ví dụ, mô đun là một thuộc tính của
kiến trúc của một hệ thống phần mềm. Một phần mềm có tính mô-
đun cao cho phép các nhà thiết kế đặt các thành phần gắn kết trong
một mô-đun, do đó tăng khả năng bảo trì của hệ thống. Tương tự,
khả năng xác định nguồn gốc yêu cầu của người dùng cho phép các
nhà phát triển ánh xạ chính xác yêu cầu tới một tập hợp con của các
mô-đun, do đó tăng tính đúng đắn của hệ thống. Một số chỉ tiêu chất
lượng liên quan đến sản phẩm và một số liên quan đến nhân sự. Ví
dụ, tính mô-đun là một tiêu chí chất lượng liên quan đến sản phẩm,
trong khi đào tạo liên quan đến nhân viên phát triển và đảm bảo chất
lượng phần mềm. Trong Bảng 17.3, chúng tôi liệt kê 23 tiêu chí chất
lượng được xác định bởi McCall và cộng sự. [6].
17.2.3 Mối quan hệ giữa các yếu tố chất lượng và tiêu chí
Mối quan hệ giữa các yếu tố chất lượng và chỉ tiêu chất lượng được
thể hiện trên hình 17.1. Mũi tên từ tiêu chí chất lượng đến yếu tố chất
lượng có nghĩa là tiêu chí chất lượng có tác động tích cực đến yếu tố
chất lượng. Ví dụ, truy xuất nguồn gốc có tác động tích cực đến tính
đúng đắn. Tương tự, tính đơn giản của tiêu chí chất lượng ảnh hưởng
tích cực đến độ tin cậy, khả năng sử dụng và khả năng kiểm tra.
Mặc dù mong muốn cải thiện tất cả các yếu tố chất lượng, nhưng làm
như vậy có thể không thực hiện được. Điều này là do, nhìn chung,
các yếu tố chất lượng không hoàn toàn độc lập.
Do đó, chúng tôi lưu ý hai đặc điểm của mối quan hệ như sau:
Hình 17.1 Mối quan hệ giữa các yếu tố chất lượng và chỉ tiêu
chất lượng [6].
• Nếu nỗ lực cải thiện một yếu tố chất lượng, một yếu tố chất lượng
khác có thể bị suy giảm. Ví dụ, nếu một nỗ lực được thực hiện để
làm cho một sản phẩm phần mềm có thể kiểm tra được, thì hiệu quả
của phần mềm có thể sẽ giảm xuống. Để làm cho mã có thể kiểm tra
được, các lập trình viên có thể không viết được mã nhỏ gọn. Hơn
nữa, nếu chúng ta quan tâm đến việc làm cho một sản phẩm có thể
xách tay, thì mã phải
BẢNG 17.3 Tiêu chí Chất lượng của McCall
Quality Criteria Definition

Access audit Ease with which software and data can be
checked for compliance with standards or
other requirements
Access control Provisions for control and protection of the
software and data
Accuracy Precision of computations and output
Communication Degree to which standard protocols and
commonality interfaces are used
Completeness Degree to which a full implementation of
the required functionalities has been
achieved
Communicativeness Ease with which inputs and outputs can be
assimilated
Conciseness Compactness of the source code, in terms
of lines of code
Consistency Use of uniform design and implementation
techniques and notation throughout a
project
Data commonality Use of standard data representations
Error tolerance Degree to which continuity of operation is
ensured under adverse conditions
Execution efficiency Run time efficiency of the software
Expandability Degree to which storage requirements or
software functions can be expanded
Generality Breadth of the potential application of
software components
Hardware Degree to which the software is dependent
independence on the underlying hardware
Instrumentation Degree to which the software provides for
measurement of its use or identification of
errors
Modularity Provision of highly independent modules
được viết theo cách dễ hiểu, và do đó, mã không cần phải ở dạng nhỏ
gọn. Nỗ lực làm cho mã di động có thể làm giảm hiệu quả của nó.
Trên thực tế, những nỗ lực cải thiện tính toàn vẹn, khả năng sử dụng,
khả năng bảo trì, khả năng kiểm tra, tính linh hoạt, tính di động, khả
năng tái sử dụng và khả năng tương tác sẽ làm giảm hiệu quả của
một hệ thống phần mềm. • Một số yếu tố chất lượng tác động tích
cực đến những yếu tố khác. Ví dụ, một nỗ lực để nâng cao tính đúng
đắn của một hệ thống sẽ làm tăng độ tin cậy của nó. Một ví dụ khác,
nỗ lực nâng cao khả năng kiểm tra của một hệ thống sẽ cải thiện khả
năng bảo trì của nó.
17.2.4 Các chỉ số chất lượng
Các yếu tố chất lượng cấp cao không thể được đo lường trực tiếp. Ví
dụ, chúng ta không thể đo lường trực tiếp khả năng kiểm thử của một
hệ thống phần mềm. Khả năng kiểm tra không thể được diễn đạt
bằng thuật ngữ “có” hoặc “không”. Thay vào đó, mức độ kiểm tra có
thể được đánh giá bằng cách kết hợp với khả năng kiểm tra một số
chỉ số chất lượng, cụ thể là tính đơn giản, thiết bị đo đạc, khả năng tự
mô tả và tính mô đun. Chỉ số chất lượng là thước đo để nắm bắt một
số khía cạnh của tiêu chí chất lượng. Một hoặc nhiều chỉ số chất
lượng phải được liên kết với mỗi tiêu chí. Các chỉ số có thể được suy
ra như sau:
Hình thành một tập hợp các câu hỏi có liên quan đến các tiêu chí chất
lượng và tìm kiếm câu trả lời “có” hoặc “không” cho mỗi câu hỏi.
Chia số câu trả lời “có” cho số câu hỏi để nhận được giá trị trong
phạm vi từ 0 đến 1. Số kết quả thể hiện chỉ số chất lượng dự kiến.
Ví dụ, chúng ta có thể đặt câu hỏi sau liên quan đến tính tự mô tả của
một sản phẩm: Tất cả tài liệu có được viết rõ ràng và đơn giản để có
thể dễ dàng hiểu các thủ tục, hàm và thuật toán không? Một câu hỏi
khác liên quan đến tính mô tả bản thân là: Cơ sở lý luận thiết kế đằng
sau một mô-đun có được hiểu rõ ràng không? Các câu hỏi khác nhau
có thể có mức độ quan trọng khác nhau trong việc tính toán một số
liệu, và do đó, các câu trả lời “có” riêng lẻ có thể có trọng số khác
nhau trong tính toán trên.
Cách tính toán giá trị của một số liệu ở trên mang tính chủ quan cao.
Mức độ chủ quan khác nhau đáng kể giữa các câu hỏi mặc dù thực tế
là tất cả các câu trả lời đều được đối xử như nhau. Rất khó để kết hợp
các thước đo khác nhau để có được thước đo cho yếu tố chất lượng ở
cấp độ cao hơn. Ngoài ra, đối với một số câu hỏi, việc xem xét câu
trả lời trên thang đo lường phong phú hơn sẽ có ý nghĩa hơn. Ví dụ,
câu hỏi "Việc thiết kế một hệ thống phần mềm có đơn giản không?"
cần phải được trả lời theo nhiều thứ tự để phản ánh nhiều câu trả lời
có thể có, thay vì câu trả lời có hoặc không.
Tương tự, người ta không thể đo lường trực tiếp độ tin cậy của một
hệ thống. Tuy nhiên, số lượng các lỗi khác nhau được quan sát cho
đến nay là thước đo độ tin cậy ban đầu của hệ thống. Hơn nữa,
khoảng cách thời gian giữa các hư hỏng quan sát được được coi là
thước đo độ tin cậy của hệ thống.
17.3 CÁC ĐẶC ĐIỂM CHẤT LƯỢNG ISO 9126
Đã có sự hợp tác quốc tế giữa các chuyên gia để xác định một khuôn
khổ chung cho chất lượng phần mềm. Một nhóm chuyên gia, dưới sự
bảo trợ của ISO, đã tiêu chuẩn hóa tài liệu chất lượng phần mềm, cụ
thể là ISO 9126, trong đó xác định sáu loại đặc điểm chất lượng rộng,
độc lập như sau:
17.4 TIÊU CHUẨN CHẤT LƯỢNG PHẦN MỀM ISO 9000: 2000 727

Chức năng: Một tập hợp các thuộc tính chịu sự tồn tại của một tập
hợp các chức năng và các thuộc tính cụ thể của chúng. Các chức
năng là những chức năng đáp ứng các nhu cầu đã nêu hoặc ngụ ý.
Độ tin cậy: Một tập hợp các thuộc tính phụ thuộc vào khả năng của
phần mềm để duy trì mức hiệu suất của nó trong các điều kiện đã nêu
trong một khoảng thời gian nhất định.
Khả năng sử dụng: Một tập hợp các thuộc tính dựa trên nỗ lực cần
thiết để sử dụng và đánh giá cá nhân về việc sử dụng đó bởi một
nhóm người dùng đã nêu hoặc ngụ ý.
Hiệu quả: Một tập hợp các thuộc tính phụ thuộc vào mối quan hệ
giữa hiệu suất của phần mềm và lượng tài nguyên được sử dụng
trong các điều kiện đã nêu.
Khả năng bảo trì: Một tập hợp các thuộc tính dựa trên nỗ lực cần
thiết để thực hiện các sửa đổi cụ thể (có thể bao gồm các sửa đổi, cải
tiến hoặc thích ứng của phần mềm với các thay đổi của môi trường
và các thay đổi trong các yêu cầu và thông số kỹ thuật chức năng).
Tính khả chuyển: Một tập hợp các thuộc tính chịu đựng khả năng
phần mềm được chuyển từ môi trường này sang môi trường khác
(bao gồm môi trường tổ chức, phần cứng hoặc phần mềm).
Tiêu chuẩn ISO 9126 bao gồm một mô hình chất lượng ví dụ, như
được thể hiện trong Hình 17.2, tiếp tục phân tích các đặc tính chất
lượng thành các đặc điểm phụ cụ thể hơn. Ví dụ, đặc tính khả năng
bảo trì đã được phân tách thành bốn đặc điểm phụ, đó là khả năng
phân tích, khả năng thay đổi, tính ổn định và khả năng kiểm tra. Sự
phân hủy thể hiện trong Hình 17.2 chỉ là một mô hình mẫu — và
không phải là một mô hình phổ quát. 20 đặc điểm phụ của Hình 17.2
được xác định như sau:
Tính phù hợp: Khả năng của phần mềm để cung cấp một tập hợp đầy
đủ các chức năng cho các nhiệm vụ và mục tiêu người dùng cụ thể.
Độ chính xác: Khả năng của phần mềm để cung cấp các kết quả hoặc
hiệu ứng đúng hoặc theo thỏa thuận.
Khả năng tương tác: Khả năng của phần mềm tương tác với một hoặc
nhiều hệ thống được chỉ định.
Bảo mật: Khả năng của phần mềm để ngăn chặn truy cập ngoài ý
muốn và chống lại các cuộc tấn công có chủ ý nhằm truy cập trái
phép vào thông tin bí mật hoặc thực hiện các sửa đổi trái phép đối
với thông tin hoặc chương trình để cung cấp cho kẻ tấn công một số
lợi thế hoặc để từ chối dịch vụ người dùng hợp pháp.
Độ chín: Khả năng của phần mềm để tránh thất bại do lỗi trong phần
mềm.
Khả năng chịu lỗi: Khả năng của phần mềm để duy trì một mức hiệu
suất cụ thể trong trường hợp lỗi phần mềm hoặc vi phạm giao diện
được chỉ định của nó.
Khả năng khôi phục: Khả năng của phần mềm để thiết lập lại mức
hiệu suất của nó và khôi phục dữ liệu bị ảnh hưởng trực tiếp trong
trường hợp bị lỗi.
Quality characteristic Quality subcharacteristics

Suitability
Accuracy
Functionality
Interoperability
Security
Maturity
Reliability Fault tolerance
Recoverability
Understandability
Usability Learnability
Operability
Time behavior
Efficiency
Resource behavior
Analyzability
Changeability
Maintainability
Stability
Testability
Adaptability
Installability
Portability
Conformance
Replaceability
Hình 17.2 Mô hình chất lượng mẫu ISO 9126 tinh chỉnh các tính
năng của tiêu chuẩn thành các đặc điểm phụ. (Từ tham chiếu 4. ©
1996 IEEE.)
Tính dễ hiểu: Khả năng của sản phẩm phần mềm cho phép người
dùng hiểu liệu phần mềm có phù hợp hay không và cách nó có thể
được sử dụng cho các nhiệm vụ và điều kiện sử dụng cụ thể.
Khả năng học hỏi: Khả năng của sản phẩm phần mềm cho phép
người dùng tìm hiểu các ứng dụng của nó.
Khả năng vận hành: Khả năng của sản phẩm phần mềm cho phép
người dùng vận hành và kiểm soát nó.
Tính hấp dẫn: Khả năng sản phẩm phần mềm được người dùng ưa
thích.
Hành vi thời gian: Khả năng của phần mềm cung cấp thời gian phản
hồi và xử lý thích hợp và tốc độ thông lượng khi thực hiện chức năng
của nó trong các điều kiện đã nêu.
Sử dụng tài nguyên: Khả năng phần mềm sử dụng các tài nguyên
thích hợp trong một thời gian thích hợp khi phần mềm thực hiện
chức năng của nó trong điều kiện đã nêu.
Khả năng phân tích: Khả năng của sản phẩm phần mềm được chẩn
đoán về các thiếu sót hoặc nguyên nhân gây ra lỗi trong phần mềm
hoặc các bộ phận cần sửa đổi để được xác định.
Khả năng thay đổi: Khả năng của sản phẩm phần mềm cho phép thực
hiện một sửa đổi cụ thể.
Tính ổn định: Khả năng của phần mềm để giảm thiểu các tác động
không mong muốn từ các sửa đổi của phần mềm.
Khả năng kiểm tra: Khả năng của sản phẩm phần mềm cho phép xác
thực phần mềm đã sửa đổi.
Khả năng thích ứng: Khả năng phần mềm được sửa đổi cho các môi
trường cụ thể khác nhau mà không cần áp dụng các hành động hoặc
phương tiện khác với những hành động được cung cấp cho mục đích
này đối với phần mềm được xem xét.
Khả năng cài đặt: Khả năng cài đặt phần mềm trong một môi trường
cụ thể.
Đồng tồn tại: Khả năng của phần mềm cùng tồn tại với các phần
mềm độc lập khác trong một môi trường chung chia sẻ tài nguyên
chung.
Khả năng thay thế: Khả năng của phần mềm được sử dụng thay thế
cho phần mềm được chỉ định khác trong môi trường của phần mềm
đó.
Các tổ chức phải xác định các đặc điểm chất lượng và đặc điểm phụ
của riêng mình sau khi hiểu đầy đủ hơn về nhu cầu của họ. Nói cách
khác, các tổ chức phải xác định mức độ của các đặc tính chất lượng
khác nhau mà họ cần phải đáp ứng trong bối cảnh phát triển phần
mềm của họ. Đạt đến mức chất lượng lý tưởng nhất từ mức hiện tại
là một quá trình dần dần. Do đó, điều quan trọng là phải hiểu nhu cầu
chuyển sang bước có thể đạt được tiếp theo hướng tới cấp độ cao
nhất - cấp độ lý tưởng nhất.
Tại thời điểm này, rất hữu ích nếu so sánh mô hình chất lượng của
McCall với mô hình ISO 9126. Vì hai mô hình tập trung vào cùng
một thực thể trừu tượng, cụ thể là chất lượng phần mềm, nên lẽ
đương nhiên là có nhiều điểm tương đồng giữa hai mô hình. Cái
được gọi là yếu tố chất lượng trong mô hình của McCall được gọi là
đặc tính chất lượng trong mô hình ISO 9126. Các yếu tố / đặc điểm
chất lượng cấp cao sau đây được tìm thấy trong cả hai mô hình: độ
tin cậy, khả năng sử dụng, hiệu quả, khả năng bảo trì và tính di động.
Tuy nhiên, có một số khác biệt giữa hai mô hình như được giải thích
trong phần sau:
Mô hình ISO 9126 nhấn mạnh các đặc điểm mà người dùng có thể
nhìn thấy, trong khi mô hình McCall cũng xem xét các chất lượng
bên trong. Ví dụ, khả năng tái sử dụng là một đặc tính bên trong của
một sản phẩm. Các nhà phát triển sản phẩm cố gắng sản xuất các
thành phần có thể tái sử dụng, trong khi tác động của nó không được
khách hàng cảm nhận.
Trong mô hình của McCall, một tiêu chí chất lượng có thể ảnh hưởng
đến một số yếu tố chất lượng, trong khi trong mô hình ISO 9126, một
tiêu chí phụ tác động đến chính xác một đặc tính chất lượng.
Yếu tố chất lượng cấp cao, chẳng hạn như khả năng kiểm tra, trong
mô hình McCall là đặc điểm phụ cấp thấp của khả năng bảo trì trong
mô hình ISO 9126.
Sau đây là một số lo ngại về các mô hình chất lượng [4]:
Không có sự nhất trí về yếu tố chất lượng cấp cao nào là quan trọng
nhất ở cấp cao nhất. McCall và cộng sự. đề xuất 11 yếu tố chất lượng
cấp cao, trong khi tiêu chuẩn ISO 9126 chỉ xác định 6 đặc điểm chất
lượng. Một số yếu tố chất lượng trong mô hình McCall quan trọng
hơn đối với các nhà phát triển. Ví dụ, khả năng tái sử dụng và khả
năng tương tác rất quan trọng đối với các nhà phát triển. Tuy nhiên,
mô hình ISO 9126 chỉ xem xét sản phẩm.
Không có sự nhất trí nào về yếu tố / đặc tính chất lượng cấp cao nhất
và đâu là tiêu chí / đặc điểm chất lượng cụ thể hơn. Ngày nay, nhiều
ứng dụng chạy trên mạng máy tính và mạng truyền thông. Tuy nhiên,
khả năng tương tác không phải là một đặc tính chất lượng cấp cao
nhất, độc lập trong mô hình ISO 9126. Không rõ tại sao khả năng
tương tác là một phần của chức năng. Việc không có cơ sở lý luận
gây khó khăn cho việc tuân theo một mô hình chất lượng theo quy
định.
17.4 TIÊU CHUẨN CHẤT LƯỢNG PHẦN MỀM ISO 9000:
2000
Có những nỗ lực không ngừng ở cấp độ quốc tế để tiêu chuẩn hóa

các khía cạnh khác nhau của truyền thông máy tính và phát triển
phần mềm. Tiêu chuẩn hóa đã đặc biệt thành công trong lĩnh vực
mạng máy tính và truyền thông không dây. Ví dụ, công việc hợp tác
của Lực lượng Đặc nhiệm Kỹ thuật Internet (IETF) là chìa khóa cho
sự phát triển của Internet. Tương tự, các nỗ lực tiêu chuẩn hóa từ
IEEE đã dẫn đến sự phát triển thành công của tiêu chuẩn mạng cục
bộ (LAN), cụ thể là tiêu chuẩn IEEE 802.3 và tiêu chuẩn mạng cục
bộ không dây (WLAN), cụ thể là IEEE 802.11a / b / g.
Bất chấp hệ quả tích cực của tiêu chuẩn hóa trong lĩnh vực truyền
thông, tiêu chuẩn hóa trong phát triển phần mềm vấp phải nhiều phản
ứng trái chiều.
Một mặt, lập luận chính chống lại tiêu chuẩn hóa là nó cản trở động
lực đổi mới của từng cá nhân. Mặt khác, các tiêu chuẩn làm giảm
hoạt động tái tạo lại các quy trình giống nhau, hoặc tương tự để phát
triển và đảm bảo chất lượng. Tính lặp lại của các quy trình là một lợi
ích chính phát sinh từ việc tiêu chuẩn hóa — và khả năng lặp lại làm
giảm chi phí phát triển phần mềm và tạo ra mức chất lượng cơ bản
của các sản phẩm phần mềm.
ISO đã phát triển một loạt các tiêu chuẩn, được gọi chung là ISO
9000. ISO được thành lập vào năm 1946, có trụ sở tại Geneva, Thụy
Sĩ. Nó phát triển và thúc đẩy các tiêu chuẩn quốc tế trong lĩnh vực
đảm bảo chất lượng và quản lý chất lượng. Tiêu chuẩn ISO 9000
thường được áp dụng cho tất cả các sản phẩm hữu hình được sản
xuất với nỗ lực của con người, chẳng hạn như gia vị cho đến phần
mềm — Thậm chí một số nhãn hiệu gia vị và gạo dùng trong nấu ăn
hàng ngày đã được chứng nhận ISO 9000. Các tiêu chuẩn ISO 9000
được xem xét và cập nhật theo thời gian, 5-8 năm một lần. Tiêu
chuẩn ISO 9000 mới nhất được phát hành vào năm 2000 được gọi là
ISO 9000: 2000. Có ba thành phần của tiêu chuẩn ISO 9000: 2000
như sau:
ISO 9000: Các nguyên tắc cơ bản và từ vựng [7]
ISO 9001: Yêu cầu [8]
ISO 9004: Hướng dẫn cải tiến hiệu suất [9]
Tại thời điểm này, chúng tôi nhắc nhở người đọc rằng ISO 9002 và
ISO 9003 là các bộ phận của ISO 9000: 1994, nhưng chúng không
còn là các bộ phận của ISO 9000: 2000. ISO 9002 đề cập đến mô
hình hệ thống chất lượng để đảm bảo chất lượng trong sản xuất và
lắp đặt, trong khi ISO 9003 đề cập đến mô hình hệ thống chất lượng
để đảm bảo chất lượng trong kiểm tra và thử nghiệm cuối cùng.
17.4.1 Các nguyên tắc cơ bản của ISO 9000: 2000
Tiêu chuẩn ISO 9000: 2000 dựa trên tám nguyên tắc sau:
Nguyên tắc 1. Tập trung vào khách hàng: Thành công của một tổ
chức phụ thuộc nhiều vào việc làm hài lòng khách hàng. Một tổ chức
phải hiểu khách hàng và nhu cầu của họ trên cơ sở liên tục. Hiểu
khách hàng giúp hiểu và đáp ứng các yêu cầu của họ. Nếu chỉ đáp
ứng yêu cầu của khách hàng là chưa đủ. Đúng hơn, các tổ chức phải
nỗ lực để vượt qua sự mong đợi của khách hàng. Bằng cách hiểu
khách hàng, người ta có thể hiểu rõ hơn về nhu cầu thực sự và những
kỳ vọng không ổn định của họ. Mọi người trong các bộ phận khác
nhau của một tổ chức, chẳng hạn như tiếp thị, phát triển phần mềm,
kiểm tra và hỗ trợ khách hàng, phải nắm bắt cùng một quan điểm về
khách hàng và yêu cầu của họ. Một ví dụ về tập trung vào khách
hàng là hiểu cách họ sẽ sử dụng một hệ thống. Bằng cách trình bày
chính xác cách khách hàng sẽ sử dụng một hệ thống, người ta có thể
tạo ra một hồ sơ người dùng tốt hơn.
Nguyên tắc 2. Lãnh đạo: Các nhà lãnh đạo đặt ra phương hướng mà
tổ chức của họ nên thực hiện và họ phải truyền đạt hiệu quả điều này
cho tất cả những người tham gia vào quá trình. Tất cả những người
trong một tổ chức phải có một cái nhìn thống nhất về phương hướng
tổ chức. Nếu không hiểu rõ về phương hướng tổ chức, nhân viên sẽ
khó biết được họ đang hướng tới đâu. Các nhà lãnh đạo phải đặt ra
những mục tiêu và mục tiêu đầy thách thức nhưng thực tế. Sự đóng
góp của nhân viên nên được các nhà lãnh đạo công nhận. Các nhà
lãnh đạo tạo ra một môi trường tích cực và cung cấp hỗ trợ cho các
nhân viên để cùng thực hiện mục tiêu của tổ chức. Họ liên tục đánh
giá lại các mục tiêu của mình và truyền đạt những phát hiện cho nhân
viên.
Nguyên tắc 3. Sự tham gia của con người: Nhìn chung, các tổ chức
dựa vào con người. Mọi người được thông báo về phương hướng tổ
chức và họ tham gia vào việc ra quyết định ở tất cả các cấp. Mọi
người được tạo cơ hội để phát huy sức mạnh và sử dụng khả năng
của mình. Mọi người được khuyến khích sáng tạo trong thực hiện
nhiệm vụ.
Nguyên tắc 4. Phương pháp tiếp cận theo quy trình: Có một số lợi
thế khi thực hiện các nhiệm vụ chính bằng cách sử dụng khái niệm
quy trình. Quá trình là một chuỗi các hoạt động biến đổi đầu vào
thành đầu ra. Các tổ chức có thể chuẩn bị một kế hoạch dưới hình
thức phân bổ nguồn lực và lập lịch trình cho các hoạt động bằng cách
làm cho quá trình được xác định, có thể lặp lại và có thể đo lường
được. Do đó, tổ chức trở nên hiệu quả và hiệu quả. Cải tiến liên tục
trong các quy trình dẫn đến cải thiện hiệu quả và hiệu lực.
Nguyên tắc 5. Phương pháp tiếp cận hệ thống để quản lý: Hệ
thống là một tập hợp các quá trình tương tác. Toàn bộ tổ chức có thể
được xem như một hệ thống các quá trình tương tác. Trong bối cảnh
phát triển phần mềm, chúng ta có thể xác định một số quy trình. Ví
dụ, thu thập các yêu cầu của khách hàng cho một dự án là một quá
trình riêng biệt liên quan đến các kỹ năng chuyên biệt. Tương tự, việc
thiết kế một đặc tả chức năng bằng cách lấy các yêu cầu làm đầu vào
là một quá trình khác biệt. Có các quy trình đồng thời và tuần tự
được thực hiện trong một tổ chức. Tại bất kỳ thời điểm nào, mọi
người đều tham gia vào một hoặc nhiều quy trình. Một quá trình bị
ảnh hưởng bởi kết quả của một số quá trình khác, và đến lượt nó, nó
ảnh hưởng đến một số quá trình khác trong tổ chức. Điều quan trọng
là phải hiểu mục tiêu chung của tổ chức và các mục tiêu phụ riêng lẻ
liên quan đến mỗi quá trình. Để một tổ chức nói chung thành công về
mặt hiệu lực và hiệu quả, các mối tương tác giữa các quá trình phải
được xác định và phân tích.
Nguyên tắc 6. Cải tiến liên tục: Cải tiến liên tục có nghĩa là các quy
trình liên quan đến phát triển sản phẩm phần mềm được xem xét định
kỳ để xác định vị trí và cách thức thực hiện các cải tiến tiếp theo
trong quy trình. Vì không có quy trình nào có thể là hoàn hảo để bắt
đầu, cải tiến liên tục đóng một vai trò quan trọng trong sự thành công
của tổ chức. Vì có những thay đổi độc lập trong nhiều lĩnh vực,
chẳng hạn như quan điểm của khách hàng và công nghệ, nên việc
xem xét các quy trình và tìm kiếm cải tiến là điều đương nhiên. Cải
tiến quy trình liên tục dẫn đến chi phí sản xuất và bảo trì thấp hơn.
Hơn nữa, những cải tiến liên tục dẫn đến ít khác biệt hơn giữa hành
vi mong đợi và hành vi thực tế
của sản phẩm. Các tổ chức cần phát triển các chính sách của riêng
mình về thời điểm bắt đầu đánh giá quá trình và xác định các mục
tiêu của quá trình đánh giá.
Nguyên tắc 7. Phương pháp tiếp cận thực tế để ra quyết định:
Các quyết định có thể được đưa ra dựa trên sự kiện, kinh nghiệm và
trực giác. Sự thật có thể được thu thập bằng cách sử dụng quy trình
đo âm thanh. Xác định và định lượng các tham số là trọng tâm của
phép đo. Khi các nguyên tố đã được định lượng, việc thiết lập các
phương pháp đo các nguyên tố đó sẽ trở nên dễ dàng hơn. Cần có các
phương pháp xác nhận dữ liệu đo được và cung cấp dữ liệu cho
những người cần. Dữ liệu đo phải chính xác và đáng tin cậy. Một
chương trình đo lường định lượng giúp tổ chức biết được mức độ cải
tiến đã đạt được do cải tiến quy trình.
Nguyên tắc 8. Mối quan hệ nhà cung cấp cùng có lợi: Các tổ chức
hiếm khi tạo ra tất cả các thành phần mà họ sử dụng trong sản phẩm
của mình. Các tổ chức thường mua các thành phần và hệ thống con
từ các bên thứ ba. Một tổ chức phải lựa chọn cẩn thận các nhà cung
cấp và làm cho họ nhận thức được các nhu cầu và mong đợi của tổ
chức. Hiệu suất của các sản phẩm được mua từ bên ngoài cần được
đánh giá và nhu cầu cải tiến các sản phẩm và quy trình của chúng
phải được thông báo cho các nhà cung cấp. Cần duy trì mối quan hệ
hợp tác cùng có lợi với các nhà cung cấp.
17.4.2 Các yêu cầu của ISO 9001: 2000
Trong phần này, chúng tôi sẽ mô tả ngắn gọn năm phần chính của
tiêu chuẩn ISO 9001: 2000. Để biết thêm chi tiết, chúng tôi đề nghị
người đọc tham khảo tài liệu tham khảo 8. Năm phần chính của tiêu
chuẩn ISO 9001: 2000, trong phần 4–8, sẽ được trình bày tiếp theo.
Phần 4: Yêu cầu hệ thống Khái niệm về hệ thống quản lý chất
lượng (QMS) là cốt lõi của phần 4 của tài liệu ISO 2001: 2000. Hệ
thống quản lý chất lượng được xác định theo chính sách chất lượng
và mục tiêu chất lượng. Trong bối cảnh phát triển phần mềm, một ví
dụ về chính sách chất lượng là xem xét tất cả các sản phẩm công việc
bởi ít nhất hai người có kỹ năng. Một chính sách chất lượng khác là
thực hiện tất cả các trường hợp thử nghiệm trong ít nhất hai chu kỳ
thử nghiệm trong quá trình thử nghiệm hệ thống. Tương tự, một ví dụ
về mục tiêu chất lượng là sửa chữa tất cả các lỗi gây ra sự cố hệ
thống trước khi phát hành. Các cơ chế được yêu cầu phải được xác
định dưới dạng các quá trình để thực hiện các chính sách chất lượng
và đạt được các mục tiêu chất lượng. Hơn nữa, cần phải xác định các
cơ chế để cải tiến hệ thống quản lý chất lượng. Các hoạt động nhằm
thực hiện chính sách chất lượng và đạt được các mục tiêu chất lượng
được xác định dưới dạng các quá trình chất lượng tương tác. Ví dụ,
xem xét yêu cầu có thể được coi là một quá trình riêng biệt. Tương
tự, kiểm tra mức hệ thống là một quá trình khác trong hệ thống chất
lượng. Sự tương tác giữa các quá trình nói trên xảy ra do nhu cầu làm
cho tất cả các yêu cầu có thể kiểm tra được và nhu cầu xác minh rằng
tất cả các yêu cầu đã thực sự được kiểm tra đầy đủ. Tương tự, đo
lường và phân tích là những quá trình quan trọng trong phát triển
phần mềm hiện đại. Các cải tiến trong hệ thống quản lý chất lượng
hiện có đạt được bằng cách xác định quy trình đo lường và phân tích
cũng như xác định các khu vực cần cải tiến.
Tài liệu là một phần quan trọng của QMS. Không có QMS mà không
có tài liệu thích hợp. QMS phải được lập thành văn bản thích hợp
bằng cách xuất bản sổ tay chất lượng. Sổ tay chất lượng mô tả các
chính sách chất lượng và mục tiêu chất lượng. Các thủ tục để thực
hiện QMS cũng được lập thành văn bản. Khi QMS phát triển bằng
cách kết hợp các chính sách và mục tiêu được cải tiến, các tài liệu
theo đó phải được kiểm soát. Tài liệu QMS phải tạo điều kiện thuận
lợi cho việc lập kế hoạch, thực hiện và quản lý các quá trình của tổ
chức một cách hiệu quả và hiệu quả. Các hồ sơ được tạo ra từ kết quả
của việc thực hiện các quy trình của tổ chức được lập thành văn bản
và xuất bản để thể hiện bằng chứng rằng các yêu cầu khác nhau của
ISO 9001: 2000 đã được đáp ứng. Tất cả các chi tiết về quy trình và
các tương tác trong quy trình tổ chức đều được ghi lại. Tài liệu rõ
ràng là chìa khóa để hiểu cách một quy trình bị ảnh hưởng bởi quy
trình khác. Phần tài liệu có thể được tóm tắt như sau:
Ghi lại các chính sách và mục tiêu của tổ chức. Công bố tầm nhìn của
tổ chức.
Ghi lại tất cả các quá trình chất lượng và mối quan hệ qua lại của
chúng.
Thực hiện cơ chế phê duyệt tài liệu trước khi chúng được phân phối.
Xem xét và phê duyệt các tài liệu cập nhật.
Giám sát tài liệu đến từ nhà cung cấp.
Ghi lại hồ sơ cho thấy rằng các yêu cầu đã được đáp ứng.
Ghi lại một thủ tục để kiểm soát hồ sơ.
Phần 5: Yêu cầu về quản lý Khái niệm chất lượng không thể được
giải quyết từng chút một bởi các nhà phát triển và kỹ sư thử nghiệm
riêng lẻ. Thay vào đó, quản lý cấp trên phải chấp nhận thực tế rằng
chất lượng là một khái niệm phổ biến. Lãnh đạo cấp trên phải nỗ lực
để thấy rằng toàn bộ tổ chức đều nhận thức được các chính sách chất
lượng và các mục tiêu chất lượng. Điều này đạt được bằng cách xác
định và xuất bản Hệ thống quản lý chất lượng cũng như đặt ra một cơ
chế để cải tiến liên tục. QMS của tổ chức phải được hỗ trợ bởi quản
lý cấp trên với loại và số lượng nguồn lực phù hợp. Sau đây là một số
hoạt động quan trọng để quản lý cấp trên thực hiện về vấn đề này:
Nâng cao nhận thức về chất lượng để đáp ứng nhiều yêu cầu khác
nhau, chẳng hạn như khách hàng, quy định và luật định.
Xây dựng Hệ thống quản lý chất lượng bằng cách xác định các chính
sách và mục tiêu của tổ chức liên quan đến chất lượng, phát triển cơ
chế để thực hiện các chính sách và mục tiêu đó, đồng thời phân bổ
nguồn lực để thực hiện các chính sách và mục tiêu đó.
Xây dựng cơ chế cải tiến liên tục Hệ thống quản lý chất lượng.
Tập trung vào khách hàng bằng cách xác định và đáp ứng các yêu cầu
của họ để thỏa mãn họ.
Xây dựng chính sách chất lượng để đáp ứng nhu cầu của khách hàng,
phục vụ chính tổ chức và làm cho nó có thể phát triển theo những
thay đổi của thị trường và những phát triển mới trong công nghệ.
Đối phó với khái niệm chất lượng một cách có kế hoạch bằng cách
đảm bảo rằng các mục tiêu chất lượng được đặt ra ở cấp độ tổ chức,
các mục tiêu chất lượng hỗ trợ chính sách chất lượng và các mục tiêu
chất lượng có thể đo lường được.
Xác định rõ trách nhiệm và quyền hạn của từng cá nhân liên quan đến
việc thực hiện các chính sách chất lượng.
Bổ nhiệm người quản lý có trách nhiệm và quyền hạn để giám sát
việc thực hiện Hệ thống quản lý chất lượng của tổ chức. Vị trí như
vậy cho thấy tầm nhìn rõ ràng về QMS của tổ chức đối với thế giới
bên ngoài, cụ thể là đối với khách hàng.
Truyền đạt hiệu quả của QMS cho nhân viên để nhân viên có vị trí tốt
hơn trong việc hình thành các cải tiến trong mô hình QMS hiện có. •
Định kỳ xem xét hệ thống quản lý chất lượng để đảm bảo rằng hệ
thống quản lý chất lượng là một hệ thống hiệu quả và nó đáp ứng đầy
đủ các mục tiêu và chính sách của tổ chức để làm hài lòng khách
hàng. Dựa trên kết quả xem xét và những thay đổi trên thị trường và
công nghệ, cần thực hiện các hành động để cải thiện mô hình bằng
cách đặt ra các chính sách tốt hơn và các mục tiêu cao hơn.
Phần 6: Yêu cầu về nguồn lực Các nguồn lực là chìa khóa để đạt
được các chính sách và mục tiêu của tổ chức. Các tuyên bố về chính
sách và mục tiêu phải được sao lưu với việc phân bổ đúng loại và số
lượng nguồn lực. Có nhiều loại nguồn lực khác nhau, cụ thể là nhân
viên, thiết bị, công cụ, tài chính và tòa nhà, để đặt tên cho những
nguồn lực chính. Thông thường, các nguồn lực khác nhau được kiểm
soát bởi các bộ phận khác nhau của một tổ chức. Nói chung, các
nguồn lực được phân bổ cho các dự án trên cơ sở cần thiết. Vì mọi
hoạt động trong một tổ chức đều cần một số loại tài nguyên, các quy
739
trình quản lý tài nguyên tương tác với các loại quy trình khác. Các
hoạt động quan trọng liên quan đến quản lý tài nguyên như sau:
Xác định và cung cấp các nguồn lực cần thiết để hỗ trợ chính sách
chất lượng của tổ chức nhằm thực hiện các mục tiêu chất lượng. Ở
đây, yếu tố quan trọng là xác định các nguồn lực để có thể đáp ứng —
và thậm chí vượt quá mong đợi của khách hàng.
Phân bổ nguồn nhân lực chất lượng cho các dự án. Ở đây, chất lượng
nhân sự được định nghĩa ở các khía cạnh giáo dục, đào tạo, kinh
nghiệm và kỹ năng. • Có cơ chế nâng cao trình độ chất lượng của
nhân sự. Điều này có thể đạt được bằng cách xác định mức năng lực
thấp hơn có thể chấp nhận được. Để nhân sự có thể đạt đến mức năng
lực tối thiểu có thể chấp nhận được, điều quan trọng là phải xác định
và hỗ trợ một chương trình đào tạo hiệu quả. Hiệu quả của chương
trình đào tạo phải được đánh giá thường xuyên.
Cung cấp và duy trì các phương tiện, chẳng hạn như không gian văn
phòng, nhu cầu máy tính, nhu cầu thiết bị và dịch vụ hỗ trợ, để thực
hiện thành công QMS của tổ chức.
Quản lý môi trường làm việc, bao gồm các yếu tố vật lý, xã hội, tâm
lý và môi trường, có lợi cho việc tạo ra hiệu quả và hiệu lực của các
nguồn lực “con người”.
Phần 7: Yêu cầu về hiện thực Phần này đề cập đến các quy trình
biến các yêu cầu của khách hàng thành sản phẩm. Người đọc có thể
lưu ý rằng không có nhiều thay đổi từ ISO 9001: 1994 sang ISO
9001: 2000 trong phần hiện thực hóa. Các yếu tố chính của phần hiện
thực như sau:
Xây dựng một kế hoạch để hiện thực hóa một sản phẩm từ các yêu
cầu của nó. Các yếu tố quan trọng của một kế hoạch như vậy là xác
định các quá trình cần thiết để phát triển một sản phẩm, trình tự các
quá trình và kiểm soát các quá trình. Các mục tiêu chất lượng sản
phẩm và các phương pháp kiểm soát chất lượng trong quá trình phát
triển được xác định trong quá trình lập kế hoạch.
Để thực hiện một sản phẩm cho khách hàng, cần phải tương tác nhiều
với khách hàng để hiểu và nắm bắt các yêu cầu. Việc nắm bắt các yêu
cầu đối với một sản phẩm bao gồm việc xác định các loại yêu cầu
khác nhau, chẳng hạn như các yêu cầu do khách hàng tạo ra, các yêu
cầu bắt buộc khi sử dụng sản phẩm, các yêu cầu do các cơ quan bên
ngoài đặt ra và các yêu cầu được coi là hữu ích cho chính tổ chức. •
Xem xét các yêu cầu của khách hàng trước khi cam kết thực hiện dự
án. Các yêu cầu không có khả năng được đáp ứng sẽ bị từ chối trong
giai đoạn này. Hơn nữa, phát triển một quy trình giao tiếp với khách
hàng. Điều quan trọng là phải để khách hàng tham gia vào tất cả các
giai đoạn phát triển sản phẩm.
Sau khi các yêu cầu được xem xét và chấp nhận, việc thiết kế và phát
triển sản phẩm sẽ diễn ra:
Thiết kế và phát triển sản phẩm bắt đầu với việc lập kế hoạch: Xác
định các giai đoạn của thiết kế và phát triển, phân công các trách
nhiệm và quyền hạn khác nhau, quản lý sự tương tác giữa các nhóm
khác nhau và cập nhật kế hoạch khi có thay đổi.
Chỉ định và xem xét các yếu tố đầu vào để thiết kế và phát triển sản
phẩm.
Tạo và phê duyệt các đầu ra của thiết kế và phát triển sản phẩm. Sử
dụng kết quả đầu ra để kiểm soát chất lượng sản phẩm.
Định kỳ xem xét các kết quả đầu ra của thiết kế và phát triển để đảm
bảo rằng tiến độ đang được thực hiện.
Thực hiện xác minh thiết kế và phát triển trên kết quả đầu ra của
chúng.
Thực hiện xác nhận thiết kế và phát triển.
Quản lý các thay đổi có ảnh hưởng đến thiết kế và phát triển: Xác
định các thay đổi, ghi lại các thay đổi, xem xét các thay đổi, xác minh
các thay đổi, xác thực các thay đổi và phê duyệt các thay đổi.
Thực hiện theo quy trình mua hàng xác định bằng cách đánh giá các
nhà cung cấp tiềm năng dựa trên một số yếu tố, chẳng hạn như khả
năng đáp ứng các yêu cầu và giá cả, đồng thời xác minh rằng sản
phẩm đã mua đáp ứng các yêu cầu của nó.
Đưa ra cơ chế và cơ sở hạ tầng để kiểm soát sản xuất. Điều này bao
gồm các thủ tục xác nhận các quy trình sản xuất, các thủ tục xác định
và theo dõi cả các mặt hàng cụ thể và trừu tượng, các thủ tục
để bảo vệ các tài sản do bên ngoài cung cấp và các thủ tục bảo quản
các thành phần và sản phẩm của tổ chức.
Xác định các nhu cầu giám sát và đo lường và lựa chọn các thiết bị
thích hợp để thực hiện các công việc đó. Điều quan trọng là phải hiệu
chỉnh và bảo trì các thiết bị đó. Cuối cùng, sử dụng các thiết bị đó để
thu thập dữ liệu hữu ích để biết rằng sản phẩm đáp ứng các yêu cầu.
741
Phần 8: Yêu cầu về khắc phục Phần này liên quan đến việc đo
lường, phân tích dữ liệu đo lường và cải tiến liên tục. Việc đo lường
các chỉ số hoạt động của các quá trình cho phép người ta xác định
một quá trình đang hoạt động tốt như thế nào. Nếu quan sát thấy rằng
một quá trình đang hoạt động dưới mức mong muốn, thì hành động
khắc phục có thể được thực hiện để cải thiện hiệu suất của quá trình.
Hãy xem xét ví dụ sau. Chúng tôi tìm ra các nguồn gốc của lỗi trong
quá trình kiểm tra và đếm cấp hệ thống, chẳng hạn như những nguồn
được đưa vào trong giai đoạn thiết kế. Nếu phát hiện có quá nhiều
khuyết tật được đưa vào trong giai đoạn thiết kế, thì cần phải thực
hiện các hành động để giảm số khuyết tật. Ví dụ, một kỹ thuật xem
xét thiết kế thay thế có thể được giới thiệu để phát hiện những khiếm
khuyết trong giai đoạn thiết kế. Trong trường hợp không có phép đo,
rất khó để đưa ra quyết định khách quan liên quan đến cải tiến quy
trình. Vì vậy, đo lường là một hoạt động quan trọng trong một ngành
kỹ thuật. Phần 8 của tiêu chuẩn ISO 9001: 2000 đề cập đến một loạt
các nhu cầu đo lường hiệu suất như được giải thích như sau:
Sự thành công của một tổ chức phần lớn được quyết định bởi sự hài
lòng của khách hàng. Do đó, tiêu chuẩn này yêu cầu các tổ chức phát
triển các phương pháp và thủ tục để đo lường và theo dõi mức độ hài
lòng của khách hàng một cách liên tục. Ví dụ: số lượng cuộc gọi đến
đường dây trợ giúp của một tổ chức có thể được coi là thước đo mức
độ hài lòng của khách hàng — quá nhiều cuộc gọi là thước đo mức
độ hài lòng của khách hàng kém hơn.
Một tổ chức cần lập kế hoạch và thực hiện đánh giá nội bộ một cách
thường xuyên để theo dõi trạng thái của hệ thống quản lý chất lượng
của tổ chức. Một ví dụ về đánh giá nội bộ là để tìm hiểu xem liệu
nhân sự có trình độ học vấn, kinh nghiệm và kỹ năng thích hợp có
được chỉ định vào một dự án hay không. Đánh giá nội bộ cần được
thực hiện bởi các kiểm toán viên độc lập theo một thủ tục được lập
thành văn bản. Các biện pháp khắc phục dự kiến sẽ được thực hiện để
giải quyết bất kỳ thiếu sót nào được kiểm toán viên phát hiện.
Tiêu chuẩn yêu cầu rằng cả hai quá trình, bao gồm các quá trình
QMS và sản phẩm phải được giám sát bằng cách sử dụng một bộ các
chỉ số hiệu suất chính. Một ví dụ về đo lường các đặc tính của sản
phẩm là xác minh xem một sản phẩm có đáp ứng các yêu cầu của nó
hay không. Tương tự, một ví dụ về đo lường các đặc tính của quá
trình là xác định mức độ mô-đun của một hệ thống phần mềm.
Kết quả của việc đo lường các đặc tính của sản phẩm, có thể phát
hiện ra rằng một sản phẩm không đáp ứng các yêu cầu của nó. Các tổ
chức cần đảm bảo rằng các sản phẩm đó không được phát hành cho
khách hàng. Nguyên nhân của sự khác biệt giữa sản phẩm mong đợi
và sản phẩm thực cần được xác định.
Tiêu chuẩn yêu cầu dữ liệu thu thập được trong các quá trình đo
lường phải được phân tích để đưa ra các quyết định khách quan. Phân
tích dữ liệu được thực hiện để xác định hiệu quả của QMS, tác động
của những thay đổi được thực hiện đối với QMS, mức độ hài lòng
của khách hàng, sự phù hợp của sản phẩm với yêu cầu của họ và hiệu
suất của sản phẩm và nhà cung cấp.
Chúng tôi cho rằng các sản phẩm có khuyết tật, vì quy trình sản xuất
có thể không hoàn hảo. Tuy nhiên, một khi đã biết rằng có những
khiếm khuyết trong sản phẩm do thiếu sót trong các quá trình được sử
dụng, thì cần phải nỗ lực để cải tiến các quá trình. Cải tiến quy trình
bao gồm cả hành động khắc phục và hành động phòng ngừa nhằm
nâng cao chất lượng sản phẩm.
17.5 TÓM TẮT
Khái niệm chất lượng phần mềm rất rộng, và do đó, sẽ rất hữu ích
nếu xem xét nó từ các quan điểm khác nhau. Năm 1984, Garvin [1]
phân tích khái niệm chất lượng - của các sản phẩm nói chung, không
đặc biệt là các sản phẩm phần mềm - từ năm quan điểm, đó là quan
điểm siêu nghiệm, quan điểm người dùng, chế độ xem sản xuất, chế
độ xem sản phẩm và quan điểm dựa trên giá trị. Theo quan điểm siêu
việt, chất lượng là thứ chỉ có thể cảm nhận được thông qua kinh
nghiệm. Quan điểm của người dùng quan tâm đến mức độ sản phẩm
đáp ứng nhu cầu và mong đợi của người dùng. Theo quan điểm sản
xuất, chất lượng được cảm nhận thông qua sự phù hợp với quy trình
sản xuất. Theo quan điểm về sản phẩm, phẩm chất tốt bên trong của
sản phẩm chuyển thành phẩm chất tốt bên ngoài của sản phẩm. Quan
điểm dựa trên giá trị liên quan đến số tiền người dùng sẵn sàng trả
cho một mức chất lượng nhất định.
Nó hữu ích để đo lường chất lượng vì ba lý do. Đầu tiên, đo lường
cho phép chúng tôi phát triển các đường cơ sở về chất lượng. Thứ
743
hai, vì cải tiến chất lượng có một chi phí liên quan, nên điều quan
trọng là phải biết cải tiến chất lượng đạt được bao nhiêu cho một chi
phí nhất định. Cuối cùng, sẽ rất hữu ích nếu biết mức chất lượng hiện
tại để có thể lập kế hoạch cải tiến hơn nữa.
Kỹ thuật của Gilb [5] để đo lường chất lượng, được nêu ở phần sau,
rất hữu ích trong việc đo lường các yếu tố chất lượng không thể đáp
ứng được bằng phép đo trực tiếp: Khái niệm chất lượng được chia
nhỏ liên tiếp thành các bộ phận thành phần của nó cho đến khi mỗi bộ
phận có thể được biểu thị bằng một số trực tiếp. các thuộc tính có thể
đo lường được.
Việc đo lường chế độ xem dễ dàng hơn. Hai số liệu được sử dụng
rộng rãi là số lượng lỗi và chi phí làm lại. Số liệu đầu tiên đề cập đến
số lượng lỗi đã được phát hiện, trong khi số liệu thứ hai đề cập đến
chi phí để sửa chữa các lỗi đã biết. Số lượng khuyết tật có thể được
phân tích để cung cấp cho chúng tôi ý tưởng tốt hơn về quá trình phát
triển. Ví dụ, mỗi lỗi có thể được truy tìm từ một giai đoạn của quá
trình phát triển phần mềm mà lỗi được đưa vào. Các cải tiến cần được
thực hiện đối với các giai đoạn mà một phần lớn các khuyết tật được
đưa vào. Tương tự, cần thực hiện các cải tiến đối với các giai đoạn
mà các khiếm khuyết nghiêm trọng được đưa vào. Ví dụ thứ hai về
phân tích số lượng khuyết tật là xác định các mô-đun có chứa một số
lượng lớn các khuyết tật. Một ví dụ thứ ba về phân tích số lượng
khuyết tật là tách các khuyết tật được phát hiện trong quá trình phát
triển với những khuyết tật được phát hiện
17.5 TÓM TẮT
trong quá trình hoạt động. Nếu một số lượng lớn các khuyết tật được
tìm thấy trong quá trình vận hành, người ta có thể kết luận rằng quá
trình kiểm tra cần được cải thiện nhiều. Ví dụ thứ tư về việc sử dụng
số lượng khuyết tật là có thể so sánh các mô-đun khác nhau về mật độ
khuyết tật.
Tương tự, chi phí làm lại có thể được phân tích thành hai phần: chi
phí làm lại trước và chi phí làm lại sau vui lòng làm lại. Chi phí làm
lại trước là thước đo hiệu quả phát triển, trong khi chi phí làm lại sau
làm lại là thước đo chất lượng được cung cấp của hệ thống.
Một khái niệm khác về chất lượng phần mềm, thường được gọi là các
yếu tố chất lượng của McCall, được đề xuất bởi McCall, Richards và
Walters vào năm 1977 [6]. Họ đã nghiên cứu khái niệm chất lượng
phần mềm về các yếu tố chất lượng và tiêu chí chất lượng. Tiêu chí
chất lượng là một thuộc tính của yếu tố chất lượng. McCall và cộng
sự. xác định 23 tiêu chí chất lượng. Một số ví dụ về tiêu chí chất
lượng là tính mô-đun, khả năng truy xuất nguồn gốc, tính đơn giản và
tính đầy đủ. Tóm lại, yếu tố chất lượng thể hiện đặc tính hành vi của
hệ thống, và McCall et al. đề xuất 11 yếu tố chất lượng: tính đúng
đắn, độ tin cậy, hiệu quả, tính toàn vẹn, khả năng sử dụng, khả năng
bảo trì, khả năng kiểm tra, tính linh hoạt, tính di động, khả năng tái sử
dụng và khả năng tương tác. 11 yếu tố chất lượng được phân loại
thành ba loại: vận hành sản phẩm, sửa đổi sản phẩm và chuyển đổi
sản phẩm. Hoạt động của sản phẩm liên quan đến tính đúng đắn, độ
tin cậy, hiệu quả, tính toàn vẹn và khả năng sử dụng. Việc sửa đổi sản
phẩm liên quan đến khả năng bảo trì, khả năng kiểm tra và tính linh
hoạt. Chuyển đổi sản phẩm liên quan đến tính di động, khả năng tái
sử dụng và khả năng tương tác.
Một sáng kiến toàn cầu để hiểu khái niệm về chất lượng phần mềm
đã được thực hiện bởi các chuyên gia trên khắp thế giới. Nỗ lực hợp
tác của họ đã dẫn đến việc tiêu chuẩn hóa khái niệm chất lượng của
ISO dưới dạng các tài liệu ISO 9126 và ISO 9000: 2000. Tài liệu ISO
9126 là về các đặc tính chất lượng, trong khi tài liệu ISO 9000: 2000
là tiêu chuẩn đảm bảo chất lượng. Yếu tố chất lượng trong mô hình
McCall được gọi là đặc tính chất lượng trong mô hình ISO 9126. Tuy
nhiên, có một số khác biệt giữa hai mô hình. Mô hình ISO 9126 tập
trung vào các đặc điểm mà người dùng có thể nhìn thấy, trong khi mô
hình McCall cũng nhấn mạnh chất lượng bên trong.
Sẽ rất hữu ích nếu bạn cần lưu ý một vài mối quan tâm về các mô
hình chất lượng được thảo luận trong chương này. Không có sự nhất
trí về yếu tố chất lượng cấp cao nào là quan trọng nhất ở cấp cao
nhất. Hơn nữa, không có sự nhất trí nào về yếu tố chất lượng cấp cao
nhất và yếu tố chất lượng cấp thấp, tức là thuộc tính / đặc điểm phụ
cụ thể, chất lượng.
Có ba thành phần của tiêu chuẩn ISO 9000: 2000, đó là ISO 9000,
ISO 9001 và ISO 9004. Tài liệu ISO 9000 là về các nguyên tắc cơ
bản và từ vựng, tài liệu ISO 9001 là về các yêu cầu và tài liệu ISO
9004 bao gồm các hướng dẫn về cải tiến hiệu suất.
Tài liệu ISO 9000 dựa trên tám nguyên tắc: tập trung vào khách hàng,
lãnh đạo, sự tham gia của mọi người, cách tiếp cận theo quy trình,
745
cách tiếp cận hệ thống để quản lý, cải tiến liên tục, cách tiếp cận thực
tế để ra quyết định và mối quan hệ nhà cung cấp cùng có lợi. Tài liệu
ISO 9001 đề cập đến năm loại yêu cầu sau: yêu cầu hệ thống, yêu cầu
quản lý, yêu cầu nguồn lực, yêu cầu hiện thực hóa và yêu cầu khắc
phục.
Một số sách và bài báo đã được viết về đảm bảo chất lượng phần
mềm và các mô hình chất lượng. Số tháng 1 năm 1996 của IEEE
Software được dành cho chất lượng phần mềm. Số đặc biệt trình bày
một số bài báo đề cập đến các chủ đề sau: đóng góp của các tiêu
chuẩn vào chất lượng sản phẩm, kết quả chất lượng về mặt giá trị
kinh doanh, hỗ trợ thiết kế và kiểm tra dựa trên chất lượng, chất
lượng phần mềm trong điện tử tiêu dùng và một nghiên cứu điển hình
về dự đoán chất lượng sớm trong hệ thống viễn thông.
Trong cuốn sách Đường đến chất lượng phần mềm [10], Jarvis và V
Crandall tập trung vào hai cách tiếp cận để đảm bảo chất lượng. Cách
tiếp cận đầu tiên là sử dụng các phương pháp định hướng chất lượng
như quản lý chất lượng toàn diện, ISO 9000 và các cấp độ SEI CMM.
Cách tiếp cận thứ hai của họ dựa trên ý tưởng xây dựng chất lượng
thành sản phẩm có thể phân phối ngay từ đầu và trong suốt quá trình
phát triển sản phẩm.
Trong cuốn sách Đảm bảo Chất lượng Phần mềm: Nguyên tắc và
Thực hành [11], Godbole trình bày các nguyên tắc và thực hành đảm
bảo chất lượng một cách toàn diện. Cuốn sách nhấn mạnh nhiều vào
việc lập kế hoạch đảm bảo chất lượng, chất lượng sản phẩm và chất
lượng quy trình, kiểm thử phần mềm, kiểm tra và hướng dẫn, và các
mô hình cải tiến chất lượng, chẳng hạn như mô hình ISO 9000 và
CMM.
Trong cuốn sách Đảm bảo chất lượng phần mềm [12], Galin trình bày
một cách tổng quan toàn diện về chất lượng phần mềm và đảm bảo
chất lượng phần mềm (SQA). Các chủ đề bổ sung được đề cập trong
cuốn sách của Galin là các thành phần khác nhau của hệ thống đảm
bảo chất lượng phần mềm, chẳng hạn như kiến trúc SQA, các thành
phần chất lượng phần mềm tiền dự án, các thành phần SQA trong
vòng đời dự án, các thành phần cơ sở hạ tầng chất lượng phần mềm
và các thành phần quản lý chất lượng phần mềm. Ví dụ, xem xét và
phát triển hợp đồng và các kế hoạch chất lượng là các thành phần
chất lượng phần mềm tiền dự án. Tương tự, đánh giá và chiến lược
kiểm thử phần mềm là các thành phần trong vòng đời của dự án. Ví
dụ về các thành phần cơ sở hạ tầng là các thủ tục và hướng dẫn công
việc và đào tạo nhân viên. Một số thành phần quản lý chất lượng
phần mềm là kiểm soát tiến độ dự án và các thước đo chất lượng phần
mềm. Một thành phần ví dụ của tiêu chuẩn, chứng nhận và đánh giá
là quản lý chất lượng bằng cách sử dụng ISO 9000 và CMM.
DA Garvin. “Chất lượng sản phẩm” thực sự có ý nghĩa gì? Tạp chí
Quản lý Sloan, Mùa thu 1984, trang 25–43.
M. Paulk, B. Curtis, MB Chrissis và CV Weber. Mô hình trưởng
thành năng lực, Phiên bản 1.1. Phần mềm IEEE, tháng 7 năm 1993,
trang 18–27.
M. Paulk, B. Curtis, MB Chrissis và CV Weber. So sánh ISO 9001
với Phần mềm CMM.IEEE, tháng 1 năm 1995, trang 74–83.
B. Kitchenham và SL Pfleeger. Chất lượng phần mềm: Mục tiêu khó
nắm bắt. Phần mềm IEEE, tháng 1 năm 1996, trang 12–21.
T. Gilb. Nguyên tắc Quản lý Kỹ thuật Phần mềm. Addison-Wesley,
Reading, MA, 1987.
JA McCall, PK Richards và GF Walters. Yếu tố chất lượng phần
mềm, Vol. 1, ADA 049014. Dịch vụ Thông tin Kỹ thuật Quốc gia, >
Springfield, VA, 1977.
Tổ chức Tiêu chuẩn hóa Quốc tế (ISO). Hệ thống quản lý chất lượng
- nguyên tắc cơ bản và Từ vựng, ISO 9000: 2000. ISO, Geneva, tháng
12 năm 2000.
CHAPTER
18
MaturityModels
Chúng ta là sản phẩm của 4,5 tỷ năm tiến hóa sinh học chậm chạp,
ngẫu nhiên. Không có lý do gì để nghĩ rằng quá trình tiến hóa đã
dừng lại. Con người là động vật chuyển tiếp. Anh ấy không phải là
đỉnh cao của tạo hóa.
-Carl Sagan
18.1 Ý TƯỞNG CƠ BẢN TRONG QUÁ TRÌNH PHẦN MỀM
Khái niệm về quy trình đóng một vai trò quan trọng trong sự phát
triển phần mềm ngày nay. Không có quy trình lặp lại, kết quả lặp lại
duy nhất mà bạn có khả năng tạo ra là lỗi [1]. Trong bối cảnh kỹ thuật
phần mềm, một quy trình bao gồm một tập hợp các hoạt động được
thực hiện để phát triển các sản phẩm phần mềm. Các hoạt động tìm ra
các biểu hiện dưới dạng phương pháp, kỹ thuật, chiến lược, thủ tục và
thực hành. Những hoạt động đó chủ yếu dựa vào kho thông tin như
tài liệu, tiêu chuẩn và chính sách. Các quy trình khác nhau được thúc
đẩy bởi các mục tiêu khác nhau và sự sẵn có của các nguồn lực. Khái
niệm quy trình không chỉ được áp dụng để phát triển mã nguồn mà
còn cho các sản phẩm liên quan đến phần mềm khác, chẳng hạn như
kế hoạch dự án, tài liệu yêu cầu, tài liệu thiết kế và hướng dẫn sử
dụng. Sẽ có hiệu quả nếu tuân theo một quy trình xác định vì những
lợi ích sau:
Quá trình này có thể được lặp lại trong các dự án tiếp theo.
Quá trình có thể được đánh giá bằng cách sử dụng nhiều số liệu khác
nhau, chẳng hạn như chi phí, chất lượng và thời gian để cung cấp một
sản phẩm.
Có thể thực hiện các hành động để cải thiện quy trình nhằm đạt được
kết quả tốt hơn.
Quy trình phát triển phần mềm bao gồm một số quy trình khác nhau
cho các nhiệm vụ thành phần khác nhau của nó. Ví dụ, tập hợp các
yêu cầu của hệ thống, xây dựng đặc tả chức năng của hệ thống, thiết
748 CHƯƠNG 18 CÁC MÔ HÌNH NĂNG LỰC
kế hệ thống, kiểm tra hệ thống và bảo trì hệ thống là những nhiệm vụ

khác nhau được thực hiện trong vòng đời của hệ thống phần mềm.
Những nhiệm vụ khác nhau, hoàn toàn khác với từng
546
18.1 Ý TƯỞNG CƠ BẢN TRONG QUÁ TRÌNH PHẦN MỀM
khác, cần phải tuân theo các quy trình khác nhau. Quy trình thu thập
yêu cầu về cơ bản khác với quy trình thử nghiệm. Tương tự, một quá
trình thiết kế rất khác với một quá trình thử nghiệm. Tuy nhiên,
không thể loại trừ một số điểm tương đồng giữa quy trình bảo trì và
quy trình thử nghiệm vì nhiệm vụ bảo trì có thể liên quan đến những
thay đổi đáng kể đối với thiết kế của hệ thống cũng như kiểm tra
nghiêm ngặt.
Kiểm thử phần mềm được coi là một quá trình riêng biệt vì nó liên
quan đến nhiều hoạt động, kỹ thuật, chiến lược và chính sách độc đáo
như được giải thích trong phần sau:
Thử nghiệm được thực hiện để đạt được các mục tiêu sau:
Tiết lộ các khiếm khuyết trong các sản phẩm phần mềm
Chỉ ra mức độ mà một hệ thống phần mềm sở hữu các thuộc tính chất
lượng khác nhau, chẳng hạn như độ tin cậy, hiệu suất, độ ổn định và
khả năng mở rộng
Thử nghiệm bắt đầu gần như cùng lúc khi một dự án được hình thành
ý tưởng và nó kéo dài chừng nào hệ thống còn tồn tại.
Kiểm thử được thực hiện bởi những người có trách nhiệm khác nhau
trong các giai đoạn phát triển phần mềm khác nhau. Các cấp độ kiểm
thử khác nhau đó thường được gọi là kiểm thử đơn vị, kiểm thử tích
hợp, kiểm thử hệ thống và kiểm thử chấp nhận.
Một số kỹ thuật có thể được áp dụng ở mỗi cấp độ kiểm thử để tạo
các trường hợp kiểm thử.
Một số chiến lược kiểm tra khác nhau có thể được áp dụng ở các cấp
độ kiểm tra khác nhau.
Một số chỉ số có thể được theo dõi để đánh giá tiến trình thử nghiệm.
Một số chỉ số có thể được theo dõi để phản ánh chính xác các mức
chất lượng khác nhau của hệ thống.
749
Thử nghiệm chịu ảnh hưởng của các chính sách của tổ chức, chẳng
hạn như mức chất lượng cần đạt được trong một sản phẩm, phần tổng
ngân sách cho một dự án được phân bổ cho thử nghiệm và thời gian
thử nghiệm.
Kiểm thử có thể được thực hiện trong sự kết hợp của các phương
thức thực hiện các trường hợp kiểm thử thủ công và tự động.
Để có thể cải tiến một quy trình đã xác định, tổ chức cần đánh giá các
khả năng và hạn chế của nó. Ví dụ, mô hình trưởng thành năng lực
(CMM), được phát triển bởi Viện Kỹ thuật Phần mềm (SEI) tại Đại
học Carnegie Mellon, cho phép một tổ chức đánh giá các quy trình
phát triển phần mềm của mình. Mô hình hỗ trợ cải tiến quy trình gia
tăng. Đối với một tổ chức, thực tế hơn là phát triển một quy trình cải
tiến liên tục hơn là tìm một quy trình “vừa phải”. Bằng cách nhận ra
tầm quan trọng của kiểm thử như một quy trình riêng biệt - khác
nhiều so với quy trình tổng thể để phát triển phần mềm - một mô hình
riêng biệt, được gọi là mô hình kiểm thử trưởng thành (TMM), đã
được phát triển để đánh giá quy trình kiểm thử. Ngoài ra, để một tổ
chức có thể cải tiến quy trình thử nghiệm của mình, mô hình cải tiến
quy trình thử nghiệm (TPI) đã được phát triển.
18.2 MÔ HÌNH KHẢ NĂNG NĂNG LỰC
Trong quy trình phát triển phần mềm, chúng tôi tìm kiếm ba thuộc
tính mong muốn như sau:
Các sản phẩm có chất lượng cao nhất. Lý tưởng nhất là sản phẩm
không có khuyết tật. Tuy nhiên, trên thực tế, một số nhỏ các khuyết
tật với hậu quả ít nghiêm trọng hơn thường được dung thứ.
Các dự án được hoàn thành theo kế hoạch của họ, bao gồm cả tiến
độ.
Các dự án được hoàn thành trong phạm vi ngân sách được phân bổ.
Tuy nhiên, các nhà phát triển sản phẩm phần mềm lớn hiếm khi đạt
được ba thuộc tính trên. Do tính chất phức tạp của hệ thống phần
mềm, các sản phẩm được phát hành với các lỗi đã biết và chưa biết.
Các lỗi không xác định tự biểu hiện thành các lỗi không mong muốn
trong quá trình vận hành tại hiện trường, tức là khi chúng ta biết rằng
hệ thống đã được phát hành với các lỗi chưa biết. Trong nhiều tổ
chức, các dự án phần mềm thường bị trễ và vượt quá ngân sách. Do
góc độ kinh doanh trong phát triển phần mềm, điều quan trọng đối
với sự tồn tại của các tổ chức là phát triển các sản phẩm chất lượng
cao, chi phí thấp trong một thời gian ngắn. Để hướng tới mục tiêu đó,
các nhà nghiên cứu và nhà phát triển đang nghĩ ra các kỹ thuật và
công cụ mới. Tuy nhiên, việc đưa các kỹ thuật và công cụ mới vào
quy trình phải được lên kế hoạch cẩn thận để tạo ra hiệu quả cải tiến
sản phẩm.
Trong khi trao hợp đồng cho một tổ chức về một sản phẩm phần
mềm, khách hàng cần đạt được sự tin tưởng rằng tổ chức đó có khả
năng cung cấp sản phẩm mong muốn. Sự tự tin đó có thể đạt được
bằng cách đánh giá năng lực của các tổ chức. Bộ Quốc phòng Hoa Kỳ
là một khách hàng lớn của các hệ thống phần mềm, họ muốn đánh giá
năng lực của các nhà thầu phần mềm của mình. Bộ Quốc phòng
muốn có một khuôn khổ để đánh giá mức độ trưởng thành của các
quy trình phần mềm được sử dụng bởi các tổ chức. Vào khoảng năm
1986, SEI đã bắt đầu phát triển một khuôn khổ để đánh giá sự trưởng
thành của quy trình.
Mức độ trưởng thành của quá trình phát triển cho chúng ta biết tổ
chức có khả năng sản xuất phần mềm chất lượng cao, chi phí thấp ở
mức độ nào. Do đó, khung đánh giá là CMM. Sau khi đánh giá mức
độ trưởng thành hiện tại của một quá trình phát triển, các tổ chức có
thể làm việc để cải thiện quá trình để đạt được mức độ chín muồi cao
hơn tiếp theo của quá trình. Trong khuôn khổ CMM, một quy trình có
năm cấp độ trưởng thành. Trước khi đi vào chi tiết về các mức độ
trưởng thành khác nhau, sẽ rất hữu ích nếu bạn có cái nhìn thoáng
qua về một quá trình chưa trưởng thành — một tổ chức có thể được
coi là chưa trưởng thành nếu nó tuân theo các quá trình chưa trưởng
thành [2].
Một mặt, một tổ chức chưa trưởng thành có thể không có một quy
trình xác định, và ngay cả khi có quy trình đó, tổ chức đó có thể
không tuân theo quy trình đó. Các nhà phát triển và quản lý phản ứng
với các vấn đề khi chúng xảy ra, thay vì thực hiện các biện pháp
phòng ngừa để loại bỏ chúng hoặc giảm tần suất xuất hiện của chúng.
Nói cách khác, các vấn đề về sản phẩm và quy trình được giải quyết
theo cách đặc biệt. Các ước tính về chi phí, tiến độ và chất lượng có
độ chính xác cao do không có chương trình đo lường để thu thập dữ
liệu quy trình. Do đó, các dự án vượt quá ước tính chi phí và thời gian
751
bởi một yếu tố lớn. Không có chương trình đo lường để đánh giá chất
lượng sản phẩm hoặc quá trình.
Mặt khác, một tổ chức trưởng thành thực hiện các hoạt động của
mình một cách có kế hoạch. Cả quá trình và đặc tính sản phẩm đều
được đo lường để theo dõi tiến độ và chất lượng của sản phẩm. Các
ước tính chính xác hơn do tuân theo một chương trình đo lường
nghiêm ngặt. Nhân viên được theo sát những phát triển mới thông
qua đào tạo. Nỗ lực không ngừng được thực hiện để nâng cao chất
lượng sản phẩm đồng thời giảm chi phí và thời gian thực hiện. Các
quy trình đã xác định được cập nhật liên tục để tận dụng các kỹ thuật,
công cụ và kinh nghiệm mới từ các dự án trước đây. Khi một tổ chức
ngày càng trưởng thành hơn, các tiêu chuẩn và chính sách của tổ
chức đóng vai trò quan trọng trong việc phát triển sản phẩm. Các tổ
chức trở nên trưởng thành theo cách thức gia tăng; nghĩa là, các quy
trình được cải thiện theo cách tiếp cận tiến hóa, thay vì tạo ra những
thay đổi mạnh mẽ.
Khi một tổ chức chuyển từ cấp độ này sang cấp độ tiếp theo, khả
năng xử lý của tổ chức được cải thiện để tạo ra phần mềm chất lượng
tốt hơn với chi phí thấp hơn. CMM xác định năm cấp độ trưởng
thành riêng biệt, trong đó cấp độ 1 là cấp độ ban đầu và cấp độ 5 là
cấp độ trưởng thành cao nhất của quá trình.
18.2.1 Kiến trúc CMM
Đầu tiên, chúng tôi giải thích khái niệm mức độ trưởng thành bằng
cách sử dụng Hình 18.1, sau đó là mô tả chi tiết về các mức độ riêng
lẻ. Hình 18.1 có thể được đọc như sau:
Mức độ trưởng thành cho biết khả năng của quy trình và chứa các
lĩnh vực quy trình chính (KPA). Các KPA cho mỗi cấp độ được liệt
kê trong Hình 18.2.
18.2 MÔ HÌNH KHẢ NĂNG NĂNG LỰC 753
Maturity levels
Indicate Contain
Process capability Key process areas
Achieve Organized by
Goals Common features
Address Contain
Implementation or
Key practices
institutionalization
Describe
Infrastructure or
activities
Hình 18.1 Cấu trúc CMM. (Từ ref. 3. © 2005 John Wiley &
Sons.)
Process change management Level 5: Optimizing
Technology change management Continuously improving
Defect prevention process
Software quality management Level 4: Managed

Quantitative process management Predictable process
Peer review
Intergroup coordination
Software product engineering
Integrated software management Level 3: Defined
Training program Standard consistent process
Organization process definition
Organization process focus
Software configuration management

Software quality assurance
Software subcontract management
Level 2: Repeatable
Software project tracking and oversight
Disciplined process
Software project planning
Requirements management
Initial Level 1
Hình 18.2 Các mức độ trưởng thành của SW-CMM. (Từ ref. 3.
© 2005 John Wiley & Sons.)
Các lĩnh vực quy trình chính được mong đợi để đạt được mục tiêu và
được tổ chức theo các đặc điểm chung.
Các đặc điểm chung bao gồm các thực hành chính và giải quyết việc
thực hiện hoặc thể chế hóa các thực hành chính.
Các thực hành chính mô tả cơ sở hạ tầng hoặc các hoạt động.
Khi các thực hành chính được tuân thủ, các mục tiêu của KPA dự
kiến sẽ đạt được.
Mức độ trưởng thành đạt được bằng cách đáp ứng tất cả các mục tiêu
của tất cả các KPA ở cấp độ đó.
18.2.2 Năm mức độ trưởng thành và các lĩnh vực quá trình chính
Năm cấp độ trưởng thành của quy trình và KPA của chúng được giải
thích như sau. KPA cho từng cấp độ trưởng thành được liệt kê trong
Hình 18.2.
Cấp độ 1: Ban đầu Ở cấp độ này, phần mềm được phát triển theo
mô hình không theo quy trình. Không có nhiều kế hoạch liên quan.
Ngay cả khi một kế hoạch được chuẩn bị, nó có thể không được tuân
theo. Các cá nhân đưa ra quyết định dựa trên năng lực và kỹ năng của
chính họ. Không có KPA nào liên quan đến cấp độ 1. Một tổ chức
đạt cấp độ 1 mà không cần nỗ lực.
Cấp độ 2: Tính lặp lại Ở cấp độ này, khái niệm về một quy trình tồn
tại để có thể lặp lại thành công cho các dự án tương tự. Hiệu suất của
các hoạt động đã được chứng minh của các dự án trước đây được sử
dụng để chuẩn bị kế hoạch cho các dự án trong tương lai. Mức độ
này có thể được tóm tắt là có kỷ luật vì các quy trình được sử dụng
để lặp lại. Tất cả các quá trình đều nằm dưới sự kiểm soát hiệu quả
của hệ thống quản lý dự án. Các KPA ở cấp độ 2 như sau:
Quản lý yêu cầu: Điều quan trọng là phải thiết lập sự hiểu biết
chung giữa khách hàng và nhà phát triển. Chi tiết của một dự án,
chẳng hạn như lập kế hoạch và quản lý, được hướng dẫn bởi một cái
nhìn chung về các yêu cầu của khách hàng.
Lập kế hoạch dự án phần mềm: Điều này có nghĩa là tạo và tuân
theo một kế hoạch hợp lý để thực hiện và quản lý một dự án.
Theo dõi và giám sát dự án phần mềm: Điều này có nghĩa là làm
cho tiến trình của dự án có thể nhìn thấy được để ban quản lý biết
được tình trạng của dự án. Các hành động khắc phục có thể được
thực hiện nếu tiến độ thực tế của một dự án sai lệch đáng kể so với
tiến độ kế hoạch.
Quản lý hợp đồng phụ phần mềm: Điều này có nghĩa là đánh giá,
lựa chọn và quản lý các nhà cung cấp hoặc nhà thầu phụ.
Đảm bảo chất lượng phần mềm: Điều này có nghĩa là đánh giá các
quy trình và sản phẩm để hiểu hiệu quả và chất lượng của chúng.
Quản lý cấu hình phần mềm: Điều này có nghĩa là đảm bảo tính
toàn vẹn của các sản phẩm của một dự án miễn là dự án tiếp tục tồn
tại.
Cấp độ 3: Được xác định Ở cấp độ này, tài liệu đóng một vai trò
quan trọng. Các quy trình liên quan đến quản lý dự án và các hoạt
động phát triển phần mềm được lập thành văn bản, xem xét, tiêu
chuẩn hóa và tích hợp với các quy trình của tổ chức. Nói cách khác,
có sự chấp nhận của toàn tổ chức đối với các quy trình tiêu chuẩn.
Việc phát triển phần mềm được thực hiện theo một quy trình đã được
phê duyệt. Các chức năng và các phẩm chất liên quan được theo dõi.
Chi phí và lịch trình được giám sát để giữ chúng trong tầm kiểm soát.
Các KPA ở cấp độ 3 như sau:
Tập trung vào Quy trình của Tổ chức: Điều này có nghĩa là đặt ra
một vai trò và trách nhiệm trong toàn tổ chức để đảm bảo rằng các
hoạt động liên quan đến cải tiến quy trình trên thực tế được tuân thủ.
Định nghĩa Quy trình Tổ chức: Một số thực hành hữu ích bất kể
các dự án. Vì vậy, điều quan trọng là phải xác định và ghi lại những
thực hành đó.
Chương trình đào tạo: Các cá nhân cần được đào tạo liên tục để
làm cho họ hiểu biết về các lĩnh vực ứng dụng và những phát triển
mới trong kỹ thuật và công cụ phần mềm. Việc đào tạo được kỳ vọng
sẽ làm cho chúng hiệu quả và hiệu quả.
Quản lý phần mềm tích hợp: Điều này có nghĩa là tích hợp các
hoạt động quản lý và kỹ thuật phần mềm của một tổ chức vào một
quy trình chung được xác định. Tích hợp dựa trên nhu cầu thương
mại và công nghệ của các dự án riêng lẻ.
Kỹ thuật sản phẩm phần mềm: Điều này có nghĩa là tuân theo một
quy trình đã xác định một cách nhất quán bằng cách tích hợp các
hoạt động kỹ thuật để tạo ra phần mềm với các thuộc tính mong
muốn. Các hoạt động bao gồm kích thích yêu cầu, thiết kế chức
năng, thiết kế chi tiết, mã hóa và thử nghiệm.
Điều phối giữa các nhóm: Điều này có nghĩa là một nhóm phát triển
phần mềm phối hợp với các nhóm khác, chẳng hạn như khách hàng,
nhóm tiếp thị, và nhóm đảm bảo chất lượng phần mềm (SQA), để
hiểu nhu cầu và mong đợi của họ.
Đánh giá ngang hàng: Các sản phẩm công việc, chẳng hạn như yêu
cầu, thiết kế và mã, được các đồng nghiệp xem xét để tìm ra các
khiếm khuyết ở giai đoạn đầu. Đánh giá ngang hàng có thể được thực
hiện bằng cách kiểm tra và hướng dẫn.
Cấp độ 4: Được quản lý Ở cấp độ này, các chỉ số đóng vai trò quan
trọng. Các chỉ số liên quan đến quá trình và sản phẩm được thu thập
và phân tích. Những chỉ số này được sử dụng để có được cái nhìn sâu
sắc về định lượng về cả quy trình và chất lượng sản phẩm. Khi các
chỉ số cho thấy rằng các giới hạn đang bị vượt quá, các hành động
khắc phục sẽ được kích hoạt. Ví dụ: nếu có quá nhiều trường hợp thử
nghiệm không thành công trong quá trình kiểm tra hệ thống, sẽ rất
hữu ích khi bắt đầu một quy trình phân tích nguyên nhân gốc rễ để
hiểu tại sao rất nhiều thử nghiệm không thành công. KPA ở cấp độ 4
như sau:
Quản lý quy trình định lượng: Dữ liệu quy trình cho biết quy trình
đang hoạt động tốt như thế nào. Nếu một quy trình không hoạt động
như mong đợi, quy trình được cải thiện bằng cách xem xét dữ liệu đo
được.
Quản lý chất lượng phần mềm: Các thuộc tính chất lượng của sản
phẩm được đo lường ở dạng định lượng để có cái nhìn sâu sắc hơn về
các quá trình và sản phẩm. Các cải tiến được đưa vào các quy trình
và hiệu quả của chúng được đánh giá bằng cách đo lường các thuộc
tính chất lượng sản phẩm.
Cấp độ 5: Tối ưu hóa Ở cấp độ này, các tổ chức cố gắng liên tục cải
tiến các quy trình của họ. Điều này đạt được trong hai bước: (i) Quan
sát tác động của các quy trình, bằng cách đo lường một số chỉ số
chính, lên chất lượng, chi phí và thời gian thực hiện của sản phẩm
phần mềm và (ii) các thay đổi về hiệu ứng đối với các quy trình bằng
cách giới thiệu các kỹ thuật, phương pháp mới , công cụ và chiến
lược. Sau đây là các KPA ở cấp độ 5:
Phòng ngừa khuyết tật: Điều này có nghĩa là phân tích nguyên
nhân gốc rễ của các lớp khuyết tật khác nhau và thực hiện các biện
pháp phòng ngừa để đảm bảo rằng các khuyết tật tương tự không tái
diễn.
Quản lý Thay đổi Công nghệ: Điều này có nghĩa là xác định các kỹ
thuật, công cụ và phương pháp luận hữu ích và dần dần đưa chúng
vào các quy trình phần mềm. Ý tưởng chính là tận dụng những phát
triển mới trong công nghệ.
Quản lý Thay đổi Quy trình: Điều này có nghĩa là cải tiến các quy
trình của tổ chức để có tác động tích cực đến chất lượng, năng suất
và thời gian phát triển.
18.2.3 Các đặc điểm chung của các thực hành chính
Các phương pháp thực hành chính trong mọi KPA được sắp xếp
thành năm loại được gọi là các đặc điểm chung như được giải thích ở
phần sau. Các đặc điểm chung là các thuộc tính của các thực hành
chính cho biết việc thực hiện hoặc thể chế hóa KPA có hiệu quả, có
thể lặp lại và lâu dài hay không.
Cam kết Thực hiện: Một tổ chức phải thể hiện trong hành động -
không chỉ bằng lời nói - rằng nó cam kết cải tiến quy trình. Các hành
động của quản lý cấp trên, chẳng hạn như thiết lập các chính sách của
tổ chức và phân bổ nguồn lực cho các hoạt động cải tiến quy trình,
đưa ra bằng chứng rằng một tổ chức cam kết thực hiện một cách tốt
hơn. Ví dụ, ban lãnh đạo có thể xây dựng chính sách để sử dụng các
quy trình đã được thiết lập và lâu dài.
Khả năng thực hiện: Khả năng của một tổ chức để thực hiện một
quá trình một cách có thẩm quyền được xác định bởi cấu trúc của tổ
chức, nguồn lực và con người để thực hiện quá trình. Sự sẵn có của
nhân viên được đào tạo đầy đủ và thái độ thay đổi của họ có tác động
tích cực đến khả năng thực hiện của họ.
Các hoạt động đã thực hiện: Những hoạt động này mô tả những gì
cần phải được thực hiện để thiết lập khả năng của một quá trình.
Chúng bao gồm các vai trò và thủ tục cần thiết để hiện thực hóa
KPA. Các hoạt động điển hình được thực hiện để hiện thực hóa KPA
là lập kế hoạch, thực hiện kế hoạch, theo dõi công việc và thực hiện
các hành động khắc phục để đảm bảo rằng công việc luôn bám sát kế
hoạch.
Đo lường và phân tích: Đo lường là chìa khóa để biết tình trạng
hiện tại và hiệu quả của một quy trình. Đo lường liên quan đến việc
thu thập dữ liệu có thể tiết lộ tiến trình và hiệu quả của các quá trình.
Dữ liệu thu thập được phải được phân tích để có cái nhìn sâu sắc về
các quy trình. Việc đo lường và phân tích phải được thực hiện để có
thể thực hiện các hành động khắc phục.
Xác minh việc thực hiện: Sau khi có các chính sách và quy trình,
cần phải thực hiện các hoạt động bằng cách tuân thủ quy trình tiêu
chuẩn. Có thể kiểm tra sự tuân thủ với quy trình tiêu chuẩn bằng cách
thực hiện đánh giá và xem xét thường xuyên.
18.2.4 Ứng dụng CMM
Để một tổ chức đạt được một mức độ trưởng thành nhất định, tất cả
các mục tiêu của tất cả các KPA ở cấp đó — và tất cả các cấp trước
đó — phải được thoả mãn. Ví dụ: để một tổ chức ở cấp độ 2, tất cả
sáu KPA liên quan đến cấp độ 2 phải được thỏa mãn. Đối với một tổ
chức ở cấp độ 3, tổ chức phải đáp ứng tất cả sáu KPA liên quan đến
cấp độ 2 và tất cả bảy KPA liên quan đến cấp độ 3. SEI cung cấp hai
phương pháp luận để đánh giá năng lực hiện tại của tổ chức: đánh giá
nội bộ và đánh giá bên ngoài. SEI đã phát triển cải tiến quy trình nội
bộ dựa trên đánh giá dựa trên mức độ trưởng thành về năng lực
(CBA-IPI) để hỗ trợ các tổ chức tự đánh giá. CBA-IPI sử dụng CMM
làm mô hình tham chiếu để đánh giá năng lực quy trình của tổ chức
bằng cách xác định những KPA nào đang được đáp ứng và những gì
cần được cải thiện.
SEI đã phát triển khung đánh giá CMM (CAF) để cung cấp cơ chế
đánh giá chính thức các tổ chức. CAF mô tả các yêu cầu và hướng
dẫn được các chuyên gia đánh giá bên ngoài sử dụng trong việc thiết
kế các phương pháp đánh giá tuân thủ CAF.
18.2.5 Tích hợp mô hình trưởng thành năng lực (CMMI)
Sau khi phát triển và ứng dụng thành công CMM trong lĩnh vực phần
mềm, được gọi là CMM phần mềm (CMM-SW), CMM trong các
lĩnh vực khác cũng được phát triển.
CMM cho phần mềm, được gọi là CMM-SW, được phát hành lần
đầu tiên vào năm 1991 với tên gọi CMM-SW phiên bản 1.0, tiếp theo
là CMM-SW phiên bản 1.1 vào năm 1993. Sau khi phát hành lần đầu
tiên, nhiều tổ chức phần mềm đã sử dụng nó để tự đánh giá và đánh
giá bên ngoài. Sự thành công của CMM-SW đã dẫn đến sự phát triển
của CMM trong các lĩnh vực khác. Do đó, khái niệm CMM không
phải là phần mềm cụ thể. Để đánh giá cao khả năng ứng dụng rộng
rãi của CMM, chúng tôi xin nhắc người đọc những điều sau: CMM là
một mô hình tham chiếu về các thực hành thuần thục trong một lĩnh
vực cụ thể được sử dụng để hình thành và cải thiện khả năng của một
nhóm trong việc thực hiện kỷ luật đó. Để kể tên một số, có một số
CMM như sau:
CMM phần mềm
CMM kỹ thuật hệ thống
CMM phát triển sản phẩm tích hợp
Liên minh công nghiệp điện tử 731 CMM
CMM mua lại phần mềm
Người CMM
Nguồn nhà cung cấp CMM
Rõ ràng là từ các ví dụ trên về CMM rằng chúng có thể có các đặc
điểm khác nhau. Các CMM khác nhau theo ba cách, đó là kỷ luật,
cấu trúc và định nghĩa về sự trưởng thành. Đầu tiên, các CMM khác
nhau được áp dụng cho các lĩnh vực khác nhau, chẳng hạn như phát
triển phần mềm, kỹ thuật hệ thống, mua lại phần mềm và con người.
Thứ hai, các cải tiến có thể được thực hiện liên tục hoặc theo từng
giai đoạn riêng biệt. Cuối cùng, định nghĩa về thời gian đáo hạn phụ
thuộc vào đơn vị được xem xét. Rõ ràng là con người và việc mua lại
phần mềm trưởng thành theo những cách khác nhau, và sự trưởng
thành của họ được xác định theo những cách khác nhau.
Khi nhiều hơn một CMM được áp dụng trong một tổ chức, một số
vấn đề đã xuất hiện vì những lý do sau:
Các mô hình khác nhau có cấu trúc khác nhau, cách đo lường mức độ
trưởng thành khác nhau và các điều khoản khác nhau.
Rất khó để tích hợp các CMM khác nhau để đạt được mục tiêu chung
của tổ chức là sản xuất các sản phẩm chất lượng cao, chi phí thấp
theo đúng tiến độ.
Rất khó để sử dụng nhiều mô hình trong việc lựa chọn nhà cung cấp
và thầu phụ.
Do đó, một nhu cầu cấp thiết được đặt ra là phải có một quan điểm
thống nhất về cải tiến quy trình trong toàn tổ chức. Do đó, đã phát
triển ý tưởng về CMMI. CMMI bao gồm thông tin từ các mô hình
sau:
Mô hình trưởng thành khả năng cho phần mềm (CMM-SW)
Mô hình trưởng thành khả năng phát triển sản phẩm tích hợp (IPD-
CMM)
Mô hình trưởng thành về năng lực cho kỹ thuật hệ thống (CMM-SE)
Mô hình trưởng thành về năng lực để tìm nguồn cung ứng của nhà
cung cấp (CMM-SS)
Tính hữu ích của CMMI được công nhận dễ dàng bằng cách xem xét
các sự kiện sau đây. Thứ nhất, các hệ thống phần mềm phức tạp ngày
nay thường được xây dựng bằng cách sử dụng một số hệ thống con
do các bên khác phát triển. Ví dụ, một mô-đun bảo mật có thể được
mua từ một nhà cung cấp khác. Tương tự, một mô-đun truyền thông
có thể được lấy từ một nhà cung cấp chuyên về hệ thống truyền
thông. Cần phải đánh giá sự trưởng thành của các nhà cung cấp. Thứ
hai, các hệ thống lớn thường chứa một số thành phần đa dạng, chẳng
hạn như cơ sở dữ liệu, truyền thông, bảo mật và xử lý thời gian thực.
Sự chung sống và khả năng tương tác của các hệ thống đa dạng, có
thể được phát triển bởi các nhà cung cấp khác nhau, là điều tối quan
trọng đối với sự vận hành thành công của các hệ thống lớn hơn. Do
đó, điều quan trọng là phải đánh giá mức độ trưởng thành của một
quá trình phát triển sản phẩm tích hợp. Thứ ba, nói chung, các hệ
thống phần mềm phức tạp thường cần chạy trên các nền tảng thực thi
chuyên biệt. Ví dụ, phần mềm định tuyến Internet chạy trên phần
cứng chuyên dụng và hệ điều hành chuyên dụng, thay vì nền tảng
phần cứng và hệ điều hành thường được sử dụng. Những loại phần
mềm đó cần được phát triển trong bối cảnh hệ thống phù hợp.
18.3 CẢI TIẾN QUY TRÌNH THỬ NGHIỆM
Quá trình kiểm tra là một cách thức nhất định để thực hiện các hoạt
động liên quan đến phát hiện khuyết tật. Một số hoạt động kiểm thử
mong muốn điển hình trong phát triển phần mềm như sau:
Xác định các mục tiêu thử nghiệm
Chuẩn bị kế hoạch kiểm tra
18.3 CẢI TIẾN QUY TRÌNH THỬ NGHIỆM 761
Xác định các loại thử nghiệm khác nhau

Thuê nhân viên kiểm tra
Thiết kế các trường hợp thử nghiệm
Thiết lập băng ghế kiểm tra
Mua sắm các công cụ kiểm tra
Chỉ định các trường hợp kiểm thử cho các kỹ sư kiểm thử
Ưu tiên các trường hợp thử nghiệm để thực thi
Tổ chức thực hiện các trường hợp kiểm thử thành nhiều chu kỳ kiểm
thử
Chuẩn bị lịch trình để thực hiện các trường hợp thử nghiệm
Thực thi các trường hợp thử nghiệm
Báo cáo lỗi
Theo dõi các khiếm khuyết trong khi giải quyết chúng
Đo lường tiến độ thử nghiệm
Đo lường các thuộc tính chất lượng của phần mềm được kiểm tra
Đánh giá hiệu quả của quá trình thử nghiệm
Xác định các bước để cải thiện hiệu quả của các hoạt động thử
nghiệm
Xác định các bước để giảm chi phí thử nghiệm
Bản chất của các hoạt động trong một quá trình kiểm tra là rất rộng.
Một mặt, hoạt động kiểm tra có thể là một hoạt động đơn giản, dễ
hiểu, chẳng hạn như báo cáo các khuyết tật. Mặt khác, việc ưu tiên
các trường hợp kiểm thử để thực thi là một nhiệm vụ không hề nhỏ.
Một nhiệm vụ phức tạp hơn là tổ chức việc thực thi thử nghiệm thành
một vài chu kỳ thử nghiệm bằng cách xem xét tất cả các trường hợp
thử nghiệm hoặc một tập hợp con của chúng trong mỗi chu kỳ thử
nghiệm. Tương tự, xác định các bước để cải thiện hiệu quả của các
hoạt động kiểm tra là một nhiệm vụ không hề nhỏ.
Bây giờ chúng tôi trình bày một ví dụ đơn giản về quy trình thử
nghiệm cho thử nghiệm cấp hệ thống. Quá trình kiểm tra này được
trình bày theo các bước sau:
Phân loại các tính năng của một hệ thống thành k loại.
Thiết kế N i số trường hợp kiểm thử cho loại đối tượng thứ i với 1 ≤ i
≤ k. Số N i của các trường hợp kiểm thử được ký hiệu là tập T i .
Chạy T 1 ∪ ··· ∪ T k để phát hiện khuyết tật.
Chạy T 1 ∪ ··· ∪ Sau mỗi lần sửa chữa khuyết tật cho đến khi không
tìm thấy khuyết tật nào nữa hoặc đã đến lúc giải phóng hệ thống.
Người ta có thể dễ dàng nhận ra một số thiếu sót trong quá trình kiểm
tra trên như sau:
Các công cụ kiểm tra chưa được sử dụng.
Các trường hợp thử nghiệm chưa được ưu tiên. • Toàn bộ bộ thử
nghiệm đã được thực thi trong mỗi chu kỳ thử nghiệm, thay vì các tập
hợp con đã chọn của nó trong các chu kỳ thử nghiệm sau đó.
Do đó, điều quan trọng là phải cải thiện các quy trình thử nghiệm và
việc tuân theo một mô hình đã xác định sẽ có lợi cho việc cải tiến
chúng. Ý tưởng cải tiến các quy trình kiểm tra bằng cách tuân theo
một mô hình, cụ thể là mô hình TPI, lần đầu tiên được nghiên cứu bởi
Tim Koomen và Martin Pol. Họ đã thảo luận rộng rãi về mô hình TPI
trong một cuốn sách được viết tốt [4]. Quy trình kiểm tra cần được
cải thiện vì ba lý do như được giải thích trong phần sau:
Chất lượng: Quá trình kiểm tra tốt hơn sẽ cung cấp thông tin chi tiết
hơn về các đặc tính chất lượng của hệ thống đang được kiểm tra. Ví
dụ, sau khi chạy tất cả các trường hợp thử nghiệm hai lần, chúng ta
nên có một ý tưởng tốt về mức độ tin cậy của hệ thống. Ở đây, mục
đích không phải là có một sản phẩm chất lượng tốt hơn - mặc dù điều
đó luôn là mong muốn. Thay vào đó, mục đích là có một quy trình
kiểm tra được cải tiến giúp chúng ta có cái nhìn sâu sắc hơn về chất
lượng của hệ thống đang được kiểm tra.
Thời gian thực hiện: Quy trình kiểm tra tốt hơn giúp tiết kiệm thời
gian kiểm tra và do đó mang lại nhiều thời gian hơn cho các lĩnh vực
phát triển hệ thống khác. Ví dụ, người ta có thể sử dụng ý tưởng ưu
tiên thực hiện các trường hợp kiểm thử để các lỗi khó sửa chữa được
phát hiện càng sớm càng tốt. Việc phát hiện sớm các khiếm khuyết
khó sửa chữa giúp nhà phát triển có thêm thời gian để giải quyết
những khiếm khuyết đó, do đó rút ngắn thời gian phát triển.
Chi phí: Quá trình kiểm tra tốt hơn dự kiến sẽ được thực hiện với chi
phí thấp hơn và do đó làm giảm chi phí phát triển hệ thống tổng thể.
Ví dụ, người ta có thể chọn một cách thận trọng một tập hợp con của
các trường hợp thử nghiệm, thay vì toàn bộ bộ thử nghiệm, để kiểm
tra hồi quy hướng tới giai đoạn kết thúc của kiểm thử cấp hệ thống
trong quá trình phát triển. Bằng cách lựa chọn cẩn thận một tập hợp
con của bộ thử nghiệm, chúng tôi có thể giảm chi phí thử nghiệm hệ
thống mà không ảnh hưởng đến hiệu quả của nó. Các trường hợp
kiểm thử có thể có tác động tích cực đến chi phí phát triển bằng cách
ảnh hưởng đến các quá trình thu thập yêu cầu và thiết kế phần mềm.
Ví dụ: trong khi thu thập các yêu cầu phần mềm, chúng tôi có thể hỏi
các câu hỏi sau:
Các yêu cầu có thể kiểm tra trực tiếp không?
Nếu một số yêu cầu không thể kiểm tra trực tiếp, có thể kết hợp một
số yêu cầu khác để các yêu cầu ban đầu có thể dễ dàng kiểm tra được
không?
Do đó, bằng cách xem xét khả năng kiểm tra của các yêu cầu, có thể
giảm chi phí phát triển. Nếu một yêu cầu không thể kiểm tra được, tốt
hơn hết là xác định những yêu cầu đó và thảo luận với khách hàng
sớm trong giai đoạn phát triển. Về cơ bản, những gì đang được thực
hiện là xác nhận các yêu cầu với các trường hợp thử nghiệm trước khi
các yêu cầu đó trở thành một phần của thiết kế — hoặc thậm chí là
hợp đồng giữa tổ chức phát triển và khách hàng.
Rõ ràng là một quy trình kiểm tra tốt hơn cho chúng ta cái nhìn sâu
sắc hơn về các thuộc tính chất lượng của hệ thống và nó góp phần
phát triển các sản phẩm phần mềm với chi phí thấp hơn trong thời
gian ngắn hơn. Một cách tiếp cận trực quan để cải thiện quy trình
kiểm tra như sau:
Bước Xác định khu vực cần cải tiến: Chúng tôi xác định một
1. khu vực thử nghiệm mà chúng tôi muốn thấy những cải tiến
ngay lập tức. Đối với các nguyên tắc, chúng tôi xem xét ba
lĩnh vực chính cần cải tiến, đó là chất lượng, thời gian và chi
phí và tập trung vào một khía cạnh chính xác. Giả sử rằng
chúng ta muốn có ý tưởng tốt về chất lượng hoạt động của
hệ thống càng sớm càng tốt.
Bước Đánh giá Trạng thái Hiện tại của Quy trình Kiểm tra:
2. Điều quan trọng là phải biết vị trí của chúng ta đối với lĩnh
vực đã chọn để cải thiện. Điều này là do nó có khả năng ảnh
hưởng đến việc chúng ta đi đâu tiếp theo và làm thế nào để
đạt được điều đó. Đề cập đến ví dụ về việc có ý tưởng tốt về
hiệu suất của hệ thống càng sớm càng tốt, chúng tôi đánh giá
khi quá trình kiểm tra hiện tại cho chúng tôi biết về hiệu suất
của hệ thống. Việc đánh giá như vậy có thể được thực hiện
bằng cách xác định thời gian các trường hợp kiểm thử liên
quan đến hiệu suất được thực thi. Nếu các trường hợp thử
nghiệm như vậy được thực hiện trong giai đoạn kết thúc của
thử nghiệm hệ thống, thì có khả năng các thử nghiệm đó
được thực hiện sớm hơn.
Bước Xác định Trạng thái và Phương tiện Mong muốn Tiếp
3. theo: Khi chúng tôi biết trạng thái hiện tại của quá trình thử
nghiệm đối với lĩnh vực mong muốn cải tiến, chúng tôi có vị
trí tốt hơn để đánh giá mức độ cải tiến có thể. Người ta phải
xác định cẩn thận số lượng cải tiến sẽ được nhìn thấy. Quá
nhiều cải tiến ở một trạng thái có thể yêu cầu những thay đổi
đáng kể trong quá trình thử nghiệm. Do đó, các cải tiến gia
tăng được ưu tiên hơn. Đôi khi, một cải tiến nhất định có thể
yêu cầu cải tiến trong các lĩnh vực khác, không được chọn.
Loại và mức độ cải tiến muốn có hiệu quả phải được lựa
chọn cẩn thận. Ví dụ, người ta có thể đánh giá hiệu suất của
một hệ thống trong các môi trường thực thi khác nhau,
chẳng hạn như hệ thống được tải nhẹ, hệ thống được tải vừa
phải và hệ thống được tải nhiều. Do đó, nếu chúng ta quan
tâm đến thông tin hiệu suất ban đầu trong môi trường tải
nhẹ, chúng ta có thể ưu tiên thực hiện các bài kiểm tra liên
quan đến hiệu suất trước khi thực hiện các bài kiểm tra tải.
Trong ví dụ trên, ưu tiên thực hiện kiểm tra là một ví dụ về
các phương tiện cần thiết để thực hiện một cải tiến.
Bước Thực hiện các Thay đổi Cần thiết cho Quy trình: Các cải
4. tiến, như đã xác định ở trên, được thực hiện trong quy trình
thử nghiệm theo cách có kế hoạch. Sau đó, hiệu quả của quá
trình thử nghiệm mới được đánh giá để xác minh xem có thu
được kết quả mong muốn hay không.
Mặc dù các bước của mô hình cải tiến quy trình thử nghiệm ở trên có
vẻ đơn giản, nhưng việc thực hiện chúng thì không. Các bước, đặc
biệt là bước thứ hai và thứ ba, quá chung chung và do đó rất khó đạt
được sự thống nhất giữa các kỹ sư thử nghiệm. Do đó, cần có một mô
hình tham chiếu có thể làm cơ sở để cải tiến thử nghiệm. Mô hình
TPI của Koomen và Pol khuyến khích và hỗ trợ cải thiện dần dần
từng bước quá trình kiểm tra. Quá nhiều thay đổi trong một quá trình
thử nghiệm có thể không thành công vì hai lý do. Đầu tiên, quá nhiều
thay đổi có khả năng yêu cầu quá nhiều tài nguyên, có thể không khả
dụng ở một trạng thái. Thứ hai, mọi người thường chống lại quá
nhiều thay đổi được thực hiện cùng một lúc.
Một khái niệm quan trọng được tiết lộ trong mô hình cải tiến quy
trình thử nghiệm trực quan của Phần 18.3 là ý tưởng đánh giá tình
trạng hiện tại của quy trình thử nghiệm. Tình trạng hiện tại của quá
trình kiểm tra được đánh giá từ các quan điểm khác nhau, được gọi là
các lĩnh vực chính — và 20 lĩnh vực chính đã được xác định. Ví dụ,
sử dụng các công cụ kiểm tra là một lĩnh vực quan trọng trong quá
trình kiểm tra. Tương tự, việc sử dụng các số liệu là một lĩnh vực
quan trọng khác. Trạng thái của quy trình kiểm tra đối với lĩnh vực
chính được thể hiện theo một trong bốn cấp độ trưởng thành — A, B,
C và D. Cấp độ thuần thục của quy trình kiểm tra đối với lĩnh vực
chính tăng dần từ A đến D. Sau đây, chúng tôi mô tả ngắn gọn 20 lĩnh
vực chính:
Chiến lược kiểm tra: Một quá trình kiểm tra cần phát hiện sớm các
khiếm khuyết nghiêm trọng trong quá trình kiểm tra. Ví dụ, điều này
có thể đạt được bằng cách ưu tiên thực hiện các trường hợp thử
nghiệm. Chiến lược kiểm tra cần tìm ra khuyết tật với chi phí thấp
hơn. Chiến lược kiểm tra sẽ cho phép chúng tôi lập bản đồ chính xác
các yêu cầu với các trường hợp kiểm thử cho mục đích truy xuất
nguồn gốc.
Mô hình vòng đời: Một quy trình thử nghiệm có thể là một quy trình
phức tạp liên quan đến nhiều hoạt động của người luyện và nhiều
người và kéo dài trong vài tháng. Do đó, đối với mục đích quản lý vi
mô, quy trình kiểm tra có thể được coi là có một vòng đời được xác
định rõ ràng với các giai đoạn riêng biệt, chẳng hạn như lập kế hoạch,
chuẩn bị và thực hiện. Mỗi giai đoạn được đặc trưng bởi một tập hợp
các hoạt động. Ví dụ, lập kế hoạch và ước tính chi phí là các hoạt
động lập kế hoạch. Tương tự như vậy, thiết kế các trường hợp thử
nghiệm và thiết lập các băng ghế thử nghiệm là các hoạt động chuẩn
bị. Mỗi hoạt động cần có cấu trúc rõ ràng dưới dạng mục tiêu, đầu
vào, giả định, quy trình, đầu ra, ràng buộc, phụ thuộc và công cụ hỗ
trợ. Mô hình vòng đời cho phép chúng ta có một quá trình thử
nghiệm có thể lặp lại và do đó có thể dự đoán được. Tính lặp lại là lợi
ích chính của mô hình vòng đời.
Moment of Involvement: Việc thực thi thực tế các trường hợp kiểm
thử không thể bắt đầu cho đến khi mã được viết. Tuy nhiên, quá trình
thử nghiệm có thể bắt đầu bất cứ lúc nào. Ví dụ, lý tưởng nhất là lập
kế hoạch kiểm tra nên bắt đầu đồng thời với việc kích thích các yêu
cầu. Điều này sẽ cho phép chúng tôi xác minh khả năng kiểm tra của
từng yêu cầu. Tương tác sớm hơn và chặt chẽ hơn giữa các nhà phát
triển và nhân viên SQA dẫn đến việc hiểu rõ hơn về nhu cầu thử
nghiệm về nguồn lực và thách thức.
Lập kế hoạch và Ước tính: Lập kế hoạch liên quan đến việc xác định
và lập lịch trình cho các hoạt động sẽ được thực hiện, xác định các
ràng buộc và xác định các nguồn lực. Để chuẩn bị cho các hoạt động
theo kế hoạch, điều quan trọng là có thể ước tính chính xác số lượng
nguồn lực cần thiết. Trong trường hợp không có một kế hoạch và dự
toán tốt, một dự án có thể hết thời gian và vượt quá ngân sách. Do đó,
một dự án thử nghiệm cần phải được lên kế hoạch cẩn thận và ước
tính chính xác chi phí của nó càng sớm càng tốt.
Kỹ thuật đặc tả kiểm thử: Kỹ thuật đặc tả kiểm thử là kỹ thuật cho
phép chúng ta lấy các trường hợp kiểm thử từ một nguồn thông tin,
chẳng hạn như đặc tả yêu cầu của hệ thống, tài liệu thiết kế của hệ
thống và mã nguồn của hệ thống. Vì có nhiều nguồn thông tin của
một hệ thống phần mềm, nên cần phải xác định nhiều kỹ thuật đặc tả
kiểm tra. Việc phân tích kỹ thuật đặc tả kiểm thử sẽ cho chúng ta biết
nó sẽ phát sinh ra những loại trường hợp kiểm thử nào. Nói cách
khác, bằng cách nghiên cứu kỹ thuật đặc tả thử nghiệm, chúng ta sẽ
có cái nhìn sâu sắc hơn về chất lượng và phạm vi của thử nghiệm.
Kỹ thuật kiểm thử tĩnh: Theo nghĩa rộng, có hai loại hoạt động kiểm
thử: tĩnh và động. Kiểm thử động liên quan đến việc thực thi mã thực
tế, trong khi kiểm tra tĩnh liên quan đến nhiều loại đánh giá, chẳng
hạn như xác minh yêu cầu, xem xét thiết kế và xem xét mã. Hai hình
thức kiểm tra đều có những ưu điểm và hạn chế riêng. Tuy nhiên,
điều rõ ràng là cần phải thực hiện cả hai hình thức kiểm tra để kiểm
tra tổng thể có hiệu quả và không tốn kém.
Chỉ số: Ai cũng biết rằng những con số giúp chúng ta có cái nhìn sâu
sắc hơn về mọi thứ — quy trình và sản phẩm. Khái niệm về đo lường,
đại diện
dưới dạng thước đo, cho phép chúng ta định lượng các thuộc tính
định tính của quá trình và sản phẩm. Người ta có thể dễ dàng xác
định một số thuộc tính chất lượng của quá trình thử nghiệm, chẳng
hạn như năng suất trong thiết kế thử nghiệm, tốc độ thực hiện thử
nghiệm, tỷ lệ báo cáo lỗi, tỷ lệ sửa chữa lỗi và số lượng lỗi chưa được
sửa. Các chỉ số thử nghiệm cho phép chúng tôi theo dõi tiến trình thử
nghiệm và giúp chúng tôi xử lý mức chất lượng của hệ thống đang
thử nghiệm. Các số liệu cũng hữu ích trong việc đánh giá tác động
của các thay đổi trong quy trình.
Công cụ kiểm tra: Các công cụ có thể được sử dụng trong một số
hoạt động liên quan đến kiểm thử như sau: tạo trường hợp kiểm thử,
thực hiện kiểm thử tự động và theo dõi lỗi. Các công cụ kiểm tra có
khả năng giảm thời gian thiết kế kiểm thử và thời gian thực hiện kiểm
thử. Các công cụ kiểm tra có thể giúp chạy nhiều thử nghiệm hơn, do
đó đạt được nhiều thử nghiệm hơn. Theo dõi lỗi thông qua một công
cụ giúp chúng tôi làm cho hoạt động ít bị lỗi hơn. Cuối cùng, các
công cụ làm cho các nhiệm vụ kiểm thử bớt đơn điệu hơn đối với các
kỹ sư kiểm thử.
Môi trường thử nghiệm: Tốt nhất, thử nghiệm cấp hệ thống nên được
thực hiện trong môi trường hoạt động của hệ thống. Tuy nhiên, đôi
khi rất tốn kém, hoặc không thực tế, để thiết lập một môi trường hoạt
động trong phòng thí nghiệm thử nghiệm. Do đó, các môi trường thử
nghiệm càng gần với thực tế càng tốt được thực hiện trong phòng thí
nghiệm. Các thành phần của môi trường thử nghiệm bao gồm phần
cứng, phần mềm, thiết bị truyền thông và các công cụ và kỹ thuật để
mô phỏng sự tương tác của hệ thống được thử nghiệm với thế giới
bên ngoài. Ví dụ, tương tác thực tế với thế giới bên ngoài có thể được
mô phỏng bằng cách sử dụng bộ tạo lưu lượng. Các môi trường thử
nghiệm khác nhau là cần thiết để thực hiện các hạng mục thử nghiệm
khác nhau. Ví dụ: chúng ta cần một môi trường để kiểm tra hiệu suất
và một môi trường khác để kiểm tra bảo mật. Môi trường thử nghiệm
phải phản ánh chính xác mục tiêu của thử nghiệm. Nếu không thiết kế
cẩn thận các môi trường thử nghiệm, chúng tôi sẽ không thể đo lường
các thuộc tính chất lượng của hệ thống đang thử nghiệm. Hơn nữa,
nếu môi trường thử nghiệm khác biệt đáng kể với môi trường vận
hành, thì có khả năng là một số lượng lớn các hư hỏng mới được
quan sát thấy trong quá trình vận hành. Do đó, môi trường thử
nghiệm có tác động lớn đến chất lượng, chi phí và tính kịp thời của
thử nghiệm.
Môi trường văn phòng: Một văn phòng được tổ chức tốt và các nguồn
lực sẵn có kịp thời có tác động tích cực đến các kỹ sư kiểm thử. Một
tổ chức văn phòng bao gồm những thứ cơ bản như phòng thoải mái,
bàn, ghế, v.v. Môi trường làm việc thân thiện cùng với chính sách
nhân sự tốt góp phần tạo nên sự hài lòng cho nhân viên. Các kỹ sư
thử nghiệm hài lòng với tâm trạng tốt có khả năng làm việc hiệu quả
hơn.
Cam kết và Động lực: Trong một dự án thử nghiệm, một số loại
người có liên quan, cụ thể là các nhà quản lý, kỹ sư thử nghiệm và kỹ
thuật viên. Các nhà quản lý cần hiểu tầm quan trọng của nhiệm vụ
đang giao và thúc đẩy những người khác bằng cách cung cấp cho họ
đào tạo và nguồn lực. Kỹ sư kiểm thử là những người thiết kế và thực
hiện các trường hợp kiểm thử. Kỹ thuật viên cung cấp dịch vụ hỗ trợ.
Ngay cả khi kiểm thử phần mềm không phải là công việc ưa thích của
họ, họ cần phải hoàn toàn cam kết với công việc của mình. Nếu các
kỹ sư kiểm tra ở lại vị trí của họ
ở công ty trong một thời gian rất ngắn, người ta có thể lập luận rằng
họ đã không hoàn toàn cam kết thử nghiệm.
Chức năng kiểm tra và đào tạo: Một nhóm kiểm tra cần bao gồm
những người có chuyên môn và đào tạo khác nhau. Một số người có
chuyên môn về quản lý, một số là chuyên gia trong lĩnh vực chủ đề
của hệ thống đang được thử nghiệm, và một số là chuyên gia trong
lĩnh vực thử nghiệm. Các kỹ sư kiểm tra cũng cần phải có chuyên
môn khác nhau. Ví dụ: một số kỹ sư kiểm thử là chuyên gia kiểm tra
hiệu suất, một số là chuyên gia kiểm tra bảo mật, một số là chuyên
gia kiểm tra tải, v.v. Nếu không có sự kết hợp phù hợp của những
người trong một nhóm thử nghiệm, một số người trong số họ có thể
được đào tạo về một số lĩnh vực. Kỹ năng giao tiếp giữa các cá nhân
tốt cũng được yêu cầu đối với một người để trở thành một kỹ sư thử
nghiệm thành công.
Phạm vi phương pháp luận: Cốt lõi của quy trình kiểm tra là khái
niệm về phương pháp luận bao gồm các hoạt động, thủ tục, kỹ thuật,
quy định, v.v. Lý tưởng nhất là một tổ chức sử dụng một phương
pháp nhưng điều chỉnh nó cho các dự án khác nhau tùy thuộc vào nhu
cầu đặc biệt của dự án. Ví dụ: một dự án có thể chứa một thành phần
lớn của xử lý thời gian thực, trong khi một dự án khác chứa một
thành phần lớn của giao diện người dùng đồ họa. Sự khác biệt về các
đặc điểm của dự án có thể đòi hỏi một tổ chức phải chú trọng đến các
kỹ thuật tạo và thực thi thử nghiệm. Nhưng, về cơ bản, hai dự án có
thể là sự thích nghi của một phương pháp luận chung. Phương pháp
luận chung phải đủ linh hoạt để dễ dàng thích nghi. Mặt khác, rất
không mong muốn đưa ra một phương pháp luận mới cho mỗi dự án
thử nghiệm mới.
Giao tiếp: Một nhóm thử nghiệm giao tiếp trong chính họ và với các
nhóm bên ngoài, cụ thể là các nhà phát triển, nhóm tiếp thị và khách
hàng. Giao tiếp nội bộ tốt là điều cần thiết để làm việc như một nhóm
gắn kết với cơ hội giữ cho bản thân luôn theo sát các diễn biến trong
nhóm. Giao tiếp với khách hàng cho phép nhóm thử nghiệm tìm hiểu
về những mong đợi của khách hàng. Giao tiếp với các nhà phát triển
là điều cần thiết để hiểu các chi tiết thiết kế của hệ thống. Nhóm tiếp
thị, bằng cách giao tiếp với nhóm thử nghiệm, theo dõi tiến trình thử
nghiệm hệ thống và mức chất lượng hiện tại của hệ thống đang thử
nghiệm.
Báo cáo: Có nhiều loại hoạt động báo cáo khác nhau, chẳng hạn như
báo cáo nội bộ và báo cáo bên ngoài, liên quan đến quá trình kiểm
tra. Báo cáo khuyết tật là một hoạt động nội bộ. Chất lượng của hệ
thống đang thử nghiệm phải được báo cáo cho khách hàng. Báo cáo
cho khách hàng thuộc báo cáo bên ngoài. Bằng cách đưa ra những
báo cáo hữu ích cho khách hàng, bạn có thể xây dựng mối quan hệ tốt
đẹp với họ.
Quản lý lỗi: Các kỹ sư kiểm tra báo cáo các lỗi cần được khắc phục
bởi các nhà phát triển. Tuy nhiên, trạng thái của một khiếm khuyết
phức tạp hơn một tình huống cố định hoặc không cố định. Ví dụ, một
khiếm khuyết được báo cáo phải được phân tích để hiểu liệu đó có
thực sự là một khiếm khuyết hoặc do các kỹ sư kiểm tra hiểu nhầm
hay không. Một khiếm khuyết thực sự cần được sửa chữa bởi một
hoặc nhiều nhà phát triển. Do đó, một khiếm khuyết có thể ở trạng
thái mở trong nhiều tuần. Một lần
một lỗi được tuyên bố là đã được sửa, các kỹ sư kiểm tra phải xác
minh rằng lỗi đã thực sự được sửa. Do đó, sẽ rất hữu ích nếu tuân
theo một mô hình vòng đời để quản lý các khuyết tật. Bằng cách quản
lý các khuyết tật bằng cách sử dụng mô hình vòng đời, chúng ta có
thể dễ dàng xác định trạng thái và tiến độ kiểm tra cũng như mức chất
lượng của hệ thống được kiểm tra.
Quản lý phần mềm kiểm thử: Các sản phẩm được phát triển trong quá
trình phát triển phần mềm được sử dụng trong khi kiểm tra hệ thống.
Các sản phẩm như vậy là đặc điểm kỹ thuật yêu cầu, đặc điểm kỹ
thuật thiết kế chức năng, mã nguồn, kế hoạch thử nghiệm và bộ thử
nghiệm. Vì các bản sửa đổi được thực hiện cho các thực thể đó trên
cơ sở cần thiết, có thể có một số phiên bản của sản phẩm tồn tại tại
thời điểm kiểm tra hệ thống. Do đó, nên sử dụng phiên bản phù hợp
của từng sản phẩm để thử nghiệm hiệu quả và hiệu quả. Điều này có
thể đạt được thông qua việc sử dụng thích hợp các công cụ quản lý
phần mềm thử nghiệm.
Quản lý quy trình thử nghiệm: Các quy trình thử nghiệm rất dễ nhìn
thấy vì mọi người, bao gồm cả nhà phát triển, giám đốc tiếp thị và
khách hàng, đều quan tâm đến việc biết tiến trình thử nghiệm và mức
chất lượng hiện tại của hệ thống và xu hướng của hệ thống. Kiểm tra
hệ thống xảy ra gần với ngày giao hàng dự kiến của sản phẩm nên nó
thu hút thêm sự chú ý của tất cả mọi người. Do đó, để có thể bám sát
lịch trình và duy trì trong phạm vi ngân sách, cần tuân thủ các thông
lệ đã được chứng minh trong quản lý. Ví dụ về quản lý quy trình thử
nghiệm theo cách thức xác định như sau: (i) Chuẩn bị kế hoạch cho
quy trình, (ii) xác minh kế hoạch, (iii) thực hiện kế hoạch, (iv) theo
dõi tiến trình, và (v) thực hiện các biện pháp khắc phục và phòng
ngừa.
Đánh giá: Kiểm tra chỉ là một khía cạnh của đảm bảo chất lượng.
Chất lượng của toàn bộ hệ thống có thể được cải thiện bằng cách
đánh giá chất lượng của tất cả các sản phẩm, ngoại trừ mã nguồn,
được xây dựng trong quá trình phát triển. Ví dụ, sẽ hữu ích khi đánh
giá các yêu cầu và tài liệu thiết kế, hướng dẫn sử dụng và các công cụ
khác nhau được sử dụng trong phát triển hệ thống, bao gồm cả các
công cụ kiểm tra. Khái niệm đánh giá liên quan đến kiểm tra có thể
được áp dụng trong suốt quá trình phát triển. Bằng cách đánh giá các
sản phẩm khác trước khi thực hiện kiểm thử dựa trên thực thi, một tổ
chức có thể giảm chi phí phát triển phần mềm. Điều này là do việc
đánh giá các sản phẩm trung gian cho phép phát hiện sớm các khuyết
tật.
Kiểm tra mức độ thấp: Các quá trình kiểm tra trong một tổ chức
không thể chỉ tập trung vào kiểm tra mức hệ thống. Trước khi toàn bộ
hệ thống chịu sự khắc nghiệt của kiểm thử cấp hệ thống, nhiều thử
nghiệm, ở dạng cấp đơn vị và cấp tích hợp, cần được thực hiện bởi
các lập trình viên riêng lẻ và kỹ sư kiểm tra tích hợp, tương ứng. Nếu
không có niềm tin mạnh mẽ vào kiểm thử đơn vị và kiểm thử tích
hợp, thì hệ quả đơn thuần là kiểm thử cấp hệ thống sẽ tan rã; nghĩa là,
không có thử nghiệm hệ thống có ý nghĩa nào có thể được thực hiện
nếu những thứ cơ bản không hoạt động. Hiệu quả của kiểm thử cấp
thấp, cụ thể là kiểm thử đơn vị và tích hợp, có được từ thực tế là các
lỗi được phát hiện và khắc phục sớm trong giai đoạn phát triển.
Mức độ trưởng thành của các lĩnh vực chính Một quá trình kiểm
tra được đánh giá liên quan đến 20 lĩnh vực chính được giải thích ở
trên. Cụ thể, người ta quan tâm đến việc biết một khu vực trọng điểm
nhất định đã trưởng thành ở mức độ nào. Tất cả các lĩnh vực chính có
thể không phát triển ở mức độ như nhau vì thực tế là một tổ chức có
thể không chú trọng đến tất cả. Mức độ trưởng thành của các khu vực
chính được ký hiệu là A, B, C và D, trong đó A thể hiện mức độ
trưởng thành thấp nhất và D là mức cao nhất. Thời gian đáo hạn của
một khu vực quan trọng tăng lên khi chúng ta chuyển từ A sang B, B
sang C, v.v. Mỗi cấp độ tốt hơn so với người tiền nhiệm của nó theo
một hoặc nhiều cách từ nhóm ba thông số mong muốn: chất lượng,
thời gian và tiền bạc. Ý định của chúng tôi là tìm kiếm những cải tiến
về chất lượng, thời gian và tiền bạc (chi phí) nhất quán với những
thảo luận trước đó về sự cần thiết phải cải tiến quy trình kiểm tra
trong Phần 18.3.
Đối với một khu vực trọng điểm để đạt đến một mức độ nhất định,
khu vực trọng điểm phải đáp ứng các yêu cầu, được gọi là các điểm
kiểm tra, gắn với cấp độ đó và tất cả các cấp độ bên dưới nó đối với
lĩnh vực trọng điểm đó. Ví dụ: một quy trình thử nghiệm được chốt ở
mức C phải đáp ứng tất cả các yêu cầu cho các mức A, B và C. Nếu
một quy trình thử nghiệm không đáp ứng các yêu cầu của mức A, quy
trình vẫn ở mức ban đầu dưới A. Các yêu cầu đối với mỗi lĩnh vực
chính để đạt đến một mức độ trưởng thành nhất định được đưa ra
trong Bảng 18.1. Bằng cách phân tích Bảng 18.1, chúng tôi đưa ra
các nhận xét sau:
Tất cả các lĩnh vực chính không có bốn mức độ trưởng thành. Ví dụ,
kỹ thuật đặc tả kiểm tra vùng trọng điểm có hai cấp độ trưởng thành,
đó là A và B, và B là cấp độ thuần thục cao nhất cho vùng trọng điểm
này. Đối với các kỹ thuật đặc tả kiểm tra khu vực chính, hai yêu cầu
khác biệt có tầm quan trọng là kỹ thuật không chính thức và kỹ thuật
chính thức, theo thứ tự đó. Nếu các trường hợp thử nghiệm không
bao giờ được đưa vào văn bản, thì mức độ trưởng thành của các kỹ
thuật đặc tả thử nghiệm vẫn ở mức ban đầu, thấp hơn A. nhóm các
yêu cầu đó theo thứ tự sức mạnh tăng dần để sự tiến bộ từ nhóm này
đến nhóm tiếp theo dẫn đến sự cải thiện rõ rệt và quy trình kiểm tra
tốt hơn. Nếu không có nhiều yêu cầu đối với một lĩnh vực trọng điểm
để đáp ứng, thì không cần phải có bốn cấp độ trưởng thành. • Mức độ
trưởng thành cao nhất của một khu vực chính không cần phải là D.
Trong các kỹ thuật đặc tả kiểm tra khu vực trọng điểm, mức độ
trưởng thành cao nhất là B.
Tồn tại sự phụ thuộc giữa các mức độ trưởng thành của các khu vực
chính. Trong bối cảnh nhất định, phụ thuộc có nghĩa là để một lĩnh
vực then chốt đạt được mức độ trưởng thành nhất định, thì một số
lĩnh vực then chốt khác phải đạt đến độ chín nhất định. Bây giờ
chúng ta hãy xem xét một ví dụ như sau. Để đánh giá khu vực chính
ở mức A, điều quan trọng là các kỹ thuật đặc tả kiểm tra, giao tiếp và
quản lý lỗi phải ở mức B. Do đó, mức độ trưởng thành của tất cả các
khu vực chính không cải thiện trong các bước khóa. Ý tưởng về sự
phụ thuộc vào kỳ hạn yêu cầu cải thiện mức độ trưởng thành của các
lĩnh vực quan trọng theo cách thức ưu tiên. Ví dụ: trước tiên, chúng
tôi nâng cấp độ thuần thục của quản lý khiếm khuyết lên B trước khi
chúng tôi bắt đầu một quy trình để nâng cấp độ thuần thục của đánh
giá khu vực chính lên cấp A.
Dựa trên các ý tưởng về sự phụ thuộc và mức độ ưu tiên, một ma trận
kiểm tra độ chín, như thể hiện trong Bảng 18.2, được xây dựng. Ma
trận độ chín thử nghiệm
TABLE18.1RequirementsforDifferentMaturityLevels
Keyarea LevelA LevelB LevelC LevelD
Teststrategy Strategyforsingle Combinedstrategyfor Combinedstrategyfor Combinedstrategyforall

high-leveltest high-leveltests high-leveltestsplus testandevaluationlevels
low-leveltestsor
evaluation
Life-cyclemodel Planning,specification, Planningpreparation,
execution specification,execution,
andcompletion
MomentofinvolvementCompletionoftestbasisStartoftestbasis Startofrequirements Projectinitiation
definition
EstimatingandplanningSubstantiatedestimating Statisticallysubstantiated
andplanning estimatingandplanning
TestspecificationtechniqueInformaltechniques Formaltechniques
StatictesttechniquesInspectionoftestbasisChecklists
Metrics Projectmetrics(product)Projectmetrics(process)Systemmetrics Organizationmetrics(more
thanonesystem)
Testtools PlanningandcontroltoolsExecutionandanalysis Extensiveautomationof
tools thetestprocess
Testenvironment Managedandcontrolled Testinginmostsuitable Environmentoncall
testenvironment environment
Officeenvironment Adequateandtimelyoffice
environment
Commitmentand Assignmentofbudgetand Testingintegratedin Testengineering
motivation time projectorganization
TestfunctionsandtrainingTestmanagerandtesters(Formal)methodical, Formalinternalquality
technical,andfunctional assurance
support,management
564
TABLE18.1( Continued )
776
Keyarea LevelA LevelB LevelC LevelD

)
ScopeofmethodologyProjectspecific OrganizationgenericOrganizationoptimizing,
R&Dactivities
Communication InternalcommunicationProjectcommunication Communicationwithin
defects,changecontrol organizationaboutthe
qualityofthetest
process
Reporting Defects Progress(statusoftests Risksand Recommendationshavea
( andproducts),activities recommendations, softwareprocess
costsandtime, substantiatedwith improvementcharacter
milestones),defectswith metrics
priorities
CHƯƠNG 18 CÁC MÔ HÌNH NĂNG LỰC
(
Defectmanagement InternaldefectmanagementExtensivedefect Projectdefectmanagement
managementwith
flexiblereporting
facilities
TestwaremanagementInternaltestware Externalmanagementof Reusabletestware Traceabilitysystem
management testbasisandtestobject requirementstotest
cases
TestprocessmanagementPlanningandexecutionPlanning,execution, Monitoringandadjusting
monitoring,and withinorganization
adjusting
Evaluation EvaluationtechniquesEvaluationstrategy
Low-leveltesting Low-leveltestlifecycle White-boxtechniquesLow-levelteststrategy
planning,specification,
4. andexecution)
PearsonEducation.
SourceFromref ©
(
:
1999
565
BẢNG 18.2 Ma trận độ chín kiểm tra
Tỉ lệ
Kiểm soát hiệu quả

Khu vực
số
trọng điểm 1 2 3 4 5 6 7 9 10 11 12 13
8
0
Chiến lược Một - - - - B - - - C - D
thử nghiệm
Mô hình Một - - B
vòng đời
Khoảnh Một - - - B - - - C - D
khắc tham
gia
Ước tính và Một - - - - - - B
lập kế
hoạch
Kiểm tra Một - B
các kỹ thuật
đặc tả
Kỹ thuật Một - B
kiểm tra
tĩnh
Số liệu Một - - B - - C - D
Các công Một - - B - - C
cụ kiểm tra
Môi trường Một - - - B - - - - - C
thử nghiệm
Môi trường Một
văn phòng
Cam kết và Một - - - B - - - - - C
động lực
Kiểm tra Một - - B - - - C

chức năng
và đào tạo
Phạm vi Một - - - - - B - - C
phương
pháp luận
Liên lạc Một - B - - - - - - C
Báo cáo Một - - B - C - - - - D
Quản lý Một - - - B - C
khiếm
khuyết
Quản lý Một - - B - - - C - - - D
phần mềm
thử nghiệm
Quản lý Một - B - - - - - - - C
quá trình
kiểm tra
Sự đánh giá Một - - B
Kiểm tra Một - B - C
mức độ
thấp
Nguồn: Từ ref. 4. © 1999 Pearson Education.
cho thấy rằng mức độ trưởng thành tổng thể của một quá trình thử
nghiệm có thể được biểu diễn trên thang điểm từ 1–13. Sau đây,
chúng tôi phân loại 13 thang đo mức độ trưởng thành của một quá
trình thử nghiệm thành ba phân đoạn định tính riêng biệt.
Mức độ trưởng thành của các quá trình kiểm tra 13 thang
điểm của mức độ trưởng thành được thể hiện trong
Bảng 18.2 được chia thành ba nhóm định tính, cụ thể là, được kiểm
soát, hiệu quả và tối ưu hóa, như được thảo luận dưới đây:
kiểm soát: Nhóm thang đo 1–5 được dán nhãn là có kiểm soát. Quá
trình kiểm tra được thực hiện theo cách có kiểm soát có nghĩa là tất
cả các hoạt động thành phần đều được lên kế hoạch và các hoạt động
đó được thực hiện theo từng giai đoạn theo một chiến lược đã hoạch
định. Trong nhóm này, một số khu vực chính đã đạt được mức trưởng
thành B, trong khi phần còn lại đã đạt mức trưởng thành A.
Hiệu quả: Sau khi đã thiết lập các cơ chế để thực hiện các hoạt động
thành phần của quá trình thử nghiệm một cách có kiểm soát (thang
điểm 1–5), cần phải nỗ lực nhiều hơn để đạt được hiệu quả trong quá
trình thử nghiệm. Mức độ trưởng thành của các khu vực quan trọng
rơi vào thang điểm 6–10 nhấn mạnh tính hiệu quả. Trong nhóm này
của
780
18.3 CẢI TIẾN QUY TRÌNH THỬ NGHIỆM
thang đo, tất cả các lĩnh vực quan trọng, ngoại trừ đánh giá, được
nâng lên ít nhất là cấp độ B với một số là cấp độ C. Ví dụ, thời điểm
tham gia của lĩnh vực quan trọng được cải thiện lên cấp độ B và C
trong nhóm hiệu quả. Mức độ trưởng thành C của thời điểm tham gia
có nghĩa là liên quan đến một quá trình thử nghiệm ở giai đoạn xác
định yêu cầu. Việc suy nghĩ sớm như vậy về việc kiểm tra các yêu
cầu cho phép nhóm SQA thiết kế các trường hợp kiểm thử đòi hỏi ít
chi phí làm lại hơn. Bằng cách để các kỹ thuật kiểm tra tĩnh khu vực
quan trọng trưởng thành đến cấp độ B, chi phí kiểm tra có thể được
giảm bớt bằng cách sử dụng các đánh giá yêu cầu, đánh giá thiết kế
và đánh giá mã.
Tối ưu hóa: Ba cấp độ quy trình kiểm tra 11–13 nằm trong nhóm tối
ưu hóa. Trong nhóm này, tất cả các lĩnh vực then chốt đã đạt đến mức
trưởng thành cao nhất tương ứng. Tối ưu hóa quy trình kiểm tra có
nghĩa là thực hiện các nhiệm vụ kiểm tra theo cách tốt nhất có thể từ
quan điểm chất lượng, thời gian và chi phí. Khi thời gian trôi qua, các
kỹ thuật và công cụ mới có thể có sẵn để giải quyết các vấn đề kiểm
tra. Do đó, một quy trình kiểm tra phải phát triển liên tục để có thể
tận dụng các công nghệ và công cụ mới. Các tổ chức có thể áp dụng
các bài học kinh nghiệm từ các dự án trước đây của họ để làm những
việc nhằm đạt được kết quả tốt hơn về chất lượng, đồng thời tốn ít
tiền hơn và ít thời gian hơn cho việc kiểm tra.
Áp dụng mô hình TPI Sau đây, chúng tôi giải thích cách áp dụng
mô hình TPI để cải thiện quy trình kiểm tra.
Phân tích quy trình kiểm tra hiện tại, sử dụng Bảng 18.1, về 20 lĩnh
vực chính và đánh giá từng lĩnh vực chính — A, B, C hoặc D — nếu
có, tùy thuộc vào mức độ trưởng thành của các lĩnh vực chính.
Đánh giá thang đo hiện tại, từ 1 đến 13, của quá trình thử nghiệm
bằng cách so sánh trạng thái hiện tại của quá trình thử nghiệm với ma
trận độ chín của phép thử tiêu chuẩn trong Bảng 18.2.
Xác định mục tiêu của tổ chức theo quy mô tiếp theo, từ 1 đến 13, mà
tổ chức cần đạt được. Rõ ràng là từ ma trận độ chín thử nghiệm trong
Bảng 18.2 rằng, để chuyển từ thang đo này sang thang đo tiếp theo,
người ta không cần phải tìm kiếm những cải tiến trong tất cả các lĩnh
vực chính. Ví dụ: nếu chúng ta muốn chuyển từ thang điểm 5 lên 6,
chúng ta cần cải tiến chiến lược kiểm tra các lĩnh vực chính (A đến
18.4 KIỂM TRA MỨC ĐỘ MÔ HÌNH 781
B), thời điểm tham gia (A đến B), kỹ thuật kiểm tra tĩnh (A đến B),
chức năng kiểm tra và đào tạo (A đến B), báo cáo (B đến C), đánh giá
(“ban đầu” cho A) và kiểm tra mức độ thấp (A đến B). Các lĩnh vực
chính khác vẫn ở mức độ trưởng thành hiện tại — những lĩnh vực
chính này không cần phải cải thiện lên mức độ trưởng thành cao hơn
vì tác động của chúng có thể không hữu ích ở quy mô quy trình thử
nghiệm 6. Ví dụ: không cần thu thập quá nhiều thông tin chi tiết liên
quan đến các chỉ số thử nghiệm nếu quá trình kiểm tra sẽ không sử
dụng chúng cho mục đích tối ưu hóa, ở quy mô 6.
Cuối cùng, cần thực hiện các hành động để cải thiện các lĩnh vực
chính đã xác định ở bước trước. Một lần nữa, Bảng 18.1 được sử
dụng để xác định các mục hành động.
18.4 MÔ HÌNH ĐỐI THỦ KIỂM TRA
Tương tự như khái niệm đánh giá và cải tiến các quy trình phát triển
phần mềm, cần có một khuôn khổ để đánh giá và cải tiến các quy
trình kiểm thử. Cải tiến liên tục các quy trình kiểm tra là mục tiêu lý
tưởng của các tổ chức, và đánh giá đóng một vai trò quan trọng trong
việc cải tiến quy trình. Điều này là do một tổ chức phải biết mức độ
trưởng thành hiện tại của mình trước khi thực hiện các hành động để
chuyển sang cấp độ tiếp theo. Ilene Burnstein và các đồng nghiệp của
cô tại Viện Công nghệ Illinois đã đi tiên phong trong khái niệm TMM
để giúp các tổ chức đánh giá và cải thiện quy trình thử nghiệm của họ
[5, 6].
TMM mô tả một lộ trình phát triển của quá trình kiểm tra trưởng
thành trong năm cấp độ hoặc giai đoạn, như được minh họa trong
Hình 18.3. TMM đưa ra hướng dẫn về cách cải thiện quy trình kiểm
tra. Mỗi giai đoạn được đặc trưng bởi các khái niệm về
Level 5:Optimization/defect prevention

and quality control
Test process optimization

Quality control
Application of process data for defect prevention
Level 4: Management and measurement
Software quality evaluation

Establish a test measurement program
Establish an organizationwide review program
Level 3: Integration
Control and monitor the testing process

Integrate testing into the software life cycle
Establish a technical training program
Establish a software test organization
Level 2: Phase definition
Institutionalize basic testing techniques and methods

Initiate a test planning process
Develop testing and debugging goals
Level 1: Initial
Hình 18.3 Cấu trúc năm cấp của TMM. (Từ tài liệu tham khảo 5.
© 2003 Springer.)
mục tiêu trưởng thành, hỗ trợ các mục tiêu trưởng thành và các hoạt
động, nhiệm vụ và trách nhiệm (ATR), như được giải thích trong
phần sau:
Mục tiêu trưởng thành: Mỗi cấp độ trưởng thành, ngoại trừ cấp độ
1, chứa các mục tiêu trưởng thành nhất định. Để tổ chức đạt được
một mức độ trưởng thành nhất định, tổ chức phải đáp ứng các mục
tiêu trưởng thành tương ứng. Các mục tiêu về thời gian trưởng thành
được xác định trong điều kiện của các mục tiêu cải tiến thử nghiệm.
: Các mục tiêu về kỳ hạn được hỗ trợ bởi các mục tiêu phụ về kỳ hạn.
Để đạt được mục tiêu trưởng thành, có thể cần phải đáp ứng một số
mục tiêu phụ chi tiết.
Hoạt động, Nhiệm vụ và Trách nhiệm: Các mục tiêu phụ trưởng
thành đạt được nhờ các ATR nhằm giải quyết các vấn đề liên quan
đến việc thực hiện các hoạt động và nhiệm vụ. ATR cũng đề cập đến
cách một tổ chức có thể điều chỉnh các hoạt động của mình để tổ
chức có thể di chuyển phù hợp với mô hình TMM, tức là chuyển từ
cấp độ này sang cấp độ tiếp theo. ATR được cải tiến thêm thành
"quan điểm", được gọi là quan điểm phê bình, từ quan điểm của ba
nhóm người khác nhau:
người quản lý, nhà phát triển và kỹ sư thử nghiệm, và khách hàng
(người dùng / khách hàng).
Các mục tiêu trưởng thành liên quan đến năm cấp độ của mô hình
TMM sẽ được giải thích ở phần sau.
Cấp độ 1. Ban đầu Không có mục tiêu trưởng thành nào được chỉ
định ở cấp độ này. Mức độ TMM 1 được gọi là mức ban đầu. Để một
tổ chức ở cấp độ 1, không cần phải làm gì đặc biệt. Mức 1 đại diện
cho một tình huống trong đó việc kiểm tra không được thực hiện theo
cách có kế hoạch. Kiểm tra bắt đầu sau khi mã được viết. Ở cấp độ
này, một tổ chức thường thực hiện thử nghiệm để chứng minh rằng
hệ thống hoạt động. Không có nỗ lực nghiêm túc nào được thực hiện
để theo dõi tiến độ thử nghiệm và mức chất lượng của sản phẩm. Các
trường hợp kiểm thử được thiết kế và thực thi theo cách đột xuất. Tài
nguyên kiểm tra, chẳng hạn như người kiểm tra được đào tạo, công
cụ kiểm tra và môi trường kiểm tra, không có sẵn. Tóm lại, kiểm thử
không được coi là một giai đoạn quan trọng, riêng biệt trong phát
triển phần mềm.
Cấp độ 2. Định nghĩa giai đoạn Ở cấp độ 2, các mục tiêu trưởng
thành như sau:
Phát triển các mục tiêu thử nghiệm và gỡ lỗi.
Bắt đầu quá trình lập kế hoạch kiểm tra.
Thể chế hóa các kỹ thuật và phương pháp thử nghiệm cơ bản.
(i) Phát triển các Mục tiêu Kiểm tra và Gỡ lỗi Việc tách kiểm thử
khỏi gỡ lỗi là một bước phát triển quan trọng trong quá trình kiểm
thử. Kiểm thử đơn vị và gỡ lỗi có thể có một số tính năng phổ biến
như những tính năng được thực hiện bởi các lập trình viên riêng lẻ.
Tuy nhiên, sự tách biệt của chúng trở nên rõ ràng hơn khi chúng ta
xem xét các cấp độ thử nghiệm cao hơn, ví dụ: thử nghiệm tích hợp,
thử nghiệm cấp hệ thống và thử nghiệm chấp nhận. Ví dụ: khi chúng
tôi chuyển từ kiểm tra cấp đơn vị sang kiểm tra cấp hệ thống, các kỹ
sư kiểm tra quan tâm hơn đến việc kiểm tra các tính năng cấp cao hơn
của hệ thống và họ không tập trung vào chi tiết cấp mã. Mặt khác, gỡ
lỗi chủ yếu là một hoạt động cấp mã
được bắt đầu sau khi một lỗi được phát hiện trong phần mềm. Bản
chất của việc gỡ lỗi quy định rằng nó không thể được thực hiện một
cách có kế hoạch, ngoại trừ việc chuẩn bị sẵn sàng để sử dụng các
công cụ trong việc gỡ lỗi.
Kiểm tra bao gồm các hoạt động có thể được lập kế hoạch và thực
hiện cẩn thận. Các trách nhiệm kiểm tra và gỡ lỗi phải được phân
công hợp lý. Việc gán trách nhiệm gỡ lỗi dễ dàng hơn — nhà phát
triển viết mã cho một đơn vị hoặc duy trì nó, theo mặc định, chịu
trách nhiệm gỡ lỗi cho đơn vị đó. Tương tự, việc phân công trách
nhiệm cho kiểm thử đơn vị cũng dễ dàng — lập trình viên của đơn vị
thực hiện kiểm thử đơn vị. Việc chỉ định trách nhiệm kiểm thử tích
hợp, kiểm thử hệ thống và kiểm thử chấp nhận là một nhiệm vụ
không hề nhỏ vì yêu cầu nhân viên kiểm thử phải có chuyên môn
khác nhau. Ví dụ, một số nhân viên kiểm tra cần phải là chuyên gia
kiểm tra hiệu suất.
Một số mục tiêu phụ về trưởng thành cụ thể có thể hỗ trợ mục tiêu
này như sau: • Các tổ chức thành lập các ủy ban về kiểm tra và gỡ lỗi,
và các ủy ban đó được hỗ trợ kinh phí cần thiết.
Các ủy ban phát triển và lập thành văn bản các mục tiêu kiểm tra.
Một ví dụ về mục tiêu thử nghiệm là theo dõi một khiếm khuyết từ
trạng thái phát hiện ban đầu đến trạng thái cuối cùng được sửa và xác
minh.
Các ủy ban phát triển và ghi lại các mục tiêu gỡ lỗi.
Các mục tiêu kiểm tra và gỡ lỗi được lập thành văn bản được sử dụng
rộng rãi trong tổ chức từ người quản lý đến nhà phát triển và kỹ sư
kiểm tra. Tất cả những người trong tổ chức đều nhận thức được các
mục tiêu kiểm tra và gỡ lỗi và cố gắng đạt được những mục tiêu đó.
(ii) Lập kế hoạch InitiateaTestPlanningProcess là một dấu hiệu cho
thấy mức độ trưởng thành nhất định của bất kỳ quy trình nào. Mức độ
đáo hạn chính xác phụ thuộc vào phạm vi và việc thực hiện kế hoạch.
Lập kế hoạch kiểm tra giải quyết những vấn đề sau:
Xác định mục tiêu kiểm tra: Xác định mục tiêu của quy trình kiểm
tra là trọng tâm cho sự thành công của nó. Nếu không có các mục tiêu
rõ ràng, sẽ rất khó để theo dõi và hướng dẫn tiến trình thử nghiệm.
Hơn nữa, nếu không có các mục tiêu rõ ràng, sẽ rất khó để đo lường
mức độ thành công đạt được trong thử nghiệm. Hai loại mục tiêu có
thể được xác định: liên quan đến chất lượng phần mềm và liên quan
đến quy trình. Một ví dụ về loại mục tiêu trước đây là: Các đơn vị
chương trình phải vượt qua tất cả các bài kiểm tra cấp đơn vị trước
khi bắt đầu các bài kiểm tra tích hợp. Một ví dụ khác về các mục tiêu
liên quan đến chất lượng phần mềm là: Các trường hợp kiểm thử cấp
hệ thống được nhóm thành kiểm thử chức năng, kiểm tra độ tin cậy,
kiểm tra tải, kiểm tra bảo mật, v.v.
Một ví dụ về các mục tiêu liên quan đến quy trình là: Trong khi quá
trình thử nghiệm hệ thống đang diễn ra, phần trăm các trường hợp thử
nghiệm đã vượt qua phải được theo dõi hàng tuần. Một ví dụ khác là:
Thử nghiệm hệ thống được giảm thời gian bằng cách sử dụng nhiều
giường thử nghiệm.
Phân tích rủi ro: Các yếu tố có thể ảnh hưởng xấu đến việc kiểm tra
phải được xác định. Một ví dụ về rủi ro trong thử nghiệm là người ta
đã nhấn mạnh nhiều vào khía cạnh hiệu suất của hệ thống, nhưng
không có kỹ sư thử nghiệm nào có khả năng thiết kế và thực hiện các
thử nghiệm hiệu suất trong quá trình thử nghiệm hệ thống.
Chiến lược phát triển: Các loại chiến lược khác nhau đều có liên
quan đến thử nghiệm. Ví dụ: chúng ta có thể chọn một trong số một
số chiến lược kiểm tra tích hợp, chẳng hạn như từ trên xuống, từ dưới
lên và tăng dần, hoặc một chiến lược cần được tuân theo trong quá
trình thực hiện các trường hợp kiểm tra hệ thống như đã thảo luận
trong Phần 12.7. Trên thực tế, mọi hoạt động thử nghiệm lớn đều đòi
hỏi phải tuân theo một chiến lược nhất định.
Xây dựng các thông số kỹ thuật kiểm tra: Các trường hợp kiểm
thử riêng lẻ phải được thiết kế và lập thành văn bản một cách thận
trọng. Phải có một mục tiêu kèm theo thiết kế của mỗi trường hợp thử
nghiệm. Tiếp theo, một quy trình phác thảo các bước của test case
được thiết kế. Đầu vào mong muốn và kết quả mong đợi tương ứng
với trường hợp thử nghiệm được xác định. Điều kiện ban đầu để thực
hiện mỗi trường hợp thử nghiệm cũng được xác định. Cuối cùng, một
trường hợp thử nghiệm được ghi lại đúng cách để dễ sử dụng và khả
năng truy cập.
Phân bổ nguồn lực: Việc phân bổ nguồn lực là một nhiệm vụ quan
trọng trong bất kỳ hoạt động được lên kế hoạch nào. Cần có một số
loại tài nguyên khác nhau để kiểm thử phần mềm: kỹ sư kiểm thử có
•
chuyên môn phù hợp, tài nguyên để thiết lập môi trường kiểm thử và
tài nguyên để quản lý quá trình kiểm thử. Nói cách khác, đối với mỗi
hoạt động thử nghiệm, nhân sự, kinh phí và thời gian phải được phân
bổ.
Các mục tiêu phụ về trưởng thành cụ thể sau đây có thể hỗ trợ mục
tiêu trên ở cấp độ 2: • Tổ chức giao nhiệm vụ lập kế hoạch kiểm tra
cho một ủy ban xác định. Ủy ban phát triển một khuôn khổ để lập kế
hoạch kiểm tra.
Ủy ban phát triển một mẫu kế hoạch thử nghiệm, và mẫu này được
ghi chép đầy đủ và phổ biến rộng rãi.
Các công cụ thích hợp được sử dụng để tạo và quản lý các kế hoạch
kiểm tra.
Các quy định được đưa ra để nhu cầu của khách hàng tạo thành một
phần của kế hoạch thử nghiệm. Nói cách khác, khách hàng được tham
gia vào quá trình thử nghiệm.
(iii) InstitutionalizeBasicTestingandMethods Một số phương pháp và
kỹ thuật thử nghiệm cơ bản được biết đến rộng rãi trong ngành. Ví
dụ: kiểm tra mức đơn vị có thể được thực hiện bằng cách tập trung
vào các khía cạnh của luồng điều khiển và luồng dữ liệu trong một
đơn vị chương trình và một số chỉ số về độ bao phủ của mã được liên
kết với các kỹ thuật thử nghiệm đó. Các chỉ số về phạm vi kết hợp
với các kỹ thuật đó cho phép người thử nghiệm định lượng thử
nghiệm cấp đơn vị. Hơn nữa, cả hai phương pháp kiểm tra hộp trắng
và hộp đen đều có thể được áp dụng ở cấp độ đơn vị. Khi người thử
nghiệm chuyển từ cấp độ đơn vị lên cấp độ cao hơn, chẳng hạn như
cấp độ tích hợp và hệ thống, kiểm thử hộp đen trở thành tiêu chuẩn vì
việc áp dụng kỹ thuật kiểm thử hộp trắng cho một hệ thống con lớn là
vô cùng khó khăn. Người ta cần áp dụng một hoặc nhiều kỹ thuật để
thực hiện kiểm thử hộp đen: kiểm thử chương trình chức năng, phân
vùng lớp tương đương, phân tích giá trị ranh giới, bảng quyết định và
đoán lỗi. Ma trận xác định nguồn gốc yêu cầu phải được xác định để
duy trì mối liên hệ giữa các yêu cầu và trường hợp thử nghiệm, nghĩa
là, trường hợp thử nghiệm nào bao hàm từng yêu cầu và yêu cầu nào
được đề cập trong từng trường hợp thử nghiệm. Bằng cách theo dõi
những trường hợp thử nghiệm nào đã vượt qua, người ta biết cho đến
nay hệ thống đang thử nghiệm đã thỏa mãn những yêu cầu nào. Mục
tiêu trưởng thành ở trên có thể được hỗ trợ bởi các mục tiêu phụ sau:
Một nhóm chuyên gia được thành lập để nghiên cứu, đánh giá và đề
xuất một tập hợp các kỹ thuật và phương pháp thử nghiệm cơ bản.
Nhóm cũng đề xuất một số công cụ hỗ trợ các kỹ thuật và phương
pháp kiểm tra đó.
Ban Giám đốc phải thiết lập các chính sách để đảm bảo rằng các kỹ
thuật và phương pháp được khuyến nghị được thực hành và các công
cụ được sử dụng trong toàn tổ chức một cách nhất quán.
Cấp độ 3. Tích hợp Ở cấp độ 3, như tên gọi, kiểm thử được tích hợp
hoàn toàn với quá trình phát triển ngay từ khi lập kế hoạch dự án.
Kiểm tra không giới hạn đối với một hoạt động bắt đầu sau khi mã
hóa kết thúc. Cả thử nghiệm cũng không được coi là chỉ dựa trên thực
thi. Thay vào đó, các loại hoạt động kiểm tra khác nhau được thực
hiện trong suốt vòng đời của hệ thống và một số hoạt động kiểm tra
đó được thực hiện mà không cần thực thi mã. Ở cấp độ 3, một tổ chức
tạo ra một nhóm kiểm thử riêng biệt bao gồm các chuyên gia kiểm
thử và người quản lý kiểm thử, các nguồn lực của riêng họ và một
lịch trình để có thể đưa cảm giác chất lượng vào các sản phẩm phần
mềm từ quá trình hình thành dự án. Ví dụ, tại thời điểm đặc tả yêu
cầu, nhóm thử nghiệm có thể tác động đến quá trình thu thập yêu cầu
bằng cách (i) xác nhận rằng tất cả các yêu cầu đều có thể kiểm tra
được và (ii) bao gồm các yêu cầu của chính họ để các yêu cầu của
khách hàng có thể kiểm tra được. Nhóm thử nghiệm độc lập đánh giá
hệ thống từ quan điểm của khách hàng bằng cách tương tác trực tiếp
với khách hàng và kết hợp quan điểm của họ vào quá trình thiết kế
thử nghiệm. Bằng cách hoạt động độc lập, nhóm kiểm tra tập trung
vào các vấn đề liên quan đến chất lượng, chẳng hạn như thể chế hóa
các kỹ thuật và phương pháp kiểm tra, đánh giá các công cụ kiểm tra,
đánh giá khả năng kiểm tra của các yêu cầu, thuê và đào tạo các kỹ sư
kiểm tra bằng cách xem xét nhu cầu của dự án và xác định các chỉ số
kiểm tra. Nói cách khác, mục tiêu của họ là thực hiện các hoạt động
thử nghiệm để phần mềm chất lượng cao hơn được sản xuất với chi
phí thấp hơn và trong thời gian ngắn. Các mục tiêu trưởng thành ở
cấp độ 3 như sau:
Thành lập nhóm kiểm thử phần mềm.
•
Thiết lập một chương trình đào tạo kỹ thuật.

Tích hợp kiểm thử vào vòng đời phần mềm.
Kiểm soát và giám sát quá trình thử nghiệm.
(i) Thành lậpSoftwareTestGroup Kiểm thử phần mềm là một nhiệm
vụ chuyên môn cao ngang với việc nắm bắt các yêu cầu và thiết kế
một hệ thống. Người ta đã thừa nhận rộng rãi rằng các hoạt động thử
nghiệm phải được bắt đầu ngay khi bắt đầu lập kế hoạch cho một dự
án. Do đó, phải tồn tại một nhóm kiểm thử độc lập để thực hiện kiểm
thử mà không có bất kỳ ảnh hưởng nào từ các nhà phát triển. Những
lợi thế của việc có một nhóm kiểm tra độc lập như sau:
Nhóm thử nghiệm độc lập có thể phát triển kiến thức chuyên môn
mong muốn về thử nghiệm bằng cách thuê đúng người và cung cấp
đào tạo cho các thành viên của nhóm.
Nhóm kiểm thử có thể có tác động tích cực đến chất lượng phần mềm
bằng cách cho các thành viên tham gia vào các cuộc họp để xem xét
các yêu cầu trong giai đoạn thu thập yêu cầu của vòng đời phần mềm.
Các thành viên từ nhóm kiểm tra đảm bảo rằng các yêu cầu có thể
kiểm tra được. Đảm bảo khả năng kiểm tra của một yêu cầu là rất
quan trọng vì nếu không có quy trình cụ thể để xác minh rằng hệ
thống phần mềm sở hữu một yêu cầu nhất định, tổ chức không thể
thuyết phục khách hàng rằng nhu cầu của họ được đáp ứng.
Kiểm tra liên quan đến nhiều nhiệm vụ chuyên biệt, chẳng hạn như
lập kế hoạch kiểm tra, thiết kế kiểm thử, thực hiện kiểm tra, lập lịch
kiểm tra, tuân theo các tiêu chuẩn liên quan đến kiểm tra, thu thập và
giám sát các chỉ số kiểm tra, duy trì các trường hợp kiểm thử và theo
dõi các lỗi. Do đó, lập lịch trình cho các nhiệm vụ đó và mua sắm các
tài nguyên cần thiết là rất quan trọng để hoàn thành việc kiểm tra hệ
thống đúng thời hạn. • Chất lượng của một sản phẩm phần mềm được
đánh giá độc lập mà không có bất kỳ sự can thiệp nào từ nhóm phát
triển. Sự độc lập này là trọng tâm để tránh mọi thành kiến cố ý hoặc
vô ý mà các nhà phát triển có thể có đối với sản phẩm của họ.
Khách hàng cảm thấy tin tưởng hơn nhiều về một sản phẩm nếu nó
đã được thử nghiệm và đánh giá bởi một nhóm thử nghiệm độc lập
với nhóm phát triển.
Do đó, thử nghiệm phải được thực hiện bởi một nhóm thử nghiệm
độc lập. Các mục tiêu phụ về thời gian đáo hạn hỗ trợ các mục tiêu
trên như sau:
Một nhóm kiểm tra toàn tổ chức được thành lập với sự lãnh đạo, hỗ
trợ mạnh mẽ và tài trợ từ ban quản lý. Nhóm kiểm tra phải được trao
quyền ảnh hưởng đến chất lượng của các sản phẩm phần mềm để việc
hình thành nhóm kiểm tra không được coi là một bài tập đơn thuần.
Nhóm kiểm thử phải tham gia vào tất cả các giai đoạn phát triển phần
mềm, vai trò và trách nhiệm phải được giao cho các thành viên nhóm
riêng lẻ trong các giai đoạn phát triển phần mềm thích hợp.
Các kỹ sư thử nghiệm được đào tạo và có động cơ được chỉ định vào
nhóm thử nghiệm.
Nhóm thử nghiệm trong một tổ chức phải giao tiếp với khách hàng để
có được cảm nhận về nhu cầu của họ để có thể tiến hành thử nghiệm
nhằm đáp ứng mong đợi của khách hàng.
(ii) Chương trình huấn luyện kỹ thuật thành lập Một chương trình đào
tạo kỹ thuật là điều cần thiết để duy trì một nhóm nhân viên có trình
độ và tay nghề cao để kiểm tra. Các tổ chức có xu hướng thuê nhân
viên không có tay nghề cao cho các công việc thử nghiệm vì nói
chung không có đủ nhân viên thử nghiệm đủ trình độ trong ngành. Do
đó, các tổ chức phải nỗ lực liên tục để đào tạo nhân viên thử nghiệm
về khái niệm chất lượng, lập kế hoạch thử nghiệm, phương pháp và
kỹ thuật thử nghiệm, tiêu chuẩn và công cụ thử nghiệm. Các kỹ sư
kiểm tra tìm hiểu các khái niệm và quy trình của các loại đánh giá
khác nhau, chẳng hạn như xem xét thiết kế và xem xét mã, được thảo
luận trong Chương 3.
(iii) IntegrateTestingintoSoftwareLifeCycle Ngược lại với cấp độ 2,
nơi thử nghiệm được bắt đầu như một hoạt động riêng biệt sau khi mã
hóa kết thúc, thử nghiệm ở cấp độ 3 là hoàn toàn
•
được tích hợp với vòng đời phát triển phần mềm khi bắt đầu lập kế
hoạch dự án. Do đó, lập kế hoạch thử nghiệm được bắt đầu từ rất sớm
trong vòng đời của sản phẩm. Tập trung sớm vào thử nghiệm cho
phép nhóm thử nghiệm tham gia vào việc thu thập yêu cầu, thiết kế
và đánh giá mã. Các mục tiêu phụ về thời gian đáo hạn để hỗ trợ mục
tiêu trên như sau:
Giai đoạn kiểm thử được phân chia thành nhiều hoạt động, chẳng hạn
như lập kế hoạch kiểm thử, kiểm thử đơn vị, kiểm thử tích hợp, kiểm
thử hệ thống và kiểm thử chấp nhận, để các hoạt động riêng biệt được
thực hiện dễ dàng vào những thời điểm thích hợp trong vòng đời của
một sản phẩm phần mềm. Các loại đánh giá khác nhau, chẳng hạn
như đánh giá yêu cầu, đánh giá thiết kế và đánh giá mã, được xác
định. Tất cả các hoạt động kiểm tra và đánh giá đó được tích hợp vào
mô hình V-mô hình kiểm tra.
Tất cả các hoạt động thử nghiệm và xem xét được tích hợp vào một
mô hình thử nghiệm chữ V được thể chế hóa và tổ chức phải đảm bảo
rằng mô hình này được tuân thủ.
Tổ chức hỗ trợ một cơ chế hiệu quả để nhóm thử nghiệm giao tiếp
với các nhà phát triển, khách hàng và nhóm tiếp thị. Kết quả là, các
kỹ sư thử nghiệm tìm hiểu về các yêu cầu, chi tiết thiết kế, kỳ vọng
của khách hàng và triết lý tiếp thị của tổ chức. Nhóm kiểm tra càng
hiểu biết nhiều về sản phẩm thì càng có nhiều ảnh hưởng đến chất
lượng sản phẩm. Quản lý cấp trên của một tổ chức phải tạo điều kiện
thuận lợi cho việc trao đổi thông tin đó.
(iv) Giám sát và Kiểm soát Quá trình Kiểm tra Giám sát và kiểm soát
là những khía cạnh quan trọng của việc lập kế hoạch. Nếu không có
sự giám sát thì sẽ không thể biết được liệu một dự án có diễn ra đúng
tiến trình hay không, và do đó, không thể thực hiện các biện pháp
khắc phục để kiểm soát dự án. Cấp độ 3 liên quan đến một số hoạt
động giám sát và kiểm soát liên quan đến thử nghiệm để cung cấp
khả năng hiển thị về tiến trình của một dự án thử nghiệm. Ban quản
lý có thể thực hiện hành động hiệu quả để một dự án thử nghiệm bám
sát kế hoạch nhất có thể khi tiến độ của dự án khác biệt đáng kể so
•
•
với kế hoạch. Tiến độ của một dự án thử nghiệm có thể được đo

lường như sau:
Số lượng nỗ lực Kiểm thử: Điều này bao gồm số lượng các trường
hợp kiểm thử được thiết kế và số lượng các trường hợp kiểm thử
được thực thi.
Chi phí thử nghiệm: Chi phí này đại diện cho tất cả các chi phí
trong việc thực hiện các hoạt động liên quan đến thử nghiệm.
Lịch trình: Điều này liên quan đến thời gian bắt đầu và kết thúc của
các hoạt động thử nghiệm.
Các mục tiêu phụ về thời gian đáo hạn sau đây là bắt buộc để hỗ trợ
mục tiêu trên:
Tổ chức phát triển các chính sách và cơ chế để giám sát và kiểm soát
các dự án thử nghiệm.
Một tập hợp các chỉ số liên quan đến quy trình thử nghiệm được sử
dụng phải được xác định, ghi lại và cung cấp cho tất cả các kỹ sư thử
nghiệm có liên quan.
Một tập hợp các hành động khắc phục tiềm ẩn và kế hoạch dự phòng
phải được xác định và lập thành văn bản. Nó có thể được sử dụng khi
tiến độ thực tế của một dự án thử nghiệm khác biệt đáng kể so với kế
hoạch.
Cấp độ 4. Quản lý và đo lường Ở cấp độ 4 của TMM, kiểm thử có
phạm vi lớn hơn nhiều và không chỉ là một giai đoạn khác trong vòng
đời phát triển phần mềm. Sau đây là các mục tiêu trưởng thành ở cấp
độ 4:
Thiết lập một chương trình đánh giá toàn tổ chức.
Thiết lập chương trình đo kiểm tra.
Đánh giá chất lượng phần mềm.
(i) Chương trình SettingOrganizationwideReview Để tăng cường thử
nghiệm dựa trên thực thi, một chương trình đánh giá được thiết lập để
phát hiện sớm các khiếm khuyết trong vòng đời phát triển sản phẩm
và với chi phí thấp hơn. Tất cả các sản phẩm phần mềm, chẳng hạn
như tài liệu yêu cầu và tài liệu thiết kế, đều được xem xét. Hơn nữa,
các kế hoạch kiểm thử, các trường hợp kiểm thử và quy trình kiểm
•
•
thử đều được xem xét kỹ lưỡng. Do đó, đánh giá được thực hiện
trong suốt vòng đời của sản phẩm. Các mục tiêu phụ hỗ trợ mục tiêu
này như sau:
Ban lãnh đạo cần phát triển các chính sách xem xét và đảm bảo rằng
các chính sách đó được tuân thủ nghiêm ngặt.
Nhóm kiểm tra cần phát triển các mục tiêu, kế hoạch, thủ tục và cơ
chế ghi lại để thực hiện các đánh giá.
Mục tiêu phải được xác định rõ ràng. • Các thành viên của nhóm
kiểm tra phải được đào tạo để đảm bảo sự tham gia hiệu quả của họ
vào các quá trình xem xét.
(ii) Chương trình đo lường thiết lập Một chương trình đo lường thử
nghiệm được thiết lập để đo lường năng suất, tiến độ và chất lượng
công việc liên quan đến thử nghiệm. Ví dụ: năng suất trong thử
nghiệm đề cập đến tốc độ thiết kế thử nghiệm về số lượng trường hợp
thử nghiệm mỗi người trong ngày và số lượng trường hợp thử nghiệm
được thực hiện bởi một người mỗi ngày. Số lượng các trường hợp thử
nghiệm được một người xem xét mỗi ngày là một ví dụ khác về năng
suất trong thử nghiệm. Tiến độ kiểm tra đề cập đến mức độ công việc
đã được hoàn thành với tham chiếu đến mức độ cần thiết phải được
thực hiện. Do đó, người ta phải đo đều đặn tất cả các đại lượng biểu
thị sự tiến bộ. Một số ví dụ về các đại lượng có thể đo lường là số
lượng trường hợp thử nghiệm đã được thiết kế và số lượng trường
hợp thử nghiệm đã được thực hiện. Chất lượng của một sản phẩm
phần mềm được đo bằng cường độ hỏng hóc, tức là số lượng lỗi được
quan sát thấy trên một đơn vị thời gian. Các mục tiêu phụ hỗ trợ mục
tiêu này như sau: • Các chỉ số kiểm tra phải được xác định cùng với
các mục tiêu của chúng.
Một kế hoạch đo kiểm cần được phát triển với việc thu thập và phân
tích dữ liệu.
Một kế hoạch hành động cần được phát triển để đạt được sự cải tiến
quy trình bằng cách xem xét các dữ liệu đo được.
(iii) Đánh giá Phần mềm Chất lượng Mục tiêu quan trọng của quá
trình phát triển phần mềm là tạo ra các sản phẩm phần mềm có chất
•
•
lượng cao nhất có thể. Một nhóm kiểm tra phải đo lường chất lượng
của sản phẩm để tìm hiểu chất lượng mà một quá trình nhất định có
thể dẫn đến và thực hiện các biện pháp để cải tiến quá trình với mục
tiêu nâng cao chất lượng sản phẩm. Do đó, nhóm thử nghiệm phải
xác định các thước đo chất lượng, chẳng hạn như tính đúng đắn, độ
tin cậy, khả năng bảo trì và khả năng sử dụng, để cải thiện thêm.
Nhóm thử nghiệm phải đánh giá tính đầy đủ của một quá trình thử
nghiệm để đánh giá đáng tin cậy các chất lượng kết quả trong sản
phẩm. Các mục tiêu phụ về thời gian đáo hạn hỗ trợ mục tiêu này như
sau:
Tổ chức cần xác định các thuộc tính chất lượng và mục tiêu chất
lượng cho các sản phẩm phần mềm.
Ban lãnh đạo nên xây dựng các chính sách và cơ chế để thu thập các
chỉ số đo kiểm nhằm hỗ trợ các mục tiêu chất lượng.
Cấp độ 5. Tối ưu hóa, Phòng ngừa sai sót và Kiểm soát chất
lượng Tối ưu hóa và phòng ngừa sai sót là các khái niệm ở cấp độ
cao nhất, cụ thể là cấp độ 5. Về mặt trực quan, tối ưu hóa có nghĩa là
chi tiêu ít tài nguyên hơn để đạt được sản phẩm chất lượng cao hơn
và phòng ngừa lỗi có nghĩa là thực hiện các biện pháp trong suốt quá
trình phát triển để các sản phẩm phần lớn không có khuyết tật. Ở cấp
độ 5, các mục tiêu trưởng thành như sau:
Ứng dụng dữ liệu quy trình để ngăn ngừa lỗi
Kiểm soát chất lượng thống kê
Tối ưu hóa quy trình kiểm tra
(i) ApplyationofProcessDataforDefectPrevention Ở cấp độ 5, các tổ
chức nỗ lực liên tục để học hỏi kinh nghiệm nhằm giảm thiểu số
lượng khiếm khuyết trong hệ thống. Phòng ngừa khiếm khuyết là một
đặc điểm quan trọng của các tổ chức trưởng thành. Các nhóm kiểm
tra trong các tổ chức trưởng thành phân tích các khuyết tật và các
mẫu của chúng và thực hiện phân tích nguyên nhân gốc rễ để hiểu rõ
hơn về các mẫu khuyết tật. Để ngăn ngừa sự tái diễn của các khiếm
khuyết phổ biến trong các dự án tương lai, các kế hoạch hành động
được phát triển và các quy trình được cải thiện. Phải có cơ chế để
•
•
đảm bảo rằng các kế hoạch hành động được tuân thủ. Các cơ chế như
vậy bao gồm việc hình thành một nhóm ngăn ngừa lỗi tương tác với
các nhà phát triển để áp dụng các hoạt động ngăn ngừa lỗi trong quá
trình phát triển. Các mục tiêu phụ về sự trưởng thành hỗ trợ mục tiêu
này như sau: • Ban giám đốc nên thành lập một nhóm phòng ngừa sai
sót.
Các khiếm khuyết được xác định và loại bỏ được ghi lại trong từng
giai đoạn phát triển.
Mỗi khiếm khuyết được phân tích để tìm ra nguyên nhân gốc rễ của
nó.
Các nhà quản lý, nhà phát triển và nhóm kiểm tra nên tương tác để
phát triển một kế hoạch hành động nhằm loại bỏ sự tái diễn của các
khiếm khuyết thường xảy ra.
Ban lãnh đạo nên đặt ra một cơ chế để thực hiện và theo dõi kế hoạch
hành động.
•
(ii) StatisticalQualityControl Ở cấp độ 5, các tổ chức nâng cao hơn
nữa chất lượng của các sản phẩm phần mềm bằng cách thúc đẩy quá
trình thử nghiệm với lấy mẫu thống kê, đo lường mức độ tin cậy, độ
tin cậy và các mục tiêu về độ tin cậy của phần mềm. Mục tiêu này
mạnh hơn mục tiêu đánh giá chất lượng phần mềm ở cấp độ 3. Có thể
nhắc lại rằng mục tiêu đánh giá chất lượng tập trung vào các loại chất
lượng phần mềm khác nhau, chẳng hạn như chức năng, độ tin cậy,
khả năng sử dụng và tính mạnh mẽ. Các công cụ tự động được sử
dụng để thu thập và phân tích lỗi. Mô hình sử dụng được sử dụng để
thực hiện kiểm tra thống kê, trong đó mô hình sử dụng được chọn từ
một tập hợp con của tất cả các cách sử dụng có thể có của phần mềm.
Từ thử nghiệm thống kê, người ta có thể kết luận về hiệu suất hoạt
động chung của sản phẩm phần mềm. Các mục phụ hỗ trợ kiểm soát
chất lượng thống kê như sau:
Nhóm thử nghiệm thiết lập các mục tiêu chất lượng có thể đo lường ở
mức cao, chẳng hạn như tốc độ thực hiện trường hợp thử nghiệm, tỷ
lệ xuất hiện khuyết tật và tổng số khuyết tật có thể tìm thấy trong quá
trình thử nghiệm.
Các nhà quản lý đảm bảo rằng các mục tiêu chất lượng mới là một
phần của kế hoạch kiểm tra. • Nhóm kiểm tra được đào tạo về các
phương pháp kiểm tra và phân tích thống kê: phân tích Pareto, sơ đồ
nguyên nhân và kết quả, lưu đồ, biểu đồ xu hướng, biểu đồ, biểu đồ
phân tán và biểu đồ kiểm soát.
Đầu vào của người dùng được thu thập để lập mô hình sử dụng.
(iii) TestProcessOptimization Tối ưu hóa thử nghiệm đề cập đến tất
cả các hoạt động dẫn đến cải tiến liên tục quy trình thử nghiệm. Một
yếu tố thiết yếu của tối ưu hóa thử nghiệm là lượng hóa quy trình thử
nghiệm để có thể thực hiện các phép đo chính xác nhằm tìm ra nơi có
thể cải tiến thêm. Tối ưu hóa thử nghiệm bao gồm các hoạt động sau:
Xác định các phương pháp kiểm tra có thể được cải thiện.
Xác định một cơ chế để cải thiện một thực hành đã được xác định.
Đặt một cơ chế để theo dõi cơ chế cải thiện thực hành.
Liên tục đánh giá các công nghệ và công cụ liên quan đến thử nghiệm
mới.
Phát triển quản lý hỗ trợ chuyển giao công nghệ.
Các mục tiêu phụ hỗ trợ tối ưu hóa quy trình kiểm tra như sau:
797
Thành lập nhóm cải tiến quy trình thử nghiệm để giám sát quá trình
thử nghiệm và xác định các lĩnh vực cần cải tiến.
Đánh giá các công nghệ và công cụ mới để cải thiện khả năng của
quá trình thử nghiệm. Cần phải có sự hỗ trợ của quản lý để thiết lập
các chính sách và cơ chế cho mục đích này.
Một cơ chế được đưa ra để đánh giá liên tục hiệu quả của quá trình
thử nghiệm.
Tiêu chí dừng kiểm tra dựa trên các mục tiêu chất lượng, được thảo
luận trong Chương 12.
18.5 TÓM TẮT
CMM là một khuôn khổ để đánh giá và cải thiện năng lực hiện tại của
một công ty phát triển phần mềm. Như tên cho thấy, CMM có thể
được sử dụng để đánh giá khả năng phát triển hệ thống phần mềm
của một tổ chức đã trưởng thành ở mức độ nào. Mô hình cho phép
người ta đánh giá một tổ chức trên thang điểm từ 1–5, trong đó 5 thể
hiện mức độ trưởng thành cao nhất. Mô hình cho phép người ta đánh
giá một tổ chức bằng cách xem xét các hoạt động hiện tại của tổ chức
đó. Về cơ bản, CMM là một cách tiếp cận cải tiến quy trình. Để
chuyển sang cấp độ trưởng thành tiếp theo, các tổ chức cần áp dụng
các thông lệ mới phù hợp với cấp độ trưởng thành tiếp theo. Cấp độ 1
là cấp độ ban đầu, cấp độ 2 được gọi là có thể lặp lại, cấp độ 3 là cấp
độ xác định, cấp độ 4 được quản lý và cấp độ 5 là cấp độ tối ưu hóa.
Mỗi cấp độ được đặc trưng bởi một tập hợp các khu vực quy trình
chính.
Điều hữu ích là nhớ lại rằng CMM tập trung vào toàn bộ quá trình
phát triển, trong khi mô hình TPI cho phép chúng ta chỉ tập trung vào
một quá trình thử nghiệm. Quá trình kiểm tra là một cách thức nhất
định để thực hiện các hoạt động liên quan đến việc ngăn ngừa và phát
hiện khuyết tật. Một số ví dụ về hoạt động kiểm thử là xác định mục
tiêu kiểm thử, chuẩn bị kế hoạch kiểm thử và thiết kế các trường hợp
kiểm thử. Quy trình kiểm tra cần được cải thiện vì ba lý do: (i) Quy
trình kiểm tra tốt hơn sẽ cung cấp thông tin chi tiết hơn về các đặc
tính chất lượng của hệ thống, (ii) quy trình kiểm tra tốt hơn sẽ giảm
thời gian kiểm tra và (iii) quy trình kiểm tra tốt hơn nên chi phí thấp
hơn. Tim Koomen và Martin Pol [4] đưa ra ý tưởng cải tiến quy trình
kiểm tra bằng cách đề xuất mô hình TPI. Về mặt trực quan, bất kỳ
cách tiếp cận nào để cải thiện quy trình kiểm tra đều bao gồm bốn
bước sau: (i) Xác định lĩnh vực cần cải tiến, (ii) đánh giá trạng thái
hiện tại của quy trình kiểm tra, (iii) xác định trạng thái mong muốn
tiếp theo và các phương tiện để đạt được nó, và (iv) thực hiện các
thay đổi cần thiết đối với quy trình. Quá trình kiểm tra được đánh giá
liên quan đến 20 lĩnh vực chính, chẳng hạn như chiến lược kiểm tra,
thời điểm tham gia, lập kế hoạch và số liệu. Mức độ trưởng thành của
quá trình kiểm tra được đánh giá trên thang điểm từ 1–13. 13 cấp độ
trưởng thành của quy trình kiểm tra được phân chia thành ba nhóm
định tính rộng, cụ thể là, được kiểm soát, hiệu quả và tối ưu hóa.
Cuối cùng, TMM đưa ra các hướng dẫn liên quan đến cách cải thiện
quy trình kiểm tra. Trong mô hình này, sự thành thục của một quá
trình thử nghiệm được đánh giá trên thang điểm từ 1–5. Mỗi cấp độ
trong số năm cấp độ trưởng thành được đặc trưng bởi các khái niệm
về mục tiêu trưởng thành; các mục tiêu trưởng thành được hỗ trợ bởi
các mục tiêu phụ và các hoạt động, nhiệm vụ và trách nhiệm. Năm
cấp độ trưởng thành được gọi là ban đầu (cấp độ 1), xác định giai
đoạn (cấp độ 2), tích hợp (cấp độ 3), quản lý và đo lường (cấp độ 4)
và tối ưu hóa, ngăn ngừa lỗi và kiểm soát chất lượng (cấp độ 5).
Nhiều sách và bài báo đã được viết về CMM và CMMI. Một bài báo
toàn diện về CMM là của Paulk, Curtis, Chrissis và Weber [2] — ba
tác giả đầu tiên đến từ Viện Kỹ thuật Phần mềm. Hai cuốn sách hay
về CMM và CMMI lần lượt là của Land [3] và Mutafelija và
Stromberg [7]. Tuy nhiên, các bản sửa đổi được thực hiện đối với các
tài liệu CMM và CMMI theo thời gian
thời gian. Vì vậy, rất hữu ích khi tham khảo trang web chính của SEI
để biết thông tin kịp thời về CMM và CMMI:
http://www.sei.cmu.edu/.
Để biết thêm thông tin về mô hình TPI, người đọc có thể tham khảo
cuốn sách có tựa đề Cải tiến Quy trình Kiểm tra của Koomen và Pol
[4]. Để biết thêm thông tin về TMM, người đọc có thể tham khảo
cuốn sách có tựa đề Kiểm thử phần mềm thực tế của Burnstein [5].
Một mô hình trưởng thành khác thường được các tổ chức áp dụng
được gọi là mô hình trưởng thành Six Sigma để giải quyết các vấn đề
799
về chất lượng và sự hài lòng của khách hàng. Six Sigma được tạo ra
bởi một số CEO tài năng nhất của Mỹ, những người như Bob Galvin
của Motorola, Larry Bossidy của AlliedSignal và Jack Welch của GE.
Six Sigma là một phương pháp tiếp cận đa diện, dựa vào doanh
nghiệp để cải tiến quy trình, giảm chi phí và tăng lợi nhuận. Để đạt
được Six Sigma, một quy trình không được tạo ra nhiều hơn 3,4
khuyết tật trên một triệu cơ hội. Phương pháp luận Six Sigma
DMAIC, bao gồm năm bước xác định, đo lường, phân tích, cải tiến
và kiểm soát, là một hệ thống cải tiến cho các quy trình hiện có dưới
đặc điểm kỹ thuật và đang tìm kiếm sự cải tiến gia tăng. Phương pháp
luận DMADV Six Sigma, bao gồm năm bước xác định, đo lường,
phân tích, thiết kế và xác minh, là một hệ thống cải tiến được sử dụng
để phát triển các quy trình hoặc sản phẩm mới ở mức chất lượng Six
Sigma. Nó cũng có thể được sử dụng nếu một quy trình hiện tại yêu
cầu nhiều hơn là chỉ cải tiến gia tăng. Độc giả quan tâm được khuyến
khích đọc những cuốn sách sau để thảo luận chi tiết về chủ đề này:
M. Harry, Six Sigma: Chiến lược quản lý đột phá Cách mạng hóa các
tập đoàn hàng đầu thế giới, Random House, New York, 2000.
T. Pyzdek, Sổ tay Six Sigma, McGraw-Hill Professional, New York,
2001.
RR Macala, Jr., LD Stuckey và DC Gross. Quản lý phát triển dòng

sản phẩm, miền cụ thể. Thực hành và trải nghiệm phần mềm, Vol. 13,
số 3, 1996, trang 57–68.
M. Paulk, B. Curtis, MB Chrissis và CV Weber. Mô hình trưởng
thành năng lực, Phiên bản 1.1. Phần mềm IEEE, tháng 7 năm 1993,
trang 18–27.
S. Đất. Khởi động CMM / CMMI Cải tiến quy trình phần mềm.
Wiley, Hoboken, NJ, 2005.
T. Koomen và M. Pol. Cải tiến Quy trình Kiểm tra. Addison-Wesley,
Reading, MA, 1999.
I. Burnstein. Kiểm thử phần mềm thực tế. Springer, New York, 2003.
I. Burnstein, A. Homyen, T. Suwanassart, G. Saxena và R. Grom.
Đánh giá và cải tiến quy trình kiểm tra phần mềm Modelfor A
Testing Maturity. Chuyên gia Chất lượng Phần mềm, tháng 9 năm
1999, trang 1–8.
B. Mutafelija và H. Stromberg. Cải tiến Quy trình có Hệ thống Sử

dụng ISO 9001: 2000 và CMMI. Artech House, Boston, MA 2003.
Bài tập
Giải thích ngắn gọn về kiến trúc CMM.
Giải thích ngắn gọn năm cấp độ trưởng thành trong mô hình CMM.
Giải thích ngắn gọn các đặc điểm chung của các thực hành chính
trong mô hình CMM.
Giải thích ngắn gọn ý tưởng của một quá trình thử nghiệm.
Tại sao điều quan trọng là phải cải thiện quy trình kiểm tra?
Giải thích ngắn gọn cách tiếp cận trực quan để cải thiện quy trình
kiểm tra.
Giải thích ngắn gọn cách đánh giá trạng thái hiện tại của quá trình thử
nghiệm.
Giải thích ngắn gọn mức độ trưởng thành của các khu vực chính
trong mô hình TPI.
Giải thích ngắn gọn ý chính trong TMM.
Giải thích ngắn gọn các cấp độ khác nhau trong TMM về mục tiêu
trưởng thành của họ.
801
GLOSSARY
Con người được sinh ra một mình và chết đi một mình; và anh ta trải
nghiệm những hậu quả tốt và xấu của nghiệp mình một mình; và anh
ta đi một mình đến địa ngục hoặc nơi ở tối cao. —Chanakya
Chuẩn giao tiếp 1xEvolution-data được tối ưu hóa (1xEV-DO)
để truyền và nhận các khung dữ liệu qua kênh vô tuyến không
dây sử dụng công nghệ CDMA.
Ký hiệu cú pháp trừu tượng Một (ASN.1) Ký hiệu để xác định
chính thức cú pháp của thông điệp được trao đổi giữa một loạt các
ứng dụng liên quan đến Internet.
chí chấp nhận Các tiêu chí một hệ thống phải đáp ứng để được
khách hàng chấp nhận và cho phép khách hàng xác định xem có chấp
nhận hệ thống hay không.
Kiểm tra chấp nhận Kiểm tra chính thức được tiến hành để
xác định liệu một hệ thống có đáp ứng các tiêu chí chấp nhận của nó
hay không.
Thiết bị đầu cuối truy cập Có thể là điện thoại di động, máy tính
xách tay hoặc trợ lý kỹ thuật số cá nhân (PDA) với modem không
dây.
Độ chính xác Mức độ phù hợp của một đại lượng được đo hoặc tính
toán với giá trị thực (đúng) của nó.
Thử nghiệm ngẫu nhiên thích ứng Trong thử nghiệm ngẫu
nhiên thích ứng, các đầu vào thử nghiệm được chọn từ một tập hợp
được tạo ngẫu nhiên theo cách sao cho các đầu vào thử nghiệm này
được trải đều trên toàn bộ miền đầu vào.
Miền liền kề Hai miền kề nhau nếu chúng có chung một bất đẳng
thức về biên.
Chế độ truyền không đồng bộ (ATM) Giao thức mạng chuyển
tiếp tế bào mã hóa lưu lượng dữ liệu thành các ô nhỏ, có kích thước
cố định (53 byte = 48 byte dữ liệu và 5 byte thông tin tiêu đề). Công
nghệ hướng kết nối trong đó kết nối được thiết lập giữa hai điểm cuối
trước khi bắt đầu trao đổi dữ liệu thực tế.
Thuộc tính Thuộc tính của dịch vụ được hệ thống cung cấp cho
người dùng.
Xác thực Quy trình xác minh danh tính được xác nhận của một
người nào đó hoặc một cái gì đó.
Xác thực, ủy quyền và kế toán (AAA) Máy chủ mạng được sử
dụng để kiểm soát quyền truy cập vào mạng. Quá trình xác thực xác
định người dùng. Quy trình ủy quyền thực hiện các chính sách xác
định tài nguyên và dịch vụ nào mà người dùng hợp lệ có thể truy cập.
Quy trình kế toán theo dõi thời gian và tài nguyên dữ liệu được sử
dụng để phân tích thanh toán và sử dụng.
Ủy quyền Quy trình xác minh xem một cá nhân có quyền truy
cập vào một tài nguyên cụ thể hay không.
581
tự động là một ứng cử viên tốt cho tự động hóa.
Tính sẵn sàng Đo lường mức độ sẵn sàng của một hệ thống.
Nói một cách đơn giản, tính khả dụng là tỷ lệ thời gian một hệ thống
ở trong tình trạng hoạt động.
Backdoor được tạo ra bởi một chương trình máy tính cho phép
bất kỳ ai có kiến thức về sự tồn tại của nó đều có thể truy cập vào hệ
thống.
Kiểm tra khả năng sao lưu / phục hồi Xác minh rằng hệ thống
có thể được khôi phục sau khi bị lỗi. Nó được thực hiện bằng cách
sao lưu vào một điểm trong chu kỳ xử lý trước khi xảy ra bất kỳ lỗi
nào và xử lý lại tất cả các giao dịch xảy ra sau thời điểm đó.
chữa sai Sửa chữa gây hư hỏng tài sản thế chấp.
Kiểm tra kết nối cơ bản Xác minh xem việc triển khai có thể
thiết lập kết nối cơ bản hay không trước khi thực hiện các thử nghiệm
kỹ lưỡng.
Thử nghiệm cơ bản Cung cấp một dấu hiệu sơ bộ cho thấy hệ thống
đã sẵn sàng cho các thử nghiệm nghiêm ngặt hơn.
Kiểm tra hành vi Xác minh các yêu cầu hệ thống truyền thông
động của một quá trình triển khai. Đây là các yêu cầu và tùy chọn
xác định hành vi có thể quan sát được của một giao thức. Một phần
lớn các bài kiểm tra hành vi, cấu thành phần chính của các bài kiểm
803
tra hệ thống truyền thông, có thể được tạo ra từ các tiêu chuẩn giao
thức.
nghiệm beta Thử nghiệm được thực hiện bởi người mua tiềm năng
trước khi phát hành sản phẩm. Mục đích của thử nghiệm beta không
nhằm mục đích tìm ra các khiếm khuyết mà là để thu thập thông tin
phản hồi từ hiện trường cho các nhà phát triển về khả năng sử dụng
của sản phẩm.
Big-bang Kỹ thuật kiểm tra tích hợp trong đó tất cả các mô-đun
phần mềm được kết hợp với nhau để xây dựng hệ thống hoàn chỉnh
để toàn bộ hệ thống có thể được kiểm tra.
Kiểm tra lỗi bit (BERT) Liên quan đến việc truyền một mẫu bit
đã biết qua một kênh và sau đó xác minh mẫu nhận được để tìm lỗi.
Kiểm thử hộp đen Còn được gọi là kiểm thử chức năng, một kỹ
thuật kiểm tra bỏ qua các chi tiết bên trong của hệ thống và chỉ tập
trung vào các đầu vào được chấp nhận, các đầu ra được tạo ra và các
điều kiện thực thi.
Kiểm tra khởi động Xác minh rằng hệ thống có thể khởi động hình
ảnh phần mềm của nó từ các tùy chọn khởi động được hỗ trợ.
Bot Đại lý phần mềm theo cách nói của Internet. Một bot tương
tác với các dịch vụ mạng dành cho mọi người như thể đó là một con
người. Một cách sử dụng điển hình của bot là thu thập thông tin. Một
cách sử dụng bot độc hại hơn nữa là điều phối và vận hành một cuộc
tấn công tự động trên các máy tính nối mạng, chẳng hạn như một
cuộc tấn công từ chối dịch vụ phân tán.
từ dưới lên Kỹ thuật kiểm tra tích hợp trong đó kiểm tra bắt đầu
từ các mô-đun ở các nhánh ngoài cùng của cây hiển thị mô-đun và
chuyển sang các mô-đun tạo nên “chương trình chính”.
Bất đẳng thức biên Từ quan điểm hình học, một miền được xác
định bởi một tập hợp các bất đẳng thức biên, trong đó mỗi bất đẳng
thức xác định một biên của miền.
Phân tích giá trị ranh giới (BVA) Mục đích của BVA là chọn các
phần tử gần với ranh giới của miền đầu vào để cả cạnh trên và cạnh
dưới của một lớp tương đương đều được bao phủ bởi các trường hợp
kiểm tra.
Phạm vi nhánh Lựa chọn các đường dẫn chương trình theo
cách mà các nhánh nhất định (tức là các cạnh đi ra của các nút) của
một đồ thị luồng điều khiển được bao phủ bởi việc thực hiện các
đường dẫn đó. Phạm vi chi nhánh hoàn toàn có nghĩa là chọn một số
đường dẫn sao cho việc thực thi của chúng khiến tất cả các chi nhánh
được bao phủ.
Xây dựng hình ảnh phần mềm tạm thời để thử nghiệm nội bộ
trong tổ chức. Cuối cùng, bản dựng cuối cùng sẽ là một ứng cử viên
để kiểm tra hệ thống và một hệ thống như vậy có thể được phát hành
cho khách hàng.
Kiểm tra chấp nhận kinh doanh (BAT) Được thực hiện trong tổ
chức phát triển của nhà cung cấp để đảm bảo rằng hệ thống cuối
cùng sẽ vượt qua kiểm tra chấp nhận của người dùng.
Mô hình trưởng thành khả năng (CMM) Cung cấp các hướng dẫn
để cải thiện quy trình phát triển phần mềm. Mô hình tạo điều kiện
thuận lợi cho việc đánh giá mức độ trưởng thành của các quá trình
trên thang điểm từ 1–5. Cấp độ 5 là cấp độ trưởng thành cao nhất của
quá trình.
khả năng Kiểm tra xem việc triển khai có cung cấp các khả
năng quan sát được dựa trên các yêu cầu của hệ thống truyền thông
tĩnh hay không. Các yêu cầu tĩnh mô tả các tùy chọn, phạm vi giá trị
cho các tham số và bộ định thời.
Phương pháp phân vùng danh mục (CPM) Phương pháp
luận dựa trên đặc điểm kỹ thuật có hệ thống sử dụng một đặc tả chức
năng không chính thức để tạo ra đặc tả kiểm tra chính thức.
Phân tích nguyên nhân Là loại phân tích được tiến hành để xác
định nguyên nhân gốc rễ của một khiếm khuyết và bắt đầu các hành
động để loại bỏ nguồn gốc của khiếm khuyết.
Yêu cầu thay đổi (CR) Yêu cầu chính thức của người đánh giá
mã để thực hiện thay đổi đối với mã.
tự đặc trưng Các trình tự của bộ W của FSM được gọi là trình
tự đặc trưng của FSM.
Biểu mẫu yêu cầu đăng ký Đối với mỗi bản sửa lỗi được kiểm tra
trong một bản dựng, một biểu mẫu yêu cầu đăng ký được điền bởi
các nhà phát triển phần mềm và được nhóm kỹ sư xây dựng xem xét.
quy trình phòng sạch được IBM giới thiệu vào cuối những
năm 1980. Quá trình bao gồm hai nhóm hợp tác - nhóm phát triển và
đảm bảo chất lượng - và năm hoạt động chính: đặc tả, lập kế hoạch,
thiết kế và xác minh, chứng nhận chất lượng và phản hồi. Các ý
tưởng sau đây hình thành nền tảng của quy trình phòng sạch: (i) phát
805
triển gia tăng theo kiểm soát chất lượng thống kê (SQC), (ii) phát
triển phần mềm dựa trên các nguyên tắc toán học và (iii) kiểm tra
phần mềm dựa trên các nguyên tắc thống kê.
Ranh giới đóng Một ranh giới bị đóng nếu các điểm dữ liệu
trên ranh giới là một phần của miền quan tâm.
Miền đóng Một miền có tất cả các ranh giới của nó bị đóng lại.
Lỗi đóng cửa Xảy ra nếu một đường biên bị đóng khi ý định là có
một đường biên mở hoặc ngược lại.
Thiệt hại tài sản thế chấp Điều gì xảy ra khi một tính năng mới
hoặc một sửa chữa khiếm khuyết trong một phần của hệ thống gây ra
một khiếm khuyết (thiệt hại) cho một phần khác, có thể không liên
quan của hệ thống.
thử kết hợp Phương pháp lựa chọn trường hợp thử nghiệm
trong đó các trường hợp thử nghiệm được xác định bằng cách kết
hợp các giá trị của một số tham số đầu vào thử nghiệm dựa trên một
số chiến lược tổ hợp.
Kiểm tra giao diện dòng lệnh Xác minh rằng hệ thống có thể
được cấu hình theo một cách cụ thể bằng cách sử dụng giao diện
dòng lệnh.
Các thành phần bán sẵn (COTS) thương mại Các thành phần
phần mềm được sản xuất bởi các tổ chức của nhà cung cấp bên thứ
ba có thể được sử dụng lại trong một hệ thống. Thông thường, các
loại thành phần này được phân phối mà không có mã nguồn của
chúng.
năng tương thích Xác minh rằng hệ thống có thể hoạt động theo
cùng một cách trên tất cả các nền tảng, hệ điều hành, hệ quản trị cơ
sở dữ liệu và hệ điều hành mạng.
Giả thuyết về lập trình viên có năng lực Giả định để phân
tích đột biến, trong đó nói rằng các lập trình viên nói chung là có
năng lực và họ không tạo ra các chương trình “ngẫu nhiên”.
Kiểm tra sự phù hợp Còn được gọi là kiểm tra sự phù hợp, quá
trình xác minh xem một sản phẩm có đáp ứng các thông số kỹ thuật
tiêu chuẩn của sản phẩm mà nó được thiết kế để đáp ứng hay không.
Lỗi tính toán Xảy ra khi dữ liệu đầu vào cụ thể khiến chương trình
thực thi đường dẫn đúng nhưng giá trị đầu ra lại sai.
Tính bảo mật Mã hóa dữ liệu của người gửi sao cho chỉ
người nhận dự kiến mới có thể giải mã dữ liệu đó.
Kiểm tra cấu hình Các hoạt động cấu hình lại trong quá trình
kiểm tra khả năng tương tác.
Kiểm tra sự phù hợp Quy trình xác minh xem một triển khai
có tuân theo đặc điểm kỹ thuật của nó hay không.
Biểu đồ luồng điều khiển (CFG) Biểu diễn bằng đồ thị luồng
điều khiển trong một đơn vị chương trình.
Kiến trúc phối hợp Phiên bản nâng cao của kiến trúc phân tán,
trong đó người kiểm tra cấp trên và cấp dưới được điều phối bởi một
giao thức quản lý kiểm tra.
Hiệu ứng ghép nối Giả định cho phân tích đột biến nói rằng nếu
một bộ thử nghiệm có thể bộc lộ những khiếm khuyết đơn giản trong
một chương trình, thì nó cũng có thể bộc lộ những tổ hợp lỗi đơn
giản phức tạp hơn.
Nhóm chức năng chéo Trong một tổ chức, tập hợp các nhóm
có cổ phần khác nhau trong một sản phẩm. Ví dụ: nhóm tiếp thị,
nhóm hỗ trợ khách hàng, nhóm phát triển, nhóm thử nghiệm hệ
thống, nhóm phát triển và nhóm duy trì sản phẩm được gọi chung là
nhóm đa chức năng trong một tổ chức.
Độ phức tạp theo chu kỳ (độ phức tạp của McCabe) Dựa trên
khái niệm lý thuyết đồ thị và được gọi là số tuần hoàn, đại diện cho
độ phức tạp của một mô-đun phần mềm.
Tiêu chí chấp nhận chuyển đổi dữ liệu Được sử dụng để đo
lường và báo cáo khả năng của phần mềm để chuyển đổi dữ liệu ứng
dụng hiện có sang các định dạng mới.
Sự bất thường của luồng dữ liệu Chuỗi các hành động “bất
thường” trên một biến dữ liệu, ví dụ: hai lần gán giá trị liên tiếp cho
một biến dữ liệu hoặc tham chiếu đến một biến không xác định.
Biểu đồ luồng dữ liệu (DFG) Biểu diễn bằng đồ thị của một
chương trình, trong đó các nút đại diện cho các phép tính và các
nhánh đại diện cho các vị từ, nghĩa là, điều kiện.
Gỡ lỗi Quy trình xác định nguyên nhân của lỗi và sửa chữa nó; xảy
ra như một hệ quả của một bài kiểm tra phát hiện ra một khiếm
khuyết.
Bảng quyết định Bao gồm một tập hợp các điều kiện và một tập
hợp các hiệu ứng. Đối với mỗi kết hợp các điều kiện, một quy tắc tồn
tại. Mỗi quy tắc bao gồm phản hồi Y (có), N (không) hoặc— (không
807
quan tâm) và chứa danh sách các hiệu ứng hoặc kết quả mong đợi
được liên kết.
khiếm khuyết trong phần mềm có khả năng gây ra lỗi.
Tuổi khuyết tật Khoảng thời gian từ khi phát hiện ra khuyết tật.
Mật độ khuyết tật Số khuyết tật trên một nghìn dòng mã.
ngừa lỗi Các biện pháp ngăn ngừa có thể được thực hiện trong
quá trình phát triển mã để giảm các lỗi trong chương trình.
Mức độ ưu tiên của khuyết tật Đo lường mức độ sớm nhất của
khuyết tật cần được sửa chữa.
Hiệu quả loại bỏ khuyết tật (DRE) Tỷ lệ giữa số khuyết tật được
phát hiện trong một hoạt động với số khuyết tật lẽ ra phải được tìm
thấy.
Mức độ nghiêm trọng của khuyết tật Đo lường mức độ ảnh
hưởng bất lợi mà một khuyết tật có thể gây ra đối với hoạt động của
sản phẩm.
Định nghĩa một biến Một biến được cho là được xác định
nếu vị trí bộ nhớ của biến đó nhận một giá trị một cách rõ ràng.
Kiểm tra nút xuống cấp Xác minh hoạt động của hệ thống sau khi
một phần của hệ thống trở nên không hoạt động.
Tấn công từ chối dịch vụ (DoS) Làm ngập một hệ thống thông
tin, chẳng hạn như máy chủ, với một số lượng lớn các yêu cầu dịch
vụ đến mức hệ thống thông tin không thể đáp ứng.
Kiểm tra xác minh thiết kế (DVT) Do nhóm phần cứng viết và
thực hiện trước khi tích hợp phần cứng với hệ thống phần mềm. Các
loại DVT là chẩn đoán, phóng tĩnh điện, phát xạ điện từ, điện, nhiệt,
môi trường, âm học, đóng gói thiết bị, an toàn và độ tin cậy.
Máy trạng thái hữu hạn xác định FSM sao cho đầu ra và trạng
thái tiếp theo của nó là một hàm của trạng thái hiện tại và đầu vào
được áp dụng.
Thiết bị đang thử nghiệm (DUT) Sản phẩm được sản xuất đang
tra chẩn đoán Xác minh rằng các thành phần phần cứng của
hệ thống đang hoạt động như mong muốn. Ví dụ như tự kiểm tra khi
bật nguồn, kiểm tra vòng lặp lại Ethernet và kiểm tra lỗi bit.
Chữ ký điện tử Thông báo tin nhắn được mã hóa được nối vào tin
nhắn. Việc tạo ra một chữ ký số liên quan đến mã hóa khóa công
khai và một thuật toán hàm băm.
Phân biệt trình tự Trình tự đầu vào tạo ra một trình tự đầu ra duy
nhất cho một trạng thái khi trình tự đầu vào được áp dụng cho FSM
bắt đầu ở trạng thái nhất định.
Kiến trúc phân tán Kiểm tra kiến trúc trong đó có một PCO ở
ranh giới dịch vụ trên và một PCO khác ở ranh giới dịch vụ thấp hơn.
PCO ở ranh giới dịch vụ thấp hơn nằm ở đầu từ xa của N - 1 nhà
cung cấp dịch vụ để điều khiển gián tiếp và quan sát N ASP và N
PDU. Điều này cho phép người kiểm tra cấp trên và cấp dưới cư trú
ở các vị trí riêng biệt về mặt vật lý.
Lỗi miền Xảy ra khi dữ liệu đầu vào cụ thể khiến chương trình
thực thi sai đường dẫn trong chương trình.
Kiểm thử đơn vị động Phương pháp kiểm tra dựa trên thực thi
trong đó một đơn vị chương trình thực sự được thực thi và kết quả
của nó được quan sát.
hệ thống quản lý phần tử (EMS) Xác minh chức năng của EMS,
chẳng hạn như giám sát và quản lý các phần tử mạng.
Trình giả lập Trình giả lập phần mềm cho phép các chương trình
máy tính chạy trên một nền tảng (kiến trúc máy tính và / hoặc hệ điều
hành) khác với nền tảng mà chương trình được viết ban đầu. Không
giống như mô phỏng, chỉ cố gắng tái tạo hành vi của một chương
trình, một trình giả lập cố gắng mô phỏng, ở nhiều mức độ khác
nhau, các trạng thái của thiết bị được mô phỏng.
Mã hóa Kỹ thuật mật mã được sử dụng để cung cấp tính bảo mật.
Tài liệu về thay đổi kỹ thuật (EC) Cung cấp mô tả ngắn gọn về
các vấn đề và mô tả những thay đổi nào cần thực hiện đối với yêu
cầu ban đầu.
Lệnh thay đổi kỹ thuật (ECO) Tài liệu chính thức mô tả một
thay đổi đối với phần cứng hoặc phần mềm sẽ được giao cho khách
hàng. Tài liệu này bao gồm ma trận khả năng tương thích phần
cứng / phần mềm và được phân phối cho bộ phận vận hành, bộ phận
hỗ trợ khách hàng và các nhóm bán hàng của tổ chức.
Tiêu chí đầu vào Các tiêu chí phải đáp ứng trước khi bắt đầu giai
đoạn thử nghiệm.
Lỗi Khi một sự kiện kích hoạt một lỗi trong chương trình, trước
tiên nó đưa chương trình vào trạng thái không ổn định trung gian,
được gọi là lỗi, nếu và khi nó truyền đến đầu ra, cuối cùng sẽ gây ra
lỗi hệ thống.
809
Phỏng đoán lỗi Kỹ thuật thiết kế kiểm tra trong đó kinh
nghiệm của người kiểm tra được sử dụng để (i) đoán các loại lỗi và
vị trí có thể xảy ra của lỗi trong hệ thống và (ii) thiết kế kiểm tra cụ
thể để phơi bày chúng. Việc thiết kế các trường hợp thử nghiệm bằng
kỹ thuật đoán lỗi chủ yếu dựa trên kinh nghiệm của người thử
nghiệm với mã tương tự như việc triển khai đang thử nghiệm.
Tạo hạt giống lỗi Quá trình cố ý bổ sung các lỗi đã biết trong
chương trình máy tính nhằm mục đích ước tính số lượng lỗi còn lại
trong chương trình trong quá trình kiểm tra và loại bỏ lỗi.
Phân vùng lớp tương đương Chia miền đầu vào của hệ thống
đang được kiểm thử thành các lớp (hoặc nhóm) các trường hợp kiểm
thử có ảnh hưởng tương tự đến hệ thống.
biến đột biến tương đương Không phân biệt được với chương trình
đang thử nghiệm.
Nhìn chung, việc xác định liệu một đột biến có tương đương với một
chương trình hay không là điều không thể quyết định.
chí thoát Tiêu chí xác định các điều kiện phải được đáp ứng
trước khi hoàn thành giai đoạn thử nghiệm.
Máy trạng thái hữu hạn mở rộng Mở rộng máy trạng thái
hữu hạn (FSM). EFSM có khả năng thực hiện các phép tính
bổ sung như cập nhật giá trị của các biến, thao tác bộ định thời và
đưa ra quyết định. Ngôn ngữ Đặc tả và Mô tả (SDL) cung cấp một
khuôn khổ để chỉ định một hệ thống là một hoặc nhiều EFSM.
Giao thức xác thực mở rộng (EAP) Giao thức xác thực được
mô tả trong Yêu cầu nhận xét (RFC) 2284. Đối với mạng LAN
không dây, EAP được gọi là EAP qua mạng LAN (EAPOL).
Điểm cực trị Điểm là một điểm mà hai hoặc nhiều ranh giới giao
nhau.
Lập trình cực đoan (XP) Phương pháp luận phát triển phần mềm
tự thích ứng và hướng vào con người. XP bắt đầu với năm giá trị:
giao tiếp, phản hồi, đơn giản, dũng cảm và tôn trọng. Sau đó, nó xây
dựng 12 quy tắc / khuyến nghị mà các dự án XP nên tuân theo.
Thất bại Biểu hiện không có khả năng của một chương trình để
thực hiện chức năng cần thiết của nó. Nói cách khác, đó là sự cố hệ
thống được chứng minh bằng đầu ra không chính xác, kết thúc bất
thường hoặc các hạn chế về thời gian và không gian không được đáp
ứng.
Cường độ hỏng hóc Được biểu thị bằng số lượng lỗi quan sát
được trên một đơn vị thời gian.
Tiêu cực giả Xảy ra khi một cuộc tấn công tiềm năng hoặc thực sự
bị bỏ sót bởi một hệ thống phát hiện xâm nhập. Sự xuất hiện của kịch
bản này càng nhiều, thì càng có nhiều nghi ngờ về trách nhiệm giải
trình của hệ thống phát hiện xâm nhập và công nghệ của nó.
Dương tính giả Thường được gọi là báo động giả, xảy ra khi
hệ thống phát hiện xâm nhập đọc hoạt động hợp pháp là một cuộc tấn
công.
Lỗi Nguyên nhân của lỗi. Ví dụ, một đoạn mã bị thiếu hoặc
không chính xác là một lỗi. Một lỗi có thể vẫn không được phát hiện
trong một thời gian dài cho đến khi một số sự kiện kích hoạt nó.
tra dựa trên lỗi Kỹ thuật kiểm tra được sử dụng để chỉ ra rằng
một loại lỗi cụ thể không nằm trong một chương trình. Các trường
hợp kiểm tra nhằm mục đích tiết lộ các loại lỗi cụ thể được xác định
trước, ví dụ, đoán lỗi, gieo hạt lỗi hoặc kiểm tra đột biến.
Tạo lỗi (lỗi) Quá trình cố ý thêm các lỗi đã biết vào chương trình
máy tính nhằm mục đích theo dõi tốc độ phát hiện và loại bỏ lỗi và
ước tính số lỗi còn lại trong chương trình. Cũng được sử dụng để
đánh giá tính đầy đủ của các thử nghiệm.
Chèn lỗi Phương pháp đưa lỗi vào chương trình. Một tiên tri
hoặc một thông số kỹ thuật có sẵn để khẳng định rằng những gì được
chèn vào đã làm cho chương trình không chính xác.
Mô phỏng lỗi Quá trình chèn lỗi trong chương trình. Các lỗi đã chèn
không được đảm bảo sẽ làm cho chương trình không chính xác.
Trong mô phỏng lỗi, người ta có thể sửa đổi một câu lệnh không
chính xác của một chương trình và biến nó thành một chương trình
đúng.
dẫn khả thi Đường dẫn trong đó tồn tại một đầu vào để khiến
đường dẫn thực thi.
Tính năng Tập hợp các yêu cầu liên quan.
khách hàng đầu tiên (FCS) Bản xây dựng phần mềm mới được
phát hành cho khách hàng trả tiền đầu tiên.
Máy tính trạng thái hữu hạn (FSM) Tự động hóa dữ liệu với
một số trạng thái hữu hạn. Các tự động thay đổi trạng thái của nó khi
một kích thích bên ngoài được áp dụng. Trạng thái của FSM được
định nghĩa là một điều kiện ổn định trong đó FSM nghỉ cho đến khi
811
một kích thích bên ngoài, được gọi là đầu vào, được áp dụng. Một
đầu vào làm cho FSM tạo ra một đầu ra có thể quan sát được và trải
qua quá trình chuyển đổi trạng thái từ trạng thái hiện tại sang trạng
thái mới mà nó vẫn ở đó cho đến khi đầu vào tiếp theo xảy ra.
Frame relay (FR) Kỹ thuật truyền dữ liệu lớp vật lý để di chuyển
khung dữ liệu từ máy tính / bộ định tuyến này sang máy tính / bộ
định tuyến khác.
toàn bộ Được sử dụng để kiểm tra trạng thái và bất kỳ thay đổi cấu
hình nào của các nút được quản lý bởi máy chủ EMS.
Tài liệu đặc tả chức năng Tài liệu yêu cầu do nhà phát triển phần
mềm tạo ra để thể hiện nhu cầu của khách hàng.
thử chức năng Kiểm thử trong đó một chương trình P được
xem như là một hàm biến đổi vectơ đầu vào X i thành một vectơ đầu
ra Y i sao cho Y i = P (X i ). Hai khái niệm chính trong kiểm thử chức
năng như sau: (i) xác định chính xác miền của mỗi biến đầu vào và
đầu ra và (ii) chọn các giá trị từ miền dữ liệu có các thuộc tính quan
trọng.
Điểm chức năng (FP) Đơn vị đo lường để thể hiện số lượng
chức năng nghiệp vụ mà hệ thống thông tin cung cấp cho người
dùng. Các điểm chức năng được định nghĩa vào năm 1977 bởi Alan
Albrecht tại IBM.
Biểu đồ Gantt Biểu đồ thanh phổ biến để thể hiện lịch trình dự
án.
oracle tiêu chuẩn vàng trong đó phiên bản trước của hệ thống
ứng dụng hiện có được sử dụng để tạo ra kết quả mong đợi.
Kiểm tra giao diện người dùng đồ họa Xác minh giao diện
trông của hệ thống ứng dụng.
Handoff để chuyển việc xử lý cuộc gọi từ một trạm gốc sang
một trạm gốc khác.
Hàm băm Thuật toán nhận một thông điệp đầu vào có độ dài tùy
ý và tạo ra một mã có độ dài cố định. Đầu ra có độ dài cố định được
gọi là hàm băm, hoặc bản tóm tắt thông báo, của thông báo đầu vào
ban đầu.
Nguy hiểm của một hệ thống hoặc một tình huống vật lý, khi kết
hợp với các điều kiện môi trường nhất định, có thể dẫn đến tai nạn
hoặc hoạt động sai. Nguy hiểm là điều kiện tiên quyết dẫn đến tai
nạn.
tra tính khả dụng cao Xác minh tính dự phòng của các mô-
đun phần cứng và phần mềm riêng lẻ. Mục đích ở đây là xác minh
rằng hệ thống phục hồi một cách duyên dáng và nhanh chóng từ lỗi
phần cứng và phần mềm mà không ảnh hưởng đến hoạt động của hệ
thống. Nó còn được gọi là khả năng chịu lỗi.
Tài liệu thiết kế cấp cao Mô tả kiến trúc hệ thống tổng thể.
Phép thử lý tưởng Nếu chúng ta có thể kết luận, từ việc thực hiện
thành công một mẫu miền đầu vào, rằng không có lỗi nào trong
chương trình, thì mẫu đầu vào tạo thành một phép thử lý tưởng.
Thực hiện theo thử nghiệm (IUT) Chủ đề thực hiện cho các thử
nghiệm. IUT có thể là một hệ thống hoàn chỉnh hoặc một thành phần
của nó.
Hành động không phù hợp Tính giá trị sai cách, không thể gán giá
trị cho một biến hoặc gọi một thủ tục với danh sách đối số sai.
Lựa chọn đường dẫn không phù hợp Nếu có sự kết hợp bị lỗi
giữa một điều kiện chương trình và một đường dẫn, thì một đường
dẫn sai được chọn và điều này được gọi là lựa chọn đường dẫn không
phù hợp.
Đường dẫn khả thi Đường dẫn chương trình không bao giờ có
thể được thực thi.
Yêu cầu suy ra Bất cứ điều gì mà một hệ thống được mong đợi
để thực hiện nhưng không được nêu rõ ràng trong đặc tả.
Thử nghiệm theo thứ tự tham số (IPO) Kỹ thuật thử nghiệm kết
hợp để tạo ra các trường hợp thử nghiệm đáp ứng phạm vi bảo hiểm
theo từng cặp.
Các số liệu trong quá trình Theo dõi tiến độ của dự án và sử dụng
các số liệu này để định hướng tiến trình của dự án.
Vectơ đầu vào Tập hợp tất cả các thực thể dữ liệu được đọc
bởi một chương trình có các giá trị phải được cố định trước khi nhập
đơn vị.
Kiểm tra Đánh giá nhóm đồng nghiệp từng bước của một sản
phẩm làm việc, với mỗi bước được kiểm tra dựa trên các tiêu chí đã
định trước.
Kiểm tra khả năng cài đặt Đảm bảo rằng hệ thống có thể được cài
đặt chính xác trong môi trường khách hàng.
Kiểm tra tính toàn vẹn Xác minh xem dữ liệu có bị sửa đổi
trong quá trình vận chuyển hay không.
813
Giao thức Internet (IP) Giao thức định tuyến được sử dụng để
di chuyển dữ liệu qua mạng internet chuyển mạch gói. IP là một giao
thức lớp mạng trong bộ giao thức Internet.
Internet Protocol Security (IPSec) Giao thức bảo mật lớp mạng
cung cấp các tính năng bảo mật, bao gồm bảo mật, xác thực, toàn vẹn
dữ liệu và bảo vệ chống lại các cuộc tấn công phát lại dữ liệu.
Kiểm tra khả năng tương tác Xác minh rằng hệ thống có thể
tương tác với các sản phẩm của bên thứ ba.
Kiểm tra giữa các hệ thống Kiểm tra tích hợp trong đó tất cả
các hệ thống được kết nối với nhau và các bài kiểm tra được thực
hiện từ đầu đến cuối.
Kiểm thử giữa các hệ thống Kiểm thử tích hợp mức độ thấp với
mục tiêu kết hợp các mô-đun lại với nhau để xây dựng một hệ thống
gắn kết. Kiểm thử nội bộ yêu cầu kết hợp các mô-đun với nhau trong
một hệ thống.
Biểu đồ Ishikawa Còn được gọi là biểu đồ xương cá hoặc biểu
đồ nguyên nhân và kết quả, cho thấy nguyên nhân của một sự kiện
nhất định. Nó được Kaoru Ishikawa sử dụng lần đầu tiên vào những
năm 1960 và được coi là một trong bảy công cụ cơ bản của quản lý
chất lượng: biểu đồ, biểu đồ Pareto, bảng kiểm, biểu đồ kiểm soát,
biểu đồ nguyên nhân và kết quả, lưu đồ và biểu đồ phân tán.
JUnit Khung kiểm thử tự động được sử dụng bởi các nhà phát triển
thực hiện các đơn vị chương trình và kiểm thử đơn vị bằng ngôn ngữ
lập trình Java.
Lĩnh vực quy trình chính (KPA) Cấp độ trưởng thành của CMM
chứa các lĩnh vực quy trình chính. KPA được mong đợi để đạt được
mục tiêu và được tổ chức theo các đặc điểm chung.
Lean được sử dụng để tăng tốc và giảm chi phí của quy trình sản
xuất bằng cách loại bỏ chất thải. Nguyên tắc loại bỏ lãng phí đã được
vay mượn từ ý tưởng của Taiichi Ohno - cha đẻ của Hệ thống sản
xuất Toyota. Phương pháp luận phát triển tinh gọn được tóm tắt bởi
bảy nguyên tắc sau: loại bỏ lãng phí, tăng cường học hỏi, quyết định
càng muộn càng tốt, phân phối nhanh nhất có thể, trao quyền cho
nhóm, xây dựng tính chính trực và nhìn thấy tổng thể. Quy trình tinh
gọn là bản dịch của các nguyên tắc và thực hành sản xuất tinh gọn
sang lĩnh vực phát triển phần mềm.
điốt phát sáng (LED) Xác minh hoạt động của trạng thái đèn
báo LED. Các thử nghiệm LED được thiết kế để đảm bảo rằng trạng
thái hoạt động trực quan của hệ thống và các mô-đun con là chính
xác.
Giao thức truy cập thư mục nhẹ (LDAP) Giao thức bắt nguồn từ
tiêu chuẩn X.500 và được định nghĩa trong Yêu cầu nhận xét (RFC)
2251. LDAP tương tự như cơ sở dữ liệu nhưng có thể chứa nhiều
thông tin mô tả hơn. LDAP được thiết kế để cung cấp phản hồi nhanh
chóng cho các tra cứu khối lượng lớn.
Giao thức xác thực mở rộng nhẹ (LEAP) Cisco-wireless EAP
cung cấp xác thực dựa trên tên người dùng / mật khẩu giữa máy
khách không dây và máy chủ kiểm soát truy cập.
Kiểm tra khả năng mở rộng và tải Thực hành hệ thống với nhiều
người dùng thực hoặc ảo và xác minh xem nó có hoạt động chính xác
trong các mức, mẫu và kết hợp lưu lượng đã được kiểm tra hay
không.
Kiến trúc cục bộ Kiểm tra kiến trúc trong đó PCO được xác
định ở ranh giới dịch vụ trên và dưới của IUT.
Kiểm tra ghi nhật ký và truy tìm Xác minh cấu hình và hoạt
động của các chức năng ghi nhật ký và truy tìm.
Lỗi logic Khi một chương trình tạo ra kết quả không chính xác
không phụ thuộc vào tài nguyên được yêu cầu, lỗi được gây ra do
thiếu sót cố hữu trong chương trình chứ không phải do thiếu tài
nguyên. Những khiếm khuyết ở dạng lỗi yêu cầu, lỗi thiết kế và lỗi
xây dựng.
thử nghiệm thấp hơn Thực thể người kiểm tra chịu trách
nhiệm về việc kiểm soát và quan sát tại PCO thích hợp bên dưới IUT
hoặc tại một địa điểm từ xa.
Tài liệu thiết kế cấp thấp Đặc tả chi tiết của các mô-đun phần
mềm trong kiến trúc.
trì Khả năng bảo trì của một hệ thống để trải qua quá trình sửa
chữa và phát triển.
Cơ sở thông tin quản lý (MIB) Cơ sở dữ liệu được sử dụng để
quản lý các thiết bị trong mạng truyền thông.
Quan điểm sản xuất về chất lượng Chất lượng được coi là sự phù
hợp với các yêu cầu. Khái niệm về quá trình đóng một vai trò quan
trọng trong quan điểm sản xuất.
815
Tiếp thị beta Thử nghiệm beta giúp xây dựng nhận thức sớm và
quan tâm đến sản phẩm của những người mua tiềm năng.
Thời gian trung bình giữa hai lần hỏng hóc (MTBF) Thời gian
mong đợi giữa hai lần hỏng hóc liên tiếp của một hệ thống. Về mặt
kỹ thuật, MTBF chỉ nên được sử dụng cho các hạng mục có thể sửa
chữa được, trong khi MTTF nên được sử dụng cho các hạng mục
không thể sửa chữa. Tuy nhiên, MTBF thường được sử dụng cho cả
mặt hàng có thể sửa chữa và không thể sửa chữa.
Thời gian trung bình để hỏng (MTTF) Thời gian trung bình dự
kiến cho đến khi hỏng hóc đầu tiên của một thiết bị. MTTF là một
giá trị thống kê và có nghĩa là giá trị trung bình trong một khoảng
thời gian dài và một số lượng lớn các đơn vị. MTTF là một thước đo
cơ bản về độ tin cậy cho các hệ thống không thể sửa chữa.
Thời gian trung bình để sửa chữa (MTTR) Khoảng thời
gian từ khi một cái gì đó bị hỏng đến khi nó đã được sửa chữa và
hoạt động lại hoàn toàn. MTTR thể hiện lượng thời gian thiết bị
không thể cung cấp dịch vụ.
Cột mốc Điểm kiểm tra chính, hoặc một mục tiêu phụ, được
xác định trong lịch trình thử nghiệm hoặc dự án.
Mishap Còn được gọi là một tai nạn, một sự kiện ngoài ý
muốn dẫn đến tử vong, thương tật, bệnh tật, thiệt hại hoặc mất mát
tài sản, hoặc gây hại cho môi trường.
Thiếu các đường dẫn luồng điều khiển Không có mã nào để xử
lý một điều kiện nhất định. Điều này xảy ra khi chúng tôi không xác
định được điều kiện và do đó, không xác định được một phép tính
dưới dạng một đường dẫn.
Kiểm tra mô-đun Xác minh rằng tất cả các mô-đun hoạt động
riêng lẻ như mong muốn trong hệ thống. Mục đích ở đây là xác minh
rằng hệ thống cùng với phần mềm điều khiển các mô-đun này hoạt
động như được chỉ định trong đặc tả yêu cầu.
Phân tích đột biến Liên quan đến sự đột biến của mã nguồn bằng
cách giới thiệu các câu lệnh hoặc sửa đổi các câu lệnh hiện có theo
những cách nhỏ. Ý tưởng là giúp người thử nghiệm phát triển các thử
nghiệm hiệu quả hoặc xác định các điểm yếu trong dữ liệu thử
nghiệm hoặc trong mã hiếm khi hoặc không bao giờ được truy cập
trong quá trình thực thi.
Phần tử mạng Nút mạng nằm trên mạng được quản lý và chạy tác
nhân SNMP.
Trạm quản lý mạng Thực thi các ứng dụng quản lý giám sát và
điều khiển các phần tử mạng.
Công nghệ mới Trình quản lý mạng LAN (NTLM) Giao
thức xác thực được sử dụng trong các triển khai giao thức mạng khác
nhau của Microsoft. NTLM sử dụng cơ chế phản hồi thử thách để
xác thực trong đó khách hàng có thể chứng minh danh tính của họ mà
không cần gửi mật khẩu đến máy chủ.
Máy trạng thái hữu hạn không xác định FSM trong đó hàm trạng
thái tiếp theo không chỉ được xác định bởi trạng thái hiện tại và đầu
vào của nó. Một sự kiện nội bộ cũng có thể gây ra chuyển đổi trạng
thái. Ngoài ra, với một đầu vào bên ngoài ở một số trạng thái, trạng
thái tiếp theo của FSM không thể được xác định duy nhất.
Điểm tắt Cho một ranh giới, một điểm tắt là một điểm cách xa
ranh giới. Người ta phải xem xét một lĩnh vực quan tâm và mối quan
hệ của nó với ranh giới trong khi xác định một điểm lệch.
Kiểm tra chèn và tháo trực tuyến Xác minh tính dự phòng của
từng mô-đun bao gồm cả phần mềm điều khiển các mô-đun này.
Trên điểm Cho một biên miền, một điểm trên là một điểm trên
biên hoặc rất gần biên nhưng vẫn thỏa mãn bất đẳng thức biên.
Ranh giới mở Ranh giới với các điểm dữ liệu không phải là một
phần của miền quan tâm.
mở Miền với tất cả các ranh giới của nó mở đối với miền.
Hồ sơ hoạt động Tập hợp các hoạt động được hỗ trợ bởi một hệ
thống và xác suất xảy ra của chúng. Một hồ sơ hoạt động được tổ
chức dưới dạng cấu trúc cây, trong đó mỗi cung được gắn nhãn một
hành động và xác suất xuất hiện của nó.
Oracle xác minh tính đúng đắn của kết quả đầu ra chương
trình. Một tiên tri có thể là một đặc tả, một chuyên gia, một phần dữ
liệu hoặc một chương trình khác.
sản xuất thiết bị gốc (OEM) sản xuất các sản phẩm hoặc
thành phần được sử dụng trong các sản phẩm khác do một công ty
khác bán, thường được gọi là đại lý giá trị gia tăng hoặc VAR. OEM
thường xây dựng một sản phẩm theo đơn đặt hàng dựa trên các thiết
kế của VAR. Ví dụ, ổ cứng trong hệ thống máy tính có thể được sản
817
xuất bởi một công ty tách biệt với công ty lắp ráp và tiếp thị máy
tính.
Kiểm thử mảng trực giao (OA) Kỹ thuật kiểm tra kết hợp để
chọn một tập hợp các trường hợp kiểm thử từ một loạt các bài kiểm
tra và làm cho việc kiểm tra trở nên hiệu quả và hiệu quả. Kiểm tra
OA dựa trên một ma trận đặc biệt được gọi là hình vuông la tinh,
trong đó ký hiệu giống nhau xuất hiện chính xác một lần trong mỗi
hàng và cột.
Sơ đồ phân loại lỗi trực giao (ODC) để phân loại lỗi phần
mềm và hướng dẫn phân tích dữ liệu lỗi tổng hợp đã phân loại.
Nút phục vụ dữ liệu gói (PDSN) Cung cấp quyền truy cập vào
Internet, mạng nội bộ và máy chủ ứng dụng cho các trạm di động sử
dụng mạng truy cập vô tuyến CDMA2000 (RAN). Hoạt động như
một cổng truy cập, một thực thể PDSN cung cấp khả năng truy cập
IP di động và IP đơn giản, hỗ trợ tác nhân nước ngoài và vận chuyển
gói cho mạng riêng ảo. Nó hoạt động như một máy khách cho một
máy chủ xác thực, ủy quyền và kế toán (AAA) và cung cấp cho các
trạm di động một cổng vào mạng IP.
Bao phủ theo cặp Yêu cầu rằng, đối với một số lượng tham số
đầu vào nhất định cho hệ thống, mỗi tổ hợp giá trị có thể có cho bất
kỳ cặp tham số nào phải được bao phủ bởi ít nhất một trường hợp thử
nghiệm. Đó là một trường hợp đặc biệt của thử nghiệm tổ hợp.
cặp Kỹ thuật thử nghiệm tích hợp trong đó chỉ có hai hệ thống
được kết nối với nhau được thử nghiệm trong một hệ thống tổng thể.
Mục đích của thử nghiệm theo cặp là để đảm bảo rằng hai hệ thống
đang được xem xét có thể hoạt động cùng nhau, giả định rằng các hệ
thống khác trong môi trường tổng thể hoạt động như mong đợi.
Lược đồ oracle tham số trong đó một thuật toán được sử dụng
để trích xuất một số tham số từ các đầu ra thực tế và so sánh chúng
với các giá trị tham số mong đợi.
Nguyên tắc Pareto cho rằng 80% vấn đề có thể được khắc phục
với 20% toàn bộ nỗ lực. Nó còn được gọi là quy tắc 80–20.
thử phân vùng Kỹ thuật kiểm tra trong đó miền đầu vào của
chương trình được chia thành các miền phụ không trùng lặp; tiếp
theo, một đầu vào thử nghiệm được chọn từ mỗi miền phụ. Giả định
cơ bản là tất cả các phần tử bên trong một miền phụ về cơ bản khiến
hệ thống hoạt động theo cùng một cách và bất kỳ phần tử nào của
một miền phụ sẽ gây ra lỗi trong chương trình như bất kỳ phần tử nào
khác trong cùng một miền.
Đường dẫn Chuỗi các câu lệnh trong một chương trình hoặc một
đơn vị chương trình. Về mặt cấu trúc, một đường dẫn là một chuỗi
các câu lệnh từ nút ban đầu của CFG đến một trong các nút kết thúc.
Vị từ đường dẫn Tập hợp các vị từ được liên kết với một đường
dẫn.
Biểu thức vị từ đường dẫn Vị ngữ đường dẫn được thông dịch.
tiên tri hoàn hảo trong đó hệ thống (IUT) được kiểm tra song
song với một hệ thống đáng tin cậy chấp nhận mọi đầu vào được chỉ
định cho IUT và “luôn luôn” tạo ra kết quả chính xác.
Lỗi hiệu suất Làm cho chương trình không thể tạo ra đầu ra mong
muốn trong giới hạn tài nguyên đã chỉ định.
Kiểm tra hiệu suất Xác định hiệu suất hệ thống thực tế như thế
nào so với hiệu suất hệ thống được dự đoán. Các bài kiểm tra được
thiết kế để xác minh thời gian phản hồi, thời gian thực thi, thông
lượng, sử dụng tài nguyên và tốc độ lưu lượng.
Ping Công cụ mạng máy tính được sử dụng để kiểm tra xem một
máy chủ cụ thể có thể truy cập được qua mạng IP hay không. Ping
hoạt động bằng cách gửi các gói “yêu cầu tiếng vang” ICMP đến
máy chủ đích và lắng nghe các câu trả lời “phản hồi tiếng vang” của
ICMP. Sử dụng định thời khoảng thời gian và tốc độ phản hồi, ping
ước tính thời gian khứ hồi và tỷ lệ mất gói giữa các máy chủ.
Điểm kiểm soát và quan sát (PCO) Điểm tương tác được
chỉ định tốt giữa hệ thống và người dùng của nó.
Giao thức điểm-điểm (PPP) Giao thức liên kết dữ liệu
thường được sử dụng để thiết lập kết nối trực tiếp giữa hai nút qua
cáp nối tiếp, đường dây điện thoại, đường trung kế và điện thoại di
động.
Kiểm tra chu trình chạy điện Xác minh rằng hệ thống khởi
động liên tục và hoạt động sau một chu kỳ cấp điện.
Sức mạnh của các phương pháp thử Được sử dụng để so
sánh các phương pháp thử. Khái niệm về ít nhất là tốt là một ví dụ về
việc so sánh sức mạnh của các phương pháp thử nghiệm. Phương
pháp thử nghiệm M ít nhất cũng tốt như phương pháp thử nghiệm N
nếu, bất cứ khi nào N phát hiện ra lỗi trong chương trình P bằng cách
819
tạo ra một thử nghiệm, thì phương pháp M phát hiện ra lỗi tương tự
bằng cách tạo ra cùng một thử nghiệm hoặc một thử nghiệm khác.
Tự kiểm tra khi bật nguồn (POST) Xác định xem các thành
phần phần cứng có ở trạng thái thích hợp để chạy phần mềm hay
không.
Dự đoán Chức năng lôgic được đánh giá tại một điểm quyết
định.
Xác định phạm vi bao phủ Khám phá tất cả các kết hợp có thể có
của các giá trị chân lý của các điều kiện ảnh hưởng đến một con
đường đã chọn cho tất cả các con đường.
Giải nghĩa vị từ Các phép toán thay thế một cách tượng trưng dọc
theo một đường dẫn để biểu thị các vị từ chỉ theo vectơ đầu vào và
một vectơ không đổi.
Quan điểm về chất lượng của sản phẩm Giả thuyết trung tâm
của quan điểm này là: nếu một sản phẩm được sản xuất ra với những
đặc tính bên trong tốt thì nó sẽ có những phẩm chất bên ngoài tốt.
Đột biến chương trình Thực hiện một thay đổi nhỏ đối với
một chương trình để có được một chương trình mới được gọi là đột
biến. Một đột biến có thể tương đương hoặc không tương đương với
chương trình gốc. Đột biến chương trình được sử dụng để đánh giá
tính đầy đủ của các bài kiểm tra.
Giao thức xác thực có thể mở rộng được bảo vệ (PEAP) Phương
pháp truyền thông tin xác thực một cách an toàn, bao gồm cả mật
khẩu, qua mạng không dây.
Đảm bảo chất lượng (QA) (i) Một mô hình có kế hoạch và có hệ
thống của tất cả các hành động cần thiết để cung cấp sự tin tưởng đầy
đủ rằng một mặt hàng hoặc sản phẩm phù hợp với các yêu cầu kỹ
thuật đã thiết lập và (ii) một tập hợp các hoạt động được thiết kế để
đánh giá quá trình mà sản phẩm được phát triển hoặc được sản xuất.
Vòng tròn chất lượng (QC) Nhóm công nhân tình nguyện, thường
là các thành viên trong cùng một bộ phận, gặp nhau thường xuyên để
thảo luận về các vấn đề và trình bày với cấp quản lý những ý tưởng
của họ để giải quyết vấn đề. Vòng tròn chất lượng được bắt đầu ở
Nhật Bản vào năm 1962 bởi Kaoru Ishikawa như một phương pháp
cải tiến chất lượng khác. Phong trào ở Nhật Bản được điều phối bởi
Liên minh các nhà khoa học và kỹ sư Nhật Bản (JUSE).
Kiểm soát chất lượng Tập hợp các hoạt động được thiết kế để
đánh giá chất lượng của các sản phẩm được phát triển hoặc sản xuất.
Tiêu chí chất lượng Thuộc tính của yếu tố chất lượng có liên quan
đến phát triển phần mềm. Ví dụ, mô đun là một thuộc tính của kiến
trúc của một hệ thống phần mềm.
Yếu tố chất lượng Đặc tính hành vi của một hệ thống. Một số ví
dụ về các yếu tố chất lượng cấp cao là tính đúng đắn, độ tin cậy, hiệu
quả, khả năng kiểm tra, tính di động và khả năng tái sử dụng.
Quản lý chất lượng Trọng tâm của nhóm quản lý chất lượng là
đảm bảo tuân thủ quy trình và tùy chỉnh các quy trình phát triển phần
mềm.
Chỉ số chất lượng Đo lường để nắm bắt một số khía cạnh của tiêu
chí chất lượng. Một hoặc nhiều chỉ số chất lượng được liên kết với
mỗi tiêu chí.
nhanh Được sử dụng để kiểm tra xem một phần tử mạng có
thể truy cập được hay không bằng cách thực hiện ping trên nút bằng
thao tác SNMP Get ().
Mạng truy nhập vô tuyến (RAN) Một phần của hệ thống viễn
thông di động. Nó thực hiện một công nghệ truy cập vô tuyến. Về
mặt khái niệm, nó nằm giữa điện thoại di động và mạng lõi (CN).
tra ngẫu nhiên Các đầu vào kiểm tra được chọn ngẫu nhiên từ
miền đầu vào của hệ thống.
Tham chiếu đến một biến Một biến được cho là được tham chiếu
nếu giá trị được giữ ở vị trí bộ nhớ của biến được tìm nạp.
Kiểm thử hồi quy Kiểm tra lại có chọn lọc một hệ thống hoặc một
thành phần để xác minh rằng các sửa đổi không gây ra các tác động
ngoài ý muốn và hệ thống hoặc thành phần đó vẫn tuân thủ các yêu
cầu cụ thể của nó.
quy định Đảm bảo rằng hệ thống đáp ứng các yêu cầu của các
cơ quan quản lý của chính phủ.
Ghi chú phát hành Tài liệu đi kèm với một bản dựng hoặc một
phần mềm đã phát hành. Ghi chú phát hành chứa các thông tin sau:
các thay đổi kể từ lần xây dựng hoặc phát hành cuối cùng, các lỗi đã
biết, các lỗi đã sửa và các tính năng được bổ sung.
Kiểm tra độ tin cậy Đo khả năng tiếp tục hoạt động của hệ thống
trong một khoảng thời gian dài.
821
Tiêu chí đáng tin cậy Một tiêu chí lựa chọn thử nghiệm là
đáng tin cậy nếu và chỉ khi tất cả các thử nghiệm được lựa chọn bởi
tiêu chí đều thành công hoặc không có thử nghiệm nào được lựa chọn
bởi tiêu chí là thành công.
trúc từ xa Kiến trúc trong đó IUT không có PCO ở ranh giới
dịch vụ trên và không có quyền truy cập trực tiếp đến ranh giới dịch
vụ dưới.
Dịch vụ người dùng quay số xác thực từ xa (RADIUS) giao thức
AAA cho các ứng dụng như truy cập mạng và di động IP.
Yêu cầu Mô tả nhu cầu hoặc mong muốn của người dùng mà
một hệ thống phải thực hiện.
lại Trình tự đầu vào đặt một triển khai về trạng thái ban đầu độc
lập với trạng thái mà thực thi đang ở trước khi trình tự đặt lại được áp
dụng.
phí làm lại Chi phí sửa chữa các khuyết tật đã biết.
Kiểm tra độ mạnh mẽ Xác minh mức độ mạnh mẽ của một hệ
thống, nghĩa là nó hoạt động một cách linh hoạt như thế nào trong
tình huống lỗi hoặc cách nó xử lý sự thay đổi trong trạng thái hoạt
động của nó.
Phân tích nguyên nhân gốc rễ (RCA) Lớp phương pháp giải
quyết vấn đề nhằm xác định nguyên nhân gốc rễ của vấn đề. Thực
hành RCA được dự đoán dựa trên niềm tin rằng các vấn đề được giải
quyết tốt nhất bằng cách cố gắng sửa chữa hoặc loại bỏ các nguyên
nhân gốc rễ, thay vì chỉ giải quyết các triệu chứng rõ ràng ngay lập
tức.
Đảm bảo an toàn Một chương trình đảm bảo an toàn được thiết
lập trong tổ chức để loại bỏ các mối nguy hiểm hoặc giảm các rủi ro
liên quan đến mức có thể chấp nhận được.
Hệ thống phần mềm quan trọng về an toàn Hệ thống phần
mềm có lỗi có thể gây ra thiệt hại về tính mạng.
Tích hợp bánh sandwich Kỹ thuật kiểm tra trong đó các mô-đun
phần mềm được tích hợp bằng cách sử dụng kết hợp các kỹ thuật từ
trên xuống và từ dưới lên.
Giàn giáo Các chương trình máy tính và tệp dữ liệu được xây
dựng để hỗ trợ phát triển và thử nghiệm phần mềm nhưng không
nhằm mục đích đưa vào sản phẩm cuối cùng. Mã giàn giáo mô phỏng
chức năng của các thành phần chưa tồn tại và cho phép chương trình
thực thi. Mã giàn giáo liên quan đến việc tạo các sơ khai và trình điều
khiển thử nghiệm.
Kiểm tra khả năng mở rộng Xác minh xem hệ thống có thể
mở rộng đến các giới hạn kỹ thuật của nó hay không.
Scrum để phát triển phần mềm. Phương pháp này được
Takeuchi và Nonaka mô tả lần đầu tiên trong “Trò chơi phát triển sản
phẩm mới” (Harvard Business Review, tháng Giêng / tháng Hai năm
1986). Đây là một quá trình lặp đi lặp lại, gia tăng để phát triển bất
kỳ sản phẩm nào hoặc quản lý bất kỳ công việc nào.
Secure shell (SSH) Tập hợp các tiêu chuẩn và một giao thức mạng
liên quan cho phép thiết lập một kênh an toàn giữa máy tính cục bộ
và máy tính từ xa. SSH thường được sử dụng để đăng nhập vào một
máy từ xa và thực hiện các lệnh.
lớp cổng bảo mật (SSL) cung cấp xác thực điểm cuối và bảo
mật thông tin liên lạc qua Internet bằng cách sử dụng mật mã.
Bảo mật của khoa học máy tính liên quan đến việc bảo vệ máy
tính, tài nguyên mạng và thông tin chống lại sự truy cập, sửa đổi và /
hoặc phá hủy trái phép.
Khả năng phục vụ Khả năng của nhân viên hỗ trợ kỹ thuật để gỡ
lỗi hoặc thực hiện phân tích nguyên nhân gốc rễ để theo đuổi giải
quyết một vấn đề với sản phẩm. Khả năng phục vụ còn được gọi là
khả năng hỗ trợ.
Chu trình Shewhart Còn được gọi là chu trình Deming theo tên của
W. Edwards Deming, được đặt theo tên của Walter Shewhart, người
đã đưa ra khái niệm này trong cuốn sách Phương pháp thống kê từ
quan điểm của kiểm soát chất lượng, Dover Publications, New York,
1986. Đó là một chu trình cải tiến liên tục được gọi là kế hoạch, thực
hiện, kiểm tra và hành động (PDCA).
Ranh giới dịch chuyển Sai số biên dịch chuyển được cho là xảy
ra nếu ranh giới thực song song với nhưng không giống với ranh giới
quan tâm.
Màng bọc co lại Vật liệu làm bằng nhựa polyme với hỗn hợp
polyeste. Khi nhiệt được tác động lên vật liệu này, nó sẽ giảm kích
thước để tạo thành một lớp niêm phong trên bất cứ thứ gì mà nó bao
phủ. Màng bọc co lại cung cấp một lớp niêm phong rõ ràng là giả
mạo giúp đảm bảo độ tươi ngon và ngăn cản việc ăn cắp vặt. Gói co
lại thường được tìm thấy trên đĩa CD, DVD, gói phần mềm và sách.
823
Giao thức Quản lý Mạng Đơn giản (SNMP) Một phần của bộ
IP được xác định bởi Lực lượng Đặc nhiệm Kỹ thuật Internet. Giao
thức được sử dụng bởi các hệ thống quản lý mạng để giám sát các
thiết bị gắn vào mạng trong các điều kiện cần sự chú ý của quản trị
viên.
Mô phỏng Mô phỏng một số vật thực, trạng thái của sự việc
hoặc quy trình. Hành động mô phỏng một cái gì đó thường đòi hỏi
đại diện cho các đặc điểm hoặc hành vi chính nhất định của một hệ
thống vật lý hoặc trừu tượng đã chọn.
Six Sigma Bộ thực hành được Motorola phát triển ban đầu để cải
tiến các quy trình một cách có hệ thống bằng cách loại bỏ các khiếm
khuyết. Thuật ngữ Six Sigma đề cập đến khả năng của các quy trình
có khả năng cao để tạo ra đầu ra trong đặc điểm kỹ thuật. Đặc biệt,
các quy trình hoạt động với chất lượng Six Sigma tạo ra ở mức độ lỗi
dưới 3,4 lỗi trên mỗi (một) triệu cơ hội.
Xử lý bàn giao nhẹ nhàng hơn Quy trình xử lý trong đó giao
tiếp cấp người dùng sử dụng đồng thời hai cung của một trạm gốc
duy nhất.
mềm Thủ tục xử lý trong đó giao tiếp cấp người dùng sử dụng đồng
thời hai trạm gốc.
Hình ảnh phần mềm Phần mềm biên dịch nhị phân.
Độ tin cậy của phần mềm Cường độ lỗi của hệ thống phần mềm
hoạt động trong một môi trường nhất định.
Ngôn ngữ đặc tả và mô tả (SDL) Ngôn ngữ đặc tả cấp cao được
xây dựng dựa trên các khái niệm sau: hệ thống, được mô tả phân cấp
bởi các phần tử được gọi là hệ thống, khối, kênh, quy trình, dịch vụ,
tín hiệu và các tuyến tín hiệu; hành vi, được mô tả bằng cách sử dụng
phần mở rộng của khái niệm FSM; dữ liệu, được mô tả bằng cách sử
dụng khái niệm kiểu dữ liệu trừu tượng và các biến chương trình và
cấu trúc dữ liệu thường được hiểu; và giao tiếp không đồng bộ.
Mô hình xoắn ốc Còn được gọi là mô hình vòng đời xoắn ốc,
một phương pháp phát triển hệ thống (SDM) được sử dụng trong
công nghệ thông tin (CNTT). Mô hình phát triển này kết hợp các tính
năng của mô hình tạo mẫu và mô hình thác nước. Mô hình xoắn ốc
được Barry Boehm định nghĩa trong bài báo năm 1988 của ông “Mô
hình xoắn ốc về phát triển và nâng cao phần mềm” (IEEE Computer,
tháng 5 năm 1988, trang 61-72).
đo lường hiệu quả của việc kiểm tra.

Bên liên quan Cá nhân hoặc tổ chức có ảnh hưởng đến hành vi
của hệ thống hoặc bị tác động bởi hệ thống.
Phạm vi của câu lệnh Lựa chọn các đường dẫn theo cách mà
một số câu lệnh nhất định được bao phủ bởi việc thực hiện các đường
dẫn đó. Phạm vi hoàn chỉnh của câu lệnh có nghĩa là chọn một số
đường dẫn sao cho việc thực thi của chúng khiến tất cả các câu lệnh
được bao phủ.
Kiểm thử đơn vị tĩnh Kiểm thử đơn vị không dựa trên thực thi.
Trong thử nghiệm đơn vị tĩnh, một lập trình viên không thực thi đơn
vị; thay vào đó, nó liên quan đến việc xem xét chính thức hoặc xác
minh mã.
Tiên tri thống kê Trường hợp đặc biệt của tiên tri tham số trong
đó các đặc điểm thống kê của kết quả thử nghiệm thực tế được xác
minh.
tra thống kê Kỹ thuật kiểm tra sử dụng mô hình thực nghiệm chính
thức để kiểm tra ngẫu nhiên theo mô hình sử dụng của phần mềm.
Trong thử nghiệm thống kê, một mô hình được phát triển để mô tả
dân số sử dụng phần mềm và mô hình được sử dụng để tạo ra một
mẫu thống kê chính xác về tất cả các mục đích sử dụng phần mềm có
thể có.
Kiểm tra căng thẳng Đánh giá và xác định hành vi của một
thành phần phần mềm khi tải được cung cấp vượt quá khả năng thiết
kế của nó.
Stub “Chương trình con giả” thay thế một mô-đun được gọi bởi
mô-đun sẽ được kiểm tra. Sơ khai thực hiện thao tác dữ liệu tối thiểu,
chẳng hạn như in xác minh mục nhập và trả lại quyền kiểm soát cho
đơn vị được kiểm tra.
Giai đoạn duy trì Tối ưu hóa và tinh chỉnh phần mềm đang hoạt
động và tập trung nhiều hơn vào khách hàng và đối thủ cạnh tranh để
đảm bảo rằng một phần mềm không mất những gì đã có được.
Kỹ sư kiểm tra duy trì Kỹ sư kiểm tra chịu trách nhiệm kiểm
tra sản phẩm trong giai đoạn duy trì của nó.
Kiểm tra tích hợp hệ thống (SIT) Giai đoạn kiểm tra trong đó các
thành phần phần mềm, thành phần phần cứng hoặc cả hai được kết
hợp và kiểm tra để đánh giá tương tác của chúng.
825
Kiểm tra độ phân giải của hệ thống Đầu dò để cung cấp các
câu trả lời chẩn đoán xác định cho các yêu cầu cụ thể.
Kiểm tra hệ thống Kiểm tra toàn diện được thực hiện để xác
nhận toàn bộ hệ thống và các đặc tính của nó dựa trên các yêu cầu và
thiết kế.
beta kỹ thuật được tiến hành để thu thập phản hồi về khả năng sử
dụng của sản phẩm trong môi trường thực tế với các cấu hình khác
nhau. Ý tưởng là thu thập phản hồi từ một số lượng hạn chế người
dùng cam kết dành nhiều thời gian và suy nghĩ cho việc đánh giá của
họ.
Telnet Ứng dụng dựa trên mạng được sử dụng để cung cấp
các phiên đăng nhập dòng lệnh hướng người dùng giữa các máy chủ
trên Internet.
cầu về khả năng kiểm tra Yêu cầu rằng có thể xây dựng một mục
tiêu kiểm tra để xác định xem thuộc tính hệ thống đã được thỏa mãn
hay chưa.
Kiểm tra tính đầy đủ Độ tốt của kiểm tra. Nếu một bài kiểm tra
không cho thấy bất kỳ lỗi nào trong một chương trình, điều đó không
có nghĩa là không có lỗi nào trong chương trình đó. Vì vậy, điều
quan trọng là phải đánh giá mức độ tốt của một bài kiểm tra.
Kiến trúc thử nghiệm Kiến trúc trừu tượng được mô tả bằng
cách xác định các điểm gần IUT nhất mà tại đó điều khiển và quan
sát được chỉ định. Các kiến trúc kiểm thử trừu tượng có thể được
phân loại thành bốn loại chính: cục bộ, phân tán, phối hợp và từ xa.
Tự động hóa kiểm tra Sử dụng các công cụ kiểm tra để thực hiện
kiểm tra mà ít hoặc không có sự can thiệp của con người.
Trường hợp thử nghiệm Cặp đầu vào và kết quả mong đợi. Một
trường hợp kiểm tra bao gồm một mục tiêu kiểm tra cụ thể.
Hiệu suất thiết kế trường hợp thử nghiệm (TCDY) Chỉ số
thường được sử dụng để đo lường hiệu quả thiết kế trường hợp thử
nghiệm.
trường hợp kiểm thử Đo lường chất lượng của các trường
hợp kiểm thử về khả năng tiết lộ lỗi của chúng.
Trường hợp thử nghiệm bị thoát Đôi khi các lỗi được tìm thấy
trong chu kỳ thử nghiệm mà không có trường hợp thử nghiệm nào
được thiết kế. Đối với những khiếm khuyết đó, các trường hợp thử
nghiệm mới được thiết kế, được gọi là trường hợp thử nghiệm đã
thoát.
Thư viện trường hợp thử nghiệm Thư viện tổng hợp các
bước thử nghiệm có thể sử dụng lại của các tiện ích cơ bản được sử
dụng làm khối xây dựng để tạo điều kiện thuận lợi cho việc phát triển
các kịch bản thử nghiệm tự động.
Quy trình phối hợp kiểm tra Tập hợp các quy tắc để phối
hợp hành động của người kiểm tra cấp trên và cấp dưới.
Chu kỳ thử nghiệm Thực hiện một phần hoặc toàn bộ tất cả các bộ
thử nghiệm được lập kế hoạch cho một giai đoạn thử nghiệm hệ
thống nhất định. Kiểm thử hệ thống liên quan đến ít nhất một chu kỳ
kiểm tra.
Dữ liệu thử nghiệm Phần tử của miền đầu vào của một chương
trình. Dữ liệu thử nghiệm được chọn bằng cách xem xét một số tiêu
chí lựa chọn.
Phát triển theo hướng kiểm thử (TDD) Phương pháp luận phát
triển phần mềm trong đó các lập trình viên viết các bài kiểm tra đơn
vị trước mã sản xuất.
điều khiển thử nghiệm Chương trình gọi một thiết bị đang
được thử nghiệm, chuyển đầu vào cho thiết bị đang được thử nghiệm,
so sánh kết quả thực tế với kết quả mong đợi từ thiết bị và báo cáo
kết quả thử nghiệm tiếp theo.
Hiệu quả thử nghiệm Đo lường chất lượng của nỗ lực thử
nghiệm.
Nỗ lực thử nghiệm Chỉ số xác định chi phí và thời gian cần thiết
để tạo và thực hiện một trường hợp thử nghiệm tính bằng ngày.
Môi trường thử nghiệm Thiết lập trong đó các thử nghiệm hệ
thống được thực hiện. Nó còn được gọi là giường thử nghiệm.
Sự kiện thử nghiệm Tương tác nguyên tử giữa IUT và người thử
nghiệm trên hoặc dưới.
Trước tiên hãy thử nghiệm phương pháp luận phát triển phần
mềm, trong đó các lập trình viên viết các bài kiểm tra đơn vị trước
khi viết mã.
Mô hình kiểm tra độ trưởng thành (TMM) Cung cấp hướng
dẫn về cách cải thiện quy trình kiểm tra. Sự trưởng thành của một
quá trình thử nghiệm được thể hiện trong năm cấp độ hoặc giai đoạn,
cụ thể là 1–5. Mỗi giai đoạn được đặc trưng bởi các khái niệm về
827
mục tiêu trưởng thành, hỗ trợ các mục tiêu trưởng thành và các hoạt
động, nhiệm vụ và trách nhiệm (ATR).
Kiểm tra và kiểm tra ký hiệu điều khiển (TTCN) Ngôn
ngữ lập trình dành riêng để kiểm tra các giao thức truyền thông và
dịch vụ web. Lên đến phiên bản 2, ngôn ngữ này không được viết
theo thông thường dưới dạng bảng và ngôn ngữ từng được gọi là Ký
hiệu kết hợp dạng cây và dạng bảng (TTCN) và đã được đổi tên
thành Ký hiệu kiểm tra và kiểm tra trong phiên bản 3.
Giao thức quản lý thử nghiệm Giao thức được sử dụng để
thực hiện các thủ tục điều phối thử nghiệm bằng cách sử dụng các
đơn vị dữ liệu giao thức quản lý thử nghiệm (TM-PDU) trong kiến
trúc điều phối.
Mục tiêu kiểm tra Mô tả những gì cần được xác minh để đảm bảo
rằng một yêu cầu cụ thể được thực hiện một cách chính xác.
Thử nghiệm oracle Có thể quyết định xem một trường hợp thử
nghiệm đã vượt qua hay chưa. Một tiên tri cung cấp một phương
pháp để (i) tạo ra kết quả mong đợi cho các đầu vào thử nghiệm và
(ii) so sánh kết quả mong đợi với kết quả thực tế của việc thực hiện
Vị từ kiểm tra Mô tả các điều kiện hoặc tổ hợp các điều kiện
liên quan đến hoạt động chính xác của một chương trình.
Ưu tiên kiểm thử Thứ tự thực hiện các trường hợp kiểm thử theo
các tiêu chí nhất định.
Quy trình kiểm tra Cách thức thực hiện nhất định các hoạt động
liên quan đến phát hiện khuyết tật.
Mô hình cải tiến quy trình thử nghiệm (TPI) Cho phép người
ta đánh giá mức độ trưởng thành của các quy trình thử nghiệm. Tình
trạng hiện tại của quá trình kiểm tra được đánh giá từ 20 quan điểm,
được gọi là các lĩnh vực chính. Trạng thái của quy trình kiểm tra liên
quan đến một lĩnh vực chính được thể hiện theo một trong bốn cấp
độ trưởng thành — A, B, C và D. Cấp độ A là cấp độ thành thục thấp
nhất và cấp độ trưởng thành tăng dần từ A đến D .
Mục đích kiểm thử Mô tả cụ thể mục tiêu của trường hợp kiểm
thử tương ứng.
Lựa chọn thử nghiệm Lựa chọn cẩn thận một tập hợp con của
các bộ thử nghiệm trên cơ sở các tiêu chí nhất định. Một tập hợp con
được chọn của các bộ thử nghiệm được sử dụng để thực hiện thử
nghiệm hồi quy.
Tiêu chí lựa chọn thử nghiệm Thuộc tính của một chương
trình, một đặc tả, của một miền dữ liệu.
Bộ kiểm thử Nhóm các trường hợp kiểm thử có thể được thực thi
như một gói theo một trình tự cụ thể. Các bộ thử nghiệm thường liên
quan đến lĩnh vực của hệ thống mà chúng thực hiện, theo mức độ ưu
tiên của chúng hoặc theo nội dung.
Công cụ kiểm tra Sản phẩm phần cứng hoặc phần mềm thay thế
hoặc nâng cao một số khía cạnh hoạt động của con người liên quan
đến việc kiểm tra.
Vectơ kiểm tra Còn được gọi là vectơ đầu vào kiểm tra, một
thể hiện của đầu vào cho một chương trình.
Ranh giới nghiêng Lỗi xảy ra nếu ranh giới thực giao với ranh
giới dự kiến.
Tích hợp từ trên xuống Một loại kỹ thuật kiểm tra tích hợp trong đó
kiểm tra bắt đầu ở mô-đun trên cùng của chương trình, thường được
gọi là “chương trình chính” và hoạt động đối với các nhánh ngoài
cùng của cây khả năng hiển thị, dần dần thêm các mô-đun khi quá
trình tích hợp diễn ra.
Kiểm soát chất lượng toàn diện (TQC) Cách tiếp cận quản lý
cho một tổ chức tập trung vào chất lượng và dựa trên sự tham gia của
tất cả các thành viên và hướng tới thành công lâu dài thông qua sự
hài lòng của khách hàng và lợi ích cho tất cả các thành viên của tổ
chức và cho xã hội. Kiểm soát chất lượng toàn diện là khái niệm
chính trong cuốn sách năm 1951 của Armand Feigenbaum, Kiểm
soát chất lượng: Nguyên tắc, Thực hành và Quản trị. Tái bản vào
năm 2004 với tên Total Quality Control, McGraw-Hill, New York.
Ma trận xác định nguồn gốc Cho phép một người tạo ánh xạ giữa
các yêu cầu và trường hợp kiểm thử theo cả hai cách.
Quan điểm siêu việt về chất lượng Chất lượng có thể được công
nhận thông qua kinh nghiệm nhưng không được định nghĩa ở một số
hình thức có thể hiểu được.
Chuỗi truyền Chuỗi đầu vào có độ dài tối thiểu đưa việc triển khai
từ trạng thái ban đầu sang trạng thái nhất định.
Chuyến tham quan chuyển tiếp Các chuyển đổi trạng thái
được xác định trong đặc tả FSM được thực hiện ít nhất một lần bằng
829
cách áp dụng trình tự đầu vào cho việc triển khai, bắt đầu từ trạng
thái ban đầu của FSM. Một chuỗi đầu vào như vậy được gọi là một
chuyến tham quan chuyển tiếp của FSM.
Giao thức điều khiển truyền (TCP) Giao thức cốt lõi của bộ
IP. Các ứng dụng trên các máy chủ nối mạng có thể tạo kết nối với
nhau bằng TCP; các phân đoạn dữ liệu được truyền qua kết nối TCP
để có độ tin cậy cao hơn. Giao thức đảm bảo cung cấp các phân đoạn
dữ liệu theo thứ tự và đáng tin cậy. TCP hỗ trợ nhiều ứng dụng phổ
biến của Internet, bao gồm World Wide Web, e-mail và shell an toàn.
Bảo mật lớp truyền tải (TLS) Cung cấp xác thực điểm cuối và
bảo mật thông tin liên lạc qua Internet bằng cách sử dụng mật mã.
Bảo mật lớp truyền tải đường hầm (TTLS) Tương tự như
giao thức TLS, nhưng xác thực máy khách được mở rộng sau khi kết
nối truyền tải an toàn đã được thiết lập.
Sự không xác định của một biến Một biến được cho là không
được xác định nếu vị trí bộ nhớ của biến đó giữ một giá trị không còn
ý nghĩa nữa.
Trình tự đầu vào-đầu ra (UIO) duy nhất Về cơ bản là trình tự
đầu vào sao cho trình tự đầu ra tương ứng xác định duy nhất trạng
thái mà việc triển khai đã ở trước khi áp dụng trình tự UIO.
Ngôn ngữ mô hình hóa hợp nhất (UML) Ngôn ngữ đặc tả tiêu
chuẩn hóa để mô hình hóa đối tượng. UML là một ngôn ngữ mô hình
hóa có mục đích chung bao gồm ký hiệu đồ họa được sử dụng để tạo
ra một mô hình trừu tượng của một hệ thống.
Đơn vị Chương trình đơn vị hoặc mô-đun có thể được xem
như một đoạn mã triển khai
Chức năng cấp "thấp".
thử đơn vị Kiểm thử một đơn vị chương trình một cách riêng
biệt. Kiểm thử đơn vị được thực hiện bởi lập trình viên đã viết đơn vị
chương trình.
Đơn vị đang thử nghiệm Đơn vị chương trình đang được thử
nghiệm trong bối cảnh môi trường giả lập.
Kiểm tra nâng cấp / hạ cấp Xác minh rằng bản dựng phần mềm hệ
thống có thể được nâng cấp hoặc hạ cấp.
kiểm tra trên Thực thể kiểm tra kiểm soát và quan sát ranh giới dịch
vụ trên của IUT.
Kiểm tra khả năng sử dụng Phương tiện đo lường mức độ mọi
người có thể sử dụng một số đối tượng do con người tạo ra, chẳng
hạn như trang web, giao diện máy tính, tài liệu hoặc thiết bị, cho mục
đích dự định của nó.
Hồ sơ sử dụng Hồ sơ phần mềm đặc trưng cho việc sử dụng
hoạt động của một hệ thống phần mềm. Hoạt động sử dụng là mục
đích sử dụng phần mềm trong môi trường dự định.
Kiểm thử chấp nhận người dùng (UAT) Do khách hàng tiến
hành để đảm bảo rằng hệ thống đáp ứng các tiêu chí chấp nhận theo
hợp đồng.
Quan điểm của người dùng về chất lượng Mức độ mà một sản
phẩm đáp ứng nhu cầu và mong đợi của người dùng.
Tiêu chí hợp lệ Tiêu chí lựa chọn thử nghiệm là hợp lệ nếu và
chỉ khi bất cứ khi nào một chương trình đang được thử nghiệm có
lỗi, tiêu chí sẽ chọn thử nghiệm có lỗi. Quy trình xác nhận đảm bảo
rằng phần mềm đáp ứng được mong đợi của khách hàng.
Quan điểm dựa trên giá trị về chất lượng Ý tưởng trung tâm trong
quan điểm dựa trên giá trị là số tiền khách hàng sẵn sàng trả cho một
mức chất lượng nhất định.
Phán quyết Phán quyết kiểm tra là một tuyên bố đạt, không đạt
hoặc không kết luận được liên kết với một trường hợp kiểm tra. Đạt
có nghĩa là kết quả quan sát được đáp ứng mục đích kiểm tra và hoàn
toàn hợp lệ đối với yêu cầu. Không đạt có nghĩa là kết quả quan sát
được không hợp lệ đối với yêu cầu. Phán quyết không kết luận có
nghĩa là kết quả quan sát được là hợp lệ đối với yêu cầu nhưng không
thể kết luận đối với mục đích kiểm tra.
xác minh để đảm bảo sự tương ứng của giai đoạn thực hiện quy
trình phát triển phần mềm với đặc điểm kỹ thuật của nó.
Mạch ảo (VC) Bố trí giao tiếp trong đó dữ liệu từ người dùng
nguồn có thể được chuyển đến người dùng đích qua nhiều mạch giao
tiếp thực trong một khoảng thời gian giao tiếp; việc chuyển đổi bị ẩn
khỏi người dùng. Mạch ảo vĩnh viễn (PVC) là một mạch ảo được
thiết lập để sử dụng lặp lại giữa cùng một thiết bị đầu cuối dữ liệu
(DTE). Trong PVC, liên kết dài hạn giống như giai đoạn truyền dữ
liệu của một cuộc gọi ảo. Các mạch ảo vĩnh viễn loại bỏ nhu cầu thiết
lập và xóa cuộc gọi lặp lại. Mặt khác, các mạch ảo chuyển mạch
831
(SVC) thường được thiết lập trên cơ sở mỗi cuộc gọi và bị ngắt kết
nối khi cuộc gọi kết thúc.
Virus có khả năng lây lan nhanh chóng đến một số lượng lớn máy
tính nhưng không thể tự làm hết được. Nó phải lan rộng bằng cách sử
dụng sự hỗ trợ của một chương trình khác.
Đánh giá hướng dẫn trong đó lập trình viên dẫn đầu nhóm đánh giá
thông qua quá trình thực thi sản phẩm theo cách thủ công hoặc mô
phỏng bằng cách sử dụng các tình huống được xác định trước.
Mô hình thác nước Mô hình phát triển phần mềm tuần tự
trong đó sự phát triển được coi là chảy xuống đều đặn — giống như
thác nước — thông qua các giai đoạn phân tích yêu cầu, thiết kế,
triển khai, thử nghiệm, tích hợp và bảo trì. Nguồn gốc của thuật ngữ
"thác nước" thường được cho là một bài báo (Quản lý sự phát triển
của các hệ thống phần mềm lớn: Khái niệm và kỹ thuật, trong Kỷ yếu
của WESCON, tháng 8 năm 1970, trang 1-9. In lại trong ICSE,
Monterey, CA, 1987, trang 328-338) được xuất bản năm 1970 bởi
WW Royce.
thử hộp trắng Phương pháp kiểm tra trong đó chủ yếu tính
đến các cơ chế bên trong, chẳng hạn như mã và logic chương trình,
của một hệ thống hoặc thành phần.
Worm có khả năng lây nhiễm vào hệ thống máy tính theo
cách riêng của nó.
W -set Tập hợp các trình tự đầu vào cho FSM. Khi tập hợp các
đầu vào được áp dụng cho việc triển khai FSM ở trạng thái dự định,
người ta mong đợi quan sát các đầu ra xác định duy nhất trạng thái
của việc triển khai.
Cuộc tấn công Zero-day Trình bày một loại mối đe dọa mới và
đặc biệt nghiêm trọng. Được phát triển đặc biệt để khai thác các lỗ
hổng phần mềm trước khi có bản vá, các cuộc tấn công này không
được các sản phẩm bảo mật truyền thống nhận ra: chúng xâm nhập
vào mạng mà không bị phát hiện, hoàn toàn không có thời gian
chuẩn bị cho việc phòng thủ.

Software Testing and Quality Assurance T-1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Testing and Quality Assurance T-1

Uploaded by

Copyright:

Available Formats

KIỂM THỬ PHẦN MỀM

VÀ ĐẢM BẢO CHẤT LƯỢNG

A JOHN WILEY & SONS, INC., PUBLICATION

Danh sách các hình xxi

1.1 Cuộc cách mạng về chất lượng 1

2.1 Các khái niệm cơ bản trong lý thuyết kiểm tra 31

3.1 Khái niệm về Kiểm thử đơn vị 51

4.1 Ý tưởng cơ bản 88

6.1 Lỗi tên miền 135

7.1 Khái niệm về kiểm thử tích hợp 158

8.1 Phân loại các Kiểm tra Hệ thống 192

10.1 Mô hình hướng trạng thái 265

11.1 Các yếu tố thiết kế thử nghiệm 321

13.1 Ý tưởng cơ bản 408

17.1 Năm quan điểm về chất lượng phần mềm 519

18.1 Ý tưởng cơ bản trong quy trình phần mềm 546

CHÚ GIẢI THUẬT NGỮ 581

DANH MỤC CÁC HÌNH xxiii

Hình 1.2 Sơ đồ Ishikawa.

1.3 VAI TRÒ CỦA KIỂM TRA

1.5 THẤT BẠI, LỖI, LỖI VÀ ĐÁNH BẠI

1.6 LƯU Ý VỀ ĐỘ TIN CẬY CỦA PHẦN MỀM

1.7 MỤC TIÊU KIỂM TRA

1.8 TRƯỜNG HỢP KIỂM TRA LÀ GÌ?

D1 Apply inputs P1 Observe outcome

Assign a test verdict

Unit Integration System Acceptance

1.18 CÔNG CỤ THỬ NGHIỆM VÀ TỰ ĐỘNG HÓA

Một vấn đề quan trọng trong lý thuyết của Goodenough và Gerhart là

Vị từ được gọi là REVEALING (C, S) nắm bắt ý tưởng trên trong

Hình 2.4 Bối cảnh áp dụng thử nghiệm đầy đủ.

3.2 KIỂM TRA ĐƠN VỊ THỐNG KÊ

Mọi dòng mã trong thiết bị đã được kiểm tra.

3.3 PHÒNG NGỪA ĐÁNH BẠI

Call and pass input

Unit Under Test

Call Acknowledge Call Acknowledge

Print Stub Stub Print

Hình 3.2 Môi trường kiểm thử đơn vị động.

Bước Chọn một yêu cầu, đó là một câu chuyện.

Add a single test

Add code for the test

Execute all tests

// giá trị; y là thực tế

Process of generating test input data

Output Test input

Sequential computation Decision point Merge point

Điều kiện trên được thực hiện như sau:

av = (double) −999 av = (double)sum/tv T

Đường dẫn 1 1-2-3 (F) -10 (T) -12-13

BẢNG 4.3 Đầu vào và Đường dẫn trong openfiles ()

SCPath 1 1-2-3 (F) -10 (F) -11-13

BCPath 1 1-2-3 (F) -10 (F) -11-13

BCPath 4 1-2-3 (T) -4 (T) -5-6 (F) -9-3 (F) -

4.5.4 Dự đoán tiêu chí mức độ phù hợp

3 Compute OB3 3 Compute AB3

4 OB = OB1 || OB2 || OB3 4 AB = AB1 && AB2 && AB3

OBlock1 OBlock2 ABlock1 ABlock2

public static int SymSub (int x1, int x2) {int y;

Chúng tôi đưa ra các ví dụ về dữ liệu thử nghiệm đã chọn để đạt

Woodward, Hedley và Hennell [12] đã xác định được một số vấn đề

Clarke [3] mô tả một hệ thống tự động để tạo dữ liệu thử nghiệm từ

5.3 TỔNG QUAN VỀ KIỂM TRA DÒNG DỮ LIỆU ĐỘNG

Vẽ biểu đồ luồng dữ liệu từ một chương trình.