测试基础 如何保障你的被测系统覆盖度是全的

大侠 · 2024年10月12日 · 最后由 CKL的思考 回复于 2024年11月04日 · 7022 次阅读

如何保障你的被测系统覆盖度是全的?这个大家有什么好的方法论或者实践吗

共收到 8 条回复 时间 点赞

根据需求,设计整理测试用例, 只要三方评审觉得完整就是全的。
PS 没有绝对意义上的百分百覆盖,只有基于需求和修改范围和风险评估来整理合理的覆盖范围。

  1. 让干系人相信你覆盖全了,哪怕一个用例,你能做到相信
  2. 不会出生产问题
  3. 如果出了生产问题,让大家觉得怪不了你

一层一层的包裹,第一层对需求规格进行测试,保证需求的覆盖度
第二层对需求进行拆解,按测试的维度进行大的测试规划
第三层 对每种测试 (功能 性能 可用性 安全) 再进行第二层规划
第四层 就是测试用例,用例要保证覆盖测试策略
第五层 用例的执行是否到位,问题是否记录
每一层出问题都会影响被测系统覆盖度,量力而行就好

软件测试原则:完全测试是不可能的

你这给自己挖了个大坑啊?为啥会有这样的诉求呢?

这个问题区分是向别人证明覆盖性和向自己证明覆盖性。
不少项目并没有可靠的测试依据材料,都是参考性资料和大量测试人员探索确认的功能内容。如果你去看各种黑盒功能测试方法的描述,它的前提就是存在这种理想化的东西。
如果只是对外证明测试工作的专业性,那么基本上把你现在的测试内容总结提炼一下就可以了,比如什么根据产品文档、需求手册、会议记录等等提取测试点外加业务回归之类一通描述就够了。这个有很多评论都是这样的,通常你对外做说明只需要确保对方信服即可。
而你自己思考覆盖是否完善,国家软考有一个软件测评师证书相关的书,从软件质量测评的角度提出了几个衡量软件质量的维度。包括功能、安全、兼容性等等,虽然这些都是测试行业老生常谈的用词,但是我觉得这是一个很好的角度。既然要谈覆盖,那肯定得基于某个标准/定义选择不同挡位对应精细程度来执行的不是麽。
软件产品和硬件一样,不一样的标准对应不同的产品。军工的民用的,高端的低端的各有不同,那么你的产品需要怎么样的质量标准呢?

测试充分性包含三个层次的:代码层次的测试充分性、系统(功能/非功能)层次的测试充分性、业务层次的测试充分性,而 “业务层次的测试充分性” 最具决定性的。

代码层次:这一层次在很长一段时间内,是被测试人员忽略的(能力不够)。万丈高楼平地起,测试人员需要花一部分精力去关注代码层的交付质量:代码静态分析、覆盖率验证、全链路测试、契约测试等,可以快速提升测试效率。同时,这个层次也是最适合做自动化的层次。

系统(功能/非功能)层次:大部分测试人员的主要精力都会花在这里(自称点工)。根据现有的需求文档或者 Story 描述,结合业务特点和自己的经验,通过测试用例的设计,验证功能点的正确性。并适当地开展一些非功能性测试。只关注这层,往往会忽略很多上下游业务依赖的错误,或者是底层代码在特定场景下的问题。

业务层:这里指的是需要有端到端的业务视野,从全流程的角度去验证复杂场景。这需要测试人员对业务非常熟悉,同时也熟悉业务关联的上下游系统。这类测试人员其实非常难得(在制造业的某个领域,曾经半年招不到一个,但这类人其实就业面也比较窄,因为对口的业务公司也不会太多,所以专注业务的同学需要慎重选择深入哪个业务)。

在做测试策略和测试设计时,需要针对以上三个层次都有所覆盖,才能提升测试的充分性。

可参考:https://testerhome.com/topics/40827

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册