从软件工程角度看测试
这是软件工程系列的第六篇文章，我想从软件工程的角度来谈谈关于软件测试的一些话题。
软件工程的核心
软件工程简单来说就是多人参与、有计划有步骤的构造一个符合质量标准的软件产品的过程。参与人越多、产品越复杂、流程越繁琐，最终构造的软件产品就越可能出现问题。
软件工程出现的初衷，就是为了摆脱软件质量危机，其核心内容是要用工程化的方法去规范软件开发，让软件开发项目可以按时保质完成的同时且成本可控。
抽象归纳可以称之为一个核心三个方法，即：以软件开发为核心，对开发过程组织+对方法的运用+对工具的使用。
以工程方法，解决复杂性下软件质量的不可控，所以质量是其最核心的部分。
软件测试的本质
记得刚开始从事软件测试工作时，那个时候测试的岗位很多企业的定位是QC，就是质量检测和控制。
从软件测试工程师的日常工作来说，绝大多数时间都是在分析需求写case、发现bug、跟进bug解决和验证。
近几年的软件测试岗位，开始逐渐变为了QA，即质量保障。
看似只是一个名词的变化，其实背后对应的是企业对软件测试这个岗位有了更多的要求和期望。
当然也有同学会自嘲自己是点工、PageClienter等，面试造火箭入职拧螺丝的背后也存在很多无奈。
无论行业如何变化，软件测试的本质还是和软件质量息息相关的。
前面的文章聊过，质量保障需要“风险可识别+问题可追踪+结果可验证+数据可量化”，才能最大限度的实现其价值。
CKL老师也提到过“业务可验收、研发可实现、测试可验证、部署可交付”等类似理念，本质是在描述如何评估软件质量。
那么，质量保障应该如何理解？我们可以从软件质量保障和交付生命周期的三个阶段来做不同的定义。
需求设计质量
我们谈软件质量，不可避免要从它的源头说起，而源头就是需求和设计阶段要做的事情。
这个阶段包括原型图、PRD文档、交互设计、技术方案、测试用例等几项重要产出物，当然他们有一定的前后依赖关系。
在需求设计阶段，我个人认为比较重要的有如下几点：
- 需求评审（是否有遗漏、描述不清、存在逻辑漏洞等）；
- 设计评审（设计是否满足需求要求、是否合理美观友好）；
- 方案评审（方案实现难易程度、可测性、是否需要更多资源）；
- 用例评审（场景是否尽可能覆盖、和技术方案实现是否吻合）；
为什么要做大量评审工作？因为如果源头存在问题，那么研发过程和用户使用质量就无从谈起，方向错了就全错了。
评审的价值在于从用户使用场景角度出发，通过评审提问，把需求逐步澄清并形成验收条件，产、研、测三方共同确认，形成共识，以保证大家对需求的认知不发生偏差，为后续团队正确的做事提供有价值的指导。
研发过程质量
“软件质量是构建出来的，不是测试出来的”。
测试的本质是验证研发交付的产出物是否达到需求设计及预期的标准。并不能直接带来质量的提升，只能通过种种手段多维度的去验证是否达标，并通过流程规范、度量标准等去保障最终的交付物达标。
因此，我们常说的各种测试技术手段，都是验证和保障交付质量的手段，而不是构建质量的手段。
当然，开发有自己的一套体系，比如编码规范、单元测试覆盖率等，这里不做详细描述，我们重点关注测试维度。
用户使用质量
用户使用质量，指的是软件线上发布后，我们对用户使用过程进行追踪并采集数据进行评估度量的过程。
软件工程是将软件研发过程进行科学管理以控制质量，通过流水线的形式进行交付上线。
而软件测试则是通过一系列手段来验证最终的交付产出物是否达到预期的质量标准。
那么，谁该对软件质量负责呢？
谁对软件质量负责？
通过上文可以看出，软件质量的构成主要由需求设计质量+研发过程质量+用户使用质量三者决定。
换个角度来理解就是软件质量=功能质量+代码质量+过程质量。
功能质量用来评估软件产品是否满足用户的预期需要，代码质量很大程度上决定了最终交付质量的下限，过程质量则是整个研发交付过程是否足够标准高效。
因为影响质量的因素，除了需求和代码，还有投入的成本、涉及的范围以及时间。
既然软件质量的构成和影响因素有多方面，那么软件质量也并不是独独由测试工程师负责。
有一点需要明确的是：在工作中一定要权责对等，而不是按照岗位名称定责甩锅。
按照软件质量=功能质量+代码质量+过程质量的公式，那么应该由如下三种角色对软件质量负责。
- 功能质量：软件测试工程师；
- 代码质量：软件开发工程师；
- 过程质量：项目经理/项目负责人；
我一直有个观点是技术本身不产生价值，需要借由业务的商业价值来体现技术的价值，技术对业务提供支撑和服务。
所以无论是测试还是开发或者项目经理，其实本质利益是一致的。
权责分明，利益明确，保持一致的方向和质量保障理念，才能更好的交付高质量的软件产品。
