Kỹ thuật kiểm thử hồi quy ứng dụng trong phát triển các ứng dụng trên điện thoại thông minh

Kỹ thuật kiểm thử hồi quy ứng dụng trong phát triển các ứng dụng trên điện thoại thông minh Kỹ thuật kiểm thử hồi quy ứng dụng trong phát triển các ứng dụng trên điện thoại thông minh Kỹ thuật kiểm thử hồi quy ứng dụng trong phát triển các ứng dụng trên điện thoại thông minh luận văn tốt nghiệp,luận văn thạc sĩ, luận văn cao học, luận văn đại học, luận án tiến sĩ, đồ án tốt nghiệp luận văn tốt nghiệp,luận văn thạc sĩ, luận văn cao học, luận văn đại học, luận án tiến sĩ, đồ án tốt nghiệp

ĐIỆN THOẠI THÔNG MINH

LUẬN VĂN THẠC SĨ KỸ THUẬT PHẦN MỀM

…

Hà Nội – 2017

BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

LỜI CAM ĐOAN

Tôi xin cam đoan những gì tôi viết dưới đây là hoàn toàn chính thống không sao ché p, những kết quả đo đạc mô phỏ ng có trong luận văn chưa từ ng đươ ̣c công bố từ bất cứ tài liệu nào dưới mọi hình thức Các thông tin

sử du ̣ng trong luâ ̣n văn có nguồn gố c và đươ ̣c trích dẫn rõ rà ng

Tôi xin hoàn toàn chịu trách nhiệm nếu có dấu hiệu sao chép kết quả

từ các tài liệu khác

HỌC VIÊN

NGUYỄN TRỌNG HÀ

LỜI CẢM ƠN

Lời đầu tiên tôi xin chân thành c ảm ơn các thầy cô trong Bộ môn Công nghệ phần mềm - Viện Công nghệ thông tin và truyền thông - Đại học

Bách khoa Hà Nội Đặc biệt TS Nguyễn Thanh Hùng, người đã hướng

dẫn vô cùng tận tình, tâm huyết để tôi có thể hoàn thành luận văn này

Ngoà i ra, tôi cũng xin bà y tỏ lò ng biết ơn sâu sắc đến gia đình, ba ̣n bè , những người đã luôn ủ ng hô ̣ tôi trong suốt quá trình ho ̣c tâ ̣p và hoàn thà nh chương trình đà o ta ̣o Tha ̣c sỹ Kỹ thuật ta ̣i Viện Công nghệ thông tin

và Truyền thông, Đại ho ̣c Bách khoa Hà Nội

Mă ̣c dù tôi đã nỗ lư ̣c và cố gắng hoàn thiê ̣n luâ ̣n văn bằng tất cả nhiê ̣t tình và năng lư ̣c của mình, tuy nhiên không thể tránh khỏ i những thiế u sót, rấ t mong nhâ ̣n đươ ̣c những đó ng gó p quý bá u củ a quý thầ y cô và các ba ̣n

Tôi xin chân thà nh cả m ơn

HỌC VIÊN

NGUYỄN TRỌNG HÀ

MỤC LỤC

LỜI MỞ ĐẦU

CHƯƠNG 1 TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM 5

1.1 Kiểm thử phần mềm 5

1.2 Một số khái niệm 6

1.3 Phương pháp kiểm thử 8

1.4 Các mức kiểm thử 12

1.5 Quy trình kiểm thử 15

1.6 Kiểm thử tự động 16

1.7 Tổng kết chương 19

CHƯƠNG 2 KIỂM THỬ HỒI QUY ỨNG DỤNG DI ĐỘNG 20

2.1 Ứng dụng trên các thiết bị di động (Mobile application) 20

2.2 Kiểm thử ứng dụng cho thiết bị di động 21

2.3 Kỹ thuật kiểm thử hồi quy trong ứng dụng di động 23

2.4 Qui trình kiểm thử hồi quy 24

2.5 Các vấn đề nên kiểm thử hồi quy 26

2.6 Công cụ hỗ trợ kiểm thử hồi quy ứng dụng di động 28

2.7 Tổng kết chương 29

CHƯƠNG 3 CÔNG CỤ KIỂM THỬ HỒI QUY ÁP DỤNG CHO ỨNG DỤNG TRÊN ĐIỆN THOẠI THÔNG MINH 30

3.1 Công cụ kiểm thử Robotium 30

3.2 Công cụ kiểm thử Selendroid 33

3.3 Công cụ kiểm thử Appium 38

3.4 Công cụ kiểm thử Selenium 40

3.5 Áp dụng thiết kế ứng dụng Adapter kiểm thử 43

3.5.1 Thiết kế chương trình 44

3.5.2 Kiểm thử và kết quả 51

3.6 Tổng kết chương 58

CHƯƠNG 4 KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 60

4.1 KẾT LUẬN 60

4.2 HƯỚNG PHÁT TRIỂN CỦA ĐỀ TÀI 61TÀI LIỆU THAM KHẢO 62

DANH MỤC BẢNG

Bảng 1 1 Chi phí triển khai bảo trì phần mềm [2] 8 Bảng 2 1 Danh sách các công cụ kiểm thử hồi quy[10] 29 Bảng 3 1 Bảng so sánh của Appium[16] 39

DANH MỤC HÌNH

Hình 1 1 Chi phí triển khai bảo trì phần mềm [2] 8

Hình 1 2 Kỹ thuật kiểm thử hộp trắng [5] 10

Hình 1 3 Kỹ thuật kiểm thử hộp đen [5] 11

Hình 1 4 Kỹ thuật kiểm thử hộp xám [5] 12

Hình 1 5 Quy trình kiểm thử phần mềm [9] 15

Hình 2 1 Các lĩnh vực ứng dụng mobile [12] 20

Hình 2 2 Các loại ứng dụng mobile[11] 21

Hình 2 3 Các kỹ thuật thực hiện hồi quy [4] 23

Hình 2 4 Qui trình tổng quát cho kiểm thử hồi quy 24

Hình 2 5 Kiểm thử hồi quy trong phương pháp phát triển Agile[11] 25

Hình 3 1 Danh sách các các lớp của Robotium hỗ trợ kiểm thử [17] 31

Hình 3 2 Các bước thực hiện kiểm thử Robotium [17] 31

Hình 3 3 Kiến trúc của Selendroid[19] 34

Hình 3 4 Đặc điểm của Appium 38

Hình 3 5 Giao diện công cụ Appium 40

Hình 3 6 Cấu trúc công cụ Selenium[18] 40

Hình 3 7 Sử dụng Appium và Selenium cho ki ểm thử [16] 43

Hình 3 8 Mô hình đặc tả ứng dụng cho kiểm thử hồi quy 44

Hình 3 9 Giao diện của ứng dụng Adapter Test Smartphone 45

LỜI MỞ ĐẦU

Kiểm thử phần mềm không còn là một vấn đề mới và tầm quan trọng của nó thì lại càng không thể bàn cãi Một phần mềm tốt là một phần mềm

đã được đánh giá tốt từ nhà phát triển đến người sử dụng cuối

Thời đại hiện nay, với sự bùng nổ về số lượng ứng dụng đặc biệt là những ứng dụng trên đa nền tảng Với số lượng ứng dụng như vậy thì cuộc chạy đua giữa những nhà phát triển đã chuyển dần từ tìm những ý tưởng mới sang làm thế nào để cải thiện, cải tiến những ứng dụng có sẵn, sao cho

có thể đáp ứng được nhu cầu trải nghiệm ngày càng cao của người dùng Với những lí do trên, đề tài đã tìm hiểu và trình bày một số phương pháp nâng cao hiệu quả kiểm thử của ứng dụng, từ đó có thể áp dụng phương pháp kiểm thử hồi quy một cách phù hợp vào ứng dụng cụ thể

Nội dung luận văn “Kỹ thuật kiểm thử hồi quy ứng dụng trong phát

triển các ứng dụng trên điện thoại thông minh” gồm các phần sau:

Chương 1 TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM

Chương 2 KIỂM THỬ HỒI QUY ỨNG DỤNG DI ĐỘNG

Chương 3 CÔNG CỤ KIỂM THỬ HỒI QUY ÁP DỤNG CHO ỨNG

DỤNG TRÊN ĐIỆN THOẠI THÔNG MINH

Chương 4 KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN

Để có thể hoàn thành luận văn này, tôi chân thành cảm ơn TS Nguyễn Thanh Hùng và các thầy, cô tại Trường Đại học Bách Khoa - Hà Nội đã nhiệt tình giúp đỡ trong suốt quá trình thực hiện luận văn Tuy đã cố gắng hết sức, nhưng do thời gian và kiến thức còn hạn chế nên luận văn không tránh khỏi sai sót, tôi rất mong sự bổ sung, góp ý của các thầy cô!

HỌC VIÊN

NGUYỄN TRỌNG HÀ

Trong kỹ thuật kiểm thử không chỉ giới hạn ở việc thực hiện một chương trình hoặc ứng dụng với mục đích đi tìm cáclỗi phần mềm (bao gồm các lỗi và các thiếu sót) mà còn là một quá trình phê chuẩn và xác minh một chương trình máy tính [1], ứng dụng, sản phẩm nhằm:

 Đáp ứng được mọi yêu cầu đặc tả khi thiết kế và phát triển phần mềm

 Thực hiện công việc đúng như kỳ vọng

 Có thể triển khai được với những đặc tính tương tự

 Và đáp ứng được mọi nhu cầu của các bên liên quan

Tùy thuộc vào từng phương pháp, việc kiểm thử có thể được thực hiện bất cứ lúc nào trong quá trình ph át triển phần mềm Theo qui trình phát triển phần mềm truyền thống (waterfall process) thì các hoạt động kiểm thử được tiến hành sau khi các yêu cầu được xác định và việc lập trình được hoàn tất nhưng trong môi trường phát triển linh hoạt (Agile) thì việc kiểm thử được tiến hành liên tục trong suốt quá trình xây dựng phần mềm Như vậy, mỗi một phương pháp kiểm thử bị chi phối theo một quy trình phát triển phần mềm nhất định

Kiểm thử không thể xác định hoàn toàn được tất cả các lỗi bên trong phần mềm.Thay vào đó, nó so sánh trạng thái và hành vi của sản phẩm với các nguyên tắc hay cơ chế để phát hiện vấn đề Các nguyên tắc này có thể bao gồm (nhưng không giới hạn) các đặc tả phần mềm, hợp đồng, sản phẩm tương đương, các phiên bản trước của cùng một sản phẩm, phù hợp với mục đích dự kiến nhằm đáp ứng sự kỳ vọng của người dùng, khách hàng, quy định của pháp luật hiện hành và các tiêu chuẩn liên quan khác [2] Phạm vi của kiểm thử phần mềm thường bao gồm việc kiểm tra mã lệnh, thực hiện các mã lệnh trong môi trường và điều kiện khác nhau, và việc kiểm thử các khía cạnh của mã lệnh, có làm đúng nhiệm vụ của chương trình hay không, và chương trình có làm những gì cần phải làm hay không

6

Trong môi trường phát triển phần mềm hiện nay, một đội kiểm thử có thể tách biệt với đội phát triển Các thành viên trong đội kiểm thử giữ các vai trò khác nhau Các thông tin thu được từ kiểm thử có thể được sử dụng để điều chỉnh quá trình phát triển phần mềm

Mỗi sản phẩm phần mềm có một đối tượng phục vụ riêng Ví dụ như đối tượng của phần mềm trò chơi điện tử là hoàn toàn khác với đối tượng của phần mềm ngân hàng Vì vậy, khi một tổ chức phát triển hoặc đầu tư vào một sản phẩm phần mềm, họ có thể đánh giá liệu các sản phẩm phần mềm

có được chấp nhận bởi người dùng cuối, đối tượng phục vụ, người mua, hay những người giữ vai trò quan trọng khác hay không Và việc kiểm thử phần mềm là một quá trình nỗ lực để đưa ra những đánh giá này

1.2 Một số khái niệm

Khiếm khuyết (defect) và lỗi (failure)

Không phải tất cả các khiếm khuyết của phần mềmbị gây ra bởi lỗi lập trìnhmà nguồn gốc chung của các khiếm khuyết đó nằm ở những thiếu sót trong yêu cầu; Ví dụ, yêu cầu không được xác nhận mà gây ra lỗi là sự sơ suất của các nhà thiết kế của chương trình.Những thiếu sót yêu cầu thường thấy trong những yêu cầu phi chức năng như là khả năng kiểm thử, khả năng mở rộng, bảo trì, tính khả dụng, hiệu suất, và khả năng bảo mật [5] Lỗi phần mềm xảy ra trong suốt quá trình như sau: Một lập trình viên tạo ra một lỗi (sai lầm), mà kết quả cho ra là một khiếm khuyết (thất bại, sai sót) trong mã nguồn phần mềm Nếu lỗi này được thực hiện, trong những tình huống nhất định hệ thống sẽ tạo ra kết quả sai, gây ra một sự thất bại (failure) Không phải tất cả các khiếm khuyết nhất thiết sẽ dẫn đến lỗi nghiêm trọng Ví dụ, lỗi trong mã chết sẽ không bao giờ dẫn đến thất bại Lỗi có thể biến thành một sự thất bại khi môi trường thay đổi Ví dụ về những thay đổi trong môi trường bao gồm các phần mềm đang chạy trên một nền tảng phần cứng máy tính mới, thay đổi trong nguồn dữ liệu, hoặc tương tác với các phần mềm khác nhau Một khiếm khuyết duy nhất có thể dẫn đến một loạt các dấu hiệu thất bại

Một vấn đề rất cơ bản với kiểm thử phần mềm là việc kiểm thử tất

cả các kết nối đầu vào và điều kiện tiền đề (trạng thái ban đầu) là không khả thi, ngay cả với một sản phẩm đơn giản Điều này có nghĩa rằng số lượng các khiếm khuyết trong một sản phẩm phần mềm có thể rất lớn và có thể xảy ra không thường xuyên nên rất khó để tìm thấy trong quá trình

7

kiểm thử Quan trọng hơn, những yêu cầu phi chức năng về chất lượng như: tính khả dụng, khả năng mở rộng, hiệu suất, khả năng tương thích, độ tin cậy nếu xét về mặt chủ quan thì nó chưa tạo nên giá trị đủ để mọi người có thể chấp nhận được nó

Các nhà phát triển phần mềm không thể kiểm thử được tất cả mọi thứ, nhưng họ có thể sử dụng tổ hợp thiết kế kiểm thử để xác định số lượng tối thiểu của các kiểm thử cần thiết để bao quát được những điều họ muốn Dù

là kiểm thử tốc độ hay độ sâu thì họ có thể sử dụng phương pháp này để xây dựng được những cơ cấu khác nhau trong từng trường hợp kiểm thử (test case) cụ thể [6]

Chi phí cho kiểm thử phần mềm

Một nghiên cứu được tiến hành bởi NIST trong năm 2002 cho bi ết rằng các lỗi phần mềm gây tổn thất cho nền kinh tế Mỹ 59,5 tỷ đô mỗi năm, hơn một phần ba chi phí này có thể tránh được nếu việc kiểm thử phần mềm được thực hiện tốt hơn [7]

Thực tế chứng minh rằng, một kiếm khuyết nếu được tìm ra sớm hơn thì chi phí để sửa chữa nó sẽ rẻ hơn Bảng dưới đây cho thấy chi phí sửa chữa các khiếm khuyết tùy thuộc vào giai đoạn nó được tìm ra.Ví dụ, một vấn

đề được tìm thấy sau khi đã ra bản phần mềm chính thức rồi sẽ có chi phí gấp 10-100 lần khi giải quyết vấn đề từ lúc tiếp nhận yêu cầu Với sự ra đời của cách thức triển khai thực tiễn liên tục và các dịch vụ dựa trên đám mây, chi phí tái triển khai và bảo trì có thể làm giảm bớt theo thời gian

và đặc tả yêu cầu

Ph

a thiết

kế kiến trúc

P

ha xây dựng

Ph

a kiểm thử hệ thống

S

au khi phát hành

và đặc tả yêu cầu

1x 3x 5

–10x 10x

10–100x

Pha

Bảng 1 1 Chi phí triển khai bảo trì phần mềm [2]

Vai trò của kiểm thử viên

Kiểm thử phần mềm được thực hiện bởi nhiều Tester Cho đến những năm 1980, thuật ngữ "nhân viên kiểm thử phần mềm" đã được sử dụng thường xuyên, nhưng sau đó cũng được coi là một nghề riêng biệt Liên quan đến các giai đoạn và các mục tiêu khác nhau trong kiểm thử phần mềm thì những vai trò khác nhau đã đư ợc thiết lập cho các nhà quản lý, trưởng nhóm kiểm thử, nhà phân tích kiểm thử, nhà thiết kế kiểm thử, Tester, nhà phát triển tự động hóa và quản trị viên kiểm thử [9]

Lịch sử của kiểm thử phần mềm

Sự tách biệt giữa việc gỡ lỗi (sửa lỗi, debugging) với kiểm thử (testing) lần đầu tiên được Glenford J Myers đưa ra vào năm 1979 Mặc dù sự quan tâm của ông là kiểm thử sự gián đoạn ("một kiểm thử thành công là tìm ra được một lỗi") nó minh họa mong muốn của cộng đồngcông nghệ phần mềm để tách biệt các hoạt động phát triển cơ bản, giống như việc tách phần

gỡ lỗi ra riêng khỏi quá trình kiểm thử Vào năm 1988,Dave GelperinvàWilliam C Hetzel đã phân loại các giai đoạn và mục tiêu trong kiểm thử phần mềm theo trình tự sau [11]:

 Trước 1956: Hướng về việc kiểm soát lỗi

 1957-1978: Hướng về chứng minh lỗi

 1979-1982: Hướng về tính phá hủy của lỗi

 1983–1987: Hướng về đánh giá lỗi

 1988–2000: Hướng về việc phòng ngừa lỗi

1.3 Phương pháp kiểm thử

Kiểm thử tĩnh và kiểm thử động

Có rất nhiều phương pháp để kiểm thử phần mềm Đánh giá, định hướng hoặc kiểm tra được gọi là kiểm thử tĩnh, trong khi việc chạy mã lập trình thực tế trong các tình huống được gọi là kiểm thử động Kiểm thử tĩnh thông thường có thể được bỏ qua khi thực hành nhưng kiểm thử động diễn

ra khi bản thân chương trình đó đang đư ợc sử dụng Kiểm thử động có thể

vị, liên kết giữa các đơn vị trong quá trình tích hợp, và giữa các hệ thống con trong một kiểm thử hệ thống cấp Mặc dù phương pháp này thiết kế kiểm thử có thể phát hiện ra nhiều lỗi hoặc các vấn đề, nó có thể không phát hiện các phần chưa thực hiện của các đặc điểm kỹ thuật hoặc yêu cầu thiếu sót

10

Hình 1 1 Kỹ thuật kiểm thử hộp trắng [5]

Các kỹ thuật được sử dụng trong kiểm thử hộp trắng bao gồm:

 Kiểm thử API (giao diện lập trình ứng dụng) - kiểm thử ứng dụng

có sử dụng các API public và cá nhân

 Kiểm thử độ bao phủ mã lệnh- tạo ra các trường hợp kiểm thử để đáp ứng một số tiêu chí bao phủ mã lệnh(Ví dụ, các nhà thiết kế kiểm thử có thể tạo ra các bài kiểm thử để làm tất cả các câu lệnh trong chương trình được thực hiện ít nhất một lần)

 Phương pháp chèn lỗi - cố tình đưa ra những lỗi để đánh giá hiệu quả của các chiến lược kiểm thử

 Phương pháp kiểm thử đột biến

 Phương pháp thử tĩnh

Các công cụ bao phủ mã có thể đánh giá đầy đủ của một bộ kiểm thử đã được tạo ra bằng phương pháp bất kỳ nào đó, bao gồm cả kiểm thử hộp đen Điều này cho phép nhóm nghiên cứu phần mềm kiểm thử các bộ phận của một hệ thống mà hiếm khi được kiểm thử và đảm bảo rằng các điểm chức năng quan trọng nhất đã được kiểm thử Bao phủ mã lệnh gồm:

 Bao phủ chức năng (hàm): dựa vào các báo cáo của chức năng để thực hiện

 Bao phủ câu lệnh: dựa vào các báo cáo về số lượng các dòng được thực hiện để hoàn thành kiểm thử

100% bao phủ câu lệnh đảm bảo rằng tất cả các đường dẫn mã lệnh, hoặc các nhánh (trong điều kiện của luồng điều khiển) được thực hiện ít nhất một lần Điều này hữu ích trong việc đảm bảo đúng chức năng nhưng

11

không đủ kể từ khi các mã tương tự có thể thực hiện tiến trình xử lý dữ liệu đầu vào khác nhau dù đúng hoặc không

Kiểm thử hộp đen

Kiểm thử hộp đen là kiểm thử chức năng mà không cần bất kỳ kiến thức

về cấu trúc và hành vi bên trong ph ần mềm Các kiểm thử viên chỉ biết về những gì phần mềm phải làm mà không biết là nó làm như thế nào Phương pháp kiểm thử hộp đen bao gồm: Phân vùng tương đương, phân tích giá tr ị biên, tất cả các cặp kiểm thử, bảng chuyển đổi trạng thái, kiểm thử bảng quyết định, kiểm thử dựa trên mô hình, sử dụng Test Case, kiểm thử thăm

dò và kiểm thử dựa trên đặc điểm kỹ thuật

Hình 1 2 Kỹ thuật kiểm thử hộp đen [5]

Kiểm thử dựa trên đặc điểm kỹ thuật nhằm mục đích để kiểm tra các chức năng của phần mềm theo các yêu cầu ứng dụng Mức độ kiểm thử thường đòi hỏi Test Case kỹ lưỡng để được cung cấp bởi các Tester, những người mà sau đó có thể xác minh một cách đơn giản rằng đối với một giá trị đầu vào hoặc đầu ra (hoặc cách xử lý) có thể giống hoặc không giống so với giá trị kỳ vọng được định vị trong một Test Case nhất định Các Test Case được xây dựng quanh các thông số kỹ thuật và các yêu cầu đề xuất, tức là những tất cả những gì ứng dụng đó phải làm Nó được sử dụng để mô

tả mở rộng phần mềm bao gồm các thông số kỹ thuật, các yêu cầu và thiết

kế được mô tả trong tài liệu đặc tả, tài liệu thiết kế, nguồn để xây dựng Test Case Các kiểm thử này có thể là chức năng hoặc phi chức năng

Kiểm thử dựa trên đặc điểm kỹ thuật có thể là cần thiết để đảm bảo chức năng chính xác, nhưng nó không đủ để bảo vệ chống lại các tình huống phức tạp hoặc có độ rủi ro cao

12

Phương pháp kiểm thử này có thể được áp dụng cho tất cả các cấp kiểm thử phần mềm: đơn vị, tích hợp, hệ thống và chấp nhận Nó không thể thực hiện được tất cả các kiểm thử các cấp độ cao hơn nhưng nó có thể tạo ưu thế tốt khi kiểm thử từng đơn vị

Kiểm thử hộp xám

Kiểm thử hộp xám là một phương pháp kiểm thử phần mềm được kết hợp giữa Phương pháp Kiểm thử Black Box (hộp đen) và White Box (hộp trắng) Trong Kiểm thử Hộp xám, cấu trúc bên trong sản phẩm chỉ được biết một phần

Hình 1 3 Kỹ thuật kiểm thử hộp xám [20]

Kiểm thử hộp xám liên quan đến hiểu biết về cấu trúc dữ liệu bên trong

và các thuật toán cho mục đích của các trường hợp kiểm thử thiết kế Khi thực hiện kiểm thử với User hoặc mức độ hộp đen, Tester không nhất thiết phải truy cập vào mã nguồn của phần mềm Ta có thể thao tác với dữ liệu đầu vào và định dạng đầu ra không xác định như hộp xám bởi vì đầu vào và đầu ra rõ ràng ở bên ngoài của "hộp đen" mà chúng được hệ thống gọi ra trong quá trình kiểm thử Sự phân biệt này là đặc biệt quan trọng khi tiến hành kiểm thử tích hợp giữa hai Module được viết mã bởi hai nhà phát triển khác nhau, mà ở đó chỉ có các giao diện được bộc lộ ra để kiểm thử Tuy nhiên, các kiểm thử mà yêu cầu thay thế một kho lưu trữ dữ liệu back-end như một cơ sở dữ liệu hoặc một tập tin đăng nhập không xác định như hộp xám, người dùng sẽ không thể thay đổi các kho lưu trữ dữ liệu trong khi sản phẩm vẫn đang hoạt động bình thường

1.4 Các mức kiểm thử

Kiểm thử đơn vị

Kiểm thử đơn vị hay còn được gọi là kiểm thử thành phần, đề cập đến việc kiểm thử chức năng từng phần của mã, thường ở mức độ chức năng

13

Trong một môi trường hướng về đối tượng thì điều này thường là cấp độ lớp, và các kiểm thử đơn vị tối thiểu bao gồm hàm dựng và hàm hủy Nhiều loại kiểm thử được viết bởi các nhà phát triển như họ làm việc trong mã (kiểu hộp trắng) để đảm bảo rằng từng hàm riêng biệt hoạt động đúng như

kỳ vọng Một hàm có thể có nhiều kiểm thử từ đó giúp nắm bắt được các trường hợp góc hoặc các nhánh trong mã nguồn Kiểm thử đơn vị một mình không thể đảm bảo hết được từng chức năng của từng bộ phận trong phần phềm nhưng nó được sử dụng để đảm bảo rằng các khối kiến trúc của phần mềm hoạt động độc lập với nhau

Kiểm thử đơn vị là một quá trình phát triển phần mềm có liên quan đến ứng dụng đồng bộ của một loạt các chiến lược phòng ngừa phát hiện lỗi và

để giảm thiểu rủi ro, thời gian và chi phí Nó được thực hiện bởi kỹ sư hay nhà phát triển trong suốt giai đoạn xây dựng của vòng đời phát triển phần mềm Không chỉ tập trung vào việc đảm bảo chất lượng truyền thống mà phải gia tăng nó lên vì thế kiểm thử đơn vị có mục đích loại bỏ những lỗi cấu trúc trước khi mã hóa rồi mới thúc đẩy việc quản lý chất lượng Chiến lược này nhằm nâng cao chất lượng cũng như hiệu quả của phần mềm trong tiến trình quản lý và phát triển chung

Tùy thuộc vào kỳ vọng của tổ chức phát triển phần mềm, kiểm thử đơn

vị có thể bao gồm phân tích mã tĩnh, phân tích lu ồng dữ liệu, phân tích dữ liệu, đánh giá mã cân bằng, phân tích mã bao phủ và các thực hành xác nhận phần mềm khác

Kiểm thử tích hợp

Kiểm thử tích hợp là một hình thức kiểm thử phần mềm nhằm tìm cách xác minh các giao diện giữa các thành phần xung đột của một thiết kế Các thành phần này có thể tích hợp theo cách lặp đi lặp lại hoặc tất cả cùng nhau ("Big Bang") Thông thường cách thức này được coi là một thực hành tốt hơn vì nó cho phép các vấn đề về giao diện được định vị một cách nhanh chóng và cố định hơn

Kiểm thử tích hợp làm lộ ra các khiếm khuyết trong các giao diện và tương tác giữa các thành phần tích hợp (Modules) Các nhóm thành phần đã được kiểm thử lớn dần từng bước tương ứng với các thuộc tính của cấu trúc thiết kế đã được tích hợp và kiểm thử cho đến khi phần mềm hoạt động như một hệ thống

14

Kiểm thử hệ thống

Kiểm thử hệ thống giúp xác minh một hệ thống được tích hợp có đáp ứng đầy đủ các yêu cầu hay không Ngoài ra, kiểm thử phần mềm phải đảm bảo rằng các chương trình hoạt động như kỳ vọng, không còn bị phá hủy hay lỗi phần nào đó trong môi trường hoạt động của nó hoặc không gặp sự cố khi hoạt động với tiến trình khác

 Kiểm thử hệ thống bao gồm kiểm thử hộp đen, vì vậy các kiến thức

về thiết kế nội bộ hoặc cấu trúc hoặc code không cần thiết cho loại kiểm thử phần mềm này

 Kiểm thử hệ thống bao gồm kiểm thử chức năng và phi chức năng

 Kiểm thử hệ thống tập trung nhiều hơn vào các chức năng của toàn

bộ hệ thống

 Các trường hợp kiểm thử hệ thống bao gồm các chức năng của sản phẩm hoàn chỉnh và được thực hiện các trường hợp kiểm thử mức độ cao

 Các hành vi của ứng dụng hoàn chỉnh được kiểm tra để đáp ứng các yêu cầu quy định

 Các trường hợp kiểm thử và dữ liệu kiểm thử được thực hiện và các

dữ liệu thực tế không được sử dụng trong loại kiểm thử này

 Trong kiểm thử tích hợp hệ thống sẽ tích hợp các mô-đun khác nhau

và kiểm tra giao diện giữa chúng để kiểm tra tính toàn vẹn dữ liệu

 Trong khi thực hiện quá trình kiểm thử hệ thống, kiểm tra tính đúng đắn được thực hiện bởi nhân viên kiểm thử

Các kỹ thuật kiểm thử khác nhau được sử dụng trong kiểm thử hệ thống:

15

 Đây là một kiểm thử liên quan đến nhu cầu của người sử dụng, yêu cầu và quy trình kinh doanh đư ợc tiến hành để xác định có hay không một hệ thống đáp ứng các tiêu chí chấp nhận và kiểm tra hệ thống đáp ứng yêu cầu của khách hàng

 Kiểm thử chấp nhận kiểm thử các chức năng để kiểm tra hành vi của

hệ thống bằng cách sử dụng dữ liệu thực tế Nó cũng được gọi là thử nghiệm người dùng doanh nghiệp

 Kiểm thử chấp nhận được thực hiện bởi người dùng cuối để kiểm tra

hệ thống được xây dựng để phù hợp với yêu cầu kinh doanh của tổ chức

 Trong kiểm thử này, tất cả các giao diện đã được kết hợp và hệ thống

đã hoàn thành và đã được kiểm tra Người dùng cuối cũng thực hiện các kiểm thử để kiểm tra khả năng sử dụng của hệ thống

1.5 Quy trình kiểm thử

Quy trình kiểm thử tổng quát bao gồm các bước sau

Hình 1 4 Quy trình kiểm thử phần mềm [9]

16

1.6 Kiểm thử tự động

Việc tự động kiểm thử đang ngày càng được quan tâm sử dụng , đặc biệt

là sử dụng mô hình TDD (Test – Drive – Development) Có rất nhiều framework tích hợp trong môi trường phát triển nên thuận lợi cho mỗi phiên bản được chạy kiểm thử tự động mọi lúc khi tích hợp liên tục phần mềm [11]

Khi kiểm thử tự động không thể sao chép tất cả mọi thứ như con người

có thể làm nhưng nó có thể rất hữu ích cho việc kiểm thử hồi quy Tuy nhiên, nó cũng đòi hỏi phải có những kịch bản kiểm thử tốt để tiến hành kiểm thử

Kiểm thử tự động sử dụng trong các giai đoạn kiểm thử:

 Unit Testing( Kiểm thử đơn vị)

 Integration Testing( Kiểm thử tích hợp)

 Và trong các loại kiểm thử:

 Smoke Testing( Kiểm thử khói)

 Functional Testing( Kiểm thử chức năng)

 Regression Testing( Kiểm thử hồi quy)

 Và trong kỹ thuật kiểm thử:

 Black Box Testing( Kiểm thử hộp đen)

Các công cụ kiểm thử

Chương trình kiểm thử và phát hiện lỗi có thể được hỗ trợ đáng kể bởi các công cụ kiểm thử và gỡ lỗi Những màn hình chương trình cho phép giám sát toàn bộ hoặc một phần của mã chương trình gồm:

 Lệnh thiết lập giả lập (simulator) cho phép giám sát hoàn chỉnh cấp hướng dẫn và các thiết bị vi lượng

 Hình ảnh chương trình cho phép thực hiện từng bước và ngắt đoạn

có điều kiện ở cấp nguồn hoặc trong mã máy

 Các báo cáo độ bao phủ của mã

Các công cụ gỡ lỗi biểu tượng hoặc kết xuất định dạng cho phép kiểm tra các biến tại các chỗ lỗi và tại các điểm được lựa chọn

Các công cụ kiểm thử GUI chức năng tự động được sử dụng để lặp lại mức độ kiểm tra hệ thống thông qua GUI (giao diện đồ họa)

Điểm định chuẩn cho phép so sánh hiệu suất chạy thực được hoạt động

 Đặc điểm:

 Cung cấp các điều khoản để xuất khẩu ghi lại kịch bản trong các ngôn ngữ khác như Java, Ruby, RSpec, Python, C #, JUnit và TestNG

 Nó có thể thực hiện nhiều bộ kiểm thử cùng một lúc

 Xác định phần tử sử dụng id, tên, đường dẫn X, v.v

 Lưu trữ các bộ kiểm thử như Ruby Script, HTML và b ất kỳ định dạng nào khác

 Hỗ trợ tệp tin người dùng selenium-extensions.js

 Cho phép để chèn ý kiến ở giữa của kịch bản để hiểu rõ hơn nội dung

và mục đích của kịch bản kiểm thử

 QTP (HP UFT)

 Khái niệm:

QTP được sử dụng rộng rãi để kiểm tra chức năng( Functional Testing)

và hồi quy( Regression Testing), gi ải quyết các ứng dụng phần mềm và môi trường cài đặt Để đơn giản hóa việc tạo và bảo trì thử nghiệm, nó

sử dụng khái niệm kiểm tra từ khóa

 Đặc điểm:

 Được sử dụng dễ dàng hơn dành cho người kiểm thử viên không theo ngành kỹ thuật để thích ứng và tạo ra các trường hợp thử nghiệm làm việc

18

 Sửa lỗi nhanh hơn bằng cách ghi lại và sao chép các lỗi cho nhà phát triển

 Thu gọn tài liệu thử nghiệm tại một trang web

 QTP hỗ trợ môi trường phát triển NET

 Có cơ chế xác định đối tượng kiểm thử tốt

 Rational Function Tester

 Khái niệm:

Là 1 công cụ kiểm tra tự động hướng đối tượng có khả năng tự động kiểm tra dữ liệu, kiểm tra giao diện, và kiểm thử hồi quy( Regression Testing)

 Đặc điểm:

 Hỗ trợ một loạt các giao thức và ứng dụng như Java, HTML, NET, Windows, SAP, Visual Basic

 Có thể ghi lại và phát lại các hành động theo yêu cầu

 Tích hợp tốt với các công cụ quản lý kiểm soát nguồn như Rational Clear Case và tích hợp Rational Team Concert

 Cho phép các nhà phát triển tạo ra các kịch bản liên quan đến từ khóa

để có thể được tái sử dụng

 Bộ biên tập Công cụ Java Developer Toolkit của Eclipse tạo điều kiện cho nhóm tạo mã thử nghiệm các đoạn mã trong Java với Eclipse

 Hỗ trợ điều khiển tùy chỉnh thông qua proxy SDK (Java / Net)

 Hỗ trợ kiểm soát phiên bản để cho phép phát triển song song các kịch bản thử nghiệm

 WATIR

 Khái niệm:

Là một phần mềm kiểm tra mã nguồn mở để kiểm thử hồi quy( Regression Testing) Watir chỉ hỗ trợ khám phá Internet trên các cửa sổ trong khi Watir webdriver hỗ trợ Chrome, Firefox, IE, Opera

 Đặc điểm:

 Hỗ trợ nhiều trình duyệt trên các nền tảng khác nhau

 Sử dụng một ngôn ngữ kịch bản hiện đại có đầy đủ tính năng

19

 Hỗ trợ ứng dụng web được viết bởi bất kỳ ngôn ngữ

 Cho phép bạn viết các test case dễ đọc và bảo trì

 SilkTest

 Khái niệm:

Silk Test được thiết kế để thực hiện kiểm tra chức năng( Functional Testing) và hồi quy( Regression Testing) Nó là một ngôn ngữ hướng đối tượng giống như C ++ Nó sử dụng các khái niệm về đối tượng, các class và sự kế thừa

 Đặc điểm:

 Nó bao gồm tất cả các tập tin mã nguồn

 Chuyển đổi các lệnh script thành các lệnh GUI Trên cùng một máy, các lệnh có thể được chạy trên một máy từ xa hoặc máy chủ

 Để xác định chuyển động của con chuột cùng với các bấm phím, Silktest có thể được thực hiện Nó có thể sử dụng cả phương pháp phát lại và ghi hoặc các phương pháp lập trình mô tả

 Xác định tất cả các điều khiển và cửa sổ của ứng dụng được thử dưới dạng các đối tượng và xác định tất cả thuộc tính và thuộc tính của mỗi đối tượng

1.7 Tổng kết chương

Kiểm thử phần mềm là một bước quan trọng trong quá trình phát triển phần mềm, nhằm đưa đến cho người dùng cuối một sản phẩm tốt Khi thực hiện kiểm thử phần mềm cần nhiều bước thực hiện theo thứ tự tuần tự, tùy thuộc vào từng phương pháp, việc kiểm thử có thể được thực hiện bất cứ lúc nào trong quá trình phát triển phần mềm Với phương pháp truyền thống thì các nỗ lực kiểm thử được tiến hành sau khi các yêu cầu được xác định và việc lập trình được hoàn tất, nhưng trong Agile (là một tập hợp các phương pháp phát triển phần mềm linh hoạt dựa trên việc lặp đi lặp lại và gia tăng giá trị) thì việc kiểm thử được tiến hành liên tục trong suốt quá trình xây dựng phần mềm Như vậy, mỗi một phương pháp kiểm thử bị chi phối theo một quy trình phát triển phần mềm nhất định

20

CHƯƠNG 2 KIỂM THỬ HỒI QUY ỨNG DỤNG DI ĐỘNG

Công nghệ điện thoại di động và các thiết bị thông minh hiện nay là xu hướng và cũng là tương lai của thế giới Mỗi ngày có hàng triệu ứng dụng được tải (download) từ kho ứng dụng (Appstore hoặc Google Play) về các thiết bị cá nhân Các ứng dụng di động rất phong phú đa dạng đáp ứng đủ các nhu cầu học tập, chăm sóc sức khỏe hay giải trí, kinh doanh của người dùng Để kiểm thử được các ứng dụng trên các thiết bị di động (Mobile App Testing) thì trước hết ta cần hiểu về các thiết bị di động [12]

Khi xây dựng một phiên bản mới của hệ thống (ví dụ sau khi sửa lỗi, thay đổi hoặc thêm chức năng, v.v.), có thể vô tình gây ra các lỗi mới Nhiều khi thay đổi rất nhỏ cũng gây những vấn đề lớn ngoài sức tưởng tượng của đội phát triển Để tránh những việc đáng tiếc này xảy ra cần kiểm thử lại phần mềm để đảm bảo các chức năng đã chạy tốt vẫn tiếp tục chạy tốt

2.1 Ứng dụng trên các thiết bị di động (Mobile application)

Ứng dụng di động là những ứng dụng chỉ được sử dụng cho các thiết bị

di động hoặc tablet thông qua các cửa hàng trực tuyến của các hãng như App Store của Apple hay Google Play của Google Những ứng dụng này phát triển dựa trên mã hoặc framework cho mỗi nền tảng, điều này sẽ gây cản trở cho một số máy nhất định Ở những smartphone tầm thấp có thể không chạy được ứng dụng do cấu hình thấp hoặc cần một hệ điều hành mới hơn

Hình 2 1 Các lĩnh vực ứng dụng mobile [12]

21

Các dạng ứng dụng trên thiết bị di động bao gồm:

 Native Application: Các ứng dụng này được phát triển cho một nền

tảng cụ thể và được cài trên thiết bị

 Web Based Applications: Các ứng dụng được truy cập thông qua

trình duyệt của thiết bị

 Hybrid Application: Là loại ứng dụng kết hợp các yếu tố của cả

Native app và Web app

Hình 2 2 Các loại ứng dụng mobile[11]

2.2 Kiểm thử ứng dụng cho thiết bị di động

2.2.1 Kiểm thử ứng dụng di động

Kiểm thử ứng dụng di động là một quá trình mà các phần mềm ứng dụng được phát triển cho các thiết bị di động cầm tay được thử nghiệm chức năng của nó, khả năng sử dụng và tính nhất quán Kiểm thử ứng dụng di động có thể được tự động hóa hoặc thực hiện bằng tay Ứng dụng di động hoặc được cài đặt trước hoặc có thể được cài đặt từ các nền tảng phân phối phần mềm điện thoại di động

Với mỗi loại ứng dụng thì kiểm thử ứng dụng di động đều đóng vai trò rất quan trọng Vì số lượng lượt tải ứng dụng thường lên tới hàng triệu lượt cho một sản phẩm nào đó Do vậy, một ứng dụng bị lỗi không bao giờ được đánh giá cao Nó thường gây tổn thất về mặt tài chính, vấn đề pháp lý và không thể khắc phục thiệt hại hình ảnh thương hiệu sản phẩm

 Đa nền tảng (iOS 6,7,8, Android 4.2;4.3;4.4 , BB 5;BB6 )

 Các thiết bị di đông có thời gian chạy ứng dụng khác nhau

 Thách thức phần cứng của thiết bị:

 Giới hạn tốc độ xử lý

 Giới hạn dung lượng bộ nhớ của thiết bị

 Sự khác biệt về giao thức của thiết bị WAP/HTTP

 Thách thức về đường truyền mạng:

 Đa dạng các loại mạng (GSM/GPRS/WIFI/3G…)

 Không dự đoán được thời gian cho truyền tải dữ liệu

 Khác biệt về tốc độ kết nối thông qua vật lý

 Đa dạng các nhà điều hành mạng với những tính năng mạng khác nhau

 Ngoài ra kiểm thử ứng dụng di động cũng bao gồm các dạng kiểm thử sau:

 Kiểm thử giao diện (UI Testing): Kiểm tra màu sắc, phong cách Menu, nhất quán của giao diện người dùng trên các thiết bị khác nhau

 Kiểm thử chức năng (Function Testing): Kiểm tra các chức năng

chính của ứng dụng di động theo đặc điểm kĩ thuật của thiết bị

 Kiểm thử hiệu suất và chịu tải (Performance and Load Test) :

Kiểm tra hành vi của ứng dụng di động trong các nguồn tài nguyên thấp (Bộ nhớ/ Không gian lưu trữ), hành vi của trang web điện thoại

di động khi ngiều người sử dụng điện thoại di động cùng truy cập vào trang app di động

 Kiểm tra khả năng sử dụng (Usability Testing): Kiểm tra các khía

cạnh khả năng sử dụng các ứng dụng di động

23

 Thử nghiệm tương thích (Compatibility Testing) : Kiểm tra khả

năng tương thích của ứng dụng của bạn với các tính năng thiết bị gốc

để đảm bảo rằng ứng dụng của bạn không cản trở các ứng dụng khác

trong thiết bị

2.3 Kỹ thuật kiểm thử hồi quy trong ứng dụng di động

Khi phiên bản mới của phần mềm không còn hoạt động như trước thì

phiên bản mới hồi quy với bản trước đó Phiên bản mới không hồi quy tức

là nó vẫn giữ được các tính năng là một yêu cầu chất lượng cơ bản

Hồi quy có thể được thực hiện bằng các kỹ thuật sau:

Hình 2 3 Các kỹ thuật thực hiện hồi quy [4]

Phương pháp đơn giản để kiểm thử hồi quy là chạy lại tất cả các ca kiểm

thử của phiên bản trước Tuy nhiên việc kiểm lại toàn bộ này rất tốn kém

và không tầm thường Các ca kiểm thử trước đó có thể không chạy lại được

với phiên bản mới của phần mềm mà không sửa đổi gì Một bộ kiểm thử

chất lượng tốt phải được duy trì xuyên suốt các phiên bản của hệ thống

Thay đổi trong phiên bản phần mềm mới có thể tác động tới khuôn dạng

của đầu vào và đầu ra, và các ca kiểm thử có thể cần các thay đổi tương

ứng để chạy được Ngay cả việc sửa đổi một cách đơn giản của cấu trúc dữ

liệu, chẳng hạn như việc bổ sung các trường hay sự thay đổi nhỏ của các

loại dữ liệu, có thể làm các ca kiểm thử trước đây không chạy được nữa

Hơn nữa, một số ca kiểm thử có thể bị lỗi thời, khi các tính năng của phần

mềm đã thay đổi hoặc bị loại bỏ khỏi phiên bản mới

Các khung hỗ trợ để dịch đặc tả kiểm thử thành ca kiểm thử sẽ giúp giảm

ảnh hưởng của thay đổi định dạng của đầu vào và đầu ra Các đặc tả ca

24

kiểm thử và các mệnh đề về kết quả mong đợi mà phản ánh tính đúng của

ca kiểm thử và tránh các chi tiết cụ thể sẽ giảm một phần lớn công sức kiểm thử khi có thay đổi nhỏ

Các bộ kiểm thử chất lượng cao có thể được duy trì qua các phiên bản của phần mềm bằng việc xác định và loại bỏ các ca kiểm thử lỗi thời Việc

dư thừa là do nhiều người cùng làm hoặc do chương trình bị thay đổi gây ra Các ca kiểm thử dư thừa không ảnh hưởng đến tính đúng, sai, mà chỉ ảnh hưởng đến chi phí kiểm thử

2.4 Qui trình kiểm thử hồi quy

Trong thực tế sẽ có một số biến thể về các qui trình phát triển và qui trình kiểm thử (bao gồm kiểm thử hồi qui) tùy thuộc vào từng tổ chức phần mềm Tuy nhiên, về cơ bản, một qui trình kiểm thử hồi quy được thực hiện qua các giai đoạn sau được áp dụng cho phát triển ứng dụng desktop, web

và mobile:

Hình 2 4 Qui trình tổng quát cho kiểm thử hồi quy

25

Trong các phương pháp phát triển linh hoạt nhanh hiện nay bao gồm

XP, Scrum, DSDM, Lean và FDD thì Scrum đư ợc ưu tiên lựa chọn như là một phương pháp, một khung phát triển dự án theo phương pháp linh hoạt (agile) phổ biến Và đặc biệt, qui trình này phù hợp với các dự án phát triển ứng dụng di động nói riêng và những ứng dụng có tính thay đổi yêu cầu cao, đòi hỏi sản phẩm xuất xưởng sớm nhưng yêu cầu về chất lượng không hề giảm mà ngày càng cao hơn

Kiểm thử hồi quy là một phần quan trọng của quá trình kiểm soát chất lượng phần mềm Trên thực tế, đối với qui trình phát triển ứng dụng truyền thống, qui trình kiểm thử hồi qui được nghiên cứu và đề xuất tương ứng và rõ ràng

Hình 2.5 dưới đây là đề xuất qui trình thực hiện kiểm thử và kiểm thử hồi quy trong từng sprint của dự án/sản phẩm; ứng dụng phương pháp phát triển TDD, hoạt động kiểm thử ngay từ giai đoạn đầu của mỗi sprint, việc lặp lại sau khi refactoring cũng đư ợc xem là hoạt động hồi quy và tích hợp liên tục (CI – continuos integration) Và k ết thúc mỗi một giai đoạn nước rút (sprint) sẽ thực hiện hồi quy toàn bộ phiên bản thứ i, tiếp tục thay đổi,

bổ sung tính năng, yêu cầu và mở ra sprint tiếp theo Các yêu cầu (stories/backlog) sẽ không được thay đổi mỗi khi Sprint đó đã đư ợc thực thi

Hình 2 5 Kiểm thử hồi quy trong phương pháp phát triển Agile[11]

26

Để thiết kế, phát triển và triển khai các tính năng mới, nhưng điều quan trọng là phải đảm bảo rằng những thay đổi mới cho sản phẩm không phá vỡ chức năng hiện có, không xuất hiện các lỗi mới, hoặc xuất hiện lại các lỗi được giải quyết trước đó Công việc này có thể là tẻ nhạt và ít thú vị đối với các nhà kiểm thử Do đó, việc kết hợp kiểm thử hồi quy bằng tay và tự động được kết hợp với nhau Sau khi thiết lập một chiến lược thử nghiệm, kiểm tra hồi quy có thể được tối ưu hóa để có được giá trị tốt nhất về công sức, nỗ lực thực hiện kiểm thử Cụ thể, rất hiếm khi có một yêu cầu để kiểm tra mọi sự kết hợp có thể có của các nền tảng, hệ điều hành, và các thiết bị - vì vậy chiến lược là để xác định các khu vực có nguy cơ cao và tập trung vào những điểm này Những khu vực này sẽ phát hiện ra 90% các khiếm khuyết của ứng dụng

2.5 Các vấn đề nên kiểm thử hồi quy

i Bao gồm các trường hợp thử nghiệm có thường xuyên mang lại lỗi: Một số khu vực trong ứng dụng rất dễ bị lỗi do sau một sự thay đổi lập trình nhỏ Có thể theo dõi các trường hợp thử nghiệm không thành công, thành công trong suốt chu kỳ sản phẩm trong bộ kiểm tra hồi quy

ii Bao gồm các trường hợp kiểm tra xác minh tính năng cốt lõi của ứng dụng: Trước thiết kế các trường hợp thử nghiệm, xác định tất cả các tính năng cốt lõi của ứng dụng Đảm bảo rằng các trường hợp thử nghiệm bao gồm tất cả các chức năng được đề cập trong tài liệu yêu cầu Có thể sử dụng một ma trận truy xuất để đảm bảo rằng không có yêu cầu nào là không được kiểm tra

iii Bao gồm các trường hợp thử nghiệm cho các chức năng đã trải qua những thay đổi gần đây Duy trì lịch sử của thay đổi chức năng cho tài liệu trường hợp thử nghiệm để xác định các trường hợp thử nghiệm để bao gồm trong bộ hồi quy

iv Bao gồm tất cả các trường hợp thử nghiệm tích hợp Ngay cả khi thử nghiệm tích hợp là một phần riêng biệt của chu kỳ kiểm thử phần mềm, các trường hợp thử nghiệm của nó phải được bao gồm trong bộ kiểm tra hồi quy Một sửa chữa phút cuối cùng, một ứng dụng đã được thử nghiệm có thể phá vỡ tính toàn vẹn giữa hai mô-đun khác nhau Ví dụ: dữ liệu có thể

bị mất trên một giao diện, tin nhắn có thể không nhận được thông báo đúng, hoặc giao diện có thể không được thực hiện như đã chỉ định

27

v Bao gồm tất cả các trường hợp thử nghiệm phức tạp: Một số chức năng

hệ thống chỉ có thể được thực hiện bằng cách làm theo một chuỗi các sự kiện giao diện người dùng đồ hoạ (GUI) phức tạp Để mở một tệp, người dùng có thể phải nhấp vào menu 'Tệp' và sau đó chọn 'Mở', sử dụng hộp thoại để chỉ định tên tệp và sau đó tập trung ứng dụng vào cửa sổ mới mở

Rõ ràng, số lượng các hoạt động có thể tăng lên theo cấp số nhân Điều này

có thể trở thành một vấn đề nghiêm trọng; trong một số tình huống, chức năng của toàn bộ hệ thống bị dừng lại Kết quả là, tất cả các trường hợp thử nghiệm phức tạp phải là một phần của bộ kiểm tra hồi quy

vi Ưu tiên các trường hợp thử nghiệm để kiểm tra hồi quy: Ưu tiên các trường hợp thử nghiệm liên quan đến tác động kinh doanh và các chức năng quan trọng và được sử dụng thường xuyên Sẽ rất hữu ích nếu phân tích được hoàn thành để xác định trường hợp thử nghiệm nào có liên quan Một

ý tưởng là phân loại các trường hợp thử nghiệm thành các ưu tiên khác nhau dựa trên tầm quan trọng và việc sử dụng của khách hàng Việc lựa chọn các trường hợp thử nghiệm dựa trên mức độ ưu tiên sẽ giảm đáng kể các nỗ lực dành cho kiểm tra hồi quy

vii Phân loại các trường hợp kiểm tra đã chọn: Thử nghiệm hồi quy trở nên rất khó khăn khi phạm vi ứng dụng lớn và có các gia tăng liên t ục hoặc các bản vá cho hệ thống Trong những trường hợp như vậy, các bài kiểm tra chọn lọc cần được thực hiện để tiết kiệm cả chi phí và thời gian thử nghiệm Phân loại các trường hợp thử nghiệm làm cho công việc này dễ dàng hơn Các trường hợp thử nghiệm lỗi thời: Đây là lỗi cụ thể và không thể được sử dụng trong các chu k ỳ kế tiếp Cách thông minh để sử dụng chúng là khi lỗi tương ứng xuất hiện

viii Chọn các trường hợp thử nghiệm trên cơ sở 'case-to-case': Có thể có một số phương pháp tiếp cận chính xác để kiểm tra hồi quy phải được quyết định theo từng trường hợp cụ thể:

Nếu mức độ nghiêm trọng và tác động của các bản sửa lỗi thấp, thì đó là

đủ để một kỹ sư kiểm tra chọn vài trường hợp kiểm tra từ công cụ quản lý kiểm tra và thực hiện chúng Các trường hợp thử nghiệm này có thể thuộc bất kỳ Mức độ ưu tiên nào (0, 1 hoặc 2)

Nếu mức độ nghiêm trọng và tác động của các bản sửa lỗi là vừa, người kiểm tra cần phải thực hiện tất cả các trường hợp thử nghiệm Ưu tiên 0 và

Ưu tiên 1 Nếu sửa lỗi cần thêm các trường hợp thử nghiệm từ Mức độ ưu

28

tiên 2, thì những trường hợp thử nghiệm đó cũng có thể được chọn và sử dụng để kiểm tra hồi quy Chọn các trường hợp kiểm tra Mức độ ưu tiên 2 trong trường hợp này là mong muốn nhưng không bắt buộc

Nếu mức độ nghiêm trọng và tác động của các bản sửa lỗi cao, thì cần phải thực hiện tất cả các trường hợp Ưu tiên 0, Ưu tiên 1 và các trư ờng hợp thử nghiệm Mức độ ưu tiên 2 được chọn cẩn thận

Một cũng có thể đi qua bản ghi đầy đủ các thay đổi đã xảy ra như là kết quả của các bản sửa lỗi và chọn các trường hợp kiểm tra để tiến hành kiểm tra hồi quy Đây là một quá trình phức tạp nhưng có thể cho kết quả rất tốt

ix Phân loại các trường hợp kiểm tra hồi quy dựa trên rủi ro tiếp xúc Việc phân loại các trường hợp kiểm tra hồi quy phải được thực hiện vào đầu dự báo

2.6 Công cụ hỗ trợ kiểm thử hồi quy ứng dụng di động

Một số công cụ kiểm thử tự động hỗ trợ kiểm thử hồi quy phổ biến [14]:

ta biết cần phải hồi quy khu vực nào, tiết kiệm được công sức và chi phí phát triển phần mềm