1, 软件测试需求:以一个项目的观点看待软件测试工作,这个项目的范围就是软件测试需求,它定义了软件测试工作的范围,是进行其他测试活动的基础。
软件测试需求的内容: –功能测试需求
–性能测试需求
–可靠性测试需求
–国际化与本地化测试需求
–安全性测试需求
2,软件需求管理
定义1:软件需求就是一个为软件系统的需求进行启发、组织、建档的系统方法,一个建立和维护客户和项目团队之间关于变更系统需求所达成的一致性的过程。
定义2:一种获取,组织并记录系统需求的系统化方案,以及一个使客户与项目团队对不断变更的系统需求达成并保持一的过程。
2) 软件需求管理要求:
a) 软件需求规格说明已文档化,并经评审后存档。
b) 文档化的软件需求规格说明受管理和控制。
c) 供软件工程和管理使用的分配基线已建立,使软件产品满足分配需求的接收标准;分配需求是制定软件开发计划的根据,是整个软件生命周期中估算、计划、执行和跟踪软件项目活动的基础。
d) 软件开发计划、软件工作产品和软件过程活动与软件需求保持一致。
业界常见的测试过程中存在的问题:
软件测试本身的需求文档不全,有些需求待定;
产品质量维度事先没有全面明确,要包括的测试类型不全;
测试计划和编写测试案例没有规范;
没有系统的测试需求分析方法、流程或指导;
测试中经常会出现需求和缺陷遗漏、测试设计遗漏的问题。
(1)失败经验教训说明必须要有软件测试需求管理
(2)业界专家建议必须实施软件测试需求管理
(3)缺乏成熟的理论和统一标准而需要需求管理
1) 软件测试需求分析的目标:软件需求分析的目的就是要对软件测试要解决的问题进行详细的分析,弄清楚参与软件测试活动的干系人对软件测试活动和交付物要求,包括需要输入什么数据,要得到什么结果,最后应输出什么。
2) 测试需求分析主要有两个任务:
(1)通过对测试活动需要解决问题及其环境的理解、分析和综合,建立分析模型。
(2)在完全弄清所有测试活动干系人对测试的确切要求的基础上,用 “软件测试需求规格说明书”把测试需求以正式书面形式确定下来。(Software Test Requirement Specification,SRS,简称测试需求书)
1)软件测试需求分析的意义:
如果把测试活动比作软件生命周期,测试需求就相当于软件的需求规格,测试用例相当于软件的详细设计,测试用例的开发过程相当于软件的编码过程。但是软件测试不是简单把“软件”两个字全部替换成了“测试”这样简单,就测试需求分析的方法而言,即可以参考软件需求分析方法,又有其独特性。
2) 软件测试需求分析的方法:
(1) 通过软件的需求推导软件测试需求(最通用的方法)
1) 软件测试需求分析的过程
(1) 软件测试需求分析干系人分析
(2) 需求收集和整理
(3) 测试需求的优先级排序
(4) 评审测试需求
评审内容:评审的内容包括完整性检查和准确性检查。
评审的方法:相互评审、交叉评审;轮查;走查;小组评审;评审人员
正式评审小组中,一般存在多种角色,包括协调人、作者、评审员等。
评审员需要精心挑选,保证不同类型的人员都要参与进行来,通常包括开发经理、项目经理、测试经理、系统分析人员、相关开发人员和测试人员等。
从关注几个方面的问题来分析软件测试需求管理的内容:
(1)定义测试需求
(2)测试需求确认
(3)建立测试需求状态
(4)测试需求评审
(5)测试需求责任制
(6)测试需求跟踪
a) 客户的需求变更
b) 市场需求变更
c) 技术或非技术的其他原因
a) 测试需求变更管理的必要性
b) 测试需求变更管理的意义
c) 软件测试需求变更的主要任务:分析变更的必要性和合理性,确定是否实施变更;记录变更信息,提交变更申请;做出更改;修改相应的软件测试工作,如更新测试用例等;评审后,正式发布新版本的软件测试需求说明书。
d) 建立测试需求管理模型
在测试工作进展的过程中,可能存在若干种状态:
(1)只知道大致需求,具体细节还有待细化;
(2)已经初步确定,等待评审;
(3) 已经确定的,并经过团队评审,在可预期未来不会发生变更;
(4) 已经评审完毕正在进行设计、实现测试用例的测试需求;
(5) 完成设计、实现测试用例的测试需求。
Open:对于原始需求或接收到的正式需求,但未正式进行需求分析之前的需求状态统一定义为:“Open”状态
Analyzed:对需求状态为“Open”的需求,若已完成需求分析过程,但还未正式通过需求评审前,其状态统一定义为“Analyzed”状态
Reviewed:对需求状态为“Analyzed”的需求,若已正式通过需求评审,但还未完成测试,或测试结果为不合格之前,其状态统一定义为“Reviewed”状态
Resolved:对需求状态为“Analyzed”或“Reviewed”的需求,若已完成需求设计和编码,且已通过单元测试,其状态统一定义为“Resolved”状态
Passed:对需求状态为“Resolved”的需求,如果已通过正式测试,其状态统一定义为“Passed”状态
Unresolved:对需求状态为“Resolved”的需求,如果未通过正式测试,其状态统一定义为“Unresolved”状态。
Closed:对需求状态为“Resolved”的需求,若需求已正式上线商用,且得到客户和项目团队的共同认可后,其状态统一定义为“Closed”状态。
Cancel:当原定义的某些需求被取消时(包括上线前取消和上线后取消),其需求状态统一定义为“Cancel”状态。
Failed:对需求状态为“Closed”的需求,若需求在上线商用后发现问题或存在缺陷,需要对其进行修正时,其需求状态统一定义为“Failed”状态
定义:软件测试需求文档的版本管理是软件测试需求管理的基础,籍此可以使得同一软件测试需求文档可以被测试团队中不同的人员编辑,并且记录下每次编辑的增量,必要的情况下还可以回滚到某个版本。
HP Application Lifecycle Management文档版本管理的功能:
• 权限管理
• 每次文档升级后的版本管理和恢复
• 团队协作时同时操作
• 文档版本比较
指跟踪一个软件测试需求使用期限的全过程。
1)软件测试需求跟踪有两种方式,正向跟踪与逆向跟踪:
正向跟踪:以软件测试需求为切入点,检查软件测试需求说明书中的每个需求是否都能在测试用例设计和实现中有相应的测试用例对应。
逆向跟踪:测试用例设计和实现等测试交付物是否都能在软件测试需求说明书中找到测试需求与之对应。
• 为测试团队提供了软件测试需求跟踪能力。
• 通过跟踪软件测试需求的后续测试用例信息可以帮助确保所有软件测试需求被实现,没有遗漏。
• 在对软件测试需求进行增、删、改等变更时可以确保与之对应的测试用例也进行必要的更新,而不被不忽略。
• 及时可靠的对软件测试需求进行跟踪,使得维护时能正确、完整地实施变更,从而提高生产效率
用于现代应用测试的软件解决方案有惠普应用生命周期管理(ALM)是一款应用测试软件,可为您提供统一的存储库、一致的用户体验,可定制的仪表板,支持从单一存储库管理整个应用生命周期,包括从需求开始到准备交付为止的整个过程。
惠普应用程序生命周期管理流程图:
(2)指定需求
(3)计划测试
(4)执行测试
(5)追踪缺陷