软件测试基本理论

原创已于 2024-09-18 14:21:16 修改 · 1.2k 阅读

30 ·

CC 4.0 BY-SA版权

文章标签：

#功能测试 #测试工具

于 2024-09-18 10:58:58 首次发布

软件测试专栏收录该内容

1 篇文章

订阅专栏

一、什么是软件测试？

软件测试（英语：Software Testing），是使用人工操作（手动测试）或者软件自动运行的方式（自动化测试）来检验软件是否满足用户需求的过程。

软件测试的目的‌是确保软件的质量，确认软件以正确的方式做了你所期望的事情。其主要目的是发现软件的错误、有效定义和实现软件成分由低层到高层的组装过程、验证软件是否满足任务书和系统定义文档所规定的技术要求，并为软件质量模型的建立提供依据。

‌软件测试的方法‌包括‌黑盒测试和‌白盒测试。黑盒测试通过数据输入观察数据输出，检查软件内部功能是否正常；白盒测试根据软件内部应用、源代码等对产品内部工作过程进行调试，常与黑盒测试结合使用。

‌软件测试的复杂性和经济性‌体现在其涉及多个方面，包括但不限于需求分析、设计、编码、集成和部署等阶段。此外，软件测试需要投入大量的人力、物力和时间，以确保软件的正确性和稳定性。

二、软件测试基本理论

软件测试的工作一般是由测试工程师进行，一般在工作中主要是负责做各种方面的测试，如功能测试、性能测试、安全性测试、兼容性测试、UI测试、接口测试等。

1、软件测试的基本流程

软件测试的基本流程大致分为以下情况，不同公司有不同差异。

产品经理或者项目经理给到需求

👇

开发以及测试人员对需求文档进行分析总结，并记录疑问的地方

👇

随后进行开会讨论解答需求上的疑惑以及指出不足，并讨论时间计划安排制定初步计划

👇

制定完计划如测试计划之后运用各种方法进行测试用例设计

👇

每个测试完成自己任务的测试用例设计之后进行初步的测试用例评审，如组内讨论或者给产品经理或者项目经理评审，全部组员完成测试用例设计后拉上开发和所有测试以及产品进行测试用例评审会议进行查漏补缺，以核对与开发理解的需求是否一致并进行完善

👇

测试人员把所有测试用例进行标注排优先级，将优先级最高的主流程的用例（Level1）进行关联，由开发人员自测或者测试人员进行冒烟测试跑主流程

👇

测试通过后进行提测，将之前的测试用例进行逐条测试

👇

将测试中发现的BUG进行追踪，进行多轮的Bugfix版本以验证Bug是否修复

👇

最后进行一到两轮全面的回归测试，以防止修复旧的bug而产生新的Bug

👇

总结测试报告

2、测试计划大致分为哪些内容

①项目概述：包含项目概述、项目简介、测试范围、测试目标等。

②测试资源：包含人力资源、物力资源等。

③测试安排：包含阶段划分、时间安排、人员安排、进度安排等。

④测试策略：包含测试类型、测试方法、测试环境等。

⑤测试风险以及应对措施：包含风险识别、风险评估、应对措施等。

⑥测试输出：包含测试用例、缺陷管理、总结报告、测试文档等。

3、测试方法

测试的方法有很多，大致分为测试方法和测试用例的方法

测试方法有很多，如：单元测试、系统测试、集成测试、冒烟测试等。

功能测试、性能测试、安全测试、兼容测试、UI测试、弱网测试、稳定性测试、负载测试、压力测试等。

白盒测试、灰盒测试、黑盒测试。

测试用例的方法有很多，如白盒测试中的：代码审查、逻辑覆盖、语句覆盖、判定覆盖等。

黑盒测试中的：等价类、边界值、错误推导法、因果法、判定法等。

4、如何设计完善的测试用例

①首先设计完善的测试用例就需要有一个规范的流程制度，在流程制度之下，作为测试工程师首要的就是需要充分的了解需求文档中的内容以及判断不足及时提出。

②其次需要结合多种测试方法以及测试用例方法进行测试用例的设计，从多方面去考虑，如功能、性能、兼容、UI、安全等方面，还需要站在用户使用者的角度去考虑。

③进行多轮的测试用例评审会议进行查漏补缺，因为一个人的思维肯定是不够完善的，考虑的不够全面，需要和其他组员一起去完善测试用例的设计。

④编写测试用例时可以先用XMind去拟出大致思维框架，个人比较推荐最后转化用Excel去详细编写测试用例，一个好的测试用例基本包含：用例编号、所属产品、所属模块、相关联需求、用例标题、步骤、前置条件、优先级、用例类型、用例状态、期待结果、实际结果、由谁创建、创建日期、相关联版本号、附件等。

5、管理测试用例以及Bug的工具有哪些

管理测试用例以及Bug的工具有很多，常见的有禅道、JIRA、Tapd等，既可以对测试用例进行上传以及建立测试单关联测试用例等，也可以对Bug进行追踪和管理。能非常高效的推动测试的进程以及项目组工作上的协调。

6、如何提一个质量高的Bug

在开发转测之后，通常就轮到测试工程师负责对这个版本进行测试了，在对之前编写的测试用例进行逐条测试之后，一般会发现很多个Bug，那么对于这些失败的测试用例我们通常都同样将其执行转为Bug，以便我们进行追踪管理，并且在如上Bug管理平台中能方便我们在下一个版本测试中进行追踪和修复。

一个好的Bug描述通常包含：标题、操作步骤、测试结果、期望结果、附件、所属产品、所属项目、所属版本、所属模块、所属需求、Bug类型、严重程度、优先级、指派人、截止日期、反馈者、出现Bug平台、抄送人等。

Bug的生命周期一般包括：

发现Bug👉确认Bug👉提出Bug👉分配Bug👉修复Bug👉验证Bug👉关闭Bug

通常如果Bug尚未得到修复，是一个影响其余测试用例执行的Bug，那么在这个Bug下的其余测试用例一般也会在该测试版本都转为Bug并且设置为“阻塞”状态，以告组内其他成员情况。测试人员在等开发修复完Bug后，等待下一个版本转测或者直接更新测试环境进行验证。随后在确认完毕已经修复完毕Bug且没有产生新的Bug之后，会对Bug进行关闭。