2021-01-12 10:15发布
拿到一个需求后,我们首先应该通读需求文档,先通过需求文档,对要做的需求的背景有个整体的了解,其实这个过程也是对需求文档测试的过程,对需求整体的了解后,我们可以先记录自己的一些疑惑,为后面需求的分析做一个准备工作,这个环节我们应该更多的了解一些需求的目的和一些用户的使用场景。
例:3.3版本大立案流程需求,需求文档中对于业务场景给了一个流程图
保密要求-图片忽略
从需求示意图中我们大致可以了昆明大立案的整个流程,使用的法院只有中院与基层院,主要是一个案件在基层院与中院的流转过程,使用的人员主要是法院的立案庭的人员,但是我们不知道涉及的案件主要有哪些,以及出现这样的场景是基于哪些业务逻辑,这些都是我们接下来要和需求人员了解的,这是我们分析这个需求和设计用例的基础,也是我们分析需求合理性的依据。
可以通过业务知识来分析需求的合理性,而不是单单通过系统是怎样实现的来判断需求是否合理,这也是测试人员必备的技能之一,即需要我们有深厚的业务功底,然后在通过结合系统现有的实现来分析需求的合理性。
在我看来需求是否合理主要包括两个方面:第一,满足客户需求。第二,在系统原有的基础上,尽量减少改动成本。
通过以上对需求的分析,我们就可以确定测试的范围和优先级了。首先我们要确定好这个需求所涉及的全部测试点,然后通过分析,分析出测试范围的优先级。
确定了测试范围和优先级后,就可以对各模块进行细化,可以用MindManager列出个模块下的测试点,各模块或大的测试点需要写出对应的测试方法,或测试策略。是否需要性能测试、白盒测试,是否需要提前准备数据,或会遇到什么样的测试难点,采取怎样的应对措施。
根据以往的经验我们都知道,在开发一个比较复杂的需求的周期中,测试的前期准备工作通常都是比较充足的,当然特殊情况除外,因此在确定了测试范围和优先级后,测试人员和测试负责人应该先确定一下哪些需求测试是可以提前介入的,比如,15FB新增新案件来源和新结案方式字段的需求,前期的新旧关系对应文档,测试就是可以提前进行介入,在需求完成了对应关系文档后,测试在进行重新梳理一下,这样既提高了文档的可靠性,也相当于测试提前介入测试了,规避了后面的测试的进度风险和质量风险。
做完了需求的细化后,要对自己做的需求分析从头到尾在捋一遍,查看有没有什么遗漏的,因为需求也又可能遗漏的地方。主要关注有没有场景需求没有考虑全面, 涉及的修改范围被遗漏了,以及一些特殊的关联配置没有考虑到的,另外如果需求做了一些变动也要及时补充需求分析,主要是分析变动可能带来的风险,以及准备哪些应对之策。
先确定好这个需求所涉及的全部测试点,然后通过分析,分析出测试范围的优先级。
确定了测试范围和优先级后,就可以对各模块进行细化,可以用MindManager列出个模块下的测试点,各模块或大的测试点需要写出对应的测试方法,或测试策略。是否需要性能测试、白盒测试,是否需要提前准备数据,或会遇到什么样的测试难点,采取怎样的应对措施。针对所确定的测试要点,分析测试执行时对应的测试方案/方法。
什么是需求
需求是产品必须完成的事以及必须具备的品质。
功能性需求
功能性需求是产品必须完成的那些事,要求一定的功能和品质。
例子:培训机构的班主任可以给所在班级学员打考勤
非功能性需求
非功能性需求是产品必须具备的属性或品质。诸如观感、可用性、安全性和法律限制等。
例子: 平台用户数为5万人,每天登录用户数为10000左右,网络的带宽为100M带宽。在工作时间根据资料名称条件进行搜索,可以在3秒内得到搜索结果。
这类需求通常在产品的功能确定之后(但并非总是如此)。也就是说,一旦知道了产品要做的事情,就可以确定它的行为方式,它需要具备什么品质以及它的响应速度、可用性、可读性和安全性。
限制条件
限制条件是全局性的需求。它们可以是对项目本身的限制,或是对产品最终设计的限制。
在测试前,应该对测试结果有一个初步的估计。比如,性能(IO/CPU)应该是提升,还是降低,大概幅度会有多少。这样当测试结果与预估偏差极远时,很可能测试的过程或者方法是有问题的。1) 如果是已有模块,可以参考改模块历史的测试数据。看变化是否合理。2)...
响应时间、并发用户数、TPS、吞吐量、CPU利用率、内存使用率、在线并发用户数等
性能测试是基于功能、接口完整的情况下,对服务端进行压力测试、负载测试、疲劳测试、并发测试,来发现性能瓶颈。一、负载测试。负载测试的目的主要是为了测试软件系统是否达到需求文档设计的目标;例如一款软件在一定时期内,最大支持多少并发用户数,软件请...
测试模型V模型测试阶段:单元测试集成测试系统测试瀑布模型瀑布模型(Waterfall Model) 是一个项目开发架构,开发过程是通过设计一系列阶段顺序展开的,从系统需求分析开始直到产品发布和维护,每个阶段都会产生循环反馈,因此,如果有信息未被覆盖或者发现了...
一、准备工作在什么阶段开展性能测试工作?一般情况下,是在被测系统已完成功能测试、系统趋于稳定的情况下,才会进行性能测试。1. 组建测试团队根据被测系统的实际情况,组建一个性能测试团队,团队成员包括:开发人员、运维人员、DBA和测试人员等。2. 性能需...
性能测试针对场景来讲的,在不同的场景,得出性能指标值。这些场景是真实环境有可能出现的。常见场景——压力测试,是否能长期提供服务
上面看,运行结果没有任何提示,也不知道运行到什么程度,相当不友好,那我们来美化一下吧!等等!这是个死循环,通过脚本运行自己,所以会永远运行下去。我的天,幸好发现得早。现在 更换authTest.sh,原因是这个是要运行eaidkAuth文件的,因此需要更改,否...
对于接口测试,首先测试人员要懂代码,你只需要知道接口的作用是什么就可以了,其次,自己去读开发的代码。然后,根据该接口功能及代码写测试用例:根据该接口参数,构造不同的用例,测试接口在参数合法及非法情况下能否达到预期效果,根据该接口中的逻辑,测...
如果接口 (API)已经定义好, 那就可以设计接口的测试用例了。 而且可以把用例加到 API 的spec 中,让开发人员了解这些测试用例,帮助开发出正确的代码。
最多设置5个标签!
1、 通过需求文档了解需求的实现背景
2、 分析需求合理性
3、 确定测试的范围和优先级
4、 细化测试点并确定测试方法
5、 确定哪些工作测试人员可以提前介入
6、 查缺补漏
1、 通过需求文档了解需求的实现背景
2、 分析需求合理性
3、 确定测试的范围和优先级
4、 细化测试点并确定测试方法
5、 确定哪些工作测试人员可以提前介入
6、 查缺补漏
1、 通过需求文档了解需求的实现背景
拿到一个需求后,我们首先应该通读需求文档,先通过需求文档,对要做的需求的背景有个整体的了解,其实这个过程也是对需求文档测试的过程,对需求整体的了解后,我们可以先记录自己的一些疑惑,为后面需求的分析做一个准备工作,这个环节我们应该更多的了解一些需求的目的和一些用户的使用场景。
例:3.3版本大立案流程需求,需求文档中对于业务场景给了一个流程图
保密要求-图片忽略
从需求示意图中我们大致可以了昆明大立案的整个流程,使用的法院只有中院与基层院,主要是一个案件在基层院与中院的流转过程,使用的人员主要是法院的立案庭的人员,但是我们不知道涉及的案件主要有哪些,以及出现这样的场景是基于哪些业务逻辑,这些都是我们接下来要和需求人员了解的,这是我们分析这个需求和设计用例的基础,也是我们分析需求合理性的依据。
2、 分析需求合理性
可以通过业务知识来分析需求的合理性,而不是单单通过系统是怎样实现的来判断需求是否合理,这也是测试人员必备的技能之一,即需要我们有深厚的业务功底,然后在通过结合系统现有的实现来分析需求的合理性。
在我看来需求是否合理主要包括两个方面:第一,满足客户需求。第二,在系统原有的基础上,尽量减少改动成本。
3、 确定测试的范围和优先级
通过以上对需求的分析,我们就可以确定测试的范围和优先级了。首先我们要确定好这个需求所涉及的全部测试点,然后通过分析,分析出测试范围的优先级。
4、 细化测试点并确定测试方法
确定了测试范围和优先级后,就可以对各模块进行细化,可以用MindManager列出个模块下的测试点,各模块或大的测试点需要写出对应的测试方法,或测试策略。是否需要性能测试、白盒测试,是否需要提前准备数据,或会遇到什么样的测试难点,采取怎样的应对措施。
5、 确定哪些工作测试人员可以提前介入
根据以往的经验我们都知道,在开发一个比较复杂的需求的周期中,测试的前期准备工作通常都是比较充足的,当然特殊情况除外,因此在确定了测试范围和优先级后,测试人员和测试负责人应该先确定一下哪些需求测试是可以提前介入的,比如,15FB新增新案件来源和新结案方式字段的需求,前期的新旧关系对应文档,测试就是可以提前进行介入,在需求完成了对应关系文档后,测试在进行重新梳理一下,这样既提高了文档的可靠性,也相当于测试提前介入测试了,规避了后面的测试的进度风险和质量风险。
6、 查缺补漏
做完了需求的细化后,要对自己做的需求分析从头到尾在捋一遍,查看有没有什么遗漏的,因为需求也又可能遗漏的地方。主要关注有没有场景需求没有考虑全面, 涉及的修改范围被遗漏了,以及一些特殊的关联配置没有考虑到的,另外如果需求做了一些变动也要及时补充需求分析,主要是分析变动可能带来的风险,以及准备哪些应对之策。
通过需求文档了解需求的实现背景
拿到一个需求后,我们首先应该通读需求文档,先通过需求文档,对要做的需求的背景有个整体的了解,其实这个过程也是对需求文档测试的过程,对需求整体的了解后,我们可以先记录自己的一些疑惑,为后面需求的分析做一个准备工作,这个环节我们应该更多的了解一些需求的目的和一些用户的使用场景。
例:3.3版本大立案流程需求,需求文档中对于业务场景给了一个流程图
保密要求-图片忽略
从需求示意图中我们大致可以了昆明大立案的整个流程,使用的法院只有中院与基层院,主要是一个案件在基层院与中院的流转过程,使用的人员主要是法院的立案庭的人员,但是我们不知道涉及的案件主要有哪些,以及出现这样的场景是基于哪些业务逻辑,这些都是我们接下来要和需求人员了解的,这是我们分析这个需求和设计用例的基础,也是我们分析需求合理性的依据。
2、 分析需求合理性
可以通过业务知识来分析需求的合理性,而不是单单通过系统是怎样实现的来判断需求是否合理,这也是测试人员必备的技能之一,即需要我们有深厚的业务功底,然后在通过结合系统现有的实现来分析需求的合理性。
在我看来需求是否合理主要包括两个方面:第一,满足客户需求。第二,在系统原有的基础上,尽量减少改动成本。
3、 确定测试的范围和优先级
通过以上对需求的分析,我们就可以确定测试的范围和优先级了。首先我们要确定好这个需求所涉及的全部测试点,然后通过分析,分析出测试范围的优先级。
4、 细化测试点并确定测试方法
确定了测试范围和优先级后,就可以对各模块进行细化,可以用MindManager列出个模块下的测试点,各模块或大的测试点需要写出对应的测试方法,或测试策略。是否需要性能测试、白盒测试,是否需要提前准备数据,或会遇到什么样的测试难点,采取怎样的应对措施。
5、 确定哪些工作测试人员可以提前介入
根据以往的经验我们都知道,在开发一个比较复杂的需求的周期中,测试的前期准备工作通常都是比较充足的,当然特殊情况除外,因此在确定了测试范围和优先级后,测试人员和测试负责人应该先确定一下哪些需求测试是可以提前介入的,比如,15FB新增新案件来源和新结案方式字段的需求,前期的新旧关系对应文档,测试就是可以提前进行介入,在需求完成了对应关系文档后,测试在进行重新梳理一下,这样既提高了文档的可靠性,也相当于测试提前介入测试了,规避了后面的测试的进度风险和质量风险。
6、 查缺补漏
做完了需求的细化后,要对自己做的需求分析从头到尾在捋一遍,查看有没有什么遗漏的,因为需求也又可能遗漏的地方。主要关注有没有场景需求没有考虑全面, 涉及的修改范围被遗漏了,以及一些特殊的关联配置没有考虑到的,另外如果需求做了一些变动也要及时补充需求分析,主要是分析变动可能带来的风险,以及准备哪些应对之策。
1.通过需求文档了解需求的实现背景
2.分析需求合理性
3.确定测试的范围和优先级
4.细化测试点并确定测试方法
5.确定哪些工作测试人员可以提前介入
6.查缺补漏
先确定好这个需求所涉及的全部测试点,然后通过分析,分析出测试范围的优先级。
确定了测试范围和优先级后,就可以对各模块进行细化,可以用MindManager列出个模块下的测试点,各模块或大的测试点需要写出对应的测试方法,或测试策略。是否需要性能测试、白盒测试,是否需要提前准备数据,或会遇到什么样的测试难点,采取怎样的应对措施。针对所确定的测试要点,分析测试执行时对应的测试方案/方法。
1、 通过需求文档了解需求的实现背景
2、 分析需求合理性
3、 确定测试的范围和优先级
4、 细化测试点并确定测试方法
5、 确定哪些工作测试人员可以提前介入
6、 查缺补漏
什么是需求
需求是产品必须完成的事以及必须具备的品质。
功能性需求
功能性需求是产品必须完成的那些事,要求一定的功能和品质。
例子:培训机构的班主任可以给所在班级学员打考勤
非功能性需求
非功能性需求是产品必须具备的属性或品质。诸如观感、可用性、安全性和法律限制等。
例子: 平台用户数为5万人,每天登录用户数为10000左右,网络的带宽为100M带宽。在工作时间根据资料名称条件进行搜索,可以在3秒内得到搜索结果。
这类需求通常在产品的功能确定之后(但并非总是如此)。也就是说,一旦知道了产品要做的事情,就可以确定它的行为方式,它需要具备什么品质以及它的响应速度、可用性、可读性和安全性。
限制条件
限制条件是全局性的需求。它们可以是对项目本身的限制,或是对产品最终设计的限制。
1、 通过需求文档了解需求的实现背景
2、 分析需求合理性
3、 确定测试的范围和优先级
4、 细化测试点并确定测试方法
5、 确定哪些工作测试人员可以提前介入
6、 查缺补漏
相关问题推荐
在测试前,应该对测试结果有一个初步的估计。比如,性能(IO/CPU)应该是提升,还是降低,大概幅度会有多少。这样当测试结果与预估偏差极远时,很可能测试的过程或者方法是有问题的。1) 如果是已有模块,可以参考改模块历史的测试数据。看变化是否合理。2)...
响应时间、并发用户数、TPS、吞吐量、CPU利用率、内存使用率、在线并发用户数等
性能测试是基于功能、接口完整的情况下,对服务端进行压力测试、负载测试、疲劳测试、并发测试,来发现性能瓶颈。一、负载测试。负载测试的目的主要是为了测试软件系统是否达到需求文档设计的目标;例如一款软件在一定时期内,最大支持多少并发用户数,软件请...
测试模型V模型测试阶段:单元测试集成测试系统测试瀑布模型瀑布模型(Waterfall Model) 是一个项目开发架构,开发过程是通过设计一系列阶段顺序展开的,从系统需求分析开始直到产品发布和维护,每个阶段都会产生循环反馈,因此,如果有信息未被覆盖或者发现了...
一、准备工作在什么阶段开展性能测试工作?一般情况下,是在被测系统已完成功能测试、系统趋于稳定的情况下,才会进行性能测试。1. 组建测试团队根据被测系统的实际情况,组建一个性能测试团队,团队成员包括:开发人员、运维人员、DBA和测试人员等。2. 性能需...
性能测试针对场景来讲的,在不同的场景,得出性能指标值。这些场景是真实环境有可能出现的。常见场景——压力测试,是否能长期提供服务
上面看,运行结果没有任何提示,也不知道运行到什么程度,相当不友好,那我们来美化一下吧!等等!这是个死循环,通过脚本运行自己,所以会永远运行下去。我的天,幸好发现得早。现在 更换authTest.sh,原因是这个是要运行eaidkAuth文件的,因此需要更改,否...
对于接口测试,首先测试人员要懂代码,你只需要知道接口的作用是什么就可以了,其次,自己去读开发的代码。然后,根据该接口功能及代码写测试用例:根据该接口参数,构造不同的用例,测试接口在参数合法及非法情况下能否达到预期效果,根据该接口中的逻辑,测...
如果接口 (API)已经定义好, 那就可以设计接口的测试用例了。 而且可以把用例加到 API 的spec 中,让开发人员了解这些测试用例,帮助开发出正确的代码。