Quy trình làm việc toàn diện, tích hợp CI/CD, đạo đức và bảo mật: Sử dụng AI một cách có trách nhiệm

Lợi nhuận:

• Khả năng thiết kế vai trò của trí tuệ nhân tạo và các điểm phê duyệt của con người trong quy trình QA từ đầu đến cuối từ ý tưởng đến phát hành trong bối cảnh CI/CD
• Trong CI/CD, không cho phép AI tự động “vượt qua” bài kiểm tra mà áp dụng các giới hạn để bảo vệ dữ liệu và khóa bí mật
• Khả năng thực hiện kiểm tra bảo mật trong thẩm quyền và cho mục đích phòng thủ, đồng thời áp dụng các nguyên tắc tiết lộ có trách nhiệm và minh bạch về mặt đạo đức.

Trong mười đơn vị trước, chúng tôi đã sử dụng AI trong các nhiệm vụ riêng lẻ: tạo kịch bản, mã tự động hóa, báo cáo lỗi, phân tích mức độ phù hợp, kiểm tra đột biến. Đơn vị cuối cùng này kết hợp tất cả chúng thành một quy trình làm việc có trách nhiệm. QA hiện đại không phải là công việc chỉ dừng lại ở bàn làm việc của một người; Đó là một quá trình tồn tại trong CI/CD (Tích hợp liên tục / Phân phối liên tục - đường dẫn trong đó mã được kết hợp liên tục, tự động kiểm tra và chuẩn bị để xuất bản thường xuyên và an toàn). AI có thể chạm vào mọi giai đoạn của quá trình này. Nhưng khi sức mạnh của AI ngày càng tăng thì tầm quan trọng của việc sử dụng nó một cách có trách nhiệm cũng tăng lên: quyền riêng tư, thẩm quyền trong kiểm tra bảo mật, đạo đức và quan trọng nhất là giữ cho con người đưa ra quyết định về chất lượng. Trong phần này, bạn sẽ tìm hiểu về dòng chảy và ranh giới từ đầu đến cuối.

Luồng QA được hỗ trợ bởi AI từ đầu đến cuối

Vai trò của AI trong hành trình của tính năng từ ý tưởng đến phát hành:

1. Phân tích yêu cầu. AI đánh dấu sự mơ hồ trong yêu cầu và thiếu tiêu chí chấp nhận ("quy tắc này không cho biết mật khẩu tối thiểu có bao nhiêu ký tự").

2. Thiết kế thử nghiệm. Kịch bản và bản thảo trường hợp (đơn vị 2), trường hợp biên (đơn vị 3) nằm trong số các tiêu chí chấp nhận.

3. Tự động hóa. bản nháp mã kiểm tra Đơn vị (6), API (5) và UI (4); mỗi cái được xác nhận bằng đột biến ( 10 ).

4. Tích hợp CI/CD. Các thử nghiệm sẽ tự động chạy với mỗi lần hợp nhất mã. AI phác thảo cấu hình đường dẫn (YAML), tóm tắt nhật ký các lần kiểm tra không thành công, gợi ý nguyên nhân cốt lõi có thể xảy ra.

5. Quyết định trả tự do. Kết quả phân tích rủi ro (8) và hồi quy (9) được thu thập - nhưng chuyên gia quyết định liệu nó có thể thành công hay không.

6. Giám sát và phản hồi sản xuất. Lỗi trong cuộc sống sẽ trở thành thử nghiệm trong tương lai; AI đề xuất trường hợp hồi quy từ lỗi sản xuất.

Mẹo: Thiết lập AI dưới dạng một lớp trong CI/CD để “tăng tốc các bản nháp do con người đánh giá” thay vì “viết bài kiểm tra và đưa ra quyết định”. Không có thử nghiệm được tạo tự động nào được đưa vào quy trình mà không có con người xem xét và phê duyệt chúng.

AI trong CI/CD: nơi có, nơi không

Sân khấu

AI phù hợp

con người là cần thiết

Dự thảo mã kiểm tra

Có

Sửa đổi + đột biến

Dự thảo YAML quy trình

Có

Xác thực + kiểm tra khóa bí mật

Tóm tắt nhật ký thất bại

Có

Xác nhận nguyên nhân gốc rễ

Chẩn đoán xét nghiệm dễ vỡ

Có

Quyết định giải pháp lâu dài

"Có thể có một phiên bản không?"

không

Đánh giá chuyên môn và trách nhiệm

Tự động "vượt qua" bài kiểm tra

không bao giờ

—

Thận trọng: Đừng bao giờ giao cho AI nhiệm vụ như "sửa nó để vượt qua bài kiểm tra thất bại" trong CI/CD. Điều này làm mất đi mục đích của việc kiểm tra và tự động che đậy các lỗi. AI có thể giải thích lỗi, đề xuất sửa lỗi; nhưng “tô màu xanh thử” phải là quyết định có ý thức, lý trí của con người.

Quyền riêng tư, dữ liệu và bảo mật: ranh giới bất biến

Quyền riêng tư. Trong môi trường thử nghiệm, dữ liệu khách hàng thực tế, bản sao cơ sở dữ liệu sản xuất, khóa API và thông tin hệ thống nội bộ đều rất nhạy cảm. Đừng đưa những thứ này cho các công cụ AI công cộng. Dữ liệu cá nhân phải tuân theo KVKK và các quy định tương tự; Nhật ký mặt nạ và ảnh chụp màn hình. Sử dụng dữ liệu thử nghiệm tổng hợp (hư cấu) bất cứ khi nào có thể.

Kiểm tra bảo mật - phòng thủ và ủy quyền. Các bài kiểm tra bảo mật đã học trong mô-đun này (kiểm tra ủy quyền/IDOR, giới hạn tải lên tệp, xác thực đầu vào) chỉ để kiểm tra sản phẩm của chính bạn trong phạm vi ủy quyền bằng văn bản và xác định. Việc sử dụng AI để truy cập vào hệ thống của người khác mà không được phép, vũ khí hóa các lỗ hổng thực sự hoặc thực hiện thử nghiệm ngoài phạm vi đều là phi đạo đức và bất hợp pháp. Khi bạn tìm thấy lỗ hổng bảo mật, hãy tuân thủ nguyên tắc tiết lộ có trách nhiệm — giữ bí mật lỗ hổng đó và báo cáo cho bên liên quan để có thể khắc phục.

Đạo đức và sự minh bạch. Không trình bày các bài kiểm tra do AI tạo ra như tác phẩm của riêng bạn; Nói rằng bạn đang sử dụng AI trong nhóm là sự minh bạch. Bạn phải chịu trách nhiệm về sự thiếu chính xác của kết quả đầu ra do AI tạo ra - “AI đã viết nó” không phải là một cái cớ.

Dấu nhắc yếu / Dấu nhắc mạnh

Yếu: "Thiết lập quy trình thử nghiệm cho CI."

Strong: "Dự thảo quy trình làm việc CI YAML cho các hành động GitHub: chạy thử nghiệm đơn vị + API trên mỗi PR, tạo báo cáo đưa tin, chạy thử nghiệm đột biến (Stryker) hàng tuần. Không nhúng bí mật vào mã; chỉ sử dụng tham chiếu bí mật. Hợp nhất khối nếu kiểm tra có màu đỏ. Đây là BẢN NHÁP; tôi sẽ xem xét và chỉnh sửa các bước xác thực và quản lý khóa bí mật. KHÔNG THÊM bước 'sửa chữa' hoặc 'di chuyển' kiểm tra tự động."

Lời nhắc mạnh mẽ; Nó áp đặt các giới hạn về tính bảo mật, đánh giá của con người và "không kiểm tra tự động".

Bốn mẫu có thể sao chép

1) Kế hoạch kiểm thử toàn diện:

Vai trò của bạn: lãnh đạo QA cấp cao. Soạn thảo kế hoạch thử nghiệm toàn diện từ ý tưởng đến phát hành cho tính năng sau: [tính năng + tiêu chí chấp nhận]. Các giai đoạn: phân tích yêu cầu (sự không chắc chắn), thiết kế thử nghiệm, các lớp tự động hóa (đơn vị/API/UI), tích hợp CI/CD, tiêu chí quyết định phát hành, theo dõi sản xuất. Chỉ định vai trò của các điểm phê duyệt AI và CON NGƯỜI ở từng giai đoạn riêng biệt.

2) Phác thảo đường ống CI/CD:

Bản phác thảo CI YAML cho [GitHub Actions/GitLab CI/Azure Pipelines]: - Unit + API test + phạm vi trong PR- Ngăn chặn hợp nhất trong thử nghiệm màu đỏ- Chỉ các giá trị bí mật với bí mật; nhúng vào mãĐây là bản nháp; Tôi sẽ xem lại các bước quản lý và phê duyệt chính. Thêm bước kiểm tra tự động sửa/vượt qua.

3) Phân tích nhật ký kiểm tra không thành công:

Trong bản in CI đó, các bài kiểm tra có màu đỏ. Kiểm tra nhật ký; nhóm các lỗi, phân biệt nguyên nhân gốc rễ có thể xảy ra và MÀ có thể là lỗi thực sự và có thể là vấn đề môi trường/kiểm thử dễ bị tổn thương. Nếu có dữ liệu cá nhân, hãy che giấu nó. Quyết định và sửa chữa sẽ là của tôi. Nhật ký: [dán]

4) Kiểm tra trước bảo mật/quyền riêng tư:

Trước khi dữ liệu/nhật ký thử nghiệm này được gửi đến công cụ AI, hãy kiểm tra xem: nó có chứa dữ liệu cá nhân, khóa API, địa chỉ hệ thống nội bộ, dữ liệu sản xuất không? Liệt kê những khu vực nào, nếu có, cần được che/loại bỏ. Đang xử lý như cũ. Nội dung: [dán]

ba trường hợp nhỏ

Trường hợp 1 - Tốc độ của dòng chảy từ đầu đến cuối. Một nhóm đã giải quyết tính năng “gia hạn đăng ký” mới bằng quy trình từ đầu đến cuối được hỗ trợ bởi AI: những điểm không chắc chắn về yêu cầu được gắn cờ trước, các bài kiểm tra ba lớp được soạn thảo và xác thực đột biến, gắn với CI. Tính năng này đã giảm chu kỳ thử nghiệm vốn mất 5 ngày trong quy trình truyền thống xuống còn 2 ngày; nhưng sự chấp thuận của con người vẫn được duy trì ở mọi giai đoạn và sự không chắc chắn về yêu cầu (điều gì sẽ xảy ra nếu quá trình làm mới không thành công) đã bị đóng trước khi hoạt động.

Trường hợp 2 - Trở về từ rò rỉ chìa khóa. Một nhà phát triển đã nhờ AI tạo CI YAML và AI đã nhúng khóa API trông giống như thật vào YAML làm ví dụ. Bước “kiểm tra trước bảo mật/quyền riêng tư” đã nắm bắt được điều này; khóa được chuyển đổi thành tham chiếu bí mật. Nếu không có bước kiểm tra, khóa sẽ bị rò rỉ vào phần kiểm soát phiên bản (lịch sử git).

Trường hợp 3 - Giới hạn thẩm quyền. Một thành viên trong nhóm muốn áp dụng bài kiểm tra IDOR mà anh ấy đã học được vào hệ thống trực tiếp của đối tác kinh doanh vì "Tôi rất tò mò". Trưởng nhóm QA đã dừng: việc thực hiện kiểm tra bảo mật trên hệ thống khác mà không có sự cho phép bằng văn bản và phạm vi xác định là bất hợp pháp. Việc thử nghiệm chỉ được thực hiện trong môi trường thử nghiệm sản phẩm của chính họ, có thẩm quyền; Bên chịu trách nhiệm mở đã được thông báo cho nhóm liên quan.

Những lỗi thường gặp

• Làm cho AI đưa ra quyết định phát hành. Đặt câu hỏi "Nó có thể được phát hành không?" tới AI và đặt câu trả lời thay cho chữ ký.
• "Vượt qua" bài kiểm tra tự động. Trong CI, yêu cầu AI tô màu xanh lá cây cho bài kiểm tra; che đậy lỗi lầm.
• Cung cấp dữ liệu/chìa khóa bí mật của xe. Chia sẻ dữ liệu sản xuất, dữ liệu cá nhân hoặc khóa API mà không có sự giám sát.
• Kiểm tra bảo mật trái phép. Kẻ tấn công đang thử nghiệm trên một hệ thống khác mà không có phạm vi và sự cho phép.
• Đưa thử nghiệm vào quy trình mà không cần xem xét. Tự động chạy bản phác thảo AI mà không cần sự chấp thuận của con người.
• Đổ lỗi cho AI. Bảo vệ kết quả đầu ra không chính xác bằng cách nói "AI đã viết nó".

Tóm lại

QA từ đầu đến cuối là một quy trình mở rộng từ yêu cầu đến theo dõi sản xuất và tồn tại trong CI/CD; Ở mọi giai đoạn, AI tạo bản nháp, tóm tắt nhật ký và đề xuất nguyên nhân gốc rễ. Nhưng ranh giới là không thể thay đổi: con người đưa ra quyết định thử nghiệm và phê duyệt công bố; AI không bao giờ được trao quyền tự động “vượt qua” bài kiểm tra; dữ liệu bí mật và chìa khóa không được đưa vào xe; Kiểm tra bảo mật chỉ được thực hiện trên sản phẩm của chính bạn, trong phạm vi ủy quyền bằng văn bản và phạm vi được xác định, nhằm mục đích phòng thủ và các phát hiện được báo cáo với sự tiết lộ có trách nhiệm. Hãy minh bạch khi bạn sử dụng AI; Bạn chịu trách nhiệm về tính chính xác của đầu ra. AI tăng tốc; Bạn đảm bảo về chất lượng và đạo đức.

Nhiệm vụ ứng dụng

Soạn thảo kế hoạch từ ý tưởng đến phát hành bằng mẫu “kế hoạch thử nghiệm toàn diện” cho một tính năng trong dự án của riêng bạn; Đánh dấu vai trò của AI và các điểm phê duyệt của con người một cách riêng biệt ở từng giai đoạn. Sau đó, tạo YAML với “bản phác thảo quy trình CI/CD” và áp dụng “kiểm tra trước bảo mật/quyền riêng tư” cho YAML này để kiểm tra dữ liệu khóa/bí mật được nhúng. Cuối cùng, hãy liệt kê tất cả các điểm “quyết định của con người” trong kế hoạch của bạn và giải thích bằng một câu tại sao những quyết định này không thể được giao cho AI.

danh sách kiểm tra

• [ ] Tôi cho rằng các quyết định phát hành và thử nghiệm là do con người phê duyệt; Tôi không giao nó cho AI.
• [ ] Trong CI/CD, tôi không cấp cho AI quyền tự động "vượt qua/sửa" bài kiểm tra.
• [ ] Tôi đã kiểm tra và che giấu dữ liệu bí mật, dữ liệu cá nhân và chìa khóa trước khi gửi chúng lên xe.
• [ ] Tôi chỉ xem xét việc thử nghiệm bảo mật trên sản phẩm của chính mình, trong phạm vi và ủy quyền bằng văn bản.
• [ ] Tôi đã giải quyết các lỗ hổng được phát hiện bằng nguyên tắc tiết lộ có trách nhiệm.
• [ ] Tôi đã tuyên bố rõ ràng rằng tôi đã sử dụng AI và tự chịu trách nhiệm về tính chính xác của kết quả đầu ra.

Thi học phần

1. 'Vượt sai' được xác định chính xác nhất trong bối cảnh QA như thế nào?

• A) Mặc dù bài kiểm tra chuyển sang màu xanh nhưng thực tế nó không xác nhận bất kỳ hành vi nào; ✔ Không chuyển sang màu đỏ ngay cả khi mã bị hỏng
• B) Bài kiểm tra chạy rất chậm và hết thời gian.
• C) Kiểm tra phát hiện lỗi thực sự và chuyển sang màu đỏ
• D) Thử nghiệm chỉ chạy trong môi trường sản xuất

Giải thích: Đạt giả là khi bài kiểm tra cho biết 'đạt' nhưng thực tế không xác nhận điều gì có ý nghĩa; Test xanh nhưng dù phần mềm có lỗi cũng không bắt được. Đây là rủi ro số một của AI trong QA vì AI có xu hướng tạo ra các bài kiểm tra trông gọn gàng nhưng lại trống rỗng.

2. Đâu là vị trí chính xác nhất của trí tuệ nhân tạo trong quá trình thử nghiệm và đảm bảo chất lượng?

• A) Trí tuệ nhân tạo có thể quyết định liệu phiên bản có thể được phát hành mà không cần sự chấp thuận của con người hay không
• B) Trí tuệ nhân tạo là trợ lý tạo ra các bản thảo, ý tưởng; Quyết định và trách nhiệm 'đã sẵn sàng để xuất bản chưa' thuộc về chuyên gia ✔
• C) Trí tuệ nhân tạo chỉ viết văn bản và không thể xử lý mã kiểm tra
• D) Trí tuệ nhân tạo luôn viết bài test chính xác hơn con người nên việc review là không cần thiết

Mô tả: Trí tuệ nhân tạo là trợ lý thử nghiệm, tạo bản phác thảo và nhân rộng ý tưởng; tạo ra các kịch bản thử nghiệm, mã tự động hóa và bản nháp báo cáo. Tuy nhiên, trách nhiệm và phê duyệt cuối cùng đối với các quyết định về chất lượng như “phần mềm này đã sẵn sàng để xuất bản chưa” hay “kiểm tra này đã vượt qua chưa” thuộc về chuyên gia có thẩm quyền.

3. Dựa trên thực tế là lỗi hầu hết xảy ra ở các giá trị ngưỡng, kỹ thuật thiết kế bài kiểm tra nào là để kiểm tra riêng 17, 18 và 19 cho giới hạn 18 tuổi?

• A) Kiểm tra chuyển trạng thái
• B) Bảng quyết định
• C) Phân tích giá trị biên ✔
• D) Thử nghiệm thăm dò

Giải thích: Phân tích giá trị biên dựa trên quan sát rằng lỗi xảy ra thường xuyên nhất ở các ranh giới và kiểm tra các giá trị ngưỡng (ngay dưới, ngay trên và ngay trên giới hạn) một cách riêng biệt. Đó là một kỹ thuật mạnh mẽ bổ sung cho các lớp tương đương.

4. Nên ưu tiên phương pháp nào trong việc lựa chọn thành phần để giảm tính dễ vỡ trong mã tự động kiểm tra giao diện người dùng được tạo bằng trí tuệ nhân tạo?

• A) Sử dụng đường dẫn XPath dài nhất có thể
• B) Chọn phần tử theo vị trí pixel của nó trên màn hình
• C) Sử dụng bộ chọn dựa trên tên lớp CSS
• D) Sử dụng các thuộc tính ổn định (data-testid) được thêm vào để thử nghiệm ✔

Giải thích: Đường dẫn XPath dài và tên lớp CSS phụ thuộc rất nhiều vào cấu trúc và thiết kế trang; Nó bị hỏng khi thay đổi giao diện nhỏ nhất. Các thuộc tính ổn định được thêm riêng cho thử nghiệm (ví dụ: data-testid) không bị ảnh hưởng bởi những thay đổi về thiết kế và làm cho thử nghiệm trở nên mạnh mẽ.

5. Tại sao việc kiểm tra API chỉ kiểm tra mã trạng thái HTTP (ví dụ: 200) là không đủ?

• A) Bởi vì dữ liệu nội dung có mã trạng thái chính xác có thể bị hỏng và chỉ kiểm tra trạng thái sẽ không phát hiện được điều này (tin cậy giả) ✔
• B) Bởi vì mã trạng thái không đáng tin cậy chút nào trong các thử nghiệm API
• C) Bởi vì việc kiểm tra mã trạng thái làm chậm quá trình kiểm tra rất nhiều
• D) Bởi vì mã trạng thái không bao giờ được trả về trong các thử nghiệm API

Giải thích: Trong khi máy chủ trả về mã trạng thái chính xác, nó có thể trả về dữ liệu bị hỏng trong nội dung (sai loại, thiếu trường, giá trị được tính toán không chính xác). Bài kiểm tra chỉ nhìn vào tình huống không thể nhìn thấy điều này và đưa ra sự tự tin sai lầm. Vì vậy, việc xác thực lược đồ/hợp đồng và quy tắc kinh doanh cũng cần được thêm vào.

6. Tại sao việc yêu cầu AI ‘tính toán thủ công giá trị mong đợi theo quy tắc chấp nhận, không tham chiếu đầu ra hiện tại của hàm’ khi in các bài kiểm tra đơn vị?

• A) Bởi vì tính toán thủ công chạy thử nghiệm nhanh hơn
• B) Bởi vì nếu không thì quá trình kiểm tra sẽ chấp nhận hành vi hiện tại (có thể có lỗi) của mã là 'chính xác' và xác nhận lỗi ✔
• C) Bởi vì trí tuệ nhân tạo không thể tính toán được số thập phân
• D) Bởi vì các quy tắc chấp nhận không bao giờ được sử dụng trong các bài kiểm tra

Giải thích: Nếu AI lấy được giá trị mong đợi từ đầu ra của hàm được kiểm tra, nó sẽ khiến bài kiểm tra “vượt qua” ngay cả khi hàm bị lỗi; Nghĩa là, bất kể mã nào tạo ra, bài kiểm tra đều được tính là đúng. Việc tính toán giá trị mong đợi một cách độc lập với quy tắc chấp nhận sẽ đảm bảo rằng thử nghiệm là người gác cổng cho quy tắc chứ không phải là bản sao của mã.

7. Đặc điểm nào sau đây là đặc điểm nổi bật nhất của một báo cáo lỗi tốt?

• A) Càng dài và mang tính kỹ thuật càng tốt
• B) Được viết bởi trí tuệ nhân tạo
• C) Chứa các bước tái tạo xác định mà nhà phát triển có thể thực hiện độc lập và tạo ra lỗi ✔
• D) Đây chỉ là một ảnh chụp màn hình

Giải thích: Giá trị thực sự của báo cáo lỗi là nhà phát triển có thể tạo lại lỗi mà không cần sự trợ giúp của bạn. Các bước tái tạo xác định, có thể theo dõi từ đầu đảm bảo điều này; Nếu thiếu các bước này, báo cáo thường đóng lại vì 'không thể tạo được'.

8. Cách diễn đạt chính xác nhất cho mối liên hệ giữa mức độ nghiêm trọng và mức độ ưu tiên trong lỗi viết sai tên công ty trên trang chủ?

• A) Cường độ và mức độ ưu tiên phải luôn có cùng giá trị
• B) Cả mức độ nghiêm trọng và mức độ ưu tiên của lỗi này chắc chắn là thấp
• C) Mức độ nghiêm trọng và mức độ ưu tiên là cùng một khái niệm, một nhãn là đủ
• D) Cường độ kỹ thuật có thể thấp nhưng ưu tiên kinh doanh (danh tiếng) có thể cao; Cả hai được đánh giá khác nhau ✔

Giải thích: Mức độ nghiêm trọng là tác động kỹ thuật của lỗi (lỗi đánh máy thấp về mặt kỹ thuật), mức độ ưu tiên là mức độ khẩn cấp cần sửa (cao vì đây là yếu tố danh tiếng mà mọi khách truy cập đều nhìn thấy). Cả hai không phải lúc nào cũng đi cùng một hướng; Ví dụ này là tình huống có mức độ ưu tiên cao và mức độ nghiêm trọng thấp.

9. Cách giải thích chính xác nhất về bộ thử nghiệm có độ bao phủ 90% dòng là gì?

• A) Nó cho thấy rằng các dòng được thực thi nhưng không chứng minh rằng chúng hoạt động chính xác; ✔ độ che phủ cao có thể tạo ra sự tự tin sai lầm
• B) Chứng minh một cách thuyết phục rằng 90% phần mềm không có lỗi
• C) Đây là thước đo dứt khoát về chất lượng bài kiểm tra xuất sắc.
• D) Cho biết rằng không cần phải viết bất kỳ bài kiểm tra bổ sung nào nữa

Giải thích: Phạm vi bao phủ hàng cho biết chỉ các hàng được thực thi; Nó không chứng minh rằng nó tạo ra kết quả chính xác. Ngay cả với các thử nghiệm không chắc chắn, vẫn có thể đạt được mức độ bao phủ 90%. Phạm vi là một bản đồ 'chưa bao giờ được tìm ở đâu', không phải là sự đảm bảo 'mọi thứ đã được kiểm tra'; khả năng bảo vệ thực tế được đo bằng thử nghiệm đột biến.

10. Trong thử nghiệm dựa trên rủi ro, rủi ro của một tính năng được tính toán như thế nào để định hướng nỗ lực thử nghiệm hạn chế?

• A) Chỉ theo số dòng mã
• B) Bằng cách nhân xác suất thất bại và hậu quả sẽ xảy ra khi nó bị hỏng ✔
• C) Chỉ theo thứ tự phát triển tính năng
• D) Chỉ ưu tiên tính năng dễ viết bài kiểm tra nhất

Giải thích: Trong thử nghiệm dựa trên rủi ro, rủi ro được đánh giá là xác suất = xác suất (khả năng xảy ra sự cố) × tác động (thiệt hại nếu bị hỏng). Các miền có xác suất cao và tác động cao (thanh toán, xác thực) xứng đáng được thử nghiệm cường độ cao nhất, trong khi các miền thấp×thấp nhận được thử nghiệm nhẹ.

11. Rủi ro chính của việc thêm lần thử lại vào một bài kiểm tra đôi khi đạt và đôi khi thất bại (dễ gãy/không ổn định) mặc dù mã không thay đổi là gì?

• A) Rút ngắn thời gian chạy thử nghiệm
• B) Giảm tỷ lệ bao phủ
• C) Che đậy lỗi đồng thời thực sự hoặc nguyên nhân cốt lõi và ngăn chặn triệu chứng ✔
• D) Thay đổi tên bài kiểm tra

Giải thích: Thử lại là một công cụ chẩn đoán, không phải là một phương pháp điều trị. Sự thiếu quyết đoán thường xuất phát từ tình trạng chủng tộc thực tế hoặc chứng nghiện; Việc thực hiện kiểm tra 'vượt qua' bằng cách thử lại sẽ che giấu lỗi thực sự này và có thể gây ra sự cố nghiêm trọng trong quá trình thực hiện. Nguyên nhân gốc rễ phải được tìm thấy đầu tiên.

12. Thử nghiệm đột biến, phương pháp trung thực nhất để đo lường xem bộ thử nghiệm có thực sự bảo vệ hay không, hoạt động như thế nào?

• A) Bằng cách đo tốc độ chạy của các bài kiểm tra
• B) Bằng cách đếm số dòng mã được viết
• C) Bằng cách chạy thử nghiệm theo thứ tự khác nhau
• D) Bằng cách cố tình tạo ra các dấu ngắt nhỏ trong mã và đo lường xem các bài kiểm tra có bắt được chúng không ✔

Mô tả: Kiểm tra đột biến tạo ra các biến dạng nhỏ có chủ ý (đột biến) trong mã nguồn; Một bộ thử nghiệm tốt sẽ phát hiện được những biến dạng này và chuyển sang màu đỏ. Các đột biến không bị bắt (sống sót) chỉ ra rằng các thử nghiệm không duy trì hành vi đó. Điểm đột biến là thước đo chất lượng trung thực hơn nhiều so với mức độ bao phủ phần trăm.

13. Giới hạn chính cần tuân thủ khi thực hiện kiểm tra bảo mật (ví dụ: kiểm tra ủy quyền/IDOR) là gì?

• A) Việc này chỉ nên được thực hiện trên sản phẩm của chính họ, trong phạm vi cho phép bằng văn bản và phạm vi xác định, nhằm mục đích phòng thủ ✔
• B) Nó có thể được áp dụng tự do cho bất kỳ hệ thống quan tâm nào
• C) Nó có thể được dùng thử trên hệ thống trực tiếp của đối tác kinh doanh mà không được phép
• D) Mọi lỗ hổng được tìm thấy phải được công bố công khai ngay lập tức.

Mô tả: Các bài kiểm tra bảo mật đã học trong mô-đun này chỉ dành cho việc kiểm tra sản phẩm của chính bạn cho mục đích phòng thủ, trong phạm vi được ủy quyền bằng văn bản và phạm vi được xác định. Truy cập vào hệ thống của người khác mà không được phép hoặc thực hiện kiểm tra ngoài phạm vi là trái đạo đức và bất hợp pháp; Bất kỳ lỗ hổng nào được tìm thấy đều được báo cáo thông qua việc tiết lộ có trách nhiệm.

14. Không bao giờ được trao quyền nào cho AI trong quy trình CI/CD?

• A) Tóm tắt nhật ký kiểm tra thất bại
• B) Quyền tự động 'vượt qua' bài kiểm tra không đạt (màu đỏ) hoặc sơn màu xanh lá cây ✔
• C) Đề xuất dự thảo mã kiểm tra
• D) Soạn thảo tệp YAML theo đường ống

Mô tả: AI có thể tạo phác thảo mã kiểm tra, quy trình YAML và tóm tắt nhật ký trong CI/CD; tuy nhiên, không bao giờ được cung cấp khả năng tự động 'vượt qua/sửa chữa' một bài kiểm tra thất bại. Điều này làm mất đi mục đích của việc kiểm tra và tự động che đậy các lỗi. Sơn màu xanh lá cây thử nghiệm phải là quyết định có ý thức và hợp lý của một người.