到了上世纪80年代初期，软件和IT行业进入了大发展，软件趋向大型化、高复杂度，软件的质量越来越重要。这个时候，一些软件测试的基础理论和实用技术开始形成，并且人们开始为软件开发设计了各种流程和管理方法，软件开发的方式也逐渐由混乱无序的开发过程过渡到结构化的开发过程，以结构化分析与设计、结构化评审、结构化程序设计以及结构化测试为特征。七，妥善保存测试计划、测试用例、出错统计和***终分析报告，为维护提供方便。

“你们是如何测试软件的？”

理想情况下，验证代码质量应该是单元测试、人工测试以及自动化测试的结合。

***信号：“我们都写不出 bug，哈哈。” → 那些人正是会写出 bug 的人。

　“你们使用什么样的版本控制系统？”

版本控制系统对于协作极其有用，在职业环境下没有理由不使用。

***信号 #1：“额，版本控制系统？” → 快跑，跑得越远越好。

永远记得使用版本控制。

***信号 #2：“lt;插入不的或者定制的 VCSgt;” → 这表明他们很有可能没有跟上时代并且很久没有升级自己的基础设施了。

您的数据事务是基于什么？或者，您需要什么级别的事务支持？如果您的系统需要ACID属性，那么您很好还是坚持使用RDBMS解决方案。否则，您将花费大量的时间试图在您的应用程序/业务逻辑层重制ACID保证，并且您可能仍然没有RDBMS解决方案那么。#3: 您需要Web/高可伸缩性吗？测试原则一，测试应该尽早进行，好在需求阶段就开始介入，因为***严重的错误不外乎是系统不能满足用户的需求。总是在先计算出您需要什么样的可伸缩性。在这个特殊的例子中，我们正在为微软内部游戏工作室构建系统。有10到15个游戏工作室正在考虑中——这取决于有多少注册用户使用这个系统每个工作室多有3-5个活跃的游戏标题。每个游戏标题为三个环境存储遥测模式——开发、预生产（PPE）和生产对于每个标题，将会有2-5个数据科学家同时修改游戏标题数据每一个标题事件都有大约50 KB的max事件数据我们被要求存储所有的版本——我们估计这个数字是1000除以一个标题的生命周期有了以上粗略的估计，我们就可以计算并发性和存储需求：

总并发数 = 工作室数量 * 标题数量每工作室 * 用户数量每标题

= 15 * 5 * 5 = 375 并发用户

大存储 = 工作室数量 * 标题数量每工作室 * 环境数量 * 事件存储大小每版本* 需要存储的版本数

= 15 * 5 * 3 * 50 KB * 1000 = 11250000 KB = 11.25 GB大存储

SQL Azure支持1024个并发打开连接，并且能够很容易地支持并发需求。另外，在考虑云计算时，11.25 GB实际上是一个非常小的数字。

这个系统并不是下一个FaceBook或必应——那么NoSQL的路线真的值得吗？