项目测试工作说明

《项目测试工作说明》由会员分享，可在线阅读，更多相关《项目测试工作说明（18页珍藏版）》请在金锄头文库上搜索。

1、项目测试工作说明项目测试流程项目立项制订测试计划 软件开发设计文档软件需求文档测试用例设计单元测试集成测试系统测试测试执行撰写测试报告测试结果整理分析研发经理审查递交报告系统达不到上线要求测试退出符合上线要求项目现状需求不清晰：由于客户对信息化系统接触较少，无法提供详细明确的业务需求 ，致使我们的需求人员对用户的需求无法进行鉴别、综合和建模，清除用户需求的 模糊性、歧义性和不一致性，分析系统的数据要求，为原始问题及目标软件建立逻 辑模型。 软件设计不充分：依据需求文档，开发要将实际业务需求转化为软件功能需求 ，并出具详细的软件规格说明书。目前开发只提供差异化文档并未出具详细的软件 功能设计说明

2、文档，对功能实现没有一个完整开发业务逻辑说明 功能实现不到位：可能由于开发周短或者公司缺乏技术底蕴或者使用某种框架 技术的限制无法将功能做到完全满足功能需求（包括隐含的）或者易操作和人性化 方面做的不足 系统代码较脆弱：由于代码设计没有考虑周全以及缺乏异常处理机制，经常遇 到报黄页，或者页面缓存太过严重等问题经常出现 系统优化不彻底：随着项目的越来越多，一些老问题一直没有修改，一些功能 需要重构一直没有重构。 用户业务差异化太大：同一个业务不同的客户不同的功能需求，我们的系统配 置项越来越多。如何做好我们的测试工作我是一个业务专家：对目前的系统业务要熟练掌握，这个功能是干什么的？该 功能有什么

3、样的业务关联？这个操作会引发系统怎样的影响？这个功能有几种配置 ？每个配置都是基于什么样的功能场景？为什么有这样的功能操作逻辑？它的优势 是什么？等等 我是一个客户：我的角色就是一个客户，我要体验系统是不是很人性化，功能 实现是不是符合我的要求，界面是不是一看就知道我得到了什么信息，如何去操作 ？一些重要操作是不是有提醒功能避免误操作或者提下一步操作提示？ 我是一个逻辑缜密的人：这个功能实现关联多个功能，他们是否能够协调正常 工作？这个业务流程有多少个环节每个环节是否能够读取正确的数据？业务功能变 更对前后关联的业务影响有多大？ 我是一个优化专家：功能实现是不是存在可以优化的地方，功能实现是否

4、有漏 洞存在影响用户的正常使用?功能实现是否存在不足可以，那些功能是冗余无用的 ？哪些功能尚未使用？ 我是一个追究思源的人：为什么功能这样实现，它的业务需求是什么？它的功 能目标是什么？在一个什么样的业务场景下进行使用？它的使用对象是那些人，业 务关联都那些人？测试计划俗话说：凡事预则立，不预则废！不论做什么事，事先有准备，就能得到成功，不 然就会失败。项目测试在实施前就要制订测试计划。 测试计划Testing plan，描述了要进行的测试活动的范围、方法、资源和进度的文 档。它确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。测试计划可 以有效预防计划的风险，保障计划的顺利实施。

5、测试计划编写6要素 1）Why：为什么要进行这些测试：【编写目的】 2) What：测试哪些方面，不同阶段的工作内容：【测试范围】、【测试目标】、 【质量目标】 3) When：测试不同阶段的起止时间：【测试进度】 4) Where：相应文档，缺陷的存放位置，测试环境等；【参考文档】、【测试交 付文档】、【软件资源】、【硬件资源 】 5) Who：项目有关人员组成，安排哪些测试人员进行测试 【人力资源】 6) How：如何去做，使用哪些测试工具以及测试方法进行测试。【测试技术】、 【测试策略】、【风险和约束】、【测试退出标准 】测试执行测试执行的内容包括功能测试、集成测试、系统测试（回归测试）

6、。 功能测试：即某一单个功能的测试。功能测试的要点如下：功能实现满足用户需求（功能实现与需求及设计相一致）功能最优化（操作便捷不复杂、界面友好好理解、信息提示温馨易懂）功能健壮性（如格式校验、异常处理机制、缓存机制、必填项校验）功能权限（数据权限、操作权限）功能关联（输入数据来源、输入数据去向）功能操作逻辑（增删改查的操作顺序和操作条件） 集成测试：多个功能融合在一起进行的测试.一般用于业务流程测试和业务关联测试:上一个功能的输出结果是否可以作为本次功能的输入上一个功能的输入结果是否可以作为本次功能操作可操作数据项之一最后一个功能的输出结果是否影响了上一个或上上一个功能的操作 系统测试：系统的

7、全部功能整合在一起进行的测试，其目的：校验功能的正确性、业务流程操作的正确性、数据流转的正确性功能测试交付文档功能测试交付单是测试人员对某一个功能测试完毕之后需要交付的一个文档。该文 档描述了测试人员测试一个功能的全部过程，如业务了解度、测试点、业务逻辑、业务 关联性、业务的待优化建议等内容。 功能描述：对被测试功能进行概括介绍。 功能操作逻辑：通过操作逻辑图反映该功能的增删改查及其他操作功能的顺序 及操作条件 功能关联业务：说明被测试功能相关联的业务 功能测试结果：详细描述被测试功能的测试功能点及测试结果 关联业务测试结果：详细描述被测试功能关联业务关联的正确性 功能优化建议：对功能实现提出

8、优化建议 编写该文档的优势： 规范测试人员的测试工作 从文档中检测测试人员的测试是否完整 将测试人员忽略的测试点找出来保证测试覆盖度的最大化 检测测试人员对该功能的认知度功能测试过程中我们应该做的在功能测试过程中我们会遇到很多问题。如需求不明确、开发实现功能与需求或设计不相符等 等，那么我们该如何解决呢？ 需求不明确：首先我们要找到需求人员了解该业务需求，其次要求需求人员在需求文档中补充 该需求的详细内容或者要求需求人员通过邮件的形式告知测试以及开发人员该需求的详细内容 功能实现与需求设计不一致：首先找到功能实现的开发人员确认不一致的原因，如果是经上面 领导确认过的则需要找到项目负责人进行证实

9、，并发送邮件进行告知变更原因及变更结果；如果是 开发人员私自变更，可拒绝测试并通过发邮件告知项目负责人。 隐含功能开发测试理解有误差：有些隐含功能开发实现与测试理解不一致，则可通过与开发人 员沟通，若双方坚持已见且无认可的妥协方案，同需求及项目负责人进行协商，将最终的方案通过 邮件进行告知 功能优化：由于设计方案欠缺考虑导致实现的功能有许多的隐患问题，如操作不简便，页面不 美观、没有达到引导客户操作的功效，提示信息不友好或者看不懂等，测试人员要给予优化的建议 。 特殊操作缺乏提示：如删除前的确认框提示、不可回退操作的确认提示、或者隐含生成其他记 录的提示等更能体现我们系统的人性化 功能交换测试

10、：我们每个人都有自己的优势，是别人无法比拟的，有的人注重逻辑，有的人注 重细节，有的人倾向于界面，一个功能的完整的测试不是一个人能完成的，功能交换测试能够最大 程度的提高测试质量和测试覆盖度功能测试过程中我们必须要注意的一个系统有很多业务功能要进行测试，一个系统的功能也不是由一个人来完成测试 工作的，因此，一个系统功能的测试由多个人进行分工完成的，在这样的情况下，有些 测试人员可能只会测试自己负责的功能，不会关注别人测试的功能，这种测试态度是不 正确的，测试人员和开发人员不一样，只知道自己负责开发的业务即可，熟悉系统业务 是测试人员的基本技能，不是局部而是全部。一个测试人员具备了掌握全系统的业

11、务你 才可以做到: 1)新功能设计上可以评估设计是否考虑周全 2)清晰的知道哪些关联业务需要测试 3)在新功能设计上给予指导性的建议 4)你有资格成为一个业务专家 5) 提高测试覆盖度确保测试质量 6)在整体业务把握的基础上提升测试思维的高度和测试意识 7)分析定位系统Bug是什么原因造成的 8）系统变更带来的影响和风险评估 9）培养缜密的逻辑思维，做到举一反三，化整为零，聚零为整 10）从软件业务领悟实际业务，实际业务转化软件业务缺陷跟踪管理流程发现缺陷确认缺陷提交缺陷分析缺陷测试主管测试人员提交缺陷后续修改修改缺陷缺陷存档项目经理分配缺陷开发人员验证缺陷测试人员关闭缺陷验证通过验证不通过

12、后续缺陷修改缺陷跟踪我们应该做的缺陷跟踪是缺陷发现、提交、分配、修正、校验这样的一个过程。缺陷跟踪可以衡量一个测试 人员的测试力度，也是保证软件质量一个重要环节。通过缺陷管理可以反应开发的质量，为软件上 线提供依据。缺陷跟踪过程中我们应该做的如下： 发现缺陷，能够定位缺陷的级别，缺陷修改的缓重轻急 发现缺陷，能够分析缺陷产生的原因，方便开发修改缺陷定位问题所在 发现缺陷，缺陷描述要简洁易懂，尽量不要给开发或他人造成误解或者不解 提交缺陷，要分类汇总生成缺陷反馈文档 提交缺陷，将缺陷反馈文档放置指定位置并通过邮件告知测试主管或测试负责人 缺陷确认，通过缺陷描述确认该缺陷是否为真正的缺陷 缺陷确认

13、，要通过缺陷描述操作系统重现缺陷进行确认 缺陷确认，确认该缺陷的级别，轻重缓解是否得当 缺陷验证，确认开发修复缺陷是否正确 缺陷验证，确认开发修复缺陷的同时是否产生了新的缺陷 缺陷验证，验证通过的缺陷要及时修改缺陷的状态，必要时添加验证备注说明 缺陷验证，将验证不通过的缺陷进行缺陷状态的修改，并通过邮件方式告知开发人员进行修改 ，并监督直至验证通过 将未修复延期修复的缺陷进行整理一个单独的文档进行存放并通过邮件告知相关人员缺陷跟踪我们必须要注意的发现了缺陷，开发不认可，或者开发通过非正常手段来解决问题等等情况我们如何 来应对来减缓测试和开发的这种敌对状态和通过什么样的方式来解决问题。 开发不认

14、可这是个缺陷：我们可以给开发讲为什么是缺陷，有什么样的严重后患来 证明就是个缺陷，如果开发还是不认可，我们可上诉至测试主管和项目经理进行最后的 确认，如果是缺陷开发必须进行修改，如果认为不是缺陷或者可延期修改，必须在缺陷 反馈文档增加备注说明，并通过邮件的方式告知相关人员 开发通过非正常手段修复缺陷:开发不是修改代码修复缺陷，而是隐藏代码掩盖了 缺陷的重现操作等非正常手段间接修复缺陷，我们将此情况上诉至测试主管和项目经理 ，通过协调给予最终的解决方案，通过邮件方式将解决方案告知相关人按照方案开发进 行修改，测试进行校验，并在缺陷修复备注给予说明 开发迟迟不修改缺陷：对于已经确认并要修改的缺陷，

15、开发迟迟不予修改，则测试 人员需要时时询问缺陷修复的时间，如果时间拖的过久需要项目经理以邮件的方式进行 告知缺陷修复的具体时间或近期不能修复的原因。 开发修复缺陷出现后遗症：开发修复缺陷可能会引发新的缺陷的产生，因此要求我 们在校验缺陷的同时，必须校验相关功能的其他操作是否正常。 延期缺陷的追踪：有些缺陷被延期，可能由于相关方面的原因无暇顾及这些遗留缺 陷而将缺陷一而再再而三的搁置最终不了了之。因此要定期的追踪项目经理遗留缺陷的 修复工作缺陷反馈文档缺陷追踪管理有两种方式，通过缺陷管理工具进行管理，另外是通过缺陷文档进行 管理。无论是缺陷管理工具还是缺陷文档，缺陷基本信息包括如下： 缺陷位置：

16、描述缺陷所在的功能模块菜单页面 项目名称：缺陷出现的项目名称 项目版本：缺陷出现在的项目的哪个版本当中 缺陷标题：概括描述功能缺陷 缺陷描述：描述缺陷产生的操作步骤导致的实际系统反应与期望结果不一致 缺陷级别：缺陷的严重程度（改善性、一般、严重、致命） 缺陷优先级：缺陷处理轻慢缓急度（有空改改、正常处理、高度重视、立即解决） 提交时间：缺陷提交时间 缺陷状态：已提交、已分配、待验证、已关闭、无效 提交人：发现并条件缺陷的测试人员 修改人：修复缺陷的开发人员 修改时间：缺陷修复时间 验证人：验证缺陷的人 验证时间：验证缺陷的时间 备注：填写缺陷从提交到验证过程中的重要说明缺陷级别定义改善性缺陷：由问题提出人对测试对象的改进意见或测试人员提出的建议、质疑。 一般缺陷：次要功能没有完全实现但不影响使用。如提示信息不太准确，或用户界 面差，操作时间长，模块功能部分失效等，打印内容、格式错误，删除操作未给出提示 ，数据库表中有过多的空字段等 严重缺陷：系统的主要功能部分丧失、数据不能保存，系统的次要功能完全丧失。 问题局限在本模块，导致模块功能失效或异常