Phương pháp kiểm thử phần mềm: Mô hình QA

⚡ Tóm tắt thông minh

Phương pháp kiểm thử phần mềm xác định các chiến lược và loại kiểm thử được sử dụng để chứng nhận rằng ứng dụng đáp ứng kỳ vọng của khách hàng. Mô hình thác nước, lặp lại, linh hoạt và lập trình cực đoan định hình thời điểm bắt đầu kiểm thử và cách thức phản hồi được trả về.

  • 🎯 Định nghĩa cốt lõi: Các chiến lược và loại kiểm thử nhằm xác minh ứng dụng cần kiểm thử so với kỳ vọng của khách hàng, mỗi loại đều có mục tiêu và kết quả riêng.
  • 🪜 Thác nước: Các giai đoạn diễn ra theo trình tự nghiêm ngặt, vì vậy việc lập kế hoạch thử nghiệm bắt đầu sớm nhưng việc thực hiện phải chờ đến khi thiết kế hoàn chỉnh.
  • 🔁 Lặp lại: Một dự án lớn được chia thành nhiều phần, mỗi phần trải qua một chu trình thác nước, và toàn bộ hệ thống được kiểm tra sau mỗi chu kỳ.
  • Nhanh nhẹn: Các chu kỳ phát triển ngắn, tăng dần giúp ưu tiên phản ứng nhanh chóng trước sự thay đổi hơn là lập kế hoạch chi tiết, với mỗi bản phát hành đều được kiểm tra kỹ lưỡng.
  • 👥 Lập trình cực đoan: Chu kỳ làm việc rất ngắn với lập trình viên làm việc theo cặp và phương pháp phát triển dựa trên kiểm thử (test driven development), trong đó bài kiểm thử được viết trước khi viết mã.
  • 🧭 Các yếu tố lựa chọn: Bản chất dự án, yêu cầu của khách hàng và tiến độ sẽ quyết định phương pháp nào phù hợp.
  • 📋 Thiết lập cơ bản: Lập kế hoạch thực tế, xác định rõ các kết quả cần đạt được, thống nhất phương pháp kiểm thử và báo cáo minh bạch.

Các phương pháp kiểm thử phần mềm

Phương pháp kiểm thử phần mềm là gì?

Phương pháp kiểm thử phần mềm được định nghĩa là các chiến lược và loại thử nghiệm được sử dụng để chứng nhận rằng Ứng dụng đang được kiểm thử đáp ứng mong đợi của khách hàng. Phương pháp kiểm tra bao gồm kiểm tra chức năng và phi chức năng để xác nhận AUT. Ví dụ về các phương pháp thử nghiệm là Kiểm tra đơn vị, Thử nghiệm hội nhập, Thử nghiệm hệ thống, Kiểm tra năng suất v.v. Mỗi phương pháp thử nghiệm đều có mục tiêu thử nghiệm, chiến lược thử nghiệm và sản phẩm phân phối được xác định.

Lưu ý: Vì Kiểm thử phần mềm là một phần không thể thiếu của bất kỳ Phương pháp phát triển nào, nên nhiều công ty sử dụng thuật ngữ Phương pháp phát triển & Phương pháp kiểm thử một cách thông tục. Do đó, Phương pháp thử nghiệm cũng có thể đề cập đến các mô hình Thác nước, Agile và các mô hình QA khác trái ngược với định nghĩa về Phương pháp thử nghiệm ở trên. Thảo luận về các loại thử nghiệm khác nhau không mang lại giá trị cho người đọc. Do đó, chúng ta sẽ thảo luận về các mô hình phát triển khác nhau.

Phương pháp kiểm thử so với loại kiểm thử so với chiến lược kiểm thử

Ghi chú trên cho thấy một sự mơ hồ thực sự trong ngành. Ba thuật ngữ được sử dụng thay thế cho nhau trong cuộc trò chuyện nhưng lại có nghĩa khác nhau trong tài liệu dự án, và việc nhầm lẫn chúng dẫn đến các kế hoạch kiểm thử trả lời sai câu hỏi.

Hạn Câu hỏi nó trả lời Đã quyết định bởi Các ví dụ
Phương pháp kiểm tra Kiểm thử được tích hợp vào chu trình phát triển khi nào và như thế nào? Mô hình phát triển đang được sử dụng Mô hình thác nước, lặp đi lặp lại, linh hoạt, lập trình cực đoan
Loại thử nghiệm Khía cạnh nào của sản phẩm đang được kiểm chứng? Phạm vi rủi ro và yêu cầu Đơn vị, tích hợp, hệ thống, hiệu năng, bảo mật
mức độ thử nghiệm Phần mềm được kiểm tra ở mức độ chi tiết nào? Vị trí trong hệ thống phân cấp xây dựng Thành phần, tích hợp, hệ thống, chấp nhận
Chiến lược thử nghiệm Phương pháp tiếp cận chất lượng của tổ chức chúng ta là gì? Vai trò lãnh đạo QA, áp dụng cho tất cả các dự án. Dựa trên rủi ro, ưu tiên tự động hóa, chuyển dịch sang trái.
Kế hoạch kiểm tra Dự án này sẽ kiểm tra chính xác những gì, khi nào và do ai thực hiện? Quản lý kiểm thử, dự án cụ thể Phạm vi, lịch trình, nguồn lực, tiêu chí nhập và xuất.

Một nguyên tắc hữu ích cần ghi nhớ: phương pháp luận quyết định nhịp điệu, loại hình quyết định mục tiêu, và... kế hoạch kiểm tra Ghi lại cam kết. Các phần bên dưới sẽ xem xét các phương pháp luận.

Mô hình thác nước

Mô hình thác nước

Nó là gì?

Trong tạp chí Mô hình thác nước, tiến trình phát triển phần mềm qua các giai đoạn khác nhau như Phân tích yêu cầu, Thiết kế, v.v. – tuần tự.

Trong mô hình này, giai đoạn tiếp theo chỉ bắt đầu khi giai đoạn trước đó đã hoàn thành.

Phương pháp thử nghiệm là gì?

Giai đoạn đầu tiên trong mô hình thác nước là giai đoạn yêu cầu trong đó tất cả các yêu cầu của dự án được xác định đầy đủ trước khi bắt đầu thử nghiệm. Trong giai đoạn này, nhóm kiểm thử suy nghĩ về phạm vi kiểm thử, chiến lược kiểm thử và soạn thảo một kế hoạch kiểm thử chi tiết.

Chỉ sau khi thiết kế phần mềm hoàn tất, nhóm sẽ chuyển sang thực hiện các trường hợp thử nghiệm để đảm bảo rằng phần mềm được phát triển hoạt động như mong đợi.

Trong phương pháp này, nhóm thử nghiệm chỉ tiến hành giai đoạn tiếp theo khi giai đoạn trước đã hoàn thành.

Ưu điểm Nhược điểm
Mô hình Kỹ thuật phần mềm này rất đơn giản để lập kế hoạch và quản lý. Do đó, các dự án có yêu cầu được xác định rõ ràng và nêu trước có thể được kiểm tra dễ dàng bằng mô hình thác nước. Trong mô hình thác nước, bạn chỉ có thể bắt đầu với giai đoạn tiếp theo sau khi giai đoạn trước đã hoàn thành. Do đó, mô hình này không thể đáp ứng được các sự kiện ngoài kế hoạch và sự không chắc chắn.
Phương pháp này không phù hợp với các dự án có yêu cầu thay đổi thường xuyên.

Phát triển lặp đi lặp lại

Phát triển lặp đi lặp lại

Nó là gì?

Trong mô hình này, một dự án lớn được chia thành nhiều phần nhỏ, và mỗi phần được trải qua nhiều lần lặp lại của mô hình thác nước. Sau mỗi lần lặp, một mô-đun mới được phát triển hoặc một mô-đun hiện có được nâng cấp. Mô-đun này được tích hợp vào kiến ​​trúc phần mềm và toàn bộ hệ thống được kiểm thử đồng bộ.

Phương pháp thử nghiệm là gì?

Ngay sau khi quá trình lặp hoàn tất, toàn bộ hệ thống sẽ được kiểm tra. Phản hồi từ quá trình thử nghiệm sẽ có ngay lập tức và được đưa vào chu trình tiếp theo. Thời gian thử nghiệm cần thiết trong lần lặp liên tiếp có thể được giảm bớt dựa trên kinh nghiệm thu được từ các lần lặp trước.

Ưu điểm Nhược điểm
Ưu điểm chính của việc phát triển lặp lại là phản hồi thử nghiệm có sẵn ngay lập tức vào cuối mỗi chu kỳ. Mô hình này làm tăng đáng kể chi phí liên lạc vì vào cuối mỗi chu kỳ, phải đưa ra phản hồi về sản phẩm bàn giao, nỗ lực, v.v.

Phương pháp nhanh nhẹn

Phương pháp nhanh nhẹn

Nó là gì?

Các phương pháp phát triển phần mềm truyền thống hoạt động dựa trên tiền đề rằng các yêu cầu phần mềm vẫn không đổi trong suốt dự án. Nhưng với sự gia tăng về độ phức tạp, các yêu cầu trải qua nhiều thay đổi và liên tục phát triển. Đôi khi, chính khách hàng không chắc chắn về những gì mình muốn. Mặc dù mô hình lặp lại giải quyết được vấn đề này, nhưng nó vẫn dựa trên mô hình thác nước.

Trong phương pháp Agile, phần mềm được phát triển theo chu kỳ tăng dần và nhanh chóng. Sự tương tác giữa khách hàng, nhà phát triển và khách hàng được nhấn mạnh hơn là các quy trình và công cụ. Phương pháp linh hoạt tập trung vào việc ứng phó với sự thay đổi hơn là lập kế hoạch mở rộng.

Phương pháp thử nghiệm là gì?

Thử nghiệm gia tăng được sử dụng trong các phương pháp phát triển linh hoạt và do đó, mọi bản phát hành của dự án đều được kiểm tra kỹ lưỡng. Điều này đảm bảo rằng mọi lỗi trong hệ thống đều được khắc phục trước lần phát hành tiếp theo.

Ưu điểm Nhược điểm
Có thể thực hiện các thay đổi trong dự án bất cứ lúc nào để tuân thủ các yêu cầu. Tương tác liên tục với khách hàng đồng nghĩa với việc tăng thêm áp lực về thời gian cho tất cả các bên liên quan bao gồm chính khách hàng, nhóm phát triển và thử nghiệm phần mềm.
Thử nghiệm gia tăng này giảm thiểu rủi ro.

lập trình cực đoan

Lập trình cực đoan

Nó là gì?

Lập trình cực đoan là một loại phương pháp linh hoạt tin tưởng vào các chu kỳ phát triển ngắn. Một dự án được chia thành các nhiệm vụ kỹ thuật đơn giản. Các lập trình viên viết mã một phần mềm đơn giản và phản hồi lại cho khách hàng. RevĐiểm iew từ khách hàng được tổng hợp và các nhà phát triển tiến hành nhiệm vụ tiếp theo.

Trong các nhà phát triển lập trình cực đoan thường làm việc theo cặp.

Lập trình cực đoan được sử dụng ở những nơi mà yêu cầu của khách hàng liên tục thay đổi.

Phương pháp thử nghiệm là gì?

Lập trình cực đoan tuân theo sự phát triển dựa trên thử nghiệm được mô tả như sau -

  1. Thêm một Trường hợp thử nghiệm vào bộ kiểm thử để xác minh chức năng mới vẫn chưa được phát triển.
  2. Chạy tất cả các thử nghiệm và rõ ràng trường hợp thử nghiệm mới được thêm vào phải thất bại do chức năng chưa được mã hóa
  3. Viết một số mã để triển khai tính năng/chức năng
  4. Chạy lại bộ thử nghiệm. Lần này, trường hợp thử nghiệm mới sẽ đạt vì chức năng đã được mã hóa
Ưu điểm Nhược điểm
Khách hàng có ý tưởng thiết kế phần mềm mơ hồ có thể sử dụng lập trình cực đoan (extreme programming). Các cuộc họp giữa nhóm phát triển phần mềm và khách hàng sẽ làm tăng thêm yêu cầu về thời gian.
Kiểm tra liên tục và tích hợp liên tục các bản phát hành nhỏ đảm bảo mã phần mềm được phân phối có chất lượng cao

Mô hình chữ V và mô hình xoắn ốc

Hai mô hình khác xuất hiện trong hầu hết các dự án và hoàn thiện bức tranh tổng thể, bởi vì mỗi mô hình giải quyết một điểm yếu của phương pháp thác nước theo một cách khác nhau.

Mẫu V. Thường được gọi là xác minh và thẩm định, mô hình V ghép mỗi giai đoạn phát triển với một giai đoạn kiểm thử tương ứng, được vẽ như hai nhánh của chữ V. Yêu cầu đi kèm với kiểm thử chấp nhận, thiết kế cấp cao đi kèm với kiểm thử hệ thống, thiết kế cấp thấp đi kèm với kiểm thử tích hợp, và lập trình đi kèm với kiểm thử đơn vị. Giá trị của nó là thiết kế kiểm thử bắt đầu song song với mỗi giai đoạn phát triển chứ không phải sau khi lập trình, do đó các yêu cầu mơ hồ được phát hiện bởi người viết các bài kiểm thử chấp nhận nhiều tháng trước khi lỗi có thể xuất hiện. Điểm yếu của nó được kế thừa từ mô hình thác nước: mô hình vẫn giả định các yêu cầu là ổn định.

Mô hình xoắn ốc. Mô hình xoắn ốc lặp đi lặp lại xoay quanh việc phân tích rủi ro một cách rõ ràng. Mỗi vòng lặp bao gồm bốn hoạt động: xác định mục tiêu, xác định và giải quyết rủi ro, phát triển và thử nghiệm, sau đó lập kế hoạch cho vòng lặp tiếp theo. Do đó, việc thử nghiệm tập trung vào những nơi có rủi ro cao nhất thay vì phân bổ đều. Mô hình này phù hợp với các chương trình lớn, tốn kém và kéo dài như ngành hàng không vũ trụ hoặc hệ thống lõi ngân hàng, nơi chi phí phát hiện muộn là rất lớn. Đối với một dự án web nhỏ, chi phí phát sinh từ việc phân tích rủi ro chính thức ở mỗi vòng lặp hiếm khi được biện minh.

Cả hai mô hình đều nằm giữa kỷ luật của mô hình thác nước và khả năng phản ứng nhanh nhạy của mô hình linh hoạt. Trong trường hợp tần suất phát hành quan trọng hơn cả hai yếu tố trên, thì... DevOps Quy trình tự động đưa việc kiểm thử vào hệ thống tích hợp liên tục, do đó mọi commit đều được tự động xác minh.

Chọn phương pháp phần mềm nào?

Có rất nhiều phương pháp có sẵn để phát triển phần mềm và thử nghiệm tương ứng. Mỗi kỹ thuật và phương pháp thử nghiệm được thiết kế cho một mục đích cụ thể và có những ưu điểm và nhược điểm tương đối.

Việc lựa chọn một phương pháp cụ thể phụ thuộc vào nhiều yếu tố như tính chất của dự án, yêu cầu của khách hàng, tiến độ dự án, v.v.

Từ góc độ thử nghiệm, một số phương pháp thúc đẩy đầu vào thử nghiệm sớm trong vòng đời phát triển, trong khi những phương pháp khác đợi cho đến khi mô hình hoạt động của hệ thống sẵn sàng.

Làm thế nào để thiết lập các phương pháp kiểm thử phần mềm?

Các phương pháp kiểm thử phần mềm không nên được thiết lập chỉ vì mục đích kiểm tra mã phần mềm. Cần xem xét bức tranh lớn và mục tiêu chính của dự án phải hài lòng với phương pháp thử nghiệm. Tham khảo danh sách uy tín này nhà cung cấp dịch vụ kiểm thử phần mềm người có thể giúp bạn thiết lập các chiến lược thử nghiệm hiệu quả phù hợp với mục tiêu dự án của bạn.

Lập kế hoạch

Lập kế hoạch thực tế là chìa khóa để thực hiện phương pháp thử nghiệm thành công và lịch trình phải đáp ứng nhu cầu của mọi thành viên trong nhóm.

Sản phẩm được xác định

Để giữ tất cả các thành viên của nhóm trên cùng một trang, cần cung cấp các sản phẩm được xác định rõ ràng. Các sản phẩm phân phối phải chứa nội dung trực tiếp mà không có bất kỳ sự mơ hồ nào.

phương pháp thử nghiệm

Sau khi lập kế hoạch hoàn tất và các sản phẩm phân phối được xác định đã được cung cấp, nhóm thử nghiệm sẽ có thể xây dựng phương pháp thử nghiệm phù hợp. Các tài liệu định nghĩa và các cuộc họp của nhà phát triển phải cho nhóm biết về phương pháp thử nghiệm tốt nhất có thể được sử dụng cho dự án.

Báo cáo

Rất khó đạt được báo cáo minh bạch nhưng bước này quyết định tính hiệu quả của phương pháp thử nghiệm được sử dụng trong dự án.

Câu Hỏi Thường Gặp

Đúng vậy, và điều đó khá phổ biến. Các chương trình được quản lý thường áp dụng mô hình quản trị thác nước cho các nhóm triển khai linh hoạt, nhờ đó việc lập tài liệu đáp ứng yêu cầu của kiểm toán viên trong khi quá trình phát triển vẫn duy trì chu kỳ phản hồi ngắn.

Đưa hoạt động kiểm thử lên giai đoạn sớm hơn trong vòng đời phát triển, nhờ đó các lỗi được phát hiện ngay từ khâu yêu cầu và thiết kế thay vì sau khi lập trình. Phát triển dựa trên kiểm thử (Test-Driven Development - TDD) là sự dịch chuyển sang trái được mở rộng đến mức tối đa.

Trí tuệ nhân tạo (AI) rút ngắn chu kỳ phản hồi thay vì thay thế mô hình. Các trường hợp thử nghiệm được tạo tự động, bộ định vị tự phục hồi và lựa chọn dựa trên rủi ro cho phép các chu kỳ linh hoạt ngắn đạt được độ bao phủ mà trước đây cần một giai đoạn dài.

Đúng vậy. Phân tích tác động kiểm thử giúp ánh xạ các thay đổi mã nguồn đến các bài kiểm thử bao phủ chúng, do đó, một quy trình sẽ chạy một tập hợp con được nhắm mục tiêu trong vài phút thay vì phải chạy toàn bộ bộ kiểm thử hồi quy qua đêm.

Đúng vậy, nhưng đơn giản hơn. Phương pháp Agile ưu tiên phần mềm hoạt động hơn là tài liệu đầy đủ, chứ không phải là không có tài liệu nào cả. Tiêu chí chấp nhận, kiểm thử tự động và kế hoạch kiểm thử ngắn gọn vẫn là bằng chứng cần thiết.

Tóm tắt bài viết này với: