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

ตัวอย่างเช่น: ขณะทำการทดสอบการทำงานของแบบฟอร์มในเว็บแอปพลิเคชันเราจะทดสอบฟิลด์โดยป้อนค่าการป้อนข้อมูลแบบสุ่มชนิดต่าง ๆ

โดยทั่วไปเราในฐานะผู้ใช้แอปพลิเคชันเว็บไม่ได้ป้อนค่าสุ่มลงในฟิลด์

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

หมายเหตุ: ตัวอย่างข้างต้นเป็นเพียงตัวอย่างกรณี ปัญหาดังกล่าวอาจเกิดขึ้นในคุณสมบัติ / โมดูลใด ๆ

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

คุณอาจไม่ป้อนค่าสุ่มลงในฟิลด์ของเว็บแอปพลิเคชัน แต่แน่นอนว่ามีคนที่ทำเช่นนั้น

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

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

ไม่เคยคิดอะไร

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

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

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

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

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

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

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

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

ในฐานะนักพัฒนาซอฟต์แวร์คุณอาจกำลังพิจารณาว่าค่าที่ยอมรับได้คือ [0, 1, 2, 3, ⋯ 99, 100] และทุกอย่างอื่นเป็นเรื่องโง่ มาดูกันว่าทำไมผู้ใช้ยังสามารถป้อนค่า "โง่" เหล่านั้น

ความผิดพลาด

%^

ผู้ใช้ป้อนค่า 56 แต่กดผิดพลาดShiftขณะป้อน (ตัวอย่างเช่นเนื่องจากบนแป้นพิมพ์ภาษาฝรั่งเศสคุณต้องกดShiftเพื่อป้อนตัวเลขและผู้ใช้สลับระหว่างแป้นพิมพ์ภาษาฝรั่งเศสกับ QWERTY อย่างต่อเนื่อง)

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

56q

ที่นี่ผู้ใช้อาจป้อนตัวเลขตามด้วยแท็บเพื่อย้ายไปยังฟิลด์ถัดไป แทนการกด  ⇆  ผู้ใช้กดคีย์เพื่อนบ้าน

ความเข้าใจผิดและการตีความที่ผิด

อินพุตว่างอาจเป็นปกติที่สุด ผู้ใช้จินตนาการว่าฟิลด์นี้เป็นตัวเลือกหรือไม่ทราบว่าจะใส่อะไรในฟิลด์นี้

56.5

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

none

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

150

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

[____] % of disk space (2 TB)

เมื่อผู้ใช้เริ่มพิมพ์ข้อความก็จะเปลี่ยนข้อความทันทีเพื่อให้เป็น:

[5___] % of disk space (102.4 GB of 2 TB)

การรับรอง

ตัวเลขหรือตัวเลขขนาดใหญ่ที่มีจุดลอยตัวสามารถแสดงต่างกันได้ ยกตัวอย่างเช่นจำนวน 1,234.56 1,234.56สามารถเขียนเหมือนว่า: การแสดงข้อความของหมายเลขเดียวกันจะแตกต่างกันไปตามวัฒนธรรม ในฝรั่งเศส, 1 234,56หมายเลขเดียวกันจะถูกเขียนเช่นนี้ ดูเครื่องหมายจุลภาคที่คุณไม่คาดหวังและช่องว่าง

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

มนุษย์กับคอมพิวเตอร์

Twenty-four

มนุษย์ธรรมดาไม่ได้คิดแบบเดียวกับคอมพิวเตอร์ “ ยี่สิบสี่” เป็นตัวเลขจริงโดยไม่ขึ้นกับสิ่งที่พีซีจะบอกคุณ

แม้ว่า (1) ระบบส่วนใหญ่จะไม่จัดการกับการป้อนข้อมูลประเภทนี้ทั้งหมดและ (2) ผู้ใช้เกือบทุกคนจะไม่นึกถึงการป้อนตัวเลขที่เขียนด้วยตัวอักษรแบบเต็ม แต่ก็ไม่ได้หมายความว่าอินพุตนั้นโง่ ในAbout Face 3 Alan Cooper ชี้ให้เห็นว่าการไม่ใช้งานอินพุตนั้นเป็นเครื่องบ่งชี้ว่าคอมพิวเตอร์ไม่สามารถปรับตัวเข้ากับมนุษย์ได้และโดยพื้นฐานแล้วอินเตอร์เฟสควรจะสามารถจัดการอินพุตเหล่านั้นได้อย่างถูกต้อง

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

Unicode

5𝟨

Unicode ขอสงวนความประหลาดใจของตัวเอง: ตัวละครที่มีหน้าตาเหมือนกันจะไม่เหมือนกัน ไม่เชื่อ คัดลอกวางกับเครื่องมือสำหรับนักพัฒนาของเบราว์เซอร์ของคุณและกด"5𝟨" === "56"Enter

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

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

ข้อสรุป

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

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

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

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

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

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

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

โดยทั่วไปค่า 'สุ่ม' จะไม่สุ่ม คุณกำลังพยายามที่จะจับกรณีขอบ, "ไม่ทราบที่ไม่รู้จัก"

พูดเช่น # อักขระจะผิดพลาดคุณแอพ คุณไม่รู้เรื่องนี้ล่วงหน้าและมันเป็นไปไม่ได้ที่จะเขียนเคสทดสอบสำหรับอินพุตที่เป็นไปได้ทั้งหมด แต่เราสามารถเขียนแบบทดสอบเพื่อ"¬!"£$%^&*()_+-=[]{};'#:@~,./<>?|\"ดูว่ามันแตกหรือไม่

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

หลังจากนั้นฉันทำตามแนวทาง: if "a very specific use case" do, else show error

หากฉันมีกรณีการใช้งานหลายครั้งฉันจะกำหนดอย่างเคร่งครัดและโยงถึงข้างต้น

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

อินพุตการทดสอบปกติที่เขียนโดยมนุษย์พร้อมจะมาพร้อมกับสมมติฐานและอคติ อคติเหล่านี้สามารถตรวจพบคลาสของบั๊กได้จากการทดสอบ

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

Fuzzing ไม่มีอคติเกี่ยวกับการป้อนข้อมูล มันจะใช้ระบบของคุณอย่างไร้ความปราณีด้วยการผสมผสานที่เป็นไปได้ของอินพุต "ที่ถูกต้อง" Unicode, ASCII, ใหญ่, เล็ก, และข้อผิดพลาดมากมาย ระบบของคุณควรตอบสนองอย่างงดงามต่อพวกเขาทั้งหมด มันไม่ควรผิดพลาด ผู้ใช้ควรได้รับข้อความที่เหมาะสมเกี่ยวกับสิ่งที่ผิดพลาดและวิธีการแก้ไข มันไม่ได้เป็นขยะใน / ขยะออกก็มูลฝอย In / Out

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

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

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

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

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

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

หากเป็นไปตามที่ฉันต้องการฉันจะส่งคืนซอฟต์แวร์และถือว่าไม่เหมาะสำหรับวัตถุประสงค์ ความแตกต่างระหว่างผลิตภัณฑ์ซอฟต์แวร์ที่อ่อนแอและแข็งแกร่งคือระดับการทดสอบที่ได้รับ

ตัวอย่างเช่น: ขณะทำการทดสอบการทำงานของแบบฟอร์มในเว็บแอปพลิเคชันเราจะทดสอบฟิลด์โดยป้อนค่าการป้อนข้อมูลแบบสุ่มชนิดต่าง ๆ

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

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

เมื่อคุณเป็นซอฟต์แวร์ทดสอบความเครียดคุณพยายามค้นหาขอบเขตของข้อ จำกัด ของซอฟต์แวร์

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

คุณสามารถผ่านการทดสอบการทำงานทั้งหมดของคุณ แต่ยังคงล้มเหลวในการทดสอบความเครียด

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

ใช่นี่คือการปฏิบัติมาตรฐาน

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

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

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

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