Kiểm tra tính di động – Portability testing là những kiểm tra liên quan đến mức độ mà một phần của phần mềm hoặc hệ thống có thể chuyển vào môi trường dự định (ban đầu hoặc từ môi trường hiện có), có thể thích ứng với môi trường mới hoặc có thể thay thế một thực thể khác.
Kiểm tra khả năng tương thích – Compatibility testing gồm 2 khía cạnh:
– Interoperability – Khả năng tương tác
– Coexistence – Cùng tồn tại
Kiểm thử khả năng bảo trì – Maintainability Testing là một loại kiểm thử phần mềm nhằm đánh giá khả năng của phần mềm để được bảo trì và duy trì trong thời gian dài
Kiểm tra tính khả dụng – Usability Testing đo lường xem người dùng có cảm thấy hiệu quả, hợp lý và hài lòng với phần mềm hay không
Kiểm thử hiệu năng – Performance testing liên quan đến việc đo lường hiệu năng của một hệ thống hoặc phần mềm trong các điều kiện cụ thể liên quan đến lượng tài nguyên được sử dụng
Kiểm thử bảo mật nhằm mục đích đảm bảo rằng mọi người không thể nhìn thấy và làm những gì họ không có quyền truy cập.
ISO 9126 định nghĩa reliability – độ tin cậy là “khả năng của sản phẩm phần mềm thực hiện các chức năng được yêu cầu của nó trong các điều kiện đã nêu trong một khoảng thời gian xác định hoặc trong một số hoạt động xác định.”
Kiểm thử các đặc điểm chất lượng phần mềm là quá trình kiểm tra và đánh giá các đặc điểm liên quan đến chất lượng của phần mềm trong quá trình phát triển và triển khai. Điều này bao gồm việc xác định xem phần mềm có đáp ứng được các yêu cầu chất lượng cụ thể hay không, và có thể hoạt động đúng cách trong môi trường sản xuất hay không.
Management Review là một khía cạnh quan trọng trong việc quản lý của bất kỳ tổ chức, hệ thống hoặc doanh nghiệp nào. Bài viết hôm nay mình sẽ giới thiệu về hoạt động quản lý review và kiểm toán – audit trong kiểm thử phần mềm. Nào hãy cùng mình tìm hiểu nhé!
Review checklist này là ý tưởng của L. Peter Deutsch và những cộng sự tại Sun Microsystems. Đây là công ty đi đầu trong việc thiết kế và phát triển ứng dụng phân tán. Review checklist này dành cho việc đánh giá thiết kế.
Review là một loại kiểm thử tĩnh (static test). Đối tượng được review không được thực thi hoặc chạy trong quá trình review. Và cũng giống như bất kỳ hoạt động kiểm thử nào khác, review có thể có nhiều mục tiêu khác nhau.
Phát hiện lạm dụng API – API Misuse Detection là một quy trình hoặc công cụ trong phân tích source code và kiểm thử phần mềm nhằm xác định các trường hợp trong đó một ứng dụng hoặc chương trình sử dụng API một cách không đúng cách hoặc không tuân theo các quy tắc và hướng dẫn của nó.
Phát hiện con trỏ hoang dã – Wild Pointer Detection là một phần quan trọng trong kiểm thử phần mềm và phân tích source code. Nó nhằm xác định và giám sát việc sử dụng con trỏ một cách an toàn và đúng đắn trong chương trình máy tính.
Memory leak detection là một quá trình trong kiểm thử phần mềm hoặc phân tích source code nhằm xác định và điều tra các tình huống trong đó một ứng dụng hoặc chương trình máy tính không thể truy cập hoặc giải phóng bộ nhớ một cách đúng đắn sau khi nó không còn cần thiết.
Phân tích đồ thị gọi hàm – Call-Graphing Analysis là một phương pháp sử dụng trong việc phân tích source code để hiểu cách các hàm hoặc phương thức được gọi và tương tác với nhau trong chương trình.
Data-Flow Analysis là một phương pháp phân tích source code để xác định cách dữ liệu chảy qua các phần của chương trình. Nó tập trung vào việc theo dõi và phân tích cách dữ liệu được tạo ra, truyền đi và sử dụng trong source code.
Trong phân tích tĩnh (Static Analysis), Complexity Analysis được sử dụng để đo lường độ phức tạp của source code mà không cần thực thi chương trình. Điều này giúp đánh giá mức độ phức tạp của code và xác định các vấn đề có thể xảy ra hoặc cần được tinh chỉnh để cải thiện hiệu suất, bảo trì hoặc sửa lỗi.
API Testing là quá trình kiểm thử để đảm bảo tính đúng đắn, độ tin cậy và hiệu suất của các giao diện lập trình ứng dụng (APIs). Trong quá trình phát triển phần mềm, API Testing là một phần quan trọng để đảm bảo rằng các API hoạt động đúng cách và tuân thủ các quy định đã được xác định.
Độ phức tạp chu kỳ – Cyclomatic complexity là số vòng lặp cần thiết và không phải ngẫu nhiên số trường hợp kiểm thử mà chúng ta cần để kiểm thử tập hợp các đường dẫn cơ sở. Độ phức tạp không phụ thuộc vào kích thước của module mà phụ thuộc vào số lượng quyết định có trong đó.
Linear Code Sequence and Jump – LCSAJ là các khối code nhỏ phù hợp với một cấu hình cụ thể. Về mặt hình thức, ta coi rằng các module phần mềm được tạo thành từ các chuỗi code tuyến tính được nhảy tới, thực thi và sau đó nhảy từ đó.
Bao phủ nhiều điều kiện – Multiple Condition Coverage là một phương pháp trong kiểm thử phần mềm dùng để đảm bảo rằng tất cả các khả năng kết hợp của các điều kiện trong source code đã được kiểm tra.
Bao phủ quyết định/điều kiện – Condition/Decision Coverage là sự kết hợp giữa bao phủ quyết định và bao phủ điều kiện để giải quyết nhược điểm của bao phủ chỉ có điều kiện đã chỉ ra ở bài viết trước.
Kiểm thử điều kiện – Condition testing (còn gọi là condition coverage) là một phương pháp kiểm thử phần mềm nhằm đảm bảo rằng tất cả các điều kiện logic trong source code đã được kiểm tra và đánh giá ít nhất một lần trong quá trình kiểm thử.
Kiểm thử vòng lặp – Loop testing (hay Loop coverage) là một phương pháp trong kiểm thử phần mềm để đảm bảo rằng tất cả các loại vòng lặp trong source code đã được thực thi một số lần tương ứng.
Kiểm thử quyết định – Decision Testing (hay decision coverage hoặc branch coverage) là một phương pháp trong kiểm thử phần mềm để đảm bảo rằng tất cả các nhánh của source code được thực hiện ít nhất một lần trong quá trình kiểm thử.
Bao phủ câu lệnh – Statement coverage (Instruction hoặc Code Coverage) là phương pháp kiểm thử phần mềm đo lường mức độ mà các dòng code (hay câu lệnh) trong chương trình đã được thực thi trong quá trình kiểm thử. Để đạt được phạm vi bao phủ của câu lệnh, chúng ta chọn dữ liệu kiểm thử buộc luồng thực thi phải đi qua từng dòng code mà hệ thống chứa.
Về mặt khái niệm, tấn công phần mềm là một hình thức kiểm thử tập trung và có định hướng nhằm cố gắng buộc các lỗi cụ thể xảy ra. Nó có cấu trúc hơn kỹ thuật kiểm thử phân loại lỗi, vì nó được xây dựng dựa trên mô hình lỗi. Mô hình lỗi nói về cách lỗi hình thành và cách thức cũng như lý do lỗi biểu hiện thành lỗi.
Kiểm thử thăm dò (Exploratory Testing) là một phương pháp kiểm thử phần mềm mà trong đó người kiểm thử sẽ thực hiện việc kiểm thử mà không theo một kịch bản kiểm thử cụ thể hay một kế hoạch kiểm thử trước đó. Thay vào đó, người kiểm thử sẽ tự do khám phá và kiểm tra ứng dụng như một người dùng thực tế, trong quá trình đó họ sẽ kiểm tra, đánh giá, và tìm lỗi, vấn đề hoặc tình huống không mong muốn.
Kỹ thuật kiểm thử dựa vào checklist (checklist-based testing) không hẳn là một trào lưu mới trong kiểm thử phần mềm, nhưng gần đây ngày càng nhiều người nhận ra những lợi ích mà chúng mang lại. Bài viết này giới thiệu về: Thế nào kiểm thử dựa vào checklist, Lợi ích và thách thức mà loại kiểm thử này mang lại, Cách thức xây dựng một checklist thông qua một ví dụ thực thế. Nào hãy bắt đầu tìm hiểu cùng mình nhé…
Kỹ thuật đoán lỗi (Error Guessing) là một phương pháp kiểm thử phần mềm dựa trên kinh nghiệm và trực giác của người kiểm thử để tìm ra các tình huống, kịch bản hoặc điều kiện tiềm năng mà có thể dẫn đến lỗi hoặc sự cố trong phần mềm. Thay vì tuân theo một kế hoạch kiểm thử cụ thể, người kiểm thử dựa vào sự hiểu biết của họ về hệ thống để tạo ra các trường hợp kiểm thử không đều đặn nhưng có thể là những điểm yếu tiềm ẩn.
Phân loại lỗi – Defect Taxonomies là một hệ thống phân loại được sử dụng để phân loại và tổ chức các lỗi hoặc khuyết điểm trong quá trình kiểm thử phần mềm. Nó giúp tổ chức các lỗi theo các danh mục cụ thể, giúp kiểm thử viên và nhóm phát triển hiểu rõ hơn về các vấn đề có thể xảy ra trong phần mềm và cách xử lý chúng. Phân loại lỗi cũng có thể giúp ích trong việc báo cáo và phân tích các vấn đề trong quá trình phát triển và kiểm thử.
Về mặt khái niệm, cây phân loại – classification tree là cách để kiểm tra sự kết hợp có giới hạn của các yếu tố. Chúng cho phép người kiểm thử kiểm tra một số yếu tố nhiều hơn những yếu tố khác. Mô hình cơ bản là một biểu diễn đồ hoạ của các yếu tố và các tuỳ chọn cho từng yếu tố, thường được chuẩn bị bằng cách sử dụng phân vùng tương đương. Ngoài ra còn có các quy tắc kết hợp yếu tố và tùy chọn, bao gồm mức độ kết hợp để đạt được giữa các yếu tố nhất định (ví dụ: tất cả bộ ba cho ba yếu tố, nhưng chỉ các cặp cho các yếu tố khác).
Pairwise testing là một kỹ thuật kiểm thử phần mềm được sử dụng để tạo ra một tập hợp các bộ kiểm thử tối ưu bằng cách chọn các giá trị đầu vào sao cho mọi cặp giá trị có thể xảy ra đều được kiểm tra ít nhất một lần.
Về mặt khái niệm, Use case testing là một cách để đảm bảo rằng chúng ta đã kiểm thử các luồng xử lý và kịch bản điển hình và đặc biệt cho hệ thống, từ quan điểm của các tác nhân khác nhau tương tác trực tiếp với hệ thống và từ quan điểm của các bên liên quan khác nhau, những người tương tác gián tiếp với hệ thống.
Kiểm thử dựa trên trạng thái – State-based testing (hay State Transition Testing) là một loại kiểm thử phần mềm dựa trên sự chuyển đổi giữa các trạng thái của hệ thống. Trong phương pháp này, hệ thống được xem xét như một tập hợp các trạng thái và các sự kiện (events) hoặc hành động (actions) có thể xảy ra, và kiểm thử được thiết kế để kiểm tra các sự chuyển trạng thái và hành vi của hệ thống trong mỗi trường hợp chuyển đổi.
Kiểm thử dựa vào bảng quyết định (Decision Table Testing) là kỹ thuật kiểm thử biểu diễn dạng bảng của một tập hợp các điều kiện và các hành động liên quan. Nó được biểu thị dưới dạng các quy tắc cho biết hành động nào sẽ xảy ra đối với tập hợp các giá trị điều kiện nào. Kiểm thử viên có thể sử dụng các bảng quyết định để phân tích các quy tắc áp dụng cho phần mềm đang kiểm tra và thiết kế các bài kiểm tra để bao gồm các quy tắc đó.
Phân tích giá trị cận biên – Boundary Value Analysis là một kỹ thuật kiểm thử phần mềm tập trung vào kiểm tra các giá trị đầu vào nằm ở biên của khoảng giá trị hợp lệ hoặc không hợp lệ. Mục tiêu chính của phân tích giá trị cận biên là tìm ra các lỗi hoặc vấn đề liên quan đến xử lý giá trị biên của phần mềm.
Kỹ thuật phân vùng tương đương (Equivalence Partitioning) là một kỹ thuật kiểm thử phần mềm mà trong đó các tập hợp dữ liệu hoặc giá trị đầu vào được chia thành các nhóm tương đương dựa trên cách phần mềm xử lý chúng. Mục tiêu chính của phân vùng tương đương là giảm số lượng trường hợp kiểm thử cần kiểm tra trong khi vẫn đảm bảo rằng các trường hợp kiểm thử quan trọng được bao phủ.
Có hai loại chính của kỹ thuật kiểm thử phần mềm là kiểm thử tĩnh và kiểm thử động. Mỗi kỹ thuật kiểm thử lại phân loại thành những loại nhỏ hơn. Sơ đồ minh hoạ dưới đây sẽ giúp các bạn có cái hình dung rõ hơn về các kỹ thuật sử dụng trong kiểm thử phần mềm hiện nay.
Trong Selenium WebDriver, CSS selectors có thể được sử dụng để định vị các phần tử web bằng phương pháp By.cssSelector(). Phương thức này chấp nhận một chuỗi CSS selectors làm đối số của nó, xác định tiêu chí lựa chọn cho phần tử được định vị.
Trong Selenium WebDriver, locators – bộ định vị (hay bộ tìm kiếm) được dùng để xác định và định vị Web element – phần tử trên trang web. Phần tử Web có thể là link, button, dropdown box, text box, checkbox, v.v..
Người dùng có thể xác định các phần tử web bằng cách kiểm tra mã nguồn HTML của trang web thông qua sử dụng “Inspect Tools” của trình duyệt. Còn trong kiểm thử tự động, việc xác định phần tử web sẽ thông qua các bộ chọn – selectors. Chúng giúp Selenium WebDriver tương tác với các phần tử web và mô phỏng hành động của người dùng.
Web element và locator là hai thứ khác nhau. Web element locator là một đối tượng để tìm và trả về các phần tử web trên một trang bằng cách sử dụng câu truy vấn – query. Nó cho phép nhà phát triển hoặc người kiểm thử định vị và tương tác với các phần tử HTML, CSS hoặc JavaScript trên một trang web. Nói tóm lại, locators dùng để tìm elements.
Locator có quan trọng đối với Kỹ sư kiểm thử tự động không? Câu trả lời là rất quan trọng. Nếu như người dùng có thể tương tác với trang web một cách trực quan: chúng ta nhìn, scroll, nhấp chuột, gõ thông qua trình duyệt. Thì công việc kiểm thử tự động đòi hỏi phải tương tác với trang web thông qua lập trình. Nghĩa là chúng cần được mã hoá bằng code để tìm và thao tác với các thành phần của web. Kiểm thử tự động sẽ không “nhìn” trang web như con người. Thay vào đó, nó sẽ tìm kiếm trên DOM.
Quyết định cấp độ kiểm thử nào phù hợp với khu vực kiểm tra nào là một trong những hoạt động quan trọng trong quá trình thiết kế kiểm thử. Bài viết hôm nay, mình sẽ cùng các bạn tìm hiểu về low-level test case và high-level test case, cũng như những ưu nhược điểm của từng loại.
Nào, hãy bắt đầu nhé!
Có nhiều mô hình phát triển phần mềm khác nhau và mỗi mô hình đều có yêu cầu và quy trình kiểm thử riêng. Bài viết hôm nay mình sẽ trình bày về kế hoạch kiểm thử cho một số mô hình phát triển phần mềm phổ biến, bao gồm: Mô hình tuần tự – Sequential Models, Mô hình lặp lại -Iterative Models, Mô hình Agile – Agile Models, Mô hình xoắn ốc – Spiral Models.
Nào hãy bắt đầu tìm hiểu cùng mình nhé!
Ma trận đánh giá rủi ro – Risk assessment matrix là một công cụ được sử dụng trong quản lý rủi ro để xác định mức độ rủi ro của các sự kiện, hành động hoặc tình huống cụ thể. Ma trận đánh giá rủi ro thường là một bảng hai chiều với hai tham số chính là xác suất – probability và mức độ nghiêm trọng – severity. Mỗi tham số được chia thành một số mức đánh giá, thường từ 1 đến 3 hoặc 1 đến 5, để tạo ra các ô trong ma trận.
Mô hình FMEA (Failure Mode and Effects Analysis) là một phương pháp phân tích rủi ro được sử dụng để xác định, đánh giá và giảm thiểu các lỗi tiềm ẩn hoặc lỗi có thể xảy ra trong một quy trình, sản phẩm hoặc hệ thống. Nó được sử dụng rộng rãi trong các lĩnh vực như công nghiệp, y tế, ô tô, hàng không vũ trụ và phần mềm.
Quá trình xác định rủi ro bao gồm các hoạt động sau:
Thu thập thông tin: Thu thập thông tin về dự án, hệ thống hoặc tổ chức liên quan đến các khía cạnh như yêu cầu, thiết kế, môi trường vận hành, công nghệ, quy trình làm việc, nhân lực, tài chính, v.v.. Điều này giúp xây dựng một hình dung toàn diện về hoạt động và môi trường của dự án hoặc tổ chức.
Phân tích các yếu tố gây rủi ro: Xem xét các yếu tố gây rủi ro trong dự án hoặc tổ chức. Các yếu tố này có thể bao gồm: sự không chắc chắn, sự phụ thuộc vào bên thứ ba, thiếu nguồn lực, thiếu kỹ năng, quy trình không hiệu quả, sự thay đổi công nghệ, môi trường tổ chức không ổn định, v.v. Điều này giúp xác định các khía cạnh có khả năng gây rủi ro trong dự án hoặc tổ chức.
Xác định các rủi ro: Dựa trên thông tin và phân tích, xác định các rủi ro tiềm ẩn có thể xảy ra trong dự án hoặc tổ chức. Các rủi ro có thể được mô tả theo cách chung hoặc cụ thể, bao gồm cả các nguy cơ có thể xảy ra và tác động của chúng.
Ghi nhận thông tin về rủi ro: Ghi lại thông tin về các rủi ro đã xác định, bao gồm: mô tả, nguyên nhân, tác động, mức độ nghiêm trọng và khả năng xảy ra. Thông tin này sẽ tạo nên cơ sở dữ liệu về rủi ro để từ đó có thể thực hiện các hoạt động quản lý rủi ro.
Ngày nay, “chất lượng” đang trở thành một yếu tố quan trọng trong phân phối phần mềm. Các cải tiến liên tục diễn ra để nâng cao chất lượng nhằm giữ cho khách hàng hài lòng. Hầu hết kỹ sư kiểm thử đều chịu áp lực rất lớn về mặt thời gian và nguồn lực để siết chặc số thử nghiệm. Thông thường bản dựng được bàn giao cho họ vào phút cuối. Không thể bỏ lỡ thời gian giao hàng và đồng thời chất lượng cũng không thể bị ảnh hưởng.
Vì vậy, làm thế nào để chúng tôi quyết định bài kiểm tra nào là quan trọng trong giai đoạn này? Những điều mà tester coi là quan trọng có thể không thực sự quan trọng đối với khách hàng. Tầm quan trọng của tính năng hoặc chức năng được quyết định từ quan điểm của ai? Ai sẽ quyết định đâu là những bài kiểm tra quan trọng? Và rất nhiều câu hỏi khác tiếp tục phát sinh.
Để trả lời tất cả những câu hỏi này và xử lý tình huống trên một cách hiệu quả, một phương pháp thử nghiệm có tên là ‘Risk-based testing – Kiểm thử dựa vào rủi ro’ đã ra đời.
Nào hãy cùng mình tìm hiểu trong các bài viết này nhé.
Một sự thật là kiểm thử tự động luôn là mục tiêu nhắm tới của mọi kiểm thử viên phần mềm. Hầu hết chúng ta đều muốn trở thành kiểm thử viên tự động – automation tester. Nhưng chỉ một vài người trong chúng ta thành công với nó. Bài viết hôm nay, mình sẽ đưa ra một số lời khuyên về kiến thức và kỹ năng cần thiết để giúp bạn trở thành một kiểm thử viên tự động thành công mà bạn mong muốn.
Hãy bắt đầu nhé!
Bài viết hôm nay sẽ đề cập đến các bước thực hiện trong một quy trình kiểm thử tự động. Chúng bao gồm:
Step 1: Lựa Chọn Công Cụ Kiểm Thử
Step 2: Xác Định Phạm Vi Của Kiểm Thử Tự Động
Step 3: Xây Dựng Kế Hoạch Kiểm Thử Tự Động
Step 4: Thiết Kế Và Phát Triển Kịch Bản Kiểm Thử Tự Động
Step 5: Tiến Hành Kiểm Thử
Step 6: Phân Tích Và Báo Cáo Kết Quả Kiểm Thử
Step 7: Bảo Trì Và Nâng Cấp Kiểm Thử Tự Động
Kiểm thử tự động – Automation Testing là đang là xu hướng trong lĩnh vực kiểm thử phần mềm và ngày càng có nhu cầu cao. Nhưng liệu nó có thực sự hiệu quả về mặt chi phí? Bạn có thực sự cắt giảm được chi phí bằng việc sử dụng các công cụ kiểm thử tự động thay vì trả tiền cho kiểm thử thủ công? Tương lai của kiểm thử tự động sẽ ra sao? Trong bài viết này chúng ta sẽ tìm câu trả lời câu trả lời nhé.
Nếu một kiểm thử viên thủ công làm việc 8 tiếng một ngày và trở về nhà, thì kiểm thử tự động làm việc mọi lúc. Vậy thì nó có thực sự hiệu quả. Trước khi bắt đầu với việc xây dựng một chiến lược và thành lập team kiểm thử, hãy cùng mình điểm qua những cái nhìn đúng đắn về kiểm thử tự động.
Mình hay đùa rằng việc tìm bug giống như truy tìm tội phạm và người kiểm thử giống như thám tử vậy. Và muốn tìm được “tội phạm” của mình, trước hết người kiểm thử viên cần biết đặc điểm nhận diện của chúng, khoanh vùng những chỗ khả nghi, và truy tìm theo đầu mối. Mỗi loại bug khác nhau sẽ có những đặc thù khác nhau. Trong bài viết hôm nay, mình sẽ giới thiệu cho các bạn một số loại bug phổ biến cùng những đặc điểm đặc trưng của chúng. Nào, hãy cùng mình tìm hiểu nhé.
Test Web hay Test Website là việc kiểm tra trang web hay ứng dụng web của bạn nhằm đảm bảo chúng hoạt động theo một tiêu chuẩn chất lượng nhất định. Đó là một quá trình bao gồm nhiều hoạt động khác nhau, nhưng mục tiêu chính luôn giống nhau – phát hiện càng nhiều lỗi càng tốt và phát triển các phương pháp nhằm ngăn chặn chúng trong tương lai.
Kiểm thử phần mềm là một quá trình điều tra. Người kiểm thử đưa phần mềm qua rất nhiều bài kiểm tra để phát hiện bất kỳ lỗi ẩn nào, hành vi không đoán trước hoặc sự không nhất quán về chức năng. Sau mỗi lần kiểm tra, người kiểm thử sẽ gửi một báo cáo chi tiết giúp các nhà phát triển khắc phục các sự cố đã phát hiện, duy trì phần mềm không có lỗi và đảm bảo phần mềm chạy như dự định. Hiện nay có nhiều phương pháp kiểm thử phần mềm, nhưng phổ biến nhất vẫn là Black-box Testing, White-box testing, Grey-box testing. Bằng các cách tiếp cận khác nhau, các phương pháp này giữ cho code sạch và kiểm tra chức năng một cách hiệu quả.
Bài viết này hãy cùng mình tìm hiểu về Những phương pháp này là gì, Chúng được sử dụng để làm gì, Sự khác biệt giữa chúng, cũng như tìm ra điểm mạnh và điểm yếu của từng phương pháp kiểm thử. Nào hãy cùng bắt đầu nhé!
Trong quá trình kiểm thử phần mềm, việc thiết kế các bộ dữ liệu kiểm thử (test data) đóng vai trò quan trọng để đảm bảo tính toàn vẹn và độ tin cậy của phần mềm. Thiết kế các bộ dữ liệu kiểm thử hiệu quả giúp tăng độ chính xác của kết quả kiểm thử và giảm thiểu những rủi ro tiềm ẩn trong quá trình sử dụng phần mềm.
Để thiết kế các bộ dữ liệu kiểm thử, ta cần phải hiểu rõ yêu cầu và chức năng của phần mềm cần kiểm thử. Dựa trên đó, ta có thể thiết kế các bộ dữ liệu kiểm thử đa dạng, phong phú và đầy đủ các trường hợp kiểm thử. Các bộ dữ liệu kiểm thử cần bao gồm các trường hợp kiểm thử cơ bản và các trường hợp kiểm thử đặc biệt.
Ở phần 1 mình đã giới thiệu về kiểm thử mobile là gì, phân loại các loại mobile app và việc lập chiến lược kiểm thử trên mobile. Trong bài viết này, mình xin giới thiệu danh sách kiểm tra – checklist cho mobile app. Checklist này sẽ cung cấp cho người kiểm thử cách tiếp cận từng bước kiểm tra để đảm bảo chất lượng sản phẩm trước khi phát hành ra thị trường.
Ngành công nghiệp ứng dụng di động đang phát triển với tốc độ chưa từng thấy. Điều này đã dẫn đến sự gia tăng đáng kể số lượng ứng dụng sẵn có để người dùng cuối tải xuống. Các ứng dụng dành cho thiết bị di động đóng vai trò quan trọng trong việc thay đổi cách mọi người làm việc, giao tiếp, mua sắm cũng như tương tác với nhau. Vì vậy, để sản phẩm của bạn nổi bật giữa đám đông, khi người dùng tiếp tục tải xuống hàng nghìn ứng dụng mỗi ngày, là một thách thức lớn. Sản phẩm của bạn phải đảm bảo chất lượng, đẹp mắt và đáp ứng được nhu cầu sử dụng của người dùng.
Với vai trò là một nhà kiểm thử phần mềm, bạn cần thực hiện những danh mục kiểm thử gì? Các công cụ, thiết bị nào có thể hỗ trợ kiểm thử? Các bước lập kế hoạch là gì? Hãy cùng mình tìm hiểu qua bài viết này nhé.
Functional testing và phi chức năng là cách tiếp cận phổ biến nhất để phân loại các loại kiểm thử phần mềm khác nhau. Hai loại này đề cập đến bản chất của quá trình thử nghiệm và chính xác những gì đang được thử nghiệm. Có hai điều cần biết về functional testing và phi chức năng nếu bạn chưa từng tìm hiểu sâu về hai loại kiểm thử này trước đây.
Thứ nhất, sự phân chia giữa functional testing và phi chức năng không cố định. Đối với một số loại kiểm thử, việc phân loại chúng không phải là điều dễ dàng.
Thứ hai, cả functional testing và phi chức năng đều cần thiết cho sự thành công của dự án kiểm thử phần mềm của bạn, mặc dù theo những cách khác nhau.
Bước vào lĩnh vực IT có thể rất khó khăn. Để làm việc tốt trong nghề này bạn cần sẵn sàng và mong muốn học hỏi, không ngừng cải thiện kỹ năng của mình và có mục tiêu trở thành một chuyên gia trong lĩnh vực của mình. Đây không phải là con đường sự nghiệp dễ dàng, nhưng nó rất đáng giá.
Mình không học CNTT, cũng không bắt đầu công việc kiểm thử phần mềm. Mình học qua những đồng nghiệp của mình, qua những buổi chia sẻ, đào tạo training của những người đi trước. Một câu nói mà mình rất thích khi bắt đầu theo đuổi con đường này:
**If not you, but who?**
**If not now, but then?**
Nếu bạn có hứng thú với nghề kiểm thử phần mềm, hãy tự mình tìm hiểu và đưa ra quyết định nhé. Bởi “Không phải bạn thì là ai? Không phải bây giờ thì khi nào?”
Khi bạn là một tester mới trong một công ty phần mềm (yeah, giống mình), bạn có thể đối mặt với một số thử thách trong những ngày đầu. Bạn cần tìm hiểu quy định công ty, quy trình dự án, làm quen đồng nghiệp mới. Bạn biết đấy, nó chẳng dễ dàng gì. Tuy nhiên, bạn sớm sẽ học được chúng, điều khó khăn nhất còn chưa đến. Bạn có thể sẽ tham gia vào một dự án đầu tiên – với rất nhiều những ràng buộc, các module, các component cần bạn test nhanh chóng, nhưng phải chất lượng. May mắn ra bạn sẽ được cung cấp tài liệu hoặc mockup, nhưng nếu không – thì đây là thời điểm bạn cần tới Kiểm thử thăm dò – Exploratory testing.
Tìm bug và viết báo cáo về bug phát hiện là một trong những công việc quen thuộc của mọi kiểm thử viên. Một bug được báo cáo hiệu quả thì cơ hội được sửa chữa của nó sẽ cao hơn. Report bug là một kỹ năng, và để trở thành một kiểm thử viên chuyên nghiệp thì bạn cần nắm được kỹ năng này. Bài viết này mình sẽ giới thiệu về quy trình viết bug report cũng như các mẹo để có một report hiệu quả và chuyên nghiệp.
Test case là một tài liệu mô tả tập hợp các hành động, các điều kiện và kết quả mong đợi mà tester cần xác minh đối với sản phẩm phần mềm. Đây là tài liệu căn bản cần có để xác định xem một phần mềm hoặc một trong các tính năng của nó có hoạt động theo đúng dự tính và mong muốn ban đầu hay không.
Một test case được xây dựng kém có thể dẫn đến những rò rỉ lỗ hổng đáng kể. Điều này làm tốn thời gian và tiền bạc. Do đó, việc xây dựng các test case hiệu quả là điều tối quan trọng đối với sự thành công của bất kỳ dự án phần mềm nào.
