你说的对，很多时候就是因为没有规范，所以测试起来极其费劲。所以在小公司测试的时候，测试人员应该靠自己的努力去赢得大家的信任。这样慢慢地就可以帮助公司制定一些符合公司实情的规范，从而走上一个良性的循环。 个人建议：
优先进行功能走读。 我觉得这个还是测试流程的问题（如果LZ公司有测试流程的话）。像LZ说的字符串、输入文本框这些测试点应该在单元测试或者说单个UC测试的时候完成的，接下来就是正确的业务逻辑和业务功能以及异常的流程的测试。功能测试应该还是以正常的业务功能为主，业务功能不能通过这个软件根本没意义。 从这个问题本身来看，很简单，就是个测试优先级和测试阶段的问题。一般来说，冒烟-》主要功能-》细节展开。
缺陷严重性分级后，各个测试阶段对应发现不同级别的问题。BLOCKER级的问题在冒烟时发现，CRITICAL级的在主功能发现，MAJOR级的在走辅助功能时陆续发现，到什么数据检查之类的时候，已经只能发现MINOR以下的问题了。
但是看了楼下的各种回答，我发现，对于测试人员如何进行需求分析这个问题，是可以开一个专题的。在我眼里，一个高级测试工程师应该同时是一个合格的需求分析师。 結果很認真地讀了每一層，發現後面不知道誰是老大誰是lz了╮(╯▽╰)╭ 先主流程，再细枝末节的功能
楼主可以先整理出一部分核心的功能、流程用例，给开发，开发内测通过这些用例了再提交给测试部门 业务流程的BUG属于P1-P2级问题并且修复需要的时间相对多应当优先测试，再者才是P3-P4交互及显示上的问题，太纠结于细节会让测试过程变成钻牛角尖而浪费资源。在功能测试基本完成后可以进行安全及性能测试，通过阶段划分可以有效的降低产品质量风险并且进度可以得到控制。软件产品的质量并不是测试一个岗位能控制得了的，在有条件的情况下建议推广产品设计评审、视觉风格平生、技术方案评审、单元测试、接口测试等将产品质量保障向前推，让产品经理、开发人员共同加入到产品的质量保障上来。同时质量保障向后推建立好用户反馈机制、用户BUG复现机制，从这几个方面入手可以使产品质量得到很大提高。
页:
1
[2]
