Về kiểm thử thực tế trong môi trường thật hoặc môi trường công ty

Kiểm thử phần mềm với số liệu thật trong môi trường thực tiễn gọi là gì? Kiểm thử phần mềm với số liệu thật trong môi trường thực tiễn thế nào? Cùng theo dõi nội dung trình bày dưới đây về việc kiểm thử phần mềm với số liệu thật trong môi trường thực tiễn bạn !.

Kiểm thử phần mềm với số liệu thật trong môi trường thực tiễn gọi là

1. Test bed là gì?

Nói chung, Test bed là một môi trường phát triển phần mềm. Nó cho phép các nhà phát triển để kiểm tra các module của họ mà không ảnh hưởng đến các server của production. Test bed không giới hạn dành riêng cho các lập trình viên mà còn được sử dụng bởi Tester. Nó cũng được biết đến như là môi trường kiểm thử .

2. Test Environment là gì?

Một môi trường thử nghiệm là một thiết lập của phần mềm và phần cứng cho các đội kiểm thử để tiến hành kiểm tra các test case. Nói cách khác, nó hỗ trợ thực hiện kiểm thử với phần cứng, phần mềm và cấu hình mạng.

Test bed hoặc môi trường thử nghiệm được cấu hình như là một phần thiết yếu của ứng dụng đng được kiểm thử. Trong một vài trường hợp, Test bed có thể là sự kết hợp của môi trường kiểm thử và các dữ liệu kiểm thử nó hoạt động.

3. Quy trình kiểm thử thực tiễn đối với một dự án thực tiễn:

Bất cứ khi nào chúng tôi nhận được một dự án mới, sẽ có một cuộc meeting khởi động dự án. Trong cuộc họp này, chúng tôi về cơ bản là thảo luận về khách hàng là ai? dự án dự định kéo dài trong bao lâu và thời gian bàn giao là khi nào? Tất cả những người tham gia vào cuộc họp là project manager, teck leads, QA leads, developers, tester, vv…

Từ khi kế hoạch dự án SRS (đặc tả yêu cầu phần mềm) được phát triển. Trách nhiệm của những người kiểm thử là tạo một kế hoạch kiểm thử phần mềm và plan dự án từ file SRS này. Deverloper bắt đầu coding theo design. Công việc của dự án đưuọc chia thành các module khác nhau và các module dự án này được phân chia cho các developer.

Trong thời gian đó, trách nhiệm của mỗi tester là tạo ra các kịch bản test và viết test case theo các module được assign. Chúng tôi cố gắng cover hầu hết tất cả các test case function từ file SRS. Data có thể được duy trì một cách thủ công trong một vài mẫu excel test case hoặc các công cụ theo dõi bug.

Khi developer hoàn thành các module riêng lẻ, những module này được assign cho các tester. Smoke testing được thực hiện trên các module này và nếu việc kiểm thử chúng bị fail thì sẽ được assign lại cho các developer tương ứng để fix.

Đối với những module đã pass, việc kiểm thử thủ công sẽ được thực hiện theo file test case đã viết. Bất kỳ bug nào được tìm thấy, chúng sẽ được assign lại cho developer thực hiện module đó và log trên công cụ quản lý bug. Sau khi bug đã được fix, tester sẽ kiểm tra lại lỗi và thực hiện kiểm thử hồi quy tất cả các module có liên quan. Nếu bug đã pass thì sẽ được đánh dấu trạng thái là đã đóng. Nếu không thì chu kỳ lỗi sẽ tiếp tục được lặp đi lặp lại.

Các loại kiểm thử khác nhau được thực hiện trên từng module và thực hiện kiểm thử tích hợp trên molule tích hợp. Các kiểm thử này bao gồm: Kiểm tra tính thương thích, kiểm thử ứng dụng trên các phần cứng khác nhau, các phiên bản hệ điều hành khác nhau, các nền tảng phần mềm khác nhau và trên các trình duyệt khác nhau…

Load và stress testing cũng được thực hiện theo SRS. Cuối cùng, system testing được thực hiện bằng cách tạo môi trường khách hàng giả lập. Khi pass hết tất cả các trường hợp kiểm thử đã được chuẩn bị và quyết định đưa ra để phát hành sản phẩm.

4. Các bước thực hiện kiểm thử:

Dưới đây là chi tiết mỗi bước kiểm thử được thực hiện trong quản lý chất lượng phần mềm và vòng đời kiểm thử được xác định theo tiêu chuẩn IEEE và ISO:

1. Review SRS: Xem xét các đặc tả yêu cầu của phần mềm.
2. Các mục tiêu cần được thực hiện trong bản release chính.
3. Target ngày đã được lên kế hoạch cho các phiên bản release.
4. Kế hoặc chi tiết của dự án đã được xây dựng. Điều này bao gồm các quyết định về thiết kế Design.
5. Xây dựng kế hoặc kiểm thử dựa trên thiết kế Design.
6. Kế hoạch kiểm thử: bao gồm các mục tiêu, phương pháp áp dụng trong khi kiểm thử, các tính năng cần được kiểm thử và không được kiểm thử, các tiêu trí rủi ro, schedule kiểm thử, hỗ trợ đa nền tảng và phân bố nguồn lực để kiểm thử.
7. Test Specifications Tài liệu này bao gồm các chi tiết kỹ thuật (các yêu cầu phần mềm) cần thiết trước khi thực hiện kiểm thử.
8. Viết test case

• Smoke (BVT) test case
• Chuẩn hóa Test cases
• Đề ra các Test Cases xấu
• Mở rộng Test Cases

9. Phát triển – Các module được phát triển theo từng phần riêng biệt.
10. Ràng buộc cài đặt: Trình cài đặt được xây dựng xung quanh các sản phẩm độc lập.
11. Thủ tục Build: Một bản build bao gồm các bộ cài các sản phẩm có sẵn – đa nền tảng.
12. Testing Kiểm thử Smoke (BVT): Kiểm thử ứng dụng cơ bản để quyết định kiểm thử thêm

• Kiểm thử các tính năng mới
• Kiểm thử đa nền tảng, đa trình duyệt
• Kiểm thử stress và kiểm thử sự rò rỉ memory

13. Báo cáo tóm tắt kiểm thử Báo cáo bug và các báo cáo khác đã được tạo.
14. Code freezing Không có thêm tính năng nào được thêm vào tại thời gian này.
15. Testing Build và kiểm thử hồi quy.
16. Quyết định release sản phẩm.
17. Kịch bản sau release cho các mục tiêu tiếp theo.

Hy vọng nội dung trình bày trên đã gửi tới những thông tin bổ ích về kiểm thử phần mềm với số liệu thật trong môi trường thực tiễn. Nếu có những câu hỏi và câu hỏi liên quan đến kiểm thử phần mềm với số liệu thật trong môi trường thực tiễn hãy liên hệ Công ty Luật LVN Group để được tư vấn và hỗ trợ.