关于软件测试:一次软件的可靠性测试实践

4次阅读

共计 3169 个字符，预计需要花费 8 分钟才能阅读完成。

作者：孙敬云

可靠性测试是一种非功能测试，它能够发现那些暗藏在软件内，会导致软件能力降落的缺点。在修复这些缺点之后，咱们能够让目标软件在长时间运行的状态下，仍然能够解决等量的数据。

因而为了保障公司内各个我的项目的可靠性程度，咱们便引入了可靠性测试。

咱们对第一阶段的可靠性测试定义了这样一个指标：在特定的环境和较长的工夫范畴内测试一下 ”X” 的维持能力。咱们要重点关注的是 ”X 是否足够稳固（业务解决能力的稳定值）”、“X 是否存在内存泄露问题 ”、”X 的索引成果是否显著 ” 等。

基于咱们要达成的指标，具体的落地计划是这样的：

Conainer: *是咱们本轮测试中波及到的所有服务实例，其中 X-Service1，X-Service2 和X-Service3是指标零碎 X 的三个外围模块，咱们须要独自运行它们。

这里须要非凡阐明的是：首先，可靠性测试计划是基于咱们的「集成测试计划」实现的；其次，测试什么样的场景和测试过程自身是离开的。因而对于「可靠性测试计划」的外围性能来说，它既不须要关怀如何构建测试环境，也不须要关怀具体要执行什么样的测试用例，它的外围就是要监测咱们在反复模仿客户应用场景的过程中，各个相干服务实例的理论状态。

集成测试计划：「跨团队我的项目的集成测试实际分享」

咱们将上述外围拆分为四个局部：用例执行器、状态管理器、报告生成器和告诉模块。

用例执行器的定位很简略，就是反复的执行指定的”测试用例“。在每次执行”测试用例“时，用例执行器都会对外推送相干事件，这里最重要的就是”实现“事件。

订阅者能够在”实现“事件中获悉单次执行的后果，比方执行了多少，失败了多少等等。

顾名思义，状态管理器治理着所有服务的状态，通过它能够不便的获取到每个服务的最新状态。当然它也记录着用例执行器推送的数据，例如用例执行总数、失败总数、最近一个周期用例执行数和最近一个周期失败数等形容业务能力的数据。

报告生成器的职责有两个：一是定义报告的数据格式；二是生成对应格局的报告。生成报告所需的数据基本上都能在状态管理器中拿到，如果咱们须要展现更多的数据，这就须要对状态管理器进行扩大或者引入更多的”插件“；同样的如果须要更多样的展现，也能够对报告生成器进行扩大，默认生成的报告是这样样子的：

”列“里定义了所有相干服务实例的 CPU、Memory、Network 和 Disk 信息，”行“里则每隔一段时间就采集一次相干的数据。

告诉模块也有两个职责，立刻告诉和定时告诉。然而通常状况下，咱们只会用到定时告诉，比方每隔 10 分钟向指定地址发送一次最新的报告。

主程序
有了这四局部，可靠性测试的外围也就实现了。咱们再为它们包装一个”主程序“，”主程序“的职责是将这四局部串联在一起，这样应用起来就更容易一些，比方将入口定义为这样：

 await DurabilityPlatform.run(projectName, {
 "mongodb": MongoDBDockerExecutor,
 "redis": RedisDockerExecutor,
 "elasticsearch": ElasticsearchDockerExecutor,
 "service-Y": ServiceYDockerExecutor,
 "service-X1": ServiceX1DockerExecutor,
 "service-X2": ServiceX2DockerExecutor,
 "service-X3": ServiceX3DockerExecutor
 }, {
 duration: 1 * 3600 * 24 * 1000, // 继续测试 1 天
 interval: 10 * 60 * 1000, // 每 10 分钟采集一次最新状态
 incomingWebhook: "https://hook.worktile.com/incoming/xxxxx", // 定时告诉的地址
 specsPath: path.join(__dirname, "specs"), // 测试用例所在的文件夹
 onStart: async () => {// 向 PingCode 中创立一个测试计划},
 onEnd: async (reportURL: string) => {// 更新 PingCode 测试计划的状态}
    });

技术计划确定之后，下一步就是回归指标自身：在特定的环境和较长的工夫范畴内测试一下 ”X” 的维持能力。咱们须要确定一些用户的应用场景，而后通过测试用例的形式模仿这些场景。

例如用户能够在”X“零碎中创立资源、更新资源和获取资源。那么咱们就把这个过程模仿进去。在用例执行器指定的用例文件夹下创立一个新的测试文件：

describe("Simulate user scenarios: Create, Edit and Get", () => {it("Create a resource;expect-ok", async () => {});
 it("Edit a resource;expect-ok", async () => {});
 it("Get a resource;expect-ok", async () => {});
})；

可靠性测试框架会重复的运行这几个测试用例。随着工夫的推移，同样的几个测试用例，它的运行效率可能会降落，咱们就是要通过场景的模仿来察看到数据的变动。

比方咱们运行了一段时间之后，能够察看一下业务吞吐的趋势，是放弃住还是继续降落？是缓降还是指数降？有没有忽然的断崖式降落？

总之，写的测试用例肯定要笼罩次要的业务点，这样能力更全面的发现问题。

在可靠性测试中，写框架、写测试是一部分，数据的解析是另一部分。比方咱们看上面一部分数据：

从上图可知，在同样的工夫周期内，同一份用例的执行效率在随工夫降落。咱们将它转化为报表：

这阐明 X 零碎的业务吞吐能力会随着工夫的推移逐步降落，而且在运行很少的工夫后就会呈现这个问题。那咱们须要再深入研究一下：

咱们发现 Service- Y 的 CPU 始终处于高位，内存也有迟缓上涨的趋势，这会是根本原因吗？咱们还须要再深入研究……导致 Service- Y 体现异样的起因是什么并不重要，重要的是：报告解析的过程，就是一个察看数据 -> 大胆猜测 -> 更多数据 -> 猜测验证的过程，它须要教训撑持，然而也离不开数据的反对。

结尾
咱们须要晓得，可靠性测试中的数据指标并不是固定的，在本文中选取了 ” 理论运行用例数 ”、”理论失败用例数“、”每 10 分钟运行用例数“、”每 10 分钟失败用例数“、”各个服务 CPU 使用率“、”各个服务内存使用量“、”各个服务硬盘使用量“和”各个服务 IO 使用量“，只是为了达到咱们定义的指标。对于更多的场景，咱们须要依据理论状况再采集相干数据，本文旨在分享教训，而不是在定义什么。

非功能测试的实质还是要通过适当的主观数据来反映服务的状态，这须要咱们有不断改进的态度，而不是一劳永逸的构想。好了，本期内容就是这些。

PingCode 官网

对于 PingCode

PingCode 是由国内老牌 SaaS 厂商 Worktile 打造的智能化研发管理工具，围绕企业研发治理需要推出了 Agile（麻利开发）、Testhub（测试治理）、Wiki（知识库）、Plan（我的项目集）、Goals（指标治理）、Flow（自动化治理）、Access（目录治理）七大子产品以及利用市场，实现了对我的项目、工作、需要、缺点、迭代布局、测试、指标治理等研发治理全流程的笼罩以及代码托管工具、CI/CD 流水线、自动化测试等泛滥支流开发工具的买通。

自正式公布以来，以酷狗音乐、商汤科技、电银信息、51 社保、万国数据、金鹰卡通、用友、国汽智控、智齿客服、易快报等知名企业为代表，曾经有超过 13 个行业的泛滥企业抉择 PingCode 落地研发治理。

正文完