收獲在一次驚濤駭浪的“軟體測試”（二）

    上篇文章我們寫的都是在處理事情上的一些收獲，這篇文章我們主要說一下開發軟體方面的。

一：團隊開發。

    團隊開發中，對于人員和任務的配置設定是重中之重。對于人員管理，我覺得應該先小人後君子。把一切規範和獎罰

措施都在項目開始之前就制定好，并嚴格按照規範執行，防止項目拖延。每個人都按照自己的計劃去執行，而且每天

的晨會或者例會都要有它存在的意義，不能說每天都彙報，卻不統計任務的完成情況。做事和做人分開，隻要是關于

項目的，都嚴格按照規範執行，凡事對事不對人。而任務的配置設定，就需要根據人合理安排任務，通知要有任務清單，

這個任務安排給誰了，什麼時候完成，如何驗收都要寫清楚，同時必須要檢測，而不是配置設定出去就算完事了。争取每

個錯誤隻要出現就解決或者記錄。這次的開發過程出現了很多關于這方面的問題，比如：2.0出現的問題在這版裡面依

舊存在。管理端沒有很好的融合到考試系統裡面來等。

二：業務為王。

    這是大家都知道的一句話，可是知道是一回事，真正拿我們做的東西去給客戶使用是另一回事。我們所有的功能

都應該建立在對業務的了解和對客戶需求的充分分析上，而不是想當然的去做。有時候我們以為對的，以為人性化的

東西，客戶不一定會接受。尤其是針對不同的客戶需求時，更應該根據各種需求合理設計我們的軟體。不能為了某個

客戶的需求而忽略其他客戶的感受。

三：統一規範。

   每次開發之前都要将軟體使用，代碼規定等統一了，而且組長要做好檢查工作，這有會給後期開發省去很多不必

要的麻煩。比如：資料庫版本，靜态變量的使用，資料類型等。而且每次規範的變更都要通知到每位組員。這次我們

在這方面基本上撞的頭破血流了，希望大家引以為戒，後面會有專門的學術報告講這個。這些貌似不起眼的錯誤，會

給我們軟體的使用帶來毀滅性的打擊。

四：回報。

    單獨把它拿出來說，是因為這次這個系統中這部分基本上是空白。回報不僅是指客戶對我們的軟體提意見，還有

我們在設計軟體時，每一步的操作都要有記錄，每一次資料的變動都應該提示客戶哪些地方發生了變化，比如：導入

題庫，應該回報給使用者導入成功多少條資料，多少條沒有導入成功，沒有成功的是如何處理的。導入學生要跟基礎數

據庫比對，告訴客戶那些學生存在問題，和保證學生導入的準确性。同時，我們上面說的，任務布置出去以後也必須

有回報才算這個任務完成了。

五：軟體管理。

    所有需要我們手動記錄或者去資料庫操作的都應該可以在軟體背景可以實作。所有可能改變的地方，都應該可以

在背景靈活配置。這樣才能做出來靈活性和擴充性都俱佳的軟體。

六：權限管理。

    想做出一個多功能大型的軟體，權限管理必須做好。一個隻供三四人使用的軟體不需要權限管理。就像提高班随

着人數的增多，為了友善管理，各種委員會就會相應的誕生。軟體也一樣，要想發展壯大，就必須配置設定好權限。每個

角色都有隻屬于自己權限，隻能操作屬于自己的那部分。

    以上隻是這次考試過程中遇到或者想到的一部分内容，大家可能都知道這些，但是真正的做出來讓别人去用去評

價那将是另一個概念，我們應該把我們平時學習的東西和别人總結的都應用到平時的開發中去，拿别人撞的頭破血流

的經曆作為自己的經驗！這樣才能讓我們的軟體被更廣泛的認可。