软件测试管理与实践-课程标准

软件测试管理与实践课程标准

课程名称：软件测试管理与实践

课程编号：

课程类别：理论（含实践）

适用专业：软件技术专业

学时：54

学分：3

一、课程的性质

本课程是计算机软件技术专业的专业课，其目标是让学生掌握测试管理技术，包括测试计划的制订、测试用例管理、测试执行、缺陷管理、测试总结分析等几个方面。通过本课程的学习，使学生能完成测试需求分析、计划制订、执行、总结等与企业实际工作相关的任务。

该课程以学习和掌握软件测试管理技术为教学目标。课程主要解决正确认识软件测试管理的机理、功能，并能够正确运用，将软件测试管理理论和工程实践有机结合并加以应用，达到对软件测试管理技术的全面掌握。通过开展实际软件项目包的测试过程中应用合理的测试管理技术。

该课程为学习是以掌握软件测试基础知识为必要的理论基础和实践基础，同时要求掌握一些常用的功能测试、性能测试方法为知识前提。培养目标是使学生能掌握在常用的测试管理技能，并为从事软件测试专业工作和职业规划具备持续发展能力。

本课程标准适用于软件技术专业软件测试管理课程的教学。

二、设计思路

测试管理课程设计的主要思路是以工作为载体，通过实际工作或模拟工作获取知识和经验，在整个课程中选择企业项目，形成工作小组，执行企业测试管理的整个过程和关键活动，项目组以项目为载体，项目成员以项目任务为载体，设计学习情境，反映出工作对象、工具、工作方法、组织方式和工作要求等具体内容。

依据教学对象对软件测试管理技术理论知识“必须”的原则，把握课程内容的系统完整性和运用特性，对软件测试管理涉及到的理论知识与技术运用作较深入地分析，保持专门性知识的相对完整和深度，为从事和完成软件测试管理所获得必要理论和实践的基础。

该课程为软件技术的专业课程，教学设计为实施理论实践一体化的方法。实践不仅作为对理论教学内容的实证，同时也是对理论知识具体运用，以达到对软件测试管理所涉及的原理、技术手段运用得到实际体验与深化理解。实践教学主要从软件测试管理工具应用于管理全过程为入手点，强调实际工具应用与理论理解相结合。

针对以上分析，课程的主线有三条：理论+工具+项目=实践。

图软件测试管理课程的三条主线

该课程标准以软件测试人才培养方案为依据而设计制定，在教学设计、考核设计方面的约束如下：

●教学设计为对网络型课程教学与资源管理系统的依赖和运用，并对实践教学环境与条

件的要求提出约束。该课程软件测试管理工具或平台可选用TestTrack Pro，ALM，

SilkPlan Pro，Jira等，但是工具的选择要与目前市场主流工具吻合。

●教学效果考核设计为多元结构，评价从小组讨论、作业、综合笔试、项目实践情况四

个方面考核，并设置权重比例。

●课程标准的内容关联软件评测师（国家人事部软件专业技术任职资格中级）的考试的

内容和部分要求，并基本涵盖考试的理论知识面和深度。

三、课程目标

本课程通过完成以项目为载体的工作任务，使学生掌握测试计划的制订、测试用例管理、测试执行、

测试总结分析等测试管理相关技术和工具。在项目实战中培养学生的设计能力、计划能力和执行能力，团队合作与沟通能力、自主学习与创新能力，为今后应用测试管理技术从事软件测试工作奠定坚实的基础。

本课程教学过程以学生为主体，以职业能力目标为核心，培养学生具备相应的专业能力、方法能力和社会能力。按职业能力的三个方面其具体目标如下：

1.专业能力

（1）能正确认识和深入理解软件测试管理全过程中的基本概念、工作原理和运用范围；

（2）能独立开展软件测试项目的需求、规划、设计、执行和结果分析；

（3）能正确使用测试管理工具及平台，并能具体运用和解决实际问题；

（4）能正确理解缺陷处理流程，并掌握一般及严重缺陷处理的一般方法；

（5）能正确理解合理建设测试团队几个要素、如何完善团队沟通机制；

（6）能借助工具完成测试中涉及到的资源管理、文档管理、用例管理等；

（7）达到软件评测师专业资格考试的基本理论知识和技能要求。

2.方法能力

（1）培养分析问题、解决问题的能力；

（2）培养制定工作计划并按照计划实施的能力；

（3）培养自主获取知识和技能的学习能力

（4）培养查找资料、文献等取得信息的能力

3.社会能力

（1）具有严谨的科学作风、踏实的工作态度、良好的职业道德以塑造良好的职业形象；

（2）具有较强的团队协作能力，自觉的规范意识和团队精神

（3）具有良好的口头和书面表达能力以及沟通交流能力

（4）具有一定的创新与创业能力

四、课程内容和要求

1、该课程学习预备知识与技能要求

a)计算机系统的知识

b)计算机网络系统的知识

c)操作系统知识及运用能力

d)熟练的程序设计（C/C++、Java、Web开发技术）与编码能力

e)软件测试基础知识

测试环境管理规范

软件测试环境重要性及意义稳定、可控勺测试环境，可使测试人员花费较少时间完成测试用例勺执行可保证每一个被提交勺缺陷被准确勺重现 ; 经过良好规划和管理勺测试环境，可以尽可能勺减少环境勺变动对测试工作勺不利影响， 1. 测试环境重要性及意义稳定、可控勺测试环境，可使测试人员花费较少时间完成测试用例勺执行可保证每一个被提交勺缺陷被准确勺重现 ; 经过良好规划和管理勺测试环境，可以尽可能勺减少环境勺变动对测试工作勺不利影响，并可以对测试工作勺效率和质量勺提高产生积极勺作用。 2. 测试环境搭建原则测试环境搭建之前，需要明确以下问题：所需计算机数量，以及对每台计算机勺硬件配置要求，包括存和硬盘勺容量、网卡所支持勺速度等 ; 部署被测应用勺服务器所必需勺操作系统、数据库管理系统、中间件、 WEB 服务器以及其他必需组件勺名称、版本，以及所要用到勺相关补丁勺版本 ; 用来执行测试工作勺计算机所必需勺操作系统、数据库管理系统、中间件、 WEB 艮务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本; 是否需要专门的计算机用于被测应用的服务器环境和测试管理服务器的环境的备份; 测试中所需要使用的网络环境 ; 执行测试工作所需要使用的文档编写工具、测试管理系统、性能测试工具、缺陷跟踪管理系统等软件的名称、版本、 License 数量，以及所要用到的相关补丁的版本。对于性能测试工具，则还应当特别关注所选择的工具是否支持被测应用所使用的协议 ; 测试数据的备份与恢复是否需要 ; 模拟实际生产环境或用户环境搭建。 3. 测试环境管理、设置专门勺测试环境管理员每条业务线或测试小组应配备一名专门勺测试环境管理员，其职责包括： u 测试环境搭建。包括操作系统、数据库、中间件、 WE 曲艮务器等必须软件的安装，配置，并做好各项安装、配置手册编写； u 记录组成测试环境的各台机器硬件配置、 IP 地址、端口配置、机器的具体用途，以及当前网络环境的情况；管理规范 CPUl 勺速度、内

软件测试流程管理体系

测试体系建设与软件测试流程（初稿）

目录 1.目的3 2.范围3 3.测试过程描述4 3.1 测试流程图4 3.2 活动说明5 3.2.1 需求评审5 3.2.2 编写测试计划6 3.2.3测试用例设计8 3.2.4 测试用例执行9 3.2.5发布版本回归测试12 3.2.6版本迭代回归测试13 3.2.7 文档测试16 3.2.8 测试报告18 4.软件缺陷管理系统—禅道19 4.1 概述19 4.1.1 编写目的19

4.1.2 适用范围19 4.1.3 角色和职责19 4.1.4 禅道简介19 4.2 缺陷状态关系示意图20 4.3 缺陷流转的过程及处理20 4.3.1 基于禅道的项目/测试/Bug管理21 4.4 禅道项目管理流程图21 5.配置管理21 1.目的本文是对项目软件测试的指导性文件，对软件测试过程中所涉及到的测试理论、测试类型、测试方法、测试标准、测试流程及测试过程中涉及到的角色职责进行总体规范，以有效保证软件质量。 2.范围本文适用于所有软件测试人员。

3.测试过程描述 3.1 测试流程图需求规格说明书测试用例测试计划开发计划评审Checklist 需求评审会议评审通过评审测试版本发布执行测试用例部署测试环境提交缺陷报告修复缺陷确认缺陷是否验证缺陷不通过测试完成通过测试报告发布上线

3.2 活动说明 3.2.1需求评审 3.2.1.1目的从源头把握软件质量，并确保开发结果与实际需求相一致，分析需求实现的可能性，功能细节描述无二义，补充需求细节，确定项目周期和时间。 3.2.1.2角色与职责测试负责人：《需求规格说明书》的编写，以及软件开发过程中《需求规格说明书》的修正；评审人员：项目经理、开发人员、测试人员等项目干系人；评审《需求规格说明书》，从全面性、完整性、正确性、一致性、可靠性方面检查《需求规格说明书》，将需求缺陷Checklist提交给产品需求人员，在评审会议上讨论，确定为缺陷后，跟踪需求缺陷直至需求缺陷验证关闭。 3.2.1.3启动标准《软件需求规格说明书SRS》编写完成

软件测试管理规范

软件测试工作规范 1 目的统一公司所有项目的软件测试流程；提供一套适合公司所有项目并可裁减的软件测试工具； 2 范围本规范中单元测试适用于所有的JAVA项目；本规范中集成测试、系统测试和性能测试适用于所有项目。 3 测试阶段与软件开发阶段的对应关系 1 过程描述 1.1 单元测试活动该活动包括以下环节： ● 编写单元测试计划； ● 设计单元测试用例； ● 执行单元测试过程； ● 记录单元测试缺陷； ● 编写单元测试报告； 1.1.1 活动目的验证软件系统模块内功能、容错、界面和报表测试和桩模块、子模块之间的接口测试。 1.1.2 角色与职责 1.1.3 测试范围

● 单元模块的功能性测试 ● 单元模块内和模块之间的接口测试 ● 单元模块的容错性测试 ● 单元模块的界面测试 ● 单元模块内的权限 1.1.4 进入条件已经完成被测模块的编码工作 1.1.5 输入《详细设计说明书》 1.1.6 活动说明对于结构化的编程语言，程序单元指程序中定义的函数或子程序。单元测试是指对函数或子程序所进行的测试。对于面向对象的编程语言，程序单元指特定的一个具体的类或相关的多个类。单元模块之间的接口等。（1）开发人员依据详细设计编写单元测试计划和和单元测试用例，《详见junit使用说明》和《jprobe使用说明》，需详细描述该用例的输入、输出和预期结果等相关内容；（2）开发人员编写程序代码；（3）开发人员执行单元测试用例，并记录执行结果；（4）开发人员执行测试用例过程中发现的缺陷，必须提交到缺陷跟踪工具中；（5）开发组长完成单元测试后，编写单元测试分析报告，项目经理审核《单元测试分析报告》。 1.1.7 输出已通过回归测试、打标签单元级的代码《单元测试分析报告》 1.1.8 退出条件 ● 被测代码语句覆盖率满足单元测试计划中制定的代码覆盖率要求； ● 测试用例执行覆盖率应达100%； ● 《单元测试分析报告》通过评审；

软件测试的基本流程

一：软件测试的基本流程 1.熟悉需求 2.需求评审（测试人员，开发，需求参与）剔除需求中不合理的部分和一些无法实现的部分，有异议的地方，描述不清楚的地方。 3.编写测试计划 4.测试计划评审 5.测试分析 6.测试分析评审（交叉评审） 7.设计测试用例 8.编写测试用例 9.测试用例评审 10.冒烟测试 11.运行测试用例 12.提交BUG 13.回归测试 14.编写测试报告二：什么是冒烟测试冒烟测试，英文是Smoke testing。冒烟测试的名称可以理解为该种测试耗时短，仅用一袋烟功夫足够了。也有人认为是形象地类比新电路板功基本功能检查。任何新电路板焊好后，先通电检查，如果存在设计缺陷，电路板可能会短路，板子冒烟了。冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。三：什么是回归测试回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。回归测试包括两部分：函数本身的测试、其他代码的测试。在对被修改的函数重新测试。如果函数的设计功能没有变化，直接运行函数测试就可以了。如果修改了设计功能，则要根据增减的功能点，增加或删除测试用例。另外，还要完成白盒覆盖。函数代码的修改可能导致调用该函数的代码产生错误，所以需要测试其他代码。如果函数是私有函数并且未涉及到全局变量，应运行类测试，否则应运行工程测试。在函数列表中选择类测试或工程测试，编译运行测试工程，即可执行对其他代码的回归测试。四：测试报告包含的内容

软件测试流程及规范V1.1

二、各阶段具体流程 1.需求分析阶段立项需求调研编写/修改SRS 提交SRS SRS 审核审核是否通过达到要求提交最终版SRS 审核是否通过审核通过依据SRS ，项目整体计划，设计、编写《测试计划》和《测试设计》《测试计划》根据SRS 定义相应的测试需求报告，即制订测试的标准，以后所有的测试工作都将围绕着测试需求来进行，符合测试需求的应用程序即是合格的，反之即是不合格的；同时，还要适当选择测试内容，合理安排测试人员、测试时间及测试资源等。《测试设计》将测试计划阶段制订的测试需求分解、细化为若干个可执行的测试过程，并为每个测试过程选择适当的测试用例。进入概要设计阶段评审测试计划和测试设计优化测试计划、测试设计1.1步骤说明 1、需求定义基本完成，SRS 编写完成。 2、开评审会，由需求调研人员、开发组、设计组、测试组等人员对需求中不清楚、不完整、存在疑义的地方提出问题，相关人员解答并确认。 3、当评审未通过，直接打回，重新修改SRS ，问题解决后，重新提交评审。

4、当评审通过后，依据SRS，项目整体计划，设计、编写《测试计划》和《测试设计》，具体模板见附件。 5、开评审会，由开发组、设计组、测试组等人员对计划和设计中不清楚、不完整、存在疑义的地方提出问题。 6、当审批未通过，直接打回，优化测试计划、测试设计，问题解决后，重新提交评审。 7、审核通过后，进入下一阶段。 1.2测试通过打回标准 1.3、阶段的输出输入：最新SRS、项目计划输出：测试计划、测试设计 2、单元及集成测试流程

软件测试基础要点总结

软件测试基础要点总结软件测试基础要点总结从宏观的角度讲，软件测试过程一般可划分为单元测试、集成测试、验收测试和系统测试等几个主要测试阶段。 1.测试计划注意事项 1．测试计划不一定要尽善尽美，但一定要切合实际，要根据项目特点、公司实际情况来编制，不能脱离实际情况； 2．测试计划一旦制定下来，并不就是一成不变的，随着软件需求、软件开发、人员流动等发生变化，测试计划也要根据实际情况的变化而不断进行调整，以满足实际测试要求．3．测试计划要能从宏观上反映项目的测试任务、测试阶段、资源需求等，不一定要太过详细．测试原则 ①应尽早和不断地进行软件“测试”。 ②测试用例中，不仅要选择合理的输入数据，还要选择不合理的输入数据。③在开发各阶段应事先分别制定出相应的测试计划，在测试开始后应严格执行，防止随意性。④对发现错误较多的程序模块，应进行重点测试。⑤避免程序员测试自己的程序。 ⑥用穷举测试是不现实的，一般通过设计测试用例，充分覆盖所有条件或所有语句即可。⑦长期妥善保存测试计划、测试用例、出错统计和有关的分析报告。 2.测试用例文档测试用例文档通常是由简介和测试用例两部分组成：

简介部分编制了测试目的、测试范围、定义术语、参考文档等，这个与测试计划是一致的。测试用例部分逐一列出各个测试用例。测试用例（TestCase）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。测试用例部分测试用例通常包含的信息：用例标识和用例名称内容描述前提条件执行步骤预期结果评价准则用例设计人员和设计时间用例执行人员和执行时间其它内容3.软件缺陷缺陷的表现形式不仅体现在功能的失效方面，还体现在其他方面。主要类型有：①软件没有实现产品规格说明所要求的功能模块软件中；②出现了产品规格说明指明不应该出现的错误； ③软件实现了产品规格说明没有提到的功能模块； ④软件没有实现虽然产品规格说明没有明确提及但应该实现的目标； ⑤软件难以理解，不容易使用，运行缓慢，或从测试员的角度看，最终用户会认为不好。测试用例：以计算器为例 ①计算器的产品规格说明定应能准确无误地进行加、减、乘、除运算。如果按下加法键，没什么反应，就是第一种类型的缺陷；若计算结果出错，也是第一种类型的缺陷。②产品规格说明书还可能规定计算器不会死机，或者停止反应。如果随意敲键盘导致计算器停止接受输入，这就是第二种类型的缺陷。 ③如果使用计算器进行测试，发现除了加、减、乘、除之外还可以求平方根，但是产品规格说明没有提及这一功能模块。这是第三种类型的缺陷④在测试计算

测试管理工作思路 (2)

测试管理工作思路1引言随着信息化的深入，管理功能的软件产品的质量在保障银行的稳定、高效运转方面发挥着越来越重要的作用。作为提高软件产品质量的最重要手段，加强对软件产品的测试得到了各家银行的高度重视。随着信息化在农信的快速发展，科技中心对软件产品质量要求越来越高，软件产品由过去的地市为单位向全省大集中的方向发展，这样软件的一个小bug，可能会影响到全省范围，造成很大的负面影响。因此软件测试在整个软件生命周期中变得更加重要。 13年科技中心加大对测试工作的投入和重视程度。今年把测试工作作为开发科一项重要工作，加强测试管理与逐步建立完善的测试体系、流程和制度。具体工作内容如下： 2测试环境科技中心没有独立、完善和满足需求的测试环境。目前功能测试环境和开发环境混在一起，有时几个系统同时公用一套设备，这样很难保证测试的独立性和充分性；性能测试也缺少相应环境，很多项目的性能测试是在生产环境进行，这样当上线后，很难做到定期测试，做到预防；同时开发环境和测试环境混在一起，缺乏设备的管理和使用流程，造成设备利用不合理。基于以上问题，经过前期对环境设备的调研和分析，对环境做出了合理规划。分为开发环境、功能测试环境与性能测试环境。目前功能测试环境已梳理完毕，正在对不满足要求的环境进行迁移，但性能测试环境还不具备，已申请购入新设备，需要逐步完善功能测试与性能测试环境。建立工具环境：目前bug管理工具jira有独立的环境，但测试工具与常用工具软件还没有单独的环境存放，如性能测试工具loadrunner，jprofiler等，各版本的jdk，数据库软件、操作系统等。测试环境建设目标： ?提高测试效率，提高测试充分性，更好的保证系统质量； ?测试环境管理更加有序、高效、规范； ?更加合理安排资源，提高测试资源利用率，节约投资。

软件测试规范制度

安徽中杰测试管理规范序号版本编号修订内容修订人批准人发布时间 1 安徽中杰软件测试管理规范2015年7月20 日

1.目的本文是对项目软件测试的指导性文件，对软件测试过程中所涉及到的测试理论、测试类型、测试方法、测试标准、测试流程及测试过程中涉及到的角色职责进行总体规范，以有效保证软件质量。 2.范围本文适用于软件测试人员。 3.参考资料《缺陷管理规范》《测试执行规范》《文档测试指南》《项目测试计划模版》《测试用例设计规范》《功能测试用例模版》《集成测试用例模版》《项目测试报告模版》《自动化测试计划模版》《性能测试计划模版》

4.测试过程描述 4.1 测试流程图需求评审测试计划测试设计功能测试执行集成测试设计 /性能测试设计集成/性能测试文档测试项目总结

4.2 活动说明 4.2.1 需求评审 4.2.1.1目的从源头把握软件质量，并确保开发结果与实际需求相一致 4.2.1.2角色与职责需求人员：《需求规格说明书》的编写，以及软件开发过程中《需求规格说明书》的修正；评审人员：评审《需求规格说明书》，从全面性、完整性、正确性、一致性、可靠性方面检、查《需求规格说明书》，将需求缺陷提交给需求人员，并跟踪需求缺陷直至需求缺陷验证关闭。 4.2.1.3启动标准《需求规格说明书》编写完成

4.2.1.4工作流程图需求评审评审人员需求人员验证需求规格说明书评审完成对需求规格说明书评审发现需求缺陷修正需求规格说明书将需求缺陷提交给需求人员修正需求文档，并提交评审人员验证全部缺陷验证通过存在不通过的需求缺陷 4.2.1.5输入/输出输入：《需求规格说明书》输出：需求缺陷 4.2.1.6规范参见《文档评审指南》

软件测试基本流程与要求要求规范

软件测试基本流程与规范 1目标制定完整且具体的测试路线和流程，为快速、高效和高质量的软件测试提供基础流程框架。最终目标是实现软件测试规范化，标准化。 2测试流程说明

3测试需求分析测试需求是整个测试过程的基础；确定测试对象以及测试工作的范围和作用。用来确定整个测试工作（如安排时间表、测试设计等）并作为测试覆盖的基础。而且被确定的测试需求项必须是可核实的。即，它们必须有一个可观察、可评测的结果。无法核实的需求不是测试需求。所以我现在的理解是测试需求是一个比较大的概念，它是在整个测试计划文档中体现出来的，不是类似的一个用例或者其他. ·测试需求是制订测试计划的基本依据，确定了测试需求能够为测试计划提供客观依据； ·测试需求是设计测试用例的指导，确定了要测什么、测哪些方面后才能有针对性的设计测试用例； ·测试需求是计算测试覆盖的分母，没有测试需求就无法有效地进行测试覆盖； 3.1测试方法与规范 3.1.1测试方法随着软件技术发展，项目类型越来越多样化。根据项目类型应选用针对性强的测试方法，合适的测试方法可以让我们事半功倍。以下是针对目前项目工程可以参考的测试方法： ?β测试（beta测试）--非程序员、测试人员 β测试，英文是Beta testing。又称Beta测试，用户验收测试（UAT）。 β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。当开发和测试根本完成时所做的测试，而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员完成，不能由程序员或测试员完成。?α测试（Alpha测试）--非程序员、测试人员 α测试，英文是Alpha testing。又称Alpha测试. Alpha测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由该系统的程序员或测试员完成。在系统开发接近完成时对应用系统的测试;测试后，仍然会有少量的设计变更。这种测试一般由最终用户或其他人员来完成，不能由程序员或测试员完成。?兼容性测试 --测试人员兼容性测试是指测试软件是否可以成功移植到指定的硬件或者软件环境中，例如在B/S项目中各个不同浏览器之间的测试。 ?用户界面测试-UI测试--测试人员用户界面测试，英文是User interface testing。又称UI测试。用户界面，英文是User interface。是指软件中的可见外观及其底层与用户交互的部分（菜单、对话框、窗口和其它控件）。

软件测试环境管理规范

测试环境管理规范

修改履历修改编号版本修改条款及内容修改日期 1 V1.0 初稿

目录 1.概述 (5) 1.1目的 (5) 1.2适用范围 (5) 2.环境使用要求和原则 (5) 2.1环境使用要求 (5) 2.2环境使用原则 (5) 3.硬件环境 (6) 3.1全流程测试环境申请 (6) 3.1.1申请流程图 (6) 3.1.2申请流程说明： (6) 3.2待测系统环境申请 (7) 3.2.1申请流程图 (7) 3.2.2申请流程说明： (7) 3.3测试用机申请 (8) 3.3.1申请流程图 (8) 3.3.2申请流程说明： (8) 3.4硬件环境变更 (9) 3.4.1全流程测试环境变更流程图 (9) 3.4.2全流程测试环境变更流程说明： (9) 3.5硬件环境释放 (10) 3.5.1释放流程图 (10) 3.5.2释放流程说明 (10) 4.环境权限 (11) 4.1权限说明 (11) 4.1.1查询帐户 (11) 4.1.2监控帐户 (11) 4.1.3应用帐户 (11) 4.1.4备用帐户 (11) 4.1.5特殊帐户 (11) 4.2权限申请流程 (11) 4.2.1查询帐户申请流程 (11) 4.2.2监控帐户申请流程 (11)

4.2.3应用帐户申请流程 (12) 4.2.4备用帐户申请流程 (12) 4.2.5特殊帐户申请流程 (12) 4.3应用系统 (12) 4.3.1应用版本变更 (12) 应用版本部署 (12) 应用版本变更 (12) 4.3.2测试数据 (12) 测试数据预埋 (13) 测试数据变更 (13) 5.系统参数变更 (13) 5.1工作时段参数变更 (14) 5.1.1变更流程图： (14) 5.1.2变更流程说明： (14) 5.2非工作时段参数变更 (15) 5.2.1变更流程图： (15) 5.2.2变更流程说明 (15) 6.系统备份 (16) 6.1不定期备份 (16) 6.1.1备份说明 (16) 6.1.2备份流程 (16) 6.2特需备份 (16) 6.2.1备份说明 (16) 6.2.2备份流程 (16)

软件测试文档编制规范

文档编制规范

目录文档编制规范 (1) 一、文档的分类 (2) 二、文档的编号 (2) 三、文档编写的格式要求 (3) 3.1、页面布局 (3) 3.1.1、页边距 (3) 3.1.2、页眉页脚 (3) 3.2、首页标题及公司基本信息 (3) 3.3、目录 (4) 3.4、正文 (4) 3.4.1、正文内容 (4) 3.4.2、小标题级别 (4) 3.4.3、图片与表格 (5) 3.4.4、功能点与列表 (8) 3.5、附件 (8)

一、文档的分类将文档分成如下几类： 1、规章制度类（编号：GZZD）：公司、部门的各项规章制度； 2、工作规范类（编号：GZGF）：各部门的工作规范； 3、项目管理规范类（编号：XMGL）：项目管理规范、药监项目管理规范、招投标系统开发与实施指南等； 4、项目类文档（编号：XM）：包括项目各个过程的产出物，如合同（HT）、建设方案（FA）、需求文档（XQ）、设计文档（SJ）、操作手册（CZSC）、测试报告（CSBG）等； 5、体系类（ISO9001、ISO27001、CMMI3）； 6、知识类（编号：ZS）：各类技术经验总结等； 7、产品类（编号：产品名称缩写）：如OA、Mis平台、电子招投标产品的介绍资料/操作手册等 8、其他类（不需要编号）：上述7个类别之外的其它文档。二、文档的编号文档的编号是文档唯一标识，主要用于文档的检索和版本控制。文档编号规则如下：文档编号=文档所属部门代码+文档类别代码+文档流水号+版本号示例如下：例如：QYGL－GZZD －001V2.1

企业管理部说明： 1.部门代码为各部门的拼音首字母（公司的部门代码为GTXD）。部门编码示例：企业管理部－QYGL、人力资源部－RLZY、行政部－XZ、开发部－KF（子部门为KF1、KF2类推）、实施部－SS（子部门SS1、SS3类推）、测试部－CS等； 2.版本号使用2位数字进行声明，数字间使用英文标点“.”隔开。首位数字表示第几个版本，末尾数字表示版本内的第几次修改。例如：v1.0表示第一次正式发布的版本； v1.2，表示在第一次发布后进行第二次修改后的文档。 3.其它类的文档（各种表单、ppt等），无需编号、页眉页脚，如《培训记录表》等。 4.EXCEL类文档按WORD文档编号方式编号。 5.其他各类外来文件，包括各法律法规、技术标准和顾客资料等，均按各自的原本编号，也不需要另外修改。三、文档编写的格式要求 3.1、页面布局 3.1.1、页边距上下页边距：2.54厘米，左右页边距：3.17厘米（默认）。 3.1.2、页眉页脚页眉：加入公司logo图片左对齐；后面加上文档名称，用小五号宋体字（Times new Roman）；文件编号和版本号，如“GTXD-GZZD-001 V1.0”右对齐；页眉顶端距离0.8厘米。页脚：加入公司名称及联系方式居中；加入页码/总页数右对齐页面底部；用小五号宋体字（Times new Roman），页脚底端距离1.2厘米。首页如果是封页，则不显示页眉页脚。 3.2、首页标题及公司基本信息公司基本信息：顶格、两端对齐，以图片形式放置公司logo及公司基本信息。

软件测试管理规范

1.1.2角色与职责软件测试工作规范 1目的统一公司所有项目的软件测试流程；提供一套适合公司所有项目并可裁减的软件测试工具； 2范围本规范中单元测试适用于所有的JA V A项目；本规范中集成测试、系统测试和性能测试适用于所有项目。 3测试阶段与软件开发阶段的对应关系 1过程描述 1.1单元测试活动该活动包括以下环节： ● 编写单元测试计划； ● 设计单元测试用例； ● 执行单元测试过程； ● 记录单元测试缺陷； ● 编写单元测试报告； 1.1.1活动目的验证软件系统模块内功能、容错、界面和报表测试和桩模块、子模块之间的接口测试。

1.1.3测试范围 ● 单元模块的功能性测试 ● 单元模块内和模块之间的接口测试 ● 单元模块的容错性测试 ● 单元模块的界面测试 ● 单元模块内的权限 1.1.4进入条件已经完成被测模块的编码工作 1.1.5输入《详细设计说明书》 1.1.6活动说明对于结构化的编程语言，程序单元指程序中定义的函数或子程序。单元测试是指对函数或子程序所进行的测试。对于面向对象的编程语言，程序单元指特定的一个具体的类或相关的多个类。单元模块之间的接口等。（1）开发人员依据详细设计编写单元测试计划和和单元测试用例，《详见junit 使用说明》和《jprobe使用说明》，需详细描述该用例的输入、输出和预期结果等相关内容；（2）开发人员编写程序代码；（3）开发人员执行单元测试用例，并记录执行结果；（4）开发人员执行测试用例过程中发现的缺陷，必须提交到缺陷跟踪工具中；（5）开发组长完成单元测试后，编写单元测试分析报告，项目经理审核《单元测试分析报告》。 1.1.7输出已通过回归测试、打标签单元级的代码《单元测试分析报告》 1.1.8退出条件 ● 被测代码语句覆盖率满足单元测试计划中制定的代码覆盖率要求； ● 测试用例执行覆盖率应达100%；

软件测试工作流程()

软件开发与测试配合工作流程 XXX软件股份有限公司质量部目录 1．简介本流程文件旨在规定一个简单的可使开发人员和测试人员在软件开发的编码阶段相互配合工作的工作流程，其中包括测试与开发的配合、送测单和BUG单的填写、测试循环的结束等部分。开发阶段与测试循环的关系、测试模块的组合与测试原则、BUG的分类评级原则等也在本流程文件中有相关的描述。鉴于公司的技术要求，目前质量部的测试人员不仅要完成黑盒测试工作，而且还要进行白盒测试中的“代码走查”工作。其它的白盒测试工作，目前还不在测试人员的工作职责之内。由于公司已经为质量管理部开发完成“辅助测试系统1.0”，因此本测试流程的制定就建立在辅助测试系统之上，如果辅助测试系统有了新的版本，质量部将根据其变化适当调整测试流程。 2．适用范围本流程文件适用于公司开发软件并需要测试服务的任何软件开发项目组、软件开发人员，以及任何测试人员。

当项目组在辅助测试系统中注册以后，公司领导可以使用本系统查询了解所有在本系统中注册的项目的测试信息，项目的质量管理员可以使用本系统查询了解项目的当前测试进展情况。程序员和测试员都可以使用本系统查询到自己产生的送测单和BUG单。 3．术语、名词定义 3.1 送测软件送测软件包括一切软件执行必须的文件、数据、数据库配置等。开发人员必须提供所有的详细的资料以保证测试人员可以像客户一样的运行被测软件。 3.2 开发文档开发人员提供给测试人员的开发文档至少包括以下几种：用户需求，概要设计，详细设计，用户手册等。开发人员应当在开发每阶段完成后三天内就向测试人员传送本阶段完成的开发文档，以利于测试人员的工作。 3.3 测试文档测试文档包括测试计划、测试用例说明、BUG报告及分析、测试总结，以及测试工作全部完成后的测试报告等。测试文档由测试人员编写并维护，也属于开发文档的一部分。

软件测试管理规定V

金鼎文科技技术有限公司软件测试管理规定（版权所有，翻版必究）目录第一章引言 (2) 第一条测试概述 (2) 第二条测试目标 (3) 第三条适用范围 (4) 第二章测试职责 (4) 第三章需求分析 (5) 第四章测试策略 (6) 第四章测试计划 (7) 第五章测试用例 (7) 第一条测试用例设计方法 (7) 第二条测试用例操作步骤 (11) 第三条测试用例选择准则 (11) 第四条测试软/硬件环境 (11) 第五条测试数据准备 (11) 第六条测试执行过程绩效考核 (12) 第六章测试执行 (12)

第一条项目测试周期 (12) 第二条项目测试启动 (12) 第三条项目测试阶段 (12) 第四条项目测试结束 (13) 第五条测试执行过程绩效考核 (13) 第七章测试变更 (13) 第八章缺陷管理 (14) 第一节缺陷基本属性 (14) 第二节缺陷管理流程 (14) 第三节缺陷分类 (15) 第四节缺陷定义 (17) 第五节缺陷完成度 (18) 第六节处理机制 (18) 第九章测试结果分析 (19) 第一节测试完成的标准 (19) 第二节允许保留的缺陷 (19) 第十章测试输出文档 (20) 第一章引言第一条测试概述无论怎样强调软件测试的重要性和它对软件可靠性的影响都不过分。在开发大型软件系统的漫长过程中，面对着极其错综复杂的问题，人的主观认识不可能完全符合客观现实，与工程密切相关的各类人员之间的通信和配合也不可能完美无缺，因此，

在软件生命周期的每个阶段都不可避免地会产生差错。我们力求在每个阶段结束之前通过严格的技术审查，尽可能早地发现并纠正差错；经验表明审查并不能发现所有差错，此外在编码过程中还不可避免地会引入新的错误。如果在软件投入生产性运行之前，没有发现并纠正软件中的大部分差错，则这些差错迟早会在生产过程中暴露出来，那时不仅改正这些错误的代价更高，而且往往会造成很恶劣的后果。测试的目的就是在软件投入生产性运行之前，尽可能多地发现软件中的错误。目前软件测试仍然是保证软件质量的关键步骤，它是对软件规格说明、设计和编码的最后复审。软件测试在软件生命周期中横跨两个阶段。通常在编写出每个模块之后就对它做必要的测试(称为单元测试)，模块的编写者和测试者是同一个人，编码和单元测试属于软件生命周期的同一个阶段。在这个阶段结束之后，对软件系统还应该进行各种综合测试，这是软件生命周期中的另一个独立的阶段，通常由专门的测试人员承担这项工作。大量统计资料表明，软件测试的工作量往往占软件开发总工作量的40％以上，在极端情况，测试那种关系人的生命安全的软件所花费的成本，可能相当于软件工程其他开发步骤总成本的三倍到五倍。因此，必须高度重视软件测试工作，绝不要以为写出程序之后软件开发工作就接近完成了，实际上，大约还有同样多的开发工作量需要完成。仅就测试而言，它的目标是发现软件中的错误，但是，发现错误并不是我们的最终日的。软件工程的根本目标是开发出高质量的完全符合用户需要的软件。第二条测试目标下面这些规则也可以看作是测试的目标或定义： (1)测试是为了发现程序中的错误而执行程序的过程； (2)好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案； (3)成功的测试是发现了至今为止尚未发现的错误的测试。从上述规则可以看出，测试的正确定义是“为了发现程序中的错误而执行程序的

软件测试过程管理-考题

软件测试过程管理-考题-标准化文件发布号：（9456-EUATWK-MWUB-WUNN-INNUL-DDQTY-KII

一、软件测试过程管理 1. 关于软件测试模型，描述正确的是（C） A. V模型测试的对象就是程序本身，测试与开发可以同一阶段进行 B. W模型测试的对象是程序，需求、设计等，可以支持迭代的开发模型 C. H模型软件测试过程活动完全独立，贯穿产品整个生命周期,与其他流程并发地进行。 D. X模型是事先计划再进行测试。 2. 制定测试计划的步骤：（D） A. 确定项目管理机制预计测试工作量测试计划评审 B. 确定测试范围确定测试策略确定测试标准、预计测试工作量 C. 确定测试构架确定项目管理机制预计测试工作量测试计划评审 D. 确定测试范围确定测试策略确定测试标准确定测试构架确定项目管理机制预计测试工作量测试计划评审 3、编写测试计划的目的是：（ABC）(多选) A、使测试工作顺利进行 B、使项目参与人员沟通更舒畅 C、使测试工作更加系统化 D、软件工程以及软件过程的需要 E、软件过程规范化的要求 F、控制软件质量 4、某公司采用的软件开发过程通过了CMM2认证，表明该公司（C）。 A. 开发项目成效不稳定，管理混乱 B. 对软件过程和产品质量建立了定量的质量目标 C. 建立了基本的项目级管理制度和规程，可对项目的成本、进度进行跟踪和控制 D. 可集中精力采用新技术新方法，优化软件过程 5. (B )可以作为软件测试结束的标志。 A．使用了特定的测试用例B．错误强度曲线下降到预定的水平C．查出了预定数目的错误D．按照测试计划中所规定的时间进行了测试 6．软件测试计划的内容应包括（D）。 A. 测试目的、背景 B. 被测软件的功能、输入和输出 C. 测试内容和评价标准 D. 以上全部 7．下面不属于软件测试过程中的输入类的是(B)。 A. 软件配置 B. 测试用例 C. 测试配置 D. 测试工具 8. 下列不属于测试需求分析阶段的输入的是（A）。 A. 软件测试的方法与规范 B. 软件需求规格说明 C. 软件测试计划 D.软件设计说明

软件测试基础习题及答案范文

1、软件测试的定义？软件测试是一个过程或者一系列过程，用来确认计算和代码完成了其应该完成的功能，并且不执行其不应该有的操作。 2、软件测试的目标是什么？是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正各种错误和缺陷提高软件质量，降低软件发布后由于潜在的软件错误和缺陷造成的隐患所带来的商业风险。 3、简单描述一下软件测试的原则？所有的软件测试都应追溯到用户需求应当把“尽早地和不断地进行软件测试”作为测试者的座右铭 Good Enough原则质量第一充分注意测试中的群集现象程序员应避免检查自己的程序有据可依尽量避免软件测试的随意性，要有预期结果重视回归测试妥善保存一切测试过程文档 4、软件测试中验证和确认的区别？ Verfication 验证：是保证软件正确实现特定功能的一系列活动和过程。目的是保证软件生命周期中的每一个阶段的成果满足上一个阶段设定的目标。 Validation 确认：是保证软件满足用户需求的一系列的活动和过程。目的是在软件开发后保证与用户需求符合 5、软件测试按照测试的基本策略可分为哪两种并加以详细说明？白盒测试：白盒测试也称结构测试或逻辑驱动测试，是指基于一个应用代码的内部逻辑知识，即基于覆盖全部代码、分支、路径、条件的测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。

黑盒测试：黑盒测试是指不基于内部设计和代码的任何知识，而基于需求和功能性的测试，黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等，主要用于软件确认测试。 6、整个软件生命周期中，需要进行哪几项测试？单元测试、集成测试、系统测试、验收测试单元测试单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。因为单元测试需要知道内部程序设计和编码的细节知识，一般应由程序员而非测试员来完成，往往需要开发测试驱动模块和桩模块来辅助完成单元测试。因此应用系统有一个设计很好的体系结构就显得尤为重要。一个软件单元的正确性是相对于该单元的规约而言的。因此，单元测试以被测试单位的规约为基准。单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。集成测试集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。它根据集成测试计划，一边将模块或其他软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。集成测试的策略主要有自顶向下和自底向上两种。系统测试系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的“先知者问题”。因此，系统测试应该按照测试计划进行，其输入、输出和其他动态运行行为应该与软件规约进行对比。软件系统测试方法很多，主要有功能测试、性能测试、随机测试等等。验收测试验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。所不同的是，验收测试常常有软件系统的购买者代表在现场，甚至是在软件安装使用的现场。这是软件在投入使用之前的最后测试。

软件测试规范

软件测试标准规范 1目的为了确保软件产品质量，使产品能够顺利交付和通过验收，特编写本文档，以作参考 2适用范围本文档适用于项目开发过程中的单元测试、集成测试、系统测试、业务测试、验收测试以及一些专项测试。 3职责项目测试负责人组织编制《测试计划》、《测试方案》，指导和督促测试人员完成各阶段的测试工作。项目组测试人员按照《测试计划》、《测试方案》完成所承担的测试任务，并按要求填写《问题报告及维护记录》。测试经理依照确认规程和准则对工作产品进行确认，提出对确认规程和准则的修改意见项目负责人组织测试环境的建立。项目经理审核负责控制整个项目的时间和质量。研发人员确认修改测试人员提交的bug。 4工作流程 4.1 测试依据详细设计是模块测试的依据。因此设计人员应向测试人员提供《系统需求规格书名书》、《详细设计》、《概要设计》等有关资料。测试人员必须认真阅读，真正弄懂系统需求和详细设计。 4.2 制订《测试方案》

在测试之前，由项目负责人根据《测试计划》的要求，组织人员编制相应的《测试方案》，《测试方案》应包括以下内容：测试目的；所需人员及相应培训要求；测试环境、工具和测试软件；测试用例、测试数据和预期的结果。 4.3 单元测试项目开发实现过程中，每个程序单元（程序单元的划分视具体开发工具而定，一般定为函数或子程序级）编码调试通过后，要及时进行单元测试。单元测试由单元开发者自己进行，使用白盒测试方法，根据程序单元的控制流程，争取达到分支覆盖。对于交互式运行的产品，不便于进行自动测试的，可以采用功能测试的方法进行。单元测试针对程序模块，从程序的内部结构出发设计测试用例。多个模块可以独立进行单元测试。单元测试内容包括模块接口测试、局部数据结构测试、路径测试、错误处理测试等；单元测试组织原则一遍根据开发进度安排对已开发完成的单一模块进行测试；单元测试停止标准：完成了所有规定单元的测试，单元测试中发现的bug已经得到修改。 4.4 集成测试编码开发完成，项目组内部应进行组装测试。集成测试由项目负责人组织策划（编写测试计划、测试用例）并实施。集成测试着重对各功能模块之间的接口进行测试，验证各功能模块是否能协调工作、参数传递及功能调用是否正常。测试采用交叉方法，即个人开发的软件应由其他的项目组成员进行测试。集成测试过程应填写《问题报告及维护记录》，测试结果应形成《测试报告》。 4.5 系统测试

软件测试过程和管理(二)

[模拟] 软件测试过程和管理(二) 选择题第1题：下列哪个不是测试环境的组成要素______。 A.软、硬件 B.技术文档 C.测试工具 D.网络环境参考答案：B 第2题：以下活动中，不属于测试计划的内容是______。 A.为测试各项活动制定一个实现可行的综合的计划 B.确定测试过程中每个测试阶段的测试完成标准 C.识别测试活动中各种风险，并给出风险应对措施 D.分析测试需求，并制定测试方案参考答案：D 第3题：下列有关测试过程抽象模型的描述中正确的是______。 A.V模型指出，软件测试要尽早准备，尽早执行，只要某个测试达到了准备就绪点，测试执行活动就可开展 B.W模型强调，测试伴随着整个软件开发周期同步进行，而且测试的对象不仅仅是程序，需求、设计也同样需要测试 C.H模型指出，单元测试和集成测试应检测程序的执行是否满足软件设计的要求 D.X模型提出针对完整的程序进行集成的编码和测试参考答案：B 第4题：下列哪个选项不属于测试计划要达到的目标______。 A.为测试各项活动制定一个现实可行的、综合的计划，包括每项测试活动的

对象、范围、方法、进度和预期结果 B.为项目实施建立一个组织模型，并定义测试项目中每个角色的责任和工作内容 C.为测试执行活动设计测试方案，编制测试用例 D.确定测试需要的时间和资源，以保证其可获得性和有效性参考答案：C 第5题：下列有关软件测试设计的说法中，正确的是______。 A.测试方案应考虑是否可行、是否有效和是否能够达到预期的测试目标 B.基于判定表的测试用例设计方法是白盒测试用例设计方法 C.测试方案设计中可以忽略软件系统的实际使用环境 D.测试开发不是测试用例设计的工作内容参考答案：A 第6题：下列有关测试项目结束与定稿测试报告的说法中，正确的是______。 A.测试执行完成，测试人员向测试负责人提交测试报告后，测试项目就可以结束了 B.对当前软件产品存在的缺陷进行逐个分析，认定剩余缺陷对产品质量无重大影响后，即可定稿测试报告 C.审查测试全过程，检查测试计划和内容无遗漏后，即可定稿测试报告 D.当所有测试计划内容完成，测试覆盖率达到要求及产品质量达到定义的标准，即可定稿测试报告参考答案：D 第7题：下列哪项工作与软件缺陷管理和追踪无关______。 A.对缺陷应该包含的信息条目、状态分类等进行完善设计 B.通过软件系统自动发送通知给相关开发和测试人员，使缺陷得到及时处理 C.对测试用例的执行结果进行记录和追踪 D.通过一些历史曲线和统计曲线来分析和预测未来的缺陷发展情况参考答案：C

软件测试规程

编号：SYD/CMM-STP 软件CMM规范之―― 软件测试规程 V1.0.0

前言软件测试是保证软件质量的重要手段，软件测试规程规范了公司软件测试及测试管理流程，结合公司在测试过程中所采用的方法、工具等，检查、验证开发工作产品，确保公司的产品： 1.满足用户对软件产品定义的需求； 2.产品文档满足软件CMM规范及用户需求； 3.产品中软件代码的错误降到最少； 4.产品运行的稳定性、可用性良好。

修订页

目录 1.目的 (1) 2.适用范围 (1) 3.定义 (1) 4.职责 (1) 5.测试分类 (2) 6.使用工具 (3) 7.流程图 (4) 8.测试过程管理 (5) 8.1 测试计划制订及管理 (6) 8.1.1任务描述 (6) 8.1.2工作内容 (6) 8.1.3工作产品 (6) 8.1.4裁剪指南 (6) 8.2 测试用例设计及管理 (7) 8.2.1任务描述 (7) 8.2.2工作内容 (7) 8.2.3工作产品 (8) 8.2.4裁剪指南 (8) 8.3 测试程序设计和管理 (8) 8.3.1任务描述 (8) 8.3.2工作内容 (8) 8.3.3工作产品 (9) 8.3.4裁剪指南 (9) 8.4 BUG管理 (9) 8.4.1任务描述 (9) 8.4.2工作内容 (9) 8.4.3工作产品 (11) 8.1.5裁剪指南 (11) 8.5 测试分析报告编写及管理 (11) 8.5.1任务描述 (11) 8.5.2工作内容 (12) 8.5.3工作产品 (12) 8.5.4裁剪指南 (12) 8.6 单元测试 (12) 8.6.1任务描述 (12) 8.6.2工作内容 (12) 8.6.3工作产品 (13) 8.6.4裁剪指南 (13)