O2O商城测试流程

《O2O商城测试流程》由会员分享，可在线阅读，更多相关《O2O商城测试流程（9页珍藏版）》请在装配图网上搜索。

1、O2O商城测试流程1目标定制完整且具体的测试路线和流程，为快速、高效和高质量的软件测试提供基础流程框架。终目标是实现软件测试规范化，标准化。人性化2 测试流程说明3 测试需求分析测试需求是整个测试过程的基础；确定测试对象以及测试工作的范围和作用。用来确定整个测试工作（如安排时间表、测试设计等）并作为测试覆盖的基础。而且被确定的测试需求项必须是可核实的。即，它们必须有一个可观察、可评测的结果。无法核实的需求不是测试需求。所以我现在的理解是测试需求是一个比较大的概念，它是在整个测试计划文档中体现出来的，不是类似的一个用例或者其他.测试需求是制订测试计划的基本依据，确定了测试需求能够为测试计划提供客

2、观依据；测试需求是设计测试用例的指导，确定了要测什么、测哪些方面后才能有针对性的设计测试用例；3.1 测试方法与规范3.1.1测试方法随着软件技术发展，项目类型越来越多样化。根据项目类型应选用针对性强的测试方法，合适的测试方法可以让我们事半功倍。以下是针对目前项目工程可以参考的测试方法： 兼容性测试兼容性测试是指测试软件是否可以成功移植到指定的硬件或者软件环境中，例如在B/S项目中各个不同浏览器之间的测试。 用户界面测试-UI测试用户界面测试，英文是Userinterfacetesting。又称UI测试。用户界面，英文是Userinterface。是指软件中的可见外观及其底层与用户交互的部分（

3、菜单、对话框、窗口和其它控件）。用户界面测试是指测试用户界面的风格是否满足客户要求，文字是否正确，页面是否美观，文字，图片组合是否完美，操作是否友好等等。UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。 冒烟测试冒烟测试，英文是Smoketesting。冒烟测试的名称可以理解为该种测试耗时短，仅用一袋烟功夫足够了。也有人认为是形象地类比新电路板功基本功能检查。任何新电路板焊好后，先通电检查，如果存在设计缺陷，电路板可能会短路，板子冒烟了。冒烟测试的对象是每一个新编译的需要正式测试的软件版本

4、，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。 随机测试（自由测试）随机测试，英文是Adhoctesting。随机测试没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行用例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试样例(TestCase)没有覆盖到的部分。另外，对于软件更新和新增加的功能要重点测试。重点对一些特殊点情况点、特殊的使用环境、并发性、进行检查。尤其对以前测试发现的重大

5、Bug,进行再次测试，可以结合回归测试(Regressivetesting)一起进行。 黑盒测试(功能测试)黑盒测试，英文是BlackBoxTesting。又称功能测试或者数据驱动测试。黑盒测试是根据软件的规格对软件进行的测试，这类测试不考虑软件内部的运作原理，因此软件对用户来说就像一个黑盒子。软件测试人员以用户的角度，通过各种输入和观察软件的各种输出结果来发现软件存在的缺陷，而不关心程序具体如何实现的一种软件测试方法。 性能测试性能测试，英文是PerformanceTesting。性能测试是在交替进行负荷和强迫测试时常用的术语。理想的“性能测试”(和其他类型的测试)应在需求文档或质量保证、测

6、试计划中定义。性能测试一般包括负载测试和压力测试。通常验证软件的性能在正常环境和系统条件下重复使用是否还能满足性能指标。或者执行同样任务时新版本不比旧版本慢。一般还检查系统记忆容量在运行程序时会不会流失(memoryleak)。比如，验证程序保存一个巨大的文件新版本不比旧版本慢。3.1.2测试规范测试规范是根据开发规范而制定的测试标准，测试规范也是后期测试用例编写的重要依据。因为开发规范因公司而异，因产品而异，所以测试规范的标准程度每个公司都不一样。从理论到方法到各类流程到各类报告模版，都属于测试规范的范畴，当一整套规范形成之后，可使得测试工作进行更加稳健，所有问题有据可查。32软件需求规格说

7、明书软件需求规格说明书是软件达到的各项功能的目标。是测试人员各项工作的依据，没有需求就无法判断测试结果是正确的。33软件设计说明(概要与详细设计)设计说明书包含软件的一些框架、字段、数据库设计等。软件设计说明对测试工作开展有很大影响，没有软件设计说明很多问题将无法溯源，测试准备的前期工作也是根据软件设计说明来制定的。34页面原型（demo页面原型是项目人员快速熟悉项目的最佳路径。在需求不够明确，设计说明书不够全面的情况下，页面原型也是后期测试用例编写思想的重要根据。.index.html4 测试过程设计明确测试目的，最终达成目的并验证结果是测试要做的事情。包括：1. 测试范围：描述本次测试中的

8、测试范围，如：测试软件功能范围、测试种类等。2. 简单的描述如何搭建测试平台。3. 项目信息：说明要测试的项目的相关资料，如：输入输出文档，产品描述，软件主要功能。4. 人力资源的分配。5. 测试需求：笼统说，就是测试中的所有设计和需求文档。作为本次测试的依据4.1 测试策略制定 这一阶段在于需求、详细设计、测试计划完成之后，主要是本次测试的策略阶段。很多公司少这个一个阶段，需要有计划性的分出产品的功能扣出测试的功能点，现阶段大多公司都是直接拿着文档就开始做用例设计。 对需求进行分析，列出具体的功能列表。（一般根据功能交互文档就能明确出此功能的大体功能，一层层的分下去，一直到没个功能表单。然后

9、考虑到使用那些测试方法？工作一旦做到执行阶段，我们可以更好的根据这些功能表一点一点的覆盖也能让我们在用例评审时，充分的证实我们的工作是有效的能够保证产品的质量。）一般在此之前，一些业务培训和需求评审是有必要是听一下的。这样能够更早更熟练的理解需求。 对于一个个测试该如何进行测试？如下：a）功能测试 功能范围（划分出各自负责的功能模块） 使用测试方法（等价类、边界值等测试方法方法） 测试标准（符合设计、需求和规范文档对该功能的描述）b）界面测试c）兼容性测试4.2 测试计划1）要充分考虑测试计划的实用性，即测试计划与实际之间的接近程度和可操作性。编写测试计划的目的在于充分考虑执行测试时的各种资源

10、，包括测试内容、测试标准、时间资源、人力资源等等，准确地说是要分析执行时所能够调用的一切资源以及受各种条件限制等。a）测试内容：对一个软件来说测试计划中会明确本次测试做哪些测试？如：系统测试：在整个系统测试中会有（界面测试、功能测试、性能测试、兼容性测试、安装卸载测试、可靠性测试等测试）。b）测试目的：一般多为保证产品质量是否达到预期的指标。这个指标也就是在测试中定义的结束标准。c）测试标准：需要考虑本次测试需要输入那些文档，该项目结束标准定义、测试结束标准的定义？bug级别定义、优先级定义、bug管理流程定义。这个都需要在执行测试事明确。计划中应该包含这些内容。d）资源分配：这里分为人力资源

11、、软硬件资源等划分。一般会把人力资源的利用写入一个测试人员任务分配表里，按照不同的阶段，每个阶段提交相应的成果（难度很大）。软硬件资源中主要是在做计划时考虑到需要多少电脑或别的工具，列出清单。e）测试风险：大多考虑到的就是项目开发延期、测试人员不足用例无法全面覆盖测试点、时间不足用例无法全部执行、bug无法及时修改导致无法验证、测试人员技能不足导致测试进度拉长。4.3测试附件 用例模板、缺陷报告模板（请见测试计划） 测试环境的搭建 缺陷管理流程和缺陷级别定义（划分）缺陷状态一般分为：新建、打开、已分配、已修复、关闭、重新打开中间会有：延期、重复、拒绝等状态缺陷管理流程： 若不是，就会指派相应的

12、人或跟测试者讨论 若是，进行处理，resolved（）并给出解决方法。（可创建补丁附件及补充说明）3.测试人员查询开发者已修改的bug,进行回归测试。 经验证无误后，修改状态为verified（验证）。待整个产品发布后，修改为closed（关闭）。 还有问题reopened（重新开放），状态重新变为“new”并发送邮件通知。缺陷等级划分：本规范定义以下五类缺陷，供参考，具体产品的缺陷类型定义可根据产品特点进行调整级别符号概述详述致命A系统任何一个主要功能完全失效，系统无法安装、登陆或其他主要功用户数据受到破坏，系统崩溃、悬能不可用挂、死机或者危机人身安全死循环或内存不足等原因导致程序无法运行由

13、于程序引起的系统无法启动、死机、蓝屏、非法退出在数据或安全方面存在重大问题严重B系统的主要功能部分失效,数据不冃匕保存，系统的次要功冃匕兀全丧失，系统所提供的功能或服务受到明显影响 基本功能存在部分问题或次要功能无法实现或遗漏 未进行异常处理 性能与预期相差很大一般C系统的次要功能没有完全实现，但不影响用户的正常使用。 次要功能没有完全实现，但不影响用户使用本产品 界面存在明显缺陷，设计不友好 提示信息不准确 一般的性能问题轻微D使操作者不方便或遇到麻烦，但它不影响功能的操作和执行 界面格式显示不规范 建议性的改进要求建议E功能性建议，功能使用性、方便性、易用性不够 个人感觉不好的方面 个人的

14、见解5 测试实施5.1执行开发就会转版本给我们测试部门进行系统测试了。拿到版本我们首先搭建测试环境做一个预测试，目的是来评断这个版本是不是可测试的。如果预测试不通过，打回开发部返工，如果通过了，就开始我们第一轮的系统测试。 第一轮系统测试我们会执行我们所编写的所有测试用例，做好测试结果的记录，发现缺陷了提交缺陷报告。当第一轮测试结束后，我们把所有的bug单提交给开发人员，由他们进行修改。 在他们修复bug期间,我们会对第一轮系统测试做一个测试评估，出一个测试报告。开发改bug结束，提交一个新的版本给我们，我们重新搭建测试环境开始第二轮系统测试。首先是回归我们提交的缺陷报告，然后会在用例中挑选一

15、些优先级别比较高的用例来进行测试，发现问题了继续提交缺陷报告，只到缺陷率低于用户要求了，我们就进行最后一轮的回归测试，结束系统测试。6 测试评估执行阶段结束了进入测试评估阶段，我们会出一个总的测试报告对我们测试的这个过程和版本的质量做一个详细的评估。6.1测试总结报告在所有测试任务完成之后，测试负责人将要编写测试总结报告，对测试进行总结，并且提交给全体项目组，为产品的后续工作提供重要的信息支持。过程要点详细描述输入条件测试组完成了所有的测试执行工作工作内容测试负责人根据测试的结果，按照测试报告的文档模板编写测试报告，测试报告必须包含以下重要内容： 测试资源概述多少人、多长时间 测试结果摘要一一

16、分别描述各个测试需求的测试结果，产品实现了哪些功能点，哪些还没有实现 缺陷分析一一按照缺陷的属性分类进行分析 测试需求覆盖率一一原先列举的测试需求的测试覆盖率，可能一部分测试需求因为资源和优先级的因素没有进行测试，那么在这里要进行说明 测试评估一一从总体对项目质量进行评估退出标准测试负责人完成了符合标准的测试报告，发送给全项目组责任人测试负责人责任人项目经理6.2测试归档测试归档是在测试验收结束宣布测试有效、结束测试后，对测试过程中涉及到各种标准文档进行归类，存档。过程要点详细描述输入条件测试工作完成工作内容归类，存档测试过程涉及到的文档，主要包括以下文档（必须）测试计划书 测试用例书 测试报告书（一轮测试） 测试总结书退出标准全部文档归类完毕，版本号封存责任人测试负责人