Kiểm thử phần mềm 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ử phần mềm 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.

Kiểm thử 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. 

Đào tạo Tester chuyên nghiệp

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 thử phần mềm 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 thử phần mềm thâm nhập và đánh giá lỗ hổng

Kiểm thử 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 thử 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 thử 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 thử phần mềm 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 thử phần mềm 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 thử phần mềm 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 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 độ.

Đào tạo Tester chuyên nghiệp NIIT - ICT Hà Nội

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ử 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ử phần mềm 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 - 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. Kiểm thử phần mềm 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ử phần mềm 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ó thêm thông tin 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ử phần mềm ướ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 đượ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 được chọn 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ử 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ử phần mềm.

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ũng là 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à thực hiện, 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ử phần mềm

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ử 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ử phần mềm 

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ử 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ử phần mềm 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ử đơ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 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à làm việc cùng nhau. 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 các 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à người kiểm thử phần mề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 một đội dựa trên số lượng Đ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 chính xác nỗ lự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 thử 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ử phần mềm đơn vị

Thử nghiệm hội nhập

Thử nghiệm hệ thống

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

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

Kiểm thử đơn vị

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

Đượ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ử phần mềm đơ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ử

Tấ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

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 với 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ử phần mềm 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 - Cấp độ chấp nhận hệ thống hoặc vận hành, đố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ử 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.

Kiểm thử phần mềm - 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.

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.

kiểm thử phần mềm 

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

Người kiểm thử 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 thực hiện 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ử 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ử phần mềm 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ự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 dựa trên 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ử phần mềm 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ử.

Tham gia vào phiên ước tính để đạt được nỗ lực và thời gian 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ử phần mềm và chất lượng sản phẩm thường xuyên.

Hãy sẵn sàng để điều chỉnh 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.

Kiểm thử phần mềm - Hoạt động theo dõi

Tình trạng kiểm thử phần mềm có thể được truyền đạt

Trong các cuộc họp độc lập hàng ngày

Sử dụng các công cụ quản lý kiểm thử tiêu chuẩn

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

Qua tin nhắn

Trạng thái thử nghiệm được xác định bằng trạng thái vượt qua thử nghiệm là rất quan trọng trong việc quyết định liệu tác vụ có được thực hiện hay không. Xong có nghĩa là tất cả các bài kiểm thử phần mềm cho nhiệm vụ vượt qua.

Tiến độ kiểm thử

Tiến trình kiểm thử có thể được theo dõi bằng cách sử dụng

Bảng Scrum (Bảng nhiệm vụ nhanh nhẹn)

Biểu đồ Burndown

Kết quả kiểm thử tự động

Tiến độ thử nghiệm cũng có tác động trực tiếp đến tiến độ phát triển. Điều này là do Câu chuyện người dùng có thể được chuyển sang trạng thái Xong chỉ sau khi đạt được Tiêu chí chấp nhận. Đến lượt nó, điều này được quyết định bởi Trạng thái thử nghiệm vì Tiêu chí chấp nhận được đánh giá theo Trạng thái thử nghiệm.

Nếu có bất kỳ sự chậm trễ hoặc tắc nghẽn trong tiến trình thử nghiệm, toàn bộ nhóm sẽ thảo luận và hợp tác để giải quyết tương tự.

Trong các dự án Agile, các thay đổi diễn ra khá thường xuyên. Khi có nhiều thay đổi diễn ra, chúng ta có thể mong đợi rằng Trạng thái thử nghiệm, Tiến độ thử nghiệm và Chất lượng sản phẩm sẽ phát triển liên tục. Người kiểm thử phần mềm Agile cần lấy thông tin đó cho nhóm để có thể đưa ra các quyết định phù hợp vào đúng thời điểm để đi đúng hướng để hoàn thành thành công mỗi lần lặp.

Khi thay đổi xảy ra, chúng có thể ảnh hưởng đến các tính năng hiện có từ các lần lặp trước. Trong những trường hợp như vậy, các thử nghiệm thủ công và tự động phải được cập nhật để đối phó hiệu quả với rủi ro hồi quy. Kiểm thử hồi quy cũng là cần thiết.

Chất lượng sản phẩm

Số liệu chất lượng sản phẩm bao gồm

Kiểm thử đạt / không đạt

Khiếm khuyết Tìm thấy / Đã sửa

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

Kiểm thử vượt qua / tỷ lệ thất bại

Khiếm khuyết giá khám phá

Mật độ khuyết tật

Tự động hóa việc thu thập và báo cáo các số liệu chất lượng sản phẩm giúp trong

Duy trì tính minh bạch.

Thu thập tất cả các số liệu có liên quan và cần thiết vào đúng thời điểm.

Báo cáo ngay lập tức mà không bị chậm trễ truyền thông.

Cho phép người kiểm thử tập trung vào kiểm thử phần mềm.

Lọc sử dụng sai số liệu.

Để đảm bảo chất lượng sản phẩm tổng thể, nhóm Agile cần có được phản hồi của khách hàng về việc sản phẩm có đáp ứng mong đợi của khách hàng hay không. Điều này cần được thực hiện vào cuối mỗi lần lặp và phản hồi sẽ là đầu vào cho các lần lặp tiếp theo.

Các yếu tố để thành công

Trong các dự án Agile, các sản phẩm chất lượng có thể được phân phối nếu thử nghiệm Agile thành công.

Những điểm sau đây cần được xem xét cho sự thành công của thử nghiệm Agile

Kiểm thử phần mềm Agile dựa trên các phương pháp kiểm thử đầu tiên và liên tục. Do đó, các công cụ kiểm thử truyền thống, được xây dựng theo phương pháp kiểm thử cuối cùng, có thể không phù hợp. Do đó, trong khi chọn Công cụ kiểm thử trong các dự án Agile, sự liên kết với kiểm thử Agile cần phải được xác minh.

Giảm tổng thời gian thử nghiệm bằng cách tự động hóa các thử nghiệm sớm hơn trong vòng đời phát triển.

Người kiểm thử phần mềm nhanh nhẹn cần duy trì tốc độ của mình để phù hợp với lịch phát hành phát triển. Do đó, việc lập kế hoạch, theo dõi và lập kế hoạch lại các hoạt động thử nghiệm thích hợp cần được thực hiện nhanh chóng với chất lượng sản phẩm là mục tiêu.

Thử nghiệm thủ công chiếm tới 80% thử nghiệm trong các dự án. Do đó, những người thử nghiệm có chuyên môn cần phải là một phần của nhóm Agile.

Sự tham gia của những người thử nghiệm có chuyên môn trong suốt vòng đời phát triển làm cho toàn bộ nhóm tập trung vào chất lượng sản phẩm đáp ứng mong đợi của khách hàng.

Xác định câu chuyện của người dùng nhấn mạnh hành vi sản phẩm được người dùng cuối mong đợi.

Xác định Tiêu chí chấp nhận ở cấp độ câu chuyện / cấp độ người dùng theo mong muốn của khách hàng.

Nỗ lực và thời gian ước tính cho các hoạt động thử nghiệm.

Lập kế hoạch thử nghiệm hoạt động.

Liên kết với nhóm phát triển để đảm bảo sản xuất mã đáp ứng các yêu cầu với thiết kế thử nghiệm trả trước.

Thử nghiệm đầu tiên và thử nghiệm liên tục để đảm bảo đạt được trạng thái thực hiện đáp ứng các tiêu chí chấp nhận tại thời điểm dự kiến.

Đảm bảo thử nghiệm ở tất cả các cấp trong nước rút.

kiểm thử phần mềm hồi quy ở cuối mỗi lần chạy nước rút.

Thu thập và phân tích các số liệu sản phẩm hữu ích cho sự thành công của dự án.

Phân tích lỗi để xác định cái nào cần sửa trong Sprint hiện tại và cái nào có thể bị trì hoãn cho các Sprint tiếp theo.

Tập trung vào những gì quan trọng từ quan điểm của Khách hàng.

Lisa Crispin đã xác định bảy yếu tố chính để thử nghiệm thành công Agile -

Phương pháp tiếp cận toàn đội - Trong cách tiếp cận này, các nhà phát triển đào tạo người thử nghiệm và người thử nghiệm đào tạo các thành viên khác trong nhóm. 

Điều này giúp mọi người hiểu mọi nhiệm vụ trong dự án, từ đó cộng tác và đóng góp sẽ có lợi ích tối đa. Sự hợp tác của người thử nghiệm với khách hàng cũng là một yếu tố quan trọng để đặt kỳ vọng của họ ngay từ đầu và chuyển các tiêu chí chấp nhận sang yêu cầu để vượt qua thử nghiệm.

Tư duy kiểm thử nhanh nhẹn - Những người thử nghiệm chủ động liên tục cải thiện chất lượng và cộng tác liên tục với các thành viên còn lại trong nhóm.

Tự động kiểm thử hồi quy - Thiết kế để kiểm thử và phát triển ổ đĩa với các bài kiểm thử. Bắt đầu đơn giản và cho phép nhóm chọn các công cụ. Hãy sẵn sàng để cung cấp lời khuyên.

Cung cấp và lấy phản hồi - Vì đây là giá trị Agile cốt lõi, toàn bộ nhóm nên được mở để nhận phản hồi. Vì người kiểm thử là nhà cung cấp phản hồi chuyên gia, cần tập trung vào thông tin liên quan và cần thiết. Đổi lại, về việc có được thông tin phản hồi nên phù hợp với thay đổi và thử nghiệm trường hợp thử nghiệm.

Xây dựng một nền tảng thực hành Agile cốt lõi - Tập trung vào kiểm thử bên cạnh mã hóa, tích hợp liên tục, môi trường kiểm thử phần mềm hợp tác, làm việc tăng dần, chấp nhận thay đổi, duy trì sức mạnh tổng hợp.

Phối hợp với khách hàng - Lấy ví dụ, hiểu và kiểm thử phần mềm ánh xạ yêu cầu đối với hành vi của sản phẩm, thiết lập Tiêu chí chấp nhận, nhận phản hồi.

Nhìn vào Bức tranh lớn - Phát triển ổ đĩa với các thử nghiệm và ví dụ đối mặt với doanh nghiệp bằng cách sử dụng dữ liệu thử nghiệm trong thế giới thực và suy nghĩ về các tác động trên các lĩnh vực khác.

Kiểm thử phần mềm - Người kiểm thử trong nhóm

Agile Development là trung tâm nhóm và các nhà phát triển và người thử nghiệm tham gia vào tất cả các hoạt động của dự án và phát triển. Teamwork tối đa hóa thành công của thử nghiệm trong các dự án Agile.

Một người thử nghiệm trong nhóm Agile phải tham gia và đóng góp cho tất cả các hoạt động của dự án và đồng thời phải tận dụng chuyên môn trong thử nghiệm.

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

Một người kiểm thử phần mềm Agile nên có kỹ năng kiểm thử truyền thống. Ngoài ra, người kiểm thử  Agile cần.

Kỹ năng giao tiếp tốt.

Khả năng hành động tích cực và định hướng giải pháp với các thành viên trong nhóm và các bên liên quan.

Khả năng hiển thị quan trọng, định hướng chất lượng, suy nghĩ hoài nghi về sản phẩm.

Khả năng chủ động để chủ động thu thập thông tin từ các bên liên quan.

Kỹ năng làm việc hiệu quả với khách hàng và các bên liên quan trong việc xác định Câu chuyện người dùng có thể kiểm thử , Tiêu chí chấp nhận.

Tài năng để trở thành một thành viên nhóm tốt làm việc với các nhà phát triển trong việc sản xuất mã chất lượng.

Khả năng sử dụng các kỹ năng kiểm thử để có các trường hợp kiểm thử đúng vào đúng thời điểm và đúng cấp độ và thực hiện chúng tốt trong thời gian chạy nước rút.

Có khả năng đánh giá và báo cáo kết quả kiểm thử , tiến độ kiểm thử và chất lượng sản phẩm.

Cởi mở để đáp ứng với các thay đổi nhanh chóng, bao gồm thay đổi, thêm hoặc cải thiện các trường hợp thử nghiệm.

Tiềm năng tự tổ chức công việc.

Nhiệt tình để tăng trưởng kỹ năng liên tục.

Năng lực trong Tự động hóa thử nghiệm, Phát triển dựa trên thử nghiệm (TDD), Phát triển dựa trên thử nghiệm chấp nhận (ATDD), Phát triển hướng hành vi (BDD) và Thử nghiệm dựa trên kinh nghiệm.

Vai trò của Người kiểm thử phần mềm trong Nhóm Agile

Người kiểm thử trong Nhóm Agile tham gia vào tất cả các hoạt động của dự án và phát triển để đóng góp tốt nhất về chuyên môn thử nghiệm.

Các hoạt động của Agile Tester bao gồm

Đảm bảo sử dụng đúng các công cụ kiểm thử .

Cấu hình, sử dụng và quản lý môi trường thử nghiệm và dữ liệu thử nghiệm.

Kèm cặp các thành viên khác trong các khía cạnh liên quan của thử nghiệm.

Đảm bảo rằng các nhiệm vụ thử nghiệm thích hợp được lên lịch trong quá trình phát hành và lập kế hoạch chạy nước rút.

Hiểu, thực hiện và cập nhật chiến lược kiểm thử.

Phối hợp với các nhà phát triển, khách hàng và các bên liên quan trong việc làm rõ các yêu cầu, về khả năng kiểm thử , tính nhất quán và tính đầy đủ.

Thực hiện các bài kiểm thử đúng vào đúng thời điểm và đúng cấp độ kiểm thử .

Báo cáo lỗi và làm việc với nhóm trong việc giải quyết chúng.

Đo lường và báo cáo phạm vi kiểm thử trên tất cả các kích thước bảo hiểm áp dụng.

Tham gia hồi cứu nước rút, chủ động đề xuất và thực hiện cải tiến.

Trong Vòng đời Agile, người kiểm thử phần mềm đóng vai trò quan trọng trong

Làm việc theo nhóm

Kế hoạch kiểm thử

Nước rút không

Hội nhập

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

Làm việc theo nhóm

Trong Phát triển Agile, làm việc nhóm là cơ bản và do đó đòi hỏi những điều sau đây -

Phương pháp hợp tác - Làm việc với các thành viên nhóm chức năng chéo về Chiến lược thử nghiệm, Lập kế hoạch kiểm thử , Đặ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. Đóng góp chuyên môn kiểm thử kết hợp với các hoạt động nhóm khác.

Tự tổ chức - Lập kế hoạch và tổ chức tốt trong giai đoạn nước rút để đạt được các mục tiêu thử nghiệm bằng cách hợp nhất chuyên môn từ các thành viên khác trong nhóm.

Trao quyền - Đưa ra các quyết định kỹ thuật phù hợp trong việc đạt được các mục tiêu của nhóm.

Cam kết - Cam kết hiểu và đánh giá hành vi và đặc điểm của sản phẩm theo yêu cầu của khách hàng và các bên liên quan.

Minh bạch - Mở, Giao tiếp và Có trách nhiệm.

Độ tin cậy - Đảm bảo độ tin cậy của chiến lược thử nghiệm, việc thực hiện và thực hiện. Giữ cho khách hàng và các bên liên quan được thông báo về chiến lược thử nghiệm.

Mở để phản hồi - Tham gia vào quá trình hồi tưởng nước rút để học hỏi từ cả thành công và thất bại. Tìm kiếm phản hồi của khách hàng và hành động nhanh chóng và phù hợp để đảm bảo chất lượng cung cấp.

Kiên cường - Đáp ứng với những thay đổi.

Kế hoạch kiểm thử.

Kế hoạch kiểm thử nên bắt đầu trong quá trình lập kế hoạch phát hành và cập nhật trong mỗi lần chạy nước rút. Lập kế hoạch kiểm thử nên bao gồm các nhiệm vụ sau

Xác định phạm vi thử nghiệm, phạm vi thử nghiệm, thử nghiệm và chạy nước rút mục tiêu.

Quyết định về môi trường thử nghiệm, công cụ kiểm thử , dữ liệu thử nghiệm và cấu hình.

Chỉ định thử nghiệm các tính năng và đặc điểm.

Lập lịch các nhiệm vụ kiểm thử phần mềm và xác định tần suất của các bài kiểm thử .
thử ác định phương pháp thử nghiệm, kỹ thuật, công cụ và dữ liệu thử nghiệm.

Nâng cao các điều kiện tiên quyết như nhiệm vụ, chuyên môn và đào tạo tiền nhiệm.

Xác định các phụ thuộc như chức năng, mã, thành phần hệ thống, nhà cung cấp, công nghệ, công cụ, hoạt động, nhiệm vụ, nhóm, loại thử nghiệm, mức độ kiểm thử và ràng buộc.

Đặt ưu tiên xem xét tầm quan trọng của khách hàng / người dùng và phụ thuộc.

Đến thời gian và nỗ lực cần thiết để kiểm thử .

Xác định nhiệm vụ tại mỗi kế hoạch nước rút.

Nước rút không

Sprint Zero liên quan đến các hoạt động chuẩn bị trước khi nước rút đầu tiên. Người kiểm thử cần cộng tác với nhóm trong các hoạt động sau

Xác định phạm vi

Chia câu chuyện của người dùng thành các lần chạy nước rút

Tạo kiến ​​trúc hệ thống

Lập kế hoạch, mua và cài đặt các công cụ (bao gồm các công cụ kiểm thử )

Tạo chiến lược thử nghiệm ban đầu cho tất cả các cấp độ thử nghiệm

Xác định số liệu kiểm thử

Chỉ định tiêu chí chấp nhận, còn được gọi là định nghĩa của Done Done

Xác định tiêu chí xuất cảnh

Tạo bảng Scrum

Đặt hướng để thử nghiệm trong các lần chạy nước rút

Hội nhập

Trong Agile, một sản phẩm hoạt động chất lượng phải sẵn sàng để phát hành tại bất kỳ thời điểm nào trong vòng đời phát triển. Điều này ngụ ý tích hợp liên tục như là một phần của sự phát triển. Một người kiểm thử phần mềm Agile cần hỗ trợ tích hợp liên tục với kiểm thử liên tục.

Để thực hiện điều này, một người kiểm thử cần phải

Hiểu chiến lược hội nhập.

Xác định tất cả các phụ thuộc giữa các chức năng và tính năng.

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

Một người kiểm thử Agile cần điều chỉnh các thực hành Agile để kiểm thử trong một dự án nhanh.

Ghép nối - Hai thành viên trong nhóm làm việc cùng nhau trên cùng một bàn phím. Là một trong số họ kiểm thử , các đánh giá / phân tích thử nghiệm khác. Hai thành viên trong nhóm có thể

Một người thử nghiệm và một nhà phát triển

Một người thử nghiệm và một nhà phân tích kinh doanh

Hai người thử

Thiết kế thử nghiệm tăng dần - Các trường hợp thử nghiệm được xây dựng từ các câu chuyện của người dùng, bắt đầu bằng các thử nghiệm đơn giản và chuyển sang các thử nghiệm phức tạp hơn.

Sơ đồ tư duy - Bản đồ tư duy là một sơ đồ để sắp xếp thông tin một cách trực quan. Sơ đồ tư duy có thể được sử dụng như một công cụ hiệu quả trong kiểm thử Agile, sử dụng thông tin nào liên quan đến các phiên kiểm thử cần thiết, chiến lược kiểm thử  và dữ liệu kiểm thử phần mềm có thể được tổ chức.

Kiểm thử phần mềm - Các vấn đề pháp lý

Trước khi cho phép ai đó kiểm thử phần mềm dữ liệu nhạy cảm, các công ty thường thực hiện các biện pháp liên quan đến tính sẵn có, bảo mật và tính toàn vẹn của dữ liệu. 

Để thỏa thuận này được thực hiện, tuân thủ pháp luật là một hoạt động cần thiết cho một tổ chức.

Kiểm thử phần mềm

Các quy định pháp lý quan trọng nhất phải được tuân thủ khi thiết lập và duy trì các hệ thống bảo mật và ủy quyền được trình bày dưới đây trong bối cảnh sử dụng để thực hiện các thử nghiệm thâm nhập.

Các vấn đề pháp lý là gì?

Sau đây là một số vấn đề có thể phát sinh giữa người thử nghiệm và khách hàng của anh ta

Người kiểm thử phần mềm không biết khách hàng của mình - vì vậy, trên cơ sở nào, anh ta nên được cấp quyền truy cập dữ liệu nhạy cảm

Ai sẽ đảm bảo an toàn cho dữ liệu bị mất?

Khách hàng có thể đổ lỗi cho việc mất dữ liệu hoặc bảo mật cho người kiểm thử phần mềm

kiểm thử phần mềm thâm nhập có thể ảnh hưởng đến hiệu suất hệ thống và có thể nêu ra các vấn đề về bảo mật và toàn vẹn; do đó, điều này rất quan trọng, ngay cả trong một thử nghiệm thâm nhập nội bộ, được thực hiện bởi một nhân viên nội bộ để xin phép bằng văn bản. 

Cần có một thỏa thuận bằng văn bản giữa người kiểm thử phần mềm và công ty / tổ chức / cá nhân để làm rõ tất cả các điểm liên quan đến bảo mật dữ liệu, công bố thông tin, vv trước khi bắt đầu thử nghiệm.

Một tuyên bố về ý định nên được soạn thảo và ký hợp lệ bởi cả hai bên trước khi thực hiện bất kỳ công việc thử nghiệm nào. Cần phải nêu rõ rằng phạm vi của công việc và rằng, bạn có thể và không thể làm trong khi thực hiện các bài kiểm thử phần mềm lỗ hổng.

Đối với người thử nghiệm, điều quan trọng là phải biết ai sở hữu doanh nghiệp hoặc hệ thống đang được yêu cầu làm việc và cơ sở hạ tầng giữa các hệ thống thử nghiệm và các mục tiêu của họ có thể bị ảnh hưởng bởi thử nghiệm bút. Ý tưởng là để đảm bảo;

Người kiểm thử phần mềm có quyền bằng văn bản, với các tham số được xác định rõ ràng.

công ty có các chi tiết về máy thử bút của mình và đảm bảo rằng ông sẽ không rò rỉ bất kỳ dữ liệu bí mật nào.

Một thỏa thuận pháp lý có lợi cho cả hai bên. Hãy nhớ rằng, các quy định thay đổi từ quốc gia này sang quốc gia khác, vì vậy hãy luôn tuân thủ luật pháp của quốc gia bạn. Ký một thỏa thuận chỉ sau khi xem xét các luật tương ứng.

Kiểm thử phần mềm - Khắc phục

Những nỗ lực kiểm thử phần mềm thâm nhập - tuy có thể triệt để - có thể luôn luôn đảm bảo một khám phá toàn diện về mọi trường hợp trong đó hiệu quả của kiểm soát an ninh là không đủ.

Xác định lỗ hổng hoặc rủi ro kịch bản chéo trang trong một khu vực của ứng dụng có thể không chắc chắn phơi bày tất cả các trường hợp của lỗ hổng này có trong ứng dụng. Chương này minh họa khái niệm và tiện ích của khắc phục.

Kiểm thử phần mềm

Khắc phục hậu quả là gì?

Khắc phục hậu quả là một hành động đưa ra một cải tiến để thay thế một sai lầm và đặt nó đúng. Thông thường sự hiện diện của lỗ hổng trong một khu vực có thể cho thấy sự yếu kém trong quá trình hoặc thực tiễn phát triển có thể đã nhân rộng hoặc kích hoạt lỗ hổng tương tự ở các vị trí khác.

Do đó, trong khi điều chỉnh lại, điều quan trọng là người kiểm thử phải điều tra cẩn thận thực thể hoặc ứng dụng được kiểm thử phần mềm có kiểm soát bảo mật không hiệu quả.

Vì những lý do này, công ty tương ứng nên thực hiện các bước để khắc phục mọi lỗ hổng có thể khai thác trong một khoảng thời gian hợp lý sau khi kiểm thử thâm nhập ban đầu.

Trên thực tế, ngay sau khi công ty hoàn thành các bước này, người kiểm thử bút nên thực hiện kiểm thử lại để xác thực các kiểm soát mới được thực hiện có khả năng giảm thiểu rủi ro ban đầu.

Các nỗ lực khắc phục kéo dài trong một thời gian dài hơn sau khi thử nghiệm bút ban đầu có thể yêu cầu thực hiện cam kết thử nghiệm mới để đảm bảo kết quả chính xác của môi trường hiện tại nhất.

Quyết định này nên được thực hiện sau khi phân tích rủi ro về mức độ thay đổi đã xảy ra kể từ khi thử nghiệm ban đầu được hoàn thành.

Hơn nữa, trong các điều kiện cụ thể, vấn đề bảo mật được gắn cờ có thể minh họa một lỗ hổng cơ bản trong môi trường hoặc ứng dụng tương ứng.

Do đó, phạm vi kiểm thử lại nên xem xét liệu có bất kỳ thay đổi nào gây ra bởi việc khắc phục được xác định từ thử nghiệm được phân loại là đáng kể hay không.

Tất cả các thay đổi nên được kiểm thử lại; tuy nhiên, việc kiểm thử phần mềm lại toàn bộ hệ thống có cần thiết hay không sẽ được xác định bằng đánh giá rủi ro của các thay đổi.

Kiểm thử phần mềm - Hạn chế

Bởi vì tốc độ phát triển nhanh chóng trong lĩnh vực thông tin và công nghệ, câu chuyện thành công của thử nghiệm thâm nhập là tương đối ngắn. 

Khi cần bảo vệ nhiều hơn cho các hệ thống, thường xuyên hơn bạn cần thực hiện kiểm thử phần mềm thâm nhập để giảm khả năng tấn công thành công đến mức được công ty đánh giá cao.

Sau đây là những hạn chế chính của Kiểm thử thâm nhập

Giới hạn thời gian - Như tất cả chúng ta đều biết, kiểm thử thâm nhập không phải là bài tập ràng buộc mọi lúc; tuy nhiên, các chuyên gia kiểm thử thâm nhập đã phân bổ một lượng thời gian cố định cho mỗi thử nghiệm. 

kiểm thử phần mềm

Mặt khác, những kẻ tấn công không bị hạn chế về thời gian, họ lên kế hoạch cho nó trong một tuần, tháng hoặc thậm chí nhiều năm.

Giới hạn phạm vi - Nhiều tổ chức không kiểm thử mọi thứ, vì những hạn chế của riêng họ, bao gồm các hạn chế về tài nguyên, hạn chế bảo mật, hạn chế về ngân sách, v.v.

Tương tự như vậy, một người kiểm thử  có phạm vi hạn chế và anh ta phải rời khỏi nhiều phần của hệ thống có thể dễ bị tổn thương hơn nhiều và có thể là một ngách hoàn hảo cho kẻ tấn công.

Giới hạn về quyền truy cập - Người kiểm thử thường xuyên hơn đã hạn chế quyền truy cập vào môi trường đích. Ví dụ: nếu một công ty đã thực hiện thử nghiệm thâm nhập đối với các hệ thống DMZ của mình từ tất cả các mạng internet của mình, nhưng điều gì sẽ xảy ra nếu những kẻ tấn công tấn công qua cổng internet thông thường.

Giới hạn của Phương pháp - Có nhiều khả năng hệ thống mục tiêu có thể gặp sự cố trong quá trình kiểm thử thâm nhập, do đó, một số phương pháp tấn công cụ thể có thể sẽ bị tắt khỏi bàn đối với người kiểm thử phần mềm thâm nhập chuyên nghiệp.

Ví dụ: tạo ra một cơn lũ từ chối dịch vụ để chuyển hướng một quản trị viên hệ thống hoặc mạng khỏi một phương thức tấn công khác, thường là một chiến thuật lý tưởng cho một kẻ thực sự xấu, nhưng nó có khả năng nằm ngoài các quy tắc tham gia đối với hầu hết những người thử nghiệm thâm nhập chuyên nghiệp .

Giới hạn bộ kỹ năng của Người kiểm thử thâm nhập - Thông thường, người kiểm thử thâm nhập chuyên nghiệp bị hạn chế vì họ có kỹ năng hạn chế bất kể chuyên môn và kinh nghiệm trong quá khứ của họ. Hầu hết trong số họ tập trung vào một công nghệ cụ thể và có kiến ​​thức hiếm về các lĩnh vực khác.

Giới hạn của khai thác đã biết - Nhiều người thử nghiệm chỉ biết những khai thác đó là công khai. Trên thực tế, sức mạnh tưởng tượng của họ không được phát triển như những kẻ tấn công. Những kẻ tấn công thường nghĩ xa hơn suy nghĩ của người kiểm thử và phát hiện ra lỗ hổng để tấn công.

Giới hạn Thử nghiệm - Hầu hết những người thử nghiệm bị ràng buộc về thời gian và làm theo các hướng dẫn đã được cung cấp cho họ bởi tổ chức hoặc người cao niên của họ.

Họ không thử một cái gì đó mới. Họ không nghĩ xa hơn những chỉ dẫn đã cho. Mặt khác, những kẻ tấn công có thể tự do suy nghĩ, thử nghiệm và tạo ra một số con đường mới để tấn công.

Hơn nữa, kiểm thử thâm nhập không thể thay thế các kiểm thử bảo mật CNTT thông thường, cũng không thể thay thế chính sách bảo mật chung, mà thay vào đó, kiểm thử phần mềm thâm nhập bổ sung cho các quy trình xem xét đã thiết lập và phát hiện ra các mối đe dọa mới.

Kiểm thử phần mềm Vs. Hacking đạo đức

Kiểm thử phần mềm thâm nhập có liên quan rất chặt chẽ với hack đạo đức, vì vậy hai thuật ngữ này thường được sử dụng thay thế cho nhau.

Tuy nhiên, có một dòng khác biệt mỏng giữa hai điều khoản này. Chương này cung cấp cái nhìn sâu sắc về một số khái niệm cơ bản và sự khác biệt cơ bản giữa thử nghiệm thâm nhập và hack đạo đức.

Kiểm thử phần mềm

Kiểm thử phần mềm thâm nhập

Kiểm thử thâm nhập là một thuật ngữ cụ thể và chỉ tập trung vào việc khám phá các lỗ hổng, rủi ro và môi trường mục tiêu với mục đích bảo mật và kiểm soát hệ thống.

Hay nói cách khác, thử nghiệm thâm nhập nhắm vào các hệ thống phòng thủ của tổ chức tương ứng bao gồm tất cả các hệ thống máy tính và cơ sở hạ tầng của nó.

Hacking đạo đức

Mặt khác, hack đạo đức là một thuật ngữ bao quát tất cả các kỹ thuật hack và các kỹ thuật tấn công máy tính liên quan khác.

Vì vậy, cùng với việc phát hiện ra các lỗ hổng bảo mật và lỗ hổng bảo mật, và đảm bảo an ninh cho hệ thống mục tiêu, nó vượt ra ngoài việc hack hệ thống nhưng với sự cho phép để bảo vệ an ninh cho mục đích tương lai.

Do đó, chúng ta có thể rằng, đó là một thuật ngữ ô và kiểm thử phần mềm thâm nhập là một trong những tính năng của hack đạo đức.

Sau đây là những khác biệt chính giữa thử nghiệm thâm nhập và hack đạo đức được liệt kê trong bảng sau 

Kiểm thử thâm nhập	Hacking đạo đức
Một thuật ngữ hẹp chỉ tập trung vào kiểm thử thâm nhập để bảo mật hệ thống bảo mật.	Một thuật ngữ toàn diện và kiểm thử thâm nhập là một trong những tính năng của nó.
Một người kiểm thử về cơ bản không cần phải có kiến ​​thức toàn diện về mọi thứ thay vì chỉ có kiến ​​thức về lĩnh vực cụ thể mà anh ta tiến hành kiểm thử bút.	Một hacker đạo đức về cơ bản cần phải có kiến ​​thức toàn diện về lập trình phần mềm cũng như phần cứng.
Một người kiểm thử không nhất thiết phải là một người viết báo cáo tốt.	Một hacker đạo đức về cơ bản cần phải là một chuyên gia về viết báo cáo.
Bất kỳ người thử nghiệm nào với một số đầu vào của kiểm thử thâm nhập đều có thể thực hiện kiểm thử bút.	Nó đòi hỏi phải là một chuyên gia chuyên môn trong chủ đề này, người có chứng nhận bắt buộc về hack đạo đức để có hiệu quả.
Giấy làm việc ít hơn so với hack đạo đức.	Một công trình giấy chi tiết được yêu cầu, bao gồm cả thỏa thuận pháp lý, vv
Để thực hiện loại thử nghiệm này, cần ít thời gian hơn.	Hack đạo đức liên quan đến rất nhiều thời gian và nỗ lực so với thử nghiệm thâm nhập.
Thông thường, khả năng truy cập của toàn bộ hệ thống máy tính và cơ sở hạ tầng của nó không yêu cầu. Khả năng truy cập chỉ được yêu cầu cho phần mà người kiểm thử thực hiện kiểm thử bút.	Theo tình hình, nó thường yêu cầu toàn bộ khả năng tiếp cận tất cả các hệ thống máy tính và cơ sở hạ tầng của nó.

Vì các kỹ thuật thâm nhập được sử dụng để bảo vệ khỏi các mối đe dọa, những kẻ tấn công tiềm năng cũng nhanh chóng trở nên ngày càng tinh vi hơn và phát minh ra những điểm yếu mới trong các ứng dụng hiện tại.

Do đó, một loại thử nghiệm thâm nhập cụ thể là không đủ để bảo vệ tính bảo mật của bạn đối với các hệ thống được thử nghiệm.

Theo báo cáo, trong một số trường hợp, một lỗ hổng bảo mật mới được phát hiện và cuộc tấn công thành công đã diễn ra ngay sau khi thử nghiệm thâm nhập.

Tuy nhiên, điều đó không có nghĩa là kiểm thử phần mềm thâm nhập là vô ích. Điều đó chỉ có nghĩa là, điều này đúng với việc kiểm thử thâm nhập triệt để, không có gì đảm bảo rằng một cuộc tấn công thành công sẽ không diễn ra, nhưng chắc chắn, thử nghiệm sẽ giảm đáng kể khả năng tấn công thành công.

Kiểm thử phần mềm - Hacking đạo đức

Sự phát triển nhanh chóng của internet đã thay đổi cách sống của mọi người. Ngày nay, hầu hết các công trình tư nhân và công cộng đều phụ thuộc vào internet. Chính phủ tất cả các kế hoạch làm việc bí mật, và hoạt động đều dựa trên internet. Tất cả những điều này làm cho cuộc sống rất đơn giản và dễ dàng truy cập kiểm thử phần mềm.

Nhưng với tin tốt, cũng có một mặt tối của sự phát triển này, tức là tin tặc hình sự. Không có giới hạn địa chính trị của những tin tặc hình sự này, chúng có thể hack bất kỳ hệ thống nào từ bất kỳ nơi nào trên thế giới. Họ có thể làm hỏng dữ liệu bí mật và lịch sử tín dụng rất tệ.

Kiểm thử phần mềm

Do đó, để bảo vệ khỏi các tin tặc hình sự, khái niệm về tin tặc đạo đức đã phát triển. Chương này thảo luận về khái niệm và vai trò của một hacker đạo đức kiểm thử phần mềm.

Tin tặc đạo đức là ai?

Tin tặc đạo đức là các chuyên gia máy tính được phép hợp pháp để hack một hệ thống máy tính với mục tiêu bảo vệ khỏi các tin tặc hình sự. Một hacker đạo đức xác định các lỗ hổng và rủi ro của một hệ thống và gợi ý cách loại bỏ chúng.

Tin tặc hình sự là ai?

Tin tặc hình sự là những chuyên gia lập trình máy tính chuyên hack các hệ thống khác với mục đích đánh cắp dữ liệu, đánh cắp tiền, phỉ báng tín dụng của người khác, phá hủy dữ liệu của người khác, tống tiền ai đó, v.v.

Tin tặc hình sự có thể làm gì?

Khi một hệ thống bị hack, một hacker hình sự có thể làm bất cứ điều gì với hệ thống đó. Hai hình ảnh sau đây CC Palmer, được công bố trên pdf.textfiles.com, minh họa một ví dụ đơn giản về một trang bị hack

Dưới đây là ảnh chụp màn hình của một trang web được chụp trước khi nó bị hack

Và, đây là ảnh chụp màn hình của cùng một trang web sau khi nó bị hack

Bộ kỹ năng của tin tặc đạo đức là gì?

Các hacker chuyên nghiệp về đạo đức có các bộ kỹ năng sau đây để hack hệ thống về mặt đạo đức

Họ phải đáng tin cậy.

Bất kể rủi ro và lỗ hổng nào, họ phát hiện ra trong khi thử nghiệm hệ thống, kiểm thử phần mềm họ phải giữ bí mật.

Khách hàng cung cấp thông tin bí mật về cơ sở hạ tầng hệ thống của họ như địa chỉ IP, mật khẩu, v.v ... Tin tặc đạo đức cần giữ bí mật thông tin này.

Tin tặc đạo đức phải có kiến ​​thức âm thanh về lập trình máy tính, mạng và phần cứng.

Họ nên có kỹ năng phân tích tốt để phân tích tình huống và suy đoán rủi ro trước.

Họ nên có kỹ năng quản lý cùng với sự kiên nhẫn, vì thử nghiệm bút có thể mất một ngày, một tuần hoặc thậm chí nhiều hơn.

Tin tặc đạo đức làm gì?

Các tin tặc đạo đức, trong khi thực hiện kiểm thử phần mềm thâm nhập, về cơ bản cố gắng tìm câu trả lời cho các câu hỏi sau

Những điểm yếu mà một hacker hình sự có thể đánh là gì?

Một hacker hình sự có thể nhìn thấy gì trên các hệ thống mục tiêu?

Một hacker hình sự có thể làm gì với thông tin bí mật đó?

Hơn nữa, một hacker đạo đức được yêu cầu phải giải quyết thỏa đáng các lỗ hổng và rủi ro mà anh ta thấy tồn tại trong (các) hệ thống đích. Anh ta cần phải giải thích và đề nghị các thủ tục tránh. Cuối cùng, chuẩn bị một bản báo cáo cuối cùng về tất cả các hoạt động đạo đức mà anh ta đã làm và quan sát trong khi thực hiện kiểm thử phần mềm thâm nhập.

Các loại tin tặc

Tin tặc thường được chia thành ba loại.

Hacker mũ đen

"Hacker mũ đen" là một cá nhân có phần mềm máy tính cũng như phần cứng rộng lớn và mục đích của anh ta là vi phạm hoặc bỏ qua bảo mật internet của người khác. Tin tặc mũ đen cũng phổ biến như tin tặc hoặc tin tặc bóng tối.

Hacker mũ trắng

Thuật ngữ "hacker mũ trắng" dùng để chỉ một hacker máy tính có đạo đức, là một chuyên gia bảo mật máy tính, chuyên kiểm thử phần mềm thâm nhập và trong các phương pháp thử nghiệm liên quan khác. Vai trò chính của anh là đảm bảo an ninh cho hệ thống thông tin của một tổ chức.

Hacker mũ xám

Thuật ngữ "hacker mũ xám" dùng để chỉ một hacker máy tính phá vỡ hệ thống bảo mật máy tính có tiêu chuẩn đạo đức nằm ở đâu đó giữa đạo đức thuần túy và độc hại.

Kiểm thử phần mềm - Viết báo cáo

Không nhất thiết là một người kiểm thử phần mềm thâm nhập có kinh nghiệm có thể viết một báo cáo tốt, vì viết báo cáo về kiểm thử thâm nhập là một nghệ thuật cần phải được học riêng.

Viết báo cáo là gì?

Trong kiểm thử thâm nhập, viết báo cáo là một nhiệm vụ toàn diện bao gồm phương pháp, quy trình, giải thích phù hợp về nội dung và thiết kế báo cáo, ví dụ chi tiết về báo cáo thử nghiệm và kinh nghiệm cá nhân của người kiểm thử. 

Sau khi báo cáo được chuẩn bị, nó được chia sẻ giữa các nhân viên quản lý cấp cao và đội ngũ kỹ thuật của các tổ chức mục tiêu. Nếu có bất kỳ loại nhu cầu nào phát sinh trong tương lai, báo cáo này được sử dụng làm tài liệu tham khảo.

Báo cáo giai đoạn viết

Do công việc viết toàn diện có liên quan, viết báo cáo thâm nhập được phân loại thành các giai đoạn sau -

Lập kế hoạch báo cáo

Bộ sưu tập thông tin

Viết bản thảo đầu tiên

Đánh giá và Hoàn thiện

Lập kế hoạch báo cáo

Kiểm thử phần mềm

Lập kế hoạch báo cáo bắt đầu với các mục tiêu, giúp người đọc hiểu được những điểm chính của thử nghiệm thâm nhập. Phần này mô tả lý do tại sao thử nghiệm được tiến hành, lợi ích của thử nghiệm bút, v.v. Thứ hai, lập kế hoạch báo cáo cũng bao gồm thời gian thực hiện thử nghiệm.

Các yếu tố chính của viết báo cáo là

Mục tiêu - Nó mô tả mục đích và lợi ích chung của thử nghiệm bút.

Thời gian - Bao gồm thời gian là rất quan trọng, vì nó đưa ra trạng thái chính xác của hệ thống. Giả sử, nếu có bất cứ điều gì sai xảy ra sau đó, báo cáo này sẽ cứu người kiểm thử phần mềm, vì báo cáo sẽ minh họa các rủi ro và lỗ hổng trong phạm vi kiểm thử thâm nhập trong khoảng thời gian cụ thể.

Đối tượng mục tiêu - Báo cáo thử nghiệm bút cũng cần bao gồm đối tượng mục tiêu, chẳng hạn như người quản lý bảo mật thông tin, người quản lý công nghệ thông tin, giám đốc an ninh thông tin và nhóm kỹ thuật.

Phân loại báo cáo - Vì, nó được bảo mật cao, mang địa chỉ IP của máy chủ, thông tin ứng dụng, lỗ hổng, mối đe dọa, nó cần được phân loại đúng. Tuy nhiên, việc phân loại này cần được thực hiện trên cơ sở tổ chức mục tiêu có chính sách phân loại thông tin.

Phân phối báo cáo - Số lượng bản sao và phân phối báo cáo nên được đề cập trong phạm vi công việc. Cũng cần phải đề cập rằng các bản cứng có thể được kiểm soát bằng cách in một số lượng hạn chế các bản sao được đính kèm với số của nó và tên của người nhận.

Bộ sưu tập thông tin

Do các quy trình phức tạp và kéo dài, người kiểm thử bút được yêu cầu đề cập đến mọi bước để đảm bảo rằng anh ta thu thập tất cả thông tin trong tất cả các giai đoạn thử nghiệm. Cùng với các phương pháp, ông cũng cần đề cập về các hệ thống và công cụ, kết quả quét, đánh giá lỗ hổng, chi tiết về phát hiện của mình, v.v.

Viết bản thảo đầu tiên

Một khi, người kiểm thử đã sẵn sàng với tất cả các công cụ và thông tin, bây giờ anh ta cần bắt đầu bản thảo đầu tiên. Chủ yếu, anh ta cần phải viết bản thảo đầu tiên trong các chi tiết - đề cập đến mọi thứ tức là tất cả các hoạt động, quy trình và kinh nghiệm.

Đánh giá và Hoàn thiện

Sau khi bản báo cáo được soạn thảo, bản báo cáo phải được xem xét trước bởi chính bản thân và sau đó bởi người cao niên hoặc đồng nghiệp có thể đã hỗ trợ anh ta. Trong khi xem xét, người đánh giá dự kiến ​​sẽ kiểm thử phần mềm từng chi tiết của báo cáo và tìm ra bất kỳ sai sót nào cần được sửa chữa.

Nội dung của Báo cáo thử nghiệm thâm nhập

Sau đây là nội dung tiêu biểu của báo cáo thử nghiệm thâm nhập

Tóm tắt

Phạm vi công việc

Mục tiêu dự án

Giả định

Mốc thời gian

Tóm tắt kết quả

Tóm tắt đề xuất

Phương pháp luận

Lập kế hoạch

Khai thác

Báo cáo

Kết quả chi tiết

Thông tin hệ thống chi tiết

Thông tin máy chủ Windows

Tài liệu tham khảo

ruột thừa

Các loại thử nghiệm tự động và một số hiểu lầm về tự động hóa thử nghiệm

Trong phần thứ hai của loạt bài hướng dẫn tự động hóa thử nghiệm này , tôi sẽ mô tả ngắn gọn các loại thử nghiệm tự động và sau đó quan trọng nhất là tôi sẽ xóa một số hiểu lầm về tự động hóa thử nghiệm.

Các loại thử nghiệm tự động :

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

Có ba loại kiểm thử phần mềm tự động chính.

# 1 . Kiểm thử đơn vị tự động

Kiểm thử phần mềm đơn vị tự động được viết để kiểm thử ở cấp mã. Lỗi được xác định trong các chức năng, phương pháp và thói quen được viết bởi các nhà phát triển.

Một số công ty yêu cầu các nhà phát triển tự kiểm thử đơn vị và một số thuê tài nguyên tự động kiểm thử chuyên ngành. Các tài nguyên này có quyền truy cập vào mã nguồn và họ viết các bài kiểm thử đơn vị để phá mã sản xuất. 

Do sự hiện diện của các thử nghiệm đơn vị, bất cứ khi nào mã biên dịch, tất cả các thử nghiệm đơn vị đều chạy và cho chúng tôi biết kết quả là liệu tất cả các chức năng có hoạt động hay không. Nếu bất kỳ kiểm thử đơn vị nào thất bại, điều đó có nghĩa là hiện tại đã có lỗi trong mã sản xuất.

Một số công cụ phổ biến nhất hiện có trên thị trường là NUnit và JUnit . Microsoft cũng cung cấp khuôn khổ riêng để thử nghiệm đơn vị gọi là MSTest . Đi qua các trang web của các công cụ này và họ sẽ cung cấp các ví dụ và hướng dẫn về cách viết bài kiểm thử  đơn vị.

# 2. Dịch vụ web tự động / Kiểm thử API

Giao diện lập trình ứng dụng (API) giúp phần mềm có thể nói chuyện với các ứng dụng phần mềm khác. Cũng giống như bất kỳ phần mềm nào khác, API cần phải được kiểm thử . Trong loại thử nghiệm này, GUI thường không liên quan.

Những gì chúng tôi kiểm thử ở đây thường là các vấn đề về chức năng, tuân thủ và bảo mật. Trong các ứng dụng web, chúng tôi có thể kiểm thử Yêu cầu và Phản hồi của ứng dụng của mình xem chúng có an toàn và được mã hóa hay không.

Đây là một trong những ví dụ mà chúng tôi có thể sử dụng Kiểm thử API. Công cụ phổ biến nhất để thử nghiệm API là SOAPUI có cả phiên bản miễn phí và trả phí. Có những công cụ khác, mà bạn có thể sử dụng theo nhu cầu của bạn.

# 3. Kiểm thử GUI tự động.

Loại thử nghiệm tự động này là hình thức tự động hóa khó khăn nhất vì nó liên quan đến thử nghiệm giao diện Người dùng của ứng dụng.

Thật khó khăn vì GUI rất có thể thay đổi. Nhưng loại thử nghiệm này cũng gần nhất với những gì người dùng sẽ làm với ứng dụng của chúng tôi. 

Vì người dùng sẽ sử dụng chuột và bàn phím, các kiểm thử GUI tự động cũng bắt chước hành vi tương tự bằng cách sử dụng chuột và bàn phím để nhấp hoặc ghi vào các đối tượng có trên giao diện người dùng. 

Do đó, chúng ta có thể tìm thấy các lỗi sớm và nó có thể được sử dụng trong nhiều tình huống như kiểm thử hồi quy hoặc điền vào các biểu mẫu mất quá nhiều thời gian.

Các công cụ kiểm thử GUI phổ biến nhất là QTP (Hiện được gọi là UFT) , Selenium , Test Complete và Microsoft Coded UI (là một phần của phiên bản cao cấp và cao cấp của Visual Studio).

Một số quan niệm sai lầm về kiểm thử tự động

Trong những năm qua, tôi đã nghe một số quan niệm sai lầm về tự động hóa thử nghiệm. Tôi nghĩ rằng tôi cũng nên xóa chúng trong bài viết này.

Quan niệm sai lầm # 1 . Tự động hóa là ở đây để thay thế người kiểm thử phần mềm thủ công.

Tự động hóa thử nghiệm là để giúp người thử nghiệm thực hiện thử nghiệm nhanh hơn và theo cách đáng tin cậy hơn. Nó không bao giờ có thể thay thế con người.

Hãy nghĩ về tự động hóa thử nghiệm như một chiếc xe hơi. Nếu bạn đi bộ, bạn sẽ mất khoảng 20 phút để đến nhà. Nhưng nếu bạn sử dụng xe hơi, bạn sẽ đạt được trong hai phút. 

Người điều khiển chiếc xe vẫn là bạn, một con người, nhưng .. chiếc xe giúp con người đạt được mục tiêu của mình nhanh hơn. Ngoài ra, phần lớn năng lượng của bạn được tiết kiệm, vì bạn đã không đi bộ. Vì vậy, bạn có thể sử dụng năng lượng này để thực hiện những điều quan trọng hơn.

Tương tự với thử nghiệm tự động hóa. Bạn sử dụng nó để nhanh chóng kiểm thử hầu hết các bài kiểm thử lặp đi lặp lại, dài và nhàm chán của bạn và tiết kiệm thời gian và năng lượng của bạn để tập trung và kiểm thử chức năng mới và quan trọng.

Như James Bach đã nói một câu trích dẫn tuyệt vời:

Công cụ không kiểm thử . Chỉ có người kiểm thử . Các công cụ chỉ thực hiện các hành động mà người Viking giúp kiểm thử . Cúc

Công cụ có thể nhấp vào đối tượng. Nhưng nơi để nhấp sẽ luôn được nói bởi một người kiểm thử thủ công. Tôi nghĩ rằng bạn có được quan điểm của tôi bây giờ.

Quan niệm sai lầm # 2 . Mọi thứ dưới ánh mặt trời đều có thể được tự động

Nếu bạn cố gắng tự động hóa 100% các trường hợp thử nghiệm của mình, có thể bạn sẽ có thể làm như vậy, nhưng nếu điều đó bạn có thể làm, thì điểm đầu tiên của chúng tôi trở thành sai. Bởi vì nếu mọi thứ đều tự động, người kiểm thử thủ công sẽ làm gì?

Bối rối? Đúng?

Trên thực tế, vấn đề là, bạn không thể tự động hóa 100% các trường hợp thử nghiệm của mình. Bởi vì chúng tôi, với tư cách là người kiểm thử, tin rằng không có ứng dụng nào có thể được kiểm thử 100%. Sẽ luôn có một số kịch bản mà chúng ta sẽ bỏ lỡ. Sẽ luôn có những lỗi chỉ xuất hiện khi ứng dụng của bạn được khách hàng sử dụng.

Vậy nếu ứng dụng không thể được kiểm kiểm thử phần mềm 100%, làm thế nào bạn có thể hứa tự động hóa 100%?

Ngoài ra, có một cơ hội rất nhỏ rằng bạn sẽ có thể tự động hóa tất cả các trường hợp thử nghiệm hiện tại của bạn. Luôn có những kịch bản khó tự động hóa và dễ thực hiện thủ công hơn.

Ví dụ: Một người dùng sẽ nhập dữ liệu, người dùng thứ hai sẽ phê duyệt dữ liệu, người dùng thứ ba sẽ xem dữ liệu và người dùng thứ tư bị cấm xem dữ liệu. Những kịch bản này có thể được tự động hóa, nhưng chúng sẽ tốn rất nhiều thời gian và công sức. Vì vậy, nó sẽ dễ dàng hơn nếu bạn chỉ làm điều đó bằng tay.

Hãy nhớ rằng, chúng tôi sử dụng ô tô để đi khoảng cách, nhưng có thể có tín hiệu dài trên đường, sẽ có mức tiêu thụ nhiên liệu, sẽ có vấn đề về chỗ đậu xe, phí đỗ xe và đau đầu hơn rất nhiều. Trong một số kịch bản, chúng tôi chỉ cần đi bộ và đạt đến đích của chúng tôi :) .

Vì vậy, bạn không nên cố gắng tự động hóa mọi thứ. Chỉ tự động hóa các kịch bản quan trọng và mất nhiều thời gian để thực hiện thủ công.

Quan niệm sai lầm # 3 . Tự động hóa chỉ liên quan đến ghi âm và phát lại.

Xin đừng sống trong một thế giới giả tưởng. Sự tưởng tượng này thực sự được tạo ra bởi các quảng cáo sai lệch từ các nhà cung cấp công cụ tự động hóa khác nhau. Họ nói rằng bạn chỉ cần ghi lại và phát lại các bước của bạn và các trường hợp thử nghiệm của bạn sẽ được tự động. Chà, đó là một lời nói dối lớn!

Tự động hóa là tất cả mọi thứ, nhưng ghi âm và phát lại. Các kỹ sư tự động hóa thuần túy thường không sử dụng tính năng ghi và phát lại. Ghi và phát lại thường được sử dụng để có ý tưởng về cách công cụ tạo tập lệnh cho các bước của chúng tôi.

Khi biết được kịch bản chúng tôi luôn sử dụng kịch bản để tạo các bài kiểm thử phần mềm tự động. Hãy nhớ rằng, bạn phải biết lập trình nếu bạn muốn làm tự động hóa thử nghiệm . Mặt khác, đừng nản lòng nếu bạn không biết lập trình. Bởi vì giống như bất kỳ nhiệm vụ nào khác, lập trình cũng có thể được học bằng thực tiễn và sự cống hiến.

Tôi đã biết những người, những người thậm chí không đến từ nền tảng khoa học máy tính, nhưng họ học lập trình và bây giờ họ là những kỹ sư tự động hóa tuyệt vời. Tại Microsoft, họ thuê những người thử nghiệm có thể làm lập trình. Chúng được gọi là SDET (Kỹ sư phát triển phần mềm để kiểm thử). Dòng đầu tiên của bản mô tả công việc nói rằng SD SDET viết rất nhiều mã.