Tải bản đầy đủ

Kiểm thử sản phẩm thương mại điện tử trên nền wordpress sử dụng công cụ selenium

LỜI CẢM ƠN
Em xin chân thành cảm ơn các thầy giáo, cô giáo Khoa Công nghệ thông tin
của trường Đại học Công nghệ thông tin và truyền thông Thái Nguyên và các thầy
cô của trường Đại học Công nghệ thông tin và truyền thông Thái Nguyên đã tạo
điều kiện thuận lợi cho em trong quá trình học tập năm năm qua và trong quá trình
thực hiện đồ án tốt nghiệp. Em xin gửi lời cảm ơn đặc biệt đến Thạc sỹ Nguyễn
Thu Phương - bộ môn Công nghệ phần mềm đã nhiệt tình hướng dẫn và chỉ bảo
em trong suốt thời gian thực hiện đồ án.
Em xin cũng xin gửi lời cảm ơn chân thành đến gia đình, bạn bè và các anh
chị đồng nghiệp tại Trung tâm nghiên cứu và phát triển ứng dụng di động - Trường
Đại học Công nghệ thông tin và truyền thông Thái Nguyên đã hết lòng hỗ trợ em
trong thời gian thực hiện đồ án.
Thái Nguyên, ngày 15 tháng 05 năm 2016
Sinh viên
Đinh Thị Thắm

1


LỜI CAM ĐOAN
Tôi Đinh Thị Thắm xin cam đoan:

 Đồ án tốt nghiệp là thành quả từ sự nghiên cứu hoàn toàn thực tế trên cơ
sở các số liệu thực tế và được thực hiện theo hướng dẫn của giáo viên hướng dẫn.
 Đồ án được thực hiện hoàn toàn mới, là thành quả của riêng tôi, không
sao chép theo bất cứ đồ án tương tự nào.
 Mọi sự tham khảo sử dụng trong đồ án đều được trích dẫn các nguồn tài
liệu trong báo cáo và danh mục tài liệu tham khảo.
 Mọi sao chép không hợp lệ, vi phạm quy chế của nhà trường, tôi xin
hoàn toàn chịu trách nhiệm
Thái Nguyên, ngày 15 tháng 05 năm 2016
Sinh viên
Đinh Thi Thắm

2


MỤC LỤC
LỜI CẢM ƠN 1
LỜI CAM ĐOAN
MỤC LỤC

2

3

DANH MỤC HÌNH ẢNH
MỞ ĐẦU

5

6

CHƯƠNG 1 TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM, KIỂM THỬ TỰ ĐỘNG VÀ
PHẦN MỀM MÃ NGUỒN MỞ WORDPRESS

8

1.1. Tổng quan về kiểm thử phần mềm

8


1.1.1. Khái niệm về kiểm thử phần mềm 8
1.1.2. Mục đích của kiểm thử phần mềm. 8
1.1.3. Các phương pháp kiểm thử 9
1.1.4. Chiến lược kiểm thử 9
1.1.5. Các cấp độ kiểm thử phần mềm

10

1.1.6. Mô hình chữ V trong kiểm thử phần mềm 14
1.1.7. Nguyên tắc trong kiểm thử phần mềm
1.2. Phần mềm mã nguồn mở WordPress
1.2.1. WordPress là gì?

15

16

16

1.2.2. Những thành tựu của WordPress 16
1.2.3. Ưu, nhược điểm của WordPress

17

1.2.4. Kiểm thử theme WordPress 18
CHƯƠNG 2 KIỂM THỬ ỨNG DỤNG WEBSITE SỬ DỤNG CÔNG CỤ KIỂM THỬ
TỰ ĐỘNG

21

2.1. Kiểm thử ứng dụng website

21

2.1.1. Sự khác biệt giữa kiểm thử website và kiểm thử phần mềm
2.1.2. Các đặc thù của kiểm thử website 21
3

21


2.2. Khảo sát các công cụ kiểm thử ứng dụng website

24

2.2.1. Quicktest professional 24
2.2.2. Apache Jmeter 25
2.2.3. Load Runner

25

2.2.4. Web link Validator (WLV)

26

2.2.5. Selenium 27
2.3. Đề xuất

28

2.4. Hướng dẫn sử dụng Selenium IDE và Selenium WebDriver 29
2.4.1. Selenium IDE

29

2.4.2. Selenium WebDriver 35
CHƯƠNG 3 KIỂM THỬ SẢN PHẨM THƯƠNG MẠI ĐIỆN TỬ TRÊN NỀN
WORDPRESS SỬ DỤNG CÔNG CỤ SELENIUM 43
3.1. Giới thiệu sản phẩm
3.2. Bài toán

43

43

3.3. Kế hoạch kiểm thử 45
3.4. Xây dựng test case 50
3.5. Thực thi các test case bằng công cụ Selenium 52
3.6. Kết quả thực hiện các test case của chức năng đăng kí
3.7. Báo lỗi lên công cụ quản lí dự án Taiga.io
KẾT LUẬN VÀ ĐỊNH HƯỚNG PHÁT TRIỂN
TÀI LIỆU THAM KHẢO

61

4

59

55

52


DANH MỤC HÌNH ẢNH
Hình 1.1 Các cấp độ kiểm thử phần mềm

11

Hình 1.2 Mô hình chữ V trong kiểm thử phần mềm 14
Hình 1.3 Logo của WordPress

16

Hình 1.4 Plugin Theme Check

18

Hình 1.5 Các lỗi bỏ qua trong Theme Check 19
Hình 1.6 Plugin Theme Mentor 19
Hình 1.7 Plugin Debug Bar

20

Hình 2.1 Tải Selenium IDE

29

Hình 2.2 Cài đặt Selenium IDE 30
Hình 2.3 Giao diện Selenium IDE

30

Hình 2.4 Các icon của Selenium IDE

31

Hình 2.5 Nhập website muốn kiểm tra 33
Hình 2.6 Các lệnh có sẵn của Selenium IDE
Hình 2.7 Tải Java SDK và Java SE

34

36

Hình 2.8 Giao diện của Eclipse 37
Hình 2.9 Download Selemnium WebDriver với Java 37
Hình 2.10 Tạo một project Java mới

38

Hình 2.11 Nhập các thư viện Selenium 38
Hình 2.12 Export test case sang ngôn ngữ bậc cao 41
Hình 2.13 Kết quả chạy với TestNG trong cửa sổ Results
Hình 2.14 Thư mục test-output 42
Hình 2.15 Kết quả của file index.html 42
Hình 3.1 Giao diện trang Flaton 43
Hình 3.2 Test case của chức năng đăng kí (1) 52
Hình 3.3 Test case của chức năng đăng kí (2) 52
5

41


Hình 3.4 Kết quả chạy với TestNG của cả package

54

Hình 3.5 Kết quả chạy cả package trong file index.html
Hình 3.6 Lỗi do Theme Check phát hiện

55

56

Hình 3.7 Lỗi do Debug Bar phát hiện 58
Hình 3.8 Các lỗi được đưa lên công cụ quản lí dự án Taiga.io

58

MỞ ĐẦU
 Lí do chọn đề tài
Hiện nay ngành công nghệ thông tin ngày càng phát triển không chỉ trên thế
giới nói chung mà còn ở Việt Nam nói riêng. Song song bên việc xây dựng và phát
triển các sản phẩm công nghệ thì việc đảm bảo chất lượng sản phẩm cũng là khâu
sống còn cho dự án. Chính vì vậy kiểm thử phần mềm ngày càng được quan tâm
và chú trọng hơn.
Cùng với sự phát triển của công nghệ phần mềm, lỗi phần mềm và chất
lượng phần mềm luôn là thách thức lớn với bản thân ngành phần mềm khi thực tế
đã chứng minh, kiểm thử phần mềm là giai đoạn chiếm đến hơn 40% thời gian,
kinh phí và nguồn nhân lực phát triển dự án phần mềm. Tuy nhiên ở Việt Nam
hiện nay, việc kiểm thử phần mềm vẫn chưa thực sự được nhìn nhận đúng với tầm
quan trọng của nó. Điều này thể hiện ở tỷ lệ kỹ sư kiểm thử phần mềm ở Việt Nam
còn khá thấp, cứ năm lập trình viên thì mới có một kỹ sư kiểm thử (số liệu thống
kê năm 2011 của công ty LogiGear), trong khi tỷ lệ này theo chuẩn quốc tế là 3:1.
Ngày nay, tự động hóa đang được nghiên cứu và ứng dụng trong nhiều lĩnh
vực trong đó công nghệ phần mềm nói chung và kiểm thử phần mềm nói riêng
cũng không ngoại lệ. Khi mà kiểm thử phần mềm vẫn tiêu tốn một lượng lớn thời
gian, kinh phí và nhân lực trong một dự án phần mềm thì song song với kiểm thử
truyền thống thủ công, sự ra đời của các công cụ hỗ trợ kiểm thử tự động như
Quick Test Professional, Nunit, Junit, Load Runner, JMetter (thường dùng trong
kiểm thử hiệu năng) là tất yếu. Selenium là một công cụ kiểm thử các ứng dụng
web có khá nhiều ưu điểm như có thể kiểm thử trên nhiều trình duyệt, hỗ trợ nhiều
6


ngôn ngữ lập trình, giao tiếp được với các công cụ kiểm thử khác như Junit,
testNG (với Java) hay Nunit (với C#), và ưu điểm đặc biệt của công cụ này là nó là
một bộ mã nguồn mở, do đó các tổ chức sẽ không tốn kinh phí mua bản quyền.
Tuy chưa được ứng dụng nhiều trong các tổ chức ở Việt Nam, song với những ưu
điểm trên, Selenium hứa hẹn sẽ ngày càng phát triển và trở lên thông dụng hơn
trong các tổ chức phát triển phần mềm ở nước ta. Với mong muốn có cái nhìn xác
thực, rõ ràng hơn về kiểm thử phần mềm và tiếp cận được với công cụ kiểm thử tự
động Selenium để làm tiền đề cho định hướng tương lai khi tốt nghiệp đại học sẽ
trở thành một kỹ sư kiểm thử phần mềm, cá nhân em lựa chọn để tài “Kiểm thử
sản phẩm thương mại điện tử trên nền WordPress sử dụng công cụ Selenium”
làm đề tài cho đồ án tốt nghiệp đại học của mình. Trong khuôn khổ đồ án, do thời
gian và kinh nghiệm thực tế còn hạn chế nên có những phần thực hiện chưa được
tốt, em rất mong nhận được sự góp ý của thầy cô và các bạn.
 Mục tiêu nghiên cứu
 Có cái nhìn đúng đắn và sâu sắc hơn về các vấn đề cơ bản kiểm thử
phần mềm và phần mềm mã nguồn mở WordPress.
 Hiểu rõ về các thành phần của bộ công cụ Selenium.
 Nắm được cách thức sử dụng của hai công cụ là Selenium IDE và
Selenium WebDriver.
 Ứng dụng các kiến thức kiểm thử phần mềm và kiến thức về Selenium
để viết kịch bản kiểm thử cho một ứng dụng cụ thể.
 Bố cục nội dung của đồ án
Đồ án được chia thành ba chương với nội dung như sau:
 Mở đầu: Chương này trình bày về lý do chọn đề tài, mục tiêu nghiên
cứu đồ án và bố cục nội dung của đồ án.
 Chương 1: Tổng quan về kiểm thử phần mềm và phần mềm mã
nguồn mở WordPress: Chương này trình bày những kiến thức cơ bản về kiểm thử
7


phần mềm như các nguyên tắc kiểm thử, các phương pháp kiểm thử, các giai đoạn
kiểm thử phần mềm và tổng quan về phần mềm mã nguồn mở WordPress.
 Chương 2: Kiểm thử ứng dụng website sử dụng công cụ kiểm thử tự
động: Chương này trình bày tổng quan về bộ công cụ Selenium, đi sâu vào các
thao tác với Selenium IDE và Selenium WebDriver.
 Chương 3: Kiểm thử sản phẩm thương mại điện tử trên nền
WordPress sử dụng công cụ Selenium: Chương này trình bày kịch bản kiểm thử
viết cho một số chức năng cơ bản của ứng dụng web
http://demo.roadthemes.com/flaton/ và thử nghiệm một số trường hợp kiểm
thử tự động viết bằng Selenium IDE và Selenium WedDriver.
 Kết luận: Chương này đưa ra những kết quả đồ án đạt được, những
thiếu sót chưa thực hiện được và hướng phát triển đề tài trong tương lai.
CHƯƠNG 1
TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM, KIỂM THỬ TỰ ĐỘNG
VÀ PHẦN MỀM MÃ NGUỒN MỞ WORDPRESS
1.1. Tổng quan về kiểm thử phần mềm
1.1.1. Khái niệm về kiểm thử phần mềm
Kiểm thử phần mềm là quá trình khảo sát một hệ thống hay thành phần dưới
những điều kiện xác định, quan sát và ghi lại các kết quả, và đánh giá một khía
cạnh nào đó của hệ thống hay thành phần đó (Theo Bảng chú giải thuật ngữ chuẩn
IEEE của Thuật ngữ kỹ nghệ phần mềm-IEEE Standard Glossary of Software
Engineering Terminology).
Kiểm thử phần mềm là quá trình thực thi một chương trình với mục đích
tìm lỗi (Theo “The Art of Software Testing” – Nghệ thuật kiểm thử phần mềm).
Kiểm thử phần mềm là hoạt động khảo sát thực tiễn sản phẩm hay dịch vụ phần
mềm trong đúng môi trường chúng dự định sẽ được triển khai nhằm cung cấp cho
người có lợi ích liên quan những thông tin về chất lượng của sản phẩm hay dịch vụ
8


phần mềm ấy. Mục đích của kiểm thử phần mềm là tìm ra các lỗi hay khiếm
khuyết phần mềm nhằm đảm bảo hiệu quả hoạt động tối ưu của phần mềm trong
nhiều ngành khác nhau (Theo Bách khoa toàn thư mở Wikipedia).
Có thể định nghĩa một cách dễ hiểu như sau: Kiểm thử phần mềm là một
tiến trình hay một tập hợp các tiến trình được thiết kế để đảm bảo mã hóa máy tính
thực hiện theo cái mà chúng đã được thiết kế để làm, và không thực hiện bất cứ
thứ gì không mong muốn. Đây là một pha quan trọng trong quá trình phát triển hệ
thống, giúp cho người xây dựng hệ thống và khách hàng thấy được hệ thống mới
đã đáp ứng yêu cầu đặt ra hay chưa.
1.1.2. Mục đích của kiểm thử phần mềm.
 Tìm ra nhiều lỗi bằng việc đưa ra các dòng thời gian.
 Chứng minh được sản phẩm hoàn thành có những chức năng hay ứng
dụng giống với bản đặc tả yêu cầu.
 Tạo ra các test case có chất lượng cao, thực thi hiệu quả…


9


1.1.3. Các phương pháp kiểm thử
 Kiểm thử tĩnh( Static testing): Là phương pháp thử phần mềm đòi hỏi
phải duyệt lại các yêu cầu và các đặc tả bằng tay, thông qua việc sử dụng giấy, bút
để kiểm tra logic, lần từng chi tiết mà không cần chạy chương trình. Kiểu kiểm thử
này thường được sử dụng bởi chuyên viên thiết kế người mà viết mã lệnh một
mình.
 Kiểm thử động (Dynamic testing): Kiểm thử động kiểm tra cách thức
hoạt động động của mã lệnh, tức là kiểm tra sự phản ứng vật lý từ hệ thống tới các
biến luôn thay đổi theo thời gian. Trong kiểm thử động, phần mềm phải thực sự
được biên dịch và chạy. Kiểm thử động thực sự bao gồm làm việc với phần mềm,
nhập các giá trị đầu vào và kiểm tra xem liệu đầu ra có như mong muốn hay
không. Các phương pháp kiểm thử động gồm có kiểm thử Unit – Unit Tests, Kiểm
thử tích hợp – Intergration Tests, Kiểm thử hệ thống – System Tests, và Kiểm thử
chấp nhận sản phẩm – Acceptance Tests.
1.1.4. Chiến lược kiểm thử
Trong chiến lược kiểm thử, chúng ta có ba chiến lược kiểm thử hay dùng
nhất là: kiểm thử hộp đen, kiểm thử hộp trắng, và kiểm thử hộp xám.
1.1.4.1. Kiểm thử hộp đen - Black box
Một trong những chiến lược kiểm thử quan trọng là kiểm thử hộp đen,
hướng dữ liệu, hay hướng vào/ra. Kiểm thử hộp đen xem chương trình như là
một “hộp đen”. Mục đích của bạn là hoàn toàn không quan tâm về cách cư xử
và cấu trúc bên trong của chương trình. Thay vào đó, tập trung vào tìm các
trường hợp mà chương trình không thực hiện theo các đặc tả của nó.
Theo hướng tiếp cận này, dữ liệu kiểm tra được lấy từ các đặc tả.
Các phương pháp kiểm thử hộp đen
 Phân lớp tương đương - Equivalence partitioning.
10


 Phân tích giá trị biên - Boundary values analysis.
 Kiểm thử mọi cặp - All pairs testing.
 Kiểm thử dựa trên mô hình - Model based testing.
 Kiểm thử thăm dò - Exploratory testing
 Kiểm thử dựa trên đặc tả - Specification base testing.
 Bảng quyết định - Decision table.
 Biểu đồ Usecase.
 Biểu đồ chuyển trạng thái - State Transition Diagram.
Ưu, nhược điểm
Kiểm thử hộp đen không có mối liên quan nào tới mã lệnh và kiểm thử viên
chỉ rất đơn giản tam niệm là: một mã lệnh phải có lỗi. Sử dụng nguyên tắc “Hãy
đòi hỏi và bạn sẽ được nhận”, những kiểm thử viên hộp đen tìm ra lỗi mà những
lập trình viên không tìm ra. Đó là lý do mà có nhiều trường hợp mà một kiểm thử
viên hộp đen viết rất nhiều ca kiểm thử để kiểm tra một thứ gì đó mà đáng lẽ có thể
chỉ cần kiểm tra bằng một ca kiểm thử duy nhất, và hoặc một số phần của chương
trình không được kiểm tra chút nào.
Do vậy, kiểm thử hộp đen có ưu điểm của “một sự đánh giá khách quan”,
mặt khác nó lại có nhược điểm của “thăm dò mù”.
1.1.4.2 Kiểm thử hộp trắng – White box
Là một chiến lược kiểm thử khác, trái ngược hoàn toàn với kiểm thử hộp
đen, kiểm thử hộp trắng hay kiểm thử hướng logic cho phép bạn khảo sát cấu trúc
bên trong của chương trình. Chiến lược này xuất phát từ dữ liệu kiểm thử bằng sự
kiểm thử tính logic của chương trình. Kiểm thử viên sẽ truy cập vào cấu trúc dữ
liệu và giải thuật bên trong chương trình (và cả mã lệnh thực hiện chúng).
Các phương pháp kiểm thử hộp trắng.
 Kiểm thử giao diện lập trình ứng dụng – API testing (application
programming interface): là phương pháp kiểm thử của ứng dụng sử dụng các API
11


công khai và riêng tư.
 Bao phủ mã lệnh – Code coverage: tạo các kiểm tra để đáp ứng một số
tiểu chuẩn về bao phủ mã lệnh.
 Các phương pháp gán lỗi – Fault injection.
 Các phương pháp kiểm thử hoán chuyển – Mutation testing methods.
 Kiểm thử tĩnh - Static testing
1.1.4.3 Kiểm thử hộp xám – Gray box testing
Kiểm thử hộp xám đòi hỏi phải có sự truy cập tới cấu trúc dữ liệu và giải
thuật bên trong cho những mục đích thiết kế các ca kiểm thử, nhưng là kiểm thử ở
mức người sử dụng hay mức hộp đen. Việc thao tác tới dữ liệu đầu vào và định
dạng dữ liệu đầu ra là không rõ ràng, giống như một chiếc “hộp xám”, bởi vì đầu
vào và đầu ra rõ ràng là ở bên ngoài “hộp đen” mà chúng ta vẫn gọi về hệ thống
được kiểm tra. Sự khác biệt này đặc biệt quan trọng khi quản lý kiểm thử tích hợp
– Intergartion testing giữa 2 modun mã lệnh được viết bởi hai chuyên viên thiết kế
khác nhau, trong đó chỉ giao diện là được đưa ra để kiểm thử. Kiểm thử hộp xám
có thể cũng bao gồm cả thiết kế đối chiếu để quyết định, ví dụ, giá trị biên hay
thông báo lỗi.1.1.5. Các cấp độ kiểm thử phần mềm
Kiểm thử phần mềm gồm có các cấp độ: Kiểm thử đơn vị, Kiểm thử tích
hợp, Kiểm thử hệ thống và Kiểm thử chấp nhận sản phẩm.

12


Hình 1.1 Các cấp độ kiểm thử phần mềm
1.1.5.1 Kiểm thử đơn vị - Unit Test
 Định nghĩa
Một đơn vị là một thành phần phần mềm nhỏ nhất mà ta có thể kiểm thử
được. Ví dụ, các hàm (Function), thủ tục (Procedure), lớp (Class) hay phương thức
(Method) đều có thể được xem là Unit.
Unit Test thường do lập trình viên thực hiện. Công đoạn này cần được thực
hiện càng sớm càng tốt trong giai đoạn viết code và xuyên suốt chu kỳ phát triển
phần mềm. Thông thường, Unit Test đòi hỏi kiểm thử viên có kiến thức về thiết kế
và code của chương trình
 Mục đích.
 Đảm bảo thông tin được xử lý và xuất ra là chính xác.
 Trong mối tương quan với dữ liệu nhập và chứa năng của Unit.
 Đòi hỏi tất cả các nhánh bên trong phải được kiểm tra phát hiện nhánh
sinh lỗi (nhánh đó thường là câu lệnh được thực thi trong một Unit).
 Phát hiện ra các vấn đề tiềm ẩn hoặc các lỗi ký thuật.
 Yêu cầu.

13


 Muốn làm được Unit testing thì phải chuẩn bị trước các ca kiểm thử
(Test case) hoặc các kịch bản kiểm thử (Test Script) trong đó phải ghi rõ dữ liệu
nhập vào, các bước thực hiện và dữ liệu mong chờ đầu ra của từng testcase.
 Các test case hay script phải được giữ lại để tái sử dụng.
1.1.5.2 Kiểm thử tích hợp – Intergration test
Integration test là kết hợp các thành phần của một ứng dụng và kiểm thử
như một ứng dụng đã hoàn thành. Trong khi Unit Test kiểm tra các thành phần và
Unit riêng lẻ thì Intgration Test kết hợp chúng lại với nhau và kiểm tra sự giao tiếp
giữa chúng.
Có 4 loại kiểm thử trong Integration Test:
 Kiểm thử cấu trúc (Structure Test): Tương tự White Box Test, kiểm
thử cấu trúc nhằm bảo đảm các thành phần bên trong của một chương trình chạy
đúng và chú trọng đến hoạt động của các thành phần cấu trúc nội tại của chương
trình chẳng hạn các câu lệnh và nhánh bên trong.
 Kiểm thử chức năng (Functional Test): Tương tự Black Box Test,
kiểm thử chức năng chỉ chú trọng đến chức năng của chương trình, mà không quan
tâm đến cấu trúc bên trong, chỉ khảo sát chức năng của chương trình theo yêu cầu
kỹ thuật.
 Kiểm thử hiệu năng (Performance Test): Kiểm thử việc vận hành của
hệ thống.
 Kiểm thử khả năng chịu tải (Stress Test): Kiểm thử các giới hạn của
hệ thống.
1.1.5.3 Kiểm thử hệ thống – System test
Mục đích System Test là kiểm thử thiết kế và toàn bộ hệ thống (sau khi tích
hợp) có thỏa mãn yêu cầu đặt ra hay không.
Đòi hỏi nhiều công sức, thời gian và tính chính xác, khách quan, System
Test thường được thực hiện bởi một nhóm kiểm thử viên hoàn toàn độc lập với
nhóm phát triển dự án. Bản thân System Test lại gồm nhiều loại kiểm thử khác
14


nhau, phổ biến nhất gồm:
 Kiểm thử chức năng (Functional Test): Bảo đảm các hành vi của hệ
thống thỏa mãn đúng yêu cầu thiết kế.
 Kiểm thử hiệu năng (Performance Test): Bảo đảm tối ưu việc phân
bổ tài nguyên hệ thống (ví dụ bộ nhớ) nhằm đạt các chỉ tiêu như thời gian xử lý
hay đáp ứng câu truy vấn...
 Kiểm thử khả năng chịu tải (Stress Test hay Load Test): Bảo đảm hệ
thống vận hành đúng dưới áp lực cao.
 Kiểm thử cấu hình (Configuration Test).
 Kiểm thử bảo mật (Security Test): Bảo đảm tính toàn vẹn, bảo mật
của dữ liệu và của hệ thống.
 Kiểm thử khả năng phục hồi (Recovery Test): Bảo đảm hệ thống có
khả năng khôi phục trạng thái ổn định trước đó trong tình huống mất tài nguyên
hoặc dữ liệu, đặc biệt quan trọng đối với các hệ thống giao dịch như ngân hàng
trực tuyến ...
Kết luận: Không nhất thiết phải thực hiện tất cả các kiểm thử trên mà phụ
thuộc vào yêu cầu hệ thống, tùy vào khả năng và thời gian của dự án, khi lập kế
hoạch thì người quản lý sẽ quy định kiểm thử theo những loại nào.
1.1.5.4 Kiểm thử chấp nhận – Acceptance test
Thông thường, sau giai đoạn System Test là Acceptance Test, được khách
hàng thực hiện (hoặc ủy quyền cho một nhóm thứ ba thực hiện). Mục đích của
Acceptance Test là để chứng minh phần mềm thỏa mãn tất cả yêu cầu của khách
hàng và khách hàng chấp nhận sản phẩm (và trả tiền thanh toán hợp đồng). Với
Alpha Test, người dùng kiểm thử phần mềm ngay tại nơi phát triển phần mềm, lập
trình viên sẽ ghi nhận các lỗi hoặc phản hồi, và lên kế hoạch sửa chữa.Với Beta
Test, phần mềm sẽ được gửi tới cho người dùng để kiểm thử ngay trong môi
trường thực, lỗi hoặc phản hồi cũng sẽ gửi ngược lại cho lập trình viên sửa chữa.
Nguyên tắc kiểm thử phần mềm.
1.1.5.5 Một số cấp độ kiểm thử khác
Ngoài các cấp độ trên, còn một số cấp độ kiểm thử khác như:
Kiểm thử hồi quy – Regression Testing
Theo chuẩn IEEE610.12-90, kiểm thử hồi quy là “sự kiểm tra lại có lựa
chọn của một hệ thống hay thành phần để xác minh là những sự thay đổi không
gây ra những hậu quả không mong muốn…”. Trên thực tế, quan niệm này là chỉ ra
rằng phần mềm mà đã qua được các kiểm tra trước đó vẫn có thể được kiểm tra lại.

15


Kiểm thử tính đúng – Correctness testing
Tính đúng đắn là yêu cầu tối thiểu của phần mềm, là mục đích chủ yếu của
kiểm thử. Kiểm thử tính đúng sẽ cần một kiểu người đáng tin nào đó, để chỉ ra
cách hoạt động đúng đắn từ cách hoạt động sai lầm. Kiểm thử viên có thể biết hoặc
không biết các chi tiết bên trong của các modun phần mềm được kiểm thử, ví dụ
luồng điều khiển, luồng dữ liệu, …. Do đó, hoặc là quan điểm hộp trắng, hoặc là
quan điểm hộp đen có thể được thực hiện trong kiểm thử phần mềm.
1.1.6. Mô hình chữ V trong kiểm thử phần mềm

Hình 1.2 Mô hình chữ V trong kiểm thử phần mềm
Các bước tiến hành của mô hình chữ V
 Sau khi đã có yêu cầu của khách hàng ta thực hiện đồng thời việc thiết
kế hệ thống và bản kiểm thử cho người dùng.
 Khi hoàn thành được bản thiết kế hệ thống, ta vừa thực hiện bảng kiểm
thử hệ thống (system testing) và vừa làm thiết kế kiến trúc phần mềm.

16


 Sau khi có được thiết kế kiến trúc ta chuyển sang thiết kế các module,
làm bản thiết kế các unit test đồng thời bắt đầu coding.
 Unit test, integration test, system test và acceptance testing được thực
hiện lần lượt dựa trên các thiết kế đã thực hiện sẵn.


17


Ưu điểm trong mô hình chữ V
 Có thể làm 1 số việc song song. Ví dụ: Nếu làm yêu cầu đúng thì có thể
làm song song với việc thiết kế test .
 Đạt được phần mềm chất lượng, các pha tương thích với nhau, hỗ trợ
cho nhau.
 Các hoạt động kiểm thử được chú trọng và thực hiện song song với các
hoạt động liên quan đến đặc tả yêu cầu và thiết kế.
Nhược điểm trong mô hình chữ V
 Đòi hỏi tất cả yêu cầu phần mềm phải được xác định rõ ràng ngay từ đầu dự
án.
 Pha sau thực chỉ được thực hiện khi pha trước kết thúc, không thể quay
ngược trở lại pha trước.
1.1.7. Nguyên tắc trong kiểm thử phần mềm
Để kiểm thử đạt hiệu quả thì khi tiến hành kiểm thử phần mềm cần phải
tuân thủ một số quy tắc sau:
Quy tắc 1: Một phần quan trọng của một ca kiểm thử là định nghĩa của đầu
ra hay kết quả mong muốn.
Quy tắc 2: Lập trình viên nên tránh tự kiểm tra chương trình của mình.
Quy tắc 3: Nhóm lập trình không nên kiểm thử chương trình của chính họ.
Quy tắc 4: Kiểm tra thấu đáo mọi kết quả của mỗi kiểm tra.
Quy tắc 5: Các ca kiểm thử phải được viết cho các trạng thái đầu vào
không hợp lệ và không mong muốn, cũng như cho các đầu vào hợp lệ và mong
muốn.
Quy tắc 6: Khảo sát một chương trình để xem liệu chương trình có thực
hiện cái mà nó cần thực hiện chỉ là một phần, phần còn lại là xem liệu chương
trình có thực hiện cái mà nó không cần phải thực hiện hay không.
18


Quy tắc 7: Tránh các ca kiểm thử bâng quơ trừ khi chương trình thực sự là
một chương trình bâng quơ.
Quy tắc 8: Không dự kiến kết quả của kiểm thử theo giả thiết ngầm là
không tìm thấy lỗi.
Quy tắc 9: Xác suất tồn tại lỗi trong một đoạn chương trình là tương ứng
với số lỗi đã tìm thấy trong đoạn đó.
Quy tắc 10: Kiểm thử là một nhiệm vụ cực kỳ sáng tạo và có tính thử thách
trí tuệ.
1.2. Phần mềm mã nguồn mở WordPress
1.2.1. WordPress là gì?

Hình 1.3 Logo của WordPress
 WordPress là phần mềm mã nguồn mở được cung cấp miễn phí, sử dụng
ngôn ngữ lập trình PHP và hệ cơ sở dữ liệu MySQL.
 WordPress là một dạng phần mềm mã nguồn mở, là hậu duệ chính thức
của b2/cafelog, được phát triển bởi Michel Valdrighi. Cái tên WordPress được đề
xuất bởi Christine Selleck, một người bạn của nhà phát triển chính Matt
Mullenweg.
 WordPress viết bằng PHP, sử dụng hệ quản trị cơ sở dữ liệu MySQL,
19


chạy tốt trên PHP5, hầu hết mọi host (dịch vụ lưu trữ trực tuyến) có PHP đều hỗ
trợ WordPress. Nhiều host (Godaddy, Host Gator, … ) còn có chức năng tự động
cài đặt WordPress.
 WordPress để dăng tải thông tin trên mạng, có chức năng như mọi
website khác, có thể làm site tin tức , đánh giá, bán hàng, … thậm chí là mạng xã
hội.
1.2.2. Những thành tựu của WordPress
WordPress có những thành tựu rất vượt bậc và là một mã nguồn CMS mở
phổ biến nhất hành tinh:
 Trên thế giới, có khoảng 25 bài viết được đăng lên các website sử dụng
WordPress mỗi giây.
 Số lượng website làm bằng WordPress chiếm 23% tổng số lượng
website trên thế giới.
 Trong số 100% các website sử dụng mã nguồn CMS, WordPress chiếm
60%.
 Hiện nay có tới khoảng 25% website trong danh sách 100 website lớn
nhất thế giới sử dụng mã nguồn WordPress. Ví dụ như trang tạp chí TechCrunch,
Mashable, CNN, BBC America, Variety, Sony Music, MTV News, Bata,
Quartz,…
 Phiên bản WordPress 4.0 đạt hơn 16 triệu lượt tải chỉ sau khoảng hai
tháng.
 WordPress đã được dịch sang 52 ngôn ngữ khác nhau. Tuy nhiên lại
chưa có phiên bản tiếng Việt chính thức, nhưng bạn có thể Việt hóa dễ dàng bằng
cách tìm bài trên blog với từ khóa “Việt hóa WordPress“.
 Có hơn 80 chương trình họp mặt về WordPress được tổ chức vào năm
2014.
 Mã nguồn WordPress hiện đang có khoảng 785 lập trình viên cùng hợp
20


tác phát triển.
 Chỉ tính các giao diện (hay còn gọi là theme) miễn phí trên thư viện
WordPress.org thì đã có hơn 2.700 themes khác nhau.
1.2.3. Ưu, nhược điểm của WordPress
1.2.3.1. Ưu điểm của WordPress
 Nhiều plugin hỗ trợ, hầu như mọi ý tưởng đều đã có plugin hỗ trợ.
 Nhiều theme có sẵn, hầu như là nhiều nhất trong các CMS hiện nay. Bao
gồm các theme miễn phí và theme trả phí rất chuyên nghiệp.
 Dễ tùy biến, nếu bạn là người đã có kiến thức sẵn về PHP, CSS, HTML
thì điều này rất dễ dàng.
 Nhiều cộng đồng hỗ trợ và hướng dẫn, đơn cử là như ThachPham.Com
của mình đây.
 Có thể làm được nhiều thể loại website, từ blog cá nhân đến các trang
thương mại điện tử.
 Dễ cài đặt.
 Nhẹ và hao tốn ít tài nguyên máy chủ.
 Các Theme Framework hiện có sẽ giúp bạn tự thiết kế giao diện
WordPress dễ dàng.
 Dễ sử dụng và quản lý.
1.2.3.2. Nhược điểm của WordPress
 Nhiều khái niệm khó hiểu nếu bạn mới bắt đầu.
 Muốn tùy biến WordPress, bạn phải có kiến thức lập trình web căn bản
nhất.
 Các theme đẹp đa phần là phải trả phí. Và plugin cũng vậy.
 Quá nhiều hàm có sẵn gây mệt mỏi với người lập trình.
1.2.4. Kiểm thử theme WordPress
Kiểm thử một website thương mại trên nền tảng WordPress cũng tương tự
như trên các nền tảng khác, đều thực hiện theo quy trình kiểm thử phần mềm nói
chung. Ngoài ra, WordPress hỗ trợ một số Plugin có sẵn để kiểm tra tự động về mã
nguồn hay cấu trúc bên trong giúp cho việc kiểm thử trên WordPress hiệu quả,
21


nhanh chóng.
Chúng ta sử dụng các plugin sau:
 Theme Check
 Theme Mentor
 Debug bar
 Theme Check
Plugin Theme Check là một con đường dễ dàng để bạn kiểm tra theme của
bạn và chắc chắn nó là những đặc tả với tiêu chuẩn đánh giá theme mới nhất. Với
nó, bạn có thể chạy tất cả cùng một lúc các công cụ kiểm thử tự động trên theme
của bạn mà WordPress.org sử dụng cho các sự đệ trình theme.
Để sử dụng plugin này, chọn Appearance -> Theme Check -> chọn theme
muốn kiểm tra -> Check it!

Hình 1.4 Plugin Theme Check
Theme Check sẽ hiển thị các thông tin chung của theme như tiêu đề, phiên
bản, tác giả, url của tác giả, url của theme, các thẻ, mô tả của theme và các lỗi
được tìm thấy trong theme. Trong danh sách các lỗi đó, ta sẽ bỏ qua các lỗi sau
đây:

22


Hình 1.5 Các lỗi bỏ qua trong Theme Check
Các lỗi này xảy ra không phải do mã nguồn mà có thể do phiên bản của mã
nguồn hay hệ điều hành của máy.
 Theme Mentor
Theme Mentor là một họ hàng với plugin Theme Check trong việc đi sâu
vào phân tích mã nguồn.
Nó sử dụng các phương pháp tiếp cận khác nhau để theo dõi các vấn đề
chung liên quan đến đánh giá theme từ nhóm những người đánh giá theme của
WordPress. Nó dùng để phân tích lỗi, vì vậy chỉ sử dụng như một tài liệu tham
khảo cho việc cải thiện thêm mã nguồn.
Để sử dụng plugin này, chọn Appearance -> Theme Mentor -> chọn theme
muốn kiểm tra -> Do the twist!

23


Hình 1.6 Plugin Theme Mentor
Sau khi thực hiện kiểm tra mã nguồn, nó sẽ hiển thị các lời khuyên sử dụng
các thẻ, các lệnh và truy vấn đúng chuẩn.
 Debug bar
 Thêm một danh sách gỡ rối vào thanh admin để thể hiện truy vấn, bộ
nhớ cache và thông tin gỡ rối giúp đỡ khác.
 Đây là plugin phải có cho các nhà phát triển.
 Khi WP_DEBUG bị kích hoạt nó cũng theo dõi các cảnh báo PHP và
các thông báo để chúng dễ dàng tìm thấy hơn.
 Khi SAVEQUERIES bị kích hoạt thì các truy vấn mysql bị theo dõi và hiển
thị.

24


 Thêm một lệnh PHP/MySQL với plugin Debug Bar Console.
Plugin này sẽ hiển thị trong các post và page, khi phát hiện có lỗi nó sẽ hiện
màu đỏ, khi chọn vào nó sẽ mở ra một trang hiển thị cho ta biết đó là lỗi gì.

Hình 1.7 Plugin Debug Bar

25


Tài liệu bạn tìm kiếm đã sẵn sàng tải về

Tải bản đầy đủ ngay

×