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 2Lớ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 3Trong 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 4LỜ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 5LỜ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 6phầ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 8DANH 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 9Hì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 10CHƯƠ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 11hữ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 12Hình 1 1: System Preferences
Chọn biểu tượng Keyboard
Trang 13Hì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 17Hì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 18nhiề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 20kiể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 221.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 24Click 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 25theo 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 27CHƯƠ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 28dạ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 29hoà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 30sự 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 33cầ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 35textbox) 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 37Hì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 39Cá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 40TC_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, …)