软件测试与项目分析-OA系统测试项目实施.pptx

第四章 OA系统测试项目实施;4.1.1原始测试需求分析; 需求规格：在原始需求的基础上进一步细化，软件质量概念中曾描述“满足要求”，因此体现软件质量优劣的核心标准即是特性符合程度，反向理解，即是需求表述是否定量或定性，只有明确了要求的规格，才能根据质量标准进行验证是否满足用户要求及满足的程度，因此需求规格是测试工程师真正需要关心的验证基础。需求规格说明书是经过原始需求细化、与用户确认，从软件质量各大特性及其子特性考虑的量化的用户期望表述文档。一般而言，需求规格说明书包含功能性需求、性能需求、外部接口需求（用户界面接口及外部应用程序接口），根据用户对象不同，可能还包括安全性需求、移植性需求等。需求规格说明书需写明实现哪些需求，哪些需求不能实现，参考哪些现行标准/协议/规范等。如原始需求“用户需要一杯水”，需求规格则是“用户需要一杯50ML、60°左右的纯净水”，定义了期望目标的容量、温度及属性，这样需求易于实现及易于验证。 ; 开发需求：开发需求在需求规格的基础上进一步进行了细化，一般带有明确的实现方式。开发需求由开发人员根据需求规格进行细化，从体系架构、设计思想及人机交互环节考虑。如“用户需要一杯50ML、60°左右的纯净水”细化为开发需求则为“用户需要一杯用双层玻璃杯盛着50ML、60°左右的纯净水，并且使用木质托盘送上”。 测试需求：从软件测试角度考虑，关注可度量、可实现、可验证等几个方面，如上述的需求，50ML、60°可度量，双层玻璃杯、纯净水、木质托盘可实现，整个定量及定性需求可验证，在开发需求保证继承于需求规格时，测试需求与开发需求差异不大。 对于测试需求而言，来源主要有需求规格说明书、开发需求、协议/规范/标准、用户需求、继承性需求、测试经验库、同行竞争分析等。通过确定不同的需求来源，确定原始测试需求提取的范围。在实际分析提取过程中，存在参考多个来源信息的现象，可能存在重复和冗余，需要进行整理，整理后的原始测试需求（原始测试项），作为后续原始测试需求分析活动的输入。 ; 若测试需求来源???需求规格说明书，测试工程师可以直接根据需求中功能、性能、外部接口特性，提取测试项及测试子项。这种情况下，提取出来的测试项及子项基本能保证测试需求的正确性及有效性。传统的软件项目，经过需求调研阶段，基本都会生成规范的项目需求规格说明书，这种情况下获取原始测试需求、测试项及测试子项相对容易。 对于输入是开发需求的情况，测试工程师可以考虑直接将一条开发需求作为一条原始测试需求来提取，然后参考被测对象概要设计及详细设计规格，检查提取出的原始测试需求是否存在遗漏。在实际操作中，如果觉得开发需求的粒度不合适，需求不够明确具体，可以考虑拆分成多条或者合并为一条原始测试需求。为明确测试和开发需求的对应关系，要建立原始测试需求和开发需求的跟踪关系（RTM，需求跟踪矩阵），明确提取的原始测试需求对应的开发需求标识，如果有合并的情况，则对应多个开发需求标识。随着市场竞争激烈，产品同质化加剧，奢望一份规范的需求规格说明书，将变得很难，因此很多公司可能仅有开发需求，在这种情况下，测试工程师需根据开发需求及自身经验获取测试需求，并且测试需求初步提取后一定需经过规范的同行评审环节进行评审验证确认。; 若来源范围是某行业的协议标准规范，通常是将开发需求和相关的协议标准规范分配给同一个人，以其中一个为主另一个为辅来进行原始测试需求的提取。以开发需求为主提取出原始测试需求后，再针对协议、标准、规范来分析补充。可补充的原始需求通常包括如下情况：开发文档未详细说明，而是参见某某协议标准规范；开发文档未充分考虑到相关协议标准规范的要求，存在遗漏或者错误；除开发文档要求外，还存在其它需要遵循的协议规范和标准等情况。在移动通信、金融证券产品领域内，根据行业协议、标准或规范获取测试需求是比较常见的，因为这些产品的开发基本都是遵循某些行业标准的，在需求规格说明书中经常看到“具体需求，请参考《XXXX通讯协议》”等字样。 单独从用户需求和开发文档中提取原始测试需求，也可能会存在大量的重复，所以通常也是将开发文档和相关的用户需求文档分给同一个人，以其中一个为主另一个为辅来进行原始测试需求的提取。因为开发需求往往是对用户需求的细化分解，所以一般情况是以开发需求为主提取出原始测试需求后，再通过对用户需求的分析验证提取的原始测试需求是否全面正确。;同时，为了让测试更直接面向用户，可以以用户需求为主线，将从开发需求提取出来的原始需求进行整理，因为实际上将这些开发需求还原后，真正的需求来源就是用户需求。质量较高的用户需求通常是从用户实际使用的角度来描述和划分的（可以称之为用户使用场景），此类做法比较符合测试的习惯或要求，可将它们直接作为