内部测试工具

#1 楼

是。在过去的几年中，我已经针对以下方面构建，重新构建和改进了测试工具：


基于UIAutomation的Windows自定义库
基于C＃的完整库基于Watin和UIAutomation库构建的测试堆栈
控制生成器
测试用例管理系统
缺陷跟踪系统
各种互用工具可根据需要与TFS，JIRA或Quality Center配合使用

大多数内容都是开源的（testingstax.codeplex.com。我们发现，虽然我们需要的总体技术经验更高，但是现在我们可以控制自己的命运，所以我们可以真正解决我们的问题，而不是尝试采用别人的解决方案。不能使用其专有的封闭源解决方案解决问题。

使用开放源代码/ in hous通过组合，您实际上可以使用更广泛的人才库，并且如果您遇到技术难题或需求，那就是解决这些问题的强大动力。如果没有迫切需要“愤怒”地使用X的绝佳工具。构建一个很酷或很不错的东西永远不会完成。

我想说的另一个关键点是，当涉及到这类东西时，它与工具无关，但关于人民。如果您没有具备开发和维护工具技能的人员，那就不要尝试构建它们。

#2 楼

我已经完成了许多使用不同语言和平台构建的内部工具，尽管我同意之前所说的一切，但我认为缺少的一点是，不仅要确定您是否需要该工具，还要确定是否要支持它。您要么需要能够安排该工具的维护工作，要么需要一名工具匠对其进行维护，否则，您会得到一个满足需求X的工具，但它永远不会进展，并且也不会得到更新。此外，它还需要文档，因为该工具可能不仅已经安装到位并已被使用，而且几年后可能还需要新的人来研究它，并且您想确保将来的人对工具的含义有所了解设计或制造的。注释代码很好。

也不要忘记测试该工具，我发现了一些实例，该工具对X效果很好，但导致Y问题，而Z却完全失败。在开发内部工具时，测试还不够完善。

#3 楼

在我工作的地方，几乎我们所有的工具都是内部构建的。有些提供了极大帮助，而另一些则花费了很多时间。

但是，IME如果花时间根据要解决的最大问题优先确定要构建的内容，然后再像开发客户一样谨慎地开发工具面向应用程序-并进行迭代开发，这样您就可以知道自己的发展方向是否正确，并与产品规划进行沟通，以确保您构建的内容在下一版本中不会过时，您很有可能获得积极的发展投资回报率。

否则（根据我的经验），您可能也做不到。

#4 楼

我工作的团队使用的是开源软件和本地开发的软件的组合，但其中绝大部分是本地开发的。
我们使用可用的解决方案进行持续集成和运行自动化测试，但其余围绕此框架已从头开始构建；我们负责测试的每种技术的需求对于任何常规工具来说都太具体，无法正确支持。我们依靠外部解决方案来很好地执行非常特定的任务，然后在产品工作方式的范围内构建我们需要通用的系统。该代码库很有趣，并且该框架已经可靠地为我们服务了很多年，并且可以扩展为支持新项目而几乎没有什么困难。

#5 楼

是的，但是我通常会尝试找到一个可以完成大部分繁重工作的开源工具，并为其添加自定义项。这样，您就可以快速增加价值，而又不会因再次开发基础设施而感到困惑。以一种形式将其映射到不同的形式和版本），大量的规则和数据，因此是自动化的绝佳选择。我找到了一个名为Mirth的开源工具，网址为http://www.mirthcorp.com/products/mirth-connect，该工具在医疗保健界相当流行，它具有所有HL7的功能，验证器，文件，数据库，Web服务的连接器以及简而言之，脚本编制工具就是您所需要的所有基础结构。现在大约三年后，该解决方案仍然非常有效，可以非常频繁地运行所有回归测试（100K），并且现在已完全集成到工具链中。

我必须说，它主要是捕获回归错误。

#6 楼

在构建任何东西之前，我将再次浏览一下开源世界。不管是Java，Python，Ruby还是C＃，都有工具。例如，您提到安全扫描...您是否考虑过运行Nikto。对于性能测试，可以使用Siege甚至Apache Bench。

#7 楼

我们已经成功地将实用程序方法添加到可以在组织中使用的现有ops源工具中。我们大量使用Selenium进行前端自动化测试。已构建的实用程序方法-测试数据的外部化，页面对象，测试管理工具中的更新等。这些util方法减轻了测试人员的负担，否则他们将不得不编写自己的库进行开发。

#8 楼

在我工作的团队中，我们已经看到了开发内部工具的许多价值，例如：


我们QTP的网站前端自动化，因此QA团队成员并不需要QTP专家来运行自动化测试。
可以配置并报告QA服务器配置的工具。
用于验证构建部署的工具。

我认为，如果任务重复而缓慢，那么回报肯定是可以接受的。值得说服管理层让一些团队成员每周至少分配一天的时间来开发这种工具，当然，前提是团队成员具有必要的编码技能。

#9 楼

在我最近工作的地方，我为负责测试的应用程序构建了相当特定的工具或自动化框架。我只是发现根据我正在测试的应用程序更容易做到这一点。在这种情况下，我的环境是数据驱动的C＃winforms和Windows Services应用程序。对我而言，为自己的工作构建应用程序/任务特定的工具变得更快，更容易。如果我做了更多的网络工作，我可能会更加关注Watin或Selenium等开源工具，并使其适应我的需求。实际上，这很大程度上取决于您要实现的目标。

我喜欢自己的家用工具的一件事是，我确切地知道它们的用途以及优势和局限。随着时间的流逝，您可以积累一个不错的代码库，您可以在不同项目中使用这些代码库，以帮助您更快地生产工具。

#10 楼

测试工具提供商的另一个观点

我看到公司在执行“构建与购买”决策时犯的一个错误是，它们往往低估了维护所需的工作量并不断改进工具。如果您要创建一个简单的快速工具，并且您和您的团队有信心不会随着时间的流逝而扩大范围，那么这个“警告性故事”可能对您不适用，但是这个问题已经困扰了许多公司（例如Tangurena公司？）。

在对预测的准确性过于自信之前，“我们可以在X个小时内构建比XYZ工具更好的东西，从而更好地满足我们的需求”，因此值得一试更新。这样做将：


让您感觉到您很快就会将在XYZ工具中标识的“缺失特征”添加到它的可能性。
作为对您的初步计算的现实检查，以了解创建您自己的工具需要多少工作。我们已经对测试工具进行了更新，您可以查看此列表（下面部分显示）。我严重怀疑，即使有财富100强预算支持的IT团队也会如此频繁地对内部构建的测试工具进行改进，错误修复，更改等。 br />
需要明确的是，我并不是要说总是要买工具。很多时候，获得开源工具或构建自己的工具显然对您来说是一个更好的选择。我只是想强调一下我所看到的风险；公司倾向于低估内部工具的持续维护和改进成本（并且可能高估了未来5年内部资源对改进这种工具的兴趣）。

PS-对于感兴趣的任何人，我们决定将代码开源到上面显示的“最近更新”功能。在GitHub上。

#11 楼

以下是基于我对嵌入式系统进行测试和开发内部测试的经验而得出的，对于“纯”软件系统的答案可能有所不同：
您必须将执行测试的框架与“驱动程序”和
执行测试和收集结果的框架可以像x-unit（Java或CPP），其他单元测试框架（Perl有多个）或in内部工具。很多情况下，开发一个内部软件的好处并不重要。
OTOH“驱动程序”层（所有测试的通用部分，通常是较低的部分）将受益于内部软件。例如，我评估了一个基于JUnit的测试套件，其中包括用于通用测试和测量设备的驱动程序-这些驱动程序非常通用，因此效率低下且难以使用。

#12 楼

当您的产品与众不同时，内部构建的测试工具将更加高效。以我的经验，内置的测试工具可以根据您的产品需求更有效。挑战是您的团队需要根据产品的重大变化不时更新测试工具。