1、测试计划制定—— 根据项目具体需求制定相应的测试计划方案,该方案需要包括以下几点:
a、测试环境配置:包含功能、容灾、压力和性能的测试环境架构设计及机器资源配置信息;
b、测试内容:1. 列举本次测试所需覆盖的测试范围;2. 本次测试的重点;
c、测试手段: 介绍本次测试所涉及到的技术方法;
d、测试日常安排: 包括1. 测试人员; 2. 测试总时间; 3. 具体日程安排等信息;
2、测试用例设计—— 根据项目需求文档、设计文档及开发代码进行用例设计,具体流程如下:
a、进行用例设计(有测试人员独立进行设计);
b、用例评审会议(在用例设计完成之后,要求开发、测试人员、及其他项目相关人员一起对所设计的用例进行评审,评审结果在当天通过邮件的形式发出);
c、根据评审结果修改测试用例设计,再次通过评审后完成最终版本的用例设计;
a、使用技术手段实现测试用例,使其能够进行自动化测试;
b、完成自动化代码编写之后,即可进行功能测试;
4、BUG—— 主要指在发现疑似BUG之后的处理方式:
a、当测试过程中发现疑似BUG的时候,需要首先排除Case自身设计及编码问题,之后排除因为测试环境等其他因素的影响。在这里可以采用debug定位、log日志定位等问题定位方法;
b、在确认没有上述因素的影响之后,可以与开发人员进行沟通, 与其详细描述BUG的产生原因、复现该BUG的场景,最终确认是否为BUG;
c、在相关测试平台上登记BUG。 登记BUG主要是为了1. 针对该BUG增加相应的测试用例;2. 在后续其他测试人员接收该项目之后,能够在每次版本更新测试的时候,重点关注该BUG场景;3. 体现产品质量及测试人员的工作价值;
5、性能与压力测试—— 在完成功能测试,开发版本稳定之后,就需要进行性能和压力测试:
a、设计性能和压力测试场景,主要需要考虑一下几点:
1)产品功能点: 如,该产品是Nginx版本的Tair缓存数据库的Restful客户端,那么增删改查是必备的测试场景;
2)并发请求数:
并发请求数的设定相对比较复杂:
首先,需要保证机器性能如CPU占用率、内存使用、网络流量等机器性能指标没有成为瓶颈的前提下,查看QPS曲线在不同并发数下的变化曲线;
其次,选择QPS曲线稳定的临界点,选择临界点两边的几组并发数作为每个测试场景内的并发请求数。
3)预期的机器性能阈值: 在性能测试过程中所需要关注的一些性能指标:
(1)产品的性能指标:如 QPS、用户平均等待时间、服务器平均响应时间、吞吐量等等;
(2)机器的性能指标:如CPU占用率、内存使用、网络流量等等;
b、工具选择:web server的性能测试工具有很多种,选择合适的性能测试工具非常重要:
1)自己开发的压测脚本: 缺点:不够权威、反馈数据不够全面或者开发成本高;
2)http load 或者 web bench: 个人认为功能不够强大、反馈的测试数据也不够全面;
3)Apache ab: 经过前面几篇博文的修改介绍之后,功能强大,支持1. 按时间测试;2. 多个url、header、cookie读取测试。反馈测试数据也比较全面,如:总请求数、数据总传输量、QPS、服务器平均响应时间、用户平均等待时间、网络流量等等信息;
c、数据统计与图表绘制: 完成性能和压力测试后,需要验证测试过程是否正确无其他因素干扰,并且及时统计数据并绘制成相应的测试图表;
d、最后是对上述数据及图表进行分析,提供解释说明;