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

Kiểm thử phần mềm - Kiểm tra Agile - Kỹ thuật

Kỹ thuật kiểm thử từ thử nghiệm truyền thống cũng có thể được sử dụng trong thử nghiệm Agile. Ngoài ra, các kỹ thuật và thuật ngữ kiểm thử cụ thể của Agile được sử dụng trong các dự án Agile.

Cơ sở kiểm thử

Trong các dự án nhanh, tồn đọng sản phẩm thay thế các tài liệu đặc tả yêu cầu. Nội dung của tồn đọng sản phẩm là câu chuyện người dùng thông thường. 

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

Các yêu cầu phi chức năng cũng được quan tâm trong các câu chuyện của người dùng. Do đó, cơ sở thử nghiệm trong các dự án Agile là câu chuyện của người dùng.

Để đảm bảo Kiểm thử phần mềm chất lượng, những điều sau đây cũng có thể được coi là cơ sở kiểm thử

Kinh nghiệm từ các lần lặp lại trước đó của cùng một dự án hoặc các dự án trong quá khứ.

Các chức năng, kiến ​​trúc, thiết kế, mã và các đặc tính chất lượng hiện có của hệ thống.

Khiếm khuyết dữ liệu từ các dự án hiện tại và quá khứ.

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

Tài liệu người dùng.

Định nghĩa Xong

Định nghĩa Hoàn thành (DoD) là tiêu chí được sử dụng trong các dự án Agile để đảm bảo hoàn thành một hoạt động trong hồ sơ tồn đọng của Sprint. DoD có thể thay đổi từ nhóm Scrum này sang nhóm khác, nhưng nó phải nhất quán trong một nhóm.

DoD là một danh sách kiểm thử các hoạt động cần thiết đảm bảo thực hiện các chức năng và tính năng trong câu chuyện của người dùng cùng với các yêu cầu phi chức năng là một phần của câu chuyện người dùng. Câu chuyện người dùng đạt đến giai đoạn Xong sau khi tất cả các mục trong danh sách kiểm thử DoD được hoàn thành. Một DoD được chia sẻ trên toàn đội.

Một DoD điển hình cho câu chuyện người dùng có thể chứa

Tiêu chí chấp nhận thử nghiệm chi tiết

Tiêu chí để đảm bảo tính nhất quán của Câu chuyện người dùng với những người khác trong Lặp lại

Tiêu chí cụ thể liên quan đến sản phẩm

Các khía cạnh hành vi chức năng

Đặc điểm phi chức năng

Giao diện

Yêu cầu dữ liệu thử nghiệm

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

Tái cấu trúc

Yêu cầu xem xét và phê duyệt

Ngoài DoD cho Câu chuyện của người dùng, DoD cũng được yêu cầu -

ở mọi cấp độ Kiểm thử phần mềm

cho mỗi tính năng

cho mỗi lần lặp

để phát hành

Thông tin kiểm thử

Người kiểm thử cần có thông tin Kiểm thử sau

Câu chuyện người dùng cần được kiểm thử

Tiêu chí chấp nhận liên kết

Giao diện hệ thống

Môi trường nơi Hệ thống dự kiến ​​sẽ hoạt động

Công cụ có sẵn

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

DoD

Trong các dự án Agile, vì thử nghiệm không phải là một hoạt động tuần tự và người thử nghiệm phải làm việc trong chế độ hợp tác, nên trách nhiệm của người thử nghiệm là -

Có được thông tin kiểm thử cần thiết trên cơ sở liên tục.

Xác định các lỗ hổng thông tin ảnh hưởng đến thử nghiệm.

Giải quyết các khoảng trống hợp tác với các thành viên khác trong nhóm.

Quyết định khi đạt đến một mức độ thử nghiệm.

Đảm bảo kiểm thử thích hợp thực hiện tại thời điểm thích hợp.

Thiết kế Kiểm thử phần mềm chức năng và phi chức năng

Trong các dự án Agile, các kỹ thuật thử nghiệm truyền thống có thể được sử dụng, nhưng trọng tâm là thử nghiệm sớm. Các trường hợp thử nghiệm cần được đưa ra trước khi bắt đầu thực hiện.

Đối với thiết kế thử nghiệm chức năng, người thử nghiệm và nhà phát triển có thể sử dụng các kỹ thuật thiết kế thử nghiệm Hộp đen truyền thống như

Phân vùng tương đương

Phân tích giá trị biên

Bàn quyết định

Chuyển nhà nước

Cây lớp

Đối với thiết kế thử nghiệm phi chức năng, vì các yêu cầu phi chức năng cũng là một phần của mỗi câu chuyện của người dùng, các kỹ thuật thiết kế thử nghiệm hộp đen chỉ có thể được sử dụng để thiết kế các trường hợp thử nghiệm có liên quan.

Thử nghiệm thăm dò

Trong các dự án Agile, thời gian thường là yếu tố giới hạn cho Phân tích thử nghiệm và Thiết kế thử nghiệm. Trong những trường hợp như vậy, các kỹ thuật kiểm thử thăm dò có thể được kết hợp với các kỹ thuật kiểm thử truyền thống.

Khám phá thử nghiệm (ET) được định nghĩa là học tập đồng thời, thiết kế thử nghiệm và thực hiện thử nghiệm. Trong Thử nghiệm thăm dò, người kiểm thử chủ động kiểm soát thiết kế của các thử nghiệm khi chúng được thực hiện và sử dụng thông tin thu được trong khi thử nghiệm để thiết kế các thử nghiệm mới và tốt hơn.

Kiểm thử phần mềm thăm dò có ích để phù hợp với những thay đổi trong các dự án Agile.

Thử nghiệm dựa trên rủi ro

Thử nghiệm dựa trên rủi ro là thử nghiệm dựa trên rủi ro thất bại và giảm thiểu rủi ro bằng các kỹ thuật thiết kế thử nghiệm.

Rủi ro chất lượng sản phẩm có thể được định nghĩa là một vấn đề tiềm ẩn với chất lượng sản phẩm. Rủi ro chất lượng sản phẩm bao gồm

Rủi ro chức năng

Rủi ro hiệu suất phi chức năng

Rủi ro khả năng sử dụng phi chức năng

Phân tích rủi ro được thực hiện để đánh giá xác suất (khả năng) và tác động của từng rủi ro. Sau đó, các rủi ro được ưu tiên

Rủi ro cao đòi hỏi phải thử nghiệm rộng rãi

Rủi ro thấp chỉ yêu cầu Kiểm thử phần mềm chữ thảo

Các thử nghiệm được thiết kế bằng cách sử dụng các Kỹ thuật kiểm thử phù hợp dựa trên Mức độ rủi ro và Đặc điểm rủi ro của từng rủi ro. Các thử nghiệm sau đó được thực hiện để giảm thiểu rủi ro.

Kiểm thử sự phù hợp

Kiểm thử phần mềm Fit là Kiểm thử chấp nhận tự động. Công cụ Fit và FitNesse có thể được sử dụng để tự động hóa các bài kiểm thử chấp nhận.

FIT sử dụng JUnit, nhưng mở rộng chức năng thử nghiệm. Bảng HTML được sử dụng để hiển thị các trường hợp thử nghiệm. Lịch thi đấu là một lớp Java đằng sau bảng HTML. Lịch thi đấu lấy nội dung của bảng HTML và chạy các trường hợp thử nghiệm trong dự án đang được thử nghiệm.

Kiểm thử phần mềm - Kiểm thử Agile - Phương pháp

Trong Kiểm thử phần mềm Agile, các phương pháp Kiểm thử thường được sử dụng là từ các thực tiễn truyền thống và được căn chỉnh theo nguyên tắc - Kiểm thử sớm. 

Các trường hợp thử nghiệm được viết trước khi mã được viết. Trọng tâm là phòng ngừa khiếm khuyết, phát hiện và loại bỏ chạy các loại thử nghiệm đúng lúc và đúng cấp độ.

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

Trong chương này, bạn sẽ hiểu về các phương pháp

Kiểm thử hướng phát triển (TDD)

Kiểm thử chấp nhận phát triển hướng (ATDD)

Phát triển hướng hành vi (BDD)

Hướng phát triển thử nghiệm

Trong phương pháp Phát triển hướng thử nghiệm (TDD), mã được phát triển dựa trên phương pháp tiếp cận thử nghiệm được chỉ đạo bởi các trường hợp thử nghiệm tự động. 

Một trường hợp thử nghiệm được viết trước tiên để thất bại, mã được phát triển dựa trên đó để đảm bảo rằng thử nghiệm vượt qua. Phương thức được lặp lại, tái cấu trúc được thực hiện thông qua việc phát triển mã.

TDD có thể được hiểu với sự trợ giúp của các bước sau

Bước 1 - Viết một trường hợp thử nghiệm để phản ánh hành vi dự kiến ​​về chức năng của mã cần được viết.

Bước 2 - Chạy thử nghiệm. Thử nghiệm thất bại vì mã vẫn chưa được phát triển.

Bước 3 - Phát triển mã dựa trên trường hợp thử nghiệm.

Bước 4 - Chạy thử lại. Lần này, bài Kiểm thử phần mềm phải vượt qua khi chức năng được mã hóa. Lặp lại Bước (3) và Bước (4) cho đến khi thử nghiệm vượt qua.

Bước 5 - Tái cấu trúc mã.

Bước 6 - Chạy thử nghiệm một lần nữa để đảm bảo nó vượt qua.

Lặp lại Bước 1 - Bước 6 thêm các trường hợp thử nghiệm để thêm chức năng. Các thử nghiệm được thêm vào và các thử nghiệm trước đó được chạy mỗi lần để đảm bảo mã được chạy như mong đợi. Để làm cho quá trình này nhanh chóng, các bài kiểm thử được tự động.

Các bài kiểm thử có thể ở cấp độ đơn vị, tích hợp hoặc hệ thống. Giao tiếp liên tục giữa người kiểm thử và nhà phát triển cần được đảm bảo.

Kiểm thử chấp nhận phát triển

Trong phương pháp Phát triển dựa trên thử nghiệm chấp nhận (ATDD), mã được phát triển dựa trên phương pháp thử nghiệm đầu tiên được chỉ đạo bởi các trường hợp thử nghiệm chấp nhận. 

Trọng tâm là các tiêu chí chấp nhận và các trường hợp Kiểm thử phần mềm chấp nhận được viết bởi những người thử nghiệm trong quá trình tạo câu chuyện của người dùng phối hợp với khách hàng, người dùng cuối và các bên liên quan.

Bước 1 - Viết các trường hợp kiểm thử chấp nhận cùng với các câu chuyện của người dùng phối hợp với khách hàng và người dùng.

Bước 2 - Xác định các tiêu chí chấp nhận liên quan.

Bước 3 - Xây dựng mã dựa trên các thử nghiệm chấp nhận và tiêu chí chấp nhận.

Bước 4 - Chạy thử nghiệm chấp nhận để đảm bảo mã đang chạy như mong đợi.

Bước 5 - Tự động hóa các bài kiểm thử chấp nhận. Lặp lại Bước 3 - Bước 5 cho đến khi tất cả các câu chuyện của người dùng trong Lặp lại được thực hiện.

Bước 6 - Tự động hóa các bài kiểm thử hồi quy.

Bước 7 - Chạy thử nghiệm hồi quy tự động để đảm bảo hồi quy liên tục.

Phát triển hướng hành vi (BDD)

Phát triển hướng hành vi (BDD) tương tự như Phát triển hướng thử nghiệm (TDD), và trọng tâm là kiểm thử mã để đảm bảo hành vi dự kiến ​​của hệ thống.

Trong BDD, ngôn ngữ như tiếng Anh được sử dụng sao cho hợp lý với người dùng, người Kiểm thử phần mềm và nhà phát triển. Nó đảm bảo

Giao tiếp liên tục giữa người dùng, người thử nghiệm và nhà phát triển.

Minh bạch về những gì đang được phát triển và thử nghiệm.

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

Scrum ủng hộ Cách tiếp cận toàn đội , theo nghĩa là mọi thành viên trong nhóm phải tham gia vào mọi hoạt động của dự án.

Nhóm Scrum tự tổ chức với trách nhiệm với các sản phẩm dự án. Ra quyết định được để lại cho nhóm dẫn đến các hành động thích hợp được thực hiện vào đúng thời điểm mà không có bất kỳ sự chậm trễ nào. 

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

Cách tiếp cận này cũng khuyến khích sử dụng hợp lý tài năng của đội thay vì giới hạn trong một hoạt động. Người thử nghiệm cũng tham gia vào tất cả các dự án và các hoạt động phát triển đóng góp chuyên môn của họ trong thử nghiệm.

Toàn bộ nhóm làm việc cùng nhau về Chiến lược thử nghiệm, Lập kế hoạch kiểm thử phần mềm, Đặc tả thử nghiệm, Thực hiện thử nghiệm, Đánh giá thử nghiệm và Báo cáo kết quả thử nghiệm.

Hợp tác sáng tạo câu chuyện người dùng

Người thử nghiệm tham gia Sáng tạo Câu chuyện Người dùng. Người thử nghiệm đóng góp ý tưởng của họ về hành vi có thể của hệ thống. Điều này giúp khách hàng và / hoặc người dùng cuối hiểu hệ thống trong môi trường thực và do đó hiểu rõ hơn về những gì họ thực sự muốn là kết quả. Điều này dẫn đến việc đóng băng các yêu cầu nhanh hơn và cũng làm giảm khả năng thay đổi các yêu cầu sau này.

Người kiểm thử cũng đưa ra Tiêu chí chấp nhận cho mọi kịch bản được khách hàng đồng ý.

Người kiểm thử góp phần tạo ra những câu chuyện người dùng có thể kiểm chứng.

Kế hoạch phát hành

Kế hoạch phát hành được thực hiện cho toàn bộ dự án. Tuy nhiên, khung Scrum liên quan đến việc ra quyết định lặp đi lặp lại khi có nhiều thông tin hơn trong quá trình thực hiện chạy nước rút. Do đó, phiên Lập kế hoạch phát hành khi bắt đầu dự án không cần phải tạo kế hoạch phát hành chi tiết cho toàn bộ dự án. Nó có thể được cập nhật liên tục, vì thông tin liên quan có sẵn.

Mỗi lần chạy nước rút không cần phải có một bản phát hành. Một bản phát hành có thể sau một nhóm nước rút. Các tiêu chí chính của một bản phát hành là cung cấp giá trị kinh doanh cho khách hàng. Nhóm quyết định độ dài nước rút với kế hoạch phát hành làm đầu vào.

Kế hoạch phát hành là cơ sở của phương pháp thử nghiệm và kế hoạch thử nghiệm để phát hành. Người kiểm thử ước tính Nỗ lực kiểm thử và kế hoạch Kiểm thử để phát hành. Khi kế hoạch phát hành thay đổi, người kiểm thử phải xử lý các thay đổi, có được cơ sở kiểm thử đầy đủ xem xét bối cảnh phát hành lớn hơn.

Người kiểm thử cũng cung cấp nỗ lực kiểm thử được yêu cầu ở cuối tất cả các lần chạy nước rút.

Kế hoạch nước rút

Kế hoạch nước rút được thực hiện vào đầu mỗi lần chạy nước rút. Backlog chạy nước rút được tạo ra với các câu chuyện người dùng nhặt được từ tồn đọng sản phẩm để thực hiện trong lần chạy nước rút cụ thể đó.

Người kiểm thử nên

Xác định khả năng kiểm thử phần mềm các câu chuyện của người dùng được chọn cho lần chạy nước rút

Tạo các bài kiểm thử chấp nhận

Xác định cấp độ kiểm thử

Xác định tự động hóa thử nghiệm

Người kiểm thử cập nhật kế hoạch kiểm thử với các ước tính cho nỗ lực thử nghiệm và thời lượng trong giai đoạn nước rút.

Điều này đảm bảo cung cấp thời gian cho thử nghiệm cần thiết trong thời gian nước rút đóng hộp thời gian và cả trách nhiệm của nỗ lực thử nghiệm.

Phân tích kiểm thử

Khi chạy nước rút bắt đầu, khi các nhà phát triển tiến hành phân tích câu chuyện để thiết kế và triển khai, người kiểm thử thực hiện phân tích thử nghiệm cho các câu chuyện trong hồ sơ tồn đọng nước rút. Tester tạo ra các trường hợp kiểm thử cần thiết - cả kiểm thử thủ công và tự động.

Kiểm thử

Tất cả các thành viên của nhóm Scrum nên tham gia thử nghiệm.

Các nhà phát triển thực hiện các bài kiểm thử đơn vị khi họ phát triển mã cho các câu chuyện của người dùng. Kiểm thử đơn vị được tạo trong mỗi lần chạy nước rút, trước khi mã được viết. Các trường hợp thử nghiệm đơn vị được lấy từ thông số kỹ thuật thiết kế cấp thấp.

Người kiểm thử phần mềm thực hiện các tính năng chức năng và phi chức năng của câu chuyện người dùng.

Những người kiểm thử cố vấn cho các thành viên khác trong nhóm scrum có chuyên môn về kiểm thử để toàn bộ nhóm sẽ có trách nhiệm tập thể về chất lượng sản phẩm.

Vào cuối giai đoạn nước rút, khách hàng và / hoặc người dùng cuối thực hiện Kiểm thử chấp nhận người dùng và cung cấp phản hồi cho nhóm scrum. Điều này hình thành như là một đầu vào cho lần chạy nước rút tiếp theo.

Kết quả kiểm thử được thu thập và duy trì.

Kiểm thử tự động hóa

Kiểm thử tự động hóa được coi trọng trong các nhóm Scrum. Người kiểm thử dành thời gian trong việc tạo, thực hiện, giám sát và duy trì các kiểm thử và kết quả tự động.

Vì các thay đổi có thể xảy ra bất cứ lúc nào trong các dự án scrum, người kiểm thử cần điều chỉnh việc kiểm thử các tính năng đã thay đổi và cả kiểm thử hồi quy liên quan. Kiểm thử tự động hóa tạo điều kiện quản lý nỗ lực kiểm thử liên quan đến các thay đổi.

Kiểm thử tự động ở tất cả các cấp tạo điều kiện đạt được tích hợp liên tục. Kiểm thử tự động chạy nhanh hơn nhiều so với kiểm thử thủ công mà không cần nỗ lực thêm.

Kiểm thử thủ công tập trung nhiều hơn vào kiểm thử thăm dò, lỗ hổng sản phẩm, dự đoán lỗi.

Tự động hóa các hoạt động kiểm thử 

Tự động hóa các hoạt động kiểm thử phần mềm làm giảm gánh nặng của công việc lặp đi lặp lại và tiết kiệm chi phí. Tự động hóa

Tạo dữ liệu thử nghiệm

Đang tải dữ liệu thử nghiệm

Xây dựng triển khai vào môi trường thử nghiệm

Quản lý môi trường thử nghiệm

So sánh đầu ra dữ liệu

Kiểm thử hồi quy

Trong một lần chạy nước rút, người kiểm thử kiểm thử mã mới / được sửa đổi trong lần chạy nước rút đó. Tuy nhiên, người kiểm thử cũng cần đảm bảo rằng mã được phát triển và thử nghiệm trong các lần chạy nước rút trước đó cũng đang hoạt động cùng với mã mới.

Do đó kiểm thử hồi quy được coi trọng trong scrum. Kiểm thử hồi quy tự động được chạy trong tích hợp liên tục.

Quản lý cấu hình

Một hệ thống quản lý cấu hình sử dụng các khung kiểm thử  và xây dựng tự động được sử dụng trong các dự án Scrum. Điều này cho phép chạy phân tích tĩnh và kiểm thử phần mềm đơn vị nhiều lần khi mã mới được kiểm thử vào Hệ thống quản lý cấu hình.

Nó cũng quản lý tích hợp liên tục mã mới với hệ thống. Kiểm thử hồi quy tự động được thực hiện trong quá trình tích hợp liên tục.

Các trường hợp kiểm thử thủ công, kiểm thử tự động, dữ liệu kiểm thử, kế hoạch kiểm thử, chiến lược kiểm thử và các tạo phẩm kiểm thử khác cần phải được Kiểm soát phiên bản và yêu cầu Quyền truy cập có liên quan để được đảm bảo.

Điều này có thể được thực hiện bằng cách duy trì các Tạo phẩm thử nghiệm trong Hệ thống quản lý cấu hình.

Thực hành kiểm thử Agile

Những người thử nghiệm trong Nhóm Scrum có thể tuân theo các Thực tiễn Agile sau 

Ghép nối - Hai thành viên trong nhóm ngồi lại với nhau và hợp tác làm việc. Hai người có thể là hai Người thử nghiệm hoặc một Người thử nghiệm và một Nhà phát triển.

Thiết kế thử nghiệm tăng dần - Các trường hợp thử nghiệm được phát triển khi tiến trình của Sprint tăng dần và Câu chuyện người dùng được thêm vào.

Số liệu Agile

Trong quá trình phát triển phần mềm, thu thập và phân tích các số liệu giúp cải thiện quy trình và từ đó đạt được năng suất tốt hơn, chất lượng cung cấp và sự hài lòng của khách hàng. Trong phát triển dựa trên Scrum, điều này là có thể và những người thử nghiệm phải chú ý đến các số liệu mà họ cần.

Một số số liệu được đề xuất cho phát triển Scrum. Các số liệu quan trọng là

Tỷ lệ Sprint thành công - (Số Sprint thành công / Tổng số Sprint) * 100 . Một Sprint thành công là một trong đó Nhóm có thể đáp ứng cam kết của mình.

Vận tốc - Vận tốc của nhóm dựa trên số điểm Câu chuyện mà một đội kiếm được trong một lần chạy nước rút. Điểm câu chuyện là thước đo của Câu chuyện người dùng được tính trong quá trình ước tính.

Yếu tố tập trung - (Vận tốc / Năng lực làm việc của nhóm) / 100 . Yếu tố tập trung là tỷ lệ phần trăm nỗ lực của nhóm dẫn đến kết thúc câu chuyện.

Độ chính xác ước tính - (Nỗ lực ước tính / Nỗ lực thực tế) / 100. Độ chính xác của Ước tính là khả năng của Nhóm trong việc ước tính nỗ lực một cách chính xác.

Sprint Burndown - Công việc (tính theo Story Story hoặc theo giờ) còn lại Vs. Công việc cần được duy trì lý tưởng (theo Dự toán).

Nếu nhiều hơn, điều đó có nghĩa là Nhóm đã đảm nhận nhiều Công việc hơn họ có thể làm.

Nếu ít hơn, điều đó có nghĩa là Nhóm đã không Ước tính chính xác.

Số lượng khuyết tật - Số lượng lỗi trong một Sprint. Số lượng lỗi là số lượng lỗi trong phần mềm so với tồn đọng.

Mức độ nghiêm trọng của khuyết tật - Các khuyết tật có thể được phân loại thành nhỏ, nghiêm trọng và nghiêm trọng theo mức độ nghiêm trọng của chúng. Người kiểm thử phần mềm có thể xác định phân loại.

Hồi tưởng nước rút

Trong Sprint Retrospectives, tất cả các thành viên trong nhóm sẽ tham gia. Họ chia sẻ -

Những điều đã diễn ra tốt đẹp

Số liệu

Phạm vi cải tiến

Các mục hành động để áp dụng

Kiểm thử phần mềm - Kiểm tra Agile - Quadrant

Như trong trường hợp Thử nghiệm truyền thống, Thử nghiệm Agile cũng cần bao gồm tất cả các Cấp độ thử nghiệm.

Kiểm thử đơn vị

Thử nghiệm hội nhập

Thử nghiệm hệ thống

Kiểm thử phần mềm chấp nhận người dùng

Kiểm thử đơn vị

Thực hiện cùng với Mã hóa, bởi Nhà phát triển

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

Được hỗ trợ bởi Tester, người viết Test Case đảm bảo 100% thiết kế

Các trường hợp kiểm thử đơn vị và kết quả kiểm thử đơn vị cần được xem xét

Các khuyết điểm lớn chưa được giải quyết (theo mức độ ưu tiên và mức độ nghiêm trọng) không được để lại

Tất cả các bài kiểm thử đơn vị được tự động

Thử nghiệm hội nhập

Thực hiện cùng với Tích hợp liên tục khi tiến trình của Sprints

Hoàn thành vào cuối sau khi tất cả các Sprint được hoàn thành

Tất cả các yêu cầu chức năng được Kiểm thử phần mềmTất cả các Giao diện giữa các Đơn vị được kiểm thử

Tất cả các khiếm khuyết được báo cáo

Các xét nghiệm được tự động nếu có thể

Thử nghiệm hệ thống

Thực hiện khi quá trình phát triển

Câu chuyện, tính năng và chức năng của người dùng được kiểm thử

Thử nghiệm được thực hiện trong môi trường sản xuất

Kiểm thử chất lượng được thực hiện (Hiệu suất, Độ tin cậy, v.v.)

Khiếm khuyết được báo cáo

Các xét nghiệm được tự động nếu có thể

Kiểm thử chấp nhận người dùng

Thực hiện vào cuối mỗi Sprint và khi kết thúc dự án

Thực hiện bởi khách hàng. Phản hồi được thực hiện bởi Nhóm

Phản hồi sẽ là đầu vào cho các Sprint tiếp theo

Câu chuyện của người dùng trong Sprint được xác minh trước là có thể Kiểm thử phần mềm được và với Tiêu chí chấp nhận được xác định

Các loại kiểm thử

Kiểm thử thành phần (Kiểm thử đơn vị)

Kiểm thử chức năng (Kiểm thử câu chuyện người dùng)

Các thử nghiệm phi chức năng (Hiệu suất, Tải, Căng thẳng, v.v.)

Xét nghiệm nghiệm thu

Các thử nghiệm có thể hoàn toàn bằng tay, tự động hoàn toàn, kết hợp giữa thủ công và tự động hoặc thủ công được hỗ trợ bởi các công cụ.

Hỗ trợ lập trình và kiểm thử sản phẩm phê bình

Các xét nghiệm có thể cho

Hỗ trợ phát triển (Lập trình hỗ trợ) - Các lập trình viên hỗ trợ được các lập trình viên sử dụng.

Để quyết định mã nào họ cần viết để thực hiện một hành vi nhất định của Hệ thống

Những thử nghiệm nào cần được chạy sau Mã hóa để đảm bảo Mã mới không cản trở các hành vi còn lại của Hệ thống

Chỉ xác minh (Sản phẩm phê bình) - Thử nghiệm sản phẩm phê bình được sử dụng để khám phá những bất cập trong sản phẩm hoàn chỉnh

Thử nghiệm đối mặt với công nghệ và đối mặt với công nghệ

Để quyết định thử nghiệm nào sẽ được thực hiện khi nào, bạn cần xác định xem thử nghiệm có -

Đối mặt với doanh nghiệp, hoặc

Đối mặt với công nghệ

Thử nghiệm đối mặt với doanh nghiệp

Một bài Kiểm thử phần mềm là một bài kiểm thử đối mặt với doanh nghiệp nếu nó trả lời các câu hỏi được đóng khung bằng các từ trong lĩnh vực kinh doanh. Những điều này được các chuyên gia kinh doanh hiểu và sẽ quan tâm đến họ để hành vi của hệ thống có thể được giải thích trong kịch bản thời gian thực.

Kiểm thử công nghệ

Một bài kiểm thử là một bài kiểm thử đối mặt với công nghệ nếu nó trả lời các câu hỏi được đóng khung với các từ từ miền công nghệ. Các lập trình viên hiểu những gì cần được thực hiện dựa trên sự làm rõ về công nghệ.

Hai khía cạnh của các loại thử nghiệm có thể được xem bằng cách sử dụng Bộ tứ kiểm thử  Agile được xác định bởi Brian Marick.

Phần tư kiểm thử Agile

Kết hợp hai khía cạnh của các loại thử nghiệm, Quadrant thử nghiệm Agile sau đây được dẫn xuất bởi Brian Marick

Các Quadrant thử nghiệm Agile cung cấp một phân loại hữu ích để giúp các nhóm xác định, lập kế hoạch và thực hiện thử nghiệm cần thiết.

Quadrant Q1 - Cấp độ đơn vị, Đối mặt công nghệ và hỗ trợ các nhà phát triển. Các bài kiểm thử đơn vị thuộc về Quadrant này. Những bài kiểm thử này có thể là bài kiểm thử tự động.

Quadrant Q2 - Cấp độ hệ thống, kinh doanh phải đối mặt và hành vi sản phẩm phù hợp. Các xét nghiệm chức năng thuộc về góc phần tư này. Các xét nghiệm này là thủ công hoặc tự động.

Quadrant Q3 - Mức chấp nhận của hệ thống hoặc người dùng, đối mặt với doanh nghiệp và tập trung vào các kịch bản thời gian thực. Kiểm thử chấp nhận người dùng thuộc về góc phần tư này. Các xét nghiệm này là thủ công.

Quadrant Q4 - Mức chấp nhận hệ thống hoặc hoạt động, đối mặt với công nghệ và tập trung vào hiệu suất, tải, ứng suất, khả năng duy trì, Kiểm thử phần mềm khả năng mở rộng. Các công cụ đặc biệt có thể được sử dụng cho các thử nghiệm này cùng với thử nghiệm tự động hóa.

Kết hợp những điều này, Quadrant thử nghiệm Agile phản ánh What-tests-Khi nào có thể được hình dung như sau

Kiểm thử phần mềm - Kiểm tra Agile - Thuộc tính quan trọng

Trong chương này, chúng ta sẽ thấy một số thuộc tính quan trọng của Kiểm thử phần mềm Agile.

Lợi ích kiểm thử Agile

Lợi ích của kiểm thử Agile là 

Sự hài lòng của khách hàng bằng cách nhanh chóng, liên tục hoàn toàn thử nghiệm sản phẩm và tìm kiếm phản hồi của khách hàng.

Khóa học kiểm thử phần mềm chuyên nghiệp

Khách hàng, nhà phát triển và người kiểm thử liên tục tương tác với nhau, do đó giảm thời gian chu kỳ.

Người Kiểm thử phần mềm nhanh nhẹn tham gia vào việc xác định các yêu cầu đóng góp chuyên môn kiểm thử của họ để tập trung vào những gì khả thi.

Người kiểm thử nhanh nhẹn tham gia ước tính đánh giá nỗ lực và thời gian kiểm thử.

Thiết kế thử nghiệm sớm phản ánh Tiêu chí chấp nhận.

Yêu cầu kiểm thử được củng cố bởi toàn đội, tránh những hạn chế.

Tập trung liên tục vào chất lượng sản phẩm của toàn đội.

Định nghĩa về các bài kiểm thử  phản ánh trạng thái Xong đảm bảo rằng yêu cầu được đáp ứng.

Phản hồi liên tục về sự chậm trễ hoặc tắc nghẽn để giải quyết có thể được thực hiện ngay lập tức với nỗ lực từ toàn đội.

Đáp ứng nhanh chóng với các yêu cầu thay đổi và cung cấp chúng sớm.

Tích hợp liên tục kiểm thử hồi quy.

Không có thời gian trì hoãn giữa phát triển và thử nghiệm. thử nghiệm đầu tiên, phương pháp thử nghiệm liên tục được theo sau.

Thử nghiệm tự động hóa được triển khai sớm trong vòng đời phát triển, do đó giảm tổng thời gian và nỗ lực thử nghiệm.

Thực hành tốt nhất trong Kiểm thử phần mềm Agile

Thực hiện theo các thực tiễn tốt nhất được đưa ra dưới đây

Bao gồm những người thử nghiệm có chuyên môn trong tất cả các loại thử nghiệm ở tất cả các cấp.

Người kiểm thử tham gia định nghĩa các yêu cầu, hợp tác với khách hàng về hành vi dự kiến ​​của sản phẩm.

Người kiểm thử chia sẻ phản hồi liên tục với các nhà phát triển và khách hàng.

Thử nghiệm phương pháp thử nghiệm đầu tiên và liên tục để phù hợp với công việc phát triển.

Theo dõi tình trạng kiểm thử và tiến độ kiểm thử kịp thời và liên tục với trọng tâm là cung cấp sản phẩm chất lượng.

Tự động hóa thử nghiệm sớm trong vòng đời phát triển để giảm thời gian chu kỳ.

Để thực hiện Kiểm thử hồi quy tận dụng Kiểm thử tự động như một cách hiệu quả.

Những thách thức trong kiểm thử Agile

Những thách thức sau tồn tại trong thử nghiệm Agile

Việc không hiểu được cách tiếp cận Agile và những hạn chế của nó đối với Doanh nghiệp và Quản lý có thể dẫn đến những kỳ vọng không thể thực hiện được.

Agile tuân theo cách tiếp cận toàn nhóm, nhưng không phải ai cũng biết các yếu tố cần thiết của Thực tiễn kiểm thử. Người thử nghiệm được khuyên nên huấn luyện những người khác, nhưng trong kịch bản thực tế có thể không thể thực hiện được với Sprints (Iterations) có thời gian.

Phương pháp thử nghiệm đầu tiên yêu cầu Nhà phát triển dựa trên mã hóa trên Phản hồi của người kiểm thử, nhưng trong các tình huống thực tế, Nhà phát triển đã quen với việc mã hóa các Yêu cầu đến từ Khách hàng hoặc Doanh nghiệp.

Trách nhiệm đối với Sản phẩm chất lượng thuộc về toàn bộ Nhóm Agile, nhưng trong giai đoạn ban đầu, Nhà phát triển có thể không tập trung vào Chất lượng vì họ tập trung hơn vào chế độ triển khai.

Tích hợp liên tục yêu cầu Kiểm thử phần mềm hồi quy đòi hỏi nỗ lực đáng kể, ngay cả khi nó phải được tự động hóa.

Người kiểm thử có thể thích ứng với các thay đổi với tập hợp Agile, nhưng việc điều chỉnh các Thay đổi và kiểm thử kết quả có thể không thể thực hiện được để nhắm mục tiêu hoàn thành trong Sprint.

Tự động hóa sớm được khuyến nghị để có thể giảm thời gian và nỗ lực kiểm thử thủ công. Nhưng, trong kịch bản thực tế, đến các Bài kiểm thử có thể được tự động hóa và tự động hóa chúng đòi hỏi Thời gian và Nỗ lực.

Hướng dẫn kiểm thử nhanh

Sử dụng các hướng dẫn sau trong khi thực hiện Kiểm thử Agile.

Tham gia vào Kế hoạch phát hành để xác định các hoạt động Thử nghiệm cần thiết và đưa ra phiên bản ban đầu của kế hoạch Kiểm thử phần mềm.

Tham gia vào phiên ước tính để đạt được nỗ lực và thời lượng thử nghiệm để các hoạt động kiểm thử được cung cấp trong các lần lặp.

Tham gia vào Định nghĩa câu chuyện của người dùng để đến các trường hợp kiểm thử chấp nhận.

Tham gia vào mọi Cuộc họp Lập kế hoạch Sprint để hiểu phạm vi và cập nhật Kế hoạch kiểm thử.

Liên tục cộng tác với Nhóm phát triển trong Sprint để giúp Thử nghiệm và Mã hóa thành công tốt trong Sprint.

Tham gia vào các cuộc họp độc lập hàng ngày và truyền đạt độ trễ hoặc chặn thử nghiệm nếu có, để nhận được giải pháp ngay lập tức.

Theo dõi và báo cáo tình trạng kiểm thử, tiến độ kiểm thử và chất lượng sản phẩm thường xuyên.

Hãy sẵn sàng để thích ứng với các thay đổi, đáp ứng với các sửa đổi đối với các Trường hợp thử nghiệm, Dữ liệu thử nghiệm.

Tham gia vào Hồi cứu Sprint để hiểu và đóng góp các Thực tiễn và Bài học tốt nhất đã học.

Hợp tác trong việc lấy Phản hồi của Khách hàng tại mỗi Sprint.