Mô hình truyền thống CMMI và mô hình phát triển thác nước
Một thực tế phổ biến trong kiểm thử phần mềm đó là các kiểm thử được thực hiện bởi một nhóm các Tester độc lập sau khi các chức năng được phát triển và trước khi nó được chuyển tới khách hàng. Thực hành này thường là kết quả trong giai đoạn kiểm thử đang được sử dụng như một bộ đệm tham chiếu để bù đắp cho độ trễ tham chiếu do đó ảnh hưởng đến thời gian dành cho việc kiểm thử.
Một thực tế khác là khởi động kiểm thử phần mềm tại cùng một thời điểm bắt đầu dự án và nó là một quá trình liên tục cho đến khi dự án kết thúc.
Mô hình phát triển Agile / Extreme
Ngược lại, một số quy tắc phần mềm đang nổi lên như lập trình cực đoan và sự chuyển động phát triển phần mềm AGILE, tuân thủ mô hình “Test – Driven Development ” (TDD). Trong quy trình này, kiểm thử đơn vị được viết đầu tiên do các kỹ sư phần mềm (thường là lập trình song song trong các phương pháp lập trình Extreme). Tất nhiên những kiểm thử bước đầu thất bại như dự kiến, nhưng sau đó Code được viết xong thì phần lớn các Test Suite sẽ từng bước tăng lên. Nó được cập nhật như là các lỗi điều kiện mới và các trường hợp tiềm ẩn vừa được phát hiện ra, chúng được tích hợp với bất kỳ kiểm thử hồi quy nào được phát triển. Kiểm thử đơn vị được duy trì cùng với phần còn lại của các mã nguồn phần mềm và được tích hợp chung vào quá trình xây dựng (với những kiểm thử tương tác vốn đã bị loại bỏ quá trình xây dựng mức chấp nhận thông thường). Mục tiêu cuối cùng của quá trình kiểm thử này là để đạt được việc triển khai liên tục mà ở đó những cập nhật phần mềm có thể được công bố cho công chúng thường xuyên.
Phương pháp này làm tăng các nỗ lực kiểm thử trước khi động đến bất kỳ nhóm kiểm thử chính thức. Trong một số mô hình phát triển khác, hầu hết việc thực hành các kiểm thử xảy ra sau khi các yêu cầu đã được xác định và quá trình mã hóa đã được hoàn thành.
Mô hình từ trên xuống và mô hình từ dưới lên
Kiểm thử từ dưới lên là một cách tiếp cận để kiểm thử tích hợp nơi các thành phần tồn tại ở cấp độ thấp nhất (Các Module, các biện pháp và các chức năng) được kiểm thử đầu tiên, sau đó tích hợp và sử dụng để tạo thuận lợi cho việc kiểm thử các thành phần cấp cao hơn. Sau khi kiểm thử tích hợp các Module ở cấp độ thấp hơn sẽ tiến hành kiểm thử ở các cấp độ tiếp theo. Quá trình này được lặp đi lặp lại cho đến khi các thành phần ở trật tự trên cùng của hệ thống được kiểm tra. Cách tiếp cận này là chỉ hữu ích khi tất cả hoặc hầu hết các Module có cấp độ phát triển tương đương sẵn sàng được kiểm thử. Phương pháp này cũng giúp xác định các cấp độ phát triển phần mềm và làm cho nó dễ dàng hơn để báo cáo tiến độ kiểm thử theo tỷ lệ phần trăm.
Kiểm thử từ trên xuống là một cách tiếp cận để kiểm thử tích hợp các Module trên đầu với các Module nhánh được kiểm tra từng bước cho đến khi kết thúc Module liên quan.
trong cả hai phương pháp và các trình điều khiển được sử dụng để cố định các thành phần bị thiếu sót và được hoàn thiện ở các cấp độ thay thế.
Một chu kỳ kiểm thử mẫu
Dẫu cho các biến thể tồn tại giữa các tổ chức lập trình thì vẫn có một quy trình điển hình để kiểm thử. Mẫu dưới đây là phổ biến trong các tổ chức sử dụng mô hình phát triển Waterfall (thác nước). Các hoạt động tương tự thường được tìm thấy trong các mô hình phát triển khác, nhưng có thể có hoặc không rõ ràng.
- Phân tích yêu cầu: Kiểm thử thường sẽ bắt đầu lấy các yêu cầu trong các giai đoạn của vòng đời phát triển phần mềm. Trong giai đoạn thiết kế, các Tester làm việc với các nhà phát triển để xác định những khía cạnh của một thiết kế được kiểm chứng và những thông số được kiểm tra.
- Lập kế hoạch kiểm thử: Chiến lược kiểm thử, kế hoạch kiểm thử, kiểm thử sáng tạo… Và có một kế hoạch là cần thiết vì nhiều hoạt động sẽ được thực hiện trong thời gian kiểm thử.
- Kiểm thử phát triển: Các quy trình kiểm thử, các kịch bản, Test Case, các dữ liệu được sử dụng trong kiểm thử phần mềm.
- Kiểm thử thực hiện: Dựa trên các kế hoạch, các văn bản kiểm thử và các báo cáo bất kỳ lỗi nào tìm thấy cho nhóm phát triển.
- Kiểm thử báo cáo: Sau khi hoàn tất kiểm thử, các Tester tạo ra các số liệu và báo cáo cuối cùng về nỗ lực kiểm thử của họ và có sẵn sàng phát hành phần mềm hay không.
- Phân tích kết quả kiểm thử hoặc phân tích thiếu sót được thực hiện bởi đội ngũ phát triển kết hợp với khách hàng để đưa ra quyết định xem những thiếu sót gì cần phải được chuyển giao, cố định và từ bỏ (tức là tìm ra được phần mềm hoạt động chính xác) hoặc giải quyết sau.
- Test lại khiếm khuyết: Khi một khiếm khuyết đã được xử lý bởi đội ngũ phát triển, nó phải được kiểm tra lại bởi nhóm kiểm thử.
- Kiểm thử hồi quy: Người ta thường xây dựng một chương trình kiểm thử nhỏ là tập hợp của các bài kiểm tra cho mỗi tích hợp mới, sửa chữa hoặc cố định phần mềm, để đảm bảo rằng những cung cấp mới nhất đã không phá hủy bất cứ điều gì và toàn bộ phần mềm vẫn còn hoạt động một cách chính xác.
Kiểm thử đóng gói: Mỗi phép thử thỏa mãn các chỉ tiêu truy xuất và thu được những kết quả quan trong như: bài học kinh nghiệm, kết quả, các bản ghi, tài liệu liên quan được lưu trữ và sử dụng như một tài liệu tham khảo cho các dự án trong tương lai.
(Tham khảo: wikipedia.org)
