1.测试结束标准是什么？
2.描述软件测试活动的生命周期？
3.软件的缺陷等级应如何划分？
4.当开发人员说不是BUG时,你如何应付？
5.您认为做好测试测试用例工作的关键是什么？
6.比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。
7.需求测试注意事项有哪些？
8.简述一下缺陷的生命周期
9.什么是兼容性测试？兼容性测试侧重哪些方面？
10.测试的策略有哪些？
11.我现在有个程序，发现在windows上运行得很慢，怎么判别是程序存在问题还是软硬件系统存在问题？
12.正交表测试用例设计方法的特点是什么？
13.单元测试的策略有哪些？
14.你所熟悉的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……）？
15.软件的评审一般由哪些人参加？其目的是什么？
16.你认为做好测试计划工作的关键是什么？
17.软件的安全性应从哪几个方面去测试？
18.软件配置管理工作开展的情况和认识？
19.你觉得软件测试通过的标准应该是什么样的？
20.一套完整的测试应该由哪些阶段组成？
21.单元测试的主要内容？
22.简述集成测试与系统测试关系？
23.软件系统中除用户文档之外，文档测试还应该关注哪些文档？
24.如何理解压力、负载、性能测试测试？
25.什么是系统瓶颈？
26.配置和兼容性测试的区别是什么？
27.测试中的“杀虫剂怪事”是指什么？
28.在配置测试中，如何判断发现的缺陷是普通问题还是特定的配置问题？
29.软件测试的风险主要体现在哪里？
30.软件测试人员就是QA吗？
31.性能测试工作的目的是什么？做好性能测试工作的关键是什么？
31.性能测试工作的目的是什么？做好性能测试工作的关键是什么？
32.导致软件缺陷的有原因哪些？
33.什么是软件测试？软件测试的目的是什么？
34.什么是独立测试？独立测试的好处？
35.软件测试的生命周期？
36.软件测试活动流程。
37.软件系统的用户文档包括哪些？
38.简述软件系统中用户文档的测试要点？
39.软件测试的原则
1.测试结束标准是什么？
答：用例全部测试。
覆盖率达到标准。
缺陷率达到标准。
其他指标达到质量标准。
2.描述软件测试活动的生命周期？
答：测试周期分为计划、设计、实现、执行、总结。其中：
计划：对整个测试周期中所有活动进行规划，估计工作量、风险，安排人力物力资源，安排进度等；
设计：完成测试方案，从技术层面上对测试进行规划；
实现：进行测试用例和测试规程设计；
执行：根据前期完成的计划、方案、用例、规程等文档，执行测试用例。
总结：记录测试结果，进行测试分析，完成测试报告。
3.软件的缺陷等级应如何划分？
答：A类-严重错误，包括：①由于程序所引起的死机,非法退出
②死循环
③数据库发生死锁
④因错误操作导致的程序中断
⑤功能错误
⑥与数据库连接错误
⑦数据通讯错误
B类-较严重错误，包括：①程序错误
②程序接口错误
③数据库的表、业务规则、缺省值未加完整性等约束条件
C类-一般性错误，包括：①操作界面错误（包括数据窗口内列名定义、含义是否一致）
②打印内容、格式错误
③简单的输入限制未放在前台进行控制
④删除操作未给出提示
⑤数据库表中有过多的空字段
D类-较小错误，包括：①界面不规范
②辅助说明描述不清楚
③输入输出不规范
④长操作未给用户提示
⑤提示窗口文字未采用行业术语
⑥可输入区域和只读区域没有明显的区分标志
4.当开发人员说不是BUG时,你如何应付？
答：开发人员说不是bug，有2种情况，一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动，3方商量确定好后再看要不要改。二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是BUG的依据是什么？如果被用户发现或出了问题，会有什么不良结果？ 程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不 要修改就不改。其实有些真的不是bug，我也只是建议的方式写进TD中，如果开发人员不修改也没有大问题。如果确定是bug的话，一定要坚持自己的立场， 让问题得到最后的确认。
5.您认为做好测试测试用例工作的关键是什么？
答：白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果。
黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题。
6.比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。
答：黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。
白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。
软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序 的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误：
(1)是否有不正确或遗漏的功能？
(2)在接口上，输入是否能正确的接受？能否输出正确的结果？
(3)是否有数据结构错误或外部信息（例如数据文件）访问错误？
(4)性能上是否能够满足要求？
(5)是否有初始化或终止性错误？
软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计 或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测 试。白盒测试主要是想对程序模块进行如下检查：
(1)对程序模块的所有独立的执行路径至少测试一遍。
(2)对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。
(3)在循环的边界和运行的界限内执行循环体。
(4)测试内部数据结构的有效性，等等。
单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。
单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。
集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这 一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进 程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。
系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。（常见的联调测试）
系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。
验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。
验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。
7.需求测试注意事项有哪些？
答：一个良好的需求应当具有一下特点：
完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。
正确性：每一项需求都必须准确地陈述其要开发的功能。
一致性：一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。
无二义性：对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。
健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。
必要性：“必要性”可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如 Use Case 或别的来源。
可测试性：每项需求都能通过设计测试用例或其它的验证方法来进行测试。
可修改性：每项需求只应在 SRS 中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。
可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好（fine-grained）的方式编写并单独标明，而不是大段大段的叙述。
8.简述一下缺陷的生命周期
答：软件缺陷的生命周期指的是一个软件缺陷被发现、报告到这个缺陷被修复、验证直至最后关闭的完整过程。简单的软件缺陷生命周期：
(1)发现——打开：测试人员找到软件缺陷并将软件缺陷提交给开发人员；
(2)打开——修复：开发人员再现、修复缺陷，然后提交测试人员去验证；
(3)修复——关闭：测试人员验证修复过的软件，关闭已不存在的缺陷。
但是这是一种理想的状态，在实际的工作中是很难有这样的顺利的，需要考虑的各种情况都还是非常多的。
复杂的软件缺陷生命周期：
(1)新建一个软件缺陷，这个软件缺陷是（open）状态，进行 bug 审查，不是代码问题，就是设计需要修改；
(2)新建一个软件缺陷，这个软件缺陷是（open）状态，进行 bug 审查，以后修改的，就可以延期；
(3)新建一个软件缺陷，这个软件缺陷是（open）状态，进行 bug 审查，实际没有这个 bug，可以将其关闭；
(4)新建一个软件缺陷，这个软件缺陷是（open）状态，看是否清楚可重现，如果不能重现，就是缺少信息，需要返回到（open）状态；如果能够重现，就进行修正，修正后关闭，进行回归测试。
9.什么是兼容性测试？兼容性测试侧重哪些方面？
答：兼容测试主要是检查软件在不同的硬件平台、软件平台上是否可以正常的运行，即是通常说的软件的可移植性。
兼容的类型，如果细分的话，有平台的兼容，网络兼容，数据库兼容，以及数据格式的兼容。
兼容测试的重点是，对兼容环境的分析。通常，是在运行软件的环境不是很确定的情况下，才需要做兼容。根据软件运行的需要，或者根据需求文档，一般都能够得出用户会在什么环境下使用该软件，把这些环境整理成表单，就得出做兼容测试的兼容环境了。
兼容和配置测试的区别在于，做配置测试通常不是Clean OS下做测试，而兼容测试多是在Clean OS的环境下做的。
10.测试的策略有哪些？
答：黑盒/白盒，静态/动态，手工/自动，冒烟测试，回归测试，公测（Beta测试的策略）
11.我现在有个程序，发现在windows上运行得很慢，怎么判别是程序存在问题还是软硬件系统存在问题？
答：(1)检查系统是否有中毒的特征；
(2)检查软件/硬件的配置是否符合软件的推荐标准；
(3)确认当前的系统是否是独立，即没有对外提供什么消耗CPU资源的服务；
(4)如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的；
(5)在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况。
12.正交表测试用例设计方法的特点是什么？
答：用最少的实验覆盖最多的操作，测试用例设计很少，效率高，但是很复杂；
对于基本的验证功能，以及二次集成引起的缺陷，一般都能找出来；但是更深的缺陷，更复杂的缺陷，还是无能为力的；
具体的环境下，正交表一般都很难做的。大多数，只在系统测试的时候使用此方法。
13.单元测试的策略有哪些？
答：逻辑覆盖、循环覆盖、同行评审、桌前检查、代码走查、代码评审、景泰数据流分析
14.你所熟悉的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……）？
答：Compatibility Testing（兼容性测试），也称“Configuration testing（配置测试）”，测试软件是否和系统的其它与之交互的元素之间兼容，如：浏览器、操作系统、硬件等。验证测试对象在不同的软件和硬件配置中的运行情况。
Functional testing (功能测试)，也称为behavioral testing（行为测试），根据产品特征、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试，用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本，以保证目标用户的体验将足够好，就像应用程序是专门为该市场开发的一样。
Performance testing（性能测试），评价一个产品或组件与性能需求是否符合的测试。包括负载测试、强度测试、数据库容量测试、基准测试等类型。
其它参考：
测试类型有：功能测试、性能测试、界面测试。
功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。
界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。
区别在于，功能测试关注产品的所有功能上，要考虑到每个细节功能，每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注于用户体验上，用户使用该产品的时候是否易用，是否易懂，是否规范（快捷键之类的），是否美观（能否吸引用户的注意力），是否安全（尽量在前台避免用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告）？做某个性能测试的时候，首先它可能是个功能点，首先要保证它的功能是没问题的，然后再考虑该功能点的性能测试。
15.软件的评审一般由哪些人参加？其目的是什么？
答：在正式的会议上将软件项目的成果（包括各阶段的文档、产生的代码等）提交给用户、客户或有关部门人员对软件产品进行评审和批准。其目的是找出可能影响软件产品质量、开发过程、维护工作的适用性和环境方面的设计缺陷，并采取补救措施，以及找出在性能、安全性和经济方面的可能的改进。
人员：用户、客户或有关部门开发人员，测试人员，需求分析师都可以，就看处于评审那个阶段
16.你认为做好测试计划工作的关键是什么？
答：软件测试计划就是在软件测试工作正式实施之前明确测试的对象，并且通过对资源、时间、风险、测试范围和预算等方面的综合分析和规划，保证有效的实施软件测试；
做好测试计划工作的关键 ：目的，管理，规范
(1)明确测试的目标，增强测试计划的实用性
编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确
(2)坚持“5W”规则，明确内容与过程
“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。
(3)采用评审和更新机制，保证测试计划满足实际需求
测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。
(4)分别创建测试计划与测试详细规格、测试用例
应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。
17.软件的安全性应从哪几个方面去测试？
答：(1)用户认证机制：如数据证书、智能卡、双重认证、安全电子交易协议
(2)加密机制
(3)安全防护策略：如安全日志、***检测、隔离防护、漏洞扫描
(4)数据备份与恢复手段：存储设备、存储优化、存储保护、存储管理
(5)防病毒系统
18.软件配置管理工作开展的情况和认识？
答：软件配置管理贯穿于软件开发、测试活动的始终，覆盖了开发、测试活动的各个环节，它的重要作用之一就是要全面的管理保存各个配置项，监控各配置项的状态，并向项目经理及相关的人员报告，从而实现对软件过程的控制。
软件测试配置管理包括4个最基本的活动：
配置项标识
配置项控制
配置项状态报告
配置审计
软件配置管理通常借助工具来辅助，主要有MS SourceSafe、Rational ClearCase等
19.你觉得软件测试通过的标准应该是什么样的？
答：缺陷密度值达到客户的要求
20.一套完整的测试应该由哪些阶段组成？
答：测试计划、测试设计与开发、测试实施、测试评审与测试结论
21.单元测试的主要内容？
答：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试
22.简述集成测试与系统测试关系？
答：（1）集成测试的主要依据概要设计说明书，系统测试的主要依据是需求设计说明书；
（2）集成测试是系统模块的测试，系统测试是对整个系统的测试，包括相关的软硬件平台、网络以及相关外设的测试。
23.软件系统中除用户文档之外，文档测试还应该关注哪些文档？
答：⑴开发文档
⑵软件需求说明书
数据库设计说明书、概要设计说明书、详细设计说明书、可行性 研究报告
⑶管理文档
项目开发计划、测试计划、测试报告、开发进度月报、开发总结报告
24.如何理解压力、负载、性能测试测试？
答：性能测试是一个较大的范围，实际上性能测试本身包含了性能、强度、压力、负载等多方面的测试内容。
压力测试是对服务器的稳定性以及负载能力等方面的测试，是一种很平常的测试。增大访问系统的用户数量、或者几个用户进行大数据量操作都是压力测试。而负载测试是压力相对较大的测试，主要是测试系统在一种或者集中极限条件下的相应能力，是性能测试的重要部分。100个用户对系统进行连续半个小时的访问可以看作压力测试，那么连续访问8个小时就可以认为负载测试，1000个用户连续访问系统1个小时也可以看作是负载测试。
实际上压力测试和负载测试没有明显的区分。测试人员应该站在关注整体性能的高度上来对系统进行测试。
25.什么是系统瓶颈？
答：瓶颈主要是指整个软硬件构成的软件系统某一方面或者几个方面能力不能满足用户的特定业务要求，“特定”是指瓶颈会在某些条件下会出现，因为毕竟大多数系统在投入前。
严格的从技术角度讲，所有的系统都会有瓶颈，因为大多数系统的资源配置不是协调的，例如CPU使用率刚好达到100％时，内存也正好耗尽的系统不是很多见。因此我们讨论系统瓶颈要从应用的角度讨论：关键是看系统能否满足用户需求。在用户极限使用系统的情况下，系统的响应仍然正常，我们可以认为改系统没有瓶颈或者瓶颈不会影响用户工作。
因此我们测试系统瓶颈主要是实现下面两个目的：
-发现“表面”的瓶颈。主要是模拟用户的操作，找出用户极限使用系统时的瓶颈，然后解决瓶颈，这是性能测试的基本目标。
-发现潜在的瓶颈并解决，保证系统的长期稳定性。主要是考虑用户在将来扩展系统或者业务发生变化时，系统能够适应变化。满足用户目前需求的系统不是最好的，我们设计系统的目标是在保证系统整个软件生命周期能够不断适应用户的变化，或者通过简单扩展系统就可以适应新的变化。
26.配置和兼容性测试的区别是什么？
答：配置测试的目的是保证软件在其相关的硬件上能够正常运行，而兼容性测试主要是测试软件能否与不同的软件正确协作。
配置测试的核心内容就是使用各种硬件来测试软件的运行情况，一般包括：
（1）软件在不同的主机上的运行情况，例如Dell和Apple；
（2）软件在不同的组件上的运行情况，例如开发的拨号程序要测试在不同厂商生产的Modem上的运行情况；
（3）不同的外设；
（4）不同的接口；
（5）不同的可选项，例如不同的内存大小；
兼容性测试的核心内容：
（1）测试软件是否能在不同的操作系统平台上兼容；
（2）测试软件是否能在同一操作系统平台的不同版本上兼容；
（3）软件本身能否向前或者向后兼容；
（4）测试软件能否与其它相关的软件兼容；
（5）数据兼容性测试，主要是指数据能否共享；
配置和兼容性测试通称对开发系统类软件比较重要，例如驱动程序、操作系统、数据库管理系统等。具体进行时仍然按照测试用例来执行。
27.测试中的“杀虫剂怪事”是指什么？
答：“杀虫剂怪事”一词由BorisBeizer在其编著的《软件测试技术》第二版中提出。用于描述测试人员对同一测试对象进行的测试次数越多，发现的缺陷就会越来越少的现象。就像老用一种农药，害虫就会有免疫力，农药发挥不了效力。这种现象的根本原因就是测试人员对测试软件过于熟悉，形成思维定势。
为了克服这种现象，测试人员需要不断编写新的测试程序或者测试用例，对程序的不同部分进行测试，以发现更多的缺陷。也可以引用新人来测试软件，刚刚进来的新手往往能发现一些意想不到的问题。
28.在配置测试中，如何判断发现的缺陷是普通问题还是特定的配置问题？
答：在进行配置测试时，测试工程师仍然会发现一些普通的缺陷，也就是与配置环境无关的缺陷。因此判断新发现的问题，需要在不同的配置中重新执行发现软件缺陷的步骤，如果软件缺陷不出现了，就可能是配置缺陷；如果在所有的配置中都出现，就可能是普通缺陷。
需要注意的是，配置问题可以在一大类配置中出现。例如，拨号程序可能在所有的外置Modem中都存在问题，而内置的Modem不会有任何问题。
29.软件测试的风险主要体现在哪里？
答：我们没有对软件进行完全测试，实际就是选择了风险，因为缺陷极有可能存在没有进行测试的部分。举个例子，程序员为了方便，在调试程序时会弹出一些提示信息框，而这些提示只在某种条件下会弹出，碰巧程序发布前这些代码中的一些没有被注释掉。在测试时测试工程师又没有对其进行测试。如果客户碰到它，这将是代价昂贵的缺陷，因为交付后才被客户发现。
因此，我们要尽可能的选择最合适的测试量，把风险降低到最小。
30.软件测试人员就是QA吗？
答：软件测试人员和QA完全不是一回事儿。
QA(Quality Assurance),即质量保证,包括各行业，如制造业、工业、船舶业等，在业务各个领域都设有QA部门来监管项目/产品，注意，只是在流程上进行管理、控制。
SQA(Software Quality Assurance)，特指软件行业上的质量保证，是对软件开发测试过程中的各环节质量进行管理，看看符不符合公司的规程。其中不单有业务流程上的，也有产品/项目具体质量目标上的。
软件测试是对软件产品的质量本身进行测试，是从技术方面出发测试软件。
SQA偏重于质量管理体系的建立和维护，客户和认证机构质量体系审核工作，质量培训工作等。
为了更形象地表述两者区别，必须引入开发人员角色，形成三足鼎立之局面。
举个例子：
假设软件产品交付过程等同与学生考试的过程，那么在这个过程中：
①开发人员是做考卷的学生。
②测试人员是改考卷的老师。
③QA（SQA）人员是辅导员。
软件产品是开发人员做出来的，产品是否可以在市场使用，考试是否及格，决定性的因素还是在开发。
开发人员提交了结果，学生做完了试卷，是否及格？需要测试人员进行测试的分析与判断。辅导员对具体课程不必具有特别多的专业知识，但是他会要求开发人员要先复习，然后做模拟题，最后才参加考试。他只监督你是否复习过，这就够了。因为他知道，不复习直接考试，基本上就是不及格的命。复习了，总比不复习好。而对于测试人员，他也许不懂如何做题-。-，但知道最终答案术（如执行用例者），只要有标准答案，就可以评定答案是否正确，满足预期要求（软件需求）。
所以说，软件测试与开发一样，是一个单纯的技术活，只是个结果控制。
QA不涉及具体的技术，其实是个过程改进控制过程，是对整个过程的监督和改进，保证所有的标准和程序都被遵守，并且发现和处理相关问题。QA的工作涉及公司的全局，各个相关职能，覆盖面比较宽广，是保证生产过程受控或保证产品合格，着重于维护。
31.性能测试工作的目的是什么？做好性能测试工作的关键是什么？
答：性能测试工作的目的：在正常和大量使用的状况下，验证被测系统是否按预期要求运行。
达到这个目的，需要做可扩展性测试、负载测试、压力测试等。
性能测试工作的关键：
①清晰的测试计划
②文档的测试环境(测试系统的实验环境)
③有效的测试用例
④合理的场景分析
⑤准确的瓶颈定位
⑥测试人员对性能测试的理解程度、对测试工具的熟练程度
32.导致软件缺陷的有原因哪些？
答：给软件带来错误的原因很多，具体地说，主要有如下几点：
①交流不够、交流上有误解或者根本不进行交流
在应用应该做什么或不应该做什么的细节(应用的需求)不清晰的情况下进行开发。
②软件复杂性
图形用户界面(gui)，客户/服务器结构，分布式应用，数据通信，超大型关系型数据库以及庞大的系统规模，使得软件及系统的复杂性呈指数增长，没有现代软件开发经验的人很难理解它。
③程序设计错误
向所有的人一样，程序员也会出错。
④需求变化
需求变化的影响是多方面的，客户可能不了解需求变化带来的影响，也可能知道但又不得不那么做。需求变化的后果可能是造成系统的重新设计，设计人员的日程的重新安排，已经完成的工作可能要重做或者完全抛弃，对其他项目产生影响，硬件需求可能要因此改变，等等。如果有许多小的改变或者一次大的变化，项目各部分之间已知或未知的依赖性可能会相互影响而导致更多问题的出现，需求改变带来的复杂性可能导致错误，还可能影响工程参与者的积极性。
⑤时间压力
软件项目的日程表很难做到准确，很多时候需要预计和猜测。当最终期限迫近和关键时刻到来之际，错误也就跟着来了。
⑥自负
人更喜欢说:'没问题','这事情很容易','几个小时我就能拿出来'，太多不切实际的‘没问题’，结果只能是引入错误。
⑦代码文档贫乏
贫乏或者差劲的文档使得代码维护和修改变的异常艰辛，其结果是带来许多错误。事实上，在许多机构并不鼓励其程序员为代码编写文档，也不鼓励程序员将代码写得清晰和容易理解，相反他们认为少写文档可以更快的进行编码，无法理解的代码更易于工作的保密(“写得艰难必定读的痛苦”)。
⑧软件开发工具
可视化工具，类库，编译器，脚本工具，等等，它们常常会将自身的错误逮到应用软件中。就象我们所知道的，没有良好的工程化作为基础，使用面向对象的技术只会使项目变得更复杂。
33.什么是软件测试？软件测试的目的是什么？
答：软件测试：在一定的受控制的条件下，围绕一个系统或应用程序进行并评价操作结果的过程。控制条件应包括正常条件与异常条件。软件测试企图使事情变得很糟糕，从而发现该发生而没发生，或者不该发生而发生了的事情。软件测试是以“探测”为主，在“探测”中发现软件的毛病。软件测试贯穿于软件定义与开发的整个周期 ，软件的需求规格说明书 ，结构设计及程序编码，都属于软件测试的对象。
软件测试的目的是为了保证软件产品的最终质量，在软件开发的过程中，对软件产品进行质量控制。一般来说软件测试应由独立的产品评测中心负责，严格按照软件测试流程，制定测试计划、测试方案、测试规范，实施测试，对测试记录进行分析，并根据回归测试情况撰写测试报告。测试是为了证明程序有错，而不能保证程序没有错误。
①软件测试是为了发现错误而执行程序的过程；
②测试是为了证明程序有错，而不是证明程序无错误；
③一个好的测试用例是在于它能发现至今未发现的错误；
④一个成功的测试是发现了至今未发现的错误的测试。
这种观点可以提醒人们测试要以查找错误为中心，而不是为了演示软件的正确功能。但是仅凭字面意思理解这一观点可能会产生误导，认为发现错误是软件测试的唯一目，查找不出错误的测试就是没有价值的，事实并非如此。
首先，测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的分布特征，可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。同时，这种分析也能帮助我们设计出有针对性地检测方法，改善测试的有效性。
其次，没有发现错误的测试也是有价值的，完整的测试是评定测试质量的一种方法。详细而严谨的可靠性增长模型可以证明这一点。例如 bev littlewood发现一个经过测试而正常运行了n小时的系统有继续正常运行n小时的概率。
34.什么是独立测试？独立测试的好处？
答：独立测试：软件测试由在经济上和管理上独立于开发机构的组织进行。独立测试可以避免软件开发者测试自己开发的软件，由于心理学上的问题，软件开发者难以客观、有效地测试自己的软件，而找出那些因为对问题的误解而产生的错误就更加困难。独立测试还可以避免软件开发机构测试自己的软件，软件产品的开发过程受到时间、成本和质量三者的制约，时间和成本指标便于衡量，而质量却很难度量，因此在软件开发过程中，当时间、成本和质量三者发生矛盾时，质量最容易被忽视，如果测试组织与开发组织来自相同的机构，测试过程就会面临来自与开发组织同一来源的管理方面的压力，使测试过程受到干扰。
独立测试的好处：
①客观性
对软件测试和软件中的错误抱着客观的态度，这种客观的态度可以解决测试中的心理学问题，既能够以揭露软件中错误的态度工作，也能不受发现的错误的影响。经济上的独立性使其工作有更充分的条件按测试要求去完成。
②专业性
独立测试作为一种专业工作，在长期的工作过程中势必能够积累大量实践经验，形成自己的专业优势。同时软件测试也是技术含量很高的工作，需要有专业队伍加以研究，并进行工程实践。专业化分工是提高测试水平，保证测试质量，充分发挥测试效用的必然途径。
③权威性
由于专业优势，独立测试工作形成的测试结果更具信服力，而测试结果常常和对软件的质量评价联系在一起，由专业化的独立测试机构的评价，更客观、公正和具有权威性。
④资源有保证
独立测试机构的主要任务是进行独立测试工作，这使得测试工作在经费、人力和计划方面更有保证，不会因为开发的压力减少对测试的投入，降低测试的有效性，可以避免开发单位侧重软件开发而对测试工作产生不利的影响。
35.软件测试的生命周期？
答：计划、分析、设计、构建、测试周期、最后测试和实施、实施后。
36.软件测试活动流程。
答：指定测试计划、设计测试、实施测试、执行单元测试、执行集成测试、执行系统测试、评估测试。
37.软件系统的用户文档包括哪些？
答：软件测试的文档测试应当贯穿于软件生命周期的全过程，其中用户文档是文档测试的重点。
用户手册
安装和设置指导
联机帮助
指南、向导
样例、示例和模板
授权/注册登记表
最终用户许可协议。
38.简述软件系统中用户文档的测试要点？
答：(1)读者群。文档面向的读者定位要明确，对于初级用户、中级用户以及高级用户应该有不同的定位。
(2)术语。文档中用到的术语要适用与定位的读者群，用法一直，标准定义与业界规范相吻合。
(3)正确性。测试中需检查所有信息是否真实正确，查找由于过期产品说明书和销售人员夸大事实而导致的错误。检查所有的目录、索引和章节引用是否已更新，尝试链接是否准确，产品支持电话、地址和邮政编码是否正确。
(4)完整性。对照软件界面检查是否有重要的分支没有描述到，甚至是否有整个大模块没有描述到。
(5)一致性。对照文档描述的操作执行后，检查软件返回的结果是否与文档描述的相同。
(6)易用性。对关键步骤以粗体或背景色给用户以提示，合理的页面布局、适量的图表都可以给用户更高的易用性。需要注意的是文档要有助于用户排除错误。不但描述正确操作，也要描述错误处理办法。文档对于用户看到的错误信息应该有更详细的文档解释。
(7)图标与界面截图。检查所有图表与界面截图是否与发行版本相同。
(8)样例与示例。像用户一样载入和使用样例。如果是一段程序，就输入数据并执行它。以每一个模块制作文件，确认它们的正确性。
(9)语言。不出现错别字，不要出现有二义性的说法。特别要注意的是屏幕截图或绘制图形中的文字。
(10)印刷与包装。检查印刷质量；手册厚度与开本是否合适；包装盒的大小是否合适；有没有零碎易丢失的小部件等等。
39.软件测试的原则
答：软件测试从不同的角度出发会派生出两种不同的测试原则，从用户的角度出发，就是希望通过软件测试能充分暴露软件中存在的问题和缺陷，从而考虑是否可以接受该产品，从开发者的角度出发，就是希望测试能表明软件产品不存在错误，已经正确地实现了用户的需求，确立人们对软件质量的信心。中国软件评测中心的测试原则就是从用户和开发者的角度出发进行软件产品测试的，通过我们的测试，可以为用户提供放心的产品，并对优秀的产品进行认证。
为了达到上述的原则，那么需要注意以下几点：
①应当把“尽早和不断的测试”作为开发者的座右铭
②程序员应该避免检查自己的程序，测试工作应该由独立的专业的软件测试机构来完成。
③设计测试用例时应该考虑到合法的输入和不合法的输入以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。
④一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。
⑤对测试错误结果一定要有一个确认的过程，一般由A测试出来的错误，一定要由一个B来确认，严重的错误可以召开评审会进行讨论和分析。
⑥制定严格的测试计划，并把测试时间安排的尽量宽松，不要希望在极短的时间内完成一个高水平的测试。
⑦回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多的错误出现的现象并不少见。
⑧妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。
在软件测试中如何配置软件环境配备测试环境是测试实施的一个重要阶段，测试环境适合与否会严重影响测试结果的真实性和正确性。测试环境包括硬件环境和软件环境，硬件环境指测试必需的服务器、客户端、网络连接设备以及打印机/扫描仪等辅助硬件设备所构成的环境 ；软件环境指被测软件运行时的操作系统、数据库以及其他应用软件构成的环境。在实际测试中，软件环境又可分为主测试环境和辅测试环境，主测试环境是测试软件功能、安全可靠性、性能、易用性等大多数指标的主要环境，一般来说，配置主测试环境可遵循下列原则：
①符合软件运行的最低要求。测试环境首先要保证能支撑软件正常运行。
②选用比较普遍的操作系统和软件平台。例如，一个软件若声称支持“Windows9X/ME/NT Workstation/2000 professional”和“MS OFFICE 97/2000/XP”，一般我们会采用如“Windows 2000professional+MS OFFICE 2000”的流行环境。
③营造相对简单、独立的测试环境。除了操作系统，测试机上只安装软件运行和测试必需的软件，以免不相关的软件影响测试实施。
④无毒的环境。利用有效的正版杀毒软件检测软件环境，保证测试环境中没有病毒。
辅测试环境常常用来满足不同的测试需求或特殊测试项目：
兼容性测试：在满足软件运行要求的范围内，可选择一些典型的操作系统和常用应用软件对其安装卸载和主要功能进行验证。
模拟真实环境测试：有些软件，特别是面向大众的商品化软件，在测试时常常需要考察在真实环境中的表现。如测试杀毒软件的扫描速度时，硬盘上布置的不同类型文件的比例要尽量接近真实环境，这样测试出来的数据才有实际意义。
横向对比测试：利用辅测试环境“克隆”出完全一致的测试环境，从而保证各个被测软件平等对比。