项目软件测试流程及规范.docx

《项目软件测试流程及规范.docx》由会员分享，可在线阅读，更多相关《项目软件测试流程及规范.docx（25页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、项目软件测试流程及规范目录一、项目软件流程与测试人员工作范围(4)1、项目软件流程阶段(4)2、测试人员工作范围(4)3、相关名词解释(4)二、业务需求阶段(5)1、考核指标(5)2、本阶段工作流程(5)3、本阶段详细做法(5)4、参考经历(5)三、业务需求与验收测试设计(6)1、考核指标(6)2、本阶段工作流程(6)3、本阶段详细做法(6)4、参考经历(6)四、业务需求分析与系统设计(6)1、考核指标(6)2、本阶段工作流程(6)3、本阶段详细做法(7)4、参考经历(7)五、需求理解、系统设计与确认、系统测试设计(7)1、考核指标(7)2、本阶段工作流程(7)3、本阶段详细做法(7)4、参考

2、经历(7)六、概要设计(8)1、考核指标(8)2、本阶段工作流程(8)3、本阶段详细做法(8)4、参考经历(8)七、概要设计与集成测试设计(9)1、考核指标(9)2、本阶段工作流程(9)3、本阶段详细做法(9)4、参考经历(9)八、具体设计阶段(11)1、考核指标(11)2、本阶段工作流程(11)3、本阶段详细做法(11)4、参考经历(11)九、具体设计与单元测试设计(11)1、考核指标(11)2、本阶段工作流程(11)3、本阶段详细做法(11)4、参考经历(12)十、单元测试(12)1、考核指标(12)2、本阶段工作流程(12)3、本阶段详细做法(12)4、参考经历(12)十一、集成(12)

3、1、考核指标(12)2、本阶段工作流程(12)3、本阶段详细做法(12)4、参考经历(13)十二、集成测试(13)1、考核指标(13)2、本阶段工作流程(13)3、本阶段详细做法(13)4、参考经历(14)十三、施行阶段(16)1、考核指标(16)2、本阶段工作流程(16)3、本阶段详细做法(16)4、参考经历(16)十四、确认测试与系统测试(17)1、考核指标(17)2、本阶段工作流程(17)3、本阶段详细做法(17)4、参考经历(17)十五、交付(17)1、考核指标(17)2、本阶段工作流程(17)3、本阶段详细做法(18)4、参考经历(18)十六、验收测试阶段(18)1、考核指标(18)

4、2、本阶段工作流程(18)3、本阶段详细做法(18)4、参考经历(18)一、项目软件流程与测试人员工作范围1、项目软件流程阶段XXX项目，目前采用的项目流程，主要有下面阶段一、理解业务需求阶段(立项)；二、业务需求与验收测试设计阶段；三、需求分析与系统设计；四、需求分析、系统设计与确认、系统测试设计；五、概要设计；六、概要设计与基础测试设计；七、具体设计八、具体设计与单元测试设计；九、编码；十、单元测试；十一、集成；十二、集成测试；十三、施行；十四、确认测试与系统测试；十五、交付；十六、验收测试；2、测试人员工作范围一、理解业务需求；二、编写相关业务文档；三、编写相关测试文档；四、介入项目会议

5、并整理睬议记录；五、介入项目设计；六、制定测试计划与测试方案；七、编写测试用例；八、执行测试；九、验证项目问题十、提交测试报告十一、版本推广；十二、版本后续维护3、相关名词解释业务需求讲明书：根据项目需求为蓝本，将项目需求整理成册，为项目其他文档母本，为编码工作的业务指导文档系统规格书：根据业务需求讲明书，规定需务实现的逻辑与流程，以及涉及的表构造、字段类型，囊括模块流程图、模块之间的关系、业务流程讲明、实现经过、数据表等关键要素。软件需求讲明书：以简练、准确、无歧义描绘语言，描绘软件需求，是软件测试的关键文档，也是编写测试列表、测试案例的基础文档。模测问题：模拟生产环境测试经过中所发现的项目

6、软件缺陷或者功能没有实现等问题。生产问题：生产环境中业务人员发现的项目软件缺陷或者功能没有实现等问题静态问题：项目文档中，错误或者不规范的流程图、不合理、错误或者的描绘等体如今文档中的问题。有效问题：测试问题提出后，经过编码人员修改，最终被修改验证通过的问题。二、业务需求阶段1、考核指标业务需求理解处于项目立项阶段，需求理解的程度将直接影响后续阶段。本阶段考核指标将体如今后续阶段中：编写项目相关文档的质量、测试的执行力、程序派错率、遗漏的问题数等。2、本阶段工作流程1业务部门在生产经过中面向XX客户提出的使用需求，整理成书面文档，汇总后将需求提交至XXX，同时提出软件功能需求。2XXX从全国各

7、业务部门(含海外地区)上报的需求，下发XXX所属的各研发部。3各研发部从XXX领取项目任务4框架构建人员与编码人员理解业务需求，可通过调研、会议、邮件、涵的方式。3、本阶段详细做法介入需求研讨会，理解业务需求4、参考经历业务部门提出的需求共有两种：对现有系统功能的改造；提出新的业务功能要求。对于现有功能的改造需求理解：在熟悉现有业务功能的基础上，针对改造的内容，预估涉及改造的功能模块；系统现有框架或实现方式不会做大的改动，从会议讨论中能够发现本次改造的重点与难点；区分出重点与难点之后，其他功能完全能够自我理解。对于现有功能改造的需求理解，建立在对现有系统的理解的基础上。新进人员对系统的熟悉程度

8、能够向项目组其他成员请教。对于新的业务需求：需求理解研讨会上仔细做笔记，搞清每一个功能模块的输入与输出，以到达对业务流程以及实现经过的准确把握；对于不理解或无把握之处提出本人的有效问题或者建议，恰恰体现出认真考虑的工作态度。整理需求研讨会议纪要，能够试着本人设计业务功能的框架与实现经过，比拟架构办的预案，缩小差距，提高本身需求理解的程度。三、业务需求与验收测试设计1、考核指标系统软件的质量：体现业务需求理解的程度，也体如今验收测试设计中。验收结果达不到预期值将从根本上决定考核指标。风险程度：项目介入人员的技术成熟度、稳定性、沟通能力、工时额度、人员或部门的配合度。验收测试对业务需求的覆盖率。2

9、、本阶段工作流程介入需求研讨会，间接介入验收测试设计，预估项目风险3、本阶段详细做法1介入需求研讨会：对于业务部门提出的需求，逐字逐句理解并把握，否认无效需求。2间接介入验收测试设计3预估项目风险4、参考经历1介入需求研讨会：同上。2间接介入验收测试设计。集成测试与系统测试阶段不体现项目软件验收工作，但是集成测试与系统测试范围必须涵盖业务需求范围，包含直接划定的业务范围与相关联的业务范围。本阶段能够参考集成测试阶段。3预估项目风险：积极介入项目的组织构造、平常注意业务经历与技能的积累，并保持长期性与稳定性；对项目进度的不合理安排提出本人的建议。四、业务需求分析与系统设计1、考核指标1业务需求理

10、解程度：同上。2系统设计合理性、可行性：合理性、可行性程度将直接影响项目后续阶段。3静态问题：体如今系统规格书文档中静态测试问题个数。2、本阶段工作流程1介入项目需求的理解。2介入业务需求的理解。3介入项目系统规格书的编写与修改。3、本阶段详细做法1介入项目需求的理解：同上。2介入业务需求的理解：根据项目需求，整理并归纳业务需求。3项目系统规格书：以业务需求为根据，根据一定的格式编写或者修改系统规格数。4、参考经历2介入业务需求理解：根据历次会议讨论结果和会议纪要，拆分或整合项目需求，整理完毕的业务需求讲明书必须包含项目需求的所有内容和隐含内容，为系统规格数编写或者修改的根据。3系统规格书编写

11、与修改：熟练使用相关的流程图工具，如VISO等，在理解业务流程、业务逻辑、涉及的表构造、字段等基础上进行规格书的编写与修改。系统规格书有固定的格式，有模板共参考。理解业务流程与业务逻辑能够向框架人员或者编码人员进行沟通，可以以根据本人的理解或者会议讨论结果、纪要进行；涉及的表构造、字段可向项目编码人员所取，对于新建表、更新表等操作，要要根据业务功能注意表之间的关联。五、需求理解、系统设计与确认、系统测试设计1、考核指标系统设计：系统设计对业务需求功能覆盖率、合理程度、界面友好、操作便利性等。2、本阶段工作流程集成测试人员偶然介入系统设计3、本阶段详细做法1对于修改现有功能的业务需求类，能够向编

12、码人员展示现有功能的实现经过、逻辑复杂性、参数设计合理性、GUI资源等。2对于全新的业务需求类，能够向编码人员建议类似的业务实现经过。4、参考经历1修改现有功能的业务需求类：在页面展示上类似于增加字段，后台数据表增加对应字段类型等改造。业务流程基本不会发生质的改变。测试人员能够先熟悉现有功能模块的菜单位置、图形界面，以数据驱动、业务驱动或者后台数据查看的方式把握现有的业务功能。2全新的业务需求类：XX现有的业务实现经过基本为申请签批台帐，这是业务的主要流程，针对不同的业务类型只是表现为菜单位置不同，实现经过大同小异，测试人员能够从大体流程上把握新需求的实现经过，不至于茫然而无从下手。六、概要设

13、计1、考核指标1静态测试问题：体如今软件需求讲明书中的文档问题。2、项目需求与产品双向追溯：产品功能点与项目软需契合程度。2、本阶段工作流程1业务需求的讨论。2非业务需求的讨论。3编写或修改软件需求讲明书。4评审需求要点并介入设置需务实现优先级。5制定项目需求与产品双向追溯表。3、本阶段详细做法2非业务需求讨论：与本次项目需求相关但无须本次项目中实现的需求、本次项目关联的其他业务需求，对相关的业务类型进行列举，并讨论有效解决方案。3编写或修改软件需求讲明书：根据系统规格书进行。4根据模块重要性、关键途径对其他模块影响程度设置需务实现优先级。5项目需求与产品双向追溯表：实现项目需求与产品功能的对

14、照关系。4、参考经历2非业务需求的讨论：能够列举本次业务实现经过中对其他业务类型所产生的影响，比方下游系统的数据需求、数据移行、接口参数等；其他相关联的业务实现；此项需要较丰富的业务知识。总之一点：和本次项目相关的，都能够纳入到讨论的范围。3软件需求讲明书。严格根据系统规格书进行编写。与系统规格书格式不一致，提供模板。基本要素为：模块编号、模块名称、功能概括、角色、运行条件、输入字段、输出字段、约束关系、页面截图、业务功能详述等，并注意文档排版与美观。其中业务功能为重点，具体阐述本功能模块实现的功能点，描绘无别字、错字，表述要明晰、准确、无冗余，否则属于静态测试问题。软件需求讲明书与系统规格书

15、在表述内容上要严格保持一致。软件需求讲明书修改要根据相关会议讨论结果，并确认有修改必要后再行修改。4设置需务实现优先级：测试人员介入此项工作有助于了解模块的关键程度，施行测试时能够先测试高优先级模块。有利于提高测试效率，同时也能有效把握测试进度。5项目需求与产品双向追溯表：检测产品功能列表能否全部体现出项目需求，能够有效控制项目需求的遗漏和冗余，高于项目需求或者低于项目需求都有可能存在缺陷。七、概要设计与集成测试设计1、考核指标1项目测试列表：测试列表中所涉及的功能模块的覆盖率直接影响测试案例的覆盖率，进而影响软件测试质量。2项目测试计划：体现测试工作量、测试时间与测试进度控制，进而影响测试质

16、量。3项目测试方案：体现测试工具、测试顺序与测试伦次，进而影响测试效率。4项目测试案例：测试执行的根据，直接体现了功能模块的测试覆盖率。2、本阶段工作流程1编写项目测试列表。2编写项目测试计划。3编写项目测试方案。4编写项目测试案例。3、本阶段详细做法1编写项目测试列表。包含要素：模块名称、变更类型、接口、测试案例分支、模块重要性、计划编写案例数、实际编写案例数、测试人员、测试结论等。2编写项目测试计划。包含要素：项目简介、测试目的、测试环境、工作量、人力资源要素、测试时间与进度、风险等。3编写项目测试方案。包含要素：环境、参数、数据准备、测试工具、测试列表、测试顺序与伦次等。4编写项目测试案

17、例。包含要素：模块名称、模块功能描绘、测试案例分支、测试用例、预期结果、测试人员、用例预期执行时间、用例测试通过时间、问题数、问题号等。4、参考经历1编写项目测试列表。以软件需求讲明书为蓝本，此文档作用基本为列出本次项目所实现的功能点，编写此文档时，能够拷贝软件需求讲明书中的业务功能详述部分，进行修改，参加模块或者是字段之间的约束关系，整合在一起，即：编写项目测试列表即要体现所有的功能点，也要体现模块与模块、字段与字段之间的约束关系。能够提供模板供参考格式，并注意整个文档的排版与可读性。，2编写项目测试计划。对项目进行简单介绍、讲明测试工作应该到达的预期目的(问题或缺陷闭环率100%)，体现测

18、试工作所处的软硬件环境、预期的工作量、测试介入人员与QA、一定时间段内的应达的测试进度、测试风险。其中：测试进度根据测试时间来制定并严格执行，否则，规定的时间内完不成测试任务；测试风险考虑介入测试的人员的技术成熟度、稳定性、积极性、编码人员修改问题的实效性、配合力度，或者其他相关部门、个人对提供直接数据的依靠程度。风险一般是客观存在的风险。3编写项目测试方案。体现测试工执行中的测试工作、测试顺序和伦次等测试策略。测试环境体现了软件版本安装途径、访问地址、测试列表、所需的软硬件要求等；参数部分体现了软硬件参数、环境参数、数据交互接口、DSR配置以及参数失效的错误码等；测试工具，目前主要采用黑盒手

19、工测试，自动化测试工具很少使用，辅助测试工具主要有：Rational缺陷管理工具、数据库管理工具、抓图工具、归并冲突管理工具等；测试列表同上；顺序与伦次，根据业务流程与关键途径对功能模块进行排序，确定测试顺序，一般的做法是捉住主要的业务流程，其他模块能够放在后面进行细测，比方参数设置的模块。测试伦次原则上是至少两轮，第一论对项目中的所有模块进行细致的测试，第二论主要是对第一论测试中缺陷较多的模块进行测试，同时应注意的是，确认对于修改后的问题不会引起其他的问题，或者修改后的问题在新版本中确认修改测试通过。4编写项目测试案例。功能模块名称：体如今软件需求讲明书中；变更类型：是指当前测试的模块是改造

20、后的模块还是新做的模块；接口：模块与模块之间数据交互需要相关接口，或者是系统与其他系统中数据交互也需要接口，接口的名称与详细参数在系统规格书中有具体的描绘；压力：能否需要进行压力测试，如终端多用户同时登陆等，目前在XX手工黑盒手工测试经过中较少使用；模块的重要性：关键途径模块应摆放重点测试的地位应体现该模块在整个业务流程中的重要性，模块的重要性根据业务流程与业务功能而定；案例分支纪要：在测试列表中体现；测试用例：根据分支纪要逐条设计测试案例(测试用例)，可根据因果关系分析法、等价类划分、边界值等测试理论进行设计测试案例，测试案例力求具体，应该覆盖所有程序分支，这里体现了软件需求讲明书与历次会议

21、纪要等注意点的积累。描绘语言力求准确，不建议案例重复。有意思的是，错误的数据输入也是测试的常用方法；期望结果：与软件需求讲明书、系统规格书、项目软需保持一致或是与逻辑保持一致。测试用例的设计基本单位是，一个用例验证一个功能点，比方验证短期流动资金贷款合同申请完毕后保存成功所展示的提示资源，能够这样设计用例：做一笔短期流程资金业务，必输项输入完毕后点击“保存按钮，查看提示信息。该用例的预期结果是：页面提示该笔业务合同保存成功。从上面的用例我们能看到的要素为：是短期流动资金业务，做的是申请操作，必输项体现基本输入数据，数据输入完毕后的操作，最后才是测试目的，目的体现了测试的功能点。至于怎样输入数据

22、、数据之间的约束关系、怎样验证数据保存后后台数据表与前台页面输入的能否一致、保存不成功的异常处理方式，则体如今上条或者下条测试用例中；预期测试结果：根据软件需求讲明书或者系统规格书业务模块功能描绘中模块所实现的作用，最为最终测试结果。若测试结果与以往的经历不相符和，以软需和规格书为准。由于业务需求是变化的，十分是改造的模块，先前的业务所实现功能有可能在本次项目中实行另外一套标准；测试人员：测试经过中执行测试用例的人员，测试用例设计者与执行者可能不是同一个人，这样就要求在设计测试用例时注意用例的可行性、可读性、易操作、规范。用例预期执行时间：根据测试的整体时间、项目的功能点数、业务流程的复杂性、

23、模块之间的关系、关键途径等制定用例的执行时间。用例预期执行时间体现对整个测试进度的控制，测试人员应该合理安排整体进度，并尽量在预期时间之前执行本用例，避免其他突发因素影响案例的执行，进而导致进度滞后，比方本模块的数据之源出现问题；用例通过时间：本条测试用例测试通过的时间，但是不是最终测试通过时间，只是体现了当前时间段内测试通过，应该注意其他模块修改后对本模块能否存在影响。最终通过时间一般为测试结束时间，这时所有问题闭环；问题数：执行该条用例时所发现的问题或者缺陷的数量；问题号：取自Rational中对应问题的ID。在项目测试结束时，案例全部测试通过。5从上面的阐述中，我们能发现下面的对应关系：

24、软件需求讲明书细化了系统规格书的内容；测试案例细化了测试列表；测试方案与测试计划体现了测试经过的整体控制。八、具体设计阶段1、考核指标静态测试问题：在项目软件具体设计经过中发现的系统规格书或者软件需求讲明书错误之处。2、本阶段工作流程1修改系统规格书。2修改软件需求讲明书。3、本阶段详细做法1修改系统规格书：根据编码人员或者框架人员所发现的问题修改系统规格书。2修改软件需求讲明书：同上。4、参考经历1修改系统规格书：能够通过项目例会、咨询编码人员、咨询框架人员，弄清问题所在，修改系统规格书的对应之处。同时应考虑修改的地方对其他模块的影响程度，即：符合前一个模块的输出与下一个模块的输入。2修改软件需求讲明书。同上。九、具体设计与单元测试设计1、考核指标2、本阶段工作流程1编写程序规格书。2制定代码设计曲线。3制定代码检查计划。3、本阶段详细做法目前测试人员较少介入该阶段工作。