软件测试的基本标准是啥?

Posted 2023-05-15

软件工程中软件测试的基本标准是什么?

1. 确认测试标准

实现软件确认要通过一系列墨盒测试。确认测试同样需要制订测试计划和过程，测试计划应规定测试的种类和测试进度，测试过程则定义一些特殊的测试用例，旨在说明软件与需求是否一致。

无论是计划还是过程，都应该着重考虑软件是否满足合同规定的所有功能和性能，文档资料是否完整、准确人机界面和其他方面。

确认测试的结果有两种可能，一种是功能和性能指标满足软件需求说明的要求，用户可以接受；另一种是软件不满足软件需求说明的要求，用户无法接受。项目进行到这个阶段才发现严重错误和偏差一般很难在预定的工期内改正，因此必须与用户协商，寻求一个妥善解决问题的方法。

2. 配置复审

确认测试的另一个重要环节是配置复审。复审的目的在于保证软件配置齐全、分类有序，并且包括软件维护所必须的细节。

3. α、β测试

事实上，软件开发人员不可能完全预见用户实际使用程序的情况。例如，用户可能错误的理解命令，或提供一些奇怪的数据组合，亦可能对设计者自认明了的输出信息迷惑不解，等等。因此，软件是否真正满足最终用户的要求，应由用户进行一系列验收测试。

验收测试既可以是非正式的测试，也可以有计划、有系统的测试。有时，验收测试长达数周甚至数月，不断暴露错误，导致开发延期。一个软件产品，可能拥有众多用户，不可能由每个用户验收，此时多采用称为α、β测试的过程，以期发现那些似乎只有最终用户才能发现的问题。

扩展资料：

软件测试的流程：

1、测试需求分析阶段：阅读需求，理解需求，主要就是对业务的学习，分析需求点，参与需求评审会议。

2、测试计划阶段：主要任务就是编写测试计划，参考软件需求规格说明书，项目总体计划，内容包括测试范围（来自需求文档），进度安排，人力物力的分配，整体测试策略的制定。风险评估与规避措施有一个制定。

3、测试设计阶段：主要是编写测试用例，会参考需求文档（原型图），概要设计，详细设计等文档，用例编写完成之后会进行评审。

4、测试执行阶段：搭建环境，执行冒烟测试（预测试）-然后进入正式测试，bug管理直到测试结束。

5、测试评估阶段：出测试报告，确认是否可以上线。

参考资料来源：百度百科-软件测试方法

参考技术A 1)所有的测试都应追溯到用户需求。

　　软件测试的目标在于揭示错误。从用户角度来看，最严重的错误是那些导致程序无法满足需求的错误。

　　(2)应当把“尽早地和不断地进行软件测试”作为软件测试者的座右铭。

　　应该在测试工作真正开始前的较长时间内就进行测试计划。测试计划可以在需求模型一完成就开始，详细的测试用例定义可以在设计模型被确定后立即开始。因此，所有测试应该在任何代码被产生前就进行计划和设计。

　　(3)pareto原则：测试发现的错误中80%很可能起源于20%的模块中。

　　当某个功能出问题，其对用户的影响有多大?然后根据风险大小确定测试的优先级。优先级高的测试，优先得到执行，一般来讲，针对用户最常用的20%功能(优先级高)的测试会得到完全执行，而低优先级的测试(另外用户不经常用的80%功能)就不是必要的，如果时间或经费不够，就暂时不做或少做。

　　(4)完全测试是不可能的，测试需要终止。

　　测试无法显示软件潜在的缺陷，“测试只能证明软件存在错误而不能证明软件没有错误”。最初的测试通常把焦点放在单个程序模块上，进一步测试的焦点则转向在集成的模块簇中寻找错误，最后在整个系统中寻找错误。在测试中不可能运行路径的每一种组合。然而，充分覆盖程序逻辑，并确保程序设计中使用的所有条件是有可能的。

　　(5)应由独立的第三方来构造测试。

　　第三方测试最大的特点在于它的专业性、独立性、客观性和公正性。对于软件开发商来说，经过第三方测试机构的测试，不仅可以通过专业化的测试手段发现软件错误，帮助开发商提升软件的品质，而且可以对软件有一个客观、科学的评价，有助于开发商认清自己产品的定位。对于行业主管部门以及软件使用者来说，由于第三方测试机构独立公正的地位，可以对被测试的软件有一个客观公正的评价，帮助用户选择合适、优秀的软件产品。

　　(6)充分注意测试中的群集现象。

　　测试后程序残存的错误数目与该程序中已发现的错误数目或检错率成正比。不要在某个程序段中找到几个错误就误认为该程序段就没有错误而不再测试，相反应该对错误群集的程序段进行重点测试。

　　(7)尽量避免测试的随意性。

　　测试计划应包括：所测软件的功能，输入和输出，测试内容，各项测试的进度安排，资源要求，测试资料，测试工具，测试用例的选择，测试的控制方法和过程，系统的配置方式，跟踪规则，调试规则，以及回归测试的规定等以及评价标准。

　　(8)兼顾合理的输入和不合理的输入数据。

　　(9)程序修改后要回归测试

　　修改程序后，应该重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。

　　(10)应长期保留测试用例，直至系统废弃。

　　妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护等提供方便。

百度文库里也有本回答被提问者采纳 参考技术B 通过集成测试之后，软件已完全组装起来，接口方面的错误也已排除，确认测试即可开始。确认测试应检查软件能否按合同要求进行工作，即是否满足软件需求说明书中的确认标准。
1.
确认测试标准
实现软件确认要通过一系列墨盒测试。确认测试同样需要制订测试计划和过程，测试计划应规定测试的种类和测试进度，测试过程则定义一些特殊的测试用例，旨在说明软件与需求是否一致。无是计划还是过程，都应该着重考虑软件是否满足合同规定的所有功能和性能，文档资料是否完整、准确人机界面和其他方面（例如，可移植性、兼容性、错误恢复能力和可维护性等）是否令用户满意。
确认测试的结果有两种可能，一种是功能和性能指标满足软件需求说明的要求，用户可以接受；另一种是软件不满足软件需求说明的要求，用户无法接受。项目进行到这个阶段才发现严重错误和偏差一般很难在预定的工期内改正，因此必须与用户协商，寻求一个妥善解决问题的方法。
2.
配置复审
确认测试的另一个重要环节是配置复审。复审的目的在于保证软件配置齐全、分类有序，并且包括软件维护所必须的细节。
3.
α、β测试
事实上，软件开发人员不可能完全预见用户实际使用程序的情况。例如，用户可能错误的理解命令，或提供一些奇怪的数据组合，亦可能对设计者自认明了的输出信息迷惑不解，等等。因此，软件是否真正满足最终用户的要求，应由用户进行一系列验收测试。验收测试既可以是非正式的测试，也可以有计划、有系统的测试。有时，验收测试长达数周甚至数月，不断暴露错误，导致开发延期。一个软件产品，可能拥有众多用户，不可能由每个用户验收，此时多采用称为α、β测试的过程，以期发现那些似乎只有最终用户才能发现的问题。
α测试是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的用户操作方式。经过α测试调整的软件产品称为β版本。紧随其后的β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。 参考技术C 实现软件确认要通过一系列墨盒测试。确认测试同样需要制订测试计划和过程，测试计划应规定测试的种类和测试进度，测试过程则定义一些特殊的测试用例，旨在说明软件与需求是否一致。无是计划还是过程，都应该着重考虑软件是否满足合同规定的所有功能和性能，文档资料是否完整、准确人机界面和其他方面（是否令用户满意。
确认测试的结果有两种可能，一种是功能和性能指标满足软件需求说明的要求，用户可以接受；另一种是软件不满足软件需求说明的要求，用户无法接受。项目进行到这个阶段才发现严重错误和偏差一般很难在预定的工期内改正，因此必须与用户协商，寻求一个妥善解决问题的方法。 参考技术D 首先要满足用户功能需求。
其次要使用方便、人性化，性能稳定，兼容性好，抗压性强。
还要界面友好。

相对于标准代码测试 simd 加速的正确方法是啥

【中文标题】相对于标准代码测试 simd 加速的正确方法是啥

【英文标题】：What's the proper way of testing simd speedup relative to standard code相对于标准代码测试 simd 加速的正确方法是什么

【发布时间】：2017-11-11 03:28:09

【问题描述】：

我正在学习如何使用 C 语言使用 SIMD 指令，并且我想比较使用 SIMD 的代码和不使用 SIMD 的代码。有没有人有一个测试模板可以准确识别 SIMD 代码与标准代码的预期加速？

具体来说，我注意到以下在特定配置下的大致性能时间：

SIMD first, single run:
SIMD: 0.15 s
standard: 0.35 s

SIMD first, standard second, repeated 10x:
SIMD: 0.15 s - first run, 0.05 s on subsequent runs
standard: 0.35 s - first run, 0.34 on subsequent runs

standard first, SIMD second, repeated 10x:
standard: 0.45 s - first run, 0.35 s on subsequent runs
SIMD: 0.05 s - first run, 0.05 s on subsequent runs

代码示例正在运行 uint16_t 类型的 1e8 值的数据集。数据分配和初始化在循环之外。如果我在重复循环内分配数据，则循环都具有相同的时间。如果我在 SIMD 和标准部分之前执行此操作，而不是在先到者之前执行此操作，则两者的时间都会更长：

standard: 0.45 s
SIMD: 0.15 s

那么为什么数据分配会导致这样的时间差异呢？什么是真正的加速？

代码链接： https://gist.github.com/JimHokanson/55ce2e5cac75d7df6dc24dadf383e68f

我正在使用 m3 处理器的 2016 年初 Macbook 上进行测试...

【问题讨论】：

所以，我的大部分问题都与使用 calloc 有关！我不确定来源，但我很确定我在某处看到操作系统可以用 calloc 做一些非常奇特的事情。如果我运行循环并将所有值分配给 0，则标准方法的时间差将回到 0.35 秒，而 SIMD 方法的时间差会回到 0.05 秒。我认为这代表了我的数组已初始化的真实世界用例（完全，即显式设置的每个值）。

更新： malloc 也会出现这种情况。那么这是操作系统的问题还是处理器的一些奇怪的缓存效果？

没有看到你是如何测试的，我只能猜测，但听起来你正在测试你的分配代码以及你试图加速的任何操作。也有可能即使您没有，您分配的内存也没有被触及，因此访问它会导致页面错误，因为它被交换或映射。最好包含您的实际测试代码以获得真正的答案。

我在网上发布了一个要点。我将内存分配增加得更高（1e9 个样本），并且保持相同的趋势。

如果 malloc 或 calloc 并且只读取它，则所有页面都可以写入时复制映射到相同的物理零页面，因此您可以获得 L1D 缓存命中。您的问题对您的访问模式不是很清楚。或者关于您正在测试的硬件。

【参考方案1】：

因此，问题似乎只是未能按预期实际初始化内存。我曾认为它可能是特定于 SIMD 测试的东西，而不仅仅是一般的 C。

因此，正确初始化内存的正确方法如下：

data = malloc(1e8);
//- Do a loop to initialize data (previously memset to 0 but it was suggested that this may be optimized away)
//- Do SIMD comparison vs standard approach - loop and average results

优化设置：此外，在尝试与标准库汇编代码竞争时，请记住启用优化！看： why is strchr twice as fast as my simd code 基本要点是我将 SIMD 与标准库代码进行了比较，并具有非常优化的程序集。不优化 SIMD 代码太慢，但优化后结果更合理。

过度优化：有时编译器会在一种情况下优化掉代码，而不是在另一种情况下。例如我有以下代码：

for (size_t n2 = 0; n2 < n_loops_inner; n2++)
   str2 = memchr(str,'b',N);
   char_index2 = str2 - str;

但是，这段代码执行得太快了。我在循环内搜索之前添加了以下行。

  str[(size_t)char_position] = 'b';

此外，我还将 char_index2 标记为 volatile。这些更改共同提供了更合理的执行时间。 （即比没有这些更改时慢 1000 倍）

【讨论】：

gcc 会将malloc + memset(0) 优化为calloc。如果你正在做整数的东西，memset 用非零的东西。