软件测试是质量需求的交付实践

最近反复被测试有用吗？测试必须测试工程师完成吗？为什么要做自动化测试？自动化测试的价值是什么？等等一系列的问题不断地拷问，索性就把这段时间的思考记录下来了。

软件测试的必要性

在混沌初开之际，软件开发和软件测试还是一个角色独立完成的一个事情，后来伴随着软件工程的发展，开发和测试逐渐的分开，那么随着工程化的逐渐深入，研发运营一体化的高速发展，软件测试是否还需要单独存在时不时的就回出现在各大团队内部的会议上。软件测试是不是存在其实蕴含着两方面，一方面是测试工作的独立存在，一部分是测试工程师的存在。相信说到这里很多人第一反应就是测试工程师必须存在，为什么呢？因为出问题了要有人背锅。其实并不尽然，我们先从测试工作存在的必要性开始聊起，测试工程师存在的必然性也就应运而生。

美国质量管理大师克劳士比(Philip Crosby)提出质量成本(Cost of quality-COQ)是指为了防止出现错误以及产生错误而引起的一切费用。假定你要提供一种优质的产品或服务给你的顾客，质量成本是指你因为不能第一次便做好(Doing the right thing the first time)而产生的所有有关成本。质量成本通常包括三方面: 预防成本(Prevention cost)、鉴定成本(Appraisal cost)及失效成本(Failure cost)，而失效成本又可分為內部的成本(Internal cost)和外部的成本(External cost)三者加起来就是所谓质量成本(Cost of qualit）。

我们引用质量成本的概念，在软件开发过程中如果没有测试实践，那么软件的缺陷就会导致类似传统工业一样问题，顾客会反馈“问题“，团队要付出努力找到问题，并修复问题，在这个过程中开发团队付出了鉴定成本，企业也因为影响了客户的使用而需要付出更多的成本重新获得客户信任。测试工作就在系统交付给客户之前用科学的方法设计测试用例并进行逻辑验证，将问题提早暴露、提早暴露的方法，让问题不会暴露在最终用户面前，因此赚取了额外付出挽回用户信任的成本，同时在产品没有直接交付到可以侧前就进行了修复，也大大降低了鉴定成本和修复成本。

讲清楚测试的价值其实可以从测试过程发现的缺陷讲起，想必大家都有为缺陷分类分级的经验，那么我们一般都会按照缺陷的严重程度来划分缺陷，大部分会是致命缺陷、严重缺陷、一般缺陷、建议缺陷，那么这些实际代表的是如果这个缺陷交付到了客户面前我们付出的质量成本的高低，越严重的缺陷付出的质量成本就越高，就越应该在交付过程中解决掉，将其用内部成本的代价付出代替外部成本损失。

测试工程师存在的必然性

软件测试这个过程的实施主体就是测试工程师。那么多少个测试工程师比较合适呢，或者换句话说如上的事情必须要测试工程师完成吗？开发工程师不能完成如上的工作吗？（这里就不包含技术成熟度非常优秀的团队，我们还是说绝大部分团队的现状）。这里其实要强调开发工程师不能做全部的测试工作，”自我检查类“的单元测试还是需要自己完成的。
我觉得”自己不能测试自己的代码“是每一个软件从业者都听说过的至理名言了，那么为什么不能自己测试自己的代码呢？这是有关于一个人类心理学的一个“自我偏见”和“选择性注意力”的问题。当我们欣赏自己的作品时，我们会注意到它们的优点，而忽略它们的缺点。这是因为我们已经知道了我们的作品的背景和意图，因此我们会更容易地看到它们的优点。这种现象被称为“选择性注意力”。选择性注意力是人类注意特征之一。个人不可能同时注意所有呈现的刺激，总是有选择地注意某一刺激而忽视同时呈现的其他多种刺激。例如，课堂上的学生不可能、也不应该对作用于他们视觉和听觉的刺激都作出反应，正常情况下只是集中注意教师的讲授或演示。选择性注意所指向的对象是受个体原有认知结构影响的，因此注意过程是一个主动的过程。同时，我们的作品通常是基于我们自己的想法和创意，因此，我们会对它们产生情感上的依恋。这种依恋可能会导致我们对自己的作品产生偏见，使我们认为它们比它们实际上更好。这种现象被称为“自我偏见”。

如果开发工程师不适合做全部的软件测试，那么最终用户相比就更不适合了，否则就会引起前面所说的质量成本。测试工程师作为发现问题，避免付出质量成本的主要角色还是有他存在的必要的。站在整体的视角，通过最终用户的视角完成测试验证，也会避免如上的“自我偏见”和“选择性注意力”，说白了就是测试工程师可以避免开发工程师的“灯下黑”。

服务于质量需求的软件测试

软件测试和质量的关系其实就如同软件开发和业务需求的关系一样，开发工程师通过编码交付业务需求，测试工程师通过测试交付质量需求。

这里的质量需求有些可能是客户显示的提出来的，有些是隐藏在交付软件的质量特性里而需要被交付的。无论是哪一种，质量需求最终都应该可以追溯到客户的需求中的。所以系统的质量需求也是不完全一致的，有些系统被应用在财务、款项相关的业务中，那么数据的准确性的要求就非常重要，1分钱的错误都有可能出现谬之千里的问题；有些系统被应用在不同的移动设备中，需要用户自主学习，那么兼容性和易学习性就应该更加的关注。除去最终服务的行业、用户以及行业相关监管要求决定了质量需求之外，系统的成熟度应该也是影响质量需求的一个关键因素，初创期的系统、快速开发交付的系统，稳定交付的系统和被替换的系统，每一个阶段的系统对于质量的需求应该都是不一样的，所以也应该有不一样的测试实施方案。

站在质量需求的输入角度，可以分成“无”质量需求、不清晰的质量需求、关键要素的质量需求以及全面的质量需求，其实这么分无非就是为了说清楚什么样的系统应该怎么投入测试，叫什么名字只是一个代号。

• “无”质量需求往往是在项目的被替换期，项目逐渐的退出历史舞台，处于被其他业务替换或者不再使用，从而有很少的变更甚至没有变更，大部分是系统的可用性维护上，这个阶段不会有任何明确的质量需求被验证，往往维护可用性就已经足够了，这种项目不需要测试实践保证质量，测试工程师只是在需要的时候使用原有的测试用例（如果有自动化用例就充分利用自动化用例）完成测试实践，同时参与的测试工程师要负责再次发挥价值的测试用例是有效的和和当前系统是一致的。
• 不清晰的质量需求是在项目的初创期出现的，其中初创期主要是验证想法、最小化验证交付可行性，这里主要只站在商业价值角度的实验，通过快速交付、快速验证能够将业务的想法最小之间周期进行验证，那么这个时候，往往没有明确的质量需求，潜在的一些质量需求在项目交付过程中也不会特别明显的被提及，测试工程师应该在团队中保证功能交付的正确性，这个时期的质量需求重点就是功能性，那么测试工程师主要以手工测试为主，选择一种测试用例管理办法，记录测试用例资产，就足以满足当前的质量保证要求了。
• 关键要素的质量需求是指系统在快速的交付期，需求大量积压，系统交付的过程中并没有明确的质量需求需要测试过程交付，保证需求的正确性是唯一一个被所有人注重的测试内容，兼顾行业监管要求。这个时候测试实践也并不推荐使用大量的自动化测试，使用手工测试完成最终的验收阶段的功能验证是这个时期最为重要的内容，少量非功能由于手工实现的成本非常高，通过一些工具或者自动化技术完成。
• 全面的质量需求是指系统已经进入了稳定的交付周期，有固定的交付周期，需求无明显积压，团队保持相对稳定的需求吞吐量，每个需求都有明确的质量需求，质量需求既有产品经理分析的，也有最终用户实际提出的，还有依据测试工程师的经验在需求质量保证过程中提出来的。测试工程师在这个阶段应该维护大量的自动化测试用例，少量的新业务有一些手工测试，大量的自动化测试用例全面保证了系统的质量，保证了系统功能的正确性，非功能测试也进行了全面的实际，测试工程师也有时间，有条件尝试测试左移、右移的实践。

如上仅仅是通过系统成熟度角度分析了什么情况怎么投入测试，这肯定不是唯一的分析问题的角度，其实这仅仅是一种思路，如果团队技术成熟度非常优秀，那么测试工程师有可能就不存在，测试活动（这里还是需要一个科学的驱动开发方式，例如TDD）全靠开发角色一个人承担，那么上面的一大堆的内容就没什么必要了。