个人理解大概从3个方面去考虑:
1. 表单，也就是最基础的功能；
2. 逻辑方面；
3. 业务流程。
今天去面试，面试官问我一个很让我说不清的问题，她问我如何写好Expected Result，说实话当时听到这个问题我有点茫然，我拼命的考虑如何去诠释这个问题，事实上，这么多年工作，这么多年的测试用例中，我并未关注这个问题，一个好的Expected Result，个人认为就是和将要实现的功能或者是需求要完全匹配。今天由于个人原因精力也不是很集中，似乎头脑处于空白时段，听到耳朵的问题，似乎大脑不懂得去思考。对于今天的面试我并不满意，但是今天面试官问我的一些问题，其实都很基础也很简单，但是细想起来似乎又不是很容易回答，嗨，总之是个失败的面试！
对于一个好的测试用例，无非就是三点：
1.易用性：对于一个即熟悉测试工作，又熟悉被测应用的测试人员，应当可以花费很少的时间就可以理解测试用例中表达的测试思路，并可以很快的执行完这个测试用例。对于不熟悉测试工作，不熟悉被测应用的人来说，也完全可以参照着该测试用例执行下去。
2.易维护性：当开发过程中的某些因素影响了测试需求，测试用例的作者或其他测试设计人员，应该可以花费很少的时间就完成定位并维护所有相关测试用例的工作。
3.可重用性：一个好的测试用例要保证可以随着版本的变化它始终保持可用状态，不能因为版本的变更，导致测试用例无效或者冗余。
