程序测试

或曰之程序测试

今天测试buff的属性叠加的时候，犯了致命性的原则错误，就是为了证明自己的正确性而测试，以下便是偶的自我检讨。

 

或曾经曰过：程序测试是为了发现错误而执行程序的过程

 

就是在代码完成后，通过运行程序来发现代码或模块中错误。但是，这种意义上的测试是不能在代码完成之前发现系统需求、设计上的问题，也就是说把发现需 求、设计上的问题遗留到后期，这样就会可能造成设计、编程的部分返工。增加开发的成本、延长开发的周期等。需求阶段和设计阶段的缺陷产生的放大效应会加 大。也就说 为了更早地发现问题，要将测试延伸到需求评审、设计审查活动中去。我觉得正是我们在审查策划案以及他们的设计的时候所要面对的。需要高度的重视这些问题。

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

 

或曾经曰过：测试是为了证明程序有错，而不是证明程序无错误

 

产生了一个问题：测试到底是证明软件有错论呢？还是证明软件无错论呢？个人理解，各打50大板，也就是两个方面都有道理，前者（证明所有软件的功能特性 是正确的）是从质量保证的角度来思考软件测试，后者（证明程序有错）从软件测试的直接目标和测试效率来思考，两者应该相辅相成。在后者的思想背景下，我们 认为，测试不是为了证明所有的功能可以正常工作，恰恰相反，测试就是为了找出那些不能正常工作、不一致性的地方。也就是说，测试的一般工作就是发现缺陷， 即在软件开发过程中，分析、设计与编码等工作都是建设性的，而测试是带有“破坏性”的工作。随着我们数据大量的导入、代码的堆积、功能的不断制作，各种代 码的边界、无效数据的输入以及系统的弱点，那么就需要我们自己试图破坏系统、摧毁系统，目标就是发现系统中各种各样的问题。

 

我们在实际工作中应该怎么样去面对一个复杂庞大的系统呢:

 

1 不停尝试：可能会碰到转瞬即逝或者难以重现的缺陷，尽一切可能去寻找它的起因。

2 探索精神：不要害怕进入陌生环境。在有多个模块制作的系统中，往往不是由一人完成的，那么在自己发现了别人可能存在的问题时，去探究一下，找出问题的所在，或者能详细的描述问题的特征，以供同伴尽快地解决问题。

3 猜谜：对于无法确定的问题，大胆的说出自己的猜测，往往能给别人很大的启发。

4 联系思考：从设计到制作的各个环节，所受的影响因素，联系看到的问题，然后作出问题的具体处在哪里，不会被局限于某一点。

5 拓展测试：测试显而易见的事实，这还不够；给出超常的手段或者数据来寻找缺陷。多制造一些容易产生bug的例子，有点类似破坏性测试，以检测系统的健壮性。

 

我们所需要注意的一些测试方面：

 

（1） 边界测试，测试用户输入框中的数值的最大数和最小数，以及为空时的情况。

（2） 非法测试，例如在输入数字的地方输入字母。

（3） 跟踪测试，跟踪一条数据的流程,保证数据的正确性。

（4） 在开始测试时应保证数据的正确性，然后在从系统中找出各种BUG。

（5） 接口测试，程序往往在接口的地方很容易发生错误，要在此模块测试勿掉以轻心。

（6） 代码重用测试，在开发过程中有些模块功能几乎相同，程序员在重用代码时可能忘记在原有代码上修改或修改不全面，而造成的错误。

（7） 突发事件测试，服务器上可能发生意外情况的测试。

（8） 外界环境测试，有些系统在开发时依赖于另外一个系统，当另外一个系统发生错误时，引起这个系统受到影响，从而出现错误，那就需要联系起来考虑问题可能存在的外在原因。（就是模块间，甚至是自己程序之外的输入因素所引起的问题，我这里统称为另外的系统）

（9） 在程序员刚修复Bug之后的地方,再找一找，往往程序员只修复报告出来的缺陷而不去考虑别的功能在修改时可能会重新造成错误。

（10） 认真做好测试记录在做完一天的测试记录之后,第二天再根据第一天的测试记录重复测试你会发现有未修正的错误。

（11） 文字测试，文字使用的问题，文字的大小边界字体等因素所导致的问题。

（12） 系统兼容测试，我们面临的问题还是不小。

（13） 用户的操作性测试，往往前后设计上会产生，操作歧义，从而引起用户操作上的不方便。