1. Trang chủ
  2. » Công Nghệ Thông Tin

Kiểm thử ứng dụng trên điện thoại di động và bước đầu nghiên cứu về kiểm thử tự động áp dụng vào kiểm thử ứng dụng ghi âm trên hệ điều hành IOS

122 548 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 122
Dung lượng 2,35 MB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

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à k

Trang 1

ĐẠI HỌC THÁI NGUYÊN TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG

ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC

Chuyên ngành Công nghệ phần mềm

Đề tài:

KIỂM THỬ ỨNG DỤNG TRÊN ĐIỆN THOẠI DI ĐỘNG VÀ BƯỚC ĐẦU NGHIÊN CỨU VỀ KIỂM THỬ TỰ ĐỘNG ÁP DỤNG VÀO KIỂM THỬ ỨNG

DỤNG GHI ÂM TRÊN HỆ ĐIỀU HÀNH IOS

Sinh viên thực hiện : ĐỖ THỊ XUÂN

Trang 2

Lớp : KTPMK10B, hệ chính qui

Giáo viên hướng dẫn : TS NGUYỄN VĂN NÚI

THÁI NGUYÊN, NĂM 2016

LỜI CẢM ƠN

Sau một thời gian tìm hiểu đề tài “Kiểm thử ứng dụng trên điện thoại di động và bước đầu nghiên cứu về kiểm thử tự động áp dụng vào kiểm thử ứng dụng ghi âm trên hệ điều hành IOS”, 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à sự giúp

đỡ từ các anh chị đồng nghiệp tại Công ty TNHH Phần Mềm TOWER Hà Nội

Em xin chân thành cảm ơn giáo viên hướng dẫn: TS Nguyễn Văn Núi –

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 đề tài một cách tốt nhất

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

Trang 3

Trong quá trình thực hiện đề tài chắc chắn còn 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!

Sinh viên

Đỗ Thị Xuân

Trang 4

LỜI CAM ĐOAN

Đề tài của em được thực hiện trên cơ sở những kiến thức đã tích lũy được trong quá trình học tập và làm việc, sự giúp đỡ tận tình của thầy cô, bạn

bè, đồng nghiệp cùng với một số tài liệu quý báu mà em sưu tầm được cũng như kho tàng Internet vô tận

Em xin cam đoan không sao chép từ bất cứ một đồ án tốt nghiệp nào Nếu sai em xin hoàn toàn chịu trách nhiệm trước mọi kỷ luật của nhà trường

đề ra

Sinh viên

Đỗ Thị Xuân

Trang 5

LỜI NÓI ĐẦU

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

Mạng điện thoại di động xuất hiện tại Việt Nam từ đầu những năm 1990

và theo thời gian số lượng các thuê bao cũng như các nhà cung cấp dịch vụ đi động tại Việt Nam ngày càng tăng Do nhu cầu trao đổi thông tin ngày càng tăng và nhu cầu sử dụng sản phẩm công nghệ cao nhiều tính năng, cấu hình cao, chất lượng tốt, kiểu dáng mẫu mã đẹp, phong phú nên nhà cung cấp phải luôn luôn cải thiện, nâng cao những sản phẩm của mình Do đó việc xây dựng các ứng dụng cho điện thoại di động đang là một ngành công nghiệp mới đầy tiềm năng và hứa hẹn nhiều sự phát triển vượt bậc của ngành khoa học kĩ thuật

Cùng với sự phát triển của thị trường điện thoại di động là sự phát triển mạnh mẽ của xu hướng lập trình phần mềm ứng dụng cho các thiết bị di động 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 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 Để 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ử

Trang 6

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 Bên cạnh đó, đứng trước vấn đề đặt ra đối với kiểm thử thủ công: là tester làm mọi công việc hoàn toàn 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 Hiện nay, phần lớn các tổ chức, các công ty phần mềm, hoặc các nhóm làm phần mềm đều thực hiện kiểm thử thủ công là chủ yếu Nhưng đây thực sự là vấn đề khi trong quá trình kiểm thử đòi hỏi người kiểm thử viên phải thực hiện kiểm thử hồi quy rất nhiều lần, nhiều chức năng Từ đó chúng ta đề xuất ra phương pháp kiểm thử tự động 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.

Chính vì vậy em đã chọn đề tài “Kiểm thử ứng dụng trên điện thoại di động và bước đầu nghiên cứu về kiểm thử tự động áp dụng vào kiểm thử ứng dụng ghi âm trên hệ điều hành IOS” với mục đích nghiên cứu, tìm hiểu

về kiểm thử ứng dụng và bước đầu nghiên cứu về kiểm thử tự động để 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

Trang 8

DANH MỤC HÌNH ẢNH

Hình 1 1: System Preferences 10

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

Hình 2 2 Cập nhật phiên bản mới trên điện thoại di động 27

Hình 2 3: Cách viết kịch bản kiểm thử 34

Hình 2 4 : Giao diện XCode 39

Hình 2 5: Automation trong Xcode 40

Hình 2 6: Sử dụng Instrument kiểm thử ứng dụng trên Mobile 40

Hình 2 7: Khởi động Instrument41

Hình 2 8: Giao diện Instrument 42

Hình 2 9: Tạo một kịch bản mới sử dụng Automation profiling template42Hình 2 10: Tùy chọn kịch bản 43

Hình 2 11: Tạo một kịch bản mới 44

Hình 2 12: Thay đổi tên của kịch bản 44

Hình 2 13: Vùng soạn thảo kịch bản mong muốn 44

Hình 3 4: Màn hình Ghi âm (Recording) 53

Hình 3 5: Màn hình hiển thị danh sách file ghi âm (Voice Memos) 54

Trang 9

Hình 3 6: Màn hình xem file ghi âm (Play) 55

Hình 3 10: File thiết kế màn hình ghi âm 65

Hình 3 11: Fail: Lỗi hiển thị dung lượng file ghi âm sai khi dung lượng vượt quá 1024Kb 66

Hình 3 12: File thiết kế màn hình Passcode 67

Hình 3 13: Fail: Xuất hiện lựa chọn trong mà hình Passcode 68

Hình 3 14: File thiết kế màn hình SettingỨng dụng: 69

Hình 3 15: Fail: Lỗi giao diện khi thiết lập passcode thành công 70

Hình 3 16: Báo cáo tổng thể 71

Trang 10

CHƯƠNG 1: CƠ SỞ LÝ THUYẾT

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

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

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)

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

Trang 11

hữu của hệ điều hành di động, như Apple App Store, Google Play, Windows Phone Store, và BlackBerry App World

 XCODE

 XCODE là gì?

Xcode là một Integrated Development Environment (viết tắt là IDE) tức

là một môi trường tích hợp bao gồm nhiều công cụ khác nhau như chương trình viết mã lệnh hay code editor, chương trình sửa lỗi hay debugger, chương trình mô phỏng ứng dụng khi chạy thực tế hay simulator do hãng Apple cung cấp cho những nhà phát triển lập trình trên hệ điều hành Mac OS X

 Cài đặt:

Đầu tiên sẽ download Xcode từ trên App Store Nếu chưa tìm được App Store, ở góc trên bên trái màn hình, nhấn vào biểu tượng Apple -> System Preferences

Trang 12

Hình 1 1: System Preferences

Chọn biểu tượng Keyboard

Trang 13

Hình 1 2: Biểu tượng Keyboard

Ở đây, chọn Tab Shortcuts ở phía trên và chọn mục Spotlight bên

trái

Trang 14

Hình 1 3: Tab Shortcuts chọn Spotlight

Spotlight là một tiện ích mà hệ điều hành Mac OS X cung cấp giúp tìm nhanh các file, folder, ảnh, -> Search App Store -> Sauk hi cửa sổ App Store

mở lên -> Tìm kiếm Xcode

Trang 15

 Khởi động Instruments:

 Mở Xcode

Trang 16

 Chọn Xcode > Open Developer Tool > Instruments

Hình 1.5: Khởi động công cụ Instruments

Hiển thị màn hình Instruments

Trang 17

Hình 1 6: Màn hình công cụ Instruments

 Công cụ Automation Instruments :

 Với Instruments, được tích hợp sẵn trong Xcode từ phiên bản 3.0 trở

đi, ta có thể tương tác với UI của ứng dụng (do cá nhân hoặc tổ chức của ta phát triển – đồng nghĩa với việc cần có certificate và provisioning của thiết bị

sử dụng để test) Khi sử dụng test tự động, đội ngũ của chúng ta sẽ có thời gian để làm những việc khác Tuy nhiên ta sẽ phải dành chút thời gian để viết script cho test case của ứng dụng trước đã

 Ta có thể sử dụng tính năng Automation trong Instruments để tự động tương tác với UI trong ứng dụng thông qua những đoạn script đã viết (Đồng nghĩa với việc 1 test case chỉ phải viết script 1 lần nhưng được sử dụng để test

Trang 18

nhiều lần ngay khi phát triển ứng dụng hay những bản nâng cấp sau) Những đoạn script này sẽ được chạy bên ngoài ứng dụng (đang cần test) và mô phỏng những tương tác của người dùng đối với ứng dụng bằng cách sử dụng

UI Automation API (một tập các Java Script API), đồng thời chúng sẽ ghi lại log của quá trình tương tác lên trên máy tính

 Ngoài ra ta có thể tích hợp Automation với những tính năng khác của Instruments để thực hiện những test case phức tạp hay kiểm tra rò rỉ bộ nhớ (Memory leaking) trong quá trình chạy ứng dụng

 Kỹ thuật kiểm thử kiểm thử phần mềm

 Kỹ thuật kiểm thử hộp đen (Black box)

Còn gọi là kiểm thử chức năng Việc kiểm thử này được thực hiện mà không cần quan tâm đến các thiết kế và viết mã của chương trình Kiểm thử theo cách này chỉ quan tâm đến chức năng đã đề ra của chương trình Vì vậy kiểm thử loại này chỉ dựa vào bản mô tả chức năng của chương trình, xem chương trình có thực sự cung cấp đúng chức năng đã mô tả trong bản chức năng hay không mà thôi

Kiểm thử hộp đen dựa vào các định nghĩa về chức năng của chương trình Các trường hợp kiểm thử (test case) sẽ được tạo ra dựa nhiều vào bản

mô tả chức năng chứ không phải dựa vào cấu trúc của chương trình

Kiểm thử hộp đen về bản chất không phải là một phương pháp trái ngược với kiểm thử hộp trắng Đúng hơn đây là phương pháp bổ xung cho phương pháp kiểm thử hộp trắng để phát hiện ra tất cả các loại lỗi khác nhau nhiều hơn là phương pháp kiểm thử hộp trắng đã biết

Trang 19

 Kỹ thuật kiểm thử hộp trắng (White box)

Còn gọi là kiểm thử cấu trúc Kiểm thử theo cách này là loại kiểm thử sử dụng các thông tin về cấu trúc bên trong của ứng dụng Việc kiểm thử này dựa vào quá trình thực hiện xây dựng phần mềm

Tiêu chuẩn của kiểm thử hộp trắng phải đáp ứng các yêu cầu như sau:

 Bao phủ dòng lệnh: mỗi dòng lệnh ít nhất phải được thực thi một lần

 Bao phủ nhánh: mỗi nhánh trong sơ đồ điều khiển (control graph) phải được đi qua một lần

 Bao phủ đường: tất cả các đường (path) từ điểm khởi tạo đến điểm cuối cùng trong sơ đồ dòng lệnh phải được đi qua

 Kỹ thuật kiểm thử hộp xám (Gray box)

Kiểm thử hộp xám kết hợp kiểm thử hộp đen và kiểm thử hộp trắng Kỹ thuật này xem xét tác động người dùng cuối, kiến thức kỹ thuật của hệ thống

cụ thể và môi trường vận hành Kỹ thuật này đánh giá thiết kế ứng dụng trong ngữ cảnh tương tác giữa các thành phần của hệ thống Kỹ thuật kiểm thử hộp xám là cần thiết nhằm kiểm thử hiệu quả các ứng dụng bởi vì các ứng dụng thường bao gồm nhiều thành phần Các thành phần này phải được kiểm thử trong ngữ cảnh thiết kế hệ thống để đánh giá tính năng và khả năng tương thích của chúng

Kiểm thử hộp xám rất thích hợp trong việc kiểm thử các ứng dụng Bởi vì kiểm thử hộp xám tính đến mức thiết kế cao, môi trường và điều kiện vận hành Kiểm thử hộp xám phát hiện ra các vấn đề không được xem xét bởi

Trang 20

kiểm thử hộp đen hoặc kiểm thử hộp trắng.

 Ưu điểm của kiểm thử tự động là gi?

 Cải thiện hiệu quả: Nâng cao hiệu quả khi cần kiểm tra hồi quy hay phải hao phí về mặt thời gian thì kiểm thử tự động mang lại hiệu quả rõ rệt( có thể thực hiện kiểm thử ngay cả khi không có người bất kể ngày hay đêm)

 Cải thiện độ chính xác: Khi dùng kiểm thử tự động, dù có lặp đi lặp lại bao nhiêu lần thì cũng cho ra các thao tác và kết quả giống nhau Do đó tránh được những rủi ro không cần thiết Ngoài ra, nếu một lỗi được tìm thấy, nó có thể được tái tạo bằng cách đơn giản là thực hiện cùng một kịch bản tự động, dẫn đến cải thiện khả năng tái lỗi Kiểm thư tự động còn có tính năng các thao tác test được lưu lại tự động, dễ dàng kiểm tra và cưỡng chế lỗi trong thời gian kiểm thử

 Cải thiện chất lượng: Đối với test tự động có thể nâng cao được hiệu quả của việc kiểm tra, tổng số trường hợp kiểm tra chắc chắn được tăng lên

 Nhược điểm của kiểm thử tự động:

Trang 21

 Các công cụ kiểm thử tự động mặc dù rất thuận tiện về nhiều phương diện nhưng thực tế dù như thế nào đi chăng nữa thì nó cũng không phải là một công cụ

có thể thay thế hoàn toàn quá trình kiểm thử Để thực hiện các thiếp lập tự động thì vẫn cần có con người, phải bỏ công sức, tiền bạc và thời gian

 Mất thời gian và công sức để tạo mới và chỉnh sửa script test

 Mất chi phí cho các công cụ tự động hóa như phí bản quyền, bảo trì, tìm hiểu, giáo dục

 Trường hợp nào nên và không nên áp dụng kiểm thử tự động?

 Nên :

 Những kiểm tra cần thực hiện nhiều lần

 Thực hiện kiểm tra ở nhiều môi trường

 Đặc điểm kĩ thuật được xác định, test màn hình chức năng không thay đổi trong tương lai

 Thường xuyên thực hiện test xác nhận hoạt động cơ bản( chẳng hạn như

di chuyển hệ thống)

 Test sự kết hợp của nhiều giá trị đầu vào ở một bước nào đó

 Kiểm tra nhiều màn hình của dữ liệu đầu vào

 Mục đầu vào ở nhiều màn hình đăng kí

 Không thích hợp cho tự động hóa( Không mang lại hiệu quả):

 Kiểm tra không có tính hồi quy

 Kiểm tra những hoạt động như test độ tin cây, giới hạn, cạnh tranh…

 Kết luận: Việc thực hiện tự động không phải là ứng dụng cho tất cả các

trường hợp test Không thể tự động hóa cho tất cả các trường hợp thử nghiệm Với nhiều trường hợp test không yêu cầu hồi quy, đặc điểm kĩ thuật luôn thay đổi thì tự động hóa không mang lại chút hiệu quả nào

 Quản trị dự án bằng JIRA

Trang 22

1.6.1 Tổng quan về quản trị dự án bằng Jira

Trong quá trình thực hiện một dự án, chúng ta có thể bắt gặp nhiều vấn

đề khác nhau Jira cung cấp một giải pháp tuyệt vời giúp cho việc quản lý thành viên được dễ dàng cũng như cho phép các thành viên theo dõi hoạt động của mình

 JIRA là gì?

Hình 1.7: Quản trị dự án bằng Jira

JIRA là một công cụ để theo dõi lỗi/ quản lý dự án (defect tracking/ project management) và được phát triển bởi công ty Atlassian , Inc Nó là một nền tảng độc lập

 JIRA giành cho ai?

 Đội phát triển dự án phần mềm (Software project development teams) Vd: QA

 Hệ thống chăm sóc, hỗ trợ khách hàng (Help desk system)

1.6.2 Các tính năng chính

Trang 23

 Quản lý lỗi, tính năng, công việc, những cải tiến hoặc bất kỳ vấn đề gì

 Giao diện người sử dụng mạnh mẽ và rõ ràng giúp sử dụng dễ dàng cho

cả người dùng là kỹ thuật hay nghiệp vụ

 Tương thích những quy trình nghiệp vụ theo các luồng công việc (workflow) thông thường

 Theo dõi các tệp gán, những thay đổi, các cấu phần và các phiên bản

 Tìm kiếm toàn văn và công cụ lọc mạnh mẽ (có thể tùy biến, lưu và ký xác nhận)

 Bảng phân tích đồ họa có thể tùy biến và các số liệu thống kê thời gian thực

 Cấp phép và bảo mật

 Dễ dàng mở rộng và tích hợp với các hệ thống khác (như email, RSS, Excel, XML và quản lý nguồn)

 Những tùy chọn nhắc việc có thể cấu hình một cách dễ dàng

 Có thể chạy trên hầu hết các nền tảng phần cứng, hệ điều hành và cơ sở

dữ liệu

 Dịch vụ Web cho phép kiểm soát hệ thống (SOAP, XML-RPC và giao diện REST)

 Cách tạo một vấn đề trong Jira

 Form tạo Issue

Trang 24

Click vào nút “Create Issue ”.

Hình 1 8 Tạo Issue trong Jira

 Giải thích các trường trong form:

Project: Tất cả các issue đều thuộc về một dự án Bạn có thể chọn cùng bằng cách click vào trình đơn thả xuống (drop down) và chọn các dự án mà vấn đề này thuộc về

Issue type: hiển thị tất cả các kiểu của issue rằng nó có thể được tạo và

Trang 25

theo dõi thông qua JIRA Lựa chọn sau đây là có sẵn trong danh sách này (danh sách này có thể khác nhau phụ thuộc vào các thiết lập được cài đặt bởi người quản trị)

Summary: Ghi lại tiêu đề lỗi của bạn ở đây Khi được sử dụng đúng,

trường này có thể rất thành công trong việc truyền tải những thông tin quan trọng

Priority: Trường này có thể mang một trong các giá trị

Component: Danh sách này sẽ hiển thị các thành phần của dự án Và bạn

sẽ chọn một thành phần thích hợp

Affected Version and Fix version: Đây là 2 trường sẽ hiển thị phiên bản

hiệu lực cho của dự án Nó không phải là cần thiết mà một vấn đề nào đó mà bạn gặp phải trong phiên bản này được sửa chữa trong cùng một phiên bản

Assignee: có thể điền tên của người mà vấn đề này cần được bàn giao

Bạn đồng thời cũng có thể chỉ định (assign) một vấn đề nào đó cho chính mình

Description: Đây là một trường text tùy chọn nhằm hỗ trợ bạn nhập

nhiều thông tin như bạn muốn về vấn đề của bạn Trong trường hợp của một lỗi, đó là điển hình của việc sử dụng trường này để cung cấp thông tin chi tiết

về các bước nhằm tái hiện lại khiếm khuyết/ lỗi đó

Attachtment: Bất cứ tài liệu hỗ trợ nào mà có thể được tải lên cùng với

những vấn đề (issue)

 Ưu và nhược điểm khi sử dụng Jira

Trang 26

 Ưu điểm:

 Quản lý tổng thể dự án

 Quản lý được thời gian, nhân sự

 Có nhiều CSDL hỗ trợ như: MySQL, Postgre SQL, SQLite

 Là ứng dụng đa ngôn ngữ, có sắn 30 ngôn ngữ

 Cung cấp cho người sử dụng với biểu đồ Gantt, lịch, tính năng theo dõi thời gian

 Nhược điểm:

 Tính tương thích của plugin chưa cao, cài đặt chưa dễ dàng

 Chi phí cao



Trang 27

CHƯƠNG 2: KĨ THUẬT KIỂM THỬ CÁC ỨNG DỤNG MOBILE

 Tổng quan về kiểm thử ứng dụng trên điện thoại di động

Bao gồm các hoạt động đặc biệt phải được thực hiện để đạt được các mục tiêu đặt ra Nhiều yếu tố phải được quan tâm khi đưa ra chiến lược test 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

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

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

Trang 28

dạng của các dữ liệu đầu vào 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?

 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 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à test 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ư

Trang 29

hoàn thành, do đó điều quan trọng là chú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 test 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ó

Trang 30

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ỉ cần 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

Trang 31

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

 Đặc điểm thiết bị kiểm thử

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

Trang 32

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

Trang 33

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

Trang 34

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

 Kiểm tra màn hình dọc và ngang

 Kiểm tra các hành động , Zoom In/Out (tất cả các hành động)

 Kiểm tra giao diện không bị cắt

 Kiểm tra xem các đối tượng có bị đè lên nhau không

 Kiểm tra biểu tượng loading xuất hiện nơi cần thiết

 Nhân vật không nên di chuyển ra khỏi màn hình/ khu vực nhất định

 Kiểm tra kích hoạt hoặc vô hiệu hóa các hình ảnh/ biểu tượng và nút

 Kiểm tra tiêu đề màn hình

 Kiểm tra tiêu đề của tin nhắn , mô tả thông báo, nhãn (tiêu đề của

Trang 35

textbox) có phù hợp không

 Kiểm tra vị trí focus có được đặt ngay field đầu tiên hay control đầu tiên khi load màn hình hay không?

 Font chữ hiển thị (màu sắc, kích thước …)

 Các hiệu ứng scroll, chuyển trang có smooth

 Các dữ liệu có được lưu khi đóng cửa sổ,

 Chức năng

 Đảm bảo các chức năng có trong thiết kế hoạt động tốt

 Test những chức năng ngoài luồng

 Click , swipe , touch , scroll nhanh có gây ra lỗi

 Sự chuyển hướng từ các liên kết trong ứng dụng hoặc các Social link ( g+, facebook, )

 Lấy dữ liệu từ server khi ở chế độ background running, khóa màn hình hay listen

 Kiểm tra sự đồng bộ dữ liệu khi đăng nhập ở nhiều thiết bị ( desktop, tablet, mobile)

 Test camera nếu có trong ứng dụng, ( chụp ảnh, lưu trữ )

 Nội dung, hình ảnh có hiển thị tốt khi chia sẻ trên G+, facebook ., điện thoại có cài ứng dụng facebook, G+ và không cài các ứng dụng

Trang 36

 Notification từ ứng dụng như update, nhắc nhở

 On/Off âm thanh có xảy ra lỗi

 Thời gian trên app, server, …

 Thay đổi thời gian trên Device

 Ngắt mạng đột ngột khi đang sử dụng app

 Xoay màn hình khi đang sử dụng app

 Kiểm tra chế độ rung của app nếu có

 Sử dụng app lâu có gây nóng máy

 Có các hành động khác xen vào khi đang sử dụng app: gọi điện, nhắn tin, báo thức…

 Chú ý kiểm thử cho các trường hợp System Crash / Force Close

 Cập nhật phiên bản mới

 Có update được phiên bản mới khi đang sử dụng app

 Có bị mất dữ liệu khi update lên phiên bản mới

Trang 37

Hình 2 2 Cập nhật phiên bản mới trên điện thoại di động

 Các giai đoạn kiểm thử

 Kiểm thử đơn vị (Unit Test): nhóm phát triển có trách nhiệm thực hiện trước khi bàn giao chương trình cho nhóm kiểm thử

 Kiểm thử chức năng (Functional Test), kiểm thử phi chức năng: nhóm kiểm thử có trách nhiệm thực hiện

 Kiểm thử tích hợp (Integration Test): áp dụng thử nghiệm với các dự

án CMMI Điều kiện thực hiện kiểm thử tích hợp là phải có báo cáo kiểm thử chức năng với kết luận đạt tiêu chuẩn để tích hợp

Trang 38

 Kiểu kiểm thử nghiệm thu (Acceptance Test): sẽ được thực hiện bởi phía khách hàng

 Các kỹ thuật kiểm thử ứng dụng trên điện thoại di động

2.3.1 Kiểm thử giao diện người dùng

Kiểm thử giao diện người sử dụng (UI) kiểm tra các tương tác của người dùng với phần mềm Mục tiêu của kiểm thử UI là để đảm bảo rằng giao diện người dùng cung cấp cho người sử dụng cách truy cập và sử dụng thích hợp thông qua các chức năng trong mục tiêu kiểm thử Ngoài

ra, kiểm thử UI còn để đảm bảo rằng các đối tượng trong phạm vi chức năng UI giống như mong đợi và phù hợp với tổ chức hoặc chuẩn ngành

Mục đích kiểm thử: Kiểm tra:

Việc sử dụng thông qua mục tiêu kiểm thử phản ánh đúng các chức năng và yêu cầu nghiệp vụ, bao gồm màn hình đến màn hình, trường đến trường và sử dụng các phương pháp truy cập (phím tabs, di chuột, tổ hợp phím)

Các đối tượng và thuộc tính màn hình như menus, size, position, state, và tập trung vào việc tương thích với chuẩn Cách thực hiện: Tạo ra và chỉnh sửa kịch bản kiểm thử cho mỗi màn hình để

kiểm tra việc sử dụng đúng cách và tình trạng các đối tượng cho mỗi màn hình và đối tượng của ứng dụng

Điều kiện hoàn

thành:

Mỗi màn hình được kiểm tra thành công đúng với phiên bản kiểm tra hoặc phạm vi chấp nhận được

Trang 39

Các vấn đề đặc biệt: Không phải toàn bộ các thuộc tính của các đối tượng đều truy

cập được

Bảng 2.1: Kiểm thử giao diện người dùng

 Kỹ thuật:

Test case giao diện gồm hai phần chính

Test case giao diện chung: hiển thị màn hình ở trạng thái khởi tạo, kiểm tra tab, shift+ tab order, phóng to thu nhỏ màn hình không bị vỡ giao diện, chính tả

Test case kiểm tra validate cho từng control riêng rẽ trên màn hình: viết cho từng control một Khi viết test case cho các control, cán bộ kiểm thử sẽ viết hết test case kiểm tra định dạng cho control này rồi mới chuyển sang test case cho control tiếp theo thứ tự từ trái sang phải, từ trên xuống dưới

Ví dụ: Màn hình có 2 control: 1 text box, 1 combo box -> có thể viết test case như sau:

Mã test

case

Mục đích kiểm thử Các bước thực hiện Kết quả mong

muốnTest case cho textbox A

TC_1 Kiểm tra max length Nhập quá độ dài

cho phép của text box

Không cho phép

Trang 40

TC_2 Kiểm tra auto Trim Nhập vào dấu cách

vào đầu và cuối giá trị của text box, lưu vào CSDL

Kiểm tra trong CSDL, các space ở đầu và cuối được cắt đi khi lưu vào CSDL

Test case cho combo box B

TC_4 Kiểm tra căn lề Kích vào combo

box để kiểm tra căn

lề của các giá trị trong combo box

Các giá trị trong combo box được căn lề trái

Bảng 2.2: Test case kiểm thử giao diện người dùng

2.3.2 Kiểm thử chức năng

Test case cho phần chức năng gồm test case cho các nội dung sau:

 Kiểm tra giá trị trong Combo (các giá trị hardcode hoặc có sự truy vấn

dữ liệu trong cơ sở dữ liệu để kiểm tra)

 Kiểm tra ràng buộc giữa các control (có sự truy vấn dữ liệu trong cơ sở

dữ liệu để kiểm tra)

 Kiểm tra các màn hình trung gian để thực hiện chức năng chính: ví dụ

để thực hiện chức năng phải có màn hình popup

 Hạn chế:

 Trong cơ sở dữ liệu (không rỗng, không trùng, …)

Ngày đăng: 23/04/2017, 10:30

TỪ KHÓA LIÊN QUAN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

🧩 Sản phẩm bạn có thể quan tâm

w