测试计划

也就是你安装的是个测试软件，没有在App Store上架的app，你还想用及只能通过testflight下载安装测试用，当有了新版本上架后，你这个测试版本就没用了，就会被开发者移除，你只要去App Store上更新最新版本即可，祝你好运！

正确答案应该是B

测试计划1 .引言 1．1　编写目的　　　　在开发大型软件的漫长过程中，面对极其错综复杂的问题，人的主观认识不可能完全符合客观现实，与工程密切相关的各类人员之间的通信和配合也不可能完美无缺。因此，在软件生命周期的每个阶段都不可避免地会产生差错。尤其对于机票预订系统这类会影响人们生活．财产的工程软件，必须尽量减少差错，以免造成严重的损失。测试是“为了发现程序中的错误而执行程序的过程”。测试的目的就是在软件投入生产性运行之前，尽可能多的发现软件中的错误。目前软件测试仍然是保证软件质量的关键步骤，它是对软件规格说明．设计和编码的最后复审，也是必不可少的关键步骤。1．2 项目背景本项目 公司委托，由<>软件开发小组负责开发。 1．3 定义　　　　　SQL SERVER: 系统服务器所使用的数据库管理系统（DBMS）。SQL: 一种用于访问查询数据库的语言事务流：数据进入模块后可能有多种路径进行处理。主键：数据库表中的关键域。值互不相同。外部主键：数据库表中与其他表主键关联的域。ROLLBACK: 数据库的错误恢复机制。　 1 . 4参考资料软件工程及其应用 周苏、王文等 天津科学技术出版社 1992/1　　 软件工程 张海藩 清华大学出版社 1990/11 项目的计划任务书　　　　　　《》软件开发小组　 1999/6/1 　　　　　　　　项目开发计划 《》软件开发小组 1999/6/1需求规格说明书 《》软件开发小组　　 1999/6/1　　概要设计说明书　　　 　　　 《》软件开发小组　　 1999/6/1 详细设计说明书　　　　　　　《》软件开发小组 1999/6/1用户操作手册　　　　　　　 《》软件开发小组 1999/6/12 . 任务概述2 . 1 目标 测试是“为了发现程序中的错误而执行程序的过程”, 测试的目的就是在软件投入生产性运行之前，尽可能多的发现软件中的错误。2 . 2 运行环境 由于系统将由两部分程序组成，安装在各旅行社客户机上的客户程序及航空公司内的数据服务器程序。 1．服务器端子系统的运行要求： 系统软件： Window NT Server 数据库管理系统：SQL Server 硬件要求：Pentium II 450以上, 1024M RAM, 36G HD2. 客户端子系统的运行要求： 系统软件： Window NT Workstation 数据库管理系统：SQL Server 硬件要求：Pentium 133以上, 32M RAM, 2.1G HD2. 3 需求概述 要求系统能有效、快速、安全、可靠和无误的完成上述操作。并要求客户机的 界面要单明了，易于操作，服务器程序利于维护。2 . 4 条件与限制 　　　必须在保证各硬件设备．软件系统齐备的情况下，资金充足，人员齐备，　　　各方面互相配合，齐心协力，共同完成。3 . 计划 3 . 1 测试方案 测试方案是测试阶段的关键技术问题。为了提高测试效率降低测试成本，本测 试方案采用黑盒法设计基本的测试方案，再用白盒法补充一些方案。在黑盒法测试 方案中，采用等价划分技术，把所有可能的输入数据（有效的和无效的）划分成几 等价类，其划分类在以下的输入中再详述。 3 . 2 测试项目 客户机接受信息模块测试 客户机输出信息模块测试 网络接受和发送模块结构测试 服务器模块（包括数据库）测试 各模块之间的接口测试 系统测试 3 . 3 测试准备 在测试前，与各模块的主要负责人共同协商讨论，以概要设计说明书.详细设 计说明书作为总的提纲,选择合适的输入输出数据,并加以意义列举说明。 3 . 4 测试机构及人员 测试机构由 ZJU工作组组成，人员有《》软件开发小组全体人员。　 4 . 测试项目说明 4 . 1 测试项目名称及测试内容 在测试过程中，首先需要对各子单元过程进行测试。在各子单元过程测试完毕后，再对各模块（包括各子单元过程之间的接口）进行测试，处理好各模块之间的接口，最后对系统进行测试和维护。各子模块测试名称如下： 客户机接受信息模块测试 客户机输出信息模块测试 网络接受和发送模块结构测试 服务器模块（包括数据库）测试 各模块之间的接口测试 系统测试4 . 2 测试用列 4 . 2 . 1 输入 4 . 2 . 2 输出 4 . 2 . 3 步骤及操作 在测试过程中，首先需要对各子单元过程进行测试。各子单元过程的测试必须先在程序设计员调试并编译通过后才能进行。在各子单元过程测试完毕后，再对各模块（包括各子单元过程之间的接口）进行测试，处理好各模块之间的接口，最后对系统进行测试和维护。 其操作过程如下：1． 在客户机接受信息模块过程中，先对各子单元过程分别进行测试，然后根据白盒法按照详细设计说明书中的流程图对其进行跟踪测试。2． 同样，在客户机输出信息模块．网络接受和发送模块结构和服务器模块（包括数据库）过程中先对各子单元过程分别进行测试，然后根据白盒法按照详细设计说明书中的流程图对其进行跟踪测试。，　　　　　　３．然后，根据各模块之间的各种关系，对其接口进行测试。　　　　　　４．在系统测试中，要注意对各种意外情况（列如断电．硬盘损坏等）加以　　　　　　　　处理，对数据库要注意其安全性．可靠性．健壮性．效率。网络传输更 要注意其安全性。 4 . 2 . 4 允许偏差 4 . 3 进度　　　　　由于其测试过程较长，需要对各子单元程序．各模块及它们之间的接口分　　　别进行测试进度．一般测试过程都伴随其概要设计．详细设计过程一起进行，　　　进度在１８个月左右。 4 . 4 条件　　　　　必须在保证各硬件设备．软件系统齐备的情况下，资金充足，人员齐备，　　　各方面互相配合，齐心协力，共同完成。　　 4 . 5 测试资料测试资料主要是《》软件开发小组的各类文档及浙江航空公司公司提供的各类资料档案。5 .评介 5 . １　 准则　　首先，我们要认识到测试是软件开发过程中一个非常重要的环节，一各好的软件必须经过无数次的测试。软件测试是保证软件质量的关键步骤。所以在测试过程中必须抱着不骄不躁．谦虚谨慎的态度，把好关！

如果你是应聘测试相关工作，这个应该是你的本行，第一步准备测试工作，有哪些PROCESS，第一步就不会吗？虽然本人并不是测试专业，但是这类型的答案无外乎以下两种方式：1，5W1H法，谁（由谁测试，个人及小组分工），哪里（测试地点），哪一个（具体分类），对象是什么（测试对象），什么时间（测试时间）以及怎样（测试流程准备）2，人机料法环：什么人测试，测试设备工具，用哪些材料准备，测试方法论和流程及及测试环境等注意事项

面试用的话没必要说的那么复杂、大概就这么些意思:1、测试的目的是为了发现尽可能多的缺陷，不是为了说明软件中没有缺陷。2、成功的测试在于发现了迄今尚未发现的缺陷。所以测试人员的职责是设计这样的测试用例，它能有效地揭示潜伏在软件里的缺陷。

需求分析后

　　问题三：变更的控制 　　测试计划改变了已往根据任务进行测试的方式，因此，为使测试计划得到贯彻和落实，测试组人员必须及时跟踪软件开发的过程，对产品提交测试做准备，测试计划的目的，本身就是强调按规划的测试战略进行测试，淘汰以往以任务为主的临时性。在这种情况下，测试计划中强调对变更的控制显得尤为重要。 　　变更来源于以下几个方面 　　1． 项目计划的变更 　　2． 需求的变更 　　3． 测试产品版本的变更 　　4． 测试资源的变更 　　测试阶段的风险主要是对上述变更所造成的不确定性，有效的应对这些变更就能降低风险发生的几率。要想计划本身不成为空谈和空白无用的纸质文档，对不确定因素的预见和事先防范必须做到心中有数。 　　对于项目计划的变更，除了测试人员及时跟进项目以外，项目经理必须认识到测试组也是项目成员，因此必须把这些变更信息及时通知到项目组，使得整个项目得到顺延。项目计划变更一般涉及都是日程变更，令人遗憾的是，往往为了进度的原因，交付期限是既定的，项目经理不得不减少测试的时间，这样，执行测试的时间就被压缩了。在这种情况下，测试经理常常固执的认为进度缩减的唯一的方法就是向上级通报并主观认为产品质量一定会下降，这种做法和想法不一定是正确的。由于时间不足，不能“完美”的执行所有测试，为了保证质量，第一种办法是调整测试计划中的测试策略和测试范围，实践中测试经理常常忽略测试计划的这个章节。调整的目的是重新检查不重要的测试部分，调换测试的次序和减少测试规模，对测试类型重新组合择优，力求在限定时间内做最重要部分的测试，可以把忽略部分留给确认测试或现场测试。其他应对办法包括减少进入测试的阻力，例如降低测试计划中系统测试准入准则；分步提交测试，例如改成迭代方式增量测试；减少回归测试的要求，例如开发人员实时修改，在测试计划中对缺陷修复响应时间和过程进行约定；和公司QA商量进行简化配置管理，跳过正式发布环节；缺陷进行局部回归而不是重新全部测试等等。 　　第二：项目进行过程中最不可避免的就是需求的变更。那么，测试计划中就不能进行控制和约束的吗？答案是未必。当制定计划时，如果项目需求处于动态变化时，在测试用例章节就要进行说明。许多测试经理在编制测试用例时往往没有把测试用例和测试数据进行区分，因此，造成的问题是当需求变化时辛辛苦苦设计的数据就作废了。在这时，假使面临一个需求动态的项目，必须在计划中对需求变更造成的测试（设计）方式变化进行说明，例如采用用例和数据分离、流程和界面分离、字典项和数据元素分离的设计方式，然后等到最终需求确定后细化测试设计；另一个方面是最好制定一个变更周期的约定――尤其在执行测试阶段发现需求的变更――定义变更的最大频度和重新测试的界限，计划从一定程度上能够降低不可预期需求变化造成的投入损失。值得注意的是：需求发生变更时测试经理额外的工作是记住要在需求跟踪矩阵上做记录。 　　对于测试产品版本的变更，除了部分是由于需求变更造成之外，很有可能是由于修改缺陷引发的问题或配置管理不严格造成。众所周知，测试必须是基于一个稳定的“基线”进行，否则，因反复修改造成测试资源和开发资源的浪费是可观的。合理的测试计划在章节中应增加一个测试更新管理的章节，在此章节明确更新周期和暂停测试的原则。例如，小版本的产品更新不能大于每天三次，一个相对大的版本不能每周大于1次，规定紧急发布产品仅限于何种类型的修改或变更，由谁负责统一维护和同步更新测试环境。测试计划通常制定了准入和准出准则，这是不够的，要考虑测试暂停的时候，产品错误发布或者服务器数据更新就是一个例子，暂停的时候如果测试经理不进行跟踪，可能发生测试组等待测试而没人通知继续测试的情况，所以，增加更新周期和暂停测试原则是很有必要的。 　　最后，测试资源的变更是源自测试组内部的风险而非开发组风险，当测试资源不足或者冲突，测试部门不可能安排如此多的人手和足够时间参与测试时，在测试计划中的控制方法与测试时间不足相类似。没有测试经理愿意承担资源不足的测试工作，只能说公司本身是否具备以质量为主的体系或者项目经理对产品质量的重视程度如何决定了对测试资源投入的大小，最终产品质量取决因素不仅仅在于测试经理。为了排除这种风险，除了象时间不足、测试计划变更时那样缩减测试规模等等方法以外，测试经理必须在人力资源和测试环境一栏标出明确需要保证的资源，否则，必须将这个问题作为风险记录。规避风险的办法可能有： 　　一，项目组的需求和实施人员参与系统测试； 　　二，抽调不同模块开发者进行交叉系统测试或借用其他项目开发人员； 　　三，组织客户方进行确认测试或发布β版本。 　　尽管上面尽可能的描述了测试计划如何制定才能“完美”，但是还存在的问题是对测试计划的管理和监控。一份计划投入再多的时间去做也不能保证按照这份计划进行实施。好的测试计划是成功的一半，另一半是对测试计划的执行。对小项目而言，一份更易于操作的测试计划更为实用，对中型乃至大型项目来看，测试经理的测试管理能力就显得格外重要，要确保计划不折不扣的执行下去，测试经理的人际谐调能力，项目测试的操作经验、公司的质量现状都能够对项目测试产生足够的影响。另外，计划也是“动态的”！不必要把所有的因素都可能囊括进去，也不必要针对这种变化额外制定“计划的计划”，测试计划制定不能在项目开始后束之高阁，而是紧追项目的变化，实时进行思考和贯彻，根据现实修改，然后成功实施，这才能实现测试计划的最终目标――保证项目最终产品的质量！

根据需求挖掘出隐式需求，然后制定出测试项，根据测试项确定工作内容。测试计划主要是工作的分配，所有的事情都是为了更好的完成工作而设定的条件主要分成：组织形式测试对象测试通过/失败标准测试挂起/恢复条件任务分配 a.估计工作量 b.资源分配 c.进度按排 d.风险估计和规避措施 e.输入/输出文档其中风险估计和规避措施可以理解为：测试工作任务安排中的风险和假设，以及针对每一个风险的应急处理计划

测试用例的概念：将软件测试的行为活动，做一个科学的组织归纳的过程。简单地说，测试用例就是设计一个情况，软件程序在这种情况之下，必须能正常运行并达到程序所设计的执行结果。测试用列的日常实践得出：1、明确用例设计的必要性：日程的测试行为中，我们不可能对软件进行穷举测试，为了节省资源与实践、提高测试效率、就必须从数量极大的可用测试数据中科学的挑选即有代表性、特殊性、或典型性(基于业务使用场景)，的测试数据来进行测试；2、以日常实践指导用例设计、改进的思想：a、在实施软件测试之初，以测试的角度解读需求，设计完成测试用例，避免盲目测试，提高测试效率b、测试用例的使用，使得测试的实施重点突出、目的明确c、在软件版本更新后只需维护较少数用例便可开展后续测试迭代，降低测试强度，缩短整个项目周期d、测试用例亦能做到通用化与复用化，使得软件测试过程针对性强，互补性强。并且用例的设计水平不断的精化与攀升3、科学选择设计方法：目前主流用例方法都比较实用，但在测试实践中，具体采用什么方法，还是要正对开发项目的特点对方法加以适当的选择，切勿死板硬套。

俗话说：凡事预则立，不预则废！在测试项目之初就要制定相应的测试计划。接下来谈下如何编写测试计划问题。首先了解以下几个问题：1． 为什么要编写测试计划？1）领导能够根据测试计划做宏观调控，进行相应资源配置等；2）测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等；3）便于其他人员了解测试人员的工作内容，进行有关配合工作2． 什么时间开始编写测试计划？（测试需求分析前总体测试计划书/测试需求分析后详细测试计划书）3． 由谁来编写测试计划？具有丰富经验的项目测试负责人4． 测试计划编写6要素？（5W1H）1）why——为什么要进行这些测试；2) what—测试哪些方面，不同阶段的工作内容；3) when—测试不同阶段的起止时间；4) where—相应文档，缺陷的存放位置，测试环境等；5) who—项目有关人员组成，安排哪些测试人员进行测试6) how—如何去做，使用哪些测试工具以及测试方法进行测试。

测试计划编写6要素（5W1H）：why——为什么要进行这些测试；what—测试哪些方面，不同阶段的工作内容；when—测试不同阶段的起止时间；where—相应文档，缺陷的存放位置，测试环境等；who—项目有关人员组成，安排哪些测试人员进行测试；how—如何去做，使用哪些测试工具以及测试方法进行测试测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法（最好是能先评审）想要了解更多软件测试资讯，也可关注啄木鸟学院。

软件测试计划是指导测试过程的纲领性文件，包含了产品概述， 测试策略，测试方法，测试区域，测试配置，测试周期，测试资源， 风险分析等内容；借助软件测试计划，参与测试的项目成员， 可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通， 跟踪和控制测试进度，应对测试过程中的各种变更。 �0�2�0�2测试计划和测试用例间是战略和战术的关系， 测试计划主要从宏观上规划测试活动的范围，方法和资源配置； 而测试用例是完成测试任务的具体战术。 �0�2�0�2测试计划中，最重要的是测试策略和测试方法。 测试计划工作的关键是1. �0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2 明确测试的目标，增强测试计划的实用性---测试计划中的测试范 围必须高度覆盖功能需求，测试方法必须切实可行， 测试工具具有较高的实用性，便于使用，生成的测试结果直观准确。2. �0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2坚持“5W”规则，明确内容与过程“5W”规则指：what， why， when， where，how；用例5w规则创建软件测试计划， 可帮助测试团队理解测试目的（why），明确测试范围和内容（what），确定测试开始和结束日期（when）， 指出测试的方法和工具（what）， 给出测试文档和软件存放位置（where）3. 采用评审和更新机制，保证测试计划满足实际需求

项目工期估算是根据项目范围、资源状况计划列出项目活动所需要的工期。估算的工期应该现实、有效并能保证质量。所以在估算工期时要充分考虑活动清单、合理的资源需求、人员的能力因素以及环境因素对项目工期的影响。在对每项活动的工期估算中应充分考虑风险因素对工期的影响。项目工期估算完成后，可以得到量化的工期估算数据，将其文档化，同时完善并更新活动清单。

测试策略是测试计划文档编写时的其中一部分。

“工欲善其事，必先利其器”。专业的测试必须以一个好的测试计划作为基础。尽管测试的每一个步骤都是独立的，但是必定要有一个起到框架结构作用的测试计划。测试的计划应该作为测试的起始步骤和重要环节。 一个测试计划应包括：产品基本情况调研、测试需求说明、测试策略和记录、测试资源配置、计划表、问题跟踪报告、测试计划的评审、结果等等。 产品基本情况调研： 这部分应包括产品的一些基本情况介绍，例如：产品的运行平台和应用的领域，产品的特点和主要的功能模块，产品的特点等。对于大的测试项目，还要包括测试的目的和侧重点。 具体的要点有： 变更：说明有可能会导致测试计划变更的事件。包括测试工具改进了，测试的环境改变了，或者是添加了新的功能。 产品规格：就是制造商和产品版本号的说明。 项目信息：说明要测试的项目的相关资料，如：用户文档，产品描述，主要功能的举例说明。 测试需求说明： 功能的测试：理论上是测试是要覆盖所有的功能项，例如：在数据库中添加、编辑、删除记录等等，这会是一个浩大的工程，但是有利于测试的完整性。 设计的测试：对于一些用户界面、菜单的结构还有窗体的设计是否合理等的测试。 整体考虑：这部分测试需求要考虑到数据流从软件中的一个模块流到另一个模块的过程中的正确性。 测试的策略和记录： 公正性声明：要对测试的公正性、遵照的标准做一个说明，证实测试是客观的，整体上，软件功能要满足需求，实现正确，和用户文档的描述保持一致。 非凡考虑：有的时候，针对一些外界环境的影响，要对软件进行一些非凡方面的测试。 经验判定：对以往的测试中，经常出现的问题加以考虑。 设想：采取一些发散性的思维，往往能帮助你找的测试的新途径。 测试资源配置： 项目资源计划：制定一个项目资源计划，包含的是每一个阶段的任务、所需要的资源，当发生类似到了使用期限或者资源共享的事情的时候，要更新这个计划。 问题跟踪报告： 问题描述尽可能是定量的，分门别类的列举，问题有几种： 1、严重问题：严重问题意味着功能不可用，或者是权限限制方面的失误等等，也可能是某个地方的改变造成了别的地方的问题。 2、一般问题：功能没有按设计要求实现或者是一些界面交互的实现不正确。 3、建议问题：功能运行得不象要求的那么快，或者不符合某些约定俗成的习惯，但不影响系统的性能，界面先是错误，格式不对，含义模糊混淆的提示信息等等。 测试计划的评审： 又叫测试规范的评审，在测试真正实施开展之前必须要认真负责的检查一遍，获得整个测试部门人员的认同，包括部门的负责人的同意和签字。 结果：计划并不是到这里就结束了，在最后测试结果的评审中，必须要严格验证计划和实际的执行是不是有偏差，体现在最终报告的内容是否和测试的计划保持一致，然后，就可以开始着手制作下一个测试计划了。进入讨论组讨论。

软件测试计划是指导测试过程的纲领性文件，包含了产品概述，测试策略，测试方法，测试区域，测试配置，测试周期，测试资源，风险分析等内容；借助软件测试计划，参与测试的项目成员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。测试计划和测试用例间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围，方法和资源配置；而测试用例是完成测试任务的具体战术。测试计划中，最重要的是测试策略和测试方法。测试计划工作的关键是1. 明确测试的目标，增强测试计划的实用性---测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具具有较高的实用性，便于使用，生成的测试结果直观准确。2. 坚持“5W”规则，明确内容与过程“5W”规则指：what，why，when，where，how；用例5w规则创建软件测试计划，可帮助测试团队理解测试目的（why），明确测试范围和内容（what），确定测试开始和结束日期（when），指出测试的方法和工具（what），给出测试文档和软件存放位置（where）3. 采用评审和更新机制，保证测试计划满足实际需求

软件测试计划是指导测试过程的纲领性文件，包含了产品概述， 测试策略，测试方法，测试区域，测试配置，测试周期，测试资源， 风险分析等内容；借助软件测试计划，参与测试的项目成员， 可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通， 跟踪和控制测试进度，应对测试过程中的各种变更。 0202测试计划和测试用例间是战略和战术的关系， 测试计划主要从宏观上规划测试活动的范围，方法和资源配置； 而测试用例是完成测试任务的具体战术。 0202测试计划中，最重要的是测试策略和测试方法。 测试计划工作的关键是1. 02020202020202020202020202 明确测试的目标，增强测试计划的实用性---测试计划中的测试范 围必须高度覆盖功能需求，测试方法必须切实可行， 测试工具具有较高的实用性，便于使用，生成的测试结果直观准确。2. 02020202020202020202020202坚持“5W”规则，明确内容与过程“5W”规则指：what， why， when， where，how；用例5w规则创建软件测试计划， 可帮助测试团队理解测试目的（why），明确测试范围和内容（what），确定测试开始和结束日期（when）， 指出测试的方法和工具（what）， 给出测试文档和软件存放位置（where）3. 采用评审和更新机制，保证测试计划满足实际需求

软件测试计划是指导测试过程的纲领性文件，包含了产品概述，测试策略，测试方法，测试区域，测试配置，测试周期，测试资源，风险分析等内容；借助软件测试计划，参与测试的项目成员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。�0�2�0�2测试计划和测试用例间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围，方法和资源配置；而测试用例是完成测试任务的具体战术。�0�2�0�2测试计划中，最重要的是测试策略和测试方法。测试计划工作的关键是1.�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2明确测试的目标，增强测试计划的实用性---测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具具有较高的实用性，便于使用，生成的测试结果直观准确。2.�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2坚持“5W”规则，明确内容与过程“5W”规则指：what，why，when，where，how；用例5w规则创建软件测试计划，可帮助测试团队理解测试目的（why），明确测试范围和内容（what），确定测试开始和结束日期（when），指出测试的方法和工具（what），给出测试文档和软件存放位置（where）3.采用评审和更新机制，保证测试计划满足实际需求

软件测试计划是指导测试过程的纲领性文件，包含了产品概述，测试策略，测试方法，测试区域，测试配置，测试周期，测试资源，风险分析等内容；借助软件测试计划，参与测试的项目成员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。 测试计划和测试用例间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围，方法和资源配置；而测试用例是完成测试任务的具体战术。 测试计划中，最重要的是测试策略和测试方法。 测试计划工作的关键是 1. 明确测试的目标，增强测试计划的实用性---测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具具有较高的实用性，便于使用，生成的测试结果直观准确。 2. 坚持“5W”规则，明确内容与过程 “5W”规则指：what，why，when，where，how；用例5w规则创建软件测试计划，可帮助测试团队理解测试目的（why），明确测试范围和内容（what），确定测试开始和结束日期（when），指出测试的方法和工具（what），给出测试文档和软件存放位置（where）3. 采用评审和更新机制，保证测试计划满足实际需求

1. 引言：目的、背景、范围、定义、参考资料2. 测试内容：测试功能清单3. 测试规则：进入准则，暂停/退出准则、测试方法、测试手段、测试要点、测试工具4. 测试环境：硬件环境、软件环境、特定测试环境要求5. 项目任务：测试规划，测试设计，测试执行准备，测试执行，测试总结6. 实施计划：工作量估计、人员需求及安排、进度安排、其它资源需求及安排、可交付工件7. 风险管理

测试计划包括哪些内容，包括有很多内容。

测试计划是针对项目测试一个大致规划的文档， 主要包含以下内容：1. 测试的目的和测试范围， 项目测试方法和测试模块内容。2. 项目组人员的任务分配和进度安排3. 项目执行过程中可能遇到的风险分析和风险预防。4. 项目验收的指标。你可以多去黑马程序员视频库看看，里面这样的知识点特别多如果认可我的回答，希望能帮忙采纳下

测试的目的和测试范围、项目组人员的任务分配和进度安排、项目执行过程中可能遇到的风险分析和风险预防和项目验收的指标。测试计划Testing plan，描述了要进行的测试活动的范围、方法、资源和进度的文档是对整个信息系统应用软件组装测试和确认测试。它确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。测试计划可以有效预防计划的风险，保障计划的顺利实施。测试计划的作用作为测试计划的结果，让相关人员和开发人员来评审。存储计划执行的细节，让测试人员进行同行评审。存储计划进度表、测试环境等更多的信息。测试计划的外部作用是为顾客提供一种信心，通常向顾客交代有关测试过程、人员的技能、资源、使用的工具等信息。参考资料来源：百度百科-测试计划

引言：目的、背景、范围、定义、参考资料2. 测试内容：测试功能清单3. 测试规则：进入准则，暂停/退出准则、测试方法、测试手段、测试要点、测试工具4. 测试环境：硬件环境、环境、特定测试环境要求5. 项目任务：测试规划，测试设计，测试执行准备，测试执行，测试总结6. 实施计划：工作量估计、人员需求及安排、进度安排、其它资源需求及安排、可交付工件7. 风险管理

1、确定工程 　　收集下列信息 文档 已创建（是/否） 版本/日期 需求详述 　 　 功能详述 　 　 项目计划 　 　 设计详述 　 　 原型 　 　 用户手册 　 　　　定义新的工程，Adminà New Project。 　　确定软件的结构，用Assetsà Software Structure选项定义软件结构。 　　2、定义测试策略 测试策略项 例子 测试阶段 系统测试 测试类型 功能测试 测试技术 75%用SQA Suite自动测试，25%手工测试 完成标准 95%测试用例通过并且最高级缺陷全部解决 特殊考虑 测试必须在上午进行　　 3、分解软件，写测试需求 　　分析各种信息 　　反复检查并理解各种信息，和用户交流，理解他们的要求。可以按照以下步骤执行： 　　1、确定软件提供的主要商业任务 　　2、对每个商业任务，确定完成该任务所要进行的交易。 　　3、确定从数据库信息引出的计算结果。 　　4、对于对时间有要求的交易，确定所要的时间和条件。这些条件包括数据库大小、机器配置、交易量、以及网络拥挤情况。 　　5、确定会产生重大意外的压力测试，包括：内存、硬盘空间、高的交易率 　　6、确定应用需要处理的数据量。 　　7、确定需要的软件和硬件配置。通常情况下，不可能对所有可能的配置都测试到，因此要选择最有可能产生问题的情况进行测试，包括：最低性能的硬件、几个有兼容性问题的软件并存、客户端机器通过最慢的LAN/WANF连接访问服务器。 　　8、确定其他与应用软件没有直接关系的商业交易。包括： 　　　　管理功能，如启动和推出程序 　　　　配置功能，如设置打印机 　　　　操作员的爱好，如字体、颜色 　　　　应用功能，如访问email或者显示时间和日期。 　　9、确定安装过程，包括定置从哪安装、定制安装、升级安装。 　　10、确定没有隐含在功能测试中的户界面要求。大多界面都在功能测试时被测试到。还有写没有测到，如：操作与显示的一致性，如使用快捷键等；界面遵从合理标准，如按钮大小，标签等。 　　把需求组织成层次图 　　4、估计测试工作量 　　∑(每个测试的时间*每个需求的测试的数目*测试需求的的数目) 　　（测试设计、开发、….） 　　5、确定资源 　 　　　人力资源 职位 姓名 特殊责任/说明 测试经理 　 　 测试工程师 设计/开发（可以多人） 　 　 测试工程师 测试执行（可以多人） 　 　 测试系统管理员 　 　　　系统资源 系统 名称/类型 数据库服务器 网络/子网 服务器名称 数据库名称 　 　 　 　 SQA 测试存储库 网络/子网 服务器名称 　 　 　 客户测试机 包括专门的配置需求　列表 　 测试开发的PC机 列表 　　6、创建工程调度表 任务 相关工作量（天） 整个SQA过程

软件测试定义是：为了发现程序中的错误而执行程序的过程它是帮助识别开发完成（中间或最终的版本）的计算机软件（整体或部分）的正确度(correctness)、完全度(completeness)和质量(quality)的软件过程；是SQA(softwarequalityassurance)的重要子域。软件测试的目标：(1)测试是为了发现程序中的错误而执行程序的过程；(2)好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；(3)成功的测试是发现了至今为止尚未发现的错误的测试。

软件测试计划包括以下这些内容：试范围：它指的是系统测试的范围以及本轮测试是测试全部模块还是只测试部分模块。 2.测试环境：它指的是测试人员是在什么样的软、硬件环境下进行测试。3.测试策略：它的内容包括测试的依据、系统测试准入的标准、测试工具的选择、测试的重点及方法、测试准出的标准。4.测试管理：它指的是测试任务的分配、时间的限定、测试与开发之间的沟通方式等内容。5.测试风险：它指的是测试中如不透彻理解需求文档、估计不足测试时间及测试执行不到位等情况所造成的一些测试风险。

1. 了解需求，评估测试模块的难易程度，做好初步的了解和测试思路。2. 与开发沟通，协调好提测时间以及相关约定(提测标准)。3. 根据手头的资源已经提测的时间，做好安排，预留一定缓冲时间。(一定要考虑风险点，比如开发推迟提测，bug阻碍进展，等等)4. 测试过程中需要考虑的要素：测试分析(测试案例)，数据准备，环境准备，测试执行，这几点都需要在测试计划中考虑到。

1 软件测试计划的编写基础知识已经分享的差不多了，之后就是我们的收尾工作，今天给大家讲讲我们做测试过程中会用到的一个文档：《软件测试计划》在我们软件测试工作阶段，一共分为五个阶段：计划、设计、执行、评估、验收。可以看到在做软件测试工作的时候，最开始，就是要做好计划工作，也就是软件测试计划。在软件测试计划里面应该包含哪些内容呢？包括这些：1）测试开始时间 &测试结束时间2）测试的内容模块定位（包含哪些内容测试点）3）测试的参与人员以及任务分工4）输出文档的规定以及存放5）采用的测试方法以及测试工具的申请。其实就总结起来，就是大家看见过的5W原则：When:什么时候开始做，什么时候结束测试，要在这段时间内做好一个规划与进度。What：我们要做什么？要明确的罗列出来，好明确我们的测试方向和重点，并方便后期划分责任模块Who：谁要参与这次项目的测试？具体负责哪个模块的功能测试？主要负责任务是？都是在这个里面进行明确的责任划分How：如何测试，确定我们的测试方法：是白盒测试还是黑盒测试？我们要不要进行自动化测试要不要进行性能压力测试？要不要进行安全性测试，都需要在这个里面计划好。Where：这个是说把文档放在哪里，就明确的包括了我们的输出文档有哪些：比如说测试用例？Bug列表？测试报告等等文档要存放的位置，作用就是规定输出文档以及输出文档的存放位置。 怎么样，这么一说，是不是觉得软件测试报告要很好理解了呢?今天给大家分享了软件测试报告的编写！更多问题可以加群 333782754 小编每天都按时推送，关注我们打发你的琐碎时间。如果你有别的见解，也非常欢迎留言！

提供了对测试对象进行测试的推荐方法。对于每种测试，都应提供测试说明，并解释其实施的原因。制定测试策略时所考虑的主要事项有：将要使用的技术以及判断测试何时完成的标准。下面列出了在进行每项测试时需考虑的事项，除此之外，测试还只应在安全的环境中使用已知的、有控制的数据库来执行。注意：不实施某种测试，则应该用一句话加以说明，并陈述这样的理由。例如，“将不实施该测试。该测试本项目不适用”。 [要<项目名称>中，数据库和数据库进程应作为一个子系统来进行测试。在测试这些子系统时，不应将测试对象的用户界面用作数据的接口。对于数据库管理系统（DBMS），还需要进行深入的研究，以确定可以支持以下测试的工具和技术。]测试目标：[确保数据库访问方法和进程正常运行，数据不会遭到损坏]测试范围：技术：[调用各个数据库访问方法和进程，并在其中填充有效的和无效的数据（或对数据的请求）。检查数据库，确保数据已按预期的方式填充，并且所有的数据库事件已正常发生；或者检查所返回的数据，确保正当的理由检索到了正确的数据]完成标准：[所有的数据库访问方法和进程都按照设计的方式运行，数据没有遭到损坏。]测试重点和优先级：需考虑的特殊事项：[测试可能需要DBMS开发环境或驱动程序在数据库中直接输入或修改数据。进程应该以手工方式调用。应使用小型或最小的数据库（记录的数量有限）来使所有无法接受的事件具有更大的可视度。] 测试目标：确保接口调用的正确性测试范围：所有软件、硬件接口，记录输入输出数据技术：开始标准：完成标准：测试重点和优先级：需考虑的特殊事项：接口的限制条件 [集成测试―主要目的检测系统是否达到需求对业务流程及数据流的处理是否符合标准，检测系统对业务流处理是否存在逻辑不严谨及错误，检测需求是否存在不合理的标准及要求。此阶段测试基于功能完成的测试。]测试目标：检测需求中业务流程，数据流的正确性测试范围：需求中明确的业务流程，或组合不同功能模块而形成一个大的功能。技术：[利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下内容：在使用有效数据时得到预期的结果。在使用无效数据时显示相应的错误消息或警告消息。各业务规则都得到了正确的应用。]开始标准：在完成某个集成测试时必须达到标准完成标准：[所计划的测试已全部执行。所发现的缺陷已全部解决。]测试重点和优先级：测试重点指在测试过程中需着重测试的地方，优先级可以根据需求及严重来定需考虑的特殊事项：[确定或说明那些将对功能测试的实施和执行造成影响的事项或因素（内部的或外部的）] [对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。此类测试基于黑盒技术，该技术通过图形用户界面（GUI）与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。以下为各种应用程序列出了推荐使用的测试概要：]测试目标：[确保测试的功能正常，其中包括导航，数据输入，处理和检索等功能。]测试范围：技术：[利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下内容：在使用有效数据时得到预期的结果。在使用无效数据时显示相应的错误消息或警告消息。各业务规则都得到了正确的应用。]开始标准：完成标准：测试重点和优先级：需考虑的特殊事项：[确定或说明那些将对功能测试的实施和执行造成影响的事项或因素（内部的或外部的）] [用户界面（UI）测试用于核实用户与软件之间的交互。UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外，UI测试还可确保UI中的对象按照预期的方式运行，并符合公司或行业的标准。]测试目标：[核实以下内容：通过测试进行的浏览可正确反映业务的功能和需求，这种浏览包括窗口与窗口之间、字段与字段之间的浏览，以及各种访问方法（Tab键、鼠标移动、和快捷键）的使用窗口的对象和特征（例如，菜单、大小、位置、状态和中心）都符合标准。]测试范围：技术：[为每个窗口创建或修改测试，以核实各个应用程序窗口和对象都可正确地进行浏览，并处于正常的对象状态。]开始标准：完成标准：[成功地核实出各个窗口都与基准版本保持一致，或符合可接受标准]测试重点和优先级：需考虑的特殊事项：[并不是所有定制或第三方对象的特征都可访问。] [性能评测是一种性能测试，它对响应时间、事务处理速率和其他与时间相关的需求进行评测和评估。性能评测的目标是核实性能需求是否都已满足。实施和执行性能评测的目的是将测试对象的性能行为当作条件（例如工作量或硬件配置）的一种函数来进行评测和微调。注：以下所说的事务是指“逻辑业务事务”。这种事务被定义为将由系统的某个Actor通过使用测试对象来执行的特定用例，添加或修改给定的合同。]测试目标：[核实所指定的事务或业务功能在以下情况下的性能行为：正常的预期工作量预期的最繁重工作量]测试范围：技术：[使用为功能或业务周期测试制定的测试过程。通过修改数据文件来增加事务数量，或通过修改脚本来增加每项事务的迭代数量。脚本应该在一台计算机上运行（最好是以单个用户、单个事务为基准），并在多个客户机（虚拟的或实际的客户机，请参见下面的“需要考虑的特殊事项”）上重复。]开始标准：完成标准：[单个事务或单个用户：在每个事务所预期时间范围内成功地完成测试脚本，没有发生任何故障。][多个事务或多个用户：在可接受的时间范围内成功地完成测试脚本，没有发生任何故障。]测试重点和优先级：需考虑的特殊事项：[综合的性能测试还包括在服务器上添加后台工作量。可采用多种方法来执行此操作，其中包括：直接将“事务强行分配到”服务器上，这通常以“结构化语言”（SQL）调用的形式来实现。通过创建“虚拟的”用户负载来模拟许多个（通常为数百个）客户机。此负载可通过“远程终端仿真（Remote Terminal Emulation）工具来实现。此技术还可用于在网络中加载“流量”。使用多台实际客户机（每台客户机都运行测试脚本）在系统上添加负载。性能测试应该在专用的计算机上或在专用的机时内执行，以便实现完全的控制和精确的评测。性能测试所用的数据库应该是实际大小或相同缩放比例的数据库。] [负载测试是一种性能测试。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载 测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关 的方面。][注：以下所说的事务是指“逻辑业务事务”。这各事务被定义为将由系统的某个最终用户通过使用应用程序来执行的特定功能，例如，添加或修改给定的合同。]测试目标：[核实所指定的事务或商业理由在不同的工作量条件下的性能行为时间。]测试范围：技术：[使用为功能或业务周期测试制定的测试。通过修改数据文件来增加事务数量，或通过修改脚本来增加每项事务发生的次数。]开始标准：完成标准：[多个事务或多个用户：在可接受的时间范围内成功地完成测试，没有发生任何故障。]测试重点和优先级：需考虑的特殊事项：[负载测试应该在专用的计算机上或在专用的机时内执行，以便实现完全的控制和精确的评测。负载测试所用的数据库应该是实际大小或相同缩放比例的数据库。] [强度测试是一种性能测试，实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条 件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。][注：以下提到的事务都是指逻辑业务事务。]测试目标：[核实测试对象能够在以下强度条件下正常运行，不会出现任何错误：服务器上几乎没有或根本没有可用的内存（RAM和DASD）连接或模拟了最大实际（实际允许）数量的客户机多个用户对相同的数据或帐户执行相同的事务最繁重的事务量或最差的事务组合（请参见上面的“性能测试”）。注：强度测试的目标可表述为确定和记录那些使系统无法继续正常运行的情况或条件。客户机的强度测试在“配置测试”的第3.1.11节中进行了说明。]测试范围：技术：[使用为性能评测或负载测试制定的测试。要对有限的资源进行测试，就应该在一台计算机上运行测试，而且应该减少或限制服务器上的RAM和DASD。对于其他强度测试，应该使用多台客户机来运行相同的测试或互补的测试，以产生最繁重的事务量或最差的事务组合。]开始标准：完成标准：[所计划的测试已全部执行，并且在达到或超出指定的系统限制时没有出现任何软件故障，或者导致系统出现故障条件的并不在指定的条件范围之内。]测试重点和优先级：需考虑的特殊事项：[如果要增加网络工作强度，可能会需要使用网络工具来给网络加载消息或信息包。应该暂时减少用于系统的DASD，以限制数据库可用空间的增长。使多个客户机对相同的记录或数据帐户同时进行的访问达到同步。] [容量测试使测试对象处理大量的数据，以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。例 如，如果测试对象正在为生成一份报表而处理一组数据库记录，那么容量测试就会使用一个大型的测试数据库。检验该软件是否正常运行并生成了正确的报表。]测试目标：[核实测试对象在以下高容量条件下能否正常运行：连接或模拟了最大（实际或实际允许）数量的客户机，所有客户机在长时间内执行相同的、且情况（性能）最坏的业务功能。已达到最大的数据库大小（实际的或按比例缩放的），而且同时执行多个查询或报表事务。]测试范围：技术：[使用为性能评测或负载测试制定的测试。应该使用多台客户机来运行相同的测试或互补的测试，以便在长时间内产生最繁重的事务量或最差的事务组合（请参见上面的“强度测试”）创建最大的数据库大小（实际的、按比例缩放的、或填充了代表性数据的数据库），并使用多台客户机在长时间内同时运行查询和报表事务。]开始标准：完成标准：所计划的测试已全部执行，而且达到或超出指定的系统限制时没有出现任何软件故障。]测试重点和优先级：需考虑的特殊事项：[对于上述的高容量条件，哪个时间段是可以接受的时间？]安全性和访问 [故障转移和恢复测试可可确保测试对象能成功完成转移，并能从导致意外数据损失或数据完整性破坏的各种硬件、软件可网络故障中恢复。故障转移测试可确保：对于必须持续运行的系统，一旦发生故障，备用系统就将不失时机地“顶替”发生故障的系统，以避免丢失任何数据或事务。恢复测试是一种对抗性的测试过程。在这种测试中，将把应用程序或系统置于极端的条件下（或者是模拟的极端条件下），以产生故障（例如设备输入/输出（I/O）故障或无效的数据库指针和关键字）。然后调用恢复进程并监测和检查应用程序和系统，核实应用程序或系统和数据已得到了正确的恢复。]测试目标：[确保恢复进程（手工或自动）将数据库、应用程序和系统正确地恢复到预期的已知状态。测试中将包括以下各种情况：客户机断电、服务器断电、通过网络服务器产生的通信中断DASD和/或DASD控制器被中断、断电或与DASD和/或DASD控制器的通信中断周期未完成（数据过滤进程被中断，数据同步进程被中断）、数据库指针或关键字无效、数据库中的数据元素无效或遭到破坏]测试范围：技术：[应该使用为功能和业务周期测试创建的测试来创建一系列的事务。一旦达到预期的测试起点，就应该分别执行或模拟以下操作：uf0b2 客户机断电：关闭PC机的电源。uf0b2 服务器断电：模拟或启动服务器的断电过程。uf0b2 通过网络服务器产生的中断：模拟或启动网络的通信中断（实际断开通信线路的连接或关闭网络服务器或路由器的电源）。uf0b2 DASD和DASD控制器被中断、断电或与DASD和DASD控制器的通信中断：模拟与一个或多个DASD控制器或设备的通信，或实际取消这种通信。uf0b2 一旦实现了上述情况（或模拟情况），就应该执行其他事务。而且一旦达到第二个测试点状态，就应调用恢复过程。uf0b2 在测试不完整的周期时，所使用的技术与上述技术相同，只不过应异常终止或提前终止数据库进程本身。uf0b2 对以下情况的测试需要达到一个已知的数据库状态。当破坏若干个数据库字段、指针和关键字时，应该以手工方式在数据库中（通过数据库工具）直接进行。其他事务应该通过使用“应用程序功能测试”和“业务周期测试”中的测试来执行，并且应执行完整的周期。]开始标准：完成标准：[在所有上述情况中，应用程序、数据库和系统应该在恢复过程完成时立即返回到一个已知的预期状态。此状态包括仅限于已知损坏的字段、指针或关键字范围内的数据损坏，以及表明进程或事务因中断面未被完成的报表。]测试重点和优先级：需考虑的特殊事项： [恢复测试会给其他操作带来许多的麻烦。断开缆线连接的方法（模拟断电或通信中断）可能并不可取或不可行。所以，可能会需要采用其他方法，例如诊断性软件工具。uf0b2 需要系统（或计算机操作）、数据库和网络组中的资源。uf0b2 这些测试应该在工作时间之外或在一台独立的计算机上运行。] [配置测试核实测试对象在不同的软件和硬件配置中的运行情况。在大多数生产环境中，客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工 作站可能会安装不同的软件　例如，应用程序、驱动程序等　而且在任何时候，都可能运行许多不同的软件组合，从而占用不同的资源。]测试目标：[核实测试可在所需的硬件和软件配置中正常运行。]测试范围：技术：[使用功能测试脚本。uf0b2 在测试过程中或在测试开始之前，打开各种与非测试对象相关的软件（例如Microsoft应用程序：Excel和Word），然后将其关闭。uf0b2 执行所选的事务，以模拟Actor与测试对象软件和非测试对象软件之间的交互。uf0b2 重复上述步骤，尽量减少客户机工作站上的常规可用内存。]开始标准：完成标准：[对于测试对象软件和非测试对象软件的各种组合，所有事务都成功完成，没有出现任何故障。]测试重点和优先级：需考虑的特殊事项：[需要、可以使用并可以通过桌面访问哪种非测试对象软件？uf0b2 通常使用的是哪些应用程序？uf0b2 应用程序正在运行什么数据？例如，在Excel中打开的大型电子表格，或是在Word中打开的100页文档。uf0b2 作为此测试的一部分，应将整修系统、Netware、网络服务器、数据库等都记录下来。] [安装测试有两个目的。第一个目的是确保该软件在正常情况和异常情况的不同条件下　例如，进行首次安装、升级、完整的或自定义的安装　都能进行安装。异常情况 包括磁盘空间不足、缺少目录创建权限等。第二个目的是核实软件在安装后可立即正常运行。这通常是指运行大量为功能测试制定的测试。]测试目标：核实在以下情况下，测试对象可正确地安装到各种所需的硬件配置中：uf0b2 首次安装。以前从未安装过<项目名称>的新计算机uf0b2 更新。以前安装过相同版本的<项目名称>的计算机uf0b2 更新。以前安装过从未安装过；<项目名称>安装过相同或较早的版本。uf0b2 启动或执行安装。uf0b2 使用预先确定的功能测试脚本子集来运行事务。开始标准：完成标准：<项目名称>事务成功执行，没有出现任何故障。测试重点和优先级：需考虑的特殊事项：[应该选择<项目名称>的哪些事务才能准确地测试出<项目名称>应用程序已经成功安装，而且没有遗漏主要的软件构件？。

呵呵！这是测试计划模版 请拿Wo XXX公司 文档编号 项目版本 密级项目名称： 共14页XXX项目测试计划拟制： 日期： yyyy/mm/dd审核： 日期： yyyy/mm/dd批准： 日期： yyyy/mm/dd修订记录日期 修订版本 描述 作者yyyy/mm/dd XX版本 初稿完成 XXX目 录1目标 62 概述 62.1 项目背景 62.2 范围 63 组织形式 64 测试对象 85 需求跟踪 96 测试通过/失败标准 97 测试挂起标准及恢复条件 98 测试任务安排 108.1 任务1 108.1.1方法和标准： 108.1.2 输入/输出： 108.1.3 时间安排： 108.1.4 资源 ： 108.1.5 风险和假设： 108.1.6 角色和职责： 108.2 任务2 118.2.1 方法和标准： 118.2.2 输入/输出： 118.2.3 时间安排： 118.2.4 资源 ： 118.2.5 风险和假设： 118.2.6 角色和职责： 118.3 任务3 118.3.1 方法和标准： 118.3.2 输入/输出： 118.3.3 时间安排： 118.3.4 资源 ： 128.3.5 风险和假设： 128.3.6 角色和职责： 128.4 任务4 128.4.1 方法和标准： 128.4.2 输入/输出： 128.4.3 时间安排： 128.4.4 资源 ： 128.4.5 风险和假设： 128.4.6 角色和职责： 129 应交付的测试工作产品 1310 工作量估计 1311 资源的分配 1312 附录 14XXX项目系统测试计划关键词：摘 要：缩略语清单：参考资料清单：名称 作者 编号 发布日期 出版单位1目标所有测试需求都已被标识出来；测试的工作量已被正确估计并合理地分配了人力、物力资源；测试的进度安排是基于工作量估计的、适用的；测试启动、停止的准则已被标识；测试输出的工作产品是已标识的、受控的和适用的。2 概述2.1 项目背景简要描述项目背景及所要求达到的目标，如项目的主要功能特征、体系结构及简要历史等。（开发者、架构、主要运行环境、主要功能、目标用户。）2.2 范围指明该计划的适用对象及范围。3 组织形式描述参加系统测试的各测试项目组的组织结构（可以图的形式），通过文字形式来描述各组织在系统测试中的职责和组织间关系，也可以描述测试项目组内部的结构，和各组成员的职责。描述本软件组织中关于系统测试过程和开发过程、项目管理过程、质量保证过程、配置管理过程等过程相关联的部分。明确测试组和开发组、配置管理组、质量保证组等相关组的沟通渠道，保证系统测试过程中的问题能技术沟通和解决，保证系统测试工作的顺利进行；同时要从组织上明确测试人员发现问题和监督问题解决的权利，保证测试人员的工作积极性，使得软件质量能从组织上得到保证；另外还要明确测试工作产品输出的权利，即由谁来签发《系统测试计划》、《系统测试方案》等测试文档和最终的《系统测试报告》，一般软件组织已经对此有了明确定义，如果没有，做计划时需要明确下来。举例：1）测试组内部组织结构2）测试组与其它部门之间的关系3）沟通渠道测试组组长：1、制订本组测试计划；2、给测试分析员分配任务并依据制定的计划指导和监控他们的工作；3、给测试员分配任务并依据制定的计划指导和监控他们的工作；4、与开发组保持联系和沟通，例如确定版本发布日期、沟通版本质量进展、缺陷发展趋势；5、组织本组测试文档的设计、写作和评审；6、组织本组进行相关需求跟踪；7、组织本组进行缺陷分析等质量活动；8、向测试主管等高层领导汇报本组工作测试分析员：测试员：4 测试对象这里列出系统测试计划活动中分析确定的所有功能测试项目和非功能测试项目；还要列出测试项目中的哪些特性和特性组合将不被测试，并说明不被测试的原因。在这里所列的测试项仅仅是为了表达应测试什么，至于如何测试可以在测试方案中进行描述。举例：1）业务功能业务流程数据库事务域值合法性…...2）用户界面对象状态窗口模式菜单标准尺寸的控件/文字…...3）性能在3秒内对用户登陆请求给出响应当系统内存低于32M的情况下运行应用程序，考察其性能指标为设计规定是 1,000,000 条记录的系统增加 1,000,001条记录…...4）配置在windows 98系统下进行配置测试在Unix系统下进行配置测试…...5）安装新安装（典型安装、定制安装）光盘升级安装网络升级安装…...5 需求跟踪建立测试需求跟踪矩阵表举例：需求标识 需求描述 系统测试项标识 系统测试项描述Router_V100_SRS_001 路由增加 Router_V100_ST_AddRoute 路由增加6 测试通过/失败标准本节描述系统测试计划活动中确定的系统测试通过/ 失败标准，这是判断测试过程通过或失败的标准，而不是被测对象通过或失败的标准。举例：1）达到100％需求覆盖；2）所有1级、2级用例被执行，3级、4级用例执行率达到60％；3）测试过程中缺陷率达到公司系统测试质量标准7 测试挂起标准及恢复条件描述系统测试计划活动中确定的系统测试挂起标准/恢复条件举例：系统测试挂起标准举例：1）基本功能测试不能通过；2）出现致命问题导致30％用例被堵塞，测试无法执行下去。。。。。。系统测试恢复条件举例：1）导致测试堵塞的问题被修复，并通过了回归测试；。。。。。8 测试任务安排8.1 任务18.1.1方法和标准： 指明执行该任务时，应采用的方法以及所应遵循的标准8.1.2 输入/输出： 给出该任务所必需的输入及输出8.1.3 时间安排： 给出任务的起始及持续的时间，为方便文档维护，建议采用相对时间，即任务的起始时间是相对于某一里程碑或阶段的相对时间8.1.4 资源 ： 给出任务所需要的人力和物力资源，工作量应明确到“人天”8.1.5 风险和假设： 指明启动该任务应满足的假设以及任务执行可能存在的风险8.1.6 角色和职责： 指明由谁负责该任务的组织和执行，以及谁将担负怎样的职责8.2 任务2 8.2.1 方法和标准：8.2.2 输入/输出：8.2.3 时间安排：8.2.4 资源 ：8.2.5 风险和假设：8.2.6 角色和职责：8.3 任务3 8.3.1 方法和标准：8.3.2 输入/输出：8.3.3 时间安排：8.3.4 资源 ：8.3.5 风险和假设：8.3.6 角色和职责：8.4 任务4 8.4.1 方法和标准：8.4.2 输入/输出：8.4.3 时间安排：8.4.4 资源 ：8.4.5 风险和假设：8.4.6 角色和职责：9 应交付的测试工作产品本节描述系统测试计划活动中确定的测试完成后应交付的测试文档、测试代码及测试工具等测试工作产品。举例：u2022 系统测试计划u2022 系统测试方案 u2022 系统测试用例u2022 系统测试规程u2022 系统测试日志u2022 系统测试报告u2022 。。。。。。10 工作量估计根据前面安排的任务，估计各任务的工作量，具体到人天举例：序号 任务名称 负责人 工作量（人天）1 计划测试 张三 1人天2 设计测试 李四 2人天3 实现测试 王五 3人天4 执行测试 赵六 4人天… … … … … … … …总计: 11 资源的分配本节汇总所有任务中所需要的资源举例：1）人员及培训需求：依据角色及职责和测试任务安排”中的资源，确定所需人员及培训要求，应指明人员与角色之间的映射关系2）测试环境、测试工具：依据测试任务安排中的资源，确定所需的测试环境及测试工具3）测试仪器或材料：确定所需测试仪器和设备的要求。指定仪表仅需写型号即可，非指定仪表需给出测量精度要求等。仪表需给出足够的信息，如测试中使用AM8e，则表示如下： 呼叫分析仪 + Ameritec + AM8e 功能名称 生产厂家 仪器型号 生产厂家如有缩略语，则用缩略语表示，如HP，W&G等。4）其他需求：确定需要的特殊工具，确定其他任何测试需要（如，办公室空间需要等），确定对测试小组来说目前还没有但是必需的需求的来源。12 附录

测试计划一般由资深的测试人员来做， 要对整体的项目有非常好的掌控，有丰富的测试经验的人员来编写测试计划。1. 测试计划一般由测试经理来编写。2. 测试组其他人员， 会针对自己分配的任务估算自己任务的时间，统一汇总到测试经理那里。如果想这块内容增强的小伙伴参考网上的相关知识(黑马程序员论坛等)

如何编写测试计划呢？测试计划要包括以下四个要点：1、待测试的内容；2、编写测试用例的时间；3、执行测试用例的时间；4、执行回归测试的时间。以上四点，待测试的内容可以需求分析中取得，需求分析中的测试要点就是要测试的内容，而其它3点就不是很容易确定了。因为我们可以从软件的开发进度中获得开始时间，但很难确定测试的结束的时间。下面有一个预估的办法，是大多数测试工程师的经验所得，我们拿到评审后的需求分析可以用下面的方法预估。1、计算需求分析的页数，得出测试用例的页数，需求分许页数：测试用例页数 ≈ 1：12、由测试用例页数计算编写系统测试用例时间：编写系统测试用例时间 ≈ 系统测试用例页数×1小时3、计算执行测试用例时间：编写测试用例用时：执行系统测试用时 ≈ 1：24、计算回归测试包含的时间：系统测试用时：回归测试用时≈ 2：1以上的方法可能根据测试人员对项目熟悉程度和测试经验的不同而有所差别，大家可以根据自己的经验做出调整。计算出测试用例、执行测试和回归测试的时间后，根据软件项目的开发进度就可以编写出一个软件测试的时间表了。不过从目前国内软件公司的现状来说，测试时间一般都不够，所以我们只能延长我们的工作时间，提高我们的工作效率。程序员说他们处于最底层，用户说要改什么，他们就要实现什么，没人关心他们的工作难度和工作时间。（发点牢骚，大家就当没看见，呵呵）

软件测试定义是：为了发现程序中的错误而执行程序的过程它是帮助识别开发完成（中间或最终的版本）的计算机软件（整体或部分）的正确度(correctness)、完全度(completeness)和质量(quality)的软件过程；是sqa(softwarequalityassurance)的重要子域。软件测试的目标：(1)测试是为了发现程序中的错误而执行程序的过程；(2)好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；(3)成功的测试是发现了至今为止尚未发现的错误的测试。

“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。为了使“5W”规则更具体化，需要准确理解被测软件的功能特征、应用行业的知识和软件测试技术，在需要测试的内容里面突出关键部分，可以列出关键及风险内容、属性、场景或者测试技术。对测试过程的阶段划分、文档管理、缺陷管理、进度管理给出切实可行的方法。就通常软件项目而言，基本上采用“瀑布型”开发方式，这种开发方式下，各个项目主要活动比较清晰，易于操作。整个项目生命周期为“需求－设计－编码－测试－发布－实施－维护”。然而，在制定测试计划时候，有些测试经理对测试的阶段划分还不是十分明晰，经常性遇到的问题是把测试单纯理解成系统测试，或者把把各类型测试设计（测试用例的编写和测试数据准备）全部放入生命周期的“测试阶段”，这样造成的问题是浪费了开发阶段可以并行的项目日程，另一方面造成测试不足。相应阶段可以同步进行相应的测试计划编制，而测试设计也可以结合在开发过程中实现并行，测试的实施即执行测试的活动即可连贯在开发之后。值得注意的是：单元测试和集成测试往往由开发人员承担，因此这部分的阶段划分可能会安排在开发计划而不是测试计划中。

lz你这个问题....我想反问一下lz，你制定一个计划的目的是什么？

软件测试定义是：为了发现程序中的错误而执行程序的过程它是帮助识别开发完成（中间或最终的版本）的计算机软件（整体或部分）的正确度(correctness) 、完全度(completeness)和质量(quality)的软件过程；是SQA(software quality assurance)的重要子域。软件测试的目标：(1)测试是为了发现程序中的错误而执行程序的过程；(2)好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；(3)成功的测试是发现了至今为止尚未发现的错误的测试。

软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。 测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方单元测试完成之后，接下来的工作就是集成测试.软件集成测试主要依据软件结构设计（概要设计）文档，测试主要内容有功能性、可靠性、易用性、效率、维护性和可移植性中相关的部分，根据软件需求和设计的要求而选定。 验证各软件单元集成后形成的模块能否达到概要设计规格说明中各模块的设计目标；这里，模块可能是指某个软件部件，也可能是指某个或某几个子系统。通常在做集成测试时先是从子系统内部的集成测试开始做起，做完以后再测试各子系统是否能集成为最终要实现的整体系统。也有其他做法（如自顶向下集成测试方法、核心系统先做集成测试或每日集成测试等等）。总之，万变不离其宗,集成测试要保证模块的内部正确性以及保证模块能最终集成为完整的系统。集成测试有时也被称为组装测试或灰盒测试（有观点认为集成测试介于白盒与黑盒之间）。软件集成测试具体内容包括：1.功能性测试（1）程序的功能测试。检查各个子功能组合起来能否满足设计所要求的功能。 （2）一个程序单元或模块的功能是否会对另一个程序单元或模块的功能产生不利影响。 （3）根据计算精度的要求，单个程序模块的误差积累起来，是否仍能够达到要求的技术指标。 （4）程序单元或模块之间的接口测试。把各个程序单元或模块连接起来时，数据在通过其接口时是否会出现不一致情况,是否会出现数据丢失。 （5）全局数据结构的测试。检查各个程序单元或模块所用到的全局变量是否一致、合理。 （6）对程序中可能有的特殊安全性要求进行测试。2.可靠性测试 根据软件需求和设计中提出的要求，对软件的容错性、易恢复性、错误处理能力进行测试。3.易用性测试 根据软件设计中提出的要求，对软件的易理解性、易学性和易操作性进行检查和测试。4.性能测试 根据软件需求和设计中提出的要求，进行软件的时间特性、资源特性测试。5.维护性测试 根据软件需求和设计中提出的要求，对软件的易修改性进行测试。6.可移植性测试 根据软件需求和设计中提出的要求，对软件在不同操作系统环境下被使用的正确性进行测试。

软件测试计划是指导测试过程的纲领性文件，包含了产品概述，测试策略，测试方法，测试区域，测试配置，测试周期，测试资源，风险分析等内容；借助软件测试计划，参与测试的项目成员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。0202测试计划和测试用例间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围，方法和资源配置；而测试用例是完成测试任务的具体战术。0202测试计划中，最重要的是测试策略和测试方法。测试计划工作的关键是1.02020202020202020202020202明确测试的目标，增强测试计划的实用性---测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具具有较高的实用性，便于使用，生成的测试结果直观准确。2.02020202020202020202020202坚持“5W”规则，明确内容与过程“5W”规则指：what，why，when，where，how；用例5w规则创建软件测试计划，可帮助测试团队理解测试目的（why），明确测试范围和内容（what），确定测试开始和结束日期（when），指出测试的方法和工具（what），给出测试文档和软件存放位置（where）3.采用评审和更新机制，保证测试计划满足实际需求

“工欲善其事，必先利其器”。专业的测试必须以一个好的测试计划作为基础。尽管测试的每一个步骤都是独立的，但是必定要有一个起到框架结构作用的测试计划。测试的计划应该作为测试的起始步骤和重要环节。 一个测试计划应包括：产品基本情况调研、测试需求说明、测试策略和记录、测试资源配置、计划表、问题跟踪报告、测试计划的评审、结果等等。 产品基本情况调研： 这部分应包括产品的一些基本情况介绍，例如：产品的运行平台和应用的领域，产品的特点和主要的功能模块，产品的特点等。对于大的测试项目，还要包括测试的目的和侧重点。 具体的要点有： 变更：说明有可能会导致测试计划变更的事件。包括测试工具改进了，测试的环境改变了，或者是添加了新的功能。 产品规格：就是制造商和产品版本号的说明。 项目信息：说明要测试的项目的相关资料，如：用户文档，产品描述，主要功能的举例说明。 测试需求说明： 功能的测试：理论上是测试是要覆盖所有的功能项，例如：在数据库中添加、编辑、删除记录等等，这会是一个浩大的工程，但是有利于测试的完整性。 设计的测试：对于一些用户界面、菜单的结构还有窗体的设计是否合理等的测试。 整体考虑：这部分测试需求要考虑到数据流从软件中的一个模块流到另一个模块的过程中的正确性。 测试的策略和记录： 公正性声明：要对测试的公正性、遵照的标准做一个说明，证实测试是客观的，整体上，软件功能要满足需求，实现正确，和用户文档的描述保持一致。 非凡考虑：有的时候，针对一些外界环境的影响，要对软件进行一些非凡方面的测试。 经验判定：对以往的测试中，经常出现的问题加以考虑。 设想：采取一些发散性的思维，往往能帮助你找的测试的新途径。 测试资源配置： 项目资源计划：制定一个项目资源计划，包含的是每一个阶段的任务、所需要的资源，当发生类似到了使用期限或者资源共享的事情的时候，要更新这个计划。 问题跟踪报告： 问题描述尽可能是定量的，分门别类的列举，问题有几种： 1、严重问题：严重问题意味着功能不可用，或者是权限限制方面的失误等等，也可能是某个地方的改变造成了别的地方的问题。 2、一般问题：功能没有按设计要求实现或者是一些界面交互的实现不正确。 3、建议问题：功能运行得不象要求的那么快，或者不符合某些约定俗成的习惯，但不影响系统的性能，界面先是错误，格式不对，含义模糊混淆的提示信息等等。 测试计划的评审： 又叫测试规范的评审，在测试真正实施开展之前必须要认真负责的检查一遍，获得整个测试部门人员的认同，包括部门的负责人的同意和签字。 结果：计划并不是到这里就结束了，在最后测试结果的评审中，必须要严格验证计划和实际的执行是不是有偏差，体现在最终报告的内容是否和测试的计划保持一致，然后，就可以开始着手制作下一个测试计划了。进入讨论组讨论。

测试策略一般描述软件测试活动的一般方法和目标。其中包括要进行的测试阶段（单元测试、集成测试和系统测试）以及要执行的测试类型（功能测试、性能测试、负载测试、强度测试等）。确定测试需求：明确测试的工作范围，需要测试的对象、达到的指标等。可以来源于软件需求，个人经验，以前发生的错误等。

测试计划是针对项目测试一个大致规划的文档， 主要包含以下内容：1. 测试的目的和测试范围， 项目测试方法和测试模块内容。2. 项目组人员的任务分配和进度安排3. 项目执行过程中可能遇到的风险分析和风险预防。4. 项目验收的指标。如果想这块内容增强的小伙伴参考网上的相关知识(黑马程序员论坛等)

1，计划是什么？ 计划是关于如何做某样事情的思考 2，测试计划是什么？ 测试计划是关于日和做测试软件事情的思考 3，编写测试计划关注的因素点 时间-----由项目计划覆盖 成本-----由合同覆盖 范围-----由需求文档覆盖 质量-----由QA计划或测试计划覆盖 4，编写测试计划的作用 外部：是给顾客一个信心，关于测试过程、技能、资源、工具等的信息 内部：1）作为测试计划的结果，让相关人员和开发人员来评审。 2）存储计划执行的细节，让测试人员来进行同行评审。 3）存储计划进度表、测试环境等更多的信息。 5，测试计划要点-确定测试范围 明确测试对象 1）准备问题：通过了解需求提前准备好问题，有目的去沟通 2）沟通确认：沟通确认“改动了什么”、“改动前后的区别是什么”、“为什么要改”、“改动引起的影响范围有哪些” 3）整理测试范围：根据沟通结果、测试经验等整理出最终的测试范围 6，测试计划要点-制定测试方案 测试方案受三个因素影响：测试策略，进度，安排测试资源 序号 测试类型 测试目的 1 功能性测试 根据系统需求文档和设计文档，检查产品是否正确实现了功能 2 用户界面（UI）测试 检查界面是否美观合理 3 兼容性测试 在不同浏览器上能正常运行 4 流程测试 按操作流程进行的测试，主要有业务流程、数据流程、逻辑流程、正反流程， 检查软件在按流程操作时 是否能够正确处理 5 回归测试 检查程序修改后有没有引起新的错误、是否能够正常工作以及能否满足系统的需求 6 性能测试 提取系统性能数据，检查系统是否 满足需求中所规定达到的性能 7 接口测试 检查系统能否与外部接口正常工作 8 安全性和访问控制权限测试 应用程序级别的安全性：检查用户只能访问其所属用户类型已被授权访问的那些功能或数据。 系统级别的安全性检查只有具备 系统和应用程序访问权限的用户才能访问系统和应用程序 测试计划要点-制定测试进度 测试进度的安排如下： 一轮测试： 功能测试：XX人时，完成时间X月X日 机型覆盖：XX人时，完成时间X月X日 功能回归测试：XX人时，完成时间X月X日 各类评测：XX人时，完成时间X月X日 二轮测试： 冲突测试：XX人时，完成时间X月X日 随机回归测试：XX人时，完成时间X月X日 验收测试：XX人时，完成时间X月X日 测试阶段 开始时间 持续时间 完成时间 一轮测试 功能测试 7月3日 8人时 7月4日 机型覆盖 7月4日 24人时 7月6日 各类评测 随机测试 7月6日 12人时 7月7日 产品需求测试需求测试类型&范围评估测试设计时间预估测试执行时间预估测试负责人 输入方式可扩展键盘切换页面键盘可伸缩布局正确性：验证键盘切换页面布局、显示、切换逻辑的正确性 合理性：布局、显示、切换提示是否符合用户体验 3人时3人时 键盘显示配置5人时 键盘切换6人时5人时 键盘切换提示2人时 键盘配置页面正确性：验证键盘配置页面的正确性4人时4小时 合理性：键盘配置布局是否符合用户体验 不同分辨率&横竖屏&单手键盘兼容性4人时4人时 随机测试正确性、合理性、兼容性2人时 Buffer时间8人时

软件项目的测试计划是描述测试目的、范围、方法和软件测试的重点等的文档。对于验证软件产品的可接受程度编写测试计划文档是一种有用的方式。百度百科的解释是这样的，一般软件测试计划中会明确测试对象，定义测试目标，测试通过标准，计划测试进度与参与人员，以及一些可预见的测试风险等。

某件产品首先测试生产质量、生产价格、生产规模。

软件测试计划作为软件项目计划的子计划，在项目启动初期是必须规划的。在越来越多公司的软件开发中，软件质量日益受到重视，测试过程也从一个相对独立的步骤越来越紧密嵌套在软件整个生命周期中，这样，如何规划整个项目周期的测试工作;如何将测试工作上升到测试管理的高度都依赖于测试计划的制定。测试计划因此也成为测试工作的赖于展开的基础。 　　一个好的测试计划可以起到如下作用 　　1. 避免测试的“事件驱动” 　　2. 使测试工作和整个开发工作融合起来 　　3. 资源和变更事先作为一个可控制的风险 　　测试计划的模板在各个公司中都大同小异，在个人实践中发现，测试计划制定中存在的问题具有相似性，下面重点就这些相似的问题谈谈如何制定软件项目测试计划。 　　问题一：测试阶段划分 　　就通常软件项目而言，基本上采用“瀑布型”开发方式，这种开发方式下，各个项目主要活动比较清晰，易于操作。整个项目生命周期为“需求-设计-编码-测试-发布-实施-维护”。然而，在制定测试计划时候，有些测试经理对测试的阶段划分还不是十分明晰，经常性遇到的问题是把测试单纯理解成系统测试，或者把把各类型测试设计(测试用例的编写和测试数据准备)全部放入生命周期的“测试阶段”，这样造成的问题是浪费了开发阶段可以并行的项目日程，另一方面造成测试不足。 　　合理的测试阶段应遵循下面划分方法： 　　照上图所述，相应阶段可以同步进行相应的测试计划编制，而测试设计也可以结合在开发过程中实现并行，测试的实施即执行测试的活动即可连贯在开发之后。值得注意的是：单元测试和集成测试往往由开发人员承担，因此这部分的阶段划分可能会安排在开发计划而不是测试计划中。 　　问题二：系统测试阶段日程安排 　　划分阶段清楚了，随之而来的问题是测试执行需要多长的时间?标准的工程方法或CMM方式是对工作量进行估算，然后得出具体的估算值。但是这种方法过于复杂，可以另辟专题讨论。一个可操作的简单方法是：根据测试执行上一阶段的活动时间进行换算，换算方法是与上一阶段活动时间1：1。1~1。5左右。举个例子，对测试经理来说，因为开发计划可能包含了单元测试和集成测试，系统测试的时间大概是编码阶段(包含单元测试和集成测试)1到1。5倍。这种方法的优点是简单，依赖于项目计划的日程安排，缺点是水分太多，难于量化。那么，可以采用的另一个简单方法是经验评估。评估方法如下： 　　1. 计算需求文档的页数，得出系统测试用例的页数 　　需求页数：系统测试用例页数 ≈ 1：1 　　2. 由系统测试用例页数计算编写系统测试用例时间 　　编写系统测试用例时间 ≈ 系统测试用例页数×1小时 　　3. 计算执行系统测试用例时间 　　编写系统用例用时：执行系统测试用时 ≈ 1：2 　　4. 计算回归测试包含的时间 　　系统测试用时：回归测试用时≈ 2：1 　　注：以上比值是个人工程经验值，需要更正比值的测试经理可以在具体实践中收集数据。 　　基于以上方法优点是需求为已知的，可以利用已知来推算未知，适用于需求是已知且相对稳定的情况下;缺点是处于研发状态的项目，需求不清晰的时候比较难计算。现套用一个例子加于说明：需求文档页数为500，系统测试用例页数推算为500，则编写系统测试用例时间为500小时，执行系统测试用例时间为1000小时，回归测试需要500小时，加起来总共为2000小时，按一天8小时计算，共计250个工作日/人;假如一个月为22个工作日，则共计约11人/月，即投入4个人需要3个月左右时间工作量完成。当然，这是系统测试需要的全部时间。根据测试阶段划分原则，设计用例时间可以和开发同步进行，只需在测试阶段中安排的时间为1500小时即4人2个月工作量。 　　(测试经理在编写测试计划时候，测试进度中的计划开始/结束时间往往用如20050101-20051201的具体时间划分方式，这样引起的问题是当项目计划进行变更的时候，测试计划时间不得不随时调整，这种变更可能是频繁而琐碎的，可以替代的办法是取消这种方式，采用30工作日/2人或者2人月这种工作量记录方式，这样一来，只需在项目计划中跟踪阶段的具体开始时间即可，不必反复修改测试计划。) 　　值得注意的是：国内大多数公司的测试时间都是不足的，不可能按照这样的理想比例进行运作，因为测试执行的时间实际上不可能占据整个项目周期的1/2，甚至要短于其中任何一个项目阶段时间。即使是微软的测试结束原则也并不是完成所有必需的测试，而是测试在按计划结束的那一天结束!在测试时间不足的情况下，可参考下面项目计划变更时的做法，因为计划变更也涉及到测试时间不足的情况。 　　问题三：变更的控制 　　测试计划改变了已往根据任务进行测试的方式，因此，为使测试计划得到贯彻和落实，测试组人员必须及时跟踪软件开发的过程，对产品提交测试做准备，测试计划的目的，本身就是强调按规划的测试战略进行测试，淘汰以往以任务为主的临时性。在这种情况下，测试计划中强调对变更的控制显得尤为重要。 　　变更来源于以下几个方面 　　1. 项目计划的变更 　　2. 需求的变更 　　3. 测试产品版本的变更 　　4. 测试资源的变更 　　测试阶段的风险主要是对上述变更所造成的不确定性，有效的应对这些变更就能降低风险发生的几率。要想计划本身不成为空谈和空白无用的纸质文档，对不确定因素的预见和事先防范必须做到心中有数。 　　对于项目计划的变更，除了测试人员及时跟进项目以外，项目经理必须认识到测试组也是项目成员，因此必须把这些变更信息及时通知到项目组，使得整个项目得到顺延。项目计划变更一般涉及都是日程变更，令人遗憾的是，往往为了进度的原因，交付期限是既定的，项目经理不得不减少测试的时间，这样，执行测试的时间就被压缩了。在这种情况下，测试经理常常固执的认为进度缩减的的方法就是向上级通报并主观认为产品质量一定会下降，这种做法和想法不一定是正确的。由于时间不足，不能“完美”的执行所有测试，为了保证质量，第一种办法是调整测试计划中的测试策略和测试范围，实践中测试经理常常忽略测试计划的这个章节。调整的目的是重新检查不重要的测试部分，调换测试的次序和减少测试规模，对测试类型重新组合择优，力求在限定时间内做最重要部分的测试，可以把忽略部分留给确认测试或现场测试。其他应对办法包括减少进入测试的阻力，例如降低测试计划中系统测试准入准则;分步提交测试，例如改成迭代方式增量测试;减少回归测试的要求，例如开发人员实时修改，在测试计划中对缺陷修复响应时间和过程进行约定;和公司QA商量进行简化配置管理，跳过正式发布环节;缺陷进行局部回归而不是重新全部测试等等。 　　第二：项目进行过程中最不可避免的就是需求的变更。那么，测试计划中就不能进行控制和约束的吗?答案是未必。当制定计划时，如果项目需求处于动态变化时，在测试用例章节就要进行说明。许多测试经理在编制测试用例时往往没有把测试用例和测试数据进行区分，因此，造成的问题是当需求变化时辛辛苦苦设计的数据就作废了。在这时，假使面临一个需求动态的项目，必须在计划中对需求变更造成的测试(设计)方式变化进行说明，例如采用用例和数据分离、流程和界面分离、字典项和数据元素分离的设计方式，然后等到最终需求确定后细化测试设计;另一个方面是制定一个变更周期的约定――尤其在执行测试阶段发现需求的变更――定义变更的频度和重新测试的界限，计划从一定程度上能够降低不可预期需求变化造成的投入损失。值得注意的是：需求发生变更时测试经理额外的工作是记住要在需求跟踪矩阵上做记录。 　　对于测试产品版本的变更，除了部分是由于需求变更造成之外，很有可能是由于修改缺陷引发的问题或配置管理不严格造成。众所周知，测试必须是基于一个稳定的“基线”进行，否则，因反复修改造成测试资源和开发资源的浪费是可观的。合理的测试计划在章节中应增加一个测试更新管理的章节，在此章节明确更新周期和暂停测试的原则。例如，小版本的产品更新不能大于每天三次，一个相对大的版本不能每周大于1次，规定紧急发布产品仅限于何种类型的修改或变更，由谁负责统一维护和同步更新测试环境。测试计划通常制定了准入和准出准则，这是不够的，要考虑测试暂停的时候，产品错误发布或者服务器数据更新就是一个例子，暂停的时候如果测试经理不进行跟踪，可能发生测试组等待测试而没人通知继续测试的情况，所以，增加更新周期和暂停测试原则是很有必要的。 　　最后，测试资源的变更是源自测试组内部的风险而非开发组风险，当测试资源不足或者冲突，测试部门不可能安排如此多的人手和足够时间参与测试时，在测试计划中的控制方法与测试时间不足相类似。没有测试经理愿意承担资源不足的测试工作，只能说公司本身是否具备以质量为主的体系或者项目经理对产品质量的重视程度如何决定了对测试资源投入的大小，最终产品质量取决因素不仅仅在于测试经理。为了排除这种风险，除了象时间不足、测试计划变更时那样缩减测试规模等等方法以外，测试经理必须在人力资源和测试环境一栏标出明确需要保证的资源，否则，必须将这个问题作为风险记录。规避风险的办法可能有： 　　一，项目组的需求和实施人员参与系统测试; 　　二，抽调不同模块开发者进行交叉系统测试或借用其他项目开发人员; 　　三，组织客户方进行确认测试或发布β版本。 　　尽管上面尽可能的描述了测试计划如何制定才能“完美”，但是还存在的问题是对测试计划的管理和监控。一份计划投入再多的时间去做也不能保证按照这份计划进行实施。好的测试计划是成功的一半，另一半是对测试计划的执行。对小项目而言，一份更易于操作的测试计划更为实用，对中型乃至大型项目来看，测试经理的测试管理能力就显得格外重要，要确保计划不折不扣的执行下去，测试经理的人际谐调能力，项目测试的操作经验、公司的质量现状都能够对项目测试产生足够的影响。另外，计划也是“动态的”!不必要把所有的因素都可能囊括进去，也不必要针对这种变化额外制定“计划的计划”，测试计划制定不能在项目开始后束之高阁，而是紧追项目的变化，实时进行思考和贯彻，根据现实修改，然后成功实施，这才能实现测试计划的最终目标――保证项目最终产品的质量!

软件测试计划是指导测试过程的纲领性文件，包含了产品概述，测试策略，测试方法，测试区域，测试配置，测试周期，测试资源，风险分析等内容；借助软件测试计划，参与测试的项目成员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。 测试计划和测试用例间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围，方法和资源配置；而测试用例是完成测试任务的具体战术。 测试计划中，最重要的是测试策略和测试方法。 测试计划工作的关键是 1. 明确测试的目标，增强测试计划的实用性---测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具具有较高的实用性，便于使用，生成的测试结果直观准确。 2. 坚持“5W”规则，明确内容与过程 “5W”规则指：what，why，when，where，how；用例5w规则创建软件测试计划，可帮助测试团队理解测试目的（why），明确测试范围和内容（what），确定测试开始和结束日期（when），指出测试的方法和工具（what），给出测试文档和软件存放位置（where）3. 采用评审和更新机制，保证测试计划满足实际需求

测试计划就是在编写测试用例前制定的一个计划，主要包括确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。 测试计划编写6要素（5W1H）1）why——为什么要进行这些测试；2) what—测试哪些方面，不同阶段的工作内容；3) when—测试不同阶段的起止时间；4) where—相应文档，缺陷的存放位置，测试环境等；5) who—项目有关人员组成，安排哪些测试人员进行测试6) how—如何去做，使用哪些测试工具以及测试方法进行测试。根据上面的条目写不会有问题的。

软件测试是有计划、有组织和有系统的软件质量保证活动，而不是随意地、松散地、杂乱地实施过程。为了规范软件测试内容、方法和过程，在对软件进行测试之前，必须创建测试计划。

软件测试计划中包含的内容：1、软件测试简介，这里面就包含了本次软件测试的目的，软件测试的背景，以及软件测试的内容范围说明等。 2、术语、定语和缩略词，即文章中引用的专业术语词汇等，为了让读者明白其义就需要在前面以表格、列表等方式解释清楚。3、软件测试进度安排，即测试的进度计划，如果有集成测试，还应该区分集成测试和系统测试，以及下面迭代测试时间计划、性能测试等类别测试时间计划等。 4、测试资源，这里包括了人员的分配，测试环境的配置及组网图，测试工具等。 5、风险、问题及优先级，为了把控后期的软件测试风险，应该把软件测试中可能存在的风险、问题以等级划分标识出来，并给出对应的应对策略。 6、测试策略，即我们后面开展测试的思路，如怎么开展功能测试、性能测试、安全测试等。 7、测试标准，包括测试介入标准，结束标准，以及问题严重程度，这些都应该根据公司的实际情况进行划分。如严重程度，既对bug严重级别进行定义，常见的有4级或5级划分。 8、参考文档及测试产出文档，即把制定计划参考所用的文档以及整个软件测试过程需要产出的文档罗列出来。 9、附录，如：项目任务，具体可能包含软件测试过程步骤，以及过程产出等。更多软件测试相关资讯，可关注啄木鸟学院。

　　1、明确测试目标，确定测试需求。根据当前测试工作目标不同，测试需求的确定方式有所不同。如当前为新项目的测试工作，则测试需求可能为该项目能按时上线并按用户需求的功能正常使用等；而对于产品的阶段性测试，测试需求可以以列表形式展现，列表可以列出本次测试工作所需要测试的更新及影响的测试点等； 　　2、制定测试策略的时候，需要考虑，根据测试项目特点，确定本次测试需要经历的测试阶段。确定测试阶段后，确考虑每个测试阶段的目标、进入条件及退出条件； 　　3、确定测试资源，测试资源的确定，需要充分调研，基本确定系统规模、功能复杂度、系统运行环境等，结合测试策略，考虑所需要的测试资源； 　　4、测试里程碑设计，一般测试里程碑在模版上已经列示出来，测试计划制定者按照之前分析的测试需求、确定的测试策略及明确的测试资源，作相应的风险分析，从而确定测试里程碑及里程碑的起始时间。

制定计划　　1. 分析产品　　分析什么　　用户(他们是谁，他们做什么的)　　操作(这个操作是干什么用的)　　产品结构(代码，文件，等)　　产品功能(这些功能是干什么用的)　　产品数据(输入的，输出的，状态，等)　　平台(外部的硬件和软件)　　怎么分析　　走一下产品/原型的主要流程　　评审产品和项目文档　　咨询设计人员和用户　　与类似的产品做比较　　可能的工作产出　　产品的功能范围概要　　注释性的文档　　产品的问题列表　　执行状态检查　　设计人员有没有确认以及批准了产品的功能范围概要?　　设计人员有没有认为你已经正确理解了这个产品?　　你能不能将这个产品形象化并且预测正确的行为?　　你能不能造出产品的测试数据(输入和结果)?　　你能不能配置和操作这个产品?　　你有没有理解这个产品是怎么样被使用的?　　你有没有注意到设计中的漏洞或不一致的地方?　　关于这个产品你还有没有未解决的问题?　　2. 分析产品的风险　　分析什么　　产品受到的威胁　　产品的易受攻击的地方　　失败的方式　　失败后的影响　　怎么分析　　评审需求和规格说明书　　评审出现问题的一些事件　　咨询设计人员和用户　　通过探索性风险分析和质量判据列表来评审产品　　识别基本的错误/失败方式　　可能的工作产出　　组件风险列表矩阵　　失败模型概要　　执行状态检查　　设计人员和用户有没有对风险分析达成一致?　　你有没有发现所有的重要的问题，而这些问题是否在测试过程出现呢?　　你是否知道在哪些地方要集中测试精力并获得最大的效率呢?　　设计人员有没有做一些事情使得重要的问题更容易的发现，或减少其发生的概率呢?　　如果你的风险分析是正确的，你是怎么发现的呢?　　3. 设计测试策略　　基本策略　　Domain testing(包括边界值)　　用户测试　　压力测试　　回归测试　　Sequence testing　　State testing　　基于文档的测试　　结构化测试(单元测试等)　　怎么计划　　对于风险和产品功能匹配策略　　将特殊的和实际的策略形象化　　分析是否可用自动化的机会　　使用原型去测试probes和harnesses　　不要强加计划，让测试人员自己决定　　可能的工作产出　　各个类型的报告怎样应用的测试策略文档　　风险/任务的matrix　　已选择的策略中存在的问题或挑战列表　　对产品覆盖比较少的部分提供的建议　　测试用例(如果是必须的)　　执行状态检查　　设计人员对这个测试策略达成一致了吗?　　这个策略对于项目每个参与人员以及协助人员都有用吗?　　这个测试策略是否很基本了?是否也容易的应用到这个产品中?　　这个测试策略是否透露了所以的重要的问题　　4. 计划安排　　安排的内容　　测试时间的评估和计划　　易测性的工程分析　　测试团队人员(详细的能力)　　测试人员的培训和监督　　测试人员的任务的指定　　产品开发信息的收集和管理　　项目会议，沟通，协调的方式　　与其他已存在的功能之间的关系，包括开发过程中　　测试平台的认购和配置　　测试工具盒自动化　　需要用到的测试桩和mock　　测试套的管理和维护　　建立和输出协议约定　　测试周期管理　　问题报告系统和约定　　测试状态报告的约定　　代码冻结和增量测试　　测试后期的压力管理　　项目阶段输出协议约定　　测试效率的预估　　可能的工作产出　　问题列表　　项目风险分析　　任务和责任matrix　　测试时间表　　与开发之间的约定和协议　　执行状态检查　　这个项目所列的安排是否支持测试策略?　　是否存在一些问题会阻碍测试的执行?　　在可见性的问题面前，这些安排和策略是否适合?　　你现在是否开始测试还是以后整理剩下的问题?　　5. 分享计划　　分享的方式　　让设计人员和股东都参与到整个测试计划的制定过程中　　更主动的获取关于测试计划的意见　　尽最大可能帮助开发人员保持进度　　帮助开发人员理解他们做什么会影响测试　　与技术支持和写技术文档的人分享产品质量信息　　让设计人员和开发人员评审并且批准所以相关的文档　　记录并加强与开发之间的约定　　让参与人员评审测试计划的细节　 在测试计划中尽量减少没必要的信息以增加评审的效率　 　目标　　对于测试过程达到一致的理解

测试计划包括以下内容：1. 测试目标：说明测试的目的和预期的测试结果。2. 测试范围：明确测试的功能、模块、系统、接口等范围。3. 测试策略：定义测试方法、测试技术、测试工具和测试人员的角色和职责。4. 测试资源：包括测试人员、测试设备、测试工具和测试数据等资源。5. 测试进度：规划测试的时间框架、测试阶段和测试任务的顺序。6. 测试环境：描述测试所需的硬件、软件、网络、数据库等环境。7. 风险评估：评估测试过程中可能出现的风险，并制定相应的应对措施。8. 缺陷管理：描述测试缺陷的收集、记录、跟踪和解决过程。9. 测试验收标准：定义测试完成的标准和验收标准。

测试的目的和测试范围、项目组人员的任务分配和进度安排、项目执行过程中可能遇到的风险分析和风险预防和项目验收的指标。测试计划Testing plan，描述了要进行的测试活动的范围、方法、资源和进度的文档是对整个信息系统应用软件组装测试和确认测试。它确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。测试计划可以有效预防计划的风险，保障计划的顺利实施。测试计划的作用：作为测试计划的结果，让相关人员和开发人员来评审。存储计划执行的细节，让测试人员进行同行评审。存储计划进度表、测试环境等更多的信息。测试计划的外部作用是为顾客提供一种信心，通常向顾客交代有关测试过程、人员的技能、资源、使用的工具等信息。测试计划内容：（1）为测试各项活动制定一个现实可行的、综合的计划，包括每项测试活动的对象、范围、方法、进度和预期结果。（2）为项目实施建立一个组织模型，并定义测试项目中每个角色的责任和工作内容。（3）开发有效的测试模型，能正确地验证正在开发的软件系统。（4）确定测试所需要的时间和资源，以保证其可获得性、有效性。（5）确立每个测试阶段测试完成以及测试成功的标准、要实现的目标。（6）识别出测试活动中各种风险，并消除可能存在的风险，降低由不可能消除的风险所带来的损失。

不是，他们有比较大的区别的软件测试计划是在软件测试之前，或者每个测试周期开始前编写的，计划类的文档，用以指导测试工作的进行；而测试报告，一般是在测试/一个周期的测试工作后期，总结的缺陷情况、测试所发现的问题等等总结性的汇报文档，用以向相关部门阐述测试情况、分析软件质量等等的

第一题：我认为需要在测试前需要先写好测试计划，其中最重要的是本次测试使用的测试方法、使用的测试工具、测试环境。人员方面需要进行人员及进度的安排，每个测试阶段后的输出工件，还要有风险评估。在测试前将这些准备工作做到位，这样在测试的时候就会比较有条理。 第二题：控制测试质量，我认为最好是做好测试用例的设计，这样可以对测试的覆盖率进行控制。补充：如果时间充裕的话可以在设计用例后对其进行评审，这样可以提高测试质量。不过这个在实际的工作当中一般实现不了。。。。下面列出的是网上的一个软测笔试题，好多单位在笔试的时候都会copy下来作为笔试题，我至少遇到两次了，其他的笔试题还有，但不一一列出了。 一、判断题（每题1分，12 分，正确的√，错误的╳） 1．软件测试的目的是尽可能多的找出软件的缺陷。（） 2．Beta 测试是验收测试的一种。（） 3．验收测试是由最终用户来实施的。（） 4．项目立项前测试人员不需要提交任何工件。（） 5．单元测试能发现约80%的软件缺陷。（） 6．代码评审是检查源代码是否达到模块设计的要求。（） 7．自底向上集成需要测试员编写驱动程序。（） 8．负载测试是验证要检验的系统的能力最高能达到什么程度。（） 9．测试人员要坚持原则，缺陷未修复完坚决不予通过。（） 10．代码评审员一般由测试员担任。（） 1 11．我们可以人为的使得软件不存在配置问题。（） 12．集成测试计划在需求分析阶段末提交。（） 二、不定项选择题（每题2 分，10分） 1．软件验收测试的合格通过准则是：（） A． 软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求。 B． 所有测试项没有残余一级、二级和三级错误。 C． 立项审批表、需求分析文档、设计文档和编码实现一致。 D． 验收测试工件齐全。 2．软件测试计划评审会需要哪些人员参加？（） A．项目经理 B．SQA 负责人 C．配置负责人 D．测试组 3．下列关于alpha 测试的描述中正确的是：（） A．alpha 测试需要用户代表参加 B．alpha 测试不需要用户代表参加 C．alpha 测试是系统测试的一种 D．alpha 测试是验收测试的一种 4．测试设计员的职责有：（） A．制定测试计划 B．设计测试用例 C．设计测试过程、脚本 D．评估测试活动 5．软件实施活动的进入准则是：（） A．需求工件已经被基线化 B．详细设计工件已经被基线化 C．构架工件已经被基线化 D．项目阶段成果已经被基线化 三、填空题（每空1分，24 分） 1．软件验收测试包括(正式验收测试)、(非正式验收测试和Alpha测试)、(Beta测试)三种类型。 2．系统测试的策略有功能测试、（性能测试）、（负载测试）、（压力测试）、易用性测试、（容量测试）、（强度测试）、 （兼容性测试又称）、（本地化测试）、（BVT测试）、（裸机测试）、（安全性测试）、（）、（容错性测试）、（恢复测试）、（）等15 种方法。 3．设计系统测试计划需要参考的项目文档有（需求规格说明书）、（）和迭代计划。 4．对面向过程的系统采用的集成策略有（）、（）两种。 5．通过画因果图来写测试用例的步骤为、、、及把因果图转 换为状态图共五个步骤。 四、简答题（共37分） 1． 阶段评审与同行评审的区别。（4 分） 2 ． 什么是软件测试。（3 分） 通过人工或自动化手段对系统进行测试，目的是为了验证系统是否满足预定功能或者是为了弄清楚实际结果与预期结果之间的差别。 3 ． 简述集成测试的过程。（5 分） 将通过单元测试的单元模块按照设计要求组合起来再进行测试。重点检查程序接口处是否有问题。 过程：首先进行集成测试的测试计划61664;测试设计61664;测试开发61664;测试用例执行61664;测试评估，并且进行全程的缺陷跟踪。 4 ． 怎样做好文档测试？（4 分） 文档测试要注意一下几点：文档的读者群、文档的术语、文档的正确性、文档的完整性、文档的一致性、文档的易用性、样例与示例、文档的语言 5． 白盒测试有那几种方法？（6 分） 白盒测试方法分为：静态测试和动态测试 静态测试方法：①编码标准与准则 ②走查 ③审查 ④评审 动态测试方法：①语句覆盖 ②判定覆盖 ③条件覆盖 ④判定-条件覆盖 ⑤条件组合覆盖 ⑥路径覆盖 ⑦条件组合+路径覆盖 6． 系统测试计划是否需要同行评审，为什么？（4 分） 系统测试计划需要进行同行评审，因为如果对一个系统长时间进行测试可能会出现测试疲劳甚至出现 对系统的免疫现象，因此可以进行同行评审，减少对相同系统的疲劳测试。 7． Alpha 测试与beta 测试的区别。（4 分） 8 ． 比较负载测试、容量测试和强度测试的区别。（6 分） 9 ． 测试结束的标准是什么？（3 分）

第一题：我认为需要在测试前需要先写好测试计划，其中最重要的是本次测试使用的测试方法、使用的测试工具、测试环境。人员方面需要进行人员及进度的安排，每个测试阶段后的输出工件，还要有风险评估。在测试前将这些准备工作做到位，这样在测试的时候就会比较有条理。 第二题：控制测试质量，我认为最好是做好测试用例的设计，这样可以对测试的覆盖率进行控制。补充：如果时间充裕的话可以在设计用例后对其进行评审，这样可以提高测试质量。不过这个在实际的工作当中一般实现不了。。。。下面列出的是网上的一个软测笔试题，好多单位在笔试的时候都会copy下来作为笔试题，我至少遇到两次了，其他的笔试题还有，但不一一列出了。 一、判断题（每题1分，12 分，正确的√，错误的╳） 1．测试的目的是尽可能多的找出的缺陷。（） 2．Beta 测试是验收测试的一种。（） 3．验收测试是由最终用户来实施的。（） 4．项目立项前测试人员不需要提交任何工件。（） 5．单元测试能发现约80%的缺陷。（） 6．代码评审是检查源代码是否达到模块设计的要求。（） 7．自底向上集成需要测试员编写驱动程序。（） 8．负载测试是验证要检验的系统的能力最高能达到什么程度。（） 9．测试人员要坚持原则，缺陷未修复完坚决不予通过。（） 10．代码评审员一般由测试员担任。（） 1 11．我们可以人为的使得不存在配置问题。（） 12．集成测试计划在需求分析阶段末提交。（） 二、不定项选择题（每题2 分，10分） 1．验收测试的合格通过准则是：（） A． 需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求。 B． 所有测试项没有残余一级、二级和三级错误。 C． 立项审批表、需求分析文档、设计文档和编码实现一致。 D． 验收测试工件齐全。 2．测试计划评审会需要哪些人员参加？（） A．项目经理 B．SQA 负责人 C．配置负责人 D．测试组 3．下列关于alpha 测试的描述中正确的是：（） A．alpha 测试需要用户代表参加 B．alpha 测试不需要用户代表参加 C．alpha 测试是系统测试的一种 D．alpha 测试是验收测试的一种 4．测试设计员的职责有：（） A．制定测试计划 B．设计测试用例 C．设计测试过程、脚本 D．评估测试活动 5．实施活动的进入准则是：（） A．需求工件已经被基线化 B．详细设计工件已经被基线化 C．构架工件已经被基线化 D．项目阶段成果已经被基线化 三、填空题（每空1分，24 分） 1．验收测试包括(正式验收测试)、(非正式验收测试和Alpha测试)、(Beta测试)三种类型。 2．系统测试的策略有功能测试、（性能测试）、（负载测试）、（压力测试）、易用性测试、（容量测试）、（强度测试）、 （兼容性测试又称）、（本地化测试）、（BVT测试）、（裸机测试）、（安全性测试）、（）、（容错性测试）、（恢复测试）、（）等15 种方法。 3．设计系统测试计划需要参考的项目文档有（需求规格说明书）、（）和迭代计划。 4．对面向过程的系统采用的集成策略有（）、（）两种。 5．通过画因果图来写测试用例的步骤为、、、及把因果图转 换为状态图共五个步骤。 四、简答题（共37分） 1． 阶段评审与同行评审的区别。（4 分） 2 ． 什么是测试。（3 分） 通过人工或自动化手段对系统进行测试，目的是为了验证系统是否满足预定功能或者是为了弄清楚实际结果与预期结果之间的差别。 3 ． 简述集成测试的过程。（5 分） 将通过单元测试的单元模块按照设计要求组合起来再进行测试。重点检查程序接口处是否有问题。 过程：首先进行集成测试的测试计划61664;测试设计61664;测试开发61664;测试用例执行61664;测试评估，并且进行全程的缺陷跟踪。 4 ． 怎样做好文档测试？（4 分） 文档测试要注意一下几点：文档的读者群、文档的术语、文档的正确性、文档的完整性、文档的一致性、文档的易用性、样例与示例、文档的语言 5． 白盒测试有那几种方法？（6 分） 白盒测试方法分为：静态测试和动态测试 静态测试方法：①编码标准与准则 ②走查 ③审查 ④评审 动态测试方法：①语句覆盖 ②判定覆盖 ③条件覆盖 ④判定-条件覆盖 ⑤条件组合覆盖 ⑥路径覆盖 ⑦条件组合+路径覆盖 6． 系统测试计划是否需要同行评审，为什么？（4 分） 系统测试计划需要进行同行评审，因为如果对一个系统长时间进行测试可能会出现测试疲劳甚至出现 对系统的免疫现象，因此可以进行同行评审，减少对相同系统的疲劳测试。 7． Alpha 测试与beta 测试的区别。（4 分） 8 ． 比较负载测试、容量测试和强度测试的区别。（6 分） 9 ． 测试结束的标准是什么？（3 分）