读《软件测试的艺术》笔记-草稿_测试运行初衷-CSDN博客

本文链接：https://blog.csdn.net/MoveFlower/article/details/105990630

软件测试的定义：

为了发现软件错误而执行程序的过程。

软件测试心理学：

1.软件测试是以发现软件中的错误为目标，而不是为了证明软件做了该做的，或者为了证明软件没有错误。

2.成功的测试，失败的测试。不应该以没有发现软件中的错误就定义为成功的测试，发现了软件中的错误就定义为失败的测试，让人沮丧，这种定义是对测试充满了恐惧与抗拒心理的。我们应该双手迎接测试，测试的初衷是为了保障软件稳定，高质量的运行，而不是找茬。就像病人找医生看病，如果做了大量检测，医生没有检查出病灶，不能说这是一次成功的检查，病人可能会怀疑医生的诊断能力，而相反，比如医生通过细致的检查，检测病人得了“胃溃疡”，这显然是一次成功的检测。软件测试也一样，成功的测试应该是通过细致的测试，没有发现软件的错误，或者通过细致的测试发现了软件的错误；而失败的测试，应该是没有发现软件中本该发现的错误。用这样的心理去做测试，迎接测试才是合理的。

软件测试经济学：

没有哪个人敢对自己设计的程序或者软件拍胸脯说，我的程序 or 软件很完美，没有任何错误，这或许在下一分钟就会打脸。因为测试经济学已经证明，任何一个程序几乎无法用穷举法测试所有情况，因此没有进行过充分的测试如何敢保证程序没有错误。我们测试的投入目标应该是：用最少的测试用例，最大限度的发现问题。

黑河测试 vs 白盒测试：

黑盒测试，即数据驱动测试，对程序内部不感知，用测试数据去校验软件的执行结果。穷举数据测试依然成本高昂。

白盒测试，即逻辑驱动测试，对程序内部感知，用测试用例去走查程序代码的执行逻辑，产出测试结果。穷举路径测试依然成本高昂，你甚至无法对一个循环体做全量的代码走查，更何况一个庞大的程序。

软件测试的原则：

软件测试的重要原则：

1.测试用例中，必须部分要对预期输出或结果进行定义。

2.程序员应该避免测试自己编写的程序。

3.编写软件的本体最好不要参与软件测试，交个第三方。

4.应当彻底检查每个测试的执行结果。

5.测试用例应该不仅包含有效的和可以预测到的情况，还应该包括无效的和不可预料的情况。

6.检查程序是否“做了其应该做的”，只是完成了测试工作的一半，测试的另一半是检查程序是否“做了其不应该做的”。

7.应该避免测试用例用后即放弃，除非软件本身就是一次性的。

8.计划测试工作时不应该假定不会发现错误。

9.程序某部分存在更多错误的可能性和该部分已发现错误的数量成正比。

10.软件测试是一项机富创造性，极具智力挑战的工作。

对“1.测试用例中，必须部分要对预期输出或结果进行定义。”的解释：

一个测试用例必须包含两部分：

1.对程序输入数据的描述。

2.对程序在上述输入数据下的正确输出结果的精确描述。

对“2.程序员应该避免测试自己编写的程序。”的解释：

如果我们对软件项目关注的重点发生变化，就会产生另外一个问题。当程序员“建设性”地设计和编写完程序以后，很难让他突然改变视角以一种“破坏性”的眼光来审查程序。另外，程序员可能会下意识地避免找出错误来，担心受到同事，上司，客户或正在开发的程序员或系统的主管的惩罚。还有一个重要的问题，由于程序员错误的理解了疑难定义或规范，导致程序中存在错误。如果情况是这样，程序员可能会带着同样的误解来测试自己的程序。

对“7.应该避免测试用例用后即放弃，除非软件本身就是一次性的。”的解释：

方便做回归测试。

对“9.程序某部分存在更多错误的可能性和该部分已发现错误的数量成正比。”的解释：

错误总是倾向于聚集性的存在，如果一个程序的某个部分远比其他部分更容易产生错误，那么这种现象告诉我们，为了使测试获得更大的成效，最好对这些容易存在错误的部分进行额外的测试。