软件测试中未解决的问题或挑战[关闭]

#1 楼

在持续部署的世界中，测试自动化已成为最重要的测试形式。

测试自动化的最大问题是工程师如何知道他们已涵盖所有重要的执行路径。存在代码覆盖率，但是只是找到未经测试的代码，这不是质量目标。

如果将代码覆盖率与突变测试结合使用，效果会更好，但是对于大型代码库，突变测试仍然太慢。同时处理结果还需要人工研究。由于这些原因，它不能连续地重复。 />对我来说，最大的挑战是工程师如何知道自己编写了足够的测试，同时又在测试和编码之间花费了时间。缺少一个好的标准，目前对于复杂的系统，大多数好的技术正在减慢或变得复杂。提出一种可（相对）快速自动化的流程，显着降低缺陷风险，并且该流程可重复，这对我们行业来说似乎是一个巨大的胜利。人们已经有很长时间没有测试软件了吗？可以，但是良好的测试过程很慢。未来需要快速而愤怒的事物。测试自动化会有所帮助，但是仍然很难知道是否涵盖了所有内容。这里的一些帮助将是非常有用的。设计可测试和可维护的软件几乎是一种艺术形式。
没有教导工程师像干净代码这样的质量原则。

我了解学校会努力为学生提供广泛的知识，但是编写高质量的代码应该是从您开始的头几周开始的标准。这样您就可以在实际作业中反复练习。例如，单元测试不能用几个类来解释基础知识。您需要对推理以及如何构造代码有很好的了解。然后，您还需要大量练习和一个更大的项目，以使您知道测试自动化值得您花时间。

也许是一种新的编程范例，其中将代码质量和可测试性作为主要重点。

#2 楼

尝试解决自动化的可用性测试可能对您很有趣。这将包括508测试和颜色识别，以及试图识别令人讨厌的事物，例如必须为某些事物单击3次等等。正在测试的问题，并且机器无法测试此问题。

#3 楼

分布式测试是我们仍处于开放阶段的东西。云计算使创新成为可能：您可以使用不同的系统配置启动虚拟集群，使用SDN创建网络，甚至注入故障。同时，它们使您的生活变得更加艰辛，因为您进入测试运行失败的虚拟机的时间已经被回收，而您所拥有的只是在十台机器上运行的8个服务的日志；您可以在文本编辑器中打开可能的代码，并使用时间戳尝试找出正在发生的事情。

其中一些最好的工作来自电信

我的2015年关于此事的想法。

我的观点是，可以从根本上改善结果的报告，诊断甚至自动生成复杂配置的过程。 “配置空间”是希尔伯特空间的其中之一，每当有人去“嘿，添加一个新的配置选项！”，您就添加了另一个维度。关键是配置空间中只有某些区域对成功的系统行为有效。优秀测试人员的某些工作是确定系统无法正常工作的区域，但仍在客户希望运行系统的区域之内。

本地目录

1999_ulrich_siemens_Test Architectures for Testing Distributed Systems.pdf
2001_long_DOA_ A case study in testing distributed systems.pdf
2006_rutherford_phd_Adequate System-Level Testing of Distributed Systems.pdf
2009_Hierons-_brunel_TAROT09_Testing Distributed Systems.pdf
2014_suny_IST_Model-Based Testing of Global Properties on Large-Scale Distributed Systems.pdf
2015_riesco_madrid_sparkTest_A Lightweight Tool for Random Testing of Stream Processing Systems.pdf

Ulrichs是电信的很好的介绍；专注于状态机，并从较小的stes构建汇总测试。其他人接follow而来。

在我当前的工作中，我一直在探索一个从学术角度看似乎没有任何东西写成的概念：度量标准优先测试。在这里，我们向应用程序添加了更多的系统指标，本质上公开了一些内部状态。然后，我可以在单元测试中声明系统各部分的状态。在大型系统测试中：收集这些指标并使用它们来帮助了解发生了什么。

早期，对于单元/集成测试来说，它是好的，尽管对正在测试的“灰箱”系统的更改比较脆弱：优化性能并测试发生故障的次数，您必须确定其是否为假。否定或合法。

关于形式规范和验证，尽管从HDFS中实现的版本开始工作，我实际上已经编写了Hadoop FS API的形式文件系统规范。这里使用的规范语言是Python，它的运行良好有一个关键原因：开发人员可以理解它，他们可以将声明性文件系统模型理解为一些元组，列表和哈希表。所有这些都将1：1映射到Spivey Z语言的设定理论演算上，只是伪装成python。这样，我们就有了一个可以被广泛理解和维护的规范-从那里我们可以导出文件系统契约测试。 ，并且没有自动解析/验证规范。我一直在玩TLA +，但是那种语言只会吓到所有人。

无论如何，希望我没有吓到你，但是我可以向你保证，在这个领域有博士学位。而且，由于许多工作都是作为开源完成的，因此您甚至可以了解其中的一些工作如何作用于开发社区，

#4 楼

语言解释如何？

关于语言解释的研究很多，但是对于脚本来说，无论在上下文内还是没有上下文的情况下，都很难理解句子。

如果说出一句话，它的语气将在其含义中发挥至关重要的作用。例如。非常感谢可以被解释为真诚的感谢或讽刺的评论，这取决于所用的语气。尝试总结一下。

#5 楼

测试与OpenGL，Vulkan等图形API的交互。

我不确定这是否符合您的要求，但是在尝试为图形应用编写单元测试时，我不得不放弃，因为没有可靠的方法可以做到这一点。

至少我能找到的大多数都是非常耗时且容易出错的（模拟接口所花的代码是实际实现的5倍），或者只能在没有不想经常改变。 （图像比较）

这是一个聪明的工程可以解决的实际问题，所以我不确定它是否适合研究主题。

#6 楼

将最佳做法更改为语言功能。
一些示例：

确保对HTML定位符的所有引用都是通过页面对象完成的。
确保页面对象条目是唯一的，不是吗？ t复制并实际使用
所有代码都具有测试，或者未被主分支接受
所有测试都涵盖了快乐，悲伤和可选的快乐和悲伤路径
单元测试和验收测试没有t可以互相重复测试
所有功能都包括一定程度的容量测试
内置可用性和可访问性，而不是可选的
作为开发团队的正式成员对待QE工程师
编写一套可以在所有设备，浏览器和版本上运行的测试。

您可以看到从易到难的各种测试。一些技术，一些人。有些似乎不可能。然后，您再次询问未解决的问题或挑战。

#7 楼

在流行的开源软件项目中提供补丁（修复错误）。

解决臭虫问题可能像您敢于尝试的那样。在任何项目中都有很多。