1.理解原始需求后,编写的测试用例才更有目的性。
2.细化需求点,把 “粗略”的需求,细化成一个个小需求点。熟悉功能需求后,要知道软件是怎么使用的,这也才能覆盖到各种操作。
3.理解软件的内部处理,单单是从需求点上面覆盖案例,测试用例只能覆盖“表面”的一层。一些内部的处理流程也许没有覆盖到,软件越是大型,耦合越大,“互相影响”会越多,若设计用例单单从模块本身考虑的话,很可能会对其他模块造成风险
4.从用户的使用场景考虑,这在一些网络设备比较重要,比如软件后期在一些真实的使用环境中使用
5.UI界面,功能,容错,兼容,性能等几大类,每个大类在根据软件的逻辑等进行划分成小类,后细分到测试点
6.
测试用例可以写的很详细,也可以写的比较简单。这要看公司的要求,有些公司要求测试步骤很细很细,包括测试结果和测试步骤一一对应。
要求测试步骤写的很详细的公司,一般是怕执行人员的执行力不到位,导致没有理解案例的目的,导致漏测。一般出现在新员工对软件系统的不熟悉。
如果测试步骤写的很详细的话,会很耗时间,而且过于详细的会限制执行人员的思维。个人认为测试用例的重点在于测试点上。