软件测试基础（一）

软件测试基础（一）

一、什么是软件测试

执行程序，发现软件缺陷的过程；实质上：在执行程序的过程中 ，我们希望测试到程序的每一行代码，每一个分支逻辑。

二、什么是软件的缺陷

Ron Patton 所著的《软件测试》为我们的软件缺陷所下的定义:

1. 软件没有实现产品的说明书所描述的功能。

2. 软件实现了产品说明书描述不应有的功能。

3. 软件执行了产品说明书没讲的操作。

4. 软件没有实现产品说明书没讲但应该实现的功能。

5. 从软件测试员的角度来看，软件难以理解、不易使用、运行缓慢，或者最终用户认为不对。

总结和理解：

1、没有遵循产品说明书来设计
2、产品说明书没写但应实现（这一点很容易引发开发和产品的矛盾，开发会认为需求没有不需实现，也不去询问，互相指者，产品开发互相指责，“产品：开会你又不问；开发：谁想得到。。。。。。”；测试要从中调解，第一：发现此类问题，看问题严重程度，给予产品反馈，如果确认这个问题一定是需要解决，让产品优先补充需求或强调这个是需要实现的，第二：根据团队情况看是否把BUG提到系统上，可以挂一个BUG到自己身上或者做备忘，每天上午上班，下午上班，下午前询问这个问题是否解决）
3、反馈用户和测试过程中遇到的问题，讨论出是否需要解决，需要解决则认为是缺陷

• 你印象中最深刻的Bug？（讲点有深度的Bug）

  1、什么Bug
  2、怎么发现（工具+方法+原理）
  

并非所有Bug都需要修复

“每一个测试人员都一颗追求完美的心”，当我们发现了一个缺陷时，我们希望它能够被修复，我们不能容忍被发现的缺陷眼睁睁的存在着而无法得到修复。在软件测试中，令人沮丧的现实是，即使拼尽全力，也不是所有的软件缺陷都能修复。

1. 没有足够的时间，在项目中，出现临近上线，开发没有足够的时间修复Bug
2. 修复的风险太大，在项目中，可能由于历史的原因导致添加新功能的时候，引起的Bug，如果需修复需要重构该模块的功能
3. 修复成本太高，当我们使用一种技术去完成一项工作，当技术将要完成的时候发现一个缺陷无法解决，需要换用另一个技术才能有效规避这个缺陷。那这个修复成本将非常高。迫于时间与成本的压力。我们需要暂时不去理会。
4. 目前技术无法解决，例如，在AI技术没有高速发展的年代，当时的自动翻译软件翻译出来的结果大多数是直译的，现在引入AI技术后，翻译的精准度的提高是数量级的改变。
5. 不算真正的缺陷，有人说，这不算缺陷，而是一项新的功能。在某些特殊场合，错误理解、测试错误或说明书变更会把软件缺陷当作附加功能来对待。
6. 不值得修复，这不算缺陷，而是一项新的功能。在某些特殊场合，错误理解、测试错误或说明书变更会把软件缺陷当作附加功能来对待。

面试题：

• 开发不认为是Bug你怎么处理？

  - 聊天工具沟通，3句说不明白，当面沟通解释这个为什么我认为是BUG
  - 这个时候不外乎是三种情况：
  	1 认同我说的这个BUG，但需求没说；和产品讨论是否需要实现和修改；如果产品经理说确认是Bug，属于隐性的需求或者的需求遗漏说明的一个点，测试评估该Bug的严重程度和影响，产品、测试、开发一起商量何时修复并上线，如果修复的时间成本很低或者Bug的严重程度高，在该版本修复；如果临近上线来不及，Bug的严重性不高，则在下一个版本修复。（测试同学要有风险控制意识，评估Bug的严重性和影响，因为有可能1个BUG就让你的测试时间翻倍，项目导致延期）
  	2 认同我说的这个BUG，直接修改
  	3 不认同我说的这个BUG，找产品经理或者项目经理做评估(找第三方评估)
  

完全测试的可能性

“每一个测试人员都一颗追求完美的心”，想找到程序中所有的Bug，但遗憾这是不可能做到的。

• 输入量太大
• 输出结果太多
• 软件实现的途径太多
• 软件说明书没有客观标准。从不同的角度看，软件缺陷的标准不同

输入输出太多不可能做到穷举 ，后面讲的测试方法，就是为了用有限的测试尽可能发现软件的缺陷

在工作中，对于不懂软件测试的的同事或领导，他们关心的是软件有没有Bug，很容易问：测试完了，没有Bug了是吧。
统一回答：”软件工程有Bug是正常的，不可能做到开发的程序没有Bug，也不可能做到测试发现所有的Bug，都是通过一定的方法来找到和解决Bug，达到上线的标准和降低Bug发生的可能性，加快产品更新迭代和尽可能让用户觉得我们产品好用，为用户解决问题，是我们的目标“

这也是测试人员遭受质疑的地方，你既然不能保证软件的质量，要你何用。测试人员可以提高软件的质量，至于能提高多少，全凭测试人员的能力决定了。不像开发人员对于一个功能的实现，能或不能是很明确的两个答案。

参考文章和推荐阅读

软件测试实质

《软件测试的艺术》