软件测试

由于开发人员和测试人员对需求的理解存在的差异，以及各自的工作角色，关于BUG的争论在日常的项目中是经常遇到的，如何保证BUG及时修复，非BUG不影响项目的进度至关重要

在软件测试中版本控制虽然是一门基本的实践性技术，但是许多人并不知道如何使用它，或者未能有效地利用它。这里与大家分享一下，以作为前事不忘，后事之师。

你是怎么看待“搭建测试环境”这个事情的，你觉得你能从中学到什么？你觉得这个对你后面的工作有帮助吗？你觉得测试环境的更新除了替换版本外还应该考虑什么问题？很多人都会这么回答，我觉得能学到很多东西，但具体说不上来，对后面的工作有帮助，但具体有哪些帮助同样说不上来，测试环境的更新，除了保证更新成功外，似乎没有什么需要再考虑的了。从搭建测试环境，我们到底能提升什么呢？

在添加Bug时要注意以下方面：缺陷摘要（Summary）； 缺陷描述（Description）；截屏/附件（Attachment）；其它。

什么样的测试算是好测试？我们又该怎么知道如何编写好测试？Kent Beck断定，好的测试应该具备下列条件：1. 互相隔离的；2. 自动化的；3. 编写快；4. 运行快；5. 独一无二。

文档测试之产品说明书属性检查清单

潘少红专栏

处于SOA早期阶段的企业或是企图发起SOA的企业不要忘记考虑SOA为测试带来的附加影响。理解存在的风险、评估你的内部技巧并明确技能空白，建立一个有经验的从业者网络，确认必要的工具和所需流程，确保资金提供包含了测试组织的需求。

所谓结对测试，是指两个人同时同地测试同一对象，并且在过程中充分交换思想。结对测试的想法是从结对编程中转化而来，却又和结对编程在出发点和执行思路上有较大的差异。结对测试是一种测试过程中的方法，独立于测试策略，可以施行于各种不同的开发测试模型中，当然，也可以在敏捷开发的过程中使用。

结对编程（Pair Programming）是一个非常简单和直观的概念：两位程序员坐在同一台电脑前合作完成同一段代码。两个程序员具有相同的缺点和盲点的可能性很小，所以结对编程会获得一个更优的解决方案。类似的，结对测试（Pair Testing）能不能让两个测试人员结对呢？工作经验、教育经历、看问题的角度、思维方式的差异肯定能让我们在测试同一份测试样品的时候，取长弥短、优势互补，减少测试遗漏。

现在的软件系统很多都通过安装包的方式发布。用户通过安装包安装软件系统。安装包在安装的过程中就把很多参数和需要配置的东西设置好，用户安装好软件就可以马上使用。

探索性测试可以说是一种测试思维技术。它没有很多实际的测试方法、技术和工具，但是却是所有测试人员都应该掌握的一种测试思维方式。探索性强调测试人员的主观能动性，抛弃繁杂的测试计划和测试用例设计过程，强调在碰到问题时及时改变测试策略。

人们对于性能测试和压力测试的理解往往源于对网站的体验，例如访问某个网站的页面，10秒钟还未打开，于是大部分人都选择了放弃。

安全性测试是一项迫切需要进行的测试，测试人员需要像黑客一样攻击软件系统，找到软件系统包含的安全漏洞。

有天，我接到A公司的面试通知，于是有了以下一份面经。这家公司的面试分2部分，先是笔试（后面附上笔试题目），然后是面试，下面让我慢慢道来。

解释模糊测试（模糊化）的最好方法就是使用示例。最近以来，模糊化的最常见用处是验证两种类型的数据分析程序：文件和网络。

本文介绍了团队所采用的将一组系统测试子集作为敏捷开发环境的一部分，并与代码开发活动并行的方法。我们将展示出我们的方法可以交付更好的系统测试应用程序，让实验方法将包含与代码开发并行的系统测试子集的价值和效率最大化，并提高团队的沟通和技能。这些成功 导致 （led）了在完整的系统测试开始时改进了的完整的 软件验证团队（ SVT ） 的加速的时间，以及改进了的产品质量的预期好处。

通过集成测试之后，软件已完全组装起来，接口方面的错误也已排除，确认测试即可开始。确认测试应检查软件能否按合同要求进行工作，即是否满足软件需求说明书中的确认标准。

软件测试中常见的一个问题就是概率性问题，概率性问题无论对软件测试人员还是对开发人员而言都是比较头疼的一个问题。这种概率性问题在测试中该如何处理呢？

启发法测试策略模型是设计测试策略的一套模式。这个模型的直接意图是提醒测试人员在创建测试时应该要想到的一些东西。最终，这套模型要根据实际情况来定制，并用来在专业测试人员中促进交流、自学、并且更充分的进行有意识的测试。