當然你覺得麻煩。不妨這樣做。
用列表的方式把需要測試注意的內容列出來。（日本人喜歡這樣的方法。很多日式式樣書都是這樣的），當然，具體的就要看公司的用例要求能不能允許了。
搞完了單體測試，那么下面就是大家認為比較難把握的復合測試了。因為涉及到的條件會非常的多，所以大家很想找到一個更加合適的方法去設計。
下面提供思路：
1.2vs2，3vs3，4vs4或者更多的去這樣設計。（最笨的。這樣你就不知道你到底覆蓋了多少，而又還有那些沒有覆蓋到，這就不好以后回歸的時候補充你的用例了）
2.用判定表做，然后用正交測試。（比較浪費時間，但是效率比1好，如果你的測試時間充分，那么就當是鍛煉技術和你的耐心吧！所以建議可以使用，只是建議）
3.你SQL相對比較好或者開發給你足夠的支持那么你直接去驗證SQL語句對不對就OK了瑟。比如排序字段加域名的組合。那你看SQL是不是ORDER BY 排序字段名就OK了瑟。因為單體測試已經通過，那么現在的工作其實就是驗證你的程序員是不是按照需求在后面加了相關的SQL組合查詢語句。再比如狀態+域名+開始時間。思路一樣，留個空間給大家思考這又怎么去驗證吧��！
總結之。測試并不比開發容易，有時候為了BUG的深層挖掘，常常是想很多辦法才發現1個BUG。（曾經我就為1BUG找了3天才挖掘到。。）
至于工具在這個例子中的運用，我想QTP的參數化就可以幫助你解決了。那具體的過程就不廢話了。趕快動手試下你現在準備測試的程序吧�。�！應該會給你提供幫助的。。。。
再次感謝測試時代的墨竹小姐。。。。。！同時再次祝她生日快樂�。�！
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
