【正文】 圖663此文件的大小測試數(shù)據(jù)：下面是測試用例中用到的測試數(shù)據(jù)：表66 測試用例所用的測試數(shù)據(jù)數(shù)據(jù)ID描述輸入測試用例IDD01沒有輸入搜索范圍,就進行搜索，是否出現(xiàn)報錯信息。無TC01D02沒有輸入搜索文件的搜索條件，就進行搜索，看是否能按照空字符竄匹配的原則正常搜索文件。輸入文件的搜索范圍：E:\TC02D03當(dāng)文件搜索完畢，能否出現(xiàn)提示信息。輸入文件的搜索范圍：E:\TC03D04輸入搜索條件，看程序能否正確的搜索符合條件的信息。輸入搜索文件名為：_ecErrorLog搜索范圍為：E:\TC04D05當(dāng)文件搜索完畢，雙擊顯示的文件，看能否進行文件的定位。雙擊要，定位的文件名TC05D06輸入文件的修改日期作為搜索條件，看是否能正確查找出符合要求的文件輸入修改日期在2008529到2008529之間TC06D07輸入文件的大小作為搜索條件，看是否能正確查找出符合要求的文件輸入條件文件至少有120KBTC07 測試結(jié)論通過以上的測試用例，達(dá)到了測試目的，進一步完善了本模塊程序所要表達(dá)的功能，提前對用戶提交的非法操作進行了預(yù)告，保證軟件得以正常的運行，幫助用戶正確搜索出需要查找的文件。避免了由于用戶的非法操作而使得軟件不能正常地運行。再次，當(dāng)我們所進行的操作都在合法的范圍之內(nèi)時，軟件的功能一切正常。符合軟件在設(shè)計時的制定的目標(biāo)。 第7章 與widows自帶的搜索程序的性能比較 比較方案為了體現(xiàn)比較的公平性，我選擇了分別用本搜索軟件和widows自帶的搜索程序在同一臺電腦上搜索同一個盤上的同一個文件。對搜索過程中CPU的使用率和程序占用內(nèi)存的最大數(shù)值做了比較，：對本軟件使用前和使用中所占用CPU的使用率和程序占用內(nèi)存的情況如下：使用前CPU的使用率和程序占用內(nèi)存的情況如下圖71:圖71使用中CPU的使用率和程序占用內(nèi)存的最大數(shù)值如下圖72:圖72widows自帶的搜索程序使用前和使用中所占用CPU的使用率和程序占用內(nèi)存的情況如下：使用前CPU的使用率和程序占用內(nèi)存的情況如下圖73:圖73使用中CPU的使用率和程序占用內(nèi)存的最大數(shù)值如下圖74:圖74從上面的執(zhí)行過程中資源的使用情況，可以看到在搜索過程中在CPU的使用率上，本程序在運行的過程中用到的CUP資源比windows自帶的要低，但要占用的內(nèi)存要比windows自帶的要高。結(jié)束語“多線程搜索軟件” 的畢業(yè)設(shè)計的完成，是我又一次理論到實現(xiàn)的過程,在這個過程中,我加深自己的專業(yè)知識,更加熟練地運用C進行windows程序編程。不僅如此，系統(tǒng)的設(shè)計還涉及到了一些較前沿的技術(shù)，讓我在鞏固基礎(chǔ)的同時，又學(xué)到新的知識。在設(shè)計的過程中肯定會遇到問題。比如一開始對如何匹配字符竄的知識不太熟悉，我就在圖書館查閱有關(guān)資料、在網(wǎng)上搜索，主要通過網(wǎng)絡(luò)來輔助自己的學(xué)習(xí)，同時也通過同學(xué)和老師的解惑，我很快掌握了這些在設(shè)計中要用到的知識點。通過這些經(jīng)歷讓我懂得了，不是懼怕不懂什么，而是懼怕不做什么。同時在這個過程中，讓我更加清楚地領(lǐng)會了數(shù)據(jù)庫原理、軟件工程等一些專業(yè)理論知識。并將其運用到實踐當(dāng)中去了。也深刻體會到軟件工程學(xué)在軟件設(shè)計過程中的條理性和重要性?？傊?，此次畢業(yè)設(shè)計擴充了我的知識面，這對我以后的學(xué)習(xí)和工作會有很好的啟示作用。參考文獻[1]（美）Bill Evjen, Jay Glynn. C高級編程[M]. 北京：清華大學(xué)出版社 2006.[2] 章立民. C程序開發(fā)與界面設(shè)計秘訣[M]. 北京：機械工業(yè)出版社2001.[3]（美）Jeffrey Friedl. 精通正則表達(dá)式[M]. 北京：電子工業(yè)出版社2000.[4]（美）Karli Watson. C入門經(jīng)典[M]. 北京：清華大學(xué)出版社 2006. 附錄A 外文翻譯－原文部分. .NET39。s Regex Flavor.NET has been built with a Traditional NFA regex engine, so all the important NFA related lessons from Chapter 4, 5, and 6 are applicable. Table 91 on the facing page summarizes .NET39。s regex flavor, most of which is discussed in Chapter 3.Certain aspects of the flavor can be modified by match modes (?110), turned on via option flags to the various functions and constructors that accept regular expressions, or in some cases, turned on and off within the regex itself via “(?modsmods)” and“ (?modsmods:?)” constructs. The modes are listed in Table 92 on page 408.In the table, raw escapes like “\w” are shown. These can be used directly in string literals (\w), and in C verbatim strings (@\w). In languages without regexfriendly string literals, such as C++, each backslash in the regex requires two in the string literal (\\w). See Strings as Regular Expressions(?101).The following additional notes augment Table 91: ? \b is a character shorthand for backspace only within a character class. Outside of a character class, \b matches a word boundary .\x allows exactly two hexadecimal digits, ., \xFCber matches 39。252。ber39。.\u allows exactly four hexadecimal digits, ., \u00FCber matches 39。252。ber39。, and “\u20AC” matches 39。€39。. ? As of Version , .NET Framework character classes support class subtraction, such as “[az[aeiou]]” for nonvowel lowercase ASCII letters . Within a class, a hyphen followed by a classlike construct subtracts the characters specified by the latter from those specified before the hyphen. ? \w, \d, and \s (and their uppercase counterparts) normally match the full range of appropriate Unicode characters, but change to an ASCIIonly mode with the option .In its default mode, \w matches the Unicode properties \p{Ll}, \p{Lu},\p{Lt}, \p{Lo}, \p{Nd} and \p{Pc}. Note that this does not include the \p{Lm} property. (See the table on page 123 for the property list.)In its default mode, \s matches “[?\f\n\r\t\v\x85\p{Z}]”. U+0085 is the Unicode NEXT LINE control character, and \p{Z} matches Unicode separator characters . ? \p{?} and \P{?} support standard Unicode properties and blocks, as of Unicode version . Unicode scripts are not supported.Block names require the 39。Is39。 prefix (see the table on page 125), and only the raw form unadorned with spaces and underscores may be used. For example, \p{Is_Greek_Extended} and \p{Is Greek Extended} are not allowed。 \p{IsGreekExtended} is required.Only the short property names like \p{Lu} are supported long names like \p{Lowercase_Letter} are not supported. Singleletter properties do require the braces (that is, the \pL shorthand for \p{L} is not supported). See the tables on pages 122 and 123.The special posite property \p{Lamp。} is not supported, nor are the special properties \p{All}, \p{Assigned}, and \p{Unassigned}. Instead, you might use “(?s:.)”,“ \P{Cn}”, and “\p{Cn}”, respectively. ? \G matches the end of the previous match, despite the documentation39。s claim that it matches at the beginning of the current match . ? Both lookahead and lookbehind can employ arbitrary regular expressions. As of this writing, the .NET regex engine is the only one that I know of that allows lookbehind with a subexpression that can match an arbitrary amount of text (?133). ? The option (also available via the (?n) mode modifier) turns off capturing for raw “(?)” parentheses. Explicitly named captures like “(?num\d+)” still work (?138). If you use named captures, this option allows you to use the visually more pleasing “(?)” for grouping instead of“ (?:?)”.. Additional Comments on the FlavorA few issues merit longer discussion than a bullet point allows.. Named capture.NET supports named capture , through the “(?name?) ”or“ (?39。name39。?)” syntax. Both syntaxes mean the same thing and you can use either freely, but I prefer the syntax with ?, as I believe it will be more widely used.You can backreference the text matched by a named capture within t