从测试人员的角度来看，开发人员应使用哪些测试程序理想情况下，在将项目签署给要进行测试的质量检查小组之前已经过？
显然，这将取决于所采用的开发方法，因此基于不同方法的不同答案将是极好的。我不想踩任何东西，但同时我也不想传递完全未经测试的代码。
根据我的第一句话，我应该在以下方面加强我的知识吗？此字段？
#1 楼
尽管单元测试通常足够好，但是很高兴看到开发人员确保他们已经从头到尾运行了一个过程，而不仅仅是单元测试。由于应运行的测试类型随应用程序类型的不同而有很大差异，因此我将与产品的测试联系点进行讨论。对于我来说，有了新开发人员，我通常会问他们是否愿意在未经质量检查测试的情况下在生产环境中安装该软件，并对任何缺陷负责（从不认真对待）。这往往使他们想到我什至没有想到的测试类型！
评论
只要您与开发人员有这种关系，那就是一个非常好的问题。
– CBA
2011年5月11日12:06
似乎对这个问题回答“是”的那种人是做软件开发人员的那种错误的人。我将无法完成整个质量检查团队可以完成的测试工作。我会在通过测试之前进行测试，是的，但是我不希望在通过更严格的测试之前将其发送到生产环境。
– Ed Marty
2011年5月11日17:03
我不能说我不同意你的爱德。但是，我要提出的观点是要确保开发人员已经对其进行了测试，并且可以合理地确定它可以正常工作，然后再要求将代码提升到测试环境。
– Lyndon Vrooman
2011年5月11日17:11
我通常会为应用程序提供一次快速浏览，检查所有功能（至少在快速运行时）是否按我的预期工作。我不会梦想传递至少未经我自己进行过单元测试和验证的任何代码！
–卢克
2011年5月13日在9:20
#2 楼
对我来说，行之有效的是以下步骤。开发人员尽最大努力编写好的代码。
开发人员从另一位开发人员那里获得了代码同行的评价
开发人员运行其单元测试，并检查它们是否全部通过。
开发人员和测试人员坐下来进行审查：
开发人员逐步通过测试人员让他们进行测试知道要交付的内容，任何相关的更改以及尚未完成的任何区域，以便不在这些区域中记录错误。
测试人员将对他们为该功能编写的测试进行测试。这使开发人员可以审查测试并确保它们有意义。
测试人员需要几分钟来执行一些高级测试，并与开发人员一起逐步完成该功能。任何明显的错误都将在现场修复，而无需将其记录在系统中。
在完成检查后，开发人员将检入
，然后测试人员会在第二天的日常构建。
尽管在纸面上看起来似乎很繁重，但我们发现它在清除和解决许多明显问题方面确实非常有效，因为我们没有碰到过，缺陷跟踪系统，从长远来看可以节省每个人的时间。
评论
我毫不怀疑这种方法的好处。我确实怀疑管理层批准这种“非生产性”时间的想法。我知道我知道。它根本不是非生产性的，但似乎是表面上的，这是管理层所要考虑的。 :(
–corsiKa♦
2011年5月11日下午14:04
我不同意glowcoder，在查看代码是否完成时，我已经在敏捷商店或Scrum团队中看到了这项工作。在构建版本并对开发人员进行“采访”时，我什至在小型团队中进行了测试。
– MichaelF
2011年5月11日在14:17
我要做的一个更改是将步骤4设为步骤1。首先对计划进行审核。这使开发人员可以构建可测试性功能，并帮助测试人员避免编写无用的测试或丢失测试的关键区域。编码后进行审查可能也不错，但我认为进行预审查更为重要。 @glowcoder，经过我提到的修改，我们在（小型，敏捷）团队中进行了此操作，我也在Microsoft（大型，分支与合并）中看到了这一点。两者都聘请了具有高级开发人员经验的管理人员，这似乎很关键。
– Ethel Evans
2011年5月11日下午16:45
@Michael我并不是说这没有效果。我说的是告诉管理层这是一个好主意，因为它不会“看起来”富有成效，所以不会顺利进行。我知道是的，您知道的是，但他们是有资金和批准印章的人。 @Ethel我们也有负责管理的高级开发人员，但我认为问题在于他们是这里的开发人员，因此没有所谓最佳实践环境的经验。
–corsiKa♦
2011年5月11日在16:49
如果它显示的正确，它可以顺利通过，其他环境可能比您自己的环境更容易接受。
– MichaelF
2011年5月11日20:18
#3 楼
对于开发人员在进行质量检查之前应该进行哪种测试，没有严格的规定。这取决于开发人员，质量检查团队，组织和产品。测试是达到目的的一种手段，而不是目的本身。重要的是要注意质量检查所收到的质量和发布产品的质量。如果这两个时间点的质量都不是您想要的质量，则您的组织需要查看问题所在。问题可能出在编写大量错误的特定开发人员身上，但也可能是例如脆弱的第三方程序包或含糊不清或不稳定的一组需求。
根据经验，这是开发人员在进行质量检查之前应测试的优先事项列表：
该产品仍在构建。
该产品仍在安装。
/>冒烟测试通过，即产品中对最基本的测试类型必不可少的部分仍然有效。
最积极的显而易见的测试用例（无论可用定义如何）都可以正常工作。换句话说，如果您只是尝试使用该产品，它应该可以工作。
否定测试用例都可以工作。换句话说，如果有人试图破坏产品，他们就不会这样做。
#4 楼
我还是开发者同行评审的坚定信念者。自从在我的工作场所采用这种方法以来，工作质量大大提高了。同行评审提供的新视角通常会寻找更有效的方式来编写代码或发现本来会被遗漏的错误。这总是存在可用资源/大小的问题。该项目;一个小团队可能无法有效地对所有新功能进行同等审查，而同时又无法维持其正常的工作流程。
听起来还很明显，我鼓励您将所有的更改告知测试人员对您的代码进行修改（无论大小如何）。实施新功能的次数无数次，但是由于相关工作项目从未更新过足够详细的细节，因此我不知道新功能的存在。直到我在探索性测试期间偶然发现它时。
如果您的测试人员进行了大量的自动化测试，这尤其重要（因为最小的更改会导致这些测试开始失败） 。
评论
另外，让您的测试人员知道修改的代码是否被应用程序或集成的另一个应用程序中的其他任何地方调用或使用。我见过几次对变量的简单更改似乎破坏了完全独立的功能。
– Lyndon Vrooman
2011年5月11日14:31
#5 楼
这实际上取决于项目的复杂性，团队的规模和集成的难度。单元测试。每个人都知道这一点，但是重复一遍并没有什么害处。运行您的单元测试，以确保您的代码仍然可以执行预期的工作。对于使用不需要编译的代码的开发人员而言，这尤其重要（我正在寻找您，应用性DBA）。
集成测试。只要一个项目有两个以上的开发人员，就需要集成。您不会相信当一个开发人员在不通知另一位开发人员的情况下中断界面时，我已经破坏过多少次构建。这些通常也很容易实现自动化，因为它们只涉及对单元测试的快速回归检查。
烟气测试/初步验收。这些是开发人员在构建后进行的快速（15分钟）测试，以确保构建足以进行质量检查。对于这些，我知道的最佳策略是让QA编写它们并进行开发以执行它们。这样，没有人可以抱怨其他人，从而减少了浪费时间的感觉。这些通常是针对每个功能完成的，您只需测试更改的内容即可。
自动回归测试。另一个想法是在每晚构建之后立即进行自动测试。该测试将新版本的结果与已知的良好版本进行比较，并报告任何差异。我们在0300运行该版本，在0430进行该测试。这样一来，当您进入办公室时，您会得到等待的结果。
这些通常应向QA提供良好的版本，这往往会改善工作关系以及其他优势。
#6 楼
在我的组织中，我们尝试在编写任何代码进行讨论之前让开发人员和测试人员坐下来，因为对于您实现的每个功能，答案可能会有所不同。单元测试是一种在我的团队中给出的-但通常，测试人员和开发人员也将预先自动化GUI测试。这样，当功能传递给QA时，将测试核心业务逻辑-让测试人员进行探索性测试。
#7 楼
开发过程应包括作为可交付的，编写良好的单元测试的一部分，该单元测试应随软件进入质量保证周期。最好将持续集成服务器配置为在质量检查测试构建完成后运行单元测试。#8 楼
这取决于。如果您的过程是轻量级的（例如Scrum），那么连续构建，自动化测试等就足够了。如果您的过程很重（例如瀑布），并且开发和测试组织之间存在隔离/缓慢，那么您可能希望自己进行形式化的手动测试，以免成为瓶颈。除了自动测试（单元，集成，UI自动化，如果可能的话）之外，您还应该使用生产部署过程在类似生产的环境中部署软件。
部署后，运行一些冒烟测试针对重要和/或高风险的组件。然后，让每个开发人员验证其错误修复和功能添加。更好的是，让开发人员B测试开发人员A的工作，反之亦然。
#9 楼
我们让开发人员通过进行构建并将其部署到开发环境中来测试其代码，并验证他们在新环境中的功能。如果构建中还有其他更改，则需要与其他人员协调以确保测试已完成。在其他环境中，开发人员会写出简单的计划并相互转换，以便每个开发人员都在测试他们未编写的代码。至少您应该做的事情足以验证在质量检查环境中启动时该构建不会崩溃，从而使他们不会浪费时间安装无法正常工作的构建。#10 楼
所有这些建议都很棒。我只有要补充的东西。如果在1个平台上修复了错误，由于有时代码会与其他平台共享，请也测试其他平台以查看该错误是否存在。特别是与客户的错误。#11 楼
开发人员应绝对确保软件： in）单元测试通过
如果其中任何一个失败，那么就没有理由继续进行进一步的测试。自动化的“烟雾测试”，通过基本功能运行，并验证在通过系统的所有公用路径时是否没有重大错误。如果存在这种冒烟测试，则在将构建移交给质量检查团队之前运行它也很有意义。
#12 楼
进行功能测试以外的功能，尤其是在使用Web应用程序时。SQL注入
XSS
安全模块（http vs https，标头注入，cookie劫持）等
还确保客户端代码在如果您的环境允许使用多个浏览器，则可以使用多个浏览器
使用Java开关进行测试
如果需要，请测试508节
测试缓冲区溢出
测试应用程序崩溃时是否将其遗留不安全的状态
除了功能以外，开发人员还应该关注很多事情（但请确保您对功能进行测试）。
功能测试器可能不会运行如果他/她仅对是否有用感兴趣，则查找更严重的错误。
#13 楼
无论我们是开发人员，业务分析师，产品所有者还是最终用户，我们每个人都是质量检查人员。在开发过程中，您必须既是开发人员又是质量检查人员。在产品开发的每个级别，涉及到的每个人都需要质量控制。向质量检查小组了解您可以采取的措施；通过在线文章和课程对其进行自我教育（顺便说一句，单元测试远不及最终用户在现实世界中的实际操作）。您必须处理发送给最终版本的最终版本质量检查团队似乎是最终的生产团队，并对此负有全部责任。
#14 楼
除了单元测试之外，请检查您的功能是否满足书面要求。如果书面要求已经过时，请确保您的产品经理和质量检查人员知道它。不正确或直截了当而被遗弃。如果开发人员只是要构建自己想要的东西，而产品经理只是要跟上它，为什么还要麻烦QA手动测试呢？我宁愿花时间使回归测试自动化。如果没有书面要求，对于Linux爱好者，请在某个地方写下一些内容。您可以对质量检查工程师进行口头表达，但最终可能会重复自己。只需在电子邮件或Wiki页面上写下基础知识，或者在展示功能时与质量检查工程师一起创建文档。可测试的。例如，如果该功能应在某些情况下以某种方式起作用（例如，关闭邮件服务器），请找到一种可访问的方式来模拟这种情况。将其构建为编程工作的一部分。
#15 楼
有3个好友。
3个好友（如果您不知道）是一次会议，业务分析师提出了业务需求以及测试场景（统称为“功能”），以供审核开发团队的成员和质量保证团队的成员。
这有助于在他们三个人之间建立共识。
请确保您根据此共识理解开发功能并涵盖这些内容测试方案作为最大程度地进行单元测试的一部分。
我发现这对在开发人员和测试人员之间进行公开对话非常有用，有助于在单元级（开发人员）和集成/端到端测试级（测试人员）。
评论
这些都是出色的答案，非常感谢大家！相关：sqa.stackexchange.com/questions/54/…
10,000票赞成，并衷心感谢您首先提出这个问题。一些开发人员认为测试是不重要的，是“别人的工作”。实际上，当每个人都在整个过程中努力思考质量时，才能制造出最好的产品。以我的经验，最好的开发人员是在将代码传递给质量检查人员之前对其进行全面测试的人。