41、发现的缺陷越多，说明软件缺陷越多吗？
　　这是一个比较常见的现象。测试工程师在没有找到缺陷前会绞尽脑汁的思考，但是找到一个后，会接二连三的发现很多缺陷，颇有个人成感。其中的原因主要如下：
　　-代码复用、拷贝代码导致程序员容易犯相同的错误。类的继承导致所有的子类会包含基类的错误，反复拷贝同一代码意味可能也复制了缺陷。
　　-程序员比较劳累是可以导致某些连续编写的功能缺陷较多。程序员加班是一种司空见惯的现象，因此体力不只时容易编写一些缺陷较多的程序。而这些连续潜伏缺陷恰恰时测试工程师大显身手的地方。
　　“缺陷一个连着一个”不是一个客观规律，只是一个常见的现象。如果软件编写的比较好，这种现象不常见了。测试人员只要严肃认真的测试程序可以了。
　　42、所有的软件缺陷都能修复吗？所有的软件缺陷都要修复吗？
　　从技术上讲，所有的软件缺陷都是能够修复的，但是没有必要修复所有的软件缺陷。测试人员要做的是能够正确判断什么时候不能追求软件的完美。对于整个项目团队，要做的是对每一个软件缺陷进行取舍，根据风险决定那些缺陷要修复。发生这种现象的主要原因如下：
　　-没有足够的时间资源。在任何一个项目中，通常情况下开发人员和测试人员都是不够用的，而且在项目中没有预算足够的回归测试时间，再加上修改缺陷可能引入新的缺陷，因此在交付期限的强大压力下，必须放弃某些缺陷的修改。
　　-有些缺陷只是特殊情况下出现，这种缺陷处于商业利益考虑，可以在以后升级中进行修复。
　　-不是缺陷的缺陷。我们经常会碰到某些功能方面的问题被当成缺陷来处理，这类问题可以以后有时间时考虑再处理。
　　后要说的是，缺陷是否修改要由软件测试人员、项目经理、程序员共同讨论来决定是否修复，不同角色的人员从不同的角度来思考，以做出正确的决定。
　　43、软件测试人员是QA吗？
　　软件测试人员的职责是尽可能早的找出软件缺陷，确保得以修复。而质量保证人员（QA）主要职责是创建或者制定标准和方法，提高促进软件开发能力和减少软件缺陷。测试人员的主要工作是测试，质量保证人员日常工作重要内容是检查与评审，测试工作也是测试保证人员的工作对象。
　　软件测试和质量是相辅相成的关系，都是为了提高软件质量而工作。
　　44、如何减少测试人员跳槽带来的损失？
　　在IT行业里跳槽已经是一种司空见惯的现象，而且跳槽无论给公司还是给个人都会带来一定的损失。测试队伍也无疑会面临跳槽的威胁，作为测试经理管理者，只有从日常工作中开始做起，能大限度的减少损失。建议我们从以下两个方面做起：
　　-加强部门内员工之间的互相学习，互相学习是建立学习型组织的基本要求，是知识互相转移的过程。在此基础上，可以把个人拥有的技术以知识的形式沉积下来，也完成了隐性知识到显性知识的转化。
　　-通常情况下，企业能为员工提供足够大的发展空间时，如果不是待遇特别低，员工都不会主动离开企业。因此我们要想留住员工，管理者应该把员工的个人成长和企业的发展联系起来，为员工设定合理发展规划并付诸实现。不过这项要求做起来比较，要有比较好的企业文化为依托。
　　45、测试产品与测试项目的区别是什么？
　　习惯上把开发完成后进行商业化、几乎不进行代码修改可以售给用户使用的软件成为软件产品，也是可以买“卖拷贝”的软件，例如Windows2000。而通常把针对一个或者几个特定的用户而开发的软件成为软件项目，软件项目是一种个性化的产品，可以是按照用户要求全部重新开发，也可以修改已有的软件产品来满足特定的用户需求。项目和产品的不同特点，决定我们测试产品和测试项目仍然会有很多不同的地方：
　　-质量要求不同。通常产品的质量要高一些，修复发布后产品的缺陷成本较高，甚至会带来很多负面的影响。而做项目通常面向某一用户，虽然质量越高越好，但是一般只要满足用户要求可以了。
　　-测试资源投入多少不同。做软件产品通常是研发中心来开发，进度压力要小些。同时由于质量要求高，因此会投入较多的人力、物力资源。
　　-项目后要和用户共同验收测试，这是产品测试不具有的特点。
　　此外，测试产品与测试项目在缺陷管理方面、测试策略制定都会有很大不同，测试管理者应该结合具体的环境，恰如其分的完成工作。
　　46、和用户共同测试（UAT测试）的注意点有哪些？
　　软件产品在投产前，通常都会进行用户验收测试。如果用户验收测试没有通过，直接结果是那不到“Money”，间接影响是损害了公司的形象，而后者的影响往往更严重。根据作者的经验，用户验收测试一定要让用户满意。
　　实际上用户现场测试更趋于是一种演示。在不欺骗用户的前提下，我们向用户展示我们软件的优点，后让“上帝”满意并欣然掏出“银子”才是我们的目标。因此用户测试要注意下面的事项：
　　（1）用户现场测试不可能测试全部功能，因此要测试核心功能。这需要提前做好准备，这些核心功能一定要预先经过测试，证明没有问题才可以和用户共同进行测试。测试核心模块的目的是建立用户对软件的信心。当然如果这些模块如果问题较多，不应该进行演示。
　　（2）如果某些模块确实有问题，我们可以演示其它重要的业务功能模块，必要时要向用户做成合理的解释。争得时间后，及时修改缺陷来弥补。
　　（3）永远不能欺骗用户，蒙混过关。道理很简单，因为软件是要给用户用的，问题早晚会暴露出来，除非你可以马上修改。
　　和用户进行测试还要注意各种交流技巧，争取不但短期利益得到了满足，还要为后面得合作打好基础。
　　47、如何编写提交给用户的测试报告？
　　随着测试工作越来越受重视，开发团队向客户提供测试文档是不可避免的事情。很多人会问：“我们可以把工作中的测试报告提供给客户吗？”答案是否定的。因为提供内部测试报告，可能会让客户失去信心，甚至否定项目。
　　测试报告一般分为内部测试报告和外部测试报告。内部报告是我们在测试工作中的项目文档，反映了测试工作的实施情况，这里不过多讨论，读者可以参考相关教材。这里主要讨论一下外部测试报告的写法，一般外部测试报告要满足下面几个要求：
　　-根据内部测试报告进行编写，一般可以摘录；
　　-不可以向客户报告严重缺陷，即使是已经修改的缺陷，开发中的缺陷也没有必要让客户知道；
　　-报告上可以列出一些缺陷，但必须是中级的缺陷，而且这些缺陷必须是修复的；
　　-报告上面的内容尽量要真实可靠；
　　-整个测试报告要仔细审阅，力争不给项目带来负面作用，尤其是性能测试报告。
　　总之，外部测试报告要小心谨慎的编写。
　　48、测试工具在测试工作中是什么地位？
　　国内的很多测试工程师对测试工具相当迷恋，尤其是一些新手，甚至期望测试工具可以取代手工测试。测试工具在测试工作中起的是辅助作用，一般用来提高测试效率。自动化测试弥补了手工测试的不足，减轻一定的工作量。实际上测试工具是无法替代大多数手工测试的，而一些诸如性能测试等自动化测试也是手工所不能完成的。
　　对于自动测试技术，应当依据软件的不同情况来分别对待，一般自动技术会应用在引起大量重复性工作的地方、系统的压力点、以及任何适合使用程序解决大批量输入数据的地方。然后再寻找合适的自动测试工具，或者自己开发测试程序。一定不要为了使用测试工具而使用。
　　49、常见的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。
　　1-等价类划分
　　常见的软件测试面试题划分等价类: 等价类是指某个输入域的子集合.在该子集合中，各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值等于对这一类其它值的测试.因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.
　　2-边界值分析法
　　边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例，可以查出更多的错误.
　　使用边界值分析方法设计测试用例，首先应确定边界情况.通常输入和输出等价类的边界，是应着重测试的边界情况.应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据.
　　3-错误推测法
　　基于经验和直觉推测程序中所有可能存在的各种错误， 从而有针对性的设计测试用例的方法.
　　错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例-例如， 在单元测试时曾列出的许多在模块中常见的错误-以前产品测试中曾经发现的错误等， 这些是经验的总结。还有， 输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行-这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例.
　　4-因果图方法
　　前面介绍的等价类划分方法和边界值分析方法，都是着重考虑输入条件，但未考虑输入条件之间的联系， 相互组合等-考虑输入条件之间的相互组合，可能会产生一些新的情况-但要检查输入条件的组合不是一件容易的事情， 即使把所有输入条件划分成等价类，他们之间的组合情况也相当多-因此必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例-这需要利用因果图（逻辑模型）-因果图方法终生成的是判定表-它适合于检查程序输入条件的各种组合情况.
　　5-正交表分析法
　　有时候，可能因为大量的参数的组合而引起测试用例数量上的激增，同时，这些测试用例并没有明显的优先级上的差距，而测试人员又无法完成这么多数量的测试，可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性。
　　6-场景分析方法
　　指根据用户场景来模拟用户的操作步骤，这个比较类似因果图，但是可能执行的深度和可行性更好。
　　50、您认为做好测试用例设计工作的关键是什么？
　　白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果
　　黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以少的用例在合理的时间内发现多的问题
　　51、详细的描述一个测试活动完整的过程。
　　1-项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员，测试人员以及客户的意见，完成项目计划。然后sqa进入项目，开始进行统计和跟踪
　　2-开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包括是否有遗漏或者双方理解不同的地方。测试人员完成测试计划文档，测试计划包括的内容上面有描述。
　　3-测试人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档，详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。
　　4-测试用例完成后，测试和开发需要进行评审。
　　5-测试人员搭建环境
　　6-开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测试，发现bug后提交给bugzilla。
　　7-开发提交第二个版本，包括bug fix以及增加了部分功能，测试人员进行测试。
　　8-重复上面的工作，一般是3-4个版本后bug数量减少，达到出货的要求。
　　9-如果有客户反馈的问题，需要测试人员协助重现以及回归测试。
　　52、以往是否曾经从事过性能测试工作？请尽可能的详细描述您以往的性能测试工作的完整过程。
　　曾经做过一套网管系统的性能测试，主要测试该软件在同时管理大量终端的情况下，在响应时间，cpu/磁盘/内存等参数是否满足要求。
　　也曾经做过软交换系统的呼叫性能测试，主要是测试软交换系统在有大量呼叫的情况下，响应时间，呼叫成功率，cpu/磁盘/内存等参数是否满足设计要求。
　　53、在您以往的工作中，一条软件缺陷（或者叫bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（bug）记录？
　　1-在传统的bugzilla中，bug描述应该包括以下的信息
　　2-和bug产生对应的软件版本
　　3-开发的接口人员
　　4-bug的优先级
　　5-bug的严重程度
　　6-bug可能属于的模块，如果不能确认，可以用开发人员来判断
　　7-bug标题，需要清晰的描述现象
　　8-bug描述，需要尽量给出重新bug的步骤
　　9-bug附件中能给出相关的日志和截图。
　　高质量的bug记录是指很容易理解的bug记录，所以，对于描述的要求高，能提供的信息多且准确，很好的帮助开发人员定位。
　　54、您在从事性能测试工作时，是否使用过一些测试工具？如果有，请试述该工具的工作原理，并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。
　　测试网管系统中，使用的mimic来模拟终端，能够大量的节省成本。
　　测试软交换系统的时候，使用的prolab来模拟终端并发送呼叫软交换，他完成了同时数百人才能完成的摘机拨号工作，主要工作原理是产生一些符合要求的ip包并发送给软交换系统，同时对软交换系统的回应进行处理，决定下一步动作。
　　55、您认为性能测试工作的目的是什么？做好性能测试工作的关键是什么？
　　主要是保障在大量用户的情况下，服务能正常使用。