Báo cáo: Kiểm thử ứng dụng ios và android bằng calabash trong môi trường tích hợp liên tục với cruisecontrolrb

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

BÁO CÁO TỔNG KẾT
MÔN: CÁC VẤN ĐỀ HIỆN ĐẠI CỦA
CÔNG NGHỆ PHẦN MỀM
ĐỀ TÀI: KIỂM THỬ ỨNG DỤNG iOS
VÀ ANDROID BẰNG CALABASH
TRONG MÔI TRƯỜNG TÍCH HỢP
LIÊN TỤC VỚI CRUISECONTROLRB
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
Mụ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-pla%orm

Viết kịch bản test cross-pla%orm cho app VietGag

I. 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-
driven development cùng với ý tưởng từ thiết kế domain-driver và object-
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.
- 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
- 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
- Instrumentation Test Server: là một ứng dụng khác được cài đặt và thực thi trên
thiế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
thử 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ực
hiện. Vì đặc điểm này nên gherkin thích hợp để viết test cho các ứng dụng theo
quy 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 trong
kị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:
• 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,
o 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:
Ở đâ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ện
củ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 trang-
đối tượng (giống như lớp TalksScreen ở trên).
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ượng
của nền tảng đó.
Tổng kết kiến trúc kiểm thử đa nền tảng
II. 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ển
phầ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
đó.
Xem 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ợp
liê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.
Nguyê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ện
trong 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,
Giả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át
sinh 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àm
việ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,
bởi vì công việc tích hợp không ngừng sẽ đảm bảo rằng bạn không đi lệch các thiết
kế. Mọi người có thể làm việc trong các nhóm lớn, bởi vì các thành phần khác nhau
của hệ thống phức tạp sẽ làm việc cùng nhau đảm bảo hơn. Nó giải quyết nhiều vấn đề
sớm mà các nhóm phát triển theo phương pháp agile có thể đã trải qua nếu không tích
hợp liên tục. Việc phối hợp phương pháp tích hợp liên tục với phương pháp phát triển
theo hướng kiểm thử đã bổ trợ cho phương pháp agile, bởi vì nó cho phép phương
pháp agile làm việc hiệu quả hơn.
Từ góc độ kinh doanh, phương pháp tích hợp liên tục cung cấp các kết quả nghiệp vụ
tốt hơn bằng cách cho phép cho các nhóm đều tham gia. Nghĩa là, họ có thể đưa sản
phẩm ra thị trường nhanh hơn, bằng cách tìm ra các vấn đề khi chúng còn mới và nhỏ,

không phải chờ đợi cho đến khi chúng trở nên lớn và khó sửa chữa. Họ cũng có thể
đáp ứng tốt hơn yêu cầu đưa thêm tính năng mới vào sản phẩm trong lúc đang phát
triển. Điều này tạo ra một sản phẩm tốt hơn cho khách hàng, đó là hứa hẹn thực sự của
sự linh hoạt.
2. CruiseControlrb
Tổng quan Cruisecontrolrb
CruiseControlrb là một công cụ tích hợp liên tục miễn phí, mã nguồn mở được viết
bằng ruby. Cung cấp môi trường tích hợp liên tục cho bất kì ngôn ngữ lập trình cũng
như bất kì nền tảng nào. Dễ dàng cài đặt, cấu hình và sử dụng.
- Có thể làm việc với Java Ant, .NET, NAnt hay bất kì công cụ xây dựng nào có
thể build bằng dòng lệnh và trả về một giá trị khác 0 nếu xây dựng lỗi.
- Có ứng dụng web dashboard: thuận tiện, hữu ích, trực quan.
- Mở rộng thông qua các builder plugin, tùy chỉnh tiến trình xây dựng và các tùy
chỉnh cấu hình khác.
- Khi quá trình xây dựng bị gián đoạn hoặc đã được sửa, sẽ thông báo cho người
dung qua email, tin nhắn.
- Hỗ trợ các công cụ source control management phổ biến: Subversion, Git,
Mercurial, Bazaar.
- Dễ dàng cài đặt, cấu hình đơn giản và dễ sử dụng.
- Đa nền tảng
Là một CI Server, Cruisecontrolrb làm những công việc 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
CruiseControlrb bao gồm 2 phần: builder và dashboard
Builder là một tiến trình nền làm nhiệm vụ thăm dò kho quản lý mã nguồn của bạn
(repository) mỗi khoảng thời gian định trước để xem có sửa đổi nào không.
Nếu có ai đó cập nhật công việc của mình lên repository, builder sẽ:

- Phát hiện nó
- Cập nhật một bản sao của project
- Chạy chương trình build project
- Thông báo cho những người liên quan kết quả build
Dashboard là một ứng dụng web cho phép bạn theo dõi tình trạng của project, kết quả
build và test, khắc phục sự cố.
III. Cài đặt, cấu hình và sử dụng
1. Calabash
Các phần mềm cần thiết
- Git
- AndroidSDK với app Android và Xcode với app iOS
- Ant
- Ruby
- Calabash
- CruiseControlrb
1. Git
Cách cài đặt git có tại />Chú ý nhớ add SSH key và cài đặt để sử dụng được git trên cmd.
2. ADT Bundle/Xcode
Android SDK
/>Chú ý cần phải add System Variable cho ANDROID_HOME, và thêm vào
Path đường dẫn đến /sdk/platform-tools và sdk/tools
Xcode
Cài đặt từ app store trên máy Mac
3. Ant
Cách cài đặt Ant có tại
/>Sử dụng lệnh android update project path . target 3 để tạo ra file
build.xml trong thư mục của project để có thể build bằng ant
Sử dụng lệnh ant debug để build debug version
4. Ruby
Đối với Window, sử dụng />Ở đây mình sử dụng bản 1.9.3

Đối với Mac vào />Và làm theo hướng dẫn
5. Calabash
Cài đặt Calabash-android: />android/blob/master/documentation/installation.md
Để có thể sử dụng calabash với một project android, vào thư mục chính của
project gõ lệnh: calabash-android gen
Để test một app bằng Calabash, trong thư mục của project gõ lệnh
Calabash-android run file.apk
Cài đặt Calabash-iOS
cd vào thư mục cuả project
gõ lệnh: gem install calabash-cucumber
calabash-ios setup
calabash-ios gen để tạo bộ khung features để test
Trong Xcode, build project sử dụng –cal scheme
Sau khi viết xong kịch bản test, vào thư mục project gõ lệnh cucumber để
chạy test
2. Cruisecontrolrb
Download và cài đặt
Download Cruisecontrolrb tại
/>
Sau khi download về, giải nén ra ta được thư mục `cruisecontrol.rb-master`
Gõ lệnh:
cd cruisecontrol.rb-master
./cruise start
để khởi động CruiseControl.
Mặc định CruiseControl sẽ khởi động ở localhost với port 3333
Bạn mở trình duyệt lên và truy cập vào địa chỉ `http://localhost:3333/` Nếu hiện lên
trang giao diện của CruiseControl là bạn đã thành công.
Để đưa một project vào trong quy trình Continuous Integration của CruiseControl ta
gõ lệnh:
`cruise add [project-name] -r [repository] -s [svn|git|hg|bzr]`

Ví dụ, nếu bạn có một Project tên TestCruise, link trên github là
:michael/TestCruise.git thì gõ lệnh:
`cruise add TestCruise –r :michael/TestCruise.git -s git`
Hoặc đơn giản hơn là sử dụng giao diện web của cruisecontrolrb
Chọn Add Project: điền tên của project, điền link tới Repository trên source control
management (SCM) ,chọn kiểu SCM sử dụng và ấn Create.
Danh sách các project và trạng thái của chúng sẽ được hiển thị trên giao diện web của
Cruisecontrolrb. Ở đây bạn có thể ấn vào Build Now để tiến hành build project.
Ấn vào project để xem quá trình và kết quả build và test
Config gửi mail thông báo cho lập trình viên từ gmail
a. Config email của developer thư được gửi đến
Vào thư mục `\Users\YourName\.cruise\projects\YourProject` mở file
`cruise_config.rb` chỉnh lại dòng:
`project.email_notifier.emails = ['', '']`
trong đó trong dấu ngoặc [] là danh sách các email của developer mà bạn muốn thông
báo kết quả build và test.
b. Config để sử dụng tài khoản gmail để gửi mail
Vào thư mục `:\Users\abc\.cruise` mở file `site_config.rb` thêm vào các dòng sau:

ActionMailer::Base.smtp_settings = {
:address =>"smtp.gmail.com",
:port => 587,
:domain => "gmail.com",
:authentication => :plain,
:user_name => "",
:password => "yourpassword"
}
Vậy là từ giờ mỗi khi build và test xong CruiseControl sẽ gửi mail báo kết quả về cho
các Developer.
Đây là nội dung của mail thông báo, bao gồm cả những thay đổi đã được thực hiện

trên project cũng như kết quả build và test.
Config để chạy lệnh build và test tự động với app Android và iOS
Trong thư mục của project bạn tạo một file .sh nếu là MacOS, file .bat nếu là
Window, ví dụ `buildtest.sh`, `buildtest.bat`. Ngay khi bạn muốn đưa project vào
quy trình CI hãy tạo file này.
Nếu đó là app Android thì nội dung của nó sẽ như sau:
ant debug
calabash-android run ./bin/YourProject-debug.apk
Dòng đầu tiên là lệnh build bằng ant phiên bản debug.
Dòng thứ hai là lệnh chạy test với Calabash-android.
Nếu đó là app iOS thì nội dung của nó sẽ như sau:
xcodebuild build ONLY_ACTIVE_ARCH=NO -project YourProject.xcodeproj –
scheme YourProject-cal -configuration Debug -sdk iphonesimulator6.1
DEPLOYMENT_LOCATION=YES DSTROOT=build
TARGETED_DEVICE_FAMILY=1
cucumber
Dòng thứ nhất chứa lệnh build bằng XCode.
Dòng thứ hai chứa lệnh chạy test với Cucumber.
Sau đó hãy push file này lên git, CruiseControl sẽ phát hiện có thay đổi và sẽ pull về
để build, nhưng vì chưa được config nên vẫn sẽ báo lỗi
Vào thư mục `\Users\YourName\.cruise\projects\YourProject` mở
file `cruise_config.rb` chỉnh lại dòng:
project.build_command = 'sh buildtest.sh'
đối với MacOS
hoặc
project.build_command = 'buildtest.bat'
đối với Window.
Trong đó `buildtest.sh`, `buildtest.bat` là file bạn đã tạo trong project ở trên.

Lưu lại thay đổi, CruiseControl sẽ phát hiện thay đổi trong file `cruise_config.rb` và

lập tức build lại project.
**Lưu ý**: đối với Android, bạn phải chạy sẵn giả lập với lệnh `emulator –avd
avdname` không thì lúc chạy test sẽ bị lỗi không tìm thấy thiết bị.
Còn với iOS thì server sẽ tự động mở emulator trước khi chạy test.
IV. Thành quả đạt được và hướng phát triển
Thành quả đạt được:
- Hiểu về cấu trúc cũng như cách thức hoạt động của Calabash.
- Biết cách sử dụng Calabash để viết test cho ứng dụng iOS, android và
viết test đa nền tảng.
- Hiểu tích hợp liên tục là gì, lợi ích của nó khi phát triển phần mềm theo
phương pháp Agile.
- Biết cách cấu hình và sử dụng Cruisecontrolrb để đưa các project vào
môi trường tích hợp liên tục.
- Đã viết test hoàn chỉnh cho ứng dụng android là SortAlgorithms, viết
test hoàn chỉnh đa nền tảng cho ứng dụng VietGag. Đã tích hợp được 2
ứng dụng này vào môi trường tích hợp liên tục của Cruisecontrolrb.
Hướng tìm hiểu và phát triển:
- Tiếp tục rèn luyện cách viết test cho ứng dụng iOS, Android cũng như
viết test đa nền tảng.
- Sử dụng Calabash và Cruisecontrolrb để phát triển phần mềm theo
hướng BDD thay vì chỉ viết test cho ứng dụng có sẵn như đã demo.
- Viết một server để người dùng có thể upload file app và các test case, sẽ
tự động cấu hình và kiểm thử ứng dụng sau đó thông báo cho người
dùng.
V. Các nguồn tham khảo
Calabash
Calabash-ios: />Calabash-android: />Viết test đa nền tảng: />cucumber/doc/x-platform-testing.md
/>Giới thiệu, kiến trúc, nguyên lý hoạt động của Calabash: />Tích hợp liên tục (Continuous Integration)
/> /> />integration-agile-development/
/> />CruiseControlrb

/> />