KIỂM THỬ PHẦN MỀM - SOFTWARE TESTING

QUY TRÌNH PHÁT TRIỂN PHẦN MỀM

Đỗ Thị Thu Trang - FIT.UTEHY

1
NỘI DUNG

 Chu trình phát triển phần mềm - SDLC

 Chu trình bảo trì phần mềm - SMLC
 Các mô hình phát triển phần mềm
 Kiểm thử phần mềm trong các mô hình PM

2
NỘI DUNG

 Chu trình phát triển phần mềm - SDLC

 Chu trình bảo trì phần mềm - SMLC
 Các mô hình phát triển phần mềm
 Kiểm thử phần mềm trong các mô hình PM

3
QUY TRÌNH PHÁT TRIỂN PM- SDLC

4
CHU TRÌNH PHÁT TRIỂN PM- SDLC

SDLC (Software Development

Life Cycle): là 1 mô hình khái
niệm mô tả các pha liên quan
trong 1dự án phát triển phần
mềm, từ một nghiên cứu khả thi
ban đầu cho đến khi ứng dụng
hoàn tất .

5
CHU TRÌNH PHÁT TRIỂN PM - SDLC

6
 CHU TRÌNH PHÁT TRIỂN PM - SDLC

 Đặc điểm của một giai đoạn: Initiation

Quality
Gate
 Có các đối tượng và các sản phẩm
làm việc của riêng nó, được sinh ra Definition

bởi quá trình bên trong giai đoạn đó Requirement

Review
 Mỗi GĐ có thể kết hợp với nhau, có Solution
thể lặp đi lặp lại một hoặc nhiều lần,
phụ thuộc vào độ phức tạp của dự Architecture
Review
án Construction

 Đánh giá chất lượng

Được thực thi bởi QA nhằm: Final y
Transition
 Xác định các đối tượng đã phù hợp

chưa Customer
acceptance
 Xác định các sản phẩm đã đúng như Termination
yêu cầu chưa
7
Giai đoạn khởi tạo (Initation)
1.Tổng quan
 Bắt đầu chu trình phần mềm
 Các hoạt động chính

• Thiết lập phạm vi của dự án phần mềm và các điều kiện biên
• Ước lượng chi phí và lập lịch dự án
• Xây dựng đội dự án
• Phác thảo bản kế hoạch dự án
• Xác đinh các rủi ro
• Cung cấp toàn bộ nguồn tài nguyên, công cụ và sự hỗ trợ cần thiết
cho dự án
 Quyết định thực hiện: PM, ngày thực tế bắt đầu dự án

2. Đầu ra
 Tài liệu yêu cầu người dùng (User Requirement Document)
 Bản kế hoạch đề xuất (Proposal)

8
Giai đoạn định nghĩa (Defination)
1.Tổng quan
 Mục tiêu chính của giai đoạn này là hiểu được yêu cầu của KH
 Các hoạt động chính:

• Nghiên cứu và làm rõ về các yêu cầu của KH

• Đàm phán về các điều kiện của KH

• Chỉnh sửa và phát hành bản kế hoạch dự án hoàn thiện

• Xây dựng kế hoạch kiểm thử - test plan

2. Đầu ra
 Kế hoạch dự án - Project Plan
 Kế hoạch kiểm thử - Test plan
 Nguyên mẫu - Prototype

9
Giai đoạn giải quyết vấn đề (Solution)
1.Tổng quan
 Mục tiêu chính của giai đoạn này là xác định một giải pháp hiệu quả
nhằm phù hợp với yêu cầu của KH
 Có các hoạt động chính sau:

• Tạo bản thiết kế mức cao (HLD - High Level Design)

• Tạo bản thiết kế mức thấp (LLD - Low Level Design)

• Tạo Test case, Test data

2. Đầu ra
 Tài liệu thiết kế kiến trúc - Architechture Design Document
 Tài liệu thiết kế chi tiết - Detail Design Document
 Test case, test data

10
Giai đoạn kiến tạo/xây dựng (Contruction)
1.Tổng quan
 Mục tiêu chính của giai đoạn này là xây dựng hệ thống
 Có các hoạt động chính sau:

 Coding
 Testing
2. Đầu ra
 Phần mềm đóng gói
 Test report
 Defect report
 Bản hướng dẫn cài đặt - Installation setup
 Bản hướng dẫn sử dụng - User Guide

11
Giai đoạn chuyển giao (Transition)
1.Tổng quan
 Mục tiêu chính của giai đoạn này là đảm bảo phần mềm sẵn sàng đưa
cho người sử dụng
 Có các hoạt động chính sau:

 Bàn giao phần mềm cho KH

 Hỗ trợ test chấp nhận yêu cầu (User Acceptance Testing - UAT)
2. Đầu ra
 Báo cáo dự án - Project report
 Báo cáo kiểm thử - Test report
 Báo cáo chấp nhận sản phẩm - Acceptance report

12
Giai đoạn kết thúc (Termination)
1.Tổng quan
 Mục tiêu chính của giai đoạn là tổng hợp các kết quả thực hiện của dự án
và cung cấp kiến thức, kinh nghiệm thực hiện dự án cho dự án khác
 Có các hoạt động chính sau:

• Lấy ý kiến chấp nhận sản phẩm của KH

• Tạo dự án tham khảo từ dự án vừa được thực hiện

• Các tài sản của dự án phải được tập hợp và chuyển giao cho công ty
2. Đầu ra
 Khảo sát sự thỏa mãn của KH
 Báo cáo dự án

13
NỘI DUNG

 Chu trình phát triển phần mềm - SDLC

 Chu trình bảo trì phần mềm - SMLC
 Các mô hình phát triển phần mềm
 Kiểm thử phần mềm trong các mô hình PM

14
 CHU TRÌNH BẢO TRÌ PM
Software Maintenance Life Cycle(SMLC)

15
CHU TRÌNH BẢO TRÌ PM - SMLC

16
Giai đoạn khởi tạo (Initation)
1.Tổng quan
 Bắtđầu của chu trình phần mềm
 Các hoạt động chính
• Thiết lập phạm vi phần mềm của dự án và các điều kiện biên
• Ước lượng toàn bộ chi phí và lập lịch dự án
• Xây dựng đội dự án
• Phác thảo bản kế hoạch dự án
• Xác đinh các rủi ro
• Cung cấp tất cả nguồn tài nguyên/công cụ/hỗ trợ cần thiết cho dự án
 Quyết định thực hiện: PM, ngày thực tế bắt đầu dự án
2. Đầu ra
 Bản yêu cầu
 Kế hoạch dự án
 Yêu cầu KH

17
Giai đoạn help desk
1.Tổng quan
 Các hoạt động chính

• Nhận các yêu cầu từ phía KH theo mẫu ví dụ: báo cáo vấn đề gặp
phải hoặc có yêu cầu thay đổi

• Thực hiện công việc đánh giá yêu cầu chính và trả lời cho KH
2. Đầu ra
 Các yêu cầu của KH

18
Giai đoạn sửa lỗi - Bug fixing

1.Tổng quan
 Mục tiêu chính của giai đoạn này sửa các lỗi được gửi tới từ phía KH
với hệ thống cần bảo trì

 Các hoạt động chính

• Phân tích các lỗi gửi đến, code và test

• Test hồi qui - Regression test

2. Đầu ra
 Các yêu cầu của KH

19
Giai đoạn nâng cao (Enhancement)
1.Tổng quan
 Mục tiêu chính của giai đoạn nâng cao cho hệ thống vừa và nhỏ với
sự yêu cầu thay đổi của KH

 Các hoạt động chính:

• Phân tích, và định nghĩa lại

• Code và test lại cho phần mềm có sự thay đổi

2. Đầu ra
 Các tài liệu yêu cầu
 Các tài liệu thiết kế
 Test plan, test case, test data
 Gói phần mềm

20
Giai đoạn phát hành một phần (Release sub)
1.Tổng quan
 Mục tiêu chính của phát hành một phần là đảm bảo rằng phần mềm thay
đổi có thể đáp ứng cho KH
 Các hoạt động chính:

• Phát hành một phần sản phẩm cho KH

• Triển khai phần mềm đã cập nhật tại nơi của KH và tiến hành các hoạt
động test chấp nhận
 Thông thường được chia thành hai loại: khẩn cấp và định kỳ cho
người được ủy nhiệm
2. Đầu ra
 Phần mềm đóng gói
 Biên bản bàn giao
 Báo cáo dự án

21
Giai đoạn chuyển giao (Transition)
1.Tổng quan
 Mục tiêu chính của phát hành là đảm bảo rằng tất cả phần mềm (cả phần
thay đổi) khách hàng đều có thể dùng được
 Các hoạt động chính:

• Thực hiện test hồi qui

• Chuyển giao phần mềm đã cập nhật cho KH, triển khai phần mềm đó
tại nơi KH và có hoat động test chấp nhận cuối cùng
 Thông thường được chia thành hai loại: khẩn cấp và định kỳ cho người
được ủy nhiệm
2. Đầu ra
 Phần mềm đóng gói
 Kế hoạch dự án
 Ghi chú về bàn giao
 Báo cáo dự án

22
Giai đoạn kết thúc (Terminal)
1.Tổng quan
 Mục tiêu chính của phát hành là tóm tắt kết quả đạt được của dự án và
cung cấp kiến thức và kinh nghiệm cho dự án sau

 Kết thúc dự án ở giai đoạn này khi mà KH chấp nhận toàn dự án. Các đánh
giá về dự án được sưu tập và gửi đến công ty.
2. Đầu ra
 Khảo sát sự hài lòng của KH
 Báo cáo dự án
 Báo cáo về chấp nhận KH

23
NỘI DUNG

 Chu trình phát triển phần mềm - SDLC

 Chu trình bảo trì phần mềm - SMLC
 Các mô hình phát triển phần mềm
 Kiểm thử phần mềm trong các mô hình PM

24
CÁC MÔ HÌNH PTPM

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

 Mô hình chữ V - V-model

 Mô hình lặp - Iterative

 Mô hình xoắn ốc - Spiral

 Mô hình RAD (Rapid Application Development)

 Mô hình Agile

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

26
Waterfall - Các giai đoạn phát triển

 Lấy yêu cầu khách hàng: thu thập thông tin về chi
tiết và tính năng của sản phẩm từ khách hàng càng
nhiều càng tốt.
 Thiết kế: lên kế họach xem bạn sẽ sử dụng ngôn
ngữ lập trình nào (Java hay .NET, v.v), cơ sở dữ
liệu nào (Oralce hay MySQL, v.v) cũng như những
tính năng tổng quát cũng như kiến trúc của sản
phẩm.
 Xây dựng: Sau khi thiết kế là giai đoạn xây dựng
(viết code cho sản phẩm).

27
Waterfall - Các giai đoạn phát triển

 Kiểm thử: kiểm tra xem sản phẩm được xây dựng
có đúng theo yêu cầu ban đầu của khách hàng hay
không.
 Triển khai: Triển khai sản phẩm cho khách hàng.
 Bảo trì: Sau khi triển khai sản phẩm cho khách
hàng, bạn có thể sẽ nhận được yêu cầu từ khách
hàng để tùy chỉnh hay chỉnh sửa sản phẩm.

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

 Water fall model xem mô hình sản xuất phần mềm

bao gồm nhiều giai đoạn tách biệt.
 Sau khi hoàn tất một giai đoạn thì mới chuyển
sang giai đoạn khác

29
Ưu điểm - Waterfall

 Kiến trúc kiểu tuần tự ổn định

 Các giai đoạn được định nghĩa đầu vào và đầu ra
rõ ràng. Cơ bản dựa trên tài liệu.
 Sản phẩm phần mềm được hình thành thông qua
chuỗi các hoạt động có trình tự rõ ràng.

30
Ưu điểm - Waterfall

 Kiến trúc kiểu tuần tự ổn định

 Các giai đoạn được định nghĩa đầu vào và đầu ra
rõ ràng. Cơ bản dựa trên tài liệu.
 Sản phẩm phần mềm được hình thành thông qua
chuỗi các hoạt động có trình tự rõ ràng.

31
Nhược điểm - Waterfall

 Giữa các giai đoạn có mối quan hệ rời rạc

 Khó khăn trong việc thay đổi các pha đã được thực
hiện
 Chỉ tiếp xúc với khách hàng ở pha đầu tiên nên PM
không đáp ứng được hết các yêu cầu của KH
 Kéo dài thời gian thực hiện
 Chi phí phát triển dự án lớn
 Khả năng thất bại cao

32
Mô hình chữ V - V-model

33
Mô hình chữ V - V-model

 Mô hình V hiện nay là một trong những quy trình

phát triển phần mềm được sử dụng rộng rãi nhất.
 Tương ứng mỗi giai đoạn của chu kỳ phát triển là
giai đoạn kiểm thử tương ứng.
 Việc thực hiện kiểm tra được diễn ra ngay từ giai
đoạn lấy yêu cầu.
 V mô hình cũng được gọi là mô hình xác minh
(verification) và mô hình xác nhận (validation).

34
Mô hình chữ V - V-model

 Xác minh (verification) : Xác minh là một kỹ thuật

phân tích tĩnh. Trong kiểm thử, kỹ thuật này được
thực hiện mà không phải chạy code. Nó bao gồm
một số hoạt đông như xem lại (review), kiểm tra
(inspection) và kiểm tra từ đầu tới cuối
(walkthrough).
 Xác nhận (validation): Xác nhận là một kỹ thuật
phân tích động, trong đó việc kiểm thử được thực
hiện bằng cách thực hiện code. Ví dụ bao gồm kỹ
thuật kiểm tra chức năng (function) và phi chức
năng (non-function).

35
Khi nào sử dụng V Model?

 Yêu cầu được xác định rõ ràng và không mơ hồ

 Tiêu chí chấp nhận được xác định rõ ràng.
 Dự án có quy mô vừa và nhỏ.
 Công nghệ và công cụ được sử dụng không
thường xuyên thay đổi.

36
Ưu điểm - V Model

 Quá trình phát triển và quy trình quản lý có tính tổ

chức và hệ thống
 Hoạt động tốt cho các dự án có quy mô vừa và
nhỏ.
 Kiểm tra bắt đầu từ khi bắt đầu phát triển vì vậy sự
mơ hồ được xác định ngay từ đầu.
 Dễ dàng quản lý vì mỗi giai đoạn có các mục tiêu
và mục tiêu được xác định rõ ràng.

37
Nhược điểm - V Model

 Không thích hợp cho các dự án lớn và phức tạp

 Không phù hợp nếu các yêu cầu thường xuyên
thay đổi.
 Không có phần mềm làm việc được sản xuất ở giai
đoạn trung gian.
 Không có điều khoản cho việc phân tích rủi ro nên
có sự không chắc chắn và có tính rủi ro.

38
Mô hình lặp - Iterative

 Dựa trên ý tưởng thay vì xây dựng và chuyển giao

một lần thì sẽ chia thành nhiều vòng tăng dần
 Mỗi vòng là một phần kết quả của một chức năng
được yêu cầu
 Các yêu cầu được đánh thứ tự ưu tiên, thứ tự ưu
tiên càng cao thì càng được thực hiện sớm

39
Mô hình lặp - Iterative

40
Mô hình lặp - Iterative

 Ưu điểm:
 Mỗi lần tăng vòng thì có thể chuyển giao kết quả thực hiện
cho KH, nên các chức năng của HT có thể nhìn thấy sớm
hơn
 Các vòng trước đóng vai trò mẫu thử cho vòng sau
 Những chức năng có thứ tự ưu tiên càng cao thì được
kiểm thử càng kỹ

41
Mô hình xoắn ốc - Spiral

42
Mô hình xoắn ốc - Spiral

43
Mô hình xoắn ốc - Spiral

 Phần mềm được xây dựng theo nhiều chu kỳ. Mỗi
chu kỳ tương ứng với một sản phẩn của một giai
đoạn phát triển phần mềm.
 Về bản chất, mô hình mô tả sự phát triển của phần
mềm qua các giai đoạn tiến hóa, mỗi giai đoạn
được coi như là một mô hình thác nước.
 Là một trong những “ứng cử viên” cho mô hình phát
triển phần mềm hiện tại.

44
Spiral - Đặc điểm

 Mô hình bắt đầu từ những gì khái quát nhất để đi

đến chi tiết, với mục đích lập kế hoạch làm chi tiết
hóa sản phẩm qua từng giai đoạn.
 Mô hình là ý tưởng làm giảm thiểu rủi ro thông qua
việc sử dụng các bản mẫu và các công cụ khác.

45
Mô hình Agile - Scrum

46
Mô hình Agile - Scrum

 Mô hình phát triển linh hoạt -Agile là một loại mô

hình gia tăng, phát triển dựa trên quy trình phát triển
lặp.
 Mỗi dự án được chia thành nhiều mảng nhỏ để dễ
sử dụng và thay đổi khi khách hàng yêu cầu thay
đổi
 Từng phần nhỏ của dự án sẽ được test ngay trong
quá trình làm dự án
 Yêu cầu gặp mặt trao đổi thường xuyên vì trong
Agile tại mỗi thời điểm cả nhóm phải cùng tập trung
phát triển một mảng của dự án.
47
Bốn tuyên ngôn của Agile

 Cá nhân và sự tương tác quan trọng hơn là quy

trình và công cụ.
 Ý tưởng là đặt trọng tâm vào con người và sự tương hỗ
giữa những thành viên trong nhóm.
 Cơ bản là nếu dự án có những thành viên có năng lực,
chịu làm việc cùng nhau thì sẽ mang đến thành công cho
dự án.
 Nếu dự án của bạn có quy trình làm việc tốt, được hỗ trợ
những công cụ tốt nhất nhưng những thành viên không
“cùng nhìn về một hướng” thì khả năng dự án thất bại là rất
lớn.

48
Bốn tuyên ngôn của Agile

 Phần mềm chạy tốt hơn là tài liệu đầy đủ

 Trong một số quy trình phát triển phần mềm, việc tạo ra và
cập nhật các tài liệu về sản phẩm là bắt buộc. (Nhóm Dev,
Test, QA)
 Việc tạo và cập nhật tài liệu mất nhiều thời gian và được
cho là buồn tẻ. Vậy tại sao mình phải tập trung quá nhiều
cho việc không cần thiết mà không dành thời gian đó để
trao đổi để hiểu thêm về công việc phải làm.
 Mọi người đừng hiểu lầm là làm Agile là không viết tài liệu.
Ý tưởng là chỉ viết những gì mà mọi người cần đọc.

49
Bốn tuyên ngôn của Agile

 Cộng tác với khách hàng hơn là đàm phán hợp

đồng
 Có nhiều loại khách hàng: Có khách hàng am hiểu về
công nghệ, có người không. Có người suy nghĩ nhất quán
có người thay đổi xoành xoạch, có người lạnh lùng có
người cười nói suốt ngày, v.v....
 Cách duy nhất để có thể làm việc tốt là phải cộng tác với
khách hàng để hiểu được khách hàng muốn gì và cần gì
để có thể tư vấn và điều chỉnh thay vì chỉ dựa vào những
điều đã quy định trong hợp đồng.

50
Bốn tuyên ngôn của Agile

 Phản hồi thay đổi hơn là bám sát kế hoạch

 Hầu hết những dự án, không có dự án nào không có sự
thay đổi điều chỉnh khi thực thi.
 Sự thay đổi đó có thể là thay đổi về yêu cầu, thay đổi công
nghệ, thay đổi nhân sự, thay đổi deadline, thay đổi phương
thức làm việc, v.v
 Agile không khuyến khích cho sự thay đổi nhưng khuyến
khích chúng ta tập thích nghi với thay đổi.

51
Các nguyên tắc trong Agile

 Ưu tiên cao nhất của chúng tôi là thỏa mãn khách

hàng thông qua việc chuyển giao sớm và liên tục
các phần mềm có giá trị.
 Chào đón việc thay đổi yêu cầu, thậm chí rất muộn
trong quá trình phát triển. Các quy trình linh hoạt tận
dụng sự thay đổi cho các lợi thế cạnh tranh của
khách hàng.
 Thường xuyên chuyển giao phần mềm chạy tốt tới
khách hàng, từ vài tuần đến vài tháng, ưu tiên cho
các khoảng thời gian ngắn hơn.

52
Các nguyên tắc trong Agile

 Nhà kinh doanh và nhà phát triển phải làm việc

cùng nhau hàng ngày trong suốt dự án.
 Xây dựng các dự án xung quanh những cá nhân có
động lực. Cung cấp cho họ môi trường và sự hỗ trợ
cần thiết, và tin tưởng họ để hoàn thành công việc.
 Phương pháp hiệu quả nhất để truyền đạt thông tin
tới nhóm phát triển và trong nội bộ nhóm phát triển
là hội thoại trực tiếp.
 Phần mềm chạy tốt là thước đo chính của tiến độ.
 Liên tục quan tâm đến các kĩ thuật và thiết kế tốt để
gia tăng sự linh hoạt.
53
Các nguyên tắc trong Agile

 Các quy trình linh hoạt thúc đẩy phát triển bền
vững. Các nhà tài trợ, nhà phát triển, và người dùng
có thể duy trì một nhịp độ liên tục không giới hạn.
 Sự đơn giản – nghệ thuật tối đa hóa lượng công
việc chưa xong – là căn bản.
 Các kiến trúc tốt nhất, yêu cầu tốt nhất, và thiết kế
tốt nhất sẽ được làm ra bởi các nhóm tự tổ chức.
 Đội sản xuất sẽ thường xuyên suy nghĩ về việc làm
sao để trở nên hiệu quả hơn, sau đó họ sẽ điều
chỉnh và thay đổi các hành vi của mình cho phù
hợp.
54
Ưu điểm - Mô hình Agile

 Agile là sự lựa chọn rất tốt cho những dự án nhỏ

bởi những dự án nhỏ thường có những yêu cầu
không được xác định rõ ràng và có thể thay đổi
thường xuyên.
 Với Agile khách hàng có thể được xem trước từng
phần dự án trong suốt quá trình phát triển vì
Agile phát triển phần mềm theo hướng tăng dần, có
thể đưa cho khách hàng xem từng phần đã thực
hiện hoàn thành. Từ đó có thể bám sát dự án và
luôn sẵn sàng cho bất kỳ thay đổi nào từ phía khách
hàng yêu cầu về dự án.

55
Ưu điểm - Mô hình Agile

 Agile chia dự án thành những phần nhỏ và giao cho

mỗi người, hàng ngày tất cả mọi người phải họp với
nhau trong khoảng thời gian ngắn để thảo luận về
tiến độ và giải quyết những vấn đề nảy sinh nếu có
nhằm đảm bảo đúng quy trình phát triển dự án.
 Tỉ lệ thành công của các dự án sử dụng Agile
thường cao hơn các quy trình khác.

56
Nhược điểm - Mô hình Agile

 Thiếu sự nhấn mạnh về thiết kế và tài liệu cần thiết

 Quy mô nhân lực thường giới hạn từ 7 đến 10
người, sẽ có trở ngại lớn nếu nguồn nhân lực yêu
cầu vượt quá con số này ví dụ trong các cuộc họp
trao đổi.
 Số lượng yêu cầu có thể nhiều,khó quản lý nếu như
nó bao gồm nhiều khía cạnh khác nhau về dự án.
 Số lượng nhân lực càng tăng, chất lượng càng khó
kiểm soát hơn. Việc kiểm tra mã thường xuyên và
thiết lập các chỉ tiêu đánh giá năng lực của lập trình
viên cho phép giảm thiểu nhược điểm này.
57
NỘI DUNG

 Chu trình phát triển phần mềm - SDLC

 Chu trình bảo trì phần mềm - SMLC
 Các mô hình phát triển phần mềm
 Kiểm thử phần mềm trong các mô hình PM

58
KTPM TRONG MÔ HÌNH PTPM
CHU TRÌNH PHẦN MỀM

TÓM LẠI
Nội dung bài học gồm

1. SDLC 2. SMLC 3. Model of SD 4. ST in MSD

Chu trình phát Chu trình bảo Các mô hình KTPM trong mô
triển phần mềm trị phần mềm phát triển PM hình PTPM

60
Tài liệu tham khảo

 Bộ môn CNPM - Khoa CNTT, Đề cương Kiểm thử phần mềm, Đại
học Sư phạm Kỹ Thuật Hưng Yên.

 https://viblo.asia/p/cac-mo-hinh-phat-trien-phan-mem-
GrLZDwbgKk0

 https://viblo.asia/p/vong-doi-kiem-thu-trong-mot-vai-mo-hinh-phat-
trien-phan-mem-pho-bien-hien-nay-WAyK8R6klxX

 https://viblo.asia/p/tong-quan-ve-agile-va-kiem-thu-phan-mem-
trong-mo-hinh-agile-Az45bpBQZxY

61
TỔNG KẾT

QUESTION/ ANSWER

62