5.1 Input Features Our CUEZILLA too

5.1 Input Features Our CUEZILLA tool measures quality of bug reports on the basis of their contents. From the survey, we know the most desired features in bug reports by developers. Endowed with this knowledge, CUEZILLA first detects the features listed below. For each feature a score is awarded to the bug report, which is either binary (e.g., attachment present or not) or continuous (e.g., readability).
Itemizations. In order to recognize itemization in bug reports, we checked whether several subsequent lines started with an itemization character (such as -, *, or +). To recognize enumerations, we searched for lines starting with numbers or single characters that were enclosed by parenthesis or brackets or followed by a single punctuation character.
Keyword completeness. We reused the data set provided by Andy Koetal.[20] o define a quality-score of bug reports based on their content. In a first step,we removed stop words,reduced the words to their stem, and selected words occurring in at least 1% of bug reports. Next we categorized the words into the following groups:
– action items (e.g., open, select, click) – expected and observed behavior (e.g., error, missing) – steps to reproduce (e.g., steps, repro) – build-related (e.g., build) – user interface elements (e.g., toolbar, menu, dialog) In order to assess the completeness of a bug report, we computed for each group a score based on the keywords present in the bug report. The maximum score of 1 for a group is reached when a keyword is found. In order to obtain the final score (which is between 0 and 1), we averaged the scores of the individual groups. In addition to the description of the bug report, we analyze the attachments that were submitted by the reporter within 15 minutes after the creation of the bug report. In the initial description and attachments, we recognize the following features: CodeSamples. We identify C++ and JAVA code examples using techniques from island parsing [24]. Currently, our tools can recognize declarations (for classes, methods, functions, and variables),comments,conditional statements(suchasifand switch), and loops (such as for and while). StackTraces. We currently can recognize JAVA stack traces, GDB stack traces, and MOZILLA talkback data. Stack traces are easy to recognize with regular expressions: they consist of a start line (that sometimes also contains the top of the stack) and trace lines. Patches. In order to identify patches in bug reports and attachments we again used regular expressions. They consist of several start lines(which file to patch) and blocks (which are the changes to make) [23]. Screenshots. We identify the type of an attachment using the file toolinUNIX.If an attachment is an image,we recognizeitas a screenshot. If the file is recognized as text, we process the file and search for code examples, stack traces, and patches (see above). For more details about extraction of structural elements from bug reports we refer to our previous work [7], in which we showed that we can identify the above features with a close to perfect precision. After cleaning the description of a bug report from source code, stack traces, and patches, we compute its readability. Readability. To compute readability we use the style tool, which “analyses the surface characteristics of the writing style of a document” [10]. It is important to not confuse readability with grammatical correctness. The readability of a text is measured by the number of syllables per word and the length of sentences. Read ability measures are used by Amazon.com to inform customers about the difficulty of books and by the US Navy to ensure readability of technical documents [19]. In general, the higher a readability score the more complex a text is to read. Several readability measures return values that correspond to school grades. These grades tell how many years of education a reader should have before reading the text without difficulties. For our experiments we used the following seven readability measures: Kincaid, Automated Readability Index (ARI), Coleman-Liau, Flesh, Fog, Lix, and SMOG Grade.
5.5 Recommendations by CUEZILLA The core motivation behind CUEZILLA is to help reporters file better quality bug reports. For this, its ability to detect the presence of information features can be exploited to tip reporters on what information to add. This can be achieved simply by recommending additions from the set of absent information, starting with the feature that contributes to the quality further by the largest margin. These recommendations are intended to serve as cues or reminders to reporters of the possibility to add certain types of information; likely to improve bug report quality. The left panel of Figure 1 illustrates the concept. The text in the panel is determined by investigating the current contents of the report, and then determining that would be best, for instance, adding a code sample to the report. As and when new in formation

ผลลัพธ์ (ไทย) 1:

5.1 การป้อนข้อมูลคุณสมบัติ CUEZILLA ของเรามีคุณภาพมาตรการรายงานจุดบกพร่องตามเนื้อหาของเครื่องมือ จากการสำรวจ เรารู้ว่าสิ่งที่ต้องการมากที่สุดในรายงานข้อผิดพลาดโดยนักพัฒนา CUEZILLA แรก endowed กับความรู้ ตรวจพบคุณลักษณะที่แสดงอยู่ด้านล่าง สำหรับคุณลักษณะแต่ละ คะแนนที่มอบให้รายงานข้อบกพร่อง ซึ่งเป็นแบบไบนารี (เช่น สิ่งที่แนบมาแสดง หรือไม่) หรือต่อเนื่อง (เช่น อ่าน) Itemizations การแสดงรายการในรายงานข้อผิดพลาด เราตรวจสอบว่า บรรทัดหลายบรรทัดตามมาเริ่มต้น ด้วยอักขระแสดงรายการ (เช่น-, *, หรือ +) การระบุหมายเลขการรับรู้ เราค้นหาบรรทัดที่ขึ้นต้น ด้วยตัวเลขหรือตัวอักษรเดี่ยวที่ถูกล้อมรอบ ด้วยวงเล็บหรือเล็บ หรือตาม ด้วยอักขระเครื่องหมายวรรคตอนเดียว คำสำคัญความสมบูรณ์ เรานำชุดข้อมูลโดย Andy Koetal [20] o กลุ่มคะแนนคุณภาพตามเนื้อหาของรายงานข้อผิดพลาด ในขั้นตอนแรก เราเอาคำหยุด ลดลงคำว่าเป็นต้นกำเนิดของพวกเขา และเลือกคำที่เกิดขึ้นในเวลาอย่างน้อย 1% ของรายงานข้อผิดพลาด ถัดไป เราแบ่งคำกลุ่มต่อไปนี้:–รายการการกระทำ (เช่น เปิด เลือก คลิ) – ที่คาด และสังเกตลักษณะการทำงาน (เช่น ผิดพลาด หายไป) – ขั้นตอนการทำซ้ำ (เช่น ขั้นตอน repro) – เกี่ยวกับ (เช่น สร้าง) – รายงานผู้ใช้องค์ประกอบส่วนติดต่อ (เช่น แถบเครื่องมือ เมนู โต้ตอบ) เพื่อประเมินความสมบูรณ์ของข้อผิดพลาด เราคำนวณสำหรับแต่ละกลุ่มบันทึกคะแนนตามคำสำคัญที่อยู่ในรายงานข้อผิดพลาด คะแนนสูงสุดของ 1 สำหรับกลุ่มจะมาถึงเมื่อพบคำสำคัญ เพื่อขอรับการพิจารณาให้คะแนน (ซึ่งอยู่ระหว่าง 0 และ 1), เราเฉลี่ยคะแนนของแต่ละกลุ่ม นอกจากคำอธิบายของรายงานข้อผิดพลาด เราวิเคราะห์สิ่งที่แนบที่ส่งมา โดยผู้รายงานภายใน 15 นาทีหลังจากการสร้างรายงานข้อผิดพลาด ในคำอธิบายเริ่มต้นและสิ่งที่แนบมา เรารู้จักคุณลักษณะต่อไปนี้: CodeSamples เราระบุตัวรหัส c ++และ JAVA อย่างที่ใช้เทคนิคจากเกาะที่แยกวิเคราะห์ [24] ขณะนี้ เครื่องมือของเราสามารถรับรู้ประกาศ (สำหรับชั้นเรียน การ ฟังก์ชัน ตัวแปร), ความเห็น เงื่อนไข (สลับ suchasifand), และลูป (เช่นเป็นสำหรับ และในขณะที่) StackTraces เราในขณะนี้สามารถรับรู้ JAVA สแตก GDB สแตก และ MOZILLA talkback ข้อมูล สแตกจะง่ายต่อการจดจำกับนิพจน์ปกติ: พวกเขาประกอบด้วยบรรทัดเริ่มต้น (ที่บางครั้งยัง ประกอบด้วยด้านบนของกองซ้อน) และติดตามบรรทัด แพทช์ เพื่อระบุการปรับปรุงในรายงานข้อบกพร่องและสิ่งที่แนบมา เราอีกใช้นิพจน์ปกติ ประกอบด้วยหลายเริ่มบรรทัด (ซึ่งรูปที่) และบล็อก (ซึ่งเป็นการเปลี่ยนแปลง) [23] ภาพหน้าจอ เราระบุชนิดของสิ่งที่แนบโดยใช้ toolinUNIX.If รูปแนบเป็นรูปภาพ เรา recognizeitas หน้าจอ ถ้ารูปเป็นที่ยอมรับเป็นข้อความ เราประมวลผลรูปและค้นหาตัวอย่างรหัส สแตก และแพทช์ (ดูข้างต้น) รายละเอียดเพิ่มเติมเกี่ยวกับสกัดของโครงสร้างจากรายงานจุดบกพร่อง เราถึงงานของเราก่อนหน้านี้ [7], ซึ่งเราพบว่า เราสามารถระบุคุณสมบัติข้างต้นกับความแม่นยำสมบูรณ์แบบ หลังทำความสะอาดรายละเอียดของรายงานข้อผิดพลาด จากรหัสแหล่งที่มา สแตก แพทช์ เราคำนวณความสามารถในการอ่าน อ่าน การคำนวณอ่าน เราใช้เครื่องมือสไตล์ ซึ่ง "วิเคราะห์ลักษณะพื้นผิวของรูปแบบการเขียนเอกสาร" [10] มันเป็นสิ่งสำคัญเพื่อไม่ให้สับสนอ่าน ด้วยความถูกต้องทางไวยากรณ์ ให้อ่านข้อความจะถูกวัด โดยจำนวนพยางค์ต่อคำและความยาวของประโยค ใช้วัดความสามารถในการอ่าน โดย Amazon.com เพื่อแจ้งลูกค้าเกี่ยวกับ difficulty ของหนังสือ และนาวิกให้อ่านเอกสารทางเทคนิค [19] ทั่วไป การอ่านสูงคะแนนยิ่งซับซ้อนข้อความคือการ อ่าน อ่านหลายมาตรการกลับค่าที่ตรงไปโรงเรียนเกรด เกรดเหล่านี้บอกจำนวนปีของการศึกษาการอ่านควรมีก่อนที่จะอ่านข้อความ โดย difficulties สำหรับการทดลองของเรา เราใช้มาตรการอ่านเจ็ดต่อไป: สถานที่คินเคด อัตโนมัติอ่านดัชนี (อารีย์), โคลแมน Liau เนื้อ หมอก Lix และหมอกควันระดับ 5.5 แนะนำ โดย CUEZILLA CUEZILLA ไตร่ตรองหลักคือเพื่อ ช่วยนักข่าวรูปดีกว่าคุณภาพรายงานจุดบกพร่อง สำหรับนี้ ความสามารถในการตรวจหาข้อมูลคุณสมบัติสามารถใช้ประโยชน์ให้ทิปผู้สื่อข่าวบนข้อมูลที่ต้องการเพิ่ม นี้สามารถทำได้ง่าย ๆ โดยการแนะนำเพิ่มเติมจากชุดขาดข้อมูล เริ่มต้น ด้วยคุณลักษณะที่สนับสนุนคุณภาพเพิ่มเติมโดยอัตรากำไรที่ใหญ่ที่สุด คำแนะนำเหล่านี้มีวัตถุประสงค์เพื่อใช้เป็นสัญลักษณ์หรือเตือนความจำให้ผู้สื่อข่าวเป็นไปได้เพื่อเพิ่มบางชนิดของข้อมูล แนวโน้มที่จะปรับปรุงคุณภาพการรายงานข้อผิดพลาด แผงด้านซ้ายของรูปที่ 1 แสดงให้เห็นถึงแนวคิด ข้อความในแผงถูกกำหนด โดยเนื้อหาของรายงานการตรวจสอบ และการกำหนดที่จะดีที่สุด เช่น การเพิ่มตัวอย่างรหัสการรายงาน ตามใหม่ในการ

ผลลัพธ์ (ไทย) 2:

5.1 การป้อนข้อมูลคุณสมบัติ CUEZILLA มาตรการเครื่องมือที่มีคุณภาพของเราในการรายงานข้อผิดพลาดบนพื้นฐานของเนื้อหาของพวกเขา จากการสำรวจเรารู้คุณสมบัติที่ต้องการมากที่สุดในการรายงานข้อผิดพลาดโดยนักพัฒนา กอปรด้วยความรู้นี้ CUEZILLA แรกตรวจพบคุณสมบัติที่ระบุไว้ด้านล่าง สำหรับแต่ละมีคะแนนเป็นรางวัลให้กับรายงานข้อผิดพลาดซึ่งเป็นทั้งไบนารี (เช่นสิ่งที่แนบมาในปัจจุบันหรือไม่) หรือต่อเนื่อง (เช่นการอ่าน).
Itemizations เพื่อให้รู้จักการลงรายละเอียดในรายงานข้อผิดพลาดที่เราตรวจสอบไม่ว่าจะเป็นเส้นที่ตามมาหลายเริ่มต้นด้วยตัวอักษรลงรายละเอียด (เช่น -, *, หรือ +) ที่จะรับรู้ enumerations เราหาสายที่เริ่มต้นด้วยตัวเลขหรือตัวอักษรเดียวที่ถูกล้อมรอบด้วยวงเล็บหรือวงเล็บหรือตามด้วยตัวอักษรวรรคตอนเดียว.
คำสำคัญครบถ้วน เรานำกลับมาใช้ชุดข้อมูลที่มีให้โดยแอนดี้ Koetal. [20] o de Fi NE ที่มีคุณภาพคะแนนรายงานข้อผิดพลาดขึ้นอยู่กับเนื้อหาของพวกเขา ในขั้นตอนแรกเราได้ลบคำหยุดลดคำที่ต้นกำเนิดของพวกเขาและคำที่เลือกที่เกิดขึ้นในเวลาอย่างน้อย 1% ของรายงานข้อผิดพลาด ต่อไปเราแบ่งคำที่เป็นกลุ่มต่อไปนี้:
- รายการการดำเนินการ (เช่นเปิดการคลิกเลือก) - ที่คาดหวังและสังเกตพฤติกรรม (เช่นข้อผิดพลาดที่ขาดหายไป) - ขั้นตอนในการทำซ้ำ (เช่นขั้นตอน Repro) - สร้างที่เกี่ยวข้อง ( เช่นการสร้าง) - องค์ประกอบส่วนติดต่อผู้ใช้ (เช่นแถบเครื่องมือเมนูโต้ตอบ) เพื่อที่จะประเมินความสมบูรณ์ของรายงานข้อผิดพลาดที่เราคำนวณสำหรับแต่ละกลุ่มคะแนนตามคำหลักที่มีอยู่ในรายงานข้อผิดพลาด คะแนนสูงสุด 1 สำหรับกลุ่มที่จะมาถึงเมื่อคำหลักที่พบ เพื่อให้ได้คะแนน Fi NAL (ซึ่งอยู่ระหว่าง 0 และ 1) เรามีค่าเฉลี่ยคะแนนของกลุ่มบุคคล นอกเหนือไปจากรายละเอียดของรายงานข้อผิดพลาดที่เราวิเคราะห์สิ่งที่แนบมาที่ถูกส่งมาโดยผู้สื่อข่าวได้ภายใน 15 นาทีหลังจากการสร้างรายงานข้อผิดพลาดที่ ในรายละเอียดเบื้องต้นและสิ่งที่แนบมาเราตระหนักถึงคุณสมบัติดังต่อไปนี้: CodeSamples เราระบุ C ++ และ Java ตัวอย่างโค้ดโดยใช้เทคนิคการแยกจากเกาะ [24] ปัจจุบันเครื่องมือของเราสามารถรับรู้การประกาศ (สำหรับการเรียนวิธีการฟังก์ชั่นและตัวแปร), ความเห็น, งบเงื่อนไข (สวิทช์ suchasifand) และลูป (เช่นและในขณะที่) stacktraces ขณะนี้เราสามารถรับรู้ร่องรอย JAVA กอง GDB ร่องรอยสแต็คและข้อมูล talkback มอซิลลา ร่องรอยสแต็คเป็นเรื่องง่ายที่จะยอมรับกับการแสดงออกปกติ: พวกเขาประกอบด้วยสายการเริ่มต้น (ที่บางครั้งยังมีด้านบนของสแต็ค) และติดตามเส้น แพทช์ เพื่อที่จะระบุแพทช์ในรายงานข้อผิดพลาดและสิ่งที่แนบมาเราใช้การแสดงออกปกติอีกครั้ง พวกเขาประกอบด้วยเส้นเริ่มต้นหลาย (ซึ่ง Fi le แพทช์) และบล็อก (ซึ่งการเปลี่ยนแปลงที่จะทำให้) [23] ภาพหน้าจอ เราระบุชนิดของสิ่งที่แนบมาโดยใช้ Fi le toolinUNIX.If สิ่งที่แนบมาเป็นภาพที่เรา recognizeitas ภาพหน้าจอ ถ้า Fi le ได้รับการยอมรับเป็นข้อความที่เราดำเนินการ Le Fi และค้นหาตัวอย่างโค้ดกองร่องรอยและแพทช์ (ดูด้านบน) สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับการสกัดขององค์ประกอบโครงสร้างจากรายงานข้อผิดพลาดที่เราจะเรียกการทำงานของเราก่อนหน้า [7] ในการที่เราแสดงให้เห็นว่าเราสามารถระบุคุณสมบัติข้างต้นมีความใกล้เคียงกับความแม่นยำที่สมบูรณ์แบบ หลังจากทำความสะอาดรายละเอียดของรายงานข้อผิดพลาดจากซอร์สโค้ดร่องรอยสแต็คและแพทช์เราคำนวณการอ่านของมัน การอ่าน การคำนวณการอ่านที่เราใช้เครื่องมือที่มีสไตล์ซึ่ง "การวิเคราะห์ลักษณะพื้นผิวของสไตล์การเขียนของเอกสาร" [10] มันเป็นสิ่งสำคัญที่จะไม่สับสนอ่านง่ายมีความถูกต้องตามหลักไวยากรณ์ อ่านง่ายของข้อความจะวัดจากจำนวนพยางค์ต่อคำและความยาวของประโยค อ่านมาตรการความสามารถในการใช้งานโดย Amazon.com เพื่อแจ้งให้ลูกค้าเกี่ยวกับ culty Fi DIF หนังสือและโดยกองทัพเรือสหรัฐเพื่อให้แน่ใจว่าการอ่านของเอกสารทางวิชาการ [19] โดยทั่วไปสูงกว่าคะแนนการอ่านที่มีความซับซ้อนมากขึ้นข้อความคือการอ่าน มาตรการการอ่านหลายค่าตอบแทนที่สอดคล้องกับการเรียน เกรดเหล่านี้บอกว่าหลายปีของการศึกษาเป็นผู้อ่านควรมีก่อนที่จะอ่านข้อความได้โดยไม่ต้อง DIF culties Fi สำหรับการทดลองของเราที่เราใช้ต่อไปนี้เจ็ดอ่านง่ายมาตรการ:. Kincaid อัตโนมัติดัชนีการอ่าน (ARI) โคลแมน-เหลียวเนื้อตัดหมอก, Lix และหมอกควันชั้นประถมศึกษา
5.5 การแนะนำโดย CUEZILLA แรงจูงใจหลักที่อยู่เบื้องหลัง CUEZILLA คือการช่วยให้ผู้สื่อข่าว Fi le คุณภาพที่ดีขึ้น รายงานข้อผิดพลาด สำหรับเรื่องนี้ความสามารถในการตรวจสอบสถานะของคุณลักษณะของข้อมูลที่สามารถใช้ประโยชน์ให้ทิปกับผู้สื่อข่าวเกี่ยวกับข้อมูลที่จะเพิ่ม นี้สามารถทำได้ง่ายๆโดยการแนะนำเพิ่มเติมจากชุดของข้อมูลขาดที่เริ่มต้นด้วยคุณลักษณะที่ก่อให้เกิดการมีคุณภาพต่อไปโดยอัตรากำไรที่ใหญ่ที่สุด คำแนะนำเหล่านี้มีวัตถุประสงค์เพื่อใช้เป็นตัวชี้นำหรือการแจ้งเตือนกับผู้สื่อข่าวของความเป็นไปได้ที่จะเพิ่มข้อมูลบางประเภท; มีแนวโน้มที่จะปรับปรุงคุณภาพการรายงานข้อผิดพลาด แผงด้านซ้ายของรูปที่ 1 แสดงให้เห็นถึงแนวคิด ข้อความในแผงจะถูกกำหนดโดยการตรวจสอบเนื้อหาปัจจุบันของรายงานและจากนั้นระบุว่าจะดีที่สุดเช่นการเพิ่มตัวอย่างรหัสไปยังรายงาน และเมื่อใหม่ในการสร้าง