KIỂM THỬ PHẦN MỀM NGHIÊN CỨU KIỂM THỬ TỰ ĐỘNG THEO AGILE CHO DỊCH VỤ WEB

TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP HÀ NỘI
KHOA CÔNG NGHỆ THÔNG TIN
______________________________

BÁO CÁO THỰC NGHIỆM HỌC PHẦN
KIỂM THỬ PHẦN MỀM
ĐỀ TÀI
NGHIÊN CỨU KIỂM THỬ TỰ ĐỘNG THEO AGILE CHO DỊCH VỤ
WEB

GVHD
Nhóm
Mã lớp

: Ths. Hoàng Quang Huy
: 10
: 20212IT6013002
Hà Nội, 2022


TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP HÀ NỘI
KHOA CÔNG NGHỆ THÔNG TIN
______________________________

BÁO CÁO THỰC NGHIỆM HỌC PHẦN:
KIỂM THỬ PHẦN MỀM
ĐỀ TÀI
NGHIÊN CỨU KIỂM THỬ TỰ ĐỘNG THEO AGILE CHO DỊCH VỤ
WEB
GVHD
Nhóm

Mã lớp
Sinh viên thực hiện

:
:
:
:

Ths. Hoàng Quang Huy
10
20212IT6013002
1.

Hà Nội, 2022


LỜI CẢM ƠN
Lời đầu tiên, nhóm 10 xin gửi lời cảm ơn chân thành tới thầy Hoàng Quang Huy.
Trong quá trình học tập và thực hiện đề tài này, chúng em đã nhận được sự quan tâm
giúp đỡ, hướng dẫn tận tình, tâm huyết của thầy. Những gì chúng em nhận được không
chỉ dừng lại ở kiến thức môn học mà nhiều hơn thế đó là những lời khuyên, chia sẻ
thực tế từ thầy. Chính nhờ phương pháp dạy học của thầy mà chúng em có cơ hội
khám phá và phát huy khả năng của bản thân. Những buổi thực hành của thầy chính là
cơ hội tuyệt vời giúp chúng em rèn luyện sự tự tin, cẩn thận, kỹ năng giao tiếp, làm
việc nhóm.... Đây cũng chính là hành trang quan trọng giúp chúng em tự tin bước chân
vào môi trường làm việc thực tế.
Để hoàn thành được đề tài này, nhóm chúng em đã cùng nhau nghiên cứu, thảo luận,
áp dụng những kiến thức được học trên lớp cùng với các nguồn tài liệu trên Internet và
cả những trải nghiệm của bản thân. Chúng em rất mong sẽ nhận được những lời nhận
xét, góp ý từ thầy cơ và bạn đọc để đề tài này có thể hồn thiện hơn nữa.

Một lần nữa, chúng em xin chân thành cảm ơn!
Nhóm sinh viên thực hiện.
Nhóm 10


MỤC LỤC
Chương I: Cơ sở lý thuyết...............................................................................................1
1. Khái Niệm....................................................................................................1
2. Lịch Sử Hình Thành.....................................................................................1
a. Cá nhân và sự tương tác hơn là quy trình và cơng cụ.............................1
b. Phần mềm chạy tốt hơn là tài liệu đầy đủ................................................1
c. Cộng tác với khách hàng hơn là đàm phán hợp đồng..............................2
d. Phản hồi với sự thay đổi hơn là bám theo kế hoạch.................................2
3. Nguyên Tắc Áp Dụng Trong Mô Hinh Agile..............................................2
a. Thử nghiệm giúp dự án nhanh chóng được bàn giao hơn........................2
b. Kiểm thử không chỉ là một giai đoạn của dự án.....................................3
c. Cá nhân và sự tương hỗ quan trọng hơn quy trình...................................3
d. Rút ngắn vòng lặp phản hồi......................................................................3
e. Thỏa mãn mong muốn của khách hàng....................................................3
f. Giữ những dòng code được rõ ràng..........................................................4
g. Giản lược tài liệu kiểm thử.......................................................................4
h. Chưa thể hoàn thành khi chưa qua giai đoạn kiểm thử............................4
k. Test-Last & Test-Driven..........................................................................4
4. Các giai đoạn kiểm thử phần mềm tương ứng với các giai đoạn phát triển
phần mềm trong mơ hình Agile...................................................................................4
a. Tiền-Phân-đoạn (Pre-iteration):................................................................4
b. Xác minh Yêu cầu....................................................................................4
c. Các hoạt động Đảm bảo chất lượng:........................................................6
5. Lợi Ích khi xây dựng ứng dụng web bằng phương pháp Agile...................6
a. Sự linh hoạt...............................................................................................6

b. Nâng cao khả năng lên kế hoạch thực tiễn cho dự án..............................6
c. Tăng tốc độ hoàn tất dự án.......................................................................6
d. Phản hồi liên tục của user.........................................................................7
e. Tạo động lực cho team dự án...................................................................7
g. Tăng sự gắn bó trong mối quan hệ làm việc............................................7
h. Giảm thiểu chi phí....................................................................................7
k. Chất lượng sản phẩm tốt hơn...................................................................7
j. Hạn chế rủi ro............................................................................................7
6. Scrum là gì?..................................................................................................7
a. Scrum có ích gì cho phát triển phầm mềm hiện nay................................8
b. Ba giá trị cốt lõi của Scrum......................................................................8
c. Lợi ích mà Scrum mang lại......................................................................8


d. Các khái niệm cơ bản Scrum....................................................................9
CHƯƠNG II. KẾT QUẢ THỰC NGHIỆM.................................................................13
2.1. Website kiểm thử....................................................................................13
2.2. Yêu cầu đặc tả của website.....................................................................14
2.2.1. Yêu cầu chức năng...........................................................................14
2.2.2. Yêu cầu hiệu năng............................................................................14
2.3. Công cụ kiểm thử Jmeter........................................................................14
2.4. Tiến hành kiểm thử trên website.............................................................16
2.5. Tiến hành kiểm thử trên công cụ Jmeter.................................................18
Chương III: Bài Học Kinh Nghiệm...............................................................................22
3.1. Bài học kinh nghiệm...............................................................................22
3.2. Đánh giá kết quả......................................................................................22
KẾT LUẬN...................................................................................................................23
TÀI LIỆU THAM KHẢO............................................................................................24

Chương I: Cơ sở lý thuyết
1. Khái Niệm
-

-

-

Agile là một phương pháp phát triển phần mềm linh hoạt, là một hướng tiếp cận
cụ thể cho việc quản lý dự án phần mềm. Nó gồm một q trình làm việc tương
tác và tích hợp để có thể đưa sản phẩm đến tay người dùng càng nhanh càng tốt.
Những phương pháp phát triển phần mềm theo cách truyền thống ngày càng
bộc lộ nhiều nhược điểm và tỷ lệ các dự án thất bại cao trong thời kỳ bùng phát
của ngành công nghệ. Nhận ra vấn đề đó, một số cá nhân và cơng ty riêng lẻ đã
đưa ra các phương pháp phát triển phần mềm hiện đại hơn và khác nhau để
thích ứng với tình hình mới.
Những phương thức phát triển phần mềm này giúp phần nào giải quyết được
một số vấn đề nhưng lại phát sinh vấn đề khác về sự cộng tác, kỹ thuật, công
cụ, hướng phát triển, chia sẻ ….

2. Lịch Sử Hình Thành
Vào năm 2001, bản tun ngơn Agile (Agile Manifesto) đã được thống nhất
và ra đời bởi một nhóm người có uy tính trong phát triển phần mềm:
- Individuals and interactions over processes and tools: Cá nhân và sự tương
tác hơn là quy trình và cơng cụ
- Working software over comprehensive documentation: Phần mềm chạy tốt
hơn là tài liệu đầy đủ
- Customer collaboration over contract negotiation: Cộng tác với khách hàng
hơn là đàm phán hợp đồng
- Responding to change over following a plan: Phản hồi với sự thay đổi hơn là

bám theo kế hoạch
a. Cá nhân và sự tương tác hơn là quy trình và cơng cụ
- Đặt trọng tâm vào con người và sự tương hỗ giữa những thành viên trong team.
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.
- Quy trình là các thủ tục cần thiết để phát triển dự án như thiết kế, sau đó đến
lập trình, rồi kiểm tra QA/QC. Hay để đưa ra một chức năng nào đó cần phải có
sự đồng ý của bộ phận QA/QC …. Quy trình này do mỗi công ty quy định và
bắt  buộc các nhân viên khi tham gia vào dự án phải tuân thủ.
- Công cụ là phần mềm được sử dụng trong dự án như : Phần mềm quản lý công
việc, phần mềm quản lý source code, phần mềm quản lý lỗi… Có rất nhiều
công cụ được sử dụng để hỗ trợ một tổ chức vận hành.
b. 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 lập trình viên khơng thể hoặc khơng đồng ý tiến
hành cơng việc nếu khơng có tài liệu đặc tả về yêu cầu, thiết kế hệ thống.
1


-

Nhóm kiểm thử thì u cầu tài liệu về sản phẩm để có thể viết trường hợp kiểm
thử và kiểm thử được. Nhóm QA địi tất cả các tài liệu phải được viết trước khi
sản phẩm được giao cho khách hàng nếu khơng thì khơng đủ điều kiện, chuẩn
để giao sản phẩm cho khách hàng.
- Việc viết tài liệu thật ra rất mất nhiều thời gian và được cho là rất chán. Ý
tưởng ở đây là 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.
Sau đó đúc kết và chỉ viết những gì mà mọi người cần đọc.
c. Cộng tác với khách hàng hơn là đàm phán hợp đồng

- Ta luôn nghe các câu này “Khách hàng là thượng đế” hay “khách hàng ln
ln đúng”. Tuy nhiên thì khách hàng có nhiều dạng. 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.
- Trao đổi và thảo luận với khách hàng về sự cần thiết có hay khơng của một
chức năng trong sản phẩm, từ đó quyết định là có nên làm hay khơng. Tất nhiên
để thuyết phục khách hàng thì cần có số liệu nghiên cứu cụ thể chẳng hạn.
d. Phản hồi với sự thay đổi hơn là bám theo kế hoạch
- Có một điểm chung là hầu hết những dự án đều có sự thay đổi điều chỉnh khi
triển khai. Sự thay đổi đó có thể là thay đổi về requirements, thay đổi tech
stack, thay đổi nhân sự, thay đổi deadline, thay đổi phương thức làm việc…
mặc dù kế hoạch đã được định ra rõ ràng từ đầu.
- 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.
- Một trong các nguyên tắc cơ bản của agile là “phần mềm chạy tốt chính là
thước đo của tiến độ”. Nguyên tắc này giúp nhóm dám loại bỏ đi các công việc
dư thừa không trực tiếp mang lại giá trị cho sản phẩm.
- Để vận hành được cơ chế “làm việc dựa trên giá trị”, nhóm agile thường làm
việc trực tiếp và thường xuyên với khách hàng, cộng tác trực tiếp với họ để biết
yêu cầu nào có độ ưu tiên cao hơn, mang lại giá trị hơn sớm nhất có thể cho dự
án. Nhờ đó các dự án agile thường giúp khách hàng tối ưu hóa được giá trị của
dự án. Một cách gần như trực tiếp, agile gia tăng đáng kể độ hài lòng của khách
hàng.

3. Nguyên Tắc Áp Dụng Trong Mô Hinh Agile
a. Thử nghiệm giúp dự án nhanh chóng được bàn giao hơn
Ở dự án truyền thống, kiểm thử thường được xem là bước cuối kiểm tra chất
lượng sản phẩm. Và việc ngăn chặn lỗi của phầm mềm bị coi như trách nhiệm của
QA/tester. Bug được tìm thấy dù quan trọng hay khơng thì cũng sẽ làm chậm quá trình

bàn giao sản phẩm.Trong dự án Agile, chúng ta xây dựng một sản phẩm tốt ngay từ
ban đầu, sử dụng kiểm thử để phản hồi trên ngay khi phát triển để làm thế nào cho sản


phẩm tương đồng với yêu cầu. Nghe có vẻ là thay đổi nhỏ, nhưng thực chất thì việc
này có ý nghĩa lớn. Mối liên hệ giữa tester và dev cần là sự cộng tác, tương hỗ lẫn
nhau
b. Kiểm thử không chỉ là một giai đoạn của dự án
- Kiểm thử khơng phải là một giaiđoạn trong q trình phát triển Agile mà cần
được tham gia sâu vào quy trình phát triển từ sớm.
- Cách tiếp cận Agile tập trung vào việc xác nhận những điều đúng đắn ngay từ
đầu, giảm sự cần thiết phải có nhiều kiểm thử viên (QA Tester) ở cuối quy trình
để đạt được kết quả. Đảm bảo tiến độ dự án được liên tục.
c. Cá nhân và sự tương hỗ quan trọng hơn quy trình
- Với dự án truyền thống, tester làm việc độc lập và chịu trách nhiệm với toàn bộ
hoạt động test.
- Đối với Agile, các hoạt động test được thực hiện bởi toàn bộ dự án. Để thực
hiện được hết test thì cần thực hiện lặp lại qua các sprint.
- Tuy nhiên tới khi dự án lớn hoặc phức tạp lên thì sẽ có lúc khơng thể test hết
các testcase đề ra và không thể thực hiện được mục tiêu ban đầu đề ra. Có nghĩa
team khơng thể thực hiện nhanh như họ nghĩ. Vì nếu test chưa xong thì feature
cũng khơng thể xong được, vì vậy để đẩy nhanh tốc độ thì cả team phải làm
cùng nhau và đẩy nhanh phần chậm nhất, test cùng nhau.
d. Rút ngắn vòng lặp phản hồi
- Thời gian từ khi viết code và thực hiện code tới khi biết được code vận hành
như thế nào được gọi là feedback loop (vòng phản hồi). Nếu một phần mềm
không được thực hiện test cho tới khi kết thúc và được bàn giao thì vịng phản
hồi này bị kéo dài tới cả tháng, như thế là quá dài.
- Agile tạo nên một vòng phản hồi ngắn hơn bởi với dự án Agile, phần mềm
được sẵn sàng để test ngay từ khi bắt đầu. Đặc thù của Agile là đội dự án có rất

nhiều cấp độ kiểm thử để có thể tấn công được nhiều loại dữ liệu khác nhau.
- Agile sử dụng nhiều test tự động vì nó trả lại phản hồi nhanh. Test hồi quy thủ
công mất nhiều thời gian thực hiện hơn, cần có nhân lực và có thể khơng thực
hiện ngay lập tức được. Kiểm tra thủ cơng vẫn cịn quan trọng.
- Tuy nhiên, đội Agile thường thấy rằng những thơng tin phản hồi nhanh chóng
tạo nên bởi hồi quy tự động là chìa khóa để phát hiện các vấn đề một cách
nhanh chóng, do đó làm giảm rủi ro và giảm việc phải làm lại
e. Thỏa mãn mong muốn của khách hàng
- Cho dù là sử dụng phương pháp test tự động hay phương pháp test thủ cơng thì
kịch bản test vẫn cần phải khớp với yêu cầu và mong đợi từ phía khách hàng.
- Vì vậy, trước khi tốn thời gian tìm bug và sửa lỗi thì đội ngũ phát triển ứng
dụng, phần mềm và website nên đặt câu hỏi để làm sáng tỏ mong muốn của
khách hàng đối với chức năng sản


f. Giữ những dòng code được rõ ràng
- Nguyên tắc này là một ví dụ về một nguyên tắc mà đội Agile phải có. Sẽ mất
nhiều cơng sức và thời gian để sửa lỗi khi chúng được tìm thấy.
- Nếu đó là một lỗi chính đáng nó sẽ được sửa trong vịng lặp và đơi khi kết quả
sau khi sửa sẽ khơng được tốt bằng làm từ đầu vì nó ảnh hưởng tới những phần
khác.
g. Giản lược tài liệu kiểm thử
Thay vì viết dài dịng thì Agile test sẽ
- Tái sử dụng checklist
- Tập trung vào bản chất của các thử nghiệm chứ không phải là các chi tiết ngẫu
nhiên
- Sử dụng các tài liệu hướng dẫn đơn giản
- Nắm bắt những ý tưởng thử nghiệm trong điều lệ kiểm nghiệm thăm dị
h. Chưa thể hồn thành khi chưa qua giai đoạn kiểm thử
- Trong dự án truyền thống có sự phân tách rõ ràng giữa dev và test, đó là đặc trưng

cho việc dev nói “xong” với phần họ phát triển nhưng nó vẫn chưa được test. Do
đó thực tế là phần phát triển ấy vẫn chưa xong cho tới khi test xong và bug được
fix.
- Đó là lý do vì sao mà phần mềm chỉ được để “90% done”. Agile khơng tính là
“done” mà nó cần được sẵn sàng cho sự chấp nhận của Product Owner và
khách hàng cho tới khi nó được thực thi và test
k. Test-Last & Test-Driven
Trong môi trường phát triển truyền thống, test được lấy từ tài liệu yêu cầu. Yêu
cầu và design đầu tiên, sau đó đến kiểm thử. Q trình kiểm thử diễn ra ở cuối dự án.
Tuy nhiên kiểm thử cung cấp một ví dụ về ý nghĩa của việc phát triển thỏa mãn yêu
cầu. Test được định hướng từ các thành phần của project, trong đó có tài liệu dự án.
Việc thực hiện test được tiến hành vào thời điểm cuối cùng của project. Đây gọi là
cách tiếp cận “testlast” – Test sau cùng

4. Các giai đoạn kiểm thử phần mềm tương ứng với các giai đoạn phát triển
phần mềm trong mơ hình Agile
a. Tiền-Phân-đoạn (Pre-iteration):
u cầu được phân tích chi tiết bởi BA (Business Analyst – chuyên viên phân
tích nghiệp vụ) và các tiêu chí chấp nhận (acceptance criteria). Và QA sử dụng các yêu
cầu này ngay từ đầu, ta cần phải xác minh (verify) những yêu cầu đó từ sớm và thường
xuyên.
b. Xác minh Yêu cầu
- Phương pháp tiếp cận & kiểm tra nhanh Agile thông thường thiên về việc đưa
ra phản hồi sớm; Và phương pháp này cần phải bắt đầu bằng việc kiểm tra các
yêu cầu từ sớm bởi QA hoặc tester để làm sáng rõ ý nghĩa và tính khả-kiểm


-

-

-

-

-

(testability). Việc này sẽ đảm bảo các yêu cầu luôn rõ ràng và có thể kiểm thử
được.
Yêu cầu cần đủ nhỏ để có ý nghĩa trong bối cảnh xác định; Tiêu chí chấp nhận
(acceptance criteria: những story thường được sử dụng cho các tiêu chí chấp
nhận) khơng nên bị trùng lặp, chồng chéo từ những story khác nhau, các giai
đoạn nên được phân bố một cách cụ thể ví dụ như cách tiếp cận kiểm tra nhanh
thông thường dưới đây

user story: là một tóm tắt đơn giản, ngắn gọn về chức năng mà khách hàng
mong muốn.
Tiêu chí chấp nhận (Acceptance Criteria): là những tiêu chí dùng để đánh giá
sản phẩm, chức năng đã thực hiện đúng yêu cầu hay chưa? Có thể coi đó là các
tiêu chí xác nhận hồn thành story.
Các tiêu chí đặt ra phải đáp ứng các đặc tính sau:
Tính khả dụng (usability): là tiêu chí trả lời cho câu hỏi: Có dễ sử dụng hay
khơng?
Tính chức năng (Functionality)
Xử lý lỗi (error handing): Liệt kê ra những lỗi có thể gặp phải trong q trình sử
dụng chương trình và phương thức để xử lý. Ví dụ người dùng có thể thực hiện
sai thứ tự các bước và khi đó chương trình sẽ xử lý như thế nào?
Hiệu suất( Performance)
Stress tests: Là tiêu chí trả lời cho câu hỏi: Hệ thống sẽ hoạt động như thế nào
dưới những áp lực như có nhiều người truy cập tại cùng 1 thời điểm, có quá

nhiều request được gửi đến hệ thống…
Để đạt được mục tiêu của giai đoạn này cần có sự giao tiếp chặt chẽ giữa các
bên Đội Phát triển / Nhà phân tích nghiệp vụ/ Đảm bảo chất lượng


-

Khả kiểm (Testable): Các khía cạnh có thể kiểm thử được phải được xem xét
chi tiết. Những yếu tố này thường là:
- Tìm kiếm các u cầu ẩn
- Mơi trường
- Dữ liệu kiểm thử (test data)
- Sự phụ thuộc vào các yêu cầu khác
c. Các hoạt động Đảm bảo chất lượng:
- Kiểm thử chấp nhận là các yêu cầu về phương diện kiểm thử cần được thực
hiện để hiểu các yêu cầu phần mềm. Các kiểm thử chấp nhận này được sinh ra
tự động và dùng để hướng dẫn quá trình phát triển.
- Các kiểm thử chấp nhận khơng nên bao gồm tồn bộ các tình huống (case
scenarios) do điều này có thể tạo ra những sự ngưng trệ khơng cần thiết và có
thể tạo ra quá nhiều bộ kiểm thử tự động (automated test) tương tự nhau.
- Kiểm thử chấp nhận trong các dự án Agile rất khác biệt so với các dự án truyền
thống. Không giống như các dự án truyền thống, nơi kiểm thử chấp nhận xảy ra
ở phần cuối của vòng đời phần mềm, trong dự án Agile kiểm thử chấp nhận
được thực hiện trước khi phần mềm được chuyển giao. Kiểm thử chấp nhận
cũng có xu hướng được tự động hóa để họ có thể chạy như là kiểm thử hồi quy
(regression test).
- Kiểm thử tự động rất quan trọng đối với mọi dự án Agile. Các bản build thường
xuyên yêu cầu các chu kỳ phản hồi ngắn, do đó kiểm thử hồi quy phải nhanh
chóng và chính xác.
- Trong các dự án Agile, kiểm thử tự động được thực hiện bởi tất cả các cấp độ –

lập trình viên, kiểm thử viên bảo đảm chất lượng(QA tester) và các nhà phân
tích nghiệp vụ (BA). Sự tham gia của tất cả mọi người làm gia tăng tính xác
đáng của các phần kiểm thử và thường giúp xác định đúng các phần kiểm thử.
Tuy nhiên, điều này khơng có nghĩa là tất cả mọi người phải đều phải viết mã
kiểm thử.

5. Lợi Ích khi xây dựng ứng dụng web bằng phương pháp Agile
a. Sự linh hoạt
Các phương pháp luận Agile khuyến khích các bộ phận có liên quan cung cấp
đầu vào ở tất cả các giai đoạn của dự án và bản chất lặp đi lặp lại, thích ứng của họ có
nghĩa là các nhóm phát triển Agile nắm bắt các yêu cầu thay đổi.
b. Nâng cao khả năng lên kế hoạch thực tiễn cho dự án
Phần mềm làm việc được trình bày cho các bên liên quan của dự án vào cuối
mỗi lần lặp lại - đôi khi thường xuyên như một lần một tuần - tạo cơ hội để đánh giá
trong suốt quá trình xây dựng. Chu kỳ kết quả thường xuyên này cũng giúp bạn dễ
dàng xác định khối lượng công việc đã hoàn thành - cũng như tốc độ di chuyển của dự
án.


c. Tăng tốc độ hoàn tất dự án
Agile cho phép các nhà phát triển làm việc trên các chức năng cốt lõi và các
tính năng quan trọng, trong khi các nhà thiết kế làm việc trên hình ảnh và giao diện
khung dây của kỹ sư UX sẽ được sử dụng để thử nghiệm user ban đầu. Giảm thời gian
chờ đợi hoàn thành các giai đoạn trước giúp cho việc thực hiện dự án nhanh hơn và
hiệu quả hơn.
d. Phản hồi liên tục của user
Thay vì trải qua thử nghiệm khi phần mềm đã hồn tất, một dự án Agile có thể
thích ứng với các thử nghiệm thường xuyên và phản hồi của người dùng trong suốt
quá trình xây dựng - cải thiện thiết kế sản phẩm của bạn và phù hợp với thị trường
càng sớm càng tốt.

e. Tạo động lực cho team dự án
Các nhóm Agile có quy mơ nhỏ và mỗi thành viên nắm quyền sở hữu dự án.
Điều này khuyến khích các cá nhân làm việc chăm chỉ hơn, vì điều đó có nghĩa là họ
cảm thấy bản thân như những bánh răng nhỏ trong một cỗ máy khổng lồ và không thể
thiếu đối với thành công của dự án.
g. Tăng sự gắn bó trong mối quan hệ làm việc
Đặt trọng tâm lớn vào giao tiếp và hợp tác trong nhóm phát triển và giữa các
bên liên quan, có nghĩa là các tổ chức thường tiếp tục xây dựng các mối quan hệ làm
việc bền vững và thành công trong nội bộ hoặc với các cơ quan Agile bên ngồi của
họ.
h. Giảm thiểu chi phí
Vì Agile hoạt động tốt nhất với các nhóm phát triển nhỏ hơn và là cách tạo
phần mềm nhanh hơn, hiệu quả hơn, nên nó thường tiết kiệm chi phí hơn các phương
pháp phát triển truyền thống. Hơn nữa, vì bản chất Agile là linh hoạt, bạn có khả năng
bỏ ra chi phí ít hơn cho các thay đổi đối với chức năng sau khi q trình phát triển
hồn tất.
k. Chất lượng sản phẩm tốt hơn
Các phương pháp Agile xây dựng các vòng lặp kiểm tra và phản hồi trong quá
trình phát triển, khuyến khích mã hóa “sạch sẽ”, đo lường và đánh giá thường xuyên
tất cả các công việc được thực hiện trong suốt dự án và do đó sản phẩm cuối có chất
lượng cao hơn.
j. Hạn chế rủi ro
Agile có nghĩa là liên tục ưu tiên và phát triển các tính năng cốt lõi trước, đồng
thời lưu các tính năng ít giá trị hơn cho đến sau này trong quá trình phát triển. Điều
này làm giảm rủi ro của dự án, vì ngay cả trong giai đoạn đầu của dự án, một phần
mềm hoạt động đã được sản xuất.
Nếu bạn khơng có nhóm Agile nội bộ, thì việc th một cơ quan phát triển sử
dụng phương pháp Agile cho dự án phát triển web của bạn có thể giúp bạn gặt hái tất
cả những lợi ích mà Agile mang lại.

6. Scrum là gì?
Scrum là một “bộ khung làm việc” cơ bản để tiếp cận những công việc phức
tạp. Dựa trên bộ khung này, nhóm làm việc có thể áp dụng những quy trình, kỹ thuật
khác nhau cho cơng việc của mình… Nó là một thành viên của họ Agile.

Credit: Scrum.org
a. Scrum có ích gì cho phát triển phầm mềm hiện nay
Nó giúp loại bỏ những công đoạn phức tạp và chỉ tập trung vào những công
đoạn cần thiết đáp ứng được nhu cầu của khác hàng đưa ra. Ba yếu tố nịng cốt tạo
thành một mơ hình quản lý tiến trình thực nghiệm gồm: sự minh
bạch (transparency), thanh tra (inspection) và thích nghi (adaptation).
b. Ba giá trị cốt lõi của Scrum
1. Minh bạch
Muốn áp dụng thành công Scrum, các thơng tin liên quan đến q trình phải
mình bạch và thơng suốt. Các thơng tin có thể là tầm nhìn của sản phẩm, yêu cầu của
khách hàng, tiến độ cơng việc, các rào cản khác…
Từ đó mọi thành viên ở vai trị khác nhau có đầy đủ thơng tin cần có để tiến
hành quyết định trong việc nâng cao hiệu quả công việc.
2. Thanh tra
Phải thường xuyên thanh tra các hoạt động trong Scrum và tiến độ đến đích để
phát hiện các bất thường khơng theo ý muốn. Tần suất thanh tra không nên quá dày để
khỏi ảnh hưởng đến công việc. Công tác thanh tra khi được thực hiện bởi người có kĩ
năng tại các điểm quan trọng của công việc sẽ giúp cải tiến liên tục trong Scrum.


3. Thích nghi
Scrum mang lợi thế là tính linh hoạt rất cao, nhờ đó mang lại tính thích nghi
cao. Dựa vào thông tin liên tục và minh bạch từ quá trình thanh tra và làm việc, Scrum
có thể cho lại các thay đổi tích cực, nhờ đó mang lại thành cơng cho dự án.

c. Lợi ích mà Scrum mang lại
Tính minh bạch, kiểm tra, và thích nghi là 3 nền tảng cơ bản của Scrum. Và
dưới đây là những lý do tại sao nên dùng Scrum.
1. Cải thiện chất lượng phần mềm, dễ học và dễ sử dụng.
2. Rút ngắn thời gian phát hành phần mềm, cho phép khách hàng sử dụng sản
phẩm sớm hơn.
3. Nâng cao tinh thần đồng đội, tối ưu hóa hiệu quả và nỗ lực của đội phát
triển.
4. Gia tăng tỷ suất hoàn vốn đầu tư (ROI)
5. Tăng mức độ hài lòng của khách hàng
6. Kiểm soát dự án tốt, cải tiến liên tục
7. Giảm thiểu rủi ro khi xây dựng sản phẩm
d. Các khái niệm cơ bản Scrum
1. Scrum Team
Scrum team chia làm 3 vai trò bao gồm những thành phần sau:
 Product Owner: Nhiệm vụ của Product Owner là đảm bảo việc quản lý
những cơng việc cịn tồn đọng (Product backlog) của việc phát triển sản
phẩm phần mềm. Product Owner phải liên tục cập nhật thông tin cho các
thành viên trong team để họ hiểu về u cầu hay các tính năng cần có của
sản phẩm ngay cả khi họ không trực tiếp phát triển tính năng đó.
 Development Team: là những lập trình viên sẽ tham gia vào việc phát triển
từng tính năng cụ thể. Các lập trình viên này có thể sẽ có kỹ năng khác nhau
và một số sẽ giỏi về những kỹ năng nhất định. Tuy nhiên khi sử dụng Scrum
thì tất cả các thành viên của Development Team yêu cầu phải có khả năng
làm việc thay thế vị trí của nhau và không ai chỉ chịu trách nhiệm phát triển
một (hoặc một số) tính năng nhất định.
 Scrum Master: sẽ chịu trách nhiệm cho việc lên kế hoạch để phân công
công việc, sắp xếp thứ tự ưu tiên giải quyết những cơng việc tồn đọng nào có
trong Backlog trước, tổ chức các buổi họp với Product Owner để theo dõi
tình hình và nắm thông tin cần thiết.

2. Sprint
Sprint là mộ phân đoạn lặp đi lặp lại trong quy trình phát triển phần mềm, có
khung thời gian thường là 1 tháng (từ 1 – 4 tuần) mà theo đó sản phẩm sẽ
được release phiên bản mới. Khi một Sprint kết thúc thì Scrum Master cần phải
chuyển trạng thái của nó sang Done.


Khi bắt đầu một Sprint thì Scrum Master cần đưa ra mục tiêu của Sprint đó và
mục tiêu này khơng được phép thay đổi cho tới khi Sprint hoàn thành. Tuy nhiên
Product Owner vẫn có quyền huỷ một Sprint trước thời hạn kết thúc của nó.
Mặc dù để làm điều này thì Product Owner cần sự đồng thuận của Development
Team cũng như Scrum Master. Sau khi một Sprint kết thúc thì các bên sẽ dựa trên kết
quả của Sprint đó để lên kế hoạch cho Sprint tiếp theo.
3. Sprint Planning
Đây là bước đầu tiên cần phải thực hiện trước khi một Sprint bắt đầu.
Development team họp với Product Owner để lên kế hoạch cho một sprint. Những
công việc nào cần phải được hoàn thành trong Sprint này và làm sao để có thể hồn
thành những cơng việc này.
Sau khi thống nhất được số lượng cơng việc, thời gian hồn thành thì chúng ta
có thể bắt đầu Sprint. Trong khi thực hiện một Sprint chúng ta sẽ phải có những buổi
họp được gọi là Daily Sprint hay Daily Meeting.
4. Daily Sprint
Các buổi họp Daily Sprint thường kéo dài khoản 15 phút, trong buổi họp này tất
cả các thành viên sẽ lần lượt báo cáo lại:
 Những gì họ đã làm được ngày hơm qua
 Những gì họ cần làm ngày hơm nay
 Những khó khăn mà họ gặp phải
Mỗi buổi họp này sẽ giúp việc dự kiến được kế hoạch đưa ra trong Sprint đang
làm sẽ tiến triển ra sao và liệu có cần phải cập nhật lại bản kế hoạch đã đưa ra hay
không. Tất nhiên cần nhớ rằng việc thay đổi kế hoạch này không bao gồm thay đổi

mục tiêu đã đưa ra của Sprint.
Ví dụ bạn có thể tăng thêm thời gian để hoàn thành một chức năng và qua đó
khiến Sprint phải kéo dài hơn dự kiến. Tuy nhiên mục tiêu của Sprint là cho phát hành
một phiên bản mới cần được giữ nguyên.
5. Sprint Review
Là công việc được thực hiện bởi nhóm phát triển và product owner ở cuối mối
Sprint nhằm đánh giá lại kết quả thực hiện được. Từ lúc Sprint mới hoàn thành và qua
đó đưa ra những chỉnh sửa, thay đổi cần thiết ở Sprint sau.
6. Sprint Restrospective
Dưới sự trợ giúp của Scrum master, team phát triển sẽ tổng kết những kiến nghị
và đánh giá từ bước Sprint Review ở trên để đưa ra những cải tiến nhằm nâng cao hiệu
quả làm việc cũng như sản phẩm.
7. Các công cụ (artifacts) Scrum
Scrum sử dụng các công cụ rất đơn giản nhưng hiệu quả để trợ giúp công việc.
Product backlog
Đây là danh sách ưu tiên các tính năng (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 chịu trách nhiệm sắp xếp độ ưu tiên cho từng hạng mục
(Product Backlog Item) trong Product Backlog dựa trên các giá trị do Product Owner
định nghĩa (thường là giá trị thương mại – business value).
Sprint backlog
Đây là bản kế hoạch cho một Sprint; là kết quả của buổi họp lập kế hoạch
(Sprint Planning).
Với sự kết hợp của Product Owner, nhóm sẽ phân tích các u cầu theo độ ưu
tiên từ cao xuống thấp để hiện thực hóa các hạng mục trong Product Backlog dưới
dạng danh sách công việc (TODO list).
Burndown Chart
Đây là biểu đồ hiển thị xu hướng của dự án dựa trên lượng thời gian cần thiết

còn lại để hồn tất cơng việc.
Burndown Chart có thể được dùng để theo dõi tiến độ của Sprint (được gọi là
Sprint Burndown Chart) hoặc của cả dự án (Project Burndown Chart).
Biểu đồ burndown không phải là một thành tố tiêu chuẩn của Scrum theo định
nghĩa mới, nhưng vẫn được sử dụng rộng rãi do tính hữu ích của nó.
Các cơng cụ quản lý dự án theo Agile mà bạn nên biết
Trello

Hình. Ví dụ về Trello


Đây là một trong những ứng dụng quản lý dự án nổi tiếng và được sử dụng
nhiều nhất. Nó có cả tài khoản miễn phí và cao cấp mang đến cho bạn cơ hội tuyệt vời
để sử dụng hầu hết các chức năng phổ biến.
Cấu trúc của Trello dựa trên phương pháp kanban. Tất cả các dự án được đại
diện bởi các bảng, có chứa danh sách. Mọi danh sách đều có các thẻ lũy tiến mà bạn
được tạo dưới dạng kéo và thả. Người dùng có liên quan đến bảng, có thể được gán
cho thẻ.
Tóm lại, nó có nhiều tính năng hay, nhỏ nhưng khơng kém phần hữu ích: viết
bình luận, chèn tệp đính kèm, ghi chú, ngày đáo hạn, danh sách kiểm tra, nhãn màu,
tích hợp với các ứng dụng khác, v.v. Ngoài ra, Trello được hỗ trợ bởi tất cả các nền
tảng di động. Trello là công cụ có thể được sử dụng cho cả cơng việc và các quy trình
cá nhân.

JIRA

Hình. Ví dụ về JIRA
JIRA là một công cụ được phát triển để theo dõi lỗi, theo dõi vấn đề và quản lý
dự án cho các quy trình phát triển phần mềm và di động. Bảng điều khiển JIRA có
nhiều chức năng & tính năng hữu ích có thể xử lý các vấn đề khác nhau một cách dễ

dàng.
Một số tính năng và sự cố chính: loại sự cố, quy trình làm việc, màn hình,
trường, thuộc tính vấn đề. Một số tính năng bạn sẽ khơng tìm thấy ở nơi khác. Bảng


điều khiển trên JIRA có thể được tùy chỉnh để phù hợp với quy trình kinh doanh của
bạn.

Asana

Hình. Ví dụ về Asana


Asana là công cụ quản lý công việc cho phép các nhóm chia sẻ, lập kế hoạch, tổ
chức và theo dõi tiến trình của các nhiệm vụ mà mỗi thành viên đang thực hiện. Nó
đơn giản, dễ sử dụng và miễn phí cho tối đa 30 người dùng trong một nhóm.
Như tất cả các nền tảng phần mềm quản lý dự án Agile trước đây với mục tiêu
chính là cho phép quản lý các dự án và nhiệm vụ. Điều đáng chú ý là bạn khơng cần
phải có email để sử dụng Asana. Mỗi nhóm có thể tạo nơi làm việc sẽ chứa các dự án
và nhiệm vụ của dự án: mỗi tác vụ có thể có ghi chú, nhận xét, tệp đính kèm và thẻ.
Cơng cụ này có thể được sử dụng cho các quy trình nhỏ và cho các quy trình
lớn mà khơng có bất kỳ giới hạn nào trong các ngành hoặc bộ phận.
Resource cho bạn tìm hiểu về Agile và Scrum:
 Việc làm, tuyển dụng Agile: Có rất nhiều tại TopDev với mức lương cực hấp
dẫn.
 Scrum.org: đầy đủ kiến thức cơ bản, nâng cao về Scrum và các chứng chỉ
Scrum.
 Agile Manifesto: cơ bản về Agile, tuyên ngôn Agile cho người mới bắt đầu.
 Agile Vietnam Group và Agile forum Vietnam: diễn đàn lớn nhất về Agile
tại Việt Nam, cùng chia sẻ thông tin, kiến thức, sự kiện về Agile.

CHƯƠNG II. KẾT QUẢ THỰC NGHIỆM
2.1. Website kiểm thử
Website bán đồ cơng nghệ như điện thoại, máy tính ,...

2.2. u cầu đặc tả của website
2.2.1. Yêu cầu chức năng
Đăng nhập
-Mô tả: khách hàng đăng nhập vào hệ thống với tài khoản của mình. Có chức
năng tự động đăng nhập cho những lần sau.
Đăng ký
- Mô tả: Khách hàng tạo tài khoản mới, tự động đăng nhập sau khi đăng ký.
Sửa thông tin khách hàng
-Mô tả: Khách hàng sửa thông tin cá nhân như email, số điện thoại, họ tên, mật
khẩu…Hệ thống cập nhật lại thông tin khách hang
Chi tiết sản phẩm
-Mô tả: Khách hàng xem các thông tin chi tiết của sản phẩm như: tên, hình ảnh,
giá, mơ tả, đánh giá…
Thêm giỏ hàng
-Mô tả: Khách hàng thêm các sản phẩm vào giỏ hàng. Hệ thống cập nhật giỏ
hàng.
Thêm vào danh mục u thích
-Mơ tả: Khách hàng thêm các sản phẩm vào danh mục yêu thích. Hệ thống cập
nhật danh mục u thích.
Tìm kiếm sản phẩm


Mơ tả: Khách hàng tìm kiếm các sản phẩm theo tên, từ khóa, giá, nhà sản
xuất…
Mua hàng

Mơ tả: Khách hàng điền số điện thoại và địa chỉ nhận hàng vào biểu mẫu đặt
hàng sau đó nhấn đặt hàng. Hệ thống sẽ tạo đơn cho khách hàng.
2.2.2. Yêu cầu hiệu năng
Tính dễ sử dụng:
Ngôn ngữ giao diện dễ hiểu, các biểu tượng mang ý nghĩa nhất quán
Tính ổn định:
Số lượng truy cập tối đa cùng một thời điểm: 1000 truy cập

2.3. Công cụ kiểm thử Jmeter
JMeter là một ứng dụng mã nguồn mở thuần Java, được phát triển đầu tiên bởi
Stefano Mazzocchi. JMeter dùng để kiểm tra hiệu năng, khả năng chịu tải và các chức
năng.
Tại sao sử dụng JMeter?
Bạn đã bao giờ kiểm thử một trang web mà biết nó hoạt động tốt chưa? Bao
nhiêu người truy cập mà trang web vẫn hoạt động tốt, không hề xảy ra vấn đề gì?
Giả sử một ngày nào đó, sếp u cầu bạn kiểm thử hiệu năng của trang web
www.google.com cho 100 người dùng truy cập một lúc, khi đó bạn sẽ làm gì? Bạn
nghĩ ra cách 100 người sử dụng 100 máy PC truy cập đồng thời hay sao?
Bạn nghĩ ra cách 100 người sử dụng 100 máy PC truy cập đồng thời hay sao?
Thật không khả thi chút nào khi điều kiện thiết bị không cho phép. Nếu sếp bạn lại bảo
cho số lượng lên đến 1000 lại càng không thể. Chính vì vậy cần phải có một cơng cụ
(tool) để bạn thực hiện mô phỏng những hành vi của con người để kiểm thử hiệu suất
của trang web đó chính là JMeter.
Jmeter có thể làm gì?
Jmeter là cơng cụ giúp ta giả lập thao tác của người dùng trên web. Bằng việc
giả lập các thao tác của một số lượng người dùng nhất định, Jmeter giúp ta đánh giá
được các kết quả:
 Web có thể chịu được bao nhiêu lượt truy cập/thao tác liên tục cùng lúc?
 Để đáp ứng số lượng X người sử dụng, thì cần phân phối họ truy cập trong
bao lâu? Như thế nào để Web vẫn hoạt động bình thường?

 Thời gian response dữ liệu của server với từng mức tải người dùng?
 Kết hợp với 1 số tool monitor server, ta có thể theo dõi thay đổi vật lý của
server khi có tải lớn như: CPU, RAM, Network traffic…
Cài đặt và khởi chạy Jmeter
Bước 1: Download Apache Jmeter