读书笔记之软件测试的艺术（part I）

第一部分：软件测试的经济学

1.1黑盒测试（基于功能）

又称为数据驱动的测试或驱动输入输出测试，测试的目标与内部代码的结构和机制没有关系，测试数据完全来自于软件规范，也就是说不用关心代码的内部结构，如果想用这种方法来找出程序中的所有错误，判定方法就是穷举输入测试，但是另一方面由于会出现无限种可能的现实情况，我们无法真正的一一列出所有的测试情况，只能通过有限的测试，来发现最大程度的错误。

1.2白盒测试（基于内部代码）

（1）穷举路径测试

又称为逻辑驱动测试，对程序内部的代码逻辑进行检查进行检查（常常会忽略代码的规范问题）。

穷举路径测试的漏洞：1.如果程序内部的代码虽然可以正确运行，但是没能按照要求来，例如把升序写成了降序，程序仍然存在缺陷，因为这本来就是一个不符合规范的程序。

                                2.某些程序会因为缺少路径而无法被发现，因为少考虑了若干种情况，这个程序还是有错误的，而穷举路径测试并不能测试出来。

                                3.穷举路径测试可能不会暴露敏感数据错误，例如我们在判断a和b之差与c的大小的时候，即if（（a-b）>b），可能程序会用a-b的绝对值和c作比较，而这取决于ab的 符号和类型问题，并不能发现这个问题。

 

（2）软件测试的原则

原则一：测试用例中的一个必须部分是对预期结果进行定义

也就是测试必须满足两个条件：1）对程序输入数据的描述

                                              2）对所描述的数据输入后的正确结果进行精确描述

原则二：程序员应当避免测试自己编写的程序：

毕竟让一个人来找自己的漏洞有点难

原则三：编写软件的组织不应当测试自己编写的软件：理由同上

原则四：测试用例不应根据有效的预期结果和输入情况，还应该考虑无效和没有预料到输入情况：例如给了三个数字，让我们来判断这三个数字能否组成不规则三角形、等腰三角形、等边三角形，例如输入两组数字：2,5,10，-2,8,5，显然这两组数据连三角形的构成不了，所以我们也要考虑到这种情况。

原则五：应当彻底检查每个测试的结果

有可能某个代码逻辑是错误的，然而对于我们所输入的测试数据，恰巧输出了正确的结果，所以还是要彻底的检查，不能光看表象。

原则六：检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”。这条原则是上条原则的必然结果。必须检查程序是否有我们不希望的负作用。比如，某个工资管理程序即便可以生成正确的工资单，但是如果也为非雇员生成工资单或者它覆盖掉了人员文件的第一条记录，这样的程序仍然是不正确的程序。

原则七：应避免测试用例用后即弃，除非软件本身就是一个一次性的软件。这个问题在采用交互式系统来测试软件时最常见。人们通常会坐在终端前，匆忙地编写测试用例，然后将这些用例交由程序执行。这样做的问题在于，饱含我们宝贵投人的测试用例，在测试结束后就消失了，一旦软件需要重新测试（例如，当改正了某个错误或作了某种改进后），又必须重新设计这些测试用例。情况往往是这样的，由于重新设计测试用例需要投人大量的工作，人们总是避免这样做。因此，对该程序的重新测试极少会同上次一样严格。这就意味着，如果对程序的更改导致了程序某个先前可以执行的部分发生了故障，这个故障往往是不会被发现的，保留测试用例，当程序其他部件发生更动后重新执行，这就是我们所谓的“回归测试”。

原则八：计划测试工作时不应默许假定不会发现错误。项目经理经常容易犯这个错误，这也是使用了不正确的测试定义的一个迹象——也就是说，假定“测试是一个证明程序正确运行的过程”。我们再一次重申，所谓测试，就是为发现错误而执行程序的过程。

原则 九：程序某部分存在更多错误的可能性， 与该部分已发现错误的数目成正比。这种现象如图2-2所示。乍看上去，这幅图似乎没有什么意义，但很多程序都存在这种现象。例如，假如某个程序由两个模块、类或子程序A和B组成，模块 A中已经发现了五个错误，而模块B 该原则的另一个说法是，错误总是倾向于聚集存在，而在一个具体的程序中些部分要比其他部分更容易存在错误，尽管没有人能够对这种现象给出很好的解这种现象之所以有用．是因为它给予了我们对软件测试过程的洞察或反馈。如一个程序的某个部分远比其他部分更容易产生错误．那么这种现象告诉我们，为使测试获得更大的成效，最好对这些容易存在错误的部分进行额外的测试。

原则十：软件测试是一项极富创造性、极具智力挑战性的工作。测试一个大型软件所需要的创造性很可能超过了开发该软件所需要的创造我们已经看到，要充分地测试一个软件以确保所有错误都不存在是不可能的。

今天先看到这里，后续会更新。。。