代码结合文档提取测试需求方法的研究

罗文兵 徐海波 符号

摘要：测试工程师在开展测试工作时，对于专业背景强，规模大且复杂度高，文档质量参差不齐的被测软件，会出现对需求理解不准确、不全面、不深入等问题，导致测试效果差。文章阐述了通过阅读代码结合需求文档提取测试需求的方法，经过实践，能够有效提高测试工程师分析测试需求和发现问题的能力，把控软件测试质量。

关键词：代码;文档;提取测试需求

一、研究问题的提出

随着软件测试涉及的领域越来越广泛，对测试质量的要求逐步提高，测试过程需要更加注重测试发现问题的质量和测试用例的全面性与严谨性。部分测试机构因为项目领域广泛，项目数量多且项目周期短，测试工作经常采用短平快的策略来开展。但是面对核心项目的测试，当前粗放式的测试模式已不适用。核心项目的特点往往是专业背景强，软件规模大且复杂度高，涉及的算法多，对测试工程师来说理解需求及开展测试工作更为困难。面对多场景多流程的核心软件，测试工程师经常会出现对需求理解不准确、不全面、不深入的问题，由于对需求理解不到位继而导致测试内容及方法设计不合理、不充分、不规范、不易理解、缺乏可操作性，最终测试过程只能浮于表面，发现不了软件缺陷。

测试需求主要依赖输入文档，面对简单的软件，通过阅读输入文档基本能够理解软件的需求。面对核心软件，仅仅依靠非伪代码形式的输入文档中的文字信息，已不能覆盖复杂且专业的核心软件需求。同时委托方日益增长的软件质量要求与软件测试能力越来越不匹配。核心软件的共同特点为承担核心任务或关乎人员生命安全，对安全性可靠性要求极高。大多数核心软件是嵌入式软件且为C/C++语言编写。例如航天领域的卫星姿态与轨道控制软件、星务软件、飞行控制软件、导航软件等;航空领域的光雷系统控制软件、火控计算软件、HUD控制管理软件、AMFD主控软件等。这类软件通常没有人机交互和直观的屏幕输出，接口多样化并且与硬件关系紧密，时序要求高且存在多模式切换需求。当前在航空航天领域常用的1553B总线、CAN总线，FC网络、1394网络、RapidIO网络、PCIE网络等，都是专用的芯片和接口，需要用专业的仿真工具和方法进行测试。这些因素共同提升了软件测试的困难程度。

按照目前通行的测试模式，通过对任务书和设计文档、需求说明的分析之后开始编写测试大纲，接着设计测试用例，执行静态分析，最后进行动态测试和回归测试。这种模式的确可以完成两个输出成果物：测试大纲和测试报告，但测试内容也仅限包含需求和任务书中的内容。实际上因研制周期需要，目前有一部分软件的研发过程并不是严格按照软件工程化要求进行的。有的软件需求说明、设计说明等文档是在程序编码完成之后才匆匆按编程思路补充完成的，其准确性和全面性都较差。如果软件需求中漏写了某些功能，测试工程师通过测试发现的可能性较小，测试过程中有很大概率被遗漏。稍好一些的软件需求也仅描述了与该软件相关的指标及要求，具体的实现方式和细节并未表述清晰，测试工程师阅读后也是一知半解。如果遇上逻辑不清晰或文字功底不强的研发人员，软件需求中则会存在错误、歧义甚至误导，导致如果测试工程师不与研发人员进行深入交流很难理解正确的需求。项目任务书或者研制合同虽然准确性较高，但颗粒度很大，不足以支撑测试工程师提炼测试项。如果测试工程师基于这种劣质的基线去编写测试大纲必然是不准确和不全面的，更不可能深入，在后续的测试过程极有可能会发现理解的需求和实际情况相差甚远，再回过头去修改则费工又费时。很多情况下这些错误往往不会被及时修正，甚至会出现误改软件的情况。

二、研究思路及解决方法

（一）思路

针对提出的问题，解决思路是对核心软件引入代码结合文档提取测试需求方法。既然通过软件需求很难准确、全面、深入地进行需求分析，可以尝试通过结合代码直接去分析，寻找。根据软件文档进行需求分析就像医生给病人看病，如果病人本身就讳疾忌医，不把症状告诉医生，并不是每个医生都能准确找到病因。而结合代码进行需求分析就像法医尸检，不需要被检测方的配合，方法科学加上认真仔细即能找到死因。目前先进的测试机构均已初步开展文档结合代码进行需求分析的方法提取测试需求，这种方法的好处是在阅读需求时可以检查对应的功能在代码中是否都有支撑，代码实现的功能是否正确;在阅读代码时可以检查文档是否描述全面，需求描述是否准确，需求中描述不到的细节可以通过阅读代码去补充。通过参阅并结合二者即可以检查出需求和代码实现不一致的地方，在无需研制人员配合的情况下准确定位问题所在。在阅读代码的同时可以更深入地了解软件功能点，顺着程序逻辑时序更能了解软件流程，从而达到准确全面深入了解软件需求的目的，同时还能够发现一部分软件问题。

（二） 方法

在了解了结合代码进行需求分析的解决思路后，如何结合代码进行需求分析？经过研究及通过案例实践，大体可以分为以下几个步骤，如下图所示。

图1    结合代码进行需求分析的步骤

1.测试工程师取得软件需求和代码之后，首先仔细阅读软件任务书和需求说明等文档，把软件按照功能模块进行划分，同时梳理出软件内部模块间的关系、与外部的接口关系图，对整体结构能够有一个直观的认识。

2.在关系图上进一步标出所有的输入输出流，可以有效帮助测试工程师把握整体的数据流向。然后再进一步确认输入和输出的触发条件，是周期性的还是偶发的或者条件控制的。

3.以关系图为参考，使用源代码阅读工具打开工程代码进行代码阅读。

第一遍进行粗读，如果是单任务类的软件则从main函数入手，首先找到初始化部分然后找到主循环，顺着主循环中的顺序一路梳理到每个函数，知道每个函数的功能是什么，对应之前梳理好的功能模塊是什么，直到整个主循环结束。然后找到各个中断，再从中断函数入口开始依次梳理，同样知道每个函数的功能与需求文档的对应关系。粗读完之后会对整个程序架构有一个较为完整的认识，趁此时机梳理一下输入流是从哪个函数开始接收或采集的，输出流是从哪个函数最终发出去或设置的。如果是多任务类的软件则需要从主线程开始梳理，方法同单任务，但在梳理完一个任务之后需要依次梳理其他线程，最后梳理线程间的消息通讯。第一遍粗读完之后会对软件有一个较完整的认识，相当于摸清了一棵大树的树干和树枝。第二遍进行精读，即仔细阅读每一个函数，对应每个功能模块中具体的功能点，分析代码实现功能是否跟需求描述的一致。然后分析接口部分相关代码中输入流的接收处理是否跟协议中的规定格式一致，内容是否按照协议的约定进行排列。输出流的组帧方式、填写的内容是否跟协议中的规定一致。两遍阅读完成后对软件会有一个清晰的认识，丰富了整棵大树的树叶和花果。

4.通过以上结合文档阅读代码的过程，作为测试工程师，应该已经知道软件的实际需求是怎样的，如何实现的，包括对数据的来龙去脉也已经了如指掌，在此基础上提取测试需求和测试重点编写测试项则水到渠成，一般不会出现大的出入和理解上的偏差，更不会出现丢项漏项的情况。反过来还能给软件需求提出很多改进意见，这些意见是基于软件实际提出来的，而不是通过需求猜出来的，更有说服力也更具高级感。

（三） 实践

将研究成果在多个项目中实践，项目负责人或项目经理在开展测试初期，拿到被测件后可以采用此方法对软件实施分析，将软件真正的需求吃透后给测试工程师讲解，可以帮助测试工程师更好的理解软件，为后续编写测试大纲、测试用例提供很大帮助，整体提高软件测试质量。

例1，在某商用航天控制软件测试过程中，测试工程师在编写完测试大纲后，代码走查人员在检查时发现该软件最重要最核心的火箭点火功能和点火时序都没有测到，找漏测原因时发现软件需求中没有写明，仅在任务书中体现，故测试工程师遗漏了。后期通过代码阅读发现程序中存在多个函数对应火箭点火处理和时序处理功能，很容易就发现测试功能项缺失的问题。

例2，在某通信系统综合控制器软件的需求中漏写了代号设置等多项指令设置功能，在初期测试需求中也自然遗漏了这些功能，但通过结合文档进行代码阅读最终发现了遗漏项并进行了补充。

這样的案例还有很多，包括需求描述不准确或需求与程序实现不一致等等问题，通过阅读代码的方法很容易就能准确找到。代码粗读的时间成本并不大，磨刀不误砍柴工，5000行左右的代码对于成熟的测试工程师来说粗读需要的时间也就1天，但可以节省下很多猜测需求实质，咨询需求如何实现，反复修改测试需求的时间。

测试工程师在软件需求文档质量差或需求不易理解的情况下，也可以通过代码结合文档的方法引导进行测试。针对核心软件，研制人员在软件开发过程中一般都比较谨慎，软件质量较高，且经过研制方的内审和所检等多轮内部测试后才会交由专业测试机构进行测试。测试工程师在不深入了解软件的情况下很难发现问题，在动态测试效果不佳时，可以采用代码精读法，从代码结合需求的角度进行突破。代码精读的时间成本虽然相对较高，但是会对软件测试质量有一个质的提升，面对核心软件还是应当把质量放在第一位，时间上的付出也是值得的。

通过研究和实践，采用代码结合文档提取测试需求的方法实现代码粗读和精读后，能够更容易发现软件设计上的漏洞和深层次问题，可以提高测评机构在同行业内的核心竞争力。

（四） 拓展

测试机构及测试团队需要在内部审核过程中增加项目负责人或项目经理把关的环节，项目负责人和项目经理在拿到被测软件后采用代码结合需求的方法对软件实施分析，迅速对软件有一个高度的认识和深入的理解，在此基础上不仅可以在各测试阶段指导测试工程师实施测试工作，同时也更有能力对测试本身的质量（解决需求理解不准确、不全面、不深入的问题）进行把控，对测试文档中的缺失、描述不准确、方法不恰当、理解有歧义之处很容易能够指出来，避免带着问题层层闯关。

如果被测软件专业程度高，需要测试工程师提前做好基础性研究工作，取得软件需求后对软件服务领域中的专业术语，不理解的应提前学习，查不到的先请教领导或同事，实在找不到相关资料地再请教研制人员，不要上来就向研制方询问。比如测某个专业性强的软件，询问研制人员某个非常基础的术语会让委托方认为测试工程师是外行，引起研制方的轻视和反感，心理上对测试方的专业性和能力表示怀疑，行为上表现为不配合，为后续测试设置了障碍。反之，测试工程师提前通过代码阅读结合文档的方法可以更快更深入地了解专业软件，一旦研制方发现测试工程师具备行业领域知识，并能从专业的角度提出了正确的建议，会从心理肯定测试工程师的能力，对测试工程师尊重与认可，在此基础上进行的合作也是愉快的。很多经验丰富的测试工程师在项目实施过程中通过代码结合文档的方法能够做到比研制人员还熟悉软件，原因是测试工程师不仅了解了软件的各个细节，更能够结合丰富的测试经验从测试的角度去分析软件，为软件质量的提升提出了中肯的建议。

针对专业程度高的软件，对于测试工程师及团队、机构还可以分类进行技术积累，在使用代码结合文档提取测试需求方法吃透并完成一个行业领域的测试项目后，应及时反思测试过程中遇到的坑，总结避坑经验，总结测试心得和针对此类软件的测试方法，下次再遇到此类软件时可以少走弯路，也可以给其他测试工程师启发。在遇到典型问题时及时总结编写案例，同样可以给自己和他人启发，举一反三。长久下来形成技术经验总结、典型案例总结两大资产库。这也是一个评测机构的技术积累和文化沉淀。

三、结束语

通过代码结合文档的方式不仅可以解决需求理解不准确、不全面、不深入的问题，再进一步可以解决发现不了问题或发现不了高级问题的困扰。通过代码走查，在粗读、精读两级代码阅读的基础上，再进行变量分析和逻辑分析等方法可以进一步提高软件测试质量，有效提高测试工程师发现问题的能力，拓宽测试思路。基于以上研究，综合项目实施过程中的方法和经验，已将研究成果在多个项目中进行了实践，能够有效改善软件需求理解不准确、不全面、不深入的问题，减少测试内容及方法设计不合理、不充分、不规范、不易理解、缺乏可操作性的问题。减少反复修改，把控软件测试质量。进一步发现更多的软件问题和深层次问题。后续，笔者将继续补充及改进其中不完善之处，共同优化软件测试技术，提高测试质量，增强核心竞争力。

作者单位：罗文兵    徐海波    符号    北京赛迪软件测评工程技术中心有限公司

参  考  文  献

[1] 梅尔斯，张晓明.黄琳译，软件测试的艺术 第三版 [M]. 机械工业出版社，2018-08-01.

[2] 斯平内利斯.赵学良译，代码阅读方法与实践[M]. 清华大学出版社，2010-01-01.

[3] 宫云战，邢颖，肖庆.源代码分析 [M].科学出版社，2022-01-01.

[4] 麦斯阿塞克，马素霞译.需求分析与系统设计[M] .机械工业出版社，2020-01-01.

[5] 黄震宇.军用软件工程 [M]. 电子工业出版社，2020-04-01.

[6] 李学仁.军用软件质量管理学 [M].国防工业出版社，2022-2-13.