软件测试的疑惑（一）

1、如何描述一个缺陷？
看到这个问题，也许有些读者会觉得可笑：哪个测试人员不会描述缺陷？但是现实中却真的存在很多测试人员提交的缺陷需要向开发人员进行解释或者演示后，才能让人明白他真正要表达的意思。.
实际上，是否能够清晰地描述软件缺陷，绝对体现着一个测试人员的能力水平高低。
除了极个别的不能重现的缺陷外，一个软件缺陷至少应该描述清楚三方面的内容：缺陷概述、详细内容、重现步骤。
缺陷概述——用一到两句话详细地描述缺陷的症状，使管理人员一下子就能看明白大概是什么问题。
详细内容——详细地描述缺陷的症状，可以发表自己对该缺陷的一些意见。详细内容主要供程序员进行分析。
重现步骤——详细描述如何在系统中重现缺陷，这是非常重要的一项内容，如果重现步骤描述的非常清晰，将大大加快开发人员修改缺陷的速度。

通常情况下，很多缺陷管理软件把“详细内容”与“重现步骤”进行了合并，即只有一个文本输入框供测试人员录入信息，这就导致很多测试人员疏忽了去描述“重现步骤”。
此外其他诸如测试版本、测试环境、发现日期等辅助信息也应该认真录入。
2、缺陷是谁“生产”的？
在追究一些质量问题责任的时候。常常听测试人员抱怨：“这些模块简直是垃圾！不值得测试！浪费我的时间！”，
开发人员则抱怨：“重要的问题发现不了，却成天盯着那些无关痛痒的小问题，还不如自己去测试！”。

不符合用户要求的都可以称之为缺陷，因此缺陷的来源主要有两类：一类是没有正确理解用户需求，由系统需求或者分析人员设计出来的缺陷，这类缺陷主要由设计人员“生产”；
另外一类是程序开发人员没有按照设计要求进行开发或者编写的代码存在错误而引起的缺陷，这类缺陷由程序开发人员“生产”。
对于那些开发流程不规范的组织，通常开发人员会包办测试前的大部分工作。在这种环境下，几乎没有什么设计文档，软件开发主要按照程序设计人员的想像来进行，这个时候的缺陷则主要由开发人员“生产”。

测试人员不是缺陷的“生产”者，因为测试人员没有写过一行代码，这是否意味着测试人员可以在一旁“幸灾乐祸呢”？事实恰好相反，测试人员与缺陷关系更加密切，他们是“缺陷的缺陷”的制造者。
所谓“缺陷的缺陷”，主要指测试人员提交的“不是缺陷”的缺陷，即测试人员没有正确理解需求，从而提交了根本“不是缺陷”的缺陷，这种缺陷也是测试人员经常受到指责的重要原因。
关于上面的抱怨，测试和开发双方都需要摆正心态：因为实际双方都在不停的“生产”着缺陷，只是创造的方式不同罢了。
3、缺陷产生的原因是什么？
在上个问题中，已经介绍了设计人员、开发人员、测试人员都会“生产”软件缺陷。在实际工作中，缺陷产生的方式更是层出不穷，原因也是多种多样。例如开发人员去接杯水，碰巧和另外一个接水的同事聊了几句，结果回到工位时忘记了要在某个判断语句追加此前已经想好的一个判断条件，这无疑会产生一个缺陷。因此很难一下子把缺陷产生的原因全部陈列出来，下面只是一些引起缺陷的典型原因：
（1）开发人员不太了解需求，不清楚应该“做什么”和“不做什么”，常常做不合需求的事情，因此产生了缺陷；
（2）软件系统越来越复杂，开发人员不太可能精通所有的技术。如果不能正确地掌握新的技术或者知识，可能会产生缺陷；
（3）技术文档普遍编写的很差，甚至文档本身就有缺陷，导致使用者产生更多的缺陷；
（4）软件需求、设计报告、程序经常发生变更，每次变更都可能产生新的缺陷；
（5）任何人在编程时都可能犯错误，导致程序中有缺陷；
（6）技术人员常处于进度的压力之下，不能静心思考也很容易产生缺陷，尤其是在Deadline临近之际，频繁的加班是开发人员疲于应付进度；
（7）很多开发人员过于自信，喜欢说“没问题”，因此对于一些代码不进行认真的调试，这也是一些缺陷产生的原因；
（8）频繁的拷贝代码也会把缺陷随之复制到新的程序中，尤其是复制其它团队成员的代码更容易使一些缺陷隐藏在程序中。
4、软件的质量应该由什么人来负责？
对于一些开发管理混乱或者测试刚刚起步的组织，产品质量一发生问题，习惯上会归咎于测试小组，认为测试人员没有测试好产品，所以才产生了那么多的缺陷。
对于开发管理规范一些或者测试体系已经建立一定时间的组织，如果客户投诉产品质量问题，则往往开发人员与测试人员会一起接受处罚。这种处理方式多少会让测试人员心理稍稍平衡一些。
追根溯源，软件发生质量问题实际是项目管理不规范引起的。因此，如果要追究责任的话，软件质量问题的责任应该由整个团队来承担。只有提高整个团队的开发水平，才能提高质量。
此外，也应该认识到软件发现问题是正常的现象，很少有软件实现了零缺陷。做为公司领导者，应该具体问题具体分析，不要老是考虑如何惩罚自己的成员。

5、测试能保证质量吗？
在软件质量方面，目前多数IT企业主要采取三种措施：技术评审、过程检查、软件测试。
技术评审：技术评审最初是由IBM公司为了提高软件质量和提高程序员工作效率而采用的，主要指对项目计划、软件需求、系统设计等文档进行有效评审的过程。技术评审可以由专家团队组成，也可以由组织内部人员组成，它可以尽量避免设计人员在某些方面发生“闭门造车”的情形。
通过技术评审，可以尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷，从而有效地提高产品的质量。
过程检查：属于质量工程师（QA）的工作范畴，主要检查软件项目的“工作过程和工作成果”是否符合已经制定的相关规范。在项目执行过程中，质量保证人员要不断的按照项目计划对项目进行有效的监督和检查。
通过过程检查，可以找出明显不符合规范的工作过程或者工作成果，及时纠正开发中的错误。
因此，软件测试只是保证质量的最常用手段，仅仅通过测试是不能够保证质量的，还要辅以技术评审、过程检查等手段。
6、测试的目的是什么？
测试的目的是为了发现尽可能多的缺陷，这个观念很容易让人接受，但是却很难落实到实际工作中，因为测试的目的常常被定位为“证明软件没有问题”。软件质量是否优良在投产后才能有所体现。
正确理解测试的目的十分重要。如果认为测试的目的是为了说明程序中没有缺陷，那么测试人员就会向这个目标靠拢，因而下意识地设计很多不易暴露错误的测试示例，这些测试用例恰恰证明软件实现了预期功能，这样的测试是不真实的。成功的测试在于发现了迄今尚未发现的缺陷，测试人员的职责是设计这样的测试用例——它能有效地揭示潜伏在软件里的缺陷。
7、什么是测试策略？
测试策略描述测试工程的总体方法和目标。描述目前在进行哪一阶段的测试（单元测试、集成测试、系统测试）以及每个阶段内在进行的测试种类（功能测试、性能测试、覆盖测试等）。
测试策略的制定主要包含三个方面的内容：
（1）确定测试过程要使用的测试技术和工具；
（2）制定测试启动、停止、完成标准；
（3）进行风险分析和应对方案。例如测试与外部接口或者模拟物理损坏、安全性威胁。测试计划最关键的一步就是将软件分解成单元，按照需求编写测试计划。

文章为准备面试时，朋友分享的问题，添加自己的理解和体会，希望可以帮助到大家。