DEV3_TestTraining.pptx

Test Training
2019年4月1日
Viet Nam

Mở đầu
1
Nâng cao chất lượng test
2
Kỹ thuật test design
3
Tạo test case
4

3 @2019 Usol VietNam Co.,Ltd. All rights reserved.
.
Mở đầu
 Các vấn đề đang tồn tại:
 Năng suất tester thời gian gần đây không tăng (tạo test spec, execute).
 Chất lượng test của testr khi gửi cho tester không được đảm bảo.
 Tuy nhiên, khi testr thực hiện test chức năng mình đã tạo thì năng
suất được cải thiện đáng kể.
 Ngoài ra, với các chức năng mà các dev thực hiện test thì chất
lượng khá tốt.

.
Mở đầu
 Với mục đích tăng chất lượng sản phẩm, tăng năng suất test thì sẽ
dự định thực hiện các việc dưới:
① Nâng cao chất lượng test.
② Dần dần cải thiện năng suất test, đảm bảo chất lượng sản phẩm:
Chuyển một phần công việc test ở các dự án cho dev.
Thực hiện training test, yêu cầu skill test ở các new member từ sau này là bắt buộc.
Nâng cao skill, năng suất, chất lượng tester.
③ Theo dõi đánh giá năng suất, chất lượng sau khi thực hiện theo phương
châm mới.
Mục đích của khóa training này

Nâng cao chất lượng test
2

.
1. Suy nghĩ về đảm bảo chất lượng khi test (1)
 Tại Nhật Bản chất lượng được coi là quan trọng.
Một khi đã là doanh nghiệp thì phải nâng cao lợi nhuận.
Để đạt được điều đó, phải làm sáng tỏ và thực hiện được chất lượng mà người tiêu
dùng yêu cầu.
 Test chỉ chứng tỏ được việc có lỗi
Chỉ test thôi thì không thể duy trì được chất lượng, cho nên việc tạo ra chất lượng
ngay trong quá trình làm để không có sản phẩm chất lượng kém là rất quan trọng.

.
1. Suy nghĩ về đảm bảo chất lượng khi test(2)
 Quản lí chất lượng kiểu Nhật TQM
Total Quality Management
Point như sau
 Phải thực hiện ở tất cả các giai đoạn
 Tất cả nhân viên của tất cả các bộ phận phải thực hiện
 Phải thực hiện một cách tổng hợp
=> Ngay từ công đoạn ban đầu đã phải đảm bảo chất
lượng.

.
1. Suy nghĩ về đảm bảo chất lượng khi test(3)
Việc của mình là
coding. Đảm bảo
chất lượng là việc
của tester!
Việc của mình là coding và
đảm bảo chất lượng.
Tester giúp mình tìm ra lỗi
mà mình không thể tìm
được.
Dev

.
2. Nâng cao chất lượng test
Đảm bảo được
yêu cầu của khách
hàng.
Làm thế nào
nâng cao chất
lượng?
Xác nhận đầy đủ
design, yêu cầu ->
QA -> implement.
Implement đúng,
đủ yêu cầu.
Tự xác nhận lại sản
phẩm sau khi
implement trước khi
gửi cho tester
Làm thế nào
hiểu được yêu
cầu?
Làm thế nào biết
là implement
đúng, đủ?

.
Trình tự thực hiện công việc (1)
 Trình tự thực hiện công việc:
 Xác nhận input/output, nội dung công
việc, đối tượng liên quan.
 Lên plan công việc, phân bổ effort
phù hợp.
 Thực hiện theo plan
 Xác nhận lại kết quả công việc đã
thực hiện.
 Đưa ra action cho công việc tiếp
theo.

.
 Xác nhận input/output, nội dung công việc, đối tượng liên quan, rủi ro…
Phải hiểu đầy đủ thì mới biết mình phải làm gì => xác nhận với leader.
Thông thường đây là công việc của phase Plan
Ví dụ: công việc coding
Design common
Kiến trúc hệ thống
Convention
Sơ đồ di chuyển MH
Design màn hình
Xử lý nghiệp vụ
Bản thiết kế DB
Sample function
Triển khai ngang
Checklist
…
Input
Xác nhận design
Nghe giải thích deign
QA
Tạo màn hình
Implement xử lý logic
Self check
Free test
…
Nội dung công viêc
QA
Tài liệu trao đổi
Src test
Checklist self check
Kết quả free test
…
Output
TS, NUL… Reviewer, tester…
Cần làm lại 1 phần do
thay đổi design
Có việc đột xuất phải
nghỉ

.
 Lên plan công việc, phân bổ effort phù hợp.
Dựa vào thông tin đã phân tích, lên plan thực hiện.
Nếu effort không đủ thì hãy trao đổi với leader.
Ví dụ: công việc coding
5% Xác nhận
design
5% QA 85% Implement
5% SelfCheck
+ FreeTest
Trước đây
10% Xác nhận
công việc, design
10% QA 60% Implement
5%
SelfCheck
Sau khi xem xét kĩ càng
5% Buffer
Phòng tránh rủi ro.
Plan
10% FreeTest

.
 Thực hiện theo plan đề ra
 Bám sát kế hoạch đã đề ra.
 Trường hợp có phát sinh issue ngoài dự định hãy bàn bạc
với leader => chỉnh sửa kế hoạch nếu cần thiết.
 Nắm rõ công việc đang thực hiện, thường xuyên xác
nhận lại lượng công việc còn lại.
 Suy nghĩ là không sử dụng effort buffer.
Do

.
 Xác nhận lại kết quả công việc đã thực hiện.
 Sau khi hoàn thành công việc hãy xem xét lại plan đề ra.
Listup các điểm tốt, chưa tốt.
 Plan đã hợp lí chưa? (Effort implement quá ngắn, sử dụng hết buffer
mà vẫn chưa hoàn thành, để xử lý khó lại làm sau nên không đối
ứng kịp với thay đổi…)
 Đánh giá lượng công việc đã đúng chưa? (nghĩ rằng còn 20% là
xong nhưng thực tế mất đến 50% effort mới hoàn thành…)
 Việc liên lạc, báo cáo đã tốt chưa?
Check

.
 Đưa ra action cho công việc tiếp theo.
 Với các điểm tốt thì làm thế nào để duy trì, có làm tốt hơn
được không?
 Với các điểm chưa tốt thì làm thế nào để cải thiện?
 đưa ra action cho công việc tiếp theo.
 Điều chỉnh effort cho từng phần công việc.
 Log WBS đúng, đủ.
 Tập trung vào phần khó (xử lý nghiệp vụ, phần SQL khó…)
trước.
Action

.
Nội dung self check, free test(1)
 Việc self check, free test thì ở tất cả các dự án là bắt buộc
Trong trường hợp không thể free test (do môi trường, yêu cầu từ khách hàng…) thì cần được
sự đồng ý của PL.
 Việc self check thì cơ bản hãy thực hiện theo check list,
convention của dự án.
Các PLs hãy chú ý, nếu có thể thì hãy tạo checklist cho dự án của mình.
Nếu dự án không có check list thì việc self check coi như là việc tự review 1 lần sản phẩm
của mình. Về point review thì theo point review của dự án, hoặc xác nhận với reviewer trong dự án.
 Về việc free test thì đã tạo file tiêu chuẩn, từ nay về sau các dự án
hãy customize cho phù hợp với dự án và sử dụng.

.
Tính cần thiết của test design
Các bạn có thực hiện test design không?
Thực hiện test design trước,
Sau đó chuẩn bị testcase phù hợp (Không bị lack, không bị thừa) .
・Vừa nhìn test vừa tạo test case
・Vừa nhìn specification vừa tạo testcase
・Tạo test case bằng cách thử nhiều input một cách ngẫu nhiên (Giải
pháp cho mật độ test)
Cũng có những trường hợp test bị lack,
và test thừa do bị trùng lặp nội dung.
Các bạn tạo test case bằng phương pháp nào dưới đây?

.
Các kỹ thuật test design
 Kỹ thuật black box và white box
Cả 2 kỹ thuật đều dùng để thực hiện test design nhưng có mục đích
khác nhau.
Cả 2 kỹ thuật cần phải dùng kết hợp, không thể dùng một trong hai kỹ
thuật để thay thế cho kỹ thuật còn lại.
●Kỹ thuật black box
Thực hiện test design dựa vào tài liệu design.
Thực hiện test design dựa trên cơ sở điều tra tài liệu design, rồi confirm xem chương trình
có chạy đúng theo specification không.
○Kỹ thuật white box
Thực hiện test design dựa vào program (test).
Thực hiện test design dựa vào việc tìm hiểu cấu trúc bên trong của program, rồi confirm
việc kết quả đúng được trả về thông qua những path đã định trước.
Ở khóa học này chúng tôi sẽ giải thích về “Kỹ thuật black box test”.

.
 Test design dựa vào kỹ thuật black box
Blackbox test
Design Spec của input data
Spec xử lí
Phân chia equivalence value
Phân tích giá trị biên
Special Value
Error Based
Decision table
Kỹ thuật chuyển trạng thái
Kiểm thử cặp đôi
Test data
Test scenario
Kết hợp
Test case
Case
không
qua
test
design
Test
design
① ②
① Là kỹ thuật phân tích spec xử lí, để tạo ra các test scenario thích hợp.
② Là kỹ thuật phân tích spec của input data, để extract ra test data thích hợp.

Kỹ thuật phân tích spec xử lý
3.1

.
1. Kỹ thuật bảng quyết định (Decision table)(1)
 Decision table là bảng kết hợp giữa điều kiện (Input) và kết quả
(Output).
Format của decision table(DT)
◆ Điều kiện Heading
Phần mô tả
điều kiện
Phần chỉ định
điều kiện
◆ Kết quả
Phần mô tả
xử lí
Phần chỉ định
xử lí
Tại phần chỉ định điều kiện
・Thỏa mãn điều kiện Ｔ（True）
・Không thỏa mãn điều kiện Ｆ（False）
Cũng có khi
・“－”(Ngoài đối tượng) Không đánh giá điều
kiện
Thỏa mãn / không thỏa
mãn, thế nào cũng được.
 Các bước để tạo bảng quyết định
1. Liệt kê tất cả Conditions/Inputs
2. Tính số lượng kết hợp có thể (số cases)
3. Đặt tất cả các kết hợp vào trong bảng
4. Giảm thiểu các case kết hợp và quyết định test case

.
 Ví dụ tạo test case với bảng quyết định
Điều kiện để được mượn sách của thư viện là người mượn đã đăng ký thành viên,
đã
đóng phí mượn sách, và số sách đã mượn chưa vượt quá quy định.
Bước 1: Liệt kê tất cả Conditions/Input
 Đã đăng ký thành viên chưa?
 Đã trả phí chưa?
 Đã vượt quá số lượng chưa?
Bước 2: Tính số lượng case
Ở bước 1 liệt kê có 3 điều kiện
Mỗi điều kiện gồm 2 giá trị True/False
Số kết hợp = Số giá trị của Conditon 1 * Số giá trị của Condition 2 * Số giá trị của
Condition 3 = 2 * 2 * 2 = 8

.
 Ví dụ tạo test case với bảng quyết định
Bước 3: Đặt tất cả tổ hợp vào trong bảng
Bước 4: Giảm thiểu các case kết hợp và quyết định test case
1. Nhận biết những case có chung 'Action' và chỉ khác nhau ở giá trị của 'Condition' duy nhất
2. Chuyển giá trị của 'Conditon' ở step 1 thành '-' và loại bỏ bớt case
3. Lặp lại step 1 và 2 cho đến khi không còn case nào thỏa mãn
Số lượng
testcase đã
giảm từ 8
cases xuống
4 case

.
 Bài tập về nhà:

.
2. Kỹ thuật Pairwise Testing-Kiểm thử cặp đôi(1)
 Kiểm thử cặp đôi còn được biết đến như là kiểm thử All-pairs, đây là một
kỹ thuật kiểm thử sử dụng phương pháp tổ hợp.
 Ví dụ:
Một ứng dụng gồm có:
Bằng phương pháp tổ hợp thông thường sẽ xác định được số
testcase như sau
Tổng số lượng testcase valid cần test: 10*2*2*100 = 4000
Tổng số lượng testcase valid và invalid là > 4000

.
 Thử dùng kỹ thuật phân vùng tương đương.
 List box: Sử dụng kỹ thuật phân vùng tương đương, ta có thể gộp các giá trị của list
box thành 2 vùng giá trị là 0 và giá trị khác (1 -> 9)
 Radio button: giữ nguyên giá trị On, Off
 Check box: giữ nguyên giá trị Checked, Unchecked
 Text box: chia làm 3 vùng:
 số nguyên hợp lệ [1 => 100]
 số nguyên không hợp lệ [<1 và >100]
 AlphaSpecialCharacter – các ký tự không bao gồm số nguyên
Tổng số các case còn lại: 2*2*2*3=24

.
 Áp dụng kỹ thuật Pairwise Testing.
Bước 1: Đặt các giá trị trên vào bảng với giá trị đầu tiên là đối tượng có nhiều giá trị đầu vào
nhất và đối tượng có ít giá trị đầu vào nhất ở vị trí cuối cùng (Trong ví dụ này sẽ là Textbox)
Bước 2: Điền các giá trị vào bảng theo từng cột, bắt đầu từ cột đầu tiên (Text box), vì cột tiếp
theo là List box chứa 2 vùng giá trị dữ liệu nên sẽ nhập mỗi vùng giá trị của Text box trên 2
row

.
Bước 3: Ứng với mỗi giá trị của column 1, ta nhập cả 2 giá trị của column 2 (List box) và 2 giá
trị của column 3 (Radio button)
Bước 4: Kiểm tra các sự kết hợp đảm bảo rằng chúng bao phủ tất cả các trường hợp.
Bảng trên bước 3 có thể thấy thiếu cặp 0 – OFF và Other - ON, vì vậy cần đổi vị trí giá trị On,
Of trên côt Radio button trên dòng 3 & 4
Bước 3 Bước 4

.
Bước 5: tiếp tục nhập giá trị cho các cột tiếp theo và check sự bao phủ các trường hợp
Bước 6: Check bao phủ có thể thấy chưa có cặp Others-Check hay 0-Uncheck, vì vậy đổi vị
trí giá trị Check & Uncheck trên dòng 5 & 6
Bước 5 Bước 6
Cuối cùng, đã giảm số lượng testcase từ 24 case xuống 6 case.

.
3. Kỹ thuật chuyển trạng thái (1)
 Là phương pháp quan sát, theo dõi sự chuyển từ trạng thái này sang trạng thái khác khi có
sự kiện được điều khiển bởi user
 Bổ sung các ca kiểm thử để phát hiện ra lỗi mà có thể không phát hiện được bằng điều
kiện input, output bởi các phương pháp trên.
 Các bước thực hiện:
1. Tạo sơ đồ chuyển trạng thái
2. Xác định các case cần test bảo đảm cover hết tất cả các nhánh của sơ đồ trên

.
 Ví dụ:
Test chức năng đăng nhập của hệ thống
ATM
 Nếu người dùng nhập mật khẩu hợp
lệ => đăng nhập thành công
 Nếu người dùng nhập mật khẩu
không hợp lệ lần đầu hoặc lần 2 =>
yêu cầu nhập lại mật khẩu
 Nếu người dùng nhập mật khẩu
không hợp lệ lần thứ 3 trở đi => tài
khoản sẽ bị khóa
Start
Login
lần 1
Login
lần 2
Login
lần 3
Account Blocked Access Granted
Correct
Correct
Correct
Incorrect
Incorrect
Incorrect
1
2
3
4
5 6
Sơ đồ chuyển trạng thái

.
③ Kỹ thuật chuyển trạng thái (Tiếp)
Bảng chuyển trạng thái
 Các case cần test:
 1-2-3-4-5
 1-2-6
 1-2-3-6
 1-2-3-4-6

.
 Bài tập về nhà
Tạo bảng chuyển trạng thái và case cần test.

Kỹ thuật phân tích spec của data input
3.2

.
1. Kỹ thuật phân vùng tương đương (Equivalence
Partitioning)(1)
 Chia toàn bộ giá trị input thành các nhóm giá trị mà sinh ra kết quả giống
nhau (hợp lệ / không hợp lệ)

.
1. Kỹ thuật phân vùng tương đương (Equivalence
Partitioning)(2)
 Ví dụ:
Form login
Yêu cầu:
 Input vào ô text-box user với ký tự số, độ
dài trong khoảng [6-20] ký tự
 Nếu nhập ngoài khoảng [6-20] ký tự số
=> hiển thị lỗi “Bạn chỉ được phép nhập
chuỗi từ 6 => 20 ký tự”
 Các lớp tương đương được xác định như dưới đây

.
2. Kỹ thuật phân tích giá trị biên(1)
 Là trường hợp đặc biệt của phân lớp tương đương, dựa trên những phân vùng
tương đương tester sẽ xác định giá trị biên giữa những phân vùng này
 Một số quy tắc có thể xác định các giá trị biên:
 Giá trị biên nhỏ nhất và lớn nhất
 Giá trị gần kề lớn hơn và nhỏ hơn giá trị nhỏ nhất
 Giá trị gần kề lớn hơn và nhỏ hơn giá trị lớn nhất
 Giá trị nằm giữa giá trị nhỏ nhất và lớn nhất
 Giá trị 0 hoặc blank nếu nó nằm trong vùng valid hoặc có lý do đặc biệt

.
2. Kỹ thuật phân tích giá trị biên(2)
 Ví dụ:
Xác định giá trị biên của 1 mảng [-3, 10]
 Giá trị nhỏ nhất là -3
 Giá trị lớn nhất là 10
 Giá trị nhỏ hơn giá trị nhỏ nhất: -4
 Giá trị lớn hơn giá trị lớn nhất: 11
 Giá trị nằm giữa [-3,11]: 0

.
3. Giá trị đặc biệt (Special Value)
 Giá trị cần sử dụng đặc biệt, giá trị có ý nghĩa đặc biệt.
 Ví dụ:
Ngày 29/2 （Năm nhuận）
０ (Giá trị đặc biệt)
null (Giá trị đặc biệt)

.
4. Giá trị dựa theo kinh nghiệm (Error Based)
 Giá trị mà theo trí nhớ, kinh nghiệm trong quá khứ là có trouble.
 Ví dụ:
Chưa input (null test) , blank
Cũng có trường hợp giá trị Special Value cũng là Error Based.

.
5. Tổng hợp các loại test data cần nghĩ tới
① No data:
Giá trị blank, giá trị NULL, default data
② Valid data:
Tạo tập valid data để kiểm tra ứng dụng có hoạt động đúng theo yêu cầu và các dữ liệu đó có được lưu
chính xác vào database hoặc file không
③ Invalid data:
Chuẩn bị một tập các invalid data để kiểm tra ứng dụng có xử lý thích hợp với các giá trị bất thường
không. Ví dụ như hiển thị error message, không get được dữ liệu…
④ Các loại dữ liệu sai format:
Tạo ra một tập dữ liệu sai format. Hệ thống sẽ không accept dữ liệu, cũng có thể hiển thị error
message. Ví dụ như sai định dạng ngày tháng, định dạng phone number, định dạng email, v..v.
⑤ Các giá trị biên: bao gồm cả valid và invalid data
⑥ Dữ liệu cho test performance, load test…:
Chuẩn bị dữ liệu cho loại test này có lẽ là tốn công nhất. Có thể phải sử dụng tool tạo testdata để có
thể tạo ra được lượng data phù hợp

.
6. Bài tập
 Extract test case cần test cho xử lý dưới

.
1. Tạo test scenario
 Test scenario
 1 column của decision table chính là 1 test scenario.
 Điều kiện scenario là tích của từng điều kiện (DT row).
 Ví dụ: Login check module
45
Test scenario(TS)
ID
Điều kiện
(Confirm item)
Kết quả
(Kết quả mong
đợi)
1
Trường hợp format của login name, format của password là
valid,
login name có tồn tại, và password có match.
Được phép login
2
Trường hợp format login name là invalid.
Không được phép login
3
Trường hợp format login name là valid,
format của password là invalid.
4
Trường hợp Format của login name, format của password là
valid,
login name không tồn tại.
5
Trường hợp format của login name, format của password là
valid,
login name có tồn tại và password không match.
Decision table（DT)
◆Điều kiện 1 2 3 4 5
Format của login name là valid ＴＦＴＴＴ
Format của password là valid Ｔ－ＦＴＴ
Login name có tồn tại không? Ｔ－－ＦＴ
Password có match (trùng khớp) Ｔ－－－Ｆ
◆Kết quả
Được phép login. ○
Không được phép login ○ ○ ○ ○

.
2. Tạo test case (1)
 Kết hợp testdata và test scenario để tạo thành testcase.
 Ví dụ: Trường hợp scenario 3 của login check module
Input format của login name/password đều là kí tự chữ số tiếng Anh halfsize, có 4~8 kí tự.
Testcase
Test scenario
Điều kiện:
• Trường hợp Format của login
name là valid
• Format của password là invalid
Kết quả: Không thể login
Test data
Login name (Valid format)
"aB1c"，"aB1cD2eF"，"1aB2"，"1aB2cD3e"，
"abcdefgh"
Password (Invalid format)
"aB1"，"aB1cD2eF3"，"a1#cD%"，""， " "

.
2. Tạo test case (2)
 Các lưu ý khi viết testcase
 Step test chi tiết, đơn giản, minh bạch, dễ hiểu
 Mô tả rõ mục đích và phạm vi của testcase
 Mô tả điều kiện tiền đề, data test.
 Không gộp quá nhiều kết quả confirm vào 1 case.
 Testcase nên cover các trường hợp kiểm thử như: Phân lớp tương đương, giá
trị biên, điều kiện normal và abnormal.
 Cả các trường hợp free test không có trong đặc tả yêu cầu. ( có trường hợp
thực hiện free test ở phase coding thì không cần tạo test case)

DEV3_TestTraining.pptx

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to DEV3_TestTraining.pptx

Similar to DEV3_TestTraining.pptx (20)

Recently uploaded

Recently uploaded (19)

DEV3_TestTraining.pptx

Editor's Notes