一方面，软件测试工程师所知良好的沟通和表达能力怀疑和破坏精神扎实的软件测试基础知识缜密的业务逻辑分析能力足以从用户角度转换思考的耐心、细心、自信、责任感积极的心态和团队合作能力是严格的二、软件测试职业规划跳槽
产品总监(ProductOwner )。
项目经理(项目管理器/技术经理(技术管理器) QA (质量评估)或法律法规部门测试开发(测试开发器) )领域)
销售(销售)售后服务(技术支持工程师运营(Operation )培训师/教练(Coach ) )。
测试内容：各种网站(Website ) APP的测试、iOS、Android、手机和iPad上的C/S架构的软件测试等B/S架构的Web测试，是桌面APP应用) APP
不同的需求类型(请求)
用户要求(用户要求开发要求规范) dev要求规范测试要求(测试要求)测试要求收集
客户、产品线经理(PLM )、项目开发经理或联系人的需求的潜在性和隐性
显性：明确规定的功能和特性隐性：没有明确规定，但有可能或应该具有的功能和特性。 例如，娱乐圈的潜规则，汽车需要轮胎，而且轮胎必须是4个，所有约定飞机飞行的一般东西的软件测试类型都是分阶段的
单元测试(Unit Test )单元是人为制定的最小的被测功能模块。 一般是开发制作，测试也一般制作代码的插入桩。
集成测试(Integration Test )在开发的模块之间集成第三方接口集成设备(医疗保健行业常见) ) ) ) ) ) ) ) ) ) ) ) )。
系统测试(System Test )开发所有模块后，打包进行测试的测试。 我们大部分时间都在做系统测试，玩得非常多
验收测试(验证测试) :称为冒烟测试(Smoke Test )、回归测试(Regression Test )、自由测试或随机测试)
alpha测试和beta测试： alpha测试是用户在开发环境中进行的测试，或内部用户模拟实际操作环境进行的管理测试，但不能由程序员或测试人员进行。 beta测试在一个或多个用户实际使用的环境中进行，但不能由内部人员进行。
A/B测试：主要为网站或App软件创建两个(A/B )或多个(A/B/n )版本，并在同一时间维向终端上使用的用户开放。 这些版本用于收集各种用户体验的数据和业务数据，最终分析评估和正式采用最佳版本。
基类测试
自动化测试(通用功能) ) )
性能测试
安全测试
是指区块链，如网站方面、医疗行业、汽车行业等吗？ 中心化后能否进行安全的Web安全测试定义：建立整体威胁模型，测试溢出漏洞、信息泄露、错误处理、SQL注入、认证和授权错误。
静态测试
指向不运行测试的部分的——只是检查和审查。 开发者方面，例如代码检查、代码Review、代码比较等测试负责人方面，对界面美观的“欣赏”、测试文档的检查、测试程序的翻译问题的本地化测试(也称为静态测试类型
通常意义上的软件测试，使用软件、网站、APP等来执行是我们常说的“有点”。 软件测试用例
测试用例设计方法1、等价类划分法
1、避免冗馀
2、测试中最具代表性的值之一可以表示这类其他任何值，即合理分类无限的测试数据
3、等值类划分只适用于黑匣子测试
4、等价类的基类总是只有有效等价类和无效等价类两种。 PS :有效等价类是对程序要求规格说明合理、有意义的输入数据集合。 可以利用有效的等价类，验证程序是否实现了规格书规定的功能和性能。
比如：对电话专家的
评分，范围是0~10之间，低于6分可能被炒鱿鱼有效等价类：0<=Point<=10、 无效等价类：Point<0或者Point>10
二、边界值分析法
边界值分析法就是对输入项的边界值进行测试的一种黑盒测试方法，是作为对等价类划分法的补充，基本就是绑定使用的。因果图法 1 或 0 （默认表达方式， Default ）
1代表真 0代表假
Y 或 NY=Yes代表真 N=No代表假
T 或 FT=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错误推测法
任何有意义的错误推测都值得单独写一条测试用例， 一般情况下，推测开发需求中没有明确指明的， 错误推测法很随意，就是个头脑风暴