Các mô hình xây dựng quy trình kiểm thử – Hậu Cần IT

Mô hình truyền thống CMMI và mô hình phát triển thác nước

Một thực tiễn phổ cập trong kiểm thử phần mềm đó là các kiểm thử được thực thi bởi một nhóm các Tester độc lập sau khi các tính năng được tăng trưởng và trước khi nó được chuyển tới người mua. Thực hành này thường là tác dụng trong tiến trình kiểm thử đang được sử dụng như một bộ đệm tham chiếu để bù đắp cho độ trễ tham chiếu do đó tác động ảnh hưởng đến thời hạn dành cho việc kiểm thử .Một trong thực tiễn khác là khởi động kiểm thử phần mềm tại cùng một thời gian khởi đầu dự án Bất Động Sản và nó là một quy trình liên tục cho đến khi dự án Bất Động Sản kết thúc .

Mô hình phát triển Agile / Extreme

trái lại, một số ít quy tắc phần mềm đang nổi lên như lập trình cực đoan và sự hoạt động tăng trưởng phần mềm AGILE, tuân thủ quy mô “ Test – Driven Development ” ( TDD ). Trong quy trình này, kiểm thử đơn vị chức năng được viết tiên phong do các kỹ sư phần mềm ( thường là lập trình song song trong các giải pháp lập trình Extreme ). Tất nhiên những kiểm thử trong bước đầu thất bại như dự kiến, nhưng sau đó Code được viết xong thì hầu hết các Test Suite sẽ từng bước tăng lên. Nó được update như thể các lỗi điều kiện kèm theo 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 tăng trưởng. Kiểm thử đơn vị chức năng đượ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 quy trình kiến thiết xây dựng ( với những kiểm thử tương tác vốn đã bị vô hiệu quy trình kiến thiết xây dựng mức gật đầu thường thì ). Mục tiêu ở đầu cuối của quy trình kiểm thử này là để đạt được việc tiến hành liên tục mà ở đó những update phần mềm hoàn toàn có thể được công bố cho công chúng tiếp tục .

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 sống sót ở Lever thấp nhất ( Các Module, các giải pháp và các tính năng ) được kiểm thử tiên phong, sau đó tích hợp và sử dụng để tạo thuận tiện 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 ở Lever thấp hơn sẽ triển khai kiểm thử ở các Lever tiếp theo. Quá trình này được lặp đi tái diễn cho đến khi các thành phần ở trật tự trên cùng của mạng lưới hệ thống được kiểm tra. Cách tiếp cận này là chỉ hữu dụng khi tổng thể hoặc hầu hết các Module có Lever tăng trưởng tương tự chuẩn bị sẵn sàng được kiểm thử. Phương pháp này cũng giúp xác lập các Lever tăng trưởng phần mềm và làm cho nó thuận tiện hơn để báo cáo giải trình quá trình kiểm thử theo tỷ suất 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 tương quan .trong cả hai chiêu thức và các trình tinh chỉnh và điều khiển được sử dụng để cố định và thắt chặt các thành phần bị thiếu sót và được hoàn thành xong ở các Lever thay thế sửa chữa .

Một chu kỳ kiểm thử mẫu

Dẫu cho các biến thể sống sót giữa các tổ chức triển khai lập trình thì vẫn có một quy trình nổi bật để kiểm thử. Mẫu dưới đây là thông dụng trong các tổ chức triển khai sử dụng quy mô tăng trưởng Waterfall ( thác nước ). Các hoạt động giải trí tương tự như thường được tìm thấy trong các quy mô tăng trưởng khác, nhưng hoàn toàn 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 nhu cầu các chỉ tiêu truy xuất và thu được những tác dụng quan trong như : bài học kinh nghiệm kinh nghiệm tay nghề, hiệu quả, các bản ghi, tài liệu tương quan được tàng trữ và sử dụng như một tài liệu tìm hiểu thêm cho các dự án Bất Động Sản trong tương lai .( Tham khảo : wikipedia.org )

Share

Pin

0 Shares

Source: https://vh2.com.vn
Category : Truyền Thông