blocks|key|913782|text|我要说的是，你可以不需要测试而不是需求。如果你没有需求，你怎么知道你在开发什么呢？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|913783|如果程序员足够优秀，他们应该能够捕捉到测试中发现的大多数严重错误。|913784|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I'd say you could go without Testing rather than Requirements. If you don't have requirements, how do you know what you're developing? 

If the programmers are good enough, they should be able to catch most of the egregious errors that testing would find.

blocks|key|92287|text|转过身，跟着我重复：“测试就是需求。”:-)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|92288|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Turn this around and repeat after me: "Tests are requirements." :-)

blocks|key|4157544|text|如果你指的是“正式需求”，我可以并且很容易没有这些需求。我更喜欢一个活生生的、会呼吸的客户，他能告诉我他们想要什么，而不是一份死板的、过时的文档。切换到TDD之后，我再也不想回到“无测试”的环境了。我选择非正式需求--故事、现场客户和客户编写的验收测试--而不是正式需求和没有测试。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4157545|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

If you mean "formal requirements", I can and easily do without those. I would much prefer a living, breathing customer who can tell me what they want over a rigid, out-of-date document. Having switched to TDD, I wouldn't ever want to go back to a "no test" environment. I choose informal requirements -- stories, on-site customer, and customer-written acceptance tests -- over formal requirements and no tests.

blocks|key|913874|text|你必须根据需求进行测试，所以如果你没有需求，你就不能进行测试。因此，如果你必须选择一个，你只能选择需求。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|913875|但是不做测试是一条失败的道路。有保证。|913876|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

You have to test against the requirements, so if you don't have requirements you can't do testing. So if you have to pick one, you can only pick requirements.

But not doing testing is a path to failure. Guaranteed.

blocks|key|908752|text|如果要求我在要求和测试之间做出选择，我会选择润色我的简历。在任何项目中，你都离不开这两者，因为基本的项目生命周期是：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|908753|构建并定义需求/目标(也称为Requirements)|908754|Design+&|unordered-list-item|908755|
|908756|+to+the+requirements|908757|908758|Verify，您按照规范(to+requirements.)|908759|
+)构建|908760|如果你没有可验证的成功标准和目标(然后被验证)，你如何确保你会成功呢？如果你没有成功的机会，为什么要开始这个项目呢？|908761|entityMap^0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|U|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|V|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|W|8|@]|9|@]|A|$]]|$1|I|3|J|5|F|7|X|8|@]|9|@]|A|$]]|$1|K|3|H|5|6|7|Y|8|@]|9|@]|A|$]]|$1|L|3|M|5|F|7|Z|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|10|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|11|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|S|$]]

If I were asked to choose between requirements or testing I would choose to polish up my resume. You really can’t do without either in any projects because the basic project lifecycle is:

<ol>
<li>Define Needs/Goals (AKA Requirements)</li>
<li>Design &amp; Build to the requirements</li>
<li>Verify that you built to spec (to requirements.)</li>
</ol>

If you dont have success criteria and goals that are verifiable (and then are verified) how can you insure that you are going to succeed? And if you dont have a chance to succeed, why start the project?

blocks|key|92318|text|我会说需求，因为当你在开发软件时，客户似乎总是会有某种程度的“特性爬行”。测试是SDLC中的关键部分之一。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|92319|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I would say requirements because there always seems to be some level of "feature creep" from the client when you are developing software. Testing is one of the crucial pieces in the SDLC.

blocks|key|3312387|text|需求和测试对大多数项目都很重要，但如果你真的必须选择，你应该选择需求。挑选需求而不是测试的优点之一是，您可以节省一些开发时间，因为开发人员知道他们必须构建什么，并且如果开发是在手头有额外时间完成的，您可以将这些时间分配给测试:)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3312388|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Requirements and testing are important for most projects but if you really have to pick, you should go with requirements. One of the advantages of picking requirements over testing is that, you might save some development time since the developers know what they have to build, and if the development is done with extra time in hand, you can allocate that time for testing :)

blocks|key|92445|text|测试(功能和集成)比需求更重要；如果您可以指定测试，那么您至少可以隐含地指定需求|type|unstyled|depth|inlineStyleRanges|entityRanges|data|92446|注释也是开发人员文档，单元测试是如何“快速入门”的示例;-)|92447|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

tests (feature and integration) are more important than requirements; if you can specify the tests then you have also specified the requirements, at least implictly

comments are also the developer documentation, with unit tests being the how-to 'quickstart' examples ;-)

blocks|key|4157818|text|不确定需求是指人工制品还是过程。虽然可以跳过需求作为工件，特别是对于较小的团队，但仍然可以交付产品，但跳过需求作为过程是不可能的。作为人工制品的需求让你以比构建整个事情更低的成本对系统进行建模，做可行性，评估，并为一个更大和更分散的团队减少沟通开销，并在脚下有一个共同点。忽略需求，你会得到很差的估计(不管你是提前计划了很多还是只做了一个简短的冲刺)，对可行性的想法很差，可能会非常低效的沟通和大量的错误沟通。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4157819|另一方面，需求作为一个过程将会存在，无论它是否被正式承认。你不能真的排除它，你可以假装需求过程不存在，或者集成到设计、编码、测试或直到试运行和维护的阶段。显然，以这种方式对待进程意味着它不会得到公平的关注和资源。后果通常包括:交付一些最终无用的东西，不得不在开发周期的后期修复产品现在明显的缺点，甚至一旦产品在现场失败，就必须发现真正的需求，增加开发成本，在最后期限违约，破坏团队的良好声誉，破坏用户信心等。|4157820|测试通常归结为验证和验证，最近测试技术的改进让自动化测试成为实现更高调试效率和减少回归测试所需时间的可靠工具。验证是确保团队构建了正确的产品，即范围内的需求是正确的，不是矛盾的，没有差距。另一方面，验证是确保产品是正确构建的:没有技术缺陷、意外错误等。|4157821|正如我们所看到的，在需求被忽略的情况下，测试提供了一个安全网。通常，当团队开始测试时，他们需要改进对需求的理解，并因此修改软件。由于需求工件和软件本身在对现实生活问题的解决方案进行建模时都代表了不同级别的保真度，而软件作为模型在数量级上更精确，所以应用程序的测试也会评估需求(无论它们是隐含的还是显式的，是正式分析的还是非正式交流的)。|4157822|通常，测试的替代方案是让用户报告更多的缺陷和缺点，并尝试将其作为维护的一部分进行修复(意味着在产品生命周期的后期)，从而增加每次修复的成本。|4157823|那么需求与测试呢？解雇经理。好吧，如果你想在测试阶段错过项目进度，让自己陷入构建的混乱而不是用户需要的东西，那么跳过需求，如果你只是需要对用户表现出完全不尊重的话，跳过测试。|4157824|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

Not sure if the requirements are referred to as an artefact or as a process. Although it is possible to skip requirements as artefact especially for smaller teams and still deliver a product, skipping requirements as process is out of question. Requirements as artefact let you model the system at cost lower than building the entire thing, do feasibility, estimates, and for a larger and more disperse team to cut communication overheads and have a common ground under the feet. Neglect the requirements and you get louse estimates (regardless if you plan a lot up front or just do a short sprint), poor idea of feasibility and possibly very inefficient communication and a lot of miscommunication. 

Requirements as a process on the other hand is going to exist regardless if it is formally acknowledged or not. You cannot really exclude it, you can pretend requirements process does not exist or integrate into the design, coding, testing or into stages as late as pilot and maintenance. Obviously treating the process in this way mean it will not get fair amount of attention and resource. Consequences normally range from delivering something that is ultimately useless to having to fix the now obvious shortcomings of the product later in the development cycle or even discovering the real requirements once the product fails in the field, increasing the cost of development, defaulting on the deadlines, ruining team’s good name, destroying user confidence etc.

Testing usually boils down to validation and verification, more recently testing technology improvements let automated testing to be used as a solid tool for achieving greater efficiency in debugging and reducing time necessary for regression testing. Validation is making sure that the team has built the right product, i.e. scoped requirements are correct, not contradictory and there are no gaps. Verification on the other hand is making sure that the product is built right: no technical defects, accidental errors etc. 

As we can see testing provides a safety net in the scenario where requirements were neglected. Normally as the team starts testing they need to refine their understanding of requirements and as a result modify the software. Since both requirement artefacts and software itself just represent different levels of fidelity in modelling a solution for a real life problem, and software as a model is order of magnitude more precise the testing of application evaluates requirements as well (regardless if they are implicit or explicit, formally analysed or informally communicated).

Normally the alternative to testing is to let users report a substantially larger amount of defects and shortcomings and try and fix them as part of maintenance (meaning later in product lifecycle), increasing the cost of every fix.

So requirements versus testing? Fire the manager. Ok, skip requirements if you want the project schedule slip during the testing phase and get yourself into the mess of building not what users need, skip the testing if you just need to show utter disrespect to your users.

blocks|key|4157851|text|没有需求，你就不需要测试，因为你最终得到的正是规范|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4157852|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Without requirements you don't need testing since what you end up with is exactly what was spec'd

blocks|key|4157961|text|有一些类别的软件可以在没有需求的情况下开发得很好，至少比一封电子邮件长度的模糊表达的想法更好。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4157962|问题是，如果你有一个特定的客户和项目经理，你的软件不太可能在其中之一。不太可能有人特意付钱给你，让你说，‘让我玩一个玩杂耍的猴子的有趣游戏’。|4157963|唯一不需要测试就可以开发的软件类别是failware:无论软件是否正常工作，您的公司都会设法吸引一些客户付费(或者如果您有一个非常愚蠢的客户，则在支持和维护方面支付更多费用)。|4157964|这可能更有可能:成功比失败更有利可图的合同结构仍然相当普遍。如果你认为是这种情况，并且你想要开发工作软件，那么考虑换一份你的兴趣和你的老板之间的冲突较少的工作。|4157965|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

There are categories of software that can be developed perfectly well without requirements, at least anything more than a vaguely expressed idea the length of an email.

Thing is, if you have a specific client, and a project manager, it is unlikely your software is in one of them. It's unlikely someone is specifically paying you to, say, 'make me a fun game involving a juggling monkey'.

The only category of software that can be developed without testing is failware: where your company has managed to sucker some customer into paying whether or not the software works (or if you have a really dumb customer, pay more if it doesn't work, in support and maintenance).

That's probably more likely: contracts structured so that success is less profitable than failure are still fairly common. If you think that's the case, and you want to develop working software, then consider switching to a job where your interests and your bosses are less opposed.

blocks|key|92682|text|在没有需求的情况下，我们可以制定测试计划吗？所以即使我们选择测试而不是需求，我们也不能做测试。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|92683|因此，即使您考虑敏捷测试环境，也应该优先考虑需求。|92684|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Without Requirements can we make a Test Plan? So We Cant do Testing even if we pick Testing instead of Requirements. 

So Requirements should be Priority even if you consider Agile Testing Environment.

If you had to do without one or the other in a software project, which would you pick?
I've had plenty of projects in which the client or PM thought they could get away without one or the other. We always paid the price.

Requirements or Testing?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

如果你必须在软件项目中选择其中之一，你会选择哪一个？我有很多项目，在这些项目中，客户或PM认为他们可以在没有其中一个的情况下逃脱。我们总是付出代价。

问需求还是测试？
EN

回答 12

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问需求还是测试？EN

回答 12

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问需求还是测试？
EN