การพัฒนาหน่วยทดสอบหรือการทดสอบคืออะไร?


24

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

  1. การทดสอบหน่วยและการรวมมีการวางแผนและดำเนินการกับอินเทอร์เฟซและสัญญาเสมอ ไม่ว่าคุณจะใช้สัญญาแบบเป็นทางการหรือไม่ก็ตามคุณยังคงทดสอบว่าวิธีการใดที่ควรทำเช่นสัญญา

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

  2. ฉันไม่เห็นคุณค่าใด ๆ ในการสื่อสารความกว้างและความลึกของหน่วยและการทดสอบการรวมเข้ากับเครื่องทดสอบ (ระบบ) สมมติว่าฉันเขียนรายงานที่แสดงประเภทของการทดสอบหน่วยในชั้นธุรกิจที่เฉพาะเจาะจง เขา / เธอควรจะเอาอะไรไปจากสิ่งนั้น?

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

นี่อาจดูเหมือนการพูดคุยเชิงวิชาการที่ไร้ประโยชน์ แต่ถ้าคุณทำงานในสภาพแวดล้อมที่เป็นทางการอย่างที่ฉันทำมันสำคัญมากที่จะต้องพิจารณาว่าเราทำอะไร อย่างไรก็ตามฉันผิดทั้งหมดหรือเปล่า


9
มันสำคัญไหม
yannis

5
@YannisRizos จากชื่อไม่ จากคำถามทั้งหมดดูเหมือนคนจะถามไปๆมาๆ
Ludwig Magnusson

2
@Rubio จากคำถามของคุณฉันยอมรับว่ารายงานเกี่ยวกับการทดสอบหน่วยไม่มีประโยชน์สำหรับผู้ทดสอบระบบ การทดสอบหน่วยเป็นเครื่องมือที่มีประโยชน์สำหรับนักพัฒนา ผู้จัดการทดสอบของคุณกระตุ้นความต้องการรายงานเหล่านี้อย่างไร
Ludwig Magnusson

2
@LudwigMagnusson True แต่ถ้ามันมีความสำคัญกับบุคคลที่ถามนั่นเป็นภาษาท้องถิ่นเกินไป
yannis

5
นักพัฒนาที่รายงานถึงผู้จัดการทดสอบนั้นผิดไม่ว่าอะไรก็ตาม ถ้าเธอผ่านคำขอนั้นผ่านผู้จัดการของคุณคุณต้องทำตามที่หัวหน้าของคุณบอก "คุยกับผู้จัดการของฉัน"เป็นอาวุธที่จำเป็นต้องรู้วิธีการใช้ใน "สภาพแวดล้อมที่เป็นทางการอย่างเคร่งครัด" เป็นของคุณ
ริ้น

คำตอบ:


30

การเขียนแบบทดสอบอัตโนมัติเป็นงานของนักพัฒนา การทดสอบเป็นส่วนหนึ่งของ codebase และควรได้รับการปฏิบัติเช่นนี้ - การทดสอบเหล่านี้ควรได้รับการตรวจสอบจากรหัสเดียวกันมาตรฐานการเข้ารหัสระเบียบวินัยการควบคุมแหล่งที่มาเป็นต้นซึ่งเป็นส่วนที่เหลือของโครงการ

การรันการทดสอบนั้นทำขึ้นด้วยเหตุผลสองประการ: ประการแรกเป็นเครื่องมือในการชี้นำนักพัฒนา คุณเรียกใช้การทดสอบเพื่อตรวจสอบว่ารหัสที่คุณเพิ่งเขียนทำสิ่งที่ควรจะเป็นคุณใช้พวกเขาเป็นเอกสารเพิ่มเติมและเพื่อตรวจสอบว่าการเปลี่ยนแปลงไม่ทำลายหน้าที่การทำงานที่มีอยู่ใด ๆ หากคุณทำ TDD จริงการทดสอบก็เป็นแหล่งข้อมูลทางเทคนิคที่เชื่อถือได้ เหตุผลที่สองที่ใช้ในการทดสอบคือระหว่างการควบคุมคุณภาพและการปรับใช้ การรันการทดสอบอัตโนมัติทั้งหมดควรเป็นหนึ่งในขั้นตอนแรกในการทดสอบทุกรอบ การรันการทดสอบอัตโนมัตินั้นมีราคาถูก (แทบไม่จำเป็นต้องใช้กำลังคนเลย) และมันก็ไม่สมเหตุสมผลเลยที่จะทำการทดสอบด้วยตนเองหากการทดสอบอัตโนมัติล้มเหลว

นี่หมายความว่าความรับผิดชอบควรเป็นดังนี้:

  • นักพัฒนาเขียนการทดสอบอัตโนมัติ
  • นักพัฒนาใช้การทดสอบอัตโนมัติตามความต้องการซึ่งเป็นส่วนหนึ่งของขั้นตอนการพัฒนา
  • QA ดำเนินการทดสอบอัตโนมัติทั้งหมดเป็นหนึ่งในขั้นตอนแรกของการทดสอบ

หากคุณมีบิลด์เซิร์ฟเวอร์งานของ QA (เกี่ยวกับการทดสอบอัตโนมัติ) จะทำให้คุณ "เปิดรายงานของบิลด์เซิร์ฟเวอร์และตรวจสอบว่าทุกอย่างเป็นสีเขียว"


โพสต์ที่ยอดเยี่ยมตรงตามเส้นที่ฉันจะโพสต์ มีเพียง qualm เท่านั้นที่ต้องพึ่งพาการทดสอบหน่วยเป็นอย่างมากและการทดสอบการรวมเข้าด้วยกันสามารถนำไปสู่ปัญหาที่เกิดขึ้นได้ ฉันไม่เห็นด้วยกับความจริงที่ว่างานของ QA ลดลงเพื่อตรวจสอบการสร้างเซิร์ฟเวอร์ (ฉันสมมติว่าคุณหมายถึงบางสิ่งบางอย่างเช่นฮัดสัน) นี่เป็นการเพิ่มภาระการทดสอบทั้งหมดให้กับนักพัฒนาเพื่อเขียนการทดสอบที่ครอบคลุมตรรกะทางธุรกิจทั้งหมดตลอดเวลาซึ่งดูเหมือนว่าจะทำให้นักพัฒนามีน้ำหนักมากเกินไป
dardo

4
@dardo: แน่นอนว่าการทดสอบอัตโนมัติไม่ใช่การทดสอบเดียวที่คุณควรรันมิฉะนั้นคุณสามารถกำจัด QA ได้ทั้งหมด นั่นจะไร้สาระ - แง่มุมที่สำคัญมากของผลิตภัณฑ์ซอฟต์แวร์ใด ๆ ก็ไม่สามารถทดสอบได้โดยอัตโนมัติ สิ่งที่ฉันหมายถึงคือเมื่อได้รับการทดสอบอัตโนมัติ QA ไม่ควรกังวลเกี่ยวกับการทดสอบเหล่านั้นนอกเหนือจากการตรวจสอบผลลัพธ์ของการสร้างเซิร์ฟเวอร์ หลังจากนั้นพวกเขาทำสิ่งปกติของพวกเขา - การทดสอบด้วยตนเองและกึ่งอัตโนมัติในการสร้างเสร็จ
tdammers

อ่าใช่เห็นด้วย 100% เรียงเหมือนด่านที่พวกเขามีให้ทำพวกเขาผ่าน ฯลฯ
Dardo

@tdammers - การทดสอบเป็นเพียงส่วนเล็ก ๆ ของการประกันคุณภาพ
Matthew Flynn

2
คำตอบที่ยอดเยี่ยม an authoritative source of technical specificationsแต่ผมไม่เห็นว่าการทดสอบควรจะเห็นเป็น การทดสอบควรเป็นการยืนยันรายละเอียดเฉพาะ แต่ไม่ใช่การแทนที่แน่นอน ไม่ได้บอกว่าฉันกำลังสนับสนุนสเป็กหน้าใหญ่ ๆ อย่างใดอย่างหนึ่ง แต่ค่อนข้างว่าฉันกำลังสร้างความแตกต่างที่เราใช้การทดสอบเพื่อตรวจสอบสิ่งที่เรารู้เกี่ยวกับวิธีที่ระบบควรทำงานมากกว่าที่จะมี การทดสอบกำหนดพฤติกรรม อาจจะมีความแตกต่างทางความคิด แต่ก็สำคัญ
S.Robins

10

ฉันคิดว่าสิ่งที่สำคัญที่สุดสำหรับคุณคือการชี้แจงว่าทำไมเธอถึงต้องการรายงานนั้น

อาจมีคำอธิบายที่แตกต่างกัน (ตามคำแนะนำจากหลายคำตอบ) ซึ่งต้องใช้กลยุทธ์ที่แตกต่างกันมาก

  • ถ้าเธอเป็นคนที่สมเหตุสมผลเพียงแค่ต้องการรับข้อมูลเพื่อช่วยงานของทีมทดสอบของเธอมันก็สมเหตุสมผลที่จะได้รับความเข้าใจร่วมกันและหาแนวทางแก้ไขปัญหาที่เหมาะสมกับคุณทั้งคู่ คุณสามารถพูดคุยกับเธอถึงลักษณะของการทดสอบหน่วยและความแตกต่างพื้นฐานระหว่างการทดสอบหน่วยการใช้งาน / ระบบ / การยอมรับ หวังว่าคุณจะทำให้เธอเข้าใจว่างานเหล่านี้ในระดับที่แตกต่างกันมากและไม่สามารถแทนที่งานอื่นได้
  • หากเธอเป็นคนที่คลั่งไคล้การควบคุมหรือต้องการเรียกร้องรายงานเพียงเพื่อประโยชน์ของมันคุณสามารถสร้างบางสิ่งบางอย่างเพื่อสนองความต้องการของเธอด้วยความพยายามน้อยที่สุด (เช่นสิ่งที่ @Doc แนะนำ :-)
  • หากเธอเข้าสู่เกมพลังคุณอาจถามว่าเธอมีสิทธิ์เรียกร้องรายงานจากนักพัฒนาหรือไม่ จากประสบการณ์ของฉันผู้พัฒนามักไม่ควรรายงานไปยังแผนกควบคุมคุณภาพ

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

2
@Rubio แน่นอนคุณควรชี้แจงกับเธอว่าการทดสอบหน่วยไม่สามารถแทนที่การทดสอบระบบได้ ในความเป็นจริงการครอบคลุมการทดสอบหน่วยสูงของโมดูลเฉพาะอาจเป็นสัญญาณเตือนว่าโมดูลนั้นต้องการความสนใจเป็นพิเศษในระหว่างการทดสอบระบบ! หากนักพัฒนาใช้ความเจ็บปวดเป็นพิเศษในการเขียนว่าการทดสอบจำนวนมากรหัสอาจมีการเปลี่ยนแปลงอย่างมาก / เมื่อเร็ว ๆ นี้และ / หรือเต็มไปด้วยข้อบกพร่อง
PéterTörök

7

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

ด้วยเหตุนี้ทีมงาน QA ของเราจึงไม่สนใจสิ่งที่เป็นและไม่ได้ผ่านการทดสอบก่อนที่จะเริ่มการทดสอบ

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


5

เธอยืนยันว่า devs รายงานสิ่งที่พวกเขามีหน่วยและบูรณาการการทดสอบและวิธีการ

เธอพยายามที่จะแย้งว่าการทดสอบแบบนี้เป็นจริงในขอบเขตของ "การพัฒนา" หรือไม่หรือเธอแค่พยายามคิดให้ดีว่ารหัสของคุณครอบคลุมโดยการทดสอบหน่วย เพียงแค่ดูข้อมูลที่คุณให้มาดูเหมือนว่าเธอแค่อยากรู้ว่าส่วนใดของรหัสที่ได้รับการคุ้มครองและที่ที่เธอควรจะเน้นความพยายามของทีมของเธอ

ฉันทำงานกับทีมทดสอบก่อนออกจากโรงเรียนก่อนที่จะเข้าสู่บทบาทการพัฒนาและฉันเห็นได้ว่าสิ่งนี้มีประโยชน์กับเธอและทีมของเธออย่างไร


1
แต่โฟกัสไม่ควรมาจากสเป็ค? มีสถานการณ์ที่การเปลี่ยนแปลงรหัสมีผลสะท้อนที่ไม่คาดคิดจากนั้นเป็นสิ่งสำคัญมากสำหรับผู้พัฒนาที่จะสื่อสารว่าการทดสอบควรครอบคลุมสิ่งนี้และสิ่งนี้ด้วย
Rubio

1
@Rubio: แน่นอน แต่จากมุมมองที่ใช้งานได้จริงลองดูจากมุมมองของเธอ สมมติว่าทุกส่วนของแอปพลิเคชันจะไม่ได้รับโค้ดที่ครอบคลุมโดยการทดสอบหน่วยเท่ากันอย่างสมบูรณ์แบบคุณไม่ต้องการที่จะอุทิศทรัพยากรที่มีอยู่อย่าง จำกัด ให้มากขึ้นไปยังส่วนต่าง ๆ ของแอปพลิเคชั่น สำหรับฉันมันเป็นเพียงเรื่องของการดูรายงานและบอกกับทีมของฉันว่า "เฮ้พวกดูเหมือนว่า Area X มีรหัสที่ครอบคลุมการทดสอบน้อยกว่า Area Y เราลองมุ่งเน้นไปที่การรันการทดสอบใน Area X"
Jason

@Rubio: ใช่ แต่ถ้าคุณทำ TDD (เช่น BDD) อย่างถูกต้องการทดสอบของคุณควรจะขัดกับรายละเอียดในตอนแรก หาก บริษัท ของคุณรู้แจ้งอย่างแท้จริงทีมทดสอบสามารถเขียนการทดสอบสำหรับทีมพัฒนาได้
gbjbaanb

2
สิ่งที่ถูกทดสอบ:รายงานความครอบคลุมโค้ดที่สร้างขึ้นโดยอัตโนมัติ มีการทดสอบอย่างไร:อ่านรหัสการทดสอบหน่วย @gbjbaanb: "ทีมทดสอบสามารถเขียนการทดสอบสำหรับทีม dev ได้" มีหลายสิ่งที่ไม่ถูกต้องด้วยกับคำสั่งที่ว่าผมไม่ทราบว่าจะเริ่มต้นยกเว้นที่จะบอกว่าคิดที่ดีมาก
BryanH

5

ฉันไม่เห็นว่ามันมีความสำคัญมากเกินไป

หากคุณไม่ได้ให้พวกเขาไปยัง QA / การทดสอบและพวกเขาไม่ได้ทำการทดสอบที่เหมาะสมและล้มเหลวในการผลิตมันเป็นความผิดของพวกเขาสำหรับการให้มันผ่าน QA ในการผลิตโดยไม่ตรวจสอบว่ามันทำงานตามที่ระบุ

หากคุณให้พวกเขาเพื่อ QA / การทดสอบและพวกเขาไม่ได้ทำการทดสอบที่เหมาะสม ... ผลเช่นเดียวกับถ้าคุณไม่ได้ให้พวกเขา

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

จริง ๆ ฉันไม่เห็นข้อเสียในการให้พวกเขา มันยังอยู่ใน QA / การทดสอบเพื่อตรวจสอบกับสเป็ค หากพวกเขาใช้วิธีขี้เกียจและเพียงแค่เชื่อว่าการทดสอบของคุณนั้นดีพอเพราะพวกเขาผ่านไปแล้วนั่นคือสิ่งที่พวกเขาทำไม่สำเร็จ ตราบใดที่พวกเขายังมีสเป็คเช่นกันผลของการทดสอบหน่วย / การรวมเข้าด้วยกันเป็นเพียงแค่ขุยและไม่ควรทำร้ายคุณไม่ทางใดก็ทางหนึ่ง นี่คือเหตุผลที่เรามี dev และ QA ตรวจสอบหลายครั้งว่าแอปทำงานตามที่ระบุ

Devs ทำผิดพลาด QA ทำผิดพลาดโดยที่ทั้งคู่ไม่ได้ทำผิดในรายการเดียวกัน ... และถ้าทำ ... อาจเป็นนักวิเคราะห์ที่ทิ้งลูกบอลเขียนสเป็คที่ไม่ชัดเจน


2
ข้อเสียสำหรับฉันคืองานพิเศษที่ให้คุณค่าไม่มากหรือน้อย
Rubio

@Rubio ทำงานพิเศษอะไร? เพียงพิมพ์ผลลัพธ์ หากชื่อพวกเขาดีมันจะบอกพวกเขาว่าคุณกำลังทดสอบ ไม่ควรต้องการรหัสจริงหรือคำอธิบายวิธีการทำงาน หากพวกเขาทำพวกเขาสามารถค้นหาตัวเอง
CaffGeek

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

1
@Rubio - ระบบอัตโนมัติเป็นเพื่อนของคุณ คุณสามารถตั้งค่าเซิร์ฟเวอร์การรวมอย่างต่อเนื่องที่เมลรายงานเมื่อใดก็ได้ที่มีการเช็คอิน (สิ่งนี้จะช่วยคุณได้เช่นกัน) หาก QA กำลังขอคำอธิบายเกี่ยวกับการทดสอบและรหัสดูเหมือนว่าพวกเขาผ่านพ้นระดับความมีเหตุผลและอยู่ในขอบเขตของ "ความล้มเหลวในการเข้าใจแนวคิด" หากพวกเขาไม่สามารถหรือจะไม่อ่านรหัสก็จะไร้ประโยชน์ เมื่อถึงจุดนั้นการแชทกับผู้จัดการของคุณจะเป็นประโยชน์และคุณสามารถจัดวางได้เช่น "QA ต้องการให้ฉันใช้เวลา x% ของเวลาที่ฉันช่วยให้พวกเขาอ่านรหัสใช่ไหม?
BryanH

1
+1 สำหรับการบอกว่ามันไม่ได้ทำให้ QA รับผิดชอบในการทดสอบซอฟต์แวร์อย่างอิสระ

2

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

ค่าอื่น ๆ ในการผ่านการทดสอบคือสามารถหลีกเลี่ยงการทดสอบซ้ำที่อาจซ้ำซ้อนในแง่ของการรับรองการทำงานขั้นพื้นฐาน

นอกจากนี้ยังมีการทดสอบการยอมรับของผู้ใช้ที่แยกจากทั้งหมดนี้เนื่องจากผู้ใช้อาจมีความเข้าใจของตัวเองว่าระบบทำงานอย่างไร


1
การทดสอบซ้ำซ้อนคือสิ่งที่มักใช้เป็นอาร์กิวเมนต์และบางครั้งอาจเป็นจริง อย่างไรก็ตามการทดสอบระบบจะดำเนินการตลอดทั้งระบบในขณะที่การทดสอบหน่วย / การรวมเข้าด้วยกันนั้นจะเน้นที่หน่วยเฉพาะ ฉันเห็นอันตรายที่นี่
Rubio

2

หาก บริษัท ของคุณมีวิธีการที่กำหนดไว้เพื่อให้มั่นใจในคุณภาพของผลิตภัณฑ์ (ถ้าเป็นไปตาม SOX หรือพยายามปรับปรุงระดับ CMMI ของพวกเขาพวกเขาอาจทำ) แล้วผลิตภัณฑ์จะต้องยืนขึ้นเพื่อตรวจสอบเพื่อแสดงว่ากระบวนการ ถูกติดตาม

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

ดูเครื่องมือเช่น Sonar เพื่อช่วยคุณ - มันจะรายงานระดับการครอบคลุมโค้ดและผลลัพธ์ของการทดสอบหน่วยของคุณ


SOX no, CMMI ใช่ การทดสอบหน่วย / การรวมเข้าด้วยกันของเราเป็นส่วนหนึ่งของกระบวนการตรวจสอบโค้ดและที่โดดเด่นในการตรวจสอบ ฉันสามารถรับรายงานที่สร้างจากการทดสอบหน่วย / การรวมเข้าด้วยกัน แต่นั่นเป็นความลับสำหรับผู้ทดสอบ รายงานข่าวยังอยู่ในรายงาน แต่ก็ไม่มีความหมายในตัวเอง
Rubio

ก่อนอื่นอย่าให้ชื่อที่เป็นความลับในการทดสอบของคุณ ตรวจสอบdannorth.net/introducing-bdd ประการที่สองความครอบคลุมของรหัสอาจไม่ได้กล่าวถึงคุณภาพของการทดสอบมากนัก แต่อย่างน้อยก็แสดงให้เห็นว่าหน่วยที่กำลังทดสอบไม่ได้ระเบิดขึ้นเมื่อเรียกใช้รหัสเกือบทั้งหมด
Matthew Flynn

ลิงค์ดีขอบคุณ ฉันจำได้ว่าอ่านบทความในนิตยสารที่ยอดเยี่ยมสำรวจวิธีต่าง ๆ ในการตั้งชื่อการทดสอบหน่วย แต่ไม่สามารถหาฉันตายได้ในตอนนี้ อาจเคยเป็นนิตยสาร Visual Studio หรือนิตยสารรหัส
Rubio

2

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

คุณภาพเป็นความรับผิดชอบของทีม - ทั้งนักพัฒนาผู้ทดสอบและการจัดการผลิตภัณฑ์และการทำงานร่วมกันเป็นวิธีที่ดีที่สุดเพื่อให้มั่นใจว่า

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


1

ฉันคิดว่ามันจะเป็นประโยชน์ในการให้สิ่งประเภทนี้ การครอบคลุมการทดสอบหน่วยควรเป็นสิ่งที่รู้จักกันดีจากการพัฒนาและการทดสอบเพื่อให้สามารถอธิบายได้

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


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

1

เป็นมูลค่าการกล่าวถึงวิธีการที่กล่าวถึงในหนังสือ "วิธีการทดสอบซอฟต์แวร์ Google": การทดสอบและการควบคุมคุณภาพเป็นความรับผิดชอบของทุกคนและมาตรฐานที่เข้มงวด

จริงบทบาทของสิ่งที่เป็นประเพณีที่เรียกว่า "การทดสอบ" แผนกเป็นจริงผลิตพัฒนา; คือระบบอัตโนมัติเพื่อให้องค์กรสามารถเข้าถึงระดับที่ต้องการได้อย่างประหยัด

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.