Slot 2 - 11/9/2023

Release notes (change log):

pointer: có thể can thiệp vô vùng RAM (con trỏ quét vùng RAM)

=====================================================
bug - mistake - error - defect - failure

***
NHẬP MÔN KIỂM THỬ PHẦN MỀM - SOFTWARE TESTING

- Kiểm thử là nghề của "thánh soi" đi tìm ra các sai sót, bất thường của App được
viết cho người dùng sử dụng. Sai sót được gọi BUG.

0. LỊCH SỬ CỦA THUẬT NGỮ "BUG"

- 1878
- 1947

I. THUẬT NGỮ "SAME SAME" NHAU: bug, defect ,mistake, error, failure -> xem cheat
sheet có 1 câu giải thích ngữ nghĩa đặt trong bối cảnh

II. ĐỊNH NGHĨA VỀ KIỂM THỬ PHẦN MỀM - KIỂM THỬ PHẦN MỀM LÀ GÌ? - WHAT IS SOFTWARE
TESTING
Đích đến của việc kiểm thử là tìm cái bug/sai, và khẳng định app ngon sẵn sàng đưa
vào sử dụng. Vậy đi tìm bug là kiểm thử, vậy làm sao khẳng định được đâu là bug,
khi nào là bug.

1. KIỂM THỬ PHẦN MỀM LÀ SO SÁNH GIỮA 2 ĐẠI LƯỢNG, 2 GIÁ TRỊ, 2 THỨ
- EXPECTED VALUE (giá trị kì vọng, giá trị cần phải đạt được)
- ACTUAL VALUE (giá trị thực tế, giá trị trả về thấy được)

- Kiểm thử phần mềm là so snahs giữa expected value và actual value
- nếu expected value == actual value -> app ngon
- nếu expected value != actual value -> BUG

VÍ DỤ: ta cần tìm app thu ngân - tính tiền bán hàng
- Tính tiền bán hàng tùy từng thời điểm có khuyến mãi. Vị trong tháng 9 này khuyến
mãi 10% cho đơn hàng trị giá từ 1 triệu đồng trở lên

- Dân dev viết code, cài luông công thức tính bill có áp dụng khuyến mãi tùy đơn
hàng

- Dân tester/QC/dân kiểm thử/dân thán soi sẽ chạy app, chạy thử tính năng tạo bill
xem nó chạy có đúng hay không, test tính nawg tính bill coi có đúng hay không? ->
nếu đúng, ok. nếu sau -> bug

-muốn test thì phải đưa data, chạy thử app với data đưa vào, xem app xử lý đúng hya
sai! SO SÁNH GIỮA EXPECTED VÀ ACTUAL VALUE

- Dân QC/tester biết rằng: NẾU ĐƯA VÀO APP CÁC MÓN HÀNG MÀ TỔNG THANH TOÁN LÀ 800K
-> KHÁCH HÀNG PHẢI TRẢ 800K, KO GIẢM -> 800K ĐƯỢC GỌI LÀ EXPECTED VALUEMAF APP PHẢI
TRẢ VỀ
THỰC TẾ NHẤN NÚT SCAN SẢN PHẨM, TIỀN BILL CỨ TĂNG THEO TÍT TÍT
NẾU KHÁCH HÀNG, TESTER DỪNG Ở 800K THÌ MÀN HÌNH TOTAL PHẢI LÀ 800K -> MÀN HÌNH CÓ
GÌ KHI CHẠY THÌ GỌI KAF ACTUAL VALUE
nếu màn hình == kì vọng khi chưa có app == 800k, app ngon

* TEST CASE 1:KIẾM THỬ tính bill với tiền mua < 1 triệu! App ko tính khuyến mãi
trong trường hợp này
- DÂN TESTER KIỂM THỬ CÂU CHUYỆN 2, TÌNH HUỐNG 2
SCAN sản phẩm, tít tít vừa đủ 1tr đồng; chẳng cần app, chỉ cần tình nhẩm, máy
casio, cũng biết được rằng khách phải trả
- Vậy 900K gọi là giá trị kì vọng, expected value mà app phải trả về khi mua 1
triệu đồng (khuyến mãi 10%)

- chờ app viết xõng, scan 1 triệu đồng, phần bill phải trả app phải ra 1 con số nào
đó - actual value
- nếu actual value lúc này là 900k == expected value của máy casio -> app ngon
- nếu actual value = bill phải trả == 1 triệu đồng RÕ RÀNG ACTUAL VALUE QUÁ KHÁC
EXPECTED ĐANG LÀ 900K -> bug xuất hiện
* TEST CASE 2: KIỂM THỬ tính bill với tiền mua == 1 triệu! app tính khuyến mãi
trong trường hợp này, trừ 10% tính bill

* CHỐT HẠ: Đ/N 1: KIỂM THỬ LÀ RUN APP CHẠY CÓ NHƯ TÍNH TOÁN DỰ KIẾN TRƯỚC HAY KHÔNG

2. KIỂM THỬ PHẦN MỀM LÀ SO SÁNH, ĐO LƯỜNG XEMM APP CÓ ĐẠT ĐƯỢC CÁC THÔNG SỐ VẬN
HÀNH, THÔNG SỐ HIỆU NĂNG, THÔNG SỐ TRẢI NGHIỆM HAY KHÔNG?
- Dân kiểm thử sẽ chạy app, đo xem chạy nhanh như thiết kế, dự định hay không, app
có chịu được 1 lượng người tải hay không ở cùng 1 thời điểm, kiểm tra xem tính dễ
dùng, tiện dụng của app có hay không? kiểm tra màu sắc, font chữ, ngữ pháp, dấu
câu... có ổn không

- VÍ DỤ: kiểm thử phần mềm còn đo thử xem nhấn 1 nút bất kì trên app, nhấn cái
dropdown (xổ ra filter/ dánh sách) thì APP ohair hồi trong vòng 3s trở lại cho bất
kì nút nhấn nào- hiệu năng sử dụng, performance
- ví dụ: không care app tính bill 10% đúng hay sai, mà chỉ quan tâm đủ 3s trở lại
hay không
-> KIỂM THỬ DẠNG TRẢI NGHIỆM APP ĐƯỢC GỌI LÀ KIỂM THỬ PHI CHỨC NĂNG NON-FUNCTIONAL
TESTING

"xử lý đúng và chạy nhanh"

Đ/N 1 Đ/N 2

* KHÔNG ĐƯỢC NHẦM LẪN VỚI NON-FUNCTIONAL REQUIREMENT TESTING -> CHŨ NÀY NẾU CÓ THÌ
NGHĨA KHÁC, THƯỜNG KHÔNG DÙNG THUẬT NGỮ NÀY

ví dụ: đo xem app chạy nhanh không từ 3s trở lại hay không -> non-functional
testing
khách hàng nói rằng: "app phải chạy nhanh , từ 1,5s trở lại"
QC/tester: câu này vớ vẩn không thể làm được loại câu này
non-functional không làm được

* Tìm ra những câu requirement vớ vẩn là 1 chuyện khác của nghề kiểm thử

-ví dụ: kiểm thử xem mã màu của các nút nhấn có đúng như thiết kế, bảng màu hay
không -> non-functional testing

3. KIẾM THỬ PHẦN MỀM CÒN LÀ SO SÁNH, ĐỐI CHIẾU, KIỂM TRA XEM APP CÓ ĐƯƠC CÀI ĐẶT,
HIỆN THỰC ĐÚNG NHƯ ĐÃ HỨA HAY KHÔNG; HỨA GÌ VỚI KHÁCH HÀNG, HỨA APP CÓ BAO NHIÊU
TÍNH NANGWTHIF PHẢI CÀI CHO ĐỦ (CHƯA CẦN BIẾT CHẠY ĐÚNG SAI - ĐÚNG SAI NẰM Ở 1, 2)
- VÍ DỤ: app cần login = phone, gmail, có làm chưa
- app hỗ trợ thanh toán qua momo, moca, cod, có làm chưa

- trong việc làm phần mềm, có 1 tài liệu liệt kê các tính năng của phần mềm sẽ làm,
tài liệu hứa sẽ làm tính năng gì, tài liệu gì, tài liệu này gọi tên là Software
Requirements Specification (SRS)
Bản đặc tả yêu cầu phần mềm

(nói theo nhà FU, mục III, của cuốn khóa luận tốt nghiệp - Capstone Project ở kì 9,
SWR302 luôn)

------------
CHỐT HẠ: DÙ KIỂM THỬ CÓ NHIỀU ĐỊNH NGHĨA NHƯNG CUỐI CÙNG ĐỀU LÀ:
- SO SÁNH GIỮA CẶP GÍ TRỊ: EXPECTED VALUE VS ACTUAL VALUE
- SO SÁNH GIỮA CÁC KÌ VỌNG APP PHẢI LÀ VÀ THỰC TẾ APP ĐEM LẠI CÁI GÌ
NẾU 2 CÁI == NHAU, NGON
NẾU 2 CÁI != NHAU, BUG
-----
SLOT 3 - SWT301
III. AI THAM GIA VÀO QUÁ TRÌNH KIỂM THỬ, AI LÀM THÁNH SOI, AI THAM GIA VÀO VIỆC ĐẢM
BẢO CHẤT LƯỢNG PHẦN MỀM
1. Developer

2. Tester/QC - Quality control !!!! chạy app tìm debug!!!

[NGOẠI TRUYỆN] thông tin tuyển dụng: tuyển QA/QC (Quality Assurance)

3. QC MANAGER

4. USER/END-USER - NGƯỜI DÙNG CUỐI

------------------------------------------------------
1. DEVELOPER
* CÔNG VIỆC CỦA DEVELOPER gồm
- Viết code, áp dụng thuật toán để cài code sau [nút nhấn]
- Viết code có chất lượng
- Làm sao đảm bảo được code có chất lượng - dev phải có trách nhiệm test code của
chính mình viết ra! test code của mình

* Cách để code có chất lượng - kĩ thuật kiểm thử code

- mỗi hàm/method, mỗi class mà dev viết ra đều phải được test, test tức là đưa data
vào hàm, gọi hàm chờ hàm xử lí, xem kết quả trả về của hàm có như dự kiến hay
không/mong đợi hay không?
- Nhớ rằng đơn vị code nhỏ nhất có ý nghĩa trong dự án phần mềm là hàm/class (các
câu lệnh khai báo biến, vòng lặp, try-catch... không phải là đơn vị code nhỏ nhất),
hàm/class còn được gọi là unit of code
- vậy cái việc mà dev phải test code/hàm/class mà họ viết ra thì được gọi là unit
test/unit testing
* làm sao để test 1 hàm/test class?
có nhiều cách để test 1 hàm/class
- C1: gọi hàm với dât đưa vào, in kết quả xử lí của hàm ra màn hình và nhìn =
mắt để đối chiếu xem kết quả trả về của hàm (actual) có == kết quả tính ra = tay
của mình hay không?
System.out.println(hàmCầnTest());

- C2: gọi hàm với đưa data đưa vào in kết quả xử lý ra 1 tệp tin gọi là log
file, sau đó xem kết quả (actual) đối chiếu với excepted
2 cách 1,2 là cách truyền thống, dễ làm, nhưng tốn công luận kết quả đúng sai
= mắt, có thể gây ra sai sót luôn
- C3: (fix C1, C2) mắt người dev không cần phải đi so sánh từng cặp expected
vs actual nữa! máy tự làm, code tự làm

* làm sao chơi với C3:

- Ta phải dùng thêm những thư viện/framework bên ngoài để hỗ trợ cho việc test
hàm/class đúng sai!
- Những thư viện/fw này được gọi là: unit testing framework dùng để test code của
mình-dev

Jasmine, Mocha, Jest.... --> JS

xUnit, NUnit, MS Test,.... --> C# keyword:"Unit test framework for <NNLT>"
JUnit, TestNG... --> Java

"Màu xanh đỏ đèn đường"

- mấy tool ở trên hay ở chỗ nó góp phần vào câu chuyện tự động hóa quy trình kiểm
tra code và phối hợp với quy trình deploy sản phẩm
nghĩa là bạn đưa code lên server, server tự chạy bộ kiểm thử Unit test
check xem code ngon hay không, nếu ngon, đóng gói code thành app đem lên server
khác để sẵn sàng cho việc test app, cho dùng thật từ k/h quy trình tự động hóa quá
trình quản lý code/quản lý test/ quản lý deploy được gọi chung 1 cái tên là:

Unit Test -> CI/CD/DevOps (chứng chỉ, job title, lương 2k trở lên)

2. Tester/QC - Quality control !!!! chạy app tìm debug!!!

* nhiệm vụ của dân Tester/QC:
- tìm bug ở app, tức là xem các chức năng chạy đúng không, expected == actual?
- kiểm tra xem app có đạt hiệu năng kì vọng hay không, trải nghiệm ổn không?
- kiểm tra, xác nhận xem app có làm đúng như đã hứa hay không
QC/Tester là chạy vào app, test app, ko test code

* QC/Tester kiểm thử thế nào

- QC/Tester chuẩn bị sẵn bộ data để đưa vào app
mở app lên, click vào chức năng/màn hình muốn test
gõ data đã chuẩn bị vào trang màn hình
click dropdown, checkbox, radio button nếu cần
nếu nút [xử lý] gì đó, chờ app chạy trong vòng 3s
xem kết quả trả về sau khi click nút nhấn
dùng mắt đọc kết quả trả về (actual) so sánh coi kết quả trả về
có == kết quả chuẩn bị trước đó hay không -
nếu == thì app ngon
nếu != thì app bị bug
bộ data chuẩn bị sẵn để test app đúng sai được gọi là test case - tình
huống kiểm thử, tình huống xài app để check T/F
ví dụ: muốn test cái app Calculator huyền thoại Windows
test cái chức năng chuyển đổi hệ cơ số 10 -> 2, 8, 16
ta chuẩn bị bộ data để verify tính năng
mỗi bộ data là 1 test case
test case 1: đưa con số 15 vào app, thì app phải trả về chữ F (hệ 16)
expected

test case 2: đưa vào con số 250, thì app phải trả về chữ FA (hệ 16)

[đề thi PE môn này viết khoảng 20 test case]

- cách mà tester chuẩn bị data/test case, sau đó mở app, input, click, đọc kết quả,
luận đúng sai hoàn toàn dùng sức trâu bò, thủ công
kĩ thuật kiểm thử thủ công để biết 1 app đún sai gọi là manual, testing
(cách làm truyền thống)
- có 1 kĩ thuật mới, kĩ thuật hiện đại giúp toàn bộ thao tác làm = tay ở trên tự
động luôn, tức là có cách để app tự mở lên, tự gõ info vào, tự click chọn tự nhấn
nút, tự mở trang khác, tự bắt message kết quả, tự so sánh với expected luôn, tự
động hết, kĩ thuật kiểm thử này gọi là

test authoumation/automated testing, testing automation

* how do they do that, làm sao làm được cái trò test tự động, app chạy như ma nhập
- dân kiểm thử phải lập trình để điều khiển app(không lập trình tạo app như dev)
lập trình điều khiển chuột, ô nhập, click,..
- dân kiểm thử lập trình xài đồ chơi, công cụ phụ trợ, thư viên phụ trợ
có 2 loại đồ chơi để làm app chạy như ma nhập
- TOOL BÊN NGOÀI, TRÊN INTERNET (FREE/$) GIÚP RECORD TOÀN BỘ THAO TÁC "MÔI,
Làm = TAY CỦA TESTER, NHẬP DATA, CHUYỂN TRANG, CHỌN BUTTON, CHECKBOX, NHẤN NÚT,
VERIFY VỚI EXPECTED, TOOL GHI LẠI HẾT CÁC THAO TÁC SAU ĐÓ KHI CẦN TEST LẠI, TA
PLAY-BACK"
RECORD/PLAY-BACK LÀ THUẬT NGỮ CỦA LOẠI TOOL NÀY

TÊN TOOL: KATALON (KMS), AKA AT/AKA TEST (FSOFT), RANOREX, TEST COMPLETE,
TELERIK,..

- DÂN QC /TESTER DÙNG CÁC BỘ THƯ VIỆN ĐỂ ĐIỀU KHIỂN APP, VIẾT CODE DÙNG THƯ
VIỆN NÀY ĐỂ IMPLETEMENT CÁC TEST CASE, NGHĨA LÀ VIẾT CÁC ĐOẠN CODE LẬP TRÌNH ĐỂ TỬ
ĐỘNG MỞ APP, CLICK CHUỘT, INPUT,...

ĐOẠN CODE NÀY DÙNG CÁC THỬ VIỆN ĐỂ ĐIỀU KHIỂN APP THÌ ĐOẠN CODE NÀY ĐƯỢC GỌI
LÀ TEST SCRIPT
THƯ VIỆN NỔI TIẾNG GIÚP TỰ ĐỘNG HÓA VIỆC KIỂM THỬ KHIẾN APP CHẠY NHƯ MA NHẬP
LÀ SELENIUM, APPIUM, CYPRESS...

* HỆ QUẢ: MẤY CÁI THƯ VIỆN NÀY GIÚP LÀM THÊM VIỆC: VIẾT TOOL, CÀY VIEW, CÀO
DATA TỪ WEB VỀ MÁY TÍNH, VỀ DATABASE CỦA MÌNH, TOOL CÀI DATA LÀ: CRAWL/CRAWLER BOT

* TOOL RECORD/PLAYBACK NÓ CÓ 1 CƠ CHẾ LÀ RECORD XONG PLAY LẠI EXPORT TOÀN BỘ

KỊCH BẢN RECORD THÀNH CODE ĐỂ QC ĐỘ LẠI

* CHỐT HẠ:
- CÔNG VIỆC CỦA QC:
- TẠO TEST CASE (BỘ DATA KIỂM THỬ, EXPECTED VALUE, STEP ĐỂ KIỂM THỬ, NHẬP
INFO)
- TẠO TEST SCRIPT (VIẾT CODE ĐỂ TỰ ĐỘNG THỰC THI CÁC TEST CASE)
- THỰC THI TEST CASE -> GỌI LÀ TEST RUN -> ĐI TÌM BUG HOY
===================================================================================
===================================================================================
==================
Slot 4 - SWT301

[NGOẠI TRUYỆN] thông tin tuyển dụng: tuyển QA/QC (Quality Assurance)
* NHIỆM VỤ CỦA QA
- Không sờ trực tiếp vào app để tìm bug (QC/TESTER đi tìm bug), MÀ ĐI VÒNG VÒNG
CÔNG TY, NGÓ VÀO CÁC PHÒNG BAN, KỂ CẢ PHÒNG PHÁT TRIỂN PHẦN MỀM, NGÓ VÀO CẢ DỰ ÁN
MÌNH ĐANG LÀM THANH TRA, KIỂM TRA XEM CÁC PHÒNG BAN, CÁC DỰ ÁN CÓ LÀM ĐÚNG NHƯ CAM
KẾT, CÓ TUÂN THEO QUY ĐỊNH TRÌNH CHẤT LƯỢNG ĐÃ CAM KẾT HAY KHÔNG

- ĐỨNG NGOÀI TẤT CẢ, KIỂM TRA SỰ TUÂN THỦ CỦA CÁC PHÒNG BAN, CỦA DEV TEAM
- NẾU THẤY SAI SÓT, KO NHÀO VÀO SỬA, MÀ ĐI MÉC SẾP, LÃNH ĐẠO
(~~~ thầy giám thị, đội cờ đỏ của trường, giám thị hành lang)

- VÍ DỤ:
- DEV TEAM LÀM DỰ ÁN, CHỌN SCRUM LÀM PHƯƠNG PHÁP PHÁT TRIỂN PHẦN MỀM
QUY TẮC LÀM SCRUM CƠ BẢN CÓ NHỮNG ĐIỀU SAU
1. Dự án chia thành các khoảng thời gian đều nhau, trung bình 2 tuần
2. Mỗi 2 tuần phải demo sản phẩm/run được cho khách hàng, demo vào thứ 6 tuần
thứ 2
3. Toàn bộ requirements/tính năng hứa làm này gọi là USER STORY, lưu trữ ở 1
nơi gọi là BACKLOG, ví dụ lưu ở JIRA, TRELLO, NOTTION...
 4. BUG lưu ở 1 nơi, gọi là BUG DATABASE,ví dụ BUG ZILLA, JIRA
5. Cuối mỗi tuần thứ 2 của sprint, họp demo với khách hàng, ghi nhận
feedback, deal với khách hàng về các tính năng thứ phát sinh thêm, hay thứ cần
chỉnh sửa, và phải ghi biên bản làm việc rõ ràng
6. CUOIS BUỔI DEMO (TUẦN 2 MỖI SPRINT) CÓ 1 CUỘC HỌP KHÁC TRONG NỘI BỘ TEAM
GỌI LÀ RETROSPECTIVE - HỌP CHIA SẺ CẢM XÚC VÀ KINH NGHIỆM VÀ BÀI HỌC TRONG 2 TUẦN
BIÊN BẢN GHI NHẬN
7. MỖI NGÀY 2 3 4 5 6 BUỔI SÁNG ĐẦU GIỜ HỌP ĐỨNG VÀ NHANH TRONG VÒNG 15P
MỖI THÀNH VIÊN NÓI ĐÚNG 3 CÂU:
- HÔM QUA BẠN ĐÃ LÀM GÌ?
- HÔM NAY SẼ LÀM GÌ?
- BẠN ĐANG GẶP VẤN ĐỀ GÌ?
PHIÊN HỌP NÀY GỌI LÀ DAILY STANDUP MEETING

- QA LÂU LÂU GHÉ HỎI THĂM: 4 TUẦN TRÔI QUA RỒI, TUI MUỐN XEM 2 BIÊN BẢN LÀM VIỆC
VỚI KHÁCH HÀNG? CÓ ĐỦ 2 BIÊN BẢN CHƯA? CHƯA THÌ ĐI MÉC, CÓ, CHẢ QUAN TÂM NỘI DUNG

- QA LÀ CÁNH TAY NỐI DÀI CỦA CÁC SẾP ĐỂ KIỂM SOÁT TÍNH TUÂN THỦ KỈ LUẬT, QUY TRÌNH
CỦA CÁC NHÓM, PHÒNG BAN TRONG CÔNG TY VỚI Ý NGHĨA SAU LÀ:
- MỌI VIỆC THEO ĐÚNG KẾ HOẠCH, QUY TRÌNH, ĐỘI NGŨ CHUYÊN NGHIỆP, HY VỌNG SẢN
PHẨM CÓ CHẤT LƯỢNG, MỌI THỨ ĐỀU CÓ VĂN BẢN GIẤY TỜ LÀM BẰNG CHỨNG, SAU NÀY DỄ NÓI
CHUYỆN DỄ TÌM NGUYÊN NHÂN, ĐỂ CẢI TIẾN

- QA LÀ DÂN CHƠI VỚI CÁC BỘ TIÊU CHUẨN CHẤT LƯỢNG: ISO, CMMI
- HỌ LÀ NGƯỜI CÙNG VỚI CÁC SẾP ĐƯA RA CÁC TIÊU CHUẨN, QUY TRÌNH, CÁC MẪU BÁO
CÁO/REPORT TRONG CÔNG TY ĐỂ THEO DÕI ĐƯỢC MỌI THỨ ĐANG DIỄN RA TRONG CÔNG TY, PHÒNG
BAN, PROJECT

4. USER/ END-USER - NGƯỜI CUỐI CÙNG THAM GIA VÀO CÂU CHUYỆN ĐẢM BẢO CHẤT LƯỢNG PHẦN
MỀM

- TẠI SAO LẠI CÓ CHỮ END TRONG END-USER?

- FRONT-END, BACK-END??
===================================================================================
==============================================================
* SLOT 5 - SWT301

tui ------> browser ---> lazada.vn ----> internet --> server <....> xử lí <----->
DB
bạn ------> browser ---> shopee.vn ----> internet --> server
IP
IIS/Tomcat
nginx...
app của mình
------------------------click-------------------------------------------DB>|
END
Tui/Bạn <--------------------------------------------------------------
|<END
------------------------------------>---------XỬ LÝ-------------------
ĐỂ TRẢ VỀ CHO END-USER
HẬU TRƯỜNG USER KHÔNG THẤY BACK-END
BROWSER<-----------------------------------------
BACK-END XỬ LÝ XONG TRẢ VỀ TRÌNH DUYỆT
TRÌNH DUYỆT TRƯỚC MẶT MÌNH, ĐẾN TRÌNH DUYỆT LÀ DỪNG
FRONT-END: THÔNG TIN VỀ ĐẾN MẶT MÌNH QUA MÀN HÌNH TRÌNH DUYỆT
LẬP TRÌNH BÀY INFO
CHO ĐẸP
FRONT-END DEVELOPMENT BACK-END DEV
FULL-STACK DEV
END-USER: THÔNG TIN TỪ APP TRẢ VỀ ĐẾN MÌNH LÀ CÙNG ĐƯỜNG, HẺM CỤT RỒI, HẾT ĐI ĐÂU
ĐƯỢC NỮA TUI LÀ NGƯỜI CUỐI CÙNG HỨNG THÔNG TIN TỪ APP

DB TUI CŨNG LÀ NGƯỜI CUỐI CÙNG HỨNG INFO TỪ APP, TỪ USER - END

END LÀ KẾT THÚC CỦA CÁI GÌ ĐÓ, 1 HÀNH TRÌNH INFO CHẠY LÊN

* CÓ NHIỀU CÁCH PHÂN LOẠI PHẦN MỀM, TÙY THEO TIÊU CHÍ PHÂN LOẠI
** PHÂN LOẠI PHẦN MỀM THEO PLATFORM (PHẦN CỨNG + OS + APP PHỤ TRỢ CHO VIỆC CHẠY APP
MÌNH): IOS, ANDROID, LINUX, WINDOWS, MACOS...

** PHÂN LOẠI THEO MỤC ĐÍCH SỬ DỤNG, THEO LOẠI USER/END-USER THÌ TA CHIA PHẦN MỀM
THÀNH 2 LOẠI CHÍNH (CÓ THẾ CÓ PHẦN MỀM RƠI VÀO 2 LOẠI LUÔN)
> GENERIC APP - APP PHỔ THÔNG, APP ĐẠI CƯƠNG, APP HƯỚNG ĐẾN SỐ DÒNG NGƯỜI DÙNG
>VÍ DỤ: GAME, TOOLS: BROWSER, DOWNLOAD, NÉN/XẢ, XỬ LÝ ẢNH /DỰNG PHIM
VĂN PHÒNG: W, P, E, MAIL
> Đặc trưng: thường sẽ có nút download, đăng kí login dùng thử
hướng đến nhà nhà người người xài app - nhu cầu phổ thông nhiều
người cần

CÔNG TY LÀM RA APP GENERIC, THƯỜNG SẼ CÓ NHIỀU PHIÊN BẢN DOWNLOAD,

NHIỀU PHIÊN BẢN APP CHO USER SỬ DỤNG, SỬ DỤNG SỚM
PHIÊN BẢN APP CHO USER SỬ DỤNG, SỬ DỤNG SỚM
MỤC TIÊU CỦA VIỆC CHO SỬ DỤNG, CHO DOWNLOAD, CHO SỬ DỤNG SỚM ĐỂ
- TĂNG TẾP KHÁCH HÀNG, TĂNG CƠ HỘI BÁN ĐƯỢC APP
- NHIỀU NGƯỜI DÙNG, SẼ CÓ NHIỀU FEEDBACK, NHIỀU BUG ĐƯỢC REPORT, THU
NHẬP NHIỀU CMT GỠ RỐI TRÊN CÁC FORUM, MXH
CÁC VERSION KHÁC NHAU CỦA P/M ĐỂ TĂNG DỘ TRẢI NGHIỆM VÀ TÌM BUG
- NIGHTLY BUILD (version nhiều lỗi, nhưng phong phú tính năng thử
nghiệm)
- alpha, beta, insider review, preview, RC(Release Candidate), trial, $
-> full tính năng stable, LTS, PRO, ENTERPRISE COMMUNITY(free $, giới hạn 1 số tính
năng), OPENSOURCE(free $, free source)

NGƯỜI DÙNG TRÊN MẠNG DÙNG THỬ -> RA BUG, RA FEEDBACK, RA REPORT
-> USER/END-USER ĐÃ ĐÓNG VAI TRÒ QC/TESTER
----------------
> CUSTOMIZED APP, BESPOKE APP: HÀNG ĐỘ, HÀNG THỬA RIÊNG, HÀNG LÀM THEO ĐẶT HÀNG,
DÙNG CHO MỤC ĐÍCH CHUYÊN BIỆT CỦA TỔ CHỨC/ ĐƠN VỊ/ CÔNG TY MUỐN CÓ APP
> VÍ DỤ: APP thu ngân/tính tiền của GS25, 7-Eleven, Tocotoco,
App chuyển tiền của TPBank, ACB, Vietcombank
App quản lý ngân hàng cả ACB, TPBank
App quản lý bệnh viện của BVCR, BV115
App quản lý kho của Hòa Phát, Tân Hiệp Phát
> Đặc trưng: rất thường không có nút download, mà thường chỉ có video demo để
PR năng lực công ty làm app
hướng đến 1 tập user hữu hạn, dùng cho công việc của doanh
nghiệp: bv, nhà hàng, quán ăn, khách sạn, công ty sản xuất, công ty dịch vụ
tổ chức: trường, viện, trung
tâm, hội nhóm
doanh nghiệp hoạt động theo quy tắc kinh doanh riêng, app phải
riêng!

CÔNG TY LÀM APP, LÀM XONG, CÀI ĐẶT LÊN SERVER CÔNG TY ĐẶT
HÀNG(SERVER TGDD, BV CR, HÒA PH) CÓ THỂ CÀI THÊM TRÊN MÁY CỦA NHÂN VIÊN CÔNG TY ĐẶT
HÀNG
VÍ DỤ: APP QUẢN LÝ KHO CỦA HÒA PHÁT, THÌ MÌNH CÔNG TY P/M PHẢI
CÀI APP CHO MÁY CỦA THỦ KHO CỦA HOÀ PHÁT DÙNG
APP QUẢN LÝ NGÂN HÀNG: MỞ TK CHO KHÁCH HÀNG CỦA NGÂN HÀNG GHI
NHẬN KHOẢN VAY CỦA K/H CỦA NGÂN HÀNG

NHÂN VIÊN CỦA CÔNG TY ĐẶT HÀNG LÀM APP SẼ LÀ END-USER DÙNG THỬ APP MÌNH VIẾT CHO HỌ
COI ÁP CÓ ỔN KHÔNG CÓ DÙNG ĐƯỢC TRONG HOẠT ĐỘNG CỦA CÔNG TY HAY KHÔNG
- NHÂN VIÊN HÒA PHÁT NÓI RẰNG APP NGON, DÙNG ĐƯỢC
- NHÂN VIÊN KHO CỦA TGDD, BÁC SĨ CỦA CHỢ RẪY NÓI RẰNG APP DÙNG KHÓ QUÁ

MÌNH LÀ CÔNG TY PHẦN MỀM CUNG CẤP APP CHO HỌ NGHE, GHI CHÉP, VỀ NHÀ FIX, SỬA NGAY
CHO HỌ THỬ TIẾP

NẾU LÀ APP CHUYỂN TIỀN CỦA NGÂN HÀN, THÌ NV NGÂN HÀNG CÒN GIẢ BỘ ĐÓNG VAI NGƯỜI
CHUYỂN TIỀN RÚT TIỀN ĐỂ TEST XEM APP CÓ ỔN KHÔNG VỚI KHÁCH HÀNG CỦA NGÂN HÀNG KHI
SAU NÀY HỌ TRẢI NGHIỆM APP CHUYỂN TIỀN

NÓI CHUNG NHÂN VIÊN CÔNG TY ĐẶT HÀNG LÀM APP SẼ LÀ END-USER DÙNG THỬ APP ĐỂ XEM ỔN
KHÔNG

* CHỐT HẠ: DÙ APP LOẠI NÀO THÌ CŨNG CẦN NGƯỜI DÙNG DÙNG THỬ
NGƯỜI DÙNG CÓ THỂ LÀ BẤT KỲ AI CHO APP GENERIC
NGƯỜI DÙNG LÀ NHÂN VIÊN CỦA CÔNG TY ĐẶT HÀNG LÀM APP RIÊNG CHO HỌ (CUSTOMIZE,
BESPOKE )

HÀNH ĐỘNG DÙNG THỬ ĐỂ TÌM BUG, FEEDBACK, GỢI Ý, CMT, CÀM RÀM CHÍNH LÀ HÀNH
ĐỘNG ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM
VIỆC NGƯỜI DÙNG CUỐI THAM GIA VÀO KIẾM THỬ (CHỦ ĐỘNG, BỊ ÉP TỰ NGUYỆN) GỌI LÀ

UAT - USER ACCEPTANCE TESTING - KIỂM THỬ CHẤP NHẬN, KIỂM THỬ NGHIỆM THU SẢN
PHẨM
======================================
IV. 7 VIÊN NGỌC RỒNG

--------------------
[NGOẠI TRUYỆN] - VÀI CON SỐ ĐÁNG NHỚ
* OOP: 4 + 5
* AGILE: 4 (MAMIFETO)
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
* DB: 3 DANG CHUẨN (NF),
3 LOẠI SQL: DDL (create/drop/alter), DML (select, update, delete), DCL
(grant, revoke)
5 LOẠI JOIN: INNER JOIN, LEFT, RIGHT, FULL, TÍCH ĐỀ CÁC - CARTESIAN PRODUCT
* SWR: 3 GÓC NHÌN: WHY, WHAT, WHO
* SWT: 7 VIÊN NGỌC RỒNG!!
* ARCHITECTURAL VIEW: 4 + 1 VIEW MODEL
===================================================================================
===================================================================================
====================
SLOT 6 - SWT301
7 VIÊN NGỌC RỒNG - 7 NGUYÊN LÝ CỦA VIỆC KIỂM THỬ - 7 PRINCIPLES OF SOFTWARE TESTING
- đây là những câu phát biểu danh cho dân kiểm thử phần mềm, dân QC/Tester mang ý
nghĩa
Định Hướng, Chỉ Hướng , Chỉ Dẫn những nguyên tắc
là kim chỉ nam châm dẫn lỗi đi

NHỚ NÓ, DÂN QC BIẾT NÊN LÀM GÌ, LÀM NHƯ THẾ NÀO 1 CÁCH TỔNG QUÁT NHẤT KHI TEST
PHẦN MỀM GIỐNG 4 NGUYÊN LÝ OOP SẼ CHỈ DẪN TƯ DUY VỀ LÀM APP THEO STYLE OOP/CLASS
OBJECT
** NL1: TESTING SHOWS PRESENCE OF DEFECTS
- KIỂM THỬ LÀ HOẠT ĐỘNG LIÊN QUAN ĐẾN ĐẢM BẢO PHẦN MỀM CÓ CHẤT LƯỢNG - "KHÔNG CÓ
BUG" (CHÚ Ý NGOẶC KÉP)

- KIỂM THỬ PHẦN MỀM LÀ ĐI TÌM BUG, ĐI TÌM CẰNG NHIỀU BUG CÀNG TỐT, TÌM ĐƯỢC CÀNG
NHIỀU BUG NGHIÊM TRỌNG CÀNG TỐT(BUG NHIỀU LẮM HẢ)

- KIỂM THỬ PHẦN MỀM KHÔNG CÓ NGHĨA VỤ, (KHÔNG VÌ MỤC ĐÍCH) CHỨNG MINH RẰNG APP ĐÃ
HẾT BUG RỒI
- KIỂM THỬ PHẦN MỀM KHÔNG PHẢI LÀ ĐI TÌM HẾT BUG VÀ GÂY RẰNG APP HẾT BUG RỒI, VÌ
ĐIỀU NÀY LÀ KHÔNG TƯỞNG
- APP LUÔN CÓ BUG, LUÔN TỒN TẠI BUG, BẤT CHẤT ĐÃ DÀNH THỜI GIAN TEST KĨ CỠ
NÀO
- CHÂN LÝ: APP LUÔN CÒN CÓ BUG - NÓI VUI: BUG LÀ 1 TÍNH NĂNG
CÂU HỎI: TẠI SAO APP LUÔN CÓ BUG? VÌ APP VỐN PHỨC TẠP , ĐƯỢC TẠO THÀNH TỰ
NHIÊN THÀNH TỐ, THÀNH PHẦN KHÁC NHAU!! KHI CÓ NHIỀU THÀNH PHẦN CHUNG VỚI NHAU -> SẼ
PHÁT SINH VẤN ĐỀ VÌ SỰ KHÁC BIỆT VÀ BẤT ĐỒNG BỘ
LÚC NÀO ĐÓ

- APP LUÔN CÒN BUG NHƯNG KHONG ĐỒNG NGHĨA VỚI VIỆC DÂN QC CHÚNG TA CẨU THẢ TRONG
VIỆC KIỂM THỬ
- DÂN QC PHẢI NỖ LỰC TÌM CÁC BUG, BUG CÒN TIỀM ẨN, VÌ: ĐẠO ĐƯC NGHỀ NGHIỆP, CAM KẾT
CHẤT LƯỢNG VỚI KHÁC HÀNG CỦA CÔNG TY MÀ MÌNH ĐANG LÀM THUÊ

- KHÔNG PHẢI LÀ CỨU RỖI, MÀ LÀ NÂNG CAO TRÁCH NHIỆM, VÌ BUG LUÔN CÒN ĐÓ!!

** NL2: EXHAUSTIVE TESTING IS NOT POSSIBLE/IS IMPOSSIBLE

- vắt kiệt
ép xung, đẩy tới hạn
hết sức bình sinh
VÉT CẠN
- KHÔNG THỂ TEST HẾT CÁC TÌNH HUỐNG XÀI APP CỦA USER
- KHÔNG THEERE TESST HẾT CÁC TEST CASE CHO 1 CÁI APP
- SỐ TỔ HỢP CÁC TÍNH HUỐNG XÀI APP CỦA USER VỚI BỘ DATA NÀO ĐÓ LÀ VÔ SỐ KỂ
- GIẢ SỬ THIẾT KẾ ĐỦ (VÉT CẠN) TẤT CẢ CÁC TEST CASE CÓ THỂ CÓ CỦA 1 APP, CŨNG KHÔNG
ĐỦ THỜI GIAN ĐỂ THỰC THI CÁC TEST CASE

Ví dụ: Kiểm thử tình năng + 2 con số của phần mềm calculator huyền thoại
- Kiểm thử ta thiết kế Test case: Bộ data đưa vào (input) app để tun 1 tính
năng đi kèm theo là expected value sau đó ta run cái test case này để xem trả ra kq
có như kì vọng hay không (test run,)
+ 2 con số, ta có vài test case như sau:
TC1: 0 + 0 -> 0?
0 + 1 -> 1?
0 + 2 -> 2?
0 + TRÀN MIỀN GIÁ TRỊ - BONDARY
+ VỚI SỐ ÂM
+ VỚI SỐ THỰC, THỰC + THỰC, THỰC + NGUYÊN, CÓ BIÊN
+ VỚI + - * / DẤU NGOẶC ()
SỐ TỔ HỢP CÁC BỘ DATA/TEST CASE DÀNH CHO 1 CHỨC NĂNG LÀ VÔ SỐ
TA KHÔNG ĐỦ SỨC, KHÔNG ĐỦ THỜI GIAN ĐỂ TEST HẾT CÁC TỔ HỢP SỬ DỤNG TÍNH
NĂNG,CÁC MÀN HÌNH

KHÔNG ĐỦ SỨC TEST HẾT, LÀM SAO DÁM KẾT LUẬN APP ỔN ÁP??

PHẢI DÙNG CÁC TECHNIQUES, KĨ THUẬT ĐỂ THIẾT KẾ VỪA ĐỦ CÁC TESTCASE MÀ

VẪN BAO QUÁT ĐỰƠC CÁC TÌNH HUỐNG XÀI APP
CÁC KỸ THUẬT NÀY XUẤT HIỆN TRONG CÂY BẢN ĐỒ TƯ DUY MỤC 5. TESTING
TECHNIQUES VÀ XUẤT HIỆN TRONG ĐÈ THI PE

> KHÔNG TEST HẾT ĐƯỢC CÁC TÌNH HUỐNG, VẬY CẦN CÓ CHIẾN LƯỢC THIẾT KẾ CÁC TÌNH HUỐNG
CHO ĐỦ TỐT
> CÓ THỂ VÌ KHÔNG TEST ĐƯỢC HẾT, NÓ GÓP 1 PHẦN VÀO NGUYÊN LÝ: APP LUÔN CÓ BUG

** NL3: EARLY TESTING - KIỂM THỬ CÀNG SỚM CÀNG TỐT, KIỂM THỬ THẬM CHÍ ĐƯỢC TIẾN
HÀNH KHI CHƯA VIẾT 1 DÒNG CODE NÀO CHO APP, KIỂM THỬ ĐƯỢC ÁP DỤNG, TIẾN HÀNH NGAY
KHI Ở GIAI ĐOẠN DẦU TIÊN CỦA DỰ ÁN, KIEEMRE THỬ NÊN THAM GIA NGAY TỪ GIAI ĐOẠN
REQUIREMENTS, DESIGN, THAY VÌ PHẢI CHỜ ĐẾN KHI CÓ CODE/APP 1 KIỂM THỬ
LÍ DO KIỂM THỬ SỚM LÀ: TỪ REQS ĐÃ CÓ THỂ BỊ SAI, TỪ DESIGN ĐÃ CÓ THỂ BỊ SAI, PHÁT
HIỆN SAI TỪ SỚM, SAUWR APP ĐỠ TỐN KÉM HƠN LÀ UI ĐÃ LÊN, API ĐÃ XONG DATABASE CŨNG
ĐÃ ỔN, VIỆC THÊM BỚT CHỈNH SỬA TRONG CODE SẼ TỐN KÉM

CÁC SV ĐI HỎI THẦY CÔ VỀ REQS, DB, UI, CHÍNH LÀ EARLY TESTING

CÁC THẦY CÔ ĐI CHẤM REVIEW CAPSTONE PROJECT CHÍNH LÀ EARLY TESTING

DÂN KIỂM THỬ THAM GIA VÀO CÙNG VỚI BA, ĐỌC CÁI DOCUMENT VỀ APP MÀ BA VIẾT RA TRONG
DOCUMENT CÓ HỨA HẸN VỀ TÍNH NĂNG, MÀN HÌNH, XỬ LÝ CỦA TÍNH NĂNG CẢU CÁI APP SẼ ĐANG
LÀM

ĐỌC/REVIEW DOCUMENT ĐỂ TÌM RA SAI SÓT, THIẾU HỤT SẼ GIÚP REQS TỐT VÀ CHÍNH XÁC ĐỂ
LÀM HÀI LONG KHÁCH HÀNG
PHÍ TỔN THẤT SỬA APP/CODE KHI ĐÃ ĐI ĐẾN DIADNJ CODE RẤT CAO, SO VỚI VIỆC CHƯA VIẾT
CODE MỚI HỨA HẸN TÍNH NĂNG, MỚI PHÁC THẢO DATABASE

CÓ CÂU "56%" VÀ "82%" TRONG MÔN SWR302

DÂN QC SẼ ĐƯỢC QC MANAGER/VÀ PM PHÂN CÔNG CÙNG THAM DỰ QUÁ TRÌNH LÀM DỰ ÁN TỪ SỚM
ĐỂ
- HIỂU APP
- HIỂU TÍNH NĂNG ĐANG LÀM (DÂN DEV KHÔNG HIỂU APP = DÂN QC/BA, DO
LÀM THEO)
- THIẾT KẾ TEST CASE TỪ SỚM MODULE, DÂN QC LÀM VIỆC VỚI FULL APP)
DÂN QC SẼ ĐỌC CUỐN TÀI LIỆU MÀ DÂN BA VIẾT RA ĐỂ HIỂU APP, VÀ LÀM TEST CASE TỪ CÁC
REQS CÓ TRONG CUỐN TÀI LIỆU VỪA TIẾP CẬN

LÀM PHẦN MỀM, CUỐN DOCUMENT ĐẦU TIÊN LÀ CUỐN XUẤT HIỆN DƯỚI VAI TRÒ CỦA BA VIẾT RA
CUỐN NÀY GHI NHẬN HẾT LỜI HỨA VỀ TÍNH NĂNG PHẦN MỀM SẼ LÀM
CUỐN NÀY GỌI LÀ: SOFTWARE REQUIREMENTS SPECIFICATION - SRS
BẢN ĐẶC TẢ YÊU CẦU PHẦN MỀM
VỚI KHÓA LUẬN TỐT NGHIỆP TRƯỜNG 3 CHỮ - CAPSTONE PROJECT
CUỐN

[QC MANAGER]
- LÀ SẾP CỦA DÂN QC
- TỐT NHẤT NÊN ĐI LÊN TỪ QC/TESTER (LÀM SẾP TỐT NHẤT NÊN ĐI QUA CON ĐƯỜNG LÀM LÍNH
TRƯỚC)
- LÊN KẾ HOẠC CHO VIỆC KIỂM THỬ 1 DỰ ÁN NÀO ĐÓ, PHẢI PHỐI HỢP VỚI PM ĐỂ CÙNG BÀN
KHI NÀO TEST, TEST GÌ, CẦN THIẾT BỊ GÌ, ĐỘ KHÓ ĐỂ PHÂN BỐ NHÂN LỰC QC
- CHUẨN BỊ TRANG THIẾT BỊ, MÁY MÓC, SERVER SẴN SÀNG CHO VIỆC TEST. VÍ DỤ TEST APP
BÁN HÀNG THÌ CẦN MÀN HÌNH CHẠM, MÁY ĐỌC BARCODE, MÁY IN; APP GIỮ XE CÓ CAMERA ĐỂ
CHỤP BIỂN SỐ XE
- PHÂN BỐ CON NGƯỜI QC VÀO DỰ ÁN THÍCH HỢP
- YÊU CẦU LÍNH/QC THIẾT KẾ TEST CASE, CHẠY TEST CASE - TEST RUN, GHI NHẬN BUG -
"LOG BUG"
- REPORT TÌNH TRẠNG APP VỚI PM/SẾP TRÊN
** NL4: DEFECTS CLUSTERING - SỰ PHÂN BỐ, PHÂN TÁN CỦA BUG, CỦA NHỮNG SAI SÓT
- CÓ NHỮNG CHỖ TRONG APP CÓ NHIỀU BUG
- CÓ NHỮNG CHỖ TRONG APP CÓ ÍT BUG HƠN
- CÓ NHỮNG CHỖ TRONG APP/TÍNH NĂNG MÀ CHIẾM PHẦN LỚN BUG CỦA TOÀN BỘ
- CHỈ 1 VÀI MODULE, CHIẾM SỐ LƯỢNG BUG ÁP ĐẢO
KHÔNG DÀN TRẢI NHÂN LỰC, NỖ LỰC ĐỂ TÌM BUG, TÌM NHIỀU BUG MÀ HÃY TẬP TRUNG VÀO
CHỖ NÀO ĐÓ

(NGUYÊN LÝ THỐNG KÊ - 80/20 - PARETO - ÍT > NHIỀU)

LÀM ÍT NHƯNG LẠI HIỆU QUẢ
NHIỀU KHI NGHĨ RẰNG CÓ NHIỀU MÀ LẠI CHẲNG CÓ GÌ

CÂU HỎI: CHỖ NÀO TRONG APP THÌ SẼ CÓ NHIỀU BUG, VÀ ÍT BUG
- NHỮNG TÌNH NĂNG CƠ BẢN, KINH ĐIỂN: CRUD USER, CRUD CATEGORY, CRUD ... MÀ CHỈ XẢY
RA TRÊN 1 HOẶC 2 TABLE, NÓ SẼ ÍT BỊ SAI, ÍT BUG

NHỮNG TÍNH NĂNG BÊN NGOÀI ( BÊN NGOÀI À APP MOMO, MOCA, ... GOOGLE MAIL, FB)
- THIẾT BỊ NGOẠI VI(CAMERA, CẢM BIẾN -SENSOR, MÁY ĐỌC MÃ VẠCH, MÁY IN, THIẾT BỊ
IOT, CƠ KHÍ...) TÍNH NĂNG APP MÌNH MÀ LẠI CHƠI VỚI NHIỀU MÓN, THÌ NÓ CÓ THỂ PHÁT
SINH NHỮNG THỨ KHÔNG ĐỒNG BỘ, KHÔNG TƯƠNG THÍCH, KHÔNG ỔN ĐỊNH ĐƯỜNG TRUYỀN...
>>> GÂY RA NHIỀU BUG HƠN CHỖ KHÁC
BUG Ở ĐÂU ĐƯỢC DỰ ĐOÁN NHIỀU -> PHÂN BỐ NHÂN LỰC QC TẬP TRUNG VÀO ĐÓ

** NL5: PESTICIDE PARADOX - NGHỊCH LÝ THUỐC TRỪ SÂU - HIỆN TƯỢNG KHÁNG THUỐC
- UỐNG THUỐC THUỐC CHỮA BỆNH, BỆNH KHÔNG LUI DO KHÁNG THUỐC, QUEN THUỐC
- NHỜ DÂN QC CHẶN BUG, GÁC CỬA, CHECK VAR, NHƯNG BUG CÒN, CÒN NHIỀU!! CÓ NHỜ CŨNG
NHƯ KHÔNG

NGUYÊN NHÂN:
- DO DÂN QC LÀM MÃI 1 VIỆC, LÀM HOÀI MỘT VIỆC SINH RA: QUEN VIỆC VÀ CHỦ QUAN;
THÔI PHẦN NÀY KHỎI TEST VÌ HÔM QUA ĐÃ TEST RỒI, CHẮC NÓ VẪN ỔN!!
- DO DÂN QC LÀM MÃI 1 VIỆC, TEST MÃI 1 APP, SẼ CÓ CẢM GIÁC QUEN THUỘC, NÊN DỄ BỎ
QUA KO DI KHÁM PHÁ LẠI CÁC TÍNH NĂNG, VÀ BIẾT ĐÂU TRONG QUÁ TRÌNH FIX BUG, NÂNG CẤP
TÍNH NĂNG CỦA DEV, CODE CHO TÍNH NĂNG CŨ ĐÃ THAY ĐỔI -> KO ĐC TEST LẠI -> TIỀM ẨN
BUG

CÁCH FIX:
- NÊN HOÁN ĐỔI TÁC VỤ, CÔNG VIỆC, DỰ ÁN, LOẠI HÌNH KIỂM THỬ CHO DÂN QC, KO BẮT LÀM
MÃI 1 VIỆC TRONG 1 KHOẢNG THỜI GIAN ĐỦ DAIF, HOÁN ĐỔI CÔNG VIỆC
- VÍ DỤ: TEST ƯEB APP 1 THỜI GIAN, CHUYỂN QUA TEST MOBILE, TEST DESKSTOP APP ĐỦ
THỜI GIAN THÌ CHUYỂN QUA WEB APP, TEST APP THƯƠNG MẠI ĐIỆN TỬ ĐỦ THỜI GIAN THÌ
CHUYỂN QUA APP IOT
- MÔI TRƯỜNG MỚI, CÔNG VIỆC MỚI TẠO NÊN SỰ TÒ MÒ, PHẤN KHÍCH, HAM KHÁM PHÁ -> NHỜ
CÁI KHÁM PHÁ CÓ THỂ TÌM RA, PHÁT LỘ BUG
----------------------
** NL6. TESTING IS CONTEXT DEPENDENT - KIỂM THỬ PHẦN MỀM PHỤ THUỘC NGỮ CẢNH - CÂU
CHUYỆN
- CÁC LOẠI APP KHÁC NHAU THÌ KIỂM THỬ KHÁC NHAU, TEST CASE KHÁC NHAU
- CÁC MÔI TRƯỜNG CHẠY APP KHÁC NHAU THÌ KIỂM THỬ KHÁC NHAU, TEST CASE KHÁC NHAU
- VÍ DỤ:
- TEST APP CHẠY TRÊN ANDROID CÓ CHÚT KHÁC BIỆT VỚI APP CHẠY TRÊN IOS, ĐẶC
BIỆT PHẦN BẢO MẬT, PHẦN TRUY XUẤT HỆ THỐNG
- TEST WEB APPP THÌ KHÁC MOBILE. MÀ WEB APP THÌ LẠI CẦN XEM USER DÙNG GÌ ĐỂ
XEM WEB
- DÙNG MÁY TÍNH KHÁC MOBILE DO MÀN HÌNH HẸP, 2 CHIỀU DỌC NGANG NÊN CẦN
RESPONSIVE/FLUENT
- TEST APP IOT THÌ NGOÀI TEST TÍNH NĂNG CHẠY, CÒN PHẢI LƯU Ý TÍNH TƯƠNG THÍCH
THIẾT BỊ
IOT: CẢM BIẾN, CAMERA, THIẾT BỊ CƠ KHÍ, CƠ ĐIỆN TỬ - XEM ĐỘ ỔN ĐỊNH,
GIAO THỨC GIAO TIẾP, ĐỘ PHÂN GIẢI, ÁNH SÁNG, MÔI TRƯỜNG...
- TÓM LẠI KỊCH BẢN KIỂM THỬ RẤT ĐA DẠNG VỚI CÁC LOẠI APP CŨNG ĐA DẠNG
--------------------
** NL7. ABSENCE OF ERROR FALLACY
- CẤM TUYỆT ĐỐI GÁY KIỂU: APP EM CỰC TỐT, KO CÓ BUG, ĐỐT ĐUỐC KO TÌM RA BUG
- NẾU APP MÀ "RẤT ÍT BUG" SAU NHIỀU LẦN TEST VÀ NHIỀU LẦN FIX, MÌNH VỖ NGỰC APP
NGON VÌ KO BUG CÂU DẠNG NÀY SAO VÌ 2 Ý NGHĨA
> APP NÀO CŨNG CÓ BUG, CŨNG CÒN TỒN TẠI BUG (NL1), GÁY APP FREE OF ERRORS,
GÁY APP KO BUG LÀ SAI RÒI, QUÁ SAI
> GIẢ SỬ APP NGON VÌ KO BUG, THÌ GÁY APP KO BUG KO PHẢI LÀ MỤC TIÊU LÀM APP

NÓI CÁCH KHÁC: LÀM APP, LÀM SẢN PHẨM KO BỊ LỖI, LÀM APP LÀM SP CÓ CHẤT LƯỢNG
ĐÓ LÀ ĐIỀU BẮT BUỘC PHẢI LÀM, KO AI MUỐN ĐEM SẢN PHẨM BỊ LỖI ĐI BÁN

- VẬY MÌNH SẼ GÁY GÌ????

GÁY RẰNG APP TUYỆT VỜI VÌ CÓ LƯỢNG USER ĐÔNG ĐẢO THEO THỜI GIAN, GÁY RẰNG APP RẤT
ĐC ƯA THÍCH VÀ USER ĐANG DÙNG NÓ TRONG CÔNG VIỆC HÀNG NGÀY (LÀM, GIẢI TRÍ)
THANG ĐO THÀNH CÔNG CỦA APP LÀ ĐC YÊU THÍCH SỬ DỤNG, BUG, ÍT BUG ĐÓ LÀ TRÁCH
NGHIỆM DEFAULT MẶC ĐỊNH

2 LOẠI APP KHÁC NHAU, ĐỘ ĐO KHÁC NHAU NHAU 1 CHÚT

- GENERIC: APP CHO BÁ TÁNH DÙNG
- ĐỘ THÀNH CÔNG CHÍNH LÀ TẬP HỢP ĐÔNG ĐẢO CỘNG ĐỒNG MẠNG SỬ DỤNG APP, GIỚI
THIỆU APP REVIEW APP

- CUSTOMIZED/ BESPOKE: APP LÀM RIÊNG CHO NHU CẦU CỦA DOANH NGHIỆP
- APP Quản lí kho, Bán hàng, Ko lưu, Hải quan, Hành chính công...
- ĐỘ THÀNH CÔNG CHÍNH LÀ NHỮNG FEEDBACK CỦA NHÂN VIÊN CỦA TỔ CHỨC ĐÓ XÀI
HỌ NÓI RẰNG APP NGON, KO THỂ THIẾU TRONG CÔNG VIỆC HỌ ĐANG LÀM HOẶC ĐỀ
XUẤT CHỈNH SỬA ĐỂ PHÙ HỢP SỬ DỤNG

NGƯỜI DÙNG LÀ BÁ TÁNH HAY NHÂN VIÊN CÔNG TY THÍCH DÙNG THÍCH XÀI APP
> HÀNH ĐỘNG DÙNG XÀI THẤY ỔN VÀ TIẾP TỤC DÙNG SAU GIAI ĐOẠN DÙNG THỬ THÌ GỌI
LÀ UAT - USER ACCEPTANCE TESTING

NL7: UAT LÀ QUAN TRỌNG, ÍT BUG LÀ DEFAULT

APP PHẢI PHÙ HỢP NHU CẦU SỬ DỤNG, VÀ ĐC SỬ DUNGH BỞI USER!!!!!!!!!!!!
===========================================================
V. TESTING LEVELS = CÁC MỨC ĐỘ KIỂM THỬ

Quy trình làm phần mềm theo tiến trình thời gian thì bao gồm các công đoạn sau:
(ko care phương pháp làm là Scrum hay Waterfall)

Requirements | Design | Implementation | Testing | Deployment |

Mainternance/Enhancement

WRSPM World > Requirements > Specification > Program > Machine

SWR
Requirements: Elicitation > Analysic > Specification > Validation

CẮT RIÊNG | Implementation | Testing -> DÍNH ĐẾN CODE, APP RỒI, KO HỨA NHƯ BÊN REQS
CODE CODE CODE CODE CODE CODE CODE CODE CODE ................. APP .......... KIỂM
THỬ
THEO TIẾN TRÌNH THỜI GIAN, CODE CỦA APP BẮT ĐẦU NHIỀU DẦN ĐẾN MỨC HOÀN THIỆN
------------------------------------------------------>
DEV LÀM HÀNG NGÀY
HÀM 1 HÀM+cLASS+UI+DB+API CHỨC NĂNG 1
CLASS 1 1 CHỨC NĂNG ĐÃ HÌNH THÀNH CHỨC NĂNG 2
 CHỨC NĂNG 3
HÀM 2 HÀM+CLASS+UI+DB+API HOMEPAGE
CLASS 2 1 CHỨC NĂNG KHÁC ĐÃ HÌNH THÀNH CAROUSEL
SEARCH/FILTER
HÀM 3 HÀM+CLASS+UI+DB+API VIEW DETAILS
CLASS 3 CHỨC NĂNG LOGIN, CRUD ITEMS LOGIN/REGISTER
CART
HÀM/CLASS DC GỌI LÀ QC NHẢY VÀO TEST CHỨC NĂNG PAYMENT
UNIT OF CODE - ĐƠN VỊ CODE (UI ĐỂ TƯƠNG TÁC RỒI) CRUD../
CODE ĐẾN ĐÂU, TEST ĐẾN ĐẤY CHỨC NĂNG: GOM CÁC THÀNH PHẦN
APP/SYSTEM ĐÃ XH
> MỨC TA CODE HÀM/CLASS CODE, DB, UI, DB, API
VÀ PHẢI KIỂM THỬ THÌ GỌI CHỨC NĂNG: GOM, TÍCH HỢP NHIỀU MÓN
LÀ ***UNIT TESTING LEVEL***** LẠI THÀNH 1 MÓN: LOGIN, CRUD
CODE VỪA CÓ HÀM/CLASS HOY
ĐÃ TEST RỒI KIỂM THỬ KHI CÓ CHỨC NĂNG GỌI LÀ QC NHẢY VÀO,
TEST APP HOY
KIỂM THỬ TÍCH HỢP - INTEGRATION TESTING LEVEL -
CHUẨN BỊ TEST CASE
(BỘ DATA ĐẦU VÀO
CHO APP + EXPECTED VALUE VÀ CÁC STEP ĐỂ RUN APP)
- TIẾN HÀNH CHẠY
APP TÌM BUG VỚI TESTCASE ĐỂ TÌM BUG ĐC GỌI LÀ TEST RUN
> RUN = MANUAL
> RUN = TOOL
AUTOMATION
việc kiểm thử gọi
là
SYSTEM
TESTING LEVEL
-----------------------------------------------------------------------------------
----->-
UNIT TESTING LEVEL
INTEGRATION TESTING LEVEL
SYSTEM TESTING LEVEL
ĐƯA CHO USER SỬ DỤNG, DÙNG THỬ
ĐƯA LÊN TRÊN MẠNG ĐỂ DOWLOAD QUA STORE, WEBSITE
ĐƯA LÊN SERVER WWW
CÀI VÀO MÁY NHÂN VIÊN CÔNG TY KHÁCH HÀNG
THIÊN HẠ DÙNG THỬ, NHÂN VIÊN DÙNG THỬ
CHO FEEDBACK, VÀ REPORT BUG

UAT LEVEL
USER ACCEPTANCE TESTING LEVEL
===================================================================================
=
1. UNIT TESTING LEVEL
- DEV PHẢI CÓ TRÁCH NGHIỆM ĐẢM BẢO TỪNG HÀM, TỪNG CLASS MÌNH VIẾT RA PHẢI CHẠY NGON
TỨC LÀ PHẢI XỬ LÍ INFO THẬT NGON
- LÀM SAO ĐẢM BẢO CODE MÌNH NGON, CÓ 3 CÁCH KIỂM THỬ

* CÁCH 1: GỌI HÀM, IN KẾT QUẢ TRẢ VỀ MÀN HÌNH

* CÁCH 2: GỌI HÀM, IN KẾT QUẢ TRẢ VỀ RA LOG FILE
* CÁCH 3: GỌI HÀM, DÙNG THƯ VIỆN BÊN NGOÀI, UNIT TESTING FRAMEWORK ĐỂ HỖ TRỢ VIỆC
KIỂM THỬ HÀM
NÓ DÙNG LUÔN, LÀ PHẦN CODE CỦA QUY TRÌNH ĐỘ PHÂN GIẢI 2K
QUY TRÌNH CI/CD/CD/DEVOPS LƯƠNG 2K TRỞ LÊN
=====================================
GIẢI NGỐ GITHUB
1. GIT/GITHUB LÀ GÌ?
- Git là công nghệ, kĩ thuật Quản lí source code
SCM - Source Control Mângement System
VCS - Version Control System
Hệ thống quản lí phiên bản, quản lí sự thay đổi của source
code
- Quản lí history/sự thay đổi của code theo thời gian và ta
có thể undo/rollback lại code của bất kì thời điểm nào
- Quản lí luôn sự xung đột code của các thành viên trong
team, nghĩa là code 2 dev có khả năng đề lẫn nhau
hoặc ta cần merge code/ trộn code của anh em lại
- Quản lí rẽ nhánh code. Project đc clone thành phiên bản
thử nghiệm khác nhau, thấy ổn thì nhập vào chung 1 kho final - BRANCH & MERGE
- TỪ GIT ĐẺ RA GITHUB, GITLAB, BITBUCKET... LÀ NHỮNG SERVER CUNG CẤP DỊCH VỤ (FREE
VÀ $) QUẢN LÍ SOURCE CODE CHO BẤT KÌ AI MUỐN THAM GIA

2. CẦN GÌ ĐỂ CHƠI VỚI GIT NÓI CHUNG, GITHUB NÓI RIÊNG

- DÙNG IDE CÓ SẴN MENU GIT. HOẶC CÀI THÊM PLUGIN
- DÙNG GUI TOOL RIÊNG, TOOL RỜI, VÍ DỤ SOURCETREE, GIT DESKSTOP
- DÙNG CMD TOOL, GIT-SCM, SẼ CHẠY TRÊN 2 MÔI TRƯỜNG CMD TRUYỀN THỐNG VÀ BASH (LINUX
CMD)

---------------------------------------
[NGOẠI TRUYỆN - VÀI LỆNH LINUX CƠ BẢN]
LINUX PHÂN BIỆT HOA THƯỜNG, LỆNH LUÔN CHỮ THƯỜNG
- pwd -> in ra You are here, cho mình biết mình đang đứng ở thư mục hiện thành nào
Print Working Directory
- ls, ls -a, ls -la -> in ra tring thư mục đang đứng có những gì ~~~dir trong
windows

- vim -> gọi Notepad dòng lệnh, soạn thảo văn bản
> nhấn phím Insert để vào chế độ soạn thảo
> nhấn Esc để vào chế độ gõ lệnh
> nhấn :q để thoát Vim
> nhấn :q! để thoát mà ko save
> nhấn :qw để write/save
> nhấn :qw <tên tập tin> để tạo mới tập tin và save content
- cat <ten tap tin muon xem content>
- clear
- mkdir -> tao moi folder

ĐỀ PHÒNG KHI CODE BỊ XUNG ĐỘT

GIT KÉO CODE VỀ (GIT PULL) THÌ TỰ MỞ MÀN HÌNH VIM, BIẾT ĐƯỜNG MÀ THOÁT MÀN HÌNH!!!
MỞ ĐỂ COMPARE CODE BỊ XUNG ĐỘT

---------------------------------------
3. ĐỒNG BỘ CODE LÊN GITHUB, LÊN SERVER, LÊN REMOTE - FIRST TIME
3.1 NHÓM LỆNH CHỈ GÕ 1 LẦN CHO 1 MÁY
CHỈ GÕ LẠI NẾU: CÀI LẠI WIN, MƯỢN MÁY BẠN XÀI GIT, HOẶC MÌNH ĐỔI
USERNAME/PASS CỦA GIT CỦA MÌNH

> NHÓM LỆNH KHAI BÁO THÔNG SỐ USERNAME, PASSWORD CỦA GITHUB
git config --global user.name <tên-github-của-bạn>
git config --global user.email <email-github-của-bạn>
 3.2 NHÓM LỆNH CHỈ GÕ 1 LẦN ỨNG VỚI 1 PROJECT - SANG PROJECT MỚI GÕ LẠI - CX CHỈ 1
LẦN
> CHUẨN BỊ PROJECT Ở LOCAL, TẠO MỚI PROJECT = TOOL NETBEANS, INTELLIJ, VSC
> CHUẨN BỊ SẴN 1 FILE .GITIGNORE GỌI LÀ BLACKLIST CHỨA NHỮNG THẰNG KO DC LÊN
SERVER, VÍ DỤ THƯ MỤC TARGET, DIST, BUILD, .IDEA...
ĐỂ LÀM NHANH FILE NÀY, LÊN MẠNG DÙNG TOOL SAU ĐỂ GENERATE CHO TIỆN

GITIGNORE.IO

CHUYỂN VÀO THƯ MỤC PROJECT ĐỂ CHUẨN BỊ ĐỒNG BỘ CODE LÊN SERVER
KIỂM TRA COI CÓ ĐÚNG CÓ .GITIGNORE CHƯA
BẰNG LÊNH ls | ls -a | ls -la | dir | dir -a

> gõ lệnh - DÙNG DUY NHẤT 1 LẦN CHO 1 PROJECT MỚI TẠO
CỨ MỖI KHI TẠO MỚI 1 PROJECT THÌ PHẢI GÕ LỆNH NÀY, CHỈ 1 LẦN

git init
câu lệnh này tự sinh ra 1 thư mục ẩn trong project mình, gọi là .git\
dùng để tracking history thay đổi code | cấm tuyệt đối thay đổi bên trong thư mục
này

> TẠO MỚI 1 KHO CODE Ở REMOTE SERVER TÊN TRÙNG 100% CẢ HOA THƯỜNG VỚI TÊN
PROJECT Ở LOCAL

> Gõ lệnh git add . //khi ta upload code, upload tap tin chứa trong tên có
dấu chấm đầu tên - ví dụ .gitignore
git add * //khi ta upload codo ko chứa dấu chấm ở đầu tên

// scan qua các tập tin đã bị thay đổi so với lần đồng bộ trước

git commit -m "lí do uplaid code là gì"

//XÁC NHẬN RẰNG TẤT CẢ NHỮNG TẬP TIN BỊ THAY ĐỔI SẼ LÊN SERVER LOẠI TRỪ THẰNG
BỊ Ở LẠI TRONG GITIGNORE
// ĐI THỰC TẬP, "LÍ DO PHẢI GHI TỬ TẾ, TÓM TẮT", GÕ ASDF, AHIHI ĂN ĐÒN

> khai báo kho ở xa để chuẩn bị đưa code lên vì ở xa có nhiều kho, đưa lên kho nào.
KHO Ở XA GỌI TẮT LÀ ORIGIN
git remote add origin https://github.com/phongkhongxai/math-ulti-mvn.git
git pust -u origin main

3.2 NHÓM LỆNH HUYỀN THOẠI DÙNG TỚI LUI, LIÊN TỤC BẤT KÌ KHI NÀO CẦN ĐỒNG BỘ CODE
UPDATE MỌI THỨ LÊN SERVER

git add *
git commit -m "sua gi"
git push
3 lenh xai hang ngay!!!!

==========================================================
TỔNG KẾT ĐỂ BỔ SUNG THÊM VÀO CV - MỤC TECHNICAL SKILSS
Unit Test, Junit, Regression Testing, DDT, TDD, Continuos Integration, Maven

* Unit Test:: dev phải test code của mình. Đảm bảo các hàm/method chạy đúng như
thiết kế, như tính toán
để test code của mình, thì có thể dùng cách
* JUnit
* TDD: Test Driven Development:
* DDT: Data Driven Testing: kĩ thuật viết code kiểm thử, kĩ thuật viết test script
mà tách riêng bộ data kiểm thử ra 1