Web 服务处于分布式计算的核心位置，它们之间的交互通常很难测试。分布式开发、大型的开发者团队以及对代码日益组件化的期望都有可能使Web 服务的开发变得越来越容易隐藏错误。这些类型的错误极难检测出来。压力测试是检测这类代码错误的一种有效方法，但是只有在压力系统设计得比较有效的情况下才能发挥作用。本文将让您深入了解一下这种压力系统的基本要求。
　　
测试方法
　　
　　传统的测试方法包括某种形式的简单单元测试，通常由开发人员执行。设计这些测试需要了解软件的内部知识，并且这些测试几乎总是针对产品的非常小的、特定的部分。这些类型的测试非常适合与其他代码组件极少交互，甚至没有交互的简单Web服务。
　　
　　功能验证(Functional Verification) 也是一种测试过程，在这个过程中，对产品源代码了解有限的设计者进行测试以确认产品或服务的核心功能。设计这种测试是为了证明这个核心功能符合某个规范。举个例子，我的在线拍卖显示的是输入的正确出价吗? 我的保险经纪人系统找到最便宜的报价了吗?如果这些测试失败，通常就意味着检测到了产品的一个基本问题(这个问题通常是可以直接修复)。这种测试也是适合简单的Web服务，使您可以检查服务是否能够正确执行它的各个功能。
　　
　　系统测试(System Test) 通常是在功能验证阶段完成，验证了核心功能后进行。它倾向于把整个系统作为一个整体来查找问题 — 弄清Web服务作为系统的一部分怎样运作，以及Web服务相互之间如何交互。由于系统测试是在开发生命周期快结束时才进行，所以通常不能给它分配足够的时间来完成。又因为紧张的发行日程安排以及开发的各个重要阶段的后移，系统测试阶段经常被忽略，并且一些通常都可以发现的、少见的错误都不能被检测到。即使发现了这种错误，这时也来不及确定错误的原因并设法修复它们了。因此，在查找代码错误时，必需把系统测试应用设计得尽可能高效。系统测试通常由三部分组成，它们是:　　    

性能(Performance): 这涉及到确定相关的产品统计数据的过程。例如:每秒有多少条消息?一个服务可同时接受多少个用户?
　　
　　案例(Scenario): 这是重新创建客户所需的确切配置的过程。因此在案例中发现的任何问题都可以在客户使用该产品之前被检测出来。
　　
　　压力(或称工作负载平衡): 它与另两个部分不同，因为它被设计为通过应用很大的工作负载来使软件超负荷运转。如果压力测试通过对产品保持高强度的使用(但不超过性能统计数字确定的限制)能有效地执行，那么它就经常能够发现许多隐蔽的错误，而这些错误用上面提到的任何其他技术都是发现不了的(这些错误也经常是最难修复的)。
　　
　　从检测代码错误这方面来说，可以证明这三个系统测试组件中效率最高的是压力测试部分。但由于这个过程经常跟系统的其他要素或功能测试混淆在一起，所以这个过程涉及到的方法还没有被正确着手处理或实现。
　　
　　压力下的错误
　　
　　使用压力测试，您有希望找到很多种用其他测试方法更难发现的错误。有两种错误类型是:
　　
　　内存泄漏(Memory leak): 一种极难检测的现象。内存泄漏经常发生在已发行的产品中，原因很简单，很难设计测试用例来检测它们。使用简单的功能测试，几乎发现不了内存泄漏问题，因为在产品完成之前测试没对产品进行足够多的使用。内存泄漏通常要求操作重复非常多的次数以使内存消耗达到能引起注意的程度。尽管与其它编程语言(如 C/C++)相比，Java 程序更难引入内存泄漏错误，但只要程序仍保持着对象的引用，该对象仍有可能被实例化并且它占用的内存永远不会被释放。
　　
　　并发与同步(Concurrency and Synchronization): 压力测试在查找并发性问题上非常出众，这是因为在任何一个测试生命周期中，它都应用了许多不同的代码路径和定时条件。一般的规则是，压力测试运行的时间越长，涉及并应用的代码路径组合和定时条件就越多。当然，这也的确使得这些问题很难再现(错误可以在5分钟或5天后发生)。死锁、线程泄漏以及任何一般的同步问题通常只能在压力测试阶段被检测出来。这些类型的问题很难通过执行单元测试来发现。开发人员不会一直考虑他或她的代码将与其他地方的代码(在执行单元测试时这些代码可能还没写出来)进行交互。
　　
　　现有的压力测试工具
　　
　　有许多声称能够对产品进行压力测试的可用工具目前正在开发中。被广泛应用的是针对 Web 服务的那些工具。然而，这些工具中有许多只是简单的 HTML/SOAP 生成器，它们模拟许多客户机连接，并因此对Web服务器生成高负载(这对于查找Web服务器的问题很有用，但对于查找Web服务的问题就没那么有用了)。这些工具对基本的压力测试比较有用，但它们经常是仅仅扩展功能验证阶段来重复地执行相同的功能任务。如果足够的时间和资源可用，就可以通过创建定制构建的压力测试系统来实现更有效的测试。由于压力系统的设计者通常对要测试的产品和Web服务有更多的了解，所以他们将能够确保压力系统可以用于哪些具体的代码区域。
　　
　　设计压力应用
　　
　　设计试图对Web服务进行压力测试的压力测试系统时，要让它们以某种特定的方式运行代码。这些风格超越了功能验证，目的是要弄清楚被测试的Web服务是不是不仅能做我们认为它能做的事，而且在被施加了某些高强度压力的情况下仍然继续正常运行。压力测试必须对Web服务应用四个基本条件。许多已建立的压力系统应用了这些条件。有效的压力测试系统将应用以下这些关键条件:
　　
　　重复(Repetition): 或许最明显的且最容易理解的压力条件就是测试的重复。换句话说，测试的重复就是一遍又一遍地执行某个操作或功能，比如重复调用一个Web服务。功能验证测试可以用来被弄清楚一个操作能否正常执行。而压力测试将确定一个操作能否正常执行，并且能否继续在每次执行时都正常。这对于推断一个产品是否适用于某种生产情况至关重要。客户通常会重复使用产品，因此压力测试应该在客户之前发现代码错误。许多最简单的压力系统只实现这一个条件，但简单地扩展功能验证测试来多次重复并不能构成一个有效的压力测试。当与下面的一些原则结合起来使用时，重复就可以发现许多隐蔽的代码错误。
　　
　　并发(Concurrency): 并发是同时执行多个操作的行为。换句话说，就是在同一时间执行多个测试，例如在同一个服务器上同时调用许多Web服务。这个原则不一定适用于所有的产品(比如无状态服务)，但是多数软件都具有某个并发行为或多线程行为元素，这一点只能通过执行多个代码示例才能测出来。功能测试或单元测试几乎不会与任何并发设计结合。压力系统必须超越功能测试，要同时遍历多条代码路径。至于怎么做到这一点取决于具体的产品。例如，一个Web服务压力测试需要一次模拟多个客户机。Web服务(或者任何多线程代码)通常会访问多个线程实例间的一些共享数据。因额外方面的编程而增加的复杂性通常意味着代码会具有许多因并发引起的错误。由于引入并发性意味着一个线程中的代码有可能被其他线程中的代码中断，所以错误只在一个指令集以特定的顺序(例如以特定的定时条件)执行时才会被发现。把这个原则与重复原则结合在一起，您可以应用许多代码路径和定时条件。
　　
　　量级(Magnitude): 压力系统应该应用于产品的另一个条件考虑到了每个操作中的负载量。压力测试可以重复执行一个操作，但是操作自身也要尽量给产品增加负担。例如，一个Web服务允许客户机输入一条消息，您可以通过模拟输入超长消息的客户机来使这个单独的操作进行高强度的使用。换句话说就是，您增加了这个操作的量级。这个量级总是特定于应用的，但是可以通过查找产品的可被用户计量和修改的值来确定它。例如，数据的大小、延迟的长度、资金数量的转移、输入速度以及输入的变化等等。单独的高强度操作自身可能发现不了代码错误(或者仅能发现功能上的缺陷)，但与其他压力原则结合在一起时，您将可以增加发现问题的机会。
　　
　　随机变化: 最后一点，任何压力系统都多多少少具有一些随机性。如果您随机使用前面的压力原则中介绍的无数变化形式，您就能够在每次测试运行时应用许多不同的代码路径。下面是几个关于怎样在测试生命周期内改变测试的示例。使用重复时，在重新启动或重新连接服务之前，您可以改变重复操作间的时间间隔、重复的次数，或者也可以改变被重复的 Web服务的顺序。使用并发，您可以改变一起执行的Web服务、同一时间运行的Web服务数目，或者也可以改变关于是运行许多不同的服务还是运行许多同样的实例的决定。量级或许是最容易更改的 — 每次重复测试时都可以更改应用程序中出现的变量(例如，发送各种大小的消息或数字输入值)。如果测试完全随机的话，因为很难一致地重现压力下的错误，所以一些系统使用基于一个固定随机种子的随机变化。这样，用同一个种子，重现错误的机会就会更大。
　　
　　一个压力测试通常会结合上述的所有原则，并且在允许的范围内尽可能长时间地运行。测试被允许的执行时间越长，就可以遍历越多的代码路径，并且发现的错误也越多。当然，一旦找到错误就必须诊断并修复它。由于一个代码错误可以在压力测试运行多日以后自己显示出来，所以系统必须保证当出现错误时所有可用的调试信息都被生成，否则可能就必须花费同样多的时间来重现这个错误。
　　
　　结束语
　　
　　测试是软件开发过程中至关重要的部分，并且一个重要的、经常被曲解或忽略的部分是压力测试。遵循上面详细说明的原则，您就可以设计并实现有效的压力测试系统，用来查找一些与您的代码相关的、比较隐蔽的问题。无论是利用预先写好的工具，还是创建一个完全专用的压力系统，压力测试都是用于查找Web服务(或其他任何程序)问题的本质方法 

 

网站压力测试工具集

工具 相关网址 LoadRunner http://www.mercuryinteractive.com/products/loadrunner/ SilkPerformer http://www.segue.com/products/load-s ... nce-testing/index.asp QALoad http://www.compuware.com/products/qacenter/qaload.htm WebLoad OpenSTA 开源 Jmeter 开源 自动测试工具集 工具 相关网址 WinRunner http://www.mercuryinteractive.com/products/winrunner/ SilkTest http://www.segue.com/products/functio ... l-testing/silktest.asp QARun http://www.compuware.com/products/qacenter/qarun.htm SAFS http://safsdev.sourceforge.net/Default.htm Bug追踪系统 工具 相关网址 JIRA http://www.atlassian.com/software/jira/ Bugzilla http://www.bugzilla.org TestDirector http://www.mercuryinteractive.com/products/testdirector/ GNATS http://www.gnu.org/software/gnats/ TestTrackPro http://www.seapine.com/ttpro.html 软件测试网站 http://www.ltesting.net Webserver Stress Tool Enterprise v7.0.2.173 特别版 简介说明： 可以模拟任何人数在同一时间內进站或是顺序进站时你的 Server 的反映表现，只要输入网站的

*********输入框测试思路*********

    1．验证输入与输出的是否信息一致；

　　2．输入框之前的标题是否正确；

　　3．对特殊字符的处理，尤其是输入信息徐需要发送到数据库的。特殊字符包括：'（单引号）、"（双引号）、[]（中括号）、（）（小括号）、{}（大括号）、；（分号）、<>（大于小于号）……

　　4．对输入框输入超过限制的字符的处理，一般非特殊的没有作出限制的在255byte左右；

　　5．输入框本身的大小、长度；

　　6．不同内码的字符的输入；

　　7．对空格、TAB字符的处理机制；

　　8．字符本身显示的颜色；

　　9．密码输入窗口转换成星号或其它符号；

　　10．密码输入框对其中的信息进行加密，防止采用破解星号的方法破解；

　　11．按下ctrl和alt键对输入框的影响；

　　12．对于新增、修改、注册时用的输入框，有限制的，应该输入时作出提示，指出不允许的或者标出允许的；

　　13．对于有约束条件要求的输入框应当在条件满足时输入框的状态发生相应的改变，比如选了湖南就应该列出湖南下面的市，或者选了某些条件之后，一些输入框会关闭或转为只读状态；

　　14．输入类型；根据前面的栏位标题判断该输入框应该输入哪些内容算是合理的。例如，是否允许输入数字或字母，不允许输入其他字符等。

　　15.输入长度；数据库字段有长度定义，当输入过长时，提交数据是否会出错。

　　16.输入状态；当处于某种状态下，输入框是否处于可写或非可写状态。例如，系统自动给予的编号等栏位作为唯一标识，当再次处于编辑状态下，输入框栏位应处于不可写状态，如果可写对其编辑的话，可能会造成数据重复引起冲突等。

　　17．如果是会进行数据库操作的输入框，还可以考虑输入SQL中的一些特殊符号如单引号等，有时会有意想不到的错误出现

　　18．输入类型  输入长度  是否允许复制粘贴  为空的情况  空格的考虑  半角全角测试  对于密码输入框要考虑显示的内容是*  输入错误时的提示信息及提示信息是否准确

　　19．可以先了解你要测试的输入框在软件系统的某个功能中所扮演的角色，然后了解其具体的输入条件，在将输入条件按照有效等价类，无效等价类，边界值等方法进行测试用例的设计。

　　20．关键字有大小写混合的情况；

　　21．关键字中含有一个或多个空格的情况，包括前空格，中间空格（多个关键字），和后空格；

　　22．关键字中是否支持通配符的情况（视功能而定）；

　　23．关键字的长度分别为9、10、11个字符时的情况；

　　24．关键字是valid，但是没有匹配搜索结果的情况；

　　25．输入html的标签会出现哪些问题？输入&lt；html&gt； 会出现什么问题呢？

*********输入框常规测试数据*************

    1.      常规：中文、英文、数字

　　2.      日文：こんにちは

　　3.      韩文：????????

　　4.      繁体：測試

　　5.      Html、js：</table><hr><script>alert(’a')</script>

　　6.      特殊符号：`~!@#$%^&*()_+-=[]\{}|;’”:,./?><★??????Ξ‰※ⅶ∮⌒█

　　7.      GBK内码扩展汉字：喆骉犇羴鱻乸亹倊郈辷

　　8.      禁忌词：（根据禁忌词库）

　　9.      连续不间断英文：　　

Sdfsjdhuweqwieqknsmnfsdfweiwqdzkcxkjgleijsklfjskdlfjwiqwnnskfsdfhwuekjfsfwiersfjsldjfsaidfwejkfsjdkfsahuwefljsdnfelrtweijmsdflsjriwqskdajwewerwrdfgdgderertertdfgdfgdfgerdfgdfgerdfgsdger

　　10.  多行文本：

　　测试line1

　　测试line2

　　测试line3

　　11.  输入为空校验：空、空格（半角全角）、回车、NULL、&nbsp;

　　12.  边界值

　　13.  登录帐号：

　　中文：如“测试”

　　英文：如“test”

　　14.  特殊输入框——时间日期控件：时间格式

　　15.  特殊输入框——数字：正数、负数、0、浮点数

　　16.  特殊输入框——邮箱：邮箱格式

　　17.  特殊输入框——url地址：url格式，http://为首、不包含http://、https://为首、ftp://为首等

　　18.  特殊输入框——身份证：最末尾是否支持X、x

*********输入框测试考虑侧重点*********

测试重点:

　　一、普通输入框字段校验测试

　　二、邮箱输入框字段校验测试

　　三、验证码输入框字段校验测试（假设是4位数字）

　　四、手机号码输入框字段校验测试（假设限制16个字符，只能输入数字）

　　异常情况包括如下:

　　一、普通输入框字段校验测试

　　01）不输入，空内容

　　02）输入1个字符

　　03）若输入框有长度限制为N个字符，测试N-1个字符，N个字符，N+1个字符，N+N+...（超长）这几个边界值

　　还需要测试下通过复制大于长度的值粘贴进去看是否能输入

　　04）输入半角/全角空格

　　05）输入半角/全角，大写/小写英文字符

　　06）输入半角/全角数字

　　07）输入简体中文字符（默认全角）

　　08）输入繁体中文字符（默认全角）

　　09）输入半角特殊字符：！@＃￥%……&*（）

　　10）输入全角特殊字符：!@#$%^&*()

　　11）输入html字符保持：&nbsp空格的转义字符；<scrīpt></scrīpt>；<br>；<tr>；<td>；< /tr>；</td>；</html>；</body>；</table>

　　12）输入Javascrīpt函数：<b>Hello</b>，alert("hello")

　　13）在需要密码验证，或者需要二次输入确认的地方，通过复制粘贴第一次的输入内容应该是不能通过的

　　14）高危词，违禁词，敏感词

　　15）输入正常内容的前，后，中间加入多个空格，看保存时是否会过滤掉或过滤为一个，是否会引起保存问题，是否算入长度计算

　　16）输入日文字符

　　二、邮箱输入框字段校验测试

　　01）输入合理的英文及数字字符组成的正确格式

　　02）格式正确的前提下输入第一部分中的异常字段校验

　　03）输入无@的格式，如：ab.com

　　04）输入@前无内容的格式，如@b.com

　　05）输入@后无内容的格式，如a@

　　06）输入@前后均没有内容的格式，如@

　　07）输入没有域名的格式，如a@b.，a@b

　　08）输入email中有多个@的，如a@@b.com，a@b@c.d

　　09）输入@后面直接跟域名的，如a@.com

　　10）输入@后面有多个分隔符的，如a@b.c.d，a@b.c.d.e

　　11）输入@前面有分隔符的情况，如a.b@c.d，a.b.c@d.e，a.b@c，a.b.c@d

　　三、验证码输入框字段校验测试（假设是4位数字）

　　01）不输入，空内容

　　02）空格输入

　　03）输入空格+正确验证码，空格出现在开头，中间，结尾均需要测试

　　04）输入4位其他非数字内容

　　05）输入第一部分中的异常字段校验

　　06）输入前3位或后3位验证码正确数字

　　07）输入4位正确验证码+其他数字

　　四、手机号码输入框字段校验测试（假设限制16个字符，只能输入数字）

　　01）不输入，空内容

　　02）空格输入

　　03）输入空格+数字，空格出现在开头，中间，结尾均需要测试

　　04）输入其他非数字内容

　　05）输入第一部分中的异常字段校验

　　06）输入1个数字

　　07）输入16位数字

　　08）输入超过17位数字

　　09）输入超长全数字测试

　　10）输入空格+数字，空格出现在开头，中间，结尾均需要测试

为何进行白盒测试 从“清洗面包机”讲起

   软件白盒测试是一个与黑盒测试相对的概念，是指测试者针对可见代码进行的一种测试。白盒测试通常再划分为单元测试、集成测试两大类，但依据不同的流程，对白盒测试细分的标准也不尽一致，比如在IBM的IPD流程之下，白盒测试可能划分为如下几类：模块单元测试、模块集成测试、模块系统测试、渐增Build集成测试、系统集成测试等。而在XP实践中，单元测试与集成测试之间的界限并不明显，统称为渐增迭代测试。

　　一、从一个比喻开始

　　为什么要做白盒测试？这个问题比较复杂，我们先从一个比喻开始讲起。

　　假设有一台的面包机，从上面倒入面粉与水，开动机器后从下面出来的就是烤好了的面包，这个机器的功能比较单一，接口很清晰，输入是面粉与水，输出是面包。现在假定这个面包机多年未用，内部都生锈了，现在要清洗它，类似于我们开发的软件，软件有Bug，那得通过测试来清理。

　　



　　那如何更快速的清洗这台面包机呢？有两种洗法，一是拿水从上往下灌，这是系统测试的方法。另一种是拆开来洗，拆开机 器后，拿抺布沾点清洁剂，把各零件的坑坑槽槽擦洗一遍，然后组装回来，再用水从上往下冲一遍，拆开来洗是白盒方法，组装回来用水冲是黑盒方式，相当于白盒 测试之后再追加一次系统测试。

　　无疑，上面第二种方法是正确的，我们的前提是：清洗多年未用的面包机，铁锈够多，如果洗不干净，造出的面包都是致癌物质。当然，清洗面包机还只能算简单劳动，清理软件中的Bug要复杂得多，一个if语句有两条分支，一个while循环判断也是两条分支，还有break、continue、return等，想想看，一个1万行规模的软件能有多少个分支！一个分支就是一条坑坑槽槽，而且软件Bug还具备动态特性，不是静止的明摆在哪儿。

　　所以，软件的白盒测试不可或缺，因为遗留Bug的影响很大，就像面包机没洗净留铁锈会致癌，还因为软件系统远比面包机复杂，不拆开来怎么能洗干净！

　　二、白盒测试是高效测试

　　尽管白盒测试如此重要，为什么还有许多企业不愿做白盒测试，有一个很重要的原因是：认为白盒测试太低效，不值得去做。

　　实际上这种观点有许多误解成分，首先，决策者评估各阶段测试的有效性，仅以发现问题的数量为依据，这好比锈蚀斑斑的面包机，第一次冲水下去，看到大量浊水流出就很有成就感，其实这只是表象，思维方式有不足：把发现问题与解决问题割裂开来了。

　　我们测试的目标是按既定质量标准稳定推进产品研发进度，只做系统测试的结果是：第一次冲水，很有成效，第二次冲水， 还能冲出点铁锈，第三次就没什么效果了。采用该手段并不能有效的达成既定质量目标。其次，研发质量改善，不只发现问题，还要定位问题、解决问题。白盒测试 是拆开来洗，发现、定位与解决问题不仅是彻底的，也是直接的，效率非常高，所以，单以发现问题数评估一个测试过程是否有效不尽准确，我们应该综合评估一个问题从被发现，到定位、解决，以及针对它完成回归测试的总效率。

　　下图来源于Capers Jones与McGraw-Hill的“Applied Software Measurement”文章，从该统计数据可看出，针对一个功能点的测试，若将问题发现、定位与解决都计算进去，单元测试效率最高，是集成测试的2倍，是系统测试的3倍。

　　



　　认为白盒测试低效的另一个误解是，决策者并未认清一个bug若遗留到下一阶段须多付出多少代价。经验数据表明，编码阶段的一个问题遗留到验收测试去解决，所须费用将增加5倍，如下图，一个问题越遗留到后面阶段解决，付出代价就越高，而且是成倍递增关系。




　　所以，越早测试就越能节约成本，白盒测试作为早期测试，跳过不做是得不偿失的。

　　依据上述原因，我们评估白盒测试效率时，通常将发现问题总数乘上一个系数K，以此为据再与其它测试方段的发现问题效率做对比，来权衡白盒测试值不值得去做。系数K取值与产品形态相关，按照实际经验，系数K取值区间为1.5~2.5，产品越复杂，出现问题越不容易解决的，K值要往大调。

　　三、白盒测试能彻底解决编码阶段引入的问题

　　前面我们分析了白盒测试是高效的测试，值得一做，下面我们要接着说明白盒测试必须要做，不可或缺。

　　先看一个案例，在某交换机产品的系统测试中，发现ISDN话机拨打某新业务号码时，在特定线路上，若一位一位的拨至18位，不会有问题，但如果先拨完号码再成组发送，会导致系统死机。这是一个导致死机的致命问题，最后定位出问题所在：呼叫处理的某段代码判断有误，本应小于18的判断，错写成小于等于18。

“什么叫成熟产品？只要有一个成功案例的产品就是成熟产品！”某国内大型软件公司CEO的这个经典观点广为流传，但其中的逻辑错误将风险带给了客户也带给了软件企业本身。国内一些软件企业居然一夜间成了万能公司，ERP ？ CRM ？OA？WorkFlow？我们都行！然而这些企业对软件测试的重要性大多认识不足，重开发轻测试的现象过于严重，很多公司没有专门的测试部门，测试工程师太少，开发人员兼作测试工作的现象十分普遍，在这种状况下推出的缺少严格测试等环节的软件产品只能给客户带来悲剧。

　　近年来，我国的软件企业已越来越意识到软件测试的重要性，逐渐加大软件测试在整个软件开发的系统工程中的比重。据调查统计，在成本上一般来说是“需求分析”和“规划确定”各占3%，“设计”占5%，“编程”占7%，“测试”占15%，“投产和维护”占67%.近些年来，测试成本的比例更有上升趋势 .

　　不成熟软件带来的风险

　　不成熟的软件产品是把测试成本交给了用户：企业往往是出于项目周期安排不当，或者根本没有安排专门测试，匆匆完成编码设计就将产品交付使用了。这样的后果自然是用户觉得产品漏洞百出，项目执行过程也遥遥无期，最后，项目双方都筋疲力尽，用户觉得受骗，而软件商则毁了声誉，追加了大量项目实施费用，可谓是“赔了夫人又折兵”。

　　企业逻辑的软件实现高于计算机技术：很多软件企业在没有做透前期调研的前提下就匆匆开始建设自己想象中的“大厦”，结果可想而知。当用户建立起真正的企业应用。才发现软件违背了企业逻辑，不得不进行修改。这样闭门造车无疑会给“大厦”带来致命伤害。

　　注重软件产品的质量和成熟度才会良性循环：有人把不成熟的软件产品比作是焦油坑中垂死挣扎的猛兽，布鲁克斯《人月神话》展示的可怕一幕在软件研发过程中屡见不鲜。很多软件企业常常将软件质量视为一种奢侈，如果有必要的话，为了更多功能、更快速开发或者更低成本，测试就可以被牺牲掉。然而，在实践中，如果软件开发组织对质量有一个坚定承诺，实际上可以加快开发，减少成本，并更容易地增加新的特性。在“已完成”的产品缺陷修复上花费的代价要比从一开始就修复高出很多倍。相反，一个从开始就加强产品质量的组织，是有远见和创新精神的，市场中的高质量软件将更具竞争力。

　　找出测试管理中的误区

　　笔者曾经从事专业的软件项目管理与实施，项目管理感受很深刻。有一些切身体会与读者分享。

　　吸取“前辈”经验。IBM在软件自动化测试技术核心的三个最佳成功经验是：尽早测试、连续测试、自动化测试，并在此基础上提供了完整的软件测试流程和一整套的软件自动化测试工具，组建一个测试团队，基于一套完整的软件测试流程，使用一套完整的自动化软件测试工具，完成全方位的软件质量验证。

　　别去“挖东墙补西墙”。由于项目研发期的“缺斤短两”，使项目实施和投入运行的初期 漏洞百出，时间一长用户会发疯，项目实施者也会发疯，国内前几年的众多的ERP项目失败的原因多出于此。项目实施的遥遥无期，将严重挫伤用户的耐性和信心。

　　代码与文档哪个值钱？多数项目管理者忽视了文档的重要性。对于大型软件的研发项目，还需要专业的测试过程管理软件来支撑大规模的信息交流和自动测试、代码的更新和版本的提交。这些文档和信息的价值从某种意义上甚至超出了程序代码本身。

　　全程还是后期？软件的设计阶段往往没有软件测试人员的参与，事实上设计上的缺陷往往是耗用成本最高，也是最难在开发后期修复的缺陷。而一个软件的质量与它有多大的设计缺陷有着密不可分的联系。而有经验的测试人员的质量意识，安全意识，对用户需求的了解及分析能力，对于打造高品质的软件设计都有着不可忽视的作用。

　　专职还是兼职？在传统的开发方式中，由于缺乏必要的配置管理和变更控制，测试工作根本无法提出具体的测试要求，加之开发人员的遮丑，测试工作往往是走走过场，测试结果既无法考核又无法量化，当然就无法对以后的开发工作起指导作用。事实上，每个软件项目都需要专业的测试人员进行相对独立的测试工作，从而保证软件项目的质量。

　　居安思危，控制风险。需求变更给测试带来的问题可能是灾难性的，客户需求不是变动的唯一来源。有时团队自身也能引起范围变动。团队的成员可能听说或“假设”解决方案因客户的实际要求而发生了变动。加强沟通和协作，随时了解变更的状态。

　　谁为产品质量买单？质量和质量控制应该是软件项目的的一项重要内容。但是，无论在消费类软件还是大型软件的测试领域，国内软件产品的质量掌控体系和标准都很模糊。质量控制越来越依托于公司在产品交付用户之前的测试工作的成败。

　　没有厚度就没有重心。软件测试过程的历史数据缺失是大多数软件项目失败的关键所在，这样的结论也许使很多人感到吃惊，但事实就是如此。因为这些历史数据是反映软件项目实施轨迹的第一手资料，是项目延续和反馈的基石。

　　省钱还是费钱？事实上，作为软件开发企业来说，投入人力，资金搞软件测试的最终目的还是离不开经济效益。而对与测试项目的管理也不能离开这个大前提。软件测试的经济效益主要来自以下两个方面。一是满足用户需求，提高产品的竞争力，最终提高产品的销售量。二是尽早发现缺陷，降低售后服务成本。而软件测试的最终目的就是使它带来的经济效益最大化。有一些专业的测试工具的购买、测试人员的配备和培训还需要一定的经济投入，项目决策者们可以选择适合自己的配置，但决不能没有这些方面的投入。

　　沟通还是对立？沟通是开发和测试人员必备的素质。但传统的思想认为，测试人员是找麻烦，是开发的“克星”。其实，项目管理者应该清楚，为软件的质量和品质努力的工作目标是一致的。沟通和建立沟通渠道是项目管理者的重要工作。

　　如何提高软件测试水平

　　要提高我国的软件测试行业的发展水平，首当其冲要解决软件测试队伍的问题。某著名国际软件企业的软件测试人员与软件开发人员的比率达到了3：5左右，并且在实践过程已经证明了这种人员结构的合理性。但国内公司显然一时很难达到，但更重要的是重视程度，在这个基础上壮大软件测试队伍，提高测试人员的素质。

　　其次是要学习借鉴国外完善的测试机制，包括丰富的软件测试经验，强大的测试工具，优秀的测试管理水平。真正解决测试手段落后、测试方法单一和测试工具欠缺的问题，在企业内部形成一个严密有效的纠错系统，使国内的测试工作流程、 技术水平接近国外先进水平，这样才能提高国内软件开发与测试的整体管理水平，增加软件产品的竞争力。

　　此外，要重视第三方的测试力量。第三方的专业测试企业是靠技术与服务来赢得客户信任的，也因此更加注重测试方法与质量。对于软件企业来说，从无到有地去建立测试部门，并完善测试体系，需要较大投入，将研发出来的软件产品交给实力强劲的第三方专业测试公司，在提高软件产品的质量问题同时，还节约了产品测试成本。

相信很多团队都有这个问题：编码人员和测试人员经常争论。测试人员说编码人员做的东西太烂，问题太多，缺乏规范，开发文档也没有；编码人员说测试人员责任心有问题，测完了还是令自己不放心；还有很多人认为“如果发布出去的软件有问题，就是测试人员的责任”，理由是“测试人员应该在发布之前把所有问题都找出来” 【1】。

为什么会这样？我们来简单剖析。

首先，我们先要叙述一条“公理”：任何人都不能保证其工作成果总是100％完美的。即任何人都不能做到“0缺陷”。

因此，任何一个开发团队做完了都必须经过测试，尽可能的发现潜在问题并修复后才能发布出去。所以，测试人员必须竭尽所能发现缺陷。注意了，基于上述“公理”，任何测试人员都不能保证把软件中的潜在问题100％的找出来[参见《体检报告中的“未见异常”和软件测试》]。这样说来，上述【1】的说法是有失公允的。

那为什么会争吵呢？第一，出了问题的时候编码人员和测试人员是直接责任人，并且要负责解决问题，因此很容易引起情绪上的冲动；而且多数人遇到责任归咎的时候会本能的为自己开脱。第二、大家都忽略了“任何人都不能0缺陷”的公理。

但是，这并不表示有了这个“公理”，所有人就可以心安理得的面对所有缺陷了。任何产品的主要竞争力最终来自质量。因此对质量的无限追求，是任何团队的要求。也就是说，虽然我们不能要求每个团队的工作成果100％完美、0缺陷，但是我们总期望我们的成果能够尽量趋于完美，比如99.9997％，所谓的“六西格玛”。

怎么样做到尽量趋近于完美？这可能受到多种因素的影响，比如团队的工作能力、工作态度以及项目客观因素；还有管理、过程、工具，等等；可能会有很多！但是，我们可以简单归结为所有参与者工作成果的近乎100％的完美！所以，不要争论，从自己这里开始找原因，去改进！

软件开发者需做代码复查的五大原因:

1. 开发人员若得知他们的代码会被评估，他们会更加努力工作。

2. 代码审查可以改进开发人员的编程技术

3. 代码审查有利于导师制度，程序员们会学到更多
4. 代码审查可以实现优质文化的传承
5. 代码审查可以激发团队凝聚力

测试的目的应该是验证需求

测试的目的是什么呢？这是一个看起来很简单、不太值得讨论的问题，但往往这样的问题其实是很难回答的，比如人生的意义是什么？好，现在我们就来，列举一下我们经常听到的对这个问题的回答：

“软件测试的目的是尽可能发现并改正被测试软件中的错误，提高软件的可靠性。”，这个定义听起来很正确，但用它来指导测试会带来很多问题。比如有的组织用发现的bug数来衡量测试人员的业绩，其实这就是这种测试目的论在后面作祟，其结果如何呢：其一，有一些不够敬业的测试人员会找来一些无关痛痒的bug来充数，结果许多时间会被浪费在这些无关痛痒的bug上（其实应该修复，何时修复，严重程度是什么，优先级是什么，等等）；其二，测试人员会花很大力气设计一些复杂的测试用例去发现一些迄今尚未发现的缺陷，而不关心这些缺陷是否在实际用户的使用过程当中是否会发生，从而浪费了大量的宝贵时间。究其根源，就是因为对测试目的的这种错误理解造成的，为什么这么说呢？因为软件里bug的数量是无从估计的，那么如果测试的目的是为了找bug，那么测试工作将变成一项无法完成也无法衡量进度而且部分无效的工作（因为有些bug在实际的运行过程当中根本不会发生）。

“测试的目的就是为了保证软件质量”，这个定义也是看似正确，但实际上，混淆了测试和质量保证工作的边界。软件质量要素有很多，包括：Understandability、 Conciseness、Portability、Consistency、Maintainability、Testability、 Usability、Structures、Efficiency、Security等等，所以，软件质量保证和测试其实关注的方向是不同的。

那么测试的目的应该是什么呢？IEEE在1983年提出了软件测试的定义：
“使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。”

所以，简言之，测试的目的应该是验证需求，bug（预期结果与实际结果之间的差别）是这个过程中的产品而非目标。测试人员应该象工兵一样，在大部队（客户）预期前进的方向上探雷、扫雷（bug），而不需要去关心那些根本没有人会去碰的地雷。衡量一个测试人员应该去衡量他/她测试了多少需求（测试工作量），漏过了多少bug（测试有效性）。（在后面的博文里我们会进一步谈测试后评估的重要性）

因此，我们可以看到有好的需求文档/体系对测试工作的必要性，我们看到许多测试团队在业务需求/软件需求不完备的情况下，往往或重新编写测试需求。

　一. 功能测试

　　1. 安装测试：

　　1) 安装过程中对于缺省安装目录及任意指定的安装目录，是否都能正确安装；

　　2) 若是选择安装，查看能否实现其相应的功能；

　　3) 在所有能中途退出安装的位置退出安装程序后，验证此程序并未安装成功（没有程序组及程序项产生）；

　　4) 软件安装后，对其它已经安装的软件是否有影响；

　　5) 裸机安装后，各功能点是否可用；

　　6) 安装前，安装程序是否判断可用磁盘空间大小，如果不能满足安装空间要求，安装程序能否继续；

　　7) 安装过程中查看 版权声明、版本信息、公司名称、LOGO等是否符合标准；

　　8) 安装过程中界面显示与提示语言是否准确、友好；

　　9) 重复安装时系统是否有提示、是否可以覆盖安装、是否可以升级安装、是否允许多版本共存；

　　10) 是否有注册码或硬件加密狗，在没有它们（或错误）存在的情况下能否顺利安装。

--------------------------------------------------

一：基本目标
1.安装程序能正确运行
2.程序安装正确
3.程序安装后能正确运行
4.完善性安装后程序能正确运行
二：一些方面
0、安装手册给的所有步骤得到验证；
1、安装过程中所有缺省选项得到验证；
2、安装过程中典型选项得到验证；
3、测试各种不同的安装组合，并验证各种不同组合的正确性(包括参数组合，控件执行顺序组合，产品安装组件组合，产品组件安装顺序组合(如b/s)等)
4、安装过程中异常配置或状态（非法和不合理配置）情况进行了测试(如：断电；数据库终止，网络终止等)
5、安装后是否能产生正确的目录结构和文件，文件属性正确；
6、安装后动态库是否正确；
6、安装后软件能否正确运行；
7、安装后没有生成多余的目录结构,文件，注册表信息，快捷方式等；
9、安装测试应该在所有的运行环境上进行验证(手册上指定如：操作系统，数据库，硬件环境，网络环境等)；
10、自动安装还是手工配置安装
11、至少要在一台笔记本上进行安装/卸载测试，因为有很多产品在笔记本中会出现问题，尤其是系统级的产品
13、安装,该系统是否对其他的应用程序造成不正常影响（如操作系统,应用软件等)
14、众多web服务，会不会有冲突等:
a 是否可以识别大部分的硬件；对串口硬盘的支持；常见的显卡/声卡的支持；
b 确认打包程序的特性，比如installshield,不同的打包发布程序所支持的系统都是不一样的，
　　一个软件应该只能在确认的适应的系统上安装
c.空间不足的情况，安装过程中如果像安装盘放入大量文件
d.卸载过程不得删除系统应该保留的用户数据

---------------------------------------------------

　　2．配置测试

　　1) 是否可以按照用户手册的说明，运行于多种操作系统（Windows 各版本 、Unix 、Linux 等）；

　　2) 按系统最低要求进行软件的安装配置，查看能否正常实现各种功能；

　　3) 数据源等信息配置不正确时能否给出提示信息；

　　4) 是否可以按照用户手册的说明，支持多种数据库。

　　3. 卸载测试

　　1) 卸载后注册表中的注册信息及相关的程序安装目录是否能完全删除掉；

　　2) 卸载过程中完全删除共享文件后，看其它程序能否正常运行；

　　3) 卸载后，是否对其它已经安装的软件有影响；

　　4) 系统卸载后用户建立文档是否保留；

　　5) 软件卸载画面上的软件名称及版本信息是否正确；

　　6) 在所有能中途退出卸载的位置是否能正确退出；

　　7) 卸载过程中界面显示与提示语言是否准确、友好；

　　8) 卸载后安装此系统能否打开原来保存的文件，并一切运行正常；

　　9) 卸载程序如果要求重新启动机器，在重启动之间是否给用户提示以保存现有的己运行的程序的资料；

　　10) 是否可以选择组件进行卸载；

　　11) 卸载过程中，对意外情况的处理（掉电等）。

　　12) 在卸载过程中，是否有终止或者结束按钮。

--------------------------------------------------

文件－－－－安装目录里的文件及文件夹（如：程序安装在几处的)
非安装目录（向系统其它地方添加的文件及文件夹）它们包括（exe,dll,配置文件等)
快捷方式－（桌面，菜单，任务栏，系统栏,控件面板，系统服务列表等）
复原方面－卸载后，系统能否恢复到软件安装前的状态（包含目录结构、动态库,注册表，系统配置文件,驱动程序,关联情况等）(专门的测试工具regsnap)
卸载方式－－程序自带卸载程序/系统的控件面板卸载/其它自动卸载工具（如:优化大师)
卸载状态－－程序在运行/暂停/终止等状态时的卸载
非正常卸载情况－卸载软件过程中，取消卸载进程，然后，观察软件能否继续正常使用
冲击卸载－－在卸载的过程中，中断电源，然后，启动计算机后，重新卸载软件，如果软件无法卸载，则重新安装软件，安装之后再重新卸载。
卸载环境－－不同的(操作系统，硬件环境，网络环境等)下进行卸载
卸载后,该系统是否对其他的应用程序造成不正常影响（如操作系统,应用软件等)

----------------------

　　4. 运行与关闭测试

　　1) 运行时是否与其它应用程序有冲突(内存冲突)；

　　2) 是否可以同时运行多个程序；

　　3) 任务栏有无程序运行提示；

　　4) 若有未保存的数据，关闭系统时是否有提示；

　　5) 后台服务程序在点击关闭按钮时是否有确认提示；

　　6) 运行时是否过份占用系统资源、退出时能否完成释放占用的系统资源。

　　5. 服务程序的测试：

　　1) 系统是否限制服务器程序启动的数量,如不限制,同一范围内启动多个服务是否对系统有影响；

　　2) 服务程序能否长时间正常运行；

　　3) 外界异常后，服务程序的自动恢复能力（服务器掉电、网络中断后恢复、数据库异常后恢复…）；

　　4) 在点击关闭按钮时是否有确认提示；

　　5) 应用程序与其他程序是否兼容（能否避免内存冲突）。

 6. 系统管理（参数设置）

　　1) 参数设置后，能否正确的进行应用；

　　2) 设置错误参数，系统的容错能力；

　　3) 修改参数，对与之相关模块的影响；

　　4) 系统是否有默认的参数，A 有：默认的参数是否起到作用 ；B 没有：不设置，系统能否运行或者给出提示。

　　7. 用户、权限管理

　　1) 赋予一个人员相应的权限后，在界面上看此人员是否具有此权限，并以此人员身份登陆，验证权限设置是否正确（能否超出所给予的权限）；

　　2) 删除或修改已经登陆系统并正在进行操作的人员的权限，程序能否正确处理；

　　3) 重新注册系统变更登陆身份后再登录，看程序是否能正确执行，具有权限是否正确；

　　4) 在有工作组或角色管理的情况下，删除包含用户的工作组或角色，程序能否正确处理；

　　5) 不同权限用户登录同一个系统，权限范围是否正确；

　　6) 覆盖系统所有权限设定；

　　7) 能否添加信息为空的用户(其中包括空用户名及空口令、空用户名非空口令、非空用户名及空口令)；

　　8) 能否添加长用户名及长口令，如果允许，新用户能否正确登录；

　　9) 系统是否允许删除系统管理员这一特殊用户或修改系统管理员口令，删除或修改后系统的实际情况；

　　10) 登录用户能否修改自己的权限；

　　11) 添加用户（有标识或编号）:标识相同，用户名不同；标识相同，用户名相同；标识不同，用户名相同；标识不同，用户名不同；

　　12) 登录用户能否修改本人（或其他人）的信息，删除本人（或其他人）；

　　13) 修改用户的信息（包括权限，口令，基本信息等），对其他模块的影响；

　　14) 修改用户信息：修改后的用户信息和已经存在的用户信息相同；修改后的用户信息和已经存在的用户信息不同；

　　15) 不给用户授权，是否允许登录；

　　15) 改某些设置时，是否会影响具有上级权限及相同权限人员的设置；

　　16) 系统管理员修改了某些数据，以其他人员身份登录时数据是否改变；

　　17) 用户能否同时属于多个组，各个组的权限能否交叉；

　　18) 删除后重新添加的用户是否具有以前的权限；更改用户各项属性（包括权限）看对权限是否有影响。

　　8. 系统登录测试

　　1) 使用合法用户登录系统；

　　2) 用户名、口令错误或漏填时能否登陆；

　　3) 系统是否容许多次非法登陆,是否有次数限制；

　　4) 使用已登录账号登录系统系统能否正确处理；

　　5) 使用禁用帐号登陆系统能否正确处理；

　　6) 删除或修改后的用户用原用户登录；

　　7) 不输入用户名和口令，重复点“确定”和“取消”按钮，是否允许登录。

　　9. 注销

　　1) 注销为原模块、新模块系统能否正确处理；

　　2) 中止注销能否返回原模块、原用户；

　　3) 注销为原用户、新用户系统能否正确处理；

　　4) 使用错误的帐号、口令或无权限帐号、被禁用帐号进行注销。

　　10. 修改口令

　　1) 正常情况；

　　2) 输入错误的原口令或新口令与确认口令不一致系统能否正确处理；

　　3) 修改口令后，用原口令是否能登录（同时验证新口令是否有效）；

　　4) 是否能修改其它用户的口令。

　　11. 右键功能

　　1) 右键菜单中的功能是否与菜单（或工具栏）中对应的功能一致；

　　2) 右键菜单中的功能能否正确实现；

　　3) 同一菜单下的热键是否相同。

　　12. 记录列表

　　1) 增加重复记录、空白记录，系统能否正确处理；

　　2) 修改后不保存（有保存按钮），系统能否正确处理；

　　3) 删除或修改正在使用信息，系统能否正确处理；

　　4) 删除级联记录的上游或下游记录，系统能否正确处理；

　　5) 删除记录时是否有提示；

　　6) 记录中包含的缺省系统信息能否删除和修改；

　　7) 记录列表能否及时反应记录的变化；

　　8) 记录变化之后系统相关信息能否及时更新；

　　13. 统计、查询

　　1) 对非法的时间范围系统能否正确处理；

　　2) 统计查询语句包含多个与或非条件时，系统能否正确处理；

　　3) 条件逻辑混乱，系统能否正确处理；

　　4) 多表查询统计及单表查询统计功能是否正确实现；

　　5) 分类查询、精确查询、无条件查询、组合查询能否完整列出满足条件的记录；

　　6) 能否按系统默认的条件进行查询；

　　7) 当统计时间段为当日、跨日、跨月、跨季、跨年度时，统计查询结果是否正确；

　　8) 当某些操作被别人取消后，设置条件段为取消前、取消后、包含取消操作的一段时间；

　　9) 以不同的权限登录时，统计、查询是否正确；

　　10) 在查询或统计大数据量时，系统是否允许终止操作；

　　11) 查询、统计按钮是否允许双击或更多的点击，系统做何反映；

　　12) 查询出的数据是否允许修改。

　　14. 文件操作

　　a、保存

　　1) 文件是否能够正确保存在在缺省位置或指定位置（本地、网络）；

　　2) 系统能否正确处理长文件名、特殊字符文件名保存；

　　3) 文件能否保存为其它扩展名；

　　4) 如应用程序对文件名区分大小写，当这些文件在导出到介质中时，系统能否正确处理；

　　5) 介质空间已满时，系统是否给出提示。

　　b、打开

　　1) 打开文件是否正确显示上一次保存的内容；

　　2) 系统能否正确处理非系统默认扩展名的文件；

　　3) 文件能否被其他程序正确打开；

　　4) 打开对话框中，是否有默认扩展名的文件类型；

　　5) 打开对话框时，是否有默认的路径。

　　c、打印输出

　　1) 是否按所设置的格式打印；

　　2) 是否有打印预览，能否设置打印字体，打印效果是否合乎客户要求；

　　3) 打印预览的内容是否正确，内容是否能够进行拖拽操作，是否影响实际的打印；

　　4) 安装或不安装打印功能模块，对其它模块是否有影响；

　　5) 打印机未安装系统有无提示；

　　6) 打印中途能否进行正常的打印中断，是否可以选择打印的内容。

　　7) 能否进行本地或网络打印。

　　d、导入、导出功能

　　1) 导入的文件格式非要求时，系统如何处理；

　　2) 导入、导出的有效文件能否完整正确地显示并被使用；

　　3) 导出后的文件是否允许修改，如果允许，导入后能否使用；如不允许，系统有何限制；

　　4) 导入，导出是否可以选择路径；

　　5) 在客户端和服务器端进行导入，导出；

　　6) 在客户端和客户端之间进行导入，导出；

　　7) 在本地进行导入，导出；

　　8) 不同文件格式的导入，导出。

　　e、检入与检出

　　1) 单文件、多文件检入与检出；

　　2) 能否多次检入与检出；

　　3) 文件检出后其它人能对其做何操作。

二．性能测试

　　具体用例不好设计，下面列出了一些有性能要求的测试点：

　　1) 查询

　　2) 保存

　　3) 统计

　　4) 刷新

　　5) 显示

　　6) 传输

　　7) 响应

　　8) 下载

　　打开网络上其它介质上的文件时，可制造网络拥挤情况下的文件打开操作。主要测试点，集中在几个点上。一是数据量小的时候主要的查询统计刷新等功能点；二是数据量积累到一定程度时的查询统计刷新时间，这里的一定程度是根据实际的项目和客户需求来定的。

　　三．极限压力测试

　　1) 接收大数据量的数据文件时间；

　　2) 大数据恢复时间；

　　3) 大数据导入导出时间；

　　4) 大批量录入数据时间；

　　5) 大数据量的计算时间；

　　6) 多客户机同时进行某一个提交操作；

　　7) 采用测试工具软件；

　　8) 编写测试脚本程序；

　　9) 大数据量的查询统计时间。

　　四. 容错测试

　　1) 通过断开网线的强制性停止数据传输以及重新将网线接上，查看提示信息及对系统的影响；

　　2) 系统断电，恢复后查看对系统的影响程度；

　　3) 死机后，看程序如何处理；

　　4) 服务器DOWN掉，客户端程序如何处理。

　　五．并发测试

　　1) 登录的并发操作：多人同时登录系统，使用不同或相同账号；

　　2) 提交的并发操作：多人同时提交相同的工作项、不同的工作项；

　　3) 对数据库操作的并发操作：多人同时从数据库中读出（或向数据库导入） 相同文件、不同文件。

************************

　　附：一些容易出错的地方

　　************************

　　一. 有关新建和修改

　　1. 创建或修改的内容为已经存在的内容，系统是否有提示；

　　2. 修改正在使用的数据。

　　二. 删除

　　1. 应有确认提示；

　　2. 若删除的内容在文件或数据库中，应作实际校验；

　　3. 删除正在使用的数据；

　　4. 考虑删除数据的相关数据是否同时被删除；

　　5. 重新使用已删除的数据。

　　三．关于提示信息的验证

　　有些操作系统会给出成功（有时没有成功提示）或失败的提示，一定要验证提示的正确性（尤其是一些重要操作，如修改口令），即用其它方法检查所作的操作是否真正成功或失败。

　　四．关于考虑硬盘空间已满的情况

　　1. 数据存储和备份；

　　2. 生成文件；

　　3. 拷贝文件

　　五．关于修改系统时间

　　对于和时间有关的业务，测试时考虑修改系统时间对系统的影响。

　　六．对于响应速度慢的按钮进行连续点击；或中途取消，再继续…

　　七．凡是支持并发过程的功能，一定要做并发测试（手工进行或利用工具）；

　　八．打印功能（能否正确打印，打印效果与预览是否一致）

　　九．系统初始化

　　1) 如果系统安装后需要进行初始化，初始化过程是否正确；

　　2) 如果系统安装后不需要进行初始化，安装后的默认设置是否正确、适当。

　　十．版权声明是否符合标准，如果有公司的logo，图标是否正确（最容易测试的地方，也是最容易被忽略的地方）

　　十一．如果捆绑硬件，如果可能的话，在测试我们的软件产品前要对硬件的性能、稳定性进行严格测试。（包括大数据量的传输入等）

　　十二．备份与恢复

　　1) 备份与恢复过程本身的正确性；

　　2) 备份内容的正确性（通过事先准备的测试数据在恢复后验证）；

　　3) 备份与恢复过程中对异常情况的处理（掉电、网络不通等）；

　　4) 在原始机上的恢复；

　　5) 在非原始机上的恢复；

　　6) 在裸机（只有操作系统和必要的数据库或第三方产品）上的恢复；

　　7) 在一台机器上进行若干次的备份与恢复；

　　8) 如果是支持多数据库的软件，备份与恢复是容易出错的地方。

　　需要严格把握的错误类别：

　　在整个测试过程中对每条问题都制定有错误归类，现按照问题的严重程度，把问题主要分为四类：

　　A：严重影响系统运行：导致系统出现不可预料的严重错误的问题，例如：运行过程中出现页面或页面无法显示、死机等；

　　B：影响系统运行：系统中重要的功能出现运行错误，例如：导致用户必须重新登录的问题，导致个别用户不可用的问题；

　　C：不影响系统运行但必须修改：系统中基本的操作或功能没有实现或实现有误的问题，以及不符合常规的操作界面的问题；

　　D：所提建议：不影响系统运行，对系统的可用性等提示的建议性的问题。

报表测试注意事项

进销存系统中的报表测试

 报表功能的基本要求，就是通过查询/统计/分析，提供用户所需的准确的数据。如果无法实现这个基本功能，则报表完全失去意义。

对于用户来说，报表可以直接影响到他们的决策，例如可能因为报表对销售和库存情况反映的不准确，导致错误的大量进货；或者因为报表对应收应付金额计算的不准确，而导致企业对资金占用情况做出错误的估计，

从而导致错误的决策，最终造成用户在经营上的损失。诸如此类，相信只要大家留心，还可以找出很多这样的例子。

进销存系统中的报表多如牛毛，而且各种不同行业的进销存系统中的业务有区别，报表也有些区别，因此不太可能对各种报表逐个讲解，而主要是把一些报表测试的经验总结成了十几条可以在各种行业的报表测试中应用的“最佳实践”，来跟大家一起分享。希望下面的这十几条像一招招简单实用的“擒拿手”，可以供正在进行报表测试或者准备开始作报表测试的朋友随手拈来，见招拆招，轻松应对这项工作。

（1）提高对业务的熟悉程度

    其实对任何一个软件进行测试，都必须要熟悉它的业务，包括业务流程和业务规则。但是报表同一般的业务功能还是有些区别的。例如对于单据的增、删、改，通过对界面的浏览和探索性的操作，大概都可以弄明白它的业务流程和业务规则，因为这些内容比较直观，而且在不同的行业中也差不了太多。但是在报表中，是很难直观的看到我们所需要了解的内容的。例如报表中的某个数据项，它的算法或者说数据来源，恐怕是比较难看出来的——即使是很类似的一个数据项，在不同行业的实际业务中，它的算法和数据来源也可以能完全不同的。

所以对于报表业务的熟悉，主要是两个方面：数据项的算法和数据来源，也就是说要明白一个数据项同具体的业务有什么关系，单据的增、删、改或者状态的变化，对报表中各个数据项的计算会产生什么不同的影响。如果不知道到这些，那么就无法验证报表中的数据是否准确，也无法通过报表去检查业务系统的正确与否。

（2）覆盖所有可能的查询统计方式，而不是以自己的使用习惯为准

    对于报表的使用者来说——一般是企业的中层或高层领导，他们对于报表的要求可能会是多方面的，例如在进销存系统中，可能需要按不同商品进行分类统计，也可能是按供应商分类统计，这些都是由用户在实际工作中的需要来决定的，所以假如一个报表提供了多种查询统计的方法，那么在测试时，只要时间充分，就应该覆盖这些所有可能被用到的查询统计方法，而不是以自己的使用习惯为测试的依据。

（3）使用或构造受控的数据环境

    数据对于报表测试来说是一个非常非常重要的问题。因为上面说到，报表的基本功能就是通过各种查询统计分析的方法，为用户提供准确的数据，帮助用户做出决策。那么那些用来进行测试的数据从哪里来呢？

    首先，应该保证准备足够多的有效的数据。前面一条也提到了，在实际测试报表时，应当尽可能的覆盖到报表所提供的各种查询统计方法，因此至少应该保证每一种查询统计方法都应该有对应的数据，得到的结果都不会是0，否则等于没有覆盖到这个被测的查询统计算法。当然数据也不是越多越好，能保证全部覆盖，并且刚好够用就可以了，因为数据的准备和生成也是很花时间的。

    其次，要保证数据的可控。数据并不是随意生成的，如果使用通过自动化工具或者通过业务测试时随意的输入的数据来进行报表测试，一般来说是不太可能的。因为如果无法控制数据来源，那么即使知道报表中每个数据项的算法，也无法最终验证报表的查询统计结果是否正确。例如，系统的会有不同类型的单据，每种单据又会有不同的状态，某个报表的统计中，可能会涉及到多种类型和状态的单据，那么在准备数据时，就要充分考虑到这一点，准备各种不同的单据来满足测试的要求。又比如，如果整个系统中只有一个供应商，一个商品，那么测试按供应商分类统计或者按商品分类统计的报表时，意义也就不大了。

    所以如果希望高有效、更高质量的完成报表的测试，那么就要重视并增加对于数据准备工作的关注：用于验证报表功能的数据，一定是专门为报表准备的，并且是经过精心设计，要分析影响数据项算法的各种因素，以及每个因素可能出现的不同变化，这样才有可能覆盖各种查询统计方法；同时，才能保证无论使用哪个数据项的算法进行计算，其结果都是可以预知的——因为数据来源已经被我们控制了。

    特别是对于算法比较复杂，又提供了多种查询统计方式的报表，如果想完整的测试，就需要准备大量的数据。而如果想高效、高质量的完成这项功能，就一定要理解数据准备工作的重要性。

    经过精心设计的数据还有一个好处，就是当在进行业务功能的测试时，不再需要使用一些随意的数据，而是可以通过业务测试的过程，把报表测试所需要的数据输入到系统中。并根据报表对单据类型和状态的需要，进行相应的操作。

    如果留心，你也会发现报表测试同其他业务功能测试的有个区别。业务功能（例如单据的新增、审核等）的测试用例设计，通常需要考虑的是对各种正常的、异常的业务流程和业务规则的组合的遍历或覆盖；而对于报表功能，虽然没有太复杂的业务流程和规则，但是算法更加复杂，同时报表功能本身就是一种对数据的加工处理，因此会更偏重于对于各种数据来源和算法的遍历或覆盖，也就是要准备各种正常的、异常的数据，来验证报表是否取到的该取的数据、没有取不该取的数据，并且最后计算出了正确的结果。

（4）特征性数据的准备

    这又是一个同数据准备有关的问题，也是一个解决实际问题的经验。如果由多人同时对一个系统进行测试，虽然大家各自使用的数据都是经过精心设计的，但是在实际进行报表测试时，还是很难保证其他人的数据不会对自己的测试结果产生影响，最明显的一个问题就是原来自己对结果是可以预知的——因为数据是经过精心设计的，是可控的，但是现在掺杂了别人的数据，就需要花时间去区分这种“假”的错误和真的错误。

有一个经验是可以借鉴的，就是在初期，团队内对数据的准备达成一致，使数据中的某一项具有特征性，例如分别使用不同的供应商，或者使用不同的商品。最后测试报表时，通过限定选取的数据来源，来保证相互之间尽可能的没有影响。

（5）做好数据环境的备份和维护

虽然数据是经过精心准备的，但是难免在操作过程中因为误操作导致环境的变化，例如不小心把一张单据变成了另外一种状态，或者某个类型的单据多做了一张。对于这种情况，一个简单的方法就是去维护你的数据文档——一般我们都可以用EXCEL表来保存我们事先准备的数据，可以一个文件保存一个类型的单据，例如采购单、入库单、出库单等等，文件中的每张表用来保存不同状态的单据，例如已经审核过的入库单，没有审核过的入库单，全部入库的入库单和部分入库的入库单，等等。假如你一不小心，把一张本来准备入一半的入库单全入了，那也不要惊慌，去重新调整一下你的数据文档，在相应的类型相应的状态的单据列表中新增一张就行了。

而如果想减少回归测试的工作量，那么应该考虑在一些关键的“点”上备份测试数据。例如所有的基础单据已经输入完成，但是还都没有开始审核或者出入库，那么可以备份一下，下次再测的时候可以直接在数据库中恢复这部分原始数据。

（6）在业务功能测试通过之后才开始

这一点相信应该不难理解，如果业务功能本身存在缺陷，导致的数据不准，那么最后进行报表测试也就没有什么意义了。所以，应该在保证各项同报表有关的业务的功能测试通过之后，才开始考虑对报表进行测试。

（7）寻求开发人员的协助

    在报表测试中很常见的一个问题，是需求文档中可能没有定义报表的各个数据项的算法，这时候你需要找开发人员帮忙，向他们了解准确的算法和相应的公式。

（8）多个报表相互对照

这是一项“高级”的报表测试技能，需要对整个系统中的各种业务的熟悉程度达到一种炉火纯青的地步。除了可以准确的说出各个业务的处理过程对每张报表的影响之外，还能够进行横向的联系，知道不同报表之间存在的关系。例如，一个简单的例子，库存报表中，你可以看到商品的出入库情况，而在销售报表中，你可以看到商品的销售金额和销售成本金额，在应收应付报表中，你又可以看到不同供应商或客商之间的应收应付金额。那么这几张报表之间，是否存在一些关联呢？是否会存在一些可以相互验证的地方呢？

（9）着重对那些算法复杂、与业务功能关联较多的报表的测试

    如果只是简单的把某个日期范围内的所有入库情况统计出来，可能不会出错；但是如果还要考虑按照供应商或商品汇总，同时要选取特定的类型或状态的单据，再进行一些响应的计算，恐怕就很难保证开发人员永远不会出错了。这就像业务功能的测试一样，越是复杂的业务，越有可能出错。

（10）留意四舍五入对报表数据的影响

从这一条开始，后面的内容可以说也是一些在实际测试时要注意的事项。

这也是一个常见的问题。在一般的进销存系统中，都会存在这种情况，无论小数点后保留几位，总是难以避免明细和汇总之间的差别。原因可能是因为采购和销售的包装不一致，因为拆零引起的，例如10/30*30≠10；或者由于毛利率、税率等因素导致的不一致。我们曾经试过在保留4位小数的情况下还是无法避免这种情况。

（11）留意进/存/销时使用不同单位对报表数据的影响

例如采购时是5箱，每箱有100盒，而销售单位是盒，入库之后，可能会要求按照销售单位来统计，这时要注意开发人员是否会选择了错误的单位，把500盒弄成5箱。

（12）留意业务单据中存在多个日期字段时对报表数据的影响

    一般来说，一张单据上都会有多个日期字段，比如采购单就有采购日期、单据日期、审核日期，而入库单也会有单据日期、入库日期，诸如此类。那么在测试时，一定要留意，开发人员是否按照要求选择了正确的日期，包括日期选取的一致性——是否存在这边取采购日期，那边取审核日期的情况。

（13）留意是否存在遗漏的单据类型

    例如像出入库的报表，入库方向的，除了最主要的采购入库外，可能还会包括退货入库、盘盈入库、报溢入库；出库方向的，除了最常见的销售出库，还会包括盘亏出库、报损出库。那么在具体测试时，一定要准备充分这些相应类型的单据，并且要留意开发人员是否遗漏了相应的单据类型。

（14）留意不同状态的单据对报表数据的影响

例如采购单，当采购单发出后，供应商会开始送货，可能第一批之送来了一半的商品，那么这时采购单的收货状态是“未完成” ；当供应商把商品送齐了以后，采购数量＝收货数量，则采购单的收货状态变为“已完成”。那这时留意，开发人员在采购报表中，是包含所需要的状态的单据，还是只包含了一部分？

（15）留意那些被当做默认规则的因素

有些规则——例如单据类型或者单据状态——是作为默认规则写死在SQL语句或者数据库的存储过程里面，这些规则不会体现在界面，也不会由用户选择决定。但是这些规则恰恰是最容易被忽略的部分。所以，一定要同开发人员反复确认，保证自己已经了解了同报表各数据项计算有关的各个因素。

（16）保证测试人员可以通过UI 找到自己所需的所有原始数据

在进行系统测试时，无论是报表，还是一般的业务功能测试，都不要去直接通过SQL语句查询数据库中的内容，而是通过UI来输入，再通过UI体现处理的结果进行验证——因为这是系统测试，不是集成测试，将来用户是决不会去直接查数据库的。因此，如果需要对报表的结果进行验证，应该通过其他的功能模块，去查询业务单据，或者其他报表，根据UI体现的结果，来进行确认。

（17）检查大数据量对报表的影响

    报表测试也会涉及到性能测试，主要是在大数据量查询统计的测试。大数据量一是说原始数据多，二是被操作、计算的数据多，三是某个数据项被是经过多次计算得出的。特别是对于一些算法比较复杂的报表，10万条数据和100万条数据时的响应时间将表现出巨大的差别。

（18）不要遗漏权限控制和访问安全性的测试

这里说的权限控制不是谁可以访问某个模块，谁不可以访问某个模块，而且数据的计算也没有直接的关系，而是侧重于报表设计的测试。我们都知道不同的报表是设计给不同的人看的，例如出入库报表是给仓库管理人员看的，里面不会包含商品的价格，而只会包含数量；而财务报表中，只会包含采购、销售的金额，而不会包含数量，这样才能保证可以相互对照，不会出现营私舞弊的行为。那么在测试时，应当考虑报表是否泄漏了不该泄漏的信息。当然，这里对业务的熟悉程度就是更高的要求了。

又如，不同的业务员只能看到同自己有关的业务，但是领导可以看到所有业务员的业务——例如不同的业务员分管不同的客户或者地域，他们之间的销售情况是互相保密的。

还有一种情况，系统的用户可能会为他的供应商提供一个专门的程序或者Web页面，供其对其供应的商品的销售、库存情况进行查看。那么对于这种情况，一方面是要保证某个供应商只能看到他所供应的商品的销售、库存情况，如果某个商品由多个供应商同时提供，那么其中一个供应商应该只能看到他提供的那部分，而看不到其他供应商提供的同一商品的情况。当然，这种功能一般都是通过外网（internet）来访问的，所以也还要考虑相应的访问安全性测试，以免泄漏重要的商业信息。

 

软件开发过程及软件质量保证
1.软件开发过程的几个主要阶段：
1）定义。明确开发的目标，软件的需求。
2）计划。制订软件开发所涉及到的计划。
3）设计。设计、编码、编写文档等，完成要求的软件特性。
4）稳定化。主要是测试和缺陷修复，确保软件的质量。
5）安装。安装、提交完成的软件，为客户提供运行环境。
2.几种常用的软件生命周期模型：
1）瀑布模型。
2）原型模型。
3）增量模型。
4）螺旋模型。
从软件测试人员的角度来看软件开发过程，需要注意的是：测试贯穿在整个开发过程中，而不是在某个阶段集中地做一下测试而其它阶段不用理会测试工作。

一个软件之所以被认为为质量优秀，是它内在具备了这样一些特性：
满足用户的需求；
合理进度、成本、功能关系；
具备扩展性和灵活性，能够适应一定程度的需求变化；
能够有效地处理例外的情况；
保持成本和性能的平衡。

软件质量保证(Software Quality Assurance-----SQA)是为了确保软件开发过程和结果符合预期的要求而建立的系列规程，以及依照规程和计划采取的一系列活动及其结果评审。

软件质量保证的活动主机包括：
技术方法的就用；
正式技术评审的实施；
软件测试；
标准的执行；
修改的控制；
度量；
记录和记录保存。

软件错误的定义：软件错误是软件产品中存在的导致期望的运行结果和实际结果间出现差异的一系列问题，这些问题包括故障、失效、缺陷。


软件测试：
软件测试就是为了发现软件中存在的错误而分析或执行程序的过程。具体地说，软件测试是分析程序或根据软件开发各阶段的规格说明和各程序的内部结构而精心设计出一批测试用例，并利用测试用例来运行程序，以发现程序错误的过程。

软件测试有两个基本的功能：验证(Verification)和确认(Validation)。
验证指保证软件正确地实现了特写功能的一系列活动。
确认指保证最终的产品满足系统需求。
通俗的说：验证保证产品的正确性；确认保证生产了正确的产品。

软件测试人员应该至少具备以下两个关键领域方面的知识：
1）软件测试技术；
2）被测应用程序及其相关应用领域知识。

理解以下的描述：
测试能提高软件的质量，但是提高质量不能依赖测试；
测试只能证明错误存在，不能证明错误不存在；
测试的主要困难是不知道该如何进行有效地测试，也不知道什么时候能够放心的结束测试；
每个程序员都应当测试自己的程序（份内事），但不能作为程序已通过测试的依据（所以项目需要独立的测试人员）；
80-20原则：80%的错误聚集在20%的模块中，经常出错的模块改错后还是会经常出错；
测试应当循序渐进，不要企图一次性做完。"欲速则不达"。

测试人员的目标和主要工作：
目标：（1）.基本目标是发现软件错误；
（2）.要尽可能早的找出软件错误；
（3）.必需确保找出的软件错误得以关闭。

主要工作：
1）规划测试任务
2）设计测试（包括编写测试用例等等）
3）建立一个合适的测试环境
4）评估、获取、安装和配置自动测试工具
5）执行测试
6）撰写适当的测试文档

软件测试的分类
1．从是否需要执行被测试软件的角度分：有静态测试和动态测试。
2．从测试是否针对软件结构和算法的角度分类分：白盒测试和黑盒测试。
3．从测试的不同阶段分：单元测试、集成测试、系统测试和验收测试四个阶段。
其中系统测试有：功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试等等。

针对某些功能作用的测试：
回归测试：指错误被修正后或软件功能、环境发生变化后进行的重新测试。
功能测试：测试软件的功能是否符合功能性需求，通常采用黑盒测试方式。
负载测试：测试软件系统的最大负载，超出此负载软件有可能会失常。
压力测试：与负载测试差不多，叫法不同。
易用性测试：测试软件是否易用，主观性比较强。一般要根据用户的反馈信息来评价。
安装与反安装测试：测试软件在"全部、部分、升级"等状况下的安装/反安装过程。
恢复测试：测试系统从故障中恢复的能力。
安全性测试：测试系统防止非法侵入的能力。
兼容性测试：测试系统与其它软件、硬件兼容的能力。
内存泄漏测试：测试软件在运行过程中是否会造成内存泄漏。
比较测试：通过与同类产品比较，考察该产品的优点、缺点。
Alpha测试：一种先期的用户测试，此时系统刚刚开发完成。
Beta测试：一种后期的用户测试，此时系统已经通过内部测试，大部分错误已经改正，即将正式发行。同Alpha测试一样都由用户进行，场地不同，Alpha测试一般是把用户请到开发方的场地来测试，Beta测试是指在一个或多个用户的场所进行测试。

测试工作的主要步骤：
1）测试计划：测试人员要首先对需求进行分析，最终定义一个测试集合。
2）测试设计与开发：根据软件需求、说明书完成测试用例设计并编写必要的测试驱动程序。
3）执行测试：需要做的工作是，建立测试环境；根据前面编写的测试计划和测试用例运行测试；记录测试结果；报告软件缺陷；跟踪软件缺陷直至其被处理；分析测试结果


PS　测试工程师职业素质
1）责任心
2）学习能力
3）怀疑精神
4）沟通能力
5）专注力
6）洞察力
7）团队精神
8）注重积累

在G.J.Myers的经典著作《软件测试之艺术》（The Art of Software Testing）中，给出了测试的定义：“程序测试是为了发现错误而执行程序的过程”。这个定义，被业界所认可，经常被引用。除此之外，G.J.Myers还给出了与测试相关的三个重要观点，那就是： 　

1. 测试是为了证明程序有错，而不是证明程序无错误；
2. 一个好的测试用例是在于它能发现至今未发现的错误；
3. 一个成功的测试是发现了至今未发现的错误的测试。

　　实际上，这里暗示了“软件测试”在不同侧面上的含义，也就决定了对软件测试不同的定义和不同的理解。根据作者多年的经验和理解，软件测试的不同视野，概括为如下5类：

• 软件测试的狭义论和广义论——静态和动态的测试
• 软件测试的辨证论——正向思维和反向思维
• 软件测试的风险论——测试是评估
• 软件测试的经济学观点——为盈利而测试
• 软件测试的标准论——验证和确认

　　1. 软件测试的狭义论和广义论

　　G.J.Myers所给出了测试定义——“程序测试是为了发现错误而执行程序的过程”，实际是一个狭义的概念，因为他认为测试是执行程序的过程，也就是传统意义上的测试——在代码完成后，通过运行程序来发现程序代码或软件系统中错误。但是，这种意义上的测试是不能在代码完成之前发现软件系统需求、发现设计上的问题，把需求、发现设计上的问题遗留到后期，这样就会可能造成设计、编程的部分返工。增加软件开发的成本、延长开发的周期等。需求阶段和设计阶段的缺陷产生的放大效应会加大。这非常不利于保证软件质量。这种狭义论是受软件开发瀑布模型影响。

　　正是为了更早地发现问题，所以将测试延伸到需求评审、设计审查活动中去，也就是将“软件质量保证”的部分活动归为测试活动。实际上，在软件开发实际操作中，常常将软件测试和质量保证——这两种努力（efforts）合并起来。

　　延伸后的软件测试，被认为是一种软件测试的广义概念。这就引出软件测试的两个概念“静态测试”和“动态测试”，如 测试方法的辩证统一 （1）所述，这样就由静态测试和动态测试构成一个全过程的、完整的软件测试，而且静态测试显得更为重要。

　　2.软件测试的辨证论

　　G.J.Myers的第2个观点“测试是为了证明程序有错，而不是证明程序无错误”，引出了软件测试的另外一个争论，软件测试究竟是证明所有软件的功能特性是正确的呢？还是其反向思维——对软件系统进行各种试探和攻击，找出软件系统中不正常或不工作的地方呢？从我个人理解，这两个方面都有一定道理，前者（证明所有软件的功能特性是正确的）是从质量保证的角度来思考软件测试，后者（证明程序有错）从软件测试的直接目标和测试效率来思考，两者应该相辅相成。在后者的思想背景下，我们认为，测试不是为了证明所有的功能可以正常工作，恰恰相反，测试就是为了找出那些不能正常工作、不一致性的地方。也就是说，测试的一般工作就是发现缺陷 (detect bug)，即在软件开发过程中，分析、设计与编码等工作都是建设性的，而测试是带有“破坏性”的工作。

　　对于不同的应用领域，两者的比重是不一样的，如国防、航天、银行等软件系统，承受不了任何系统失效，因为一次系统的失效完全有可能导致灾难性的损失，所以强调前者以保证非常高的软件质量。而一般的软件服务应用则不同，强调后者，质量目标设置在“用户可接受水平”，不要国度追求质量，从而可以降低软件开发成本。作者建议，在我们实际操作中，可以分阶段实施不同的测试思想，在早期阶段集中在“证明程序有错”—— 发现Bug，后期集中在验证所有特性是否正常工作——降低风险，见作者的另外一篇讨论：测试执行中非常有效的策略

　　下面就是这两种观点的基本描述：

• 验证软件是验证软件是“工作的”，以正向思维，针对软件系统的所有功能点，逐个验证其正确性。其代表人物是软件测试领域的先驱Dr. Bill Hetzel （代表论著《The Complete Guide to Software Testing》)。
  
• 证明软件是“不工作的”，以反向思维方式，不断思考开发人员理解的误区、不良的习惯、程序代码的边界、无效数据的输入以及系统的弱点，试图破坏系统、摧毁系统，目标就是发现系统中各种各样的问题。其代表人物就是上面多次提到的G.J.Myers。他强调，一个成功的测试必须是发现Bug Bug的测试，不然就没有价值。

　　3.软件测试的风险论

　　 测试被定义为“对软件系统中潜在的各种风险进行评估的活动”，这就是软件测试的风险论。软件测试自身的风险性是大家公认的，测试的覆盖度不能做到100％。测试的这种风险定义一方面源于这层含义，另外软件测试的标准有时不清楚，“软件规格说明书（Specification/ Spec）”是其中的一个标准，但也不是唯一的，因为Spec中有些内容完全有可能是错误的。所以，我们常常强调软件测试人员应该站在客户的角度去进行测试，除了发现程序中的错误，还要发现需求定义的错误、设计上的缺陷，可以针对Spec 去报Bug。但是，测试在大多数时间/情况下,是由工程师完成，而不是客户自己来做，所以又怎么能保证工程师和客户想得一样呢？

　　有人把开发比作打靶，目标明确，就是按照Spec 去实现系统的功能。而把测试比作捞鱼，目标不明确，自己判断哪些地方鱼多，就去哪些地方捞；如果只捞大鱼（严重缺陷），网眼就可以大些、撒网区域相对比较集中（测试点集中在主要功能-major features）。如果想把大大小小的鱼捞上来，网眼就要小、普遍撒网，不放过任何一块区域（测试点遍及所有功能——all features）。

　　在“风险”论的框架下，软件测试可以被看作是一个动态的监控过程，对软件开发全过程进行检测，随时发现不健康的征兆，发现问题、报告问题，并重新评估新的风险，设置新的监控基准，不断地持续下去，包括回归测试。这时，软件测试可以完全看作是软件质量控制的过程。

　　对应这种观点，产生基于风险的测试策略，首先评估测试的风险，功能出问题的概率有多大？哪些是用户最常用的20％功能——Pareto原则（也叫80/20原则）？如果某个功能出问题，其对用户的影响有多大？然后根据风险大小确定测试的优先级。优先级高的测试，优先得到执行，一般来讲，针对用户最常用的20％功能（优先级高）的测试会得到完全执行，而低优先级的测试（另外用户不经常用的80％功能）就不是必要的，如果时间或经费不够，就暂时不做或少做。

　　4.软件测试的经济学观点

　　“一个好的测试用例是在于它能发现至今未发现的错误”，体现了软件测试的经济学观点。实际上，软件测试经济学问题至今仍是业界关注的问题之一。经济学的核心就是要盈利，盈利的基础就是要有一个清楚的商业性目标。同样，商业性目标是否正确，直接决定了企业是否盈利的结果。多数情况下，软件测试是在公司内的执行。正是公司的行为目的，决定了软件测试含义或定义的经济性一面。正如，对软件质量的定义不仅仅局陷于“和客户需求的一致性、适用性”，而且要增加其它的要求——“预算内、按时发布、易于维护”。

　　软件测试也一样，要尽快尽早地发现更多的缺陷，并督促和帮助开发人员修正缺陷。原因很简单：平均而言，如果在需求阶段修正一个错误的代价是1，那么，在设计阶段就是它的3～6倍，在编程阶段是它的10倍，在内部测试阶段是它的20～40倍，在外部测试阶段是它的30～70倍，而到了产品发布出去时，这个数字就是 40～ 1000倍。修正错误的代价不是随时间线性增长，而几乎是呈指数级增长的。

　　5. 软件测试的标准论

　　如果从标准论来看软件测试，可以定义为软件测试就是“验证（Verification）”和“有效性确认（Validation）”活动构成的整体，即软件测试 = V&V。

　　“验证”是检验软件是否已正确地实现了产品规格书所定义的系统功能和特性。验证过程提供证据表明软件相关产品与所有生命周期活动的要求（如正确性、完整性、一致性、准确性等）相一致。相当于，以Spec为标准进行软件测试活动，验证软件产品和Spec的一致性。

　　“有效性确认”是确认所开发的软件是否满足用户真正需求的活动。相当于，保持对软件需求定义、设计的怀疑，一切从客户出发，理解客户的需求，发现需求定义和产品设计中的问题。这主要通过各种软件评审活动来实现。

　　需要说明的是，软件测试的对象是产品（包括阶段性产品，如市场需求说明书、产品规格说明书、技术设计文档、数据字典、程序包、用户文档等），而质量保证和管理的对象集中在软件开发的标准、流程和方法等。

　　究竟什么是软件测试呢？综上所述，软件测试的定义为：

　　软件测试是贯穿整个软件开发生命周期、对软件产品（包括阶段性产品）进行验证和确认的活动过程，

　　其目的是尽快尽早地发现在软件产品中所存在的各种问题——与用户需求、预先定义的不一致性。

    1. 页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。

　　2. 相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。

　　3. 检查按钮的功能是否正确：如update, cancel, delete, save等功能是否正确。

　　4. 字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错.

　　5. 字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错.

　　6. 标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确.

　　7. 中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错.

　　8. 检查带出信息的完整性: 在查看信息和update信息时,查看所填写的信息是不是全部带出.,带出信息和添加的是否一致

　　9. 信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.

　　10. 检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按”delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理.

　　11. 检查添加和修改是否一致: 检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.

　　12. 检查修改重名:修改时把不能重名的项改为已存在的内容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错.

　　13. 重复提交表单：一条已经成功提交的纪录，back后再提交，看看系统是否做了处理。

　　14. 检查多次使用back键的情况: 在有back的地方,back,回到原来页面,再back,重复多次,看会否出错.

　　15. search检查: 在有search功能的地方输入系统存在和不存在的内容,看search结果是否正确.如果可以输入多个search条件,可以同时添加合理和不合理的条件,看系统处理是否正确.

16. 输入信息位置: 注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方.

　　17. 上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。

　　18. 必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加*

　　19. 快捷键检查：是否支持常用快捷键，如Ctrl+C Ctrl+V Backspace等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。

　　20. 回车键检查: 在输入结束后直接按回车键,看系统处理如何,会否报错。

软件测试是保证软件产品质量的重要手段之一。它是测量、评估软件产品特点和能力的活动。现在，国内一些软件企业对于软件测试的重视程度还很不够，认为测试工作非常简单，只是简单地操作所测的软件产品而已。这种错误的思想严重影响了国内软件质量，应该引起我们的高度重视。

　　软件测试阶段可以分为若干个小的阶段，阶段的划分有多种，我现在按流程顺序将其分为四个阶段：

　　· 单元测试：由项目小组完成

　　· 集成测试：由项目小组完成

　　· 系统测试：由专业测试小组完成

　　· 交接测试：用户和开发商共同完成。

　　测试的四个阶段完全逆向检测了软件开发的各个阶段。单元测试主要是测试程序代码，集成测试主要是对设计的检测，系统测试主要测试了软件的功能，交接测试主要是对用户需求的一种检测。但是每个测试阶段仍要对其它测试阶段的测试内容加以测试，只是测试重点不同。

　　在这篇文章中，我只对单元测试流程加以阐述，而不涉及具体的测试方法。关于测试方法（如：使用手工测试还是自动测试）若有机会将在其它文章中进行阐述。

　　在单元测试前，先让我们明白以下几个问题，这可以使我们对单元测试更加清晰。

　　· 单元测试的目标：　确保模块被正确地编码

　　· 由谁去做：　　　　通常由程序人员测试

　　· 怎样去测试：　　　功能测试可以用黑匣测试方法，代码测试可用白匣测试方法　

　　· 什么时候可以停止：当 程序员感到代码没有缺陷时

　　· 记录：　　　　　　通常没有记录

　　我们在清楚以上问题后就可以编写测试用例了。测试用例是输入、执行条件和一个特殊目标所开发的预期结果集合。它按测试目的不同可分为以下几种类型：

　　· 需求测试用例：测试是否符合需求规范

　　· 设计测试用例：测试是否符合系统逻辑结构

　　· 代码测试用例：测试代码的逻辑结构和使用的数据

　　需求测试用例通常是按照需求执行的功能逐条地编写输入数据和期望输出。一个好的需求用例是可以用少量的测试用例就能够覆盖所有的程序功能。

　　设计测试用例检测的是代码和设计是否完全相符。是对底层设计和基本结构上的测试。设计测试用例可以涉及到需求测试用例没有覆盖到的代码空间（例如界面的设计）。

　　代码测试用例是基于运行软件和 数据结构上的。它要保证可以覆盖所有的程序分支、最小的语句和输出。

以上三种用例所用的数据又可分为正常数据、边缘数据和错误数据。

　　· 正常数据：在测试中所用的正常数据的量是最大的，而且也是最关键的。少量的测试数据不能完全覆盖需求，但我们要从中提取出一些具有高度代表性的数据作为测试数据，以减少测试时间。

　　· 边缘数据：边缘测试是界于正常数据和错误数据之间的一种数据。它可以针对某一种编程语言、编程环境或特定的数据库而专门设定。例如若使用SQL Server数据库，则可把SQL Server关键字（如：';AS;Join等）设为边缘数据。其它边缘数据还有： HTML的HTML;<>等关键字以及空格、@、负数、超长字符等。边缘数据要靠测试人员的丰富经验来制定。

　　· 错误数据：显而易见，错误数据就是编写与程序输入规范不符的数据从而检测输入筛选、错误处理等程序的分支。

　　由于执行测试用例的数据量巨大以及还要进行回归测试，所以可以考虑使用自动 测试工具，但提取测试数据仍要依靠编写测试用例人员的经验。并且，我们还要注意到自动测试也许不能找到程序中所有错误，手动测试所找到的错误会比自动测试所找到的要多。

　　有了测试用例，我们就可以进行测试了吧？许多公司也是这样做的，但在这里我建议大家最好要先进行代码的审议。通过代码审议找到的错误可以比测试用例测试所能找到的错误更加深入，并且发现错误的时间也比测试用例要早。代码审议要以代码 标准（根各公司具体情况自行制定）为依据，一般情况下要检查以下几点：

　　· 代码风格和规则审核

　　· 程序设计和结构的审核

　　· 业务逻辑的审核

　　代码风格和规则的审核是在每个 程序员完成一个模块或类的 时候要进行编码规范的检查。要召开审核 会议让所有的项目组人员都参加。在会前 项目经理要做一个检查表，以表的内容为检查依据，检查表的内容主要是检查的要点。在审核会上项目组的每一个人员都能看到自己和其他人员的编码问题，从而起到预防的作用。这些问题都要被解决，并且解决的结果要在审议会上被确认。

　　进行程序设计和结构的审议是因为开发工具的不同和项目时间的限制而造成设计不详细。比较深入的设计通常是在编码阶段完成的，但由于程序人员和设计人员的经验是不同的，所以会出现很大的问题。我们引入了程序设计和结构审核来保证质量。审核人员要有先进的技术开发经验。在审核之前也要一个审核列表，列出主要几项，如：程序的概要、详细设计。但仅局限于列表是不够的，审议人员 还要审议程序的精巧度和具有创造力的方面，这只能靠经验而不能只靠列表中的内容来审议。对于不同的程序员所检测代码的宽度和深度也是不同的。项目经理可以根据程序员经验的不同制定被审议人员的宽度和深度。例如：年轻的程序员要审议所有代码。但有经验的就可适当减少。

　　业务逻辑性审议必须要在代码完成后审议。业务逻辑审议实际上是审议单元模块的功能。这些功能是以系统说明为依据的。审议人员要有开发的经验并且对系统也要熟悉。审议人员通过执行程序从而了解底层代码的状态。这阶段的审议实际也包含了前两种审议，因为审议者也可以通过最后的结果检测单元模块设计和结构的准确性。

　　以上三种审议都要耗费一定的时间和 资源，但是它却能更早地发现和解决不易显现的错误。

　　审议通过后，我们终于可以使用用例来进行代码测试和调试了。代码的调试是用来保证程序能按照系统需求正常运行的一种手段。但是我所提到的这种代码调试并不是简单的调试，它要包括以下两部分：

· 特征调试

　　· 代码覆盖调试

　　首先我们要先进行特征调试。它是通过运行程序找到代码中的错误，这与我们平时常进行的调试相同。到程序能运行后，我们可使用已编好的三种类型的用例并以正常数据测试用例进行测试，若不能正常运行则要用调试工具调试。在这阶段，我们要用大量正常数据去测试。测试后，该程序应可在绝大多数的正常数据中运行。

　　其次，我们要进行代码覆盖测试，一直要达到以下目标为至：

　　· 测试到每一个最小语句的代码

　　· 测试到所有的输出结果

　　我们应该通过一步步的调试去运行每个程序的所有语句和分支。如果我们想要百分之百地覆盖就应适当运用边缘数据和错误数据。测试在这个阶段的质量是难以掌握的。它基于 程序员的责任心和经验。当这阶段完成后，每个程序员所测的深度也是不同的。因此，在这个测试阶段之前， 项目经理（或测试工程师）应制定出测试指导和计划书。它们至少应包括以下内容：

　　· 测试的主要对象

　　· 主要调试点

　　· 怎样测试

　　· 什么时候可以完成

　　至今为至，我们已完成了代码的审议和调试。如果我们是严格按照以上步骤做的，那就可以保证代码没有太多的错误，至少没有使程序运行中断的错误了。如果我们不能很好地执行代码审议和正确的调试，那我们就不能顺利地通过测试，有时我们还要不得不返回来做这些事。

　　好了，我们终于完成了单元测试的工作，程序员们可以喘口气了，但不要忘记还有更加严格的集成测试要我们去做。