ACM通信
软件测试的目标
你召集了测试团队。你扔给他们一些钱。你给他们一个时间表。然后你坐下来，看着他们离开，撕开你的产品，试图打破它。他们发现错误，报告错误，发现更多的错误，报告那些错误。很快，他们就会给你提供完美的产品，让你不用担心，也能让客户完全满意。对吧?错了。
在软件测试的艺术(2011)，格伦福德·迈尔斯博士解释说，“测试是一个执行程序的过程，目的是发现错误。”测试失败是因为任务背后的意图经常是错误的。发现错误和确保产品正常工作不是同一种策略。测试团队的主要关注点必须集中在发现错误上，而不是集中在产品是否在参数下工作。这个过程被迈尔斯博士称为“破坏性的，甚至是虐待性的”，它的重点是破坏产品，寻找各种各样的输入在压力下崩溃。
然而，大多数测试人员觉得他们在帮助确保产品的成功，但事实上，他们完全错过了这个组件。迈尔斯博士注意到这种错误的关注，他说:“你不能测试一个程序来保证它没有错误。”软件本质上有无限数量的bug。鲍里斯·贝泽说软件测试技术(1995):“显示软件工作的可能性随着测试的增加而降低;也就是说，测试越多，就越有可能发现bug。因此，如果你的目标是展示高概率的工作，那么最好不进行测试!”大多数测试人员无法理解这一点。他们倾向于将其视为一种包装整齐的产品，只需要稍加打磨就能顺畅运行。
实数可以是无限的。无论产品是大是小，是简单还是复杂，是老是新，潜在的bug都是天文数字。迈尔斯博士强调了这一点，认为“要找出程序中的所有错误是不切实际的，通常是不可能的。”即使有无限的时间和资金，测试人员也无法找到所有的bug。比尔·赫策尔在他的书中写道软件测试的完整指南(1993)说:“无论我们投入多少时间和精力，我们都无法达到100%的信心!”威廉·刘易斯在他的书中写道软件测试和持续质量改进(2009)甚至称其为“测试悖论”，它有“两个潜在且矛盾的目标:给产品良好运行的信心，以及在交付给客户之前发现软件产品中的错误。”如果是这样，你会怎么做?
测试人员必须在某个点停止寻找bug。Meyers博士指出，“在测试程序时，最难回答的问题之一是确定何时停止，因为没有办法知道刚刚检测到的错误是否是最后一个错误。”发现错误会激励测试人员，他们会继续寻找错误。在某种程度上，你必须推出产品。但如果你在发现所有bug之前就发布了产品，会发生什么呢?如果你这么做了，你的游戏会不会有bug ?是的!
尽管做了那么多工作，那么多钱，那么多努力，你还是推出了一个漏洞百出的项目。这似乎毫无意义。你的产品有缺陷。充满了错误。但是你必须问自己，还有多少关键的bug ?您本可以为您的团队提供更多的时间来完成寻找所有错误这一不可能的任务，但是他们会找到更关键的错误吗?
与其浪费时间和资源试图让产品变得完美，不如推出一个你有信心的产品。质量控制总是会发现自己在截止日期前压力很大，但你可以采取一些解决方案来确保测试对产品有利。与其让测试人员花无数的时间去寻找错误，不如给测试人员一个目标。迈耶斯博士指出，“既然测试的目标是发现错误，为什么不将完成标准设为检测某些预定义数量的错误呢?”这强制了找到错误的需要，但是限制了总数，并将注意力集中在关键的错误而不是一般的错误上。
一旦测试人员通过了这个标记，您就对产品将成功发布有了明确的信心。“发布软件是为了使用，而不是当它被认为是正确的时候，”David West在对象的思考(2004)指出，“但当发现错误的速度减缓到管理层认为可以接受的水平时。”在某种程度上，需要有一个界限，一个限制，一个目标。如果你的测试人员缺乏目标，那么他们将浪费时间和金钱去寻找那些不能提高产品整体质量的漏洞。史蒂夫·麦康奈尔软件项目生存指南(1998)甚至建议“通过比较新缺陷的数量和每周解决的缺陷数量，您可以确定项目离完成的距离有多近。”
通过为测试人员设置一个明确的限制，您可以引导他们以一个预先确定的目标进行产品测试。这个目标可以帮助测试人员消除程序中足够多的bug，使程序在启动后能够顺利运行。如果您不这样做，您可能会花费不必要的时间和金钱来查找和删除可能根本不是问题的bug。我在我的博客中简要描述了这个概念什么时候停止测试?(2015)。
叶戈尔·Bugayenko他是软件工程和管理平台Zerocracy的创始人和首席执行官。
评论
鲁道夫Olah
测试是事后的，也是必要的;但是，是否有一种方法可以让我们从一开始就更好地编写代码呢?是否存在契约式设计库或轻量级的防错误工具，可以在第一时间防止错误进入代码?
在我看来，行业中对QA团队的依赖很大，开发人员不情愿地转向编写单元和集成测试(在某些情况下根本不编写任何测试，任何类型的文档也是如此)。
本质上;是否有办法将测试成本提前加载到设计和开发中，从而使我们能够更接近理想的错误发现率?
Vivek Buzruk
测试是必要的，但不是充分的。最好的软件是由正确的开发人员而不是真正的测试人员开发/交付/增强的。
很多时候，开发人员可能没有从最终用户的角度进行测试(不仅仅是确保功能的正确性)，或者可能没有以生产优先的心态开发产品。这是测试人员可以添加巨大价值的地方。我认为以上博客更多地是从独立(黑箱)测试的角度出发的。
早些时候，每个开发人员(一个非常优秀的程序员)被期望花费20%的时间在设计(包括理解需求)和60%的时间在编码上。其余的时间应该留给调试(~10%)和测试(~10%)。当引入创新/差异化(和新的架构)时，你可能遵循不同的周期。同样的比例不能扩展到开发产品的开发人员团队。他们会做什么样的测试?单位还是我做的积分?谁负责端-端-端测试?此外，在这种情况下，开发人员要花一些时间在协作、集成等方面。这就是独立测试，将测试作为一门学科开始的地方。
在当今世界，系统更加复杂，竞争激烈，不断发展，需要对开发人员的核心技能以外的能力提出挑战的集成。每个人都希望在更短的时间内开发并发布他们的软件产品/应用程序的新版本。但是很少有技能能够交付高质量和差异化的扩展产品，考虑到产品的当前状态、预期使用、集成状态和部署等所有维度。
契约式设计(Design by contract)、面向对象(OO)等方法确实有帮助，并得到遵循。但同样的，平衡和开发伟大产品的是正确的开发人员和正确的技术领导者。除此之外，还有市场压力和资源限制。
另一种选择是使用包装好的产品，在有限的时间内提供所需的质量。不幸的是，包装产品本身正变得越来越庞大。检查一下周围的一些CRM产品，你会发现测试这些产品的定期配置是一项大业务。
另一种方法是在产品....发布之前和发布时添加额外的测试周期这样你就能对产品的质量和可用性有更独立的看法。有时这样的测试人员作为DevBox测试的一部分，导致早期测试、经常测试和持续测试。
好吧,…但这也需要优秀的测试人员。我觉得这正是博客和参考资料所强调的。
所以，总而言之，您需要根据产品复杂性、需求规模/复杂性、领域、个人技能.....来平衡设计、开发和测试以及合规预期。
愿一切都好！
显示所有2评论