System Testing bao gồm kiểm tra một hệ thống phần mềm tích hợp đầy đủ. Nói chung, một hệ thống máy tính được tạo ra với sự tích hợp của phần mềm (bất kỳ phần mềm nào cũng chỉ là một phần tử duy nhất của hệ thống máy tính). Phần mềm được phát triển theo đơn vị và sau đó được giao tiếp với phần mềm và phần cứng khác để tạo ra một hệ thống máy tính hoàn chỉnh.
Các bài viết liên quan:
Nói cách khác, hệ thống máy tính bao gồm một nhóm phần mềm để thực hiện các nhiệm vụ khác nhau, nhưng chỉ có phần mềm không thể thực hiện nhiệm vụ; đối với phần mềm đó phải được giao diện với phần cứng tương thích. System Testing là một loạt các loại kiểm tra khác nhau với mục đích để thực hiện và kiểm tra hoạt động đầy đủ của một hệ thống máy tính phần mềm tích hợp so với các yêu cầu.
Để kiểm tra luồng end-to-end của một ứng dụng hoặc phần mềm với tư cách người dùng được gọi là System Testing. Trong phần này, chúng tôi điều hướng (xem qua) tất cả các mô-đun cần thiết của một ứng dụng và kiểm tra xem các tính năng cuối cùng hoặc hoạt động kinh doanh cuối có hoạt động tốt hay không và kiểm tra sản phẩm như một hệ thống.
Đó là thử nghiệm end-to-end trong đó môi trường thử nghiệm tương tự như môi trường sản xuất.
Có bốn cấp độ kiểm thử phần mềm: unit testing, integration testing, system testing và acceptance testing, tất cả đều được sử dụng cho mục đích kiểm thử. Kiểm thử đơn vị được sử dụng để kiểm tra một phần mềm duy nhất; Kiểm thử tích hợp được sử dụng để kiểm tra một nhóm đơn vị phần mềm, System Testing được sử dụng để kiểm tra toàn bộ hệ thống và Kiểm thử chấp nhận được sử dụng để kiểm tra khả năng chấp nhận của các yêu cầu nghiệp vụ. Ở đây chúng ta đang thảo luận về System Testing là cấp độ thứ ba của các cấp độ kiểm thử.
Xem thêm Hướng dẫn Hệ điều hành- Operating System( OS)
Hệ thống phân cấp các cấp độ kiểm tra
Chủ yếu có hai phương pháp được sử dụng rộng rãi để kiểm thử phần mềm, một là kiểm thử hộp trắng sử dụng mã hóa nội bộ để thiết kế các trường hợp thử nghiệm và một phương pháp khác là kiểm thử hộp đen sử dụng GUI hoặc quan điểm người dùng để phát triển các trường hợp thử nghiệm.
- White box testing
- Black box testing
System Testing nằm trong White box testing vì nó bao gồm kiểm tra hoạt động bên ngoài của phần mềm. Kiểm tra theo quan điểm của người dùng để xác định các lỗi nhỏ.
System Testing bao gồm các bước sau.
- Xác minh các chức năng đầu vào của ứng dụng để kiểm tra xem nó có tạo ra đầu ra mong đợi hay không.
- Kiểm thử phần mềm tích hợp bằng cách bao gồm các thiết bị ngoại vi bên ngoài để kiểm tra sự tương tác của các thành phần khác nhau với nhau.
- Kiểm tra toàn bộ hệ thống để kiểm tra End to End.
- Kiểm tra hành vi của ứng dụng thông qua trải nghiệm của người có kinh nghiêm
Xem thêm Các loại hệ điều hành(operating System)
Ví dụ về System Testing
Giả sử chúng ta mở một ứng dụng, chẳng hạn như www.rediff.com, và ở đó chúng ta có thể thấy một quảng cáo được hiển thị trên đầu trang chủ và nó vẫn ở đó trong vài giây trước khi nó biến mất. Các loại Quảng cáo này được thực hiện bởi Hệ thống Quản lý Quảng cáo (AMS). Bây giờ, chúng tôi sẽ thực hiện System Testing cho loại trường này.
Ứng dụng dưới đây hoạt động theo cách sau:
- Giả sử rằng Amazon muốn hiển thị quảng cáo khuyến mãi vào ngày 26 tháng 1 lúc 10 giờ sáng trên trang chủ của Rediff cho quốc gia Ấn Độ.
- Sau đó, người quản lý bán hàng đăng nhập vào trang web và tạo một yêu cầu cho một quảng cáo được ghi ngày cho ngày trên.
- Anh ấy / cô ấy đính kèm một tệp có thể là tệp hình ảnh hoặc tệp video của AD và áp dụng.
- Ngày hôm sau, người quản lý AMS của Rediffmail đăng nhập vào ứng dụng và xác minh Yêu cầu quảng cáo đang chờ đợi.
- Người quản lý AMS sẽ kiểm tra các yêu cầu quảng cáo của Amazons đó có đang chờ xử lý hay không và sau đó anh ta / cô ta sẽ kiểm tra xem có còn trống cho ngày và giờ cụ thể hay không.
- Nếu có không gian ở đó, thì anh ấy / cô ấy sẽ đánh giá chi phí đăng Quảng cáo là 15 đô la mỗi giây và chi phí quảng cáo tổng thể trong 10 giây là gần đúng 150 đô la.
- Người quản lý AMS nhấp vào yêu cầu thanh toán và gửi giá trị ước tính cùng với yêu cầu thanh toán cho người quản lý Amazon.
- Sau đó, người quản lý amazon đăng nhập vào trạng thái Quảng cáo và xác nhận yêu cầu thanh toán, và anh ấy / cô ấy thực hiện thanh toán theo tất cả các chi tiết và nhấp vào Gửi và Thanh toán
- Ngay sau khi người quản lý AMs của Rediff nhận được số tiền, anh ấy / cô ấy sẽ thiết lập Quảng cáo cho ngày và giờ cụ thể trên trang chủ của Rediffmail.
Các tình huống System Testing khác nhau như sau:
Tình huống 1: Thử nghiệm đầu tiên là kịch bản chung, như chúng ta đã thảo luận ở trên. Kỹ sư kiểm tra sẽ thực hiện System Testing cho tình huống cơ bản trong đó người quản lý Amazon tạo yêu cầu cho Quảng cáo và Quảng cáo đó được sử dụng vào một ngày và giờ cụ thể.
Tình huống 2: Giả sử người quản lý Amazon cảm thấy không gian quảng cáo quá đắt và hủy yêu cầu. Đồng thời, Flipkart yêu cầu Không gian quảng cáo vào ngày 26 tháng 1 lúc 10:00 sáng. Sau đó, yêu cầu của Amazon đã bị hủy bỏ. Vì vậy, quảng cáo khuyến mãi của Flipkart phải được sắp xếp vào ngày 26 tháng 1 lúc 10 giờ sáng.
Sau khi tất cả, yêu cầu và thanh toán đã được thực hiện. Bây giờ, nếu Amazon thay đổi quyết định và họ cảm thấy rằng họ đã sẵn sàng thanh toán cho ngày 26 tháng 1 lúc 10 giờ sáng, điều này nên được đưa ra vì Flipkart đã sử dụng không gian đó. Do đó, một lịch khác phải mở ra để Amazon thực hiện đặt phòng của họ.
Tình huống 3: trong phần này, trước tiên, chúng tôi đăng nhập với tư cách là người quản lý AMS, sau đó nhấp vào trang Đặt giá và đặt giá cho không gian quảng cáo trên trang đăng xuất thành 10 đô la mỗi giây.
Sau đó đăng nhập với tư cách người quản lý Amazon và chọn ngày giờ đưa lên và Quảng cáo trên trang đăng xuất. Và khoản thanh toán phải là 100 đô la cho 10 giây của một trang đăng xuất Quảng cáo trên Rediffmail.
Lưu ý: Nói chung, mọi kỹ sư kiểm thử chỉ thực hiện kiểm tra chức năng, tích hợp và hệ thống trên mô-đun được chỉ định của họ.
Như chúng ta có thể thấy trong hình ảnh bên dưới, chúng ta có ba mô-đun khác nhau như Khoản vay, Bán hàng và Thấu chi. Và các mô-đun này sẽ chỉ được kiểm tra bởi các kỹ sư kiểm tra được chỉ định của họ bởi vì nếu luồng dữ liệu giữa các mô-đun hoặc kịch bản này, thì chúng ta cần xác định rõ rằng nó đang chạy trong mô-đun nào và kỹ sư kiểm tra đó nên kiểm tra điều đó.
Hãy giả sử rằng ở đây chúng tôi đang thực hiện System Testing về ước tính lãi suất, trong đó khách hàng lấy Thấu chi lần đầu tiên cũng như lần thứ hai.
Trong ví dụ cụ thể này, chúng tôi có các tình huống sau:
Các tình huống 1
- Đầu tiên, chúng tôi sẽ đăng nhập với tư cách là Người dùng; hãy xem P, và đăng ký thấu chi Rs15000, nhấp vào áp dụng và đăng xuất.
- Sau đó, chúng tôi sẽ đăng nhập với tư cách là Người quản lý và phê duyệt Thấu chi của P, và đăng xuất.
- Một lần nữa, chúng tôi sẽ đăng nhập với tư cách là P và kiểm tra số dư Thấu chi; 15000 Rs phải được đặt cọc và đăng xuất.
- Sửa đổi ngày máy chủ thành 30 ngày tiếp theo.
- Đăng nhập bằng P, kiểm tra Số dư thấu chi là 15000+ 300 + 200 = 15500, so với đăng xuất
- Đăng nhập với tư cách là Người quản lý, nhấp vào Nạp tiền và Nạp tiền Rs500, đăng xuất.
- Đăng nhập bằng P, Trả lại số tiền Thấu chi và kiểm tra số dư Thấu chi, bằng 0 Rs.
- Đăng ký Thấu chi trả trước dưới dạng hai tháng lương.
- Được Người quản lý phê duyệt, số tiền tín dụng và tiền lãi sẽ được tính vào phí xử lý lần đầu tiên.
- Đăng nhập người dùng → Trang chủ [Khoản vay, Bán hàng, Thấu chi] → Trang thấu chi [Thấu chi số tiền, Áp dụng thấu chi, Thấu chi trả nợ] → Ứng dụng
- Quản lý đăng nhập → Trang chủ [Khoản vay, Bán hàng, Thấu chi] → Trang thấu chi [Thấu chi số tiền, Áp dụng thấu chi, Thấu chi trả nợ, Phê duyệt thấu chi] → Trang Phê duyệt → Phê duyệt đơn đăng ký.
- Đăng nhập với tư cách người dùng P → Trang chủ [Khoản vay, Bán hàng, Thấu chi] → Trang thấu chi [Thấu chi số tiền, Áp dụng thấu chi, Thấu chi trả nợ] → Thấu chi được chấp thuận → Thấu chi số tiền
- Đăng nhập với tư cách người dùng P → Trang chủ [Khoản vay, Bán hàng, Thấu chi] → Trang thấu chi [Thấu chi số tiền, Áp dụng thấu chi, Thấu chi hoàn trả] → Thấu chi hoàn trả → với phí xử lý + số tiền lãi.
Tình huống 2
Bây giờ, chúng tôi thử nghiệm kịch bản thay thế trong đó ngân hàng cung cấp ưu đãi, trong đó nói rằng khách hàng nhận Rs45000 làm Thấu chi lần đầu tiên sẽ không tính phí Quy trình. Phí xử lý sẽ không được hoàn lại khi khách hàng chọn khoản thấu chi khác lần thứ ba.
Chúng tôi phải kiểm tra tình huống thứ ba, trong đó khách hàng nhận Thấu chi 45000 Rs lần đầu tiên và cũng xác minh rằng Thấu chi trả lại số dư sau khi đăng ký một khoản thấu chi khác lần thứ ba.
Tình huống 3
Trong điều này, chúng tôi sẽ phản ánh rằng ứng dụng đang được sử dụng chung bởi tất cả khách hàng, đột nhiên ngân hàng quyết định giảm phí xử lý xuống 100 Rs cho khách hàng mới và chúng tôi đã thử nghiệm Thấu chi cho khách hàng mới và kiểm tra xem ứng dụng có được chấp nhận hay không chỉ với Rs100.
Nhưng sau đó chúng tôi nhận được xung đột trong yêu cầu, giả sử khách hàng đã nộp đơn cho Rs15000 dưới dạng Thấu chi với phí quy trình hiện tại là 200 Rs. Trước khi Người quản lý chưa phê duyệt, ngân hàng sẽ giảm phí quy trình xuống 100 Rs.
Bây giờ, chúng tôi phải kiểm tra xem phí quy trình nào được tính cho Thấu chi cho khách hàng đang chờ xử lý. Và nhóm thử nghiệm không thể giả định bất cứ điều gì; họ cần giao tiếp với Nhà phân tích kinh doanh hoặc Khách hàng và tìm hiểu những gì họ muốn trong những trường hợp đó.
Vì vậy, nếu khách hàng đưa ra những yêu cầu đầu tiên, chúng tôi phải đưa ra những kịch bản tối đa có thể.
Xem thêm Cấu trúc Directory trong hệ điều hành
Các loại System Testing
System Testing được chia thành hơn 50 loại, nhưng các công ty kiểm thử phần mềm thường sử dụng một số loại trong số đó. Chúng được liệt kê dưới đây:
Regression Testing
Regression Testing được thực hiện trong quá trình System Testing để xác nhận và xác định rằng nếu có bất kỳ lỗi nào trong hệ thống do sửa đổi trong bất kỳ phần nào khác của hệ thống. Nó đảm bảo rằng bất kỳ thay đổi nào được thực hiện trong quá trình phát triển không tạo ra một khiếm khuyết mới và cũng mang lại sự đảm bảo; các khiếm khuyết cũ sẽ không tồn tại khi bổ sung phần mềm mới theo thời gian.
Load Testing
Kiểm tra tải được thực hiện dưới System Testing để làm rõ liệu hệ thống có thể hoạt động dưới tải thời gian thực hay không.
Functional Testing
Kiểm tra chức năng của một hệ thống được thực hiện để tìm xem có bất kỳ chức năng nào bị thiếu trong hệ thống hay không. Tester lập danh sách các chức năng quan trọng cần có trong hệ thống và có thể được bổ sung trong quá trình kiểm tra chức năng và sẽ cải thiện chất lượng của hệ thống.
Recovery Testing
Kiểm tra phục hồi của một hệ thống là được định dạng trong quá trình System Testing để xác nhận độ tin cậy, độ tin cậy, trách nhiệm giải trình của hệ thống và tất cả đều nằm ở kỹ năng phục hồi của hệ thống. Nó sẽ có thể khôi phục thành công từ tất cả các sự cố hệ thống có thể xảy ra.
Trong thử nghiệm này, chúng tôi sẽ kiểm tra ứng dụng để kiểm tra xem ứng dụng phục hồi như thế nào sau sự cố hoặc thảm họa.
Kiểm tra khôi phục bao gồm các bước sau:
- Bất cứ khi nào phần mềm gặp sự cố, phần mềm đó không được biến mất mà nên viết thông báo nhật ký sự cố hoặc thông báo nhật ký lỗi trong đó nêu lý do sự cố. Ví dụ: C: // Program Files / QTP / Cresh.log
- Nó sẽ giết thủ tục của chính nó trước khi nó biến mất. Giống như, trong Windows, chúng ta có Trình quản lý tác vụ để hiển thị quá trình nào đang chạy.
- Chúng tôi sẽ giới thiệu về lỗi và sự cố ứng dụng, có nghĩa là ai đó sẽ dẫn chúng tôi đến cách thức và thời điểm ứng dụng sẽ gặp sự cố. Hoặc Bằng kinh nghiệm, sau vài tháng tham gia làm việc với sản phẩm, chúng tôi có thể biết được cách thức và thời điểm ứng dụng gặp sự cố.
- Mở lại ứng dụng; ứng dụng phải được mở lại với các cài đặt trước đó.
Ví dụ: Giả sử chúng ta đang sử dụng trình duyệt Google Chrome thì bị mất nguồn, sau đó chúng ta bật hệ thống lên và mở lại Google chrome thì nhận được thông báo muốn bắt đầu phiên làm việc mới hay khôi phục lại phiên bản cũ. phiên họp. Đối với bất kỳ sản phẩm đã phát triển nào, nhà phát triển viết một chương trình khôi phục mô tả lý do tại sao phần mềm hoặc ứng dụng gặp sự cố, thông báo nhật ký sự cố có được viết hay không, v.v.
Migration Testing
Thử nghiệm di chuyển được thực hiện để đảm bảo rằng nếu hệ thống cần được sửa đổi trong cơ sở hạ tầng mới thì nó sẽ được sửa đổi mà không gặp bất kỳ sự cố nào.
Usability Testing
Mục đích của thử nghiệm này để đảm bảo rằng hệ thống đã quen thuộc với người dùng và nó đáp ứng mục tiêu của nó cho những gì nó phải làm.
Để biết thêm thông tin về kiểm tra khả năng sử dụng, hãy tham khảo liên kết dưới đây:
Software and Hardware Testing
Việc System Testing này nhằm mục đích kiểm tra khả năng tương thích của phần cứng và phần mềm. Cấu hình phần cứng phải tương thích với phần mềm để chạy nó mà không gặp bất kỳ vấn đề gì. Khả năng tương thích cung cấp tính linh hoạt bằng cách cung cấp các tương tác giữa phần cứng và phần mềm.
Tại sao System Testing lại Quan trọng?
- System Testing đảm bảo hàng trăm phần trăm về hiệu suất của hệ thống vì nó bao gồm chức năng đầu cuối của hệ thống.
- Nó bao gồm kiểm tra kiến trúc phần mềm hệ thống và các yêu cầu nghiệp vụ.
- Nó giúp giảm thiểu các vấn đề trực tiếp và lỗi ngay cả sau khi sản xuất.
- System Testing sử dụng cả hệ thống hiện có và hệ thống mới để cung cấp cùng một dữ liệu trong cả hai và sau đó so sánh sự khác biệt về chức năng của các chức năng đã thêm và chức năng hiện có, do đó, người dùng có thể hiểu được lợi ích của các chức năng mới được bổ sung của hệ thống.
Kiểm tra bất kỳ ứng dụng nào
Ở đây, chúng tôi sẽ kiểm tra ứng dụng Gmail để hiểu cách hoạt động của Kiểm tra chức năng, tích hợp và Hệ thống.
Giả sử, chúng ta phải kiểm tra các phân hệ khác nhau như Đăng nhập, Soạn thư, Thư nháp, Hộp thư đến, Mục đã gửi, Thư rác, Trò chuyện, Trợ giúp, Đăng xuất của ứng dụng Gmail.
Trước tiên, chúng tôi thực hiện Kiểm tra chức năng trên tất cả các Mô-đun, sau đó chỉ chúng tôi mới có thể thực hiện kiểm tra tích hợp và System Testing.
Trong kiểm thử chức năng, ít nhất chúng ta có một mô-đun để thực hiện kiểm thử chức năng. Vì vậy, ở đây chúng tôi có Mô-đun Soạn thư nơi chúng tôi đang thực hiện kiểm tra chức năng.
Compose
Các thành phần khác nhau của mô-đun Soạn thư là To, CC, BCC, Subject, Attachment, Body, Sent, Save to Draft, Close.
Đối với các thành phần CC & BCC, chúng tôi sẽ lấy đầu vào tương tự như thành phần Tới.
Đối với thành phần Chủ đề, chúng tôi sẽ thực hiện các đầu vào và tình huống sau:
Login
- Đầu tiên, chúng ta sẽ nhập tên người dùng và mật khẩu để đăng nhập vào ứng dụng và Kiểm tra tên người dùng trên Trang chủ.
Compose
- Soạn thư, gửi và kiểm tra thư trong Mục đã gửi [người gửi]
- Soạn thư, gửi và kiểm tra thư trong người nhận [Hộp thư đến]
- Soạn thư, gửi và tự kiểm tra thư [Hộp thư đến]
- Soạn thư, nhấp vào Lưu dưới dạng Bản nháp và đăng ký bản nháp của người gửi.
- Soạn thư, gửi id không hợp lệ (định dạng hợp lệ) và kiểm tra thư chưa được gửi.
- Soạn thư, đóng và đăng ký Thư nháp.
Inbox
- Chọn e-mail, trả lời và kiểm tra các mục đã gửi hoặc Hộp thư đến của người nhận.
- Chọn thư trong Hộp thư đến để trả lời, Lưu dưới dạng Thư nháp và kiểm tra trong Thư nháp.
- Chọn thư, sau đó xóa nó và kiểm tra trong Thùng rác.
Sent Item
- Chọn e-mail, Mục đã gửi, Trả lời hoặc Chuyển tiếp, và chọn mục Đã gửi hoặc hộp thư đến của người nhận.
- Chọn thư, Mục đã gửi, Trả lời hoặc Chuyển tiếp, Lưu dưới dạng Thư nháp và xác minh trong Thư nháp.
- Chọn thư, xóa và kiểm tra trong Thùng rác.
Draft
- Chọn bản nháp email, chuyển tiếp và chọn Mục đã gửi hoặc Hộp thư đến.
- Chọn bản nháp email, xóa và xác minh trong Thùng rác.
Chat
- Trò chuyện với người dùng ngoại tuyến được lưu trong hộp thư đến của người nhận.
- Trò chuyện với người dùng và xác minh trong cửa sổ trò chuyện.
- Trò chuyện với người dùng và kiểm tra lịch sử trò chuyện.
