KIỂM THỬ PHẦN MỀM HƯỚNG CLOUD

1. Điện toán đám mây (cloud computing ) là gì? và dịch vụ  kiểm thử phần mềm hướng cloud

 - Ra đời từ năm 2007 - Điện toán đám mây đã châm ngòi cho một cuộc cách mạng trong cách cung cấp thông tin và dịch vụ của các tổ chức. Nó hứa hẹn nhiều lợi ích nhưng cũng đặt ra cho nhà cung cấp nhiều thách thức hơn mặc dù điện toán đám mây chỉ là một cách khác để cung cấp tài nguyên máy tính chứ chưa phải là một công nghệ mới mẻ. 

Vậy điện toán đám mây là gì? Có thể hiểu đơn giản, các nguồn điện toán khổng lồ như phần mềm, các dịch vụ… sẽ nằm tại các máy chủ ảo (đám mây) trên Internet thay vì trong máy tính gia đình và văn phòng (trên mặt đất) để mọi người kết nối và sử dụng mỗi khi họ cần. Với các dịch vụ sẵn có trên Internet, doanh nghiệp không phải mua và duy trì hàng trăm, thậm chí hàng nghìn máy tính cũng như phần mềm mà chỉ cần tập trung sản xuất bởi đã có người khác lo cơ sở hạ tầng và công nghệ thay họ. Ta có thể truy cập đến bất kỳ tài nguyên nào tồn tại trong “đám mây (cloud)” tại bất kỳ thời điểm nào và từ bất kỳ đâu thông qua hệ thống Internet.

                        

Cũng như các nhà cung cấp phần mềm tại Việt Nam, một số công ty cũng đang tận dụng thế mạnh của các đơn vị trực thuộc từng bước đưa những phần mềm dùng chung của các bưu điện trên khắp các tỉnh/ thành trở thành các dịch vụ phần mềm dưới dạng phần mềm hướng cloud based. Bên cạnh đó còn tích cực đẩy mạnh việc cung cấp, kinh doanh các dịch vụ CNTT ra ngoài thị trường. Đây là mảng hứa hẹn nhiều tiềm năng nhưng cũng bị cạnh tranh gay gắt không kém các dịch vụ Viễn thông. Với vai trò kinh doanh các dịch vụ như vậy, Tập đoàn có hai phương thức để tạo các sản phẩm dịch vụ: tự phát triển hoặc mua để kinh doanh dịch vụ.

Cả hai phương thức này đều đặt ra yêu cầu kiểm định phần mềm chặt chẽ bởi việc kinh doanh các dịch vụ CNTT cũng giống như các dịch vụ Viễn thông, cần đảm bảo cam kết chất lượng phần mềm, dịch vụ tới khách hàng. Với những yêu cầu như vậy, cộng với xu thế các phần mềm, hệ thống được cung cấp dưới dạng cloud nêu yêu cầu kiểm định phần mềm cloud là một bài toán cần phải giải quyết ngay.

2. Đặc điểm khác biệt giữa phần mềm hướng cloud với các phần mềm truyền thống

Phần mềm hướng cloud có nhiều đặc điểm khác so với phần mềm và ứng dụng web truyền thống. Đây là phần mềm có kiến trúc multi-tenant (nhiều bên thuê) trong đó tất cả người dùng và các ứng dụng được chia sẻ trong một cơ sở hạ tầng và một nền code chung được duy trì tập trung. Đây là một điểm mạnh của phần mềm hướng cloud vì nó tiết kiệm được khá nhiều chi phí cho cả nhà cung cấp lẫn người sử dụng. Ngoài ra, nó còn thuận tiện trong việc triển khai trên diện rộng và dễ dàng trong việc sửa chữa, bảo trì, v.v... 

Tuy nhiên, bên cạnh những điểm mạnh thì phần mềm hướng cloud cũng ẩn chứa một  số rủi ro, nguy cơ do những đặc điểm kiến trúc phần mềm của mình. Một số rủi ro mà

các phần mềm hướng cloud thường gặp phải bao gồm: rủi ro về mặt hiệu năng, bảo mật, khả năng sẵn sàng hay khả năng bảo trì, v.v.... 

3.  Một số nguy cơ cần kiểm soát đối với phần mềm hướng cloud

Những nguy cơ liên quan đến hiệu năng là mục tiêu quan trọng trong một thời gian dài. Với điện toán đám mây, càng nhiều kết  nối được thực hiện trên Internet thì rủi ro về hiệu năng càng nhiều hơn.

 Khi nhiều hệ thống khác được sử dụng với sự trợ giúp của đám mây thì việc sử dụng internet có thể dẫn đến nguy cơ về hiệu năng đối với tất cả các quy trình nghiệp vụ. 

Một hướng quan trọng trong lựa chọn điện toán đám mây là khả  năng mở rộng của dịch vụ. Khi nhu cầu tăng thì năng lực của hệ thống tự động tăng một  cách nhanh chóng, sau đó khi nhu cầu giảm thì năng lực hệ thống cũng sẽ giảm đi. Đây chính là khả năng đàn hồi, một khía cạnh test riêng trong cloud.

 Những rủi ro xuất hiện đối với hiệu năng  cũng đi cùng với bảo mật: đây cũng chính là điều mà người quản lý kiểm thử luôn luôn quan tâm. Khi sử dụng đám mây có nghĩa là những nguy cơ về bảo mật phải được giải quyết một cách rõ ràng. Sự cố bảo mật có thể  dẫn đến thiệt hại ngay lập tức cho doanh nghiệp và có thể dẫn đến vi phạm pháp luật. Có rất nhiều các quy định về an toàn thông tin và bảo mật. 

Việc chia sẻ tài nguyên CNTT với các khách hàng khác cũng sẽ dẫn  đến các vấn đề an ninh. Trong tất cả các mô hình thực hiện điện toán đám mây thì sự nguy hiểm nhất là một nhân viên không được quyền nhưng lại truy cập được vào các dữ liệu nhạy cảm.

 Đây chính là vấn đề cần phải được kiểm soát. Một đặc điểm quan trọng  khác của các dịch vụ trên đám mây là việc không khóa Internet, thông qua các dịch vụ có thể thu được ở khắp mọi nơi và trên tất cả các loại nền tảng. 

Hiện nay có một xu hướng mới, đó là nhân viên sử dụng các thiết bị của mình để làm việc. Mọi người thường làm việc ở nhiều địa điểm khác nhau, hầu hết là ngoài văn phòng và sử dụng thiết bị riêng của mình. Điều này dẫn đến một lỗ hổng mới. Vậy làm thế nào để giữ an toàn cho các thiết bị và làm thế nào để người dùng sử dụng một cách an toàn. Đó cũng là điều mà các bài kiểm thử cần phải đưa ra để kiểm tra. Rủi ro về tính sẵn sàng và liên tục ảnh hưởng trực tiếp ngay đến quá trình kinh doanh của người sử dụng. 

Một số vấn đề có thể xảy ra như mất kết nối Internet, một thiết bị bị lỗi trong dịch vụ riêng của mình, hoặc không truy cập được vào dữ liệu công ty. Việc phân tích rủi ro sẽ đánh giá được những  gián đoạn có thể xảy ra và lường trước được hậu quả của nó. 

Tùy thuộc vào nguy cơ để đưa ra các phương pháp kiểm thử  nhằm làm giảm nhẹ các rủi ro đó.

 4. Các khía cạnh kiểm thử của phần mềm hướng cloud

- Kiểm thử bảo mật

Mục đích: nhằm đảm bảo hệ thống phòng chống được các sự tấn công từ bên ngoài, đảm bảo an ninh dữ liệu của các bên thuê. 

Bao gồm : 

Đánh giá bảo mật mạng Kiểm tra bảo mật thông tin khách hàng Kiểm thử khả năng mã hóa Kiểm thử khả năng xác thực Kiểm thử khả năng ủy quyền Kiểm thử bảo mật chống lại những tấn công từ Internet. Kiểm thử những bản vá bảo mật 

- Kiểm thử hiệu năng

Mục đích: nhằm kiểm tra hiệu suất hoạt động, phản ứng của hệ thống trong các trường hợp tải khác nhau, trường hợp quá tải cũng như khi hệ thống sử dụng tải lớn trong một thời gian đủ dài. 

Bao gồm :

+ Kiểm thử tải (Load test)

+ Kiểm thử quá tải (Stress test),

 + Kiểm thử độ bền hoặc kiểm thử khối lượng, 

 + Kiểm thử tính mềm dẻo và khả năng mở rộng 

-  Kiểm thử chức năng

Mục đích: nhằm đảm bảo các quy trình nghiệp vụ được thực hiện chuẩn xác, có thể cấu hình theo từng bên thuê.

- Kiểm thử tương thích

Mục đích: nhằm bảo đảm khả năng tương thích của ứng dụng với các mục tiêu khác nhau như trình duyệt web, các nền tảng phần cứng, người dùng (ngôn ngữ, vùng miền khác nhau) hay hệ điều hành, v.v...) 

Bao gồm : 

+ Kiểm thử khả năng tương thích của dịch vụ với các quy tŕnh nghiệp vụ
+ Kiểm thử tính tương thích với các trình duyệt
+ Kiểm thử tính tương thích với các hệ điều hành khác nhau
+ Kiểm thử khả năng nội địa hoá (Localization)
+ Kiểm thử khả năng quốc tế hoá (Internationalization testing)
+ Kiểm thử khả năng tương thích ngược về mặt giao diện

- Kiểm thử Live

Mục đích: Mục đích của kiểm thử live nhằm đảm bảo ứng dụng được test trong một môi trường thực sự. Có hai loại kiểm thử live cần được quan tâm là: 

 Kiểm thử khả năng phục hồi sau thảm hoạ và Kiểm thử khả năng nâng cấp trực tuyến

- Kiểm thử tính sẵn sàng và liên tục 

Gồm : 

Kiểm thử độ tin cậy của phần cứng
Kiểm thử độ tin cậy của phần mềm
Kiểm tra kết nối internet
Kiểm thử dự phòng

5. Kết Luận 

Từ những phân tích rủi ro và các khía cạnh kiểm thử cho phần mềm hướng cloud, chúng tôi đưa ra khung để đánh giá, kiểm tra nhằm xác định các bài kiểm thử cụ thể cho từng phần mềm với đặc điểm riêng của nó

(sưu tầm) 
---------------------------------------------------------------------------------------------------

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

Chú ý nho nhỏ cho những người lười đọc như mình :  Nếu bạn thuộc típ người lười đọc nhiều chữ, củm thấy hoa mắt chóng mặt vì phải tìm những ý chính trong búa lua xua chữ thì các bạn đọc những dòng chữ màu xanh nhé :)) .  Màu đen lướt qua là được rồi nhưng dù gì cũng khuyến khích đọc hết ;)) nếu đã lở tay mở trang này ra 

Xem Chi tiết

Lợi ích khi sử dụng CMMI

Tiếp theo bài 1 - Tìm hiểu CMMI trong kiểm thử phần mềm  , bài 2 - Lợi ích khi sử dụng CMMI 

I. Những lợi ích của CMMI

The CMMI Product Suite is at the forefront of process improvement because it provides the latest best practices for product and service development and maintenance.                 Cải tiến năng lực của các tổ chức phần mềm bằng cách nâng cao kiến thức và kỹ năng của lực lượng lao động.

            Đảm bảo rằng năng lực phát triển phần mềm  là thuộc tính của tổ chức không phải của một vài cá thể.

            Hướng các động lực của cá nhân với mục tiêu tổ chức.

            Duy trì tài sản con người, duy trì nguồn nhân lực chủ chốt trong tổ chức.

Lợi ích CMM mang lại cho Doanh nghiệp gói gọn trong  4 từ: Attract, Develop, Motivate và Organize.

1) Đối với doanh nghiệp: 

Có thêm những quyết định rõ ràng, dứt khoát trong việc quản lý và hoạt động cho các đối tượng
kinh doanh.

Giải thích về phạm vi và tầm nhìn trong vòng đời phát triển của phần mềm, cũng như các hoạt động nhằm đảm bảo sản phẩm hoặc dịch vụ đáp ứng được nhu cầu của khách hàng.

Kết hợp những gì đã có được và cộng thêm vào những thực hành tốt nhất. Ví dụ: như cách đo

lường, quản lý mạo hiểm, quản lý cung cấp.

Thực hiện thêm đầy đủ và thuần thục với cách thức làm việc.

Thêm vào chức năng nhận phê bình từ sản phẩm và dịch vụ của công ty.

Thêm vào những điều tuân theo chuẩn ISO.

2) Đối với người quản lý/thực hiện:

Hiểu được ai là người quan trọng và chia sẻ các  thông tin, phạm vi, yêu cầu của dự án.

Di chuyển từ sự không cần đồng ý đến việc dàn xếp dựa trên tác động.

Quản lý sau sửa chữa tới đo lường tiêu điểm, thêm những quản lý tiên phong thực hiện xuyên suốt chương trình.

Quản lý rủi ro sử dụng trong hệ thống và rèn luyện kỹ năng phần mềm.

Quản lý tập trung được chuyển từ “giao tiếp là bước thường lệ trong quy trình” sang “giao tiếp là cần thiết để giữ cho quy trình hoạt động” Lợi ích khi sử dụng CMMI
Đối với người quản lý cấp cao:

Tập trung vào yêu cầu như là một phần cơ bản của việc lên kế hoạch và thay đổi.

Các thông tin sớm về rủi ro và vấn đề của dự án.

Bớt sự chữa cháy

Bớt sự nhận định thiếu đầy đủ trong phân tích va chạm.

Bớt thỏa mãn về sự chữa cháy và ngăn ngừa hành động đó.

Giảm bớt những phàn nàn từ khách hàng không hài lòng với hệ thống.

Bớt đi những vận chuyển trong việc “cho đến khi vấn đề được giải quyết”

Thêm năng lực quản lý kế hoạch hệ thống và ngân sách thực hiện.

3) Đối với người lao động :

Lợi ích CMM mang lại cho người lao động:

  - Môi trường làm việc, văn hóa làm việc tốt hơn.

  - Vạch rõ vai trò và trách nhiệm của từng vị trí công việc.

  - Đánh giá đúng năng lực, công nhận thành tích.

  - Chiến lược, chính sách đãi ngộ luôn được quan tâm.

  - Có cơ hội thăng tiến.

  - Liên tục phát triển các kỹ năng cốt yếu.

II. Khác biệt giữa ISO 9001:2000 và CMM/CMMI?

•  ISO 9001 là một tiêu chuẩn quốc tế về quản lý, các điều khoản gọi là “yêu cầu” quy định những điểm cần phải làm (what to do), không chỉ ra việc đó nên làm như thế nào (how to do).

•  CMM/CMMi là một mô hình, cung cấp các hướng dẫn và kinh nghiệm thực tế dùng để phát triển, cải tiến và đánh giá năng lực của quy trình.

•  CMMi không phải là một tiêu chuẩn, tùy vào từng tổ chức, cách thực hiện khác nhau rất nhiều.

•  Về nguyên tắc, ISO bao gồm (ở mức cao) hầu hết các quy trình chủ chốt của CMM/CMMi, tuy nhiên ISO được dùng cho hầu hết mọi ngành nghề, do vậy không cụ thể và gần gũi với công việc đặc thù có liên quan đến phần mềm như CMM/CMMi. ISO không cung cấp các ví dụ và kinh nghiêm cụ thể như CMM/CMMi

III. KẾT LUẬN 

            Thứ nhất phải khẳng định CMM là bước phát triển tất yếu của các tổ chức trong thời đại kinh tế tri thức, bởi vì nó là việc kết hợp qui chuẩn và sáng tạo cho cách hoạt động của tổ chức, không cứng nhắc mà linh hoạt thay đổi theo thực tế. Mô hình về tiến hoá của tổ chức khẳng định điều này. Chúng ta cũng hiểu được vì sao bất kì thời đại, nền văn minh nào cũng có thời kì huy hoàng rồi bị sa sút và diệt vong. Mọi tổ chức không thực hiện việc đổi mới, đưa hiểu biết mới của các lớp trẻ vào, tất yếu sẽ bị diệt vong, đây là điều các cấp lãnh đạo cần nhận rõ. Ngày xưa diệt vong của từng triều đại là hàng trăm năm. Ngày nay sự diệt vong của các tổ chức chỉ là hàng chục năm hoặc chưa đến thế.

            Nếu đó đã là qui luật chung thì các tổ chức của Việt Nam cũng không ngoại lệ. Do đó càng đưa sớm CMM vào thực tế càng tốt và thúc đẩy sự phát triển ở Việt Nam. Nhưng điều thứ hai cần khẳng định là chỉ có thể thực hiện được CMM nếu đấy là nỗ lực của toàn tổ chức, và trong đó cam kết của lãnh đạo là quyết định. Vì vậy việc huấn luyện về CMM phải là huấn luyện cho toàn tổ chức, không phải chỉ là huấn luyện cho đội ngũ kĩ thuật, tuy rằng ban đầu chúng ta vẫn phải xuất phát từ phía kĩ thuật. Các cấp lãnh đạo, có quyền lực cần được học về CMM theo góc độ bảo đảm sự phát triển tiến hoá của tổ chức.

            Và thứ ba, chúng ta cần có được một đội ngũ những người am hiểu về CMM để giới thiệu cho nhiều tổ chức thực hiện. Đội ngũ này phải có khả năng dạy cho mọi loại người trong tổ chức, không chỉ cho các chuyên viên kĩ thuật, người đã sẵn sàng học cái mới. Chúng ta phải đủ khả năng để đối diện với mọi cấp lãnh đạo và cung cấp cho họ những tri thức mới về cách làm việc mới, nhưng phải biết nói theo ngôn ngữ của họ.

Nói chung mình hơi chán đọc lý thuyết suông - chỉ khi nào đi phỏng vấn mới " nghía " qua xíu . Thế nhưng biết được một số mô hình - biết được quy trình của một số công ty lớn để lựa chọn . 

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

------------------

Xem Chi tiết

TÌM HIỂU MÔ HÌNH CMMI TRONG KIỂM THỬ PHẦN MỀM

1) CMMI là gì?

CMMI viết tắt cho Capability Maturity Model Integration - Mô hình trưởng thành năng lực tích hợp - và là khuôn khổ cho cải tiến qui trình phần mềm. Nó dựa trên khái niệm về các thực hành tốt nhất về kĩ nghệ phần mềm và giải thích kỉ luật mà các công ty có thể dùng để cải tiến  tối ưu hóa quy trình phát triển phần mềm và là mô hình gồm nhiều mô hình CMM đơn lẻ 

Như vậy, CMM là khung tiêu chuẩn để đảm bảo sản phẩm làm ra đạt chất lượng. (tương tự tiêu chuẩn ISO ở các lĩnh vực khác). Mô tả các thành phần chính yếu của 1 quá trình phát triển phần mềm hiệu quả. Khi tuân thủ tiêu chuẩn này sẽ làm đơn vị phát triển phần mềm đặt các mục tiêu về chi phí, thời gian, đảm bảo chức năng và chất lượng sản phẩm.

2) Mục đích sử dụng 

Các công ty thương mại và chính phủ sử dụng mô hình CMMI để hỗ trợ viêc xác định cải tiến quy trình để xây dựng hệ thống, xây dựng phần mềm và phát triển quy trình và sản phẩm tích hợp.

            Công ty sử dụng quy trình này để phát triển, thu thập và duy trì các sản phẩm và dịch vụ và để làm chuẩn cho chính họ chống lại các công ty khác. Các quy trình tốt hơn cũng có thể là những quy trình có giá rẻ hơn và kết quả chất lượng tốt hơn, cũng như là những quy trình này ước tính thời gian thực cho dự án chính xác hơn.

Như vậy , CMMI được sử dụng với các mục đích chính sau: 

- Cải tiến quy trình, nâng cao năng suất, chất lượng sản phẩm, nâng cao lợi nhuận

- Cải thiện khả năng quản lý và giải quyết vấn đề, rủi ro

- Đảm bảo tính ổn định cho các hoạt động và sự phát triển của tổ chức

3) 5 Cấp độ của CMMI 

3.1) CMMI Level 1: (Initial) 

- Khởi đầu (lộn xộn, không theo chuẩn): đây là điểm khởi đầu để sử dụng một quy trình mới.

Level 1 là bước khởi đầu của CMMI,  mọi doanh nghiệp, công ty phần mềm, cá nhóm, cá nhân đều có thể đạt được. Ở lever này CMMI chưa yêu cầu bất kỳ tính năng nào. Ví dụ: không yêu cầu quy trình, không yêu cầu con người, miễn là cá nhân, nhóm, doanh nghiệp… đều làm về phần mềm đều có thể đạt tới mức này 

- Đặc điểm 

Hành chính: Các hoạt động của lực lượng lao động được quan tâm hàng đầu nhưng được thực hiện một cách vỗi vã hấp tấp.

Không thống nhất: Đào tạo quản lý nhân lực nhỏ lẻ chủ yếu dựa vào kinh nghiệp cá nhân.

Quy trách nhiệm: Người quản lý mong bộ phận nhân sự điều hành và kiểm sóat các hoạt động của lực lượng lao động.

Quan liêu: Các hoạt động của lực lượng lao động được đáp ứng ngay mà không cần phân tích ảnh hưởng.

Doanh số thường xuyên thay đổi: Nhân viên không trung thành với tổ chức.

3.2) CMMI Level 2- Managed

Là cấp độ tiếp theo sau level 1, tại level này quy trình đánh giá và phân tích được áp dụng trong quá trình phát triển phần mềm. Đặc điểm:

- Đã có quy trình quản lý yêu cầu, quản lý tiến độ, quản lý sản phẩm và dịch vụ

- Đã có các mốc cho từng trạng thái của sản phẩm, các mốc bàn giao sản phẩm, dịch vụ

- Đã thiết lập và xem xét những ràng buộc giữa các bên liên quan

- Sản phẩm được xem xét bởi tất cả các bên liên quan và phải được kiểm soát

- Sản phẩm hoặc dịch vụ, kết quả của quá trình phải triển phải thỏa mãn được yêu cầu, tiêu chuẩn…

3.3) Level 3- Defined:

Xác lập (thể chế hóa): Quy trình này được xác lập/ xác nhận như một quy trình doanh nghiệp tiêu chuẩn.

Là cấp độ mà tại đó ngoài các quy trình được áp dụng ở level 2 còn có thêm các quy trình khác như: phát triển yêu cầu, giải pháp kỹ thuật, tích hợp hệ thống, kiểm định, phê duyệt, quản lý rủi ro và phân tích quyết định. 

Đặc điểm:

- Tiêu chuẩn, quy trình, thủ tục trong dự án được biến đỏi để phù hợp với quy trình tiêu chuẩn của mỗi dự án đặc thù hoặc cho mỗi phần của tổ chức

- Các quy trình được định nghĩa chi tiết và khắt khe hơn so với level 2

- Quy trình được quản lý một cách chủ động hơn

- Quy trình chỉ được quản lý theo phỏng đoán

Như vậy , Các vùng tiến trình chủ chốt ở mức 3 nhằm vào cả hai vấn đề về dự án và tổ chức, vì một tổ chức (công ty) tạo nên cấu trúc hạ tầng thể chế các quá trình quản lý và sản xuất phần mềm hiệu quả qua tất cả các dự án. Chúng ập trung Tiến trình Tổ chức (Organization Process Focus), Phân định Tiến trình Tổ chức (Organization Process Definition), Chương trình Đào tạo (Training Program), Quản trị Phần mềm Tích hợp (Integrated Software Management), Sản xuất Sản phẩm Phần mềm (Software Product Engineering), Phối hợp nhóm (Intergroup Coordination), và Xét duyệt ngang hàng (Peer Reviews).

3.4 Level 4- Quantitatively Managed

Kiểm soát (định lượng): Tiến hành kiểm soát và đo lường quy trình sản xuất phần mềm

Các vùng tiến trình chủ yếu ở mức 4 tập trung vào thiết lập hiểu biết định lượng của cả quá trình sản xuất phần mềm và các sản phẩm phần mềm đang được xây dựng. 

Đó là Quản lý quá trình định lượng (Quantitative Process Management) và Quản lý chất lượng phần mềm (Software Quality Management).

Để đạt được level 4 thì phải đo lường và chuẩn hóa. Đo lường hiệu quả đáp ứng công việc, chuẩn hóac phát triển các kỹ năng, năng lực cốt lõi.

Level 4 này sẽ chú trọng vào những người đứng đầu của một công ty, họ có khả năng quản lý các công việc như thế nào

3.5) Level 5- Optimizing:

Tối ưu (cải tiến quy trình): Kiểm soát quy trình bao gồm việc cân nhắc kỹ để cải tiến/ tối ưu hóa quy trình.

Các vùng tiến trình chủ yếu ở mức 5 bao trùm các vấn mà cả tổ chức và dự án phải nhắm tới để thực hiện hoàn thiện quá trình sản xuất phần mềm liên tục, đo đếm được. Đó là Phòng ngừa lỗi (Defect Prevention), Quản trị thay đổi công nghệ (Technology Change Management), và Quản trị thay đổi quá trình (Process Change Management) Để đạt được level 4 thì phải đo lường và chuẩn hóa. Đo lường hiệu quả đáp ứng công việc, chuẩn hóac phát triển các kỹ năng, năng lực cốt lõi.

Để đạt được Level 5 thì doanh nghiệp đó phải liên tục cải tiến hoạt động tổ chức, tìm kiếm các phương pháp đổi mới để nâng cao năng lực làm việc của lực lượng lao động trong tổ chức, hỗ trợ các nhân phát triển sở trường chuyên môn. 

Chú trọng vào việc quản lý, phát triển  năng lực của nhân viên.

Huấn luyện nhân viên trở thành các chuyên gia.

Xem thêm bài 2: Các lợi ích khi sử dụng CMMI Trong quy trình quản lý chất lượng phần mềm 

Xem Chi tiết

Giới thiệu Ad-Hoc Testing - Phương pháp kiểm thử phần mềm tùy hứng bạn nên thử

1) Ad - Hoc Testing là gì ?

Bạn kiểm thử phần mềm dựa theo kinh nghiệm hoặc " tùy hứng" - không theo một kế hoạch hoặc một tài liệu nào thì đó là bạn đang kiểm thử theo Ad-Hoc testing

2) Đặc điểm của kỷ thuật Ad-Hoc testing

- Ad-hoc testing là phương pháp kiểm thử phần mềm được thực hiện một cách rất ngẫu hứng, không theo bất kỳ một kế hoạch hay tài liệu nào. Và nó cũng dự định chỉ được chạy một lần, trừ khi có lỗi xảy ra.

=> Kiểm thử viên có thể tùy hứng, tha hồ test theo ý của mình, phán đoán các case hóng búa nhất, hay xảy ra lỗi nhất tuy nhiên không thể chắc chắn bao phủ hết các trường hợp và cũng không thể ghi nhớ hết các case mình đã test do đó rất khó để tái hiện lỗi. Tuy nhiên - ưu điểm của phương pháp kiểm thử này là nhanh chóng - không bị ràng buộc

 -Ad-hoc testing là phương pháp kiểm thử phần mềm ít chính thức nhất vì bị chỉ trích là không có cấu trúc, khó tái hiện lỗi vì không có test cases  và khó kiểm soát .

- Ad-hoc testing yêu cầu kiểm thử viên thực  hiện phải có kiến thức tốt về hệ thống, về ứng dụng đang test, vì bản thân cách kiểm thử này gần giống như là việc đoán lỗi. 

-  Ad-hoc testing được dùng nhiều nhất trong kiểm thử ứng dụng hoặc trò chơi. Bất cứ ứng dụng hay trò chơi nào cũng cần đến việc kiểm thử ngẫu nhiên nhằm đoán được đến mức tối đa hành vi của users mà test cases dù có viết kỹ thế nào cũng không thể lường được hết.

3. Cách tiếp cận Ad-hoc testing

Không có một định nghĩa hay cách tiếp cận chính xác nào cho Ad-hoc testing, vì đây là việc thực hiện kiểm thử một cách ngẫu hứng. Nó phụ thuộc vào kinh nghiệm, quan điểm, cách suy nghĩ của người thực hiện kiểm thử trước một hệ thống, một ứng dụng hay trò chơi. Các tester có kinh nghiệm có thể tìm ra nhiều khiếm khuyết của hệ thống thông qua Ad-hoc testing bởi họ hiểu được những scenario thông dụng và cái gì có thể gây ra lỗi cho hệ thống mà họ kiểm thử. Tuy nhiên, người muốn tìm hiểu về Ad-hoc testing cũng có thể tiếp cận nó qua những tóm tắt sau đây:

3.1 Tiếp cận Ad-Hoc testing bằng cách -Tìm kiếm nhóm khiếm khuyết

Nhóm khiếm khuyết là một khu vực trên hệ thống, nơi có khả năng xảy ra số lượng lỗi lớn nhất. Khi thực hiện Ad-hoc testing, tester có thể thử kịch bản xem có thể tìm thấy lỗi ở những khu vực khác nhau hay không. Có người có thể tìm ra nhóm khiếm khuyết bằng cách phân tích lịch sử kiểm thử bằng test case đã được thực hiện trước đó, cũng có người tìm ra bằng cách dự đoán nơi có khả năng xảy ra lỗi.

3.2 Chú ý Sự tác động qua lại giữa các bộ phận cấu thành

Sự tác động qua lại, ảnh hưởng lẫn nhau giữa các chức năng con trên hệ thống là một kịch bản thường thấy khi có lỗi xảy ra. Khi thực hiện Ad-hoc testing, tester có thể chỉ ra sự ảnh hưởng đó giữa các module với nhau, từ đó tìm ra những trạng thái bất bình thường của hệ thống.

3.3 Suy nghĩ như một developer

Khi thực hiện Ad-hoc testing, nếu suy nghĩ như một developer, nhìn vào hệ thống và thử nghĩ xem mình có thể làm gì, làm như thế nào khi phải phát triển chức năng này, và tester sẽ biết được liệu có phần nào của chức năng hoặc một yêu cầu nào đó đối với chức năng đó có bị thiếu không. Sau đó kiểm tra code và có thể sẽ tìm ra lỗi.

3.4 Phải hiểu rõ về hệ thống

Tester phải có sự hiểu biết thật rõ về hệ thống để đảm bảo người đó có thể nghĩ ra và thử nhiều kịch bản khác nhau đối với hệ thống. Ad-hoc testing yêu cầu càng nhiều kịch bản càng tốt, và càng thực hiện được nhiều kịch bản thì khả năng tìm ra lỗi càng cao.

3.5 Kinh nghiệm của bản thân tester

Trong Ad-hoc testing, tester có kinh nghiệm bao giờ cũng tìm ra được nhiều lỗi hơn là người mới vì người đó đã từng test nhiều hệ thống khác nhau, cũng có thể là đã test những hệ thống tương tự nên thu thập được kinh nghiệm và sự hiểu biết để thực hiện Ad-hoc testing. Ghi chú, góp nhặt là phương pháp tốt để tích lũy kinh nghiệm

3.6 Test theo session

Hãy kiểm thử ứng dụng hay một phần mềm theo từng phần, tức là mỗi lần chỉ test một chức năng, nó sẽ giúp cho tester có thể chú trọng và lý giải được những vấn đề xảy ra (nếu có).

3.7 Học cách sử dụng những công cụ khác

Hiện nay có một số công cụ giúp tìm ra khiếm khuyết như công cụ debug, profilers hay task monitors, vì vậy học cách sử dụng những công cụ này có thể khiến cho vấn đề trở nên đơn giản hơn rất nhiều.

3.8 Ghi lại những gì đã tìm được

Hãy ghi lại những lỗi, khiếm khuyết mà mình tìm ta được, ghi rõ cả chức năng, khi nào thì lỗi xảy ra…Những record này sẽ giúp cho developer và cả tester trong tương lai khi họ phát triển những hệ thống hoặc ứng dụng khác. Cũng nên ghi lại những lỗi do người khác tìm ra chứ không phải mình tìm ra, để có cơ sở tham khảo về sau.

4. Kết luận:

Mặc dù thực hiện Ah-hoc testing là hoàn toàn ngẫu hứng nhưng người thực hiện cần phải có đủ kiến thức cũng như kinh nghiệm để phán đoán các kịch bản khác nhau có thể xảy ra với hệ thống hoặc ứng dụng, hoặc game đang cần test. Người thực hiện test cũng cần phải có hiểu biết chính xác và sâu sắc về đối tượng đang test để biết trường hợp nào là lỗi, khiếm khuyết do developer, do hành vi của người dùng, trường hợp nào là hạn chế của hệ thống (không thể khắc phục)…để có phương án cải thiện. 

(st)

Xem Chi tiết

CÁC LOẠI KIỂM THỬ HỌP ĐEN MÀ BẠN CẦN PHẢI BIẾT RÕ

Tiếp theo phần 1 trong topic học kiểm thử phần mềm  -bài  Tổng quan về Kiểm thử hợp đen và ưu nhược điểm. Sang phần 2, chúng ta sẽ cùng tìm hiểu các loại kiểm thử họp đen nhé

2. Các loại kiểm thử phần mềm hợp đen mà bạn cần phải biết  

2.1.   Kiểm thử tích hợp là gì?

            Integration test (kiểm thử tích hợp ) là  kết hợp các thành phần của một ứng dụng và kiểm thử như một ứng dụng đã hoàn thành. Trong khi Unit Test kiểm tra các thành phần và Unit riêng lẻ thì Intgration Test kết hợp chúng lại với nhau và kiểm tra sự giao tiếp giữa chúng.

Hai mục tiêu chính của Integration Test:
 

·         Phát hiện lỗi giao tiếp xảy ra giữa các Unit.

·         Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ (Subsystem) và cuối cùng là nguyên hệ thống hoàn chỉnh (System) chuẩn bị cho kiểm thử ở mức hệ thống (System Test).

            Trong Unit Test, lập trình viên cố gắng phát hiện lỗi liên quan đến chức năng và cấu trúc nội tại của Unit. Có một số phép kiểm thử đơn giản trên giao tiếp giữa Unit với các thành phần liên quan khác, tuy nhiên mọi giao tiếp liên quan đến Unit chỉ thật sự được kiểm tra đầy đủ khi các Unit tích hợp với nhau trong khi thực hiện Integration Test.

            Trừ một số ít ngoại lệ, Integration Test chỉ nên thực hiện trên những Unit đã được kiểm tra cẩn thận trước đó bằng Unit Test, và tất cả các lỗi mức Unit đã được sửa chữa. Một số người hiểu sai rằng Unit một khi đã qua giai đoạn Unit Test với các giao tiếp giả lập thì không cần phải thực hiện Integration Test nữa. Thực tế việc tích hợp giữa các Unit dẫn đến những tình huống hoàn toàn khác.

Một chiến lược cần quan tâm trong Integration Test là nên tích hợp dần từng Unit. Một Unit tại một thời điểm được tích hợp vào một nhóm các Unit khác đã tích hợp trước đó và đã hoàn tất các đợt Integration Test trước đó. Lúc này, ta chỉ cần kiểm thử giao tiếp của Unit mới thêm vào với hệ thống các Unit đã tích hợp trước đó, điều này sẽ làm cho số lượng can kiểm thử giảm đi rất nhiều, và sai sót sẽ giảm đáng kể.

Có 3 loại kiểm thử hộp đen trong Integration Test:

·         Kiểm thử chức năng (Functional Test): Tương tự Black Box Test, kiểm thử chức năng chỉ chú trọng đến chức năng của chương trình, mà không quan tâm đến cấu trúc bên trong, chỉ khảo sát chức năng của chương trình theo yêu cầu kỹ thuật.

·         Kiểm thử hiệu năng (Performance Test): Kiểm thử việc vận hành của hệ thống.
·         Kiểm thử khả năng chịu tải (Stress Test): Kiểm thử các giới hạn của hệ thống.

2.2.   Kiểm thử hệ thống là gì ?

            Mục đích System Test ( kiểm thử hệ thống) là kiểm thử thiết kế và toàn bộ hệ thống (sau khi tích hợp) có thỏa mãn yêu cầu đặt ra hay không.

            System Test bắt đầu khi tất cả các bộ phận của phần mềm đã được tích hợp thành công. Thông thường loại kiểm thử này tốn rất nhiều công sức và thời gian. Trong nhiều trường hợp, việc kiểm thử đòi hỏi một số thiết bị phụ trợ, phần mềm hoặc phần cứng đặc thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân bố, hoặc hệ thống nhúng. Ở mức độ hệ thống, người kiểm thử cũng tìm kiếm các lỗi, nhưng trọng tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầu khác liên quan đến chất lượng của toàn hệ thống.

            Điểm khác nhau then chốt giữa Integration Test (kiểm thử tích hợp )  và System Test ( kiểm thử hệ thống)  là System Test chú trọng các hành vi và lỗi trên toàn hệ thống, còn Integration Test chú trọng sự giao tiếp giữa các đơn thể hoặc đối tượng khi chúng làm việc cùng nhau. 

Thông thường ta phải thực hiện Unit Test và Integration Test để bảo đảm mọi Unit và sự tương tác giữa chúng hoạt động chính xác trước khi thực hiện System Test.

            Sau khi hoàn thành Integration Test, một hệ thống phần mềm đã được hình thành cùng với các thành phần đã được kiểm tra đầy đủ. Tại thời điểm này, lập trình viên hoặc kiểm thử viên bắt đầu kiểm thử phần mềm như một hệ thống hoàn chỉnh. Việc lập kế hoạch cho System Test nên bắt đầu từ giai đoạn hình thành và phân tích các yêu cầu.

            System Test kiểm thử cả các hành vi chức năng của phần mềm lẫn các yêu cầu về chất lượng như độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật. Mức kiểm thử này đặc biệt thích hợp cho việc phát hiện lỗi giao tiếp với phần mềm hoặc phần cứng bên ngoài, chẳng hạn các lỗi "tắc nghẽn" (deadlock) hoặc chiếm dụng bộ nhớ. Sau giai đoạn System Test, phần mềm thường đã sẵn sàng cho khách hàng hoặc người dùng cuối cùng kiểm thử chấp nhận sản phẩm (Acceptance Test) hoặc dùng thử (Alpha/Beta Test).

            Đòi hỏi nhiều công sức, thời gian và tính chính xác, khách quan, System Test thường được thực hiện bởi một nhóm kiểm thử viên hoàn toàn độc lập với nhóm phát triển dự án. Bản thân System Test lại gồm nhiều loại kiểm thử khác nhau, phổ biến nhất gồm:

·         Kiểm thử chức năng (Functional Test): Bảo đảm các hành vi của hệ thống thỏa mãn đúng yêu cầu thiết kế dựa trên use case hoặc tính năng nghiệp vụ và nguyên tắc nghiệp vụ
·         Kiểm thử hiệu năng (Performance Test): Bảo đảm tối ưu việc phân bổ tài nguyên hệ thống (ví dụ bộ nhớ) nhằm đạt các chỉ tiêu như thời gian xử lý hay đáp ứng câu truy vấn...
·         Kiểm thử khả năng chịu tải (Stress Test hay Load Test): Bảo đảm hệ thống vận hành đúng dưới áp lực cao (ví dụ nhiều người truy xuất cùng lúc). Stress Test tập trung vào các trạng thái tới hạn, các "điểm chết", các tình huống bất thường như đang giao dịch thì ngắt kết nối (xuất hiện nhiều trong kiểm tra thiết bị như POS, ATM...)...
·         Kiểm thử cấu hình (Configuration Test).
·         Kiểm thử bảo mật (Security Test): Bảo đảm tính toàn vẹn, bảo mật của dữ liệu và của hệ thống.
·         Kiểm thử khả năng phục hồi (Recovery Test): Bảo đảm hệ thống có khả năng khôi phục trạng thái ổn định trước đó trong tình huống mất tài nguyên hoặc dữ liệu; đặc biệt quan trọng đối với các hệ thống giao dịch như ngân hàng trực tuyến...

            Nhìn từ quan điểm người dùng, các cấp độ kiểm thử trên rất quan trọng: Chúng bảo đảm hệ thống đủ khả năng làm việc trong môi trường thực.

            Lưu ý là không nhất thiết phải thực hiện tất cả các loại kiểm thử nêu trên. Tùy yêu cầu và đặc trưng của từng hệ thống, tuỳ khả năng và thời gian cho phép của dự án, khi lập kế hoạch, người Quản lý dự án sẽ quyết định áp dụng những loại kiểm thử nào.

Xem Chi tiết

MÁCH BẠN ƯU NHƯỢC ĐIỂM CỦA KIỂM THỬ HỌP ĐEN VÀ CÁC PHƯƠNG PHÁP KIỂM THỬ HỌP ĐEN

1.    Tổng quan về kỹ thuật test hộp đen

            Trong quy trình kiểm thử phần mềm sử dụng chiến lược kiểm thử hộp đen gồm kiểm thử tích hợp và kiểm thử hệ thống.

            Vậy kiểm thử hợp đen trong kiểm thử phần mềm là gì và mục đích của Kiểm thử họp đen ?

Một trong những chiến lược kiểm thử quan trọng là kiểm thử hộp đen, hướng dữ liệu, hay hướng vào/ra. Kiểm thử hộp đen xem chương trình như là một “hộp đen”. 

Mục đích của bạn là hoàn toàn không quan tâm về cách cư xử và cấu trúc bên trong của chương trình. Thay vào đó, tập trung vào tìm các trường hợp mà chương trình không thực hiện theo các đặc tả của nó.

Theo hướng tiếp cận này, dữ liệu kiểm tra được lấy chỉ từ các đặc tả.

1.1.   Các phương pháp kiểm thử hộp đen

·         Phân lớp tương đương – Equivalence partitioning.

·         Phân tích giá trị biên – Boundary value analysis.

·         Kiểm thử mọi cặp – All-pairs testing.

·         Kiểm thử fuzz – Fuzz testing.

·         Kiểm thử dựa trên mô hình – Model-based testing.

·         Ma trận dấu vết – Traceability matrix.

·         Kiểm thử thăm dò – Exploratory testing.

·         Kiểm thử dựa trên đặc tả – Specification-base testing.

            Kiểm thử dựa trên đặc tả tập trung vào kiểm tra tính thiết thực của phần mềm theo những yêu cầu thích hợp. Do đó, kiểm thử viên nhập dữ liệu vào, và chỉ thấy dữ liệu ra từ đối tượng kiểm thử. Mức kiểm thử này thường yêu cầu các ca kiểm thử triệt để được cung cấp cho kiểm thử viên mà khi đó có thể xác minh là đối với dữ liệu đầu vào đã cho, giá trị đầu ra (hay cách thức hoạt động) có giống với giá trị mong muốn đã được xác định trong ca kiểm thử đó hay không. Kiểm thử dựa trên đặc tả là cần thiết, nhưng không đủ để để ngăn chặn những rủi ro chắc chắn.

1.2.   Ưu, nhược điểm của kiểm thử họp đen

            Kiểm thử hộp đen không có mối liên quan nào tới mã lệnh, và kiểm thử viên chỉ rất đơn giản tâm niệm là: một mã lệnh phải có lỗi. Sử dụng nguyên tắc “ Hãy đòi hỏi và bạn sẽ được nhận”, những kiểm thử viên hộp đen tìm ra lỗi mà những lập trình viên đã không tìm ra. 

Nhưng, mặt khác, người ta cũng nói kiểm thử hộp đen “giống như là đi trong bóng tối mà không có đèn vậy”, bởi vì kiểm thử viên không biết các phần mềm được kiểm tra thực sự được xây dựng như thế nào. Đó là lý do mà có nhiều trường hợp mà một kiểm thử viên hộp đen viết rất nhiều ca kiểm thử để kiểm tra một thứ gì đó mà đáng lẽ có thể chỉ cần kiểm tra bằng 1 ca kiểm thử duy nhất, và/hoặc một số phần của chương trình không được kiểm tra chút nào.

            Do vậy, kiểm thử hộp đen có ưu điểm của “một sự đánh giá khách quan”, mặt khác nó lại có nhược điểm của “thăm dò mù”.

Xem thêm, Các loại kiểm thử phần mềm  họp đen 

Xem Chi tiết

Việc biết nhiều về UI/UX sẽ có lợi như thế nào cho công việc kiểm thử ??

Hôm nay , topic " chia sẻ kinh nghiệm, thủ thuật về kiểm thử phần mềm " của blog Học kiểm thử phần mềm tự động sẽ cùng tìm hiểu về những vấn đề liên quan đến UX, UI.

Các bạn thân mến, nếu như với một  Designer -Vấn đề UI là vấn đề cốt lỗi. Việc design một giao diện Website đẹp, bắt mắt ,thân thiện, dễ sử dụng là vô cùng quan trọng thì đối với 1 tester - nhìn, nhận xét , đánh giá ," soi mói"  và tìm lỗi thì vấn đề UI cũng là một vấn đề cốt lỗi của các member chuyên vạch lá tìm sâu đó nhé. 

Tương tự vậy, đối với các Developer , việc tạo ra sản phẩm với UX , UI hài hòa, chuyên nghiệp , thu hút người dùng là công việc thường nhật  thì đối với 1 Tester, công việc thường nhật cũng chỉ là việc tìm bug trong quá trình sử dụng và nói lên cái bất hợp lý nếu có trong quá trình thiết kế.

Vậy làm thế nào để có những testcase " thần thánh" , độc lạ nhưng hợp tình hợp lý, không gây " chia rẻ " nội bộ và " thù hằn" dân tộc thì việc Tìm hiểu UX, UI là việc cần thiết và cấp bách nhất !

1) Kiểm thử viên phần mềm (Tester) chỉ việc test theo yêu cầu có sẵng có  cần quan tâm đến UX/UI hay không?

Bạn là người kiểm thử phần mềm - là đại diện cho người sử dụng , mục đích cuối cùng cũng là hướng tới điều tốt nhất, hài lòng nhất cho người sử dụng , Bạn cảm thấy khó khăn khi sử dụng thì chắc chắn, người dùng - hoàn toàn xa lạ với ứng dụng của bạn cũng có cảm giác như thế.

Ví dụ nhé : Từ facebook cho đến google, menu icon trong ứng dụng mobile thường để biểu tượng 

, thường nằm ở header , góc bên trái hoặc bên phải . Đột nhiên ứng dụng của bạn , Menu là 1 icon của Exit hoặc 1 biểu tượng khác, nằm ở body của ứng dụng mỗi khi click vô trang nào đó, làm người dùng bối rối và dễ gây hiểu lầm, đương nhiên sẽ không tốt. Designer ... có cái lý riêng của họ , muốn độc đáo , khác lạ chẳng hạn hoặc khách hàng muốn thế và họ chỉ việc làm theo trong khi khách hàng. 

Còn developer  là người code từng dòng của product đó, dĩ nhiên sử dụng được tốt. Nhưng nếu cho 1 user ở bên ngoài vào thử, mọi chuyện sẽ hoàn toàn khác. Vậy đó, tester là người đánh giá sản phẩm, có thể nói lên cảm nhận của mình ở khía cạnh người dùng về sản phẩm, có thể góp ý điều hướng như thế nào cho hợp lý nhất. 

Bản thân mình cũng từng gặp một số ứng dụng, Client gửi Design bị sai so với đặc tả trong tài liệu , mà Coder thì làm theo design nên dẫn đến việc sản phẩm cuối cùng sắp lên thớt , sau khi đưa QC test và feedback với Client vẫn phải thay đổi lại design cho phù hợp 

Vậy câu trả lời cho câu hỏi " QC/Tester có cần phải quan tâm UX, UI không?" đã có câu trả lời rồi đó . Không làm ra sản phẩm nhưng để nhận xét, đánh giá đúng sản phẩm phải có kiến thức về nó . Kiến thức đó là sự tích lũy của những kinh nghiệm từ các sản phẩm đã làm, đang làm và sẽ làm , đang vọc phá, đã vọc phá và dự định sẽ vọc phá , những thói quen cá nhân cho 1 sản phẩm  cũng phải được chú ý  .... Đó là nguyên tắc của 1 tester 

2)  Không biết về UX/UI  sẽ ảnh hưởng như thế nào đối với công việc kiểm thử phần mềm

- Bạn sẽ dễ dàng bỏ qua những sai sót nhỏ chẳng hạn màu sắc, tỉ lệ giữa các element ...

- Bạn sẽ không hiểu ý đồ và không có cái nhìn tổng quan cho từng phần trong thiết kế

- Bạn sẽ cảm thấy - miễn chạy tốt chức năng , có thể chấp nhận việc tùy biến design hoặc tùy biến chức năng , dẫn đến việc sản phẩm cuối cùng không giống như đặc tả mà chỉ hao hao giống ...

- Bộ testcase của bạn sẽ nghèo nàn nếu không hiểu được thói quen người dùng cho từng chức năng của giao diện đó .

Một ví dụ rất hay xảy ra là khi các bạn designer làm xong phần design, đưa cho coder thì bạn coder hay comment là design như thế này khó quá, không thể làm được và yêu cầu thay đổi design để code dễ hơn. 

Tuy nhiên, không phải cứ dễ code hơn là hay hơn. Vì bạn coder không hiểu về UI/UX nên không hiểu vì sao design nó cần như thế,  Và Tester lại thấy Coder làm như vậy là hợp lý, không quan tâm nhiều đến Design , gây ảnh hưởng đến sản phẩm cuối cùng.

3) Việc biết nhiều về UI/UX sẽ có lợi như thế nào cho 1 tester và công việc kiểm thử phần mềm và xây dựng bộ script cho kiểm thử phần mềm tự động 

Nó sẽ giúp bạn suy nghĩ theo hướng làm thế nào để user dễ sử dụng nhất, từ đó làm chủ sản phẩm.

và sẽ cho ra những testcase " thần thánh".Nhưng nên nhớ là đừng có " thần thánh " cao siêu , những  trường hợp kiểu thử vô lý và " không giống ai" nhé,  sẽ bị gạch đá và bị nguyền rủa không thương tiếc đó . Nên nhớ nghề Tester cũng là một trong số những nghề " nguy hiểm" ak . hehe

4) UI là gì ? 

 4.1. Định nghĩa UI : User Interface - Giao diện người dùng , UI là cái mà người dùng nhìn thấy.

Các nhà thiết kế website, nhà phát triển ứng dụng và kinh doanh thương mại điện tử dành nhiều quan tâm đến việc hiểu được yêu cầu của người dùng và thói quen của người dùng– chẳng hạn như họ muốn điều hướng như thế nào, menu yêu cầu có những gì – trước khi đi vào thiết kế UI cho ứng dụng của họ.
 Toàn bộ quá trình thu thập yêu cầu người dùng, đặt những yếu tố khác nhau của phần mềm và tạo ra một giao diện người dùng hiệu quả được gọi là thiết kế giao diện người dùng (UI design).

4.2. Nguyên tắc để đánh giá 1 UI tốt 

 - Biết đối tượng sử dụng sản phẩm của bạn  để họ thấy rõ ràng những thông điệp có sẵn phù hợp với họ 

- Mượn các hành vi, thói quen sử dụng quen thuộc của người sử dụng 

- Tính trực quan , ngắn gọn, dễ hiểu  

- Tập trung vào các vị trí tỷ lệ vàng, , tỉ lệ 1/3 ...Chúng ta thường bị thu hút bởi các khu vực chuyển động hơn là các khu vực tĩnh. Những thay đổi tại khu vực động sẽ được phát hiện dễ dàng. Các con trỏ văn bản là một ví dụ của một đối tượng hấp dẫn mắt. Thay đổi hình ảnh của nó có thể là những báo hiệu thay đổi trạng thái khác nhau và hữu ích.

 - Nguyên tắc ngữ pháp , sử dụng ngôn ngữ của người dùng 

- Hiểu được các trợ giúp mà người dùng cần

- Hãy để cho người dùng tự tin bằng cách tạo dựng một hệ thống an toàn

- Một số nguyên tắc khác 

Như vậy , UI càng đơn giản, gọn nhẹ  và làm nổi bật cái mà người dùng muốn ( mục đích sử dụng ) và cái mà người dùng cần cộng với phù hợp với thói quen người sử dụng thì đó là một UI tốt . Tất nhiên nếu tất cả các đều đó cộng thêm một chút " đẹp, hài hòa , lạ mắt" nữa thì quá tốt.

Thử nhìn lại một số giao diện đặc trưng cho mô tả trên nhé , tiêu biểu nhất là Trang web của gã khổng lồ Google.com. 

Ta có thể dễ dàng nhận ra, yêu tố đơn giản, dễ sử dụng mà google đã khai thác triệt để, ai cũng có thể sử dụng dễ dàng, chỉ là 1 ô tìm kiếm với nút search . Kết quả trả về cũng vô cùng rõ ràng, thân thiện .

5. UX là gì ?UX là cách người dùng sử dụng, các chức năng của chương trình đó  (User Experience)

( Click vào hình để xem rõ hơn ) 

---------------------

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

Xem Chi tiết