- 博客(38)
- 收藏
- 关注
RSS订阅转载 高效梳理测试范围的方法——业务格式图管理方案
一、背景我们在项目进展的过程中，是不是还遇到了这些问题：1、项目有deadline，还没开始讨论需求已经限定死了发布时间，里程碑时间点促使进度往前赶，而往往项目还没有成熟到可以推进的程度2、为赶进度项目成员之间的沟通会减少和不明确，每个人的理解出入就会越大，返工的隐患就出现了3、项目人员变更，替换的人员对项目并不是非常了解，理解成本耗费大量项目时间4、开发过程中的方案变更，没能
2013-03-13 17:26:40
1560
转载 这些年我们一起经历的矛盾
测试1. 手工 VS 自动化2. 指导性的测试 VS 探索性测试3. 低成本的模拟测试 VS 高成本的真实环境 测试4. 报bug VS 口头沟通5. 内部测试尽量全 VS 开放外部参与测试6. 独立自主 VS 外包合作流程1. 糙快猛 VS 精慢柔(scrum, agile...)2. 有文档 VS demo 为王3. 需要测试的角色 VS
2013-03-13 17:16:23
517
转载 管理测试机器的使用效率
伴随着业务测试的开展，测试使用的机器逐渐增加：性能测试、全网回归、部署测试工具的机器等。当测试机器的规模逐步增加，达到上百台甚至上千台时，如何对这些机器进行有效的利用就面临着诸多挑战：机器已申请，但长期未使用机器处于使用状态，但资源浪费严重部门整体的资源使用率无法估量我们提出了机器利用率这个概念，来对机器的使用情况进行计算、统计和分类，提供直接有效的数据给各Owner，以期
2013-03-13 17:13:43
842
转载 团队（公司）博客的影响力
当我选择淘宝的测试工程师的职位时，我就在google上搜索 淘宝+测试 第一个就是这个博客，我惊羡于她的口号---做行业标准；日后几乎每天都会看，而几乎每一两天就会有新文章，这让我觉得这不仅仅是一个“活着”的博客，这更说明她背后的团队是非常有活力的，这也是我选择做淘宝测试的一个原因。 而今我就要在这个对我有过影响的博客上写篇文章的时候，我能想到这只是一篇文章，可能空洞没有新意，
2013-03-13 16:35:08
640
转载 什么是“测感”
什么是测感呢？举几个例子：“在一堆乱七八糟的工牌中每个人都能够快速找到自己的工牌。用的是什么算法？”“如果一群姑娘站在你面前，你一眼看过去，就知道哪个长的漂亮，哪个是你喜欢的哪一型的，不需要用尺子量一量身高，再量一量三围。又用了什么算法？”“一接电话就知道是身边的哪位朋友，这时又用了什么算法？”，“盲人知道自家客厅，卧室的哪个方位，为什么看不见也能知道呢？”所以，测感，直面解释，就是你一眼看上
2013-03-13 16:31:43
616
转载 第一章 Web MVC简介 —— 跟开涛学SpringMVC
Web MVC简介1.1、Web开发中的请求-响应模型：在Web世界里，具体步骤如下：1、 Web浏览器（如IE）发起请求，如访问http://sishuok.com2、 Web服务器（如Tomcat）接收请求，处理请求（比如用户新增，则将把用户保存一下），最后产生响应（一般为html）。3、web服务器处理完成后，返回内容给web客户端（一般就是我们的浏览器），客户端
2013-03-06 13:56:15
511
转载 HTTP协议之压缩
之前写过一个篇 【HTTP协议详解】 ，这次继续介绍HTTP协议中的压缩。本文会使用Fiddler来查看HTTP request和Response, 如果不熟悉这个工具，可以先参考[Fiddler教程]HTTP压缩是指: Web服务器和浏览器之间压缩传输的”文本内容“的方法。 HTTP采用通用的压缩算法，比如gzip来压缩HTML,Javascript, CSS文件。 能大大减少网
2013-03-06 11:40:02
551
转载 HTTP协议之基本认证
http协议是无状态的， 浏览器和web服务器之间可以通过cookie来身份识别。 桌面应用程序(比如新浪桌面客户端， skydrive客户端)跟Web服务器之间是如何身份识别呢？ 什么是HTTP基本认证桌面应用程序也通过HTTP协议跟Web服务器交互， 桌面应用程序一般不会使用cookie, 而是把 "用户名+冒号+密码"用BASE64算法加密后的字符串放在http request
2013-03-06 11:06:13
479
转载 谈谈分析模型的那些事儿 之 职责驱动设计
前面讲了为什么我们要使用分析模型，现在我们看设计分析模型的基本原则。分配职责和职责驱动设计 我们在开始分析模型的时候，首先要弄清楚一个非常重要的原则，就是以职责为中心。OO分析设计的核心原则之一，就是软件系统中的所有元素都必须具有高度相关的职责，也就是说，软件系统中所有的模块、包、对象类，都应当拥有一个清晰的职责，并且与它相关的所有元素（即模块中的所有包、包中的所有对象类、对象类中的所有属
2013-03-06 10:41:15
1254
转载 谈谈分析模型的那些事儿 之 开始分析
当需求分析结束、需求确认完成、需求讨论告一段落的时候，我们的需求分析员拿出了厚厚的一打用例分析模型、领域设计模型，需求分析阶段结束，开始进入开发阶段。但是，这时候虽然需求分析阶段结束了，却千万不要以为需求分析就结束了，如果你还这样认为，说明你还没有摆脱瀑布式开发的思维。瀑布式开发的思维的关键点就是认为，需求分析阶段应当完成所有的需求分析和确认的工作，否认需求分析阶段以后还会变更需求。拥抱变化是现代
2013-03-06 10:28:13
582
转载 谈谈领域模型的那些事儿 之 从领域获取知识
前言：你写过用例模型吗？也许有；你写过领域模型吗？也许还没有。在这里，我们可以尝试写写领域模型，看看它的作用、带给我们的好处。随着RUP在中国的传播，人们开始尝试用RUP统一过程来指导软件的设计和开发，但这些尝试并不成功。比较普遍的，大家都开始使用用例模型来进行需求阶段的分析和设计了。当然，能做出第一步已经非常不错了，但这远远不够。要做好需求分析，用例模型可以帮助我们分析清楚软件需求中要求
2013-03-06 10:27:05
2232
转载 谈谈领域模型的那些事儿 之 注意什么
前面我们讲了如何从业务领域获取知识，创建领域模型，那么建立领域模型应当注意什么呢？建立领域模型应当注意的问题1．领域模型不是数据模型，也不是软件对象模型一个创建领域模型的过程中非常容易犯的错误就是，将领域模型当成了数据模型，或者软件对象模型。领域模型，又称为概念模型、领域对象模型或分析对象模型，是“专用于解释业务领域中重要的‘事物’和产品”[RUP]。领域模型专注于现实世界的对象（概念
2013-03-06 10:07:53
1234
转载 谈谈用例模型的那些事儿 之 注意什么
给大家几个建立用例模型中常出现的问题和应对遵循的原则：一．如何发现用例经过以上的讲解，相信大家对建立用例模型有了一个整体的概念，然后开始着手练习绘制用例模型。这时候，一个非常严峻的问题出现了：如何发现用例。大师曾经给出了答案，大致意思就是：首先选择系统边界，然后确定主要参与者，定义满足用户目标的用例，为其命名。然而，我在实践中证明，这套方法过于理论，并不实用。也许，我们换一种思路会更加符合
2013-03-06 09:39:01
1134
转载 谈谈用例模型的那些事儿 之 用例图
——对用例模型及其应用的一次有益的探讨前言：这是一次对用例模型的探讨。怎样建立用例模型，怎样编写用例说明，它与需求规格说明书有什么区别，它能替代需求规格说明书吗？也许在这里可以找到你要的答案。进入软件业稍微久一点儿的人恐怕都不会陌生，软件开发的最初阶段都是谈需求、写需求规格说明书。需求规格说明书是与客户最终确认到纸上的，非常正式的公文。软件开发应当做什么，做成什么样子，什么东西不做，项
2013-03-05 11:15:12
5900
转载 我们应当怎样做需求确认：评审与签字确认会（24）
时间过得真快，经过一系列需求研讨、需求分析和整理确认，我们整理出了需求列表，编写出了需求规格说明书，一切似乎该到结束需求分析阶段的时候了。但是，敏捷大师的一句话让我们彻底心凉到了骨头里。敏捷大师说了，我们不可能在需求分析阶段完成所有的需求分析工作，它将延续到设计、开发，甚至测试阶段。一直以来，我对这句话非常困惑。既然需求分析阶段不能完成所有的需求分析工作，那么完成多少才算结束呢？80%？6
2013-03-05 10:24:56
1213
转载 我们应当怎样做需求确认：需求规格说明书（23）
曾经有项目组拿着用户编写的原始需求就开始开发，随后状况不断，一次令人崩溃的研发过程。拿着用户编写的原始需求，编写我们自己的需求规格说明书，之所以重要，就在于用户编写的原始需求，是脱离了技术实现，编写的一份十分理想的业务需求。理想与现实总是有差距，我们之所以要编写自己的需求规格说明书，就是要本着实事求是、切实可行的态度，去描述用户的业务需求。那些不可行的需求被摒弃，或者换成更加可行的解决方案。这就是
2013-03-05 10:18:48
839
转载 我们应当怎样做需求确认：快速原型法（22）
常常听到许多朋友跟我埋怨，需求分析之难，就在于用户自身就常常弄不清楚自己的需求。起初在需求确认的时候说得好好的，一到软件上线的时候就不是那么回事了，这可没法整。但我们只要坐下来仔细分析就会发现，在需求分析的时候我们跟用户是在空对空地讨论问题。用户不是专业人士，他也搞不清楚软件到底会做成啥样，所以你跟他确认的时候他就点头了。但是，用户不是傻子，当你软件上线时，他拿到了实物了，知道软件做成啥样了，一旦
2013-03-05 10:10:18
916
转载 我们应当怎样做需求确认：一个需求列表的实例（21）
现在我举一个具体实例来看看需求列表是怎样编写的吧。这是一个公司内部的评审系统，它分为制订评审计划、执行评审、制作评审报告与问题跟踪四部分。经过初次与评审人员的业务讨论以后，我们整理出这样一个需求列表：1．评审发起人填写一份评审计划，详细记录评审时间、评审内容、评审者、评审地点，制订评审组长，并预计评审工作量，发起一个评审任务。2．评审者在收到邮件后，进入评审任务中，对评审内容进行评审，
2013-03-04 17:28:10
2043
转载 我们应当怎样做需求确认：需求列表（20）
需求分析是一个我们与客户不断沟通的过程，这个过程就如同我们与老板的一次对话。老板把你叫去，给你交待了一大堆任务。我们首先是仔细聆听任务的内容，然后整理个一二三四。然后我们复述一遍老板的意思：“老板，我复述一遍，您看看我理解得对不对。首先，您要求我×××，然后×××，最后×××。”老板：“恩，就是这意思，你照着办吧。”之后，我们开始了我们的工作。这个复述的步骤相当重要，因为人与人的沟通最大的问题就是
2013-03-04 17:19:40
933
转载 我们应当怎样做需求分析：非功能需求（19）
我曾经看过许多关于需求分析的书籍，老外写的，国人写的，都有。但我总体就是一个感觉：累。各种各样的分析、各种各样的视图，让人眼花缭乱。为什么会这样呢？不得不说，需求分析是一个太宽泛的概念了，不同的行业（商业的、管理的、游戏的），不同类型的软件（底层的、桌面的、网络应用的），不同的设计方式（面向过程的、面向对象的），需求分析的过程都存在着巨大的差异。要制订放之四海而皆准的方法谈何容易。即使同一类型的软
2013-03-04 17:18:11
965
转载 我们应当怎样做需求分析：领域驱动设计（18）
2007年，世界级的软件分析大师Eric Evans发表了他的经典著作《领域驱动设计》，进而形成了一套独特的软件分析与设计方法，简称为DDD（Domain-Driven Design）。在领域驱动设计思想中，有许多是涉及到需求分析领域的先进方法，我把它归纳为有效建模、统一语言和持续学习。有人说：大师所站的高度实在太高了，是生活在太空里的，所以我们要追随大师就只有因为缺氧而死掉。我认为这句话
2013-03-04 16:59:25
517
转载 我们应当怎样做需求分析：原文分析法（17）
原文分析法（Textual Analysis），是在用例说明与流程分析的基础上进行的业务领域分析，是一项在需求研讨会后整理和分析需求的工作。当我们完成了用例图的绘制，为每个用例编写出用例说明以后，原文分析的工作就可以开始了。要讲解原文分析，我们还是用一个实例更简单明了：这是一个实际项目的用例说明。在进行原文分析的时候，我们首先要做的事情就是对用例说明中事件流部分的文字描述，提取其中
2013-03-04 16:48:51
417
转载 我们应当怎样做需求分析：业务领域分析（16）
在需求分析工作中，最后一项分析工作就是业务领域分析啦。业务领域分析，就是对需求分析中涉及到的业务实体，以及它们相互之间关联关系的分析。前面我们谈到了功能角色分析，或者说用例分析，它是从整体的角度对整个系统人机交互的分析与整理。随后我们谈到了业务流程分析，它是在对系统人机交互的分析与整理的基础上，更加细致的去分析和整理那些业务流程，以及组成这些流程的一个个业务操作。业务流程分析是对系统进行的一种动态
2013-03-04 16:03:21
952
转载 我们应当怎样做需求分析：行动图和状态图（15）
前面，我们耗费了大量的篇幅来讨论用例分析及用例图。用例图，无疑是功能分析、角色分析，以及流程分析的利器，它将我们要开发的系统，清晰而详尽地描述出来。但是，正如任何事物都有两面性，用例图也不例外，也有自己不利的一面。在我看来，这集中体现在两个方面：只见树木不见森林、不生动形象。什么叫“只见树木不见森林”呢？就是说，用例说明中对业务流程的描述，过早地将系统的整体流程，分散到了各个用例中了，丢失
2013-03-04 15:58:28
1135
转载 我们应当怎样做需求分析：子用例与扩展用例（14）
用例模型作为UML中4+1视图中非常重要的一员，非常集中地体现了面向对象的分析与设计思想。用例模型将现实世界中连续的一个一个业务流程，按照场景划分到了一个一个的用例中。由于场景的出现，使得用例中的业务流程存在着高度的内聚性，从而成为了日后各种对象的雏形。同时，在用例分析中，又将那些存在于各个用例中的，相同或相近的业务操作提取出来，形成一个一个的子用例或扩展用例，又体现了面向对象设计中的复用性。现在
2013-03-04 15:50:19
692
转载 我们应当怎样做需求分析：查询报表分析（13）
在我以往的用例分析中，使用这样格式的用例模式，对于大多数业务操作流程来说是得心应手的，但对于有些功能来说总感觉不对劲。感觉不对劲的，就是那些查询、汇总与报表功能。对于这部分功能，需要我们描述的不是什么操作流程，而更重要的是那些数据项、数据来源、报表格式、数据链接，以及使用者、使用频率的说明。而这些，在以往的用例说明格式中统统都没有，怎么办呢？俗话说“东西是死的人是活的”，把我们的用例格式改改吧。
2013-03-04 15:46:29
558
转载 我们应当怎样做需求分析：业务流程分析（下）（11）
另外，业务流程分析的另一个重要的分析内容就是流程差异化分析。不同的领导有不同的思路，不同的单位有不同的情况。因此，我们在进行流程分析的时候，常常面临流程差异化的问题。我们说企业信息化就是一次改革，这首先体现在业务流程的规范化操作，也就是消除这种流程差异。但不同的单位有不同的情况，这特别体现在不同地域和文化的不同，又常常造成这种流程差异不可避免。分与合，分治与一统，常常是一个都要兼顾的问题，非常微妙
2013-03-04 15:33:41
843
转载 我们应当怎样做需求分析：业务流程分析（上）（10）
我们将从客户调研现场拿回来的需求，经过一番功能角色分析，整个系统的整体脉络与轮廓已经被勾画出来。在这个过程中，我们首先将系统划分成了几个功能模块（如果系统规模较大，还应先划分为几个子系统，然后再划分出各个功能模块）。然后，我们为每个功能模块绘制用例图。用例图是站在用户角度去观察的系统，即系统为用户提供了哪些功能，这就是功能分析。同时，这些功能是为哪些用户服务的，这就是角色分析。我们绘制的用例图应当
2013-03-04 15:26:04
1387
转载 我们应当怎样做需求分析：功能角色分析与用例图（9）
在我们进行一系列需求调研工作的同时，我们的需求分析工作也开始启动了。需求调研与需求分析工作应当是相辅相伴共同进行的。每次参加完需求调研回到公司，我们就应当对需求调研的成果进行一次需求分析。当下一次开始进行需求调研时，我们应当首先将上次需求分析的结果与客户进行确认，同时对需求分析中提出的疑问交给客户予以解答。这就是一个需求捕获->需求整理->需求验证->再需求捕获的过程。但是，当我们经过一番
2013-03-04 15:16:50
2364
转载 我们应当怎样做需求调研：需求捕获（下）（8）
另一种就是客户压根儿没有想到的需求。也许你会提出这样的疑问，客户压根儿没有想到的需求我们还提出来做什么？这种压根儿没有想到的，实际是在业务需求阶段压根儿没有想到的，并不代表最终都没有想到。很多开发人员总在埋怨，说客户需求总是在软件项目的后期改来改去，为什么？客户并不是软件研发领域的专业人员。在业务需求阶段，由于没有可以展示和操作的实物，客户总是在空对空的凭空想象今后的软件应当做成什么样子。这就注定
2013-03-04 11:07:56
465
转载 我们应当怎样做需求调研：需求捕获（上）（7）
前面我们讨论了，需求分析工作是一个迭代的过程：需求捕获->需求整理->需求验证->再需求捕获······需求捕获是这个迭代过程的开始，也是整个需求分析工作中最重要的部分。没有捕获哪来后面的整理与验证工作？但是，非常遗憾，按照我以往的经验，需求捕获是我们最薄弱的环节。前面我提到的许许多多项目开发的问题都可以归结为需求分析的问题，而许许多多需求分析的问题又都可以归结为需求捕获不完整的问题。需求捕获是整
2013-03-04 11:01:47
480
转载 我们应当怎样做需求调研：迭代（6）
前面我一直在反复强调这样一个观点，需求分析不是一蹴而就的，是一个反复迭代的过程。它将从第一次需求分析开始，一直持续到整个项目生命周期。为什么这样说呢？让我们一起来分析分析。在第一次的需求分析阶段，我们在一段时期内需要与客户进行反复地讨论，这个过程往往是这样一个反复循环的过程：需求捕获->需求整理->需求验证->再需求捕获••••••需求捕获，就是我们与客户在一起开研讨会，讨论需求的
2013-03-04 10:58:37
359
转载 我们应当怎样做需求调研：需求研讨（5）
前面我们探讨了业务研讨会应当怎样组织，下面我们再具体讨论一下我们应当怎样与客户讨论业务需求。如果说组织业务研讨会是项目经理的功底，那么讨论业务需求就是需求分析人员的功底。以往我们常常认为，需求分析是一件最简单的事情。客户说他们需要做一个什么软件，有些什么功能，我们照着做就可以了，所谓的需求分析员就是需求的记录员。我要说，这是一个极大的错误，许多失败的软件项目，或者说软件项目中的需求问题，大
2013-03-01 18:33:35
406
转载 我们应当怎样做需求调研：研讨会（4）
经过一番努力，我们终于在客户中找到了一批人，可以解答困扰我们多时的业务问题了，真是不容易呀。但是，如何以合适的时间、合适的地点、通过合适的形式与客户研讨业务需求，是摆在项目经理面前的一道难题。在我所经历的项目中，业务研讨会没有一个是相同的。我曾经做过一个政府机关的项目，在这个项目中，从总局到省、地市、区县，形成了一个多组织机构的管理系统。虽然全国管理流程大体相同，但各地因各地实际情况的不同
2013-03-01 15:21:00
558
转载 我们应当怎样做需求调研：拜访（3）
项目组经过一番努力，获得了一些初步的成果。首先是给客户留下了一个良好的印象，这是一个开端，但要在他们心目中树立自己的职业威信还要看你今后的表现。同时，我们与客户一起为项目制订了短期与长期目标。不要小看了这些目标，它们就是我们的尚方宝剑。正是因为有了它，今后项目中的有关各方就应当协助实现这个目标。我们应当清晰地向客户表达这样一个意思，要完成这样的目标，不是某一方的努力，而是双方共同努力的结果。这也是
2013-03-01 15:13:15
446
转载 我们应当怎样做需求调研：初识（2）
很多需求分析的工作是从需求调研开始的，我们就从这里说起吧。需求调研是需求分析最重要的一环，也最集中地体现了需求分析的特点——既是一份体力活儿，更是一份技术活儿。它既要求我们具有一种理解能力、设计能力，更要求我们具有一种与人交往、沟通的能力。在一个阳光明媚的下午，项目经理带领着项目组成员，参加了客户组织的见面会，一个新的软件研发项目就这样开始了。双方在一种友好的气氛中进行，相互寒暄，介绍与会
2013-03-01 15:09:20
454
转载 我们应当怎样做需求分析（1）
又到新年了，日历又要从2011年翻到2012年了，这使我有太多的感慨，进而勾起了对太多往事的回忆。过去的10年，毫无疑问是中国软件业发展最快的10年。当我们刚刚毕业的时候，还在使用VB、PB开发一些简单的数据库应用，而现在却几乎看不到它们的踪影，换来的是诸如J2EE和.NET这样的大型web应用。而这期间，RUP、XP、敏捷开发、持续集成••••••一个接一个的新概念层出不穷，令人眼花缭乱。现在想
2013-03-01 14:54:58
467
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人