ਇੱਕ DBMS ਵਿੱਚ ਯੂਨਿਟ ਟੈਸਟ - ਅਸੀਂ ਇਸਨੂੰ ਸਪੋਰਟਮਾਸਟਰ ਵਿੱਚ ਕਿਵੇਂ ਕਰਦੇ ਹਾਂ, ਭਾਗ ਇੱਕ

ਹੇ ਹਬਰ!

ਮੇਰਾ ਨਾਮ ਮੈਕਸਿਮ ਪੋਨੋਮਾਰੇਂਕੋ ਹੈ ਅਤੇ ਮੈਂ ਸਪੋਰਟਮਾਸਟਰ ਵਿੱਚ ਇੱਕ ਡਿਵੈਲਪਰ ਹਾਂ। ਮੇਰੇ ਕੋਲ IT ਖੇਤਰ ਵਿੱਚ 10 ਸਾਲਾਂ ਦਾ ਤਜਰਬਾ ਹੈ। ਉਸਨੇ ਆਪਣਾ ਕਰੀਅਰ ਮੈਨੂਅਲ ਟੈਸਟਿੰਗ ਵਿੱਚ ਸ਼ੁਰੂ ਕੀਤਾ, ਫਿਰ ਡੇਟਾਬੇਸ ਵਿਕਾਸ ਵਿੱਚ ਬਦਲਿਆ। ਪਿਛਲੇ 4 ਸਾਲਾਂ ਤੋਂ, ਟੈਸਟਿੰਗ ਅਤੇ ਵਿਕਾਸ ਵਿੱਚ ਪ੍ਰਾਪਤ ਗਿਆਨ ਨੂੰ ਇਕੱਠਾ ਕਰਦੇ ਹੋਏ, ਮੈਂ DBMS ਪੱਧਰ 'ਤੇ ਆਟੋਮੈਟਿਕ ਟੈਸਟਿੰਗ ਕਰ ਰਿਹਾ ਹਾਂ।

ਮੈਂ ਸਿਰਫ਼ ਇੱਕ ਸਾਲ ਤੋਂ ਸਪੋਰਟਮਾਸਟਰ ਟੀਮ ਵਿੱਚ ਹਾਂ ਅਤੇ ਇੱਕ ਵੱਡੇ ਪ੍ਰੋਜੈਕਟ 'ਤੇ ਸਵੈਚਲਿਤ ਟੈਸਟਿੰਗ ਵਿਕਸਿਤ ਕਰ ਰਿਹਾ ਹਾਂ। ਅਪ੍ਰੈਲ ਵਿੱਚ, ਸਪੋਰਟਮਾਸਟਰ ਲੈਬ ਦੇ ਮੁੰਡਿਆਂ ਅਤੇ ਮੈਂ ਕ੍ਰਾਸਨੋਦਰ ਵਿੱਚ ਇੱਕ ਕਾਨਫਰੰਸ ਵਿੱਚ ਗੱਲ ਕੀਤੀ, ਮੇਰੀ ਰਿਪੋਰਟ ਨੂੰ "ਡੀਬੀਐਮਐਸ ਵਿੱਚ ਯੂਨਿਟ ਟੈਸਟ" ਕਿਹਾ ਗਿਆ ਸੀ ਅਤੇ ਹੁਣ ਮੈਂ ਇਸਨੂੰ ਤੁਹਾਡੇ ਨਾਲ ਸਾਂਝਾ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹਾਂ। ਇੱਥੇ ਬਹੁਤ ਸਾਰਾ ਟੈਕਸਟ ਹੋਵੇਗਾ, ਇਸਲਈ ਮੈਂ ਰਿਪੋਰਟ ਨੂੰ ਦੋ ਪੋਸਟਾਂ ਵਿੱਚ ਵੰਡਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ। ਪਹਿਲੇ ਵਿੱਚ, ਅਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਆਟੋਟੈਸਟਾਂ ਅਤੇ ਟੈਸਟਿੰਗ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ, ਅਤੇ ਦੂਜੇ ਵਿੱਚ, ਮੈਂ ਸਾਡੀ ਯੂਨਿਟ ਟੈਸਟਿੰਗ ਪ੍ਰਣਾਲੀ ਅਤੇ ਇਸਦੇ ਉਪਯੋਗ ਦੇ ਨਤੀਜਿਆਂ 'ਤੇ ਵਧੇਰੇ ਵਿਸਤਾਰ ਵਿੱਚ ਵਿਚਾਰ ਕਰਾਂਗਾ।

ਪਹਿਲੀ, ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਬੋਰਿੰਗ ਥਿਊਰੀ. ਆਟੋਮੇਟਿਡ ਟੈਸਟਿੰਗ ਕੀ ਹੈ? ਇਹ ਉਹ ਟੈਸਟਿੰਗ ਹੈ ਜੋ ਸੌਫਟਵੇਅਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਆਧੁਨਿਕ ਆਈ.ਟੀ. ਵਿੱਚ ਇਹ ਸਾਫਟਵੇਅਰ ਵਿਕਾਸ ਵਿੱਚ ਤੇਜ਼ੀ ਨਾਲ ਵਰਤੀ ਜਾਂਦੀ ਹੈ। ਇਹ ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਹੈ ਕਿ ਕੰਪਨੀਆਂ ਵਧ ਰਹੀਆਂ ਹਨ, ਉਨ੍ਹਾਂ ਦੀਆਂ ਸੂਚਨਾ ਪ੍ਰਣਾਲੀਆਂ ਵਧ ਰਹੀਆਂ ਹਨ ਅਤੇ, ਇਸਦੇ ਅਨੁਸਾਰ, ਕਾਰਜਕੁਸ਼ਲਤਾ ਦੀ ਮਾਤਰਾ ਜਿਸਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਵਧ ਰਹੀ ਹੈ. ਮੈਨੁਅਲ ਟੈਸਟਿੰਗ ਕਰਵਾਉਣਾ ਮਹਿੰਗਾ ਹੁੰਦਾ ਜਾ ਰਿਹਾ ਹੈ।

ਮੈਂ ਇੱਕ ਵੱਡੀ ਕੰਪਨੀ ਲਈ ਕੰਮ ਕੀਤਾ ਜਿਸਦੀ ਰੀਲੀਜ਼ ਹਰ ਦੋ ਮਹੀਨੇ ਬਾਅਦ ਆਉਂਦੀ ਹੈ। ਉਸੇ ਸਮੇਂ, ਇੱਕ ਦਰਜਨ ਟੈਸਟਰਾਂ ਨੂੰ ਹੱਥੀਂ ਕਾਰਜਸ਼ੀਲਤਾ ਦੀ ਜਾਂਚ ਕਰਨ 'ਤੇ ਪੂਰਾ ਮਹੀਨਾ ਖਰਚਿਆ ਗਿਆ ਸੀ। ਡਿਵੈਲਪਰਾਂ ਦੀ ਇੱਕ ਛੋਟੀ ਟੀਮ ਦੁਆਰਾ ਆਟੋਮੇਸ਼ਨ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਧੰਨਵਾਦ, ਅਸੀਂ ਡੇਢ ਸਾਲ ਵਿੱਚ ਟੈਸਟਿੰਗ ਦੇ ਸਮੇਂ ਨੂੰ 2 ਹਫ਼ਤਿਆਂ ਤੱਕ ਘਟਾਉਣ ਦੇ ਯੋਗ ਹੋ ਗਏ। ਅਸੀਂ ਨਾ ਸਿਰਫ ਟੈਸਟਿੰਗ ਦੀ ਗਤੀ ਵਧਾਈ ਹੈ, ਸਗੋਂ ਇਸਦੀ ਗੁਣਵੱਤਾ ਵਿੱਚ ਵੀ ਸੁਧਾਰ ਕੀਤਾ ਹੈ। ਸਵੈਚਲਿਤ ਟੈਸਟਾਂ ਨੂੰ ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ ਲਾਂਚ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਉਹ ਹਮੇਸ਼ਾ ਉਹਨਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੇ ਗਏ ਚੈਕਾਂ ਦੇ ਪੂਰੇ ਕੋਰਸ ਨੂੰ ਪੂਰਾ ਕਰਦੇ ਹਨ, ਯਾਨੀ ਅਸੀਂ ਮਨੁੱਖੀ ਕਾਰਕ ਨੂੰ ਬਾਹਰ ਰੱਖਦੇ ਹਾਂ।

ਆਧੁਨਿਕ ਆਈ.ਟੀ. ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਇਸ ਤੱਥ ਦੁਆਰਾ ਹੈ ਕਿ ਇੱਕ ਡਿਵੈਲਪਰ ਨੂੰ ਨਾ ਸਿਰਫ਼ ਉਤਪਾਦ ਕੋਡ ਲਿਖਣ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ, ਸਗੋਂ ਇਸ ਕੋਡ ਦੀ ਜਾਂਚ ਕਰਨ ਵਾਲੇ ਯੂਨਿਟ ਟੈਸਟਾਂ ਨੂੰ ਵੀ ਲਿਖਣਾ ਪੈ ਸਕਦਾ ਹੈ।

ਪਰ ਕੀ ਜੇ ਤੁਹਾਡਾ ਸਿਸਟਮ ਮੁੱਖ ਤੌਰ 'ਤੇ ਸਰਵਰ ਤਰਕ 'ਤੇ ਅਧਾਰਤ ਹੈ? ਮਾਰਕੀਟ 'ਤੇ ਕੋਈ ਸਰਵ ਵਿਆਪਕ ਹੱਲ ਜਾਂ ਵਧੀਆ ਅਭਿਆਸ ਨਹੀਂ ਹੈ। ਇੱਕ ਨਿਯਮ ਦੇ ਤੌਰ 'ਤੇ, ਕੰਪਨੀਆਂ ਆਪਣੀ ਸਵੈ-ਲਿਖਤ ਜਾਂਚ ਪ੍ਰਣਾਲੀ ਬਣਾ ਕੇ ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਦੀਆਂ ਹਨ। ਇਹ ਸਾਡਾ ਆਪਣਾ ਸਵੈ-ਲਿਖਤ ਆਟੋਮੇਟਿਡ ਟੈਸਟਿੰਗ ਸਿਸਟਮ ਹੈ ਜੋ ਸਾਡੇ ਪ੍ਰੋਜੈਕਟ 'ਤੇ ਬਣਾਇਆ ਗਿਆ ਸੀ ਅਤੇ ਮੈਂ ਆਪਣੀ ਰਿਪੋਰਟ ਵਿੱਚ ਇਸ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗਾ।

ਵਫ਼ਾਦਾਰੀ ਦੀ ਜਾਂਚ

ਪਹਿਲਾਂ, ਆਓ ਉਸ ਪ੍ਰੋਜੈਕਟ ਬਾਰੇ ਗੱਲ ਕਰੀਏ ਜਿੱਥੇ ਅਸੀਂ ਇੱਕ ਸਵੈਚਲਿਤ ਟੈਸਟਿੰਗ ਸਿਸਟਮ ਲਗਾਇਆ ਹੈ। ਸਾਡਾ ਪ੍ਰੋਜੈਕਟ ਸਪੋਰਟਮਾਸਟਰ ਵਫ਼ਾਦਾਰੀ ਪ੍ਰਣਾਲੀ ਹੈ (ਉਸੇ ਤਰ੍ਹਾਂ, ਅਸੀਂ ਇਸ ਬਾਰੇ ਪਹਿਲਾਂ ਹੀ ਲਿਖਿਆ ਹੈ ਇਹ ਪੋਸਟ).

ਜੇਕਰ ਤੁਹਾਡੀ ਕੰਪਨੀ ਕਾਫ਼ੀ ਵੱਡੀ ਹੈ, ਤਾਂ ਤੁਹਾਡੀ ਵਫ਼ਾਦਾਰੀ ਪ੍ਰਣਾਲੀ ਵਿੱਚ ਤਿੰਨ ਮਿਆਰੀ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹੋਣਗੀਆਂ:

• ਤੁਹਾਡਾ ਸਿਸਟਮ ਬਹੁਤ ਜ਼ਿਆਦਾ ਲੋਡ ਕੀਤਾ ਜਾਵੇਗਾ
• ਤੁਹਾਡੇ ਸਿਸਟਮ ਵਿੱਚ ਗੁੰਝਲਦਾਰ ਕੰਪਿਊਟਿੰਗ ਪ੍ਰਕਿਰਿਆਵਾਂ ਸ਼ਾਮਲ ਹੋਣਗੀਆਂ
• ਤੁਹਾਡੇ ਸਿਸਟਮ ਨੂੰ ਸਰਗਰਮੀ ਨਾਲ ਸੁਧਾਰਿਆ ਜਾਵੇਗਾ।

ਚਲੋ ਕ੍ਰਮ ਵਿੱਚ ਚੱਲੋ... ਕੁੱਲ ਮਿਲਾ ਕੇ, ਜੇਕਰ ਅਸੀਂ ਸਾਰੇ ਸਪੋਰਟਮਾਸਟਰ ਬ੍ਰਾਂਡਾਂ 'ਤੇ ਵਿਚਾਰ ਕਰੀਏ, ਤਾਂ ਸਾਡੇ ਕੋਲ ਰੂਸ, ਯੂਕਰੇਨ, ਚੀਨ, ਕਜ਼ਾਕਿਸਤਾਨ ਅਤੇ ਬੇਲਾਰੂਸ ਵਿੱਚ 1000 ਤੋਂ ਵੱਧ ਸਟੋਰ ਹਨ। ਇਨ੍ਹਾਂ ਸਟੋਰਾਂ ਵਿੱਚ ਹਰ ਰੋਜ਼ ਲਗਭਗ 300 ਖਰੀਦਦਾਰੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਭਾਵ, ਹਰ ਸਕਿੰਟ 000-3 ਜਾਂਚਾਂ ਸਾਡੇ ਸਿਸਟਮ ਵਿੱਚ ਦਾਖਲ ਹੁੰਦੀਆਂ ਹਨ। ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ, ਸਾਡੀ ਵਫ਼ਾਦਾਰੀ ਪ੍ਰਣਾਲੀ ਬਹੁਤ ਜ਼ਿਆਦਾ ਲੋਡ ਹੁੰਦੀ ਹੈ। ਅਤੇ ਕਿਉਂਕਿ ਇਹ ਸਰਗਰਮੀ ਨਾਲ ਵਰਤੀ ਜਾਂਦੀ ਹੈ, ਸਾਨੂੰ ਇਸਦੀ ਗੁਣਵੱਤਾ ਦੇ ਉੱਚਤਮ ਮਾਪਦੰਡ ਪ੍ਰਦਾਨ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ, ਕਿਉਂਕਿ ਸੌਫਟਵੇਅਰ ਵਿੱਚ ਕਿਸੇ ਵੀ ਤਰੁੱਟੀ ਦਾ ਅਰਥ ਹੈ ਵੱਡੇ ਵਿੱਤੀ, ਪ੍ਰਤਿਸ਼ਠਾਤਮਕ ਅਤੇ ਹੋਰ ਨੁਕਸਾਨ।

ਉਸੇ ਸਮੇਂ, ਸਪੋਰਟਮਾਸਟਰ ਸੌ ਤੋਂ ਵੱਧ ਵੱਖ-ਵੱਖ ਤਰੱਕੀਆਂ ਚਲਾਉਂਦਾ ਹੈ. ਇੱਥੇ ਕਈ ਤਰ੍ਹਾਂ ਦੀਆਂ ਤਰੱਕੀਆਂ ਹਨ: ਇੱਥੇ ਉਤਪਾਦ ਪ੍ਰੋਮੋਸ਼ਨ ਹਨ, ਹਫ਼ਤੇ ਦੇ ਦਿਨ ਨੂੰ ਸਮਰਪਿਤ ਹਨ, ਇੱਕ ਖਾਸ ਸਟੋਰ ਨਾਲ ਜੁੜੇ ਹੋਏ ਹਨ, ਰਸੀਦ ਦੀ ਮਾਤਰਾ ਲਈ ਤਰੱਕੀਆਂ ਹਨ, ਸਾਮਾਨ ਦੀ ਸੰਖਿਆ ਲਈ ਹਨ। ਆਮ ਤੌਰ 'ਤੇ, ਬੁਰਾ ਨਹੀਂ. ਗਾਹਕਾਂ ਕੋਲ ਬੋਨਸ ਅਤੇ ਪ੍ਰੋਮੋਸ਼ਨਲ ਕੋਡ ਹੁੰਦੇ ਹਨ ਜੋ ਖਰੀਦਦਾਰੀ ਕਰਨ ਵੇਲੇ ਵਰਤੇ ਜਾਂਦੇ ਹਨ। ਇਹ ਸਭ ਇਸ ਤੱਥ ਵੱਲ ਲੈ ਜਾਂਦਾ ਹੈ ਕਿ ਕਿਸੇ ਵੀ ਆਦੇਸ਼ ਦੀ ਗਣਨਾ ਕਰਨਾ ਇੱਕ ਬਹੁਤ ਹੀ ਗੈਰ-ਮਾਮੂਲੀ ਕੰਮ ਹੈ.

ਆਰਡਰ ਪ੍ਰੋਸੈਸਿੰਗ ਨੂੰ ਲਾਗੂ ਕਰਨ ਵਾਲਾ ਐਲਗੋਰਿਦਮ ਸੱਚਮੁੱਚ ਭਿਆਨਕ ਅਤੇ ਗੁੰਝਲਦਾਰ ਹੈ। ਅਤੇ ਇਸ ਐਲਗੋਰਿਦਮ ਵਿੱਚ ਕੋਈ ਵੀ ਬਦਲਾਅ ਕਾਫ਼ੀ ਖ਼ਤਰਨਾਕ ਹਨ। ਇਹ ਜਾਪਦਾ ਸੀ ਕਿ ਸਭ ਤੋਂ ਵੱਧ ਪ੍ਰਤੀਤ ਹੋਣ ਵਾਲੀਆਂ ਮਾਮੂਲੀ ਤਬਦੀਲੀਆਂ ਕਾਫ਼ੀ ਅਣਪਛਾਤੇ ਪ੍ਰਭਾਵਾਂ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦੀਆਂ ਹਨ. ਪਰ ਇਹ ਬਿਲਕੁਲ ਅਜਿਹੀਆਂ ਗੁੰਝਲਦਾਰ ਕੰਪਿਊਟਿੰਗ ਪ੍ਰਕਿਰਿਆਵਾਂ ਹਨ, ਖਾਸ ਤੌਰ 'ਤੇ ਉਹ ਜੋ ਨਾਜ਼ੁਕ ਕਾਰਜਸ਼ੀਲਤਾ ਨੂੰ ਲਾਗੂ ਕਰਦੀਆਂ ਹਨ, ਜੋ ਆਟੋਮੇਸ਼ਨ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ ਉਮੀਦਵਾਰ ਹਨ। ਅਜਿਹੇ ਦਰਜਨਾਂ ਕੇਸਾਂ ਦੀ ਹੱਥੀਂ ਜਾਂਚ ਕਰਨਾ ਬਹੁਤ ਸਮਾਂ ਲੈਣ ਵਾਲਾ ਹੈ। ਅਤੇ ਕਿਉਂਕਿ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਦਾਖਲਾ ਬਿੰਦੂ ਬਦਲਿਆ ਨਹੀਂ ਹੈ, ਇਸ ਨੂੰ ਇੱਕ ਵਾਰ ਵਰਣਨ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਤੁਸੀਂ ਜਲਦੀ ਆਟੋਮੈਟਿਕ ਟੈਸਟ ਬਣਾ ਸਕਦੇ ਹੋ ਅਤੇ ਭਰੋਸਾ ਰੱਖ ਸਕਦੇ ਹੋ ਕਿ ਕਾਰਜਕੁਸ਼ਲਤਾ ਕੰਮ ਕਰੇਗੀ।

ਕਿਉਂਕਿ ਸਾਡੇ ਸਿਸਟਮ ਦੀ ਸਰਗਰਮੀ ਨਾਲ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਕਾਰੋਬਾਰ ਤੁਹਾਡੇ ਤੋਂ ਕੁਝ ਨਵਾਂ ਚਾਹੁੰਦਾ ਹੈ, ਸਮੇਂ ਦੇ ਨਾਲ ਜੀਉਂਦਾ ਹੈ ਅਤੇ ਗਾਹਕ-ਅਧਾਰਿਤ ਹੋਣਾ ਚਾਹੁੰਦਾ ਹੈ। ਸਾਡੀ ਵਫ਼ਾਦਾਰੀ ਪ੍ਰਣਾਲੀ ਵਿੱਚ, ਰੀਲੀਜ਼ ਹਰ ਦੋ ਮਹੀਨਿਆਂ ਵਿੱਚ ਬਾਹਰ ਆਉਂਦੀਆਂ ਹਨ। ਇਸ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਹਰ ਦੋ ਮਹੀਨਿਆਂ ਬਾਅਦ ਸਾਨੂੰ ਪੂਰੇ ਸਿਸਟਮ ਦੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਰੀਗਰੈਸ਼ਨ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਉਸੇ ਸਮੇਂ, ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ, ਜਿਵੇਂ ਕਿ ਕਿਸੇ ਵੀ ਆਧੁਨਿਕ ਆਈਟੀ ਵਿੱਚ, ਵਿਕਾਸ ਤੁਰੰਤ ਵਿਕਾਸਕਾਰ ਤੋਂ ਉਤਪਾਦਨ ਤੱਕ ਨਹੀਂ ਜਾਂਦਾ ਹੈ। ਇਹ ਡਿਵੈਲਪਰ ਦੇ ਸਰਕਟ ਤੋਂ ਉਤਪੰਨ ਹੁੰਦਾ ਹੈ, ਫਿਰ ਟੈਸਟ ਬੈਂਚ, ਰੀਲੀਜ਼, ਸਵੀਕ੍ਰਿਤੀ, ਅਤੇ ਕੇਵਲ ਤਦ ਹੀ ਉਤਪਾਦਨ ਵਿੱਚ ਖਤਮ ਹੁੰਦਾ ਹੈ। ਘੱਟੋ-ਘੱਟ, ਟੈਸਟ ਅਤੇ ਰੀਲੀਜ਼ ਸਰਕਟਾਂ 'ਤੇ, ਸਾਨੂੰ ਪੂਰੇ ਸਿਸਟਮ ਦੀ ਪੂਰੀ ਰੀਗਰੈਸ਼ਨ ਨੂੰ ਪੂਰਾ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਵਰਣਿਤ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਲਗਭਗ ਕਿਸੇ ਵੀ ਵਫ਼ਾਦਾਰੀ ਪ੍ਰਣਾਲੀ ਲਈ ਮਿਆਰੀ ਹਨ। ਆਉ ਸਾਡੇ ਪ੍ਰੋਜੈਕਟ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਬਾਰੇ ਗੱਲ ਕਰੀਏ.

ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ, ਸਾਡੀ ਵਫ਼ਾਦਾਰੀ ਪ੍ਰਣਾਲੀ ਦਾ 90% ਤਰਕ ਸਰਵਰ-ਅਧਾਰਿਤ ਹੈ ਅਤੇ ਓਰੇਕਲ 'ਤੇ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ। ਡੇਲਫੀ ਵਿੱਚ ਇੱਕ ਕਲਾਇੰਟ ਦਾ ਪਰਦਾਫਾਸ਼ ਕੀਤਾ ਗਿਆ ਹੈ, ਜੋ ਇੱਕ ਸਵੈਚਲਿਤ ਕਾਰਜ ਸਥਾਨ ਪ੍ਰਸ਼ਾਸਕ ਦਾ ਕੰਮ ਕਰਦਾ ਹੈ। ਬਾਹਰੀ ਐਪਲੀਕੇਸ਼ਨਾਂ (ਉਦਾਹਰਨ ਲਈ ਇੱਕ ਵੈੱਬਸਾਈਟ) ਲਈ ਉਜਾਗਰ ਕੀਤੀਆਂ ਵੈੱਬ ਸੇਵਾਵਾਂ ਹਨ। ਇਸ ਲਈ, ਇਹ ਬਹੁਤ ਤਰਕਸੰਗਤ ਹੈ ਕਿ ਜੇਕਰ ਅਸੀਂ ਇੱਕ ਸਵੈਚਲਿਤ ਟੈਸਟਿੰਗ ਪ੍ਰਣਾਲੀ ਨੂੰ ਤੈਨਾਤ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਇਸਨੂੰ ਓਰੇਕਲ 'ਤੇ ਕਰਾਂਗੇ।

ਸਪੋਰਟਮਾਸਟਰ ਵਿੱਚ ਵਫ਼ਾਦਾਰੀ ਪ੍ਰਣਾਲੀ 7 ਸਾਲਾਂ ਤੋਂ ਵੱਧ ਸਮੇਂ ਤੋਂ ਮੌਜੂਦ ਹੈ ਅਤੇ ਇੱਕਲੇ ਡਿਵੈਲਪਰਾਂ ਦੁਆਰਾ ਬਣਾਈ ਗਈ ਸੀ... ਇਹਨਾਂ 7 ਸਾਲਾਂ ਦੌਰਾਨ ਸਾਡੇ ਪ੍ਰੋਜੈਕਟ 'ਤੇ ਵਿਕਾਸਕਾਰਾਂ ਦੀ ਔਸਤ ਸੰਖਿਆ 3-4 ਲੋਕ ਸੀ। ਪਰ ਪਿਛਲੇ ਸਾਲ ਵਿੱਚ, ਸਾਡੀ ਟੀਮ ਵਿੱਚ ਕਾਫ਼ੀ ਵਾਧਾ ਹੋਇਆ ਹੈ, ਅਤੇ ਹੁਣ ਇਸ ਪ੍ਰੋਜੈਕਟ 'ਤੇ 10 ਲੋਕ ਕੰਮ ਕਰ ਰਹੇ ਹਨ। ਭਾਵ, ਉਹ ਲੋਕ ਪ੍ਰੋਜੈਕਟ ਤੇ ਆਉਂਦੇ ਹਨ ਜੋ ਆਮ ਕੰਮਾਂ, ਪ੍ਰਕਿਰਿਆਵਾਂ ਅਤੇ ਆਰਕੀਟੈਕਚਰ ਤੋਂ ਜਾਣੂ ਨਹੀਂ ਹੁੰਦੇ ਹਨ। ਅਤੇ ਇੱਕ ਵਧਿਆ ਹੋਇਆ ਖਤਰਾ ਹੈ ਕਿ ਅਸੀਂ ਗਲਤੀਆਂ ਤੋਂ ਖੁੰਝ ਜਾਵਾਂਗੇ.

ਪ੍ਰੋਜੈਕਟ ਸਟਾਫ ਯੂਨਿਟਾਂ ਵਜੋਂ ਸਮਰਪਿਤ ਟੈਸਟਰਾਂ ਦੀ ਅਣਹੋਂਦ ਦੁਆਰਾ ਦਰਸਾਇਆ ਗਿਆ ਹੈ। ਬੇਸ਼ੱਕ, ਟੈਸਟਿੰਗ ਹੁੰਦੀ ਹੈ, ਪਰ ਜਾਂਚ ਵਿਸ਼ਲੇਸ਼ਕਾਂ ਦੁਆਰਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਉਹਨਾਂ ਦੀਆਂ ਹੋਰ ਮੁੱਖ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਤੋਂ ਇਲਾਵਾ: ਵਪਾਰਕ ਗਾਹਕਾਂ, ਉਪਭੋਗਤਾਵਾਂ ਨਾਲ ਸੰਚਾਰ ਕਰਨਾ, ਸਿਸਟਮ ਲੋੜਾਂ ਦਾ ਵਿਕਾਸ ਕਰਨਾ, ਆਦਿ। ਆਦਿ... ਇਸ ਤੱਥ ਦੇ ਬਾਵਜੂਦ ਕਿ ਟੈਸਟਿੰਗ ਬਹੁਤ ਉੱਚ ਗੁਣਵੱਤਾ ਵਿੱਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ (ਇਹ ਜ਼ਿਕਰ ਕਰਨਾ ਖਾਸ ਤੌਰ 'ਤੇ ਉਚਿਤ ਹੈ, ਕਿਉਂਕਿ ਕੁਝ ਵਿਸ਼ਲੇਸ਼ਕ ਇਸ ਰਿਪੋਰਟ ਨੂੰ ਦੇਖ ਸਕਦੇ ਹਨ), ਇੱਕ ਚੀਜ਼ 'ਤੇ ਵਿਸ਼ੇਸ਼ਤਾ ਅਤੇ ਇਕਾਗਰਤਾ ਦੀ ਪ੍ਰਭਾਵਸ਼ੀਲਤਾ ਨੂੰ ਰੱਦ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ. .

ਉਪਰੋਕਤ ਸਭ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ, ਡਿਲੀਵਰ ਕੀਤੇ ਉਤਪਾਦ ਦੀ ਗੁਣਵੱਤਾ ਵਿੱਚ ਸੁਧਾਰ ਕਰਨ ਅਤੇ ਵਿਕਾਸ ਦੇ ਸਮੇਂ ਨੂੰ ਘਟਾਉਣ ਲਈ, ਇੱਕ ਪ੍ਰੋਜੈਕਟ 'ਤੇ ਆਟੋਮੈਟਿਕ ਟੈਸਟਿੰਗ ਦਾ ਵਿਚਾਰ ਬਹੁਤ ਤਰਕਪੂਰਨ ਲੱਗਦਾ ਹੈ। ਅਤੇ ਵਫ਼ਾਦਾਰੀ ਪ੍ਰਣਾਲੀ ਦੀ ਹੋਂਦ ਦੇ ਵੱਖ-ਵੱਖ ਪੜਾਵਾਂ 'ਤੇ, ਵਿਅਕਤੀਗਤ ਡਿਵੈਲਪਰਾਂ ਨੇ ਆਪਣੇ ਕੋਡ ਨੂੰ ਯੂਨਿਟ ਟੈਸਟਾਂ ਨਾਲ ਕਵਰ ਕਰਨ ਦੇ ਯਤਨ ਕੀਤੇ। ਸਮੁੱਚੇ ਤੌਰ 'ਤੇ ਇਹ ਇੱਕ ਕਾਫ਼ੀ ਅਸੰਬੰਧਿਤ ਪ੍ਰਕਿਰਿਆ ਸੀ, ਜਿਸ ਵਿੱਚ ਹਰ ਕੋਈ ਆਪਣੇ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਢੰਗਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਸੀ। ਅੰਤਿਮ ਨਤੀਜੇ ਯੂਨਿਟ ਟੈਸਟਾਂ ਲਈ ਆਮ ਸਨ: ਟੈਸਟ ਵਿਕਸਿਤ ਕੀਤੇ ਗਏ ਸਨ, ਕੁਝ ਸਮੇਂ ਲਈ ਵਰਤੇ ਗਏ ਸਨ, ਇੱਕ ਵਰਜਨਡ ਫਾਈਲ ਸਟੋਰੇਜ ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ਗਏ ਸਨ, ਪਰ ਕਿਸੇ ਸਮੇਂ ਉਹ ਚੱਲਣਾ ਬੰਦ ਹੋ ਗਏ ਸਨ ਅਤੇ ਭੁੱਲ ਗਏ ਸਨ। ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਸੀ ਕਿ ਟੈਸਟਾਂ ਨੂੰ ਇੱਕ ਖਾਸ ਕਲਾਕਾਰ ਨਾਲ ਜੋੜਿਆ ਗਿਆ ਸੀ, ਨਾ ਕਿ ਪ੍ਰੋਜੈਕਟ ਨਾਲ.

utPLSQL ਬਚਾਅ ਲਈ ਆਉਂਦਾ ਹੈ

ਕੀ ਤੁਸੀਂ ਸਟੀਫਨ ਫਿਊਰਸਟਾਈਨ ਬਾਰੇ ਕੁਝ ਜਾਣਦੇ ਹੋ?

ਇਹ ਇੱਕ ਹੁਸ਼ਿਆਰ ਵਿਅਕਤੀ ਹੈ ਜਿਸਨੇ ਆਪਣੇ ਕੈਰੀਅਰ ਦਾ ਇੱਕ ਲੰਮਾ ਹਿੱਸਾ ਓਰੇਕਲ ਅਤੇ PL/SQL ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਸਮਰਪਿਤ ਕੀਤਾ, ਅਤੇ ਇਸ ਵਿਸ਼ੇ 'ਤੇ ਕਾਫ਼ੀ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਰਚਨਾਵਾਂ ਲਿਖੀਆਂ ਹਨ। ਉਸਦੀਆਂ ਮਸ਼ਹੂਰ ਕਿਤਾਬਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਕਿਹਾ ਜਾਂਦਾ ਹੈ: "ਓਰੇਕਲ PL/SQL. ਪੇਸ਼ੇਵਰਾਂ ਲਈ।" ਇਹ ਸਟੀਫਨ ਸੀ ਜਿਸ ਨੇ utPLSQL ਹੱਲ ਵਿਕਸਿਤ ਕੀਤਾ, ਜਾਂ, ਜਿਵੇਂ ਕਿ ਇਸਦਾ ਅਰਥ ਹੈ, Oracle PL/SQL ਲਈ ਯੂਨਿਟ ਟੈਸਟਿੰਗ ਫਰੇਮਵਰਕ। utPLSQL ਹੱਲ 2016 ਵਿੱਚ ਬਣਾਇਆ ਗਿਆ ਸੀ, ਪਰ ਇਸ 'ਤੇ ਸਰਗਰਮੀ ਨਾਲ ਕੰਮ ਕਰਨਾ ਜਾਰੀ ਹੈ ਅਤੇ ਨਵੇਂ ਸੰਸਕਰਣ ਜਾਰੀ ਕੀਤੇ ਗਏ ਹਨ। ਰਿਪੋਰਟਿੰਗ ਦੇ ਸਮੇਂ, ਨਵੀਨਤਮ ਸੰਸਕਰਣ 24 ਮਾਰਚ, 2019 ਦਾ ਹੈ।
ਇਹ ਕੀ ਹੈ. ਇਹ ਇੱਕ ਵੱਖਰਾ ਓਪਨ ਸੋਰਸ ਪ੍ਰੋਜੈਕਟ ਹੈ। ਇਸਦਾ ਭਾਰ ਕੁਝ ਮੈਗਾਬਾਈਟ ਹੈ, ਉਦਾਹਰਣਾਂ ਅਤੇ ਦਸਤਾਵੇਜ਼ਾਂ ਸਮੇਤ। ਭੌਤਿਕ ਤੌਰ 'ਤੇ, ਇਹ ORACLE ਡੇਟਾਬੇਸ ਵਿੱਚ ਯੂਨਿਟ ਟੈਸਟਿੰਗ ਦੇ ਆਯੋਜਨ ਲਈ ਪੈਕੇਜਾਂ ਅਤੇ ਟੇਬਲਾਂ ਦੇ ਸਮੂਹ ਦੇ ਨਾਲ ਇੱਕ ਵੱਖਰੀ ਸਕੀਮਾ ਹੈ। ਇੰਸਟਾਲੇਸ਼ਨ ਵਿੱਚ ਕੁਝ ਸਕਿੰਟ ਲੱਗਦੇ ਹਨ। utPLSQL ਦੀ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਵਿਸ਼ੇਸ਼ਤਾ ਇਸਦੀ ਵਰਤੋਂ ਦੀ ਸੌਖ ਹੈ।
ਵਿਸ਼ਵ ਪੱਧਰ 'ਤੇ, utPLSQL ਯੂਨਿਟ ਟੈਸਟਾਂ ਨੂੰ ਚਲਾਉਣ ਲਈ ਇੱਕ ਵਿਧੀ ਹੈ, ਜਿੱਥੇ ਇੱਕ ਯੂਨਿਟ ਟੈਸਟ ਨੂੰ ਆਮ ਓਰੇਕਲ ਬੈਚ ਪ੍ਰਕਿਰਿਆਵਾਂ ਵਜੋਂ ਸਮਝਿਆ ਜਾਂਦਾ ਹੈ, ਜਿਸਦਾ ਸੰਗਠਨ ਕੁਝ ਨਿਯਮਾਂ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ। ਲਾਂਚ ਕਰਨ ਤੋਂ ਇਲਾਵਾ, utPLSQL ਤੁਹਾਡੇ ਸਾਰੇ ਟੈਸਟ ਰਨ ਦਾ ਇੱਕ ਲੌਗ ਸਟੋਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਅੰਦਰੂਨੀ ਰਿਪੋਰਟਿੰਗ ਸਿਸਟਮ ਵੀ ਹੈ।

ਆਉ ਇਸ ਤਕਨੀਕ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਲਾਗੂ ਕੀਤੇ ਯੂਨਿਟ ਟੈਸਟ ਕੋਡ ਕਿਸ ਤਰ੍ਹਾਂ ਦਾ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਇਸਦੀ ਇੱਕ ਉਦਾਹਰਨ ਵੇਖੀਏ।

ਇਸ ਲਈ, ਸਕਰੀਨ ਯੂਨਿਟ ਟੈਸਟਾਂ ਦੇ ਨਾਲ ਇੱਕ ਆਮ ਪੈਕੇਜ ਨਿਰਧਾਰਨ ਲਈ ਕੋਡ ਦਿਖਾਉਂਦਾ ਹੈ। ਲਾਜ਼ਮੀ ਲੋੜਾਂ ਕੀ ਹਨ? ਪੈਕੇਟ ਨੂੰ "utp_" ਨਾਲ ਪ੍ਰੀਫਿਕਸ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਟੈਸਟਾਂ ਵਾਲੀਆਂ ਸਾਰੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦਾ ਬਿਲਕੁਲ ਉਹੀ ਅਗੇਤਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਪੈਕੇਜ ਵਿੱਚ ਦੋ ਮਿਆਰੀ ਪ੍ਰਕਿਰਿਆਵਾਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ: “utp_setup” ਅਤੇ “utp_teardown”। ਪਹਿਲੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਹਰੇਕ ਯੂਨਿਟ ਟੈਸਟ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਕੇ ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਦੂਜੀ - ਲਾਂਚ ਤੋਂ ਬਾਅਦ।

“utp_setup”, ਇੱਕ ਨਿਯਮ ਦੇ ਤੌਰ ਤੇ, ਸਾਡੇ ਸਿਸਟਮ ਨੂੰ ਯੂਨਿਟ ਟੈਸਟ ਚਲਾਉਣ ਲਈ ਤਿਆਰ ਕਰਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਟੈਸਟ ਡੇਟਾ ਬਣਾਉਣਾ। "utp_teardown" - ਇਸਦੇ ਉਲਟ, ਸਭ ਕੁਝ ਅਸਲ ਸੈਟਿੰਗਾਂ 'ਤੇ ਵਾਪਸ ਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਲਾਂਚ ਨਤੀਜਿਆਂ ਨੂੰ ਰੀਸੈਟ ਕਰਦਾ ਹੈ।

ਇੱਥੇ ਸਭ ਤੋਂ ਸਰਲ ਯੂਨਿਟ ਟੈਸਟ ਦਾ ਇੱਕ ਉਦਾਹਰਨ ਹੈ ਜੋ ਸਾਡੇ ਵਫ਼ਾਦਾਰੀ ਸਿਸਟਮ ਲਈ ਮਿਆਰੀ ਫਾਰਮ ਵਿੱਚ ਦਾਖਲ ਕੀਤੇ ਗਏ ਗਾਹਕ ਫ਼ੋਨ ਨੰਬਰ ਦੇ ਸਧਾਰਣਕਰਨ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ। ਯੂਨਿਟ ਟੈਸਟਾਂ ਨਾਲ ਪ੍ਰਕਿਰਿਆਵਾਂ ਕਿਵੇਂ ਲਿਖਣੀਆਂ ਹਨ ਇਸ ਬਾਰੇ ਕੋਈ ਲਾਜ਼ਮੀ ਮਾਪਦੰਡ ਨਹੀਂ ਹਨ। ਇੱਕ ਨਿਯਮ ਦੇ ਤੌਰ 'ਤੇ, ਟੈਸਟ ਦੇ ਅਧੀਨ ਸਿਸਟਮ ਦੀ ਇੱਕ ਵਿਧੀ ਲਈ ਇੱਕ ਕਾਲ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਇਸ ਵਿਧੀ ਦੁਆਰਾ ਵਾਪਸ ਕੀਤੇ ਨਤੀਜੇ ਦੀ ਤੁਲਨਾ ਸੰਦਰਭ ਨਾਲ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਸੰਦਰਭ ਨਤੀਜੇ ਅਤੇ ਪ੍ਰਾਪਤ ਕੀਤੇ ਗਏ ਦੀ ਤੁਲਨਾ ਮਿਆਰੀ utPLSQL ਵਿਧੀਆਂ ਦੁਆਰਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

ਇੱਕ ਯੂਨਿਟ ਟੈਸਟ ਵਿੱਚ ਕਈ ਜਾਂਚਾਂ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਜਿਵੇਂ ਕਿ ਉਦਾਹਰਨ ਤੋਂ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਅਸੀਂ ਫ਼ੋਨ ਨੰਬਰ ਨੂੰ ਸਧਾਰਣ ਕਰਨ ਅਤੇ ਹਰੇਕ ਕਾਲ ਤੋਂ ਬਾਅਦ ਨਤੀਜੇ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨ ਲਈ ਟੈਸਟ ਕੀਤੇ ਢੰਗ ਨੂੰ ਲਗਾਤਾਰ ਚਾਰ ਕਾਲਾਂ ਕਰਦੇ ਹਾਂ। ਇੱਕ ਯੂਨਿਟ ਟੈਸਟ ਵਿਕਸਿਤ ਕਰਦੇ ਸਮੇਂ, ਤੁਹਾਨੂੰ ਇਹ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਅਜਿਹੀਆਂ ਜਾਂਚਾਂ ਹਨ ਜੋ ਸਿਸਟਮ ਨੂੰ ਕਿਸੇ ਵੀ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰਭਾਵਤ ਨਹੀਂ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਕੁਝ ਦੇ ਬਾਅਦ ਤੁਹਾਨੂੰ ਸਿਸਟਮ ਦੀ ਅਸਲ ਸਥਿਤੀ ਵਿੱਚ ਵਾਪਸ ਜਾਣ ਦੀ ਲੋੜ ਹੈ।
ਉਦਾਹਰਨ ਲਈ, ਪ੍ਰਸਤੁਤ ਯੂਨਿਟ ਟੈਸਟ ਵਿੱਚ ਅਸੀਂ ਸਿਰਫ਼ ਇਨਪੁਟ ਫ਼ੋਨ ਨੰਬਰ ਨੂੰ ਫਾਰਮੈਟ ਕਰਦੇ ਹਾਂ, ਜੋ ਕਿ ਕਿਸੇ ਵੀ ਤਰੀਕੇ ਨਾਲ ਵਫ਼ਾਦਾਰੀ ਪ੍ਰਣਾਲੀ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕਰਦਾ ਹੈ।

ਅਤੇ ਜੇਕਰ ਅਸੀਂ ਇੱਕ ਨਵਾਂ ਕਲਾਇੰਟ ਬਣਾਉਣ ਦੀ ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਯੂਨਿਟ ਟੈਸਟ ਲਿਖਦੇ ਹਾਂ, ਤਾਂ ਹਰੇਕ ਟੈਸਟ ਤੋਂ ਬਾਅਦ ਸਿਸਟਮ ਵਿੱਚ ਇੱਕ ਨਵਾਂ ਕਲਾਇੰਟ ਬਣਾਇਆ ਜਾਵੇਗਾ, ਜੋ ਕਿ ਟੈਸਟ ਦੇ ਬਾਅਦ ਦੇ ਲਾਂਚ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦਾ ਹੈ।

ਇਸ ਤਰ੍ਹਾਂ ਯੂਨਿਟ ਟੈਸਟ ਚਲਾਏ ਜਾਂਦੇ ਹਨ। ਦੋ ਸੰਭਾਵਿਤ ਲਾਂਚ ਵਿਕਲਪ ਹਨ: ਇੱਕ ਖਾਸ ਪੈਕੇਜ ਤੋਂ ਸਾਰੇ ਯੂਨਿਟ ਟੈਸਟ ਚਲਾਉਣਾ ਜਾਂ ਇੱਕ ਖਾਸ ਪੈਕੇਜ ਵਿੱਚ ਇੱਕ ਖਾਸ ਯੂਨਿਟ ਟੈਸਟ ਚਲਾਉਣਾ।

ਇਹ ਉਹ ਹੈ ਜੋ ਅੰਦਰੂਨੀ ਰਿਪੋਰਟਿੰਗ ਪ੍ਰਣਾਲੀ ਦੀ ਇੱਕ ਉਦਾਹਰਣ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ। ਯੂਨਿਟ ਟੈਸਟ ਦੇ ਨਤੀਜਿਆਂ ਦੇ ਆਧਾਰ 'ਤੇ, utPLSQL ਇੱਕ ਛੋਟੀ ਰਿਪੋਰਟ ਬਣਾਉਂਦਾ ਹੈ। ਇਸ ਵਿੱਚ ਅਸੀਂ ਹਰੇਕ ਖਾਸ ਜਾਂਚ ਦਾ ਨਤੀਜਾ ਅਤੇ ਯੂਨਿਟ ਟੈਸਟ ਦਾ ਸਮੁੱਚਾ ਨਤੀਜਾ ਦੇਖਦੇ ਹਾਂ।

ਆਟੋਟੈਸਟ ਦੇ 6 ਨਿਯਮ

ਪ੍ਰਬੰਧਨ ਦੇ ਨਾਲ ਮਿਲ ਕੇ, ਵਫ਼ਾਦਾਰੀ ਪ੍ਰਣਾਲੀ ਦੇ ਸਵੈਚਲਿਤ ਟੈਸਟਿੰਗ ਲਈ ਇੱਕ ਨਵਾਂ ਸਿਸਟਮ ਬਣਾਉਣਾ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਅਸੀਂ ਉਹਨਾਂ ਸਿਧਾਂਤਾਂ ਨੂੰ ਨਿਰਧਾਰਤ ਕੀਤਾ ਹੈ ਜੋ ਸਾਡੇ ਭਵਿੱਖ ਦੇ ਸਵੈਚਲਿਤ ਟੈਸਟਾਂ ਦੀ ਪਾਲਣਾ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।

1. ਆਟੋਟੈਸਟ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਅਤੇ ਉਪਯੋਗੀ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ. ਸਾਡੇ ਕੋਲ ਸ਼ਾਨਦਾਰ ਡਿਵੈਲਪਰ ਹਨ, ਜਿਨ੍ਹਾਂ ਦਾ ਨਿਸ਼ਚਤ ਤੌਰ 'ਤੇ ਜ਼ਿਕਰ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਕਿਉਂਕਿ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੁਝ ਸ਼ਾਇਦ ਇਸ ਰਿਪੋਰਟ ਨੂੰ ਦੇਖਣਗੇ, ਅਤੇ ਉਹ ਸ਼ਾਨਦਾਰ ਕੋਡ ਲਿਖਦੇ ਹਨ. ਪਰ ਇੱਥੋਂ ਤੱਕ ਕਿ ਉਹਨਾਂ ਦਾ ਸ਼ਾਨਦਾਰ ਕੋਡ ਸੰਪੂਰਨ ਨਹੀਂ ਹੈ ਅਤੇ ਇਸ ਵਿੱਚ ਗਲਤੀਆਂ ਹਨ, ਹਨ, ਅਤੇ ਜਾਰੀ ਰਹਿਣਗੀਆਂ। ਇਹਨਾਂ ਗਲਤੀਆਂ ਨੂੰ ਲੱਭਣ ਲਈ ਆਟੋਟੈਸਟ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਜੇ ਇਹ ਕੇਸ ਨਹੀਂ ਹੈ, ਤਾਂ ਜਾਂ ਤਾਂ ਅਸੀਂ ਖਰਾਬ ਆਟੋਟੈਸਟ ਲਿਖ ਰਹੇ ਹਾਂ, ਜਾਂ ਅਸੀਂ ਇੱਕ ਮਰੇ ਹੋਏ ਖੇਤਰ ਵਿੱਚ ਆ ਗਏ ਹਾਂ ਜੋ, ਸਿਧਾਂਤ ਵਿੱਚ, ਵਿਕਸਤ ਨਹੀਂ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ. ਦੋਵਾਂ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਅਸੀਂ ਕੁਝ ਗਲਤ ਕਰ ਰਹੇ ਹਾਂ, ਅਤੇ ਸਾਡੀ ਪਹੁੰਚ ਦਾ ਕੋਈ ਮਤਲਬ ਨਹੀਂ ਹੈ।
2. ਆਟੋਟੈਸਟ ਵਰਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ. ਇੱਕ ਸੌਫਟਵੇਅਰ ਉਤਪਾਦ ਨੂੰ ਲਿਖਣ ਲਈ ਬਹੁਤ ਸਾਰਾ ਸਮਾਂ ਅਤੇ ਮਿਹਨਤ ਖਰਚਣ, ਇਸਨੂੰ ਇੱਕ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਰੱਖਣ ਅਤੇ ਇਸਨੂੰ ਭੁੱਲਣ ਦਾ ਕੋਈ ਮਤਲਬ ਨਹੀਂ ਹੈ. ਟੈਸਟਾਂ ਨੂੰ ਚਲਾਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ ਚਲਾਉਣਾ ਚਾਹੀਦਾ ਹੈ।
3. ਆਟੋਟੈਸਟਾਂ ਨੂੰ ਸਥਿਰਤਾ ਨਾਲ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਦਿਨ ਦੇ ਸਮੇਂ, ਲਾਂਚ ਸਟੈਂਡ ਅਤੇ ਹੋਰ ਸਿਸਟਮ ਸੈਟਿੰਗਾਂ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ, ਟੈਸਟ ਰਨ ਉਸੇ ਨਤੀਜੇ ਵੱਲ ਲੈ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ। ਇੱਕ ਨਿਯਮ ਦੇ ਤੌਰ ਤੇ, ਇਹ ਇਸ ਤੱਥ ਦੁਆਰਾ ਯਕੀਨੀ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ ਕਿ ਆਟੋਟੈਸਟ ਫਿਕਸਡ ਸਿਸਟਮ ਸੈਟਿੰਗਾਂ ਦੇ ਨਾਲ ਵਿਸ਼ੇਸ਼ ਟੈਸਟ ਡੇਟਾ ਦੇ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ.
4. ਆਟੋਟੈਸਟਾਂ ਨੂੰ ਤੁਹਾਡੇ ਪ੍ਰੋਜੈਕਟ ਲਈ ਸਵੀਕਾਰਯੋਗ ਗਤੀ 'ਤੇ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਸਮਾਂ ਹਰੇਕ ਸਿਸਟਮ ਲਈ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਨਿਰਧਾਰਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਕੁਝ ਲੋਕ ਸਾਰਾ ਦਿਨ ਕੰਮ ਕਰਨ ਦੇ ਸਮਰੱਥ ਹੋ ਸਕਦੇ ਹਨ, ਜਦੋਂ ਕਿ ਦੂਸਰੇ ਇਸ ਨੂੰ ਸਕਿੰਟਾਂ ਵਿੱਚ ਕਰਨਾ ਮਹੱਤਵਪੂਰਨ ਸਮਝਦੇ ਹਨ। ਮੈਂ ਤੁਹਾਨੂੰ ਥੋੜ੍ਹੀ ਦੇਰ ਬਾਅਦ ਦੱਸਾਂਗਾ ਕਿ ਅਸੀਂ ਆਪਣੇ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਕਿਹੜੇ ਸਪੀਡ ਸਟੈਂਡਰਡ ਪ੍ਰਾਪਤ ਕੀਤੇ ਹਨ।
5. ਆਟੋਟੈਸਟ ਵਿਕਾਸ ਲਚਕਦਾਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ. ਕਿਸੇ ਵੀ ਕਾਰਜਸ਼ੀਲਤਾ ਦੀ ਜਾਂਚ ਕਰਨ ਤੋਂ ਇਨਕਾਰ ਕਰਨ ਦੀ ਸਲਾਹ ਨਹੀਂ ਦਿੱਤੀ ਜਾਂਦੀ ਕਿਉਂਕਿ ਅਸੀਂ ਇਸਨੂੰ ਪਹਿਲਾਂ ਜਾਂ ਕਿਸੇ ਹੋਰ ਕਾਰਨ ਕਰਕੇ ਨਹੀਂ ਕੀਤਾ ਹੈ। utPLSQL ਵਿਕਾਸ 'ਤੇ ਕੋਈ ਪਾਬੰਦੀਆਂ ਨਹੀਂ ਲਾਉਂਦਾ ਹੈ, ਅਤੇ ਓਰੇਕਲ, ਸਿਧਾਂਤ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਕਈ ਤਰ੍ਹਾਂ ਦੀਆਂ ਚੀਜ਼ਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਸਮੱਸਿਆਵਾਂ ਦਾ ਹੱਲ ਹੁੰਦਾ ਹੈ, ਇਹ ਸਿਰਫ ਸਮੇਂ ਅਤੇ ਮਿਹਨਤ ਦੀ ਗੱਲ ਹੈ।
6. ਤੈਨਾਤੀਯੋਗਤਾ। ਸਾਡੇ ਕੋਲ ਕਈ ਸਟੈਂਡ ਹਨ ਜਿੱਥੇ ਸਾਨੂੰ ਟੈਸਟ ਚਲਾਉਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਹਰੇਕ ਸਟੈਂਡ 'ਤੇ, ਇੱਕ ਡੇਟਾ ਡੰਪ ਨੂੰ ਕਿਸੇ ਵੀ ਸਮੇਂ ਅਪਡੇਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਆਟੋਮੈਟਿਕ ਟੈਸਟਾਂ ਦੇ ਨਾਲ ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਚਲਾਉਣਾ ਜ਼ਰੂਰੀ ਹੈ ਕਿ ਤੁਸੀਂ ਬਿਨਾਂ ਕਿਸੇ ਦਰਦ ਦੇ ਇਸਦੀ ਪੂਰੀ ਜਾਂ ਅੰਸ਼ਕ ਸਥਾਪਨਾ ਨੂੰ ਪੂਰਾ ਕਰ ਸਕੋ.

ਅਤੇ ਇੱਕ ਦੋ ਦਿਨਾਂ ਵਿੱਚ ਦੂਜੀ ਪੋਸਟ ਵਿੱਚ ਮੈਂ ਤੁਹਾਨੂੰ ਦੱਸਾਂਗਾ ਕਿ ਅਸੀਂ ਕੀ ਕੀਤਾ ਅਤੇ ਅਸੀਂ ਕਿਹੜੇ ਨਤੀਜੇ ਪ੍ਰਾਪਤ ਕੀਤੇ।

ਸਰੋਤ: www.habr.com