测试需求点的改进。网络上有一个帖子说微软的用户登录功能的测试用例有5000个测试用例,很多做测试的朋友第一个反应是变态。大家的这个反应有很多妒忌、羡慕的意思,其实更多的是不知道为什么微软会写那么多的测试用例,而如何写出来(这是测试人员第一个基本功)就更不了解了,于是才有了这个反应。其实编写测试需求,编写测试用例几万,几十万,几百万并不是一个很难的事情,关键看你是否掌握编写测试需求以及测试用例的方法。
测试需求的来源是系统需求报告(或者叫软件规格说明书等名字),测试需求报告主要内容是本次测试需要测试那些点,一般的系统需求说明书是按照系统,子系统,模块、功能、子功能、数据的形式来编写的,(这里是指的比较规范的需求说明书),比如人力资源管理,可能包括前端人力资源管理子系统(给人力资源部门的工作人员使用),后台管理子系统(系统管理员进行用户管理,权限管理等操作的系统)。
用前端人力资源管理子系统而言一般有人员基本信息管理模块,薪金管理模块等模块,而人员基本信息管理模块又可以分为添加新人员基本信息功能,修改人员基本信息功能,删除人员基本信息功能,查询人员基本信息功能,汇总人员基本信息功能等功能,而在添加新人员基本信息功能里会涉及到人员基本信息的具体数据内容,比如人员姓名、性别、出生时间、到本单位的时间等信息。
以上内容都应该在软件需求报告中获得,很多单位由于开发流程的差异测试人员即使不能在需求文档中获得,也应该可以从概要设计文档或者详细设计文档中获得,最糟糕的,也可以从开发人员的开发的系统上获得(顺便说一句,测试人员获得这些信息的顺序,可以代表开发部门开发的规范性和开发能力的高低,越早获得说明开发越规范)。作为一