ĐẢM BẢO VÀ KIỂM SOÁT CHẤT LƯỢNG

Chương 4: Các kỹ thuật kiểm tra tĩnh

HCM – 10/2012

4/23/2014

1

Nội dung

Các phương pháp Testing

 Kiểm thử tĩnh  Kiểm thử động

Các kiểu rà soát (Review)

Phân tích tĩnh

4/23/2014 Trang 2

Các phương pháp Testing

Dynamic

Static

etc.

Reviews

Behavioural

Static Analysis

Inspection

Non-functional

Functional

Walkthroughs

Structural

Desk-checking

etc.

etc.

Usability

Equivalence Partitioning

Control Flow

Performance

Data Flow

etc.

Boundary Value Analysis

etc.

Statement

Cause-Effect Graphing

Arcs

Symbolic Execution

Branch/Decision

Random

Branch Condition

LCSAJ

Definition -Use

State Transition

Branch Condition Combination

4/23/2014 Trang 3

Kiểm thử tĩnh

Phân tích tĩnh thực hiện mà không cần thực thi hệ thống thực sự. Điều này ngược với kiểm thử động

Thường thì nó không kiểm thử chi tiết

mà chủ yếu kiểm tra tính đúng đắn của code (mã lệnh), thuật toán hay tài liệu

Đây chính là verification trong mô

hình V&V

Những thực hiện: lập trình viên và QC

4/23/2014 Trang 4

Lợi ích

 Bổ sung cho kiểm tra động trong giai đoạn kiểm chứng

chương trình  Có thể phát hiện sớm 30%-70% lỗi  Chi phí chỉnh sửa một khiếm khuyết tăng lên nhanh chóng sau mỗi giai đoạn. trong thiết kế tốn phí 1.0, trước kiểm thử: 6.5, trong kiểm thử:15 và sau phân phối sẽ từ 60 đến 100

 Nhận diện tổng quát, các lỗi sớm được phát hiện.

 Chi phí thấp hơn nhưng lại đạt được khả năng sửa lỗi

phù hợp hơn, tốt hơn  Chỉ ra một “lô” các lỗi “liên quan”

 Sửa toàn thể (một loạt) lỗi sau đó  Phát hiện sự phụ thuộc, thiếu nhất quán  Nâng cao khả năng bảo trì mã/chương trình  „„„„„„„„Ngăn ngừa khiếm khuyết

4/23/2014 Trang 5

Chi phí sửa lỗi trong quá trình phát triển

4/23/2014 Trang 6

Kiểm thử động

Kiểm thử động cần thực thi hệ thống thực sự bao gồm nhập các giá trị đầu vào và kiểm tra xem liệu đầu ra có như mong muốn hay không

Đây chính là validation trong mô hình

V&V

Các phương pháp kiểm thử động gồm

có kiểm thử Unit – Unit Tests, Kiểm thử tích hợp – Intergration Tests, Kiểm thử hệ thống – System Tests, và Kiểm thử chấp nhận sản phẩm – Acceptance Tests

4/23/2014 Trang 7

Kiểm thử Tĩnh vs. Kiểm thử Động

4/23/2014 Trang 8

Nội dung

Các phương pháp Testing

 Kiểm thử tĩnh  Kiểm thử động

Các kiểu rà soát (Review)

Phân tích tĩnh

4/23/2014 Trang 9

Thế nào là rà soát (Review)

 Review là quá trình kiểm tra có hệ thống được thực hiện bởi 1 hay nhiều người với mục tiêu chính là tìm kiếm và loại bỏ những khiếm khuyết  Mục tiêu của rà soát:

 Tìm kiếm khiếm khuyết  Thu sự hiểu biết  Tạo sự thảo luận

 Review giúp xác định lỗi trước khi chúng

trở thành 1 phần của code thực thi  Làm những lỗi rẻ hơn và dễ sửa hơn

4/23/2014 Trang 10

Các loại lỗi

Ba loại lỗi có ở mỗi bước của quá trình

phát triển phần mềm:  Lỗi mới được sinh ra  Lỗi còn lại của các bước trước  Lỗi được phóng đại lên do các nhân tố lỗi

của các bước trước

Nếu không rà soát lỗi tồn lại gia tăng nhanh, và chi phí cho việc loại trừ các lỗi ngày càng lớn; Nguyên tắc xử lý lỗi: “chi phí bây giờ hay để lại sau phải với chi phí nhiều hơn?”

4/23/2014 Trang 11

Review: Chi phí và lợi ích

Chi phí

 Thời gian  Sự nỗ lực thu thập và phân tích các yếu tố

(metrics)

Lợi ích

 Lịch biểu ngắn hơn  Chu kỳ kiểm tra ngắn hơn, chi phí kiểm thử

thấp hơn

 Gia tăng năng suất  ‰Cải tiến chất lượng sản phẩm 4/23/2014

Trang 12

Tiến trình chung của hoạt động rà soát

4/23/2014 Trang 13

Vai trò và Trách nhiệm

 Điều phối/Chủ trì (Moderator):

 Chủ trì các cuộc họp

 Thư ký:

 Tập hợp thông tin về tìm kiếm lỗi

 Tác giả:

 Mô tả, giải thích và trả lời các câu hỏi

 Người rà soát (Reviewer/inspector):

 Tìm kiếm lỗi  Người quản lý:

 Lập kế hoạch, sắp xếp tài nguyên và việc huấn luyện,

hỗ trợ, phân tích các yếu tố quy trình

 Đôi khi, một người có thể đóng nhiều vai trò  Tác giả đôi khi đóng vai trò như Trung gian  Một trong những người rà soát làm thư ký

4/23/2014 Trang 14

Cuộc họp rà soát

 Mọi cuộc họp rà soát phải:

 Gồm từ 3 đến 5 người liên quan.  Phải chuẩn bị trước (1 người không quá2

giờ).

 Cuộc họp chỉ nên từ 2-3 giờ. Mỗi cuộc họp rà soát chỉ hạn chế trong một phần nhỏ, cụ thể.  Kết luận đưa ra 1 trong 3 quyết định sau:  Chấp nhận sản phẩm không cần chỉnh sửa  Khước từ sản phẩm vì những lỗi nghiêm trọng  Chấp nhận cho chỉnh sửa sản phẩm, sau khi

chỉnh sửa phải rà soát lại

4/23/2014 Trang 15

Sản phẩm rà soát

Sản phẩm của cuộc họp rà soát:

 Báo cáo các vấn đề nảy sinh do các cá

nhân rà soát nêu ra

 Một danh sách các vấn đề cần giải quyết  Một văn bản tổng kết cuộc họp rà soát đó.

Văn bản tổng kết họp rà soát phải chỉ

rõ:  Đã rà soát cái gì  Ai rà soát  Tìm thấy cái gì và Kết luận ra sao

4/23/2014 Trang 16

Những gì có thể được rà soát?

Bất kỳ thứ gì được viết ra:

 Hợp đồng, chính sách, kế hoạch kinh

doanh

 Yêu cầu, đánh giá mức độ khả thi, kế

hoạch kiểm tra chấp nhận (Acceptance Test)

 Kế hoạch Test, Test case, kết quả test  Bản thiết kế, CSDL  Source code  User guide, training  …

4/23/2014 Trang 17

Nhân tố Rà soát thành công

 Huấn luyện kỹ càng  Rà soát cả chức năng –

 Phải có sự chuẩn bị  Rà soát sản phẩm,

phi chức năng

không rà soát người làm ra nó

 Lập và theo danh sách kiểm tra (checklist)

 Giới hạn tranh cãi  Tập trung tìm kiếm“vấn đề”, không đi vào giải quyết

 Nắm rõ các ghi chú đã

viết

 Giới hạn, cẩn thận chọn

lựa người tham gia

4/23/2014 Trang 18

Các kiểu Review

4/23/2014 Trang 19

Kiểm lại (Desk checking)

Start

Tác giả sẽ gởi tài liệu,

Author

Tự review

source code… cho người cần rà soát

Author

Dựa trên kế hoạch review, thông báo cho reviewers

Reviewer

Review và phát hiện lỗi

Sửa lỗi

Author

Reviewer

Kiểm tra lại

End

Trang 20 4/23/2014

Kiểm lại (Desk checking)

 Desk checking kém hiệu quả hơn quá trình

lần bước (walktrough) và rà soát (inspector) vì không có sự phối hợp làm việc theo nhóm.  Quá trình làm việc theo nhóm thúc đẩy sự

cạnh tranh lành mạnh

 Con người thích phô trương các lỗi mà họ tìm

thấy.

 Trong quá trình desk-checking có thể sẽ

không tìm thấy lỗi nào.

 Tóm lại Desk-checking cũng có giá trị còn hơn là không làm gì cả. Tuy nhiên nó kém hiệu quả hơn walkthrough và inspection.

4/23/2014 Trang 21

Lần bước (Walkthrough)

Walkthrough:

 Tác giả (Author) là

Start

nhân vật trung tâm và là người điều phối buổi họp

Author Planning

Author/Reviewer Walk Through

 Những người tham gia đặt câu hỏi, và ghi chú những lỗi có thể có

Author Rework

Author/Reviewer Follow up

End

4/23/2014 Trang 22

Lần bước (Walkthrough)

 Mục tiêu:

 Giải thích và đánh giá những nội dung trong tài liệu hay source code

 Phát hiện sớm những lỗi

 Thiết lập sự hiểu biết chung mọi người trong

team

 Xem xét và thảo luận những giải pháp được đề nghị cũng như tính khả thi của những giải pháp này

 Thiết lập sự nhất trí trong team

4/23/2014 Trang 23

Rà soát cặp (Peer Review)

Không có quy trình

thực sự, không tài liệu ghi chú, không xác định rõ trách nhiệm

Review có thể tiến hành qua „trao đổi

ngoài lề, lập trình theo cặp

Mục tiêu chính là để kiếm ra lỗi Chưa hữu ích, rẻ, phổ biến

4/23/2014 Trang 24

Thanh tra (Inspection)

Start

Chủ trì

Lên kế hoạch

Nhóm

Họp tổng quan

Chủ trì/Tác giả

Chuẩn bị

Nhóm

Buổi họp rà soát

Defect Log

Buổi họp phân tích nguyên nhân

Những để nghị để cải thiện quy trình

Chủ trì/Tác giả

Làm lại

No

Tiếp tục

Reviewer/Chủ trì/Tác giả

Tất cả lỗi được sửa

End

4/23/2014 Trang 25

Thanh tra (Inspection)

Buổi họp được lên kế hoạch và có cấu

trúc rõ ràng

Có giai đoạn chuẩn bị kỹ càng Vai trò của mọi người trong buổi họp

được phân rõ ràng

Được điều khiển bởi người điều tiết

4/23/2014 Trang 26

Thanh tra (Inspection)

 Scope

 Kích cỡ

 Chỉ nên tập trung vào từng

 Min: 3 (4 nếu tác giả là

phần cụ thể

 130-150 SLOC per hour

người trình bày)

 Thời điểm

 Max: 7 (ít hơn nếu chủ trì có ít kinh nghiệm)

 Không quá sớm  Không quá muộn

 Thời lượng

 Mục tiêu

 Không nhiều hơn 2 giờ

 Không để những lỗi tương tự xuất hiện trong tương lai

 Kết quả

 Nguyên tắc (Rules)

 Không cố gắng giải quyết vấn

để liền

 Tất cả mọi người tham dự

phải chuẩn bị tài liệu kỹ càng

 Tất cả reviewers phải đồng ý trên kết quả  Tất cả các phát hiện phải được lưu trữ lại

4/23/2014 Trang 27

Lỗi thường gặp trong phân tích yêu cầu-thiết kế

 Mập mờ: nghĩa chính xác là gì ?

 VD: Hệ thống nên truy cập đển hệ thống khác

• Hệ thống khác là những hệ thống nào? Phương thức truy

cập? Cấu trúc của dữ liệu truyền nhận?

 Không đầy đủ: Rồi, Còn gì nữa?

 VD: trên 3 lần nhập mật khẩu không đúng, hệ thống

sẽ khóa tài khoản của NSD

• Trong bao lâu? Muốn mở khóa thì sao? Ai có quyền mở

khóa?

 Không kiểm tra được: Tôi có thể kiểm tra phần này

ra sao?  VD: Hệ thống có khả năng sẵn sàng 100%

• ‰Không biết kỹ thuật kiểm tra để biết hoàn toàn sẵn sàng

 Quá phức tạp hay khó hiểu

 Các sơ đồ ‘tồi” và gây khó hiểu

4/23/2014 Trang 28

Danh mục rà soát kế hoạch kiểm thử

Các chức năng chủ yếu có được trình

diễn sớm không?

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

Lịch trình kiểm thử có được xác định rõ

ràng hay không?

Nguồn lực và công cụ kiểm thử đã được

xác định và đã sẵn sàng hay chưa? Đã thiết lập cơ chế lưu trữ báo cáo

chưa?

4/23/2014 Trang 29

Danh mục rà soát kế hoạch kiểm thử

Các thiết bị và các tình huống kiểm thử

đã được minh định chưa?

Công việc phát triển kiểm thử đã được

lập lịch chưa?

Thử nghiệm áp bức cho phần mềm đã

được đặc tả chưa?

Cả hai loại kiểm thử hộp trắng và hộp

đen đã được đặc tả chưa?

4/23/2014 Trang 30

Danh mục rà soát cho việc tạo test case

 Có phải tất cả các đường logic độc lập đều

được kiểm thử?

 Có phải tất cả các ca kiểm thử đều đã được xác định và lập danh sách với đủ các kết qủa mong đợi?

 Việc xử lý sai có được kiểm thử?  Các giá trị biên có được kiểm thử?  Các yêu cầu thời gian có được kiểm thử?  Các biến thể chấp nhận được của kết quả kiểm thử mong đợi đã được đặc tả chưa? 4/23/2014

Trang 31

Danh mục rà soát cho việc kiểm thử giao diện

 Màu nền chung của toàn bộ màn hình  Màu chữ, font, font size  Canh lề  Thông báo trên màn hình có được viết đúng chính tả  Kiểm tra maxlength  Phân biệt chữ hoa / chữ thường  Phân biệt 全角/半角 (toàn giác/bán giác: chỉ áp dụng với Tiếng Nhật, toàn giác thì chữ mập, tròn hơn 2-3bytes; bán giác: chữ ốm 1byte)

 Phân biệt ký tự unicode  Cho phép null hay không  Cho phép nhập ký tự đặc biệt hay không? Kiểm tra format

theo kiểu nào?

 Kiểm tra đối với trường hợp năm nhuần có được tính đúng

không?

 Kiểm tra giá trị 00 và 13 đối với tháng  Kiểm tra giá trị 00 và 32 đối với ngày  Kiểm tra giá trị 28 , 29, 30 -Feb có được tính đúng không?

4/23/2014

Trang 32

Lỗi tiêu biểu phát hiện

Tham chiếu tới biến chưa gán trị Giao tiếp không nhất quán giữa chương

trình và module

Biến chưa bao giờ sử dụng Mã “chết” Vi phạm chuẩn lập trình Yếu điểm bảo mật Vi phạm cú pháp mã và mô hình v..v

4/23/2014 Trang 33

Nội dung

Các phương pháp Testing

 Kiểm thử tĩnh  Kiểm thử động

Các kiểu rà soát (Review)

Phân tích tĩnh

4/23/2014 Trang 34

Phân tích tĩnh

 Phân tích source code để tìm ra những lỗi

mà không cần thực hiện chúng

 Phân tích tĩnh thường đi kèm với những

công cụ hỗ trợ

 Có khá nhiều công cụ hỗ trợ tĩnh, nhưng

phần lớn chúng tập chung vào:  Những tiêu chuẩn code (coding standards)  Cấu trúc luồng điều khiển (control flow

structure)

 Cấu trúc luồng dữ liệu (data flow structure )  Cấu trúc dữ liệu (data structure)

4/23/2014 Trang 35

Những tiêu chuẩn code (coding standards)

Người lập trình viên không chỉ có nhiệm vụ viết code chính xác mà còn phải viết code có chất lượng cao  Dễ đọc, dễ hiểu, có thể sử dụng lại, có thể

bảo trì…

Những tiêu chuẩn code: sẽ lập ra những nguyên tắc (rule) về lập trình để đảm bảo code đạt được những mục đích trên và tránh được những lỗi tiềm ẩn

4/23/2014 Trang 36

Coding standards

 A set of programming rules

 e.g. 'Always check boundaries

on an array when copying to that array'

 Naming conventions

 Variables, global variables, constants, methods, classes,

attributes,...

 Comments

 brief, explain WHY instead of HOW, placement of

comments,...  Layout specifications

 indentation, spacing, blank lines, curly braces,...

 ...  Should use support tools

4/23/2014 Trang 37

Cấu trúc luồng điều khiển

Thể hiện source code dưới dạng đồ thị,

giúp xác định:  Những vòng lặp vô hạn  Những dòng code chết  Những điều kiện đi vào vòng lặp  Độ phức tạp của chương trình

• complexity = number of decisions + 1

4/23/2014 Trang 38

Cấu trúc luồng điều khiển

Hình nào có độ phức tạp cao hơn? 1

5

3

2

4/23/2014 Trang 39

Cấu trúc luồng điều khiển

4/23/2014 Trang 40

Cấu trúc luồng dữ liệu

Tập trung vào sự xuất

hiện của những biến dữ liệu từ lúc nó được khai báo đến khi nó bị hủy, để xác định:

 Biến không bao giờ được sử dụng  Tham khảo đến 1 biến chưa được khai báo  Phép gán không chính xác

4/23/2014 Trang 41

Lợi ích của phân tích tĩnh

Phát hiện lỗi sớm Có những cảnh báo về những lỗi tiềm

ẩn

Xác định những lỗi không dễ dàng phát

hiện trong kiểm tra động

Tăng tính bảo trì (maintainability) của

source code Ngăn ngừa lỗi

4/23/2014 Trang 42

ĐẢM BẢO VÀ KIỂM SOÁT CHẤT LƯỢNG

4/23/2014

43