2021-01-12 10:16发布
第一、把用户需求转化为功能需求：1）对测试范围进度量 2）对处理分支进行度量 3）对需求业务的场景进行度量 4）明确其功能对应的输入、处理和输出 5）把隐式需求转变为明确。
第二、明确测试活动的五个要素：测试需求是什么、决定怎么测试、明确测试时间、确定测试人员、确定测试环境：测试中需要的技能，工具以及相应的背景知识，测试过程中可能遇到的风险等等。测试需求需要做到尽可能的详细明确，以避免测试遗漏和误解。
首先肯定这个观点，软件测试确实需要从需求分析入手，但是，国内大多数的软件公司的测试都是从集成测试开始的，甚至直接从系统测试开始，这样做不符合一般的流程，但是也没有什么办法，毕竟差距和国外有很大。
说说从需求分析开始的好处：首先，“尽早的了解被测系统”，这句经典的软件测试原则就体现出来了，早入手，早了解，至于能否深刻了解，还是看需求评审做的是否充足；第二，如果在需求分析阶段发现系统存在严重的Bug（此阶段的bug最多），或者发现不可测的地方，可以及时的进行修改，避免了后期修改bug的巨大的成本浪费。以上两点是最主要的方面，把握住这两点就可以了。
第一、深刻理解需求，明确用户的真实需要，来评判软件是否解决了用户的问题，给用户带来了价值。测试应该是替用户进行把关的人。
第二、了解用户的行业特点、使用习惯、认知情况和业务流程，才能更好的以用户视角进行测试工作。
第三、测试对于需求也要进行评审，在初期评估一个需求是否有可行性和可测试性，是对需求的一个把关。
如果是增量开发，原始测试需求提取的分析方法为继承性需求分析；
原始测试需求分析常用的工程方法为质量模型分析、功能交互分析和用户场景分析；
测试特性分析的工程方法为测试特性建模和测试项分解分配。
如果要成功的做一个测试项目，首先必须了解测试规模、复杂程度与可能存在的风险，这些都需要通过详细的测试需求来了解。所谓知己知彼，百战不殆。测试需求不明确，只会造成获取的信息不正确，无法对所测软件有一个清晰全面的认识，测试计划就毫无根据可言，只凭感觉不做详细了解就下定论的项目是失败的。
测试需求分析越详细精准，表明对所测软件的了解越深，对所要进行的任务内容就越清晰，就更有把握保证测试的质量与进度。
如果把测试活动比作软件生命周期，测试需求分析就相当于软件的需求规格，测试策略相当于软件的架构设计，测试用例相当于软件的详细设计，测试执行相当于软件的编码过程。只是在测试过程中，我们把”软件”两个字全部替换成了”测试”。这样，我们就明白了整个测试活动的依据来源于测试需求，所以需求分析是整个测试活动必不可少的环节。
不做需求分析或需求分析不到位，可能会产生很严重的问题，比如：
（1） 浪费时间和资源实现了用户不需要的需求；
（2） 遗漏了需求文档中没提到，但很重要的需求，导致客户满意度降低。
（3） 需求分析不到位，错误的估计了测试的工作量，导致延误发布周期，可能会降低发布质量。
以上的几个问题，在实际开发中是比较常见的，主要的原因就是需求分析不到位，会导致影响客户的满意度。
（1）保证软件需求的可测试性
就是要保证所有的需要实现的需求都是可以用某种方法来明确的判断是否符合需求文档中的描述。如果对于某条需求或某个特性，无法通过一个明确的方法来进行验证，或者无法预知它的结果，那么就意味着这条需求的描述存在缺陷，应该请需求人员对需求文档进行修改或补充。
（2）确保需求文档中所描述的内容是真实可靠的
我们必须考虑，提出这些需求的涉众，是否真的可以正确的描述自己的需求？我们的需求人员是否真的可以正确的理解用户的需求？有没有一些被用户认为在业务处理上是理所当然、极其平常的事情，而没有作为需求提出来？有没有一些被用户认为他们过去使用的软件已经提供了相应的功能，所以认为我们也应当提供，而没有提出来的？作为测试人员，还是需要对软件产品所涉及的行业的业务有一个全面的、深入的了解。
软件测试的目的
1）软件测试是为了发现错误而执行程序的过程。
2）测试是为了证明程序有错，而不是证明程序无错。（发现错误不是唯一目的）
3）一个好的测试用例在于它发现至今未发现的错误。
4）一个成功的测试是发现了至今未发现的错误的测试。
一般参加需求分析的人员是多样的，包括产品人员，开发人员，测试人员，产品人员最主要是讲解需求，开发人员主要考虑这个需求使用现在的技术能不能实现，需要花费多长时间，而测试人员主要是了解清楚需求本身，考虑如果后续要测试的话，应该从什么样的角度出发，考虑哪些方面的问题等，通过整体的需求分析过程，能够让我们整个团队的所有人员都更清楚需求本身要实现的功能，后续的沟通成本也会更低，并且通过需求分析还能发现一些不合理的需求进行及时的更新，避免后续的返工
、 黑盒测试：是一种常用的软件测试方法，它将被测软件看作一个打不开的黑盒，主要根据功能需求设计测试用例，进行测试。几种常用的黑盒测试方法和黑盒测试工具有，等价类划分法、边界值分析法、因果图法、决策表法。在实际运用中要选择合适的方法。二、 因果...
果图法是一种适合于描述对于多种输入条件组合的测试方法，根据输入条件的组合、约束关系和输出条件的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件涉及的各种组合情况。因果图法一般和判定表结合使用，通过映射同...
判定表（Decision Table）是分析和表达多逻辑条件下执行不同操作的情况下的工具.在程序设计发展的初期,判定表就已被当作编写程序的辅助工具了.由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确....
判定表通常有以下四个部分组成：1)条件桩（Condition Stub）：列出了问题的所有条件。通常认为列出的条件的次序无关紧要。2)动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。3)条件项（Condition Entry）：列出针对它左列...
长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是...
1) 边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。2) 边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。
边界值分析方法是对等价类划分方法的补充. 长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例，可以查出更多的错误.使用边界值分析方法设计测试用例...
在编程中，布尔量指一个真或假状态。通常它们分别用0,1或1,-1来表示，这和编程语言有关。具体来说当布尔量为真的时候表示一个表达式或判断成立，否则这个式子或判断不成立。你把它理解为成立或不成立就行了。...
1）输入条件规定取值范围，则卡定义一个有效等价类和两个无效等价类。例如学生成绩范围是0~100，则一个有效类：0
1，先确定等价类别2，找出有效等价类和无效等价类3，边界值找好，尽可能多的找的会有重复的数据4，有效等价类尽可能条件符合的归一起不要重复5，无效等价类单独写开6，写好测试用例7，执行测试用例...
应用场景：只要有数据输入的地方就可以采用等价类划分法。按照需求，把无穷多的数据进行分类，从中挑选出代表性数据进行测试。具体操作：（1）明确测试对象（测试什么）（2）划分等价类（按照需求分有效、无效）（3）细化等价类（有效、无效进行细化）（4）建...
采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。
Priority()和Severity(严重程度)是的两个重要属性。很多新人经常混淆这两个概念。通常，人员在提交Bug时，只定义Bug的Severity, 即该Bug的严重程度，而将Priority交给Project Leader 或Team Leader来定义，由他们来决定该Bug被修复的优先等级。某种意义上来说...
1致命：致命是指系统主要功能丧失，用户数据受到破坏，造成系统崩溃、悬挂、死机或者危及人身安全等的问题。例如程序所引起的死机,非法退出、死循环、数据库发生死锁、数据流环节上严重的数值计算错误、产品设计存在严重的安全问题、漏洞被利用后可能导致系统...
1、New:（新的）当某个bug被发现的时候（第一次），测试人员需要与项目负责人沟通以确认发现的的确是一个bug，如果被确认是一个bug，就将其记录下来，并将bug的状态设为New。2、Assigned（已指派的）当一个bug被指认为New之后，将其将给开发人员，开发人员将...
软件缺陷是计算机软件或程序中存在的某种破坏正常运行能力的问题、错误,或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。IEEE729-1983对缺陷有一个标准的定义:从产品内部看,缺陷是软件产品开发或维护过程中存在的错误、毛病等...
最多设置5个标签!
{var%20f='http://v.t.sina.com.cn/share/share.php?appkey=1515056452',u=z||d.location,p=['&url=',e(u),'&title=',e(t||d.title),'&source=',e(r),'&sourceUrl=',e(l),'&content=',c||'gb2312','&pic=',e(p||'')].join('');function%20a(){if(!window.open([f,p].join(''),'mb',['toolbar=0,status=0,resizable=1,width=440,height=430,left=',(s.width-440)/2,',top=',(s.height-430)/2].join('')))u.href=[f,p].join('');};if(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else%20a();})(screen,document,encodeURIComponent,'','','/static/images/logo.png', '推荐 风亦有情 的问题《【软件测试基础】测试需求分析目的》','http://www.shouhuola.com/q-32716.html','页面编码gb2312|utf-8默认gb2312'));){kind=link}
需求分析的目的：
第一、把用户需求转化为功能需求：1）对测试范围进度量 2）对处理分支进行度量 3）对需求业务的场景进行度量 4）明确其功能对应的输入、处理和输出 5）把隐式需求转变为明确。
第二、明确测试活动的五个要素：测试需求是什么、决定怎么测试、明确测试时间、确定测试人员、确定测试环境：测试中需要的技能，工具以及相应的背景知识，测试过程中可能遇到的风险等等。测试需求需要做到尽可能的详细明确，以避免测试遗漏和误解。
首先肯定这个观点，软件测试确实需要从需求分析入手，但是，国内大多数的软件公司的测试都是从集成测试开始的，甚至直接从系统测试开始，这样做不符合一般的流程，但是也没有什么办法，毕竟差距和国外有很大。
说说从需求分析开始的好处：首先，“尽早的了解被测系统”，这句经典的软件测试原则就体现出来了，早入手，早了解，至于能否深刻了解，还是看需求评审做的是否充足；第二，如果在需求分析阶段发现系统存在严重的Bug（此阶段的bug最多），或者发现不可测的地方，可以及时的进行修改，避免了后期修改bug的巨大的成本浪费。以上两点是最主要的方面，把握住这两点就可以了。
第一、深刻理解需求，明确用户的真实需要，来评判软件是否解决了用户的问题，给用户带来了价值。测试应该是替用户进行把关的人。
第二、了解用户的行业特点、使用习惯、认知情况和业务流程，才能更好的以用户视角进行测试工作。
第三、测试对于需求也要进行评审，在初期评估一个需求是否有可行性和可测试性，是对需求的一个把关。
如果是增量开发，原始测试需求提取的分析方法为继承性需求分析；
原始测试需求分析常用的工程方法为质量模型分析、功能交互分析和用户场景分析；
测试特性分析的工程方法为测试特性建模和测试项分解分配。
1、需求分析的必要性
如果要成功的做一个测试项目，首先必须了解测试规模、复杂程度与可能存在的风险，这些都需要通过详细的测试需求来了解。所谓知己知彼，百战不殆。测试需求不明确，只会造成获取的信息不正确，无法对所测软件有一个清晰全面的认识，测试计划就毫无根据可言，只凭感觉不做详细了解就下定论的项目是失败的。
测试需求分析越详细精准，表明对所测软件的了解越深，对所要进行的任务内容就越清晰，就更有把握保证测试的质量与进度。
如果把测试活动比作软件生命周期，测试需求分析就相当于软件的需求规格，测试策略相当于软件的架构设计，测试用例相当于软件的详细设计，测试执行相当于软件的编码过程。只是在测试过程中，我们把”软件”两个字全部替换成了”测试”。这样，我们就明白了整个测试活动的依据来源于测试需求，所以需求分析是整个测试活动必不可少的环节。
2、不做需求分析的后果
不做需求分析或需求分析不到位，可能会产生很严重的问题，比如：
（1） 浪费时间和资源实现了用户不需要的需求；
（2） 遗漏了需求文档中没提到，但很重要的需求，导致客户满意度降低。
（3） 需求分析不到位，错误的估计了测试的工作量，导致延误发布周期，可能会降低发布质量。
以上的几个问题，在实际开发中是比较常见的，主要的原因就是需求分析不到位，会导致影响客户的满意度。
（1）保证软件需求的可测试性
就是要保证所有的需要实现的需求都是可以用某种方法来明确的判断是否符合需求文档中的描述。如果对于某条需求或某个特性，无法通过一个明确的方法来进行验证，或者无法预知它的结果，那么就意味着这条需求的描述存在缺陷，应该请需求人员对需求文档进行修改或补充。
（2）确保需求文档中所描述的内容是真实可靠的
我们必须考虑，提出这些需求的涉众，是否真的可以正确的描述自己的需求？我们的需求人员是否真的可以正确的理解用户的需求？有没有一些被用户认为在业务处理上是理所当然、极其平常的事情，而没有作为需求提出来？有没有一些被用户认为他们过去使用的软件已经提供了相应的功能，所以认为我们也应当提供，而没有提出来的？作为测试人员，还是需要对软件产品所涉及的行业的业务有一个全面的、深入的了解。
软件测试的目的
1）软件测试是为了发现错误而执行程序的过程。
2）测试是为了证明程序有错，而不是证明程序无错。（发现错误不是唯一目的）
3）一个好的测试用例在于它发现至今未发现的错误。
4）一个成功的测试是发现了至今未发现的错误的测试。
一般参加需求分析的人员是多样的，包括产品人员，开发人员，测试人员，产品人员最主要是讲解需求，开发人员主要考虑这个需求使用现在的技术能不能实现，需要花费多长时间，而测试人员主要是了解清楚需求本身，考虑如果后续要测试的话，应该从什么样的角度出发，考虑哪些方面的问题等，通过整体的需求分析过程，能够让我们整个团队的所有人员都更清楚需求本身要实现的功能，后续的沟通成本也会更低，并且通过需求分析还能发现一些不合理的需求进行及时的更新，避免后续的返工
相关问题推荐
、 黑盒测试：是一种常用的软件测试方法，它将被测软件看作一个打不开的黑盒，主要根据功能需求设计测试用例，进行测试。几种常用的黑盒测试方法和黑盒测试工具有，等价类划分法、边界值分析法、因果图法、决策表法。在实际运用中要选择合适的方法。二、 因果...
果图法是一种适合于描述对于多种输入条件组合的测试方法，根据输入条件的组合、约束关系和输出条件的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件涉及的各种组合情况。因果图法一般和判定表结合使用，通过映射同...
判定表（Decision Table）是分析和表达多逻辑条件下执行不同操作的情况下的工具.在程序设计发展的初期,判定表就已被当作编写程序的辅助工具了.由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确....
判定表通常有以下四个部分组成：1)条件桩（Condition Stub）：列出了问题的所有条件。通常认为列出的条件的次序无关紧要。2)动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。3)条件项（Condition Entry）：列出针对它左列...
长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是...
1) 边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。2) 边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。
边界值分析方法是对等价类划分方法的补充. 长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例，可以查出更多的错误.使用边界值分析方法设计测试用例...
在编程中，布尔量指一个真或假状态。通常它们分别用0,1或1,-1来表示，这和编程语言有关。具体来说当布尔量为真的时候表示一个表达式或判断成立，否则这个式子或判断不成立。你把它理解为成立或不成立就行了。...
1）输入条件规定取值范围，则卡定义一个有效等价类和两个无效等价类。例如学生成绩范围是0~100，则一个有效类：0
1，先确定等价类别2，找出有效等价类和无效等价类3，边界值找好，尽可能多的找的会有重复的数据4，有效等价类尽可能条件符合的归一起不要重复5，无效等价类单独写开6，写好测试用例7，执行测试用例...
应用场景：只要有数据输入的地方就可以采用等价类划分法。按照需求，把无穷多的数据进行分类，从中挑选出代表性数据进行测试。具体操作：（1）明确测试对象（测试什么）（2）划分等价类（按照需求分有效、无效）（3）细化等价类（有效、无效进行细化）（4）建...
采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。
Priority()和Severity(严重程度)是的两个重要属性。很多新人经常混淆这两个概念。通常，人员在提交Bug时，只定义Bug的Severity, 即该Bug的严重程度，而将Priority交给Project Leader 或Team Leader来定义，由他们来决定该Bug被修复的优先等级。某种意义上来说...
1致命：致命是指系统主要功能丧失，用户数据受到破坏，造成系统崩溃、悬挂、死机或者危及人身安全等的问题。例如程序所引起的死机,非法退出、死循环、数据库发生死锁、数据流环节上严重的数值计算错误、产品设计存在严重的安全问题、漏洞被利用后可能导致系统...
1、New:（新的）当某个bug被发现的时候（第一次），测试人员需要与项目负责人沟通以确认发现的的确是一个bug，如果被确认是一个bug，就将其记录下来，并将bug的状态设为New。2、Assigned（已指派的）当一个bug被指认为New之后，将其将给开发人员，开发人员将...
软件缺陷是计算机软件或程序中存在的某种破坏正常运行能力的问题、错误,或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。IEEE729-1983对缺陷有一个标准的定义:从产品内部看,缺陷是软件产品开发或维护过程中存在的错误、毛病等...