一、软件质量保证和软件测试的区别
软件质量保证（Software Quality Assurance）:SQA介入于整个软件开发过程——监督和 改进过程，确认达成的标准和过程被正确的遵循，保证问题被发现和解决。它以预防 为主。 软件测试（Software Testing）:软件测试是在一定控制的条件下，围绕一个系统或应用 的操作并且评价其结果（一个最简单的例子：如果用户使用硬件A，在应用接口B上做 了操作C，那么结果D应当出现），控制的条件应当包括正常和异常的条件。测试企图 使事情变得很糟糕，从而来检测出一些应当发生而没有发生，或者不应当发生而发生 的事情。测试以检测为主。 *关于如何安排QA和测试的任务时，不同的组织变化是很大的。有时它们可以有一个 组或个人来负责，共同的是一个项目组混合了测试人员和开发人员，并且他们一起紧 密的工作，而QA过程有项目经理来监督。所有这些是同组织的大小和商业结构有关 的。
二、软件中存在错误的来源
1、缺乏或者没有进行沟通，如对于一些我们应用程序中应当或者不应当实现的细节问 题。 2、软件复杂度——在当今的软件开发中，对于一些没有经验的人来说，软件复杂性 可能是难以理解的。图形化界面，客户/服务器和分布式的应用，数据通信，大规模的 关系数据库，应用程序的规模等指数般的增加了软件的复杂度。面向对象技术也有可 能增加软件复杂度，除非能够被很好的工程化。 3、编程错误——任何一个编程人员都可能产生错误。 4、不断变更的需求——用户可能不知道变更的影响，或者知道影响却还是需要进行 变更，这些会引起重新设计，工程的重新安排，对其它项目的影响，已完成的工作可 能不得不重做或推翻，硬件需求可能也会受到影响。如果存在许多小的变更或者任何 大的改动，由于项目中不同部分间可知和不可知的依赖关系，这样就会产生问题，跟 踪变更的复杂性也可能引入错误。项目开发人员的积极性也会受到打击。在一些快速 变化的商业环境下，不断变更的需求可能是一种残酷的事实。在这种情况下，管理人 员必须了解结果的风险，QA工程师和测试工程师必须适应和计划进行大规模的测试来 防止不可避免的BUG出现无法控制的局面。 5、时间的压力——软件项目的时间安排是最难的，通常是需要很多猜测的工作。当最 后期限来临的时候，错误也就伴随发生了。 6、人员的自大——我们经常会发现人们普遍喜欢说： “没问题” “很简单” “我可以在几小时内解决那个问题” “修改那些老代码应当是很简单的” 而不是说： “那会增加很多复杂性，可能会导致很多错误” “如果我们要做那个的话，我们将无能为力” “我无法估计可能要多长时间，除非我能进一步进行观察和研究” “我们无法搞清楚那些混乱的代码到底在做什么事情” 如果存在太多的“没问题”的话，问题也就产生了。 7、缺乏文档的代码——维护和修改很差的代码或缺乏文档的代码是很困难的。最终 结果将导致BUG的出现。 8、软件开发工具——视图工具，类库，编译器，脚本工具等等通常会把它们自身的 BUG 引入到你的项目中。
三、测试分类
1、黑盒测试——不是基于内部代码和设计的知识，而是基于需求和功能。 2、白盒测试——基于应用程序的内部逻辑的知识，通过语句，分支，路径和条件的 覆盖率。 3、单元测试——测试中的最小单位，测试特殊的功能或代码模块。由于需要对内部 代码和设计的详细知识，该测试一般由开发者完成而不是由测试人员完成。该测试的 容易程度同代码设计的好坏直接相关。 4、增量型的集成测试——随着新功能的增加，不断的对应用程序进行测试。在程序 的所有部分完成之前，需要一个应用程序的各个部分之间能够相对独立的进行工作。 这类型测试可以有开发者或测试者完成 5、集成测试——测试应用程序结合的部分来确定它们的功能结合到一起是正确的。 在这里‘部分’的概念可能是代码模块，独立的应用程序，在网络上的客户端和服务 器断程序等等。这类型测试典型的是于客户/服务器和分布式系统相关。 6、功能测试——是一种黑盒测试，同应用程序的功能需求紧密相关。这类型测试应 当有测试人员来完成。这并不意味着开发人员在发布版本之前就不需要检查他们的代 码。 7、端到端测试——同系统测试类似，包括模拟现实世界对一个完整的应用环境进行 测试。例如同数据库进行交互、使用网络通信，或者其他的软件、硬件和系统进行交 互。 8、理智测试——这是一种典型的原始测试，其目的是要确定一个新的软件版本在一 些主要的测试努力下表现的足够好并且可以接受。例如：如果一个新软件每五分钟当 机一次，使系统执行速度极其缓慢，或者破坏系统数据，那么该软件就处于不够‘理 智’状态，必须保证在当前状态下进行进一步测试。 9、回归测试——在软件或环境被修改后进行的再测试。可能很难确定我们需要进行 多少的再测试，尤其接近到开发过程的末期。自动测试工具可能会有很大的帮助。 10、可接受性测试——基于最终用户的规格进行的最后测试。或者基于最终用户在一 定的时间范围内的测试。 11、负荷测试——在高负荷条件下进行的测试。 12、压力测试——该术语通常同负荷测试和性能测试是可交换的。也可用于描述这样 一些测试 如：在不正常的负荷状态下，过分的重复某些动作或输入情况下进行的系统功能测试 13、性能测试——该术语通常同负荷测试和压力测试是可交换的。理想的性能测试是 定义在需求文档或QA测试计划中的。 14、安装和反安装测试——测试完全、部分或升级的安装/反安装过程 15、恢复测试——测试当出现崩溃，硬件错误或其他灾难性问题时，系统的表现情况 16、安全性测试——测试系统对于内部和外部非法入侵、故意损坏时的表现情况。可 能需要复杂的测试技术。 17、兼容性测试——测试系统在不同的平台/硬件/操作系统/网络上的表现情况。 18、ALPHA测试——在开发进行结束的时候进行的测试。针对测试的结果可能还会进 行一些小的设计更改。这类测试典型的是由用户进行的，而不是由开发者或测试人员 进行的。 19、BETA测试——在开发和测试已经全部结束后，并且在最终版本发布之前进行的 测试。这类测试典型的是由用户进行的，而不是由开发者或测试人员进行的。
四、开发和执行软件测试需要哪些步骤
1、获取需求、功能设计、详细设计规格和其它必须文档 2、获取预算和时间安排需求 3、确定项目相关人员和他们的责任，汇报需求，必须的标准和过程（如版本过 程、变更过程等） 4、确认应用高风险的部分，设定优先级，确定测试的范围和限制 5、确定测试的方法——单元测试、集成测试、功能测试、负荷测试、可用性测 试等 6、确定环境需求（软件/硬件/通信等） 7、确定测试用具环境（记录/回放工具、覆盖率分析器、测试跟踪、问题跟踪等 等） 8、确定测试输入需求 9、确定任务，任务责任和相应的工作量 10、设定时间安排估计、时间表、里程碑等 11、确定输入的等价类、边界值分析、错误类 12、准备测试计划文档和需要的评审 13、写测试用例 14、对测试用例进行必须的评审 15、准备测试环境和测试用具，获取需要的用户手册/参考文档/配置指导/安装 指导，建立跟踪过程，日志和存档过程，获取测试数据 16、获取和安装软件版本 17、执行测试 18、评价和汇报测试结果 19、跟踪问题和修改 20、如果需要进行再测试 21、在整个生命周期内维护和修改测试计划、测试用例、测试环境和测试用具
五、什么是测试计划
测试计划是描述软件测试努力的目标、范围、方法和焦点的文档。准备测试计 划的过程是完整考虑软件产品可接受评价努力的一个有用的方法。完整的文档 将有助于测试组之外的人理解为什么要进行软件正确性检测，并且如何进行检 测。测试计划应当足够完整但也不应当太详尽，以致在测试组之外没有人会读 它。下面是一些可能会包含在测试计划中的一些内容，依赖于特定的项目： 1、标题 2、确定软件的版本号 3、修订文档历史，包括作者、日期和批示 4、目录表 5、文档的目的和适合的读者群 6、测试的目的 7、软件产品概述 8、相关文档列表，例如：需求、设计文档、其他测试计划等 9、相关的标准或合法需求 10、可跟踪性需求 11、相关的命名规范和标识符规范 12、整个软件项目组织和人员/联系信息/责任 13、测试组织和人员/联系信息/责任 14、假设和依赖关系 15、项目风险信息 16、测试优先级和焦点 17、测试范围和限制 19、测试提纲——对测试过程的一个分解，通过测试类型、特点、功能性、过 程、系统、模块等 20、测试环境设置和配置问题 21、数据库设置需求 22、概述系统日志/错误日志/其他性能，有助于描述和汇报问题的屏幕捕获工具 等 23、有助于测试者跟踪问题根源的具体软硬件工具的论述 24、测试自动化的可能性和概述 25、使用的测试工具，包括版本、补丁等 26、使用的项目测试度量 27、报告需求和测试可传递性 28、软件入口和出口准则 29、初始的理性测试阶段和标准 30、测试终止和重新开始的标准 31、人员安排 32、测试地点 33、用到的测试外的组织，他们的目的、责任、可传递性、联系人和协作问题 34、相关的财产、分类、安全性和许可证问题 35、公开的一些问题 36、附录——词汇表、缩略语等
六、什么是测试用例
1、一个测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目 的是确定应用程序的某个特性是否正常的工作。一个测试用例应当有完整的信息， 如：测试用例ID号，测试用例名字，测试用例的目的，测试条件、输入数据需求、步 骤和期望结果。 2、注意开发测试用例的过程有助于在应用的需求和设计中发现问题。这主要是由于是 需要完整的考虑应用的整个操作。正因为这样，需要在开发的早期准备测试用例。
七、制定测试计划应该考虑哪些因素
应明确的在测试计划中确立好"测试管理机制"的关键事件,如: 1>.汇报机制确定好用周报制度还是日报制度，日报的反馈速度快，定位解决问 题快,但信息处理工作量大; 2>.例会制度,每周举行一次例会，根据实际情况，考虑测试计划的调整或滚动; 3>.实施怎样的实验室管理制度，以做到责任明确; 4>.在日报中的工作汇报：不仅是发现的问题，还应包括在测试时新创造的测试 点，这些测试点应该补充到测试计划中作为一个测试项 5>.人员情绪如何调整，在测试周期过长时，影响测试效率的一个重要因素是测 试人员的情绪，一个人反复测试一个模块，总是会出现厌倦情绪的。具体怎么调整？ 是一个有待讨论的问题。 应明确的在测试计划中确立"数据"的管理和分析体系和办法,如: 专人对提交的过程文档,周报报告中的数据予以整理和管理，以便后期在系统测 试评审时作为数据来分析。 现在往往是在系统测试结束后才来收集数据，可能会造成数据的不同程度失真或滞 后。收集的数据可以按不同种类来划分。这可以依赖我们系统CHECKLIST。有一种工 具叫 SRES (软件可靠性专家系统) 还是很有用的，我们可以按照它的输入数据来收 集。 应明确的在测试计划中确立"风险估计"的引入,如: 制定测试计划时,就应该考虑好对系统测试工作量的估计，测试成本的估计,版本 市场定位的估计等等,并且必要时可根据实际情况进行裁剪或补充