软件检测工作的基本步骤

最近正在为面试新工作做打算，大概梳理工具检测的基本步骤，以便自己在面谈时沉着应对面试官提问软件检测工作是怎样进行的。

首先成为测试员工必须学习并知道业务流程，分析需求点

为啥要举行需求评审大会啦，这也就是这也就是进行探讨需求的目的是哪个？

（一），把客户需求转化为功能需求（1）对检测范围进行度量（2）对处理分支进行度量（3）对需求的业务场景进行度量（4）明确对应功能的输入，处理和输出（5）把隐形需求转化明确。

（二），明确测试活动的五个元素，测试需求是哪个，怎么测试，明确检测时间，确定测试人员，确定检测环境-

测试中应该什么技能，工具和相应的背景常识。测试项目中碰到的风险之类。

测试需求尽可能的做到具体，明确，已导致测试过程中发生的遗漏。

（三）怎么进行测试需求分析

（1,）确认功能（业务用途，辅助功能，数据约束，易用性需求，编辑约束，参数需求，权限需求，性能需求）

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-121589-1.html