● Các giai đoạn cần kiểm thử sản phẩm:
○ Theo như hình trên, trước khi bất kỳ một phiên bản Platform 4.x.x nào được phát hành ra ngoài thị trường thì sẽ có 5 giai đoạn kiểm thử cho các phiên bản: 4.x-M2, 4.x-M1, 4.x-RC2, 4.x-RC1 và 4.x.x.
○ Số lượng kịch bản kiểm thử cho mỗi ứng dụng (như ECMS, Calendar, Wiki, Forums, FAQ …) có thể giao động từ 100 đến khoàng 1000 trường hợp kiểm thử cho mỗi môi trường. Dưới đây là một số thống kê về số lượng kịch bản kiểm thử của một vài chức năng trong hệ thống. Số lượng này tính theo một môi trường (Ví dụ: môi trường Ubuntu+Firefox+MySQL+Tomcat)
Feature Số lƣợng testcase Wiki 342 Gatein 235 PLF 795 Forum 283 ECMS 1132 Calendar 455 Social 620
● Để kiểm thử cho tất cả ứng dụng, hệ điều hành, trình duyệt và cơ sở dữ liệu khác nhau, số lượng kịch bản kiểm thử sẽ rất lớn. Bên cạnh đó các feature mới cũng phải tiến hành kiểm thử song song với các feature cũ. Có thể thấy nguồn lực cho kiểm thử hồi quy (Regression test) và các kiểm thử cho feature mới sẽ rất lớn.
● Ngoài ra, công ty cũng sử dụng CI để deploy sản phẩm hàng ngày. Để có thể phát hiện ra sớm những vấn để của sản phẩm, kiểm thử tự động cũng sẽ được tích hợp CI để test những sản phẩm hàng ngày đó.
● Từ những lợi ích của BDD-Cucumber-Selenium-TestLink-CI, tôi và các bạn đồng nghiệp đã xây dựng Framework tích hợp điểm mạnh của BDD- Cucumber-Selenium-TestLink-CI để hỗ trợ quá trình kiểm thử, build dự án, phát hành sản phẩm với chất lượng tốt hơn.
● Dưới đây là kết quả cài đặt, chạy thử và đánh giá kết quả của framework. Do quy định về luật bảo mật của dự án và quy định vê luật bảo mật của công ty, tôi sẽ không sử dụng mã nguồn chi tiết trong dự án đang triển khai ở công ty mà sẽ sử dụng mã nguồn tôi viết để kiểm thử một trang web application (live.guru99.com). Tuy nhiên cấu trúc dự án, cấu trúc mã nguồn và kết quả đánh giá sẽ dựa vào dự án thực tế tôi đang triển khai.