44.什么是测试策略?
　　测试策略描述测试工程的总体方法和目标 主要包括以下三个方面：
　　1 确定的测试技术和工具
　　2 制定测试启动 停止 完成标准
　　3 风险分析和应对方案
　　其目的 是为我们更好的写出高质量的用例 提供支撑
　　45. 软件测试按过程分为三个步骤
　　单元测试：单元测试又称模块测试，是针对软件设计的小单位 ─ 程序模块，进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。
　　单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
　　集成测试：在运行（可能是不完整）的应用中保证软件单元被结合后能正常操作的测试执行的阶段
　　系统测试：当应用作为整体运行时的测试执行阶段
　　46.软件测试员和组长的职责分工
　　普通测试员：
　　创作相关的测试计划和测试案例
　　识别可自动测试的区域
　　参与组内的测试计划和测试案例以及测试脚本分析工作
　　手动或自动测试
　　按照需求规格说明查证并验证各项功能
　　发现并报告bug，跟踪其状态
　　初步评估bug对产品其他部分的影响
　　测试组长：
　　确定测试的策略
　　参与对整个产品的完整测试计划的制定
　　参与并管理测试
　　评估bug对用户的影响
　　跟踪关键bug状态
　　管理测试工作和对象的资源
　　参与面试新人
　　交流状态和存在问题，并驱动问题的解决
　　促进组内的交流
　　47. 什么是bug？
　　软件的Bug指的是软件中（包括程序和文档）不符合用户需求的问题。
　　常见的软件Bug分为以下三类：
　　没有实现的功能
　　完成了用户需求的功能，但是运行时会出现一些功能或性能上的问题
　　实现了用户不需要的多余的功能
　　48.什么是CMM？
　　CMM：Capability Maturity Model，即“能力成熟度模型”。
　　它是一个分 5 级的、可以描述结构完善程度的模型，用它来说明所交付的软件的效能。
　　49. 您认为在测试人员同开发人员的沟通过程中，如何提高沟通的效率和改善沟通的效果？维持测试人员同开发团队中其他成员良好的人际关系的关键是什么？
　　尽量能有面对面的沟通，如果做不到，那么尽量能直接通过电话沟通，如果只能通过Email等非及时沟通工具的话，强调必须对特性的理解深刻以及能表达清楚。
　　一是真诚，二是团队精神，三是在专业上有共同语言，当然也可以通过直接指出一些小问题，而不是进入BUG Tracking System来增加对方的好感。
　　50. 你们以前的测试流程是怎样的？
　　明确需求——测试计划——制定测试策略和测试用例——搭建测试环境、执行测试用例、提交缺陷报告——对测试过程和版本质量评估得出测试总结报告——后验收测试
　　51. 请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。
　　黑盒测试：把测试对象当成一个黑盒子，测试人员完全不考虑逻辑结构和内部特性，只依据程式的需求说明书来检查程式的功能是否满足它的功能说明。
　　白盒测试：把测试对象当成一个透明的盒子，允许测试人员利用程序内部逻辑结构及相关信息，设计或选择测试用例，对程式所有逻辑路径进行测试。
　　单元测试：白盒测试的一种，对软件设计中的单元模块进行测试。
　　集成测试：在单元测试的基础上，对单元模块之间的连接和组装进行测试。
　　系统测试：在所有都考虑的情况下，对系统进行测试。
　　验收测试：第三方进行的确认软件满足需求的测试。
　　52. 您以往的工作中是否曾开展过测试用例的评审工作？如果有，请描述测试用例评审的过程和评审的内容。
　　53. 软件本地化测试和功能测试都有那些方面要注意？
　　本地化是将软件版本语言进行更改，比如将英文的windows改成中文的windows是本地化。
　　本地化测试过程中的测试工作集中在：
　　受本地化影响的方面，如 UI 和内容
　　区域性或区域设置特定的、语言特定的和地区特定的方面
　　基本功能测试
　　在本地化环境中运行的安装和升级测试
　　根据产品的目标地区计划应用程序和硬件兼容性测试。
　　54. 什么是软件质量？
　　高质量的软件是适当的、无错误的，能在预算内按时交货，满足需求/或期望，并且是可维护的。所以，质量是一个主观的术语。它取决于谁是客户以及客户对项目计划的影响。对一个软件开发项目来说，“客户”的范围很广，包括终用户、客户所接受的测试者、与客户合同有关的官员、客户管理、开发机构的管理者/会计/测试人员/销售人员、未来的软件维护工程师、股票持有者、杂志专栏记者，等等。每一类客户对“质量”都有自己的倾向性 – 会计部门判断质量会从其收益来考虑，而终用户则重视友好的用户界面和没有错误。
　　55． 为什么软件会有毛病？
　　1.交流错误或者没有进行交流，需求不明确
　　2. 软件的复杂性  编程错误
　　3. 需求变更   客户恐怕不明白改变需求的影响，也许是知道但依然需要变更 ── 会导致重新设计、重订工程进度表、对其他项目的影响、已完成的工作需要重做或者放弃、对硬件需求的影响等等。如果在项目中出现许多小的改变或一个大的改变，在项目各部分中出现已知或未知的相关的问题，可能会相互影响并导致出现问题。而且，不断地变更也会增加软件的复杂性，可能会导致错误的出现。这样会影响技术人员的积极性。在一些快速变化的商业环境里，持续变更需求的影响是致命的。在这种情况下，管理者必须知道它的危险性。质量保障和测试工程师必须与此相适应，并安排持续的广泛的测试，以克服不可避免产生的问题。
　　4. 时间压力
　　因为有许多猜测成分，软件开发项目的进度很难安排得理想。当后期限快到的时候，压力逐渐增大，错误随之产生
　　5. 自负心理、 代码文档质量差、 软件开发工具