自动化测试问题总结

总结一些自动化测试常见的一些问题。

1.你的自动化测试框架包括哪些模块？
（1）测试用例管理模块：打了不同标记的测试用例，包括测试分类、测试用例所属模块、优先级、作者
（2）页面管理模块：主要包括各个页面元素定位和操作方法的封装，采用页面对象模型（Page Object Model，POM）的设计和实现。
（3） 测试数据管理模块：可以采用数据驱动测试框架来管理和使用测试数据。通过将测试数据和测试代码分离，实现数据和测试逻辑的解耦，提高了测试用例的可维护性和可复用性。（实际操作：我用的C#，创建DataPrepare文件夹，放置每个用例对应的测试数据，每个用例对应一个类，将一些公用的测试数据再剥离出来，创建对应的类或枚举，比如我做医疗信息系统科室信息是公用的，我就创建一个depart类，类包括id、name、keywords属性，再创建一个类将不同的科室实例化。）
（4）数据库操作模块（Using System.Data.SqlClient库实现数据库的增删改查、还原数据库、备份数据库的操作）
（5）测试执行引擎模块（批量执行用例，或者按照分类来执行用例）
（6）日志模块：日志记录的级别、格式和输出目标。
实例：我的日志是以*.txt方法打印输出的，命名规则是用例名称，将每个用例的输出日志*.txt文件和执行失败的截图放在以用例名称命名的文件夹下，将所有当次执行的用例放在以时间戳命名的文件夹下。在日志中我会添加一些信息方便定位问题，比如会把exepect和act值打印出来，Pass和Fail结果打印出来，如果执行Fail会进行截图。
（7）报告模块：报告是以xml格式呈现的，主要包含了各个执行用例的名称、作者、执行结果，及通过和失败数目的汇总。
（8）邮件模块：调用邮件库（C# System.Net.Mail），配置服务器信息，编写邮件发送函数，构建邮件内容，包括：邮件主题、收件人、抄送人、正文内容和附件。定时发送邮件。
实例：可能遇到一些认证问题、网络问题、邮件被拦截问题。添加异常处理机制，在邮件发送功能中添加异常处理机制，捕获发送过程中可能出现的异常，并记录错误日志以便后续排查问题。

2.测试脚本维护成本高
（1）功能变更未更新用例：比如维护最基本的冒烟测试用例，其实很难发现重大缺陷的，执行的时候报错，很多时候是需求改变模块功能改变未通知到自动化测试工程师，没有维护好脚本。
（2）写很多用处不大的测试用例：如果资源有限的情况下，建议维护优先级P0、P1级别的用例就可以了，或者维护冒烟测试用例。但是一些经理或者上面的管理者觉得晚上设备空闲着，搞个自动化测试吧，这样晚上也能测了，等于浪费了资源。反正测试这玩意儿都是重复劳动，根本不需要人工干预。写了一堆脚本，白白增加了维护成本，但没有实际的产出。

3.逆向测试场景的用例不适合放在自动化测试中
因为逆向思维测试的不确定性，这种不确定性会影响自动化测试的最终运行结果。对于执行自动化测试来说真正可拍的不是逆向思维用例，二十那种不知道什么时候就会报错的测试场景和用例。针对功能文档、需求变动不多的正向测试场景。

4. 编写测试用例
编写测试用例的过程和其他开发任意的编码工作没用什么本质上的区别，也别指望用例脚本可以一次性的编写到位，脚本大多数都是需要一次一次的优化，起初写的效率低一点也没关系，我们先确保可以跑通，复用性和健壮性可以稍微差点。
但是跑通后，及应该着眼于性能方面，如果你用的python，跑几条用例是完全没问题的，因为python是动态语言，变量执行对象的时候编译器无法做任何有删，另外加上他本身是解释指向性，所以是在跑大量测试用例的情况下，一定会出现运行周期时间长与以外报错的情况出现，此时提高代码的性能就成了重中之重，算法时间复杂度的优化、内置方法的合理使用、避免全局变量、减少循环等等都可以给我们的代码提供响应的性能提升。