1.软件测试用例怎么写才能更全面,才不会乱【测试大纲怎么写】你好，可以参考：测试也很累的喔，还有你可以找找：史上最全测试用例设计方法一、界面规范1.是否整个软件的字段的字体、大小、颜色、排列一致2.是否整个软件的字段后都有冒号（如果有，是否都属于同一种字体）二、用例编写粒度准则1.对于不作为一个完整业务流的操作，如增、删、改等，每个操作（比如增加）作为一个用例 。
2.对于完整的业务功能实现的操作，把实现一个业务功能的目的作为一个用例 。3.对于紧密关联的业务功能，把关联的业务功能实现作为一个用例 。
4.对于异常情况下的操作，作为一个用例 。5.对于在异常情况下的操作的数据处理，作为一个用例 。
2.测试用例书写要详细到什么程度这里说的不是设计测试用例的数量，而是测试用例的书写 。
如：前置条件： entity表中有一个 XX字段 = XX ,oo字段 = oo 的实体记录 。
等等，把需要准备的数据也写到TC里面了 。
很费时间！！
而且由于是对内开发的软件，开发方经常改动页面，导致TC也要更改 。写的粗一点的还好说，像我写这么详细，改起来真的很痛苦 。但不写这么详细又怕不对（我真是如履薄冰一样的前行啊 。）
在各处搜索了一下，觉得下面这个人说的最有道理，以后可以参考之 。
@smilehe：切身感受：
如果自己写用例并自己测试，除了边界上或者异常等处必须详细，之外的可以“自己清楚”；
如果写给别人用，老老实实的写详细；
如果自己写 用例并打算日后也做为其他项目参考，建议事后补详细！
在设计用例的时候可以用mm图将功能点仔细分析，具体每一个用例后，可以在后面列出要输入数据的类型作为备注，防止在FREETEST中书写TC时遗忘 。
在freetest上，先写上名字就行 。反正是自己测试，测试点都在mm图上 。等有时间，或者项目接近尾声的时候/开发不再有改动时，再去完善TC 。
3.软件项目的测试文档如何写目前没有经典的定义 。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略 。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档 。
不同类别的软件，测试用例是不同的 。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快 。笔者主要从事企业管理软件的测试 。因此我们的做法是把测试数据和测试脚本从测试用例中划分出来 。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案 。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例 。
随着中国软件业的日益壮大和逐步走向成熟，软件测试也在不断发展 。从最初的由软件编程人员兼职测试到软件公司组建独立专职测试部门 。测试工作也从简单测试演变为包括：编制测试计划、编写测试用例、准备测试数据、编写测试脚本、实施测试、测试评估等多项内容的正规测试 。测试方式则由单纯手工测试发展为手工、自动兼之，并有向第三方专业测试公司发展的趋势 。
要使最终用户对软件感到满意，最有力的举措就是对最终用户的期望加以明确阐述，以便对这些期望进行核实并确认其有效性 。测试用例反映了要核实的需求 。然而，核实这些需求可能通过不同的方式并由不同的测试员来实施 。例如，执行软件以便验证它的功能和性能，这项操作可能由某个测试员采用自动测试技术来实现；计算机系统的关机步骤可通过手工测试和观察来完成；不过，市场占有率和销售数据（以及产品需求），只能通过评测产品和竞争销售数据来完成 。