我们都知道,一个软件从无到有要经过需求设计、编码实现、测试验证、部署发布这四个主要环节。需求来源于用户反馈、市场调研或者商业判断。意指在市场行为中,部分人群存在某些诉求或痛点,只要想办法满足这些人群的诉求,且投入产出有差价有利润可赚,就会创造需求。这些需求经过专业的评估分析和加工设计,就会变成具体的业务需求和对应的产品设计图。然后由专门的研发同学设计实现的技术方案,通过编码来将抽象的业务逻辑变成具体的软件产品功能。
产品测试验证通过,再交付给专门的运维或者负责线上部署的同学,在生产环境编译打包发布。然后通过产品发布会或者消息推送告知用户,我们提供了什么软件产品,可以满足你们的什么诉求。
这其中的逻辑很简单,服务提供者提供的软件产品,是否满足了用户的需要。通过提供这个软件产品,服务提供者的业务目标是否达成(比如广告投放、平台手续费、增值服务费)。决定用户使用产品并且不断有更多的用户使用产品的因素,在于用户对产品是否认可,在于用户的量级和留存转化(人越多,成本越容易摊薄,业务场景也越多,商业利润的来源方式就越多)。
我们都知道,随着业务复杂性和系统架构复杂性的提升,以及团队人员的变动、需求的迭代和各种配置的变更,软件本身可能会出各种问题,这是一个不断墒增的过程。软件研发交付已经变成了一个特别复杂的团队协作才能完成的巨大工程。为了控制复杂性不断墒增,为了降低软件可能出问题的风险和影响,为了保证复杂的团队协作可以朝着同一个方向前进,为了保证软件研发交付过程的每个环节都达成预期目标,我们做了哪些事情?
其中测试用例的作用是什么?写用例是为了验证本次交付范围尽可能覆盖到,不遗漏,交付部分不出问题或者问题已知风险可接受。是一种在有限的已知范围内,尽可能cover风险的手段。
我个人认为,写不写case,做不做质量门禁之类的都是手段。大部分时候,测试做的工作都是测试环境的质量保障,最终发布上线,交付给用户的使用结果和业务目标是否达成,才是真正的质量。只不过人总会失误、遗漏,人的能力参差不齐。所有才要写用例,定规范,用各种手段来保证这件事。你会发现,到最后要解决的,还是人的问题。
如何把不同能力、不同认知的人,用一些手段,让他们的认知、能力、水平保持在某个基线之上,督促这些人完成同一件事,达成同一个目的,这才是关键。测试用例只是测试思维的一个载体,它指导着测试活动的进行,是测试执行的最低保障。过程可控,测试计划,方案,用例,还有日报,周报这些,其实都是为了达成这个目的。质量保障的各种方法和手段,就是提高团队的交付产出物下限。