如何做好测试需求分析个人总结?
作者:网络转载 发布时间:[ 2016/3/30 14:12:40 ] 推荐标签:软件测试管理 需求管理
一、测试需求分析的过程:
1.根据需求规格提取独立的功能点,确定测试范围;
2.对独立功能进行分析,确定各独立功能的测试点;
3.对业务场景即功能组合进行分析,提供业务场景的测试点;
4.对非功能特性进行分析,了解需要测试的非功能特性;
5.针对系统级接口进行分析,了解被测试对象、测试规格。分析可测性,确定测试方法、工具。
二、测试需求分析需要考虑的一些问题和细节:
问题:
1.已文档化的需求是否被正确实现;
2.是否存在遗漏需求;
3.是否存在画蛇添足的问题(实现了不存在于需求规格的需求)。
细节:
1.需求项与测试项关联、与测试用例关联(避免遗漏);
2.区分出测试项的优先级(80/20法则);(可以使用两次80/20法则,将优先级快速分为三个层次:5%、15%、80%)
3.针对可能存在的需求遗漏和疑似额外的实现,主动联系需求提出方,进行沟通并确认;
4.若需求项(测试项)可测试性差,及时反馈(涉及接口的,需要看到API,或接口文档)。
三、工作方法改进:
1. 量体为用:在不同的工作环境中开展测试活动,需按工作环境中的实际情况灵活的调整工作方式。
比如在软件开发不是公司主营业务的团队做测试,需要把握好以下工作(身为测试员的体会):
A. 沟通;
B. 前期早介入(想办法熟悉产品的需求);
C. 做好测试需求分析、用例(包括用例的评审);
D. 提出改进工作流程及方法,提出提升被测物可测试性的建议(发现问题提出,否则领导会认为你不主动或什么都不懂);
E. 测试总结:测试覆盖率、测试充分性(是否可以从这些方面再有所提高)、改进意见、经验分享;
F. 测试:将测试的触手伸向代码(越主动越有利)。
说明:有时候会发现,本来是变量没有初始化被调用,或是对象没有被正确的实例化被使用,而产生的错误。但是开发人员在对应类或函数的日志输出部分
写的是“Network Error.” 或是“New Error + $Date”. 这样给通过日志判断、定位错误的测试人员造成一些困扰。
2. 换位思考:不管是做领导工作,还是普通的测试员或研发人员,能够做到换位思考的人,未来可期。
3.不二过:尽量不在工作中犯同样的错误。即要善于总结问题并及时改正。同时,分享自己犯的错误和解决方法也很重要。
注:
很多时候要做需求分析是没有文档的,不管有没有文档,文档写的如何,有效的沟通关键。看文档其实也是和写文档的人做思想的交流嘛。
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11