Showing posts with label MOBILE-TESTING. Show all posts
Showing posts with label MOBILE-TESTING. Show all posts

Chuyên mục Kiểm thử di động ( Mobile testing ) hôm nay sẽ bàn luận về vấn đề UI trên Smart Phone .  Là vấn đề mà bất kỳ một kiểm thử viên nào cũng nên biết rõ .

Khách hàng là thượng đế , Khách hàng muốn Team của bạn phát triển thêm nhiều chức năng mới cho ứng dụng của họ . Đương nhiên là phải đồng ý rồi, thế nhưng , bạn nên nhớ, Có thể việc nhồi nhét nhiều chức năng có thể giết chết ứng dụng của bạn đó ! 
Tại sao lại như vậy ? 

Là tại vì, trên smartphone, diện tích màn hình là có giới hạn và số nút, số chức năng trên 1 màn hình liên quan mật thiết đến chất lượng và tính thân thiện của ứng dụng. Những cải thiện hợp lí, những yêu cầu chính đáng đi nữa cũng sẽ trở thành thảm họa nếu số lượng tăng lên và hiển thị " chen chúc" nhau trên màn hình nhỏ hẹp . Và người làm ứng dụng trên di động nên hiểu rằng : 
 -  Nhiều lựa chọn không hẳn là tốt vì có thể nó  gây hoang mang cho người dùng . Nếu chức năng mà bạn thêm vào đó không quá cần thiết thì nghĩa là bạn đang mất nhiều hơn là được.
 -  Khả năng phán đoán của con người sẽ yếu đi nếu mọi chức năng, mọi lựa chọn đều được phơi bày . Diện tích màn hình có thể coi như tiền bảo hiểm, bạn có thể dùng xả láng tùy ý. Tuy nhiên, đến lúc thật sự cần đến nó bạn sẽ bó tay không làm được gì.
 - Không gian màn hình là tài nguyên có hạn , đồng thời cũng là thứ bảo đảm cho sinh mạng của ứng dụng nên phải  biết " tiết kiệm" và sử dụng   họp lý . Vấn đề “mỗi yếu tố chiếm mấy phần màn hình?” là câu hỏi lớn nhất dành cho các nhà thiết kế giao diện cho smartphone. Thêm chức năng cũng đồng nghĩa với việc lấy khả năng mở rộng của app, tính bao quát và diện tích màn hình ra để đánh đổi lấy tính tiện lợi.  
- Không nên quá tham lam, những chức năng thêm vào có thể là vô hạn, nhưng những cái cần được nhấn mạnh thì có hạn. Việc thêm chức năng là việc không  thể Undo được  , Vì sao ư ? 
Chức năng hiển thị ắt sẽ có người dùng, và họ sẽ quen với nó, Nếu  chúng ta undo chức năng đó, nghĩa là chúng ta sẽ nhận một loạt những phàn nàn từ phía user - điều này chẳng ai muốn. Thường thì những người có vai trò đưa ra quyết định trong 1 dự án sẽ không đánh đổi việc bỏ chức năng để gánh lấy rủi ro đó. Kết quả là, chức năng thường chỉ có thêm vào chứ không có bớt đi.
 Đây như  tuyên ngôn chứng minh cho trường hợp , Nếu làm theo tất cả những gì User và khách hàng của bạn yêu cầu thì 99% sẽ  dẫn đến việc ứng dụng đó sẽ bị " phá cho tan nát" và " chết yểu" trước khi trình làng. 


Kiểm thử tự động

 Đây là  MS-Word ở tình trạng hiển thị toàn bộ chức năng của toolbar. Nếu hiển thị hết các chức năng đó thì chúng ta chỉ còn 3 dòng để soạn thảo văn bản trong khi đó chức năng chính của chương trình này là để soạn thảo văn bản .
- Tiếp theo là việc User không thích học lại từ đầu
 Việc thêm chức năng đồng nghĩa với việc cập nhật và làm quen với cái mới . Thực tế đã chứng minh, thói quen người dùng như một loại quán tính, Nếu bạn muốn user học lại cách sử dụng để dùng app được tiện hơn, rất nhiều khả năng user sẽ rời bỏ bạn cùng với cuộc “cách mạng” đó của bạn. Mất thời gian , thay đổi vì một chút tiện lợi hơn thôi mà phải trải nghiệm, làm quen lại từ đầu là một cái giá quá đắt.
Với tâm lí đó, user thường ghét việc layout và vị trí các button trong app bị thay đổi cho dù đó là những thay đổi hợp lí đi chăng nữa. Còn nếu những thay đổi thậm chí không thật sự hợp lí mà chỉ là kết quả của việc mở rộng chức năng vô tổ chức thì bạn nên chuẩn bị tinh thần để đón nhận việc user sẽ xóa app, hơn là việc họ học lại cách sử dụng nó.
- Tất cả không thể cùng đóng vai chính
Khi trên một màn hình đã có quá nhiều thứ rối rắm thì một giải pháp thường được đưa ra là “hãy làm cho cái ABC nào đó  nổi bật lên”.

Bàn về  tính dễ nhìn, về UI nói chung người ta thường có suy nghĩ “cứ nổi bật là sẽ dễ nhìn”. Đây là một sai lầm rất lớn.  “Làm nổi bật cái ABC” nào đó  cũng đồng nghĩa với việc “khiến những gì ngoài cái ABC bớt nổi bật đi”.

- Độ quan trọng của các yếu tố cũng là một khái niệm tương đối. 

Thiết kế layout cho smartphone cũng gần giống với việc nghĩ xem trước khi đi du lịch, nên bỏ những thứ gì trong nhà vào vali để xách đi. Nhà bạn có thể hiểu là ứng dụng trên PC, còn vali của bạn có thể hiểu là ứng dụng trên smartphone.
Về lí mà nói, mang theo tất cả những gì có trong nhà là tiện nhất. Tuy nhiên vấn đề là cái vali của bạn chỉ chứa được một số lượng đồ nhất định thôi. Một chiếc vali nhét đầy những đồ linh tinh, ngược lại sẽ trở thành gánh nặng của bạn. Bạn nhét chúng vào vì muốn tiện lợi nhưng rồi chính chúng sẽ khiến cho tính tiện lợi của chuyến du lịch mất đi.

Đối với app hay đối với chuyến du lịch của bạn cũng vậy, vấn đề không phải là “thứ gì ta cần mang theo?” mà là “thứ gì mà ta không cần mang theo cũng được?”.

Sau khi cho đồ vào vali bạn sẽ cảm thấy nặng lên ngay, nhưng đối với app thì khác – bạn không thể cảm nhận sức nặng đó bằng các giác quan được. Bạn sẽ tiếp tục thêm nhiều thứ vào mà không cảm thấy gì, đến lúc giật mình nhận ra thì app của bạn đã ở tình trạng không thể cứu vãn được nữa rồi.
Mang theo toàn bộ đồ đạc trong nhà đi du lịch là một việc làm vô nghĩa. Đối với app cũng vậy.


Kiem-thu-phan-mem-tu-dong


Xem thêm : Mobile testing 
 Những gạch đầu dòng quan trọng khi kiểm thử ứng dụng trên điện thoại di động
-------------------
Nguồn : tech.blog.framgia 

Học kiểm thử phần mềm 




Nội dung của bài học kiểm thử phần mềm tự động hôm nay sẽ hướng dẫn cách kiểm thử API với tình huống và bài tập cụ thể . Phần thực hành sẽ cho lên đầu sau đó là phần lý thuyết 
Để nhận bài viết mới nhất - các bạn nhập email ở" Đăng ký nhận bài qua mail " nhé 

Kiem-thu-phan-mem


I. Kiểm thử API với Rest client

1. Tình huống : 

Test API của chức năng đăng kí . 

Dữ  liệu đầu vào gồm:

Name : Chỉ được nhập kí tự , Không khoảng cho phép nhập số và ký tự đặc biệt và gioi hạn 100 ký tự

Username: Không có khoảng cách, không ký tự đặc biệt, giới hạn 32 ký tự
Email : Định dạng đúng email
Password : Gioi hạn 12 kí tự, không cho phép nhập ký tự đặc biệt
Re-type password : Phải giống với nội dung password
Age: Chọn trong dropdow box với nội dung có sẵn
Gender: Chọn Male hoặc FeMale
Country : United Kingdon ( chỉ một 1 chọn)
Language : English (EN) or VietNam(VI)
Daily recap : Thời gian nhắc - Chọn giá trị theo định dạng thời gian
Product : Chọn 1 Product trong danh sách
Reason : Chọn 1 lý do dùng sản phẩm (not required)
When dit you hear about the app : Chọn trong danh sách
Radio button Accept: Chọn Accept để đồng ý các điều khoản, nội quy
End checkbox:Check để nhận bản tin ( not required )

Giao diện để kiểm thử như hình dưới



Kiem-thu-phan-mem



Sau khi input dữ liệu hợp lệ và click Next button, sẽ chuyển sang Màn hình Avatar để chọn 1 Avatar có săng trong danh sách :



Kiem-thu-phan-mem

Sau khi chọn ảnh xong, click Done để hoàn thành việc đăng ký

2.Chọn công cụ kiểm thử :

+ Rest Client Add-on
     Mở Firefox và nhập đường dẫn
     https://addons.mozilla.org/en-us/firefox/addon/restclient/
    Sau đó nhấn Install . Vậy là xong, 

các bạn đã cài đặt xong tool để kiểm thử API 

+ Các case sẽ kiểm thử 

+ Dữ liệu vào và dự kiến dữ liệu đầu  ra cho các trường họp kiểm thử

 ( Input - out put với các field quy định thì Dev/PM sẽ cung cấp nhé, Việc của QC là nhập dữ liệu cho các field và xem phản hồi thôi)  Và đây là đoạn API cho Sign up cho chương trình này
 + Input
   {
"email": "qctestervvn001@gmail.com",
"user-name": "test1",
"password": "a123456",
"name": "QCTESTER",
"age": 19,
"gender": "MALE",
"country": "US",
"language": "en_US",
"recap-time": {
"type": "DAILY",
"value": "12:00:00"
},
"avatar": "/content/en_US/avatars/joker",
"app-reference": "\\app",
"device-date": "2015-01-20 10:41:00"
}
 +Out put
Đăng ký thành công:
{
  "type": "SUCCESS",
  "code": "SU-002",
  "message": "Sign up successfully"
} 
Đăng ký không thành công : Sẽ hiển thị mã lỗi và nội dung lỗi 

Giờ các bạn làm theo hướng dẫn của video nhé, chúng ta sẽ kiểm thử cho các trường họp sau:



  • Một số  trường họp kiểm thử:

  • 1)      Đăng ký thành công
  • 2)      Đăng ký ko thành công do email / Username đã tồn tai 
  • 3)      Đăng ký không thành công vì nhập sai định dạng email
  • 4)      Đăng ký không thành công vì để trống User hoặc email
  • 5)      Đăng ký không thành công vì Name vượt quá 100 kí tự
  • 6)      Đăng ký không thành công vì nhập tuổi sai định dạng ( Các bạn chú ý case này nhé, thường thì tuổi là 1 danh sách lựa chọn, người dùng chỉ có thể chọn hoặc không chọn thôi - không thể nhập dữ liệu ngoài danh sách cho nó ) 
  • 7)      Một số khác các bạn thực hành  trong Project cua cac ban nhé, đây chỉ là đemo choc ho chúng ta hiểu TEST API là test nhưng gì thôi 

II. Tìm hiểu lý thuyết


1. API là gì ?
API (Application Programming Interface - Giao diện lập trình ứng dụng )
API là lớp chuyên xử lý các thao tác người dùng, nhận request từ người dùng, xử lý và trả về dữ liệu cho Data base sau đó lại lấy dữ liệu từ Database gửi ngược lại người dùng ở tầng giao diện . 
API gồm nhiều phương thức nhưng chủ yếu là dùng 2 phương thức 
POST : Đẩy dữ liệu lên Server
GET:  Nhận dữ liệu từ Server và hiển thị 
(Còn nhiều phương thức khác pà kon tự search nha- thường rất hiếm dùng)

Vì sao API  phải validate dữ liệu trước khi xử lý trong khi dữ liệu hợp lệ đã được Validate hầu hết ở tầng giao diện ?


- Ở tầng giao diện người dùng ( website hiển thị), thường Javascript sẽ chặn những dữ liệu không họp lệ, cho nên khi gửi đến để Server xử lý, hầu hết đều là dữ liệu hợp lệ.


Tuy nhiên, nếu dùng thủ thuật, một số dữ liệu không họp lệ vẫn có thể vượt qua phần kiểm soát của giao diện và khi lưu vô database, sẽ làm sai những ràng buộc , gây nên những lỗi nghiêm trọng cho hệ thống.

Vì vậy, Test API  một là giúp kiểm tra lại 1 lần nữa, sàn lọc những dữ liệu không họp lệ được gửi tới và " lọt lưới" từ tầng giao diện, từ đó sẽ đưa ra thông báo cụ thể , hai là xử lý các yêu cầu của người dùng để đưa ra kết quả hiển thị cho người dùng xem có đúng như kết quả mong đợi hay không

Ngoài Rest client , ta còn có thể sử dụng thêm một số tool như

  • Công cụ SOAPUI
  • Công cụ Runscope
  • Công cụ Postman with jetpacks
  • Công cụ Postman with newman
  • Công cụ Curl
  • Công cụ Cfix
  • Eclipse SDK tool- Automated API testing  
Chúc các bạn thành công

---------------
http://kiemthuphanmemvvn.blogspot.com/
Face: https://www.facebook.com/KiemThuPhanMemVvn
Group: https://www.facebook.com/groups/1549328495322684/ 
Chọn "Đăng ký nhận bài qua mail" để nhận bài viết mới nhất nhé 

Học kiểm thử phần mềm tự đông 












 Kiểm thử ứng dụng trên thiết bị di động 

Ngày nay - ứng dụng di động đang ngày càng phát triển và Kiểm thử ứng dụng trên điện thoại đang hot hơn bao giờ hết .

 Vậy kiểm thử trên thiết bị di động sẽ chú ý test những case nào ? Chúng ta sẽ test những gì và kiểm thử ứng dụng như thế nào ? 

Bài viết này sẽ chia sẽ những checklist quan trọng khi test trên điện thoại di động 



Kiem-thu-phan-mem


I. Cài đặt và định hình ứng dụng khi Test trên thiết bị di động 

1) Dự án của bạn Client yêu cầu kiểm thử trên thiết bị di động/ tablet nào ( SamSung S5, Iphone5, Iphone 4...) , hỗ trợ trên những hệ điều hành nào ( Android 4.2,4.3 ...IOS6, IOS7,IOS8...), Kích thước màn hình hỗ trợ (4.0 inch, 4.5 inch ...) từ đó dùng chương trình giả lập và dùng cả thiết bị thực để thực hiện việc kiểm thử

2) Ứng dụng bạn đang kiểm thử lưu trữ ở đâu - hình thức lưu trữ ( Thẻ nhớ - bộ nhớ điện thoại)
  Điều gì xảy ra khi ta xóa thư mục lưu trữ của ứng dụng

3) Ứng dụng cùng hoạt động trên nhiều thiết bị khác nhau ,việc đồng bộ sẽ như thế nào

4) Tải ứng dụng ở đâu - kiểm thử các trường họp đầy bộ nhớ hoặc gián đoạn trong quá trình tải app

5) Kiểm thử quá trình cài đặt, gỡ bỏ ứng dụng , cài đặt lại và sẽ như thế nào nếu quá trính đó bị gián đoạn

6)  Kiểm thử quá trình update app , sẽ như thế nào nếu không update version mới

II.  Test giao diện ứng dụng trên thiết bị di động 

 Tương tự như Kiểm thử Website hay ứng dụng trên desktop , Kiểm thử giao diện trên di động vẫn chú trọng vào các điểm sau:

1)  Màu nền, màu chữ,kiểu chữ (hoa thường, font chữ...)  có khóp với Design , trường họp không có design, có thể kiểm tra xem màu nền có phù họp - có bị trùng với màu chữ gây khó đọc hoặc rối mắt người dùng không

2) Font size, size của các textbox, button và canh trái , phải, giữa ...ở chế độ bình thường , chiều dọc , xoay theo chiều ngang ...

3) Border các textbox, button... có smooth

4) Text, tootip của warning message, nội dung trang hiển thị  ...

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

6)   Dữ liệu hiện tại có được lưu khi đóng cửa sổ hay không?

7) 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? . Ngọai trừ có trường hợp yêu cầu set vị trí focus cụ thể

8) Kiểm tra giao diện khi người dùng thực hiện các hiệu ứng cảm ứng như swipe, touch ,tap on , zoom, pinch, multi-touch, shake and orientation.

9) Bàn phím nhập liệu có hoạt động tốt và không gây lỗi khi tiến hành input dữ liệu trên tất cả các màn hình

III. Test chức năng cho ứng dụng di động

1.  Đảm bảo các chức năng có trong thiết kế hoạt động tốt
2. Test những chức năng ngoài luồng
3. Test các chức năng khi mất kết nối mạng, kết nối mạng wifi, kết nối chậm, kết nối 3G,2G,4G..., chế độ máy bay ...
4. Click , swipe , otuch , scroll ...nhanh có gây ra lỗi
5. Sự chuyển hướng từ các liên kết trong ứng dụng hoặc các Social link ( g+,facebook...)
6. Thời gian của ứng dụng, trên Phone hay server ,Khi thay đổi cài đặt trong điện thoại ( ngày tháng , ngôn ngữ...), ứng dụng hoạt động ra sao
8. Get dữ liệu từ server khi ở chế độ background running,khóa màn hình hay listen
9. Kiểm tra sự đồng bộ dữ liệu khi đăng nhập ở nhiều thiết bị ( desktop, tablet, mobile)
10. Test camera nếu có trong ứng dụng, ( chụp ảnh, lưu trữ ...)
12. 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 ụng facebook, G+ ...và không cài các ứng dụng đó
13. Notification từ ứng dụng như update, nhắc nhở ...
14. Kiểm thử cho các trường họp bị gián đoạn khi sử dụng app như : Cuộc gọi , tin nhắn, Pin yếu, hoặc các tường họp đang mở nhạc,
15. Chú ý kiểm thử cho các trường họp System Crash / Force Close

Đây chỉ là góp nhặt và rút ra từ kinh nghiệm bản thân, các bạn có thể bổ sung thêm các case tủ của mình để bổ sung thêm bằng cách comment ở dưới nha,

Cảm ơn các bạn đã đóng góp và chia sẻ, hy vọng bài viết sẽ giúp ích cho các bạn đang là kiểm thử viên phần mềm hoặc đang tim hiểu về Kiểm thử phần mềm và cả các PM, Developer chú ý thêm một vài trường họp để dự án hoạt động tốt


Chúc một ngày vui vẻ và thành công
------------------------------
KiemthuphanmemVvn
Face: https://www.facebook.com/KiemThuPhanMemVvn
G+: https://plus.google.com/u/0/b/117542284818070877723/117542284818070877723/about






Xem nhiều nhất

Zui Zui

Nếu bạn không đủ mạnh -Đừng cố đi ngược đám đông