+3

Khái quát về kiểm thử trên SmartPhone - Android

I> Giới thiệu

1.Giới thiệu

Với sự phát triển nhanh chóng của Internet cộng với trào lưu mạng xã hội bùng nổ điện thoại thông minh đang ngày càng được sử dụng nhiều nhằm đáp ứng nhu cầu giải trí đa dạng của người dùng. Từ một chiếc điện thoại thông thường chỉ được cài đặt sẵn vài ba ứng dụng của nhà sản xuất thì nay với các thiết bị chạy các hệ điều hành nhúng (Android, iOS,...) ta có thể dễ dàng đáp ứng được các nhu cầu của người dùng bằng cách cài thêm các phần mềm bên thứ ba mà không gây ra trở ngại nào.

Từ đây lại đặt ra một vấn đề hiển nhiên là kiểm thử các phần mềm chạy trên di động này để xem chúng có đáp ứng được các yêu cầu đề ra ban đầu hay không trước khi phân phát sản phẩm tới tay người tiêu dùng. Thực hiện đúng các điều kiện cơ bản sau sẽ làm giảm khả năng kiểm thử phần mềm trên mobile bị sai.

Ví dụ chọn đúng thiết bị cần kiểm thử, vì mỗi thiết bị đều có những tính năng đặc thù riêng ví dụ như iOS thì chỉ có năm mẫu có màn hình kích thước khác nhau là iPad (9.7 inches), iPad Mini (7.9 inches) , iPhone 4S (3.5 inches) và iPhone 5 (4.0 inches) trong khi Android thì có tới hơn 10 nhà sản xuất phần cứng với hàng trăm mẫu màn hình kích thước khác nhau. Nắm bắt được các kiến thức cơ bản của môi trường lập trình SDK để từ đó ta có thể tạo được các Emulator phù hợp để kiểm thử.

2. Các yếu tố ảnh hưởng đến hoạt động của phần mềm trên SmartPhone

  • Tuổi thọ của Pin: Bình thường một chiếc điện thoại có thời lượng Pin đủ dùng trong nhiều ngày nhưng với những chiếc điện thoại smartphone do sử dụng rất nhiều dịch vụ giải trí như kết nối mạng, nghe nhạc, xem phim,...nên thời lượng pin bị rút ngắn đi rất nhiều nên cần phải nạp điện thường xuyên hơn.

  • Kết nối mạng: các ứng dụng luôn luôn tiêu thụ tài nguyên khi chúng kết nối mạng. Bản chất của di động là vị trí luôn luôn thay đổi vì vậy người dùng có thể tắt kết nối mạng của thiết bị đi trong một vài giờ. Vì vậy ta phải thiết một ứng dụng có khả năng hoạt động ngay cả khi không có mạng (offline) chẳng hạn như gửi email hay viết tin nhắn và ngay khi mạng được kết nối tới thì ứng dụng có khả năng gửi hàng loạt email và tin nhắn mà người dùng đã soạn thảo trước đó một cách tự động.

  • Sự khác nhau giữa các thiết bị và phần mềm cài trên từng thiết bị này, bao gồm kích cỡ màn hình, chipset, bộ nhớ,...Lí tưởng nhất nếu phần mềm có thể hoạt động trên mọi thiết bị phần cứng và nền tảng khác nhau.

  • Giới hạn về tài nguyên: hầu hết các thiết bị di động đều có tìa nguyên hạn chế như tốc độ xử lí của CPU, không gian lưu trữ,...vì vậy vấn đề tiết kiệm tài nguyên hệ thống của các ứng dụng cũng rất cần được xem trọng.

3.Lựa chọn thiết bị SmartPhone để Testing

Vì các đội kiểm thử không ai có đầy đủ mọi mẫu điện thoại cần thiết nên trên mỗi nền tảng ta có thể chọn ra các thiết bị di động tiêu biểu để tiến hành kiểm thử như:

  • Các thiết bị phổ biến bao gồm iPhone 4S của Apple, Nokia N73.

  • Với Android thì có thể lựa chọn Samsung Galaxy Nexus chạy android 4.0

  • Với các thiết bị ít phổ biến hơn ta có thể chọn Sony Erission LiveView.

4. Kiểm thử tự động

a) Unit test: được khuyến nghị nên sử dụng cho các đơn vị mã nhỏ. Một đơn vị mã có thể có một vài phương thức riêng lẻ hay phương thức quan hệ trong một file chương trình. Unit test chỉ test một phần nhỏ của chương trình để xem chúng hoạt động có đúng không

Report_thang9_1.jpg

					Hình 4.3. Kiểm thử tích hợp

Với các ứng dụng mobile, một vài nền tảng chính có và mở rộng các unit testting framework được tạo và chạy như một phần của quy trình phát triển phần mềm.

b) Kiểm thử tích hợp: khi các Unit test đã được kiểm thử thành công thì tích hợp test giúp ta kiểm thử được cả ứng dụng khi kết hợp các module vào với nhau. Như đã đề cập ở bên trên thì kiểm thử đơn vị đã đủ linh hoạt để thay thế các loại hình kiểm thử khác, bao gồm cả kiểm thử tích hợp. Bởi vì kiểm thử tích hợp sẽ cần nhiều mã hơn nên sẽ mất nhiều thời gian, nhất là đối với các thiết bị di động tài nguyên luôn hạn hẹp. Để khắc phục ta có thể chạy các công việc tốn thời gian một cách bất đồng bộ và chỉ thực hiện kiểm thử tích họp khi kiểm thử đơn vị đã thành công.

c) Kiểm thử Activity: Activity là khái niệm đồng nhất và cũng là thành phần quan trọng nhất trong ứng dụng Android. Một Activity là một thành phần rời rạc và liên kết chia sẻ dữ liệu với các thành phần khác trong Android thông qua giao diện form và các luồng chạy ngầm. Android SDK cũng bao gồm các framework cho phép ta kiểm thử tự động các Activity.

d) Kiểm thử hệ thống, ứng dụng Kiểm thử hệ thống là kiểm thử toàn bộ ứng dụng. Một vài nền tảng platform có thể bao gồm cả việc test cả chương trình nhỏ chạy ngầm bên dưới. Có một số phần mềm test tự động mà có thể sinh ra các tác tử (Agent) chạy ngầm trên mobile để tạo ra các test script kiểm thử một cách tự động. Các tác tử này có một vài dạng như chạy trên thiết bị và cho phép chúng tương tác với ứng dụng hay chạy trên các ứng dụng riêng lẻ.

e) Kiểm thử thông qua giao diện chỉ được hỗ trợ trong các SDK của android và iOS. Kiểm thử giao diện được cung cấp sẵn trên iOS và Monkeyrunner là cong cụ kiểm thử thông qua giao diện mới nhất trên Android.

II> Android Testing Framework

Nền tảng Android cung cấp một framework rất tiện dụng mở rộng từ JUnit framework chuẩn với nhiều tính năng phù hợp với các chiến lược kiểm thử. Những tính năng này bao gồm:

  • Bổ sung các class Android mở rộng từ JUnit framework cho phép truy cập vào các đối tượng hệ thống trong Android.

  • Instrumentation framework cho phép kiểm soát và kiểm tra ứng dụng.

  • Các đối tượng giả lập (Mock) được sử dụng phổ biến trong hệ thống Android.

  • Các công cụ cho phép thực hiện các test riêng lẻ hay chạy cả một dãy các lệnh test mà có thể không cần đến Instrumentation framework (IF).

  • Hỗ trợ quản lí test và các peoject test trong ADT plugin của Eclipse và cả chế độ dòng lệnh command line của hệ điều hành.

1. Instrumentation framework (viết tắt là IF)

Instrumentation framework là một phần cơ bản của testing framework. IF điều khiển ứng dụng kiểm thử và cho phép gắn các đối tượng thay thế giả lập (Mock object) vào ứng dụng để chạy. Ví dụ ta có thể tạo một đối tượng giả lập Context trước khi ứng dụng bắt đầu và cho phép ứng dụng sử dụng nó. Tất cả mọi tương tác giữa ứng dụng và môi trường xung quanh có thể sử dụng phương pháp tiếp cận này. Ta cũng có thể tách riêng ứng dụng của chúng ta trong một môi trường giới hạn để lấy về kết quả, hoặc các dữ liệu được lưu trữ và không thay đổi như ContentProvider, cơ sở dữ liệu hay thậm chí là hệ thống file.

Một project Android thường có một project Test tương ứng với tên kết thúc bằng Test. Bên trong một Test project file AndroidManifest.xml khai báo thẻ cho biết IF là <instrumentation></ instrumentation>. Ví dụ: giả sử project Android có file manifest có dạng sau:

Report_thang9_2.jpg

Thì trong test project file này sẽ có dạng tương ứng là :

Report_thang9_3.jpg

Nhìn ví dụ này ta có thể thấy ngay rằng trong thẻ khai báo IF là <instrumentation> với thuộc tính name là trình chạy kiểm thử test runner, class mặc định của Android testing API (android.test.runner), ta cũng có thể tùy biến class này bằng cách kế thừa từ class InstrumentationTestRunner, thuộc tính targetPackage chỉ ra package của ứng dụng mà ta muốn kiểm thử (trong ví dụ là AddressContacts).

2. Kiến trúc Testing framework

Report_thang9_4.jpg

Trong kiến trúc này InstrumentationTestRunner làm nhiệm vụ trung gian trong việc chạy các testcase. Các thành phần chính trong kiến trúc này:

  • Application package: chứa toàn bộ ứng dụng để test

  • Test projects: chứa các mã nguồn, file manifest và những file khác dùng để kiểm thử ứng dụng. Ta có thể sử dụng Eclipse để tạo ra test project này.

  • Testing API

  • Junit: ta có thể sử dụng các class Junit testcase để kiểm thử đơn vị trên các class.

  • Instrumentation: Android Instrumentation là một tập các phương thức điều khiển trong hệ thống Andoird. Các điều khiển này độc lập với vòng đời của ứng dụng và chúng cũng kiểm soát cách Android tải ứng dụng để chạy. Thông thường Android framework không cung cấp cách để gọi trực tiếp các hàm callback trong vòng đời của một ứng dụng như onCreate(), onResume(),... nhưng với instrumentation ta có thể gọi các hàm này thông qua các phương thức như getActivity(), activity.finish(),...

  • Test case classes: Android cung cấp một vài class kế thừa từ class TestCase và Assert của Junit framework như ApplicationTestCase, InstrumentationTestCase,...

  • Mock Object: để chống sự phụ thuộc (dependency injection) trong kiểm thử, Adroid cung cấp các class để tạo các đối tượng hệ thống giả lập như MockContext, MockContentProvider,...

  • MonkeyRunner: một API để thực thi trong môi trường với ngôn ngữ là Python.

-Monkey: một công cụ dòng lệnh để kiểm thử khả năng chịu tải của ứng dụng thông qua công cụ adb của Android.

3. Các mục tiêu kiểm thử

Trong suốt quá trình phát triển phần mềm, các testcase sẽ hướng đến các thiết bị khác nhau. Từ đơn giản, phức tạp và tốc độ kiểm thử trên máy ảo đến trên một thiết bị thật cụ thể nào đó. Ngoài ra có một vài trường hợp trung gian như chạy các test trên một máy ảo cục bộ JVM hay DVM, phụ thuộc vào từng trường hợp. Mỗi trường hợp đều có ưu và nhược điểm riêng. Emulator có lẽ là thiết bị phù hợp nhất mà ta có thể thay đổi gần như tất cả các tham số cấu hình để mô phỏng các điều kiện khác nhau cho testcase.

Thiết bị thật dùng để test hiệu năng vì trên emulator sẽ không thể tính ra được các thông số trên thiết bị thật sẽ như thế nào. Rendering, filling, và các trường hợp khác nên được kiểm tra trước khi ứng dụng được chuyển giao cho người dùng cuối.

4.Một vài dạng kiểm thử trên Android

Vì các Android testing API đều là sự mở rộng trên Junit framework nên testing trên Android cũng có một số tính năng tương tự như trên Junit nhưng có một số phần mở rộng để phù hợp với đặc thù của nền tảng Android như sau:

a) Unit test: Junit framework là một nền tảng co bản cho kiểm thử đơn vị trên Android, đơn giản Junit là một framework mã nguồn mở được viết bởi Erich Gamma và Kent Beck. Android API 17 (android 4.2) hiện vẫn chưa hỗ trợ cho Junit 4, vì vậy để kiểm thử đơn vị ta sẽ sử dụng Junit 3

b) Kiểm thử giao diện người dùng (UI Test): như ta đã biết, chỉ có các luồng chính mới được phép thay đổi giao diện người dùng. Để có thể kiểm thử trên UI, ta phải sử dụng annotation @UIThreadTest hay nếu chỉ chạy một phần test trên UI, thì sử dụng lệnh Activity.runOnUiThread(Runnable r) với r là thread chứa các lệnh kiểm thử.

Class TouchUtils cung cấp các sự kiện cho phép ta thực thi các tương tác với UI như:

  • Click
  • Drag
  • Long click
  • Scroll
  • Tap
  • Touch

c) Kiểm thử tích hợp: được dùng để kiểm thử các thành phần riêng lẻ khi kết hợp với nhau. Các modules khi được kiểm thử đơn vị độc lập sẽ được tích hợp lại trong kiểm thử tích hợp. Thông thường Android Activities cần tích hợp với hệ thống để thực thi được. Các Activities cần ActivityManager cung cấp vòng đời và truy cập vào các tài nguyên, hệ thống file và cơ sở dữ liệu. Tương tự với Service và ContentProvider. Tất cả các thành phần này đếu được Android testing framework hỗ trợ cho việc kiểm thử dễ dàng.

d) Kiểm thử chức năng hay kiểm thử chấp nhận Trong phát triển phần mềm, kiểm thử chấp nhận thường do những người quản lí chất lượng thực hiện trên một ngôn ngữ đặc thù nào đó. Tuy nhiên khách hàng thường là những người chính thực hiện các kiểm thử này. Có một vài công cụ và framework hỗ trợ việc này như FitNesse. Gần đây có một khuynh hướng phát triển phần mềm mới là Behavior Driven Development (BDD) đang trở nên phổ biến và được biết như là sự tiến hóa của TDD

e) Kiểm thử hệ thống bao gồm:

-Kiểm thử hiệu năng: đo đặc tính hiệu năng của các thành phần lặp lại nhiều lần để có thể tối ưu hóa phần mềm.

-Kiểm thử giao diện: như đã trình bày trên

-Kiểm thử Smokes: Trong lĩnh vực sản xuất phần mềm, smoke testing thường được dùng cho lần tích hợp các modules, thành phần hoặc sau khi phần mềm được sửa chữa, bảo trì nhằm mục đích cung cấp cho các bên liên quan những bảo đảm phần mềm không có những lỗi nghiêm trọng. Nó chứng minh được phần mềm không bị thất bại ngay lần đầu tiên để chuẩn bị cho bước test tiếp theo là stress test.

-Kiểm thử cài đặt: sau khi đóng gói phần mềm cần kiểm thử việc cài đặt có thành công không trước khi chuyển giao cho khách hàng.

Trong phần trình bày tiếp theo, em xin trình bày chi tiết các class mà Android testing framework hỗ trợ trong việc kiểm thử phần mềm và các bước tiến hành để xây dựng phần mềm theo quy trình phát triển TDD


All rights reserved

Viblo
Hãy đăng ký một tài khoản Viblo để nhận được nhiều bài viết thú vị hơn.
Đăng kí