Kiểm thử ứng dụng ICTU social trên nền android

dung của riêng mình.Để kiểm thử hiệu quả các ứng dụng trên điện thoại, kiểm thử viên cần có kỹ năng sau: Kỹ năng tốt về kiểm thử phần mềm, hiểu biết về ứng dụng, kiến thức về công nghệ t

 LỜI CẢM ƠN Sau một thời gian tìm hiểu đề tài “Kiểm thử ứng dụng “ICTU_Social” trên nền Android”, em đã hoàn thành tiến độ dự kiến Để đạt được kết quả này,

em đã nỗ lực thực hiện và đồng thời cũng nhận được rất nhiều sự giúp đỡ, quan tâm, ủng hộ của các thầy cô bạn bè gia đình và đặc biệt là các anh chị tại cơ sở thực tập – Trung tâm nghiên cứu và phát triển ứng dụng di động (RDCMA)

Em xin chân thành cảm ơn giáo viên hướng dẫn: Ths.Nguyễn Thu Phương–

Bộ môn Công nghệ phần mềm – Trường Đại học Công nghệ thông tin và truyền thông – Đại học Thái Nguyên đã tận tình giúp đỡ em hoàn thành đồ án này

Em xin chân thành cảm ơn các thầy cô và ban lãnh đạo trường Đại học Công nghệ thông tin và truyền thông – Đại học Thái Nguyên đã nhiệt tình giảng dạy và truyền đạt kiến thức quý báu và bổ ích trong suốt quá trình em học tập tại trường

Em xin chân thành cảm ơn các thầy, cô giáo viên thuộc bộ môn Công nghệ phần mềm đã trang bị cho em những kiến thức chuyên ngành rất hữu ích để em hoàn thành đề tài và phục vụ cho công việc của em sau này

Vì thời gian có hạn nên không thể tránh khỏi những thiếu sót, em rất mong nhận được sự đóng góp ý kiến từ thầy cô và các bạn

Em xin chân thành cảm ơn!

 LỜI CAM ĐOAN Tôi: Đỗ Thị Ánh Hồng xin cam đoan:

 Những nội dung trong đồ án này hoàn toàn là do tôi thực dưới sự hướng dẫn trực tiếp của giáo viên hướng dẫn: Ths.Nguyễn Thu Phương

 Đồ á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 31 tháng 5 năm 2016

Sinh viên

Đỗ Thị Ánh Hồng

1.1 Các khái niệm cơ bản về kiểm thử phần mềm 10

1.3 Phương pháp kiểm thử ứng dụng “ICTU_Social”20

1.3.1 Lựa chọn phương pháp kiểm thử 20

1.3.2 Các phương pháp kiểm thử thủ công dùng trong quá trình kiểm thử ứng dụng “ICTU_Social” 22

CHƯƠNG 2 QUY TRÌNH KIỂM THỬ ỨNG DỤNG TRÊN MOBILE 262.1 Xác định chiến lược kiểm thử 26

2.2 Lập kế hoạch kiểm thử(Test Plan) 29

2.3 Thiết kế kịch bản kiểm thử (Test Case) 34

2.4 Thực thi test case 37

2.5 Phân tích kết quả kiểm thử 37

2.6 Tổng hợp báo cáo 38

CHƯƠNG 3 KIỂM THỬ ỨNG DỤNG “ICTU_Social” 403.1 Đặc tả hệ thống 40

3.2 Thiết kế Testplan cho dự án 47

3.3 Thiết kế Testcase và kết quả thực hiện Testcase 52

3.3.1 Testcase chung cho ứng dụng 52

3.3.2 Testcase kiểm tra giao diện 54

3.3.3 Testcase cho chức năng 55

3.3.4 Testcase kiểm thử hiệu suất và chịu tải 61

3.3.5 Testcase kiểm thử tương thích 62

3.3.6 Testcase kiểm tra gián đoạn 62

3.4 Phân tích kết quả kiểm thử 64

3.5 Tổng hợp báo cáo 64

KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN65

TÀI LIỆU THAM KHẢO 66

Hình 3.6 Giao diện chức năng Tin nhắn 44

Hình 3.7 Chức năng Vote/ Bình luận/ Xem chi tiết bài viết 45

Hình 3 8 Chức năng trong Friends 46

Hình 3.9 Giao diện trang cá nhân 47

Hình 3.10 Testcase chung cho ứng dụng 1 52

Hình 3.11 Kết quả thực hiện testcase(Chức năng Zoom không hoạt động) 53Hình 3.12 Testcase chung cho ứng dụng 2 53

Hình 3.13 Testcase kiểm tra giao diện 54

Hình 3.14 Kết quả thực hiện testcase 54

Hình 3.15 Testcase cho chức năng Đăng nhập 55

Hình 3.16 Các trường hợp lỗi khi thực hiện chức năng Login 55

Hình 3.17 Testcase cho chức năng Đăng bài viết/Status 56

Hình 3.18 Kết quả thực hiện kiểm thử chức năng Sent 56

Hình 3.19 Testcase cho chức năng Vote, Bình luận, Điều hướng đến Friend 57Hình 3.20 Kết quả thực hiện testcase cho chức năng Vote(Hiệu ứng vote) 57

Hình 3.21 Kết quả thực hiện testcase cho chức năng Bình luận 58

Hình 3.22 Kết quả thực hiện testcase cho chức năng Điều hướng đến Friend

59

Hình 3.23 Testcase cho chức năng trên Trang cá nhân 60

Hình 3.24 Kết quả thực hiện testcase cho chức năng điều hướng đến trang cá nhân

60

Hình 3.25 Testcase kiểm thử hiệu suất và chịu tải 61

Hình 3.26 Kết quả chạy testcase kiểm thử hiệu suất và chịu tải(3 người dùng)

61

Hình 3.27 Testcase kiểm thử tương thích 62

Hình 3.28 Gián đoạn bởi tin nhắn/Camera/Media 62

Hình 3.29 Gián đoạn bởi yêu cầu bộ nhớ và Pin 63

Hình 3.30 Gián đoạn bởi SIM/Ngày giờ/Email/Trò chơi 63

Hình 3.31 Gián đoạn bởi Kết nối mạng/Thông báo/Bluetooth 64

LỜI MỞ ĐẦU

Ngày nay ngành công nghiệp phần mềm hiện nay đang đạt được những thành tựu đáng kể tuy vẫn còn nhiều khó khăn và thách thức Một trong khó khăn hàng đầu luôn được đề cập đến là vấn đề thiếu hụt nguồn nhân lực cả về lượng lẫn

về chất, trong đó đáng kể nhất là sự thiếu hụt đội ngũ chuyên viên kiểm thử phần mềm chuyên nghiệp

Chất lượng của phần mềm rất quan trọng Kiểm thử là một thành phần chính của phát triển phần mềm để đảm bảo độ tin cậy và chất lượng của phần mềm Muốn tạo ra ứng dụng có hiệu năng cao, đáng tin cậy thì sau bước xây dựng, cần phải kiểm thử ứng dụng đó một cách tỉ mỉ, cẩn thận và chặt chẽ Cũng như các ngành sản xuất khác quy trình là một trong những yếu tố cực kỳ quan trọng đem lại

sự thành công cho các nhà sản xuất phần mềm, nó giúp cho mọi thành viên trong

dự án có thể làm việc hiệu quả hơn từ đó chất lượng sản phẩm phần mềm làm ra sẽ tốt hơn

Hiện nay rất nhiều ứng dụng được xây dựng trên nền tảng Android Android

là một nền tảng phần mềm dựa trên mã nguồn mở Linux OS (Kernel 2.6) cho máy

di động, máy tính bảng và những phần mềm trung gian(middleware) Nó không đơn thuần là một hệ điều hành, một công cụ lập trình hay một phần mềm trung gian mà nó gồm tất cả Ứng dụng mạng xã hội hay còn gọi là Facebook(ứng dụng Facebook chạy trên rất nhiều hệ điều hành trong đó có hệ điều hành Android) vẫn đang là mạng xã hội lớn nhất hiện nay với hơn 1,15 tỉ người dùng Mạng xã hội là

sự kết hợp giữa các bài tự đăng và chia sẻ nội dung Không chỉ những người trẻ tuổi mới sử dụng mạng xã hội, mà công cụ này hiện đã mang tính toàn cầu và được gắn với mọi ngõ ngách của Internet, thậm chí trở thành tài sản kĩ thuật số đối với nhiều cá nhân, doanh nghiệp Nhiều doanh nghiệp đang nỗ lực không ngừng trong việc xây dựng mạng lưới những người theo dõi họ trên mạng xã hội, đồng thời tạo

ra một diễn đàn riêng, tự phát triển các kênh marketing và mạng lưới phân phối nội

dung của riêng mình.

Để kiểm thử hiệu quả các ứng dụng trên điện thoại, kiểm thử viên cần có kỹ năng sau: Kỹ năng tốt về kiểm thử phần mềm, hiểu biết về ứng dụng, kiến thức về công nghệ trên thiết bị di động, hiểu biết về các kỹ thuật kiểm thử, hiểu biết về các loại lỗi đặc trưng và kiến thức về một số công cụ và khả năng áp dụng của chúng

Chính vì vậy em đã chọn đề tài “Kiểm thử ứng dụng “ICTU_Social” trên nền

Android” với mục đích nghiên cứu, tìm hiểu về kiểm thử, quy trình kiểm thử ứng dụng trên mobile và tiến hành kiểm thử ứng dụng trên mobile để có thể đảm bảo phần mềm đáp ứng nhu cầu người dùng, phần mềm chạy đúng chức năng

 Mục tiêu nghiên cứu

Mục tiêu của nghiên cứu trong quá trình thực tập như sau:

 Tìm hiểu về kiểm thử phần mềm và các quy trình kiểm thử phần mềm

 Quy trình kiểm thử ứng dụng trên mobile

 Kĩ thuật xây dựng Testplan và Testcase

 Kĩ thuật kiểm thử ứng dụng trên nền Android

 Phương pháp nghiên cứu

 Phương pháp nghiên cứu kết hợp các phương pháp tổng hợp, thống kê, phân tích và tham khảo một vài ý kiến của các thầy cô hướng dẫn cũng như doanh nghiệp hướng dẫn…

 Phương pháp nghiên cứu lý thuyết: đọc tài liệu, phân tích và tổng hợp tài liệu nghiên cứu

 Tham khảo tài nguyên trên internet dưới sự chỉ dẫn của giáo viên hương dẫn

 Phạm vi nghiên cứu: Trong thời gian rất có hạn, đề tài chỉ giới hạn

nghiên cứu trong phạm vi có thể:

 Tìm hiểu kiểm thử phần mềm và các quy trình kiểm thử phần mềm

 Quy trình kiểm thử ứng dụng trên mobile

 Tiến hành xây dựng Testplan và Testcase.

 Tiến hành kiểm thử ứng dụng Android dựa trên Testplan và Testcase

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ụ 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

 Các phương pháp kiểm thử

Có 2 phương pháp kiểm thử chính là: Kiểm thử tĩnh và Kiểm thử động

 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.

 Các chiến lược kiểm thử

Ba trong số những chiến lược kiểm thử thông dụng nhất bao gồm: Kiểm thử hộp đen, Kiểm thử hộp trắng và Kiểm thử hộp xám.

 Kiểm thử hộp đen – Black box testing

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 chỉ 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.

 Phân tích giá trị biên – Boundary value analysis.

 Kiểm thử mọi cặp – All-pairs testing.

 Kiểm thử fuzz – Fuzz testing

 Kiểm thử dựa trên mô hình – Model-based testing

 Ma trận dấu vết – Traceability matrix.

 Kiểm thử thăm dò – Exploratory testing.

 Kiểm thử dựa trên đặc tả – Specification-base testing.

Kiểm thử dựa trên đặc tả tập trung vào kiểm tra tính thiết thực của phần mềm theo những yêu cầu thích hợp Do đó, kiểm thử viên nhập dữ liệu vào, và chỉ thấy dữ liệu ra từ đối tượng kiểm thử Mức kiểm thử này thường yêu cầu các ca kiểm thử triệt để được cung cấp cho kiểm thử viên

mà khi đó có thể xác minh là đối với dữ liệu đầu vào đã cho, giá trị đầu ra (hay cách thức hoạt động) có giống với giá trị mong muốn đã được xác định trong ca kiểm thử đó hay không Kiểm thử dựa trên đặc tả là cần thiết, nhưng không đủ để để ngăn chặn những rủi ro chắc chắn.

 Ư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 tâm 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 Nhưng, mặt khác, người ta cũng nói kiểm thử hộp đen “giống như là đi trong bóng tối mà không có đèn vậy”, bởi vì kiểm thử viên không biết các phần mềm được kiểm tra thực sự được xây dựng như thế nào Đó 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 1 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ù”.

 Kiểm thử hộp trắng – White box testing

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

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: kiểm thử hộp trắng bao gồm mọi kiểm thử tĩnh.

Phương pháp kiểm thử hộp trắng cũng có thể được sử dụng để đánh giá sự hoàn thành của một bộ kiểm thử mà được tạo cùng với các phương pháp kiểm thử hộp đen Điều này cho phép các nhóm phần mềm khảo sát các phần của 1 hệ thống

ít khi được kiểm tra và đảm bảo rằng những điểm chức năng quan trọng nhất đã được kiểm tra

 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.

 Kiểm thử tích hợp – Intergration Test

Integration test 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

 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

 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.

 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

System Test lại gồm nhiều loại kiểm thử khác 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 (ví dụ nhiều người truy xuất cùng lúc) Stress Test tập trung vào các trạng thái tới hạn, các “điểm chết”, các tình huống bất thường như đang giao dịch thì ngắt kết nối (xuất hiện nhiều trong kiểm tra thiết bị như POS, ATM…)…

 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…

 Kiểm thử chấp nhận sản phẩm – 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

 Tổng quan về thiết bị di động và các nền tảng di động hiện nay

 Tổng quan về thiết bị di động

 Định nghĩa:

Một thiết bị di động là một thiết bị máy tính kích thước nhỏ bỏ túi, điển hình là với màn hình hiển thị với các phím cảm ứng hoặc các bàn phím nhỏ

 Các nền tảng di động hiện nay (Mobile Platform)

Có rất nhiều các hệ điều hành dành cho di động hiện nay trên thị trường như Android, iOS, Blackberry, J2ME, Symbian, Palm, Windows phone, Samsung Bada, Nokia Meego… Kiến thức về các hệ điều hành cho di động thực sự rất quan trọng để trở thành 1 kỹ sư kiểm thử di động giỏi Những hiểu biết về khả năng và hạn chế của từng hệ điều hành sẽ cho người kiểm thử viên sự tự tin để phân biệt được đâu là lỗi ứng dụng và đâu là giới hạn của hệ điều hành

Hiện nay trên thị trường thịnh hành các thiết bị di động sử dụng các hệ điều hành như hình dưới đây:

 iOS (Iphone, Ipad)

 Android (SamSung, Sony, HTC…)

 WindowPhone (Nokia, HTC)

 BlackBerry (BlackBerry)

 Khảo sát số lượng người sử dụng Smartphone

 Từ những số liệu của công ty Appota liên quan tới lĩnh vực di động tại Việt Nam, hiện nay nước ta đang có khoảng 22 triệu người sử dụng smartphone tức

là cứ 4 người Việt lại có 1 người sử dụng điện thoại thông minh

 Cũng theo thống kê này, trong gần 200 triệu lượt tải ứng dụng năm

2014, có gần 60% ứng dụng tải từ iOS còn lại là Android

Hình 1.2 Số lượng người sử dụng Smartphone ở Việt Nam

di động Trong đó, tỉ lệ người sử dụng mạng xã hội trong độ tuổi 18-29 đạt tới 89%, trong khi đó độ tuổi 30-49 chỉ là 72%; 60% những người trong độ tuổi từ 50 đến 60 đang hoạt động trên các mạng xã hội, còn nhóm người ở độ tuổi trên 65 chỉ

là 43%

 Theo thống kê, hiện có 23% người dùng Facebook đăng nhập ít nhất 5 lần mỗi ngày, thời gian dành cho Facebook trong mỗi giờ vào mạng tùy thuộc vào từng quốc gia (top 3 sử dụng nhiều nhất hiện nay đang là Mỹ với 16 phút, Australia 14 phút và Anh là 13 phút)

 Cũng theo thống kê số lượng người sử dụng smartphone truy cập mạng

xã hội đạt 62%(2015) Đây là con số ấn tượng về sự phát triển vượt bậc và nhanh chóng của mạng xã hội Facebook đồng thời khẳng định vị trí dẫn đầu trong số các mạng xã hội hiện nay

Hình 1.3 Tỷ lệ người sử dụng mạng xã hội.

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

Một phần mềm ứng dụng trên thiết bị di động, còn được gọi tắt là ứng dụng

di động, hoặc ứng dụng, (tiếng Anh: Mobile app hoặc app) là phần mềm ứng dụng được thiết kế để chạy trên điện thoại thông minh, máy tính bảng và các thiết

bị di động khác

Các ứng dụng thường có sẵn thông qua các nền tảng phân phối ứng dụng, bắt đầu xuất hiện vào năm 2008 và thường được điều hành bởi các chủ sở hữu của hệ điều hành di động, như Apple App Store, Google Play, Windows Phone Store, và BlackBerry App World Một số ứng dụng miễn phí, trong khi một số ứng dụng phải được mua

Thuật ngữ "ứng dụng" là một rút ngắn của thuật ngữ "phần mềm ứng dụng" Trong tiếng Anh, thường được viết là app và đã trở thành rất phổ biến và trong năm 2010 đã được liệt kê như là " từ ngữ của năm" do Hiệp hội American Dialect Society chọn lọc

Ứng dụng di động ban đầu được cung cấp với mục đích thông tin tổng quát

và các dịch vụ thông dụng trên mạng toàn cầu, bao gồm email, lịch, danh bạ, và thị trường chứng khoán và thông tin thời tiết Tuy nhiên, nhu cầu chung của những người sử dụng thiết bị di động và khả năng phát triển của các nhà lập trình đã mở rộng thành các loại khác, chẳng hạn như trò chơi di động, tự động hóa nhà máy, GPSvà các dịch vụ dựa trên địa điểm, định vị và ngân hàng, để theo dõi, mua

vé và các ứng dụng y tế di động gần đây Sự bùng nổ về số lượng và sự đa dạng của các ứng dụng đã tạo ra 1 tiềm năng và thị trường lớn

Sự phổ biến của các ứng dụng di động đã tiếp tục tăng Theo công ty nghiên cứu thị trường Gartner, 102 tỷ ứng dụng sẽ được tải về trong năm 2013 (91% trong

số đó là miễn phí) nhưng chúng vẫn sẽ tạo ra 26 tỷ USD, tăng 44,4% so với 18 tỷ USD vào năm 2012 Báo cáo phân tích ước tính rằng nền kinh doanh ứng dụng tạo ra doanh thu hơn 10 tỷ cho mỗi năm trong Liên minh châu Âu, trong khi hơn

529.000 công ăn việc làm đã được tạo ra trong 28 quốc gia EU do sự tăng trưởng của thị trường ứng dụng.

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ị Native App, được hiểu nôm na là ứng dụng gốc, hay ứng dụng được viết cho các thiết bị di động, chạy trên từng nền tảng (iOS, Android, RIM-OS, QNX…) khác nhau và tất nhiên là trên các thiết bị khác nhau

để thực hiện một chức năng cụ thể như: danh bạ, lịch, phần mềm nghe nhạc, xem video trên điện thoại/tablet… và đa số các trò chơi trên thiết bị di động đều là ứng dụng gốc Ví dụ cụ thể: Một game Angry bird bạn download trên AppStore tức là chúng phải chỉ chạy trên IOS, nếu bạn cài đặt trên HĐH khác thì nó không thể hiểu được

 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 như: http://m.facebook.com

 POST: Đẩy dữ liệu lên Server

 GET: Nhận dữ liệu từ Server và hiển thị

API phải xác nhận dữ liệu trước khi xử lý trong khi dữ liệu hợp lệ đã được xác nhận ở hầu hết tầng giao diện vì ở tầng giao diện người dùng, thường

Javascript sẽ chặn những dữ liệu không hợp lệ, cho nên khi gửi đến để Server xử

lý, hầu hết đều là dữ liệu hợp lệ Tuy nhiên, nếu dùng thủ thuật, một số dữ liệu không hợp lệ vẫn có thể vượt qua phần kiểm soát của giao diện và khi lưu vào database, sẽ làm sai những ràng buộc, gây nên những lỗi nghiêm trọng cho hệ thống Vì vậy Test API sẽ giúp kiểm tra lại một lần nữa, sàng lọc những dữ liệu không hợp lệ được gửi tới và lọt qua từ tầng giao diện, từ đó sẽ đưa ra thông báo

cụ thể, xử lý các yêu cầu của người dùng để đưa ra kết quả hiển thị cho người dùng xem có đúng như kết quả mong đợi hay không

 Công cụ hỗ trợ:

 SOAPUI

 Runscope

 Posman with jetpacks

 Postman with newman

 Curl

 Advanced rest client

 Phương pháp kiểm thử ứng dụng “ICTU_Social”

 Lựa chọn phương pháp kiểm thử

 Khi phát triển phần mềm, việc thực hiện kiểm thử là bắt buộc, cho dù người thực hiện kiểm thử có thể là developer hoặc là tester Vì thế, có kiến thức về kiểm thử, lựa chọn loại hình kiểm thử phù hợp với sản phẩm là điều cần thiết cho bất cứ người nào tham gia vào quá trình làm sản phẩm Có 2 phương pháp kiểm thử: kiểm thử thủ công và kiểm thử tự động:

 Kiểm thử thủ công là Tester làm mọi thứ bằng tay, từ viết test case đến thực hiện test, mọi thao tác như nhập điều kiện đầu vào, thực hiện một số sự kiện khác như click nút và quan sát kết quả thực tế, sau đó so sánh kết quả thực tế với kết quả mong muốn trong test case, điền kết quả test Mọi thứ hoàn toàn bằng tay

 Kiểm thử tự động: nghĩa là áp dụng một số công việc kiểm thử bằng công cụ, phần mềm hỗ trợ test - test tool - không phải nhất thiết hoàn toàn mọi hoạt động bằng cách tự động hóa Trong quá trình kiểm thử có rất ít hoặc không có

sự tương tác của con người, giúp cho người thực hiện việc kiểm thử phần mềm (tester) không phải lặp đi lặp lại các bước nhàm chán



 So sánh ưu – nhược điểm của phương pháp kiểm thử thủ công và kiểm thử tự động:

- Thích hợp kiểm thử trong trường hợp các test case chỉ phải thực hiện một số ít lần

- Giảm được chi phí ngắn hạn

- Thích hợp với trường hợp phải test nhiều lần cho một case

- Có tính ổng định và tin cậy cao hơn

- Giảm thời gian và công sức

- Giảm chi phí đầu tư dài hạn

Nhược điểm

- Tốn thời gian Đối với mỗi lần phát hành(relase) người kiểm thử vẫn phải thực hiện lại một tập hợp các test case đã chạy dẫn đến sự mệt mỏi và lãng phí

- Mất thời gian tìm hiểu công cụ test tự động và cách tạo các dữ liệu chuẩn bị cho quá trình kiểm thử

- Đối với những tester không hiểu biết về code

sẽ khó khăn trong việc tạo dữ liệu test

- Chi phí đầu tư ban đầu lớn

- Kiểm thử thủ công là không thể thay thế vì người ta không thể tự động hóa mọi thứ

- Nhiều testcase khó mô

tả -> không bao phủ được các trường hợp kiểm thử

Bảng 1.1 So sánh ưu – nhược điểm của các phương pháp

 Kiểm thử thủ công là không thể thay thế vì người ta không thể tự động

hóa mọi thứ Hiện tại hầu như tất cả các tổ chức, công ty phát triển phần mềm đều lựa chọn kiểm thử thủ công cho mọi sản phẩm Ngoài ra, tùy trường hợp cụ thế khác, tùy vào nội dung dự án, kiến thức cũng như kỹ năng của người thực hiện kiểm thử mà áp dụng loại hình kiểm thử cho phù hợp Tuy nhiên theo ý của người viết thì kiểm thử thủ công vẫn là phương pháp kiểm thử không thể thay thế Cho

dù có áp dụng kiểm thử tự động vào giai đoạn nào của dự án thì vẫn cần có người thực hiện kiểm thử thủ công nhằm đảm bảo giảm tối đa những lỗi không thể lường trước trong bất kỳ kịch bản nào

 Kết luận: Từ việc nhận thức được yêu cầu thực tế của ứng dụng và những ưu – nhược điểm của phương pháp kiểm thử thủ công nên em quyết định sử dụng phương pháp kiểm thử thủ công để kiểm thử ứng dụng “ICTU_Social”

 Các phương pháp kiểm thử thủ công dùng trong quá trình kiểm thử ứng dụng “ICTU_Social”

 Kiểm thử giao diện

Để kiểm thử hiệu quả thiết kế và cài đặt giao diện người dùng của một ứng dụng Mobile, chúng ta cần hiểu ý đồ của người thiết kế và ý đồ của người phát triển Với các thông tin đó, chúng ta có thể phát triển nhiều cách kiểm thử hiệu quả hướng đến những vùng trong thiết kế và cài đặt giao diện có khả năng chứa nhiều lỗi nhất

 Khó đọc kiểu chữ nghiêng và có chân

 Hiển thị lộn xộn do sử dụng nhiều kiểu chữ trong một tài liệu

Màu sắc  Khả năng thích hợp của màu nền

 Khả năng thích hợp của màu chữ

 Sử dụng màu lộn xộn

 Chọn lựa màu phụĐường viền (Border)  Hiệu ứng ba chiều trên các nút lệnh có

thể là những gợi ý trực quan hiệu quả đối với người dùng

 Sử dụng hiệu ứng ba chiều trên các phần

tử không tương tác có thể dẫn đến sự khó hiểu

 Sử dụng các nút quay lui thường dẫn tới kết quả không mong đợi

Bảng  Kiểm thử nên thực hiện trên tất cả các

version hệ điều hành theo yêu cầu của khách hàng

Bảng 1.2 Sơ đồ các cấp độ kiểm thử

 Kiểm thử chức năng

Giả thuyết của loại kiểm thử này là tìm lỗi nhằm kiểm tra xem sản phẩm phần mềm có hữu ích với người sử dụng và có thực hiện những gì mà người dùng thực sự mong đợi hay không Kiểm thử chức năng là một nhóm kiểm thử rất rộng Kiểm thử chức năng bao gồm nhiều phương pháp kiểm thử như FAST, TOFT, kiểm thử Forced-error Test-FET,…

 Kiểm thử đơn giản chấp nhận chức năng (FAST) Kiểm thử FAST bao phủ các chức năng theo chiều rộng nhưng không theo chiều sâu Kiểm thử FAST thực thi mức thấp nhất chức năng mỗi lệnh của một chương trình Sự kết hợp các chức năng không được kiểm thử trong phạm vi của kiểm thử FAST

 Kiểm thử chức năng hướng tác vụ (TOFT) kiểm tra xem ứng dụng có thể thực hiện các công việc hữu ích một cách đúng đắn không TOFT là những kiểm thử tích cực nhằm kiểm tra các chức năng của chương trình bằng cách so sánh kết quả của các công việc được thực hiện với tài liệu đặc tả yêu cầu Các kiểm thử TOFT được thực hiện với một danh sách các chức năng trong hệ thống

Để có được danh sách đó thì đặc tả sản phầm cần được phân tích kỹ lưỡng Sản phẩm cũng cần được kiểm tra xem có chức năng nào không được định rõ hoặc hoàn toàn không có trong mục đặc tả hay không

 Kiểm thử lỗi ép buộc (Forced-error Test-FET) cố ý tạo ra những điều kiện lỗi phần mềm Mục tiêu của FET là tìm các điều kiện lỗi không được phát hiện hoặc bị xử lý sai Các điều kiện lỗi cần được xử lý một cách hợp lý nghĩa là ứng dụng phục hồi thành công hay ứng dụng thoát mà không làm hỏng dữ liệu và vẫn có cơ hội lưu giữ công việc đang làm Thường khó thu thập danh sách đầy đủ các điều kiện lỗi Dưới đây là một số cách tạo danh sách điều kiện lỗi:

 Thu thập danh sách các thông điệp lỗi từ các lập trình viên

 Phỏng vấn các lập trình viên

 Khảo sát dữ liệu, chuỗi ký tự trong tệp nguồn

 Thu thập thông tin từ đặc tả

 Sử dụng kinh nghiệm cá nhân

 Sử dụng một ma trận kiểm thử đầu vào hợp lệ/ không hợp lệ

 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 nhiề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

 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ị

 Kiểm tra gián đoạn

 Vì lí do các thiết bị di động có bộ nhớ thấp hơn nhiều so với desktop nên phải đảm bảo rằng khi có cuộc gọi thoại, tin nhắn SMS, cắm sạc, thông báo bộ nhớ thấp trong khi ứng dụng đang chạy không gây ra bất cứ xung đột nào



 CHƯƠNG 2

 QUY TRÌNH KIỂM THỬ ỨNG DỤNG TRÊN MOBILE

 Xác định chiến lược kiểm thử

Trong suốt quá trình lập chiến lược test thì phải có sự ràng buộc, liên quan của các yếu tố, bao gồm sự rủi ro, nguồn lực, giới hạn thời gian, giới hạn chi phí

Chiến lược test tốt sẽ thu hẹp trách nhiệm của tester và các điểm sau:

 Hiểu cấu trúc hệ thống

Chia nhỏ hệ thống thành những lớp riêng rẽ như giao diện người dùng hay cách thức tiếp cận database Hiểu về cấu trúc hệ thống sẽ giúp các kiểm thử viên xác định được chiến lược test cho mỗi lớp hệ thống đó hay sự kết hợp giữa các lớp

đó với nhau Xác định xem có áp dụng GUI testing hay các chương trình test phụ trợ hay áp dụng cả hai Khi đã hiểu cấu trúc hệ thống thì người ta sẽ tìm ra cách thức tốt nhất để test thông qua giao diện người dùng (GUI), chương trình test phụ trợ hay cả hai Hầu hết các nỗ lực test yêu cầu việc test được áp dụng trong cả hai mức độ, ví dụ giao diện người dùng thường chứa mã, các chuẩn mực được sử dụng

và thẩm tra

Khi xác định được chiến lược test, các tester nên ghi nhớ toàn bộ các trường hợp phức tạp, các mức yêu cầu mang tính nghiệp vụ, các loại test phụ trợ nhiều hơn là test giao diện người dùng Sở dĩ như vậy là do ngôn ngữ và công nghệ để làm nên một sản phẩm phần mềm là rất phức tạp Ví dụ: mục đích của ứng dụng là phát triển, tập trung vào giao diện người dùng có khi chiếm tới 75% chức năng của chương trình, còn 25% là test phân lớp Không thể sử dụng 75% thời gian để test phân lớp chưc năng bởi vì chức năng chính cần test là giao diện người dùng

 Lựa chọn kỹ thuật test, công cụ test

Việc thu hẹp các kiểu kỹ thuật test nhằm giúp giảm bớt sự kết hợp và đa

dạng của các dữ liệu đầu vào Các kỹ thuật test rất đa dạng và nó phải được xác định như một phần của chiến dịch test Khi chiến lược test được đưa ra, tester phải xác định các công cụ test được sử dụng, bao gồm test thủ công hay test bằng các công cụ nào? Nếu cần thiết sẽ xây dựng nên một công cụ riêng thay vì phải mua công cụ kiểm thử.

 Tiến hành viết kịch bản và khai thác công cụ test

Người thiết kế test những gì sẽ quyết định phát triển các công cụ test tự động Họ sẽ đưa ra các kiến thức về test thủ công và các loại công cụ test tự động hiện có trên thị trường Nếu các thao tác test không thể thực hiện bằng tay thì tiến hành viết kịch bản và khai thác các công cụ test tự động dựa trên kịch bản đã viết

 Xác định nhân lực và kinh nghiệm yêu cầu, phạm vi test

Căn cứ vào chiến lược test phác thảo sẽ có được yêu cầu về nhân lực và kinh nghiệm của cá nhân đó cần có Nếu như một phần chiến lược test phải sử dụng test công cụ test tự động thì buộc phải có người hiểu về công cụ đó Và điều cần thiết đặt ra là cần có cả những người test về lĩnh vực đặc biệt đó, hay còn hiểu

là tets sâu về nghiệp vụ Nếu nhóm test không có các kỹ năng test tốt thì sẽ gây nguy hiểm và ảnh hưởng tới thành công của dự án

Tester phải hiểu được phạm vi cần test là những gì Trong một vài trường hợp, ví dụ có thể có văn bản xác nhận, trong đó liệt kê tất cả các chức năng được yêu cầu test hay phạm vi test Trong một số trường hợp khác thì tester phải tự xác định phạm vi test, nguồn lực test, lịch test, công cụ test, rủi ro, và các phần không cần test

 Thiết lập những phần, những tiêu chuẩn được loại bỏ, lập lịch test

Việc xác định phạm vi test có liên quan mật thiết tới việc xác định các tiêu chuẩn tồn tại Release criteria chỉ ra rằng công việc test phải được coi như hoàn thành, do đó điều quan trọng là cúng phải được thể hiện dưới hình thức văn bản trước đó

Chiến lược test phải được xác định trước để xác định nỗ lực test Lập lịch

chi tiết cho việc test là rất quan trọng để tránh việc thực hiện chiến lược test không đúng như yêu cầu đặt ra

 Quan tâm tới các giai đoạn test

Các giai đoạn tets khác nhau áp dụng các chiến lược test khác nhau Ví dụ trong suốt giai đoạn test chức năng của chương trình, việc kiểm thử các chức năng xem các chức năng có hoạt động được không Vậy kế hoạch đặt ra chiến lược test

đó áp dụng cho giai đoạn nào của hệ thống Khi xác định thứ tự các phần cần test, nhóm test nên xem xét lại các yêu cầu để đảm bảo rằng phần nào cần được ưu tiên

 Mức độ rủi ro

Sau khi đánh giá rủi ro, yêu cầu test ưu tiên được đưa ra nhằm đảm bảo giảm mức rủi ro cho hệ thống Các khoản mục có độ rủi ro cao có thể là những chức năng nhập mà không cho nhập dữ liệu vào hệ thống

 Tính chất hoạt động

Một số yêu cầu test được sắp xếp theo thứ tự ưu tiên bởi vì chúng được áp dụng cho các chức năng thường xuyên được sử dụng hay những phần kiến thức bị thiếu hụt của người sử dụng cuối cùng

 Nguồn lực sẵn có

Yếu tố đầu tiên trong test Procedure là nguồn lực sẵn có Thiết kế test có sự ràng buộc, bao gồm giới hạn phần cứng và tính đối lập của các yêu cầu của dự án

 Thời gian hoàn thành phần mềm

Thời gian dự án nên dành nhiều hơn cho phía lập trình Một người quản lý test tốt cần hiểu một cách chắc chắn, nhanh nhạy về hệ thống khi thời gian xây dựng hệ thống có giới hạn Chiến lược test phải thích hợp, vừa khớp với thời gian được căn sẵn Nếu có vấn đề cấp thiết thì cần chỉ ran ngay lập tức để điều chỉnh chiến lược test hoặc chấp nhận rủi ro của hệ thống nếu không có thời gian dành cho việc test

 Quy trình thiết kế mới, công nghệ mới

 Giới thiệu về quy trình thiết kế mới, bao gồm các công cụ thiết kế và độ

rủi ro gia tăng.

 Nếu công nghệ mới được thực hiện, rủi ro xảy ra là có thể công nghệ đó không chạy được Nó sẽ hiểu nhầm yêu cầu, hay thực hiện không đúng các yêu cầu, mà cũng có thể các yêu cầu sẽ bị chắp vá

 Sự phức tạp, Mức độ sử dụng thường xuyên của người dùng

Việc phân tích các tài liệu để test phải được thực hiện để xác định chức năng nào là phức tạp nhất và tập trung tìm kiếm lỗi trong chức năng đó và các phần khác chịu ảnh hưởng của lỗi đó như thế nào

Các chức năng thường xuyên được sử dụng luôn tiềm ẩn lỗi (lỗi của hệ thống) và có khả năng rủi ro cao nếu phần này bị lỗi Vì vậy, phần nào người dùng

sử dụng nhiều cần được test kỹ hơn

 Các yêu cầu không test

Các yêu cầu chức năng và phi chức năng nếu không được test (bị bỏ sót) thì rủi ro hệ thống không thành công là rất cao Tuy nhiên, nếu nhóm test kiểm tra, nghiên cứu các yêu cầu này trong giai đoạn nghiên cứu đặc tả yêu cầu của phần mềm, thì những rủi ro này là nhỏ nhất

 Lập kế hoạch kiểm thử(Test Plan)

 Xác định và phân chia hợp lý thời gian, nhân sự, các công cụ

Test Manager hoặc Test Leader sẽ xây dựng kế hoạch ban đầu về kiểm thử Công việc này định nghĩa phạm vi kiểm thử, các chiến lược kiểm thử, nhận dạng các rủi ro và yếu tố bất ngờ, các hoạt động kiểm thử nào là thủ công, kiểm thử nào

là tự động hay cả hai, ước lượng chi phí kiểm thử và xây dựng lịch kiểm thử và nhận dạng môi trường kiểm thử

Kế hoạch kiểm thử cần được xem lại bởi QC(Quality Control) team, Developers, Business Analysis PM (Project Manager) and Customer và được chấp thuận bởi Project Manager và Customer Nó cần được hiệu chỉnh trong suốt chu kỳ kiểm thử để phản ánh các thay đổi nếu cần thiết

Kế hoạch kiểm thử cần phải được xây dựng sớm như có thể có trong mỗi

chu kỳ phát triển phần mềm để: Tập hợp và tổ chức các thông tin kiểm thử cần thiết Cung cấp thông tin về qui trình kiểm thử sẽ xảy ra trong tổ chức kiểm thử, cho mỗi thành viên trong đội kiểm thử có hướng đi đúng Gán các trách nhiệm rõ ràng cụ thể cho mỗi thành viên đội kiểm thử Có lịch biểu làm việc rõ ràng và các thành viên có thể làm việc với nhau tốt Kế hoạch kiểm thử cần chứa các thông tin sau đây :

 Phạm vi/mục tiêu kiểm thử

 Các chiến lược được dùng

 Các tài nguyên phần cứng và phần mềm phục vụ kiểm thử

 Các nhu cầu về nhân viên và huấn luyện nhân viên

 Các tính chất cần được kiểm thử

 Các tính chất không cần kiểm thử

 Các rủi ro & sự cố bất ngờ

 Lịch kiểm thử cụ thể

 Các kênh thông tin liên lạc

 Cấu hình cho từng phần tử như kế hoạch kiểm thử, testcase, thủ tục kiểm thử,

 Môi trường kiểm thử (Test bed)

 Tiêu chí đầu vào và tiêu chí dừng kiểm thử

 Các kết quả phân phối

 Môi trường kiểm thử

Môi trường kiểm thử bao gồm tất cả các yếu tố hỗ trợ việc kiểm thử như dữ liệu test, phần cứng, phần mềm, mạng và các điều kiện khác Chuẩn bị môi trường, nền tảng cho công việc kiểm thử phần mềm, gồm Hệ điều hành (IOS, Android, )sssd

Sự đa dạng các thiết bị di động với màn hình kích cỡ khác nhau và cấu hình phần cứng như bàn phím cứng, bàn phím ảo (màn hình cảm ứng)…Nhiều hãng

thiết bị di động như HTC, Samsung, Apple và Nokia.Nhiều hệ điều hành di động khác nhau như Android, Symbian, Windows, Blackberry và IOS.Các phiên bản khác nhau của hệ điều hành như iOS 5.x, iOS 6.x, BB5.x, BB6.x …Các lần cập nhật thường xuyên của phiên bản - (như android- 4.2, 4.3, 4.4, iOS 5.x, 6.x) - với mỗi lần cập nhật đều cần đảm bảo sao cho không có chức năng ứng dụng bị ảnh hưởng.Thiết bị di động có kích thước màn hình điện thoại nhỏ hơn so với máy tính

để bàn Thiết bị di động có ít bộ nhớ hơn so với máy tính để bàn Thiết bị di động thường sử dụng kết nối mạng 2G, 3G, 4G hoặc WIFI, trong khi đó máy tính để bàn thường sử dụng băng thông rộng hay kết nối quay số.Các công cụ kiểm thử tự động hóa có thể không chạy được trên các ứng dụng di động

Những giới hạn trong thiết bị kiểm thử:

 Giới hạn bộ xử lí CPU(của thiết bị)

 Hạn chế RAM

 Phụ thuộc nguồn

 Thời gian sử dụng pin hạn chế

 Và quan trọng là, hiện nay trong các công ty, thiết bị để kiểm thử rất là khan hiếm

Hình 2.1 Đặc điểm thiết bị kiểm thử

 Những lưu ý khi kiểm thử

Trước khi bắt đầu kiểm thử ứng dụng trên các thiết bị di động, Tester cần biết một số điều để có thể kiểm thử tốt hơn:

 Phân tích các ứng dụng tương tự: Hãy thử phân tích một số ứng dụng

Ví dụ, nếu phải kiểm thử ứng dụng chia sẻ tệp tin trên điện thoại di động, hãy tìm kiếm một số ứng dụng tương tự khác và quan sát tính năng của nó

 Giữ cho các trình giả lập luôn sẵn sàng: đôi khi, chúng ta mất rất nhiều thời gian để mượn hoặc yêu cầu thiết bị di động cho việc kiểm thử Trong trường

hợp này, để tận dụng thời gian bạn có lẽ sẽ muốn kiểm thử một vài trường hợp trên trình giả lập.

 Phân tích các vấn đề liên quan đến thiết bị: Một khi các thiết bị mục tiêu

đã được xác định, bạn hãy tìm hiểu các vấn đề liên quan đến thiết bị đó Điều này

sẽ giúp bạn hiểu rõ vấn đề bạn đang và sẽ gặp phải liên quan đến thiết bị hay ứng dụng

 Sử dụng trình giả lập nhưng không hoàn toàn tin tưởng nó: Bạn có thể cần đến các trình giả lập trong khi kiểm thử, tuy nhiên hay ghi nhớ rằng không được thực hiện 100% test case trên emulator Thêm vào đó, thời gian đáp ứng ở emulator rất khác với thiết bị thực, cho nên bạn có thể sẽ bỏ qua một số lỗi và những lỗi này chính là điểm yếu của các thiết bị thật

 Xác định các tiêu chuẩn về hiệu suất (performance): đối với bất kỳ ứng dụng di động nào, hiệu suất chính là điều lo lắng lớn nhất Hãy đảm bảo là bạn có những tham số hoặc yêu cầu kiểm thử về hiệu suất để bạn có thể dựa vào chúng trong quá trình kiểm thử Bộ nhớ cũng là 1 trong những yếu điểm của các thiết bị

di động, và ứng xử của ứng dụng lệ thuộc vào những điều kiện này Hãy dành cho

nó một sự quan tâm phù hợp

 Những vấn đề cần kiểm tra

 Cài đặt app

 Có cài đặt được app vào máy hay không?

 Xảy ra hiện tượng gì khi đang cài app thì máy hết pin, mất mạng,

 Bộ nhớ máy

 App có chiếm nhiều bộ nhớ của máy

 Cài đặt app khi full bộ nhớ xảy ra trường hợp gì?

 Giao diện

 Giao diện cũng là phần quan trọng của app Để kiểm tra giao diện, chúng ta nên kiểm tra những case thông thường sau: