1. Trang chủ
  2. » Giáo án - Bài giảng

Bài Giảng Kiểm Thử Phần Mềm ( Combo Full Slides 6 Chương )

293 54 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Tiêu đề Bài Giảng Kiểm Thử Phần Mềm
Trường học ISR-CMU
Chuyên ngành Kiểm Thử Phần Mềm
Thể loại Bài giảng
Năm xuất bản 2010
Thành phố CMU
Định dạng
Số trang 293
Dung lượng 19,3 MB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

PowerPoint Presentation 1 BÀI GIẢNG KIỂM THỬ PHẦN MỀM @ ISR CMU 2010 NỘI DUNG BÀI GIẢNG  Chương 1 Giới thiệu về kiểm thử phần mềm  Chương 2 Kiểm thử hộp đen  Chương 3 Kiểm thử hộp trắng  Chương 4[.]

Trang 1

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

Trang 2

@ ISR-CMU 2010

NỘI DUNG BÀI GIẢNG

Trang 3

Giới thiệu về kiểm thử

phần mềm

Kiểm thử phần mềm

Trang 4

 Các kĩ thuật, tiến trình kiểm thử

 Hiểu và tạo được các trường hợp kiểm thử cho

các chương trình đơn giản

 Quản lí chất lượng phần mềm

4

Trang 5

Kiến thức cần thiết

 Ngôn ngữ (nói , hiểu, viết): tiếng việt, tiếng anh

 Cơ bản của IT

 Kĩ năng lập trình (debug và kiểm tra lỗi)

 Cơ bản của SE, quy trình phát triển phần mềm

 Ngôn ngữ mô tả lôgic ( phản ứng) : tiến trình algebra, state machines, petri nets.

 Logic, tập hợp

 Thống kê.

Trang 6

@ ISR-CMU 2010

Tài liệu tham khảo

 Ian Sommerville: “Software Engineering”, 7th

Ed., 2004.

 Roger S Pressman: “Software Engineering: A

Practitioner's Approach”, 6 th Ed., McGraw-Hill,

2004.

 John Musa: “Software Reliability Engineering”,

McGraw-Hill

6

Trang 7

Kiểm thử phần mềm là gì?

Kiểm thử phần mềm là quá trình thực thi 1 hệ

thống phần mềm để xác định xem phần mềm có

đúng với đặc tả không và thực hiện trong môi

trường như mong đợi hay không?

Trang 9

Thuật ngữ

ERROR

FAILURE FAULT

Trang 10

Chi phí thay đổi

Trang 11

Mục tiêu

mềm để mọi người hiểu 6 í chính sau:

1 Các định nghĩa và chi phí của các khiếm

4 Điều gì làm nên một người kiểm thử giỏi

5 Thực tiễn của kiểm thử phần mềm

6 Các thuật ngữ của kiểm thử phần mềm

Trang 12

@ ISR-CMU 2010

Ví dụ

được xác định như sau:

nextDate (tháng, ngày, năm): hàm mà kết

quả đầu ra là ngày tiếp theo của ngày đầu vào 1

≤ tháng ≤ 12, 1 ≤ ngày ≤ 31,1900 ≤ năm ≤

2060.

Hàm này đã được cài đặt bởi ngôn ngữ java.

 Nếu chỉ có các đặc tả và các file class, làm thế nào

có thể chắc chắn rằng hàm đó đã được cài đặt chính xác?

 Nếu đã cài đặt hàm, có nghĩa là, có các file java, làm thế nào có thể chắc chắn rằng code là chính xác?

6

Trang 13

Ví dụ 1 (1)

 Nếu bạn có các đặc tả và các file.class, có lẽ có thể tiếp tục như sau:

1 Suy nghĩ một vài phút dựa trên các đặc tả và chọn ngày 2006/06/16

như là một đầu vào cho chương trình.

Trang 14

B3: Click vào nút Tell

và xem kết quả hiện lên là ngày

16/6/2006

Trang 15

B3:Click vào nút Tell

và kết quả hiện lên là 32/1/2007

Trang 16

@ ISR-CMU 2010

Ví dụ 2 (1)

 Khi đã thực hiện 1 chức năng , tức là đã có mã nguồn của nó

Nhưng làm sao để biết được code đó là chính xác Hãy xem ví

dụ dưới đây :

16

Trang 17

Ví dụ 2 (2)

 Để kiểm tra code, thì mỗi dòng sẽ được chạy ít nhất một lần

Nhưng file Year.java chỉ là một phần của chương trình, nó không thể chạy một mình Vì vậy cần code thêm 1 đoạn để kiểm tra xem

1 năm nào đó có phải là năm nhuận hay không.

Trang 18

@ ISR-CMU 2010

Kết luận

 Hai ví dụ cho ta biết được rằng chắc chắn sẽ có một số sai lầm trong chương trình Trong thử nghiệm phần mềm, đây

được gọi là một lỗi(defect).

 Những ví dụ này là hai phương pháp tiếp cận khác nhau, đều có thể áp dụng để tìm lỗi Một được gọi là kiếm tra

chức năng như trong ví dụ 1, ví dụ 2 được gọi là kiểm tra cấu trúc

 Bây giờ bạn có thể tự hỏi mình rằng là lí do tại sao chúng

ta phải tìm các lỗi(defect)?

18

Trang 19

Tại sao lỗi lại phát sinh trong phần mềm?

Phần mềm được tạo ra bởi chính chúng ta

 Chúng ta có thể biết nhiều thứ những chúng ta không thể biết được tất

cả mọi thứ.

 Các lập trình viên đều có kĩ năng, nhưng không phải ai cũng hoàn hảo.

 1 số lập trình viên không có những quy tắc khắt khe với các đoạn mã của mình.

 Các lập trình viên là những người dễ gây ra sai sót (lỗi).

Làm việc dưới áp lực ngày càng tăng để đảm bảo đúng thời hạn

 Không có thời gian để kiểm tra, các chức năng có thể bị làm sai.

 Hệ thống có thể không đáp ứng đầy đủ các yêu cầu ban đầu.

Phần mềm thực sự phức tạp, trừu tượng và vô hình

 Khó có thể xem phần mềm nếu nó là chưa hoàn chỉnh hoặc hoạt động thiếu chính xác.

 Khó có ai có thể hiểu hết hoàn toàn 1 hệ thống lớn.

 Quá nhiều giao diện bên ngoài không cần thiết.

Trang 20

@ ISR-CMU 2010

Tại sao phải tìm kiếm các lỗi

 Phần mềm được viết bởi con người Và họ tạo ra những sai sót Chi phí của các lỗi có thể là rất cao.

 Từ góc nhìn của 1 người phát triển phần mềm:

• Phải mất rất nhiều thời gian và nỗ lực để sửa chữa các lỗi Một cuộc khảo sát cho thấy khoảng 50% thời gian làm việc của người lao động phần mềm được chi tiêu vào việc tìm kiếm và sửa lỗi.

• Càng sớm tìm ra lỗi thì chúng ta càng tiết kiệm được chi phí

• Bài giảng 11 sẽ có thông tin chi tiết hơn

 Từ góc nhìn của 1 người dùng cuối:

• Không ai thích 1 phần mềm mà sử dụng thì hay bị treo.

• Với việc sử dụng nhiều hơn và thường xuyên hơn của phần mềm trong cuộc sống hàng ngày ,chúng ta cần các phần mềm có chất lượng hơn, đáng tin cậy hơn và an toàn hơn.

 Phải cần kĩ thuật để tìm các lỗi và đó là mục đích của kiểm thử phần mềm

20

Trang 21

Nguồn gốc của các lỗi

Khâu định hướng

 Người phát triển không hiểu họ đang làm gì

 Thiếu sự đào tạo thích hợp dẫn đến lỗi trong đặc tả, thiết kế ,

coding và kiếm thử

Khâu kết nối

 Người phát triển không đủ hiểu biết và các kiến thức cần thiết.

 Thông tin không đạt được ở tất cả các bên liên quan.

Thông tin bị mất

Khâu giám sát

 Bỏ qua những thứ cần thiết

Trang 22

@ ISR-CMU 2010

Lỗi (defect) là gì ? (1)

 Không có 1 định nghĩa tiêu chuẩn

 Các tổ chức khác nhau có những định nghĩa khác nhau.

 Những điều được chấp nhận bởi các chuyên gia:

1 Các phần mềm không làm được cái gì đó mà nó nên làm

2 Các phần mềm làm 1 cái gì đó mà đặc tả bảo nó không nền làm

3 Làm cái gì đó mà đặc tả không đề cập đến

4 Các phần mềm không làm 1 cái gì đó mà các đặc điểm kĩ thuật không

đề cập đến nhưng lại là nên làm

5 Phần mềm khó hiểu , khó sử dụng , chậm hoặc không đúng

22

Trang 23

 Điều quan trọng là phải biết chia sẽ những hiểu

biết của mình trong tổ chức hoặc nhóm làm việc

Trang 24

@ ISR-CMU 2010

Kiểm thử phần mềm là gì

Định nghĩa kiểm thử phần mềm

 Không có định nghĩa tiêu chuẩn

 Các tổ chức khác nhau có định nghĩa khác nhau

 Dưới đây là định nghĩa được chấp nhận bởi nhiều chuyên gia

1 Myers : kiểm thử là tiến trình thực hiện 1 chương trình với mục

đích là tìm ra lỗi

2 IEEE[1990] : kiểm thử là tiến trình của hoạt động hệ thống hoặc

thành phần theo điều kiện cụ thể, quan sát hoặc ghi lại kết quả, và tạo

một đánh giá về một số khía cạnh của hệ thống hoặc một thành phần

 Chú í :

 Testing quá trình để chứng minh phần mềm có khiếm khuyết

 Các đối tượng được thử nghiệm không chỉ bao gồm các đoạn code mà

còn là các sản phẩm sau mỗi pha phần mềm

24

Trang 25

Mục tiêu của kiểm thử phần mềm

Trang 26

@ ISR-CMU 2010

Quá trình kiểm thử làm việc như thế nào?

26

Trang 27

Giới thiệ

u về kiể

m thử phầ

Trang 28

 Được cài đặt trong ngôn ngữ tự nhiên hoặc ngôn ngữ lập trình.

Hiệu quả tìm lỗi: tìm được lỗi hoặc ít nhất là khả năng tìm lỗi

Tiêu chuẩn: giảm số lượng các test case cần thiết.

Kinh tế: trong thể hiện,phân tích và gỡ rối.

Tiến hóa: hiệu quả của các trường hợp kiểm thử (Test case) cũ

sau mỗi lần thay đổi phần mềm

28

Trang 29

Cài đặt 1 Trường hợp kiểm thử (Test case)(1)

Mã kiểm thử(Test ID): TestSample_ST_001

Độ ưu tiên (Priority): P1

Phần kiểm thử (Test Item): Hàm Next Date

Các điều kiện thực hiện: 1 Chương trình có thể chạy

Quy trình kiểm thử: 1.Chạy chương trình

2.Nhập 6 vào ô Month,16 vào ô Day,2006 vào ô Year

3.Click vào nút Tell

Kết quả mong đợi: 1/1/2007

Kết quả thực hiện:

Trang 30

@ ISR-CMU 2010

Cài đặt 1 Trường hợp kiểm thử (2)

 Cài đặt trường hợp kiêm thử (Test case) trong

ngôn ngữ lập trình Java sử dụng Junit frame work ( www.junit.org )

30

Trang 31

Các yêu cầu cho nhân viên kiểm thử giỏi(1)

Hãy ghi nhớ những điều dưới đây có thể có ích:

 Nhân viên kiểm thử cần có các tính cách nghiệp vụ: thật thà, khách quan, trung thành.

 Nhân viên kiểm thử cần tuyệt đối tin rằng có lỗi trong

phần mềm, và sẽ tìm ra lỗi hoặc không có lỗi

 Nhân viên kiểm thử cần phải được định hướng rõ ràng bởi vì lỗi không tự thể hiện ra.

 Nhân viên kiểm thử nên có tính kiên trì Phần lớn thời gian các nhân viên phải lặp đi lặp lại 1 hành động, như nhập dữ liệu hàng nghìn lần chỉ để tìm ra 1 lỗi

 Nhân viên kiểm thử phải báo cáo lỗi không phát sinh Vì các lỗi đó có thể dẫn tới lỗi không tránh khỏi

Trang 32

@ ISR-CMU 2010

Các yêu cầu cho nhân viên kiểm thử giỏi(2)

Hãy ghi nhớ những điều này có thể có ích:

 Nhân viên kiểm nên khôn khéo, có khả năng thuyết phục báo cho lập trình viên rằng có lỗi, nếu không sẽ

Trang 33

Thực tế của việc kiểm thử phần mềm

Một nhân viên kiểm thử nên chú í đến những

điều sau đây:

lỗi ở đó

Trang 34

@ ISR-CMU 2010

 Nếu muốn kiểm thử chức năng

của máy tính bên, hãy nghĩ ra các khả

năng về đầu ra cho nó:

Vậy có vô số trường hợp xảy ra:

Trang 35

Không thể kiểm thử hoàn toàn một phần mềm (3)

Trang 36

@ ISR-CMU 2010

Kiểm thử không thể không tìm ra lỗi

Nếu một nhân viên nghĩ lỗi không tồn tại, đó

là do anh ấy không tìm ra lỗi hoặc chưa tìm ra lỗi

rằng một phần mềm hết lỗi

36

Trang 37

Càng tìm càng ra nhiều lỗi

lúc không tập trung gây nên lỗi

lỗi tìm thấy và được gỡ sẽ phát sinh nhiều lỗi khác)

Trang 38

@ ISR-CMU 2010

Kiểm thử phần mềm không phải là bước cuối

mềm: Chỉ là tìm lỗi chứ không sửa lỗi

công của tất cả các pha trong xây dựng phần mềm

38

Trang 40

@ ISR-CMU 2010

Kiểm thử và gỡ rối

 Kiểm thử là tiến trình hoạt động của một hệ thống hoặc một

thành phần với điều kiện xác định; nhằm quan sát hoặc ghi lại các kết quả, và tạo ra sự cân bằng một vài khía cạnh của hệ

 Kiểm thử là quá trình tìm lỗi trong khi gỡ rối để xác định vị trí và sửa lỗi.

 Qui trình làm việc: Kiểm thử: Tìm lỗi-> Gỡ rối: Định vị, sửa lỗi -> Kiểm thử xác minh xem lỗi đã được sửa chưa?.

40

Trang 41

Sự kiểm chứng (Validation) và sự kiểm định (Verification)

Trang 42

@ ISR-CMU 2010

Kiểm thử hộp đen và hộp trắng

vi ,điều khiển dử liệu)

hộp đen và không có kiến thức của cấu trúc

bên trong hoặc như thế nào mà phần mềm

thực sự làm việc sử dụng trong khi kiểm thử

điều khiển logic)

trong của hệ thống và logic phần mềm

10/10/2023

Trang 43

Mô hình chữ V

Trang 44

@ ISR-CMU 2010

Các cấp độ kiểm thử khác nhau

Cấp độ đơn

 Các khối xây dựng lên của hệ thống làm việc chính

xác như qui định không?

Trang 45

Phân loại các kĩ thuật kiểm thử

Trang 46

@ ISR-CMU 2010

Phân loại dựa trên việc các test được tạo

ra như thế nào?

Trang 47

Kiểm thử và đảm bảo chất lượng phần mềm

Kiểm thử

 Kiểm thử là quá trình hoạt động của hệ thống hoặc

bên dưới thành phần quy định truyền thống , quan sát

hoặc ghi lại kết quả , và tạo ra một đánh giá của 1 vài

khía cạnh của hệ thống hoặc thành phần

 Sự thiết lập của hoạt động thiết kế tới đánh giá quá

trình bới những người thiết kế phần mềm

 Mục tiêu của SQA là đánh giá và cải thiện tiến trình

Khác nhau và quan hệ

 Đối tượng làm việc của kiểm thử là phần mềm

 Đối tượng làm việc của quản lí chất lượng là quá

trình phát triển phần mềm

Trang 48

@ ISR-CMU 2010

Tổng kết

của phần mềm là tìm kiếm khiếm khuyết

Trang 49

Homework

Trang 50

@ ISR-CMU 2010

Q&A

50

Trang 51

Kiểm thử hộp đen

Kiểm thử phần mềm

Trang 53

Quy trình kiểm định

Trang 54

@ ISR-CMU 2010

Lợi ích của việc kiểm định: Phát hiện lỗi sớm

54

lượng bằng cách tìm kiếm các sai sót sớm trong việc phát triển vòng đời.

Trang 55

Kiểm thử hộp đen

thống

• Thuyết minh: các chức năng đủ & vận hành đúng

• Thực hiện: qua giao diện

• Cơ sở: đặc tả, điều kiện vào/ra và cấu trúc dữ liệu

• Ít chú í đến logic nội tại của nó

Trang 56

@ ISR-CMU 2010

Mô hình khái niệm kiểm thử hộp đen

56

Trang 57

Mục đích kiểm thử hộp đen

Trang 58

@ ISR-CMU 2010

Câu hỏi cho kiểm thử hộp đen

giao diện) đạt được đến đâu?

Trang 59

Vấn đề và tiêu chuẩn lựa chọn

lớn

giản)

(không phải 1 sai cụ thể gắn với 1 kiểm thử

cụ thể)

Trang 60

@ ISR-CMU 2010

Mục tiêu

quả nhất cho kiểm thử hộp đen:

tương đương)

60

Trang 61

Kiểm thử hộp đen - Black-box testing

 Đinh nghĩa

 Kiểm thử hộp đen: kiểm thử bỏ qua chi tiết, cấu trúc bên trong hệ thống và chỉ tập trung vào kết quả đầu ra.

 ƒKiểm thử hộp đen thường sử dụng:Kiểm thử hộp đen thường sử dụng:

 Boundary Testing (Kiểm thử biên)

 Equivalence Class Testing (Kiểm thử lớp tương đương)

 Decision Table (Bảng quyết định)

 Error Guess Testing (Kiểm thử đoán lỗi)

Trang 62

@ ISR-CMU 2010

Kiểm thử hộp đen (2)

nếu chỉ áp dụng duy nhất một kĩ thuật

nắm vững các đặc tả

chức năng phần mềm mà còn cả thuộc tính phi chức năng, chẳng hạn như bảo mật, hiệu suất, khả năng sử dụng

62

Trang 63

Phân vùng tương đương

Partitioning): chia các miền đầu vào của chương trình thành các tập dữ liệu có cùng đặc điểm mà từ đó các trường hợp kiểm thử

có thể tiền hành kiểm thử

bao phủ số lỗi nhiều nhất để giảm tối thiểu số lượng các trường hợp kiểm thử

Trang 64

@ ISR-CMU 2010

Phân vùng tương đương

64

Trang 65

Phân vùng tương đương

các lớp mà dữ liệu thuộc lớp này là hợp lệ

thuộc lớp này là không hợp lệ

nghiệm (test case)

case)

Trang 66

@ ISR-CMU 2010

Xác định các lớp tương đương(1)

Điều cần biết về phân lớp tương đương:

một lớp tương đương

dụng các phương pháp xác định khác nhau

có thể bị ảnh hưởng bởi các lớp tương đương khác nhau

xác định các lớp tương đương

66

Trang 67

Xác định các lớp tương đương(2)

1 Nếu một điều kiện đầu vào xác định cụ thể một mức của các giá trị, thì xác định được một lớp tương đương hợp lệ và một lớp tương đương không hợp lệ

2 Nếu một điều kiện đầu vào quy định cụ thể số lượng các giá trị, thì xác định được một lớp tương đương hợp

lệ và một lớp tương đương không hợp lệ.

3 Nếu một điều kiện đầu vào xác định một tập hợp các giá trị đầu vào và có một lí do để tin rằng chương trình

xử lí mỗi một giá trị khác nhau, thì xác định được một lớp hợp lệ tương đương cho mỗi một giá trị và một lớp tương đương không hợp lệ.

Trang 68

@ ISR-CMU 2010

Xác định các lớp tương đương(3)

4 Nếu một điều kiện đầu vào quy định cụ thể "phải là“ , chẳng hạn như "kí tự đầu tiên của bộ nhận diện phải là

một chữ,“ thì xác định được một lớp tương đương hợp lệ

và một lớp tương đương không hợp lệ.

5 Nếu có bất kỳ lí do để tin rằng chương trình không xử lí các yếu tố trong một lớp tương đương giống nhau, thì ta phân chia lớp tương đương vào các lớp tương đương nhỏ hơn.

68

Trang 69

Xác định các Test Cases

1 Đặt một số duy nhất cho mỗi lớp tương ứng.

2 Thiết kế một test case bao gồm nhiều lớp tương ứng hợp lệ đã được phát hiện nhất có thể cho đến khi tất cả các lớp tương ứng hợp lệ được phủ bởi test case.

3 Thiết kế một test case bao gồm một và chỉ một trong số các lớp tương ứng không hợp lệ đã được phát hiện ra cho đến khi các test case của bạn bao phủ hết các lớp không hợp lệ tương ứng.

Chú í: Để có thể thực hiện việc xây dựng các test case dễ dàng hơn chúng ta có thể sử dụng bảng sau để phát hiện

Điều kiện Lớp tương đương

hợp lệ Số thứ tự Lớp tương đương không

hợp lệ

Số thư tự

Trang 70

@ ISR-CMU 2010

Ví dụ (1)

nextDate(month,day,year): hàm đưa ra ngày

tiếp theo của ngày nhập vào

1≤month ≤12, 1≤day ≤31, 1900≤year ≤2060

Hai cách phân lớp này có ảnh hưởng rất lớn

từ việc xác định các lớp tương đương

70

Trang 71

Ví dụ (2) - Cách phân lớp thứ nhất

 Bảng phân loại các lớp tương đương và số thứ tự

của chúng:

Điều kiện Lớp tương đương

hợp lệ Số thứ tự Lớp tương đương không

hợp lệ

Số thư tự

Trang 72

@ ISR-CMU 2010

Ví dụ (3) - Cách phân lớp thứ nhất

72

1 Các lớp 1, 2, 3 có đầu vào (6,16,2006), kết quả mong

muốn là (6,17,2006).

2 Các lớp 4, 2, 3 có đầu vào (-2,16,2006), kết quả mong

muốn là “Input Error!”

3 Các lớp 5, 2, 3 có đầu vào (20,16,2006), kết quả mong

muốn là ”Input Error!”

4 Các lớp 1, 6, 3 có đầu vào (5,0,2006), kết quả mong

muốn là ”Input Error!”

5 Các lớp 1, 7, 3 có đầu vào (5,40,2006), kết quả mong

muốn là ”Input Error!”

6 Các lớp 1, 2, 8 có đầu vào (5,10,1812), kết quả mong

muốn là ”Input Error!”

7 Các lớp 1, 2, 9 có đầu vào (5,10,3006), kết quả

mong muốn là ”Input Error!”

Ngày đăng: 10/10/2023, 18:11

HÌNH ẢNH LIÊN QUAN

Bảng Quyết định Đầu vào Giới hạn(1) - Bài Giảng Kiểm Thử Phần Mềm ( Combo Full Slides 6 Chương )
ng Quyết định Đầu vào Giới hạn(1) (Trang 88)
Bảng Quyết định Đầu vào Giới hạn(2) - Bài Giảng Kiểm Thử Phần Mềm ( Combo Full Slides 6 Chương )
ng Quyết định Đầu vào Giới hạn(2) (Trang 89)
Bảng Quyết định Đầu vào Mở rộng(1) - Bài Giảng Kiểm Thử Phần Mềm ( Combo Full Slides 6 Chương )
ng Quyết định Đầu vào Mở rộng(1) (Trang 90)
Bảng Quyết định Đầu vào Mở rộng(2) - Bài Giảng Kiểm Thử Phần Mềm ( Combo Full Slides 6 Chương )
ng Quyết định Đầu vào Mở rộng(2) (Trang 91)
Bảng Quyết định Đầu vào Mở rộng (3) - Bài Giảng Kiểm Thử Phần Mềm ( Combo Full Slides 6 Chương )
ng Quyết định Đầu vào Mở rộng (3) (Trang 92)
Bảng Quyết định - Bài Giảng Kiểm Thử Phần Mềm ( Combo Full Slides 6 Chương )
ng Quyết định (Trang 93)
Bảng quyết định - Bài Giảng Kiểm Thử Phần Mềm ( Combo Full Slides 6 Chương )
Bảng quy ết định (Trang 99)
Hình chữ V) - Bài Giảng Kiểm Thử Phần Mềm ( Combo Full Slides 6 Chương )
Hình ch ữ V) (Trang 191)
Sơ đồ - tích hợp từ trên xuống - Bài Giảng Kiểm Thử Phần Mềm ( Combo Full Slides 6 Chương )
t ích hợp từ trên xuống (Trang 218)
Sơ đồ tích hợp dưới lên - Bài Giảng Kiểm Thử Phần Mềm ( Combo Full Slides 6 Chương )
Sơ đồ t ích hợp dưới lên (Trang 223)
Hình khi ứng dụng đang - Bài Giảng Kiểm Thử Phần Mềm ( Combo Full Slides 6 Chương )
Hình khi ứng dụng đang (Trang 283)

🧩 Sản phẩm bạn có thể quan tâm