浅谈静态测试（二）

jamietesting

2、产品说明书的低级测试技术
1）产品说明书属性检查清单
可称为：“一丝不苟”的优秀产品说明书应具有8个重要的属性：
完整。是否有遗漏和丢失？完全吗？单独使用是否包含全部内容？
       准确。既定解决方案正确吗？目标明确吗？有没有错误？
       精确、不含糊、清晰。描述是否一清二楚？还是自说自话？容易看懂和理解吗？
       一致。产品功能描述是否自相矛盾，与其他功能有没有冲突？
       贴切。描述功能的陈述是否必要？有没有多余信息？功能是否原来的客户要求?
       合理。在特定的预算和进度下，以现有人力、物力和资源能否实现？
       代码无关。是否坚持定义产品，而不是定义其所依赖的软件设计、架构和代码？
可测试。特性能否测试？测试员建立验证操作的测试程序是否提供足够的信息？
边看要想想如何测试？
       在这个过程中，我们最常用的方法就是关联和比对：
Ø
系统规格书与数据结构的比对
a.数据结构表中涉及到的字典项，我们需要在测试过程中核对定义的准确性，所以在系统规格说明书中一定要对字典项有一个比较详细的描述。
b.如果在数据结构中定义的字段不是从前台录入的，就需要系统规格书中描述清楚它具体从哪一张表中取到。
Ø
软件需求书明书与数据结构的比对

a.数据结构中的字段定义与软需中的输入输出项比对，检查是否有遗漏。比如在软需中描述有A字段，而在相应的数据结构表中没有涉及该字段。

b.数据类型及长度是否有矛盾。比如数据结构中描述长度为8，而在软需的输入项描述中长度为10，这样很可能造成后续程序在把数据写入数据库中时报错。

c.软需中功能，比对数据结构，软需中的字段在何时写入了哪些表，在何时何种条件下状态发生变化。比如在软需中描述，在三种不同的状态下，会发生三种不同的动作；而在数据结构中这个字段只对应了两个状态，比对的结论：这样的设计是有遗漏的。
Ø
系统规格书与软件需求说明书的比对
系统规格书中的流程说明，与软件需求说明书中的功能描述是否相符？
系统规格说中描述，应该存入A表，而在软需中描述应该存入B表，相互矛盾
Ø
软件需求说明书，功能模块与功能模块的关联与比对
a.新增模块中判断过某些字段相互比较，关联修改模块，这些点是否应该控制，是否已经控制。
比如申请日期与系统日期的比较，在新增的时候是需要的，但是在修改的时候如果也加上了这样的判断就是错误的；还有一些控制，如果在新增的时候控制住了，在修改的时候不去控制，一样会导致错误的出现。
b.台帐表和申请表的判断之间的相同点和不同点。
c.数据相互关联的模块，是否存在矛盾。有些模块单独看起来是没有什么问题的，但是关联起来看就是存在问题的：两者的描述是否存在矛盾；关联起来看的时候接口部分条件是否定义清楚。
Ø
软件需求说明书与实际系统的比对
在集成测试阶段或者系统测试阶段的时候，可以针对实际的系统来重新审视软件需求书明书：一点是软需中描述的名称在系统中是否可以一一对应，有差异，不利于测试，需要修改；另一点，软需中描述的功能是否与实际系统中有出入，如果有矛盾，并且以实际系统实现的功能为准的话，则需要修改软需。
对于文档的测试，还需要关注文档的各个部分描述的完整性。也是比较常见的问题，比如系统规格书中没有文档结构说明的描述。
2）产品说明书用语检查清单
如果开发本身对于问题把握不好，那这一段软需肯定写的也会比较牵强，不易看懂。
注意下面这些特别的词语：
总是、每一种、所有、没有、从不。如果看到此类绝对和肯定的，切实认定的叙述，软件测试员可以着手设计针锋相对的测试案例，比如说明书中描述说，所有业务都会调用某一参数，而所有业务中分为A、B、C三种不同类别的业务，我们就要针对不同的业务做类似的案例，检查是否真的都能够调用某一参数。
当然、因此、明显、显然、必然。这些话意图诱使接受假定情况。不要中了圈套。
某些、有时、常常、通常、惯常、经常、大多、几乎。这些话太过模糊。“有时”发生作用的功能无法测试。
等等、诸如此类、依此类推。以这样的词结束的功能清单无法测试。功能清单要绝对或者解释明确，以免让人迷惑，不知如何推论。
良好、迅速、廉价、高效、小、稳定。这些是不确定的说法，不可测试。如果在产品说明书中出现，就必须进一步指明含义。
已处理、已拒绝、已忽略、已消除。这些说法可能会隐藏大量需要说明的功能。
如果……那么……（没有否则）。找出有“如果……那么……”而缺少配套的“否则”结构的陈述。想一想“如果”没有发生会怎样。
对于这些描述要给予特别的关注，可以发现不少静态测试问题。
编码结束的时候，可以对于代码进行静态测试，这种方法也会在系统测试之前发现一些问题。主要是存储过程的检查：
1、有些内容通过代码静态测试来得更容易些。
比如，支行撤并，前台是要测试的，但是初期，可以从代码上看出来是否存在比较明显的问题，应该划转过来的表是否涉及到相关的操作。Where 子句中对哪些客户，哪些业务进行了处理，是否有遗漏，如果有遗漏，这样的撤并无需执行，可以肯定是有问题的。
2、在代码中参数定义及传参比较容易出错。
参数定义，比如应该为字符型的字段，定义为数字型的，程序执行时可能导致某些字段显示错；
传参，比如汇总查询某一机构及其下级行的所有数据，在存储过程中涉及到两个参数，一个是传入的机构代码A，由前台选定的；另一个是机构以及这个机构下面的各级行号。汇总查询过程中，根据该机构及其下各级行号循环来查询，如果没有出入各级行号，而是传为了参数A，就会导致汇总查询的结果不准确。
五、与开发组的沟通测试就是为了找到软件缺陷而执行程序的过程，而这个软件问题的多少，质量的好坏，直接关系到对于一个开发人员的考评，这就注定了开发和测试之间的矛盾，除非像有些外企那样开发和测试不直接接触，否则这样的矛盾，我们每一个测试人员都要面对，要想更好的测试，更好的保证软件的质量，提高与开发的沟通是我们应该好好研究的课题。针对静态测试，我们需要在提问过程中注意到下面几点，以争取以一个有利的位置与开发沟通。
1、提问题的质量：好的问题，开发是欢迎的，同时会赢得开发对我们测试的认同。
我们对于问题数是有考核的，但是不能因为考核而背弃了软件测试的初衷——保证软件的质量，去一味的追求问题数，提过多简单的问题，比如字面上的问题，诚实的说对于软件质量的帮助不是很大，但却会引起开发的不满和对我们测试能力的质疑。
测试人员希望开发理解和支持测试工作，开发也希望能够通过策划四有效的保证软件的质量，我们需要相互理解，相互支持，从开发的角度上去考虑一下，他们的任务是非常重的，要做好目前的项目，准备下一个项目，解决之前项目的各种补丁问题，所以注重问题的质量，是减少开发和测试之间的冲突，更好的沟通的必要前提。
2、提问题的时间
在前面我们谈到静态测试的重要性中，说到静态测试可以让我们在项目早期介入，尽早的找出软件缺陷，尽可能为项目节省大笔开销时间。所以静态测试提问的时间应该考究，最好能够把准备工作做得早些，让发现问题的时间尽量的提前，我认为编码开始之前发现的问题是效果最好的，意义最大的，这个时候发现问题，一者开发有时间；来修改你的问题，响应速度比较快，二者编码工作还没有开始，不会加重开发的工作，开发会比较乐于配合。在编码还没有完成，系统测试还没有开始的这段时间，发现静态测试问题也是比较有效的，起码开发有时间去调整。
反过来如果已经到了系统测试，甚至于系统测试的默契，这个时候的静态测试问题基本上已经意义不大了。很大成分上会是文档问题，让开发不愿意接受，带着情绪去修改，影响开发与测试的沟通。

3、提问题的立场和态度要明确
       如果在与开发出现分歧时，需要我们坚持我们的立场，是问题，尤其是明显的，较为严重的问题都要上Rational登记。如果开发有什么不理解，可以跟他说一说这样做的好处：便于提醒开发及时修改相关内容，同时有助于测试验证问题，不至于遗漏。

jamietesting

欢迎大家来讨论一下静态测试的执行！