文章目录
- 软件测试定义
- 软件缺陷的定义
- 软件失败的一些术语
- 臭名昭著的软件缺陷案例
- 软件缺陷产生原因
- 软件缺陷的修复费用问题
- 并非所有的软件缺陷都需要修复
- 软件测试员在做什么
- 软件测试员应具备的素质
软件测试定义
IEEE1983年定义：
使用人工或自动手段来运行或测定某个系统的过程，检验他是否满足规定的需求或是弄清楚预期结果与实际结果之间的差别。
软件缺陷的定义
满足下面五个条件之一：
- 软件未实现产品说明书要求的功能；
- 软件出现了产品说明书指明不应该出现的错误；
增加功能的同时也就引入了更多的风险
- 软件实现了产品说明书未提到的功能；
- 软件未实现产品说明书虽未明确提及但应该实现的目标；
例如测试一个计算器时，没有考虑到电池电量不足可能会导致的计算不正确的情况。
- 软件难以理解、不易使用、运行缓慢或者——从软件测试员的角度来看——最终用户会认为不好。
同样用计算器举例，假如计算器中“=”的位置放置让人使用起来感觉不舒服，那么这个问题就可以认为是软件缺陷。
另外：软件测试员是第一个真正使用软件的人，否则客户就是第一个使用软件产品的人。
需要知道，编写让所有客户都满意的软件是不可能的，所以评价是一定要尽量的客观、全面。
软件失败的一些术语
缺点：defect 偏差：variance
故障：fault 失败：failure
问题：problem 矛盾：inconsistency
错误：error 特殊：feature
事件：incident 缺陷：bug
异常：anomly
至于在开发过程中使用哪些词，这与开发小组的特点有关系。
臭名昭著的软件缺陷案例
上面的例子是课本上的关于国外的一个重大的软件缺陷的例子，国内的只查到了08年奥运会网站崩溃的例子。其他有知道的案例大家可以在评论区补充一下。
另外需要注意的是，在英特尔处理器事件中，Intel公司的解决方式很有问题。1：测试时发现了这个问题，管理层认为没必要修复，也没必要公开；2：软件缺陷被大众发现时，公司试图弱化问题的严重性；3：因公众压力决定对软件进行召回时，要求用户证明自己因缺陷受到了影响。
在爱国者导弹系统中是双方独立工作都很好，但是合在一起就不行了。
软件缺陷产生原因
根据刚才软件缺陷的定义来看，显然核心词汇是“产品说明书”，几乎每一条都与产品说明书有关。
所以大多数软件缺陷最大原因并非源自编程错误，而是产品说明书。
第二大来源是设计。原因是随意、易变、沟通不足。
软件缺陷的修复费用问题
考虑如下情景（这里假设使用瀑布模型进行开发，当前在软件测试阶段）：
当产品刚开始拿去测试时，可以认为可以很快的找出第一个软件缺陷，再根据错误往往集中出现的原则，我们可以认为这段代码相关的或者附近的位置仍有错误，此时找出软件缺陷的时间成本和人力成本都是比较小的。
接下来，随着时间的推进，我们把刚才提到的软件进行了许多修复，可以找到的缺陷越来越少。此时若我们坚持找出来软件所有的错误（这当然是不可能的），就需要花费更长的时间和精力，此时的修复成本会急速增加。因此我们需要在测试数量与成本之间找到一个平衡点。
大意如下图所示：
并非所有的软件缺陷都需要修复
原因如下：
1.时间是有限的，我们没有足够的时间
2.不算真正的软件缺陷。很多情况下，理解错误、测试错误或者说明书变更会把可能的软件缺陷当做功能来对待
3.修复的风险太大。因为修复本身可能会带来新的、未知的缺陷
4.不值得修复。有些缺陷在不常用的功能中出现或者有些缺陷本身不常出现，那么通常不修复。但是这需要有上级决定，而不是程序员和测试员自己决定。这取决于商业风险决策。
软件测试员在做什么
首先我们达成一点共识：软件测试员的目的是发现软件缺陷。
但是这样就够了吗？前面说过，我们的时间是有效的，产品总是会有交付日期等时间限制的，所以我们需要将上面的表述改为：软件测试员的目的是尽可能早的找出软件缺陷。。
接下来进一步思考，找出软件之后就放手不管吗？显然不是。我们需要敦促程序员将缺陷修复（这也是为什么程序员与测试员的关系一般都是不好的（笑））。所以给出最终表述：软件测试员的目的是尽可能早的找出软件缺陷，并确保其得以修复。
“修复”缺陷并不一定是指改正软件，还可以在用户手册中增加注释，又或者为用户提供特殊的培训。
软件测试员应具备的素质
- 他们是探索者
- 他们是故障排查员
- 他们不放过任何蛛丝马迹
- 他们具有创造性
- 他们是群追求完美者
- 他们判断准确
- 他们注重策略和外交
- 他们善于说服
