Babylon -ий толийг Stardict уруу хөрвүүлэх

Виндовсын орчинд Babylon гэж сайн толь бичиг байдаг билээ. Энэ толь нь хэрэглэхэд хялбар бөгөөд маш олон толь бичигтэй, гэхдээ үнэтэй. Өөрөөр хэлбэл энэ толийг зүй ёсоор хэрэглэхийн тулд мөнгө төлөх шаардлагатай гэсэн үг.

Stardict нь Linux, FreeBSD, Solaris, Win32 -бүгдэн дээр нь ажилладаг нээлттэй эх бүхий толь бичгийн програм юм. Мөн л нээлттэй эх бүхий төрөл бүрийн толь бичгүүдтэй. Гэхдээ толь бичгийн сан нь арай Babylon-д хүрэхгүй, тухайлбал монгол хэлтэй толь бичиг байхгүй байсан юм. Тэгвэл Babylon-оос нээлттэй формат руу хөрвүүлдэг dictconv гэдэг програмын тусламжтайгаар Babylon-ий Англи-Монгол толийг stardict формат руу хөрвүүллээ.

Хөрвүүлсэн файлыг эндээс авч болно. Татаж авсан толио линукс дээр бол /usr/share/stardict/dic дотор, Виндовс дээр бол C:\Program files\stardict\dic\ директори дотор задлаад stardict-ээ ахин ачаалахад шинэ толь нэмэгдсэн байх болно.

Олон үйлдлийн систем нэг дискэн дээр

Анх линукс үйлдлийн систем сонирхож эхлэж байхад виндовс суулгачихсан хард дискэн дээрээ нэмж линукс суулгах гэж нилээд юм болдог байв. Нэг удаа виндовсоо ахиж суулгах хэрэг гараад, тэгсэн чинь компьютерээ дахин ачаалтал үйлдлийн систем сонгодог цэс маань гарч ирэхгүй шууд виндовс ачаалагдаж байна. Ингээд эхний гашуун туршлага : виндовс бол найзархаг үйлдлийн систем биш, бусад үйлдлийн системтэй нэг дискэн дээр байхыг хүсдэггүй юм байна. Ингээд дараа нь өөр өөр линуксуудыг нэмж суулгаж туршив, бүр FreeBSD -г нөгөөдүүлтэйгээ хамт суулгаж үзэв. Ингэж олон үйлдлийн систем суулгахад дараалал чухал бөгөөд хамгийн найзархаг бусаас нь эхлэж суулгах хэрэгтэй юм байна гэдгийг ойлгов. Тухайн үед бол Windows->FreeBSD->Linux-ууд(Mandrake, RedHat, Debian, Slackware,...) байсан. Тэгэхээр хамгийн найзархаг нь Линукс болж таарч байна. Тэр үед эдгээр үйлдлийн системүүдийг бүгдийг нь хэрэглээд ч гавьсан юмгүй, суулгахаас цааш хэтрээгүй ч хатуу дискний партишнууд болоод үйлдлийн системийн ачаалагчдын талаар жаахан мэдлэгтэй болсон юм.

Өнөөдөр бидний хамгийн түгээмэл хэрэглэдэг PC нь нэг хатуу дискэн дээр 4 өөс дээшгүй primary partition байхыг зөвшөөрдөг, учир нь дискний мастер бүүт бичлэг дээр 4 өөс дээш паритишн бүртгэгддэггүй. Түүнээс олон партишн үүсгэхийн тулд 4 партишнийхаа аль нэгийг өргөтгөгдсөн партишн(extended partition) болгоод, өргөтгөгдсөн партишн дотроо дуртай тооны логик партишн(logical partition) үүсгэж болно. Логик партишний мэдээлэл нь өргөтгөгдсөн партишний эхний сектороос эхэлдэг. Компьютер асаад хатуу дискний хамгийн эхэнд байрлах бүүт сектороос үйлдлийн систем ачаалах кодыг ажиллуулдаг ба энэ нь секторт(512 байт) үйлдлийн систем ачаалах код, дискний партишнуудын мэдээлэл байрлах ёстой. Ер нь стандартаараа бол мастер бүүт дээр байрлах код нь идэвхтэй партишний эхний сектор луу үйлдлийн систем ачаалах эрхийг шилжүүлдэг. Ингэж партишны эхний сектор руу үйлдлийн систем ачаалах эрхийг шилжүүлэх үйлдлийг гинжин ачаалалт(chain-loading) гэдэг. Өмнө бидний цухас дурдсан олон үйлдлийн систем суулгасан үед хэрэглэдэг үйлдлийн систем сонгох цэс нь энэ эхний сектор дээр сууж байгаад цэснээс сонгох үед харгалзах партишн руу нь үйлдлийн систем ачаалах эрхийг шилжүүлнэ. Тэр үед сонгогдсон партишн дээр мөн үйлдлийн систем сонгох програм суусан байвал дахин тэндээсээ өөр үйлдлийн систем сонгосон ч болно, зүгээр тухай партишн дээрээсээ үйлдлийн системийг ачаалсан ч болно. Ингэхээр гинжин хэлхээс шиг дүр зураг бууж байгаа биз.

Үйлдлийн систем болгонд ачаалагч програм байх бөгөөд эдгээр нь партишний эхний сектор дээрээс дуудагдаж, үйлдлийн системийн цөм хэсгийг эхлүүлнэ. Үйлдлийн систем ачаалагч болгонд тохиргооны файл бий.

Линуксийн хувьд grub, lilo гэж үйлдлийн систем ачаалагчид түгээмэл хэрэглэгддэг. grub -ийг авч үзье. Ер нь үйлдийн систем ачаалагчыг мастер бүүт дээр аль болох суулгахгүйгээр, тухайн партишн дээр нь суулгавал зүгээр. Ингэснээр дараа нь мастер бүүт дээр өөр ачаалагч суулгахад эрх чөлөөтэй болно. Үүний тулд үйлдлийн систем ачаалагчаа хуулж авах хэрэгтэй. Хуулж аваагүй тохиолдолд, линуксаа логик партишн дээр суулгачихсан бол линукс руугаа дахин орж болохгүй л болчих болов уу. Линукс маань мастер хатуу дискний 2-р партишн дээр суусан гэж үзвэл доорх командаар ачаалагчийг хуулж авч болно.

dd if=/dev/hda2 of=/mnt/usb/linux.bin bs=512 count=1

Windows NT төрлийн үйлдлийн системийг ачаалагч нь NT Loader гэж програм байдаг. Энэ програмын тохиргооны файл нь boot.ini гэж файл бий. Түрүүн хуулж авсан файлаа С дискэн дээр хуулаад C:\linux.bin="Linux" гэсэн мөрийг boot.ini файлд нэмж өгвөл бид линукс руугаа орох боломжтой болно. Мэдээж Виндовс байгаа партишнийг идэвхтэй(active partition) гэж үзэв.

[boot loader] timeout=10 default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows XP" /noexecute=optin /fastdetect C:\linux.bin="Linux"

Хэрэв линуксийн партишн нь идэвхтэй бол Линуксийн ачаалагч дээрээ Виндовсийг тохируулж өгнө. grub -ийн тохиргоо нь /boot/grub/menu.lst файлд байна. Дараах мөрүүдийг menu.lst файлд нэмж өгнө.

title Windows XP root (hd0,3) makeactive chainloader +1

Энд нэг анхаарах зүйл бол хатуу дискний нэрлэлт юм. grub дээр хатуу дискүүд hd0(master harddisk), hd1(slave harddisk) гэх мэт нэрлэгдээд, партишнууд нь (hd0, 3) гэх мэтээр илэрхийлэгдэнэ. (hd0, 3) гэдэг нь мастер хатуу дискний 4 дэх партишнийг илэрхийлнэ. Хэрэв линуксийг мастер хатуу дискэн дээр, виндовсыг дэд(slave) хатуу дискэн дээр суулгасан бол grub дээр нилээд юм бичиж өгөх хэрэгтэй, учир нь виндовс бол мастер хатуу дискэн дээрээс л ажиллана гэсэн амбицтай үйлдлийн систем юм.

title Windows XP root (hd1,0) savedefault makeactive map (hd0) (hd1) map (hd1) (hd0) chainloader +1

Энд map гэдэг командаар виндовсыг "зальдаж" байна.

FreeBSD дээр партишнийг slice -гэдэг. slice нь дотроо label-уудтай. label нь логик партишнтэй төстэй гэж ойлгож болно. FreeBSD суулгахын тулд нэг primary партишний нөөц хэрэгтэй. Хатуу дискэн дээрээ ямар ч партишнгүй хоосон зай үлдээж байгаад суулгана. Ингэхэд мастер бүүт бичлэг дээр нэг ширхэг primary партишн нэмэгдсэн байх ба тэр нь FreeBSD ийн slice юм. BSD -ийн ачаалагчыг мөн мастер бүүт дээр эсвэл өөрийнх нь slice дээр суулгаж болно. Ер нь бол slice дээр нь суулгах нь илүү уян хатан гэж зөвлөх байна.


Эх сурвалжууд:

• How to dual-boot Windows NT/2000/XP and Linux using NTLDR
• Dual-Boot Linux and Windows 2000/Windows XP with GRUB HOWTO
• How to boot an OS directly with GRUB
• Dual and Multi Booting FreeBSD, Linux, and OpenBSD

Системийн найдвартай байдал

Саяхан блоггэр.ком дээр алдаа гарсан байсныг зарим хүмүүс анзаарсан байх. Пост оруулах хуудасны оронд HTTP 500 дугаар алдаа гарсан харагдсан. Мөн эртээрхэн Яхоо мэсэнжэр 2-3 цаг орчим зогссон. Гэхдээ энэ явдлаа урьдчилан зарласан ба, системийн шинэчлэлтийн ажил байсан гэж тайлбарласан. Илүү ойрхон жишээ гэвэл Мобикомын шинэ жилийн түгжрэл, -гээд... Эдгээрийг дурддагийн учир бол Системийн найдвартай байдалын тухай авч үзэх гэсэн юм. Чанартай сайн програм хангамж нь алдаагүй зөв ажиллахаас гадна, осол доголдлын үед яс чанараа харуулдаг билээ.

Найдвартай байдал гэдэг нь : Систем өөрийн үүргийг өгөгдсөн нөхцөл байдалд, тодорхой хугацааны туршид доголдолгүйгээр гүйцэтгэж чадах магадлал юм. Ер нь 100% найдвартай систем байх боломжгүй. Гэхдээ маш өндөр түвшинд найдвартай байдлыг хангасан системүүд байж болох бөгөөд, тэдгээрийн зэрэглэл нь таван ес(99.999%-ийн найдвартай), зургаан ес(99.9999%-ийн найдвартай) гэх мэт тоогоор илэрхийлэгддэг.

Тухайн системийг найдвартай эсэхийг шинжлэхэд юун түрүүнд системийн хаа нэг хэсэгт доголдол гарснаар систем бүхэлдээ зогсож болох газруудыг авч үздэг. Өөрөөр хэлбэл нэг цэгийн доголдол буюу single point of failure -уудыг судлана. Ингээд тухайн хэсэг доголдох эх шалтгаанууд юу байж болхыг судлаж, эдгээр шалтгаануудыг аль болох цөөлөх хэрэгтэй. Бүх шалтгааныг урьдчилан сэргийлэх боломжгүй учраас, тухайн хэсгийн эрсдэлийг дизайны түвшинд багасгах аргыг мөн хэрэглэдэг. Жишээ нь сүлжээний картыг нэмж суурилуулах, сэрвэрээ давхарлаж ажиллуулах гэх мэт шийдэл байж болно. Аль нэг сүлжээний карт/сэрвэр ажиллахаа байлаа гэхэд, бусад нь идэвхжиж, системийн хэвийн ажиллагаа үргэлжилсээр байна гэсэн үг.

Системийн найдвартай ажиллагааны түвшинг MTBF(Mean Time Between Failure) буюу алдаа хоорондын хугацаа гэдэг үзүүлэлтээр илэрхийлэх нь элбэг. Гэхдээ иймэрхүү үзүүлэлт бол магадлал бодоод гаргасан тоо л юм, харин системийн найдвартай ажиллагааг бодитоор үнэмжинэ гэдэг өөрөө том асуудал байдаг. Сүлжээний холболтын найдвартай эсэхийг бол нэг картаа сүлжээнээс салгаад үзчихэж болно. Тэгвэл, гурван жил тасралтгүй ажиллах ёстой системийн найдвартай байдлыг яаж үнэмжших вэ? Гурван жил ажиллуулж турших уу? Сансрын хөлгийн найдвартай ажиллах эсэхийг сансарт хөөргөж тестлэнэ гэвэл асар их зардал гарна гэх мэт.. Иймэрхүү тохиолдолд тестийг дэд хэсгүүдээр нь маш нарийн хийх ч юмуу, эсвэл хиймэл орчинд туршаад бодит ертөнцөд гаргах нь бий. Гэтэл маш нарийн тооцоолж хийсэн ч, туршилт хийлгүй хөөргөнө гэдэг аз туршсан хэрэг болно - зургаан естэй систем ч санаанд ороогүй, тооцоологдоогүй үлдсэн жижиг зүйлээс болж осолдсон тохиолдол байдаг.

Системийн Найдвартай байдал гэдэг нэгэн бичлэгээр тоймлож барахгүй сонирхолтой, өргөн хүрээтэй сэдэв тул ингээд өндөрлөж, эх сурвалжуудыг тоймлон үлдээе.

Эх сурвалж:

• Reliability engineering. Найдвартай байдлын инженерчлэлийн тухай Википедиа тайлбар дээр тун ойлгомжтой бичсэн байна.
• 99.999 or Five Nines Uptime. Таван ес нь бодит байдал дээр хангалттай байдаг юм бол? Системийн ажиллагаа бүтэн жилийн хугацаанд хэдхэн минут тасалдахад л хэрэглэгчийн итгэл 99 хувиар унах магадлалтай гэнэ.
• Byzantine fault tolerance. Баталгаагүй холбооны шугамыг ашиглаж баттай мэдээ солилцох тухай. Энэ бол эртний Византиний хоёр армийн тухай домгоос гаралтай бодлого юм. Хоёр арми нэгэн хотыг зэрэг дайрах болсон боловч, тэдгээр хоёр армийн хооронд орших хөндийг дайснууд эзэлсэн байгаа. Зэрэг дайрахын тулд аль нэг тал нь хэдийд дайрахаа элч илгээж нөгөө армидаа хэлэх хэрэгтэй. Гэхдээ мэдээг нөгөө арми үнэхээр хүлээж авсан гэдэгт итгэлтэй болж байж л дайрах нь мэдээж. Гэтэл нөгөө арми нь хүлээж авлаа гэдэг хариугаа мөн очсон гэдэгт итгэлтэй болж байж л дайрах хэрэгтэй болно. Гэх мэтээр төгсгөлгүй үргэлжилэх юм. Энэ бодлогод ямар шийдлүүд байж болох вэ?
• Software Metrics and Reliability. Програм хангамжын найдвартай байдлыг ямар үзүүлэлтээр хэмждэг тухай. Хатуумжын найдвартай байдал нь, ашиглалтын хугацааны сүүл хэсэгт муудаж эхэлдэг бол, програм хангамжынх хугацаа өнгөрөх тусам сайжирдаг байна.
• Why Software Is Bad and What We Can Do to Fix It. Програм хангамжын найдвартай байдал хэзээ ч 100% -д хүрэхгүй гэж дээр дурдсан билээ. Тэгвэл яагаад ийм байна вэ? Үүний учир шалтгаан бол бидний програм хангамж маань алгоритм дээр суурилсан, асинхрон байдагт юм байна. Бодит байдал дээр зэрэгцэн өрнөж байгаа процессуудыг цуваа байдлаар буюу алгоритмчлах аргаар загварчилдаг билээ. Харин хүний тархи, электрон хэлхээ зэрэг шиг асинхрон, үзэгдэл дээр тулгуурласан хэлбэрээр загварчилж чадвал хичнээн том системийг ч 100% найдвартай хийх боломжтой гэнэ. Тэгвэл үүнийг хэрхэн хэрэгжүүлэх вэ? Энэхүү COSA төсөлийн зорилго нь энэ юм.

Виндовсыг аргалах нь

Аргалах ч биш л дээ, Виндовс дээр хийдэг тохиргоонууд л гэсэн үг.

1. Windows Explorer дотроос аль нэг директори сонгоод командын мөр ажиллуулах. Үүний тулд дараах тэкстийг reg өргөтгөлтэй файлд хадгалаад ажиллуулна.

Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\Directory\shell\Command] @="Command &Prompt" [HKEY_CLASSES_ROOT\Directory\shell\Command\command] @="cmd.exe /k cd \\\"%1\\\""

Ингэсний дараа дуртай директори дээрээ баруунаараа товшиход "Command Prompt" гэсэн цэсний сонголт бий болсон байх бөгөөд түүнийг сонговол Командын мөрийг тухай директорид ажиллуулах болно.

2. Дискүүдийг автоматаар шэйр хийдгийг болиулах. Доорх текстийг reg өргөтгөлтэй файлд хадгалаад ажиллуулна.

Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters] "AutoShareWks"=dword:00000000

3. Zip файлыг директори мэтээр харуулахыг болиулах. Explorer ажиллахад том хэмжээний zip файлуудыг уншихдаа их удаагаад байдаг. Дараах командыг ажиллуулвал zip файлыг директори шиг харуулахаа болино.

regsvr32 /u zipfldr.dll

Юникс shell-ийн командууд

Юникс орчинд ороход шел дээр ажиллах нь зайлшгүй. Шел дээр ажиллах нь эхлээд залхуутай мэт санагдаж болох ч, энэ нь командууд болон багаж хэрэгслүүдийг хир зөв, үр дүнтэй ашиглаж байгаагаас хамаардаг. Үүний тулд хийж байгаа үйлдлээ хэрхэн илүү хялбар хурдан хийх вэ гэдгийг бодож, интернэтээс туршлага судлаж, шинэ хэрэгсэл, шинэ команд байнга сурч байх хэрэгтэй. Ингээд зарим хэрэг болохуйц командуудыг сийрүүлье.

Ямар шел дээр ажиллаж байгааг харах

# echo $SHELL /bin/bash

Командын гарын авлагыг унших

# man ls

Програм хаана байрлаж байгааг харах

# whereis cp cp: /bin/cp /usr/share/man/man1/cp.1.gz /usr/share/man/man1p/cp.1p.gz

Ажиллаж байгаа директори харах

# pwd /home/ochiro

Файлын төрлийг харах

# file pauker.pau.gz pauker.pau.gz: gzip compressed data, from MS-DOS

Файлын эхний 5 мөрийг харах

# head -n 5 ./tomcat/logs/localhost.2007-03-05.log Mar 5, 2007 4:36:16 PM org.apache.catalina.core.ApplicationContext log INFO: ContextListener: contextInitialized() Mar 5, 2007 4:36:16 PM org.apache.catalina.core.ApplicationContext log INFO: SessionListener: contextInitialized() Mar 5, 2007 4:36:17 PM org.apache.catalina.core.ApplicationContext log

Файлын сүүлийн 5 мөрийг харах

# tail -n 5 ./tomcat/logs/manager.2007-03-05.log INFO: HTMLManager: list: Listing contexts for virtual host 'localhost' Mar 5, 2007 5:15:48 PM org.apache.catalina.core.ApplicationContext log INFO: HTMLManager: restart: Reloading web application at '/testapp' Mar 5, 2007 5:15:48 PM org.apache.catalina.core.ApplicationContext log INFO: HTMLManager: list: Listing contexts for virtual host 'localhost'

Лог файлын сүүлийн мөрүүдийг ажиглах

# tail -f ./tomcat/logs/localhost.2007-03-05.log at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)

Хоёр файлын ялгааг олох

# diff dic.txt dic-new.txt 1a2 > new line

Удаан ажиллах командыг ард ажиллуулах

# bin/backup-files.sh & [1] 26490

Ард ажиллаж байгаа командуудыг харах

# jobs [1]+ Stopped bin/backup-files.sh

Ажиллуулсан командуудынхаа түүхийг үзэх

# history 1 echo $SHELL 2 whereis cp 3 pwd 4 file pauker.pau.gz 5 head -n 5 TUTORIAL~ 6 cp dic.txt dic-new.txt 7 cat dic.txt 8 vi dic-new.txt 9 diff dic.txt dic-new.txt ....

Файл байхгүй бол үүсгэх

# touch newfile.txt

Дискний сул зайг харах

# df -h Filesystem Size Used Avail Use% Mounted on /dev/hda2 13G 7.6G 4.5G 63% / udev 506M 152K 506M 1% /dev /dev/hda3 51G 25G 26G 49% /home /dev/hdb1 38G 25G 2.2G 92% /mnt/FAT32

Директори доторхи файлуудыг хэмжээгээр нь буурах эрэмбээр жагсаах

# du -sh archive/* | sort -nrk 1 859M archive/nihongo 303M archive/photo 277M archive/lessons 233M archive/install 1.8G archive/books

Бичсэн скриптдээ ажиллах зөвшөөрөл тавих

# chmod u+x scripts/upload.sh

Тооны тооллыг хөрвүүлж харах

# echo 'obase=10; ibase=16; E59' | bc 3673

Олон мөр оролт

# bc <<> A > EOF 10

Директорын бүтцийг ганц командаар үүсгэх

# mkdir -p project/{lib/ext,bin,src,doc/{html,txt,pdf},demo/stat/a}

Директорийг архивлах

# tar cvf /tmp/archive.tar archive

Файлыг шахах

# gzip archive.tar

Архивийн файлыг сонгосон директори луу задлах

# tar xvf -C dest/to/extract archive.tar.gz

Эхний команд тэг утга буцаасан тохиолдолд дараагийн команд ажиллана

# cd directory/exists && tar xvf ~/archive.tar

Эхний команд тэг биш утга буцаавал дараагийнх ажиллана

# cd directory/not/exists || mkdir -p directory/not/exists

Директори байхгүй бол үүсгээд архивийг задлана

# cd dest/dir || mkdir -p dest/dir && tar xvf -C dest/dir ~/archive.tar

Урт командыг арагш ташуу зураасаар хуваах

# cd dest/to/extract || \ > mkdir -p est/to/extract && \ > tar xvf -C est/to/extract ~/archive.tar

Зарим командуудыг дэд шелд ажиллуулаад гаралтыг admin руу мэйлдэх

# ( cd dest/to/extract/ || mkdir -p dest/to/extract && \ > VAR=$PWD; cd ~; tar xvf -C $VAR archive.tar ) \ > | mailx admin -S "Archive contents"

Зарим командуудыг бүлэглэж ажиллуулаад гаралтыг admin руу мэйлдэх

# { cp ${VAR}a . && chown -R guest.guest a && \ > tar cvf newarchive.tar a; } | mailx admin -S "New archive"

Эхний командаар гарч ирэх жагсаалтууд дээр өөр команд ажиллуулах

# ls -1 | xargs file bin: directory desk-books: directory Desktop: directory diagrams: directory dic-new.txt: UTF-8 Unicode text dic.txt: UTF-8 Unicode text

Файл дотроос текст хайх

# grep implement TUTORIAL.txt On systems which do not implement suspending, C-z creates a subshell function which implements the C-p command.

Файл дотроос хайхдаа regular expression ашиглах

# grep ^The TUTORIAL.txt The characters ">>" at the left margin indicate directions for you to The first thing that you need to know is how to move around from place The following commands are useful for viewing screenfuls: There are several ways you can do this. You can use the arrow keys, The location of the cursor in the text is also called "point". To There is a whole series of commands that start with CONTROL-x; many of .......

wc хэрэглэлгүйгээр файл дотор хайсан текст хэдэн мөрөнд байгааг тоолох

# grep -c ^The TUTORIAL.txt 30

awk ашиглаж багана сонгож харах

# ls -l | awk '{print $3 " " $8 }' ochiro bin ochiro desk-books ochiro Desktop ochiro diagrams ochiro dic-new.txt ochiro dic.txt ........

Сонгосон баганаас хайх

# ls --time-style=locale -l | awk '$6 == "Mar"' drwxr-xr-x 11 ochiro users 3064 Mar 1 14:34 desk-books drwxr-xr-x 2 ochiro users 784 Mar 2 09:53 Desktop -rw-r--r-- 1 ochiro users 13 Mar 7 13:55 dic-new.txt drwxr-xr-x 5 ochiro users 2664 Mar 6 10:43 downloads drwxr-xr-x 2 ochiro users 48 Mar 5 13:55 ftpserver drwxrwxrwx 7 ochiro users 400 Mar 5 18:03 wbt

Файл дотроос текст хайж(cursor) солиод(pointer) шинэ файлд хадгалах

# sed s/cursor/project_name/g TUTORIAL.txt > TUTORIAL_new.txt

Олон файлаас(*.txt) текст хайж(searchtext) солих(replacetext)

# find ./ -name *.txt -type f -exec sed -i 's/searchtext/replacetext/' {} \;

Хамгийн их хэрэглэсэн 10 командаа харах

# history|awk '{print $2}'|awk 'BEGIN {FS="|"} {print $1}' \ > |sort|uniq -c|sort -nr|head -10 125 ls 32 su 32 cd 26 vi 25 sudo 23 cat 19 ping 19 netstat 19 exit 18 ps

Сүүлийн нэг цагийн дотор өөрчөгдсөн файлууд

# find ~ -mmin -60 \! -type d /home/ochiro/.thunderbird/Mail/Junk /home/ochiro/.thunderbird/Mail/Sent /home/ochiro/.thunderbird/Mail/Inbox.msf /home/ochiro/.thunderbird/Mail/Drafts /home/ochiro/.thunderbird/Mail/Inbox /home/ochiro/.thunderbird/Mail/Junk.msf /home/ochiro/.thunderbird/Mail/Sent.msf /home/ochiro/.thunderbird/Mail/Drafts.msf /home/ochiro/TUTORIAL_new.txt /home/ochiro/dic.txt

Эх сурвалжууд:

• UNIX tips and tricks for a new user, Part 1: File maintenance tools
• UNIX tips and tricks for a new user, Part 3: Introducing filters and regular expressions
• UNIX tips and tricks for a new user, Part 4: Some nifty shell tricks
• Bash Reference Manual
• UNIX tips: Learn 10 good UNIX usage habits
• UNIX tips: Productivity tips
• AWK

VI - текст засварлагч

Анх юникс систем дээр ажиллаж эхлэх үед, тохиргооны файл засах зэрэгт ашиглахын тулд vi текст засварлагчийн командыг хажуудаа хэвлэж наачихсан хирнээ л мартчихаад байдаг байж билээ. Саяхан нэг юм хийх гэсэн чинь хоёр мөрийг нийлүүлэх, текст солих командуудыг санадаггүй. Ингээд мартсан командаа олж авахын хажуугаар бусад түгээмэл командуудыг мөн харж авав. Мартсан хүмүүст санахад, шинэ сурж байгаад хүнд хичээл болох болов уу гээд бичье.

vi -нь команд горим, оруулах горим гэсэн хоёр горимтойгоороо бусад текст засварлагч програмуудаас ялгаатай. Цөөхөн товчлуур шаардагддаг энгийн байх, дээр үеийн удаан сүлжээтэй орчинд хэмнэлттэй байх зэрэг нөхцөлүүдээс үүдэж ийм сонин байдлаар хийгдсэн болов уу. vi байхгүй юникс/линукс систем гэж байхгүй. Дараах командаар vi -г ажиллуулна.

$ vi test.txt

Хэрэв одоо ажиллаж байгаа директорид test.txt -нэртэй файл байвал тэр файлыг нээнэ, байхгүй бол шинэ файл үүсгэнэ. Анх ажиллангуут команд горимд байх ба энэ горимд байх үед товчлуурууд нь команд ажиллуулахад ашиглагдана. Харин текст оруулах горим буюу текст горимд байх үед товчлуурууд дээр дарахад текст бичигдэнэ.

Горим солих командууд a Курсорын араас текст оруулна i Курсорын өмнө текст оруулна A Мөрийн төгсгөлөөс текст оруулна I Мөрийн эхнээс текст оруулна o Одоо байгаа мөрний доор шинэ мөр нэмж текст оруулна O Одоо байгаа мөрний дээр шинэ мөр нэмж текст оруулна [ESC] Текст горимоос гарна

Курсор шилжүүлэхэд сумтай товчнуудыг хэрэглэж болох боловч зарим тохиолдолд сумтай товчнууд ажиллахгүй байх нь элбэг. Энэ үед h, j, k, l товчнуудыг хэрэглэнэ. Ер нь эдгээр товчийг хэрэглээд сурчвал гараа хол зөөхгүй давуу талтай тул сурахыг эрмэлзэх хэрэгтэй.

Нэг зайгаар шилжих h урагш нэг тэмдэгт шилжих l арагш нэг тэмдэгт шилжих j доош нэг мөр шилжих k дээш нэг мөр шилжи

Нэг нэг зай шилжихээс гадна, үгийн эхэнд очих, мөрийн төгсгөлд очих гэх мэт командууд байна.

Мөр дотор жилжих b үгийн эхэнд очих e үгийн төгсгөлд очих w дараагийн үгийн эхэнд очих ^ мөрийн харагдаж байгаа хамгийн эхний тэмдэгт дээр очих 0 мөрийн эхэнд очих $ мөрийн төгсгөлд очих

Дэлгэцээр гүйлгэх харах бол нүүр нүүрээр шилжих командуудийг хэрэглэнэ.

Дэлгэцээр шилжих командууд CTRL+F нэг нүүр хойшлох CTRL+B нэг нүүр урагшлах CTRL+D хагас нүүр хойшлох CTRL+U хагас нүүр урагшлах gg Файлын эхэнд очих G Файлын төгсгөд очих

Текст засварлах командууд

Текстийг устгах үед устгагдсан текст хадгалагдаж үлдэх бөгөөд түүнийг өөр газар хуулж тавьж болдог.

Устгах командууд x тэмдэгт устгах dw үгийн курсороос хойших хэсгийг устгах d$ мөрийн курсороос хойших хэсгийг устгах D мөрийн курсороос хойших хэсгийг устгах dd мөрийг устгах

Солих командаар текстийг өөрчлөхөд, [ESC] товч дарагдтал оруулах үйлдэл үргэлжлэх болно.

Солих/өөрчлөх командууд r тэмдэгтийг өөрчлөх cw үгийн курсороос хойшхи хэсгийг солих c$ мөрийн курсороос хойшхи хэсгийг солих C мөрийн курсороос хойшхи хэсгийг солих Ns N ширхэг тэмдэгтийг солих

Хайлтын командуудад regular expression ашиглаж болно. Хайлтын командууд нь [ENTER] товчоор төгсөх ёстой.

Хайлтын командууд /text текстийг арагш хайна ?text текстийг урагш хайна n хамгийн сүүлд хайсан текстийг өмнөх чиглэлд хайна N хамгийн сүүлд хайсан текстийг эсрэг чиглэлд хайна

Өгөгдсөн текстийг хайж олоод солиход дараах командыг ажиллуулна.

Хайж солих команд :%s/text1/text2/g[RETURN] text1 ийг text2 оор солино.

Тэкстийг бусад засварлагч шиг хуулж болох ба, хуулагдсан текст устгагдсан текстийн адил буферт хадгалагдана.

Хуулах командууд yw үгийн курсороос хойшхи хэсгийг хуулна y$ мөрийн курсороос хойшхи хэсгийг хуулна yy мөрийг хуулна Y мөрийг хуулна

Буферт байгаа хуулсан болон устгасан текстийг хаа нэг газар тавихад дараах хоёр командыг хэрэглэнэ.

Буферээс гаргах командууд p буферт байгаа текстийг курсорын өмнө гаргана P буферт байгаа текстийг курсорын араас гаргана

Буцах болон Давтах команд нь зөвхөн хамгийн сүүлчийн үйлдлийг л буцаана.

Буцах/Давтах команд u хамгийн сүүлчийн командыг буцаана CTRL+r буцаасан командыг дахин ажиллуулна . хамгийн сүүлд хийсэн командыг дахин ажиллуулна

Ихэнх текст засварлагчид дээр мөрийн эхэнд очоод устгах үйлдэл хийхэд өмнөх мөрийн араас залгагддаг бол vi дээр тэгдэггүй.

Мөр нийлүүлэх J Мөрийн төгсгөлд дараагийн мөрийг залгана

Хадгалах ба гарах командууд нь : аар эхлэх бөгөөд [ENTER] товчоор хэрэгжинэ.

Хадгалах ба гарах командууд :w файлыг хадгална :w NAME файлыг NAME нэрээр хадгална :w! NAME NAME нэртэй файлыг дарж хадгална :wq файлыг хадгалаад засварлагчаас гарна :q засварлагчаас гарна :q! хийсэн өөрчлөлтүүдийг хадгалалгүйгээр гарна

(:) -аар эхэлсэн командуудаас бусад командуудын өмнө давтах тоог оруулж бичсэнээр олон удаа ажиллууж болно. Жишээлбэл

10dd

гэж ажиллуулбал 10 мөрийг устгана.


Эх сурвалж

• UNIX tips and tricks for a new user, Part 2: The vi text editor
• VI (and Clone) Editor Reference Manual

Тестийг автоматжуулах нь

Програм хангамжын тест гэдэг нь чанарыг баталгаажуулах, хангах хамгийн чухал хэсэг бөгөөд чанарын шаардлагыг өндөрт тавьсан системийн хөгжүүлэлтэд сайн тестийн инженер, тэстийн баг, тэстийн хөрөнгө оруулалт зайлшгүй. Зарим хөгжүүлэгчид тестийг уйтгартай, үр ашиг багатай, ёс төдий зүйл мэтээр хүлээж авдаг нь тестийг хийх оновчтой, үр ашигтай арга барилыг бий болгоогүй, тестээр системийн алдаа сэвийг илрүүлэх сэтгэхүй байхгүйгээс тэр. Ингээд өөртэйгөө маргаж, энд тэндээс юм ухаж төнхөж байж олсон зүйлээ хуваалцья.

Програм хангамжын тестийг автоматжуулах, үр ашгийг дээшлүүлэх тухай

Тэстийг автоматжуулах ажлыг програм хангамж хөгжүүлэлтийн процессын дагуу ул суурьтай авч үзэж, төлөвлөгөөтэй, хөрөнгө хүч, цаг хугацаа зарцуулж, хэрэглэгчтэй, гүйцэтгэгчтэй, хүлээж буй тодорхой үр дүнтэй байж хийх ёстой болохыг энэ талын мэргэжилтнүүд нэгэн дуугаар зөвшөөрдөг.

Систем хөгжүүлэлтийн ажил юуны түрүүнд шаардлагыг тодруулах буюу хэрэглэгчид юу хэрэгтэй байгааг судласнаар эхэлдэг. Тэстийг автоматжуулах гэдэг маань гараар хийдэг тестийг автоматаар хийх гэж ойлгогдох нь хэнд ч илт. Иймд тэстийг автоматжуулахын өмнө гараар тестийг хийх процесс тодорхой болсон байх ёстой байх нь. Тестийн процесс байхгүй бол, байхгүй юмыг автоматжуулна гэдэг утгагүй. Ингээд эхний заавал хийх ёстой зүйл бол тестийн процессыг сайтар тодруулах юм. Тестийн загвар буюу тэстийг хэрхэн явуулах, ямар багаж хэрэглэх, яаж ажиллуулах, үр дүнг хэрхэн шалгах, тэстийн үед ашиглагдах файлуудын тайлбар, гарын авлагуудыг зэрэг үүнд багтана. Тухайн системийн тухай ерөнхий ойлголттой хэн ч байсан тестийг ажиллуулж дөнгөхөөр хэмжээнд тэстийн процессыг тодорхой болгох хэрэгтэй. Ингэж тодруулах явцад ямар хэсгийг хэрхэн өөрчилөн сайжруулж болох нь тодорч ирэх ч талтай. Үр ашиг муутай тестийн процессийг автоматжуулаад ч гарах үр дүн нь сайжрахгүй. Гараар хийгдэж байгаа тестийн үр ашгийг сайжруулах, илүү боловсронгуй болгох энгийн алхмуудыг хийхдээ, тестийн үр ашиг нь тухайн тестээр алдаа илрүүлэх магадлал, тестийг гүйцэтгэхэд амар хялбар байдал, илрүүлсэн алдааны байрлал болоод шалтгааныг тодорхойлоход хир дөхөмтэй зэргээр хэмжигддэг гэдгийг бодоорой.

Тэстийн процессыг тодорхой болгон баримтжуулж, зарим сайжруулалтуудыг хийсний дараа автоматжуулах шаардлагаа тодорхойлно. Ямар ч тодорхой хүлээсэн үр дүнгүйгээр ажлаа эхлэх нь автоматжуулагчид болон бусад хүмүүсийг залхаахад хүргэдэг. Ерөнхийдөө бол рилийзийг хурдасгах, тестийн тоог олшруулах, хүн хүчийг хэмнэх, өндөр мэдлэггүй хүмүүсээр тэст хийлгэх, тестийг найдвартай болгох зэрэг үр дүнг хүлээж болно. Харин яг ямар тестүүдийг автоматжуулах вэ? ажлаа хаанаас эхлэх вэ гэдэг асуудал дараагийн шатанд тавигдана.

Тэстийн автоматжуулалт ихэвчлэн регресс тест буюу өмнө ажиллуулаад шалгачихсан тестүүдийг дахин дахин ажиллуулах хэсгээс эхэлдэг. Кодод өөрчлөлт орох болгонд өмнөх ажиллаж байсан тестүүд хэвийн эсэхийг шалгана гэсэн үг. Нэгэнт ажиллуулаад туршчихсан учраас автоматжуулахад амар байхаас гадна, хамгийн гол нь олон дахин давтагдах учраас автоматжуулснаар олох ашиг нь их юм. Зарим тестийг огт автоматжуулах шаардлагагүй ч байж болно. Тухайлбал ганцхан удаа ажиллаад ахиж ажиллахгүй тэстийг автоматжуулах нь утгагүй. Мөн туйлын ярвигтай тестүүдийг автоматжуулахад их цаг хугацаа, хүч хөдөлмөр шаардах учраас гараар хийж байсан нь дээр. Ийм тестийг хүч зарцуулаад автоматжууллаа ч, тестийн кодод алдаа гарах магадлал их учраас дараа нь тэртэй тэргүй гараар ажиллуулж үнэмших хэрэгтэй болдог. Иймд бүх тестийг захаас аваад автоматжуулах гэхээсээ аль автоматжуулахад амар хирнээ, гарах ашиг нь харагдахуйц хэсгүүдээс эхлэх нь зүйтэй.

Ямар үр дүн хүлээх, тестийн аль хэсгийг автоматжуулахаа шийдсэн бол системийн хөгжүүлэлтийн дараагийн цикл болох хэрхэн хийх буюу дизайны шат руу орно.
Ингээд:

• Record/Playback загвар,
• Функционалаар задлах арга,
• Түлхүүр үгээр жолоодогдох

аргачлалуудыг авч үзье.

Record/Playback загвар нь хэрэгжүүлэхэд хамгийн хэцүү. Хэрэглэгчийн тест хийж байгаа бүх үйлдлийг бичиж аваад дараа нь автоматаар давтан ажиллуулах гэсэн энгийн арга боловч, төрөл бүрийн график дүрслэлийн орчин, шинэ шинэ технологи зэрэгтэй харьцах шаардлагатай учраас Record/Playback хийдэг програмууд их үнэтэй байдаг. Энэ арга сонсоход сайхан байгаа боловч яг бодит байдал дээр хэрэглэх үед бараг хэрэгцээгүй болчихдог. Учир нь хэрэглэгчийн үйлдлийг бичиж авах үед үүсэх скрипт нь өөрчлөгдөх, дахин засварлахад хүндрэлтэй учраас програмд жижиг засвар ороход тестийг дахин гараар ажиллуулж бичиж авах болдог. Хамгийн гажиг нь тэстийг бичиж авахын тулд тухайн үйлдэл заавал зөв ажиллаж байх ёстой. Тэгэхээр бичиж байх явцад ихэнх алдаа тохиолдох бөгөөд, алдааг засаж байж бичих үйлдэл дуусна. Ингэхээр гараар тестлэснээс ялгаа байхгүй биз дээ.

Функционалаар задлах арга нь тестийн тохиолдлуудыг үндсэн үйлдлүүдээр нь задлаж хоорондоо үл хамааралтай ортогональ скриптүүдийг хөгжүүлэх аргачлал юм. Хэрэглэгчийн функцүүд, Бизнесийн Функцийн скриптүүд, Дэд функцийн скриптүүд гэх мэтээр скриптүүдийг үечилж, эдгээр нь хаанаас дуудагдахаас хамаарахгүйгээр өөр өөрийн үйлдлийг гүйцэтгэх чадвартай байна. Жишээлбэл:

• Бизнесийн функцүүд : Гүйлгээ хийх скрипт, Мессеж илгээх скрипт
• Дэд функцүүд буюу туслах функцүүд : Өгөгдөл харьцуулах, Лог шалгах, Сэрвэр лүү холбогдох
• Хэрэглэгчийн функцүүд : Лог файл унших, сүлжээний холболт үүсгэх

Хамгийн гадна талд нь Жолоодогч скрипт байж, тестийг ажиллуулна. Жолоодогч скрипт нь дотроо "Тестийн тохиолдлууд"-ыг дуудсан байна. Тэстийн тохиолдол бүр нь тестийн логикийг Бизнес функцийн скриптүүдээр ажиллуулна. Дэд функцүүд болон бусад туслах скриптүүд нь хаанаас ч дуудагдаж болно.

Жолоодогч скрипт:
* * Орчны тохиргоо болон бусад шаардлагатай үйлдлүүдийг хийж дуусаад "тестийн тохиолдлууд"-ыг дэс дараалан ажиллуулж эхлэнэ.
Тестийн тохиолдлын скрипт:
* * Тестийн логикийг Бизнес функцийн скриптүүдийг дуудаж ажиллуулна.
Бизнес функцийн скрипт:
* * Програмын тодорхой функцүүдийг хэрэгжүүлнэ
Дэд функцын скриптүүд:
* * Бизнес функцыг хэрэгжүүлэхэд шаардлагатай програм дотор түгээмэл ашиглагдах дэд функцүүд.
Хэрэглэгчийн функцүүд:
* * Ерөнхий, Дэлгэцтэй харьцах, Сүлжээтэй харьцах
* * Эдгээр нь хаанаас ч дуудагдаж болно.

Тухайлбал Сервэртэй холбогдолт үүсгэх -гэдэг тэстийн тохиолдол дараах байдлаар бичигдэж болно.

Сервертэй холбогдох:

1. Тохиргооны файлаас сервэрийн хаягийг унших
2. Сэрвэртэй холбогдох хүсэлтийг сүлжээгээр илгээх
3. Хариултыг хүлээж авах
4. Холбогдсон эсэхийг шалгах

Сэрвэртэй холбогдох хүсэлтийг сүлжээгээр илгээх- дэд функцыг цааш задалвал:

1. Сэрвэртэй TCP/IP холболт үүсгэх
2. Холбогдогдох хүсэлт-ийн мессежийг бэлдэх
3. Мессежийг TCP/IP холболтоор дамжуулах

Дээрхээс харвал "Сэрвэртэй холбогдох хүсэлтийг сүлжээгээр илгээх"- дэд функц нь ерөнхий зориулалтийн "Мессеж илгээх" -гэдэг функц байж болохоор байна. Үүний тулд өгөгдлийг функцээс салгах хэрэгтэй, тестийн тохиолдолд харгалзах өгөгдлүүд болон хүлээх үр дүнг тестийн скриптүүдээс тусдаа файлд хадгалснаар шинэ тестүүдийг үүсгэхэд хялбар болох юм. Энэ арга нь дахин дахин ашиглагдаг скрипт модулиудыг ашиглаж тестийн өгөгдөл болон шалгах нөхцөлийг файлд хадгалснаар нилээд хөдөлмөр хэмнэж байгааг ч, дараах сул талуудтай.

• Скрипт хэлний өндөр мэдлэг шаарддаг
• Тестийн тохиолдол болгонд хэд хэдэн текст файл шаардлагатай болох учраас эдгээр файлуудыг зохицуулахад хүндрэл гардаг
• Тэстчин тестийн төлөвлөгөөг нарийвчилсан өгөгдлийн хамт гаргахын хажуугаар эдгээр өгөгдлүүдийг тусгай форматтайгаар текст файлуудад оруулж тестэнд бэлдэх шаардлагатай.
• Энгийн текст файлуудыг анхааралтай үүсгэхгүй бол формат зөрснөөс болж тестийн скриптүүд буруу ажиллаж болно

Түлхүүр үгээр жолоодогдох арга буюу Тестийн төлөвлөгөөгөөр жолоодогдох арга нь өмнөх аргын сайн талуудыг шингээхээс гадна ихэнх сул талуудыг үгүйсгэж чаддаг. Ажиллах зарчим ерөнхийдөө адилхан боловч тестийн өгөгдлийг дүрслэх арга нь өөр юм. Шууд хүснэгтэн аргаар бэлдсэн тестийн төлөвлөгөөн дээр тулгуурлаж скриптүүд ажилладаг.

Түлхүүр үг	Байрлал	Оролт/Шалгах Өгөгдөл	Тайлбар	OK/NG
Connect	10.10.10.20		Сэрвэр лүү холбогдох
Send	10.10.10.20	0x87467348	Холбогдох хүсэлт явуулах
Receive	10.10.10.20		Хүсэлтийн хариуг хүлээж авах
Check	app_log.txt	"Connected to server : 10.10.10.20"	Холбогдсон эсэхийг шалгах

Дээрх хүснэгтийг ямар нэг хүснэгт боловсруулах програмаар бэлдээд текст хэлбэр лүү хөрвүүлэх тул, контроллер скрипт тэр текст файлыг мөр мөрөөр нь уншиж мөрийн эхэнд байх түлхүүр үгэнд харгалзах скриптийг, бусад нүдэн дэх мэдээллийг параметр байдлаар дамжуулан ажиллуулна. Энэ аргын давуу тал нь тестийн төлөвлөгөөг шууд тестийн өгөгдөл болгож ашиглаж байгаагаас гадна, тестийг ажиллуулах хүн зөвхөн түлхүүр үгнүүдийг судлахад л болохоор байгаа. Тестийн өгөгдлөө бэлдээд ганц командаар тестүүдээ ажиллуулах боломжтой боллоо. Мөн дээр хүснэгтийг харж байгаад гараар тестийг ажиллуулах ад ч эвтэйхэн гэдэг нь харагдаж байна.

Тестийн процессыг сайжруулах, тестийг автоматжуулахад яг хөгжүүлэлтийн орчинтой адил тестийн тусдаа орчин хэрэгтэйг онцлон анхаарах хэрэгтэй. Хөгжүүлэлтэд хэрэглэж байгаатай яг адилхан програм хангамж, тохиргоо, техник байх ёстой.

Тестийн скрипт гэдэг нь бас л програм хангамж код учраас эх кодын удирдлагаар хангаж, сайн програмчин хуваарилж, хэрэглэгчид болох тестчидэд зориулж тайлбар, гарын авлага хийх нь зүй. Ер нь тест хийнэ гэдэг, зөвхөн тестийг ажиллуулаад OK/NG гэж бичихийн нэр биш, кодыг шинжилж судлаж, ухаж төнхөж байж жинхэнэ утгаар нь хэрэгжүүлдэг болохыг байнга санах хэрэгтэй. Энд тэстийг автоматжуулах тухай ярьж байгаа болохоос автоматаар тэстлэх гэж яриагүй билээ. Тест гэдэг бол системийн ажиллагааг үнэмжих, батлах процесс. Хэрэв тестийг бүрэн автоматжуулсан гэвэл тэстийн үр дүнг хэрхэн үнэмших вэ? Бүрэн автомат байлаа гэвэл, түүнийг өөрийг нь зөв ажиллаж байгааг бас тестлэх хэрэгтэй болно. Иймд гар тест ямагт байх ёстой бөгөөд автоматаар хийж байгаа тестийг хэзээ хүссэн цагтаа гараар хийж шалгах боломжтой байх ёстой. Иймд сайн тестчин хэзээд хэрэгтэй, үнэ цэнэтэй байх болно. Тестчин хүн ажлынхаа зарим хэсгийг автоматжуулснаар тестийн нөхцөлүүдээ баяжуулах, тэстийн скриптээ сайжруулах гээд илүү ашигтай ажилд анхаарал хандуулах боломжтой болно.

::Дүгнэлт::

Тестийг автоматжуулах нь тестлэх гэж байгаа кодыг бичихээс техникийн хувьд ч, менежментийн хувьд ч дутахгүй ажил учраас систем хөгжүүлэлтийн төслийн адилаар хүн хүч, нөөц шаардах ёстой аж. Тэстийг автоматжуулахад зайлшгүй шаардлагатай хүний нөөц бол тестийн скриптийг хөгжүүлэх туршлагатай програмчин, тестийг амжилттайгаар үргэлжлүүлэх сайн тестчиний орон тоо юм. Зөв арга барил сонгож, нөхцөл байдлаар хангаж чадвал тестийг автоматжуулснаар зөвхөн тестийн хувьд ч биш, бүхэл төслийн хувьд үр ашиг гаргаж, системийн чанарыг нэмэгдүүлэх боломжтой.

Хэрэглэсэн эх сурвалжууд:

• When Should a Test Be Automated? - Тэстээ автоматжуулах уу үгүй юу? Автоматжуулснаар олох ашиг их үү, алдах зүйл их үү? Автомат тест маань хир урт настай бол? Автомат тестэд орж байгаа код хир тогтвортой вэ? Хэрэв тестүүдээ автоматжуулахаар зэхэж байгаа бол энэ өгүүллийг уншиж үзээрэй.
• Four lessons for software testers (and their managers) - Тэстийн багт байх ёстой зан чанаруудын тухай-үргэлж шинийг эрэлхийлж, тэстлэж буй кодоо ухаж шинжиж, дэд хэсгүүдийг интерграц хийж, өөрчлөлтийг ухамсарладаг байх ёстой.
• Seven Steps to Test Automation Success - Тэстийг автоматжуулах ажлыг мөн л системийг хөгжүүлэх процессийн дагу хийхийн сацуу, онцлог шинж чанаруудыг тусгах хэрэгтэй тухай маш сайхан бичсэн. Эндээс санаа авах зүйл маш их байгаа.
• How Effective is Your Test Automation? - Автомат тэст үнэхээр тестлэх ёстой зүйлээ тэстлэж байгаа болов уу? Хүний оролцоогүй бүрэн автомат тэстэд яаж итгэх вэ? Тэстийн кодонд алдаа байвал яах вэ? Тестийг зөв хэрэгжүүлээгүй бол яах вэ? Гэх мэт автомат тестийн сэжигтэй цэгүүдийг авч үзсэн.
• Totally Data-Driven Automated Testing - Өгөгдлөөр жолоодогдох автомат тестийг хэрхэн хэрэгжүүлэх тухай, туршлагатай мэргэжилтний бичсэн өгүүлэл. Эндээс тэстийн төлөвлөгөөг хэрхэн автомат тэст болгох санааг олж авав.

Тэстийн талаарх бусад эх сурвалжууд:

• Software Testing Institute - Software Testing Publications - Тэстийн институтийн вэб дээрх тэстийн талаар хэвлэгдсэн номуудын жагсаалт. Номын жагсаалтаас гадна бусад мэдээлэл нь ч чухал.
• Automated Testing Specialists - Articles - Автомат тест болон тестийн талаарх өгүүллүүд.
• Maverick Software Consulting -- Books - Програм хангамжын тэст болон тэстийн автоматжуулалтын тухай номын жагсаалт.
• Cem Kaner - Publications - Тэстийн мэргэжилтэн Cem Kaner-ийн материалууд.