改善网络的可扩展型
实现快速收敛
OSPF路由器的类型
内部路由器：所有接口同属于一个区域
区域边界路由器（ABR）：连接一个/多个区域到骨干区域
自治系统边界路由器（ASBR）：连接OSPF域和其他AS
区域的类型：骨干区域（Area 0）、标准区域、末梢区域、完全末梢区域、非纯末梢区域等
链路状态通告
常见的LSA有六种类型，分别是LSA1、LSA2、LSA3、LSA4、LSA5和LSA7
ASBR会通过自己的LSA1中有标识着自己是ASBR的字段，当ASBR同区域的ABR收到后，会为自己所在的除已知ASBR信息区域外的所有区域生成LSA4，用来通告ASBR信息。 ABR的LSA1中亦有一个标识自己是ABR的字段。
所有LSA1、LSA2、LSA3信息在Area0的ABR路由器上汇总成新的LSA3，再通告给其他Area。
路由重分发
将其他协议或静态等路由通过ASBR路由器通告到OSPF中去。
命令：redistribute
配置路由路由重分发
R5(config-router)#redistribute protocol [metric metric-value] [metric-type type-value] [subnets]
protocol：进行路由重发的源路由协议，如：bgp、eqp、isis、ospf [process-id（进程）]、staic（静态）、connect（直连）、rip
metric：指定路由的度量值
metric-type：重分发的路由类型，1或2，即E1和E2
subnets：与其子网一起宣告，即关闭子网汇总
RIP重分发至OSPF（度量值默认为20，类型默认为E2）
R1(config-router)#redistribute rip subnets
将OSPF重分发至到RIP
R1(config-router)#redistribute ospf 110 metric 10
110：ospf协议进程ID
10：默认度量值
静态路由重分发
R5(config-router)#redistribute static subnets
默认路由重分发
R5(config-router)#default-information originate [always]
always：直接重分发路由，ASBR可以不配置默认路由
路由表中的路由类型
O IA ：OSPF的区域间路由
O E2：此路由的度量值默认为20，且在域内/外不累加，恒为20
O E2：此路由的度量值默认为20，且在域外不累加，域内累加
（将一个协议重分发到另一个协议中，域外都不累加）
末梢区域和完全末梢区域
满足以下4个条件的区域
只有一个默认路由作为其区域的出口
区域不能作为虚链路的穿越区域
Stub区域里无自治系统边界路由器ASBR
不是骨干区域Area 0
1、末梢区域（Stub Area）
没有LSA4、LSA5、LSA7通告，将重分发的路由信息汇聚成一条默认路由
配置命令
R1(config-router)#area area-id stub
2、完全末梢区域（Totally Stubby Area）
除一条LSA3的默认路由通告外，没有LSA3、LSA4、LSA5、LSA7通告，将重分发的路由信息和LSA3路由信息汇聚成一条默认路由
配置命令
R1(config-router)#area area-id stub no-summary
（在整个区域的所有路由器中都要配置）
配置非纯末梢区域（NSSA）
配置NSSA区域
R1(config-router)#area area-id nssa [no-summary]
配置了NSSA区域后，ASBR所在OSPF区域内的LSA5通告信息被LSA7替代了LSA5，此区域本来的ABR将LSA7转换成了LSA5，此ABR兼任了ASBR。no-summary 将其他域内的路由信息（LSA3）汇总成一条默认路由。
路由汇总
外部汇总
R1(config-router)#area 2 range ip-address mask
内部汇总
R4(config-router)#summary-address ip-address mask
查看OSPF协议配置信息
show ip protocols
查看OSPF配置信息
show ip ospf
查看LSDB内的所有LSA数据信息
show ip ospf database
查看接口上OSPF配置的信息
show ip ospf interface
查看OSPF邻居和邻接关系
show ip ospf neighbor [detail] // detail：详细查看
查看路由器“邻接”的整个过程
debug ip ospf adj
查看每个OSPF数据包的信息
debug ip ospf packet
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
环境配置
项目使用SSH架构，现在要添加Spring事务管理功能，针对当前环境，只需要添加Spring2.0AOP类库即可。添加方法：
点击项目右键->BuildPath->Addlibrarys:
打开AddLibraries对话框，然后选定MyEclipseLibraries：
点击Next，找到Spring2.0aopLibraries并勾选上，点击finsh即可。
如果在项目里面能看到下面的库文件，说明已经安装成功。
事务配置
首先在/WEB-INF/applicationContext.xml添加以下内容：
<!--配置事务管理器--> <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，所以在命名上需要作出规范，初步的构想就是模块名+Advice（只是一种命名规范）。
（2）tx:attribute标签所配置的是作为事务的方法的命名类型。
如<tx:methodname="save*"propagation="REQUIRED"/>
其中*为通配符，即代表以save为开头的所有方法，即表示符合此命名规则的方法作为一个事务。
propagation="REQUIRED"代表支持当前事务，如果当前没有事务，就新建一个事务。这是最常见的选择。
（3）aop:pointcut标签配置参与事务的类，由于是在Service中进行数据库业务操作，配的应该是包含那些作为事务的方法的Service类。
首先应该特别注意的是id的命名，同样由于每个模块都有自己事务切面，所以我觉得初步的命名规则因为all+模块名+ServiceMethod。而且每个模块之间不同之处还在于以下一句：
expression="execution(*com.test.testAda.test.model.service.*.*(..))"
其中第一个*代表返回值，第二*代表service下子包，第三个*代表方法名，“（..）”代表方法参数。
（4）aop:advisor标签就是把上面我们所配置的事务管理两部分属性整合起来作为整个事务管理。
图解：
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
1. 建立project
django-admin.py startproject newproject
完成上个步骤后，可发现在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.创建数据库表
#python manage.py syncdb
按提示输入账号密码即可
#python manage.py runserver
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
1.要提高质量的bug：
——》多次重现之后，确定为bug
——》用专业的属于描述bug
——》标题简洁清晰，概括准确（因为bug不只是在卡法在看，主管和做bug统计时都要关注，所以标题很重要。例如：在XX情景下，发生了OO状况，注意场景描述与操作步骤描述的区别）
2. 如何判断bug是不是小bug？
——》从“用户体验”上看对用户的影响，来判断是否为小bug。在提交bug时，应在bug描述中写明“影响”
3.提交bug中的附件
——》1.测试数据（excel,sql语句）
——》2.如果是自己上传的图片，要注意文件的命名规范 ： 图序列/含义
——》3.日志信息：截取关键部分
4.bug的严重程度和优先级如何判定？
——》严重程度是从 “用户角度”来说的。
——》优先级是从“
测试人员角度”来说的。 优先级高的bug可能并不严重，但是阻碍了测试人员接下来的测试，则提高优先级，让开发先fixed掉这些bug
5.bug的深度如何判断？bug深度有什么作用？
——》bug深度 是为了解决某些开发人员代码质量差的问题。每隔一段时间统计一下“很容易发现” 的bug数量，可以看出一个开发人员在这段时间的代码质量和
工作状态，便于管理人员协助调整。“很容易发现”的bug多为功能逻辑上的问题，是一般的开发人员不会犯的菜鸟级问题。而对于建议性bug来说，一般都判定为“很难发现”，因为此类bug含有测试人员的主观因素在。
6.如何通过分析bug了解项目质量：
1。根据活动bug趋势图 。（活动bug：没有进入最终状态之前的bug都是活动bug）
2.每日新增bug趋势图
3.开发未关闭的bug个数
7.开发fixed掉一个bug，但是在修改过程中引入了另外的bug，这种情况下是应该重新提bug还是在原来bug上reopen?
——》重新提bug， 要保证bug的单一性。
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
0、前言
在软件设计开发中，代码的设计都体现在：子系统与子系统、模块与模块、函数与函数之间的关系，设计越糟糕的软件，维护成本越高，质量也往往难以达标和称赞。
好的设计必定是：层次关系简洁、清晰、易维护和扩展的。
不会研究太高深的设计，只总结出一些常见的代码设计缺陷，这些设计缺陷如能很好的解决和避免，相信代码能力（编写、设计、评审、重构）能提高一个档次。
主要介绍下面15个常见代码设计缺陷：
1、复杂函数（Blob Operation）
缺陷特征：指的是代码行多，分支嵌套深，变量多，参数多，注释多，复杂度高等特征的函数。
缺陷影响：函数不易理解和维护，代码重复、冗余。
解决方法：新开发代码时，函数都是越写越复杂的，应该要有意识地、积极地去分解提炼成小函数或独立功能的函数，甚至当感觉需要以注释来说明点什么的时候，这时其实就应该独立成一个函数。函数建议值：代码行24，if语嵌套深度6，圈复杂度10，功能应该单一。
2、数据泥团（Data Clumps）
缺陷特征：函数的参数多且参数列表相似，反复调用相同的参数列表。
缺陷影响：大量重复，影响编译的效率；参数多，很难理解和调用。
解决方法：参数列表应该封装成结构。建议值：函数参数平均为2，避免5个以上。
伪码示例：GetDate(int year,int month,int day,int time) -> GetDate(struct DateRange)。
3、不必要的耦合（Unnecessary Coupling）
缺陷特征：包含某个头文件，但是却没有使用头文件中任何内容。
缺陷影响：编译链接速度慢，耦合度高，头文件错误包含，如包含某个头文件却没有使用里面的内容，某个头文件却依赖某个dll，则会引起不必要的dll依赖和错误。
解决方法：头文件不能乱包含，100%确认每个包含的头文件使用情况，删除不必要包含的头文件。
4、过度耦合（Intensiue Coupling）
缺陷特征：一个函数调用大量其它模块的函数，却调用很少本模块的函数。
缺陷影响：一个函数与多个函数（这些函数属于少数一两个类）联系过于紧密；一个类提供了很多函数给外部某个函数调用；耦合度高，类不够抽象。
解决方法：识别内、外部模块函数，外部模块要足够抽象调用。
5、循环依赖（Cyclic Dependencies）
缺陷特征：多个子系统处于一个环状互相依赖关系里面；函数的调用关系混乱、循环；文件直接或间接交叉引用。
缺陷影响：不易理解和维护，编译慢，关系混乱，重用困难。
解决方法：多文件或系统间要划分清楚结构、层次关系，应做到无环依赖。
伪码示例：循环包含头文件，file A包含file B,而file B又包含了file A。
6、依恋情节（Feature Envy）
缺陷特征：函数很少访问自己模块数据，总是访问外部模块数据；访问自己模块少，访问其它模块多；数据和操作不在同一模块；对其它类的数据比较感兴趣。
缺陷影响：耦合度高。
解决方法：同一模块的数据和操作应该放在一起。
7、重复代码（Repeat code）
缺陷特征：不同模块或文件间有类似或重复功能的类；不同类间有类似或重复功能的函数；同一父类的子类间存在相似或重复功能的代码。
缺陷影响：代码膨胀混乱，不易维护，本来维护一处代码由于重复代码要维护多处。
解决方法：提炼重复代码。如工具函数封装成工具类，通用功能封装成公共库。
8、不稳定依赖（Unstable Dependencies）
缺陷特征：一个子系统或模块依赖于另一个比它更不稳定的子系统或模块，如上层模块依赖于不稳定的底层模块，上层模块肯定会问题不断。
缺陷影响：不独立，不稳定，牵一发而动全身。
解决方法：当有依赖关系时，一定要先保证被依赖子系统或模块的稳定性。至少应保证不稳定的子系统要依赖稳定的子系统。
9、未利用的接口（Underutiliaed Interface）
缺陷特征：设计并实现了很多接口，大部分未使用或只在内部使用；定义了很多全局变量，大部分其它模块未使用。
缺陷影响：冗余，设计过度，暴露可视化。
解决方法：按需设计接口，不需要对外公开的变量和函数应该私有化。
10、紊乱类（Schizophrenic Class）
缺陷特征：一个类实现了多个不同的功能，如界面类又处理了业务相关的功能。
缺陷影响：不易理解，耦合度高，公共方法太多。
解决方法：对多个功能进行拆分。
11、复杂类（Blob Class）
缺陷特征：规模非常庞大、复杂性高的类，常常包含多个复杂函数，有多重功能。
缺陷影响：圈复杂度高，内聚性差，耦合度高，不易看懂和维护。
解决方法：解决复杂函数，结构要清晰，类功能应该单一。建议值：类行数应在2000以内。
12、全能类（God Class）
缺陷特征：一个类集中了多个不相关类的功能；一个类操作其它模块数据太多；大而复杂。
缺陷影响：破坏了类的封装性，耦合度高，内聚性差，不易维护。
解决方法：多个功能不相关的类应该分别封装成不同的类，适当搬移函数，解决复杂函数问题。
13、歪曲层次（Distorted Hierarchy）
缺陷特征：类的继承关系比较深。
缺陷影响：复杂度高，不易维护。
解决方法：类的继承层次结构不应该超过6。
14、数据类（Data Class）
缺陷特征：提供许多公共属性和函数，供很多其它类来操作，自己却很少操作。
缺陷影响：非面向对象，缺乏封装性，不易维护。
解决方法：封装性。
15、破坏继承（Tradition Breaker）
缺陷特征：派生类几乎没有使用任何继承父类的功能，却增加了全新的功能。
缺陷影响：非继承关系却继承，难理解，不易维护。
解决方法：理清类与类之间的继承关系，不适合继承关系的类应该单独分开。
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
什么时候已经测够了, 可以停止了, 这个问题是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是否下降, 也就是看是否有收敛的迹象. 如果还是在向上发展, 当然是无法结束.
- 即使现在bug已经解完, 并且目前没有发现新bug, 但是若是目前submission ratio值是很高, 也不可能瞬间忽然降成0. 所以这通常意味着, 其实受测系统里面还有很多潜藏的bug, 只是目前还没被抓出来. 所以还是要降低到某个程度才是比较save的状况.
3. The testing budget is exhausted.
4. The project duration is completed.
时间了也是个无可奈何的指标, 这有可能时当初schedule就有问题, 或是测试规划的有问题. 导致时间不够使用.
5. The risk in the project is under acceptable limit.
如果risk很低, 是project可以接受的范围当然是无所谓啦!! Manager说了算!! 呵呵~~~
其实测试是否可以停止,是否足够, 这要看你是否收及足够的information. 毕竟测试是个information-gethering的流程, 如果你有足够的信息, 让你可以掌握目前project质量的状态, 你自然可以很清楚知道目前测试是否已经够了, 可以结束了.
所以当你不知道是否测试可以结束时, 先问问自己你是否掌握项目的状况. 如果不知道, 当然是回答不了啦!!
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：
软件开发组织执行SEI的能力成熟度模型(CMM)可能会由于在 Rational 统一过程或RUP中缺乏一个软件质量保证(SQA)
工作流而失败。本文描述了一个虚拟的 SQA 工作流，其源自于 Leslee Probasco 的RUP的十点要素。
存在有九个RUP工作流程，包括了需求、
项目管理、配置 & 变更管理，甚至还有业务建模——但是没有一个是用于软件质量保证(SQA)的。这种明显的疏忽对寻求SEI的软件成熟度模型(CMM)的项目和组织是非常棘手的1，因为SQA的关键过程域(KPA)承载了成熟度模型的重要工作。自从有了
需求管理的KPA，其可以精细地映射到Rational 统一过程?或RUP?的需求工作流，还有项目管理(包括计划和监控)和
配置管理的关键过程域同样分别精细地映射到RUP的项目管理以及配置和变更管理的工作流，难道只是对SQA没有吗?
我开始回答这个问题，并且沿着这条路揭示了CMM以及RUP实质的SQA工作流中的质量的真正含义。
SQA和CMM
软件工程协会(SEI)将软件质量保证设置为CMM的基础级别2。他们也将所有其它关键过程域的验证和确认放在了质量保证中。此外，CMM反复强调高级管理人员必须“保护个人履行SQA责任”，因为这有可能会给发现不一致问题的职员带来管理上的问题。如此强调 SQA活动和需求，为什么没有一个SQA工作流，以及更重要的是在RUP中没有一个SQA角色呢?一个SQA工作流会提供活动，还有工件，以及在其它RUP流程里提供个人执行SQA的各自的检查点。
虚拟的SQA工作流
为了解决这个迷惑，我寻找什么是已经被证实了的RUP里有效解决问题的实践。RUP是通过软件工程过程权威(SEPA)进行质量保证--尽管理论上是SQA，这是一个组的职责，而不是一个个体的角色。我做了一个练习，创建了RUP的一个视图，以满足SQA角色的需要，如同在CMM中所确定的那样。我特别实行了Leslee Probasco在“RUP的十点要素--一个有效开发过程的精髓”中所描述的建议，3来创建一个真实的SQA工作流。在她的论文(在此以后用RUP10来指代)，Probasco推荐形成一个有标签的笔记本4，每个标签代表每个要素(V-PRI-BAPE-CU)，用来管理一个项目的基本元素。所以我创建了一个这样的笔记本，每个标签包括了RUP的必要工件描述，复制了相关活动以产生RUP已经定义的元素和所有的检查点，还有个人记录和元素以支持各自的要素。
例如，对于必要元素 #1，远景(Vision)，我插入了远景工件的副本，还有RUP中用于产生远景的三个活动：开发远景，管理依赖关系，以及评估概念构架的生存能力。我也包括了远景和涉众请求检查点的一个副本。接着我执行了这些活动，将结论文档化，并且正如Probasco建议的那样，我产生了很多记录。5在我对RUP和CMM有了更多认识时，我增加了更多的工件、活动、检查点以及指南到相应的标签中。
远景
远景的开发包括了很多的便笺，因为众多的远景都会成为想法。远景必须有效地针对涉众所面对的问题。SQA工程师既不是一个RUP角色，也没有一个所描述活动和定义工件的工作流视图。为了更好地理解我的涉众-SQA工程师的需要，我借用了Alan Cooper的The Inmates Are Running the Asylum及其开发“角色”的实践。6我的SQA工程师角色是一位名叫Ginger的女性。她在RUP和CMM的训练方面属于中级水平的工程师。在对分配给她的项目上涉及到的过程不一致发出错误警告上，她并不是资历较浅的，但是在期望她挑战那些拥有更多过程或领域专门知识上也并不是经验丰富的。
Cooper 这样形容“消极角色”：某些人，对于他们，过程不是在被构建，而是需要更好地理解过程需求。这些消极的角色代表了30多个的RUP角色，这些角色是Ginger必须接口的，因为她提供了对产生的工件产品和执行的活动的客观评审。这些个人在软件开发实践方面接受了更细致的训练和练习。Ginger不在项目中，并且没有涉及到所有的项目活动，因此对她来说，很容易遗漏或误解一些事情。当 Ginger足够成熟来理解她的个人职责时，她被期望知道在什么时间和执行哪些验证和确认活动，她不被期望能够强制过程一致性(就是SEPA)。进一步的，与CMM一致的是，当她尝试“逐步升高项目外部的偏差”到可执行级时，她被保护以免于可能的“敌对人员行为”。
计划
对于Ginger，计划就是遵循RUP10，并产生一个虚拟的SQA工作流程。过程规模度量的搜集、分析和报告是Gingre必需进行的工作。她知道在RUP里有多少工件、活动、角色评审和评估的步骤，因此能够更好地计划和安排她的任务时间表。在冲突解决领域，她知道工件的所有人和活动的产生者不是相同的角色这种情况，她或许能通过确保这些工件的检查点或规格特征在每个团队成员间达成一致。这些在RUP10素材笔记本里的表述帮助Ginger知道了什么、在哪里以及如何开始她的质量审核。她的工作流程将会遵循RUP过程相关的素材和图表，作为RUP的工件和活动集合。我也会进一步使用RUP10来配置一个过程，集中在质量和使用的规模度量上(通过阶段和角色来统计工件和活动)。
风险
对Ginger而言，计算风险意味着将场景脚本化。成功和可选场景揭示了在项目中冲突可能出现的地方。CMM通过重复使得履行SQA角色的个人需要得到保护这点非常清晰。因此，虚拟的SQA工作流程需要揭示潜在的危险领域。如果Ginger的老板是项目经理，对她的职业生涯有什么影响?如果她识别了一个不一致问题，但是项目不能按照过程来解决它，那么她必须把这个问题进行上报到这个经理之上。此风险的缓解包括确保过程是明确的，并且在冲突可能出现的区域，在C级别(CIO，COO，等)上得到管理委员会的批准。
问题
对Ginger而言关键问题是术语。RUP和CMM都有大量的词汇。当在审计期间发现过程中有一个不一致问题时，在挑选出什么是必需的和什么仅仅是方针上可能会有一些困难。当不一致的问题在项目中出现时，开发过程就变成了存储库，每个人都从中寻找为他们自己辩护或攻击其他人的东西。过程的机械模仿变成了会议和电子邮件中的标准操作流程。管理是强迫的、迫不得已的，间歇前进。因此，“捕获一个公共词汇表”的RUP活动--特别是评价结果的步骤--需要非常仔细地来解决这个问题。所有过程的涉众--经理，实施人员，以及Ginger--必需同意 1)什么是过程所必需的，2)在项目开始前什么只是一个方针。
业务用例
识别业务用例是简单的。组织的高级管理人员建立业务用例来完成CMM的合格证明。这依次变成个人、项目和组织过程所有者的业务用例。
构架
所有构件设计模式的来源，模型-视图-控制器8，是此项任务的理想构架设计模式。在这个经典模式中，模型是过程(RUP)，视图是Ginger的，并且控制器是质量活动(包括测试)。质量活动必须使成本和进度处于项目的控制之下，以满足CMM的精神。其它设计模式也在过程定义里也有一席之地，也就是维护和支持。这些模式包括反射(变更工作产品以变更开发者的行为)，仲裁人(解决冲突--对SEPA有益)，以及命令链(提升远离项目的不一致)。
产品
Ginger的一个虚拟SQA工作流包括了RUP工件及其检查点、活动及其步骤的度量和总结，和计划不同CMM活动的角色总结。她也有一个RUP10要素的笔记本，分别按照RUP和CMM的相关项进行了裁剪，包括了将RUP映射到CMM的IBM白皮书。她现在可能正用这项信息来计划并执行其工件的过程审计。这个视图让她知道：
1)哪些RUP的产品工件有检查点;
2)哪些工件推荐为必需的，哪些工件对于一个给定的阶段是可选的;
3)哪些活动具有称为“结果的评估和验证”的步骤，以及谁来验证它们。
例如，软件需求规格说明书(SRS)工件是需求详细说明人负责的。它有定义的检查点，是详细说明软件需求活动的结果，也是由需求详细说明人执行的。它是定义测试方法活动的一个输入，定义测试方法活动包含评估和验证你的结果(对于测试设计人员)和确认测试动因(由测试经理)。Ginger需要确保担任测试设计人员和测试经理角色的个人被包含在需求的评审中，并且她可能使用检查点来执行分别的产品审计。Ginger现在知道如何有效地和高效地报告产品和过程度量给SEPA。
评估项目管理者联盟
Ginger对过程的评估需要检查在开始的时候先检查利己主义(她的和我的)。我们必需保持关注，并且为了避免被她的批评观点所泄气，我需要对他们加以分类，或者是 1)一个过程的误传，这需要修正，或者 2) 一个过程需求的误传，这需要澄清。同样地，当在她的项目中发现偏离时，Ginger必需将她的评估展现为建设性的批评;出于同样原因，当她发现指示一致时，她必须提供积极的反馈。所有这些都需要进一步发展和改进过程。
变更
管理材料的变更是非常不正式的，并且及时地根据Ginger的需要进行管理。简单的日期和时间标注还有电子邮件日志这样指示变更的基本解释是不足的。
用户支持
对Ginger提供支持如此简单，就象是重新建立特定的RUP工作流、角色、活动、工件或CMM关键实践。RUP10论文展示了过程建立、配置和监控的一个清晰路径。
结束语
使用RUP10为Ginger建立一个虚拟的SQA工作流是富于挑战性的和有益的，因为正如我所发现的，质量的概念出现在RUP的任何地方。关于SQA工作流的一个明显之处是在测试工作流和要求评估的已定义活动中。然而，带有检查点以及工件和活动集合在测试或其它流程中的地方的工件数量，以及涉及到的多个角色，要求每个人想到Ginger。质量活动不是被限制为由一个指定的角色执行的一个单一活动或一组活动。而且，SQA角色是在所有的角色中共享的，而不是从这个包中分离出去的。组织必需依靠其所有的员工来在每个点上确保质量，一个产品就是在这些点上被定义、设计、实现、配置、评审、测试和发布的。Ginger只不过是这个负责质量的抽象角色的实现--一个使用Cooper术语“角色”：当所有的角色都执行分配给他们的活动时，我们必须考虑这个角色的多个方面。
备注
1 因为质量保证被植入了CMM和集成CMM(CMMI)的阶段，因此在本文的上下文中，区分对于区别两个模型不是必需的。我简单地查阅了整个“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
许多刚开始接触用户体验概率的企业非常希望能有一套标准体系，照做就可以保证产品的优质用户体验。其实，有许多讲解用户体验评估要素和方法的公开资源，那么为什么还是只有少数产品拥有优质的用户体验呢？这其中有什么“秘密”？
用户体验质量的基础要素
有用性。满足用户的需求，为用户解决实际问题，给用户带来价值。比如开发者需要明确输入法产品的主要功用是帮助用户在
手机上进行更快的文字输入，而不是在手机上进行文字输入的同时利用手势动作给手机充电。当然，产品不一定只能围绕用户的现有需求。事实上很多优秀的产品就是通过创造性地发掘用户需求并解决，从而为产品带来巨大价值。比如，直观的触摸控制、随时随地连接网络、利用随身携带的
移动设备，做以往需要通过不同设备才能实现的事情，当这些用户需求被创造性地发掘、整合和满足时，就出现了iPhone这样划时代的产品。
可用性/易用性。这是用户体验中最核心也是最庞杂的部分，包括可识别、可理解、可预测、掌控感、及时反馈、操作连续、一致性、稳定、可靠、效率、使用疲劳度、易记忆、避免用户犯错并宽容对待用户错误等内容。可用性不仅包括界面设计，也包括产品的整体表现。比如产品是否使用流畅、稳定，就是典型的涉及产品整体表现的例子。另外，在不同的使用情景下，可用性的侧重点也不同。比如坐在办公室中用手机拨打电话和开车时用手机拨打电话，对产品可用性的要求就不同，相应的对产品的要求也不同。
感性满意度：给予用户美感、愉悦或其他特定感受（比如游戏中的紧张感），给予用户成就感或被关注、被尊重等感受。这些感受甚至可以延伸到产品之外，比如让用户觉得自己使用某个产品，在朋友圈里就显得很牛。
激发性。经典的用户体验评估主要包括以上三种要素，但随着Web 2.0、社交网络的兴起，在融入了分享和社交元素的产品以及很多游戏和探索创造型产品（比如绘图、音乐创作等）中，可以引入一个新的基础要素，用来评估产品激发用户进行探索、创造、分享、互动的活跃程度。用户的这些行为已经超越了单纯的把产品作为工具使用的概念，而是把产品作为一个平台，发挥自己的能力和潜力，和其他用户一起产生聚变的力量。营造这种用户体验的要素，我称之为激发性。
实际产品的常见问题
在实际产品中，最容易判断却又最常见的是和可用性有关的问题。
缺乏重点和引导。用户进入页面，看到的东西很多，却不知道从何入手、该做什么，或者重要的功能被隐藏起来让用户很难发现。
缺乏明确的规则和一致性。如一个界面上的部分文字或图案可以点击、另一部分文字或图案不能点击；有些操作自动保存、有些操作默认不保存；同一个功能的按钮在不同界面上位置不同、或者形态不同。
界面设计容易引起误操作。当用户发现时已造成了严重后果，或者让用户产生困惑。其次，经常会出现和感性满意度相关的问题。
犯基础设计错误。对界面元素的色彩、段落的排布、字体的选取过于随意，是最容易让产品显得不专业的几个方面。
采用与产品气质不符的视觉设计。把轻量的网络应用设计成层次复杂、质感厚重，或者在精致的界面中突然出现一个简陋的系统自带控件，以及抄袭其他知名产品的设计。
为形式而形式。故意做一些很酷的效果，而不是为了更好地实现功能，甚至影响正常操作。
然而，并不是仅仅依照这些用户体验要素定制产品就一定能获得优质的用户体验。首先，不同类型的产品需要不同的用户体验要素评价标准。比如工具类产品需要提高完成任务的效率，而游戏类产品反而可能需要降低完成任务的效率。面向普通用户的产品往往强调简洁易用，而企业级产品最重要的特质是稳定和可靠，反而要把操作做得复杂，反复确认以避免误操作；其次，即便是同一产品，在不同的使用情景下，可用性的侧重点也不同，需要全局化平衡考量；再次，在企业的不同发展阶段，需要制订相应的用户体验评价标准。比如有些产品在发展初期需要重点积累种子用户，用户体验侧重于让这些特殊的种子用户满意。而到了快速成长期，重点变为大量发展普通用户，用户体验就会变为兼顾普通用户和种子用户的需求。
要做好产品的用户体验质量控制，第一件事是想清楚产品究竟需要什么样的用户体验：怎样的用户，在何种情景下，用产品做什么；产品的用户体验近期目标和长期目标是什么。由此再去组织资源，制订工作流程，以及考评和激励手段。同时，用户体验的质量控制不能只靠评估。如果产品在研发过程中没有用户体验力量的参与，而在随后的评估中发现了问题，常常意味着大量的工作需要推倒重来，可往往已经没有时间进行修正了。
用户体验质量监控体系
用户体验质量控制体系不仅仅是产品完成时的检验，而应成为贯穿研发过程始终的工作。
在研发过程中，让用户体验工作尽早开始。进行访谈、焦点小组（Focus Group）、跟踪观察（Field Study或Diary Study）、问卷、数据分析等用户研究、基于用户体验的竞品分析，快速形成产品概念。
快速设计、快速检验。充分进行设计探索，将设计想法做成效果图或原型，及早请目标用户进行测试，根据反馈快速改进方案。
有条件的团队可以请资深的产品和用户体验人员组成委员会，定期开用户体验评审会（UX/UI review）。有时，资浅但是不属于这个项目团队的产品人员或用户体验人员提出新鲜的意见和建议。同时，用户体验评审会也是资浅人员观察学习资深人员分析问题、讨论问题的好场所。
请非项目组成员的用户体验人员详细试用和评估产品（Cognitive Walkthrough）。
在产品中预埋监测点。等产品上线后收集用户数据，或者主动进行对比实验（A/B test），分析数据作为产品改进的依据。
建立通畅的用户反馈渠道，以及鼓励用户反馈的机制。
根据产品特质、用户特点、使用情景、产品发展阶段，选择相应方法、流程、评估要素，在研发过程中推动用户体验工作，就是质量控制体系保证用户体验质量的秘密。
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
安装 nodejs
安装 Appium
Appium是Android平台上一个测试框架。
本文简单地介绍如何在
Linux机器上安装并运行该框架。
应用环境：
Ubuntu 12.04 LTS
HTC One X (endeavoru, S720e)
Android SDK
请参考SDK环境，这里就不多说了。
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
配置手机
手机需要是已经root过的！
su
chmod 777 /data/local
另外，也要确保你手机上安装了最新的chrome浏览器!
Note:
这步是必需的，否则后面会发生无法启动浏览器的异常。
下载&运行测试项目
# 下载项目
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结果如下:
- 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