TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP HÀ NỘI

BÁO CÁO THÍ NGHIỆM HỌC PHẦN
THỰC TẬP CƠ SỞ NGÀNH KỸ THUẬT PHẦN MỀM
CHỦ ĐỀ:

NGHIÊN CỨU VỀ KIỂM THỬ PHẦN MỀM TẠI
CÔNG TY FSOFT
GVHD:Th.S Vũ Thị Dương
Nhóm 3:
1.
2.
3.
4.
5.

Đoàn Hải Quân
Đinh Phương Nam
Nguyễn Hải Nam
Mạch Văn Quân
Trần Minh Quang

6.

1


Phần 1: Phần mở đầu

I.

Lời nói đầu
Ngày nay cơng nghệ thơng tin đang ngày càng phát triển nhanh chóng, kéo theo đó là hệ

thống mạng và các phần mềm cũng gia tăng cả về số lượng theo quy mô rộng và cả về chất
lượng phần mềm theo chiều sâu. Nhưng cũng từ đó đã nảy sinh ra nhiều vấn đề về lỗi hỏng hóc
phần mềm khơng đáng có gây ra các ảnh hưởng nghiêm trọng đến xã hội, kinh tế,...Những lỗi
này có thể do tự bản thân phần mềm bị hỏng do không được kiểm duyệt kĩ lưỡng trước khi đưa
cho người dùng cuối hay cũng có thể do có người cố tình phá hoại nhằm đánh cắp thơng tin cá
nhân như mã số tài khoản ngân hàng, số điện thoại, danh bạ, tin nhắn,...Những vấn đề nan giải và
cấp thiết này càng có xu hướng mở rộng trong các năm gần đây, điển hình như sự cố máy tính
Y2K năm 2000 làm tê liệt nhiều hệ thống máy tính lớn hay như càng có nhiều loại virus phá hoại
mới xuất hiện, tấn công vào các lỗ hổng bảo mật phần mềm làm tê liệt nhiều hệ thống phần mềm
và phần cứng. Nhận thấy “ Kiểm thử phần mềm trong sản xuất phần mềm” là 1 quy trình quan
trọng nên chúng em đã chọn đề tài này để tìm hiểu.
Để có thể hồn thành tốt đề tài chúng em xin gửi lời cảm ơn chân thành đến cô Ths.Vũ
Thị Dương – giảng viên bộ môn Thực tập cơ sở ngành , Khoa Công nghệ thông tin ,trường Đại
Học Công Nghiệp Hà Nội, đã định hướng, hướng dẫn và chỉ bảo tận tình trong quá trình chúng
em làm báo cáo thực tập này . Em xin chúc cơ và gia đình luôn luôn mạnh khỏe và hạnh phúc.
Tuy nhiên, do thời gian và trình độ có hạn nên báo cáo khơng thể tránh khỏi những thiếu sót.
Chính vì vậy, em rất mong có được sự góp ý từ các cơ giáo và toàn thể các bạn.

2


II.

Mô tả chủ đề nghiên cứu
a. Quá trình nghiên cứu chia làm 2 giai đoạn :




Giai đoạn 1 : Tự nghiên cứu tổng quan về kiểm thử phần mềm
Giai đoạn 2 : Tìm hiểu kiểm thử phần mềm tại cơng ty FSOFT

b. Lý do nghiên cứu :
Nhận thấy kiểm thử phần mềm là một ngành quan trọng trong sản xuất phần
mềm.Hiện nay trên thị trường có rất nhiều phần mềm chưa hoàn toàn đạt tiêu
chuẩn nhưng vẫn xuất hiện tràn lan trên thị trường. Từ đây ta dễ dàng nhận ra là
mặc dù phần mềm phát triển ngày càng phức tạp nhưng vấn đề chất lượng vẫn là
một dấu hỏi lớn cần xem xét cẩn thận.
Do đó yêu cầu đặt ra là cần có cơng tác kiểm thử phần mềm thật kĩ lưỡng
nhằm ngăn chặn các lỗi hay hỏng hóc còn tiềm tàng bên trong phần mềm mà ta
chưa kịp nhận ra. Tuy nhiên vì phần mềm ngày càng lớn, hàng nghìn module, có
thể do cả một cơng ty hàng nghìn người phát triển vì vậy để kiểm thử được một
phần mềm lớn như vậy sẽ tốn rất nhiều công sức và thời gian nếu làm thủ công,
chưa kể đến chất lượng kiểm thử sẽ khơng cao va thật chính xác phù hợp cho u
cầu. Theo nhiều tính tốn thì cơng việc kiểm thử đóng vai trị hết sức quan trọng
trong quy trình phát triển phần mềm, nó đóng góp tới 40% tổng tồn bộ chi phí cho
việc sản xuất phần mềm. Vì vậy cần có các hệ thống kiểm thử phần mềm một cách
tự động cho phép ta thực hiện được các cơng việc một cách nhanh chóng và độ an
tồn, chính xác cao nhất có thể. Và đó chính là lí do em lựa chọn đề tài này để
nghiên cứu, tìm hiểu và đề ra các giải pháp mới để cải tiến các quy trình kiểm thử
như hiện nay sao cho có năng suất cao nhất.

c. Mục tiêu cần đạt được .
•
•

Hiểu được tổng quan về kiểm thử phần mềm và tầm quan trọng của nó
trong sản xuất phần mềm .

Vượt lên bản thân tìm hiểu quá trình kiểm thử tại cơng ty FSOFT.
+ Quy trình,mơ hình cấp độ kế hoạch của kiểm thử.
+ Quá trình thực hiện.
+ Yêu cầu khách hàng.
3


Xin tài liệu kiểm thử của công ty để tham khảo .
Khó khăn thách thức của ngành kiểm thử phần mềm .
+

•

Phần 2: Nghiên cứu về quy trình kiểm thử phần mềm Software testing life cycle( STLC) công ty Fsoft

I. Giai đoạn I : ( Tự nghiên cứu) Tổng quan về kiểm thử
1.

phần mềm
Khái niệm
Kiểm thử phần mềm là hoạt động khảo sát thực tiễn sản phẩm hay dịch vụ

phần mềm trong đúng môi trường chúng dự định sẽ được triển khai nhằm cung cấp
cho những người có lợi ích liên quan những thông tin về chất lượng của sản phẩm
hay dịch vụ phần mềm ấy. Mục đích của kiểm thử phần mềm là tìm ra các lỗi hay
khiếm khuyết phần mềm nhằm đảm bảo hiệu quả hoạt động tối ưu của phần mềm
trong nhiều ngành khác nhau. (Wikipedia).
Software testing là một trong những kĩ thuật phần mềm “ xác minh và xác
nhận “ (verification and validation hay gọi tắt là V&V).
Ví dụ :

Trong phần mềm chơi game Monopoly, chúng ta có thể xác minh rằng hai
người choi khơng thể sở hữu cùng một nhà. Validationis quá trình đánh giá một hệ
thống hoặc một thành phần trong hoặc ở cuối của q trình phát triển để xác định
xem nó đáp ứng yêu cầu quy định

2.

Vai trò của kiểm thử phần mềm

Việc tạo ra một sản phẩm phần mềm phải trải qua nhiều giai đoạn ,người ta
gọi là qui trình phát triển phần mềm, bắt đầu từ khi có ý tưởng cho đến đưa ra sản
phẩm có rất nhiều giai đoạn thay đổi theo thời gian.


Ví dụ :

4


Hình 1.1
Một sản phẩm phần mềm không chỉ đơn giản là các đoạn mã chương trình
mà cịn rất nhiều phần ẩn đằng sau nó ( Hình 1.1). Vì vậy, việc mắc lỗi khơng chỉ
xảy ra trong khi lập trình mà cịn xảy ra cao hơn trong các cơng đoạn khác của qui
trình phát triển một sản phẩm phần mềm.
Quy trình kiểm thử có liên kết chặt chẽ với q trình xây dựng một phần mềm .
•

Cải thiện phần mềm của bạn

Vai trò của kiểm thử trong phát triển phần mềm bắt đầu với việc cải thiện độ

tin cậy, chất lượng và hiệu suất của phần mềm. Nó hỗ trợ nhà phát triển kiểm tra
xem phần mềm có đang hoạt động đúng cách hay không và đảm bảo rằng phần
mềm đang khơng thực hiện những gì nó khơng được phép làm.
•

Đảm bảo chất lượng

Chất lượng đóng một vai trị quan trọng trong thế giới cạnh tranh ngày nay.
Kiểm tra sẽ là cần thiết để làm cho phần mềm khơng có lỗi. Những khiếm khuyết có
thể được xác định và sửa chữa.
•

Giúp tránh các tình huống nguy hiểm

Kiểm thử phần mềm tốt và hiệu quả sẽ giúp cải thiện tính bảo mật. Xác thực
và xác nhận là mục đích chính của các dịch vụ kiểm thử phần mềm. Về cơ bản,
kiểm thử phần mềm không chỉ giúp phát hiện ra các khiếm khuyết trong phần mềm
mà cịn cả cấu hình của nó. Thơng qua thử nghiệm, các nhà phát triển có thể xác
định độ tin cậy của phần mềm.

5


Những kỹ thuật , loại hình và các cấp độ của phương pháp
kiểm thử
3.2. Mức độ kiểm tra phần mềm
3.

3.1.1. Unit


Testing ( Kiểm thử đơn vị)

Dùng để test 1 đoạn code, thường được làm bởi developer. Các ứng dụng
phần mềm bao gồm các khối mã khác nhau (mơ-đun, quy trình, thủ tục, chức năng,
lệnh gọi, v.v.) mỗi khối được gọi là một đơn vị. Đây là cấp độ thử nghiệm đầu tiên
và thường được thực hiện bởi các nhà phát triển. Mỗi đơn vị này thực hiện một
chức năng hoặc nhiệm vụ riêng và cụ thể. Kiểm thử đơn vị là kiểm tra từng đơn vị
một cách độc lập để đảm bảo rằng nó thực hiện nhiệm vụ hoặc chức năng đã định.
Kiểm thử đơn vị có hai loại : Kiểm thử thủ công và kiểm thử tự động.
Kiểm thử đơn vị thường được tự động hóa nhưng vẫn có thể được thực hiện
theo cách thủ công. Kỹ thuật phần mềm không ưu tiên cái này hơn cái kia nhưng tự
động hóa được ưu tiên hơn. Cách tiếp cận thủ cơng để kiểm tra đơn vị có thể sử
dụng tài liệu hướng dẫn từng bước.
Ví dụ :
Điện thoại di động có một số ứng dụng hệ thống và người dùng
(chẳng hạn như quay số điện thoại, trình quản lý tệp, tin nhắn, máy ảnh, sao lưu và
khôi phục, danh bạ, tải xuống, trình quản lý lưu trữ, facelock, vân tay, v.v.... Mỗi
ứng dụng này là một đơn vị và có thể tự kiểm tra độc lập với nhau.
Ưu điểm : Kiểm thử đơn vị cho phép lập trình viên cấu trúc lại mã vào một ngày
sau đó và đảm bảo rằng mơ-đun vẫn hoạt động chính xác (tức là Kiểm tra hồi
6


quy). Thủ tục là viết các trường hợp kiểm thử cho tất cả các chức năng và phương
pháp để bất cứ khi nào thay đổi gây ra lỗi, nó có thể được xác định và sửa chữa
nhanh chóng. Do tính chất mơ-đun của kiểm thử đơn vị, chúng tơi có thể kiểm tra
các phần của dự án mà không cần đợi những người khác hoàn thành.
Nhược điểm :
Kiểm thử đơn vị không thể được mong đợi để bắt mọi lỗi trong
một chương trình. Khơng thể đánh giá tất cả các đường dẫn thực thi ngay cả trong

các chương trình tầm thường nhất. Bản chất của kiểm thử đơn vị tập trung vào một
đơn vị mã. Do đó, nó khơng thể bắt lỗi tích hợp hoặc lỗi cấp hệ thống rộng.

3.1.2.

Integration Testing (Kiểm thử tích hợp)

Kiểm thử tích hợp, bao gồm nhiều Module, test những chức năng, class khác
nhau có liên quan đến nhau.
Các phương pháp chiến lược :
+ Cách tiếp cận Big Bang:
+ Phương pháp tiếp cận gia tăng: được chia thành nhiều cách sau
-

Phương pháp tiếp cận từ trên xuống

-

Phương pháp tiếp cận từ dưới lên

-

Phương pháp tiếp cận Sandwich - Kết hợp Từ trên xuống và
Từ dưới lên

Ví Dụ : Kiểm thử tích hợp từ dưới lên :

7



Trong ví dụ về điện thoại di động của chúng tơi ở trên, ứng dụng máy ảnh
tích hợp với trình quản lý bộ nhớ. Điều này là do khi máy ảnh được sử dụng (để
chụp ảnh hoặc quay video), đầu ra phải được lưu trữ trên phương tiện lưu trữ (có
thể là bộ nhớ trong hoặc bộ nhớ ngồi). Kiểm tra tích hợp đảm bảo rằng điều này
xảy ra.
Ví dụ : Đơn vị camera tích hợp thành cơng với trình quản lý lưu trữ.

3.1.3.

System Testing (Kiểm thử cả hệ thống )

Kiểm tra hệ thống là sự kết hợp của nhiều đơn vị khác nhau được tích hợp
với nhau để thực hiện một chức năng hoặc nhiệm vụ. Kiểm tra hệ thống đảm bảo
rằng tất cả các đơn vị được tích hợp hoàn toàn và hoạt động như một, đáp ứng các
yêu cầu thiết kế.
Có hơn 50 loại kiểm thử hệ thống với 1 số loại thông dụng trong các công ty
lớn là :
1.

Kiểm tra khả năng sử dụng chủ yếu tập trung vào việc người dùng
dễ dàng sử dụng ứng dụng, tính linh hoạt trong việc xử lý các điều
khiển và khả năng của hệ thống để đáp ứng các mục tiêu của nó.

2.

Kiểm tra tải cần thiết để biết rằng một giải pháp phần mềm sẽ hoạt
động dưới tải trong đời thực.

3.


Kiểm tra hồi quy liên quan đến việc kiểm tra được thực hiện để đảm
bảo khơng có thay đổi nào được thực hiện trong suốt quá trình phát
triển gây ra lỗi mới. Nó cũng đảm bảo khơng có lỗi cũ xuất hiện từ
việc bổ sung các mô-đun phần mềm mới theo thời gian.

4.

Kiểm tra khôi phục được thực hiện để chứng minh một giải pháp
phần mềm là đáng tin cậy, đáng tin cậy và có thể khơi phục thành cơng
từ các sự cố có thể xảy ra.

5.

Kiểm thử di chuyển được thực hiện để đảm bảo rằng phần mềm có
thể được di chuyển từ cơ sở hạ tầng hệ thống cũ hơn sang cơ sở hạ
tầng hệ thống hiện tại mà không gặp bất kỳ sự cố nào.

6.

Kiểm tra chức năng cịn được gọi là kiểm tra tính hoàn chỉnh của
chức năng, Kiểm tra chức năng liên quan đến việc cố gắng nghĩ về bất
kỳ chức năng nào có thể bị thiếu. Người kiểm tra có thể lập danh sách
các chức năng bổ sung mà một sản phẩm có thể phải cải thiện trong
q trình kiểm tra chức năng.
8


7.

Kiểm thử Phần cứng / Phần mềm - IBM gọi kiểm thử Phần cứng /

Phần mềm là "Kiểm tra HW / SW". Đây là lúc người kiểm tra tập trung
sự chú ý của mình vào các tương tác giữa phần cứng và phần mềm
trong q trình kiểm tra hệ thống.

Ví dụ :Sau khi một chiếc điện thoại hồn chỉnh, nó sẽ được kiểm tra tổng thể để
xem nó hoạt động tốt như thế nào với những bộ phận riêng lẻ.

3.1.4.

Functional testing ( Kiểm thử chức năng)

Ở cấp độ phát triển phần mềm này, nó được kiểm tra để chấp nhận cả nội bộ
(bởi những người không trực tiếp tham gia thiết kế và phát triển nó (thử nghiệm
Alpha) và cả bên ngồi bởi một nhóm người dùng cuối được chọn (thử nghiệm
Beta).Đây là giai đoạn cuối cùng của thử nghiệm chức năng và được sử dụng để
kiểm tra xem phần mềm đã sẵn sàng để sử dụng hay chưa. Sản phẩm phải được
kiểm tra để tuân thủ các tiêu chí kinh doanh và nếu nó đáp ứng nhu cầu của người
dùng cuối.
Các bước thực hiện :
•

Hiểu các yêu cầu chức năng

•

Xác định đầu vào kiểm tra hoặc dữ liệu kiểm tra dựa trên các u
cầu

•


Tính tốn kết quả mong đợi với các giá trị đầu vào thử nghiệm đã
chọn

•

Thực thi các trường hợp thử nghiệm

•

So sánh kết quả dự kiến thực tế và tính tốn

9


3.2.

Các loại kiểm thử phần mềm
3.2.1. Usability

testing

Người dùng là yếu tố quan trọng nhất trong sự phát triển của bất kỳ phần
mềm nào. Bài kiểm tra này kiểm tra các yếu tố con người và giao diện người dùng
đồng ý với người dùng cuối như thế nào. Có vẻ như đây là các quy trình và các
bước cần thiết để thực hiện các nhiệm vụ và phân tích mức độ hiệu quả, trực quan
và dễ dàng của các bước đó.
Quy trình kiểm tra khả năng sử dụng bao gồm các giai đoạn sau :

1. Lập kế hoạch : Trong giai đoạn này, các mục tiêu của kiểm tra khả năng sử


dụng được xác định
2. Tuyển dụng : Trong giai đoạn này, bạn tuyển dụng số lượng người thử

nghiệm mong muốn theo kế hoạch kiểm tra khả năng sử dụng của bạn.
3. Kiểm tra khả năng sử dụng : Trong giai đoạn này, kiểm tra khả năng sử

dụng thực sự được thực hiện.

10


4. Phân tích dữ liệu : Dữ liệu từ các bài kiểm tra khả năng sử dụng được phân

tích kỹ lưỡng để đưa ra các suy luận có ý nghĩa và đưa ra các đề xuất hữu
ích để cải thiện khả năng sử dụng tổng thể của sản phẩm của bạn.
5. Báo cáo : Kết quả của bài kiểm tra khả năng sử dụng được chia sẻ với tất cả

các bên liên quan có liên quan có thể bao gồm nhà thiết kế, nhà phát triển,
khách hàng và Giám đốc điều hành
Có hai phương pháp có sẵn để thực hiện kiểm tra khả năng sử dụng :
+

Kiểm tra khả năng sử dụng trong phòng thí nghiệm : Thử nghiệm này
được thực hiện trong một phịng thí nghiệm riêng biệt với sự chứng kiến của
các quan sát viên. Người kiểm tra được giao nhiệm vụ để thực hiện

+

Kiểm tra khả năng sử dụng từ xa : Theo thử nghiệm này, người quan sát
và người kiểm tra được định vị từ xa. Người kiểm tra truy cập Hệ thống

đang Kiểm tra, từ xa và thực hiện các nhiệm vụ được giao.

Ví dụ: Giả sử người dùng sử dụng camera phone và mỗi lần hệ thống hỏi nơi lưu
tệp (bộ nhớ trong hoặc bộ nhớ ngồi). Điều này có thể được coi là khơng hiệu
quả. Thay vào đó, người dùng có thể đặt vị trí lưu trữ mặc định và khơng phải chỉ
ra như vậy mỗi khi sử dụng máy ảnh.

3.2.2. Smoke/sanity

Phương thức thử nghiệm này được đặt tên là lần đầu tiên bật một thiết bị
điện mới được thiết kế trong nhà máy thiết kế và hy vọng nó khơng bốc
khói. Kiểm tra khói sẽ kiểm tra nhẹ hầu hết các thành phần chính, đặc biệt chú ý
đến việc tích hợp thích hợp. Nếu thử nghiệm này được thông qua, sản phẩm sẽ tiếp
tục thử nghiệm thêm.
Kiểm tra khói thường được thực hiện thủ cơng mặc dù có khả năng hồn thành
tương tự thơng qua tự động hóa. Nó có thể khác nhau giữa các tổ chức.
Chu kì kiểm thử khói : Lưu đồ bên dưới cho thấy cách Kiểm tra khói được thực
hiện. Sau khi bản dựng được triển khai trong QA và kiểm tra khói được vượt qua,
chúng tơi sẽ tiến hành kiểm tra chức năng. Nếu thử nghiệm khói khơng thành cơng,
chúng tơi thốt thử nghiệm cho đến khi sự cố trong bản dựng được khắc phục.

11


3.2.3. Security

testing

Mọi phần mềm đều phải chịu trách nhiệm trước các cuộc tấn công nguy
hiểm và những kẻ xâm nhập. Kiểm tra bảo mật tìm kiếm các sơ hở, khiếm khuyết

và lỗ hổng trong hệ thống có thể khiến phần mềm gặp phải các mối đe dọa như
vậy.
Có bảy loại kiểm tra bảo mật chính theo sổ tay phương pháp Kiểm tra bảo mật
nguồn mở :

•

Quét lỗ hổng bảo mật : Điều này
được thực hiện thông qua phần mềm
tự động để quét hệ thống chống lại
các dấu hiệu lỗ hổng đã biết.

•

Qt bảo mật: Nó liên quan đến việc
xác định các điểm yếu của mạng và
hệ thống, sau đó cung cấp các giải
pháp để giảm những rủi ro này. Quá
trình quét này có thể được thực hiện
cho cả quét Thủ cơng và Tự động.

•

Kiểm tra thâm nhập : Loại kiểm tra
này mô phỏng một cuộc tấn công từ một hacker độc hại. Thử nghiệm này
12


liên quan đến việc phân tích một hệ thống cụ thể để kiểm tra các lỗ hổng
tiềm ẩn đối với một nỗ lực tấn cơng bên ngồi.

•

Đánh giá rủi ro: Thử nghiệm này liên quan đến việc phân tích các rủi ro an
ninh được quan sát thấy trong tổ chức. Rủi ro được phân loại là Thấp, Trung
bình và Cao. Thử nghiệm này đề xuất các biện pháp kiểm soát và giảm thiểu
rủi ro.

•

Kiểm tra bảo mật: Đây là hoạt động kiểm tra nội bộ của các Ứng dụng và Hệ
điều hành để tìm các lỗi bảo mật. Việc kiểm tra cũng có thể được thực hiện
thơng qua việc kiểm tra từng dịng mã

•

Hack theo đạo đức: Đó là hack hệ thống Phần mềm của Tổ chức. Không
giống như các tin tặc độc hại, những kẻ ăn cắp vì lợi ích của riêng mình,
mục đích là để lộ các lỗ hổng bảo mật trong hệ thống.

•

Đánh giá tư thế: Điều này kết hợp quét bảo mật, lấy cắp đạo đức và đánh giá
rủi ro để hiển thị tư thế bảo mật tổng thể của một tổ chức.

3.2.4. User

Acceptance Testing

User Acceptance Testing là quá trình xác nhận rằng phần mềm đã tạo ra có
hoạt động phù hợp với người dùng cuối hay khơng.

Ví dụ: Facebook ra mắt một tính năng mới, cho phép người dùng Facebook gửi
bưu thiếp cho gia đình và bạn bè. Về mặt, kỹ thuật giải pháp làm việc. Tester có thể
sử dụng nó, tuy nhiên do thiếu sự quan tâm và nhu cầu sẽ không ai muốn gửi bưu
thiếp in. Kiểm tra chức năng sẽ diễn ra tốt, kiểm tra khả năng sử dụng cũng sẽ tốt,
nhưng kiểm tra chấp nhận người dùng có thể sẽ thất bại vì người dùng Facebook
khơng có nhu cầu gửi bưu thiếp trong Facebook
3.2.5. Localization

Testing

Kiểm thử bản địa hóa là một kỹ thuật kiểm thử phần mềm, trong đó hành vi
của một phần mềm được kiểm tra cho một khu vực, ngơn ngữ hoặc văn hóa cụ
thể. Mục đích của việc kiểm tra bản địa hóa cho một phần mềm là để kiểm tra các
khía cạnh ngơn ngữ và văn hóa thích hợp cho một ngơn ngữ cụ thể. Đây là q
trình tùy chỉnh phần mềm theo ngơn ngữ và quốc gia được nhắm mục tiêu.
3.2.6. Globalization

Testing

13


Kiểm thử tồn cầu hóa là một phương pháp kiểm thử phần mềm được sử dụng để
đảm bảo rằng ứng dụng phần mềm có thể hoạt động trong bất kỳ nền văn hóa hoặc
địa phương nào (ngơn ngữ, lãnh thổ hoặc trang mã) bằng cách kiểm tra các chức
năng của phần mềm bằng cách sử dụng từng loại đầu vào quốc tế có thể. Mục đích
của kiểm thử Tồn cầu hóa là để đảm bảo rằng phần mềm có thể được sử dụng trên
tồn thế giới hoặc quốc tế. Nó còn được gọi là Kiểm thử quốc tế.

3.2.7. Non-functional







testing: Kiểm thử phi chức năng

Performance : Điều này kiểm tra hiệu suất, khả năng đáp ứng và độ
ổn định của phần mềm khi chịu một tải nhất định.
Endurance
Loading testing
Volume
Scalability

3.2.8. Maintenance (Bảo
• Regression ( Lặp
•
3.3.

trì)
đi lặp lại)

Maintenance

Phương pháp kiểm thử
3.3.1. Thử

nghiệm đặc biệt ( Thử nghiệm khỉ thử nghiệm ngẫu


nhiên)
Một thử nghiệm được thực hiện mà khơng có tài liệu hoặc kế hoạch được
cung cấp. Nó thường được thực hiện một cách ngẫu nhiên mà khơng có bất kỳ quy
trình hoặc ý định nào được xác định trước.Mục đích là để xác định các lỗi và phá
14


vỡ ứng dụng bằng cách thực thi luồng hoặc một chức năng ngẫu nhiên.Mặc dù việc
xác định các khiếm khuyết mà khơng có trường hợp thử nghiệm là một thách thức
bình thường, nhưng có thể các khiếm khuyết được tìm thấy bằng thử nghiệm đặc
biệt có thể khơng được phát hiện với các trường hợp thử nghiệm hiện có.
Các bước kiểm tra ngẫu nhiên:
Đầu vào Ngẫu nhiên được xác định để đánh giá dựa trên hệ thống.
Đầu vào thử nghiệm được chọn độc lập với miền thử nghiệm.
Kiểm tra được thực hiện bằng cách sử dụng các đầu vào ngẫu nhiên đó.
Ghi lại kết quả và so sánh với kết quả mong đợi.
Tái tạo / Nhân bản vấn đề và nêu ra các khiếm khuyết, sửa chữa và kiểm tra lại.

3.3.2. Thử

nghiệm Agile

Một thử nghiệm đảm bảo rằng các lý tưởng của phát triển phần mềm linh
hoạt được tuân thủ theo Tuyên ngôn của họ.
Các kế hoạch thử nghiệm điển hình trong Agile bao gồm:
1.

Phạm vi thử nghiệm

2.


Các chức năng mới đang được thử nghiệm

3.

Mức độ hoặc Các loại thử nghiệm dựa trên độ phức tạp của các tính năng

4.

Kiểm tra tải và hiệu suất

5.

Xem xét cơ sở hạ tầng

6.

Kế hoạch giảm thiểu hoặc rủi ro

7.

Nguồn cung ứng

8.

Các sản phẩm được giao và các cột mốc quan trọng

3.3.3. Thử

nghiệm hộp đen


Dùng để kiểm tra chức năng mà không xem xét mã nguồn cũng như cấu
chúc chương trình bên trong. Thường kiểm thử hộp đen quan tâm nhiều đến các bộ
15


dữ liệu kiểm thử đầu vào. Người kiểm thử hoàn tồn khơng quan tâm đến cấu trúc
và hành vi bên trong của chương trình. Người kiểm thử chỉ cần quan tâm đến
việc tìm các hiện tượng mà phần mềm khơng hành xử theo đúng đặc tả của nó. Do
đó, dữ liệu kiểm thử sẽ xuất phát từ đặc tả.
Dưới đây là các bước chung sau để thực hiện bất kỳ loại Kiểm tra Hộp đen nào.
1. Ban đầu, các yêu cầu và thông số kỹ thuật của hệ thống được kiểm tra.
2. Tester chọn các đầu vào hợp lệ (kịch bản kiểm tra tích cực) để kiểm tra xem
SUT có xử lý chúng một cách chính xác hay khơng. Ngồi ra, một số đầu
vào không hợp lệ (kịch bản kiểm tra âm tính) được chọn để xác minh rằng
SUT có thể phát hiện ra chúng.
3. Tester xác định đầu ra mong đợi cho tất cả các đầu vào đó.
4. Người kiểm thử phần mềm xây dựng các trường hợp kiểm thử với các đầu
vào đã chọn.
5. Các trường hợp thử nghiệm được thực thi.
6. Người kiểm tra phần mềm so sánh kết quả đầu ra thực tế với kết quả đầu ra
dự kiến.
7. Các khiếm khuyết nếu có sẽ được sửa và kiểm tra lại.

3.3.4. Thử

nghiệm hộp trắng

Khác với kiểm thử hộp đen, kiểm thử hộp trắng xem xét mọi module trong
chương trình, các luồng thực hiện cơng việc để từ đó đưa ra các chiến

lược kế hoạch cụ thể cho việc kiểm thử. Người kiểm thử truy nhập vào mã nguồn
chương trình và có thểkiểm tra nó, lấy đó làm cơ sở để hỗ trợ việc kiểm thử.
Những gì người kiểm tra làm khi kiểm tra một ứng dụng bằng kỹ thuật kiểm thử
hộp trắng:
Bước 1 : Hiểu mã nguồn
Điều đầu tiên mà người kiểm thử thường làm là học và hiểu mã nguồn của ứng
dụng. Vì kiểm thử hộp trắng liên quan đến việc kiểm tra hoạt động bên trong của
16


một ứng dụng, người kiểm tra phải rất hiểu biết về ngơn ngữ lập trình được sử
dụng trong các ứng dụng mà họ đang kiểm tra.
Bước 2: Tạo các trường hợp kiểm tra và thực hiện
Bước cơ bản thứ hai để kiểm tra hộp trắng liên quan đến việc kiểm tra mã nguồn
của ứng dụng cho luồng và cấu trúc thích hợp. Một cách là viết thêm mã để kiểm
tra mã nguồn của ứng dụng.
3.3.5. Thử

nghiệm hộp xám

Đây là một kĩ thuật kiểm thử mới dựa trên những đặc tính của cả kiểm thử
hộp đen và hộp trắng. Mục tiêu chính của kiểm thử hộp xám là kiểm thử các ứng
dụng trên nền web (web based).

Các bước để thực hiện Kiểm tra hộp xám là:
•

Bước 1 : Xác định đầu vào

•


Bước 2 : Xác định kết quả đầu ra

•

Bước 3 : Xác định các con đường chính

•

Bước 4 : Xác định các chức năng con

•

Bước 5 : Phát triển đầu vào cho các Hàm con

•

Bước 6 : Phát triển kết quả đầu ra cho các Hàm con

•

Bước 7 : Thực thi trường hợp kiểm thử cho các hàm con

•

Bước 8 : Xác minh kết quả chính xác cho các Hàm con

•

Bước 9 : Lặp lại bước 4 & 8 cho các Hàm con khác


•

Bước 10 : Lặp lại bước 7 & 8 cho các Hàm con khác

17


Các trường hợp kiểm tra để kiểm tra hộp xám có thể bao gồm, liên quan đến GUI,
liên quan đến bảo mật, liên quan đến cơ sở dữ liệu, liên quan đến trình duyệt, liên
quan đến hệ thống hoạt động, v.v.

4.

Nhu cầu tuyển dụng khó khăn thách thức với ngành kiểm
thử

Cơng việc của người tester vừa dễ lại vừa khó. Cái thách thức lớn nhất của
người tester là trong một thời gian làm sao để tìm được chiến lược test tốt nhất.
Khơng sản phẩm nào là khơng có bug và khơng ai dám khẳng định rằng mình test
hết bug chính vì thế thể việc xác định phạm vi test, yêu cầu test từ đó vạch ra kế
hoạch và chiến lược là một trong những thách thức lớn nhất của bộ phận test.
5.

Những điều kiện, kĩ năng cần thiết để trở thành 1 tester











Kỹ năng phân tích
Kỹ năng viết, tạo 1 Test case
Kỹ năng Programming: 1 tester có thể sử dụng được một trong những
ngơn ngữ lập trình phổ biến nhất hiện nay (Jscrip, Java, python, ….)
Hiểu thêm một số dạng testing
Hiểu được ứng dụng mà mình đang làm việc
Kinh nghiệm sử dụng các công cụ kiểm thử tự động
Hiểu về vòng đời của một dự án kiểm thử phần mềm tự động
Chiến lược phát triển của các kịch bản kiểm thử
Liên tục cập nhập kiểm thử phần mềm

II. Giai đoạn 2 : (Tìm hiểu tại doanh nghiệp ) Kiểm
thử phần mềm tại công ty FSOFT
1.

Quy trình(mô hình,chu kì...), kỹ thuật, cấp độ và kế hoạch
của 1 quá trình kiểm thử.



Các kỹ thuật được sử dụng:
Kiểm thử hộp đen
+ Kiểm thử hộp trắng
+ Kiểm thử hộp xám
Các cấp độ

+ Kiểm thử đơn vị
+ Kiểm thử tích hợp
+ Kiểm thử hệ thống
+ Kiểm thử chấp nhận
+



2.

Cách thiết kế kịch bản kiểm thử
18


Xây dựng bảng kế hoạch kiểm thử:
+ Phạm vi kiểm thử
+ Phương pháp kiểm thử
+ Nguồn lực
+ Kế hoạch thực hiện
Mục tiêu của testing planning:
Xác định mục tiêu dài hạn và ngắn hạn của việc kiểm thử
Xác định các đối tượng có ảnh hưởng:
 Khách hàng
 Các bên liên quan
 Mục tiêu dự án
Các rủi ro có thể xảy ra
Phương thức thực hiện kiểm thử
Tổ chức các trường hợp kiểm thử
• Các bước thực hiện Test Planning:
 Xác định phạm vi, các rủi ro và các mục tiêu của việc kiểm thử

 Xác định các phương thức thực hiện
 Xây dựng chính sách và chiến lược kiểm thử
 Xác định hệ thống tài nguyên
 Xây dựng kế hoạch bao gồm danh sách công việc, thời gian thực
hiện và phương thức đánh giá
 Xác định điều kiện dùng
•


o
o

o
o
o

3.

Quá trình thực hiện .
+
+
+
+
+

4.

Nhận yêu cầu từ khách hàng
Lập kế hoạch kiểm thử
Thiết kế các test case

Tiến hành các test case
Báo cáo lỗi, báo cáo kết quả kiểm thử

Quá trình kiểm thử gắn với yêu cầu khách hàng .
+

+
+
+

Vai trò của kiểm thử là cực kì quan trọng đối với khách hàng, quyết định
chất lượng sản phẩm phần mềm khi tới tay khách hàng. Sản phẩm chất
lượng được giao cho khách hàng giúp họ sử dụng hiệu quả hơn.
Quá trình kiểm thử phải đảm bảo tính năng đó đúng với requirement (u
cầu) của khách hàng.
Kiểm thử là điều cần thiết vì nó đảm bảo độ tin cậy của khách hàng và sự
hài lòng của họ về ứng dụng.
Thử nghiệm phần mềm là cần thiết để cung cấp các phần mềm chất lượng
cao cho khách hàng hoặc ứng dụng phần mềm đòi hỏi chi phí bảo trì thấp
hơn và do đó dẫn đến kết quả chính xác, nhất quán và đáng tin cậy hơn.

19


5.

Các tài liệu kiểm thử (các mẫu, biểu cần hoàn thiện: lập
kế hoạch,..)
Tester.xlsx




Giải thích về các sheet:

-

Sheet cover: Giới thiệu tên dự án, ngày tạo file testcase, phiên bản, người

-

viết tài liệu, người phê duyệt tài liệu.
Sheet record:
+ Table of content: Mục lục của tài liệu, bao gồm những sheet nào, và nội
+

dung của các sheet đó.
Record of change: Lưu lại quá trình sửa đổi qua các phiên bản và người

-

sửa đổi, ngày sửa đổi chúng.
Sheet test report: Dùng để đếm xem bao nhiêu case pass và bao nhiêu case

-

fail.
Sheet Requirement Mapping: Cho chúng ta biết được test case được viết
cho chức năng nào, có thể nhìn trực quan, rõ ràng test case của chức năng
nào, có thể đính kèm link hoặc tài liệu yêu cầu chức năng để người đọc có


-

thể mở lại đọc yêu cầu của chức năng.
Sheet Function (kiểm thử chức năng): Chỉ tập trung kiểm tra chức năng của
ứng dụng đó có hoạt động đúng như khách hàng mong đợi không? Khi test
sẽ dựa vào tài liệu yêu cầu (requirement) hoặc tài liệu mô tả chi tiết
(specification) để test. Khơng quan tâm đến các khía cạnh khác như giao

»

diện đẹp, xấu, dễ sử dụng hay không, thời gian xử lý nhanh hay chậm.
Nói chung, sheet này gồm các testcase về logic chức năng, đảm bảo các

-

chức năng phải đúng như yêu cầu.
Sheet Screen Element: Sheets này dùng để test màn hình hiển thị của chức
năng, xem có đúng với thiết kế hay khơng. Tester sẽ viết các testcase phải

-

bảo đảm được giao diện sẽ phải giống với thiết kế.
Sheet Email Template :
+ Đối với những chức năng cần gửi mail hoặc nhận mail thì mới sử
dụng sheet này, bao gồm các test case về template email đảm bảo
đúng theo thiết kế của email. Thường thì sẽ gồm các case như mail
cần gửi tới ai, tên mail là gì, nội dung,…
20



+
»
-

Cịn những chức năng khơng có phần gửi mail và nhận mail thì bỏ qua

sheet này.
Đây là sheet có thể có hoặc khơng và tùy thuộc vào chức năng.
Sheet DashBoard View : Nếu u cầu có DashBoard thì mới dùng sheet
này, khơng thì bỏ qua. Sheet này test phần hiển thị trang DashBoard có đúng

»
-

với thiết kế hay khơng.
Đây là cũng là sheet có thể có hoặc khơng.
Sheet Common Case: Bao gồm những test case chung được liệt kê cho cả
sản phẩm, được sử dụng ở tất cả các chức năng, nó có thể dùng lại mà khơng

-

6.

cần thay đổi case ở mỗi chức năng.
VD: fomat phông chữ, màu sắc button, làm trò số,…

Những người thực hiện kiểm thử, vai trò từng người.
Vị trí

Test manager


Vai trò
•
•

Tester

•
•
•

Developer trong kiểm
thử

•
•

Test administration

•
•

SQA member

7.

•

Quản lý toàn bộ dự án
Xác định hướng dự án

Xây dựng các test cases
Tạo test suites
Thực hiện kiểm thử, ghi lại kết quả, báo cáo lỗi
Tạo chương trình để kiểm thử, code được tạo bởi
developer
Tạo tập lệnh automation test
Xây dựng và đảm bảo Mơi trường kiểm thử, quản lý
và duy trì tài sản
Hỗ trợ nhóm sử dụng mơi trường kiểm thử để thực
hiện kiểm thử
Chịu trách nhiểm đảm bảo chất lượng

Những chứng nhận về phần mềm của công ty Fsoft

Những chứng nhận về phần mềm của công ty FSOFT là:


Vào năm 2002, FSOFT đạt chứng chỉ CMM4. Đây là chứng chỉ chất lượng
của Viện Kỹ nghệ Phần mềm SEI do Bộ Quốc phòng Mỹ thành lập và cấp
21






kinh phí hoạt động. Việc đạt được chứng chỉ này là vô cùng quan trọng đối
với Fsoft, là kết quả của sự miệt mài thực hiện trong hơn 1 năm qua của cả
trung tâm tính từ ngày chính thức khởi động dự án CMM 1/2/2001. Với
chứng chỉ này, công ty FPT đã trở thành 1 trong số 120 công ty phần mềm

có chất lượng hàng đầu thế giới, và là công ty đầu tiên của Đông Nam á đạt
được chứng chỉ chất lượng uy tín này ở cấp 4 (high mature level).
1/2006, FSOFT đạt được chứng chỉ BS7799-2:2002. Đây là chứng chỉ về
quy trình bảo mật thơng tin.
Năm 2007, đạt chứng chỉ ISO 27001:2005.
Cho tới hiện nay FSOFT đã nhận được các chứng chỉ thế giới về chất lượng
và bảo mật như: CMMI 5, ISO 9001, IS0 20000.

Tài liệu tham khảo:
a/newest
(indiumsoftware.com)

Phần 3: Kết luận và bài học kinh nghiệm
I.

Bài học kinh nghiệm
Thông qua những tài liệu tự nghiên cứu cùng với sự giúp đỡ tận tình của

giáo viên phụ trách bộ mơn. Nhóm 3 đã rút ra cho mình những bài học về quá trình
kiểm thử phần mềm :
+

Hiểu được định nghĩa được khái niệm của kiểm thử phần mềm.Những
thách thức, khó khăn của một tester nói riêng và ngành kiểm thử phần
mềm nói chung. Biết được để trở thành 1 tester cần những điều kiện

+

+


kỹ năng và yếu tố gì .
Biết được những mức độ kiểm tra một phần mềm, kiểm thử phần
mềm có những loại nào, và những phương pháp kiểm thử. Những lưu
ý cần thiết cho quá trình kiểm thử
Tổng quát lên quá trình chung và cơ bản cho một quá trình kiểm thử
bình thường cũng như của công ty phần mềm FSOFT đang sử dụng

+

thực tế và biết về những biểu mẫu cần thiết cho quá trình kiểm thử .
Vai trị của u cầu khách hàng đối với một quá trình kiểm thử là rất
quan trọng.

22


II.

Kết Luận
Với cách tiếp cận dựa trên những đề xuất đã có trong lĩnh vực nghiên cứu về

kiểm thử phần mềm,cùng với sự tiếp cận doanh nghiệp trong thời gian ngắn , bài
báo cáo này là một sự tổng hợp những nét tổng quan trong lĩnh vực kiểm thử phần
mềm. Sau đây là những điểm chính mà bài báo cáo đã tập trung nghiên cứu :
•

Trình bày một cách tổng quan nhất về kiểm thử phần mềm: khái niệm,
mục đích và mục tiêu của kiểm thử, trong đó giới thiệu phương pháp
thiết kế dữ liệu thử phổ biến được hầu hết các kiểm thử viên sử dụng
hiện nay. Hiểu được nhu cầu thị trường những khó khăn thách thức ở

trong lĩnh vực kiểm thử phần mềm để từ đó rút ra những điều kiện cần

•

thiết để trở thành 1 kiểm thử viên.
Trình bầy ngắn gọn về các kỹ thuật,loại hình phương pháp kiểm trong đó
đã chỉ rõ được điểm khác biệt của các phương pháp kiểm thử hiện nay

•

đang có và được các cơng ty áp dụng.
Tìm hiểu về lĩnh vực kiểm thử phần mềm của công ty Fsoft về kế
hoạch ,quy trình thực hiện, những tài liệu kiểm thử được chia sẻ khi tiếp
cận doanh nghiệp...

Trong quá trình thực hiện bài tập lớn cũng như trong thời gian trước đó,
nhóm chúng em đã cố gắng tập trung nghiên cứu về lĩnh vực kiểm thử này cũng
như đã tham khảo khá nhiều tài liệu liên quan. Tuy nhiên, do thời gian và trình độ
có hạn nên khơng tránh khỏi những hạn chế và thiếu sót nhất định. Nhóm 3
chúng em thật sự mong muốn nhận được những góp ý cả về chun mơn lẫn cách
trình bày của báo cáo từ cô và các bạn .Trân thành cảm ơn !

23