Bài giảng Nhập môn công nghệ phần mềm (Introduction to software engineering) - Chương 8: Quản lý chất lượng phần mềm (Tiếp)

gt; 20
 End; }
end; abs = y x20 yes
 end; -----------------------------------end; absz=fie = y (x,y) z=foo (x,y) 
 Test case-2: test-case-1: t t
 Testtest case case-1:-1: test case-2: test case-1: x20
 input: y = 0 input:input: y y = = - 5-5 test-case:2----------------------------------- t f
 input: y = 0 test-case-3:input: y = f0 t input: y = -5
 expected result: 0 expected result: 5 expectedtest-case-1: result: 0 t t expected result: 5
 expected-result: 0 expected-result: 5 test-case-4test-case:2 f f t f
 actual result: ? actual result: ? actual result: ? actual result: ?
 actual result: ? actual result: ? 2001-10-10test-case-3: PUM-I, fMariam Kamkar, t IDA 8
2001-10-10 PUM-I, Mariam Kamkar, IDA 6 2001-10-10test-case-4 PUM-I, Mariam Kamkar, f IDA f 6
 15 16
 2001-10-10 PUM-I, Mariam Kamkar, IDA 8
 15 16
 4
 3
 3
 4
 3. Kỹ thuật thiết kế trường hợp thử 
 3.1. Kiểm thử hộp đen
 và các phương pháp kiểm thử 
 • Kỹ thuật thiết kế trường hợp thử dựa trên đặc • Phân đoạn tương đương
 tả bề ngoài của chương trình: Kiểm thử hộp • Phân tích giá trị biên
 đen (Black box test): WHAT ? • Đoán lỗi
 •
 Kỹ thuật thiết kế trường hợp thử dựa trên đặc • Và 1 số kỹ thuật khác
 tả bên trong của chương trình: Kiểm thử hộp 
 Đầu vào
 trắng (white box test): HOW ? Kết quả
 Hộp đen
 • Kiểm thử Top-Down hay Bottom-Up
 Chiến lược kiểm tra dữ liệu hộp đen
 17 18
17 18
 a. Phương pháp phân đoạn tương b. Phương pháp phân tích giá trị biên
 đương (Equivalence Partition) (Boundary value analysis)
 • Mục đích: giảm số lượng test bằng cách chọn • Là 1 trường hợp riêng của phân đoạn
 các tập dữ liệu đại diện • Thí dụ: nếu miền dữ liệu là tháng thì giá trị 0 
 • Thực hiện: Chia dữ kiệu vào thành các đoạn, hay >12 là không hợp lệ
 mỗi đoạn đại diện cho một số dữ liệu => việc
 kiểm thử chỉ thực hiện trên đại diện đó • Thường sử dụng trong kiểm thử module 
 • Ưu điểm: Test theo mức trừu tượng hơn là
 trường. 
 • Áp dụng: màn hình, menu hay mức quá trình.
 • Ví dụ:
 19 20
19 20
 c. Phương pháp đoán lỗi d. Phương pháp đồ thị nguyên nhân -
 (Error Guessing) kết quả (Cause-effect Graphing)
 • Dựa vào trực giác và kinh nghiệm
 SEQUENCE
 • Thí dụ lỗi chia cho 0. Nếu module có phép chia AND
 thì phải kiểm thử lỗi này
 • Nhược điểm: không phát hiện hết lỗi NOT
 DO UNTIL
 OR
 21 22
21 22
 3.2. Kiểm thử hộp trắng Kiểm thử hộp trắng (tiếp)
 • Là phương pháp kiểm thử dựa vào cấu trúc • Người KSPM có thể đảm bảo:
 – Kiểm tra tất cả các lộ trình độc lập bên trong 1 mô đun
 điều khiển của các thủ tục để thiết kế các ít nhất 1 lần
 trường hợp kiểm thử. – Kiểm tra tất cả các nhánh đúng/sai của lựa chọn
 – Kiểm tra việc thực hiện của vòng lặp tại các biên và
 bên trong vòng lặp
 – Kiểm tra các cấu trúc dữ liệu để đảm bảo tính hợp
 Đầu vào
 Kết quả thức.
 h h
 h h • Các kỹ thuật:
 – Kiểm thử theo lộ trình (Basis path testing)
 Chiến lược kiểm tra dữ liệu hộp trắng – Kiểm thử theo cấu trúc điều khiển. 
 23 24
23 24
 a. Kiểm thử theo lộ trình Ví dụ: lưu đồ khối chương trình
 • Là kỹ thuật do Tom McCabe đề xuất cho phép nhà
 kiểm thử tiến hành 1 số đo về độ phức tạp lô gic
 của các thủ tục và số đo này được sử dụng để 1
 giúp cho việc định nghĩa các lộ trình cơ bản sao
 cho các lệnh trong chương trình được thực hiện 11 2
 ít nhất 1 lần trong quá trình kiểm thử. 3
 • Sử dụng Ký pháp đồ hoạ luồng/ đồ thị chương 6 4
 trình: 
 – Mỗi nút đồ thị biểu diễn 1 lệnh/ 1 dãy lệnh liên tiếp 7 8 5
 – Cung của đồ thị biểu diễn luồng điều kiện (trình tự 9
 thực hiện).
 10
 25 26
25 26
 Ví dụ: Đồ thị chương trình Chú ý
 1 • Một cung bao giờ cũng phải kết thúc tại 1 nút (có
 thể nút này không tương ứng với bất kỳ lệnh nào
 2, trong thủ tục).
 3 • Vùng bao bởi các cung và nút gọi là Region (khi
 4,
 6 tính, ta phải tính cả vùng bao ngoài).
 3 5
 • Thí dụ đồ thị chương trình ở slide trước gồm 4 
 7 2 8 1 vùng (các số in nghiêng). 
 • Với điều kiện phức tạp (nhiều hơn 1 phép so 
 sánh) thì mỗi so sánh lại tách thành 1 nút riêng.
 9 10
 4 • Thí dụ: If a OR b then X else Y Endif
 11
 27 28
27 28
 Độ phức tạp lặp (Cyclomatic 
 Độ phức tạp lặp
 Complexity)
 • Độ phức tạp lặp là 1 số đo phần mềm, cung cấp 1 đơn • Có 3 cách tính độ phức tạp lặp ký hiệu V(G):
 vị đo định lượng về độ phức tạp lô gic của CT.
 – V(G) = E – N +2, với E là số cung, N là số nút của G
 • Trong ngữ cảnh áp dụng kiểm thử theo lộ trình, giá trị
 này sẽ cung cấp số lượng các lộ trình (path) độc lập – V(G) = số vùng (region)
 trong 1 chương trình và đó được coi như là cận trên – V(G) = P +1, với P là số lượng nút Predicat (nút giả
 của số lượng test phải tiến hành để đảm bảo mọi lệnh định, không có thật). 
 đều được thực hiện ít nhất 1 lần.
 • Lộ trình độc lập? 1 phần của CT bao gồm ít nhất 1 tập
 lệnh hay 1 điều kiện mới.
 • Đồ thị CT trên có 4 lộ trình độc lập: 1-11; 1-2-3-4-5-10-
 1-11; 1-2-3-6-8-9-10-1-11; 1-2-3-6-7-9-10-1-11
 29 30
29 30
 Thí dụ: chương trình viết bằng PDL Lời giải
 i = 1
 1 TotalInput = TotalValid = 0 2 • Số lộ trình độc lập (độ phức tạp lặp) = 6
 Sum = 0 –
 While value(i) -999 And TotalInput < 100 Do 3 1-2-10-11-13; 1-2-10-12-13
 4 TotalInput = TotalInput +1 – 1-2-3-10-11-13; 1-2-3-4-5-8-9-2 
 If Value(i) >= Minimum And value(i) <= Maximum 5
 6 Then TotalValid = TotalValid +1 –
 7 1-2-3-4-5-6-8-9-2; 1-2-3-4-5-6-7-8-9-2
 Sum = Sum + value(i)
 Else Skip – : có nghĩa là phần tiếp theo còn lại đồ thị là chấp
 Endif nhận được.
 i = i +1 8
 EndDo 9 • Đồ thị chương trình ?
 10 If TotalValid > 0 Then Average = Sum / TotalValid 11
 Else Average = -999 12 • Số test phải thực hiện: 6
 Endif
 13
 LastUpdate 8-07  Dept. of SE, 2001 SE-V.31 32
31 32
 3.3. Trình tự thiết kế kiểm thử 4. Kiểm thử module
 • Kiểm thử module • Kiểm thử tích hợp module
 • Kiểm thử tích hợp – Kiểm thử dưới lên (Bottom-up Test)
 – Kiểm thử tích hợp trên xuống – Kiểm thử trên xuống (Top-down Test)
 – Kiểm thử tích hợp dưới lên – Kiểm thử cột trụ (Big bang Test)
 – Kiểm thử hồi qui – Kiểm thử kẹp (Sandwich Test)
 33 34
33 34
 a. Kiểm thử dưới lên
 Kiểm thử dưới lên (Tiếp)
 (Bottom-up Test)
 • Các module mức thấp được tổ hợp vào các
 chùm thực hiện một chức năng con Mức 4
 •
 Viết trình điều khiển phối hợp vào/ ra và kiểm Mức 3
 thử
 • Kiểm thử chùm/bó
 Mức 2
 • Loại bỏ trình điều khiển và chuyển lên mức
 trên
 Mức 1
 35 36
35 36
 b. Kiểm thử trên xuống
 Kiểm thử trên xuống (tiếp)
 (Top-down Test)
 • module điều khiển chính được dùng như trình
 điều khiển kiểm thử, gắn các nút con trực tiếp
 vào nó
 • Thay các nút con bằng các module thực tại
 (theo chiều sâu / ngang) Mức 1
 Mức 2
 • Kiểm thử từng module được gắn vào Mức 3
 • Các 1 nút thử xong được thử tiếp nút khác Mức 4
 • Kiểm thử hồi quy
 37 38
37 38
 c. Kiểm thử cột trụ (Big bang Test) d. Kiểm thử kẹp (Sandwich Test)
 • Tích hợp không tăng dần • Tích hợp trên xuống cho các mức trên cấu trúc 
 • Tất các các module đều được tổ hợp trước chương trình
 • Toàn bộ chương trình được kiểm thử tổng thể • Tích hợp dưới lên cho các mức phụ thuộc
 • Khó khăn: khó cô lập lỗi, khi chữa xong lỗi này
 có thể lỗi mới lại phát sinh
 39 40
39 40
 5. Kiểm thử hệ thống 6. Kiểm thử chấp nhận
 • Kiểm thử phục hồi: bắt buộc phần mềm hỏng • Mục đích: để bàn giao PM cho khách hàng
 nhiều cách để kiểm chứng phục hồi • Đối tượng: Cần có sự tham gia của ND
 • Kiểm thử an toàn: kiểm chứng cơ chế bảo vệ • Trình tự: Dựa vào Yêu cầu PM
 • Kiểm thử gay cấn
 • Kiểm thử hiệu năng
 41 42
41 42
 Chương 8: Quản lý chất lượng phần 
 1. Khái niệm
 mềm
 • Mô hình V & V • Bảo trì là công việc tu sửa, thay đổi phần mềm
 • Kiểm thử đã được phát triển (chương trình, dữ liệu, JCL, 
 các loại tư liệu đặc tả, . . .) theo những lý do 
 • Bảo trì nào đó.
 1. Khái niệm • Các hình thái bảo trì: bảo trì để
 2. Quy trình nghiệp vụ – Tu chỉnh
 3. Các vấn đề còn tồn tại – Thích nghi
 4. Bảo trì trong các phương pháp phát triển phần – Cải tiến
 mềm – Phòng ngừa
 43 44
43 44
 a. Bảo trì để tu sửa b. Bảo trì để thích hợp
 • Là bảo trì khắc phục những • Kỹ nghệ ngược (Reverse 
 khiếm khuyết có trong phần Engineering): dò lại thiết kế để • Là tu chỉnh phần mềm theo thay đổi của môi 
 mềm. tu sửa. trường bên ngoài nhằm duy trì và quản lý phần 
 • Một số nguyên nhân điển hình • Những lưu ý 
 – Kỹ sư phần mềm và khách hiểu – Mức trừu tượng mềm theo vòng đời của nó.
 nhầm nhau. – Tính đầy đủ
 – Lỗi tiềm ẩn của phần mềm do – Tính tương tác • Thay đổi phần mềm thích nghi với môi trường: 
 sơ ý của lập trình hoặc khi kiểm 
 thử chưa bao quát hết. – Tính định hướng công nghệ phần cứng, môi trường phần mềm.
 – Vấn đề tính năng của phần 
 mềm: không đáp ứng được yêu • Những nguyên nhân chính:
 cầu về bộ nhớ, tệp, . . . Thiết kế 
 sai, biên tập sai . . . – Thay đổi về phần cứng (ngoại vi, máy chủ,. . .)
 – Thiếu chuẩn hóa trong phát 
 triển phần mềm (trước đó). – Thay đổi về phần mềm (môi trường): đổi OS
 – Thay đổi cấu trúc tệp hoặc mở rộng CSDL
 45 46
45 46
 c. Bảo trì để cải tiến d. Bảo trì để phòng ngừa
 • Là việc tu chỉnh hệ phần • Còn gọi là tái kỹ nghệ (re- • Là công việc tu chỉnh • Mục đích: sửa đổi để
 mềm theo các yêu cầu ngày engineering) chương trình có tính đến thích hợp với yêu cầu
 càng hoàn thiện hơn, đầy • Mục đích: đưa ra một thiết tương lai của phần mềm thay đổi sẽ có của người
 đủ hơn, hợp lý hơn. kế cùng chức năng nhưng
 • Những nguyên nhân chính: có chất lượng cao hơn. đó sẽ mở rộng và thay đổi dùng.
 – Do muốn nâng cao hiệu suất • Các bước thực hiện: như thế nào. • Thực hiện những thay đổi
 nên thường hay cải tiến – Xây dựng lưu đồ phần mềm •
 phương thức truy cập tệp. Thực ra trong khi thiết kế trên thiết kế không tường
 – Suy dẫn ra biểu thức Bun cho phần mềm đã phải tính minh.
 – Mở rộng thêm chức năng mới từng dãy xử lý
 cho hệ thống.
 – Biên dịch bảng chân lí đến tính mở rộng của nó, • Hiểu hoạt động bên trong
 – Cải tiến quản lý kéo theo cải 
 tiến tư liệu vận hành và trình – Tái cấu trúc phần mềm nên thực tế ít khi ta gặp chương trình
 tự công việc. bảo trì phòng ngừa nếu • Thiết kế / lập trình lại.
 – Thay đổi người dùng hoặc như phần mềm được 
 thay đổi thao tác. thiết kế tốt. • Sử dụng công cụ CASE
 47 48
47 48
 2. Quy trình nghiệp vụ Sơ đồ bảoThực thi “trên trìbàn”:
 Hiểu phần mềm đã -Nắm vững các chức năng của hệ thống theo tài
 có liệu
 • Quy trình bảo trì: quá trình trong vòng đời của phần mềm, -Nắm vững đặc tả chi tiết, điều kiện kiểm thử, . . . 
 cũng tuân theo các pha phân tích, thiết kế, phát triển và theo tài liệu
 kiểm thử từ khi phát sinh vấn đề cho đến khi giải quyết 2 Phát triển phần -Dò đọc chương trình nguồn, hiểu trình tự xử lý chi 
 Loại bảo trì?
 xong. mềm mới tiết của hệ thống
 • Các nhiệm vụ bảo trì: 1 -Khi thêm chức năng mới phải phát triển chương
 – Phân tích/cô lập: phân tích tác động, phân tích những giá trị lợi Tu sứa phần mềm trình cho phù hợp với yêu cầu
 đã có -Cần tiến hành từ thiết kế, lập trình, gỡ lỗi và kiểm
 ích, và cô lập các thành phần cần bảo trì thử unit
 – Thiết kế: thiết kế lại hệ thống (phải biết cách tu sửa, thay đổi). -Phản ảnh vào giao diện của phần mềm (thông
 – Kiểm thử tính nhất báo, phiên bản, . . .)
 Thực thi: thay thế mã nguồn và kiểm soát từng đơn vị thành quán
 phần hệ thống, có tính đến thời gian lập trình.
 • Thao tác bảo trì: Gồm 2 loại 
 Kiểm thử sau bảo -Bảo trì chương trình nguồn, tạo các module mới
 – Tu chỉnh cải đã có (loại 1) trì và dịch lại.
 -Thực hiện kiểm thử unit và tu chỉnh những mục
 – Thêm cái mới (loại 2) liên quan có trong tư liệu đặc tả.
 Tạo biểu quản lý bảo -Chú ý theo sát tác động của module được sửa
 trì đến các thành phần khác trong hệ thống.
 49 50
49 50
 Sơ đồ bảoBằng kiểm thửtrìtích hợp 3. Các vấn đề còn tồn tại
 Hiểu phần mềm đã -Đưa đơn vị (unit) đã dược kiểm thử vào hoạt
 có động trong hệ thống
 -Điều chỉnh sự tương tích giữa các module • Phương pháp cải tiến thao tác bảo trì:
 -Dùng các dữ liệu trước đây khi kiểm thử để kiểm
 2 Phát triển phần thử lại tính nhất quán
 Loại bảo trì? – Sáng kiến trong quy trình phát triển phần mềm
 mềm mới ! Chú ý hiệu ứng làn sóng trong chỉnh sửa
 1 – Sáng kiến trong quy trình bảo trì phần mềm
 Tu sứa phần mềm –
 đã có Khi hoàn thành bảo trì: Phát triển những kỹ thuật mới cho bảo trì
 -Kiểm tra nội dung mô tả có trong tư liệu đặc tả
 -Cách ghi tư liệu có phù hợp với mô tả môi trường
 Kiểm chứng tính nhất phần mềm mới hay không ?
 quán
 Để quản lý tình trạng bảo trì, lập biểu:
 Kiểm thử sau bảo
 trì -Ngày tháng, giờ
 -Nguyên nhân
 -Tóm tắt cách khắc phục
 Tạo biểu quản lý bảo -Chi tiết khắc phục, hiệu ứng làn sóng
 trì -Người làm bảo trì
 -Số công 51 52
51 52
 a. Sáng kiến trong quy trình b. Sáng kiến trong quy trình bảo trì
 phát triển phần mềm phần mềm
 • Chuẩn hóa mọi khâu trong phát triển phần • Sử dụng các công cụ hỗ trợ phát triển phần
 mềm mềm
 • Người bảo trì chủ chốt tham gia vào giai đoạn • Chuẩn hóa thao tác bảo trì và thiết bị môi
 phân tích và thiết kế trường bảo trì
 • Thiết kế để dễ bảo trì • Lưu lại những thông tin sử bảo trì
 • Dự án nên cử một người chủ chốt của mình
 làm công việc bảo trì sau khi dự án kết thưc
 giai đoạn phát triển.
 53 54
53 54
 c. Phát triển những kỹ thuật mới cho 
 Bài tập về nhà
 bảo trì
 • Công cụ phần mềm hỗ trợ bảo trì • Tìm hiểu SMMM – Software Maintenance 
 • Cơ sở dữ liệu cho bảo trì Maturity Model.
 • Quản lý tài liệu, quản lý dữ liệu, quản lý
 chương trình nguồn, quản lý dữ liệu thử, quản
 lý sử bảo trì
 • Trạm bảo trì tính năng cao trong hệ thống
 mạng lưới bảo trì với máy chủ thông minh.
 55 56
55 56
 Chương 8: Quản lý chất lượng phần 
 a. Phát triển lặp
 mềm
 • Mô hình V & V
 Yêu cầu Phân tích & Thiết kế
 • Kiểm thử Kế hoạch
 ban đầu Cài đặt
 • Bảo trì
 1. Khái niệm Kiểm thử
 2. Quy trình nghiệp vụ
 Đánh giá
 3. Các vấn đề còn tồn tại Triển khai
 4. Bảo trì trong các phương pháp phát triển phần 
 Mỗi vòng lặp tạo ra
 mềm một phiên bản
 thực thi
 57 58
57 58
 RUP Agile
 Phát triển lặp
 Giá trị sản phẩm được phân phối từng bước lặp đi lặp lại
 Bắt đầu Khởi thảo Xây dựng Chuyển đổi
 Mô hình nghiệp vụ
 Yêu cầu
 Phân tích và thiết kế
 Cài đặt
 Kiểm thử
 Triển khai
 Các vòng lặp
 Bước lặp lặp. lặp. lặp. lặp. lặp. lặp. lặp.
 sơ bộ(s) #1 #2 #n #n+1 #n+2 #m #m+1
 59 60
59 60
 Scrum b. Hướng thành phần
 • Những hoạt động bảo trì chính ở CBSD
 – Gắn kết hóa và gói hóa
 – May đo hóa
 – Phát hiện lỗi và cô lập
 – Cập nhật cấu hình thành phần
 – Theo dõi và kiểm tra các hành vi hệ thống
 – Kiểm thử các thành phần
 61 62
61 62
 c. Mã nguồn mở Kiểm thử và bảo trì
 • Sự khác biệt với bảo trì theo phương pháp • Kiểm thử • Bảo trì
 – Thay đổi, cải tiến phần 
 truyền thống – Phát hiện lỗi, đánh mềm đã được phát triển
 – Phiên bản ngày tháng giá phần mềm – Thực hiện sau khi phần 
 – Thực hiện trong và mềm được đưa vào sử 
 – Chờ đợi dịch vụ dụng
 sau quá trình phát 
 triển phần mềm
 63 64
63 64