我们需要什么样的软件测试?

[来源] 达内    [编辑] 达内   [时间]2013-02-03

对互联网产品来说,最有效的测试方式也许并不是找一堆专职的测试工程师在公司内部尽可能地覆盖每一个功能细节,让真正的用户来对产品进行测试在很多情况下也许是更好的选择。无论是FB

  1.“用户质量”和“开发质量”就是我通常用来分析一个产品究竟需要什么样的测试的第一个因素。

  在这个维度下,我们可以很容易地理解,如果一个产品仅仅是 “一次性”的产品(也即,开发后不再需要维护和持续演化),那么测试的重点一定就是“用户质量”(只需要关心该产品是否在用户面前表现得够好 可以了);代码是不是够烂,设计是不是不合理并不重要。而如果一个产品是需要持续演进较长时间的,那就必须关心代码和设计的质量(“开发质量”)。例如,一个采用付费下载方式进行销售的小游戏,开发团队通常不会花太多的时间和精力在保证产品具有良好的“开发质量”上,而宁愿花更多的时间去调整外部的细节表现,音效,图像上。

  2. 另一个直接决定了产品需要什么样的测试的纬度是“产品对缺陷的容忍程度”。

  测试工程师有时候喜欢把“零缺陷”作为标榜测试工作的口号(我在很长一段时间内也是如此),但,仔细想想,如果发现一个缺陷的成本比让这个缺陷留在产品中带来的损失更大,那是否还值得去发现这个缺陷?我想 从项目的角度来说,答案是不言而喻的。测试是一个资源权衡的活动,也是一个基于风险的活动,因此,产品的缺陷带来的影响越小,影响越容易被消除(修复),这个缺陷的价值就越小,值得投入用来发现缺陷的资源也就越少。

  拿互联网产品和传统的桌面产品来比较,对桌面型产品来说,缺陷的修复成本足够高(只能通过软件召回或是发布补丁的方式),因此对缺陷的容忍度就低;而对于互联网产品来说,由于其产品的修复成本足够低(对一个已知的 缺陷,可能只需要花上几分钟到几十分钟就能完全修复了),因此相对而言,其对缺陷的容忍程度更高(当然,对于那些会导致用户数据损失或是带来其他不可逆破坏的缺陷,那又另当别论了),对互联网产品开发来说,及时识别缺陷(发现那些用户已经遇到的缺陷),快速定位缺陷和快速修复缺陷的能力往往要比在系统测试阶段发现缺陷的能力更重要。而要能有强大的识别缺陷和定位缺陷的能力,就必须依靠产品内建的“开发质量”了。

  再以医疗行业的某些软件为例,对涉及到医疗器械的控制软件(如自动注射器,心脏起搏器等),其对缺陷的容忍程度就非常低,原因很简单,因为这类缺陷可能带来的后果太严重。

  3. 第三个因素是“有效的测试方式”。

  对互联网产品来说,最有效的测试方式也许并不是找一堆专职的测试工程师在公司内部尽可能地覆盖每一个功能细节,让真正的用户来对产品进行测试在很多情况下也许是更好的选择。无论是FB,Google等公司提倡的dog food( 全部员工来进行测试),还是在实际产品上进行的a/b testing, 或是游戏公司通常喜欢采用的内测方式,都是典型的让用户参与测试的方法。另外,根据产品不同的特性,适合采用手工测试还是自动化测试的方式来进行测试也是一个值得考虑的点。

  4. 第四个因素则是“产品的开发团队所处的状况”,因此,对同一个组织来说,在组织发展的不同阶段,所需要的测试也是不同的。

资源下载