Kiểm thử thâm nhập - Hướng dẫn & Tự động

Cả thử nghiệm thâm nhập thủ công và thử nghiệm thâm nhập tự động đều được thực hiện cho cùng một mục đích. Sự khác biệt duy nhất giữa họ là cách họ được tiến hành.

Như tên cho thấy, kiểm tra thâm nhập thủ công được thực hiện bởi con người (chuyên gia của lĩnh vực này) và kiểm tra thâm nhập tự động được thực hiện bởi chính máy.

Học kiểm thử phần mềm chuyên nghiệp

Chương này sẽ giúp bạn tìm hiểu khái niệm, sự khác biệt và khả năng áp dụng của cả hai điều khoản.

Kiểm tra thâm nhập bằng tay là gì?

Kiểm tra thâm nhập thủ công là kiểm tra được thực hiện bởi con người. Trong loại thử nghiệm như vậy, lỗ hổng và rủi ro của máy được kiểm tra bởi một kỹ sư chuyên gia.

>>Nói chung, các kỹ sư kiểm tra thực hiện các phương pháp sau kiểm thử phần mềm chuyên sâu <<

Thu thập dữ liệu - Thu thập dữ liệu đóng vai trò chính để thử nghiệm. Người ta có thể thu thập dữ liệu theo cách thủ công hoặc có thể sử dụng các dịch vụ công cụ (như kỹ thuật phân tích mã nguồn trang web, v.v.) có sẵn trực tuyến.

Các công cụ này giúp thu thập thông tin như tên bảng, phiên bản DB, cơ sở dữ liệu, phần mềm, phần cứng hoặc thậm chí về các plugin của bên thứ ba khác, v.v.

Đánh giá tính dễ bị tổn thương - Sau khi dữ liệu được thu thập, nó giúp người kiểm tra xác định điểm yếu bảo mật và thực hiện các bước phòng ngừa tương ứng.

Khai thác thực tế - Đây là một phương pháp điển hình mà một chuyên gia thử nghiệm sử dụng để khởi động một cuộc tấn công vào hệ thống mục tiêu và tương tự, làm giảm nguy cơ bị tấn công.

Chuẩn bị báo cáo - Sau khi thâm nhập xong, người kiểm tra chuẩn bị báo cáo cuối cùng mô tả mọi thứ về hệ thống. Cuối cùng, báo cáo được phân tích để thực hiện các bước khắc phục để bảo vệ hệ thống mục tiêu.

Các loại kiểm tra thâm nhập bằng tay

Kiểm tra thâm nhập thủ công thường được phân loại theo hai cách sau

Kiểm tra thâm nhập bằng tay tập trung - Đây là một phương pháp tập trung nhiều để kiểm tra các lỗ hổng và rủi ro cụ thể. 

Kiểm tra thâm nhập tự động không thể thực hiện kiểm tra này; nó chỉ được thực hiện bởi các chuyên gia về con người kiểm tra các lỗ hổng ứng dụng cụ thể trong các miền đã cho.

Kiểm tra thâm nhập thủ công toàn diện - Thông qua kiểm tra toàn bộ các hệ thống được kết nối với nhau để xác định tất cả các loại rủi ro và lỗ hổng. 

Tuy nhiên, chức năng của thử nghiệm này mang tính tình huống hơn, chẳng hạn như điều tra xem nhiều lỗi có nguy cơ thấp hơn có thể mang lại kịch bản tấn công dễ bị tổn thương hơn không, v.v.

Kiểm tra thâm nhập tự động là gì?

Kiểm tra thâm nhập tự động nhanh hơn, hiệu quả, dễ dàng và đáng tin cậy để kiểm tra lỗ hổng và rủi ro của máy một cách tự động.

Công nghệ này không yêu cầu bất kỳ kỹ sư chuyên gia nào, thay vào đó nó có thể được điều hành bởi bất kỳ người nào có ít kiến ​​thức nhất về lĩnh vực này.

Các công cụ để kiểm tra thâm nhập tự động là Nessus, Metasploit, OpenVAs, backtract (loạt 5), v.v ... Đây là những công cụ rất hiệu quả làm thay đổi hiệu quả và ý nghĩa của kiểm tra thâm nhập.

Tuy nhiên, bảng dưới đây minh họa sự khác biệt cơ bản giữa thử nghiệm thâm nhập thủ công và tự động.

Kiểm tra thâm nhập bằng tay	Kiểm tra thâm nhập tự động
Nó đòi hỏi kỹ sư chuyên gia để thực hiện thử nghiệm.	Nó được tự động để ngay cả một người học có thể chạy thử nghiệm.
Nó đòi hỏi các công cụ khác nhau để thử nghiệm.	Nó có các công cụ tích hợp không yêu cầu bất cứ điều gì từ bên ngoài.
Trong loại thử nghiệm này, kết quả có thể thay đổi từ thử nghiệm này sang thử nghiệm khác.	Nó có kết quả cố định.
Kiểm tra này đòi hỏi phải nhớ làm sạch bộ nhớ của người kiểm tra.	Nó không.
Nó là đầy đủ và mất thời gian.	Nó là hiệu quả hơn và nhanh chóng.
Nó có thêm lợi thế tức là nếu một chuyên gia thực hiện kiểm tra bút, sau đó anh ta có thể phân tích tốt hơn, anh ta có thể nghĩ những gì một hacker có thể nghĩ và nơi anh ta có thể tấn công.Do đó, anh ta có thể đặt bảo mật cho phù hợp.	Nó không thể phân tích tình hình.
Theo yêu cầu, một chuyên gia có thể chạy thử nghiệm nhiều.	Nó không thể.
Đối với điều kiện quan trọng, nó đáng tin cậy hơn.	Không phải vậy.

Học kiểm thử phần mềm - Các loại kiểm tra thâm nhập

Loại thử nghiệm thâm nhập thông thường phụ thuộc vào phạm vi và yêu cầu và yêu cầu của tổ chức. Chương này thảo luận về các loại thử nghiệm thâm nhập khác nhau. Nó còn được gọi là Thử nghiệm Bút .

Học kiểm thử phần mềm chuyên nghiệp

Các loại kiểm tra bút

Sau đây là các loại thử nghiệm bút quan trọng

Kiểm tra thâm nhập hộp đen

Kiểm tra thâm nhập hộp trắng

Kiểm tra thâm nhập hộp xám

Để hiểu rõ hơn, hãy để chúng tôi thảo luận chi tiết về từng người trong số họ

Kiểm tra thâm nhập hộp đen

>> Trong thử nghiệm thâm nhập hộp đen, người kiểm thử phần mềm không biết gì về các hệ thống mà anh ta sẽ kiểm tra. Anh ta quan tâm đến việc thu thập thông tin về mạng hoặc hệ thống đích <<

Ví dụ, trong thử nghiệm này, một người thử nghiệm chỉ biết kết quả mong đợi là gì và anh ta không biết kết quả đến như thế nào. Anh ta không kiểm tra bất kỳ mã lập trình.

Ưu điểm của kiểm tra thâm nhập hộp đen

Nó có những ưu điểm sau

Người kiểm thử không nhất thiết phải là một chuyên gia, vì nó không đòi hỏi kiến ​​thức ngôn ngữ cụ thể

Người kiểm tra xác minh mâu thuẫn trong hệ thống thực tế và thông số kỹ thuật

Kiểm tra thường được tiến hành với quan điểm của người dùng, không phải người thiết kế

Nhược điểm của kiểm thử phần mềm  thâm nhập hộp đen

Nhược điểm của nó là

Đặc biệt, các loại trường hợp thử nghiệm rất khó thiết kế.

Có thể, nó không có giá trị, nhà thiết kế incase đã tiến hành một trường hợp thử nghiệm.

Nó không tiến hành mọi thứ.

Kiểm tra thâm nhập hộp trắng

Đây là một thử nghiệm toàn diện, vì người kiểm tra đã được cung cấp toàn bộ thông tin về các hệ thống và / hoặc mạng như Schema, Mã nguồn, chi tiết hệ điều hành, địa chỉ IP, v.v. Nó thường được coi là mô phỏng cuộc tấn công của một nguồn nội bộ. Nó còn được gọi là kết cấu, hộp thủy tinh, hộp trong và kiểm tra hộp mở.

Kiểm tra thâm nhập hộp trắng kiểm tra phạm vi bảo hiểm mã và thực hiện kiểm tra luồng dữ liệu, kiểm tra đường dẫn, kiểm tra vòng lặp, v.v.

Ưu điểm của kiểm tra thâm nhập hộp trắng

Nó mang những lợi thế sau

Nó đảm bảo rằng tất cả các đường dẫn độc lập của một mô-đun đã được thực hiện.

Nó đảm bảo rằng tất cả các quyết định hợp lý đã được xác minh cùng với giá trị đúng và sai của chúng.

Nó phát hiện ra các lỗi đánh máy và kiểm thử phần mềm cú pháp.

Nó tìm thấy các lỗi thiết kế có thể xảy ra do sự khác biệt giữa luồng logic của chương trình và thực thi thực tế.

Kiểm tra thâm nhập hộp xám

Trong loại thử nghiệm này, một người thử nghiệm thường cung cấp thông tin một phần hoặc giới hạn về các chi tiết bên trong của chương trình của một hệ thống. Nó có thể được coi là một cuộc tấn công của một tin tặc bên ngoài đã giành được quyền truy cập bất hợp pháp vào các tài liệu cơ sở hạ tầng mạng của một tổ chức.

Ưu điểm của kiểm tra thâm nhập hộp xám

Nó có những ưu điểm sau

Vì người kiểm tra không yêu cầu quyền truy cập của mã nguồn, nó không xâm phạm và không thiên vị

Vì có sự khác biệt rõ ràng giữa nhà phát triển và người thử nghiệm, nên ít có nguy cơ xảy ra xung đột cá nhân

Bạn không cần cung cấp thông tin nội bộ về các chức năng của chương trình và các hoạt động khác

Các lĩnh vực kiểm tra thâm nhập

Kiểm thử phần mềm thâm nhập thường được thực hiện trong ba lĩnh vực sau

Kiểm tra thâm nhập mạng - Trong thử nghiệm này, cấu trúc vật lý của một hệ thống cần được kiểm tra để xác định lỗ hổng và rủi ro đảm bảo an ninh trong mạng. 

Trong môi trường mạng, người kiểm tra xác định các lỗi bảo mật trong thiết kế, triển khai hoặc vận hành mạng của công ty / tổ chức tương ứng. Các thiết bị được kiểm tra bởi người kiểm tra có thể là máy tính, modem hoặc thậm chí là thiết bị truy cập từ xa, v.v.

Kiểm tra thâm nhập ứng dụng - Trong thử nghiệm này, cấu trúc logic của hệ thống cần phải được kiểm tra. Đây là một mô phỏng tấn công được thiết kế để thể hiện hiệu quả của các kiểm soát bảo mật của ứng dụng bằng cách xác định lỗ hổng và rủi ro. 

Tường lửa và các hệ thống giám sát khác được sử dụng để bảo vệ hệ thống bảo mật, nhưng đôi khi, nó cần kiểm tra tập trung đặc biệt là khi lưu lượng được phép đi qua tường lửa.

Phản hồi hoặc quy trình làm việc của hệ thống - Đây là khu vực thứ ba cần được kiểm tra. Kỹ thuật xã hội tập hợp thông tin về sự tương tác của con người để có được thông tin về một tổ chức và máy tính của nó. 

Có lợi khi Kiểm thử phần mềm khả năng của tổ chức tương ứng để ngăn chặn truy cập trái phép vào hệ thống thông tin của nó. Tương tự, thử nghiệm này được thiết kế dành riêng cho quy trình làm việc của tổ chức / công ty.

Kiểm thử phần mềm - Kiểm tra thâm nhập Vs. Dễ bị tổn thương

Nói chung, hai thuật ngữ này, tức là Kiểm thử thâm nhập và đánh giá tính dễ bị tổn thương được sử dụng thay thế cho nhau bởi nhiều người, vì hiểu lầm hoặc quảng cáo tiếp thị.

Nhưng, cả hai điều khoản này khác nhau về mục tiêu và các phương tiện khác. Tuy nhiên, trước khi mô tả sự khác biệt, trước tiên chúng ta hãy hiểu cả hai thuật ngữ một.

Học kiểm thử phần mềm chuyên nghiệp

Kiểm tra thâm nhập

>> Kiểm thử phần mềm thâm nhập sao chép các hành động của kẻ tấn công mạng bên ngoài hoặc / và bên trong nhằm phá vỡ bảo mật thông tin và hack dữ liệu có giá trị hoặc phá vỡ hoạt động bình thường của tổ chức <<

Vì vậy, với sự trợ giúp của các công cụ và kỹ thuật tiên tiến, một người kiểm tra thâm nhập (còn được gọi là hacker đạo đức ) đã nỗ lực để kiểm soát các hệ thống quan trọng và có được quyền truy cập vào dữ liệu nhạy cảm.

Đánh giá tính dễ bị tổn thương

Mặt khác, đánh giá lỗ hổng là kỹ thuật xác định (khám phá) và đo lường các lỗ hổng bảo mật (quét) trong một môi trường nhất định.

Đó là một đánh giá toàn diện về vị trí bảo mật thông tin (phân tích kết quả). Hơn nữa, nó xác định các điểm yếu tiềm ẩn và cung cấp các biện pháp giảm thiểu thích hợp (khắc phục) để loại bỏ các điểm yếu đó hoặc giảm dưới mức rủi ro.

Sơ đồ sau đây tóm tắt đánh giá lỗ hổng

Bảng dưới đây minh họa sự khác biệt cơ bản giữa kiểm tra thâm nhập và đánh giá lỗ hổng

Kiểm tra thâm nhập	Đánh giá tính dễ bị tổn thương
Xác định phạm vi của một cuộc tấn công.	Tạo một thư mục tài sản và tài nguyên trong một hệ thống nhất định.
Kiểm tra thu thập dữ liệu nhạy cảm.	Khám phá các mối đe dọa tiềm năng cho từng tài nguyên.
Tập hợp thông tin mục tiêu và / hoặc kiểm tra hệ thống.	Phân bổ giá trị định lượng và ý nghĩa cho các tài nguyên có sẵn.
Dọn dẹp hệ thống và đưa ra báo cáo cuối cùng.	Nỗ lực giảm thiểu hoặc loại bỏ các lỗ hổng tiềm năng của các tài nguyên có giá trị.
Nó không xâm phạm, tài liệu và đánh giá và phân tích môi trường.	Phân tích toàn diện và thông qua việc xem xét hệ thống mục tiêu và môi trường của nó.
Đó là lý tưởng cho môi trường vật lý và kiến ​​trúc mạng.	Đó là lý tưởng cho môi trường phòng thí nghiệm.
Nó có nghĩa là cho các hệ thống thời gian thực quan trọng.	Nó có nghĩa là cho các hệ thống không quan trọng.

Lựa chọn nào là lý tưởng để thực hành?

Cả hai phương pháp đều có chức năng và cách tiếp cận khác nhau, vì vậy nó phụ thuộc vào vị trí bảo mật của hệ thống tương ứng. Tuy nhiên, vì sự khác biệt cơ bản giữa kiểm tra thâm nhập và đánh giá lỗ hổng, kỹ thuật thứ hai có lợi hơn so với kỹ thuật thứ nhất.

Đánh giá lỗ hổng xác định các điểm yếu và đưa ra giải pháp để khắc phục chúng. Mặt khác, kiểm tra thâm nhập chỉ trả lời câu hỏi rằng "bất kỳ ai cũng có thể đột nhập vào bảo mật hệ thống và nếu vậy, thì anh ta có thể làm hại gì?"

Hơn nữa, một đánh giá lỗ hổng cố gắng cải thiện hệ thống bảo mật và phát triển một chương trình bảo mật tích hợp, trưởng thành hơn. Mặt khác, kiểm tra thâm nhập chỉ đưa ra một bức tranh về hiệu quả của chương trình bảo mật của bạn.

Như chúng ta đã thấy ở đây, đánh giá lỗ hổng có lợi hơn và cho kết quả tốt hơn so với thử nghiệm thâm nhập. Nhưng, các chuyên gia khuyên rằng, là một phần của hệ thống quản lý bảo mật, cả hai kỹ thuật nên được thực hiện thường xuyên để đảm bảo một môi trường bảo mật hoàn hảo.

kiểm thử phần mềm - Kiểm tra thâm nhập - Phương pháp

Kiểm thử phần mềm thâm nhập là sự kết hợp của các kỹ thuật xem xét các vấn đề khác nhau của hệ thống và kiểm tra, phân tích và đưa ra giải pháp. Nó dựa trên một quy trình có cấu trúc để thực hiện kiểm tra thâm nhập từng bước.

Kiểm thử phần mềm chuyên nghiệp

Chương này mô tả các bước hoặc giai đoạn khác nhau của phương pháp thử nghiệm thâm nhập.

Các bước của phương pháp kiểm tra thâm nhập

Sau đây là bảy bước kiểm tra thâm nhập

Lập kế hoạch & chuẩn bị

Lập kế hoạch và chuẩn bị bắt đầu với việc xác định các mục tiêu và mục tiêu của thử nghiệm thâm nhập.

Khách hàng và người kiểm tra cùng xác định các mục tiêu để cả hai bên có cùng mục tiêu và sự hiểu biết. Mục tiêu chung của kiểm tra thâm nhập là

Để xác định lỗ hổng và cải thiện tính bảo mật của các hệ thống kỹ thuật.

Có bảo mật CNTT được xác nhận bởi một bên thứ ba bên ngoài.

Tăng tính bảo mật của cơ sở hạ tầng tổ chức / nhân sự.

Trinh sát

Trinh sát bao gồm phân tích thông tin sơ bộ. Nhiều lần, người kiểm tra không có nhiều thông tin ngoài thông tin sơ bộ, tức là địa chỉ IP hoặc khối địa chỉ IP. 

Người Kiểm thử phần mềm bắt đầu bằng cách phân tích thông tin có sẵn và, nếu được yêu cầu, yêu cầu thêm thông tin như mô tả hệ thống, kế hoạch mạng, v.v. từ khách hàng. 

Bước này là thử nghiệm thâm nhập thụ động, một loại. Mục tiêu duy nhất là để có được một thông tin đầy đủ và chi tiết của các hệ thống.

Khám phá

Trong bước này, một người kiểm tra thâm nhập rất có thể sẽ sử dụng các công cụ tự động để quét các tài sản mục tiêu để phát hiện ra các lỗ hổng. Các công cụ này thường có cơ sở dữ liệu riêng cung cấp các chi tiết về các lỗ hổng mới nhất. Tuy nhiên, người kiểm tra phát hiện ra

Khám phá mạng - Chẳng hạn như khám phá thêm các hệ thống, máy chủ và các thiết bị khác.

Host Discovery - Nó xác định các cổng mở trên các thiết bị này.

Thẩm vấn dịch vụ - Nó thẩm vấn các cổng để khám phá các dịch vụ thực tế đang chạy trên chúng.

Phân tích thông tin và rủi ro

Trong bước này, người Kiểm thử phần mềm phân tích và đánh giá thông tin thu thập được trước các bước kiểm tra để tự động xâm nhập hệ thống. Do số lượng hệ thống và quy mô cơ sở hạ tầng lớn hơn nên cực kỳ tốn thời gian. Trong khi phân tích, người kiểm tra xem xét các yếu tố sau

Các mục tiêu được xác định của bài kiểm tra thâm nhập.

Những rủi ro tiềm ẩn cho hệ thống.

Thời gian ước tính cần thiết để đánh giá các lỗ hổng bảo mật tiềm năng cho thử nghiệm thâm nhập hoạt động tiếp theo.

Tuy nhiên, từ danh sách các hệ thống được xác định, người kiểm tra có thể chọn chỉ kiểm tra những hệ thống có chứa lỗ hổng tiềm năng.

Nỗ lực xâm nhập tích cực

Đây là bước quan trọng nhất phải được thực hiện với sự quan tâm đúng mức. Bước này đòi hỏi mức độ mà các lỗ hổng tiềm năng đã được xác định trong bước khám phá có rủi ro thực tế. Bước này phải được thực hiện khi cần xác minh các lỗ hổng tiềm năng. 

Đối với những hệ thống có yêu cầu toàn vẹn rất cao, lỗ hổng và rủi ro tiềm ẩn cần được xem xét cẩn thận trước khi tiến hành các quy trình làm sạch quan trọng.

Phân tích cuối cùng

Bước này chủ yếu xem xét tất cả các bước được thực hiện (đã thảo luận ở trên) cho đến thời điểm đó và đánh giá các lỗ hổng hiện diện dưới dạng rủi ro tiềm ẩn. Hơn nữa, người kiểm tra đề nghị loại bỏ các lỗ hổng và rủi ro. Trên hết, người Kiểm thử phần mềm phải đảm bảo tính minh bạch của các bài kiểm tra và các lỗ hổng mà nó tiết lộ.

chuẩn bị báo cáo

Chuẩn bị báo cáo phải bắt đầu với các quy trình thử nghiệm tổng thể, tiếp theo là phân tích các lỗ hổng và rủi ro. Các rủi ro cao và các lỗ hổng nghiêm trọng phải có các ưu tiên và sau đó theo thứ tự thấp hơn.

Tuy nhiên, trong khi ghi lại báo cáo cuối cùng, các điểm sau đây cần được xem xét -

Tóm tắt tổng thể về thử nghiệm thâm nhập.

Chi tiết từng bước và thông tin thu thập được trong quá trình thử bút.

Chi tiết về tất cả các lỗ hổng và rủi ro được phát hiện.

Chi tiết về làm sạch và sửa chữa các hệ thống.

Gợi ý cho an ninh trong tương lai.

Học kiểm thử phần mềm - Kiểm tra Agile - Công cụ

Trong các dự án Agile, Người kiểm thử chịu trách nhiệm cho các nhiệm vụ hàng ngày sau

Hỗ trợ các nhà phát triển mã hóa, làm rõ về hành vi dự kiến ​​của hệ thống.

Giúp các nhà phát triển trong việc tạo ra các bài kiểm tra đơn vị hiệu quả và hiệu quả.

Phát triển các kịch bản tự động hóa.

Tích hợp các công cụ / tập lệnh kiểm thử tự động với tích hợp liên tục để kiểm tra hồi quy.

Để triển khai hiệu quả và nhanh chóng các tác vụ này, hệ thống Tích hợp liên tục (CI) hỗ trợ CI của Mã và các thành phần thử nghiệm được sử dụng trong hầu hết các dự án Agile.

học kiểm thử phần mềm 

Người kiểm tra và nhà phát triển trong các dự án nhanh có thể được hưởng lợi từ các công cụ khác nhau để quản lý các phiên kiểm tra và để tạo và gửi báo cáo Khiếm khuyết. 

Ngoài các công cụ chuyên dụng để kiểm tra nhanh, các nhóm nhanh cũng có thể được hưởng lợi từ các công cụ quản lý kiểm thử và tự động hóa.

>> Học kiểm thử phần mềm <<

Lưu ý - Các giải pháp tự động hóa ghi và phát lại, kiểm tra lần cuối, nặng và kiểm tra không linh hoạt như.

Quy trình làm việc thử nghiệm cuối cùng được khuyến khích bởi các công cụ như vậy không hoạt động đối với các nhóm Agile.

Các tập lệnh không thể nhầm lẫn được tạo bằng các công cụ như vậy trở thành một trở ngại để thay đổi

Các công cụ chuyên dụng như vậy tạo ra nhu cầu về các chuyên gia tự động hóa Thử nghiệm và do đó thúc đẩy các silo

Các công cụ được sử dụng rộng rãi là

S.No.	Công cụ & Mục đích
1	Hudson Khung CI
2	Selen Kiểm tra chức năng - Tích hợp với Hudson
3	CruiseControl Khung CI
4	Tháng sáu Kiểm tra đơn vị Java
5	Nữ tu Kiểm tra đơn vị .Net
6	Cobertura / JavaCodeCoverage / JFeature / JCover / Bảo hiểm kiểm tra Java
7	hề Java - Kiểm tra đột biến / Tạo lỗi tự động
số 8	Gretel Công cụ giám sát vùng phủ sóng thử nghiệm Java
9	TestCocoon C / C ++ hoặc C # - giảm số lượng Bài kiểm tra bằng cách tìm các Bài kiểm tra dự phòng và tìm Mã chết
10	JAZZ Java - Chi nhánh, Nút, và Bảo vệ Defuse và triển khai GUI, Trình lập kế hoạch kiểm tra, Thiết bị động và Trình phân tích kiểm tra
11	Kiến Java - Tự động hóa xây dựng
12	Nam Kinh .Net - Xây dựng tự động hóa
13	Ngọn lửa Bổ trợ kiểm tra Agile cho JIRA

Công cụ tự động kiểm tra Agile

Hỗ trợ các công cụ tự động kiểm tra Agile hiệu quả

Tự động hóa thử nghiệm sớm bằng cách sử dụng phương pháp thử nghiệm đầu tiên.

Viết mã tự động kiểm tra bằng ngôn ngữ thực, ngôn ngữ cụ thể của miền.

Tập trung vào hành vi dự kiến ​​của hệ thống.

Tách biệt bản chất của Thử nghiệm khỏi các chi tiết triển khai, do đó làm cho Công nghệ trở nên độc lập.

Bồi dưỡng hợp tác.

Các thử nghiệm đơn vị tự động (sử dụng Junit hoặc NUnit) hỗ trợ phương pháp thử nghiệm đầu tiên cho mã hóa. Đây là các thử nghiệm hộp trắng và đảm bảo rằng thiết kế là âm thanh, và không có khiếm khuyết. 

Các thử nghiệm như vậy được xây dựng bởi các nhà phát triển với sự hỗ trợ từ người thử nghiệm và có thể độc lập với chức năng được yêu cầu. Điều này dẫn đến việc cung cấp một sản phẩm có thể không đáp ứng yêu cầu của khách hàng và do đó không có giá trị kinh doanh.

Mối quan tâm này được giải quyết bằng cách tự động hóa các Bài kiểm tra chấp nhận được viết với sự cộng tác của khách hàng, các bên liên quan khác, người kiểm tra và nhà phát triển. 

Các thử nghiệm chấp nhận tự động được viết bởi khách hàng hoặc chủ sở hữu sản phẩm / nhà phân tích kinh doanh phản ánh hành vi dự kiến ​​của sản phẩm. Sự tham gia của các nhà phát triển đảm bảo việc sản xuất mã theo yêu cầu. Tuy nhiên, nếu thử nghiệm chỉ tập trung vào sự chấp nhận, mã kết quả có thể vẫn không thể mở rộng.

Do đó, Kiểm tra đơn vị tự động và Kiểm tra chấp nhận tự động là miễn phí và cả hai đều cần thiết trong Phát triển Agile.

Các công cụ và khung công cụ linh hoạt hỗ trợ Kiểm tra chấp nhận tự động là

Phù hợp

Fitnesse

Sự kết hợp

Hồng ngọc

Quả dưa chuột

Phù hợp

Ward Castyham đã phát triển công cụ Fit có thể được sử dụng cho Tự động kiểm tra chấp nhận. Fit cho phép

Khách hàng hoặc Chủ sở hữu sản phẩm để đưa ra ví dụ về hành vi sản phẩm bằng Microsoft Word và Microsoft Excel

Lập trình viên để dễ dàng biến những ví dụ đó thành các bài kiểm tra tự động.

Fit 1.1 hỗ trợ cả Java và .NET.

FitNlie

FitNesse là một wiki, là một kiểu máy chủ web cho phép bất kỳ khách truy cập nào thực hiện bất kỳ chỉnh sửa nào, bao gồm thay đổi các trang hiện có và tạo các trang mới. 

Một ngôn ngữ đánh dấu đơn giản cho phép bạn dễ dàng tạo các tiêu đề, làm đậm văn bản, gạch chân và in nghiêng, tạo danh sách dấu đầu dòng và thực hiện các loại định dạng đơn giản khác.

Trong FitNesse, Tự động kiểm tra chấp nhận như sau

Express kiểm tra dưới dạng bảng dữ liệu đầu vào và dữ liệu đầu ra dự kiến.

Sử dụng FitNesse để đặt bảng thử nghiệm trên trang mà bạn có thể chỉnh sửa.

Hoặc, đặt bảng kiểm tra vào Microsoft Excel, sao chép vào bảng tạm và sau đó sử dụng lệnh Bảng tính sang FitNesseđể định dạng FitNlie đúng bảng của bạn

Chạy thử

Bạn nhận được kết quả kiểm tra bằng cách mã hóa màu của các ô trong bảng kiểm tra

các ô màu xanh biểu thị rằng các giá trị dự kiến ​​thu được

các ô màu đỏ biểu thị rằng giá trị khác với giá trị bạn mong đợi

các tế bào màu vàng thể hiện rằng một ngoại lệ đã được ném

Quả dưa chuột

Dưa chuột là một công cụ dựa trên khung phát triển hướng hành vi (BDD). Các tính năng chính là

Được sử dụng để viết các bài kiểm tra chấp nhận cho các ứng dụng web.

Cho phép tự động hóa xác nhận chức năng ở định dạng dễ đọc và dễ hiểu như tiếng Anh đơn giản.

Đã được triển khai trong Ruby và sau đó được mở rộng sang khung Java. Cả hai đều ủng hộ Junit.

Hỗ trợ các ngôn ngữ khác như Perl, PHP, Python, .Net, v.v.

Có thể được sử dụng cùng với Selenium, Watir, Capybara, v.v.

Kiểm thử phần mềm - Kiểm tra nhanh - Kanban

Các hoạt động kiểm thử phần mềm Agile có thể được quản lý hiệu quả bằng cách sử dụng các khái niệm Kanban. Sau đây đảm bảo kiểm thử được hoàn thành kịp thời trong vòng lặp / chạy nước rút và do đó tập trung vào việc phân phối sản phẩm chất lượng.

Câu chuyện của người dùng có thể kiểm thử và có kích thước hiệu quả dẫn đến việc phát triển và thử nghiệm trong giới hạn thời gian được chỉ định.

Học kiểm hử phần mềm chuyên nghiệp

Giới hạn WIP (Công việc đang tiến hành) cho phép tập trung vào một số lượng hạn chế các câu chuyện của người dùng tại một thời điểm.

Bảng Kanban đại diện cho quy trình làm việc một cách trực quan, giúp theo dõi các hoạt động kiểm thử và tắc nghẽn, nếu có.

Khái niệm hợp tác nhóm Kanban cho phép giải quyết các tắc nghẽn khi chúng được xác định, không có thời gian chờ đợi.

Chuẩn bị các trường hợp thử nghiệm trả trước, duy trì bộ thử nghiệm khi quá trình phát triển tiến triển và có được Phản hồi của khách hàng giúp loại bỏ các khiếm khuyết trong vòng lặp / chạy nước rút.

Định nghĩa Xong (DoD) được cho là Xong-Xong theo nghĩa là Câu chuyện đạt đến trạng thái hoàn thành chỉ sau khi thử nghiệm cũng hoàn tất.

Hoạt động thử nghiệm trong phát triển sản phẩm

Trong phát triển sản phẩm, các bản phát hành có thể được theo dõi với tính năng bảng Kanban. Các tính năng cho một bản phát hành cụ thể được gán cho bảng Tính năng Kanban theo dõi trạng thái phát triển tính năng một cách trực quan.

Các tính năng trong một bản phát hành được chia thành các câu chuyện và được phát triển trong bản phát hành bằng cách sử dụng phương pháp nhanh.

Các hoạt động kiểm thử phần mềm sau đây đảm bảo phân phối chất lượng trong mỗi bản phát hành và vào cuối tất cả các bản phát hành

Người kiểm thử tham gia vào Tạo câu chuyện người dùng và do đó đảm bảo

Tất cả các Hành vi có thể có của Hệ thống được ghi lại bằng các Câu chuyện của Người dùng và Yêu cầu Không có chức năng là một phần của Câu chuyện Người dùng.

Câu chuyện của người dùng là Testable.

Kích thước của Câu chuyện người dùng cho phép Phát triển và Kiểm thử hoàn tất (DoneDone) trong Lặp lại.

Nhiệm vụ trực quan Ban Kanban

Mô tả trạng thái và tiến độ của Nhiệm vụ

Nút cổ chai được xác định ngay lập tức khi chúng xảy ra

Tạo điều kiện để đo thời gian chu kỳ có thể được tối ưu hóa

Hợp tác nhóm giúp trong

Trách nhiệm của toàn đội cho chất lượng sản phẩm

Giải quyết các tắc nghẽn khi và khi chúng xảy ra, tiết kiệm thời gian chờ đợi

Đóng góp của mọi chuyên môn trong tất cả các hoạt động

Tích hợp liên tục tập trung vào Kiểm thử tích hợp liên tục

Tự động hóa các bài kiểm thử để tiết kiệm nỗ lực và thời gian kiểm thử

Phòng ngừa khiếm khuyết với các trường hợp thử nghiệm được viết trước đó cho Phát triển và tư vấn cho các Nhà phát triển về những gì được dự đoán bởi các hành vi khác nhau của Hệ thống

Giới hạn WIP để tập trung vào số lượng Câu chuyện người dùng giới hạn tại một thời điểm

Kiểm thử liên tục khi quá trình phát triển tiến triển, để đảm bảo Sửa lỗi trong vòng lặp -

Đảm bảo phạm vi kiểm thử

Giữ số lượng khuyết tật mở thấp

Khám phá câu chuyện

Khám phá Câu chuyện là sự giao tiếp trong một nhóm Agile để khám phá sự hiểu biết về Câu chuyện khi chủ sở hữu sản phẩm vượt qua một câu chuyện để chấp nhận phát triển.

Chủ sở hữu sản phẩm đưa ra câu chuyện dựa trên chức năng mà hệ thống mong đợi. Các nhà phát triển khám phá nhiều hơn về mỗi câu chuyện trước khi họ đánh dấu nó đã sẵn sàng để chấp nhận. Người kiểm thử cũng tham gia vào giao tiếp từ quan điểm kiểm thử để làm cho nó có thể kiểm thử được càng tốt.

Hoàn thiện Câu chuyện dựa trên giao tiếp liên tục và liên tục giữa Chủ sở hữu sản phẩm, Nhà phát triển và Người kiểm thử.

Ước lượng

Ước tính xảy ra trong Kế hoạch phát hành và mỗi Kế hoạch lặp.

Trong Kế hoạch phát hành, người kiểm thử phần mềm cung cấp

Thông tin về những hoạt động kiểm thử được yêu cầu

Ước tính nỗ lực cho cùng

Trong lập kế hoạch Lặp lại, những người thử nghiệm góp phần quyết định những gì và có bao nhiêu câu chuyện có thể được bao gồm trong một lần lặp. Quyết định phụ thuộc vào nỗ lực kiểm thử và ước tính lịch trình kiểm thử. Ước tính Câu chuyện cũng phản ánh ước tính thử nghiệm.

Trong Kanban, Done-Done chỉ được hoàn thành khi một câu chuyện được phát triển và thử nghiệm và được đánh dấu là hoàn thành không có lỗi.

Do đó, Ước tính kiểm thử đóng vai trò chính trong ước tính câu chuyện.

Kế hoạch câu chuyện

Story Planning bắt đầu sau khi Story được ước tính và được gán cho Lặp lại hiện tại.

Story Planning bao gồm các nhiệm vụ kiểm thử sau

Chuẩn bị dữ liệu kiểm thử

Mở rộng các bài kiểm thử phần mềm chấp nhận

Thực hiện kiểm thử thủ công

Tiến hành các buổi kiểm thử thăm dò

Tự động kiểm thử tích hợp liên tục

Ngoài các Nhiệm vụ kiểm thử này, các nhiệm vụ khác cũng có thể được yêu cầu, chẳng hạn như -

Kiểm thử năng suất

Kiểm thử hồi quy

Cập nhật các bài kiểm thử phần mềm tích hợp liên tục

Câu chuyện tiến triển

Story Progression khám phá các thử nghiệm bổ sung được yêu cầu do kết nối liên tục giữa nhà phát triển và người thử nghiệm. Trong các tình huống mà các nhà phát triển cần rõ ràng hơn khi thực hiện, người kiểm thử thực hiện kiểm thử thăm dò.

Kiểm thử liên tục được thực hiện trong Tiến trình câu chuyện và bao gồm Kiểm thử tích hợp liên tục. Toàn bộ đội tham gia vào các hoạt động thử nghiệm.

Chấp nhận câu chuyện

Chấp nhận câu chuyện xảy ra khi câu chuyện đạt đến trạng thái Xong-Xong. tức là câu chuyện được phát triển và thử nghiệm và báo hiệu là hoàn thành.

Thử nghiệm câu chuyện được cho là hoàn thành khi tất cả các thử nghiệm liên quan đến vượt qua câu chuyện hoặc mức độ tự động hóa thử nghiệm được đáp ứng.

Kiểm thử phần mềm - Kiểm tra Agile - Sản phẩm làm việc

Kế hoạch kiểm thử được chuẩn bị tại thời điểm Lập kế hoạch phát hành và được sửa đổi tại mỗi Kế hoạch Sprint. Kế hoạch kiểm thử hoạt động như một hướng dẫn cho quá trình thử nghiệm để có phạm vi kiểm thử hoàn chỉnh.

Nội dung tiêu biểu của Kế hoạch kiểm thử phần mềm là 

Đào tạo kiểm thử phần mềm 

Chiến lược kiểm thử

Môi trường thử nghiệm

Kiểm thử vùng phủ sóng

Phạm vi kiểm thử

Kiểm thử nỗ lực và lịch trình

Công cụ kiểm thử 

Trong các Dự án Agile, tất cả các Thành viên Nhóm chịu trách nhiệm về chất lượng của sản phẩm. Do đó, tất cả mọi người tham gia vào kế hoạch kiểm thử là tốt.

Trách nhiệm của người kiểm thử là cung cấp hướng dẫn cần thiết và cố vấn cho phần còn lại của đội với chuyên môn kiểm thử của họ.

Câu chuyện của người dùng

Câu chuyện người dùng không kiểm thử sản phẩm làm việc trên nguyên tắc. Tuy nhiên, trong các dự án Agile, những người thử nghiệm tham gia vào Tạo câu chuyện người dùng. Người kiểm thử viết Câu chuyện người dùng mang lại giá trị cho khách hàng và bao gồm các hành vi khác nhau có thể có của hệ thống.

Người kiểm thử phần mềm cũng đảm bảo rằng tất cả các Câu chuyện của người dùng đều có thể kiểm thử được và đảm bảo Tiêu chí chấp nhận.

Kiểm thử thủ công và tự động

Trong lần chạy thử đầu tiên, Kiểm thử thủ công được sử dụng. Chúng bao gồm

Bài kiểm thử đơn vị

Kiểm thử tích hợp

Kiểm thử chức năng

Các xét nghiệm phi chức năng

Xét nghiệm nghiệm thu

Các bài kiểm thử sau đó được tự động cho các lần chạy tiếp theo.

Trong Phát triển hướng thử nghiệm, các thử nghiệm đơn vị được viết trước tiên để thất bại, Mã được phát triển và thử nghiệm để đảm bảo các Thử nghiệm vượt qua.

Trong thử nghiệm chấp nhận hướng phát triển , các thử nghiệm chấp nhận được viết trước tiên để thất bại, Code được phát triển và thử nghiệm để đảm bảo các thử nghiệm vượt qua.

Trong các phương pháp Phát triển khác, Người kiểm thử cộng tác với các thành viên còn lại trong Nhóm để đảm bảo Phạm vi kiểm thử.

Trong tất cả các loại phương thức, tích hợp liên tục diễn ra, bao gồm kiểm thử tích hợp liên tục.

Nhóm có thể quyết định khi nào và những bài kiểm thử nào sẽ được tự động hóa. Ngay cả khi tự động hóa các thử nghiệm đòi hỏi nỗ lực và thời gian, các thử nghiệm tự động kết quả sẽ giảm đáng kể nỗ lực và thời gian thử nghiệm lặp đi lặp lại trong các lần lặp của Dự án Agile. 

Điều này lần lượt tạo điều kiện cho nhóm chú ý hơn đến các hoạt động cần thiết khác, chẳng hạn như Câu chuyện người dùng mới, Thay đổi, v.v.

Trong Scrum , các lần lặp được đóng hộp theo thời gian. Do đó, nếu không thể hoàn thành kiểm thử phần mềm Câu chuyện người dùng trong một Sprint cụ thể, người kiểm thử có thể báo cáo trong cuộc họp chờ hàng ngày rằng câu chuyện của người dùng không thể đạt đến Trạng thái đã hoàn thành trong Sprint đó và do đó cần phải chờ đến Sprint tiếp theo.

Kết quả kiểm thử

Vì hầu hết các Thử nghiệm trong Dự án Agile đều được tự động, Công cụ tạo Nhật ký kết quả kiểm thử cần thiết. Người kiểm thử xem lại Nhật ký kết quả kiểm thử. Các kết quả kiểm thử phần mềm cần được duy trì cho mỗi lần chạy nước rút / phát hành.

Tóm tắt kiểm thử cũng có thể được chuẩn bị có chứa

Phạm vi thử nghiệm (Những gì đã được thử nghiệm và những gì chưa được thử nghiệm)

Phân tích lỗi cùng với Phân tích nguyên nhân gốc nếu có thể

Trạng thái kiểm thử hồi quy sau khi sửa lỗi

Các vấn đề và Nghị quyết tương ứng

Vấn đề đang chờ xử lý, nếu có

Bất kỳ sửa đổi nào được yêu cầu trong Chiến lược thử nghiệm

Kiểm thử số liệu

Kiểm thử số liệu báo cáo

Trong các dự án Agile, Số liệu kiểm thử phần mềm bao gồm các số liệu sau cho mỗi Sprint -

Nỗ lực kiểm thử

Kiểm thử độ chính xác dự toán

Kiểm thử vùng phủ sóng

Bảo hiểm kiểm thử tự động

Số khuyết tật

Tỷ lệ lỗi (Số lỗi trên mỗi điểm câu chuyện của người dùng)

Khiếm khuyết nghiêm trọng

Thời gian để khắc phục một lỗi trong cùng một Sprint (Chi phí phải trả là 24x để sửa một lỗi thoát khỏi nước rút hiện tại)

Số lỗi được sửa trong cùng một Sprint

Hoàn thành kiểm thử chấp nhận của khách hàng trong Sprint

Báo cáo hồi cứu và hồi cứu của Sprint

Những người thử nghiệm cũng đóng góp vào Báo cáo Hồi cứu và Hồi cứu của Sprint. Các nội dung tiêu biểu là

Kiểm thử số liệu

Kết quả kiểm thử Nhật ký kết quả xem xét

Điều gì đã đúng và những gì có thể được cải thiện từ Quan điểm thử nghiệm

Thực hành tốt nhất

Bài học kinh nghiệm

Các vấn đề

Phản hồi của khách hàng