ซอฟต์แวร์ซื้อขายอัตโนมัติบน Solana: กรณีทดสอบเพื่อการยอมรับ

การยอมรับซอฟต์แวร์ซื้อขายอัตโนมัติบน Solana ต้องมีขอบเขต

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

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

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

เขียนข้อกำหนดหลักฐานก่อนเริ่มทดสอบ

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

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

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

กรณีทดสอบ: สัญลักษณ์ที่แสดงตรงกันแต่เป็น mint ผิดตัว

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

หลักฐานควรแสดงว่าการตรวจอนุญาตตรวจตัวระบุใด หากซอฟต์แวร์ยอมรับข้อเสนอเพราะสัญลักษณ์ตรงกัน การทดสอบจะเผยความล้มเหลวของขอบเขต หากปฏิเสธด้วยเพียงข้อผิดพลาดทั่วไป พฤติกรรมอาจปลอดภัยแต่คำอธิบายยังต้องปรับปรุง

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

กรณีทดสอบ: หน่วยโทเคนต่างจากจำนวนดิบ

ใช้จำนวนโทเคนที่ควบคุมไว้โดยทราบการตีความตำแหน่งทศนิยมแน่นอน เช่น จำนวนดิบ 1,250,000 เมื่อใช้ทศนิยมหกตำแหน่งหมายถึง 1.25 โทเคน ข้อเสนอ วงเงินอนุญาต และจำนวนที่แสดงควรตีความตรงกัน

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

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

กรณีทดสอบ: หลักฐานที่จำเป็นเก่าเกินไป

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

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

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

กรณีทดสอบ: สองข้อเสนอแย่งใช้งบประมาณก้อนเดียว

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

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

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

กรณีทดสอบซอฟต์แวร์ซื้อขายอัตโนมัติบน Solana ต้องมีผลที่ยังไม่ทราบ

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

พฤติกรรมที่คาดหวังคือมีบันทึกความพยายามที่ยังไม่คลี่คลายอย่างถาวร เชื่อมโยงกับเจตนาเดิม พร้อมจำกัดการกระทำที่พึ่งพากันตามนโยบายตรวจสอบกระทบยอด ซอฟต์แวร์ควรหาหลักฐานเกี่ยวกับความพยายามนั้นก่อนตัดสินใจว่าอนุญาตให้ทำการกระทำทางเศรษฐกิจอีกครั้งหรือไม่

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

กรณีทดสอบ: รับการส่งธุรกรรมแล้วแต่ยังไม่ยืนยัน

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

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

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

กรณีทดสอบ: ลองใหม่หลังการส่งที่ยังไม่ทราบผล

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

ตรวจบันทึกถาวรหาเจตนาและการกันทรัพยากรซ้ำซ้อน ความพยายามส่งผ่านเครือข่ายหลายครั้งอาจเป็นส่วนหนึ่งของนโยบายส่งที่บันทึกไว้ แต่ไม่ควรกลายเป็นการกระทำทางเศรษฐกิจที่ไม่เกี่ยวข้องกัน การทดสอบควรระบุความสัมพันธ์ที่แน่นอนระหว่างความพยายามต่าง ๆ กับคำขอเดิมที่ได้รับอนุญาต

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

กรณีทดสอบ: การขายออกบางส่วนยังเหลือสถานะถือครองจริง

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

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

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

กรณีทดสอบ: ค่าธรรมเนียมเปลี่ยนบัญชีแม้การซื้อขายไม่สำเร็จ

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

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

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

กรณีทดสอบ: ปรากฏคุณสมบัติโทเคนที่ไม่รองรับ

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

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

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

กรณีทดสอบ: ถอนอำนาจระหว่างกระบวนการทำงาน

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

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

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

กรณีทดสอบ: กระบวนการเริ่มใหม่ขณะมีงานค้าง

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

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

ตรวจการกันทรัพยากรหลังเริ่มใหม่ การกันควรตรงกับสถานะที่กู้คืนมา โดยไม่มีการปล่อยหรือกันซ้ำที่อธิบายไม่ได้ การเริ่มใหม่อย่างถูกต้องรักษาความสัมพันธ์ทางเศรษฐกิจระหว่างบันทึกไว้ พร้อมกับตัวบันทึกเอง

กรณีทดสอบ: เวอร์ชันกฎเปลี่ยนระหว่างเหตุการณ์ต่อเนื่อง

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

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

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

กรณีทดสอบ: ข้อมูลส่งออกสร้างลำดับงานที่ไม่สำเร็จขึ้นใหม่ได้

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

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

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

ตัดสินความล้มเหลวจากผลตามมาและสาเหตุ

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

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

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

เก็บกรณีที่ผ่านด้วยการไม่ทำอะไรไว้

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

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

ยอมรับกระบวนการที่กำหนดชัด ไม่ใช่คำสัญญา

รายงานการตรวจรับสุดท้ายควรระบุเวอร์ชันที่ทดสอบ สภาพแวดล้อม รูปแบบอำนาจ ขอบเขตที่รองรับ ผลของแต่ละกรณี และข้อจำกัดที่ยังไม่ได้ทดสอบ ควรแยกหลักฐานที่สังเกตได้ออกจากคำกล่าวอ้างที่มีเพียงเอกสาร และแยกพฤติกรรมจำลองออกจากพฤติกรรมระบบจริง

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

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