测试需求报告.ppt

测试需求分析 --by 唐晓文 content 前言 举例对比两种需求分析方式（粗略、详细） 总结需求分析要注意的问题 常见典型需求有哪些容易遗漏 目录 content 测试需求分析工作的特点 前言 1、分析越详细、确认得越多，做得越多，但返工少，质量好。 2、不要指望开发人员会确认全部需求，有时候他宁愿不说，便可以按照他擅长的方式做，但这也许并不是产品人员所希望的。 3、对于需求的理解，测试人员一定要比开发理解得深刻。 4、想发现问题，不仅要从用户角度想，也要从开发角度想。 5、想得越透彻、测试越轻松、越保险。 案例分析 “将所有的访问者都记录下来，对每次访问要记录访问开始时间、访问结束时间、访问者的IP地址这三个信息作为一条日志记录。要求以天为单位每天生成一个访问记录日志文件。” 以上需求描述清晰吗？有什么问题？如何分析？ 粗略的分析需求 需求功能 【分析的结果】 功能操作的数据 1、记录用户访问日志 2、以天为单位生成日志文件 So easy！ 就是把访问开始时间、结束时间、IP地址记录到日志文件里，OK，开始开发。 1、访问开始时间 2、访问结束时间 3、访问者的IP地址 各种和预期不符 测试时发现 各种需求再确认 各种重新开发 测试时间又少了 不对，文件保存成这个格式无法在报表上展现。 不对，用户访问出错没记录，怎么办？ 之前没人说要限制文件大小的嘛！ 加个日志模块，怎么把功能影响到了？！ 到了测试时才发现 详细的分析需求 是否描述清晰 是否存在遗漏或漏洞 1、每天生成一个日志文件，什么时候创建，几点创建？ 2、何时记录？访问请求收到后记录一次，访问完记录一次，还是整个请求完成后记录？ 1、 用户访失败后是否记录进日志？哪个字段保存？ 2、如果收到访问请求后立即记录，用户访问失败会被记录成功，而实际上用户并没有成功访问到该页面。 详细的分析需求 是否影响旧功能 其他质量要求 日记记录模块如果报错，是否会影响到用户正常访问？ 加了日志记录模块，如何保障现有功能不受影响？ 1、当日日志文件保存的数据量超大后如何处理？文件太大导致打不开、无法使用。是否要分段保存？ 2、是实时读写文件记录日志吗？实时保存的效率问题。 3、日志文件不存在或保存日志文件的机器宕机需要容错吗？ 详细的分析需求 挖掘隐式需求 开发实现上要确认的问题 1、除了描述中提及的访问时间和IP地址外，访问者还有哪些属性呢？只记录时间和IP能否满足运营分析需求？ 2、日志文件记录给谁看、谁用？对方有什么要求？ 1、每条访问记录是以什么格式来记录？是否有特殊要求？ 2、日志文件文件名，存放位置，文件格式（二进制？文本？以什么符号分隔？）文件内容、文件创建时间、文件大小、文件访问权限等属性需要确定。 3、是实时读写文件吗？还是先存到数据库再定时生成文件。 哪些问题需要我们发现 定义是否清晰 描述无二义性、各种输入输出限制、约束条件均已限定，并且量化。无其他疑问和可能性。 需求是否合理 有无前后矛盾冲突的需求？设计是否合理？符合用户习惯和行业规范？ 是否存在漏洞 流程逻辑是否完整的考虑了开始结束并形成闭环？所有分支是否都有相应处理？所有可能的情况是否都想到？ 哪些问题需要我们发现 是否影响旧功能 是否与原逻辑相冲突？是否会改变原有逻辑？相关的功能是否会被影响？数据是否被破坏导致其他业务方无法使用？ 需求是否可测 所有需求是否可测，且快速可测？如有需要开发工具的要提前想好提出，提高测试效率。 其他质量要求 要确认是否有性能、安全、兼容性方面的质量要求。且这些质量要求要细化成数据、指标或具体要求。 哪些问题需要我们发现 挖掘隐式需求 是否与原逻辑相冲突？是否会改变原有逻辑？相关的功能是否会被影响？数据是否被破坏导致其他业务方无法使用？ 开发需求问题 按照目前理解是否能开发了？怎样实现？或还需确认哪些内容才能实现？从开始到结束是否都能实现？有何难点、瓶颈？ 需求重点明确 此次需求哪些是产品、用户关注重点？哪些是开发难点？需求优先级是否明确？产品要求是否明确？ 需求快速确认表 小试牛刀 案例需求分析： 从管理后台或Android手机客户端上传图片（保存在第三方平台）。在我方的Android手机客户端中规定模块展现显示图片。 大家开始提问或讨论！ 问题列举 上传图片类型、大小限制。 上传下载的接口性能，最大支持多大并发，响应速度？ 上传后图片以什么形式保存在哪？重命名、自动压缩？ 上传重复图片是否允许？（同名重复） 上传过程中遭遇网络闪断如何处理？（主要是客户端） 支持多图片上传还是单图片上传？多图片同时上传是全部传完才算成功还是传了多少算多少？上传失败的图片忽略不计？ 客户端查看图片接口崩溃后是否会有友好提示？ 客户端是否有图片缓存？缓存