作者 | 田西西
这篇文章是去年年初写的，过了一年了，如今翻出来看仍然觉得很有意义，所以稍加完善一下分享给大家一起讨论。
在 QA 的认知中什么是质量。保证需求上线不出 bug 吗。记得早期刚入行工作的时候，一名测试的职责是把需求文档翻译成测试用例，并按照用例一轮一轮执行并对过程中产生的 bug 进行 bug 生命周期管理。瀑布模型下的软件周期长达半年甚至一年。测试也是纯黑盒进行，接触不到源码，接触不到部署的环境。
随着软件行业的发展，互联网的兴起，敏捷的引入。软件从瀑布模型、螺旋模型到敏捷开发，软件的发版也变成了一个快节奏的事情，从周二周四上线，到每天都有需求或者 bugfix 上线。测试的工作也从原有功能测试为主到人人自动化，人人工程效能的阶段，而且智能化、精准化也不断的引入进来。
不过随着行业或者工作模式的发展，偶尔回顾下早期的工作，也是阶段性总结复盘的一种方式，也会发现有一些不同的认知和想法。
首先回顾下入行初期我的测试工作，当时为传统互联网行业。
1、阅读需求文档
产品会输出非常详尽的需求文档，包含原型图，字段、按钮、页面交互的详细描述。
2、根据需求文档梳理测试大纲
编写大纲主要是罗列需求的一些功能点，梳理测试思路和根据大纲进行粗略排期。
3、编写测试用例
根据测试大纲编排用例的结构和编写测试用例，此时测试大纲对用例设计思路和防止功能遗漏非常有用。
4、执行测试
根据编写好的测试用例逐条执行并记录执行状态，执行完成后会对本轮执行进行总结报告和用例补充、更新。
根据 bug 修复情况进行 bug 验证及安排下一轮测试计划。
5、软件实施
此部分一般由软件实施工程师进行，将已内测完成的软件带至现场安装调试并进行现场测试。
自此软件就算做发布成功，后续会根据实施工程师或者现场人员的反馈进行问题修复和优化。
过去的流程看似简单，但每个过程都异常繁重，现在回忆起来甚至有点繁文缛节的感觉。但是在如今互联网的时代，有哪些技能依旧值得去不断学习和回顾的呢。
我认为有两个点。测试大纲和测试用例。
这两个点是测试的一个基石，可以串联测试对整个软件生命周期质量的思考。
首先是测试大纲，拿到需求整理测试大纲在当年是硬性要求，在现在的敏捷时代，编写用例都需要敏捷，大纲便逐步退出了测试流程。不过建议大家保持梳理大纲的习惯，方便做出更结构化的测试用例。当然在转转，测试大纲演化成了另一种形态，叫做测试方案，增加了对全流程质量的考虑。一般在需求评审后技术方案产出前后输出，技术方案评审后，用例评审前进行评审。测试方案不仅仅是梳理需要考虑的测试点和测试方法，更是对技术方案、产品方案完整性的验证。
以下就介绍以下方案的几个关键内容以及其价值。
需求背景与目标：对需求的理解
一个好的需求一定是有明确的背景和目标以及要解决的问题，这才是需求的核心价值。而作为测试，一定是了解产品的核心价值甚至某个业务的核心价值，才能测好一个需求。因为背景目标和要解决的问题明确后，后续的技术方案、技术实现都是为这个目标服务，实现甚至放大核心价值。所以这也是判断技术方案、技术实现好坏底层依据。
业务流程及数据、状态流转
此部分内容主要是对产品业务流、技术的数据流或者状态流进行梳理。
对业务流的梳理客服加深对业务的理解，设计出更结构化的用例。
对数据流或者状态流的梳理可以加深对系统设计的理解，进而对系统间的数据交互，状态变化的依据加强梳理，提前发现设计不合理的地方，另外考虑数据交互和状态流转时否需要幂或操作失败是否需要补偿。保障系统不会因服务抖动而导致异常数据同时也不可过度设计增加维护成本。
数据清洗及新老兼容
在互联网需求快速迭代的背景下，数据清洗和新老兼容在前期很容易忽略。如字段变更包括增减及修改字段属性（一般设计中字段只增不减不改，防止系统无法回滚。），需要新版本是否兼容老数据，以及老数据是否要清洗。清洗方案需要考虑上线过程是否可以平滑过渡。另外需要模拟清洗过程是否对业务有影响，以及数据清洗后的正确性。另外数据清洗还需要考虑数据回退，避免不可逆操作。可选的方式有新老环境接口 diff，新老数据接口 diff 两种。
异常测试
前面梳理了数据流转和状态流转，在系统间数据交互、单据状态流转时就可能发生异常。首先要看技术方案对关键业务流程是否做了容错考虑，如事务是否正确回滚、操作成功但触发重试是否有幂等。另外测试中需要在真实环境中模拟异常验证是否与技术方案一致。方式可以选择通过粗暴的修改代码、修改环境进行。如异常测试是常态化工作，也可以开发异常注入平台，让异常测试门槛更低更高效。
回滚方案、灰度方案、监控及指标测试
核心业务一定考虑回滚方案和线上灰度方案及线上的监控指标，尽可能做到上线平稳，一锤子买卖不能做。但是回滚方案、灰度方案、监控是否可靠，还需要按照方案描述的步骤在线下进行模拟测试。
测试数据构造
测试过程中需要各种数据进行验证，此部分需要考虑好数据如何提前准备。另外需要考虑需求的可测性，如数据的可造性以及造数的成本。如果成本过高会导致测试成本及后续回归成本变大，所以在此环节需要同步反推技术方案对可测性的思考。
编写测试用例
写好测试用例需要多久的沉淀，一年？两年？三年？对于测试的基本功面试一个需要长期不断精益的能力。好的测试应该是结构清晰，包含清晰的前置条件、操作步骤和期望结果，理解成本低可交叉执行。同时最关键的是测试用例可以完整的还原需求和技术方案甚至完整程度高于需求和技术方案。
在敏捷化开发的现在，好的用例依然是关键，这里也提供一个关于用例涉及的文章链接：
测试立身之本 - 如何写好测试用例
写在最后，基本功的打磨是一个精益求精的过程，可以在一件事情的基础上拓宽非常多的考虑，最终目的还是做好全流程质量把控，但也要根据实际业务、团队情况，不做过度设计。
