需求测试

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/qq_20475689/article/details/79228908
1.产品需要完成的功能和产品需要具有的品质
2.功能性需求:产品能够完成哪些功能
非功能性需求:产品的响应速度,可观性,可用性,安全性,
3.高质量的需求叙述有6大特性:
正确:
需求精确描述产品功能
可实现:
每个需求可以实现
必要性:
符合用户需求
优先权:
为每个需求,特征,用例分配实现的优先权
明确:
明确需求说明
可证实:
能够做出测试计划或其他验证方式
4.理想的项目流程:需求测试——用例编写——测试执行——回归稳定——维护
但是实际上用例编写时还要和产品确认需求
5.需求不断变化对测试的影响:
测试不断的理解需求,时刻维护测试用例
测试时间无法保证,测试进度无法评估,测试质量无法保证
面对不断变化的需求,我们应该站在用户的角度思考需求的问题,主动确认了解需求
领导者:面对不断变化的需求我们需要对需求变化带来的工作量和风险进行评估,需要和产品研发明确产品质量要求,测试范围,需要协调的资源(浏览器,手机型号等)和时间
6.需求测试策略:优先考虑真实用户需求场景,确保整体功能需求完整。
针对用户上传功能:
上传什么东西,格式,大小,上传界面
支持哪些用户上传?是否有权限控制?
上传是否需要管理员审核?
上传的东西在哪里可以查看?
上传中遇到异常情况如何处理?...
7.需求测试问题分类:
需求完整性:将实现功能描述清楚
需求可测性:可以通过用例或者其他方法验证
需求一致性:需求上下文,需求原型之间一致
界面元素:界面布局等易用性问题
异常分析和容错处理:深入考虑可能导致的异常情况
需求建议:分问题类别,主要个人观点
展开阅读全文

个人测试经历的一点总结——测试需求的孤立分开

01-14

做了一段时间的测试,也发现、复现、解决过各种问题。现在想起来工作中最大的问题是测试人员与需求人员孤立分开导致的矛盾。rn 工作有苦也有乐。让我记忆深刻的一件事是第一次去面试测试岗位的时候,面试官问:当测试人员发现一个问题,而开发人员不认为是问题的时候,该怎么办?当时胡乱答了一通,也不记得说了些什么了。工作中才发现经常碰到类似的现象,解决之道其实并不需要过多的争论,只需要做到一件事:你能否将问题复现?商业软件大多比较复杂,再加上大家的经验、水平等原因,有的现象很难复现。复现不了,解决当然就难,而且可能无从下手。开发手上有一大堆事,所以也不能怪开发对这样的现象不重视(他可能也心有余而力不足)。能复现了,你只要把bug提上去,解决不解决也就不必太计较了(他自动会解决,而且一般都很快)。有的现象并不是很轻松就能复现,但复现后,不仅会极大的提高解决问题的速度,而且当客户遇到类似问题的时候,你可以很轻松的告诉他用的软件版本旧了。rn 工作中就发生这样一件事:作为测试的我,发现一个问题(需求中的一个功能点看起来完全没有实现)。这看起来是一个大问题,于是我想和需求确认一下这个问题:是需求改了(不需要实现这个功能了)?还是必须马上通知开发人员修正这个问题。但我去和需求交流的时候,需求看上去很忙,回复我说这个功能已经实现了,我无话可说。这事也就算过去了。可不巧的是那天需求突然又发现了这个问题,于是和开发组长说:这个功能完全没有实现,必须马上改。要知道,这时候项目都快完工了啊。大家都很郁闷,于是开会,把我叫去了,开发组长第一句话就是:你测试的,这么重大的问题怎么没发现?——哎,什么黑锅都得我背。虽然需求稍微圆了场,说我经常和他交流之类的,但项目质量黑锅总是由测试背,我已经快习惯了。rn 其实现在回想起来,这个问题可以早发现,早解决。可那天我去和需求交流的时候,偏偏他很忙,好像正在忙着别的什么事情。我呢,看到需求都这么肯定了,也就没当回事,多一事不如少一事。没想到这个事情还是必须解决的。rn 最后,以网上流传的一个故事作为本总结的结尾。部队规定:机械师发现飞机发动机3毫米裂缝,记三等功一次。一机械师检查发动机,发现一个1.5毫米的裂缝,并没有上报,而是心存等它长大的心理。于是,每天检查的时候,他都只允许自己检查这个部位,不让别人查。一天不知道是太热还是什么原因,机械师懒得爬上去检查这个部位了,而是让一机械员上来检查。机械员一查,3毫米裂缝,马上上报。大队长、中队长等都来了,更先进的检查设备也用上了。最后定论:2.76毫米裂缝,给机械员记三等功一次。而机械师就有点倒霉了,当年专业回家。 论坛

没有更多推荐了,返回首页