Beta阶段测试报告

测试点

选择的测试点有两个

• 一个是用户与浏览器（客户端）之间的节点，也就是模拟用户对浏览器的操做与获取的响应来进行测试，称之为“前测试点”(Front Test Point)。
• 一个是浏览器（客户端）与服务器之间的节点，也就是模拟客户端来向服务器收发HTTP请求来进行测试，称之为“后测试点”(Back Test Point)。

咱们没有在服务器内部设置测试点，也就是说咱们将服务器视为一个黑盒。

测试阶段目标(Roadmap)

1. alpha阶段：
   • 搭建自动测试环境
     • 在后测试点，实现测试逻辑和测试数据分离，为持续测试作基础。
     • 在前测试点，实现自动化测试，为持续测试作基础。
   • 检验各功能在理想条件下是否如规格书所描述地运行。
     • 理想条件：彻底符合预期的简单输入。
2. beta阶段：
   • 兼容性检查：测试在不一样终端、不一样平台、不一样浏览器上的运行状况。
     • 不一样终端：mobile、PC
     • 不一样平台：mac OS, windows, android, ios
     • 不一样浏览器：chrome, edge, firefox
   • 安全性检查：使用攻击性的测试思路，挖掘安全性漏洞。
     • 泄露敏感信息的代码、包、数据、接口。
     • 能够被利用的接口。
     • 在被攻破后的可执行的应急措施。
3. gamma阶段：
   • 易用性检查：检验是否存在不合理的设计/不易用的情景。
     • 良好的响应性。
     • 快捷的操做。
     • 直观的反馈。
     • 需求的知足程度。
   • 鲁棒性检查：检验边界条件，在非异常的极端/特殊状况下各功能是否如规格书所描述地运行。
     • 在后测试点，构建复杂测试样例。
     • 在前测试点，构造usercase模拟一套用户的操做，并在此基础上实现并行测试。
       • 并行测试：构建多个usercase，随机伪并发执行，检验是否运做正常。

各阶段出口条件：

1. alpha：在理想条件下运行符合规格描述。
2. beta：经过安全性、兼容性检查。并经过alpha阶段的回归测试。
3. gamma：经过鲁棒性、易用性检查。并经过alpha, beta阶段的回归测试。

测试工具

测试架构彻底使用Django的django.test模块。

服务器端对两个测试点使用不一样的作法：

• 对于前测试点，由于须要在js代码中指定后端的域名+端口，因此没法使用django.test模块初始化时提供的具备随机端口的django测试服务器。因此咱们每次进行前测试的时候，都须要手动在本地创建一个测试服务器，而后手动刷新一下它的数据库，将测试数据填充进去。
• 对于后测试点，直接使用django的fixture系统来填充测试数据库。

客户端对两个测试点采用不一样的工具来模拟：

• 对于前测试点，使用Selenium模拟客户端。
• 对于后测试点，使用Django原生的Client模拟客户端。

前测试点

设计模式

使用Page Object做为Design Pattern。即，将每一个页面做为一个类，将该页面提供的服务做为接口。每一个类内部本身维护该页面的元素定位符。

测试环境的搭建

使用Fiddler对域名和端口进行重映射，将对远端服务器的请求转换为对本地服务器的请求。
经过使用openssl本身签个证书以及使用werkzeug_debugger_runserver实现本机支持https。

本地劫持腾讯验证码服务器

由于咱们使用了腾讯验证码做为安全措施，但这个措施会致使自动测试的不可行。解决方案是本地架设了一台假的腾讯验证码服务器，而后利用Fiddler劫持一切发送给真的腾讯验证码服务器上的请求给假的上面去，从而确保自动化测试的可行性。

端口状况

• nginx服务器，开在80端口，负责分发html, js文件。
• django服务器，开在随机用户端口，负责后端接口的供应。
• faketx服务器，开在3668端口，负责伪装本身是腾讯的验证码服务器
• testcase进程，开在随机用户端口，负责调用selenium，而后selenium打开浏览器，请求nginx服务器获取网页文件，再经过ajax请求django服务器获取后端数据。

代码覆盖率计算方法

使用jscover，启用local-storage来支持跨页面的插桩记录存取。详见。

基本流程以下：

1. 使用jscover对前端js文件插桩。
2. 修改测试代码，使得每一个WebDriver被销毁前会保存插桩记录。
3. 合并插桩记录，获得覆盖率报告。

不过须要注意的是，仅仅只对js文件插桩，裸写在html文件中的js代码不会被归入覆盖率的统计中。

测试思路

细的来讲：

1. 检查用户须要知道的信息的元素是否出如今页面上。
2. 检查页面上是否出现了不应出现的元素。（例如已经登陆的用户却在界面上找到了登陆按钮）
3. 检查用户操做是否获得预期的响应。
4. 检查页面跳转逻辑是否如逾期执行。
5. 检查异常处理是否合理完善。

粗的来讲：

1. 检查典型用户的一套操做流程是否能正常执行，而且用户是否可以的获得他们想要的信息。
2. 检查用户的异常操做是否会获得合理的报错，并能顺利恢复现场。

测试样例总览

此处不将列出详细的测试用例内容，只列出每族测试样例的概述。

• [+]号表示还未完成。

---

• 页面跳转逻辑检查
• 功能检查
  • 登陆功能
  • 注册功能
  • 注销功能
  • 搜索功能
  • 切页功能
  • 评论发表功能
  • 我的信息修改功能
  • 评论赞踩功能
• [+]页面冗余检查
• 兼容性检查
  • [+]页面长宽比兼容性检查：在不一样长宽比的浏览器界面下是否都能有良好响应
  • 浏览器兼容性检查：在不一样浏览器中是否都能有良好响应
    • chrome, firefox, edge
    • [+]国产浏览器
  • [+]操做系统兼容性检查
  • [+]硬件平台兼容性检查
• [+]易用性检查
  • 在登陆/注册信息不完整/错误的状况下可否给出有效提示引导用户完善信息
  • 在评论超字数的状况下可否给出有效提示引导用户
  • 各功能的响应速度是否合理

后测试点

前提

咱们默认一切规格规定的渠道的用户输入都已在前端被充分检验正确性（例如，注册时用户名、密码是否符合格式），故在后端不作任何相关测试。

代码覆盖率计算方法

使用python的coverage获取代码覆盖率。仅计算rateMyCoure目录下的代码。

测试思路

1. 检查各接口是否如规格描述地正确响应。
2. 检查是否存在不应暴露给用户的资源也暴露了。
3. 使用代码覆盖率，检查是否存在无用代码。

测试样例总览

此处不将列出详细的测试用例内容，只列出每族测试样例的概述。

• [+]号表示还未完成。

---

• 标准检查：对于很是良好的输入的状况下，各接口是否给出正确输出。
• [+]边界检查：对于知足传入需求，但处在边界的输入，各接口是否能给出正确输出。
• 安全性检查：是否存在能在无权限的状况下获取敏感信息的接口，或在无限制的状况下占用过多服务器资源的接口。

Beta阶段测试结果

由于大量使用了python的subTest，不少测试样例被转变成了一组子测试样例的线性执行序列，因此统计测试样例数目已经变成一件没啥意义的事情了，之后也都不将统计。

前测试点

commit: 5c6e26850dd8f74f423433f78d60535647bd90ef

Bug:

• 切页功能：1, 2, 3
• 赞踩功能：1
• Edge的兼容性问题：1, 2
• 其余：1

Invalid:

• 切页功能：1

js覆盖率：

后测试点

commit: ff51f9ec21efb90cce08e5585c90cb7235cd7da1

Bug:

• 评分功能：1
• 评分计算：1

Invalid:

• 评分计算：1

python覆盖率：

安全性检查

• 分析书
• 解决报告书

主要解决的问题：

• Django的秘钥的存放
• CSRF攻击
• XSS攻击
• Clickjacking攻击
• 启用HSTS

回答问题

在测试过程当中发现了多少Bug？有哪些是Beta阶段的新Bug？有哪些是Alpha阶段没有发现的Bug？

边敲边测的单元测试中发现的bug数没有统计，由于没有进issue。黑盒测试的过程当中发现了9个bug。没有alpha阶段遗留下来的bug，所有都是beta阶段的新bug。

你是怎么进行场景测试（scenario testing）的？包括你预期不一样的用户会怎样使用你的软件？他们有什么需求和目标？你的软件提供的功能怎么组合起来知足他们的须要？（仅描述新功能便可）

场景测试

模拟用户的一系列操做，并在每一个操做的步骤上检查页面是否如用户指望进行。

1. 一名无聊的学生，需求是查看别人对课程的评价，而且发表本身的评价
   1. 注册
   2. 登陆
   3. 搜索课程
   4. 点进课程页面
   5. 查看评论
   6. 点赞/踩评论
   7. 添加评论
   8. 注销
   • 赞踩功能可以让这名学生在探索课程评价的时候更好地参与并互动进去。
2. 一名选课中的学生，需求是大量浏览别人对课程的评价
   1. 注册
   2. 登陆
   3. 搜索课程
   4. 点进课程页面
   5. 查看评论
   6. 若已经检索完，则注销，不然返回3
   • 切页功能可使这名学生在大量检索课程时获得更佳高效、温馨的体验。

你是否有回归测试确保新功能的加入没有影响已有功能？请给出一到两个测试用例并解释。

所写的全部测试样例都是回归测试的一部分。

def test_regist_exist_user(self):
    page = HomePage(self.driver, self.domain)
    page = page.goRegistPage()
    page.fillForm(
        name="rbq",
        email="rbq@test.com",
        password="abc123!@#",
        repassword="abc123!@#",
    )
    page.submit() # Should still be RegistPage
    rs(min=3)
    page.checkIsSelf()

注册功能是alpha阶段已经实现的，在alpha阶段写完的这个测试样例在beta阶段就成为了回归测试的测试样例。它作的事情是打开主页，进入注册页面，填写表单，提交，而后检查是否注册失败（由于是试图注册一个已经注册了的用户）。

给出你的测试矩阵（test matrix），也即在什么样的平台、硬件配置、浏览器类型……上对你的软件进行测试？

Window Size	Browser
PC	Chrome
Mobile(Only for Chrome)	Firefox
	Edge

你的软件Beta版本的出口条件（exit criteria）是什么？也即在什么条件下，认定你的软件已经足够好，能够发布Beta版本？

经过安全性、兼容性检查。并经过alpha阶段的回归测试。主要功能的代码在测试中都被覆盖到。