1660115 08(1thực hành kiểm tra phần mềm )

Họ và tên: Tạ Lê Minh Đức
MSSV: 1660115
Lớp 16CK1

Công cụ kiểm chứng phần mềm Khảo sát một số kỹ
thuật kiểm chứng phần mềm
Kỹ thuật kiểm thử:
 Monkey testing:
Giới thiệu
Monkey Testing là khái niệm mới toanh với mình. Đã thực hiện kiểm thử
khá nhiều ứng dụng và nhiều lần phải kiểm thử khơng có kịch bản mà
giờ mới biết đến kiểm thử có tên như này. Sau đây mình sẽ chia sẻ những
gì mình tìm hiểu được về Monkey Testing.
Monkey Testing là một kỹ thuật trong kiểm tra phần mềm khi đó, người
dùng kiểm tra ứng dụng bằng cách đưa giá trị đầu vào bất kỳ và kiểm tra
xem ứng dụng xử lý ra sao (hoặc cố gắng phá hủy chương trình).
Hầu hết kĩ thuật này được làm 1 cách tự động, người dùng nhập giá trị
không hợp lệ bất kỳ và kiểm tra xử lý. Với monkey test, khơng có qui
tắc, kĩ thuật này không theo testcase hay chiến lược xác định trước. Nó
làm việc theo tâm trạng và cảm tính của người kiểm thử.
Kỹ thuật này được tự động hóa hay nói đúng hơn là bạn có thể viết
chương trình/ kịch bản để tạo ra đầu vào ngẫu nhiên rồi đưa vào ứng
dụng và phân tích xử lý. Kĩ thuật này làm việc khá tốt khi thực hiện
load/stress testing hay khi bạn cố gắng phá hủy chương trình bằng cách
đưa khơng ngừng giá trị ngẫu nhiên vào.
 
Trước khi nói về “Monkey”, tơi sẽ giới thiệu về “Horse”
Ở hình bên dưới, bạn nhìn thấy một chiếc dây hãm ở con ngựa đúng
không? Cái này được dùng để chỉ dẫn và điều khiển con ngựa để nó

không bị mất tập trung và chỉ tâp trung vào đường thẳng trên đường mà
thôi.
Cũng giống như vậy, với test bằng tay hay test tự động thì chúng ta lúc
này đều giống như con ngựa vậy. Bởi vì chúng ta bị chỉ đường và dẫn đi
bằng testcase/ kế hoạch và chiến lược, bị kiểm sốt bởi số liệu chất
lượng.
Bởi vì chúng ta có 1 cái dây hãm quanh mình nên không muốn chuyển
hướng tập trung, chỉ tập trung một cách nghiêm khắc vào bộ testcase và
ngoan ngoãn thực hiện chúng.
Khá hồn hảo khi là 1 con ngựa nhưng có đơi khi bạn muốn làm 1 con
khỉ không?
Monkey test là tất cả những gì bạn muốn làm, một cách tự động
Kỹ thuật test này khá lộn xộn vì nó khơng theo mơ hình đặc tả nào.
Nhưng câu hỏi ở đây là
Tại sao?
Bất cứ khi nào bạn đưa một ứng dụng web lớn ra thế giới, bạn có thể
tưởng tượng bạn phục vụ những loại người dùng nào khơng?
Có người dùng tốt, lành mạnh nhưng bạn không thể chắc chắn rằng sẽ
không có người dùng xấu.
Có n số người xấu, những người cũng giống như khỉ, thích chơi xung
quanh ứng dụng, đưa vào sự khác lạ, những đầu vào lớn hoặc cố tình làm
hỏng ứng dụng.
Như vậy để kiểm thử được những tình thế đó, chúng ta, những tester
cũng phải trở thành khỉ, nghĩ và thậm chí phải kiểm thử để ứng dụng của
mình an tồn khỏi những con khỉ xấu tính.
Các loại Monkey
Có 2 loại Monkey:


1. Monkey mau lẹ

1 con khỉ mau lẹ được định nghĩa bởi các đặc tính bên dưới:
-Có ý tưởng ngắn gọn về ứng dụng
-Biết các trang của ứng dụng sẽ dẫn đến đâu
-Biết giá trị đầu vào là hợp lệ hay không hợp lệ
-Làm việc hoặc tập trung để phá hỏng hệ thống
-Khi tìm thấy 1 lỗi, chúng đủ thơng minh để bắt lỗi
-Nhận thức được các menu và button
-Khá cừ với stress và load test
2. Monkey chậm chạp
1 con khỉ chậm chạp được định nghĩa bởi các đặc tính bên dưới:
-Khơng có ý tưởng gì về ứng dụng
-Khơng biết giá trị đầu vào là hợp lệ hay không hợp lệ
-Kiểm tra ứng dụng 1 cách ngẫu nhiên và không nhận thức được điểm
bắt đầu của ứng dụng hay điểm kết thúc của luồng
-Mặc dù không nhận thức được ứng dụng nhưng chúng vẫn có thể định
nghĩa lỗi như lỗi mơi trường hay lỗi phần cứng
-Khơng có ý kiến gì nhiều về UI và chức năng
Kết quả
Lỗi báo cáo từ Monkey test địi hỏi phân tích chi tiết. Vì khơng rõ các
bước tái hiện lỗi (hầu như là vậy) nên việc khơi phục bug sẽ khó.
Tơi nghĩ kĩ thuật này nên làm ở giai đoạn sau của việc kiểm thử khi tất cả
chức năng đã được kiểm thử và đã có một chút đang tin về hiệu quả của
ứng dụng. Nếu làm nó ở giai đoạn đầu của kiểm thử, mức độ nguy hiểm
sẽ cao hơn. Nếu chúng ta đang sử dụng 1 chương trình hay kịch bản để
tạo ra đầu vào hợp lệ và không hợp lệ ngẫu nhiên thì phân tích sẽ trở lên
dễ dàng hơn.


Lợi thế của Monkey Testing
-Dễ dàng cài đặt và thực hiện

-Có thể thực hiện bởi những người “khơng q lão luyện”
-1 kĩ thuật tốt để kiểm tra độ tin tưởng của phần mềm
-Có thể phát hiện bug có ảnh hưởng lớn hơn
-Khơng tốn tiền
Bất lợi của Monkey Test
-Có thể phải mất nhiều ngày mới phát hiện ra 1 lỗi
-Số lượng lỗi ít hơn
-Việc tái hiện 1 lỗi(nếu xảy ra) trở thành 1 thử thách
-Một số lỗi có thể có đầu ra không mong muốn của kịch bản test, do vậy
việc phân tích trở nên khó khăn và mất thời gian
Ví dụ: tester áp dụng các testcase ngẫu nhiên trên hệ thống để tìm Bug
mà khơng cần xác định trước.
 Sanity testing:
Khái niệm: Sanity Test - Kiểm thử bình thường là một loại kỹ thuật
kiểm thử trong đó tester sẽ kiểm tra những chức năng mới thêm, bug đã
hoàn chỉnh trên hệ thống và tập trung vào một hoặc vài vùng mới chứ
không phải tồn bộ hệ thống.
Khất bại.
Ví dụ: hi một phiên bản vừa ra đời ta sẽ ưu tiên kiểm tra những chức
năng mà gây ra lỗi ở bản trước hoặc chức năng mới thêm ở bản hiện tại,
ta áp dụng chiến lượt Sanity test nếu phần mềm không được như mong
đợi thì từ chối nhận và đánh dấu là phiên bản này đã tPhần mềm máy
tính v.1 được tích hợp chức năng cộng: 1 + 2 = 5 => Qua phiên bản sau
v.2  lỗi khơng được fix thì => Phiên bản v.2 đã thất bại.
2) Ví dụ và áp dụng:


Hệ thống phần mềm bán dừa qua internet phiên bản 1.0 với 20 chức
năng khác nhau. Nhưng khi tạo một hóa đơn cho người mua dừa có lỗi
khơng hiển thị địa chỉ của người này.

Người chủ muốn qua phiên bản: 2.0 sẽ sửa được lỗi trên và có thể hiển
thị thêm Coupon khi tạo hóa đơn.
=> Là tester ta áp dụng kỹ thuật Sanity Test (- Đôi khi ta gọi nó chiến
lượt Sanity Test cho sang trọng.)
Khi áp dụng: ta sẽ thực hiện việc testing trên hai phần:
Một là kiểm tra lỗi khơng hiển thị địa chỉ có cịn hay khơng, hai là kiểm
tra chức năng mới thêm Coupon có được thực thi vào hay không?
Sau khi định được vùng sẽ kiểm tra, ta đưa ra những kịch bản để test cho
vùng đó. Cơ bản sẽ là:
Kịch bản 1 - Tạo hóa đơn mua dừa => Ưu tiên kiểm tra lỗi và chức năng
Coupon.
Kịch bản 2 - Người mua không có nhập địa chỉ khi mua dừa.
 A/B testing:
A/B Test (hay A/B Split Test) là một phương pháp thử nghiệm 2 phiên
bản (A và B) về giao diện hoặc cách bố trí nội dung, các nút căn chỉnh
điều hướng, vị trí đặt hình ảnh, nút mua hàng của một website bán hàng.
Mục đích cuối cùng là để kiểm tra xem khách hàng thích cách bài trí nào
hơn, đặt các nút ở vị trí nào làm tăng tỉ lệ khách hàng, thu hút nhiều lượt
xem hơn…
Khi sự thu hút khách hàng đang ngày càng bị thu hẹp trong khi sự cạnh
tranh trực tuyến đang ngày càng gay gắt. Vì vậy, các nhà làm marketing
cần phải hiểu rõ về tỉ lệ chuyển đổi tối ưu hóa (CRO).


CRO là một trong những khía cạnh quan trọng nhất của một chiến lược
tiếp thị kĩ thuật số, bởi tỉ lệ chuyển đổi là thước đo duy nhất có sự tương
quan tới tỉ lệ hoàn vốn ROI.
Ngay cả khi một khách hàng “chuyển đổi” ngay trên website của bạn
nhưng không giống như việc mua sắm hàng hóa, dịch vụ (ví dụ như
đăng kí bản tin) thì các quy tắc CRO vẫn còn áp dụng đúng.

Thật sai lầm khi nhắc đến việc thực hiện một kế hoạch CRO mà bạn lại
chỉ liên tưởng đến việc thay đổi màu sắc trên nút button, thêm bằng
chứng xã hội, hoặc rút ngắn nội dung trang web bao gồm cả
gaminification (tạm dịch là yếu tố game để tạo sự thích thú, vui nhộn)…
Một lời khuyên dành cho bạn để tối ưu hóa tỉ lệ chuyển đổi trên website
là hãy sử dụng A/B Test.
A/B test là phương pháp nhằm giúp các nhà lập trình, marketing, các
doanh nghiệp lắng nghe khách hàng tốt hơn và nhờ đó, mang lại những
trải nghiệm tuyệt vời hơn cho khách hàng của họ.
Ví dụ: Với một trang web bạn có thể A/B testing hết tồn bộ những yếu
tố nào có thể ảnh hưởng đến hành vi của người dùng như hình ảnh, tựa
đề, nội dung, call to action, form điền thông tin, v.v… Test lần lượt từng
yếu tố mà bạn cảm thấy có thể cải thiện để gia tăng conversion rate.
 Alpha testing:
Alpha testing là một dạng của acceptance testing; Thực hiện để xác định
tất cả các vấn đề/ lỗi có thể xảy ra trước khi phát hành sản phẩm đến tay
người dùng. Trọng tâm của việc kiểm thử này là để mô phỏng người
dùng thực - Real users bằng cách sử dụng các kỹ thuật Black box và
white box. Mục đích là để thực hiện các nhiệm vụ mà một người sử
dụng điển hình có thể thực hiện. Alpha testing được thực hiện trong môi
trường lab và thường các tester là nhân viên nội bộ của tổ chức, công ty.
Kiểu kiểm thử này được gọi là alpha vì nó được thực hiện sớm, gần cuối
của sự phát triển của phần mềm, và trước khi thử nghiệm beta. 


Ví dụ: chơi thử game trước khi phát hành chính thức đến mọi người.
 Beta testing:
Beta test một phần mềm được thực hiện bởi "người sử dụng thật - Real
users" trong một "môi trường thực tế - Real environment" và có thể
được coi là một hình thức acceptance testing bởi người dùng ngoài.

Phiên bản beta của phần mềm chỉ được phát hành/công bố cho một số
lượng hạn chế người dùng cuối để lấy thông tin phản hồi về chất lượng
sản phẩm. Beta test làm giảm nguy cơ thất bại của sản phẩm và tăng độ
tin tưởng vào chất lượng của nó thơng qua các ý kiến nhận xét, đánh giá
từ khách hàng. Đây là bước kiểm tra cuối cùng trước khi chuyển một
phần mềm đến tay khách hàng. Lợi thế lớn nhất của beta test là phản hồi
trực tiếp từ phía người dùng cuối, nó giúp kiểm tra phần mềm trong mơi
trường real time.
Ví dụ: mở máy chủ Beta, phát hành phiên bản trước máy chủ chính cho
người chơi có thể trải nghiệm trước phiên bản và tìm ra lỗi giúp Tester.

Lỗi hiển thị khơng tiện dụng
Ví dụ 1: lỗi giao diện màn hình đen trong game Fifa Online 3.
Ví dụ 2: lỗi hiển thị giao diện web trên Google Chrome 39.
Ví dụ 3: lỗi Flash Player dừng đột ngột trên Google Chrome.
Ví dụ 4: lỗi plugins trên Google Chrome.
Ví dụ 5: lỗi giao diện Youtube.