วิธีทดสอบแอพพลิเคชั่นที่มีขนาดใหญ่มาก


10

ฉันมีแอพ PHP ที่มีขนาดใหญ่มาก โดยปกติจะมีนักพัฒนา 2-3 คนทำงานเต็มเวลาและเราไปถึงจุดที่เราทำการเปลี่ยนแปลงและสร้างข้อบกพร่อง (ฟีเจอร์ไอ!) ซอฟต์แวร์ไม่ซับซ้อนต่อการพูดเพียงมีจำนวนมากเกิดขึ้น (35 ~ ตัวควบคุมเกี่ยวกับรุ่นเดียวกัน ฯลฯ )

แม้จะระมัดระวังก็เป็นเรื่องง่ายสำหรับการเปลี่ยนแปลงในมุมมองนี้ (การปรับแต่ง id บนองค์ประกอบ) เพื่อทำลายการค้นหา ajax ที่เกิดขึ้นภายใต้เงื่อนไขพิเศษบางอย่าง

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

บางทีเราต้องใช้เวลาส่วนหนึ่ง Q / A คน?

ทุกคนมีคำแนะนำ / ความคิดใด ๆ


"... จากนั้นทดสอบการทำ" ถูกที่ควรจะเป็นมากกว่า ?
ajax333221

คำตอบ:


25

ใช่คุณต้องมีเจ้าหน้าที่ Q / A เหตุผลหลายประการรวมถึง

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

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


3
+1 เราได้รับการฝึกอบรมอย่างสูงเกินไปในการตรวจสอบปัญหาที่ผู้ใช้ทั่วไปมี
superM

3

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

หลังจากนั้นให้ถามตัวเองว่าคุณสามารถทำการทดสอบบางส่วนหรือเกือบทั้งหมดโดยอัตโนมัติด้วยความพยายามอย่างสมเหตุสมผล หากคำตอบคือใช่คุณควรตั้งโปรแกรม หากคำตอบคือ "ไม่" และคุณคิดว่า "เวลาส่วนบุคคล Q / A" ราคาถูกกว่าก็ควร obviuos สิ่งที่คุณต้องการ ในกรณีส่วนใหญ่มันเป็นความคิดที่ดีที่จะมีทั้งคู่ - คน Q / A สำหรับการทดสอบด้วยตนเองและประดิษฐ์การทดสอบใหม่และการทดสอบการถดถอยอัตโนมัติจำนวนมากเช่นกัน


+1 สำหรับการกล่าวถึงการทดสอบการถดถอยและชี้ให้เห็นว่าการทดสอบหน่วยไม่ใช่วิธีแก้ปัญหาที่มีประสิทธิภาพเท่านั้น
จอร์โจ

สวัสดีคุณช่วยอธิบายเพิ่มเติมเกี่ยวกับการทดสอบการถดถอยได้ไหม ฉันเชื่อว่าสิ่งเหล่านี้คือการป้องกันข้อผิดพลาดเก่า ๆ ที่เกิดขึ้นอีกครั้ง แต่ด้วยวิธีการที่คุณเสนอเพื่อดูสิ่งนี้ทำ? การทดสอบหน่วย? 'รายการตรวจสอบ' ของสิ่งที่ต้องตรวจสอบหรือไม่ ขอบคุณ :)
Wizzard

@Wizzard: การทดสอบการถดถอยคำศัพท์เป็นเพียงคำทั่วไปสำหรับการทดสอบทุกประเภทสำหรับฟังก์ชันการทำงานที่มีอยู่แล้ว (เพื่อป้องกันไม่ให้คุณแตกหักเมื่อเปลี่ยนแอปของคุณ) ซึ่งครอบคลุมการทดสอบจากรายการตรวจสอบการทดสอบอัตโนมัติผ่านส่วนหน้าของคุณ (นี่อาจเป็นเบราว์เซอร์ของคุณ) และการทดสอบหน่วยเช่นกัน คำแนะนำของฉันคือการที่คุณควรคิดเกี่ยวกับสิ่งที่จะทดสอบอิสระว่าคุณกำลังจะไปทดสอบ (ถ้าคุณพูดว่า "เราพยายามทดสอบหน่วย" ยกตัวอย่างเช่นคุณมีอยู่แล้วที่ "วิธีการ" ไม่ได้อยู่ที่ "อะไร") .
Doc Brown

2

จ้างมืออาชีพ QA

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

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


1

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

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


1

15 คอนโทรลเลอร์และรุ่นไม่ใหญ่มาก ต้องใช้เวลาสักพักในการทดสอบการเขียนนิสัยการเตะเข้าหากัน (ในลักษณะที่เป็นมิตรก่อน) จะช่วยได้มาก

มีเครื่องมือที่สามารถควบคุมความครอบคลุมการทดสอบเพื่อขยายบางอย่าง เครื่องมือครอบคลุมรหัสสำหรับ PHP


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