Category: Software Testing

จากตอนที่ 1 เราได้ทราบภาพรวมกิจกรรมและขั้นตอนต่างๆ ทั้งหมดในการทดสอบซอฟต์แวร์กันไปแล้ว ตอนที่ 2 ผู้เขียนจะลงลึกในรายละเอียดขั้นตอนที่ 1 ของการทดสอบซอฟต์แวร์กันค่ะ โดยขั้นตอนที่ 1 นั่นก็คือ

1. ผู้ทดสอบรับการถ่ายทอดการทำงานของซอฟต์แวร์ที่จะทดสอบจากนักพัฒนาโปรแกรม

ขั้นตอนนี้เป็นการถ่ายทอดการทำงานของซอฟต์แวร์จากนักพัฒนาโปรแกรมให้กับผู้ทดสอบเพื่อให้ผู้ทดสอบทราบภาพรวม ขอบเขตและเข้าใจการทำงานทั้งหมดของซอฟต์แวร์ก่อนเริ่มการทดสอบ รวมถึงรวบรวม Task Test ทั้งหมดของซอฟต์แวร์ที่จะทดสอบค่ะ

ผู้เขียนขอย่อยการดำเนินการในขั้นตอนที่ 1 เพื่อให้เข้าใจง่าย ๆ ตาม Flowchart นี้นะคะ

อธิบายดังนี้ ค่ะ

1. เริ่มจากการนัดหมายเวลาในการถ่ายทอดการทำงานของวอฟต์แวร์กันก่อนค่ะ โดยนักพัฒนาโปรแกรมจะนัดวันเวลาที่จะถ่ายทอดการทำงานของซอฟต์แวร์ให้กับผู้ทดสอบกับผู้จัดการโครงการ ซึ่งจะต้องนัดล่วงหน้า ระยะเวลาเท่าไหร่นั้นก็ตามแล้วแต่เห็นสมควรและพิจารณากันเอาเองค่า อย่างทีมของผู้เขียน ก็จะนัดอย่างน้อย 1 สัปดาห์ก่อนเริ่มการทดสอบค่ะ (นัดทำไม นัดกันให้ชัดเจน จะได้เตรียมตัวเตรียมใจถูกเตรียมสมองให้โล่งงงงค่ะกันถ้วนหน้าค่ะ)

2. เมื่อได้วันเวลากันเรียบร้อยแล้ว ผู้จัดการโครงการก็แจ้งวันเวลาที่นักพัฒนาโปรแกรมจะถ่ายทอดการทำงานของซอฟต์แวร์ให้กับผู้ทดสอบรับทราบค่ะ (PM ซึ่งถือว่ามีอำนาจการจัดการบริหารในทีม ก็จะมาแจ้งให้ทราบบ อิอิ สบายใจกันทุกฝ่ายค่ะ)

3. เมื่อถึงวันเวลาตามที่ได้นัดหมายไว้ นักพัฒนาโปรแกรมก็จะมาถ่ายทอดการทำงานของซอฟต์แวร์ให้กับผู้ทดสอบค่ะ ในขั้นนี้โปรแกรมเมอร์ต้องถ่ายทอดการทำงานของซอฟต์แวร์ให้กับผู้ทดสอบอย่างละเอียด และจัดเตรียม Software Requirements Specification และ Functional Design ของซอฟต์แวร์มาให้กับผู้ทดสอบด้วยนะคะ (จะได้ใช้เป็นข้อมูลตอนทดสอบค่ะ บางทีที่จดๆๆ เข้าใจมา ก็อาจจะผิดพลาดได้)

–> ในการถ่ายทอดการทำงานของซอฟต์แวร์

นักพัฒนาโปรแกรมต้องอธิบาย ภาพรวมทั้งหมดและการทำงานของซอฟต์แวร์ว่ามีการทำงานอะไรบ้างและทำงานอย่างไร ซอฟต์แวร์มีข้อจำกัดอะไรบ้างเพื่อผู้ทดสอบจะได้เข้าใจและทราบข้อมูลที่จะนำไปทดสอบ

–> โดยในระหว่างการถ่ายทอดการทำงานของซอฟต์แวร์ หากผู้ทดสอบมีข้อสงสัยเกี่ยวกับการทำงานของซอฟต์แวร์

ผู้ทดสอบควรซักถามจากนักพัฒนาโปรแกรมหรือศึกษาจาก Software Requirements Specification และ Functional Design ของซอฟต์แวร์ที่จะทดสอบให้เข้าใจนะคะ ไม่ควรเก็บข้อสงสัยนั้นไว้หรือทดสอบซอฟต์แวร์ไปตามความคิดของตนเองเพราะจะส่งผลให้การทดสอบนั้นดำเนินการไปในแนวทางที่ไม่ถูกต้อง การทดสอบอาจล่าช้ากว่าที่ได้กำหนดไว้ซึ่งเกิดจากผู้ทดสอบเอง และอาจไม่สามารถค้นหาข้อผิดพลาดที่มีอยู่ของซอฟต์แวร์ได้ค่ะ

ผู้เขียนได้รวบรวมข้อมูลจากประสบการณ์ทดสอบซอฟต์แวร์ที่ผ่านมา และสรุปเป็นข้อมูลที่ผู้ทดสอบต้องทราบก่อนเริ่มการทดสอบซอฟต์แวร์เอาไว้ด้วยค่ะ ไว้จะมาแชร์ไว้ในบทความหน้าให้อ่านกันนะคะ (อัพเดท ตามไปอ่านกันได้ที่ บความเรื่อง 7 ข้อมูลที่ผู้ทดสอบต้องทราบก่อนเริ่มการทดสอบซอฟต์แวร์ นะคะ)

ส่วนบทความนี้มาต่อที่ขั้นตอนถัดไปกันก่อนนะคะ

4. เมื่อผู้ทดสอบทราบข้อมูลก่อนการทดสอบซอฟต์แวร์แล้ว ให้บันทึกข้อมูลเหล่านั้นลงในฟอร์มบันทึกการทดสอบและผลการทดสอบส่วนที่ 1 คือ Test Information ที่ได้จัดเตรียมไว้ค่ะ ตัวอย่างค่ะ

และขั้นสุดท้ายยยยยยยยยยยยย

5. ผู้ทดสอบรวบรวบการทำงานทั้งหมดของซอฟต์แวร์ที่จะทดสอบโดยรวบรวมจาก Function หรือ Use Case ของซอฟต์แวร์ซึ่งตรงตามข้อกำหนดของซอฟต์แวร์ที่ได้ระบุไว้ (หากโปรแกรมมีผู้ใช้หลายบทบาทให้แยก Task Test ตามบทบาทการใช้งาน) โดย Function เหล่านั้นจะถูกบันทึกเป็น Task Test ในการทดสอบและระบุ Task Test No. เอาไว้ (1 Task Test เท่ากับ 1 ชุดการทดสอบ) เพื่อเตรียม Test Step และออกแบบ Test Case สำหรับทดสอบแต่ละ Task Test ในขั้นตอนต่อไป

สำหรับ Task Test No. นั้นแนะนำให้ตั้งโดยใช้ตัวอักษรย่อเพียงสองถึงสามตัวและตามด้วยตัวเลขที่จะเรียงลำดับไปเรื่อย ๆ เช่น TE001 เป็นต้น

Task Test คือ ชุดการทดสอบของแต่ละการทำงาน (Function) ต่าง ๆ ของซอฟต์แวร์

ตัวอย่างค่ะ

สำหรับรายละเอียดของขั้นตอนที่ 1 ก็มีเท่านี้ค่ะ ส่วนบทความหน้านั้น ผู้เขียนจะมาแชร์ข้อมูลที่ผู้ทดสอบต้องทราบก่อนเริ่มการทดสอบซอฟต์แวร์ไว้ให้นะคะ และบทความถัดไปจะลงลึกในรายละเอียดขั้นตอนที่ 2 (#3) กันต่อค่ะ

หลังจากที่เราเริ่มเขียน Test Script ไปสักพัก ก็จะเริ่มมี Test Step ที่เรามักต้องทำซ้ำ ๆ กัน เช่นเวลาเริ่มต้นและส่วนท้ายของ Test Script ทำให้ Test Script ของเราดูรก อ่านยาก มี Code ซ้ำ ๆ กันเต็มไปหมด และ Test Script เองก็มี Step ที่ไม่เกี่ยวกับการ Test ปนมาเพียบเลย

วันนี้เลยขอเสนอให้ลองใช้ Setup และ Tear Down เพื่อช่วยลด Step เหล่านี้จาก Test Script ของเราดู โดย Setup และ Tear Down คืออะไรมารู้จักกัน

Suite Setup = ก่อนที่จะเริ่ม Run Test ทั้งหมด จะต้องเริ่มการทำงานตัวนี้ก่อน

Suite Teardown = หลังจาก Run Test เสร็จทั้งหมดแล้วจะสั่งให้ทำอะไรตอนสุดท้าย

Test Setup = ก่อนที่จะเริ่มเข้า Test Case ให้เริ่มการกระทำนี้ก่อน

Test Teardown = หลังจากจบ Test Case แต่ละ Case ให้ทำการกระทำนี้

ตัวอย่าง

จากรูปด้านบน ก่อนที่จะเริ่ม Run Test ทั้งหมด ให้เริ่มทำการเปิด Browser ก่อน เมื่อเริ่ม Test Case ให้แสดงคำว่า Start!!! และเมื่อจบ Test Case ให้แสดงคำว่า “Finish!!!” แล้วพอจบ Test ให้ทำการ ปิด Browser นี้

ดังนั้น กรณีหากเรามี Case แค่ Case เดียวอาจจะไม่จำเป็นที่จะต้องใช้ Test Setup กับ Test Teardown ก็ได้ เพราะว่าเราสามารถใช้ Suite Setup ในการเริ่มต้น และ Suite Teardown ในการจบการกระทำเลยก็ได้

***สมมติว่า Test Case เรามี Pre-Condition ที่มี Step เหมือนกันทุก Test Case ก็ควรเอา Step นี้อยู่ใน Test Setup

ข้อดีของ Setup และ Teardown

• ลดความซ้ำซ้อนของแต่ละ Test Script ลง ช่วยให้ดูง่ายขึ้น
• ช่วยทำให้เราโฟกัส กับสิ่งที่เราต้องการจะ Test ในแต่ละ Test Case ได้จริงๆ โดยไม่มี Setup Step และ Teardown Step มาทำให้ดูวุ่นวาย เกินความจำเป็น
• ช่วยเครียร์ Test Environment เสมอก่อนจากรัน Test และหลังจากรัน Test เสร็จ
• ถึง Test จะ Failed  แต่ Teardown ก็ยังทำงานต่อ จึงมั่นใจได้ว่า Test Environment ของเราสะอาดเสมอก่อนจะรัน Test ข้อต่อไป ^_^

สวัสดีค่ะ … ถึงเวลาซ๊ากที ฤกษ์งามยามดี กลิ่นดอกพญาสัตบรรณเลือนหาย แสงแดดสาดส่องแทนที่ ฤดูร้อนถามหา ณ เพลานี้เราได้พบกัน 🌼🌼

ก็ว่ากันตามหัวข้อของบทความ เรื่องราวเหมือนจะไม่เครียดแต่จริง ๆ ก็วิชาก๊านน วิชาการอยู่นะคะ ฮาา 😉
ผู้เขียนจำได้ว่าสมัยเรียนป. ตรี (ก็ผ่านมายังไม่กี่ปีหรอกค่ะ ฮรี่ ๆ) Software Testing เป็น หัวข้อหนึ่งที่ผู้เขียนต้องเรียนด้วยค่ะ .. และผ่านมาไม่กี่ปี
ปัจจุบันผู้เขียนก็ได้มีโอกาส (ที่เรียกว่าบทบาทหน้าที่) เป็นผู้ทดสอบซอฟต์แวร์มาแล้วหลาย ๆ โปรแกรมค่ะ (อ๊ะไม่กี่ปีเหรอ ?) จึงได้รวบรวมข้อมูลและประสบการณ์เอาไว้ และถือโอกาสนี้มาเขียนบทความแชร์ให้กับผู้อ่านเพื่อเป็นแนวทางและ/หรือความรู้เล็ก ๆ น้อย ๆ ได้นำไปใช้ในการทดสอบซอฟต์แวร์ซึ่งถือเป็นขั้นตอนหนึ่งที่สำคัญไม่น้อยไปกว่าขั้นตอนอื่นในกระบวนการพัฒนาซอฟต์แวร์กันค่ะ

สำหรับเนื้อหาหลักของบทความนี้ (ตอนที่ 1) ผู้เขียนจะนำเสนอข้อมูลและแชร์ประสบการณ์ให้กับผู้อ่านทราบเกี่ยวกับกิจกรรมและขั้นตอนต่าง ๆ ของการทดสอบซอฟต์แวร์กันก่อนค่ะ ในตอนต่อไปเราจะลงลึกไปแต่ละขั้นตอนพร้อมตัวอย่าง และประสบการณ์ที่ผู้เขียนอยากจะแชร์ให้ผู้อ่านได้ทราบกันนะคะ (เผื่อว่าเราจะได้มาระดมสมอง ช่วยแสดงความคิดเห็นกันเข้ามา และ/หรือผู้อ่านจะมีข้อเสนอแนะให้กับผู้เขียน ถือว่าเป็นการแลกเปลี่ยนกันค่ะ)
การทดสอบซอฟต์แวร์ที่ผู้เขียนจะมาแชร์นั้น จะเป็นการทดสอบแบบ Functional Testing โดยใช้เทคนิค Blackbox Testing และทดสอบแบบ Manual นะคะ

แต่ก่อนที่เราจะเข้าสู่เนื้อหาหลักของบทความนี้กันนั้น ผู้เขียน (ขอ) อธิบายนิยาม/ความหมายของ Software Testing รวมถึง Manual Testing, Functional Testing และ Blackbox Testing กันก่อนนะคะ เพื่อทั้งผู้อ่านและผู้เขียนจะได้ทบทวนกันซักหน่อย และทำความเข้าใจไปพร้อม ๆ กันค่ะ (อิอิอิ) 😊

Software Testing หรือการทดสอบซอฟต์แวร์ คืออะไรกันน่ะ ?

การทดสอบซอฟต์แวร์ หรือ Software Testing ก็คือ กระบวนการในการประเมินและปรับปรุงคุณภาพของซอฟต์แวร์โดยการค้นหาข้อผิดพลาดและ/หรือจุดบกพร่องของซอฟต์แวร์ที่มีอยู่ให้ปรากฏออกมา แล้วสามารถระบุแนวทางที่ทำให้เกิดขึ้นได้และก็ทำการแก้ไข ค่ะ

Manual Testing คืออะไร ?

Manual Testing ก็คือ การทดสอบที่ดำเนินการโดยไม่ได้ใช้เครื่องมืออัตโนมัติ (Automated Tool) หรือสคริปต์ (Script) โดยผู้ทดสอบจะ Run Test ตาม Test Plan, Test Case หรือ Test Scenarios ด้วยมือของผู้ทดสอบเองนั่นแหละค่ะ
[Manual คำศัพท์ทางวิศวกรรม ความหมาย คือ คู่มือ, (งาน) ทำด้วยมือ]

อ่านถึงตรงนี้ผู้อ่านบางท่านอาจตั้งคำถามในใจ และ/หรืออุทาน ออกมาว่า “เดี๋ยวนี้เค้าทำ Automated Testing กันแล้วน่ะ ทำไมยัง Manual กันนี่ ! ” ก็เพราะว่า …………..

อืม ….. ยังไงผู้เขียนก็คิดว่า การที่เราจะตัดสินใจลงมือทดสอบแบบ Automated เลยแบบสุ่มสี่สุ่มห้า (รวมถึงเรื่องอื่นในชีวิต Drama ซะงั้น ฮาาา) โดยไม่ได้ดูถึงความเหมาะสมความคุ้มค่า ไอ้ที่เค้าว่าดีนั้น ก็อาจจะไม่ดีเพราะไม่ได้เหมาะสมกับการทดสอบโปรแกรมที่เราจะทดสอบก็ได้ และผู้เขียนเชื่อว่า เราจะ Automated ได้ดีนั้น ยังไงก็ต้อง Manual ได้ดีระดับหนึ่งก่อน มีความเข้าใจ และมีประสบการณ์มาก่อน เหมือนเป็นพื้นฐานที่สำคัญค่ะ อีกอย่างสุดท้ายเมื่อเรามีประสบการณ์การทดสอบซอฟต์แวร์ไประยะหนึ่งแล้ว เราก็จะพบว่าการทดสอบโปรแกรมหนึ่ง ๆ นั้น ยังไงก็ต้องทดสอบแบบ Manual ร่วมกับ Automated อยู่ดี จะ Automated 100% เลยก็อาจจะไม่ครอบคลุมทั้งหมดได้
และเอาเป็นว่า ………. ผู้เขียนจะมาเล่าเรื่องนี้ให้ละเอียดกัน (ตามที่ผู้เขียนได้ประสบพบเจอ ศึกษาหาข้อมูลมา) ซักบทความหนึ่งในโอกาสหน้านะคะ ตอนนี้ก็เริ่ม ๆ มาจับ ๆ ถู ๆ เอ้ยยยยย ศึกษา Automated Test บ้างแล้วค่ะ ส่วน Tool ตัวไหนนั้น ขออุบส์ไว้ก่อนนะคะ กลัวจะไม่เวิคคค แฮร่ ไปซะไกลแล้วววจร้าาา เรามาว่ากันด้วยเนื้อหาของตอนที่ 1 ต่อกันดีกว่า ๆ นะคะ

Functional Testing คืออะไร ?

Functional Testing คือ การทดสอบการทำงานของซอฟต์แวร์ว่าสามารถทำงานได้ครบถ้วนและถูกต้องตรงตามข้อกำหนดซอฟต์แวร์ที่ระบุไว้หรือไม่ โดยเราจะมุ่งเน้นตรวจสอบความถูกต้องของ Output ที่ออกมาค่ะ

แล้ว Blackbox Testing ล่ะ คืออะไร ?

Blackbox Testing หรือการทดสอบแบบกล่องดำ ก็คือ การทดสอบที่ไม่คำนึงถึงคำสั่งภายในซอฟต์แวร์ (เปรียบเหมือนกล่องดำที่มองไม่เห็นอะไรข้างใน) เป็นการทดสอบการทำงานของซอฟต์แวร์ตามความต้องการ (Requirements) ที่มี โดยดูค่าผลลัพธ์ที่แสดงออกมา (Output) จากข้อมูลนำเข้า (Input) ที่ให้กับซอฟต์แวร์ว่ามีความสอดคล้องกันหรือไม่ค่ะ ซึ่งถ้าโปรแกรมทำงานถูกต้องก็คือ Ouput ต้องสอดคล้องกันกับ Input นั่นเอง

ทบทวนนิยาม/ความหมาย กันแล้ว ผู้เขียนขออธิบายในส่วนกิจกรรม ขั้นตอนการทดสอบซอฟต์แวร์ต่อเลยนะคะ

ก่อนเริ่มการทดสอบซอฟต์แวร์ของทีมพัฒนาของผู้เขียนนั้น

ผู้ทดสอบจะต้องได้รับการถ่ายทอดการทำงานของซอฟต์แวร์จากนักพัฒนาโปรแกรมจนเข้าใจเสียก่อน ซึ่งจริง ๆ ก็พอจะเข้าใจภาพรวมการทำงานของโปรแกรมที่จะทดสอบอยู่แล้วค่ะ เพราะผู้ทดสอบเองก็ได้เข้าไปมีส่วนร่วมตั้งแต่เก็บรวบรวมความต้องการของโปรแกรมแล้วก่อนเริ่มพัฒนาค่ะ – ตรงนี้ถือว่าได้มาทำความเข้าใจ ทบทวนร่วมกันอีกซักครั้งเพื่อให้เข้าใจตรงกันก่อนจะเริ่มทดสอบโปรแกรมของเรากันนะคะ

เมื่อทดสอบเรียบร้อยแล้ว ผู้ทดสอบก็จะส่งมอบเอกสารซึ่งได้จากการทดสอบ (Test Report และ Defect Log) ให้กับนักพัฒนาโปรแกรมพร้อมกับการทบทวนผลการทดสอบร่วมกับทีมพัฒนาเพื่อรับทราบรายการข้อผิดพลาดและข้อเสนอแนะของโปรแกรมที่ได้จากการทดสอบ และนักพัฒนาโปรแกรมดำเนินการแก้ไขปรับปรุงโปรแกรมตามรายการเหล่านั้นต่อไปค่ะ

เมื่อนักพัฒนาโปรแกรมแก้ไขปรับปรุงโปรแกรมเสร็จเรียบร้อยแล้ว ก็จะแจ้งให้กับผู้ทดสอบทราบ เพื่อทำการทดสอบผลการแก้ไขปรับปรุงเหล่านั้นอีกครั้งหนึ่งก่อนปิดการทดสอบเมื่อรายการข้อผิดพลาดและข้อเสนอแนะเหล่านั้นได้รับการแก้ไขปรับปรุงเรียบร้อยแล้ว หลังจากนั้นจึงจะจัดทำคู่มือการใช้งานซอฟต์แวร์ อบรมการใช้งานให้กับผู้ใช้ และแจ้งนักพัฒนาโปรแกรมเพื่อติดตั้งใช้งานซอฟต์แวร์ต่อไปค่ะ

จากภาพรวมกิจกรรมต่าง ๆ ในการทดสอบซอฟต์แวร์ที่ผู้เขียนได้อธิบายไปข้างต้น ผู้เขียนจึงขอสรุปเป็นขั้นตอนการทดสอบซอฟต์แวร์ทั้งหมด 8 ขั้นตอนเพื่อให้เข้าใจง่าย ๆ (เราจะลงลึกแต่ละขั้นตอนในบทความตอนต่อไปนะคะ) ดังนี้ค่ะ

1. ผู้ทดสอบรับการถ่ายทอดการทำงานของซอฟต์แวร์ที่จะทดสอบจากนักพัฒนาโปรแกรม (Preparation Testing)

2. ผู้ทดสอบเตรียมเหตุการณ์ทดสอบ ออกแบบกรณีทดสอบ และยืนยันความถูกต้อง (Test Development and Verify)

3. ผู้ทดสอบทดสอบซอฟต์แวร์และเปรียบเทียบผลการทดสอบ (Test Execution)

4. ผู้ทดสอบรายงานผลการทดสอบ (Test Reporting)

5. ผู้ทดสอบทบทวนผลการทดสอบร่วมกับทีมพัฒนาซอฟต์แวร์ (Test Result Analysis)

6. นักพัฒนาโปรแกรมแก้ไขปรับปรุงข้อผิดพลาดและข้อเสนอแนะของซอฟต์แวร์ และแจ้งให้ผู้ทดสอบรับทราบผลการแก้ไข (Defect Fixing)

7. ผู้ทดสอบรับทราบผลการแก้ไขซอฟต์แวร์ ทดสอบผลการแก้ไขและปิดการทดสอบ (Defect Retesting and Closure)

8. นักพัฒนาโปรแกรมติดตั้งใช้งานซอฟต์แวร์

สำหรับตอนที่ 1 ผู้เขียนขอจบไว้เท่านี้ก่อนนะคะ โดยในตอนถัดไป เราจะมาลงลึกกันแต่ละขั้นตอนพร้อมตัวอย่างแต่ละขั้นตอนเพื่อจะได้เข้าใจกันมากขึ้นค่ะ

ปล. เนื้อหาในบทความนี้ได้ปรับปรุงเนื้อหาจากคู่มือเรื่อง “การทดสอบซอฟต์แวร์ด้วยกลยุทธ์การทดสอบแบบกล่องดำ (Black Box Testing) สำหรับเจ้าหน้าที่บริการลูกค้าระบบสารสนเทศบุคลากร” เพื่อให้ผู้อ่านอ่านได้ง่ายขึ้น คู่มือดังกล่าวนั้น ผู้เขียนได้จัดทำขึ้นมาโดยรวบรวมข้อมูลจากประสบการณ์การทดสอบซอฟต์แวร์ของผู้เขียนเอง ร่วมกับการศึกษาข้อมูลเพิ่มเติมจากแหล่งความรู้และ/หรือผู้มีความรู้ท่านอื่น ๆ สำหรับอ้างอิงแหล่งข้อมูลต่าง ๆ นั้น ผู้อ่านสามารถดูได้จากคู่มือดังกล่าวนะคะ

ทำไม Tester ต้องรู้จัก Web Element Locator ก็เพราะว่าทุกสิ่งทุกอย่างที่ทุกคนเห็นบนหน้าเว็บ มันคือ Web Element และ Robot Framework ก็รู้จัก หน้าเว็บจาก  Element Locator ที่เหล่า Tester กำหนดให้ในแต่ละ Test script นั่นเองค่ะ ดังนั้น Tester ควรจะต้องรู้จัก Element Locator และวิธีการใช้งานค่ะ

ตัวอย่าง Locator ของ Selenium library ดังรูป

Element Locator มีหลายประเภท ดังนี้
1. Id
Element ที่มีการกำหนด id ไว้ ซึ่งเราควรจะเลือกใช้ locator นี้ค่ะ มีความเสถียรมากสุด เพราะถึงแม้ว่าจะมีการเปลี่ยนย้ายตำแหน่งของ Element นี้ จะไม่กระทบ Test script ของเราเลยค่ะ
ตัวอย่าง locator ::  id=u_0_n;

2. Name
Element ที่มีการกำหนด name  ไว้
ตัวอย่าง locator ::  name=lastname

3. Css Selector
Css เอาไว้กำหนด style รูปแบบของ element นั้นๆ
ตัวอย่าง locator :: css=input#u_0_s 

4. XPath
XPath คืือ เป็นเส้นทางการเข้าถึงโครงสร้างภายในส่วนต่างๆของ Web
ตัวอย่าง locator :: xpath=//*[@id=”u_0_z”]

*เพื่อ performance ของการทดสอบที่ดี ขอแนะนำว่า เราควรจะใช้ locator ลำดับที่ 1 จนถึง 4 ตามลำดับเลยจ้า

ID –> NAME –> CSS –> XPATH

ตัวอย่าง Test Script ที่ใช้ Element Locator รูปแบบต่างๆ

วิธีการหา Element Locator

หากเราต้องการหา Locator  ในหน้า Web สามารถทำได้ง่ายมากๆ ดังนี้

1. Open website ที่ต้องการจะทดสอบขึ้นมา
2. เอาเมาส์ไปจิ้ม ตรง Element ที่ต้องการ
3. กดปุ่ม F12

เท่านี้เราก็เริ่มเขียน Test script โดยใช้ Locator เพื่อทดสอบ Web site กันได้แล้วค่ะ

สืบเนื่องจากการทำ Automated test แล้วรำคาญการเปิดหน้าต่างการทำงานขึ้นมา เพราะอยากจะรู้แค่ผลลัพธ์ก็เท่านั้น วันนี้เลยมาเสนอ Headless Mode feature เป็นของ Chrome สามารถ run automated test ด้วย Chrome แบบที่ไม่มี web browser แสดงขึ้นมา หรือที่เรียกกันว่า Headless Mode นั่นเองค่ะ ไม่ต้องDownload อะไรใด ๆ เลย เพียงแค่เราติดตั้ง Chrome เท่านั้นก็สามารถใช้งาน feature นี้ได้แร่ะ (Version 60 ขึ้นไป) ขั้นตอนมาดูกันเลย ในตัวอย่างนี้จะเป็นการเขียน Code ทดสอบด้วย Selenium Library จ้า

การตั้งค่า Headless Mode คำสั่งดังนี้

ตัวอย่าง Test script สำหรับรันเทส web แบบ Headless mode ตามด้านล่างเลยค่ะ

หาก Run แล้วจะพบว่าไม่มี Chrome Browser เปิดขึ้นมาให้กวนใจอีกต่อไป แต่เมื่อเข้าไปดูใน Test Report ก็จะพบว่ายังสามารถ Run Automated Test ได้ถูกต้องด้วยค่ะ