一、软件测试工程师须知
良好的沟通和表达能力
具有怀疑与破坏的精神
扎实的软件测试基础知识
缜密的业务逻辑分析能力
处在用户的角度进行换位思考
足够的耐心、细心、信心、责任心
积极乐观向上的心态和团队协作能力
要有严谨、敢于承担责任、稳重的做事风格
善于自我总结、自我督促和不断学习的能力
二、软件测试职业规划 & 转职
产品总监(ProductOwner)
项目经理 (ProjectManager) / 技术经理 (Technical Manager)
QA (Quality Assurance) 或者法律法规部门
测试开发 (TestingDeveloper)
（领域）业务专家 (BusinessExpert )
手工测试(Manual testing)唯一和最后的出路，但此路其实很光明
销售（ Sales ）
售后技术支持 (TechnicalSupport Engineer)
运营 (Operation)
培训师 / 教练 (Coach)
测试的内容：
B/S 架构的 Web 测试，如各种网站 (Website)
APP 的测试， iOS ，安卓，在手机上或在 iPad 上
C/S 架构的软件测试，多为桌面应用程序 (Application)
手机测试 (MobilePhone)
嵌入式软件测试（测试硬件设备里的软件功能
游戏测试
搜索引擎测试
本地化测试
AI 测试？
区 块链测试
不同的需求类型（Requirement）
用户需求（ UserRequirement ）
开发需求规格说明书（ DEV Requirement Specification ）
测试需求（ TestingRequirement ）
测试需求收集
客户、 产品线经理（ ProductLine Manager ， PLM ）、 项目开发经理或负责人
需求的显性和隐性
显性：明确规定的功能与特性
隐 性 ：没有被明确规定但是有可能或应该拥有的功能与特性，例如：娱乐圈的潜规则，汽车必须要有轮胎且必须是四个轮胎，飞机必须要会飞等一切约定俗成的东西
软件测试类型以阶段划分
单元测试（Unit Test）：单元就是人为规定的最小的被测功能模块。一般是开发做的，测试一般也就做代码插桩。
集成测试（Integration Test）： 开发好的模块之间的集成 第三方接口集成 设备集成（医疗行业见多）
系统测试（System Test）：所有模块开发完毕后，打包给测试做的测试，我们大多数时间做的其实都是系统测试，玩法极多
验收测试（Verification Test）： 冒烟测试（ Smoke Test ）、 回归测试（ Regression Test ）、 自由测试或叫作随机测试（ Free Test ）
Alpha测试与Beta测试：Alpha测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，但不能由程序员或测试员完成。 Beta测试是在一个或多个或大量用户的实际使用环境下进行的测试，但不能由任何公司内部人员完成。
A/B测试：主要是为Web网站或App软件制作两个（A/B）或多个（A/B/n）版本，在同一时间维度开放给终端使用的用户。这些版本用来收集各种用户体验数据和业务数据，最后分析评估出最好版本来正式采用。
测试基类
自动化测试（泛指功能）
性能测试
安全性测试
泛指 Web 网站方面、 医疗行业、 汽车行业等、 区 块链？去中心化后能否安全
Web安全性测试定义：建立整体的威胁模型，测试溢出漏洞、信息泄漏、错误处理、SQL 注入、身份验证和授权错误。
静态测试
指测试不运行的部分 —— 只是检查和审核。开发人员方面如：代码走查，代码 Review ，代码比较等；测试人员方面如：界面美观度“鉴赏”，测试文档检查，测试程序翻译问题的本地化测试（也算是一种静态测试类型吧）等
动态测试
指通常意义上的软件测试，使用和运行软件、网站、 APP 等，就是我们常讲的“点点点”。
软件测试用例
测试用例设计方法
1、避免冗余
2、测试其中一个最具有代表性的值就能代表这一类的其他任何值，即：将无穷尽的测试数据进行合理分类
3、等价类划分只适用于黑盒测试
4、等价类的基类永远只有两种：有效等价类和无效等价类。PS：有效等价类就是指对于程序的需求规格说明来说是合理的，有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。
举例: 对电话专员的评分，范围是0~10之间，低于6分可能被炒鱿鱼
有效等价类：0<=Point<=10、 无效等价类：Point<0或者Point>10
二、边界值分析法
边界值分析法就是对输入项的边界值进行测试的一种黑盒测试方法，是作为对等价类划分法的补充，基本就是绑定使用的。
因果图法
1 或 0 （默认表达方式， Default ）
1代表真 0代表假
Y 或 N
Y=Yes代表真 N=No代表假
T 或 F
T=True代表真 F=False代表假
4种原因与结果的关系
4种原因与原因的约束
E约束（排他性约束、Exclusive）：C1和C2中最多有一个可能为1，即C1和C2不能同时为1
I约束（包含性约束, Inclusive）：： C1、C2、C3中至少有一个必须是1，即： C1、C2、C3不能同时为0
O约束（唯一性约束, Only）：C1和C2必须有一个且仅有一个为1
R约束（必要性约束, Request）：： C1是1时，C2必须是1
M约束（强制约束，Masking）：：唯一的针对结果的约束；若结果E1是1，则结果E2强制为0
判定表法Decision Table Method：
判定表是分析和表达多种输入条件下系统执行不同动作的工具，它可以把复杂的逻辑关系和多种条件组合的情况表达得既准确又明确。
一般情况下，我们在画出因果图后写出判定表，两者绑定使用。但是无论是因果图法也好，判定表法也好，它们两者都是可以单独使用的。
根据个人喜好，熟练了以后，可以考虑直接使用判定表法，省去画图步骤（Normally）。
因果图+判定表的经验结论
判定表法的优点：
1、充分考虑了输入条件间的组合，对组合情况覆盖充分；
2、最终每个用例覆盖多种输入情况，有利于提高测试效率；
3、设计过程中，对输入条件间的约束关系做了考虑，避免了无效用例，用例的有效性高；
4、能同时得出每个测试项的预期输出。
判定表法的缺点：
1、当被测试特性输入较多时，会造成判定表规格过于庞大；
2、输入之间的约束条件不能有效区分输入是否确实需要进行组合测试，会造成不需要组合测试的输入做了组合，从而产生用例冗余。
场景法
软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流
现在的场景法就是测试用例设计脑图，人称 XMind
错误推测法
任何有意义的错误推测都值得单独写一条测试用例， 一般情况下，推测开发需求中没有明确指明的， 错误推测法很随意，就是个头脑风暴