本文主要是介绍软件工程师小窍门，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
软件工程师小窍门
场景：三个软件项目的内部质量审核。这些项目大部分是基于Android或IOS使用Java。
参与者:开发人员(D),项目领导人(PL),测试人员(T),评审小组(A)
参考模型:敏捷软件开发,CMMI
由于大部分的问题都是其他软件开发公司的常见问题，您可能会发现，大多数评审小组的建议也可以应用于您的组织。
= ==
要求：
A: 你如何筹备收集和引出用户需求?例如你是如何计划的?
PL/D:我们没有需求计划。我们将在整个项目周期分配时间。
A: 你觉得如果需求计划涵盖了以下几个方面是否有帮助: 1)谁是被访谈者——名字和角色；2）参与人的角色和职责;3)必要的资源例如一个可用的旧资源，4)具体数据／时间
PL/D:我们会为每一次访谈中的讨论做记录。
A:团队访谈前最好事先做好准备，以减少遗漏重要点的风险。
A:你如何验证用户需求？
PL/D: 我们使用用户需求规范文档草案的模拟屏幕和原型。
A: 因为客户/用户缺乏IT背景，他们可能难以理解需求规范文档。建议用场景的形式来验证需求。
PL/D:什么是“场景”？
A:例如，作为用户，我希望通过网络系统订一张11月20日（5天后）上海到深圳的机票。当你简要介绍这个场景的时候，你和团队可以在系统已经开发的情况下，通过屏幕演示给用户。你就能马上了解到认识上的误差。这不只是使用平常的情况下。特别用在特殊情况下，那些通常都会被你的开发团队的误解的场景上。
A:你知道这个需求来源（指向列表中的要求）？怎么用？
PL/D: （试图找到相应的会议记录）我确信我在会议上做过记录，只是现在找不到了。本周晚一点交给你好吗？
A: 假若你为你的的需求和资源做了一个需求跟踪矩阵，这个问题你2分钟之内就能回答出来。同样的，做一个映射到测试用例的表格，可以确保所有需求都能被测试。没有测试的情况下，没有对应任何要求。
A:你是怎么做需求检查的？
PL/D:我们用评审检查表。
A:在技术评审中你主要检查什么？
PL/D: 评审检查表是否完整和恰当,…。(指的是需求评审检查表)
A: 此外,你至少应该检查:可追溯,可检验(测试),可唯一识别、一致性等。
设计和实现：
A:如何确保你的代码质量和可复用性？
D: 因为我们缺少时间,所以没有做单元测试。基本依赖于代码评审自动化工具来检查。
A:代码评审不能取代单元测试。可以使用代码的检讨，找出缺陷，第一，但你还是要运行测试，以确保代码是好的。如果你没有一组测试，以确保质量的代码，这将是非常困难，当你试图改变或重构未来的软件。那是因为你不会知道是否改变或不改变程序的其他功能。当你制定了一套完整的测试案例，你会只是通过这些测试运行后再次重新设计。在敏捷或极限编程中，我们强调编写测试用例之前，先编程[测试驱动开发（TDD））。这是同样的想法。
关于测试：
A: 你是怎样准备系统测试？
T: 对于每个功能需求，我们写一些测试用例，执行测试。如果我们发现任何错误/缺陷，我们将其报告给开发人员纠正。
A: 在这个测试案例，它只是说“输入用户名“，你不指定将测试输入。如果开发商想重新运行测试，他们怎么会知道？
A: 准备测试用例仅仅是测试计划的一部分。测试计划应包括资源，测试环境，退出标准。你应该想一想，用什么样的措施来收集这些测试以及这些措施的目的。这篇关于软件工程师小窍门的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
