หน้าแรก>ซอร์สโค้ด JSP>หมวดหมู่อื่นๆ
ดาวน์โหลด

Save เป็นกรอบการทดสอบบรรทัดคำสั่งอเนกประสงค์ที่สามารถใช้สำหรับการทดสอบเครื่องมือที่ทำงานกับรหัสเช่นเครื่องวิเคราะห์แบบคงที่และคอมไพเลอร์ มันเป็นแอปพลิเคชันดั้งเดิมที่ไม่จำเป็นต้องติดตั้ง SDK ใด ๆ

บันทึกคืออะไร?

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

ผลงาน

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

เริ่มต้นอย่างรวดเร็ว: สถานการณ์ผู้ใช้

1. การวิเคราะห์แบบคงที่คำเตือนตามลำดับ

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

2. การวิเคราะห์แบบคงที่คำเตือนการประมวลผลโครงการทั้งหมด

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

3. การแก้ไขรหัสอัตโนมัติหรือการสร้าง

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

4. คำเตือนที่คาดหวังในไฟล์ที่แยกจากกัน

  • ฉันไม่ต้องการระบุคำเตือนที่คาดหวังไว้ในรหัส
  • ฉันชอบใช้ ไฟล์แยกต่างหาก ใน Sarif หรือรูปแบบอื่น ๆ

วิธีการวิ่ง

  1. ดาวน์โหลดรุ่นล่าสุดที่เหมาะสำหรับระบบปฏิบัติการและสถาปัตยกรรมของคุณ
  2. ตั้งค่าและกำหนดค่าฐานทดสอบของคุณในรูปแบบบันทึกที่ถูกต้อง อ้างถึง test_detection และปลั๊กอินสำหรับคำแนะนำ
  3. ดำเนินการคำสั่งต่อไปนี้ (แก้ไขตามสถาปัตยกรรมและระบบปฏิบัติการของคุณ): save "/my/path/to/tests"

tests มีไฟล์การกำหนดค่า save.toml

บันทึกการบันทึก

ในการดีบักบันทึกการดำเนินการคุณสามารถใช้อาร์กิวเมนต์ต่อไปนี้: --log=TYPE , ที่ TYPE สามารถเป็นหนึ่งในสิ่งต่อไปนี้:

  • all - การบันทึกที่ครอบคลุมซึ่งรวมถึงข้อมูลทั้งหมดจากการดำเนินการบันทึกรายละเอียดมากกว่าการดีบัก (คล้ายกับร่องรอย)
  • debug - แสดงผลลัพธ์คำเตือนและข้อมูลการดีบัก
  • warnings - แสดงผลลัพธ์และคำเตือนที่สำคัญ
  • results_only - แสดงเฉพาะผลลัพธ์

ปลั๊กอินพร้อมตัวอย่าง

นี่คือรายการปลั๊กอินมาตรฐาน:

  • ปลั๊กอินเตือน: นี่คือสำหรับเครื่องมือทดสอบที่ตรวจจับปัญหาในซอร์สโค้ดและสร้างคำเตือน
  • Fix Plugin: ใช้สำหรับการทดสอบเครื่องมือวิเคราะห์แบบคงที่ที่แก้ไขข้อความ
  • ปลั๊กอิน Fix-and Warn: การเพิ่มประสิทธิภาพสำหรับสถานการณ์ที่คุณต้องการแก้ไขไฟล์และตรวจสอบคำเตือนว่าเครื่องมือไม่สามารถระบุได้ในการเรียกใช้ครั้งเดียว

หากคุณต้องการให้ปลั๊กอินหลายตัวทำงานในไดเรกทอรีของคุณโดยใช้ไฟล์ทดสอบเดียวกัน (ทรัพยากร) เพียงเพิ่มทั้งหมดลงในการกำหนดค่า save.toml : 

 [general]
...

[fix]
...

[warn]
...

[other plugin]
...

บันทึกคำเตือน DSL

บันทึก CLI คุณสามารถอ่านเพิ่มเติมเกี่ยวกับ warn plugin ได้ที่นี่

วิธีกำหนดค่า

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

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

คุณสามารถกำหนดค่าพฤติกรรมทั่วไปของบันทึกโดยใช้อาร์กิวเมนต์บรรทัดคำสั่งหรือโดยใช้ไฟล์กำหนดค่าชื่อ save.properties ไฟล์นี้ควรอยู่ในไดเรกทอรีเดียวกับการทดสอบรูททดสอบ, save.toml

สำหรับรายการที่ครอบคลุมของตัวเลือกที่สามารถส่งผ่านเพื่อบันทึกผ่านบรรทัดคำสั่งหรือไฟล์ save.properties โปรดดูที่ตารางตัวเลือกหรือเรียกใช้คำสั่ง save --help โปรดทราบว่าตัวเลือกที่มีตัวเลือกนั้นมีความไว

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

ทดสอบการตรวจจับและบันทึกไฟล์ TOML

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

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

ตัวอย่างเช่นด้วยลำดับชั้นของไดเรกทอรีต่อไปนี้: 

 | A
  | save.toml
  | B
    | save.toml

save.toml ในไดเรกทอรี B จะสืบทอดการตั้งค่าและคุณสมบัติจากไดเรกทอรี A.

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

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

 | A
  | B
  | myTest.java

ดังที่ได้กล่าวไว้ก่อนหน้านี้ save.toml เป็นสิ่งจำเป็นสำหรับการกำหนดค่าการทดสอบ เป็นการดีที่ ควรมีไฟล์การกำหนดค่าหนึ่งไฟล์สำหรับแต่ละไดเรกทอรีที่มีการทดสอบสร้างความสัมพันธ์แบบหนึ่งต่อหลายคน เราอ้างถึงไดเรกทอรีเหล่านี้เป็น test suites

เหตุผลที่อยู่เบื้องหลังการมีไฟล์การกำหนดค่าเดียวสำหรับชุดทดสอบหนึ่งชุดคือการหลีกเลี่ยงการกำหนดค่าซ้ำซ้อนภายในชุดทดสอบเดียวกัน

save.toml ไฟล์กำหนดค่า

การกำหนดค่าบันทึกใช้รูปแบบ TOML ที่ขับเคลื่อนโดยโครงการ KTOML ดังที่ได้กล่าวไว้ข้างต้น save.toml สามารถสืบทอดได้จากลำดับชั้นของไดเรกทอรี (ไดเรกทอรีหลัก)

ไฟล์การกำหนดค่ามีตาราง [general] และตาราง [plugins] สำหรับข้อมูลเพิ่มเติมเกี่ยวกับปลั๊กอินโปรดดูที่ส่วนปลั๊กอิน

ในส่วนนี้เราจะให้ข้อมูลเฉพาะเกี่ยวกับตาราง [general] ซึ่งสามารถใช้กับปลั๊กอินทั้งหมด 

 [general]
# Your custom tags that will be used to detect groups of tests (required)
tags = ["parsing", "null-pointer", "etc"]

# Custom free text that describes the test suite (required)
description = "My suite description"

# Simple suite name (required)
suiteName = "DocsCheck", "CaseCheck", "NpeTests", "etc" 

# Execution command (required at least once in the configuration hierarchy)
# By the default these binaries should be in the same directory of where SAVE is run 
# or should have full or relational path (root - is the directory with save executable)
execCmd="./ktlint -R diktat-0.4.2.jar"

# Excluded tests in the suite (optional). Here, you can list the names of excluded tests, separated by commas. By default, no tests are excluded.
# To exclude tests, use the relative path to the root of the test project (to the root directory of `save.toml`)
excludedTests = ["warn/chapter1/GarbageTest.kt", "warn/otherDir/NewTest.kt", "etc"]

# Command execution time for one test (in milliseconds)
timeOutMillis = 10000

# Language for tests
language = "Kotlin"

ดำเนินการทดสอบเฉพาะ

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

$ save [options] /path/to/tests/Test1

นอกจากนี้คุณยังสามารถจัดทำรายการเส้นทางสัมพัทธ์เพื่อทดสอบไฟล์ (คั่นด้วยช่องว่าง): 

$ save [options] /path/to/tests/Test1 /path/to/tests/Test2

บันทึกจะตรวจจับไฟล์ save.toml ที่ใกล้ที่สุดโดยอัตโนมัติและใช้การกำหนดค่าจากไฟล์

Note: บน Windows อย่าลืมใช้ backslash สองครั้ง \ เป็นตัวคั่นพา ธ

บันทึกเอาต์พุต

บันทึกสนับสนุนหลายรูปแบบสำหรับเอาต์พุตรายงานการทดสอบ:

  • PLAIN : ตารางที่มีลักษณะคล้าย markdown แสดงผลการทดสอบทั้งหมด
  • PLAIN_FAILED : คล้ายกับ PLAIN แต่แสดงเฉพาะการทดสอบที่ล้มเหลว
  • JSON : การแสดงโครงสร้างของผลการดำเนินการ

รูปแบบที่ต้องการสามารถเลือกได้โดยใช้ตัวเลือก --report-type=PLAIN

วัตถุประสงค์ของโครงการตรวจสอบและประเมินผลการวิเคราะห์แบบคงที่ (บันทึก) โครงการ

วัตถุประสงค์ของโครงการตรวจสอบและประเมินผลการวิเคราะห์แบบคงที่ (บันทึก) โครงการ

วัตถุประสงค์ของการบันทึก

อินโทร

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

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

ปัญหา

เมื่อเริ่มต้นการเดินทางของพวกเขาผู้สร้างเครื่องวิเคราะห์แบบคงที่ทุกคนเริ่มต้นด้วยการระบุประเภทของปัญหาเครื่องมือของพวกเขาจะกำหนดเป้าหมาย สิ่งนี้มักจะจำเป็นต้องค้นหารายการที่มีอยู่ของปัญหาที่อาจเกิดขึ้นหรือแพ็คเกจทดสอบที่สามารถเป็นแนวทางในกระบวนการพัฒนาโดยเฉพาะอย่างยิ่งหากทำตามวิธีการ TDD (การพัฒนาที่ขับเคลื่อนด้วยการทดสอบ) ในขณะที่โดเมนอื่น ๆ ในการเขียนโปรแกรมระบบได้สร้างมาตรฐานและชุดทดสอบเช่นเกณฑ์มาตรฐาน Spec.org ที่ใช้ทั่วโลกเพื่อประเมินซอฟต์แวร์และส่วนประกอบฮาร์ดแวร์ต่างๆ แต่ไม่มีมาตรฐานดังกล่าวสำหรับการระบุปัญหาในภาษาการเขียนโปรแกรมยอดนิยม ในขณะที่แนวทางสำหรับการเข้ารหัสใน C/C ++ ได้รับการจัดตั้งขึ้นโดย MISRA แต่ก็ไม่มีการเทียบเท่ากับภาษาที่ใช้กันอย่างแพร่หลายเช่น Python และ JVM-Languages มีชุดทดสอบที่ NIST แต่กรอบและระบบนิเวศของพวกเขาค่อนข้าง จำกัด

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

การพัฒนา

สร้าง

โครงการใช้ Gradle เป็นระบบสร้างและสามารถสร้างได้โดยใช้คำสั่ง ./gradlew build

ในการรวบรวมสิ่งประดิษฐ์พื้นเมืองคุณต้องติดตั้งข้อกำหนดเบื้องต้นตามที่อธิบายไว้ในเอกสาร Kotlin/Native

ในการเข้าถึงการพึ่งพาที่โฮสต์บนรีจิสทรีแพ็คเกจ GitHub ให้เพิ่มสิ่งต่อไปนี้ลงใน gradle.properties หรือ ~/.gradle/gradle.properties : 

 gprUser =<GH username>
gprKey =<GH personal access token>

สามารถสร้างโทเค็นการเข้าถึงส่วนบุคคลได้ที่ https://github.com/settings/tokens/new ตรวจสอบให้แน่ใจว่าโทเค็นมีขอบเขตที่มี read:packages

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

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