Bài giảng kiểm thử phần mềm và đảm bảo chất lượng phần mềm ( combo full slides 5 chương )

Bài giảng kiểm thử phần mềm và đảm bảo chất lượng phần mềm Nội dung bài giảng Chương 1 Giới thiệu Kiểm thử phần mềm Chương 2 Kiểm thử trong vòng đời phần mềm Chương 3 Các kỹ thuật kiểm thử tĩnh Chương 4 Kiểm thử tự động Chương 5 Thiết kế tài liệu kiểm thử

Kiểm thử phần mềm

và Đảm bảo chất lượng phần mềm

Giới thiệu Kiểm thử phần

mềm

GV: Phan Thị Hiền Email: phanhien388@gmail.com

Nội dung bài giảng

 Chương 1 Giới thiệu Kiểm thử phần mềm

 Chương 2 Kiểm thử trong vòng đời phần mềm

 Chương 3 Các kỹ thuật kiểm thử tĩnh

 Chương 4 Kiểm thử tự động

 Chương 5 Thiết kế tài liệu kiểm thử

Nội dung bài giảng

 Chương 1 Giới thiệu Kiểm thử phần mềm

 Chương 2 Kiểm thử trong vòng đời phần mềm

 Chương 3 Các kỹ thuật kiểm thử tĩnh

 Chương 4 Kiểm thử tự động

 Chương 5 Thiết kế tài liệu kiểm thử

Chương 1 Giới thiệu Kiểm thử phần mềm

Tại sao phải kiểm thử?

Lỗi

Khái niệm Kiểm thử phần mềm

◦ Là quá trình thực thi 1 chương trình hay

Khái niệm thẩm định và xác minh

Kiểm thử hộp trắng – Kiểm thử hộp

đen

◦ Là phương pháp kiểm thử dựa trên các

đặc tả bên trong của chương trình

◦ Là phương pháp kiểm thử chỉ dựa trên

các đặc tả bên ngoài của chương trình,

mà không quan tâm tới logic của nó

Các giai đoạn kiểm thử

◦ Phân tích yêu cầu

Các giai đoạn kiểm thử

Vai trò của KTPM

đưa vào sử dụng

thực hiện và phân phối(chất lượng

Tiêu chuẩn dừng kiểm thử

◦ Rủi ro(kỹ thuật, nghiệp vụ, dự án…)

◦ Ràng buộc ngân sách, thời gian

◦ Phiên bản kiểm thử

◦ Môi trường kiểm thử

◦ …

Một số nguyên lý kiểm thử

của kiểm thử

Câu hỏi và bài tập

Chương 2 Kiểm thử trong vòng đời phần mềm

 Mỗi pha sẽ đc xem xét lại ở thời điểm hoàn

thành của nó để phục vụ cho việc quản lý chất lượng

 Khó có thể làm rõ yêu cầu ở thời điểm ban đầu của quá trình phát triển.

 Sẽ luôn có những hoạt động cần lặp lại

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

◦ Mô hình bản mẫu(prototyping model): Một bản mẫu của giao diện người dùng sẽ

được phát triển để lọc ra các yêu cầu

 Các yêu cầu đc làm rõ trong giai đoạn đầu.

 Giai đoạn cuối sẽ ít được hiệu chỉnh và xem

xét lại

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

◦ Mô hình xoắn ốc(Sprial model): Các hệ

thống con được phát triển một cách độc lập

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

 Các mô hình chi phí

◦ Mô hình COCOMO: Khối lượng cv lập trình viên phải làm đc tính toán trong chi phí dựa trên 1 công thức

toán học, sử dụng mô hình thống kê và gồm các mức

cơ bản, trung bình và nâng cao.

◦ Phương pháp điểm chức năng FP(Function Point):

Nhóm 5 phần tử - đầu vào, đầu ra, yêu cầu, tệp logic

và giao diện – được thu thập và đc cộng lại có trọng

số Dựa trên giả sử rằng tổng có trọng số tương quan với các mức phát triển phần mềm, kích thước của việc phát triển sẽ được ước lượng Cách nhìn nhận theo phương pháp này chính là việc coi thứ người dùng

thực sự cần ko phải là chương trình mà là chức năng.

Kiểm thử trong vòng đời phần mềm

‰Kiểm thử cho mỗi giai đọan/phần phát Kiểm thử cho mỗi giai đọan/phần phát triển

‰Kiểm thử cho mỗi giai đọan/phần phát Các mức kiểm tra nhấn mạnh vào mục tiêu phối hợp liên tục, không trùng lắp

‰Kiểm thử cho mỗi giai đọan/phần phát Phân tích, thiết kế bắt đầu sớm, ngăn ngừa lỗi

Kiểm chứng và chứng thực

 Kiểmchứng( Verification)

‰Kiểm thử cho mỗi giai đọan/phần phát Tìm các lỗi trong từng giai đoạn

‰Kiểm thử cho mỗi giai đọan/phần phát các hành động để đảm bảo cho

phần mềm được hiện thực đúng

theo một chức năng cụ thể nào đó

‰Kiểm thử cho mỗi giai đọan/phần phát “Are we building the system

right?”

„ Chứng thực( validation) Chứng thực( validation)

‰Kiểm thử cho mỗi giai đọan/phần phát Tìm lỗi trong hệ thống, phần

chuyển giao

‰Kiểm thử cho mỗi giai đọan/phần phát các hành động để đảm bảo cho

phần mềm được xây dựng theo

đúng yêu cầu của khách hàng

‰Kiểm thử cho mỗi giai đọan/phần phát “Are we building the right

system?”

Module được kiểm thử

Module sẽ được kiểm thử

Bộ điều khiển

Mô phỏng các chức năng ở các

module mức cao

Các mức kiểm thử

Kiểm thử tích hợp:

◦ Kiểm thử khi tích hợp nhiều module với nhau.

◦ Mục đích: kiểm tra giao diện giữa các module, đầu vào và đầu ra.

◦ Phương pháp:

 Kiểm thử từ trên xuống(top-down)

 Kiểm thử từ dưới lên(bottom-up)

 Kiểm thử big-bang: Kiểm thử khi các module đơn vị

đã đc kiểm thử xong.

 Kiểm thử hỗn hợp(sandwich): Các module mức thấp

đc kiểm thử từ dưới lên, các module mức cao được kiểm thử từ trên xuống.

Các mức kiểm thử

 Phương pháp kiểm thử tích hợp:

◦ Kiểm thử từ trên xuống:

 Kiểm thử từ module mức caothấp

 Cần có các cuống để mô tả các module chưa đc kiêm thử

 Giao diện giữa các module có thể được kiểm thử đầy đủ

Hiệu quả trong các hệ thống mới được phát triển

◦ Kiểm thử từ dưới lên:

 Kiểm thử từ module mức thấpcao

 Cần có bộ điều khiển để mô tả các module mức cao chưa

Các mức kiểm thử

◦ Nhằm tìm lỗi trên toàn bộ và cá biệt về

hành vi, chức năng, đáp ứng của hệ

thống

◦ Dựa trên: đặc tả yêu cầu, thiết kế mức

cao, use cases, rủi ro, kinh nghiệm, môi trường, …

◦ Kiểu kiểm tra: Chức năng, bảo mật, hiệu năng, tin cậy, …

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

◦ Các trường hợp kiểm thử được thiết kế

dựa trên các đặc tả bên ngoài của

chương trình Ko quan tâm đến logic của chương trình, dữ liệu kiểm thử được

chuẩn bị dựa trên các đặc tả bên ngoài

◦ Các trường hợp kiểm thử được dựa trên các đặc tả bên trong của chương trình

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

Các tiêu chí kiểm thử:

◦ Phân chia tương đương:

 Khoảng của các giá trị đầu vào được chia

thành nhiều lớp, và một giá trị kiểm thử sẽ được chọn ra từ mỗi lớp như 1 giá trị đại diện(vd: giá trị trung bình của 1 lớp….)

 Lớp tương đương hợp lệ: Là khoảng của các giá trị dữ liệu đúng

 Lớp tương đương không hợp lệ: Là khoảng

của các giá trị dữ liệu sai

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

Phân chia tương đương:

◦ Ví dụ: một textbox chỉ cho phép nhập số nguyên từ 1 đến 100

◦  Ta không thể nhập tất cả các giá trị từ 1 đến 100

◦ Ý tưởng của kỹ thuật này : 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

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

Phân chia tương đương:

◦ Trong ví dụ trên dùng kỹ thuật phân vùng tương đương, chia làm 3 phân vùng như sau:

◦ Như vậy chỉ cần chọn 3 test case để test trường hợp này: -5, 55, 102 hoặc 0, 10, 1000, …

0

valid invalid invalid

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

 Phân chia tương đương:

◦ Tuy nhiên nếu ta nhập vào số thập phân (55.5) hay một ký tự không phải là số (abc)?

◦ Trong trường hợp trên có thể chia làm 5 phân vùng như sau:

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

 Khoảng các giá trị đầu vào được phân chia

thành nhiều lớp, và các giá trị biên(giá trị giới hạn) của mỗi lớp được chọn ra thành giá trị kiểm thử.

  cần 4 test case để test trường hợp này:

0,1,10,101

valid invalid invalid

0

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

 Ví dụ: Một ngân hàng trả lãi cho khách hàng dựa vào số tiền còn lại trong tài khoản Nếu số tiền từ 0 đến 100$ thì trả 3% lãi, từ lớn hơn 100 $ đến nhỏ hơn 1000$ trả 5% lãi, từ 1000$ trở lên trả 7% lãi.

◦ Dùng kỹ thuật phân vùng tương đương :

 Test cases: -0.44, 55.00, 777.50, 1200.00

◦ Kỹ thuật phân tích giá trị biên : -0.01, 0.00, 100.00, 100.01, 999.99, 1000.00

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

 Mỗi giá trị giới hạn đều nằm trong một phân vùng nào

đó Nếu chỉ sử dụng giá trị giới hạn thì ta cũng có thể test luôn phân vùng đó.

 Tuy nhiên vấn đề đặt ra là nếu như giá trị đó sai thì nghĩa là giá trị giới hạn bị sai hay là cả phân vùng bị sai Hơn nữa, nếu chỉ sử dụng giá trị giới hạn thì không đem lại sự tin tưởng cho người dùng vì chúng

ta chỉ sử dụng những giá trị đặc biệt thay vì sử dụng giá trị thông thường.

 Vì vậy, cần phải kết hợp cả Phân lớp tương đương và phân tích giá trị biên

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

Các tiêu chí kiểm thử:

Bao phủ lệnh Mỗi câu lệnh được thực hiện ít nhất 1 lần

Bao phủ điều kiện quyết

định(bao phủ nhánh) Các trường hợp đúng và sai trong quyết định được thực hiện ít nhất 1 lần Bao phủ điều kiện(bao phủ

điều kiện nhánh) Khi có nhiều điều kiện, mọi tổ hợp cho các trường hợp đúng và sai đều được thỏa mãn Bao phủ quyết định/điều

kiện Là két hợp bao phủ nhánh và bao phủ điều kiện Bao phủ đa điều kiện Khi có nhiều điều kiện, mọi tổ hợp cho các

Kiểm thử tĩnh

ĐN: Là việc kiểm tra tài liệu, source code…

mà không cần phải thực thi phần mềm

Các lỗi tìm thấy trong quá trình kiểm tra có thể dễ dàng loại bỏ với chi phí rẻ hơn nhiều

so với việc tìm thấy và loại bỏ chúng ở test độngLợi ích của việc kiểm tra(reviews):

◦ Lỗi sớm được tìm thấy và sửa chữa

◦ Giảm thời gian lập trình

◦ Giảm thời gian & chi phí kiểm thử

Kiểm thử tĩnh

◦ Tài liệu đặc tả yêu cầu

◦ Tài liệu đặc tả thiết kế

◦ Sơ đồ luồng dữ liệu

◦ Mô hình ER

◦ Source code

◦ Test case

Kiểm thử động

Kiểm thử động

Structure-based

Error Guessing

Statement

Experience-based

Use Case Testing

State Transition Decision Tables

Boundary Value Analysis

Equivalence Partitioning Specification-based

Các loại kiểm thử trong kiểm thử hệ thống

 Kiểm thử chức năng(function testing): Kiểm thử hệ thống sau khi tích hợp có hoạt động đúng chức năng theo yêu cầu đặt ra trong bản mô tả hay không.

 Kiểm thử giao diện(user interface testing)

 Kiểm thử hiệu năng(performance testing)

 Kiểm thử mức độ đáp ứng(stress testing): Thực thi hệ thống với giả thiết là các tài nguyên hệ thống yêu cầu

không đáp ứng được về chất lượng, ổn định và số

Các loại kiểm thử trong kiểm thử hệ thống

 Kiểm thử ổn định(robustness testing): Kiểm thử dưới các điều kiện ko mong đợi như nguồn điệnbị ngắt, ng dùng gõ lệnh sai…

 Kiểm thử hồi phục(recovery testing): Chỉ ra các kết quả trả về khi xảy ra lỗi, mất dữ liệu, thiết bị… hoặc xóa

các dữ liệu hệ thống và xem khả năng phục hồi của hệ thống

 Kiểm thử quá tải(overload testing): Đánh giá hệ thống khi nó vượt qua giới hạn cho phép.

 Kiểm thử chất lượng(quality testing):Đánh giá sự tin tưởng, vấn đề duy tu, tính sẵn sàng của hệ thống Bao gồm cả việc tính toán thời gian trung bình hệ thống sẽ

bị hỏng và thời gian trung bình để khắc phục

Câu hỏi và bài tập

Chương 3 Các kỹ thuật kiểm thử tĩnh

◦ ‰Kiểm thử cho mỗi giai đọan/phần phát Các dạng rà soát chương trình

◦ ‰Kiểm thử cho mỗi giai đọan/phần phát Các giai đoạn rà soát

◦ ‰Kiểm thử cho mỗi giai đọan/phần phát Các vai trò và trách nhiệm

◦ ‰Kiểm thử cho mỗi giai đọan/phần phát Nhân tố thành công cho quá trình duyệt xét

„ Chứng thực( validation) Phân tích tĩnh bằng các công cụ

Rà soát và quá trình kiểm thử

„ Chứng thực( validation) Khái niệm chính

◦ ‰Kiểm thử cho mỗi giai đọan/phần phát Các sản phẩm thực hiện phần mềm và

kỹ thuật kiểm tra

◦ ‰Kiểm thử cho mỗi giai đọan/phần phát Tầm quan trọng và giá trị

◦ ‰Kiểm thử cho mỗi giai đọan/phần phát Sự khác biệt giữa tĩnh và động

Kiểm thử tĩnh

 Rà soát và công vụ

‰Kiểm thử cho mỗi giai đọan/phần phát Rà soát theo các khía cạnh không chính thức và chính thức

‰Kiểm thử cho mỗi giai đọan/phần phát Các công cụ có thể thực hiện vài kiểu kiểm tra tĩnh

‰Kiểm thử cho mỗi giai đọan/phần phát Sử dụng cho

 Yêu cầu, thiết kế, thêm mã, giản đồ csdl, tài liệu, các kịch

„ Chứng thực( validation)

bản, …

„ Chứng thực( validation) Mô hình và các khuôn mẫu

‰Kiểm thử cho mỗi giai đọan/phần phát Sơ đồ của mô hình phức tạp có thể tiềm ẩn các vấn đề trong thiết kế : sơ đồ, cách dùng từ, …

‰Kiểm thử cho mỗi giai đọan/phần phát Một sơ đồ“xấu” đồng nghĩa với việc tiềm ẩn nhiều lỗi

„ Chứng thực( validation) Kịch bản kiểm tra(Test cases) và dữ liệu

‰Kiểm thử cho mỗi giai đọan/phần phát Kiểm tra phân tích và thiết kế trên cơ sở các đặc tả về PTTK

 rà soát có cấutrúc

‰Kiểm thử cho mỗi giai đọan/phần phát Kiểm tra phần này thường phát hiện nhiều “vấnđề”

Rà soát(Review): chi phí và lợi ích

 Chi phí

‰Kiểm thử cho mỗi giai đọan/phần phát Thời gian

‰Kiểm thử cho mỗi giai đọan/phần phát Sự nỗ lực thu thập và phân tích các yếu tố (metrics)

‰Kiểm thử cho mỗi giai đọan/phần phát Cải tiến quá trình

„ Chứng thực( validation) Lợi ích

‰Kiểm thử cho mỗi giai đọan/phần phát Lịch biểu ngắn hơn(do loại bỏ lỗi hiệu quả)

‰Kiểm thử cho mỗi giai đọan/phần phát Chu kỳ kiểm tra ngắn hơn, chi phí kiểm thử thấp hơn

‰Kiểm thử cho mỗi giai đọan/phần phát Gia tăng năng suất

‰Kiểm thử cho mỗi giai đọan/phần phát Cải tiến chất lượng sản phẩm

„ Chứng thực( validation) Mấu chốt:

‰Kiểm thử cho mỗi giai đọan/phần phát Những kỹ thuật có tính phản hồi cao nhằm cải tiến

 chất lượng

Mối liên quan Tĩnh và Động

Giống nhau Khác nhau

Các kiểu rà soát

„ Chứng thực( validation) Không chính thức: không có quy trình thực sự, trao đổi ngoài lề, chưa thực sự hữu ích, rẻ, phổ biến.

 Ngang hàng (đồng nghiệp): gồm đồng nghiệp, chuyên gia kỹ thuật… mà không có người quản

lý, quá trình đã được xác lập, lập tài liệu.

 “Lần bước” (Walkthroughs): lần theo tài liệu và mã

 “Thẩmtra”(Inspections): có người trung gian điều phối, đứng đầu 1 nhóm thẩm tra thông qua mộ

quá rình thẩm tra chính thức, có danh mục kiểm định( checklists), mục thông tin (entry), các tiêu chuẩn hiện có.

Quy trình rà soát tổng quát

Vai trò và trách nhiệm

„ Chứng thực( validation) Điều phối(Moderator):

‰Kiểm thử cho mỗi giai đọan/phần phát Chủ trì các cuộc họp

„ Chứng thực( validation) Thư ký:

‰Kiểm thử cho mỗi giai đọan/phần phát Tập hợp thông tin về tìm kiếm lỗi

„ Chứng thực( validation) Tác giả:

‰Kiểm thử cho mỗi giai đọan/phần phát Mô tả, giải thích và trả lời các câu hỏi

„ Chứng thực( validation) Người rà soát (Reviewer/inspector):

‰Kiểm thử cho mỗi giai đọan/phần phát Tìm kiếm lỗi

„ Chứng thực( validation) Người quản lý:

‰Kiểm thử cho mỗi giai đọan/phần phát Lập kế hoạch, sắp xếp tài nguyên và việchuấn luyện,

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

„ Chứng thực( validation) Đôi khi, một ngườicó thể đóng nhiều vai trò

‰Kiểm thử cho mỗi giai đọan/phần phát Tác giả đôi khi đóng vai trò nhưTrung gian

‰Kiểm thử cho mỗi giai đọan/phần phát Một trong những người rà soát làm thư ký

‰Kiểm thử cho mỗi giai đọan/phần phát Đặc tả được xác định bởi kiểu rà soát

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

 „ Chứng thực( validation) Cung cấp huấn luyện

 „ Chứng thực( validation) Rà soát cả sản phẩm–không sản phẩm

 „ Chứng thực( validation) Lập và theo sát lịch/ mục tiêu

 „ Chứng thực( validation) Giới hạn tranh cãi

 „ Chứng thực( validation) Tập trung tìm kiếm “vấn đề”, không đi vào giải quyết

 „ Chứng thực( validation) Nắm rõ các ghi chú đã viết

 „ Chứng thực( validation) Giới hạn, cẩn thận chọn lựa người tham gia

 „ Chứng thực( validation) Phải có sự chuẩn bị

 „ Chứng thực( validation) Lập danh sách “chú ý” kiểm tra

 „ Chứng thực( validation) Duyệt lại các phần Rà soát

 „ Chứng thực( validation) Đúng kỹ thuật

 „ Chứng thực( validation) Bảo đảm hỗ trợ quản lý

 „ Chứng thực( validation) Học–làm tốt hơn

Lỗi thông thường yêu cầu-thiết kế

„ Chứng thực( validation) Mập mờ: nghĩa chính xác là gì ?

‰Kiểm thử cho mỗi giai đọan/phần phát VD: Hệ thống nên cho phép đọc email ISP

 ISP là gì ? Kích cỡ

„ Chứng thực( validation) email ? Cho phép gửi kèm?

„ Chứng thực( validation) 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

„ Chứng thực( validation) mở khóa thì sao ? Ai có quyền

„ Chứng thực( validation) Phụ thuộc quá mức, kết nối và độ phức tạp

 ‰Kiểm thử cho mỗi giai đọan/phần phát Tìm kiếm các sơ đồ ‘tồi” và gây khó hiểu

Tham khảo tài liệu chuẩn IEEE829 : chuẩn Rà Soát