软件检测工作基本步骤

最近在为面试新工作做打算，所以想想整理一下软件检测的基本工作步骤，大致梳理一遍，这样也便于自己在面试过程中可以沉着的应对面试官的测试工作怎么进行的难题。

为什么测试人员要参与意愿分析？也就是进行检测需求预测的目的是哪个？

第一、把客户需求转换为功能需求：1）对检测范围进度量2）对处理分支进行度量3）对意愿业务的场景进行度量4）明确其用途对应的输入、处理和输出5）把隐式需求转变为确立。

第二、明确测试活动的五个要素：测试需求是哪个、决定如何测试、明确检测时间、确定测试人员、确定检测环境：测试中应该的技能，工具或者相应的背景常识，测试过程中也许遭遇的风险之类。测试需求必须做到尽可能的具体细化，以防止检测遗漏和误解。

怎么进行测试需求预测？

第一、确认功能（业务用途、辅助功能、数据约束、易用性需求、编辑约束、参数需求、权限需求、性能约束）：

1、业务用途：与客户实际业务直接相关的用途以及细节

2、辅助功能：辅助完成业务用途的一些功用以及细节，例如：设置过滤条件

3、数据约束：功能的细节，主要是用于控制在执行功能时，数据的显示范围，数据之间的关系等

4、易用性需求：功能的细节，产品中需要提供，便于功能操作使用的一些细节，例如：快捷键等

5、编辑约束：功能的细节，在功能执行时，对输入数据项目的一些约束条件，例如：只能输入数字等

6、参数需求：功能的细节，在功能执行时，需要按照参数设定不同，进行不同处理的细节

7、权限需求：功能的细节，在功能执行的过程，根据不同的权限进行不同的处理，不包含直接限制某个用途的权限

8、性能约束：功能的细节，执行功能时，必须满足的性能需求

第二、场景分析

1、考虑场景的调用者：考虑每一个场景提供的服务是供那些内部组件以及平台读取的，找出所有调用者。调用前提，约束都要考量。每一个调用都可以考量成一个大的业务流程（一般和内部有交互的业务出错率比较大，需要重点关注）

2考虑平台外部各个场景之间的：形成外部业务流程，需要探讨每个画面之间的约束关系，执行条件，组织出各类业务流程图

第三、挖掘隐性需求

这应该测试工程师的心得积累：1）常用的以及要求的业务流程2）各个业务流程分支的遍历3）明确要求不可使用的业务流程4）没有明确要求之后需要不可使用的业务流程5）其他异常以及不符合规定的操作

以上是仔细的讲解了怎样进行检测需求预测，详细的检测需求方式可以参考《软件检测需求预测方式》这篇博客。在需求预测过程中编写整个测试计划，在这个过程中应该参考需求规格说明书，这个阶段通常状况下是检测主管编写的。包括检测人员，测试时间，测试软件，以及检测手段等。这是在测试需求预测中的产物《测试计划》，如何编写测试计划，请参考下面文章《如何编写一个好的测试计划》。

测试用例是测试工作的最核心的组件，在执行任何检测之前，首先需要完成检测用例的撰写。测试用例是指导你执行检测，帮助证明硬件功能或看到工具缺陷的一种说明。用例设计好后进行审核。这个地方该讲的东西就多了，如何设计测试用例，设计测试用的方式，怎么进行检测用例的审核等等。

第一、如何进行检测用例的设计

编写测试用例之前我们应该对项目的意愿有清晰的知道，对要测试哪些，按照哪个顺序检测，覆盖这些需求做到心中有数，作为检测用例的编写者不仅知道要有常用的检测用例编写方式，同时还要知道被测工具的设计、功能型号说明、用户试用场景或者程序/模块的结构。

步骤：

1、测试需求预测：从项目部拿到工具的需求规格说明书后，开始对项目的意愿进行探讨，通过自己的剖析、理解，整理作为检测需求， 清楚分析出被检测对象具备什么用途。 明确检测用例中的测试集用例与需求的关系，即一个或多个测试用例集对应一个测试需求。

2、业务流程分析：分析完需求后，明确每一个功能的业务处理步骤，不同的用途点作业务的组合，以及项目的隐式需求。如遇复杂的测试用例设计前，先画出硬件的业务流程。从业务流程上，应得到下面信息：

A、 主流程是哪些?

B、 条件备选流程是哪个?

C、 数据流向是哪个?

D、 关键的判定条件是哪个?

3、测试用例设计

完成以下两步则可进行检测用例设计，功能测试用例，应务必考虑边界、异常、性能的状况，以便看到更多的隐藏问题。设计检测用例的常用方式：1）等价类2）边界值3）因果图4) 判定表5)数据迁移6) 正交实验7) 场景法8) 错误判断（注意：编写测试用例时，我们尽可能取的不需要是有效等价类而必须是无效等价类）

4.编写完成后自我检测或者部门内部评审：

1）测试用例本身的表述是否清晰，语言具体；是否存在二义性；

2）测试用例内容能否完整，是否清晰的包括输入和预期输出的结果；测试方法能否清晰；

3）测试用例中使用的检测数据能否正确，准确；

4）测试用例是否具备指导性，是否能灵活的指导工具检测工程师通过测验用例发现更多的弊端，而不是限制它们的认知；

5）是否考虑到测试用例执行的强度。对于不断重复执行的流程，是否保证了验证点相似；或者检测用例的设计能否存在冗余性等。这些都或许促使测试用例执行效率低下；

6）画出硬件需求跟踪矩阵，验证检测用例是否完全覆盖了需求，验证检测用例的覆盖性；

7）测试用例是否完全遵循了硬件需求的要求。这一点其实有一些难做到。考虑到时间/成本的关系，应该视具体状况而定。

具体详尽内容可参考《如何有效的进行检测用例评审》

5.测试用例更新完善

测试用例编写完成以后还要不断完善，如遇需求设置或用途新增时，测试用例需要配套设置升级，同时在检测过程中看到设计测试用例时考量不周，需要对检测用例进行设置规范;在硬件交付使用后用户反馈的硬件缺陷，而弊端又是因测试用例存在漏洞导致，也应该对检测用例进行规范。

首先搭建测试环境，准备好检测数据，进行分析，预测通过以后，按照检测用例进入正式测试，有效的检测执行可以将测试用例发挥最大的价值。因此，测试用例规范执行有助于更好的看到代码中存在的弊端。根据个人测试工作经验，好的测试执行需要包括如下内容：

1、测试执行中检测测试执行时间不足测量工作的基本程序，需尽快上报风险。满足品质优先，进度其次方法。

2、测试用例按优先级顺序执行，通常是基本、详细和异常顺序执行。

3、未执行用例、标志为删除以及无效的用例，需注明理由。

4、执行过程中有疑问的检测用例（场景、操作方法、检查点等）需找检测设计人员澄清。

5、测试执行需对用例描述的检测点逐一检查，避免遗漏。

6、重视不易重现的弊端场景，可能是一个bug。

7、执行过程中看到有后期设计遗漏用例需补充到用例文档并执行验证。

8、建议检测人员交叉执行重复测试用例，用例执行对同样检测人员有免疫性。避免可能的弊端仍然遗漏到现网。

9、如有需要，建议保留测试结果，结果可视。也方便不同版本间的测试结果对比。

10、已确定问题需立即根据问题单提单要求（规范和缺陷定级）提单。

11、跟踪问题单恢复状况并重回验证问题单。

12、每轮次测试结束，find一下是否有core文件产生。

13、测试结束，将最后检测用例文档上传到归档目录，实现用例重用。

以上是对于通常的硬件检测步骤测量工作的基本程序，如果是自动化测试的话，应该也有按照检测用例进行脚本编写，运行脚本等。此处可能写的不具体，希望你们可以再下方评论让我完善。

在测试用例执行过程中，包含了：功能测试阶段、缺陷追踪阶段（bug tracking）、回归测试阶段、系统检测阶段、验收测试阶段等（系统已满足检测条件（开发完成），按照尚未评定过的检测用例依次执行，执行过程中迅速记录问题，将难题尽快提交到QC上，要跟踪缺陷。等研发修复后进行回归测试，确认清除后关闭缺陷，如果说该疑问要升级而制造上未进行验证，就把缺陷状况改为生产未验证。对有异议的缺陷经甲方、开发和检测三方进行沟通探讨，由甲方最终确认处理方法。在检测过程中也会遇到对意愿有异议，会反馈给主管，由总监与甲方沟通来对该需求提出一些可行性建议，最终还是由甲方来确认准确依据各个公司的业务流程而不一样）。

测试报告是指把测试的过程和结果写出文档，对看到的弊端和缺憾进行探讨，为纠正软件的存在的品质难题提供根据，同时为工具验收和投产打下基础。测试报告是检测阶段最终的文档产出物。优秀的检测经理或测试员工必须具有良好的文档撰写能力，一份详细的检测报告涵盖足够的信息，包括产品品质和检测过程的评判，测试报告基于测试中的数据收集或者对最后的检测结果预测。

测试报告的内容可以总结为下面目录：

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/shumachanpin/article-121591-1.html