Bài giảng Kiểm thử phần mềm Bài 2

PHƯƠNG PHÁP KIỂM THỬ Testing methods  Kiểm thử hộp trắng White Box Testing: Trong kiểm thử hộp màu trắng, cấu trúc mã hoặc thuật toán của chương trình được đưa vào xem xét.. KIỂM THỬ H

BÀI GIẢNG KIỂM THỬ PHẦN MỀM

BÀI 2:

I Phương pháp kiểm thử ( Testing Methods)

II Các giai đoạn kiểm thử (Testing Levels)

III Quy trình kiểm thử (Testing Process)

PHƯƠNG PHÁP KIỂM THỬ (Testing methods)

 Phân vùng tương đương (Equivalence partitioning)

 Phân tích giá trị biên (Boundary value analysis)

 Vẽ Đồ Thị Nguyên Nhân Kết Quả (Cause-effect Graphing)

 Đoán lỗi – Error Guessing

PHƯƠNG PHÁP KIỂM THỬ (Testing methods)

 Kiểm thử hộp trắng (White Box Testing):

Trong kiểm thử hộp màu trắng, cấu trúc mã hoặc thuật toán của chương trình được đưa vào xem xét Các trường hợp kiểm thử được thiết kế dựa vào cấu trúc mã hoặc cách thức làm việc của chương trình Người kiểm thử truy cập vào mã nguồn chương trình và có thể kiểm tra nó, lấy đó làm cơ sở để hỗ trợ việc kiểm thử

 Kiểm thử hộp đen ( Black Box Testing):

Trong khi đó kiểm thử hộp đen không yêu cầu kỹ sư kiểm thử cần phải có bất kỳ kiến thức

về mã hoặc thuật toán của chương trình Nó kiểm tra các chức năng của hệ thống tức là những gì hệ thống được cho là cần phải làm dựa trên các Đặc tả yêu cầu Các trường hợp kiểm thử thường được xây dựng xung quanh đó

Có 2 phương pháp:

KIỂM THỬ HỘP ĐEN (Black Box Testing)

 Là phương pháp test dựa trên đầu vào và đầu ra của chương trình để test mà không quan tâm tới code bên trong được viết ra sao Tester xem phần mềm như là một hộp đen

 Trong khi đó kiểm thử hộp đen không yêu cầu kỹ sư kiểm thử cần phải có bất

kỳ kiến thức về mã hoặc thuật toán của chương trình Nó kiểm tra các chức năng của hệ thống tức là những gì hệ thống được cho là cần phải làm dựa trên các Đặc tả yêu cầu Các trường hợp kiểm thử thường được xây dựng

xung quanh đó

Phân vùng tương đương(Equivalence partitioning)

 Chia (partition) đầu vào thành những nhóm tương đương nhau (equivalence) Nếu một giá trị trong nhóm hoạt động đúng thì tất cả các giá trị trong nhóm

đó cũng hoạt động đúng và ngược lại

 — Mục đích : Giảm đáng kể số lượng test case cần phải thiết kế vì với mỗi

lớp tương đương ta chỉ cần test trên các phần tử đại diện

Thiết kế Test-case bằng phân lớp tương đương tiến hành theo 2 bước:

(1) Xác định các lớp tương đương (2) Xác định các ca kiểm thử

Phân vùng tương đương(Equivalence partitioning)

 Nguyên tắc:

 1 lớp các giá trị lớn hơn

 1 lớp các giá trị nhỏ hơn

 n lớp các giá trị hợp lệ

 Bảng liệt kê các lớp tương đương

Điều kiện vào/ ra Các lớp tương đương

hợp lệ

Các lớp tương không

hợp lệ

Phân vùng tương đương(Equivalence partitioning)

Ví dụ minh họa:

cầu dưới đây:

+ Zip Code : 5 chữ số

Phân vùng tương đương(Equivalence partitioning)

Bài làm:

1 Ký tự số:

+ Không nhập ký tự nào + Nhập < 5 ký tự

+ Nhập 5 ký tự + Nhập> 5 ký tự

2 Ký tự chữ

3 Ký tự đặc biệt Điều kiện đầu vào yêu cầu một giá trị xác định, phân hoạch thành một

lớp tương đương hợp lệ và hai lớp tương đương không hợp lệ Chẳng hạn,

nếu đầu vào x=5 (x là Zip code), thì lớp hợp lệ là x= 5, các lớp không hợp lệ là

x <5 và x >5

Phân vùng tương đương(Equivalence partitioning)

Phân tích giá trị biên (Boundary value analysis)

 Đây là phương pháp test mà chúng ta sẽ test tất cả các giá trị ở vùng biên của dữ liệu vào và dữ liệu ra Chúng ta sẽ tập trung vào các giá trị biên chứ không test toàn bộ dữ liệu Thay vì chọn nhiều giá trị trong lớp đương tương

để làm đại diện, phân tích giá trị biên yêu cầu chọn một hoặc vài giá trị là các cạnh của lớp tương đương để làm điều kiện test

 — “Test các giá trị biên” chúng ta chỉ test các phần sau:Bất kỳ một cách chọn thực hiện trong phương pháp “Giá trị biên” ta có thể sử dụng được tốt Thay

vì ta phải test toàn bộ vùng cần test ta có thể test 6 hoặc 4 case và vẫn đảm

bảo là hệ thống hoạt động tốt Boundary conditions là các vị trí ở giữa,

trên và dưới các biên của lớp tương đương

 Một số điểm cần lưu ý khi dùng phương pháp này:

 Luôn test trường hợp “0” nếu nó nằm trong vùng kiểm tra và một vài trường hợp nếu nó nằm ngoài vùng bởi vì 0 là giá trị khá đặc biệt

Phân tích giá trị biên (Boundary value analysis)

 Luôn test các chuỗi rỗng nếu nó nằm trong vùng test và ngay cả khi nó không nằm trong vùng test

 Phân tích giá trị biên là kỹ thuật thiết kế test case và hoàn thành phân vùng tương đương

 Mục tiêu là lựa chọn các test case để thực thi giá trị biên

 Phân tích giá trị biên sẽ chọn các giá trị:

Phân tích giá trị biên (Boundary value analysis)

Ví dụ minh họa:

Cho một mảng [ -3 , 10], ta có giá trị biên là:

+ Giá trị nhỏ nhất: -3 + Giá trị lớn nhất: 10 + Giá trị nhỏ hơn giá trị nhỏ nhất: -4 + Giá trị lớn hơn giá trị lớn nhất: 11 + Giá trị nằm trong -3 và 10: 0

Đây là phương pháp test mà chúng ta sẽ test tất cả các giá trị ở vùng biên của dữ liệu vào

và dữ liệu ra Chúng ta sẽ tập trung vào các giá trị biên chứ không test toàn bộ dữ liệu

Đồ thị Nguyên nhân - Kết quả(Cause & Effect Graphing)

 Một điểm yếu của hai phương pháp trên là chúng không khảo sát sự kết hợp của các trường hợp đầu vào Việc kiểm tra sự kết hợp đầu vào không phải là một

nhiệm vụ đơn giản bởi vì nếu bạn phân lớp tương đương các trạng thái đầu vào, thì số lượng sự kết hợp thường là rất lớn

 Đồ thị nhân - quả sử dụng mô hình các quan hệ logic giữa nguyên nhân và kết

quả cho thành phần phần mềm Mỗi nguyên nhân được biểu diễn như một điều kiện (đúng hoặc sai) của một đầu vào, hoặc kết hợp các đầu vào Mỗi kết quả

được biểu diễn như là một biểu thức Bool biểu diễn một kết quả tương ứng cho những thành phần vừa thực hiện

Đồ thị Nguyên nhân - Kết quả(Cause & Effect Graphing)

 Kỹ thuật gồm có 4 bước:

 Xác định điều kiện vào và hành động cho mỗi module cần kiểm định

 —Xác định đồ thị nguyên nhân – kết quả

 Đồ thị được chuyển thành bảng quyết định

 —Những phần trong bảng quyết định được chuyển thành test case

Đồ thị Nguyên nhân - Kết quả(Cause & Effect Graphing)

Ví dụ minh họa:

 Trên màn hình đăng nhập, có 2 thông tin cần đưa vào là Tên đăng nhập và mật khẩu, chỉ thực hiện đăng nhập thành công nếu nhập đúng cả Tên đăng nhập và mật khẩu, các trường hợp còn lại sẽ hiển thị thông báo “Nhập không chính xác, yêu cầu nhập lại”

Đồ thị Nguyên nhân - Kết quả(Cause & Effect Graphing)

Đoán Lỗi ( Error Guessing)

 — Một kỹ thuật thiết kế test-case khác là error guessing – đoán lỗi Tester được đưa cho 1 chương trình đặc biệt, họ phỏng đoán, cả bằng trực giác và kinh nghiệm, các loại lỗi có thể và sau đó viết các ca kiểm thử để đưa ra các lỗi

đó

 Thật khó để đưa ra một quy trình cho kỹ thuật đoán lỗi vì nó là một quy trình

có tính trực giác cao và không thể dự đoán trước Ý tưởng cơ bản là liệt kê một danh sách các lỗi có thể hay các trường hợp dễ xảy ra lỗi và sau đó viết các ca kiểm thử dựa trên danh sách đó.Nói cách khác, bạn liệt kê những

trường hợp đặc biệt đó mà có thể đã bị bỏ sót khi chương trình được thiết kế

Sự giống nhau giữa Kiểm thử Hộp trắng và Hộp đen

 Hai loại hình kiểm thử đều nhằm mục đích là kiểm định lại phần mềm nhằm

loại bỏ những lỗi và những gì thiếu trong quá trình làm phần mềm nhằm mục

đích là đem lại một sản phẩm tốt đến khách hàng

 Kiểm thử hộp trắng: Kiểm thử hộp trắng là phương pháp kiểm thử dựa vào

cấu trúc/mã lệnh chương trình Phương pháp kiểm thử hộp trắng kiểm thử một

chương trình (một phần chương trình, hay một hệ thống, một phần của hệ

thống) đáp ứng tốt tất cả các giá trị input bao gồm các giá trị không đúng hay

không theo dự định của chương trình

 Phương pháp dựa trên:

o Data flow testing

o Branch testing

o Statement testing (các câu lệnh)

o Path testing (đường dẫn)

o

Sự giống nhau giữa Kiểm thử Hộp trắng và Hộp đen

 Kiểm thử hộp đen:

Kiểm thử hộp đen hay còn gọi là kiểm thử chức năng, việc kiểm nghiệm này được thực hiện mà không cần quan tâm đến các thiết kế và viết mã của chương trình Kiểm thử theo cách này chỉ quan tâm đến chức năng đã đề ra của chương trình Vì vậy kiểm thử loại này chỉ dựa vào bản mô tả chức năng của chương trình, xem chương trình có thực sự cung cấp đúng chức năng đã

mô tả trong bản chức năng hay không mà thôi

Phương pháp dựa trên:

- Chức năng thiếu hoặc không đúng đắn

- Sai về giao diện

- Sai trong cấu trúc hoặc trong truy cập dữ liệu ngoài

- Sai thực thi chức năng Tùy vào từng giai đoạn trong quá trình phát triển phần mềm sẽ dùng các loại kiểm thử thích hợp

CÁC GIAI ĐOẠN KIỂM THỬ (Testing levels)

Có 4 mức độ kiểm thử:

1 UnitTesting : test ở mức cơ bản, test từng module nhỏ trong hệ thống do lập trình

viên thực hiện Là kiểu white box testing

Mục đích: để xác nhận rằng mỗi thành phần của phần mềm thực hiện đúng với thiết kế

2 Integration Testing: test ở mức tích hợp (tích hợp các hàm lại với nhau, tích hợp

các màn hình lại với nhau theo từng module hay dựa theo chức năng) do tester thực hiện

Mục đích: mục đích để tìm ra lỗi trong quá trình tích hợp các thành phần , module lại với nhau

CÁC GIAI ĐOẠN KIỂM THỬ (Testing levels)

3 System Testing: test ở mức hệ thống (tích hợp toàn bộ các hàm, các chức năng

thành một phần mềm, module hoàn chỉnh)

Mục đích: để đánh giá hệ thống tuân thủ đúng với đặc tả yêu cầu

4 Acceptance Testing: mức test này giống như system test nhưng thường được

khách hàng thực hiện test, mục đích là xem phần mềm có đáp ứng đúng yêu cầu của khách hàng chưa

Mục đích: để đánh giá hệ thống tuân thủ đúng với yêu cầu của khách hàng và có thể chấp nhận hay không chấp nhận để bàn giao sản phẩm

Và trong kiểm thử chấp nhận chia ra làm hai loại:

CÁC GIAI ĐOẠN KIỂM THỬ (Testing levels)

 Apha: là việc kiểm thử hoạt động chức năng thực tế hoặc giả lập do người dùng/khách

hàng tiềm năng hoặc một nhóm test độc lập thực hiện tại nơi sản xuất phần mềm

Alpha testing thường dùng cho phần mềm đóng gói sẵn để bán (ví dụ như MS office, window, chương trình diệt virus) là một hình thức kiểm thử chấp nhận nội bộ, trước khi phần mềm được tiến hành kiểm thử beta

 Beta: được thực hiện sau alpha testing Các phiên bản của phần mềm - được biết như

là các phiên bản beta – chúng được phát hành tới một số lượng giới hạn khán giả bên ngoài nhóm sản xuất phần mềm Sản phẩm được phát hành đến một số nhóm người

để test nhiều hơn nữa có thể chắc chắn rằng sản phẩm có một số bug Thỉnh thoảng, các phiên bản beta được phát hành rộng rãi để tăng phạm vi phản hồi từ một lượng người sử dụng tương lai lớn nhất

QUY TRÌNH KIỂM THỬ (Testing process)

 Software Testing Process

SOFTWARE TESTING là gì?

 Software testing là một cuộc kiểm tra nhằm cung cấp cho các bên liên quan (khách hàng hay nhóm phát triển phần mềm, ) thông tin về chất lượng của sản phẩm hoặc dịch vụ đang kiểm thử (under test)

 Software testing cũng cung cấp mục tiêu, cái nhìn độc lập về phần mềm, điều này cho phép việc đánh giá và hiểu rõ các rủi ro khi thực thi phần mềm Các kỹ thuật kiểm thử bao gồm, nhưng không giới hạn, trong quy trình thực thi

chương trình hoặc ứng dụng với mục đích tìm kiếm bug (lỗi, khiếm

khuyết/nhược điểm)

 Software testing cũng có thể xem như là quá trình thẩm định và thẩm tra

(validating and verifying) phần mềm/chương trình/ứng dụng/sản phẩm để:

 Đáp ứng được các yêu cầu công việc và kỹ thuật đã được quy định trong thiết kế

và trong lúc phát triển

 Làm việc như mong đợi

SOFTWARE PROCESS là gì?

TEST PLAN là gì?

 Một kế hoạch kiểm thử dự án phần mềm (test plan) là một tài liệu mô tả các mục tiêu, phạm vi, phương pháp tiếp cận, và tập trung vào nỗ lực kiểm thử phần mềm Quá trình chuẩn bị test plan là một cách hữu ích để suy nghĩ tới những nỗ lực cần thiết để xác nhận khả năng chấp nhận một sản phẩm phần mềm

 Cấu trúc chung của một test plan:

Tên project Danh sách các Module cần test Ngày bắt đầu, ngày kết thúc Danh sách các Test case Nhân sự tham gia

Tài nguyên sử dụng (Servers, Workstations, Printers,…)

Kế hoạch thực hiện (sử dụng Ms Project lập kế hoạch)…

 Xem biểu mẫu Test Plan

TEST CASE là gì?

 Test case mô tả một dữ liệu đầu vào (input), hành động (action) và một kết quả mong đợi (expected response), để xác định một chức năng của ứng dụng phần mềm hoạt động đúng hay không

 Một test case có thể có các phần đặc thù khác nhau như mã test case, tên test case, mục tiêu test, các điều kiện test, các yêu cầu data input, các bước thực hiện và các kết quả mong đợi Mức chi tiết có thể được định nghĩa khác nhau dựa vào quy mô của dự án hay quy mô của công ty sản xuất phần mềm

 Quá trình phát triển test case có thể giúp tìm ra lỗi trong các yêu cầu hoặc thiết

kế của ứng dụng, vì nó đòi hỏi phải tư duy hoàn toàn thông qua các hoạt động của ứng dụng Vì lý do này, việc chuẩn bị test case sớm nhất có thể trong qui trình phát triển phần mềm là rất hữu ích

TEST CASE là gì?

 Nó bao gồm 3 bước cơ bản :

- Mô tả : đặc tả các điều kiện cần cố để tiến hành kiểm tra

- Nhập : đặc tả đối tượng hoặc dữ liệu cần thiết, được sử dụng làm đầu vào để thực hiện kiểm tra

- Kết quả mong chờ : kết quả trả về từ đối tượng kiểm tra

 Biểu mẫu Testcase:

TESTING EXECUTION là gì?

 Thực hiện test trực tiếp trên ứng dụng phần mềm sau khi lập trình viên bàn giao

 Dựa trên các test cases đã được viết trước đó để thực hiện test trên phần mềm

 Thực hiện ghi nhận kết quả kiểm thử vào cột kết quả của tài liệu kịch bản kiểm thử Nếu kết quả kiểm thử là thất bại thì nhóm kiểm thử ghi nhận lỗi lên hệ thống quản lý lỗi

 Nhóm kiểm thử, QTDA, nhóm lập trình, nhóm giải pháp tham gia vào quá trình quản lý/xử lý lỗi ( bug/ defect)

TESTING EXECUTION là gì?

 Thực hiện test trực tiếp trên ứng dụng phần mềm sau khi lập trình viên bàn giao

 Dựa trên các test cases đã được viết trước đó để thực hiện test trên phần mềm

 Thực hiện ghi nhận kết quả kiểm thử vào cột kết quả của tài liệu kịch bản kiểm thử Nếu kết quả kiểm thử là thất bại thì nhóm kiểm thử ghi nhận lỗi lên hệ thống quản lý lỗi

 Nhóm kiểm thử, QTDA, nhóm lập trình, nhóm giải pháp tham gia vào quá trình quản lý/xử lý lỗi ( bug/ defect)

Question & Answer?

Bài 3: Nội dung buổi học tuần sau:

Biểu mẫu testcases

Khái niệm và cấu trúc của testcases

Hướng dẫn cách viết testcases Bài tập

Lỗi phần mềm là gì ? (Defect/Bug)

Khái niệm (Concept) Bug Priority, Bug Severity Bug Report

Quy trình log và closed Bug ( Defect life cycle)

Re-test khác Regression test thế nào?