Topics: 1. Sharing experience on software testings 2. Automation testing for web application 3. Testing techniques: Tips and tricks (for webapp) 4. How to plan testing, how to write effective test cases so that we can find more bugs 5. What is BDD and how to apply it software testing 6. The importance of developer testing (testing by developers) Contents Kỹ thuật kiểm thử - tips & tricks - Hộp đen - tester - Hộp trắng - developer testing - Kiểm thử đơn vị - automation, developer testing Kiểm thử web - webapp - Demo - Kinh nghiệm tự động với selenium - tips, automation, Phát triển theo hành vi - BDD - Giới thiệu BDD (behaviour driven development) - Demo behat

1. Kiểm thử Phần mềm
cho người lập trình và người kiểm thử
Trương Anh Hoàng
trình bày cho Septeni Technology, 7/7/2014
1

2. Duy Tan Geek, 2014/05/28. Hanoi. Nguyen Vu Hung. Licensed under CC BY
Septeni Technology

3. Tự giới thiệu
• Trương Anh Hoàng (truonganhhoang@gmail)
• Giảng viên ĐH Công nghệ - ĐHQGHN,
• Chủ nhiệm Bộ môn Công nghệ Phần mềm
• Môn chính: Công nghệ phần mềm và Kiểm thử và đảm bảo chất lượng phần
mềm
• Nghiên cứu về kiểm chứng phần mềm, phân tích chương trình, và kiểm thử tự
động
• Đào tạo
• CN. (90-94), ThS. (99-01) - ĐH Tổng hợp Hà Nội (nay ĐHKHTN – ĐHQGHN)
• TS (02-06) ở ĐH Bergen, NaUy
• Kinh nghiệm làm việc
• MITEC: bán vé tàu Thống nhất, nhiều người dùng, VB, Access, 1996-1997
• Olivetti: phần host của hệ thống ATM, Ngân hàng bán lẻ, C, Sun Solaris, 1998-
2001
• Punch Entertainment: làm trò chơi trên điện thoại di động, C++, BREW, J2ME,
2006-2007
• Trường ĐHCN: làm phần mềm trên nền web, truongnha.com, Python/Django,
mobile web, 2011-2012
3

4. Dự kiến
• Sharing experience on software testings
• Automation testing for web application
• Testing techniques: Tips and tricks (for webapp)
• How to plan testing, how to write effective test
cases so that we can find more bugs
• What is BDD and how to apply it software testing
• The importance of developer testing (testing by
developers)
4

5. Nội dung
• Kỹ thuật kiểm thử - tips & tricks
• Hộp đen - tester
• Hộp trắng - developer testing
• Kiểm thử đơn vị - automation, developer testing
• Kiểm thử web - webapp
• Demo
• Kinh nghiệm tự động với selenium - tips, automation,
• Phát triển theo hành vi - BDD
• Giới thiệu BDD
• Demo behat
5

6. Chương trình có lỗi?
//Đổi giá trị không dùng biến phụ
#include <stdio.h>
void swap(int *xp, int *yp)
{
*xp = *xp + *yp;
*yp = *xp - *yp;
*xp = *xp - *yp;
}
6

7. Kỹ thuật kiểm thử
• Kỹ thuật hộp đen/chức năng
• Giá trị biên, cận biên
• Lớp tương đương
• Bảng quyết định
• Từng đôi (pairwise)
• Kỹ thuật hộp trắng/cấu trúc
• Khái niệm, ý tưởng
• Tiêu chuẩn bao phủ
• Kiểm thử đơn vị
7

8. Kiểm thử hộp đen/chức năng
• Tập trung vào chức năng của chương trình/mô-đun
• Kiểm tra chương trình chạy đúng như mong đợi
• Không thể kiểm tra hết tất cả các trường hợp
• => Bài toán đặt ra: giảm số lượng ca kiểm thử
• Phương pháp chung: chia không gian đầu vào thành các miền
tương đương, sau đó chọn một ca kiểm thử từ mỗi miền
tương đương này.
• Dễ thực hiện với một vài biến/trường nhập liệu
• Không đơn giản khi hàm có nhiều biến hoặc màn hình có nhiều
trường nhập liệu
• Tổ hợp tất cả các trường hợp sẽ tăng số ca kiểm thử rất nhanh
• Một số kỹ thuật: giá trị biên, lớp tương đương, bảng
quyết định, từng đôi (pairwise)
8

9. Kiểm thử giá trị biên
• Kiểm thử giá trị biên (boundary value analysis)
• Kiểm thử giá trị biên thông thường
• Ví dụ với 1 biên [a,b] sẽ lấy 5 ca kiểm thử
• 2 biên a, b (lỗi thường xảy ra ở biên)
• 2 cận biên a+, b- (lỗi thường xảy ra ở cận biên)
• (a+b)/2 (đại diện dữ liệu thông thường, đúng)
• Với nhiều biến hơn
• Lấy một giá trị đại diện, rồi lần lượt thay thế các biên, cận biên để
tạo ca kiểm thử mới
• Ví dụ thêm [c,d]
• <(a+b)/2, (c+d)/2>, <(a+b)/2, c>, <(a+b)/2, c+>, <(a+b)/2, d->,
<(a+b)/2, d>,
• <a, (c+d)/2>, <a+, (c+d)/2>, <b-, (c+d)/2>, <b, (c+d)/2>
• Phát hiện được các lỗi thông thường
9

10. Kiểm thử giá trị biên
• Một số biến thể
• Kiểm thử giá trị biên mạnh
• Thêm giá trị ngoài khoảng, với [a,b] thì lấy thêm a- và b+
• Kiểm thử giá trị biên tổ hợp
• Tổ hợp các bộ giá trị có thể của các biên
• 4n + 1 ca kiểm thử
• Kiểm thử với giá trị đặc biệt, ví dụ 0
• Nhược điểm
• Không hiệu quả khi các đầu vào có ràng buộc với nhau
• Tạo ra nhiều ca kiểm thử thừa, không hợp lệ, ví dụ: 31/2
• Không khai thác thông tin về chương trình hay ý nghĩa của
biến
• Ưu điểm
• Đơn giản, dễ tự động hóa
10

11. Kiểm thử phân hoạch tương
đương
• Phân hoạch: chia miền đầu vào thành các lớp tương
đương
• Hợp của tất cả các lớp bằng miền đầu vào
• Cảm giác đã kiểm thử hết
• Hai lớp bất kỳ không giao nhau
• Không dư thừa
• Mỗi lớp gồm các giá trị ‘tương đương’ theo nghĩa các
giá trị sẽ cùng gây ra hành vi như nhau đối với chương
trình
• => Bài toán đặt ra là làm sao chọn được quan hệ tương
đương để từ đó xác định được các lớp tương đương
(phân hoạch)
11

12. Kiểm thử lớp tương đương
• Chọn phân hoạch
• Thường là “thủ công” (craft):
• Chỉ dựa trên đặc tả (không dựa trên mã nguồn)
• Cần có hiểu biết về miền xác định
• Thường khó có thể xác định dựa vào đặc tả thiết kế giao diện
• Phải hiểu đầu vào phụ thuộc nhau như thế nào
12

13. Kiểm thử lớp tương đương - Ví dụ
• Xét chương trình P có ba biến đầu vào: a, b và c với các
miền xác định là A, B, and C.
• Phân hoạch của các miền này giả sử là:
• Gọi ai thuộc Ai là một phần tử đại diện của lớp
• Ví dụ lấy phần tử giữa của 1 khoảng
• Tương tự có bi và ci.
• Các ca kiểm thử sẽ được xây dựng từ các phần tử đại
diện này
13
A = A1 U A2 U A3
B = B1 U B2 U B3 U B4
C = C1 U C2

14. Kiểm thử lớp tương đương yếu
• Chỉ lấy tất cả các phần tử đại diện ít nhất một lần
• Số ca kiểm thử tối thiểu sẽ bằng số lớp của phân hoạch
có nhiều tập con nhất
• Trong ví dụ trước là 4
14
# a b c
WE1 a1 b1 c1
WE2 a2 b2 c2
WE3 a3 b3 c1
WE4 a1 b4 c2

15. Kiểm thử lớp tương đương mạnh
• Dựa trên tích Đề-các của các lớp con
• Với ví dụ trước ta có:
3 * 4 * 2 = 24 ca kiểm thử
• Cách này xét đến tất cả các tương tác của các giá trị đại
diện
• Áp dụng được cho cả miền đầu ra
• Ưu điểm
• Nếu kiểm tra cả giá trị không hợp lệ thì cần thêm các lớp
tương đương ngoài khoảng xác định
• Thích hợp với đầu vào là khoảng hoặc tập các giá trị rời rạc
• Có thể kết hợp với giá trị biên
15

16. Kiểm thử dựa trên bảng quyết
định
• Bảng quyết định - BQĐ (decision table)
• Yêu cầu chức năng có thể mô tả bằng bảng BQĐ
• BQĐ mô tả logic phức tạp ngắn gọn và chính xác
• Gắn các điều kiện với các hành động tương ứng
• Giống lệnh if-then-else và switch-case
• BQĐ có thể liên kết nhiều điều kiện độc lập với vài hành
động một cách dễ hiểu
• Khác các cấu trúc điều khiển trong các ngôn ngữ lập trình
16

17. Bảng quyết định
• Yêu cầu chức năng có thể mô tả bằng bảng quyết
định (BQĐ)
• BQĐ là một cách chính xác và gọn để mô tả logic
phức tạp
• Gắn các điều kiện với các hành động tương ứng
• Giống lệnh if-then-else và switch-case
• BQĐ có thể liên kết nhiều điều kiện độc lập với vài
hành động một cách dễ hiểu
• Khác các cấu trúc điều khiển trong các ngôn ngữ lập
trình
17

18. Ví dụ về bảng quyết định
Điều kiện
Máy in không in Y Y Y Y N N N N
Đèn đỏ nhấp nháy Y Y N N Y Y N N
Không nhận ra máy in Y N Y N Y N Y N
Hành động
Kiểm tra dây nguồn X
Kiểm tra dây tín hiệu X X
Kiểm tra phần mềm in đã cài đúng X X X X
Kiểm tra/thay mực X X X X
Kiểm tra kẹt giấy X X
Khắc phục sự cố máy in
18

19. Ví dụ bảng quyết định tính lương
Cách tính lương
19

20. Sử dụng bảng quyết định
• Để dễ quan sát tất cả các điều kiện
• Có thể dùng để
• Mô tả logic phức tạp
• Sinh ca kiểm thử, còn gọi là kiểm thử dựa trên logic
• Kiểm thử dựa trên logic được xem là:
• Kiểm thử cấu trúc khi áp dụng cho các cấu trúc chương
trình
• Vd luồng điều khiển
• Kiểm thử hàm khi áp dụng cho đặc tả
20

21. Sử dụng bảng quyết định
• Bảng thích hợp khi:
– Đặc tả có thể chuyển về dạng bảng
– Thứ tự các hành động xảy ra không quan trọng
– Thứ tự các luật không ảnh hưởng đến hành động
– Khi một luật thỏa mãn và được chọn thì không cần xét
luật khác
• Các hạn chế trên không ảnh hưởng đến việc sử
dụng bảng
• Trong hầu hết các ứng dụng thứ tự các mệnh đề được
xét là không quan trọng
21

22. Một số vấn đề với bảng quyết
định
• Trước khi sử dụng bảng cần đảm bảo:
• Các luật phải đầy đủ
• Có mọi tổ hợp
• Các luật phải nhất quán
• Mọi tổ hợp giá trị chân lý chỉ gây ra một tập hành động
22

23. Thiết kế ca kiểm thử
• Để xác định ca kiểm thử, chúng ta chuyển các điều
kiện thành đầu vào, hành động thành đầu ra
• Một số điều kiện sẽ tham chiếu đến các lớp tương
đương đầu vào, và hành động tham chiếu đến các
phần xử lý chức năng chính của cột đang xét
• Các luật được chuyển thành các ca kiểm thử
23

24. Kinh nghiệm với kiểm thử dựa
trên bảng quyết định
• Bảng quyết định phù hợp khi
– Có nhiều quyết định đưa ra
– Có các quan hệ logic quan trọng giữa các biến đầu vào
– Có các tính toán liên quan đến các tập con của các biến
đầu vào
– Có quan hệ nhân quả giữa đầu vào và đầu ra
– Có logic tính toán phức tạp (độ phức tạp đồ thị
cyclomatic cao)
• Bảng quyết định không dễ mở rộng (scale up)
• Bảng quyết định có thể làm mịn, cải tiến dần
24

25. Kiểm thử từng đôi
• Tiếng Anh: pairwise testing, combinatorial testing
• Thực tế quan sát cho thấy, hầu hết lỗi do kết hợp
của 2 yếu tố/tham số
• => Kiểm thử từng đôi sinh bộ kiểm thử chứa tất cả
các cặp giá trị cần kiểm thử của các biến
• Giảm đáng kể số lượng ca kiểm thử
• Vẫn hiệu quả trong việc phát hiện lỗi (50-90%)
25

26. Ví dụ
• All pairs: 3x2x2x2x2=48 ca
• Pairwise: 6 ca kiểm thử
Combin
ation
Seattype Bedlinen Tea Gypsies Demobe
es
1 Berth X X X X
2 Berth _ _ _ _
3 Coupe X _ X _
4 Coupe _ X _ X
5 Lux X X _ _
6 Lux _ _ X X
unX
26

27. • 13 ca kiểm thử là
đủ
cho tất cả các tổ
hợp bộ 3
• Tất cả các tổ hợp
là 1024.
0 = effect off
1 = effect on
Ví dụ
27

28. Nhận xét về kiểm thử từng đôi
• Có nhiều công cụ, thuật toán cho
• http://www.pairwise.org/tools.asp
• Sinh ra tất cả các cặp với số ca kiểm thử ít nhất
• Sử dụng pairwise khi cần thiết
• Rất nhiều biến/tham số và lỗi xảy ra sẽ nghiêm trọng
• Giảm đáng kể số ca kiểm thử
28

29. Kỹ thuật kiểm thử hộp
trắng
Ý tưởng
29

30. Kiểm thử hộp trắng/cấu trúc
• Kiểm thử hộp trắng dựa trên mã nguồn để xây
dựng các ca kiểm thử và kiểm tra đầu ra.
• Cụ thể nó dựa trên:
• Các định nghĩa chặt chẽ liên quan đến ngữ nghĩa của
ngôn ngữ lập trình
• Luồng điều khiển, luồng dữ liệu, mục tiêu, tiêu chuẩn bao phủ
• Phân tích toán học
• Phân tích đồ thị, đường đi
• Các phép đo chính xác
• Bao phủ
30

31. Định nghĩa đồ thị chương trình
• Cho một chương trình trong ngôn ngữ mệnh lệnh, đồ thị
chương trình của nó là một đồ thị có nhãn, có hướng
trong đó
• Đỉnh là các nhóm lệnh hoặc một phần của một lệnh
• Cạnh là luồng điều khiển
31

32. FindMean (FILE ScoreFile)
{ float SumOfScores = 0.0;
int NumberOfScores = 0;
float Mean=0.0; float Score;
Read(ScoreFile, Score);
while (! EOF(ScoreFile) {
if (Score > 0.0 ) {
SumOfScores = SumOfScores + Score;
NumberOfScores++;
}
Read(ScoreFile, Score);
}
/* Compute the mean and print the result */
if (NumberOfScores > 0) {
Mean = SumOfScores / NumberOfScores;
printf(“ The mean score is %fn”, Mean);
} else
printf (“No scores found in filen”);
}
1
2
3
4
5
7
6
8
9
32

33. Đồ thị chương trình
33

34. Độ đo bao phủ
• Độ đo bao phủ là dụng cụ để đo mức độ bộ kiểm
thử phủ (cover) chương trình đến đâu
• Một số độ đo thông dụng
34
Độ đo Mô tả Nhận xét
C0 Tất cả các lệnh Yếu, chưa đủ
C1 Tất cả các nhánh Tạm đủ
C1P Từng kết quả của mọi mệnh đề (điều kiện) Nên áp dụng
C2 C1 + bao phủ vòng lặp Nên áp dụng
CMCC Bao phủ các điều kiện phức Nên áp dụng
C∞ Mọi đường đi có thể
...
Không thực tế

35. Thảo luận
• Người lập trình phải làm bằng các hàm kiểm thử
đơn vị
• Người kiểm thử không làm được
• Công ty nên đưa ra chính sách
• Ví dụ: đạt 70% tiêu chuẩn C1
• Công cụ đo mức độ bao phủ hầu hết có sẵn
35

36. Kiểm thử hộp trắng cao cấp
• Data flow testing
• Slide base testing
• Model-based
• Không dễ áp dụng
read (z)
x = 0
y = 0
if (z  0)
{
x = sqrt (z)
if (0  x && x  5)
y = f (x)
else
y = h (z)
}
y = g (x, y)
print (y)
Definition / Use
1 main( )
2 {
3 int i, sum;
4 sum = 0;
5 i = 1;
6 while(i <= 10)
7 {
8 sum = sum + 1;
9 ++ i;
10 }
11 Cout<< sum;
12 Cout<< i;
13 }
<12, i>
36

37. Tổng kết kỹ thuật kiểm thử hộp
đen và trắng
• Hộp đen
• Kiểm thử viên cần biết để chọn tổ hợp các kỹ thuật để áp
dụng tùy thuộc vào tính chất bài toán, loại lỗi cần tìm
• Nhanh, đơn giản: giá trị biên + ngoài biên
• Vừa: lớp tương đương, tổ hợp
• Kỹ, đầu tư: bảng quyết định
• Hộp trắng
• Người lập trình PHẢI viết kiểm thử đơn vị cho phần mã mình
viết ra
• Nên đặt ra tiêu chuẩn bao phủ, cho từng dự án, từng đội,
hoặc cả công ty
• Nộp mã nguồn vào repo sau khi tất cả các kiểm thử đơn vị
thành công hết
37

38. Kiểm thử ứng dụng web
Selenium và kinh nghiệm
38

39. Các khía cạnh đánh giá một
webapp
• Kiểm thử chức năng
• Không bàn đến
• Kiểm thử nội dung, cấu trúc,
• Kiểm thử dễ dùng, dễ điều hướng
• Kiểm thử thuộc tính chất lượng (phi chức năng) khác:
performance, compatibility, security, ..
39

40. Thách thức với kiểm thử chức
năng webapp
• Nhiều trình duyệt, nhiều kích thước màn hình,
nhiều hệ điều hành
• Nhiều cách tương tác: touch, mouse, keyboard
• => Tự động hóa sẽ tiết kiệm lớn so với công sức
đầu tư
• Selenium
• Mức kiểm thử viên, dùng IDE, record/playback
• Mức lập trình viên, dùng thư viện, viết mã kiểm thử đơn vị,
chức năng
• BDD
• Tự động kiểm thử chấp thuận
40

41. Kiểm thử viên với Selenium IDE
• Record/Playback thường chưa đủ
• Mã (xpath) sinh ra không tối ưu
• Khi chương trình bị sửa giao diện, dễ làm playback không chạy
được nữa
• Cần hiểu mã sinh ra và chỉnh sửa thêm, làm bằng tay
• Kiểm thử viên nên được đào tạo để có thể làm được việc này
• Hoặc nên có lập trình viên để làm việc này
• Mục đích sửa là để các ca kiểm thử tự động ổn định
• Ví dụ: sửa selector bằng ID, text/name nếu biết đoạn text đó duy
nhất trên màn hình
• Thực hiện khi thiết kế giao diện tương đối ổn định
• Tạo shell command để kiểm thử viên chạy tự động,
không phải thao tác trên IDE mỗi lần
41

42. Demo Selenium
42

43. Hỗ trợ kiểm thử từ người lập trình
khi làm giao diện
• Mã HTML sinh ra phải tuân thủ chuẩn (validate HTML)
• Nên có ID cho các phần tử, đôi khi chỉ để phục vụ kiểm
thử
• ID giúp các ca kiểm thử selenium ổn định, không phụ thuộc
cấu trúc trang web
• Chỉ dùng một số selector ít bị ảnh hưởng bởi thay đổi
giao diện
• ID, Text, ...
• Khi refactor mã nguồn, chỉnh luôn test scripts nếu bị
ảnh hưởng
• Người lập trình sửa mã nguồn, xong chạy các ca kiểm thử,
nếu fails thì sửa
• Giảm giao đổi giữa người lập trình, người kiểm thử
43

44. Lập trình viên với Selenium
• Viết kiểm thử chức
năng
• Đa số framework hỗ
trợ
• Tập trung vào các
trường hợp đúng
trước
<?php
class WebTest extends PHPUnit_Extensions_Selenium2TestCase
{
protected function setUp()
{
$this->setBrowser('firefox');
$this->setBrowserUrl('http://www.example.com/');
}
public function testTitle()
{
$this->url('http://www.example.com/');
$this->assertEquals('Example WWW Page', $this->title());
}
}
?>
44

45. Tổng kết với Selenium
• Vai trò của người lập trình với kiểm thử rất quan
trọng
• phải có trách nhiệm hỗ trợ tạo điều kiện cho kiểm thử
viên, sẽ tăng hiệu quả chung của cả đội
• Kiểm thử viên tìm các lỗi khó lường khác
• Giao diện, tương thích, hiệu năng, v.v.
• Khi có lỗi, bổ sung thêm ca kiểm thử tự động
• Tránh không bị lặp lại
• Đặc biệt những lỗi do khách hàng đã chỉ ra
• Thiết kế giao diện phải chú ý vấn đề hỗ trợ kiểm
thử bằng selenium
45

46. BDD
Behaviour Driven Development
Giới thiệu, demo behat
46

47. BDD – Phát triển hướng hành vi
• TDD: viết mã kiểm thử trước khi mã chương trình
• Vấn đề của TDD:
• Khách hàng khó có thể đọc được mã kiểm thử,
• Đọc được cũng khó có thể khẳng định chúng đã đúng mong
muốn của họ chưa
• Ngôn ngữ mã kiểm thử khác ngôn ngữ của khách hàng
• Giải pháp là BDD
• Mở rộng/phát triển của TDD
• Dùng chính mô tả của khách hàng làm cơ sở để kiểm thử
• Một tính năng sẽ được cụ thể hóa bằng các các ví dụ - được dùng
làm các ca kiểm thử
• BDD không chỉ là tự động kiểm thử
• BDD là thay đổi tư duy về cách phát triển phần mềm
47

48. Mục tiêu của BDD
• Phần mềm được phát triển theo hướng mang lại
các giá trị kinh doanh (business value)
• Viết mã kiểm thử trước, viết chương trình sau
• Làm từng phần nhỏ
• Tạo điều kiện để yên tâm cải tiến mã nguồn
(refactor)
• Lợi ích
• Giảm thời gian viết chương trình
• Khuyến khích hợp tác trong toàn đội
• Tăng tính mô-đun, mềm dẻo, và dễ mở rộng
48

49. Qui trình TDD
From http://www.agiledata.org/essays/tdd.html
49

50. Qui trình BDD
From http://www.agiledata.org/essays/tdd.html
50

51. Đặc tả bằng ví dụ
• Giúp làm rõ yêu cầu của một chức năng
• Hành vi được cụ thể bằng các ví dụ và là tiêu chuẩn
(cần) để nghiệm thu
Behavior = Examples = Acceptance Criteria
• Mỗi ví dụ sẽ là một ca kiểm thử (ở cả mức đơn vị,
hệ thống và chấp thuận)
• Là đầu vào để phát triển viết phần mềm
51

52. Ví dụ về đặc tả bằng ví dụ
Feature: Search courses
Courses should be searchable by topic
Search results should provide the course code
Scenario: Search by topic
Given there are 240 courses which do not have the topic "biology"
And there are 2 courses A001, B205 that each have "biology" as one of the topics
When I search for "biology"
Then I should see the following courses:
| Course code |
| A001 |
| B205 |
52

53. Qui trình
• Dựa trên yêu cầu (user story/feature) xác định các
ví dụ cụ thể (scenarios)
1. Giao cho một nhóm thực hiện,
2. Cả đội cùng phê duyệt
• Tất cả khách hàng, quản lý dự án, chuyên viên phân tích nghiệp
vụ (BA), đội phát triển (lập trình viên và kiểm thử viên) sẽ kiểm
tra và duyệt các yêu cầu, ví dụ
3. Viết chức năng phần mềm (implementation)
4. Khi tất cả các ca kiểm thử bằng ví dụ chạy đúng thì phần
mềm là hoàn thành
53

54. Giới thiệu nhanh về behat
• Behat
• http://docs.behat.org/quick_intro.html
• Cài đặt
• Chạy được trên Linux, Windows
• Sử dụng
1. Tạo cấu trúc: behat --init
2. Viết các feature, các scenario
3. Chạy kiểm thử (chấp thuận), lúc đầu sẽ toàn lỗi
4. Viết mã thực hiện cho các bước trong scenario, cài đặt chức
năng phần mềm
5. Chạy lại kiểm thử ở bước 3, nếu có lỗi làm tiếp bước 4, nếu
hết lỗi có nghĩa phần mềm đã hoàn thành – đã thực hiện
chức năng mà đại diện là các ví dụ đã chạy tốt
54

55. Feature
55

56. Scenario
56

57. 57

58. 58

59. 59

60. Demo behat
• http://docs.behat.org/quick_intro.html
60

61. Công cụ khác
• Coding standards/style checkers,
Unit testing, Coverage,..
• BDD
• Codeception: BDD-like
• PhpSpec
• Khác
• http://robotframework.org/
• A generic test automation framework
<?php
$I = new AcceptanceTester($scenario);
$I->wantTo('create wiki page');
$I->amOnPage('/');
$I->click('Pages');
$I->click('New');
$I->see('New Page');
$I->fillField('title', 'Hobbit');
$I->fillField('body', 'By Peter Jackson');
$I->click('Save');
$I->see('page created'); // notice generated
$I->see('Hobbit','h1'); // head of page of is our title
$I->seeInCurrentUrl('pages/hobbit');
$I->seeInDatabase('pages', array('title' => 'Hobbit'));
?>
61

62. Tổng kết
• Nhiều kỹ thuật kiểm thử, hộp đen, hộp trắng,
nhưng (dường như) ít được để ý, áp dụng
• Chú ý kiểm thử biên + từng đôi, lớp tương đương … có
thể dựa trên trực giác
• Nhiều công cụ, thư viện cho kiểm thử viên, cho
người lập trình
• Kiểm thử viên: Selenium IDE
• Kiểm tra tương thích trình duyệt
• Lập trình viên: Chú ý kiểm thử đơn vị, chức năng và đạt
tiêu chuẩn bao phủ (cần, chưa đủ)
62

63. Tổng kết
• BDD: phương pháp làm phần mềm lấy kiểm thử chấp
thuận làm gốc
• Xu hướng (hiện đại), nên đầu tư nghiên cứu, ứng dụng
• Phải đầu tư nhiều hơn, nhưng được bù đắp về lâu dài
• Người lập trình phải viết mã kiểm thử, bảo trì chúng
• Người kiểm thử
• Kiểm tra lại các chức năng khi phát hành (release)
• Phát hiện thêm các lỗi không lường trước được hết
• Kiểm thử các yêu cầu chất lượng: usability, performance, …
• Một dự án phần mềm ngày nay cần kèm theo một dự
án kiểm thử nó, với qui mô, kích cỡ không kém
• Giúp phát triển bền vững, đảm bảo chất lượng, giúp phát
hành liên tục
63

64. Q&A
Thanks!
64Slide có sử dụng nhiều ví dụ, hình ảnh tham khảo trên Internet