22 什么是“软件测试”？
Software testing is the process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs) and to evaluate the features ofthe software item
1就是一个通过分析软件和需求之前差异，发现bug,对软件的功能进行评价的过程。
2.软件测试就是在受控制的条件下对系统或应用程序进行操作并评价操作的结果。
3.软件测试是为了发现错误而执行程序的过程。
23 什么是“测试案例”?
测试案例是一份文档，它描述了一个输入、反应、或者是与其相应的预期的响应，以便来判断应用软件的工作是否正常。测试案例应当包括测试标识、测试案例的名称、目标、测试条件/设置、输入数据要求、步骤、以及预期的结果。
24 如果时间不够，无法进行充分的测试怎么办?
使用风险分析，确定测试的重点。由于很少有机会对一个应用软件进行所有可能的测试 (包括所有可能的事件组合、所有的相关性、或者一切可能出错的东西)，对大多数软件开发项目来说，利用风险分析是适当的。这需要判断技能、常识、感觉和经验。如果有正当理由，也可采用正式的方法。需要考虑下列因素：
1) 对于该项目的用途而言，哪种功能最重要?
2) 哪种功能对用户最明显?
3) 哪种功能对安全影响最大?
4) 哪种功能对用户最有用?
5)对客户来说，该应用软件的哪个部分最重要?
6)在开发过程中，该应用软件的哪个部分可以最先测试?
7)哪一部分代码最复杂，容易导致出现错误?
8)哪一部分的应用程序是在急迫或在惊恐的情况下开发出来的?
9)哪一部分程序与过去项目中引起问题的部分相类似/有关?
10)哪一部分程序与过去项目中需要大量维护的部分相类似/有关?
11)需求和设计的那些部分不清楚或不容易读?
12)开发人员认为在应用软件中哪些部分是高风险的?
13)哪些问题能造成最差的发行?
14)哪些问题最能引起用户抱怨?
15)哪些测试可以容易地覆盖多种功能?
16)哪些测试在覆盖高风险部分的测试时使用时间最少?
25 如果需求一直在变化怎么办?
1)如果可能，尽早与承担该项目风险的人接触，以便了解需求会怎样改变，从而可以尽早地改变测试计划和策略。
2)如果在对应用程序进行初始设计时多考虑一些适应性，那么以后在发生需求的改变时，就不需要再为改变做很多事情了。
3)好的代码注释和好的文档有助于开发人员作出相应的改变。
4)只要有可能，就应使用快速原型 (rapid prototyping)，以帮助用户确认他们的需求，从而减少变更。
5)在项目的时间表中应当留出余量，以应付可能出现的变更。
6)尽量把新的需求纳入应用软件的“下一版”，而把原始需求作为“第一版”。
7)通过谈判，把易于实现的新的变更列入项目，而把难于实现的新需求列入该应用软件的以后的版本。
8)要确保让客户和管理人员了解变更对进度表的影响、所带来的风险、以及因变更所引起的大量资金消耗。
9)在应付改变时，应在为建立自动测试而作的努力和重新进行测试所做的努力之间取得平衡。
10)在设计自动测试剧本时，试图使其有一些灵活性。
11)在对应用软件进行自动测试时，要把注意力集中在看来不大会改变的部分。
12)对变更进行适当的风险分析，以减少回归测试的要求。
13)在设计测试案例时要有一定的灵活性。做到这一点并不容易，所以要降低测试案例的详细程度，或者只建立高级的通用型的测试计划。
14)少注意详细的测试计划和测试案例，要把重点放在专门的测试 (ad hoc testing) 上。
26.软件测试分哪两种方法？分别适合什么情况？
软件测试方法一般分为两种：白盒测试与黑盒测试。白盒测试又称为结构测试、逻辑驱动测试或基于程序本身的测试，它着重于程序的内部结构及算法，通常不关心功能与性能指标；黑盒测试又被称为功能测试、数据驱动测试或基于规格说明的测试，它实际上是站在最终用户的立场，检验输入输出信息及系统性能指标是否符合规格说明书中有关功能需求及性能需求的规定。
27.一套完整的测试应该由哪些阶段组成？分别阐述一下各个阶段。
计划阶段、设计阶段、白盒单元、白盒集成、黑盒单元、黑盒集成、系统测试、回归测试、验收测试一套完整的测试应该由五个阶段组成：
1）测试计划首先，根据用户需求报告中关于功能要求和性能指标的规格说明书，定义相应的测试需求报告，即制订黑盒测试的最高标准。以后所有的测试工作都将围绕着测试需求来进行，符合测试需求的应用程序即是合格的，反之即是不合格的；同时，还要适当选择测试内容，合理安排测试人员、测试时间及测试资源等。
2）测试设计将测试计划阶段制订的测试需求分解、细化为若干个可执行的测试过程，并为每个测试过程选择适当的测试用例（测试用例选择的好坏将直接影响测试结果的有效性）。
3）测试开发建立可重复使用的自动测试过程。
4）测试执行执行测试开发阶段建立的自动测试过程，并对所发现的缺陷进行跟踪管理，测试执行一般由单元测试、组合测试、集成测试、系统联调及回归测试等步骤组成，测试人员应本着科学负责的态度，一步一个脚印地进行测试。
5）测试评估结合量化的测试覆盖域及缺陷跟踪报告，对于应用软件的质量和开发团队的工作进度及工作效率进行综合评价。
28.软件测试的类型有那些？分别比较这些不同的测试类型的区别与联系。
BVT （Build VerificationTest），主要目的是验证最新生成的软件版本在功能上是否完整，主要的软件特性是否正确Scenario Tests（基于用户实际应用场景的测试），Scenario Tests优点是关注了用户的需求，缺点是有时候难以真正模仿用户真实的使用情况Smoke Test，修复Bug后，针对此次修复是否会对其他模块造成影响而进行的专门测试。Smoke Test优点是节省测试时间，防止build失败。缺点是覆盖率还是比较低此外，还有Application Compatibility Test（兼容性测试），主要目的是为了兼容第三方软件，确保第三方软件能正常运行，用户不受影响。Accessibility Test（软件适用性测试），是确保软件对于某些有残疾的人士也能正常的使用，但优先级比较低。其它的测试还有Functional Test（功能测试）、Security Test（安全性测试）、Stress Test（压力测试）、Performance Test（性能测试）、Regression Test（回归测试）、Setup/Upgrade Test（安装升级测试）等
29.测试用例通常包括那些内容？着重阐述编制测试用例的具体做法不同结构的用例包括的不一样。（版本、编号、项目、设计人员、设计日期、输入、预期输出……）
软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果。
用例编号： 测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则： PROJECT1-ST-001 ，命名规则是项目名称＋测试阶段类型（系统测试阶段）＋编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。
测试标题： 对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如 “ 测试用户登录时输入错误密码时，软件的响应情况 ” .重要级别： 定义测试用例的优先级别，可以笼统的分为 “ 高 ” 和 “ 低 ” 两个级别。一般来说，如果软件需求的优先级为 “ 高 ” ，那么针对该需求的测试用例优先级也为 “ 高 ” ；反之亦然，测试输入： 提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。
操作步骤： 提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。
预期结果： 提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。
30.描述使用bugzilla缺陷管理工具对软件缺陷（BUG）跟踪的管理的流程
1) 测试人员或开发人员发现bug后，判断属于哪个模块的问题，填写bug报告后，系统会自动通过Email通知项目组长或直接通知开发者。
2) 经验证无误后，修改状态为VERIFIED.待整个产品发布后，修改为CLOSED.
3) 还有问题，REOPENED，状态重新变为“New"，并发邮件通知。
4) 项目组长根据具体情况，重新reassigned分配给bug所属的开发者。
5) 若是，进行处理，resolved并给出解决方法。（可创建补丁附件及补充说明）
6) 开发者收到Email信息后，判断是否为自己的修改范围。
7) 若不是，重新reassigned分配给项目组长或应该分配的开发者。
8) 测试人员查询开发者已修改的bug，进行重新测试。（可创建test case附件）
