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

BÁO CÁO THỰC HÀNH
Mơn: Kiểm thử phần mềm
Đề tài: Tìm hiểu về q trình kiểm thử negative và
interoperability

Nhóm thực hiện: 21
Mã lớp: 20212IT6013002
Danh sách nhóm :
Người hướng dẫn: TS. Hồng Quang Huy

Hà Nội, 11/2021


MỤC LỤC
CHƯƠNG 1: KHÁI NIỆM KIỂM THỬ PHẦN MỀM............................................4
1.1. Khái niệm.........................................................................................................4
1.2. Lợi ích của kiểm thử.........................................................................................4
1.3. Các giai đoạn của q trình kiểm thử phần mềm..............................................5
1.3.1. Phân tích u cầu về sản phẩm (requirement analysis)..............................5
1.3.2. Lập kế hoạch kiểm thử phần mềm (test planning).....................................6
1.3.3. Thiết kế kịch bản kiểm thử phần mềm (test case development).................7
1.3.4. Sắp đặt môi trường kiểm thử phần mềm (test environment set up)............7
1.3.5. Thực thi quá trình kiểm thử phần mềm (test execution)............................7
1.3.6. Kết thúc chu trình kiểm thử phần mềm (test cycle closure).......................8
1.4. Kiểm thử hộp đen.............................................................................................8
1.4.1. Khái niệm..................................................................................................8
1.4.2. Ưu điểm.....................................................................................................9

1.4.3. Nhược điểm...............................................................................................9
1.5. Kiểm thử hộp trắng.........................................................................................10
1.5.1. Khái niệm................................................................................................10
1.5.2. Ưu điểm...................................................................................................10
1.5.3. Nhược điểm.............................................................................................11
CHƯƠNG 2: QUÁ TRÌNH KIỂM THỬ NEGATIVE VÀ INTEROPERABILITY
..................................................................................................................................... 12
2.1. Kiểm thử negative..........................................................................................12
2.1.1. Khái niệm................................................................................................12
2.1.2. Quy trình thực hiện Kiểm tra bị động(Negative Testing).........................14
2.1.3. Ưu điểm...................................................................................................15
2.1.4. Nhược điểm.............................................................................................15
2.2. Kiểm thử Interoperability (kiểm thử liên tác).................................................16
2.2.1. Khái niệm................................................................................................16
1


2.2.2. Quy trình thực hiện Kiểm tra liên tác.......................................................17
2.2.3. Ưu điểm...................................................................................................19
2.2.4. Nhược điểm.............................................................................................20
CHƯƠNG 3: ỨNG DỤNG KIỂM THỬ..................................................................21
3.1. Lập kế hoạch..................................................................................................21
3.2. Công cụ..........................................................................................................21
3.3. Kịch bản kiểm thử..........................................................................................21
3.4. Thực hiện kiểm thử........................................................................................21
3.5. Cài đặt các công cụ.........................................................................................25
KẾT LUẬN................................................................................................................28
TÀI LIỆU THAM KHẢO.........................................................................................29

2



LỜI MỞ ĐẦU
Công nghệ thông tin là một ngành rất phát triển trong xã hội ngày nay. Nó
được ứng dụng trong rất nhiều ngành, lĩnh vực và đạt được hiệu quả cao. Đặc
biệt là trong công tác quản lý, tin học làm giảm nhẹ được sức của con người
quản lý, tiết kiệm thời gian và gọn nhẹ hơn nhiều so với cách quản lý bằng giấy
tờ như trước kia. Ứng dụng tin học vào cơng tác quản lý cịn giúp thu hẹp không
gian lưu trữ dữ liệu, tránh thất lạc dữ liệu một cách an tồn. Hơn nữa nó cịn
giúp tìm kiếm, tra cứu thơng tin một cách nhanh chóng, chính xác và đầy đủ.
Nhóm em xin gửi lời tri ân sâu sắc đến thầy ThS. Hoàng Quang Huy.
Trong quá trình tìm hiểu và học tập bộ mơn Kiểm thử phần mềm, nhóm đã nhận
được sự hướng dẫn và những chia sẻ rất tận tình, tâm huyết của thầy. Từ những
hướng dẫn tận tình của thầy cùng với kiến thức mà nhóm đã học tập, tìm hiểu,
chúng em đã hồn thành báo cáo đề tài “Nghiên cứu kỹ thuật kiểm negative và
interoperbility”.
Với tất cả sự cố gắng, nỗ lực của mình, nhóm em đã hồn thành tốt nhất bài
báo cáo này. Nhưng chúng em vẫn rất mong nhận được sự góp ý của thầy cơ và
các bạn để bài báo cáo của chúng em được hồn thiện hơn.
Kính chúc thầy cô thật nhiều sức khoẻ, hạnh phúc và thành công trong cuộc
sống.
Nhóm em xin chân thành cảm ơn!

3


CHƯƠNG 1:KHÁI NIỆM KIỂM THỬ PHẦN MỀM
1.1.

Khái niệm

Kiểm thử phần mềm là một quá trình kiểm tra để phát hiện ra lỗi của những

phần mềm, ứng dụng nhằm cung cấp cho khách hàng, lập trình viên… thơng tin
về chất lượng của phần mềm được kiểm thử. Mục đích cuối cùng của công việc
này là để đảm bảo sản phẩm (phần mềm, ứng dụng) được tạo ra theo đúng mong
muốn khách hàng và hoạt động hiệu quả. Với các công ty phát triển phần mềm
thì Tester (chuyên viên kiểm thử phần mềm) có vai trị cốt yếu để đảm bảo uy
tín của công ty, tránh những trường hợp sản phẩm lỗi bị khách hàng trả về nơi
sản xuất.
Kiểm thử phần mềm là phương pháp kiểm tra xem sản phẩm phần mềm đó
trên thực tế có phù hợp với các yêu cầu đã đặt ra hay khơng, và đảm bảo rằng
khơng có lỗi hay khiếm khuyết. Nó bao gồm việc kiểm tra, phân tích, quan sát
và đánh giá các khía cạnh khác nhau của sản phẩm. Người kiểm thử phần mềm
(Tester) sử dụng kết hợp các công cụ thủ công và tự động. Sau khi tiến hành
kiểm thử, Tester báo cáo kết quả cho team phát triển. Mục đích là xác định các
lỗi, khiếm khuyết hoặc các yêu cầu còn thiếu so với yêu cầu thực tế.
1.2.

Lợi ích của kiểm thử
Hiệu quả về chi phí: Đây là một trong những lợi ích quan trọng của kiểm

thử phần mềm. Thực tế cho thấy rằng các lỗi thiết kế khó có thể được loại trừ
hồn tồn đối với bất kỳ hệ thống nào. Đó không phải là lỗi bất cẩn của
Developer mà đôi khi do sự phức tạp của hệ thống. Nếu các vấn đề về thiết kế
khơng được phát hiện, thì việc tìm ra và sửa các lỗi/khiếm khuyết sẽ trở nên khó
khăn và tốn kém hơn. Kiểm thử bất kỳ dự án IT nào cũng sẽ giúp công ty tiết
kiệm, việc xác định lỗi trong giai đoạn đầu sẽ giúp quá trình sửa chữa tốn ít chi
phí hơn.

4



Bảo mật: Đây là điểm nhạy cảm và dễ bị tấn công nhất của kiểm thử phần
mềm. Kiểm thử giúp loại bỏ các rủi ro và vấn đề trong sản phẩm. Cùng với đó,
tất cả khách hàng đều đang tìm kiếm những sản phẩm đáng tin cậy.
Chất lượng sản phẩm: Đây là yêu cầu thiết yếu của bất kỳ sản phẩm phần
mềm nào. Kiểm thử phần mềm giống như việc củng cố danh tiếng công ty bằng
cách cung cấp các sản phẩm chất lượng cho khách hàng.
Sự hài lòng của khách hàng: Trong bất kỳ hoạt động kinh doanh sản
phẩm nào, mục tiêu cuối cùng đều là mang đến cho khách hàng trải nghiệm tốt
nhất. Sự hài lòng của khách hàng rất quan trọng trong quá trình hợp tác lâu dài.
1.3.

Các giai đoạn của q trình kiểm thử phần mềm
Khơng có một quy trình nào đúng trong mọi trường hợp, nhưng 6 bước

dưới đây mang tính khái quát và phù hợp nhất cho hầu hết quá trình kiểm thử
phần mềm:

Phân tích u
cầu

Thiết kế kiểm
Lập kế hoạch
thử

Chuẩn bị mơi
Thực thi
trường
Kết thúc


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

5


1.3.1. Phân tích yêu cầu về sản phẩm (requirement analysis)
Bước đầu tiên của việc kiểm thử phần mềm là gì? Khơng liên quan đến
việc kiểm tra thử nghiệm gì đâu nhé. Các thành viên trong nhóm kiểm thử sẽ lập
thành một QA team để thực hiện nghiên cứu, phân tích chi tiết các tài liệu về
thiết kế hệ thống, những yêu cầu của khách hàng về tiêu chí, chất lượng của sản
phẩm, các bản mẫu (prototype) mà khách hàng cung cấp, ...
Nhờ đó, team này sẽ nắm bắt được các yêu cầu của dự án. Bên cạnh đó,
nếu có thắc mắc về mong muốn của khách hàng hay muốn đưa ra các đề xuất
mới, QA team sẽ đưa ra câu hỏi cho các bên như BA( Business Analysis),
trưởng nhóm kiểm thử hay khách hàng để hiểu rõ hơn về yêu cầu trong các tài
liệu trên. Hơn nữa, vì khơng phải khách hàng nào cũng hiểu biết về công nghệ
nên khá khó khăn để đặt câu hỏi mang tính chun mơn cho họ. Chính vì vậy,
những người trong QA team sẽ phải hỗ trợ và cung cấp các đề xuất một cách dễ
hiểu nhất cho khách hàng lựa chọn.
1.3.2. Lập kế hoạch kiểm thử phần mềm (test planning)
Sau khi đã nhận được các tài liệu phân tích, báo cáo… từ QA team ở bước
trên, các leader sẽ tiến hành lập kế hoạch kiểm thử cho cả nhóm thực hiện.
Người lập kế hoạch sẽ phải thực hiện các hoạt động như:
- Xác định phạm vi của dự án: các vấn đề liên quan đến thời gian thực hiện,
lịch trình, cơng việc cụ thể cho từng giai đoạn…
- Xác định phương pháp tiếp cận: dựa vào thời gian, yêu cầu của khách
hàng, công nghệ, kỹ thuật… leader kiểm thử phần mềm sẽ đưa ra cách thức
kiểm thử phù hợp, hiệu quả nhất.
- Xác định nguồn lực cho quá trình kiểm thử: cần bao nhiêu người tham

gia, ai làm cơng việc gì, cần những thiết bị hỗ trợ nào, số lượng ra sao…
- Lập kế hoạch thiết kế công việc kiểm thử: đưa ra các chức năng cần kiểm
thử. những cơng việc gì cần thực hiện, thời gian bao lâu, xác định những điều
6


kiện tối thiểu để bắt đầu cũng như khi nào thì kết thúc hoạt động kiểm thử với
từng chức năng…
1.3.3. Thiết kế kịch bản kiểm thử phần mềm (test case development)
Dựa vào kế hoạch của leader đã đưa ra cũng như các tài liệu đầu vào khác,
các chuyên viên kiểm thử phần mềm (Tester) sẽ xem xét lại và bắt đầu viết test
case chi tiết. Bên cạnh viết kịch bản chi tiết thì các chuyên viên kiểm thử cũng
phải chuẩn bị trước các dữ liệu như test data, test script cho các trường hợp cần
thiết. Sau khi đã hoàn thành test case/checklist, các thành viên cũng như team
leader cần kiểm tra lại xem cần bổ sung, sửa chữa vấn đề gì khơng để tránh
những rủi ro về sau.
1.3.4. Sắp đặt môi trường kiểm thử phần mềm (test environment set up)
Đầu vào của quá trình này là các kịch bản kiểm thử, test data, kế hoạch
kiểm thử đã lập ra ở các bước trên… Việc thiết lập môi trường (test
environment) kiểm thử phần mềm cũng khá quan trọng trong quy trình test phần
mềm vì nếu mơi trường khơng phù hợp với sản phẩm hay mong muốn khách
hàng thì kết quả kiểm thử sẽ khơng chính xác. Mơi trường kiểm thử sẽ được
thiết lập dựa trên những đề nghị của khách hàng, hay các đặc điểm của sản phẩm
như server, network, client,...
Ngoài ra, chuyên viên kiểm thử cũng cần chuẩn bị một vài test case để xem
môi trường kiểm thử đã sẵn sàng cho bước thực thi tiếp theo hay chưa. Kết thúc
giai đoạn này, tester đã có được sẵn mơi trường phù hợp cho việc test phần mềm
trong thực tế.
1.3.5. Thực thi quá trình kiểm thử phần mềm (test execution)
Nhiệm vụ chính của chun viên kiểm thử phần mềm là gì? Dựa vào tất cả

những tài liệu, kế hoạch từ các bước trên, các tester sẽ tiến hành các test case
trên môi trường kiểm thử đã được thiết lập. Họ sẽ so sánh kết quả kiểm thử với
kết quả mong đợi để phát hiện ra các lỗi sai và tiến hành theo dõi các lỗi đó đến
7


khi chúng được fix hồn tồn. Bên cạnh đó, kiểm thử viên cũng cần theo dõi tiến
độ của dự án và điều chỉnh sao cho phù hợp với kế hoạch đề ra.
Công việc của người kiểm thử không phải chỉ là test phần mềm, họ còn
phải hỗ trợ, đưa ra các đề xuất hay giải pháp hợp lý cho các lập trình viên
(developer) để hồn thành sản phẩm như mong muốn. Trong quá trình này,
chuyên viên kiểm thử phải thường xuyên báo cáo về tình hình test (phần nào đã
được kiểm tra, phần nào chưa, báo cáo các tình huống phát sinh bất ngờ…) cho
các bên liên quan như team leader, người quản lý dự án, khách hàng…
1.3.6. Kết thúc chu trình kiểm thử phần mềm (test cycle closure)
Đây là giai đoạn cuối cùng của quy trình kiểm thử phần mềm. Tất cả các
chuyên viên thực hiện test phần mềm sẽ tổng hợp và viết báo cáo kết quả cuối
cùng của việc kiểm thử (test report final). Trong đó phải chỉ ra được bao nhiêu
test case đạt/ không đạt yêu cầu, bao nhiêu case được sửa, bao nhiêu lỗi được
phát hiện, lỗi tồn tại nhiều ở chức năng nào, chức năng nào đã được/ chưa được
kiểm thử hay trễ tiến độ… Bên cạnh đó, team test phần mềm cũng cần xem lại
quá trình thực hiện để nhìn ra những điểm tốt, chưa tốt của team, cũng như rút
kinh nghiệm cho những lần kiểm thử sau này.
1.4.

Kiểm thử hộp đen

1.4.1. Khái niệm
Kiểm thử hộp đen: là một phương pháp kiểm thử phần mềm được thực hiện
mà không biết được cấu tạo bên trong của phần mềm, là cách mà các tester kiểm

tra xem hệ thống như một chiếc hộp đen, không có cách nào nhìn thấy bên trong
của cái hộp.
Nó cịn được gọi là kiểm thử hướng dữ liệu hay là kiểm thử hướng in/out.
Người kiểm thử nên xây dựng các nhóm giá trị đầu vào mà sẽ thực thi đầy
đủ tất cả các yêu cầu chức năng của chương trình.

8


Cách tiếp cận của các tester đối với hệ thống là không dùng bất kỳ một kiến
thức về cấu trúc lập trình bên trong hệ thống, xem hệ thống là một cấu trúc hồn
chỉnh, khơng thể can thiệp vào bên trong.
1.4.2. Ưu điểm
Các tester được 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.
Các tester theo phương pháp black box khơng có “mối ràng buộc” nào với
code, và nhận thức của một tester rất đơn giản: một source code có nhiều lỗi. Sử
dụng nguyên tắc, "Hỏi và bạn sẽ nhận" các tester black box tìm được nhiều bug
ở nơi mà các DEV khơng tìm thấy.
Tester có thể không phải IT 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.
Các tester có thể được thực hiện bởi một cơ quan độ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ị.
Hệ thống thật sự với toàn bộ yêu cầu của nó được kiểm thử chính xác.
Thiết kế kịch bản kiểm thử khá nhanh, ngay khi mà các yêu cầu chức năng
được xác định.
1.4.3. Nhược điểm
Dữ liệu đầu vào yêu cầu một khối lượng mẫu (sample) khá lớn
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.
Khả năng để bản thân kỹ sư lạc lối trong khi kiểm thử là khá cao.
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.
9


Kiểm thử black box được xem như "là bước đi trong mê cung tối đen mà
không mang đèn pin” bởi vì tester khơng biết phần mềm đang test đã được xây
dựng như thế nào. Có nhiều trường hợp khi một tester viết rất nhiều trường hợp
test để kiểm tra một số thứ có thể chỉ được test bằng một trường hợp test
và/hoặc một vài phần cuối cùng không được test hết.
1.5.

Kiểm thử hộp trắng

1.5.1. Khái niệm
Kiểm thử Hộp Trắng là một kỹ thuật xác minh giúp các kỹ sư phần mềm có
thể sử dụng để kiểm tra mã code của họ hoạt động như dự kiến

Đối tượng được kiểm thử là 1 thành phần phần mềm (TPPM).TPPM có thể
là 1 hàm chức năng, 1 module chức năng, 1 phân hệ chức năng…
Phương pháp Kiểm tra Hộp trắng áp dụng cho các mức độ kiểm tra phần
mềm sau đây:
• Unit Testing(Kiểm thử đơn vị): Để kiểm tra đường dẫn trong một đơn vị.
• Integration Testing(Test tích hợp): Để kiểm tra đường dẫn giữa các đơn
vị.
• System Testing(Test hệ thống): Để kiểm tra các đường dẫn giữa các hệ
thống con.
Tuy nhiên, nó là chủ yếu áp dụng cho các kiểm thử đơn vị

10


1.5.2. Ư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 đường dẫn
-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ã hoá
-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
sốt lỗi tối đa nhất.
1.5.3. Nhược điểm
-Vì các bài kiểm tra rất phức tạp, địi hỏi phải có các nguồn lực có tay nghề
cao, với kiến thức sâu rộng về lập trình và thực hiện.
-Maintenance test script có thể là một gánh nặng nếu thể hiện thay đổi quá
thường xuyên.
-Vì phương pháp thử nghiệm này liên quan chặt chẽ với ứng dụng đang
được test, nên các công cụ để phục vụ cho mọi loại triển khai / nền tảng có thể
khơng sẵn có.

11


CHƯƠNG 2:QUÁ TRÌNH KIỂM THỬ NEGATIVE VÀ
INTEROPERABILITY
2.1.

Kiểm thử negative


2.1.1. Khái niệm
Negative testing (kiểm thử bị động) là một loại kiểm thử phần mềm được
sử dụng để kiểm tra ứng dụng phần mềm về các dữ liệu và điều kiện đầu vào
không mong muốn. Dữ liệu hoặc điều kiện không mong muốn có thể là bất cứ
điều gì, từ kiểu dữ liệu sai cho đến tấn cơng hack mạnh. Mục đích của kiểm tra
bị động là để ngăn chặn ứng dụng phần mềm bị treo do các đầu vào tiêu cực và
cải thiện chất lượng và độ ổn định.
Tất cả những trường hợp này sẽ được negative testing. Điều quan trọng của
điều này là chúng tôi không thể đảm bảo rằng tất cả những điều đã đề cập ở trên
sẽ không xảy ra, vì vậy chúng tơi cần chúng được chứa đựng.
Xem xét trường hợp kiểm tra tình trạng thừa cân và khi thực hiện, thang
máy hoạt động khơng bình thường khi có tình trạng thừa cân. Điều này có thể
gây ảnh hưởng đến độ tin cậy của hệ thống và thậm chí có thể gây nguy hiểm
đến tính mạng. Điều này giải thích negative testing là gì và tầm quan trọng của
nó.
Trường hợp tương tự cũng được áp dụng trong phần mềm. Đối với negative
testing, chúng tôi đã đi chệch khỏi quy trình hoạt động bình thường. Hãy đi qua
một số ví dụ.
Hãy xem xét một biểu mẫu đăng ký chẳng hạn.

12


Negative Testing

Positive Testing

Cố gắng nhập một id email không Chỉ những id email hợp lệ mới được
hợp lệ vào trường email


nhập vào trường email

Cố gắng nhập số điện thoại không Số duy nhất sẽ được nhập vào trường
hợp lệ vào trường số điện thoại (ký số
tự)
Tải lên hình ảnh có kích thước ngồi Chỉ những hình ảnh có kích thước
ranh giới đã chỉ định

dưới ranh giới cụ thể mới được tải lên

Tải lên các tệp không hợp lệ như tệp Chỉ tải lên các định dạng hình ảnh
XML, SQL, v.v. trong trường tải lên hợp lệ như jpg.png, v.v.
hình ảnh

Như chúng tơi đã nói trước đó, chúng tơi phải đảm bảo trong tất cả các
trường hợp tiêu cực này, hệ thống của chúng tơi sẽ hoạt động bình thường. Hãy
xem xét trường hợp nếu ai đó cố gắng nhập một ký tự vào trường số và hệ thống
không thể xử lý dữ liệu khơng mong muốn vì nó đang mong đợi một số và cuối
cùng, hệ thống bị treo. Hoặc điều gì sẽ xảy ra nếu ai đó cố gắng thực hiện
chèn SQL và xóa tất cả dữ liệu của chúng tôi khỏi cơ sở dữ liệu. Chúng tôi
không thể chịu được những tổn thất tiềm tàng như vậy. Vì vậy việc kiểm tra âm
tính là quan trọng.
Tổ chức có trách nhiệm cung cấp sản phẩm chất lượng tốt cho khách hàng
của mình. Để đạt được điều này, người ta phải làm Negative Testing
Là một phần của xác nhận chống lại sự thất bại, một tổ chức phải thực hiện
Negative Testing
Có thể chúng ta khơng thể xây dựng một hệ thống 100% khơng có lỗi,
nhưng chúng ta phải đảm bảo rằng chúng ta đã làm mọi thứ để ngăn chặn lỗi, để
đạt được điều đó, chúng ta nên thực hiện Negative Testing

13


Tác động là một yếu tố mà chúng tôi phải xem xét. Hãy xem xét chúng tôi
đã thực hiện thử nghiệm tích cực trên một trang thương mại điện tử và đảm bảo
rằng mọi thứ đều ổn. Nhưng điều gì sẽ xảy ra nếu có một lỗ hổng trong hệ thống
của chúng tơi mà ai đó có thể thực hiện việc chèn SQL và xóa tất cả dữ liệu của
chúng tơi. Đó sẽ là một vi phạm an ninh lớn. Để tránh loại trường hợp này,
người ta cũng phải làm
Đối với các ứng dụng mở cho công chúng, chủ yếu là các trang web, chúng
tôi phải luôn nhớ rằng chúng tơi khơng có nhiều quyền kiểm sốt quy trình sử
dụng của ứng dụng, vì vậy chúng tơi phải thực hiện Negative Testing để đảm
bảo rằng tất cả các trường hợp đó đều được bảo vệ và ngăn chặn.
Một điều nữa mà chúng ta cần quan tâm là có rất nhiều hacker đen ngồi
kia đang tìm cơ hội để phá hoại hệ thống. Lấy cắp dữ liệu là một trường hợp
quan trọng được đề cập trong negative testing
Khách hàng luôn mong đợi các sản phẩm khơng có lỗ hổng bảo mật, để
đảm bảo rằng negative testing là điều bắt buộc
Nếu đó là một sản phẩm nhạy cảm như thương mại điện tử, chứng khốn
trực tuyến, v.v. thì bảo mật và negetive testing là điều bắt buộc
Mối quan tâm duy nhất đối với khách hàng liên quan đến Negative Testing
là chi phí. Nhưng một khi tác động được phân tích, khách hàng sẽ quyết định có
thực hiện hay khơng negative testing
2.1.2. Quy trình thực hiện Kiểm tra bị động(Negative Testing)
Để thực hiện Negative Testing, chúng tôi phải xem xét tất cả các trường
hợp có thể xảy ra. Đó là nếu có thể, chúng ta phải xem xét nó trong trường hợp
thử nghiệm cho dù đó có phải là cách sử dụng khơng đúng hay khơng. Ví dụ:
nếu chúng ta thấy một trường email, hãy nghĩ về tất cả các đầu vào có thể có,
chúng ta có thể đặt ở đó ngồi định dạng email chính xác. Tương tự như vậy khi


14


chúng tơi thấy tùy chọn tải lên hình ảnh, chúng tơi phải kiểm tra nó với tất cả
các tệp có thể.
Trong khi tạo các trường hợp negative testing chúng tôi phải ưu tiên các
đầu vào nếu khơng, sẽ có rất nhiều trường hợp có thể xảy ra. Ví dụ: đối với
trường hình ảnh chỉ có các tệp '.png' được cho là nhập, chúng ta có thể có nhiều
tùy chọn để tải lên như 'jpeg', 'xml', 'xls', v.v. Vì vậy, chúng ta cần ưu tiên các
tùy chọn như XML và SQL có thể có tác động lớn hơn jpeg và xls, vì vậy chúng
ta nên quan tâm đến các trường hợp SQL và XML trước. Như vậy, chúng tôi
phải ưu tiên các trường hợp trước khi thực hiện để tiết kiệm thời gian và chi phí
kiểm tra.
2.1.3. Ưu điểm
Như chúng ta đã biết Negaive Testing là rất quan trọng để đảm bảo chất
lượng của một sản phẩm. Một sản phẩm chất lượng tốt là một sản phẩm khơng
có lỗ hổng bảo mật, để đảm bảo rằng việc Negative Testing là rất quan trọng.
Thực hiện Negative Testing để đảm bảo rằng tất cả các trường hợp có thể
xảy ra đều được bảo hiểm. Cố ý hay vơ ý đều có khả năng xảy ra các trường hợp
Negative Testing .Vì vậy, để đảm bảo tất cả các trường hợp được bảo hiểm,
chúng tôi phải làm negative testing cùng với positive testing.
Negative Testing sẽ khiến khách hàng tin tưởng hơn trước khi phát trực
tiếp.
Negative testing đảm bảo rằng nghiệp vụ được xác nhận, negative testing
đảm bảo rằng phần mềm được chuyển giao khơng có sai sót nào có thể xảy ra khi
khách hàng sử dụng.
2.1.4. Nhược điểm
Trong Kỹ thuật phần mềm, negative testing trong một số trường hợp trở
nên lãng phí thời gian và năng lượng. Trong nhiều trường hợp, không cần
negative testing quá mức. Ví dụ: nếu một ứng dụng được tạo để sử dụng cho

15


một người, thì chúng ta khơng cần phải xem xét trường hợp 100 người dùng sử
dụng hệ thống cùng một lúc. Vì vậy điều kiện quyết định trong các trường hợp
negative testing là rất quan trọng. Sẽ có lúc chúng ta không phải negative testing
trên một hệ thống cụ thể.
Yêu cầu những người có kỹ năng và kinh nghiệm để tạo các trường hợp
negative testing
Đối với khách hàng, negative testing là một điều khác gây ra sự chậm trễ
không cần thiết trong việc phát hành và tăng thêm chi phí.
Cơ hội mà một nhóm dành nhiều thời gian và năng lượng hơn cho việc
negative testing. Có khả năng người thử nghiệm dành nhiều thời gian và năng
lượng cho negative testing dẫn đến nồng độ thấp hơn trong positive testing
2.2.

Kiểm thử Interoperability (kiểm thử liên tác)

2.2.1. Khái niệm
Kiểm liên tác là một loại kiểm thử phần mềm, kiểm tra xem phần mềm có
thể tương tác với các thành phần và hệ thống phần mềm khác hay khơng. Mục
đích của các bài kiểm tra Khả năng liên tác là để đảm bảo rằng sản phẩm phần
mềm có thể giao tiếp với các thành phần hoặc thiết bị khác mà khơng có bất kỳ
vấn đề tương thích nào.
Nói cách khác, kiểm tra liên tác có nghĩa là để chứng minh rằng chức năng
end-to-end giữa hai hệ thống giao tiếp là như được chỉ định bởi các yêu cầu. Ví
dụ, kiểm tra liên tác được thực hiện giữa điện thoại thông minh và máy tính
bảng để kiểm tra việc truyền dữ liệu qua Bluetooth.
Có nhiều cấp độ khác nhau của Kiểm tra liên tác, chúng
 Khả năng tương tác vật lý

 Khả năng tương tác kiểu dữ liệu
 Mức đặc điểm kỹ thuật Khả năng tương tác
16


 Khả năng tương tác ngữ nghĩa
Kiểm tra liên tác tác được thực hiện bởi vì,
 Nó đảm bảo cung cấp dịch vụ đầu cuối cho hai hoặc nhiều sản
phẩm từ các nhà cung cấp khác nhau
 Sản phẩm phần mềm phải có thể giao tiếp với thành phần hoặc thiết
bị khác mà khơng có bất kỳ vấn đề tương thích nào
Rủi ro liên quan do thiếu Kiểm tra liên tác là
 Mất dữ liệu
 Hiệu suất không đáng tin cậy
 Hoạt động không đáng tin cậy
 Hoạt động không chính xác
 Khả năng bảo trì thấp
2.2.2. Quy trình thực hiện Kiểm tra liên tác
Quy trình thử nghiệm để kiểm tra liên tác bao gồm các bước sau:
Bước 1 : Khởi chạy dự án.
 Xác định chính thức hóa tun bố công việc và thiết lập cơ sở hạ
tầng quản lý dự án.
Bước 2 : Thiết lập phịng thí nghiệm kiểm tra
 Đảm bảo rằng tất cả các công cụ kỹ năng và tự động hóa cần
thiết được thiết lập cho các hoạt động thử nghiệm
 Sử dụng các công cụ tự động hóa để giảm thiểu các trường
hợp thử nghiệm và sử dụng lại các trường hợp thử nghiệm
 Duy trì cơ sở dữ liệu gồm các tệp cấu hình
 Ghi lại và phân tích các chỉ số cho dự án


17


 Ghi lại cấu hình từ các thử nghiệm khơng thành cơng để tham khảo
và phân tích
Bước 3 : Xây dựng kế hoạch kiểm tra
 Viết kế hoạch kiểm tra
 Xác định các trường hợp và thủ tục kiểm tra
 Thiết lập thiết bị giám sát cần thiết để duy trì nhật ký kiểm tra.
Bước 4: Thực hiện kế hoạch kiểm tra
 Thực thi các trường hợp thử nghiệm
 Làm việc với nhóm kiểm tra để phân tích ngun nhân gốc rễ của
lỗi
Bước 5 : Kết quả tài liệu
 Sử dụng nhật ký kiểm tra để ghi lại các ghi chú triển khai
Bước 6 : Giải phóng tài nguyên và đánh giá hiệu suất của dự án,
 Với sự trợ giúp của các cơng cụ tự động hóa, phân tích kết quả
kiểm tra

18


Prerequisites

Interoperability

(Điều kiện tiên
quyết)
Interoperability Testing
Framework


Test System
Design

Executable Test Suite (ETS)

(Thiết kế hệ thống
(Bộ kiểm thử thực thi)

kiểm thử liên tác)

(Khung kiểm thử liên

Abstract Test Suite (ATS)

tác)
Define Test

(Bộ kiểm thử tóm tắt)

Configuration
(Xác định cấu
Testing Descriptions

hình kiểm thử)

Specify Test Cases

Validate


(Chỉ định các trường hợp kiểm thử)

(Xác thực)

(Mô tả kiểm thử)
Define Message
Structures
Test Architecture
(Kiến trúc kiểm thử)

(Xác định cấu

Equipment Operation

Conformance

trúc thông báo)

Repository

Check Repository

(Hoạt động tuân thủ

(Kho lưu trữ kiểm

thiết bị)

tra sự phù hợp)


Define Test
Limitations
(Hạn chế)

Parameters
(Xác định các
thông số kiểm

Implement Codec and

thử)

Adaptations Functions
(Thực hiện các chức năng
Codec và thích ứng)

2.2.3. Ưu điểm
 Kết nối hai hoặc nhiều thiết bị từ các nhà cung cấp khác nhau
 Kiểm tra kết nối giữa các thiết bị
 Kiểm tra xem thiết bị có thể gửi / nhận các gói hoặc khung từ
nhau khơng
 Kiểm tra xem dữ liệu có được xử lý đúng cách trong mạng và các
lớp cơ sở hay khơng
 Kiểm tra xem các thuật tốn đã triển khai có hoạt động chính
xác khơng
19