1、软件测试流程的意义

从一个软件企业的长远发展来看，如果要提高产品的质量首先应当从流程抓起，规范软件产品的开发过程和软件测试的流程。这是一个软件企业从小作坊的生产方式向集成化规范化的大公司迈进的必经之路，也是从根本上解决软件开发和软件测试质量问题，提高工作效率的一个关键手段。

软件产品的开发同其它产品（如汽车）的生产有着共同特性，即需要按一定的过程来进行生产。在工业界，流水线生产方式被证明是一种高效的，且能够比较稳定的保证产品质量的一种方式。通过这种方式，不同的人员被安排在流程的不同位置，最终为着一个目标共同努力，这样可以防止人员工作间的内耗，极大的提供工作效率。并且由于其过程来源于成功的实例，因此其最终的产品质量能够满足过程所设定的范围。软件工程在软件的发展过程中吸取了这个经验并把它应用到了软件开发中，这就形成了软件工程过程，简单的说就是开发流程。

不管我们做哪件事情，都有一个循序渐进的过程，从计划到策略到实现。软件流程就是按照这种思维来定义我们的开发过程，它根据不同的产品特点和以往的成功经验，定义了从需求到最终产品交付的一整套流程。流程告诉我们该怎么一步一步去实现产品，可能会有那些风险，如何去避免风险等等。由于流程来源于成功的经验，因此，按照流程进行开发可以使得我们少走弯路，并有效的提高产品质量，提高用户的满意度。

目前流行的流程方法有很多种，如瀑布模型、螺旋模型、RUP模型、IPD流程等，不同的过程模型适合于不同类型的项目。

2、软件测试工作流程图

2.1 软件测试工作总体流程图

说明：软件测试技术之集成测试和系统测试的反馈意见可能导致设计文档（需求或数据库）的修改。

本文转载自51Testing软件测试网（查看全文）：http://www.51testing.com/html/76/n-193276.html

软件测试分析——业内对软件测试分析有着不同的看法，是否取舍都有自己的市场。

A公司：软件测试流程非常严谨的公司：用户需求->软件需求->软件需求规格说明书->用例

B公司：取反（软件测试流程非常严谨的公司）：用户需求->产品需求->软件测试分析->用例

从A公司来看，所有输入质量都已非常稳定，具备了从需求直接到用例的粒度。软件测试只需要直接验证需求与功能的一致性即可。有点“被测试”的感觉。

从B公司来看，输入质量不高，产品需求更像一个功能清单，只知道我要什么，但是具体到你要的东西是否已经有另一种形式存在了？他与其他功能的联系是什么？他要的是A还是A'？因此，在这种情况下，需要有测试分析把问题统统理清。

结论是什么？……测试的世界里永远没有理想境界。

软件测试用例——这也许是最没有争论的东西。

我很少完全按着用例来执行，但我会把用例写得非常详细。

原因有：测试时，我已对功能验证点了如指掌。可过一阵子，我可能完全忘记它。

缺陷——需要测试来分析缺陷产生的原因吗？

之前看到有个文章说，提交缺陷时只需要描述现象即可，过多的分析可能会误导开发。但自从有一次，开发看到我缺陷描述中的原因分析，兴奋不已时。我才醒悟，“自己能做到的我从来不去麻烦别人”。分析问题原因也是一种测试，是对开发思想的测试。当然前提是你分析的依据是充分的。

软件测试报告——报告给谁看？

如果非要选出一个最需要看的对象。我觉得那就是你：如果你对自己的工作都不负责，那你期望谁对你的报告负责？

本文转载自51Testing软件测试网：http://www.51testing.com/html/85/n-143385.html

最近在各博客中看到不少同仁在聊现在越来越热的软件测试技术和测试工程方法，而本人也在一个通讯公司专职测试摸爬滚打了多年，其中有些心得，希望使用容易理解的语言组织成系列和广大同仁分享。其中可能涉及软件测试技术、软件测试设计方法、软件测试建模、软件测试流程/开发流程、软件测试管理、软件测试度量等方面，如有不确之处，还请多多讨论。

搞技术的都知道，技术钻研的越深，越容易有技术情节，但不论如何，软件测试本身就是一个发展中的行业，特别需要不同方面的声音，希望大家着重关心不同情况下适用的技术本质，而不是无谓的争吵。

总体来介绍一下一般的软件测试活动，目前一般比较上规模的创新技术公司或企业，会设立专门的测试岗位，而测试岗位根据具体职位不同有很大的区别，例如厂验（出厂测试，抽样检验产品的合格率），SIT系统集成测试（在开发后期，根据用户使用场景进行测试），SDV系统设计验证（在系统开发阶段，转测试的第一个环节）等等，总体来说，测试工作越向前介入开发阶段，测试含金量越高。而目前各大技术公司逐渐从瀑布、螺旋开发模式逐渐向迭代开发、增量开发、敏捷开发靠拢，越来越关注测试在设计阶段的重要作用，这些都会在后面系列逐一介绍。

我们一般用户接触到的也有测试，例如最近Firefox的Beta测试，微软的体验测试等，这些测试都有一个共性--看不到系统的实现方式，纯黑盒体验测试。方才也提到，测试活动越靠前，越了解系统，越懂得各个开发阶段所使用的测试方法。

在瀑布模型中，开发一般必做的是单元测试，自己写代码，自己打桩写测试代码，主要验证语法、逻辑等基本问题，这里有个问题，测试有个主要的思想是“避免让程序员测试自己的程序”，这是一般是指系统测试，开发人员进行单元测试的效率是很高的，首先自己保证没有导致编译不通过的低级错误、内存泄露等隐藏很深的错误，此类错误在系统测试也可以测试，但成本太高；同事之间的代码Review也是很好的错误检测方法；在各个模块接口完成后，可以进行基本功能联调，这时出现的接口问题是主要的拦路虎。一般有积累的系统，会使用模拟器仿真系统，在实际仿真环境调试，这样效率很高。

本文转载自51Testing软件测试网（查看全文）：http://www.51testing.com/html/90/n-178590.html

最近股市行情好像不怎么样，不少人在买进还是卖出之间犹豫。各位精明的投资者，你有没有考虑一下软件测试工具的领域呢？因为这个领域最近也处于风云变幻、浪起云涌的“大时代”，而时代造就英雄，究竟谁能在软件测试工具这个市场上成为笑到最后的英雄呢？

IN - Oracle的“神谕”

随着Web应用程序在软件市场的成长，其地位变得不可忽视。Oracle在这方面的投入也在加大，其中一个“大手笔”就是大刀砍向Empirix，把其旗下的e-TEST买入，并入Oracle的“Enterprise Manager”和“Real Application Testing”中，以期支撑起Oracle在软件测试领域的地位。

这不禁让人有点愕然，“Oracle不是做数据库的吗？怎么搞起软件测试来了？！”其实，这一点都不奇怪。

为了支撑Oracle的软件蓝图，Oracle其实需要的不仅仅是一个测试工具，Oracle需要的是一个ALM、需要加入质量控制、变更控制的内容。在购入e-TEST之前，Oracle的RAT（Real Application Testing）仅仅局限在数据库方面的测试。

再来看看e-TEST，e-TEST是由若干个测试工具组成，包括e-Manager Enterprise（用于测试过程管理）、e-Tester（用于功能测试和回归测试）、e-Load（用于性能和压力测试），基本上覆盖了软件测试的全过程、各主要领域。

买入e-TEST只是其中的一步，这是向着Oracle的SOA-based架构迈进、以及实现其Fusion策略的一步，估计下一步还会有其他的动作。Empirix给Oracle增添了测试的能力，但是Oracle还需要获得变更控制、版本管理等方面的能力，以便完成其“一统天下”的软件霸主伟业。

业界分析Oracle整合e-TEST的过程将会是比较顺利的一个过程，因为Empirix的685个企业客户中，已经有400个是Oracle的用户，e-TEST即将整合到的Oracle Enterprise Manager 10g，是一个拥有全球21000个客户的产品。e-TEST预计将得到20亿美元的产品研发投入预算。

OUT - Agitar“心灰意冷”

有人看好软件测试工具的市场，有人则选择放弃。

最近，Agitar这个Java单元测试工具商业领域的佼佼者宣布放弃AgitarOne。Jerry Rudisin（Argitar的CEO）心灰意冷地说：“单元测试是一个不错的选择，但是未能成为主流的选择”。

本文转载自51Testing软件测试网（查看全文）：http://www.51testing.com/html/53/n-86253.html

曾经，软件测试是软件工程教科书上薄薄的几页四号字，是百度知道上大段的介绍，是想象中繁杂的文档……百度知道上这样定义软件测试工程师的工作：“软件测试工程师的工作就是利用软件测试工具按照测试方案和流程对产品进行功能和性能测试，甚至根据需要编写不同的测试工具，设计和维护测试系统，对测试方案可能出现的问题进行分析和评估。执行测试用例后，需要跟踪故障，以确保开发的产品适合需求”。

推敲一下，不难发现其隐含的对软件测试的定义：按照测试方案和流程对产品进行功能和性能测试，确保开发产品适合需求。再仔细推敲，感觉不对，按这个理解，测试只是从需求定下以后入手，以需求为标准，使得产品功能满足需求即可。实际的情况是怎样呢？稍夸张一点说，就像我们不能保证产品不存在bug一样，没有人能保证需求不变动。因此，需求定下以后测试工程师再介入只能是一句空话。

入职以来，亲身的经历是软件测试工程师从PRD评审阶段就介入了。这样的好处也体会到了：需求不再是word中冷冰冰的字眼，而是评审中经过大家讨论的，烂熟于心的东西，而且一些存在的问题尽早地被挖掘出来，尽早地解决，后期的需求变动减少甚至没有，使得上线前的压力减小。

当然也有一些问题：例如PRD文档写的过于简单或者拿到PRD到评审之间的时间很短，没有时间仔细研究PRD或PRD看的不是很清楚，这样会导致PRD评审的作用和意义就不那么明显了。

PRD评审后，测试的工作就全面铺开了。写TC，执行TC，记录bug，跟踪bug，回归测试，性能测试……各种测试的方法就可以择机而上，根据各自的特点发挥各自的作用，最终的目的就是：从各种角度，最大限度地保证产品的质量和性能。

刚入测试的门槛，心之所发，笔之所至。有不对的地方，大家多指教。

本文转载自51Testing软件测试网：http://www.51testing.com/html/47/n-142347.html

第一步：对要执行测试的产品/项目进行分析，确定软件测试策略，制定软件测试计划。该计划被审核批准后转向第二步。软件测试工作启动前一定要确定正确的测试策略和指导方针，这些是后期开展工作的基础。只有将本次软件测试目标和要求分析清楚，才能决定软件测试资源的投入。

第二步：设计测试用例。设计测试用例要根据测试需求和测试策略来进行，进度压力不大时，应该设计的详细，如果进度、成本压力较大，则应该保证测试用例覆盖到关键性的测试需求。该用例被批准后转向第三步。

第三步：如果满足“启动准则”（EntryCriteria），那么执行测试。执行测试主要是搭建测试环境，执行测试用例。执行测试时要进行进度控制、项目协调等工作。

第四步：提交缺陷。这里要进行缺陷审核和验证等工作。

第五步：消除软件缺陷。通常情况下，开发经理需要审核缺陷，并进行缺陷分配。程序员修改自己负责的缺陷。在程序员修改完成后，进入到回归测试阶段。如果满足“完成准则”（ExitCriteria），那么正常结束测试。

第六步：撰写软件测试报告。对软件测试进行分析，总结本次的经验教训，在下一次的工作中改。

本文转载自51Testing软件测试网：http://www.51testing.com/html/15/n-122015.html

不觉间，从事软件测试驱动开发（Test Driven Development）半年有余，自从看了Robert Martin的《敏捷软件开发：原则、模式与实践》， 就忍不住想实践一下，亲身体会书中描述的美妙景象。恰逢项目中一个全新功能交由我负责，开发周期也不是十分急迫，就拿这个新功能当回小白鼠，遵循书中的实践方法开始进行软件测试驱动开发。

随着开发的不断深入，软件测试驱动开发的实践渐入佳境，对其认识也从开始时的顶礼膜拜逐渐回归理性，在为其优长欢欣鼓舞的同时，更理解了其不足或者说是不具备的能力。

软件测试驱动开发意味着不再是从需求分析与概要设计/详细设计后直接进入到实现代码的编写，而是转而根据需求分析和概要设计进行软件测试用例的设计与软件测试代码的编写，通过软件测试代码硬性规定了实现代码所必须满足的功能需求、容错能力。编写实现代码的唯一目的就是使所有测试用例成功运行，任何测试用例的失败都意味着实现代码存在功能缺陷或者逻辑错误。之后就是不断重复--修改或增加代码再运行所有测试用例检查结果--的迭代过程。

看上去很简单的一个过程，却与传统的开发格格不入，惯性的力量导致开始时很难从传统过程的思维方式中摆脱出来。在做完需求分析与概要设计，开始设计测试用例与编写测试代码时手足无措，只能摸着石头过河，试着去做去写，然后通过测试驱动开发的迭代过程去观察，去体会，去修改，去适应，然后再重复迭代过程。就这样，渐渐理解了测试驱动开发这种“进化->测试->反馈->再进化->…”迭代循环的自然与强大，从测试中得到的反馈不仅说明实现代码的完备和健全与否，也给人不断进步之感，似乎总是在脚踏实地的前进着。因为在迈开每一步之前，都知道已有的工作经受了测试的检验，就具有相应的信心。即使发现有更好更优秀的设计实现，也可以放心大胆的彻底重构，因为有软件测试用例和软件测试代码作监督作守候。

此外，测试驱动开发也改变了原先开发的视角，不再是直接编写实现代码，而是转而从旁观者和使用者的角度设计软件测试用例和软件测试代码，总是能够发现很多原先忽略的因素和条件。