问题标签 [qa]

我们必须验证大量资源文件的命名约定和格式完整性等。

是否有可用的框架/工具使这更容易？我想到了像 Ant/Phing 这样的构建工具，但我想知道是否有更专注于这种测试的东西。

理想情况下，它将根据修改时间缓存结果并生成不合格文件的报告。它应该足够灵活，可以快速轻松地将任意测试添加到适合某个正则表达式的文件中。就像测试所有位于 3 个目录深处的 *.psd 并确保它们的颜色空间是 CMYK。添加依赖关系也应该很容易，这样如果其中一个 PSD 失败，父目录 .. 说 2 级，也会被标记为无效。理想情况下，它是可插入的，因此我们可以编写一个 shell 脚本或其他东西来执行返回 true/false 的新测试（如 CMYK 测试）。

当然，我们可以自己动手……但不要重新发明轮子。

想法？

这可能是一个错误的问题，但是，在 asp.net Web 应用程序上复制大量负载的最佳方法是什么？有没有一种简单的方法可以模拟特定页面上的许多请求？还是最好使用分析器跟踪单个请求，然后在性能正常的情况下从中解决？

了解 Web 应用程序与服务器规范的配合情况会很好。我希望能够在我的测试服务器上模拟大量流量，以便我可以确定生产服务器是否足够好（特别是 iis/asp.net 而不是 db 性能）。

我可能有机会成为工程密集型 QA 团队（单元/场景测试自动化）的一员，以获得更多报酬。然而，目前我是一名软件工程师，这听起来对我来说更有声望。不过，更多的钱听起来也不错，但在什么时候值得呢？

你会说哪种类型的测试应该是重点（对于测试人员/质量保证人员），为什么？

来自维基百科的一组快速定义：

黑盒测试

• 以测试对象的外部视角推导出测试用例。这些测试可以是功能性的或非功能性的，尽管通常是功能性的。测试设计人员选择有效和无效输入并确定正确的输出。不知道测试对象的内部结构。

白盒测试

• 使用系统的内部视角来设计基于内部结构的测试用例。它需要编程技能来识别通过软件的所有路径。测试人员选择测试用例输入以通过代码练习路径并确定适当的输出。在电气硬件测试中，电路中的每个节点都可能被探测和测量；一个例子是在线测试（ICT）。

只是为了澄清一点，我意识到两者都很重要，但是通常它们在开发和质量检查之间是分开的。

内部知识对测试人员/QA 是否重要？我听说过使用这些知识进行测试可以让他们更好地测试问题的论点，但我也听说过这种知识会分散功能需求并促进“测试代码”而不是预期解决方案的论点。

http://stackoverflow.com/questions/61532/tips-for-hiring-good-testers

上面的帖子我已经参考过了，但是我想知道一个没有丰富经验的应届大学毕业生在面试时可以期待哪些面试问题？他可能已经在课程中完成了质量保证测试课程。具体来说，他最有可能被问到关于基本测试的哪些问题？

我在一家程序员不到 10 人的小型软件公司工作。我们的软件安装在全球数十个地方。我们的代码库非常庞大，主要是由于糟糕的设计和大量的代码重复 (IMO)。我们有大约 30 个不同的项目，每个项目总共有大约 600 KLOC，其中大约 200 KLOC 是我们自己开发的代码。当我在 2006 年到达那里时，这段代码甚至还没有受到修订控制。我已经设法说服权力，它很重要，我们现在使用代码控制系统（cs-rcs，不是我的选择，但总比没有好）和错误跟踪系统。最大的缺失是整个过程中完全缺乏质量保证。我们的发布过程在纸面上是不存在的，实际上它包括“按 ctrl-F9，将二进制文件复制到客户端，声明问题已修复”。

谁能指点我一些官方文件或PHB语言文件或文章来解释这个过程中的公然疯狂？我相信老板可以聘请一些顾问告诉他这件事，然后他可能会相信。但我只是一个拥有软件工程学士学位的低级维护人员。而且我的种族对我也没有帮助。在这种情况下使用什么弹药最好？

正如我从一些问答环节中了解到的（参见this和this），单元测试应该由开发人员编写。

在我以前的工作场所，我们试图将这项任务交给 QA 工程师，但没有奏效。可能是因为它已经是一个项目的中间，他没有机会进行重要的代码覆盖，或者可能是因为其他原因。

您认为以这种方式将开发人员从编写单元测试中解放出来是一个坏主意吗？

我想知道人们使用什么机制来执行和跟踪对 SVN 承诺的同行评审。

对于每个提交，我希望能够跟踪人们是否进行了同行评审（我不确定在他们不能提交的情况下执行规则是否是一个好主意，我的直觉是不应该像那里那样强制执行可能是在没有同行评审的情况下提交的正当理由），但是应该能够跟踪未经审查的提交，以便在发布之前我们可以查看所有这些提交。

您在编写集成测试时遇到了哪些挑战？编写单元测试是否有助于编写集成测试？

您的 QA 团队是否有效。我发现我遇到的许多 QA 人员更多是验证者和软件破解专家。

我所说的验证者的意思是，他们逐步完成所提供的所有场景，基本上是遍历应用程序并确保它完成预期的工作。

我所说的破坏者的意思是，他们验证但他们也努力寻找破坏软件并发现缺陷的场景。

你的发现相似吗？

关于破解软件的历史记录 在 80 年代 IBM 内部有一个名为 Black Team 的团队。他们有一种文化，当他们破坏软件以鼓励识别缺陷时，他们会说他们已经“成功”了。当他们未能发现/识别软件中的任何故障时，他们认为他们的工作是“失败的”。另一方面，他们“失败”的结果是非常可靠的软件......

还有一本书：James Whittaker 的《如何破解软件：测试实用指南》