对于测试人员来说,漏测是一件非常难受的事情。
什么是漏测?
顾名思义:指的是软件产品在测试结束后,出现了在测试过程中未发现的问题。一旦出现漏测,首先给用户带来的体验感是非常差,特别是一些严重的bug,比如闪退,未响应等,那么用户极有可能会找同类型进行产品替代,毕竟现在目前市场上同类型的产品过于太多;从公司本身来看,缺陷发现的越晚,修复的成本就会越高,投入的人力,物力,时间就会拉长;从测试人员本身来看,间接性也证明了测试人员能力不足,个人的工作就会受到质疑。不漏测在工作中其实很难做到,即使是大型比较完善的团队,依旧存在这样的问题,但是尽可能少漏测,是作为测试人员最基本的职责。
那么如何做到避免漏测呢?
1、首先从需求开始
测试需求的提取,是为了告诉测试人员”测什么”,测试需求是测试人员在需求阶段的初始阶段,通过多方渠道收集(比如需求规格说明书,概要设计,详细设计,项目合同书等)的需求文件,进行可测性分析而形成的需求。此内容也是后续测试活动开展的依据之一。
测试需求往往来源于业务需求和系统需求。
项目实践中,通常业务需求是指从业务层面分析的内容,包括业务场景、业务流程、要实现的业务目标及一些约束条件(例如,角色约束、业务规则约束等)。
项目实践中,通常系统需求包含了系统的功能性需求和非功能性需求。
功能性需求——定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足了业务需求。非功能性需求——包括产品必须遵从的标准、规范和合约;外部界面的具体细节;性能要求;设计或实现的约束条件及质量属性。
同时,找好可以测试需求的对象:产品、用户、开发人员、运维人员做好沟通。需求收集完毕后,需求评审是软件开发中重要的环节之一。通过需求评审可以将不一致、遗漏和错误的需求审查出来。
确认需求和软件目标的一致性,识别出功能、非功能需求,为后续测试工作提供依据;使项目相关角色,对需求理解达成一致,降低修改和沟通的成本。
2、其次是提高软件测试设计质量
测试用例是为了体现”怎么测”,对于测试需求来说,要做到100%全覆盖,多来设计有效的测试场景,保证测试的有效性。测试用例设计完毕后,也要及时做好评审,测试用例的评审能够使用例的结构更清晰,覆盖的用户场景更全面。如果团队条件允许,可以部门内部之间进行交叉测试,毕竟每个人的测试思路是有不一样的出发点,能够更多覆盖测试场景。
3、一定要做好回归测试
不仅要确保之前提交的缺陷已被全部修复,还要确保没有引发新的缺陷。最后,做好测试复盘工作,针对本轮测试过程中存在有疑问的地方,进行总结,以及和相关部门人员保持好一致意见。
所以,作为一名合格的测试人员,一定要仔细,认真完成自己的本职工作,毕竟漏测极有可能会引发商业风险,做好质量管理的践行者!
最后感谢每一个认真阅读我文章的人,看着粉丝一路的上涨和关注,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走! 希望能帮助到你!【100%无套路免费领取】