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

Đi tìm ra các sai sót, bất thường của App được viết cho người sử dụng. Sai sót được
gọi là 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Ì
-Đích đến của việc kiểm thử là tìm cái sai/bug, 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 dc đâ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 đucojw)
-ACTUAL VALUE (giá trị thực tế, giá trị trả về thấy được)
-Kiểm thử phần mềm là so sánh 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 là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í dụ tháng 9 này khuyến mãi
10% cho đơn hàng trị giá từ 1 tr đồng trở lên
- Dân dev viết code, cài luôn 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ử/thánh soi sẽ chạy app, chạy thử tính năng tạo bill xem
nó chạy có đúng hay không? nếu đúng oke, nếu sai BUG!!

- Muón test thì phải đưa data, chạy thử app với data đưa vài, xem app xử lý đúng
hay 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 VALUE MÀ APP PHẢI
TRẢ VỀ!! THỰC TEES NHẤN NÚT SCAN SẢN PHẨM, TIỀN BILL CỨ TĂNG THEO TÍT TÍT. NẾU
KHÁCH DỪ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 LÀ 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 < 1tr !! App ko tính khuyến mãi
trong trường hợp này.

- Dân tester kiểm thử câu chiện 2, tình huống 2:

scan sản phẩm, tít tít vừa đủ 1tr dongl chẳng cần app, chỉ cần tính nhẩm, cũng
biết đc khách phải trả 900k
- Vậy 900k dc gọi là giá trị kì vọng, expected value mà app phải trả về khi khách
mua 1tr dong(km 10%)

- Chờ app viết xong, scan đủ 1tr dong, phần bill phải trả app 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 bới
1 trd dong!
- nếu actual value == bill phải trả == 1 tr 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 == 1tr !! App tính khuyến mãi trong
trường hợp này, TRỪ 10% RA BILL

* CHỐt HẠ: D/N 1: KIỂM THỬ LÀ RUN APP ĐỂ XEM APP CHẠY CÓ NHƯ TÍNH TOÁN HAY KO
2. KIỂM THỬ PHẦN MỀM LÀ SO SÁNH, ĐO LƯỜNG XEM APP CÓ ĐẠT ĐC CÁC THÔNG SỐ VẬN HÀNH,
THÔNG SỐ HIỆU NAY, THÔNG SỐ TRẢI NGHIỆM HAY KO ??
- Dân kiểm thử sẽ chạy app, đo xem app chạy nhanh như thiết kế, dự định hay ko, app
có chịu tải dc 1 lượng người dùng nào đó hay ko ở 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 ko?? kiểm tra màu sắcm font chữ, ngữ pháp,
dấu câu.. có ổn ko

- 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/ds) THÌ APP PHẢI PHẢN 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ụ: ko care app tính bill 10% đúng hay sai, mà chỉ cần quan tâm đủ 3s trở lại
hay ko
-> KIỂM THỬ DẠNG TRẢI NGHIỆM APP DC GỌI LÀ KIỂM THỬ PHI CHỨC NĂNG NON-FUNCTIONAL
TESTING

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

Đ/N 1 Đ/N2

* KO ĐC NHẦM LẪN VỚI : NON-FUCTIONAL REQIREMENTS TESTING -> CHỮ NÀY NẾU CÓ THÌ LÀ
NGHĨA KHÁC, THƯỜNG KO DÙNG THUẬT NGỮ NÀY!!
ví dụ: đo xem app chạy nhanh, từ 3s trở lại hay ko -> non-functional testing
k/h 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, ko làm dc loại câu này
tìm ra những câu reqs vớ vẩn, là 1 chiện khác của nghề kiểm thử!!!

- Ví dụ tiếp: kiểm thử xem mã màu của các nút nhấn có đúng như thiết kế hay ko ->
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 KO; HỨA GÌ VỚI KHÁCH HÀNG, HỨA APP CÓ BN TÍNH NĂNG
THÌ PHẢI CÀI CHO ĐỦ (CHƯA CẦN BIẾT CHẠY ĐÚNG SAI - ĐÚNG SAI NẰM Ở D/N 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ê ca 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 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 lun)

----------------
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 GIÁ TRỊ: EXPECTED VÀ ACTUAL
- so sánh giữa cái kì vọng app phải làm 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!!

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 bug
[NGOẠI TRUYỆN] THÔNG TIN TUYỂN DỤNG : tuyển QA/QC (Quality Asurance)
3.QC MANAGER
4.USER/END-USER - NGƯỜI DÙNG CUỐI
---------------------
1.DEVELOPER
* Công việc của DEV 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 DC CODE CÓ CHẤT LƯỢNG - DEV PHẢI CÓ TRÁCH NGHIỆ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ƯƠNGK - KĨ THUẠT KIỂM THỬ CODE

- Mỗi hàm/method, mỗi class mà dev viết ra đều phải dc test, test tức là đưa data
vào hàm, gọi hàm chờ hàm xử lí, xem kết quả có như dự kiến hay ko??
- Trong dự án phần mềm nhớ rằng đơn vị code nhỏ nhất có ý nghĩa là HÀM/CLASS (các
câu lệnh khai báo biến, vòng lặp, try-catch,..) ko 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 DEV phỉa TEST CODE/HÀM/CLASS MÀ HỌ VIẾT RA THÌ DC GỌI LÀ UNIT
TEST/UNIT TESTING
*LÀM SAO ĐỂ TEST HÀM/TEST CLASS???
- c1: gọi hàm với data đư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ó == kq tính toán = tay của mình hay
ko???
- C2: gọi hàm với data đưa vào, in kết quả xử lí của hàm ra 1 tập tin gọi là LOG
FILE, SAU ĐÓ XEM KẾT QUẢ ACTUAL ĐỐI CHIẾU VỚI EXPECTED
2 CÁCH 1 2 LLAF CÁCH TRIUYEENF THỐNG L, DỄ LÀM, NHUNG TÓN CÔNG LUẬN KẾT QUẢ ĐÚNG
SAI = MẮT, CÓ THỂ GAY RA SAI SÓT LUÔN
- C3: (FIX CHO C1, C2) MẮT NGƯỜI DEV KO CẦN PHẢI ĐI SO SÁNH TUNGWF CẶP EXPECCTED
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 dc 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ÓPP 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 nộ kiểm thử unit test
check xem code ngon hay ko, 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 DC 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

- 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 ko,
expected = actual?
kiểm tra xem app có đạt hiệu năng kì vọng hay ko, trải
nghiệm ổn ko?
kiểm tra, xác nhận xem app có làm đúng như đã hứa hay ko

QC/TESTER LÀ CHẠM VÀO APP, XÀI APP, TEST APP, KO TEST CODE!!!
*QC/Tester kiểm thử THẾ NÀO???
- QC/TESTER chuẩn bị sẵn bộ data/ dữ liệu để đưa vào app
mở app lên, click vào chức năng/màn hình múm test
gõ data đã chuẩn bị vào trang màn hình
click dropdown, checkbox, radio button nếu cần
nhấn nút[xử lí] gì đó, chờ app chạy trong vòng 3s
xem kết quả trả về sau khi clcik nút nhấn
 dùng mắt đọc kq trả về(actual) so sánh kq trả về có == kq chuẩn bị
trước đó hay ko - EXPECTED.
nếu == thì app ngon
nếu != thì app bị BUG
BỘ DATA CHUẨN BỊ SẴN ĐỂ TEST APP ĐÚNG SAI DC 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 của 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 trả về chữ F (hệ 16)
test case 2: đưa con số 250 vào app, thì app trả về 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, THỦ CÔNG
KĨ THUẬT KIỂM THỬ THỦ CÔNG ĐỂ BIẾT 1 APP ĐÚNG SAI GỌI LÀ MANUAL TESTING (CÁCH
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 Ở TRÊN TỰ ĐỘNG, 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 EXPECTED LUN!! TỤ DỌNG HẾT KĨ THUẬT NÀY
GỌI LÀ
TEST AUTOMATION/AUTOMATED TESTING, TESTING AUTOMATION
*HOW DO THEY DO THAT, LÀM SAO LÀM DC CÁI TRÒ NÀY:
- DÂN KIỂM THỬ PHẢI LẬP TRÌNH ĐỂ DK APP (KO LẬP TRÌNH TẠO APP NHƯ DEV)
- DÂN KIỂM THỬ LẬP TRÌNH XÀI THÊM ĐỒ CHƠI, CÔNG CỤ NHƯ 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Á "MỒI",
LÀM = TAY CỦA TESTER, NHẬP DÂT, CHUYỂN TRANG, CHỌN BTTON, CHECKBOX, NHẤN NÚT,
VERIFY VỚI EXPECTED, TÔL GHI LẠI HẾT CÁC THAO TÁC
SAU ĐÓ KHI CẦN TEST LẠI, TA PLAY-BACK RECORD/PLAYBACK 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, RỒI VIẾT CODE DÙNG
THƯ VIỆN NÀY ĐỂ IMPLEMENT THỰC THI 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 DC
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, GỌI 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ÀO DATA GỌI LÀ:
CRAWL/CRAWLER BOT
* TOOL RECORD/PLAYBACK NÓ CÓ 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 THÔI

[NGOẠI TRUYỆN] THÔNG TIN TUYỂN DỤNG : tuyển QA/QC (Quality Asurance)
* NHIỆM VỤ CỦA QA
- ko sờ trực tiếp vào app để tìm BUG (QC/TESTER ĐI TÌM BUG), MÀ ĐI VÒNG VÒNG TRONG
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
ĐANG LÀM THANH TRAM 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 TRÌNH CHẤT LƯỢNG ĐÃ CAM KẾT HAY HO
- ĐỨ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

- 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 dc gọi là USER STORY, lưu trữ
ở 1 nơi gọi là BACKLOG, ví dụ lưu ở JIRA, TRELLO, NOTION
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 K/H, GHI NHẬN FEEDBACK, DEAL
VỚI K/H VỀ 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. CUỐI BUỔI DEMO (TUẦN THỨ 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 MỖI NGÀY 2 3 4 5 6 BUỔI SÁNG ĐẦU GIỜ HỌP NHANH VÀ ĐỨNG 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 MÚM XEM 2 BIÊN BẢN LÀM
VIỆC VỚI K/H?? CÓ ĐỦ 2 BIÊN BẢN CHƯA??? CHƯA THÌ ĐI MÉ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 PHÍ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 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 RATRONG CÔNG TY, PHÒNG
BAN, PROJECT.

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

-TẠI SAO CÓ CHỮ END TRONG END-USER --->> END là sự kết thúc của luồng đi thông tin;
END-USER: THÔNG TIN TỪ APP CHẢY VỀ ĐẾN MÌNH, HẾT ĐI ĐÂU DC NỮA.LÀ NGƯỜI CUỐI CÙNG
HỨNG THÔNG TIN TỪ APP; DB TUI CX LÀ NGƯỜI CUỐI CÙNG HỨNG INFO TỪ APP, TỪ USER.
-FRONT-END, BACK-END????

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 CHẢY VỀ ĐẾN MÌNH LÀ CÙNG ĐƯỜNG, HỂM CỤT RÒI, HẾT ĐI ĐÂU
DC NỮA TUI LÀ NGƯỜI CUÓI CÙNG HỨNG THÔNG TIN TỪ APP
DB TUI CCX LÀ NGƯỜI CUỐI CÙNG HỨNG INFO TỪ APP, TỪ USER - END
END: KẾT THÚC CỦA 1 GÌ ĐÓ, 1 HÀNH TRÌNH INFO CHẠY ĐẾ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 NÊN PHỤ TRỢ CHO VIỆC CHẠY
APP MÌNH: ios, ANDROID,LINUX, WINDOW, 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 CHÚNG, APP HƯỚNG ĐẾN SỐ ĐÔNG NGƯỜI DÙNG
>Ví dụ: Game, Tools: browser, download, nén/xả, xử lí ảnh/dựng phim văn
phong:...
>Đặc trưng: thường sẽ có nút download, đăng kí login dùng thử

CÔNG TY LÀM RA APP GENERIC, THƯỜNG SẼ CÓ NHÌU PHIÊN BẢN DOWNLOAD, NHÌU 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 DC APP
- NHIỀU NGƯỜI DÙNG, SẼ CÓ NHÌU FEEDBACK, NHÌU BUG DC REPORT, THU THẬP NHIỀU
CMT GỠ RỐI TRÊN CÁC FORUM, MXH
CÁ LOẠI VERSION KHÁC NHAU CỦA P/M ĐỂ TĂNG ĐỘ TRẢI NGHIỆM VÀ TÌM BUG
- NIGHTLY BUILD (version nhìu lỗi, nhưng phong phú tính năng thử nghiệm)
- alpha, beta, insider review, preview, RC, trial, stable, LTS, PRO,
ENTERPRISE, COMMUNITY, OPENSOURCE

NGƯỜI DÙNG NHÀO VÀO 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Ị/CTY MÚM CÓ APP
>Ví dụ: App thu ngân của GS25, 711,
App chuyển tiền của TPBank, ACB; App quản lí ngân hàng
App quản lí bv của bvcr, bcdai hoc y,
App quản lí kho của Hòa Phát, Tân Hiệp Phát
>Đặc trưng: rất thường ko có nút download, mà thường chỉ có vid demo để PR
năng lực cty 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, ks, công sản xuất, dịch vụ, tổ chức: trường, viện,
trung tâm, hội nhóm
doanh nghiệp hoạt động thoe quy tắc kinh doanh riêng, app phải riêng!!

CTY LÀM APP, LÀM XONG, CÀI ĐẶT LÊN SERVER CTY ĐẶT HÀNG (SERVER TGDD, BV...)
CÓ THỂ CÀI THÊM TRÊN MÁY CỦA NHÂN VIÊN CTY ĐẶT HÀNG
VÍ DỤ APP QUẢN LÍ KHO CỦA HÒA PHÁT, THÌ MÌNH CTY P/M PHẢI CÀI APP CHO
MÁY CỦA THỦ KHO DÙNG
APP QUẢN LÍ NGÂN HÀNG THÌ PHẢI CÀI VÀO MÁY CỦA CÁC GDV ĐỂ XỬ LÍ VIỆC
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 KH CỦA NGÂN
HÀNG

NHÂN VIÊN CỦA CTY ĐẶT HÀNG LÀM APP SẼ LÀ END-USER DÙNG THỬ APP MÌNH VIẾT CHO HỌ CÓ
ỔN ÁP KO CÓ DÙNG ĐC TRONG HOẠT ĐỘNG CỦA CTY HAY KO

MÌNH LÀ CÔNG TY PHẦN MỀM CC APP CHO HỌ PHẢI NGHE, GHI CHÉP, VỀ NHÀ FIX, SỬA NGAY ĐỂ
CHO HỌ DÙNG THỬ

NẾU LÀ APP CHUYỂN TIỀN CỦA NGÂN HANG, 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 KKO 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 CTY ĐẶT HÀNG LÀM APP SẼ LÀ END-USER DÙNG THỬ ÁPP ĐỂ XEM ỔN KO

* CHỐT HẠ: DÙ APP LOẠI NÀO THÌ CŨNG CẦN NGƯỜI 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Ọ( CUSTOMINE APP)

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 (MANIFESTO)
* DB: 3 DẠNG 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 - CARTERSIAN PRODUCT
* SWR: 3 GÓC NHÌN: WHY, WHAT, WHO
* SWT: 7 VIÊN NGỌC RỒNG!!!
* ARCHITECTURAL VIEW: 4+1 VIEW MODEL