<pre id="ff7yo"></pre>

      <form id="ff7yo"><legend id="ff7yo"></legend></form>
        <nav id="ff7yo"><listing id="ff7yo"></listing></nav><nav id="ff7yo"></nav>

        <nav id="ff7yo"><listing id="ff7yo"></listing></nav>
        <small id="ff7yo"></small><nav id="ff7yo"><dd id="ff7yo"></dd></nav>
      1. <nav id="ff7yo"></nav>
          <form id="ff7yo"></form><nav id="ff7yo"></nav>
          <nav id="ff7yo"></nav>
          <sub id="ff7yo"></sub>
          更多課程 選擇中心

          軟件測試培訓
          達內IT學院

          400-111-8989

          軟件開發實踐:如何將編碼和文檔相結合?

          • 發布:軟件測試培訓
          • 來源:軟件測試問答
          • 時間:2017-09-11 16:42

          好像軟件開發人員都特別討厭文檔(個人觀察,個人觀點)。做軟件有一大堆文檔,例如項目立項報告,需求調研報告,需求規格說明書,概要設計報告,詳細設計報告...。文檔一大堆,真正讓大家仔細閱讀,起到作用的好像不多。

          倒也不是這些文檔沒有,其實這些文檔的作者都是費很大的心力去完成的,雖然有些段落是文檔中模板需要才添加的,有很多套話。但是還是有很多章節是很有用,作者下了很大功夫的, 對開發很有用的。如項目立項報告中對開該項目的定位,市場分析及可能形成的門檻和競爭優勢的分析都是很有用的。需求調研報告中的競品分析,特性識別也是很有用的。需求規格說明書也是開發人員在開發過程中,會時不時找出來仔細閱讀,認真去摳的。

          但是文檔給我們的感覺還是雖然下了大力氣寫,但是好像效果都不好,性價比不高。

          在敏捷開發中, 對文檔就不是很重視了。在敏捷開發中, 提倡講述用戶故事,然后就是實現,測試等。敏捷開發提倡源代碼即文檔。

          當時在做了多年的開發后,我發覺適當的文檔,對于產品經理,開發者,測試人員之間的溝通,還是很有用的。

          最近進行了一次編碼和文檔相結合的實現,在這里寫出來,和大家交流一下。

          1 概述

          最近做了一個小功能。代碼做完后大約有800-1000行左右(C程序),功能比較獨立, 而且是有一個后臺需求, 沒有UI。我嘗試在開發這個功能的過程中寫文檔。

          這個文檔是按照自己的理解寫的, 沒有套用任何模板。最開始也是自己使用的,作為整理思路的工具。該文檔后來也用于與產品經理及測試人員溝通。自己覺得效果還可以。通過該文檔,與產品經理澄清了一些自己認識不正確的地方。 該文檔給測試人員提供了幫助,而且能讓測試人員盡量的了解了需求和設計。

          2 文檔內容

          2.1 需求整理

          首先是關于需求的整理。因為只有理解好需求才能開發出正確的軟件。怎么算是理解了需求, 寫出來,并于需求相關人員達成一致,才能算理解了需求。

          以前經常會遇到開發人員自己以為理解了需求, 下手開發,開發完成后才發現和需求人員理解的不一致, 甚至需求人員理解與客戶的真正需求不一致的情況。所以上來我就對需求進行整理。

          到這兒,可能大家會頭大。用瀑布式開發流程下,寫過需求調研報告和需求規格說明書的人知道,這些都是大工程,工作量大,而且預期效果也不好。

          在這里,我沒有按照以前的需求規格說明書的思路整理需求。而是采用敏捷開發中的用戶故事的方式來寫。

          2.1.1 用戶需求

          用戶需求按照如下樣式寫的:

          作為一名...,我希望..., 以便于...。

          這里沒有以前需求規格說明書中大寫繁瑣的部分,只是簡單的一句話,當時很有用。如果你沒有寫過,非常建議你試試。

          該段文字信息量還是比較大, 而且每一段都是很重要的,根據優先級有大到小:以便于>作為一名>我希望。

          關于這句話,簡易看看《軟件需求 第三版》的相關章節,寫的很好。《敏捷革命》的第六章中的“不要盲目執行任務, 要領會用戶故事”對這個句子也有精彩的描述。

          關于這部分,我的建議是:

          不要超過5條,如果超過條,請仔細反思一下,是不是對需求真正理解了。(我的前提是一個較小的功能)。

          關于這部分,在我的實踐中, 最開始以兩條(實際用戶和維護人員), 后來又一次識別出了一條(工廠模式的測試人員)。

          2.1.2 功能需求

          有了用戶需求后, 需要將用戶需求細化為功能需求,也就是功能點。簡易用下面的語句:

          A應該...。

          我本次的實踐中,功能點共6項, 包括“該功能應該提供完善的日志,以便于在出現為你的時候,通過日志能快速定位問題”和“在系統重啟后,日志不應該丟失”等。其中多數是在開始時識別出來的,也有后來添加的,例如工廠模式下的特殊處理。

          2.1.3 限制,依賴和假設

          在我們的功能開發中,其實是有很多限制,依賴和假設的。很多時候,我們會把這些依賴和限制記在心里,這是不夠的,我們需要把它們寫出來。這些對我們開發人員,測試人員和需求相關人員都很有用。這些限制,依賴和假設要得到需求人員的認可,測試人員的理解。在編碼時候,我們甚至需要把這些作為注釋放在代碼中。

          2.1.4 總結

          關于需求的整理,需要得到需求人員和客戶的認可,開發人員保證真正的理解(我的理解: 在用戶需求中,能真正明白“以便于”部分和“作為一名”部分,就算是真正了解了), 測試人員應該深入了解這些內容,才能知道功能的來龍去脈,寫出正確的測試用例。

          在我的實踐中,這部分的文檔其實不多, 應該只有半頁多一點的文檔。

          2.2 需求測試用例

          根據需求編寫需求測試用例,我是站在開發者的角度寫的測試用例,目標就是覆蓋需求中的功能點及其各種情況。格式比較隨意, 主要是能把這些功能都驗證了,沒有落下測試點。

          在本次實踐中,我共編寫10條測試用例。

          這些測試用例希望能得到測試人員的評審。

          其實測試人員未必會直接用這些測試用例,但是能給他們很大的輔助。本次實踐中, 測試人員對這些測試用例還是很關注的。

          2.3 設計

          主要是記錄下設計中的想法和思路。在本次實踐中, 我畫了一張關聯圖,主要用來標識該功能中, 系統與哪些外部對象交互,交互了哪些信息。然后用一些文字表述了實現的基本思路。

          本次實踐中,設計部分大約占半頁, 包括關聯圖。

          2.4 設計測試用例

          針對設計設計的測試用例。這一塊也需要測試人員評審。 但是這塊測試主要是我自己使用的。因為我覺得一個功能發布出去,最好自己能做以便FT測試。

          本次事件中,設計的測試用例大約有*項。

          2.5 實現

          這一部分主要是給代碼Review的人看的。因為我覺得讓別人給自己Review代碼,只提供一個ReviewBoard或diff文件,不是很好。

          在本次實踐中,我提供了一個時序圖,并在發出Review請求的時候,將該文檔作為附件也發送了出去。

          如果是用面向對象編程,我可能會提供一個類圖及一個類列表,在類圖中表述類之間的關系,在類列表中,描述一個每個類的功能及想法。

          3 總結

          以上是自己本次實踐中的文檔。個人覺得對自己的開發很有幫助,而且文檔的規模也不大,維護成本也不高。

          該文檔將客戶和需求人員,開發人員,測試人員以及代碼Review人員都涉及到了。

          最開始是從需求部分開發的。

          得到認可后, 又覺得既然功能明確了,可以嘗試讓自己站在一個測試者的角度看,該怎么測試, 于是有了需求測試用例相關部分。

          因為到這時候,文檔還是很小,所以我就把設計及設計的測試用例都放在一起了,作為自己使用的文檔。

          在編碼完成后,考慮到方便別人Review,又把時序圖加了上來。

          這就是我本次的文檔實踐。

          預約申請免費試聽課

          填寫下面表單即可預約申請免費試聽!怕錢不夠?可就業掙錢后再付學費! 怕學不會?助教全程陪讀,隨時解惑!擔心就業?一地學習,可全國推薦就業!

          上一篇:性能測試工具開發怎么做?
          下一篇:如何負責一個項目的質量保證工作?

          參加軟件測試培訓靠譜不?

          軟件測試培訓都學寫什么?

          軟件測試工程師需要我們掌握什么技術?

          學習軟件測試的優勢是什么

          • 掃碼領取資料

            回復關鍵字:視頻資料

            免費領取 達內課程視頻學習資料

          • 視頻學習QQ群

            添加QQ群:1143617948

            免費領取達內課程視頻學習資料

          Copyright ? 2021 Tedu.cn All Rights Reserved 京ICP備08000853號-56 京公網安備 11010802029508號 達內時代科技集團有限公司 版權所有

          選擇城市和中心
          黑龍江省

          吉林省

          河北省

          陜西省

          湖南省

          貴州省

          云南省

          廣西省

          海南省

          神马影院-战旗影院-首播影院-新视觉影院-在线观看中文字幕dvd播放 百度 好搜 搜狗
          <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <文本链> <文本链> <文本链> <文本链> <文本链> <文本链>