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

 Phân tích và tìm hiểu tài liệu Đặc tả yêu cầu phần mềm  Tham gia vào chuẩn bị/ lập Test plans  Thực hiện viết test design, test cases kịch bản kiểm thử  Thực hiện test test exec

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

BÀI 1:

I Các khái niệm, định nghĩa về Software Testing

II Các quy trình Sản xuất Phần mềm

SOFTWARE TESTING ?

 What is Software Testing?

 Why is Testing important?

 What is the objective of Software Testing?

 Who do testing?

 Responsibilities of software tester?

khi phát triển phần mềm ngay từ ban đầu, chứ không đơn thuần chỉ là việc tìm

những lỗi sẵn có khi nhóm phát triển đã đưa ra những phiên bản cụ thể của

phần mềm

 Kiểm thử phần mềm đảm bảo sản phẩm phần mềm đáp ứng chính xác, đầy đủ

và đúng theo yêu cầu của khách hàng, yêu cầu của sản phẩm đề đã đặt ra

 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

 Kiểm thử phần mềm tạo điều kiện cho bạn tận dụng tối đa tư duy đánh giá và

sáng tạo để bạn có thể phát hiện ra những điểm mà người khác chưa nhìn thấy

“It is also said to be an art to improve the quality of the software made.”

Tại sao SOFTWARE TESTING quan trọng?

 Kiểm thử phần mềm là một hoạt động giữ vai trò rất quan trọng để bảo đảm chất lượng phần mềm và là hoạt động mang tính sống còn trong các dự án sản xuất hoặc gia công phần mềm Vì vậy, kiểm thử phần mềm đã trở thành qui trình bắt buộc trong các dự án phát triển phần mềm trên thế giới

 Làm gì cũng cần kiểm tra, đánh giá thì mới biết được liệu nó có đạt được những gì được mong đợi, có sai sót gì không

 Kiểm thử phần mềm để tránh được những rủi ro, lỗi phát sinh trong suốt quá trình tạo ra sản phẩm Lỗi phát hiện càng sớm càng giúp tránh được rủi ro và chi phí

Mục tiêu của SOFTWARE TESTING ?

 Để kiểm tra xem phần mềm đáp ứng nhu cầu của khách hàng và phù hợp với các đặc

tả và đảm bảo chất lượng và tính chính xác của ứng dụng

 Nó thật sự có làm việc như mong muốn?

 Nó làm được gì mà người sử dụng mong đợi?

 Tiết kiệm thời gian và chi phí bởi xác định/ tìm kiếm những thiếu sót/ lỗi sớm

 Biết rằng chúng ta đã thỏa mãn được những yêu cầu của khách hàng

“The main objective of software testing is to maintain and deliver a quality product to

the client.”

Who do SOFTWARE TESTING ?

 Có nhiều đối tượng có thể tham gia vào kiểm thử:

Trách nhiệm của tester?

 Phân tích và tìm hiểu tài liệu Đặc tả yêu cầu phần mềm

 Tham gia vào chuẩn bị/ lập Test plans

 Thực hiện viết test design, test cases (kịch bản kiểm thử)

 Thực hiện test ( test execution)

 Theo dõi kết quả test

 Báo cáo kiểm thử ( test report)

 Giao tiếp với đội phát triển, khách hàng

 Các bài học rút ra để cải thiện chất lượng của ứng dụng

Các Mô hình phát triển Phần mềm

( Software Life Cycle - SLC )

Một số mô hình SLC phổ biến trên thế giới:

Software Life Cycle là gì?

 Một trong những kiến thức cần thiết của một kỹ sư kiểm thử phần mềm chuyên

nghiệp đó là hiểu biết và nắm rõ SDLC (Software Development Life-cycle/chu kỳ phát triển phần mềm), bởi vì kiểm thử phần mềm (software testing) là 1 phần và liên quan chặt chẽ, mật thiết đến SDLC

 Quy trình là một trong những yếu tố cực kỳ quan trọng đem lại sự thành công cho các nhà sản xuất phần mềm, nó giúp cho mọi thành viên trong dự án từ người cũ đến người mới, trong hay ngoài công ty đều có thể xử lý đồng bộ công việc tương ứng vị trí của mình thông qua cách thức chung của công ty, hay ít nhất ở cấp độ dự án

Software Life Cycle là gì?

 Vai trò kiểm thử trong suốt quy trình của phần mềm

 Kiểm thử không tồn tại độc lập

 Các hoạt động của kiểm thử luôn gắn liền với các hoạt động phát triển phần mềm

 Các mô hình phát triển phần mềm khác nhau cần các cách tiếp cận test khác nhau

Software Life Cycle là gì?

STT Giai đoạn Công việc Đầu ra

1 Giải pháp/

Yêu cầu Thực hiện khảo sát chi tiết yêu cầu khách hàng và tổng hợp vào tài liệu Giải pháp (Phân tích nghiệp vụ, Phân tích yêu

cầu, Đặc tả yêu cầu, Prototype)

Tài liệu giải pháp phải mô tả đầy đủ các yêu cầu về chức

năng, phi chức năng, giao diện

Tài liệu Đặc tả yêu cầu Prototype

2 Thiết kế Thực hiện thiết kế và tổng hợp vào tài liệu Thiết kế (Thiết kế

tổng thể, thiết kế CSDL, Thiết kế chi tiết) Thiết kế tổng thể, thiết kế

CSDL, Thiết kế chi tiết

3 Lập trình Lập trình viên thực hiện lập trình theo tài liệu Giải pháp và

Thiết kế đã được phê duyệt Source code

4 Kiểm thử CBKT tạo kịch bản kiểm thử theo tài liệu giải pháp

Thực hiện kiểm thử Cập nhật kết quả vào KBKT, lỗi được log đầy đủ Tester và Developer phối hợp xử lý các lỗi và cập nhật trên

Hệ thống quản lý lỗi

Testcases Lỗi trên Hệ thống quản lý lỗi

5 Triển khai Triển khai sản phẩm cho Khách hàng Biên bản triển khai với

khách hàng

Mô hình thác nước – Waterfall

Mô hình này bao gồm các giai đoạn xử lý nối tiếp nhau như sau:

 Phân tích yêu cầu và tài liệu đặc tả (Requirements and Specifications): là giai

đoạn xác định những Yêu cầu liên quan đến chức năng và phi chức năng mà hệ thống phần mềm cần có Giai đoạn này cần sự tham gia tích cực của khách hàng và kết thúc bằng một tài liệu được gọi là “Bản đặc tả yêu cầu phần mềm” hay SRS (software

requirement specification) Tài liệu Đặc tả yêu cầu chính là nền tảng cho các hoạt

động tiếp theo cho đến cuối dự án

 Phân tích hệ thống và thiết kế (System Analysis and Design): là giai đoạn định

ra làm thế nào để hệ thống phần mềm đáp ứng những yêu cầu mà khách hàng yêu cầu trong tài liệu SRS

Mô hình thác nước – Waterfall

 Lập trình (Coding and Unit Test): là giai đoạn hiện thực làm thế nào được chỉ ra

trong giai đoạn “Phân tích hệ thống và thiết kế”

 Kiểm thử (Test): bao gồm kiểm thử tích hợp cho nhóm các thành phần và kiểm thử

toàn hệ thống (system test) Một khâu kiểm thử cuối cùng thường được thực hiện là nghiệm thu (acceptance test), với sự tham gia của khách hàng trong vai trò chính để xác định hệ thống phần mềm có đáp ứng yêu cầu của họ hay không

 Cài đặt và bảo trì (Deployment and Maintenance): đây là giai đoạn cài đặt, cấu

hình và đào tạo cho khách hàng Giai đoạn này sửa chữa những lỗi của phần mềm

(nếu có) và phát triển những thay đổi mới được khách hàng yêu cầu (như sửa đổi,

thêm hay bớt chức năng/đặc điểm của hệ thống)

=> Nhược điểm của mô hình waterfall: Thực tế cho thấy đến những giai đoạn cuối

của dự án mới có khả năng nhận ra sai sót trong những giai đoạn trước và phải quay lại

để sửa chữa

 Tinh thần chủ đạo của V-model là các hoạt động kiểm thử phải được tiến hành song song (theo khả năng có thể) ngay từ đầu chu trình cùng với các hoạt động phát triển Ví dụ, các hoạt động cho việc lập kế hoạch kiểm thử toàn hệ thống có thể được thực hiện song song với các hoạt động phân tích và thiết kế hệ thống

Mô hình Xoắn ốc – Spiral model

 Trong mô hình xoắn ốc, quy trình phát triển phần mềm được thực hiện như một vòng xoáy ốc Mỗi vòng xoắn ốc biểu diễn một hoạt động trong tiến trình phát triển phần

mềm

 Nó dựa trên ý tưởng là tối thiểu hóa rủi ro, bằng viêc phân tích yếu tố rủi ro ở mỗi bước lặp và sử dụng phương pháp làm bản mẫu Quá trình phát triển được chia thành nhiều bước lặp lại, mỗi bước bắt đầu bằng việc lập kế hoạch, phân tích rủi ro, rồi tạo bản mẫu,

hoàn thiện và phát triển hệ thống, duyệt lại, và cứ thế tiếp tục Nội dung gồm 4 hoạt

động chính:

1 Lập kế hoạch: xác định mục tiêu, giải pháp và ràng buộc;

2 Phân tích rủi ro: phân tích các phương án, xác định và giải quyết rủi ro;

Mô hình Xoắn ốc – Spiral model



3 Phát triển và kiểm định: phát triển sản phẩm “mức tiếp theo” Xây dựng một hay

một số biểu diễn của ứng dụng

4 Lên kế hoạch cho chu kỳ lặp tiếp theo: kiểm duyệt tất cả các kết quả của các giai

đoạn con xảy ra trước đó và lập kế hoạch cho chu kỳ lặp tiếp theo

 Với mỗi lần lặp vòng xoắn ốc (bắt đầu từ tâm), các phiên bản được hoàn thiện dần Tại một vòng xoắn ốc, phân tích rủi ro phải đi đến quyết định “ tiến hành tiếp hay dừng “ Nếu rủi ro quá lớn, thì có thể đình chỉ dự án hay thay đổi yêu cầu đặt ra cho thích hợp

Mô hình này thích hợp để phát triển các hệ thống quy mô lớn

Mô hình Agile: quy trình Scrum

 Scrum là một quy trình phát triển phần mềm theo mô hình linh hoạt (agile) Công nghệ Agile cung cấp rất nhiều phương pháp luận, quy trình và các thực nghiệm để cho việc phát triển phần mềm trở nên nhanh chóng và dễ dàng Hiện nay tại Việt Nam, quy trình này đang được thực thi tại các đội phát triển phần mềm của một số công ty lớn

 Product Owner tạo ra Product Backlog chứa các yêu cầu của dự án với các hạng

mục được sắp theo thứ tự ưu tiên Đội sản xuất sẽ thực hiện việc hiện thực hóa dần các yêu cầu của Product Owner với sự lặp đi lặp lại các giai đoạn từ 1 đến 4 tuần làm

việc (gọi là Sprint) với đầu vào là các hạng mục trong Product Backlog, đầu ra là các

gói phần mềm hoàn chỉnh có thể chuyển giao được (Potentially Shippable Product Increment)

Mô hình Agile: quy trình Scrum

( Định nghĩa về sprint: các vòng lặp phát triển gọi là các sprint Sprint là những chu kỳ nhỏ để phát triển sản phẩm Trong Sprint, nhóm sẽ tập trung phát triển những chức năng cụ thể nào đó và hoàn hiện nó vào cuối mỗi Sprint Mỗi Sprint sẽ có thời gian cố định được thống nhất, thường là 1 hoặc 2 tuần và thường không hơn 4 tuần)

 Trước khi cả nhóm thực hiện làm các sprint, đội sản xuất cùng họp với Product Owner

hoạch (theo cách làm của Scrum) là Sprint Backlog chứa các công việc cần làm

trong suốt một Sprint

 Trong suốt quá trình phát triển, nhóm sẽ phải cập nhật Sprint Backlog và thực hiện công việc họp hằng ngày (Daily Scrum) để chia sẻ tiến độ công việc cũng như các

vướng mắc trong quá trình làm việc cùng nhau Nhóm được trao quyền để tự quản

lí và tổ chức lấy công việc của mình để hoàn thành công việc trong Sprint

Mô hình Agile: quy trình Scrum

 Buổi họp Sơ kết Sprint (Sprint Review) ở cuối Sprint sẽ giúp khách hàng thấy được

nhóm đã có thể chuyển giao những gì, còn những gì phải làm hoặc còn gì phải thay đổi hay cải tiến Sau khi kết thúc việc đánh giá Sprint, Scrum Master và nhóm cùng tổ

chức họp Cải tiến Sprint (Sprint Retrospective) để tìm kiếm các cải tiến trước khi

Sprint tiếp theo bắt đầu, điều này sẽ giúp nhóm liên tục học hỏi và trưởng thành qua từng Sprint

 Các Sprint sẽ được lặp đi lặp lại cho tới khi nào các hạng mục trong Product Backlog đều được hoàn tất hoặc khi Product Owner quyết định có thể dừng dự án căn cứ tình hình thực tế Do quy trình luôn luôn được cải tiến, nhóm Scrum thường có năng suất lao động rất cao Đây là hai lợi ích to lớn mà Scrum mang lại cho tổ chức

Quy trình Scrum: 4 cuộc họp

 Scrum định nghĩa quy tắc cho bốn sự kiện chủ chốt (các cuộc họp) nhằm tạo môi trường và quy cách hoạt động và cộng tác cho các thành viên trong dự án Các lễ nghi này diễn ra trước khi Sprint bắt đầu (Sprint Planning), trong khi Sprint diễn ra (Daily Scrum) và sau khi Sprint kết thúc (Sprint Review và Sprint Retrospective):

1 Sprint Planning (Họp Kế hoạch Sprint): Nhóm phát triển họp với Product Owner để

lên kế hoạch làm việc cho một Sprint Công việc lập kế hoạch bao gồm việc chọn lựa các yêu cầu cần phải phát triển, phân tích và nhận biết các công việc phải làm kèm theo các ước lượng thời gian cần thiết để hoàn tất các tác vụ Scrum sử dụng cách thức lập

kế hoạch từng phần và tăng dần theo thời gian, theo đó, việc lập kế hoạch không diễn

ra duy nhất một lần trong vòng đời của dự án mà được lặp đi lặp lại, có sự thích nghi với các tình hình thực tiễn trong tiến trình đi đến sản phẩm

Quy trình Scrum: 4 cuộc họp

2 Daily Scrum (Họp Scrum hằng ngày):Scrum Master tổ chức cho Đội sản xuất

họp hằng ngày trong khoảng 15 phút để Nhóm Phát triển chia sẻ tiến độ công việc

 Trong cuộc họp này, từng người trong nhóm phát triển lần lượt trình bày để trả lời 3 câu hỏi sau:

 Hôm qua đã làm gì?

 Hôm nay sẽ làm gì?

 Có khó khăn trở ngại gì không?

3 Sprint Review (Họp Sơ kết Sprint): Cuối Sprint, nhóm phát triển cùng với Product

Owner sẽ rà soát lại các công việc đã hoàn tất (DONE) trong Sprint vừa qua và đề

xuất các chỉnh sửa hoặc thay đổi cần thiết cho sản phẩm

4 Sprint Retrospective (Họp Cải tiến Sprint): Dưới sự trợ giúp của Scrum Master,

nhóm phát triển sẽ rà soát lại toàn diện Sprint vừa kết thúc và tìm cách cải tiến quy trình làm việc cũng như bản thân sản phẩm

Quy trình Scrum: 3 vai trò

 Trong Scrum, đội ngũ tham gia phát triển phần mềm được phân chia ra ba vai trò với

trách nhiệm rõ ràng để đảm bảo tối ưu hóa các công việc đặc thù Ba vai trò này

bao gồm: Product Owner (chủ sản phẩm), Scrum Master và Development Team (Đội sản xuất hay Nhóm Phát triển)

 Product Owner: Là người chịu trách nhiệm về sự thành công của dự án, người định

nghĩa các yêu cầu và đánh giá cuối cùng đầu ra của các nhà phát triển phần mềm

 Scrum Master: họ phải đảm bảo các sprint được hoàn thành đúng mục đích, bảo vệ đội

làm việc và loại bỏ các trở ngại

 Development Team: thường từ 5-9 người, tùy theo quy mô dự án nó có thể có rất

nhiều đội, nhiều người tham gia

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

HỌC PHẦN NỘI DUNG

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

White-box testing

Black-box testing

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

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

Unit testing Integration testing System testing Acceptance testing

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

Quy trình kiểm thử phần mềm

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)

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

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

 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:

 Xác định phân vùng tương đương và test case thích hợp theo yêu

cầu dưới đây:

+ Zip Code : 5 chữ số

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

Bài làm:

 Phân vùng tương đương ZIP Code

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