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

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?


SOFTWARE TESTING là gì?








Kiểm thử phần mềm (software testing) là hoạt động nhằm tìm kiếm, phát hiện
các lỗi của phần mềm
Kiểm thử phần mềm còn hướng đến mục tiêu xa hơn có thể gọi là “phịng bệnh
hơn chữa bệnh”. Tức là nâng cao khả năng kiểm soát và hạn chế các lỗi xảy ra
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ử:








Software tester
Software developer
Project Leader/ Manager
End User

Điều gì xảy ra nếu việc kiểm thử khơng tìm được lỗi trong phần mềm hoặc phát hiện
quá ít lỗi
 Phần mềm có chất lượng q tốt
 Quy trình/Đội ngũ kiểm thử hoạt động không hiệu quả


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)
V model
Iterative and Incremental model
(mơ hình lặp và tăng dần)
RAD model (mơ hình phát triển
ứng dụng nhanh)
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 ngồ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/
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 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ử
tồ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.


Mơ hình chữ V – V model




Trong mơ hình Waterfall, kiểm thử được thực hiện
trong một giai đoạn riêng biệt. Cịn với mơ hình chữ
V, tồn bộ qui trình được chia thành hai nhóm giai
đoạn tương ứng nhau: phát triển và kiểm thử. Mỗi
giai đoạn phát triển sẽ kết hợp với một giai đoạn
kiểm thử tương ứng
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


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
xố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 q 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 hồn chỉnh có thể chuyển giao được (Potentially Shippable Product
Increment)


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


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à hồ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 q 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 để hồ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 ln ln đượ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 đã hồ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à sốt lại tồ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 hồ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.