软件测试2-测试必须有策略和测试有哪些最高原则

什么是软件测试

测试是为发现错误而执行程序的过程。

软件测试一个破坏性的过程，甚至是一个施虐的过程，也就是第一天说的“找茬”游戏。 当一个输入框让我输入手机号码时，我偏不，我要输入非手机号码，甚至不填。 当界面提示让我点击第一个按钮时，我偏不，我要点第二个，第三个。

这和开发是一个截然相反的工作，开发的思路是创造，把功能做出来，正常运行； 而测试的工作是找茬，故意让程序不正常运行，生活中经常挑别人的毛病的人，也许更适合做测试。

如果通过设计一条用例，成功的让程序触发某种异常和错误，那就可以让团队趁早发现这个问题，从而在产品正式发布之前，让软件有一个更好的质量。

测试人员是靠 bug 来提升话语权的，如果有开发宣传“我写的代码没有bug"， 那我们反驳的最好方式是多找几个 bug 出来。

黑盒测试要精通

黑盒测试是一种重要的测试策略，所有刚入行的测试首先就是把黑盒测试玩得非常顺手。使用这种测试方法时，将程序视为一个黑盒子。测试目标与程序的内部机制和结构完全无关，而是将重点集中放在发现程序不按其规范正确运行的环境条件。

而白盒测试是测试程序的内部机制和结构，能够看到具体的代码，对测试人员的要求更高。

黑盒测试又称为数据驱动的测试或输入/输出驱动的测试。 因为关注不到具体的代码逻辑，所以只能控制盒子外面的数据（输入和输出)。

穷举法没用

穷举法是把所有可能的输入条件作为测试用例，但是一个功能的输入基本上都是无限的，使用穷举法意味着要对每个单一功能设计无限个测试用例，这当然是不可能做到的。

比如说用户界面中需要你输入一个手机号用来登录，去测试的时候不仅需要输入正确的手机号，而且还需要测试输入的不是手机号时，程序如何反应。 不是手机号的数据你永远都举不完。

穷举法不会用在实战当中的第二个原因是它不经济。 就算我们可以把所有的数据都列举出来，也没有足够的时间和精力对每个数据去执行测试。

好的测试策略是经济高效的

在测试一个软件时，一定要制定好策略。 如果所有的测试人员都不精通代码，那么最好以黑盒测试为主，白盒测试会花费大量的人员培养成本。

在设计用例的时候要根据具体的业务对测试进行划分，灵活使用各类用例设计方法。

在面试的时候，通常需要结合具体的业务谈谈上家工作怎么做测试，具体的测试流程是怎样的，测试策略是怎样的，这些可以看看我整理的真实面试题集锦，顺便求个赞，三连必回哦。

测试原则是一个测试人员时刻要铭记在心的，甚至要形成一种本能，指导测试工作。

原则1：测试找不出所有的Bug

软件的复杂性仅次于生命体，甚至现在很多软件都已经有了人工智能的属性。对于这样精妙的系统，一小点异常都有可能产生连锁反映，最终让整个系统无法运行。就好像人体只需要吸入一粒微小的尘埃，就可能感染病菌，从而引起人体的高能反应，最终导致人病倒，无法行动。

像软件这样的精妙系统，就算做再多测试，也无法找出所有的错误，就好像你永远无法保证，人不生病一样。

原则2：2/8 原则

少数功能模块会测试到大多数缺陷，用数字来表示就是 80％的问题出现在20％的功能模块中。在很多领域中都存在 2/8 原则，而在测试中同样会运用到这个原则。

为什么会这样的原因很多，我们只能适当分析。 比如开发某个功能模块的程序员水平不行，引入了大量缺陷； 也可能是这个功能模块非常复杂，可能出现大量没有考虑到的因素。

原则3：尽早介入测试

一个软件越复杂，越有可能产生新 bug。 热力学第二定律指出：孤立系统自发地朝著热力学平衡方向──最大熵状态──演化，同样地，第二类永动机永不可能实现。

这个定律同样适用于信息系统。 当一个软件引入越多的信息，越多的功能，会让软件变得越来越混乱，从而产生越来越多bug。

如果要少产生bug，首先是要保持软件整体的简单性，还有就是尽早介入测试。 因为在一个功能被开发的早期，功能还足够简单，早期介入测试能更高效的找到bug，如果一个功能演化到后期，被更多其他的程序使用，变得越来越复杂，找到bug会难很多。 尽早介入测试，还可以让开发快速得到反馈，从而尽快修复bug，不会把bug带到更复杂的代码世界中。

原则4：抗药性原则

抗药性原则又叫杀虫剂悖论（Pesticide Paradox）。随着时间的推移，重复使用相同的杀虫剂消灭昆虫会导致昆虫对农药产生抵抗力，从而使杀虫剂对昆虫无效，这同样适用于软件测试。

如果进行相同的重复测试，则该方法将无助于发现新的缺陷。为了解决此问题，需要定期检查和更新测试用例，添加新的和不同的测试用例以帮助发现更多的缺陷。测试人员不能简单地依靠现有的测试技术。他必须不断寻找改进现有方法的方法，以使测试更有效。

原则5：要有精确的预期结果

测试用例中一个必需部分是对预期输出或结果的定义，这条显而易⻅的原则在软件测试中却是最常犯的错误之一，很多测试人员对程序应该产生的结果没有明确定义，只是凭感觉判断结果是否异常。

尽管“软件测试是破坏性”的定义是合理的，但人们在潜意识中仍然渴望看到正确的结果，所以当程序运行符合测试人员的心理预期时，他们会自以为程序是正常的。没有期望，也就没有所谓的意外。

克服这种倾向的一种方法，就是通过事先精确定义程序的预期输出，鼓励人们对所有的输出进行仔细检查。因此，一个测试用例必须包括两个部分：1.对程序的输入数据的描述。2.对程序在上述输入数据下的正确

如有不懂还要咨询下方小卡片，博主也希望和志同道合的测试人员一起学习进步

在适当的年龄，选择适当的岗位，尽量去发挥好自己的优势。

我的自动化测试开发之路，一路走来都离不每个阶段的计划，因为自己喜欢规划和总结，

测试开发视频教程、学习笔记领取传送门！！！