法律到的软件测试

发布时间:2018-09-19  栏目:法律  评论:0 Comments

1 全经过的软件测试图解

风土人情的软件测试,开发人员完成任务后,最后交给受测试人员,这种模式下,测试人员不能够赶紧发现需等的先天不足,同时测试工作的开展呢落后了,产品质量得无至有效的历程控制和分析,总体进度可能会见出于返工问题导致拖延。

嘿是全程软件测试,也足以说到的软件测试,如下图所示:
法律 1

在普SDLC中,三长角色主线和季只级次。

老三漫漫角色主线:开发、QA、测试,文中主要讲解测试。

季只级次:需求、开发、发布、日常营业。

简单的话可综合为产图所示:

法律 2

测试人员贯穿这四只级次,开展测试活动,试实践活动大概描述如下图所示:

法律 3

每个阶段呢有开发人员对应之运动,以及QA人员对应之活动。

对于产品而言,每次版本迭代,都见面更:需求、开发、发布,最后推向日常营业,发布等虚线指向的需求等和普通营业等,并无是一个已阶段,而是不断迭代的历程。

这就是说测试人员是什么样开展全程软件测试活动的为?

店铺信息化的路

法律 4

2 需求等测试

以求等,开发人员、测试人员、QA人员根本做的作业,如下表所示:

阶段

开发人员

测试人员

QA人员

需求阶段

· 用户故事分析

· 用户故事估时

· 参与用户故事分析、挖掘故事含混性

· 参考经验库质疑开发的时间估算

· 保证确认需求活动符合需求管理过程

· 管理用户故事评审

· 管理需求变更

当测试人员的主要实施如下:

涉足用户故事分析、挖掘故事含混性

每当sprint会议达成,对用户故事进行剖析,检查功能性需求与非功能性需求是否描述清晰,其中好以非功能性需求当作验收要,例如一个用户故事:

“客户愿意增进响应时间”

测试人员应当协助开发人员消除故事的含混性:提高什么的应时间跟响应时间吗多少?可以建议改也:

“客户信息日常查询返回结果的应时间啊5s内”

征当“客户信息”模块,进行“普通查询”操作,返回结果的时以5s内,这个陈述句已经清晰表达了,也高达了排含混性的作用。同样,测试人员可以编写提高查询效率的用户故事:

“客户以信查询模块,进行日常查询,能够当5s内返回结果”

“备注:5s啊非功能性需求,也是验收要”

参考经验库质疑开发的流年量

以sprint会议及,开发人员根据涉出牌(团队温馨定义的条条框框,用扑克牌)估算日,当被起最终结果的时,测试人员应当对该展开质询。测试人员借鉴历史经验库:开发人员在某个方面的艺如何、该模块已发出过何种程度的败笔、修复缺陷的消耗时间是稍稍之类,综合考虑,提出问题,让开发估算最终之流年,尽可能考虑这些因素。当然,测试人员能够质疑之内部一个前提是:测试人员具备相关支付经历。

总结:在求等,测试人员要发挥作用,减少含混性需求引入到开发阶段、同时帮助开发做好时间量。

问题

法律 5

法律 6

 

3 开发阶段测试

当开发阶段,开发人员、测试人员、QA人员要做的事情,如下表所示:

阶段

开发人员

测试人员

QA人员

需求阶段

· 用户故事分析

· 用户故事估时

· 参与用户故事分析、挖掘故事含混性

· 参考经验库质疑开发的时间估算

· 保证确认需求活动符合需求管理过程

· 管理用户故事评审

· 管理需求变更

当测试人员的首要实施如下:

效果要确认

Xmind是一个不胜好用的脑图工具,通常以开发人员进行编码前,测试人员会对需求处理的用户故事,与开发人员进行确认,修正理解偏差,确保需求理解一致。

法律 7

 

希冀-5-脑图用例模板

测试用例设计

测试人员主要设计测试故事点,使用DSL(Domain Specific
language),对测试用例进行描述,包括三只基本要素:

Feature、Scenario、Example,补充要素:xmind、Requirement。

Feature:把测试分类及某某模块,并针对性是特性本身的事情目的进行有关描述,带进业
务目标,传递业务知识。

Scenario:标明这Feature的测试场景,可以行使文字描述步骤,或者使xmind脑图

讲述,场景中的数量使用Examples中列有的。

Example:引出具体的数码表格把用到之多少都来得下,避免同一步骤为测试数据
的变迁而再多任何造成冗余。

Xmind:脑图文件,展示测试故事点

Requirement:关联需求管理网的求id。

趁高效越来越红,敏捷测试为重新多受到了大家之关注。在此处,我想称一下自身于快项目受到相遇的一个自动化测试相关题材与我们怎么借助DSL领域专用语言来化解其。

对高效软件开发方法来肯定了解的食指且清楚,敏捷软件开发过程是一个迭代式交付的长河。每个迭代相当给较小型的交给周期。那么,为了配合往往的软件提交,敏捷测试相对于传统测试必须要举行相应的调动。这吗造成了快捷项目面临的测试面临几独特有的挑战:

  1. 多次的回归测试为担保每个迭代的结晶还是可授的
  2. 给整开发团队参与到测试活动被盖缩短质量信息之上报周期
  3. 被客户与届测试活动着来辅助提高测试的实用

自动化测试于诺本着反复之回归测试是挑战上从在老重要之意。自动化测试做不好,团队最后见面给每个迭代都见面加的回归测试工作量压垮。

本身更过的一个伙,在斯团中,大家好已经发现及了自动化测试的重要,在自动化测试高达之投入不遗余力。我们深信自动化功能测试增加及足够多之时段,它就是能够指导手动回归测试,保证总体交付过程顺利进行。

诚然,自动化测试刚起展开的上,我们低收入大多。每增加一个自动化测试,我们就能减小一些手动测试。自动化测试为咱们我们发出于丰硕的时光来手动测试那些还未曾来得及自动化的、难以让自动化的力量点及,而且还能够起时空和生机开探索性测试。这个结果给团队感到在特别美好,也为我们针对自动化测试坚信不疑

而是好景不添加,随着自动化测试的不断增多,我们会面临这样有题目:

  1. 自动化测试是环在实现细节进行的。随着数据之长,业务的概貌十分爱迷失在细节被。
  2. 以效能级别丧失了针对测试的寻踪。由于测试人员无法实际了解那些测试案例给自动化测试覆盖。每次回归的时刻,团队还需回归整个测试组。

于是,我们的手动测试越来越难获自动化测试的拉扯。它开始变成了档次之鸡肋。测试代码阅读困难、维护困难和测试结果的关押起吧坏困难。这直接促成了俺们不光使投入相当的岁月来充实自动化测试,也如投入多时日来读书并行使测试结果。

于是我们初步重复审视自动化测试的做法,继续找更好之法子。

迅猛,我们发现“能够走起”并无是好之自动化测试就需要的特色。让咱经过一样段测试代码来拘禁一下切实怎么回事。

selenium.open(“/”)
selenium.type(“id=username”, “myname”)
selenium.type(“id=password”, “mypassword”)
selenium.click(“id=btnLogin”)
selenium.waitForPageToLoad(30000)
assertTrue(selenium.isTextPresent(“Welcome to our website!”))

此测试着,我们率先打开了一个页面,在页面中找一个id为username的输入框,输入“myname”,然后还寻觅一个id为password的输入框,输入“password”,然后点击一个id为btnLogin的按钮,等待30秒后,断言页面应该出现的字。

咱得以视,这个测试的实现充分完整的叙述了测试的操作过程,是一个面向步骤而休是目的的描述。当然,稍加分析,我们吧足以拘留出来这测试的目的是测用户登录成功系统。

然,想象当我们有成千上万如此面向步骤来描述的测试时,要从中抽离出受多零碎的操作步骤所淹没的测试图,并拿测试的结果运用起来,其实并无那直观。而且,如果以测试中起了错,对于问题之求实职能点的定位为无是那爱。

再就是,并无是团中有的成员还产生能力看和编辑这样的测试。这毋庸置疑降低了团队成员对自动化测试的参与度。对于客户,自动化测试再次是一个黑盒子,做了啊,没举行什么,基本上整不彻底,更讲不齐与届自动化测试着,帮助提高测试的得力。

类现象,究其原因就是测试可读性太差,测试图未敷明确。可运行而爱读的测试才是好之自动化测试。这样才能够管其他时刻,我们无会见丧失对测试案例的跟踪及管理。测试人员随时都可通过快捷阅读测试,了解那些功能已让自动化测试覆盖,有效统筹手工测试的工作量。

岂提高测试的可读性呢?

我们的解决办法是DSL领域专用语言。

咦是世界专用语言?在马丁大叔的博客里发生比较详细的叙说。大致来说,领域专用语言就是是指向有世界的一定目的编程语言。不像Java、C#相当于通用语言,可以缓解任何领域的题材。领域专用语言由此投机独特的语法结构来讲述又接近受专业领域语言的事情。

于测试的叙述能够接近受测系统的圈子语言、使测试图获取清晰表达就是是咱们想只要取得的效用。DSL正好能帮忙我们实现。

叫咱又探之前的那段代码:

selenium.open(“/”)
selenium.type(“id=username”, “myname”)
selenium.type(“id=password”, “mypassword”)
selenium.click(“id=btnLogin”)
selenium.waitForPageToLoad(30000)
assertTrue(selenium.isTextPresent(“Welcome to our website!”))

是因为下的是通用语言,在咱们是一定的利用状况被展示过于细节化、过程化,不可知清晰表达测试图。

交换DSL,我们的测试就足以一直用验收规范的语言来叙述如下:

Given I am on login page
When I provide username and password
Then I can enter the system

这般测试的情就是直观多矣,还含了有些业务信息,让咱们了解是是于测试一个报到的场景,而无是轻易的输入信息,兼顾传递了业务知识的职责。至于这些DSL背后能够运转的代码,也受藏起来。如果是匪可知阅读原来那么的测试代码的人(不管是求分析人员或者客户还一些对准自动化代码关注于少的测试人员)想使加盟到自动化测试活动着展开报告,就不见面被DSL背后的代码带来的“噪音”所影响。

本来,在我们的实际使场景中,这个需求远非那么简单,我们的验收规范还见面考虑不同之数量论输入不同组合的用户名密码:

Given I am on login page
When I provide ‘david’ and ‘davidpassword’
Then I can enter the system
Given I am on login page
When I provide ‘kate’ and ‘kate_p@ssword’
Then I can enter the system

与重新多的测试数据。

这就是说这种景象下,仅仅是比浅显的语言或不够的,毕竟测试数量在那么张在。如果测试数量不能够压缩,维护起来仍非常烦。打独比方,如果系统的兑现成为了历次都设输入用户称、密码以及一个肆意验证码,我们虽需要在我们的自动化测试中改多地处,比较繁琐。因此,我们用在可读性比较好之自然语言描述的测试高达,把它们的抽象层次再加强一点。

有幸的是,我们当即挑选的DSL工具是cucumber,它除了提供了几只测试的讲述层次:Feature,Scenario,Steps,还提供了特别好之同等栽集体措施—数据表。

如此这般,我们的之自动化测试就得把之前的十分登录的效能根据特性、场景总结暨切实的步子分离开来,清晰的分支,同时采用数据表我们的测试精简成一层层给再次多次只是输入数据有所变化的操作过程,如下:

Feature: authentication
In order to have personalized information
I want to access my account by providing authentication information
So that the system can know who I am
Scenario Outline: login successfully
Given I am on login page
When I provide ‘<username>’ and ‘<password>’
Then I can enter the system
Examples:
|username |password |
|david |davidpass |
|kate |kate_p@ssword|

测试就生看起便再度畅快了。首先,用Feature关键字,我们拿测试分类及login这个坏特点下之,并对准之特性本身的业务目的进行相关描述,带上业务目标,传递业务知识;然后用Scenario关键字来增进挈领的表明我们这测试场景被开的凡测试登录成功之景况,并且将手续都写出来;最后,我们用Examples关键字引出具体的数表格把用到的数目还展示出,避免我们的一模一样步骤为测试数据的更动而又多全勤造成冗余。万一打了要求的变通,要求以提供用户称、密码以及验证码,那我们的测试呢就待变更较少之地方即够用了。

再精的是,用了这种数据表的法门,整个集团的通力合作效率提高了。对于刻画代码没有那么顺的测试人员来说,增加自动化测试为即是加又多测试数据,填充到多少表里就足以了。

就算这么,我们用DSL实现了而是尽的可读性强的文档。帮助了回归测试,降低了文档维护难度,也促进团队成员用测试来传递知识之能动,让更多人能与届测试着。

用例评审

重中之重是坚持同行评审的原则,主要以测试组内进行,负责该任务的开发人员也会见参与,简单来说就是指向测试用例进行查漏补缺的工作。

测试探索

进展了“功能要确认”和“用例评审”后,为了确保测试场景的覆盖率,需要更进行测试探索。在开发人员完成雏形之后,使用探索式测试的策略,对效果基本流程进行有目的的快速走查,挖掘功能不确定的地方同补测试场景,避免不确定的元素拖延到开发阶段后期,造成返工。

中:功能测试、Bug
Tracking、回归测试、系统测试、验收测试都是惯常测试工作所要环节。

燃尽图发布

此外,测试人员还有雷同宗重点工作,每日公布燃尽图,让集体询问时进度情况,总结问题

八方,寻求耗时跨预期时间任务之解决办法。

法律 8

图-6-燃尽图

图片特点:

1)剩余工时在计划条件上方,代表进度有推迟,应赶紧进度;

发觉此类题材,需要分析总结,原则是确保交到时,对相应职责进行调,拥抱变化,发现任务粒度太特别,该拆分的继续拆分;对于重构需要郑重,不要过分深入重构,给测试带来格外工作量,影响所有快,对于周版本而言,只有付出、测试在承诺的年月外得任务,才是真正好,仅仅开成功交算不上成功。

2)剩余工时在计划条件接近,代表开展不错,继续保持;

此刻啊用查阅在这种速度下,优先级赛之任务是否取得时保险,而非是为拍卖了简短任务才令燃尽图长的尴尬。往往有些开发人员,喜欢挑着任务来举行,把大概容易做、优先级的天职先成功了,因为这些总在预料内能够完成,所以最初燃尽图的取向看起没问题。

短经验库

每个团队都设有开发/测试新人和出/测试老人,当测试人员与出新人进行要求肯定的时候,还需要展开缺陷经验教训的唤起,避免多走弯路。

法律 9

升级开发自测质量

测试人员可以供有关checklist(大家好依据原作者提供的改为符组织的)帮助开发人员在编码过程被关注开发自测的中心,从而提升质量。

法律 10

 

希冀-8-web软件测试checklist

绵绵集成

动持续集成(Jenkins)平台,做到高效的构建出代码,自动的单元测试化,来增长开发代码的频率以及质地。

背单元测试的开发人员,会吸收失败构建的邮件;

当集成测试的开发人员,会收下失败构建的邮件;

担负自动化测试(Selenium)的测试负责人员,会收取失败构建的邮件;

这种艺术,确保单元测试、集成测试、自动化测试,有有关人口关爱和保安。

法律 11

贪图-9-持续集成

Sonar反馈

Sonar is an open platform to manage code quality. As such, it covers the
7 axes of code quality。

法律 12

sonar分析结果

测试人员主要反映问题如下:

Code coverage:团队要求代码覆盖率在80%上述;

Test success:团队要求测试成功率以100%;

Duplications:团队要求代码重复率在10%之下;

Violations:团队要求Major类别的代码规则缺陷在20之下;

付出集团要管每个环境之质目标,才会确保百分之百的质地目标。

小结:

测试人员与开发人员永远不是不共戴天关系,而是帮关系,确切来说是质天枰的简单边,任何单方面的劳作尚未办好,都见面失去平衡。

互联互通

法律 13

 

法律 14

法律 15

4 发布等级测试

当宣告等,开发人员、测试人员、QA人员要做的政工,如下表所示:

阶段

开发人员

测试人员

QA人员

发布阶段

· 上线申请

· 上线部署

· 服务监控

· 测试报告

· 线上功能检查

· 管理评审活动

· 管理文档产物

作测试人员的重要性实施如下:

测试报告

姣好验收测试,提供测试报告,给出测试数据量,例如:

  • 测试发现瑕疵总数:测试过程遭到起的去状态为“无效”、“不用转”的短处数量。
  • 测试发现严重缺陷往往:测试过程遭到发出的连删除状态呢“无效”、“不用转”的、且要为“Major”和“Critical”的弱项总数目。
  • 测试发现缺陷修复数:测试过程遭到出的状态为“已关闭”的缺点数量;
  • 非缓解缺陷往往:除去状态吧“无效”、“不用转”、“关闭”的短总数。
  • 症结修复率:(测试发现缺陷的修复数)÷(测试发现瑕疵总数)×100%
  • 沉痛缺陷率:(测试发现严重缺陷往往)÷(测试发现瑕疵总数)×100%
  • 沉痛缺陷修复率:(已修复的重缺陷往往)÷(测试发现严重缺陷往往)×100%
  • 测试需要覆盖率:已经测试需要单数÷需求总数×100%

短统计分析报告

另外,测试人员还有雷同项关键工作,对当下版本的弱项进行统计分析:

本缺陷级别统计:

 

Critical

Major

Medium

Minor

总计

首页

0

0

1

0

1

模块一

0

0

0

2

2

模块二

0

1

2

10

13

模块三

0

0

1

4

5

模块四

0

0

1

2

3

模块五

0

0

3

2

5

模块六

0

1

0

1

2

模块七

0

2

0

6

8

sonar

0

1

2

0

3

总计

0

5

10

27

 

法律 16

图-11-缺陷统计

以缺陷来源统计:

 

开发1

开发2

开发3

开发4

开发5

遗留

Critical

0

0

0

0

0

0

Major

1

2

0

0

0

2

Medium

1

7

0

1

0

1

Minor

1

7

4

6

3

6

总计

3

16

4

7

3

9

按缺陷状态统计:

缺陷总数

已关闭缺陷数

遗留

缺陷修复率

严重缺陷数

严重缺陷率

已关闭严重缺陷数

严重缺陷修复率

42

40

2

95%

5

12%

5

100%

测试进度及题材分析:

1.
由BUG的不得了级别分布来拘禁,Major级别以上的BUG占12%,占的百分比不愈,说明大部分的关键职能曾落实了;

2.
之中于sonar定义级别之先天不足,主要集中在代码规范及单元测试覆盖率,说明代码质量有待增进;

3.
本子测试的早期时间较丰满,后期随着开发提交成功的效果点增加,BUG数量增多,剩余测试时换得七上八下;

4.
以本测试中,发现测试环境存在同样潮代码被埋、两不好因开发人员操作失误影响测试执行的图景;

小结:

测试人员应当不断反馈、改进、总结每个版本有的题材(不管是毛病,还是经过中冒出的),并针对瑕疵进行辨析,总结出部分规律,帮助开发人员建立好的惯,改进代码的色。

5 日常营业等测试

每当日常营业等,开发人员、测试人员、QA人员主要做的事务,如下表所示:

阶段

开发人员

测试人员

QA人员

日常运营

生产故障登记

· 版本问题反馈和改进提议

· 生产故障分析

管理日常运营活动

平常营业等,并无是已阶段,即便需求、开发、发布等暂停活动,只要产品提供劳务,日常运营都存在正在。

用作测试人员的根本实施如下:

本子问题反馈及改进建议

对一般性营业产生的问题,总结反馈,提出改进建议,并且跟踪实施。

生产故障分析

支援开发排查生产故障,避免测试场景的落。

6 人力资源

软件测试并无是保险产品质量的结尾一鸣防线,测试人员也未是,测试人员的办事完全好由更加资深的开发人员来完成,不过具体总是残酷的,目前测试和付出之比例也:1:3,在成熟的团组织是这样子,另外一些尚于不停改进的组织,由于资源不足,可能失掉交1:7。开发人员在相当丰富的一段时间内不容许全代表测试人员,有个重大因素:思维方法不同,有句古话来描写:江山易改本性难移。当开发人员的思量方法改变之上,那就是成测试人员了,倒不如把测试人员独立出来又好,并且培养为开发人员一定之测试素养,这个针对保管产品质量都是生扶持的。

全程软件测试实践,强调的凡贯通每个阶段的测试活动,不论是支付、还是测试,要解两者的移位价,什么时候该做呀工作,什么工作该到位什么水平才算是好,保证每个环节的成色,才会管产品的全程质量,另外产品质量不是测试出的,而是构建过程遭到沉淀下来的,开发人员的造诣、测试人员的造诣、以及组织对出测试过程的珍惜程度,决定了产品质量。产品质量就不啻一片蛋糕,应当切分为小片,落实到每个人手里,让每个人尝试到甜头,担当起来。

7 TQM(全面质量管理) in Software

即时是一个延伸与涉及,过程如下:

法律 17

TQM是以产品质量为主干,建立从一仿照是严谨高效的质量体系,以提供满足用户需要之产品之满贯活动.

以软件业,软件质量得不顶加强关键因在质量观念的差,而用到质量管理的琢磨下于软件业,是增进软件出品质量、获取竞争优势的灵光手法。CMM不但对指导过程改进是平码特别好的工具,而且把宏观质量管理概念应用到软件上,实现自需求管理到品种计划、项目控制、软件取得、质量担保、配置管理之软件过程圆质量管理。CMM的考虑是一体从消费者需求出发,从都集团范围达到执行过程质量管理,正顺应了TQM的主干标准。因此,它的意义不光是对准软件开发的过程进程控制,最要之它们还是平种植高效的管住方法,有助于企业最老程度之下降资金,提高质量和用户满意度。

软件质量管理体现TQM的运行机制
软件质量管理是CMM四层被一个独自的KPA,其目的是一旦项目的软件质量管理活动是发生计划之、软件出品之品质目标是量化的以及被管理之。它以了完善质量管理活动之科学程序—PDCA(Plan、Do、Check、Action),即四单等级:

(1)
计划:即确定质量目标与落实者目标要以的法门。制定质量计划是满质量管理活动的底蕴。国家标准对质量下之概念也:
质量是产品还是劳动满足明确或含有需要力量的特性与特征的总和。

对于软件来说,软件质量则反映在质量特点上,ISO/IEC9126受到确定了6个品质特点,即功能性、可靠性、易用性、效率、可维护性和而一致性,每个特性包含若干子特性。设定质量目标即如果找到用户之质量需跟这些品质特点的相关性,并以那转会为开销进程中不过过量的技术指标或力指标,作为质量控制的基于。

上述的六要命特征属于软件之标属性,与用户满意度直接相关,可以因集团的对象和类别之特点建立质量模型,并以一定之法,如QFD(Quality
Function Deployment)、GQM(Goal Question
Metrics)等规定量化的身分目标,但随即在实际上工作备受屡屡是相当复杂与难以获得的。因此,更常用的做法是盖过程能力目标反映产品质量目标,一个杰出的能力指标虽缺点密度(即各级单位规模工作产品遭是的瑕疵往往)和呼应的等缺陷排错率,可以依据历史数据估算活之框框以及对象缺陷密度,从而对每个阶段发现的弱点数量进行支配。

(2) 实施
:即以约定计划、目标措施及其分工实际施行。为了在过程被控制软件的成色,需利用对应的手段于预约的阶段点或里程碑上进行软件工作产品质量的测,常用之方有
同行评审、原型评价、测试等。这些措施要由有限端针对软件的色进行度量,一凡中属性,即经过和活动自己可以度量的属性,例如工作产品之缺陷密度
;二凡外部属性,即与用户环境息息相关的性质,这些性在过程中再三难以度量,只有经过以品种的最初引入用户测试来予以评价,而深受用户参与开发过程,大大有利于产品质量的提高。

(3) 检查
:即把实施的结果与计划之求比,检查计划的履行情况跟执行之力量,是否上预期的靶子,并物色有由。在对品质度量的结果进行分析时,往往会用到一些统计工具及方法,如检查表、直方图、控制图、Pareto图、散布图、因果图、运行图等。这些工具得以帮助确定问题、评估现状、发现因居然形成下一样步道。

(4) 处理
:即下结论经验教训法律,将无缓解的题材作下一阶段制定计划之基于。CMM要求针对软件质量测量的结果分析后,应“采取适度的和软件质量计划相平等的法子,以便让出品之品质测量结果跟软件质量目标相适合”。


希望对君公司IT软件研发和质量管理起辅助。 其它您可能感兴趣的篇章:
速软件质量担保的计和履行
构建便捷之研发与自动化运维
IT运维监控解决方案介绍
IT持续集成的色管理
美貌公司环境和店家文化
店铺绩效管理体系的平衡记分卡
店家文化、团队文化和知识共享
大功能的团建设
团队目标及私目标
餐饮连锁企业IT信息化解决方案一

要是有想打听再多软件研发 , 系统 IT集成 , 企业信息化,项目管理,企业管理
等消息,请关注本身之微信订阅号:

法律 18

 

作者:Petter Liu
出处:http://www.cnblogs.com/wintersun/
正文版权归作者和博客园共有,欢迎转载,但未经作者同意要保留这个段子声明,且以文章页面明显位置于来原文连接,否则保留追究法律责任的权利。
拖欠篇为又宣布在自己的独自博客中-Petter Liu
Blog。

统一看

法律 19

法律 20

集合身份管理

法律 21

数据管理型

法律 22

法律 23

信用社数目并业务架构

法律 24

业务流程框架

法律 25

业务流程模型

法律 26

生性流程支持

法律 27

法律 28

超越业务的业务流程组合

法律 29

EBS总线

法律 30]

SOA架构上视图

法律 31

BI商业智能架构

法律 32

技术劳务架构

法律 33


可望对您公司企业信息化IT架构和管理来赞助。 其它您可能感兴趣的文章:
智能企业同信息化之一
由企业家基本素质想到的
飞软件质量担保的道和履行
构建便捷之研发及自动化运维
IT运维监控解决方案介绍
IT持续集成的色管理
人才公司环境和企业文化
店家绩效管理体系的平衡记分卡
号文化、团队文化以及文化共享
强功能的集团建设
伙食连锁公司IT信息化解决方案一

假如产生想打听再多软件研发 , 系统 IT集成 , 企业信息化,项目管理,企业管理
等新闻,请关注自身的微信订阅号:

法律 34

 

作者:Petter Liu
出处:http://www.cnblogs.com/wintersun/
正文版权归作者和博客园共有,欢迎转载,但未经作者同意要保留这个段子声明,且以篇章页面明显位置给出原文连接,否则保留追究法律责任的权利。
欠篇也以发表于自我之独门博客中-Petter Liu
Blog。

留下评论