关于一般性质软件服务公司的软件测试

yangzy707

我所在的公司是一家运营平台提供商；也是一家B2B网站运营商；说一下
公司开发部的人员相对比较少；而部门相互独立；而我所在的恰恰是运行负荷高；用户多；操作面广的一个平台；总的来说，前期的开发早已告一段落；现在仅仅是出于长期的繁杂的维护中....
前期的需求测试就是去了解整个系统的业务逻辑；并配合需求分析去讨论和研究流程；当然需求分析的重要性是不可言喻的；影响的是一个软件工程的生命力。基本上在该阶段TESTER是去了解和思考。在这个时期中，我们主要是去了解业务流程的主题，但是请勿忽略业务本身在实际操作中横向的延展面。因为很多的模块或者书页面是独立或是相对独立的存在系统中。力求得到实际的数据或者是数据模板；去了解作业流和数据流；理论上所说的什么校验和检查需求分析的错误或者是逻辑上的矛盾基本上在TESTER上是不会发生；而除非是质量部门；但是没有。
需求之后就要产生的分析画面设计（DEMO设计）、数据库结构设计、数据字典、技术框架；也有公司为了集约时间，或者赶时间而放弃做DEMO；其实这样的做法真的是不可取的；在demo的过程会产生很多一系列的问题；而分析画面和需求分析数据是能直接导出测试用例的编写。一个完整的的测试用例是建立在的分析页面之上；仅仅根据需求分析资料去做测试用例也不是不常见。甚至没有测试资料，直接进入测试也大有存在。同时测试计划和测试策略（包括在测试计划中）编写完成。
接下来是 进入代码阶段；编程是成为这个阶段的主要工作，而TESTER在编程中期之前要完成测试用例。编程阶段是出现意外情况比较多的时候；当然这和前期的需求以及分析的失误有较大关系；可能客户的新需求、分析的漏洞、技术实现的困难等等原因。编码的过程和单元测试是相互累叠的过程；这个单元测试过程一般由开发程序员来控制这次的冒烟测试。TESTE来做此单元最终确认测试。继而就是jira或者是mantis的BUG记录。
代码阶段的完成标志着测试工作的全面进行；这个时期要求的是测试员的优秀的业务遵循和沟通能力，展示tester的业务素质和技术能力；尽早的竟可能多的寻找出属于功能性的不足和业务逻辑的缺失。全面的系统测试中往往发现前期复活的BUG。
验收测试我们也是在系统测试之后，利用完正式的数据进行测试。其实算是种α测试；在建立不同场景进行模拟测试；所谓建立场景在系统测试用例设计之初就已经考虑；而验收测试将诸如此类的测试在正式数据环境下进行再次测试；而β测试也有进行；我们是运营服务平台，在确认α测试健康的情况下，直接上线运行；并通过产品服务部反馈各个区域用户的使用状况和问题。也算是一种β测试。
最后就是一个测试报告；其实测试报告所说明的就是一件事；BUG统计；至于测试部门对质量的评价以及认知我认为还没有达到这种境界去评价整体的性能以及质量；即使真的有发现诸如此类的问题；应该解决在上线之前而非上线之后的事情。

迪斯科

LZ头像好可爱