Category: Developer

งานพัฒนาระบบ, เขียนโปรแกรม

  • CrystalReport : จัดการกราฟซ่อนแอบ

    จากที่ผู้เขียนช่วงนี้ได้มีการทำกราฟใน Crystal Report ทำไปทำมาผลปรากฎว่า
    กราฟไม่แสดงรูปซะงั้น (ไหงเป็นแบบนี้ได้หว่าาาาาา T T)

    จึงได้ลองค้นหาข้อมูลและพบว่า ต้องเพิ่ม Config เพิ่มเติมเข้าไปใน
    ” Web.config “
    ตาม Code ด้านล่างเลยจ้าาาา

    ส่วนแรก

    “System.web” ส่วน “httpHandlers”
    โดย Version จะต้องเป็น Version Crystal Report ที่เราใช้งานอยู่ อย่าลืมตรวจสอบให้ตรงกันด้วยนะ

    <configuration>
     <system.web> 
       <httpHandlers>       
          <add verb="GET" path="CrystalImageHandler*"/type="CrystalDecisions.Web.CrystalImageHandler, CrystalDecisions.Web, Version=13.0.2000.0, Culture=neutral, PublicKeyToken=692fbea5521e1304"/>     
       </httpHandlers>   
     </system.web>
    </configuration>

    ส่วนที่สอง

    “System.webServer” ส่วน “handlers”
    โดย Version จะต้องเป็น Version Crystal Report ที่เราใช้งานอยู่ อย่าลืมตรวจสอบให้ตรงกันด้วยนะ

    <configuration>
     <system.webServer>
       <validation validateIntegratedModeConfiguration="false"/>
         <handlers>
           <add name="CrystalImageHandler.aspx_GET" verb="GET" path="CrystalImageHandler*" type="CrystalDecisions.Web.CrystalImageHandler, CrystalDecisions.Web, Version=13.0.2000.0, Culture=neutral, PublicKeyToken=692fbea5521e1304" preCondition="integratedMode"/>
         </handlers>
     </system.webServer>
    </configuration>

    หวังว่า Blog นี้จะช่วยเหลือท่านที่ประสบปัญหาเดียวกันอยู่นี้ไม่มากก็น้อยนะคะ

    แล้วพบกันใหม่ Blog หน้าค่าาาาาา 🙂

  • Setup และ Teardown (Robot Freamwork)

    หลังจากที่เราเริ่มเขียน 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 ข้อต่อไป ^_^
  • การเชื่อมต่อ OAuth2 ด้วย WordPress

    อยาก  Login ด้วย OAuth2 กับ WordPress ต้องทำอย่างไร

    สำหรับตัวอย่างนี้จะทำการติดตั้งบน WordPress 5.1 ผ่าน Plugin Simple Single Sign On

    • หลังจากติดตั้ง WordPress เสร็จ เข้าหน้า Administrator แล้วทำการกด Install เพื่อเข้าไปยังหน้าติดตั้ง Extension เพิ่มเติม ทำการเพิ่มปลั๊กอินใหม่ดังรูป

    • ทำการค้นหา single sign on และทำการ Install Now

    • จากนั้นทำการกด Activate

    • จากนั้นทำการตั้งค่าโดยข้าม Step 1 ไปตั้งค่า Step 2 เนื่องจากได้มีการตั้งค่า WP OAuth Server ให้รองรับไว้อยู่แล้ว

    • หลังจากนั้นทำการทดสอบ Login โดยกดปุ่ม Single Sign On

    เพิ่งเท่านี้ก็จะสามารถใช้งานได้ แต่ยังเป็นแบบเลือกได้ว่าจะ Login แบบ Local หรือผ่าน OAuth โดยอาจจะทำเป็นปุ่มในหน้าแรกเพื่อให้กด Login ก็ได้เช่นกัน

  • การเชื่อมต่อ OAuth2 ด้วย Joomla

    อยาก  Login ด้วย OAuth2 กับ Joomla ต้องทำอย่างไร

                 สำหรับตัวอย่างนี้จะทำการติดตั้งบน Joomla 3.9.3 ผ่าน Plugin MiniOrange OAuth Client

    • หลังจากติดตั้ง Joomla เสร็จ เข้าหน้า Administrator แล้วทำการกด Install เพื่อเข้าไปยังหน้าติดตั้ง Extension เพิ่มเติม

    • หลังจากนั้นกด Add Install from Web

    • ค้นหาชื่อ oauth

    • ติดตั้ง miniOrange OAuth Client 

    • หลังจากติดตั้งเสร็จให้ทำการเปิด Plugins เพิ่มเติมดังรูป

    • จากนั้นทำการตั้งค่าโดยสำหรับ miniOrange ต้องสมัครใช้งานก่อน เพราะมีทั้งแบบฟรีและไม่ฟรี แต่เราจะใช้เฉพาะในส่วนของฟรี

    • ในการสมัครต้องใส่ email และตั้งรหัสผ่าน

    • หลังจากติดตั้ง Joomla เสร็จให้ทำการกด Install เพื่อเข้าไปยังหน้าติดตั้ง Extension เพิ่มเติม

    • จากนั้นทำการตั้งค่าเกี่ยวกับ OAuth

    • สามารถกดทดสอบการ Authen ได้ที่ปุ่ม Test Configuration

    • จะปรากฎหน้า Login เพื่อเข้าสู่ระบบ

     

    •  

    • หลังจาก Login เสร็จจะคืนค่า User Profile ดังรูป

              ในการเอาไปใช้งานต่อให้ทำการสร้างปุ่ม ชี้ไปยัง http://localhost/joomla/?morequest=oauthredirect&app_name=other เพื่อเข้าใช้งาน OAuth ลองไปทำต่อดูครับ

  • เรียนรู้เทคโนโลยี OAuth2

    OAuth2 คืออะไร ทำไมต้องใช้

                 OAuth2 คือมาตรฐานหนึ่งของระบบยืนยันตัวตน และจัดการสิทธิ์การเข้าใช้งานระบบต่าง ๆ เป็นมาตรฐาน rfc6747[1] ที่ใช้สำหรับ Client เชื่อมต่อกับ Server ที่ใช้ในการ Authen & Authorize เพื่อให้ได้รับสิ่งที่เรียกว่า Access Token เพื่อใช้แทน Username และ Password (สามารถใช้อย่างอื่นเพื่อขอ Token ก็ได้) เพื่อนำไปใช้กับบริการอื่น ๆ ทำให้มีความปลอดภัยมากขึ้น รวมถึงบอกว่าทำมีสิทธิ์ทำอะไรได้บ้างกับบริการนั้น ๆ (จริง ๆ แล้วถ้า Access Token หลุดก็เอาไปเข้าระบบอื่น ๆ ได้ อาจจะต่างตรงแค่ไม่เห็น Password) โดยแนะนำต้องใช้คู่กับ https อีกชั้นเพื่อความปลอดภัยสูงสุด โดยแสดงภาพคร่าว ๆ เป็น Protocol Flow ดังรูป[2]

                  โดย Access Token จะมีเวลาจำกัดในการใช้งานเมื่อ Token หมดอายุ ก็ต้องไปขอใหม่ เมื่อเลิกใช้งานก็ขอยกเลิก Token รูปแบบการใช้งานมี 4 รูปแบบหรือเรียกว่า grant_type โดยแต่ละแบบมีรายละเอียดดังนี้[3]

    1. Authorization Codeใช้สำหรับ Web Server ที่ใช้ Code ด้านหลังในการเชื่อมต่อกับ OAuth Server โดยไม่ได้เปิดเผยให้สาธารณะเห็น อธิบายเป็นลักษณะการใช้งานคือ
      – ผู้ใช้งานเข้า Web Site
      – จะมีให้กด Login Facebook, Twitter, Google หรืออื่น ๆ 
      – เมื่อผู้ใช้กดก็จะเด้งให้ไป Login ที่ผู้ให้บริการนั้น ๆ ถ้าเคย Login ไว้แล้วก็จะข้ามขั้นตอนนี้ไป
      – ถ้าผู้ให้บริการนั้น ๆ เช่น Facebook จะให้กดยอมรับข้ออนุญาต ส่วนมากจะถามเรื่องสิทธิ์ในการเข้าถึงข้อมูลส่วนตัว
      – เมื่อผู้ใช้กดอนุญาต ก็จะกลับมายัง Web Site โดยในเบื้องหลัง WebSite จะได้ authorization code มาเรียกร้อยแล้วจากผู้ให้บริการ
      – จากนั้นทาง Web Site ก็สามารถเข้าถึงข้อมูลของผู้ให้บริการนั้น ๆ ได้ตามสิทธิที่อนุญาตไว้


      วิธีใช้ authorization code

      1. มีปุ่ม login ซึ่งมี link มี parameter คล้ายๆแบบนี้
        https://[oauth-server]/authorize?response_type=code&client_id=testclient&client_secret=testpass&redirect_uri=http%3A%2F%2F10.1.0.20%3A32778%2F%3Fauth%3Dsso
      2. เมื่อกดปุ่ม login ระบบจะต้องแจ้งว่า จะขอใช้สิทธิเรื่องใดบ้าง

      3. เมื่อผู้ใช้กดตกลงอนุญาต หน้าจอจะถูกพาไปยัง redirect_uri ที่ระบุไว้ พร้อมทั้งส่ง authorization code มาให้ด้วย
      4. ซึ่งจะมีหน้าตาประมาณนี้
         https://yoursite.com/oauth/callback?code=xxx 
      5. อ่าน code ออกมาเพื่อนำไปขอ access_token กับ API ของผู้ให้บริการ login ตัวนั้นๆ
         POST https://api.blah.com/oauth/token?grant_type=authorization_code&code=xxx&redirect_uri=xxx&client_id=xxx&client_secret=xxx 
        

        ค่า client_id, client_secret โดยมาก เจ้าของ login API (Identity provider) จะเป็นคนกำหนดมาให้

        หลังจากส่ง code ด้วย HTTP method POST และบอกว่าเป็น grant_type แบบ authorization_code ไปแล้ว client จะได้ access_token กลับมา เราจะเอา access_token นั้นในการเรียก API อื่น ๆ ต่อไป

    2. Implicit

      ใช้สำหรับ App ฝั่ง Client ซึ่งไม่จำเป็นต้องมี Web Server เป็นเหมือนการคุยระหว่าง Web Browser Client กับ OAuth Server ตรง ๆ เหมาะกับพวกที่ลงท้ายด้วย JS เช่น ReactJS, AngularJS ที่ต้องการดึงข้อมูลด้วย Browser เลย (เหมาะกับ Mobile เป็นพิเศษ) ลักษณะการทำงานคล้าย ๆ กับข้อ 1 แต่จะต่างกันตรงไม่ต้องส่ง Client_Secret เป็นวิธีที่เปิดเผยให้สาธารณะเห็น

      วิธีใช้ Implicit

      1. สร้างปุ่ม login ที่ส่ง action ไปยัง URL แบบนี้
         https://login.blah.com/oauth?response_type=token&client_id=xxx&redirect_uri=xxx&scope=email 
      2. เมื่อผู้ใช้กดปุ่ม จะแสดงหน้าต่างขอใช้สิทธิ หากตกลงข้อมูลจะ submit ไป server แล้วข้อมูล token จะถูกส่งกลับมาตาม redirect_uri ที่กำหนดเอา
      3. client_id ในข้อ 1 id provider เป็นคนกำหนดมาให้
      4. token ที่ได้มา เอาไปใช้ได้ดึงข้อมูลตามสิทธิ์ที่ได้มาได้เลย
    3. Password Credentials

      ใช้สำหรับ Application ที่มีการจัดการสิทธิเอง แต่ต้องการยืนยันตัวตนเท่านั้น ซึ่งวิธีนี้ไม่ต้อง Redirect ไปที่ผู้ให้บริการอื่น วิธีนี้เหมาะกับการใช้งานที่เป็นบริการของตัวเอง เพราะ username password จะปรากฎในเครื่องที่ส่งขอ token ถ้าไปรันวิธีนี้บน Server อื่นที่ไม่ได้เป็นเจ้าของ แสดงว่า เขาอาจจะดักเอา username password ไปใช้ก็ได้


      การใช้ Password Credentials

      1. มี form รับ username/password เมื่อกด submit แล้ว ส่ง form submit (POST method) ไปยัง server/service ของเรา
         POST https://login.blah.com/oauth/token?grant_type=password&username=xxx&password=xxx&client_id=xxx 
      2. จะได้ access_token มาใช้งานได้เลยหากใส่ข้อมูลถูกต้อง
    4. Client Credentials

      ในกรณีที่เป็นการคุยระหว่าง Application -> Service โดยจะไม่เกี่ยวข้องกับผู้ใช้ ยกตัวอย่างว่าเราอาจจะได้ข้อมูลสักอย่างแต่ต้องการความปลอดภัยว่าต้องเป็นเครื่องที่เราให้สิทธิ์ ก็สามารถส่ง id และ secret ที่ออกให้ Application ส่งมาขอ token เพื่อเข้าถึง Service นั้น ๆ ได้เลย

    OAuth2 ปลอดภัยหรือไม่

          อยู่ที่การใช้งาน ว่าปลอดภัยหรือไม่ ถ้ารันบน http ธรรมดา ยังไงก็ไม่ปลอดภัย ถ้าใช้ php 4/5 หรือ windows 2003/2008/2008/2008 R2 ยังไงก็ไม่ปลอดภัย 

    แล้วทำไมต้องใช้ OAuth2

    – เนื่องจากเป็นมาตรฐานที่พัฒนาจาก OAuth1.0a ที่มีการใช้งานมาก ทำให้ Version 2 ซึ่งลดความซับซ้อนลง การใช้งานจึงเข้าใจง่ายขึ้น

    – เร็วกว่า xml web service ใช้ json ในการสื่อสาร เพราะขนาดข้อมูลที่ส่งจะเล็กกว่ามาก

    – มีผู้ให้บริการภายนอกหลากหลาย

    – เหมาะกับใช้งานที่หลากหลาย เพราะรองรับหลากหลายภาษา (Java, Python, Go, .NET. Ruby, PHP, .NET, ฯลฯ)

    – สามารถประยุกต์นำมาใช้งานเป็น Single Sign On ได้ (ต้องพัฒนาเพิ่มเอง ไม่มีมาให้ในมาตรฐาน)

    =================================================

    References :
    [1] The OAuth 2.0 Authorization Framework : https://tools.ietf.org/html/rfc6749

    [2] An Introduction to OAuth2 : https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2

    [3] OAuth 2.0 clients in Java programming, Part 1, The resource owner password credentials grant : https://www.ibm.com/developerworks/library/se-oauthjavapt1/index.html

  • Refresh ข้อมูลในกรณีที่ฐานข้อมูลมีการอัพเดทใน LINQ และ Entity Framework (Refresh Query in LINQ)

    จากปัญหาที่เคยเจอในกรณีที่ฐานข้อมูลมีการอัพเดทไปแล้ว พอ Select ข้อมูลออกมาข้อมูลไม่ refresh ในกรณีนี้จะยกตัวอย่างการใช้งานฟังก์ชัน reload ของ System.Data.Entity.Infrastructure

    public class DbEntityEntry where TEntity : class

    // Summary:
    // Reloads the entity from the database overwriting any property values with values
    // from the database. The entity will be in the Unchanged state after calling this
    // method.
    public void Reload();

    โดยการใช้งานนั้นจะยกตัวอย่างตามโค้ดด้านล่าง

    ProjectEntities pe = new ProjectEntities();

    var project = pe.PROJECT.Where(w => w.ID == projectID && w.YEAR == year).FirstOrDefault();

    if (project != null)

    {
    pe.Entry(project).Reload();

    }

    หวังว่าคงจะได้ช่วยโปรแกรมเมอร์ทีมีปัญหาเรื่องการ refresh ข้อมูลผ่าน LINQ และ Entity Framework

  • การสร้างเงื่อนไขแบบหลายตัวแปรในการค้นหาข้อมูลผ่าน LINQ (Multiple Search In LINQ)

    การสร้างเงื่อนไขแบบหลายตัวแปรในการค้นหาข้อมูลผ่าน Linq เพื่อให้เห็นภาพชัดเจน จะยกตัวอย่างโดย กำหนดเงื่อนไข 3 ตัวแปร ดังนี้

    • ตัวแปร “ชื่อ/นามสกุล/เลขประจำตัวประชาชน”
      โดยใช้ control TextBox ที่ชื่อ ID=”txtSearch”
    • ตัวแปร “โครงการรับ” โดยใช้ control DropDownList ที่ชื่อ ID=”ddProject”
    • ตัวแปร “สถานะการตรวจเอกสาร”
      โดยใช้ control DropDownList ที่ชื่อ ID=”ddStatus”

    จากนั้นเราสร้าง Entity ยกตัวอย่างเป็น UploadEntities ซึ่งในที่นี้ สร้าง DbSet ที่เชื่อมต่อฝั่งฐานข้อมูลยกตัวอย่างเป็น V_REGISTRATION_UPLOAD ผ่าน Entity Framework 4.5 จากนั้นใช้ LINQ ในการเขียนเงื่อนไข ยกตัวอย่างตามโค้ดด้านล่าง

    project = ddProject.SelectedValue;

    status = ddStatus.SelectedValue;

    search = txtSearch.Text.Trim();

    outList = ue.V_REGISTRATION_UPLOAD

    .Where(w => (w.STUD_FNAME.Contains(search) || w.STUD_LNAME.Contains(search) || w.CITIZEN_ID.Contains(search)) || string.IsNullOrEmpty(search))

    .Where(x => x.PROJECT_ID == project || string.IsNullOrEmpty(project))

    .Where(y => y.APPROVED_STATUS == status || string.IsNullOrEmpty(status)) .ToList();

    gvUploadedList.DataSource = outList;

    gvUploadedList.DataBind();

    แสดงการใช้งานฟังก์ชัน Where ของ LINQ ในส่วนของ code behide
    ผลลัพธ์ที่ได้จากการเรียกใช้เงื่อนไขฟังก์ชัน Where ของ LINQ

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

  • การทดสอบซอฟต์แวร์ (Software Testing) – #1 กิจกรรม และขั้นตอนการทดสอบซอฟต์แวร์

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

    ก็ว่ากันตามหัวข้อของบทความ เรื่องราวเหมือนจะไม่เครียดแต่จริง ๆ ก็วิชาก๊านน วิชาการอยู่นะคะ ฮาา 😉
    ผู้เขียนจำได้ว่าสมัยเรียนป. ตรี (ก็ผ่านมายังไม่กี่ปีหรอกค่ะ ฮรี่ ๆ) 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) สำหรับเจ้าหน้าที่บริการลูกค้าระบบสารสนเทศบุคลากร” เพื่อให้ผู้อ่านอ่านได้ง่ายขึ้น คู่มือดังกล่าวนั้น ผู้เขียนได้จัดทำขึ้นมาโดยรวบรวมข้อมูลจากประสบการณ์การทดสอบซอฟต์แวร์ของผู้เขียนเอง ร่วมกับการศึกษาข้อมูลเพิ่มเติมจากแหล่งความรู้และ/หรือผู้มีความรู้ท่านอื่น ๆ สำหรับอ้างอิงแหล่งข้อมูลต่าง ๆ นั้น ผู้อ่านสามารถดูได้จากคู่มือดังกล่าวนะคะ

  • มารู้จัก Web Element Locator กัน

    ทำไม 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 กันได้แล้วค่ะ