ਲਾਭ:
- CI/CD ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਵਿਚਾਰ ਤੋਂ ਜਾਰੀ ਕਰਨ ਲਈ ਅੰਤ ਤੋਂ ਅੰਤ ਤੱਕ QA ਪ੍ਰਵਾਹ ਵਿੱਚ ਨਕਲੀ ਬੁੱਧੀ ਅਤੇ ਮਨੁੱਖੀ ਪ੍ਰਵਾਨਗੀ ਬਿੰਦੂਆਂ ਦੀ ਭੂਮਿਕਾ ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਨ ਦੀ ਸਮਰੱਥਾ
- CI/CD ਵਿੱਚ, AI ਨੂੰ ਸਵੈਚਲਿਤ ਤੌਰ 'ਤੇ ਟੈਸਟ ਪਾਸ ਕਰਨ ਲਈ ਅਧਿਕਾਰਤ ਨਹੀਂ ਕਰਨਾ, ਪਰ ਗੁਪਤ ਡੇਟਾ ਅਤੇ ਕੁੰਜੀਆਂ ਦੀ ਸੁਰੱਖਿਆ ਲਈ ਸੀਮਾਵਾਂ ਲਾਗੂ ਕਰਨਾ
- ਅਥਾਰਟੀ ਦੇ ਅੰਦਰ ਅਤੇ ਰੱਖਿਆਤਮਕ ਉਦੇਸ਼ਾਂ ਲਈ ਸੁਰੱਖਿਆ ਜਾਂਚ ਕਰਨ ਦੀ ਸਮਰੱਥਾ, ਅਤੇ ਜ਼ਿੰਮੇਵਾਰ ਖੁਲਾਸੇ ਅਤੇ ਨੈਤਿਕ ਪਾਰਦਰਸ਼ਤਾ ਦੇ ਸਿਧਾਂਤਾਂ ਨੂੰ ਅਪਣਾਉਣ ਦੀ ਸਮਰੱਥਾ।
ਪਿਛਲੀਆਂ ਦਸ ਯੂਨਿਟਾਂ ਵਿੱਚ, ਅਸੀਂ ਵਿਅਕਤੀਗਤ ਕੰਮਾਂ ਵਿੱਚ AI ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਸੀ: ਦ੍ਰਿਸ਼ ਬਣਾਉਣਾ, ਆਟੋਮੇਸ਼ਨ ਕੋਡ, ਬੱਗ ਰਿਪੋਰਟਿੰਗ, ਕਵਰੇਜ ਵਿਸ਼ਲੇਸ਼ਣ, ਮਿਊਟੇਸ਼ਨ ਟੈਸਟਿੰਗ। ਇਹ ਅੰਤਿਮ ਇਕਾਈ ਉਹਨਾਂ ਸਾਰਿਆਂ ਨੂੰ ਇੱਕ ਜ਼ਿੰਮੇਵਾਰ ਵਰਕਫਲੋ ਵਿੱਚ ਜੋੜਦੀ ਹੈ। ਆਧੁਨਿਕ QA ਕੋਈ ਨੌਕਰੀ ਨਹੀਂ ਹੈ ਜੋ ਇੱਕ ਵਿਅਕਤੀ ਦੇ ਡੈਸਕ 'ਤੇ ਖਤਮ ਹੁੰਦੀ ਹੈ; ਇਹ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਹੈ ਜੋ CI/CD ਦੇ ਅੰਦਰ ਰਹਿੰਦੀ ਹੈ (ਨਿਰੰਤਰ ਏਕੀਕਰਣ / ਨਿਰੰਤਰ ਡਿਲਿਵਰੀ — ਪਾਈਪਲਾਈਨ ਜਿੱਥੇ ਕੋਡ ਨੂੰ ਲਗਾਤਾਰ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ, ਸਵੈਚਲਿਤ ਤੌਰ 'ਤੇ ਟੈਸਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਪ੍ਰਕਾਸ਼ਨ ਲਈ ਅਕਸਰ ਅਤੇ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਤਿਆਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ)। AI ਇਸ ਪ੍ਰਕਿਰਿਆ ਦੇ ਹਰ ਪੜਾਅ ਨੂੰ ਛੂਹ ਸਕਦਾ ਹੈ। ਪਰ ਜਿਵੇਂ-ਜਿਵੇਂ AI ਦੀ ਸ਼ਕਤੀ ਵਧਦੀ ਹੈ, ਉਸੇ ਤਰ੍ਹਾਂ ਇਸਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਨਾਲ ਵਰਤੋਂ ਕਰਨ ਦੀ ਮਹੱਤਤਾ ਵੀ ਵਧਦੀ ਹੈ: ਗੋਪਨੀਯਤਾ, ਸੁਰੱਖਿਆ ਜਾਂਚ ਵਿੱਚ ਅਧਿਕਾਰ, ਨੈਤਿਕਤਾ, ਅਤੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ, ਗੁਣਵੱਤਾ ਦੇ ਫੈਸਲੇ ਨੂੰ ਮਨੁੱਖ ਤੱਕ ਰੱਖਣਾ। ਇਸ ਯੂਨਿਟ ਵਿੱਚ, ਤੁਸੀਂ ਅੰਤ ਤੋਂ ਅੰਤ ਤੱਕ ਪ੍ਰਵਾਹ ਅਤੇ ਸੀਮਾਵਾਂ ਸਿੱਖੋਗੇ।
ਐਂਡ-ਟੂ-ਐਂਡ AI-ਸੰਚਾਲਿਤ QA ਪ੍ਰਵਾਹ
ਵਿਚਾਰ ਤੋਂ ਰੀਲੀਜ਼ ਤੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਦੇ ਸਫ਼ਰ ਵਿੱਚ AI ਦੀ ਭੂਮਿਕਾ:
1. ਲੋੜਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ। AI ਲੋੜਾਂ ਅਤੇ ਗੁੰਮ ਸਵੀਕ੍ਰਿਤੀ ਮਾਪਦੰਡਾਂ ਵਿੱਚ ਅਸਪਸ਼ਟਤਾਵਾਂ ਨੂੰ ਫਲੈਗ ਕਰਦਾ ਹੈ ("ਇਹ ਨਿਯਮ ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਹੈ ਕਿ ਪਾਸਵਰਡ ਵਿੱਚ ਘੱਟੋ-ਘੱਟ ਕਿੰਨੇ ਅੱਖਰ ਹਨ")।
2. ਟੈਸਟ ਡਿਜ਼ਾਈਨ. ਦ੍ਰਿਸ਼ ਅਤੇ ਕੇਸ ਡਰਾਫਟ (ਯੂਨਿਟ 2), ਕਿਨਾਰੇ ਦੇ ਕੇਸ (ਯੂਨਿਟ 3) ਸਵੀਕ੍ਰਿਤੀ ਦੇ ਮਾਪਦੰਡਾਂ ਵਿੱਚੋਂ ਹਨ।
3. ਆਟੋਮੇਸ਼ਨ। ਯੂਨਿਟ (6), API (5) ਅਤੇ UI (4) ਟੈਸਟ ਕੋਡ ਡਰਾਫਟ; ਹਰੇਕ ਦੀ ਪੁਸ਼ਟੀ ਪਰਿਵਰਤਨ (10) ਦੁਆਰਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।
4. CI/CD ਏਕੀਕਰਣ। ਟੈਸਟ ਹਰ ਕੋਡ ਮਿਲਾਨ ਨਾਲ ਆਪਣੇ ਆਪ ਚੱਲਦੇ ਹਨ। AI ਡਰਾਫਟ ਪਾਈਪਲਾਈਨ ਕੌਂਫਿਗਰੇਸ਼ਨ (YAML), ਅਸਫਲ ਟੈਸਟਾਂ ਦੇ ਲੌਗਾਂ ਦਾ ਸਾਰ ਦਿੰਦਾ ਹੈ, ਸੰਭਾਵਿਤ ਮੂਲ ਕਾਰਨ ਦਾ ਸੁਝਾਅ ਦਿੰਦਾ ਹੈ।
5. ਜਾਰੀ ਕਰਨ ਦਾ ਫੈਸਲਾ। ਜੋਖਮ ਵਿਸ਼ਲੇਸ਼ਣ (8) ਅਤੇ ਰਿਗਰੈਸ਼ਨ (9) ਨਤੀਜੇ ਇਕੱਠੇ ਕੀਤੇ ਜਾਂਦੇ ਹਨ - ਪਰ ਮਾਹਰ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਇਹ ਸਫਲ ਹੋ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ।
6. ਉਤਪਾਦਨ ਦੀ ਨਿਗਰਾਨੀ ਅਤੇ ਫੀਡਬੈਕ। ਲਾਈਵ ਵਿੱਚ ਗਲਤੀਆਂ ਭਵਿੱਖ ਦੇ ਟੈਸਟ ਬਣ ਜਾਂਦੀਆਂ ਹਨ; AI ਇੱਕ ਨਿਰਮਾਣ ਨੁਕਸ ਤੋਂ ਰਿਗਰੈਸ਼ਨ ਕੇਸ ਦਾ ਪ੍ਰਸਤਾਵ ਕਰਦਾ ਹੈ।
ਸੁਝਾਅ: CI/CD ਵਿੱਚ AI ਨੂੰ ਇੱਕ ਪਰਤ ਵਜੋਂ ਸੈਟ ਅਪ ਕਰੋ ਜੋ "ਟੈਸਟ ਲਿਖਦਾ ਹੈ ਅਤੇ ਫੈਸਲੇ ਲੈਂਦਾ ਹੈ" ਦੀ ਬਜਾਏ "ਮਨੁੱਖੀ-ਸਮੀਖਿਆ ਕੀਤੇ ਡਰਾਫਟਾਂ ਨੂੰ ਤੇਜ਼ ਕਰਦਾ ਹੈ"। ਕੋਈ ਵੀ ਸਵੈਚਲਿਤ ਤੌਰ 'ਤੇ ਤਿਆਰ ਕੀਤੇ ਟੈਸਟਾਂ ਨੂੰ ਮਨੁੱਖੀ ਸਮੀਖਿਆ ਅਤੇ ਮਨਜ਼ੂਰੀ ਦਿੱਤੇ ਬਿਨਾਂ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਦਾਖਲ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ।
CI/CD ਵਿੱਚ AI: ਕਿੱਥੇ ਹਾਂ, ਕਿੱਥੇ ਨਹੀਂ
ਸਟੇਜ
AI ਫਿੱਟ
ਮਨੁੱਖ ਜ਼ਰੂਰੀ ਹੈ
ਟੈਸਟ ਕੋਡ ਡਰਾਫਟ
ਹਾਂ
ਸੰਸ਼ੋਧਨ + ਪਰਿਵਰਤਨ
ਪਾਈਪਲਾਈਨ YAML ਡਰਾਫਟ
ਹਾਂ
ਪ੍ਰਮਾਣਿਕਤਾ + ਗੁਪਤ ਕੁੰਜੀ ਦੀ ਜਾਂਚ
ਅਸਫਲ ਲੌਗ ਸਾਰਾਂਸ਼
ਹਾਂ
ਮੂਲ ਕਾਰਨ ਦੀ ਪੁਸ਼ਟੀ
ਨਾਜ਼ੁਕ ਟੈਸਟ ਨਿਦਾਨ
ਹਾਂ
ਸਥਾਈ ਹੱਲ ਦਾ ਫੈਸਲਾ
"ਕੀ ਕੋਈ ਸੰਸਕਰਣ ਹੋ ਸਕਦਾ ਹੈ?"
ਨਹੀਂ
ਮਾਹਰ ਨਿਰਣਾ ਅਤੇ ਜ਼ਿੰਮੇਵਾਰੀ
ਆਟੋਮੈਟਿਕਲੀ ਟੈਸਟ "ਪਾਸ" ਕਰੋ
ਕਦੇ ਨਹੀਂ
-
ਸਾਵਧਾਨ: CI/CD ਵਿੱਚ ਕਦੇ ਵੀ AI ਨੂੰ "ਫੇਲ ਹੋਣ ਵਾਲੇ ਟੈਸਟ ਪਾਸ ਕਰਨ ਲਈ ਇਸ ਨੂੰ ਠੀਕ ਕਰੋ" ਵਰਗਾ ਆਦੇਸ਼ ਨਾ ਦਿਓ। ਇਹ ਜਾਂਚ ਦੇ ਉਦੇਸ਼ ਨੂੰ ਹਰਾ ਦਿੰਦਾ ਹੈ ਅਤੇ ਆਪਣੇ ਆਪ ਗਲਤੀਆਂ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ। AI ਗਲਤੀ ਦੀ ਵਿਆਖਿਆ ਕਰ ਸਕਦਾ ਹੈ, ਸੁਧਾਰ ਦਾ ਸੁਝਾਅ ਦੇ ਸਕਦਾ ਹੈ; ਪਰ "ਟੈਸਟ ਗ੍ਰੀਨ ਪੇਂਟਿੰਗ" ਇੱਕ ਵਿਅਕਤੀ ਦਾ ਚੇਤੰਨ, ਤਰਕਪੂਰਨ ਫੈਸਲਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਗੋਪਨੀਯਤਾ, ਡੇਟਾ ਅਤੇ ਸੁਰੱਖਿਆ: ਅਟੱਲ ਸੀਮਾਵਾਂ
ਗੋਪਨੀਯਤਾ। ਟੈਸਟ ਵਾਤਾਵਰਨ ਵਿੱਚ, ਅਸਲ ਗਾਹਕ ਡੇਟਾ, ਉਤਪਾਦਨ ਡੇਟਾਬੇਸ ਕਾਪੀਆਂ, API ਕੁੰਜੀਆਂ ਅਤੇ ਅੰਦਰੂਨੀ ਸਿਸਟਮ ਜਾਣਕਾਰੀ ਸੰਵੇਦਨਸ਼ੀਲ ਹੁੰਦੀ ਹੈ। ਇਹਨਾਂ ਨੂੰ ਜਨਤਕ AI ਟੂਲਸ ਨੂੰ ਨਾ ਦਿਓ। ਨਿੱਜੀ ਡੇਟਾ KVKK ਅਤੇ ਸਮਾਨ ਨਿਯਮਾਂ ਦੇ ਅਧੀਨ ਹੈ; ਮਾਸਕ ਲੌਗ ਅਤੇ ਸਕ੍ਰੀਨਸ਼ਾਟ। ਜਿੱਥੇ ਵੀ ਸੰਭਵ ਹੋਵੇ ਸਿੰਥੈਟਿਕ (ਕਾਲਪਨਿਕ) ਟੈਸਟ ਡੇਟਾ ਦੀ ਵਰਤੋਂ ਕਰੋ।
ਸੁਰੱਖਿਆ ਜਾਂਚ — ਰੱਖਿਆਤਮਕ ਅਤੇ ਅਧਿਕਾਰਤ। ਇਸ ਮੋਡੀਊਲ ਵਿੱਚ ਸਿੱਖੇ ਗਏ ਸੁਰੱਖਿਆ ਟੈਸਟ (ਅਧਿਕਾਰ/ਆਈਡੀਓਆਰ ਟੈਸਟ, ਫਾਈਲ ਅਪਲੋਡ ਸੀਮਾਵਾਂ, ਇਨਪੁਟ ਪ੍ਰਮਾਣਿਕਤਾ) ਸਿਰਫ਼ ਲਿਖਤੀ ਅਧਿਕਾਰ ਅਤੇ ਪਰਿਭਾਸ਼ਿਤ ਦਾਇਰੇ ਵਿੱਚ ਤੁਹਾਡੇ ਆਪਣੇ ਉਤਪਾਦ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਹਨ। ਬਿਨਾਂ ਇਜਾਜ਼ਤ ਕਿਸੇ ਹੋਰ ਦੇ ਸਿਸਟਮ ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਲਈ AI ਦੀ ਵਰਤੋਂ ਕਰਨਾ, ਅਸਲ ਕਮਜ਼ੋਰੀਆਂ ਨੂੰ ਹਥਿਆਰ ਬਣਾਉਣਾ, ਜਾਂ ਦਾਇਰੇ ਤੋਂ ਬਾਹਰ ਦਾ ਟੈਸਟ ਕਰਨਾ ਅਨੈਤਿਕ ਅਤੇ ਗੈਰ-ਕਾਨੂੰਨੀ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਕੋਈ ਸੁਰੱਖਿਆ ਕਮਜ਼ੋਰੀ ਲੱਭਦੇ ਹੋ, ਤਾਂ ਜ਼ਿੰਮੇਵਾਰ ਖੁਲਾਸੇ ਦੇ ਸਿਧਾਂਤ ਦੀ ਪਾਲਣਾ ਕਰੋ — ਕਮਜ਼ੋਰੀ ਨੂੰ ਗੁਪਤ ਰੱਖਣਾ ਅਤੇ ਸੰਬੰਧਿਤ ਧਿਰ ਨੂੰ ਇਸਦੀ ਰਿਪੋਰਟ ਕਰਨਾ ਤਾਂ ਜੋ ਇਸਨੂੰ ਠੀਕ ਕੀਤਾ ਜਾ ਸਕੇ।
ਨੈਤਿਕਤਾ ਅਤੇ ਪਾਰਦਰਸ਼ਤਾ। AI ਦੁਆਰਾ ਤਿਆਰ ਕੀਤੇ ਗਏ ਟੈਸਟਾਂ ਨੂੰ ਆਪਣੇ ਖੁਦ ਦੇ ਕੰਮ ਵਜੋਂ ਪੇਸ਼ ਨਾ ਕਰੋ; ਇਹ ਦੱਸਣਾ ਕਿ ਤੁਸੀਂ ਟੀਮ ਦੇ ਅੰਦਰ AI ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ, ਪਾਰਦਰਸ਼ਤਾ ਹੈ। ਤੁਸੀਂ ਇੱਕ AI-ਨਿਰਮਿਤ ਆਉਟਪੁੱਟ ਦੀ ਅਸ਼ੁੱਧਤਾ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੋ — “AI ਨੇ ਇਸਨੂੰ ਲਿਖਿਆ” ਕੋਈ ਬਹਾਨਾ ਨਹੀਂ ਹੈ।
ਕਮਜ਼ੋਰ ਪ੍ਰੋਂਪਟ / ਮਜ਼ਬੂਤ ਪ੍ਰੋਂਪਟ
ਕਮਜ਼ੋਰ: "CI ਲਈ ਟੈਸਟ ਪਾਈਪਲਾਈਨ ਸੈੱਟ ਕਰੋ।"
ਮਜ਼ਬੂਤ: "GitHub ਐਕਸ਼ਨਾਂ ਲਈ ਇੱਕ CI ਵਰਕਫਲੋ YAML ਦਾ ਖਰੜਾ ਤਿਆਰ ਕਰੋ: ਹਰੇਕ PR 'ਤੇ ਯੂਨਿਟ + API ਟੈਸਟ ਚਲਾਓ, ਕਵਰੇਜ ਰਿਪੋਰਟ ਤਿਆਰ ਕਰੋ, ਮਿਊਟੇਸ਼ਨ ਟੈਸਟਿੰਗ (ਸਟ੍ਰਾਈਕਰ) ਹਫਤਾਵਾਰੀ ਚਲਾਓ। ਕੋਡ ਵਿੱਚ ਭੇਦ ਏਮਬੇਡ ਨਾ ਕਰੋ; ਕੇਵਲ ਭੇਦ ਸੰਦਰਭ ਦੀ ਵਰਤੋਂ ਕਰੋ। ਜੇਕਰ ਟੈਸਟ ਲਾਲ ਹਨ ਤਾਂ ਅਭੇਦ ਨੂੰ ਬਲੌਕ ਕਰੋ। ਇਹ ਇੱਕ ਡਰਾਫਟ ਅਤੇ ਸੰਪਾਦਨ ਕੁੰਜੀ ਪਗ ਹੈ। ਮੈਂ ਡ੍ਰਾਫਟ ਅਤੇ ਸੰਪਾਦਨ ਕੁੰਜੀ ਪ੍ਰਬੰਧਨ ਕਦਮ ਦੀ ਸਮੀਖਿਆ ਕਰਾਂਗਾ। ਇੱਕ ਸਵੈਚਲਿਤ ਟੈਸਟਿੰਗ 'ਫਿਕਸ' ਜਾਂ 'ਮਾਈਗਰੇਟ' ਕਦਮ ਸ਼ਾਮਲ ਕਰੋ।"
ਸ਼ਕਤੀਸ਼ਾਲੀ ਪ੍ਰੋਂਪਟ; ਇਹ ਗੁਪਤਤਾ, ਮਨੁੱਖੀ ਸਮੀਖਿਆ, ਅਤੇ "ਕੋਈ ਸਵੈਚਲਿਤ ਟੈਸਟਿੰਗ ਨਹੀਂ" 'ਤੇ ਸੀਮਾਵਾਂ ਲਾਉਂਦਾ ਹੈ।
ਚਾਰ ਕਾਪੀ ਕਰਨ ਯੋਗ ਟੈਂਪਲੇਟ
1) ਅੰਤ ਤੋਂ ਅੰਤ ਤੱਕ ਟੈਸਟਿੰਗ ਯੋਜਨਾ:
ਤੁਹਾਡੀ ਭੂਮਿਕਾ: ਸੀਨੀਅਰ QA ਨੇਤਾ। ਹੇਠਾਂ ਦਿੱਤੀ ਵਿਸ਼ੇਸ਼ਤਾ ਲਈ ਰੀਲੀਜ਼ ਕਰਨ ਲਈ ਵਿਚਾਰ ਤੋਂ ਲੈ ਕੇ ਅੰਤ ਤੋਂ ਅੰਤ ਤੱਕ ਟੈਸਟਿੰਗ ਯੋਜਨਾ ਦਾ ਖਰੜਾ ਤਿਆਰ ਕਰੋ: [ਵਿਸ਼ੇਸ਼ਤਾ + ਸਵੀਕ੍ਰਿਤੀ ਮਾਪਦੰਡ]।ਪੜਾਅ: ਲੋੜਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ (ਅਨਿਸ਼ਚਿਤਤਾਵਾਂ), ਟੈਸਟ ਡਿਜ਼ਾਈਨ, ਆਟੋਮੇਸ਼ਨ ਲੇਅਰਾਂ (ਯੂਨਿਟ/API/UI), CI/CD ਏਕੀਕਰਣ, ਰੀਲੀਜ਼ ਫੈਸਲੇ ਦੇ ਮਾਪਦੰਡ, ਉਤਪਾਦਨ ਟਰੈਕਿੰਗ। ਹਰੇਕ ਪੜਾਅ 'ਤੇ AI ਅਤੇ ਮਨੁੱਖੀ ਪ੍ਰਵਾਨਗੀ ਬਿੰਦੂਆਂ ਦੀ ਭੂਮਿਕਾ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਨਿਸ਼ਚਿਤ ਕਰੋ।
2) CI/CD ਪਾਈਪਲਾਈਨ ਰੂਪਰੇਖਾ:
[GitHub ਐਕਸ਼ਨ/GitLab CI/Azure ਪਾਈਪਲਾਈਨਜ਼] ਲਈ CI YAML ਡਰਾਫਟ:- PR ਵਿੱਚ ਯੂਨਿਟ + API ਟੈਸਟ + ਸਕੋਪ- ਲਾਲ ਟੈਸਟ ਵਿੱਚ ਅਭੇਦ ਹੋਣ ਤੋਂ ਰੋਕੋ- ਗੁਪਤ ਮੁੱਲ ਕੇਵਲ ਰਾਜ਼ਾਂ ਨਾਲ; ਕੋਡ ਵਿੱਚ ਏਮਬੇਡਿੰਗ ਇਹ ਇੱਕ ਡਰਾਫਟ ਹੈ; ਮੈਂ ਮੁੱਖ ਪ੍ਰਬੰਧਨ ਅਤੇ ਮਨਜ਼ੂਰੀ ਦੇ ਪੜਾਵਾਂ ਦੀ ਸਮੀਖਿਆ ਕਰਾਂਗਾ। ਇੱਕ ਸਵੈ-ਸ਼ੁੱਧ/ਪਾਸ ਟੈਸਟ ਪੜਾਅ ਸ਼ਾਮਲ ਕਰਨਾ।
3) ਅਸਫਲ ਟੈਸਟ ਲਾਗ ਵਿਸ਼ਲੇਸ਼ਣ:
ਉਸ CI ਪ੍ਰਿੰਟਆਊਟ ਵਿੱਚ, ਟੈਸਟ ਲਾਲ ਹੁੰਦੇ ਹਨ। ਲਾਗ ਦੀ ਜਾਂਚ ਕਰੋ; ਅਸਫਲਤਾਵਾਂ ਦਾ ਸਮੂਹ ਕਰੋ, ਸੰਭਾਵਿਤ ਮੂਲ ਕਾਰਨ ਨੂੰ ਵੱਖ ਕਰੋ ਅਤੇ ਅਸਲ ਅਸਫਲਤਾ ਕੌਣ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਜੋ ਇੱਕ ਨਾਜ਼ੁਕ ਟੈਸਟ/ਵਾਤਾਵਰਣ ਦਾ ਮੁੱਦਾ ਹੋ ਸਕਦਾ ਹੈ। ਜੇ ਕੋਈ ਨਿੱਜੀ ਡੇਟਾ ਹੈ, ਤਾਂ ਇਸ ਨੂੰ ਮਾਸਕ ਕਰੋ. ਫੈਸਲਾ ਅਤੇ ਸੁਧਾਰ ਮੇਰਾ ਹੋਵੇਗਾ। ਲੌਗ: [ਪੇਸਟ]
4) ਸੁਰੱਖਿਆ/ਗੋਪਨੀਯਤਾ ਪ੍ਰੀ-ਚੈੱਕ:
ਇਸ ਟੈਸਟ ਡੇਟਾ/ਲੌਗ ਨੂੰ AI ਟੂਲ ਨੂੰ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ, ਜਾਂਚ ਕਰੋ: ਕੀ ਇਸ ਵਿੱਚ ਨਿੱਜੀ ਡੇਟਾ, API ਕੁੰਜੀ, ਅੰਦਰੂਨੀ ਸਿਸਟਮ ਪਤਾ, ਉਤਪਾਦਨ ਡੇਟਾ ਸ਼ਾਮਲ ਹੈ? ਸੂਚੀ ਬਣਾਓ ਕਿ ਕਿਹੜੇ ਖੇਤਰਾਂ ਨੂੰ, ਜੇ ਕੋਈ ਹੈ, ਨੂੰ ਮਾਸਕ/ਹਟਾਉਣ ਦੀ ਲੋੜ ਹੈ। ਜਿਵੇਂ ਕਿ ਇਹ ਹੈ ਪ੍ਰੋਸੈਸਿੰਗ. ਸਮੱਗਰੀ: [ਪੇਸਟ]
ਤਿੰਨ ਛੋਟੇ ਕੇਸ
ਕੇਸ 1 - ਸਿਰੇ ਤੋਂ ਅੰਤ ਦੇ ਵਹਾਅ ਦੀ ਗਤੀ। ਇੱਕ ਟੀਮ ਨੇ ਇੱਕ AI-ਸੰਚਾਲਿਤ ਐਂਡ-ਟੂ-ਐਂਡ ਫਲੋ ਦੇ ਨਾਲ ਇੱਕ ਨਵੀਂ "ਗਾਹਕੀ ਨਵੀਨੀਕਰਨ" ਵਿਸ਼ੇਸ਼ਤਾ ਨਾਲ ਨਜਿੱਠਿਆ: ਲੋੜ ਅਨਿਸ਼ਚਿਤਤਾਵਾਂ ਸਾਹਮਣੇ ਫਲੈਗ ਕੀਤੀਆਂ ਗਈਆਂ, ਤਿੰਨ-ਲੇਅਰ ਟੈਸਟਾਂ ਦਾ ਖਰੜਾ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਅਤੇ ਪਰਿਵਰਤਨ-ਪ੍ਰਮਾਣਿਤ, CI ਨਾਲ ਬੰਨ੍ਹਿਆ ਗਿਆ। ਵਿਸ਼ੇਸ਼ਤਾ ਨੇ ਟੈਸਟਿੰਗ ਚੱਕਰ ਨੂੰ ਘਟਾ ਦਿੱਤਾ, ਜਿਸ ਨੂੰ ਰਵਾਇਤੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ 5 ਦਿਨ ਲੱਗਦੇ ਸਨ, 2 ਦਿਨ ਤੱਕ; ਪਰ ਮਨੁੱਖੀ ਪ੍ਰਵਾਨਗੀ ਨੂੰ ਹਰ ਪੜਾਅ 'ਤੇ ਸੁਰੱਖਿਅਤ ਰੱਖਿਆ ਗਿਆ ਸੀ, ਅਤੇ ਇੱਕ ਲੋੜਾਂ ਦੀ ਅਨਿਸ਼ਚਿਤਤਾ (ਕੀ ਹੁੰਦਾ ਹੈ ਜੇਕਰ ਰਿਫ੍ਰੈਸ਼ ਅਸਫਲ ਹੋ ਜਾਂਦਾ ਹੈ) ਨੂੰ ਲਾਈਵ ਤੋਂ ਪਹਿਲਾਂ ਬੰਦ ਕਰ ਦਿੱਤਾ ਗਿਆ ਸੀ।
ਕੇਸ 2 - ਕੁੰਜੀ ਲੀਕ ਤੋਂ ਵਾਪਸੀ। ਇੱਕ ਡਿਵੈਲਪਰ ਕੋਲ AI ਜਨਰੇਟ CI YAML ਸੀ, ਅਤੇ AI ਨੇ ਇੱਕ ਉਦਾਹਰਨ ਵਜੋਂ YAML ਵਿੱਚ ਇੱਕ ਅਸਲੀ ਦਿੱਖ ਵਾਲੀ API ਕੁੰਜੀ ਨੂੰ ਏਮਬੈਡ ਕੀਤਾ। "ਸੁਰੱਖਿਆ/ਗੋਪਨੀਯਤਾ ਪ੍ਰੀਚੈਕ" ਕਦਮ ਨੇ ਇਸਨੂੰ ਹਾਸਲ ਕੀਤਾ; ਕੁੰਜੀ ਨੂੰ ਗੁਪਤ ਸੰਦਰਭ ਵਿੱਚ ਬਦਲਿਆ ਗਿਆ। ਆਡਿਟ ਕਦਮ ਦੇ ਬਿਨਾਂ, ਕੁੰਜੀ ਸੰਸਕਰਣ ਨਿਯੰਤਰਣ (ਗਿਟ ਇਤਿਹਾਸ) ਵਿੱਚ ਲੀਕ ਹੋ ਜਾਵੇਗੀ।
ਕੇਸ 3 - ਅਧਿਕਾਰ ਦੀ ਸੀਮਾ। ਇੱਕ ਟੀਮ ਮੈਂਬਰ IDOR ਟੈਸਟ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਚਾਹੁੰਦਾ ਸੀ ਜੋ ਉਸਨੇ "ਮੈਂ ਉਤਸੁਕ ਸੀ" ਵਿੱਚੋਂ ਇੱਕ ਕਾਰੋਬਾਰੀ ਭਾਈਵਾਲ ਦੇ ਲਾਈਵ ਸਿਸਟਮ ਲਈ ਸਿੱਖਿਆ ਸੀ। QA ਨੇਤਾ ਨੇ ਰੋਕਿਆ: ਲਿਖਤੀ ਅਧਿਕਾਰ ਅਤੇ ਪਰਿਭਾਸ਼ਿਤ ਦਾਇਰੇ ਤੋਂ ਬਿਨਾਂ ਕਿਸੇ ਹੋਰ ਸਿਸਟਮ 'ਤੇ ਸੁਰੱਖਿਆ ਜਾਂਚ ਕਰਨਾ ਗੈਰ-ਕਾਨੂੰਨੀ ਹੈ। ਟੈਸਟਿੰਗ ਸਿਰਫ ਉਹਨਾਂ ਦੇ ਆਪਣੇ ਉਤਪਾਦਾਂ ਦੇ ਟੈਸਟ ਵਾਤਾਵਰਣ ਵਿੱਚ, ਅਧਿਕਾਰ ਦੇ ਨਾਲ ਕੀਤੀ ਗਈ ਸੀ; ਖੁੱਲ੍ਹੇਆਮ ਜ਼ਿੰਮੇਵਾਰ ਧਿਰ ਵੱਲੋਂ ਸਬੰਧਤ ਟੀਮ ਨੂੰ ਸੂਚਿਤ ਕੀਤਾ ਗਿਆ।
ਆਮ ਗਲਤੀਆਂ
- AI ਨੂੰ ਜਾਰੀ ਕਰਨ ਦੇ ਫੈਸਲੇ ਲੈਣਾ। ਸਵਾਲ ਪੁੱਛਣਾ "ਕੀ ਇਸ ਨੂੰ ਜਾਰੀ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ?" AI ਨੂੰ ਭੇਜੋ ਅਤੇ ਦਸਤਖਤ ਦੀ ਥਾਂ 'ਤੇ ਜਵਾਬ ਪਾਓ।
- ਸਵੈਚਲਿਤ ਟੈਸਟ "ਪਾਸ ਕਰਨਾ"। CI ਵਿੱਚ, AI ਹੋਣ ਨਾਲ ਟੈਸਟ ਨੂੰ ਹਰਾ ਰੰਗ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ; ਗਲਤੀਆਂ ਨੂੰ ਢੱਕਣਾ.
- ਵਾਹਨ ਨੂੰ ਗੁਪਤ ਡੇਟਾ/ਕੁੰਜੀ ਦੇਣਾ। ਬਿਨਾਂ ਨਿਗਰਾਨੀ ਦੇ ਉਤਪਾਦਨ ਡੇਟਾ, ਨਿੱਜੀ ਡੇਟਾ ਜਾਂ API ਕੁੰਜੀਆਂ ਨੂੰ ਸਾਂਝਾ ਕਰਨਾ।
- ਅਣਅਧਿਕਾਰਤ ਸੁਰੱਖਿਆ ਟੈਸਟਿੰਗ. ਸਕੋਪ ਅਤੇ ਇਜਾਜ਼ਤ ਦੇ ਬਿਨਾਂ ਕਿਸੇ ਹੋਰ ਸਿਸਟਮ 'ਤੇ ਹਮਲਾਵਰ ਟੈਸਟਿੰਗ।
- ਸਮੀਖਿਆ ਤੋਂ ਬਿਨਾਂ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਟੈਸਟਾਂ ਨੂੰ ਪੇਸ਼ ਕਰਨਾ। ਮਨੁੱਖੀ ਪ੍ਰਵਾਨਗੀ ਤੋਂ ਬਿਨਾਂ AI ਸਕੈਚ ਨੂੰ ਆਟੋਮੈਟਿਕ ਚਲਾਓ।
- AI 'ਤੇ ਦੋਸ਼ ਮੜ੍ਹਨਾ। "AI ਨੇ ਲਿਖਿਆ" ਕਹਿ ਕੇ ਗਲਤ ਆਉਟਪੁੱਟ ਦਾ ਬਚਾਅ ਕਰਨਾ।
ਸਾਰੰਸ਼ ਵਿੱਚ
ਐਂਡ-ਟੂ-ਐਂਡ QA ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਹੈ ਜੋ ਲੋੜਾਂ ਤੋਂ ਲੈ ਕੇ ਉਤਪਾਦਨ ਟਰੈਕਿੰਗ ਤੱਕ ਫੈਲਦੀ ਹੈ ਅਤੇ CI/CD ਦੇ ਅੰਦਰ ਰਹਿੰਦੀ ਹੈ; ਹਰ ਪੜਾਅ 'ਤੇ, AI ਡਰਾਫਟ ਤਿਆਰ ਕਰਦਾ ਹੈ, ਲੌਗ ਨੂੰ ਸੰਖੇਪ ਕਰਦਾ ਹੈ, ਅਤੇ ਮੂਲ ਕਾਰਨਾਂ ਦਾ ਸੁਝਾਅ ਦਿੰਦਾ ਹੈ। ਪਰ ਸੀਮਾਵਾਂ ਅਟੱਲ ਹਨ: ਮਨੁੱਖ ਟੈਸਟਿੰਗ ਫੈਸਲੇ ਲੈਂਦੇ ਹਨ ਅਤੇ ਪ੍ਰਵਾਨਗੀ ਜਾਰੀ ਕਰਦੇ ਹਨ; AI ਨੂੰ ਕਦੇ ਵੀ ਆਪਣੇ ਆਪ ਟੈਸਟ ਪਾਸ ਕਰਨ ਦਾ ਅਧਿਕਾਰ ਨਹੀਂ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ; ਗੁਪਤ ਡੇਟਾ ਅਤੇ ਕੁੰਜੀਆਂ ਵਾਹਨ ਵਿੱਚ ਦਾਖਲ ਨਹੀਂ ਹੁੰਦੀਆਂ ਹਨ; ਸੁਰੱਖਿਆ ਜਾਂਚ ਸਿਰਫ ਤੁਹਾਡੇ ਆਪਣੇ ਉਤਪਾਦ 'ਤੇ, ਲਿਖਤੀ ਅਧਿਕਾਰ ਅਤੇ ਪਰਿਭਾਸ਼ਿਤ ਦਾਇਰੇ ਦੇ ਅੰਦਰ, ਰੱਖਿਆਤਮਕ ਉਦੇਸ਼ਾਂ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਨਤੀਜਿਆਂ ਨੂੰ ਜ਼ਿੰਮੇਵਾਰ ਖੁਲਾਸੇ ਨਾਲ ਰਿਪੋਰਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ AI ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ ਤਾਂ ਪਾਰਦਰਸ਼ੀ ਰਹੋ; ਤੁਸੀਂ ਆਉਟਪੁੱਟ ਦੀ ਸ਼ੁੱਧਤਾ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੋ। ਏਆਈ ਤੇਜ਼ ਕਰਦਾ ਹੈ; ਤੁਸੀਂ ਗੁਣਵੱਤਾ ਅਤੇ ਨੈਤਿਕਤਾ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦੇ ਹੋ।
ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਕੰਮ
ਆਪਣੇ ਖੁਦ ਦੇ ਪ੍ਰੋਜੈਕਟ ਦੀ ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਲਈ "ਐਂਡ-ਟੂ-ਐਂਡ ਟੈਸਟ ਪਲਾਨ" ਟੈਮਪਲੇਟ ਨਾਲ ਜਾਰੀ ਕਰਨ ਲਈ ਵਿਚਾਰ ਤੋਂ ਇੱਕ ਯੋਜਨਾ ਦਾ ਖਰੜਾ ਤਿਆਰ ਕਰੋ; ਹਰ ਪੜਾਅ 'ਤੇ AI ਅਤੇ ਮਨੁੱਖੀ ਪ੍ਰਵਾਨਗੀ ਬਿੰਦੂਆਂ ਦੀ ਭੂਮਿਕਾ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਚਿੰਨ੍ਹਿਤ ਕਰੋ। ਫਿਰ "CI/CD ਪਾਈਪਲਾਈਨ ਆਉਟਲਾਈਨ" ਦੇ ਨਾਲ ਇੱਕ YAML ਤਿਆਰ ਕਰੋ ਅਤੇ ਏਮਬੈਡਡ ਕੁੰਜੀ/ਗੁਪਤ ਡੇਟਾ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਇਸ YAML 'ਤੇ "ਸੁਰੱਖਿਆ/ਗੋਪਨੀਯਤਾ ਪ੍ਰੀਚੈੱਕ" ਲਾਗੂ ਕਰੋ। ਅੰਤ ਵਿੱਚ, ਆਪਣੀ ਯੋਜਨਾ ਵਿੱਚ ਸਾਰੇ "ਮਨੁੱਖੀ ਫੈਸਲੇ" ਬਿੰਦੂਆਂ ਦੀ ਸੂਚੀ ਬਣਾਓ ਅਤੇ ਇੱਕ ਵਾਕ ਵਿੱਚ ਜਾਇਜ਼ ਠਹਿਰਾਓ ਕਿ ਇਹ ਫੈਸਲੇ AI ਨੂੰ ਕਿਉਂ ਨਹੀਂ ਸੌਂਪੇ ਜਾ ਸਕਦੇ।
ਚੈੱਕਲਿਸਟ
- [ ] ਮੈਂ ਰੀਲੀਜ਼ ਅਤੇ ਟੈਸਟਿੰਗ ਦੇ ਫੈਸਲਿਆਂ ਨੂੰ ਮਨੁੱਖੀ ਮਨਜ਼ੂਰੀ ਦਿੰਦਾ ਹਾਂ; ਮੈਂ ਇਸਨੂੰ AI ਦੇ ਹਵਾਲੇ ਨਹੀਂ ਕੀਤਾ।
- [ ] CI/CD ਵਿੱਚ ਮੈਂ AI ਨੂੰ ਟੈਸਟ ਨੂੰ ਆਪਣੇ ਆਪ "ਪਾਸ/ਸਹੀ" ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੱਤੀ।
- [ ] ਮੈਂ ਵਾਹਨ ਨੂੰ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਗੁਪਤ ਡੇਟਾ, ਨਿੱਜੀ ਡੇਟਾ ਅਤੇ ਕੁੰਜੀਆਂ ਦੀ ਜਾਂਚ ਕੀਤੀ ਅਤੇ ਮਾਸਕ ਕੀਤਾ।
- [ ] ਮੈਂ ਲਿਖਤੀ ਅਧਿਕਾਰ ਅਤੇ ਦਾਇਰੇ ਦੇ ਅੰਦਰ, ਸਿਰਫ ਆਪਣੇ ਉਤਪਾਦ 'ਤੇ ਸੁਰੱਖਿਆ ਟੈਸਟਿੰਗ 'ਤੇ ਵਿਚਾਰ ਕੀਤਾ ਹੈ।
- [ ] ਮੈਂ ਜ਼ਿੰਮੇਵਾਰ ਖੁਲਾਸੇ ਦੇ ਸਿਧਾਂਤ ਨਾਲ ਪਾਈਆਂ ਗਈਆਂ ਕਮਜ਼ੋਰੀਆਂ ਨੂੰ ਸੰਬੋਧਿਤ ਕੀਤਾ।
- [ ] ਮੈਂ ਪਾਰਦਰਸ਼ੀ ਤੌਰ 'ਤੇ ਕਿਹਾ ਕਿ ਮੈਂ AI ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਹੈ ਅਤੇ ਆਉਟਪੁੱਟ ਦੀ ਸ਼ੁੱਧਤਾ ਲਈ ਆਪਣੇ ਆਪ ਨੂੰ ਜ਼ਿੰਮੇਵਾਰ ਠਹਿਰਾਇਆ ਹੈ।
ਮੋਡੀਊਲ ਪ੍ਰੀਖਿਆ
1. QA ਸੰਦਰਭ ਵਿੱਚ 'ਗਲਤ ਪਾਸ' ਨੂੰ ਸਭ ਤੋਂ ਸਹੀ ਢੰਗ ਨਾਲ ਕਿਵੇਂ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ?
- ਏ) ਹਾਲਾਂਕਿ ਟੈਸਟ ਹਰਾ ਹੋ ਜਾਂਦਾ ਹੈ, ਇਹ ਅਸਲ ਵਿੱਚ ਕਿਸੇ ਵਿਵਹਾਰ ਦੀ ਪੁਸ਼ਟੀ ਨਹੀਂ ਕਰਦਾ; ✔ ਕੋਡ ਖਰਾਬ ਹੋਣ 'ਤੇ ਵੀ ਲਾਲ ਨਹੀਂ ਹੁੰਦਾ
- ਅ) ਟੈਸਟ ਬਹੁਤ ਹੌਲੀ ਚੱਲਦਾ ਹੈ ਅਤੇ ਸਮਾਂ ਖਤਮ ਹੁੰਦਾ ਹੈ।
- C) ਟੈਸਟ ਇੱਕ ਅਸਲੀ ਗਲਤੀ ਦਾ ਪਤਾ ਲਗਾਉਂਦਾ ਹੈ ਅਤੇ ਲਾਲ ਹੋ ਜਾਂਦਾ ਹੈ
- ਡੀ) ਟੈਸਟ ਸਿਰਫ ਉਤਪਾਦਨ ਦੇ ਵਾਤਾਵਰਣ ਵਿੱਚ ਚੱਲਦਾ ਹੈ
ਵਿਆਖਿਆ: ਇੱਕ ਸੂਡੋ-ਪਾਸ ਉਦੋਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕੋਈ ਟੈਸਟ 'ਪਾਸ' ਕਹਿੰਦਾ ਹੈ ਪਰ ਅਸਲ ਵਿੱਚ ਕੋਈ ਵੀ ਅਰਥਪੂਰਨ ਪੁਸ਼ਟੀ ਨਹੀਂ ਕਰਦਾ; ਟੈਸਟ ਹਰਾ ਹੈ, ਪਰ ਭਾਵੇਂ ਸੌਫਟਵੇਅਰ ਨੁਕਸਦਾਰ ਹੈ, ਇਹ ਇਸ ਨੂੰ ਨਹੀਂ ਫੜੇਗਾ। ਇਹ QA ਵਿੱਚ AI ਦਾ ਨੰਬਰ ਇੱਕ ਜੋਖਮ ਹੈ ਕਿਉਂਕਿ AI ਅਜਿਹੇ ਟੈਸਟ ਪੈਦਾ ਕਰਦਾ ਹੈ ਜੋ ਸਾਫ਼-ਸੁਥਰੇ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ ਪਰ ਖੋਖਲੇ ਹੁੰਦੇ ਹਨ।
2. ਟੈਸਟਿੰਗ ਅਤੇ QA ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਨਕਲੀ ਬੁੱਧੀ ਦੀ ਸਭ ਤੋਂ ਸਹੀ ਸਥਿਤੀ ਕੀ ਹੈ?
- ਏ) ਨਕਲੀ ਬੁੱਧੀ ਇਹ ਫੈਸਲਾ ਕਰ ਸਕਦੀ ਹੈ ਕਿ ਕੀ ਸੰਸਕਰਣ ਮਨੁੱਖੀ ਪ੍ਰਵਾਨਗੀ ਤੋਂ ਬਿਨਾਂ ਜਾਰੀ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ
- ਅ) ਨਕਲੀ ਬੁੱਧੀ ਇੱਕ ਸਹਾਇਕ ਹੈ ਜੋ ਡਰਾਫਟ ਅਤੇ ਵਿਚਾਰ ਤਿਆਰ ਕਰਦੀ ਹੈ; 'ਕੀ ਇਹ ਪ੍ਰਕਾਸ਼ਨ ਲਈ ਤਿਆਰ ਹੈ' ਦਾ ਫੈਸਲਾ ਅਤੇ ਜ਼ਿੰਮੇਵਾਰੀ ਮਾਹਰ ਦੀ ਹੈ ✔
- C) ਆਰਟੀਫੀਸ਼ੀਅਲ ਇੰਟੈਲੀਜੈਂਸ ਸਿਰਫ ਟੈਕਸਟ ਲਿਖਦੀ ਹੈ ਅਤੇ ਟੈਸਟ ਕੋਡ ਨਾਲ ਬਿਲਕੁਲ ਵੀ ਨਜਿੱਠ ਨਹੀਂ ਸਕਦੀ
- ਡੀ) ਨਕਲੀ ਬੁੱਧੀ ਹਮੇਸ਼ਾ ਮਨੁੱਖ ਨਾਲੋਂ ਸਹੀ ਟੈਸਟ ਲਿਖਦੀ ਹੈ, ਇਸ ਲਈ ਸਮੀਖਿਆ ਬੇਲੋੜੀ ਹੈ
ਵਰਣਨ: ਨਕਲੀ ਬੁੱਧੀ ਇੱਕ ਟੈਸਟਿੰਗ ਸਹਾਇਕ, ਡਰਾਫਟ ਜਨਰੇਟਰ ਅਤੇ ਵਿਚਾਰ ਗੁਣਕ ਹੈ; ਟੈਸਟ ਦੇ ਦ੍ਰਿਸ਼, ਆਟੋਮੇਸ਼ਨ ਕੋਡ ਅਤੇ ਰਿਪੋਰਟ ਡਰਾਫਟ ਤਿਆਰ ਕਰਦਾ ਹੈ। ਹਾਲਾਂਕਿ, 'ਕੀ ਇਹ ਸਾਫਟਵੇਅਰ ਪ੍ਰਕਾਸ਼ਨ ਲਈ ਤਿਆਰ ਹੈ' ਜਾਂ 'ਕੀ ਇਹ ਟੈਸਟ ਪਾਸ ਕੀਤਾ ਗਿਆ ਹੈ' ਵਰਗੇ ਗੁਣਵੱਤਾ ਵਾਲੇ ਫੈਸਲਿਆਂ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਅਤੇ ਅੰਤਿਮ ਪ੍ਰਵਾਨਗੀ ਸਮਰੱਥ ਮਾਹਰ ਦੀ ਹੈ।
3. ਇਸ ਤੱਥ ਦੇ ਆਧਾਰ 'ਤੇ ਕਿ ਗਲਤੀਆਂ ਜ਼ਿਆਦਾਤਰ ਥ੍ਰੈਸ਼ਹੋਲਡ ਮੁੱਲਾਂ 'ਤੇ ਹੁੰਦੀਆਂ ਹਨ, ਕਿਹੜੀ ਟੈਸਟ ਡਿਜ਼ਾਈਨ ਤਕਨੀਕ 18 ਦੀ ਉਮਰ ਸੀਮਾ ਲਈ 17, 18 ਅਤੇ 19 ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਟੈਸਟ ਕਰਨ ਲਈ ਹੈ?
- ਏ) ਰਾਜ ਪਰਿਵਰਤਨ ਟੈਸਟ
- ਅ) ਫੈਸਲਾ ਸਾਰਣੀ
- ਸੀ) ਸੀਮਾ ਮੁੱਲ ਵਿਸ਼ਲੇਸ਼ਣ ✔
- ਡੀ) ਖੋਜੀ ਟੈਸਟਿੰਗ
ਵਿਆਖਿਆ: ਸੀਮਾ ਮੁੱਲ ਵਿਸ਼ਲੇਸ਼ਣ ਇਸ ਨਿਰੀਖਣ 'ਤੇ ਅਧਾਰਤ ਹੈ ਕਿ ਗਲਤੀਆਂ ਸੀਮਾਵਾਂ 'ਤੇ ਅਕਸਰ ਵਾਪਰਦੀਆਂ ਹਨ ਅਤੇ ਥ੍ਰੈਸ਼ਹੋਲਡ ਮੁੱਲਾਂ (ਬਿਲਕੁਲ ਹੇਠਾਂ, ਬਿਲਕੁਲ ਉੱਪਰ, ਅਤੇ ਸੀਮਾ ਤੋਂ ਬਿਲਕੁਲ ਉੱਪਰ) ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਟੈਸਟ ਕਰਦੀਆਂ ਹਨ। ਇਹ ਇੱਕ ਸ਼ਕਤੀਸ਼ਾਲੀ ਤਕਨੀਕ ਹੈ ਜੋ ਬਰਾਬਰੀ ਦੀਆਂ ਕਲਾਸਾਂ ਨੂੰ ਪੂਰਕ ਕਰਦੀ ਹੈ।
4. ਨਕਲੀ ਬੁੱਧੀ ਨਾਲ ਤਿਆਰ ਕੀਤੇ UI ਟੈਸਟ ਆਟੋਮੇਸ਼ਨ ਕੋਡ ਵਿੱਚ ਕਮਜ਼ੋਰੀ ਨੂੰ ਘਟਾਉਣ ਲਈ ਤੱਤ ਦੀ ਚੋਣ ਵਿੱਚ ਕਿਹੜੀ ਪਹੁੰਚ ਨੂੰ ਤਰਜੀਹ ਦਿੱਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ?
- ਏ) ਸਭ ਤੋਂ ਲੰਬੇ XPath ਮਾਰਗ ਦੀ ਵਰਤੋਂ ਕਰਨਾ
- ਅ) ਸਕਰੀਨ 'ਤੇ ਇਸਦੀ ਪਿਕਸਲ ਸਥਿਤੀ ਦੇ ਅਨੁਸਾਰ ਤੱਤ ਦੀ ਚੋਣ ਕਰਨਾ
- C) CSS ਕਲਾਸ ਦੇ ਨਾਮਾਂ ਦੇ ਅਧਾਰ ਤੇ ਚੋਣਕਾਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ
- D) ਟੈਸਟਿੰਗ ਲਈ ਜੋੜੀਆਂ ਗਈਆਂ ਸਥਿਰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ (ਡੇਟਾ-ਟੈਸਟਿਡ) ਦੀ ਵਰਤੋਂ ਕਰਨਾ ✔
ਵਿਆਖਿਆ: ਲੰਬੇ XPath ਮਾਰਗ ਅਤੇ CSS ਕਲਾਸ ਦੇ ਨਾਮ ਪੇਜ ਬਣਤਰ ਅਤੇ ਡਿਜ਼ਾਈਨ 'ਤੇ ਬਹੁਤ ਨਿਰਭਰ ਹਨ; ਇਹ ਮਾਮੂਲੀ ਇੰਟਰਫੇਸ ਬਦਲਾਅ 'ਤੇ ਟੁੱਟ ਜਾਂਦਾ ਹੈ। ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਟੈਸਟਿੰਗ ਲਈ ਜੋੜੀਆਂ ਗਈਆਂ ਸਥਿਰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ (ਜਿਵੇਂ ਕਿ ਡੇਟਾ-ਟੈਸਟਿਡ) ਡਿਜ਼ਾਈਨ ਤਬਦੀਲੀਆਂ ਦੁਆਰਾ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਟੈਸਟਾਂ ਨੂੰ ਮਜ਼ਬੂਤ ਬਣਾਉਂਦੀਆਂ ਹਨ।
5. ਏਪੀਆਈ ਟੈਸਟ ਲਈ ਸਿਰਫ਼ HTTP ਸਥਿਤੀ ਕੋਡ (ਉਦਾਹਰਨ ਲਈ 200) ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਇਹ ਨਾਕਾਫ਼ੀ ਕਿਉਂ ਹੈ?
- A) ਕਿਉਂਕਿ ਸਹੀ ਸਥਿਤੀ ਕੋਡ ਵਾਲਾ ਸਰੀਰ ਡੇਟਾ ਖਰਾਬ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਸਥਿਤੀ ਦੀ ਜਾਂਚ ਹੀ ਇਸ ਨੂੰ ਨਹੀਂ ਫੜੇਗੀ (ਸੂਡੋ-ਟਰਸਟ) ✔
- ਅ) ਕਿਉਂਕਿ ਸਥਿਤੀ ਕੋਡ API ਟੈਸਟਾਂ ਵਿੱਚ ਬਿਲਕੁਲ ਵੀ ਭਰੋਸੇਯੋਗ ਨਹੀਂ ਹੁੰਦੇ ਹਨ
- C) ਕਿਉਂਕਿ ਸਥਿਤੀ ਕੋਡ ਦੀ ਜਾਂਚ ਟੈਸਟ ਨੂੰ ਬਹੁਤ ਹੌਲੀ ਕਰ ਦਿੰਦੀ ਹੈ
- ਡੀ) ਕਿਉਂਕਿ API ਟੈਸਟਾਂ ਵਿੱਚ ਸਥਿਤੀ ਕੋਡ ਕਦੇ ਵੀ ਵਾਪਸ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ
ਵਿਆਖਿਆ: ਜਦੋਂ ਸਰਵਰ ਸਹੀ ਸਥਿਤੀ ਕੋਡ ਵਾਪਸ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਸਰੀਰ ਵਿੱਚ ਖਰਾਬ ਡੇਟਾ ਵਾਪਸ ਕਰ ਸਕਦਾ ਹੈ (ਗਲਤ ਕਿਸਮ, ਗੁੰਮ ਫੀਲਡ, ਗਲਤ ਢੰਗ ਨਾਲ ਗਿਣਿਆ ਮੁੱਲ)। ਟੈਸਟ ਜੋ ਸਿਰਫ ਸਥਿਤੀ ਨੂੰ ਵੇਖਦਾ ਹੈ ਇਸ ਨੂੰ ਨਹੀਂ ਦੇਖ ਸਕਦਾ ਅਤੇ ਗਲਤ ਵਿਸ਼ਵਾਸ ਦਿੰਦਾ ਹੈ. ਇਸ ਲਈ ਸਕੀਮਾ/ਇਕਰਾਰਨਾਮਾ ਅਤੇ ਕਾਰੋਬਾਰੀ ਨਿਯਮ ਪ੍ਰਮਾਣਿਕਤਾ ਨੂੰ ਵੀ ਜੋੜਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
6. ਯੂਨਿਟ ਟੈਸਟਾਂ ਨੂੰ ਛਾਪਣ ਵੇਲੇ AI ਨੂੰ 'ਸਵੀਕ੍ਰਿਤੀ ਨਿਯਮ ਦੇ ਅਨੁਸਾਰ ਸੰਭਾਵਿਤ ਮੁੱਲ ਦੀ ਦਸਤੀ ਗਣਨਾ ਕਰਨ ਲਈ, ਫੰਕਸ਼ਨ ਦੇ ਮੌਜੂਦਾ ਆਉਟਪੁੱਟ ਦਾ ਹਵਾਲਾ ਨਾ ਦਿਓ' ਲਈ ਕਹਿਣਾ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ?
- A) ਕਿਉਂਕਿ ਦਸਤੀ ਗਣਨਾ ਟੈਸਟਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਚਲਾਉਂਦੀ ਹੈ
- ਅ) ਕਿਉਂਕਿ ਨਹੀਂ ਤਾਂ ਟੈਸਟ ਕੋਡ ਦੇ ਮੌਜੂਦਾ (ਸ਼ਾਇਦ ਬੱਗੀ) ਵਿਹਾਰ ਨੂੰ 'ਸਹੀ' ਵਜੋਂ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਅਤੇ ਬੱਗ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ✔
- C) ਕਿਉਂਕਿ ਆਰਟੀਫੀਸ਼ੀਅਲ ਇੰਟੈਲੀਜੈਂਸ ਦਸ਼ਮਲਵ ਸੰਖਿਆਵਾਂ ਦੀ ਗਣਨਾ ਨਹੀਂ ਕਰ ਸਕਦੀ
- ਡੀ) ਕਿਉਂਕਿ ਸਵੀਕ੍ਰਿਤੀ ਨਿਯਮ ਕਦੇ ਵੀ ਟੈਸਟਾਂ ਵਿੱਚ ਨਹੀਂ ਵਰਤੇ ਜਾਂਦੇ ਹਨ
ਵਿਆਖਿਆ: ਜੇਕਰ AI ਟੈਸਟ ਦੇ ਅਧੀਨ ਫੰਕਸ਼ਨ ਦੇ ਆਉਟਪੁੱਟ ਤੋਂ ਅਨੁਮਾਨਿਤ ਮੁੱਲ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਟੈਸਟ ਨੂੰ 'ਪਾਸ' ਬਣਾ ਦੇਵੇਗਾ ਭਾਵੇਂ ਫੰਕਸ਼ਨ ਨੁਕਸਦਾਰ ਹੈ; ਭਾਵ, ਜੋ ਵੀ ਕੋਡ ਪੈਦਾ ਕਰਦਾ ਹੈ, ਟੈਸਟ ਨੂੰ ਸੱਚ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। ਸਵੀਕ੍ਰਿਤੀ ਨਿਯਮ ਤੋਂ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਅਨੁਮਾਨਤ ਮੁੱਲ ਦੀ ਗਣਨਾ ਕਰਨਾ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਟੈਸਟ ਨਿਯਮ ਦਾ ਗੇਟਕੀਪਰ ਹੈ, ਕੋਡ ਦਾ ਸ਼ੀਸ਼ਾ ਨਹੀਂ।
7. ਹੇਠ ਲਿਖੀਆਂ ਵਿੱਚੋਂ ਕਿਹੜੀ ਇੱਕ ਚੰਗੀ ਬੱਗ ਰਿਪੋਰਟ ਦੀ ਸਭ ਤੋਂ ਵੱਖਰੀ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ?
- ਏ) ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਲੰਬਾ ਅਤੇ ਤਕਨੀਕੀ ਹੋਣਾ
- ਅ) ਨਕਲੀ ਬੁੱਧੀ ਦੁਆਰਾ ਲਿਖਿਆ ਗਿਆ
- C) ਨਿਰਣਾਇਕ ਪ੍ਰਜਨਨ ਕਦਮਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ ਜਿਸਦਾ ਵਿਕਾਸਕਾਰ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਪਾਲਣਾ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਗਲਤੀ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ ✔
- ਡੀ) ਇਹ ਸਿਰਫ਼ ਇੱਕ ਸਕ੍ਰੀਨਸ਼ੌਟ ਹੈ
ਵਿਆਖਿਆ: ਬੱਗ ਰਿਪੋਰਟ ਦਾ ਅਸਲ ਮੁੱਲ ਇਹ ਹੈ ਕਿ ਡਿਵੈਲਪਰ ਤੁਹਾਡੀ ਮਦਦ ਤੋਂ ਬਿਨਾਂ ਬੱਗ ਨੂੰ ਦੁਬਾਰਾ ਤਿਆਰ ਕਰ ਸਕਦਾ ਹੈ। ਸਕ੍ਰੈਚ ਤੋਂ ਨਿਰਣਾਇਕ, ਖੋਜਣ ਯੋਗ ਪ੍ਰਜਨਨ ਕਦਮ ਇਸ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਂਦੇ ਹਨ; ਜੇਕਰ ਇਹ ਕਦਮ ਗਾਇਬ ਹਨ, ਤਾਂ ਰਿਪੋਰਟ ਅਕਸਰ 'ਨਿਰਮਾਣ ਨਹੀਂ ਕਰ ਸਕਿਆ' ਵਜੋਂ ਬੰਦ ਹੋ ਜਾਂਦੀ ਹੈ।
8. ਮੁੱਖ ਪੰਨੇ 'ਤੇ ਕੰਪਨੀ ਦੇ ਨਾਮ ਦੀ ਗਲਤ ਸਪੈਲਿੰਗ ਦੀ ਗਲਤੀ ਵਿੱਚ ਗੰਭੀਰਤਾ ਅਤੇ ਤਰਜੀਹ ਦੇ ਵਿਚਕਾਰ ਸਬੰਧ ਲਈ ਸਭ ਤੋਂ ਸਹੀ ਸਮੀਕਰਨ ਕਿਹੜਾ ਹੈ?
- ਏ) ਤੀਬਰਤਾ ਅਤੇ ਤਰਜੀਹ ਦਾ ਹਮੇਸ਼ਾ ਇੱਕੋ ਜਿਹਾ ਮੁੱਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ
- ਅ) ਇਸ ਗਲਤੀ ਦੀ ਗੰਭੀਰਤਾ ਅਤੇ ਤਰਜੀਹ ਦੋਵੇਂ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਘੱਟ ਹਨ
- C) ਗੰਭੀਰਤਾ ਅਤੇ ਤਰਜੀਹ ਇੱਕੋ ਧਾਰਨਾ ਹਨ, ਇੱਕ ਲੇਬਲ ਕਾਫ਼ੀ ਹੈ
- ਡੀ) ਤਕਨੀਕੀ ਤੀਬਰਤਾ ਘੱਟ ਹੋ ਸਕਦੀ ਹੈ ਪਰ ਵਪਾਰਕ ਤਰਜੀਹ (ਸ਼ੋਹਰਤ) ਉੱਚ ਹੋ ਸਕਦੀ ਹੈ; ਦੋਵਾਂ ਦਾ ਵੱਖ-ਵੱਖ ਮੁਲਾਂਕਣ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ✔
ਵਿਆਖਿਆ: ਗੰਭੀਰਤਾ ਗਲਤੀ ਦਾ ਤਕਨੀਕੀ ਪ੍ਰਭਾਵ ਹੈ (ਟਾਇਪੋ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਘੱਟ), ਤਰਜੀਹ ਇਹ ਹੈ ਕਿ ਇਸਨੂੰ ਕਿੰਨੀ ਜਲਦੀ ਠੀਕ ਕਰਨ ਦੀ ਲੋੜ ਹੈ (ਉੱਚ ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਪ੍ਰਤਿਸ਼ਠਾ ਤੱਤ ਹੈ ਜੋ ਹਰ ਵਿਜ਼ਟਰ ਦੇਖਦਾ ਹੈ)। ਦੋਵੇਂ ਹਮੇਸ਼ਾ ਇੱਕੋ ਦਿਸ਼ਾ ਵਿੱਚ ਨਹੀਂ ਜਾਂਦੇ; ਇਹ ਉਦਾਹਰਨ ਘੱਟ ਗੰਭੀਰਤਾ-ਉੱਚ ਤਰਜੀਹ ਵਾਲੀ ਸਥਿਤੀ ਹੈ।
9. 90% ਲਾਈਨ ਕਵਰੇਜ ਵਾਲੇ ਟੈਸਟ ਸੂਟ ਦੀ ਸਭ ਤੋਂ ਸਹੀ ਵਿਆਖਿਆ ਕੀ ਹੈ?
- ਏ) ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਲਾਈਨਾਂ ਨੂੰ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ ਪਰ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਉਹ ਸਹੀ ਵਿਵਹਾਰ ਕਰਦੇ ਹਨ; ✔ ਉੱਚ ਕਵਰੇਜ ਗਲਤ ਵਿਸ਼ਵਾਸ ਦੇ ਸਕਦੀ ਹੈ
- ਅ) ਸਿੱਟੇ ਵਜੋਂ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਸਾਫਟਵੇਅਰ ਦਾ 90% ਬੱਗ-ਮੁਕਤ ਹੈ
- C) ਇਹ ਸ਼ਾਨਦਾਰ ਟੈਸਟ ਗੁਣਵੱਤਾ ਦਾ ਇੱਕ ਨਿਸ਼ਚਿਤ ਮਾਪ ਹੈ।
- ਡੀ) ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਹੁਣ ਕੋਈ ਵਾਧੂ ਟੈਸਟ ਲਿਖਣ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ
ਵਿਆਖਿਆ: ਕਤਾਰ ਕਵਰੇਜ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਸਿਰਫ਼ ਕਤਾਰਾਂ ਹੀ ਚਲਾਈਆਂ ਗਈਆਂ ਸਨ; ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਇਹ ਸਹੀ ਨਤੀਜੇ ਪੈਦਾ ਕਰਦਾ ਹੈ. ਬੇਲੋੜੇ ਟੈਸਟਾਂ ਦੇ ਨਾਲ ਵੀ, 90% ਕਵਰੇਜ ਪ੍ਰਾਪਤ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਸਕੋਪ ਇੱਕ 'ਕਦੇ ਨਹੀਂ ਦੇਖਿਆ ਕਿੱਥੇ' ਨਕਸ਼ਾ ਹੈ, ਨਾ ਕਿ 'ਸਭ ਕੁਝ ਪਰਖਿਆ ਗਿਆ ਹੈ' ਭਰੋਸਾ; ਅਸਲ ਸੁਰੱਖਿਆ ਨੂੰ ਪਰਿਵਰਤਨ ਜਾਂਚ ਦੁਆਰਾ ਮਾਪਿਆ ਜਾਂਦਾ ਹੈ।
10. ਜੋਖਮ-ਅਧਾਰਤ ਟੈਸਟਿੰਗ ਵਿੱਚ, ਕਿਸੇ ਵਿਸ਼ੇਸ਼ਤਾ ਦੇ ਜੋਖਮ ਨੂੰ ਸਿੱਧੇ ਸੀਮਤ ਟੈਸਟਿੰਗ ਯਤਨਾਂ ਲਈ ਕਿਵੇਂ ਗਿਣਿਆ ਜਾਂਦਾ ਹੈ?
- ਏ) ਸਿਰਫ਼ ਕੋਡ ਦੀਆਂ ਲਾਈਨਾਂ ਦੀ ਗਿਣਤੀ ਦੁਆਰਾ
- ਅ) ਅਸਫਲਤਾ ਦੀ ਸੰਭਾਵਨਾ ਅਤੇ ਇਸ ਦੇ ਟੁੱਟਣ 'ਤੇ ਹੋਣ ਵਾਲੇ ਪ੍ਰਭਾਵ ਨੂੰ ਗੁਣਾ ਕਰਕੇ ✔
- C) ਸਿਰਫ਼ ਉਸੇ ਕ੍ਰਮ ਵਿੱਚ ਜਿਸ ਵਿੱਚ ਵਿਸ਼ੇਸ਼ਤਾ ਵਿਕਸਿਤ ਕੀਤੀ ਗਈ ਸੀ
- ਡੀ) ਸਿਰਫ਼ ਉਸ ਵਿਸ਼ੇਸ਼ਤਾ ਨੂੰ ਤਰਜੀਹ ਦੇਣਾ ਜਿਸ ਲਈ ਟੈਸਟ ਲਿਖਣਾ ਸਭ ਤੋਂ ਆਸਾਨ ਹੈ
ਵਿਆਖਿਆ: ਜੋਖਮ-ਅਧਾਰਿਤ ਟੈਸਟਿੰਗ ਵਿੱਚ, ਜੋਖਮ ਦਾ ਮੁਲਾਂਕਣ ਸੰਭਾਵਤਤਾ = ਸੰਭਾਵਨਾ (ਟੁੱਟਣ ਦੀ ਸੰਭਾਵਨਾ) × ਪ੍ਰਭਾਵ (ਜੇ ਟੁੱਟਣ 'ਤੇ ਨੁਕਸਾਨ) ਵਜੋਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਉੱਚ ਸੰਭਾਵਨਾ ਅਤੇ ਉੱਚ ਪ੍ਰਭਾਵ ਵਾਲੇ ਡੋਮੇਨ (ਭੁਗਤਾਨ, ਪ੍ਰਮਾਣਿਕਤਾ) ਸਭ ਤੋਂ ਤੀਬਰ ਜਾਂਚ ਦੇ ਹੱਕਦਾਰ ਹਨ, ਜਦੋਂ ਕਿ ਘੱਟ × ਘੱਟ ਡੋਮੇਨ ਲਾਈਟ ਟੈਸਟਿੰਗ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ।
11. ਇੱਕ ਟੈਸਟ ਵਿੱਚ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦਾ ਮੁੱਖ ਜੋਖਮ ਕੀ ਹੈ ਜੋ ਕਦੇ ਪਾਸ ਹੁੰਦਾ ਹੈ ਅਤੇ ਕਈ ਵਾਰ ਫੇਲ ਹੁੰਦਾ ਹੈ (ਭੁਰਭੁਰਾ/ਫਲਕੀ) ਭਾਵੇਂ ਕੋਡ ਬਦਲਿਆ ਨਹੀਂ ਹੈ?
- ਏ) ਟੈਸਟ ਦੇ ਚੱਲ ਰਹੇ ਸਮੇਂ ਨੂੰ ਛੋਟਾ ਕਰਨਾ
- ਅ) ਕਵਰੇਜ ਪ੍ਰਤੀਸ਼ਤ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ
- C) ਇੱਕ ਸਹੀ ਸਮਕਾਲੀ ਗਲਤੀ ਜਾਂ ਮੂਲ ਕਾਰਨ ਨੂੰ ਢੱਕਣਾ ਅਤੇ ਲੱਛਣ ਨੂੰ ਦਬਾਉਣ ਲਈ ✔
- ਡੀ) ਟੈਸਟ ਦਾ ਨਾਮ ਬਦਲਣਾ
ਵਿਆਖਿਆ: ਮੁੜ-ਕੋਸ਼ਿਸ਼ ਇੱਕ ਡਾਇਗਨੌਸਟਿਕ ਟੂਲ ਹੈ, ਇੱਕ ਇਲਾਜ ਨਹੀਂ। ਨਿਰਣਾਇਕਤਾ ਅਕਸਰ ਇੱਕ ਅਸਲ ਨਸਲੀ ਸਥਿਤੀ ਜਾਂ ਨਸ਼ੇ ਤੋਂ ਆਉਂਦੀ ਹੈ; ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਕੇ ਟੈਸਟ 'ਪਾਸ' ਕਰਨਾ ਇਸ ਅਸਲ ਗਲਤੀ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ ਅਤੇ ਲਾਈਵ ਵਿੱਚ ਗੰਭੀਰ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ। ਪਹਿਲਾਂ ਮੂਲ ਕਾਰਨ ਲੱਭਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ.
12. ਪਰਿਵਰਤਨ ਜਾਂਚ, ਇਹ ਮਾਪਣ ਦਾ ਸਭ ਤੋਂ ਇਮਾਨਦਾਰ ਤਰੀਕਾ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਇੱਕ ਟੈਸਟ ਸੂਟ ਅਸਲ ਵਿੱਚ ਸੁਰੱਖਿਆ ਕਰਦਾ ਹੈ, ਕੰਮ ਕਰਦਾ ਹੈ?
- ਏ) ਟੈਸਟਾਂ ਦੀ ਚੱਲ ਰਹੀ ਗਤੀ ਨੂੰ ਮਾਪ ਕੇ
- ਅ) ਗਿਣਤੀ ਕਰਕੇ ਕੋਡ ਦੀਆਂ ਕਿੰਨੀਆਂ ਲਾਈਨਾਂ ਲਿਖੀਆਂ ਗਈਆਂ ਸਨ
- C) ਵੱਖ-ਵੱਖ ਕ੍ਰਮ ਵਿੱਚ ਟੈਸਟ ਚਲਾ ਕੇ
- ਡੀ) ਕੋਡ ਵਿੱਚ ਜਾਣਬੁੱਝ ਕੇ ਛੋਟੇ ਬ੍ਰੇਕ ਬਣਾ ਕੇ ਅਤੇ ਇਹ ਮਾਪ ਕੇ ਕਿ ਕੀ ਟੈਸਟ ਉਨ੍ਹਾਂ ਨੂੰ ਫੜਦੇ ਹਨ ✔
ਵਰਣਨ: ਪਰਿਵਰਤਨ ਜਾਂਚ ਸਰੋਤ ਕੋਡ ਵਿੱਚ ਛੋਟੀਆਂ ਜਾਣਬੁੱਝ ਕੇ ਵਿਗਾੜ (ਮਿਊਟੇਸ਼ਨ) ਪੈਦਾ ਕਰਦੀ ਹੈ; ਇੱਕ ਚੰਗੇ ਟੈਸਟ ਸੂਟ ਨੂੰ ਇਹਨਾਂ ਵਿਗਾੜਾਂ ਨੂੰ ਫੜਨਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਲਾਲ ਹੋ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਪਰਿਵਰਤਨ ਜੋ ਫੜੇ ਨਹੀਂ ਗਏ (ਬਚ ਗਏ) ਦਰਸਾਉਂਦੇ ਹਨ ਕਿ ਟੈਸਟ ਉਸ ਵਿਵਹਾਰ ਨੂੰ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਰੱਖਦੇ ਹਨ। ਪਰਿਵਰਤਨ ਸਕੋਰ ਪ੍ਰਤੀਸ਼ਤ ਕਵਰੇਜ ਨਾਲੋਂ ਗੁਣਵੱਤਾ ਦਾ ਇੱਕ ਬਹੁਤ ਜ਼ਿਆਦਾ ਇਮਾਨਦਾਰ ਮਾਪ ਹੈ।
13. ਸੁਰੱਖਿਆ ਟੈਸਟਿੰਗ (ਜਿਵੇਂ ਕਿ ਅਧਿਕਾਰ/ਆਈਡੀਓਆਰ ਟੈਸਟ) ਕਰਦੇ ਸਮੇਂ ਪਾਲਣਾ ਕੀਤੀ ਜਾਣ ਵਾਲੀ ਮੁੱਖ ਸੀਮਾ ਕੀ ਹੈ?
- A) ਇਹ ਸਿਰਫ ਇਸਦੇ ਆਪਣੇ ਉਤਪਾਦ 'ਤੇ, ਲਿਖਤੀ ਅਧਿਕਾਰ ਅਤੇ ਪਰਿਭਾਸ਼ਿਤ ਦਾਇਰੇ ਦੇ ਅੰਦਰ, ਰੱਖਿਆਤਮਕ ਉਦੇਸ਼ਾਂ ਲਈ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ✔
- ਅ) ਇਹ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਦਿਲਚਸਪੀ ਦੀ ਕਿਸੇ ਵੀ ਪ੍ਰਣਾਲੀ 'ਤੇ ਲਾਗੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ
- C) ਬਿਨਾਂ ਇਜਾਜ਼ਤ ਦੇ ਵਪਾਰਕ ਭਾਈਵਾਲਾਂ ਦੇ ਲਾਈਵ ਸਿਸਟਮਾਂ 'ਤੇ ਇਸ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ
- D) ਕੋਈ ਵੀ ਕਮਜ਼ੋਰੀ ਪਾਈ ਜਾਂਦੀ ਹੈ ਜੋ ਤੁਰੰਤ ਜਨਤਕ ਤੌਰ 'ਤੇ ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ।
ਵਰਣਨ: ਇਸ ਮੋਡੀਊਲ ਵਿੱਚ ਸਿੱਖੇ ਗਏ ਸੁਰੱਖਿਆ ਟੈਸਟ ਸਿਰਫ਼ ਲਿਖਤੀ ਅਧਿਕਾਰ ਅਤੇ ਪਰਿਭਾਸ਼ਿਤ ਦਾਇਰੇ ਦੇ ਅੰਦਰ, ਰੱਖਿਆਤਮਕ ਉਦੇਸ਼ਾਂ ਲਈ ਤੁਹਾਡੇ ਆਪਣੇ ਉਤਪਾਦ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਹਨ। ਬਿਨਾਂ ਇਜਾਜ਼ਤ ਦੇ ਕਿਸੇ ਹੋਰ ਦੇ ਸਿਸਟਮ ਤੱਕ ਪਹੁੰਚਣਾ ਜਾਂ ਦਾਇਰੇ ਤੋਂ ਬਾਹਰ ਦੀ ਜਾਂਚ ਕਰਨਾ ਅਨੈਤਿਕ ਅਤੇ ਗੈਰ-ਕਾਨੂੰਨੀ ਦੋਵੇਂ ਹਨ; ਲੱਭੀਆਂ ਗਈਆਂ ਕੋਈ ਵੀ ਕਮਜ਼ੋਰੀਆਂ ਜ਼ਿੰਮੇਵਾਰ ਖੁਲਾਸੇ ਦੁਆਰਾ ਰਿਪੋਰਟ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।
14. CI/CD ਪਾਈਪਲਾਈਨ ਵਿੱਚ AI ਨੂੰ ਕਦੇ ਵੀ ਕਿਹੜਾ ਅਧਿਕਾਰ ਨਹੀਂ ਦਿੱਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ?
- A) ਫੇਲ੍ਹ ਹੋਏ ਟੈਸਟ ਲੌਗਾਂ ਦਾ ਸਾਰ ਦੇਣਾ
- ਅ) ਫੇਲ (ਲਾਲ) ਟੈਸਟ ਨੂੰ ਆਪਣੇ ਆਪ 'ਪਾਸ' ਕਰਨ ਜਾਂ ਇਸ ਨੂੰ ਹਰੇ ਰੰਗ ਵਿੱਚ ਪੇਂਟ ਕਰਨ ਦਾ ਅਧਿਕਾਰ ✔
- C) ਇੱਕ ਟੈਸਟ ਕੋਡ ਡਰਾਫਟ ਦਾ ਸੁਝਾਅ ਦੇਣਾ
- ਡੀ) ਪਾਈਪਲਾਈਨ YAML ਫਾਈਲ ਡਰਾਫਟਿੰਗ
ਵਰਣਨ: AI CI/CD ਵਿੱਚ ਟੈਸਟ ਕੋਡ ਦੀ ਰੂਪਰੇਖਾ, ਪਾਈਪਲਾਈਨ YAML, ਅਤੇ ਲੌਗ ਸੰਖੇਪ ਤਿਆਰ ਕਰ ਸਕਦਾ ਹੈ; ਹਾਲਾਂਕਿ, ਫੇਲ੍ਹ ਹੋਏ ਟੈਸਟ ਨੂੰ ਆਪਣੇ ਆਪ 'ਪਾਸ/ਫਿਕਸ' ਕਰਨ ਦੀ ਯੋਗਤਾ ਕਦੇ ਨਹੀਂ ਦਿੱਤੀ ਜਾਣੀ ਚਾਹੀਦੀ। ਇਹ ਜਾਂਚ ਦੇ ਉਦੇਸ਼ ਨੂੰ ਹਰਾ ਦਿੰਦਾ ਹੈ ਅਤੇ ਆਪਣੇ ਆਪ ਗਲਤੀਆਂ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ। ਟੈਸਟ ਨੂੰ ਹਰਾ ਪੇਂਟ ਕਰਨਾ ਇੱਕ ਵਿਅਕਤੀ ਦਾ ਸੁਚੇਤ ਅਤੇ ਤਰਕਪੂਰਨ ਫੈਸਲਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।