软件测试工作流程图
软件测试中的决策树与流程图设计
软件测试中的决策树与流程图设计软件测试是保证软件质量的重要环节，而在软件测试中，决策树和流程图是两个常用的工具，用于设计测试用例和规划测试流程。
本文将介绍软件测试中的决策树和流程图设计，以及它们在测试中的应用。
一、决策树设计决策树是一种基于树状结构的图形模型，用于描述对象在决策过程中的选择序列。
在软件测试中，决策树可以被用于设计测试用例，指导测试人员进行测试。
决策树的根节点表示一个初始决策，每个分支代表一个选择分支，叶子节点表示一个终止决策。
在设计决策树时，需要根据被测试软件的规格说明书或需求文档，识别出各种可能的情况和决策点，并逐步细化构建决策树。
以网上购物为例，我们可以设计一个简单的决策树，如下所示：```开始购物├─ 是否登录？│ ├─ 是── 已购物？│ │ ├─ 是── 查看订单│ │ └─ 否── 添加至购物车│ └─ 否── 请先登录```通过这个决策树，我们可以得到一系列的测试用例，例如测试已登录用户的查看订单功能、未登录用户的添加至购物车功能等。
二、流程图设计流程图是一种用于描述流程、步骤和决策的图形工具。
在软件测试过程中，流程图可以被用于规划测试流程，指导测试人员按照预定的流程进行测试。
常见的流程图有活动图、状态图、顺序图等。
在软件测试中，我们通常使用活动图来表示测试流程，其中每个节点代表一个活动，节点之间的连线表示活动之间的关系。
以登录功能测试为例，我们可以设计一个简单的活动图，如下所示：```开始├─ 输入用户名和密码├─ 点击登录按钮│ ├─验证用户名是否存在│ │ ├─ 存在── 验证密码是否正确│ │ └─ 不存在── 提示用户用户名不存在│ └─ 验证通过── 登录成功```通过这个流程图，我们可以清晰地看到登录功能测试的步骤和决策点，测试人员可以按照这个流程图执行相应的测试。
三、决策树与流程图的应用决策树和流程图设计对于软件测试具有重要的作用，它们可以帮助测试人员全面而系统地进行测试。
测试作业流程及标准规范
1目标侧重测试工作步骤及规范控制，明确产品研发各阶段测试组应完成工作。
测试技术和策略等问题不在本文档描述范围内。
本规范作为全部测试组成职员作前必需掌握工作规范，也供给其它部门其它组查阅参考，方便于组间协调沟通，愈加好合作完成产品研发工作。
2概念和术语在整个产品研发过程中，测试类型根据前后次序关键分为：单元测试、集成测试、系统测试及产品确定，整个过程以下面W模型所表示：图1相关测试类型概念以下：1）单元测试：验证产品中模块，测试依据关键为模块具体设计或模块需求规格。
能使问题及早暴露，也便于问题定位处理，单元测试属于早期测试，所以错误发觉后能明确知道是某一单元产生，单元测试允很多个被测单元测试工作同时开展。
依据企业研发步骤实际情况，此测试也可由设计研发人员实施。
2）集成测试是验证模块间接口及匹配关系，测试依据关键为概要设计。
通常采取自底向上或自顶向下模块集成方法，逐步集成。
在此步骤中测试组还负责验收研发人员提供转测试材料，假如材料不完备，测试组能够拒绝接收。
3）系统测试是对系统一系列整体、有效性、可靠性测试，测试依据关键为设计规格及产品需求规格。
目标是确定产品和设计规格、需求、行业标准及企业标准符合性，同时还要确定性能和系统稳定性，和之前集成测试应遵照“相同被测对象不要做两遍相同测试”基础标准。
4）除单元测试、集成测试和系统测试之外，还应有“产品确定”步骤，即在用户环境中或模拟用户环境测试和验证产品，在有限试用用户中或模拟用户环境中发觉产品问题并加以妥善处理，确保产品质量，提升用户满意度。
确定和试验室内部测试区分在于：试验室内部测试要尽可能多做，多发觉问题；确定要在达成质量目标情况下尽可能少做；二者要在质量和成本之间权衡、综合考虑。
5）TD：全称Mercury TestDirector，一个测试管理工具。
6）黑盒测试：黑盒测试也称功效测试，它是经过测试来检测每个功效是否全部能正常使用。
在测试中，把程序看作一个不能打开黑盒子，在完全不考虑程序内部结构和内部特征情况下，在程序接口进行测试，它只检验程序功效是否根据需求要求正常使用，程序是否能合适地接收输入数据而产生正确输出信息。
软件测试流程图案例
软件测试流程图案例在线购物场景测试:第一步:确定基本流和备选流第二步:确定场景场景流的组合场景1—成功购物基本流场景2---账号不存在基本流备选流1 场景3---账号或密码错误基本流备选流2 场景4---余额不足基本流备选流3 场景5---账号没有钱基本流备选流4第三步:设计用例(v:有效;I:无效;n/a:不相干)输入用例场景/条件预期结果编号账号密码余额1:成功购物成功购物 1 V V V2:账号不存在提示账号不存在 2 I n/a n/a3:账号或密码错误(账提示账号或密码错误，返回到3 V I n/a 号正确，密码错误) 基本流步骤33:账号或密码错误(账提示账号或密码错误，返回到4 I V n/a 号错误，密码正确) 基本流步骤3提示账号余额不足请充值，充4:余额不足 5 V V I 值后返回到基本流步骤4 提示用户绑定银行卡或充值，5:账号没有钱 6 V V I 充值后返回到基本流步骤4第四步:设计数据，填入用例表(前置条件:所购商品价格150元) 假设Sue是注册用户，密码1s2，余额200;Jim未注册用户;Sun是注册用户，密码1234;Van是注册用户，密码1v2，账号余额1;Tom是注册用户，密码123，余额为0;用例输入场景/条件预期结果编号账号密码余额1:成功购物成功购物 1 Sue 1s2 2002:账号不存在提示账号不存在 2 Jim -- --3:账号或密码错误(账提示账号或密码错误，返回3 Sun 12345678 -- 号正确，密码错误) 到基本流步骤33:账号或密码错误(账提示账号或密码错误，返回4 Sunny 1234 -- 号错误，密码正确) 到基本流步骤3提示账号余额不足请充值，4:余额不足 5 Van 1v2 1 充值后返回到基本流步骤4课堂练习:旅馆住宿系统房间网上预订业务• 需求:游客访问网站进行网上房间预订操作，选择合适的房间后，进行在线预订;此时，需使用个人账号登录系统;待登录成功后，进行订金支付(订金额为1天的房款);支付成功后，生成房间预订单，完成整个房间预订流程。
冒烟测试流程图和测试数据准备
冒烟测试流程图和测试数据准备
冒烟测试：冒烟测试的对象是每⼀个新编译的需要正式测试的软件版本，⽬的是确认软件基本功能正常，可以进⾏后续的正式测试⼯作。
测试⽤例设计：进⼊测试⽤例编写阶段不要着急进⾏⽤例编写，先完全熟悉产品说明书和UI原型，进⾏测试⽤例设计，将测试⽤例和UI 原型描述不清除，或者按照当前流程往下⾛⽆法进⾏（如：UI原型上某个数据不知道来源，或者某个数据⽆法进⼊系统），要详细记录这种情况并反馈给项⽬负责⼈，并询问清除，清除之后进⾏测试⽤例设计（不⽤写测试步骤，需要确定测试⽤例的级别，设计范围包括全部功能）
测试⽤例补全：按照之前的测试⽤例设计进⾏测试⽤例补全（冒烟：⾼：低= 1.5:4.5:4）
冒烟测试流程：将业务流程和数据流标清除（业务流和数据流的箭头最好分开），只需要进⾏主要功能的冒烟（主流程）
冒烟测试数据：最好据有差异性，具有代表性（不要只是为了计算⽅便进⾏构造数据）
冒烟测试结果：只要主流程能够继续往下⾛，继续进⾏冒烟测试。
如果某个流程卡住了，⽆法进⾏下⼀步操作，冒烟测试不通过。
软件业务流程图
软件业务流程图软件业务流程图是指对软件业务进行流程分析和建模的图形工具，主要用于描述软件开发、测试、运维等各个环节的流程和其之间的关系。
下面我们来简要介绍一下软件业务的主要流程。
软件业务流程图由多个环节组成，包括需求分析、设计、开发、测试、上线和运维等各个环节。
下面是一个典型的软件业务流程图：1. 需求分析阶段：这个阶段主要是与客户进行沟通，了解客户的需求和业务需求。
包括需求收集、需求分析和需求确认等环节。
在此阶段，软件开发人员和客户之间进行多次会议和讨论，以明确客户的需求并制定需求规格文档。
2. 设计阶段：在这个阶段，软件开发人员将根据需求分析阶段的需求规格文档，设计软件的整体架构、模块划分以及数据存储结构等。
这其中包括系统架构设计、数据库设计和界面设计等环节。
3. 开发阶段：在开发阶段，开发人员将根据需求规格文档和设计文档进行编码和调试。
这个阶段是整个软件开发过程中最为关键的一环，它决定了软件的质量和性能。
开发阶段包括编码、调试和单元测试等环节。
4. 测试阶段：在测试阶段，测试人员对开发完成的软件进行测试，主要目的是发现软件的缺陷和问题。
测试阶段包括功能测试、性能测试、安全测试和兼容性测试等环节。
5. 上线阶段：在上线阶段，软件开发人员将已经通过测试的软件部署到生产环境中。
在这个阶段，还需要进行一些准备工作，例如数据库的初始配置、服务器的部署和网络的连接等。
6. 运维阶段：一旦软件上线运行，就需要进行日常的运维工作。
运维工作主要包括监控系统的状态、定期备份数据、处理用户反馈和解决问题等。
上述流程只是一个典型的软件业务流程，在实际应用中可能会根据具体的项目需求进行适当的调整和优化。
在软件开发过程中，流程图可以帮助开发人员更加清晰地了解整个业务流程，并及时发现和解决问题，从而提高软件开发效率和质量。
常见的软件研发基本流程图
模型图模型名称测试介入点测试范围优点瀑布模型全部代码编写完后整个软件产品1、测试成本低2、测试范围小3、简单、高效螺旋模型1、一个功能代码完成后，进行单元测试2、一个模块代码完成后，进行集成测试3、产品全部功能完成后，进行系统测试1、单元测试--代码2、集成测试--接口3、系统测试--整个软件产品1、应对变更和风险能力强2、测试介入时间早3、测试较充分4、软件质量有所提高和改善RUP模型（Rationalunified process ）Rational统一开发过程每个阶段编码完成后每个阶段业务建模时定义的功能范围+上一阶段完成的所有功能1、将系统进行分解，简化了测试的难度2、每个阶段提交个半成品a、提高客户的信心b、控制变更范围c、可以提早进行变更IPD模型（Integration product development）集成产品开发过程1、硬件研发完成后--硬件测试2、软件研发完成后--软件测试1、硬件2、软件所有部门的数据都进行了充分的数据共享，提高了决策的准确性常见的软件研发基本流程图缺点适用范围1、测试介入晚，发现缺陷较晚，软件质量不可控2、上有成果物未完成时下游的人力资源闲置3、简单、高效1、项目小2、需求明确3、公司规模小1、需要专业的风险识别专家2、成本高与人的生命和财产相关的系统需要专业的软件构架师不适合功能模块联系较紧密的系统管理成本较高大型的软硬件集成厂商。
软件测试的基本流程
软件测试的基本流程软件测试的基本流程软件测试和软件开发⼀样，是⼀个⽐较复杂的⼯作过程，如果⽆章法可循，随意进⾏测试势必会造成测试⼯作的混乱。
为了使测试⼯作标准化、规范化，并且快速、⾼效、⾼质量的完成测试⼯作，需要制订完整且具体的测试流程。
软件测试的流程不同类型的软件产品测试的⽅式和重点不⼀样，测试流程也会不⼀样。
同样类型的软件产品，不同公司所指定的测试流程也会不⼀样。
虽然不同软件的详细测试步骤不同，但它们所遵循的最基本的测试流程是⼀样的：分析测试需求-制定测试计划-设计测试⽤例-执⾏测试-编写测试报告。
下⾯对软件测试基本流程进⾏简单介绍。
（1）分析测试需求测试⼈员在制订测试计划之前需要先对软件需求进⾏分析，以便对要开发的软件产品有个清晰的⼈认识，从⽽明确测试对象及测试⼯作的范围和测试重点。
在分析测试需求时还可以获取⼀些测试数据，作为测试计划的基本依据，为后续的测试打好基础。
测试需求分析其实也就是对软件需求进⾏测试，测试⼈员可以发现软件需求中不合理的地⽅，如需求描述是否完整，准确⽆歧义，需求优先级安排是否合理等。
测试⼈员⼀般会根据软件开发需求⽂档制作⼀个软件需求规格说明书检查列表，按照各个检查项对软件需求进⾏分析校验如图所⽰上表列出了需要对软件需求进⾏什么样的检查，测试⼈员按照检查项逐条检查和判断，如果满⾜要求则选择【是】，如果不满⾜要求则选择【否】，如果某个检查项不适⽤则选择【NA】。
表1-3只是⼀个通⽤的软件需求规格说明检查列表，在实际测试中，要根据具体的测试项⽬进⾏适当的增减或修改。
在分析测试需求时要注意，被确定的测试需求必须是可核实的，测试需求必须有⼀个可观察，可评测的结果。
⽆法核实的需求就不是测试需求。
测试需求分析还要和客户进⾏交流，以澄清某些混淆，确保测试⼈员与客户尽早地对项⽬达成共识。
（2）指定测试计划测试⼯作贯穿于整个软件开发⽣命周期，是⼀项庞⼤⽽复杂地⼯作，需要制定⼀个完整且详细地测试计划作为指导。
软件测试的流程和注意事项
软件测试的流程和注意事项在软件开发的过程中，软件测试是一个至关重要的环节。
通过软件测试，可以保证软件质量的可靠性和稳定性，以及用户的满意度。
然而，软件测试并不是一件简单的事情，需要考虑的因素很多，包括测试流程、测试方法、测试工具等。
下面，就软件测试的流程和注意事项进行阐述。
一、软件测试的流程1.需求分析阶段：在这个阶段，测试人员需要认真了解产品的功能和需求，了解产品的特性和使用场景，考虑产品的用户群体和使用习惯。
测试人员需要借助一些工具和方法，如故事地图等，对需求进行细化和梳理，制作测试计划和测试用例。
2.测试计划阶段：在这个阶段，测试人员需要制定详细的测试计划，包括测试的内容、测试的目的、测试的时间、测试的环境、测试的人员等等。
测试人员需要按照预定的计划和步骤进行测试，确保测试覆盖率达到预期目标。
3.测试用例设计阶段：在这个阶段，测试人员需要依据需求和测试计划，设计全面、详细、精准的测试用例。
测试用例需要覆盖产品的所有功能和场景，考虑不同的使用方式和用户习惯。
测试用例需要经过反复的验证和修改，确保其可靠性和有效性。
4.测试执行阶段：在这个阶段，测试人员需要执行测试用例，对软件进行全面的测试。
测试人员需要认真记录测试结果和异常信息，并及时反馈给开发人员和相关负责人。
测试人员需要借助一些测试工具和方法，如自动化测试工具、压力测试工具等，提高测试效率和测试覆盖率。
5.测试报告阶段：在这个阶段，测试人员需要综合分析测试结果和异常情况，编制详细的测试报告，包括测试的整体情况、测试的覆盖率、测试的缺陷情况、测试的建议等。
测试报告需要传达给开发人员、项目经理、测试负责人等人，以便改进产品的质量和性能。
6.缺陷修复阶段：在这个阶段，开发人员需要分析测试报告中的缺陷和异常信息，进行修复。
测试人员需要对修复后的软件进行二次测试，验证是否已经解决了问题。
测试人员还需要对新的问题进行记录和反馈。
7.测试结束阶段：在这个阶段，测试人员需要汇总测试的所有结果和报告，进行总结和分析。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件开发与测试配合工作流程XXX软件股份质量部目录1．简介 (4)2．适用围 (5)3．术语、名词定义 (5)3.1 送测软件 (5)3.2 开发文档 (5)3.3 测试文档 (6)3.4 被测程序 (6)3.5 送测单 (6)3.6 BUG单 (6)3.7 测试循环 (7)4．参考文献 (7)5．测试与开发的配合 (7)5.1 文档和软件保存目录 (8)5.2 辅助工具的使用 (9)5.2.1 辅助测试系统1.0 (9)5.2.2 SourceSafe6.0 (10)5.3 开发与测试配合的流程 (11)6 . 送测单 (12)6.1送测单的填写 (13)6.2 工作流程 (15)7 ．BUG单 (16)7.1 BUG单的填写 (17)7.2 工作流程 (19)8 ．测试阶段的结束 (19)9 . 备注 (20)9.1 开发阶段与测试阶段 (20)9.2 待测模块的组合与测试原则 (21)9.3 BUG的分类评级原则 (21)9.4 国标中有关BUG数量的描述 (23)9.5 测试阶段的划分 (23)1．简介本流程文件旨在规定一个简单的可使开发人员和测试人员在软件开发的编码阶段相互配合工作的工作流程，其中包括测试与开发的配合、送测单和BUG单的填写、测试循环的结束等部分。
开发阶段与测试循环的关系、测试模块的组合与测试原则、BUG的分类评级原则等也在本流程文件中有相关的描述。
鉴于公司的技术要求，目前质量部的测试人员不仅要完成黑盒测试工作，而且还要进行白盒测试中的“代码走查”工作。
其它的白盒测试工作，目前还不在测试人员的工作职责之。
由于公司已经为质量管理部开发完成“辅助测试系统1.0”，因此本测试流程的制定就建立在辅助测试系统之上，如果辅助测试系统有了新的版本，质量部将根据其变化适当调整测试流程。
2．适用围本流程文件适用于公司开发软件并需要测试服务的任何软件开发项目组、软件开发人员，以及任何测试人员。
当项目组在辅助测试系统中注册以后，公司领导可以使用本系统查询了解所有在本系统中注册的项目的测试信息，项目的质量管理员可以使用本系统查询了解项目的当前测试进展情况。
程序员和测试员都可以使用本系统查询到自己产生的送测单和BUG单。
3．术语、名词定义3.1送测软件送测软件包括一切软件执行必须的文件、数据、数据库配置等。
开发人员必须提供所有的详细的资料以保证测试人员可以像客户一样的运行被测软件。
3.2开发文档开发人员提供给测试人员的开发文档至少包括以下几种：用户需求，概要设计，详细设计，用户手册等。
开发人员应当在开发每阶段完成后三天就向测试人员传送本阶段完成的开发文档，以利于测试人员的工作。
测试文档包括测试计划、测试用例说明、BUG报告及分析、测试总结，以及测试工作全部完成后的测试报告等。
测试文档由测试人员编写并维护，也属于开发文档的一部分。
3.4被测程序被测程序指的是开发人员提交测试的软件可执行的部分。
被测程序应当既包括单独的工程文件，以便测试人员进行代码走查工作；而且还要包括已经编译打包好的可执行文件。
3.5送测单送测单是指开发人员向测试人员提交被测软件时必须填写的提交报告。
开发人员应当谨慎填写送测单上的被测程序的版本号，保证和被测程序的版本号一致。
送测单必须有送测重点，以利于测试人员工作。
3.6 BUG单BUG单是指测试人员在测试完成后，向开发人员提交的BUG汇总报告。
开发人员确认并修改BUG后，必须填入修改意见并将BUG 单返回给测试人员以验证是否修改成功。
测试循环是指从软件单元/模块的第一次提交测试到本编码阶段结束中间经过的所有的有关的测试行为和过程。
其开始的标志是本阶段的第一份提交的送测单，其结束标志是测试总结或测试报告的提交和审批通过。
4．参考文献1.计算机软件测试文件编制规，GB 9386-882.<<客户机/服务器系统测试>>，（美）Bourne，K.C.著，机械工业，1998.5.3.软件开发规，航空工业标准6464-905．测试与开发的配合目前，质量部已经装备测试工作专用的工具“辅助测试系统1.0”，因此测试与开发的配合将结合此工具展开；并且质量部已经有自己专用的测试服务器，从而可以大体上做到测试与开发独立进行。
本文件中规定的流程就是按照这个思想形成。
由于目前公司自主开发的软件产品基本上都是基于客户机/服务器模式，因此，要做到测试与开发独立进行，只需要把软件用到的数据库分开安装到不同的服务器上就可以了，从而保证开发与测试不会产生数据冲突。
如果是采用B/S结构的软件，只需要在开发部的服务器上建立一个可执行包就可以了；在必要的情况下，也可同时在质量部服务器上建立可执行包。
在此系统的基础之上，又采取用Microsoft SourceSafe6.0来对开发文档和软件进行管理，从而减少了文档传递失误的机会，提高了测试自动化的程度，也降低了测试人员的工作量。
5.1 文档和软件保存目录公司目前采取的开发方式，用SourceSafe来对整个开发的产品来进行管理，因此对于测试人员来说，不必再单独对开发文档、软件模块进行复制和保存，测试服务器上的共享目录只是用于保存最终发行的软件产品。
共享目录在项目开始阶段由测试小组的负责人在质量部专用的测试服务器上建立，并由测试负责人在整个项目期间进行维护。
共享目录的容包括评审通过的最终软件（源代码和可执行文件）、各种开发文档（包括测试文档）。
最终的共享目录TsPrjName的结构如下所示：具体的建立规则如下：1．假设项目中文简称为PrjName, 则共享目录的名字必须是TsPrjName。
如项目简称为“宝开二期”，则共享目录的名字就是“Ts宝开二期”。
2．子目录“开发文档”用于存放开发人员传递到测试组的所有“完整的”开发文档，这里的“完整”指经过公司技术委员会评审确认的、能独立向所有使用者发行的文档。
当不同的文档使用人员对其容产生歧义时，都以这里保存的文档作为仲裁依据。
其二级子目录可以分为规格说明、需求分析、概要设计等等，由开发人员和测试人员商量决定。
3．子目录“最终软件”存放已经通过部评审的软件，如果软件是分为几个阶段开发的，并且每个阶段的产品都要发行给用户，则测试员必须备份每个阶段最终发行给用户的产品。
5.2 辅助工具的使用辅助工具目前有两个：辅助测试系统 1.0和Microsoft SourceSafe6.0。
5.2.1 辅助测试系统1.0辅助测试系统1.0是一个B/S系统，通过IExplorer访问，建立在质量部服务器上，由质量部维护，使用人员通过在IE地址栏中输入qa-bck/test/访问。
辅助测试系统的用户必须在该系统中具有用户账号，否则无法使用。
辅助测试系统中的使用人员共分为六种身份：测试主管，测试员，项目经理，程序员、领导和超级用户。
相同的用户账号只能具有一种身份，所有的用户只能由超级用户建立。
通过辅助测试系统，用户可以查阅到当前项目中程序员的送测信息和模块的送测情况，可以随时了解程序中仍然存在的BUG信息，并可以看到查询出来的信息的统计结果。
除了领导和超级用户身份以外，对于其它身份登陆的用户，系统具有自动提醒功能，既登陆后系统可以自动提醒用户现在需要处理的一些工作。
所以，要求处于测试中的程序的相关人员，如项目经理、程序员、测试主管和测试员等，每天都必须在不同时段登陆本系统至少三次以上。
5.2.2 Microsoft SourceSafe6.0使用SourceSafe6.0的主要作用在于能减少文档的传递次数，从而能有效的降低文档的不一致性，提高文档的及时性和有效性。
开发人员使用SourceSafe6.0可以保证所有人员包括测试人员看到的是同一个版本的文档，从而避免理解上的偏差。
SourceSafe6.0的服务器建立在开发部门的服务器上，由开发部门维护，测试人员对其数据库的访问由项目经理控制。
测试人员通过计算机上的SourceSafe客户端对服务器上的数据库进行访问。
测试人员在测试过程中形成的测试文档，也应当按照项目经理指定的目录保存在SourceSafe里面，这样既方便了同开发人员之间的交流，也使得所有项目产品有了一个统一的存放地点。
对SourceSafe中保存的其他开发文档和软件产品，原则上测试人员都只能读而不能写，比如对于文档和软件产品只能使用“get last version”命令来进行阅读，测试人员在得到这些产品以后，都不必再把它们放回去。
不同的测试人员只能对他/她自己负责测试的部分具有读的权利，对于其它项目的软件产品和文档，不具有访问的权利。
5.3 开发与测试配合的流程→开发人员在辅助测试系统中填写送测单，提交待测模块代码、可执行文件和相应的设计文档给项目经理确认。
→项目经理检查送测单上的容后，执行确认工作，并将打包好的可执行代码发布到开发部服务器的SourceSafe中（如果是B/S结构的软件，要把可执行代码发布到IIS上），将相关的数据库发布到质量部服务器上。
→测试人员接受送测单后，从SourceSafe中获得程序代码，开始测试。
测试包括两方面的容：一是代码走查工作，其次是功能测试工作。
→代码走查以公司下发的《编码规及管理办法》为检查依据。
如果在本次送测的某个模块中的代码走查中发现存在5个以上违反编码规的地方，则将该模块返回给程序员重新送测，本模块的测试结束，继续下一个模块的测试。
如果所有模块都不能通过代码走查工作，则本次测试全部结束，不必再进行下一步的功能测试。
→功能测试以公司下发的《质量部测试管理办法》为测试依据。
测试人员应当严格按照管理办法上的相关规定开展工作，并认真完成BUG纪录的填写。
完成测试后，将BUG单传递给测试主管确认。
→测试人员测试完成后，测试主管必须对BUG单执行“验证”过程，即检验BUG单上描写的BUG是否都是正确的。
验证完以后，测试主管将BUG单返回给程序员。
→程序员对BUG单上的所有纪录都必须认真处理后，再把BUG单连同修改完成的软件产品一起返回给测试员进行回归测试。
对于具体的使用辅助测试系统的开发与测试配合的工作流程可以参见《辅助测试系统使用手册》（由开发2部负责编写，预计会在8月初完成），也可以参见qa\wangl\软件测试\测试流程图\。
6. 送测单送测单用于开发人员向测试人员提交被测软件，由程序员填写并通过项目经理传递到测试人员。
在辅助测试系统中，已经将送测单的填写集成进去了，这里给出送测单的主要元素及其填写方法。
如果在辅助测试系统中的送测单的形式与这里列出的不同，请参考本文件的规定执行。
送测单的形式如下所示：送测单6.1送测单的填写其填写规则约定如下：1．项目名称、送测容、送测人和送测日期等四个字段由送测人填写。
送测容指的是本次送测的程序模块。