Trong các công ty phần mềm chủ yếu chúng ta thường gặp “kiểm thử” ở hình thái là các chị em gái (xinh đẹp & cá tính) ngồi viết test case dựa trên các tài liệu mô tả và aceptance criterial. Sau đó, dựa trên test case sẽ thực hiện “test” phần mềm do các lập trình viên làm ra. Mỗi khi phát hiện ra lỗi, chị em tester gọi nó là “bug” mà anh em developer thì cãi lại là “feature”.
Đang xem: Kiểm thử phần mềm là gì
Một câu chuyện vui vậy thôi, dù là “bug” hay “feature” nếu nó có ảnh hưởng đến chất lượng phần mềm thì developer sẽ phải là người sửa (tùy vào tính chất urgent mà sửa luôn hoặc sắp lịch mà fix-bug).
Để đảm bảo chất lượng phần mềm, không chỉ cần một vài người mở đi mở lại phần mềm, lặp đi lặp lại một vào thao tác bằng tay hoặc bằng một vài công cụ là đủ,câu chuyện phía trên chỉ là một trong số nhiều các cách thức kiểm thử phần mềm. Trong bài viết này, tôi xin chia sẻ một số “keyword” về kiểm thử phần mềm, các bạn có thể tìm hiểu sâu hơn về nghề nghiệp này bằng cách search google hoặc đọc các tài liệu về software testing nhé.
1. Kiểm thử phần mềm là gì?
Là một tiến trình hay một tập hợp các tiến trình được thiết kế ra để:
Đảm bảo phần mềm thực hiện đúng theo những thứ mà chúng đã được thiết kế.Trong quá trình sử dụng phần mềm không phát sinh bất cứ thứ gì không mong muốn.
Đây là một pha quan trọng trong quá trình phát triển hệ thống phần mềm:
Giúp cho khách hàng thấy được sản phẩm đặt ra đã đáp ứng được yêu cầu hay chưa.Đảm bảo chất lượng phần mềm khi đưa ra sử dụng. Tránh các rủi ro khi cho khách hàng khi đưa phần mềm vào sử dụng.Giảm thời gian và chi phí phát sinh do bảo trì (fix lỗi) cho người viết phần mềm.
Có 2 kiểu kiểm thử phần mềm:
Kiểm thử tĩnh (Static testing)Kiểm thử động (Dynamic testing)1.1. Kiểm thử tĩnh (Static testing)Là phương pháp kiểm thử phần mềm thủ công.Phương pháp này thường được những người phân tích thiết kế phần mềm (IT-BA) thực hiện.
Cách thực hiện:Dùng giấy, bút và trí “tưởng tượng” để kiểm tra logic, kiểm tra từng chi tiết luồng nghiệp vụ theo yêu cầu đề bài mà không cần chạy chương trình.
Mục đích:Cách làm này có thể sẽ giúp BA phát hiện ra những thiếu xót trong đề bài để bổ sung tài liệu trước khi chuyển sang cho DEV.
Đôi khi static testing sẽ bị nhầm lẫn với việc BA đưa tài liệu cho các bên liên quan (khách hàng/đại diện khách hàng/product owner) để review trước khi chuyển giao tài liệu sang pharse mới (DEV).
1.2. Kiểm thử động (Dynamic testing)
Phương pháp thử phần mềm thông qua việc chạy chương trình để theo dõi trạng thái, kết quả của từng bước / toàn bộ các bước trong quá trình thực thi phần mềm.
Cách thực hiện dựa trên các ca kiểm thử (test case) xác định bằng sự hoạt động của đối tượng kiểm thử hay toàn bộ chương trình.
Kiểm tra cách thức hoạt động động của mã lệnh, bao gồm luôn cả kiểm tra sự phản ứng vật lý từ hệ thống tới các biến luôn thay đổi theo thời gian.
Mục đích:Trong kiểm thử động, tester quan tâm đến dữ liệu đầu vào và output đầu ra.
Với mỗi tập dữ liệu đầu vào sẽ phát sinh ra một tập dữ liệu output
Nếu chương trình nhận đầu vào để “chạy” sau đó đưa ra dữ liệu output giống như yêu cầu. Có thể nói đó là phần mềm đã hoạt động thành công.
Các cách phân loại kiểm thử động:Có hai trường phái phân loại kiểm thử
1. Phân loại theo chiến lược kiểm thử2. Phân loại theo mức độ kiểm thử
2. Các cách phân loại kiểm thử động
2.1. Phân loại theo chiến lược kiểm thử
Black box testing
Xem chương trình như 1 “hộp đen”.Kiểm thử dựa trên đặc tả của phần mềm.Không quan tâm cấu trúc bên trong của chương trình, tập trung tìm các trường hợp mà chương trình không thực hiện theo đặc tả của nó.
Đặc điểm:
Không cần biết tới code và cấu trúc chương trình.Đánh giá chương trình khách quan.Hạn chế: nhiều trường hợp áp dụng nhiều ca kiểm thử để kiểm tra trong khi chỉ cần 1 pha kiểm thử duy nhất “Thăm dò mù”.
Các phương pháp:
Phân lớp tương đương – Equivalence partitioningPhân tích giá trị biên – Boundary value analysisKiểm thử mọi cặp – ALl-pairs testingKiểm thử fuzz – Fuzz tesingKiểm thử dựa trên mô hình – Model-based testingMa trận dấu viết – Traceability matrixKiểm thử thăm dò – Exploratory testingKiểm thử dựa trên đặc tả – Specification-base testing
White box testing
Còn được gọi là clear box testing, glass box testing, transparent box testing.Thường thiết kế các trường hợp kiểm thử dựa vào cấu trúc bên trong của phần mềm
Đặc điểm:
WBT đòi hỏi kỹ thuật lập trình am hiểu cấu trúc bên trong của phần mềm ( các logic nghiệp vụ, luồng dữ liệu, chức năng, kết quả ).Phương thức: Chọn các đầu vào và xem các đầu ra.Phụ thuộc vào các cài đặt hiện tại của hệ thống và của phần mềm, nếu có sự thay đổi thì bài test cũng phải thay đổi theo.Được ứng dụng trong các kiểm tra ở cấp độ module ( điển hình), tích hợp ( có khả năng ) và hệ thống của quá trình test phần mềm.
Các phương pháp:
Kiểm thử API: Là phương pháp kiểm thử ứng dụng sử dụng các public & private API.Bao phủ mã lệnh (code coverage): Tạo các kiểm tra để đáp ứng một số tiêu chuẩn về kiểm thử mã lệnh.Các phương pháp gán lỗi (Fault injection)Các phương pháp kiểm thử hoán chuyển (mutation testing method)Gray (grey) box testing
Kết hợp của black-box và white-box testing.
2.2. Phân loại theo mức độ
Mức độ ở đây là mỗi giai đoạn kiểm thử sẽ đáp ứng các yêu cầu hoặc mô tả tương ứng nào.
Xem thêm: Cách Chơi Trốn Tìm Một Mình (Cảnh Báo: Nội Dung Có Thể Gây Ám Ảnh)
Unit Testing:
Kiểm thử trên các thành phần độc lập nhỏ nhất của phần mềm.
Thông thường, phần mềm được chia nhỏ ra các thành phần độc lập nhau: Function -> Class -> Module -> Package. Lập trình viên sau khi lập trình ra các thành phần, tự viết chương trình unit testing để đảm bảo dữ liệu do mình tạo ra hoạt động bình thường.
Unit-testing thường được thực hiện bởi các developer làm trực tiếp hoặc các leader viết để kiểm thử source code của team phát triển. Ở một số công ty việc viết unit-test gần như là bắt buộc và mỗi lần thay đổi source code việc pass qua các bài unit-test trước khi đưa sản phẩm nên PRODUCTION.
Tất nhiên là việc viết unit-test sẽ chiếm kha khá thời gian của các developer nên trong thực tế nhiều công ty/team bỏ qua việc này. Nếu bỏ qua unit-test thì “gánh nặng” về chất lượng phần mềm sẽ đè xuống giai đoạn kiểm thử tiếp theo.
Intergration Test: Kiểm thử tích hợp
Thực hiện test việc kết nối, ghép nối giữa các unit/module.
Mục tiêu:
Phát hiện ra lỗi giao tiếp giữa các unitPhát hiện lỗi giao tiếp giữa hệ thống và các hệ thống khác (DB, Queue, …)Chuẩn bị cho System test
Ở giai đoạn này, developer và tester bắt đầu có sự kết hợp với nhau để làm việc (đặc biệt là các team làm việc theo Scrum framework). Developer phối hợp với bộ phận hạ tầng IT/devops để xây dựng các kết nối giữa các hệ thống (cron-job, queue/background job, database, api,…). Sau đó tester có thể bắt đầu các bài test về kết nối giữa các module.
System Test – Kiểm thử hệ thống:
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 bao gồm các loại kiểm thử:
Kiểm thử chức năng (Functional Test)Kiểm thử hiệu năng (Performance Test)Kiểm thử khả năng chịu tải (Stress Test hay Load Test)Kiểm thử cấu hình (Configuration Test)Kiểm thử bảo mật (Security Test)Kiểm thử khả năng phục hồi (Recovery Test)
Giai đoạnsystem testlà giai đoạn kết hợp giữa tất cả các bộ phận trong khối công nghệ thông tin để thực hiện. Ví dụ:Functional Testdo các tester thực hiện dựa trên các mô tả/yêu cầu của phần mềm.Security Test do bộ phận an toàn thông tin thực hiện.Recovery Testsẽ do bộ phận quản trị cơ sở dữ liệu thực hiện…..
–> Chuẩn bị cho Acceptance test
Acceptance Test – Kiểm thử chấp nhận sản phẩm:
Chứng minh phần mềm thỏa mãn tất cả yêu cầu của khách hàng và khách hàng chấp nhận sản phẩm.
Khách hàng có thể tự test hoặc thuê bên thứ ba thực hiện test.
Kiểm thử Alpha (Alpha Test) và kiểm thử Beta (Beta Test).
Kiểm thử Alpha: Được thực hiện trong nội bộ của ban phát triển phần mềm với các cộng tác viên là các tester, người dùng nội bộ hoặc các khách hàng được mời.
Kiểm thử Beta: Được thực hiện với số lượng các “tester” lớn hơn nhằm phát hiện các thay đổi hoặc lỗi trong quá trình đưa ra với người dùng.
Nếu bạn có chơi game, sẽ biết đến các event như Open-beta, Closed-Beta,… là các cách nhà xuất bản game đưa sản phẩm ra mắt các game thủ.
Release Testing:
Release testing được thực hiện sau khi triển khai phần mềm lên hệ thống thật.
Các bộ phận liên quan sẽ chuẩn bị tập dữ liệu để kiểm thử trên hệ thống production. Đây là giai đoạn cực kỳ quan trọng, quyết định sản phẩm sẽ đưa ra để khách hàng sử dụng hay hoãn lại (nếu có thể) hoặc rollback lại version trước đó.
Kết luận
Với số lượng keyword phía trên hy vọng sẽ giúp mọi người bổ sung thêm các góc nhìn về kiểm thử phần mềm.
Xem thêm: fix lỗi ios 9.1
Tùy vào khả năng vận hành và quy mô của dự án/sản phẩm mà các công ty sẽ áp dụng các phương pháp kiểm thử đảm bảo chất lượng phần mềm khác nhau. Quan trọng nhất là khả năng phối hợp giữa các bộ phận trong quy trình phát triển phần mềm sẽ cho một sản phẩm tốt.
