项目软件测试流程及规范Word文档下载推荐.docx
《项目软件测试流程及规范Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《项目软件测试流程及规范Word文档下载推荐.docx（17页珍藏版）》请在冰豆网上搜索。
系统规格书：
依据业务需求说明书，规定需求实现的逻辑与流程，以及涉及的表结构、字段类型，囊括模块流程图、模块之间的关系、业务流程说明、实现过程、数据表等关键要素。
软件需求说明书：
以简练、准确、无歧义描述语言，描述软件需求，是软件测试的关键文档，也是编写测试列表、测试案例的基础文档。
模测问题：
模拟生产环境测试过程中所发现的项目软件缺陷或者功能没有实现等问题。
生产问题：
生产环境中业务人员发现的项目软件缺陷或者功能没有实现等问题
静态问题：
项目文档中，错误或者不规范的流程图、不合理、错误或者的描述等体现在文档中的问题。
有效问题：
测试问题提出后，经过编码人员修改，最终被修改验证通过的问题。
二、业务需求阶段
1、考核指标
业务需求理解处于项目立项阶段，需求理解的程度将直接影响后续阶段。
本阶段考核指标将体现在后续阶段中：
编写项目相关文档的质量、测试的执行力、程序派错率、遗漏的问题数等。
2、本阶段工作流程
1．业务部门在生产过程中面向XX客户提出的使用需求，整理成书面文档，汇总后将需求提交至XXX，同时提出软件功能需求。
2．XXX从全国各业务部门（含海外地区）上报的需求，下发XXX所属的各研发部。
3．各研发部从XXX领取项目任务
4．框架构建人员与编码人员理解业务需求，可通过调研、会议、邮件、涵的方式。
3、本阶段具体做法
参与需求研讨会，理解业务需求
4、参考经验
业务部门提出的需求共有两种：
对现有系统功能的改造；
提出新的业务功能要求。
对于现有功能的改造需求理解：
在熟悉现有业务功能的基础上，针对改造的内容，预估涉及改造的功能模块；
系统现有框架或实现方式不会做大的改动，从会议讨论中可以发现本次改造的重点与难点；
区分出重点与难点之后，其他功能完全可以自我理解。
对于现有功能改造的需求理解，建立在对现有系统的理解的基础上。
新进人员对系统的熟悉程度可以向项目组其他成员请教。
对于新的业务需求：
需求理解研讨会上仔细做笔记，搞清每一个功能模块的输入与输出，以达到对业务流程以及实现过程的精确把握；
对于不理解或无把握之处提出自己的有效问题或者建议，恰恰体现出认真思考的工作态度。
整理需求研讨会议纪要，可以试着自己设计业务功能的框架与实现过程，比较架构办的预案，缩小差距，提高自身需求理解的程度。
三、业务需求与验收测试设计
系统软件的质量：
体现业务需求理解的程度，也体现在验收测试设计中。
验收结果达不到预期值将从根本上决定考核指标。
风险程度：
项目参与人员的技术成熟度、稳定性、沟通能力、工时额度、人员或部门的配合度。
验收测试对业务需求的覆盖率。
参与需求研讨会，间接参与验收测试设计，预估项目风险
1．参与需求研讨会：
对于业务部门提出的需求，逐字逐句理解并把握，否定无效需求。
2．间接参与验收测试设计
3．预估项目风险
同上。
2．间接参与验收测试设计。
集成测试与系统测试阶段不体现项目软件验收工作，但是集成测试与系统测试范围必须涵盖业务需求范围，包含直接划定的业务范围与相关联的业务范围。
本阶段可以参考集成测试阶段。
3．预估项目风险：
积极参与项目的组织结构、平时注意业务经验与技能的积累，并保持长期性与稳定性；
对项目进度的不合理安排提出自己的建议。
四、业务需求分析与系统设计
1．业务需求理解程度：
2．系统设计合理性、可行性：
合理性、可行性程度将直接影响项目后续阶段。
3．静态问题：
体现在系统规格书文档中静态测试问题个数。
1．参与项目需求的理解。
2．参与业务需求的理解。
3．参与项目系统规格书的编写与修改。
1．参与项目需求的理解：
2．参与业务需求的理解：
依据项目需求，整理并归纳业务需求。
3．项目系统规格书：
以业务需求为依据，按照一定的格式编写或者修改系统规格数。
2．参与业务需求理解：
根据历次会议讨论结果和会议纪要，拆分或整合项目需求，整理完毕的业务需求说明书必须包含项目需求的所有内容和隐含内容，为系统规格数编写或者修改的依据。
3．系统规格书编写与修改：
熟练使用相关的流程图工具，如VISO等，在理解业务流程、业务逻辑、涉及的表结构、字段等基础上进行规格书的编写与修改。
系统规格书有固定的格式，有模板共参考。
理解业务流程与业务逻辑可以向框架人员或者编码人员进行沟通，也可以根据自己的理解或者会议讨论结果、纪要进行；
涉及的表结构、字段可向项目编码人员所取，对于新建表、更新表等操作，要要根据业务功能注意表之间的关联。
五、需求理解、系统设计与确认、系统测试设计
系统设计：
系统设计对业务需求功能覆盖率、合理程度、界面友好、操作便利性等。
集成测试人员偶尔参与系统设计
1．对于修改现有功能的业务需求类，可以向编码人员展示现有功能的实现过程、逻辑复杂性、参数设计合理性、GUI资源等。
2．对于全新的业务需求类，可以向编码人员建议类似的业务实现过程。
1．修改现有功能的业务需求类：
在页面展示上类似于增加字段，后台数据表增加对应字段类型等改造。
业务流程基本不会发生质的改变。
测试人员可以先熟悉现有功能模块的菜单位置、图形界面，以数据驱动、业务驱动或者后台数据查看的方式掌握现有的业务功能。
2．全新的业务需求类：
XX现有的业务实现过程基本为申请－签批－台帐，这是业务的主要流程，针对不同的业务类型只是表现为菜单位置不同，实现过程大同小异，测试人员可以从大体流程上把握新需求的实现过程，不至于茫然而无从下手。
六、概要设计
1．静态测试问题：
体现在软件需求说明书中的文档问题。
2、项目需求与产品双向追溯：
产品功能点与项目软需契合程度。
1．业务需求的讨论。
2．非业务需求的讨论。
3．编写或修改软件需求说明书。
4．评审需求要点并参与设置需求实现优先级。
5．制定项目需求与产品双向追溯表。
2．非业务需求讨论：
与本次项目需求相关但无须本次项目中实现的需求、本次项目关联的其他业务需求，对相关的业务类型进行列举，并讨论有效解决方案。
3．编写或修改软件需求说明书：
依据系统规格书进行。
4．依据模块重要性、关键路径对其他模块影响程度设置需求实现优先级。
5．项目需求与产品双向追溯表：
实现项目需求与产品功能的对照关系。
2．非业务需求的讨论：
可以列举本次业务实现过程中对其他业务类型所产生的影响，比如下游系统的数据需求、数据移行、接口参数等；
其他相关联的业务实现；
此项需要较丰富的业务知识。
总之一点：
和本次项目相关的，都可以纳入到讨论的范围。
3．软件需求说明书。
严格按照系统规格书进行编写。
与系统规格书格式不一致，提供模板。
基本要素为：
模块编号、模块名称、功能概括、角色、运行条件、输入字段、输出字段、约束关系、页面截图、业务功能详述等，并注意文档排版与美观。
其中业务功能为重点，详细阐述本功能模块实现的功能点，描述无别字、错字，表述要清晰、准确、无冗余，否则属于静态测试问题。
软件需求说明书与系统规格书在表述内容上要严格保持一致。
软件需求说明书修改要根据相关会议讨论结果，并确认有修改必要后再行修改。
4．设置需求实现优先级：
测试人员参与此项工作有助于了解模块的关键程度，实施测试时可以先测试高优先级模块。
有利于提高测试效率，同时也能有效把握测试进度。
检测产品功能列表是否全部体现出项目需求，可以有效控制项目需求的遗漏和冗余，高于项目需求或者低于项目需求都有可能存在缺陷。
七、概要设计与集成测试设计
1．项目测试列表：
测试列表中所涉及的功能模块的覆盖率直接影响测试案例的覆盖率，进而影响软件测试质量。
2．项目测试计划：
体现测试工作量、测试时间与测试进度控制，进而影响测试质量。
3．项目测试方案：
体现测试工具、测试顺序与测试伦次，进而影响测试效率。
4．项目测试案例：
测试执行的依据，直接体现了功能模块的测试覆盖率。
1．编写项目测试列表。
2．编写项目测试计划。
3．编写项目测试方案。
4．编写项目测试案例。
包含要素：
模块名称、变更类型、接口、测试案例分支、模块重要性、计划编写案例数、实际编写案例数、测试人员、测试结论等。
项目简介、测试目标、测试环境、工作量、人力资源要素、测试时间与进度、风险等。
环境、参数、数据准备、测试工具、测试列表、测试顺序与伦次等。
模块名称、模块功能描述、测试案例分支、测试用例、预期结果、测试人员、用例预期执行时间、用例测试通过时间、问题数、问题号等。
以软件需求说明书为蓝本，此文档作用基本为列出本次项目所实现的功能点，编写此文档时，可以拷贝软件需求说明书中的业务功能详述部分，进行修改，加入模块或者是字段之间的约束关系，整合在一起，即：
编写项目测试列表即要体现所有的功能点，也要体现模块与模块、字段与字段之间的约束关系。
可以提供模板供参考格式，并注意整个文档的排版与可读性。
，
对项目进行简单介绍、说明测试工作应该达到的预期目标（问题或缺陷闭环率100%），体现测试工作所处的软硬件环境、预期的工作量、测试参与人员与QA、一定时间段内的应达的测试进度、测试风险。
其中：
测试进度依据测试时间来制定并严格执行，否则，规定的时间内完不成测试任务；
测试风险考虑参与测试的人员的技术成熟度、稳定性、积极性、编码人员修改问题的实效性、配合力度，或者其他相关部门、个人对提供直接数据的依赖程度。
风险一般是客观存在的风险。
体现测试工执行中的测试工作、测试顺序和伦次等测试策略。
测试环境体现了软件版本安装路径、访问地址、测试列表、所需的软硬件要求等；
参数部分体现了软硬件参数、环境参数、数据交互接口、DSR配置以及参数失效的错误码等；
测试工具，目前主要采用黑盒手工测试，自动化测试工具很少使用，辅助测试工具主要有：
Rational缺陷管理工具、数据库管理工具、抓图工具、归并冲突管理工具等；
测试列表同上；
顺序与伦次，按照业务流程与关键路径对功能模块进行排序，确定测试顺序，一般的做法是抓住主要的业务流程，其他模块可以放在后面进行细测，比如参数设置的模块。
测试伦次原则上是至少两轮，第一论对项目中的所有模块进行细致的测试，第二论主要是对第一论测试中缺陷较多的模块进行测试，同时应注意的是，确认对于修改后的问题不会引起其他的问题，或者修改后的问题在新版本中确认修改测试通过。
功能模块名称：
体现在软件需求说明书中；
变更类型：
是指当前测试的模块是改造后的模块还是新做的模块；
接口：
模块与模块之间数据交互需要相关接口，或者是系统与其他系统中数据交互也需要接口，接口的名称与具体参数在系统规格书中有详细的描述；
压力：
是否需要进行压力测试，如终端多用户同时登陆等，目前在XX手工黑盒手工测试过程中较少使用；
模块的重要性：
关键路径模块应摆放重点测试的地位应体现该模块在整个业务流程中的重要性，模块的重要性依据业务流程与业务功能而定；
案例分支纪要：
在测试列表中体现；
测试用例：
依据分支纪要逐条设计测试案例（测试用例），可依据因果关系分析法、等价类划分、边界值等测试理论进行设计测试案例，测试案例力求详细，应该覆盖所有程序分支，这里体现了软件需求说明书与历次会议纪要等注意点的积累。
描述语言力求准确，不建议案例重复。
有意思的是，错误的数据输入也是测试的常用方法；
期望结果：
与软件需求说明书、系统规格书、项目软需保持一致或是与逻辑保持一致。
测试用例的设计基本单位是，一个用例验证一个功能点，比如验证短期流动资金贷款合同申请完毕后保存成功所展示的提示资源，可以这样设计用例：
做一笔短期流程资金业务，必输项输入完毕后点击“保存”按钮，查看提示信息。
该用例的预期结果是：
页面提示该笔业务合同保存成功。
从上面的用例我们能看到的要素为：
是短期流动资金业务，做的是申请操作，必输项体现基本输入数据，数据输入完毕后的操作，最后才是测试目的，目的体现了测试的功能点。
至于如何输入数据、数据之间的约束关系、如何验证数据保存后后台数据表与前台页面输入的是否一致、保存不成功的异常处理方式，则体现在上条或者下条测试用例中；
预期测试结果：
依据软件需求说明书或者系统规格书业务模块功能描述中模块所实现的作用，最为最终测试结果。
若测试结果与以往的经验不相符和，以软需和规格书为准。
因为业务需求是变化的，特别是改造的模块，先前的业务所实现功能有可能在本次项目中实行另外一套标准；
测试人员：
测试过程中执行测试用例的人员，测试用例设计者与执行者可能不是同一个人，这样就要求在设计测试用例时注意用例的可行性、可读性、易操作、规范。
用例预期执行时间：
根据测试的整体时间、项目的功能点数、业务流程的复杂性、模块之间的关系、关键路径等制定用例的执行时间。
用例预期执行时间体现对整个测试进度的控制，测试人员应该合理安排整体进度，并尽量在预期时间之前执行本用例，避免其他突发因素影响案例的执行，从而导致进度滞后，比如本模块的数据之源出现问题；
用例通过时间：
本条测试用例测试通过的时间，但是不是最终测试通过时间，只是体现了当前时间段内测试通过，应该注意其他模块修改后对本模块是否存在影响。
最终通过时间一般为测试结束时间，这时所有问题闭环；
问题数：
执行该条用例时所发现的问题或者缺陷的数量；
问题号：
取自Rational中对应问题的ID。
在项目测试结束时，案例全部测试通过。
5．从上面的阐述中，我们能发现下面的对应关系：
软件需求说明书细化了系统规格书的内容；
测试案例细化了测试列表；
测试方案与测试计划体现了测试过程的整体控制。
八、详细设计阶段
静态测试问题：
在项目软件详细设计过程中发现的系统规格书或者软件需求说明书错误之处。
1．修改系统规格书。
2．修改软件需求说明书。
1．修改系统规格书：
根据编码人员或者框架人员所发现的问题修改系统规格书。
2．修改软件需求说明书：
可以通过项目例会、咨询编码人员、咨询框架人员，弄清问题所在，修改系统规格书的对应之处。
同时应考虑修改的地方对其他模块的影响程度，即：
符合前一个模块的输出与下一个模块的输入。
九、详细设计与单元测试设计
1．编写程序规格书。
2．制定代码设计曲线。
3．制定代码检查计划。
目前测试人员较少参与该阶段工作。
十、单元测试
1．编码人员自测
1．偶尔协助编码人员准备自测数据。
1．协助编码人员准备自测数据：
可以利用数据库现有数据、可以直接操作后台数据表，比如修改字段值等等。
十一、集成
1．评审测试计划。
2．评审测试方案。
3．评审测试案例。
4．测试准备。
1．评审测试计划：
项目例会方式评审。
2．评审测试方案：
3．评审测试案例：
4．数据准备：
测试数据。
5．环境准备：
软硬件环境。
6．相关文档：
学习文档、技术文档、日志等。
由计划制定人主持例会，阐述计划制定的依据，项目组其他人员评审计划是否可行，存在异议之处以会议纪要的方式确认下来，并由计划制定人更新到测试计划中，备案。
同评审测试计划。
4．数据准备。
常用的支行、柜员、客户，相关参数，这些数据可以在平时工作中注意积累。
这里提到的数据，要素比较全面、可用性比较高，这样在测试执行过程中可以起到事半功倍的效果。
5．环境准备。
包括软硬件环境。
硬件方面：
处理器、内存、显卡显存、硬盘转速是否达到测试所需；
软件方面：
测试工具是否正常使用、数据库工具是否可用、IE版本是否符合要求、系统补丁是否齐全、IE设置是否正确、操作系统语言版本、防火墙是否阻断通讯、最新程序数否更新到测试环境等等。
6．相关文档。
各个项目文档是否最新版本、各个项目文档是否评审通过。
十二、集成测试
1．集成测试有效问题数：
在集成测试过程中发现的有效问题数，目前XX制定的4%，即：
百功能点要发现至少四个有效问题。
比如，XX2008年7月份版本所有项目的总功能点为10000，则在缺陷管理工具中至少体现400个以上有效问题并全部解决，才符合版本出口条件。
4％为季度版本中所有项目的均值。
2．静态问题数：
相关项目文档所体现的静态问题。
3．问题验证的实效性。
XX制定的规范：
当前状态为自己手中的问题要在两个工作日之内验证完毕。
1．集成测试执行。
2．提交集成测试问题。
3．验证集成测试问题。
4．更新测试案例。
5．分析缺陷分布。
6．统计集成测试问题数量。
1．集成测试：
严格依据软件需求说明书进行集成测试。
2．提交集成测试问题：
按照一定的程序、规定的方式在指定的缺陷管理工具中提交问题。
3．验证集成测试问题：
该问题状态为“修改完成，待确认”状态时进行问题验证。
4．更新测试案例：
提交测试问题后，根据问题内容对应到具体的案例中
5．分析缺陷分布：
根据问题所在功能模块，概算问题分布，以确认回装验证重点。
6．统计集成测试问题数量：
贯穿在测试过程中，可以及时更改测试方法或者测试深度。
1）深入了解软件需求说明书并严格按照软件需求说明书的业务流程进行集成测试工作。
软需是测试人员进行测试的最直接的项目文档，软需当中体现了基本的业务流程与业务逻辑。
执行测试的过程中依据软需当中的每一段文字、每一个判定、每一种业务条件组织测试用例，功能模块最终的验证结果与软需描述完全保持一致才能说明该模块测试通过。
软需的编写一般是按照业务流程或者是业务逻辑进行编写的，所以一般也间接决定了执行测试的功能模块顺序。
XX现场一般采用的测试方法是按照软需的描述一步步进行验证。
但是，即使在规范的条件约束下，软需的描述语言在不同编码人员的编写下，有一定的不一致，这种情况下，我们需要从自身理解的业务需求来判断软需的功能描述是否正确，若存在不一致之处，及时与相关人员进行沟通，经过确认之后在对该模块进行测试。
值得注意的是，模块与模块之间的关联性非常重要，如果是一个人执行整个业务的测试，会注意模块之间的相互影响；
如果复杂的业务流程由多人负责不同的模块进行测试，此时需要加强测试合作。
简单的做法是告诉其他人我需要什么样的数据，或者请提供符合测试要求的数据，以便于更有利的发现问题并定位问题。
测试的同时我们需要保持清醒的头脑，多想想当前的模块数据来源的多样性与数据输出的多样性，此时宜采用发散思维。
并注意一笔数据的复用，提高测试效率。
同时，在测试过程中也思考，根据业务流程或者数据驱动的方式所发现的许多业务细节在软需中是否已经包含，往往这些细节在测试过程中是必须要执行的。
2）相关业务的表结构请参考软件需求说明书。
测试过程中不可避免的要与后台数据表进行接触，熟练使用数据库管理工具与精通各类表结构在测试过程中会给予很大的帮助，甚至为了测试业务的中间模块，在业务流程存在瓶颈的情款下，我们可以直接操作后台数据表。
了解表结构我们基本可以有如下好处：
a．查看前台页面展示与后台数据表数据是否一致。
b．页面保存或者修改数据后，后台数据表是否更新并且更新结果与预期保持一致。
c．查看相关存储过程，分解程序执行的每一步，有利于白盒测试经验的积累。
d．直接修改相关表中字段，快速得到所需数据，特别在生产问题验证等时间紧、任务重的测试工作中，免去了前台页面的许多环节。
举一个印象很深例子：
在一个不上主机的国内地区，做一笔国内银行保函修改申请的业务，这种测试需求在前台页面是根本没有办法实现的，而我们只需要修改一个表中一个字段值，就轻松解决了。
新进测试人员也不必感到恐慌，只要平时多加注意并养成经验积累的好习惯与保持良好的记忆，上述的操作是不难做到的。
3）测试业务流程请参考系统规格书。
系统规格书中对每一个模块都会有一张易懂的流程图，测试人员可以据图了解业务的每一个分支，避免了分支的遗漏。
我的理解是，系统规格书是对功能模块的业务概述，可以有助于理解软件需求说明书中难懂的语言逻辑，特别是在软需不断更新的情况下。
同时，系统规格书中有业务所涉及的所有表名称，这是软需中所没有的，而我们积累表名称的来源也是系统规格书。
建议的做法：
将表名整理成册并匹配简单说明，你将成为数据高手，在他人需要帮助的情况下，轻松解决问题，是团队合作的催化剂。
4）查看相关会议纪要。
先期投入巨大时间与人力的项目例会，最终体现在集成测试阶段。
会议纪要点睛式的要点描述，更有助于提高测试覆盖率，在测试的过程中注意纪要的要点，将会使测试更加完美。
曾经有这样的经历：
项目集成测试完毕后，我们在想，软需与规格书上的所有要点我们都测试到了，会议纪要也测试到了，我们提出的问题相当有水平，我们会觉得测试是一个追求完美的工作，下一次会更加完美，就让系统测试人员因发现不了高质量的问题痛苦去吧。
5）整个测试过程要高度关注测试时间。
时间的宽裕是保证测试质量的关键要素之一，关注时间要素可以有效调整测试进度，避免因时间分配不科学，导致有的模块测试不充分。
我们也常常遇到测试的有效时间被严重挤压的情况。
这时我们需要先测试已经开发完毕的模块。
先保证可以测试的模块质量，至于剩下的模块开发进度，我们要和编码人员保持不间断的沟通，明确交付测试的时间。
对于按期交付测试的模块我们也可以通过把握时间，合理的安排测试进度，从而保证了测试质量。
6）测试过程中注意测试顺序与测试伦次。
测试的顺序依据项目的不同存在差异，总之做到合理安排就可以，伦次一般采用不低于二伦的方式，第一论对所有的模块进行功能测试，第二论对发现问题较多的模块进行测试，或者是确认问题二次修改产生的影响。
7）测试过程中养成良好的日志习惯。
日志的格式不作统一，依据个人的习惯而进行。
日志主要记录了测试过程中使用的基础数据，这对于我们验证问题时可以提供帮助，我们可以使用现有的数据来验证问题，有时候不要重新做数
升级会员 