标签：style blog http color 使用 2014
趣味小故事：
Bug词原意臭虫或虫子。
【第一个计算机Bug诞生68年】1945年9月，编译器发明者格蕾斯·哈珀正领着她的小组构造”马克二型”计算机。突然，马克二型死机了；哈珀在某出错继电器上发现一只被电死的飞蛾；她将蛾子贴到记事本中并注明”第一个发现虫子实例”。从此，计算机错误称为Bug，将发现Bug并纠正的过程叫”Debug”！
计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。
第一大来源于需求定位错误，需求说明文档没有写，或者不够全面，经常更改，总是导致的结果就是一开始的需求定错了，那么这个软件的bug就会出现。（在这里你就可以看出来bug不仅仅是编程的错误，更多的原因很可能是因为需求不明确）
第二大来源是设计错误。架构师设计架构，设计师设计更多的细节等错误。
还有一些原因很可能是测试错误，不过这一点的比例占得很小。
设计软件，通常我们需要有计划，有条理的开发过程来实现。这个过程的整个阶段，我们都可以从中发现bug。不过随着时间的推移，修复软件缺陷的费用也在呈十倍的增长。你可以想象建筑楼房一样，一开始还比较好改动，但是越到后来越不好改，而且很多时候找不到问题出在了哪里，很有可能需要拆掉一部分重新建，工期反复，搞不好最后还会赔钱。所以，费用的增长与软件的开发过程成正比增长，我们所需要做的，就是尽早的发现bug！
完全测试程序不可能
如果你妄想对一个程序进行完全测试，那我劝你别想了。完全测试程序是不可能的，首先输入量太大，输出结果太多，软件的执行路径也太多。而且需求是主观的，你认为对的，也许在别人眼里就是不正确的！
测试无法显示潜伏的软件缺陷
想想一下，如果让你测试软件，你测试很多回后的结果是，没有发现问题，但是这个时候你能说，这个软件是没有问题，没有bug的吗？软件测试的工作与防疫员是很相似的，你可以报告软件存在问题，但是却不能报告软件没有问题。解决方法，继续测试。
看完上面的两条，相信你对“软件测试有风险”这个标题有了一定的认识，任何人都无法对软件进行完全测试，这样也导致了软件很可能潜伏bug，所以，我们要做的是，尽可能的降低风险，贴近完全测试。在这里，软件测试员需要学会一个关键的思想——如何把数量巨大的可能测试减少到可以控制的范围，以及如何针对风险做出明智的抉择，哪些测试重要，哪些测试不重要。
你杀死过“小强（蟑螂）”吗？小强有一个很霸气的称号——不死的小强！
在这里我们的软件中的bug就像我们生活中的害虫一样，发现一个，附近可能就有一堆。而且一个有意思的现象是，软件中的bug也具有抵抗力，当我们反复使用相同的测试工具来测试的时候，慢慢的你就会发现该软件居然对此测试工具有了免疫力，戏称“杀虫剂怪事”，有意思吧。
我们需要做出一款没有任何bug的软件交付给用户吗？做过开发的应该都知道，很多软件的上市，多多少少都会存在一些缺陷，那么当时为什么没有改？
原因很多，比如没有足够的时间，不算是真正的bug，修复的风险太大，不值得修复等等，这些都可以是我们不修改bug的原因。记得我曾经在一篇博文中写过，心有百川之人，有的时候，我们的心胸也要给bug的留一些空间。
你可以这样理解，准确就是指命中目标，精确在软件的行业，你可以指软件的稳定性，计算的精度。我们对这个有个大致的了解就可以，这样有利于我们判断bug的严重级别，而且不同的公司可能有不同的标准，我们需要学习。
确认是保证软件符合需求；验证是保证软件满足用户的要求过程。这样说有点绕，你可以这样理解，确认是最基本的保证，更倾向于开发过程中的事情；而验证是要实际去检验的，根据现实生活来保证是否满足，是对最终产品的检验。
如果说这个软件一直很稳定，可靠，我们可以说这个软件具有可靠性，甚至于我们可以不完全正确的说，这个软件的质量很好；而实际上判定质量好坏的范围很广，比如软件的功能，运行能力，兼容性等等，可靠性只是判断软件质量的其中一条，是必要不充分条件。
在这里区分两个定义，软件测试员的目标是尽可能早的找出bug并确保bug修复；而软件质量保证人员的主要职责是创建和执行改进软件开发过程并防止bug发生的标准和方法。
他们两者有时候也会存在一些交叉，比如测试员会做一些QA的工作，QA人员也会进行一些测试。具体还要根据公司的安排来看，比如有的公司，测试和QA都是同一个人。
小结：
啰啰嗦嗦也说了这么多，其实我已经尽可能的精简了，嘿嘿。本文说的比较零散，算是对测试入门的一些专业术语和具体情况的一个了解吧。如果想要具体了解的，还要具体去查一些资料来学习，也欢迎与大家交流和探讨！
标签：style blog http color 使用 2014
原文地址：http://blog.csdn.net/caozhangyingfei0109/article/details/36688807
