我公司的测试人员无法访问我们的应用程序的源代码，我们对版本控制存储库（git）的访问权限有限。
这是由于机密性和安全性所致义务-一般规则说，公司中的每个员工都应仅具有对完成工作必不可少的资源（信息，系统等）的访问权限，但对与工作无关的信息的访问应受到限制。
有人认为测试人员不需要访问源代码即可完成工作。很久以前，那时我们使用瀑布模型，因此质量保证团队与开发分离。但是现在我们正在过渡到敏捷，测试人员和开发人员现在合并到一个混乱的局面。
我已经与一些在其他公司工作过的开发人员讨论了这个话题，他们告诉我认为这是一个“奇怪的”规则，并且测试人员可以访问其他地方的代码库。
我将说服管理层放宽此规则，并至少给测试人员提供只读权限访问源代码，我正在寻找此更改的参数-以及是否存在任何潜在的不利因素或威胁？
我可以想象一些参数：
Tester可以进行代码审查并直接在代码中找到一些错误
Tester查看代码可以了解产品的体系结构，这有助于她设计更好的测试用例
Tester可以编写单元测试和集成测试而不是开发人员
深入了解代码可以帮助测试人员更好地诊断错误
测试人员查看代码可以提出一些建议使UI自动化更容易的更改
Tester可以支持开发人员并进行同样的细微更改，从而使开发人员可以专注于更复杂的事情
...
还有什么？
#1 楼
我个人认为，Pro
通过允许测试人员访问源代码以及全面的测试技术（例如MC / DC测试），可以进行白盒测试，可以应用条件决策测试。
您可能需要考虑的问题：
每个测试人员都可以与您一起阅读源代码吗？如果他们能够阅读源代码，他们是否愿意？如果您恰好是愿意承担额外责任的少数测试人员之一，那么访问源代码将不会产生深远的影响。
所有测试人员都可以正确进行代码审查吗？
代码审查需要长期还清股息，您的管理层期望短期收益吗？您的管理层了解技术细节吗？您的管理层是否愿意等待看到长期的收获？
您的管理层在授予您源代码访问权限后将在寻找重大的收获，他们所承担的风险是机密性。如果过一会儿没有取得重大进展，您的管理层可能需要向他们的管理层回答有关授予源代码访问权限是否是正确的决定？如果发生这种情况，您和您的管理层将有失去信任的风险。
您提到我已经与一些在其职业生涯中为其他公司工作过的开发人员讨论了这个主题，他们告诉我这是一个“奇怪的”规则，测试人员可以在其他地方访问代码库。请记住，这是他们在一次也许很随意的交谈中的意见，他们所服务的公司可能没有您当前公司的机密。我认为这不是应该考虑的有效因素。结论：
您的方法是提高软件和您的整体质量积极寻求新方法。这正是QA的目的，做得好！
在没有访问源代码的情况下，QA仍然可以通过很多方法执行测试。
超出您的预期的是，大多数公司更有可能将源代码访问限制为仅需要了解的基础。
#2 楼
为了回答这个问题，我认为最好先研究一下为什么设置了代码访问限制。它是财务软件这一事实是有道理的。通过最大程度地减少对源代码的暴露来最小化安全漏洞的风险非常重要。这可能不是最好的方法，但是如果在暴风雪中，您不需要旅行，不要这样做，则可以最大程度地减少道路上可能发生的事故。关于如何与公司进行对话以使测试人员可以访问源的要点：
同意并非每个测试人员都需要访问代码（任何黑匣子类型的测试角色）
公司领导需要数据和统计数据来说服他们通常进行的任何事情。分析在开发和发布过程中遗漏的错误列表，并指出白盒测试可能发现的问题。
调查当今处于“测试中的软件开发”角色的人
，大多数从任何计算机专业毕业的学生都经过某种编码培训，并且能够从开发人员试图通过经验，很多问题，漏洞和新测试涵盖的功能中领会到任何想法。开发人员遍历代码更改时发现了一些案例
#3 楼
有权访问源代码的测试人员和进行代码审查的测试人员是完全独立的事情。测试人员通常不具备足够的技术能力，而且根据我的经验，甚至不是所有开发人员都可以进行代码审查。对应用程序源代码的读取访问权限对测试很有帮助，如果您能够阅读和理解代码。
您也没有提到您正在执行哪种类型的测试，这是功能性的黑匣子吗？
在这种情况下，如果您与开发人员保持联系，并要求他们向您提供更多有关他们实现的功能/功能以及他们如何设计工作原理的详细信息，您将受益匪浅。
这可能只是一个高水平的讨论，不一定是技术性的讨论。如果您从此开始，您将能够阅读他们的代码并理解其思维方式，而无需实际查看他们编写的源代码。
希望有所帮助。
#4 楼
当然，测试人员应该可以访问开发人员编写的代码。在敏捷开发中，测试应该是并行活动。如果您有专门的测试人员，他们应该能够在开发过程中添加自动化测试，或者对构建进行探索性测试，他们可以通过代码自行构建。
引用Less框架：
将测试与开发分离通常会导致程序员与测试人员之间发生冲突。测试人员（寻找错误）试图证明程序的部分错误。程序员-在代码中具有自我意识-可以保护自己，代码和程序。
在Scrum团队中，“测试人员”不再是测试人员，而是“简单”的成员
合作才能达到该目标。
在此处了解更多信息...
如果可以编程您需要在敏捷团队中访问代码，而无需进行讨论。您只有不这样做的缺点。
即使安全性对于拒绝访问也是半生半熟的优点。测试人员和开发人员在安全方面有何区别？如果他们坐在同一个房间里，无论有没有直接进入，他们都可以偷相同的东西。如果您确实愿意，可以很容易地访问某人的帐户并窃取其代码。例如，使用USB键盘记录器。
我还希望测试人员时不时地在开发机器上进行配对编程和配对测试。如果程序员上厕所该怎么办？
但是要在您的列表（已经很完整）上添加一些项目符号：
测试人员可以创建自己的构建并探索
测试人员可以是自组织的跨职能团队成员！
只需确保您不接受“这就是我们在此处始终这样做的方式”。
#5 楼
优点如果您正在测试安全性或其他关键代码，则您的测试要求将包括100％的代码和决策覆盖率-这通常是在没有实际代码的情况下无法实现的。 br />您无法测试的规范通常比实际代码更容易理解和窃取，因此，只有当您的代码具有实现规范中所包含内容的专有方法时，机密性才成为问题。
缺点
如果测试人员查看代码，则他们很可能会按书面形式对代码进行测试，而不是按要求对代码的功能进行测试。
建议
许多公司将测试团队划分为功能（黑盒），测试人员和覆盖率（灰盒），测试人员。划分可以基于技能集和对所包含信息的清除程度。
#6 楼
通常，我会尝试通过证明观点来赢得战斗，但是在这种情况下，为什么不尝试从另一端进攻呢？问“为什么不呢？”大多数大型软件我认识或工作过的公司并不限制对产品工作人员的READ访问源代码，并且很少有例外，例如将工作外包到远程站点或超级机密项目时。
您的经理可能尝试争论上述好的论据，不是因为论证有误，而是因为管理者习惯于保护自己的决定。
#7 楼
与很多问题一样，答案取决于。正如其他人指出的那样，根据所使用的方法（例如敏捷），可以指定源代码访问权限，因为测试和开发之间没有任何区别。因此，当然，如果您是敏捷团队的一员，是的，您应该可以访问源代码，应该参与代码审查，应该提交修复程序，等等。但是，需要权衡。您所谈论的测试类型称为白盒测试，即测试人员可以访问源代码，而黑盒测试则不能。而且，敏捷开发的前提是能够将所有内容分解为每个人都易于理解的小巧易用的部件，通常可以在组件级别，但不能在系统级别。
如果您在进行集成/系统/验收测试，则对整个系统的行为更感兴趣，而不是对单个功能更感兴趣。而且，如果您有权访问源代码，那么就会需要测试源代码，而不是API / spec，这是一种诱惑。作为集成/系统/验收测试人员，您无需担心各个功能的工作原理，无论使用任何规模的代码，都将无法完全理解它。您关心的是理解用例和预期的系统行为。
正如其他人所说的，有时会遇到信任或法律责任等问题。这些是业务决策，而不是技术决策。
#8 楼
“敏捷重视工作代码，而不是全面的文档”。如果测试人员没有全面的最新规范，则需要查看代码。如果测试人员无法准确了解每个规范修订版本中发生了什么变化，则需要对代码进行区分。
评论
“测试人员可以编写单元测试和集成测试来代替开发人员”，不是这样。最好由相同的编码器在代码之前或与代码并行编写，以获取全部好处。除此之外，您所描述的只是“测试人员” ==“专注于测试的常规程序员”。当然，那是最好的，我想这更多是您公司的传统问题。在我们所处的位置，测试人员和开发人员彼此分开。想法是开发人员在编写/测试时具有一定的心态，但是我们希望测试人员摆脱那种思维定式，以发现开发人员不会注意到的错误。理想情况下，测试人员将以与最终用户更相似的方式来接近产品。