ಲಾಭಗಳು:
- ಸ್ಥಿತಿ ಕೋಡ್, ಸ್ಕೀಮಾ/ಒಪ್ಪಂದ, ವ್ಯವಹಾರ ನಿಯಮ ಮತ್ತು ಋಣಾತ್ಮಕ/ಅಧಿಕಾರ ಲೇಯರ್ಗಳಲ್ಲಿ ಕೃತಕ ಬುದ್ಧಿಮತ್ತೆ ಬೆಂಬಲದೊಂದಿಗೆ API ಪರೀಕ್ಷೆಯನ್ನು ಆಳವಾಗಿ ನಡೆಸುವ ಸಾಮರ್ಥ್ಯ
- ಮಾದರಿ ಪ್ರತಿಕ್ರಿಯೆಯಿಂದ JSON ಸ್ಕೀಮಾವನ್ನು ರಚಿಸುವ ಸಾಮರ್ಥ್ಯ ಮತ್ತು ಟೈಪ್ ಮತ್ತು ಕಡ್ಡಾಯ ದೃಢೀಕರಣದೊಂದಿಗೆ ಸ್ಥಿತಿ ಕೋಡ್ ಅನ್ನು ಮಾತ್ರ ನೋಡುವ ಹುಸಿ-ವಿಶ್ವಾಸವನ್ನು ತಪ್ಪಿಸಿ
- ಸಿಂಥೆಟಿಕ್ ಡೇಟಾದೊಂದಿಗೆ ದೃಢೀಕರಣ ಮತ್ತು IDOR ನಂತಹ ಭದ್ರತಾ ಸನ್ನಿವೇಶಗಳನ್ನು ಪರೀಕ್ಷಿಸುವ ಸಾಮರ್ಥ್ಯ ಮತ್ತು ದೃಢೀಕರಣದೊಳಗೆ ರಕ್ಷಣಾತ್ಮಕ ಉದ್ದೇಶಗಳಿಗಾಗಿ ಮಾತ್ರ
ಹೆಚ್ಚಿನ ಆಧುನಿಕ ಸಾಫ್ಟ್ವೇರ್ API ಮೂಲಕ ಹಿನ್ನೆಲೆಯಲ್ಲಿ ಪರಸ್ಪರ ಮಾತನಾಡುತ್ತದೆ (ಅಪ್ಲಿಕೇಶನ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಇಂಟರ್ಫೇಸ್ - ನಿರ್ದಿಷ್ಟ ಒಪ್ಪಂದದ ಪ್ರಕಾರ ಎರಡು ಸಾಫ್ಟ್ವೇರ್ ತುಣುಕುಗಳು ಮಾತನಾಡುವ ಇಂಟರ್ಫೇಸ್). ಮೊಬೈಲ್ ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಟ್ಗೆ ಐಟಂಗಳನ್ನು ಸೇರಿಸಿದಾಗ, ಅದು ನಿಜವಾಗಿಯೂ ಸರ್ವರ್ನಲ್ಲಿರುವ API ಗೆ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುತ್ತದೆ. ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಲೆಕ್ಕಿಸದೆಯೇ ಈ ಸಂಭಾಷಣೆಯು ಸರಿಯಾಗಿದೆ, ಸುರಕ್ಷಿತವಾಗಿದೆ ಮತ್ತು ಸ್ಥಿರವಾಗಿದೆಯೇ ಎಂದು API ಪರೀಕ್ಷೆಯು ಪರಿಶೀಲಿಸುತ್ತದೆ; ಇದು UI ಪರೀಕ್ಷೆಗಿಂತ ವೇಗವಾಗಿ, ಹೆಚ್ಚು ಸ್ಥಿರವಾಗಿದೆ ಮತ್ತು ಆಳವಾಗಿದೆ. API ಪರೀಕ್ಷೆಯಲ್ಲಿ ಕೃತಕ ಬುದ್ಧಿಮತ್ತೆ (AI) ಅತ್ಯಂತ ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆ: ಇದು API ವ್ಯಾಖ್ಯಾನದಿಂದ ಪರೀಕ್ಷೆಗಳನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ, ಪ್ರತಿಕ್ರಿಯೆ ಸ್ಕೀಮಾವನ್ನು ಹೊರತೆಗೆಯುತ್ತದೆ (ಡೇಟಾದ ರಚನೆಯನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುವ ಒಪ್ಪಂದ), ಅಂಚಿನ ಪ್ರಕರಣಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ. ಆದರೆ ಮತ್ತೊಮ್ಮೆ ಕೇಂದ್ರ ಎಚ್ಚರಿಕೆಯು ಅನ್ವಯಿಸುತ್ತದೆ: AI ನಿಮ್ಮ API ಯ ನೈಜ ವ್ಯವಹಾರ ನಿಯಮಗಳನ್ನು ತಿಳಿದಿರುವುದಿಲ್ಲ; "200 ಹಿಂತಿರುಗಿದೆ" ಎಂದು ಮಾತ್ರ ದೃಢೀಕರಿಸುವ ಬಾಹ್ಯ ಪರೀಕ್ಷೆಗಳನ್ನು ಉತ್ಪಾದಿಸಲು ಒಲವು ತೋರುತ್ತದೆ. ಪರೀಕ್ಷೆಯು ನಿಜವಾದ ಒಪ್ಪಂದ ಮತ್ತು ವ್ಯವಹಾರ ತರ್ಕವನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ನಿಮ್ಮ ಕೆಲಸ.
ಈ ಘಟಕದಲ್ಲಿ, ಪೋಸ್ಟ್ಮ್ಯಾನ್, REST ಅಶ್ಯೂರ್ಡ್ ಮತ್ತು ಸ್ಕೀಮಾ ಮೌಲ್ಯೀಕರಣದಂತಹ ವಿಧಾನಗಳೊಂದಿಗೆ AI- ಬೆಂಬಲಿತ, ಆಳವಾದ API ಪರೀಕ್ಷೆಗಳನ್ನು ಹೇಗೆ ಹೊಂದಿಸುವುದು ಎಂಬುದನ್ನು ನೀವು ಕಲಿಯುವಿರಿ.
API ಪರೀಕ್ಷೆಯ ಪದರಗಳು
ಹಲವಾರು ಆಳಗಳಲ್ಲಿ API ಪರೀಕ್ಷೆಯನ್ನು ಪರಿಗಣಿಸಿ, AI ಪ್ರತಿ ಪದರದಲ್ಲಿ ವಿಭಿನ್ನವಾಗಿ ಸಹಾಯ ಮಾಡುತ್ತದೆ:
1. ಸ್ಥಿತಿ ಕೋಡ್ ಮತ್ತು ಮೂಲ ಪ್ರತಿಕ್ರಿಯೆ. ವಿನಂತಿಯು ನಿರೀಕ್ಷಿತ HTTP ಸ್ಥಿತಿ ಕೋಡ್ ಅನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತದೆಯೇ (ಯಶಸ್ಸಿಗಾಗಿ 200/201, ದೋಷಕ್ಕಾಗಿ 400/401/404)? ಇದು ಅತ್ಯಂತ ಬಾಹ್ಯ ಪದರವಾಗಿದೆ; AI ಸುಲಭವಾಗಿ ಉತ್ಪಾದಿಸುತ್ತದೆ ಆದರೆ ಕೇವಲ ಸುಳ್ಳು ನಂಬಿಕೆಯನ್ನು ನೀಡುತ್ತದೆ.
2. ಸ್ಕೀಮಾ/ಒಪ್ಪಂದದ ಊರ್ಜಿತಗೊಳಿಸುವಿಕೆ. ಪ್ರತಿಕ್ರಿಯೆಯ ರಚನೆಯು ಒಪ್ಪಂದಕ್ಕೆ ಸರಿಹೊಂದುತ್ತದೆಯೇ - ನಿರೀಕ್ಷಿತ ಕ್ಷೇತ್ರಗಳು ಇವೆಯೇ, ಅವುಗಳ ಪ್ರಕಾರಗಳು ಸರಿಯಾಗಿವೆಯೇ, ಅಗತ್ಯವಿರುವ ಕ್ಷೇತ್ರಗಳು ಕಾಣೆಯಾಗಿದೆಯೇ? AI JSON ಸ್ಕೀಮಾವನ್ನು ರಚಿಸಬಹುದು - JSON ಡಾಕ್ಯುಮೆಂಟ್ನ ರಚನೆಯನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುವ ಮಾನದಂಡ - ಮಾದರಿ ಪ್ರತಿಕ್ರಿಯೆಯಿಂದ ಮತ್ತು ಪರೀಕ್ಷೆಗಳು ಆ ಸ್ಕೀಮಾದ ವಿರುದ್ಧ ಮೌಲ್ಯೀಕರಿಸಬಹುದು. ಕ್ಷೇತ್ರ-ಆಧಾರಿತ ಪ್ರತಿಪಾದನೆಯನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಬರೆಯುವುದಕ್ಕಿಂತ ಇದು ಹೆಚ್ಚು ದೃಢವಾಗಿದೆ.
3. ವ್ಯಾಪಾರ ನಿಯಮ ಊರ್ಜಿತಗೊಳಿಸುವಿಕೆ. ನಿಜವಾದ ಮೌಲ್ಯವು ಇಲ್ಲಿದೆ: "1000 TL ಆದೇಶಕ್ಕಾಗಿ, ರಿಯಾಯಿತಿ ಕ್ಷೇತ್ರವು 100 ಆಗಿರಬೇಕು", "ರದ್ದಾದ ಆದೇಶವನ್ನು ಮತ್ತೆ ರದ್ದುಗೊಳಿಸಲಾಗುವುದಿಲ್ಲ". ನೀವು ನಿಯಮಗಳನ್ನು ನೀಡಿದರೆ ಮಾತ್ರ AI ಇವುಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ; ಕೊಡದಿದ್ದರೆ ಜಿಗಿಯುತ್ತದೆ.
4. ಋಣಾತ್ಮಕ ಮತ್ತು ಭದ್ರತೆ. ಅಮಾನ್ಯ ಟೋಕನ್ಗಾಗಿ 401, ಬೇರೊಬ್ಬರ ಡೇಟಾವನ್ನು ಪ್ರವೇಶಿಸಲು 403, ಕೆಟ್ಟ ದೇಹಕ್ಕಾಗಿ 400 ಅನ್ನು ತೆರವುಗೊಳಿಸಿ. ದೃಢೀಕರಣ ಪರೀಕ್ಷೆಗಳು (ಬಳಕೆದಾರರು ತಮ್ಮ ಸ್ವಂತ ಡೇಟಾವನ್ನು ಮಾತ್ರ ಪ್ರವೇಶಿಸಬಹುದು ಎಂದು ಪರಿಶೀಲಿಸುವುದು) API ಭದ್ರತೆಯ ಹೃದಯ ಮತ್ತು ರಕ್ಷಣಾತ್ಮಕ ಉದ್ದೇಶಗಳಿಗಾಗಿ ಮಾಡಲಾಗುತ್ತದೆ.
ಸಲಹೆ: "ಕೇವಲ ಸ್ಥಿತಿ ಕೋಡ್ ಮಾತ್ರವಲ್ಲ, ಪ್ರತಿಕ್ರಿಯೆ ಸ್ಕೀಮಾ ಮತ್ತು ಆ ವ್ಯವಹಾರ ನಿಯಮಗಳನ್ನು ಮೌಲ್ಯೀಕರಿಸಲು" AI ಗೆ ಹೇಳದೆ ಪರೀಕ್ಷೆಗೆ ವಿನಂತಿಸಬೇಡಿ. ಇಲ್ಲದಿದ್ದರೆ, "200 ಹಿಂತಿರುಗಿಸಲಾಗಿದೆ, ಉತ್ತೀರ್ಣವಾಗಿದೆ" ಎಂದು ಹೇಳುವ ಪರೀಕ್ಷೆಗಳನ್ನು ನೀವು ಬಿಡುತ್ತೀರಿ ಆದರೆ ದೋಷಪೂರಿತ ಡೇಟಾವನ್ನು ಹಿಂದಿರುಗಿಸುವ API ಅನ್ನು ಗಮನಿಸುವುದಿಲ್ಲ.
ದುರ್ಬಲ ಪ್ರಾಂಪ್ಟ್ / ಬಲವಾದ ಪ್ರಾಂಪ್ಟ್
ದುರ್ಬಲ: "ಈ API ಗಾಗಿ ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯಿರಿ."
ಪ್ರಬಲ: "POST/ಆರ್ಡರ್ ಎಂಡ್ಪಾಯಿಂಟ್ಗಾಗಿ REST ಅಶ್ಯೂರ್ಡ್ (ಜಾವಾ) ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯಿರಿ. ಒಪ್ಪಂದ: ಉತ್ಪನ್ನ ಐಡಿ ಮತ್ತು ಪ್ರಮಾಣವು ದೇಹದಲ್ಲಿ ಕಡ್ಡಾಯವಾಗಿದೆ; 201 ಮತ್ತು {orderId, ಒಟ್ಟು, ರಿಯಾಯಿತಿ, ಸ್ಥಿತಿ} ಅನ್ನು ಯಶಸ್ಸಿನ ಮೇಲೆ ಹಿಂತಿರುಗಿಸಲಾಗುತ್ತದೆ. ವ್ಯಾಪಾರ ನಿಯಮಗಳು: 10% ರಿಯಾಯಿತಿ 1000 TL ಗಿಂತ ; 400 ಕ್ಕಿಂತ ಹೆಚ್ಚು ಮೌಲ್ಯ ; ಟೋಕನ್ 403 ಮತ್ತೊಂದು ಬಳಕೆದಾರರ ಆದೇಶವನ್ನು ನೋಡಿದಾಗ: (1) ಸ್ಥಿತಿ ಕೋಡ್, (2) ಪ್ರತಿಕ್ರಿಯೆ JSON ಸ್ಕೀಮಾ ಊರ್ಜಿತಗೊಳಿಸುವಿಕೆ, (4) 200/201 ಅನ್ನು ಮಾತ್ರ ಪರಿಶೀಲಿಸಬೇಡಿ.
ಪ್ರಬಲ ಪ್ರಾಂಪ್ಟ್ ಒಪ್ಪಂದ, ವ್ಯಾಪಾರ ನಿಯಮಗಳು, ಭದ್ರತಾ ಸನ್ನಿವೇಶಗಳು ಮತ್ತು ಸ್ಕೀಮಾ ಮೌಲ್ಯೀಕರಣದ ನಿರೀಕ್ಷೆಯನ್ನು ನೀಡುತ್ತದೆ.
ಒಪ್ಪಂದ ಪರೀಕ್ಷೆ: ತಂಡಗಳ ನಡುವಿನ ವಿಘಟನೆಯನ್ನು ತಡೆಯುವುದು
ಮೈಕ್ರೊ ಸರ್ವೀಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್ಗಳಲ್ಲಿ (ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಪರಸ್ಪರ ಸ್ವತಂತ್ರವಾಗಿರುವ ಮತ್ತು API ನೊಂದಿಗೆ ಮಾತನಾಡುವ ಸಣ್ಣ ಸೇವೆಗಳಾಗಿ ವಿಂಗಡಿಸಲಾದ ರಚನೆ), ಸೇವೆಯ ಪ್ರತಿಕ್ರಿಯೆ ಸ್ವರೂಪವನ್ನು ಬದಲಾಯಿಸುವುದರಿಂದ ಅದಕ್ಕೆ ಸಂಪರ್ಕಗೊಂಡಿರುವ ಇತರ ಸೇವೆಗಳನ್ನು ಮೌನವಾಗಿ ಅಡ್ಡಿಪಡಿಸುತ್ತದೆ. ಗುತ್ತಿಗೆ ಪರೀಕ್ಷೆ - ಪೂರೈಕೆದಾರ ಸೇವೆ ಮತ್ತು ಗ್ರಾಹಕ ಸೇವೆಯ ನಡುವಿನ API ಒಪ್ಪಂದವು ಎರಡೂ ಬದಿಗಳಲ್ಲಿ ಮುರಿದುಹೋಗಿಲ್ಲ ಎಂದು ಪರಿಶೀಲಿಸುವ ಪರೀಕ್ಷೆ - ಅಂತಹ ವಿರಾಮಗಳನ್ನು ಮೊದಲೇ ಹಿಡಿಯುತ್ತದೆ. ಕಲ್ಪನೆ ಹೀಗಿದೆ: ಗ್ರಾಹಕನು ಉತ್ಪಾದಕರಿಂದ ತಾನು ನಿರೀಕ್ಷಿಸುವ ಪ್ರತಿಕ್ರಿಯೆಯ ರೂಪವನ್ನು "ಒಪ್ಪಂದ" ಎಂದು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತಾನೆ; ಪ್ರತಿ ಬದಲಾವಣೆಯೊಂದಿಗೆ, ತಯಾರಕರು ಈ ಒಪ್ಪಂದವನ್ನು ಇನ್ನೂ ಅನುಸರಿಸುತ್ತಾರೆ ಎಂದು ಪರೀಕ್ಷಿಸುತ್ತಾರೆ. ಆದ್ದರಿಂದ ಕ್ಷೇತ್ರದ ಹೆಸರು ಅಥವಾ ಪ್ರಕಾರವು ಬದಲಾದಾಗ, ಗ್ರಾಹಕರು ಪೈಪ್ಲೈನ್ ಕ್ರ್ಯಾಶ್ ಆಗುವ ಮೊದಲು ಅದನ್ನು ಸೂಚಿಸುತ್ತಾರೆ.
ಈ ಸಂದರ್ಭದಲ್ಲಿ AI ಎರಡು ಕಾರ್ಯಗಳನ್ನು ವೇಗಗೊಳಿಸುತ್ತದೆ: ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ API ಪ್ರತಿಕ್ರಿಯೆಯಿಂದ ಗ್ರಾಹಕರ ನಿರೀಕ್ಷೆಯನ್ನು ಪ್ರತಿಬಿಂಬಿಸುವ ಒಪ್ಪಂದವನ್ನು ರಚಿಸುವುದು ಮತ್ತು ಯಾವ ಒಪ್ಪಂದದ ಷರತ್ತು ಬದಲಾವಣೆಯು ಮುರಿಯಬಹುದು ಎಂಬುದನ್ನು ಮೊದಲೇ ಗುರುತಿಸುವುದು. ಆದರೆ ಒಪ್ಪಂದವು ಸ್ವತಃ ವ್ಯವಹಾರ ನಿರ್ಧಾರವಾಗಿದೆ: ಯಾವ ಪ್ರದೇಶಗಳು ನಿಜವಾಗಿಯೂ ನಿರ್ಣಾಯಕವಾಗಿವೆ ಎಂಬುದನ್ನು ತಜ್ಞರು ನಿರ್ಧರಿಸುತ್ತಾರೆ, ಯಾವ ಬದಲಾವಣೆಗಳು ಹಿಂದುಳಿದ ಹೊಂದಾಣಿಕೆಯನ್ನು ಮುರಿಯುತ್ತವೆ - ಹಳೆಯ ಗ್ರಾಹಕರು ಕೆಲಸ ಮಾಡುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತಾರೆ. AI ಒಪ್ಪಂದವನ್ನು ಬರೆಯುತ್ತದೆ; ನೀವು ಅದನ್ನು ಅನುಮೋದಿಸುವವರು.
ಸಲಹೆ: ಕ್ಷೇತ್ರವನ್ನು ಅಳಿಸುವುದು ಅಥವಾ API ನಲ್ಲಿ ಕ್ಷೇತ್ರದ ಪ್ರಕಾರವನ್ನು ಬದಲಾಯಿಸುವುದು ಯಾವಾಗಲೂ ಬ್ರೇಕಿಂಗ್ ಬದಲಾವಣೆಯಾಗಿದೆ. ಹೊಸ ಕ್ಷೇತ್ರಗಳನ್ನು ಸೇರಿಸುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಸುರಕ್ಷಿತವಾಗಿದೆ. AI ಬದಲಾವಣೆಯನ್ನು "ಬ್ರೇಕಿಂಗ್ ಅಥವಾ ಸೇಫ್" ಎಂದು ವರ್ಗೀಕರಿಸುವುದರಿಂದ ತ್ವರಿತ ಬಿಡುಗಡೆಯ ಭದ್ರತಾ ಪರಿಶೀಲನೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ.
ಪೋಸ್ಟ್ಮ್ಯಾನ್ ಅಥವಾ ಕೋಡ್ ಆಧಾರಿತ?
ಮಾನದಂಡ
ಪೋಸ್ಟ್ಮ್ಯಾನ್/ನ್ಯೂಮನ್
REST ಖಚಿತ / ಕೋಡ್ (ಜಾವಾ, C#, JS)
ಕಲಿಕೆ
ಸುಲಭ, ದೃಶ್ಯ
ಕೋಡ್ ಜ್ಞಾನದ ಅಗತ್ಯವಿದೆ
ಆವೃತ್ತಿ ನಿಯಂತ್ರಣ
ಸಂಗ್ರಹ JSON
ನೇರವಾಗಿ ಮೂಲ ಕೋಡ್ನಲ್ಲಿ
ಸಂಕೀರ್ಣ ತರ್ಕ
ಲಿಮಿಟೆಡ್ (JS ಸ್ಕ್ರಿಪ್ಟ್ಗಳು)
ಪೂರ್ಣ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಶಕ್ತಿ
CI/CD ಏಕೀಕರಣ
ನ್ಯೂಮನ್ ಜೊತೆ
ನಿರ್ಮಾಣದ ಮೇಲೆ ನೇರವಾಗಿ ಅವಲಂಬಿತವಾಗಿದೆ
ಸ್ಕೀಮಾ ಮೌಲ್ಯೀಕರಣ
ಪರೀಕ್ಷಾ ಸ್ಕ್ರಿಪ್ಟ್ಗಳೊಂದಿಗೆ
ಗ್ರಂಥಾಲಯದೊಂದಿಗೆ ಶಕ್ತಿಯುತವಾಗಿದೆ
ತಂಡದ ಪ್ರಮಾಣ
ಸಣ್ಣ/ಮಧ್ಯಮ
ದೊಡ್ಡ, ಪ್ರಬುದ್ಧ
ಎಐ ಎರಡಕ್ಕೂ ಕೋಡ್ ಅನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ; ನಿಮಗೆ ಯಾವುದು ಬೇಕು ಎಂದು ಸ್ಪಷ್ಟಪಡಿಸಿ.
ನಾಲ್ಕು ನಕಲಿಸಬಹುದಾದ ಟೆಂಪ್ಲೇಟ್ಗಳು
1) ಗುತ್ತಿಗೆ ಆಧಾರಿತ API ಪರೀಕ್ಷೆ:
ನಿಮ್ಮ ಪಾತ್ರ: ಹಿರಿಯ API ಪರೀಕ್ಷಾ ಇಂಜಿನಿಯರ್. [ಉಪಕರಣ/ಭಾಷೆ] ಜೊತೆಗೆ ಕೆಳಗಿನ ಅಂತಿಮ ಬಿಂದುವಿಗೆ ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯಿರಿ: [ವಿಧಾನ + ಮಾರ್ಗ]. ಒಪ್ಪಂದ: [ಅಗತ್ಯವಿರುವ ಕ್ಷೇತ್ರಗಳು, ಯಶಸ್ಸಿನ ಕೋಡ್, ಪ್ರತಿಕ್ರಿಯೆ ರಚನೆ]. ವ್ಯಾಪಾರ ನಿಯಮಗಳು: [ನಿಯಮಗಳು]. ಪರೀಕ್ಷಾ ಲೇಯರ್ಗಳು: (1) ಸ್ಥಿತಿ ಕೋಡ್ (2) ಪ್ರತಿಕ್ರಿಯೆ ಸ್ಕೀಮಾ ಊರ್ಜಿತಗೊಳಿಸುವಿಕೆ(3) ಪ್ರತಿ ವ್ಯವಹಾರ ನಿಯಮಕ್ಕೆ ಸಂಬಂಧಿತ ನಿಯಮವನ್ನು ಪ್ರತಿಪಾದಿಸಿ (4) ಋಣಾತ್ಮಕ ನಿಯಮವನ್ನು ಪ್ರತಿಪಾದಿಸಿ
2) ಮಾದರಿ ಪ್ರತಿಕ್ರಿಯೆಯಿಂದ ಸ್ಕೀಮಾ ರಚನೆ:
ಕೆಳಗಿನ ಮಾದರಿ API ಪ್ರತಿಕ್ರಿಯೆಯಿಂದ JSON ಸ್ಕೀಮಾವನ್ನು ರಚಿಸಿ. ಅಗತ್ಯವಿರುವ ಕ್ಷೇತ್ರಗಳು, ಪ್ರಕಾರಗಳು, ಸ್ವರೂಪ ನಿರ್ಬಂಧಗಳನ್ನು ಸೂಚಿಸಿ (ದಿನಾಂಕ, ಇಮೇಲ್, ಸಂಖ್ಯೆ ಶ್ರೇಣಿ). ನಂತರ ಈ ಸ್ಕೀಮಾ ವಿರುದ್ಧ ಮೌಲ್ಯೀಕರಿಸುವ ಪರೀಕ್ಷಾ ಉದಾಹರಣೆಯನ್ನು ನೀಡಿ. ಮಾದರಿ ಪ್ರತಿಕ್ರಿಯೆ: [JSON ಅಂಟಿಸಿ]
3) ಋಣಾತ್ಮಕ ಮತ್ತು ಅಧಿಕೃತ ಸನ್ನಿವೇಶಗಳು:
ಎಂಡ್ ಪಾಯಿಂಟ್[ಎಂಡ್ ಪಾಯಿಂಟ್] ಗಾಗಿ ಋಣಾತ್ಮಕ ಮತ್ತು ಭದ್ರತಾ ಪರೀಕ್ಷಾ ಪ್ರಕರಣಗಳನ್ನು ರಚಿಸಿ. ಇವುಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ: ಕಾಣೆಯಾದ/ಅಗತ್ಯವಿರುವ ಕ್ಷೇತ್ರ, ತಪ್ಪಾದ ಪ್ರಕಾರ, ತುಂಬಾ ದೊಡ್ಡ ಮೌಲ್ಯ, ಅಮಾನ್ಯ/ಅವಧಿ ಮೀರಿದ ಟೋಕನ್, ಅನಧಿಕೃತ ಸಂಪನ್ಮೂಲಕ್ಕೆ ಪ್ರವೇಶ (IDOR — ID ಬದಲಾಯಿಸುವ ಮೂಲಕ ಬೇರೊಬ್ಬರ ದಾಖಲೆಗೆ ಪ್ರವೇಶ), ದರ ಮಿತಿ. ಪ್ರತಿ ಸನ್ನಿವೇಶಕ್ಕೂ ನಿರೀಕ್ಷಿತ ಸ್ಥಿತಿ ಕೋಡ್ ಮತ್ತು ದೋಷ ದೇಹವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಿ. ಗಮನಿಸಿ: ನನ್ನ ಸ್ವಂತ API ನಲ್ಲಿ ಮಾತ್ರ ಪರೀಕ್ಷಿಸಲಾಗುವುದು, ಅಧಿಕೃತವಾಗಿದೆ.
4) ಹುಸಿ ನಂಬಿಕೆ ನಿಯಂತ್ರಣ:
ಈ API ಪರೀಕ್ಷೆಯನ್ನು ಪರಿಶೀಲಿಸಿ. ಸರ್ವರ್ ಸರಿಯಾದ ಸ್ಥಿತಿ ಕೋಡ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸಿದರೆ ಈ ಪರೀಕ್ಷೆಯು ಕ್ಯಾಚ್ ಆಗುತ್ತದೆಯೇ ಆದರೆ FALSEbody/data? ಇಲ್ಲದಿದ್ದರೆ, ಸ್ಕೀಮಾ ಮತ್ತು ವ್ಯವಹಾರ ನಿಯಮದ ಮೌಲ್ಯೀಕರಣವನ್ನು ಸೇರಿಸಿ. ಪರೀಕ್ಷೆ: [ಅಂಟಿಸಿ ಪರೀಕ್ಷೆ]
ಮೂರು ಸಣ್ಣ ಪ್ರಕರಣಗಳು
ಪ್ರಕರಣ 1 - ಸ್ಕೀಮಾ ಮೌಲ್ಯೀಕರಣದ ಶಕ್ತಿ. ಒಂದು ತಂಡವು AI ಯೊಂದಿಗೆ ತಯಾರಿಸಿದ ಪರೀಕ್ಷೆಗಳಲ್ಲಿ ಸ್ಥಿತಿ ಕೋಡ್ ಅನ್ನು ಮಾತ್ರ ಪರಿಶೀಲಿಸುತ್ತಿದೆ. ಒಂದು ಆವೃತ್ತಿಯಲ್ಲಿ, API ಒಟ್ಟು ಕ್ಷೇತ್ರವನ್ನು ಪಠ್ಯವಾಗಿ ತಪ್ಪಾಗಿ ಹಿಂತಿರುಗಿಸಲು ಪ್ರಾರಂಭಿಸಿತು ("1200"); ಪರೀಕ್ಷೆಗಳು ಹಸಿರಾಗಿಯೇ ಇದ್ದವು ಏಕೆಂದರೆ ಅದು ಇನ್ನೂ 200 ಹಿಂತಿರುಗುತ್ತಿದೆ. ಮೊಬೈಲ್ ಅಪ್ಲಿಕೇಶನ್ ಕ್ರ್ಯಾಶ್ ಆಗಿದೆ. "ಮಾದರಿ ಪ್ರತಿಕ್ರಿಯೆಯಿಂದ ಸ್ಕೀಮಾ ಉತ್ಪಾದನೆ" ಟೆಂಪ್ಲೇಟ್ನೊಂದಿಗೆ ಪ್ರಕಾರದ ಮೌಲ್ಯೀಕರಣವನ್ನು ಸೇರಿಸಿದ ನಂತರ, ಅದೇ ದೋಷವನ್ನು ತಕ್ಷಣವೇ ಹಿಡಿಯಲಾಯಿತು.
ಪ್ರಕರಣ 2 - ಅಧಿಕಾರ ಅಂತರ (IDOR). AI ನಿಂದ ರಚಿಸಲಾದ "ಋಣಾತ್ಮಕ ಮತ್ತು ಅಧಿಕೃತ ಸನ್ನಿವೇಶಗಳ" ನಡುವೆ ಪರಿಣಿತರು IDOR ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸಿದರು: ಅವರು ಬಳಕೆದಾರರ A ನ ಟೋಕನ್ನೊಂದಿಗೆ ಬಳಕೆದಾರ B ನ ಆರ್ಡರ್ ಐಡಿಯನ್ನು ವಿನಂತಿಸಿದರು. API 200 ಮತ್ತು B ಡೇಟಾವನ್ನು ಹಿಂತಿರುಗಿಸಿದೆ - ಇದು ಗಂಭೀರವಾದ ಅಧಿಕೃತ ದುರ್ಬಲತೆಯಾಗಿದೆ. ಈ ರಕ್ಷಣಾತ್ಮಕ ಪರೀಕ್ಷೆಯು ಲೈವ್ ಆಗುವ ಮೊದಲು ಡೇಟಾ ಸೋರಿಕೆಯನ್ನು ಮುಚ್ಚಿದೆ.
ಪ್ರಕರಣ 3 - ವ್ಯವಹಾರ ನಿಯಮ ಬೈಪಾಸ್. AI ರಿಯಾಯಿತಿ ಎಂಡ್ಪಾಯಿಂಟ್ಗಾಗಿ 8 ಪರೀಕ್ಷೆಗಳನ್ನು ರಚಿಸಿತು; ಎಲ್ಲರೂ 200 ಅನ್ನು ಪರಿಶೀಲಿಸುತ್ತಿದ್ದರು, ಯಾರೂ ರಿಯಾಯಿತಿ ಮೊತ್ತವನ್ನು ಪರಿಶೀಲಿಸುತ್ತಿಲ್ಲ. ತಜ್ಞರು ವ್ಯವಹಾರ ನಿಯಮಗಳನ್ನು ಪ್ರಾಂಪ್ಟ್ಗೆ ಸೇರಿಸಿದರು ಮತ್ತು ಅವುಗಳನ್ನು ಪುನರುತ್ಪಾದಿಸಿದರು. 1000 TL ಮಿತಿಯಲ್ಲಿ ರಿಯಾಯಿತಿಯನ್ನು ತಪ್ಪಾಗಿ ಲೆಕ್ಕಹಾಕಲಾಗಿದೆ ಎಂದು ಹೊಸ ಪರೀಕ್ಷೆಗಳು ಬಹಿರಂಗಪಡಿಸಿವೆ (ರಿಯಾಯಿತಿಯನ್ನು 999 ಗೆ ಅನ್ವಯಿಸಲಾಗಿದೆ). ಗುತ್ತಿಗೆ ನಿಯಂತ್ರಣ ಸಾಕಾಗುವುದಿಲ್ಲ; ವ್ಯಾಪಾರ ನಿಯಮಗಳ ನಿಯಂತ್ರಣ ಅತ್ಯಗತ್ಯ.
ಸಾಮಾನ್ಯ ತಪ್ಪುಗಳು
- ಕೇವಲ ಸ್ಟೇಟಸ್ ಕೋಡ್ ನೋಡುತ್ತಿದ್ದೇನೆ. "200 ಹಿಂತಿರುಗಿದೆ ಮತ್ತು ಹಾದುಹೋಗಿದೆ" ಎಂದು ಹೇಳಲು; ಭ್ರಷ್ಟ ದೇಹವನ್ನು ನೋಡುವುದಿಲ್ಲ (ಸುಳ್ಳು-ನಂಬಿಕೆ).
- ಸ್ಕೀಮಾ ಮೌಲ್ಯೀಕರಣವನ್ನು ಬೈಪಾಸ್ ಮಾಡಲಾಗುತ್ತಿದೆ. ಕ್ಷೇತ್ರದ ಪ್ರಕಾರಗಳು ಮತ್ತು ಬಾಧ್ಯತೆಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತಿಲ್ಲ; ರೀತಿಯ ಬದಲಾವಣೆಗಳು ಮೌನವಾಗಿ ಹಾದುಹೋಗುತ್ತವೆ.
- ವ್ಯಾಪಾರ ನಿಯಮಗಳನ್ನು ಒದಗಿಸದೆ ಪರೀಕ್ಷೆಗೆ ವಿನಂತಿಸಲಾಗುತ್ತಿದೆ. AI ಗೆ ನಿಯಮಗಳು ತಿಳಿದಿಲ್ಲ; ಇದು ತಾಂತ್ರಿಕ ನಿಯಂತ್ರಣವನ್ನು ಮಾತ್ರ ಉತ್ಪಾದಿಸುತ್ತದೆ.
- ಋಣಾತ್ಮಕ ಮತ್ತು ಅರ್ಹತೆಯ ಸನ್ನಿವೇಶಗಳನ್ನು ಮರೆತುಬಿಡುವುದು. ಭದ್ರತಾ ದೋಷಗಳು (IDOR, ಅನಧಿಕೃತ ಪ್ರವೇಶ) ಈ ಪರೀಕ್ಷೆಗಳಿಂದ ಮಾತ್ರ ಹಿಡಿಯಲ್ಪಡುತ್ತವೆ.
- ನೈಜ/ಉತ್ಪಾದನೆ ಟೋಕನ್ಗಳು ಮತ್ತು ಡೇಟಾವನ್ನು ಬಳಸುವುದು. ಪರೀಕ್ಷೆಗಾಗಿ ಮೀಸಲಾದ ಮಾಧ್ಯಮ ಮತ್ತು ಸಂಶ್ಲೇಷಿತ ಡೇಟಾವನ್ನು ಬಳಸಿ; ವಾಹನಕ್ಕೆ ನಿಜವಾದ ಕೀಲಿಗಳನ್ನು ಅಂಟಿಸಬೇಡಿ.
- ಅನಧಿಕೃತ ಭದ್ರತಾ ಪರೀಕ್ಷೆ. ನಿಮ್ಮ ಸ್ವಂತ API ನಲ್ಲಿ ಮತ್ತು ಅನುಮತಿಯೊಂದಿಗೆ ಮಾತ್ರ ದೃಢೀಕರಣ ಪರೀಕ್ಷೆಗಳನ್ನು ರನ್ ಮಾಡಿ.
ಸಾರಾಂಶದಲ್ಲಿ
ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಲೆಕ್ಕಿಸದೆಯೇ API ಪರೀಕ್ಷೆಯು ಸಾಫ್ಟ್ವೇರ್ ತುಣುಕುಗಳ ಭಾಷಣವನ್ನು ತ್ವರಿತವಾಗಿ ಮತ್ತು ಆಳವಾಗಿ ಪರಿಶೀಲಿಸುತ್ತದೆ. AI; ಮಾದರಿ ಪ್ರತಿಕ್ರಿಯೆಯಿಂದ JSON ಸ್ಕೀಮಾ ಮತ್ತು ಋಣಾತ್ಮಕ/ಸುರಕ್ಷತಾ ಸನ್ನಿವೇಶಗಳನ್ನು ರಚಿಸುವಲ್ಲಿ ಒಪ್ಪಂದದ ಪರೀಕ್ಷೆಗಳು ಬಹಳ ಪರಿಣಾಮಕಾರಿಯಾಗಿವೆ. ಆದರೆ ಸ್ಥಿತಿ ಕೋಡ್ ಅನ್ನು ಮಾತ್ರ ಪರಿಶೀಲಿಸುವ ಬಾಹ್ಯ ಪರೀಕ್ಷೆಗಳು ಹುಸಿ ವಿಶ್ವಾಸವನ್ನು ನೀಡುತ್ತವೆ. ಎಲ್ಲಾ ನಾಲ್ಕು ಲೇಯರ್ಗಳ ಅಗತ್ಯವಿದೆ: ಸ್ಥಿತಿ ಕೋಡ್, ಸ್ಕೀಮಾ ಮೌಲ್ಯೀಕರಣ, ವ್ಯವಹಾರ ನಿಯಮ, ಋಣಾತ್ಮಕ ಮತ್ತು ದೃಢೀಕರಣ. ಪ್ರಾಂಪ್ಟ್ನಲ್ಲಿ ವ್ಯಾಪಾರ ನಿಯಮಗಳು ಮತ್ತು ಒಪ್ಪಂದವನ್ನು ಹಾಕಿ; ಸಿಂಥೆಟಿಕ್ ಡೇಟಾದೊಂದಿಗೆ ಮತ್ತು ದೃಢೀಕರಣದೊಂದಿಗೆ ಮಾತ್ರ ಭದ್ರತಾ ಪರೀಕ್ಷೆಗಳನ್ನು ಮಾಡಿ.
ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯ
ನಿಮ್ಮ ಸ್ವಂತ ಪ್ರಾಜೆಕ್ಟ್ನಿಂದ API ಅಂತಿಮ ಬಿಂದುವನ್ನು ಆಯ್ಕೆಮಾಡಿ. "ಒಪ್ಪಂದ-ಆಧಾರಿತ API ಪರೀಕ್ಷೆ" ಟೆಂಪ್ಲೇಟ್ನೊಂದಿಗೆ AI ನಾಲ್ಕು-ಪದರದ ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯುವಂತೆ ಮಾಡಿ. ನಂತರ "ಮಾದರಿ ಪ್ರತಿಕ್ರಿಯೆಯಿಂದ ಸ್ಕೀಮಾ ಉತ್ಪಾದನೆ" ಯೊಂದಿಗೆ ಪ್ರಕಾರ/ಜಾರಿ ಮೌಲ್ಯೀಕರಣವನ್ನು ಸೇರಿಸಿ ಮತ್ತು "ಹುಸಿ-ವಿಶ್ವಾಸ ಪರಿಶೀಲನೆ" ಅನ್ನು ಅನ್ವಯಿಸಿ. ನಿಮ್ಮ ಸ್ವಂತ ಪರೀಕ್ಷಾ ಪರಿಸರದಲ್ಲಿ ಕನಿಷ್ಠ ಒಂದು IDOR/ಅಧಿಕೃತ ಸನ್ನಿವೇಶವನ್ನು ರನ್ ಮಾಡಿ. ನೀವು ಕಂಡುಕೊಂಡ ಯಾವುದೇ ಒಪ್ಪಂದ ಅಥವಾ ವ್ಯಾಪಾರ ನಿಯಮ ಉಲ್ಲಂಘನೆಗಳನ್ನು ವರದಿ ಮಾಡಿ; ನಿಮಗೆ ಯಾವುದನ್ನೂ ಕಂಡುಹಿಡಿಯಲಾಗದಿದ್ದರೆ, ಅದು ಹಿಡಿದಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸಲು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಅಸಮರ್ಪಕ ಪ್ರತಿಕ್ರಿಯೆಯ ವಿರುದ್ಧ ಪರೀಕ್ಷೆಯನ್ನು ಚಲಾಯಿಸಿ.
ಪರಿಶೀಲನಾಪಟ್ಟಿ
- [ ] ನಾನು ಪರೀಕ್ಷೆಯ ನಾಲ್ಕು ಲೇಯರ್ಗಳನ್ನು ಒಳಗೊಂಡಿದೆ (ಪ್ರಕರಣ, ಸ್ಕೀಮಾ, ವ್ಯವಹಾರ ನಿಯಮ, ಋಣಾತ್ಮಕ/ಅಧಿಕಾರ).
- [ ] ನಾನು ಸ್ಪಷ್ಟವಾಗಿ ಒಪ್ಪಂದ ಮತ್ತು ವ್ಯವಹಾರ ನಿಯಮಗಳನ್ನು AI ಗೆ ನೀಡಿದ್ದೇನೆ.
- [ ] ನಾನು ಪ್ರತಿಕ್ರಿಯೆ ಸ್ಕೀಮಾವನ್ನು ಮೌಲ್ಯೀಕರಿಸುವ ಪರೀಕ್ಷೆಗಳನ್ನು ಹೊಂದಿಸಿದ್ದೇನೆ (ಕ್ಷೇತ್ರ, ಪ್ರಕಾರ, ಕಡ್ಡಾಯ).
- [ ] ನಾನು ಕನಿಷ್ಟ ಒಂದು ದೃಢೀಕರಣ/IDOR ಸನ್ನಿವೇಶವನ್ನು ರಕ್ಷಣಾತ್ಮಕವಾಗಿ ಪ್ರಯತ್ನಿಸಿದೆ.
- [ ] ನಾನು ನಿಜವಾದ ಟೋಕನ್/ಡೇಟಾ ಬದಲಿಗೆ ಪರೀಕ್ಷಾ ಪರಿಸರ ಮತ್ತು ಸಿಂಥೆಟಿಕ್ ಡೇಟಾವನ್ನು ಬಳಸಿದ್ದೇನೆ.
- [ ] ನಾನು ಪ್ರತಿ ಪರೀಕ್ಷೆಯು ಭ್ರಷ್ಟ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಹಿಡಿಯುತ್ತದೆ ಎಂದು "ಹುಸಿ-ವಿಶ್ವಾಸ ಪರಿಶೀಲನೆ" ಯೊಂದಿಗೆ ಸಾಬೀತುಪಡಿಸಿದೆ.