站长工具域名查询社区,seo网络营销优化,网站建设企业战略,高端大气网页需求分析
跟同事之间探讨客户需求
对需求文档进行测试 互相交换想法
2、需求评审
如何评审
首先提前一天发邮件给格个参会人员#xff0c;准备参与XXX项目需求评审
参与人员#xff1a;产品经理#xff0c;项目经理#xff0c;研发负责人#xff0c;研发小组成员准备参与XXX项目需求评审
参与人员产品经理项目经理研发负责人研发小组成员测试负责人测试小组成员
然后开始会议主要分析产品需求的合理性开发考虑这个需求可不可以实现测试考虑能不能给用户带来更好的使用体验。
3、根据需求编写测试计划
确定需求分析说明书是制订测试计划的基本依据
测试计划的定义 软件测试计划是指导测试过程的纲领性文件 测试计划包含的内容 概述测试目的、参考文档、缩略语)
测试范围(测试范围要测试哪些模块)
测试组网图(系统架构图、组网图)
资源需求(硬件资源需求、软件资源需求、人员需求)
测试条件(测试版本启动、测试版本停止、测试版本挂起的准则
测试进度(测试所有活动的时间安排是测试需求分析、测试用例、测试轮次的时间安排)
测试准则测试用例通过、测试用例失败、回归的准则、培训计划
人力风险
1人力资源不够 解决方式按照项目计划测试计划准备好测试需要的人力
2测试用例未被完全执行 解决方式:在测试留存中严格控制测试的执行.抽查,责任归个具体的人
3人员流动测试人员对业务不熟悉 解决方式:做好人员流动的准备,加大业务培训
需求风险
1 需求人员,测试人员,开发人员对需求的理解不一致
解决方式加强需求评审和沟通
2后期需要小的变更点,没有引起重视,未知会到测试
解决方式:项目流程控制,所有变更必须知会测试进行测试和分析
3 需求变动大导致测试工作量增加,可能导致的测试不充分
解决方式:通过加班延长测试时间,加大测试人员投入,保证测试充分
开发风险
1开发提测的时间晚于原计划导致测试时间被压缩
解决方式开发把握好计划送测的时间做好晚送测的测试准备加班或加入人力等
2开发修复bug考虑不周全带入新的缺陷
解决方式:bug验证要考虑好相应的场景回归相关的功能
环境风险
测试环境与线上环境差异过大导致环境问题
解决方式:尽量使用和线上环境差异少的测试环境条件允许可模拟一套与线上相近的测试环境来做项目最后的回归测试或安装测试
测试计划的目的
粗略地估计测试大致需要的周期和最终测试报告递交的时间
4、编写测试要点
根据需求编写测试点 一个需求点包含N个测试点
5、编写测试用例 部分公司有要点也有用例大部分公司有测试要点就没有 测试用例没有测试要点就写测试用例二取其一
什么是测试用例 测试用例是一份测试文档它描述输入、操作步骤、和一个期望的结果其目的是确定应用程序的某个特性是否正常的工作是测试执行的依据
测试用例的组成内容
所属产品
所属模块
用例编号
用例名称
前置条件
操作步骤
预期结果
实际结果 测试人员
5、用例评审 评审分类 1、部门评审测试部门全体成员参与的评审。
2、公司评审这里包括了项目经理、需求分析人员、架构设计人员、开发人员和测试人员。
3、客户评审包括了客户方的开发人员和测试人员。这种情况在外包公司比较常见
评审内容
1、用例设计的结构安排是否清晰、合理是否利于高效对需求进行覆盖。
2、优先极安排是否合理。
3、是否覆盖测试需求上的所有功能点。
4、用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确期待结果是否有明显的验证方法。
5、是否已经删除了冗余的用例。
6、是否包含充分的负面测试用例。充分的定义如果在这里使用2 8法则那就是4倍于正面用例的数量毕竟一个健壮的软件其中80%的代码都是在“保护”20%的功能实现。
7、是否从用户层面来设计用户使用场景和使用流程的测试用例。 8、是否简洁复用性强。例如可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。
搭建测试环境等待开发转测试提测提测的准则冒烟测试通过根据用例来执行测试
测试不通过的应在缺陷报告当中记录
缺陷报告的内容
所属产品
所属模块
影响版本
Bug类型
Bug标题
严重程度
Bug状态
优先级
重现步骤
附件
提交bug后还需对bug进行跟踪
测试完毕编写测试报告
一直反复测试2-3轮过后才确认测试结束
测试报告的内容
简介 (产品名称、版本号、参考文档)
测试资源描述 (地点、人物软件测试环境、硬件测试环境测试组网图测试仪器)
测试时间统计 (测试任务的时间这里面的时间是详细的每个版本的细分时间统计)
测试用例分析 (测试用例执行情况分析哪些用例通过了哪些发现问题了),
缺陷情况分析 (分布情况、严重程度、遗留问题)
测试版本质量分析 (测试版本的质量怎么样描述一下)
测试活动评估 (测试活动及写测试用例脚本方面的质量方面描述一下)
测试过程改进 (改进的建议)
