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ề.

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
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
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
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
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 -
- 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.
- 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
- Viết một số mã để triển khai tính năng/chức năng
- 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.




