The definition of software defects
Look at Ron Patton is defined as our software defects under.
1, the software does not implement the functions described in the specification of the product. (Personally feel " description " than " claimed " more appropriate)
2, a software product specification describes undue function.
3, the software implementation of the product specification did not speak of operation
4, the software does not implement functions product specifications did not say it should be implemented.
5, from the point of view of software testers, software difficult to understand, difficult to use, slow, or the end user to be wrong.
Why are so many pieces to a definition to describe? This " defect " defined there is so complicated it? No, it is not complicated, the author just wanted to give a more comprehensive "defects" under the definition. Here we come to build a house for example, to explain the meaning of the definition of each. It is not very perfect and immutable product description says, but in the actual project, it can be very simple, ambiguous, and often changes should be noted.
1, the software does not implement the functions described in the product specification. The owner of the house want to have a landing large windows let the sun shine into the house better, and he deliberately drawn out of the house design drawings, and also be explained. As a result, he saw all four walls, only a small door of the house. So for testers, he is a defect.
2, software undue product features described in the specification. As the owner of the house lives in the south, warm weather, and hired masons north of the results to the owner of the house built with natural heating has a big chimney, and the owner of the house specially design drawings explained, his own house Do chimney. So for testers, this is a flaw.
3, the software implementation of the product specification did not speak of operation. Similar to the second, except that the second is the owner has made it clear not to say his chimney, but this one is emphasized that in case the owner did not say. Masons wiseacre added a chimney up. For testers, superfluous functions can also be considered a defect.
4, the software does not implement functions product specifications did not say it should be implemented. The height of the main room of the house, pattern, material, color described very clearly. Masons built the house at the time of the discovery, the owner did not mention foundations such thing, in order to make the house secure, so that all the houses are necessary to hit the ground, although the owner did not say, but the function of the foundation must be done. If the description does not do it because there is no, but this one must do. For testers, this can be depending on the defect.
6, from the point of view of software testers, software difficult to understand, difficult to use, slow, or the end user to be wrong. Software testers are testing software defect software in addition to running, the same as a user in the software re-use. If you feel that they are difficult to use, or software interface is very inefficient and ugly, etc., it can also be considered defective. Or end users find this is not something you want to get the product of time, it is now also possible defect. Of course, you say that things are not what you want, we can not rely side of the story, you can get a contract, product brochures evaluated.
The ok , analyze defined above defects, how to determine a defect. The following look at the original side testing, we can view them as software testing process of "rules of the road." It will help us to work better software testing.
The possibility of full completion of the test program
Beginning to do software testing might think to get after the software can be fully tested, find all software defects, software and perfect. Unfortunately this is not possible, we can not fully test a software, even the simplest program does not work. The main reasons are:
- Enter the amount is too large
- The output too much
- Way too much software
- Software Manual no objective standard. From a different perspective, a different standard software defects.
More than "too much" of possibilities together, resulting in test conditions are difficult to determine. Examples cited in the book original calculator, too complicated, all right! We have another simpler mail login. Although expressed scheme to "log on" to sample, like the first example describes the programming of each book is up, " the Hello world ." But this simple example to better illustrate the problem, here it is again.
To 126 mailboxes for example, the user length of 50 characters and a password is not too good computing (as are the * number), so here by 50 characters to calculate. Ok! Although, I already know the correct user name and password.
In the case enter the correct user name:
1 , enter the correct password can log name is also No,
2 , the error input 0 it? 1 it? 2 it? ...... until
99999999999999999999999999999999999999999999999999 ，
3. If the password is not numbers, but the character of it, A , b , c ... AA , bb , CC .....
4、如果是大写呢 A 、B、C.... AA 、BB、CC.....
5、如果是大小写呢 Aa、Ab ....
6、如果是小写+数字呢 1a 、1b 、1c ....2a 、2b 、2c.....
7、如果是大写+数字呢 1A 、1B 、1Cc....2A 、2A 、2A.....
8、如果是大写+小写+数字呢 1Aa 、1Bb 、1Cc ....1Aa 、1Bb 、1Cc.....
9、如果有特殊字符呢 @#￥%……&*
10、如果输入字符有空格呢 a b、adbc ee......
11、如果是其它字符+大小写字母+数字呢+空格呢 ！@#&+123AIBKIkklzcb ......
......
12、再换正确的密码，错误的文件名再来一次。
13、用错误的用户名和密码再把上面的情况验证一次。（这样会匹配到所有的用户名密码）
14、什么都不输，直接点击登录
这样穷举下去，哪怕世界上超级的计算机，也需要计算十年、百年才能验证所有情况。如果觉得某些测试条件是重复的或都无必要的或都为了节省时间，而将其剔除，那么就不能称为完全测试。
软件测试是有风险的
好吧！你已经知道了不进行完全测试是有风险的，如果决定不去测试所有的情况，那么我们就选择了风险。在上面的邮箱登录的例子中，（假如）由于程序所使用语言的特点，有些字符在存储的时候会被转义，如& 会被转义为_ 存储，一个叫“&&” 用户，一个叫“ __”的用户，使用了相同的密码，碰巧程序员没考虑到这种情况，那么程序该如何登录呢？（我也不知道，这只是个假设的例子）
对于一个免费开放的邮箱来说，会有成千上万的用户每天都有用户注册登录，如果有用户遇到了上面的问题呢？程序该如何处理？当然，对于一个邮箱系统，你可能不以为然，他的修复速度与成本都不算高，假如，这个用户有非常保密且重要的邮件，结果被别一个用户登录查看了呢？假如这不是一个邮箱系统，而是一个银行系统呢？那有可能用户的财产就会受到损失。（相比较而言，互联网产品（B/S架构）比客户端产品（C/S架构）的修复速度与成本要低。
这样说有些耸人听闻，又不能全部测试，不测试又会漏掉软件缺陷。软件终归要分布的，此时测试就要停止，但是如果这么快停止下来，还有测试没做。怎么办？
如上图所示，纵轴是表示缺陷的数量，横轴表示测试工作量。缺陷的数量随着测试工作的进展在不段减少；但测试费用也随着工作量在不段提高。
也就是说要想发现更多的缺陷就必须投入更多费用（这个费用包括时间、人力，物力）， 对一个新项目，我们前提可能1天发现10个缺陷。到后面可能10天发现1个缺陷，或者发现一个缺陷所需要的时间更长，我们有必要为发现一个缺陷而继续增加费用么？本来就不存在完美的产品，我们的目标是找到最合适的测试量，使投入（测试费用）与回报（修复缺陷数）达到最优。
测试无法显示潜在的软件缺陷
仔细理解一下这个标题。当测试人员对一个软件进行测试时，他发现了很多缺陷，功能的，界面的，兼容性能。然后，测试人员可以好不忧郁的说，这个软件存在缺陷。
当测试人员又对另一个软件进行测试时，他用尽各种测试方法，测遍所有功能（当然，这是不可能，上面已经说了无法完全测试），他投入了大量的时间和精力却最终没有发现一个缺陷。那么测试人员不能保证这个软件是没缺陷的，当然，他更无法去报告这些潜伏的缺陷。也就是说测试人员只能报告已经发现的缺陷，对于未知的谁也不能肯定。
（这也是测试人员遭受质疑的地方，你既然不能保证软件的质量，要你何用。测试人员可以提高软件的质量，至于能提高多少，全凭测试人员的能力决定了。不像开发人员对于一个功能的实现，能或不能是很明确的两个答案。）
找到的软件缺陷越多，就说明软件的缺陷越多
我们先来体会下面两句话。
“找到的软件缺陷越多，说明软件遗留的缺陷越少”
“找到的软件缺陷越少，说明软件遗留的缺陷越少”
不管是开发还是测试，我们期望软件遗留的缺陷少。但是上面的两句话都不成立。我们发现缺陷的多少和最终软件遗留的缺陷多少毫无关系。那么为什么会有上面两种推断呢？
“找到的软件缺陷越多，说明软件遗留的缺陷越少”这种情况，假设缺陷在一定数量的情况下，测试人员业务非常精通，测试极其认真，发现越多的缺陷 ，说明还遗留的缺陷就越少。那么，我也可以假设随便这么一测，就发现这么多缺陷，那这个软件应该还有很多。
“找到的软件缺陷越少，说明软件遗留的缺陷越少”这种情况，假设开发人员经验非常丰富，而且工作非常认真，测试人员花费了很大的时间和精力都不能找到缺陷，说明软件本身的质量很好，也就是说其本身遗留的缺陷越少。那么，我也可以假设为，是不是测试对业务不够熟悉，经验不够丰富，为什么发现不了缺陷。那么可能软件遗留的缺陷还有很多，只是我没有发现。
更严谨说法，或者更准确的说法是“找到的软件缺陷越多，只能说明软件的缺陷越多。”我们发现的缺陷越多，只能说明软件的缺陷多。并无法正明软件还遗留的缺陷的多少。
当然，也并不是无法评估软件遗留缺陷的多少，我们可以根据开人员的工作经验与技术能力，测试人员的工作经验，测试技能，对业务的熟悉程度以及以往完的成项目质量进行评估。
并非所有软件缺陷都能修复
“每一个测试人员都一颗追求完美的心”，当我们发现了一个缺陷时，我们希望它能够被修复，我们不能容忍被发现的缺陷眼睁睁的存在着而无法得到修复。在软件测试中，令人沮丧的现实是，即使拼尽全力，也不是所有的软件缺陷都能修复。
这并不意味着软件测试员未达到目的，或者项目小组将发布质量有缺陷的产品。其真正的含义是要软件测试员具备本文开头（缺陷的定义）中所描述的测试的素质---进行良好的判断，搞清楚在什么情况下不能追求完美。项目小组需要每对一个软件缺陷进行取舍，根据风险决定哪些要修复，哪些不要。
不需要修复软件缺陷的原因：
* 没有足够的时间。在任何一个项目中，通常是软件功能较多，而代码编写人员和软件测试人员较少，而且在项目进度中没有给测试留出足够的空间。
* 不算真正的缺陷。或者有人说，这不算缺陷，而是一项新的功能。在某些特殊场合，错误理解、测试错误或说明书变更会把软件缺陷当作附加功能来对待。
* 目前技术无法解决。你不会相信，人类有丰富的想象力，很多时候是受制于技术上无法实现。
* 修复的风险太大。这种情况非常常见。软件本身是脆弱的、难以理清头绪。修复一个软件缺陷可能导致其它软件缺陷出现。在紧迫的产品发布进度压力之后，修复软件将冒引入更多缺陷的情况下。我们只能不去理睬现有的缺陷。
* 修复成本太高，当我们使用一种技术去完成一项工作，当技术将要完成的时候发现一个缺陷无法解决，需要换用另一个技术才能有效规避这个缺陷。那这个修复成本将非常高。迫于时间与成本的压力。我们需要暂时不去理会。
* 不值得修复。虽然有些不中听，但这是真的。不常出现的软件缺陷和在不常用的功能中出现的缺陷，或都出现也不会造成什么影响，那么就不值得去修复。这些都要归结为商业风决策。
软件说明书不断变化
软件开发者面临一个难题。整个行业变化太快，去年还很时髦的产品今年就过时了，同时，软件变得更庞大、更复杂，功能越来越多，导致软件开发周期不断变长。这两种反作用力形成了矛盾，结果是产品说明书一变再变。
除了紧跟变化没有其他方法。假定我们的产品有一个不得更改的最终产品说明书。经过两年按部就班的开发快要完工时，结果竞争对也手发布了一个产品，结果从功能、性能、用户体验都要优于我们即将完工的产品。我们是继续完成一个失去竞争力的产品，还是重新讨论产品功能，重写产品需求，并开发修订产品？明智的选择是后者。
软件测试员必须要想到产品需求可能改变。未曾计划的特性会增加，经过测试并报告软件缺陷的特性可能发生变化甚至被删除。这些者是可能的。
软件测试术语
准确与精确
关于软件准确与精确之间是存在区别的。我的理解在保证准确的基础上求精确。拿一个计算器来做例子。我最喜欢拿一个计算器来输入10除以3 ，如查等于3.0（四舍五入）了，那么它就不够准确。如果计算的结果是3.3.... 那么要我看他的小数点后面有几个3 ，3越多表示越精确。（个人认为在软件测试中，这个用到的不多）
验证和合法性检查
虽然验证和合法性检查常常互换使用，但是他们有不同的定义。其中的差别对软件测试很重要。
验证是保证软件符合产品需求的过程。合法性检查是保证软件满足用户要求的过程。
验证更多的是站在产品需求的角度去测试软件，合法性（或叫“合理性”合适）是站在用户的角度是测试软件，当他们发生冲突时，就需要对产品时行衡量。但我偏向于用户角度，因为产品的最终目的是给用户使用，而不是为了符合需求文档。
质量和可靠性
质量解释为“优秀程度”或者“超越同类的”。如果说软件产品质量高，就是指它能够满足客户要求。客户会感到该产品性能卓越，优于其他产品。
如果在测试过程一直稳定、可靠，就会认为这是高质量的产品。这样理解错误。可靠性只是质量的一个方面。那么产品在各种机型上是否一样运行稳定。是否有技术支持，是否使用方便且性能优秀，这些灰是质量的组成部分。
测试与QA
软件测试人员的目标是找出软件的缺陷，尽可能早的发现并确定修复缺陷。
QA的主要职责是创建和加强促进软件开发并防止软件缺陷的标准和方法。