本節書摘來自華章出版社《移動app測試實戰》一 書中的第1章，第1.3節，作者：邱鵬 陳吉 潘曉明，更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。
在一個較大型的項目中，通常運作的方式是按照子項目或者功能子產品來進行分工，每個功能子產品有具體對應的設計、産品、營運、開發和測試人員。結合實際的項目情況，如果功能較大可能上面一個角色有多個人一起參與，反之也可能一個人同時負責多個功能子產品。不管是哪種情況，實際項目在測試進行中，以上不同的角色，以及對應的各個團隊leader，甚至公司或部門管理層，都希望及時看到工作的進展，以及遇到的問題和風險。
而另一個方面，網際網路産品的測試周期都比較短，一個子產品的整個測試周期隻有幾天是非常常見的，使得我們不可能有大量的時間用在整理測試進度的報告本身。結合這兩種情況，我們需要考慮一個比較清晰簡潔的方式來反映出測試工作的進度，暴露出其中的問題讓大家盡快關注到，同時讓編寫這樣的進度報告的代價變得比較小，因為太多的文字工作是無法承受的。下面我們來看一下在實際的項目中我們用到的一些方式。
從大的方面，我們将測試報告分為兩類：
1）測試進度報告：在測試階段中間發出，告知測試工作的進度，發現的問題、風險，以及接下來的計劃。
這個報告發送的頻次依據具體的項目情況而定，對于比較重要的且時間比較短的項目，建議每天發出，讓相關人員可以非常及時地了解進展和風險。對于一些周期比較長的或者重要性的不高的項目，可以考慮隔天或者每周發送，基于大家的讨論來約定。
2）測試完成報告：标志測試工作的結束，會給出對應的測試結果和結論，包含是否達到可釋出的标準以及還有哪些遺留問題。這個報告一般在整個測試工作完成之後發出，針對某一個具體的子產品或者整個的測試項目。
下面我們來看看這兩種測試報告的具體内容。
1.3.1 測試進度報告
首先來看下測試進度報告，我們拿一個具體的郵件報告的例子來看，如圖1-5所示。
從以上報告我們可以看出，主要的内容非常簡潔，符合我們前面說的目标。主要側重以下幾個方面：
風險和問題：基于要事先說的原則，在郵件的一開始就把目前遇到的可能影響項目品質或者進度的問題列出來。如果是比較緊急的，可以标紅或者加粗來引起收件人的注意。
測試工作進度：這個可以給出一個大概的百分比，可以用測試用例的執行情況，也可以基于測試人員自己的工作估計。
目前bug統計：一個簡單的bug統計，讓大家可以看到bug的總數和待處理的bug數量。
未關閉bug清單：讓大家可以比較直覺地看到待解決bug的情況，從标題上就有個基本的了解，以及對應的狀态、嚴重程度和相關的處理人。
以上測試進度報告的内容在項目實際運作過程中并不是嚴格限定的，相當于一個指導，大家可以基于項目的情況，補充項目的内容資訊。
比如我們常遇到以下幾種情況：
1）該項目包括多個子項目，每個子項目有獨立的進展情況，但是整體在一個進度報告裡面比較高效。
針對這種情況，可以在上面的“測試進度報告”裡面寫上各個子項目的進展情況，如表1-1所示。
2）專項測試進展。針對某個子產品的測試，除了基本的黑盒功能測試之前，可能還需要進行其他針對性的測試，我們稱之為專項測試，具體的專項測試内容和做法将在本書的後續章節展開讨論，這裡為了便于說明，隻簡單列舉部分測試類型，比如：相容性測試、流量測試、電量測試、弱網絡測試、代碼覆寫率測試。
針對不同類型的子產品，專項測試的開展情況可能不同，如果有相關的開展，建議也在測試進度報告中顯示出來。可以在上述簡單模闆的基礎上，補充類似下面的資訊：
【專項測試進展】
相容性測試：已完成android 2.3，4.0，以及3種不同分辨率的測試，整體進度40%
流量測試：已完成，無異常
電量測試：已完成，無異常
弱網絡測試：已完成，一個問題已送出bug，bug單号××××
代碼覆寫率測試：未完成
以上是單個項目的測試進展報告，為了便于全局了解整體的測試進度情況，可以将各個項目的進展彙總到一張表格中，如圖1-6所示。
在這個聚合的整體測試進度報告中，資訊已經被抽象，是以不像單個子產品的測試進度報告一樣可以看到比較細節的資訊。如果需要了解對應子產品的細節，需要檢視該子產品的測試人員發出的針對該子產品的測試進度報告。
當某個具體的功能子產品測試完成後，對應子產品的測試負責人會發出對應子產品的測試報告，發給相關的項目經理/設計/産品/開發/運維同僚，以及對應的團隊leader，标志着該功能通過了測試，可以進入釋出（或者灰階）階段。
圖1-7所示是一個測試完成報告的樣例。
實際中報告的具體資訊可以根據團隊項目管理的要求來做調整。在有專職項目經理來跟進功能和版本進度的情況下，通常項目經理會基于這樣的測試完成報告來認定該子產品的測試完成，常常也意味着該子產品研發工作的完成，是以在發出該報告前也需要将遺留問題都評審過，大家認定目前子產品品質達到了釋出标準。
以上是單個子產品的測試完成報告，對于整個app，通常android和ios等平台分開來看，因為對外釋出的機關是一個完整的app，是以也需要一個完整的測試完成報告來給出測試的結論。格式和上面類似，隻是測試範圍和遺留問題的羅列可能會多一些。
以上介紹的測試進度和測試完成報告，基本能滿足測試項目管理的需求，在日常的測試工作中保持資訊的及時同步。但是在資訊的完整性和效率上也有進一步提升的空間，主要展現在下面幾個方面：
1）以上報告裡面的資訊都是手工填寫的。上述報告的裡面的測試用例資訊，bug統計資訊和清單，以及對應的需求點等資訊，都是測試人員手工填寫到報告中的，這個會需要耗費一些時間，同時資訊的準确性有時也得不到保障。
2）一些時間次元的資訊丢失。按前面讨論的，測試進度報告是定期發出的，每次看到都是一封獨立的郵件，閱讀報告的人無法快速地了解到時間次元的資訊，比如：
該功能是什麼時候提測的，有沒有提測延期？
測試和預期有沒有延期，偏差的原因。
測試的耗時情況。
這些資訊也可以手工填寫，但是非常容易因為了解不一緻而出錯。
3）溝通的成本。如果需要報告格式的變更，需要很多的溝通成本。
針對這樣的一些問題，在一些比較成熟的測試團隊，特别是一些有較強開發能力的測試團隊，通常會借助自動化的系統來标準化測試進度的填寫，以及相關資訊的自動抽取，測試人員隻需要觸發相關的報告，并填寫少量的主觀資訊，就可以發出标準化的報告。
圖1-8、圖 1-9、圖1-10是單個子產品的測試報告樣例。
以上報告的大部分資訊都來自于功能測試平台，測試人員隻需填寫測試報告總結和釋出延期原因等主觀資訊，以及針對一些選項做選擇。整個模闆是标準化且可定制的。
如果要做到上面的系統化方法，除了測試團隊有一定的成熟度和開發能力之外，其實對整個研發組織的項目管理也提出了一定的要求。上面功能測試平台的資訊粗略地說需要來自三個方面的系統：
版本需求管理平台。将産品經理或者研發自身提出的各個功能疊代，錄入到對應的系統管理起來，需求評審/開發/走查/轉測試/測試完成等各個狀态都可以在系統中扭轉，各個對應的研發角色可以參與進來操作，并完善相關的資訊。這個比excel和郵件的方式來管理需求要友善和高效很多。
測試用例管理平台。可以友善地進行用例的錄入和管理，以及支援評審等功能。
缺陷管理平台。缺陷的建立、狀态的扭轉、已經資料的統計等功能。
以上三個平台都需要提供相關的資料接口，允許測試平台等外部程式拉取對應的資訊來彙總。
而更近一步，如果平台上有了每個子產品的上述基本資訊，自然就會想到可以借助平台來自動化地聚合整個項目組，或者整個大的app版本所有子產品的測試進展和完成情況。這樣就可以非常具體地看到各種不同次元的測試項目的資訊，對于測試團隊的負責人來說，對整個測試情況也會有比較好的把握，也能及時發現項目的風險和問題，同時也提到了非常多的度量角度，對項目和團隊管理上也是很好的參考。