使用系统的同时,你应该具备行业知识。系统可能是针对某个专业领域设计的。例如一个期货交易系统。你没有基本的期货知识,比如什么是持仓,什么是平仓。那么你如何能真正理解这个系统呢?当你有了业务知识以后,你会进行更深入的思考,来全面测试系统。
你还需要具备良好的软件知识。比如某些控件的特性。单选框只能单选,不能多选。日历控件是否可以手工输入非法格式等。这些都是应具备的意识。
最后加上你的主观判断,你对系统的整体感觉怎么样?是否越用越厌烦,为什么厌烦。系统的反应速度是否可以容忍,细节处理是否圆滑,等等。
在你认识系统的时候,可以使用一些方法,来帮助你更有效率地学习。比如可以画一些流程图。一图胜万语。同时,你也留下宝贵的文档。当然,这个步骤中,你也要随时注意保留和更新文档,以备后用。
沟通:需求规格不一定非要以文档的形式表现出来。软件既然能做出来,那肯定是有需求的。而最清除需求的,一定是软件的直接制造者,开发人员。开发人员自己知道需求,但一般不会主动和测试人员沟通。因此,测试一定要主动和开发人员沟通。可以安排会议,让开发人员给测试人员介绍系统,并演示系统。让测试人员对系统有一个整体了解。然后测试人员能进行更细致的测试。在进行细致测试的时候,一定会有更多不明确的地方。这时就需要利用自己的行业知识,计算机知识等,猜测一部分。不需要每个细节都去询问开发人员。因为开发人员也有自己的工作,他们不希望花太多时间来给你解释。
有些项目中,客户会直接参与到项目组来。这时,测试人员在权限允许的情况下,可以和客户进行沟通。客户那得来的需求,是最原始的需求。但是,客户未必有良好的表达能力来描述希望的功能,也未必有计算机知识,因此不能描述出一些隐式的需求。在被允许的情况下,测试人员可以和客户进行交流,不仅可以帮助客户正确描述出真实需求,测试人员也能详细了解需求。但是项目是要考虑成本的,客户的期望是无限制的。在客户提出需求以后,测试人员要先和PM或其他相关负责人协商后,才能将与客户交流得来的需求,作为测试的依据。同事,第一时间告知相关开发人员最新的信息,也记录成文档。这时,你就将非文档形式的需求,转换为文档形式了。至于文档的格式,不一定要按照标准SRS的格式。因为它本身就不是个规范的SRS。以任何容易理解的方式,组织你的文档。
有时候,会根本找不到可以沟通的人。不要奇怪,确实就是有这种时候。比如:
1. 测试一个开源软件
2. 接到一个测试外包,但又没有得到相关文档,为了追求利益,还是接下了
3. 软件项目组的部分人员已经联系不上等等
这时候,一方面需要PM协调获取相关资料,联络相关人员。另一方面,测试人员也可组织头脑风暴,利用集体的智慧,共同探讨和猜测软件中的各个环节。也可以安排Bug Bash,让尽可能多的人员参与随机测试。一定会有人提出具有创造性的意见的。
在进行以上步骤的时候,利用良好的工具,能让你事半功倍。我经常在使用的一个工具,就是Mindjet MindManager。这是一个很好的,帮助扩展思维的工具。它以分支的形式,来表现你的思维层次。你可以先列出个最基本的系统整体结构,然后逐步细化,增加分支。不要急于一次就将真个系统分析透彻,这是不可能的。你在进行以上步骤的时候,随时会细化这个结构。当项目结束后,看看这个结构图,简直可以当作SRS来参考了!
文章来源于领测软件测试网 https://www.ltesting.net/