作为软件测试人员,我们需要在需求阶段就开始介入测试,因为通常在测试进行之前,需要对测试需求进行分析和汇总以及评审,给测试方案的设计提供参考。那我们在接收到测试任务的时候应该做些什么呢?以下汇总一下本人建议,仅供参考,需根据实际项目情况来定夺。
了解产品
了解产品的部署环境:部署的软硬件环境,以及与产品线上环境的差别。一般应尽量一致。
了解产品功能
了解功能目的
通过阅读需求文档或设计原型,或者口头向产品负责人了解产品有哪些模块。形成产品功能列表
了解各功能模块的开发进度,完成/未完成。未完成原因与完成时间
了解容易出错的模块
了解已知问题
了解业务流程:了解产品的业务流程有哪些,构造业务流程图。
了解模块的作用,设计出来的目的,为了满足用户的什么要求
了解各功能及模块的用户场景
确认核心功能、主要功能;常用功能、不常用功能,确认重要模块的应用场景(可用于确认测试重点)
了解产品的其他要求
对性能的要求
对安全性的要求
对环境的要求:操作系统、浏览器(兼容性要求)
产品分解
页面链接(各页面的访问,是否有404、500等报错)
功能流(主流程、备选流,可理解为数据流向)
数据统计的准确性
不同平台同一数据的一致性
同一平台同一类型数据的统一性(如时间格式、提示信息窗口--警告类、成功类,等)
用户界面(布局排版是否正常合理规范)
用例编写,测试用例编写的过程也是加深对产品的理解的过程
测试,测试过程总不可能一帆风顺,会遇到各种各样的情况。比如某些操作导致的系统失效,可能是在写测试用例的时候未考虑到的。因此测试过程的是补充用例的最佳指导,也是更加深刻理解产品的过程。另外需要说明的一点是,测试过程,特别是对于迭代快速的项目,可能未进行测试用例的编写,测试只是根据测试点开展。这就很难避免会遇到一些我们不是非常确定操作步骤的问题,包括偶发性的问题,以及路径比较复杂的问题,常常在发现问题后,甚至记不起发现这个问题前自己的操作。遭遇这种情况是非常令测试人员头疼的。我的建议是,可以在测试的过程中,使用录屏工具,对我们的测试所有操作进行录制。当遇到无法确定操作步骤的问题时,查录制记录。
(待续……)