软件测试是一项活动，但如果我们仅仅把测试当成一项为把关软件质量的活动来执行，或许你会发现这项活动会有些繁琐，有些枯燥，没有成就感……

　　软件测试又是一种艺术，但如果每个测试工程师都把自己视为艺术家，追求尽善尽美，开发同学可能就要疯了……

　　当然，这里并不是讨论软件测试是什么这个命题，而是作为一个测试人员，怎样去发现测试中的美，从而快乐地工作。

　　或许我们可以在测试活动中添加一点点艺术的元素，让测试“美”起来，使你不再有繁琐感，不再感觉枯燥，不再没有成就感，让你真正爱上测试。

　　下面从功能，性能，测试数据，覆盖率以及测试模型分别扯下测试中的美，纯属个人拙见，不一定有用，不足之处，望请各位大侠前辈师兄多多指导。

　　功能之美

　　功能测试美在哪里？

　　美在知识面的广

　　或许对于那些向往开发工作的测试员来说，也许“功能方向的测试技术含量是不高的”，或许有人会认为功能方向的测试只要了解需求，熟悉业务，点点鼠标就能完成，曾经我也是这么认为，看来是自己对功能测试认识太浅以及过于浮燥。

　　如果要想真正的做好每一个项目的功能测试，要知道的知识还是很多的，比如操作系统(Linux)，数据库(Oracle，MySQL，Sybase ASA)，网络以及一些常用的软件与测试工具及bug管理工具(twork，automan，QC，PLSQL)；

　　如今的大多数应用，不管是CS还是BS，都与数据库有亲密的接触，所以我们还要了解整个系统的数据结构，每个功能对应哪张表，进行哪些数据操作，前台展示是否一致，这些都需要功能测试人员自己去验证；

　　当然，我们还需要对代码结构有一定的了解，测试并非一次就可以通过的，在开发同学fix一个new状态的bug后，不管是close或reopen，测试人员不防看看代码，懂一些代码知识也能更好地分析和定位bug，特别涉及到js等前端代码时，因为很多界面和功能兼容性问题都是由js等前端代码造成的；

　　除此之外，我们还需要知道测试策略，测试方法以及设计测试用例的方法，如等价类，边界值，场景法，因果图，判定表，错误猜测法等。

　　如果你对这些还是不符合你对美的标准，请继续往下看。

　　美在测试思维的奇异

　　有人说当对测试技术与业务的掌握达到一定的程度上时，测试思维在此时就显得尤为重要。

　　在测试一个日常或项目前，通过对需求，UC及对系统的了解，能不能探索出一个最佳的测试方案和测试计划。特别是日常，因为日常较小，在了解或评审UC后，大概的测试方案或许应该浮现于你的脑海中。

　　测试用例是测试计划的进一步细化，在做TC设计时，能不能对那些测试用例设计方法信手拈来，使TC能覆盖一些特别的路径，从而发现那些更加隐秘的bug，这也是测试思维神奇的地方。

　　很多时候，喜欢thinking in testing这三个单词，当测试对象已经经过常规的测试轰炸后，如果我们能换个思维方式，从不同角度模拟更多的用户场景，或许能在“山穷水尽疑无路”时出现“柳岸花明又一村”的景象。

　　这就是测试思维奇异的地方，或许作为新人，我们还无法达到这种境界，但这并不防碍我们去思考。

　　美在功能的完整

　　在功能的世界里，只有完整，因为不完整就意味着是缺陷，那是bug！

　　而在淘宝，功能的完整有两种，一是指测试对象的功能要完整，二是指测试对象的界面要完整。

　　测试对象界面完整具体指界面美观，某一功能的界面色调与整体页面的色调要和谐，易用性强。试想，一个界面操作级难的功能，又有多少人会去使用，客户第一，我们拿实际行动证明。

　　喜欢下厨房的人或许有这样的体会：做一道好菜，看之有色，闻之有欲，食之有味。功能测试中的测试对象也如此，只有做好了，用户才会发出“哇”的惊叹，不然只有一声“哦”的敷衍，质的不同，这就是功能完整美魅力！

　　看着一个个功能在经过你的测试把关下发布上线，供千千万万的用户使用，你还会因为做功能测试而感到无成就感吗？相信你不会。

　　先休息下下，下篇内容预报：性能曲线美，数据准确美，谢谢！

相关链接：