我一直在思考这个问题。
毕竟长期处于这样的状态，而测试工作责任划分中涵盖客户不满意、运行不顺畅的锅，所以在测试用例的编写下要尽可能地思考周全，减少这部分后果的产生。
没有需求，就要寻找其他支持性文档。需求文档在很多时候其实是没有的，而相对的开发在实际开发过程中也不会次次都写相关文档，比如概要设计、功能设计等。那么此时传到测试人员的工作就只是一个概念性的结果，然而这部分结果要推演出完整链条就只能靠测试人员的工作经验了。
功能说明书
网络获取相同或相似功能说明书，对一些明确拥有规范的协议进行研究并整理。
过往经验
根据以往工作经验进行软件预判，针对软件易用性、稳定性、安全性等进行规划。
和开发交流
与开发沟通功能实现流程，逆向推演符合流程的结果和不符合流程的软件提示。对流程的每个节点进行预判，针对一些具有争议性的问题点进行邮件记录。
交叉模块
交叉模块考虑，在新功能与原软件的兼容和交叉部分进行梳理，最好是绘制出相关模块调用关系图，确保无一遗漏。
参考
参考同行业相关文档，百度关键功能，从中获得经验。
边测试边完善测试用例
用例编写并不是前期编写完后期就不用再管的一项工作，在测试过程中通常会发现很多在测试之前没有想到的点，这些部分需要完善在测试用例中，以便后期需要时参考。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
