qileilove

　好久没写博客了，除了是工作较忙的原因外，其实是也一直在想如何整合我所有的开发经验及技术积累，开发过很多Winform共享软件、ASP.NET的WebForm项目，发现很多东西是相互关联很紧密的，但往往我们太忙太懒，要好好整理，并整理出棒棒的一般比较难，但我们没有停步，梦想总会慢慢接近并实现。在做了很多项目之后，发现人的惰性或者惯性很大，因此有机会得好好整理下开发的成功，优化再优化，用的时候就越来越顺手了。

　　在所有开发过的项目过程，很多如权限管理、字典数据管理模块，都是非常常用的模块，本文主要想介绍下提炼出来，各个项目均可通用的字典数据管理系统（或者叫做模块更为适合），在介绍之前，我想介绍下我的整合路线及一些想法，如下所示：

　　其中框架中所有介绍的内容均为现有开发框架中有的东西及特性，如果要了解Winform框架的多维特点，可以现在最新的共享软件《仓库管理系统》，具体可以参考文章《从开发的软件《备件仓库管理系统》总结的一些经验》进行了解，该共享软件除了整合众多优秀的功能外，一个特点就是数据管理模块也得到了升华。

　　在Winform框架中，其中权限管理系统、字典管理系统，都是可以做成独立的程序来使用，而且应该可以在程序中引用来查询或者获取相关的字典数据，如找某个键值的字典列表作为下拉列表，而且由于实际项目总，有点是SqlServer、有的是Access数据库的，所以支持多数据库是最好的选择。

　　在字典数据数据管理工程项目中，我们看到有两个不同的数据访问层，工厂模式通过不同的配置，调用不同的数据访问层，从而实现SqlServer、Access等数据库的支持，当然可以扩展更多的数据库支持，我们先来看看工程项目的视图如下所示：

配置文件如下所示

　丢失更新是数据中一个比较常见的经典问题，在做项目时我们有时可能会没有注意到这个问题，但这个问题相当重要，有时会带来比较严重的结果。下面我们就来讨论下这个丢失更新。

　　一、什么是丢失更新：

　　用一个操作过程来说明：

　　（1）会话Session1 中的一个事务获取（查询）一行数据，并显示给一个用户User1。

　　（2）会话Session2 中的另一个事务也获取这一行，但是将数据显示给另一个用户User2。

　　（3）User1 使用应用修改了这一行，让应用更新数据库并提交。会话Session1 的事务执行完毕。

　　（4）User2 也修改这一行，让应用更新数据库并提交。会话Session2 的事务执行完毕。

　　这个过程就叫做“丢失更新”，因为第（3）步做的操作会全部丢失（被第4步操作覆盖），最终数据库只会保存第（4）步的更新结果。这个情况在有些系统中可能不会有影响，但在有些系统中可能就影响很大了，举个简单的例子：

　　财务系统加工资，若公司本次调薪决定给员工张三加1k人民币，财务部两名操作人员A和B，过程情况若是这样的：

　　1）A操作员在应用系统的页面上查询出张三的薪水信息，然后选择薪水记录进行修改，打开修改页面但A突然有事离开了，页面放在那没有做任何的提交。

　　2）这时候B操作员同样在应用中查询出张三的薪水信息，然后选择薪水记录进行修改，录入增加薪水额1000，然后提交了。

　　3）这时候A操作员回来了，在自己之前打开的薪水修改页面上也录入了增加薪水额1000，然后提交了。

　　其实上面例子操作员A和B只要一前一后做提交，悲剧就出来了。后台修改薪水的sql：update 工资表 set salary = salary + 增加薪水额 where staff_id = ‘员工ID’。这个过程走下来后结果是：张三开心了这次涨了2k，操作员A和B都郁闷了。

　　二、解决思路：

　　基本两种思路，一种是悲观锁，另外一种是乐观锁； 简单的说就是一种假定这样的问题是高概率的，最好一开始就锁住，免得更新老是失败；另外一种假定这样的问题是小概率的，最后一步做更新的时候再锁住，免得锁住时间太长影响其他人做有关操作。

　　三、解决方案1（悲观锁）

　　a）传统的悲观锁法（不推荐）：

　　以上面的例子来说明，在弹出修改工资的页面初始化时（这种情况下一般会去从数据库查询出来），在这个初始化查询中使用select ...for update nowait， 通过添加for update nowait语句，将这条记录锁住，避免其他用户更新，从而保证后续的更新是在正确的状态下更新的。然后在保持这个链接的状态下，在做更新提交。当然这个有个前提就是要保持链接，就是要对链接要占用较长时间，这个在现在web系统高并发高频率下显然是不现实的。

　　b）现在的悲观锁法（推荐优先使用）：

　　在修改工资这个页面做提交时先查询下，当然这个查询必须也要加锁（select ...for update nowait），有人会说，在这里做个查询确认记录是否有改变不就行了吗，是的，是要做个确认，只是你不加for update就不能保证你在查询到更新提交这段时间里这条记录没有被其他会话更新过，所以这种方式也需要在查询时锁定记录，保证在这条记录没有变化的基础上再做更新，若有变化则提示告知用户。

　　四、解决方案2（乐观锁）

　　a）旧值条件（前镜像）法：

　　就是在sql更新时使用旧的状态值做条件，SQL大致如下 Update table set col1 = newcol1value， col2 = newcol2value…. where col1 = oldcol1value and col2 = oldcol2value….，在上面的例子中我们就可以把当前工资作为条件进行更新，如果这条记录已经被其他会话更新过，则本次更新了0行，这里我们应用系统一般会做个提示告知用户重新查询更新。这个取哪些旧值作为条件更新视具体系统实际情况而定。（这种方式有可能发生阻塞，如果应用其他地方使用悲观锁法长时间锁定了这条记录，则本次会话就需要等待，所以使用这种方式时最好统一使用乐观锁法。）

　　b）使用版本列法（推荐优先使用）：

　　其实这种方式是一个特殊化的前镜像法，就是不需要使用多个旧值做条件，只需要在表上加一个版本列，这一列可以是NUMBER或 DATE/TIMESTAMP列，加这列的作用就是用来记录这条数据的版本（在表设计时一般我们都会给每个表增加一些NUMBER型和DATE型的冗余字段，以便扩展使用，这些冗余字段完全可以作为版本列用），在应用程序中我们每次操作对版本列做维护即可。在更新时我们把上次版本作为条件进行更新。

　　c）使用校验和法（不推荐）

　　d）使用ORA_ROWSCN法（不推荐）

　　五、结论：

　　综上所述，我们对丢失更新问题建议采取上面的悲观锁b方法或乐观锁b方法（蓝色字体已标注），其实这两种方式的本质都一样，都是在更新提交时做一次查询确认在更新提交，我个人觉得都是乐观的做法，区别在于悲观锁b方法是通过select..for update方式，这个可能会导致其他会话的阻塞，而乐观锁b方法需要多一个版本列的维护。

　　个人建议：在用户并发数比较少且冲突比较严重的应用系统中选择悲观锁b方法，其他情况首先乐观锁版本列法。

1、系统日志

　　/var/log/messages不仅是服务器的系统日志，很多时候它也包括许多服务的日志，所以它被称为“杂货铺”，建议重点关注。大家一般都喜欢用以下命令来看最后10条日志：tail -n10/var/log/messages。

　　其实还可以将一段日志保存成文件（Xmanager3.0企业版的shell也有日志录像截取功能），或者直接用vim来处理。我以前配置主从复制的bind服务器时，有时会因为权限的原因报错，这时就可以在一台报错的服务器上用命令tail -f/var/log/messages实时查看服务器的日志变化情况，从而查找错误的蛛丝马迹。事实证明，效果很好，而且将此命令用于lvs+keepalived的排错效果也不错。其他服务器配置排错以此类推，这个做法也推荐读者掌握。

　　2、系统安全日志

　　/var/log/secure记录登录系统存取数据的文件，例如POP3、SSH、Telnet、FTP等都会被记录，我们可以利用此文件找出不安全的登录IP。目前比较流行的SSH防暴力破解工具DenyHosts主要也是读此文件。另外，我写了一个原理类似的shell安全脚本，用于线上服务器，在后面的章节跟大家分享。

　　3、记录登录者的数据

　　/var/log/wtmp记录登录者的信息数据，由于此文件已经被编码过（为二进制文件），想用cat等命令直接查看是不行的，必须使用last指令来取出文件的内容，如下所示：

　　4、记录登录时间

　　/var/log/lastlog记录每个使用者最近登录系统的时间。因此当使用者登录时，就会显示其上次登录的时间，你应该注意一下这个时间，若此时间不是你上次登录的时间，表示账号可能被人盗用了。此可执行文件可用/usr/bin/lastlog指令读取（在FreeBSD8&FreeBSD8.1下为/usr/sbin/lastlogin）。使用此命令后的记录如下所示：

　　直至目前，我国还没有适应国情的、系列化协调配套的、工程化的软件生产过程管理、软件质量评测、控制技术规范和法律规程指导，为此，我国急需以大力发展软件第三方测试工程为基础，建立、健全我国软件工程监理体制。

　　第三方测试有别于开发人员或用户进行的测试，其目的是为了保证测试工作的客观性。从国外的经验来看，测试逐渐由专业的第三方承担。同时第三方测试还可适当兼顾初级监理的功能，其自身具有明显的工程特性，为发展软件工程监理制奠定坚实的基础。

　　第三方测试工程主要包括需求分析审查、设计审查、代码审查、单元测试、功能测试、性能测试、可恢复性测试、资源消耗测试、并发测试、健壮性测试、安全测试、安装配置测试、可移植性测试、文档测试以及最终的验收测试等十余项。

　　测试并不仅仅是为了要找出错误。测试方还需要对错误进行归类和总结，通过分析错误产生的原因和错误的分布特征，可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进，更好地帮助用户。根据软件工程的要求，测试工作应贯穿开发的全过程，如右图所示。

　　从测试流程中可以看出，编码和单元测试基本上属于程序的调试，一般由开发方自己进行。作为第三方测试，定位在系统测试和集成测试最为有效。但是，为了得到高质量的软件，第三方也要适当介入编码与单元测试，能够更好地保证测试的有效性、准确性和可信性。

　　认清“第三方”的责任

　　第三方测试以合同的形式制约了测试方，使得它与开发方存在某种‘对立’的关系，所以它不会刻意维护开发方的利益，保证了测试工作在一开始就具有客观性。第三方一般都不直接参加开发方系统的设计和编程，为了能够深入理解系统，发现系统中存在得问题，第三方测试必须按软件工程的要求办事，以软件工程的标准要求开发方和用户进行配合，从而较好地体现软件工程的理念。引入第三方测试后，由于测试方相对的客观位置，由用户、开发方、测试方三方组成的三角关系也便于处理以往用户、开发方双方纠缠不清的矛盾，使得许多问题能得到比较客观的处理。

　　第三方测试不同于开发方的自测试。由开发人员承担的测试存在很多弊病，除去自身利益驱使带来的问题外，还有许多不客观的毛病，主要表现在思维的定势上。由于他熟悉设计和编程等，往往习惯于按一定的“程式”考虑问题，以至思路比较局限，难于发现“程式”外存在的问题。因为第三方测试的目的就是为尽量多地发现程序中的错误而运行程序的过程，可以更多的发现问题。此外，随着系统越做越大，客观上讲开发人员也无精力参与测试，同时也不符合大生产专业分工的原则。

　　第三方测试不同于用户的自测试。用户是应用软件需求的提出者，对于软件应该完成的功能是非常清楚的，是进行功能验证的最佳人选。客观情况是，大部分的用户都不是计算机的专业人士，很难对系统的内部实现过程进行深入的分析。对系统的全面测试，功能测试仅仅是一个方面，还要包括并发能力、性能等多种技术测试。这些测试对技术有很高的要求，必须由计算机的专业人员才能完成。

　　第三方测试一般还兼顾初级监理的职能，不但要对应用进行各种测试，还进行需求分析的评审、设计评审、用户类文档的评审等，这些工作对用户进行系统的验收以及推广应用都非常有意义。

　　如何组织管理

　　在测试的过程中，用户、开发方与测试方形成了一个三角关系，从最终目标来讲，三方是完全一致的，都是希望保证系统稳定运行。但在测试过程中，三方的关系却是既对立又合作。对立是指各自坚持自己的职责，合作是指每一方的工作都需要其它两方的支持和帮助。

软件测试的过程

　　为了保证测试的顺利进行，测试方必须强化内部的组织管理。根据我们的经验，完整的测试机构必须包括业务分析部门、技术支持部门、规划设计部门和综合后勤部门。例如在中国现代化支付系统第三方测试项目当中，信息化工程总体研究中心的人员分工大致是：部分人员专攻支付业务，部分人员专攻技术支持，部分人员负责测试规划与综合案例的设计，部分人员负责现场情景调度，部分人员从事案例的细化与运行。测试结果表明，总体上达到了各司其职、忙而有序。

上面已经谈到了准敏捷测试模式了，离咱们所说的敏捷测试已经无限接近了，但是要了解真正的敏捷测试，还是需要回到敏捷开发上来讲，前面一开始已经说过，敏捷测试严格上来说其实是属于敏捷开发的一部分，所以敏捷开发的价值观也会同样适用于敏捷测试，那么敏捷有哪些价值观呢？总共是五个，分别是简单、沟通、反馈、勇气、谦逊。

　　光看这五个词，我想大部分人可能会晕乎了，不知所云的，难道敏捷就五个词能概括了？就像电影里出现的武功秘籍一样，一招就一个图，我们看了根本就不知道是啥，人家一看就能炼成神功了。

　　其实呢，这几个价值观并不是教你怎么去实现敏捷，而是教你用一种什么样的态度去对待开发：要时刻想着最简单的方法去处理需要解决的问题，要经常与和开发/客户沟通，对于积极对待反馈，要有勇气去做决策，对团队各个成员都要尊重。这么几个价值观，对于你去初次理解敏捷而言，我相信几乎没有用处，甚至会让你觉得很迷茫，到底敏捷是啥，但是一旦当你已经真正理解了敏捷的时候，你就会发现，诶，的确是这样子的，说得很好！（哲学上说，事物的发展总是需要经历否定之否定阶段，对知识的理解也是一样，一开始看一下概念觉得很简单，觉得自己已经理解了（肯定）；深入下去，发现问题越来越多，觉得自己没办法去理解（否定）；到最后经过不断地思索与实践，终于彻底理解后，你就会觉得一开始那些简单的概念很精辟，就应该那么简单！（否定之否定=肯定））

　　不过相对于当初的先行者而言，我们又是幸运的，因为很多前辈已经帮我们理解了这些价值观，并且研究出了很多实现的方式， 但是我们也不能去奉行拿来主义，毕竟是人家想出来的，是基于人家的实际情况，对于我们的情况不一定会适合，最好的办法就是取其精华，去其糟粕，结合实际，加以改进。

　　接下来我就开始讲什么是真正的敏捷测试模式和我们公司怎么结合它来取其精华，去其糟粕，结合实际，加以改进。

　　当然这个所谓的真正的敏捷测试模式也是业内主流的模式，我们公司的实际运用中还是有所区别的，下面都会提到。

　　跟前面讲到的准敏捷测试相比，真正的敏捷测试其实也只是加以改进和丰富，所以与客户的沟通、积极响应需求的变更、以及开发与测试的同步，这些都还是存在的，当然敏捷测试改进和增加了许多地方，主要有：

　　1、过程需要实现迭代：每个迭代周期需要完成一定量的功能，没有完成的功能不能Check In代码，这些功能需要经过严格测试，并且开发需要修复主要的严重Bug，这样子在最后就得到一个可以工作的并且相对稳定的Build，这个迭代周期就算完了，然后开始下一个迭代周期。这样就类似与我们修路一样，修路的话需要打好几层地基，每层地基打严实后，再铺上面一层，这样子即使最上层破了，只要修一下最上层就好了，不会影响到下面层的质量，如果是最下面那层没打严的话，一出问题每层都会损坏，要修的话，要全部扒掉这么多层地基才能修好。所以迭代对于测试的要求就特别高了，因为只有把这个迭代的主要Bug找到并修好，下面的迭代周期才能不受影响，才能确保以后出现的问题不用“打到最底层”才能被修好，“打到最底层”意味着就是人力，物力，时间以及最重要的产品的质量！

　　下面是一个迭代的简单示意图，应该可以理解的，就不多讲了。

　　2、测试不单单要和客户沟通，也要跟公司里的人经常进行沟通，因为一个公司的所有人其实都只有一个共同目标，就是把公司发展好，这样子其他的比如自己的发展，待遇等等才有可能实现。那么体现在实际的工作中就是：

　　a）测试需要完全理解需求讲的知识点，不懂或者有疑虑要及时跟设计沟通，这样子可以让你更好地理解需求，甚至帮助设计人员发现错误；

　　b）测试人员需要经常跟开发人员沟通，看看做的功能，修的Bug主要会影响哪些其他模块，主要出现问题的原因是什么，怎么弄可以最快速度重复出Bug来，这样子就帮助自己掌握测试的方向以及帮助开发快速修复Bug以及避免以后出现类似Bug。

　病初愈，最近做了几次培训，性能测试和测试工具。现在自己弄了一个论坛也把很多的心思放到性能测试上，个人喜好所在。

　　在这几培训和最近别人问的问题中，感觉到有这么几件事情：

　　1、有些人很想接触性能测试，但是一到具体的细节，兴趣索然。不管是工具的操作，还是理论的理解。要说我讲课能力有限，可以把人讲的没有兴趣，这是我个人问题。这个因素在实际的操作中，总不会有吧。实际的操作还是有些人觉得没什么意义。有的人就像是见了刺猬，不知道从哪下口。要说工具有多麻烦，我觉得也不至于。至少LoadRunner比word简单多了。我曾经说：一周时间完全可以掌握LoadRunner的操作，其他的就要看练习和经验了。这么说，是不是有经验的过来人，感觉对？当然人不可能都一样的。我想强调的就是工具并不复杂。复杂的是应用。

　　2、理论对性能测试的指导作用容易被忽视。很多时候，技术人在考虑问题的时候，都是技术细节，觉得只要是理论都挺无聊的。大而泛，忽悠人用的。从我自己的感受来说，我觉得完全不是这样。当然对某个词的定义这样的理论问题，我们用不着太细究。但是性能测试理论，真的对我们的实际工作没有指导意义吗？或者说意义不大？比如，在讨论基准测试的时候，很多人都知道基准测试是什么意思？但是很少有人能把基准测试的范围和程度说清楚。应该测试什么？做到什么程度？这些仅是技术问题吗？在相应的位置上的测试人员，有没有考虑过你的职位能做或不能做什么事？能做到或做不到什么事情？应该做或不应该做什么事情？这些都会对项目的质量产生影响的。

　　3、面对性能测试过程、结果、数据，真的理解清楚了吗？针对同一个数据和过程不同的人感觉到的层面是不一样的。这就是经验和能力的区别，就算是两个人做的结果完全一样，我想由于能力不同，也会这一结果的理解不同。在多次培训的过程中，我解释最大、最小、平均、标准方差等值的时候，都会有人有醒悟的样子。我们说为什么这几个值，重要到放在summary里面，为什么不是中位数？为什么不取个微分放那儿？其实，这都是有设计上的原因的。所以说，我们面对这些东西的时候，要知道它具体的含义，从而把握的更清楚。也对我们做的事情更确定。不会经常出现别人问几句就问倒了的现象。

　　写这个文章就是想告诉大家：

　　1、技术是一步步积累的；

　　2、理解自己做的事情。

　跟着师傅做了几个日常，参加了几次需求的讨论，渐渐感觉到做需求还是需要花费不少精力的。如果说对原来的业务非常熟悉，相对来说做起来就轻松一些，而要是从来都没接触过这块内容，就会感觉有点像丈二和尚摸不着头脑：知道用户想要什么，但是却不知道如何跟现有的系统更好的结合起来，我们到底能够提供什么？用户的需求是否合理？做需求分析，不能跟着用户的感觉走，因为这样的话，只能是用户说一你做一，而如果用户不能很好的提炼需求的时候，我们就会进入一个死循环了。在和用户讨论的时候，我们首先要知道用户为什么会提出这个需求？能够帮助他解决什么样的问题？希望达到什么样的效果？并不是所有的用户都能正确的表达自己所想要的东东的。

　　一个比较典型的例子：最近跟一个营销平台的PD在聊用户一般会怎么样来提需求的時候，谈到曾经做过的一个营销活动的推广需求，运营人员为了推广某一项活动，往往会比较纠结在页面上这个按钮应该如何放置，需要新增加几个显示字段才能达到这次活动的效果，那这是用户最根本的需求吗？不是，实际上他真正需要的是应该给他提供几个维护活动的界面：类似什么样的活动时应该出现下拉的选择框进行维护，什么样的活动应该给他提供几个选项项。他们习惯上只会关注到现在他需要什么样的功能，在下次需要新的功能的时候，又会来提新的需求，所以对于类似这样的问题，PD的作用就显现出来了：透过现象看本质，要善于抓住用户描述问题的过程，引导他抛出隐含在这个需求背后的衍生内容，复述一下用户所说的目前存在的问题，了解一下用户可能会用的方式有哪些？并说明对流程的理解，再结合流程中的不明确点设计要询问的问题，并将客户的反馈记录下来，然后与客户确认一下是否有遗漏的内容，增加这些属性是否就都已经覆盖了他所想要的所有功能了？

　　我想这其实也就是需求分析的价值所在吧。这步工作如果没有做好，往往就会导致考虑得不够充分而引起新的需求变更，甚至关系到开发出来的软件产品能否得到用户的认可，客户能否真正运用我们的产品帮助他们解决业务或管理上的问题。当然要做到这一点，也不是一两天就能搞定的，需要一个逐渐积累的过程，学会如何巧妙的向客户提问也是一门非常值得我们去思考的学问。业务方在需求的提出方面起着主导作用，但PD必須要能够对客户的需求进行过滤，要在非常了解原有系统功能，架构设计的基础上来给出建议，这样才有可能在需求阶段规避掉一些具有比较大业务风险、技术风险的需求。

　　我们与运营方讨论的过程中会收集到一些新的需求，回来后一般需要对用户繁杂的业务进行流程的提取，把那些分布在各个部门的同一种业务提取出来进行初步的整理和分析， 把大致的功能点整理一下，遇到不明确的、有疑问的再咨询师傅，必要的时候还要跟开发进行讨论实现上是否可行。整体的思路是这样的：业务的目标是什么？用户需要怎么做才能完成业务目标？系统要能为用户提供哪些支持？系统必须符合哪些规则？展现的形式可以包括：用例的分析，业务流程和活动输入输出的分析，业务操作规则的整理，通过确定用户的任务，每项用户任务的步骤，定义对业务具有重要意义的数据并确定已有的逻辑关系。在确保业务描述基本没什么问题的前提下，邀请开发和业务方进行评审，并对业务流程上不对的地方进行修改。经过几次来回的交流，最终才能取得较全面的需求。需求分析关注的目标应该是“做什么”，而不是“怎么做”，所以在描述需求的时候，表述的方式应该是“实现什么”，而不是“如何实现”。

　　做需求分析的过程，其实跟我们的测试分析工作有非常相似之处：我们在测试活动中，也都是从理解业务的需求开始的，首先需要明确测试需求（What），才能决定怎么测（How），通过了解这个项目具体是做什么的，完成一个什么样的业务，哪些功能是最常用的？哪些功能是重点？还有就是用户在处理实际业务时都要作些什么，多个业务之间的先后顺序是怎样的，用户在处理业务时对于哪些地方有特别的要求，等等。这部分规则，就是我们的测试需求中最基本的一部分。测试需求不明确，只会造成获取的信息不正确，无法对所测项目有一个清晰全面的认识，活在自己世界里的人是可悲的。

　　测试需求并不等同于软件需求，它是以测试的观点根据项目需求整理出一个checklist，作为测试该项目的主要工作内容。根据所测的功能点进行分析、分解，从而得出着重于某一方面的测试，如界面、业务流、接口、数据等等。理解项目需求，需要从整体到局部，从局部到细节。测试人员不要总只了解自己模块的内容，要先从整个项目的业务流程入手，然后再到自己的功能模块，这样的好处是，测试人员了解上下游的交易功能，更加的能够了解业务的实现方法。经过一番狂轰乱炸式的深入理解之后，再将自己负责的模块有条有理的整理出来，然后讲解给项目组成员，这样也有利于模块之间的整合理解，再由他们提出各种各样的问题，若能很轻松的回答出各种各样的问题，说明你对项目的理解已经很到位了，而如果在提问的过程中有很多的问题，都是你之前没有考虑到的，那说明测试的需求分析做的还不够到位，这时你就需要好好总结一下，是因为自己经验方面的问题，还是由于其他方面的原因。总结起来测试需求的内容大致如下：

　　1、理解系统的流程：整理出业务的常规逻辑，一项一项列出各种可能的测试场景，同时借助于需求文档资料，来确定该场景应该导致的结果

　　2、进行功能的分解：系统包含哪些主要的功能，每个功能的期望值是什么；各个模块处理哪些业务，各子系统模块之间的数据接口关系，基础数据从哪里进入，通过哪些处理生成哪些结果等等。在做完以上步骤之后，将业务流中涉及的各种结果以及中间流程分支回顾一遍，确定是否还有其他场景可能导致这些结果，以及各中间流程之间的交互可能产生的新的流程，从而进一步补充与完善测试需求。

　　以上只是个人对如何进行需求的捕获以及怎么样做好需求理解的一些看法，同时也是对我自己前段时间的工作做的一点梳理，希望大家能多多交流，共同进步，把我们的测试工作做的更好。

　主持人：首先，我给大家介绍一下我们推出的巅峰访谈系统活动，我们是邀请来自厂商的领导和专家，来解读一下技术趋势和应用方案。今天我们请到的是惠普公司的Mark Sarbiewski先生和王滢女士。

　　Mark Sarbiewski先生是资深的产品市场主管，他全面参与惠普软件的市场工作，在测试软件领域有非常长的工作经历。那么，王滢女士是中国惠普软件部技术顾问，她也有多年从事测试软件的售前咨询和技术支持的经历。

　　我们第一个环节是请Mark Sarbiewski先生为大家讲解一下惠普提出应用质量管理包括哪些具体的内容。

　　Mark Sarbiewski：非常感谢大家能够发出这样的邀请，抽出时间和我们一起做这样的访谈。首先，我简单地和大家做一个介绍，和大家谈一谈惠普在软件应用质量管理方面的一些观点。

　　在我介绍的开场白，我想引用一个非常著名的资深公司说过的一番话，这个话的中心思想软件的最终目的在何处呢？当最终用户使用这样的软件的时候，软件的性能是有效的，而且是安全的。所以，我们是最开始在这个价值上面，把它最终传送到用户手上，让他觉得物有所值。

　　接下来，我们再看另一则引言，这其实告诉我们一个思想，就是软件是不断变化的，它现在已经变得越来越复杂，而且与很多事物都是相关联的。这提醒我们如果我们依然用10年前的老办法来做软件，我们很难在日新月异的软件市场当中获得成功。

　　那么，我们来用这页简单地看一下应用软件方面的一个变化。最一开始的时候，我们只是看到一个孤立形式的软件的应用，我们更多地是用于金融行业。

　　当时的问题是当它用于金融行业的时候，它最一开始的效果是不错的，但是随后我们要对它进行一些调整的时候，却发现很难做出这样的调整。

　　现在，我们在全球很多公司看到一个跟以往不同的情况，就是现在都采取一个不同的架构，我们是根据服务来选择软件，而且这个软件因为取决于服务，所以可以应用到整个的业务流程当中。

　　现在我们也很高兴见到了很多新进的科技产生，比如说Web2.0的技术，这使得应用可用性更强，而且具有更高的挑战性，同时带来的可用性和安全方面、性能方面的挑战。惠普希望能够在这个基础上，更加了解我们客户的需求，能够更好地帮助他们。

　　在惠普，我们采取的解决方案第一步就是把质量是三个支柱支撑的，首先是功能性，就是它是否能够很好地运行。第二个支柱就是性能，当有上千万的用户来使用这个应用的时候，它是否能够正常运行。第三个支柱就是是否安全。

　　那么，这个解决方案的第二步，就是在整个应用的生命周期当中，我们支持的是哪一个环节。很多人在谈软件的开发周期、生命周期，这意味着什么呢？这是开发之初一直到最后的交付使用。

　　如果说仅仅关注于开发这个环节的话，那么实际上会忽略很多真正应该值得我们去注意的问题，如果我们来看一个完整地应用生命周期的话，它应该是更加宽泛的，应该延续到最终用户使用运行起来这个阶段。

　　因为在这个时候，就是在真正运行这些软件的时候，或者是使用这些应用的时候，我们这个时候发现的问题所需要来解决的资源、人力，甚至这个问题产生对于公司造成的一些风险、影响，都值得我们去关注。

　　在我们解决方案中，最后的一步就是要统观全局，纵观整个的生命周期，找出几个最重要的点，能够使得我们的软件应用在交付客户使用的最后可以发挥它的效用，就是最后是我们需要关键控制的关键控制点。

　　我来谈一谈为什么我们要谈论着几个关键控制点，或者说战略控制点。因为很多的公司他们在考虑是应用什么样的科技、技术来做研发，来选择它们的应用，是用JAVA还是用.net来做，是买这样的应用还是自己研发这样的应用，但是真正的问题在于他们是否理解了需要这个软件、需要这些应用背后的需求，如果最一开始没有把这个需求搞明白，没有和他们的客户沟通，那么应该说最后的效果也是不好的。

　　所以，我们提倡的是应该正确地去理解这些需求，同时也要分析所有这些需求所意味的风险，这样才能够做出适当地选择来完成测试，最后把这个应用推上线。

　　我们的解决方案就是有各种各样不同的中心，这就是我们的产品组合，使各个部门所相关到的人员都能够彼此联系，做出一个协同的决定。

　　最后，我想用另外一句引言来做结，这个引言告诉我们在很多的IT公司、IT部门每个人都应该很忙碌，但是我们不应该以这种表相认为这个项目就做成功了，我们应该这个结果或者是效果来衡量、评价所做的应用是否成功。

　　以上就是我简单地介绍，我们来进行问答环节。

　　主持人：我们这次问题的来源，首先是为这次访谈我们准备了一些具体的问题，同时我们在网上发出了一个征集问题的帖子，我们大概有近40位的网友在上面留言，他们提出了实际工作中包括软件测试人员职业发展的问题。

　　首先，我想请问一下Mark Sarbiewski先生，在刚才您提到的介绍中讲到，现在是越来越复杂的IT系统给企业带来了业务的风险，那么在这个很长的应用生命周期的过程中，谁需要来为规避这些风险负责呢？

　　Mark Sarbiewski：这个问题提得相当地好，我总体的一个答案是说，并没有说某一方要为所有的风险买单，并不是这样一个情况的。说起来，现在软件应用对于每个公司来说是至关重要的，所以我们应该设立一个中心风险管理的团队，来对待这些风险，每个团队有一个负责人，但是并不是说这个负责人就应该对于风险负责，而是团队当中的每一个人都应该负责，一直到设计人员、开发人员、运行团队、质量团队每一个人都应该负担这样的责任。

本人一直在做产品和项目的公司测试部门从事测试工作，从未在第三方测试团队中工作过，因此，本人的观点仅限于非第三方测试团队。

　　在本人的从业经历中，先后涉及过医疗、水利、政府、军队等行业，以个人的经历来看，在非第三方测试团队中，是不存在专职的性能测试团队的。这是由于所在公司的性质以及测试工作任务所决定的。由于处在非第三方的测试团队中，其工作任务就是负责公司的产品或项目的质量保证。在日常的工作中，80%以上的工作属于需求分析和功能测试，当然，对于做产品的公司来说，功能测试中还包含自动化测试；而性能测试工作仅在功能稳定后，才会正式开展，因此，性能测试的工作量仅占日常工作的20%左右。正是由于性能测试工作所占日常工作量的比重不大，所以，公司不可能组建专职的性能测试团队，因为公司不可能让这些性能测试工程师在一年的大部分时间内都闲着。。。

　　（当然，性能测试应该从单元测试就开始，这样才能尽早的发现问题，这也是国外软件测试所推崇的。但是，这不符合我国当前的软件测试发展形势。毕竟软件测试行业在国内尚属发展初期，现在能组织性能测试工作的公司就已经很不错了，有相当一部分公司都是只要软件不宕机，压根就不会想起性能测试的。 ）

　　抱怨完当前的形势之后，咱们言归正传。虽说公司不会组建专职的性能测试团队，但是公司却提倡软件测试人员具备性能测试的技能，平时从事功能测试，一旦有性能测试需求，也可以立即投入。（给的是功能测试工程师的待遇，干的却有性能测试工程师的活。公司还真会算账。。。 ）

　　接下来谈一下测试团队应具备的性能测试技能吧。

　　首先，性能测试的重点是场景设计。那么，测试团队就必须具备需求调研和分析的能力。有人会说，性能测试指标都是用户给定的，还需要需求调研和分析能力么？答案是肯定的。因为相当一部分用户所提出的性能测试指标是不可靠的。他们提出的性能测试指标，往往是拍脑袋拍出来的。如：一个业务发生频率不高的系统，但用户数却在4万人，这时候用户很可能就会要求并发数在4000左右，但实际上没有那么大的业务量，系统是不需要那么高的并发数的。反之，有的系统虽说用户数不是太多，但是业务发生频率很高，这种系统要求的并发数也不会很低。因此，测试人员必须具备需求调研和分析的能力，能够引导客户，得到真实的业务发生频率、发生类型、业务量以及数据量。从而，分析出系统可能出现性能瓶颈的业务，并进行场景设计；

　　其次，应具备一定的系统分析能力。被测软件所用框架、中间件、业务组件、硬件、网络、部署结构等所有因素，哪些地方有可能出现性能瓶颈。那么，它一定在你的测试场景覆盖范围之内。如：一个使用频率不高的业务组件，但由于业务复杂度较高或资源冲突等因素，很有可能会成为性能瓶颈的。

　　最后，就是应具备负载生成工具及监控工具的应用能力。毕竟，设计的性能测试场景是需要被执行，性能测试执行结果是需要被采集的。

　　如果已经掌握上述的各项能力，那么说明这支团队已经具备初级的性能测试执行能力。接下来，再谈一下更高的要求。

　　第一，掌握硬件的配置及原理。如：F5负载均衡服务器，采用的是哪种均衡策略，这将直接影响到你的性能测试场景的设计及执行的效果；

　　第二，掌握被测软件所用操作系统的常用命令，它可以帮助你启动/关闭操作系统的服务，以及系统资源使用情况；

　　第三，掌握被测软件所用中间件的配置参数及监控方法；

　　第四，掌握必要的开发能力。商业化的测试工具毕竟有一定的局限性，很难完全支撑各类性能测试的执行。因此，需要开发必要的负载生成工具、预埋数据脚本、监控工具等；

　　第五，掌握测试结果分析和调优的能力。测试结果仅仅是采集到还是不够的，还需要分析系统运行时的资源使用情况，分析系统性能瓶颈以及是否存在由于性能原因导致功能性错误等问题。当然，如果能够根据测试结果，给出性能瓶颈的解决方法，那么，这支测试团队就是支高素质的性能测试团队。

　　以上仅仅是个人的一些观点，不足之处，还望大家指正。