Trong kiểm thử phần mềm, người kiểm thử thực hiện nhiều cấp độ kiểm thử khác nhau. Từ unit testing đến acceptance testing, đảm bảo rằng tất cả các thành phần của sản phẩm được kiểm tra kỹ lưỡng, không có bất kỳ trở ngại nào. Được thực hiện sau khi integration testing và trước khi acceptance tests, system test là một trong những cấp độ kiểm thử phần mềm, sẽ được thảo luận chi tiết dưới đây.
1. Kiểm thử hệ thống là gì?
Kiểm thử hệ thống là cấp độ kiểm thử đánh giá hành vi của một hệ thống phần mềm tích hợp đầy đủ dựa trên các yêu cầu và thông số kỹ thuật được xác định trước. Đó là một giải pháp cho câu hỏi ” nếu hệ thống hoàn chỉnh hoạt động theo các yêu cầu được xác định trước của nó?”
Một số cân nhắc quan trọng đối với thử nghiệm Hệ thống là:
•Thứ nhất, hiệu suất của Kiểm thử hệ thống xảy ra trong một hệ thống được tích hợp và phát triển đầy đủ.
•Thứ hai, hiệu suất của các bài kiểm tra Hệ thống xảy ra trên toàn bộ hệ thống trong bối cảnh các thông số kỹ thuật yêu cầu chức năng (FRS) hoặc thông số kỹ thuật yêu cầu hệ thống (SRS) hoặc cả hai. Nói cách khác, các bài kiểm tra Hệ thống xác nhận không chỉ thiết kế mà còn cả các khía cạnh hành vi và khả năng sử dụng.
•Ngoài những điều trên, nó xác minh toàn bộ sản phẩm, sau khi tích hợp tất cả các thành phần phần mềm và phần cứng và xác nhận nó theo các thông số kỹ thuật.
•Hơn nữa, Kiểm thử hệ thống có thể bao gồm cả loại kiểm thử chức năng và phi chức năng.
Ví dụ:
Chúng ta hãy lấy trường hợp của một nhà sản xuất ô tô. Một nhà sản xuất xe hơi không sản xuất chiếc xe như một chiếc xe hoàn chỉnh. Mỗi thành phần xe hơi được sản xuất riêng biệt, chẳng hạn như ghế ngồi, tay lái, gương, phanh, dây cáp, động cơ, khung xe, bánh xe, v.v. Sau khi sản xuất từng mặt hàng, thử nghiệm độc lập sẽ xảy ra để xem liệu chúng có hoạt động theo cách mà chúng phải làm không công việc. Nó được gọi là Unit testing .
Sau khi lắp ráp từng bộ phận, việc xác minh sẽ xảy ra. Nó kiểm tra xem việc lắp ráp có tạo ra bất kỳ tác dụng phụ nào đối với chức năng của từng thành phần hay không. Ngoài ra, việc kiểm tra hoạt động trơn tru của cả hai thành phần cũng diễn ra. Nó được gọi là kiểm thử Tích hợp .
Sau khi tất cả các bộ phận đã được lắp ráp và chiếc xe đã ở đúng vị trí – Chúng ta có thể cho rằng chiếc xe đã sẵn sàng lái một cách an toàn không? Toàn bộ Xe phải được kiểm tra các khía cạnh khác nhau theo các yêu cầu đã xác định, như thể:
•Xe có thể vận hành trơn tru, hệ thống phanh, bánh răng và các chức năng khác hoạt động chính xác (Kiểm tra chức năng).
•Túi khí sẽ bung ra trong trường hợp va chạm (Kiểm tra không hoạt động).
Và tất cả nỗ lực kiểm tra này được gọi là Kiểm tra Hệ thống, nhằm xác minh chiếc xe trên mọi khía cạnh.
Một khi chiếc xe được lắp ráp và sẵn sàng để sử dụng, chúng ta có thể tung nó ra công chúng không? Không, chúng tôi có một cấp độ kiểm tra khác được gọi là Kiểm tra sự chấp nhận của người dùng , trong đó một nhóm Người dùng / Khách hàng sẽ kiểm tra xe trong điều kiện thực tế. Họ sẽ lái chiếc xe trên đường, xem chiếc xe hoạt động như thế nào về sự thoải mái tổng thể, trải nghiệm và các tính năng chính như Phanh, Bánh răng, hệ thống âm nhạc, v.v. Sau khi vượt qua giai đoạn UAT, thì Xe đã sẵn sàng để lăn bánh cho khách hàng.
2. Mục tiêu của kiểm thử hệ thống
•Một trong những mục tiêu chính của Kiểm thử hệ thống là giảm thiểu rủi ro. Ngay cả sau khi thử nghiệm riêng lẻ các thành phần, rủi ro về cách tất cả chúng sẽ kết hợp với nhau để tạo thành một Hệ thống hoàn chỉnh vẫn tồn tại. Kiểm tra hệ thống loại bỏ rủi ro này bằng cách đảm bảo rằng nó sẽ hoạt động theo yêu cầu của khách hàng.
•Kiểm thử hệ thống phải xác minh xem thiết kế của các hành vi chức năng và phi chức năng của hệ thống có phù hợp với thông số kỹ thuật của khách hàng hay không.
•Xác thực rằng hệ thống đã hoàn tất và sẽ hoạt động như mong đợi.
•Kiểm thử hệ thống nhằm mục đích xây dựng niềm tin vào chất lượng của toàn bộ hệ thống.
•Kiểm tra hệ thống cũng nhằm mục đích tìm ra các khuyết tật và ngăn chặn các khuyết tật thoát ra các cấp độ kiểm tra hoặc sản xuất cao hơn. Ngoài ra, đây là giai đoạn duy nhất xảy ra trên Hệ thống đầy đủ ngay trước khi kiểm tra Chấp nhận người dùng. Vì vậy, điều quan trọng là phải tìm ra tất cả các khuyết tật có thể có ở giai đoạn này và chúng không bị rò rỉ khi sản xuất.
•Kết quả Kiểm tra Hệ thống được các bên liên quan sử dụng để đưa ra quyết định phát hành. Tiêu chí đầu vào cho kiểm tra Chấp nhận người dùng là cơ sở hoàn thành Kiểm tra hệ thống. Kiểm tra hệ thống cũng có thể tuân theo các yêu cầu hoặc tiêu chuẩn pháp lý hoặc quy định.
3. Cơ sở thử nghiệm
Cơ sở kiểm thử là nguồn thông tin hoặc tài liệu, là yêu cầu chính để viết các trường hợp kiểm thử và cũng để phân tích kiểm thử. Cơ sở của thử nghiệm phải được xác định rõ ràng và có cấu trúc đầy đủ để người ta có thể nhanh chóng xác định các điều kiện thử nghiệm mà từ đó các trường hợp thử nghiệm được hình thành.
Ví dụ về các sản phẩm công việc có thể được sử dụng làm cơ sở thử nghiệm để kiểm tra hệ thống bao gồm:
•Đặc tả yêu cầu hệ thống và phần mềm (chức năng và phi chức năng) – SRS đưa ra các yêu cầu đầy đủ về cách Hệ thống tích hợp hoạt động. Nó sẽ tạo cơ sở cho việc đưa ra các Kịch bản Kiểm tra Hệ thống.
•Báo cáo phân tích rủi ro – Nó chỉ ra các khu vực có rủi ro. Nó có thể là từ quan điểm thực hiện hoặc quan điểm pháp lý / tuân thủ. Kiểm tra hệ thống phải đảm bảo rằng trọng tâm là các lĩnh vực này.
•Các ca sử dụng – Chúng hiển thị các luồng hành trình của Hệ thống. Nó tạo cơ sở cho các kịch bản kết thúc được tạo ra
•Biểu đồ trạng thái – Đây là biểu diễn trực quan dưới dạng lưu đồ về cách mỗi thành phần tương tác với nhau và các điểm kích hoạt của chúng.
•Mô hình hành vi của hệ thống – Mô hình này mô tả các quá trình và hoạt động mà mỗi thành phần có liên quan, đồng thời cho thấy cách chúng sẽ tương tác với các thành phần khác.
•Hướng dẫn sử dụng và hệ thống – Thông thường đối với một phần mềm dựa trên sản phẩm, hướng dẫn sử dụng được tạo ra, vì vậy người dùng dễ dàng tìm ra cách sử dụng. Ví dụ: đối với phần mềm tính thuế thu nhập, hướng dẫn sử dụng sẽ mô tả cách điền dữ liệu và cách tính toán diễn ra.
4. Kiểm tra đối tượng
Đối tượng thử nghiệm là thành phần hoặc hệ thống yêu cầu thử nghiệm. Bây giờ chúng ta hãy xem xét các đối tượng thử nghiệm để kiểm tra hệ thống:
Đối tượng kiểm thử điển hình của kiểm thử hệ thống bao gồm:
•Các ứng dụng
•Hệ thống phần cứng / phần mềm
•Các hệ điều hành
•Hệ thống đang thử nghiệm
•Cấu hình hệ thống và dữ liệu cấu hình
Nếu bạn nhìn vào các Đối tượng thử nghiệm này, bạn sẽ nhận thấy rằng đây là những Hệ thống được tích hợp đầy đủ. Hệ thống có thể là một phần mềm (như trang web / ứng dụng Amazon hoặc Flipkart) hoặc nó có thể là Hệ điều hành (như Windows 10), v.v.
5. Những sai sót và thất bại điển hình cho Kiểm thử hệ thống
Ví dụ về các lỗi điển hình đối với thử nghiệm hệ thống bao gồm:
•Không thực hiện được các tác vụ chức năng end to end – Ví dụ: Một phần mềm đặt vé tàu đặt vé thành công nhưng không gửi được email xác nhận mã số vé cho khách hàng.
•Tính toán không chính xác – Ví dụ: Coi như bạn đang mua sắm trên trang web Amazon. Bạn đã thêm hai sản phẩm trị giá 100$ và 50$. Giá trị giỏ hàng hiển thị là 150 $. Bây giờ bạn áp dụng chiết khấu 10% cho Giỏ hàng, giảm giá 15$ và giảm giá trị Giỏ hàng xuống còn 135$. Sau khi đặt hàng, bạn quyết định hủy sản phẩm 50$. Việc hủy bỏ sản phẩm sẽ xảy ra và bạn được hoàn lại 50$. Đó là lỗi Hệ thống áp dụng chiết khấu 10% trong khi số tiền hoàn lại thực tế phải là 45$.
•Kiểm soát không chính xác hoặc luồng dữ liệu trong hệ thống. Ví dụ: Hãy xem xét rằng bạn đã sử dụng chiết khấu 15% cho một sản phẩm trị giá 5$. Sau khi giảm giá, giá trị sẽ là $ 4,75. Bây giờ, ứng dụng có một logic sai khi làm tròn số ở vị trí thập phân đầu tiên, nơi nó tính phí thẻ 4,8$ thay vì 4,75 $. Luồng dữ liệu không chính xác như vậy có thể dẫn đến lỗi trong giai đoạn thử nghiệm Hệ thống
•Hành vi không hoạt động hoặc chức năng không mong muốn của hệ thống – Ví dụ: bạn đang sử dụng ứng dụng Amazon và nếu có cuộc gọi đến, ứng dụng đang bị lỗi. Mặc dù không có gì sai về mặt chức năng của ứng dụng, nhưng việc khắc phục những hành vi phi chức năng như vậy là rất quan trọng đối với sự thành công chung của ứng dụng.
•Có những trường hợp hệ thống không hoạt động như được mô tả trong hệ thống và hướng dẫn sử dụng.
•Có những tình huống mà hệ thống không hoạt động chính xác trong môi trường sản xuất. Thường thì Hệ thống hoạt động hoàn toàn tốt trong môi trường thử nghiệm, nhưng khi được phát hành sang môi trường giống như sản xuất, nó không hoạt động. Do đó, một bài kiểm tra Hệ thống phải luôn luôn xảy ra trong một môi trường bắt chước sản xuất; đồng thời về phần mềm và phần cứng
6. Phương pháp tiếp cận và Trách nhiệm
Người kiểm thử độc lập thường làm Kiểm thử hệ thống để có cái nhìn khách quan về Hệ thống. Chiến lược là để nhóm kiểm thử tham gia ngay từ đầu, để họ có hiểu biết đầy đủ về Hệ thống. Các kịch bản kiểm tra hệ thống thường là kiểm tra đầu cuối có thể bao gồm toàn bộ Hệ thống. Các kiến trúc sư và chủ sở hữu sản phẩm thường xem xét các tình huống này.
Trách nhiệm của Nhóm Kiểm tra Hệ thống:
•Hiểu quy trình hệ thống và tạo hành trình của người dùng cấp cao
•Tạo các trường hợp kiểm tra Hệ thống từ đầu đến cuối chi tiết
•Xác định và tạo bất kỳ dữ liệu thử nghiệm nào cần thiết để thực hiện các trường hợp thử nghiệm
•Phối hợp với các nhóm Scrum để đảm bảo sẵn sàng hỗ trợ đầy đủ để sửa chữa các khiếm khuyết
•Các cuộc họp bộ ba khiếm khuyết để khắc phục trách nhiệm giải trình về việc sửa lỗi cho nhóm Scrum
7. Phân biệt các loại kiểm thử hệ thống
Giống như bất kỳ thử nghiệm phần mềm nào, Kiểm tra hệ thống cũng là một tổ hợp các loại kiểm tra khác nhau, cho phép nhóm xác nhận hiệu suất và chức năng tổng thể của sản phẩm. Mỗi loại thử nghiệm này tập trung vào các khía cạnh khác nhau của sản phẩm và đáp ứng các yêu cầu khác nhau của khách hàng / người dùng. Các loại kiểm tra hệ thống này là:
•Kiểm tra khả năng sử dụng: Kiểm tra khả năng sử dụng chủ yếu tập trung vào việc người dùng dễ sử dụng ứng dụng, tính linh hoạt trong việc xử lý các điều khiển và khả năng hệ thống đáp ứng các mục tiêu của nó
•Kiểm tra tải: Kiểm tra tải là cần thiết để biết rằng một giải pháp phần mềm sẽ hoạt động dưới các tải trong thực tế.
•Kiểm thử hồi quy: Kiểm thử hồi quy liên quan đến các thử nghiệm được thực hiện để đảm bảo rằng không có thay đổi nào được thực hiện trong quá trình phát triển gây ra lỗi mới. Nó cũng đảm bảo rằng không có lỗi cũ xuất hiện khi thêm mô-đun phần mềm mới theo thời gian.
•Kiểm tra khôi phục: Kiểm tra khôi phục xảy ra để chứng minh rằng giải pháp phần mềm là đáng tin cậy và có thể khôi phục thành công sau sự cố có thể xảy ra.
•Kiểm tra di chuyển: Kiểm tra di chuyển xảy ra để đảm bảo rằng phần mềm di chuyển từ cơ sở hạ tầng hệ thống cũ hơn sang cơ sở hạ tầng hệ thống hiện tại mà không gặp bất kỳ sự cố nào.
•Kiểm tra hiệu suất: Chúng tôi thực hiện Kiểm tra hiệu suất để kiểm tra phản ứng, độ ổn định, khả năng mở rộng, độ tin cậy và các chỉ số chất lượng phần mềm khác, trong các khối lượng công việc khác nhau.
•Kiểm thử bảo mật: Kiểm thử bảo mật đánh giá các tính năng bảo mật của phần mềm để đảm bảo, bảo vệ, tính xác thực, tính bảo mật và tính toàn vẹn của thông tin và dữ liệu.
Nguồn: https://www.toolsqa.com/software-testing/istqb/system-testing/
You need to login in order to like this post: click here
YOU MIGHT ALSO LIKE
