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

ਪਹਿਲਾ ਭਾਗ - ਇੱਥੇ.

ਸਥਿਤੀ ਦੀ ਕਲਪਨਾ ਕਰੋ. ਤੁਹਾਨੂੰ ਨਵੀਂ ਕਾਰਜਸ਼ੀਲਤਾ ਵਿਕਸਿਤ ਕਰਨ ਦੇ ਕੰਮ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈ ਰਿਹਾ ਹੈ। ਤੁਹਾਡੇ ਕੋਲ ਤੁਹਾਡੇ ਪੂਰਵਜਾਂ ਤੋਂ ਵਿਕਾਸ ਹੈ। ਜੇ ਅਸੀਂ ਮੰਨ ਲਈਏ ਕਿ ਤੁਹਾਡੀ ਕੋਈ ਨੈਤਿਕ ਜ਼ਿੰਮੇਵਾਰੀ ਨਹੀਂ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਕੀ ਕਰੋਗੇ?

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

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

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

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

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

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

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

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

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

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

ਇਸ ਲਈ, ਆਓ ਸਾਡੀ ਯੂਨਿਟ ਟੈਸਟਿੰਗ ਪ੍ਰਣਾਲੀ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੇ ਨਤੀਜਿਆਂ ਬਾਰੇ ਗੱਲ ਕਰੀਏ।

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

ਅੱਗੇ ਕੀ ਹੈ

ਆਉ ਆਟੋਮੇਟਿਡ ਟੈਸਟਿੰਗ ਪ੍ਰੋਜੈਕਟ ਲਈ ਵਿਕਾਸ ਯੋਜਨਾਵਾਂ ਬਾਰੇ ਗੱਲ ਕਰੀਏ।

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

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

ਪਰ ਇਹ ਵਿਕਾਸ ਦੇ ਸਪੱਸ਼ਟ ਤਰੀਕੇ ਹਨ। ਜੇ ਅਸੀਂ ਕਿਸੇ ਹੋਰ ਗੈਰ-ਮਾਮੂਲੀ ਚੀਜ਼ ਬਾਰੇ ਗੱਲ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਹੇਠ ਲਿਖਿਆਂ ਨੂੰ ਉਜਾਗਰ ਕਰਦੇ ਹਾਂ:

1. ਵਰਤਮਾਨ ਵਿੱਚ, ਆਟੋਟੈਸਟ ਪ੍ਰਬੰਧਨ DBMS ਪੱਧਰ 'ਤੇ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, i.e. ਸਫਲ ਕੰਮ ਲਈ PL/SQL ਦਾ ਗਿਆਨ ਜ਼ਰੂਰੀ ਹੈ। ਜੇ ਜਰੂਰੀ ਹੋਵੇ, ਸਿਸਟਮ ਪ੍ਰਬੰਧਨ (ਉਦਾਹਰਣ ਲਈ, ਮੈਟਾਡੇਟਾ ਲਾਂਚ ਕਰਨਾ ਜਾਂ ਬਣਾਉਣਾ), ਤੁਸੀਂ ਜੇਨਕਿੰਸ ਜਾਂ ਇਸ ਤਰ੍ਹਾਂ ਦੀ ਕੋਈ ਚੀਜ਼ ਵਰਤ ਕੇ ਕਿਸੇ ਕਿਸਮ ਦਾ ਐਡਮਿਨ ਪੈਨਲ ਬਣਾ ਸਕਦੇ ਹੋ।
2. ਹਰ ਕੋਈ ਗਿਣਾਤਮਕ ਅਤੇ ਗੁਣਾਤਮਕ ਸੂਚਕਾਂ ਨੂੰ ਪਿਆਰ ਕਰਦਾ ਹੈ। ਆਟੋਮੇਟਿਡ ਟੈਸਟਿੰਗ ਲਈ, ਅਜਿਹਾ ਯੂਨੀਵਰਸਲ ਇੰਡੀਕੇਟਰ ਕੋਡ ਕਵਰੇਜ ਜਾਂ ਕੋਡ ਕਵਰੇਜ ਮੈਟ੍ਰਿਕ ਹੈ। ਇਸ ਸੂਚਕ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਅਸੀਂ ਇਹ ਨਿਰਧਾਰਿਤ ਕਰ ਸਕਦੇ ਹਾਂ ਕਿ ਟੈਸਟ ਦੇ ਅਧੀਨ ਸਾਡੇ ਸਿਸਟਮ ਦੇ ਕੋਡ ਦਾ ਕਿੰਨਾ ਪ੍ਰਤੀਸ਼ਤ ਆਟੋਟੈਸਟਾਂ ਦੁਆਰਾ ਕਵਰ ਕੀਤਾ ਗਿਆ ਹੈ। ਸੰਸਕਰਣ 12.2 ਤੋਂ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋਏ, Oracle ਇਸ ਮੈਟ੍ਰਿਕ ਦੀ ਗਣਨਾ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਅਤੇ ਮਿਆਰੀ DBMS_PLSQL_CODE_COVERAGE ਪੈਕੇਜ ਦੀ ਵਰਤੋਂ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ।

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

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

ਸਿੱਟਾ

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

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

ਟਿੱਪਣੀਆਂ ਲਿਖੋ ਜੇ ਕੋਈ ਅਜਿਹੇ ਨੁਕਤੇ ਹਨ ਜਿਨ੍ਹਾਂ 'ਤੇ ਭਵਿੱਖ ਵਿੱਚ ਜ਼ੋਰ ਦਿੱਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਾਂ ਅਜਿਹੇ ਸਵਾਲ ਜਿਨ੍ਹਾਂ ਲਈ ਖੁਲਾਸਾ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਸਿਰਫ਼ ਰਜਿਸਟਰਡ ਉਪਭੋਗਤਾ ਹੀ ਸਰਵੇਖਣ ਵਿੱਚ ਹਿੱਸਾ ਲੈ ਸਕਦੇ ਹਨ। ਸਾਈਨ - ਇਨ, ਤੁਹਾਡਾ ਸੁਆਗਤ ਹੈ.

ਕੀ ਅਸੀਂ ਇਸ ਬਾਰੇ ਹੋਰ ਲਿਖਾਂਗੇ?

• ਹਾਂ ਜ਼ਰੂਰ

• ਨਹੀਂ ਧੰਨਵਾਦ

12 ਉਪਭੋਗਤਾਵਾਂ ਨੇ ਵੋਟ ਪਾਈ। 4 ਉਪਭੋਗਤਾ ਪਰਹੇਜ਼ ਰਹੇ।

ਸਰੋਤ: www.habr.com