在持续开发下测试应用程序

#1 楼

Craig，我在类似的环境中工作了6年。 DEV和QA在同一个盒子上，使用的代码始终在不断变化。在我进行测试的过程中，开发人员签出了一个程序，进行了更新和重新编译。刚开始的时候，我很沮丧。如果可能的话，我会创建自己的“沙箱”（仅用于db，而不是实际程序），但有时由于添加的新程序数量而导致不可行。有时，我在进行会话崩溃之前会收到警告，但通常不会。背景知识：


我们有2位测试人员，您真正的测试人员和另外1位测试人员。
我们支持5位开发人员，偶尔支持一到两名。
我们有1位核心客户购买的工具，带有12个可选模块，5个版本的软件来支持，5个版本的OS以及3个平台的支持（IE＆FF是唯一的浏览器）。
QA验证我们自己的错误和客户不管发生了什么事情（漏洞修复无时无刻不在；修复新开发人员时没有中断）。
我们会每60天不断推出服务包，并不断推出新版本每18个月左右。
所有这些都是在没有任何要求的情况下完成的。

听起来还熟悉吗？

从记录上来说，我没有抱怨；我说的是事实。这种环境对我们的团队来说非常有效。像任何团队一样，总会有一些我需要改变/改进的事情。我们有一个非常忠诚的客户群，它为我们的系统赢得了成功，并取得了成功。 >如何在这样的环境中进行彻底测试？内部版本不稳定，错误修复会影响其他模块，我也不想错过任何内容。
临界值是最好的解决方案吗？

＃1：接受无论测试多么彻底，您都将遗漏错误。我的团队做了什么并且目前为止运作良好，我开发了一个“微型回归”套件，该套件涉及所有模块，仅测试了核心功能。我对它进行了加权和缩放，这样一来在紧缩的时候就不会碰到较低的加权区域。其中大部分是遗留代码，几乎没有错误。

对于＃2：我建议您在自己的“代码冻结”的2-3天内，要求开发人员主动进行代码更改，并告诉您程序x正在更改。仅当他们知道只有几天时，这才起作用。不用担心它是否敏捷。找到最适合您的团队和环境的方案，然后进行选择。

就自动化而言：
如果维护脚本所需的时间与手动测试所需的时间相同，则不要不用理会我们的自动化程度为零，因为全职管理需要1个人。

如果可以的话，最后一件事情。您的理智：保护它。为此，请将您的难题提交给您的经理，按照他/她的建议做出回应，然后放手。您知道自己正在做的最好的工作，超越一切。在这种环境中找到积极的地方，向他们学习并坚持下去。您将在今天和将来使用它们。

#2 楼

阅读您的帐户后，我有几个问题。起初它们听起来可能很刺耳，但您的声音听起来像是您所在的组织必须考虑一些严峻的现实。

1）复杂性在这里是一个问题，还是您对复杂性有何反应？ （伴随着您的组织显然对复杂性没有反应吗？）

2）您的程序员是否需要编写他们可以保证可以使用的代码，还是仅仅是需要编写代码？

3）您是否有任何经理在那里工作，或者每个人都只是干他喜欢的事情？

以下几点要点：

我们目前正在使用看板董事会的“敏捷”方法论，以跟踪所有工作项目。

不要将“方法论”与“实践”或“工具”或“技术”甚至“方法”混淆”。方法论是对方法的研究。现在，看来我正在做书。那不是我的意图。但是，我发现人们经常用盛大的词汇掩盖不胜一筹的知识或采用需要继续学习的学科。最重要的是，许多应用程序都依赖于其他应用程序。因此，即使尚未对某个应用程序进行技术更新，也有可能它仍然受到其他地方的更改的影响。

如果您想到而不是将所有这些都视为问题，那么会发生什么？它作为测试结果-测试正在揭示的问题的证据吗？事实是，相互依存度不高对产品乃至业务都是一个问题。由于您无法控制代码和相互依赖关系，因此无法更改它-但可以肯定地将其报告为问题。任何使测试变得更加困难或需要更长时间的措施，都会使产品中的所有错误得以更长时间地隐藏，从而增加了风险。

另外，由于应用程序的不断开发，很难对稳定的版本进行测试。

这是同一问题的另一个实例。当您最终部署了一个足以进行测试的稳定性的构建，并且您在大量不确定性和极端时间压力下进行了一系列测试时，是什么使您以及开发团队和企业认为该稳定性足以发布为了解决这个问题，我尝试引入一种“截止”期，在此之前，没有人可以在发布前2/3天合并到我的测试分支（但是此延迟期不会别把我当成特别“敏捷”的人。）

别担心；除了速度部分外，您的团队在执行其他操作上似乎都不是特别敏捷。

Agilists（至少是XP员工）谈论的一件事是可持续步伐的想法。您的测试正在揭示（您正在描述）一个在我看来似乎不可持续的步伐。您可能会问：“我该如何应对？”但是我认为在这里试图应付会加重这个问题。一个更重要的问题是，“开发团队将如何回应我透露的有关产品和项目的信息？”

在类似的工作环境中，任何人都没有经验吗？他们可以提供的任何建议，因为这会令人沮丧，显然，更多的动手操作可能会不错，但这不是可用的选择。认为它不能真正解决问题）。无论如何，这是您的企业选择拒绝的选项。他们还能做出什么其他选择？

--- Michael B.

#3 楼

开发人员与测试人员的比例为5：让开发人员编写自动化的单元测试是我所追求的长期策略。

问题描述了理解系统依赖性（和相互依赖性）的问题。我相信采用单元测试将推动某些行为，这些行为会使设计上的依赖关系更加明显。虽然这不是最终的答案，但要花些时间才能从这项工作中获得一些成果。

为了得到一些短期的缓解，我会召开一些会议来真正记录依赖项。视觉上。包括每个组件（dll），每个数据库，每个UI，甚至甚至每个脚本等。您不能包含太多。

#4 楼

首先，我要说的是，由一群经验丰富且受人尊敬的测试人员提供的大量答复，请确保明智地使用他们的建议，我知道我会:)

我的情况截然不同，我们是一家中型组织，在许多开发和测试环境中采用敏捷Scrum方法。话虽如此，我们每天执行数百个构建和部署。我们不断发展的成功的关键在于单元测试，构建和部署自动化以及不断的沟通。

如果您遇到的情况，我将重点关注以下内容：

我什至无法开始真正地描述单元测试对持续集成成功的有用性。话虽这么说，这可能是您无法控制的事情，请务必加以推动，但您自己却做不到。

再次考虑自动化。考虑到您是一支大军，我建议首先进行一系列烟雾/健康测试，以从最重要的应用程序开始进行部署。我真的会专注于非常简单的检查应用程序启动和对请求的响应的事情。聚集一个简单的套件（每个应用程序可能要进行一个或两个测试）以在每个部署上运行将帮助您更快地发现问题，这是您严重缺失的CI的关键。

与开发人员进行代码审查。我发现这对于创建测试和理解代码在幕后的实际工作非常有帮助。此外，向开发人员提问通常会在您开始测试之前就发现问题。

与企业进行交互。您的公司是否对每次部署中都会出现的当前缺陷感到满意？如果不是，则可以推动更改以提高代码质量。

最后，我要说的是，我真的很羡慕您的情况。作为唯一的测试人员，您可以尝试自己认为合适的新事物，并查看对您的团队有用的东西。我有点控制狂，很乐意为您提出的问题找到解决方案。对我来说，弄清楚这是我们要做的很酷的事情。

祝您好运，测试愉快！

#5 楼

我将提供一些建议，然后描述自己的情况，以便与您进行比较。

您两次提到“敏捷”，但说您对当前流程几乎感到沮丧，这表明尽管您可能不重视当前流程，但您确实重视“敏捷”原则-也许所描述的原则在敏捷宣言中。在我看来，敏捷性就是使用频繁的通信对变化做出快速反应。如果您无法负担每个周期的全面回归测试，则必须像现在一样，找到一种选择性测试的方法。也许您的开发人员可以传达其他信息，这些信息可以帮助您改善选择过程。如果他们现在不这样做，他们可以建议可能会受到更改影响的领域。 （这只有在开发人员认真地承担这一责任时才会有所帮助，但是以我的经验，大多数开发人员都会这样做。）正如Rob Murdoch所提到的，另一种选择是增进您对应用程序中组件之间如何相互依赖的了解，以便您可以自行决定如何将错误修复程序转换为需要测试的区域。

如果您不能聘请另一位测试人员，并且如果一个人要测试的工作太多，那么可能是时候将一些测试推回给开发人员。这可以通过自动化的单元测试来完成。另一种选择是要求开发人员协助进行手动测试。如果您走这条路，建议您每次请同一个开发人员测试相同的东西。有时，在开发人员多次手动测试某些东西之后，他们会提出自动测试东西的想法。或者，如果开发人员一遍又一遍地发现某个区域中的错误，他们可能会想办法使容易出错的部分更可靠。

这是我的情况。我是一个由三个开发人员组成的团队在单个应用程序上的唯一测试人员。我们并非故意遵循敏捷过程。我们每六到十二周就会部署一个大型版本，中间会放一些较小的“错误修复”版本。在测试完新功能之后，我需要一周的时间进行回归测试。

大多数情况下，我的开发人员不会编写单元测试。我经常有大量的时间来编写自动化程序，因此对于某些容易出错的，特别重要的或者手动进行测试特别耗时或容易出错的选定区域，我拥有一些API和文件级的自动化功能。

您描述了UI自动化的非生产性体验。我对Visual Studio的编码UI测试不熟悉，但是我对其他UI自动化技术的经验是应该有选择地使用它。我的经验也是，UI自动化的维护成本常常超过其收益。我只在界面变化很小但由于实现更改而容易出现错误的地方使用UI自动化。 （我也将此原理用于非UI自动化。）

#6 楼

当我读到这篇文章时，我不得不承认我的第一个念头是“我不知道你为我的雇主工作过”

我面临着与六个测试人员组成的团队类似的困难，其中大约有两个测试人员（目前）有十几个开发人员在针对不稳定的代码库和发布日期进行了十项重大新功能处理，同时又对测试软件进行了巨大的结构更改，从而破坏了单个回归脚本（大多数问题也是错误的软件，而不更改执行GUI的脚本必须考虑的更改）。

各个级别的自动化都可以帮上忙，但是要想使它正确，确实要付出很大的前期成本。获得稳定的GUI端自动化的关键是确保脚本代码中恰好有一个地方明确引用了GUI组件。一旦知道了这一点，无论是通过名称映射（“ EditBox1” =“ FirstNameEdit”等）还是其他方法，GUI级自动化都会变得更加稳定。在过去的6周中，我花了大约3到5倍的时间来处理最古老的脚本（美化和略微重构的记录和回放），这是我围绕并面向对象设计和构建的脚本所花费的时间，数据驱动的脚本代码框架。

那就是说，我想您当前的问题是教育您周围的人有关测试的价值以及所有开发人员进行更多单元测试的好处。这可能是一个棘手的话题，尤其是当您有效地告诉与您合作的开发人员他们的工作“不够好”时。为此，我建议向不进行单元测试的人员介绍单元测试，以节省时间和精力，并确保其他人所做的任何事情都不会破坏其他人的代码。

我希望您能想到一些事情。这不是一个令人愉快的地方，但是有时知道您不是那里唯一的人会很有帮助。

#7 楼

很好的问题。我经历了类似的状态。请找到相关问题

采用敏捷测试是一种好方法吗？

User246回答我想提及并添加一些建议


首先，问问自己，敏捷的哪些方面对您很重要。其次，问自己为什么这些方面很重要。
最后，问问自己自己所提及的实践是否与这些原因兼容

由于您只是管理多个应用程序的一名测试人员，因此面临的挑战是


由于时间限制导致无法进行手动测试，因此没有投资自动化的范围，这会将测试策略限制为手动测试
我建议您评估/花时间进行分析，如何实现重复的手动测试工作，您需要分配20％的时间用于自动化
可能是您的工作量的分散方式。您可能正在执行多项任务，导致工作时间延长。如果您可以安排时间/计划任务并验证实际工作，则将有所帮助。尝试使用http://www.rescuetime.com/

如果开发人员可以执行单元测试用例/记录他们执行的基本功能测试用例，则有助于在早期识别错误，如果可以识别标注可能会被DEV团队发现的基本错误，这将减少在解决问题上花费的时间
采用白盒测试和黑盒测试策略的结合。对于与DB相关的测试，请尝试使用VSDB DB版本的工具-T.S.T-T-SQL测试工具-http://tst.codeplex.com/，查看是否可以自动执行Web服务，数据库（与存储过程相关的测试用例）。这样，您可以手动测试UI层，并且可以单独测试其他相关功能。我对一个Web应用程序进行了一些分析-测试自动化设计问题

另一个很好的阅读-哪些因素会影响质量检查/测试人员与应用开发人员的比例


请添加您的评论。我将根据自己的经验分享反馈。

#8 楼

我想提出两点。

首先，敏捷并不意味着您不能跟上步伐，它实际上是相反的。敏捷的目标是快速但高质量。例如，scrum模型中的核心思想之一就是拥有专用的sprint进行部署（这是一个经常被忽视或忽略的想法）。这样做的原因是为了提供稳定性，以便真正降低质量。提到的另一点，但绝对值得重复的一点是，具有足够的单元测试的测试驱动开发是敏捷的核心概念，这非常重要。

其次，我想就此提出不同的意见。 UI自动化。我已经取得了无数的成功，并假设它是您可以用来进行回归测试的最简单，最重要的工具之一，前提是您要测试的产品的预期寿命足够长，并且在此期间回归测试通过的次数预期寿命不仅仅是少数几个。为了使UI自动化成功且可维护，您需要使用正确的抽象级别。如果您正确编写UI自动化，那么代码更改影响一个测试用例还是一千个测试用例就无关紧要，那么更新测试所需的工作量应该相同。这意味着测试用例应如下所示：
public void UpdateUserTest（）
{
SignIn（UserData）;
UpdateUserData（UserData2）;
VerifyData（ UserData2）;
}
这是一个非常基本的例子。注意，没有引用页面上的特定元素，甚至没有引用测试方法中的特定页面。同样，在您的帮助器方法（SignIn，UpdateUserData和VerifyData）内部，您应该仅引用包含在页面容器类内部的元素。最后，需要告知开发人员要在适合元素的位置添加ID（并且不能随机更改那些ID），并且要意识到这会影响您的自动化，因此他们可以在可能的情况下避免这种情况。

UI自动化的经验对于其中的某些人来说是有用的信息。如果愿意的话，我很乐意提供有关如何实现Web UI自动化抽象的更多详细信息。

#9 楼

我想补充一点，过去对我有帮助。这是在这种情况下的责任。

在我看来，不是创造质量的责任在于测试人员。开发人员应该通过编写良好的代码来创造质量。他们不仅应该相信，而且还应该表明他们已经创造了能够发挥作用的单位。并且各个部门可以一起工作。在这种情况下，测试人员实际上只应该执行最后的检查步骤，即接受最终结果还是使最终结果失败。

现在，测试人员可以以各种方式帮助开发人员。但是，在我看来，重要的是不要免除开发人员的责任。该公司已将包括文档在内的产品发送给IBM测试实验室。返回的结果是“我们发现了太多错误，将无法继续进行更多测试”。当公司询问实验室发现了哪些错误时，答案是“我们不会告诉您，因为那样的话您将只解决那些错误，而不会解决所有必然存在的其他错误”。这当然是极端的，但可以作为例证。