浅谈静态测试（一）

jamietesting

静态测试
       通过上一个版本静态测试的开展，对于静态测试有了进一步的认识，这里大概做一下小结，以便下一个阶段的静态测试能够更加顺利的执行，另外希望可以让新来的同事对静态测试有一个基本的认识。
一、什么是静态测试，静态测试的意义和对象描述软件测试有这样两个术语：静态测试和动态测试，静态测试是指测试不运行的部分——只是检查和审阅。动态测试是指通常意义上的测试——运行和使用软件。
       我们系统测试是很重要的，不容忽视的，但是系统测试的功能测试阶段，编码已经完成，这个时候所发现的问题，需要付出比较高的代价去修正它，而静态测试不用等到编码结束再去做，可以在系统开始需求讨论，功能设计的时候就进行测试。严格来说所有的书面的，甚至非书面产生的与项目相关的东西都可以成为我们静态测试的对象。静态测试，会让我们尽早的发现软件缺陷，完全可以在编码之前把问题遏制在萌芽中，从而大大降低开发和测试的成本。
在目前阶段，我们静态测试主要针对系统规格书、软件需求说明书等来展开，用数据结构，存储过程作为辅助。
二、静态测试开始和进行的时机       理论上讲，静态测试从项目立项，即可开始测试，贯穿整个项目始终。在实际中，我们系统测试基本上是上一个版本结束的时候进入下一个版本的静态测试阶段，这个时候基本上系统规格书和软件需求说明书都已经完成初稿，一直测试到我们系统测试结束。静态测试开始的原则是越早越好，我们从立项即开始静态测试可能比较困难，但可以根据自己的项目情况，尽可能的早些。
三、静态测试开始前的测试准备工作，如何更加全面和深入的进行静态测试       首先，静态测试有一个潜在的约定，你要对所要测试的系统有一定的业务基础，这样你的测试才能更加全面和深入的进行。对于新员工来讲，这一点是需要加强的，面临陌生的系统，全新的业务，尽快的熟悉系统的特性，业务的背景，做好充分的准备工作，将有利于静态测试顺利的进行。

1、如果将要测试的是新增的业务流程上的项目，建议找一种类似的业务，先在系统中熟悉起来。
举一个简单的例子，比如可以看贷款的整个流程，因为它是信贷系统中最为典型的业务，这个过程中，申请、审批、转登、台帐、发送准贷证、主机上处理、批量或者实时返传回台帐。整个过程中自己一边做，一边可以考虑测试中应该注意的问题，对于输入域有哪些什么常见的控制；功能上，比如页面跳转控制上有什么特别；表与表的转换；状态的变化等有什么要注意的点。如果可以对于已有的类似的业务流程有一个清晰的认识，对于新业务的把握也会更加游刃有余。

2、测试变更类项目，建议将原有的系统先熟悉起来，以便对于新增，修改的点有更明确清晰的认识。尤其涉及到公共模块的改动，一定要搞清楚原来的控制点是怎样的。

其次，对于项目的业务背景，总体设计的了解也是非常重要的。
1）它的设计背景如何，总体要实现哪些内容，这些可以从《总体方案》中大概的得知。通过对总体方案的研读，可以让我们比较清晰的了解所测试的内容的轮廓。
2）具体设计涉及到哪些表，可以从数据结构中得知，对于数据结构的理解可以让我们更加透彻的审视系统规格书和软件需求说明书。
对于新增的项目，我们拿到表结构后，大致看一下，有哪些表，哪些是申请表，哪些是中间表，哪些是台帐表，这样我们大概就了解了这个项目是怎样实现的，数据流是怎样的。
对于修改的项目，要对本次的修改点有比较清晰的了解，哪些字段做了变更，哪些字段是新增的，在程序中哪些地方会引用到这些字段。
有备无患，只有充分的前期准备，才会在静态测试过程中取得比价满意的效果，这里面我们有一个隐含的假设，假设时间比较充裕，但往往会出现时间紧张的状况，这种情况是大家目前共同面对的问题。
比如本次我所参与测试的7月份间接银团项目刚刚完成系统测试，马上又投入到分行调研的系统测试中，这期间的静态测试工作准备时间非常仓促，对于这一类情况项目的静态测试，一方面依赖与对系统的熟悉，以往的经验，这要求我们平时的项目测试过程中多积累经验；另一方面一定要事先弄清楚在测试的范围内哪些是你所不了解的，没有把握的，这部分内容找到后，就是去尽快的寻找解决的办法，基本上业务方面的问题可以在我们的测试团队内部解决；如果涉及到控制类比较复杂的，测试人员较难搞清楚的，最好提前跟对应的开发沟通，搞清楚项目的测试要点，或是去求证你的测试思路是否正确。这样有助于我们尽快的进入状态，缩短准备时间，更好的进行静态测试。
四、静态测试过程中如果发现静态测试问题，从哪些方面着手静态测试开展的时间还不长，对于经验来说也是比较浅的，更是见仁见智的，这里我也与其他同事讨论过，把大家的想法做一个简单的总结，仅为后来的测试做一个小小的借鉴，有什么不合适的地方，请大家指出来，讨论一下，以便我们能够得到一个更加有效的解决办法。
关于静态测试产品说明书，大概有以下两种方法：
1、对产品说明书进行高级审查
测试产品说明书的第一步不是钻进去找软件缺陷，而是在一个高度上审视。审查产品说明书是为了找出根本性的大问题、疏忽和遗漏之处。也许这更像是研究而不是测试，但是研究主要是为了更好地了解软件要做什么。如果能够很好地理解产品说明书背后的原因和操作方式，就可以更好地仔细检查。
1）当软件测试员第一次接到需要审查的产品说明书时，最容易做的事是把自己当作客户。
先去了解客户所想是很重要的，这就涉及到我们静态测试的准备工作要做到位，有一定的业务背景了解，这样在审视产品说明书的时候才更有可能发现功能的设计不合理的地方。比如以下几种情况，设计就是不合理的：
a.按照产品说明书中所描述的内容，不能够满足用户预期得到的功能，有遗漏。
比如涉及到公共模块改造的项目，设计到的业务种类有A、B、C、D、E、F六种，而说明书中，仅仅描述了五种业务，这就是一个设计遗漏问题。
b.
常见的增、删、改、查的控制，不符合客户的需求。
新增、修改、删除的时候需要的控制没有描述。比如CM2002中，台帐的新增、修改、删除需要判断是否有业务调帐授权，如果在说明书中没有相关描述，就会导致程序员在编码的时候对这一点的遗漏。
可以修改，可以删除的状态不全面。比如CM2002中，申请、退回到调查、否决状态均是可以修改的。如果系统中对于业务申请的描述这样说：“点击修改，判断业务状态是否为申请，如果为申请状态则可以修改；否则不允许修改，给出相应提示。”，这样的描述，遗漏了另外两种状态的描述，显然是不符合客户的控制要求的。
查询，尤其是汇总查询，用户要求在多种条件的约束下，给出汇总查询的结果，如果在说明书中判断中丢失了某一种条件，都是不能完成最终汇总任务的。
c.按照产品说明书的描述，是否有本次项目不实现的内容。
比如，在总体方案中，描述某功能本次设计暂不实现，而在系统规格书或者软件需求说明书中出现了这一部分内容的描述，这个时候很可能是写了多余的内容。
d.涉及到多种情况，是否都有清晰的描述。
尤其是对于各种分支情况的测试：如果是A，则怎么样，没有描述，不是A是B，是C的情况系统将如何处理；或者把A情况的功能错误描述为B情况下的功能。这个是软需上常常出现的问题。
上面的这些内容都是我们需要检查的，另外如果什么知识也没有，那一定要记住一条原则：遇到不懂的就要问。如果审查产品说明书的某一部分时不理解，不要假定它是对的，而把它放掉。这一点其实对于新员工和老员工都是非常重要的，不要有什么担心，不懂没关系，可以去学习，测试最忌讳的也莫过于不懂装懂了。其实这些逻辑写的不清楚的地方，往往是开发也比较含糊的地方，容易出错，一定要让他们描述清楚。比如CM2002中关于授信的测试，很多项目中都会设计到，而且大部分都比较复杂，如果在软需中描述的很简略，不清楚，基本上到项目后期开发才能搞清楚这个逻辑关系是怎么样的。
2）研究现有的标准和规范
老系统上的东西是我们最好的学习范例，在测试阶段我们可以根据这些已有的标准和规范来审视新的产品说明书，比如一些比较不易理解的控制，或者页面跳转，我们可以时间动手，对现有的业务进行操作，观察它是怎样控制的，从而判断，说明书上所描述的内容是否符合现有的规范。
3）审查和测试同类软件
同类的软件或者项目中存在的控制，功能，可以给我们一个好的提示，让我们的静态测试更加有的放矢，比如我们可以说一个软件系统中要设计一个新的功能，而这个功能在同类软件中有成形的产品，借鉴现有的经验，很容易比对出，目前的设计存在哪些缺陷。