我要作的是一個基於SSH的門票售賣系統,在系統中常見的質量屬性有:可用性、可修改性、性能、安全性、易用性。安全
可用性方面:性能
可用性是指系統正常運行時間的比例,是經過兩次故障之間的時間長度或在系統崩潰狀況下可以恢復正常運行的速度來衡量的。實現可用性的戰術分爲三類:錯誤檢測(用來檢測故障的健康監視)、錯誤恢復(檢測到故障時的恢復)、錯誤預防(阻止錯誤演變爲故障)。用於檢測錯誤的3個戰術是: 信號/響應、心跳、異常。用於錯誤恢復的戰術有7種:表決、主動冗餘、被動冗餘、備件、shadow操做、狀態再同步、檢查點/回滾。用於錯誤預防的戰術有3種:從服務中刪除、事務、進程監視器。學習
修改用戶密碼方面,當用戶建立完帳號時,會建立初始密碼,但以後可能認爲密碼不安全,從而想要修改密碼,當修改密碼時,須要確認密碼,當密碼和確認的密碼不同是時,則不能完成對密碼的修改。因此當用戶輸入的密碼和第二個確認密碼不一樣時,則馬上返回修改密碼界面進行從新修改,而不會直接把第一個密碼保存起來;還有當買票時,剩餘的票不足夠了用戶所買的狀況;管理員刪除用戶時,若是用戶有購票信息,則先刪除全部該用戶的購票信息,在刪除用戶信息。測試
實例一spa
刺激源設計 |
刺激接口 |
製品進程 |
環境事件 |
響應事務 |
響應度量 |
用戶 |
輸入的密碼和確認密碼不同 |
系統 |
正常狀態 |
從新返回修改密碼界面。 |
1s以內 |
實例二
刺激源 |
刺激 |
製品 |
環境 |
響應 |
響應度量 |
用戶 |
須要購買的票比剩餘的票多 |
系統 |
正常狀態 |
返回到票的數量顯示界面,而且提示出票的數量不足 |
在1s以內 |
實例三
刺激源 |
刺激 |
製品 |
環境 |
響應 |
響應度量 |
管理員 |
刪除用戶信息時,該用戶有購票記錄。 |
系統 |
正常狀態 |
先刪除他的購票記錄,以後再刪除用戶信息 |
在1s以內 |
可修改性方面:
關注的兩個方面:兩個關注點:能夠修改什麼?什麼時候以及誰進行修改。可修改性的戰術有:局部化修改(減小由某個變動直接影響的模塊的數量);防止連鎖反應(限制對局部化的模塊的修改) ;推遲綁定時間(控制部署時間和成本)。
用戶或着管理員修改本身密碼方面,在不影響別人密碼的前提下,在5s左右完成;設計人員修改用戶界面用戶購買的票的詳細信息的界面,在不影響其餘功能的前提下修改代碼,要求在4小時內完成代碼修改和測試,不產生有反作用的變;最終用戶想要增長票的屬性,在不影響其餘功能的前提下,修改代碼並進行測試。
實例一
刺激源 |
刺激 |
製品 |
環境 |
響應 |
響應度量 |
管理員或用戶 |
修改密碼 |
系統 |
正常狀態 |
查找改用戶或管理員的密碼,而且修改爲新的密碼 |
在5s以內 |
實例二
刺激源 |
刺激 |
製品 |
環境 |
響應 |
響應度量 |
開發人員 |
但願修改用戶購票詳情界面 |
系統 |
設計時 |
修改並驗證後,沒有反作用的影響 |
在4小時以內 |
實例三
刺激源 |
刺激 |
製品 |
環境 |
響應 |
響應度量 |
最終用戶 |
增長票的種類 |
系統 |
設計時 |
修改並驗證後,沒有反作用的影響 |
在3小時以內 |
性能方面:
指系統的響應能力----即對外部刺激(事件)作出反應時所須要的時間或在某段時間內所處理的事件個數。
20人同時登錄進行買票等操做,查看系統是否響應正常。
實例一
刺激源 |
刺激 |
製品 |
環境 |
響應 |
響應度量 |
20人 |
試圖同時登錄系統 |
系統 |
正常運行 |
用戶的操做被處理 |
平均響應時間5秒 |
24小時每隔一個小時隨機登錄一次,參看系統是否登錄成功。
實例二
刺激源 |
刺激 |
製品 |
環境 |
響應 |
響應度量 |
用戶 |
沒個一個小時隨機登錄一次系統 |
系統 |
正常運行 |
用戶的操做正常被處理 |
平均響應時間3秒 |
安全性方面:
安全性是衡量系統在向合法用戶正常提供服務的狀況下,阻止非受權使用的能力。
在售票管理系統中。管理員不能修改用戶的基本信息以及用戶的購票信息;用戶不能查看別人的購票信息以及進行操做。
實例一:
刺激源 |
刺激 |
製品 |
環境 |
響應 |
響應度量 |
管理員 |
修改用戶信息或者購票信息 |
系統 |
正常運行 |
操做被禁止 |
100%禁止操做 |
實例二:
刺激源 |
刺激 |
製品 |
環境 |
響應 |
響應度量 |
用戶 |
查看其餘用戶信息 |
系統 |
正常運行 |
操做被禁止 |
100%禁止操做 |
易用性方面:
關注的是對用戶來講完成某個指望任務的難易程度,分爲:有效性、錯誤避免及錯誤處理、用戶自信和滿意度、可學習性。有用性和易用性很類似,可用性是指是否可使用,而易用性是指是否方便使用。易用性運行時戰術:一旦系統執行,就能夠經過爲用戶提供關於系統正在作什麼的反饋,以及爲用戶提供發出基於易用性命令的能力來加強易用性;易用性設計時戰術:在測試過程當中,一般會頻繁修改用戶接口。也就是說,易用性工程師將爲開發人員提供對當前用戶接口設計的修改。
用戶註冊後會直接進入系統,不須要再輸入帳號和密碼。
實例一:
刺激源 |
刺激 |
製品 |
環境 |
響應 |
響應度量 |
用戶 |
用戶註冊進入系統 |
系統 |
正常運行 |
註冊成功後,進入系統 |
響應時間少於2s |
當用戶登錄後,買票時,會自動顯示用戶的帳號和姓名,當選完數量後,自動顯示總價。
實例二:
刺激源 |
刺激 |
製品 |
環境 |
響應 |
響應度量 |
用戶 |
用戶買票 |
系統 |
正常運行 |
顯示總價 |
響應時間少於2s |
以上是個人項目的質量屬性以及質量屬性場景,可能個人分析或許不是很完整,可是我會盡可能把個人項目作得完整。一個項目的質量屬性影響着項目的好壞,因此要想作好項目,必須先分析好本身的質量屬性。