ಹಲೋ, ಹಬ್ರ್!
ನನ್ನ ಹೆಸರು ಮ್ಯಾಕ್ಸಿಮ್ ಪೊನೊಮರೆಂಕೊ ಮತ್ತು ನಾನು ಸ್ಪೋರ್ಟ್‌ಮಾಸ್ಟರ್‌ನಲ್ಲಿ ಡೆವಲಪರ್ ಆಗಿದ್ದೇನೆ. ಐಟಿ ಕ್ಷೇತ್ರದಲ್ಲಿ ನನಗೆ 10 ವರ್ಷಗಳ ಅನುಭವವಿದೆ. ಅವರು ಹಸ್ತಚಾಲಿತ ಪರೀಕ್ಷೆಯಲ್ಲಿ ತಮ್ಮ ವೃತ್ತಿಜೀವನವನ್ನು ಪ್ರಾರಂಭಿಸಿದರು, ನಂತರ ಡೇಟಾಬೇಸ್ ಅಭಿವೃದ್ಧಿಗೆ ಬದಲಾಯಿಸಿದರು. ಕಳೆದ 4 ವರ್ಷಗಳಿಂದ, ಪರೀಕ್ಷೆ ಮತ್ತು ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ಪಡೆದ ಜ್ಞಾನವನ್ನು ಒಟ್ಟುಗೂಡಿಸಿ, ನಾನು DBMS ಮಟ್ಟದಲ್ಲಿ ಪರೀಕ್ಷೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುತ್ತಿದ್ದೇನೆ.
ನಾನು ಕೇವಲ ಒಂದು ವರ್ಷದಿಂದ ಸ್ಪೋರ್ಟ್ಮಾಸ್ಟರ್ ತಂಡದಲ್ಲಿದ್ದೇನೆ ಮತ್ತು ಪ್ರಮುಖ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳಲ್ಲಿ ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಯನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಿದ್ದೇನೆ. ಏಪ್ರಿಲ್‌ನಲ್ಲಿ, ಸ್ಪೋರ್ಟ್ಮಾಸ್ಟರ್ ಲ್ಯಾಬ್‌ನ ವ್ಯಕ್ತಿಗಳು ಮತ್ತು ನಾನು ಕ್ರಾಸ್ನೋಡರ್‌ನಲ್ಲಿ ನಡೆದ ಸಮ್ಮೇಳನದಲ್ಲಿ ಮಾತನಾಡಿದ್ದೇವೆ, ನನ್ನ ವರದಿಯನ್ನು "ಡಿಬಿಎಂಎಸ್‌ನಲ್ಲಿ ಘಟಕ ಪರೀಕ್ಷೆಗಳು" ಎಂದು ಕರೆಯಲಾಯಿತು ಮತ್ತು ಈಗ ನಾನು ಅದನ್ನು ನಿಮ್ಮೊಂದಿಗೆ ಹಂಚಿಕೊಳ್ಳಲು ಬಯಸುತ್ತೇನೆ. ಬಹಳಷ್ಟು ಪಠ್ಯ ಇರುತ್ತದೆ, ಆದ್ದರಿಂದ ನಾನು ವರದಿಯನ್ನು ಎರಡು ಪೋಸ್ಟ್‌ಗಳಾಗಿ ವಿಭಜಿಸಲು ನಿರ್ಧರಿಸಿದೆ. ಮೊದಲನೆಯದಾಗಿ, ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ಆಟೋಟೆಸ್ಟ್ಗಳು ಮತ್ತು ಪರೀಕ್ಷೆಯ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇವೆ ಮತ್ತು ಎರಡನೆಯದರಲ್ಲಿ, ನಮ್ಮ ಘಟಕ ಪರೀಕ್ಷಾ ವ್ಯವಸ್ಥೆ ಮತ್ತು ಅದರ ಅಪ್ಲಿಕೇಶನ್‌ನ ಫಲಿತಾಂಶಗಳ ಕುರಿತು ನಾನು ಹೆಚ್ಚು ವಿವರವಾಗಿ ವಾಸಿಸುತ್ತೇನೆ.
ಮೊದಲಿಗೆ, ಸ್ವಲ್ಪ ನೀರಸ ಸಿದ್ಧಾಂತ. ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆ ಎಂದರೇನು? ಇದು ಸಾಫ್ಟ್‌ವೇರ್‌ನಿಂದ ನಡೆಸಲ್ಪಡುವ ಪರೀಕ್ಷೆಯಾಗಿದೆ ಮತ್ತು ಆಧುನಿಕ ಐಟಿಯಲ್ಲಿ ಇದನ್ನು ಸಾಫ್ಟ್‌ವೇರ್ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ಹೆಚ್ಚಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ. ಕಂಪನಿಗಳು ಬೆಳೆಯುತ್ತಿವೆ, ಅವುಗಳ ಮಾಹಿತಿ ವ್ಯವಸ್ಥೆಗಳು ಬೆಳೆಯುತ್ತಿವೆ ಮತ್ತು ಅದರ ಪ್ರಕಾರ, ಪರೀಕ್ಷಿಸಬೇಕಾದ ಕಾರ್ಯದ ಪ್ರಮಾಣವು ಬೆಳೆಯುತ್ತಿದೆ ಎಂಬುದು ಇದಕ್ಕೆ ಕಾರಣ. ಹಸ್ತಚಾಲಿತ ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸುವುದು ಹೆಚ್ಚು ದುಬಾರಿಯಾಗುತ್ತಿದೆ.
ನಾನು ದೊಡ್ಡ ಕಂಪನಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡಿದ್ದೇನೆ, ಅದರ ಬಿಡುಗಡೆಗಳು ಪ್ರತಿ ಎರಡು ತಿಂಗಳಿಗೊಮ್ಮೆ ಹೊರಬರುತ್ತವೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಒಂದು ಡಜನ್ ಪರೀಕ್ಷಕರು ಕಾರ್ಯವನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಪರಿಶೀಲಿಸಲು ಇಡೀ ತಿಂಗಳು ಕಳೆದಿದೆ. ಡೆವಲಪರ್‌ಗಳ ಸಣ್ಣ ತಂಡದಿಂದ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಅನುಷ್ಠಾನಕ್ಕೆ ಧನ್ಯವಾದಗಳು, ನಾವು ಪರೀಕ್ಷೆಯ ಸಮಯವನ್ನು ಒಂದೂವರೆ ವರ್ಷಗಳಲ್ಲಿ 2 ವಾರಗಳಿಗೆ ಕಡಿಮೆ ಮಾಡಲು ಸಾಧ್ಯವಾಯಿತು. ನಾವು ಪರೀಕ್ಷೆಯ ವೇಗವನ್ನು ಹೆಚ್ಚಿಸಿದ್ದೇವೆ, ಆದರೆ ಅದರ ಗುಣಮಟ್ಟವನ್ನು ಸುಧಾರಿಸಿದ್ದೇವೆ. ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಗಳನ್ನು ನಿಯಮಿತವಾಗಿ ಪ್ರಾರಂಭಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಅವುಗಳು ಯಾವಾಗಲೂ ಅವುಗಳಲ್ಲಿ ಒಳಗೊಂಡಿರುವ ಸಂಪೂರ್ಣ ಚೆಕ್ ಕೋರ್ಸ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತವೆ, ಅಂದರೆ, ನಾವು ಮಾನವ ಅಂಶವನ್ನು ಹೊರಗಿಡುತ್ತೇವೆ.
ಉತ್ಪನ್ನದ ಕೋಡ್ ಅನ್ನು ಬರೆಯಲು ಮಾತ್ರವಲ್ಲದೆ ಈ ಕೋಡ್ ಅನ್ನು ಪರಿಶೀಲಿಸುವ ಘಟಕ ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯಲು ಡೆವಲಪರ್ ಅಗತ್ಯವಿರುತ್ತದೆ ಎಂಬ ಅಂಶದಿಂದ ಆಧುನಿಕ ಐಟಿ ನಿರೂಪಿಸಲ್ಪಟ್ಟಿದೆ.
ಆದರೆ ನಿಮ್ಮ ಸಿಸ್ಟಮ್ ಪ್ರಾಥಮಿಕವಾಗಿ ಸರ್ವರ್ ಲಾಜಿಕ್ ಅನ್ನು ಆಧರಿಸಿದ್ದರೆ ಏನು? ಮಾರುಕಟ್ಟೆಯಲ್ಲಿ ಸಾರ್ವತ್ರಿಕ ಪರಿಹಾರ ಅಥವಾ ಉತ್ತಮ ಅಭ್ಯಾಸಗಳಿಲ್ಲ. ನಿಯಮದಂತೆ, ಕಂಪನಿಗಳು ತಮ್ಮದೇ ಆದ ಸ್ವಯಂ-ಲಿಖಿತ ಪರೀಕ್ಷಾ ವ್ಯವಸ್ಥೆಯನ್ನು ರಚಿಸುವ ಮೂಲಕ ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತವೆ. ಇದು ನಮ್ಮ ಸ್ವಂತ ಸ್ವಯಂ-ಲಿಖಿತ ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷಾ ವ್ಯವಸ್ಥೆಯಾಗಿದ್ದು ಅದನ್ನು ನಮ್ಮ ಯೋಜನೆಯಲ್ಲಿ ರಚಿಸಲಾಗಿದೆ ಮತ್ತು ನಾನು ಅದರ ಬಗ್ಗೆ ನನ್ನ ವರದಿಯಲ್ಲಿ ಮಾತನಾಡುತ್ತೇನೆ.
ನಿಷ್ಠೆಯನ್ನು ಪರೀಕ್ಷಿಸಲಾಗುತ್ತಿದೆ
ಮೊದಲಿಗೆ, ನಾವು ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷಾ ವ್ಯವಸ್ಥೆಯನ್ನು ನಿಯೋಜಿಸಿದ ಯೋಜನೆಯ ಬಗ್ಗೆ ಮಾತನಾಡೋಣ. ನಮ್ಮ ಯೋಜನೆಯು ಸ್ಪೋರ್ಟ್ಮಾಸ್ಟರ್ ಲಾಯಲ್ಟಿ ಸಿಸ್ಟಮ್ ಆಗಿದೆ (ಮೂಲಕ, ನಾವು ಅದರ ಬಗ್ಗೆ ಈಗಾಗಲೇ ಬರೆದಿದ್ದೇವೆ ).
ನಿಮ್ಮ ಕಂಪನಿಯು ಸಾಕಷ್ಟು ದೊಡ್ಡದಾಗಿದ್ದರೆ, ನಿಮ್ಮ ಲಾಯಲ್ಟಿ ಸಿಸ್ಟಮ್ ಮೂರು ಪ್ರಮಾಣಿತ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ:
- ನಿಮ್ಮ ಸಿಸ್ಟಂ ಹೆಚ್ಚು ಲೋಡ್ ಆಗುತ್ತದೆ
- ನಿಮ್ಮ ಸಿಸ್ಟಂ ಸಂಕೀರ್ಣ ಕಂಪ್ಯೂಟಿಂಗ್ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ
- ನಿಮ್ಮ ಸಿಸ್ಟಮ್ ಅನ್ನು ಸಕ್ರಿಯವಾಗಿ ಸುಧಾರಿಸಲಾಗುತ್ತದೆ.
ಕ್ರಮವಾಗಿ ಹೋಗೋಣ ... ಒಟ್ಟಾರೆಯಾಗಿ, ನಾವು ಎಲ್ಲಾ ಸ್ಪೋರ್ಟ್ಮಾಸ್ಟರ್ ಬ್ರ್ಯಾಂಡ್ಗಳನ್ನು ಪರಿಗಣಿಸಿದರೆ, ನಂತರ ನಾವು ರಷ್ಯಾ, ಉಕ್ರೇನ್, ಚೀನಾ, ಕಝಾಕಿಸ್ತಾನ್ ಮತ್ತು ಬೆಲಾರಸ್ನಲ್ಲಿ 1000 ಕ್ಕೂ ಹೆಚ್ಚು ಮಳಿಗೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಈ ಮಳಿಗೆಗಳಲ್ಲಿ ಪ್ರತಿದಿನ ಸುಮಾರು 300 ಖರೀದಿಗಳನ್ನು ಮಾಡಲಾಗುತ್ತದೆ. ಅಂದರೆ, ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 000-3 ಚೆಕ್‌ಗಳು ನಮ್ಮ ಸಿಸ್ಟಮ್ ಅನ್ನು ಪ್ರವೇಶಿಸುತ್ತವೆ. ಸ್ವಾಭಾವಿಕವಾಗಿ, ನಮ್ಮ ನಿಷ್ಠಾವಂತ ವ್ಯವಸ್ಥೆಯು ಹೆಚ್ಚು ಲೋಡ್ ಆಗಿದೆ. ಮತ್ತು ಅದನ್ನು ಸಕ್ರಿಯವಾಗಿ ಬಳಸುವುದರಿಂದ, ನಾವು ಅದರ ಗುಣಮಟ್ಟದ ಉನ್ನತ ಗುಣಮಟ್ಟವನ್ನು ಒದಗಿಸಬೇಕು, ಏಕೆಂದರೆ ಸಾಫ್ಟ್‌ವೇರ್‌ನಲ್ಲಿನ ಯಾವುದೇ ದೋಷವು ದೊಡ್ಡ ವಿತ್ತೀಯ, ಖ್ಯಾತಿ ಮತ್ತು ಇತರ ನಷ್ಟಗಳನ್ನು ಅರ್ಥೈಸುತ್ತದೆ.
ಅದೇ ಸಮಯದಲ್ಲಿ, ಸ್ಪೋರ್ಟ್ಮಾಸ್ಟರ್ ನೂರಕ್ಕೂ ಹೆಚ್ಚು ವಿಭಿನ್ನ ಪ್ರಚಾರಗಳನ್ನು ನಡೆಸುತ್ತದೆ. ವಿವಿಧ ಪ್ರಚಾರಗಳಿವೆ: ಉತ್ಪನ್ನ ಪ್ರಚಾರಗಳಿವೆ, ವಾರದ ದಿನಕ್ಕೆ ಮೀಸಲಾದವುಗಳಿವೆ, ನಿರ್ದಿಷ್ಟ ಅಂಗಡಿಗೆ ಕಟ್ಟಲಾದವುಗಳಿವೆ, ರಶೀದಿಯ ಮೊತ್ತಕ್ಕೆ ಪ್ರಚಾರಗಳಿವೆ, ಸರಕುಗಳ ಸಂಖ್ಯೆಗೆ ಪ್ರಚಾರಗಳಿವೆ. ಸಾಮಾನ್ಯವಾಗಿ, ಕೆಟ್ಟದ್ದಲ್ಲ. ಗ್ರಾಹಕರು ಬೋನಸ್‌ಗಳು ಮತ್ತು ಪ್ರಚಾರದ ಕೋಡ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದಾರೆ, ಅದನ್ನು ಖರೀದಿ ಮಾಡುವಾಗ ಬಳಸಲಾಗುತ್ತದೆ. ಯಾವುದೇ ಆದೇಶವನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುವುದು ಬಹಳ ಕ್ಷುಲ್ಲಕ ಕಾರ್ಯವಾಗಿದೆ ಎಂಬ ಅಂಶಕ್ಕೆ ಇದೆಲ್ಲವೂ ಕಾರಣವಾಗುತ್ತದೆ.
ಆದೇಶ ಸಂಸ್ಕರಣೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಅಲ್ಗಾರಿದಮ್ ನಿಜವಾಗಿಯೂ ಭಯಾನಕ ಮತ್ತು ಸಂಕೀರ್ಣವಾಗಿದೆ. ಮತ್ತು ಈ ಅಲ್ಗಾರಿದಮ್‌ಗೆ ಯಾವುದೇ ಬದಲಾವಣೆಗಳು ಸಾಕಷ್ಟು ಅಪಾಯಕಾರಿ. ಅತ್ಯಂತ ತೋರಿಕೆಯಲ್ಲಿ ಅತ್ಯಲ್ಪ ಬದಲಾವಣೆಗಳು ಸಾಕಷ್ಟು ಅನಿರೀಕ್ಷಿತ ಪರಿಣಾಮಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು ಎಂದು ತೋರುತ್ತಿದೆ. ಆದರೆ ಇದು ನಿಖರವಾಗಿ ಅಂತಹ ಸಂಕೀರ್ಣ ಕಂಪ್ಯೂಟಿಂಗ್ ಪ್ರಕ್ರಿಯೆಗಳು, ವಿಶೇಷವಾಗಿ ನಿರ್ಣಾಯಕ ಕಾರ್ಯವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವಂತಹವುಗಳು ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಅತ್ಯುತ್ತಮ ಅಭ್ಯರ್ಥಿಗಳಾಗಿವೆ. ಹತ್ತಾರು ರೀತಿಯ ಪ್ರಕರಣಗಳನ್ನು ಕೈಯಿಂದ ಪರಿಶೀಲಿಸುವುದು ಬಹಳ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಮತ್ತು ಪ್ರಕ್ರಿಯೆಯ ಪ್ರವೇಶ ಬಿಂದುವು ಬದಲಾಗದೆ ಇರುವುದರಿಂದ, ಅದನ್ನು ಒಮ್ಮೆ ವಿವರಿಸಿದ ನಂತರ, ನೀವು ತ್ವರಿತವಾಗಿ ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಗಳನ್ನು ರಚಿಸಬಹುದು ಮತ್ತು ಕಾರ್ಯವು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ವಿಶ್ವಾಸದಿಂದಿರಿ.
ನಮ್ಮ ಸಿಸ್ಟಂ ಅನ್ನು ಸಕ್ರಿಯವಾಗಿ ಬಳಸುವುದರಿಂದ, ವ್ಯಾಪಾರವು ನಿಮ್ಮಿಂದ ಹೊಸದನ್ನು ಬಯಸುತ್ತದೆ, ಸಮಯದೊಂದಿಗೆ ಜೀವಿಸುತ್ತದೆ ಮತ್ತು ಗ್ರಾಹಕ-ಆಧಾರಿತವಾಗಿರುತ್ತದೆ. ನಮ್ಮ ಲಾಯಲ್ಟಿ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ, ಪ್ರತಿ ಎರಡು ತಿಂಗಳಿಗೊಮ್ಮೆ ಬಿಡುಗಡೆಗಳು ಹೊರಬರುತ್ತವೆ. ಇದರರ್ಥ ಪ್ರತಿ ಎರಡು ತಿಂಗಳಿಗೊಮ್ಮೆ ನಾವು ಸಂಪೂರ್ಣ ವ್ಯವಸ್ಥೆಯ ಸಂಪೂರ್ಣ ಹಿಂಜರಿತವನ್ನು ಕೈಗೊಳ್ಳಬೇಕಾಗಿದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಸ್ವಾಭಾವಿಕವಾಗಿ, ಯಾವುದೇ ಆಧುನಿಕ ಐಟಿಯಂತೆ, ಅಭಿವೃದ್ಧಿಯು ತಕ್ಷಣವೇ ಡೆವಲಪರ್ನಿಂದ ಉತ್ಪಾದನೆಗೆ ಹೋಗುವುದಿಲ್ಲ. ಇದು ಡೆವಲಪರ್ನ ಸರ್ಕ್ಯೂಟ್ನಲ್ಲಿ ಹುಟ್ಟುತ್ತದೆ, ನಂತರ ಅನುಕ್ರಮವಾಗಿ ಪರೀಕ್ಷಾ ಬೆಂಚ್ ಮೂಲಕ ಹಾದುಹೋಗುತ್ತದೆ, ಬಿಡುಗಡೆ, ಸ್ವೀಕಾರ, ಮತ್ತು ನಂತರ ಮಾತ್ರ ಉತ್ಪಾದನೆಯಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ. ಕನಿಷ್ಠ, ಪರೀಕ್ಷೆ ಮತ್ತು ಬಿಡುಗಡೆ ಸರ್ಕ್ಯೂಟ್ಗಳಲ್ಲಿ, ನಾವು ಸಂಪೂರ್ಣ ಸಿಸ್ಟಮ್ನ ಸಂಪೂರ್ಣ ಹಿಂಜರಿತವನ್ನು ಕೈಗೊಳ್ಳಬೇಕಾಗಿದೆ.
ವಿವರಿಸಿದ ಗುಣಲಕ್ಷಣಗಳು ಯಾವುದೇ ಲಾಯಲ್ಟಿ ಸಿಸ್ಟಮ್‌ಗೆ ಪ್ರಮಾಣಿತವಾಗಿವೆ. ನಮ್ಮ ಯೋಜನೆಯ ವೈಶಿಷ್ಟ್ಯಗಳ ಬಗ್ಗೆ ಮಾತನಾಡೋಣ.
ತಾಂತ್ರಿಕವಾಗಿ, ನಮ್ಮ ಲಾಯಲ್ಟಿ ಸಿಸ್ಟಮ್ನ 90% ತರ್ಕವು ಸರ್ವರ್ ಆಧಾರಿತವಾಗಿದೆ ಮತ್ತು Oracle ನಲ್ಲಿ ಅಳವಡಿಸಲಾಗಿದೆ. ಡೆಲ್ಫಿಯಲ್ಲಿ ಕ್ಲೈಂಟ್ ಅನ್ನು ಬಹಿರಂಗಪಡಿಸಲಾಗಿದೆ, ಇದು ಸ್ವಯಂಚಾಲಿತ ಕೆಲಸದ ಸ್ಥಳ ನಿರ್ವಾಹಕರ ಕಾರ್ಯವನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಬಾಹ್ಯ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗಾಗಿ ತೆರೆದ ವೆಬ್ ಸೇವೆಗಳಿವೆ (ಉದಾಹರಣೆಗೆ ವೆಬ್‌ಸೈಟ್). ಆದ್ದರಿಂದ, ನಾವು ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷಾ ವ್ಯವಸ್ಥೆಯನ್ನು ನಿಯೋಜಿಸಿದರೆ, ನಾವು ಅದನ್ನು ಒರಾಕಲ್‌ನಲ್ಲಿ ಮಾಡುತ್ತೇವೆ ಎಂಬುದು ಬಹಳ ತಾರ್ಕಿಕವಾಗಿದೆ.
ಸ್ಪೋರ್ಟ್‌ಮಾಸ್ಟರ್‌ನಲ್ಲಿ ಲಾಯಲ್ಟಿ ಸಿಸ್ಟಮ್ 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 ನಿಯಮಗಳು
ಲಾಯಲ್ಟಿ ಸಿಸ್ಟಮ್ನ ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಗಾಗಿ ಹೊಸ ವ್ಯವಸ್ಥೆಯನ್ನು ರಚಿಸಲು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು, ನಿರ್ವಹಣೆಯೊಂದಿಗೆ, ನಮ್ಮ ಭವಿಷ್ಯದ ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಗಳು ಅನುಸರಿಸಬೇಕಾದ ತತ್ವಗಳನ್ನು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ.
- ಸ್ವಯಂ ಪರೀಕ್ಷೆಗಳು ಪರಿಣಾಮಕಾರಿಯಾಗಿರಬೇಕು ಮತ್ತು ಉಪಯುಕ್ತವಾಗಿರಬೇಕು. ನಾವು ಅದ್ಭುತ ಡೆವಲಪರ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಅವರು ಖಂಡಿತವಾಗಿಯೂ ಉಲ್ಲೇಖಿಸಬೇಕಾಗಿದೆ, ಏಕೆಂದರೆ ಅವರಲ್ಲಿ ಕೆಲವರು ಬಹುಶಃ ಈ ವರದಿಯನ್ನು ನೋಡುತ್ತಾರೆ ಮತ್ತು ಅವರು ಅದ್ಭುತ ಕೋಡ್ ಅನ್ನು ಬರೆಯುತ್ತಾರೆ. ಆದರೆ ಅವರ ಅದ್ಭುತ ಕೋಡ್ ಕೂಡ ಪರಿಪೂರ್ಣವಾಗಿಲ್ಲ ಮತ್ತು ದೋಷಗಳನ್ನು ಹೊಂದಿದೆ, ಹೊಂದಿದೆ ಮತ್ತು ಮುಂದುವರಿಯುತ್ತದೆ. ಈ ದೋಷಗಳನ್ನು ಕಂಡುಹಿಡಿಯಲು ಸ್ವಯಂ ಪರೀಕ್ಷೆಗಳ ಅಗತ್ಯವಿದೆ. ಇದು ಹಾಗಲ್ಲದಿದ್ದರೆ, ಒಂದೋ ನಾವು ಕೆಟ್ಟ ಸ್ವಯಂ ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯುತ್ತಿದ್ದೇವೆ ಅಥವಾ ತಾತ್ವಿಕವಾಗಿ ಅಭಿವೃದ್ಧಿಯಾಗದ ಸತ್ತ ಪ್ರದೇಶಕ್ಕೆ ನಾವು ಬಂದಿದ್ದೇವೆ. ಎರಡೂ ಸಂದರ್ಭಗಳಲ್ಲಿ, ನಾವು ಏನಾದರೂ ತಪ್ಪು ಮಾಡುತ್ತಿದ್ದೇವೆ ಮತ್ತು ನಮ್ಮ ವಿಧಾನವು ಸರಳವಾಗಿ ಅರ್ಥವಿಲ್ಲ.
- ಸ್ವಯಂ ಪರೀಕ್ಷೆಗಳನ್ನು ಬಳಸಬೇಕು. ಸಾಫ್ಟ್‌ವೇರ್ ಉತ್ಪನ್ನವನ್ನು ಬರೆಯಲು ಸಾಕಷ್ಟು ಸಮಯ ಮತ್ತು ಶ್ರಮವನ್ನು ವ್ಯಯಿಸಿ, ಅದನ್ನು ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಇರಿಸಿ ಮತ್ತು ಅದನ್ನು ಮರೆತುಬಿಡುವುದರಲ್ಲಿ ಯಾವುದೇ ಅರ್ಥವಿಲ್ಲ. ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸಬೇಕು ಮತ್ತು ಸಾಧ್ಯವಾದಷ್ಟು ನಿಯಮಿತವಾಗಿ ನಡೆಸಬೇಕು.
- ಆಟೋಟೆಸ್ಟ್ಗಳು ಸ್ಥಿರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬೇಕು. ದಿನದ ಸಮಯದ ಹೊರತಾಗಿ, ಲಾಂಚ್ ಸ್ಟ್ಯಾಂಡ್ ಮತ್ತು ಇತರ ಸಿಸ್ಟಮ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳು, ಪರೀಕ್ಷಾ ರನ್‌ಗಳು ಅದೇ ಫಲಿತಾಂಶಕ್ಕೆ ಕಾರಣವಾಗಬೇಕು. ನಿಯಮದಂತೆ, ಸ್ಥಿರ ಸಿಸ್ಟಮ್ ಸೆಟ್ಟಿಂಗ್ಗಳೊಂದಿಗೆ ವಿಶೇಷ ಪರೀಕ್ಷಾ ಡೇಟಾದೊಂದಿಗೆ ಆಟೋಟೆಸ್ಟ್ಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಎಂಬ ಅಂಶದಿಂದ ಇದು ಖಾತ್ರಿಪಡಿಸಲ್ಪಡುತ್ತದೆ.
- ಆಟೋಟೆಸ್ಟ್ಗಳು ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್‌ಗೆ ಸ್ವೀಕಾರಾರ್ಹ ವೇಗದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬೇಕು. ಈ ಸಮಯವನ್ನು ಪ್ರತಿ ವ್ಯವಸ್ಥೆಗೆ ಪ್ರತ್ಯೇಕವಾಗಿ ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ. ಕೆಲವು ಜನರು ದಿನವಿಡೀ ಕೆಲಸ ಮಾಡಲು ಶಕ್ತರಾಗಿರುತ್ತಾರೆ, ಆದರೆ ಇತರರು ಅದನ್ನು ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಮಾಡಲು ನಿರ್ಣಾಯಕವೆಂದು ಕಂಡುಕೊಳ್ಳುತ್ತಾರೆ. ನಮ್ಮ ಯೋಜನೆಯಲ್ಲಿ ನಾವು ಯಾವ ವೇಗದ ಮಾನದಂಡಗಳನ್ನು ಸಾಧಿಸಿದ್ದೇವೆ ಎಂದು ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ.
- ಆಟೋಟೆಸ್ಟ್ ಅಭಿವೃದ್ಧಿ ಹೊಂದಿಕೊಳ್ಳುವಂತಿರಬೇಕು. ಯಾವುದೇ ಕಾರ್ಯವನ್ನು ಪರೀಕ್ಷಿಸಲು ನಿರಾಕರಿಸುವುದು ಸೂಕ್ತವಲ್ಲ ಏಕೆಂದರೆ ನಾವು ಅದನ್ನು ಮೊದಲು ಮಾಡಿಲ್ಲ ಅಥವಾ ಬೇರೆ ಕಾರಣಕ್ಕಾಗಿ. utPLSQL ಅಭಿವೃದ್ಧಿಗೆ ಯಾವುದೇ ನಿರ್ಬಂಧಗಳನ್ನು ವಿಧಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಒರಾಕಲ್, ತಾತ್ವಿಕವಾಗಿ, ವಿವಿಧ ವಿಷಯಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಹೆಚ್ಚಿನ ಸಮಸ್ಯೆಗಳಿಗೆ ಪರಿಹಾರವಿದೆ, ಇದು ಕೇವಲ ಸಮಯ ಮತ್ತು ಶ್ರಮದ ವಿಷಯವಾಗಿದೆ.
- ನಿಯೋಜನೆ. ನಾವು ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸಬೇಕಾದ ಹಲವಾರು ಸ್ಟ್ಯಾಂಡ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಪ್ರತಿ ಸ್ಟ್ಯಾಂಡ್‌ನಲ್ಲಿ, ಯಾವುದೇ ಸಮಯದಲ್ಲಿ ಡೇಟಾ ಡಂಪ್ ಅನ್ನು ನವೀಕರಿಸಬಹುದು. ನೀವು ಅದರ ಪೂರ್ಣ ಅಥವಾ ಭಾಗಶಃ ಅನುಸ್ಥಾಪನೆಯನ್ನು ನೋವುರಹಿತವಾಗಿ ನಿರ್ವಹಿಸುವ ರೀತಿಯಲ್ಲಿ ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಗಳೊಂದಿಗೆ ಯೋಜನೆಯನ್ನು ನಡೆಸುವುದು ಅವಶ್ಯಕ.
ಮತ್ತು ಒಂದೆರಡು ದಿನಗಳಲ್ಲಿ ಎರಡನೇ ಪೋಸ್ಟ್‌ನಲ್ಲಿ ನಾವು ಏನು ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ನಾವು ಯಾವ ಫಲಿತಾಂಶಗಳನ್ನು ಸಾಧಿಸಿದ್ದೇವೆ ಎಂದು ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ.
ಮೂಲ: www.habr.com