改善網(wǎng)絡的可擴展型
實現(xiàn)快速收斂
OSPF路由器的類型
內(nèi)部路由器：所有接口同屬于一個區(qū)域
區(qū)域邊界路由器（ABR）：連接一個/多個區(qū)域到骨干區(qū)域
自治系統(tǒng)邊界路由器（ASBR）：連接OSPF域和其他AS
區(qū)域的類型：骨干區(qū)域（Area 0）、標準區(qū)域、末梢區(qū)域、完全末梢區(qū)域、非純末梢區(qū)域等
鏈路狀態(tài)通告
常見的LSA有六種類型，分別是LSA1、LSA2、LSA3、LSA4、LSA5和LSA7
ASBR會通過自己的LSA1中有標識著自己是ASBR的字段，當ASBR同區(qū)域的ABR收到后，會為自己所在的除已知ASBR信息區(qū)域外的所有區(qū)域生成LSA4，用來通告ASBR信息。 ABR的LSA1中亦有一個標識自己是ABR的字段。
所有LSA1、LSA2、LSA3信息在Area0的ABR路由器上匯總成新的LSA3，再通告給其他Area。
路由重分發(fā)
將其他協(xié)議或靜態(tài)等路由通過ASBR路由器通告到OSPF中去。
命令：redistribute
配置路由路由重分發(fā)
R5(config-router)#redistribute protocol [metric metric-value] [metric-type type-value] [subnets]
protocol：進行路由重發(fā)的源路由協(xié)議，如：bgp、eqp、isis、ospf [process-id（進程）]、staic（靜態(tài)）、connect（直連）、rip
metric：指定路由的度量值
metric-type：重分發(fā)的路由類型，1或2，即E1和E2
subnets：與其子網(wǎng)一起宣告，即關閉子網(wǎng)匯總
RIP重分發(fā)至OSPF（度量值默認為20，類型默認為E2）
R1(config-router)#redistribute rip subnets
將OSPF重分發(fā)至到RIP
R1(config-router)#redistribute ospf 110 metric 10
110：ospf協(xié)議進程ID
10：默認度量值
靜態(tài)路由重分發(fā)
R5(config-router)#redistribute static subnets
默認路由重分發(fā)
R5(config-router)#default-information originate [always]
always：直接重分發(fā)路由，ASBR可以不配置默認路由
路由表中的路由類型
O IA ：OSPF的區(qū)域間路由
O E2：此路由的度量值默認為20，且在域內(nèi)/外不累加，恒為20
O E2：此路由的度量值默認為20，且在域外不累加，域內(nèi)累加
（將一個協(xié)議重分發(fā)到另一個協(xié)議中，域外都不累加）
末梢區(qū)域和完全末梢區(qū)域
滿足以下4個條件的區(qū)域
只有一個默認路由作為其區(qū)域的出口
區(qū)域不能作為虛鏈路的穿越區(qū)域
Stub區(qū)域里無自治系統(tǒng)邊界路由器ASBR
不是骨干區(qū)域Area 0
1、末梢區(qū)域（Stub Area）
沒有LSA4、LSA5、LSA7通告，將重分發(fā)的路由信息匯聚成一條默認路由
配置命令
R1(config-router)#area area-id stub
2、完全末梢區(qū)域（Totally Stubby Area）
除一條LSA3的默認路由通告外，沒有LSA3、LSA4、LSA5、LSA7通告，將重分發(fā)的路由信息和LSA3路由信息匯聚成一條默認路由
配置命令
R1(config-router)#area area-id stub no-summary
（在整個區(qū)域的所有路由器中都要配置）
配置非純末梢區(qū)域（NSSA）
配置NSSA區(qū)域
R1(config-router)#area area-id nssa [no-summary]
配置了NSSA區(qū)域后，ASBR所在OSPF區(qū)域內(nèi)的LSA5通告信息被LSA7替代了LSA5，此區(qū)域本來的ABR將LSA7轉(zhuǎn)換成了LSA5，此ABR兼任了ASBR。no-summary 將其他域內(nèi)的路由信息（LSA3）匯總成一條默認路由。
路由匯總
外部匯總
R1(config-router)#area 2 range ip-address mask
內(nèi)部匯總
R4(config-router)#summary-address ip-address mask
查看OSPF協(xié)議配置信息
show ip protocols
查看OSPF配置信息
show ip ospf
查看LSDB內(nèi)的所有LSA數(shù)據(jù)信息
show ip ospf database
查看接口上OSPF配置的信息
show ip ospf interface
查看OSPF鄰居和鄰接關系
show ip ospf neighbor [detail] // detail：詳細查看
查看路由器“鄰接”的整個過程
debug ip ospf adj
查看每個OSPF數(shù)據(jù)包的信息
debug ip ospf packet
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
環(huán)境配置
項目使用SSH架構(gòu)，現(xiàn)在要添加Spring事務管理功能，針對當前環(huán)境，只需要添加Spring2.0AOP類庫即可。添加方法：
點擊項目右鍵->BuildPath->Addlibrarys:
打開AddLibraries對話框，然后選定MyEclipseLibraries：
點擊Next，找到Spring2.0aopLibraries并勾選上，點擊finsh即可。
如果在項目里面能看到下面的庫文件，說明已經(jīng)安裝成功。
事務配置
首先在/WEB-INF/applicationContext.xml添加以下內(nèi)容：
<!--配置事務管理器--> <beanid="transactionManager"class="org.springframework.orm.hibernate3.HibernateTransactionManager"> <propertyname="sessionFactory"> <refbean="mySessionFactory"/> </property> </bean> |
注：這是作為公共使用的事務管理器Bean。這個會是事先配置好的，不需各個模塊各自去配。
下面就開始配置各個模塊所必須的部分，在各自的applicationContext-XXX-beans.xml配置的對于事務管理的詳細信息。
首先就是配置事務的傳播特性，如下：
<!--配置事務傳播特性--> <tx:adviceid="TestAdvice"transaction-manager="transactionManager"> <tx:attributes> <tx:methodname="save*"propagation="REQUIRED"/> <tx:methodname="del*"propagation="REQUIRED"/> <tx:methodname="update*"propagation="REQUIRED"/> <tx:methodname="add*"propagation="REQUIRED"/> <tx:methodname="find*"propagation="REQUIRED"/> <tx:methodname="get*"propagation="REQUIRED"/> <tx:methodname="apply*"propagation="REQUIRED"/> </tx:attributes> </tx:advice> <!--配置參與事務的類--> <aop:config> <aop:pointcutid="allTestServiceMethod"expression="execution(*com.test.testAda.test.model.service.*.*(..))"/> <aop:advisorpointcut-ref="allTestServiceMethod"advice-ref="TestAdvice"/> </aop:config> |
需要注意的地方:
（1）advice（建議）的命名：由于每個模塊都會有自己的Advice，所以在命名上需要作出規(guī)范，初步的構(gòu)想就是模塊名+Advice（只是一種命名規(guī)范）。
（2）tx:attribute標簽所配置的是作為事務的方法的命名類型。
如<tx:methodname="save*"propagation="REQUIRED"/>
其中*為通配符，即代表以save為開頭的所有方法，即表示符合此命名規(guī)則的方法作為一個事務。
propagation="REQUIRED"代表支持當前事務，如果當前沒有事務，就新建一個事務。這是最常見的選擇。
（3）aop:pointcut標簽配置參與事務的類，由于是在Service中進行數(shù)據(jù)庫業(yè)務操作，配的應該是包含那些作為事務的方法的Service類。
首先應該特別注意的是id的命名，同樣由于每個模塊都有自己事務切面，所以我覺得初步的命名規(guī)則因為all+模塊名+ServiceMethod。而且每個模塊之間不同之處還在于以下一句：
expression="execution(*com.test.testAda.test.model.service.*.*(..))"
其中第一個*代表返回值，第二*代表service下子包，第三個*代表方法名，“（..）”代表方法參數(shù)。
（4）aop:advisor標簽就是把上面我們所配置的事務管理兩部分屬性整合起來作為整個事務管理。
圖解：
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
1. 建立project
django-admin.py startproject newproject
完成上個步驟后，可發(fā)現(xiàn)在newproject文件夾下生成了：一個名為newproject的文件夾，一個manage.py文件。
newproject文件夾上又包含了4個文件：
__init__.py
setting.py
urls.py
wsgi.py
至此project建立完畢！
2. 修改文件
#vim urls.py from django.conf.urls.defaults import patterns, include, url # Uncomment the next two lines to enable the admin: from django.contrib import admin admin.autodiscover() urlpatterns = patterns('', # Examples: # url(r'^$', 'csvt01.views.home', name='home'), # url(r'^csvt01/', include('csvt01.foo.urls')), # Uncomment the admin/doc line below to enable admin documentation: # url(r'^admin/doc/', include('django.contrib.admindocs.urls')), # Uncomment the next line to enable the admin: url(r'^admin/', include(admin.site.urls)), ) |
去掉標紅位置的#
#vim setting
INSTALLED_APPS中去掉‘django.contrib.admin’這行的注釋
3.創(chuàng)建數(shù)據(jù)庫表
#python manage.py syncdb
按提示輸入賬號密碼即可
#python manage.py runserver
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
1.要提高質(zhì)量的bug：
——》多次重現(xiàn)之后，確定為bug
——》用專業(yè)的屬于描述bug
——》標題簡潔清晰，概括準確（因為bug不只是在卡法在看，主管和做bug統(tǒng)計時都要關注，所以標題很重要。例如：在XX情景下，發(fā)生了OO狀況，注意場景描述與操作步驟描述的區(qū)別）
2. 如何判斷bug是不是小bug？
——》從“用戶體驗”上看對用戶的影響，來判斷是否為小bug。在提交bug時，應在bug描述中寫明“影響”
3.提交bug中的附件
——》1.測試數(shù)據(jù)（excel,sql語句）
——》2.如果是自己上傳的圖片，要注意文件的命名規(guī)范 ： 圖序列/含義
——》3.日志信息：截取關鍵部分
4.bug的嚴重程度和優(yōu)先級如何判定？
——》嚴重程度是從 “用戶角度”來說的。
——》優(yōu)先級是從“
測試人員角度”來說的。 優(yōu)先級高的bug可能并不嚴重，但是阻礙了測試人員接下來的測試，則提高優(yōu)先級，讓開發(fā)先fixed掉這些bug
5.bug的深度如何判斷？bug深度有什么作用？
——》bug深度 是為了解決某些開發(fā)人員代碼質(zhì)量差的問題。每隔一段時間統(tǒng)計一下“很容易發(fā)現(xiàn)” 的bug數(shù)量，可以看出一個開發(fā)人員在這段時間的代碼質(zhì)量和
工作狀態(tài)，便于管理人員協(xié)助調(diào)整。“很容易發(fā)現(xiàn)”的bug多為功能邏輯上的問題，是一般的開發(fā)人員不會犯的菜鳥級問題。而對于建議性bug來說，一般都判定為“很難發(fā)現(xiàn)”，因為此類bug含有測試人員的主觀因素在。
6.如何通過分析bug了解項目質(zhì)量：
1。根據(jù)活動bug趨勢圖 。（活動bug：沒有進入最終狀態(tài)之前的bug都是活動bug）
2.每日新增bug趨勢圖
3.開發(fā)未關閉的bug個數(shù)
7.開發(fā)fixed掉一個bug，但是在修改過程中引入了另外的bug，這種情況下是應該重新提bug還是在原來bug上reopen?
——》重新提bug， 要保證bug的單一性。
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
0、前言
在軟件設計開發(fā)中，代碼的設計都體現(xiàn)在：子系統(tǒng)與子系統(tǒng)、模塊與模塊、函數(shù)與函數(shù)之間的關系，設計越糟糕的軟件，維護成本越高，質(zhì)量也往往難以達標和稱贊。
好的設計必定是：層次關系簡潔、清晰、易維護和擴展的。
不會研究太高深的設計，只總結(jié)出一些常見的代碼設計缺陷，這些設計缺陷如能很好的解決和避免，相信代碼能力（編寫、設計、評審、重構(gòu)）能提高一個檔次。
主要介紹下面15個常見代碼設計缺陷：
1、復雜函數(shù)（Blob Operation）
缺陷特征：指的是代碼行多，分支嵌套深，變量多，參數(shù)多，注釋多，復雜度高等特征的函數(shù)。
缺陷影響：函數(shù)不易理解和維護，代碼重復、冗余。
解決方法：新開發(fā)代碼時，函數(shù)都是越寫越復雜的，應該要有意識地、積極地去分解提煉成小函數(shù)或獨立功能的函數(shù)，甚至當感覺需要以注釋來說明點什么的時候，這時其實就應該獨立成一個函數(shù)。函數(shù)建議值：代碼行24，if語嵌套深度6，圈復雜度10，功能應該單一。
2、數(shù)據(jù)泥團（Data Clumps）
缺陷特征：函數(shù)的參數(shù)多且參數(shù)列表相似，反復調(diào)用相同的參數(shù)列表。
缺陷影響：大量重復，影響編譯的效率；參數(shù)多，很難理解和調(diào)用。
解決方法：參數(shù)列表應該封裝成結(jié)構(gòu)。建議值：函數(shù)參數(shù)平均為2，避免5個以上。
偽碼示例：GetDate(int year,int month,int day,int time) -> GetDate(struct DateRange)。
3、不必要的耦合（Unnecessary Coupling）
缺陷特征：包含某個頭文件，但是卻沒有使用頭文件中任何內(nèi)容。
缺陷影響：編譯鏈接速度慢，耦合度高，頭文件錯誤包含，如包含某個頭文件卻沒有使用里面的內(nèi)容，某個頭文件卻依賴某個dll，則會引起不必要的dll依賴和錯誤。
解決方法：頭文件不能亂包含，100%確認每個包含的頭文件使用情況，刪除不必要包含的頭文件。
4、過度耦合（Intensiue Coupling）
缺陷特征：一個函數(shù)調(diào)用大量其它模塊的函數(shù)，卻調(diào)用很少本模塊的函數(shù)。
缺陷影響：一個函數(shù)與多個函數(shù)（這些函數(shù)屬于少數(shù)一兩個類）聯(lián)系過于緊密；一個類提供了很多函數(shù)給外部某個函數(shù)調(diào)用；耦合度高，類不夠抽象。
解決方法：識別內(nèi)、外部模塊函數(shù)，外部模塊要足夠抽象調(diào)用。
5、循環(huán)依賴（Cyclic Dependencies）
缺陷特征：多個子系統(tǒng)處于一個環(huán)狀互相依賴關系里面；函數(shù)的調(diào)用關系混亂、循環(huán)；文件直接或間接交叉引用。
缺陷影響：不易理解和維護，編譯慢，關系混亂，重用困難。
解決方法：多文件或系統(tǒng)間要劃分清楚結(jié)構(gòu)、層次關系，應做到無環(huán)依賴。
偽碼示例：循環(huán)包含頭文件，file A包含file B,而file B又包含了file A。
6、依戀情節(jié)（Feature Envy）
缺陷特征：函數(shù)很少訪問自己模塊數(shù)據(jù)，總是訪問外部模塊數(shù)據(jù)；訪問自己模塊少，訪問其它模塊多；數(shù)據(jù)和操作不在同一模塊；對其它類的數(shù)據(jù)比較感興趣。
缺陷影響：耦合度高。
解決方法：同一模塊的數(shù)據(jù)和操作應該放在一起。
7、重復代碼（Repeat code）
缺陷特征：不同模塊或文件間有類似或重復功能的類；不同類間有類似或重復功能的函數(shù)；同一父類的子類間存在相似或重復功能的代碼。
缺陷影響：代碼膨脹混亂，不易維護，本來維護一處代碼由于重復代碼要維護多處。
解決方法：提煉重復代碼。如工具函數(shù)封裝成工具類，通用功能封裝成公共庫。
8、不穩(wěn)定依賴（Unstable Dependencies）
缺陷特征：一個子系統(tǒng)或模塊依賴于另一個比它更不穩(wěn)定的子系統(tǒng)或模塊，如上層模塊依賴于不穩(wěn)定的底層模塊，上層模塊肯定會問題不斷。
缺陷影響：不獨立，不穩(wěn)定，牽一發(fā)而動全身。
解決方法：當有依賴關系時，一定要先保證被依賴子系統(tǒng)或模塊的穩(wěn)定性。至少應保證不穩(wěn)定的子系統(tǒng)要依賴穩(wěn)定的子系統(tǒng)。
9、未利用的接口（Underutiliaed Interface）
缺陷特征：設計并實現(xiàn)了很多接口，大部分未使用或只在內(nèi)部使用；定義了很多全局變量，大部分其它模塊未使用。
缺陷影響：冗余，設計過度，暴露可視化。
解決方法：按需設計接口，不需要對外公開的變量和函數(shù)應該私有化。
10、紊亂類（Schizophrenic Class）
缺陷特征：一個類實現(xiàn)了多個不同的功能，如界面類又處理了業(yè)務相關的功能。
缺陷影響：不易理解，耦合度高，公共方法太多。
解決方法：對多個功能進行拆分。
11、復雜類（Blob Class）
缺陷特征：規(guī)模非常龐大、復雜性高的類，常常包含多個復雜函數(shù)，有多重功能。
缺陷影響：圈復雜度高，內(nèi)聚性差，耦合度高，不易看懂和維護。
解決方法：解決復雜函數(shù)，結(jié)構(gòu)要清晰，類功能應該單一。建議值：類行數(shù)應在2000以內(nèi)。
12、全能類（God Class）
缺陷特征：一個類集中了多個不相關類的功能；一個類操作其它模塊數(shù)據(jù)太多；大而復雜。
缺陷影響：破壞了類的封裝性，耦合度高，內(nèi)聚性差，不易維護。
解決方法：多個功能不相關的類應該分別封裝成不同的類，適當搬移函數(shù)，解決復雜函數(shù)問題。
13、歪曲層次（Distorted Hierarchy）
缺陷特征：類的繼承關系比較深。
缺陷影響：復雜度高，不易維護。
解決方法：類的繼承層次結(jié)構(gòu)不應該超過6。
14、數(shù)據(jù)類（Data Class）
缺陷特征：提供許多公共屬性和函數(shù)，供很多其它類來操作，自己卻很少操作。
缺陷影響：非面向?qū)ο螅狈Ψ庋b性，不易維護。
解決方法：封裝性。
15、破壞繼承（Tradition Breaker）
缺陷特征：派生類幾乎沒有使用任何繼承父類的功能，卻增加了全新的功能。
缺陷影響：非繼承關系卻繼承，難理解，不易維護。
解決方法：理清類與類之間的繼承關系，不適合繼承關系的類應該單獨分開。
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
什么時候已經(jīng)測夠了, 可以停止了, 這個問題是QA常常會被問到的, 也是其中一個不容易回答的問題. 可是這也是你無法逃避的問題, 因為每次product 要release時, 你就要面對一次, 即使沒有人問你, 你自己也會問自己是不是可以出貨了.
以下是常見的的criteria
1. All the high priority bugs are fixed.
- 這通常是最重要的, 如果重要的bug沒解, 是不敢出貨的
- 不過通常僅限于重要的bug, 至于所有bug都要解掉這件事, 好像不是每個人都愿意買單的. 所以這里會有些落差存在, 需要事先和manager and RD溝通, 否則最后會沒有共識.
2. The rate at which bugs are found is too small.
- 通常這是要看是否bug submission ratio是否下降, 也就是看是否有收斂的跡象. 如果還是在向上發(fā)展, 當然是無法結(jié)束.
- 即使現(xiàn)在bug已經(jīng)解完, 并且目前沒有發(fā)現(xiàn)新bug, 但是若是目前submission ratio值是很高, 也不可能瞬間忽然降成0. 所以這通常意味著, 其實受測系統(tǒng)里面還有很多潛藏的bug, 只是目前還沒被抓出來. 所以還是要降低到某個程度才是比較save的狀況.
3. The testing budget is exhausted.
4. The project duration is completed.
時間了也是個無可奈何的指標, 這有可能時當初schedule就有問題, 或是測試規(guī)劃的有問題. 導致時間不夠使用.
5. The risk in the project is under acceptable limit.
如果risk很低, 是project可以接受的范圍當然是無所謂啦!! Manager說了算!! 呵呵~~~
其實測試是否可以停止,是否足夠, 這要看你是否收及足夠的information. 畢竟測試是個information-gethering的流程, 如果你有足夠的信息, 讓你可以掌握目前project質(zhì)量的狀態(tài), 你自然可以很清楚知道目前測試是否已經(jīng)夠了, 可以結(jié)束了.
所以當你不知道是否測試可以結(jié)束時, 先問問自己你是否掌握項目的狀況. 如果不知道, 當然是回答不了啦!!
Reference
1. When should Testing stop?
http://creativetesters678.blogspot.com/2008/07/when-should-testing-stop.html
2. Chapter 8 Manaing the Testing Project, Lesson Learned in Software Testing.
Lesson 185 "Enough testing" mean "enough informaiton for my clients to make good decisions"
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
本文來自于
Rational Edge：
軟件開發(fā)組織執(zhí)行SEI的能力成熟度模型(CMM)可能會由于在 Rational 統(tǒng)一過程或RUP中缺乏一個軟件質(zhì)量保證(SQA)
工作流而失敗。本文描述了一個虛擬的 SQA 工作流，其源自于 Leslee Probasco 的RUP的十點要素。
存在有九個RUP工作流程，包括了需求、
項目管理、配置 & 變更管理，甚至還有業(yè)務建模——但是沒有一個是用于軟件質(zhì)量保證(SQA)的。這種明顯的疏忽對尋求SEI的軟件成熟度模型(CMM)的項目和組織是非常棘手的1，因為SQA的關鍵過程域(KPA)承載了成熟度模型的重要工作。自從有了
需求管理的KPA，其可以精細地映射到Rational 統(tǒng)一過程?或RUP?的需求工作流，還有項目管理(包括計劃和監(jiān)控)和
配置管理的關鍵過程域同樣分別精細地映射到RUP的項目管理以及配置和變更管理的工作流，難道只是對SQA沒有嗎?
我開始回答這個問題，并且沿著這條路揭示了CMM以及RUP實質(zhì)的SQA工作流中的質(zhì)量的真正含義。
SQA和CMM
軟件工程協(xié)會(SEI)將軟件質(zhì)量保證設置為CMM的基礎級別2。他們也將所有其它關鍵過程域的驗證和確認放在了質(zhì)量保證中。此外，CMM反復強調(diào)高級管理人員必須“保護個人履行SQA責任”，因為這有可能會給發(fā)現(xiàn)不一致問題的職員帶來管理上的問題。如此強調(diào) SQA活動和需求，為什么沒有一個SQA工作流，以及更重要的是在RUP中沒有一個SQA角色呢?一個SQA工作流會提供活動，還有工件，以及在其它RUP流程里提供個人執(zhí)行SQA的各自的檢查點。
虛擬的SQA工作流
為了解決這個迷惑，我尋找什么是已經(jīng)被證實了的RUP里有效解決問題的實踐。RUP是通過軟件工程過程權(quán)威(SEPA)進行質(zhì)量保證--盡管理論上是SQA，這是一個組的職責，而不是一個個體的角色。我做了一個練習，創(chuàng)建了RUP的一個視圖，以滿足SQA角色的需要，如同在CMM中所確定的那樣。我特別實行了Leslee Probasco在“RUP的十點要素--一個有效開發(fā)過程的精髓”中所描述的建議，3來創(chuàng)建一個真實的SQA工作流。在她的論文(在此以后用RUP10來指代)，Probasco推薦形成一個有標簽的筆記本4，每個標簽代表每個要素(V-PRI-BAPE-CU)，用來管理一個項目的基本元素。所以我創(chuàng)建了一個這樣的筆記本，每個標簽包括了RUP的必要工件描述，復制了相關活動以產(chǎn)生RUP已經(jīng)定義的元素和所有的檢查點，還有個人記錄和元素以支持各自的要素。
例如，對于必要元素 #1，遠景(Vision)，我插入了遠景工件的副本，還有RUP中用于產(chǎn)生遠景的三個活動：開發(fā)遠景，管理依賴關系，以及評估概念構(gòu)架的生存能力。我也包括了遠景和涉眾請求檢查點的一個副本。接著我執(zhí)行了這些活動，將結(jié)論文檔化，并且正如Probasco建議的那樣，我產(chǎn)生了很多記錄。5在我對RUP和CMM有了更多認識時，我增加了更多的工件、活動、檢查點以及指南到相應的標簽中。
遠景
遠景的開發(fā)包括了很多的便箋，因為眾多的遠景都會成為想法。遠景必須有效地針對涉眾所面對的問題。SQA工程師既不是一個RUP角色，也沒有一個所描述活動和定義工件的工作流視圖。為了更好地理解我的涉眾-SQA工程師的需要，我借用了Alan Cooper的The Inmates Are Running the Asylum及其開發(fā)“角色”的實踐。6我的SQA工程師角色是一位名叫Ginger的女性。她在RUP和CMM的訓練方面屬于中級水平的工程師。在對分配給她的項目上涉及到的過程不一致發(fā)出錯誤警告上，她并不是資歷較淺的，但是在期望她挑戰(zhàn)那些擁有更多過程或領域?qū)ｉT知識上也并不是經(jīng)驗豐富的。
Cooper 這樣形容“消極角色”：某些人，對于他們，過程不是在被構(gòu)建，而是需要更好地理解過程需求。這些消極的角色代表了30多個的RUP角色，這些角色是Ginger必須接口的，因為她提供了對產(chǎn)生的工件產(chǎn)品和執(zhí)行的活動的客觀評審。這些個人在軟件開發(fā)實踐方面接受了更細致的訓練和練習。Ginger不在項目中，并且沒有涉及到所有的項目活動，因此對她來說，很容易遺漏或誤解一些事情。當 Ginger足夠成熟來理解她的個人職責時，她被期望知道在什么時間和執(zhí)行哪些驗證和確認活動，她不被期望能夠強制過程一致性(就是SEPA)。進一步的，與CMM一致的是，當她嘗試“逐步升高項目外部的偏差”到可執(zhí)行級時，她被保護以免于可能的“敵對人員行為”。
計劃
對于Ginger，計劃就是遵循RUP10，并產(chǎn)生一個虛擬的SQA工作流程。過程規(guī)模度量的搜集、分析和報告是Gingre必需進行的工作。她知道在RUP里有多少工件、活動、角色評審和評估的步驟，因此能夠更好地計劃和安排她的任務時間表。在沖突解決領域，她知道工件的所有人和活動的產(chǎn)生者不是相同的角色這種情況，她或許能通過確保這些工件的檢查點或規(guī)格特征在每個團隊成員間達成一致。這些在RUP10素材筆記本里的表述幫助Ginger知道了什么、在哪里以及如何開始她的質(zhì)量審核。她的工作流程將會遵循RUP過程相關的素材和圖表，作為RUP的工件和活動集合。我也會進一步使用RUP10來配置一個過程，集中在質(zhì)量和使用的規(guī)模度量上(通過階段和角色來統(tǒng)計工件和活動)。
風險
對Ginger而言，計算風險意味著將場景腳本化。成功和可選場景揭示了在項目中沖突可能出現(xiàn)的地方。CMM通過重復使得履行SQA角色的個人需要得到保護這點非常清晰。因此，虛擬的SQA工作流程需要揭示潛在的危險領域。如果Ginger的老板是項目經(jīng)理，對她的職業(yè)生涯有什么影響?如果她識別了一個不一致問題，但是項目不能按照過程來解決它，那么她必須把這個問題進行上報到這個經(jīng)理之上。此風險的緩解包括確保過程是明確的，并且在沖突可能出現(xiàn)的區(qū)域，在C級別(CIO，COO，等)上得到管理委員會的批準。
問題
對Ginger而言關鍵問題是術語。RUP和CMM都有大量的詞匯。當在審計期間發(fā)現(xiàn)過程中有一個不一致問題時，在挑選出什么是必需的和什么僅僅是方針上可能會有一些困難。當不一致的問題在項目中出現(xiàn)時，開發(fā)過程就變成了存儲庫，每個人都從中尋找為他們自己辯護或攻擊其他人的東西。過程的機械模仿變成了會議和電子郵件中的標準操作流程。管理是強迫的、迫不得已的，間歇前進。因此，“捕獲一個公共詞匯表”的RUP活動--特別是評價結(jié)果的步驟--需要非常仔細地來解決這個問題。所有過程的涉眾--經(jīng)理，實施人員，以及Ginger--必需同意 1)什么是過程所必需的，2)在項目開始前什么只是一個方針。
業(yè)務用例
識別業(yè)務用例是簡單的。組織的高級管理人員建立業(yè)務用例來完成CMM的合格證明。這依次變成個人、項目和組織過程所有者的業(yè)務用例。
構(gòu)架
所有構(gòu)件設計模式的來源，模型-視圖-控制器8，是此項任務的理想構(gòu)架設計模式。在這個經(jīng)典模式中，模型是過程(RUP)，視圖是Ginger的，并且控制器是質(zhì)量活動(包括測試)。質(zhì)量活動必須使成本和進度處于項目的控制之下，以滿足CMM的精神。其它設計模式也在過程定義里也有一席之地，也就是維護和支持。這些模式包括反射(變更工作產(chǎn)品以變更開發(fā)者的行為)，仲裁人(解決沖突--對SEPA有益)，以及命令鏈(提升遠離項目的不一致)。
產(chǎn)品
Ginger的一個虛擬SQA工作流包括了RUP工件及其檢查點、活動及其步驟的度量和總結(jié)，和計劃不同CMM活動的角色總結(jié)。她也有一個RUP10要素的筆記本，分別按照RUP和CMM的相關項進行了裁剪，包括了將RUP映射到CMM的IBM白皮書。她現(xiàn)在可能正用這項信息來計劃并執(zhí)行其工件的過程審計。這個視圖讓她知道：
1)哪些RUP的產(chǎn)品工件有檢查點;
2)哪些工件推薦為必需的，哪些工件對于一個給定的階段是可選的;
3)哪些活動具有稱為“結(jié)果的評估和驗證”的步驟，以及誰來驗證它們。
例如，軟件需求規(guī)格說明書(SRS)工件是需求詳細說明人負責的。它有定義的檢查點，是詳細說明軟件需求活動的結(jié)果，也是由需求詳細說明人執(zhí)行的。它是定義測試方法活動的一個輸入，定義測試方法活動包含評估和驗證你的結(jié)果(對于測試設計人員)和確認測試動因(由測試經(jīng)理)。Ginger需要確保擔任測試設計人員和測試經(jīng)理角色的個人被包含在需求的評審中，并且她可能使用檢查點來執(zhí)行分別的產(chǎn)品審計。Ginger現(xiàn)在知道如何有效地和高效地報告產(chǎn)品和過程度量給SEPA。
評估項目管理者聯(lián)盟
Ginger對過程的評估需要檢查在開始的時候先檢查利己主義(她的和我的)。我們必需保持關注，并且為了避免被她的批評觀點所泄氣，我需要對他們加以分類，或者是 1)一個過程的誤傳，這需要修正，或者 2) 一個過程需求的誤傳，這需要澄清。同樣地，當在她的項目中發(fā)現(xiàn)偏離時，Ginger必需將她的評估展現(xiàn)為建設性的批評;出于同樣原因，當她發(fā)現(xiàn)指示一致時，她必須提供積極的反饋。所有這些都需要進一步發(fā)展和改進過程。
變更
管理材料的變更是非常不正式的，并且及時地根據(jù)Ginger的需要進行管理。簡單的日期和時間標注還有電子郵件日志這樣指示變更的基本解釋是不足的。
用戶支持
對Ginger提供支持如此簡單，就象是重新建立特定的RUP工作流、角色、活動、工件或CMM關鍵實踐。RUP10論文展示了過程建立、配置和監(jiān)控的一個清晰路徑。
結(jié)束語
使用RUP10為Ginger建立一個虛擬的SQA工作流是富于挑戰(zhàn)性的和有益的，因為正如我所發(fā)現(xiàn)的，質(zhì)量的概念出現(xiàn)在RUP的任何地方。關于SQA工作流的一個明顯之處是在測試工作流和要求評估的已定義活動中。然而，帶有檢查點以及工件和活動集合在測試或其它流程中的地方的工件數(shù)量，以及涉及到的多個角色，要求每個人想到Ginger。質(zhì)量活動不是被限制為由一個指定的角色執(zhí)行的一個單一活動或一組活動。而且，SQA角色是在所有的角色中共享的，而不是從這個包中分離出去的。組織必需依靠其所有的員工來在每個點上確保質(zhì)量，一個產(chǎn)品就是在這些點上被定義、設計、實現(xiàn)、配置、評審、測試和發(fā)布的。Ginger只不過是這個負責質(zhì)量的抽象角色的實現(xiàn)--一個使用Cooper術語“角色”：當所有的角色都執(zhí)行分配給他們的活動時，我們必須考慮這個角色的多個方面。
備注
1 因為質(zhì)量保證被植入了CMM和集成CMM(CMMI)的階段，因此在本文的上下文中，區(qū)分對于區(qū)別兩個模型不是必需的。我簡單地查閱了整個“CMM”。有關CMM和軟件CMMI更多的信息，以及關鍵過程域。
2 帶有特別是級別1的CMM過程成熟度的基礎等級(2)。
3 參見“The Ten Essentials of RUP：The Essence of an Effective Development Process”，Leslee Probasco, IBM Rational 白皮書
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
許多剛開始接觸用戶體驗概率的企業(yè)非常希望能有一套標準體系，照做就可以保證產(chǎn)品的優(yōu)質(zhì)用戶體驗。其實，有許多講解用戶體驗評估要素和方法的公開資源，那么為什么還是只有少數(shù)產(chǎn)品擁有優(yōu)質(zhì)的用戶體驗呢？這其中有什么“秘密”？
用戶體驗質(zhì)量的基礎要素
有用性。滿足用戶的需求，為用戶解決實際問題，給用戶帶來價值。比如開發(fā)者需要明確輸入法產(chǎn)品的主要功用是幫助用戶在
手機上進行更快的文字輸入，而不是在手機上進行文字輸入的同時利用手勢動作給手機充電。當然，產(chǎn)品不一定只能圍繞用戶的現(xiàn)有需求。事實上很多優(yōu)秀的產(chǎn)品就是通過創(chuàng)造性地發(fā)掘用戶需求并解決，從而為產(chǎn)品帶來巨大價值。比如，直觀的觸摸控制、隨時隨地連接網(wǎng)絡、利用隨身攜帶的
移動設備，做以往需要通過不同設備才能實現(xiàn)的事情，當這些用戶需求被創(chuàng)造性地發(fā)掘、整合和滿足時，就出現(xiàn)了iPhone這樣劃時代的產(chǎn)品。
可用性/易用性。這是用戶體驗中最核心也是最龐雜的部分，包括可識別、可理解、可預測、掌控感、及時反饋、操作連續(xù)、一致性、穩(wěn)定、可靠、效率、使用疲勞度、易記憶、避免用戶犯錯并寬容對待用戶錯誤等內(nèi)容。可用性不僅包括界面設計，也包括產(chǎn)品的整體表現(xiàn)。比如產(chǎn)品是否使用流暢、穩(wěn)定，就是典型的涉及產(chǎn)品整體表現(xiàn)的例子。另外，在不同的使用情景下，可用性的側(cè)重點也不同。比如坐在辦公室中用手機撥打電話和開車時用手機撥打電話，對產(chǎn)品可用性的要求就不同，相應的對產(chǎn)品的要求也不同。
感性滿意度：給予用戶美感、愉悅或其他特定感受（比如游戲中的緊張感），給予用戶成就感或被關注、被尊重等感受。這些感受甚至可以延伸到產(chǎn)品之外，比如讓用戶覺得自己使用某個產(chǎn)品，在朋友圈里就顯得很牛。
激發(fā)性。經(jīng)典的用戶體驗評估主要包括以上三種要素，但隨著Web 2.0、社交網(wǎng)絡的興起，在融入了分享和社交元素的產(chǎn)品以及很多游戲和探索創(chuàng)造型產(chǎn)品（比如繪圖、音樂創(chuàng)作等）中，可以引入一個新的基礎要素，用來評估產(chǎn)品激發(fā)用戶進行探索、創(chuàng)造、分享、互動的活躍程度。用戶的這些行為已經(jīng)超越了單純的把產(chǎn)品作為工具使用的概念，而是把產(chǎn)品作為一個平臺，發(fā)揮自己的能力和潛力，和其他用戶一起產(chǎn)生聚變的力量。營造這種用戶體驗的要素，我稱之為激發(fā)性。
實際產(chǎn)品的常見問題
在實際產(chǎn)品中，最容易判斷卻又最常見的是和可用性有關的問題。
缺乏重點和引導。用戶進入頁面，看到的東西很多，卻不知道從何入手、該做什么，或者重要的功能被隱藏起來讓用戶很難發(fā)現(xiàn)。
缺乏明確的規(guī)則和一致性。如一個界面上的部分文字或圖案可以點擊、另一部分文字或圖案不能點擊；有些操作自動保存、有些操作默認不保存；同一個功能的按鈕在不同界面上位置不同、或者形態(tài)不同。
界面設計容易引起誤操作。當用戶發(fā)現(xiàn)時已造成了嚴重后果，或者讓用戶產(chǎn)生困惑。其次，經(jīng)常會出現(xiàn)和感性滿意度相關的問題。
犯基礎設計錯誤。對界面元素的色彩、段落的排布、字體的選取過于隨意，是最容易讓產(chǎn)品顯得不專業(yè)的幾個方面。
采用與產(chǎn)品氣質(zhì)不符的視覺設計。把輕量的網(wǎng)絡應用設計成層次復雜、質(zhì)感厚重，或者在精致的界面中突然出現(xiàn)一個簡陋的系統(tǒng)自帶控件，以及抄襲其他知名產(chǎn)品的設計。
為形式而形式。故意做一些很酷的效果，而不是為了更好地實現(xiàn)功能，甚至影響正常操作。
然而，并不是僅僅依照這些用戶體驗要素定制產(chǎn)品就一定能獲得優(yōu)質(zhì)的用戶體驗。首先，不同類型的產(chǎn)品需要不同的用戶體驗要素評價標準。比如工具類產(chǎn)品需要提高完成任務的效率，而游戲類產(chǎn)品反而可能需要降低完成任務的效率。面向普通用戶的產(chǎn)品往往強調(diào)簡潔易用，而企業(yè)級產(chǎn)品最重要的特質(zhì)是穩(wěn)定和可靠，反而要把操作做得復雜，反復確認以避免誤操作；其次，即便是同一產(chǎn)品，在不同的使用情景下，可用性的側(cè)重點也不同，需要全局化平衡考量；再次，在企業(yè)的不同發(fā)展階段，需要制訂相應的用戶體驗評價標準。比如有些產(chǎn)品在發(fā)展初期需要重點積累種子用戶，用戶體驗側(cè)重于讓這些特殊的種子用戶滿意。而到了快速成長期，重點變?yōu)榇罅堪l(fā)展普通用戶，用戶體驗就會變?yōu)榧骖櫰胀ㄓ脩艉头N子用戶的需求。
要做好產(chǎn)品的用戶體驗質(zhì)量控制，第一件事是想清楚產(chǎn)品究竟需要什么樣的用戶體驗：怎樣的用戶，在何種情景下，用產(chǎn)品做什么；產(chǎn)品的用戶體驗近期目標和長期目標是什么。由此再去組織資源，制訂工作流程，以及考評和激勵手段。同時，用戶體驗的質(zhì)量控制不能只靠評估。如果產(chǎn)品在研發(fā)過程中沒有用戶體驗力量的參與，而在隨后的評估中發(fā)現(xiàn)了問題，常常意味著大量的工作需要推倒重來，可往往已經(jīng)沒有時間進行修正了。
用戶體驗質(zhì)量監(jiān)控體系
用戶體驗質(zhì)量控制體系不僅僅是產(chǎn)品完成時的檢驗，而應成為貫穿研發(fā)過程始終的工作。
在研發(fā)過程中，讓用戶體驗工作盡早開始。進行訪談、焦點小組（Focus Group）、跟蹤觀察（Field Study或Diary Study）、問卷、數(shù)據(jù)分析等用戶研究、基于用戶體驗的競品分析，快速形成產(chǎn)品概念。
快速設計、快速檢驗。充分進行設計探索，將設計想法做成效果圖或原型，及早請目標用戶進行測試，根據(jù)反饋快速改進方案。
有條件的團隊可以請資深的產(chǎn)品和用戶體驗人員組成委員會，定期開用戶體驗評審會（UX/UI review）。有時，資淺但是不屬于這個項目團隊的產(chǎn)品人員或用戶體驗人員提出新鮮的意見和建議。同時，用戶體驗評審會也是資淺人員觀察學習資深人員分析問題、討論問題的好場所。
請非項目組成員的用戶體驗人員詳細試用和評估產(chǎn)品（Cognitive Walkthrough）。
在產(chǎn)品中預埋監(jiān)測點。等產(chǎn)品上線后收集用戶數(shù)據(jù)，或者主動進行對比實驗（A/B test），分析數(shù)據(jù)作為產(chǎn)品改進的依據(jù)。
建立通暢的用戶反饋渠道，以及鼓勵用戶反饋的機制。
根據(jù)產(chǎn)品特質(zhì)、用戶特點、使用情景、產(chǎn)品發(fā)展階段，選擇相應方法、流程、評估要素，在研發(fā)過程中推動用戶體驗工作，就是質(zhì)量控制體系保證用戶體驗質(zhì)量的秘密。
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
安裝 nodejs
安裝 Appium
Appium是Android平臺上一個測試框架。
本文簡單地介紹如何在
Linux機器上安裝并運行該框架。
應用環(huán)境：
Ubuntu 12.04 LTS
HTC One X (endeavoru, S720e)
Android SDK
請參考SDK環(huán)境，這里就不多說了。
Appium
安裝 nodejs
apt-get install nodejs
# 或者通過nodejs源碼編譯，這樣可以使用最新的代碼
cd ~/downloads
wget http://nodejs.org/dist/v0.10.25/node-v0.10.25.tar.gz
tar -zxf node-v0.10.25.tar.gz
cd ode-v0.10.25
./configure --prefix=/usr/local/node
make && make install
# edit ~/.bashrc and add node to your PATH env
安裝 Appium
npm install -g appium # install appium as a global app
配置手機
手機需要是已經(jīng)root過的！
su
chmod 777 /data/local
另外，也要確保你手機上安裝了最新的chrome瀏覽器!
Note:
這步是必需的，否則后面會發(fā)生無法啟動瀏覽器的異常。
下載&運行測試項目
# 下載項目
git clone git@github.com:ytfei/appium_chrome_demo.git
cd appium_chrome_demo
npm install # 安裝依賴包
# 啟動appium
appium -g appium.log &
# 開始測試
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
最近做一個項目,使用了WEBService,但是這個接口是別人提供的并且沒有完成,但是WSDL給提供了.
想使用SOAPUI的MOCKSERVICE功能模擬一個WEBService.
首先用AXIS做了一個WEBService,用以下代碼進行測試OK,但訪問SOAPUI做的MOCKSERVICE失敗,
想向各位高手確認下,SOAPUI的MOCKSERVICE能做為一WEBService讓
JAVA程序訪問嗎?
JAVA WEBclient代碼如下:
Java code?123456789101112131415161718192021222324252627 // String endpoint = "http://localhost:8080/axis/Hello.jws?wsdl"; String endpoint = "http://localhost:8088/axis/Hello.jws?WSDL"; Service service = new Service(); Call call = (Call) service.createCall(); call.setTargetEndpointAddress(endpoint); call.setOperationName("hello"); call.setSOAPVersion(SOAPConstants.SOAP11_CONSTANTS); call.addParameter("name", org.apache.axis.encoding.XMLType.XSD_STRING, javax.xml.rpc.ParameterMode.IN); // call.addParameter("ToCurrency", org.apache.axis.encoding.XMLType.XSD_STRING, // // javax.xml.rpc.ParameterMode.IN); call.setReturnType(org.apache.axis.encoding.XMLType.XSD_STRING); Object result = call.invoke(new Object[]{"JPY"}); System.out.println("result is "+result.toString()); SOAPUI的HTTP LOG如下: Sun Aug 26 23:18:36 JST 2012:DEBUG:HelloSoapBinding MockService was unable to dispatch mock request com.eviware.soapui.impl.wsdl.mock.DispatchException: Missing operation for soapAction [] and body element [hello] with SOAP Version [SOAP 1.1] at com.eviware.soapui.impl.wsdl.support.soap.SoapUtils.findOperationForRequest(SoapUtils.java:353) at com.eviware.soapui.impl.wsdl.mock.WsdlMockRunner.dispatchPostRequest(WsdlMockRunner.java:260) at com.eviware.soapui.impl.wsdl.mock.WsdlMockRunner.dispatchRequest(WsdlMockRunner.java:383) at com.eviware.soapui.monitor.JettyMockEngine$ServerHandler.handle(JettyMockEngine.java:701) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:326) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542) at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:938) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:755) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) Sun Aug 26 23:18:36 JST 2012:ERROR:An error occured [Missing operation for soapAction [] and body element [hello] with SOAP Version [SOAP 1.1]], see error log for details |
JAVA的錯誤代碼如下:
- Unable to find required classes (javax.activation.DataHandler and javax.mail.internet.MimeMultipart). Attachment support is disabled. AxisFault faultCode: {http://xml.apache.org/axis/}HTTP faultSubcode: faultString: (500)Internal Server Error faultActor: faultNode: faultDetail: {}:return code: 500 <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Body> <soapenv:Fault> <faultcode>Server</faultcode> <faultstring>Missing operation for soapAction [] and body element [hello] with SOAP Version [SOAP 1.1]</faultstring> </soapenv:Fault> </soapenv:Body> </soapenv:Envelope> {http://xml.apache.org/axis/}HttpErrorCode:500 (500)Internal Server Error at org.apache.axis.transport.http.HTTPSender.readFromSocket(HTTPSender.java:744) at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:144) at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32) at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118) at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83) at org.apache.axis.client.AxisClient.invoke(AxisClient.java:165) at org.apache.axis.client.Call.invokeEngine(Call.java:2784) at org.apache.axis.client.Call.invoke(Call.java:2767) at org.apache.axis.client.Call.invoke(Call.java:2443) at org.apache.axis.client.Call.invoke(Call.java:2366) at org.apache.axis.client.Call.invoke(Call.java:1812) at WebServiceClient.main(WebServiceClient.java:51) (500)Internal Server Error |
用JAVA訪問AXIS的WEBSERVICE的OK結(jié)果如下:
- Unable to find required classes (javax.activation.DataHandler and javax.mail.internet.MimeMultipart). Attachment support is disabled. result is Hello JPY |
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters