การครอบคลุมเส้นทางรับประกันการค้นหาข้อบกพร่องทั้งหมดหรือไม่

หากทุกเส้นทางผ่านโปรแกรมได้รับการทดสอบแล้วไม่รับประกันว่าจะหาข้อบกพร่องทั้งหมดหรือไม่?

ถ้าไม่ทำไมไม่ คุณจะผ่านทุกขั้นตอนการทำงานของโปรแกรมและไม่พบปัญหาหากมีอยู่ได้อย่างไร

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

หมายเหตุ: บทความนี้จะให้ข้อมูลสรุปสั้น ๆ เกี่ยวกับประเภทความคุ้มครองตามที่ฉันคิดถึง

หากทุกเส้นทางผ่านโปรแกรมได้รับการทดสอบแล้วไม่รับประกันว่าจะหาข้อบกพร่องทั้งหมดหรือไม่?

ไม่

ถ้าไม่ทำไมไม่ คุณจะผ่านทุกขั้นตอนการทำงานของโปรแกรมและไม่พบปัญหาหากมีอยู่ได้อย่างไร

เพราะแม้ว่าคุณทดสอบเป็นไปได้ทั้งหมดเส้นทางที่คุณยังไม่ได้ทดสอบพวกเขาด้วยความเป็นไปได้ทั้งหมดค่าหรือเป็นไปได้ทั้งหมดรวมกันของค่า ตัวอย่างเช่น (pseudocode):

def Add(x as Int32, y as Int32) as Int32:
   return x + y

Test.Assert(Add(2, 2) == 4) //100% test coverage
Add(MAXINT, 5) //Throws an exception, despite 100% test coverage

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

- EW Dijkstra (เน้นเพิ่มเขียนเมื่อปี 1988 ตอนนี้เป็นเวลามากกว่า 2 ทศวรรษแล้ว)

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

ลองนึกภาพคุณมี testuite ที่ครอบคลุมเส้นทาง 100% ตอนนี้ลบการยืนยันทั้งหมดและเรียกใช้ Testuite อีกครั้ง ตอนนี้, Testuite ยังคงมีความครอบคลุมเส้นทาง 100% แต่มันไม่มีอะไรทดสอบอย่างแน่นอน

นี่เป็นตัวอย่างที่ง่ายกว่าในการปัดเศษสิ่งต่างๆออก พิจารณาอัลกอริทึมการเรียงลำดับต่อไปนี้ (ใน Java):

int[] sort(int[] x) { return new int[] { x[0] }; }

ตอนนี้มาทดสอบกัน:

sort(new int[] { 0xCAFEBABE });

ตอนนี้ให้พิจารณาว่า (A) การเรียกเฉพาะนี้เพื่อsortส่งกลับผลลัพธ์ที่ถูกต้อง (B) การทดสอบโค้ดทั้งหมดได้รับการครอบคลุม

แต่เห็นได้ชัดว่าโปรแกรมไม่ได้เรียงลำดับ

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

พิจารณาabsฟังก์ชั่นที่คืนค่าสัมบูรณ์ของตัวเลข นี่คือการทดสอบ (Python ลองนึกภาพกรอบการทดสอบบางส่วน):

def test_abs_of_neg_number_returns_positive():
    assert abs(-3) == 3

การใช้งานนี้ถูกต้อง แต่ได้รับความคุ้มครองรหัส 60% เท่านั้น:

def abs(x):
    if x < 0:
        return -x
    else:
        return x

การใช้งานนี้ผิด แต่ได้รับการครอบคลุมโค้ด 100%:

def abs(x):
    return -x

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

รหัสต่อไปนี้มี Use-After-Free:

int main(void)
{
    int* a = malloc(sizeof(a));
    int* b = a;
    *a = 0;
    free(a);
    *b = 12; /* UAF */
    return 0;
}

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

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

int main(int a, int b)
{
    if (a != b) {
        if (cryptohash(a) == cryptohash(b)) {
            return ERROR;
        }
    }
    return 0;
} 

หากชุดทดสอบของคุณสามารถสร้างเส้นทางทั้งหมดสำหรับสิ่งนี้แสดงความยินดีกับคุณว่าเป็นผู้เข้ารหัส

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

อีกวิธีหนึ่งในการตอบคำถามนี้คือจากการปฏิบัติ:

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

คำถามที่เกี่ยวข้องจึงคือ:

จุดครอบคลุมของเครื่องมือครอบคลุมโค้ดคืออะไร?

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

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

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

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

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

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

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

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

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

หากทุกเส้นทางผ่านโปรแกรมได้รับการทดสอบแล้วไม่รับประกันว่าจะหาข้อบกพร่องทั้งหมดหรือไม่?

ดังที่ได้กล่าวไปแล้วคำตอบคือไม่

ถ้าไม่ทำไมไม่

นอกจากสิ่งที่กำลังพูดมีข้อบกพร่องปรากฏในระดับต่าง ๆ ซึ่งไม่สามารถทดสอบด้วยการทดสอบหน่วย เพียงพูดถึงไม่กี่:

• ข้อบกพร่องติดกับการทดสอบการรวม (การทดสอบหน่วยไม่ควรใช้ทรัพยากรจริงหลังจากทั้งหมด)
• ข้อบกพร่องในความต้องการ
• ข้อบกพร่องในการออกแบบและสถาปัตยกรรม

การทดสอบทุกเส้นทางหมายความว่าอย่างไร

คำตอบอื่น ๆ นั้นยอดเยี่ยม แต่ฉันต้องการเพิ่มว่าเงื่อนไข "ทุกเส้นทางผ่านโปรแกรมที่ถูกทดสอบ" นั้นไม่ชัดเจน

พิจารณาวิธีนี้:

def add(num1, num2)
  foo = "bar"  # useless statement
  $global += 1 # side effect
  num1 + num2  # actual work
end

หากคุณเขียนการทดสอบที่ยืนยันadd(1, 2) == 3เครื่องมือครอบคลุมรหัสจะบอกคุณว่ามีการใช้งานทุกบรรทัด แต่คุณไม่ได้ยืนยันอะไรเลยเกี่ยวกับผลข้างเคียงของโลกหรือการมอบหมายที่ไร้ประโยชน์ บรรทัดเหล่านั้นดำเนินการแล้วแต่ยังไม่ได้รับการทดสอบจริง ๆ

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

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

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

การทดสอบทุกครั้งที่เราทำได้คือการวิเคราะห์พฤติกรรมเพื่อไปยังโปรแกรมที่ปราศจากข้อบกพร่อง ไม่มีอะไรสมบูรณ์แบบ.

ดี ... ใช่จริง ๆ ถ้าทุกเส้นทาง "ผ่าน" โปรแกรมจะถูกทดสอบ แต่นั่นหมายความว่าทุกเส้นทางที่เป็นไปได้ผ่านพื้นที่ทั้งหมดของสถานะที่เป็นไปได้ทั้งหมดที่โปรแกรมสามารถมีได้รวมถึงตัวแปรทั้งหมด แม้แต่โปรแกรมที่เรียบง่ายที่รวบรวมแบบสแตติก - กล่าวคือ cruncher number ของ Fortran เก่า - ที่ไม่สามารถทำได้แม้ว่าอย่างน้อยก็สามารถจินตนาการได้: ถ้าคุณมีตัวแปรจำนวนเต็มสองตัวคุณจะต้องจัดการกับวิธีที่เป็นไปได้ทั้งหมด กริดสองมิติ จริง ๆ แล้วมันดูเหมือนพนักงานขายเดินทาง สำหรับnตัวแปรเช่นคุณจะจัดการกับnพื้นที่มิติดังนั้นสำหรับโปรแกรมใด ๆ ที่จริงงานคือ untractable สมบูรณ์

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

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

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

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

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

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