báo cáo thực tập Kiểm thử phần mềm và ứng dụng

HỌC VIỆN NÔNG NGHIỆP VIỆT NAM

KHOA CÔNG NGHỆ THÔNG TIN

BÁO CÁO TIẾN ĐỘ THỰC TẬP CHUYÊN NGÀNH

ĐỀ TÀI: “Kiểm thử phần mềm và ứng dụng”
Người thực hiện:

Võ Thị Anh- 601267- K60QLTT
Nguyễn Thị Mai- 601309- K60QLTT

Giảng viên hướng dẫn:
Bộ môn quản lý:

Th.S Trần Trung Hiếu
Công nghệ phần mềm

Hà Nội - 2019
1


2


MỤC LỤC

Kết quả thực hiện đề tài theo đề cương thực tập chuyên ngành (Đến ngày 10
tháng 3 năm 2019)
1. Những kết quả đã hoàn thành được theo tiến độ thực tập chuyên ngành
 Tổng quan tình hình nghiên cứu về Software Tesing trong nước và

ngoài nước
 Nội dung và các phương pháp nghiên cứu Kiểm thử phần mềm
 Tổng quan về kiểm thử phần mềm:
- Các khái niệm cơ bản về kiểm thử phần mềm
- Các phương pháp về kiểm thử phần mềm
3


Các kĩ thuật trong kiểm thử phần mềm
Phân loại kiểm thử
 Tìm hiểu lý thuyết cơ bản các công cụ hỗ trợ trong quá trình kiểm thử
2. Dự kiến tiến độ tiếp theo
 Giới thiệu về Website thương mại điện tử YSheer, các chức năng
-

chính và mô tả nghiệp vụ của hệ thống này.
 Ứng dụng kiểm thử lên Website, sử dụng các công cụ hỗ trợ và báo
cáo kết quả.

PHẦN I: MỞ ĐẦU
1.1 Đặt vấn đề
Trong những năm gần đây với sự phát triển rất mạnh của công nghệ thông tin,
ngành công nghệ phần mềm đang chiếm một vị trí hết sức quan trọng trong xu
hướng phát triển kinh tế công nghiệp hóa, hiện đại hóa của nước ta. Cùng với sự
phát triển ấy các chương trình phần mềm ra đời ngày càng nhiều, đòi hỏi các nhà
sản suất phần mềm phải có một phương pháp để nâng cao chất lượng sản phẩm
cũng như tối ưu hiệu suất làm việc để có thể cạnh tranh. Vì vậy kiểm thử phần
mềm đang ngày càng đóng vai trò quan trọng trong ngành công nghiệp phát triển
phần mềm không chỉ ở Việt Nam mà trên thế giới. Kiểm thử phần mềm là một

khâu rất quan trọng trong quá trình phát triển phần mềm. Kiểm thử phần mềm để
kiểm tra phần mềm có đúng với đặc tả và thiết kế hệ thống không, có đáp ứng yêu
cầu người dùng không, có lỗi lập trình không, hoạt động có hiệu quả không,…Như
vậy, kiểm thử phần mềm là để đáp ứng yêu cầu người dùng, phát triển lỗi để từ đó
nâng cao chất lượng phần mềm. Vậy làm thế nào để có thể kiểm tra dự án phần
4


mềm của ta chạy ổn định, đạt được tính hiệu quả cao, nhưng lại tiết kiệm được thời
gian cũng như kinh phí trong quá trình kiểm thử là một điều thiết yếu đối với các
nhà kiểm thử.
Với mong muốn có cái nhìn xác thực, rõ ràng hơn về quy trình kiểm thử phần
mềm, đảm bảo chất lượng phần mềm và tiếp cận với các công cụ hỗ trợ kiểm thử,
giải quyết phần nào vấn đề về tiết kiệm thời gian, kinh phí trong việc tìm kiếm lỗi,
quản lý lỗi khi tiến hành kiểm thử; đồng thời rèn kỹ năng làm việc, tạo tiền đề định
hướng cho tương lai sau khi ra trường. Được sự đồng ý của Th.S Trần Trung Hiếu
và Khoa CNTT chúng em chọn đề tài “Kiểm thử phần mềm và ứng dụng”.
1.2 Mục đích và yêu cầu
1.2.1 Mục đích
Tìm hiểu cơ sở lý thuyết về kiểm thử phần mềm, các công cụ hỗ trợ trong quá
trình kiểm thử và ứng dụng để kiểm thử một số chức năng của website thương mại
điện tử Ysheer. Mục tiêu cụ thể như sau:




Nắm được tổng quan về quá trình kiểm thử phần mềm.
Hiểu được tầm quan trọng, mục đích, vai trò kiểm thử phần mềm.
Tìm hiểu về các cấp độ, các nguyên tắc, các phương pháp, kỹ thuật kiểm thử




phần mềm.
Biết cài đặt và sử dụng các công cụ trong quá trình kiểm thử.
Áp dụng tiến hành kiểm thử chức năng, hiệu năng trên website cụ thể.



1.2.2 Yêu cầu
Để đạt được mục đích như trên, thì trong quá trình thực hiện đề tài phải nắm
được các yêu cầu và cần tập trung vào tìm hiểu tài liệu liên quan đến vấn đề nghiên
cứu:
 Hiểu được các kiến thức cơ bản về (khái niệm, quy trình, cấp độ, nguyên

tắc…) trong kiểm thử và tận dụng theo đúng quy trình.
 Hiểu biết các phương pháp kiểm thử, thiết kế các trường hợp kiểm thử cho
một phần mềm xác định.
5


 Sử dụng công cụ quán lý lỗi Redmine, công cụ kiểm thử hiệu năng Jmeter,

và ứng dụng vào dự án thực tế.

6


PHẦN II: TỔNG QUAN TÌNH HÌNH NGHIÊN CỨU TRONG VÀ NGOÀI
NƯỚC

2.1 Tình hình nghiên cứu trong nước
Công nghệ thông tin Việt Nam nói chung và phát triển phần mềm nói riêng
đang có những bước phát triển tốt và sinh động. Tuy nhiên, có một thực tế là kiểm
thử phần mềm ở Việt Nam đã đi sau nhiều nước khác. Về mặt số lượng thì Việt
Nam thấp hơn rất nhiều so với thế giới. Tỷ lệ developer và tester trong dự án của
thể giới là 3:1 còn ở Việt Nam lại là 5:1.
Trước đây, về mặt chất lượng, ở Việt Nam chủ yếu là các dự án outsource (gia
công phần mềm), mà đa phần các dự án này chủ yếu tập trung vào những công việc
cấp thấp. Dù đã có nhiều công ty đảm nhận những dự án lớn, giá trị cao nhưng số
lượng đó còn rất ít, do đó cần phải tăng tốc để bắt kịp trình độ của thế giới.
Ở thời điểm hiện tại, nhiều công ty, doanh nghiệp trước kia phát triển mạnh về
xây dựng phần mềm cũng đã phát triển mạnh về kiểm thử, có thể kể đến 1 số
doanh nghiệp lớn như: IT Sol, Citigo, Fsoft, Viettel, Simax…
Về xu hướng kiểm thử phần mềm đang phát triển mạnh ở Việt Nam, nó vẫn là
một bài toán không chỉ với các công ty sản xuất phần mềm. Nó vừa để kiểm soát
lỗi trong quá trình lập trình cũng vừa là chứng minh cho khách hàng phần mềm đã
thực hiện đúng các yêu cầu họ dặt ra. Là các xu hướng về kiểm thử trên nền web,
kiểm thử app mobile, sử dụng các công cụ hỗ trợ đang được nhiều công ty, doanh
nghiệp hướng đến và ưu tiên phát triển.
2.2 Tình hình nghiên cứu ngoài nước
Testing ở thế giới đã phát triển từ lâu, nếu như ở Việt Nam tỉ lệ chỉ có 1
Tester thì có 5 lập trình viên nhưng ở nước ngoài tỉ lệ này là 4:1, như vậy với 4
Tester thì mới có một lập trình viên. Có thể nói Testing có rất nhiều tiềm năng phát
triển.
7


Nhật Bản là một quốc gia có nền Công nghệ thông rất phát triển. Người
Nhật vốn đã tỉ mỉ nên họ muốn sản phẩm của họ làm ra phải đạt được chất lượng,
cũng như quy trình làm ra sản phẩm phải được quản lý chặt chẽ kể từ giai đoạn đầu

của dự án. Nên với QA/Tester người Nhật không chỉ có kiểm thử sản phẩm mà họ
còn vừa phải đảm bảo quy trình của phần mềm, vừa phải tìm ra những lỗi của sản
phẩm. Vì vậy Test Matrix là một phần quan trọng và không thể thiếu trong các dự
án của Nhật Bản.

2.3 Đề tài và tính thời sự, tầm quan trọng của đề tài
Thỏa mãn nhu cầu của người dùng là việc rất quan trọng khi tạo ra sản phẩm
hay đảm bảo chất lượng phần mềm là một phần không thể thiếu trong quá trình sản
xuất phần mềm. Để tạo ra một sản phẩm chất lượng lại tiết kiệm kinh phí, nguồn
lực, thời gian không phải là một việc dễ dàng. Vì vậy, việc sử dụng công cụ hỗ trợ
giúp quản lý chất lượng phần mềm được ưu tiên phát triển trong ngành công nghệ
phần mềm. Với đề tài “ Kiểm thử phần mềm và ứng dụng” sẽ giúp ta hiểu rõ hơn
việc tìm kiếm, theo dõi, xử lý, cập nhật và quản lý lỗi phát sinh trong quá trình
kiểm tra, kiểm thử phần mềm đảm bảo chất lượng phần mềm trước khi được triển
khai vào thực tế.

8


PHẦN III: NỘI DUNG VÀ PHƯƠNG PHÁP NGHIÊN CỨU
3.1 Địa điểm và thời gian nghiên cứu
• Địa điểm nghiên cứu:
- Học Viện Nông Nghiệp Việt Nam - Trâu Quỳ - Gia Lâm - Hà Nội.
• Địa điểm thực tập:
- Công ty cổ phần Công nghệ và Giải pháp Simax (Phòng 1406, Tòa HH1,
Dương Đình Nghệ - Yên Hòa, Cầu Giấy, Hà Nội.).
• Thời gian thực tập và nghiên cứu:
- Bắt đầu: 02/01/2019
- Kết thúc: 28/02/2019
• Công việc thực hiên:

- Viết đề cương thực tập chuyên ngành.
- Tìm hiểu về các nguyên tắc cơ bản của kiểm thử phần mềm.
- Tìm hiểu về mô hình phát triển của phần mềm, quản lý chất lượng phần
mềm.
- Tìm hiểu về quy trình của kiểm thử phần mềm, các mức kiểm thử, các
loại kiểm thử, các phương pháp kiểm thử, các kỹ thuật kiểm thử.
- Tìm hiểu các công cụ hỗ trợ kiểm thử: Jmeter, Redmine.
- Tìm hiểu hệ thống website Thương mại điện tử.
- Ứng dụng kiểm thử chương trình và viết báo cáo kiểm thử.
- Hoàn thành báo cáo thực tập chuyên ngành.
3.2 Nội dung nghiên cứu
Bài báo cáo được tổ chức là 5 phần như sau:
• Phần I: Nêu tên đề tài, trình bày lý do, mục đích và yêu cầu khi thực hiện

đề tài.
• Phần II: Trình bày tổng quan về tình hình nghiên cứu trong nước và ngoài
nước.
• Phần III: Trình bày nội dung và phương pháp nghiên cứu.
• Phần IV: Kết quả và thảo luận.
Chương 1: Tổng quan về kiểm thử phần mềm: Chương này nêu ra các khái
niệm cơ bản như: Kiểm thử phần mềm là gì? Vai trò của kiểm thử phần mềm, quy

9


trình phát triển phần mềm, quy trình kiểm thử phần mềm, các giai đoạn kiểm thử
phần mềm, phương pháp kiểm thử phần mềm…
Chương 2: Các công cụ hỗ trợ quá trình kiểm thử: Chương này trình bày tổng
quan về các công cụ: JMeter, Redmine.
Chương 3: Chương này giới thiệu về website, các chức năng chính, mô tả

nghiệp vụ hệ thống của website này.
Chương 4: Ứng dụng kiểm thử website .Ứng dụng kiểm thử sử dụng các công
cụ hỗ trợ và báo cáo kết quả.
- Phần V: Kết luận và đề nghị
- Phần VI: Tài liệu tham khảo
3.3. Phương pháp nghiên cứu
-

Tham khảo các giáo trình, tài liệu liên quan đến nội dung đề tài (ebook, các
bài viết, bài học trên các website và làm việc thực tế trên website).

- Khảo sát bài toán thực tế.
- Lấy yêu cầu người dùng.
- Thu thập dữ liệu.
-

Kiểm thử và nhận ý kiến đánh giá của người sử dụng và giáo viên hướng
dẫn.

10


PHẦN IV: KẾT QUẢ VÀ THẢO LUẬN
Chương 1: Tổng quan về kiểm thử phần mềm
1. Các khái niệm cơ bản về kiểm thử phần mềm
1.1 Kiểm thử phần mềm là gì?
Kiểm thử phần mềm (Software testing) là hoạt động nhằm tìm kiếm, phát
hiện các lỗi của phần mềm; đả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 đã đặt ra; cung cấp mục tiêu, cái nhìn độc
lập về phần mềm, cho phép việc đánh giá và hiểu rõ hơn các rủi ro khi thực thi

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 tìm thấy.
1.2 Lỗi phần mềm là gì? Nguyên nhân sinh ra lỗi của phần mềm
• Lỗi phần mềm là: Lỗi phần mềm là một thất bại hoặc sai sót gây ra kết quả
sai hoặc không mong muốn trong một chương trình. Đó là một lỗi khiến cho
ứng dụng không thể vận hành như mong muốn.
• Nguyên nhân sinh ra lỗi của phần mềm:
Có rất nhiều nguyên nhân dẫn đến lỗi phần mềm. Lý do thường gặp
nhất đó là do sai sót của con người trong quá trình thiết kế và lập trình. Khi
đã biết được nguyên nhân dẫn đến những khiếm khuyết của phần mềm, việc
sửa chữa để giảm thiểu những khiếm khuyết đó sẽ trở nên dễ dàng hơn rất
nhiều.
Các lỗi phổ biến như:
 Hiểu lầm trong giao tiếp hoặc không có giao tiếp: Thành công của ứng
dụng phần mềm nào cũng đều dựa vào sự giao tiếp giữa các bên liên
quan, đội ngũ phát triển và đội ngũ kiểm thử. Những yêu cầu không rõ
ràng và những hiểu lầm về các yêu cầu là hai lý do chính dẫn đến khiếm
khuyết trong phần mềm. Ngoài ra, những khiếm khuyết phát sinh trong
11


giai đoạn phát triển còn là do đội ngũ phát triển không được thông báo










chính xác về các yêu cầu.
Sự phức tạp của các ứng dụng phần mềm hiện hành có thể trở nên rất
khó hiểu đối với bất kỳ ai không có kinh nghiệm trong lĩnh vực phát triển
phần mềm hiện đại. Các giao diện loại Windows, cấu trúc máy kháchmáy chủ và các ứng dụng phân tán, truyền thông dữ liệu, cơ sở dữ liệu
quan hệ khổng lồ, và kích thước của các ứng dụng đã góp phần làm tăng
thêm sự phức tạp của phần mềm/hệ thống. Và việc áp dụng những kỹ
thuật hướng đối tượng có thể phức tạp hóa, thay vì đơn giản hóa, một dự
án, trừ khi dự án đó được thiết kế tốt.
Lỗi lập trình: Các lập trình viên cũng là con người, nên việc họ mắc sai
sót là điều bình thường. Không phải thành viên nào của đội phát triển
cũng là chuyên gia về miền. Những lập trình viên thiếu kinh nghiệm hay
không có kiến thức thích hợp về miền có thể mắc phải những lỗi rất đơn
giản trong khi lập trình. Việc thiếu thực hành các thao tác lập trình đơn
giản, kiểm thử đơn vị hay gỡ lỗi là một số nguyên nhân thường thấy dẫn
đến các lỗi phát sinh trong quá trình phát triển.
Thay đổi yêu cầu: Khách hàng có thể không hiểu được ảnh hưởng mà
những thay đổi đó gây ra, hoặc là họ hiểu nhưng vẫn yêu cầu thay đổi thiết kế lại, thay đổi nhân sự, ảnh hưởng đến những dự án khác, những
đầu việc đã hoàn thành có thể cần làm lại hoặc bỏ đi, những yêu cầu về
phần cứng có thể bị ảnh hưởng, v.v...Khi thay đổi xảy ra, dù lớn hay nhỏ
thì những mắt xích giữa các phần của dự án cũng rất có khả năng sẽ
tương tác với nhau và gây ra vấn đề; và quá trình giám sát những thay đổi
sẽ rất phức tạp và dễ dẫn đến lỗi. Qua đó, tinh thần làm việc của đội ngũ
nhân sự cũng có thể bị ảnh hưởng.
Áp lực thời gian: Việc lên lịch cho các dự án phần mềm là khó nhất, và
thường đòi hỏi con người phải phỏng đoán rất nhiều. Khi hạn chót gần kề
và khủng hoảng xuất hiện thì sai lầm là điều rất khó tránh khỏi. Lịch trình
không thực tế, mặc dù không phổ biến, nhưng lại là mối quan tâm chính
trong các dự án quy mô nhỏ/công ty và dễ dẫn đến lỗi phần mềm. Nếu

không có đủ thời gian để thiết kế, coding và kiểm thử một cách hoàn
chỉnh thì chắc chắn phần mềm sẽ có lỗi.
Các công cụ phát triển phần mềm: Các công cụ trực quan, các thư viện
lớp, trình biên dịch, công cụ kịch bản, v.v...thường cũng có lỗi riêng hoặc
12









được tài liệu hóa rất kém, dẫn đến việc sản sinh thêm lỗi. Các lập trình
viên phần mềm thường dùng những công cụ phần mềm thay đổi liên tục,
nhưng việc giữ bắt kịp với các phiên bản khác nhau và khả năng tương
thích của chúng là một vấn đề rất lớn đang hiện hữu.
Không thiết lập thử nghiệm thích hợp (môi trường thử nghiệm) để kiểm
tra tất cả các yêu cầu.
Viết code hoặc kiểm thử các trường hợp khi chưa hiểu rõ tất cả các yêu
cầu.
Thiết kế sai dẫn đến việc trong tất cả các giai đoạn của chu kỳ phát triển
phần mềm đều có vấn đề.
Thường xuyên phát hành các bản vá lỗi phần mềm trong khi chưa hoàn
thành việc kiểm tra vòng đời của phần mềm.
Dành ít thời gian hoặc bỏ qua hoàn toàn việc kiểm tra hồi quy.
Không theo dõi quá trình phát triển và kiểm thử một cách liền mạch.
Những thay đổi vào phút cuối rất có thể sẽ dẫn đến lỗi.

1.3 Vai trò của kiểm thử phần mềm
Lỗi có thể xuất hiện ở bất kì giai đoạn nào trong vòng đời phát triển phần
mềm, kiểm tra nghiêm ngặt là cần thiết trong quá trình phát triển và bảo trì để xác
định các lỗi để giảm thất bại khi hoạt động và làm tăng chất lượng của hệ thống khi
đi vào vận hành.
-

Tìm các bug (lỗi) phát sinh do lập trình viên tạo ra khi code.
Đạt được sự tự tin và cung cấp thông tin về mức độ chất lượng.
Để ngăn ngừa lỗi.
Đảm bảo rằng kết quả cuối cùng đáp ứng các yêu cầu kinh doanh và người
sử dụng.
Để đạt được sự tín nhiệm của khách hàng bằng cách cung cấp cho họ một
sản phẩm chất lượng.

Kiểm thử phần mềm sẽ giúp hoàn thiện các ứng dụng phần mềm hoặc sản
phẩm so với yêu cầu kinh doanh và người sử dụng. Nó là rất quan trọng để đảm
bảo kiểm thử tốt để kiểm thử các ứng dụng phần mềm hoàn toàn và chắc chắn rằng
nó hoạt động tốt và theo các thông số kỹ thuật.

13


Kiểm tra phần mềm để chắc chắn kiểm thử đang thực hiện đúng cách và hệ
thống đã sẵn sàng để sử dụng. Kiểm thử bao phủ các lĩnh vực khác nhau như: chức
năng của các ứng dụng, khả năng tương thích của các ứng dụng với các hệ điều
hành, phần cứng và các loại khác nhau của các trình duyệt, thực hiện kiểm thử để
kiểm tra hiệu năng của các ứng dụng để đảm bảo rằng hệ thống đáng tin cậy và
không có trục trặc hay không nên có bất kỳ vấn đề cản trở. Xác định rằng các ứng
dụng có thể được triển khai một cách dễ dàng với máy tính và không có bất kỳ sự

cố. Do đó các ứng dụng rất dễ dàng để cài đặt, tìm hiểu và sử dụng.
Kiểm thử phần mềm cho phép tạo ra những đánh giá khách quan về mức độ
phù hợp của hệ thống các yêu cầu đã nêu và thông số kỹ thuật.
Kiểm tra xác nhận rằng hệ thống đáp ứng các yêu cầu khác nhau bao gồm:
chức năng, hiệu suất, độ tin cậy, an toàn, khả năng sử dụng và như vậy. Việc xác
nhận này được thực hiện để đảm bảo rằng chúng ta đang xây dựng hệ thống phù
hợp.
Xác nhận để đảm bảo đang xây dựng hệ thống phù hợp. Ngoài việc giúp đưa
ra quyết định, các thông tin từ các kiểm thử phần mềm giúp quản lý rủi ro.
Cuối cùng của việc kiểm thử là hướng đến chất lượng của phần mềm. Một
dự án có chất lượng tốt khi đã đáp ứng được đầy đủ những yêu cầu của khách
hàng, ngoài những đặc điểm kỹ thuật được xây dựng chính xác, khách hàng còn
muốn dự án sẽ nằm trong ngân sách, thời gian hoàn thành đúng như yêu cầu.
1.4 Ai là người thực hiện Test (kiểm thử)
Ai là người thực hiện Test phần mềm? Điều này phụ thuộc vào quy trình của
các bên liên quan đến dự án. Trong ngành công nghiệp phần mềm, những công ty
lớn có một team chuyên chịu trách nhiệm về việc đánh giá phần mềm đã phát triển
với những yêu cầu được chỉ định từ trước – gọi là Tester
Trong hầu hết các trường hợp, người kiểm thử (Tester) có thể là:
- Software Tester – nhân viên kiểm thử phần mềm
- Software Developer – nhân viên phát triển phần mềm
- Leader hoặc manager của dự án
- Product Owner – người sở hữu sản phẩm
- User – người dùng cuối
14


1.5 Thực hiện kiểm thử khi nào? Khi nào thì việc kiểm thử phần mềm kết
thúc?
Tùy vào từng mô hình phát triển phần mềm mà thời gian thực hiện test là khác

nhau.
• Thực hiện kiểm thử khi:
- Kiểm thử thực hiện càng sớm càng tốt. Theo quy trình phát triển phần

mềm thì kiểm thử được thực hiện sau giai đoạn coding. Code xong thì
Dev sẽ build và bàn giao cho Tester thực hiện test.
- Thực tế thì tester tham gia sớm hơn, chỉ cần có tài liệu Đặc tả Yêu
cầu/Nghiêp vụ là tester thực hiện tìm hiểu nghiệp vụ dự án và thực hiện
viết testcase.
• Việc kiểm thử phần mềm kết thúc khi
- Dừng test có thể theo yêu cầu của người quán lý dự án dừng test vì lý
do nào đấy.
- Dừng test khi tất cả các chức năng đã được test xong. Đảm bảo tất cả
các chức năng đã chạy đúng theo Đặc tả phần mềm và toàn bộ lỗi đã
được sửa và test xong hết.
1.6 Các vai trò trong kiểm thử phần mềm
• Test Manager: Là người đứng đầu bộ phận kiểm thử, quản lý chung về các vấn đề
liên quan như quy trình làm việc, nhân sự.
• Test Leader: Là người trực tiếp tham gia vào quá trình kiểm thử dự án cùng với
Tester, Test Leader đảm nhiệm vai trò quản lý công việc của Tester, thực hiện
Verify các sản phẩm mà Tester tạo ra cũng như báo cáo của Test Menager khi có
yêu cầu.
• Tester: Là người trực tiếp thực hiện quá trình kiểm thử, đảm bảo chất lượng của
sản phẩm theo những nhiệm vụ được phân công.

15


2. Quy trình kiểm thử phần mềm

Hình 2: Quy trình kiểm thử phần mềm
Trong đó:
2.1 Lập kế hoạch kiểm thử (Test plan)
Kế hoạch kiểm thử là một tài liệu mô tả các mục tiêu, phạm vi, phương pháp
tiếp cận, và tập trung vào nỗ lực kiểm thử phần mềm.
-

Cấu trúc chung của một test plan:
+ Tên project (Tên dự án)
+ Danh sách các module cần test
+ Ngày bắt đầu, ngày kết thúc
+ Danh sách các test case
+ Nhân sự tham gia
+ Tài nguyên sử dụng (Servers, Workstations, Printers,…)
+ Kế hoạch thực hiện (sử dụng MS Project lập kế hoạch)…

16


2.2 Viết testcase
Test case: mô tả một dữ liệu đầu vào (input), hành động (action) và một kết
quả mong đợi (expected response), để xác định một chức năng của ứng dụng phần
mềm hoạt động đúng hay không.
 Một trường hợp kiểm thử có thể có các phần đặc thù khác nhau như mã

test case, tên test case, mục tiêu kiểm thử, các điều kiện kiểm thử, các
yêu cầu về dữ liệu đầu vào, các bước thực hiện và các kết quả mong
đợi.
 Gồm 3 bước cơ bản:
- Mô tả: Đặc tả các điều kiện cần cố để tiến hành kiểm tra.

- Nhập: Đặc tả đối tượng hoặc dữ liệu cần thiết, được sử dụng làm
đầu vào để thực hiện kiểm tra.
- Kết quả mong chờ: Kết quả trả về từ đối tượng kiểm tra.
 Quá trình phát triển test case có thể giúp tìm ra lỗi trong các yêu cầu
hoặc thiết kế của ứng dụng, vì nó đòi hỏi phải tư duy hoàn toàn thông
qua các hoạt động của ứng dụng.
2.3 Thực hiện test
- Thưc hiện test dựa trên testcase đã viết.
- Chạy lại các case bị lỗi trước đó để xác nhận là case đó đã được sửa.
- So sánh kết quả kết quả ghi nhận đc khi thực thi với kết quả mong đợi.
- Đánh giá kết quả kiểm thử cho các trường hợp kiểm thử.
- Viết báo cáo lỗi khi có bug.
2.4 Viết báo cáo kiểm thử (test report)
Báo cáo kiểm thử thể hiện tiến độ kiểm thử, tiến độ sửa lỗi và số lượng lỗi được
tìm thấy hay còn tồn của dự án. Nó là công cụ để phục vụ cho đánh giá hay giám
sát dự án có kịp tiến độ hay không, có thể bàn giao cho khách hàng hay không và
các vấn đề cần giải quyết khi mà số lượng lỗi còn nhiều, gây ra các rủi ro về tiến
độ hoàn thành của dự án để có những điều chỉnh kịp thời.

17


3. Các mức kiểm thử(Test level)
Quy trình kiểm thử phần mềm sẽ được thực hiện theo 4 giai đoạn như sau:

Hình 3: Các mức kiểm thử phần mềm
3.1 Kiểm thử đơn vị (Unit test):
Là việc kiểm thử các đơn vị chương trình một cách cô lập, và cần được kiểm
thử riêng biệt để phát hiện lỗi trong nội tại và khắc phục trước khi được tích hợp
với các đơn vị khác

+ Do lập trình viên đảm nhận.
+ Unit test được thực hiện càng sớm càng tốt trong giai đoạn viết code và
xuyên suốt chu kỳ phát triển phần mềm.
+ Mục đích: Bảo đảm thông tin được xử lý và xuất dữ liệu một cách chính
xác trong mối tương quan nhập dữ liệu và chức năng.
3.2 Kiểm thử tích hợp (Intergration testing):
Mức kế tiếp của kiểm thử đơn vị là kiểm thử tích hợp. Sau khi các đơn vị
chương trình để cấu thành hệ thống đã được kiểm thử, chúng cần được kết nối với
nhau để tạo thành hệ thống đầy đủ và có thể làm việc. Công việc này không hề đơn
giản và có thể có lỗi về giao diện giữa các đơn vị, và cần xác minh các thành phần

18


trong phần mềm có tương tác được với nhau hay , có hoạt động phối hợp cùng
nhau được hay không và cần phải kiểm thử để phát hiện những lỗi này.
+ Do kiểm thử viên thực hiện
+ Các nhóm kiểm thử lớn dần cho đến khi thành một hệ thống.
+ Mục đích: Tìm ra lỗi trong các giao diện và giao tiếp giữa các thành phần.
3.3 Kiểm thử hệ thống (System test):
kiểm thử mức này được áp dụng khi đã có một hệ thống đầy đủ sau khi tất cả
các thành phần đã được tích hợp. mục đích của việc kiểm thử hệ thống là để đảm
bảo rằng việc cài đặt tuân thủ đầy đủ các yêu cầu được đặc tả của người dùng. Là
mức kiểm thử nhằm đưa hệ thống vào vận hành thử nghiệm tại các môi trường
khác nhau nhằm tìm ra các lỗi về hệ thống, tính tương thích, kiểm thử cả hệ thống
về chức năng chính, sự liên kết giữa các modules với nhau, kiểm thử giao diện…
vvv.
+ Do kiểm thử viên thực hiện.
+ Mục đích: Chứng thực rằng hệ thống đã được tích hợp với các hệ thống bên
ngoài hoặc hệ thống thứ 3 đã được xác minh trog các yêu cầu của hệ thống.

3.4 Kiểm thử chấp nhận (Acceptance test):
Khi nhóm kiểm thử hệ thống đã thõa mãn với một sản phẩm, sản phẩm đó đã
sẵn sàng để đưa vào sử dụng. được thực thi bởi chính khách hàng nhằm đảm bảo
rằng sản phẩm phần mềm làm việc đúng như họ mong đợi. Có 2 loại kiểm thử
chấp nhận: Kiểm thử chấp nhận doanh nghiệp (Alpha testing) là một nhóm người
thực hiện test tại nơi sản xuất phần mềm. Alpha testing là một hình thức kiểm thử
chấp nhận nội bộ, được tiến hành bởi nhà sản xuất ra phần mềm, trước khi phần
mềm được tiến hành kiểm thử Beta. Kiểm thử chấp nhận người dùng (Beta test)
được thực hiện tại địa điểm của khách hàng/ người dùng thực hiện test hay sử dụng
phần mềm bên ngoài-không phải tại nơi sản xuất phần mềm.

19


4. Các phương pháp kiểm thử phần mềm
4.1 Phương pháp kiểm thử hộp đen
Khái niệm: Là phương pháp kiểm thử dựa trên đầu vào và đầu ra của chương
trình để kiểm thử, Chỉ kiểm thử chức năng và giao diện dựa trên nghiệp vụ của hệ
thống mà không quan tâm tới mã chương trình bên trong được viết ra sao. Tester
xem phần mềm như là một hộp đen. Kiểm thử hộp đen không yêu cầu kỹ sư kiểm
thử cần phải có bất kỳ kiến thức về mã hoặc thuật toán của chương trình. Nó kiểm
tra các chức năng của hệ thống tức là những gì hệ thống được cho là cần phải làm
dựa trên các đặc tả yêu cầu (Requirement document).

Hình 4: Black Box Testing
Ưu điểm:
-

Không có mối ràng buộc nào về code, và kiểm thử những thứ lập trình

viên có thể bỏ qua hoặc không nhìn thấy trong quá trình lập trình.
- Người kiểm thử thực hiện tử quan điểm của người dùng và sẽ giúp đỡ
trong việc sáng tỏ sự chênh lệch về thông số kĩ thuật.
- Người kiểm thử có thể không phải là một lập trình viện chuyên nghiệp,
không cần phải biết ngôn ngữ lập trình hoặc làm thế nào các phần mềm
đã được thực hiện.
- Người kiểm thử có thế thực hiện một cách độc lập từ các developer, cho
phép một cái nhìn khách quan và tránh sự phát triển thiên vị.
20


-

Thiết kế kịch barb kiểm thử khá nhanh, ngay khi mà các yêu cầu chức
năng được xác định.

Nhược điểm:
-

Dữ liệu đầu vào yêu cầu một khối lượng mẫu khá lớn.
Chỉ có thể khám phá mù (không biết phần mềm kiểm thử được xây dựng
như thế nào), do đó khi áp dụng phương pháp kiểm thử hộp đen đòi hỏi
người thực hiện phải làm việc vất vả hơn để khám phá được càng nhiều

bug càng tốt.
- Nhiều dự án không có thông số rõ ràng thì việc thiết kế test case rất khó
và do đó khó viết kịch bản kiểm thử do cần xác định tất cả các yếu tố
đầu vào, và thiếu cả thời gian cho việc tập hợp này.
-

Chỉ có một số nhỏ các đầu vào có thể được kiểm tra và nhiều đường dẫn
chương trình sẽ được để lại chưa được kiểm tra.

4.2 Phương pháp kiểm thử hộp trắng
Khái niệm: Là phương pháp kiểm thử dựa cả vào giải thuật, cấu trúc code
bên trong phần mềm, việc kiểm thử được tiến hành dựa cả vào việc kiểm xem giải
thuật, mã lệnh đã làm có đúng không.
Trong kiểm thử hộp trắng, cấu trúc mã hoặc giải thuật của chương trình được
đưa vào xem xét, các trường hợp kiểm thử được thiết kế dựa vào cấu trúc mã hoặc
cách thức làm việc của chương trình. Người kiểm thử truy cập vào mã chương
trình và có thể kiểm tra nó, lấy đó làm cơ sở để hổ trợ việc kiểm thử.
Để thực hiện được phương pháp kiểm thử hộp trắng thì người kiểm thử phải
có kỹ năng , kiến thức nhất định về ngôn ngữ lập trình được dùng, về thuật giải
được dùng trong thành phần phần mềm để có thể thông hiểu được chi tiết về các
đoạn code cần khiểm thử.
21


Hình 5: White Box Testing
Ưu điểm:
- Test có thể bắt đầu ở giai đoạn sớm hơn, không cần phải chờ đợi cho
-

GUI để có thể test.
Test kỹ càng hơn, có thể bao phủ hầu hết các trường hợp.
Thích hợp trong việc tìm kiếm lỗi và các vẫn đề trong mã lệnh.
Cho phép tìm kiếm các lỗi ẩn bên trong.
Các lập trình viên có thể tự kiểm tra.
Giúp tối ưu việc mã hóa.
Do yêu cầu kiến thức cấu trúc bên trong của phần mềm nên việc kiểm

soát lỗi tối đa nhất.

Nhược điểm:
-

Đòi hỏi các lập trình viên phải có tay nghê cao, kiến thức sâu rộng.
Rất khó để duy trì kiểm thử hộp trắng, vì nó đòi hỏi các công cụ chuyên biệt

như phân tích source code và công cụ sửa lỗi.
- Đôi khi không thể khả thi khi kiểm tra chi tiết từng dòng source code để tìm
ra các lỗi tiềm ẩn có thể gây ra vấn đề cho hệ thống, vì nhiều luồng sẽ không
được kiểm tra.
4.3 Phương pháp kiểm thử hộp xám (Gray Box Testing)
Khái niệm: Là một phương pháp kiểm thử phần mềm được kết hợp giữa
phương pháp kiểm thử hộp trắng và phương pháp kiểm thử hộp đen.
Trong kiểm thử hộp xám, cấu trúc bên trong sản phẩm chỉ được biết một phần,
Tester có thể truy cập vào cấu trúc dữ liệu bên trong và thuật toán của chương trình

22


với mục đích là để thiết kế testcase, nhưng khi test thì test như là người dùng cuối
hoặc là ở mức hộp đen.
Được gọi là kiểm thử hộp xám vì trong chương trình phần mềm, mắt của
Tester giống như hộp xám/bán trong suốt-nhìn qua hộp này ta chỉ có thể thấy được
một phần.
Ví dụ: Khi code của 1 module nào đó được xem xét để thiết kế testcase
(phương pháp kiểm thử hộp trắng) và khi test thực tế thì được thực hiện test trên
giao diện người dùng (phương pháp kiểm thử hộp đen).
5. Kiểm thử động và Kiểm thử tĩnh

5.1 Kiểm thử tĩnh (Static Testing)
Static testing chính là kiểm thử hộp trắng được thực hiện ở giai đoạn đầu
của Chu kỳ phát triển. Nó được thực hiện trước khi triển khai code. Thường có hai
phần:
Review: thường được sử dụng để tìm và loại bỏ lỗi hoặc sự mơ hồ trong tài
liệu như yêu cầu, thiết kế, trường hợp kiểm tra…
Static analysis: code được viết bởi các Dev được phân tích để tìm ra những
lỗi thường mắc phải.

-

Các phương pháp Static testing bao gồm Ispection, Wailthroughs, Technical
reviews và Informal reviws:
-

-

-

Inspection: mục đích chính là tìm ra các khiếm quyết. Việc kiểm tra được
thực hiện bởi người phê duyệt. Đây là loại đánh giá thông thường có một
danh sách kiểm tra được chuẩn bị để kiểm tra xem tài liệu công việc hoàn
thành tới đâu.
Walk-through: trong loại kỹ thuật này, Leader mở một cuộc họp để giải thích
sản phẩm. những người tham gia có thể đặt ra những câu hỏi nếu chưa hiểu
và ghi chú lại, phục vụ cho việc hoàn thành công việc.
Technical review: trong loại kiểm tra này, kiểm tra về kỹ thuật sẽ được kiểm
tra 1 vòng. Việc này tiến hành để kiểm tra xem code được thực hiện theo
23

-

đúng các thông số kỹ thuật và tiêu chuẩn hay không. Nói chung các kế hoạch
kiểm tra, chiến lược kiểm thử và các tập lệnh kiểm tra được xem xét kỹ ở
đây.
Informal review: kỹ thuật kiểm tra tĩnh trong đó tài liệu được xem xét, nhận
xét một cách không chính thức và đưa ra các ý kiến không chính thức.

Hình 6: Các kỹ thuật kiểm thử tĩnh
5.2 Kiểm thử động (Dynamic Testing)
Kiểm thử động được thực hiện khi code đang ở chế độ thực thi. Kiểm thử
động được thực hiện trong môi trường thực thi chạy chương trình ứng dụng. Khi
code được thực thi, thì đầu vào được truyền một giá trị, kết quả hoặc đầu ra của
việc thực hiện được so sánh với kết quả dự kiến ban đầu đã đưa ra. Với việc này
chúng ta có thể quan sát được các hành vi chức năng của phần mềm, giám sát hệ
thống bộ nhớ, thời gian phản hồi của CPU, hiệu suất của hệ thống. Thử nghiệm
dynamic còn được gọi là thử nghiệm xác nhận (Validation testing), đánh giá sản
phẩm. Thử nghiệm động gồm hai loại: Kiểm tra chức năng và Kiểm tra phi chức
năng.

24


Hình 6: các kỹ thuật kiểm thử động
6. Các kỹ thuật kiểm thử
Có nhiều kỹ thuật kiểm thử phần mềm, sau đây là 4 kỹ thuật phổ biến nhất
trong kỹ thuật kiểm thử hộp đen là: kỹ thuật phân vùng tương đương, kỹ thuật
phân tích giá trị biên, bảng quyết định và kỹ thuật đoán lỗi.
Trong quá trình kiểm thử, kiểm thử viên có thể áp dụng nhiều kỹ thuật khác

nhau, kết hợp các phương pháp kiểm thử với nhau để có thể tìm các lỗi của phần
mềm một cách tối đa.
6.1 Kỹ thuật phân vùng tương đương
Đây là phương pháp chia đầu vào thành những nhóm tương đương nhau.
Nếu một giá trị trong nhóm hoạt động đúng thì tất cả các giá trị trong nhóm đó
cũng hoạt động đúng và ngược lại.
-

-

Mục đích: Giảm đáng kể số lượng test case cần phải thiết kế vì với mỗi lớp tương
đương ta chỉ cần test trên các phần tử đại diện.
Thiết kế test case bằng phân lớp tương đương tiến hành theo 2 bước:
+ Xác định các lớp tương đương.
+ Xác định các trường hợp kiểm thử.
Nguyên tắc:
+ Một lớp các giá trị lớn hơn
+ Một lớp các giá trị nhỏ hơn
+ Nhiều lớp các giá trị hợp lệ
Ví dụ: From Login bao gồm User:Text Box, Passwword: TextBox
25