下载掌阅APP，畅读海量书库
立即打开
在不同的项目团队中，测试团队的具体分工或者职能可能会存在一定的差异，但是整体的职能划分一般都是相通的。本节我们主要介绍SSD测试团队的主要职能。
毫无疑问，SSD测试的首要目的是确保产品能够符合质量标准。在此基础上，其他未包含在测试需求中但却又合理的需求，也需要视具体情况进行测试覆盖。
一般来讲，项目经理会在项目开始之初拉着市场（或者业务）、开发、测试等部门联合制定具体的测试需求。但是对于多数团队，现实情况更多可能是市场或者业务部门讲不清楚他们具体需要的是什么，他们更加倾向于先由研发团队提出参考意见再从中作筛选。所以，作为一个专业的测试团队，我们需要具备提出具体测试需求的能力，甚至是主导并制定测试需求的能力。
此外，对于一些“异常”的测试需求，我们也需要谨慎对待。举个具体的例子：我们都知道NVMe的命令处理是“不保序”的，也就是说盘侧并不会保证先下发的命令一定会先完成。因此，协议会推荐主机确保下发的命令主动规避连续的读写命令存在逻辑地址重复的情况。于是，有的测试部门理所当然地规避了这种测试场景。正常来讲，这是合情合理的。可惜的是，我们的产品部署在客户那里，而这个场景可能触发一些致命性的问题。所以说，要特别谨慎对待一些看似合理的“规避”行为。
对于一些协议上讲得模棱两可的地方，我们需要小心对待相关的测试需求。如果存在对应的竞品，那么我们可以参考竞品的处理方法；如果没有，那么尽量去和市场或者业务部门沟通以达到大家都认同的结果。
有了明确的测试需求，接下来测试团队就可以制定相应的测试策略了。这个没有什么捷径，我们需要按照实际情况制定可执行性强的策略，比如参考项目整体交付时间、测试团队资源情况和开发团队的交付周期等制定策略。
测试策略是一种根据软件质量标准和测试规范制定的测试计划。我们会依据被测试对象的具体特性和实施的客观因素，结合多种类型的测试策略来确保软件的质量。
具体来说，SSD项目的测试策略通常包括以下几个方面。
● 测试范围 ：明确要测试的功能、模块和系统。正常来讲，开发测试团队和生产测试团队的测试策略不会相同，因为这两个团队的测试范围本来就不一样。
● 测试角色 ：定义不同测试团队成员的角色和职责。在一个项目周期内，推荐每个模块的测试负责人相对固定。如果团队人力充足，则强烈建议建立完善的人员备份机制。
● 测试方法 ：针对SSD的不同模块，选择合适的测试方法，例如白盒测试和黑盒测试等。
● 测试工具 ：选择适合项目的测试工具、测试驱动，以提高测试效率和自动化率。
● 测试层级 ：确定测试的不同层次，例如单元测试、集成测试和系统测试等。据我们了解，国内的SSD团队很少有做单元测试的，只有少数团队在做核心模块的单元测试。对于单元测试，我们比较推荐在开发团队落地或者由开发测试团队共建。
● 测试类型 ：根据需求选择适当的测试类型，例如功能测试、性能测试和安全性测试等。对于功能测试、性能测试，不必多说，SSD团队基本都知道要做。但是有些团队对安全性测试并不重视。这里，我们强烈建议大家把安全性测试好好落地。
● 验证环境 ：准备与客户实际环境相似的测试环境。
● 风险和处理方案 ：识别潜在的风险并制定相应的应对措施。一般来讲，新的功能、新的组件（存储介质、主控芯片等）都可能引发高风险，我们需要针对这些制定应对措施。
● 测试指标 ：定义衡量测试质量和进度的标准。
● 测试可交付成果 ：定义测试过程中需要交付的文档和报告。
一般来讲，测试策略并不是一直不变的，它会随着项目的推进而变化，我们就需要相应地刷新测试策略。
测试研发并不是测试团队自己的事情，我们需要拉通开发团队一起交付项目可用的测试脚本和工具。
在实际SSD项目研发过程中，测试团队还需要考虑配合开发团队的具体周期安排，来提供匹配的测试集。例如，开发团队一般会选择先把基础IO功能打通，像垃圾回收之类的高级功能可能要排在后面，那么测试团队就需要注意按照实际项目需求提供相应脚本。
此外，测试研发并不单单是脚本开发，它还包括相应的测试设计、测试联调等一系列动作。测试团队需要确保交付的测试脚本是实际可用、可执行的，我们需要尽量避免过多的脚本问题。
对于脚本语言，我们没有过多的推荐。无论是当下比较流行的Python，还是C或者Shell，基本都能够满足测试的需求。对于脚本语言的选型，我们可以思考一下哪种语言能够更好地与测试驱动、测试工具相结合；哪种语言能够更好地解决代码维护等问题；哪种语言更加符合团队的实际代码能力情况。
测试设计，一般是指测试用例的设计。所有测试的设计依据，一定来源于产品需求以及具体固件的设计。我们首先需要保证的是具体SSD行为是符合产品需求的，然后才是按照详细固件设计情况进行测试用例的设计。
测试联调，一般是指测试脚本与对应固件版本的联合调试。一般我们会在独立分支上进行联调，确保适配没有问题后再同步更新到各自的代码主分支上。如果测试团队单方面进行了测试调整，我们建议要跟开发团队同步好信息，避免无效或者错误的调整。
测试执行是项目质量保证过程中非常重要的一个环节，我们需要确保测试能够顺畅地执行。无论我们的测试设计得多么完美，测试脚本实现得多么漂亮，如果没有顺畅的测试执行流程来支撑，都无法产生完整的测试结果，那么所有的测试设计、测试实现都会变得毫无意义。
对于SSD研发过程中的测试，挂盘是家常便饭，而这会严重影响测试的顺利执行。不幸的是，这可能是所有SSD研发团队在测试中都会遇到的问题。为了解决这个问题，要么我们能够准备足够多的测试环境，以量取胜；要么我们能够构建一套恢复挂盘的机制，确保挂盘能够恢复并重新加入当前测试流程。
测试质量评估是指评估整个测试过程及其结果的有效性、准确性和可靠性的一种活动。它主要通过对测试过程中的各种活动进行监控、检查和审计，以及对测试结果进行比较、分析和评价，来确保软件产品的质量满足预定的要求。
测试质量评估通常包括以下几个方面。
1） 产品需求的覆盖情况 ：确认测试是否全面地覆盖了所有产品需求。
2） 缺陷检测能力 ：查看已发现的缺陷数量及严重程度，判断测试是否能有效发现产品存在的问题，对于遗留问题需要明确给出相应的风险评估结果。
3） 测试覆盖情况 ：具体如下。
● 功能测试 ：验证SSD的所有功能是否正常工作，如数据传输、数据保护和节能模式等功能；“白盒测试”则关注诸如垃圾回收、磨损均衡等固件内部功能模块。
● 性能测试 ：衡量SSD的性能，包括顺序读写速度、随机读写速度和延迟等；如果有对接的业务场景，我们也需要给出具体业务场景下的性能数据。
● 稳定性测试 ：通过长时间运行，看SSD是否稳定可靠。
● 兼容性测试 ：测试SSD与其他硬件、软件之间的兼容性，包括主板、CPU、内存和操作系统等。
● 数据安全测试 ：检查SSD的数据保护机制是否有效，能否防止数据泄漏或损坏。
● 负载压力测试 ：模拟实际使用场景，检验SSD在高负载条件下的性能和稳定性。
● 耐久性测试 ：长时间运行测试，检查SSD的使用寿命。