chapter3

Nội dungTổng quan về lỗi phần mềm Thực hành kiểm thử Kiểm thử tĩnh Tổng quan về thiết kế trường hợp kiểm thử Kỹ thuật kiểm thử 1 2 3 4 5 6 Kiểm thử phần mềm... 1 Lỗi giao diện người dù

KỸ THUẬT KIỂM THỬ

1 Các nguyên lý 2 Vòng đời

4 Kiểm thử chức năng

3 Kỹ thuật kiểm thử

5 Kiểm thử cấu trúc 6 Quản lý chất lượng

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

Nội dung

Tổng quan về lỗi phần mềm

Thực hành kiểm thử

Kiểm thử tĩnh Tổng quan về thiết kế trường hợp kiểm thử

Kỹ thuật kiểm thử

1 2 3

4 5 6

Kiểm thử phần mềm

 Một lỗi phần mềm là sự không trùng khớp giữa chương trình và đặc tả của nó, nếu đặc tả phần mềm tồn tại và được cho là đúng Đặc tả sai  phần mềm sai

 Một lồi phần mềm hiện diện khi chương trình

không làm cái mà người sử dụng đầu cuối mong muốn nó làm.

Lỗi phần mềm (Bug)

1) Lỗi giao diện người dùng - User interface errors

2) Lỗi xử lý - Error handling

3) Lỗi liên quan tới ranh giới/biên - Boundary-related errors

4) Lỗi tính toán - Calculation errors

5) Lỗi các trạng thái đầu và sau - Initial and later states

6) Lỗi luồn kiểm soát - Control flow errors

7) Lỗi trong xử lý hoặc dịch dữ liệu - Errors in handling or interpreting data

8) Tranh đoạt điều khiển - Race conditions

9) Điều kiện tải - Load conditions

10) Phần cứng – Hardware

11) Kiểm soát phiên bản và mã nguồn – Source and version control

12) Tài liệu – Document

13) Các lỗi kiểm thử – Testing errors

Các nhóm lỗi phần mềm phổ biến

 Có nhiều cách để làm cho chương trình làm việc một cách khó khăn,

người ta quy chúng vào một nhóm lỗi có tên là “Lỗi giao diện người dùng”

 Lỗi giao diện người dùng chia thành nhiều nhóm nho

- Functionality: chương trình không làm những thứ như nó nên làm, hoặc làm một cách khổ sở

hay không hoàn chỉnh.

- Communication: Làm thế nào để tìm ra cách sử dụng chương trình? Nó có chính xác không?

Có gì đó nhầm lẫn, sai lệch không?

- Command structure: Có dễ bị lạc trong chương trình không? Có lệnh nào dễ bị nhầm lẫn

không? Có lỗi nào làm bạn lãng phí thời gian không? Vì sao?

- Missing commands: chương trình thiếu lệnh, cứng nhắc và khó điều chỉnh đề phù hợp với

từng đối tượng người sử dụng VD phím tắt

- Performance:chương trình chạy bị chậm hơn mong đợi người dùng

- Output: không có đủ thông tin đầu ra mong muốn VD người sử dụng muốn xuất đầu ra qua

thiết bị đầu cuối, tệp, máy in.

1) User interface errors

 Không lường trước hết các sai sót của chương trình và bảo vệ chương trình trước các sai sót này

 Thiếu thông báo lỗi hoặc điều kiện sinh ra lỗi.

 Giải quyết lỗi được phát hiện không hợp lý

 Vd trong việc bảo vệ chống lại dữ liệu bị corrupt, kiểm tra dữ liệu đầu vào người dùng, kiểm soát phiên bản, bo qua lỗi tràn bộ nhớ, so sánh dữ liệu, không phục lỗi, phục hồi khi có lỗi phần cứng

2) Error handling

 Bất kỳ thành phần nào của chương trình được mô tả có sự xuất hiện của miền giá trị: từ nhiều hơn đến ít hơn, từ lớn nhất tới nho nhất, từ sớm nhất tới muộn nhất, đầu tiên tới cuối cùng, ngắn nhất tới dài nhất đều cần kiểm tra ranh giới miền giá trị Chương trình thường chạy đúng và ổn định với các giá trị nằm trong miền xác định và hay bị gặp lỗi/ sự cố tại các giá trị nằm ngoài biên của miền xác định

 Tìm kiếm lỗi ranh giới: vòng lặp, không gian bộ nhớ, thời gian, xử lý sai các

trường hợp nằm ngoài ranh giới

 VD

- Số lượng sinh viên tối thiểu của 1 lớp tín chỉ là 15 tối đa là 40 sinh viên

- Dung lượng bộ nhớ chiếm dụng của chương trình khi thực thi tối thiểu là 2MB tối đa là 50MB

- …

 Hiểu sai công thức

 Sai số tính toán

 Tính toán sai do sai thuật toán

 Sử dụng sai công thức

 Sử dụng sai kiểu dữ liệu cho công thức tính toán

4) Calculation errors

 Nhiều chương trình chỉ sai ở lần chạy đầu tiên, ở

những lần chạy sau các thông tin khởi tạo đã được lưu trữ lại nên việc chạy chương trình không gặp lại lỗi này nữa.

 Tìm kiếm lỗi: thiết lập chỉ mục dữ liệu bằng không, khởi tạo biến kiểm soát vòng lặp, khởi tạo lại 1 con tro, …

 VD Lỗi do lần đầu chạy file chưa được khởi tạo,

5) Initial and later states

 Luồng kiểm soát của một chương trình miêu tả cái mà chương trình sẽ làm tiếp theo trong những hoàn cảnh cụ thể Lỗi luồng kiểm soát xẩy ra khi chương trình thực hiện sai việc làm tiếp

theo.

 Lỗi này thường xuất hiện do giả định trạng thái trả ra sai, xử lý ngoại lệ dựa trên cách thoát, tràn trên tràn dưới bộ đệm, thất bại trong việc chặn và bo chặn ngắt, các so sánh, lỗi kiểu dữ liệu, thiếu hoặc sai các mặc định - default

 Vd Lỗi luồng kiểm soát xẩy ra do câu lệnh rẽ nhánh.

6) Control flow errors

 Một modun có thể truyền dữ liệu tới modun

hoặc chương trình khác Một tập dữ liệu có thể được truyền đi và nhận lại nhiều lần Trong quá trình này tập dữ liệu có thể bị corrupt (hong)

hoặc dịch sai Những thay đổi cuối cùng tới dữ liệu có thể bị mất hoặc thất lạc tới một vài phần khác của hệ thống.

7) Errors in handling or interpreting data

 Khi làm việc với dữ liệu chia sẻ, dù ở dạng tệp, cơ sở dữ liệu, các kết nối mạng, bộ nhớ dùng chung hay ở những dạng khác của truyền thông liên tiến trình, có một số lỗi dễ tạo ra làm tổn thương tới tính bảo mật của hệ thống, đặc biệt là trong các hệ thống đa xử lý.

 Ví dụ, nếu bạn mở một tệp và sau đó đọc nó, mặc dù ứng dụng của bạn không làm gì giữa hai hoạt động, vài quy trình khác có thể thay thế tệp sau khi tệp đã được mở và trước khi được đọc Nếu hai tiến trình khác nhau (trong cùng hoặc khác ứng dụng) đang ghi lên chung một tệp, sẽ không có cách nào để biết cái nào ghi trước, cái nào sẽ ghi đè lên dữ liệu được ghi bởi tiến trình kia Tình huống này gây ra lỗ hổng về bảo mật

 Chương trình có thể hoạt động sai khi bị quá tải, nó có thể bị lỗi khi chạy trong một thời gian quá dài hoặc thực thi

quá trọng tải cho phép, chiếm dụng quá vùng nhớ cho

phép, thất bại khi cố chia sẻ vùng nhớ hoặc thời gian sử dụng CPU với chương trình khác hoặc giữa hai tiến trình con của nó

 Ghi nhớ rằng tất cả mọi chương trình đều có giới hạn Vấn

đề là nó có đáp ứng được các giới hạn đã đề ra hoặc cách

xử lý thất bại khi vượt quá giới hạn cho phép

9) Load conditions

 Vd chương trình gửi dữ liệu tới các thiết bị rồì

lờ đi các mã lỗi phản hồi lại, và cố gắng sử dụng thiết bị phần cứng đang bận hoặc không tồn tại gây ra lỗi về phần cứng.

 Hoặc trong trường hợp khác, nếu phần cứng

hong, phần mềm cũng bị hong nếu nó không

nhận ra và khôi phục lại từ phần cứng hong.

 Cần kiểm soát phiên bản và toàn vẹn mã

nguồn, tránh trường hợp kiểm thử đi kiểm thử lại một phần mã nguồn phiên bản cũ

 QA đưa ra những quy định chặt chẽ về toàn

vẹn mã nguồn và kiểm soát phiên bản mã

 Các tài liệu cũng là một phần của sản phẩm phần mềm Tài liệu nghèo nàn, kém chất

lượng có thể làm người sử dụng tin là sản

phẩm làm việc không chính xác

 Các lỗi được tạo ra bởi kiểm thử viên là một trong các lỗi phổ biến nhất được pha kiểm thử, chẳng qua là do người kiểm thử không báo cáo lại chi

tiết các ca kiểm thử đó Nhưng kiểm thử viên nên ghi nhớ một số lỗi trong những lỗi bạn mắc phải khi sử dụng chương trình hoặc việc bạn gặp quá nhiều lỗi kiểm thử khi kiểm thử có thể phản ánh các vấn đề trong giao diện người sử dụng  đây có thể tiềm ẩn lỗi trong thiết kế Khi đó các lỗi của bạn chính là các dữ liệu kiểm thử cho chương

trình

13) Testing errors

 Khi có lỗi/ vấn đề được tìm thấy qua hoạt động kiểm thử, nó cần được báo cáo lại một cách rõ ràng, dễ hiểu để người khác có thể đọc và fix nó  viết bug report

 Làm thế nào để viết bug report hiệu quả

- Mô tả làm thế nào để sinh ra vấn đề Các lập trình viên bỏ qua các

báo cáo của các vấn đề mà bản thân họ không thể nhìn thấy

- Phân tích lỗi để có thể miêu tả nó bên trong một số lượng bước tối

thiểu, bỏ qua các bước không cần thiết

- Viết một báo cáo hoàn chỉnh, dễ hiểu sao cho lập trình viên không bị

hiểu lầm hay bực mình

- Viết báo cáo ngay khi nhìn thấy

Vòng đời của bug và nội dung bug

report

Vòng đời

của bug

 Program, release, version:

thông tin về chương trình,

phiên bản code hay bản

 Attachment- tài liệu đính

kèm: print out, memory

dump, memo describing,…

Nội dung của bug

report

 Bó buộc mạnh bạo

Cách tiếp cận gỡ lỗi

Bó buộc mạnh bạo

 Phương pháp thông dụng nhất và kém hiệu quả nhất để cô lập nguyên nhân của lỗi phần mềm.

 Áp dụng phương pháp gỡ lỗi bó buộc mạnh bạo khi tất cả các phương pháp khác đều thất bại

 Triết lý “cứ để máy tính tìm ra lỗi”, cho xổ ra nội dung bộ nhớ, gọi tới chương trình lưu dấu vết khi chạy và nạp chương trình với lệnh WRITE Hy vọng tr tìm ra được nguyên nhân trong

lượng lớn thông tin đưa ra

 VẤN ĐỀ: chương trình có lỗi nhưng kết quả cuối cùng có thể không lỗi

 Có thể lãng phí thời gian và công sức

Lật ngược

 Cách tiếp cận khá thông dụng có thể được

dùng trong những chương trình nho

 Bắt đầu tại chỗ chúng được phát hiện ra, lật ngược theo những chương trình gốc (một

cách thủ công) cho tới chỗ tìm ra nguyên

nhân

 VẤN ĐỀ: chương trình gốc lớn, số con đường lật ngược nhiều

Loại bỏ nguyên nhân

 Quy nạp hay diễn dịch và đưa vào khái niệm về phân

hoạch nhị phân

 Dữ liệu có liên quan tới việc xuất hiện lỗi được tổ chức để

cô lập ra các nguyên nhân tiềm năng

 Một “giả thiết nguyên nhân” được nêu ra và dữ liệu trên được dùng để chứng minh hay bác bo giả thiết đó

 Một cách khác, xây dựng ra một danh sách mọi nguyên nhân đặc biệt có nhiều hứa hẹn thì dữ liệu sẽ được làm mịn thêm để cố gắng cô lập ra lỗi

Nội dung

Tổng quan về lỗi phần mềm

Thực hành kiểm thử

Kiểm thử tĩnh Tổng quan về thiết kế trường hợp kiểm thử

Kỹ thuật kiểm thử

1 2 3

4 5 6

Kiểm thử phần mềm

Vai trò con người trong việc kiểm thử

Quy trình kiểm thử tổng quát

Thiết kế trường hợp kiểm thử dựa

trên các yêu cầu:

 Các trường hợp thử nghiệm được thiết kế để kiểm thử các yêu cầu hệ thống

 Được sử dụng trong hầu hết các bước kiểm thử hệ thống bởi vì các yêu cầu hệ thống

thường được thực hiện bởi một vài thành

phần

 Với mỗi yêu cầu, xác định các trường hợp thử nghiệm để có thể chứng to được hệ thống có yêu cầu đó

Thiết kế kiểm thử dựa trên phân

hoạch

 Xác định các phân hoạch đầu vào và phân hoạch đầu ra và thiết kể thử nghiệm

 Hệ thống thực hiện với đầu vào từ tất cả các

phân hoạch và sinh ra đầu ra trong tất cả các

phân hoạch

 Các phân hoạch là các nhóm dữ liệu có chung đặc tính như tất cả các số đều âm, tất cả tên đều có đều có độ dài nho hơn 30 ký tự, tất cả các sự kiện phát sinh từ việc chọn các mục trên thực

đơn…

Thiết kế kiểm thử dựa trên cấu trúc

 Sử dụng những hiểu biết về cấu trúc chương trình để thiết kế các thử nghiệm thực hiện tất

cả các phần của chương trình

 Nên kiểm tra thực thi mỗi câu lệnh ít nhất một lần

 Kiểm thử cấu trúc giúp cho việc xác định các trường hợp thử nghiệm.

Các phương pháp kiểm thử

 Phân loại dựa vào việc chạy chương trình:

kiểm thử tĩnh là các kỹ thuật đánh giá, định

hướng kiểm tra các tài liệu và mã nguồn mà không cần chạy chương trình Kiểm thử động

là phương pháp thông qua việc chạy chương trình để kiểm tra đánh giá

 Phân loại theo cách tiếp cận hộp: kiểm thử

hộp trắng và kiểm thử hộp đen, kiểm thử hộp xám

Các kỹ thuật kiểm thử

Kiểm thử tĩnh (Không thực thi chương trình)

• Danh sách các kiểm tra tài liệu, đặc tả,

mã nguồn, vv

Kiểm thử chức năng (Hộp đen)

• Dựa trên hành vi/ chức năng phần mềm

Kiểm thử cấu trúc (Hộp trắng)

• Dựa trên cấu trúc phần mềm

Một vài kỹ thuật kiểm thử

Structural

Behavioural

Functional Non-functional

Reviews

Walkthroughs

Desk-checking

Data Flow

Data Flow

Arcs

Equivalence Partitioning

Equivalence Partitioning

Boundary Value Analysis

Boundary Value Analysis

Cause-Effect Graphing Random

Usability Performance

Static Analysis Inspection

Control Flow

Control Flow

Phương pháp kiểm thử tĩnh

 Xem xét đặc tả

 Xem xét mã nguồn

Duyệt đặc tả mức cao

 Duyệt đặc tả mức cao

- Quan sát ở mức tổng thể

- Đóng vai người khách hàng

• Hiểu xem họ thực sự cần gì

• Khách hàng không nói những gì là hiển nhiên

– Ví dụ: an ninh, dễ sử dụng, v.v.

- Đối chiếu với đặc tả

• Làm rõ những gì mình không hiểu

– Không hiểu được là lỗi của đặc tả

Duyệt đặc tả mức cao

 Đối chiếu chuẩn mực hiện hành

- Thuật ngữ, qui ước

- Chuẩn mực quốc tế,

- Chuẩn do địa phương ban hành

- Chuẩn về an ninh

- Chuẩn về dễ sử dụng

-

Duyệt đặc tả mức cao

 So sánh với các sản phẩm cạnh tranh

- Chức năng

- Công nghệ

- Đơn giản, dễ sử dụng

- An ninh, bảo mật

- Độ tin cậy

-

- Ngôn ngữ diễn đạt

- Tính khả kiểm thử

Khảo sát mã nguồn

 Phản biện hình thức

 Ích lợi

Phản biện chéo

 Kiểm tra lẫn nhau, phi hình thức

 Qui trình tương tự phản biện hình thức,

nhưng đơn giản hóa bớt

- Tác giả trình bày cho một nhóm nhỏ (5 lập trình,

kiểm thử viên khác) đã xem mã nguồn trước

 Thanh tra

- Người trình bày không phải là tác giả nói và nhận

xét về mã nguồn, những người khác cũng phản biện

 Đảm bảo tính nhất quán, dễ hiểu của mã

nguồn do nhiều người cùng viết, sửa

Danh sách kiểm tra mã nguồn

 Kiểm tra theo danh sách để không bo sót

- Lỗi tham chiếu dữ liệu

- Lỗi mô tả dữ liệu

- Lỗi tính toán

- Lỗi điều khiển

- Lỗi truyền tham số

-

Ví dụ danh sách kiểm tra

 Structure

- ❏ ❏ Does the code completely and correctly implement the design?

- ❏ ❏ Does the code conform to any pertinent coding standards?

- ❏ ❏ Is the code well-structured, consistent in style, and consistently formatted?

- ❏ ❏ Are there any uncalled or unneeded procedures or any unreachable code?

- ❏ ❏ Are there any leftover stubs or test routines in the code?

- ❏ ❏ Can any code be replaced by calls to external reusable components or library functions?

- ❏ ❏ Are there any blocks of repeated code that could be condensed into a single procedure?

- ❏ ❏ Is storage use efficient?

- ❏ ❏ Are symbolic used rather than “magic number” constants or string constants?

- ❏ ❏ Are any modules excessively complex and should be restructured or split into multiple routines?

Ví dụ danh sách kiểm tra

- ❏ ❏ Do all assigned variables have proper type consistency or casting?

- ❏ ❏ Are there any redundant or unused variables?

 Arithmetic Operations

- ❏ ❏ Does the code avoid comparing floating-point numbers for equality?

- ❏ ❏ Does the code systematically prevent rounding errors?

- ❏ ❏ Does the code avoid additions and subtractions on numbers with greatly different magnitudes?

- ❏ ❏ Are divisors tested for zero or noise?

Ví dụ danh sách kiểm tra

 Loops and Branches

- ❏ ❏ Are all loops, branches, and logic constructs complete, correct, and properly nested?

- ❏ ❏ Are the most common cases tested first in IF- -ELSEIF chains?

- ❏ ❏ Are all cases covered in an IF- -ELSEIF or CASE block, including ELSE or DEFAULT clauses?

- ❏ ❏ Does every case statement have a default?

- ❏ ❏ Are loop termination conditions obvious and invariably achievable?

- ❏ ❏ Are indexes or subscripts properly initialized, just prior to the loop?

- ❏ ❏ Can any statements that are enclosed within loops be placed outside the loops?

- ❏ ❏ Does the code in the loop avoid manipulating the index variable or using it upon exit from the loop?