Xem mẫu
- 21/07/2020
Chương 1. Tổng quan về
kiểm thử phần mềm
1.1. Khái niệm phát triển phần mềm
1.1.1. Khái niệm phần mềm
1.1.2. Vòng đời phát triển phần mềm
1.1.3. Các mô hình phát triển phần mềm
1.2. Khái niệm kiểm thử phần mềm
1.2.1. Khái niệm kiểm thử
Bộ môn Công nghệ thông tin 1.2.2. Đảm bảo chất lượng
Trường Đại học Thương mại 1.2.3. Kiểm soát chất lượng sản phẩm
1.3. Các nguyên tắc kiểm thử
1.4. Vai trò kiểm thử phần mềm
4
Tài liệu tham khảo 1.1.1. Khái niệm phần mềm
Ian Sommerville, Software Engineering, 10th Khái niệm phần mềm
Edition, 2016. Một phần mềm gồm 3 thành phần:
Glenford J. Myers, Tom Badgett, Todd M. Chương trình máy tính: mã nguồn, mã máy
Thomas, Corey Sandler, The Art of Software Cấu trúc dữ liệu: cấu trúc làm việc (bộ nhớ trong) và cấu trúc
lưu trữ (bộ nhớ ngoài)
Testing, 2011. Các tài liệu liên quan: tài liệu hướng dẫn sử dụng (dành cho
người dùng), tài liệu phát triển (dành cho người phát triển
Ron Patton, Software Testing, Second Edition, hệ thống), tài liệu tham khảo kỹ thuật (dành cho người bảo
Sam Publishing, 2009. trì)
http://www.seleniumframework.com/ Phần mềm được coi là tất cả các kỹ thuật
ứng dụng để thực hiện những dịch vụ chức
http://www.tester.vn/ năng cho mục đích nào đó bằng phần cứng,
http://www.testingvn.com/ làm cho sử dụng phần cứng máy tính đạt
hiệu quả cao.
2 5
Nội dung 1.1.1. Khái niệm phần mềm
Chương 1. Tổng quan về kiểm thử
phần mềm
Chương 2. Quy trình kiểm thử phần
mềm
Chương 3. Các công cụ kiểm thử phần
mềm
Chương 4. Thiết kế ca kiểm thử
3 6
1
- 21/07/2020
Nhóm kỹ thuật, phương pháp luận 1.1.2. Vòng đời phát triển PM
Các khái niệm và trình tự cụ thể hóa Là khoảng thời gian tính từ khi phần
một hệ thống mềm được đề xuất cho đến khi bỏ đi:
Các phương pháp tiếp cận giải quyết cụ thể là từ khi được đặt hàng, phát
vấn đề triển, sử dụng đến khi bị loại bỏ.
Các trình tự thiết kế và phát triển Vòng đời phần mềm được phân chia
được chuẩn hóa thành các pha chính như xác định yêu
Các phương pháp đặc tả yêu cầu, thiết cầu, triển khai, kiểm thử, bảo trì (vận
kế hệ thống, thiết kế chương trình, hành)... Phạm vi, thứ tự các pha khác
kiểm thử, toàn bộ quy trình quản lý nhau tùy theo từng mô hình, dự án cụ
phát triển phần mềm. 7
thể 10
Nhóm chương trình 1.1.2. Vòng đời phát triển PM
Là phần giao diện với phần cứng, tạo thành từ các nhóm Tùy mô hình áp dụng mà việc phân
lệnh chỉ thị cho máy tính biết trình tự thao tác xử lý dữ
liệu chia các pha, các bước có thể có sự
Phần mềm cơ bản: với chức năng cung cấp môi trường khác nhau: từ 3 đến 20 pha.
thao tác dễ dàng cho người sử dụng nhằm tăng hiệu năng
xử lý của phần cứng (ví dụ như OS là chương trình hệ
thống) Xác định yêu cầu Triển khai Kiểm thử
Phần mềm ứng dụng: dùng để xử lý nghiệp vụ thích hợp
nào đó (quản lý, kế toán, . . .), phần mềm đóng gói, phần
(VËn hµnh) Bảo trì
mềm của người dùng, . . .
Vòng đời phần mềm
8 11
1.1.2. Vòng đời phát triển PM
Nhóm các tư liệu
Những tư liệu hữu ích, có giá trị cao và Các giai đoạn phát triển phần mềm
rất cần thiết để phát triển, vận hành và 1. Phân tích tính khả thi và đặc tả yêu cầu
bảo trì phần mềm 2. Phân tích
3. Thiết kế
Để xây dựng phần mềm với độ tin cậy
4. Mã hóa
cao cần tạo ra các tư liệu chất lượng
5. Kiểm thử
cao: đặc tả yêu cầu, mô tả thiết kế từng
6. Cài đặt
loại, điều kiện kiểm thử, thủ tục vận
7. Bảo trì
hành, hướng dẫn thao tác, …
9 12
2
- 21/07/2020
Phân tích tính khả thi
3. Đặc tả yêu cầu: Pha này sẽ tư liệu hoá những thông tin thu thập được.
Phân tích tính khả thi Có hai loại yêu cầu cần được xác định:
* Yêu cầu của người sử dụng: là những yêu cầu bằng ngôn ngữ tự nhiên bổ
Xác định vấn đề cần giải quyết sung thêm cho các biểu đồ của các dịch vụ mà hệ thống cung cấp và các
ràng buộc vận hành của nó. Kiểu yêu cầu này được viết bởi người sử
Xem xét các giải pháp và kỹ thuật khác nhau dụng.
* Yêu cầu hệ thống: là những tài liệu có cấu trúc mô tả chi tiết về các chức
(đánh giá ưu nhược điểm của từng giải năng, dịch vụ và các ràng buộc vận hành của hệ thống. Yêu cầu hệ thống
pháp) sẽ định nghĩa những gì cần phải xây dựng, cho nên nó có thể trở thành
bản hợp đồng giữa khách hàng và nhà thầu.
Đánh giá về thời gian, giá thành, nguồn tài 4. Đánh giá yêu cầu: pha này sẽ kiểm tra lại các yêu cầu xem chúng có
đúng thực tế hay không, có thống nhất không, có đầy đủ không. Nếu
nguyên cần thiết phát hiện ra lỗi thì ta phải chỉnh sửa các lỗi này.
Sản phẩm: tài liệu phân tích
13 16
Đặc tả yêu cầu Đặc tả yêu cầu
Phân tích và đặc tả yêu cầu Xác định nhu cầu của khách hàng/người sử
dụng
Xác định bài toán, chứ không phải là giải pháp
Khó khăn
Khách hàng không biết rõ cái họ cần
Khách hàng không trình bày rõ cái họ muốn thay đổi
Sản phẩm: tài liệu đặc tả yêu cầu
14 17
Đặc tả yêu cầu Thiết kế phần mềm
Đặc tả yêu cầu (hay còn gọi là kỹ thuật xác định yêu cầu) là quy Thiết kế phần mềm là quá trình thiết kế cấu trúc phần mềm dựa trên
trình tìm hiểu và định nghĩa những dịch vụ nào được yêu cầu những tài liệu đặc tả. Hoạt động thiết kế bao gồm những công việc
và các ràng buộc trong quá trình vận hành và xây dựng hệ chính sau:
thống. Thiết kế kiến trúc: Các hệ thống con cấu thành lên hệ thống cần xây dựng
Quy trình xác định yêu cầu bao gồm bốn pha chính: và mối quan hệ giữa chúng được xác định và tư liệu hoá.
1. Nghiên cứu khả thi: Nghiên cứu khả thi giúp xác định Đặc tả trừu tượng: với mỗi hệ thống con, phải có một bản đặc tả về các
những yêu cầu của người sử dụng có thoả mãn những công dịch vụ của nó và những ràng buộc khi nó vận hành.
nghệ hiện tại hay không. Về góc độ kinh doanh, nghiên cứu Thiết kế giao diện: với mỗi hệ thống con, các giao diện của nó với những
khả thi nhằm xác định hệ thống đưa ra có mang lại lợi hệ thống con khác phải được thiết kế và tư liệu hoá.
nhuận không. Việc nghiên cứu khả thi nên được thực hiện Thiết kế thành phần: các dịch vụ cung cấp cho các thành phần khác và các
một cách nhanh chóng và không quá tốn kém. Kết quả của giao diện tương tác với chúng phải được thiết kế.
việc nghiên cứu khả thi sẽ xác định có nên tiếp tục xây dựng Thiết kế cấu trúc dữ liệu: cấu trúc dữ liệu được sử dụng để cài đặt hệ
hệ thống nữa hay không. thống phải được thiết kế một cách chi tiết và cụ thể.
2. Phân tích và rút ra các yêu cầu: đây là quy trình đưa ra các Thiết kế thuật toán: Các thuật toán được sử dụng để cung cấp các dịch vụ
yêu cầu hệ thống thông qua một số phương pháp như: quan phải được thiết kế chi tiết và chính xác.
sát hệ thống hiện tại, phỏng vấn và thảo luận với người sử
dụng, phân tích nhiệm vụ, phân tích tài liệu hoặc hệ thống
cũ … Trong pha này, chúng ta có thể phải xây dựng một hoặc
nhiều mô hình hệ thống và các mẫu thử.
15 18
3
- 21/07/2020
Phân tích Mã hóa và gỡ rối
Mã hóa và gỡ rối
Mã hóa: cài đặt các thiết kế bằng ngôn ngữ
lập trình không đơn thuần chỉ là lập trình
Viết tài liệu
Chuẩn lập trình
Lập trình theo cấp
Công cụ
Quản lý phiên bản
Gỡ rối: phát hiện các lỗi trong quá trình lập
trình
Sản phẩm: chương trình
19 22
Thiết kế phần mềm Kiểm thử
Các công việc trong thiết kế phần mềm Kiểm thử - Đánh giá phần mềm hay
còn gọi là thẩm tra và đánh giá (V&V -
Verification and validation) được sử
dụng để chỉ ra rằng hệ thống đã thực
hiện theo đúng các đặc tả và thoả mãn
mọi yêu cầu của khách hàng.
Kiểm thử bao gồm các công đoạn:
kiểm tra, xem xét lại, và kiểm thử hệ
thống. Kiểm thử hệ thống tức là cho hệ
thống thực hiện trên những trường
20 hợp có dữ liệu thật được lấy từ tài liệu23
đặc tả hệ thống. Quy trình kiểm thử
Thiết kế phần mềm Bảo trì hệ thống
Các phương pháp thiết kế Bảo trì hệ thống:
Hướng chức năng
Bảo đảm chương trình vận hành tốt
Hướng đối tượng
Cài đặt các thay đổi
Cài đặt các yêu cầu mới
Xử lý các lỗi khi vận hành
Sản phẩm: chương trình
21 24
4
- 21/07/2020
1.1.3. Các mô hình phát triển PM
Bảo trì hệ thống
Hiện nay có rất nhiều mô hình phát
Cải tiến phần mềm triển phần mềm, và thường được phân
Khi các yêu cầu hệ thống thay đổi theo sự thành 2 loại: mô hình tuyến tính và mô
thay đổi của các yêu cầu nghiệp vụ thì phần hình lặp.
mềm phải cải tiến và thay đổi để hỗ trợ
Mô hình tuyến tính: các bước được thực
khách hàng. Thông thường chi phí để bảo trì
hiện tuần tự, không lặp lại.
và cải tiến thường đắt hơn nhiều so với chi Mô hình thác nước
phí xây dựng phần mềm. Mô hình V…
Mô hình lặp: các bước có thể thực hiện song
song, có thể lặp lại một số bước.
Mô hình tiến hóa
Mô hình xoắn ốc
25 Mô hình hợp nhất… 28
1.1.2. Vòng đời phát triển phần mềm a. Mô hình Thác nước
Mô hình thác nước (Water Fall Model)
26 29
1.1.2. Vòng đời phát triển phần mềm a. Mô hình Thác nước
Các pha của mô hình thác nước bao
Kiểm thử cần thực hiện trong suốt gồm:
vòng đời của phần mềm Phân tích và xác định các yêu cầu
Kiểm thử không tồn tại độc lập. Thiết kế hệ thống và phần mềm
Các hoạt động của kiểm thử luôn gắn liền với Cài đặt và kiểm thử đơn vị
các hoạt động phát triển phần mềm.
Tích hợp và kiểm thử hệ thống
Các mô hình phát triển phần mềm khác nhau
Vận hành và bảo trì.
cần các cách tiếp cận test khác nhau.
27 30
5
- 21/07/2020
a. Mô hình Thác nước b. Mô hình V
Bảo trì
Là mô hình cổ điển
Phương pháp áp dụng 1 lần Phân tích yêu Kiểm thử chấp
cầu nhận
Điều khiển hiệu quả
Thiết kế hệ Kiểm thử hệ
Phạm vi giới hạn của vòng lặp thống thống
Vòng đời dài Thiết kế Kiểm thử đơn vị và
chương trình tích hợp
Không thích hợp với các hệ thống
không rõ ràng Lập trình
31 34
Ứng dụng b. Mô hình V
Trong mô hình thác nước, năm pha trên phải
được thực hiện một cách tuần tự; kết thúc pha Trong mô hình V:
trước, rồi mới được thực hiện pha tiếp theo. Do
đó, nhược điểm chính của mô hình thác nước là Các tiến trình kiểm thử được thêm vào
rất khó khăn trong việc thay đổi các pha đã được
thực hiện. Giả sử, pha phân tích và xác định yêu
cầu đã hoàn tất và chuyển sang pha kế tiếp, nhưng Kết nối kiểm thử với phân tích và thiết kế
lúc này lại có sự thay đổi yêu cầu của người sử
dụng; thì chỉ còn cách là phải thực hiện lại từ đầu. Thích hợp với những trường hợp bài toán
Mô hình này chỉ thích hợp khi các yêu cầu đã
được tìm hiểu rõ ràng và những thay đổi sẽ được không nhất quán
giới hạn một cách rõ ràng trong suốt quá trình
thiết kế. Tuy nhiên, trong thực tế có rất ít những
hệ thống nghiệp vụ có các yêu cầu ổn định.
32 35
Nhận xét b. Mô hình V
Ưu điểm: Toà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
Chỉ phù hợp với các dự án nhỏ hoặc
giai đoạn phát triển sẽ tiến hành song song với một
Yêu cầu xác định giai kiểm thử tương ứng => các lỗi được phát hiện
Nhược điểm: sớm ngay từ đầu
Tinh thần chủ đạo của V-model là các hoạt động kiểm
Không phù hợp với dự án lớn
thử phải được tiến hành song song (theo khả năng có
Thời gian thực hiện lâu 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.
33 36
6
- 21/07/2020
b. Mô hình V c. Mô hình bản mẫu
Giai đoạn phát triển:
Xác định yêu cầu và đặc tả (Requirement & Specification): Xác định
Mục đích
yêu cầu cần thiết mà hệ thống đòi hỏi, đưa ra bản đặc tả. Xem xét yêu cầu người sử dụng ở giai đoạn
Phân tích hệ thống (System Analysis): Phân tích các yêu cầu mà hệ
thống cần có và đưa ra giải pháp tích hợp các yêu cầu đó vào hệ thống.
ban đầu
Thiết kế chi tiết (Detailed Design): Chi tiết hóa các bước thực hiện xây Giảm bớt rủi ro và không chắc chắn
dựng hệ thống (Về cả giao diện và nội dung).
Phát triển (Development ): Thực hiện việc viết code Kiểm chứng thiết kế và thực thi
Giai đoạn kiểm thử:
Nên thường xuyên trả lời các câu hỏi
Kiểm tra từng thành phần và tích hợp (Unit & Intergration Test): Kiểm
tra các module của hệ thống tương ứng với pha thiết kế chi tiết. chuyên biệt; mục đích phải được xác
Kiểm thử toàn hệ thống (System Test): kiểm thử hoạt động của hệ thống
(về chức năng, giao diện). định.
Nghiệm thu (Accepted Test): Kiểm tra lần cuối cùng và nghiệm thu sản
phẩm đưa vào sử dụng.
37 40
b. Mô hình V Lợi ích của bản mẫu
Với V model thì công việc test được tham gia ngay từ đầu, từ Học bằng cách làm việc
lúc lấy yêu cầu là có thể "test" bằng cách review tài liệu yêu
cầu, rồi cho tới review đặc ta chi tiết, các bản thiết kế,... review Tăng cường giao tiếp
code rồi cuối cùng là test ở mức thấp nhất - từng module, chức
năng, màn hình,... đến test tích hợp rồi kiểm thử hệ thống. Tăng sự tham gia của người dùng vào
So với mô hình khác thì ở mô hình này, công việc test đi sát dự án
hơn và ngay từ đầu khi bắt đầu phát triển. Chắc chắn chất
lượng dự án sẽ tốt hơn. Nhưng tại sao người ta vẫn tiếp tục đưa Làm rõ các yêu cầu chỉ biết một phần
ra mô hình phát triển khác? Vì ở mô hình chữ V này người ta
vẫn phát triển cùng lúc cả hệ thống (nhiều yêu cầu, chức năng
cùng lúc) mà rủi ro (risk) về thay đổi yêu cầu là rất lớn. Nên
mô hình này vẫn có thể gặp rắc rối khi khách hàng thường
xuyên thay đổi yêu cầu.
38 41
c. Mô hình bản mẫu Tuần tự làm bản mẫu
Tập hợp yêu cầu
Thiết kế nhanh
Nghe Khách Tạo / sửa
trình bày bản mẫu Xây dựng bản mẫu
Đánh giá của khách hàng
Làm mịn
Khách kiểm tra
bản mẫu
Quay lại thiết kế nhanh để điều chỉnh
Mô hình bản mẫu (Prototyping model) Xây dựng sản phẩm
39 42
7
- 21/07/2020
Đánh giá d. Mô hình xoắn ốc
Ưu điểm: phù hợp với
Hệ thống rủi ro cao Lập kế hoạch
Phân tích rủi ro
Yêu cầu không chắc chắn
Giao tiếp
Giao diện chưa rõ ràng khách hàng
Khái niệm
Chiến lược cài đặt chưa rõ ràng Thiết kế
Làm mới
Nâng cấp
Khách hàng Xây dựng &
đánh giá Xuất xưởng
Bảo trì
Mô hình xoắn ốc (spiral)
43 46
Đánh giá d. Mô hình xoắn ốc
Hạn chế: (Boehm 1987)
Chi phí tăng thêm
Khách hàng có thể cho rằng nguyên mẫu là
Xác định mục đích, Đánh giá lựa chọn;
hệ thống thực lựa chọn và ràng Phân tích
xác định và giải
buộc rủi ro quyết rủi ro
Mong đợi không thực tế về tiến triển của dự án Phân tích
rủi ro
Người phát triển có sự chọn lựa không tốt
Phân tích
rủi ro Bản mẫu
Bản mẫu
Phù hợp cho nguyên mẫu, nhưng không phù hợp cho hệ Bản mẫu
thống thực Lập kế hoạch
yêu cầu
Chức năng Yêu cầu phần
mềm
Thiết kế
hệ
Thiết kế
chi tiết
thống
Nguyên mẫu không giống hoàn toàn hệ Lập kế hoạch
phát triển
Kiểm thử yêu
cầu
thống cuối cùng
Lập
Kế hoạch kiểm trình
thử và tích hợp Kiểm thử
Khách hàng sẽ có các phản ứng khác nhau thiết kế Kiểm
thử Phát triển và kiểm
Kế hoạch cho giai đoạn tiếp Tích hợp và đơn vị chứng sản phẩm
Kiểm thử kiểm thử
chấp nhận mức tiếp theo
44 47
Ứng dụng d. Mô hình xoắn ốc
Trong mô hình xoắn ốc, quy trình phát triển phần mềm
Mô hình bản mẫu thường được sử dụng được biểu diễn như một vòng xoắn ốc. Các pha trong quy
khi: trình phát triển xoắn ốc bao gồm:
Thiết lập mục tiêu: xác định mục tiêu cho từng pha của dự án.
Khi mới rõ mục đích chung chung của phần
Đánh giá và giảm thiểu rủi ro: rủi ro được đánh giá và thực hiện các
mềm, chưa rõ chi tiết đầu vào hay xử lý ra sao hành động để giảm thiểu rủi ro.
hoặc chưa rõ yêu cầu đầu ra Phát triển và đánh giá: sau khi đánh giá rủi ro, một mô hình xây
dựng hệ thống sẽ được lựa chọn từ những mô hình chung.
Dùng như “Hệ sơ khai” để thu thập yêu cầu Lập kế hoạch: đánh giá dự án và pha tiếp theo của mô hình xoắn ốc
người dùng qua các thiết kế nhanh sẽ được lập kế hoạch.
Các giải thuật, kỹ thuật dùng làm bản mẫu có
thể chưa nhanh, chưa tốt, miễn là có mẫu để
thảo luận gợi yêu cầu của người dùng
45 48
8
- 21/07/2020
d. Mô hình xoắn ốc Đánh giá
Nhấn mạnh việc đánh giá các rủi ro Ưu điểm
Phần mềm được xây dựng theo nhiều Hạn chế rủi ro sớm
chu kỳ. Mỗi chu kỳ tương ứng với một Nhận được phản hồi ( feedbacks) từ khách
sản phẩm của 1 giai đọan phát triển hàng sớm
Dễ kiểm soát các mạo hiểm ở từng mức tiến hóa
Xác định các mục tiêu, giải pháp, ràng buộc
Đánh giá các giải pháp, xác định các nguy cơ
Hạn chế
và tìm cách giải quyết chúng Khó thuyết phục khách hàng là phương pháp tiến hóa
xoắn ốc có thể kiểm soát được
Phát triển và kiểm thử sản phẩm của chu kỳ
Chưa được dùng rộng rãi như các mô hình tuyến tính
này hoặc chế thử.
Lập kế hoạch cho chu kỳ tiếp theo 49 52
d. Mô hình xoắn ốc (tiếp) Ứng dụng
Giao tiếp khách hàng: giữa người phát triển và khách Mô hình xoắn ốc phù hợp với
hàng để tìm hiểu yêu cầu, ý kiến Các hệ phần mềm quy mô lớn, các dự án lớn,
Lập kế hoạch: Xác lập tài nguyên, thời hạn và những phức tạp
thông tin khác Hệ thống cần phát triển nhiều phiên bản
Phân tích rủi ro: Xem xét mạo hiểm kỹ thuật và mạo Các hệ thống có yêu cầu chưa xác định rõ ràng
hiểm quản lý
Thiết kế: Xây dựng một hay một số biểu diễn của
ứng dụng
50 53
d. Mô hình xoắn ốc (tiếp) e. Mô hình hợp nhất
Mô hình hợp nhất sử dụng Các kỹ thuật thế hệ 4
(Fourth generation techniques): Tập hợp các công cụ
Xây dựng và xuất xưởng: xây dựng, kiểm thử, cho phép xác định đặc tính phần mềm ở mức cao, sau
cài đặt và cung cấp hỗ trợ người dùng (tư liệu, đó tự động sinh mã nguồn dựa theo đặc tả đó.
huấn luyện, . . .) Các công cụ 4GT điển hình: ngôn ngữ phi thủ tục cho
truy vấn CSDL, tạo báo cáo, xử lý dữ liệu, tương tác
Đánh giá của khách hàng: Nhận các phản hồi màn hình, tạo mã nguồn, khả năng đồ họa bậc cao, khả
của người sử dụng về biểu diễn phần mềm trong năng bảng tính, khả năng giao diện Web.
Từ thu thập yêu cầu cho đến sản phẩm: đối thoại giữa
giai đoạn kỹ nghệ và cài đặt khách và người phát triển là quan trọng.
Không nên bỏ qua khâu thiết kế: 4GT chỉ áp dụng để
triển khai thiết kế qua ngôn ngữ lập trình thế hệ 4
(4GL- Fourth-generation programming language).
51 54
9
- 21/07/2020
e. Mô hình hợp nhất e. Mô hình hợp nhất
Tiến trình hợp nhất có thể được nhìn Góc nhìn kỹ thuật
dưới hai góc nhìn khác nhau
Góc nhìn quản lý: quan tâm đến lĩnh vực
kinh tế, chiến thuật, con người.
Tiến trình gồm 4 giai đoạn.
Góc nhìn kỹ thuật: quan tâm đến công nghệ,
kiểm tra chất lượng, phương pháp.
Tiến trình gồm nhiều bước lặp.
55 58
e. Mô hình hợp nhất e. Mô hình hợp nhất
Góc nhìn quản lý Kết hợp hai góc nhìn
56 59
e. Mô hình hợp nhất e. Mô hình hợp nhất
Góc nhìn kỹ thuật: các bước lặp Mô hình hợp nhất và UML
Mỗi bước lặp gồm các hoạt động
Đặc tả
Phân tích
Thiết kế
Mã hóa
Kiểm thử
Cài đặt
Mỗi bước lặp là một tiến trình thác đổ
57 60
10
- 21/07/2020
e. Mô hình hợp nhất f. Mô hình Agile: quy trình Scrum
Ưu điểm: giảm thời gian phát triển và Scrum là một quy trình phát triển phần mềm theo
tăng năng suất lao động. mô hình linh hoạt (agile). Vì thế, nó tuân thủ các
nguyên tắc của Agile
Nhược điểm: 4GT khó dùng hơn ngôn
Scrum rất linh hoạt như các phương pháp Agile
ngữ lập trình, mã khó tối ưu và khó khác. Nhờ đó nó mang lại tính thích nghi rất cao.
bảo trì cho hệ thống lớn cần kỹ Dựa trên các thông tin minh bạch hóa từ các quá
năng của kỹ sư phần mềm trình thanh tra và làm việc, Scrum có thể phản hồi
Trong tương lai: kết hợp 4GT với mô lại các thay đổi một cách tích cực, nhờ đó mang
hình hướng thành phần. lại thành công cho dự án.
61 64
f. Mô hình Agile: quy trình Scrum f. Mô hình Agile: quy trình Scrum
Agile là một phương pháp phát triển phần mềm linh hoạt để
làm sao đưa sản phẩm đến tay người dùng càng nhanh càng tốt Các công cụ (artifacts) Scrum
càng sớm càng tốt. Product backlog: Đây là danh sách ưu tiên các tính năng
Đặc trưng Agile: (feature) hoặc đầu ra khác của dự án, có thể hiểu như là
danh sách yêu cầu (requirement) của dự án. Product Owner
◦Tính lặp (Iterative): Dự án sẽ được thực hiện trong các phân
đoạn lặp đi lặp lại. Các phân đoạn (được gọi là Iteration hoặc
chịu trách nhiệm sắp xếp độ ưu tiên cho từng hạng mục
Sprint) này thường có khung thời gian ngắn (từ 1 – 4 tuần). Trong (Product Backlog Item) trong Product Backlog dựa trên các
mỗi phân đoạn này, nhóm phát triển thực hiện đầy đủ các công giá trị do Product Owner định nghĩa
việc cần thiết như lập kế hoạch, phân tích yêu cầu, thiết kế, triển Sprint backlog: Đây là bản kế hoạch cho một Sprint; là kết
khai, kiểm thử (với các mức độ khác nhau) để cho ra các phần quả của buổi họp lập kế hoạch (Sprint Planning). Với sự kết
nhỏ của sản phẩm. hợp của Product Owner, nhóm sẽ phân tích các yêu cầu theo
◦Các phân đoạn (Sprint) lặp đi lặp lại trong Agile: Các phương độ ưu tiên từ cao xuống thấp để hiện thực hóa các hạng mục
pháp Agile thường phân rã mục tiêu thành các phần nhỏ với quá trong Product Backlog dưới dạng danh sách công việc
trình lập kế hoạch đơn giản và gọn nhẹ nhất có thể, và không thực (TODO list).
hiện việc lập kế hoạch dài hạn.
62 65
f. Mô hình Agile: quy trình Scrum f. Mô hình Agile: quy trình Scrum
Product Owner tạo ra Product Backlog chứa các yêu
Đặc trưng Agile:
◦Tính tiệm tiến (Incremental) và tiến hóa (Evolutionary): Cuối các
cầu của dự án với các hạng mục được sắp theo thứ tự
phân đoạn (Sprint), nhóm phát triển thường cho ra các phần nhỏ của sản ưu tiên. Đội sản xuất sẽ thực hiện việc hiện thực hóa
phẩm cuối cùng. Các phần nhỏ này thường là đầy đủ, có khả năng chạy dần các yêu cầu của Product Owner với sự lặp đi lặp
tốt, được kiểm thử cẩn thận và có thể sử dụng ngay (gọi là potentially
shippable product increment of functionality). Theo thời gian, phân đoạn lại các giai đoạn từ 1 đến 4 tuần làm việc (gọi là
(sprint) này tiếp nối phân đoạn (sprint) kia, các phần chạy được này sẽ Sprint) với đầu vào là các hạng mục trong Product
được tích lũy, lớn dần lên cho tới khi toàn bộ yêu cầu của khách hàng
được thỏa mãn.
Backlog, đầu ra là các gói phần mềm hoàn chỉnh có
◦Tính thích ứng (hay thích nghi – adaptive): Do các Sprint chỉ kéo dài thể chuyển giao được (Potentially Shippable Product
trong một khoảng thời gian ngắn, và việc lập kế hoạch cũng được điều Increment)
chỉnh liên tục, nên các thay đổi trong quá trình phát triển (yêu cầu thay
đổi, thay đổi công nghệ, thay đổi định hướng về mục tiêu v.v.) đều có Đội sản xuất cùng họp với Product Owner để lập kế
thể được đáp ứng theo cách thích hợp. Theo đó, các quy trình Agile hoạch cho từng Sprint. Kết quả của buổi lập kế hoạch
thường thích ứng rất tốt với các thay đổi.
(theo cách làm của Scrum) là Sprint Backlog chứa các
63 công việc cần làm trong suốt một Sprint. 66
11
- 21/07/2020
f. Mô hình Agile: quy trình Scrum f. Mô hình Agile: quy trình Scrum
Các Sprint sẽ được lặp đi lặp lại cho tới 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
khi nào các hạng mục trong Product 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
Backlog đều được hoàn tất 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.
67 70
f. Mô hình Agile: quy trình Scrum f. Mô hình Agile: quy trình Scrum
Trong suốt quá trình phát triển, nhóm sẽ phải cập nhật Sprint
2. Daily Scrum (Họp Scrum hằng ngày):Scrum Master tổ chức cho
Backlog và thực hiện công việc họp hằng ngày (Daily Scrum)
Đội sản xuất họp hằng ngày trong khoảng 15 phút để Nhóm Phát
để chia sẻ tiến độ công việc cũng như các vướng mắc trong quá 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
trình làm việc cùng nhau. Nhóm được trao quyền để tự quản lí triển lần lượt trình bày để trả lời 3 câu hỏi sau:
và tổ chức lấy công việc của mình để hoàn thành công việc Hôm qua đã làm gì?
Hôm nay sẽ làm gì?
trong Sprint.
Có khó khăn trở ngại gì không?
Khi kết thúc Sprint, nhóm tạo ra các gói phần mềm có chức 3. Sprint Review (Họp Sơ kết Sprint): Cuối Sprint, nhóm phát
năng hoàn chỉnh, sẵn sàng chuyển giao (shippable) cho khác triển cùng với Product Owner sẽ rà soát lại các công việc đã hoàn tất
hàng. Buổi họp Sơ kết Sprint (Sprint Review) ở cuối Sprint sẽ (DONE) trong Sprint vừa qua và đề xuất các chỉnh sửa hoặc thay đổi
giúp khách hàng thấy được nhóm đã có thể chuyển giao những cần thiết cho sản phẩm.
gì, còn những gì phải làm hoặc còn gì phải thay đổi hay cải 4. Sprint Retrospective (Họp Cải tiến Sprint): Dưới sự trợ giúp
tiến. Sau khi kết thúc việc đánh giá Sprint, Scrum Master và của Scrum Master, nhóm phát triển sẽ rà soát lại toàn diện Sprint vừa
nhóm cùng tổ chức họp Cải tiến Sprint (Sprint Retrospective) 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
để tìm kiếm các cải tiến trước khi Sprint tiếp theo bắt đầu, điều sản phẩm.
này sẽ giúp nhóm liên tục học hỏi và trưởng thành qua từng
Sprint. 68 71
f. Mô hình Agile: quy trình Scrum f. Mô hình Agile: quy trình Scrum
Trong Scrum, đội ngũ tham gia phát triển phần mềm được
Quy trình Scrum được vận hành thế phân chia ra ba vai trò với trách nhiệm rõ ràng để đảm bảo
nà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.
69 72
12
- 21/07/2020
Kiểm thử trong mô hình Agile
Ko thực hiện đưa toàn bộ yêu cầu/ nghiệp vụ của hệ thống vào
Lựa chọn mô hình
code và testing cùng 1 lúc ( như quy trình truyền thống) mà sẽ Phụ thuộc vào bài toán, vào môi
chia các Yêu cầu ra làm theo từng giai đoạn. Mỗi 1 giai đoạn chỉ
làm 1 số lượng yêu cầu nhất định
trường cụ thể
Chia thành nhiều giai đoạn nhỏ để thực hiện hay còn gọi là
Sprint
Mỗi 1 sprint thường kéo dài từ 1 tuần đến 4 tuần ( ko dài hơn 1 Yêu cầu rõ ràng: => Mô hình thác nước
tháng)
Đầu sprint sẽ lên kế hoạch làm những yêu cầu nào. Sau đó, sẽ Yêu cầu chưa rõ ràng, độ phức tạp cao
thực hiện code và test. Cuối sprint là 1 sản phẩm hoàn thiện cả Yêu cầu có khả năng thay đổi
code lẫn test có thể demo và chạy được. Không chắc chắn về tính hiệu quả, tính khả thi
Hoàn thành sprint 1, tiếp tục làm sprint 2, sprint... cho đến khi
hoàn thành hết các yêu cầu. => Làm bản mẫu, mô hình xoắn ốc, Agile
73 76
Kiểm thử trong mô hình Agile
Trong mỗi 1 sprint thì sẽ có họp hàng ngày – daily meeting. Cả team
Một số lưu ý
sẽ đứng họp thành 1 vòng tròn, thường chỉ họp ngắn từ 15 – 20 phút.
Mỗi thành viên sẽ báo cáo: hôm qua tôi đã làm gì? Hôm nay tôi sẽ
làm gì? Có gặp khó khăn gì ko?
Trong mỗi 1 sprint thì các thành viên của dự án phải tạo task cho
code và test,1 task code xong là phải có task test liền ngay đó. Do
Tổ hợp các mô hình:
thời gian làm ngắn ngày nên hiệu quả làm việc phải cao, đúng tiến Có thể tổ hợp các mô hình để đem lại hiệu quả
độ để đảm bảo cuối sprint là hoàn thành được cả test. ( ý này nếu bị
hỏi mới kể)
Ưu điểm của quy trình này là phù hợp với những yêu cầu/ nghiệp vụ
hay thay đổi, hoặc hệ thống nghiên cứu do làm theo từng giai đoạn
ngắn ngày, có thể nhìn thấy những rủi ro hay những điểm chưa phù
hợp để thay đổi ( ý này nếu bị hỏi mới kể)
Điều hành đội dự án sẽ là ông scrum master, còn có product owner là
người đánh giá phần mềm làm đã theo đúng nghiệp vụ/ yêu cầu chưa
( ý này nếu bị hỏi mới kể) 74 77
Kết luận
Một số lưu ý
Trong thực tế, người ta thường kết
hợp nhiều mô hình cho một dự án
Đối với Hệ thống phức tạp, cần chia dự
Lặp tiến trình:
án thành các hệ thống con Mỗi phần của tiến trình được lặp theo 2
cách tiếp cận
Áp dụng mô hình xoắn ốc hay mô hình hợp nhất cho
toàn bộ dự án.
• Phát triển gia tăng
Mỗi hệ thống con có thể áp dụng một mô hình khác nhau
Áp dụng mô hình nguyên mẫu cho các hệ thống con phức
• Phát triển xoắn ốc
tạp
Áp dụng mô hình thác nước cho các hệ thống con khác
75 78
13
- 21/07/2020
1.2. Khái niệm kiểm thử phần mềm
Một số lưu ý Kiểm thử phần mềm là quá trình khảo sát
một hệ thống hay các thành phần dưới
những điều kiện xác định; quan sát, ghi
Chuẩn hóa tiến trình:
lại kết quả, và đánh giá một khía cạnh nào
Tăng năng lực của tổ chức phát triển phần
mềm đó của hệ thống hay thành phần đó. (Theo
IEEE Standard Glossary of Software
• ISO 9000-03 (International Standards Organization )
Engineering Terminology).
• CMM (Software Engineering Institute)
Kiểm thử là giai đoạn quan trọng đảm bảo
chất lượng phần mềm.
79 82
1.2.1. Khái niệm kiểm thử
Một số lưu ý Kiểm thử là tiến trình xem xét, kiểm
tra lại đặc tả, phân tích, thiết kế và
Giảm chi phí phát triển: mã hoá nhằm phát hiện lỗi phần
Sử dụng các phương pháp, công cụ tiên tiến mềm, xác minh phần mềm có đúng
• tái sử dụng: thư viện thương mại,... đặc tả, thiết kế; có đáp ứng nhu cầu
• tự sinh mã: công cụ tạo giao diện,...
người dùng, có hoạt động hiệu quả
không .
• hướng đối tượng: kế thừa, bảo trì
Kiểm thử thành công khi phát hiện
• ngôn ngữ bậc cao: năng lực biểu diễn cao ra lỗi; kiểm thử không phát hiện ra
lỗi là kiểm thử dở (Theo Sue
A.Conger- The New SE)
80 83
1.2.1. Khái niệm kiểm thử
Một số lưu ý Software Testing là một quá trình thực thi một chương
trình với mục đích tìm lỗi.
Thực hiện các pha phát triển: Quality Testing = Verification + Validation (Xác minh
Pha xác định yêu cầu và thiết kế có vai trò quyết định và Thẩm định)
đến chất lượng phần mềm, chiếm phần lớn công sức so
Là hoạt động kiểm tra xem phần mềm có chạy chính xác
với mã hóa, kiểm thử.
hay không (Verification) và có thoả mãn yêu cầu của
Khi chuyển tiếp giữa các pha phát triển phải thẩm định
khách hàng hay không (Validation) nhằm hướng tới mục
để đảm bảo lỗi không ảnh hưởng đến pha sau.
tiêu chất lượng của phần mềm.
Tài liệu tạo ra ở mỗi pha không chỉ dùng cho pha kế
tiếp mà còn dùng để đảm bảo chất lượng của phần
mềm và dùng trong khâu bảo trì.
Cần chuẩn hóa mẫu biểu, cách thức ghi chép, tạo tài
liệu nhằm đảm bảo chất lượng phần mềm.
81 84
14
- 21/07/2020
1.2.1. Khái niệm kiểm thử 1.2.2. Đảm bảo chất lượng
Kiểm thử là một quá trình đánh giá một hệ thống hay là QA: Giám sát, quản lý và đảm bảo chất lượng
các thành phần của nó với mục đích là xác định xem nó có QA ( Quality Assurance ), là những công việc đảm bảo chất
thỏa mãn những yêu cầu được đưa ra hay không. Hiểu một lượng của việc xây dựng hệ thống, quy trình sản xuất của công
cách đơn giản, kiểm thử - test là chạy một chương trình để ty theo một chuẩn mực. Giám sát chặt chẽ và đo lường việc
xác nhận bất kì lỗ hổng, lỗi sai hay những yêu cầu bị bỏ thực hiện các chuẩn chất lượng trong các giai đoạn từ nghiên
quên, những yêu cầu không đúng so với yêu cầu thực tế đề cứu thị trường, thiết kế… cho đến sản xuất và bán hàng, chăm
sóc khách hàng.
ra.
QA có nhiệm vụ giám sát để bảo đảm các tiêu chuẩn và quy trình sản
Theo tiêu chuẩn ANSI/IEEE 1059, kiểm thử như một quá xuất PM được định nghĩa và tuân thủ nghiêm túc, hướng đến mục
trình của việc phân tích các thành phần của phần mềm để tiêu các sản phẩm (SP) trung gian cũng như SP sau cùng của dự án
dò tìm sự khác biệt giữa phần mềm thực tế đang tồn tại và thỏa mãn các tiêu chuẩn và yêu cầu đã định trước đó. Công việc của
những điều kiện được yêu cầu – requirement.(đó là thiếu QA liên quan đến quy trình (process).
sót – defect, sai sót - error, lỗi - bug). Từ đó đánh giá được
chất lượng của sản phẩm phần mềm.
85 88
1.2.1. Khái niệm kiểm thử 1.2.2. Đảm bảo chất lượng
Thông thường, trong một dự án PM, khách hàng chỉ
trả tiền cho lưc lượng sản xuất trực tiếp như developer
và tester, do đó đầu tư vào lực lượng QA là một đầu tư
mang tính nội bộ và nền tảng, giúp công ty cải tiến và
kiểm soát các quy trình đảm bảo chất lượng
Một khi quy trình sản xuất được tuân thủ nghiêm túc,
lỗi xuất hiện ở các khâu sản xuất sẽ được nhận diện và
ngăn chặn sớm, SP sau cùng (ở chặng kiểm định) sẽ ít
lỗi và khả năng thành công của dự án được bảo đảm
hơn, do đó tổng chi phí sẽ thấp hơn.
86 89
1.2.1. Khái niệm kiểm thử 1.2.2. Đảm bảo chất lượng
2 mục đích chính của hoạt động Quy trình bao gồm các biểu mẫu, các bước và hướng dẫn cụ thể giúp
thành viên dự án thực hiện một công việc nào đó một cách nhất quán
kiểm thử: và có kiểm soát. Có rất nhiều quy trình khác nhau được thiết kế tùy
theo nhu cầu của một dự án như Quy trình phát triển yêu cầu SP
Kiểm tra xem phần mềm làm ra có đúng (Requirement); Quy trình thiết kế SP (Design); Quy trình triển khai
đặc tả (yêu cầu, phân tích, thiết kế) hay và viết code (Coding); Quy trình kiểm định SP (Testing); Quy trình
cài đặt và hỗ trợ (Delivery); Quy trình bảo trì SP (Maintenance); Quy
không. trình quản trị dự án (Project management); Quy trình quản lý cấu
Kiểm tra xem phần mềm có đáp ứng yêu hình (Coonfiguration management); Quy trình đảm bảo chất lượng
(Quality Assurance).
cầu người dùng hay không.
Đây chính là 2 hoạt động cốt yếu để
đảm bảo chất lượng phần mềm, diễn
ra trong suốt quá trình phát triển
phần mềm. 87 90
15
- 21/07/2020
1.2.2. Đảm bảo chất lượng 1.2.3. Kiểm soát chất lượng phần mềm
QA là người tham gia phát triển quy trình hoạt động ở cấp QC (Quality Control) là những công việc liên quan
công ty và ở cấp dự án, đánh giá các tài liệu. Ngoài ra, họ đến kiểm soát, kiểm tra, đánh giá chất lượng của sản
còn phải giám sát và kiểm tra (audit) các hoạt động được phẩm. QC là một trong những khâu trong quy trình
thực hiện trong dự án xem chúng có tuân thủ các quy trình
sản xuất rất quan trọng, được tiến hành xen kẽ trong
(process) đã được định ra; xác định các điểm không tương
thích với quy trình (process noncompliance – gọi tắt là
những công đoạn sản xuất, tạo ra những sản phẩm có
NC) và báo cáo cho những người liên quan và các cấp chất lượng theo yêu cầu. QC thường hoạt động trong
quản lý đồng thời giám sát để bảo đảm chúng được giải những nhà máy sản xuất theo quy trình, những quy
quyết đến khi hoàn tất. trình công nghệ hiện đại, trong các lĩnh vực về kĩ
Nhân sự QA cũng có thể phản hồi về những bất cập của thuật, lập trình, may mặc. QC kiểm tra chất lượng của
quy trình và đề xuất cải tiến quy trình. sản phẩm, đảm bảo chất lượng của sản phẩm trường
QA cũng hay gọi là PQA ( Process Quanlity Assurance –
khi đưa ra thị trường sử dụng.
Cán bộ quản lý chất lượng quy trình).
91 94
Quy trình đảm bảo chất lượng Quy trình Kiểm soát chất lượng
1. Đề xuất, đưa ra quy trình phát triển (development process) 1. Tìm hiểu hệ thống, phân tích tài liệu mô tả về
sản phẩm phù hợp với yêu cầu cụ thể của từng dự án. Các quy
trình này có thể được phát triển dựa trên V-model hay Agile hệ thống và thiết kế test case, thực hiện việc
(đa số là Scrum hoặc Lean Development) hay thông qua việc test phần mềm trước khi giao cho khách hàng
áp dụng những quy trình quản lý sẵn có như ISO hay CMMI. hay đưa ra thị trường.
2. Đưa ra những tài liệu, biểu mẫu, hướng dẫn để đảm bảo chất
2. Lên kế hoạch kiểm thử phần mềm
lượng của sản phẩm cho tất cả các bộ phận trong nhóm phát
triển sản phẩm. 3. Viết Script cho automation test
3. Kiểm tra, audit việc thực thi quy trình của các bộ phận trong 4. Sử dụng các test tool để tạo và thực hiện các
nhóm làm sản phẩm có đúng quy trình QA đã đề ra không.
test case/script chi tiết.
4. Nhắc nhở đội ngũ phát triển sản phẩm việc tuân thủ theo quy
trình làm việc đã đưa ra. 5. Phối hợp với nhóm lập trình trong việc fix bug
5. Điều chỉnh, thay đổi quy trình phù hợp với từng sản phẩm mà và báo cáo chi tiết cho Project Manager hoặc
các team đang thực hiện. các bên liên quan tuỳ từng dự án, sản phẩm.
92 95
1.2.3. Kiểm soát chất lượng phần mềm 1.2.3. Kiểm soát chất lượng phần mềm
QC = Quality Control QA: là người người đặt ra các quy định cho dự
QC chính là Tester. Nhiều công ty gọi là QC chứ án như: đề xuất đưa ra quy trình phát triển dự
không phải là tester. án, giám sát, quản lý và ban hành chất lượng.
Quality Control: Điều khiển chất lượng Mục đích để đảm bảo rằng quy trình phát triển
hoặc bảo trì chắc chắn sẽ đáp ứng được các mục
Tập hợp các hoạt động được tạo ra nhằm đánh
giá chất lượng sản phẩm, bảo đảm sản phẩm tiêu hệ thống đã đề ra.
đúng đặc tả yêu cầu QC: Là người thi thành các quy định, nguyên tắc
để đảm bảo sản phẩm cuối cùng thực hiện đúng
Trực tiếp kiểm tra chất lượng của sản phẩm
các quy định, nguyên tắc mà QA đặt ra. Cũng là
Có nhiệm vụ khảo sát, chạy thử và báo cáo lỗi
người kiểm thử, tìm các trường hợp còn thiếu
sót hay lỗi so với yêu cầu được đặt ra bởi khách
93 hàng. 96
16
- 21/07/2020
QA QC
QA bao gồm các hoạt động đảm bảo và thực
hiện quy trình, trình tự và tiêu chuẩn trong nội
QC/Tester bao gồm các hoạt động để đảm bảo
việc kiểm tra một phần mềm đã đáp ứng yêu cầu
1.3. Các nguyên tắc kiểm thử
dung kiểm thử phần mềm đã phát triển và những
yêu cầu đặt ra
trong tài liệu yêu cầu (đảm bảo việc phát hiện
lỗi/bug trong phần mềm) (4) Dữ liệu thử cho kết quả bình thường
Tập trung vào quy trình và tuần tự hơn là quản Tập trung vào việc test thự tế trên phần mềm thì không có ý nghĩa nhiều, cần có những
lý việc test thực tế trên hệ thống nhằm phát hiện lỗi trong quá trình phát triển
hệ thống
dữ liệu kiểm thử phát hiện ra lỗi phần
Đảm bảo chất lượng là quy trình định hướng Kiểm soát chất lượng là định hướng sản phẩm mềm.
Mục tiêu của đảm bảo chất lượng phần mềm là
phòng tránh lỗi trong ứng dụng phần mềm giúp
Mục tiêu của kiểm soát chất lượng phần mềm là
xác định, phát hiện các lỗi trong khi phát triển
(5) Khi thiết kế trường hợp thử, không chỉ
cải thiện quá trình phát triển và kiểm thử ứng dụng phần mềm dữ liệu kiểm thử nhập vào, mà phải thiết kế
Không liên quan đến việc thực thi chương Liên quan đến việc thực thi chương trình, code trước cả dữ liệu kết quả sẽ có.
chình, code
Xác định điểm yếu trong các quy trình phát triển Xác định các lỗi cần sửa (6) Khi phát sinh thêm trường hợp thử thì
để cải thiện
Đây là tập hợp con của vòng đời phát triển phần Testing là tập hợp con của Quality Control
nên thử lại những trường hợp thử trước đó
mềm (SDLC) (Quản lý chất lượng) để tránh ảnh hưởng lan truyền sóng khi
Được thực hiện trước khi kiểm soát chất lượng Được thực hiện chỉ sau khi hoạt động Đảm bảo
Chất lượng được hoàn thành 97
kiểm thử. 100
1.4. Vai trò kiểm thử phần mềm
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 đả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.
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.
Software testing cũng có thể xem như là quá trình thẩm định và
thẩm tra (validating and verifying) phần mềm/chương trình/ứng
dụng/sản phẩm để:
Đáp ứng được các yêu cầu công việc và kỹ thuật đã được
quy định trong thiết kế và trong lúc phát triển
Làm việc như mong đợi
98 101
1.3. Các nguyên tắc kiểm thử BÀI TẬP CHƯƠNG 1
(1) Chất lượng phần mềm do khâu thiết 1. Khái niệm phần mềm, vòng đời phát triển phần mềm.
2. Trình bày các mô hình phát triển phần mềm. Theo anh
kế quyết định là chủ yếu, chứ không chị mô hình phát triển nào hiện đang được triển khai
phải khâu kiểm thử. phổ biến các công ty phát triển phần mềm.
3. Khái niệm kiểm thử phần mềm, đảm bảo chất lượng
(2) Tính dễ kiểm thử phụ thuộc vào cấu phần mềm.
4. So sánh hoạt động kiểm thử phần mềm và kiểm soát
trúc chương trình. chất lượng phần mềm.
5. Phân tích các nguyên tắc kiểm thử phần mềm. Theo
(3) Người kiểm thử và người xây anh chị, những nguyên tắc nào đảm bảo chất lượng
phần mềm.
dựng phần mềm nên khác nhau.
6. Phân tích vai trò kiểm thử phần mềm trong quá trình
phát triển phần mềm.
99 102
17
- 21/07/2020
CHƯƠNG 2. QUY TRÌNH KIỂM 2.1. Các giai đoạn kiểm thử phần mềm
THỬ PHẦN MỀM
2.1. Các giai đoạn kiểm thử phần mềm Bắt đầu
2.2. Nội dung kiểm thử Kế hoạch test
Lập kế hoạch Test
2.2.1. Kiểm thử đơn vị Mẫu test
Các thủ tục Test
Thiết kế Test
2.2.2. Kiểm thử tích hợp Cài đặt và chuẩn bị Mã nguồn Test
Dữ liệu test
Test
Môi trường
2.2.3. Kiểm thử hệ thống
2.2.4. Kiểm thử chấp nhận Lỗi
Test tích hợp
Xem xét và Đánh giá Báo cáo kết quả
test, đề xuất giải
2.3. Các hình thức kiểm thử Biên bản test kết quả test
Test hệ thống pháp
2.3.1. Kiểm thử chức năng
Tổng hợp, báo cáo
2.3.2. Kiểm thử phi chức năng Hồ sơ báo cáo tổng
hợp test
2.4. Công việc của người kiểm thử Kết thúc
103 106
2.1. Các giai đoạn kiểm thử phần mềm
2.1. Các giai đoạn kiểm thử phần mềm
Các giai đoạn kiểm thử phần mềm Bắt đầu Initiation (khởi động)
Definition (Xác định yêu cầu)
Definition Lập kế hoạch Test Xác định yêu cầu
Solution Thiết kế kiến trúc Solution (Thiết kế kiến trúc)
Thiết kế Test
Cài đặt và chuẩn bị Construction (Xây dựng)
Construction Lập trình
Test
Coding (lập trình)
Construction Thử nghiệm
Test tích hợp
Xem xét và Đánh giá Testing (thử nghiệm)
kết quả test
Test hệ thống
Tổng hợp, báo cáo
Kết thúc Transition (Triển khai)
Termination (Kết thúc)
104 107
2.1. Các giai đoạn kiểm thử phần mềm
CÁC HOẠT ĐỘNG - Lập kế hoạch test
1. Xác định yêu cầu cho test Các yêu cầu test TN Test,
Bắt đầu
• Phương thức thực hiện CBT
Lập kế hoạch Lập kế hoạch Test • Tiêu
2. Đánh giá rủi ro và lập mức ưu chuẩnCáchoàn
rủi rothành việc test,
liên quan đánh
đến test TN Test
tiên cho các yêu cầu giá chất lượng
• Dựa trên sản phẩm
cáccầu
sảntest
phẩm
•• Số Các yêu đượcphân
xác tích
định
Thiết kế Test Cácngười,
•yếu tố
Xácmức kỹ
định:năng
cần chú cái
test ý gì?
• Môi• trường độ ưu
test: tiên
phần
Chuẩn bị Xác định: giới hạnmềm, cứng…
công việc, thời
Cài đặt và chuẩn bị 3. Xác lập chiến lược test • Công cụPhương
gian, test lực
nguồn thức thực hiện TN Test
Test • Dữ liệu test
Tiêu chuẩn đánh giá
Test tích hợp
Các yếu tố cần chú ý
Test Xem xét và Đánh
Các nguồn lực • Xác định nguồn lực TN Test
4. Xác định nguồn lực và môi
Test hệ thống
giá kết quả test • Lịch trình test
Phân tích kết quả trường • Các mốc chính
5. Lập lịch trình test Lịch trình test TN Test
Tổng hợp, báo cáo
6. Tổng hợp thông tin, lập KH test Kế hoạch test TN Test
7. Xem xét và thông qua KH test Kế hoạch test được phê duyệt QTDA
Kết thúc
105 108
18
- 21/07/2020
CÁC HOẠT ĐỘNG - thiết kế test CÁC HOẠT ĐỘNG - test hệ thống
•Dựa trên các sản phẩm của:
• Phân tích
• bước lập KH test 1. Nhận bàn giao với đội lập trình Các sản phẩm cần test được tiếp CBT
1. Lập danh sách các loại test, đảm Danh• sách loại các
Xác định test test case TN Test, • Kiểm tra và cập nhật:
nhận
bảo cho việc xác lập tính đúng đắn & CBT
• Mô tả test case: vào, ra, điều kiện Thiết• kế
Test
test,case
2. Chỉnh sửa thiết kế test test script, dữ liệu test TN Test
thỏa mãn yêu cầu của sản phẩm được•cập nhật
Test procedure
2. Xây dựng tình huống test (test Thiết kế test, các mẫu mã sử TN Test, 3. Cài đặt • Test
Chương trìnhscript
được cài đặt CBT
case) dụng, yêu cầu về dữ liệu test CBT
4. Thực hiện test và ghi nhận lỗi Biên•bản
Testtestdata CBT
3. Xây dựng và tổ chức thủ tục test Các thủ tục test TN Test,
(test procedure) CBT Danh sách lỗi phát hiện
• Dựa vào: các test case
4. Xem xét tình huống test và thủ tục • Xác định
Biên bản xem xét các test procedure QTDA, Cán 5. Xử lý lỗi Biên bản test TN Test, CBT
test, đánh giá tỷ lệ yêu cầu của khách • Xác lập mối quan hệ và thứ tự bộgiữa
lập trình Danh sách lỗi phát hiện
• Khi hệ thống thoả mãn các
hàng (hoặc tình huống sử dụng) sẽ • Các test procedure với nhau 6. Xem xét các kết quả test và việc Kếtra
quả test được xem xét TN Test,QTDA,
• Các test procedure - Test cases
tiêu chuẩn đặt
được test dựa trên thiết kế test đã lập thực hiện khắc phục lỗi CBT, CBCL
(nếu cần)
5. Thông qua thiết kế Test Thiết kế test được thông qua QTDA
7. Kết quả test được xem xét Xác nhân sản phẩm đủ tiêu chuẩn QTDA, CBCL,
phát hành TN Test
CÁC HOẠT ĐỘNG - xem xét và đánh giá kết quả
CÁC HOẠT ĐỘNG - Cài đặt và chuẩn bị test test
Test script
1. Phân tích lỗi và đưa ra đề xuất Báo cáo kết quả test TN Test
1.Lập các test script để thực hiện các • Các
Test lệnh dùng để tự động hoá TN
scipts các Test/
thủ
tục test Đề xuất
tình huống test/thủ tục test (nếu cần) CBT
• Lập trình, sử dụng công cụ test tự động
2. Chuẩn bị dữ liệu test Dữ liệu test CBT 2. Đánh giá tỷ lệ test, đánh giá mức Báo cáo kết quả test TN Test
độ đạt được các tiêu chí để hoàn
3. Chuẩn bị môi trường Môi trường sẵn sàng cho CBT
thành test
việc thực hiện test
3. Xem xét báo cáo kết quả test Báo cáo kết quả test được xem QTDA,
4. Kiểm tra các công cụ test Biên bản kiểm tra công cụ CBT
xét CBCL
test • Phân tích lỗi dựa:
5. Xem xét môi trường, điều kiện và dữ Môi trường và dữ liệu test TN Test/ • mức độ lặp lại
liệu test được kiểm tra CBT • Dựa trên tỷ lệ YCnghiêm
• độ được test/tổng
trọng
số YC cần test• Thời gian sửa lỗi…
CÁC HOẠT ĐỘNG - test tích hợp CÁC HOẠT ĐỘNG - tổng hợp, báo cáo
• Tài liệu
• Gói phần mềm
•…
1. Nhận bàn giao với đội lập trình Các sản phẩm cần test được tiếp CBT Dữ liệu, kết quả test CBT
• Dựa trên thiết kế test
nhận
1. Tập hợp các dữ liệu, kết
• Ghi nhận lỗi vào DMS quả test
2. Cài đặt Hệ thống để test sẵn sàng CBT
3. Thực hiện test và ghi nhận lỗi Biên bản test CBT 2. Lập báo cáo tổng hợp test Báo cáo tổng hợp test TN Test
3. Tổ chức lưu trữ tài liệu, hồ Hồ sơ, files CBT
4. Xử lý lỗi Danh sách lỗi phát hiện TN Test,
• Phối hợp với đội lập trình CBT sơ
• Test lại -> Ghi nhận lỗi mới
5. Xem xét các kết quả test và việc Biên bản test TN Test,
thực hiện khắc phục lỗi QTDA,
CBT, CBCL
(nếu cần)
19
- 21/07/2020
HOẠT ĐỘNG – xác định test
CÁC HOẠT ĐỘNG case
Vấn đề của thiết kế test Phân hoạch tương đương - Equivalence partitioning
Xác định các test case Ví dụ:
Phân hoạch tương đương Input Expected
Output
Đường đi trong mô đun Hàm tính trị tuyệt đối
100 100
- miền dữ liệu = 0
Mô tả các test case - miền dữ liệu < 0 -20 20
0 0
115
CÁC HOẠT ĐỘNG – mô tả test case HOẠT ĐỘNG – xác định test case
Tên mô đun/chức năng muốn kiểm thử Phân hoạch tương đương - Equivalence partitioning
Dữ liệu vào
Mở rộng test case:
- dữ liệu thông thường: số, xâu kí tự, file,...
- môi trường thử nghiệm: phần cứng, OS,... Tạo test case cho các trường hợp đặc biệt
- thứ tự thao tác (khi kiểm thử giao diện) - biên của số trong máy tính
(vd. 32767, -32768)
Kết quả mong muốn - số không (0)
- số âm, số thập phân
- thông thường: số, xâu kí tự, file,...
- dữ liệu sai kiểu
- màn hình, thời gian phản hồi - dữ liệu ngẫu nhiên
Kết quả thực tế
116 119
HOẠT ĐỘNG – xác định test
HOẠT ĐỘNG – xác định test case case
Phân hoạch tương đương - Equivalence partitioning Đường đi trong mô đun
Không thể kiểm thử mọi trường hợp Phân tích mô đun để xác định đường đi
Chia dữ liệu thành các miền có cùng hành vi Đường đi là thứ tự thực hiện các lệnh từ điểm
Tạo một test case cho từng miền bắt đầu đến điểm kết thúc của mô đun
Tạo test case cho biên của các miền Thiết kế các test case để kiểm thử mọi đường đi
- nhiều lỗi xuất hiện với giá trị biên
117
20
nguon tai.lieu . vn
