Cần một môi trường thực tế nhất có thể: giả lập rất tốt, nhưng vẫn chưa đủ. Simulator hiện nay chưa thể giả lập một số thao tác như rotate – xoay màn hình, con quay hồi chuyển. Rất nhiều loại thiết bị các mẫu điện thoại máy tính bảng mới xuất hiện liên tục, theo đó các loại màn hình, độ phân giải, hệ điều hành, bộ vi xử lý cũng rất khác nhau. Các điều kiện hay thay đổi: thiết đặt, mạng, bộ nhớ, ... cũng có thể gây ra lỗi. Nhiều công ty lập trình tiến hành kiểm thử bằng tay: đó thực sự là 1 công việc nhàm chán, lặp đi lặp lại, đắt đỏ, tốn nhiều thời gian. Những vấn đề phát sinh từ sự khác biệt giữa các thiết bị: crash, lỗi đồ họa, lỗi tính toán lỗi UI, không hiển thị text, button, ...
Trang 1ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ -
Cán bộ giám sát: TS Võ Đình Hiếu
1. Dương Hữu Hiếu
2. Nguyễn Đình Đại
3. Nguyễn Văn Kháng
Trang 2Mục Lục
Phân công công việc
Trình bày viết định nghĩa các bước với Calabash console
Ý tưởng và cách thức viết test Cross-platform
Viết kịch bản test cross-platform cho app VietGag
Trang 3I. Calabash
1. Các vấn đề kiểm thử trên ứng dụng di động
- Cần một môi trường thực tế nhất có thể: giả lập rất tốt, nhưng vẫn chưa đủ Simulator hiện nay chưa thể giả lập một số thao tác như rotate – xoay màn hình, con quay hồi chuyển
- Rất nhiều loại thiết bị - các mẫu điện thoại máy tính bảng mới xuất hiện liên tục, theo đó các loại màn hình, độ phân giải, hệ điều hành, bộ vi xử lý cũng rất khác nhau
- Các điều kiện hay thay đổi: thiết đặt, mạng, bộ nhớ, cũng có thể gây ra lỗi
- Nhiều công ty lập trình tiến hành kiểm thử bằng tay: đó thực sự là 1 công việc nhàm chán, lặp đi lặp lại, đắt đỏ, tốn nhiều thời gian
- Những vấn đề phát sinh từ sự khác biệt giữa các thiết bị: crash, lỗi đồ họa, lỗi tính toán lỗi UI, không hiển thị text, button,
Hình minh họa một số lỗi trên thiết bị di động
2. Calabash
a. Giới thiệu về Calabash
- Calabash là một công cụ kiểm thử ứng dụng di động tự động và đa nền tảng
- Calabash chỉ sử dụng một giao diện duy nhất: Cucumber cho cả iOS và android
- giúp giảm thời gian học, nhanh chóng ứng dụng
- Có thể tái sử dụng các feature của Cucumber để chạy đa nền tảng – từ đó giảm thời gian và chi phí kiểm thử
- Thích hợp với quy trình BDD – Behavior-Driven Development, là một quy trình sản xuất phần mềm kết hợp kỹ thuật tổng quát và các nguyên lý của test-
Trang 4driven development cùng với ý tưởng từ thiết kế domain-driver và oriented analysis and design – phân tích thiết kế hướng đối tượng để cung cấp cho lập trình viên và chuyên gia phân tích kinh doanh các công cụ chia sẻ, các tiến trình chia sẻ để phối hợp cùng việc phát triển phần mềm, dựa vào lợi ích kinh doanh và hiểu biết kỹ thuật): Những đặc tả kinh doanh có thể hiểu được, chạy được như là các test Vì thế calabash rất thích hợp để phát triển các ứng dụng với mục đích kinh doanh.
object Chạy được trên các thiết bị vật lý cũng như giả lập – đáp ứng được nhu cầu chạy trên các thiết bị thật
- Hỗ trợ cả ứng dụng thuần di động lẫn các ứng dụng lai, như là ứng dụng có nhúng webview
- Miễn phí, mã nguồn mở - có một cộng đồng phát triển và hỗ trợ lớn
- Một số hỗ trợ tùy chọn: đào tạo, tư vấn, cung cấp thiết bị test trên mây – bạn cóthể trả phí để thuê các thiết bị test trên mây để test các chức năng yêu cầu thiết
bị thật Các thiết bị này được gắn một con robot nhỏ để có thể xoay thiết bị khi cần thiết
b. Kiến trúc của Calabash
Mô hình thiết kế
- Calabash được thiết kế theo mô hình client-server nên gồm có 2 phần:
• Client library được viết bằng ruby
• Server framework được viết bằng objective-C
- Calabash client bao gồm các thư viện calabash-android để kiểm thử cho ứng dụng android và calabash-ios để kiểm thử cho ứng dụng iOS Calabash server cũng có calabash iOS và Android Framework tương ứng
- Calabash client và Calabash server giao tiếp với nhau bằng jSON thông qua giao thức http Calabash server sẽ nhận yêu cầu từ Calabash client và thao tác với ứng dụng
Giao tiếp giữa calabash và cucumber
Trang 5- Công cụ cucumber sẽ thực thi kịch bản test theo từng bước trong file feature được viết bằng gherkin và tạo ra các kết quả test.
- Cụ thể từng bước của kịch bản test trong các file step definitions được viết bằng ruby Calabash clients được sử dụng để mô tả các bước này
Calabash-ios
Với iOS chúng ta sẽ tạo một bản sao đặc biệt bằng Xcode và liên kết với calabash framework Server framework sẽ bắt đầu một http server bên trong ứng dụng này và nghe yêu cầu từ client library Các phương thức ruby API được sử dụng để viết các bước kiểm thử sẽ tạo http request tới server để làm những việc như tìm kiếm thành phần trong giao diện, thao tác trên chúng
Calabash-android
Trang 6- Instrumentation Test Server: là một ứng dụng khác được cài đặt và thực thi trênthiết bị Ứng dụng này dựa trên ActivityInstrumentationTestCase2 từ android SDK Nó được tạo ra bởi calabash framework Chúng ta sẽ thao tác với nó thay
vì thao tác trực tiếp với app
- Lợi ích lớn nhất của kiến trúc này là bạn có thể kiểm thử ứng dụng Android màkhông cần thay đổi bất kì cái gì trong ứng dụng
c. Viết test với Calabash
Tạo khung thư mục Cucumber
- Đầu tiên bạn vào thư mục chứa app và chạy lệnh
• Calabash-android gen đối với app android
• Calabash-ios gen đối với app iOS
- Calabash sẽ tạo ra một khung thư mục như sau:
• Trong thư mục Support là các file mô tả tiến trình cài đặt và kiểm thử ứng dụng, ở đây bạn có thể thay đổi hành động trước và sau khi kiểm
Trang 7thử ví dụ như sau mỗi kịch bản test cài đặt lại ứng dụng, hoặc là chỉ khởiđộng lại ứng dụng.
• Các file có phần mở rộng feature ngay phía ngoài thư mục feature: là file mô tả các kịch bản test được viết bằng gherkin
• Thư mục Step_difinitions chứa các file mô tả chi tiết từng bước kiểm thử trong các file feature, được viết bằng ruby API của calabash
Gherkin
- Là một ngôn ngữ hướng dòng - Line-oriented language: sử dụng khoảng thụt đầu dòng để xác định cấu trúc, kết thúc dòng để chấm dứt báo cáo Hầu hết các dòng bắt đầu bằng một từ khóa
- Là một Business Readable, Domain Specific Language: tức là ngay cả những người kinh doanh, không nhất thiết phải là một lập trình viên, cũng có thể hiểu được, và nó có thể mô tả những lĩnh vực chuyên ngành Nó cho phép mô tả hành vi của phần mềm mà không cần biết chi tiết làm sao hành vi đó được thựchiện Vì đặc điểm này nên gherkin thích hợp để viết test cho các ứng dụng theoquy trình BDD – behavior driven development
- Gherkin phục vụ 2 mục đích:
• Là tài liệu hướng dẫn: file feature như là một tài liệu chỉ dẫn lập trình viên các bước để test ứng dụng, rất rõ ràng và chi tiết Nhiệm vụ cảu lập trình viên chỉ còn định nghĩa các bước đó ra
• Kiểm thử tự động: calabash sẽ kiểm thử phần mềm theo từng bước trongkịch bản test ở file feature
- Các từ khóa của Gherkin có thể viết bằng nhiều ngôn ngữ: hiện tại là 37 ngôn ngữ bao gồm cả tiếng việt
Cách viết feature
- Dòng đầu tiên bắt đầu bằng từ khóa Feature, theo sau đó là các dòng mô tả feature
- Mỗi feature có thể chứa một hay nhiều scenario: bắt đầu bằng từ khóa
Scenario, sau từ khóa Scenario là dòng mô tả kịch bản test
- Ngoài kịch bản, feature có thể chứa:
Trang 8• Background: thêm một số bối cảnh vào các kịch bản, chạy trước mỗi kịch bản
• Scenario Outline và Example: tạo ra một kịch bản mẫu để chạy với nhiều bộ input khác nhau
- Mỗi scenario chứa nhiều step bắt đầu bởi các từ khóa Given, When, Then, But hoặc And Cucumber không có sự phân biệt giữa các từ khóa này Nhưng chúng ta rất nên sử dụng chúng đúng cách
o Given: đưa hệ thống vào một trạng thái trước khi người sử dụng bắt đầu tương tác với hệ thống (trong các bước When) Như trên hình là trạng thái chỉ còn 1 lon caffee trong máy, và tôi đã nhét và máy 1$
o When: mô tả các hành động chính người dùng thực hiện như là touch button, scroll, Trên hình là tôi đã thực hiện hành động là ấn vào nút chọn caffee
- Then: quan sát kết quả - các quan sát liên quan đến giá trị kinh doanh, lợi ích trong mô tả tính năng, như là các giao diện người dùng, tin nhắn, không phải làmột cái gì đó ẩn và không có giá trị kinh doanh Như ví dụ kết quả mong muốn
là tôi nên được phục vụ một lon caffee
- But và And: dùng để nối các step thay cho việc lặp lại các từ khóa – làm cho các step đọc trôi chảy hơn
Định nghĩa các bước trong kịch bản test
- Mỗi bước (step) sẽ tương ứng với một định nghĩa bước (step definition)
- Mỗi định nghĩa bước bao gồm một từ khóa, một chuỗi hoặc biểu thức chính quy, và một khối lệnh
- Các câu lệnh của định nghĩa làm một trong ba việc:
o Gesture: thực hiện hành động của người dùng như chạm, kéo thả, cuộn, xoay màn hình,
Trang 9o Assertions: xác nhận một thành phần như text, button, có tồn tại và
có chính xác hay không
o Screenshots: chụp ảnh màn hình hiện tại – cần thiết khi kiểm thử các thành phần đồ họa không thể bắt lỗi bằng Assertions
- Sử dụng API tương ứng với mỗi nền tảng iOS hoặc Android để viết
Viết test cho kiểm thử đa nền tảng
Tại sao phải viết test kiểm thử đa nền tảng?
- Các công ty thường phát triển ứng dụng của họ trên nhiều nền tảng khác nhau: điện thoại, máy tính bảng Android, iPhone, iPad, Web, Trong đa số các trường hợp, yêu cầu kinh doanh và thông số kỹ thuật là giống nhau, hoặc tương
tự nhau trên các nền tảng Nếu mỗi nền tảng đều viết một bộ test riêng trong khi chúng có các điểm chung như thế rất lãng phí thời gian và tiền bạc Nhưng
do sự khác nhau trên các nền tảng, nên việc viết một bộ test có thể chạy trên tất
cả các nền tảng là không thể, nhưng chúng ta sẽ cố gắng tái sử dụng nhiều nhất
có thể, để chi phí viết test đa nền tảng là thấp nhất
Ý tưởng viết test đa nền tảng
Kiểm thử tự động là lập trình, do đó những cách thức làm tốt trong lập trình cũng được áp dụng cho việc kiểm thử tự động Ruby có tính hướng đối tượng, và phần lớn kiểm thử Calabash nên theo một thiết kế hướng đối tượng tốt như là nguyên tắc trừu tượng hóa, tách các mối liên quan, mô-đun hóa, tái sử dụng,
- Sử dụng mô hình Trang-Đối tượng Page-Object Pattern (POP): viết những đoạn mã kiểm tra có cấu trúc tốt hơn nhằm sử dụng lại các đoạn code cho đa nền tảng tốt hơn
- Page Object: trừu tượng hóa một màn hình của ứng dụng thành một trang đối tượng Trang đối tượng này cung cấp phương pháp để truy vấn trang thái, dữ liệu của màn hình, và các phương thức tác động lên màn hình
- Lợi ích: trừu tượng hóa và tái sử dụng
Ví dụ ta có một màn hình Talkscreen được trừu tượng hoá thành một trang đối tượng
là một class như sau:
Trang 10Ở đây ta có phương thức talks() trả về các cuộc nói chuyện đang diễn ra, phương thức details(talk) để theo dõi chi tiết của một cuộc nào chuyện bất kỳ Dường như giao diệncủa lớp TalksScreen thích hợp cho cả 2 nền tảng iOS và Android Điều đó nghĩ là đoạn mã được gọi, thường ở trong định nghĩa các bước, là độc lập với nền tảng, do đó
nó có thể được tái sử dụng qua các nền tảng
Làm như thế giúp bạn tái sử dụng hoàn toàn tính năng Cucumber cũng như khi cài đặt: các chi tiết của việc tương tác với màn hình được thực thi bởi trang đối tượng
Ý tưởng ở đây là bạn cung cấp cài đặt của các trang đối tượng cho mỗi nền tảng bạn muốn cung cấp (iPhone, iPad, điện thoại Android, máy tính bảng Android, web trên diđộng, web cho máy bàn…)
Cách viết test kiểm thử đa nền tảng
Để viết test đa nền tảng với Calabash, ta thực hiện lần lượt các bước sau:
1. Cho mỗi màn hình bạn muốn kiểm thử, chọn một giao diện cho một lớp đối tượng (giống như lớp TalksScreen ở trên)
trang-2. Trong mỗi định nghĩa bước, chỉ sử dụng các trang đối tượng và phương thức của chúng (không trực tiếp gọi các hàm API của Calabash iOS hay Calabash Android)
3. Với mỗi nền tảng có hỗ trợ, đặt một lớp chứa các thực thi các phương thức của trang-đối tượng
4. Tạo một hồ sơ Cucumber (config/cucumber.yml) Định nghĩa một hồ sơ cho mỗi nền tảng (android, ios), chắc chắn mỗi hồ sơ chỉ tải các lớp trang-đối tượngcủa nền tảng đó
Tổng kết kiến trúc kiểm thử đa nền tảng
Trang 11II. Cruisecontrolrb
1. Tích hợp liên tục (Continuous Integration).
Tích hợp liên tục là gì?
Continuous Integration (CI), hay “tích hợp liên tục” là một trong những Agile
Practices, được thiết kế ban đầu như một phần của XP (eXtreme Programming) Nhưng hiện nay với những ưu điểm vượt trội của mình thì CI còn được áp dụng một cách riêng biệt Nhiều nhà phát triển sử dụng CI, nhưng không áp dụng toàn bộ các Practices trong XP
Tích hợp liên tục (Continuous Intergration hay CI) là một môi trường hỗ trợ phát triểnphần mềm có chức năng giúp các thành viên trong nhóm phát triển tích hợp công việc của họ một cách thường xuyên, liên tục Mỗi điểm tích hợp sẽ được kiểm tra bởi một qui trình build và test tự động để đảm bảo rằng việc thích hợp sẽ không gây ra lỗi cho sản phẩm hiện tại và phát hiện sớm nhất những lỗi phát sinh trong quá trình tích hợp đó
Trang 12Xem mã nguồn
Xây dựng sản phẩm
Chạy các kiểm thử Công bố kết quả
Phần mềm phát triển theo mô hình Agile còn được gọi là phần mềm tích hợp liên tục (Continuous Integration) Hệ thống tích hợp liên tục là thành phần sống còn của một Agile team
Khi được dùng như một phần của phương pháp tiếp cận dựa trên kiến trúc, sự tích hợpliên tục (Continuous Integration - CI) và phát triển theo hướng kiểm thử (Test-Driven Development - TDD) mở rộng phương pháp agile cơ bản đủ để cung cấp cả chất lượng cao lẫn tính linh hoạt của dự án
CI không thể làm cho code của bạn không bị lỗi (đương nhiên, bởi lỗi hay không là phụ thuộc vào … chính bạn), thế nhưng nó có thể giúp bạn phát hiện ra lỗi một cách
dễ dàng, và nhanh chóng Mục đích cuối cùng của CI là đảm bảo cho việc project của bạn có thể triển khai vào bất cứ lúc nào bạn muốn
Trang 13Nguyên tắc duy nhất : NEVER BREAK THE BUILD! Để đảm bảo được quy tắc này, bạn cần giải quyết được hai vấn đề sau :
- Những gì chạy tốt trên máy của bạn cũng cần phải chạy tốt trên máy của người khác Lý do kiểu như “Nó vẫn chạy tốt trên máy tôi mà” là không được chấp nhận !
Có thể là do bạn sơ ý add thiếu một vài file vào Source Code Management của mình, hay thay đổi một vài config, cấu trúc database … mà không thông báo với người khác v.v.v
- Chỉ những code mà đảm bảo cho bản build thành công mới đực phép xuất hiệntrong nhánh chính (mainline)
Để giải quyết những vấn đề này, người ta sử dụng một server trung gian đứng ra thực hiện các bản build mỗi khi có yêu cầu tích hợp Nó được gọi là CI Server CI server cócác nhiệm vụ chính sau:
- Quản lí kho lưu trữ mã nguồn
- Kiểm tra và đưa tài nguyên từ kho lưu trữ mã nguồn vào trong quy trình tích hợp
- Xây dựng mã nguồn và chạy các kiểm thử
- Thông báo cho các lập trình viên trong nhóm
Một số CI server thông dụng: CruiseControlrb, CruiseControl.NET, Jenkins,
Trang 14Giải pháp này thực sự giúp cho các nhà phát triển phần mềm giảm bớt các vấn đề phátsinh trong quá trình tích hợp và cho phép công việc phát triển phần trở nên mềm nhanh chóng và gắn kết hơn.
CI bao hàm một loạt những quá trình được gắn kết với nhau như: tự động build, kiểm tra tiêu chuẩn mã, phân tích tĩnh, kiểm thử đơn vị, triển khai, kiểm thử tích hợp,
Các yêu cầu của một hệ thống tích hợp liên tục
- Một Source Control Management: SVN, Mercurial, Git, Visual Source Safe…
- Một hệ thống build tự động: Xcode, Ant, NET, NAnt,
- Khả năng tự kiểm thử trên bản build tự động đó: JUnit,Cucumber , CppUnit …
- Code phải được chuyển lên nhánh chính (mainline) hàng ngày
- Một CI server có thể gắn kết các công việc trên: Jenkins, Bamboo, Cruisecontrol, Hudson,
- Khả năng kiểm thử sản phẩm trong môi trường đồng nhất
- Khả năng báo cáo tình trạng bản build
- Khả năng triển khai tự động bản build
- Mọi người có thể nhìn thấy những gì đã xảy ra (thay đổi, lỗi…)để xem xét và giải quyết
Ưu điểm
- Giảm thiểu rủi ro do lỗi được phát hiện sớm
- Giảm thiểu sự lặp lại cho các quá trình
- Tạo phần mềm có giá trị sử dụng sớm nhất có thể và sẳn sàng triển khai mọi lúc mọi nơi
- Cung cấp cái nhìn xuyên suốt tổng quan và cụ thể cho từng giai đoạn, từ đó dễ dàng lập kế hoạch phát triển
- Nâng cao kỹ năng của đội ngũ nhân viên phát triển phần mềm
- Cải thiện chất lượng phần mềm
Nhược điểm
- Cần thời gian thiết lập hệ thống ban đầu và làm quen với CI server
- Đòi hỏi quản lý dự án, người lập trình, người kiểm định phải am hiểu mô hình phát triển phần mềm Agile, hệ thống tích hợp CI, cách sử dụng các công cụ hỗ trợ cho Agile và CI
- Chi phí thiết bị phần cứng (các server cho CI)
Lợi ích khi sửa dụng tích hợp liên tục
Từ góc độ kỹ thuật, tích hợp liên tục (Continuous Integration - CI) giúp các nhóm làmviệc hiệu quả hơn Các nhóm này có thể có chức năng liên quan nhau, tạo ra phần cứng và phần mềm làm việc cùng nhau Họ có thể làm việc ở những nơi khác nhau,