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

 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À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

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í

“Testing is important because software bugs could be expensive or even dangerous.”

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:

 Waterfall model (thác nước)

 Spiral model ( mô hình xoắn)

 Agile model (scrum process)

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ì?

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

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à

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

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

để lập kế hoạch cho từng Sprint (gọi là Scrum Meeting) Kết quả của buổi lập kế

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)

Integration testing System testing Acceptance testing

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

Quy trình kiểm thử