1、O2O 产品验收标准编写人：王图坤编写时间：2015-02-26目录一、 引言 .3二、 验收项目和验收标准 .32.1 验收项目 .32.1.1 功能项测试 .32.1.2 业务流程测试 .32.1.3 容错测试 .32.1.4 安全性测试 .42.1.5 性能测试 .42.1.6 易用性测试 .42.1.7 兼容性测试 .42.1.8 文档测试 .52.1.9 特别要求的测试。 .52.2 验收标准 .52.2.1 产品错误的严重性等级( 如表 1、2 所示) .52.2.2 验收标准 .52.2.3 验收标准详细说明 .72.3 验收流程 .82.3.1 冒烟测试 .82.3.2 常规测
2、试 .82.3.3 第三方测试 .82.3.4 回归测试 .82.3.5 验收完成发布产品 .9三、 结束语 .9一、 引言鉴于目前公司强制性统一的产品验收标准的情况, 现 O2O 事业部自行制定了以下验收标准文档供验收参考，参考人员包括但不限于前端、开发、产品、测试、QA 人员。对一般互联网公司而言，三种人需对产品的质量进行控制：测试、QA 和产品经理。测试人员是负责“挑问题”的;QA 是负责“尽量不出现问题”的;产品经理是负责“是否有问题”的。对互联网产品而言，验收有三层含义： 产品功能需求用例化后，用例执行符合预期 与需求吻合，正向操作的用户体验良好 设计和前端 UI 符合评审的标准二、
3、 验收项目和验收标准验收项目2.1.1 功能项测试对产品需求规格说明书中的所列举所有功能项进行测试。2.1.2 业务流程测试对产品项目中的典型业务流程进行测试，含：正向流程、逆向流程、异常流程。2.1.3 容错测试容错测试的检查内容包括:1) 产品对用户常见的误操作是否能进行提示;2) 产品对用户的操作错误和产品错误, 是否有准确、清晰的提示;3) 产品对重要数据的删除是否有警告和确认提示;4) 产品是否能判断数据的有效性, 屏蔽用户的错误输入, 识别非法值, 并有相应的错误提示。2.1.4 安全性测试安全性测试的检查内容包括:1) 产品中的密钥是否以密文方式存储;2) 产品是否有留痕功能,
4、即是否保存有用户的操作日志;3) 产品中各种用户的权限分配是否合理。2.1.5 性能测试对产品需求规格说明书中明确的产品性能进行测试。测试的准则是要满足产品需求规格说明书中的各项性能指标。2.1.6 易用性测试易用性测试的内容包括:1) 产品的用户界面是否友好, 是否出现中英文混杂的界面;2) 产品中的提示信息是否清楚、易理解, 是否存在原始的英文提示;3) 产品中各个模块的界面风格是否一致;4) 产品中的查询结果的输出方式是否比较直观、合理。2.1.7 兼容性测试参照用户的软、硬件使用环境和需求规格说明书中的规定, 列出开发的产品需要满足的软、硬件环境。对每个环境进行测试。2.1.8 文档测
5、试用户文档包括: 安装升级手册、操作手册和运维手册。对用户文档测试的内容包括:1) 操作、维护文档是否齐全、是否包含产品使用所需的信息和所有的功能模块;2) 用户文档描述的信息是否正确, 是否没有歧义和错误的表达;3) 用户文档是否容易理解, 是否通过使用适当的术语、图形表示、详细的解释来表达;4) 用户文档对主要功能和关键操作是否提供应用实例;5) 用户文档是否有详细的目录表和索引表。2.1.9 特别要求的测试。如高压力、断电、断网、服务器损坏等极端测试。2.2 验收标准2.2.1 产品错误的严重性等级( 如表 1、2 所示)2.2.2 验收标准1) 测试用例不通过数的比例 3 %;2) 不
6、存在错误等级为 1 的 BUG;3) 不存在错误等级为 2 的 BUG;4) 错误等级为 3 的 bug 数量 5;5) 所有提交的错误都已得到确认，有解决方案。表 1：严重性等级定义表严重性等级 说明1 不能执行正常功能或重要功能, 或者危及人身安全。2 严重地影响系统要求或基本功能的实现, 且没有办法解决。3 严重地影响系统要求或基本功能的实现, 但存在合理的解决办法。4 使操作者不方便或遇到麻烦, 但不影响执行正常功能或重要功能。5 其它错误。表 2：错误与严重性等级对应表测试特性 错误 严重性等级没有实现应有的功能; 1没有实现部分功能, 并且没有替代方案; 2功能没有实现部分功能,
7、但有替代方案。 3业务流程存在重大的隐患; 1业务业务流程衔接错误。 2性能 不能满足性能指标 2由误操作或错误输入等导致死机或系统自动退出; 1对误操作、错误输入没有提示; 3容错没有识别非法值和错误输入, 导致错误数据存储到数据库中。3密钥以明文方式存储; 2没有留痕功能; 2安全性各种用户的权限分配不合理 2界面不友好, 出现中英文夹杂的界面; 4提示不清楚, 出现原始的英文提示; 4界面风格不一致; 4易用性查询结果输出方式不直观。 4在特定的软、硬件环境下, 不能实现应有的功能; 1在特定的软、硬件环境下, 不能实现部分功能, 并且没有替代方案;2兼容性在特定的软、硬件环境下, 不能
8、实现部分功能, 但有合理的替代方案。3文档 文档错误 52.2.3 验收标准详细说明首先, 在表 1 中定义了产品错误的严重性等级,将错误分为 15 个等级, 等级 1 为最严重的错误,而等级 5 为最轻微的错误。A. 1 级错误的描述这一级别的错误一般包括以下内容: 没有实现或错误地实现重要的功能; 产品在操作过程中由于产品自身的原因自动退出系统或出现死机的情况;产品在操作过程中由于产品自身的原因对系统或数据造成破坏; 特殊产品在操作过程中可能危及人身安全等。B. 2 级错误的描述这一级别的错误一般包括: 没有实现基本功能,并且不存在替代办法; 没有实现重要功能中的部分功能, 并且不存在替代
9、办法; 没有满足系统的性能要求。C. 3 级错误的描述这一级的错误是与第 2 级别的错误相对应的,在第 2 级错误中, 不存在替代方法, 而第 3 级错误则存在替代方法。D. 4 级错误的描述这一级别的错误通常为易用性方面的错误。E. 5 级错误的描述通常为文档方面的错误, 如安装手册、操作手册、维护手册中的描述错误。2.3 验收流程2.3.1 冒烟测试对于研发提交的测试版本，测试人员都需进行冒烟测试，如冒烟测试不通过，则开发人员需重新编译代码，直至冒烟测试通过，测试人员方可根据正式测试用例文档进行正式测试。2.3.2 常规测试测试过程中, 测试人员的依据包括但不限于产品需求规格说明书 、 测
10、试用例文档 、同时还需包括特定产品的相关行业标准。测试人员对发现的每一个 BUG 都需要依据表 2中的严重性说明来进行确定相应的严重性等级,并发现的 BUG 描述清楚录入禅道，并指定对应的人予与解决。2.3.3 第三方测试如需进行第三方的验收测试, 则测试人员需将第三方发现的所有 BUG 进行总结和归纳, 并提交完整的测评报告, 在测评报告中包括每一级别的 BUG 数量和 BUG 清单描述( 所有的错误都需经过产品经理及测试人员的确认) 都需录入禅道并指定对应的人。2.3.4 回归测试研发人员对测评报告中的所有 BUG 进行修改, 并提交给测试人员进行回归测试, 确认测评报告中的所有 BUG
11、都得到了修复，则视为验收成功，测试人员才可以向产品负责人提交发布新版本的申请;如测评报告中的 BUG 并未得到全面解决修复, 则要求开发人员在规定的时间内全面修复,并重新提交给测试人员再次进行完整的验收测试。2.3.5 验收完成发布产品产品负责人根据测评报告中每一级别的 BUG 数量和 BUG 清单与验收标准进行一一对照, 发布的产品不允许带 1 级 2 级错误 bug 发布。如特殊情况下无法避免带 BUG 发布，则 3、4、5 级错误 BUG 的数量可由产品负责人，如数量在可接受的范围内,则产品视为可以验收成功，予以发布;如错误的级别和数量在可接受的范围外, 则产品视为验收不成功，不能发布到线上正式环境，研发人员需重新编译代码解决相关问题再提交测试。三、 结束语本方案对产品开发和验收工作有一定的指导作用, 但还比较粗略, 需要在具体实践中不断完善。
