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