在开发过程中，错误不断出现在我们的GUI软件中。应该如何解决？

#1 楼

在决定如何解决问题之前，您需要了解这些反复断裂的核心问题是什么。

依靠（更多，改进，更好，更快等）测试可能不是最有效的解决方案在这里。它甚至可能根本无济于事。


是否存在代码合并问题？修复程序是否因此而被撤销？
您是否出现了新的bug，且症状相似？
这些UI功能是否基本上没有完全“成熟”？也许您是在浪费
在开发过程中过早地测试它们？
开发人员是否在新代码中犯了同样的错误？他们训练有素吗？
是否存在足够的文档？

这里有很多潜在的核心问题-每个都有不同的解决方案。

#2 楼

很难从StackExchange的两个段落中得出关于组织的可靠结论，但是在我看来，这似乎太快了。您经常更换产品的事实表明它是相当新的。对于新产品和新公司，当您的大多数用户是早期采用者时，快速发布可能比高质量发布更为重要。如果那确实是您的实际情况，那么您可能必须忍受这样的情况，直到您有更多的时间得到满足。

您在标题中提到了UI问题，在问题中两次提到，所以我假设您是质量问题特定于用户界面；即其他软件的状态更好。如果您有时间，建议您放慢速度并采取措施，确保对UI进行更彻底且一致的测试。如果您的测试人员不使用测试计划，则应该为他们编写一个计划，至少是针对用户界面中特别容易出错的方面。您的测试人员使用的环境与您的用户使用的种类和种类是否相同？例如，如果您有一个基于浏览器的UI，那么测试人员是否在使用相同的各种浏览器和屏幕分辨率？

您可能会调查为什么您的开发人员会创建许多UI错误。他们是否意识到质量问题？从他们的角度来看，快速检查工作或对工作进行单元测试是否更重要？开发人员是否使用正确的基础架构？如果一件事情的变化在其他地方导致了一系列错误，那么您可能会遇到设计问题。

#3 楼

如果您唯一关心的是用户界面中的布局错误；您可以尝试打架布局错误。
它是一个开放源代码Java库，用于检查布局错误。您可以在此处找到更多信息

http://code.google.com/p/fighting-layout-bugs/

此外Selenium可以帮助您自动创建一个回归套件。您提出了这些测试易碎的问题。在一定程度上是正确的。但是，如果做得很整洁，从长远来看，它们可以证明是一项资产。您需要在自动化和手动探索之间取得平衡，以达到两全其美的目的。

Gojko所描述的内容比以往任何时候都更加精美，因此，这里是链接

http ：//gojko.net/2010/04/13/how-to-implement-ui-testing-without-shooting-yourself-in-the-foot-2/

#4 楼

简短答案：开发自动回归套件，正确完成UI测试不会脆弱。

更长的答案：

我建议您花一些时间使用以下方法开发自动回归测试套件硒。很多时候，人们说UI测试很脆弱，但我认为只有在没有正确编程的情况下，它们才是脆弱的。确实很难创建一个运行良好的测试套件，但最终还是值得的。

思考一下，直到项目结束之前，测试人员将花费多少时间粗略地执行重复性任务并考虑开发一个功能良好/可维护的测试套件以摆脱那些重复性任务将花费多少时间。

如果您选择创建一个自动测试套件，则您或您的客户最终将获得一个系统，该系统维护起来更容易，更便宜。一个完善的自动化测试套件值得很多钱。手动测试更像是浪费金钱。

由于没有自动回归套件，因此您的团队现在承担着巨大的技术债务。您应该确定现在值得删除债务是否值得，如果是，则继续进行删除。尝试使每个参与人员都了解开发/维护此类套件的投资回报率，并尝试优先开发此类套件以及其余工作的优先级。

说服管理并不总是那么容易花费大量时间来开发测试套件而不是花费时间来开发功能可能是一个好主意，但我认为您还是应该尝试。

雇用一个可能也是一个好主意硒顾问/培训师一段时间，以培训您的测试人员/开发人员如何构建功能完善，功能良好的测试套件（如果您的公司还没有任何专家的话）。建立一个好的测试套件非常困难，专家可能会阻止您进入所有陷阱。

#5 楼

您的签到流程/策略如何？

我过去发现开发同行评审和测试同行评审对减少此类回归有很大帮助。可以编译清单以标识出前5位到前10位风险最高的区域，并设置一个规则，如果开发人员的计算机上的任何这些中断（前提是它们已加载了最新的代码），则不允许他们进行检入。不得超过5-10分钟。这些测试可以是手动的也可以是自动的，具体取决于这些屏幕的变化。

是的，它将增加签入时间，但这可以确保您早点发现这些错误并立即修复它们。而不是花时间进行测试，提出错误，进行开发并再次进行测试。

有了这一过程，开发人员很快就会学会检查这些事情，甚至可以在做同行之前-测试复习。结果，它们将产生更好的代码。

#6 楼

您的团队面临的几个问题以及可能的解决方案：

保持/负载过多-公司正在尝试推出产品的速度太快，或者您的产品确实需要不断更改功能，或者开发团队不做测试。在这两种情况中的一种或两种情况的组合中，测试团队要承受大量的负载以保持这种状态。这可能会导致测试人员疲劳或态度的发展，即使我们尽力而为，仍然存在很多错误。

自动化-测试自动化与开发它的测试团队一样脆弱。如果您有可以开发良好的测试自动化功能的工程师，那将无可奈何。如果您不够自信，请从自动化相对稳定且重复性最高的任务开始，例如如果您必须在每个测试周期中测试“创建用户”，则值得进行自动化。自动化还将为测试人员带来一定程度的创造力满足，并为他们带来期待。毫无疑问，它将以更快的速度为您提供更多的覆盖范围。

与项目中的其他成员进行通信-与项目经理或类似人员进行通信，即测试团队正在超负荷工作，并且他们是否可以重新考虑每个发行版所推出的功能数量。开发团队也很可能有同样的感觉。结果，在将代码传递给测试团队之前，他们可能无法彻底测试其代码。该公司可以选择-添加更多具有更多错误的功能，或者减少具有更高质量的功能。

测试团队-最后也是最重要的一点（如果尚未完成），请经理在两周内至少与每个团队成员会面一次，并获得他们的反馈。他们的满意程度，对工作，工作量的看法等。获得自上次会议以来所做的工作的最新动态以及他们在下届会议之前期待实现的目标的最新信息。任何改善产品质量的建议。这也将提供有关团队实际水平，是否有足够的动力，是否有人做得还不够等方面的洞见。您还可以在质量检查团队中进行日常站岗以进行每日更新。

希望提供一些指导。

#7 楼

很好的问题。感谢您提出要求

如果我们计划测试生产/实时方案，自动化可以解决这个问题。以下是实现产品自动化的方法。

第一阶段


在开发阶段开始使用自动化
当拥有模拟UI时，Id

阶段II


在测试过程中，确保您的自动化处于可用状态
根据已发现的错误＃添加/更新自动化案例

第III阶段


将代码部署到生产环境中后，从日志中捕获大多数用户工作流程序列

示例


50％的用户登录，搜索并购买单个产品
30％的用户登录，查找报价并订购多个产品


自动化可以如果我们根据生产日志中的实际用户场景来利用它，则很有用。这样，您可以确保测试所有主要的用户工作流程

功能测试工作量+回归测试工作量+更新自动化工作量可能是考虑时间表的挑战。可能的解决方案是，开发人员在运行自动化套件并在早期阶段确定错误。测试团队可以在工作范围内添加生产工作流（基于捕获的日志的主要6个工作流是自动化工作的标准）


即使您无法自动化生产工作流，也要跟踪生产错误＃和遗漏的场景，并确保它们针对每个构建都退回
拥有知识存储库/准则（不是作为测试用例，而是至少要说（可能发生错误的区域/清单））将有助于
以上所有个人的所有权证明事情很重要。从遗漏的错误中学习并添加相关的检查点以解决将来的发行版
获得领域专业知识需要时间，但是拥有丰富的产品知识将有助于进行良好的探索性测试
跟踪错误，检查重复发生的错误的模式。如果我们能够得出某些领域的开发人员的评估质量/某些开发人员需要改进，则将其作为质量检查小组的建议

#8 楼

在我看来，您没有在重复使用代码。

除非您提早开始，否则我认为您无法使用复杂的UI运行全面的UI测试自动化。不过，这仍然是一个好主意！但是我认为滚动位置等细节并不是您关注的重点。 （也许我们只是做错了）
在我们的UI测试中，我们测试用例和一些常规冒烟测试。

那么这可能是设计问题？！
如果封装了UI进入控件并重用它们，它们被破坏的可能性较小。

我知道责怪测试人员的本能，但作为开发人员，我需要专注于减少bug的产生。

因此，我使用封装变化的设计和可重用的组件。
将您的设计分离，以便您可以重用证明有效的组件。
对于我们来说，TDD可以做到这一点。

#9 楼

如果测试团队无法全面测试GUI，那么看看是否可以让其他人代替它进行测试！

在开发人员移交软件之前，先了解一下他们进行了哪些测试，看看是否您可以让他们做更多/更好的测试。另外，您能否让客户为您测试软件（即Beta测试）？