這裏所謂的設計思路，其實就是寫測試腳本時要註意的點。在工作中，我根據自己的經驗，針對實際工作內容整理了腳本規範，逐步優化了腳本規範和測試腳本的模板。
個人認為，在編寫測試腳本時，需要註意以下幾點:規範性、簡潔性、時效性、結構化、穩定性、可讀性。
標準化有多重要？大家遵循的規範是壹樣的，所以看別人的劇本很容易找不到北。
測試腳本應該保持簡潔。精致是壹種修養，簡約是壹種風格。如何保持簡單？最基本的就是不要多余。
劇本時效性的重要性還沒有完全被認識。為什麽不徹底的說出來？因為在工作過程中，我發現很多測試人員都有壹個錯誤的想法:我在壹個套件/案例上花壹兩秒、幾秒或者更多的時間有什麽關系？
這有什麽關系？整個測試項目集中有數千個案例。如果每個案子多花壹秒鐘，積少成多就是幾千秒。根據我們手頭的病例數量，回歸至少還需要兩個小時。
對於壹個初級劇本作者來說，關註劇本的時效性可以考慮以下幾點:
再者，腳本的時效性離不開測試點和測試用例的組織。30個測試點組織成10個案例和30個測試點組織成8個案例，所以腳本的運行時效不同。及時性有多差取決於腳本運行的每個操作。
清楚的了解每個常見操作的運行時間，可以幫助我們寫出更及時的腳本。妳怎麽知道每個操作都需要時間來運行？看看腳本運行後生成的log.html。
清晰的腳本結構，包括套件設置/拆卸和案例設置/拆卸。
穩定的腳本可以降低自動化維護的成本。
腳本穩定性的常見問題有:
壹個可讀的腳本可以減少其他人學習和維護腳本的成本。
良好的用例編寫習慣可以讓別人更容易理解妳的測試用例和測試腳本。案例文檔中應該有完整、清晰、準確的測試案例。
在測試腳本中，您還可以添加適當的註釋，使腳本更容易理解。
評論分兩種:評論和“#”。前壹個批註的內容將反映在報告中，後壹個批註的內容不會顯示在報告中。建議在腳本中使用Comment進行註釋，並使用“Comment step-n”使腳本步驟和用例步驟壹壹對應。