寻求底层软件测试方法

1.华为、中兴等通信公司的嵌入式软件测试是如何开展的

分不同的阶段

2.工作内容上如何避免与评估或其他部门的重复性

自动化

3.嵌入式软件测试采用哪个工具比较好

一般自已开发

“事物间的共同点，就是底层逻辑。

只有不同之中的相同之处、变化背后不变的东西，才是底层逻辑。

......

底层逻辑+环境变量 = 方法论”

所以我们要来探讨一下：软件测试的底层逻辑是什么？

1. 对软件测试的基本认知

对软件测试的基本认知，使我们达成共识，从而基于这个共识，更容易去讨论软件测试的底层逻辑。对软件测试的基本认知，需要精简到一句话来描述，即抓住软件测试的本质，以简洁的方式描述正确的软件测试价值观，但不是某个人的软件测试价值观，而是能被大多数人接受的软件测试价值观。

软件测试是验证软件功能特性是否满足需求；

软件测试就是发现软件中存在的缺陷

软件测试包含了静态测试——需求、设计、代码的评审活动

软件测试是系统、完整地评估软件产品质量，提供质量信息

软件测试是暴露、揭示产品质量风险

软件测试不仅是技术性活动，而且是 社会 性、心理等多方面的综合性活动。

软件测试是通过投入质量保障性成本来极大地减少劣质成本

根据这些对软件测试的认知，用一句话来说明软件测试的基本认知，那就是：基于对用户真实需求的理解，通过各种手段获得软件产品真实的、全方位的质量信息。无论是验证软件功能特性是否满足需求、评估产品的质量还是揭示产品的质量风险，都是基于获得的有关产品的真实的质量信息做出判断的，而缺陷可以看做是这个活动过程中的副产品。

这里强调对用户真实需求的理解，一方面体现“没有用户就没有质量，质量相对用户而存在”，我们必须从用户角度出发来完成测试，另方面是用户的真实需求，而不是虚假的、错误的需求，业务的需求最终要分解成用户角色的需求，而系统的功能/非功能性需求也是为了满足用户的需求。

这里提到的“软件产品”不局限于程序，还包括数据、需求文档、设计文档、代码、用户手册、技术手册等。

了解了“什么是软件测试”之后，下面就可以讨论软件测试的底层逻辑。

2. 软件测试的底层逻辑

软件测试的底层逻辑可以概括为三个问题的回答：

为什么测？

测什么？

如何测？

而且在回答这三个问题的过程中，要能适应不同的测试对象（如Windows/MacOS native应用、 web软件、移动app、嵌入式软件 ）、不同的测试类型（如功能测试、性能测试、安全性测试、兼容性测试等）、不同的测试层次（如单元测试、集成测试、系统测试等）、不同的团队和不同的产品等，成为放之四海而皆准的答案。虽然上下文不同，会有不同的测试方法、技术和实践，但我们能抽象出它们的共同点。

基于这样的考虑，那下面就来回答这三个基本问题：

为什么测？只要是人做的工作，就不能保证万无一失，会存在问题。如果软件带着问题出去，就很有可能给客户带来损失或让客户不满意，最终导致企业的利益受损。过去无数的质量事故，也证明了这一点，在交付给客户之前，软件需要得到充分的测试，否则后果严重。

测什么？取决于交付的质量目标，即从质量目标出发，进行目标分解，然后针对每一个特定的子目标来确定要获得的有关被测对象的质量数据，从而确定其测试范围或测试项。如果再进一步，我们根据用户对质量特性、功能特性的感受不同来决定测试项的优先级。这部分属于测试分析的工作，并涉及测试风险和测试策略。

如何测？就是找到获取被测对象的质量数据的方式、方法或手段，包括测试方案设计、场景设计、测试用例或测试数据等的设计。

软件测试灵魂三问，如何怼回去？

第 1 问：为什么这个 Bug 测不出来？

第 2 问：测试怎么测得？到底会不会测？

第 3 问：测试快点啊！为什么总是测试拖后腿，最后才报 Bug？

其实也体现了“软件测试”的另一层逻辑，即：

第1问的答案所呈现的底层逻辑：测试是不能穷尽的，测试总是有风险的，而且开发写出的Bug越多，测试漏掉的Bug越多；测试只能证明已发现的缺陷是缺陷，不能证明软件没有缺陷，因为测试是一个样本实验。

第2问的答案所呈现的底层逻辑：对所做的测试工作（包括测试目标的制定、测试分析的过程以及对应的测试设计方法）能解释清楚，而且测试不是孤立的工作，受需求（如需求模糊）、系统设计（如耦合性、复杂性）、编程（如偷偷修改代码）等影响，测试要与产品、开发等紧密合作。

第3问的答案所呈现的底层逻辑：我们可以在开发写完代码之前完成测试分析、测试计划和测试设计，但系统层次的测试执行需要等待开发完成版本构建，测试执行是后期工作，测试时间容易被开发前期工作挤掉一部分，项目的延期容易造成错觉——测试拖后腿。

测试的底层逻辑（概率思维）：测试是一个样本实验，需要精心分析和设计，努力以最小的代价并尽早地去揭示质量风险。

3. 测试流程的底层逻辑

测试流程符合一般工程项目流程，经过分析、计划、设计、实施和评估的过程，任何一个环节不可缺失，每一个环节都重要，但前面的环节会影响后面的环节，所以越在前面的环节越重要。测试分析是基础，依次是设计、实施和评估，构成一个金字塔模型。

测试流程的另一个底层逻辑：形成闭环。如果经过评估，发现测试过程有问题，需要重新分析、修改计划、修改设计......再经过一个完整的过程，构成一个新的闭环。

4. 测试分析的底层逻辑

测试分析的底层逻辑是基于系统思维、结构化思维去思考，需要从项目背景、产品结构、质量要求等各个方面进行系统地思考，不容忽视一些蛛丝马迹，顺藤摸瓜，完整地呈现测试范围，识别出各种测试风险，最终明确测试项及其优先级。

测试分析的底层逻辑之一：测试分析是层层剥离、逐步深入的系统分析过程。从业务需求、用户行为、系统功能、应用场景等不同维度对被测对象进行系统的分析，最终确定测什么。

测试分析的底层逻辑之二：测试分析也是一个博弈、选择直至平衡的过程，需要定力和洞察力，做出取舍，如运用80/20原则，抓主要风险，有时需要舍弃一些次要风险。

测试分析的底层逻辑之三：以终为始，从测试目标出发最终回到测试目标，如从考虑如何衡量测试充分性地要求出发，最终分析的结果——各测试项完成是能够满足测试充分性的要求的。

5.测试人员的底层逻辑

最后谈谈测试人员的底层逻辑。测试人员是否有价值，不取决于他/她目前的工作态度、知识与技能，而是取决于工作态度、知识与技能的进步速度，因为我们无法改变过去，但可以改变未来。只要持续学习、持续反思，就能快速完成自己的进化，快速成长起来，就没有人能挡得住你的壮丽前程。

   你对底层程序员有何看法？他们的主要工作是什么？

程序员，外面都说人傻，钱多，死得早。

不过我本人是程序员，所以不完全认同，但是也不能说没有。程序员因为天天和代码打交道，代码是很多逻辑的部分，所以程序员一般逻辑思维不会太差，但是整体来说和人交接和情商就比较低。

a

因为一群大老爷们讨论需求什么的就是各种吵吵，基本上说弄就弄。

然后程序员的起步工资确实比较理想，但是后期其他行业工资也会上来。程序员的工资都是加班加出来的，不管多么好的公司，出产品的时候各种加班，有一些加班是阶段性，但是有很多的公司就是长期性，基本上每天都是加班。所以加班也是程序员的标签之一。

程序员因为逻辑长期脑力运动，再加上程序员都是很懒的，肯定也有爱运动的，但大部分都比较懒，我接触的懒人居多，不会特别去装扮自己（包括女程序员，基本都不会化妆的）。

所以程序员会有一点点的邋遢，但是邋遢和脏是两回事，邋遢只是不爱打扮，但是个人卫生一般还是可以的。然后体格方面也不会太好，长时间坐着，大肚子的概率和秃头非常高，我的几个老大头发都比较稀少掉头发，我现在也开始掉头发。

所以死得早应该是说这个。

还有一点，程序员聊天的时候喜欢说一些代码性的东西，外行感觉十分奇怪，但是这是程序员的笑话，这个是职业病，其他职业应该也有。

b

不过程序员谈恋爱的时候这些毛病一般很少存在，都会刻意去避免。

总的来说程序员其实也还好，只是一个职业不会有太大的区别，人际关系可能差点点，然后逻辑肯定不差。其他就是宅。

技术的日新月异，各个公司的血液不断换新，企业想要发展依赖于产品，而产品的开发归于技术的支持。新老开发人员的不同在于，老一辈的开发人员在年轻时学的技术在现在应用的很少了，生活上上有老下有小，体力和精力投入的要少，学习新技术的能力比不上年轻人，思路也不灵敏了，逻辑分析能力，理解能力逐步减退，唯剩经验，但是 IT 届的经验不如创新值钱。

既然从事了程序员，那自己就在这个行业学点东西。但是中国跟国外的程序员就不一样，中国的程序员懂得很全面，而国外的是对一个方面很精的这种。

c

1.自己把技术学到位。往大公司发展，才能真正地学到东西。2.实在不行，用做程序员这几年的资金，做点小生意，有魄力，就往大的方面发展。要不就安安逸逸过一生。

---