在构思“汽车电子软件测试的脉络”这个主题时，我脑子里先是蹦出来三个词：哲学、本质 和 底层逻辑 。
同时转念一想，打算通过一篇文章就想探到如此深度岂非痴心妄想和不知天高地厚。实际上，诸多冠此类帽子的文章多是名不副实。算了，人近不惑，脑力渐衰，把书读薄也更甚于读厚。
不过，读薄的前提至少是要有体系和脉络。所以选用了“脉络”这个词，细想来，确实比前面想到的那三个词更合我真意。
在开始这条脉络之前，还是先把概念澄清，以设定一个理解基线。
什么是软件测试？
《软件测试的艺术》的作者梅耶的定义是“软件测试就是为了发现缺陷而运行程序的过程”。
尽管不同的角色在不同的角度都有不同的定义，比如有从需求入手的、有从质量着眼的，也有从一致性、风险和成本等展开的……
各有各的道理，但我从实务的角度看，选用了梅耶的定义，毕竟运行程序发现缺陷是我们日常可见的测试的最显著特点。
好，正式开始。
为了更贴近实际项目运行，我大体按照业务的运行时间线，把这条脉络的一头一尾分别定义为“测试策略”和“测试汇总”。
1、测试策略
在企业里，我们所做的所有工作，从来不是独立的，也从来不是单一的技术问题或者管理问题，而是需要一个统筹的考虑。
测试也一样，开始之前我们要有“策略”，这是一个High-level的概念，多少有一点模棱两可，很难说清楚其准确内涵，不同干系人也有不同的期望，本文给三个参考的维度，分别是测试规则或指南、测试目标和测试原则。
尽管实际工作中，我们基本无法清晰地拆分出隶属于不同维度的工作，而是相互混杂和渗透，但为了便于沟通和理解，暂且还是按此拆分。
1.1 测试规则或指南
测试规则或指南，我们把它定义为统领性、强制性或推荐性的一些规则、要求或建议，它们一般由公司层面整体定义，并要求执行。
比如，什么节点前应该做测试分析，应该用哪个报告模板，什么测试条目是必测项，测试用例的选择要考虑哪些，测试的准入准出规则是什么，是否必须先完成冒烟测试，什么情况下必须做压力测试，测试覆盖率怎么考虑，测试通过率怎么定义，如何区分不同层次测试的责任人，缺陷的处理方式，测试与需求的追溯性要求，单元测试必须在其他测试前完成，回归测试时测试用例如何选择，自动化测试比例及开始时机怎么定义，必须执行全量测试的标准等等。
会有很多的角度去定义，无法详述。
总之，是一些基于公司策略和历史经验等制定的纲领性的文件。
当然，多数不那么规范的公司不会定义很细，要求也不会很严格，姑且有这么个概念。
1.2 测试目标
测试目标呢，比较宽泛的理解有查找问题、确认满足需求、避免问题泄漏、保证客户满意、提升质量、降低成本、推进持续改善等等。
这些内容虽然并不难理解，但还是太泛泛而谈了。
在具体的某个客户、某个平台、某个项目、某次迭代、某次交付的组合里，会有多方面因素要考虑，这是个复杂的且需要背景信息的事，无法简单说明。
举几个可能需要思考的问题，感性感觉下。
这个客户对测试报告的提交需求是什么？这次上了哪些主要功能点？该平台或该项目是否有历史LLs？已经识别到什么潜在风险需要测试探测吗？内部有什么质量目标？本次交付变更点是什么？自动化测试台架是否可用？这次是工程车间装车，还是台架或者产线？什么功能是本次交付最关注的？是否上路，上什么路……
综合各种信息，项目经理或测试经理可以来统筹判断及调整本次测试的目标，据此再来进行后续的计划、执行等工作。
1.3 测试原则
考试有答题技巧，工作有方法论，打仗有兵法。测试原则差不多等同于这类。在整个和测试相关的工作中，是否有一些参考性的原则呢？
1、要尽可能早地测试。这是质量成本的原则，发现问题越晚，成本和影响越高越大。
2、不可能进行穷举式测试。进行完全的测试是不可能的，完全没有任何缺陷的软件也是不存在的，要根据风险评估进行测试用例设计，进行最佳的测试量定义。
3、关注缺陷群集效应。二八法则我们都听说过，在此也是适用的，少量的模块经常包含大部分缺陷。统计数据也表明，一段程序已发现的缺陷越多，则该段程序发生更多缺陷的可能性也很大.
4、杀虫剂悖论。如果同一个测试人员重复执行相同的测试，该方法将无法发现新的测试缺陷。这既有测试用例更新不及时的原因，也有测试人员的思维定势和思维懈怠的原因。所以测试用例要经常更新，测试人员也可以适时轮换。
5、测试只能证明存在缺陷，而无法证明不存在缺陷。因为测试实际上是一个样本实验，不可能涵盖所有情况。
6、没有缺陷不代表软件一定能够使用。比如测试用例本身未覆盖需求，这其实说明了测试本身的局限性，也说明了我们要进行全方位软件开发及测试管理的必要性。
7、测试最好由非软件开发人员担任。这是从心理学角度来看的，毕竟让一个人否定自己的工作是令人沮丧的，而且如果开发人员对某个功能有错误认识，再去测试可能依旧无法识别。
8、测试顺序。为了尽可能早地合理退出，要首先执行具有较高失败概率的测试。比如，最好依次进行冒烟测试（核心功能预测试）、缺陷重新测试、测试新功能、测试修改或优化的特性、测试未改变的特性(回归测试)。
实际工作中，策略更多是在项目经理或测试经理脑子里的整体谋篇布局，以上三个维度是落于纸面上的一个参考。
2、测试管理
有个通盘的策略性考量后，就可以进入管理层面的工作上了。
接下来看测试管理。
当组织结构庞大和软硬件功能复杂时，测试也同样会变得很复杂和容易混乱。
这时，就非常需要由专门的人按照特有的流程进行组织和管理。管理的范畴很大，为了避免描述混杂在一起，我们这里只谈小管理，不涉及具体工程层面的内容。
我们可以将测试管理的目标定义为：根据确定的测试范围，交付与测试相关的工作包（例如，测试规范、测试执行、评审和报告等），同时还要满足项目进度计划中定义的里程碑节点。