软件测试的7个基本原则
软测小生
共 2644字，需浏览 6分钟
·
2020-10-23 18:48
毕生所学，得到最重要的东西是一种以原则为基础的生活方式，是它帮助我发现真相是什么，并据此如何行动。
– Ray Dalio《原则》
原则一：测试证明软件存在缺陷
时至今日，依然有不少人容易犯错：没有发现错误的测试说明软件没有缺陷。
这个原则可以用另一种方式来描述: 测试的本质是证明软件存在缺陷，而不是软件没有任何缺陷。
测试只能证明软件是存在缺陷的（证伪），而不是证明软件是没有缺陷的（证实）。
原则二：穷尽测试是不可能的
测试数据、输入和测试场景的所有组合是不可能的，因为它需要大量的时间。相反，测试团队只能专注于一些重要的指标，例如：设置测试策略的风险和优先级。一般来说，项目周期里永远不可能允许测试团队在项目中进行大量有效的组合测试。
比如测试一个简单的计算器，你可以尝试1+1,1+2,1+3,1+n……，但是时间上允许你把所有的数字都考虑进去做详尽测试吗？显然是不可能的，从功能本身出发也算是多余操作。
随着系统承载业务多，代码规模也越庞大，算法逻辑复杂度也越高。要让测试完全覆盖是不可能的。那难道不测？非也！我们可以采取以下策略：
1、精准测试：改动什么测什么；
2、二八原则：只测重点；
3、等价划分；
等等
原则三：尽早介入测试
这条很重要，但是对测试的要求也会更高。
“早期的鸟儿有虫吃”或者是“早起的虫子被鸟吃”，对，说的就是这个理儿，早，是我们解决问题的有效办法。
必须尽早介入测试活动，为软件开发的下一阶段做好准备。只要生成产品需求或文档，测试人员甚至就可以开始测试。
另外，尽早介入测试，测试人员能够更全面的了解需求和项目整体进度，知己知彼百战不殆，说的就是这个理儿。
尽早介入测试原则与测试左移和测试前移具有异曲同工之妙。
原则四：缺陷具有集群性
之前听过一种理论，二八原则，即：80%的错误是由20%的模块引起的。
缺陷聚类指的是在几个模块中发现了大部分缺陷。这一原则要求测试团队利用自己的知识和经验，确定要测试的潜在模块。这一预测有助于节省时间和精力，因为团队只需要关注那些 “敏感” 领域。
然而，这种方法也有缺点: 一旦测试人员只专注于所有团队的一小块区域，他们可能会错过其他区域的错误。
原则五：杀虫剂悖论
当我们反复使用相同的杀虫剂的时候，会有少量害虫产生免疫而存活下来，使得杀虫剂失去药效。
原则六：测试是上下文相关的
各种产品或项目包含不同的元素、特征和要求。因此，测试人员不能对不同的项目应用相同的测试方法。例如，银行行业的应用程序应该比娱乐软件需要做更多的测试。
原则七：无错误谬论
在 原则一：测试显示软件存在缺陷 中说明，测试是为了降低缺陷存在的可能性而开展的活动，即便多次测试都没有发现任何缺陷，也不能证明软件是完美的。
Appium移动端自动化测试--基础预热 Appium移动端自动化测试--搭建测试环境 Appium移动端自动化测试--录制测试用例并运行 Appium移动端自动化测试--使用IDE编辑并强化脚本 Appium移动端自动化测试--控件定位方法 Appium移动端自动化测试--元素操作与触摸动作 Appium移动端自动化测试--搭建模拟器和真机环境 Appium移动端自动化测试--测试用例改造 Appium移动端自动化测试--capability使用和常用设备交互命令
软件自动化测试交流群已创建，公号回复入群即可获取入群二维码。
评论