本文目录一览：
- 1、什么是软件测试？
- 2、软件测试的工作内容包括哪些？
- 3、测试流程和测试方法是什么？
- 4、测试有哪些类别？
- 5、测试怎么做
什么是软件测试？
软件测试是依据国家标准GB/T 25000.51-2016系统与软件工程 系统与软件质量要求和评价(SQuaRE) 第51部分:就绪可用软件产品(RUSP)进行的软件检测服务。
具体服务内容需要根据业主单位或建设方的需求，一般都会包括功能性测试，性能测试等。
方法有人工和自动化工具，各家公司都有自己常用的软件，但现在对国产化要求越来越高，无论是对检测环境还是检测工具也好，都有国产化的要求。
承建单位自行测试的报告一般无法作为项目验收使用的，现在如今国家的相关法规对软件上线都进行了严格规定，鼓励第三方软件测评机构参与项目测评，提升我国的软件质量。无论从功能和性能上都要求达到需求规格说明书里的要求，更在安全上也逐步的加强检测。
软件测试的工作内容包括哪些？
软件测试的工作内容包括：
1、修改测试案例；
2、用自动测试工具进行测试，尽早找到软件缺陷，并确保其得以关闭；
3、项目可行性、可靠性分析，风险分析；
4、制定测试计划；
5、测试自动化开发。
职责：
1、为高层提供服务：即测试部门将产品的测试报告提供给高层，由高层作出有关决策。测试报告应包含高层希望了解的产品情况：错误发现率、错误改正率、问题收敛趋势，等等。
2、为项目经理提供服务：向项目经理提供的测试报告应满足项目经理关注的需求，这些需求包括：产品的功能有哪些未满足、性能方面有哪些问题、哪些问题已与程序员沟通，但未达成一致意见，需要提交高层仲裁，等等。
3、为QA提供服务：测试人员参与质量管理活动应该是服务性质的，即他不是去主导质量管理活动，而是为质量管理活动提供服务支持。测试人员通过测试报告，利用事实和数据来反映产品的质量情况，为QA的工作提供依据。
4、为程序员提供服务：测试员要同程序员交朋友，向程序员及时反馈具体的程序问题，并与程序员共同探讨。一方面，测试员通常比程序员更了解业务领域，因此，他能从业务员的视角来检测产品的功能；另一方面，测试员通过测试用例能发现程序员不易想到的问题。
测试流程和测试方法是什么？
测试流程
1、需求分析：需求分析由产品人员制定，细化每一个功能的细节，每一个按钮的位置，对于稍大或复杂一点的需求进行建模。
2、需求评审：所有参与项目人员进行，开发人员、测试人员。测试人员提出需求，开发人员考虑功能实现的方案与可行性、当然开发负责也是要参与的。测试人员主要是对需求的理解提出疑问，以便才能根据需求写用例。
3、开发人员制定开发计划：开发人员需求根据需求功能点进行排期。然后将开计划转交给测试人员。
4、测试计划制定测试计划：测试人员根据开发计划，对测试具体测试时间，也就是开发功能完成后的时间，进行几轮测试等。然后，把项目的开发与测试计划提交到Teambiton进行任务管理。
5、编写测试用例：根据详细的需求文档，开始进行用例的编写。
6、用例评审：在用例进行评审之间，先以邮件形式将用例发送给相关人员，以便他们事先了解用例对哪些功能进行验证以及验证的细节。然后，测试人员组进行用例评审，开发人员对用例与实际功能不符合有哪些，产品人员对会通过用例对功能的具体实现进行把握等等。
7、提交代码：开发人员完成所有功能后，会对自己的功能进行一个自测。自测完成后提交测试人员进行测试。
8、具体测试流程：开发人员对于提测的功能进行测试，发现的问题通过缺陷管理工具进行反馈，开发人员对问题进行修复，然后，准备第二轮测试。测试人员完成第一轮测试后，需要写测试结论，发到相关人员。然后进行第二轮测试，并且对第一轮中发现的问题进行重点回归。
9、测试通过：经过两到三轮或四轮的测试后，直到没发现新的问题，或暂时无法解决，或不紧急的问题。通过上级确认，可以通过。编写测试报告与验收方案。
测试方法
1、冒烟测试：指在对一个新版本系统进行大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。引入到软件测试中，就是指测试小组在正规测试一个新版本之前，先投入较少的人力和时间验证一个软件的主要功能，如果主要功能都没有实现，则打回开发组重新开发。
2、功能测试：功能测试检查实际的功能是否符合用户的需求。测试的大部分工作也是围绕软件的功能进行，设计软件的目的也就是满足客户对其功能的需求。功能测试又可可以细分为很多种：界面测试、逻辑功能测试、易用性测试、安装测试、兼容性测试等。
3、回归测试：指修改了旧代码后，重新实行测试以确认修改后没有引入新的错误或导致其他代码产生错误。原有功能在新版本上进行回归测试，保证运行准确。
4、验收测试：验收测试是部署软件之前的最后一个测试操作。对产品功能、用户界面、性能、业务关联性的全局测试，确保产品达到产品经理的需求，没有阻碍产品使用的大bug。
5、升级测试：从历史版本升级到当前新版本的测试，确保升级后，软件可以正常使用，重点对升级后的新功能进行测试。
测试有哪些类别？
一、按测试阶段分
单元测试、集成测试(开发和测试员都可以做,接口测试划分在集成测试里面的)、系统测试(完整的、整体的一一个测试，不是安卓、苹果系统)、验收测试(正式验收测试、Alpha测试、 Beta测试游戏内测、预发布版本、公测)
二、按测试技术划分
白盒测试(代码级别)、黑盒测试(通过外部操作和表面反应来发现)、灰盒测试。
三、按测试包含的内容划分
功能测试(点点点)、界面测试(U界面)、安全测试、兼容性测试、易用性测试(否容易上手)、性能测试、力测试负载测试、恢复测试(灾备,自我修复)
四、其他测试
冒烟测试(版本发布之前主干测试,在真正测试之前)、回归测试 (验证测试修复好的BUG及其相关功能是否正常...怎样确定回归测试范围)、探索性测试 (测试思维)随机测试。
测试怎么做
最近，很多小伙伴正在面试新工作做准备。所以我整理一下软件测试的基本工作流程和一些测试用例编写方法。大致内容如下，希望这些内容对大家有帮助。
首先，作为测试人员需了解业务，分析需求点
为什么测试人员要参加需求分析？也就是进行测试需求分析的目的是什么？
第一、把用户需求转化为功能需求
1）对测试范围进度量
2）对处理分支进行度量
3）对需求业务的场景进行度量
4）明确其功能对应的输入、处理和输出
5）把隐式需求转变为明确
第二、明确测试活动的五个要素
测试需求是什么、决定怎么测试、明确测试时间、确定测试人员、确定测试环境、测试中需要的技能，工具以及相应的背景知识，测试过程中可能遇到的风险等等。测试需求需要做到尽可能的详细明确，以避免测试遗漏和误解。
那么，接下来怎么进行测试需求分析？
1）确认功能
（业务功能、辅助功能、数据约束、易用性需求、编辑约束、参数需求、权限需求、性能约束）
1、业务功能：与用户实际业务直接相关的功能或者细节；
2、辅助功能：辅助完成业务功能的一些功能或者细节，例如：设置过滤条件；
3、数据约束：功能的细节，主要是用于控制在执行功能时，数据的显示范围，数据之间的关系等；
4、易用性需求：功能的细节，产品中必须提供，便于功能操作使用的一些细节，例如：快捷键等；
5、编辑约束：功能的细节，在功能执行时，对输入数据项目的一些约束条件，例如：只能输入数字等；
6、参数需求：功能的细节，在功能执行时，需要根据参数设置不同，进行不同处理的细节；
7、权限需求：功能的细节，在功能执行的过程，根据不同的权限进行不同的处理，不包括直接限制某个功能的权限；
8、性能约束：功能的细节，执行功能时，必须满足的性能需求；
2）场景分析
1、考虑场景的调用者：考虑每一个场景提供的服务是供哪些外部模块或者系统调用的，找出所有调用者。调用前提，约束都要考虑。每一个调用都可以考虑成一个大的业务流程（一般和外部有交互的业务出错率比较大，需要重点关注）。
2、考虑系统内部各个场景之间的联系：形成内部业务流程，需要分析每个场景之间的约束关系，执行条件，组织出各种业务流程图。
3）挖掘隐性需求
这需要测试工程师的经验积累：
1）常用的或者规定的业务流程
2）各个业务流程分支的遍历
3）明确规定不可使用的业务流程
4）没有明确规定但是应该不可使用的业务流程
5）其他异常或者不符合规定的操作
接下来，一起说说测试用例设计那点事儿
1、如何进行测试用例的设计？
编写测试用例之前，我们需要对项目的需求有清晰的了解，对要测试什么，按照什么顺序测试，覆盖哪些需求做到心中有数，作为测试用例的编写者不仅了解要有常见的测试用例编写方法，同时需要了解被测软件的设计、功能规格说明、用户使用场景以及程序/模块的结构。
步骤
1）测试需求分析：从项目部拿到软件的需求规格说明书后，开始对项目的需求进行分析，通过自己的分析、理解，整理成为测试需求， 清楚分析出被测试对象具有哪些功能。明确测试用例中的测试集用例与需求的关系，即一个或多个测试用例集对应一个测试需求。
2）业务流程分析：分析完需求后，明确每一个功能的业务处理流程，不同的功能点做业务的组合，以及项目的隐式需求。如遇复杂的测试用例设计前，先画出软件的业务流程。从业务流程上，应得到以下信息：
A、主流程是什么?
B、条件备选流程是什么?
C、数据流向是什么?
D、关键的判断条件是什么?
3）测试用例设计：
完成以上两步则可进行测试用例设计，功能测试用例，应尽量考虑边界、异常、性能的情况，以便发现更多的隐藏问题。设计测试用例的常见方法：
等价类 → 边界值 → 因果图 → 判定表 → 状态迁移 → 正交实验 → 场景法 → 错误推断（注意：编写测试用例时，我们尽可能取的不应该是有效等价类而应该是无效等价类）
4）编写完成后自我检查以及部门内部评审：
①测试用例本身的描述是否清晰，语言准确；是否存在歧义性；
②测试用例内容是否完整，是否清晰的包含输入和预期输出的结果；测试步骤是否清晰；
③测试用例中使用的测试数据是否恰当，准确；
④测试用例是否具有指导性，是否能灵活的指导软件测试工程师通过测试用例发现更多的缺陷，而不是限制他们的思维；
⑤是否考虑到测试用例执行的效率。对于不断重复执行的步骤，是否保证了验证点相同；或者测试用例的设计是否存在冗余性等。这些都可能导致测试用例执行效率低下；
⑦画出软件需求跟踪矩阵，验证测试用例是否完全覆盖了需求，验证测试用例的覆盖性；
⑧测试用例是否完全遵守了软件需求的规定。这一点其实有一些难做到。考虑到时间/成本的关系，应该视具体情况而定。
5）测试用例更新完善：
测试用例编写完成之后需要不断完善，如遇需求更改或功能新增时，测试用例必须配套修改更新，同时在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善;在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善。
紧接着，测试用例执行的过程
首先搭建测试环境，准备好测试数据，进行预测，预测通过之后，按照测试用例进入正式测试，有效的测试执行可以将测试用例发挥最大的价值。因此，测试用例规范执行有助于更好的发现代码中存在的缺陷。根据个人测试工作经验，好的测试执行应该包含如下内容：
①测试执行中评估测试执行时间不足，需及时上报风险。满足质量优先，进度其次原则。
②测试用例按优先级顺序执行，通常是基本、详细和异常顺序执行。
③未执行用例、标志为删除或者无效的用例，需注明原因。
④执行过程中有疑问的测试用例（场景、操作步骤、检查点等）需找测试设计人员澄清。
⑤测试执行需对用例描述的检查点逐一检查，避免遗漏。
⑥重视不易重现的缺陷场景，可能是一个bug。
⑦执行过程中发现有前期设计遗漏用例需补充到用例文档并执行验证。
⑧建议测试人员交叉执行重复测试用例，用例执行对相同测试人员有免疫性。避免可能的缺陷一直遗漏到现在。如有需要，建议保留测试结果，结果可视。以便于不同版本间的测试结果对比。已确认问题需及时按照问题单提单要求（规范和缺陷定级）提单。
⑨跟踪问题单修复情况并回归验证问题单。每轮次测试结束，find一下是否有core文件产生。测试结束，将最终测试用例文档上传到归档目录，实现用例重用。
以上是针对一般的软件测试流程，如果是自动化测试的话，应该还有根据测试用例进行脚本编写，运行脚本等。此处可能写的不详细，希望大家可以在下方评论让我完善。
最后已达到准确要求的，根据测试情况写测试报告，对整个测试过程和版本的质量做一个评估。
测试报告是指把测试的过程和结果写成文档，对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。测试报告是测试阶段最后的文档产出物。优秀的测试经理或测试人员应该具备良好的文档编写能力，一份详细的测试报告包含足够的信息，包括产品质量和测试过程的评价，测试报告基于测试中的数据采集以及对最终的测试结果分析。
